📄 rfc33.txt
字号:
operating systems overhead, and network transmission delays. Unless
we use special strategies it may be difficult or even impossible for
a distant user to make use of the more sophisticated subsystems
offered. While these difficulties are especially severe in the area
of graphics, problems may arise even for teletype interaction. For
example, suppose that a foreign subsystem is designed for teletype
consoles connected by telephone, and then this subsystem becomes
available to network users. This subsystem might have the following
characteristics.
1. Except for echoing and correction of mistyping, no action is
taken until a carriage return is typed.
Crocker, et. al. [Page 13]
RFC 33 New HOST-HOST Protocol 12 February 1970
2. All characters except "^", and "<-" and carriage returns are
echoed as the character is typed.
3. <- causes deletion of the immediately preceding character, and
is echoed as that character.
4. ^ causes all previously typed characters to be ignored. A
carriage return and line feed are echoed.
5. A carriage return is echoed as a carriage return followed by a
line feed.
If each character typed is sent in its own message, then the
characters
H E L L O <- <- P c.r.
cause nine messages in each direction. Furthermore, each character
is handled by a user level program in the local HOST before being
sent to the foreign HOST.
Now it is clear that if this particular example were important, we
would quickly implement rules 1 to 5 in a local HOST program and send
only complete lines to the foreign HOST. If the foreign HOST program
could not be modified so as to not generate echoes, then the local
program could not only echo properly, it could also throw away the
later echoes from the foreign HOST. However, the problem is not any
particular interaction scheme; the problem is that we expect many of
these kinds of schemes to occur. We have not found any general
solutions to these problems, but some observations and conjectures
may lead the way.
With respect to heterogeneous consoles, we note that although
consoles are rarely compatible, many are equivalent. It is probably
reasonable to treat a model 37 teletype as the equivalent of an IBM
2741. Similarly, most storage scopes will form an equivalence class,
and most refresh display scopes will form another. Furthermore, a
hierarchy might emerge with members of one class usable in place of
those in another, but not vice versa. We can imagine that any scope
might be an adequate substitute for a teletype, but hardly the
reverse. This observation leads us to wonder if a network-wide
language for consoles might be possible. Such a language would
provide for distinct treatment of different classes of consoles, with
semantics appropriate to each class. Each site could then write
interface programs for its consoles to make them look like network
standard devices.
Crocker, et. al. [Page 14]
RFC 33 New HOST-HOST Protocol 12 February 1970
Another observation is that a user evaluates an interactive system by
comparing the speed of the system's responses with his own
expectations. Sometimes a user feels that he has made only a minor
request, so the response should be immediate; at other times he feels
he has made a substantial request, and is therefore willing to wait
for the response. Some interactive subsystems are especially
pleasant to use because a great deal of work has gone into tailoring
the responses to the user's expectations. In the network, however, a
local user level process intervenes between a local console and a
foreign subsystem, and we may expect the response time for minor
requests to degrade. Now it may happen that all of this tailoring of
the interaction is fairly independent of the portion of the subsystem
which does the heavy computing or I/O. In such a case, it may be
possible to separate a subsystem into two sections. One section
would be a "front end" which formats output to the user, accepts his
input, and controls computationally simple responses such as echoes.
In the example above, the program to accumulate a line and generate
echoes would be the front end of some subsystem. We now take notice
of the fact that the local HOSTs have substantial computational
power, but our current designs make use of the local HOST only as a
data concentrator. This is somewhat ironic, for the local HOST is
not only poorly utilized as a data concentrator, it also degrades
performance because of the delays it introduces.
These arguments have led us to consider the possibility of a Network
Interface Language (NIL) which would be a network-wide language for
writing the front end of interactive subsystems. This language would
have the feature that subprograms communicate through network-like
connections. The strategy is then to transport the source code for
the front end of a subsystem to the local HOST, where it would be
compiled and executed.
During preliminary discussions we have agreed that NIL should have at
least the following semantic properties not generally found in other
languages.
1. Concurrency. Because messages arrive asynchronously on
different connections, and because user input is not
synchronized with subsystem output, NIL must include semantics
to accurately model the possible concurrencies.
2. Program Concatenation. It is very useful to be able to insert
a program in between two other programs. To achieve this, the
interconnection of programs would be specified at run time and
would not be implicit in the source code.
Crocker, et. al. [Page 15]
RFC 33 New HOST-HOST Protocol 12 February 1970
3. Device substitutability. It is usual to define languages so
that one device may be substituted for another. The
requirement here is that any device can be modeled by a NIL
program. For example, if a network standard display controller
manipulates tree-structures according to messages sent to it
then these structures must be easily implementable in NIL.
NIL has not been fully specified, and reservations have been
expressed about its usefulness. These reservations hinge upon our
conjecture that it is possible to divide an interactive system into a
transportable front end which satisfies a user's expectations at low
cost and a more substantial stay-at-home section. If our conjecture
is false, then NIL will not be useful; otherwise it seems worth
pursuing. Testing of this conjecture and further development of NIL
will take priority after low level HOST-HOST protocol has stabilized.
HOST/IMP INTERFACING
The hardware and software interfaces between HOST and IMP is an area
of particular concern for the HOST organizations. Considering the
diversity of HOST computers to which a standard IMP must connect, the
hardware interface was made bit serial and full-duplex. Each HOST
organization implements its half of this very simple interface.
The software interface is equally simple and consists of messages
passed back and forth between the IMP and HOST programs. Special
error and signal messages are defined as well as messages containing
normal data. Messages waiting in queues in either machine are sent
at the pleasure of the machine in which they reside with no concern
for the needs of the other computer.
The effect of the present software interface is the needless
rebuffering of all messages in the HOST in addition to the buffering
in the IMP. The messages have no particular order other than arrival
times at the IMP. The Network Control Program at one HOST (e.g.,
UTAH) needs waiting RFNM's before all other messages. At another
site (e.g., SRI), the NCP could benefit by receiving messages for the
user who is next to be run.
What is needed is coding representing the specific needs of the HOST
on both sides of the interface to make intelligent decisions about
what to transmit next over the channel. With the present software
interface, the channel in one direction once committed to a
particular message is then locked up for up to 80 milliseconds! This
approaches one teletype character time and needlessly limits full-
duplex, character by character, interactions over the net. At the
very least, the IMP/HOST protocol should be expended to permit each
side to assist the other in scheduling messages over the channels.
Crocker, et. al. [Page 16]
RFC 33 New HOST-HOST Protocol 12 February 1970
CONCLUSIONS
At this time (February 1970) the initial network of four sites is
just beginning to be utilized. The communications system of four
IMPs and wide band telephone lines have been operational for two
months. Programmers at UCLA have signed in as users of the SRI 940.
More significantly, one of the authors (S. Carr) living in Palo Alto
uses the Salt Lake PDP-10 on a daily basis by first connecting to
SRI. We thus have first hand experience that remote interaction is
possible and is highly effective.
Work on the ARPA network has generated new areas of interest. NIL is
one example, and interprocess communication is another. Interprocess
communication over the network is a subcase of general interprocess
communication in a multiprogrammed environment. The mechanism of
connections seems to be new, and we wonder whether this mechanism is
useful even when the processes are within the same computer.
REFERENCES
1 L. ROBERTS
"The ARPA network"
Invitational Workshop on Networks of Computers Proceedings
National Security Agency 1968 p 115 ff
2. R M RUTLEDGE et al
"An interactive network of time-sharing computers"
Proceedings of the 24th National Conference
Association for Computing Machinery 1969 p 431 ff
3. F E HEART R E KAHN S M ORNSTEIN W R CROWTHER
D C WALDEN
"The interface message processors for the ARPA network"
These Proceedings
LIST OF FIGURES
Figure 1 Initial network configuration
Figure 2 A typical message from a 24-bit machine
Figure 3 A typical socket
Figure 4 The relationship between sockets and processes
Figure 5 A typical TELNET dialog.
Underlined characters are those types by the user.
Crocker, et. al. [Page 17]
RFC 33 New HOST-HOST Protocol 12 February 1970
SRI
_____
/ \
| XDS |
| 940 |
\_____/
|
+----------+
| IMP |
+----------+
/ | \
/ | \
/ | \ +----+ _____
/ | \ | I | / \
______ +----+ / | \| M |--| DEC |
/ \ | I |/ | | P | | PDP-10|
| IBM |---| M | | +----+ \_____/
| 360/75 | | P |\ |
\______/ +----+ \ | UTAH
\ |
UCSB \ |
+----------+
| IMP |
+----------+
|
___|___
/ \
| XDS |
|(sigma)-7|
\_______/
UCLA
Figure 1 Initial network configuration
Crocker, et. al. [Page 18]
RFC 33 New HOST-HOST Protocol 12 February 1970
|<------------ 24bits ----------->|
| |
+---------------------------------+
| |
| Leader (32 bits) |
| __________________|
| | 100 --- ----0 |<----16 bits of marking
+--------------+------------------+
| |
| |
| Text of messages (96 bits) |
| |
+------------------------+--------+
| 100----- ----0|
+-------^----------------+
|
|______16 bits of padding added
by the interface
Figure 2 A typical message from a 24-bit machine
24 8 8
+----------------------+-----------+----------+
| User Number | | |
+----------------------+-----------+----------+
| |___AEN
|
|___HOST number
Figure 3 A typical socket
|<--- connection --->|
+---------+ +---------+
| | link | |
| process |--(|--------------|)--| process |
| | ^ ^ | |
+---------+ | | +---------+
| |
send socket receive socket
Figure 4 The relationship between sockets and processes
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Lorrie Shiota 08/00]
Crocker, et. al. [Page 19]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -