rfc61.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,012 行 · 第 1/3 页
TXT
1,012 行
RFC 61 Interprocess Communication in a Computer Network July 1970
Still another example, this time a demonstration of the use of the
FORTRAN compiler. We have already explained how a user sits down at
his teletype and gets connected to an executive. We go on from
there. The user is typing in and out of the executive which is doing
SENDs and RECEIVEs. Eventually the user types RUN FORTRAN and the
executive asks the monitor to start up a copy of the FORTRAN compiler
and passes to FORTRAN as start up parameters the two ports the
executive was using to talk to the teletype. FORTRAN is of course
expecting these parameters and does SENDs and RECEIVEs to these ports
to discover what input and output files the user wants to use.
FORTRAN types INPUT FILE? to the user who responds F001. FORTRAN
then sends a message to the file-system-process which is asleep
waiting for something to do. The message is sent via well-known
ports and it asks the file system to open F001 for input. The
message also contains a pair of ports that the file-system-process
can use to send its reply. The file-system looks up F001, opens it
for input, makes some entries in its open file tables, and sends a
message back to FORTRAN which contains the ports which FORTRAN can
use to read the file. The same procedure is followed for the output
file. When the compilation is complete, FORTRAN returns the teletype
port numbers back to the executive which has been asleep waiting for
a message from FORTRAN, and then FORTRAN halts itself. The file-
system-process goes back to sleep when it has nothing else to do.
[The reader should have noticed by now that I do not like to think of
a new process (consisting of a new conceptual copy of a program)
being started up each time another user wishes to use the program.
Rather, I like to think of the program as a single process which
knows it is being used simultaneously by many other processes and
consciously multiplexes among the users or delays service to users
until it can get around to them.]
Again, the file-system-process can keep a small collection of port
numbers which it uses over and over if it can get file system users
to return the port numbers when they are done with them. Of course,
when this collection of port numbers has eventually dribbled away,
the file system can get some new unique numbers from the monitor.
Note that when two processes wish to communicate they set up the
connection themselves, and they are free to do it in a mutually
convenient manner. For instance, they can exchange port numbers or
one process can pick all the port numbers and instruct the other
process which to use. Of course, in a particular implementation of a
time-sharing system, the builders of the system might choose to
restrict the processes' execution of SENDs and RECEIVEs and might
forbid arbitrary passing around of port numbers, requiring instead
that the monitor be called (or some other special program) to perform
these functions.
Walden [Page 7]
RFC 61 Interprocess Communication in a Computer Network July 1970
Flow control is provided in this system by the simple method of never
starting a SEND from one process until a RECEIVE is executed by the
receiver. Of course, interprocess messages may be sent back and
forth suggesting that a process stop sending or that space be
allocated, etc.
INTERPROCESS COMMUNICATION BETWEEN REMOTE PROCESS
The system described in the previous section easily generalizes to
allow interprocess communication between processes at geographically
different locations as, for example, within a computer network.
Consider first a simple configuration of processes distributed around
the points of a star. At each point of the star there is an
autonomous time-sharing system. A rather large, smart computer
system, called the Network Controller, exists at the center of the
star. No processes can run in this center system, but rather it
should be thought of as an extension of the monitor of each time-
sharing system in the network.
It should be obvious to the reader that if the Network Controller is
able to perform the operations SEND, RECEIVE, SEND FROM ANY, RECEIVE
ANY, and UNIQUE and that if all of the monitors in all of the time-
sharing systems in the network do not perform these operations
themselves but rather ask the Network Controller to perform these
operations for them, then we have solved the problem of interprocess
communication between remote processes. We have no further change to
make.
The reason everything continues to work when we postulate the
existence of the Network Controller is that the Network Controller
can keep track of which RECEIVEs have been executed and which SENDs
have been executed and match them up just as the monitor did in the
model time-sharing system. A networkwide port numbering scheme is
also possible with the Network Controller knowing where (i.e., at
which site) a particular port is at a particular time.
Next, consider a more complex network in which there is no common
center point making it necessary to distribute the functions
performed by the Network Controller among the network nodes. In the
rest of this section I will show that it is possible to efficiently
and conveniently distribute the functions performed by the star
Network Controller among the many network sites and still enable
general interprocess communication between remote processes.
Some changes must be made to each of the four SEND/RECEIVE operations
described above to adapt them for use in a distributed network. To
RECEIVE is added a parameter specifying a site to which the RECEIVE
Walden [Page 8]
RFC 61 Interprocess Communication in a Computer Network July 1970
is to be sent. To SEND FROM ANY and SEND is added a site to send the
SEND to although this is normally the local site. Both RECEIVE and
RECEIVE ANY have added the provision for obtain the source site of
any received message. Thus, when a RECEIVE is executed, the RECEIVE
is sent to the site specified, possibly a remote site. Concurrently
a SEND is sent to the same site, normally the local site of the
process executing the SEND. At this site, called the rendezvous
site, the RECEIVE is matched with the proper SEND and the message
transmission is allowed to take place to the site from whence the
RECEIVE came.
A RECEIVE ANY never leaves its originating site and therein lies the
necessity for SEND FROM ANY. It must be possible to send a message
to a RECEIVE ANY port and not have the message blocked waiting for
RECEIVE at the sending site. Of course, it would be possible to
construct the system so the SEND/RECEIVE rendezvous takes place at
the RECEIVE site and eliminate the SEND FROM ANY operation, but in my
judgment the ability to block a normal SEND transmission at the
source site more than makes up for the added complexity.
Somewhere at each site a rendezvous table is kept. This table
contains an entry for each unmatched SEND or RECEIVE received at that
site and also an entry for all RECEIVE ANYs given at that site. A
matching SEND/RECEIVE pair is cleared from the table as soon as the
match takes place or perhaps when the transmission is complete. As
in the similar table kept in the model time-sharing system, SEND and
RECEIVE entries are timed out if unmatched for too long and the
originator is notified. RECEIVE ANY entries are cleared from the
table when a fulfilling message arrives.
The final change necessary to distribute the Network Controller
functions is to give each site a portion of the unique numbers to
distribute via its UNIQUE operation. I'll discuss this topic further
below.
To make it clear to the reader how the distributed Network Controller
works, an example follows. The details of what process picks port
numbers, etc. are only exemplary and are not a standard specified as
part of the system.
Suppose there are two sites in the network: K and L. Process A at
site K wishes to communicate with process B at site L. Process B has
a RECEIVE ANY pending at port M.
Walden [Page 9]
RFC 61 Interprocess Communication in a Computer Network July 1970
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ / \ /
\ / \ port M /
\________/ \____^___/
|
RECEIVE ANY
Process A, fortunately, knows of the existence of port M at site L
and sends messages using the SEND FROM ANY operation from port N to
port M. The message contains two port numbers and instructions for
process B to SEND messages to process A to port P from port Q. Site
K's site number is appended to this message along with the message's
SEND port N.
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ / \ /
\ port N /--->SEND FROM --->\ port M /
\________/ ANY \________/
to port M, site L
containing K, N, P, & Q
Process A now executes a RECEIVE at port P from port Q. Process A
specifies the rendezvous site to be site L.
Walden [Page 10]
RFC 61 Interprocess Communication in a Computer Network July 1970
SITE K SITE L
________ R ________
/ \ e / \
/ \ n T/ \
/ \ d a \
| | e b Process B |
| Process A | z l |
| | v e |
\ / o \ /
\ port P / RECEIVE ---> u \ /
\________/ MESSAGE s \________/
to site L
containing P, Q, & K
A RECEIVE message is sent from site K to site L and is entered in the
rendezvous table at site L. At some other time, process B executes a
SEND to port P from port Q specifying site L as the rendezvous site.
SITE K SITE L
________ R ________
/ \ e / \
/ \ n T/ \
/ \ d a \
| | e b Process B |
| Process A | z l |
| | v e |
\ / o \ /
\ port P / u <--- port Q /
\________/ SEND s \________/
to site L
containing P & Q
A rendezvous is made, the rendezvous table entry is cleared, and the
transmission to port P at site K takes place. The SEND site number
(and conceivably the SEND port number) are appended to the messages
of the transmission for the edification of the receiving process.
Walden [Page 11]
RFC 61 Interprocess Communication in a Computer Network July 1970
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ port P / \ port Q /
\ / <---- transmission <---- \ /
\________/ to port T, site K \________/
containing data and L
Process B may simultaneously wish to execute a RECEIVE from port N at
port M.
Note that there is only one important control message in this system
which moves between sites, the type of message that is called a
Host/Host protocol message in [3]. This control message is the
RECEIVE message. There are two other possible intersite control
messages: an error message to the originating site when a RECEIVE or
SEND is timed out, and the SEND message in the rare case when the
rendezvous site is not the SEND site.
Of course there must also be a standard format for messages between
ports. For example, the following:
Walden [Page 12]
RFC 61 Interprocess Communication in a Computer Network July 1970
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?