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
