rfc48.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,012 行 · 第 1/3 页
TXT
1,012 行
RFC 48 A Possible Protocol Plateau April 1970
D. Error Reporting
As mentioned by J. Heafner and E. Harslem of RAND, it is
important to treat errors which might occur. A good philosophy
is to guard against any input which destroys the consistency of
the NCP's data base.
The specific formulation of the error command given by Heafner
and Harslem in NWG/RFC #40 and by Meyer in NWG/RFC #46 seems
reasonable and we recommend its adoption. Some comments are in
order, however.
A distinction should be made between resource errors and other
types of errors. Resource errors are just the detection of
overload conditions. Overload conditions are well-defined and
valid, although perhaps undesirable. Other types of errors
reflect errant software or hardware. We feel that resource
errors should not be handled with error mechanisms, but with
mechanisms specific to the problem. Thus the <CLS> command may
be issued when there is no more room to save waiting <RFC>'s.
Flow control protocol is designed solely to handle buffering
overload.
With respect to true errors, we are not certain what the value
of the <ERR> command is to the recipient. Presumably his NCP
is broken, and it may only aggravate the problem to bombard it
with error commands. We therefore, recommend that error
generation be optional, that all errors be logged locally in a
chronological file and that <ERR> commands received likewise be
logged in a chronological file. No corrective action is
specified at this time.
In the short time the network has been up at UCLA, we have
become convinced that the network itself will generate very few
errors. We have watched the BBN staff debug and test the IMP
program, and it seemed that most of the errors affected timing
and throughput rather than validity. Hence most errors will
probably arise from broken Hosts and/or buggy NCP's.
E. Status Testing and Reporting
A valuable debugging aid is to be able to get information about
what a foreign NCP thinks is happening. A convenient way to do
this is to permit NCP's to send status whenever they wish, but
to always have them do it whenever they receive a request.
Postel & Crocker [Page 7]
RFC 48 A Possible Protocol Plateau April 1970
Since we view this feature as primarily a debugging tool, we
suggest that a distinct link, like 255, be used. The intent is
that processing of status requests and generating of status
messages should use as little of the normal machinery as
possible. Thus we suggest that link 255 be used to send
"request status" and "status is" commands. The form follows
the suggestion on page 2 of NWG/RFC #40.
Meyer's <ECO> command is easily implemented and serves the more
basic function of testing whether a foreign NCP is alive. We
suggest that the length of the <ECO> command be variable, as
there seems to be no significance in this context to 48 bits.
Also, the value of a (presumably) 8 bit binary switch is
unclear, so we recommend a pair of commands:
<ECO> <length> <text>
and
<ERP> <length> <text>
where
<length> is 8 bits.
Upon receipt of an <ECO> command the NCP would echo with the
<ERP> command.
F. Expansion and Experimentation
As Meyer correctly points out in NWG/RFC #46, network protocol
is a layered affair. Three levels are apparent so far.
1. IMP Network Protocol
2. Network Control Program Protocol
3. Special user level or Subsystem Level Protocol
This last level should remain idiosyncratic to each Host (or
even each user). The first level is well-specified by BBN, and
our focus here is on level 2. We would like to keep level 2 as
neutral and simple as possible, and in particular we agree that
login protocol should be as much on level 3 as possible.
Simplicity and foresight notwithstanding, there will arise
occasions when the level 2 protocol should change or be
experimented with. In order to provide for experimentation and
change, we recommend that only link numbers 2 through 31 be
assigned to regular connections, with the remaining link
numbers, 32 to 255, used experimentally. We have already
suggested that link 255 be used for status requests and
replies, and this is in consonance with our view of the
experimental aspects of that feature.
Postel & Crocker [Page 8]
RFC 48 A Possible Protocol Plateau April 1970
We also recommend that control command prefixes from 255
downward be used for experimentation.
These two conventions are sufficient, we feel to permit
convenient experimentation with new protocol among any subset
of the sites. We thus do not favor inclusion of Ancona's
suggestion in NWG/RFC #42 for a message data type code as the
first eight bits of the text of a message.
G. Multiplexing Ports to Sockets
Wolfe in NWG/RFC #38 and Shoshani et al in NWG/RFC #44 suggest
that it should be possible to attach more than one port to a
socket. While all of our diagrams and prototypical system
calls have shown a one-to-one correspondence between sockets
and ports, it is strictly a matter of local implementation. We
note that sockets form a network-wide name space whose sole
purpose is to interface between the idiosyncratic structures
peculiar to each operating system. Our references to ports are
intended to be suggestive only, and should be ignored if no
internal structures corresponds to them. Most systems do have
such structures, however, so we shall continue to use them for
illustration.
H. Echoing, Interrupts and Code Conversion
1. Interrupts
We had been under the impression that all operating systems
scanned for a reserved character from the keyboard to
interpret it as an interrupt signal. Tom Skinner and Ed
Meyer of MIT inform us that model 37 TTY's and IBM 2741
generate a "long space" of 200-500 milliseconds which is
detected by the I/O channel hardware and passed to the
operating system as an interrupt. The "long space" is not a
character -- it has no ASCII code and cannot be program
generated.
Well over a year ago, we considered the problem of
simulating console interrupts and rejected the <INT> type
command because it didn't correctly model any system we
knew. We now reverse our position and recommend the
implementation of an INTERRUPT system call and an <INT>
control command as suggested by Meyer in NWG/RFC #46.
Postel & Crocker [Page 9]
RFC 48 A Possible Protocol Plateau April 1970
Two restrictions of the interrupt facility should be
observed. First, when communicating with systems which scan
for interrupt characters, this feature should not be used.
Second, non-console-like connections probably should not
have interrupts. We recommend that systems follow their own
conventions, and if an <INT> arrives for a connection on
which it shouldn't the <INT> should be discarded and
optionally returned as an error.
2. Echoing and Code Conversion
We believe that each site should continue its current
echoing policy and that code conversion should be done by
the using process. Standardization in this area should
await further development.
Ancona's suggestion of a table-driven front-end transducer
seems like the right thing, but we believe that such
techniques are part of a larger discussion involving
higher-level languages for the network.
I. Broadcast Facilities
Heafner and Harslem suggest in NWG/RFC #39 a broadcast
facility, i.e. <TER> and <BDC>. We do not fully understand the
value of this facility and are thus disposed against it. We
suspect that we would understand its value better if we had
more experience with OS/360. It is probably true in general
that sites running OS/360 or similar systems will find less
relevance in our suggestions for network protocol than sites
running time-sharing systems. We would appreciate any cogent
statement on the relationship between OS/360 and the concepts
and assumptions underlying the network protocol.
J. Instance Numbers
Meyer in NWG/RFC #46 suggests extending a socket to include an
_instance_ code which identifies the process attached to the
socket. We carefully arranged matters so that processes would
be indistinguishable. We did this with the belief that both as
a formal and as a practical matter it is of concern only within
a Host whether a computation is performed by one or many
processes. Thus we believe that all processes within a job
should cooperate in allocating AEN's. If an operating system
has facilities for passing a console from process to process
within a job, these facilities mesh nicely with the current
network protocol, even within reconnection protocol; but
instance numbers interfere with such a procedure.
Postel & Crocker [Page 10]
RFC 48 A Possible Protocol Plateau April 1970
We suggest this matter be discussed fully because it relates to
the basic philosophy of sockets and connections. Presently we
recommend 40 bit socket numbers without instance codes.
K. AEN's
Nobody, including us, is particularly happy with our name AEN
for the low order 8 bits of the socket. We rejected _socket_
number_, and are similarly unhappy with Meyer's _socket_code_.
The word socket should not be used as part of the field name,
and we solicit suggestions.
III. Environment
We assume that the typical host will have a time-sharing operating
system in which the cpu is shared by processes.
Processes
We envision that each process is tagged with a _user_number_. There
may be more than one process with the same user number, and if so,
they should all be cooperating with respect to using the network.
We envision that each process contains a set of _ports_ which are
unique to the process. These ports are used for input to or output
from the process, from or to files, devices or other processes.
We also envision that each process has an event channel over which it
can receive very short messages (several bits). We will use this
mechanism to notify a process that some action external to the
process has occurred.
To engage in network activity, a process _attaches_ a _local_socket_
to one of its ports. Sockets are identified by user number, host and
AEN, and a socket is local to a process if their user numbers match
and they are in the same host. A process need only specify an AEN
when it is referring to a local socket.
Each port has a status which is modified by system calls and by
concurrent events outside the process. Whenever the status of a port
is changed, the process is sent an event over its event channel which
specifies which port's status has changed. The process may then look
at a port's status.
These assumptions are used descriptive material which follows.
However, these assumptions are not imposed by the network protocol
and the implementation suggested by section IV is in no way binding.
Postel & Crocker [Page 11]
RFC 48 A Possible Protocol Plateau April 1970
We wish to make very clear that this material is offered only to
provide clues as to what the implementation difficulties might be and
not to impose any particular discipline.
For example, we treat <RFC>'s which arrive for unattached local
sockets as valid and queue them. If desired, an NCP may reject them,
as Meyer suggests, or it might hold them for awhile and reject them
if they're not soon satisfied. The offered protocol supports all
these options.
Another local option is the one mentioned before of attaching
multiple ports to a socket. We have shown one-one correspondence but
this may be ignored. Similarly, the system calls are merely
suggestive.
System Calls
These are typical system calls which a user process might execute.
We show these only for completeness; each site will undoubtedly
implement whatever equivalent set is convenient.
We use the notation
Syscall ( arg , arg ...; val ... )
1 2 1
where
Syscall is the system call
arg etc. are the parameters supplied with the call, and
1
val etc. are any values returned by the system call.
1
Init (P,AEN,FS,Bsiz;C)
P Specifies a port of the process.
AEN Specifies a local socket. The user number of this
process and host number of this host are implicit.
FS Specifies a socket with any user number in any host,
with any AEN.
Bsiz Specified the amount of storage in bits the user wants
to devote to buffering messages.
C The condition code returned.
Init attempts to attach the local socket specified by AEN to the port
P and to initiate a connection with socket FS. Possible returned
values of C are
Postel & Crocker [Page 12]
RFC 48 A Possible Protocol Plateau April 1970
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?