Warum gibt es kein .ReceiveStream bei den Socket-Komponenten (TClientSocket und TServerSocket)?

Die Existenz der Methode .SendStream und der häufig missverstandene Zusammenhang des OnReceive-Ereignisses mit der empfangenen Datenmenge (FAQ-Beitrag) führt leider oft zu der falschen Annahme, es sei ohne weiteres möglich, einen Stream über eine TCP-Verbindung zu senden und auf der Empfängerseite damit wieder als (identischen) Stream weiterzuarbeiten. Diese Vorstellung ist häufig eine gedankliche "Weiterentwicklung" folgender Arbeitsweise: in einfachen Chats wird eine Nachricht mit .SendText gesendet und genau diese Nachricht kann mit .ReceiveText wieder aus der Verbindung gelesen werden. Der oben referenzierte FAQ-Beitrag erläutert, warum das nur zufällig klappt. Deshalb liegt die Idee häufig nahe, das ginge auch mit einem Delphi-Stream-Objekt (wie z.B. einem TMemoryStream). Spätestens aber wenn auffällt, dass die Socket-Komponenten ja gar keine .ReceiveStream-Methode haben, kommt man dann schon ins Grübeln...

Tja, warum eigentlich? Eine Socketverbindung sollte als universelle Dienstleistung zum Transportieren von Daten betrachtet werden. Das geht aber nur dann, wenn die Daten ohne Strukturinformationen (wie zum Beispiel die Menge der Daten) verarbeitet werden. Deshalb fehlt die Möglichkeit, dem Empfänger die Größe des Streams mitzuteilen. Aber genau das ist notwendig, um ein Stream-Objekt in Delphi verarbeiten zu können. Fazit: Netzwerkverbindungen sind strukturfreie Dienstleistungseinrichtungen!

Eine Lösungsmöglichkeit für das Problem besteht darin, die Länge des Stream-Objekts zusätzlich zu den Stream-Daten zu senden. Damit sind wir aber schon wieder bei einem alten Bekannten: dem Protokoll. Warum? Wir haben in diesem Fall zwei verschiedene Typen von Daten: Stream-Länge und Stream-Daten, und um die Zwei auseinanderhalten zu können, brauchen wir ein Protokoll.

cu
Narses