GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc205

Network Working Group R. Braden Request for Comments: 205 UCLA/CCN NIC: 7172 6 August 1971

               NETCRT - A CHARACTER DISPLAY PROTOCOL
 At the May NWG, meeting, CCN circulated dittoed copies of a proposed
 character-display protocol NETCRT.  Since that time, NETCRT has been
 revised significantly; the current version is now being published as
 an RFC, as promised last May.
 NETCRT was developed because a particular site (RAND) requested
 Network access to URSA, CCN's display-based crje system.  The primary
 use of URSA at UCLA is conversational remote job entry from a display
 terminal: entering and editing program text, submitting programs for
 batch execution, and examining job output; URSA is not a general-
 purpose time-sharing system.
 URSA's text editor is designed for a fast updating character display
 and cannot be used in any reasonable way from a typewriter-like
 console.  Therefore, a simple TELNET protocol is not adequate for
 using the crje function of URSA.  Furthermore, we have assumed that
 other ARPA sites will have their own text editors, well matched to
 their own terminals and systems.  Therefore, CCN has implemented
 NETRJS (see RFC #189), to provide remote job submission and retrieval
 services, before implementing NETCRT.
 There are a number of other functions in URSA besides crje; some of
 these would probably be useful to remote users.  URSA contains a
 comprehensive STATus service, whose constantly-updating displays are
 "windows" into the operation of the machine and the operating system,
 allowing a user to watch the progress of his jobs through the system.
 URSA also includes on-line data set (file) utilities, convenient for
 a user with files stored at CCN.  To obtain access to these
 facilities, a few sites which use CCN heavily may want to implement
 NETCRT.  The schedule for implementation of NETCRT at CCN to allow
 Network access to URSA will depend upon the existence of a user site
 that wants the service and that will write a suitable NETCRT user
 process.  Interested sites are urged to contact the CCN Technical
 Liaison, Bob Braden.
 Even though the implementation schedule for NETCRT is nebulous, we
 are publishing the specs now for several reasons.  First, we would
 like comments and criticisms.  Furthermore, NETCRT contains some
 features which may be useful in the protocol(s) now being developed
 for full graphical displays.

Braden [Page 1] RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971

NETCRT PROTOCOL - VERSION 3

A. INTRODUCTION

 The UCLA Campus Computing Network (CCN) node intends to provide
 Network access to its conversational remote job entry system URSA.
 The URSA system is display-oriented, supporting only character
 displays with local buffers (originally IBM 2260 displays, now CCI
 301 TV display consoles).  This document defines a third-level
 protocol called NETCRT which allows a Network user in a remote Host
 to look like a CCI console to URSA.  NETCRT is defined in terms of a
 virtual character display ("VCD") terminal, simulated by a process in
 the user host.
 URSA, like many on-line console systems, attempts to provide a good
 man/machine interaction by keeping tight control over the state of
 the terminal.  On the other hand, the Network Working Group has
 deliberately built some "squishiness" into the standard Network
 protocols.  We believe this squishiness is a conceptual mistake when
 dealing with remote man/machine interaction, and we would support
 protocol revisions to allow control over the effective communication
 compliance between processes in different hosts.  However, this
 NETCRT protocol attempts to cope with the present squishiness, which
 is apparently built into a number of host's NCPs.  In fact, we have
 arranged things so a host can improve response time and reduce
 Network traffic with NETCRT by using the message buffering inherent
 in his NCP.

B. THE VIRTUAL CHARACTER DISPLAY

 A VCD consists of the following virtual hardware (see Figure 1):
 1. A rectangular _display screen_ capable of displaying N lines of M
    characters.
 2. A _local buffer_ of M x N characters used to refresh the display.
 3. A _cursor register_ which addresses the characters in the buffer
    (and hence on the screen).  This register controls the writing of
    text into the local buffer from either the keyboard or the server,
    and the reading of the local buffer by the server.
 4. A _keyboard_ containing text keys and control keys.  Each text key
    enters a character into local buffer at the current cursor address
    and steps the cursor register by 1.

Braden [Page 2] RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971

 5. A _communication interface_ through which the server CPU can send
    a stream of _command_ segments to the VCD and receive a stream of
    _response_ segments from the VCD.  The command segments include
    control commands to the VCD and text to be written into the local
    buffer.  Response segments contain status indicators and text read
    from the buffer.  In addition, both VCD and server may send break
    signals.
 The current address in the cursor register, an integer between 0 and
 M x N-1, is displayed as a blitch, underscore, or other visual
 indication at the corresponding point on the screen; this indication
 is called the _cursor_.  Position 0 is the upper left corner of the
 screen.
 The screen is addressed in line ("row") order, and read and write
 operations by the server overflow automatically from one line to the
 next.  The cursor register is not assumed to operate modulo M x Nxsy.
 It is possible for a server command to set the cursor register to M x
 N, one position beyond the last screen position; however, the server
 should never set the register to an address beyond M x N, and it
 should not leave the cursor at M x N when the keyboard is unlocked.
 The application program or conversational system using the VCD may
 format each display screen in a variety of ways, and may use a number
 of styles of interaction.  One consequence is that the application
 program might have to look anywhere on the screen (i.e., in the local
 buffer) to find the input information it requires.  We may consider
 three alternative mechanisms for transmitting information from the
 VCD to the serving CPU:
 Mechanism 1    Whenever the user presses a "Transmit" control key,
                the entire M x N characters in the buffer are
                transmitted to the server CPU.
 Mechanism 2    When the user presses "Transmit", the string of text
                between a "start" control character and the cursor is
                transmitted to the server.
 Mechanism 3    The server must send a read command segment to the VCD
                before the "Transmit" key will have an effect.  The
                read command segment determines which parts of the
                buffer are to be transmitted to the server.
 Mechanism 1 may be faulted as too costly in transmission time and
 channel capacity, while Mechanism 2 is too restrictive.  The scheme
 which we propose here is based on Mechanism 3, which subsumes the
 other two.

Braden [Page 3] RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971

 The VCD is assumed to include the following control keys:
 Erase          Clears the display buffer to all blanks and resets the
                cursor to position 0 (the upper left corner of the
                screen).
 Transmit       Locks the keyboard and places the VCD under control of
                the server CPU.  Typically, the server will read
                specified areas of the screen and perhaps write out
                new data before unlocking the keyboard again.
 Break          Has the same effect as _Transmit_, and in addition
                sends an interrupt message to the server CPU.  The
                _Break_ key always sends the interrupt, regardless of
                the state of the VCD.
 Reset          May be used to unlock the VCD keyboard in case the
                server CPU fails to respond immediately and the user
                wishes to enter new or different information.
 These may be called pure control keys, since they do not correspond
 to any text characters.  The following control key does store a
 character into the display buffer:
 Newline        Enter a Newline (NL) character into the display buffer
                and reset the cursor to the beginning of the next
                line.  If this character is encountered during a read
                or write operation, it is executed (i.e., the cursor
                is moved to the beginning of the next line) and the NL
                is counted as _one_ character.
 Finally, there are assumed to be keys for manually positioning the
 cursor to any address on the screen.  Cursor positioning keys may
 include: cursor right, cursor up, cursor left (BS), cursor down (LF),
 and cursor return (CR).  A tab (HT) mechanism could also be defined,
 although none is included here.

C. VCD STATES

 The VCD has two internal states, _Local_ and _Control_ (see Figure
 2).
 Local State:   The keyboard is unlocked and all keys are active.  The
                VCD does not accept or recognize any commands from
                server except (reverse) Break.

Braden [Page 4] RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971

 Control State: The keyboard is locked, and only the _Break_ and
                _Reset_ keys are active.  The VCD accepts and executes
                command segments from the server, and returns response
                segments as the result of read commands.
 The VCD changes from Local to Control state if either:
    (1) The user presses the _Transmit_ key; or
    (2) the user presses the _Break_ key; or
    (3) the server sends a reverse Break request.
 _Transmit's_ only effect is to enter Control State; _Break_ enters
 Control State and also sends a break request (INS and X'80') to the
 server.
 The VCD returns to Local State when either:
 1. The user presses the _Reset_ key; or
 2. the VCD encounters a LOCAL command from the server and is not in
    the process of synchronizing a reverse break (see section E
    below).
 We should note that CCI and IBM 2260 character display consoles
 actually have only one control key ("Interrupt" on CCI, "Enter" on
 2260) to perform the functions of both _Break_ and _Transmit_; this
 one key in fact has the function of the _Break_ key of the VCD.  We
 have included both _Break_ and _Transmit_ keys in the VCD for
 generality, but the URSA-NETCRT interface will be programmed to allow
 a Network user of URSA to either (1) employ the _Break_ key
 exclusively, or (2) use either _Break_ or _Transmit_ as appropriate.
 This will be achieved by URSA simply by ignoring those break requests
 (INS messages) which occur while there are outstanding read commands.

D. VCD COMMANDS

 The server sends the VCD a string of command segments.  These are of
 varying length, consisting of an op code and none or more parameters.
 The commands recognized by the VCD are as follows:

Braden [Page 5] RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971

1. Display & Keyboard Control Commands:

 Command      Parameter(s)               Function
 -------      ------------       -----------------------------------
 ERASE           none            Erase display and reset cursor to 0.
                                 i.e, clear the local buffer.
 BLANK           none            Disable display refresh (i.e., blank
                                 the screen but do not clear the local
                                 buffer).
 UNBLANK         none            Enable display refresh.
 LOCAL           none            Put VCD in _local_ state.  The result
                                 is to suspend command interpretation
                                 and unlock the keyboard.
 SYNC            none            Used to synchronize reverse Break
                                 from server.  SYNC (X'80) is placed
                                 in stream by server at same time that
                                 it sends an INS.  VCD enters Control
                                 State, synchronizes INS with BREAK
                                 command (see next section), and
                                 continues command interpretation.

2. Cursor Control Commands:

 CURSOR  16 bit integer P        Set cursor register to P, where
                                 0 <= P <= M x N.
 FIND    X'0001' followed        Move the cursor to point to an
         by one character        occurrence of the character c.
         c                       Specifically, search backwards
                                 toward lower addresses) from the
                                 current cursor position and take
                                 the first occurrences of c (i.e.,
                                 the one with the largest address).
                                 If no occurrence is found, leave
                                 cursor at position 0.
 SAVE            none            Save a copy of the current cursor
                                 address in local register S.
 RESTORE         none            Replace cursor register contents by
                                 value S.

Braden [Page 6] RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971

I/O Commands:

 WRITE n,text    16 bit integer  Write n bytes of text into display
                 n, followed by  buffer starting at current cursor
                 n text bytes.   position and advancing cursor by 1
                                 for each byte (except NL character
                                 advances to beginning of next line).
                                 Here [sigma] + n <= M x N.
 READ n          16 bit integer  Read n bytes starting at the cursor
                 n.              [sigma] and advancing cursor by one
                                 for each byte (except NL advances
                                 cursor to beginning of next line).
                                 NL counts as one character.  Send the
                                 text to the server as a response
                                 segment.  Must have n + [sigma]
                                 <= M x N.
 SREAD           none            Read S - [sigma] bytes starting from
                                 the current cursor position [sigma]
                                 up to (but not including) the cursor
                                 address stored in register S.  The
                                 cursor is left in position S as a
                                 result.  Send the text to the server
                                 as a response segment.
 AWRITE n,text   16 bit integer  Same as WRITE n, except characters
                 n, followed by  are not stored in buffer if they
                 n text bytes.   have a lower cursor address than
                                 the value in S.
 Here are some applications of these commands in URSA:
 1. One elementary URSA terminal operation reads the screen from
    position x up to (but not including) the current cursor position.
    This could be done with the sequence of VCD command segments:
                      SAVE
                      CURSOR x
                      SREAD
 2. Another common operation in URSA is to remember the cursor, update
    specific information on the screen, and replace the cursor.  This
    can be done by the following 8 + n byte sequence of command
    segments:

Braden [Page 7] RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971

                      SAVE
                      CURSOR x
                      WRITE n, text
                      RESTORE
 3. In URSA, the area in which a user is to type his response is
    usually delimited on the left by a "Start Symbol" (graphic '[1]').
    This is a historical remnant of the IBM 2260, which has only two
    hardware read operators: read the full screen, and read from the
    Start Manual Input Symbol ("SMI") to the cursor.  The SMI read
    operation can be simulated easily on the VCD as follows:
                      SAVE
                      FIND '[1]'
                      SREAD
 4. The _Break_ (or _Transmit_) key on the VCD may serve the function
    of the INTerrupt key on a CCI console (or ENTer on an IBM 2260).
    URSA will often attempt to minimize Network traffic by sending a
    sequence of commands (one message if allocation allows) like the
    following:
  1. +

CURSOR m |

          WRITE n, text                       - URSA writes a request
          LOCAL                              |
                                            -+
                                            -+
                     +-          +-+         |_ User types response
                     |   _BREAK_   |         |
    - -User Presses  | _TRANSMIT_  |key - - -+
                     +-           -+        -+
            SAVE                             |
            CURSOR p                          - URSA reads response
            SREAD                            |
                                            -+
    At other times, URSA might send the sequence:
              CURSOR m
              WRITE n,TEXT
              LOCAL
              READ  0
    and wait for the INS from the user pressing _Break_ (or the
    response segment triggered by the zero-length read if he presses
    _Transmit_); then URSA will send the appropriate read command
    sequence.

Braden [Page 8] RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971

F. NETWORK MESSAGE FORMATS

 The VCD connects the server through ICP to a standard socket,
 establishing thereby a pair of connections between the VCD and the
 server.  Command segments (server-to-VCD) and response segments
 (VCD-to-server) are sent over these connections, without regard to
 physical message boundaries, using byte size 8.  The VCD is defined
 to operate in a segment-at-a-time mode (rather than character-at-a-
 time), with local echo.  Therefore, the server never echoes under
 NETCRT.
 In many cases URSA will send a sequence of command segments (as in
 the examples of the preceding section) at once; if there is
 sufficient allcocation they will be sent in the same message.
 Response time may be improved, therefore, if the user site is able to
 buffer ahead on command segments.  This buffering does raise break
 synchronization problems, which are solved in the following manner
 for reverse (server-to-user) break:
    The server sends an INS on the control link and also a SYNC
    command (X'80) on the data link to the VCD.  On receiving either,
    the VCD enters Control State and then achieves synchronization
    between the INS and BREAK; if the INS arrives first, the VCD
    executes normally all commands buffered in his host, _except_ it
    ignores LOCAL commands, until the SYNC appears.  Having achieved
    synchronization, the VCD continues normal command interpretation
    (without ignoring ensuring LOCAL commands).
 By this means the server can regain control of the VCD to write new
 information at any time.  For example, when URSA is used under
 NETCRT, most WRITE or AWRITE sequences will be preceded by a BREAK
 from the server, since URSA will not know the current state of the
 VCD.  Even if URSA left the VCD in Control State, the user might have
 manually returned his VCD to Local State by pressing _Reset_.
 After receiving an INS, the VCD executes rather than ignores buffered
 commands so that pending writes will not be lost in case that
 processing at the user side has been held up temporarily.  The read
 commands executed after the server sent an INS might be irrelevant to
 a server, which can ignore the corresponding response segments.  In
 order to do so, the server simply keeps matching counts of read
 commands sent and corresponding response segments received.
 Command segments will use the following formats:
 Form 1 (No parameters)  q:OPCODE(8)
    where q = X'80' means SYNC

Braden [Page 9] RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971

              X'91'   "   LOCAL
              X'92'   "   ERASE
              X'93'   "   BLANK
              X'94'   "   UNBLANK
              X'95'   "   SAVE
              X'96'   "   RESTORE
              X'97'   "   SREAD
 Form 2 (16 bit integer)  q:OPCODE(8) + n:INTEGER(16)
    where q = X'9E' means READ n
          q = X'9C'   "   CURSOR n
    In both cases, 0 <= n <= M x N
 Form 3 (count and text) q:OPCODE(8) + n:LENGTH(16) + (TEXT(8) = n)
    where q = X'9D' means WRITE
          q = X'9A' means AWRITE
          q = X'9F' and n=1 means FIND
 A response segment, caused by a READ or SREAD command, has the
 following format:
    RESPONSE <-----X'A1' + CURSOR(16) + n:LENGTH(16) + (TEXT(8) = n)
 where n > 0 is the number of characters actually read.  CURSOR(16) is
 an integer giving the final cursor position after the corresponding
 read command.  Note that the command READ 0 is permissible and may be
 used by the server to find the current cursor position, or to find
 out when the user presses _Transmit_.

Braden [Page 10] RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971

E. SCREEN SIZE

 For simplicity and consistency with URSA, we have chosen to treat the
 cursor as a single integer.  This in turn means that VCD and server
 must agree upon the number of columns M; it is also desirable for the
 server to know N.
 The agreement on M and N takes place through a one-sided negotiation.
 The server is assumed to know what M and N values he can handle and
 these are published for user sites.  When the VCD is first connected
 to the server, the VCD must send an Open response segment with the
 values M and N:
    Open segment <---- X'B1' + M(8) + N(8) + X'0000'
 If the VCD fails to send this segment or the server does not like the
 values, the server closes the connections and the user is considered
 logged off.

Endnotes

 [1] Graphic representation of start symbol: shaded triangle on its
 side.

Braden [Page 11] RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971

                      +---------------+
                      |               |
                      | D I S P L A Y |
                      +---------------+
                              ^
                              |
                              | Refresh
                              |
                      +---------------+
                      |     LOCAL     |    Address
                      |     BUFFER    |<------------+
                      +---------------+             |
                       ^  ^       |                 |
   +-----------+  text |  |       |                 |
  /            |_______|  |       |                 |
 |  KEYBOARD   |          |WRITE  |READ             |
 +-------------+          |AWRITE |SREAD            |
                          |       |                 |
          control         |       v                 |
                      +---------------+     +---------------+
                      |      VCD      |     | CURSOR ADDRESS|
                      |    CONTROL    |<--->|    REGISTER   |
                      +---------------+     +---------------+
                          ^       |                 ^
                          |       |                 |
                          |       |                 |
                          |       |                 |
                          |       |                 |
                          |       |                 v
                          |       |         +---------------+
                          |       |         |       S       |
                          |       |         |   REGISTER    |
                          |       |         +---------------+
                          |       v
                      +---------------+
                      |     COMM      |
                      |   INTERFACE   |
                      +---------------+
                          ^       |
                          |       |
                          |       v
                 COMMANDS           RESPONSES
                     Network Connections
            FIGURE 1.  VIRTUAL CHARACTER DISPLAY
            ------------------------------------

Braden [Page 12] RFC 205 NETCRT - A CHARACTER DISPLAY PROTOCOL 6 August 1971

                    Keyboard Unlocked
                  No Commands Executed
                 +--------------------+
                 |                    |
         +------>|       LOCAL        |------+
         |  +--->|       State        |      |
         |  |    +--------------------+      |
         |  |        |              |        |
         |  |        |              |        |
         |  |        |Break         |        |
         |  |        |              |        |   INS received
 LOCAL   |  |        | key          |        |
         |  |        |  [send INS   |        |
 Command |  |        |   and X'80'] |        |
 Executed|  |        |              |Transmit|
         |  | Reset  |              |        |
         |  |        |              |  key   |
         |  |  key   |              |        |
         |  |        v              v        |
         |  |   +--------------------+       |
         |  +---|       Control      |<------+
         |      |        State       |
         +------|                    |
          |     +--------------------+
          |      ^
          |      |  Keyboard locked,
          |      |  Execute Commands
          +------+
 After INS is
 received, LOCAL
 command is ignored
 until SYNC (X'80')
 is encountered
                  FIGURE 2.  VCD STATES
                  ---------------------
        [This RFC was put into machine readable form for entry]
         [into the online RFC archives by Lorrie Shiota, 2/02]

Braden [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc205.txt · Last modified: 2002/03/04 20:35 (external edit)