25 Aug 1988 11:59-EDT
It looks like another instance of the "have to retransmit a
FIN, so better subtract one from the sequence #" bug. Note that the
response (maybe to pktnum 2483, but possibly to an earlier packet
since the timestamps on 2483 and 2484 are identical) in pktnum 2484
was to ack 1d52f72. Thus the receiver has already received the data
being retransmitted in pktnums 2485, 2487 and 2489.
[Clearly useless retransmissions -- maybe (the timestamps are all
very close) an instance of the "retransmit all unacked data on a
retransmission timeout" algorithm, or (the timestamps are not
exactly equal) a "retransmit on ack before updating/processing
send-left & processing the retransmit queue" design deficiency].
It would have been nice if the trace began earlier, say on the first
transmission of the packet containing sequence number 1d53100; was
a FIN sent at the "same" time?
[Note [fnord sends its fin, with seq # 108d4e02] you mean 108d4e01.
Also, notice that in pktnum 2492, a FIN is being (re)transmitted at
a different sequence number, 1d53102, than it was in pktnum 2489,
1d53101 = 1d52f71+190.]
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:14 GMT