Wie vermeide ich Drosselung?

Ich schreibe ein vernetztes iOS-Spiel. Beim Senden von Paketen mit GKMatchSendDataReliable(von denen ich annahm, dass es sich um UDP mit einem eigenen geschriebenen Paketempfangscode handelt) mit 60 Paketen pro Sekunde (also 16 ms zwischen benachbarten Paketen) verschlechtern sich die durchschnittlichen Ping-Zeiten schnell: Ich habe unten 7 GameCenter-Übereinstimmungen geöffnet (nacheinander) ) und schickte einfach eine "Flut" von 100 Paketen (mit einer Rate von 60 Paketen pro Sekunde). Ich habe die durchschnittliche Hin- und Rückfahrt gemessen und dies sind die Ergebnisse:

[ 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

Nach den letzten 2 Tests liegen die Ergebnisse bei ca. 1000 ms.

Es scheint, dass ich gedrosselt werde, höchstwahrscheinlich von meinem ISP. Da es sich um ein iOS-Spiel handelt, werden die Benutzer regelmäßig Verbindungen zu Wohngebieten verwenden.

Wenn ich die Paketsenderate auf 10-mal langsamer geändert habe (also 1 Paket alle 160 ms), dauern die Tests viel länger, aber die Roundtrip-Zeiten bleiben konstant niedrig.

[21:31:27]: Ich habe eine durchschnittliche Hin- und Rückfahrtzeit von 55,289109 ms gesehen, er hat 69,032727 ms gesehen

Es sieht also so aus, als würde die Latenz bei der Verbindung gering gehalten (und nicht von ISPs "bestraft" werden). Ich muss die Rate der von mir gesendeten Pakete reduzieren. Denken Sie daran, dass dies sehr kleine Pakete sind, wie maximal 40 Bytes, aber ich werde immer noch gedrosselt.

Ich suche nach Richtlinien, wie viele UDP-Pakete ich pro Sekunde senden kann, um nicht gedrosselt zu werden! Gibt es irgendwo allgemeine Richtlinien?

Nicht einmal Heim-PC-basierte Action-Spiele oder große MMOs führen ihre Pakete mit 60 Hz aus. Außerdem ist es nicht unbedingt eine großartige Sache, wirklich kleine Paketgrößen zu haben. Jedes dieser winzigen Pakete hat einen großen Aufwand, wenn es nur versendet wird.

Versuchen Sie, 10-Hz-Updates mit clientseitiger Interpolation aufzunehmen. Ich gehe davon aus, dass Sie bereits interpolieren, da es immer zu Ping-Verzögerungen kommt.

Informieren Sie sich über die MTU-Größen und geben Sie weitere Informationen ein, um den längeren Zeitraum abzudecken. Eine durchschnittliche Paketgröße auf der Transportschicht beträgt ungefähr 1400. Alles, was über der MTU-Größe liegt, teilt Ihre Nachricht auf und verursacht noch mehr Overhead.

Zunächst müssen Sie sicherstellen, wie groß die gesamten Daten sind. Ihr ISP kümmert sich höchstwahrscheinlich um die tatsächlich gesendeten Bytes, nicht um die Anzahl oder Häufigkeit der Datagramme. Wenn Sie 60-mal pro Sekunde Datagramme mit maximaler Größe (65507 Nutzlast-Oktekte) senden, senden Sie etwa 30 Mbit / s stromaufwärts. Nicht jeder hat eine solche Verbindung.

Denken Sie daran, dass der IP-Header 20 Oktette und der UDP-Header 8 Oktette lang ist. Das sind zusätzliche 28 Oktette, die Sie für jedes Datagramm senden.

Wenn Sie Ihre Verbindung nicht voll ausschöpfen, kann es an vielen Stellen zu Verzögerungen bei Ihren Paketen kommen: dem Betriebssystem des Clients, Ihrem Gateway (wahrscheinlich einem WLAN-Router oder Kabelmodem), Ihrem ISP, dem ISP des anderen Peers und dem anderen Peer Gateway, unter anderem das Betriebssystem des anderen Peers.

Falls Sie es noch nicht verwendet haben, empfehle ich die Verwendung von Wireshark , einem äußerst leistungsstarken Tool zur Diagnose von Netzwerkproblemen. Betrachten Sie es als das Äquivalent eines Debuggers, aber für die Vernetzung.

Es gibt verschiedene Möglichkeiten, den Netzwerkverkehr mit Wireshark zu diagnostizieren:

• Verwenden Sie Wireshark in einem PC im selben Netzwerk wie das mobile Gerät mit einem promiskuitiven Hub und stellen Sie Ihr Netzwerkgerät als promiskuitiv ein

• Stellen Sie einen PC als drahtloses Gateway ein und verbinden Sie Ihr mobiles Gerät mit diesem Gateway. Hören Sie dann mit Wireshark auf diesem PC

• Führen Sie Wireshark auf demselben Computer wie ein Emulator aus

• Führen Sie tcpdump im Gerät selbst aus (einfach für Android, erfordert Jailbreak unter iOS) und lesen Sie dann die erfassten Daten auf Wireshark

• Erstellen Sie ein einfaches Programm, das genau das Gleiche tut, aber auf einem PC funktioniert, und verwenden Sie dort Wireshark.

• ... und viele andere

Sie möchten überprüfen, welche Pakete wann gesendet werden. Wenn die Verzögerung beispielsweise auftritt, bevor sie gesendet werden, werden Sie vom Betriebssystem gedrosselt. Wenn Sie die Verzögerung sogar auf einer Desktop-Version desselben Programms erhalten, bedeutet dies, dass Sie irgendwo vom Netzwerk gedrosselt werden.

Wenn Sie vom Netzwerk gedrosselt werden, sollten Sie normalerweise ICMP-Datagramme vom Typ 4 erhalten, damit Sie anhand dieser Daten überprüfen können, wo genau Sie gedrosselt werden.

Zusammenfassend lässt sich sagen, dass es viele Gründe gibt, warum sich Ihre Pakete verzögern können. Es ist ratsam, herauszufinden, wo sich das Problem befindet, bevor Sie versuchen, das Problem zu lösen.

Es scheint, dass eine meiner Annahmen falsch war. Nach dieser :

GKMatchSendDataUnreliable mode, das Bild, das im sogenannten UDP übertragen werden soll. Von TCP gesendetes Bild im GKMatchSendDataReliable-Modus. Sollte es normalerweise ein GKMatchSendDataUnreliable sein.

Das Ändern des Sendemodus auf echtes UDP (dh GKMatchSendDataUnreliable) scheint niedrige Ping-Raten bei 60 Paketen pro Sekunde aufrechtzuerhalten. Es sieht aus wie ich habe durch Nagles geschlagen worden noch einmal .

Ich bekomme immer noch seltsames Verhalten (Perioden mit sehr hohen Ping-Zeiten), bin mir aber nicht sicher, warum dies der Grund ist (ISP oder Netzwerküberlastung).

[ 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

Später:

[ 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     

Es ist also sporadisch und geht in Wellen. Ich denke, ich muss einige der Vorschläge in den anderen Posts ausprobieren, z. B. die Reduzierung meiner Paketsenderate.