🚀 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.)

[stuff deleted]

>   reliable than ping (tcp vs. udp) and that sending messages
>   across an open socket would require less overhead than ping.
>   (Is that correct?)
>
>Thanks for any help...
>- Keith


Ping doesn't use UDP, Ping uses ICMP, which is at the IP layer in the protocol
stack.  Therefore Ping would have less overhead than either type of socket
that you mention, TCP or UDP.  Ping just sends an ICMP request for echo packet.
In this packet it puts the time it sent it.  When the packet arrives it
calculates the round trip.  To get at ICMP you could create a RAW socket.  This
allows access to IP and ICMP.  It doesn't make a difference which you use though.
ICMP should have less overhead, but everything will be required to time out if the
echo is returned.  IP is conectionless and therefore can't tell when a machine is
up or went it isn't.  (Try running an ATM network is that's important, if you can
afford it of course.)  As for your problem, I don't really know the best way to
deal with that.  I think you're on the right track, some type of watchdog timer
system.  But I don't know enough about TCP/IP OS/2 programming to say much.

Chris
---------------
cinacio@vt.edu

Keith Bennett (kbennett@cpcug.org) wrote:
: 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)?

: 2) Is there a way to get the recv() to detect the shutdown and
:    return an error code?

: 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.)

: 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?)


I seem to remember the toolkit letting you set the TCP keepalive timeout 
through the setsockopt function.  Also, I believe thtat in IAK there is 
something to set keepalive for the entire system.  This might help your 
problem.

--
-------------------------------------------------------------------------
coneil@tiger.lsu.edu - <Insert some witty saying here>
oneill@bit.csc.lsu.edu - http://bit.csc.lsu.edu/~oneill/