Broadband Optimizer for Revolution?
Dar Scott
dsc at swcp.com
Tue May 31 20:08:56 EDT 2005
On May 31, 2005, at 5:20 PM, Alex Tweedly wrote:
>> Well, I have had my caffeine, so I have no excuse, but I don't know
>> what transmit window is.
>>
>> The TCP window is controlled by the receiver.
>>
> Not entirely. The "Window" field in the TCP header is indeed the
> receiver's definition of the number of octets he is willing to
> receive, so he does control it; however, a TCP stack will keep track
> of the "send window" for each connection. The "recv window" as sent by
> the receiver is an upper bound on the "send window" - but but the send
> window will be decreased according to any data sent since the last ACK
> was received, and also as a result of NAKs (and slow start). (see
> rfc 793, sect 3.2)
>
> Also, it will never exceed the configured send window size; thus even
> if a remote receiver is able and willing to have the window grow to
> say 64K, if the inet.sendspace was set to 32K, then the transmitter
> will never grow his send window above 32k (because he needs to buffer
> all that data within the TCp stack to allow for retransmits, and is
> unwilling to hold more than 32k).
I couldn't find any reference to "transmit window" or "slow start" in
rfc 793. I don't see how it's part of TCP, proper. The "send window"
is really just the senders view of the standard TCP window and should
not refer to self-limitations of the sender.
Even so, thanks for this info.
I think you're saying that the "congestion window" used by some
implementations is limited by both the TCP window (called "receive
window" by some) and some configuration called the "transmit window".
This imposes a minimum on the transmit buffer size, and it seems you
are saying that the practice is also to make this the maximum on the
transmit buffer. Did I get that right?
Thanks,
Dar
--
**********************************************
DSC (Dar Scott Consulting & Dar's Lab)
http://www.swcp.com/dsc/
Programming and software
**********************************************
More information about the use-livecode
mailing list