Was ich mich schon seit längerem frage: Mithilfe von Kanalkodierung kann man doch Daten so kodieren, dass etwaige Übertragungsfehler zu einer gewissen Wahrscheinlichkeit erkannt werden, woraufhin man das Datenpaket ggf. reparieren oder einen Retransmit beantragen kann. Aber das ist der Punkt.. Übertragungsfehler können doch nur zu einer gewissen Wahrscheinlichkeit erkannt werden und es muss immer zwischen Wahrscheinlichkeit der Erkennung eines Fehlers und der bestmöglichen Nutzung der zur Verfügung stehenden Datenrate abgewogen werden. Das bedeutet, für eine 100%ige Fehlererkennungsrate müssten zu den eigentlichen Daten unendlich viele Zusatzinformationen gesendet werden. Ist ja auch intuitiv. Angenommen ich verwende Repetition-Codes und sende jedes Datenpaket einfach doppelt, dann besteht eine gewisse Wahrscheinlichkeit, dass sich der selbe Übertragungsfehler gleich in beide Pakete an der gleichen Stelle einschleicht und somit unerkannt bleibt. Sende ich das gleiche Paket aber 1000 mal ist die Wahrscheinlichkeit, dass alle Datenpakete mit dem selben Übertragungsfehler beeinflusst sind sehr gering, aber immer noch nicht 0. D.h. bei genügend Datendurchsatz kommt es eben alle paar Jahre vielleicht mal vor, dass ein solcher Fehler tatsächlich auftritt. Jetzt stellt man sich mal vor, es handle sich um einen Übertragungsfehler zwischen Bankkonten und eine Verkettung ungünstiger Ereignisse führt nun dazu, dass der zu transferierende Betrag von 1 Millionen auf 10 Millionen verändert wird, ohne dass dieses von Fehlererkennungsmechanismen bemerkt werden kann, was sehr unwahrscheinlich ist, aber aufgrund der immensen Summe an weltweit pro Sekunde durchgeführtne Transaktionen ja mal vorkommen kann. Wie wird sichergestellt, dass das dennoch nicht passiert? Ist Kanalkodierung so gut, dass mit nur wenig mehr Daten die Wahrscheinlichkeit eines nichterkannten Fehlers schon auf abartig kleine Werte gesenkt werden kann? Ist die übliche Dimensionierung der Kanalkodierung so gewählt, dass Fehler tatsächlich nur alle hunderttausend Jahre mal auftreten? Wie wird das dimensioniert? Oder liegt es daran, dass die Netzte, über die derart sensible Daten übertragen werden hinreichend rausch- und kollisionsfrei sind? lg
Paul H. schrieb: > was sehr > unwahrscheinlich ist, aber aufgrund der immensen Summe an weltweit pro > Sekunde durchgeführtne Transaktionen ja mal vorkommen kann. Nein. Bevor Du es schaffst (auch mit größter Mühe) eine 256-Bit Prüfsumme kollidieren zu lassen wird unsere Sonne bereits verglüht sein und Du wirst genug Entropie erzeugt haben um den ganzen Sektor hier dunkel und kalt zu machen. 256-Bit Prüfsummen sind Stand der Technik wenn es auf Integrität der Daten ankommt.
Paul H. schrieb: > Ist Kanalkodierung so gut, dass mit nur wenig mehr Daten die > Wahrscheinlichkeit eines nichterkannten Fehlers schon auf abartig kleine > Werte gesenkt werden kann? Eine gute Prüfsumme ist effizienter als die bloße Wiederholung der Nachricht: https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction > By adding t check symbols to the data, a Reed–Solomon code can > detect any combination of up to t erroneous symbols, or correct up > to ⌊t/2⌋ symbols. > Ist die übliche Dimensionierung der Kanalkodierung so gewählt, dass > Fehler tatsächlich nur alle hunderttausend Jahre mal auftreten? Ja (wenn der Designer es nicht verkackt hat). > Wie wird das dimensioniert? Oder liegt es daran, dass die Netzte, über > die derart sensible Daten übertragen werden hinreichend rausch- und > kollisionsfrei sind? Siehe oben. Wenn auf einem bestimmten Kanal Fehler häufiger sind, muss man halt mehr Prüfsummen übertragen, um eine bestimmte Fehlerhäufigkeit zu erhalten. In der Praxis kann man die Fehlerrate aber oft nicht voraussagen. Viele Protokolle definieren eine Prüfsumme fester Größe (z.B. 32-Bit-CRC bei Ethernet), und wenn zu viele Fehler auftreten, hat man halt Pech gehabt.
Paul H. schrieb: > Wie stellt man 100%ige Datenintegrität sicher? gar nicht! Es bleibt immer ein Restrisiko. 100 % Sicherheit widerspricht dem 3. Hauptsatz der Thermodynamik.
google mal: - CRC - Hamming Abstand - Mean time between failure (MTBF) und mach dir selbst gedanken ab wieviel % sicherheit bzw. wieviel Jahren MTBF man von "sicher genug" sprechen kann. Variiert natürlich von Anwendungsfall zu Anwendungsfall. Außerdem laufen ja nicht nur retransmits und Kanalkodierungen bei bidirektionalen Übertragungsverfahren sondern auch Kanalschätzungen. DH dass sowohl Übertragungsart (zB Modulation, Datenrate) als auch Kodierung zur Laufzeit angepasst werden können (-> siehe jedes moderne Übertragungsverfahren für Mobiles ab 2.5G)
Wiederholung der Nachricht ist die wohl ineffizienteste Methode überhaupt. Ein Verfahren mit theoretischen 100% Sicherheit existiert nicht. Du musst also definieren, welche Sicherheit dir ausreicht. Relevant ist auch der Charakter der auftretenden Fehler. Sind das wild verstreute Einzelbitfehler oder eher Bursts? Ist nur Integrität wichtig oder auch Korrektur interessant?
Theoretisch sicher ist das Übermitteln der Nachricht mit Prüfsumme, das Antworten mit dieser Nachricht und einem OK dran und neuer Prüfsumme und das erneute Senden der Nachricht mit OK und DoppelOK dran und neuer Prüfsumme. Quasi wie ein Mensch beim Funk.
Lukas T. schrieb: > Theoretisch sicher ist das Übermitteln der Nachricht mit Prüfsumme, das > Antworten mit dieser Nachricht und einem OK dran und neuer Prüfsumme und > das erneute Senden der Nachricht mit OK und DoppelOK dran und neuer > Prüfsumme. Quasi wie ein Mensch beim Funk. Im Fehlerfall könnte das "Nein nein, nicht OK!" am Ende dennoch mit geringer Wahrscheinlichkeit als "OK!" verstanden werden
Paul H. schrieb: > Im Fehlerfall könnte das "Nein nein, nicht OK!" am Ende dennoch mit > geringer Wahrscheinlichkeit als "OK!" verstanden werden Eigentlich nicht, da im Fehlerfall nicht die Nachricht zurück gesendet wird, sondern schlicht die Fehlermeldung. 100% Sicherheit gibt es nicht. Aber für Aribags und ABS im Auto reicht fast schon CRC alleine (gibt aber noch circa vier weitere Mechanismen). Zurücksenden und Vergleichen ist (meiner Meinung nach) so nahe an 100% wie es geht, sofern die üblichen Mechanismen mit Checksumme und so weiter ebenfalls angewandt werden.
Paul H. schrieb: > Jetzt stellt man sich mal vor, es handle sich um einen > Übertragungsfehler zwischen Bankkonten und eine Verkettung ungünstiger > Ereignisse führt nun dazu, dass der zu transferierende Betrag von 1 > Millionen auf 10 Millionen verändert wird Die grössten Unschärfefaktoren sind immer noch im Kopp. bei einer "Papierüberweisung" muss man ziemlich genau auch noch nach 5 Jahren die damals hinterlegte Unterschrift reproduzieren können. bei Abweichung wird die Überweisung zurück gestellt. Bei telefonischem oder computerisiertem Zahlungsverkehr kräht da kein Schwein nach, weil... es funktioniert. Wenn man da jetzt'n Zahlendreher reinbekommt -wir sind wieder bei der Unschärfe im Hirn, kann ein technischer Automatismus da natürlich auch nix machen.
● J-A V. schrieb: > Wenn man da jetzt'n Zahlendreher reinbekommt Geht aber nur noch beim Überweisungsbetrag. Die Kontonummer hat "IBAN" sei Dank eine Prüfziffer, mit der sich Zahlendreher finden lassen. Probier's selbst aus: http://www.iban-rechner.de/iban_validieren.html
1 | DE05 7000 0000 0070 0015 06 - wird akzeptiert |
2 | DE05 7000 0000 0070 0015 60 - wird nicht akzeptiert |
3 | DE05 7000 0000 0700 0015 06 - wird nicht akzeptiert |
(Die Kontonummer ist die eines Finanzamtes, es ist also müßig, irgendwelche Spielereien damit anzustellen)
Schon, aber da der Überweisungsbetrag nunmal eine willkürliche Größe ist, ist es irgendwie ziemlich schwierig, den mit einer Prüfsumme zu sichern. Auf EC-Schecks konnte/musste man den Betrag in Worten ausschreiben, ein solches Verfahren könnte vielleicht etwas Sicherheit bringen, aber dürfte andererseits auch viele Leute überfordern. Bedenkt man, daß es Bundesländer gibt, in denen die Bewohner nicht "fünfzehn" oder "fünfzig" sagen können ... möcht ich mir nicht ausmalen, was die Texterkennungssysteme da zu kämpfen haben.
Rufus Τ. F. schrieb: > ist es irgendwie ziemlich schwierig, den mit einer Prüfsumme zu > sichern. Warum das denn? Es wird ein Betrag eingegeben. Dieser wird ja wohl als Datenwort übermittelt. Die "Zieladresse" sagt nix dazu? woher weiss denn sonst ein System dass der Absender eine "01100110" gesendet hat und wie kann man sicherstellen, dass am anderen Ende auch eine "01100110" und keine "01100111" ankommt? Das sind doch längst uralte Techniken. Ausgerechnet im Banking implementiert man das nicht? dann sollte man das schnell mal ändern. oder sonst eine Beitragsbestätigung als 2. Fenster, wie die Passwortbestätigung bei der Anmeldung für ein Forum, neue EmailAdresse etcpp. so schwer kanns ja nicht sein.
● J-A V. schrieb: > Warum das denn? > Es wird ein Betrag eingegeben. Dieser wird ja wohl als Datenwort > übermittelt. Die "Zieladresse" sagt nix dazu? Das ist die Frage, an welcher Stelle das geschieht. Bei der IBAN werden Fehleingaben in das Überweisungsformular abgefangen, beim Betrag ist das prinzipbedingt unmöglich. Daß die Daten des Überweisungsformulars, so wie sie eingegeben wurden dann fehlerfrei transportiert werden, das ist sichergestellt. Aber die Eingabe in das Formular kann nur endlich abgesichert werden. Ein Zahlendreher im Betrag, ein zu großer Betrag - das lässt sich nur mit Kontrolle seitens des Absenders überwachen, d.h. mit Korrekturlesen vor dem Absenden des Überweisungsauftrags. Was meinst Du mit "Zieladresse"? Stellst Du Dir vor, daß der Empfänger einer Überweisung vor Absenden der Überweisung seiner Bank die erwartete Überweisung bekanntgibt?
Rufus Τ. F. schrieb: > Was meinst Du mit "Zieladresse"? der Ort, Das Gerät etc, wo die übermittelten Daten hin sollen.
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.