home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / tcpip / 5890 < prev    next >
Encoding:
Text File  |  1993-01-09  |  2.1 KB  |  48 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!sdd.hp.com!cs.utexas.edu!torn!csd.unb.ca!mta.ca!DEDGAR
  3. From: dedgar@mta.ca
  4. Subject: time outs in FIN-WAIT2??
  5. Message-ID: <1993Jan9.164215.20972@jupiter.sun.csd.unb.ca>
  6. Sender: news@jupiter.sun.csd.unb.ca
  7. Reply-To: dedgar@mta.ca
  8. Organization: Mount Allison U, Sackville, N.B. Canada 
  9. Date: Sat, 9 Jan 1993 16:42:15 GMT
  10. Lines: 36
  11.  
  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.