In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
ane.com writes:
> This is fairly easy to do for the transmit side of things and would
> yield an immediate improvement in available mbuf space. For the receive
> side of things we can't really do anything with existing connections
> (because we've already advertised that the space is available to the
> remote end),
You can't change the RFC 1323 window scale.
You can reduce the window size with each ACK, although this is frowned
upon.
To quote RFC 791,
The mechanisms provided allow a TCP to advertise a large window and to
subsequently advertise a much smaller window without having accepted
that much data. This, so called "shrinking the window," is strongly
discouraged. The robustness principle dictates that TCPs will not
shrink the window themselves, but will be prepared for such behavior
on the part of other TCPs.
Given a choice between failing new connections because insufficient
buffer space is available and a slow down (both from the decreased
window size and packets dropped by the sender as it's adjusting), the
later is probably preferable.
Of course, avoiding this by reducing the buffer size of new connections
before you run out is a better idea.
--
<a href="http://www.poohsticks.org/drew/";>Home Page</a>
For those who do, no explanation is necessary.
For those who don't, no explanation is possible.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
