[comp.protocols.tcp-ip] timimg-out a socket read... AND THE ANSWER IS ...

ihsan@ficc.ferranti.com (jaleel ihsan) (06/30/90)

... do something like this (info. provided courtesy of ted@Ultra.com):

s = socket();
connect(s,..)
timeval.tv_sec = 15;  /* set timeout to 15 seconds */
timeval.tv_usec = 0;
rmask = 1<<s;
if (select(32, &rmask, (struct fd_set *)0, (struct fd_set *)0, timeval)) == 0 {
    close(s);
}

I intentionally left out information reguarding my OS and the tcp-ip
implementation from my original posting because, before solving the
problem on my platform, I wanted to know:

	1. What does the TCP protocol standard has to say about it.

	2. What the user interface standard has to say about it.

The overwhelming response (I got through news, but mainly through email)
and its unanimity clearly indicates that the answer to 2. above is that
"select(2)" IS the standard user I/F.

The answer to 1. above (courtesy of gjack@datlog.co.uk) is:

Section 4.2.3.6 of RFC-1122 (Host Requirements protocol) says
keepalives MAY be implemented (ie are OPTIONAL), if provided
the interval MUST be configurable.

Thankyou so much to those who replied.

BTW, the OS I *have* to work with is Intel's RMX (Real-Time Executive)
and the tcp-ip implementation is from a third party vendor who has
taken some unix tcp-ip driver and ported a subset of it to RMX, and
that's one of the problems.

In addition to the standard user I/F "read()", the vendor provides an
RMX async read with time-out capability.  When the timer times-out,
a "no-data-to-read" indication is returned but unfortunately the read
is not canceled and no mechanism is provided so that I can cancel the
read (ie a "cancel io" function is not provided by the tcpip driver)
On top of that the standard user I/F function "select()" is not provided.
Pretty unreasonable thing to do !!!

So if the time-out occurs, I want to close the socket and try to
reestablish the connection.  But due to the pending read I cannot
do it without having a dangling TCP connection.  And I cannot
afford to leave a dangling connection, because if happens a few
times, resources associated with the connections will dry up and
my system will be dead in the water !!!

Jaleel