On 12/10/2012 6:12 PM, Bill Hoffman wrote:
>
> That is indeed very curious. Can you investigate how they differ and if
> there's a pattern over repeated test runs (and failures) ?

OK, I ran this a few times and found that the files differ at different
spots:

-rwx------+ 1 hoffman Domain Users 54777435 Dec 11 11:05 b.t.gz.b1 - failed
-rwx------+ 1 hoffman Domain Users 54787595 Dec 11 11:05 b.t.gz.b2 - failed
-rwx------+ 1 hoffman Domain Users 54780623 Dec 11 11:06 b.t.gz.b3 - failed
-rwx------+ 1 hoffman Domain Users 54787655 Dec 11 11:04 b.t.gz.worked

Each of the failures goes bad at a different point in the file:

$ ./diff.exe b.t.gz.b1 b.t.gz.worked
files differ at byte 12225789

$ ./diff.exe b.t.gz.b2 b.t.gz.worked
files differ at byte 36623849

$ ./diff.exe b.t.gz.b3 b.t.gz.worked
files differ at byte 42033149

The source for that diff program is as follows:
  int count =0;
   while(fin && fin2)
     {
     char fb, f2b;
     fin.read(&fb, 1);
     fin2.read(&f2b, 1);
     if(fb != f2b)
       {
       std::cerr << "files differ at byte " << count << "\n";
       return 0;
       }
     count++;
     }

This makes me think it just misses some bytes in the middle which is
what causes the server to say that it is done, because it is. The
client just missed a chunk in the middle somehow. The bytes that get
missed are random with no pattern.

I ran wireshark again and found something possibly interesting...
Around the same percentage of the transfer as to the point where the
data is bad in the file. There are some errors. I can send the pcapng
file with the extraction if it helps. However, here are the interesting
parts. Everything is normal until this part:

5 0.000047000 192.168.1.133 192.168.1.236 TCP 54 [TCP ACKed unseen
segment] 46463 > http [ACK] Seq=1 Ack=11681 Win=256 Len=0
6 0.000060000 192.168.1.236 192.168.1.133 HTTP 1514 Continuation or
non-HTTP traffic
... same as above until here:

12 0.000073000 192.168.1.133 192.168.1.236 TCP 66 [TCP Dup ACK 5#1]
46463 > http [ACK] Seq=1 Ack=11681 Win=256 Len=0 SLE=4381 SRE=5841

13 0.000082000 192.168.1.133 192.168.1.236 TCP 66 [TCP Dup ACK 5#2]
46463 > http [ACK] Seq=1 Ack=11681 Win=256 Len=0 SLE=5841 SRE=7301

15 0.000098000 192.168.1.133 192.168.1.236 TCP 66 [TCP Dup ACK 5#4]
46463 > http [ACK] Seq=1 Ack=11681 Win=256 Len=0 SLE=8761 SRE=10221

14 0.000090000 192.168.1.133 192.168.1.236 TCP 66 [TCP Dup ACK 5#3]
46463 > http [ACK] Seq=1 Ack=11681 Win=256 Len=0 SLE=7301 SRE=8761

15 0.000098000 192.168.1.133 192.168.1.236 TCP 66 [TCP Dup ACK 5#4]
46463 > http [ACK] Seq=1 Ack=11681 Win=256 Len=0 SLE=8761 SRE=10221
16 0.000111000 192.168.1.133 192.168.1.236 TCP 66 [TCP Dup ACK 5#5]
46463 > http [ACK] Seq=1 Ack=11681 Win=256 Len=0 SLE=10221 SRE=11681

Then at the end the FIN is sent and the FIN/ACK stuff goes on for a bit
until it gives up.

Ideas?

-Bill

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-12-11