Still waiting on the trace. - jim On Fri, 5 Sep 2003 16:17:32 -0700 "Eric Robinson" <[EMAIL PROTECTED]> wrote:
> 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 > _______________________________________________ RLUG mailing list [EMAIL PROTECTED] http://www.rlug.org/mailman/listinfo/rlug
