Einzelnen Beitrag anzeigen

Benutzerbild von BUG
BUG

Registriert seit: 4. Dez 2003
Ort: Cottbus
2.094 Beiträge
 
#5

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

  Alt 21. Apr 2014, 22:50
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.

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.

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.

Geändert von BUG (21. Apr 2014 um 22:56 Uhr)
  Mit Zitat antworten Zitat