pww@bwdls55.bnr.ca (Peter Whittaker) (12/20/90)
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