| 楼主 |
2004-10-19 15:43:00 |
积分：0分
|
Network Working Group George H. Mealy
Request for Comments: 91 Harvard University
December 27, 1970
A PROPOSED USER-USER PROTOCOL
INTRODUCTION:
There are many good reasons, and maybe one or two bad ones, for making
it appear that communication over the Network is only a special case of
input/output -- at least as far as user programming is concerned. Thus,
for instance, the Harvard approach toward implementing the HOST-HOST
protocol and Network Control Program treats each link as a "logical
device" in PDP-10 terminology. Setting up a connection is similar to
local device assignment, and communication over a link will make use of
the standard system input/output UUO's. This makes it possible to sue
existing programs in conjunction with the Network without modification
-- at least if other PDP-10's are being dealt with.
This takes us only so far, however. The notion of a "logical device"
does not exist on the PDP-10; it does on the IBM 360 (I am speaking here
at the level of the operating system -- user program interface).
Furthermore, in the absence of a Network standard requiring fixed
representations for integers, reals, etc. (which I would oppose), any
pair of user processes must arrive at a local agreement, and one or both
must assume the burden of data conversion where necessary. Any standard
protocol should allow such agreements to be given expression and should
accommodate at least the minimum of control information that will allow
such agreements to function in practice. Finally, we must note that the
IMP-IMP and HOST-HOST protocols do not provide for a check that an
action requested by a user process is actually accomplished by the other
processes; this type of issue has always been regarded as subject to
treatment at the USER-USER protocol level.
This proposal is intended to face the above three types of issue only to
a certain extent. I can best explain that extent by stating the
criteria I would use to judge any USER-USER protocol proposal:
1. The notion of a (logical) record
should be present, and the notion of a message should be
suppressed. (To a FORTRAN programmer, that which is
written using one WRITE statement with no accompanying
FORMAT is a record; to an OS/360 machine language
programmer, PUT writes a record).
[Page 1]
2. It should be possible to so implement the
protocol in HOST systems and/or library routines that now
existing user programs can access files anywhere in the
Network without program modification. (Initially, at
least, this ability must be restricted to HOST systems of
the same type).
3. The protocol should be implementable (not
necessarily implemented) in any HOST system at the SVC or
UUO level. Specific knowledge of the characteristics of
the other HOST involved should be unnecessary.
It should be noted that the above imply that some user programs must be
aware of the nature of the other HOST -- at least in each case where the
second criterion fails. As we make progress in (or give up on) the cases
where the failure now occurs, the burden of accommodating system
differences will shift toward implementation in protocols (i.e., the
HOST systems) or, by default, in user programs.
Quite clearly, any proposal initiated today should be suspect as to the
extent to which it "solves" ultimate problems. How ambitious to be is
strictly a matter of taste. At this stage, I prefer to try something
which I believe can be used by all of us (and, hence, is worth doing),
goes a reasonable distance towards solving our short-range problems, is
easy to do, and offers hope of viability in the long range view. In the
following, I intend to describe the proposal itself with, I hope, proper
motivational arguments for its pieces. I will then sketch the specific
implementation we at Harvard are making for the PDP-10 and describe how
we intend to apply it in the specific case of storage of files on other
PDP-10's in the Network.
USER-USER PROTOCOL (PROPOSAL)
The following protocol is intended to apply to the data bits in messages
between the end of the marking bits and the beginning of the padding
bits.
The present IMP-IMP and HOST-HOST protocols are unaffected by this
proposal.
The general principle is that each segment (this is not a technical
term) of data is preceded by control information specifying its nature
and extent. The basic scheme has been evolved from that used in the SOS
buffering system (see the papers in JACM, April 1959 and especially that
by O.R. Mock).
Our point of view is that a link is a carrier of information.
[Page 2]
Information is carried in segments of a fixed maximum length called
messages*.
That this is so is an accident, from the user's point of view; when he
wishes to transmit a contiguous stream of data, he will in general,
segment it in a different (from the IMP-IMP or HOST-HOST protocol view)
manner -- we will call his segment a record. It should be clear that
this is entirely analogous between the notion of (physical) block and
(logical) record. On the side, file storage systems also make use of
control and status information; we will also.
At the USER-USER protocol level, all information transmitted over the
link is a sequence of flags followed by (possibly null) data blocks.
The general |
 回复
|
|
| 1楼 |
2004-10-17 11:22:00 |
|
积分：0分
|
Network Working Group A. McKenzie
Request for Comments #93 BBN
Updates RFC's 66, 80 January 1971
Initial Connection Protocol
A review of the Initial Connection Protocol (ICP) first
described in RFC #66 and restated in RFC #80 has revealed an area of
ambiguity, which in turn reflects an ambiguity in the Host-Host
Protocol Document No. 1. This is the definition of the message sent
over the connection from "Server socket #1". In both referenced
RFC's, the message is defined as "exactly an even 32 bit number". It
is not clear, however, whether this 32 bit number is meant to follow
an eight-bit "message data type" code or not, stemming from the fact
that the Host-Host Protocol makes provision for such codes but does
not seem to absolutely demand them.
Only one implementation of an ICP has been documented in the
NWG literature - that at UCSB (RFC #74). The implementers of this ICP
have apparently interpreted the Host-Host Protocol as demanding a
message data type code, and therefore do transmit a code of zero.
Steve Crocker indicates (private communication) that the Host-
Host Protocol was intended to require a message data type code. We
therefore recommend that RFC numbers 66 and 80 be amended to show that
the "even 32 bit number" is preceded by a message data type code of
zero (zero is the only code currently defined).
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by James Thompson 4/97 ]
[Page 1]
|
| 回复
|
|
| 2楼 |
2004-10-17 11:22:00 |
|
积分：0分
|
places a whole logical record in the output buffer(s). The
effective address is that of a word:
IOWD count, location
A PUTF UUO must have been used to output the proper SIZE flag.
Thereafter, each use of PUT will output a BLOCK flag,*
simulate a number of calls to PUTD using the IOWD to discover the
location and size of the user data area, and then output a RS flag to
indicate end of record.
In the case of byte size of less than 36 bits, PUT will use the ILDB
instruction to pick up bytes to be output by PUTD. Hence, the standard
PDP-10 byte handling format is used, and the count part of the IOWD is
the total byte count, not word count.
The above UUO'S have both an error return and a normal return.
GETFD UUO:
The calling sequence for this UUO is:
GETFD CH, E
error return
whyte flag return
block flag return
data return
[Page 8]
The effective address is the location at which the flag or data will be
returned. The flag is returned in the same format as for PUTF and the
data in the same format as for PUTD. Certain flags (NUL, IGNORE, and
EOM) will be handled entirely with the UUO and will not be reported to
the user. SYS should eventually be handled this way, but initially will
be handled by the user.
GET UUO:
The calling sequence for this UUO is:
GET CH, E
error return
end of file return
end of group return
normal return
GET transmits the next logical record to the user, using GETFD together
with an IOWD in the same format as for PUT. If the IOWD count runs out
before end of record, the remainder of the record will be skipped. In
any case, the updated IOWD will be returned at the effective address of
the UUO in order to inform the user how much data was transmitted or
skipped.
PDP-10 FILE TRANSMISSION:
Assume that I have a link connected to another PDP-10 and a user process
there that is listening. In order to get that process to send me a file,
the sequence of flags that might be transmitted can be represented as
follows, where the UUO'S executed by me are in the left margin, the
flags are indented, and the commentary opposite them indicates the
nature of the data block transmitted:
[Page 9]
PUT F
CONTROL Data with OPEN parameters, requesting OPEN
LABEL File identification data for LOOKUP
EOM Forces message to be transmitted
GETFD
STATUS Status returned by OPEN
SIZE Byte size to be used
LABEL File retrieval information
PUTF
CONTROL Data requesting INPUT from file
EOM Forces request to be transmitted
GETFD
STATUS Status bits returned by INPUT
GET Logical record (one file buffer load)
(loop back to second PUTF, above, for other records)
Finally, the status information returned by the second GETF indicates
end of file, and I wind up with the sequence:
PUTF
CONTROL Data requesting a CLOSE
EOM Forces transmission
GETFD
STATUS Status bits returned by CLOSE
In the case I am getting a file, the main loop looks like:
PUTF
CONTROL Data requesting OUTPUT
PUT Logical record (one file buffer load) PUTF
EOM Forces transmission
GETFD
STATUS Status bits returned by OUTPUT
The use of both the record and the flag transmission UUO's is worth
noting, as well as the use of the EOM flag to force transmission of a
message when switching between input and output over the link. PUT and
GET UUO's are clearly required above for transmission of the CONTROL and
LABEL data; I suppressed them for the sake of clarity.
For this application, the handshaking nature of the transmission of
CONTROL and STATUS flags are mandatory. While the protocol would permit
[Page 10]
transmission of a complete file without the handshaking, it would be an
all or nothing proposition - a single error would necessitate doing it
all over again, presuming that the receiving process did not end up in a
complete tangle.
BRIEF DISCUSSION:
The PDP-10 space required to implement the above protocol is about 400
instructions, divided equally between the input and the output side.
Enough experimental coding has been done to confirm the feasibility of
this basic strategy, taken together with experience with implementation
and use of the SOS buffering system.
The above does not touch the question of LOGON protocol, except
indirectly. My belief is that it can be accommodated in the framework of
this proposal, but I have not tested this theory as yet. As indicated
further above, I would be tempted to handle the matter with the SYS
flag, given that SYS data is interpreted directly by the system (in our
system, we would use the RUN UUO to run the LOGON CUSP, which would, in
turn handshake using ASCII data over the link). In this way, I think we
might be able to dispense with the notion of dedicated sockets and the
reconnection morass.
One other point that needs thought is the question of how to handle the
interrupt on link facility. Should it have any direct relation to the
GET/PUT UUO's, or be handled on the side? I am inclined to think that it
should be treated qua interrupt of the user process, quite independently
of the matter of data transmission over the link. Some of our current
work on the PDP-10 monitor would lend itself rather easily to
implementation as a true interrupt.
ENDNOTES*
1. A message is that string of bits between any two HOST-HOST headers.
2. In memory of an attractive, but nonspelling, SDC secretary who
could not distinguish between black and white, at least during 1957
and in manuscript form.
3. PUTF may be used to ouput the block flag, if a different from
BLOCK is required.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Colin Barrett 9/97 ]
[Page 11]
|
| 回复
|
|
| 3楼 |
2004-10-17 11:22:00 |
|
积分：0分
|
KEY USERI/USETO argument
CONTROL READ IN/INPUT
WRITE OUT/OUTPUT
ALLOCATE ? ENTER
OPEN ? LOOKUP
STATUS ? GETSTS
The "?" notations above indicate lack of a very direct parallel. It is
worth noting that the OS/360 GET and PUT have direct parallels in any
implementation of the USER-USER protocol that embodies the notion of
record; our implementation of the protocol will lead to introduction of
this notion for all PDP-10 input/output involving disc and tape storage,
as well as IMP communication.
[Page 5]
If I know the MULTICS terminology, I could extend the set of parallels
above with more precision. Although my terminology has been drawn from
systems with explicit input/output imperatives, I wish to emphasize that
this setup in intended to handle control and data communication in
general; MULTICS is a system in which the classical distinction between
external and internal storage is blurred (from the user's point of view)
in a manner I wish it blurred in the USER-USER protocol. I offer SYS
with only slight trepidation. The general notion is that one should be
able to communicate directly with a foreign HOST rather than via a
foreign user process as its intermediary, SYS is like a UUO or SVC, but
for the foreign HOST's consumption rather than my HOST's. From the
HOST's point of view, the problem in implementation is in establishing a
process context record unconnected with any local user process. This,
however, is strongly associated with our current LOGON conundrum. On the
PDP-10, for instance, users are more or less identified with local
teletype lines, and any link is not one of those! Hence, subterfuge is
necessary to let a foreign user log on. OS/360 is as (actually, more)
perverse in its own way.
The process of logging a foreign process onto my local system is not
(except possibly for MULTICS) a simple matter of having a special (!!)
user job present which is responsible for doing it. When and if
anything else is possible, the HOST must provide a system instruction
(UUO or SVC or whatever) that gives the requisite information
establishing a process independent in all senses of the process that
made the request. Otherwise, self- protection mechanisms which are
reasonable for any system will make us all much more interdependent that
we wish. To do this, there must exist in every system a UUO/SVC that
does the right thing (ATTACH, but forget me). If this is true, then the
LOGON process over the Network is tantamount to issuance of a foreign
UUO/SVC by another node in the Network. I see no reasonable way around
this. If that is the case, then SYS N is the kind of flag to use to
convey the requisite data. If that is so, then it is only reasonable to
let SYS convey a request for any OS instruction at the user program-
operating system interface level!
The practical questions of implementation are something else! In the
case of the PDP-10, I can pretty well see how to turn a SYS into either
a LOGON request to execute a monitor command or UUO (would that they
were the same) as the case might be. OS/360 is more sophisticaed,
unfortunately. MULTICS might make it. Naytheless, I hope that is clear
that what we want to do, which is what the protocol should reflect, is
quite a different question from that of how it is to be done in the
context of a specific HOST system. What we want to do is, in general,
rather independent of the system we are dealing with as far as the
protocol is concerned, and we should not fail to introduce general
notions into the protocol just because we are uncertain as to how they
may have to be translated into particular implementation practice.
[Page 6]
A PDP-10 IMPLEMENTATION
Although the following can be implemented as either a set of user
routines or imbedded in the monitor as UUO's (our first implementation
will be the former), the latter version will be used for descriptive
purposes. The UUO's would be:
PUTF CH, E Put flag
PUTD CH, E Put data
PUT CH, E Put record
GETFD CH, E Get flag or data
GET CH, E Get record
In the above, "CH" is the logical channel number. The customary OPEN or
INIT UUO is used to open the channel. Standard format user buffers are
assigned. However, the ring and buffer headers will be used in a
nonstandard way, so that data mode 12 is assigned for used with Network
buffering and file status bit 31 must be on for input. (Any of the
devices DSK, DTA, MTA, or IMP can be used in this mode.)
In the Harvard NCP and HOST-HOST protocol implementation, user buffers
do not correspond directly to messages. On output, each user buffer will
be formatted into a message; on input, a message may become one or two
user buffer loads (128 word buffers are used in order to make maximum
use of the facilities of the disk services routines).
PUTF UUO:
This UUO places a flag into the output buffer. The effective address is
the location of a word:
XWD operation, count
In the case of block flags, the count is ignored, since it will be
computed from the number of bytes actually placed in the buffer before
the next use of PUTF. PUTF and PUTD will insert EOM flags automatically
as each buffer becomes full; if data bytes are currently being placed in
the buffer by PUTD, it will also insert an EOM flag after computing the
count for the previous block flag in the buffer and place a new block
flag of the same type at the beginning of the next buffer, after
inserting a SIZE flag stating the then current byte size.
PUTD UUO:
This UUO places data into the output buffer. The effective address is
the location of the data byte (if the byte size is less than 36) or of
the next 36 bit word of data to be placed in the buffer. In the first
case, the byte is assumed to be in the low order part of the word
[Page 7]
addresses. In the second case, the data word containing the final bits
of the byte contains them in the high order part of the word, and the
next data byte starts a new word in PDP-10 storage. Thus, for a byte
size of 64, two .ne 5 entries to PUTD would be used per byte
transmitted, the first containing 36 bits and the second containing 28
bits, left- justified. This strategy allows maximum use of the PDP-10
byte handling instructions.
PUT UUO:
This UUO |
| 回复
|
|
| 4楼 |
2004-10-17 11:22:00 |
|
积分：0分
|
format will be:
OPERATION COUNT DATA
The OPERATION field is always present and is four bits long. The COUNT
field, when present, gives the number of data bytes following in the
data block. The bytes size is set be the last preceding SIZE flag (in
most cases). The byte may be between zero and 255 bits long (Yes,
Virginia, zero is zero even when you have a System/360). The OPERATION
field and the COUNT field (when present) are called the flag and the
data bytes (when present) the data block. Flags followed by data blocks
(even when null due to a zero count) are called block flags, and other
flags are called whyte* flags.
It is to be noted that, since the SIZE flag sets the byte size for the
following blocks, byte size may be set at that "natural" for the sending
or for the receiving HOST, depending on local agreement between the
sending and receiving processes. It is specifically required that a SIZE
flag appear in each message prior to any block flag (except the ASCII
flag); the SIZE flag may be introduced on a default basis by the
routine(s) implementing the protocol and is intended partially as a
means of detecting certain classes of error.
The COUNT field is 8 bits in length (except in the EOM flag, where it is
16 bits long). The flags are as follows:
[Page 3]
Whyte Flags:
0 - NUL No operation (consider next flag)
1 - RS Record Separator (end of record)
2 - GS Group Separator (end of group)
3 - FS File Separator (end of file)
4 - ESC Escape to local convention for flags
5 - (reserved for later assignment)
6 - EOM N End of Message (M is total bit count)
7 - SIZE N Byte size is N bits
8 - IGNORE N Ignore following data bits
Block Flags:
9 - SYS N N bytes of data for receiving HOST system
10 - CONTROL N N bytes of control data follow
11 - STATUS N N bytes of status data follow
12 - LABEL N N bytes of identification data follow
13 - KEY N N bytes of key data follow
14 - ASCII N N (8-bit) bytes of ASCII data follow
15 - BLOCK N N bytes of data follow
I have already mentioned the requirement for SIZE. Absence of the SIZE
floag in any message containing block flags (except ASCII) is a definite
error. EOM is partially another error-checking device and partially a
device for bypassing the padding conundrum. A user program should never
see EOM on input; the user may write an EOM to force transmission. EOM
delimits the end of the useful information in the message and restates
the total number of bits in the message, starting with the first bit
following the marking and ending with the last bit of the EOM count
field, to check possible loss of information. This is a check against
errors in the IMP-HOST electrical interface and in the HOST mushyware.
EOM must appear at the end of each messager, unless ESC has apeared.
ESC is intended as a (hopefully) unused [a]scape hatch, for nonuse by
those installations and/or applications wishing to avoid using more than
four bits of the USER-USER protocol on any link. For instance, it may be
desired to use a link as a bit stream, ignoring even message boundaries.
If and when anarchists can achieve local agreement, more power to them!
NUL and IGNORE are intedned to be space fillers, in case it is helpful
to make the first bit of the subsequent data block occur on a convenient
address boundary. (An especially helpful HOST interrupt routine might
even paste a combination of NUL and IGNORE over the marking bits when
receiving a message -- in which case, their bit count should be
transmitted on to the GET rountines to correct the EOM bit count check).
The separator operations introduce the notions of logical record, group,
and file. Specifically, there is no requirement that a record be
[Page 4]
contained entirely within a message or that only a single record be
contained in a message! In addition, there is no requirement that only
one file be transmitted during a connection. For instance, a user might
wish to use a link to transmit a collection of rountines, and then do
something else with the link. By local agreement, then, a single routine
might consist of a cumber of records forming a group, the whole
collection might form a file, and the link might remain connected after
the FS flag is received.
The interpretation of the various block flags is similarly open to local
agreement. The two flags intended to convey pure data are ASCII and
BLOCK; the difference between them is only (as far as the protocol is
concerned) that the byte size is implicit for ASCII (8 bits) and
explicit for BLOCK (the count field of the next preceding SIZE flag).
Beyond this, however, the semantic content of the block following ASCII
is governed by the current standards for ASCII; EBCDIC information may
not be transmitted in an ASCII block!!
CONTROL and STATUS are intended for communication of control information
between user processes, and the interpretation of their accompanying
data blocks is open to local agreement. Generically, CONTROL means "try
to do the following" and STATUS means "but I feel this way, doctor." A
CONTROL flag will prompt a returned STATUS flag, sooner or later, or
never. LABEL is intended for use in identifying the following unit(s) of
data, at the file or group level. Again, the specific interpretation is
a matter of local agreement. KEY is intended to mimic the notion of
address or key -- this is at the record, data item, or even physical
storage block level. For the familiar with PDP-10 system and/or OS/360,
the following parallels are offered for guidance:
USER-USER protocol OS/360 PDP-10
CONTROL OPEN OPEN
CLOSE CLOSE
LABEL DSCB File retrieval information
KEY |
| 回复
|
|
| 5楼 |
2004-10-17 11:23:00 |
|
积分：0分
|
Network Working Group
Request for Comments #98
Network Information Center #5744
Logger Protocol Proposal
Edwin W. Meyer, Jr.
Thomas P. Skinner
February 11, 1971
With the ARPA Network Host-to-Host Protocol specified and at
least partially implemented at a number of sites, the question of what
steps should be taken next arises. There appears to be a widespread
feeling among Network participants that the first step should be the
specification and implementation of what has been called the "Logger
Protocol"; the Computer Network Group at project MAC agrees. The term
"logger" has been commonly used to indicate the basic mechanism to gain
access (to "login") to a system from a console. A network logger is
intended to specify how the existing logger of a network host is to
interface to the network so as to permit a login from a console attached
to another host.
To implement network login capability now seems quite
desirable.In the first place, it is natural for Network participants to
wish to learn more about the remote systems in the immediate fashion
afforded by direct use of those systems. In the second place, the
technical problems introduced by remote logins are probably less complex
than those involved with such further tasks as generalized file
transfer; thus, a Logger Protocol could be implemented relatively
quickly, furnishing additional impetus and encouragement for taking
still further steps.
In order to furnish at least a basis for discussion (and at most
an initial version of a Logger Protocol), we have prepared this
document, which attempts to present a minimal set of conditions for
basing a Logger Protocol. This proposal covers only the mechanism for
accomplishing login. What occurs following login is not discussed here,
because we feel more experimentation is necessary before any protocol
for general console communication can be established as standard. In its
absence, each site should specify its own experimental standards for
console communications following login.
Some of the points raised in this document have already reached
a certain level of consensus among network participants while at least
one point is rather new. It should be clearly understood, however, that
we feel regardless of the disposal of particular issues, Networkwide
[Page 1]
RFC 98 Logger Protcol Proposal Feb 1971
agreement should be reached as soon as possible on some general
protocol. This is all the more desirable in view of the fact that it is
quite likely that certain points which should be covered in this
protocol will only become apparent during the course of implementation;
therefore, the sooner a common basis for implementation can be reached,
the sooner a more rigorous protocol can be enunciated.
Before turning to 1) a discussion of the points with which to
decide the protocol should deal, and 2) specifications for the current
state of the protocolm we feel that we should acknowledge the
consideration that a case could be made for avoidingthe difficulty of
generating a Logger Protocol by simply declaring that each host may
specify its own, perhaps unique, preferences for being approached over
the Network. Although such a course is certainly possible, it does not
seem to us to be desirable. One reason for avoiding such a course is
simply that following it hamper general Network progress, in that
adressing the task of interfacing with some 20 systems is bound to more
time-consuming than to interface with "one" system, even though each
indivudual one of the former, multiple interfaces might be in some sense
simpler than the latter, single interface. Another consideration is less
pragmatic, but nonetheless important: agreement on a common protocol
would tend to foster a sense of Network "community", which would tend to
be fragmented by the local option route. After all, the Host-to-Host
Protocol could have been handled on a per-host basis as well; assumedly,
one reason why it has not had something to do with similar, admittedly
abstract considerations.
Context
Structurally, the mechanism serving to login a user over the Network
consists of two parts, one part at the using host, the other at the
serving host. The using or local host is the one to which the users
typewriter is directly connected; it contains a modulewhich channels and
transforms communications between the Network connection and the
typewriter. The serving or foreign host provides the service to be used;
it contains programming that adapts the logger and command system to use
through the Network rather than a local typewriter.
There are three different phases to a login through the network.
1. During the connection phase the users console is connected to
the serving logger through the network. This is, of course,
the most important phase from the protocol viewpoint.
2. The second or dialog phase consists of a sequence of exchange
between the user and the logger that serves to identify the
user and verify his right to use the system. In some hosts,
this phase may be minimal or non-existent.
[Page 2]
RFC 98 Logger Protcol Proposal Feb 1971
3. The admission phase occurs after the user has successfully
completed the login dialog. It consists of switching his
network typewriter connections from the logger to an entity
providing a command processor of some sort. In some hosts
|
| 回复
|
|
| 6楼 |
2004-10-17 11:23:00 |
|
积分：0分
|
1 - Character at a time half duplex
Case 2 - Character at a time full duplex
Case 3 - Line at a time half duplex
Although line at a time is full duplex is a logical possibility,
no such approach is in general use and we ignore it in the following
discussion.
In the discussions to follow, in Section 2b, 2c and 2d, we describe
the modes of access which we would like to investigate
experimentally. We want to study user reaction with 10 char/sec, 15
char/sec, and 30 char/sec devices.
2b. User Program Telnet
Consider the above classes of terminal in turn and the ways the
Telnet program might handle communications between them and the NIC.
The Telnet program might allow both full and half duplex
communication as specified by the user.
2b1. Case 1 - Character at a Time Full Duplex
The simplest approach would be for the Telnet program to
take each character received from the terminal (except a special
character or character sequence needed to escape back to the
terminals host system), convert the code to ASCII and transmit it
as a message to NLS(NIC). NLS(NIC) would handle all character
echoing and transmit echo messages back to the Telnet for actual
transmission to the terminal in the appropriate terminal code.
This mode of communication involves full duplex transmission user
to user and is probably the severest test of the interactive
characteristics of the host-network-host system.
[Page 3]
NETWORK WORKING GROUP RFC #96 NIC 5739
Depending on loading at the remote host, on the network, and
at ARC, round trip delay for simple character echoing may be
several seconds. Experience in communication between the old ARC
940 and a heavily loaded PDP-10 at Utah showed occasional delays
on the order of 4 or 5 seconds and longer for single character
echoing. Human factors considerations in use of NLS(NIC) indicate
that such delays would be frustrating to the user. A more cageful
study of this mode of communication should give a base against
which to measure the other modes of communication.
2b2. Case 2 - Character at a Time Half Duplex
There are two subcases which we treat identically:
i) The Telnet program sees a half duplex terminal.
ii) The Telnet program sees a full duplex terminal, but
provides echoing so as to make the terminal half duplex as seen
by NIC.
With the character at a time half duplex case the NIC program
will operate in two modes:
a) short mode
b) long mode
In short mode the user will type in the command and receive on
his terminal only the characters echoed by his system and the
NIC response to the command.
In long mode. the user will receive feedback from NIC at an
appropriate point in the command. We want to see how novice and
experienced users feel about working in these two modes, given
the delays in the system response.
2b3. Case 3 - Line at a Time Half Duplex
From the point of ciew of the NIC this case is essentially the
same as Case 2. From the point of ciew of the network this
case is a more efficient use fo the network as the messages are
longer. This case is also more efficient for the user host
system as it will require fewer calls to the Telnet subsystem;
response for Case 3 may be better than Case 2.
[Page 4]
NETWORK WORKING GROUP RFC #96 NIC 5739
2c. The NLS(T) Front End
In this mode of communication, the subsystem which handles
communication with the NIC is to perform some of the interactive
and other tasks now performed by NLS(T). The type of tasks to be
performed are echoing of the characters typed and the additional
feedback characters for the full spell out of the command words,
parsing of the command string, error handling where appropriate,
and the sending of a parsed string as a message to NLS(T). If it
should turn out that this mode of communication is the one
preferred by sites, we would expect to supply an example version
of the Front End program written in some language to serve as a
model for implementation. The Network Working Group may want to
give further study to a standard language for specifying such
programs as indicated in NWG/RFC 51, NIC (4752,).
2d. Monitor Telnet
Much of the response delay in the experiments of Section 2b
is expected to result from the fact that the Telnet described
there is a user program. We will run the experiments of Section 2b
with the appropriate Telnet routines resident as a part of the
user host monitor.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Henrik Johansson 4/97 ]
[Page 5]
|
| 回复
|
|
| 7楼 |
2004-10-17 11:23:00 |
|
积分：0分
|
Network Working Group NIC 5739
Request for Comments: 96 Richard W. Watson
Category: Informational SRI-ARC
12 February 1971
An Interactive Network Experiment to Study Modes of Access the Network
Information Center
1. Introduction
This NWG/RFC outlines the framework for a simple interactive
experiment to study modes of access to the Network Information Center
(NIC). A detailed specification for the initial access conventions to
the NIC is contained in NWG/RFC 97, NIC (5740,). The initial online
service to be provided by the Network Information Center are oriented
around the SRI-ARC (ARC) Online System, typewriter version - NLS(T).
These services will involve creation, manipulation, searching, and
distribution of symbolic material (text initially). The initial Online
System was display oriented and considerable development has gone into
the study of features required for a comfortable interface to the user.
In preparation for use with the Network Information Center, a typewriter
oriented version has been developed. Assuming good computer response and
a typewriter terminal operating at 30 char/sec, the system provides
powerful and comfortable to use capabilities for handling structured
textual material.
The question to which the experiment, to be described below,
addresses itself is to determine how to extend these capabilities
through the network to users at remote sites, possibly operating 10
char/sec and higher speed terminals through fairly heavily loaded
systems. This experiment will also provide useful information about the
interactive characteristics of the network, and guidelines for designers
of other interactive systems to be used with the network. We propose
that this experiment will be conducted with the assistance and
cooperation of one other site. We estimate that the experiment will
require about three calendar months. In order to minimize the resources
required for the experiment, we will collect meaningful response time
statistics that are easy to obtain with presetly existing metering
facilities in the SRI and cooperating site systems, and network
performance measuring facilities. We will not conduct formal
productivity studies with the users of the connection, but will obtain
their subjective impressions on use of the various connection modes. The
result will be data indicating the costs and benefits obtained using the
types of access described below. We would expect that this information
would be useful to sites in determining how they want to implement
access to the NIC and other interactive sites.
[Page 1]
NETWORK WORKING GROUP RFC #96 NIC 5739
During the period of the experiment, other sites will want to access the
NIC as they come up on the network. We would recommend a simple
approach, such as described in Section 2b, initially with a possible
change later if the experiment indicates improved response and/or human
factors coupling can be obtained with one of the other approaches,
NWG/RFC 97, NIC (5740,) specifies this initial access approach in
detail.
2. Getting Connected to the Network
2a. Introduction
There are three basic approaches to allowing remote sites to
connect to the NIC through the network, which we can call User
Program Telnet, NLS(T) Front End, Monitor Telnet. Each of these is
discussed below. Each approach requires code which will run in the
remote host.
We assume that standard conventions for Telnet programs will be
specified by the Network Working Group. In the companion paper
(NWG/RFC 97), NIC (5740,)) we include recommended conventions on
solving those problems which we are aware exists relative to initial
NIC access, although we have tried to specify conventions useful more
generally. The NLS(T) Front End Program would interface to the Telnet
Program.
We assume that no matter which approach is taken, the software
at the ARC end use the information obtained during the connection
process to log-in the remote terminal under a general account and
will place the terminal user in the NIC version of NLS, which we will
call NLS(NIC) for short. The NLS(NIC) will ask the terminal user for
his initials. The remote user then has access to all NIC facilities.
The initial typewriter oriented system accepts commands of the
general form:
<command words> <operand> <delimiter> ... <operand> <delimiter>
The <command words> is usually two words, the first to indicate
a general operation class, and the second to indicate a general data
structure type to be operated on. The <operand>s specify specific
data entities to be operated upon, or instructions to adjust NLS
parameters.
[Page 2]
NETWORK WORKING GROUP RFC #96 NIC 5739
The system at ARC is full duplex and allows the user to type the
first character of the command words and the system immediately echos
the remaining characters as feedback and support for the user. Other
feedback is echoed where appropriate. The question we need to answer
is what changes in this system will be required to suit it to the
network and remote site constraints. We now look at problems existing
at the remote sites.
To gain connection to the NIC we assume that the user logs into
his local system and calls up a subsystem or cusp. This subsystem or
system program, Telnet program will be used to access other sites as
well. The remote terminal and its controlling software system can
operate in three basic modes as seen by the host subsystems
Case |
| 回复
|
|
| 8楼 |
2004-10-17 11:23:00 |
|
积分：0分
|
Computer Science Department ext. 267
Schenley Park
Pittsburgh, Pa. 15213
Richard Winter CCA
Computer Corporation of America (617) 491-5301
565 Technology Square
Cambridge, Mass. 02139
Robert Sundberg HARV
Harvard University (517) 495-4147
Aiken Computation Laboratory
33 Oxford Street
Cambridge, Mass. 02138
James Madden ILL
University of Illinois (217) 333-0395
Center for Advanced Computation
168 Engineering Research Laboratory
Urbana, Illinois 61801
Joel Winett (for the 360) LINC
Massachusetts Institute of Technology (617) 862-5500
Lincoln Laboratory ext. 7474
244 Wood Street
Lexington, Mass. 02173
William Kantrowitz (for the TX-2) LINC
Massachusetts Institute of Technology (617) 862-5500
Lincoln Laboratory ext. 7349
244 Wood Street
Lexington, Mass. 02173
Albert Vezza MAC
Massachusetts Institute of Technology (617) 864-6900
Project MAC ext. 5877
545 Technology Square
Cambridge, Mass. 02139
Crocker [Page 3]
RFC 95 Distribution of NWG/RFCs Through the NIC February 1971
David Wood MITRE
Mitre Corporation (703) 893-3500
Information Systems Dept., W140 ext. 2528
Westgate Research Park
McLean, Va. 22101
Thomas Lawrence RADC
Rome Air Development Center (ISIM) (315) 330-3857
Griffiss Air Force Base (315) 330-7834
Rome, New York 13440
John Heafner RAND
Rand Corporation (213) 393-0411
Computer Science Department ext. 7606
1700 Main Street
Santa Monica, Calif. 90406
Abe Landsberg SDC
System Development Corporation (213) 393-9411
2500 Colorado Avenue ext. 454 or 6119
Santa Monica, Calif. 90406
Michael Wilbur SRAI
Stanford Research Institute (415) 326-6200
Artificial Intelligence Group ext. 4576
333 Ravenswood Avenue
Menlo Park, Calif. 94025
James A. (Andy) Moorer SUAI
Stanford University (415) 321-2300
Computation Center, AI Project ext. 4971
Stanford, Calif. 94305
Edward A. Feigenbaum SUHP
Stanford University, Heuristic Programming (415) 321-2300
Computation Center, Serra Hall ext. 4878
Stanford, Calif. 94305
Ari Ollikainen UCLA
University of California at Los Angeles (213) 825-2381
Computer Science Department
3732 Boelter Hall
Los Angeles, Calif. 90024
Crocker [Page 4]
RFC 95 Distribution of NWG/RFCs Through the NIC February 1971
Steve Crocker (for ARPA Office Liaison) UCLA
University of California at Los Angeles (213) 825-2368
Computer Science Department
3732 Boelter Hall
Los Angeles, Calif. 90024
James White UCSB
University of California at Santa Barbara (805) 961-2274
Computer Research Laboratory
Santa Barbara, Calif. 93106
Barry D. Wessler UTAH
University of Utah (801) 322-8378
Computer Science/IRL
Salt Lake City, Utah 84112
Author's Address
Steve Crocker
University of California at Los Angeles
Computer Science Department
3732 Boelter Hall
Los Angeles, CA 90024
Phone: (213) 825-2368
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Adam Costello 3/97 ]
Crocker [Page 5]
|
| 回复
|
|
| 9楼 |
2004-10-17 11:23:00 |
|
积分：0分
|
NIC 5731
Network Working Group Steve Crocker
Request for Comments: 95 UCLA
4 February 1971
Distribution of NWG/RFCs Through the NIC
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Notice
The Network Information Center (NIC), administered by Doug Engelbart
at SRI, has established (or is establishing) lines of communication
with all of the sites. The mechanism is for each site to have a
Station Agent and a Technical Liaison Contact. The Station Agent
maintains a small library of documents which arrive from the NIC.
The Technical Liaison Contact matches requests from the network
community to people or services at his site, and vice versa.
In my opinion, the current mailing list for the Network Working Group
seems to duplicate in large part the NIC's distribution system.
Therefore, I am making the following changes.
(1) Each site is presumed to have a Technical Liaison Contact.
Where none has been appointed, the current receiver of NWG notes
for that site will be assumed to be the Technical Liaison
Contact. (Each site may change its Technical Liaison Contact by
notifying the NIC.)
(2) NWG notes will be sent only to Technical Liaison Contacts and to
those on the current mailing list who are not at a site.
(3) RFC numbers and NIC numbers will continue to be assigned by
Jeanne North at SRI -- (415) 326-6200, ext. 4119, or use
Enterprise numbers:
BB&N, CASE, HARV, LINC, MAC, CCA Enterprise 0740
ARPA, MITR Enterprise 1-0740
CMU Enterprise 9074
ILL Enterprise 1074
SDC, RAND, UCLA, UCSB, UTAH Zenith 9-0740
Crocker [Page 1]
RFC 95 Distribution of NWG/RFCs Through the NIC February 1971
(4) NWG notes may be sent to the NIC for distribution, or may be
distributed directly. If an author intends to distribute an NWG
note himself, he should so inform Mrs. North and obtain any
changes to the mailing list. All mailing should be airmail or
first class, depending upon distance.
Those on the current mailing list who are not at sites are
Alfred Cocanower MERIT
MERIT Computer Network (313) 764-9423
611 Church Street
Ann Arbor, Michigan 48104
Douglas McKay IBM
IBM Watson Research Center (914) 945-1159
P. O. Box 218
Yorktown Heights, New York 10598
Thomas O'Sullivan Raytheon
Raytheon Data Systems (617) 762-6700
1415 Boston-Providence Turnpike ext. 2120
Norwood, Mass. 02062
Technical Liaison Contacts
John T. Melvin SRI-ARC
Stanford Research Institute (415) 326-6200
Augmentation Research Center ext. 4328
333 Ravenswood Avenue
Menlo Park, Calif. 94025
Dr. Lawrence G. Roberts ARPA
Advanced Research Projects Agency (202) 694-5921
1400 Wilson Boulevard (202) 694-5922
Arlington, Virginia 22209
Robert Kahn BBN
Bolt Beranek and Newman Inc. (617) 491-1850
50 Moulton Street ext. 421
Cambridge, Mass. 02138
Dan Murphy BBN
Bolt Beranek and Newman Inc. (617) 491-1850
50 Moulton Street ext. 351
Cambridge, Mass. 02138
Crocker [Page 2]
RFC 95 Distribution of NWG/RFCs Through the NIC February 1971
John Barden CASE
Case Western Reserve University (216) 368-4467
Computing and Information Sciences
Room 222, Crawford Hall
10900 Euclid Avenue
Cleveland, Ohio 44106
Harold R. Van Zoeren CMU
Carnegie-Mellon University (412) 683-7000
|
| 回复
|
|
| 10楼 |
2004-10-17 11:24:00 |
|
积分：0分
|
is in accordance with an anticipated change to the ASCII
standard.
Currently the ASCII standard permits two methods of ending a
line. One method defines a single character, line feed (012), as
incorporating the combined functions of line space and carriage return
to the lefthand margin. The second method, implicitly permitted by
ASCII, uses the two character sequence line feed (012) and carriage
return (015) to perform the same function.
There is a proposal that the ASCII standard be changed to
include a return to the left-hand margin in all vertical motion
characters of at least one full space (line feed, vertical tab and new
page). This will disallow the dual character sequence to end a line.
It is suggested that a character in a hostst character set not
having any ASCII equivalnet be represented by the ASCII two character
sequence ESC (033) and one of the ASCII characters. Each host should
publish a list of the escape sequence it has defined.
[Page 8]
RFC 98 Logger Protcol Proposal Feb 1971
Transaction Block Format
All textual messages exchanged between user and logger are to
consist of one or more "transaction blocks". Each transaction block is a
sequence of 8-bit elements in the following format:
<code> <count> <char1> ... <charn>
<code> is an 8-bit element that is not interpreted in this
protocol. In the proposed general console communications
protocol, this field specifies communication modes or
special characteristics of this transaction block. Here
<code> is to be zero.
<count> is an 8-bit element that specifies the number of character
elements that follow in this transaction block. It is
interpreted as a binary integer which has a permissible
range between 0 and 127. The most significant bit is zero.
<chari> is an 8-bit element containing a standard 7-bit ASCII
character right-adjusted. The most significant bit is
zero. The number of <chari> in the transaction block is
governed by the <count> field. A maximum of 127 and
minimum of zero characters are permitted in a single
transaction block.
The most significant bit of each of these elements is zero,
effectively limiting each of these elements to seven bits of
significance. The reason for doing this is twofold: the eighth bit of
the <chari> elements is specifically reserved for future expansion, and
it was desired to limit all the elements so as to permit certain
implementations to convert the incoming stream from 8-bit elements to
7-bit elements prior to decoding.
With one exception, there is to be no semantic connotation
attached with the division of a logger-user message into one or more
transaction blocks. The character string comprising the message to be
transmitted may be divided and apportioned among multiple transaction
blocks according to the whim of the sending host. If less than 128
characters in length, the message may be sent as a single transaction
block. The exception is that separate messages may not appear in the
same transaction block. That is, a message must start at the beginning
of a transaction block and finish at the end of one. Note also that
there is no syntactic device for specifying the last transaction block
of a message. It is presumed that the logger end user both have
sufficient knowledge of the format to know when all of a message has
arrived
[Page 9]
RFC 98 Logger Protcol Proposal Feb 1971
Note that the first 8-bits of data transmitted through a newly
established connection must be a type code as specified in Protocol
Document 1. This type code must be sent prior to the first transaction
block and should be discarded by the receiving host.
Acknowledgments
Robert Bressler, Allen Brown, Robert Metcalfe, and Michael
Padlipsky contributed directly to the establishment of the ideas
presented here. Thanks are due |
| 回复
|
|
| 11楼 |
2004-10-17 11:24:00 |
|
积分：0分
|
operation in which
all typed material is directed by the computer. A key struck by
a user does not print directly. Rather the code is sent to the
computer, which "echoes" it back to be printed on the typewriter.
To reduce complexity, there is to be no option for network
echoplexing (for the login only). A using system having its
typewriters operating in echoplex mode must generate a local
echo to its typewriters. However, a serving system operating
echoplexed should suppress the echo of the input during the login
phase.
2. Correction of Mistakes. During the login dialog the user may make
a typing mistake. There is no mistake correction ecplicitly
proposed here. If the message in error has not yet been
transmitted, the user can utilize the input editing conventions
of either the using or the serving host. In the first case, the
message is corrected before transmission; in the second, it is
corrected at the serving host. If the user has made an
uncorrectlable mistake, he should abort the login and try again.
To abort, he instructs the local (using) host to "close" one of
the connections. The connections are disconnected as specified in
the Initial Connection Protocol.
3. "Waiting". It may happen that the user may get into a login dialog
but for some reason does not complete it. The logger is left
waiting for a response by the user. The logger should not wait
indefinitely but after a reasonable interval (perhaps a minute)
abort the login and "close" the connections according to the
provisions of the Initial Connection Protocol.
4. Socket Assignments. The Initial Connection Protocol does not
specify the ownership of the sockets to be used by the logger in
connecting to the user. (The use code field of the socket
identifier determines ownership.) The sockets may belong to the
logger or may have an arbitraryuser code not used by another
process currently existing at the serving host. Under this initial
[Page 5]
RFC 98 Logger Protcol Proposal Feb 1971
scheme, it is not possible to implement administratively assigned
user codes, because the logger must assign permanent sockets
before the identity of the user is verified. A future connection
protocol can avoid this problem by implementing a socket
connection as a part of the admission phase. The logger would talk
to the user over the logger's sockets. Following identification it
would transfer the connections to the sockets belonging to the
user.
5. General Console Communications. A companion paper under
preparation outlines a protocol for general console communcations
between hosts. This paper will seek to adress most of the
problems associated with typewriter like communications. This
includes discussion of full and half duplex, character escapes,
action characters and other pertinent topics. Such a protocol
might not be suitable for all terminals and host systems but
would include solutions to problems for many. It is not
intended as a monolithic standard, but rather as a recommendation
for those sites who wish to implement a common protocol. The
important point is that we feel quite a bit of actual network
usage is required before all the problems are better understood.
This is a prerequisite for devising a standard.
SPECIFICATIONS
Initial Connection Protocol - Connection Phase
The following sequence is as presented in RFC 80. It is restated
here for completeness.
1. To intiate contact , the using process requests a connection of
his receive socket (US) to a socket (SERV) in the serving host.
By convention, this socket has the 24-bit user number field set
to zero. The 8-bit tag or AEN field is set to one indicating
the socket gender to be that of a sending socket. There is no
restriction on the choice of the socket US other than it be of
of the proper gender; in this case a receive socket. As a result
the using NCP sends:
User -> Server
8 32 32 8
+-----+------------+------------+-----+
| RTS | US | SERV | P |
+-----+------------+------------+-----+
[Page 6]
RFC 98 Logger Protcol Proposal Feb 1971
over the control link one, where P is the receive link assigned
by the user's NCP.
2. The serving host now has the option of accepting the request for
connection or closing the the connection.
a. If he sends a close it is understood by the user that the
foreign host is unable to satisfy a request for service at
this time. The serving host's NCP would send:
Server -> User
8 32 32
+-----+-----------+------------+
| CLS | SERV | US |
+-----+-----------+------------+
with the user's NCP sending the echoing close:
User -> Server
8 32 32
+-----+-----------+------------+
| CLS | US | SERV |
+-----+-----------+------------+
b. If the serving host is willing to provide service it will
accept the connection and immediately close the connection.
This results in the the serving host's NCP sending:
Server -> User
8 32 32
+-----+-----------+------------+
| STR | SERV | US |
+-----+-----------+------------+
8 32 32
+-----+-----------+------------+
| CLS | SERV | US |
+-----+-----------+------------+
[Page 7]
RFC 98 Logger Protcol Proposal Feb 1971
with the user's NCP sending the echoing close. It sends:
User -> Server
8 32 32
+-----+-----------+------------+
| CLS | US | SERV |
+-----+-----------+------------+
It should be mentioned that the echoing closes are required
by the host-to-host protocol and not by the logger initial
connection protocol.
Character Set
The character set used in conducting the login dialog is
standard ASCII as documented in "American National Standard Code for
Information Interchange", ANS X3, 4-1968, American National Standard
Institute, October, 1968. A logger at a serving host may demand any kind
of input that can be expressed as a string of one or more ASCII
characters. It similarly, it may output any such string.
All ASCII characters are legal, including the graphics and
control characters. However, it is proposed that the only standard way
of indicating the end of a console line be the line feed character
(012). This |
| 回复
|
|
| 12楼 |
2004-10-17 11:24:00 |
|
积分：0分
|
this switching may be totally conceptual; in others there
may be a real internal switching between entities.
The Connection Phase
The issues involved in specifying a protocol for implementing
login can be separatedintop two major parts: how to establish and
maintain the network connection between the typewriter and the logger,
and how to conduct a dialog after the connection is made. The first part
is called the Initial Connection Protocol by Harlem and Heafner in RFC
80. It in turn consists of two subparts: how to establish a connection
and how and when to destroy it.
We endorse the proposal for establishing a connection made in
RFC 80, which we summarize briefly for convenience. It is a two-step
process utilizing the NCP control messages to &n | |
