rfc150.txt

RFC 的详细文档！

receiver catch up with it. By pinpointing bottlenecks, it can be used to
detect design mismatches.

      Unless the channel has no outstanding messages or it is dead,
there is the possibility that concurrently with the request the
receiving process will accept another message. This being the case, the
count returned can not be assumed to be exact but must be considered as
only an upper bound.

ABILITY TO GET WAKEUPS WHEN MESSAGES ARE ACCEPTED

      In conjunction with the above it should be possible for a user
process to be alerted when the number of messages that have been sent
over a particular channel and not accepted at the far end falls below a
specified threshold. Thus a process, upon discovering that twenty
messages are still outstanding, can elect to enter the shade until this
number has fallen to less than five. By doing so the process can run in
'burst mode'. Rather than being swapped in and out of core fifteen times
and each time being allowed to send one message, it is loaded once and
sends fifteen messages. There is no penalty for doing this since the
bottleneck on throughput is at the receiving process. If swapping costs
for the local process are significant, there may be considerable
economic advantage to this mode of operation.

      If the remote process dies or issues a channel 'close', the count
of undelivered messages becomes frozen. If the receiving process is
expecting this type of wakeup, it should get one at this time even
though the count has not reached the desired threshold. The process is
thus alerted to do a postmortem on the channel.



                                                                [Page 6]

RFC #150                 Use of IPC Facilities                5 May 1971


ABILITY TO LEARN ABOUT MESSAGES QUEUED FOR INPUT

      A process should be able to learn of the status of the Nth logical
message queued on a given input channel. It should a least be able to
determine if it is available, whether or not it is complete, how long it
is and what it contains.

      This facility allows a program to make general preparations before
accepting a message. It offers some escape from being put into the
awkward position of having accepted input and not being able to dispose
of it. If for example, it is known that processing the message will
result in two more messages being sent, then it is advantageous to get
guarantees that the output can be generated before the input is
accepted.

      Under circumstances in which one end of a channel is moved from
one process to another, for example, moving a teletype connection
between a user program and a debugging program, this ability to scan
ahead in the input stream allows a process to check whether or not
pending input is really meant for it. If it is, the input will then be
accepted normally, otherwise, the end of the channel must be first moved
to another receiving process.

      Accepting input should be viewed as a grave responsibility, not to
be undertaken unless there is reasonable assurance that the input can be
processed. One of the first rules of asynchronous system design is to
detect errors as soon as possible. If propagated, the tangled results
may be hopeless to unravel.

ABILITY TO LEARN HOW MANY MESSAGES ARE WAITING

      A process should be able to determine how many messages are
left to be processed on a given input channel. Two uses are readily
thought of. Given pending inputs on several channels a process should be
able to exercise preference. One decision might be to take input first
from the channel with the most messages queued. This might have the
effect of increasing throughput since by freeing message buffers the
remote transmitting process might be allowed to run. Another possibility
might be that the receiving process has some control over the sending
process and, upon observing the backlog on inputs, it could tell that
process to slow down.

      Assuming that the remote process is still able to send messages,
the number of inputs reported is only a lower bound. New inputs may be
added concurrently. If the foreign process has died or has otherwise
closed the connection then the bound can be made exact. The local
process should be able to learn when it is exact.




                                                                [Page 7]

RFC #150                 Use of IPC Facilities                5 May 1971


GUARANTEE THAT INPUT WILL STAY AVAILABLE

      This requirement states that if a process has been told that it is
able to receive N messages on a given channel, that those messages are
really available and buffered within the host machine. If promised to a
user process, messages should not mysteriously become unavailable. An
example of how this might happen is illustrated in RFC60.  There, during
a panic for buffer space, messages are destroyed and reported as being
in error. They are later recovered from backup copies contained in the
foreign host.

ABILITY TO RECEIVE A WAKEUP WHEN INPUTS ARRIVE

      A process should be able to enable a wakeup when the number of
messages queued on an input channel exceeds a specified value or has
reached its maximum value. This allows a program to process input in a
burst mode fashion and to economize on swapping costs. It also permits
inputs to be combined in a simple manner. If, for example, two inputs
are needed before anything can be done, then the appropriate interrupt
can be easily generated.

      The same interrupt should be generated if the maximum number of
inputs have been received. Two cases are distinguished. Either the
foreign process has closed the channel and is therefore not sending more
messages, or the system will not allocate more buffers until some input
is accepted. In this way the process can be informed that there is no
point in waiting for the condition it anticipates.

ABILITY TO SPECIFY SPECIAL WAKEUPS

      A process, when trying to run efficiently, should be able to
specify arbitrarily complicated wakeup conditions. This allows a user
managed way of minimizing the number of premature wakeups. This
generality is perhaps most easily provided for by allowing the main
process to designate a small low overhead interrupt driven routine that
will check for the desired conditions and issue a wakeup to the main
process whenever they are met.

ABILITY TO MEASURE CHANNEL CAPACITY

      There has been much discussion about the measure of a data stream
and in the heat of committee, much confusion has been generated. It is
our feeling that, within the present domain of discussion, there is no
single measure of the capacity of a message channel. Two completely
orthogonal concepts must be measured -- 1) the number of messages
buffered and 2) the number of bits of encoded data represented. The
system overhead associated with each is very much implementation
dependent and hence no general equation can express the measure of one



                                                                [Page 8]

RFC #150                 Use of IPC Facilities                5 May 1971


in terms of the other. By making an arbitrary assumption (eg. a message
boundary equals 100 bits of buffer), a system runs the risk of excluding
new nodes that are unable to meet the old criterion.

ABILITY TO FIND OUT MAXIMUM CHANNEL CAPACITY

      There should be provided a system call that enables a user process
to learn of the maximum current capacity of any given channel. This
should be reported as a pair of numbers, namely the maximum bit count
and the maximum message count.

ABILITY TO CONSTRAIN CHANNEL CAPACITY

      A process using a channel should be able to set new bounds on the
capacity of a given channel. If possible the system should try to meet
this bound. It should be noted that the actual bounds imposed must meet
the constraints of at least four different sources -- local and remote
user process, local and remote system -- by setting a arbitrarily high
bound, no guarantee is made that it can be met. Similarly, a low bound
can not always be met until buffered messages are consumed.

      Thus a receiving process, by setting the current message bound to
zero, effectively disables the transmission of new messages. Thus,
without the cooperation of the transmitting process, message generation
can be temporarily disabled, while outstanding message buffers are
flushed. Later the message allocation can be raised to its original
limit and transmission can be resumed.

ABILITY TO CLOSE A CHANNEL AT ANY TIME

      A process should be able to close down a channel at any time. If
the process has died, the system should be able to close all open
channels for it. For channels over which the process was receiving data,
pending input should be thrown away and indications returned to the
transmitting system marking the channel as dead and identifying the last
data item accepted. This identification will be in terms of the number
of logical messages discarded and the number of bits left in the oldest
message.

      If a process closes a channel over which it had been sending,
buffered output should be sent normally, and with it should be sent an
indication that this is all of the input that will ever appear.








                                                                [Page 9]

RFC #150                 Use of IPC Facilities                5 May 1971

ABILITY TO GIVE AWAY CHANNEL PRIVILEGES

      The right to perform any of the operations discussed here is
normally reserved by the process that established the channel. At times
that process may wish to transfer some of its delegated power to another
process, especially in an environment where one process may spawn
another and resources must be passed to the newly created process.

      Schemes for such reassignment can become arbitrarily complicated.
One could, for example, assign each of the various aspects of usage
individually and then separately assign the various rights of
reassignment. Fortunately it is not always necessary that it become so
elaborate, it is expected that in most cases the following simple
strategy can suffice. The ability to close a channel is retained
exclusively by the process that established the channel. If the channel
is still open when the process dies, it is automatically closed by the
system. All other uses of the channel remain outside system control. The
channel is known by name and all processes to which the name has been
given may make use of the channel. It is left to user level coordination
to insure that only one process is actually making use of it at any one
time.

ABILITY TO INITIATE CHANNEL CREATION

      For most cases channel establishment can be handled quite simply.
A process announces to its local system that it listening on a 
specified channel. It is connected to the first remote process that
'dials' the right number. Identification of the caller takes place
only after the channel has been established. In the event of a wrong
number, the channel can be closed and the listening resumed. Callers
trying to reach preestablished channels will get a 'busy signal'.

      To 'dial' a remote process a process must specify a channel on
which it is listening and a remote number. The system will then
attempt to establish the connection. The channel will become 'busy'
during this time.

      For processes that prefer to avoid the complications of
identifying remote callers, an additional feature can be added. By
specifying both the local and remote channel identifiers a process can
transfer to the system the responsibility for screening callers for
the proper identification. The connection will only be accepted from
the caller specified.


                                                                [Page 10]

RFC #150                 Use of IPC Facilities                5 May 1971


ABILITY TO REPORT TRANSMISSION ERRORS

      If after prescanning an input message a process should decide
that it contains some sort of transmission error, it should be able to
reject the message. The system should then invoke any internal error
recovery mechanism that it may have implemented.

POSTSCRIPT

      The author welcomes any comments, questions, or corrections to
this document. Even the most informal note or telephone call will be
appreciated. Especially of interest are opinions about the usefulness
of the discussion and wether or not there should be more papers
directed at other of the basic questions of computer networking. If
the consensus tends to the affirmative, then others are encouraged to
contribute working papers on the problems of flow control, error
handling, process ownership, accounting, resource control, and the
like.


RBK/TX2


         [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by Michael Baudisch 9/97 ] 






















                                                                [Page 11]