Re: Test device before connect()

Craig Jacobsen wrote:

When it drops, the connect() hangs for 3 to 5 minutes trying to make a
connection. (I would like that to be a few seconds, but there are no time out values
that I can see.)

Here's an article that I wrote about timeouts with sockets. It describes two ways to do a timeout, and has sample code for the connect API:
http://systeminetwork.com/article/timeouts-sockets-0


Further, I would add that if you want to write robust TCP apps -- ones that can survive a network that's having trouble -- then you need to be using non-blocking sockets throughout your application.

Non-blocking assures that your application can NEVER get stuck forever waiting for the network. And in a robust application, that's a very important thing to do.

You were lucky in your instance -- you got stuck on the connect() API, which is relatively kind in that it times out after a number of minutes. Had you had the network error during a send() or recv() API, you might've gotten hung up permanently with no timeouts at all.

Use non-blocking with select() for everything you do. Write yourself a library of socket routines and put them in a service program and have them do all of the work for you, including the non-blocking and select() code.

In THAT environment, you'll never get hung up permanently, and you'll have complete control over how long you wait for a time out.