Einzelnen Beitrag anzeigen

Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.184 Beiträge
 
Delphi 12 Athens
 
#6

AW: Eigenes Protokoll - Prinzipieller Aufbau

  Alt 6. Aug 2012, 21:45
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
$2B or not $2B

Geändert von himitsu ( 6. Aug 2012 um 21:55 Uhr)
  Mit Zitat antworten Zitat