Как избежать удушения?

Я пишу сетевую игру для 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

После двух последних испытаний результат составляет около 1000 мс.

Казалось бы, меня душит, скорее всего, мой провайдер. Поскольку это игра для iOS, люди будут использовать обычные бытовые подключения.

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

[21:31:27]: я видел среднее время туда и обратно 55,289109 мс, он видел 69,032727 мс

Таким образом, похоже, чтобы поддерживать низкую задержку на соединении (и не быть «наказанным» провайдерами), я должен уменьшить скорость отправки пакетов. Имейте в виду, что это очень маленькие пакеты, например, максимум 40 байт, но я все еще ограничен.

Я ищу рекомендации о том, сколько пакетов UDP я могу отправить в секунду, чтобы избежать удушения! Есть ли где-нибудь общие рекомендации?

Даже домашние ПК, основанные на экшене, или крупные ММО не запускают свои пакеты с частотой 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 mode, изображение для передачи в так называемом UDP. GKMatchSendDataReliable mode - изображение, отправляемое по TCP. Должно ли это быть GKMatchSendDataUnreliable обычно.

Изменение режима отправки на реальный UDP (т. Е. GKMatchSendDataUnreliable), По- видимому, поддерживает низкие скорости пинга на уровне 60 пакетов в секунду. Похоже , я был поражен Nagles еще раз .

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

[ 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     

Так что это время от времени и идет волнами. Я предполагаю, что мне придется попробовать некоторые из предложений в других сообщениях, таких как снижение скорости отправки пакетов.