AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Netzwerke Eigenes Protokoll - Prinzipieller Aufbau

Eigenes Protokoll - Prinzipieller Aufbau

Ein Thema von blablab · begonnen am 6. Aug 2012 · letzter Beitrag vom 7. Aug 2012
Antwort Antwort
blablab

Registriert seit: 3. Jan 2006
507 Beiträge
 
Delphi 7 Enterprise
 
#1

Eigenes Protokoll - Prinzipieller Aufbau

  Alt 6. Aug 2012, 00:36
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
  Mit Zitat antworten Zitat
Benutzerbild von BUG
BUG

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

AW: Eigenes Protokoll - Prinzipieller Aufbau

  Alt 6. Aug 2012, 01:24
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 Bei Google suchenFluß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.
Intellekt ist das Verstehen von Wissen. Verstehen ist der wahre Pfad zu Einsicht. Einsicht ist der Schlüssel zu allem.
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
2.786 Beiträge
 
Delphi 2009 Professional
 
#3

AW: Eigenes Protokoll - Prinzipieller Aufbau

  Alt 6. Aug 2012, 07:04
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.
Michael Justin
  Mit Zitat antworten Zitat
r2c2

Registriert seit: 9. Mai 2005
Ort: Nordbaden
925 Beiträge
 
#4

AW: Eigenes Protokoll - Prinzipieller Aufbau

  Alt 6. Aug 2012, 14:40
http://www.christian-rehn.de/2007/12...kommunikation/
http://www.entwickler-ecke.de/topic_60744.html?view=dl

mfg

Christian
Kaum macht man's richtig, schon klappts!
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#5

AW: Eigenes Protokoll - Prinzipieller Aufbau

  Alt 6. Aug 2012, 20:36
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.
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
38.276 Beiträge
 
Delphi 10.4 Sydney
 
#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
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

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

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#7

AW: Eigenes Protokoll - Prinzipieller Aufbau

  Alt 6. Aug 2012, 21:49
Fehlerkorrektur und Erkennung dürfte hier unnötig sein, da TCP ja schon sicherstellt, dass alle Daten korrekt und vollständig übertragen werden.
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#8

AW: Eigenes Protokoll - Prinzipieller Aufbau

  Alt 7. Aug 2012, 08:26
...
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.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
38.276 Beiträge
 
Delphi 10.4 Sydney
 
#9

AW: Eigenes Protokoll - Prinzipieller Aufbau

  Alt 7. Aug 2012, 10:32
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +2. Es ist jetzt 10:01 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf