3.4. Closing a Connection

Either side may choose to close an established connection. This is accomplished by sending a packet with the FIN control bit set. No data may appear in a FIN packet. The other end of the connection responds by shutting down its end of the connection and sending a FIN, ACK in response.

Side A Side B

1. ESTABLISHED ESTABLISHED

2. [CLOSE request from user] FIN-WAIT --> <SN=0><AN=1><CTL=FIN> ...

3. --> LAST-ACK ... <SN=1><AN=1><CTL=FIN,ACK> <--

4. TIME-WAIT <-- --> <SN=1><AN=0><CTL=ACK> ...

5. --> CLOSED

6. (after 2*SRTT time passes) CLOSED

In line 2 the user on side A of the fully opened connection has decided to close it down by issuing a CLOSE call. No more data will be accepted for sending. If data remains unsent a message "Warning: Unsent data remains." is communicated to the user. No more data will be received. A packet containing a FIN but no data is constructed and sent. Side A goes into the FIN-WAIT state.

Side B sees the FIN sent and immediately builds a FIN, ACK packet in response. It then goes into the LAST-ACK state. The FIN, ACK packet is received by side A and an answering ACK is immediately sent. Side A then goes to the TIME-WAIT state. In line 5 side B receives the final acknowledgment of its FIN, ACK packet and goes to the CLOSED state. In line 6 after waiting to be sure its last acknowledgment was received side A goes to the CLOSED state (SRTT is the Smoothed Round Trip Time and is defined in section 6.3.1).

4. Packet Reception

The act of receiving a packet is relatively straightforward. There are a few points which deserve some discussion. This chapter will discuss packet reception stage by stage in time order.

Synch Detection

The first stage in the reception of a packet is the discovery of a SYNCH pattern. Octets are read continuously and discarded until the SYNCH pattern is seen. Once SYNCH has been observed proceed to the Header Reception stage.

Header Reception

The remainder of the header is three octets in length. No further processing can continue until the complete header has been read. Once read the header checksum test is performed. If this test fails it is assumed that the current SYNCH pattern was the result of a data error. Since the correct SYNCH may appear immediately after the current one, go back to the Synch Detection stage but treat the three octets of the header following the bad SYNCH as new input.

If the header checksum test succeeds then proceed to the Data Reception stage.

Data Reception

A determination of the remaining length of the packet is made. If either of the SYN, RST, SO, or FIN flags are set then legally the entire packet has already been read and it is considered to have 'arrived'. No data portion of a packet is present when one of those flags is set. Otherwise the LENGTH field specifies the remaining amount of data to read. In this case if the LENGTH field is zero then the packet contains no data portion and it is considered to have arrived.

We now assume that a data portion is present and LENGTH was non-zero. Counting the data checksum LENGTH+2 octets must now be read. Once read the data checksum test is performed. If this test fails the entire packet is discarded, return to the Synch Detection stage. If the test succeeds then the packet is considered to have arrived. Once arrived the packet is released to the upper level protocol software. In a multiprocess implementation packet reception would now begin again at the Synch Detection stage.

5. Functional Specification

A convenient model for the discussion and implementation of protocols is that of a state machine. A connection can be thought of as passing through a variety of states, with possible error conditions, from its inception until it is closed. In such a model each state represents a known point in the history of a connection. The connection passes from state to state in response to events. These events are caused by user calls to the protocol interface (a request to open or close a connection, data to send, etc.), incoming packets, and timeouts.

Information about a connection must be maintained at both ends of that connection. Following the terminology of [TCP 81] the information necessary to the successful operation of a connection is called the Transmission Control Block or TCB. The user requests to the protocol interface are OPEN, SEND, RECEIVE, ABORT, STATUS, and CLOSE.

This chapter is broken up into three parts. First a brief description of each protocol state will be presented. Following this is a slightly more detailed look at the allowed transitions which occur between states. Finally a detailed discussion of the behavior of each state is given.