VII. Connection Status
An excellent mechanism for describing the sequence of events required to establish and terminate a connection involves a state diagram. We may assume that each socket can be associated with a state machine, and that this state machine may, at any time, be in one of ten possible states. In any state, certain network events cause the connection status to enter another state; other events are ignored; still others are error. A transition may also involve the local NCP performing some action. Figure 7.1 depicts the state machine. Circles [now boxes: Ed] represent states (described below); arrows show legal transitions between states. The labels on the arrows identify the event which caused them (note that CLOSE is a system call, CLS is a control command). Phrases after slashes denote the action which should be performed while traveling over that arrow. The arrow labeled '[E]RFC' (found between states 0 and 1) represents the condition that whenever a connection enters the CLOSED state, the pending call queue for that connection is checked [Original was backwards "E": Ed.]
If any pending calls exist in the queue, the connection moves to the PENDING state. If an RFC is received for a socket in the CLOSED state, it is also moved along this path to the PENDING state. Events and the actions they cause are described in sections VIII and IX below. Descriptions of the ten states follow:
(0) CLOSED
The local socket is not attached to any port and no user has requested a connection with it. (The table entry is non-existent).
(1) PENDING CALL
The socket is not attached to any port but one or more requests for connection have been received. A LISTEN system call will be satisfied immediately by the first entry in the pending call queue for a matching request; all other pending calls are deleted.
(2) LISTENING
The socket is attached to a port. We are waiting for a user to request connection with this socket.
(3) RFC-RCVD
We are listening and an RFC was received. The local user has been informed of the pending call. He must respond with either a CLOSE or an ACCEPT.
(4) ABORT
We have notified the user that his LISTEN has been satisfied but he has not yet responded; if during this time the foreign user aborts the connection by sending a CLS, we send a CLS to acknowledge the abort and mark the fact with this state. When the user accepts or refuses the call, we can inform him the connection has been prematurely terminated.
(5) RFC-SENT
This state is entered when:
- a) The local user has attached this socket to a port by issuing a CONNECT.
- b) An RFC has been sent, and
- c) No reply has been received.
When the user issues a CONNECT the pending call queue is searched.
If a matching RFC is not found, the queue is deleted and this state is entered. As new RFC's arrive they are compared with our user's request. If they do not match, the RFC is immediately refused. If the RFC matches, it completes the initialization process and the connection enters the OPEN state.
(6) OPEN
RFC's have been exchanged and the connection is securely established. Transmission may begin following receipt of an ALL command from the receive side, and will then proceed subject to flow control.
(7) CLS-WAIT
After the local user has executed a CLOSE, and we have issued a CLS, we must wait for an acknowledging CLS before the connection can be completely closed. If the appropriate CLS has not already been received, this state is entered.
(8) DATA-WAIT
If we are on the send side and the local user executes a CLOSE system call, a CLS cannot be issued if our data buffer is not empty or if a RFNM for the last data message is outstanding. The connection enters this state to wait for these conditions to be fulfilled. Upon completion and acknowledgement of output a CLS may be issued and the connection enters the CLS-WAIT state, waiting for the acknowledging CLS. If a CLS arrives while in the DATA-WAIT state we clear our buffer (the CLS came from a receive socket, indicating it is no longer interested in our data) and enter the RFNM-WAIT state to wait for the network to clear.
(9) RFNM-WAIT
If we are on the send side and a CLS command arrives, we cannot issue an acknowledging CLS if we have not received the RFNM for our last data message. We enter this state to await the RFNM, and cease all further data transmission. When the RFNM comes in, a CLS may then be issued, and the connection will be closed.
______________
| | CLOSE
CONN/ | CLOSED |<---------------------------+
send RFC | (0) | LISTEN |
+----------------| |-----------------------+ |
| |______________| | |
| | ^ | |
| [E]RFC | | CLS/send CLS | |
| ___V____|____ ___V____|____
| non-matching | | | |
| CONN/send RFC | PENDING | LISTEN RFC | LISTENING |
| +-------------| (1) |----------+ +----| (2) |
| | |_____________| | | |_____________|
| | matching | | |
___V___V_____ CONN/send RFC| __V___V______
| | | ACCEPT/ | | CLS/
| RFC-SENT | RFC | send RFC | RFC-RECD | send CLS
| (5) |----------+ | +----------| (3) |---------+
|_____________| | | | |_____________| |
| | | | | | |
| | ___V___V___V___ SND&CLOSE | ____________ |
| | RCV&CLS/ | |-----------)->| | |
| | send CLS | OPEN | SND&CLS | | DATA-WAIT | |
| | +---------| (6) |--------+ | | (8) | |
| | | |_______________| | | |____________| |
| | | RCV&CLOSE/ | | | | |
| | | send CLS | | | | |
| | | | | | | CLS |
| | | ______V______ | | | |
| | | CLOSE/ | |CLOSE/ | | | |
| | | send CLS| CLS-WAIT |send CLS | | | |
| +---)--------->| (8) |<--------)--+ | |
| | |_____________| | | |
| | | ___V______V_ ______V___
| | | | | | |
| | | | RFNM-WAIT | | ABORT |
| | CLS | | (9) | | (4) |
| | | |____________| |__________|
| | | | |
| | ______V_______ RFNM/ | |
| | | | send CLS | |
| CLS/ +--------->| CLOSED |<----------+ |
| send CLS | (0) | ACCEPT|CLOSE |
+----------------->| |<----------------------------+
|______________|
Figure 7.1: Connection State Diagram