rfc705.txt

RFC 相关的技术文档

FEP is device independent.  For the present however, an initial implementation
will be accomplished using the DEC PDP/11 computer as the FE device and the
front-end software is to be based upon an extended version of the original ELF
system developed at SCRL.

For more detailed information, see Appendix C.

	by :								  9
		G. W. Bailey	(BAILEY@OFFICE-1)
		K. McCloghrie   (MCCLOGHRIE@OFFICE-1)


                        ***WORKING DOCUMENT***


                                  28


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


                              APPENDIX A				  10

                              References


[1]	ICP is used in this document in a less strict manner than specified
	in NIC 7101, in that it is not necessarily two simplex connections
	that are set up as the result of the exchange of the socket number
	on the initial connection.

[2]	An example of connections needing to be affiliated, is in the
	implementation of FTP, where the control connection and the data
	connection have a defined relationship in their socket assignments.

[3]	Note that a range of socket numbers is reserved for use by an index
	when it is set-up (cf. AEN).

	However, socket numbers for the paths of an index are not necessarily
	contiguous.  For instance, when the next path opened after a SEND
	path is another SEND path, or when a path other than the first of an
	index is opened with ICP specified.  Nevertheless, if a protocol
	requires contiguous sockets, then the opening of the paths in a logical
	manner will provide the contiguity.

[4]	One possible translation will be from a Network Virtual Terminal on
	the network side to a local terminal type on the Host side.

[5]	The FE will directly equate the INTERRUPT command with the Host-Host
	protocol INR/INS commands.

[6]	Note that the READY indication in a REPLY is, in the general case,
	not directly related to a network RFNM; unless it is heavily loaded, 
	the FE will be buffering possibly more than one message (in either
	direction) until flow control mechanism allow the messages to be sent
	on.

	However, it is possible that a particular Host might wish to have
	knowledge of receipt of a previous message before transmitting the
	next.  In this case, the FEP implementation could be set up to only
	indicate READY after receiving the RFNM and possibly only send RFNMs
	after receiving a REPLY containing an ACK.


                        ***WORKING DOCUMENT***


                                  29


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


                              APPENDIX B				  11

                            State Diagrams



In the state diagrams below the following notation is used:

	REPLY(A)    - REPLY with ACK=1, READY/NOT-READY irrelevant
	REPLY(N)    - REPLY with NAK=1, READY/NOT-READY irrelevant
	REPLY(R)    - REPLY with ACK=0, NAK=0, READY=1
	REPLY(A+R)  - REPLY with ACK=1, READY=1
	REPLY(N+R)  - REPLY with NAK=1, READY=1
	REPLY(A+NR) - REPLY with ACK=1, NOT-READY=1
	REPLY(N+NR) - REPLY with NAK=1, NOT-READY=1



                       State Diagram for INDEX



	/ ------\                   /-------\           /-----\
	!       !BEGIN(new index)   !       !           !     !
	!       !->--------------->-!Index  !           !     !
	!Index  !LISTEN(new index)  !Open   !           !     !
	!Closed !                   !Pending!           !Index!
	!       !           REPLY(N)!       !REPLY(A)   !Open !
	!       !-<---------------<-!       !->------->-!     !
	!       !                   \-------/           !     !
	!       !                                       !     !
	!       !             /-------\      END(Path=0)!     !
	!       !             !       !-<-------------<-!     !
	!       !     REPLY(A)!Index  !                 !     !
	!       !-<---------<-!Close  !REPLY(N)         !     !
	!       !             !Pending!->------------->-!     !
        \-------/             \-------/                 \-----/



                        ***WORKING DOCUMENT***


                                  30


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


                        APPENDIX B (continued)

                     State Diagram for Whole Path


	/------\BEGIN       /----------\
	!      !->-------->-!          !
	!      !LISTEN      !Connection!               
	!Path  !            !Pending   !REPLY(A)        /-------\
	!Closed!    REPLY(N)!          !->------------>-!       !
	!      !-<--------<-!          !                !       !
	!      !            \----------/                !Path   !
	!      !                                        !Conn-  !
	!      !            /-----\     RESPONSE(CODE>0)! ecting!
	!      !            !     !-<-----------------<-!       !
	!      !            !Path !                     !       !
	!      !    REPLY(A)!Abort!          END(PATH>0)!       !
	!      !-<--------<-!Pend-!-<-----------------<-!       !
	!      !            ! ing !                     !       !
	!      !            !     !REPLY(N)             !       !
	\------/            !     !->----------------->-!       !
                            \-----/                     !       !
                                                        !       !
                             /-------\                  !       !
                             !       !  RESPONSE(CODE=0)!       !
           /----\            !Path   !-<--------------<-!       !
	   !    !            !Open   !                  !       !
	   !Path!            !Pending!REPLY(N)          !       !
           !Open!    REPLY(A)!       !->-------------->-!       !
	   !    !-<--------<-!       !                  \-------/
	   \----/            \-------/









                        ***WORKING DOCUMENT***


                                  31


RFC 705
Front-End protocol


                        ***WORKING DOCUMENT***



                        APPENDIX B (continued)

               State Diagram for Each Direction of Path




	/----\MESSAGE             /-------\             /-------\
	!    !->---------------->-!       !REPLY(A+NR)  !       !
	!Path!INTERRUPT           !Command!->--------->-!Message!
	!Open!                    !Blocked!REPLY(N+NR)  !Blocked!
	!    !                    !       !             !       !
	!    !          REPLY(A+R)!       !    INTERRUPT!       !
	!    !-<----------------<-!       !-<---------<-!       !
	!    !          REPLY(N+R)\-------/             !       !
	!    !                                  REPLY(R)!       !
	!    !-<----------------------<---------------<-!       !
	!    !                                          !       !
	!    !END(PATH>0)         /-------\  END(PATH>0)!       !
	!    !->---------------->-!       !-<---------<-!       !
	!    !                    !       !             !       !
	!    !          REPLY(N+R)!Path   !REPLY(N)     !       !
	!    !-<----------------<-!Close  !->--------->-!       !
	\----/                    !Pending!             \-------/
                                  !       !
	/------\          REPLY(A)!       !
	!Path  !-<--------------<-!       !
	!Closed!                  !       !
	!      !                  \-------/
	\------/










                        ***WORKING DOCUMENT***


                                  32


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


                              APPENDIX C

                       Front-End Implementation


Introduction

A Network Access System (NAS), developed for a DEC PDP/11 computer, supports
the current Imp-Host, Host-Host and ICP protocols.  The implementation of
these protocols facilitate process-process communications across the network
and multi-user TELNET access to foreign hosts.  This NAS provides the FE 
environment in which FEP is implemented.

The NAS system is comprised of a Kernel or executive section and a Network
Control Program (NCP) plus a collection of modules to support device
interfaces, handle terminals, and implement applications, as appropriate.  The
software is modular and extensible.

The KERNEL

The Kernel of the system consists of a set of functional modules which perform
the task of resource management in a multiprocessing environment.  This allows
processes to be created, vie for processor service according to priority, 
intercommunicate, and be terminated.  System primitives exist for various
tasks such as process creation and synchronization, storage allocation, and
sharing of the interval timer.

The term process used here describes an autonomous sequence of states brought
about by the PDP-11 processor; a process' state is characterized by the set of
processor registers, a stock, and process-owned storage areas.  Process share 
storage areas which are accessed only (eq. pure code).  Processes also share
storage areas which may be updated (eq. control tables).  In this case an
allocation mechanism is utilized to prevent simultaneous ownership of an 
updatable storage area.  The storage area is thus viewed as a sequentially 
sharable resource which is allocated by the process, modified, and then
released.

Processes are given control of the processor by a single procedure called the
Dispatcher.  Processes are said to be in a ready state or in a waiting state.
When a process blocks itself, control is given to the highest priority ready
process.


                        ***WORKING DOCUMENT***


                                  33


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


Each process has an associated input message queue.  This queue is the vehicle
for interprocess communication.  A process is blocked (put into a wait state)
when its input message queue becomes empty (voluntary wait), or when an 
interrupt occurs (involuntary wait) because a higher priority process is to
receive control of the processor.  A process may voluntarily block itself
waiting for any signal, or it may block itself for a specific event to be
posted to its input message queue.

The Network Control Program

The NCP provides "third level" protocol functions to local processes.  It
contains a process which decodes and passes messages which have been received
from the IMP and placed on the IMP-Host queue.  This process interacts with
other processes which call the NCP to establish connections or to transmit
data.  Thus the NCP is essentially divided into two parts:

    1)	a process which handles incoming messages from the network,
	interprets IMP-Host and Host-Host control messages, and forwards
	regular messages on established connections; and 

    2)	a set of primitives which allow local processes to establish
	connections to other processes across the network, and to perform
	requests for data to be transferred on these connections.

There are two primary data structures used by the NCP to monitor the status
of network connections.  The first is called the Host Table, and describes
that which is peculiar to each given host; the second is referred to as a
Connection Table and contains all information on the state of a local NCP 
socket (connection).  Connection Tables may be created either through
external requests (e.q., an RFC is received from a remote host) or through
internal requests (e.g., a local process performs a LISTEN).

Flow control is that portion of the NCP which governs the flow of data on
connections.  There are two procedures which perform this task; one which 
handles receive connections and one which handles send connections.  These
procedures receive control when an event has occurred which may now make it 
possible to transfer data on a connection.

Both send and receive flow control procedures have the responsibility of moving
data between local process buffers and messages being received or transmitted
over the network.  In addition, they handle the formatting and unpacking of


                        ***WORKING DOCUMENT***


                                  34


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


messages received.  Local processes are unaware that data is being transmitted
as discrete messages.

The NCP watchdog process monitors the state of network connections, checking
for error conditions and performing garbage collection tasks.  It receives 
control at periodic intervals and scans the list of known hosts, looking for
existing connections.  For each host to which an input or output connection
exists, the Watchdog causes a Host-Host NOP message to be sent.  Thus if a
remote Host crashes while data is being awaited, local processes are informed
of the error condition.  The NCP takes notice of the remote crash when it
receives a IMP--Host type 7 control message (Destination Host Dead).  It then
automatically closes all connections to that Host, and notifies using processes
of that fact.

A second function of the NCP Watchdog is to check for connections hung because
of an outstanding RFNM.  If a RFNM is not received for a specified interval,
the message is discarded, and the associated connection closed.

The FEP Handler

The Front-End Protocol is implemented as a collection of related, but
specialized processes which manage network connections on the one side, and
manage FEP paths and indexes on the other.  Some FEP processes are NCP users.
They cause network connections to be made, rule on incoming RFCs, and both
accept and generate network data.  Other FEP processes support the Host.
These processes parse incoming commands, create indexes and paths, control
the generation of replies and generally manage the paths.  Certain FEP 
processes control specialized tasks such as translation of data, servicing of 
LISTEN commands and generation of RESPONSE commands.

Two data structures provide control information for FEP activities.  An Index
Table exists for each active index.  Each Index Table associates one or more
Path Table entries.  Information in the Path Table reflects the state of the
path, the translation type specified for data on this path, and necessary
information to associate the path to any appropriate NCP Connection Tables.
The Path Table is the common interface for all of the FEP modules.  Most FEP
processes are activated to service some event which is usually associated to
a path.  The action of the process will likely be dic