As per Relevance of the word connection, we have this rfc below:
Request for Comments: 689 May 1975
NIC #32656
TENEX NCP Finite State Machine for
TENEX Memo Number 155
The attached figure describes the finite state machine used in
version 1.33 to implement the ARPANET Host to Host protocol.
memo updates that of 27 August 1971, TENEX memo number 113,
regard to the finite state machine. Other parts of that memo
been incorporated into the JSYS manual and other documents
TENEX NCP Finite State Machine for Connections Page 2
The components of a finite state machine (FSM) are States
Events, and Actions. These are listed below
States Events
01 CLZD 00 RRFC 00
02 PNDO 01 CLSR 01
03 LSNG 02 CLSS 02
04 RFCR 03 CLZR 03
05 CLW1 04 CLZS 04
06 RFCS 05 ACPT 05
07 OPND 06 CONN 06
10 CLSW 07 LISN 07
11 DATW 10 RRFN 10
12 RFN1 11 TIME 11
13 CLZW 12 RRFB 12 AES
16 FREE 13
14
Note that there are two kinds of "close" events and actions: a
at the JSYS level (CLOSF) and one at the host-to-host protocol
(CLS). The names in the above list contain "CLS" if they
concerned with host-to-host CLS, and CLZ if the are concerned
CLOSF
Each state will be briefly described below, along with
which may occur while a connection is in that state, and actions
are taken as the state is advanced
A few overall notes: Actions are shown on the state
following a "/''. Any transition without an action shown
"ANOP", a null action. The action "AFNY" means a "funny" event (i.e.,
one not expected in this state -- probably a bug) has occurred.
result of this action is an IMPBUG error printout. Any event
shown on the state diagram causes the state to loop back to itself
an AFNY to be generated. These are not shown explicitly on
diagram. Another "funny" event is the execution of an "accept"
by the user program when the state is not RFCR. However, an
user program can do this, and no IMPBUG should be generated as
result, so most states show a loop to self with no action (i.e.,
"ANOP") as a result of the ACPT event. The event "TIME" (also
"HUNG") simply means that the socket has not changed state for
specified time interval and may need to be prodded along. This
is currently two minutes, except for connections in error states
the FSM is stepped faster to clear the connection out
State 16 - FREE - Free
A connection in this state has never existed, or is almost
deleted. No events are expected in this state except a program
(events CLZR or CLZS), or an erroneous Accept. The Accept causes
error status bit to be set (AABT - Action: abort). A
leaves the FREE state by the creation of a socket. This can be
result of a user OPENF or an incoming RFC. This causes the
TENEX NCP Finite State Machine for Connections Page 3
to move into the CLZD state
State 01 - CLZD -
This state is very transitory. Events which cause a socket to
created also immediately cause a further state change to either
(if the event was the receipt of an RFC), LSNG if the event was
Listen JSYS - i.e., an OPENF with a null extension), or RFCS (if
event was an OPENF with a foreign socket specified). In the
case, an RFC is sent to the foreign socket (ARFC).
State 02 - PNDG -
In this state, an RFC has been received, but no local program
indicated any interest in it. Events which may occur here are
LISN - a program decides to listen on the socket. Since an RFC
arrived, the FSM is stepped to the same place it would have been
the LISN and RRFC had occurred in the other order; namely RFCR
CONN - a program decides to connect to the foreign socket. This
the FSM to OPND and causes the AOPB action (open the link and send
matching RFC).
TIME - The RFC (which was unsolicited) has sat around for two
without any local program deigning to act upon it. Therefore,
clear out the tables, it is refused (ACLS - a close is sent) and
next state is CLSW to await the matching CLS
CLSR or CLSS - The site who sent the RFC has changed its mind and
a CLS, so we send the matching CLS and return the socket to the
state
State 10 - CLSW - Wait for
This state is entered when no further activity is required on
connection except the receipt of a CLS from the far end. The CLS
already been sent to the far end. In some cases, the file
CLOSF has not been done, so events CLZR and CLZS cause loops
CLSW. The expected events are CLSR or CLSS, the receipt of the
from the far end of the connection, and these step the connection
state FREE. Also, if two minutes go by without the CLS, it is
that the required CLS response was lost by the foreign site so
causes the same action
State 03 - LSNG - Listening for
In this state, no network activity has occurred. The local
is, however, waiting for some attempt at connection. This state
not time out (event TIME loops into LSNG). The program may decide
stop listening (e.g., it may simply log out of TENEX) so events
and CLZS move the connection to state FREE. The desired event is
receipt of an RFC for this socket. When an RFC arrives for a
in a state other than CLZD, it is checked to see that the byte
matches that declared by the user program. It then becomes event
if the byte size matches, or RRFB if it does not match. RRFB causes
LSNG socket to go to state CLSW and a CLS to be sent, refusing
connection. In the normal case, event RRFC steps the connection
state RFCR
TENEX NCP Finite State Machine for Connections Page 4
State 06 - RFCS - An RFC has been sent
This state is entered when a program does a Connect (an OPENF with
specific foreign socket). The RFC has been sent, and the matching
is awaited. If the foreign site refuses the request for connection
sending a CLS, events CLSR and CLSS cause the matching CLS to be
(ACLS) and the socket is stepped to FREE state. If the user
gives up waiting for the acceptance of the connection (events CLZS
CLZR), a timeout happens (TIME) or an RFC arrives but has the
byte size (RRFB), the socket is stepped to CLSW and a CLS is
(ACLS). In the case of a properly accepted connection (event RRFC),
the link tables are opened (AOPL) and the connection state goes
OPND
State 04 - RFCR - An RFC has been received
This state is reached when a Listen has been done by the user, and
RFC (with matching byte size) has been received. This state and
PNDG state make up the queueing mechanism for received RFC's.
RFC's in PNDG state are for sockets which are not listening (
another connection with the same socket number may have been
-- this is just not the first one), so they time out after
minutes. In RFCR, though, a program has done a listen. Therefore
timeouts are suppressed to allow the accept to be done (event
loops to RFCR).
If the foreign site tires of waiting for the accept, it may send a
(events CLSR or CLSS) in which case the matching CLS is sent (ACLS
and the socket moves to state FREE
Also, while in this state, the program may examine the foreign
and socket and decide to refuse the connection by doing a
(events CLZR and CLZS). This causes a CLS to be sent (action ACLS
and the socket steps to CLSW to await the matching CLS
If the program likes the request for connection, it will accept
with an MTOPR JSYS (event ACPT), causing action AOPB (sending
matching RFC and opening the link tables), and the socket steps
state OPND
State 07 - OPND - opened
This is the state during which data may be transferred. Both RFC'
have been sent. Allocation and RFNM activity are not considered
this state diagram, but until one end or the other tries to close
connection that activity proceeds at another level of the code.
exception is event TIME. After two minutes of inactivity on
socket, action ACKA (Check allocation) occurs. This action
allocate resynchronizing to occur if the foreign host is known
understand that extension to the host-host protocol
The remaining events and states are all associated with
getting a connection closed and free, from the OPND state. This
complicated. There are four initial events: closes done locally
closes from the remote end of the connection, each of which may be
a sending or a receiving connection. These are CLZR, CLZS, CLSR
CLSS
CLZR - The local program closes a connection which has been receiving
A CLS is sent (ACLS) and the state is stepped to CLW1 which is
to CLSW except that the link tables must be closed when a CLS
TENEX NCP Finite State Machine for Connections Page 5
back
CLZS - The local program closes a connection which has been sending
The state is stepped to DATW and action AEOS is performed.
(action end of send) sets a done flag which lower level routines
to signal the FSM when the last data has been sent and acknowledged
RFNM
CLSR - a CLS is received on a receive connection. This is the
"end of file" case. Action AEOR (end of receive) occurs and the
moves to CLZW. AEOR causes the same flags to be set as AEOS, and
addition (if this connection is hooked to an NVT) causes an NVT
to be performed
CLSS - a CLS is received on a send connection, before we (the
end) had closed it. Action AESl occurs, which is the same as
except that messages queued to go out are discarded. The state
to RFN2 to await the final RFNM
State 05 - CLW1 - Close wait sub 1.
This state is the same as CLSW except that a link table entry
to be cleared out. A CLS has been sent and we await the matching CLS
When it arrives, or two minutes go by, the state is stepped to
and action ACLL (close link) is performed
State 11 - DATW - Final data wait
This state is NOT the normal waiting for data on an open connection
It is only during the sending of the last of the data on a
connection which has been locally closed but which has not yet had
the data accepted by the far end
RRFN - Received final RFNM - event is the desired one. When
occurs, all the data has been sent so we send a CLS (ACLS) and go
state CLW1 to await the matching CLS
TIME may also occur. If it does, we pretend we had seen the
RFNM and act as for RRFN. This timeout may occur either because
RFNM has been lost by the IMP or the subnet, or because
unresposiveness on the part of the foreign host. The latter
occur if the amount of data to be sent when the CLOSF is done
the available allocation at that time. If the foreign host does
send allocation, or disagrees with us and thinks allocation
outstanding, the timeout will free the socket
CLSS may occur. If so, the far end has not accepted all the data,
wants to abort the connection. This is treated about as it was
it occurred from the OPND state, namely AES1 action, but must go to
different next state, RFN1, to distinguish the fact that a local
has already occurred
State 14 - RFN2 - Final RFNM wait sub 2.
This state means that an unexpected close arrived when we were
sending data. We now await the final RFNM for any outstanding
messages. When this occurs, or if there were no outstanding messages
the state moves to CLZW. ACLO is performed, sending a CLS (
the unexpected CLS which arrived during OPND) and closing the link
If two minutes go by and no final RFNM arrives, we also just go
CLZW to prevent being hung by an unresponsive foreign host or
IMP/subnet failure, also performing ACLO. This is analogous to
TENEX NCP Finite State Machine for Connections Page 6
timeout from state DATW above
While waiting for the RFNM, the local program may try to CLOSF
connection (CLZR, CLZS). If so, we go to state RFN1 and continue
await the final RFNM
State 12 - RFN1 - Final RFNM wait sub 1. In this state, it's
over but the final RFNM. When it arrives (RRFN) or two minutes go
(TIME), we close the link tables and send a CLS to the foreign
(ACLO). Since the CLS has already been received, the connection
now gone and we step it to FREE
State 13 - CLZW - Wait for program to close file
This is the normal state after an end of file when receiving,
the CLOSF (CLZR) has occurred. It is also the state of a
connection which was aborted (CLS) by the receiver (foreign host)
all sent messages have been RFNM'ed but the local CLOSF (CLZS) has
been done. We wait for the local program to do the CLOSF. When
does, we close the link table if this is a receive connection, and
either case step the connection to the FREE state
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
