home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / tcpip / 5148 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  2.7 KB
  1. Path: sparky!uunet!know!hri.com!noc.near.net!news.bbn.com!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!ogicse!das-news.harvard.edu!husc-news.harvard.edu!burrhus!ddl
  2. From: ddl@burrhus.harvard.edu (Dan Lanciani)
  3. Newsgroups: comp.protocols.tcp-ip
  4. Subject: Re: Detecting Dropped Sockets (Why is this hard on PC's?)
  5. Message-ID: <1992Nov13.033719.8300@burrhus.harvard.edu>
  6. Date: 13 Nov 92 03:37:19 GMT
  7. References: <1992Oct30.212442.119@novell.com> <49191@shamash.cdc.com> <921112165655@cream.ftp.com>
  8. Distribution: na
  9. Organization: Harvard University, Cambridge, MA
  10. Lines: 38
  11.  
  12. In article <921112165655@cream.ftp.com>, jbvb@vax.ftp.com  (James B. VanBokkelen) writes:
  13. | In article <49191@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
  14. | 
  15. |     I don't disagree with your statements, however, I was curious about
  16. |     the systems you execute on.  Specifically, when a process is
  17. |     terminated, what happens to the open file descriptors?  Aren't they
  18. |     typically "closed"?  Doesn't TCP typically map this into a "normal
  19. |     connection close"?
  20. | 
  21. | This is one of the places where attempts to "make network connections look
  22. | just like files" start to get rocky.  The "close on termination" happens
  23. | because 1) close is an operation that already exists, thus it's easy,
  24. | 2) close is most likely to preserve data and abet debugging, and 3)
  25. | close is necessary for overall filesystem consistency.  There are many
  26. | times I've wished I could find out "file closed during program abort"
  27. | from a directory listing, but OS designers haven't gotten that far.  TCP
  28. | can (and in my opinion, should) be more informative.
  29.  
  30.     Curiously enough, the old 2.9BSD (aka 4.1c) networking code
  31. went to some lengths to get an indication of whether a socket was
  32. closed explicitly by the process.  As I recall, this involved a
  33. new argument to the internal kernel closef() function and, of course,
  34. changes to every call to said function.  The argument was passed
  35. as true when the process actually called close() and false when
  36. closef() was invoked as part of exit handling.  (It may not have been
  37. completely obvious which way things went on an implicit close caused
  38. by, e.g., dup2(). :)
  39.     After all this bother, the tcp/ip code did very little with
  40. the information.  I don't remember whether this was because of a
  41. real bug or because of a ``fix'' to correct problems caused by
  42. doing something extreme like sending RST.  The original intent
  43. was almost certainly to prevent processes from getting hung in
  44. an exiting state, rather than to inform the peer that something
  45. funny had happened.  In any case, the code disappeared long before
  46. 4.3BSD but at least it has been tried...
  47.  
  48.                 Dan Lanciani
  49.                 ddl@harvard.*
  50.