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 _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
