Я пишу сетевую игру для 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, чтобы вы могли использовать их для проверки того, где именно вас душат.
В заключение, существует много причин, по которым ваши пакеты могут задерживаться, и было бы разумно выяснить, где проблема, прежде чем вы начнете пытаться решить проблему.
источник
Похоже, одно из моих предположений было неверным. Согласно этому :
Изменение режима отправки на реальный UDP (т. Е.
GKMatchSendDataUnreliable), По- видимому, поддерживает низкие скорости пинга на уровне 60 пакетов в секунду. Похоже , я был поражен Nagles еще раз .Я все еще получаю странное поведение (периоды с очень высоким временем пинга), но я не уверен, что основная причина (интернет-провайдер или перегрузка сети).
Потом:
Так что это время от времени и идет волнами. Я предполагаю, что мне придется попробовать некоторые из предложений в других сообщениях, таких как снижение скорости отправки пакетов.
источник