RFC46 日本語訳
0046 ARPA Network protocol notes. E. Meyer. April 1970. (Format: TXT=41338 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Edwin E. Meyer, Jr.
Request for Comments: 46 Massachusetts Institute of Technology
17 April 1970
ワーキンググループのエドウィン・E.マイヤー、コメントを求めるJr.Requestをネットワークでつないでください: 46 マサチューセッツ工科大学1970年4月17日
ARPA Network Protocol Notes
アーパネットプロトコル注意
The attached document contains comments and suggestions of the Network Working Group at Project MAC. It is based upon the protocol outlined in NWG/RFC 33, 36, and later documents.
添付書類はProject MACにNetwork作業部会のコメントと提案を含んでいます。 それはNWG/RFC33、36以降ドキュメントに概説されたプロトコルに基づいています。
This proposal is intended as a contribution to the dialog leading to a protocol specification to be accepted by the entire Network Working Group.
この提案はプロトコル仕様につながる対話への貢献として全体のNetwork作業部会によって受け入れられることを意図します。
We solicit your comments.
私たちはあなたのコメントに請求します。
I - INTRODUCTION
私--序論
In this document the Network Working Group at MIT Project MAC suggest modifications and extensions to the protocol specified by Carr, Crocker, and Cerf in a preprint of their 1970 SJCC paper and extended by Crocker in NWG/RFC 36. This document broadly outlines our proposal but does not attempt to be a complete specification. It is intended to be an indication of the type and extent of the protocol we think should be initially implemented.
MITのこのドキュメントNetwork作業部会では、Project MACは1970年のそれらのSJCC論文の前印刷でカー、クロッカー、およびサーフによって指定されて、NWG/RFC36でクロッカーによって広げられたプロトコルに変更と拡大を勧めます。 このドキュメントは、私たちの提案について広く概説しますが、完全な仕様であることを試みません。 それはタイプのしるしであることを意図します、そして、私たちが考えるプロトコルの範囲は初めは、実装されるべきです。
We agree with the basic concept of simplex communication between sockets having unique identifiers. We propose the implementation of a slightly modified subset of the network commands specified in NWG/RFC36 plus the ERR command as specified by Harslem and Heafner in NWG/RFC 40.
私たちは、ユニークな識別子を持ちながら、ソケットの間でシンプレクスコミュニケーションに関する基本概念に同意します。 私たちはNWG/RFC40でNWG/RFC36で指定されたネットワークコマンドとHarslemとHeafnerによる指定されるとしてのERRコマンドのわずかに変更された部分集合の実装を提案します。
Given the basic objective of getting all ARPA contractors onto the network and talking to each other at the earliest possible date, we think that it is important to implement an initial protocol that is reasonably simple yet extendable while providing for the major initial uses of the network. It should be a simple protocol so as to elicit the broadest possible support and to be easily implementable at all installations with a minimum of added software.
すべてのARPA契約者をネットワークに得て、できるだけ早く互いに話す基本的な目的を考えて、私たちは、初期のプロトコルがそれであると実装するのが合理的に簡単であることが、重要であると思いますが、ネットワークの主要な初期の用途に備えている間「広げ-可能」します。 それは可能な限り広いサポートを引き出す簡単なプロトコルであるべきです、そして、容易にであるすべてのインストールのときに最小付記されたソフトウェアで実装可能されます。
While the protocol will evolve, the fundamentals of a protocol accepted and implemented by all installations are likely to prove very resistant to change. Thus it is very important to make the initial protocol open-ended and flexible. A simple basic protocol is more likely to succeed in this respect than a complicated one. This
プロトコルは発展するでしょうが、すべてのインストールで受け入れられて、実装されたプロトコルの原理は変えるために非常に抵抗力があると判明しそうです。 したがって、初期のプロトコルを制限のなくフレキシブルにするのは非常に重要です。 簡単な基本プロトコルはこの点で複雑なものより成功しそうです。 これ
[Page 1]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[1ページ]
does not preclude the existence of additional layers of protocol between several installations so long as the basic protocol remains supported.
基本プロトコルがサポートされたままで残っている限り、いくつかのインストールの間の追加層のプロトコルの存在を排除しません。
We feel that three facilities must be provided for in the initial protocol:
私たちは、初期のプロトコルで3つの施設に備えなければならないと感じます:
1. Multi-path communication between two existing processes which know
how to connect to each other.
1. 互いに接する方法を知っている2つの既存のプロセスのマルチ経路コミュニケーション。
2. A standard way for a process to connect to the logger (logging
process at a HOST) at a foreign HOST and request the creation of a
user process. (The login ritual may or may not be standardized.)
2. プロセスが外国HOSTできこりに接して(HOSTにプロセスを登録します)、ユーザ・プロセスの作成を要求する標準の方法。 (ログイン儀式は標準化されるかもしれません。)
3. A standard way for a newly created process to initiate pseudo-
typewriter communication with the foreign process which requested
its creation.
3. 新たに作成されたプロセスが外国とのコミュニケーションが処理する疑似タイプライタを開始する作成を要求した標準の方法。
The major differences between the protocol as proposed by Carr, Crocker, and Cerf and this proposal are the following:
カー、クロッカー、およびサーフによって提案されるプロトコルとこの提案の主要な違いは以下です:
1. The dynamic reconnection strategy specified in Crocker's
NWG/RFC 36 is reserved for future implementation. We feel that
its inclusion would unduly complicate the initial implementation
of the protocol. We outline a strategy for foreign process
creation that does not require dynamic reconnection. Nothing in
this proposal precludes the implementation of dynamic reconnection
at a later date.
1. クロッカーのNWG/RFC36で指定されたダイナミックな再接続戦略は将来の実装のために予約されます。 私たちは、包含がプロトコルの初期の実装を過度に複雑にすると感じます。 私たちはダイナミックな再接続を必要としない外国プロセス作成のために戦略を概説します。 この提案における何もより後日、ダイナミックな再接続の実装を排除しません。
2. We propose that an "instance tag" be added to the socket
identifier so as to separate sockets belonging to different
processes of the same user coexisting at one HOST.
2. 私たちは、「インスタンスタグ」が1HOSTに共存する同じユーザの異なったプロセスに属すソケットを切り離すためにソケット識別子に追加されるよう提案します。
3. The following NCP commands have been added:
3. 以下のNCPコマンドは加えられます:
a. The ERR command specified in NWG/RFC 40 is included.
a。 NWG/RFC40で指定されたERRコマンドは含まれています。
b. BLK and RSM commands are presented as possible alternatives to
the "cease on link" IMP command and SPD and RSM commands set
forth in NWG/RFC 36. Because these commands operate on socket
connections rather than link numbers, they do not impede the
implementation of socket connection multiplexing over a single
link number, should that later prove desirable.
b。 「リンクの上にやんでください」IMPコマンド、SPD、およびRSMコマンドへの可能な代替手段がNWG/RFC36で旅に出るようにBLKとRSMコマンドは提示されます。 これらのコマンドがリンク番号よりむしろソケット接続を手術するので、ただ一つのリンク番号の上多重送信するソケット接続の実装を妨害しません、それが後で望ましいと判明するなら。
c. An INT command that interrupts a process is specified. We feel
that it is highly important to be able to interrupt a process
that may be engaged in unwanted computation or output. To
implement the interrupt as a special format within a normal
c。 プロセスを中断するINTコマンドは指定されます。 私たちは、求められていない計算か出力に従事するかもしれないプロセスは中断できるのが非常に重要であると感じます。 特別な形式として標準の中で中断を実装するために
[Page 2]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[2ページ]
message raises severe difficulties: the connection may be
blocked when the interrupt is needed, and the NCP must scan
each incoming message for an interrupt signal.
メッセージは厳しい困難を上げます: 中断が必要であるときに、接続は妨げられるかもしれません、そして、NCPは割り込み信号のための各入力メッセージをスキャンしなければなりません。
d. An ECO echoing command to test communications between NCPs is
included.
d。 NCPのコミュニケーションをテストするコマンドを反映するECOは含まれています。
4. Sockets are conceptualized as having several states, and these are
related to conditions under which network requests may be queued.
This differs from the unlimited queuing feature, which presents
certain implementation difficulties.
4. ソケットはいくつかの州を持っているとして概念化されます、そして、これらはネットワーク要求が列に並ばせられるかもしれない状態に関連します。 これは無制限な列を作りの特徴と異なっています。(それは、ある実装困難を提示します)。
5. The protocol regarding creation of a foreign process and
communication with it is removed to a separate User Control and
Communication (UCC) protocol level and is more fully specified.
5. それとの外国プロセスとコミュニケーションの作成に関するプロトコルは、別々のUser ControlとCommunication(UCC)プロトコルレベルに移されて、より完全に指定されます。
II - A HIERARCHY OF PROTOCOLS
II--プロトコルの階層構造
It seems convenient and useful to view the network as consisting of a hierarchy of protocol and implementation levels. In addition to aiding independent software and hardware development, provisions for a layered protocol allow additions and substitution of certain levels in experimental or special purpose systems.
プロトコルと実装レベルの階層構造から成るとネットワークをみなすように便利で役に立つように思えます。 独立しているソフトウェアとハードウェア開発を支援することに加えて、層にされたプロトコルのための条項は実験的であるか専用であるシステムにおける、あるレベルの追加と代替を許します。
We view the initial network communications system as a hierarchy of three systems of increasing generality and decreasing privilege level. These are:
私たちは一般性を増強して、特権レベルを減少させる3台のシステムの階層構造であると初期のネットワーク通信網をみなします。 これらは以下の通りです。
1. IMP Network - The network of IMPs and physical communication lines
is the basic resource which higher level systems convert into more
generalized communication facilities. The IMP network acts as a
"wholesaler" of message transmission facilities to a highly
privileged module within each HOST.
1. IMP Network--IMPsと物理的な通信回線のネットワークは、より高い平らなシステムがさらに一般化された通信機器に変換する基本のリソースです。 IMPネットワークはメッセージ通信施設の「卸売業者」として各HOSTの中で非常に特権があるモジュールに機能します。
2. Network Control Program - Each HOST contains a module called the
Network Control Program (NCP) which has sole control over
communications between its HOST and the IMP network. It acts as a
"retailer" of the wholesale communications facilities provided by
the IMP network. The network of NCPs can be viewed as a higher
level communications system surrounding the IMP network which
factors raw message transmission capabilities between HOSTs into
communication facilities between ordinary unprivileged processes.
2. ネットワークControl Program--各HOSTはHOSTとIMPネットワークとのコミュニケーションの唯一のコントロールを持っているNetwork Control Program(NCP)と呼ばれるモジュールを含んでいます。 大量のコミュニケーション施設の「小売業者」がIMPネットワークで提供したので、それは行動します。 IMPネットワークを囲むより高い平らな通信網としてNCPのネットワークを見なすことができます(HOSTsの間の生のメッセージトランスミッション能力を普通の「非-特権を与え」させられたプロセスの間の通信機器の要因として考慮します)。
[Page 3]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[3ページ]
H O S T A H O S T C
______________________________ ______________________
| | | |
| ____ ____ ____ ____ | | ____ ____ ____ |
| |Proc| |Proc| |Proc| | | | | |Proc| |Proc| | | |
| | A | | B | | C | |UCC | | | | D | | E | |UCC | |
| |____| |____| |____| |____| | | |____| |____| |____| |
| | | | | | | | | | |
- - - - - - |- - - |- - - |- - -|- - -|- - |- - -|- - - |- - - - - -
| | | | | NCP NETWORK | | | |
| | | | | | | | | | |
| _|_____|______|______|_ | | _|_____|______|_ |
| | | | | | | |
| | N C P A | | | | N C P C | |
| |_______________________| | | |________________| |
| || | | || |
|_____________________||_______| |_______||_____________|
|| ||
- - - - - - - - - - - -|| - - - - - - - - - - ||- - - - - - - - - -
|| IMP NETWORK ||
___||___ ____||__
| | | |
| IMP |------------| IMP |
| A | | C |
|________| |________|
| |
| ________ |
| | | |
+------| IMP |-----+
| B |
|________|
H O S TはH O S T Cです。______________________________ ______________________ | | | | | ____ ____ ____ ____ | | ____ ____ ____ | | |Proc| |Proc| |Proc| | | | | |Proc| |Proc| | | | | | A| | B| | C| |UCC| | | | D| | E| |UCC| | | |____| |____| |____| |____| | | |____| |____| |____| | | | | | | | | | | | | - - - - - - |- - - |- - - |- - -|- - -|- - |- - -|- - - |- - - - - - | | | | | NCPネットワーク| | | | | | | | | | | | | | | | _|_____|______|______|_ | | _|_____|______|_ | | | | | | | | | | | N C P A| | | | N C P C| | | |_______________________| | | |________________| | | || | | || | |_____________________||_______| |_______||_____________| || || - - - - - - - - - - - -|| - - - - - - - - - - ||- - - - - - - - - - || 悪童ネットワーク|| ___||___ ____||__ | | | | | 悪童|------------| 悪童| | A| | C| |________| |________| | | | ________ | | | | | +------| 悪童|-----+ | B| |________|
FIG 1. Modular View Of Network
図1。 ネットワークのモジュールの視点
3. User Control and Communication Module - The preceding two
communication systems are sufficient to permit communication
between unprivileged processes that already exist. However, one
of the primary initial uses of the network is thought to involve
the creation of a foreign user process through interaction with
the foreign HOST's logger. The User Control and Communication
Module (UCC) implements protocol sufficient for a process to
communicate with a foreign HOST's logger and to make initial
control communication with a created process. Such a process is
to have the same privileges (subject to administrative control) as
a local (to the foreign HOST) user process. The UCC module
communicates through the NCP in a manner similar to an ordinary
process. Except for the ability to close connections to a dead
3. ユーザControlとCommunication Module--前の2個の通信系が、既に存在する「非-特権を与え」させられたプロセスのコミュニケーションを可能にするために十分です。 しかしながら、外国HOSTのきこりとの相互作用でネットワークのプライマリ初期の用途の1つが外国ユーザ・プロセスの作成にかかわると考えられます。 User ControlとCommunication Module(UCC)道具はプロセスが外国HOSTのきこりとコミュニケートして、作成されたプロセスとの初期のコントロールコミュニケーションを作ることができるくらい議定書を作ります。 そのようなプロセスには、ローカル(外国HOSTへの)のユーザ・プロセスと同じ特権(運営管理コントロールを条件とした)があることになっています。 UCCモジュールはNCPを通って普通のプロセスと同様の方法で交信します。 接続を死者に終える能力を除いて
[Page 4]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[4ページ]
process, the UCC module has no special network privileges. The
UCC protocol is only one of several third-level protocols that
could be implemented. For example, a set of batch processing
systems connected through the NCP system might implement a load-
sharing protocol, but not a UCC.
処理してください、そして、UCCモジュールはどんな特別なネットワーク特権も持っていません。 UCCプロトコルは実装することができたいくつかの第3レベルプロトコルの1つにすぎません。 例えば、NCPシステムを通して接続された1セットのバッチ方式は、UCCではなく、プロトコルを共有しながら、負荷を実装するかもしれません。
III - NETWORK CONTROL PROGRAM
III--ネットワーク・コントロール・プログラム
Each HOST implements a module called the Network Control Program (NCP) which controls all network communications involving that HOST. The network of NCPs forms a distributed communication system that implements communication paths between individual processes. The NCP protocol issues involve: (i) the definition of these communication paths, and (ii) a system for coordinating the distributed NCP system in maintaining these communication paths. These are discussed below.
各HOSTはそのHOSTにかかわるすべてのネットワークコミュニケーションを制御するNetwork Control Program(NCP)と呼ばれるモジュールを実装します。NCPのネットワークはコミュニケーションが個々のプロセスの間の経路であると実装する分配された通信系を形成します。 NCPプロトコル問題は以下にかかわります。 (i) これらの通信路の定義、およびこれらの通信路を維持する際に分配されたNCPシステムを調整する(ii)システム。 以下でこれらについて議論します。
Sockets
ソケット
Communication between two processes is made through a simplex connection between two sockets: a send socket attached to one process and a receive socket attached to another process. Sockets have the following characteristics:
2つのプロセスのコミュニケーションは2個のソケットの間のシンプレクス接続で作られています: aはあるプロセスに取り付けられたソケットを送ります、そして、aは別のプロセスに取り付けられたソケットを受けます。 ソケットには、以下の特性があります:
Socket Identifier - A socket identifier is used throughout the network to uniquely identify a socket. It consists of 48 bits, having the following components:
ソケットIdentifier--ソケット識別子は、唯一ソケットを特定するのにネットワーク中で使用されます。 以下のコンポーネントを持っていて、それは48ビットから成ります:
a. User Number (24 bits) - A socket attached to a process is
identified as belonging to that process by a user number
consisting of 8 bits of "home" HOST code plus 16 bits of user
code assigned by the home HOST. This user number is the same
for all sockets attached to any of his processes in any HOST.
a。 プロセスに取り付けられたソケットは「ホーム」HOSTコードの8ビットとホームHOSTによって割り当てられたユーザコードの16ビットから成るユーザ番号に従ってそのプロセスに属すとして特定されます。ユーザNumber(24ビット)--どんなHOSTの彼のプロセスのいずれにも取り付けられたすべてのソケットに、このユーザ番号は同じです。
b. Instance Tag (8 bits) - More than one process belonging to a
user may simultaneously exist within a single HOST. The
instance tag identifies the particular process to which a
socket belongs. A user's first process at a HOST to use the
network receives instance tag = 0 by convention.
b。 ユーザのものである1つのプロセスが同時に、独身のHOSTの中に存在するかもしれません。インスタンスTag(8ビット)--、十二分である、インスタンスタグはソケットが属する特定のプロセスを特定します。 ネットワークを使用するHOSTのユーザの最初のプロセスはコンベンションでインスタンスタグ=0を受けます。
c. HOST Number (8 bits) - This is the code of the HOST on which
the attached process exists.
c。 HOST Number(8ビット)--これは付属プロセスが存在するHOSTのコードです。
d. Socket Code (8 bits) - This code provides for 128 send and 128
receive sockets in each process. The low order bit determines
whether this is a "send" (= 1) or "receive" (= 0) socket.
d。 ソケットCode(8ビット)--128が発信して、128が各プロセスでソケットを受けるので、このコードは提供されます。 下位のビットは、これが「発信してください」という(= 1)か「受信してください」(= 0)ソケットであるかどうか決定します。
[Page 5]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[5ページ]
States of Sockets - Each socket has an associated state. The NCP may implement more transitory states of a socket, but the three following are of conceptual importance.
Socketsの州--各ソケットには、準国家があります。 NCPはソケットの、より一時的な州を実装するかもしれませんが、3人の次の事柄が概念的に重要です。
a. Inactive - there is no currently existing process which has
told the NCP that it wishes to listen to this socket. No other
process can successfully communicate with an inactive socket.
a。 不活発である、--このソケットを聞きたがっているとNCPに言ったどんな現在既存のプロセスもありません。 他のどんなプロセスも首尾よく不活発なソケットとコミュニケートできません。
b. Open - Some process has agreed to listen to events concerning
this socket but it is not yet connected.
b。 開いてください--あるプロセスが、このソケットに関してイベントを聞くのに同意しましたが、それはまだ接続されていません。
c. Connected - This socket is currently connected to another
socket.
c。 接続されました--このソケットは現在、別のソケットに接続されます。
Socket Event Queue - A queue of events to be disclosed to the owning process is maintained for each open or connected socket. It consists of a chronologically ordered list of certain events generated by the action of one or more foreign processes trying to connect or disconnect this socket. An entry in the event queue consists of the event type plus the identifier of the foreign socket concerned. The following event types are defined:
ソケットEvent Queue--所有プロセスに明らかにされるべきイベントの待ち行列はそれぞれの開いているか接続されたソケットのために維持されます。 それはこのソケットから接続しようとするか、または切断しようとする1つ以上の外国プロセスの動作で生成されたあるイベントの年代順に規則正しいリストから成ります。 イベント待ち行列におけるエントリーは外国ソケットに関するタイプと識別子が関したイベントから成ります。 以下のイベントタイプは定義されます:
a. "request" - a foreign socket requests connection. (not queued
if local socket is already connected)
a。 「要求」--外国ソケットは接続を要求します。 (地方のソケットが既に接続されるなら、列を作りません)
b. "accept" - a foreign socket accepts requested connection.
b。 「受け入れてください」--外国ソケットは要求された接続を受け入れます。
c. "reject" - a foreign socket rejects requested connection.
c。 「廃棄物」--外国ソケットは要求された接続を拒絶します。
d. "close" - a foreign socket disconnects an existing connection.
d。 「近い」--外国ソケットは既存の接続から切断します。
A "request" event is removed from the queue when it is accepted or rejected. The other events are removed from the queue as they are disclosed to the owning process.
それを受け入れるか、または拒絶するとき、待ち行列から「要求」イベントを取り除きます。 所有プロセスにそれらを明らかにするとき、待ち行列から他のイベントを取り除きます。
Some events are intended to be transparent to the process owning the socket, and they do not generate entries in the event queue.
いくつかのイベントがソケットを所有しているプロセスに透明であることを意図して、それらはイベント待ち行列におけるエントリーを生成しません。
Although an event queue is conceptually unlimited, it seems necessary to place some practical limit on its length. When an event queue for a socket is full, any incoming event that would add to the queue should be discarded and the sending NCP notified (via ERR command described below).
イベント待ち行列は概念的に無制限ですが、何らかの実用的な限界を長さに置くのは必要に思えます。 ソケットのためのイベント待ち行列が完全であるときに、待ち行列の一助となるどんな入って来るイベントも捨てられるべきでした、そして、送付NCPに通知しました(以下で説明されたERRコマンドで)。
[Page 6]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[6ページ]
NCP Control Communications
NCPコントロールコミュニケーション
The NCP network coordinates its activities through control commands passed between its individual components. These commands generally concern the creation and manipulation of socket connections controlled by the NCP receiving the command. A control command is directed to a particular NCP by being sent to its HOST as a message over link number 1 (designated as the control link), which is reserved for that purpose. The IMP network does not distinguish between these messages and regular data messages implementing communication through a socket connection.
NCPネットワークは個々のコンポーネントの間で通過された制御コマンドを通した活動を調整します。 一般に、これらのコマンドは作成に関係があります、そして、ソケット接続の操作は、コマンドを受け取りながら、NCPによって制御されました。 制御コマンドは、メッセージとしてHOSTにリンク番号1(コントロールリンクを任じます)の上送ることによって、特定のNCPに向けられます。リンク番号はそのために予約されます。 IMPネットワークはソケット接続でコミュニケーションを実装するこれらのメッセージと通常のデータメッセージを見分けません。
The following NCP control commands are defined:
以下のNCP制御コマンドは定義されます:
a. Request for Connection
a。 接続を求める要求
RFC <local socket> <foreign socket> [<link no.>]
RFCの地方のソケット><外国<ソケット>。[<リンクNo.>]
An NCP directs this command to a foreign NCP to attempt to
initiate a connection between a local socket and a foreign socket.
If the foreign socket is open, the foreign NCP places a "request"
event into the socket's event queue for disclosure to the process
that owns it. If the foreign process accepts, the foreign NCP
returns a positive acknowledgement in the form of another RFC. It
rejects connection by issuing the CLS command (see below). An RFC
is automatically rejected without consulting the owning process if
the foreign socket is not open (inactive or connected). Multiple
RFCs to the same socket are placed into its event queue in order
of receipt. Any queued RFCs are automatically rejected by the NCP
once the owning process decides to accept a connection. The NCP
which has control of the "receive" socket of the potentially
connected pair designates a link number over which messages are to
flow.
NCPは地方のソケットと外国ソケットとの接続を開始するのを試みる外国NCPにこのコマンドを向けます。 外国ソケットが開くなら、外国NCPはそれを所有しているプロセスへの公開のためのソケットのイベント待ち行列に「要求」イベントを置きます。 外国プロセスが受け入れるなら、外国NCPは別のRFCの形で積極的な承認を返します。 それは、CLSコマンドを発行することによって、接続を拒絶します(以下を見てください)。 外国ソケットが開かないなら(不活発であるか接続された)所有プロセスに相談しないで、RFCは自動的に拒絶されます。 同じソケットへの複数のRFCsが先着順にイベント待ち行列に置かれます。 所有プロセスが、接続を受け入れるといったん決めると、どんな列に並ばせられたRFCsもNCPによって自動的に拒絶されます。 「受信してください」という潜在的に接続された組のソケットを管理するNCPはメッセージが流れることになっているリンク番号を指定します。
b. Close a Connection
b。 接続を終えてください。
CLS <local socket> <foreign socket>
CLSの地方のソケット><外国<ソケット>。
An NCP issues this network command to disconnect an existing
connection or to negatively acknowledge an RFC. There is a
potential race problem if an NCP closes a local send socket in
that the CLS command may reach the foreign NCP prior to the last
message over that socket connection. This race is prevented by
adhering to two standards: (i) A CLS command for a local send
socket is not transmitted until the RFNM for the last message to
the foreign socket comes back, and (ii) the foreign NCP processes
all incoming messages in the order received.
NCPは既存の接続から切断するか、または否定的にRFCを承認するこのネットワークコマンドを発行します。 CLSが命令するので閉鎖aローカルがソケットを送るNCPが最後のメッセージの前にそのソケット接続の上で外国NCPに達するかもしれないなら、潜在的人種問題があります。 このレースは2つの規格を固く守ることによって、防がれます: (i) ローカルがソケットを送るので、外国ソケットへの最後のメッセージのためのRFNMが戻るまで、CLSコマンドは伝えられません、そして、(ii)外国NCPは受注におけるすべての入力メッセージを処理します。
[Page 7]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[7ページ]
c. Block Output over a Connection
c。 接続の上のブロック出力
BLK <foreign send socket>
BLK<外国、ソケット>を送ってください。
A process may read data through a receive socket slower than
messages are coming in and thus the NCP's buffers may tend to clog
up. The NCP issues this command to a foreign NCP to block further
transmission over the socket pair until the receiving process
catches up.
Aはメッセージが入っているより遅くソケットを受けます、そして、プロセスが、aを通したデータを読むかもしれないその結果、NCPのバッファは上に妨げる傾向があるかもしれません。 NCPは、受信プロセスが追いつくまでソケット組の上のさらなるトランスミッションを妨げるために外国NCPにこのコマンドを発行します。
d. Resume Output over a Blocked Connection
d。 妨げられた接続の上の出力を再開してください。
RSM <foreign send socket>
RSM<外国、ソケット>を送ってください。
An NCP issues this command to unblock a previously blocked
connection.
NCPは非ブロックとの以前に妨げられた接続をこのコマンドに発行します。
e. Interrupt the Process Attached to a Connection
e。 接続に愛着しているプロセスを中断してください。
INT <foreign socket>
INTの<の外国ソケット>。
Receipt of this message causes the foreign NCP to immediately
interrupt the foreign process attached to <foreign socket> if it
is connected to a local socket. Data already in transit within
the NCP network over the interrupted connection will be
transmitted to the destination socket. The meaning of "interrupt"
is that the process will immediately break off its current
execution and execute some standard procedure. That procedure is
not defined at this protocol level.
このメッセージの領収書で、外国NCPはすぐに、それが地方のソケットに接続されるなら<の外国ソケット>に付けられた外国プロセスを中断します。 既に中断している接続の上のNCPネットワークの中のトランジットにおけるデータは目的地ソケットに送られるでしょう。 「中断」の意味はプロセスがすぐに、現在の実行をやめて、何らかの標準手続きを実行するということです。 その手順はこのプロトコルレベルで定義されません。
f. Report an Erroneous Command to a Foreign NCP
f。 誤ったコマンドを外国NCPに報告してください。
ERR <code> <command length> <command in error>
ERR<コード><コマンド長さの><命令の間違った>。
This command is used to report spurious network commands or
messages, or overload conditions that prevent processing of the
command. <code> specifies the error type. If <code> specifies an
erroneous network command, <command in error> is that command (not
including IMP header) and <command length> is an integer
specifying its length in bits. If <code> specifies an erroneous
message, <command in error> contains only the link number over
which the erroneous message was transmitted. (This is slightly
modified from the specification in NWG/RFC 40.)
このコマンドは、偽りのネットワークコマンドかメッセージを報告するか、または処理するのを防ぐコマンドの状態を積みすぎるのに使用されます。 <コード>は誤りタイプを指定します。 <コード>が誤ったネットワークコマンドを指定するなら、<コマンドの間違った>はコマンド(IMPヘッダーを含んでいない)と<コマンド長さの>がビットの長さを指定する整数であるということです。 <コード>が誤ったメッセージを指定するなら、<コマンドの間違った>は誤ったメッセージが送られたリンク番号だけを含んでいます。 (これはNWG/RFC40の仕様からわずかに変更されます。)
[Page 8]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[8ページ]
g. Network Test Command
g。 ネットワークテスト命令
ECO <48 bit code> <echo switch>
ECO<48ビット・コード><エコースイッチ>。
An NCP may test the quality of communications between it and a
foreign NCP by directing to it an ECO command with an arbitrary
<48 bit code> (of the same length as a socket identifier) and
<echo switch> 'on'. An NCP receiving such a ECO command should
immediately send an acknowledging ECO with the same <48 bit code>
and <echo switch> 'off' to the originating NCP. An NCP does not
acknowledge an ECO with <echo switch> 'off'. We feel that this
command will be of considerable aid in the initial shakedown of
the entire network.
NCPは、48ビットの任意の<コード>(ソケット識別子と同じ長さの)と<エコースイッチ>'on'とのECOコマンドをそれに向けることによって、それと外国NCPとのコミュニケーションの品質をテストするかもしれません。 そのようなECOコマンドを受け取るNCPはすぐに、同じ<48ビット・コード>と<エコースイッチ>'off'と承認ECOを起因するNCPに送るべきです。 NCPは<エコースイッチ>'off'とECOを承認しません。 私たちは、このコマンドが全体のネットワークの初期の調整におけるかなりの援助のものになるのを感じます。
h. No Operation Command
h。 操作命令がありません。
NOP
NOP
An NCP discards this command upon receipt.
NCPは領収書でこのコマンドを捨てます。
User Interface to the NCP
NCPへのユーザーインタフェース
The NCP at each HOST has an interface through which a local process can exercise the network, subject to the control of the NCP. The exact specification of this interface is not a network protocol issue, since each installation will have its own interface keyed to its particular requirements. The protocol requirements for the user interface to an NCP are that it provide all intended network functions and no illegal privileges. Examples of such illegal privileges include the ability to masquerade as another process, eavesdrop on communications not intended for it, or to induce the NCP to send out spurious network commands or messages.
各HOSTのNCPには、地方のプロセスがNCPのコントロールを条件としてネットワークを運動させることができるインタフェースがあります。 このインタフェースの正確な仕様はネットワーク・プロトコル問題ではありません、各インストールでそれ自身のインタフェースを特定の要件に合わせるので。 NCPへのユーザーインタフェースのためのプロトコル要件はすべての意図しているネットワーク機能を提供しますが、どんな不法な特権も提供しないということです。 それかNCPが偽りのネットワークコマンドかメッセージを出すのを引き起こすことを意図しないコミュニケーションを、そのような不法な特権に関する例は別のプロセスのふりをする能力を含んで、立ち聞きしてください。
We outline here an interface based on the Carr, Crocker, and Cerf proposal that is sufficient to fully utilize the network. While this particular set of calls is intended mainly for illustrative purposes, it indicates the types of functions necessary.
私たちはここにネットワークを完全に利用するために十分なカー、クロッカー、およびサーフの提案に基づくインタフェースについて概説します。 この特定のセットの呼び出しは主に説明に役立った目的のために意図しますが、それは必要な状態で機能のタイプを示します。
The following calls to the NCP are available:
NCPへの以下の呼び出しは利用可能です:
a. LISTEN <my 8 bit socket code>
a。 LISTEN<は私の8ビットのソケットコード>です。
A user opens this socket, creating an empty event queue for it.
This LISTEN call may block waiting for the first "request" event,
or it may return immediately.
それのための空のイベント待ち行列を作成して、ユーザはこのソケットを開けます。 このLISTEN呼び出しが最初の「要求」イベントの待ちを妨げるかもしれませんか、またはそれはすぐに、戻るかもしれません。
[Page 9]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[9ページ]
b. INIT <my socket code> <foreign socket>
b。 INIT<は私のソケットコード>の<の外国ソケット>です。
A user attempts to connect <my socket> to <foreign socket>. The
local NCP sends an RFC to the foreign NCP requesting that the
connection be created. The returned acknowledgemnet is either an
RFC (request accepted) or CLS (request rejected). At the caller's
option, the INIT call blocks on the expected "accept" or "reject"
event, or it can return immediately without waiting. In this case
the user must call STATUS (see below) at a later time to determine
the action by the foreign NCP. When a blocked INIT call returns,
the "accept" or "reject" event is removed from the event queue.
ユーザは、<を接続するのを試みます。<外国のソケット>への私のソケット>。 ローカルのNCPは接続が創造されるよう要求する外国NCPにRFCを送ります。 返されたacknowledgemnetはRFC(要求は受け入れた)かCLS(拒絶された要求)のどちらかです。 すぐ待たないで、訪問者の選択では、INITが、予想された「受け入れてください」か「廃棄物」イベントでのブロックと呼ぶか、またはそれは戻ることができます。 この場合、ユーザは、外国NCPで動作を決定するために後でSTATUS(以下を見る)と呼ばなければなりません。 妨げられたINIT呼び出しが戻るとき、イベント待ち行列から「受け入れてください」か「廃棄物」イベントを取り除きます。
c. STATUS <my socket code>
c。 STATUS<は私のソケットコード>です。
This call reports out the earliest previously unreported event in
the queue of <my socket>. The STATUS call deletes the event from
the queue if that type of event is deleteable by disclosure.
この呼び出しは最も早い以前に非報告されたイベントから<の待ち行列で私のソケット>を報告します。 そのタイプのイベントが公開で削除可能であるなら、STATUS呼び出しは待ち行列からイベントを削除します。
d. ACCEPT <my socket code>
d。 ACCEPT<は私のソケットコード>です。
The user accepts connection with the foreign socket whose
"request" event is earliest in the event queue for <my socket>.
An acknowledging RFC is sent to the accepted foreign socket, and
the "request" event is deleted from the event queue. Should any
other "request" event exist in the queue, the NCP automatically
denies connection by sending out a CLS command and deleting the
event.
ユーザはイベントはイベントが最も早いという「要求」が<のために私のソケット>を列に並ばせる外国ソケットとの接続を受け入れます。 受け入れられた外国ソケットに承認RFCを送ります、そして、イベント待ち行列から「要求」イベントを削除します。 NCPは、CLSコマンドを出して、イベントを削除しながら、いかなる他の「要求」イベントも待ち行列で存在するべきであることを自動的に接続を否定します。
e. REJECT <my socket code>
e。 REJECT<は私のソケットコード>です。
The user rejects connection with the foreign socket whose
"request" event is earliest in the event queue for <my socket>.
The NCP sends out a CLS command and deletes the "request" event
from the queue.
ユーザはイベントはイベントが最も早いという「要求」が<のために私のソケット>を列に並ばせる外国ソケットとの接続を拒絶します。 NCPは、CLSコマンドを出して、待ち行列から「要求」イベントを削除します。
f. CLOSE <my socket code>
f。 CLOSE<は私のソケットコード>です。
The user directs the NCP to disconnect any active connection to
this socket and to deactivate the socket. The NCP sends out a CLS
command to the foreign socket if a connection has existed. The
status of the foreign socket also becomes closed once the "close"
event is disclosed to the foreign process.
ユーザはどんな活発な接続からもこのソケットに切断して、ソケットを非活性化するようNCPに指示します。 接続が存在したなら、NCPは外国ソケットにCLSコマンドを出します。 また、「近い」イベントがいったん外国プロセスに明らかにされると、外国ソケットの状態は閉じられるようになります。
g. INTERRUPT <my socket code>
g。 INTERRUPT<は私のソケットコード>です。
The user directs the NCP to send out an INT command to the foreign
socket connected to <my socket>.
ユーザは、外国ソケットへのINTコマンドが<に接続したアウトに私のソケット>を送るようNCPに指示します。
[Page 10]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[10ページ]
h. TRANSMIT <my socket code> <pointer> <nbits>
h。 TRANSMIT<は私のソケットコード><指針><nbits>です。
The user wishes to read (<my socket> is receive) or write (<my
socket> is send) <nbits> of data into or out of an area pointed to
by <pointer>. A call to write returns immediately after the NCP
has queued the data to send a message over the connection. The
call to write blocks only if the connection is blocked or if the
local NCP is too loaded to process the request immediately. Data
to be transmitted over a connection is formatted into one or more
IMP messages of maximum length 8095 bits and transmitted to the
foreign HOST over the link number specified in the RFC sent by the
NCP controlling the receiving connection. A "close" event in the
event queue for <my socket> is disclosed through the action of
TRANSMIT. A call to write discloses the "close" event
immediately. A read call discloses it when all data has been
read.
ユーザが読みたがっている、(<、私のソケット>が受信することである、)、書いてください、(<、私のソケット>が発信することである、)、領域の中、または、<ポインタ>によって示された領域の外へからのデータの<nbits>。 NCP直後リターンを書くという要求は、接続の上にメッセージを送るためにデータを列に並ばせました。 ブロックを書くという要求は接続が単に妨げられるか、ローカルのNCPであるならすぐに要求を処理するのにおいてあまりロードされています。 接続の上に伝えられるべきデータは、最大の長さに関する1つ以上のIMPメッセージに8095ビットフォーマットされて、外国HOSTに受信接続を監督するNCPによって送られたRFCで指定されたリンク番号の上送られます。 出来事における「近い」出来事は<のために列を作ります。私のソケット>はTRANSMITの機能で明らかにされます。 書くという要求はすぐに、「近い」出来事を明らかにします。 すべてのデータを読んであるとき、読書呼び出しはそれを明らかにします。
The History of a Connection From a User View
ユーザ視点からの接続の歴史
An Illustrative Example
説明に役立つ実例
Assume that process 'a' on HOST A wishes to establish connection with process 'b' on HOST B. Before communication can take place, two conditions must be fulfilled:
HOST B.Beforeコミュニケーションの過程'b'との関係を確立するというHOST A願望での過程'a'が行われることができて、2つの条件が達成されなければならないと仮定してください:
a. process 'a' must be able to specify to its NCP a socket in 'b's
socket space to which it wants to connect.
a. 過程'a'は'それが接続したがっているbのソケットスペース'でNCPにソケットを指定できなければなりません。
b. process 'b' must already be LISTENing to this socket.
b. 過程'b'は既にこのソケットへのLISTENingであるに違いありません。
1. Establishing the Connection
1. 接続を確立します。
a. process 'b' LISTENs to socket 'Bb9'.
a. ソケット'Bb9'に'b'LISTENsを処理してください。
b. process 'a' INITs 'Bb9' to its 'Aa12'. The NCP at A generates
an RFC specifying link number = 47, which it chooses from its
available set of links. This is the link over which it will
receive messages if the connection is ACCEPTed by process 'b'.
b. 'a' INITs'Bb9'を'Aa12'に処理してください。 AのNCPはそれが利用可能なセットのリンクから選ぶリンク番号=47を指定するRFCを発生させます。 工程'b'によってこれはそれが接続がACCEPTedであるならメッセージを受け取るリンクです。
c. process 'b' is informed of A's INIT request. He may REJECT
connection (NCP B sends back a CLS) or ACCEPT (NCP B sends back an
RFC).
c. 過程'b'はAのINIT要求において知識があります。 彼はREJECT接続(NCP BはCLSを返送する)かACCEPT(NCP BはRFCを返送する)がそうするかもしれません。
d. If process 'b' ACCEPTs, the confirming RFC establishes the
connection, and messages can now flow.
d。 過程'b'ACCEPTsであるなら、確認しているRFCは接続を確立します、そして、メッセージは現在、流れることができます。
[Page 11]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[11ページ]
HOST A | HOST B
INITIATOR | ACCEPTOR
PROCESS 'a' | PROCESS 'b'
|
|
| a. LISTEN 'socket code 9'
|
|
b. INIT 'socket code 12' 'Bb9' |
RFC 'AA12' 'Bb9' 'link 47' ==========>
|
| c. ACCEPT 'socket code 9'
| RFC 'Bb9' 'Aa12'
|
| d. TRANSMIT 'send buffer' 'len'
| 'socket 9'
<============== IMP message 'link 47' 'send buffer'
|
e. TRANSMIT 'rec buffer' 'length'
'socket 12' ============>
|
| f. CLOSE 'socket code 9'
|
last RFNM ===>
<============== CLS 'Bb9' 'Aa12'
closes socket 'Aa12' |
|
ホストA| ホストB創始者| アクセプタの過程'a'| 過程'b'| | | a。 LISTEN'ソケットコード9'| | b。 INIT'ソケットコード12''Bb9'| RFC'AA12''Bb9''リンク47'==========>|| c。 ACCEPT'ソケットコード9'| RFC'Bb9''Aa12'| | d。 TRANSMITは'バッファ''lenを送ります'。| 'ソケット9'<。============== IMPメッセージ('リンク47'は'バッファを送ります')| e。 TRANSMIT'recバッファ''長さ''ソケット12'============>|| f。 CLOSE'ソケットコード9'| 最後のRFNM===><======= CLS'Bb9''Aa12'はソケット'Aa12'を閉じます。| |
FIG 2. Establishing and Communicating over a Socket Connection
図2。 ソケット接続の上で設立して、交信します。
2. Sending Messages over a Connection.
2. 接続の上にメッセージを送ります。
a. Process 'b' issues a TRANSMIT call to send data through the
connection. NCP B formats this into an IMP message and sends it
to NCP A with link number = 47 as specified by A's RFC.
a。 過程'b'は接続でデータを送るというTRANSMIT要求を発行します。 NCP Bは、AのRFCによる指定されるとしてのリンク番号=47と共にIMPメッセージにこれをフォーマットして、NCP Aにそれを送ります。
b. NCP A receives the raw message from NCP B with link number =
47. NCP A uses this link number in deciding who the intended
recipient is, and stores the message in a buffer for the recipient
process.
b。 NCP Aはリンク番号=47でNCP Bから生のメッセージを受け取ります。 NCP Aは、意図している受取人がだれであるかを決める際にこのリンク番号を使用して、受取人の過程のためのバッファにメッセージを格納します。
c. Process 'a' may issue a read (TRANSMIT) call for socket code 12
at any arbitrary time. The read call blocks if there is no data
pending for the socket. The read call picks up the specified
number of bits transmitted over socket code 12, perhaps across an
IMP message boundary. The boundaries of the IMP messages are
invisible to the read call.
c。 過程'a'は任意の何時でもソケットコード12のための読書(TRANSMIT)呼び出しを発行するかもしれません。 ソケットに、未定のどんなデータもなければ、読みは、ブロックと呼びます。 読みは、ソケットコード12の上に伝えられたビットの指定された数に選択と呼びます、恐らくIMPメッセージ限界の向こう側に。 IMPメッセージの限界は読書呼び出しに目に見えません。
[Page 12]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[12ページ]
d. Should process 'b' send data over the connection at a faster
rate than process 'a' picks it up, NCP A can issue a BLK command
to NCP B if A's buffers start filling. Later, when process 'a'
catches up NCP A can tell B to resume transmission via an RSM
command.
d。 過程'a'がそれを拾うより速いレート、Aのバッファがいっぱいになり始めるならAがNCP BへのBLKコマンドを発行できるNCPで'b'送信データを接続の上に処理するべきです。 過程'a'がその後追いつくとき、NCP Aは、RSMコマンドでトランスミッションを再開するためにBを言うことができます。
3. Process 'b' Closes the Connection
3. 過程'b'は接続を終えます。
a. Process 'b' decides to close the connection, and it issues the
CLOSE call to NCP B. To avoid race problems B waits for the RFNM
from the previous message over this connection, then sends the CLS
command to NCP A. When the RFNM from the CLS command message
returns, NCP B flushes socket 'Bb9' from its tables, effecting the
close at its end and deactivating 'Bb9'.
a。 過程'b'は、接続を終えると決めます、そして、それはNCP B.にCLOSE呼び出しを発行します。ToはBがこの接続の上で前のメッセージからRFNMを待っていて、次に、CLSコマンドをCLSコマンドメッセージリターンからNCP A.When RFNMに送って、NCP Bがテーブルからソケット'Bb9'を洗い流すことにおけるレース問題を避けます、終わりに閉鎖に作用して、'Bb9'を非活性化して。
b. Because of sequential processing within NCP A, the last message
to socket 'Aa12' is guaranteed to have been directed to a process
before the CLS from NCP B comes through. Upon receipt of the CLS
from B, NCP A marks socket 'Aa12' as "close pending" and places a
"close" event into the event queue of 'Aa12'.
b。 NCP Aの中の順次処理のために、ソケットへの'Aa12'という最後のメッセージは、NCP BからのCLSが現れる前に過程に向けられたために保証されます。 BからのCLSを受け取り次第、NCP Aは、「未定の閉鎖」と場所としてのソケット'Aa12'が「近い」出来事であると'Aa12'のイベント待ち行列にマークします。
c. Process 'a' can still issue read calls for socket 'Aa12' while
there is buffered data pending. When 'a' issues a read call after
the buffer has been emptied, the "close" event is disclosed to
inform 'a' of the closure, and socket 'Aa12' is flushed from the
tables of NCP A.
c。 バッファリングされた未定のデータがありましたが、'a'がまだ発行できる過程はソケット'Aa12'のために呼び出しを読みました。 バッファが空にされた後に'a'が読書呼び出しを発行するとき、「近い」出来事は閉鎖について'a'に知らせるために明らかにされます、そして、ソケット'Aa12'はNCP Aのテーブルから洗い流されます。
4. Process 'a' Closes the Connection
4. 過程'a'は接続を終えます。
a. Let us return to step 2. and assume that process 'a' wants to
close the connection from its end. There is no race problem
because we assume that once 'a' issues a CLOSE call, it no longer
wants to read messages over that socket.
a。 戻って、2を踏んで、過程'a'が終わりから接続を終えたがっていると仮定しましょう。 私たちが、'a'がいったんCLOSE呼び出しを発行すると、それがもうそのソケットの上にメッセージを読みたがっていないと思うので、人種問題が全くありません。
b. Assume that process 'a' issues a CLOSE call on socket 'Aa12'.
NCP A immediately sends out a CLS command to NCP B and marks
socket 'Aa12' as "close pending". Any data buffered for read on
'Aa12' is discarded. To allow remaining messages already in
transit from process 'b' to percolate through the IMP network to
NCP A and be discarded without error comments, NCP A retains
'Aa12' in its tables for a suitable period of time after receiving
the RFNM from the CLS command. During this period NCP A discards
all messages received over the closing connection. After allowing
a reasonable amount of time for these dead messages to come in,
NCP A flushes 'Aa12' from its tables, effectively closing the
connection and deactivating 'Aa12'. Further messages to socket
'Aa12' result in NCP A sending an ERR "erroneous command" to the
originating NCP.
b。 過程'a'がソケット'Aa12'でCLOSE呼び出しを発行すると仮定してください。 NCP Aは、すぐに、NCP BにCLSコマンドを出して、「未定の閉鎖」としてソケットが'Aa12'であるとマークします。 読み続けられた'Aa12'のためにバッファリングされたどんなデータも捨てられます。 過程'b'からの既にトランジットでNCP AにIMPネットワークを浸み通らせている、誤りコメントなしで捨てられるべきメッセージのままで残っているのを許容するために、CLSコマンドからRFNMを受けた後に、NCP Aは適当な期間の間、テーブルで'Aa12'を保有します。 この期間、NCP Aは終わりの接続の上に受け取られたすべてのメッセージを捨てます。 入るこれらの死んでいるメッセージのための妥当な時間を許容した後に、NCP Aはテーブルから'Aa12'を洗い流します、事実上、接続を終えて、'Aa12'を非活性化して。 ソケットへの'Aa12'というさらなるメッセージはERR「誤ったコマンド」を由来しているNCPに送るNCP Aをもたらします。
[Page 13]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[13ページ]
c. When NCP B receives the CLS command, socket 'Bb9' is marked as
"close pending", and the CLS event is placed into the event queue
of 'Bb9'. The next time process 'b' wishes to write over that
socket, the CLS event is disclosed to inform him of the closure,
and socket 'Bb9' is removed from NCP B's tables.
c。 NCP BがCLSコマンドを受け取るとき、ソケット'Bb9'は「未定の閉鎖」としてマークされます、そして、CLS出来事は'Bb9'のイベント待ち行列に置かれます。 そのソケットの上に書くという次の時間過程'b'願望、閉鎖について彼に知らせるためにCLS出来事を明らかにします、そして、NCPビーズテーブルからソケット'Bb9'を取り除きます。
IV - USER CONTROL AND COMMUNICATION PROTOCOL
IV--ユーザコントロールと通信プロトコル
Some process must exist which agrees to listen to anybody in the network and create a process for him upon proper identification. This process is called the logger and interacts through the NCP via the network-related User Control and Communication (UCC) module, which implements the necessary protocol. Except for one instance (CLOSEing connections of dead processes), the process operating the UCC module does not have special network privileges.
ネットワークでだれでも言うことを聞いて、適切な識別のときに彼のために過程を作成するのに同意する何らかの過程が、存在しなければなりません。 この過程は、ネットワーク関連のUser ControlとCommunication(UCC)モジュールできこりと呼ばれて、NCPを通して相互作用します。(それは、必要なプロトコルを実行します)。 1つの例(死んでいる過程のCLOSEing接続)以外に、UCCモジュールを操作する過程は特別なネットワーク特権を持っていません。
Under the UCC protocol a "requestor" process which has directed the creation of a "foreign" process maintains two full-duplex pseudo- typewriter connections: one to the foreign logger, and one to the created process. The duplex connection to the foreign logger is used to identify the requestor process to the logger, and after login to return to the requestor process basic information concerning the health of the created process. The duplex connection to the created process is used for control communication to it.
UCCの下では、過程が2全二重疑似に維持する「外国」タイプライタ接続の創造を指示した「要請者」の過程について議定書の中で述べてください: 外国人のきこりへの1、および作成された過程への1。 要請者の過程をきこりに特定するのに使用される、および作成された過程の健康に関して基本の情報を要請者の過程に返すログインの後に、外国人のきこりとの重複の接続があります。 作成された過程との重複の接続はコントロールコミュニケーションのためにそれに慣れています。
Maintaining two full-duplex connections avoids reconnection problems both when the logger transfers communication to the created process and when it needs to regain control. This is at the modest expense of requiring the requestor process to switch typewriter communications between two sets of connections.
2つの全二重接続を維持すると、きこりがともに作成された過程にコミュニケーションを移して、コントロールを取り戻す必要があると、再接続問題は避けられます。 要請者の過程が2セットの接続のタイプライタコミュニケーションを切り換えるのが必要であることの穏やかな費用にはこれがあります。
The way that communication is established is essentially as follows: the requestor process first reserves four of its sockets having contiguous socket codes. Then it "signals" the UCC, specifying one of these sockets. From the "signal" the UCC knows which process is calling, and by protocol, on which requestor socket pair the UCC is to communicate with the requestor process, and which requestor socket pair the created process is to use for its communications. This is specified below in more detail.
コミュニケーションが確立される方法は本質的には以下の通りです: 要請者の過程は最初に、隣接のソケットコードを持っている4個のソケットを予約します。 そして、これらのソケットの1つを指定して、それはUCCに「合図します」。 「信号」から、UCCは、どの過程が呼んでいるかを知って、UCCが要請者の過程とどの要請者ソケット組を伝えることになっているか、そして、どの要請者ソケットが作成された過程を対にするかに関するプロトコルでコミュニケーションの使用に来ています。 これは以下でさらに詳細に指定されます。
Establishing and Operating a Remote Process
リモート過程を確立して、操作します。
The UCC at each HOST always keeps a send socket with user number = 0, instance tag = 0 open (active and unconnected) as a "signal" socket, and periodically checks for INITs to this socket. Processes wishing to create a process at this HOST must first signal the UCC by issuing an INIT to this socket.
HOSTがaであることをいつも保つそれぞれのUCCはユーザ番号=0があるソケットを送ります、と例のタグ=0がこのソケットに「信号」ソケットとして開いて(アクティブで無関係の)、INITsがないかどうか定期的にチェックします。 これのHOSTが最初にINITを発行しながらUCCに合図しなければならない過程をこのソケットに作成することを願いながら、処理します。
[Page 14]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[14ページ]
The requesting process must have four free sockets with contiguous socket codes: <base_socket> (receive) through <base_socket+3> (send). The high numbered send/receive set of sockets is used for typewriter communication with the foreign UCC, the low numbered set for typewriter communication with the created process.
要求の過程に、隣接のソケットコードがある4個の無料のソケットがなければなりません: <ベース_ソケット+3>(発信する)を通した<ベース_ソケット>(受信します)。 付番された高値は、外国UCC(作成された過程とのタイプライタコミュニケーションのための低番号付のセット)とのタイプライタコミュニケーションのために使用されるソケットのセットを送るか、または受けます。
1. The "requestor" process calls LISTEN twice to open the <base_socket+2> and <base_socket+3> receive/send pair over which it will talk to the foreign UCC. Then it sends out a "signalling" INIT call on <base_socket> to the UCC "signal" socket. The only thing that the UCC does with this "signalling" INIT call is to note down the socket number <base_socket> from which it originated. The UCC immediately rejects this request so as to keep its "signal" socket open for other signals.
1. 二度<を開くLISTENが_ソケット+2>と<ベース_ソケット+3>を基礎づけるという「要請者」過程要求は、それが外国UCCと話す組を受けるか、または送ります。 そして、それはINITが訪問する「合図」<ベース_ソケット>をUCC「信号」ソケットに出します。 UCCがこの「合図」INIT呼び出しでする唯一のことはそれが由来したソケット数の<ベース_ソケット>を書き留めることです。 UCCは、すぐに、「信号」ソケットを他の信号において開くように保つためにこの要求を拒絶します。
2. After receiving the expected REJECT on its initial INIT call to the UCC's signal socket, the requestor process issues LISTENs for <base_socket> and <base_socket+1>. (The created process will INIT these sockets to establish control communication with the requestor process.) The requestor process then blocks by calling STATUS <base_socket+2> .
2. UCCの信号ソケットへの初期のINIT呼び出しに予想されたREJECTを受けた後に、要請者の過程は<ベース_ソケット>と<ベース_ソケット+1>のためにLISTENsを発行します。 (作成された過程は要請者の過程とのコントロールコミュニケーションを証明するためにこれらのソケットをINITに望んでいます。) そして、要請者の過程は呼んでいるSTATUS<ベースのそばで_ソケット+2>を妨げます。
3. The UCC INITs a free send/receive socket pair to the requestor's <base_socket+2> and <base_socket+3> on which the requestor process is presumably LISTENing. The requestor process has called STATUS <base_socket+2> with block option after LISTENing for the two sockets, so that when the INIT from the foreign UCC reaches the requestor process, STATUS returns with the INIT indication. The requestor process verifies that the UCC is the process that is calling, then it ACCEPTs the call. The requestor process then calls STATUS <base_socket+3> and returns when the INIT for that socket reaches it. It does a similar verify and ACCEPT. (There is an arbitrary choice as for which socket the requestor process first calls STATUS.) Two way communication is established when the requestor process has ACCEPTed both INITs from the UCC. This connection is maintained during the login ritual and throughout the life of the created process. Should the requestor process fail to respond properly within a limited amount of time to the INITs of the UCC, the UCC abandons the connection attempt.
3. aを有でないUCC INITsはおそらく、要請者の過程がLISTENingである要請者の<ベースの_ソケット+2>と<ベース_ソケット+3>にソケット組を送るか、または受けます。 要請者の過程は、2個のソケットのためにLISTENingの後のブロックオプションでSTATUS<ベース_ソケット+2を>と呼びました、外国UCCからのINITが要請者の過程に達すると、STATUSがINIT指示とともに帰るように。 要請者の過程は、UCCが呼んでいる過程であることを確かめて、次に、それはACCEPTsです。呼び出し。 要請者の過程は、次に、STATUS<ベース_ソケット+3を>と呼んで、そのソケットのためのINITがそれに達すると、戻ります。 aをする、同様である、検証、そして、ACCEPT。 (要請者の過程が、最初にどのソケットに関してSTATUSと呼ぶかとして気紛れな選択があります。) 要請者の過程にACCEPTedがある双方向通信は確立されます。UCCからの両方のINITs。 この接続はログイン儀式と作成された過程の人生の間中維持されます。 要請者の過程が適切に限られた時間内にUCCのINITsに応じないなら、UCCは接続試みを捨てます。
4. The requestor process must then perform the login ritual with the UCC. (The initial protocol might standardize the login ritual.) If the logger is not satisfied and wishes to cut off the requestor, the UCC module CLOSEs both <base_socket+2> and <base_socket+3>, perhaps after the logger has sent a suitable message.
4. そして、要請者の過程はUCCと共にログイン儀式を実行しなければなりません。 (初期のプロトコルはログイン儀式を標準化するかもしれません。) きこりが満足していないか、そして、要請者、UCCモジュールCLOSEsから<ベース_ソケット+2>と<の両方を切るという願望は_ソケット+3>を基礎づけます、きこりが恐らく適当なメッセージを送った後に。
[Page 15]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[15ページ]
5. If satisfied, the logger creates a process for the user. The UCC maintains direct communication with the requestor, but this connection is now used only to report basic information concerning the created process.
5. 満たされているなら、きこりはユーザのために過程を作成します。 UCCは要請者とのダイレクトコミュニケーションを維持しますが、この接続は現在、使用されますが、作成された過程に関して基本情報を報告します。
6. The first task of a created process is to establish a dual pseudo-typewriter control connection with its requestor process. The created process INITs one of its send/receive socket pairs to the requestor's <base_socket> and <base_socket+1>. If both requests are ACCEPTed, the created process sends an initial message over this connection. Then it goes to command level, in which it awaits a typewriter command message over the connection. If the created process is unable to establish duplex communication with the requestor process, it should destroy itself. The UCC will either CLOSE its own connections with the requestor or make arrangements for another process to be created.
6. 作成された過程の最初のタスクは要請者の過程との二元的な疑似タイプライタコントロール関係を確立することです。 作成がINITs1を処理する、それ、要請者の<ベース_ソケット>と<ベース_ソケット+1>にソケット組を送るか、または受けてください。 両方の要求がACCEPTedであるなら、作成された過程はこの接続の上に初期のメッセージを送ります。 そして、それはレベルを命令しに行きます。(そこでは、それが接続の上でタイプライタコマンドメッセージを待ちます)。 作成された過程が要請者の過程との重複のコミュニケーションを確立できないなら、それは自滅するべきです。 要請者とのそれ自身の接続か別のもののための造のアレンジメントが作成されるために処理するUCC意志のCLOSE。
7. When a created process is logged-out, the UCC uses a privileged entry to the NCP to CLOSE all connections between the dead process and other processes, and to deactivate all open sockets of the dead process. The UCC transmits a message back to the requestor process, then CLOSEs the dual connections between it and the requestor process.
7. 作成された過程がログアウトされるとき、UCCは死者の間のすべての接続が処理するCLOSEへのNCPと他の過程に特権があるエントリーを使用します、そして、非活性化するために、死者のすべての開いているソケットが処理されます。 UCCは要請者の過程に送信して戻って、次に、それと要請者との二元的な接続のCLOSEsは処理します。
8. The INTERRUPT call has a standard "quit" meaning when sent from a requestor process to a created process over the requestor's receive socket <base_socket>. All pending output from the created process is aborted, and the it enters "command level" where it awaits a command over the typewriter connection to the requestor process. The interrupted processing is resumable by issuing a "start" command to the created process. (Note that the rule about pending output is more restrictive than that implemented by the INT NCP command.)
8. INTERRUPT呼び出しは、規格が、要請者のものの上で要請者の過程から作成された過程に送ったらソケット<ベース_ソケット>を受けるように意味するのを「やめること」を持っています。 そして、作成された過程からのすべての未定の出力が中止になる、それはタイプライタ接続の上のコマンドを要請者の過程に待つところに「コマンドレベル」を入れます。 中断している処理は、「始め」コマンドを作成された過程に発行することによって、再開可能です。 (未定の出力に関する規則がINT NCPコマンドで実行されたそれより制限していることに注意してください。)
This document was prepared through the use of the MULTICS "runoff"
command. A source file consisting of intermixed text and "runoff"
requests was created using the "qed" text editor. This file was
then compiled by the "runoff" command to produce a finished copy.
The latest version of this document exists online in MULTICS in
the segment
このドキュメントはMULTICS「決勝戦」コマンドの使用で準備されました。 混ぜられたテキストから成るソースファイルと「決勝戦」要求は、"qed"テキストエディタを使用することで作成されました。 そして、このファイルは完成コピーを生産する「決勝戦」コマンドでコンパイルされました。 このドキュメントの最新版はMULTICSにセグメントでオンラインで存在しています。
>udd>Multics>Meyer>network_protocol.runoff
>udd>Multics>マイヤー>ネットワーク_protocol.runoff
(END)
(終わり)
[Page 16]
RFC 46 ARPA Network Protocol Notes April 1970
RFC46アルパネットワーク・プロトコルが1970年4月に注意する[16ページ]
REQUESTOR FOREIGN
PROCESS LOGGER
-------------- -------------
a. LISTEN to sockets
<base_socket+2> and
<base_socket+3> to be
connected to foreign logger.
要請者の外国人の過程きこり-------------- ------------- a。 ソケット<へのLISTENは、外国人のきこりに接されるために_ソケット+2>と<ベース_ソケット+3>を基礎づけます。
b. INIT <base_socket>
to "signal" socket of
foreign logger.
=======================================>
b。 外国人のきこりの「信号」ソケットへのINIT<ベース_ソケット>。 =======================================>。
c. remember <base_socket>
and REJECT connection
to signal socket.
c. <ベース_ソケット>とREJECT接続を覚えていて、ソケットに合図してください。
d. LISTEN to sockets e. INIT a logger socket
<base_socket> and pair to the requestor's
<base_socket_1> to be <base_socket+2> and
connected to the created process. <base_socket+3>.
/
<==========================/
d。 ソケットeへのLISTEN。 要請者の<へのINIT aきこりのソケット<ベース_ソケット>と組は、作成された過程に>の、そして、関連している<ベース_ソケット+2になるように__1ソケット>を基礎づけます。 <ベース_ソケット+3>。 /<。==========================/
f. ACCEPT connection
with sockets from
foreign logger.
f。 外国人のきこりからのソケットとのACCEPT接続。
PERFORM LOGIN RITUAL
CREATED
PROCESS
-------------
g. INIT any socket pair
to requestor's
<base_socket> and
<base_socket+1>
/
<===========================/
h. ACCEPT connection
with sockets from created
process.
ログインの儀式の作成された過程を実行してください。------------- g。 どんなソケットも要請者の<ベース_ソケット>と<ベース_ソケット+1>/<と対にするINIT===========================/h。 作成された過程からのソケットとのACCEPT接続。
FIG. 4 Establishing a Process at a Foreign HOST
図 4 異種宿主で過程を確立すること。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Miles McCredie 11/99 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Milesマクレディー11/99によるオンラインRFCアーカイブへの]
[Page 17]
[17ページ]
一覧
スポンサーリンク
