rfc705.txt

RFC 相关的技术文档

	    COMMAND is 8 bits long
	    PARM1 and PARM2 are 16 bits long

	a)  COMMAND=1 , PARM1=Hostid

	This is the "Ready for Business" command which must be sent by both 
	Host and FE to establish communication between them.  Count gives the
	length of the TEXT field as usual.  If COUNT=8, then just the COMMAND
	field is present.  If COUNT=24, then both the COMMAND and Hostid are
	present.

	The FE will never send a Hostid.  The Host may send its Hostid in the
	event that the FE is connected to more than one IMP or if alternate
	routes to the network exist (e.g., via patch panels).

	Until both sides have sent this command no other command is valid.

	b)  COMMAND=2 , PARM1=M , PARM2=N


                        ***WORKING DOCUMENT***


                                  21


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


	This is the "CLOSING" command which is a purely information indication
	that the sender's FEP module has been told that communication will be
	terminated in M minutes for a period of N minutes (N=0 implies
	unknown).

	No action is required of the receiver, however he may be able to
	distribute the information to his users.

	c)  COMMAND=3

	This is the "CONTINUE" command which indicates that any previous
	CLOSING command is now no longer true.

		END INDEX=0 PATH+0 CODE

	This command terminates the connection between the HOST and FE.  All
	other paths/indexes are automatically aborted and the FE will close
	all network connections.  The values of the CODE field are the same
	as in the general END command.

Path 1									  5c

Path 1 is reserved for commands specific to a particular path or index.  No
commands are presently defined; they will be at a later date when more
experience has been gained on the need for them.

Path 2									  5d

Path 2 of Index 0 is used for Operator-to-Operator communication between the
Host and the FE.  It is an optional feature which is enabled by an installation
parameter.

MESSAGE commands are formatted in the normal manner with the sender requesting
that the TEXT field be displayed to the receiver's system operator.

Scenarios								    6	

The following scenarios are included to provide the reader with a "feeling" for
FEP in a varied set of applications.  The examples selected relate to existing
ARPANET protocols or other networking applications, and do not represent an
exhaustive list of capabilities.					    6a


                       ***WORKING DOCUMENT***


                                  22


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


Fields which are variable or not relevant are not shown (for purposes of 
clarity) in the command strings in the following examples.		  6b

Host Implementation of User TELNET					  6c

	BEGIN ndxa,PATH=1,host,SKT=1,,CONN-TYPE=duplex+ICP,NPATHS=1

The User TELNET process in the Host causes the BEGIN command to be issued.  
When a successful RESPONSE has been returned by the FE, a typical duplex
TELNET connection will have been made to the Host specified in the BEGIN.

Host is Providing Server TELNET						  6d

	LISTEN ndxa,PATH-1,HOST=0,SKT=1,,CONN-TYPE=duplex+ICP,NPATHS=32


With this one command the Server TELNET process in the Host has conditioned
the FE to LISTEN on Socket 1 (the well-advertised TELNET socket) and to
establish as many as 32 duplex data paths.  The FE, through the RESPONSE
command, will report each connection as it occurs.  Path 1 will represent
the first such duplex connection, etc.  The Host may then manage the data
paths individually.  Individual paths may be ended and placed back into a
LISTENing state by the Host.  If at any time an END command specifying this
INDEX with a PATH of 0 were to be sent by the Host, all connections would
be dissolved, and for all practical purposes, the Host is no longer willing
to provide Server TELNET services.

Host is Providing Server FTP						  6e

	LISTEN ndxa,PATH=1,HOST=0,SKT=3,,CONN-TYPE=duplex+ICP,NPATH=1

As soon as a RESPONSE for this LISTEN comes from the FE, the Host Server FTP
process should select a new INDEX and issue a new LISTEN for ndxb on socket 3.
The duplex connection which has been made is the control path for the file
transfer.  Based upon control information passed between server and user on
ndxa (path 1) the server FTP will either:

	BEGIN ndxa,PATH=2,(hostid etc. from response),NPATHS=1
    OR
	LISTEN ndxa,PATH=2,(hostid etc. from response),NPATHS=1


                        ***WORKING DOCUMENT***


                                  23


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


When a RESPONSE command has been received to the previous command, the data
connection (PATH 2) will have been made and transfer of data may begin.  The
values for TRANS-TYPE and CONN-TYPE for the LISTEN or BEGIN will be derived
from the exchange of information on the control path.

Host Is User FTP							  6f

	BEGIN NDXA,PATH=1,HOSTID,SKT-3,,CONN-TYPE-duplex+ICP,NPATH=1

when a RESPONSE to this command has been returned by the FE the control path
will have been connected.  The Host, after exchanging information on the 
control path, may then proceed by issuing a BEGIN or LISTEN as in the Server 
FTP example.

Teleconferencing							  6g

An INDEX with n PATHs permits up to n otherwise disassociated conversations
to be affiliated.  Each path can be manipulated individually, or all paths as
a group.  With the broadcast option -- a MESSAGE command specifying INDEX but
not specifying PATH will be broadcast to all open paths on that index.  Thus
each host may direct its messages to any or all parties.

A "conference" may be initiated by any host who issues a LISTEN with multiple
duplex paths on an agreed upon (but not necessarily well advertised) socket. 
When some foreign host connects, an ordinary TELNET connection exists.  If,
however, a third or forth or more parties connect, the hosts already engaged
in the conversation may elect to inform the late comers of the members already
involved.  Each host may then elect to connect to as many other hosts as he 
desires.  (The parties could agree as to who would BEGIN and who would LISTEN).
Following this scheme [it is not a protocol] all parties participate equally,
there is no moderator.  Each host decides to whom he will speak.  Using the 
initial LISTEN, a variation on this would permit the LISTENer to be moderator 
and require that he relay messages to other parties, as desired.

In summary, the data path mechanism permits a group of users to select an
agreed upon socket, appoint a "moderator," and at a prescribed time engage in
a conference without benefit of special protocol implementations in the FE
or in any of the hosts (except possibly the moderator).


                        ***WORKING DOCUMENT***


                                  24


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


Example of the Use of Simplex Connections				    6h

The Simplex connection types permits a host to LISTEN on a group of simplex
sockets of a particular gender.  If the host supported a group of line 
printers, for example, the Line Printer Applications Program could perform a 
LISTEN on a socket advertised to be his "Printing Socket," specifying as many
receive paths as he had printers.  Foreign hosts could then connect (via ICP) 
to his print socket.  They would be given an appropriate working socket value
and then connect to an available printer.  In this way up to n foreign hosts
may be connected to his n printers at all times.  All that any needs to know
to avail themselves of printing services is the server host's print socket.
[1]

Host Implementation							  7

Concepts								  7a

The Front-End Protocol permits a Host to make use of the network through
existing low-level protocols, without requiring that it be cognizant of the
implementation details of those protocols.

Implementation of FEP in the Host is in terms of the function it is performing
or the service it is providing.  Information regarding sockets is available
to the sophisticated user, but can be ignored if not relevant to the problem
at hand.

The Host should provide the equivalent of a BEGIN, LISTEN, MESSAGE, INTERRUPT,
and END command.  In other words, the human user or applications level process
has at its disposal the full power of FEP.

The FEP module in the Host serves as a control mechanism to multiplex/
demultiplex traffic between itself and the FE.  In appearance and function it 
is much like any multi-line interface driver.  It handles REPLYS, reports 
errors, etc.  The FEP module must also assume the responsibility for assignment
of indexes.  This could easily be implemented as a "GETINDEX" subroutine
which would allow a user to ask for an index to be assigned to him.  The
user could then proceed to do BEGINs, LISTENs, etc. on that index.

A server process makes itself available to the network at large by issuing an 
appropriate LISTEN.  The Host FEP module would not have to be aware of what
servers were implemented or in operation.  The server process, when it was 


                        ***WORKING DOCUMENT***


                                  25


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


activated, could do a "GETINDEX," followed by a LISTEN on its well-advertised
socket, and then proceed from there.  The Host FEP module simply associates
indexes to processes and passes the incoming traffic to the appropriate process
for analysis and response.  It maintains flow between itself and the FE through
the generation and receipt of REPLYs.

The type of data structures, or format of information employed in the 
implementation of the FEP commands in the Host is, of course, up to the
implementor.  BEGIN could be a macro call, with the various information
passed as parameters to the Host FEP module -- which would then arrange it
into a command for delivery to the Front-End processor.  The important
consideration is not how the commands are implemented, but simply that their 
function is provided.  It might be desirable, for instance, to implement the
Host such that the front-end processor looks like a special I/O device.  In
this case, it may be appropriate to implement a form of OPEN [for BEGIN or 
LISTEN], a GET or PUT [for MESSAGE], CLOSE [for END], etc...

Regardless of the implementation details, it appears that, while it is the
responsibility of one control module to assign and manage INDEXes, data paths
are entirely the responsibility of the process which "owns" the INDEX.

Installation Parameters							  7b

To package the software for the FE for a given Host, that Host supplies a
number of parameters defining what FE capabilities it requires.  These
parameters are input to a system-generation procedure to produce the particular
FE code.

The parameters are:

	Byte Size

	This gives the size in bits, into a multiple of which each and every
	field of a command string will be right-justified (i.e., the
	information bits come last, preceded by as many padding bits as are
	needed to complete the least integral number of bytes).

	Its value will normally be 8 but other values will be accommodated
	as necessary.


                        ***WORKING DOCUMENT***


                                  26


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


	Command String Padding

	This gives the size in bits of the width of the hardware interface
	between the Host and the FE, such that every command string
	transmitted in either direction will have padding appended to
	complete the least multiple of this width.

	In the typical implementation, this parameter will be 0 and any
	padding required will be appended/discarded by the line protocol
	underlying FEP.

	Pad Field Length

	This gives the size in bits of the PAD field in the MESSAGE command.
	This enable a Host to have the TEXT field start on a convenient
	boundary.

	Its value can be anywhere in the range 0 to 64.

	Maximum of MESSAGE

	This gives the maximum length of a MESSAGE command string.

	Because buffer allocation in the FE is based on this parameter,
	its value should be chosen with care.

	Maximum number of Indexes

	This gives the maximum number of indexes which may be set-up at any one
	time.

	Maximum Number of Paths

	This gives the maximum number of paths within one index which may be
	open at any one time.

	Translation Types

	This gives the set of required values and meanings of the TRANS-TYPE
	field of the BEGIN/LISTEN commands.  The TRANS-TYPE field is divided
	into two 8-bit subfields; the first giving the format of data on the


                        ***WORKING DOCUMENT***


                                  27


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


	network side; the second giving the format of data on the Host side.
	The FE is required to translate between these formats all data
	contained in the TEXT field of MESSAGE commands.

	This parameter specifies the required formats and their values in the
	8-bit subfields.  The value 0 is reserved to mean "bit-string" and
	when it appears as either (or both) of the subfields it implies no 
	translation is to be done.

	Broadcast Option

	This specifies whether the Host wants to be able to use the Broadcast
	feature (see Section 3j).

	Operator-to-Operator Communication Option

	This specifies whether the Host wants the ability to send messages
	to the FE operator or to have the Host's operator receive messages
	from the FE.

Other options may be included in the protocol at some later date and these will
be available through installation parameters similar to the Broadcast option.

Note that all of these parameters affect the size and complexity of the FE 
code.  Thus it is important that their values be chosen carefully so as to 
maximize FE efficiency while minimizing Host implementation effort.

For descriptions of individual Host implementations and a list of the options
available so far, see Appendix D.

FE Implementation							  8