home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / protocol / tcpip / 4105 < prev    next >
Encoding:
Text File  |  1992-08-14  |  3.1 KB  |  72 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!meaddata!russ
  3. From: russ@meaddata.com (Russ Rahn)
  4. Subject: Request for Help on TCP problem
  5. Keywords: retransmit, window
  6. Followup-To: comp.protocols.tcp-ip 
  7. Sender: news@meaddata.com (Usenet Administrator)
  8. Organization: Mead Data Central, Dayton OH
  9. Date: Fri, 14 Aug 1992 14:31:57 GMT
  10. Message-ID: <1992Aug14.143157.14145@meaddata.com>
  11. Distribution: usa
  12. Lines: 58
  13.  
  14.  
  15. I have been witnessing from time to time, a series of events that I
  16. feel is improper.  I am asking for help from you gurus on the net so
  17. that I can determine (1) if there is a problem, and (2) who has the
  18. problem.  The following is a description of what I see:
  19.  
  20. We have a protocol converter that takes frames from an X.25 cloud and
  21. converts them to TCP-IP packets and sends them to our PC.  It does the
  22. opposite with TCP-IP frames generated by our PC.
  23.  
  24. Let's pick up the action with everything running fine.  Our PC is all
  25. caught up and has just acked with an ack value (for the sake of this
  26. discussion) of 0, and gave a windowsize of 512.  The converter sends
  27. a packet to our PC with seq# 0.  For one reason or another, this frame
  28. is missed by the PC.  The converter sends the next frame with seq#
  29. 128.  This is what I would have expected.  The PC responds with an ack
  30. message with ack = 0.  Again this is what I would have expected, but
  31. this is the point where reality begins to deviate from my
  32. expectations.
  33.  
  34. The converter then sends a packet with seq# 256.  The PC acks 0.  The
  35. converter sends the packet seq# 384 with a length of 128.  This fills
  36. our window.  The PC acks 0.  Since our window is full, the converter
  37. listens to the PC this time and retransmits the packet with seq# 0.  The
  38. PC gets it and acks 128.  Our window is no longer full, since it has
  39. just slid over 128 bytes.  The converter then sends a packet with seq#
  40. 512.  The PC is forced to ack at 128.  The window is full again, so
  41. the converter listens and resends packet seq# 128.  The window slides
  42. and this pattern continues.
  43.  
  44. I thought that I had read that if you receive an ack for less than you
  45. had already sent, then you should forget all that was sent after the
  46. ack point and retransmit from that point on.  If you don't receive an
  47. ack, then you should continue sending more and more new packets until
  48. you either fill the given window (flow control) or you eventually get
  49. an ack telling you what to do.
  50.  
  51. Is this right?  Or should the PC have been saving all of the frames
  52. that were provided after the ack value it gave (those that filled the
  53. window) so that when the converter got around to retransmitting the
  54. missed packet (seq# 0), the PC could have then acked the whole window?
  55.  
  56. You can see how the current action is putting a delay in our
  57. processing while the window gets filled, and then slows processing
  58. after that by requiring so many packets to deliver just one.
  59.  
  60. Please E-Mail with any response as I don't get to read the News very
  61. often.  Also, if you would like to help, but I haven't made my
  62. question clear enough, please drop me a line and I'll try to describe
  63. the situation better.
  64.  
  65. Thanks in advance!
  66.  
  67. Russ
  68.   
  69. russ@meaddata.com
  70.  
  71.  
  72.