Indy TCP Server/Client: Streams senden/empfangen und Unterschied zu Strings???

[romber]

Hallo!
Frohe Ostern und schöne Feiertage!

Ein Server (der selber ein Webservice-Client ist) empfängt pro Minute mehrere Hundert einzelne String-Datensätze, die er dann an alle verbundenen Clients weiterleitet. Die Übertragung geschieht mittels TIdTCPServer/TIdTCPClient. Bis jetzt habe ich die Daten auch als Strings an die Clients geschickt. Auf der Clientseite wird jeder empfangene Datensatz in einen XML-Reader geladen. Der XML-Reader benutzt dafür eine Funktion namens LoadFromXML, die nichts anderes macht, als die Daten in ein Stream zu laden, um dann mittels LoadFromStream an den Reader zu übergeben. Jetzt überlege ich mir, ob es nicht besser wäre, die Datensätze direkt als Streams zu übertragen. Dazu hätte ich einige Fragen an die erfahrenen Experten:

1. Ist die Datenübertragung mittels Streams grundsätzlich schneller oder langsammer als die mit Strings? Macht es überhaupt Sinn, auf Streams umzubauen?
2. Wie schon erwähnt, müssen permanent mehrere Hundert einzelne Datensätze pro Minute hintereinander übertragen werden. Ist die Übertragung mittels Streams überhaupt dafür geeignet?
3. Im Fall von Strings muss ich jeden zu übertragenen String mit einer eindeutigen Zeichenkombination beenden, damit der Client die "zusammengewachsene" Datenpakete auseinander halten kann. Muss ich irgendwas in der Art auch für Streams anwenden?
4. In Foren wird es viel diskutiert über die Übertragung von Daten in Records (auch mittels Streams). Welche Vorteile könnten Records in meinem Fall haben?

Im Voraus vielen Dank!

[sx2008]

Zitat:

Zitat von romber (Beitrag 1256274)

... muss ich jeden zu übertragenen String mit einer eindeutigen Zeichenkombination beenden, damit der Client die "zusammengewachsene" Datenpakete auseinander halten kann

Das ist die wichtigste Frage bei TCP überhaupt.
Zunächst einmal ist TCP streambasiert, d.h. man muss sich das so vorstellen wie eine Röhre aus der immer wieder Kugeln (Bytes) herausfallen.
(es gibt noch eine 2. Röhre in Gegenrichtung)
Wieviele Kugeln direkt nacheinander rausfallen lässt sich nicht vorhersehen, denn das hängt von vielen Faktoren des Netzwerks und des IP-Stacks ab.
Daher ist es unbedingt notwendig einzelne Nachrichten mit irgendeinem Verfahren zu trennen.
Gebräuchlich sind Verfahren die einzelne Nachrichten durch ein eindeutiges Zeichen (meist Carriage Return) trennen oder vor jeder Nachricht die Anzahl der folgenden Bytes übermitteln.

Ob man Nachrichten als Strings versendet oder eine TStream-Klasse einsetzt ist nicht so wichtig.
Wichtig ist dass man ein gutes Protokoll definiert und dass der Empfänger damit umgehen kann nur Bruchstücke einer Nachricht zu empfangen und daraus die ursprünglichen Nachrichten wieder herstellen kann.

[mjustin]

Zitat:

Zitat von romber (Beitrag 1256274)

1. Ist die Datenübertragung mittels Streams grundsätzlich schneller oder langsammer als die mit Strings? Macht es überhaupt Sinn, auf Streams umzubauen?

Wenn man sich auf eine stringbasierte Übertragung festlegt, werden binäre Daten noermalerweise erst in einen String übersetzt, damit dieser dann mit einem eindeutigen Terminator abgeschlossen werden kann. Durch die Kodierung steigt der Platzbedarf des Datenstroms um 33–36 % (Base64, http://de.wikipedia.org/wiki/Base64).

In diesem Fall ist es vorteilhafter einen Stream zu senden: zum einen spart es Bandbreite, und es entfällt die Base64 Konvertierung auf Server und Client.

Zitat:

Zitat von romber (Beitrag 1256274)

2. Wie schon erwähnt, müssen permanent mehrere Hundert einzelne Datensätze pro Minute hintereinander übertragen werden. Ist die Übertragung mittels Streams überhaupt dafür geeignet?

Begrenzt wird die Leistung durch die freien Hardwareresourcen und das Netzwerk. Es kommt auf den Umfang der Daten an, eine Nachrichtenfrequenz von mehreren pro Sekunde ist völlig harmlos (auf einem Kern schaffe ich aktuell von einem Delphi TCP Client bis zu 40.000 Nachrichten die an einen auf Java basierenden Server gesendet und von diesem an den Client zurückgesendet werden).

Zitat:

Zitat von romber (Beitrag 1256274)

3. Im Fall von Strings muss ich jeden zu übertragenen String mit einer eindeutigen Zeichenkombination beenden, damit der Client die "zusammengewachsene" Datenpakete auseinander halten kann. Muss ich irgendwas in der Art auch für Streams anwenden?
Übertragung mittels Streams überhaupt dafür geeignet?

Da Streams auch jedes denkbare Endekennzeichen enthalten können, geht es nur umgekhert - mit einer Übermittlung der Länge vor den Bytes des Streams. Indy's TIdTCPClient.IOHandler unterstützt aber das Senden / Empangen von Streams mit einer automatisch vorangestellten Längenangabe. Damit ist nur wenig eigener Code notwendig. Wichtig ist vor allem die Freigabe des Streams nach seiner Verwendung (auf beiden Seiten).

Zitat:

Zitat von romber (Beitrag 1256274)

4. In Foren wird es viel diskutiert über die Übertragung von Daten in Records (auch mittels Streams). Welche Vorteile könnten Records in meinem Fall haben?

Records funktionieren nur wenn Client und Server garantiert exakt den gleichen Recordtypen verwenden. Sobald dies nicht garantiert ist (verschiedene Server / Clientversionen gleichzeitig im Einsatz, 32/64 Bit Unterstützung...) sind andere Formate robuster.

[Aphton]

[OT oder nicht, dürfte etwas mit dem Thema zu tun haben]

Ich hab kürzlich irgendwo aufgeschnappt, dass man mit Strings evtentuelle Probleme mit Endianness ganz umgeht - stimmt das eig. so?
Bei der ANSI (und sonstigen 1 Byte/Zeichen) Kodierung ist mir klar, dass die Daten immer in einer einzigen Reihenfolge im Speicher liegen, weil
die Anordnungsmöglichkeit bei 1 Byte eben nur 1 ist.
Gilt es aber auch für andere Kodierungen, die mehr benötigen? Wenn man z.B. 2 oder 4 Byte / Zeichen benötigt, können die ja, je nach Endianness, anders im Speicher liegen -
oder werden Strings speziell gehandhabt?

Weil das wäre dann oder auch immer (wenn nur 1 Byte/Zeichen) ein Pluspunkt für ein String-basiertes Protokoll!
Klärt micht auf!

:P
[/OT]

@mjustin
Man muss ja nicht wirklich base64 kodieren, oder? Ich kanns mir nur dann vorstellen, wenn man Kollisionen mit Terminalzeichen & Daten vermeiden will.
Das kann man aber auch anders und viel eleganter lösen, indem man die Terminalzeichen, die so im Datensatz vorkommen, einfach escaped.

[BUG]

Zitat:

Zitat von Aphton (Beitrag 1256312)

Ich hab kürzlich irgendwo aufgeschnappt, dass man mit Strings evtentuelle Probleme mit Endianness ganz umgeht - stimmt das eig. so?

Mehr oder wenige ja, da die Reihenfolge bei Zahlencodierung in Strings üblicherweise immer Big-Endian ist.

Zitat:

Zitat von Aphton (Beitrag 1256312)

Wenn man z.B. 2 oder 4 Byte / Zeichen benötigt, können die ja, je nach Endianness, anders im Speicher liegen

Das Problem gibt es tatsächlich, zum Beispiel bei UTF-16. Bei dem im Web gebräuchlichem UTF-8 ist das wieder kein Problem.

Zitat:

Zitat von Aphton (Beitrag 1256312)

Das kann man aber auch anders und viel eleganter lösen, indem man die Terminalzeichen, die so im Datensatz vorkommen, einfach escaped.

Relativ günstig finde ich die Lösung mit vorangestellter Nachrichtenlänge, da man dabei schon vor Ende der Nachricht weiß, wie groß diese sein wird.


Zum richtigen Thema, habe ich das richtig verstanden:

1. Du hast Strings, die XML enthalten.
2. Du versendest diese Strings durch ein bestimmtes Zeichen getrennt über TCP.
3. Dein Client-seitiger XML-Reader bekommt einen String, den er in einen Stream schreibt, um ihn dann auszulesen.

In diesem Fall: Du wirst durch das "direkte" Versenden der XML-Daten nicht viel einsparen können. Da einzige, was dir (abgesehen von der Zeit beim Kopieren) verloren geht, ist ein kleinen Potenzial zur Parallelisierung (Netzwerk-IO und der XML-Reader). Solange du XML versendest, versendest du Text/Zeichenketten. Je nach Art des Datensätzen kann eine Kodierung in XML locker 10x so groß sein. Dort liegt das eigentliche Potenzial zur Einsparung von Netzwerklast.