John has described the three-way handshake, which is used for session establishment. Once the session has been established, both sides sequence their bytes that they send and both sides ACK the other side's bytes. Remember it's a stream-oriented protocol. Each side has a stream of bytes it needs to send.
When a sender sends data, the sequence number that it puts in the packet is the sequence number of the first byte in the packet. The packet has a certain number of bytes in it, that is, a length. You should expect the sequence number in the next packet from this sender to be (seq + length) -1. The sender will keep sending as long as it has not gotten to the end of its send window. Then it must stop and wait for an ACK from the other side. The sender's send window is based on the recipient's receive window. The recipient states the size of its receive window in every packet. It is an indication of how much memory the recipient has for receiving bytes and how much is used up at this point in time. The recipient ACKs every byte, but not explicitly. The recipient sends a packet with the ACK bit set and the ACK number set to the next byte that the recipient expects to receive. By stating the next byte it expects to receive, the recipient acknowledges receiving the bytes before this. The recipients is not required to send an ACK the instant it receives data. In fact, a host can reduce network overhead and increase efficiency by sending fewer ACKs. This is known as delayed ACKs. The "Host Requirements RFC" (RFC 1122) states that a TCP implementation should implement delayed ACKs, but an ACK should not be excessively delayed. In particular, the delay must be less than 0.5 seconds, and when receiving a stream of full-sized segments, there should be an ACK for at least every second segment. Most implementations do not wait a full 0.5 seconds, which would seem awfully long on modern networks. Upon receipt of a TCP segment, a host sets an ACK timer. When the timer elapses, the host acknowledges data received so far. A typical value for the ACK timer is 0.2 seconds. One reason for delaying an ACK is that the host may have its own data to send in the same direction as the ACK. The data can be sent with the ACK, which avoids extra network traffic caused by so-called empty ACKs. An ACK that is sent with data is sometimes called a piggyback ACK. All of this is best described with an example. However, that would take too long in this forum. But stay tuned for my new book which will have examples. I have finished the writing. I'm still waiting for the publisher to do their business. Priscilla At 09:21 PM 3/24/02, John Green wrote: >i know there are many more knowledgeable here but just >lets get started with this thread. > >Source sends a syn packet to the destination and this >packet contains sequence number(say x) and ACK bit not >set >The destination receives it and sends a syn and ack. >this packet contains its sequence number(say y) and >ACK bit or flag is set >Source recieves the syn and ack and sends back an >ack back to destination. > >destination receives the ack and tcp connection is >established henceforth. >Refer RFC 793 for further details. (but any tcp/ip >book would deal with this) > >--- Juan Blanco wrote: > > Team, > > > > Do any one knows where I could find any document > > that explain how calculate > > the TCP Ack and Seq numbers. Any explanation will be > > appreciate. > > > > Thanks, > > > > > > JB >[EMAIL PROTECTED] > > >__________________________________________________ >Do You Yahoo!? >Yahoo! Movies - coverage of the 74th Academy Awards. >http://movies.yahoo.com/ ________________________ Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=39442&t=39393 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
