| 楼主 |
2004-10-19 15:42:00 |
积分：0分
|
Network Working Group
Request for Comments: 31
BINARY MESSAGE FORMS IN COMPUTER NETWORKS
Daniel Bobrow
Bolt, Beranek, and Newman
Cambridge, Massachusetts
William R. Sutherland
MIT Lincoln Laboratory
Lexington, Massachusetts
February 1968
[Page 1]
RFC 31 Binary Message Forms February 1968
MESSAGE FORMS IN COMPUTER NETWORKS
INTRODUCTION
Network communication between computers is becoming increasingly
important. However, the variety of installations working in the area
probably precludes standardization of the content and form of inter-
computer messages. There is some hope, however, that a standard way
of defining and describing message forms can be developed and used to
facilitate communication between computers. Just as ALGOL serves as
a standard vehicle for describing numerous algorithms, and BNF serves
as a standard for describing language syntax, a message description
language would be useful as a standard vehicle for defining message
formats.
Considerable progress has been made at the low level of message
handling protocol and one can expect the ASCII protocols to be used.
The discussion which follows assumes that the mechanics of exchanging
messages, check sums, repeat requests, etc., have been worked out.
The topic of concern is how to describe the content and intent of a
binary message body when the network header and trailer details have
been stripped off.
Most attempts at describing the content of binary messages
jump immediately into a consideration of the bit codings to be used.
Long, thin rectangles are drawn to represent the binary bit stream;
this stream is sliced up into boxes, and tables generally describe
the bit options for each box. A better approach would be to provide
a symbolic method for describing messages. The symbolism, by
avoiding immediate references to specific bit details, should help
one's understanding of the message content and the alternatives
available in the message body. When the basic form of the binary
message body is clear, the coding details of the actual bit fields
can be shown.
[Page 2]
RFC 31 Binary Message Forms February 1968
Describing a binary message body is not much different from
describing a text body or language. Text assumes fixed bit fields
each containing one character. Standard language description methods
(BNF) then show how the characters can be concatenated and what
interpretation should be placed on character groups. Binary message
descriptions require the additional capacity of defining various size
fields in the message and the interpretation to be placed on the bits
contained in the field.
A message description is initially intended as a reference standard
to be written down on paper and made available to new users of a
computer network. From this standard, the new user can discover the
kind and form of the binary data being exchanged over the network.
Once this is known, the programs necessary for using the network
facilities can be created. Later on, in an established network, one
can envision the promulgation of standards for newly developed binary
formats via the exchange of ASCII text messages over the network
itself instead of on paper through the mail. Still farther into the
future, the text of a binary format standard could be used as input
to compiler-like programs which automatically create data translation
programs for converting one binary format to another. Right now,
though, some kind of binary data description method, however trivial,
is desperately needed.
[Page 3]
RFC 31 Binary Message Forms February 1968
A SUGGESTED BINARY FORMAT DESCRIPTION METHOD
The basic component of a binary message is a simple field
consisting of a consecutive number of bits in the message. Binary
messages consist of concatenated fields. A format description for a
binary message will consist of a title and four declarative sections.
1) Symbolic names are declared for all the different kinds of
fields found in the binary format being defined.
2) Symbolic names are declared for commonly used values of
particular fields.
3) The legal ways of concatenating fields are indicated.
|
 回复
|
|
| 1楼 |
2004-10-15 19:06:00 |
|
积分：0分
|
Network Working Group Bill English SRI/ARC
Request for Comments No. 34 26 February 1970
SOME BRIEF PRELIMINARY NOTES ON THE ARC CLOCK
The ARC clock system provides a time reference that is written into the
core memory of the XDS 940 Computer. There are two types of time
information available--absolute and relative.
The absolute time is written into two adjacent words of core with the
following format:
First word --
Bits 0 thru 7 contain the month code in straight binary with a
range of 1 to 12
Bits 8 thru 15 contain the day code in straight binary with a
range of 1 to 31
Bits 16 thru 23 contain the year code in straight binary with
range of 0 to 99
Second word --
Bits 00 thru 7 contain the hour code written in straight binary
with a range of 0 to 23
Bits 8 thru 15 contain the minute code written in straight binary
with a range of 0 to 60
Bits 16 thru 23 contain the second code written in straight binary
with range ofr 0 to 60
These 2 words are written once each second. It is anticipated that the
accuracy of the initial setting will be on the order of 1 second, as
referred to WWV, and that the oscillator drift rate will not account for
an accumlated error of more than 1 second every 250 days. The
oscillator and clock are provided with standby power in order to
maintain the accuracy of the system. Because of variable delays in time
required to obtain access to the 940 core memory, it is anticipated that
the short-term accuracy will be on the order of 10 to 20 microseconds.
The relative time, which is written into one word of core memory, is
simply the contents of a 24 bit binary accumulator. The rate at which
the accumulator is updated can be chosen to be either once very 100
micro seconds or once every millisecond. In either case the core
[Page 1]
RFC 34 Prelimary Notes on the ARC Clock February 1970
location is written each time the accumulator is updated. As above the
short-term accuracy will be about 10 to 20 microseconds and the long-
term accuracy will be the equivalent of one second every 250 days.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Katsunori Tanaka 1/98 ]
[Page 2]
|
| 回复
|
|
| 2楼 |
2004-10-15 19:06:00 |
|
积分：0分
|
Network Working Group Jerry Cole, UCLA
Request for Comments: 32 February 5, 1970
SOME THOUGHTS ON SRI'S PROPOSED REAL TIME CLOCK
Re: NWG/RFC's #28 and 29.
The addition of a clock in one or more of the network HOST's seems to be
very desireable since it (or they) would allow user-oriented message
delay measurements. Our present network measurement facilities do not
include any internal HOST delays, and these delays may be an appreciable
portion of the total delay encountered by a HOST-to-HOST message
transmission. We may find that an extension of our "Trace" capabilities
to include internal HOST delays would be an appropriate mechanism for
utilizing such a clock. Such usage would require a clock at both the
source and the destination of the message, although such clocks would
not have to be particularly accurate nor synchronized. Other tests,
such as the absolute overall message delay from HOST A to HOST B would
require synchronization of the two clocks.
A reasonable specification for the SRI real-time clock would seem to
include a resolution of about 1 msec., an accuracy of about 1 part in
10E7 (so that two such clocks could maintain reasonable relative
accuracies over periods of many hours), and a range of about 24 hours.
A crystal controlled clock should easily meet these requirements at a
moderate cost.
The choice of the mechanism by which the HOST can read the clock appears
to be of concern also. The 1 msec. resolution may require that the
clock be entirely hardware (as opposed to a core location which would be
incremented at each clock pulse), and therefore the clock may require
some rather compli- cated interface circuitry.
At UCLA, we presently have two clocks on the Sigma 7, and one of these
has a resolution of about 2 msec. which might be usable for some
internal HOST measurements. However, it does not have the long term
accuracy for the absolute measurements mentioned above.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Richard Ames 1/98 ]
[Page 1]
|
| 回复
|
|
| 3楼 |
2004-10-15 19:06:00 |
|
积分：0分
|
4) The number of bits in each field and any special considerations
of bit codings are declared.
The following is a complete example of a binary message description
for a trivial kind of pictorial data.
Title: Illustrative graphic data format for a hierarchally
structured picture of lines and points.
Simple Fields:
OPT - Option Control Field
COORD - Numerical Coordinate Value
ID - Identnumber for group of picture parts
COUNT - Number of units in message
Field Equivalents:
PHDR <- '2' OPT
LHDR <- '4' OPT
GRPHDR <- '1' OPT
GRPEND <- '3' OPT
[Page 4]
RFC 31 Binary Message Forms February 1968
Characterizations:
CPAIR <- COORD = 2
POINT <- PHDR + CPAIR
LINE <- LHDR + CPAIR = 2
PARTS <- POINT/LINE/PARTS + PARTS
PIXUNIT <- GRPHDR + ID + PARTS + GRPEND
PIXMSG <- '5' OPT + N: COUNT + PIXUNIT = N + '0' OPT
Simple Field Sizes:
OPT 3
COORD 14
ID 9
COUNT 6
Declaration of Simple Fields
The declaration of a simple field includes a symbolic
name, and for lack of a better way, an English description of what
the contents of the field represent. For example:
Simple Fields:
F1 - Geometric Options
EXP - STD Number - Exponent
COORD - STD Number - Geometric Coordinates
Representing Field Values
A field with a specific value can be represented by a number in
single quotes followed by the field name. A number consists of
standard digits construed as binary if zeros and ones. Other numbers
must be followed by a base indicator unless no confusion is possible;
Q is octal, D is decimal.
Example:
'1001' F1
'300D' COORD
'27Q' EXP
Field values are integer numbers assigned such that the least
significant bit is sent first. Only that part of the number which
fits the field is used. Appropriate sign extension is needed for
negative numbers and for numbers whose bit representation is smaller
than the field.
[Page 5]
RFC 31 Binary Message Forms February 1968
Simple Field Equivalents
The declaration of a Simple Field Equivalent provides a symbolic
name which represents a particular field with a specific value.
Example:
Field Equivalents:
C1 <- '1001' F1
C2 <- '1010' F1
Characterization Statement
A characterization statement defines a complex field (message or
message part) by indicating how other fields can be combined and is
similar to a definition statement in BNF. The left side is a complex
field name separated (by <-) from the concatenation indications on
the right. Field names or equivalent names are concatenated by plus
(+), alternatives indicated by slash (/). Slash has precedence over
plus so that A + B/C means A followed by either B or C. Alternatives
must be distinguishable in their own right.
Characterization statement parts can be grouped in the normal
manner by parentheses. (A + B)/C means either A followed by B or C.
Repetition Indicators
Repeated occurrences of a field may be indicated by following the
field name with an equal sign (=) and a number. For example:
CPAIR <- (COORD = 2) i.e. exactly two COORD fields
PPAIRS <- (C1 + CPAIR = 10D) / (C2 + CPAIR = 40D)
Assignments Within a Characterization Statement
Simple fields interpretable as integers can be assigned to a
variable within the right side of a characterization statement. This
variable can then be used as a repetition indicator. Example:
MS <- N1: EXP + CPAIR = N1
indicates that MS consists of field EXP interpreted as an integer and
then exactly that number of CPAIRS. All variables are global in
scope.
Conditional Fields
Within a characterization statement a field may or may not
occur depending on the contents of some other previous field. This
situation is indicated by assigning a label to the determining field.
The conditional occurrence is then indicated by enclosing a condition
expression and the optional field description in brackets ([ and ]).
For example:
[Page 6]
RFC 31 Binary Message Forms February 1968
SS <- V:F1 + CPAIR + [V = C1 > PPAIRS]
which defines a format of 2 and perhaps 3 fields.
a) Field F1 labeled V followed by
b) Field CPAIR followed by
c) Field PPAIRS if the first field (V) was C1; otherwise, this
third field is not present in the message.
Conditional Alternatives
Alternatives selected by the contents of some previous field rather
than by the contents of the alternative field itself are indicated by
an extension of the conditional field notation. For example:
SM := W : F1 + CPAIR + [W = C1 > CPAIR / C2 > PPAIRS /
The determining field occurs at the beginning of the conditional
alternative and each alternative then includes its value for the
determining field and the alternative field then present.
Size of Simple Fields
A separate field size declaration is provided.
Simple Field Sizes:
F1 4
EXP 7
COORD 12
This size declaration should appear at the end of the
message description; thus, forcing the reader to postpone an early
consideration of bit details. xmodmap -e "add lock = Caps_Lock"
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Dave Bachmann 1/98 ]
[Page 7]
|
| 回复
|
|
| 4楼 |
2004-10-15 19:07:00 |
|
积分：0分
|
Crocker [Page 4]
RFC 36 Protocol Notes March 1970
III Control Commands
----------------
Command Summary
0 <NOP>
1 <RFC> <me> <you> or <RFC> <me> <you> <link>
2 <CLS> <me> <you>
3 <RSM> <link>
4 <SPD> <link>
5 <FND> <me> <you> <asker>
6 <END> <link> <end>
7 <RDY> <link>
8 <ASG> <me> <you> <link>
Commands
No Operation
Form: NOP
NOP is X'00'
Purpose: This command is included for completeness and
convenience.
Request for connection
Form: <RFC> <my socket> <your socket>
or <RFC> <my socket> <your socket> <link>
<RFC> is X'01'
<my socket> is a 32 bit socket number local to the
sender
<your socket> is a 32 bit socket number local to the
receiver
<link> is an eight bit link number.
<my socket> and your socket must be a send/receive pair.
<link> is included if and only if <my socket> is a
receive socket
Purpose: This command is used to initiate a connection. When
two hosts have exchanged RFC commands with the same
arguments (reversed), the connection is established.
Links are assigned by the receiver.
Crocker [Page 5]
RFC 36 Protocol Notes March 1970
Close
Form: <CLS> <my socket> <your socket>
<CLS> is X'02'
<my socket> and <your socket> are the same as for <RFC>
Purpose: This command is used to block a connection. It may
also be used to abort the establishment of a connection
or to refuse a request. It may happen that no
connection between the named sockets was established,
or was in the process of being established. In this
event, the <CLS> should be discarded.
Resume
Form: <RSM> <link>
<RSM> is X'03'
Purpose: This command is sent by a receiving host to cause the
sending host to resume transmission on the named link.
A sending host suspends sending if it receives a
special RFNM for some message. (Special RFNM's are
generated by the receiving IMP upon request by its
host.)
Suspended
Form: <SPD> <link>
<SPD> is X'04'
Purpose: This command is sent by a sending host to acknowledge
that it has stopped sending over the named link.
Transmission will resume if a <RSM> command is
received.
Final End
Form: <FND> <my socket> <your socket> <asker>
<FND> is X'05'
<my socket> is a 32 bit socket number of a socket local
to the sender
<your socket> is a 32 bit socket number of a socket
local to the receiver
<my socket> and <your socket> form a send/receive pair.
A connection should be established between them.
<asker> is a 40 bit socket number of the same type as
<my socket>
Crocker [Page 6]
RFC 36 Protocol Notes March 1970
Purpose: If a process decides to short-circuit itself by connecting
one of its receive sockets to one of its send sockets, the
NCP sends out two <FND> commands -- one in each direction.
Each one has <asker> initialized to <my socket>.
Upon receiving an <FND> command, the NCP checks its <your
socket>. If <your socket> is already engaged in a
reconnection, the command is passed on with a new <my
socket> and <your socket>. However, before it is passed
on, the <asker> is compared with the new <my socket>. If
they are equal, a loop has been detected and both sockets
are closed.
If <your socket> is not engaged in a reconnection, it is
marked as the end of a chain of reconnections and an <END>
is sent back.
If the connection named is not in progress, a <CLS> is sent
back and the <FND> is discarded.
End Found
Form: <END> <link> <end socket>
<END> is X'06'
<link> is an 8 bit link
<end socket> is a 40 bit socket
Purpose: This command indicates which socket is at the end of a
chain of reconnections. It is generated at <end
socket> and passed back to the other terminal socket
via all the intermediate sockets. If <end socket> is a
send socket, <link> refers to a connection with the
send socket in the sending host and the receive socket
in the receiving host. If <end socket> is a receive
socket, <link> refers to a connection with the send
socket in the receiving host and the receive socket in
the sending hose. ("sending" end "receiving" refer to
the transmission of this control command.)
Crocker [Page 7]
RFC 36 Protocol Notes March 1970
Ready
Form: <RDY> <link>
<RDY> is X'07'
<link> is an 8 bit link number
Purpose: This command is sent from a send socket to a receive
socket to indicate that all messages have been
forwarded and that reconnection may occur.
Assign New Link
Form: <ASG> <my socket> <your socket> <link>
<ASG> is X'08'
Purpose: This command completes a reconnection. It is sent from
a receive socket to a send socket after the receive
socket has received a <RDY>. A new link is assigned
and transmission commences.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Marc Blanchett 3/00 ]
Crocker [Page 8]
|
| 回复
|
|
| 5楼 |
2004-10-15 19:07:00 |
|
积分：0分
|
Network Working Group S. Crocker
Request for Comments: 36 16 March 1970
Protocol Notes
I Overview
--------
The network protocol provides three facilities:
1. Connection establishment
2. Flow control
3. Reconnection
Reconnection is considered separately from connection establishment
partly because of the complexity of reconnection and partly because I
don't have enough experience with the protocol to present these
concepts in an integrated fashion.
Connection Establishment
------------------------
Connection establishment works essentially the same as in NWG/RFC
#33. The major change is that a more general form of switching is
provided independently of establishment, so establishment is
simplified by not including switching procedures.
A rough scenario for connection establishment follows:
1. Process PA in host A grabs socket SA and requests connection with
socket SB. Process PA accomplishes this through a system call.
2. Concurrently with the above, process PB in host B grabs socket SB
and requests connection with socket SA.
3. In response to process PA's request, the network control program
in host A (referred to as NCPA) sends a Request-for-Connection
(RFC) command to host B. NCPB in host B sends a similar command
to host A. No ordering is implied: NCPB may send the command to
NCPA before or after receiving the command from NCPA.
4. NCPA and NCPB are both aware the connection is established when
each has received a RFC command and each has received the RFNM
for the one it has sent. They then notify processes PA and PB,
respectively, that the connection is established.
Crocker [Page 1]
RFC 36 Protocol Notes March 1970
One of the rules adhered to is that either SA is a send socket and SB
is a receive socket or vice versa. This condition is sometimes
stated as "SA and SB must be a send/receive pair."
5. The sending process may now send.
Flow Control
------------
In order to prevent a sending process from flooding a receiving
processes it is necessary for the receiving process to be able to
stop the flow(*). Flow control is integrated into the network RFNM
handling. When a receiving host wishes to inhibit flow on a
particular link, the host sends a special message to its IMP which
causes the next RFNM on that link to be modified. The sending host
interprets this message as a RFNM and as a request to stop sending.
A confirming control command is returned.
When the receiving host is ready to receive again, it sends a command
(RSM) telling the sending host to resume sending.
Reconnection
------------
For a great many reasons it is desirable to be able to switch one (or
both) ends of a connection from one socket to another. Depending
upon the restrictions placed upon the switching process, it may be
easy or hard to implement. To achieve maximum generality, I present
here a scheme for dynamic reconnection, which means that reconnection
can take place even after flow has started. It may turn out that for
the majority of cases, this scheme is much more expensive than it
needs to be; however, the following virtues are claimed:
1. All various forms of switching connections are provided.
2. Reconnection introduces no overhead in the processing of
messages sent over a connection i.e., the whole cost is borne
in processing the protocol.
---------------------------------------------------
*BB&N argues that unlimited buffering should be provided. It is
possible that this would be a proper strategy: but it is foreign to
my way of thinking, and I have based the protocol design on the
assumption that only a small buffer is provided on the receive end of
each connection.
Crocker [Page 2]
RFC 36 Protocol Notes March 1970
II Data Structures
---------------
1. Connection Table
2. Process Table
3. Input Link Table
4. Output Link Table
5. Link Assignment Table
Connection Table
----------------
This holds all information pertaining to local sockets, particularly
whether a socket is engaged in a connection, and if so, what state
the connection is in. Entries are keyed by local socket, but other
tables have pointers into this table also. (See the Process Table,
Input Link Table, and Output Link Table.)
Each entry contains the following information:
a) local socket (key)
b) foreign socket
c) link
d) connection state
e) flow state and buffer control
f) pointer to user's process
g) reconnection control state
h) queue of waiting callers
The local socket is a 32 bit number. If no entry exists for a
particular socket, it may be created with null values.
The foreign socket is a 40 bit number. This field will be unassigned
if no connection is established.
The link is an 8 bit number and is the link over which data is sent
from the sender to the receiver. A socket is a receive socket iff
its low-order bit is zero.
Connection state refers to whether a connection is open or not, etc.
The following possibilities may occur.
a) local process has requested a connection
b) foreign process(es) has/have requested a connection
c) connection established
d) reconnection in progress
e) close waiting
f) reconnection waiting
Crocker [Page 3]
RFC 36 Protocol Notes March 1970
Flow state and buffer control refer to checking for RFNM's sending
and accepting cease, suspend and resume commands, and keeping track
of incoming or outgoing data.
A pointer to the user's process is necessary if the process has
requested a connection.
If reconnection is in progress, it is necessary to keep track of the
sequence of events. A socket engaged in reconnection is either an
end or a middle. If it's a middle, it is necessary to store the
eight bit name of the other middle attached to the same process, and
to record receipt of END and RDY commands.
Finally, if RFC's are received either when the socket is busy or when
no process has engaged it, the RFC's are stacked first-in-first-out
on a queue for the named local socket.
Process Table
-------------
This table associates a process with a socket. It is used to process
system calls.
Input Link Table
----------------
This table associates receive links with local sockets. It is used
to decide for whom incoming messages are destined.
Output Link Table
-----------------
This table associates send links with local sockets. It is used to
interpret RFNM's and RSM commands.
Link Assignment Table
---------------------
Links are assigned by receivers. This table shows which links are
free.
|
| 回复
|
|
| 6楼 |
2004-10-15 19:07:00 |
|
积分：0分
|
Network Working Group S. Crocker
Request for Comments: 35 UCLA
Category: Informational 3 March 1970
Network Meeting
I expect to have the details of the new network protocol as
outlined in NWG/RFC #33 ready in two weeks. Some interest has been
expressed in a live presentation, so we will host a network meeting on
Tuesday, March 17, at UCLA at 9:00 a.m. To facilitate interaction,
please limit attendance to one programmer from each site. It is also
wise to leave the 18th open in case discussion continues.
The subject of the meeting will be a detailed presentation of the
network protocol, suitable for implementing unless major flaws are
discovered. Documentation will be available at the meeting and if not
obsoleted by the meeting, will be sent out as NWG/RFC on March 20.
Please call Mrs. Charlotte LaRoche at (213) 825-2543 if you need
help in making arrangements.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Jochen Friedrich 4/97 ]
[Page 1]
|
| 回复
|
|
| 7楼 |
2004-10-15 19:08:00 |
|
积分：0分
|
Network Working Group E. Harslem
Request for Comments: 40 J. Heafner
RAND
March 1970
More Comments on the Forthcoming Protocol
We have recently discussed NWG/RFC Nos. 36 and 39 with Steve Crocker,
UCLA. Steve has asked that we elaborate on the errors, queries, and
HOST status that were mentioned in NWG/RFC #39.
Please voice your opinions soon in order to affect the forthcoming
protocol specifications.
ERROR MESSAGES
<ERR> <Code> <Command length> <Command in error>
<Code> is an eight-bit field that specifies the error type. The
assigned codes are shown below. <Command length> is a 16-bit integer
that indicates the length of the <Command in error> in bits. The
<Command in error> is the spurious command.
The ranges of <Code> are shown below in hexidecimal.
00 Unspecified error types
10-0F Resource errors
10-1F Status errors
20-2F Content errors
30-3F Unused
Specific values of <Code> are shown below with their meaning.
<Code> value Semantics
00 Unspecified errors.
01 Request for an invalid resource.
02 Request for an exhausted resource, try later.
03-0F Unused.
10 Invalid <RSM>, i.e., link connected but unblocked.
11 Invalid <SPD>.
12 Invalid <ASG>, i.e., connected but no <RDY>
received.
[Page 1]
<Code> value Semantics
13 Message received on blocked link.
14-1F Unused.
20 Unknown command code.
21 Message received on unconnected link.
22 Invalid <RFC>.
23 Invalid <CLS>.
24 Invalid <RSM>, i.e., link not connected.
25 Invalid <FND>.
26 Invalid <END>.
27 Invalid <RDY>.
28 Invalid <ASG>, i.e., not connected.
29-2F Unused.
30-FF Unused.
QUERIES
<QRY> <My Socket>
or <RPY> <Your Socket> <Text>
The <QRY> is the query indicated in NWG/RFC #39 and <RPY> is the reply.
The format of <Text> is shown below; also refer to NWG/RFC #36, p. 3.
<Text>::= <16 bit count of relevant connection table entries>
<relevant connection table entries>
<relevant connection table entries>::=
<relevant connection table entries>
<a relevant connection table entry>
<a relevant connection table entry>
<a relevant connection table entry>::= <local socket> <foreign socket>
<link> <connection state>
<flow state and buffer control>
<reconnection control state>
[Page 2]
HOST STATUS
<NOP>
An NCP may be up, down, pending, etc. When an NCP changes its
state to UP it should send a <NOP> to each remote NCP which
indicates the NCP is available. The sending NCP can then
construct a vector of HOST status from the RFNMs it receives. An
NCP receiving a <NOP> can update the availability of the sending
NCP in its HOST status vector.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Richard Ames 6/97 ]
[Page 3]
|
| 回复
|
|
| 8楼 |
2004-10-15 19:08:00 |
|
积分：0分
|
Network Working Group E. Harslem
Request for Comments: 39 J. Heafner
RAND
25 March 1970
COMMENTS ON PROTOCOL RE: NWG/RFC #36
We offer the following suggestions to be considered as additions to
the April 28th 1970 protocol grammar specifications.
ERROR MESSAGES
<ERR> <Code> <Command in error>
It is desirable to include debugging aids in the initial protocol for
checking out Network Control Programs, etc.
There are three classes of errors--content errors, status errors, and
resource allocation or exhaustion. <Code> specifies the class and the
offending member of the class. The command is returned to the
sending NCP for identification and analysis.
Examples of status errors are: messages sent over blocked links and
attempts to unblock an unblocked link. Examples of content errors
are: an invalid RFC complete; a message sent on a link not connected;
closing of an unconnected link; and an attempt to unblock an
unconnected link. Examples of resource errors are: a request for a
non-existent program and connection table over- flow, etc. Resource
errors should be followed by a <CLS> in response to the <RFC>.
QUERIES
<QRY> <My Socket> < >
or <QRY> <Your Socket> <Text>
Queries provide an extension to the <ERR> facility as well as limited
error recovery, thus avoiding re-initialization of an NCP.
The first command requests the remote NCP to supply the status of all
connections to the user specified by the user number in <My socket>.
The second is the reply; <Text> contains the connection status
information. If an NCP wants the status of all connections to a
remote HOST, the <My Socket> is zero.
Harlsem & Heafner [Page 1]
RFC 39 COMMENTS ON PROTOCOL RE: NWG/RFC #36 March 1970
PROGRAM TERMINATION NOTIFICATION
<TER> <My Socket>
This command supplements rather than replaces <CLS>. It severs all
communication between a program and those programs in a given HOST to
which it is connected. This command performs what would otherwise be
handled by multiple <CLS> commands. <My Socket> contains the sender's
user number.
HOST STATUS
<HCU>
<HGD>
These messages (HOST coming up and HOST voluntarily going down) are
compatible with asynchronous, interrupt-driven programs, as opposed
to the more conventional post/poll method.
TRANSMIT AND BROADCAST
<TRN> <Body>
<BDC> <Body>
Unlike the previous commands, these are not sent over the control
link, but rather over links assigned to user programs. The prefix of
<TRN> or <BDC> indicates, to the receiving NCP, the disposition of
the message body. <TRN> indicates a message to be passed to a single
process. <BDC> specifies to the destination NCP that the message is
to be distributed over all receiving connections linked to the
sender. In response to a system call by the user to an NCP
requesting <BDC>, the NCP generates one <BDC> to each HOST to which
the sender is connected.
RFC AND DYNAMIC RECONNECTION
This protocol is complex; it proliferates control messages; it causes
queues (to become associated with re-entrant procedures) that are
artificially imposed via the protocol (remote AEN assignment); and
discounts the situation where only controlling process "A" has
knowledge that slave process "B" should be "rung out" in a dynamic
reconnection.
The <ERR>, etc., are suggestions for inclusion as additions in the
April 28th protocol specifications. The above criticism is, of
course, not intended to affect modification of the RFC structure by
April 28th, nor to reflect on those who planned it. We have not
studied the problem. It is meant, however, to voice our concern
Harlsem & Heafner [Page 2]
RFC 39 COMMENTS ON PROTOCOL RE: NWG/RFC #36 March 1970
about complexity and resulting response times. This is a difficult
problem and it deserves more study after we have exercised the
current RFC specifications. We hope to offer constructive
suggestions with respect to the RFC in the future.
JFH:hs
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Mario Vitale 08/99 ]
Harlsem & Heafner [Page 3]
|
| 回复
|
|
| 9楼 |
2004-10-15 19:08:00 |
|
积分：0分
|
Network Working Group Stephen M. Wolfe
Request for Comments: 38 UCLA CCN
20 March 1970
Comments on Network Protocol
from NWG/RFC #36
The proposed protocol does not allow for the possible multiplexing of
connections over links.
Generally, this presents no problem, but it might cause loading
restrictions in the future. Two cases where routing multiple
connections over the same link are apparent:
a) Where a user has several high speed connections, such as
between processes that transmit files over the network.
Assigning these connections to the same link limits the
percentage of network resources that may be used by that
user. This becomes particularly important when several
store-and-forward IMP's are used by the network to effect
the communication.
b) When two hosts each have their own independent network and
desire to allow access to the other hosts's network over
the ARPA net, a shortage of links may develop. Again, the
assignment of several connections to the same link could
help solve the problem.
The following changes in the protocol would make possible the future
use of multiplexed links. It is not necessary to add the
multiplexing, itself, to the protocol at this time.
a) The END and RDY must specify relevant sockets in addition to
the link number. Only the local socket name need be
supplied.
b) Problems arise with the RSM and SPD commands. Should they
refer to an entire link, or just to a given connection?
Since there is a proposal to modify the RFNM to accommodate
these commands, it might be better to add another set of
commands to block and unblock a connection, but I am not
convinced that that is the best solution.
c) The destintation socket must be added to the header of each
message on the data link. Presumably this would consist of
32 bits immediately after the header and before the marking.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Karl Reinsch 1/97 ]
[Page 1]
|
| 回复
|
|
| 10楼 |
2004-10-15 19:08:00 |
|
积分：0分
|
Idea 1. To Reconnect.
--------------------
"A NCP wanting to Reconnect tells each of his neighbors "I want to
reconnect". They wait until there are no messages in transit and
respond "OK". He then says "Reconnect as follows" and they do it.
In the Rare condition, the NCP gets back an "I want to reconnect
instead of an "OK", then one must go and one must stop. So treat a
"reconnect" from a higher Host user etc. as an ok and from a lower
as a "No-wait until I reconnect you" and do the connection.
Idea 2
------
"Decouple connections and links. Still establish connections, but
use any handy link for the messages. Don't send another message on
a connection until a FRNM comes back. Include source and
destination socket numbers in the packet.
"To reconnect, say to each of neighbors "please reconnect me as
follows...". Hold onto the connect for a short time (seconds) and
send both packets and connection messages along toward their
destinations. I haven't worked out how to keep the in-transit
messages in order, but probably everything works if you don't send
out a reconnect when RFNM's are pending."
[Page 3]
RFC 37 Network Meeting Epilogue, etc. 20 March 1970
Bill's first idea does not seem to me to be either decisively better
or (after some thought) very different, and I am considering it. I
have no strong feelings about it yet, but I am trying to develop
some.
Bill's second idea seems contrary to my conception of the role of
links. An argument in favor of decoupling connections and links
that the number of connections between two hosts might want to
exceed 255, and that even if not, it is sounder practice to isolate
dependancies in design. On the other hand, the newly provided Cease
on Link facility* (page 22 of the soon to be released BBN report
#1822 revised Febuary 1970) becomes useless. (Bill, who just put
the feature in, doesn't care.) Another objection is that it seems
intuitively bad to waste the possibility of using the link field to
carry information. (Note the conflict of gut level feelings).
In a conversation with John Haefner and Eric Harslem of RAND, the
pointed out that the current protocol makes no provision for error
detection and reporting, status testing and reporting, and expansion
and experimentation. Error detection and status testing will
require some extended discussion to see what is useful, and I expect
that such discussion will take place while implementation proceeds.
Leaving room for protocol expansion and experimentation, however, is
best done now.
I suggest that two areas for expansion be reserved. One is that
only a fraction of the 256 links be used, say the first 32. The
other area is to use command codes from 255 downward, with permanent
codes assigned from the number of links in use to 32, I feel that it
is quite unlikely that we would need more than 32 for quite some
time, and moreover, the network probably wouldn't handle traffic
implied by heavy link assignment. (These two things aren't
necessarily strongly coupled: one can have many links assigned but
only a few carrying traffic at any given time.)
Some of Heafner's and Harslen's other ideas may appear in NWG/RFC
form.
[Page 4]
RFC 37 Network Meeting Epilogue, etc. 20 March 1970
Immediate Interaction
---------------------
During the next several days, I will still be interested in those
editicisms of current protocol which might lead to rejection or
serious modification of it. Thereafter, the focus will be a
refinement, implementation, extension, and utilization. I may be
reached at UCLA through my secretary Mrs. Benita Kristel at (213)
825-2368. Also, everyone is invited to contribuet to the NWG/RFC
series. Unique numbers are assigned by Benita.
* The Cease on Link facility is a way a receiving host modifies
RFNM's so as to carry a flow-quenching meaning. An alternative
proceedure is to use a host-to-host control command.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Ron Fitzherbert 1/97 ]
[Page 5]
|
| 回复
|
|
| 11楼 |
2004-10-15 19:08:00 |
|
积分：0分
|
Network Working Group S. Crocker
Request for Comments: 37 UCLA
20 March 1970
Network Meeting Epilogue, etc.
The Meeting
-----------
On Tuesday, March 17, 1970, I hosted a Network meeting at UCLA.
About 25 people attended, including representatives from MIT, LL,
BBN, Harvard, SRI, Utah, UCSB, SDC, RAND and UCLA. I presented a
modification of the protocol in NWG/RFC #33; the modifications are
sketchily documented in NWG/RFC #36. The main modification is the
facility for dynamic reconnection.
The protocol based on sockets and undistinguished simplex
connections is quite different from the previous protocol as
documented in NWG/RFC #11. The impetus for making such changes came
out of the network meeting on December 8, 1969, at Utah, at which
time the limitations of a log-in requirement and the inability to
connect arbitrary processes was seriously challenged. Accordingly,
the primary reason for the recent meeting was to sample opinion on
the new protocol.
Recollections may vary, but it is my opinion that the protocol was
widely accepted and that the criticism and discussion fell into two
categories:
1. Questioning the complexity and usefulness of the full protocol,
especially the need for dynamic reconnection.
2. Other topics, particularly character set translation, higher
level languages, incompatible equipment, etc.
Notably lacking was any criticism of the basic concepts of sockets
and connections. (Some have since surfaced.) The following
agreements were made:
1. By April 30, I would be responsible for publishing an
implementable specification along lines presented.
2. Any interested party would communicate with me (at least)
immediately if he wished to modify the protocol.
[Page 1]
RFC 37 Network Meeting Epilogue, etc. 20 March 1970
3. If major modifications come under consideration, interested
parties would meet again. This would happen in two to three
weeks.
4. Jim Forgie of Lincoln Labs tentatively agreed to host a meeting
on higher level network languages, probably near Spring Joint
time.
Mailing List Changes
--------------------
Paul Rovner of LL is replaced by
James Forgie
Mass. Institute of Technology
Lincoln Laboratory C158
P.O. Box 73
Lexington, Mass. 02173
telephone at (617) 862-5500 ext. 7173
Professor George MEaly is added
George Mealy
Rm. 220
Aitken Computation Lab.
Harvard University
Cambridge, Massachusetts 02138
telephone at (617) 868-1020 ext. 4355
Process
-------
In all of our writing we have used the term process, to mean a
program which has an assigned location counter and an address space.
A program is merely a pattern of bits stored in some file. A new
process is created only by an already existing process. The
previous process must execute an atomic operation (forc, attach,
etc.) to cause such a creation. Processes may either cause their
own demise or be terminated by another (usually superior) process.
The above definition corresponds to the definition given by
Vyssotsky, et al on pp. 206, 207 of "Structure of the Multics
Supervisor" in the FJCC proceedings, 1965.
[Page 2]
RFC 37 Network Meeting Epilogue, etc. 20 March 1970
Because a process may create another process, and because in general
the two processes are indistinguishable when viewed externally, I
know of no reasonable way for two processes to request connection
directly with each other. The function of sockets is to provide a
standard interface between processes.
The Days After
--------------
In the time since the meeting I have had conversations with Steve
Wolfe (UCLA-CCN), Bill Crowther (BBN), and John Heafner and Erick
Harslem (RAND). Wolf's comments will appear as NWG/RFC #38 and fall
into a class I will comment on below.
Crowther submitted the following:
"A brief description of two ideas for simplifying the host protocol
described at the March meeting. These ideas have not been carefully
worked out.
|
| 回复
|
|
| 12楼 |
2004-10-15 19:09:00 |
|
积分：0分
|
Network Working Group J. Postel
Request for Comments #45 S. Crocker
UCLA
14 April 70
New Protocol is Coming
We are currently preparing a clean version of the Network protocol,
hopefully suitable for immediate implementation. As advertised, we
will send these specs out on April 28.
Since the SJCC is one week later, we will host a discussion meeting in
Atlantic City, Thursday, May 7, win the afternoon. The purpose of the
discussion meeting will be for us to explicate unclear details of our
April 29 document, and for everyone to exchange gripes, suggestions
and schedules.
(Note that the network session, chaired by Larry Roberts with papers
from BBN, et al is Thursday morning.)
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Josh Elliott 1/98 ]
[Page 1]
|
| 回复
|
|
| 13楼 |
2004-10-15 19:09:00 |
|
积分：0分
|
Network Working Group A. G. Nemeth
Request for Comments: 43 M.I.T. Lincoln Laboratory
8 April 1970
Proposed Meeting
On Friday, 8 May 1970, at 9:30 AM a meeting at M.I.T. Lincoln
Laboratory is proposed. A description of LIL (Local Interaction
Language) for the TSP (Terminal Support Processor) system will be
presented.
The purpose of the TSP system is to provide a flexible I/O
capability for network users. In order to achieve maximum flexibility,
the system is user-programmable in an interpretable language called
LIL.
LIL has the appropriate primitives for manipulating tree
structures (for interactive graphics) as well as message-oriented
I/O. The general purpose portion of the language is used to specify
the I/O handlers and the display structures.
A discussion of the problems of handling interactive programs
over the ARPA network will follow.
This conference is intended as a working group and each host
should send as few or as many individuals as are actively
interested. A working document on LIL will be mailed about a week in
advance to interested individuals.
Anyone interested in attending and/or receiving the documents
should contact A. G. Nemeth (x7354) or J. Forgie (x7173) at
M.I.T. Lincoln Labs, Lexington, Mass. 02173, (617) 862-5500.
[This RFC was put into machine readable form for entry into the RFC
archives by Glenn Forbes Fleming Larratt]
December 27, 1996
|
| 回复
|
|
| 14楼 |
2004-10-15 19:09:00 |
|
积分：0分
|
Network Working Group E.I. Ancona
Request for Comments: 42 M.I.T. Lincoln Laboratory
31 March 1970
Message Data Types
Proposal:
We propose that the first eight bits of a normal message be reserved
for a message data type. Adoption of this convention does not in any
way signify agreement as to the actual data types to be used. It
merely establishes the convention that the first eight bits of every
normal message are not available for user data.
Discussion:
Socket Port
| | | ____________
| V V /
V /
|=| /==| |
-------(+)->|Y|-->< | |
|=| \==| |
| PROCESS |
| |
|=| /==| |
-------(-)->|X|<--< | |
|=| \==| |
\ /
\____________/
It is important that conventions regarding the contents of messages
be set up early so that there will not be a large proliferation of
such conventions between every pair of programs running on the
network.
As network usage grows, network languages may develop for specifying
both the syntax and semantics of messages. However, even before such
conventions are developed, a simple way of describing such a
specification is by means of a message type which both sender and
receiver know how to interpret.
It is important that currently running programs still run with this
convention; thus, we propose that two system programs be written
which initially put in and test and remove the type information from
the message. Let us call these two programs X and Y, for lack of
Ancona [Page 1]
RFC 42 Message Data Types March 1970
better names. In general, X and Y will perform transformations on
the data, e.g., change character sets or number formats. As network
usage grows, X and Y might become table driven with the table
specified by the user.
Standard Types and Local Types:
We propose to distinguish between two kinds of message data types:
standard and local.
Since our two transformation programs cannot be expected to perform a
transformation between every possible data representation and the
data representation of the machine they are running on, and also
since the addition of a data representation should not necessarily
involve a change to X or Y, we propose that only a fixed number of
message types have meaning throughout the network. These are
standard types.
There are two classes of local types: MYLOCAL and YOURLOCAL. A
message type MYLOCAL n implies: this is type n of the set of types of
the sending host. YOURLOCAL n implies: this is type n of the set of
types of the receiving host.
Conventions:
A possible implementation of standard and local types is to define
standard type 0 to be YOURLOCAL and standard type 1 to be MYLOCAL. In
these cases, the second byte would be the local type number.
Local type 0 would mean user-specified, i.e., the message contents
are unchanged and unchecked. Installations would define their own
local type numbers and these would normally be available from the
Network Information Center.
Thus initially, all messages sent to currently running programs will
be type 0, n and all messages received from currently running
programs will be type 1, n where n is the local type number of the
character set of the installation.
Examples of Possible Standard Ty | |
