📄 rfc55.txt
字号:
to-Imp transmission out of a resident buffer and wakes up the
output scheduler when transmission is complete.
3. The Input Interpreter
This program decides whether the input is a regular message
intended for a user, a network control message, an Imp-to Host
message, or an error. For each class of message this program
invokes a subroutine to take the appropriate action.
Newkirk, et al. [Page 6]
RFC 55 Prototypical Implementation of NCP June 1970
4. The Output Scheduler
Three classes of messages are sent to the Imp
(a) Host-to-Imp messages
(b) Control messages
(c) Regular messages
We believe that a priority should be imposed among these
classes. The priority we suggest is the ordering above. The
output scheduler selects the highest priority message and
passes it to the output handler.
Host-to-Imp messages are processed first come first served.
Control messages are processed individually by host, each host
being taken in turn. A control message queue for each foreign
host is provided. When any particular host is scheduled for
output, as many control commands for that host as will fit are
concatenated into a single message. Regular messages are
processed in groups by host and link, each unique combination
being taken in turn.
5. The System Call Interpreter
This program interprets requests from the user. Each system
call has a corresponding routine which takes the appropriate
action.
The two interesting components are the input interpreter and the
system call interpreter. These are similar in that the input
interpreter services foreign requests and the system call
interpreter services local requests.
The diagram in Figure 4.1 is our conception of the Network
Control Program. Squishy amoeba-like objects represent component
programs, cylinders represent queues, and the arrows represent
data paths. In this simplified diagram tables are not shown.
["Amoeba-like" objects in original hand drawing are now firm
rectangular boxes: Ed.]
The abbreviated labels in the figure have the following meanings:
HIQ - Host-to-Imp Queue
OCCQ - Output Control Command Queue
DQ - Data Queue
IHBUF - Input Handler Buffer
OHBUF - Output Handler Buffer
Newkirk, et al. [Page 7]
RFC 55 Prototypical Implementation of NCP June 1970
____________
| USER | STRUCTURE OF THE NETWORK CONTROL PROGRAM
|____________|
^ | Fig. 4.1
_____|______V____
| |
| System |
| Call |
| Interpreter |
|_________________| _____________
^ | | | |
| | | +---------------| Input |
| | | | +-----| Interpreter |
| | | | | | |
| V V V V -------------
|======| |=========| |=======| | ^
| D Q | | O C C Q | | H I Q | | |
|======| |=========| |=======| | |
| ^ | | | |
| | | | | |
| +--------)----------)---------+ |
| | | |
+-------+ | +------+ |
__V___V___V__ |
| | |
| Output | |
| Scheduler | |
|_____________| |
| |
V |
(===========) (===========)
( O H B U F ) ( I H B U F )
(===========) (===========)
| ^
______V______ ______|______
| | | |
| Output | | Input |
| Handler | | Handler |
| | | |
------------- -------------
| ^
| |
+----------+ +-----------+
| |
____V____|____
| |
| I M P |
|______________|
Newkirk, et al. [Page 8]
RFC 55 Prototypical Implementation of NCP June 1970
V. Tables in the NCP
We envision that the bulk of the NCP's data base is in associative
tables. By "associative" we mean that there is some lookup routine
which is presented with a key and either returns successfully with a
pointer to the corresponding entry, or fails if no entry corresponds
to the key. The major tables are as follows:
1. The Rendezvous Table
This table holds the attributes of a connection. The table is
accessed by the local socket, but other tables may have
pointers to existing entries.
The components of an entry are:
(a) Local Socket
(b) Foreign Socket
(c) Link
(d) Connection State
(e) Flow State
(f) Data Queue
(g) Call Queue
(h) Port Pointer
(i) Their Buffer Size (only needed on the send side)
(j) Error State
An entry is created when either a CONNECT or a LISTEN system
call is executed or when a request for connection is received.
Various fields remain unused until after the connection is
established.
2. The Input Link Table
The input interpreter uses the concatenation of the foreign
host and link as a key into the input table. The table is used
in processing a user-destined message on an incoming link by
providing a pointer into the rendezvous table.
3. The Output Link Table
The input interpreter uses the output link table to access the
flow state as RFNM's return from transmitted messages. The
output link table is keyed by host and link and provides a
pointer into the rendezvous table.
Newkirk, et al. [Page 9]
RFC 55 Prototypical Implementation of NCP June 1970
4. The Port Table
The system call interpreter uses the concatenation of the
process identification and the port identification as a key to
obtain a pointer into the rendezvous table.
5. The Output Control Command Table
The system call interpreter and the input interpreter use this
table to make entries in the appropriate output control command
queues. Commands are queued in separate table entries
corresponding to foreign hosts. Before output the contents of
the queue are concatenated into a large control message. The
components of an entry are:
(a) Host
(b) Output Control Command Queue
6. The Output Request Queue
This queue contains an entry for each connection which has data
requiring transmission to the net. There is only one entry per
connection, which is deleted when the last packet of data is
transmitted and is entered whenever a user makes a system
request for data transmission.
The entry is re-inserted if transmission is not completed
(message too long) or is prevented by the flow control
mechanism. The only component of an entry is a local socket.
7. The Host Live Table
This is a simple table listing the hosts which are alive. This
table is checked before establishing a connection and before
sending any data to ensure that the destination host actually
exists. At present the protocol does not define the procedure
to be followed for the Host up/Host down conditions. See
NWG/RFC#57.
8. The Link Assignment Table
Link numbers are assigned by the receiver. This table records
which links are free and can, therefore, be assigned.
Newkirk, et al. [Page 10]
RFC 55 Prototypical Implementation of NCP June 1970
VI. Informal Description of Network Operations
We present here narratives describing the operation conducted during
the three major phases of network usage: opening, flow control, and
closing.
A. Opening
In order to establish a connection for data transmission, a pair
of RFC's must be exchanged. An RTS must go from the receive-side
to the send-side, and an STR must be issued by the send-side to
the receive-side. In addition, the receive-side, in its RTS, must
specify a link number. These RFC's (RFC is a generic term
encompassing RTS and STR) may be issued in any time sequence. A
provision must also be made for queuing pending calls (i.e., RFC's
which have not been dealt with by the user program). Thus, when a
user is finished with a connection, he may choose to examine the
next pending call from another process and decide to either accept
or refuse the request for connection. A problem develops because
the user may not choose to examine his pending calls; thus they
will merely serve to occupy queue space in the NCP. Several
alternative solutions to this problem will be mentioned later.
Utilizing the framework of the prototype system calls described
above, we envision at least four temporal sequences for obtaining
a successfully opened connection:
1. The user may issue a LISTEN, indicating he is willing to
consider connecting to anyone who sends him an RFC. When an
RFC comes in the user is notified. The user then decides
whether he wishes to connect to this socket and issues an
ACCEPT or a CLOSE on the basis of that decision. A CLOSE '
refuses' the connection, as discussed under "Closing." An
ACCEPT indicates he is willing to connect; an RFC is issued,
and the connection becomes fully opened.
2. Upon processing a user request for a LISTEN, the NCP
discovers that a pending call exists for that local socket.
The user is immediately notified, and he may ACCEPT or
CLOSE, as above.
3. The user issues a CONNECT, specifying a particular foreign
socket that he would like to connect to. An RFC is issued.
If the foreign process accepts the request, it answers by
returning an RFC. When this acknowledging RFC is received,
the connection is opened.
Newkirk, et al. [Page 11]
RFC 55 Prototypical Implementation of NCP June 1970
4. When presented with a CONNECT, the NCP may discover that a
pending call exists from the specified foreign socket to the
local socket in question. An acknowledging RFC is issued
and the connection is opened.
In all of the above cases the user is notified when the connection
is opened, but data flow cannot begin until buffer space is
allocated and an ALL command is transmitted.
Any of these connection scenarios will be interrupted if a CLS
comes in, as discussed under "Closing."
1. Pending Call Queues
It is essential that some form of queuing for pending RFC's
be implemented. A simple way to see this is to examine a
typical LISTEN-CONNECT sequence. One side issues a LISTEN,
the other a CONNECT. If the LISTEN is issued before the RFC
coming from the remote CONNECT arrives, all is fine.
However, due to the asynchronous nature of the net, we can
never guarantee that this sequence of events will occur. If
calls are not queued, and the RFC comes in before the LISTEN
is issued, it will be refused; if it arrives later, it will
be accepted. Thus we have an extremely ambiguous situation.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -