Newsgroups: comp.protocols.tcp-ip
Path: utzoo!utgpu!cunews!bnrgate!bwdls61.bnr.ca!bwdlh131!mleech
From: mleech@bwdlh131.bnr.ca (Marcus Leech)
Subject: Re: Monitoring TCP/IP sockets
Message-ID: <1991Jan31.012304.11878@bwdls61>
Sender: usenet@bwdls61 (Use Net)
Reply-To: mleech@bwdlh131.bnr.ca (Marcus Leech)
Organization: Bell-Northern Research, Woodline Center
References: <9101291553.AA06606@litwin.jpl.nasa.gov.> <1991Jan30.172337.7084@zoo.toronto.edu>
Date: Thu, 31 Jan 91 01:23:04 GMT


In article <1991Jan30.172337.7084@zoo.toronto.edu>,
henry@zoo.toronto.edu (Henry Spencer) writes:
|> In article <9101291553.AA06606@litwin.jpl.nasa.gov.>
litwin@ROBOTICS.JPL.NASA.GOV (Todd Litwin) writes:
|> 
|> SO_KEEPALIVE is a kludge; its timeout period is non-adjustable and quite
|> long.  You're going to have to do it yourself.
I'll second that, and add that I have successfully used application-level
  "keep-alives" (which should properly be called "make-deads") to detect
  server processes going away.  This *only* works if you have very tight
  control over where your packets are routed.  It happens that my applications
  have servers "in the next room", so network prop delays are quite
  predictable (in lieu of technicians severing cables ;-( ).
--
Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
VE3MDL@VE3JF.ON.CAN.NA         Ottawa, ON, CAN K1Y 4H7 |necessarily BNRs