home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / tcpip / 5060 < prev    next >
Encoding:
Text File  |  1992-11-06  |  3.3 KB  |  67 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!ukma!darwin.sura.net!sgiblab!newsun!donp
  3. From: donp@novell.com (don provan)
  4. Subject: Re: Detecting Dropped Sockets (Why is this hard on PC's?)
  5. Message-ID: <1992Nov5.193518.19192@novell.com>
  6. Sender: news@novell.com (The Netnews Manager)
  7. Nntp-Posting-Host: na.sjf.novell.com
  8. Organization: Novell, Inc., San Jose, California
  9. References: <1992Oct30.212442.119@novell.com> <49191@shamash.cdc.com>
  10. Distribution: na
  11. Date: Thu, 5 Nov 1992 19:35:18 GMT
  12. Lines: 53
  13.  
  14. In article <49191@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:
  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?
  18.  
  19. So your claim is that if i use such an operating system, then i must
  20. agree this behavior is correct.  Sorry.  Operating systems that aren't
  21. brain dead (most, unfortunately, no longer in production) understand
  22. that the file system's state shouldn't be changed unless the file
  23. manipulation is completed, which the application typically indicates
  24. by explicitly closing the file.  On such operating systems,
  25. terminating a process (or crashing the machine, for that matter)
  26. leaves the *original* file unchanged, or leaves no file at all if
  27. there was no original file.  In almost all cases, leaving a partially
  28. written file is absolutely the least desirable end result.  But, as
  29. most everyone else, i'm forced to use both UNIX and DOS even though
  30. they both have this fault.
  31.  
  32. >Aren't they typically "closed"?  Doesn't TCP typically map this into
  33. >a "normal connection close"?
  34.  
  35. And your claim here is that since UNIX believes that it understands
  36. how to gracefully close file descriptors, then it's OK for it to close
  37. TCP connections gracefully as well.  Hard to argue with that if you
  38. truely believe UNIX defines TCP/IP.  Even so, it's a shame to lose the
  39. useful meaning of a graceful close just because one common operating
  40. system thought it knew everything there was to know about any possible
  41. TCP application.
  42.  
  43. >I assume that you would inject an RST in cases
  44. >where you could prove "abnormal termination".  Can you cite an RFC
  45. >which gives guidelines as to when TCP should inject an RST on behalf
  46. >of the application?  I'm sure we would benefit from clean, consistent
  47. >implementations.  
  48.  
  49. To my knowledge, no RFC deals with what TCP should do if its
  50. application disappears.  Personally, i think that's because no one
  51. ever conceived of the UNIX behavior as a possibility, anymore than
  52. they thought an operating system might tend to send "Th-Th-That's all
  53. folks!" spontaneously down the TCP pipe.
  54.  
  55. But if we take RFC-793 as gospel (and why not?), since it doesn't
  56. mention process termination at all, my conclusion then is that the TCP
  57. implementation should do nothing: the connection simply disappears.
  58. No FIN, no RST, no nothing.  Then any subsequent packets from the
  59. other end of the connection would be for a non-existent connection, so
  60. TCP would respond with a RST.  In practice, in order to expedite the
  61. remote node's awareness of the situation, TCP sends a RST immediately.
  62. This isn't significantly different than doing nothing, since it's just
  63. what would happen if an old packet arrived or something like that.
  64.  
  65.                         don provan
  66.                         donp@novell.com
  67.