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

[BUG]

Zitat von Aphton:

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 von Aphton:

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 von Aphton:

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.