Würde das Senden von Lots eine kleine Pakete von UDP mehr Ressourcen (CPU, Komprimierung von Zlib, etc ...). Ich lese here, dass das Senden eines großen Pakets von ~ 65kBYTEs durch UDP wahrscheinlich fehlschlagen würde, so dass ich dachte, dass das Senden von vielen kleineren Paketen öfter gelingen würde, aber dann kommt der Rechenaufwand der Verwendung von mehr Verarbeitungsleistung (oder zumindest das ist was ich nehme an). Die Frage ist im Grunde genommen; Was ist das beste Szenario, um die maximal erfolgreichen Pakete zu senden und die Berechnung auf ein Minimum zu reduzieren? Gibt es eine bestimmte Größe, die die meiste Zeit funktioniert? Ich benutze Erlang für einen Server und Enet für den Client (in C++ geschrieben). Mit Zlib-Komprimierung auch und ich sende die gleichen Pakete an jeden Client (Broadcasting ist der Begriff, denke ich).Die zuverlässigste und effizienteste UDP-Paketgröße?
Antwort
Die maximale Größe von UDP payload fest, dass die meiste Zeit, nicht IP-Fragmentierung verursachen ist
MTU size of the host handling the PDU (most of the case it will be 1500) -
size of the IP header (20 bytes) -
size of UDP header (8 bytes)
1500 MTU - 20 IP hdr - 8 UDP hdr = 1472 bytes
@EJP über 534 Bytes gesprochen, aber ich würde es 508 beheben. Dies ist die Anzahl der Bytes, die SICHER nicht Fragmentierung führen, da die minimale MTU-Größe, die eine Host- und IP header max size ist eingestellt werden kann 60 bytes(508 = 576 MTU - 60 IP - 8 UDP) sein
Übrigens würde ich versuchen, mit 1472 Bytes gehen, weil 1500 ist ein Standard-genug Wert.
Verwenden Sie 1492 anstelle von 1500 für die Berechnung, wenn Sie eine PPPoE-Verbindung durchlaufen.
534 Bytes. Dies muss ohne Fragmentierung übertragen werden. Es kann natürlich immer noch ganz verloren gehen. Die Overheads aufgrund der erneuten Übertragung von verlorenen Paketen und die Netzwerk-Gemeinkosten selbst sind mehrere Größenordnungen signifikanter als irgendwelche CPU-Kosten.
Ich frage mich, was der direkte Effekt auf Paket der Fragmentierung ist. In meiner Anwendung, wenn ich von 508 zu 509 gehe, scheint es, dass ein '\ 0' am Ende des zweiten Pakets angehängt wird. Ich frage mich, ob es von meiner speziellen Implementierung abhängt oder es eine Truly ist? –
@mavErick Die abschließende Null kommt von Ihrem Code oder wird von ihm nicht korrekt beobachtet. UDP tut das nicht. – EJP
Sie verwenden wahrscheinlich das falsche Protokoll. UDP ist fast immer eine schlechte Wahl für Daten, die Sie für die Übertragung interessieren. Sie wickeln Schichtungssequenzierung, Wiederholungsversuche und Integritätslogik darauf auf, und dann haben Sie TCP.
"Wiederholen"? Aber ich dachte, das wäre was ... über das Zurücksenden von Paketen, um die Arbeit zu erledigen. Ich mache das für ein Online-Spiel, so dass TCP wahrscheinlich zu langsam ist, oder das ist, was alle anderen sagen. – pandoragami
"Jeder" ist oft falsch. Wenn Sie befürchten, dass Daten nicht ankommen, brauchen Sie TCP. –
Ok, was wäre die effizienteste TCP-Paketgröße unter Berücksichtigung von Nagel, etc .. – pandoragami
Würde das Senden von Lots eine kleine Pakete von UDP mehr Ressourcen nehmen?
Ja, würde es definitiv! Ich habe gerade ein Experiment mit einer Streaming-App gemacht. Die App sendet sekundengenau 2000 Datenrahmen. Die Datennutzlast für jeden Rahmen beträgt 24 Bytes. Ich habe UDP mit sendto() verwendet, um diese Daten an eine Listener-App auf einem anderen Knoten zu senden.
Was ich fand, war interessant. Dieses Maß an Aktivität hat meine sendende CPU in die Knie gezwungen! Ich ging von ungefähr 64% freie CPU-Zeit, um ungefähr 5% zu haben! Das war katastrophal für meine Bewerbung, also musste ich das beheben. Ich entschied mich, mit Variationen zu experimentieren.
Zuerst habe ich einfach den sendto() Anruf auskommentiert, um zu sehen, wie der Overhead der Paketbaugruppe aussah. Etwa 1% Treffer bei der CPU-Zeit. Nicht schlecht. OK ... muss der sendto() Aufruf sein!
Dann habe ich einen schnellen Fakeout-Test gemacht ...Ich rief die sendto() API nur einmal alle 10 Iterationen, aber ich füllte den Datensatz auf das 10-fache seiner vorherigen Länge, um den Effekt der Zusammenstellung einer Sammlung kleinerer Datensätze in eine größere, seltener gesendet zu simulieren. Die Ergebnisse waren recht zufriedenstellend: 7% CPU-Treffer im Vergleich zu 59% zuvor. Es scheint, dass zumindest auf meinem * NIX-artigen System der Vorgang des Sendens eines Pakets nur wegen des Aufwands teuer ist, den Anruf zu tätigen.
Nur für den Fall, dass jemand bezweifelt, ob der Test ordnungsgemäß funktioniert, verifizierte ich alle Ergebnisse mit Wireshark Beobachtung der tatsächlichen UDP-Übertragungen, um zu bestätigen, dass alles funktionierte, wie es sollte.
Fazit: es verbraucht viel weniger CPU-Zeit, um größere Pakete seltener zu senden, dann wird die gleiche Menge an Daten in Form von kleineren Paketen häufiger gesendet. Zugegeben, ich weiß nicht, was passiert, wenn UDP anfängt, Ihr übergroßes UDP-Datagramm zu fragmentieren ... Ich meine, ich weiß nicht, wie viel CPU-Overhead dazu beiträgt. Ich werde versuchen, es herauszufinden (ich möchte es selbst wissen) und diese Antwort aktualisieren.
Die minimale * IP * MTU ist 576. Es enthält keine Ethernet-Header, so dass 548 tatsächlich geben würde. – EJP
Sie haben Recht ... Ich korrigierte die Berechnung unter Berücksichtigung auch, dass IP-Header maximale Größe 60 Bytes erreichen kann –
508 ist genial! –