mikrocontroller.net

Forum: PC-Programmierung Absicherung Kommunikation?


Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bastle an einem Kommunikationsprotokoll zwischen Clients und einem 
Server. Die Kommunikation erfolgt über UDP (kann nicht geändert werden). 
Da kann es vorkommen, dass Pakete verlorengehen oder beschädigt 
ankommen.
In einem Teil der Pakete werden Anweisungen zum Eintragen von Daten in 
in eine Datenbanken zum Server gesendet. Diese Pakete beantwortet der 
Server mit einer Quittung. Sollte eine solche Quittung beim Client nicht 
ankommen, kann das zwei Ursachen haben:

a) das ursprüngliche Paket ist beim Server nicht angekommen, also wird 
auch keine Quittung gesendet

b) die Quittung ist verlorengegangen

Der Client wartet immer eine gewisse Zeit auf die Quittung und sendet 
dann das ursprüngliche Paket evtl. nochmal. Im Falle, dass nur die 
Quittung verlorengegenagen ist, erfolgt dann aber die Eintragung in die 
Datenbank doppelt - sofern man keine zusätzliche Absicherung betreibt.

Um das zu verhindern gebe ich jedem Paket einen Timestamp mit, der im 
Falle einer Wiederholung unverändert bleibt und die Kennung, dass es 
sich um ein wiederholtes Paket handelt. So kann der Server nachsehen, ob 
er das Paket schon mal vor Kurzem verarbeitet hat.

Das funktioniert auch soweit ganz gut, ist aber ziemlich aufwändig, z.B. 
muss eine Liste der zuletzt verarbeiteten Pakete geführt werden. Hat 
hier evlt. jmd. noch einen Tip für einen celevereren Algorithmus? Danke.

Frank

Autor: faustian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"(kann nicht geändert werden)."

Das ist allerdings bloed, weil eigentlich willst du ein hoeheres 
RPC-Protokoll (DCE, ONCRPC, SOAP, whatever...) fuer so etwas nutzen.

Autor: Tom M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
> Um das zu verhindern gebe ich jedem Paket einen Timestamp mit, der im
> Falle einer Wiederholung unverändert bleibt und die Kennung, dass es
> sich um ein wiederholtes Paket handelt. So kann der Server nachsehen, ob
> er das Paket schon mal vor Kurzem verarbeitet hat.
>
> Das funktioniert auch soweit ganz gut, ist aber ziemlich aufwändig, z.B.
> muss eine Liste der zuletzt verarbeiteten Pakete geführt werden. Hat
> hier evlt. jmd. noch einen Tip für einen celevereren Algorithmus? Danke.

Schau mal, wie es bei TCP gemacht wird, nämlich mittels Sequenz-Nummern. 
Wenn du dazu die Annahme machen kannst, dass sich Pakete niemals 
"überholen" oder das nur sehr wenige Pakete betrifft, scheint mir das 
viel effizienter zu sein, als mit Timestamps und Retransmit-Kennungen zu 
hantieren.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
> Um das zu verhindern gebe ich jedem Paket einen Timestamp mit, der im
> Falle einer Wiederholung unverändert bleibt und die Kennung, dass es
> sich um ein wiederholtes Paket handelt. So kann der Server nachsehen, ob
> er das Paket schon mal vor Kurzem verarbeitet hat.

Das mit der expliziten Retransmit-Kennung als Signal "schau in der 
Liste" solltest du lassen, wenn die Kommunikation in einer nicht von dir 
selbst vollständig kontrollierten Umgebung erfolgt (und eigentlich 
nichtmal dann). Es kann vorkommen, dass Pakete bei der Übertragung 
verdoppelt werden, und das ist durchaus keine rein theoretische 
Möglichkeit, sondern das habe ich schon einige Male auch selbst real 
gesehen.

Mit Sequenznummern braucht sich der Empfänger keine Liste der letzten 
Pakete merken, sondern er muss nur die aktuelle Sequenznummer 
speichern. Er muss dann bei einem empfangenen Paket nur die Nummer des 
Paketes mit seiner eigenen aktuellen Nummer vergleichen:

- Ist sie kleiner oder gleich der eigenen, dann darf das Paket
  nicht erneut bearbeitet werden, es muss aber trotzdem ein ACK
  gesendet werden.
- Ist sie exakt eins grösser als die eigene, wird das Paket
  bearbeitet, ein ACK gesendet und die eigene Nummer um eins erhöht.
- Ist sie mehr als eins grösser als die eigene, wird das Paket
  einfach verworfen, der Sender sendet das dann ja später erneut,
  und bis dahin sind dann hoffentlich auch die fehlenden Pakete
  "dazwischen" eingetroffen.

Das Verwerfen von Paketen im letzten Fall oben führt zu suboptimalem 
Verhalten, wenn die Reihenfolge der Pakete unterwegs geändert wurde, da 
Pakete verworfen werden, die eigentlich korrekt angekommen sind. In sehr 
vielen Fällen tritt das in der Praxis aber nur selten auf, weshalb es 
meist nicht lohnt, den Zusatzaufwand dafür zu betreiben. Der Aufwand 
wäre im wesentlichen so hoch, dass man auch gleich TCP benutzen könnte.

Was du noch brauchst ist ein Synchronisationsmechanismus, mit dem am 
Anfang der Kommunikation (oder dann wenn zuviele Pakete zwischendurch 
verloren gehen, so dass der Sender irgendwann aufgibt) die 
Sequenznummern von Sender und Empfänger auf den gleichen Stand gebracht 
werden. Am besten schaust du dir dazu mal den Three-Way-Handshake von 
TCP an.

Andreas

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ergänzung: auch für den Sender bringt dieses Sequenznummern-Verfahren in 
einigen Fällen eine Verringerung des Aufwandes mit sich.

Angenommen, das letzte ACK hatte die Nummer 4, die Zähler bei Sender und 
Empfänger stehen also beide auf 4. Jetzt werden die Pakete 5, 6, 7 und 8 
gesendet, vom Empfänger bearbeitet und geACKt, es gehen jedoch die ACKs 
5, 6 und 8 verloren.

Der Sender kann jetzt, wenn er das ACK 7 empfängt, nicht nur das Paket 7 
aus seiner Retransmit-Liste entfernen, sondern auch die Pakete 5 und 6, 
da er weiss, dass der Empfänger nur dann das ACK 7 senden würde, wenn er 
5 und 6 schon erfolgreich empfangen hat. Der Sender muss also nur das 
Paket 8 erneut senden.

Andreas

Autor: Jochen Fe. (jamesy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit einer Implementierung des AX-25-Protokolls?

Autor: Frank Esselbach (Firma: Q3) (qualidat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Infos, ich werde mal versuchen, etwas draus zu machen. 
Sequenznummern klingen vernünftig. Allerdings muss ich die wohl für 
jeden Clienten einzeln führen, wenn es mehrere an einem Server sind.
Was mache ich bei Zähler-Überlauf (z.B. Integer mit 4 Byte)? Aber wenn 
der Server nach der gleichen Methode zählt, geht es ihm genau so und 
dann stimmts ja wieder ...

Frank

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Esselbach schrieb:
> Allerdings muss ich die wohl für
> jeden Clienten einzeln führen,

Sinnvollerweise behandelt ein Server jeden Client logisch getrennt in 
einer eigenen Session.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.