wicked_one hat geschrieben:packetloss, langsamer download, verbindungsabbrüche.
und deswegen garantiert mir TCP immer noch eine korrekte übertragung, Fastpath oder Interleaving spielt da keine Rolle. Und deshalb ist mir nicht klar warum du Fastpath in Verdacht hast...
weil durch Fastpath die Korrektheit des Paketes nicht Sichergestellt wird, d.h. es könnte auch ein fehlerhaftes Paket ankommen und irgendwie durch die Fehlererkennung schlüpfen.
Beispiel:
Prüf-Verfahren, bei dem nur die Quersumme aller Bits gebildet wird.
Datenwort: 0101010101
Prüfsumme: 5
Wenn das Dantwort irgendwie durch einen Fehler verändert wird, zB auf
Datenwort: 0101010110
ist die Prüfsumme auch wieder 5.
Das sagt jetzt natürlich nichts über die Technik aus, aber Fastpath ist nicht umsonst (bei einer ordentlichen Leitung) wesentlich performanter, weil die Fehler-Überprüfung "fast" ausgeschalten wird.
und deswegen garantiert mir TCP immer noch eine korrekte übertragung, Fastpath oder Interleaving spielt da keine Rolle.
Das is allerdings richtig, TCP arbeitet sowohl mit FAstpath und Interleaving gleich, allerdings kommt es auch bei TCP vor, dass kaputte Pakete übertragen UND bestätigt werden - ich habs zumindest desöfteren erlebt.
ben hat geschrieben:Hallo!
Ich hab das Problem, dass die Prüfsumme von großen Downloads oft nicht stimmt (nicht immer aber oft). Kann es sein, dass FastPath daran schuld ist, obwohl TCP eine Fehlerkorrektur implementiert hat? Es sind Downloads vom Inode-FTP Server (suse.inode.at, ubuntu.inode.at, fedora.inode.at etec.)
Soll ich wieder auf Interleaving wechseln, oder ist es ausgeschlossen dass gerade FastPath solche Fehler verursacht?
lg
Eine Frage: Benutzt du einen Proxy-Server?