rfc725.txt

RFC 相关的技术文档

This model (illustrated in Fig. 3) uses FTP to effect the transfer of
the files.  It may be easier for some systems to use this sort of model
for more sophisticated RJE systems.  This is especially true if the
users desire to take input from the local file system or to send output
to the local file system rather than from an actual card reader or to an
actual line printer.  Although using the local file system is not
prohibited by the Data Transfer model, it may be easier to approach
through FTP.  Using FTP with NETRJE also allows the utilization of the
FTP server-server transfer mechanism to generate input from or direct
output to a third host.

The only new facility required by this model are the commands INPATH and
OUTPATH.  When using FTP to transfer input to the Server, the user must
know where to send the job so that it enters the job stream.  The INPATH
command returns as a reply such a legal pathname.  Thus the scenario for
job submission is as follows:  The user sends an INPATH command; the
Server responds with a legal Server pathname for the user.  The user
process starts sending the input to the file using FTP.  When transfer
is complete, the user sends a SCHED <server pathname> command.  When the
job has finished, the pathname created for the user may or may not
destroy the input file.  The OUTPATH command is similarily used to
identify the pathname for the output, so that it may be retrieved by
FTP.  Some systems may define file names in such a way that the user may
derive them from the parameters of his job.

Note on Replies

In all of the above examples we have refrained from defining actual
reply codes.  The intent is to use the same reply structure, and where
appropriate the same numbers, as described in RFC 640 "Revised FTP Reply
Codes".

Protocol Measurement

An integral part of any good protocol definition is a set of
measurements to allow evaluation of both the protocol and its
implementation.  This provides two functions:  1) It allows the protocol
designer to evaluate the protocol and make improvements.  2) It allows
the user of the protocol to know how expensive it is and to demand
improvements.  The proposed NETRJE protocol provides two sets of
measures - one for a particular session and one for overall performance.
These measurements may be elicited by the MEASURE command which will
take an argument with three values:  JOB (job statistics and cost
measurements), SESSION (measurements taken for this sesson), and GLOBAL





                                                                [page 9]

NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
An RJE Protocol for a Resource Sharing Network



(overall measurements of the performance of the protocol and its
implementation).  The command will return the measurements in a fixed
format reply.

The measurements reported for a job are:

   1.  CPU time,

   2.  I/O operations,

   3.  storage space time product,

   4.  job cost in dollars,

   5.  elapsed time the job waited before being executed, and

   6.  elapsed time for the job to execute.

The measures taken from a sesson are:

   1.  number of bits transferred,

   2.  transmission rate of input or output transfers,

   3.  the amount of CPU time, storage space-time product, and I/O
   operations for the session.

   4.  cost in dollars and cents.

The measures to be taken globally are:

   1.  frequency of commands and possibly command forms,

   2.  model frequency (which submission/retrieval model used),

   3.  transmission mode frequency,

   4.  total number of sessions,

   5.  transmission rate:  average, std. deviation, upper and lower
   bounds (also by transmission mode),

   6.  cpu time, storage space-time product, and I/O operations for both
   the protocol and jobs submitted:  average, std. deviation, and upper
   and lower bounds (overall as well as by model, transfer mode, and
   file size).  (The reason for including job statistics here is so that






                                                               [page 10]

NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
An RJE Protocol for a Resource Sharing Network



   management and systems personnel have some indication how the
   facility is being used.)

It is clear that it may be difficult to acquire some measures (such as
transmission rate) when NETRJE is using FTP.  This is unavoidable since
FTP is not metered.  The most straightforward solution is also to meter
FTP (hint).  For the final definition a close look will be given to the
subset that should be required.  Comments are welcome.  However, we
believe strongly that it is very important to know how a facility like
this is used as well as how well it performs.










































                                                               [page 11]

NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
An RJE Protocol for a Resource Sharing Network



Part II.  Preliminary Definition of NETRJE Commands
---------------------------------------------------

For purposes of discussion this section gives a very preliminary
definition of the NETRJE commands and their replies.  The intent is to
give a brief but not exhaustive definition of each command and its major
replies to give the flavor of the protocol.  We do not do this to
discourage nit-picking by critics, since we may actually overlook the
obvious on occasion, but merely to expedite the writing of this paper.

The reply scheme will follow the model of the revised FTP reply codes
described in RFC 640.

Access Control

   USER <usercode>

   PASS <password>

   ACCT <account>

These perform the normal functions to log the user into the system.  The
replies to them are the standard ones in FTP.  It was never clear why
"account" was not included in the old NETRJE.  Presumably, if it's
necessary for an FTP or Telnet user, it will be necessary for an RJE
user.

REINIT

This command reinitializes the state of the NETRJE server process so
that it is ready for a new user.  If the transfer of data is in progress
for the previous user, it will be allowed to complete.

ABORT

This command is used to abort the transfer of data.  This command is
meaningful to the Server only if the data is being transferred over the
Telnet connection or the default data sockets.  If FTP is being used,
the execution of this command is the responsibility of the USER NETRJE
process.

BYE

This command causes the Server to log out the user and close the Telnet
connection.  If the transfer of data is in progress, the action of the
command will be delayed until the transfer is complete.






                                                               [page 12]

NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
An RJE Protocol for a Resource Sharing Network



SCHED <input part><output part>

<input part>::= <empty>|<server pathname> [DISCARD]

   INPUT <CRLF>   <text>   <CRLF>.<CRLF>

output part ::= <empty>|<server pathname>[DISCARD]

server pathname ::= {locally recognizable string of characters
terminated by an ASCII NULL}

This command causes the input described by the <input part> to be
entered into the RJE job stream and the output produced to be disposed
of according to the <output part>.  The null condition for either
argument implies that the information has been previously specified or
is the default.

For the <input part>, the <empty> may imply two actions.  If an INDEF
command has previously specified a <server pathname>, input to the job
stream is taken from the file indicated by the file name.  If the INDEF
command has specified that the input is to come from a CCN-like data
transfer socket, the SCHED <empty> command is the signal for the Server
to start reading data.

The DISCARD modifier, if present, indicates that the file should be
discarded after it has been transmitted or it has been received and
executed.  If the input stream is to be sent on the Telnet connection,
the source may be a local device or a human user.  This facility is
provided for mini-hosts that can't use one of the other techniques and
for the user who wishes to enter job control directly at his terminal.

The empty for output specifies either the primary output file of the job
(the default) or a previously specified server pathname (OUTDEF
command).

Successful replies to this command should indicate any job-id assigned
by the local RJE system along with other status informaton.  Failure
would be because files did not exist, access was denied, etc.

OUTPUT <output spec>

<output spec>::= <job-id><xmsn part>|<job-id><server pathname>

<xmsn part>::= <empty>| /<IO params>

<IO params>::= <xmsn params>, <dest>






                                                               [page 13]

NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
An RJE Protocol for a Resource Sharing Network



This command indicates to the Server what output  is to be sent to the
user, how it is to be sent, and to whom.  The <IO params> part will
allow the specification of a host and socket so that output may be sent
to a TIP printer, or alternatively sent on the Telnet connection or to
the default data sockets.  This argument also specifies the format and
representation of the data.

When the Server receives this command, it will proceed to transmit the
output to the host in the prescribed manner.  The reply structure of
this command will depend on how the output is moved and will be
discussed in more detail later.

INPATH

This command returns to the user a legal pathname at the Server.  The
user may then transfer his input to this pathname for eventual
submission to the RJE facility.

OUTPATH

This command performs a similar function to INPATH.

DISCARD   <job-file-id>  |  <server pathname>

This allows the user to destroy input or output files associated with a
job.

INDEF     <job-id><I/O params>

OUTDEF    <job-id><I/O params>

These commands allow the user to specify the parameters necessary to
send input or retrieve output.  This command specifies how the data will
be transferred and specifies format, etc.

CANCEL <job-id>

This command allows a job to be cancelled from the RJE job stream.

STATUS <status arg>

status arg ::= <empty>|<user id>|<job-id>|<job-id><blank><job-file-id>

This command allows the user to determine the status of the RJE session,
all jobs under his usercode, a specific job, or the output of a specific
job.






                                                               [page 14]

NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
An RJE Protocol for a Resource Sharing Network



ALTER <job-id><site specific option>

SITE <site specific option>

These commands allow site specific commands to be passed to the Server
RJE system.  The ALTER command is intended to effect specific jobs,
while the SITE command is used for commands of more global effect.  They
could be merged into one.

OP <operator message>

This command allows messages to be sent to the operator at the Server
site.

Reply Codes for the Proposed NETRJE
-----------------------------------

The reply codes for this protocol will follow the model proposed for the
new FTP specificaton in RFC 640.  As a reminder we insert the pertinent
information from that RFC:

There are five values for the first digit of the reply code:

1yz     Positive Preliminary reply

   The requested action is being initiated; expect another reply before
   proceeding with a new command.  (The user-process sending another
   command before the completion reply would be in violation of
   protocol; but server-FTP processes should queue any commands that
   arrive while a preceding command is in progress.)  For
   implementations where simultaneous monitoring is difficult, this type
   of reply can be used to indicate that the command was accepted and
   the user-process may now pay attention to the data connections.

2yz     Positive Completion reply

   The requested action has been successfully completed.  A new request
   may be initiated.

3yz     Positive Intermediate reply

   The command has been accepted, but the requested action is being held
   in abeyance, pending receipt of further information.  The user should
   send another command specifying this information.  This reply is used
   in command sequence groups.







                                                               [page 15]

NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
An RJE Protocol for a Resource Sharing Network



4yz     Transient Negative Completion reply

   The command was not accepted and the requested action did not take
   place, but the error condition is temporary and the action may be
   requested again.  The user should return to the beginning of the
   command sequence, if any.  It is difficult to assign a meaning to
   "transient", particularly when two distinct sites (Server and
   User-processes) have to agree on the interpretation.  Each reply in
   the 4yz category might have a slightly different time value, but the
   intent is that the user-process is encouraged to try again.  A rule
   of thumb in determining if a reply fits into the 4yz or the 5yz
   (Permanent Negative) category is that replies are 4yz if the commands
   can be repeated without any change in command form or in properties
   of the User or Server (e.g., the command is spelled the same with the
   same arguments used, the user does not change his file access or user
   name, the server does not put up a new implementation.)

5yz     Permanent Negative Completion reply

   The command was not accepted and the requested action did not take
   place.  The User-process is discouraged from repeating the exact
   request (in the same sequence).  Even some "permanent" error
   conditions can be corrected, so the human user may want to direct his
   User-process to reinitiate the command sequence by direct action at
   some point in the future (e.g., after the spelling has been changed,
   or the user has altered his directory status.)

The following function groupings are encoded in the second digit:

x0z     Syntax - These replies refer to syntax errors, syntactically
correct commands that don't fit any functional category, and
unimplemented or superfluous commands.

x1z     Information - These are replies to requests for information,
such as status or help.

x2z     Connection - Replies referring to the Telnet and data
connections.

x3z     Authentication and accounting - Replies for the logon process
and accountng procedures.

x4z     Unspecified as yet.

x5z     File system - These replies indicate the status of the Server
file system vis-a-vis the requested transfer or other file system
action.





                                                               [page 16]

NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
An RJE Protocol for a Resource Sharing Network



The third digit gives a finer gradation of meaning in each of the
function categories specified by the second digit.  The list of replies
below will illustrate this.  Note that the text associated with each
reply is suggestive, rather than mandatory, and may even change
according to the command with which it is associated.  The reply codes,
on the other hand, should strictly follow the specifications.  That is,
Server implementations should not invent new codes for situations that
are only slightly different from the ones described here, but rather
should adapt codes already defined.

Below is a list of replies ordered by reply code.  Some new replies have
been added for RJE; these are marked by asterisks to aid the reader.
Following this list is a list of commands with the replies that are
possible for that command.  This list is not considered complete or
final; as usual comments are welcomed.

110 Restart marker reply,

   In this case the text is exact and not left to the particular
   implementation; it must read:

      MARK yyyy = mmmm

   where yyyy is user-process data stream marker, and mmmm is Server's
   equivalent marker.  (Note the spaces between the markers and "=".)

120 Service ready in nnn minutes

125 Data connection already open; transfer starting

150 File status okay; about to open data connection

200 Command okay

202 Command not implemented, superfluous at this site

211 System status, or system help reply

212 Directory status

213 File status

214 Help message (on how to use the server or the meaning of a
particular non-standard command.  This reply is useful only to the human
user.)

*215 RJE general status reply





                                                               [page 17]

NWG/RFC# 725                              DAY GRG 25-APR-77 12:41  38316
An RJE Protocol for a Resource Sharing Network