Re: Http get commands return a bad results.
:I first had the problem with cups-1.1.22-source.tar.bz2 when updating
:the cups port. I had corrupted files from several ftp sites and I
:remember that the file sizes were different each time.
:
:I just used 'fetch' to get the same file and it is corrupted once again,
:but the filesize is correct this time. I'd be happy to send you the
:file but I have no ftp server available to me. May I upload it? (8MB)
:
:...
:> sysctl net.inet.tcp.sack=0
:
:I just tried this and, with a sample size of 1 try, it works fine. I
:changed the value of sack while my newsreader was open to this group
:and it got very confused -- I had to close the newsreader and reopen
:it before I could post this. Dunno if it's related to sack or not.
Leave SACK turned off (set it to 0 in /etc/sysctl.conf) and run a bunch
more tests and report back.
If you consistently get zero corruption with SACK turned off then we
know it is SACK. Considering the experimental nature of SACK I am not
surprised, if that turns out to be what it is I will simply make the
default be off instead of on until Jeff tracks the issue down. It could
be a bug in our SACK code or in the originating machine's SACK code.
Since your NFS worked (UDP packets) and local FS copies worked, about the
only thing it can be is TCP and the only major change we've made to
TCP recently was Jeff's SACK commit.
Jeff and I both are probably kicking ourselves for not checking data
integrity issues :-). My guess is that you were downloading from LINUX
driven sites which were running SACK too.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 5 之 16 篇)：