Path: utzoo!attcan!uunet!nih-csl!lhc!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: How do you trap 1/2 a tcp connection dying ?
Message-ID: <27457@mimsy.umd.edu>
Date: 6 Nov 90 01:27:07 GMT
References: <2088@aber-cs.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 27

In article <2088@aber-cs.UUCP> aem@aber-cs.UUCP (Alec D.E. Muffett) writes:
>... 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' [from select()] 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.

Wanna bet? :-)

select() indeed returns 1 (or more) and indicates that reading the
socket will not block.  This does NOT mean that reading the socket
will succeed.  It only means it will not block---your program will
return from a read() or recv() or recvfrom() or recvmsg() immediately.

When the server knows the client is gone (on a TCP socket, this happens
when it receives a FIN or RST---here it will receive a FIN), it does
the same thing as with a pipe when the last writer vanishes.  Reads
produce the remaining data until the socket buffers have been drained;
then they return EOF.

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

Whenever read/recv returns 0 (EOF), the other end has gone away.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris