Як уникнути заїдання?

Я пишу мережеву гру для iOS. Під час надсилання пакетів GKMatchSendDataReliable(з якими я припускав, що був написаний UDP з власним кодом прийому пакетів) зі швидкістю 60 пакетів в секунду (тобто 16 мс між сусідніми пакетами), середні пінг-часи швидко погіршуються: я відкрив 7 ігор GameCenter нижче (один за одним ) і просто надіслали «повінь» у 100 пакетів (зі швидкістю 60 пакетів в секунду). Я вимірював середній час в обидва кінці, і ось такі результати:

[ 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

Після останніх 2 тестів результати становлять близько 1000 мс.

Здавалося б, мене пригнічує, швидше за все, мій провайдер. Оскільки це гра для iOS, люди використовуватимуть звичайні житлові з'єднання.

Коли я змінив швидкість надсилання пакетів на 10 разів повільніше (тому 1 пакет кожні 160 мс), тести забирають набагато довше, але час у зворотній бік залишається незмінно низьким.

[21:31:27]: я бачив середній час в обидва кінці 55,289109 мс, він бачив 69,032727 мс

Отже, схоже, щоб утримувати низьку затримку на з'єднанні (і не бути «покараним» провайдерами) я повинен зменшити швидкість передачі пакетів. Майте на увазі, що це дуже маленькі пакети, максимум 40 байт, але я все ще перебуваю на затисканні.

Я шукаю вказівки щодо того, скільки пакетів UDP я можу надсилати за секунду, щоб уникнути затримки! Чи є десь загальні вказівки?

Навіть екшн-ігри на базі домашніх ПК або великі MMO не працюють за допомогою пакетів на 60 Гц. Плюс мати справді невеликі розміри пакетів - це не обов'язково чудова річ, кожен з цих крихітних пакетів має великі накладні витрати, щойно надсилають його.

Спробуйте знімати оновлення на 10 Гц за допомогою певної інтерполяції на стороні клієнта. Я припускаю, що ви вже інтерполюєте, оскільки завжди буде пінг затримок.

Прочитайте розміри MTU та додайте більше інформації туди, щоб охопити більш тривалі часові рамки. Середній розмір пакету на транспортному шарі становитиме 1400 або близько того, все, що перевищує розмір MTU, розділить ваше повідомлення і спричинить ще більше накладних витрат.

По-перше, ви повинні переконатися, наскільки великі цілі дані. Ваш Інтернет-провайдер, швидше за все, піклується про фактично надіслані байти, а не про кількість та частоту дейтаграм. Якщо ви надсилаєте дейтаграми максимального розміру (65507 октетів корисного навантаження) 60 разів на секунду, ви надсилаєте близько 30 Мб / с вище за течією. Не у всіх такий зв’язок.

Пам'ятайте, що заголовок IP - 20 октетів, а заголовок UDP - 8 октетів. Це додаткові 28 октетів, які ви надсилаєте для кожної дейтаграми.

Якщо ви не максимізуєте своє з'єднання, є багато місць, де ваші пакети можуть затримуватися: а саме клієнтська ОС, ваш шлюз (можливо, бездротовий маршрутизатор або кабельний модем), ваш Інтернет-провайдер, Інтернет-провайдер іншого однорангового партнера, інший одноранговий шлюз, ОС інших однолітків серед інших.

Якщо ви його ще не використовували, рекомендую використовувати Wireshark , який є надзвичайно потужним інструментом для діагностики проблем із мережею. Подумайте про це як еквівалент налагоджувача, але для мереж.

Існує кілька способів діагностування мережевого трафіку за допомогою Wireshark:

• Використовуйте Wireshark на ПК у тій самій мережі, що і мобільний пристрій, з розмитим концентратором і налаштуйте свій мережевий пристрій як розбірливий

• Встановіть ПК як бездротовий шлюз і підключіть свій мобільний пристрій до цього шлюзу, а потім слухайте за допомогою Wireshark на цьому ПК

• Запустіть Wireshark в тій же машині, що і емулятор

• Запустіть tcpdump на самому пристрої (легко на Android, вимагає джейлбрейка на iOS), а потім прочитайте захоплені дані на Wireshark

• Створіть просту програму, яка робить точно те саме, але вона працює на ПК, і використовуйте Wireshark там.

• ... та багато інших

Ви хочете перевірити, які пакунки надсилаються та коли. Наприклад, якщо затримка настає перед тим, як їх надсилати, вас запускає ОС; хоча якщо ви отримуєте затримку навіть у настільній версії тієї самої програми, це означає, що вас кудись затягує мережа.

Зазвичай, якщо вас заважає мережа, вам слід отримати дейтаграми типу ICMP типу 4, щоб ви могли використовувати їх, щоб перевірити, куди саме ви потрапляєте.

На закінчення, є багато причин, через які ваші пакунки можуть затримуватися, і було б розумно з’ясувати, де проблема, перш ніж ви почнете намагатися вирішити проблему.

Здається, одне з моїх припущень було неправильним. Відповідно до цього :

GKMatchSendDataUnreliable режимі, зображення, що передається в так званому UDP. Зображення режиму GKMatchSendDataReliable, надіслане TCP. Якщо це зазвичай GKMatchSendDataUnreliable, як правило.

Зміна режиму посилу реального UDP (тобто GKMatchSendDataUnreliable) , по- видимому, підтримувати низькі ціни дзвону в 60 пакетів в секунду. Схоже, мене ще раз вразив Наглес .

Я все ще отримую дивну поведінку (періоди з дуже високим часом пінгу), але я не впевнений у першопричині (ISP або перевантаженість мережі).

[ 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

Пізніше:

[ 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     

Тож воно спорадично і йде хвилями. Я думаю, що мені доведеться спробувати деякі пропозиції в інших публікаціях, таких як зниження моєї швидкості відправки пакетів.