Re: [lwip-users] socket functionality - nonblocking?

[Micael]

On Tue, November 25, 2008 14:28, Rishi Khan wrote:
> FYI, a secondary problem with non-blocking connect is that if the
> server is not available or doesn't send RST packets for closed
> connections, you will back off on each retransmit and it may take a
> while to connect to the server once it is up. Imagine if you are
> backed off far enough that you are sending one SYN packets per minute
> and the server comes up in the middle of that.

Yes, the way I do it, is that I have a thread that constantly tries to
connect to the other servers, while also having a listen port open; the
one first, or if simultaneously, with higher tcip address wins. Once
connected, I keep the connection forever.
This means using getsockopt() (SOL_SOCKET, SO_ERROR) for checking if the
connect() where good or not, once the fdset reports activity on the
connect socket.

> The problem with non-blocking connect is that a lot of state needs to
> be kept to continue to retry the connection. For select, accept, and
> recv, you just need to look in the queue, see nothing there, and return.

Yes, I know! :) It can be quite complicated to manage all the states, but
I know of no other way, if one wants to keep it all within the same
thread. But that's partly why I want socket API, it is so much easier to
do the development on my PC (linux); just add some 20 virtual ethernet
interfaces,start as many instances of your "device code" on the PC as you
like, and once it works the way intended, move the code to a bunch of real
targets.


 Micael