Bei einer UDP-Übertragung möchten wir Übertragungsfehler erkennen und nach Möglichkeit auch korrigieren. Wir suchen deshalb momentan ein oder mehrere gute Fachbücher und Webseiten, die zu diesem Thema praxisrelevante Informationen liefern. Über entsprechende Tipps würden wir uns sehr freuen. Schon mal Danke für alle Hinweise :-)
das Hauptproblem bei UDP ist aber nicht das packet defekt sind, sondern das packete in der falschen reihenfolge oder doppelt oder überhaupt nicht ankommen. Wenn nichts ankommt kannst du auch nicht korrigieren. Fehlerkorrektur hat mit UDP recht wenig zu tun, eventuell mal getrennt danach suchen.
Peter II schrieb: > Fehlerkorrektur hat mit UDP recht wenig zu tun, eventuell mal getrennt > danach suchen. Danke für den Hinweis, Du hast natürlich vollkommen recht. Uns interessiert an dieser Stelle in erster Line die Vorgehensweise zur Fehlererkennung und -korrektur.
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.
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.
@ A. K. Überwiegend haben wir es mit einzelnen Bitfehlern zu tun. Burstfehler kommen aber auch vor. Es ist ganz klar, dass wir nicht jedes UDP-Paket retten können. Trotzdem freuen wir uns über alle Daten, die (direkt oder restauriert) fehlerfrei ankommen.
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.
Hamming schrieb: > Überwiegend haben wir es mit einzelnen Bitfehlern zu tun. Burstfehler > kommen aber auch vor. wie kann das sein? damit sollte der die CRC auf der MAC ebende schon falsch sein und damit das Packet überhaupt nicht ankommen. dann gibt es scheinbar sogar eine Prüfsumme im UDP selber: http://de.wikipedia.org/wiki/User_Datagram_Protocol wenn ihr bitfehler habt, dann habt ihr eventuell auf dem gerät defekten RAM.
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.
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.
Han sel schrieb: > Das heisst mit eurer Fehlerkorrektur würdet ihr einfach nur Ressourcen > verschwenden, ein bisschen Rechnen, aber ohne Sinn. Die Korrektur wird > nie anspringen. Das verstehe ich nicht. Welchen Sinn macht dann die Prüfsumme in UDP-Paketen?
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.
Han sel schrieb: > Die filtert fehlerhafte Paket heraus, Wir können aber versuchen, statt die fehlerhaften Pakete wegschmeißen zu lassen, diese Pakete zu retten.
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.
Han sel schrieb: > Im übrigen können UDP-Pakete an jedem Netzwerkknoten aufgrund > fehlerhafter Prüfsumme verworfen werden. Stimmt das wirklich? Bei wikipedia ist zu lesen: "Die Prüfsumme ist optional, wird aber in der Praxis fast immer benutzt, falls nicht, wird diese auf „0” gesetzt."
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.
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.
A. K. schrieb: > UDP kann auch dann (hier?) erforderlich sein, wenn es wichtiger ist, den > neuesten Stand der Daten zu haben, als wirklich alle Daten zu haben. Das ist der Fall. Bei nicht korrekt übertragenen Daten würden die fehlenden Daten durch die zuletzt gültigen Daten ersetzt werden.
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.
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.