home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / tcpip / 5763 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  2.8 KB
  1. Path: sparky!uunet!olivea!spool.mu.edu!hri.com!noc.near.net!vaxeline.ftp.com!cream.ftp.com!jbvb
  2. From: jbvb@vax.ftp.com (James B. VanBokkelen)
  3. Newsgroups: comp.protocols.tcp-ip
  4. Subject: Re: Problems detecting a dead client connections ??????
  5. Keywords: TCP crashes
  6. Message-ID: <921229150500@cream.ftp.com>
  7. Date: 29 Dec 92 20:05:00 GMT
  8. References: <1992Dec29.161908.951@nsisrv.gsfc.nasa.gov>
  9. Sender: root@vaxeline.ftp.com (vaxeline.ftp.com root account)
  10. Reply-To: jbvb@ftp.com
  11. Organization: FTP Software, Inc., Wakefield, MA
  12. Lines: 42
  13. Nntp-Software: PC/TCP NNTP
  14. Nntp-Posting-Host: whipped-cream.ftp.com
  15.  
  16. In article <1992Dec29.161908.951@nsisrv.gsfc.nasa.gov> sylvain@killians.gsfc.nasa.gov (Gregory Sylvain) writes:
  17.     
  18.     The problem manifests itself when the client end of a tcp client/server 
  19.     connection desides to "go away".  (By "go away", this could mean that the 
  20.     client crashed or that the client actually closed the connection with a 
  21.     successfull call to shutdown(2).)
  22.  
  23. I'm not a real 4bsd internals expert, but as I understand shutdown(2), it
  24. should send a FIN, initiating a normal TCP connection close handshake.
  25.     
  26.     Given that the connection is non-blocking on both ends.  And provided that
  27.     the server isn't reading or writing from the socket at the time the client
  28.     crashes, THE SERVER WILL NEVER DETECT THAT THE CLIENT ISN'T THERE ANYMORE.
  29.  
  30. This is true regardless of the blocking/non-blocking state of either end
  31. of the connection, when one end's operating system (or TCP) crashes, or
  32. network connectivity is suddenly lost.
  33.     
  34.     The next time around, when the server tries to read from the socket,
  35.     the server will get an EWOULDBLOCK.  This make some sense, since there 
  36.     obviously isn't any infomation left to read.  But why wont the server 
  37.     get an error more like ECONNRESET or ECONNABORTED.
  38.  
  39. Ya pays yer penny and gets yer choice...
  40.  
  41. If you don't mind a steady stream of "keepalive" packets the whole time the
  42. connection is open, then most TCPs will give you an indication when they
  43. haven't gotten any traffic in some time T, whose exact value may be fixed
  44. or configurable depending on the implementation.  On an SGI or other
  45. 4bsd-derived TCP, read up on SO_KEEPALIVE.  You might find that it is
  46. easier to design the application protocol with a NOOP command, which can be
  47. used to check connection liveness instead of a TCP keepalive.
  48.  
  49. But this may well annoy (or bankrupt) users of PayPerPacket networks, or
  50. those with Dial On Demand serial links.  They'll want you to design your
  51. application-layer protocol so that each end has some way of giving up after
  52. waiting "too long", without probing the connection at all.
  53.  
  54. In short, if you need to know the state of the connection, you need traffic
  55. of one sort or another, which has a cost.
  56.  
  57. James B. VanBokkelen        2 High St., North Andover, MA  01845
  58. FTP Software Inc.        voice: (508) 685-4000  fax: (508) 794-4488
  59.