Fehlerkorrigierender Code

Erkennung über übliche CRC Verfahren. Oder Hash Funktionen.
Korrektur über redundante Daten. Müsste aber auch suchen was für 
Protokolle da existieren und am günstigsten sind.
Dazu müsstet ihr aber erst mal spezifizieren, welche Arten von Fehlern 
noch korrigiert werden sollen.
1 Bit pro Byte, 2 Bit pro Byte, einzelne Bytes pro Paket, ...
Eventuell auch mal bei fehlerkorrigierendem Ram oder bei RAID anschauen 
wie die es machen.

http://de.wikipedia.org/wiki/BCH-Code

Udo hat Recht: Es ergibt wenig Sinn, ohne eine Vorstellung von Art und 
Dimension auftretender Fehler jetzt alle möglichen Verfahren in die 
Runde zu werfen. So ist es beispielsweise ein erheblicher Unterschied, 
ob es eher Einzelbitfehler oder eher Burstfehler sind, oder ob man 
aufgrund des UDP-Verfahrens ohnehin immer ganze Frames abschreiben muss.

So sind ja UDP-Frames im Ethernet durch eine CRC abgesichert. Wenn die 
Fehler also auf dieser Übertragungsebene stattfinden, dann muss man 
immer komplette Frames abschreiben und sich Gedanken darüber machen, wie 
man komplette Frames ersetzt.

Und ihr seid auch sicher daß UDP der richtige Weg ist? (TCP?)

Information-Hiding bringt dich hier nicht weiter. Mit normal betriebenen 
Ethernet-Interfaces sind defekte Frames nicht zu retten, egal ob 1 Bit 
futsch ist oder alle.

Wenn ich Daten direkt über physikalische Leitungen übertrage (per SPI, 
I2C oder sowas), dann machen fehlerkorrigierende Kodierungen Sinn.

Bei Ethernet / UDP nicht. -> OSI-Schichtenmodell. Siehe auch Peter IIs 
Kommentar:

Peter II schrieb:
> wie kann das sein? damit sollte der die CRC auf der MAC ebende schon
> falsch sein und damit das Packet überhaupt nicht ankommen.

Das heisst mit eurer Fehlerkorrektur würdet ihr einfach nur Ressourcen 
verschwenden, ein bisschen Rechnen, aber ohne Sinn. Die Korrektur wird 
nie anspringen.

Hamming schrieb:
> Ja, wir können nur eine begrenzte Anzahl von Daten übertragen und
> möchten (trotz nicht vermeidbarer Störungen) möglichst viele fehlerfreie
> Daten erhalten.

Es wäre klüger, mal etwas über die Aufgabenstellung und die 
Übertragungsstrecke zu verraten.

A. K. schrieb:
> Übertragungsstrecke

Wahrscheinlich Ethernet.

Hamming schrieb:
> Welchen Sinn macht dann die Prüfsumme in UDP-Paketen?

Die filtert fehlerhafte Paket heraus, so dass die selbstgebaute 
Fehlerkorrektur des TOs nichts zu korrigieren hätte.

Hamming schrieb:
> Wir können aber versuchen, statt die fehlerhaften Pakete wegschmeißen zu
> lassen, diese Pakete zu retten.

Dann ist das kein UDP mehr, sondern ein selbstgestricktes IP-Protokoll.
Im übrigen können UDP-Pakete an jedem Netzwerkknoten aufgrund 
fehlerhafter Prüfsumme verworfen werden. Das muss nicht zwingend am 
letzten (Ziel-)knoten passieren.

Hamming schrieb:
> Das verstehe ich nicht. Welchen Sinn macht dann die Prüfsumme in
> UDP-Paketen?

UDP ist einen Ebene oberhalb von Ethernet und auch mit anderen 
Übertragungsarten einsetzbar. Die optionale(!) UDP-Checksum ist keine 
effektive Sicherung gegen Übertragungsfehler, sondern nur eine grobe 
Konsistenzprüfung.

Hamming schrieb:
> Han sel schrieb:
>> Im übrigen können UDP-Pakete an jedem Netzwerkknoten aufgrund
>> fehlerhafter Prüfsumme verworfen werden.
>
> Stimmt das wirklich?

Eine fehlerhafte UDP-Prüfsumme ist nicht das Gleiche wie eine nicht 
vorhandene UDP-Prüfsumme.

Hamming schrieb:
> Udo Schmitt schrieb:
>> Und ihr seid auch sicher daß UDP der richtige Weg ist? (TCP?)
>
> Ja, wir können nur eine begrenzte Anzahl von Daten übertragen und
> möchten (trotz nicht vermeidbarer Störungen) möglichst viele fehlerfreie
> Daten erhalten.

Ja und? Was sollte da UDP an Vorteilen gegenüber TCP bieten?
UDP:
verbindungslos
keine Reihenfolge garantiert
Empfang von Daten nicht sicher
Pakete werden überall hingeschickt

TCP ist verbindungsorientiert, voll duplexfähig, Reihenfolge ist 
gesichert ...
hat also nur Vorteile.

Kling für mich wieder mal nach: "Ich will das aber mit dem Mittel A 
machen, auch wenn Methode B oder C besser sind"
Ich mag mich ja täuschen...

Hamming schrieb:
> Wir können aber versuchen, statt die fehlerhaften Pakete wegschmeißen zu
> lassen, diese Pakete zu retten.

Nur wenn du es schaffst, sie aus dem Ethernet-Controller überhaupt raus 
zu fischen.

Udo Schmitt schrieb:
> Ja und? Was sollte da UDP an Vorteilen gegenüber TCP bieten?

TCP benötigt im Prinzip mehr Pufferspeicher. Offiziell mindestens 2 
Frames, sonst wirds hässlich.

Nur hat er das Problem dann natürlich an anderer Stelle. Jedes 
Verfahren, das verlorene UDP Frames retten kann, hat ein ähnliches 
Problem.

Es ist doch eigentlich so wie Udo Schmitt es schreibt.

UDP ist per Definition für schnelleren Datenverkehr, dafür mit einigen 
Nachteilen bei der Sicherheit und Stabilität der Datenübertragung 
erfunden. UDP-Light auch...

TCP ist dann das entsprechende Gegenstück dazu.

Also sollte man überlegen welches Werkzeug man für welchen Zweck 
einsetzt.

Mit einem Flammenwerfer bekommt man ein BGA auch gelötet. Ob es sinnvoll 
ist muss jeder selbst entscheiden.

was du eigentlich machen möchtest.

A. K. schrieb:
> TCP benötigt im Prinzip mehr Pufferspeicher. Offiziell mindestens 2
> Frames, sonst wirds hässlich.

Ok, ich habe das nicht im Kontext zu einem µC mit wenig Memory gesehen, 
mein Fehler :-).
Aber wie du gesagt hast, wenn er die Vorteile die TCP bietet von Hand 
drum herum stricken will, dann braucht er den Speicher genauso.

Rene Schube schrieb:
> UDP ist per Definition für schnelleren Datenverkehr,

Das ist eine mögliche Begründung von UDP, aber nicht die einzige. Bei 
NFS ist aber mittlerweile auch TCP recht verbreitet.

Auch bei 1:N Verbindungen kann UDP sinnvoller sein als TCP, unabhängig 
vom Tempo.

Wenn der IP-Layer auf einem Medium mit geduldigem Retry sitzt, dann kann 
TCP tödlich sein, weil bei zeitweiligen aber vom IP-Layer nicht 
identifizierbaren Ausfällen des Mediums sonst die TCP-Retries den Kanal 
regelrecht verstopfen können (ein Fall aus der Praxis, da gab es 3 
Retry-Layer übereinander, je tiefer desto geduldiger - das war falsches 
Design von A bis Z).

UDP kann auch dann (hier?) erforderlich sein, wenn es wichtiger ist, den 
neuesten Stand der Daten zu haben, als wirklich alle Daten zu haben.

Zwei einfache Beispiele dafür, wie man Blöcke fester Länge ohne grossen 
Rechenaufwand redundant übertragen kann, wenn jeder einzelne Block 
bereits per CRC gesichert ist - hier also einem UDP-Frame im Ethernet 
entspricht. Sie benötigen aber Puffer für einige Blöcke:

(1) N Blöcke übertragen und währenddessen einen weiteren Block aufbauen, 
der ein XOR-Summe über die Daten der Blöcke bildet. Also Byte 0 vom 
XOR-Block ist Byte 0 vom ersten Block XOR Byte 0 vom zweiten Block usw. 
Diesen XOR-Block anschliessend senden. Innerhalb dieser N+1 Gruppe ist 
ein Block rekonstruierbar.

(2) Wenn grössere Burst-Fehler wahrscheinlich sind (Funkstrecke, 
Bandspeicher) und daher oft zwei aufeinander folgende Blöcke defekt 
sind, dann kann man das eben beschriebene Verfahren modifizieren und die 
geraden und ungeraden Blöcke in zwei XOR-Blöcken getrennt akkumulieren. 
Dann sind zwei aufeinander folgende Blöcke immer rekonstruierbar.