Question

What determines how many data packets are sent by the server / received by the client before the client sends an ACK? Is there any way to configure this either on server or client side to send more data before an ACK? How long does a server keep sending packets if no ACK is received? Is this configurable? Does the server request ACKs or does the client just send them?

Thanks,

Sam

Answer 1

Every byte sent over a TCP connection requires acknowledgement. That’s the rules. The server doesn’t explicitly request ACKs, because it doesn’t have to — it just expects that you’ll play by the rules, and that when it sends data, you will acknowledge it. If you don’t send ACKs for more than a certain number of bytes, any of three things can happen — the server will wait a while for an ACK (read: dead air), resend all that data that you haven’t acknowledged yet (read: more network traffic), or if it’s tried and failed to do so, it will reset the connection (read: “Connection reset by peer”).

With all that said, you don’t have to ACK every packet right away. The server will send some number of bytes — which will not be more, and will usually be less, than the client’s advertised “receive window” — before it requires an ACK. You can wait and collect a couple of segments and ACK them all at once, if you like…or send them with the data you’re sending to the server. (ACKs with data are effectively free.) Windows does this already; it waits about 200ms after it receives a segment before it sends an ACK. If another segment comes in in that time, or Windows has data ready to send, an ACK is sent immediately that covers both segments. The effect is that in the general case (a bunch of data coming in at once), the number of naked ACKs is cut in half.

If you really think you can do better than this, apparently there is a registry setting for TcpAckFrequency, which is “the number of TCP acknowledgements that will be outstanding before the delayed ACK timer is ignored” (read: before Windows immediately sends an ACK). The default is 2. You could increase this if you like, but you risk causing delays if it’s too high.

There’s also a TcpDelAckTicks, which specifies how long the delay is (in 100-ms “ticks”). By default it’s 2. Again, if it’s too high, you can cause delays that slow your network to a crawl.

If you insist on trying it, check out HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces. In there are a number of keys with GUID names; one corresponds to your current network connection. (If you’re on WiFi, there will be subkeys as well — one for each network?) You’ll need to add the values in there — they don’t exist by default.

Also, take a look at http://download.microsoft.com/download/c/2/6/c26893a6-46c7-4b5c-b287-830216597340/TCPIP_Reg.doc. It tells you about various options you can set. Note that many of the value names do not currently exist in the registry! You’ll have to add them in order to set them.