Multithreading/tasking Frage
-
Ich glaube, wenn kein recv gemacht wurde, bevor ein udp-Paket ankommt, wird es verworfen. Der Sender sendet fuer gewoehnlich nur einmal.
-
knivil schrieb:
Ich glaube, wenn kein recv gemacht wurde, bevor ein udp-Paket ankommt, wird es verworfen. Der Sender sendet fuer gewoehnlich nur einmal.
Das wäre ziemlich doof, da man dann mit einem single-threaded Empfängerprogramm schnell vom Kernel fabrizierten Packet-Loss hätte, selbst wenn nur ein Sender Daten sendet und die Netzwerkverbindung zwischen Sender und Empfänger super-stabil ist.
-
Vielleicht wird es nicht verworfen, wenn der interne Buffer leer ist. Aber das weiss ich vorher nicht. Eine Sicherheit gibt es nicht. Ich lasse mich aber gern eines besseren belehren.
-
knivil schrieb:
Vielleicht wird es nicht verworfen, wenn der interne Buffer leer ist. Aber das weiss ich vorher nicht. Eine Sicherheit gibt es nicht. Ich lasse mich aber gern eines besseren belehren.
Das Paket wird erst dann verworfen wenn der interne (Kernel) Buffer voll ist. Was idR nicht vorkommt. TCP ist schon etwas sehr robustes
Sofern deine Anwendung korrekt arbeitet und es keine angriffe auf den Server gibt, wird das nicht passieren.
-
Shade Of Mine schrieb:
Was idR nicht vorkommt. TCP ist schon etwas sehr robustes
Na is ja super, vor allem da es hier um UDP geht.
-
hustbaer schrieb:
Shade Of Mine schrieb:
Was idR nicht vorkommt. TCP ist schon etwas sehr robustes
Na is ja super, vor allem da es hier um UDP geht.
OK, dann ersetze TCP durch IP
TCP und UDP sind die selbe Technik, das Protokoll unterscheidet sich nur geringfügig.
-
Shade Of Mine schrieb:
hustbaer schrieb:
Shade Of Mine schrieb:
Was idR nicht vorkommt. TCP ist schon etwas sehr robustes
Na is ja super, vor allem da es hier um UDP geht.
OK, dann ersetze TCP durch IP
TCP und UDP sind die selbe Technik, das Protokoll unterscheidet sich nur geringfügig.
Nö. Was das angeht gibt es einen grundlegenden Unterschied: Bei TCP gibt es per Connection End-to-End Flow-Control über das Receive-Window.
Der Sender weiss immer wie viel er noch senden "darf".Bei UDP hast du soweit ich weiss nichts in dieser Richtung. Der Sender sendet sobald von seiner Seite aus alles klar ist.
-
hustbaer schrieb:
Nö. Was das angeht gibt es einen grundlegenden Unterschied: Bei TCP gibt es per Connection End-to-End Flow-Control über das Receive-Window.
Der Sender weiss immer wie viel er noch senden "darf".Bei UDP hast du soweit ich weiss nichts in dieser Richtung. Der Sender sendet sobald von seiner Seite aus alles klar ist.
Das ist ein Detail des Protokolls.
UDP ist für niedrige Latenz auf kosten der sicherheit (im Sinne wann wo und wie Pakete ankommen) während TCP für hohe sicherheit bei hoher Latenz ausgelegt ist.Die IP Pakete die ankommen sind prinzipiell fast identisch. TCP Pakete haben lediglich eine Sequenznummer und Acknummer dabei - die UDP einfach nicht braucht.
Aber wie gesagt: ersetz in meinem vorherigen Post einfach TCP durch IP und fertig.
-
Shade Of Mine schrieb:
Aber wie gesagt: ersetz in meinem vorherigen Post einfach TCP durch IP und fertig.
Dann ist sie aber Unsinn.
-
hustbaer schrieb:
Shade Of Mine schrieb:
Aber wie gesagt: ersetz in meinem vorherigen Post einfach TCP durch IP und fertig.
Dann ist sie aber Unsinn.
Wieso?
Willst du lieber ein "Kernprotokolle der IP Suite" dort stehen haben?
-
Shade Of Mine schrieb:
Das Paket wird erst dann verworfen wenn der interne (Kernel) Buffer voll ist. Was idR nicht vorkommt.
TCPUDP ist schon etwas sehr robustesSofern deine Anwendung korrekt arbeitet und es keine angriffe auf den Server gibt, wird das nicht passieren.
Wenn die Anwendung einfach zu langsam beim Abholen der Pakete ist, wird der Puffer des IP Stacks sicher voll, und es werden sicher Pakete verworfen.
Im Gegensatz zu TCP eben, wo das normalerweise über die Receive-Window Size geregelt wird.
