Ich schreibe gerade eine Software die den Datentransfer zwischen zwei uC steuert. Diese soll sicherstellen, dass die Daten sicher empfangen wurden. Daher sendet der Empfänger eine Bestätigung zurück zum Sender. Bleibt diese aus, gibt es zwei Gründe: Entweder der Empfänger hat die Daten nicht erhalten, oder die Bestätigung ging verloren. Eine Bestätigung der Bestätigung macht wenig Sinn, da man das Problem bleibt und man dieses Spiel unendlich lange fortsetzen könnte. Hat jemand eine Idee wie ich das Problem lösen könnte, oder ist mein kompletter Ansatz schon mal der falsche Weg ?
Kommt die Bestätigung nicht, werden die Daten erneut gesendet (evtl. mit Wiederholungs-Kennung). Der Empfänger kann dann entscheiden, ob er die Daten verwirft (weil schon erhalten) und bestätigt, oder übernimmt (weil noch nicht korrekt erhalten) und bestätigt. Wurde n mal eine Wiederholung gesendet, ohne dass eine Betätigung kam, ist der Kanal defekt -> ERROR.
Man könnte jedem Datenpaket eine eindeutige Nummer zuweisen, ähnlich wie bei TCP: http://www.freesoft.org/CIE/Course/Section4/9.htm
Meine Meinung zur einfachsten Lösung: Je nachdem wieviele Daten Du sendest (Buslast) würde ich im Empfänger einfach falsche Daten verwerfen (Checksumme, Parität) und den Sender die Daten dauernd wiederholen lassen. Das spart eine Menge Protokoll. Mit Bestätigungen würde ich erst dann arbeiten wenn es nicht mehr anders geht da diese ja auch selbst wieder fehlerhaft sein kann. Die Sicherheit deiner Übertragung hängt u.a. davon ab wie der Empfänger falsche Telegramme erkennt. Grüße, olfi
@Olfi > und den Sender die Daten dauernd wiederholen lassen. Das spart eine > Menge Protokoll. und wie lange soll wiederholt werden???
" und wie lange soll wiederholt werden??? " dreimal. Der Empfänger sollte aber durch ein einzelnes Zeichen anzeigen, ob er gültige '!' oder falsche '?' Daten bekommen hat. Hierzu braucht der Sender ein Timeout, in welcher Zeit die Quittung kommen muß.
Mal eine ganz andere Sichtweise: Brauchst Du überhaupt eine "sichere" Übertragung? Also, was passiert, wenn der Sender merkt, dass der Empfänger bestimmte Daten vermeintlich nicht empfangen hat? Muss er dann irgendetwas kritisches ausschalten? Wenn nein, kannst Du Dir das ganze Theater mit der Sicherung sparen. Du hast sowie schon schon selbst erkannt, dass Du nie ein 100% sicheres Protokoll entwickeln kannst. Viel wichtiger ist es, den Empfänger und das Protokoll so zu bauen, dass er Empfänger durch Datenmüll nicht aus dem Tritt kommt und sich aufhängt. Und dann noch einige praktische Erfahrungen: Der Aufwand um den Datenverkehr auf einer RS232-Leitung zu sichern, lohnt nicht. Wenn Du auf dem Kabel regelmäßig Fehler hast, dann hast Du noch ganz andere Probleme. Früher, in der Vor-Internetzeit, wurde die Mailboxen (fast) alle mit 8n1 betrieben. Also keine Parity auf der Leitung. Hat in der Praxis nie Probleme gemacht.
Danke für die Tips. Es handelt sich um eine lange Leitung, und daher können (wenn es aber auch vermutlich nie vorkommen wird) Störungen vorkommen. Wenn die Leitung kaputt ist, geht garnichts mehr. Das ist dann auch OK. Das einzige was nicht passieren darf ist, dass einzelne Bytes verloren gehen, oder falsch übertragen werden. Daher ist die Nummerierung warscheinlich das beste.
Genau das ist der springende Punkt. Wenn nicht viele Daten übertragen werden müssen, geh mit der Geschwindigkeit möglichst weit runter. Zusätzlich kannst Du dann noch die Datenpakete mit Prüfdaten (z.B. CRC) versehen und die Pakete durchnummerieren. Und evtl. grundsätzlich doppelt oder dreifach senden. Evtl. auch ineinander geschachtelt. Also etwa so: 1 2 1 3 2 4 3 5 4 6 5 7 6 8 7 9 8 9 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ Die Pfeilchen kennzeichnen immer die Haupt-Zeitschlitze, also der feste Abstand bei der ein Datenpaket das erste mal verschickt wurde. Wenn Du es noch ganz edel machen willst, baust Du auch noch eine Vorwärtsfehlerkorrektur ein. So dass der Empfänger bei einzelnen Bitfehlern den Fehler selbstständig erkennen und reparieren kann. Wenn Du Dich generell mit Datenübetragung beschäftigen willst, empfehler ich folgenden Klassiker: http://www.amazon.de/exec/obidos/ASIN/0130384887
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.