Zusammenhang Fragmentierung, max. Datagrammgröße und Sockets

[Alexander I. (daedalus)]

Hallo,

ich habe eine grundsätzliche Verständnisfrage zum Thema Fragmentierung 
(Beispiel TCP/IP):

Aus Applikationssicht kommuniziere ich ja (im einfachsten Fall) per 
BsdSockets. Wenn ich jetzt also von Applikation A zu Applikation B sagen 
wir 50 MByte übertragen will, was passiert genau im Inneren? Kann ich 
einfach

//PSEUDO-Code
BsdSocket.Write(&Mein50MByteKlotz, sizeof(Mein50MByteKlotz));

machen oder muß ich irgendwas beachten?

Hintergrund der Frage ist: Ein TCP-Datagramm darf ja nicht größer als 
64KByte sein (13 Bit Fragment-Offset im IP-Header * 8 Bytes = 65536 
Bytes), denn sonst passt's nicht mehr in den IP-Header rein.

Wer zerhackt jetzt den großen Klotz in lauter 64k-Blöcke und setzt die 
am Ziel wieder zusammen? Erledigt das der BsdSocket? Oder muß sich da 
die Anwendung selbst drum kümmern und darf nur 64k-Blöcke an den 
BsdSocket weitergeben? Im Endeffekt wäre das ja dann eine 2-stufige 
Fragmentierung oder? Helft mir doch mal auf die Sprünge ...

Stein des Anstosses ist, dass ich gerade einen kleinen Protokollstack 
für ein Embedded-System entwerfe, möchte aber nicht näher darauf 
eingehen, geht ja nur um's Verständnis, denn es ist mein erster 
"größerer Protokollstack".

Vielen Dank vorab!

[Marc D. (cosinus)]

Die Application muss sich nicht um das Fragmentieren kuemmern. Das 
geschieht alles im Stack. Und bei TCP haben wir ja auch nicht wirklich 
einen grossen Klotz sondern das ist ein Stream.

[Peter (Gast)]

> Die Application muss sich nicht um das Fragmentieren kuemmern.
ja sollte so sein, aber es kommt meist ein fehler wenn man ein zu 
grossen block versucht zu senden ( 50Mbyte sehe ich als zu gross an).
Man braucht sich nicht an die 64k größe zu halten, aber man sollte ein 
sinnvolles maximum wählen.

[Alexander I. (daedalus)]

Hallo,

ein Stream Socket mit den 50 MByte (bzw. die von der Applikation 
vorverdauten Häppchen) wird doch letzten Endes auch in einzelne 
Datagramme mit max 64k zerteilt oder? Es wird ja nur garantiert, dass 
alle Daten vollständig und in korrekter Reihenfolge angekommen sind.

Also ist es der BsdSocket, der sich um die Teilung- und 
Wiederzusammensetzung kümmert? Da die Daten-Reihenfolge ja geklärt ist, 
muss dieser im Prinzip nur am Ende des letzten empfangenen und 
bestätigten Datagramms die Daten anfügen und wenn alles vollständig ist 
an die Zielapplikation melden, dass alles da ist?

Woher weiß das Ziel eigentlich auf wieviel Daten er nun warten muß, oder 
was er überhaupt als nächstes zu tun hat? Da muß es ja auch so ne Art 
Protokoll geben, wer wann wieviele Daten anfordert, oder ist das dann 
auch wieder Aufgabe der Applikation? Gibt es ein paar Stichwörter wo ich 
da nachschlagen könnte?

Ich finde im Netz zwar viele Anleitungen und (zu) einfache Beispiele, 
wie man Sockets benutzt, aber kaum wie die intern tatsächlich aufgebaut 
sind und was da noch so hinter den I/O-Funktionen abläuft (außer die 
völlig unübersichtliche linux_socket.c mit seinen inkludierten 
Freunden).

[Marc D. (cosinus)]

auf wie viel Daten zu warten ist, ist Application sache. Wie waers wenn 
du dir mal das TCP Protocol anschaust?

http://de.wikipedia.org/wiki/Transmission_Control_Protocol