Jak uniknąć dławienia?

Piszę grę sieciową na iOS. Kiedy wysyłam pakiety z GKMatchSendDataReliable(który, jak zakładałem, to UDP z zapisanym własnym kodem odbioru pakietów) z prędkością 60 pakietów na sekundę (czyli 16 ms między sąsiednimi pakietami), średni czas pingowania gwałtownie się pogarsza: otworzyłem 7 meczów GameCenter poniżej (jeden po drugim) ) i po prostu wysłał „powódź” 100 pakietów (w tempie 60 pakietów na sekundę). Zmierzyłem średni czas podróży w obie strony, a oto wyniki:

[ 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

Po ostatnich 2 testach wyniki wynoszą około 1000 ms.

Wydawałoby się, że jestem dławiony, najprawdopodobniej przez mojego dostawcę usług internetowych. Ponieważ jest to gra na iOS, ludzie będą korzystać ze zwykłych połączeń domowych.

Kiedy zmieniłem szybkość wysyłania pakietów na 10-krotnie wolniejszą (czyli 1 pakiet co 160 ms), testy trwają znacznie dłużej, ale czasy rundy są niezmiennie niskie.

[21:31:27]: Widziałem średni czas w obie strony 55.289109 ms, widział 69.032727 ms

Wygląda więc na to, aby utrzymać małe opóźnienie połączenia (i nie zostać „ukaranym” przez ISP). Muszę zmniejszyć szybkość wysyłanych pakietów. Pamiętaj, że są to bardzo małe pakiety, na przykład maksymalnie 40 bajtów, ale wciąż jestem dławiony.

Szukam wskazówek, ile pakietów UDP mogę wysłać na sekundę, aby uniknąć ograniczenia przepustowości! Czy są jakieś ogólne wytyczne?

Nawet domowe gry akcji lub duże gry MMO nie działają z częstotliwością 60 Hz. Ponadto posiadanie naprawdę małych rozmiarów pakietów niekoniecznie jest świetną rzeczą, każdy z tych małych pakietów ma duży narzut po prostu wysyłając je.

Spróbuj strzelać do aktualizacji 10 Hz z interpolacją po stronie klienta. Zakładam, że interpolujesz już, ponieważ zawsze pojawią się opóźnienia ping.

Przeczytaj o rozmiarach MTU i wrzuć tam więcej informacji, aby objąć dłuższe ramy czasowe. Średni rozmiar pakietu w warstwie transportowej wyniesie około 1400, wszystko powyżej rozmiaru MTU podzieli Twoją wiadomość i spowoduje jeszcze większe obciążenie.

Najpierw musisz się upewnić, jak duże są wszystkie dane. Twój dostawca usług internetowych najprawdopodobniej będzie dbał o liczbę wysłanych bajtów, a nie o liczbę lub częstotliwość datagramów. Jeśli wysyłasz datagramy o maksymalnej wielkości (65507 oktetów ładunku) 60 razy na sekundę, wysyłasz około 30 Mb / s w górę. Nie każdy ma takie połączenie.

Pamiętaj, że nagłówek IP ma długość 20 oktetów, a nagłówek UDP ma długość 8 oktetów. To dodatkowe 28 oktetów, które wysyłasz dla każdego datagramu.

Jeśli nie maksymalizujesz połączenia, istnieje wiele miejsc, w których twoje pakiety mogą się opóźniać: mianowicie system operacyjny klienta, twoja brama (prawdopodobnie router bezprzewodowy lub modem kablowy), twój dostawca usług internetowych, dostawca usług internetowych drugiego użytkownika, inny serwer równorzędny gateway, między innymi system operacyjny drugiego użytkownika.

Jeśli jeszcze go nie używałeś , zalecamy skorzystanie z Wireshark , który jest niezwykle potężnym narzędziem do diagnozowania problemów z siecią. Pomyśl o tym jak o odpowiedniku debuggera, ale do pracy w sieci.

Istnieje kilka sposobów diagnozowania ruchu sieciowego za pomocą Wireshark:

• Używaj Wireshark na komputerze w tej samej sieci co urządzenie mobilne, z rozwiązanym hubem i ustawiając swoje urządzenie sieciowe jako rozwiązane

• Ustaw komputer jako bramę bezprzewodową i podłącz urządzenie mobilne do tej bramy, a następnie słuchaj za pomocą Wireshark na tym komputerze

• Uruchom Wireshark na tym samym komputerze co emulator

• Uruchom tcpdump na samym urządzeniu (łatwe w Androidzie, wymaga jailbreak na iOS), a następnie przeczytaj przechwycone dane w Wireshark

• Stwórz prosty program, który robi dokładnie to samo, ale działa na komputerze i użyj Wireshark.

• ... i wiele innych

Chcesz sprawdzić, które paczki są wysyłane i kiedy. Na przykład, jeśli opóźnienie wystąpi zanim zostaną wysłane, system operacyjny będzie dławiony; podczas gdy opóźnienie występuje nawet w wersji komputerowej tego samego programu, oznacza to, że gdzieś dławi cię sieć.

Zwykle, jeśli dławisz się przez sieć, powinieneś dostać datagramy ICMP typu 4, abyś mógł użyć ich do sprawdzenia, gdzie dokładnie dławisz się.

Podsumowując, istnieje wiele powodów, dla których twoje pakiety mogą się opóźniać, i dobrze byłoby dowiedzieć się, gdzie jest problem, zanim zaczniesz próbować go rozwiązać.

Wygląda na to, że jedno z moich założeń było błędne. Zgodnie z tym :

GKMatchSendData Tryb niewiarygodny, obraz do przesłania w tak zwanym UDP. GKMatchSendData Obraz trybu niezawodnego wysyłany przez TCP. Powinien to być zwykle GKMatchSendDataUnreliable.

Zmiana trybu wysyłania na rzeczywisty UDP (tj. GKMatchSendDataUnreliable) Wydaje się utrzymywać niskie prędkości ping przy 60 pakietach na sekundę. Wygląda na to, że po raz kolejny uderzyły mnie Nagles .

Nadal mam dziwne zachowanie (okresy z bardzo wysokimi czasami pingowania), ale nie jestem pewien głównej przyczyny (ISP lub przeciążenie sieci).

[ 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

Później:

[ 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     

Jest to więc sporadyczne i faluje. Chyba będę musiał wypróbować niektóre sugestie z innych postów, takie jak zmniejszenie szybkości wysyłania pakietów.