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
**********************************************
_______________________________________________
use-revolution mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/use-revolution
