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.