home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 600s / rfc689.txt < prev    next >
Text File  |  1992-10-14  |  13KB  |  278 lines

  1. Request for Comments: 689                                              May 1975
  2. NIC #32656
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.              TENEX NCP Finite State Machine for connections
  10.                         TENEX Memo Number 155
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19. The attached figure describes the finite state machine used in TENEX
  20. version 1.33 to implement the ARPANET Host to Host protocol. This
  21. memo updates that of 27 August 1971, TENEX memo number 113, with
  22. regard to the finite state machine. Other parts of that memo have
  23. been incorporated into the JSYS manual and other documents.
  24.  
  25.  
  26. TENEX NCP Finite State Machine for Connections                           Page 2
  27.  
  28.  
  29.  
  30. The components of a finite state machine (FSM) are States,
  31. Events, and Actions. These are listed below:
  32.  
  33. States Events Actions
  34.  
  35. 01 CLZD 00 RRFC 00 ANOP
  36. 02 PNDO 01 CLSR 01 AFNY
  37. 03 LSNG 02 CLSS 02 ACLS
  38. 04 RFCR 03 CLZR 03 ARFC
  39. 05 CLW1 04 CLZS 04 AOPB
  40. 06 RFCS 05 ACPT 05 AOPL
  41. 07 OPND 06 CONN 06 ACLL
  42. 10 CLSW 07 LISN 07 ACLO
  43. 11 DATW 10 RRFN 10 AEOR
  44. 12 RFN1 11 TIME 11 AEOS
  45. 13 CLZW 12 RRFB 12 AES1
  46. 16 FREE 13 AABT
  47. 14 ACKA
  48.  
  49. Note that there are two kinds of "close" events and actions: a close
  50. at the JSYS level (CLOSF) and one at the host-to-host protocol level
  51. (CLS). The names in the above list contain "CLS" if they are
  52. concerned with host-to-host CLS, and CLZ if the are concerned with
  53. CLOSF.
  54.  
  55. Each state will be briefly described below, along with events
  56. which may occur while a connection is in that state, and actions which
  57. are taken as the state is advanced.
  58.  
  59. A few overall notes: Actions are shown on the state diagram
  60. following a "/''. Any transition without an action shown generates
  61. "ANOP", a null action. The action "AFNY" means a "funny" event (i.e.,
  62. one not expected in this state -- probably a bug) has occurred. The
  63. result of this action is an IMPBUG error printout. Any event NOT
  64. shown on the state diagram causes the state to loop back to itself and
  65. an AFNY to be generated. These are not shown explicitly on the
  66. diagram. Another "funny" event is the execution of an "accept" MTOPR
  67. by the user program when the state is not RFCR. However, an errant
  68. user program can do this, and no IMPBUG should be generated as a
  69. result, so most states show a loop to self with no action (i.e., an
  70. "ANOP") as a result of the ACPT event. The event "TIME" (also called
  71. "HUNG") simply means that the socket has not changed state for a
  72. specified time interval and may need to be prodded along. This time
  73. is currently two minutes, except for connections in error states where
  74. the FSM is stepped faster to clear the connection out.
  75.  
  76. State 16 - FREE - Free connection
  77. A connection in this state has never existed, or is almost completely
  78. deleted. No events are expected in this state except a program CLOSF
  79. (events CLZR or CLZS), or an erroneous Accept. The Accept causes an
  80. error status bit to be set (AABT - Action: abort). A connection
  81. leaves the FREE state by the creation of a socket. This can be the
  82. result of a user OPENF or an incoming RFC. This causes the connection
  83.  
  84. TENEX NCP Finite State Machine for Connections                           Page 3
  85.  
  86.  
  87.  
  88. to move into the CLZD state.
  89.  
  90. State 01 - CLZD - Closed
  91. This state is very transitory. Events which cause a socket to be
  92. created also immediately cause a further state change to either PNDG
  93. (if the event was the receipt of an RFC), LSNG if the event was a
  94. Listen JSYS - i.e., an OPENF with a null extension), or RFCS (if the
  95. event was an OPENF with a foreign socket specified). In the latter
  96. case, an RFC is sent to the foreign socket (ARFC).
  97.  
  98. State 02 - PNDG - Pending
  99. In this state, an RFC has been received, but no local program has
  100. indicated any interest in it. Events which may occur here are:
  101. LISN - a program decides to listen on the socket. Since an RFC has
  102. arrived, the FSM is stepped to the same place it would have been if
  103. the LISN and RRFC had occurred in the other order; namely RFCR.
  104. CONN - a program decides to connect to the foreign socket. This steps
  105. the FSM to OPND and causes the AOPB action (open the link and send the
  106. matching RFC).
  107. TIME - The RFC (which was unsolicited) has sat around for two minutes
  108. without any local program deigning to act upon it. Therefore, to
  109. clear out the tables, it is refused (ACLS - a close is sent) and the
  110. next state is CLSW to await the matching CLS.
  111. CLSR or CLSS - The site who sent the RFC has changed its mind and sent
  112. a CLS, so we send the matching CLS and return the socket to the FREE
  113. state.
  114.  
  115. State 10 - CLSW - Wait for CLS
  116. This state is entered when no further activity is required on a
  117. connection except the receipt of a CLS from the far end. The CLS has
  118. already been sent to the far end. In some cases, the file system
  119. CLOSF has not been done, so events CLZR and CLZS cause loops into
  120. CLSW. The expected events are CLSR or CLSS, the receipt of the CLS
  121. from the far end of the connection, and these step the connection to
  122. state FREE. Also, if two minutes go by without the CLS, it is assumed
  123. that the required CLS response was lost by the foreign site so TIME
  124. causes the same action.
  125.  
  126. State 03 - LSNG - Listening for RFC
  127. In this state, no network activity has occurred. The local program
  128. is, however, waiting for some attempt at connection. This state does
  129. not time out (event TIME loops into LSNG). The program may decide to
  130. stop listening (e.g., it may simply log out of TENEX) so events CLZR
  131. and CLZS move the connection to state FREE. The desired event is the
  132. receipt of an RFC for this socket. When an RFC arrives for a socket
  133. in a state other than CLZD, it is checked to see that the byte size
  134. matches that declared by the user program. It then becomes event RRFC
  135. if the byte size matches, or RRFB if it does not match. RRFB causes a
  136. LSNG socket to go to state CLSW and a CLS to be sent, refusing the
  137. connection. In the normal case, event RRFC steps the connection to
  138. state RFCR.
  139.  
  140.  
  141. TENEX NCP Finite State Machine for Connections                           Page 4
  142.  
  143.  
  144. State 06 - RFCS - An RFC has been sent.
  145. This state is entered when a program does a Connect (an OPENF with a
  146. specific foreign socket). The RFC has been sent, and the matching RFC
  147. is awaited. If the foreign site refuses the request for connection,
  148. sending a CLS, events CLSR and CLSS cause the matching CLS to be sent
  149. (ACLS) and the socket is stepped to FREE state. If the user program
  150. gives up waiting for the acceptance of the connection (events CLZS or
  151. CLZR), a timeout happens (TIME) or an RFC arrives but has the wrong
  152. byte size (RRFB), the socket is stepped to CLSW and a CLS is sent
  153. (ACLS). In the case of a properly accepted connection (event RRFC),
  154. the link tables are opened (AOPL) and the connection state goes to
  155. OPND.
  156.  
  157. State 04 - RFCR - An RFC has been received.
  158. This state is reached when a Listen has been done by the user, and an
  159. RFC (with matching byte size) has been received. This state and the
  160. PNDG state make up the queueing mechanism for received RFC's. Queued
  161. RFC's in PNDG state are for sockets which are not listening (although
  162. another connection with the same socket number may have been listening
  163. -- this is just not the first one), so they time out after two
  164. minutes. In RFCR, though, a program has done a listen. Therefore,
  165. timeouts are suppressed to allow the accept to be done (event TIME
  166. loops to RFCR).
  167. If the foreign site tires of waiting for the accept, it may send a CLS
  168. (events CLSR or CLSS) in which case the matching CLS is sent (ACLS)
  169. and the socket moves to state FREE.
  170. Also, while in this state, the program may examine the foreign host
  171. and socket and decide to refuse the connection by doing a CLOSF
  172. (events CLZR and CLZS). This causes a CLS to be sent (action ACLS)
  173. and the socket steps to CLSW to await the matching CLS.
  174. If the program likes the request for connection, it will accept it
  175. with an MTOPR JSYS (event ACPT), causing action AOPB (sending the
  176. matching RFC and opening the link tables), and the socket steps to
  177. state OPND.
  178.  
  179. State 07 - OPND - opened.
  180. This is the state during which data may be transferred. Both RFC's
  181. have been sent. Allocation and RFNM activity are not considered in
  182. this state diagram, but until one end or the other tries to close the
  183. connection that activity proceeds at another level of the code. The
  184. exception is event TIME. After two minutes of inactivity on the
  185. socket, action ACKA (Check allocation) occurs. This action causes
  186. allocate resynchronizing to occur if the foreign host is known to
  187. understand that extension to the host-host protocol.
  188. The remaining events and states are all associated with properly
  189. getting a connection closed and free, from the OPND state. This gets
  190. complicated. There are four initial events: closes done locally and
  191. closes from the remote end of the connection, each of which may be for
  192. a sending or a receiving connection. These are CLZR, CLZS, CLSR and
  193. CLSS.
  194. CLZR - The local program closes a connection which has been receiving.
  195. A CLS is sent (ACLS) and the state is stepped to CLW1 which is similar
  196. to CLSW except that the link tables must be closed when a CLS comes
  197.  
  198.  
  199. TENEX NCP Finite State Machine for Connections                           Page 5
  200.  
  201.  
  202. back.
  203. CLZS - The local program closes a connection which has been sending.
  204. The state is stepped to DATW and action AEOS is performed. AEOS
  205. (action end of send) sets a done flag which lower level routines use
  206. to signal the FSM when the last data has been sent and acknowledged by
  207. RFNM.
  208. CLSR - a CLS is received on a receive connection. This is the normal
  209. "end of file" case. Action AEOR (end of receive) occurs and the state
  210. moves to CLZW. AEOR causes the same flags to be set as AEOS, and in
  211. addition (if this connection is hooked to an NVT) causes an NVT DETACH
  212. to be performed.
  213. CLSS - a CLS is received on a send connection, before we (the sending
  214. end) had closed it. Action AESl occurs, which is the same as AEOS
  215. except that messages queued to go out are discarded. The state moves
  216. to RFN2 to await the final RFNM.
  217.  
  218. State 05 - CLW1 - Close wait sub 1.
  219. This state is the same as CLSW except that a link table entry remains
  220. to be cleared out. A CLS has been sent and we await the matching CLS.
  221. When it arrives, or two minutes go by, the state is stepped to FREE
  222. and action ACLL (close link) is performed.
  223.  
  224. State 11 - DATW - Final data wait.
  225. This state is NOT the normal waiting for data on an open connection.
  226. It is only during the sending of the last of the data on a send
  227. connection which has been locally closed but which has not yet had all
  228. the data accepted by the far end.
  229. RRFN - Received final RFNM - event is the desired one. When this
  230. occurs, all the data has been sent so we send a CLS (ACLS) and go to
  231. state CLW1 to await the matching CLS.
  232. TIME may also occur. If it does, we pretend we had seen the final
  233. RFNM and act as for RRFN. This timeout may occur either because an
  234. RFNM has been lost by the IMP or the subnet, or because of
  235. unresposiveness on the part of the foreign host. The latter could
  236. occur if the amount of data to be sent when the CLOSF is done exceeds
  237. the available allocation at that time. If the foreign host does not
  238. send allocation, or disagrees with us and thinks allocation is
  239. outstanding, the timeout will free the socket.
  240. CLSS may occur. If so, the far end has not accepted all the data, but
  241. wants to abort the connection. This is treated about as it was when
  242. it occurred from the OPND state, namely AES1 action, but must go to a
  243. different next state, RFN1, to distinguish the fact that a local CLOSF
  244. has already occurred.
  245.  
  246. State 14 - RFN2 - Final RFNM wait sub 2.
  247. This state means that an unexpected close arrived when we were happily
  248. sending data. We now await the final RFNM for any outstanding data
  249. messages. When this occurs, or if there were no outstanding messages,
  250. the state moves to CLZW. ACLO is performed, sending a CLS (matching
  251. the unexpected CLS which arrived during OPND) and closing the link.
  252. If two minutes go by and no final RFNM arrives, we also just go to
  253. CLZW to prevent being hung by an unresponsive foreign host or an
  254. IMP/subnet failure, also performing ACLO. This is analogous to the
  255.  
  256. TENEX NCP Finite State Machine for Connections                           Page 6
  257.  
  258.  
  259. timeout from state DATW above.
  260. While waiting for the RFNM, the local program may try to CLOSF the
  261. connection (CLZR, CLZS). If so, we go to state RFN1 and continue to
  262. await the final RFNM.
  263.  
  264. State 12 - RFN1 - Final RFNM wait sub 1. In this state, it's all
  265. over but the final RFNM. When it arrives (RRFN) or two minutes go by
  266. (TIME), we close the link tables and send a CLS to the foreign site
  267. (ACLO). Since the CLS has already been received, the connection is
  268. now gone and we step it to FREE.
  269.  
  270. State 13 - CLZW - Wait for program to close file.
  271. This is the normal state after an end of file when receiving, before
  272. the CLOSF (CLZR) has occurred. It is also the state of a send
  273. connection which was aborted (CLS) by the receiver (foreign host) when
  274. all sent messages have been RFNM'ed but the local CLOSF (CLZS) has not
  275. been done. We wait for the local program to do the CLOSF. When it
  276. does, we close the link table if this is a receive connection, and in
  277. either case step the connection to the FREE state.
  278.