Hi Kieran, I am Enrico's collegue (he went home just now), thank you
for your support.
Il 05/05/2011 18.11, Kieran Mansley ha scritto:
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.
We suspected so.
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.
No, PC retransmit at packet 10459, with Ack 27631. Our application
does not manage this retransmission, it comes from operating system.
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.
Ok, but our application should work in a LAN, with an RS485 backup
(if the Ethernet does not work).
Normally all works within few tenths of second, and we cannot lose
control of the system, after 3 seconds not working on LAN we should
switch on RS485.
Kieran
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
--
Cristiano
|