RFC333 日本語訳
0333 Proposed experiment with a Message Switching Protocol. R.D.Bressler, D. Murphy, D.C. Walden. May 1972. (Format: TXT=62507 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Bob Bressler
Request for Comments: 333 MIT/Dynamic Modeling
NIC # 9926 Dan Murphy
Category: C9 (experimentation) BBN/TENEX
Obsoletes: 62 Dave Walden
Updates: none BBN/IMP
15 May 1972
ネットワークワーキンググループボブBresslerはコメントのために以下を要求します。 333 MIT/ダイナミックなモデルNIC#9926ダンマーフィーカテゴリ: C9(実験)BBN/TENEXは以下を時代遅れにします。 62 デーヴウォルデンUpdates: なにも、BBN/IMP1972年5月15日
A PROPOSED EXPERIMENT WITH A MESSAGE SWITCHING PROTOCOL
メッセージ交換プロトコルとの提案された実験
CONTENTS
コンテンツ
Introduction .................................................. 1 Some Background ............................................... 2 References .................................................... 3 MSP Specification ............................................. 4 Issue ......................................................... 8 Message Header ................................................ 10 Examples ...................................................... 15 TELNET ........................................................ 16 The Information Operator ...................................... 16 Unique Port Numbers ........................................... 20 Flow Chart .................................................... 23 MSP Variations ................................................ 25 Appendix ...................................................... 26
序論… 1 何らかのバックグラウンド… 2つの参照箇所… 3 MSP仕様… 4 発行します。 8メッセージヘッダー… 10の例… 15telnet… 16 問い合わせ係… 16 ユニークなポートナンバー… 20フローチャート… 23 MSP変化… 25付録… 26
INTRODUCTION
序論
A message switching protocol (MSP) is a system whose function is to switch messages among its ports.
メッセージ交換プロトコル(MSP)はポートの中でメッセージを切り換える機能がことであるシステムです。
For example, there is an implementation of an MSP in each Interface Message Processor. We believe that the effective utilization of communications networks by computer operating systems will require a better understanding of MSPs. In particular, we feel that Network Control Programs (NCPs), as they have been implemented on the ARPA Computer Network (ARPANET), do not adequately emphasize the communications aspects of networking -- i.e., they reflect a certain reluctance on the part of systems people to move away from what we term "the stream orientation". We propose, as an aside the network development using the current NCPs, to rethink the design of NCP- level software beginning with a consideration of MSPs.
例えば、MSPの実現が各Interface Message Processorにあります。 私たちは、コンピュータオペレーティングシステムによる通信網の有効な利用がMSPsの、より良い理解を必要とすると信じています。 特に、私たちは、それらがARPAコンピュータNetwork(アルパネット)で実行されたときNetwork Control Programs(NCP)が適切にネットワークのコミュニケーション局面を強調しないと感じます--システムの人々側の何から遠くに動くかためにある不本意を反映する、私たち、「流れのオリエンテーション」という用語。 私たちは、ネットワーク開発使用は別として現在のNCPとしてMSPsの考慮で始まるNCPレベルソフトウェアの設計を再考するよう提案します。
The thrust of this note is to sketch how one would organize the lowest level host-host protocol in the ARPANET around MSPs and how this organization would affect the implementation of host software.
この注意の突きはこの組織が1つがどうMSPsの周りのアルパネットで最も低い平らなホスト兼ホストプロトコルを組織化するだろうか、そして、どうホストソフトウェアの実現に影響するだろうかをスケッチすることです。
Bressler, et al. Experimentation [Page 1] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[1ページ]RFC333メッセージ交換プロトコル実験1972年5月
SOME BACKGROUND
何らかのバックグラウンド
Over the past several weeks there has been considerable informal discussion about the possibility of implementing, on an experimental basis, in several of the ARPA Network Host Computers, NCPs which follow a protocol based on the concept of message switching rather than the concept of line switching (see the parenthetical sentence in the first paragraph of page 6 of NIC document 8246, Host/Host Protocol for the ARPA Network). Party to this discussion have been Bob Bressler (MIT/Dynamic Modeling) Steve Crocker (ARPA), Will Crowther (BBN/IMP), Tom Knight (MIT/AI), Alex McKenzie (BBN/IMP), Bob Metcalfe (MIT/Dynamic Modeling), Dan Murphy (BBN/TENEX), Jon Postel (UCLA/NMC), and Dave Walden (BBN/IMP).
過去数週間、実験的にアーパネットの数個でHostコンピュータ(回線切換(6NICページの第一節の挿入句の文が8246を記録するのを見てください、アーパネットのためのHost/ホストプロトコル)の概念よりむしろメッセージ交換の概念に基づくプロトコルに従うNCP)を実行する可能性のかなりの四角ばらない意見の交換があります。 この議論へのパーティは、ボブBressler(MIT/ダイナミックなModeling)スティーブ・クロッカー(ARPA)と、ウィル・クラウザー(BBN/IMP)と、トムKnight(MIT/AI)と、アレックス・マッケンジー(BBN/IMP)と、ボブメトカルフェ(MIT/ダイナミックなModeling)と、ダン・マーフィー(BBN/TENEX)と、ジョン・ポステル(UCLA/NMC)と、デーヴ・ウォルデン(BBN/IMP)です。
Several interesting points and conclusions have been made during this discussion:
この議論の間、おもしろい数ポイントと結論をしています:
1. Bressler has implemented a message switched interprocess
communication system for the Dynamic Modeling PDP-10 and has
extended it so it could be used for interprocess communication
between processes in the Dynamic Modeling PDP-10 and the AI
PDP-10. He reports that it is something like an order of
magnitude smaller than his NCP.
1. Bresslerは、Dynamic Modeling PDP-10のメッセージの切り換えられたプロセス間通信システムを導入して、Dynamic Modeling PDP-10とAI PDP-10の過程の間のプロセス間通信にそれを使用できたようにそれを広げました。 彼は、それが彼のNCPよりわずかな桁に似ていると報告します。
2. Murphy has noted that a Host/Host protocol based on message
switching could be implemented experimentally and run in
parallel with the real Host/Host protocol using some of the
links set aside for experimentation. Further, Murphy has noted
that if this experimental message switching protocol were
implemented in TENEX, a number of (TENEX) sites could easily
participate in the experiment.
2. マーフィーは、メッセージ交換に基づくHost/ホストプロトコルが実験的に実行されて、傍らに課せられたリンクのいくつかを使用する本当のHost/ホストプロトコルに平行に実験に立候補できたことに注意しました。 さらに、マーフィーは、この実験メッセージ交換プロトコルがTENEXで実行されるなら、多くの(TENEX)サイトが容易に実験に参加できることに注意しました。
3. It is the consensus of the discussants that Bressler should
take a crack at specifying a message switching protocol* and
that if this specification looked relatively easy to implement,
a serious attempt should be made by Murphy and Bressler to find
the resources to implement the experimental protocol on the two
BBN TENEX and the MIT Dynamic Modeling and AI machines.
3. それはBresslerがメッセージ交換プロトコル*を指定することにおけるひびを飲むはずであり、この仕様が実行するのが比較的簡単に見えるなら、重大な試みが2BBN TENEX、MIT Dynamic Modeling、およびAIマシンの上で実験プロトコルを実行するためにリソースを見つけるのがマーフィーとBresslerによってされるという公式の討論会のコンセンサスです。
4. MSP was chosen as the acronym for Message Switching Protocol,
and links 192-195 were reserved for use in an MSP experiment.
4. MSPはMessage Switchingプロトコルのための頭文字語として選ばれました、そして、リンク192-195はMSP実験における使用のために予約されました。
------------- *This note fulfills any obligation Bressler may have incurred to produce an MSP specification.
------------- *この注意はBresslerがMSP仕様を作り出すために被ったどんな義務も果たします。
Bressler, et al. Experimentation [Page 2] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[2ページ]RFC333メッセージ交換プロトコル実験1972年5月
We solicit comments and suggestions from the Network Working Group with regard to this experiment. However, although we will very much appreciate comments and suggestions, because this is a limited experiment and not an attempt to specify a protocol to supersede the present Host/Host protocol for the ARPA Network, we may arbitrarily reject suggestions.
私たちはこの実験に関してNetwork作業部会からコメントと提案に請求します。 しかしながら、コメントと提案をたいへんお願いするでしょうが、これがアーパネットのために現在のHost/ホストプロトコルに取って代わるためにプロトコルを指定する試みではなく、限られた実験であるので、私たちは任意に提案を拒絶するかもしれません。
REFERENCES
参照
Familiarly with the following references will be helpful to the reading of the rest of this note.
この注意の残りの読書に以下の参照でなれなれしく役立つでしょう。
1) NIC document 8246, HOST/HOST PROTOCOL FOR THE ARPA NETWORK
1) HOST/HOST PROTOCOL FOR THE ARPA NETWORK、NICは8246を記録します。
2) NIC document 9348 on the Telnet Protocol
2) NICはテルネット・プロトコルに9348を記録します。
3) NIC document 7101, OFFICIAL INITIAL CONNECTION PROTOCOL,
DOCUMENT # 2
3) NICドキュメント7101、OFFICIAL INITIAL CONNECTION PROTOCOL、DOCUMENT#2
4) a system of interprocess communication in a resource sharing
computer network, CACM, April, 1972.
4) 1972年4月のリソース・シェアリングコンピュータネットワーク、CACMのプロセス間通信のシステム。
Reference 4 is a revision of RFC 62. We strongly suggest the reader be familiar with reference 4 before he attempts to read the present RFC; a reprint of reference 4 is attached as an appendix.
参照4はRFC62の改正です。 私たちは、彼が、現在のRFCを読むのを試みる前に読者が参照4に詳しいと強く示唆します。 参照4の増刷は付録として付けられています。
Bressler, et al. Experimentation [Page 3] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[3ページ]RFC333メッセージ交換プロトコル実験1972年5月
MSP SPECIFICATION
MSP仕様
Our MSP is essentially a generalization of the interprocess communication system outlined in Section 3 of the fourth reference. (Henceforth, if we are required to mention the interprocess communication system presented in Section 3 of reference 4, we shall call it "the IPC".) For two processes to communicate using the MSP, the process desiring to send must in some sense execute a SEND and the process desiring to receive must in some sense execute a RECEIVE. The SEND and RECEIVE, in effect, rendezvous somewhere and transmission is allowed to take place. With the RECEIVE are specified (among other things) a FROM-TO-PORT-ID, a TO-PORT-ID, and a RENDEZVOUS HOST. With SEND are specified a from-port-id, a to-port- id, a rendezvous Host, and (possibly) some data to be transmitted. Using SEND and RECEIVE, sending a message from a SENDER PROCESS to a RECEIVER PROCESS takes place as follows. The sender process executes a SEND which causes an OUT-MESSAGE plus the specified data to be transmitted to the Host specified as the rendezvous Host in the SEND. Concurrently (although not necessarily simultaneously)the receiver process executes a RECEIVE which causes an IN-MESSAGE to be sent to the Host specified as the rendezvous Host in the RECEIVE. At the rendezvous Host, OUT-messages and IN-messages are entered in a table called the RENDEZVOUS TABLE. When an OUT-message and an IN-message are detected with matching to-port-id, from-port-id, and rendezvous Host, three things are done: 1) the OUT-message plus the data is forwarded to the Host which was the source of the IN-message, 2) the IN-message is forwarded to the Host which was the source of the OUT- message, and 3) the IN-message and OUT-message plus the data are deleted from the rendezvous table in the rendezvous Host.
私たちのMSPは本質的には4番目の参照のセクション3に概説されたプロセス間通信システムの一般化です。 (今後は、参照4のセクション3に提示されたプロセス間通信システムについて言及しなければならないなら、私たちは、それを「IPC」と呼ぶつもりです。) 2つの過程がMSPを使用することで交信するために、送る過程の望みは何らかの意味でSENDを実行しなければなりません、そして、受ける過程の望みは何らかの意味でRECEIVEを実行しなければなりません。 有効なSENDとRECEIVEはどこかで集合します、そして、トランスミッションは行われることができます。 RECEIVEと共に、指定された(特に)FROM-TO-PORT-ID(ID)TO-PORT-、およびRENDEZVOUS HOSTがある、SENDと共に指定される、ポートイドです、ポートイドへのa、aは伝えられるためにHost、および(ことによると)いくつかのデータを集合させます。 SENDとRECEIVEを使用して、SENDER PROCESSからRECEIVER PROCESSにメッセージを送るのは以下の通り行われます。 送付者の過程はランデブーHostとしてSENDで指定されたHostにOUT-MESSAGEと指定されたデータを送らせるSENDを実行します。 同時に(必ず同時であるというわけではありませんが)、受信機の過程はランデブーHostとしてRECEIVEで指定されたHostにIN-MESSAGEを送らせるRECEIVEを実行します。 ランデブーHostでは、OUT-メッセージとIN-メッセージはRENDEZVOUS TABLEと呼ばれるテーブルに入力されます。 OUT-メッセージとIN-メッセージがマッチングがポートイドで、ポートイドで検出されて、Hostを集合させるとき、3つのことをします: 1) そのうえ、IN-メッセージの源、2歳であったHostにデータを転送するというOUT-メッセージ) ランデブーHostにおけるランデブーテーブルから削除されて、OUTメッセージ、および3の)源がIN-メッセージとOUT-メッセージであり、データがメッセージであったHostにIN-メッセージを転送します。
The process is greatly simplified if the rendezvous Host is also either the send Host or receive Host. Specific algorithms enumerating these sequences appear later in this note.
過程がまた、ランデブーHostがどちらかなら大いに簡素化される、Hostを送るか、またはHostを受けてください。 これらの系列を列挙する特定のアルゴリズムが後でこの注意に現れます。
To clarify the basic concepts, let us look at a case involving three Hosts, to which we shall give the names SND, RCV, and RNDZ. At Host SND, process S is doing a send, and at Host RCV, process R is doing a receive. Both specify rendezvous at Host RNDZ.
基本概念をはっきりさせるために、ケースが3Hostsにかかわるのを見ましょう。(私たちはHostsに名前のSND、RCV、およびRNDZにかけるつもりです)。 Host SND、Sがaをしている過程では、発信してください、そして、Host RCV、Rがaをしている過程では、受信してください。 両方がHost RNDZでランデブーを指定します。
Bressler, et al. Experimentation [Page 4] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[4ページ]RFC333メッセージ交換プロトコル実験1972年5月
+--------------------+ +----------+ +--------------------+ |HOST SND | | | |HOST RCV | | | | | | | | | | | | | | (PROCESS) | +----------+ | | | ( S ) | HOST | | | \ | RNDZ | (PROCESS) | | [DATA]| | ( R ) | +--------------------+ +--------------------+
+--------------------+ +----------+ +--------------------+ |ホストSND| | | |ホストRCV| | | | | | | | | | | | | | (過程) | +----------+ | | | (S) | ホスト| | | \ | RNDZ| (過程) | | [データ]| | (R) | +--------------------+ +--------------------+
Process S now executes a SEND with
Sが現在SENDを実行する過程
from-port-id = S, to-port-id = R, and rendezvous-Host = RNDZ.
ポートイドから、ポートイドへの=SはR、およびランデブーホスト=RNDZと等しいです。
Host SND then creates a table entry in its rendezvous table.
そして、ホストSNDはランデブーテーブルでテーブル項目を作成します。
+-----------------------------------+ |HOST SND MSP _ _ _ | | ------------->|_ _ _| | | / ^ |_ _ _| <-|-------RENDEZVOUS | / | |_ _ _| | TABLE |(PROCESS) | | |( S ) +-- SEND (from=S to=R; rend=RNDZ) | \ | | [DATA] | +-----------------------------------+
+-----------------------------------+ |ホストSND MSP_ _ _| | ------------->|_ _ _| | | / ^ |_ _ _| <、-、|、-、-、-、-、-、--ランデブー| / | |_ _ _| | テーブル|(過程) | | |(S) +--発信してください(=Sから=Rまで; =RNDZを引き裂いてください)。| \ | | [データ]| +-----------------------------------+
Host SND now sends an "OUT" message with S's data to Host RNDZ.
ホストSNDは現在、Sのデータがある“OUT"メッセージをホストRNDZに送ります。
HOST SND HOST RNDZ
+------------+ +---------------------------+
| MSP| "OUT" + DATA |MSP _____ RENDEZVOUS |
| |--------------------|--> |_ _ _| TABLE |
| | from=S; to=R | \ |_ _ _| |
| | | \ |_ _ _| |
+------------+ | \ __ |
| \---------->| | DATA |
| |__|BUFFER |
| |
+---------------------------+
ホストSNDホストRNDZ+------------+ +---------------------------+ | MSP| "OUT"+データ|MSP_____ ランデブー| | |--------------------|--> |_ _ _| テーブル| | | =Sから。 Rと等しいように| \ |_ _ _| | | | | \ |_ _ _| | +------------+ | \ __ | | \---------->|、| データ| | |__|バッファ| | | +---------------------------+
Concurrently process R at Host RCV executes a RECEIVE with from- port-id = S, to-port-id = R, and rendezvous-Host = RNDZ. As above, Host RCV creates a table entry in its rendezvous table and sends an "IN" message to Host RNDZ (see following figure).
Host RCVの同時に加工処理したRがRECEIVEを実行する、-、ポートイドへのポートイド=SはR、およびランデブーホスト=RNDZと等しいです。 同じくらい上では、Host RCVはランデブーテーブルでテーブル項目を作成して、「IN」メッセージをホストRNDZに送ります(次の事柄が計算されるのを見てください)。
Bressler, et al. Experimentation [Page 5] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[5ページ]RFC333メッセージ交換プロトコル実験1972年5月
(Don't panic now about buffering in an intermediate Host. The time to panic is afer you've read and understood the rest of our arguments.)
(今、中間的Hostでのバッファリングに関して慌てないでください。 慌てるのが、aferである時に、あなたは、私たちの議論の残りを読んで、理解していました。)
HOST RNDZ HOST RCV
+------------------------+ +-----------------------+
| MSP | | MSP |
| TABLE _____ | | _____ TABLE |
| +-|_ _ _| | "IN" | |_ _ _| |
| | |_ _ _|<-|----------|_ _ _|<-\ |RECEIVE
| | |_ _ _| | | |_ _ _| \ <--|(from=S
| | | | \ | to=R
| _V_ | | \ | rend=RNDZ)
| BUFFER | | | | (PROCESS) |
| |___| | | ( R ) |
+------------------------+ +-----------------------+
ホストRNDZホストRCV+------------------------+ +-----------------------+ | MSP| | MSP| | テーブル_____ | | _____ テーブル| | +-|_ _ _| | 「IN」| |_ _ _| | | | |_ _ _| <、-、|、-、-、-、-、-、-、-、-、--、|_ _ _| <、-\ |受信してください。| | |_ _ _| | | |_ _ _| \<--|(=S| | | | \から| =Rに| _V_ | | \ |=RNDZを引き裂いてください) | バッファ| | | | (過程) | | |___| | | (R) | +------------------------+ +-----------------------+
Host RNDZ now notices that the "OUT" from Host SND and the "IN" from R at RCV match one another and thus Host RNDZ takes three actions:
ホストRNDZは、今ホストSNDからの“OUT"とRCVのRからの「IN」がお互いに合っているのに気付きます、そして、その結果、ホストRNDZは3つの行動を取ります:
1. Sends an "IN to Host SND (from-port-id = S, to-port-id = R,
rendezvous-Host = RNDZ).
1. 「Host SND(ランデブーホスト=RNDZ、ポートイドから、ポートイドへの=SはRと等しい)へのIN」を送ります。
2. Sends an "OUT" and the buffered data to Host RCV (from-port-id
= S, to-port-id = R, rendezvous-Host =RNDZ)
2. “OUT"とバッファリングされたデータをホストRCVに送ります。(ランデブーホスト=RNDZ、ポートイドから、ポートイドへの=SはRと等しいです)
3. Clears the entry from its table.
3. テーブルからエントリーをクリアします。
HOST SND HOST RCV +------------------+ +------------+ +-------------+ | | | TABLE | | | | TABLE ___ | "IN" | ___ | "OUT" | ___ TABLE| | |___| | | |___| | + DATA | |_ _| | | |___|<---|--------|---|___|----|---------|->|_ _| | | |___| | | |___| | | |_ _| | | ( S ) | +------------+ | ( R )| | | HOST RNDZ | | +------------------+ +-------------+
ホストSNDホストRCV+------------------+ +------------+ +-------------+ | | | テーブル| | | | テーブル___ | 「IN」| ___ | "OUT"| ___ テーブル| | |___| | | |___| | + データ| |_ _| | | |___| <、-、--、|、-、-、-、-、-、-、--、|、-、--、|___|、-、-、--、|、-、-、-、-、-、-、-、--、|、-、>|_ _| | | |___| | | |___| | | |_ _| | | (S) | +------------+ | (R)| | | ホストRNDZ| | +------------------+ +-------------+
Host RCV gets the "OUT" and DATA and finds the matching entry in its table. It gives the DATA to process R and clears the entry from its table.
ホストRCVは“OUT"とデータを手に入れて、テーブルで合っているエントリーを見つけます。 それは、Rを処理するためにDATAに与えて、テーブルからエントリーをクリアします。
Host SND gets an "IN" which matches an entry in his table and clears that entry. This message serves as a combined acknowledgement and go ahead which can be passed along to process S.
ホストSNDは彼のテーブルでエントリーに合って、そのエントリーをクリアする「IN」を得ます。 aがSを処理するために回すことができる承認と先の碁を結合したので、このメッセージは役立ちます。
The transmission is now complete.
トランスミッションは現在、完全です。
Bressler, et al. Experimentation [Page 6] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[6ページ]RFC333メッセージ交換プロトコル実験1972年5月
By both, one, or neither of the sender and receiver processes specifying a remote rendezvous Host, four important different kinds of transmissions can be made to take place. These are illustrated in the following four figures. In the figures crossed or parallel dotted lines are used to indicate rendezvous. The site of the "crossed rendezvous" is the important difference between types of transmission illustrated in figures. Circles indicate processes. Rectangles are rendezvous tables.
リモートランデブーHostを指定する送付者と受信機の過程の両方、1、またはどちらもで、行われるのを4つの重要な異種の送信をすることができます。 これらは以下の4つの数字で例証されます。 数字では、交差しているか平行な点線は、ランデブーを示すのに使用されます。 「交差しているランデブー」のサイトは数字で例証されたトランスミッションのタイプの重要な違いです。 円は過程を示します。 長方形はランデブーテーブルです。
The figures also show "(IN)" and "(OUT)" messages being passed into the processes. The parentheses are used to indicate that the "IN" and "OUT" are only CONCEPTUALLY passed into the processes. What actually happens is implementation dependent. The process might be awakened and be given no further information if it blocked when issuing the SEND or RECEIVE. The process might be interrupted and passed some information such as the to-port-id from the IN or the from-port-id of the OUT. The process might actually be passed the complete IN or OUT message.
また、数字は、「(IN)」と"(OUT)"メッセージが過程に通過されるのを示します。 括弧は、「IN」と“OUT"が概念的に過程に渡されるだけであるのを示すのに使用されます。 何が実際に起こるかは、実現に依存しています。 過程は、さらなる情報の目を覚まされて、それはSENDを発行しながら、いつを妨げたか、そして、与えられたノーのRECEIVEであるかもしれません。 過程は中断されて、INからのポートイドかOUTのポートイドの何らかの情報を通過されるかもしれません。 完全なINかOUTメッセージが実際に過程に通り過ぎられるかもしれません。
------ _________ ------
( ) | | ( )
( ) SEND | | RECEIVE ( )
( )------>|--+ +---|<--------( )
( ) | \/ | ( )
( ) (IN) | /\ | (OUT) ( )
( )<------|--+ +--|-------->( )
(______) |_________| +DATA (______)
------ _________ ------ ( ) | | ( ) ( ) 発信してください。| | ( )( )を受けてください。------>|、--+ +---| <、-、-、-、-、-、-、--( ) ( ) | \/ | ( ) ( ) (中) | /\ | (OUT) ( ) ( )<、-、-、-、-、--、|、--+ +--|-------->( ) (______) |_________| + データ(______)
|<------------- Host K ------------------>|
| <。------------- ホストK------------------>|
A Rendezvous at the Sender's Host
送付者のホストのランデブー
---- _______ ______ ----
( ) | | | | ( )
( ) SEND | | IN | | RECEIVE( )
( )------>|-+ +--|<------------|------|<-------( )
( ) | \/ | | | ( )
( ) (IN) | /\ | OUT+DATA | | (OUT) ( )
( )<------|-+ +--|------------>|------|------->( )
(____) |_______| |______| +DATA (____)
---- _______ ______ ---- ( ) | | | | ( ) ( ) 発信してください。| | IN| | ( )( )を受けてください。------>|、-+ +--| <、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-、-、--、| <、-、-、-、-、-、--( ) ( ) | \/ | | | ( ) ( ) (中) | /\ | アウト+データ| | (OUT) ( ) ( )<、-、-、-、-、--、|、-+ +--|、-、-、-、-、-、-、-、-、-、-、--、>|、-、-、-、-、--、|、-、-、-、-、-、-->( ) (____) |_______| |______| + データ(____)
|<---- Host K ------>|<-- Network-->|<----- Host L ----->|
| <。---- ホストK------>| <-- ネットワーク-->| <、-、-、-、-- ホストL----->|
A Rendezvous at the Sender's Host
送付者のホストのランデブー
Bressler, et al. Experimentation [Page 7] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[7ページ]RFC333メッセージ交換プロトコル実験1972年5月
---- ______ _______ ----
( ) | | | | ( )
( ) SEND | | OUT+DATA | | RECEIVE( )
( )------>|------|------------->|-+ +--|<-------( )
( ) | | | \/ | ( )
( ) (IN) | | IN | /\ | (OUT) ( )
( )<------|------|<-------------|-+ +--|------->( )
( ) | | | | +DATA ( )
(____) |______| |______ | (____)
---- ______ _______ ---- ( ) | | | | ( ) ( ) 発信してください。| | アウト+データ| | ( )( )を受けてください。------>|、-、-、-、-、--、|、-、-、-、-、-、-、-、-、-、-、-、--、>|、-+ +--| <、-、-、-、-、-、--( ) ( ) | | | \/ | ( ) ( ) (中) | | IN| /\ | (OUT) ( ) ( )<、-、-、-、-、--、|、-、-、-、-、--、| <、-、-、-、-、-、-、-、-、-、-、-、--、|、-+ +--|------->( ) ( ) | | | | + データ( )(____)|______| |______ | (____)
|<---- Host K ----->|<-- Network-->|<----- Host L ----->|
| <。---- ホストK----->| <-- ネットワーク-->| <、-、-、-、-- ホストL----->|
A Rendezvous at the Receiver's Host
受信機のホストのランデブー
---- ______ _______ ______ ---- ( ) | | | | | | ( ) ( ) SEND | | OUT+DATA | | IN | |RECEIVE( ) ( )------>|------|--------->|-+ +--|<---------|------|<------( ) ( ) | | | \/ | | | ( ) ( ) (IN) | | IN | /\ |OUT+DATA | | (OUT) ( ) ( )<------|------|<---------|-+ +--|--------->|------|------>( ) ( ) | | | | | | +DATA ( ) (____) |______| |______ | |______| (____)
---- ______ _______ ______ ---- ( ) | | | | | | ( ) ( ) 発信してください。| | アウト+データ| | IN| |( )( )を受けてください。------>|、-、-、-、-、--、|、-、-、-、-、-、-、-、--、>|、-+ +--| <、-、-、-、-、-、-、-、--、|、-、-、-、-、--、| <、-、-、-、-、--( ) ( ) | | | \/ | | | ( ) ( ) (中) | | IN| /\ |アウト+データ| | (OUT) ( ) ( )<、-、-、-、-、--、|、-、-、-、-、--、| <、-、-、-、-、-、-、-、--、|、-+ +--|、-、-、-、-、-、-、-、--、>|、-、-、-、-、--、|、-、-、-、-、-->( ) ( ) | | | | | | + データ( )(____)|______| |______ | |______| (____)
|<---- Host K ----->|<--Net-->|<-Host->|<--Net-->|<----- Host L ----->|
M
| <。---- ホストK----->| <--ネット-->| <、-ホスト>| <--ネット-->| <、-、-、-、-- ホストL----->| M
A Rendezvous at an Intermediate Host
中間的ホストのランデブー
ISSUES
問題
Timeouts.
タイムアウト。
The issue of timeouts is a very sticky one. A coherent system of timeouts simplifies everything and does away with races. However, many Hosts are unwilling or unable to use timeouts, especially timeouts whose duration is specified.
タイムアウトの問題は非常にねばねばするものです。 タイムアウトのコヒーレント方式は、すべてを簡素化して、レースを片づけます。 しかしながら、多くのHostsは不本意であるか、またはタイムアウト、特に持続時間が指定されるタイムアウトを使用できません。
Without these timeouts there is probably a need for a negative acknowledgment which goes back to the source of an IN or OUT when one is timed out. However, this now leads to races.
これらのタイムアウトがなければ、1つが外で調節されているときINかOUTの源に戻る否定応答の必要がたぶんあります。 しかしながら、これは現在、レースに通じます。
A negative acknowledgment (which we will refer to as a FLUSH message) could be employed by a Host to mean:
Hostは、以下を意味するのに、否定応答(私たちがFLUSHメッセージを呼ぶつもりである)を使うことができました。
Bressler, et al. Experimentation [Page 8] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[8ページ]RFC333メッセージ交換プロトコル実験1972年5月
1. I have no room in my table
1. 私はテーブルに余地を全く持っていません。
2. I have no more available buffer space or
2. または私にはそれ以上の利用可能なバッファ領域がない。
3. I no longer wish to retain the table entry/buffer.
3. もうテーブル項目/バッファを保有したいと思いません。
In general, we believe that a Host should be allowed to throw away
an IN or OUT+data whenever it is no longer convenient for the Host
to hold the messages. This can be immediately on the arrival of a
message; for instance, if the Host does not want to buffer traffic
for which it does not have a user buffer. In lieu of timeouts,
any time a process issues a SEND or RECEIVE, it can take it back
by issuing the matching RECEIVE or SEND.
一般に、私たちは、Hostには、メッセージを保持するのがもう都合がよくないときはいつも、HostがINかOUT+データを無駄にするはずであることができると信じています。 すぐメッセージの到着にはこれがあることができます。 例えば、Hostがそれがそうしない交通をバッファリングしたいと思わないなら、ユーザバッファを持ってください。 タイムアウトの代わりに、いつでも、過程はSENDかRECEIVEを発行します、とそれは合っているRECEIVEかSENDを発行することによって、分かり返すことができます。
Blocking the Process After a Send or Receive.
加工処理した後aを妨げて、発信するか、または受信してください。
This is a question which is left implementation dependent. In
general, we do not think it is a good idea to block the process
after a SEND since it may want to do another to another port or
even do a RECEIVE. In fact, we see nothing inherently wrong with
a process doing two or more SENDs to the same port as long as the
communicating processes know what they are doing. Of course, some
communicating processes will prohibit several simultaneous
messages being in transit between the same ports, for instance the
TELNETs may well prohibit this. However, for reasons of
increasing bandwidth, etc., two processes may well want several
simultaneous messages. In this case we think it is up to the
processes to worry about the sequencing of messages; however, we
refer users desiring their processes to take a care of message
sequencing to the method used in the IMP/Very Distant Host
interface which is documented in Appendix F of BBN Report 1822.
これは実現に依存していた状態で残される問題です。 一般に、それが別のポートに別のことをしたいか、またはRECEIVEをしたがってさえいるかもしれなくて、私たちは、SENDの後に過程を妨げるのが、名案であると思いません。 事実上、私たちは、本来交信が処理される限り、同じポートに2SENDsをする過程に具合が悪いものは何かも、彼らが何をしているかを知らないのを見ます。 もちろん、いくつかの交信の過程がいくつかのトランジット同じポートの間で中であることの同時のメッセージを禁止するでしょう、例えば、TELNETsはたぶんこれを禁止するでしょう。 しかしながら、増加する帯域幅などの理由で、2つの過程がたぶんいくつかの同時のメッセージを必要とするでしょう。 この場合、私たちは、メッセージの配列を心配するのが過程まで達していると思います。 しかしながら、私たちはBBN Report1822のAppendix Fに記録されるIMP/まさしくそのDistant Hostインタフェースで使用される方法へのメッセージ配列の世話をするために彼らの過程を望んでいるユーザを参照します。
Message Buffering
メッセージバッファリング
A few points are worth mentioning with regard to message
buffering. First, most OUTs will probably be accompanied by data.
Therefore, in general, since the receiver process may be swapped
out, the receiver Host monitor must be prepared to buffer some
data somewhere. To minimize the amount of buffering needed, the
monitor could refuse further traffic from the IMP until the
earlier traffic from the IMP has been written on a disk or drum.
Or the monitor could have a small number of buffers in the monitor
area of memory which it fills as traffic comes from the IMP, and
which are swapped with buffers claimed earlier by the receiver
processes as the receiver processes are swapped in. Note that the
buffers may be less than the maximum subnet message size in length
if the RECEIVEs never specify a longer message length -- of
course, this can be enforced. Finally note that the message size,
数ポイントはメッセージバッファリングに関して言及する価値があります。 まず最初に、ほとんどのOUTsがたぶんデータによって同伴されるでしょう。 したがって、一般に、受信機の過程が外で交換されるかもしれないので、受信機Hostモニターはどこかでいくつかのデータをバッファリングする用意ができていなければなりません。 必要な状態でバッファリングの量を最小にするために、IMPからの以前の交通がディスクかドラムに書かれるまで、モニターはIMPからさらなる交通を拒否できました。 または、モニターは交通がIMPから来るときそれがいっぱいにするメモリのモニター領域の受信機の過程が交換されるので中のバッファが、より早く受信機工程で要求されていた状態で交換される少ない数のバッファを持つことができました。 バッファが最大のサブネットメッセージサイズ長さにおける以下はRECEIVEsであるなら、より長いメッセージ長を決して指定しません--もちろん、これを実施できるということであるかもしれないことに注意してください。 最終的にそれに注意してください、メッセージサイズ
Bressler, et al. Experimentation [Page 9] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[9ページ]RFC333メッセージ交換プロトコル実験1972年5月
receive-port-id, etc. are available in the first 144 bits which
come in from the IMP. It might be useful to read this before
deciding into which buffer to read the rest of the message.
ポートイドを受け取ってください、そして、などはIMPから入る最初の144ビットで利用可能です。 メッセージの残りを読むとどのバッファの中に決めるかの前にこれを読むのは役に立つかもしれません。
Positive Acknowledgments
肯定応答
Built into the system is a certain form of acknowledgment. The
information is always available as to when the receiving process
has done a RECEIVE. The sending Host is assured of receiving an
"IN" when the receive call is issued.
システムが組み込まれているのは、ある形式の承認です。 情報はいつも受信の過程がRECEIVEをした時に関して利用可能です。 呼び出しを受けてください。発信しているHostがいつを「コネ」受けるかを保証される、発行されます。
Further forms of acknowledgment and validation can be implemented
at the first user level, and advanced protocols will probably
develop a library of such routines.
最初のユーザレベルでさらなる形式の承認と合法化を実行できます、そして、高度なプロトコルはたぶんそのようなルーチンのライブラリを発展させるでしょう。
MESSAGE HEADER
メッセージヘッダー
The following section deals with the specific format of Host to
Host messages and algorithms describing the proper response to a
given message.
以下のセクションは適切な応答を与えられたメッセージに説明するHostメッセージとアルゴリズムにHostの特定の形式に対処します。
Each message begins with a 144 bit header containing the following
fields:
144ビットのヘッダーが以下の分野を含んでいて、各メッセージは始まります:
1. HOST-TO-IMP leader (32 bits) as specified in BBN Reports 1822
1. 指定されるとしてのBBN Reports1822のHOST-TO-IMPリーダー(32ビット)
2. to port ID (i.e., the id of the port receiving the message) (24
bits)
2. ID(すなわち、メッセージを受け取るポートのイド)を移植するために(24ビット)
3. MSG TYPE (8 bits) IN, OUT, FLUSH, etc.
3. MSG TYPE(8ビット)IN、OUT、FLUSHなど
4. from port ID (i.e., id or the port sending the message) (24
bits)
4. ポートID(メッセージを送るすなわち、イドかポート)から(24ビット)
5. initiating Host's table position (8 bits) see below.
5. Hostのテーブル位置(8ビット)を開始して、以下を見てください。
6. HOST "sourcing" this message (8 bits) see below.
6. このメッセージ(8ビット)の「出典を明示する」HOSTが以下を見ます。
7. RENDEZVOUS HOST (8 bits)
7. ランデブーホスト(8ビット)
8. bit count of data (16 bits)
8. データの噛み付いているカウント(16ビット)
The header format has been arranged so that no data item will cross a word boundary on machines with 16, 32, and 36-bit words, except where the size of the item is greater than the word size. The actual arrangement of bytes within words is shown in the following figures for these three word sizes. For the benefit of 36-bit Hosts, bytes 4 and 13 (numbering from 0) are unused. The 2 and 3-byte items do not
ヘッダー形式はどんなデータ項目も16、32があるマシンの上の語境界、および36ビットの単語に交差しないように、アレンジされました、項目のサイズが語長より大きいところを除いて。 単語の中のバイトの実際のアレンジメントはこれらの3つの語長のために以下の数字に示されます。 36ビットのHostsの利益のために、バイト4と13(0から、付番します)は未使用です。 2と3バイトの項目はそうしません。
Bressler, et al. Experimentation [Page 10] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[10ページ]RFC333メッセージ交換プロトコル実験1972年5月
cross word boundaries except for the port ID's on the 16 bit machines. This attention to packing and unpacking ease was given both for general convenience, and in particular because Hosts may wish to examine the header at interrupt level to determine where the rest of the message should go.
16ビットのマシンの上のポートIDのもの以外の語境界に交差してください。 容易さを梱包して、アンパックすることに関するこの注意は、一般的な便宜のために両方を与えて、Hostsがメッセージの残りがどこに行くべきであるかを決定するために割り込みレベルでヘッダーを調べたがっているかもしれないので、特に与えました。
+-------------+-------------+ 0 | HOST/IMP | DESTINATION | | FLAGS | | +-------------+-------------+ 1 | LINK | /////////// | | | /////////// | +-------------+-------------+ 2 | /////////// | | | /////////// | | +-------------+ | 3 | TO PORT ID | | | +-------------+-------------+ 4 | MESSAGE | | | TYPE | | +-------------+ | 5 | FROM PORT ID | | | +-------------+-------------+ 6 | TABLE | /////////// | | POSITION | /////////// | +-------------+-------------+ 7 | SOURCE | RENDEZVOUS | | HOST | HOST | +-------------+-------------+ 8 | BIT COUNT | | | +-------------+-------------+ | | 9 | DATA | // // | | +-------------+-------------+
+-------------+-------------+ 0 | ホスト/悪童| 目的地| | 旗| | +-------------+-------------+ 1 | リンク| /////////// | | | /////////// | +-------------+-------------+ 2 | /////////// | | | /////////// | | +-------------+ | 3 | IDを移植するために| | | +-------------+-------------+ 4 | メッセージ| | | タイプ| | +-------------+ | 5 | PORT IDから| | | +-------------+-------------+ 6 | テーブル| /////////// | | 位置| /////////// | +-------------+-------------+ 7 | ソース| ランデブー| | ホスト| ホスト| +-------------+-------------+ 8 | ビットカウント| | | +-------------+-------------+ | | 9 | データ| // // | | +-------------+-------------+
16-bit Host Format
16ビットのホスト形式
+-------------+
| | ////////// = unused
| | //////////
+-------------+
8 bits
+-------------+ | | //////////=未使用です。| | ////////// +-------------+ 8ビット
Bressler, et al. Experimentation [Page 11] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[11ページ]RFC333メッセージ交換プロトコル実験1972年5月
0 8 16 24 32 36 +-------------+-------------+-------------+-------------+------+ 0 | HOST/IMP | FOREIGN | LINK | ////////////////// | | FLAGS | HOST | | ////////////////// | +------+------+-------------+-------------+-------+-----+------+ 1 | //// | TO PORT ID | MESSAGE | | //// | | TYPE | +------+------+-------------+-------------+-------------+------+ 2 | FROM PORT ID | TABLE | //// | | | POSITION | //// | +------+-------------+-------------+------+-------------+------+ 3 | //// | SOURCE | RENDEZVOUS | BIT COUNT | | //// | HOST | HOST | | +------+-------------+-------------+---------------------------+ | | 4 | | // DATA // | | | | +-------------+-------------+-------------+-------------+------+
0 8 16 24 32 36 +-------------+-------------+-------------+-------------+------+ 0 | ホスト/悪童| 外国| リンク| ////////////////// | | 旗| ホスト| | ////////////////// | +------+------+-------------+-------------+-------+-----+------+ 1 | //// | IDを移植するために| メッセージ| | //// | | タイプ| +------+------+-------------+-------------+-------------+------+ 2 | PORT IDから| テーブル| //// | | | 位置| //// | +------+-------------+-------------+------+-------------+------+ 3 | //// | ソース| ランデブー| ビットカウント| | //// | ホスト| ホスト| | +------+-------------+-------------+---------------------------+ | | 4 | | //データ//| | | | +-------------+-------------+-------------+-------------+------+
36-bit Host Format
36ビットのホスト形式
+-------------+-------------+-------------+-------------+ 0 | HOST/IMP | FOREIGN | LINK | /////////// | | FLAGS | HOST | | /////////// | +-------------+-------------+-------------+-------------+ 1 | /////////// | TO PORT ID | | | | +-------------+-------------+-------------+-------------+ 2 | MESSAGE | FROM PORT ID | | TYPE | | +-------------+-------------+-------------+-------------+ 3 | TABLE | /////////// | SOURCE | RENDEZVOUS | | POSITION | /////////// | HOST | HOST | +-------------+-------------+-------------+-------------+ | BIT COUNT | | | | | +-------------+-------------+ | | | // DATA // | | +-------------+-------------+-------------+-------------+
+-------------+-------------+-------------+-------------+ 0 | ホスト/悪童| 外国| リンク| /////////// | | 旗| ホスト| | /////////// | +-------------+-------------+-------------+-------------+ 1 | /////////// | IDを移植するために| | | | +-------------+-------------+-------------+-------------+ 2 | メッセージ| PORT IDから| | タイプ| | +-------------+-------------+-------------+-------------+ 3 | テーブル| /////////// | ソース| ランデブー| | 位置| /////////// | ホスト| ホスト| +-------------+-------------+-------------+-------------+ | ビットカウント| | | | | +-------------+-------------+ | | | //データ//| | +-------------+-------------+-------------+-------------+
32-bit Host Format
32ビットのホスト形式
Bressler, et al. Experimentation [Page 12] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[12ページ]RFC333メッセージ交換プロトコル実験1972年5月
The fields within the Host/IMP leader are already familiar to NCP programmers however, two points about these fields are worth mentioning. First, the destination field originally contains the number of the rendezvous Host. After rendezvous at a intermediate site, the destination field contains the source of the message rendezvous with. Second, the link field for the MSP experiment can only contain link number 192-195. We have not taken the time to figure out a sensible allocation of these four links among all the messages which might be sent using the MSP. One alternative is to cycle over the links to increase the bandwidth of the "pipe" between any two Hosts. For the time being, until further consideration is given to this issue, we suggest each Host at a site using one (unique) link for all its communication.
しかしながら、NCPプログラマには、Host/IMPリーダーの中の分野が既に身近である、これらの分野に関する2ポイントは言及する価値があります。 まず最初に、あて先フィールドは元々、ランデブーHostの数を含みます。 中間的サイト、分野がメッセージランデブーの源を含む目的地でのランデブーの後に。 2番目に、MSP実験のためのリンクフィールドはリンク番号192-195を含むことができるだけです。 私たちはMSPが使用させられるかもしれないすべてのメッセージの中でわざわざこれらの4個のリンクの分別がある配分を理解していません。 1つの選択肢が、どんな2Hostsの間の「パイプ」の帯域幅を増加させるようにリンクの上に循環することになっています。 当分の間、私たちは、すべてのコミュニケーションに1個の(ユニーク)のリンクを使用することでさらなる考慮をこの問題に対して払うまでサイトの各Hostを勧めます。
The message types we have to represent in the message type field are few now: we suggest message type 2 for SEND or OUT messages and message 3 for RECEIVE or IN messages. Message type 4 is the FLUSH message, if FLUSH is used.
私たちがメッセージタイプ分野で代理をしなければならないメッセージタイプは現在、わずかです: 私たちはRECEIVEかINメッセージへのSENDのためのメッセージタイプ2かOUTメッセージとメッセージ3を勧めます。 FLUSHが使用されているなら、メッセージタイプ4はFLUSHメッセージです。
The rendezvous Host field needs no comment. Except that the field is unnecessary after the rendezvous has taken place and could then be used for something else.
ランデブーHost分野はノーコメントを必要とします。 ランデブーが行われて、そしてときに行われることができた後に分野が不要であるのを除いて、他の何かには、使用されてください。
The bit count is a count of data bits in an OUT message or the size of the input buffer (not including the header) in an IN message. Thus the sender process can tell from the IN message bit count when it receives the IN message how much of the data in the OUT message was accepted by the receiver process and can use this knowledge to retransmit the remainder of the message if so desired. After the rendezvous, we recommend that all of the data in the message be sent on the source of the IN message even if the OUT bit count was greater than the IN bit count. Thus, at the receiver Host the monitor has the option (if it wants to take it) of discarding the message for being too long, sending the number of bits the receiver process has done an IN for into the receiver process and discarding the rest, or queuing the rest of the bits and somehow notify the receiver process that there are more bits which the receiver process can ask for.
噛み付いているカウントは、OUTメッセージにおける、データ・ビットのカウントかINメッセージの入力バッファ(ヘッダーを含んでいない)のサイズです。 したがって、送付者の過程は、INメッセージを受け取るときのINメッセージビットカウントからOUTメッセージのデータのどのくらいが受信機工程で受け入れられたかを言うことができて、そう望まれているなら、メッセージの残りを再送するのにこの知識を使用できます。 ランデブーの後に、私たちは、OUTビットカウントがINがカウントに噛み付いたよりさらに大きかったならメッセージのデータのすべてがINメッセージの源で送られることを勧めます。 したがって、受信機Hostでは、モニターは長いことへのメッセージ過ぎるのを捨てるオプション(それを取りたいなら)を持っています、受信機の過程と残りを捨てるか、列を作りへのビットの残りのためにINをして、受信機の過程が求めることができるより多くのビットがあるように受信機の過程にどうにか通知するのを受信機の過程がさせるビットの数を送って。
The to- and from-port-id fields are 24-bit numbers. This size was chosen to help the TIPs. The first eight bits of a port Id should be the number of the Host at which this port id was created. Note well, that this is not necessarily the Host at which the port is being used. This is necessary since rendezvous take place at intermediate sites and because ports may move from site to site. We suggest that all port ids with the first eight bits all zero be reserved for network-wide use. In particular, a port id with all 24 bits zero will be used to mean "ANY". This gives us the options of:
そして、-、ポートイドから、分野は24ビットの数です。 このサイズは、TIPsを助けるために選ばれました。 ポートIdの最初の8ビットはこのポートイドが作成されたHostの数であるべきです。 注意は噴出して、これは必ずポートが使用されているHostであるというわけではありません。 ランデブーが中間的サイトで行われて、ポートがサイトからサイトまで動くかもしれないのでこれが必要です。 私たちは、すべてが合っているゼロ最初の8ビットがあるすべてのポートイドがネットワーク全体の使用のために予約されることを提案します。 24ビットが合っているゼロすべてがあるポートイドは「いくらかでも」意味するのにおいて特に、使用されるようになるでしょう。 これは以下のオプションを私たちに与えます。
Bressler, et al. Experimentation [Page 13] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[13ページ]RFC333メッセージ交換プロトコル実験1972年5月
RECEIVE from ANY to SPECIFIC
いずれからも特有になるまで受信してください。
RECEIVE from SPECIFIC to SPECIFIC
特定であるのから特有になるまで受信してください。
SEND from SPECIFIC to ANY
特定であるのからいずれまでも発信してください。
and SEND from SPECIFIC to SPECIFIC
そして、特定であるのから特有になるまで発信してください。
Examples of the use of these options will be given below.
これらのオプションの使用に関する例は以下に出されるでしょう。
The other options (RECEIVE to ANY) and (SEND from ANY) we feel are kind of useless but would not prohibit them. We believe that in the absence of explicit specification of rendezvous Host, the use of an ANY port id in the user's system call should affect the default rendezvous site as follows:
別の選択肢の(いずれへのRECEIVE)と(いずれからのSEND)は、ちょっと役に立たないのですが、それらを禁止しません私たちが、感じる。 私たちは、ランデブーHostの明白な仕様がないときユーザのシステムコールにおけるどんなポートイドの使用も以下のデフォルトランデブーサイトに影響するべきであると信じています:
RECEIVE from ANY--rendezvous in receiver
いずれからのRECEIVE--受信機で集合してください。
RECEIVE from SPECIFIC--rendezvous in sender
SPECIFICからのRECEIVE--送付者で集合してください。
SEND to ANY--rendezvous in sender
いずれへのSEND--送付者で集合してください。
SEND to SPECIFIC--rendezvous in sender
SPECIFICへのSEND--送付者で集合してください。
The less significant 16 bits of the id can be used however a Host wants to. For instance, eight bits might be used as a process id and eight bits might be used as a channel specification within the specified process. We suggest that each Host reserve the port ids with the middle eight bits all zero for special uses as well known ports.
Hostがどのようにそうしたくてもさえ、イドのそれほど重要でない16ビットを使用できます。 例えば、過程イドと8ビットがチャンネル仕様として指定された過程の中で使用されるかもしれないとき、8ビットは使用されるかもしれません。 私たちは、各Hostがよく知られるとしての特別な用途のためのすべてのゼロが移植する中くらいの8ビットでポートイドを予約することを提案します。
The table position field is included to help prevent costly table searches at interrupt level. Hosts sending INs and OUTs, put in the table position field the rendezvous table position of the SEND or RECEIVE associated with the IN or OUT. At an intermediate Host rendezvous, the table position fields in the matching IN and OUT are swapped so that when the messages arrive at the opposite end, the matching SEND and RECEIVE can be found quickly. The MSP must do the swap at the rendezvous, but of course the MSPs need not fill in the table position field when first transmitting an IN or OUT in which case the information arriving in an IN or OUT will be meaningless. The general algorithm, then, is to check the table position as specified in this field and if that fails, search the whole table.
テーブル位置の分野は、割り込みレベルで高価なテーブル検索を防ぐのを助けるために含まれています。 ホストがINsとOUTsを送って、INかOUTに関連しているSENDかRECEIVEのランデブーテーブル位置をテーブル位置の分野に置いてください。 中間的Hostランデブーのときに、合っているINとOUTのテーブル位置の分野は、メッセージが反対端に到着するとき、すぐに合っているSENDとRECEIVEを見つけることができるように交換されます。 MSPはランデブーのときにスワッピングしなければなりませんが、最初にINに到着する情報をケースに入れてください。さもないと、OUTが無意味になるINかOUTを伝えるとき、もちろん、MSPsはテーブル位置の分野に記入する必要はありません。 一般的なアルゴリズム、この分野で指定されて、それが失敗するなら、テーブル位置は次に、全体のテーブルを捜すようにチェックすることになっています。
The source field is filled in INs and OUTs by the MSP which originally sends these messages. At the rendezvous the source of each message is preserved in the message being forwarded to the final Host. When an IN or OUT arrives at a process, the process can use
ソースフィールドはINsとOUTsに元々これらのメッセージを送るMSPによっていっぱいにされます。 ランデブーのときに、それぞれのメッセージの源は、最終的なHostに送りながら、メッセージに保持されます。 INかOUTが過程に到着するとき、過程は使用されることができます。
Bressler, et al. Experimentation [Page 14] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[14ページ]RFC333メッセージ交換プロトコル実験1972年5月
the source information to update its understanding of the rendezvous Host (e.g., when the destination Host and rendezvous Host are different).
ランデブーHost(例えば、目的地HostとランデブーHostが異なっているとき)の理解をアップデートするソース情報。
EXAMPLES
例
The typical example.
典型的な例。
We envision communication normally taking place using specifications to and from ports and rendezvous at the sender. For instance, the TIP would probably send to other Hosts using this method and would certainly receive from other Host until the TIP asks for it. In this "normal" method a monitor could even look at the bit count in the arriving IN-message, use that as an allocation and then simulate an OUT-message of the exact correct length.
私たちは、通常、コミュニケーションが送付者でランデブーとポートとランデブーから仕様を使用することで行われるのを思い描きます。 例えば、TIPはたぶんこの方法を使用することで他のHostsに発信して、確かに、TIPが自ら災難を招くまで、他のHostから受信するでしょう。 この「正常な」方法で、モニターは、ビットが到着IN-メッセージで数えて、配分としてそれを使用して、次に、正確な適度の長さに関するOUT-メッセージをシミュレートするのを見ることさえできるでしょう。
The logging example
伐採の例
Consider an example of SEND to SPECIFIC and RECEIVE from ANY with the rendezvous at the receiver. This method might be used by some logging receiver process with a well-known to-port. For instance, a measurements program to which statistics are sent from many processes throughout the net.
ランデブーが受信機にある状態で、いずれからもSPECIFICとRECEIVEとSENDに関する例を考えてください。この方法はaが周知の何らかの伐採受信機工程でポートで使用されるかもしれません。 例えば、統計が多くから送られる測定値プログラムはネット中で処理されます。
The program library example
プログラムライブラリの例
Suppose within a given time-sharing system there is a particular library routine which is available for use by any process in the network. The library process has a RECEIVE from ANY always pending at a well-known port. Eventually, some process sends a message to the library process' well-known-port. This message includes the data to be processed, a port to use for sending the answer, and the money. The library process takes some of the money and sends it to the well-known port of the accounting process which itself has a RECEIVE from ANY pending. The library process then processes the data and sends the answer back to the process which requested the service using a SEND to SPECIFIC message which rendezvous at the destination where there is already a RECEIVE from SPECIFIC pending. Of course, in this message besides the answer, any change the requesting process has coming is returned.
与えられた時分割システムの中でネットワークにおけるどんな工程でも使用に利用可能な特定のライブラリ・ルーチンがあると仮定してください。 ライブラリの過程に、ウェルノウンポートでいつも未定のいずれからのRECEIVEがあります。 結局、何らかの過程がライブラリの過程の周知のポートにメッセージを送ります。 このメッセージは処理されるべきデータ、答えを送るのに使用するポート、およびお金を含んでいます。 ライブラリの過程は、いくらかのお金で取って、いずれからの未定のRECEIVEを持っている会計作業自体のウェルノウンポートにそれを送ります。 ライブラリの過程は、次に、データを処理して、SPECIFICメッセージにSENDを使用することでサービスを要求した過程に答えを送り返します(SPECIFICからの未定のRECEIVEが既にある目的地で集合します)。 もちろん、答え以外にこのメッセージでは、要求の過程で来るどんな変化も返します。
A comment
コメント
As can be seen from our examples, we think rendezvousing at an intermediate Host will seldom be done as the chief benefit of this comes when it is desirable to move a port (see reference 4 for a discussion of this). We would like to see all Hosts provide some
私たちの例から見ることができるように、私たちは、ポートを動かすのが望ましいときに(この議論の参照4を見てください)、この主要な利益が来るとき中間的Hostでめったに集合しないと思います。 すべてのHostsがいくつかを提供するのを見たいと思います。
Bressler, et al. Experimentation [Page 15] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[15ページ]RFC333メッセージ交換プロトコル実験1972年5月
(meager) amount of buffering for this purpose but would not require it. It shouldn't be too painful to provide a little of this kind of buffering-especially since a Host can throw away any message it can't handle.
このためにしかし、バッファリングする(貧弱)の量はそれを必要としないでしょう。 Hostがそれが扱うことができないどんなメッセージも無駄にできるので特にこの種類の少しのバッファリングを提供するのはそれほど苦痛であるべきではありません。
(THIS PAGE WILL BE REPLACED WITH A BETTER DESCRIPTION OF TELNET UNDER MSP IN A FEW DAYS--DCW)
(近日中に、MSPの下でこのページをtelnetの、より良い記述に取り替えるでしょう--DCW)
TELNET
telnet
Let us postulate a pair of Telnet programs that maintain two bidirectional communication paths, one for data and one for control. Let us also assume, for convenience that the port IDs are as follows:
2つの双方向の通信路、データのためのもの、およびコントロールのための1つを維持する1組のTelnetプログラムを仮定しましょう。 また、以下のポートIDがある便宜のために以下を仮定しましょう。
If the WRITE-CONTROL-ID is N, then --
次に、WRITE-CONTROL-IDがNであるなら--
READ-CONTROL-ID=N+1,
コントロールを読んでいるID=N+1
WRITE-DATA=N+2,
データ=N+2を書きます。
READ-DATA=N+3.
-読まれて、データはN+3と等しいです。
The initial state is the server Telnet sitting with a READ-FROM-ANY pending.
初期状態はいずれのREAD-FROMと共に未定の状態で座るサーバTelnetです。
The user Telnet now issues a SEND-TO-SPECIFIC with the data field containing the PORT-ID of the SERVER's WRITE-CONTROL-ID. This message is sent from the user-Telnet's WRITE-CONTROL-ID.
ユーザTelnetは現在、データ・フィールドがSERVERのWRITE-CONTROL-IDのPORT-IDを含んでいるSEND-TO-SPECIFICを発行します。 ユーザtelnetのWRITE-CONTROL-IDからこのメッセージを送ります。
Thus all port IDs are specified by the user Telnet, so, if desired, he need only remember one number and derive the rest. Uniqueness is preserved since the port IDs supplied by the user Telnet contain his Host ID and other information making the ID unique to him.
したがって、すべてのポートIDがユーザTelnetが指定されるので、望まれているなら、彼は、1つの数しか覚えていないで、残りを引き出さなければなりません。 ユーザTelnetによって供給されたポートIDがIDを彼にユニークにする彼のHost IDと他の情報を含んでいるので、ユニークさは保存されます。
Now that these communication paths are established, the two processes can exchange data and control information according to established Telnet protocols.
これらの通信路が確立されるので、確立したTelnetプロトコルに応じて、2つの過程がデータと制御情報を交換できます。
THE INFORMATION OPERATOR
問い合わせ係
The Message Switching Protocol itself impose no fixed requirements on the use of the port ID's, and the problem of process identification is somewhat separated from the means used to effect communication. It is, however, very much a part of the overall issue of interprocess communication, and so we here specify a facility for handling process identification, the information operator.
Message Switchingプロトコル自体はポートIDのものの使用に固定要件を全く課しません、そして、過程識別の問題は効果コミュニケーションに使用される手段といくらか切り離されます。 しかしながら、それはたいへんプロセス間通信の総合的な問題の一部であり、そうは私たちです。ここで、取り扱い過程識別(問い合わせ係)のための施設は指定します。
Bressler, et al. Experimentation [Page 16] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[16ページ]RFC333メッセージ交換プロトコル実験1972年5月
One goal in a process identification scheme is to provide a means by which processes can select their own identifiers which can be guaranteed unique and can contain information meaningful to the user. Problems of efficiency prevent making the port ID's themselves large enough to accomplish this aim. Efficiency questions aside, it would appear to be ideal to allow processes to use character strings of arbitrary length to identify themselves. Uniqueness can then be easily ensured if, for example, users follow the convention of including their names in the process identification string. Further, the remainder of the name can be chosen to have some meaning related to its use with obvious advantages and convenience for users.
過程識別計画における1つの目標が、どの過程が保証できるそれら自身の識別子を選択できるかによってユニークな手段を提供するためにあって、ユーザにとって、重要な情報を含むことができます。 効率の問題は、ポートをIDのものにするのを自分たちでこの目的を達成できるくらい大きい状態で防ぎます。 効率質問は別として、過程が自分たちを特定するのに任意の長さの文字列を使用するのを許容するのが理想的であるように見えるでしょう。 そして、例えば、ユーザが過程識別ストリングに彼らの名前を含むコンベンションに続くなら、容易にユニークさを確実にすることができます。 さらに、何らかの意味を使用に関連させるようにユーザのための明白な利点と便利で名前の残りを選ぶことができます。
One solution is to establish a convention whereby the symbolic identifiers are used only during some initial phase of communication and not in every message. That is, processes identify each other initially using symbolic identifiers, but exchange local port identifiers at the same time which are used for all ensuing messages.
1つの解決策はシンボリックな識別子があらゆるメッセージではなく、コミュニケーションの何らかの初期位相だけの間に使用されるコンベンションを設立することです。 すなわち、過程は、初めはシンボリックな識別子を使用することで互いを特定しますが、同時にのすべて続いているメッセージに使用されるローカルのポート識別子を交換します。
The means of providing this facility is to establish a process at each of a number of Hosts (e.g., all server Hosts) called the "information operator". The function of this process is to associate symbolic identification strings and port ID's. A process can identify itself and/or a foreign process to the information operator, and may request the port ID of the foreign process. The symbolic identification strings are chosen by the processes and are long enough to contain meaningful information, e.g., LOGGER, MURPHY- TESTPROG.
この施設を提供する手段は「問い合わせ係」と呼ばれるそれぞれの多くのHosts(例えばすべてのサーバHosts)で過程を確立することです。 この過程の関数は、シンボリックな識別ストリングを関連づけて、IDのものを移植することです。 過程は、それ自体、そして/または、外国過程を問い合わせ係に特定できて、外国過程のポートIDを要求するかもしれません。 シンボリックな識別ストリングは、過程によって選ばれていて、有意義な情報、LOGGER、例えばマーフィーTESTPROGを含むことができるくらい長いです。
Communication with the information operator, whether by local or remote processes, is via the regular MSP functions. The information operator will always have a RECEIVE ANY outstanding on a well-known port. This could in general be the only well-known port in existence. A message received on this port contains the following parameters:
問い合わせ係とのコミュニケーションは地方の、または、リモートな過程であるか否かに関係なく、通常のMSP機能を通したそうです。 問い合わせ係はいつもウェルノウンポートの未払いのRECEIVE ANYを持つでしょう。 一般に、これは現存する唯一のウェルノウンポートであるかもしれません。 このポートの上に受け取られたメッセージは以下のパラメタを含んでいます:
1. String identifying the foreign process with which communication
is desired.
1. 外国過程をどのコミュニケーションと同一視するストリングが望まれています。
2. String identifying the calling process.
2. 呼び出しプロセスを特定するストリング。
3. Calling process' port number.
3. 過程のものをポートナンバーと呼びます。
4. A delay specification.
4. 遅れ仕様。
Bressler, et al. Experimentation [Page 17] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[17ページ]RFC333メッセージ交換プロトコル実験1972年5月
The format of these parameters is shown in Fig. 4. In some cases, one or more of the arguments would be null. Following receipt of a message, the information operator will, in some cases, do a SEND SPECIFIC to the calling process' port number providing the desired information or notice of failure.
これらのパラメタの書式は図4に示されます。 いくつかの場合、議論の1つ以上はヌルでしょう。 いくつかの場合、メッセージの領収書に従って、問い合わせ係は、失敗の必要な情報か通知を提供しながら、呼び出しプロセスのポートナンバーにSEND SPECIFICをするでしょう。
The following two cases would appear to cover all functions of the information operator. They correspond to the SEND/RECEIVE SPECIFIC ANY cases of the MSP.
以下の2つのケースが問い合わせ係のすべての機能をカバーするように見えるでしょう。 彼らはMSPに関するSEND/RECEIVE SPECIFIC ANYケースに対応します。
1. Two processes each knowing the specific identify of the other wish
to communicate. Each does a SEND SPECIFIC to the information
operator, giving parameters 1-2, the default delay spec in this
case being WAIT. When the information operator receives the
second of these and notes that a match exists, it sends to each
process the port ID of the other process and deletes both strings
and both port ID's from its tables. The two processes, which have
each done a RECEIVE SPECIFIC in anticipation of the foreign port
number, can then communicate using just the port numbers and basic
MSP functions.
1. それぞれ特定を知っていると特定される交信するというもう片方の願望の2つの過程。 それぞれが問い合わせ係にSEND SPECIFICをします、パラメタ1-2(この場合WAITであるデフォルト遅れ仕様)を与えて 問い合わせ係がこれらと注意のマッチが存在する秒に受信するとき、もう片方の過程のポートIDを各過程に送って、両方のストリングを削除します、そして、両方がテーブルからIDのものを移植します。 そして、2つの過程(それぞれ外国ポートナンバーを予測してRECEIVE SPECIFICをした)が、まさしくポートナンバーと基本的なMSP機能を使用することで交信できます。
2. A process is set up to provide some sort of general service or
information, and its name and protocol advertised. This process
intends to maintain an outstanding SEND or RECEIVE ANY for the
first (and perhaps only) message transaction, e.g., the library
process discussed earlier. Most such processes would be receivers
initially, but there might be a few cases where a SEND could be
left outstanding, and a forcing process could come along and pick
up the information. In either case, the service process will do
SEND SPECIFIC to the information operator giving the local
symbolic ID and local port ID. The foreign symbolic ID would be
null, and the default delay spec is NO-WAIT. That is,
2. 過程は、広告に掲載されたそのある種の一般的なサービスか情報、名前、およびプロトコルを提供するためにセットアップされます。 この過程は、1番目と(恐らく唯一)のための傑出しているSENDかRECEIVE ANYがメッセージ取引、例えばより早く議論したライブラリの過程であることを、支持するつもりです。 初めは、そのようなほとんどの過程が受信機でしょうが、いくつかのケースがSENDを傑出しているままにできたところにあるかもしれなくて、強制の過程は、やって来て、情報を受信するかもしれません。 どちらの場合ではも、サービス過程は地方のシンボリックなIDとローカルのポートIDを与える問い合わせ係にSEND SPECIFICをするでしょう。 外国シンボリックなIDはヌルでしょう、そして、デフォルト遅れ仕様はWAITではありません。 That is,
INFO ( -, local ID, local port)
インフォメーション(-、地方のID、地方のポート)
The information operator will enter this information in its tables
but return nothing to the caller. The caller would proceed to do
its SEND/RECEIVE ANY to wait for business. When another process
wishes to use the advertised service, it asks the logger for the
port ID of the service process, i.e.,
問い合わせ係は、この情報をテーブルに入力しますが、何も訪問者に返さないでしょう。 訪問者は、ビジネスを待つためにSEND/RECEIVE ANYをしかけるでしょう。 別の過程が広告を出しているサービスを利用したがっているとき、すなわち、それはサービス過程のポートIDをきこりに求めます。
INFO (service ID, -, local port)
インフォメーション(IDを修理してください、-、地方のポート)
The local symbolic ID need not be specified, and the default delay
spec is NO-WAIT. The information operator would SEND the port ID
of the service process to the local port of the caller, and retain
the table entry for future callers. Only the service process
地方のシンボリックなIDは指定される必要はありません、そして、デフォルト遅れ仕様はWAITではありません。 問い合わせ係は保有するでしょう。サービスのSENDのポートIDは、訪問者の地方のポートに処理して、将来の訪問者のためにテーブル項目を保有します。 サービス過程だけ
Bressler, et al. Experimentation [Page 18] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[18ページ]RFC333メッセージ交換プロトコル実験1972年5月
could request the entry be deleted. If the service ID was unknown
to the information operator at the time of this call, it would
immediately return a failure indication, i.e., zero.
エントリーが削除されるよう要求できました。 問い合わせ係にとって、サービスIDがこの呼び出し時点で未知であるなら、それはすぐに、失敗指示(すなわち、ゼロ)を返すでしょうに。
Communicating processes would normally use the information operator local to one or the other, and like the rendezvous Host in the MSP, this would be agreed upon in advance. Service processes would normally use the information operator at their local site, and correspondingly, user processes would call the information operator at the site where the service process was expected to be available. There is no restriction on using an information operator at some other site of course, and some small and/or lazy servers could use a different Host for their service process ID's. It presents no problem for two or more information operators to have entries for the same service process, and in fact, this may be very desirable for special types of service processes which exist only one place on the net and may move around from time to time.
通常、交信の過程は1つへのローカルの問い合わせ係かもう片方を使用するでしょう、そして、MSPのランデブーHostのように、これはあらかじめ、同意されるでしょう。 通常、サービス過程はそれらのローカル・サイトで問い合わせ係を使用するでしょう、そして、ユーザ・プロセスはサービス過程が利用可能であると予想されたサイトに対応する、問い合わせ係と呼ぶでしょう。 もちろんある他のサイトで問い合わせ係を使用するときの制限が全くありません、そして、いくつかの小さい、そして/または、怠惰なサーバがそれらのIDのサービス過程ものに異なったHostを使用するかもしれません。 それは、ネットに2のための問題をいいえに示すか、または同じサービスのためのエントリーを持つオペレータが処理して、存在する特別なタイプのサービス過程には、事実上、これが非常に望ましいかもしれないという詳しい情報に1つの場所だけを示します、そして、時々動き回るかもしれません。
Processes would specify their own local port numbers, and each system would have to provide some way to help user processes do this. In TENEX for example, one would probably use the job number concatenated with another number assigned within the job. The information operator cannot supply port numbers because it will be running on a different Host than one or both of the communicants and cannot know what is a unique number for that Host. In some cases, processes would ask the "unique number process" (described below) for their local port ID, and would make it known via the information operator.
プロセスは地元のポートナンバーを指定するでしょう、そして、各システムはユーザ・プロセスがこれをするのを助ける何らかの方法を提供しなければならないでしょう。 例えば、TENEXでは、1つはたぶんもう1つの数が仕事の中で割り当てられている状態で連結された職務番号を使用するでしょう。 問い合わせ係は、聖餐拝受者の1か両方と異なったHostの上で作業するのでポートナンバーを供給できないで、何がそのHostのユニークな数であるかを知ることができません。 いくつかの場合、プロセスは、地元のポートIDのために、「ユニークな数のプロセス」(以下で、説明される)を尋ねて、問い合わせ係でそれを明らかにするでしょう。
In actual practice, a few exceptions would be made to the rule that the only "well-known" port in the world is the information operator. Such exceptions would be processes common to many Hosts, e.g., LOGGER, or those in particularly frequent use. In such cases the unique port numbers would be assigned by administrative fiat and recorded and published to all users.
実際行なわれているところでは、いくつかの例外を世界における唯一の「よく知られる」ポートが問い合わせ係であるという規則にするでしょう。 そのような例外は特に頻繁な使用での多くのHosts、例えば、LOGGER、またはそれらに共通のプロセスです。 そのような場合ユニークなポートナンバーは、すべてのユーザに管理法令で割り当てられて、記録されて、発行されるでしょう。
The symbolic identification strings are specified to be from 1 to 39 (an arbitrary maximum) ASCII characters terminated by a null (byte of all zeroes). The characters will be 7-bit ASCII in 8-bit bytes with the high order bit set to zero. A null string (first byte is null) is used where no argument is required.
シンボリックな識別ストリングは、ヌル(すべてのゼロのバイト)によって終えられた1〜39人(任意の最大)のASCII文字まであるように指定されます。 キャラクタはゼロに設定された高位のビットがある8ビットのバイトで7ビットのASCIIになるでしょう。 ヌルストリング(最初のバイトはヌルである)は議論が全く必要でないところで使用されます。
Bressler, et al. Experimentation [Page 19] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[19ページ]RFC333メッセージ交換プロトコル実験1972年5月
Format of Information Operator Messages
問い合わせ係メッセージの形式
To Information Operator: A stream of 8-bit bytes.
問い合わせ係に: 8ビットのバイトのストリーム。
+------+--//---+------+------+--//---+------+------+-------+-------+
|char 0| 1// n | null |char 0| 1// n | null | port | number| delay |
| | // | | | // | | | |spec |
+------+--//---+------+------+--//---+------+------+-------+-------+
\ /\ /\ /\ /
\_________________/ \___________________/ \___________/ \____/
PARAMETER 1 PARAMETER 2 PARAMETER 3 PARAMETER
4
Parameters given:
+------+--//---+------+------+--//---+------+------+-------+-------+ |炭0| 1 //n| ヌル|炭0| 1 //n| ヌル| ポート| 数| 遅れ| | | // | | | // | | | |仕様| +------+--//---+------+------+--//---+------+------+-------+-------+ \ /\ /\ /\ / \_________________/ \___________________/ \___________/ \____与えられている/PARAMETER1PARAMETER2PARAMETER3PARAMETER4Parameters:
1. String identifying the foreign process with which communication
is desired. (1 to 39 characters, or null)
1. 外国プロセスをどのコミュニケーションと同一視するストリングが望まれています。 (1〜39のキャラクタ、またはヌル)
2. String identifying the calling process. (1 to 39 characters, or
null)
2. 呼び出しプロセスを特定するストリング。 (1〜39のキャラクタ、またはヌル)
3. Calling process' port number.
3. 過程のものをポートナンバーと呼びます。
4. Delay specification:
4. 仕様を遅らせてください:
0=default
1=wait for match
2=don't wait for match
0 = マッチ2=のためのデフォルト1=待ちはマッチを待っていません。
From Information Operator: 3 8-bit bytes.
問い合わせ係から: 3 8ビットのバイト。
+--------|-------|-------+ | byte 0 | 1 | 2 | +--------|-------|-------+
+--------|-------|-------+ | バイト0| 1 | 2 | +--------|-------|-------+
Port number (24 bits) of requested foreign port if successful, 0 if unsuccessful.
うまくいくなら要求された外国ポートの数(24ビット)を移植してください、0 失敗しています。
UNIQUE PORT NUMBERS
ユニークなポートナンバー
The existence of unique port numbers is essential to the operation of the MSP. For instance, when two communicating processes specify message rendezvous at an intermediate site, the processes must be able to specify to- and from-ports which are not being used by other processes which have specified message rendezvous at the same site or else messages may be delivered to incorrect destinations. We have alluded to a method of providing unique port numbers earlier in this note. This method is to partition the 24-bit port number space into disjointed segments and give one segment to each Host in the network
ユニークなポートナンバーの存在はMSPの操作に不可欠です。 そして、例えば、2つの交信プロセスが中間的サイトでメッセージランデブーを指定するときプロセスが指定できなければならない、-、ポートから、どれが同じサイトかメッセージでメッセージランデブーを指定した他のプロセスによって使用されていないかは不正確な送付先に提供されるかもしれません。 私たちは、より早くユニークなポートナンバーをこの注意に提供するメソッドを暗示しました。 このメソッドは、24ビットのポートナンバースペースをばらばらのセグメントに仕切って、ネットワークで各Hostあたり1つのセグメントを与えることです。
Bressler, et al. Experimentation [Page 20] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[20ページ]RFC333メッセージ交換プロトコル実験1972年5月
to distribute when it is called upon to "create" a unique port id. Thus each 24-bit Host number will consist of two major parts. The first 8 bits will be the number of the Host "creating" the port id and the next 16 bits can be used in any manner the creating Host desires. This gives each Host 2^16 port numbers to distribute, and each Host will have the burden of distributing its segment of the port number space in a unique manner. We recommend the convention that the port numbers with the middle 8 bits equal to zero be reserved for well-known ports in the creating Host's system. We already recommend in an earlier section that port numbers with the first 8 bits equal to zero be reserved for network-wide use and in particular the port number with all 24 bits equal to zero be used to mean ANY.
ユニークなポートイドを「作成すること」が要求されるとき、分配するために。 したがって、それぞれの24ビットのHost番号は2つの大半から成るでしょう。 最初の8ビットはポートイドを「作成する」Hostの数になるでしょう、そして、作成しているHostが望んでいるどんな方法でも次の16ビットは使用できます。 これは各Host2^16に分配するポートナンバーを与えます、そして、各Hostには、ユニークな方法によるポートナンバースペースのセグメントを分配する負担があるでしょう。 私たちは、中くらいの8ビットがあるポートナンバーがゼロと等しいコンベンションが作成しているHostのシステムのウェルノウンポートのために控えられることを勧めます。 私たちは、最初の8ビットの同輩がネットワーク全体の使用のためにゼロまで予約されているポートナンバーと特にゼロに合わせるために等しいすべての24ビットがあるポートナンバーが何でも意味するのにおいて使用されていることを既に以前のセクションで勧めます。
Since each Host only has 2-16- port numbers to distribute, in general port numbers will not be able to be held and used by processes for long periods of time (e.g., weeks and months). More typically, Hosts will probably implicitly "take back' all port numbers the Host has distributed each time the Host's system goes down and will redistribute the port numbers as required when the system comes back up. In other words, port numbers will not in general remain unique over the going down of the creating Hosts. Of course, a given Host may see to give the same port numbers to a number of standard processes (such as the FORTRAN compiler) each time it comes up port numbers registered with an information operator will frequently remain constant over system ups and downs.
各Hostには分配する2-16ポートナンバーがあるだけであるので、ポートナンバーは、長期間(例えば、何週間も何カ月も)の間、プロセスで保持して、一般に、使用できないでしょう。 'Hostsは、より典型的に、Hostのシステムが落ちる各回たぶんそれとなくHostが分配したすべてのポートナンバーを「取り戻し'て、システムが来て戻るとき、必要に応じてポートナンバーを再配付するでしょう」。 言い換えれば、一般に、ポートナンバーは作成しているHostsの低下に関してユニークなままでないでしょう。 もちろん、与えられたHostはともに記名されたポートナンバーを来るたびに多くの標準のプロセス(FORTRANコンパイラなどの)に同じポートナンバーを与えるために、問い合わせ係が頻繁にシステム浮沈について一定のままでいるのがわかるかもしれません。
In spite of the fact that each Host will probably not in general be able to distribute port numbers to arbitrary user processes which ca be guaranteed to remain unique over a long period of time, there will still be demand for provision of long-term unique port numbers. To some, the procedure of going through the information operator smacks much too much of making a connection. These people will insist that for a variety of reasons their processes be allowed to communicate via ports whose identifiers remain constant for long periods of time. Therefore, it would be nice if at one or two places in the network, a long-term unique number service was provided. We'll call a process providing this service the Unique Number Process. The Unique Number Process would have assigned to it one segment of the unique port number space-all those port numbers, for instance, with the first 8- bits equal to 377-8. This process would have a SEND-to-ANY pending from a well-known port with local rendezvous specified. When any process wanted a unique number which it could depend on not to be used for all time or until the number is given back, it would send a RECEIVE-from-SPECIFIC specifying the well-known port of the Unique Number Process and rendezvous at the Unique Number Process' Host. The Unique Number Process' pending SEND-to-ANY would contain a unique number. Also, the Unique Number Process would have a RECEIVE-from-
それぞれのHostがたぶん一般に任意のユーザ・プロセスにポートナンバーを分配できないという事実にもかかわらず、どのcaがそれでも、長日月の間、ユニークなままであるために、長期のユニークなポートナンバーの支給の要求があるのが保証されますか? いくつかに、問い合わせ係に直面する手順はあまりに接続を作る多くを打ちます。 これらの人々が主張する、さまざまな理由によるそれ、それらのプロセス、ポートを通してだれの識別子が長期間の間、一定のままで残っているかを伝えるのが許容されてください。 したがって、ネットワークにおける1か2つの場所で長期のユニークな数のサービスを提供するなら、良いでしょうに。 私たちは、プロセスをこのサービスにUnique Number Processを提供すると呼ぶつもりです。 例えば、Unique Number Processは377-8と等しい最初8のビットでそれらのポートナンバーのユニークなポートナンバースペースのすべて、1つのセグメントをそれに割り当てたでしょう。 このプロセスは地方のランデブーが指定されているウェルノウンポートからの未定のSENDをいずれにも持っているでしょう。 どんなプロセスであるときにも、欲しくて、それがすべての時間か数まで使用されないように依存できたユニークな数が返されて、それは、SPECIFICからのRECEIVEにUnique Number Processのウェルノウンポートを指定させて、Unique Number ProcessのHostで集合するでしょう。 いずれへのUnique Number Processの未定のSENDはユニークな数を含んでいるでしょう。 また、Unique Number ProcessにはRECEIVEがあるだろう、-、-
Bressler, et al. Experimentation [Page 21] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[21ページ]RFC333メッセージ交換プロトコル実験1972年5月
ANY always pending at another well-known port with local rendezvous specified. At this port the Unique Number Process would receive unique numbers which processes are giving back. The Unique Number Process would maintain a bit table 2-16- bits long indicating the state of each of its unique numbers (free or in use) in some long- term storage medium such as in the file system. The Unique Number Process might also maintain some information about each process to which it gives a unique number so that when the supply of unique number gets depleted, processes can be asked to return them.
地方のランデブーで別のウェルノウンポートでいつも未定のいずれも指定しました。 このポートでは、Unique Number Processはプロセスが返しているユニークな数を受けるでしょう。 Unique Number Processは、ファイルシステムなどのいくらかの長い用語記憶媒体でそれぞれのユニークな番号(自由であるか使用中の)の事情を示しながら、テーブル2-16を少し維持するでしょう長さビットであるのに。 また、Unique Number Processはそれがユニークな数の供給を使い果たすとき、それらを返すようにプロセスに頼むことができるようにユニークな数を与える各プロセスの何らかの情報を保守するかもしれません。
It has already been mentioned that some of the process ID's registered along with their symbolic names at the information operator might be long-term unique numbers gotten from the Unique Number Process. It should also be mentioned that there would seem to be no reason, other than scarcity of storage space, that in addition to the port number through which primary access is gained to a process and which was called the process ID in the previous section, arbitrary port numbers along with their symbolic identified could not be registered with an information operator. For instance, rather than registering the name BBN-FORTRAN and a single port number, one could perhaps register the port numbers whose symbolic identifiers were BBN-FORTRAN-CONTROL-TELETYPE, BBN-FORTRAN-INPUT-FILE, BBN- FORTRAN-LISTING-FILE, and BBN-FORTRAN-BINARY-OUTPUT-FILE. This is perhaps at odds with standard practice within operating systems, but is consistent with the philosophy of reference 4 that communication is done with ports and not processes.
IDがそれらの英字名と共に問い合わせ係に登録したプロセスのいくつかがUnique Number Processから得られた長期のユニークな数であるかもしれないと既に言及されました。 また、集積スペースへの不足以外のどのプライマリアクセスでポートナンバーに加えてプロセスに獲得されたか、そして、前項でプロセスIDと呼ばれた理由が全くあるように思えないと言及されるべきです、任意のポートナンバー、それら、シンボリックである、特定されて、問い合わせ係に登録できませんでした。 例えば、名前BBN-FORTRANとただ一つのポートナンバーを示すよりむしろ、1つは恐らく、シンボリックな識別子がBBN FORTRAN CONTROLテレタイプと、BBN FORTRAN INPUT-FILEと、BBN FORTRAN-LISTING-FILEと、BBN FORTRAN BINARY-OUTPUT-FILEであったポートナンバーを示すかもしれません。 これは、恐らくオペレーティングシステムの中の標準的技法と仲たがいしてありますが、プロセスではなく、ポートでコミュニケーションをするという参照4の哲学と一致しています。
Let us now address an issue which has been ignored up to now and which was only alluded to in reference 4, the issue of port protection. We have not given this matter a great deal of thought; however, one mechanism for port protection seems quite straightforward. The heart of this mechanism is a process at each Host which we shall call (alliteratively) the Port Protection Process (PPP). The PPP maintains a list of all processes which exist at the Host and for each process the numbers of all ports which the process has "legally" obtained. Every time a process does a SEND or RECEIVE, the monitor checks with the PPP to see if the process has specified port numbers it has the right to use; i.e., those legally obtained. The PPP has some RECEIVEs always pending at well-known ports. When one process wants to pass a port to some other process, the first process sends a message to the PPP specifying the number of the port to be sent, the Host number at which the second process resides, a port at which the second process is expecting to receive the port, etc. The PPP looks up in its tables whether the first process has the port it wants to send. If it does, it sends a message to the PPP at the destination site. The message contains the number of the port to be transferred and the RECEIVE port for the destination process. The destination PPP checks in its table whether the process has the
現在これまで無視されて、参照4で暗示されただけである問題を扱いましょう、ポート保護の問題。 私たちは多くの考えをこの件に与えていません。 しかしながら、ポート保護のための1つのメカニズムがかなり簡単に見えます。 このメカニズムの中心は私たちがPort Protection Process(PPP)を呼ぶつもりである(頭韻を踏んで)各Hostのプロセスです。 PPPはプロセスが「法的に」得たHostにおいてすべての数が移植する各プロセスように存在するすべてのプロセスのリストを維持します。 毎回、プロセスはSENDかRECEIVEをします、とモニターはプロセスがポートナンバーを指定したならそれには使用する権利があることを確認するためにPPPに問い合わせます。 すなわち、法的に得られたもの。 PPPには、ウェルノウンポートでいつも未定のいくつかのRECEIVEsがあります。 ある他のプロセスにポートを通り過ぎる1個のプロセス必需品であるときに、最初のプロセスは送られるポートの数を指定するPPPにメッセージを送ります、2番目のプロセスが住んでいるHost番号、2番目のプロセスがポートを受け取る予想であるなどポート 最初のプロセスがそれが送りたがっているポートを持っているか否かに関係なく、PPPはテーブルを調べます。 そうするなら、それは目的地サイトのPPPにメッセージを送ります。 メッセージは移されるべきポートと目的地プロセスのためのRECEIVEポートの数を含んでいます。 プロセスが預けたか否かに関係なく、目的地PPPはテーブルを預けます。
Bressler, et al. Experimentation [Page 22] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[22ページ]RFC333メッセージ交換プロトコル実験1972年5月
RECEIVE port, and if so, passes the new port to the process and updates its tables to indicate the process now possesses the new port. The messages to a PPP will optionally be able to specify that a copy of a port be sent, a port be deleted, etc. The PPPs would probably have some built-in legal ports for each process, particularly the port's processes used to communicate with the PPP. The exact specification requires development but that should not be hard (see (3),(6), and (7) in reference 4). The main difficulty we see is efficient checking of the PPP's tables by the monitor for every RECEIVE or SEND without entirely supplanting the monitor's current protection system.
RECEIVEは、プロセスが今新しいポートを所有しているのを示すためにプロセスへのポートを新しさに渡して、移植して、そうだとすれば、テーブルをアップデートに渡します。 PPPへのメッセージは、ポートのコピーが送られると任意に指定できるでしょう、ポート、削除されてくださいなど。 PPPsには、各プロセス(PPPとコミュニケートするのに使用される特にポートのプロセス)のためのいくつかの内蔵の法的なポートがたぶんあるでしょう。 正確な仕様は開発を必要としますが、それは困難であるべきではありません(参照4で(3)、(6)、および(7)を見てください)。 私たちが見る主な困難はモニターの現在の保護システムに完全に取って代わることのないあらゆるRECEIVEかSENDのためのモニターによるPPPのテーブルの効率的な点検です。
FLOW CHART
フローチャート
The following section describes a flow chart for most of the MSP. A distinction is made between calls made by local processes called SEND and RECEIVE, and messages coming in over the NET called IN and OUT. An additional distinction is made between calls (or messages) with a local rendezvous and those with a foreign rendezvous Host.
以下のセクションはMSPの大部分のためにフローチャートを説明します。 INとOUTと呼ばれるNETの上で入りながら、SEND、RECEIVE、およびメッセージと呼ばれる地方のプロセスによってかけられる電話の間で区別をします。 要求(または、メッセージ)の間で外国ランデブーHostがある地方のランデブーとそれらで追加区別をします。
Since the code is quite similar, the distinction need not be made, but will be included for the sake of clarity.
コードが全く同様であるので、区別は、作られている必要はありませんが、明快のために含まれるでしょう。
It is assumed that the MSP has table provisions for the following items:
MSPには以下の項目のためのテーブル条項があると思われます:
source of message
rendezvous Host
FROM-PORT-ID
TO-PORT-ID
table position
type of message
data size and location
data about the user process
ユーザ・プロセスに関するメッセージデータサイズと位置のデータのメッセージランデブーHost FROM-PORT ID TO-PORT IDテーブル位置のタイプの源
User does a SEND or RECEIVE
ユーザはSENDかRECEIVEをします。
A. Rendezvous is at a foreign host
A.ランデブーが異種宿主にあります。
1. Store the appropriate table data
1. 適切なテーブルデータを保存してください。
2. Send a message to the rendezvous host
2. ランデブーホストにメッセージを送ってください。
a. SEND: OUT + DATA
a。 発信します: アウト+データ
b. RECEIVE: IN
b。 受信します: IN
B. Rendezvous is local - look for entry in table
B.ランデブーは地方です--テーブルでエントリーを探してください。
Bressler, et al. Experimentation [Page 23] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[23ページ]RFC333メッセージ交換プロトコル実験1972年5月
1. Entry NOT found: create entry with appropriate data
1. エントリーは当たりませんでした: 適切なデータでエントリーを作成してください。
2. A matching entry exists in table:
2. 合っているエントリーはテーブルに存在しています:
a. RECEIVE: give user the data
a。 受信します: データをユーザに与えてください。
b. Send a message to the other host (as specified by the source
field of the original msg)
b。 もう片方のホストにメッセージを送ってください。(オリジナルのmsgのソースフィールドによって指定されるように)
1)SEND: OUT+DATA
2)RECEIVE: IN
1) 発信します: アウト+データ2) 受信します: IN
c. Alert user to the fact that transaction is complete
c。 トランザクションが完全であると事実へのユーザに警告してください。
d. Clear table entry
d。 明確なテーブル項目
An IN is received over the NET-search table for matching entry.
合っているエントリーのためのNET-検索テーブルの上にINを受け取ります。
A. No matching entry create an entry with appropriate data.
A. どんなマッチングエントリーも適切なデータでエントリーを作成しません。
B. A match exists
B. マッチは存在しています。
1. Entry was cause by a local SEND
1. エントリーは地方のSENDによる原因でした。
a. Send "OUT _ DATA" to source of IN
a。 「出ている_データ」をINの源に送ってください。
b. Inform user of transaction
b。 トランザクションについてユーザに知らせてください。
c. Clear table entry
c。 明確なテーブル項目
2. Entry was caused by an OUT received over net-acting as third
host.
2. エントリーは3番目としてのネットの芝居ホストの上に受け取られたOUTによって引き起こされました。
a. Send IN to site that created table entry
a。 テーブル項目を作成したサイトに送ってください。
b. Send OUT + DATA (previously buffered) to site sending the IN
b。 + DATA(以前に、バッファリングされる)を送られるサイトに出してください。
c. Clear table entry
c。 明確なテーブル項目
An OUT + DATA is received over the NET -search table for matching entry
検索が合っているエントリーにテーブルの上に置くNETの上にOUT+DATAを受け取ります。
A. No match is found
A. マッチは全く見つけられません。
1. buffer data
1. バッファデータ
2. create appropriate table information
2. 適切なテーブル情報を作成してください。
Bressler, et al. Experimentation [Page 24] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[24ページ]RFC333メッセージ交換プロトコル実験1972年5月
B. A match is found
B. マッチは見つけられます。
1. Table entry was caused by locally executed RECEIVE
1. テーブル項目は局所的に実行されたRECEIVEによって引き起こされました。
a. give data to the user and alert him to its existence.
a. データをユーザに与えてください、そして、存在に彼の注意を喚起してください。
b. send a matching "IN" to the source of the "OUT"
b. 合っている「IN」を“OUT"の源に送ってください。
c. remove entry from table
c. テーブルからエントリーを取り除いてください。
2. Table entry was caused by the receipt of an "IN" over the NET,
thus we are acting as a third party host
2. テーブル項目はネットの上で「IN」の領収書で引き起こされました、その結果、私たちは第三者ホストとして務めています。
a. send the "OUT + DATA" to the host stored in the table
a. 「アウト+データ」をテーブルに保存されたホストに送ってください。
b. send an "IN" to the host from which the "OUT" had just
arrived.
b. “OUT"がちょうど到着したホストに「IN」を送ってください。
MSP VARIATIONS
MSP変化
It may of interest to the reader to know of some of the other MSPs we have considered while arriving at the present one.
それは私たちが現在のものに到着している間考えているのを他のいくつかのMSPsを知る読者への関心についてそうするかもしれません。
The simplest we considered is an MSP based on all rendezvous being done at the destination Host. The sender process sends an OUT- message plus the data to the destination Host. The receiver process does an IN which stays at the receivers Host. The OUT and RECEIVE rendezvous and the data is passed to the receiver process. The transmission is now complete, except in some variations of this MSP an acknowledgement is sent to the sender process. This MSP has couple of disadvantages: In the simplest formulation, the RECEIVE had to be waiting when the OUT+data arrived, otherwise the out data were thrown away. This puts too tight a constraint on the timing of the SEND and RECEIVE, especially since the sender and receiver processes can be a continent apart. However, if the IN is allowed to arrive first and must be held until matched by a RECEIVE, the monitor must buffer an indeterminate amount of data in all cases including the normal one. Further, basing everything on rendezvous at the destination makes the process of moving a port difficult.
私たちが考えた中で最も簡単なものは目的地Hostに行われるすべてのランデブーに基づくMSPです。 送付者の過程はOUTメッセージとデータを目的地Hostに送ります。 受信機の過程は受信機Hostに滞在するINをします。 OUTとRECEIVEは集合します、そして、データは受信機の過程に通過されます。 トランスミッションが現在完全である、このMSPのいくつかの変化を除いて、送付者の過程に承認を送ります。 このMSPには、2、3の損失があります: OUT+データが到着したとき、最も簡単な定式化では、RECEIVEは待たなければなりませんでした。さもなければ、出ているデータは無駄にされました。 これは送付者と受信機の過程が特に大陸であるかもしれない時からSENDとRECEIVEのタイミングにおけるきつ過ぎる規制を離れて置きます。 しかしながら、INを先着するのが許容されていて、RECEIVEによって合わせられるまで主張しなければならないなら、モニターは正常なものを含むすべての場合における不確定のデータ量をバッファリングしなければなりません。 さらに、目的地ですべてをランデブーに基礎づけるのに、ポートを動かす過程は難しくなります。
The next simplest MSP we considered was the IPC of reference 4. This works just the opposite of the above described MSP in that it is based on almost all rendezvous being done at the source Host with two special messages to handle the relatively uncommon cases when a rendezvous must be done at the destination or an intermediate Host. This system, its advantages, and disadvantages is discussed at very great length in the reference.
次の私たちが考えた中で最も簡単なMSPは参照4のIPCでした。 これは、目的地か中間的Hostにランデブーをしなければならないと2つの特別教書でソースHostにする、比較的珍しいケースを扱うほとんどすべてのランデブーに基づいているので、まさしく上の説明されたMSPの正反対を扱います。 参照で非常に大きい長さでそのこのシステム、利点、および損失について議論します。
Bressler, et al. Experimentation [Page 25] RFC 333 MESSAGE SWITCHING PROTOCOL EXPERIMENT May 1972
Bressler、他 実験[25ページ]RFC333メッセージ交換プロトコル実験1972年5月
A third variation on the MSP, suggested by Crowther, is the same as the present MSP in that the OUT and IN rendezvous at a process specified rendezvous Host and the OUT is sent to the source of the IN and the IN to the source of the OUT, but the data is not sent along with the OUT. Instead, when the OUT finally reaches the source of the IN, another message is sent from the receiver Host to the source Host requesting the data to be sent. The data finally is transmitted to the destination in response to this data request message. Our main objection to this system is its lack of symmetry, but we do recognize that it does not require any Host to buffer data for which a process has not set up an input buffer and perhaps for that reason it is a better system than the MSP we are presenting.
クラウザーによって提案されたMSPの3番目の変化はOUTとINが過程で指定されたランデブーHostとOUTを集合させるのでOUTの源へのINとINの源に現在のMSPを送りますが、OUTと共にデータは送らないのと同じです。 OUTが最終的にINの源に達するとき、代わりに、受信機Hostから送られるようデータに要求するソースHostに別のメッセージを送ります。 データは最終的にこのデータ要求メッセージに対応して目的地に送られます。 このシステムへの私たちの主な異論は調和の欠如ですが、私たちは、過程が入力バッファの上と、そして、それが私たちが寄贈しているMSPより良いシステムである恐らくその理由のでセットしていないデータをバッファリングするのが少しのHostも必要としないと認めます。
In the last MSP variation we considered, the difference between SEND or RECEIVE and OUT or IN was discarded. In this case only one message is used which we will call TRANSFER. When a process executes a TRANSFER it can specify an input buffer, an output buffer, both, or neither. Two processes wishing to communicate both execute TRANSFERs specifying the same to and from port ids and the same rendezvous Host. The TRANSFERs result in TRANSFER-messages plus data in the case that an output buffer was specified which rendezvous at the rendezvous Host. When the rendezvous occurs, the TRANSFER-messages plus their data cross and each is sent to the source of the other. The system allows processes not to know whether they must do a SEND, or RECEIVE and is (perhaps) a nice generalization of the MSP presented in this note. For instance, two processes can exchange data using this system, or two processes can kind of interrupt each other by sending dataless TRANSFERs. This variation of the MSP is a development of a suggestion of Steve Crocker. Its disadvantages are: (1) unintentional matches are more likely to occur, (2) rendezvous selection site is more complex, and (3) it's hard to think about.
私たちが考えた最後のMSP変化では、SENDかRECEIVEとOUTかINの違いは捨てられました。 この場合私たちがTRANSFERと呼ぶつもりである使用される1つのメッセージだけ。 過程がTRANSFERを実行するとき、それは指定できます。入力バッファ、出力バッファ、両方、またはどちらも。 交信したがっている2つの過程がHostとポートイドと同じランデブーHostからTRANSFERs指定をともに同じように実行します。 出力バッファが指定されて、TRANSFERsはTRANSFER-メッセージとデータをもたらします(ランデブーHostで集合します)。 ランデブーが起こると、TRANSFER-メッセージとそれらのデータは交差しています、そして、もう片方の源にそれぞれを送ります。 システムは、それらがSEND、またはRECEIVEをしなければならないかどうかを知らないように過程を許容して、(恐らく)この注意に示されたMSPの楽しい一般化です。 例えば、2つの過程がこのシステムを使用することでデータを交換できますか、または2つの過程が、dataless TRANSFERsを送ることによって、互いをちょっと遮ることができます。 MSPのこの変化はスティーブ・クロッカーの提案の開発です。 損失は以下の通りです。 (1) (3) 意図的でないマッチは、より起こりそうです、そして、(2) ランデブー選択サイトは、より複雑です、そして、それは考えにくいです。
APPENDIX
付録
A system for Interprocess Communication in a Resource Sharing Computer Network. Communications of the ACM, April, 1972. Permission to reprint this paper was granted by permission of the Association for Computing Machinery. [Omitted in republished version of RFC 333.]
Resource SharingコンピュータNetworkのInterprocess Communicationのシステム。 1972年4月のACMに関するコミュニケーション。 計算機学会の許可はこの紙を増刷する許可を与えました。 [RFC333の再刊されたバージョンでは、省略されます。]
N.B. The ideas of section 4 of the following paper are in no way critical to the ideas developed in section 3--DCW.
N. B. 以下の紙のセクション4の考えはセクション3で開発された考えに決して重要ではありません--DCW。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Via Genie 3/00 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Via Genie3/00によるオンラインRFCアーカイブへの]
Bressler, et al. Experimentation [Page 26]
Bressler、他 実験[26ページ]
一覧
スポンサーリンク
