Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!ogicse!emory!att!watmath!watserv1!utgpu!cunews!bnrgate!bwdls61.bnr.ca!usenet
From: pww@bwdls55.bnr.ca (Peter Whittaker)
Newsgroups: comp.protocols.tcp-ip
Subject: Seeking Info on behavior w, w-o keepalives
Message-ID: <1990Dec19.184703.19746@bwdls61.bnr.ca>
Date: 19 Dec 90 18:47:03 GMT
Sender: usenet@bwdls61.bnr.ca (Use Net)
Organization: Bell-Northern Research, Ltd., Ottawa, Ontario, CANADA
Lines: 51

I posted this to comp.unix.programmer and got no response, so I thought
I seek the wisdom of readers of comp.protocols.tcp-ip!  advThanksance.

I've described a client/server interaction below, where the server "goes
away" then the client tries to access the socket that had connected them.
What I need to know is what the client should expect from various operations,
with and without SO_KEEPALIVE set as a socket option (on the client side).

The client/server relationship:  server binds, listens, accepts, then 
dies (either host goes down or server crashes/is killed).  Kernel then
attempts to close socket.  (Obv.  it's a TCP socket).

The client connects, then does some other stuff 
(i.e. sleep(until_server_is_dead);).
As I understand it, this is what happens when various functions are used
against the socket (NOTE:  no data transfer is pending:  either all data
has been transferred, or none was transferred, before the server died.).

		without  SO_KEEPALIVE		with SO_KEEPALIVE

read()		retcode==-1, errno==?		retcode==-1, errno==?
		(or maybe retcode 0, EOF read in?)

write()		retcode==-1, errno==?		SIGPIPE raised

select()	?? (readfds set true?,		?? (readfds and excepfds
		    EOF pending?)		    set true, EOF pending?)

close()		socket is closed.		socket is closed (*).

(*)-if implementation is correct:  HP-UX 6.5 clients using SO_KEEPALIVE
    never let the socket be closed.  They ACK the server-side FIN_ACK,
    but keep sending keepalives:  they never send their own FIN_ACK, so 
    server never sends RST (server-side kernel ACKs the keepalives).
    Socket is never closed.

I also have a question related to what exceptional events a 
select(...,&excepfds,....) can look for (I RTFMed, but couldn't find it;
any pointers, anyone?), but I'll leave that 'til later....

Thanks,





--
Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   Open Systems Integration
pww@bnr.ca           [                          ]   Bell Northern Research 
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 763 3283  [__________________________]   Ottawa, Ontario, K1Y 4H7