UDP, wie funktionierts?
-
mit ist kein besserer titel eingefallen und es ist auch blöd zu erklären, es geht darum, wenn ich eine udp nachricht verschicke, ist dann garantiert, dass die 65.535 bytes nutzdaten auch so ankommen wie abgeschickt oder kann das iwie gesplittet werden? kommen die nutzdaten in einem stück an?
bin udp noob, einfache sprache erwünscht
-
UDP garantiert nur, dass Pakete ganz oder garnicht ankommen. Das ist alles. Ob die Pakete ankommen oder nicht, interessiert UDP nicht.
Wie gross ein Paket sein kann, haengt von der verwendeten Netzwerkstruktur ab.
Deshalb die Gretchen Frage: was willst du denn erreichen?
-
Shade Of Mine schrieb:
UDP garantiert nur, dass Pakete ganz oder garnicht ankommen. Das ist alles. Ob die Pakete ankommen oder nicht, interessiert UDP nicht.
okay, hab ich verstanden.
Shade Of Mine schrieb:
Wie gross ein Paket sein kann, haengt von der verwendeten Netzwerkstruktur ab.
hm? also geht das dann in die richtung, dass das 'große' udp paket in kleine ip pakete verpackt wird, durch die leitung geht und beim empfänger zusammengebaut wird? bei einem nonblocking socket, kann da auch ein 'halbes' udp paket ankommen, oder blockiert der erst nach einem 'ganzen' paket?
Shade Of Mine schrieb:
Deshalb die Gretchen Frage: was willst du denn erreichen?
meinen horizont von tcp auf udp erweitern
-
bei einem nonblocking socket, kann da auch ein 'halbes' udp paket ankommen, oder blockiert der erst nach einem 'ganzen' paket?
Das hat nichts mit Non-Blocking etc. zu tun.
KingKarl schrieb:
meinen horizont von tcp auf udp erweitern
Den Wikipedia-Artikel hast du nicht gefunden?
Die maximale Größe eines UDP-Datagrammes beträgt 65.535 Bytes, da das Length-Feld des UDP-Headers 16 Bit lang ist und die größte mit 16 Bit darstellbare Zahl gerade 65.535 ist. Solch große Segmente werden jedoch von IP fragmentiert übertragen.
Etwas mehr Eigeninitiative!
-
Also aus Sicht von UDP kommen die Pakete als ganzes an. Wie ein UDP-Paket genau übertragen wird interessiert UDP nicht, dafür ist erstmal IP verantwortlich und IP "verlässt" sich dann wieder auf darunter liegende Schichten.
IP kann Pakete, also auch UDP-Pakete zerstückeln, beim Empfänger werden sie dann wieder zusammengeflickt, sofern alle Fragmente ankommen. IP garantiert nicht, dass die Daten fehlerfrei übertragen werden. Im UDP-Header steht aber für gewöhnlich eine Prüfsumme, so dass Fehlerhafte Pakete meistens erkannt werden können.
-
danke!
-
Wobei zur Prüfsumme noch zu sagen ist: die Prüfsumme von TCP und UDP ist so richtig mies. Dass die Kommunikation übers Internet so gut funktioniert, liegt nur daran, dass die Schichten unterhalb von IP schon sehr gut dafür sorgen dass keine Fehler passieren.
-
Vllt. solltest du dich zunächst ein wenig mit dem Netzwerkstack befassen. Paar RFCs lesen und so...
-
hustbaer schrieb:
die Prüfsumme von TCP und UDP ist so richtig mies.
Kannst du Näheres dazu sagen? Würd mich mal interessieren...
-
Hi schrieb:
hustbaer schrieb:
die Prüfsumme von TCP und UDP ist so richtig mies.
Kannst du Näheres dazu sagen? Würd mich mal interessieren...
Er spielt wohl auf END-TO-END ARGUMENTS IN SYSTEM DESIGN an.
-
Ich meinte einfach dass die TCP Checksumme eben mies ist: eine 16 Bit additive Checksumme ist halt nicht wirklich stark, damit findet man viele sehr einfache Fehler nicht, d.h. es kann leicht vorkommen dass Fehler unerkannt bleiben.
Wäre das der einzige Schutz gegen Übertragungsfehler, dann würde es sehr oft passieren dass Daten die man über TCP/IP überträgt "kaputt" ankommen.
In dem verlinkten Paper sind dann noch ein paar weitere Punkte angeführt, die man auch nicht ausser Acht lassen sollte. Wie z.B. dass die ganzen Prüfsummen der Schichten unterhalb von TCP nix bringen, wenn ein Vorfall in einem Switch/Router die Daten verändert.
-
Bau halt dein eigenes Layer-4 Protokoll, Meister hustbaer.
-
Hast du auch irgendwas sinnvolles beizutragen, Meister Sinnlos?
-
Du hast soeben den Begriff "Layer-4 Protokoll" gelernt, reicht das nicht?
-
314159265358979 schrieb:
Du hast soeben den Begriff "Layer-4 Protokoll" gelernt, reicht das nicht?
I used to be a coder like you, then I took an arrow in the keyboard.
-
Aus welchen Gründen hat man sich denn auf fehlererkennende Codes beschränkt? Geschwindigkeitsvorteile?
-
miso schrieb:
Aus welchen Gründen hat man sich denn auf fehlererkennende Codes beschränkt? Geschwindigkeitsvorteile?
soweit ich mich jetzt eingelesen hab, geht es darum, nach mögl. die bandbreite voll auszunutzen.
die frage, welche ich mir gerade stelle: wenn ich jetzt auf tcp/udp ein 'protokoll' aufbaue, brauch ich dann eine form von fehlererkennung oder reichen die methoden der unteren schichten? wenn ja, könntet ihr mir da tipps geben, welche gut sind? sollte ich eher sowas wie einen besseren hash (md5 oder sha256) oder 'reinrassig' (ldpc bzw. turbo-code) fehlererkennende verwenden
-
das ist aber unverschämt, mich erst verunsichern, und dann nichts mehr hören lassen
-
hustbaer ist doch nicht dein Bediensteter, komm klar.
Guck dir doch einfach mal die bestehenden Application Layer Protokolle an, die verlassen sich größtenteils auch auf die unteren Schichten. Insofern würde ich so etwas nicht ins Protokoll integrieren, es sei denn du hast eine Art live Stream bei dem es wirklich kritisch ist, dass Daten korrekt ankommen.
-
Bei TCP auch miese Checksums?
Aber...da soll doch die Datenintegrität garantiert sein!? Sprich... jedes Bit muss sitzen?!
