From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc689.txt | 277 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 277 insertions(+) create mode 100644 doc/rfc/rfc689.txt (limited to 'doc/rfc/rfc689.txt') diff --git a/doc/rfc/rfc689.txt b/doc/rfc/rfc689.txt new file mode 100644 index 0000000..9a06e58 --- /dev/null +++ b/doc/rfc/rfc689.txt @@ -0,0 +1,277 @@ +Request for Comments: 689 May 1975 +NIC #32656 + + + + + + + TENEX NCP Finite State Machine for connections + TENEX Memo Number 155 + + + + + + + + +The attached figure describes the finite state machine used in TENEX +version 1.33 to implement the ARPANET Host to Host protocol. This +memo updates that of 27 August 1971, TENEX memo number 113, with +regard to the finite state machine. Other parts of that memo have +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 Actions + +01 CLZD 00 RRFC 00 ANOP +02 PNDO 01 CLSR 01 AFNY +03 LSNG 02 CLSS 02 ACLS +04 RFCR 03 CLZR 03 ARFC +05 CLW1 04 CLZS 04 AOPB +06 RFCS 05 ACPT 05 AOPL +07 OPND 06 CONN 06 ACLL +10 CLSW 07 LISN 07 ACLO +11 DATW 10 RRFN 10 AEOR +12 RFN1 11 TIME 11 AEOS +13 CLZW 12 RRFB 12 AES1 +16 FREE 13 AABT +14 ACKA + +Note that there are two kinds of "close" events and actions: a close +at the JSYS level (CLOSF) and one at the host-to-host protocol level +(CLS). The names in the above list contain "CLS" if they are +concerned with host-to-host CLS, and CLZ if the are concerned with +CLOSF. + +Each state will be briefly described below, along with events +which may occur while a connection is in that state, and actions which +are taken as the state is advanced. + +A few overall notes: Actions are shown on the state diagram +following a "/''. Any transition without an action shown generates +"ANOP", a null action. The action "AFNY" means a "funny" event (i.e., +one not expected in this state -- probably a bug) has occurred. The +result of this action is an IMPBUG error printout. Any event NOT +shown on the state diagram causes the state to loop back to itself and +an AFNY to be generated. These are not shown explicitly on the +diagram. Another "funny" event is the execution of an "accept" MTOPR +by the user program when the state is not RFCR. However, an errant +user program can do this, and no IMPBUG should be generated as a +result, so most states show a loop to self with no action (i.e., an +"ANOP") as a result of the ACPT event. The event "TIME" (also called +"HUNG") simply means that the socket has not changed state for a +specified time interval and may need to be prodded along. This time +is currently two minutes, except for connections in error states where +the FSM is stepped faster to clear the connection out. + +State 16 - FREE - Free connection +A connection in this state has never existed, or is almost completely +deleted. No events are expected in this state except a program CLOSF +(events CLZR or CLZS), or an erroneous Accept. The Accept causes an +error status bit to be set (AABT - Action: abort). A connection +leaves the FREE state by the creation of a socket. This can be the +result of a user OPENF or an incoming RFC. This causes the connection + +TENEX NCP Finite State Machine for Connections Page 3 + + + +to move into the CLZD state. + +State 01 - CLZD - Closed +This state is very transitory. Events which cause a socket to be +created also immediately cause a further state change to either PNDG +(if the event was the receipt of an RFC), LSNG if the event was a +Listen JSYS - i.e., an OPENF with a null extension), or RFCS (if the +event was an OPENF with a foreign socket specified). In the latter +case, an RFC is sent to the foreign socket (ARFC). + +State 02 - PNDG - Pending +In this state, an RFC has been received, but no local program has +indicated any interest in it. Events which may occur here are: +LISN - a program decides to listen on the socket. Since an RFC has +arrived, the FSM is stepped to the same place it would have been if +the LISN and RRFC had occurred in the other order; namely RFCR. +CONN - a program decides to connect to the foreign socket. This steps +the FSM to OPND and causes the AOPB action (open the link and send the +matching RFC). +TIME - The RFC (which was unsolicited) has sat around for two minutes +without any local program deigning to act upon it. Therefore, to +clear out the tables, it is refused (ACLS - a close is sent) and the +next state is CLSW to await the matching CLS. +CLSR or CLSS - The site who sent the RFC has changed its mind and sent +a CLS, so we send the matching CLS and return the socket to the FREE +state. + +State 10 - CLSW - Wait for CLS +This state is entered when no further activity is required on a +connection except the receipt of a CLS from the far end. The CLS has +already been sent to the far end. In some cases, the file system +CLOSF has not been done, so events CLZR and CLZS cause loops into +CLSW. The expected events are CLSR or CLSS, the receipt of the CLS +from the far end of the connection, and these step the connection to +state FREE. Also, if two minutes go by without the CLS, it is assumed +that the required CLS response was lost by the foreign site so TIME +causes the same action. + +State 03 - LSNG - Listening for RFC +In this state, no network activity has occurred. The local program +is, however, waiting for some attempt at connection. This state does +not time out (event TIME loops into LSNG). The program may decide to +stop listening (e.g., it may simply log out of TENEX) so events CLZR +and CLZS move the connection to state FREE. The desired event is the +receipt of an RFC for this socket. When an RFC arrives for a socket +in a state other than CLZD, it is checked to see that the byte size +matches that declared by the user program. It then becomes event RRFC +if the byte size matches, or RRFB if it does not match. RRFB causes a +LSNG socket to go to state CLSW and a CLS to be sent, refusing the +connection. In the normal case, event RRFC steps the connection to +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 a +specific foreign socket). The RFC has been sent, and the matching RFC +is awaited. If the foreign site refuses the request for connection, +sending a CLS, events CLSR and CLSS cause the matching CLS to be sent +(ACLS) and the socket is stepped to FREE state. If the user program +gives up waiting for the acceptance of the connection (events CLZS or +CLZR), a timeout happens (TIME) or an RFC arrives but has the wrong +byte size (RRFB), the socket is stepped to CLSW and a CLS is sent +(ACLS). In the case of a properly accepted connection (event RRFC), +the link tables are opened (AOPL) and the connection state goes to +OPND. + +State 04 - RFCR - An RFC has been received. +This state is reached when a Listen has been done by the user, and an +RFC (with matching byte size) has been received. This state and the +PNDG state make up the queueing mechanism for received RFC's. Queued +RFC's in PNDG state are for sockets which are not listening (although +another connection with the same socket number may have been listening +-- this is just not the first one), so they time out after two +minutes. In RFCR, though, a program has done a listen. Therefore, +timeouts are suppressed to allow the accept to be done (event TIME +loops to RFCR). +If the foreign site tires of waiting for the accept, it may send a CLS +(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 host +and socket and decide to refuse the connection by doing a CLOSF +(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 it +with an MTOPR JSYS (event ACPT), causing action AOPB (sending the +matching RFC and opening the link tables), and the socket steps to +state OPND. + +State 07 - OPND - opened. +This is the state during which data may be transferred. Both RFC's +have been sent. Allocation and RFNM activity are not considered in +this state diagram, but until one end or the other tries to close the +connection that activity proceeds at another level of the code. The +exception is event TIME. After two minutes of inactivity on the +socket, action ACKA (Check allocation) occurs. This action causes +allocate resynchronizing to occur if the foreign host is known to +understand that extension to the host-host protocol. +The remaining events and states are all associated with properly +getting a connection closed and free, from the OPND state. This gets +complicated. There are four initial events: closes done locally and +closes from the remote end of the connection, each of which may be for +a sending or a receiving connection. These are CLZR, CLZS, CLSR and +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 similar +to CLSW except that the link tables must be closed when a CLS comes + + +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. AEOS +(action end of send) sets a done flag which lower level routines use +to signal the FSM when the last data has been sent and acknowledged by +RFNM. +CLSR - a CLS is received on a receive connection. This is the normal +"end of file" case. Action AEOR (end of receive) occurs and the state +moves to CLZW. AEOR causes the same flags to be set as AEOS, and in +addition (if this connection is hooked to an NVT) causes an NVT DETACH +to be performed. +CLSS - a CLS is received on a send connection, before we (the sending +end) had closed it. Action AESl occurs, which is the same as AEOS +except that messages queued to go out are discarded. The state moves +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 remains +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 FREE +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 send +connection which has been locally closed but which has not yet had all +the data accepted by the far end. +RRFN - Received final RFNM - event is the desired one. When this +occurs, all the data has been sent so we send a CLS (ACLS) and go to +state CLW1 to await the matching CLS. +TIME may also occur. If it does, we pretend we had seen the final +RFNM and act as for RRFN. This timeout may occur either because an +RFNM has been lost by the IMP or the subnet, or because of +unresposiveness on the part of the foreign host. The latter could +occur if the amount of data to be sent when the CLOSF is done exceeds +the available allocation at that time. If the foreign host does not +send allocation, or disagrees with us and thinks allocation is +outstanding, the timeout will free the socket. +CLSS may occur. If so, the far end has not accepted all the data, but +wants to abort the connection. This is treated about as it was when +it occurred from the OPND state, namely AES1 action, but must go to a +different next state, RFN1, to distinguish the fact that a local CLOSF +has already occurred. + +State 14 - RFN2 - Final RFNM wait sub 2. +This state means that an unexpected close arrived when we were happily +sending data. We now await the final RFNM for any outstanding data +messages. When this occurs, or if there were no outstanding messages, +the state moves to CLZW. ACLO is performed, sending a CLS (matching +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 to +CLZW to prevent being hung by an unresponsive foreign host or an +IMP/subnet failure, also performing ACLO. This is analogous to the + +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 the +connection (CLZR, CLZS). If so, we go to state RFN1 and continue to +await the final RFNM. + +State 12 - RFN1 - Final RFNM wait sub 1. In this state, it's all +over but the final RFNM. When it arrives (RRFN) or two minutes go by +(TIME), we close the link tables and send a CLS to the foreign site +(ACLO). Since the CLS has already been received, the connection is +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, before +the CLOSF (CLZR) has occurred. It is also the state of a send +connection which was aborted (CLS) by the receiver (foreign host) when +all sent messages have been RFNM'ed but the local CLOSF (CLZS) has not +been done. We wait for the local program to do the CLOSF. When it +does, we close the link table if this is a receive connection, and in +either case step the connection to the FREE state. -- cgit v1.2.3