Re: mirage-www

[Jon Crowcroft <Jon.Crowcroft@xxxxxxxxxxxx>]

i wonder if its some thread deadlock/wedge that';'s not letting a
TCP piece make progress...?

In missive <1FF98AD3-7C87-4FFE-96D5-8C0641252600@xxxxxxxxxxxxxxxx>, Richard 
Mortier typed:

 >>
 >>On 7 Sep 2012, at 16:04, Jon Crowcroft wrote:
 >>
 >>> No, sequence numbers apply to bytes of payload data
 >>
 >>ah- it's just the SYN that applies to -- from rfc 793, p31:
 >>
 >>  In line 2 of figure 7, TCP A begins by sending a SYN segment
 >>  indicating that it will use sequence numbers starting with sequence
 >>  number 100.  In line 3, TCP B sends a SYN and acknowledges the SYN it
 >>  received from TCP A.  Note that the acknowledgment field indicates TCP
 >>  B is now expecting to hear sequence 101, acknowledging the SYN which
 >>  occupied sequence 100.
 >>
 >>in that case, no idea :)
 >>
 >>looks like the client certainly thinks things should be ack-ed further into=
 >> the stream. wireshark is having one of its (many) "moments" on my mac so i=
 >> can't actually open the file again (opening wireshark currently causes it =
 >>to fork bomb the mac with processes that activity monitor reports as "wires=
 >>hark" and ps reports as "dumpcap"...).
 >>
 >>> On 7 Sep 2012 15:21, "Richard Mortier" <Richard.Mortier@xxxxxxxxxxxxxxxx>=
 >> wrote:
 >>>=20
 >>> On 7 Sep 2012, at 14:02, David Scott wrote:
 >>>=20
 >>> > ...It looks like a problem in TCP. Anyone got any hints where to look?
 >>>=20
 >>> not specifically, but it looks like the server is acking up to byte 112; =
 >>the 3 repeated acks up to 112 trigger the fast retx as they should.
 >>>=20
 >>> isn't the server supposed to ack 1 past (because the ack itself counts as=
 >> a byte)?  ie., to 113.  (certainly that would explain why the client keeps=
 >> treating the ack to 112 as a request for retx.)
 >>>=20
 >>>=20
 >>> --
 >>> Cheers,
 >>>=20
 >>> R.
 >>>=20
 >>>=20
 >>>=20
 >>>=20
 >>> This message and any attachment are intended solely for the addressee and=
 >> may contain confidential information. If you have received this message in=
 >> error, please send it back to me, and immediately delete it.   Please do n=
 >>ot use, copy or disclose the information contained in this message or in an=
 >>y attachment.  Any views or opinions expressed by the author of this email =
 >>do not necessarily reflect the views of the University of Nottingham.
 >>>=20
 >>> This message has been checked for viruses but the contents of an attachme=
 >>nt
 >>> may still contain software viruses which could damage your computer syste=
 >>m:
 >>> you are advised to perform your own checks. Email communications with the
 >>> University of Nottingham may be monitored as permitted by UK legislation.
 >>
 >>
 >>--=20
 >>Cheers,
 >>
 >>R.
 >>
 >>
 >>
 >>
 >>

 cheers

   jon