C# Socket <EOF>

[Ghost_Rider_R]

Hallo zusammen,

mich beschäftigt aktuell, wie man in C# beim Übertragen von mehrere Objekte / Byte-Arrays (via Sockets) die Daten beim Empfangen wieder separiert bekommt.

Z.B.:
Client:
socket.Send(daten1);
socket.Send(daten2);
socket.Send(daten3);

Server:
byte[] großesDatenpaket = socket.ReceiveAll();

So wie ich das mitbekommen habe, obliegt das dem Programmierer, da kein End Of File Kennzeichen existiert.

Als Ideenansätze habe ich folgendes:
1. Die ersten 4 Bytes enthalten die Anzahl der Bytes der jeweiligen Daten.

2. Man baut selber EOF-Bytes ein z.B. 10101011. Sollte diese Sequenz innerhalb des Bytearrays bereits existieren, so muss dieses dequotet werden -> 10101011 wird ersetzt durch 1010101110101011 (analog zu ,,\\" in Zeichenketten). Am Ende muss das doppelt hinzugefügte Byte natürlich wieder entfernt werden, damit die Daten unverändert bleiben.

Wie würdet Ihr das Problem lösen, damit die Daten sauber getrennt werden können?

Danke für eure Ideen

LG Ghost

 

[sandreas]

Nimm doch MessagePack

var serializer = MessagePackSerializer.Get<T>();
// Pack obj to stream.
serializer.Pack(stream, obj);
// Unpack from stream.
var unpackedObject = serializer.Unpack(stream);

 

[Wasserhuhn]

Verstehe das Problem nicht.
Ist doch ein stinknormales Problem, dass du bei jeder Art von Stream hast. Google mal bemüht?
Man packt das in einen eigenen Layer, in dem man vorher die Länge der Payload angibt.

So wie ich das mitbekommen habe, obliegt das dem Programmierer, da kein End Of File Kennzeichen existiert.

Was heißt, es existiert kein EOF-Zeichen?
Ein Zeichen im Stream kann das Problem gar nicht lösen. Man übergibt ja einfach Daten. Da kann bzw. ist alles drin. Völlig falscher Ansatz durch fehlendes Grundverständnis.

Eines deiner vorherigen Themen beschäftigt sich ja mit demselben Grundproblem:
https://www.computerbase.de/forum/threads/mehrfach-in-einen-stream-schreiben.2068887/

Irgendwie sind alle deine Themen halbgar. War beim Kabel Crimpen ebenso. Und ich erinnere mich auch an das von mir verlinkte Thema.

 

[KitKat::new()]

Man packt das in einen eigenen Layer, in dem man vorher die Länge der Payload angibt.

was er als Idee hatte?

1. Die ersten 4 Bytes enthalten die Anzahl der Bytes der jeweiligen Daten.

Man übergibt ja einfach Daten. Da kann bzw. ist alles drin.

Eben nicht "einfach", sh.:

Sollte diese Sequenz innerhalb des Bytearrays bereits existieren, so muss dieses dequotet werden -> 10101011 wird ersetzt durch 1010101110101011 (analog zu ,,\\" in Zeichenketten).

Wenn man sich die Arbeitet etwas erleichtern möchte, kann man die Daten auch einfach base64 encoden, und sucht sich ein entsprechendes Trennzeichen raus, oder noch besser, man greift auf eine Fertiglösung zurück:

Nimm doch MessagePack

 

[andy_0]

Wie schon erwähnt, gibt es da verschiedene Ansätze. In der Realität baut man sich das in C# aber quasi nie von grund auf neu. Es gibt bereits verschiedene fertige Lösungen (z.B. NetMQ), wo die jeweiligen "Pakete" nach eigenen Gutdünken definiert werden.

Die jeweiligen Daten werden dann häufig als Objekte (C# Klasseninstanzen) serialisiert (z.B. JSON oder MessagePack Serializer) verschickt.

 

[Wasserhuhn]

was er als Idee hatte?

Habe den Post gelesen. Bitte lies du meinen auch.

Eben nicht "einfach", sh.:

?
Das Problem wird doch durch eine vernünftige Implementierung komplett umgangen.
Ja, wenn man etwas falsch macht, kann es schwieriger sein.

 

[Tornhoof]

Wenn man sich die Arbeitet etwas erleichtern möchte, kann man die Daten auch einfach base64 encoden,

Ehm, was glaubst du, was b64 hier helden würde? B64 wird genutzt um das Alphabet der Eingabedaten zu reduzieren, auf Kosten der Länge. Also um sie zb über ein ASCII Protokoll zu übertragen. Er hat aktuell kein ASCII Protokoll, er versucht ja gerade ein Protokoll zu entwickeln. Der Vorschlag die Länge vorne zu enkodieren passt schon. Seine Erkenntnis daß Stopsymbole Probleme machen auch.


Messagepack löst sein Problem auch nicht, da ist nur jedes Element in sich gut definiert. Wie viel Elemente zusammen gehören ist damit nicht geklärt, sondern nur implizit festgelegt, weil ein map Element einer Datenstruktur entspricht.

Wenn er unstrukturierte Daten schicken will ist ein Länge prefix die richtige Wahl.

 

[KitKat::new()]

Ehm, was glaubst du, was b64 hier helden würde? B64 wird genutzt um das Alphabet der Eingabedaten zu reduzieren, auf Kosten der Länge.

Wenn er das Eingabealphabet reduziert, gibt es Zeichen, die nicht mehr vorkommen. Diese können dann als Trennzeichen genutzt werden

 

[Ghost_Rider_R]

Irgendwie sind alle deine Themen halbgar. War beim Kabel Crimpen ebenso. Und ich erinnere mich auch an das von mir verlinkte Thema.

Dann tu uns doch bitte beiden einen Gefallen und mach einen großen Bogen um meine Threads. Das wäre dann Win Win für uns beide, was meinst?

 

[Wasserhuhn]

Klingt gut.
Muss das aber noch mit dem Unterhaltungsfaktor abwägen. Was raus kommt, liest du dann von mir, oder nicht.

 

[andy_0]

Haben sich deine Fragen geklärt? Hast du eine Lösung für dein Problem?

 

[Ghost_Rider_R]

Ja, ich denke ich werde es mit dem Präfix versuchen. Eventuell kombiniere ich es am Ende noch mit einem Hash-Wert, damit sichergestellt ist, dass es nicht doch zu irgendwelchen Fehlern bei der Übertragung kommt, dann müsste das so funzen.