rfc740.txt

RFC 相关的技术文档

      one record; however, those sites which are concerned with
      efficiency should send transactions as close as possible to the
      880 byte limit.

      There is no necessary connection between physical message
      boundaries and transactions ("logical messages"); the NCP can
      break a transaction arbitrarily into physical messages. The CCN
      server starts each transaction at the beginning of a new physical
      message, but this is not a requirement of the protocol.

      Each logical record within a transaction begins with an "op code"
      byte which contains the channel identification, so its value is
      unique to each channel but constant within a channel.  This choice
      provides the receiver with a convenient way to verify
      bit-synchronization, and it also allows an extension in the future
      to true "multi-leaving" (i.e., multiplexing all channels within
      one connection in each direction).

      The only provisions for transmission error detection in the
      current NETRJS protocol are (1) the "op code" byte to verify bit
      synchronization and (2) the transaction sequence number. Under the
      NETRJS protocol, a data transfer error must abort the entire
      transmission; there is no provision for restart.















Braden                                                          [page 7]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



   2.  Meta-Notation

      The following description of the NETRJS data transfer protocol
      uses a formal notation derived from that proposed in RFC 31 by
      Bobrow and Sutherland. The notation consists of a series of
      productions for bit string variables. Each variable name which
      represents a fixed length field is followed by the length in bits
      (e.g., SEQNUMB(16)).  Numbers enclosed in quotes are decimal,
      unless qualified by a leading X meaning hex.  Since each hex digit
      is 4 bits, the length is not shown explicitly in hex numbers.  For
      example, '255'(8) and X'FF' both represent a string of 8 one bits.

      The meta-syntactic operators are:

         |     :alternative string

         [ ]   :optional string

         ( )   :grouping

         +     :catenation of bit strings

      The numerical value of a bit string (interpreted as an integer) is
      symbolized by a lower case identifier preceding the string
      expression and separated by a colon.  For example, in
      "i:FIELD(8)", i symbolizes the numeric value of the 8 bit string
      FIELD.

      Finally, we use Bobrow and Sutherland's symbolism for iteration of
      a sub-string:  (STRING-EXPRESSION = n); denotes n occurrences of
      STRING-EXPRESSION, implicitly catenated together.  Here any n
      greater or equal to 0 is assumed unless n is explicitly
      restricted.

   3.  Protocol Definition

      STREAM ::= (TRANSACTION = n) + [END-OF-DATA]

         That is, STREAM, the entire sequence of data on a particular
         open channel, is a sequence of n TRANSACTIONS followed by an
         END-OF-DATA marker (omitted if the sender aborts the channel).

      TRANSACTION ::= THEAD(72) + (RECORD = r) + ('0'(1) = f)

         That is, a transaction consists of a 72 bit header, r records,
         and f filler bits; it may not exceed 880*8 bits.






Braden                                                          [page 8]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



      THEAD ::= X'FF'+f:FILLER(8)+SEQNUMB(16)+LENGTH(32)+X'00'

         Transactions are to be consecutively numbered in the SEQNUMB
         field, starting with 0 in the first transaction after the
         channel is (re-) opened.  The 32 bit LENGTH field gives the
         total length in bits of the r RECORD's which follow.  For
         convenience, the using site may add f additional filler bits at
         the end of the transaction to reach a convenient word boundary
         on his machine; the value f is transmitted in the FILLER field
         of THEAD.

      RECORD ::= COMPRESSED | TRUNCATED

         RJS will accept intermixed RECORD's which are COMPRESSED or
         TRUNCATED in an input stream.  RJS will send one or the other
         format in the printer and punch streams to a given VRBT; the
         choice is determined for each terminal id.

      COMPRESSED ::= '2'(2) + DEVID(6) + (STRING = p) + '0'(8)

      STRING     ::= ('6'(3) + i:DUPCOUNT(5))  |

         This form represents a string of i consecutive blanks

                     ('7'(3) + i:DUPCOUNT(5) + TEXTBYTE(8)) |

         This form represents string of i consecutive duplicates of
         TEXTBYTE.

                     ('2'(2) + j:LENGTH(6) + (TEXTBYTE(8) = j))

         This form represents a string of j characters.

      TRUNCATED  ::= '3'(2) + DEVID(6) + n:COUNT(8) + (TEXTBYTE(8)=n)

      DEVID(6)   ::= DEVNO(3) + t:DEVTYPE(3)

         DEVID identifies a particular virtual device, i.e., it
         identifies a channel.  DEVTYPE specifies the type of device, as
         follows:

            t = 1:  Output to remote operator console
                2:  Input from remote operator console
                3:  Input from card reader
                4:  Output to printer
                5:  Output to card punch
              6,7:  Unused





Braden                                                          [page 9]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



         DEVNO identifies the particular device of type t at this remote
         site; at present only DEVNO = 0 is possible.

      END-OF-DATA ::=X'FE'

         Signals end of job (output) or job stack (input).














































Braden                                                         [page 10]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



                               APPENDIX B

                    Telnet for VRBT Operator Console

   The remote operator console connections use the ASCII Telnet
   protocol. Specifically:

      1.  The following one-to-one character mappings are used for the
      three EBCDIC graphics not in ASCII:

         ASCII in Telnet     |  NETRJS
         ----------------------------------------------------
         broken vertical bar |  solid vertical bar
         tilde               |  not sign
         back slash          |  cent sign

      2.  Telnet controls are ignored.

      3.  An operator console input line which exceeds 133 characters
      (exclusive of CR LF) is truncated by NETRJS.

      4.  NETRJS accepts BS (Control-H) to delete a character and CAN
      (Control-X) to delete the current line.  The sequence CR LF
      terminates each input and output line.  HT (Control-I) is
      translated to a single space. An ETX (Control-C) terminates
      (aborts) the session.  All other ASCII control characters are
      ignored.

      5.  NETRJS translates the six ASCII graphics with no equivalent in
      EBCDIC into the character question mark ("?") on input.






















Braden                                                         [page 11]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



                               APPENDIX C

                            Carriage Control

   The carriage control characters sent in a printer channel by NETRJS
   conform to IBM's extended USASI code, defined by the following table:

      CODE       ACTION BEFORE WRITING RECORD
      ----       ----------------------------
      Blank      Space one line before printing
      0          Space two lines before printing
      -          Space three lines before printing
      +          Suppress space before printing
      1          Skip to channel 1
      2          Skip to channel 2
      3          Skip to channel 3
      4          Skip to channel 4
      5          Skip to channel 5
      6          Skip to channel 6
      7          Skip to channel 7
      8          Skip to channel 8
      9          Skip to channel 9
      A          Skip to channel 10
      B          Skip to channel 11
      C          Skip to channel 12



























Braden                                                         [page 12]

RFC 740                                              RTB 42423 22 Nov 77
NETRJS Protocol



                               APPENDIX D

                      Network/RJS Command Summary

   This section presents an overview of the RJS Operator Commands, for
   the complete form and parameter specifications please see references
   2 and 3.

   Terminal Control and Information Commands

      SIGNON       First command of a session; identifies VRBT by giving
                   its terminal id.

      SIGNOFF      Last command of a session; RJS waits for any data
                   transfer in progress to complete and then closes all
                   connections.

      STATUS       Outputs on the remote operator console a complete
                   list, or a summary, of all jobs in the system for
                   this VRBT, with an indication of their processing
                   status in the batch host.

      ALERT        Outputs on the remote operator console an "Alert"
                   message, if any, from the computer operator.  The
                   Alert message is also automatically sent when the
                   user does a SIGNON, or whenever the message changes.

      MSG          Sends a message to the computer operator or to any
                   other RJS terminal (real or virtual).  A message from
                   the computer operator or another RJS terminal will
                   automatically appear on the remote operator console.

   Job Control and Routing Commands