Eigenes Protokoll - Prinzipieller Aufbau

[blablab]

Hallo!

Sobald ich zwei Programme per Netzwerk miteinander kommunizieren lasse brauche ich ein kleines Protokoll. Und ich frage mich, wie ich das am geschicktesten aufbaue.
Ich habe vor einiger Zeit mal ein kleines Chatprogramm geschrieben. Da habe ich am Anfang jedes Pakets ein Byte gesetzt, das die Bedeutung des Pakets darstellte. Zum Beispiel M bedeutete dass jetzt eine Chat-Nachricht kommt. Das ganze hat auch lange Zeit wunderbar geklappt, bis ich dann WLan benutzt habe und die Pakete in mehrere Teile aufgeteilt wurden...
Jetzt habe ich mir überlegt, ich sende M + Länge der Nachricht + Nachricht. Aber was mache ich dann, wenn die Nachricht sehr lange ist und ich die Übertragung abbrechen will?
Es geht hier ja nicht um ein eigenes vollständiges Protokoll, das von 0 anfängt, sondern nur um ein Mini-Protokoll, das auf TCP aufbaut. Aber irgenwie find ich auch das schon gar nicht mal so einfach...
Wie macht man das normalerweise?

Grüße
blablab

[BUG]

Auch wenn dir TCP eine Bytestromsemantik bietet, würde ich ein ein Protokoll abstrakt wieder als einen Nachrichtenaustausch sehen. Dann kannst du dein Protokoll schön mit Hilfe von Zustandsautomaten und Ablaufdiagramm entwickeln.

Für dein spezielles Problem kannst du dir mal angucken, wie die Flußsteuerung in TCP (oder einfacheren Protokollen) umgesetzt ist und dich davon inspirieren lassen.
Dabei musst du den TCP-Datenstrom nicht unbedingt wieder logisch zerhacken, aber die Vorstellung könnte hilfreich sein.

Allgemein wäre es gut, Endianess und Kodierung von Zeichenketten festzuschreiben, damit es da keine Verwirrungen gibt. Ein Handshake, um festzustellen dass beide Endstellen das gleiche Protokoll sprechen, sollte auch nicht schaden.

[mjustin]

Zitat von blablab:

Aber was mache ich dann, wenn die Nachricht sehr lange ist und ich die Übertragung abbrechen will?

Wenn der Header die Länge enthält ist es doch einfach - mit "if Header.Length > MAX_LENGTH then CloseConnection" zum Beispiel.

Beispiele für textbasierte Protokolle:

http://stomp.github.com/stomp-specification-1.0.html

http://stomp.github.com/stomp-specification-1.1.html

Textbasiert hat den Vorteil dass man die Kommunikation mit einem einfachen Telnet-Client bereits testen kann.

[r2c2]

http://www.christian-rehn.de/2007/12...kommunikation/
http://www.entwickler-ecke.de/topic_60744.html?view=dl

mfg

Christian

[Zacherl]

Indem du ein paar Bytes mit der jeweiligen Paketlänge vorwegschickst, kannst du auf jeden Fall alle Pakete zu 100% korrekt trennen. Egal, ob 3 1/2 auf einmal ankommen oder ein Paket 4 Durchläufe braucht, um komplett zu sein.

Wenn du lange Datenströme abbrechen willst, kannst du das realisieren, indem du deine Daten auf der Seite des Senders in kleine Blöcke (z.b. 32KiB) aufteilst und dann in einer Schleife sendest. In meinem kleinen Protokoll wird neben dem Header mit der Gesamtgröße auch vor jedem kleinen Teilpaket noch ein Header mit gewissen Flags gesendet. Über diese Flags steuere ich dann beispielsweise auch den Abbruch eines Transfers.

Bei mir war die Zielsetzung allerdings auch anders, denn ich wollte mehrere simultane Transfers über ein einzelnes Socket realisieren und dazu noch ein Prioritätssystem einbauen.

[himitsu]

Wenn man jetzt wüßte, was für ein Delphi und in welche Edition verwendet wird (immer schön, daß nie alles verraten wird),
dann könnte man sogar sagen, ob es nicht sogar schon was Fertiges im Delphi gibt. (z.B. DBX, DataSnap und Co.)

Wobei es auch von anderen Anbietern fertige Lösungen gibt.

Bei einem eigenem Protokoll solltest du dir aber unbedingt erstmal ein einheitliches Grundprinzip überlegen, worauf dann alle weiteren Daten aufbauen.
Denn nur so bleibt es erweiterbar und fehlerunanfällig.

z.B.
- vor alle Daten ein Startcode (falls du später auch noch bei fehlerhaften Datenübertragungen den Anfang des nächsten Blocks erkennen willst)
- dann die Länge des ganzen Blocks
- den Namen/die Kennung des Blocks (mit Längenangabe voran oder Endemarkierung hinten dran, aber ich würde besser immer mit Längenangabe arbeiten)
- und nun die Daten, auch wieder mit Länge, welche man genausi immer mehr verschachteln könnte
- und eventuell noch eine Endemarkierung, CRC usw.

oder
- Startcode
- Datenlänge
- mit TReader/TWriter erstellter Datenblock ... TWriter kennt gewisse Grundtypen und Verschachtelungen, womit man die Daten auch wieder auseinandernehmen kann, ohne das Format zu kennen, da das Format gleich mit abgespeichert wird.
PS: Das Binärformat der DFMs nutzt dieses
- CRC32 über Datenlänge+Datenblock

Beim Empfang passiert nun auch nichts Schlimmes, wenn der Empfänger das Datenformat nicht kenn und er kann sich beruhigt dem nächsten Block widmen, da er ja weiß die das Grundformat aufgebaut ist (1. und 2. Variante) oder er kann sogar reinsehn und für die Fehlerbehandlung ein paar mehr Infos geben, da er auch noch den grundlegenden Aufbau der Daten kennt (2. Variante).

Die Fehler kann man dann entweder loggen, oder bei einheitlichem Rückkanal, mit passenden Grundfunktionen, auch dem Klienten mitteilen.
z.B. Ein Befehl für löse eine Exceptions auf dem Klienten aus und hier hast du noch eine Fehlermeldung, womit dann die Fehlermeldung immer zum Verursacher übertagen wird.
(Klient sendet fehlerhafte/unbekannte Daten oder nach dem Empfan stimmt der Hash nicht, womit auf dem Klient eine Exception "fehlerhafte Daten" ausgelöst wird, im zugehörenden Übertragungsthread ... und das Selbe, wenn der Server Daten sendet, die der Klient nicht kennt, dann knallt es im Server.

[edit]
OK, dann halt ohne

[Zacherl]

Fehlerkorrektur und Erkennung dürfte hier unnötig sein, da TCP ja schon sicherstellt, dass alle Daten korrekt und vollständig übertragen werden.

[Furtbichler]

Zitat von himitsu:

...
z.B.
- vor alle Daten ein Startcode ...
- dann die Länge des ganzen Blocks
- den Namen/die Kennung des Blocks (mit Längenangabe voran oder Endemarkierung hinten dran, aber ich würde besser immer mit Längenangabe arbeiten)
- und nun die Daten, auch wieder mit Länge, welche man genausi immer mehr verschachteln könnte
- und eventuell noch eine Endemarkierung, CRC usw.

oder
- Startcode
- Datenlänge
- mit TReader/TWriter erstellter Datenblock ...
- CRC32 über Datenlänge+Datenblock

Was passiert, wenn die Datenlänge falsch übermittelt wurde?
Ich würde mindestens ein Endezeichen oder doch eine CRC verwenden.
Eine CRC/Checksum mag redundant sein, aber was passiert, wenn der Empfang in der Mitte eines logischen Streams einsetzt? Dann ist die Datenlänge undefiniert bzw. irgendeine Hausnummer (alles schon dagewesen).
In sehr störanfälligen Netzen kann es zudem trotzdem zu Übertragungsfehlern kommen, auch wenn TCP das angeblich abfängt. Allerdings ist der Fall extrem selten

Weiterhin muss bedacht werden, das Verbindungsabbrüche nicht notwendigerweise erkannt werden, d.h. beide Seiten denken, das die Verbindung ok ist. Hier können Heartbeats helfen, also eine Seite sendet 1x pro Sekunde ein kleines Paket, das von der Gegenstelle zurückgeschickt wird.

[himitsu]

Zitat von Furtbichler:

Weiterhin muss bedacht werden, das Verbindungsabbrüche nicht notwendigerweise erkannt werden, d.h. beide Seiten denken, das die Verbindung ok ist.

Das passiert selbst bei DataSnap (siehe alte Threads von mir), wobei es beim Clienten das nächste mal Knallt und er eine neue Verbindung aufbauen könnte.
Aber der Server ist da Problematischer, da er z.B. beim Beenden aus solchen angeblich noch "offenen" Verbindungen hängen bleibt, weil er denen noch Tschüs sagen will.
Aber schlimmer ist es bei den Callbacks, denn da kann es auch im Server knallen und wenn es mal richtig Knallt, dann kannst'e schnell mal die ganze Serveranwendung vergessen.