write on socket sleeping

[Fedele Giuseppe]

Hello,

I have two processes talking to each other through a socket mechanism.
They are written in C language and run on a HP-UX 11.31 Itanium platform.

One process hungs in writing on the socket.

By using "tusc" tool I see that "write" call is in "sleeping" status.

Why and when a "write" remains in "sleeping" status?

How can I manage such a condition?

Many thanks

Giuseppe

[Matti_Kurkela]

If the type of socket/protocol you're using requires the recipient to acknowledge the data before the write operation is considered complete, this happens when the acknowledge does not arrive.

You could use the setsockopt() system call to set time-out values (SO_SNDTIMEO and SO_RCVTIMEO) for your socket: the standard default value is 0, which means the system will wait forever. This must be done before the socket is actually written to.

Then you should check the return value of your write() operation to see whether all the data was sent successfully or not. If the amount of data sent is less than the size of what you meant to send or -1, you'll know there was a problem and the timeout may have been triggered. Examine the errno variable to identify the problem type, then have your program do something appropriate to the situation.

You may wish to Google for examples of the use of setsockopt() or refer to books on Unix network programming for details.

For a nice "big picture" overview I'd recommend Chapter 8 of "Advanced UNIX Programming" by Marc J. Rochkind (Addison-Wesley, ISBN 978-0-13-141154-8).

MK

[rick jones]

I am not sure that the timeouts are implemented under HP-UX - best check that before relying on it.

As for why a write could block - a socket by default is in a "blocking" mode. If the socket buffer (SO_SNDBUF) is full, the write() call against the socket will block until there is enough space to get the all the bytes of the write() into the socket buffer. For something like a TCP connection between two processes, it means that the remote TCP has to have sent an ACKnowledgement for the data.

You can either always have SO_SNDBUF > the maximum number of bytes you will have outstanding on the socket/connection before a "natural" stopping point (eg maximum request size times maximum number of requests outstanding) or you can make the socket non-blocking and sit in a select/poll/devpoll call waiting for the socket to become writable.

Of course, if the other side of the connection "never" pulls data out of the connection, you could end-up waiting a very long time for the socket to become writable. So, you will have a timeout on that select/poll/devpoll and have to decide what to do when that timeout is reached.

[Fedele Giuseppe]

Hello Matti,

the socket is set for nonblocking I/O through the system call:

fcntl(socket, F_SETFL, O_NDELAY)

moreover the returned code of "write" is checked to verify that is greater than 0.

So, for what I know, the "write" should not block if the recipient does not acknowledge.

Isn'i it?

Do you think that setting timeouts I will avoid to fall in such a condition?

Giuseppe

[Fedele Giuseppe]

Hello Rick,

if I have well understood, your analisys refer to blocking sockets.
(My mistake: I forgot to specify that my socket was nonblocking)

So, my question is: which could be the reason why a nonblocking sockets hungs?

Many thanks

Giuseppe

[rick jones]

I would triple check that you are:

1) checking the return value of the fcntl call

2) calling it against the correct file descriptor

and

3) the fcntl call is returning success.

Some of that would be through code inspection, some of that could be accomplished with the tusc system call trace tool with which you are already familiar.

If all those checks "pass" then you should bundle-up a test case and exercise the old support contract to get the response center to file a defect.

[Fedele Giuseppe]

After having analyzed more in dept the code, I have seen that the socket is set in nonblocking mode only on server side.

Could this be the issue?

Giuseppe

[rick jones · Accepted solution]

If the client is blocking, yes, absolutely. Non-blocking is only a _local_ attribute of a socket. It means nothing for any remote socket.

[Fedele Giuseppe]

Ok, I will set also client socket in nonblocking mode.

Many thanks

Giuseppe