|Subject:||[lwip-users] Re: Problem with lwip_close in TCP|
|Date:||Thu, 29 Jun 2006 11:19:06 +0100|
|User-agent:||Thunderbird 126.96.36.199 (Windows/20060516)|
week). I've also added support to the sockets API for non-blocking connect's, so I'd love to know how to go about getting stuff into the main LWIP source (I did the non-block connect patch initially for 0.7.1, then had to manually port it to 1.0.0, then I've just done it again for the 1.1.1 tree - and it's a real PITA).
Speaking of non-blocking sockets, I've just submitted a patch for non-blocking TCP writes (lwip_send()).
I have a server application which pushes data, and found that it didn't always know when the other end closed its side of the connection. This is because it's possible to continue writing to the socket when the other end has done a close() - I understand this is because close() is considered to close *one* end of the connection. I found that some targets (Windows 2K) actually sent a RST if you continuing writing to their closed socket, which woke up the LWIP send socket, but with some targets the write socket is not woken up and ends up blocking on a full TCP sndbuf.
To get round this I needed to make the server read from the socket, as well as write, to get notification that the other end closed. However if a thread is blocking for TCP sndbuf space to become available (and it never does), then the thread never gets the chance to read from the socket. By using a non-blocking socket with select() one can check both the read and write status of the socket, allowing you to find out if the other end has quit at the same time as waiting for TCP snd_buf space to become available.
|[Prev in Thread]||Current Thread||[Next in Thread]|