Re: Capping of sockets
Re: Capping of sockets
- Subject: Re: Capping of sockets
- From: "Peter Sichel" <email@hidden>
- Date: Sat, 10 Jun 2006 10:44:55 -0400
On 6/10/06, David Aames wrote:
>So I've read
>about the TCP window and I *think* what I need to do is control the
>acknowledgment of the received data i.e., acknowledge as much as I
>want to limit the download speed. So my question is which function is
>actually sending the transfer ACK?
You don't have direct control over this from the sockets API.
It is handled by the TCP layer running in the kernel.
As you adjust the receive buffer size, it should affect
the Window Advertisement sent with subsequent ACK segments.
Having spent some time experimenting with this from an NKE,
I can tell you the interactions are fairly subtle. TCP is
designed to provide a steady supply of ACKs so the sender
can maintain an accurate RTT (round trip time) estimate.
In practice, some stacks ACK almost every other packet.
Notice the window has both a "window start" which corresponds to the
last byte acknowledged, and a "window limit" which determines how much
data can be sent before waiting for an acknowledgement that advertises
more space. In my testing, withholding ACKs and re-inserting them later
was less effective at providing smooth rate control than withholding
window advertisements to control when and how much the "window limit"
moves. My code still inserts extra ACK segments to spool out moving the
window limit. TCP actually uses two flow control mechanisms:
(1) The advertised window size which allows the receiver to flow control
the sender.
(2) Slow Start which reduces network congestion by requiring that the
stack not send more segments at once than the number of segments acknowledged.
Delaying Acks affects the RTT estimate and Slow Start behavior. While
very effective at slowing things down, the data and computation to
figure out what and how much to withhold for smooth control is non-trivial.
Kind Regards,
- Peter
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden