Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Fragmentieren TCP/UDP Pakete?

  • 1
  • 2

Werbeanzeige

Sylence

Community-Fossil

  • »Sylence« ist der Autor dieses Themas

Beiträge: 1 663

Beruf: Softwareentwickler

  • Private Nachricht senden

1

10.04.2011, 20:57

Fragmentieren TCP/UDP Pakete?

Ich weiß nicht, ob ich zu dumm zum suchen bin, aber ich hab da mal ne frage:
Wenn ich Daten über TCP oder UDP sende, ist dann sichergestellt, dass die Daten an einem Stück beim gegenüber ankommen oder kann es passieren, dass die Daten aufgesplittet werden?
Das sie auf dem Weg vom Sender zum Empfänger gesplittet werden können ist mir klar, aber kommen die Daten aus appliaktionssicht immer an einem Stück an? Also bekomm ich mit recv() z.b immer die kompletten Daten?
Bei den paar kleinen Tests die ich gemacht hab, war das immer der Fall. Aber kann auch davon ausgehen, dass es immer der Fall ist?

TrommlBomml

Community-Fossil

Beiträge: 2 117

Wohnort: Berlin

Beruf: Software-Entwickler

  • Private Nachricht senden

2

10.04.2011, 21:03

Ob und wie Deine Netzwerkverbindung mit Stücken umgeht oder nicht, hat recht wenig mit UDP/TCP zu tun, das entscheidet schicht2/3. du arbeitest aber mit sockets auf layer 4. ob daten in stücken oder ganz ankommen, hängt davon ab, wie viel deine netzkarte im puffer halten kann bzw. was der treiber damit macht. grundsätzlich solltest du nicht davon ausgehen, dass alles an einem stück reinkommt ;)

idontknow

unregistriert

3

10.04.2011, 21:06

Meines wissens nach nicht. Alles was ich sage kann aber fehlerhaft sein weil ich auch nur ganz grob damit rumgespielt habe (TCP).
Also TCP garantiert dir, dass alle Päkchen ankommen und in der richtigen Reihenfolge. Aber sie können wie du bereits festgestellt hast gesplittet werden, sprich bei einem recv kommt nicht alles an, ist aber auch relativ logisch weil recv ja eine Länge als Parameter erwartet. Sprich du musst die Pakete einfach aneinander dranhängen.

Bei deinen Tests hast du vermutlich nur wenige Strings versende und vermutlich auch über localhost mit 2 Clients auf einem PC? So hab ichs mal gemacht und bei den 20Bytes die du da versendest machts schon Sinn dass die in einem Wisch durchkommen :P. Aber kannst ja mal versuchen ein Bild oder ein Film zu verschicken^^ Spätestens dann kannst du dir vom Resultat ausgehend sicher sein :).

Sylence

Community-Fossil

  • »Sylence« ist der Autor dieses Themas

Beiträge: 1 663

Beruf: Softwareentwickler

  • Private Nachricht senden

4

10.04.2011, 21:11

Alles klar. Dankeschön :)

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

5

10.04.2011, 21:13

TCP ist ein streambasiertes Protokoll (Transmission Control Protocol). D.h. auf TCP Ebene gibt es sowas wie Pakete nicht, da gibts nur einen Datenstrom in den du auf der einen Seite was reinstopfst und aus dem auf der andren Seite was rauskommt. TCP garantiert dir dass die Daten auf der andren Seite genau in der Reihenfolge rauskommen in der sie auf der andren Seite reingestopft wurden. Aber niemand sagt wann wieviel rauskommt. Wenn du auf der einen Seite 1024 Bytes mit send() reinstopfst kanns sein dass auf der andren alle 1024 in einem recv() rauskommen oder aber dass beim ersten recv() 200 kommen und beim nächsten recv() 824 oder was auch immer. TCP kümmert sich dabei darum deinen Datenstrom korrekt und möglichst effizient zu übertragen, was so Dinge umfasst wie eben Fragmentierung in Pakete, zusammensetzen der Fragmente, Windowing, verlorene Pakete detektieren und neu Senden, etc.
UDP dagegen ist paketorientiert (User Datagram Protocol). Mit UDP schickst du einfach ein Paket an einen Empfänger, das wars, ob wann da was ankommt kümmert UDP nicht.
m4studios

Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von »dot« (10.04.2011, 21:24)

Helmut

5x Contest-Sieger

Beiträge: 692

Wohnort: Bielefeld

  • Private Nachricht senden

6

10.04.2011, 22:03

Bei UDP ist allerdings auch garantiert, dass alles, was in ein send gesteckt wird, auf der anderen Seite in der richtigen Reihenfolge ankommt.
Sei stets geduldig gegenüber Leuten, die nicht mit dir übereinstimmen. Sie haben ein Recht auf ihren Standpunkt - trotz ihrer lächerlichen Meinung. (F. Hollaender)

Union_Freedom

Treue Seele

Beiträge: 156

Wohnort: Nähe Hannover

Beruf: Student

  • Private Nachricht senden

7

10.04.2011, 23:01

Nicht zwingend. Wenn bei TCP ein Paket verloren geht, schickt er ein neues. Also wird automatisch immer eine Rückabfrage gestartet. Wenn dir bei UDP ein Paket verloren geht, sind die Daten damit automatisch nicht mehr in der richtigen Reihenfolge, also du musst die Daten identifizieren können. (Wobei Reihenfolge jetzt auch so eine Interpretationssache ist. Wenn Daten nicht 100% am Stück liegen, ist für mich die Reihenfolge unterbrochen)

Anwendungsbereich ist halt interessant. TCP ist sicherlich langsamer dafür sicherer.(Was Datenverlust betrifft) UDP eignet sich super fürs senden von Daten, wo es nicht schlimm ist, wenn mal 10% der Daten fehlen. (Positionssynchronisation oder ähnliches)

mfg
Union_Freedom
Coder bei: http://crushing-gods.de/ (Folgt uns)
Erste Eindrücke zu Crushing Gods Link

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

8

10.04.2011, 23:15

Zitat von »Union_Freedom«

Nicht zwingend. Wenn bei TCP ein Paket verloren geht, schickt er ein neues. Also wird automatisch immer eine Rückabfrage gestartet.

Er meint damit dass ein UDP Paket auch größer sein kann als die MTU, die Fragmentierung wird dabei dann von IP erledigt. D.h. alles was du an ein sendto() übergibst kommt bei UDP entweder ganz oder ganz nicht an aber sicher nicht nur teilweise.

Zitat von »Union_Freedom«

Wenn dir bei UDP ein Paket verloren geht, sind die Daten damit automatisch nicht mehr in der richtigen Reihenfolge, also du musst die Daten identifizieren können. (Wobei Reihenfolge jetzt auch so eine Interpretationssache ist. Wenn Daten nicht 100% am Stück liegen, ist für mich die Reihenfolge unterbrochen)

Pakete können unterschiedliche Routen durch ein Netzwerk nehmen sodass es durchaus auch möglich ist dass ein später abgesendetes Paket früher beim Empfänger ankommt als ein davor verschicktes.

Zitat von »Union_Freedom«

Anwendungsbereich ist halt interessant. TCP ist sicherlich langsamer dafür sicherer.(Was Datenverlust betrifft) UDP eignet sich super fürs senden von Daten, wo es nicht schlimm ist, wenn mal 10% der Daten fehlen. (Positionssynchronisation oder ähnliches)

Genau, es kommt auf die Anwendung an. TCP und UDP sind grundverschieden und stehen daher erstmal nicht wirklich in Konkurrenz zueinander. Was die Performance angeht ist die Frage: Langsamer im Vergleich zu was? Eine auf UDP basierende Eigenimplementierung eines Streamprotokolls wird wahrscheinlich langsamer und sehr viel Fehleranfälliger sein als TCP.
m4studios

Helmut

5x Contest-Sieger

Beiträge: 692

Wohnort: Bielefeld

  • Private Nachricht senden

9

10.04.2011, 23:15

@Union_Freedom
Naja, du hast mich falsch verstanden. Wenn man bei UDP send("Hello"), send("World") macht, kommt auf der anderen Seite vielleicht "WorldHello" an, aber nicht lloHeWorld. Sonst wäre UDP praktisch unbrauchbar.

Ciao
Helmut
Sei stets geduldig gegenüber Leuten, die nicht mit dir übereinstimmen. Sie haben ein Recht auf ihren Standpunkt - trotz ihrer lächerlichen Meinung. (F. Hollaender)

Union_Freedom

Treue Seele

Beiträge: 156

Wohnort: Nähe Hannover

Beruf: Student

  • Private Nachricht senden

10

10.04.2011, 23:19

Ah okay. Danke für die Verbesserungen :)

Ja, da habe ich dich wohl missverstanden.

mfg
Union_Freedom
Coder bei: http://crushing-gods.de/ (Folgt uns)
Erste Eindrücke zu Crushing Gods Link

Werbeanzeige

  • 1
  • 2

Ähnliche Themen