home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / tcpip / 5144 < prev    next >
Encoding:
Text File  |  1992-11-12  |  2.8 KB  |  60 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!snorkelwacker.mit.edu!vaxeline.ftp.com!cream.ftp.com!jbvb
  3. From: jbvb@vax.ftp.com  (James B. VanBokkelen)
  4. Subject: Re: Detecting Dropped Sockets (Why is this hard on PC's?)
  5. Message-ID: <921112165655@cream.ftp.com>
  6. Nntp-Software: PC/TCP NNTP
  7. Lines: 43        
  8. Sender: root@vaxeline.ftp.com (vaxeline.ftp.com root account)
  9. Nntp-Posting-Host: whipped-cream.ftp.com
  10. Reply-To: jbvb@ftp.com
  11. Organization: FTP Software, Inc., Wakefield, MA
  12. References: <1992Oct30.212442.119@novell.com> <49191@shamash.cdc.com>
  13. Distribution: na
  14. Date: Thu, 12 Nov 1992 16:56:55
  15.  
  16. In article <49191@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
  17.  
  18.     I don't disagree with your statements, however, I was curious about
  19.     the systems you execute on.  Specifically, when a process is
  20.     terminated, what happens to the open file descriptors?  Aren't they
  21.     typically "closed"?  Doesn't TCP typically map this into a "normal
  22.     connection close"?
  23.  
  24. This is one of the places where attempts to "make network connections look
  25. just like files" start to get rocky.  The "close on termination" happens
  26. because 1) close is an operation that already exists, thus it's easy,
  27. 2) close is most likely to preserve data and abet debugging, and 3)
  28. close is necessary for overall filesystem consistency.  There are many
  29. times I've wished I could find out "file closed during program abort"
  30. from a directory listing, but OS designers haven't gotten that far.  TCP
  31. can (and in my opinion, should) be more informative.
  32.  
  33.     ... Can you cite an RFC which gives guidelines as to when TCP should
  34.     inject an RST on behalf of the application?  
  35.  
  36. As far as I know, none of the relevant RFCs attempt to say anything about
  37. the API to TCP (for fear of getting embroiled in OS Wars).  This has
  38. always seemed to be a "goes without saying" issue to me, but maybe it
  39. will be mentioned in a future Host Requirements document.
  40.  
  41.     NOTE - this only works if the peer system does something meaningful
  42.     with the receipt of the RST, and of course, the application would
  43.     have to be in-sync with the propagation of the RST event.
  44.  
  45. All "reasonable" TCPs let applications know they've been RST, since that's
  46. the only way to notice when the other system's crashed and rebooted.
  47.     
  48.     This option seems clean and straight-forward.  The problem is
  49.     I am not aware of implementations "providing and using" a 
  50.     similar capability.
  51.  
  52. PC/TCP for DOS provides a "normal close" service to applications which
  53. exit without cleaning up all their connections.  If we can detect that
  54. the application was aborted or ^C'ed, we generate RST segments.  If
  55. the PC is powered off, we can't do anything.
  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.  
  60.