lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Decreasing window size problem


From: Tom Evans
Subject: Re: [lwip-users] Decreasing window size problem
Date: Thu, 14 Jun 2007 18:07:21 +1000

Per-Henrik Lundblom wrote:
> * Kieran Mansley <address@hidden> [070608 11:55]:
>  
> > Splitting to send a probe when your problem occurs is fine.  We need
to
> > treat "I can't send because the window is too small" the same as "I
> > can't send because the window is zero" and send probes in both
cases.
> > At the moment I think we only send probes in the latter, although
I've
> > not checked the code so could be wrong.

This problem should be in the bug list. I can't find anything matching.

> Nope, at least there is no TCP persist timer implementation in
> the 1.2.0 release.

That's a big omission. That's a "MUST" item in "Managing the Window" on
page 42 of the *September 1981* big-daddy RFC793:

    ftp://ftp.rfc-editor.org/in-notes/rfc793.txt

  The sending TCP must be prepared to accept
  from the user and send at least one octet of
  new data even if the send window is zero.

Note the "at least"? That might provide some assistance.

>From the original post on this topic:

Per-Henrik Lundblom wrote:
> At some moment, A's window
> size is smaller (say 119 bytes)

Assume the segment/queue has 128 bytes in it. I'd say it is legal to
send the whole 128 bytes. No splitting required. The section starting on
page 43 of the above RFC implies that some TCP implementations did this
over 25 years ago when they had RAM and ROM limitations (like we do now
:-).

Of course the receiver is then going to ACK 119 of the 128 bytes, so the
segment has to be split then. Does the code handle this case properly?
If that exposes another problem in the stack it would be nasty but legal
to keep sending OLD data (the whole 128 bytes) into the window until the
end of the segment is taken. Still requires the Persist Timer though,
can't get away without that.

=== 
Tom Evans

- The contents of this email, and any attachments, are strictly private and 
confidential.
- It may contain legally privileged or sensitive information and is intended 
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose, 
disseminate or otherwise use or take action in reliance upon the information 
contained in this email and any attachments, with the permission of Australian 
Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender 
immediately and promptly delete the email and attachments, together with any 
copies, from all computers.
- It is your responsibility to scan this communication and any attached files 
for computer viruses and other defects and we recommend that it be subjected to 
your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage 
of any nature, howsoever caused, which may result directly or indirectly from 
this communication or any attached files. 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]