🚀 go-pugleaf

In article <3lc25d$kt1@cpcug.org>, kbennett@cpcug.org (Keith Bennett) writes:
|> The following questions pertain to programming sockets using
|> IBM's TCP/IP for OS/2 version 2.0 (UN 64092).  Our app is
|> running under OS/2 2.1 (not 2.11) and we hope to eventually
|> upgrade to Warp.
|> 
|> We have found that when doing a blocking read (recv()) on a
|> socket, the read will not return if the machine on the other end
|> of the socket has been switched off or rebooted.  (Despite our
|> warnings, our customers do it from time to time and we have
|> decided to accommodate for that somehow in our software.)
|> 
|> 1) Is this behavior correct according to the TCP/IP standard (or
|>    convention if there isn't a standard)?

I looked at the Unix man page for recv(2), it does not handle this
situation explicitly. However, it recommends using recv in conjunction
with select(2), something like
	for(;;) {
		switch (bsdselect( maskofsockets,..., timeout) {
		case 0:
			timeout: check whether socket is still alive
			(e.g. try a non-blocking read and watch the error code)
		case -1:
			error occurred, exit
		default:
			check if the socket has data, retrieve it with recv
		}
	}
|> 
|> 2) Is there a way to get the recv() to detect the shutdown and
|>    return an error code?
See 1)

|> 
|> 3) Are there any other situations that would cause the recv() to
|>    block incorrectly?  (When planning our defense against this
|>    situation we would like to know all of the possible causes up
|>    front.)
Unix has the notion of a signal occuring during the read, in which case the
recv should return EINTR, but I don't have the doc at hand to see if
OS/2 TCP/IP also knows this. Also with non-blocking it can return EWOULDBLOCK.
I would not use a blocking read/recv with sockets anyway, but use a method
like 1).

|> 4) What would you recommend as the best way to detect the demise
|>    of the other end?  We've been thinking of having a separate
|>    thread pinging all remote hosts that have sockets connected, and
|>    forcibly closing any sockets connected to a machine that has
|>    died.  That gets elaborate though, as we'd have to keep track of
|>    which sockets are connected to whom, etc.
|> 
|>    A slightly different solution would still have a separate thread
|>    checking the other machines, but instead of pinging have a
|>    separate special purpose socket with periodic keepalive
|>    messages.  It is our understanding that sockets are more
|>    reliable than ping (tcp vs. udp) and that sending messages
|>    across an open socket would require less overhead than ping.
|>    (Is that correct?)
This won't work in general, as it might happen that a single socket
connection will crash, but the special purpose socket might stay alive, thus
lying about lifeness.
What you could do is use the same socket and send an out-of-band
message periodically by some thread, which must be answered by the
remote side within some interval.

-- 
         Dr. Holger Veit                   | INTERNET: Holger.Veit@gmd.de
|  |   / GMD-SET German National Research  | Phone: (+49) 2241 14 2448
|__|  /  Center for Information Technology | Fax:   (+49) 2241 14 2342
|  | /   Schloss Birlinghoven              |    Pentium - the first real
|  |/    53754 St. Augustin, Germany       |  processor featuring the new
                                           |    *** RISK technology ***