Stream über TCP - Blockaufteilung ?

[Stefanie]

Ich möchte über TCP Streams übertragen. Nun ist es ja bei TCP nicht so einfach wie bei UDP. Bei UDP kann ich einfach einen Stream senden und dieser kommt beim UDP-Emfänger in einem Stück wieder so an. Bei TCP - soweit ich das bisher richtig verstanden habe - werden die Daten(also der Stream) Blockweise übertragen und ich muß den Stream beim Emfänger aus den einzelnen Blöcken wieder zusammensetzen. Nun ist es nach meinen Tests so, dass größere Streams in mehrere Blöcke aufgeteilt und so Stück für Stück übertragen werden. Hingegen bei vielen kleinen Streams(Streamgröße ~ 5 bis 10 Byte), die schnell hintereinander gesendet werden (über socket.sendstream(Stream)) kommen auf der Emfängerseite mehrere Streams zu einem Block zusammengefasst an. Bei einer langsamen Netzwerkverbindung, z.B. über Modem bzw. ISDN tritt die Zusammenfassung von Streams zu größeren Blöcken deutlich stärker auf als bei einer schnellen internen LAN-Verbindung.

Nun meine Frage(n): Kann ich irgenwo festlegen, dass die kleinen Streams nicht zu mehreren Blöcken zusammengefasst und gesendet werden, bzw. kann ich die Blockgröße festlegen.
Gibt es eine verständliche Logik, wie die Blockgröße bei TCP festgelegt wird. Weis ich schon irgendwoher schon beim Senden, in welche Blöcke mein Stream aufgeteilt bzw. zusammengefasst wird ?

[Klaus01]

Guten Morgen,

die "Blockgröße" wird durch die Maximal Transfer Unit (MTU-Size) bestimmt.
Diese kann auf dem Interface (tcpDoctor) eingestellt werden.
Default MTU-Size ist, wenn ich micht nicht irre, 1500 Byte.

Grüße
Klaus

[ele]

Ich glaube du verwechselst da TCP mit UDP. Mit TCP kommt alles in einem Stück an in der Reihenfolge wie du es gesendet hast. Bei UDP kannst du Blöcke versenden, kannst aber nicht sicher sein, dass die jeweiligen Blöcke auch ankommen und schon gar nicht, dass sie in der selben Reihenfolge ankommen.

[Stefanie]

Danke Klaus,
ich hatte gehofft, dass die Blockgröße eine Einstellung beim SocketClient bzw. SocketServer ist und ich diese je nach größe des zu sendenden Streams anpassen(erzwingen) kann. So macht das aber keinen rechten Sinn, die Blockgröße zu erzwingen.
Das die MTU die Fragmentierung der Daten eigenständig übernimmt ist ja soweit OK, aber dass die MTU auf der "Gegenstelle" die Daten nicht wieder defragmentiert verwundert mich überhaupt.
Aber warum werden dann kleine Streams zu großen Blöcken zusammengefasst? Einen großen Stream wieder aus mehreren Blöcken zusammensetzen ist einfach und ich brauch nur die Größe des Streams. Einen Block in mehrere kleine Streams wieder aufspalten ist nur mit irgendeiner unique Erkennung am Anfang & Ende des Streams möglich. Das bedeutet zusätzliche Bytes am Anfang & Ende des Streams. Das möchte ich vermeiden, den bei einer Streamgröße von z.B. 6 Bytes überhaupt würde das die kleine Datenmenge unnötig aufblähen.

Habt ihr eine Idee für mein Problem ?

Zitat:

Ich glaube du verwechselst da TCP mit UDP. Mit TCP kommt alles in einem Stück an in der Reihenfolge wie du es gesendet hast. Bei UDP kannst du Blöcke versenden, kannst aber nicht sicher sein, dass die jeweiligen Blöcke auch ankommen und schon gar nicht, dass sie in der selben Reihenfolge ankommen.

Bei TCP kommt der Stream eben nicht in einem Stück an - eben wegen der Fragmentierung durch die MTU.

[ele]

Ich habe das Gefühl wir reden mit gleichen Begriffen von verschiedenen Dingen.

Ein Stream ist für mich eine beliebige anzahl von Zeichen die übertragen werden soll. Wenn Alice über TCP Daten an Bob sendet, dann wird der Stream sehr wohl in einzelne IP-Datagramme zerlegt und verschickt. Bei Bob werden diese Pakete aber wieder zusammengesetzt und in der Reihenfolge wie sie gesendet wurden. Dafür ist ja TCP da sonst müsste man alles mühsam mit UDP, welches nicht sicherstellt dass ein Paket auch ankommt und auch nicht in der richtigen Reihenfolge.

Wenn du TCP benutzt musst du dich nicht um Paketgrössen oder Reihenfolge kümmern, das macht TCP für dich. Wenn du das nicht möchtest, dann ist TCP das falsche Protokoll dafür. Beim Streaming von Audio- und Video-Daten z.B. (und das hat z.B. mit einem Stream wie er in Delphi definiert ist gar nichts zu tun) wird UDP verwendet. Das eine oder andere Paket, dass verloren geht, ist dabei nicht relevant (dafür gibt es Qualitätseinbussen).

Oder ich habe nicht verstanden worum es geht...

[generic]

Zitat:

Zitat von Klaus01

Default MTU-Size ist, wenn ich micht nicht irre, 1500 Byte.

nur bei <1Gbit Netzen.
Bei >=1Gbit gibt es Jumboframes
Wenn du PPPOE nutzen ist die Paketgröße noch kleiner 1492.

[Luckie]

Was interessiert dich das eigentlich? Du befindest dich doch im Application Layer vom OSI Referenzmodell mit deiner Anwendung. was die untergeordneten Protokolle machen, ist für dich doch gar nicht von Interesse. Deswegen gibt es ja diese Abstraktion, dass man sich auf Anwendungsebene nicht darum kümmern muss.

[Klaus01]

Zitat:

Zitat von generic

Zitat:

Zitat von Klaus01

Default MTU-Size ist, wenn ich micht nicht irre, 1500 Byte.

..
Bei >=1000Gbit gibt es Jumboframes
..

Gibt es da schon was quasi 1 Terrabit/s?

Grüße
Klaus

[himitsu]

er meinte wohl MBit,
aber ja, sowas gibt es schon lange 'ne G1-Leitung hatte ich mir schon lange gewünscht, wobei es ja heutzutage schonwieder was Schnelleres gibt.

[Stefanie]

Zitat:

Was interessiert dich das eigentlich? Du befindest dich doch im Application Layer vom OSI Referenzmodell mit deiner Anwendung. was die untergeordneten Protokolle machen, ist für dich doch gar nicht von Interesse. Deswegen gibt es ja diese Abstraktion, dass man sich auf Anwendungsebene nicht darum kümmern muss.

Luckie, damit hast du völlig recht. Was interessiert mich das eigentlich? Ich möchte einefach einen Stream übertragen und fertig. Doch ich empfange eben den Stream nicht so wie ich ihn gesendet habe. Ich erhalte den Stream Blockweise oder mehrere Streams in einem Block und muß dann selbst wieder meine Streams zusammenbasteln oder aus dem Block trennen. Der Link von Klaus war für mich sehr hilfreich, da ist alles sehr schön erklärt mit der Fragmentierung. Aber wie gesagt, damit will ich eigentlich nichts zu tun haben. Bisher hab ich noch keine Idee für mein oben angesprochenes Problem.