James explained it the same way I had heard it explained it before, but the behavior
described does not match what I'm observing. Keep in mind that there is no
ping-ponging going on. The repeated ACKs are coming back-to-back, in rapid fire, with
no server packets received in between.
-----Original Message-----
From: James Washer [SMTP:[EMAIL PROTECTED]
Sent: Friday, September 05, 2003 4:10 PM
To: [EMAIL PROTECTED]
Subject: Re: [RLUG] [OT] TCP/IP Weirdness
The technically astute reader will notice that my ack's are off by one, as the
receiving machine acks the sequence number of the next packet it expects, NOT the last
packet it received..
So.. should be
server send 1
client acks 2
server sends 2 which gets lost in the ether
client doesn't get it so client does nothing
server sends 3
client receives 3, but can only ack 2, as it has not yet seen 2
server sends 4
client receives 4, but can only ack 2, as it has not yet seen 2
server RESENDS 2
client acks 5 as he has now seen 1,2,3,and 4 and is not expecting 5
On Fri, 5 Sep 2003 14:58:28 -0700
James Washer <[EMAIL PROTECTED]> wrote:
>
> actually... depending on exactly what the client is acking... it more likely
means the client failed to see one packet.. and every time is get a new (higher
seqence) packet is acks the 'highest sequence' it at seen so far...
>
> for example
>
> server send 1
> client acks 1
> server sends 2
> client doesn't get it so client does nothing
> server sends 3
> client receives 3, but can only ack 1, as it has not yet seen 2
> server sends 4
> client receives 4, but can only ack 1, as it has not yet seen 2
> server RESENDS 2
> client acks 4
>
> >From the original description, it sounds like the server might have an
excessively long retransmit timer.
>
> - jim
>
>
> On Fri, 5 Sep 2003 11:19:40 -0700 (PDT)
> "Todd A. Jacobs" <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 5 Sep 2003, Eric Robinson wrote:
> >
> > > I'll get you the trace file later today. From memory, I believe the last
> > > ACKed packet was about 732 bytes in size, with most of the previous ones
> > > being 1432 bytes. After this packet is ACKed, the server keeps sending
> > > more data in mostly 1432-byte packets, while the client keeps ACKing the
> > > same old packet.
> >
> > This indicates that the client is not seeing later packets, for whatever
> > reason. I'd put a tap on the client's Ethernet cable, to find out if the
> > client is in fact receiving the packets on the media. If so, then it's a
> > software problem: Blame Redmond (tm).
> >
> > --
> > Sen. Orrin Hatch thinks destroying private property to ensure bigger
> > campaign contributions from media cartels is "good politics." Let your
> > senators know that supporting corporate vigilantes will bite them in
> > the political posterior next election day.
> >
> > _______________________________________________
> > RLUG mailing list
> > [EMAIL PROTECTED]
> > http://www.rlug.org/mailman/listinfo/rlug
> >
>
>
> _______________________________________________
> RLUG mailing list
> [EMAIL PROTECTED]
> http://www.rlug.org/mailman/listinfo/rlug
>
_______________________________________________
RLUG mailing list
[EMAIL PROTECTED]
http://www.rlug.org/mailman/listinfo/rlug
_______________________________________________
RLUG mailing list
[EMAIL PROTECTED]
http://www.rlug.org/mailman/listinfo/rlug
