On 2 Feb 2006, at 17:15, Simon Forster wrote: > > Can someone with a better understanding of the TCP networking > protocol than me tell me what should happen if machine B is > receiving a bunch of data, sending TCP ACKs quite cheerfully and > then machine A doesn't receive one of the ACKs? Who should jump in > next? My layman view is that machine A should resend its previous > bunch of data, to which machine B will again send an ACK... My initial reaction to this is that "of course, that's right" but a glance at RFC1122 suggests the isn't actually so simple that it can be expressed that way. Nevertheless I think this is an extremely good basis for argument. > A bit more detail for those interested: We're accepting (on machine > B) an HTTP file upload from a telco (sent by machine A) - > unfortunately, frequently the uploaded data is truncated > (particularly large files during busy times). I've looked at output > from tcpdump, and can quite clearly see the data coming in from > machine A and ACKs going out fro machine B after every couple of > datagrams (terminology?). On the interrupted feeds, you'll see an > ACK go out... and then nothing. After 5 minutes, our server sends a > finish every one minute, after which a reset will be returned > (sometimes after a few finishes have been sent). I would take the stance that this is pretty damning evidence that the other party's machine isn't doing it's job, although to be honest I'd feel happier if I were seeing it by packet-sniffing on a second machine (I bridged two network interfaces on a second machine and ran ethereal, I think, maybe snort, when I wanted to do this). There's surely no way to prove (with the equipment available to you) that the ACK packets are leaving your network past the ADSL router, but a reasonable log of what you're seeing should be sufficient to pass the onus onto the other party to prove that their machine isn't misbehaving. Beer soon? Stroller.