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?