RFC150 日本語訳

Richard Bl. Kalin                            Network Working Group
MIT Lincoln Laboratory                       Request for Comments #150
5 May 1971                                   NIC 6754

リチャードBl。 NIC6754を求める年コメント#150 1971年5月5日KalinネットワークワーキンググループMITリンカーン研究所Request

THE USE OF IPC FACILITIES

IPC施設の使用

***A WORKING PAPER***

***監査調書***

This material has not been reviewed for public release and is intended
only for use within the ARPA network. It should not be quoted or cited
in any publication not related to the ARPA network.

この材料は、公共のリリースのために見直されていなくて、使用のためだけにARPAネットワークの中で意図します。 ARPAネットワークに関連しない少しの公表でも、それを引用するべきではありませんし、また引用するべきではありません。

INTRODUCTION

序論

      It is our hypothesis that the goals of interprocess communication
are more complex than commonly realized, and that until this complexity
is more fully understood, there will be no satisfactory implementations.
The objective of an IPC design must be more than that of providing a
facility for moving bits between otherwise independent user programs, a
variety of other constraints must also be satisfied.

それはプロセス間通信の目標が一般的に実感されるより複雑であり、この複雑さが、より完全に理解されるまでどんな満足できる実現もないという私たちの仮説です。 IPCデザインの目的はまた、そうでなければ、独立しているユーザ・プログラムの間の動くビットに施設を供給するものより他のさまざまな規制を満たさなければならないという、ことであるに違いありません。

      These constraints are dictated by the eventual usage of the
facility. Any design that will sustain this usage pattern can be a
satisfactory one. If it does so efficiently, it will be said to be well
designed. Furthermore, it is unimaginable that a large design effort,
undertaken without a complete understanding of the usage it must serve,
will ever be well designed or even satisfactorily designed.

これらの規制は施設の最後の使用法で書き取られます。 この用法パターンを支えるどんなデザインも満足できるものであるかもしれません。 それほど効率的にすると、それはよく設計されていると言われるでしょう。 その上、それが役立たなければならない用法の完全な理解なしで引き受けられた大きいデザインの努力が今までによく設計されているか、または満足に設計さえされる、想像を絶しています。

      This paper undertakes the exposition of the types of usage to
which an IPC facility would be subjected, in hopes that such a
discussion will clarify the goals being pursued and will provide a
benchmark for gauging various implementation strategies. The difficulty
of this task should not be underestimated. The only experience available
for us to draw upon is from very primitive and overly constrained IPC
implementations. Extrapolation from this limited usage environment to
more general notions has as yet no basis in real experience. Such
speculation is therefore subject to enormous oversight and misguided
perspective.

この紙はIPC施設がかけられる用法のタイプの博覧会を引き受けます、そのような議論が追求される目標をはっきりさせて、様々な実現戦略を測るのにベンチマークを提供するという望みで。 このタスクの困難を過小評価するべきではありません。 私たちが利用するように利用可能な唯一の経験が非常に原始的でひどく強制的なIPC実現から来ています。 この限られた用法環境から、より一般的な概念までの推定には、まだ、実体験における基礎が全くありません。 したがって、そのような思惑は莫大な見落としと見当違いの見解を受けることがあります。

      In compiling this paper, it was necessary to imagine what services
a process might want from an IPC facility. The areas recognized include:
 1) the exchange of bit encoded information via channels.
 2) the establishment, deletion, and reassignment of these channels.
 3) the ability to debug errors and suspected errors.
 4) the potential to improve running efficiency.
 5) the capacity to avoid storage allocation deadlocks.
 6) the aided recovery from transmission errors.

この紙を編集するのにおいて、過程がIPC施設からどんなサービスを必要とするかもしれないかを想像するのが必要でした。 認識された領域は: 1) ビットの交換はチャンネルで情報をコード化しました。 2) 設立、削除、およびこれらの再割当ては向けられます。 3) 誤りと疑われた誤りをデバッグする能力。 4) 走行効率を高める可能性。 5) 記憶領域の割当て行き詰まりを避ける能力。 6) 伝送エラーからの支援された回復。

                                                                [Page 1]

RFC #150                 Use of IPC Facilities                5 May 1971

[1ページ] IPC施設1971年5月5日のRFC#150使用

This list is known to be incomplete. Some areas, such as understood to
be intelligently discussed. In other cases, omissions should be blamed
on simple oversight.

このリストが不完全であることが知られています。 知的に議論するのが理解されているようないくつかの領域。 他の場合では、省略は簡単な見落としのせいにされるべきです。

      Because of these obvious problems, one should not consider any
document of this kind as either authoritative or final. For this reason,
this paper is being kept as a computer based textfile, and so will
remain subject to editting and rerelease whenever new insights become
understood. We hope that it can remain an accurate and up to date
statement of the goals to which any group of IPC implementers can aspire
and, as such, can be a guidebook to the problems that must be faced.

これらの明白な問題のために、この種類のどんなドキュメントも正式であるか、または最終的であるとみなすべきではありません。 この理由で、この紙は、コンピュータがtextfileを基礎づけて保管されているので、edittingと再発売を条件として新しい洞察が理解されるようになるときはいつも、残るでしょう。 直面しなければならない問題のままでIPC implementersのどんなグループも切望できて、そういうものとしてガイドブックであるかもしれない目標の正確で最新の声明のままで残ることができることを願っています。

      For several reasons no attempt shall be made here to design
suitable solutions to the problems raised. To be useful, such solutions
must be machine dependent. A so called 'general solution' would actually
be too clumsy and inefficient to be of any value. Secondly, we take the
point of view of the user, who need not be aware of the manner in which
his demands are carried out, so long as they can be accomplished.
Finally, we are trying to stay aloof from the eccentricities of present
day machine organization.

いくつかの理由で、ここで試みを全く問題の適当な解決が提起したデザインにしないものとします。 役に立つように、そのような解決策はマシン依存でなければなりません。 いわゆる'一般解'は、実際にどんな価値でも効率が悪いことができなく不器用であって、効率が悪いでしょう。 第二に、私たちは彼の要求が行われる方法を意識する必要はないユーザの観点を取ります、それらを達成できる限り。 最終的に、私たちは近代のマシン組織の風変わりからよそよそしいままであろうとしています。

In our attempt to be implementation independent, we are admittedly
treading a fuzzy line. Our characterization of usage patterns presumes
both a system/process software organization and a computing milieu
capable of supporting it. Although this does not appear to significantly
affect the generality of the document, some care must be exercised in
the selection of host machines.

実現独立者である試みでは、私たちはあいまいな線を明白に踏み均しています。 私たちの用法パターンの特殊化は、両方がシステム/過程ソフトウェア組織とそれを支持できるコンピューティング周囲であると推定します。 これはドキュメントの一般性にかなり影響するように見えませんが、ホスト・マシンの品揃えに何らかの注意を訓練しなければなりません。

               *****

*****

      In the rest of this paper, we attempt to characterize the types of
usage that should be anticipated by an IPC facility. The organization is
into titled sections, each section discussing some aspect of the
expected usage.

この紙の残りでは、私たちは、IPC施設によって予期されるはずである用法のタイプについて描写するのを試みます。 題をつけられたセクション、予想された用法の何らかの局面について論ずる各セクションには組織があります。

ABILITY TO USE VARIOUS SOURCES OF WAKEUP INFORMATION

WAKEUP情報の様々な源を使用する能力

      Most processes exhibit preferences toward certain quantities of
input data. This preference is reflected in the amount of computing time
that can be expended for a given amount of input. For example, a
character translation routine might prefer eight bit quantities of
input. With seven or less bits no processing is possible, but once a
complete character is available an entire translation cycle can
commence. This preference is independent of the function of the routine.
Otherwise equivalent routines could be written that would accept one bit
at a time. In other examples, a command interpreter might require a
complete line of input, a linking loader a complete file.

ほとんどの過程が、ある量の入力データに向かって好みを示します。 この好みは与えられた量の入力のために費やすことができる計算時間の量に反映されます。 例えば、文字変換ルーチンは入力の8ビットの量を好むかもしれません。 7ビット以下では、処理でないのは可能ですが、完全なキャラクタがいったん手があくようになると、全体の翻訳サイクルは始まることができます。 この好みはルーチンの機能から独立しています。 一度に1ビット受け入れるそうでなければ、同等なルーチンは書くことができました。 他の例では、コマンドインタープリタは入力の完全な線を必要とするかもしれなくて、リンキングローダは完全なファイルです。

                                                                [Page 2]

RFC #150                 Use of IPC Facilities                5 May 1971

[2ページ] IPC施設1971年5月5日のRFC#150使用

      Every executive system must face the problem of deciding at what
times enough input is available for a given routine for it to run
efficiently. This decision can not be taken lightly. Issuing a wakeup to
a dormant process carries with it considerable overhead -- room in core
storage must be made available, the program must be swapped into memory,
tables must be updated, active registers exchanged, and the entire
procedure done in reverse once the process has finished. To issue a
wakeup when there is insufficient input for the program is inefficient
and wasteful. The amount of computing that can be done does not justify
the overhead that must be expended.

あらゆるエグゼクティブ・システムが十分な入力がどんな時にそれが効率的に走らせる与えられたルーチンに利用可能であるかを決めるという問題に直面しなければなりません。 軽くこの決定を取ることができません。 それが無視できない状態で眠っている過程にwakeupを発行するのは頭上まで運ばれます--テーブルは、コア記憶装置における場所を利用可能にしなければならなくて、プログラムをメモリと交換しなければならなくて、交換された、アップデートされて、アクティブなレジスタと、過程がいったん終わると逆であり行われた全体の手順であるに違いありません。 プログラムのための不十分な入力があるとき、wakeupを発行するのは、効率が悪くて、無駄です。 できるコンピューティングの量は費やさなければならないオーバーヘッドを正当化しません。

      The problem of determining a priori the best time to issue a
wakeup has no general solution. It depends critically upon the
relationship between waiting costs and running costs. Attempts to make
reasonable predictions must contend with the tradeoff between accuracy
and overhead. The more system code that must be run, the more overhead
incurred and the less the final prediction means.

先験的にwakeupを発行する最も良い時間を決定するという問題には、一般解が全くありません。 それは批判的にコストとランニング・コストを待つことの間の関係によります。 合理的な予測をする試みは精度とオーバーヘッドの間の見返りを競争しなければなりません。 より走らせなければならないオーバーヘッドが被って、最終的な予測が意味しないシステム・コードは、より多いです。

      Although there is no general solution, help is available to the
scheduler in specific cases. A commonly found instance is that of using
the receiving process to specify the number of bits that it is
expecting. Thus, a process may inform the supervisor/scheduler that it
requires fifty bits of input from some source before it is able to
continue. The process can then go into the shade and it will be awakened
when the required input is available.

一般解が全くありませんが、助けは特定の場合におけるスケジューラに利用可能です。 一般的に見つけられた例はそれが予想しているビットの数を指定するのに受信の過程を使用するものです。 したがって、過程は、続くことができる前にソースからの50ビットの入力を必要とすることを監督/スケジューラに知らせるかもしれません。 次に、過程は日陰に入ることができます、そして、必要な入力が利用可能であるときに、それは目を覚ますでしょう。

      In cases where input lengths are predetermined, this technique is
quite satisfactory. Elsewhere, problems arise. In the case of unknown
input sizes, too short a prediction will give rise to the inefficiencies
of premature scheduling, and too long a prediction may produce input
deadlocks.

入力の長さが予定される場合では、このテクニックはかなり満足できます。 ほかの場所では、問題が起こります。 未知の入力サイズの場合では、短過ぎる予測は時期尚早なスケジューリングの非能率をもたらすでしょう、そして、長過ぎる予測は入力行き詰まりを作り出すかもしれません。

      Under these circumstances it is common to have the process tell
the scheduler a simple criterion that can be applied to determine if
there is sufficient input -- the appearance of a carriage return in the
teletype input stream, for example. The criterion is tested either by
system routines or by a low overhead user supplied routine (which in
turn must have a criterion of its own for being awakened).  Once the
criterion is met, the main routine is awakened and processing continues.

過程にそこで確認するために適用できる簡単な評価基準が十分な入力であるとスケジューラに言わせるのは、一般的です--こういう事情ですから、例えば、テレタイプ入力ストリームにおける、復帰の外観。 システムルーチンか低い頭上のユーザ供給されたルーチン(目を覚まされるために順番にそれ自身の評価基準を持たなければならない)で評価基準はテストされます。 評価基準がいったん満たされると、メインルーチンは目を覚まします、そして、処理は続きます。

      Sometimes the system and user criteria work in conjunction with
one another. A user may specify an maximum character count,
corresponding to available buffer size, and the system may look for line
terminators. Wakeups to the user process may appear from either source.
At other times the system may preempt the user's criterion. For example,
if a process while trying to put a single character into a full buffer
is forced into shade, it will typically not be awakened again until
buffer has been almost emptied. Even though the user program only wished

時々、システムとユーザ評価基準はお互いに関連して動作します。 ユーザは最大のキャラクタカウントを指定するかもしれません、有効なバッファサイズに対応している、システムは線ターミネータを探すかもしれません。 ユーザ・プロセスへのWakeupsはどちらのソースからも現れるかもしれません。 他の時に、システムはユーザの評価基準を先取りするかもしれません。 例えば、過程が完全なバッファに単独のキャラクタを入れていようとしている間、日陰の中に強制されると、バッファがほとんど空にされるまで、それは再び通常目を覚まさないでしょう。 ユーザ・プログラムは願われていただけですが

                                                                [Page 3]

RFC #150                 Use of IPC Facilities                5 May 1971

[3ページ] IPC施設1971年5月5日のRFC#150使用

room for a single character, the system imposed a much stronger
criterion, namely room for N characters, on the assumption other calls
to output characters will follow. Thus the program is forced into
outputting in bursts and, rather than going into the shade and being
awakened N times, each time when there is only room to output one
character, the program is awakened once and sends N characters. Program
efficiency is appropriately improved.

単独のキャラクタの余地、システムははるかに強い評価基準、すなわち、Nキャラクタの余地を課しました、キャラクタを出力するという他の要求が続くという前提で。 したがって、プログラムが炸裂における出力に押し込まれて、プログラムは、N回と、その都度、1つのキャラクタを出力する余地しかないとき、日陰に入って、目を覚まされるよりむしろ、一度目を覚まして、Nキャラクタを送ります。 プログラム効率は適切に改良されます。

      A third source of criteria for deciding when to awaken the user
process is the device or routine that is producing the input data. This
source is frequently utilized in hardware design. Many computer
peripherals have the ability to send an end of record indication. For
variable length uninterpreted records this is an absolute necessity. For
fixed length records it is a convenient double check. In the world of
interprocess communication an analogous feature should be available. If
the routine that is generating the data knows how much the receiving
routine will require, then this information should be made available for
scheduling purposes. Implementing this requires a standardized way of
denoting logical boundaries on the stream of data flowing, through a
communication channel. The markers must be recognizable by the
scheduler/supervisor in the receiving host computer so that wakeups can
be issued as desired. To simplify the task of input interpretation,
marker pacement should also be visible to the receiving process.

ユーザ・プロセスにいつ目を覚まさせるかを決める評価基準の3番目の源は、入力データを作り出している装置かルーチンです。 このソースはハードウェアデザインで頻繁に利用されます。 多くのコンピュータ周辺機器には、記録的な指示の終わりを送る能力があります。 可変長の非解釈された記録のために、これは絶対必要です。 固定長レコードに関しては、それは便利な再確認です。 プロセス間通信の世界では、類似の特徴が利用可能であるべきです。 データを発生させているルーチンが、受信ルーチンがどのくらい必要とするかを知っているなら、この情報をスケジューリング目的に利用可能にするべきです。 これを実行するのは通信チャネルで流れるデータのストリームの上の論理的な境界を指示する標準化された方法を必要とします。 マーカーは、受信ホストコンピュータのスケジューラ/監督が、望まれているようにwakeupsを発行できるくらい認識可能でなければなりません。 また、入力解釈に関するタスクを簡素化するために、マーカーpacementも受信の過程に目に見えるべきです。

      The data between boundaries we shall call a logical message, since
it is a natural unit of information exchange and since the markers
travel with the data through the channel. The additional information the
markers provide about data flow yield many useful consequences.
Consider, for example, two processes that always exchange 100 bit long
logical messages. If the receiving process is able to determine the
length of each logical message that arrives, there is available a simple
facility for error detection. If a 99 bit message arrives, it is obvious
that a bit has been dropped somewhere.

私たちがそれ以来の論理メッセージを呼ぶつもりである境界の間のデータは、情報交換の自然なユニットであり、チャンネルによるデータがあるマーカー旅行以来そうです。 マーカーがデータフロー利回りに関して多くの役に立つ結果を提供する追加情報。 考えてください、そして、例えば、2つの過程がそんなにいつも長さ100ビットの論理メッセージを交換します。 受信の過程が到着するそれぞれの論理メッセージの長さを測定できるなら、誤り検出のための利用可能なa簡単な施設があります。 99ビットのメッセージが到着するなら、それがどこかに少し落とされたのは、明白です。

      It should be noted that it is not always possible for the
receiving process to compute the positions of boundary markers in the
input stream. there is no reason that the information implicit is marker
position must also be found as part of the coded input data. Even in
cases in which there is coding redundancy, it may be more difficult to
extract boundary information from the rest of the input than it is to
use the markers explicitly.

中の境界マーカーでは、入力は流れます。受信の過程には、計算するために、いいえがあるという位置がそれを推論するのが、いつも可能であるというわけではないことに注意されるべきである、情報、暗黙であることは、また、コード化された入力データの一部としてマーカー位置を見つけなければならないということです。 冗長をコード化するのがある場合ではさえ、それは入力の残りから境界情報を抜粋するのが明らかにマーカーを使用することになっているより難しいかもしれません。

ABILITY TO SEND PARTS OF LOGICAL MESSAGES

論理メッセージの部分を送る能力

      Any IPC facility, in which user storage is at all constrained, can
not require a process to send an entire logical message at one time. The
concept is only introduced to facilitate the issuing of wakeups to a
receiving process. What are convenient input quanta for the receiving

どんなIPC施設(ユーザ格納は全く抑制される)も、ひところ全体の論理メッセージを送るために過程を必要とすることができません。 概念は、wakeupsの発行を受信の過程に容易にするために紹介されるだけです。 受信のための便利な入力量子は何ですか?

                                                                [Page 4]

RFC #150                 Use of IPC Facilities                5 May 1971

[4ページ] IPC施設1971年5月5日のRFC#150使用

process may not be convenient output quanta for the sending one.
consider the case of a process running on a small machine and sending
messages to a process on a large task-multiplexed machine. For
efficiency, the receiving process requires large quantities of input
data at a time. Buffer space in the address space of the sending process
can not hold much data. The only answer is to allow the sending process
to dump its logical message in parts and with the last part to indicate
that it is the end of a message.

過程は発信もののための便利な出力量子でないかもしれません。大きいタスクで多重送信されたマシンで小さいマシンで動いて、メッセージを過程に送る過程に関するケースを考えてください。 効率のために、受信の過程は一度に、大量に関する入力データを必要とします。 送付の過程のアドレス空間におけるバッファ領域は多くのデータを保持できません。 唯一の答えは部品とメッセージの終わりであることを示す最後の部分で論理メッセージをどさっと落とすために送付の過程を許容することです。

ABILITY TO RECEIVE A LOGICAL MESSAGE IN PARTS

部品で論理メッセージを受ける能力

      In the reverse of the above situation, a receiving process may not
have sufficient buffer space available to accept an entire message at
once. It should be possible under these circumstances to elect to accept
the message in parts. This is also necessary in the case of messages
that are too long to be buffered by the system. Unless part of the
message is accepted by the receiving process, the transmission can never
be completed. This device also serves for the removal of very long
messages that appear by error in the input stream.

上の状況の逆では、受信の過程はすぐに全体のメッセージを受け入れるために利用可能な十分なバッファ領域を持っていないかもしれません。 部品でメッセージを受け入れるのを選ぶのはこういう事情ですから可能であるべきです。 また、これもシステムでバッファリングできないくらい長いメッセージの場合で必要です。 メッセージの一部が受信工程で受け入れられない場合、トランスミッションは決して終了できません。 また、この装置は入力ストリームにおける誤りで現れる非常に長いメッセージの取り外しを満たします。

ABILITY TO FIND OUT IF A MESSAGE CAN BE SENT

メッセージを送ることができるかどうか見つける能力

      If left unchecked, a routine can easily generate messages faster
than they can be consumed. Since any given amount of buffer capacity can
be quickly exhausted, there must be a way for the system to limit the
rate at which a process produces messages. This implies that at times a
process trying to send a message may be prevented from doing so because
of buffer inavailability. If the process is forced into the shade, the
pause should not come without warning. There should be a way for the
process to learn in advance if the message can be sent. A program may
have better things to do than wait for a buffer to become available.

抑制されないままにされるなら、ルーチンはメッセージを容易にそれらを消費できるより速く発生させることができます。 どんな与えられた量の緩衝能もすばやく消耗できるので、システムが過程がメッセージを出すレートを制限する方法があるに違いありません。 これは、時にはメッセージを送ろうとする過程がバッファの「不-有用性」のためにそうするのが防がれるかもしれないのを含意します。 過程が日陰の中に強制されるなら、くぎりはいきなり来るべきではありません。 過程があらかじめメッセージを送ることができるかどうか学ぶ方法があるべきです。 プログラムには、するためにバッファが利用可能になるのを待っているより良いものがあるかもしれません。

ABILITY TO GET A GUARANTEE OF OUTPUT BUFFER SPACE

出力バッファ領域の保証を得る能力

      A process should be able to get guarantee from the system that a
message of a certain size can be sent. This allows the process to know
before a computation is made that the results can be successfully
output. This allocation should remain either until it is depleted or
until it is changed by another allocation request.

過程はシステムからのあるサイズに関するメッセージを送ることができるという保証を得ることができるべきです。 これは計算をする前に知る結果が首尾よくそうであることができる過程に出力を許します。 この配分はそれを使い果たすか、または別の配分要求でそれを変えるまで残るべきです。

      This particular user option is sure to raise the wrath of legions
of system programmers. From their point of view, the empty buffer space
that is being preallocated is necessarily being wasted. For although it
contains no messages, it is not available for other uses. The user, on
the other hand, does not correlate 'empty' with 'wasteful' nor 'full'
with 'efficient'. A process needs empty output buffers as much as it
needs full input ones. Both are resources necessary to sustain
processing.

この特定のユーザ・オプションは確実にシステム・プログラマの軍勢の復讐を上げます。 彼らの観点から、「前-割り当て」られている人影のないバッファ領域は必ず浪費されています。 メッセージを全く含んでいませんが、それが他の用途に利用可能でないので。 他方では、ユーザは'無駄である''いっぱいに''効率的'で'空になってください'を関連させません。 出力されて、必要性が空にする過程はものを完全な入力を必要とするのと同じくらい非常にバッファリングします。 両方が処理し続けるのに必要なリソースです。

                                                                [Page 5]

RFC #150                 Use of IPC Facilities                5 May 1971

[5ページ] IPC施設1971年5月5日のRFC#150使用

ABILITY TO FIND OUT ABOUT OUTSTANDING MESSAGES

傑出しているメッセージを見つける能力

      A process that is sending messages over a channel should be able
to find out how many of those messages have not yet been accepted by the
user process at the far end and whether or not this number can decrease.
Ideally, it should also be able to determine the number of bits left in
any partially accepted message, but the overhead necessary to implement
this on conventional systems may be too great to be tolerated.

チャンネルの上にメッセージを送る過程はそれらのメッセージのいくつが遠端におけるユーザ・プロセスでまだ受け入れられていないか、そして、この数が減少できるかどうか見つけることができるべきです。 また、理想的に、どんな部分的に受け入れられたメッセージにも残っているビットの数を測定できるべきですが、従来のシステムの上でこれを実行するのに必要なオーバーヘッドは許容できないくらいすばらしいかもしれません。

      The count returned can be useful both dynamically and for post
mortems. Used in debugging a remote process, it allows inputs on
normally concurrent channels to be presented one at a time and in any
given order. In this way one could, for example, verify that the same
results are produced regardless of the order in which the inputs arrive.

返されたカウントはダイナミックとポストmortemsの役に立つ場合があります。リモート過程をデバッグする際に使用されていて、それは、通常同時発生のチャンネルに関する入力が一度に一つ、提示されて、いずれでも命令されるのを許容します。 このように、例えば、人は、同じ結果が入力が到達する注文にかかわらず生まれることを確かめることができました。

      If there is a failure of a receiving process, this mechanism
allows a sending process to determine the last input accepted before the
process died. Even between operational processes it provides a user
managed way for the transmitting process to slow down and let the
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

メッセージを受け入れるときWAKEUPSを手に入れる能力

      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.

特定のチャンネルの上に送られて、遠端で受け入れられていないメッセージの数が指定された敷居の下まで下がるとき、上記に関連して、ユーザ・プロセスが警告されるのは、可能であるべきです。 したがって、20のメッセージがまだ傑出していると発見するとき、過程は、この数が5未満まで下がるまで日陰に入るのを選ぶことができます。 そうすることによって、過程は'バーストモード'に立候補できます。 むしろ、内外で15回コアについて交換されて、その都度1つのメッセージを送るのが許容されているより、それは、一度ロードされて、15のメッセージを送ります。 スループットのボトルネックが受信の過程にあるのでこれをするための刑罰が全くありません。 ローカルの過程のためのスワッピングコストが重要であるなら、この運転モードのかなりの経済利点があるかもしれません。

      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.

リモート過程が'近い'でチャンネルを死ぬか、または支給するなら、「非-渡」されたメッセージのカウントは凍るようになります。 受信の過程がこのタイプをwakeupに予想しているなら、カウントは必要な敷居に達していませんが、それはこのとき、1つを得るべきです。 過程はチャンネルで検死するようこのようにして注意を促されます。

                                                                [Page 6]

RFC #150                 Use of IPC Facilities                5 May 1971

[6ページ] IPC施設1971年5月5日のRFC#150使用

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.

過程は与えられた入力チャンネルの上に列に並ばせられたNth論理メッセージの状態を知ることができるべきです。 それ、aは、完全であるか否かに関係なく、それが利用可能であるかどうかと、それがどれくらい長いか、そして、それが何を含むかを最も最少に決定できるべきですか?

      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.

この施設で、プログラムはメッセージを受け入れる前に、一般的な準備をすることができます。 それは入力されて、それを処分できないので受け入れた苦しい立場に入れるのから何らかのエスケープを提供します。 例えば、メッセージを処理すると送られるもう2つのメッセージがもたらされるのが知られているなら、入力を受け入れる前に出力を発生させることができるという保証を得るのは有利です。

      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.

例えばチャンネルの端がテレタイプ接続をユーザ・プログラムとデバッギング・プログラムの間に動かしながら1つの過程から別の過程まで動かされる状況の下で、過程は、入力ストリームで先でスキャンするこの能力で未定の入力がそれのために本当に意味されるかどうかチェックできます。 それがそうなら、次に、通常、入力を受け入れるでしょう。さもなければ、最初に、チャンネルの端を別の受信の過程に動かさなければなりません。

      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.

入力を受け入れるのは、入力を処理できるという手頃な保証がない場合引き受けられないように重い責任として見なされるべきです。 非同期デザインの最初の規則の1つはできるだけ早く誤りを検出することです。 伝播されるなら、もつれている結果は、解くために絶望的であるかもしれません。

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.

過程は、いくつのメッセージによって与えられた入力チャンネルに処理されるのが残されるかを決定できるべきです。 2つの用途が容易に考えられます。 数個のチャンネルに関する未定の入力を考えて、過程は好みを運動させることができるべきです。 1つの決定は最も多くのメッセージが列に並ばせられている状態で最初に、チャンネルから入力を取ることであるかもしれません。 これには、以来リモート伝えることの過程が走ることができるかもしれないメッセージ・バッファを解放することによってスループットを増加させるという効果があるかもしれません。 別の可能性は受信の過程が送付の過程をいくつか管理するということであるかもしれません、そして、予備を入力に観測するとき、それは減速するようにその過程に言うかもしれません。

      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

[7ページ] IPC施設1971年5月5日のRFC#150使用

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.

過程が与えられたチャンネルに関するNメッセージを受け取ることができて、それらのメッセージが本当に利用可能であると言われて、ホスト・マシンの中でバッファリングされたなら、この要件はそれを述べます。 ユーザ・プロセスに約束されるなら、メッセージは神秘的に入手できなくなるべきではありません。 これがどう起こるかもしれないかに関する例はRFC60で例証されます。 そこでは、メッセージは、バッファ領域へのパニックの間、間違っているとして無効にされて、報告されます。 後で異種宿主に含まれたバックアップコピーをそれらから取り戻します。

ABILITY TO RECEIVE A WAKEUP WHEN INPUTS ARRIVE

入力が到着するときWAKEUPを受け取る能力

      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.

入力チャンネルの上に列に並ばせられたメッセージの数が規定値を超えているか、または最大値に達したとき、過程はwakeupを有効にすることができるべきです。 これで、プログラムは、バーストモードファッションによる入力を処理して、スワッピングコストを倹約します。 また、それは、入力が簡単な方法で結合されることを許可します。 例えば、何かができる前に2つの入力を必要とするなら、適切な中断を容易に発生させることができます。

      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.

最大の入力点数を受け取ったなら、同じ中断を発生させるべきです。 2つのケースが顕著です。 外国過程が、チャンネルを閉じて、したがって、より多くのメッセージを送らないか、またはシステムは何らかの入力を受け入れるまで、より多くのバッファを割り当てないでしょう。 このように、それが予期する状態を待つ意味が全くないと過程を知らすことができます。

ABILITY TO SPECIFY SPECIAL WAKEUPS

特別な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.

効率的に動こうとするとき、過程は任意に複雑なwakeup状態を指定できるべきです。 これは時期尚早なwakeupsの数を最小にするユーザの管理された方法を許容します。 それらが会われるときはいつも、主な過程が必要な状態と問題がないかどうかチェックする日常的にされた小さい低い頭上の中断を主な過程へのwakeupに指定するのを許容することによって、この一般性は恐らく最も容易に備えられます。

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

データ・ストリームの手段についての多くの議論がありました、そして、委員会の最中に、多くの混乱が発生しました。 それは私たちが、議論の現在のドメインの中にメッセージチャンネルの容量のどんなただ一つの基準もないと感じることです。 2つの完全に直交した概念を測定しなければなりません--メッセージの数がバッファリングした1と)ビットのコード化されたデータの数が表した2)。 それぞれに関連しているシステムオーバーヘッドは実現にたいへん依存しています、そして、したがって、どんな一般方程式も1の測定を急送できません。

                                                                [Page 8]

RFC #150                 Use of IPC Facilities                5 May 1971

[8ページ] IPC施設1971年5月5日のRFC#150使用

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.

もう片方に関して。 任意の仮定(例えばメッセージ限界は100ビットのバッファと等しい)をすることによって、システムは古い評価基準を満たすことができない新しいノードを除くという危険を冒します。

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.

ユーザ・プロセスがどんな与えられたチャンネルの最大の電流容量も知るのを可能にするシステムコールを提供するべきです。 すなわち、数、最大の噛み付いているカウントの1組と最大のメッセージが重要であるときに、これは報告されるべきです。

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.

チャンネルを使用する過程は与えられたチャンネルの容量の新しい領域を設定できるべきです。 できればシステムはこのバウンドを満たそうとするはずです。 課された実際の領域が少なくとも4人のさまざまな原因の規制を満たさなければならないことに注意されるべきです--地方の、そして、リモートなユーザ・プロセス、任意に高いバウンドを設定するのによる地方の、そして、リモートなシステム、それに会うことができるという保証を全くしません。 同様に、バッファリングされたメッセージが消費されるまで、いつも低いバウンドを迎えることができるというわけではありません。

      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

[9ページ] IPC施設1971年5月5日のRFC#150使用

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.

通常、ここで議論した操作のどれかを実行する権利はチャンネルを確立した工程で保有されます。 時には、その過程は代表として派遣されたパワーのいくつかを別の過程に移したがっているかもしれません、特に1つの過程が別のものを量産するかもしれなくて、新たに作成された過程にリソースを通過しなければならない環境で。

      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.

そのような再割当ての計画は任意に複雑になることができます。 1つは、例えば、個別にそれぞれの用法の種々相を割り当てて、次に、別々に再割当ての様々な権利を割り当てるかもしれません。 幸い、とても入念になるのがいつも必要であるというわけではない、多くの場合、以下の簡単な戦略が十分であることができると予想されます。 チャンネルを閉じる能力は排他的にチャンネルを確立した工程で保有されます。 過程が消え失せるとき、チャンネルがまだオープンであるなら、それはシステムによって自動的に閉じられます。 チャンネルの他のすべての用途がシステム制御の外に残っています。 チャンネルは名前によって知られています、そして、名前が与えられているすべての過程がチャンネルを利用するかもしれません。 それが、1つの過程だけがいかなる時も実際にそれを利用することであることを保障するのがユーザレベルコーディネートに残されます。

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'.

ほとんどのケースにおいて、チャンネル設立を全く単に扱うことができます。 過程はaで聴いて、チャンネルを指定したローカルシステムに知らせます。 それは正しい数に'ダイヤルする'最初のリモート過程に関連づけられます。 チャンネルが確立された後にだけ訪問者の識別は行われます。 間違った数の場合、チャンネルは終えることができます、そして、聴取は再開しました。 前設立されたチャンネルに届こうとする訪問者が'話中音'を得るでしょう。

      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

[10ページ] IPC施設1971年5月5日のRFC#150使用

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

RBK/TX2

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

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][マイケルBaudisch9/97によるオンラインRFCアーカイブへの]

                                                                [Page 11]

[11ページ]