Re: [lwip-users] tcp connection state from app

[David Haas]

Marc Boucher wrote:

> there are imho two socket API issues here; connection state querying and
> disconnect notification.
>
> The first issue could perhaps be addressed with an ioctl
> or other similar mechanism; alternatively a 0-byte send or recv could
> be used to test the connection state (ENOTCONN should be returned if
> not connected), although this technique isn't applicable to 
> message-oriented protocols (like UDP [connectionless so it doesn't
> matter] or one day maybe SCTP [where it could matter]).
>  
What seems to be the standard is that when a connection was closed from 
the other end (but not from this end yet) if you call recv() you get 0 
bytes back but no error. This is the way lwip's socket implementation 
works and it matches what the Stevens book (Unix Network Programming) 
says it should do. I can't call recv() or read() from my monitoring 
program because I don't know how to handle the characters. Only the 
separate app thread can do that (and if it is not calling read(), then 
the data should stay in the socket for flow control purposes).

> The second issue could be covered by adding exceptfds support to
> lwip_select(). If asynchronous notification is needed, perhaps
> a SIGIO-like event mechanism could be implemented? (maybe via callback
> functions on platforms where unix-like signals are not available)
>  
My understanding from Stevens is that exceptfds are only used with OOB 
data. When a remote disconnect occurs select() will have readfds and 
writefds ready. Then if you do a read() you would get length of 0 back.

I can't actually find any ioctl call or anything else except maybe the 
poll() function. Has anyone ever used poll() for this?

David.