Làm thế nào để tránh bị tiết lưu?

Tôi đang viết một trò chơi iOS nối mạng. Khi gửi các gói với GKMatchSendDataReliable(mà tôi giả sử là UDP với mã nhận gói tin riêng được viết) ở mức 60 gói mỗi giây (vì vậy 16 ms giữa các gói liền kề), thời gian ping trung bình nhanh chóng trở nên tồi tệ hơn: Tôi đã mở 7 trận đấu GameCenter bên dưới (lần lượt từng trận đấu khác ) và chỉ cần gửi một "lũ" 100 gói (với tốc độ 60 gói mỗi giây). Tôi đã đo thời gian làm tròn trung bình và đây là kết quả:

[ 21:16:39 ]:  I saw an average roundtrip time of 52.342787 ms, he saw 54.496590 ms
[ 21:16:34 ]:  I saw an average roundtrip time of 62.631942 ms, he saw 61.991655 ms
[ 21:16:45 ]:  I saw an average roundtrip time of 88.394380 ms, he saw 83.619123 ms
[ 21:16:51 ]:  I saw an average roundtrip time of 179.053118 ms, he saw 156.869141 ms
[ 21:16:57 ]:  I saw an average roundtrip time of 75.025076 ms, he saw 75.419723 ms
[ 21:17:23 ]:  I saw an average roundtrip time of 8832.082488 ms, he saw 7616.877558 ms
[ 21:19:33 ]:  I saw an average roundtrip time of 25088.962344 ms, he saw 16833.064914 ms

Sau 2 lần kiểm tra cuối cùng, kết quả là khoảng 1000 ms.

Có vẻ như tôi đang bị điều chỉnh, rất có thể là do ISP của tôi. Vì đây là một trò chơi iOS, mọi người sẽ sử dụng các kết nối dân cư thông thường.

Khi tôi thay đổi tốc độ gửi gói thành chậm hơn 10 lần (vì vậy 1 gói cứ sau 160 ms), các thử nghiệm mất nhiều thời gian hơn, nhưng thời gian làm tròn vẫn luôn thấp.

[21:31:27]: Tôi thấy thời gian khứ hồi trung bình là 55.289109 ms, anh ấy thấy 69.032727 ms

Vì vậy, có vẻ như để giữ độ trễ thấp trên kết nối (và không bị "trừng phạt" bởi các ISP) Tôi phải giảm tốc độ gói tin tôi gửi. Hãy nhớ rằng đây là những gói rất nhỏ, như tối đa 40 byte, nhưng tôi vẫn đang bị điều chỉnh.

Tôi đang tìm hướng dẫn về số lượng gói UDP tôi có thể gửi mỗi giây để tránh bị điều chỉnh! Có bất kỳ hướng dẫn chung ở bất cứ đâu?

Ngay cả các trò chơi hành động dựa trên PC tại nhà hoặc MMO lớn cũng chạy các gói của họ ở tần số 60Hz. Ngoài ra, việc có kích thước gói thực sự nhỏ không nhất thiết phải là một điều tuyệt vời, mỗi một trong những gói nhỏ đó có một chi phí lớn khi chỉ gửi nó đi.

Hãy thử chụp để cập nhật 10Hz với một số phép nội suy phía máy khách. Tôi cho rằng bạn đã nội suy vì sẽ luôn có độ trễ ping.

Đọc về kích thước MTU và ném thêm thông tin vào đó để bao quát khung thời gian dài hơn. Kích thước gói trung bình ở lớp vận chuyển sẽ là 1400 hoặc hơn, bất cứ thứ gì trên kích thước MTU sẽ phân chia thông điệp của bạn và gây ra nhiều chi phí hơn.

Đầu tiên, bạn phải đảm bảo toàn bộ dữ liệu lớn như thế nào. ISP của bạn rất có thể sẽ quan tâm đến các byte thực tế được gửi, không phải số lượng hoặc tần suất của datagram. Nếu bạn đang gửi các datagram có kích thước tối đa (65507 octects) có kích thước 60 lần mỗi giây, thì bạn đang gửi khoảng 30 Mb / giây ngược dòng. Không phải ai cũng có loại kết nối đó.

Hãy nhớ rằng tiêu đề IP dài 20 octet và tiêu đề UDP dài 8 octet. Đó là thêm 28 octet bạn đang gửi cho mỗi datagram.

Nếu bạn không tối đa hóa kết nối của mình, có nhiều nơi các gói của bạn có thể bị trì hoãn: cụ thể là HĐH của máy khách, cổng của bạn (có thể là bộ định tuyến không dây hoặc modem cáp), ISP của bạn, ISP khác của nhà cung cấp khác, nhà cung cấp khác cổng, hệ điều hành khác của người khác trong số những người khác.

Trong trường hợp bạn chưa sử dụng nó, tôi khuyên bạn nên sử dụng Wireshark , đây là một công cụ cực kỳ mạnh mẽ để chẩn đoán các sự cố mạng. Hãy nghĩ về nó như là một trình gỡ lỗi, nhưng để kết nối mạng.

Có một số cách bạn có thể chẩn đoán lưu lượng truy cập mạng bằng Wireshark:

• Sử dụng Wireshark trong PC trong cùng mạng với thiết bị di động, với một trung tâm bừa bãi và đặt thiết bị mạng của bạn là lăng nhăng

• Đặt PC làm cổng không dây và kết nối thiết bị di động của bạn với cổng đó, sau đó lắng nghe với Wireshark trên PC đã nói

• Chạy Wireshark trong cùng một máy như trình giả lập

• Chạy tcpdump trong chính thiết bị (dễ dàng trên Android, yêu cầu bẻ khóa trên iOS), sau đó đọc dữ liệu đã chụp trên Wireshark

• Tạo một chương trình đơn giản thực hiện chính xác điều tương tự, nhưng nó hoạt động trên PC và sử dụng Wireshark trong đó.

• ... và nhiều người khác

Bạn muốn kiểm tra những gói nào sẽ được gửi, và khi nào. Ví dụ: nếu sự chậm trễ xảy ra trước khi chúng được gửi đi, bạn sẽ bị HĐH điều chỉnh; trong khi nếu bạn nhận được độ trễ ngay cả trên phiên bản máy tính để bàn của cùng một chương trình, điều này có nghĩa là bạn đang bị điều khiển bởi mạng ở đâu đó.

Thông thường, nếu bạn đang bị điều chỉnh bởi mạng, bạn nên lấy các datagram loại 4 của ICMP, vì vậy bạn có thể sử dụng chúng để kiểm tra chính xác nơi bạn đang bị điều chỉnh.

Tóm lại, có nhiều lý do tại sao các gói của bạn có thể bị chậm trễ, và sẽ là khôn ngoan nếu tìm ra vấn đề ở đâu trước khi bạn bắt đầu cố gắng giải quyết vấn đề.

Có vẻ như một trong những giả định của tôi là sai. Theo đó :

Chế độ GKMatchSendDataUnreliable, hình ảnh được truyền trong cái gọi là UDP. GKMatchSendData Hình ảnh chế độ có thể gửi được bằng TCP. Nó nên là một GKMatchSendDataUnrelible thường.

Thay đổi chế độ gửi thành UDP thực (nghĩa là GKMatchSendDataUnreliable) xuất hiện để duy trì tốc độ ping thấp ở mức 60 gói mỗi giây. Có vẻ như tôi đã bị Nagles tấn công lần nữa .

Tôi vẫn nhận được hành vi kỳ lạ (thời gian có thời gian ping rất cao), nhưng tôi không chắc nguyên nhân gốc (ISP hoặc tắc nghẽn mạng).

[ 10:30:33 ]:  I saw an average roundtrip time of 39.908923 ms, he saw 48.437794 ms
[ 10:30:39 ]:  I saw an average roundtrip time of 26.278577 ms, he saw 27.023854 ms
[ 10:30:48 ]:  I saw an average roundtrip time of 23.254163 ms, he saw 24.495182 ms
[ 10:30:54 ]:  I saw an average roundtrip time of 37.333127 ms, he saw 34.780404 ms
[ 10:31:03 ]:  I saw an average roundtrip time of 29.198575 ms, he saw 29.071106 ms
[ 10:31:11 ]:  I saw an average roundtrip time of 49.030299 ms, he saw 48.675459 ms
[ 10:31:18 ]:  I saw an average roundtrip time of 34.031792 ms, he saw 34.698117 ms
[ 10:31:24 ]:  I saw an average roundtrip time of 30.058642 ms, he saw 32.814952 ms
[ 10:31:30 ]:  I saw an average roundtrip time of 53.110438 ms, he saw 54.271453 ms
[ 10:31:45 ]:  I saw an average roundtrip time of 119.693933 ms, he saw 107.616359 ms
[ 10:31:50 ]:  I saw an average roundtrip time of 222.644443 ms, he saw 229.589861 ms
[ 10:31:57 ]:  I saw an average roundtrip time of 166.827070 ms, he saw 167.647724 ms
[ 10:32:05 ]:  I saw an average roundtrip time of 765.356593 ms, he saw 859.600923 ms
[ 10:32:13 ]:  I saw an average roundtrip time of 357.522686 ms, he saw 339.648654 ms
[ 10:32:24 ]:  I saw an average roundtrip time of 1115.639593 ms, he saw 1060.574401 ms
[ 10:32:39 ]:  I saw an average roundtrip time of 175.845995 ms, he saw 171.112166 ms
[ 10:32:44 ]:  I saw an average roundtrip time of 47.262925 ms, he saw 41.987869 ms
[ 10:32:52 ]:  I saw an average roundtrip time of 74.524443 ms, he saw 78.868198 ms
[ 10:33:47 ]:  I saw an average roundtrip time of 20.943917 ms, he saw 21.217377 ms
[ 10:33:52 ]:  I saw an average roundtrip time of 28.944821 ms, he saw 29.303144 ms
[ 10:34:06 ]:  I saw an average roundtrip time of 25.581624 ms, he saw 25.439416 ms
[ 10:34:13 ]:  I saw an average roundtrip time of 25.565568 ms, he saw 25.655267 ms
[ 10:34:18 ]:  I saw an average roundtrip time of 38.609394 ms, he saw 37.462835 ms

Một lát sau:

[ 10:38:11 ]:  I saw an average roundtrip time of 40.037623 ms, he saw 43.367524 ms
[ 10:38:21 ]:  I saw an average roundtrip time of 121.222703 ms, he saw 118.855264 ms
[ 10:38:28 ]:  I saw an average roundtrip time of 726.391897 ms, he saw 685.742454 ms
[ 10:38:33 ]:  I saw an average roundtrip time of 60.251207 ms, he saw 57.974503 ms
[ 10:38:42 ]:  I saw an average roundtrip time of 1133.909392 ms, he saw 1124.404501 ms     

Vì vậy, nó lẻ tẻ và đi trong sóng. Tôi đoán tôi sẽ phải thử một số gợi ý trong các bài viết khác như giảm tốc độ gửi gói của tôi.