Re: [lwip-users] Handshake trouble when packet is lost

[Kieran Mansley]

On Thu, 2011-05-05 at 17:54 +0200, Enrico Murador - Research &
Development - CET wrote:
> Thank you for explanation, now it is a bit clearer. I still do not 
> understand why packet 10464 contains seq = 27857.

It is the sequence number after the last byte that it has already sent.
i.e. the next sequence number.  Just because a packet got dropped (the
device doesn't know this yet) doesn't mean that this isn't the next
sequence number.

> lwIP device replies to a retransmission with ack = 27631 despite it 
> never receives ack = 27857.
> Perhaps I miss something.

I don't understand this: lwIP doesn't reply to retransmissions in the
example you sent as there aren't any retransmissions in that direction.
The lwIP device is the one that is retransmitting due to the lost
segment, not the PC.

> > The set starting at frame 11114 is identical, with again the missing
> > packet being retransmitted after a timeout of just over 1 second.
> This
> > looks fine.  It worries me that you say the PC gave up on the
> connection
> > at this point; 1 second is a very small amount of time to wait to
> give
> > up on a TCP connection.
> >
> Ok. This timeout was set only for testing purposes... It is simpler
> to 
> "catch" a collision with many devices connected and with a short
> timeout.
> There is no problem to wait more (but I think no more than 3
> seconds...).

There is nothing in the TCP specification that guarantees to get the
data correct in that time.  In general a TCP socket will retry for hours
before it gives up, and I can imagine lots of scenarios where it will
take more than 3 seconds.  How your application handles this will of
course depend on what your application does, but it should be prepared
to deal with this 3 second timeout of yours happening.

Kieran