home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / tcpip / 5893 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  3.0 KB
  1. Path: sparky!uunet!caen!hellgate.utah.edu!cc.usu.edu!jrd
  2. From: jrd@cc.usu.edu (Joe Doupnik)
  3. Newsgroups: comp.protocols.tcp-ip
  4. Subject: Re: time outs in FIN-WAIT2??
  5. Message-ID: <1993Jan9.164734.62582@cc.usu.edu>
  6. Date: 9 Jan 93 16:47:34 MDT
  7. References: <1993Jan9.164215.20972@jupiter.sun.csd.unb.ca>
  8. Organization: Utah State University
  9. Lines: 49
  10.  
  11. In article <1993Jan9.164215.20972@jupiter.sun.csd.unb.ca>, dedgar@mta.ca writes:
  12. > Hello
  13. > 
  14. > I was wondering if anyone out there knows anything about a curious thing I've
  15. > seen while ftping into various machines.
  16. > 
  17. > I am writing a pc based ftp client program, among other things this software
  18. > has a hold screen function which is useful for pausing dirs to the screen &
  19. > etc.  Anyway, if the screen is held the incoming directory listing backs up
  20. > to the limit of my advertised window - just like it is supposed to. If the 
  21. > window happens to be larger than the remaining data the other side will 
  22. > send its fin and (i presume) move to fin-wait1. My side will go to close_wait
  23. > 
  24. > My side will remain in close-wait because it cannot get rid of the remaining
  25. > data (the hold screen is on) but will ack the other sides fin which 
  26. > (i presume) moves it to fin_wait2. The problem happens when I release the
  27. > hold screen. When this happens my side finishes processing the data and sends
  28. > its own fin, then moves to last ack. I have found that if the wait is long 
  29. > enough (10 sec or so) the other side will ignore my fin and never return an
  30. > ack - this leaves me in last_ack.  Eventually it seems my retransmitted fin
  31. > will generate a reset from the other side. 
  32. > 
  33. > I interpret this problem to mean that the other side has timed out or retried
  34. > out in fin-wait2. Is this a valid assumption. Does tcp-ip software do this?
  35. > It sure isn't in the rfc. Is there another interpretation. I have experienced
  36. > it with a number of types of machines on the internet (via anonymous ftp) maybe
  37. > anonymous is a special case in unix boxes?
  38. > 
  39. > Can anyone definitly confirm (one way or the other) that this is in fact
  40. > what is going on. I don't rule out bugs in my software, but I checked pretty
  41. > thouroughly before asking here.
  42. > 
  43. > Thanks
  44. >                         Dale Edgar
  45. >                         Cybernetic Control Inc.
  46. >                         DEDGAR@MTA.CA
  47. -----------
  48.     I did some similar thinking recently in my program. The answer depends
  49. on how one interprets "delivers the data." I finally decided that delivery
  50. meant placing in a socket buffer so I could send ACKs in the background as
  51. the buffer filled. Given this position then the buffer belongs to the top
  52. level application and not to the TCP session. Thus the session can close up
  53. normally and so on, yet that buffer remains for later draining. This works
  54. well with systems which insist upon sending reams of goodbye message material 
  55. and my program is busy with other things for a while. For top level app, the
  56. session is over when both the TCP part has finished completely and the buffer
  57. is empty.
  58.     Opinions do/will differ on this end to end delivery stuff. 
  59.     Joe D.
  60.