lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Connection timeout and issue with LWIP_DEBUGF


From: Kieran Mansley
Subject: Re: [lwip-users] Connection timeout and issue with LWIP_DEBUGF
Date: Wed, 30 Jan 2008 08:56:17 +0000

On Wed, 2008-01-30 at 07:01 +0000, Muhamad Ikhwan Ismail wrote:
> Hi..
> 
> I ported lwIP 1.2.0 into MPC852T running on SMX real time OS. It works
> really great and I would have to say its a great product.
> I have however 2 issues I could use some help with.
> 
> 1. I would like to know what happens internally within the stack and
> to the socket state if e.g. the cable is plugged out ? Will the pcb
> and the socket and conn be
> automatically closed after certain interval ? I was thinking of
> implementing on the tcpip thread a timeout with a handler, which
> monitors this by counting the carrier sense losses errors
> during the interval of the timeout in transmitted frames. The handler
> will in case of a high volume of carrier sense loss error set a
> certain global flag, and all application
> instead of using while(1) loop will use (while this flag not set).
> This would work if  the application is running, not waiting on read
> or connect, which is why I wanna know 
> what happens to the listen pcb e.g. when the connection is plugged
> out.

If you try and send data on a TCP socket when the cable is unplugged the
data will obviously not be acknowledged by the other end.  This will
result in retransmissions, and eventually (after a few hours I think)
the stack will give up and close the socket.  However, for all other
sockets (UDP, listening ones, TCP ones where you don't try and send
data) the stack won't notice that the cable has been unplugged and
they'll continue to exist indefinitely.

If you want to check that connections are still alive you can use the
KEEPALIVE option to ask the stack to probe the link every now and then
and close the connection if it can't get a reply.  This is however also
a relatively slow and conservative process and it can take a long time
before the stack gives up.

Kieran 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]