TCP Flow control


Flow control is associated with the current byte sequence numbers at each end of the data flow. Whenever a segment is sent it includes the sequence number of the last byte sent. A segment will also include the sequence number of the next byte that the sending host expects to receive, this is called the acknowledgment number (ACK). A host receiving a segment can assume that the remote host has safely received all bytes up to and including byte ACK-1, local copies may now be discarded.

The difference between the number of the last byte sent and the acknowledgment number is known as the window. The maximum size of the window is advertised by a host as part of every TCP segment the host sends, a host can quench the flow of data from a remote host by advertising a window size of zero. Once a zero window size advertisement has been received a host can no longer send data. A host may not, under any circumstances, send data with byte sequence numbers greater than the sum of the remote acknowledgment number and the remote window. Under normal circumstances the remote window can be thought of as a buffer where out-of-sequence segments are held temporarily awaiting the filling in of gaps in the sequence when delayed data turns up.

Window size is not negotiated. It is up to the sender not to over-run the receiver's buffers. A small sender buffer constraint will only mean that the sender cannot take full advantage of the receiver's buffering capabilities.

The following portion of a byte stream is broken into segments as indicated below. It is here assumed that sequence numbering starts at zero.



The building up of a copy of the byte stream by the receiver is shown below. The dotted box shows the receiver window.



The following steps are shown


Segment 1 has arrived at the receiver which acknowledges it by sending an ACK segment with ACK=1000 and WIN=1600. Since ACK+WIN=2600 the sender can send segments 2,3 and 4. Segments 2 and 3 are sent.
Segment 3 has arrived but segment 2 has been delayed. The receiver sends another ACK segment with ACK=1000 and WIN=1600. The sender sends segment 4.
Segment 4 has arrived but segment 2 is still outstanding. Again the receiver sends ACK=1000, WIN=1600. However the sender cannot send segment 5 since it would take the sent sequence number to 2800 which is greater than ACK+WIN. The sender cannot do anything further unless
Segment 5 is split into smaller segments to use up the remaining part of the window. This leads to the silly window syndrome.
There is a time out.
Segment 2 reaches the receiver and the receiver announces a new ACK value.


The delayed segment 2 now reaches the receiver which sends ACK=2400 and WIN=1600 allowing the sender to send up to 4000. The initial values of the sequence numbers are exchanged during the connection establishment sequence.

The flow control mechanism shown above is usually called a sliding window protocol. The numbered packets used by X.25 are also handled in this fashion, however in X.25 the numbering is applied on a per packet basis rather than a per byte basis.

A receiver is not required to explicitly and separately acknowledge every incoming segment. A receiver may typically wait up to 200 mS before sending an acknowledgment, this can be troublesome for interactive applications. Acknowledgments can, of course, be included in the return data flow.

If a receiver has advertised a window size of zero as a flow quenching mechanism, it will subsequently "open" the window by sending a further ACK with the updated window value, this is known as a window update, it need not necessarily carry any data. A particular problem arises if the window update is lost, this problem is handled by the sender sending peridoic probes as determined by the persist timer. Such probes will include the next character which the receiver can discard by not acknowledging.

Opening a TCP connection
A TCP connection is opened by a three-way handshake to establish a common view of the sequence numbers. A connection will be initiated by an active client, the other end of the connection is described as the passive client, although in terms of the client/server software model this is likely to be a server. The passive client should be in a state known as LISTEN which simply means that it is expecting an incoming connection request.

The three way exchange involves the active client sending a SYN segment with the sequence number set to an arbitrary value (J). The passive client responds with a SYN segment with the acknowledgment number set to J+1 and the sequence number set to a further arbitrary value (K). The active client responds to the SYN segment by sending an ACK segment with the acknowledgment number set to K+1.

Hosted by Mywebcities.com

MyWebCities.Com hosted sites top list
The sites with 50 visitors per day listed here
Ferdin page Polio page Munkey page Perla page Dext page
Emv page Virus page Travel page Tcp-flow page TCP page
PC term page Test page Mike page Geog page Hanker page
Science page PC tips page Money page Med page Astro page