pww@bnr.ca (Peter Whittaker) (12/15/90)
In article <1990Dec10.194130.20414@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <epeterso.660257641@houligan>, epeterso@houligan.encore.com (Eric Peterson) writes: >|> However, the server occasionally hits a bug and core dumps or dies off >|> in some other way. But it dies off and closes its end of the ... and the rest is deleted.... Related question: I've already discovered the whims and wonders of SO_REUSEADDR: my problem is an application that uses SO_KEEPALIVE, as well. I won't go into the particulars, but could someone outline the differences in behavior between a client (as described below) using SO_KEEPALIVE, and one not using SO_KEEPALIVE? 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. advThanksance (<- isn't tm'ed, I hope?) -- 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