home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / tcpip / 5905 < prev    next >
Encoding:
Internet Message Format  |  1993-01-10  |  1.2 KB
  1. Path: sparky!uunet!wupost!waikato.ac.nz!comp.vuw.ac.nz!duncan
  2. Newsgroups: comp.protocols.tcp-ip
  3. Subject: Re: time outs in FIN-WAIT2??
  4. Message-ID: <C0nu19.8z7@comp.vuw.ac.nz>
  5. From: duncan@comp.vuw.ac.nz (Duncan McEwan)
  6. Date: Sun, 10 Jan 1993 22:48:44 GMT
  7. Sender: news@comp.vuw.ac.nz (News Admin)
  8. References: <1993Jan9.164215.20972@jupiter.sun.csd.unb.ca>
  9. Organization: Comp Sci, Victoria University, Wellington, New Zealand
  10. Nntp-Posting-Host: bats.comp.vuw.ac.nz
  11. Lines: 18
  12.  
  13. In article <1993Jan9.164215.20972@jupiter.sun.csd.unb.ca> dedgar@mta.ca writes:
  14. >
  15. >I interpret this problem to mean that the other side has timed out or retried
  16. >out in fin-wait2. Is this a valid assumption. Does tcp-ip software do this?
  17.  
  18. I'm not sure if this is what you are seeing, but pg 365 of "The Design and
  19. Implementation of the 4.3BSD UNIX Operating System", describes how 4.3
  20. BSD also starts the 2*MSL timer when in FIN_WAIT_2 state if the local
  21. process has closed.
  22.  
  23. >It sure isn't in the rfc.
  24.  
  25. It claims this is done as a work around because "certain other TCP
  26. implementations (incorrectly) fail to send a FIN on a receive-only connection.
  27. Connections to such hosts will remain in FIN_WAIT_2 state forever unless the
  28. system times them out".
  29.  
  30. Duncan
  31.