How to detect connect() drops due to unavailable server

[ashukm_1912]

Hi,
I followed the following steps to test handling of connect failure in HP UX.
I first stopped the service :
kill -s SIGSTOP

My program connected to the service using the code :
socket(AF_UNIX,SOCK_STREAM,0)
int sp = connect(sp,(sockaddr*)&server_address, server_len);

i was expecting connect to fail because the service which it is connecting to has stopped. But connect still returned non negative value.
Also when i checked netstat -s, it said socket connects dropped due to server unavialble.
How do i detect such drops?
Also, after the connect was succesful, my program tried to recv() data from the socket descriptor and got blocked there.
Please help me in this regard.
Thanks and Regards,
Ashwini

[Matti_Kurkela]

SIGSTOP is a bit of a misnomer. It does not exactly "stop" a process... "pause" would be a better word. SIGCONT would allow the process to continue exactly from the point it was stopped. This is why the OS will keep the network sockets alive. Any incoming connections will wait in the queue of the listening socket.

Of course, if the process is paused for a long time and enough incoming data from network connections remains unacknowledged, those connections will time out. If the process is unpaused after that, it may be in a situation from which it is difficult to continue.

SIGSTOP is like SIGKILL: the process cannot catch, block nor ignore it. When someone sends SIGSTOP to a process, the OS simply stops giving any CPU time for that process.

One way to detect such a situation would be to connect to first set up a timer (see "man 2 alarm" or "man 2 setitimer") with a suitable time-out value, then send a message to the server.

If the server does not respond correctly before the timer is triggered, you'll know that the service is either:
- seriously overloaded (the server does not have enough free CPU time to service you)
- paused with SIGSTOP, or
- stuck in some way (in an infinite loop, or waiting for something else that is unresponsive)

Any of these is a good reason to report the service as unresponsive. For more information, you will usually need to examine the service's logs or use other diagnostic tools to find out the state of the service.

If your program is written to specifically monitor the service, you might want to set the socket in non-blocking mode before using it to connect to the service. That allows you to catch more errors immediately, without waiting for a time-out.

MK