[lwip-users] Re: Problem with lwip_close in TCP

[Kelvin Lawson]

> 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.

Cheers,
Kelvin.