Re: Implicit acks in TCP?

Richard Fox (
Thu, 3 Mar 88 14:08:20 PST

TCP is a byte stream protocol. This means that it works based on bytes
being sent, not packets per se. Thus, you'll notice that the ACK field
is acking bytes not packets sent. To ack each byte individually would
take forever, so the ack is stating which byte it expects to receive
next ( or as you put it, it is implicity ACK'ing all data up to a certain
point). Since each packet of data contains an ACK, if you notice that
you are sending 4 packets instead of 2, where 2 would suffice if ACKS
are piggybacked, then it is your implementation adding the extra
packets, not the protocol.

I believe the problem you stated with your implementation is happening
because you have delayed acking turned off. This means as soon as you
know you can ack something received do so, then go ahead and process
the request ( ie: get and send the data).

Hope this helps some,

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:30 GMT