"Eigenes" Protokoll für eine TCP Kommunikation

[Repac3r]

Schönen guten Abend euch,

derzeit arbeite ich an einer Client/Server Lösung.

Der Server überträgt dem Client Daten aus einer Mysql Datenbank, evtl. auch Dateien.

Meine Frage ist jetzt, wie würde dafür ein relativ sauberes Protokoll aussehen?

Ich habe es mir so gedacht:

Der Client bekommt immer mindestens ein Paket zugeschickt, das wie folgt aussieht:

ID#Type#MaxCountPackets#CurrentCountPackets#Data

ID: die ID des Paketes (Die ID ist in jedem "Subpaket" gleich)

Type: sagt dem Client, ob es sich um eine Datei, um einen String o.ä handelt

MaxCountPackets: Wie viele Subpakete es gibt, falls Data größer als 4096 Byte ist

CurrentCountPackets: sagt um welches SubPaket es sich handelt

Data: kann alles mögliche sein (String, Logindaten, Bilder...)

Dieser String wird dann immer mit einer Raute gesplittet.

Wenn Data größer als 4096 Byte ist, wird ein zweites Paket hinterher geschickt.

Frage 1: Ist dies eine akzeptable Möglichkeit, um eine Cient/Server Kommunikation aufzubauen?

Frage 2: Kann ich dann einfach die komplette Nachricht am TCP Client entgegennehmen? Das heißt, dass ich keinen Buffer dazwischen schalten muss, da der Buffer eigentlich schon in der Nachricht enthalten ist.

Frage 3: Ist der Buffer, bzw. die maximale Länge pro Paket von Data zu groß?

[Klotzkopp]

Woran erkennst du den Anfang einer neuen Nachricht?

Bearbeitet 5. August 2014 von Klotzkopp

[Repac3r]

Woran erkennst du den Anfang einer neuen Nachricht?

Gut, dann wird eben am Ende und am Anfang nochmal eine Raute gesetzt, sorry total vergessen ;

Lg marcel

[Klotzkopp]

Wie unterscheidest du eine Raute im Data-Teil vom Ende der Nachricht?

[Repac3r]

Wie unterscheidest du eine Raute im Data-Teil vom Ende der Nachricht?

Hast du eine bessere Idee?

[Shadowman]

Wenn du sicherstellen kannst, dass in keinem Block eine weitere Raute vorkommen kann und du somit eine feste Anzahl an Trennzeichen hast, müsste es gehen. Wenn du das nicht sicherstellen kannst (wenn du zum Beispiel den Data Teil text sendest und dieser auch Rauten enthalten kann), kannst du nicht mit Sicherheit bestimmen, wann ein Paket zuende ist.

In diesem Fall solltest du ein anderes Zeichen für Start und Ende verwenden.

Bearbeitet 6. August 2014 von Shadowman

[Repac3r]

Wenn du sicherstellen kannst, dass in keinem Block eine weitere Raute vorkommen kann und du somit eine feste Anzahl an Trennzeichen hast, müsste es gehen. Wenn du das nicht sicherstellen kannst (wenn du zum Beispiel den Data Teil text sendest und dieser auch Rauten enthalten kann), kannst du nicht mit Sicherheit bestimmen, wann ein Paket zuende ist.

In diesem Fall solltest du ein anderes Zeichen für Start und Ende verwenden.

Was gibt es dann for ASCII Zeichen, die kaum benutzt werden. Ich kann nämlich nicht sicherstellen, was für Zeichen Data enthält.

Edit: Was haltet ihr von einer Reihe von Zeichen wie {#}?

[Klotzkopp]

Hast du eine bessere Idee?

Du könntest eine Escape-Sequenz benutzen, wenn im Datenstrom ein Steuerzeichen (in deinem Fall #) auftritt. Beispielsweise könntest du das Steuerzeichen verdoppeln, wenn es als Teil der Daten und nicht als Steuerzeichen interpretiert werden soll.

Oder du baust die Länge der Nachricht mit ins Protokoll ein.

[Shadowman]

Standard Ascii Codes mit Bedeutung:

0x01 -> Start of Header

0x02 -> Start of Text

0x03 -> End of Text

0x04 -> End of Transmission

so würde ich es aufbauen:

0x01ID#Type#MaxCountPackets#CurrentCountPackets0x02Data0x030x04

Das wäre glaube ich am saubersten

Bearbeitet 6. August 2014 von Shadowman

[Klotzkopp]

Standard Ascii Codes mit Bedeutung:

0x01 -> Start of Header

0x02 -> Start of Text

0x03 -> End of Text

0x04 -> End of Transmission

Das ist ja toll, wenn man Texte überträgt. Aber sobald man Binärdaten hat, hilft das auch nicht weiter.

[Klotzkopp]

Edit: Was haltet ihr von einer Reihe von Zeichen wie {#}?

Das verlagert das Problem nur. Was machst du, wenn diese Byte-Folge in deinen Nutzdaten auftaucht?

[Repac3r]

Das verlagert das Problem nur. Was machst du, wenn diese Byte-Folge in deinen Nutzdaten auftaucht?

Eben, dass kann ich leider nichts sicherstellen. Okay ich denke da werde ich die Länge von Data mit ins Protokoll nehmen.

Also so:

#ID#Type#MaxCountPackets#CurrentCountPackets#DataLength#Data#

[Shadowman]

Das ist ja toll, wenn man Texte überträgt. Aber sobald man Binärdaten hat, hilft das auch nicht weiter.

Wenn er Binärdaten überträgt, im Data-Block aber Text kommt (Zitat Repac3r: Ich kann nämlich nicht sicherstellen, was für Zeichen Data enthält.) muss er diese ja sowieso umwandeln. Somit muss er eine Konvertierungsmethode implementieren um aus dem Text einen Binärsatz zu machen.

Wenn er die Codes vor der Konvertierung anfügt und mit Konvertiert (natürlich dann auch umgekehrt bei der Verarbeitung) kann er auch beim eintreffen des Datenstroms auf diese Werte (natürlich binär) prüfen.

Wenn jetzt das Argument kommt, dass diese Zeichenkombination immer vorkommen kann: Jede binäre Kombination könnte rein Theoretisch in einer Folge auftreten. Hier geht es doch lediglich darum die Warscheinlichkeit zu reduzieren (oder liege ich da falsch?)

Mit Datentransfer habe ich mich noch nicht so tiefgehend auseinandergesetzt

[Repac3r]

Somit muss er eine Konvertierungsmethode implementieren um aus dem Text einen Binärsatz zu machen.

Muss ich eigentlich nicht machen, da ich ja bei Type angebe, um was es sich handelt (Text, Binär).

[flashpixx]

Welchen Sinn hat es ein eigenes Protokoll zu entwerfen? Im Normalfall sollte man auf bestehende Protokolle aufsetzen, als das Rad neu zu erfinden.

[Klotzkopp]

Somit muss er eine Konvertierungsmethode implementieren um aus dem Text einen Binärsatz zu machen.

Unsinn. Textdaten sind immer Binärdaten, umgekehrt nicht.

Wenn jetzt das Argument kommt, dass diese Zeichenkombination immer vorkommen kann: Jede binäre Kombination könnte rein Theoretisch in einer Folge auftreten. Hier geht es doch lediglich darum die Warscheinlichkeit zu reduzieren (oder liege ich da falsch?)

Wenn das Funktionieren des Protokolls auf Wahrscheinlichkeiten beruht, ist es kaputt. Es gibt erprobte Lösungen für dieses Problem, und ich habe sie genannt.

[Repac3r]

Welchen Sinn hat es ein eigenes Protokoll zu entwerfen? Im Normalfall sollte man auf bestehende Protokolle aufsetzen, als das Rad neu zu erfinden.

Deswegen habe ich auch gefragt, ob es bessere Möglichkeiten gibt

Und zur "immer wieder Rad neu erfinden Geschichte", mir macht es Spaß zu programmieren und Probleme zu lösen.

[Shadowman]

Wenn das Funktionieren des Protokolls auf Wahrscheinlichkeiten beruht, ist es kaputt. Es gibt erprobte Lösungen für dieses Problem, und ich habe sie genannt.

[Repac3r]

Eine Escapesequenz hat ja wieder das selbe Problem (sie könnte zufällig im Datenstrom auftauchen)

Habe das Problem gelöst, indem ich einfach die Länge von Data mit ins Protokoll nehme.

Aber wie würdet ihr solch eine Kommunikation aufbauen?

[SilentDemise]

Über standardisierte bestehende und jahrelang erprobte protokolle.

[Mttkrb]

Hallo,

was spricht dagegen die Daten per REST mit JSON-Objekten zu übertragen?

Gruß

[Klotzkopp]

Eine Escapesequenz hat ja wieder das selbe Problem (sie könnte zufällig im Datenstrom auftauchen)

Nein. Das einleitende Zeichen wird selbst auch durch eine Escape-Sequenz wiedergegeben.

[Patrick_C64]

"CLIENT"


Client.WriteByte(MSGTYPE type BYTE)

Client.WriteInt(MSGLEN type INT)

Client.WriteStream(MSG,MSGLEN)


Client -> Request.Send();


-------------------

"SERVER"

if(Server.Receive())

{

MSGType as Byte = Server.ReadByte(MSGTYPE type BYTE)

MSGLen as Byte = Server.ReadInt(MSGLEN type INT)

MSG as <2string>Stream Client.ReadStream(MSGLEN)

}

Protokollbescheibung:

-1 Byte MSG Type

-1 Int(4 Byte je nach Plattform/Compiler, wobei ich 2 Byte eher als Short betrachte) Länge der Nachricht

-Nachricht.

Warum nur einen String senden und den Aufwendig parsen? Wenn das viel viel einfacher geht !

Wenn der Server seine Antworten im Selben Schema (Protokoll) sendet, kannst du eine Methode implementieren zum senden und lesen die vom Host und Clienten benutzt werden kann. (U.a. Sinn und Zweck solcher Protokolle ein Verbindliches/Einheitliches Kommunikationsschema.)

Habe schon hochskalierbare Client/Host Protokolle implementiert (Slotbasierte Kommunikation etc. .....).

Nach eigenen Vorstellungen erweiter- und modifizierbar.

Sollte als Denkanstoß passen/genügen ! Toi Toi Toi und viel Erfolg!

Gruß

Patrick

Bearbeitet 6. August 2014 von Patrick_C64