Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!aem
From: aem@aber-cs.UUCP (Alec D.E. Muffett)
Newsgroups: comp.unix.questions
Subject: How do you trap 1/2 a tcp connection dying ?
Message-ID: <2088@aber-cs.UUCP>
Date: 5 Nov 90 17:35:17 GMT
Reply-To: aem@uk.ac.aber.cs (Alec D.E. Muffett)
Organization: Computer Unit UCW Aberystwyth
Lines: 56


    Hi there - I've got a problem concerning sockets and select().  I'm
using sockets (AF_INET, SOCK_STREAM, "tcp") to communicate between a
server and unassociated clients meeting on a pre-secified port number.

    Basically the client connects to the server which has an infinite
loop going around a bit like this:-

for (;;)
{
	[set up read_bitmap from an array of socket fds]
	....
	num_active = select(num_fds, &read_bitmap, NULL, NULL, NULL);
	...
	[read from ready fds and act on data received]
}

    Read_bitmap is a 'fd_set' (see <sys/types.h> on Ultrix 4.0), with
bits 0->n set corresponding to the file descriptors to watch.  The fifth
argument to select() is a NULL pointer to struct timeval, which makes
the select() sleep until something happens.

    When select() returns, read_bitmap has only the bits corresponding
to active sockets set.  Num_active is a count of those active sockets.

    Everything is hunky-dory with this situation so long as it all shuts
down in an orderly manner, the client telling the server to wind down
the server end of a connection, and then shutting down it's own.  This
internal protocol is the way I've done it in the past and it works.

    HOWEVER, if the client ups and dies (kill -9, untrapped SEGV, etc)
without telling the server it's gonna die, when the client vanishes the
server goes berserk setting a permament 'read condition' on that
particular fd and it recv()'s the last block of data sent to that fd
over and over again, once for each iteration of the for loop.  Select()
returns (int) 1 immediately and the loop goes on and on....

    What I want to do is trap this situation.  I've done a minimal
server and created the situation over and over again, and I can't find a
sensible method of trapping it.  SIGURG is not generated and of the
other bitmaps which select() generates, write_fds is not helpful and
except_fds is not set under these circumstances.

    So the question is: How do I trap the fact that the other end of a
connected INET/SOCK_STREAM/tcp socket has vanished so that I may close it?

Thanx in advance,
		alec
--
JANET	aem@uk.ac.aber or aem@uk.ac.aber.cs
INET:	aem@cs.aber.ac.uk
UUCP:	...!mcsun!ukc!aber-cs!aem
ARPA:	aem%uk.ac.aber.cs@nsfnet-relay.ac.uk,aem%uk.ac.aber@nsfnet-relay.ac.uk
BITNET:	<play around with aem%aber@ukacrl, ok?>
SNAIL:	Alec Muffett, Computer Unit, Llandinam Building, UCW Campus,
	Aberystwyth, UK, SY23 3DB