jwkhong@grand.waterloo.edu (James W. Hong) (03/03/88)
I wonder if someone could clarify a point for me regarding acks in TCP. Are implicit acks allowed in TCP? What I mean by an implicit ack is that each request or response message serves as an implicit ack for the previous response or reqeust message from that client, respectively. What BSD4.3 version TCP seems to do is to ack a request packet immediately and sends the requested data in a separate packet. This requires 4 packet exchanges rather than 2 if an implicit ack is used. Does the TCP spec. disallow using implicit acks? Or does it depend on TCP implementations? ---------------------------------------------------------------------------- James W. Hong jwkhong@grand.waterloo.cdn Dept. of Computer Science jwkhong%grand%waterloo.csnet Univ. of Waterloo jwkhong%grand%waterloo.csnet@csnet-relay.arpa Tel: (519) 885-1211 x6178
rfox@AMES-NAS.ARPA (Richard Fox) (03/04/88)
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, rich
barmar@think.COM (Barry Margolin) (03/05/88)
In article <17229@watmath.waterloo.edu> jwkhong@grand.waterloo.edu (James W. Hong) writes: >I wonder if someone could clarify a point for me regarding acks in >TCP. Are implicit acks allowed in TCP? What I mean by an implicit >ack is that each request or response message serves as an implicit >ack for the previous response or reqeust message from that client, >respectively. Your question indicates that you misunderstand TCP. TCP does not have any notion of "request" and "response" messages; some higher-level protocols, such as RPC (Remote Procedure Call), may have them, though. TCP implements a reliable bidirectional stream of octets on top of a lower-level unreliable datagram facility (generally IP). TCP doesn't require that every transmission in one direction be followed by a transmission in the other direction. Every TCP datagram includes an explicit ack, so there can be no "implicit" acknowledgements. However, for ease of implementation, most implementations send an empty acknowledgement datagram as soon as they receive a datagram. While they could wait and try to piggy-back it on the next outgoing datagram to that host, they would also have to set a timer so that an empty ack could be sent out sooner if no outgoing data is sent soon. For applications where a large amount of data is going one way and very little goes the other way (e.g. mail transfer) this could reduce throughput, because acks would not come as soon as the receiver was actually ready to receive more. And if the acks are sent too late, the sender might end up retransmitting packets that were actually received intact. Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar