RFC705 日本語訳
0705 Front-end Protocol B6700 version. R.F. Bryan. November 1975. (Format: TXT=70998 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Request for Comments: 705 NIC# 33644
コメントを求めるワーキンググループ要求をネットワークでつないでください: 705 NIC#33644
FRONT - END PROTOCOL
前部--終わりのプロトコル
B6700 VERSION
B6700バージョン
2 September 1975
1975年9月2日
This is a working document which has been developed as the specification and guideline for design of a Burroughs B6700 attachment to an ARPA-Style network.
これはARPA-様式ネットワークへのバローズのB6700付属のデザインのための仕様とガイドラインとして開発された働くドキュメントです。
The approach is to utilize a front-end processor with a new protocol for network operation. That protocol, described herein, has been built upon the concepts expressed by M.A. Padlipsky, et al, in NIC# 31117, RFC# 647.
アプローチは新しいプロトコルがあるフロントエンドプロセッサをネットワーク操作に利用することです。 ここに説明されたそのプロトコルはM.A.Padlipskyによって言い表された概念で築き上げられました、他、NIC#31117、RFC#647で。
This proposed, site-specific, FEP implementation is the work of Gerald Bailey and Keith McCloghrie of NSA and of David Grothe of ACC. It has already sustained some corrections provided by MAP. It will be helpful if interested networkers will review and provide comments to us.
この提案されて、サイト特有のFEP実装はNSAのジェラード・べイリーとキースMcCloghrieとACCのデヴィッド・グローテの仕事です。 それは既にMAPによって提供されたいくつかの修正を支えました。 関心があるネットワーカーがコメントを私たちに見直して、提供すると、役立つでしょう。
Comments to BRYAN@ISI.
BRYAN@ISI へのコメント。
Roland Bryan - ACC 1
ローランド・ブライアン--ACC1
Network Working Group Request for Comments: 705 Front-End Protocol: B6700 Version
コメントを求めるワーキンググループ要求をネットワークでつないでください: 705 フロントエンドプロトコル: B6700バージョン
***WORKING DOCUMENT***
***働くドキュメント***
FRONT-END PROTOCOL
フロントエンドプロトコル
PREFACE
序文
This document describes the protocol to be used for connecting a general- purpose computer system (host) to an ARPANET-like network via a "front-end" computer. The main body of the document is aimed at a reader who is not conversant with all the details of network protocols. However, a paragraph marked with [n], refers a reader familiar with network protocols to the n-th item of Appendix A which will amplify that particular paragraph. Further information on the network protocols referred to in this document can be obtained from the Network Information Center.
このドキュメントは、「フロントエンド」コンピュータを通して一般的な目的コンピュータ・システム(ホスト)をアルパネットのようなネットワークに接続するのに使用されるためにプロトコルについて説明します。 ドキュメントの本体はネットワーク・プロトコルに関する一部始終で詳しくない読者を対象にします。 しかしながら、aは、その特定のパラグラフについて敷衍するAppendix Aの第n項目に[n]で著しい状態で短い記事を書いて、ネットワーク・プロトコルに詳しい読者を差し向けます。 Networkインフォメーション・センターから示されたネットワーク・プロトコルに関する詳細を本書では得ることができます。
Appendix B contains diagrams showing the transitions between the different connection states. Appendices C and D give the implementation details of this protocol in the Front-End and the Hosts.
付録Bは異なった接続州の間に変遷を示しているダイヤグラムを含んでいます。 付録CとDはFront-終わりとHostsのこのプロトコルの実装詳細を明らかにします。
This protocol is predicated upon the assumption that for each host, a line protocol, at a lower level, will be established between the device-driver modules in the Host and the Front-End, and that this line protocol provides Front-End Protocol with error-free transmissions.
このプロトコルは各ホストに関して、系列プロトコルがHostのデバイスドライバモジュールとFront-終わりの間で下のレベルで確立されて、この系列プロトコルがFront-終わりのプロトコルにエラーのないトランスミッションを提供するという仮定で叙述されます。
INTRODUCTION 2
序論2
A host computer may be connected to a network for a variety of reasons. Network connection may be an attempt to expand the usefulness of the Host to the community of users which it serves by making network resources available to them. Conversely, the services which the Host provides may be made available to a larger community of users, with the network providing the method of access to those services.
ホストコンピュータはさまざまな理由でネットワークに接続されるかもしれません。 広がる試みがネットワーク資源をそれらに利用可能にすることによってそれが役立つユーザの共同体へのHostの有用性であったかもしれないなら接続をネットワークでつないでください。 逆に、ユーザの、より大きい共同体はHostが提供するサービスを入手するかもしれません、ネットワークがそれらのサービスへのアクセスのメソッドを提供していて。
In order for members of a network community to communicate in an intelligent way, there must exist a set of protocols. The implementation of these protocols in a host computer is typically called the Network Control Program (NCP). The size and complexity of the NCP is proportional to the number and complexity of protocols which it implements. For an ARPANET like network, both the number and complexity are substantial.
知的な方法で伝えるネットワーク共同体のメンバーにとって整然とします、1セットのプロトコルは存在しなければなりません。 ホストコンピュータのこれらのプロトコルの実装は通常Network Control Program(NCP)と呼ばれます。 NCPのサイズと複雑さはそれが実装するプロトコルの数と複雑さに比例しています。 ネットワークのようなアルパネットにおいて、数と複雑さの両方が実質的です。
***WORKING DOCUMENT***
***働くドキュメント***
1
1
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
A host which directly connects into the network must assume the responsibility for implementing this set of protocols. That is the "price of admission" to become a network host. It is not necessary to implement every protocol and every option in every host, but even in the simplest case -- implementation of an NCP is not a small task. The intrusion into the normal operating environment of the host is also not small.
直接ネットワークに接続するホストはこのセットのプロトコルを実装することへの責任を負わなければなりません。 それはネットワークホストになる「入場料」です。 それはすべてのホストのあらゆるプロトコルとあらゆるオプションを実装するのに必要であるのではなく、最も簡単な場合で同等です--NCPの実装は小さいタスクではありません。 また、ホストの正常な操作環境への侵入も小さくはありません。
An alternative method for network connection is to connect the host to some intermediate processor, and in turn, directly connect that processor to the network. This approach is called "Front-Ending." There are many arguments which may be posed to justify a host connection to a network through a front- end processor. The most obvious being that the responsibility for implementation of the network protocols (the NCP) can be delegated to the front-end (FE), thereby reducing the impact on the host.
ネットワーク接続のための別法は、ある中間的プロセッサにホストを接続して、順番に、直接そのプロセッサをネットワークに接続することです。 このアプローチは「前の結末」であると呼ばれます。 前部エンドプロセッサを通してホスト接続をネットワークに正当化するために引き起こされるかもしれない多くの議論があります。 最も明白であるのは、ネットワーク・プロトコル(NCP)の実装への責任をフロントエンド(FE)へ代表として派遣することができるということです、その結果、ホストで影響を減少させます。
The purpose of this document is not to justify Front-Ending as a philosophy, but rather, to introduce a protocol for communications between a host and a front-end processor which is providing it network access. The Front End Protocol (FEP) is intended to permit the host to make use of the network through existing protocols, without requiring that it be cognizant of the complexities and implementation detail inherent in their execution.
このドキュメントの目的が哲学としてFront終わるのを正当化しないことですが、ホストとそれを提供しているフロントエンドプロセッサとのコミュニケーションのためにプロトコルを紹介するために、むしろ、アクセサリーをネットワークでつないでください。 Front Endプロトコル(FEP)が、ホストが既存のプロトコルを通してネットワークを利用することを許可することを意図します、彼らの実行の固有である複雑さと実装の詳細を認識している必要でない。
The FEP is sufficiently general to permit its implementation in the host to be in terms of the function the host is performing, or the services which it is providing. Of primary consideration in specification of FEP was that it must provide the host with a sufficiently robust command repertoire to perform its network tasks, while buffering it from the details of network protocols.
FEPはホストの実装がホストが実行している機能、またはそれが提供しているサービスであることを許可できるくらい一般的です。 中のプライマリ考慮では、FEPの仕様はネットワークタスクを実行するためにネットワーク・プロトコルの詳細からそれをバッファリングしている間十分強健なコマンドレパートリーをホストに提供しなければならないということでした。
CONCEPTS 3
概念3
Introduction 3a
序論3a
Before a detailed description of the command structures is undertaken it seems appropriate to introduce several of the concepts upon which the FEP is predicated.
命令系統の詳述が引き受けられる前に、FEPが叙述されるいくつかの概念を紹介するのは適切に思えます。
The following section serves to briefly describe the FEP commands, and to elaborate on the concepts of addressing and types of connections provided.
以下のセクションは簡潔にFEPコマンドについて説明して、アドレシングの概念について詳しく説明するのに役立ちます、そして、接続のタイプは前提としました。
***WORKING DOCUMENT***
***働くドキュメント***
2
2
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Commands (General) 3b
(一般)の3bを命令します。
1. BEGIN Command
1. 始まりコマンド
This command is sent from the host to the front-end processor. Its function is to direct the establishment of one or more network connections. The type and number of connections is specified in the BEGIN command string.
このコマンドをホストからフロントエンドプロセッサに送ります。 機能は1人以上のネットワーク接続の設立を指示することです。 タイプとポートの数はBEGINコマンドストリングで指定されます。
2. LISTEN Command
2. 聴取コマンド
Through this command the host indicates its willingness to accept requests for connection arriving from other hosts. It directs the front-end processor to LISTEN for any such connection requests. The number and type of connections are specified in the command string.
このコマンドで、ホストは他のホストから到着する接続を求める要求を受け入れる意欲を示します。 それはどんなそのような接続要求のためにもLISTENにフロントエンドプロセッサを向けます。 接続の数とタイプはコマンドストリングで指定されます。
3. RESPONSE Command
3. 応答命令
The front-end processor uses the RESPONSE command to indicate to the host that a particular path specified in a BEGIN or LISTEN command is now open or that the open attempt failed.
フロントエンドプロセッサはBEGINで指定された特定の経路かLISTENコマンドが現在、開いているか、または開いている試みが失敗したのをホストに示すRESPONSEコマンドを使用します。
4. MESSAGE Command
4. メッセージコマンド
Message text passing between the host and its front-end processor is sent in this command string. The MESSAGE command is bi-directional, and is the same for host or front-end.
このコマンドストリングでホストとそのフロントエンドプロセッサの間で終わるメッセージ・テキストを送ります。 MESSAGEコマンドは、双方向であり、ホストかフロントエンドに、同じです。
5. INTERRUPT Command
5. 中断命令
The INTERRUPT command is sent by either the host of FE. Its most common use is to convey that the user wishes to terminate what he is doing - i.e., he has depressed the Control-C, ATTN, or INT key.
INTERRUPTコマンドはFEのホストによって送られます。 最も一般的な使い方はユーザがしていることを終えたがっているのを運ぶことです--すなわち、彼はControl-C、ATTN、またはINTキーを押し下げました。
6. END Command
6. 終わりのコマンド
One or more connections may be closed by either the FE or the host issuing this command. The connection(s) which are affected by the action of the END are specified in the command string.
このコマンドを発行するFEかホストのどちらかが1つ以上の接続を閉店させるかもしれません。 ENDの機能で影響を受ける接続はコマンドストリングで指定されます。
7. REPLY Command
7. 応答コマンド
This command is required to be sent by both the host and FE to acknowledge receipt of all command types (except REPLY). The success or failure of the command being acknowledged is conveyed in the REPLY command string.
このコマンドが、ホストとFEの両方で送るのにすべてのコマンドの領収書がタイプされる(REPLYを除いて)と認めるのに必要です。 承諾されるコマンドの成否はREPLYコマンドストリングを運ばれます。
***WORKING DOCUMENT***
***働くドキュメント***
3
3
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Connections 3c
コネクションズ3c
In order to engage in a meaningful conversation, the parties involved must be connected. A network connection is defined by the ARPA Host-Host Protocol document (Nic #8246) as follows : "A connection couples two processes so that output from one process is input to the other. Connections are defined to be unidirectional, so two connections are necessary if a pair of processes are to converse in both directions." The components of a connection, the sockets, are defined: "... a socket forms the reference for one end of a connection, and a connection is fully specified by a pair of sockets. A socket is identified by a Host number and a 32-bit socket number. The same number in different Hosts represents different sockets."
重要な会話に従事するために、かかわったパーティーに接しなければなりません。 以下のARPA Host-ホストプロトコルドキュメント(Nic#8246)によってネットワーク接続は定義されます: 「接続は1つのプロセスからの出力がもう片方に入力されるように、2つのプロセスを結合します。」 「コネクションズが単方向になるように定義されるので、1組のプロセスが両方の方向に話すつもりであるなら、2つの接続が必要です。」 接続のコンポーネント(ソケット)は定義されます: 「… ソケットは接続の片端の参照を形成します、そして、接続は1組のソケットによって完全に指定されます。」 ソケットはHost番号と32ビットのソケット番号によって特定されます。 「異なったHostsの同じ数は異なったソケットを表します。」
The existing network protocols incorporate prescribed strategies for selecting socket assignments, pairing sockets to form connections, and in the number of connections required to implement the protocol.
プロトコルが法人組織にする既存のネットワークが、接続を形成するためにソケットを対にして、ソケット課題を選択するための戦略が定められて、ポートの数でプロトコルを実装するのが必要です。
Conversations, in most cases, are bi-directional. Thus to simplify the Host's procedures in these cases, FEP permits duplex connections on which the Host can both send and receive. Send only and Receive only connections are also available for those situations where communication is one-way.
多くの場合、会話は双方向です。 したがって、これらの場合におけるHostの手順を簡素化するために、FEPはHostが発信して、受信できる重複の接続を可能にします。 発信、唯一、Receive、また、接続だけもコミュニケーションが一方向であるそれらの状況に手があいています。
Thus, FEP provides the flexibility to reduce complexity in the Host, in addition to accommodating existing protocols and allowing for the development of new protocols.
したがって、FEPはHostで複雑さを減少させるために柔軟性を提供します、既存のプロトコルに対応して、新しいプロトコルの開発を考慮することに加えて。
Addressing 3d
3dを扱います。
Conversations in FEP are uniquely identified at initiation by some combination of Host address, Index number, Path number and Socket assignment. The Host address and Socket assignment are required to form the connection(s); there- after the Index and Path are sufficient to identify the conversation.
FEPでの会話は開始でHostアドレス、Index番号、Path番号、およびSocket課題の何らかの組み合わせで唯一特定されます。 HostアドレスとSocket課題が接続を形成するのに必要です。 そこでは、後に、IndexとPathが、会話を特定するために十分です。
Host Address
ホスト・アドレス
If, through the BEGIN command, the local Host explicitly directs the creation of network connection(s), it must specify the address of the foreign host to which it desires communication. If the local host indicates a willingness to communicate, through the LISTEN command, the Front-End processor will supply the address of the connecting foreign host(s) in its RESPONSE command(s).
地方のHostがBEGINコマンドで明らかにネットワーク接続の作成を指示するなら、それはそれがコミュニケーションを望んでいる異種宿主のアドレスを指定しなければなりません。 ローカル・ホストがLISTENコマンドで交信する意欲を示すと、Front-エンドプロセッサはRESPONSEコマンドで接続異種宿主のアドレスを供給するでしょう。
***WORKING DOCUMENT***
***働くドキュメント***
4
4
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Socket
ソケット
A socket is either a send socket or a receive socket. This property is called the socket's gender. The sockets at either end of a network connection must be of opposite gender. As previously defined a socket forms the reference for one end of a network connection. To the extent possible, the FEP shields the Host from the responsibility of assigning sockets for individual conversations. However, because the socket is a fundamental part of the addressing mechanism of the network, the Host may need to be aware of socket assignments when establishing connections.
ソケットによるaがソケットを送るか、またはaがソケットを受けるということです。 この特性はソケットの性と呼ばれます。 ネットワーク接続のどちらかの終わりのソケットは反対の性のものであるに違いありません。 以前に定義されるように、ソケットはネットワーク接続の片端の参照を形成します。 可能な範囲内で、FEPは個々の会話のためのソケットを割り当てる責任からHostを保護します。 しかしながら、ソケットがネットワークのアドレシングメカニズムの基本的な部分であるので、Hostは、関係を樹立するとき、ソケット課題を意識している必要があるかもしれません。
It is through a "well-advertised" socket that a host provides services to other members of the network community. The Initial Connection Protocol (ICP) [1] is used to first connect to the well-advertised socket in order to exchange the number of a presently unused socket which is then used for the connections required so that the well-advertised socket can be freed for others attempting to connect.
「よく広告を出している」ソケットを通して、ホストはネットワーク共同体の他のメンバーに対するサービスを提供します。 Initial Connectionプロトコル(ICP)[1]は、最初に次に接続するのを試みる他のもののためによく広告を出しているソケットを解放できるくらい必要である接続に使用される現在未使用のソケットの数を交換するためによく広告を出しているソケットに接続するのに使用されます。
When establishing a conversation (with a BEGIN or LISTEN command) the Host indicates in the value of the CONN-TYPE field whether the socket specified is to be employed directly, or to be used as an initial connection socket.
会話(BEGINかLISTENコマンドがある)を確立するとき、Hostは、コン-TYPE分野の値でソケットが指定したかどうかが直接使われることになっているか、または初期の接続ソケットとして使用されることになっているのを示します。
Index/Path Addressing 3e
インデックス/経路アドレシング3e
Indexes are values assigned by the local Host to identify network con- versations. When conversations are established (with the BEGIN or LISTEN commands) the Host must specify an index value. This value will be associated with the resultant conversations for their duration.
インデックスはネットワークまやかしversationsを特定するために地方のHostによって割り当てられた値です。 会話が確立されるとき(BEGINかLISTENコマンドで)、Hostはインデックス値を指定しなければなりません。 この値はそれらの持続時間のための結果の会話に関連するでしょう。
It is often necessary to affiliate conversations [2]. To accommodate this, data paths are defined such that each index has one or more path(s) associated with it (a path can not exist except as a subordinate to an index) and all network communication is transmitted on some path.
会話[2]を合併するのがしばしば必要です。 各インデックスには、これを収容するために、データ経路が定義されるので、それに関連している1つ以上の経路があります、そして、(インデックスへの部下以外に、経路は存在できません)すべてのネットワークコミュニケーションが何らかの経路で伝えられます。
The maximum number of indexes which may be in use at any one time, and the maximum number of paths within one index are installation parameters.
どんな時間の使用、および1つのインデックスの中の経路の最大数ではも、インストールパラメタがあるということであるかもしれないインデックスの最大数。
Index 0 is reserved for controlling other indexes, and logically represent the "pipe" through which all other indexes "flow."
インデックス0は他のインデックスを制御するために予約されます、そして、他のすべてのインデックスが「流れる」「パイプ」を論理的に表してください。
***WORKING DOCUMENT***
***働くドキュメント***
5
5
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Addresses in FEP command strings are conveyed by the pair of fields "INDEX" and "PATH." In commands which cause new indexes to be opened, or new data paths to be added to an existing index (BEGIN or LISTEN), the PATH field indicates the first path to be acted upon by this command. For those commands which do not create new paths or indexes, if PATH is 0, then all paths associated with this INDEX are addressed; if PATH is non-zero, only the specific path within the specified INDEX is addressed.
FEPコマンドストリングのアドレスは分野「インデックス」と「経路」の組によって伝えられます。 新しいインデックスが開かれると追加するか、または既存のインデックス(BEGINかLISTEN)に新しいデータ経路を追加するコマンドで、PATH分野はこのコマンドで作用されるべき最初の経路を示します。 新しい経路かインデックスを作成しないそれらのコマンドにおいて、このINDEXに関連しているすべての経路がPATHが0歳であるなら扱われます。 PATHが非ゼロであるなら、指定されたINDEXの中の特定の経路だけが扱われます。
Path Types 3f
経路は3fをタイプします。
A path can be one of three types:
経路は3つのタイプのひとりであることができます:
a. DUPLEX - both the Host and the FE can issue MESSAGE commands on the path.
a。 DUPLEX--HostとFEの両方が経路でMESSAGEにコマンドを発行できます。
b. SEND - only the Host can issue MESSAGE commands on the path.
b。 SEND--Hostだけが経路でMESSAGEにコマンドを発行できます。
c. RECEIVE - only the FE can issue MESSAGE commands on the path.
c。 RECEIVE--FEだけが経路でMESSAGEにコマンドを発行できます。
The paths within an index may be a mixture of path types but one BEGIN/ LISTEN must be used for each contiguous set of the same type.
インデックスの中の経路は経路タイプの混合物であるかもしれませんが、同じそれぞれの隣接のタイプに1BEGIN/ LISTENを使用しなければなりません。
An FEP path is analogous to a network connection with the following exception. Network connections are always simplex. This is true for paths of type SEND or RECEIVE. However, a DUPLEX path is formed by the FE connecting two local sockets to two foreign sockets. This is a "duplex connection" which is composed of two network (simplex) connections.
FEP経路は以下の例外とのネットワーク接続に類似しています。 いつもネットワーク接続はシンプレクスです。 タイプSENDかRECEIVEの経路に、これは本当です。 しかしながら、DUPLEX経路は、2個の地方のソケットを2個の外国ソケットに接続しながら、FEによって形成されます。 これは2ネットワーク(シンプレクス)接続で構成される「重複の接続」です。
Modes of Establishing a Path 3g
3gの経路を確立するモード
One or more paths are established by the action of a single BEGIN or LISTEN command, with the mode specified in the CONN-TYPE field of the command. Each of the path types is established in one of two modes - directly or via ICP. The gender of the path (its ability to receive or send or both) is not affected by the mode.
1つ以上の経路が独身のBEGINかLISTENコマンドの動作で確立されます、モードがコマンドのコン-TYPE分野で指定されている状態で。 経路タイプ各人は2つのモードの1つ直接かICPを通して確立されます。 経路(受信するか、または発信する性能か両方)の性はモードで影響を受けません。
When any of the path types is specified with the ICP mode, the socket value in the SOCKET field is used as the "well-advertised" socket and an actual working socket will be exchanged according to the Initial Connection Protocol. When the direct mode is indicated, the specified socket is used as the working socket.
経路タイプのどれかがICPモードで指定されるとき、Initial Connectionプロトコルに応じて「よく広告を出している」ソケットと実際の働くソケットを交換するので、SOCKET分野のソケット値は使用されています。 ダイレクトモードが示されるとき、指定されたソケットは働くソケットとして使用されます。
***WORKING DOCUMENT***
***働くドキュメント***
6
6
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
In either mode, when multiple paths are indicated, the next higher socket number values of the appropriate gender are selected for each path. [3]
複数の経路が示されるとき、モードで、適切な性の次の、より高いソケット数の値は各経路に選択されます。 [3]
Translation 3h
翻訳3h
When the Host sets up a path(s) (with a BEGIN or LISTEN command) it identifies what type of translation or data-mapping it requires the FE to perform on all data transmitted on this path(s). This is specified by two values - one giving the format of the data transmitted between the FE and the network, the other giving the format of the data between the Host and the FE. [4]
Hostが経路(BEGINかLISTENコマンドがある)をセットアップするとき、それは、この経路で送られたすべてのデータに実行するのがどんなタイプに関する翻訳かデータマッピングにFEを必要とするかを特定します。 これは2つの値によって指定されます--データの書式を与える1つがFEとネットワークの間を伝わりました、もう片方がHostとFEの間にデータの書式を与えて。 [4]
Flow Control 3i
フロー制御3i
All commands (except REPLYs) must be REPLYED to by the receiver. The sender is blocked from sending more commands on the same path until a REPLY has been received. The REPLY command serves two functions: it indicates the success/failure of the last transmission on the path, and it also indicates a willingness of the receiver to accept more data on that path. Receipt of any valid REPLY on an open path is sufficient to unblock it for END or INTERRUPT commands. Thus a receiver who will not (or can not) accept more data (MESSAGE commands) on a given path need not block the sender from ENDing the path if he desires. An indication of "READY" in the reply serves to unblock the path for MESSAGE commands also.
すべてのコマンド(REPLYsを除いた)は. 受信機による送付者へのREPLYEDがREPLYを受け取るまで、より多くのコマンドを同じ経路に送るのが妨げられるということであるに違いありません。 REPLYコマンドは2つの機能を果たします: それは経路で最後のトランスミッションの成功/失敗を示します、そして、また、受信機がその経路に関する、より多くのデータを受け入れる意欲を示します。 開いている経路のどんな有効なREPLYの領収書も、ENDかINTERRUPTコマンドのためにそれを「非-妨げ」るために十分です。 または、その結果、そうしない受信機、()、経路がENDingから送付者を妨げる必要はないという当然のことに関する、より多くのデータ(MESSAGEコマンド)を受け入れてください、経路、彼は望むことができます。 回答で「準備ができること」のしるしはメッセージコマンドのための経路にも非ブロックに役立ちます。
In the normal case, the REPLY performs both functions concurrently. However, when the receiver is not ready to accept more data, he can REPLY indicating only success/failure of the last command which should be sufficient to allow the sender to free the transmission buffer, requeue the command for retransmission if necessary, etc. and wait for another REPLY command announcing the receiver's ability to accept more data.
正常な場合では、同時にREPLYは両方の機能を実行します。 しかしながら、受信機が、より多くのデータを受け入れる準備ができていないとき、彼は送付者がトランスミッションバッファを解放して、必要なら、「再-トランスミッション」のためにコマンドを「再-列に並ばせ」るのなどて、より多くのデータを受け入れる受信機の性能を示す別のREPLYコマンドを待つのを許容するために十分であるべき持続コマンドの成功/失敗だけを示すREPLYは受け入れることができます。
Exceptional Conditions 3j
例外的な状態3j
When a command is received and can not be executed, the REPLY command is used to notify the sender of the command. To do this, the bits of CODE field of the REPLY are set to show the CATEGORY of the error and its TYPE within that category (see Section 3h).
コマンドを受け取られていて、実行できないとき、REPLYコマンドは、コマンドについて送付者に通知するのに使用されます。 これをするために、REPLYのCODE分野のビットがそのカテゴリの中で誤りのCATEGORYとそのTYPEを見せるように設定されます(セクション3hを見てください)。
***WORKING DOCUMENT***
***働くドキュメント***
7
7
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
COMMANDS 4
コマンド4
Introduction 4a
序論4a
All communications between the Host and the FE is performed by means of commands. The commands are given names for documentation purposes but are distinguished by the binary value of the first field of the command string. Command strings will be padded with zeros up to the next multiple of an installation defined parameter. (This value will be dependent on the capabilities of the hardware interface between the Host and the FE.)
HostとFEとのすべてのコミュニケーションがコマンドによって実行されます。 コマンドは、ドキュメンテーション目的のための名ですが、コマンドストリングの最初の分野の2進の値によって区別されます。 コマンドストリングはインストールの定義されたパラメタの次の倍数までのゼロで水増しされるでしょう。 (この値はHostとFEとのハードウェア・インタフェースの能力に依存するようになるでしょう。)
Field lengths within a command string are specified as some number of bits. These information bits will be right-justified within the least number of bytes needed to hold them. The size of a byte will be an installation parameter which will normally be 8 bits but other values will be accommodated as necessary.
コマンドストリングの中のフィールド長は何らかの数のビットとして指定されます。 これらの情報ビットはそれらを保持するのに必要である最少のバイト数の中でまさしく正当になるでしょう。 1バイトのサイズはインストールパラメタになるでしょうが、通常、8ビットである他の値は必要に応じて設備されるでしょう。
The values and meanings of the CODE field of the REPLY command are given for each command within the following descriptions:
各コマンドのために以下の記述の中でREPLYコマンドのCODE分野の値と意味を与えます:
1: BEGIN 4b
1: 4bを始めてください。
Format
形式
BEGIN INDEX PATH HOST SOCKET TRANS-TYPE CONN-TYPE NPATHS
インデックス経路ホストソケット移-タイプコン-タイプNPATHSを始めてください。
Use
使用
This command is sent only from the Host to the FE. Its function is to direct the FE to establish one or more logical connections (paths) on the specified index between the Host and the FE.
このコマンドをHostだけからFEに送ります。 機能はHostとFEの間の指定されたインデックスにおける1つ以上の論理的な関係(経路)を確立するようFEに指示することです。
Its use has three different modes (depending on the value of the PATH field) :
使用には、3つの異なったモードがあります(PATH分野の値によって):
mode (a) - to set up a new index and to direct the FE to attempt to establish network connections for the one or more paths specified within this index.
モード(a)--新しいインデックスをセットアップして、1つ以上の経路のためのネットワーク接続を確立するのを試みるようFEに指示するのをこのインデックスの中で指定しました。
***WORKING DOCUMENTS***
***働くドキュメント***
8
8
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
mode (b) - to attempt to establish network connections for an existing (but at present closed) path within the already set-up index.
中で既存の、そして、(現在のところ、閉じる)の経路のためのネットワーク接続を確立する試みへのモード(b)、既にインデックスをセットアップしてください。
Mode (c) - to attempt to establish network connections for one or more new paths within the already set-up index.
中で1つ以上の新しい経路のためのネットワーク接続を確立する試みへのモード(c)、既にインデックスをセットアップしてください。
Parameters
パラメタ
a) BEGIN is an 8-bit field with the value 1.
a) BEGINは値1がある8ビットの分野です。
b) INDEX is a 16-bit field, specifying the index. Note that
the value 0 is reserved for special use (see Section 4).
b) インデックスを指定して、INDEXは16ビットの分野です。 値0が特別な使用のために予約されることに注意してください(セクション4を見てください)。
c) PATH is an 8-bit field, specifying the path(s) which are to be established. Its value identifies the mode of the BEGIN (see above) :
c) 設立されることである経路を指定して、PATHは8ビットの分野です。 値はBEGINのモードを特定します(上を見てください)。 :
mode (a) - its value must be 1.
モード(a)--値は1でなければなりません。
mode (b) - its value must be that of the path to be "re-opened."
モード(b)--値は、「再開する」ためには経路のものでなければなりません。
mode (c) - its value must be exactly one greater than the current number of paths defined within this index.
モード(c)--値はまさにこのインデックスの中で定義された経路の最新号よりすばらしい1つでなければなりません。
d) HOST is a 32-bit field specifying the foreign host with which connections are to be established.
d) HOSTは接続が確立されることになっている異種宿主を指定する32ビットの分野です。
e) SOCKET is a 32-bit field, specifying the first or only socket at the foreign host to which connections are to be made.
e) SOCKETは32ビットの分野です、異種宿主の接続が作られていることになっている1番目か唯一のソケットを指定して。
f) TRANS-TYPE is a 16-bit field which directs the FE to
perform this type of translation on all data (i.e. TEXT
in the MESSAGE command string) sent on every path being
established by this command. The first 8 bits specify
the format of the data on the network side; the second
8 bits specify the format of the data on the Host side.
The values assigned to the particular formats (eq. ASCII,
EBCDIC etc.) are installation parameters; however, the
f) TRANS-TYPEはこのコマンドで確立されるあらゆる経路で送られたすべてのデータ(すなわち、MESSAGEコマンドストリングのTEXT)にこのタイプに関する翻訳を実行するようFEに指示する16ビットの分野です。 最初の8ビットはネットワーク側でデータの形式を指定します。 2番目の8ビットはHost側でデータの形式を指定します。 特定の形式に割り当てられた値(eq。 EBCDIC ASCIIなど) インストールパラメタです。 しかしながら
***WORKING DOCUMENT***
***働くドキュメント***
9
9
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
value 0 will always mean "bit string" and thus if either of the 8-bit sub-fields contains 0, then no mapping will be performed.
値0はいつも「ビット列」を意味するでしょう、そして、その結果、8ビットのサブ分野のどちらかが0を含んでいると、写像は実行されないでしょう。
g) CONN-TYPE is an 16-bit field, specifying the type and mode
of connection(s) to be established for the specified path(s).
Its value informs the FE how to associate sockets with
indexes/paths (see Sections 2f and 2g).
g) 指定された経路に証明されるために接続のタイプと方法を指定して、コン-TYPEは16ビットの分野です。 値はインデックス/経路にソケットを関連づける方法をFEに知らせます(セクション2fと2gを見てください)。
Value Type Mode
値のタイプモード
7 Duplex via ICP 6 Duplex direct 5 Receive via ICP 4 Receive direct 3 Send via ICP 2 Send direct
7 ICP2Sendを通したSendが指示するICP4のReceiveのダイレクト3を通したICP6のDuplexのダイレクト5Receiveを通したデュプレックス
h) NPATHS is an 8-bit field, specifying the number of paths which
this command directs the FE to attempt to establish connections
for. If the BEGIN is of mode (b) then its value must be 1.
Otherwise the sum of its value and the value of the PATH field
is the new current number of paths plus one.
h) NPATHSは関係を樹立するこのコマンドが、FEが試みるよう指示するパスの数を指定する8ビットの分野です。 BEGINがモード(b)のものであるなら、値は1でなければなりません。 さもなければ、価値の合計とPATH分野の値は、新しい最新号の経路と1つです。
Error CODES in REPLY
回答におけるエラーコード
Category Type Meaning
カテゴリタイプ意味
3 1 PATH invalid for new index 3 2 PATH invalid for old index 3 3 PATH already open 3 4 HOST unknown 3 5 TRANSLATION-TYPE invalid 3 6 CONNECTION-TYPE invalid 3 7 NPATHS invalid for old path on old index 3 8 Specified socket inconsistent with CONN-TYPE 3 9 INDEX invalid, not ready for business 4 1 No new connections - FE full 4 2 No new connections - closing down soon
3 3PATHがすぐ既にビジネス4 1いいえの新しい接続(FE完全な4 2のいいえの新しい接続)閉鎖の準備ができるのではなく、コン-TYPE3 9INDEX病人に矛盾した旧指数3 8Specifiedソケットの上の古い経路に、無効の未知の3 4の3 5TRANSLATION-TYPE無効の3 6HOST CONNECTION-TYPE無効の3 7NPATHSを開く旧指数に、無効の新しいインデックス3 2PATHに、無効の3 1PATH
***WORKING DOCUMENT***
***働くドキュメント***
10
10
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
2: LISTEN 4c
2: 4cを聴いてください。
Format
形式
LISTEN INDEX PATH HOST SOCKET TRANS-TYPE CONN-TYPE NPATHS
インデックス経路ホストソケット移-タイプコン-タイプNPATHSを聴いてください。
Use
使用
This command is sent only from the Host to the FE.
このコマンドをHostだけからFEに送ります。
Its function is to direct the FE to "listen," i.e., to hold the specified paths pending until such time as a request for connection (RFC) is received from the network to the specified local socket. then to set up connections and to respond with a RESPONSE command for each path.
機能はすなわち、そのような時間まで未定の指定された経路を保持するためにネットワークから指定された地方の接続をセットアップして、各経路のためのRESPONSEコマンドで応じるためには当時のソケットまで接続(RFC)を求める要求を受け取るように「聴く」ようFEに指示することです。
Its use has three different modes (depending on the value of the PATH field) :
使用には、3つの異なったモードがあります(PATH分野の値によって):
mode (a) - to set up a new index and to listen on the specified local socket in order to establish connections for the specified paths.
モード(a)--新しいインデックスをセットアップして、指定された経路に関係を樹立するために指定された地方のソケットの上に聴くために。
mode (b) - to listen on the specified socket in order to establish connections for the specified, existing (but at present closed) path within the already set-up index.
モード(b)--、指定されましたが、既存の、そして、(現在のところ、閉じられます)の経路に関係を樹立するために中で指定されたソケットの上に聴く、既にインデックスをセットアップしてください。
mode (c) - to listen on the specified socket in order to establish connections for the specified new path(s) within the already set-up index.
モード(c)--、指定された新しい経路に関係を樹立するために中で指定されたソケットの上に聴く、既にインデックスをセットアップしてください。
By use of the HOST parameter, the FE can be directed to accept RFCs from any host or only from the specified host.
HOSTパラメタの使用で、FEがどんなホスト、または、指定されたホストだけからRFCsを受け入れるよう指示できます。
Parameters
パラメタ
a) LISTEN is an 8-bit field with value 2.
a) LISTENは値2がある8ビットの分野です。
b) INDEX is a 16-bit field specifying the index.
b) INDEXはインデックスを指定する16ビットの分野です。
c) PATH is an 8-bit field specifying the first of the one or more paths which are to be held pending receipt of a RFC. Its value identifies the mode of the LISTEN (see above) :
c) PATHはRFCの領収書まで保持されることである1つ以上の経路の1番目を指定する8ビットの分野です。 値はLISTENのモードを特定します(上を見てください)。 :
***WORKING DOCUMENT***
***働くドキュメント***
11
11
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
mode (a) - its value must be 1.
モード(a)--値は1でなければなりません。
mode (b) - its value must be that of the existing path.
モード(b)--値は既存の経路のものでなければなりません。
mode (c) - its value must be exactly one greater than the current number of paths within this index.
モード(c)--値はまさにこのインデックスの中では、現在のパスの数よりすばらしい1つでなければなりません。
d) HOST is a 32-bit field specifying the host from which RFCs are to be accepted; a value of 0 implies from any host.
d) HOSTはRFCsが受け入れられることになっているホストを指定する32ビットの分野です。 0の値はいずれからもホストを含意します。
e) SOCKET is a 32-bit field specifying the local socket on which the FE is to listen for RFCs.
e) SOCKETはFEがRFCsの聞こうとすることになっている地方のソケットを指定する32ビットの分野です。
f) TRANS-TYPE is a 16-bit field specifying the type of translation the FE is to perform on all data sent on every path established as a result of this command. Its values are the same as in the BEGIN command.
f) TRANS-TYPEはFEがこのコマンドの結果、確立されたあらゆる経路で送られたすべてのデータに実行することになっている翻訳のタイプを指定する16ビットの分野です。 値はBEGINコマンドと同じです。
g) CONN-TYPE is an 16-bit field specifying the type and mode of the connection(s) to be established for the specified path(s) when an RFC is received. Its values are the same as in the BEGIN command.
g) コン-TYPEはRFCが受け取られているとき、指定された経路に証明されるために接続のタイプと方法を指定する16ビットの分野です。 値はBEGINコマンドと同じです。
h) NPATHS is an 8-bit field specifying the number of paths which this command associates with the specified index and which are to be established. If the LISTEN is of mode (b) then its value must be 1. Otherwise the sum of its value and the value of the PATH field is the new current number of paths plus one, within this index. Thus its value is the number of extra RFCs for which the FE is listening on this socket.
h) NPATHSはこのコマンドが指定されたインデックスに関連づけて、設立されることであるパスの数を指定する8ビットの分野です。 LISTENがモード(b)のものであるなら、値は1でなければなりません。 さもなければ、価値の合計とPATH分野の値は、新しい最新号の経路と1つです、このインデックスの中で。 したがって、値はFEがこのソケットの上に聴いている付加的なRFCsの数です。
Error CODEs in REPLY
回答におけるエラーコード
Category Type Meaning
カテゴリタイプ意味
3 1 PATH invalid for new index 3 2 PATH invalid for old index 3 3 PATH already open 3 4 HOST unknown 3 5 TRANSLATION-TYPE invalid
老人にとって、無効の新しいインデックス3 2PATHに、無効の3 1PATHは3 3PATHに既に開いている3 4HOST未知の3 5TRANSLATION-TYPE無効の状態で索引をつけます。
***WORKING DOCUMENT***
***働くドキュメント***
12
12
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
3 6 CONNECTION-TYPE INVALID 3 7 NPATHS invalid for old path on old index 3 8 Specified socket inconsistent with CONN-TYPE 3 9 INDEX invalid, not ready for business 3 10 Socket already in use. 4 1 No new listens - FE full 4 2 No new listens - closing down soon
ビジネスの準備ができるのではなく、コン-TYPE3 9INDEX病人に矛盾した旧指数3 8Specifiedソケットの上の古い経路に、無効の3 6CONNECTION-TYPE INVALID3 7NPATHS、3、10Socket、既に使用中に。 4 1ノー新しい、聴取、--、FEが新しくない4 2を洗い張りするすぐ休業して、聴きます。
3: RESPONSE 4d
3: 応答4d
Format
形式
RESPONSE INDEX PATH CODE HOST SOCKET
応答インデックス経路コードホストソケット
Use
使用
This command is sent only from the FE to the Host - once per path specified in a BEGIN or a LISTEN command.
1BEGINかLISTENコマンドで指定された経路に一度このコマンドをFEだけからHostに送ります。
For paths specified in a BEGIN, it is sent to indicate the success or failure of the connection attempt. For paths specified in a LISTEN, it is sent at the time when the FE has received a matching RFC and has established the connection.
BEGINで指定された経路において、接続試みの成否を示すためにそれを送ります。 FEが合っているRFCを受けて、接続を確立したとき、LISTENで指定された経路において、それを送ります。
The HOST and SOCKET parameters are purely informational which the Host can ignore if it so desires. Their contents are only guaranteed if the connection attempt succeeded.
HOSTとSOCKETパラメタは純粋に情報です。Hostがそれであるなら無視できるものはそう望んでいます。 接続試みが成功した場合にだけ、それらの内容は保証されます。
Parameters
パラメタ
a) RESPONSE is an 8-bit field with value 3.
a) RESPONSEは値3がある8ビットの分野です。
b) INDEX is a 16-bit field specifying the index.
b) INDEXはインデックスを指定する16ビットの分野です。
c) PATH is an 8-bit field specifying the particular path.
c) PATHは特定の経路を指定する8ビットの分野です。
d) CODE is a 16-bit field indicating the outcome of the connection attempt:
d) CODEは接続試みの結果を示す16ビットの分野です:
***WORKING DOCUMENT***
***働くドキュメント***
13
13
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Value Meaning
値の意味
0 Path successfully established. 1 Local IMP dead. 2 Foreign IMP inaccessible. 3 Foreign Host dead. 4 Foreign Host not responding. 5 Connection refused.
首尾よく確立された0経路。 1 地方のIMPは死にました。 2 近づきがたい外国IMP。 3 外国Hostは死にました。 4 応じるのではなく、外国Host。 5 接続は拒否しました。
e) HOST is a 32-bit field specifying the foreign host to which the connection has been made.
e) HOSTは接続がされた異種宿主を指定する32ビットの分野です。
f) SOCKET is a 32-bit field specifying the socket at the foreign host. If the connection type is simplex, then it is the only foreign socket for this path; if duplex, then it is the lower of the two foreign sockets.
f) SOCKETは異種宿主でソケットを指定する32ビットの分野です。 結合方式がシンプレクスであるなら、それはこの経路への唯一の外国ソケットです。 デュプレックスであるなら、2個の外国ソケットではより低いです。
Error CODES in REPLY
回答におけるエラーコード
Category Type Meaning
カテゴリタイプ意味
3 11 INDEX unknown 3 12 PATH unknown 3 13 CODE invalid
3 11のINDEXの未知の3 12PATH未知の3 13CODE病人
4: MESSAGE 4e
4: メッセージ4e
Format
形式
MESSAGE INDEX PATH COUNT PAD TEXT
メッセージインデックス経路カウントパッドテキスト
Use
使用
This command is sent by either the Host or the FE to transmit data on the specified path and index.
このコマンドは、指定された経路とインデックスに関するデータを送るためにHostかFEのどちらかによって送られます。
Parameters
パラメタ
a) MESSAGE is an 8-bit field with value 4.
a) MESSAGEは値4がある8ビットの分野です。
b) INDEX is a 16-bit field specifying the index.
b) INDEXはインデックスを指定する16ビットの分野です。
***WORKING DOCUMENT***
***働くドキュメント***
14
14
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
c) PATH is an 8-bit field specifying the path. Note that the value 0 is used in the broadcast option (see Section 3j).
c) PATHは経路を指定する8ビットの分野です。 値0が放送オプションに使用されることに注意してください(セクション3jを見てください)。
d) COUNT is a 16-bit field specifying the number of bits of data in the TEXT field.
d) COUNTはTEXT分野のビットのデータの数を指定する16ビットの分野です。
e) PAD is an n-bit field, where n is an installation parameter. It contains only padding (in the present protocol specification) and can be used to enable the host to have the TEXT field start on a convenient boundary.
e) PADはn-ビット分野です。(そこでは、nがインストールパラメタです)。 それは、詰め物(現在のプロトコル仕様による)だけを含んでいて、ホストがTEXT分野に便利な境界を始めさせるのを可能にするのに使用できます。
f) TEXT is a field containing COUNT bits of data being transmitted on this path.
f) TEXTはこの経路で送られるCOUNTビットのデータを含む分野です。
Error CODES in REPLY
回答におけるエラーコード
Category Type Meaning
カテゴリタイプ意味
2 1 This option not implemented
3 12 PATH unknown
3 14 No connection opened in this direction
3 15 PATH blocked at this time, resent later
3 16 PATH suspended at this time, resent later
3 17 PATH closed
3 17 COUNT too large
4 3 Error in transmitting data, resend command
4 4 Data lost, resent command.
16PATHがこのとき中断させた後の3は、このオプションがこのとき妨げられているこの方向3 15PATHで開かれた3 12PATH未知の3 14いいえ接続を実装しなかった2 1がデータを送ることにおける大き過ぎる4 3Error、4 4Dataが失った再送コマンドを後の3 17PATH閉じた3 17COUNTに再送したのに憤慨します、憤慨コマンド。
5: INTERRUPT 4f Format
5: 中断4f Format
INTERRUPT INDEX PATH CODE Use
中断インデックス経路コード使用
This command is sent by either the Host or the FE.
このコマンドはHostかFEのどちらかによって送られます。
Its most common use is to pass the information that a terminal user has pressed his INT (or ATTN or Control-C) key, thereby requesting his applications program to quit what it is doing for him.[5]
最も一般的な使い方は端末ユーザが彼のINT(または、ATTNかControl-C)キーを押したという情報を通過することです、その結果、それが彼のためにしていることをやめるよう彼のアプリケーションプログラムに要求します。[5]
***WORKING DOCUMENT***
***働くドキュメント***
15
15
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Parameters
パラメタ
a) INTERRUPT is a 8-bit field with value 5.
a) INTERRUPTは値5がある8ビットの分野です。
b) INDEX is a 16-bit field specifying the index.
b) INDEXはインデックスを指定する16ビットの分野です。
c) PATH is an 8-bit field specifying the path on which the INTERRUPT is transmitted. Note that the value 0 is used in the broadcast option (see Section 3j).
c) PATHはINTERRUPTが伝えられる経路を指定する8ビットの分野です。 値0が放送オプションに使用されることに注意してください(セクション3jを見てください)。
d) CODE is a 16-bit field. It has no defined meanings as yet and should contain 0.
d) CODEは16ビットの分野です。 それは、まだ定義された意味を全く持っていなくて、0を含むべきです。
Error CODES in REPLY
回答におけるエラーコード
Category Type Meaning
カテゴリタイプ意味
2 1 This option not implemented 3 11 INDEX unknown 3 12 PATH unknown 3 14 No connection opened in this direction 3 15 PATH blocked at this time, resend later 3 17 PATH closed.
このオプションが3のINDEXの未知の3 12 11PATH未知の3 14いいえ接続を実装しなかった2 1がこのとき妨げられているこの方向3 15PATHで開かれて、17PATHが閉じた後の3を再送してください。
6: END 4g
6: 4g終わってください。
Format
形式
END INDEX PATH CODE
終わりのインデックス経路コード
Use
使用
This command is sent by either the Host or the FE, to terminate a connection. If PATH is 0, then the index and all its paths are terminated, otherwise just the specified path of the index is terminated.
このコマンドは、接続を終えるためにHostかFEのどちらかによって送られます。 インデックスとそのすべての経路がPATHが0歳であるなら終えられる、さもなければ、まさしくインデックスの指定された経路は終えられます。
Parameters
パラメタ
a) END is an 8-bit field with value 6.
a) ENDは値6がある8ビットの分野です。
b) INDEX is a 16-bit field specifying the index.
b) INDEXはインデックスを指定する16ビットの分野です。
***WORKING PARAMETER***
***加工パラメータ***
16
16
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
c) PATH is an 8-bit field containing the path to be closed, or 0 if the whole index is to be closed.
c) PATHは全体のインデックスが閉じられることであるなら閉じるべき経路、または0を含む8ビットの分野です。
d) CODE is a 16-bit field indicating the reason for the closure:
d) CODEは閉鎖の理由を示す16ビットの分野です:
Value Meaning
値の意味
0 Normal close 1 Retries exhausted 2 Foreign Host failure 3 Foreign IMP failure 4 Network failure 5 Local IMP failure.
0正常な近い1Retriesで、2Foreign Host失敗3Foreign IMP失敗4Network故障5Local IMPの故障はくたくたになりました。
The "Retries exhausted" code indicates that the FE has been retrying a transmission to the foreign host without success.
「消耗する再試行」コードは、FEが成功なしで異種宿主にトランスミッションを再試行しているのを示します。
Error CODES in REPLY
回答におけるエラーコード
Category Type Meaning
カテゴリタイプ意味
3 11 INDEX unknown 3 12 PATH unknown 3 13 CODE unknown 3 15 PATH blocked at this time, resend later 3 17 PATH closed.
このとき妨げられている未知の3のPATH未知の3 13 11INDEX3 12CODE未知の3 15PATH、17PATHが閉じた後の3を再送してください。
7: REPLY 4h
7: 回答4h
Format
形式
REPLY INDEX PATH CODE
回答インデックス経路コード
Use
使用
This command is sent by both the Host and the FE to acknowledge receipt of every other type of command (including those on index 0, see Section 4) and/or to unblock that particular direction of an opened path for the transmission of another command.
HostとFEの両方でこのコマンドを送って、別のコマンドの送信のために他のすべてのタイプのコマンド(それらを含んでいて、0は索引をつけます、とセクション4は見る)の領収書、そして/または、開かれた経路の非ブロックへのその特定の方向を承認します。
Note that the INDEX and PATH fields contain exactly the same as those of the command being replied to.
INDEXとPATH分野がちょうど答えられるコマンドのものと同じくらい含むことに注意してください。
***WORKING DOCUMENT***
***働くドキュメント***
17
17
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Parameters
パラメタ
a) REPLY is an 8-bit field with value 7.
a) REPLYは値7がある8ビットの分野です。
b) INDEX is a 16-bit field specifying the index.
b) INDEXはインデックスを指定する16ビットの分野です。
c) PATH is a 8-bit field specifying the path.
c) PATHは経路を指定する8ビットの分野です。
d) CODE is a 16-bit field indicating the success/failure of the command being REPLYed to, and the sender's readiness for more commands on the same path. It is divided into four subfields - STATUS, COMMAND, CATEGORY, and TYPE.
d) CODE、16ビットの分野がREPLYedであるコマンドの成功/失敗を示している、そして、同じ経路におけるより多くのコマンドのための送付者の準備。 それは4つの部分体に分割されます--STATUS、COMMAND、CATEGORY、およびTYPE。
1) STATUS is 4 bits wide
1) STATUSは幅4ビットです。
bit 0 (right-most) - READY bit 1 - NOT-READY bit 2 - ACK bit 3 - NAK
ビット0最も)--READYビット1--READYでないビット2--ACKビット3--NAK
ACK=1 indicates that the sender (of the REPLY) has accepted the command (being REPLYed to). NAK=1 indicates that the sender has discarded the command (with the reason given by the settings of the other bits of the CODE field).
ACK=1が、送付者(REPLYの)がコマンドを受け入れたのを示す、(REPLYedである、) NAK=1は、送付者がコマンド(理由がCODE分野の他のビットの設定によってあげられている)を捨てたのを示します。
NOT-READY=1 indicates that the sender (of the REPLY) is willing to receive an END or INTERRUPT on this path. READY=1 indicates that MESSAGE commands will also be received.
どんなREADY=1も、送付者(REPLYの)が、この経路にENDかINTERRUPTを受け取っても構わないと思っているのを示しません。 READY=1は、また、MESSAGEコマンドが受け取られるのを示します。
Normally only one REPLY command will be sent for each other command. However MESSAGE, INTERRUPT, RESPONSE and invalid END commands can be replied to by a REPLY with ACK (or NAK)=1 and NOT-READY=1 and another REPLY, some time later, with READY=1. [6]
通常、1つのREPLYコマンドだけに互いのためのコマンドを送るでしょう。 しかしながら、REPLYはACK(または、NAK)=1、READY=1でなく、および別のREPLYと共にMESSAGE、INTERRUPT、RESPONSE、および無効のENDコマンドについて答えることができます、その後、READY=1と共に。 [6]
The ACK and NAK bits are mutually exclusive and should never both be on simultaneously, and similarly the READY and NOT-READY bits.
ACKとNAKビットは、互いに排他的であり、同時で、決してともに同様に排他的であるべきではありません。READYとREADYでないビット。
Note that the READY/NOT-READY bit settings are only relevant when a path is open.
経路が開いているときだけ、READY/READYでないことの噛み付いている設定が関連していることに注意してください。
***WORKING DOCUMENT***
***働くドキュメント***
18
18
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
2) COMMAND is 4 bits wide. It indicates the command for
which this is a REPLY :
2) COMMANDは幅4ビットです。 それはこれがREPLYであるコマンドを示します:
Value Meaning
値の意味
0 any of the following 1 BEGIN 2 LISTEN 3 RESPONSE 4 MESSAGE 5 INTERRUPT 6 END
0 以下の1BEGIN2のLISTEN3RESPONSE4MESSAGE5INTERRUPT6ENDのいずれも
The value 0 is defined for cases where a Host does not wish to incur any overhead required to fill in the non-zero value.
値0はHostが非ゼロ値に記入するのに必要であるオーバーヘッドを被りたがっていないケースのために定義されます。
3) CATEGORY is 3 bits wide. It specifies the category of
the error indicated by the ACK bit being off :
3) CATEGORYは幅3ビットです。 それは以下にあるACKビットによって示された誤りのカテゴリを指定します。
Value Meaning
値の意味
1 Command not recognized 2 Option not implemented 3 Invalid 4 Action failed.
1 3Invalid4Actionであることは実装されなかったコマンドの認識されなかった2Optionが失敗しました。
Its value is relevant only when NAK=1.
NAK=1であるときにだけ、値は関連しています。
4) TYPE is 5 bits wide. It specifies which error occurred. Its value is relevant only when NAK=1. The possible values and meanings for the various errors and their corresponding CATEGORY subfield values are given under the description of each command.
4) TYPEは幅5ビットです。 それは、どの誤りが発生したかを指定します。 NAK=1であるときにだけ、値は関連しています。 それぞれのコマンドの記述で様々な誤りとそれらの対応するCATEGORY部分体値のための可能な値と意味を与えます。
Sequencing 4i
配列4i
Once communication between the Host and the FE has been established and each side is "Ready for Business" (see Section 4b) the Host may at any time send BEGIN or LISTEN commands for new indexes. The FE will acknowledge a BEGIN or
それぞれの側がいったんHostとFEとのコミュニケーションが確立されて、「ビジネスの、準備ができる」ように(セクション4bを見てください)なると、Hostはいつでも新しいインデックスのためのコマンドをBEGINかLISTENに送るかもしれません。 またはFEがBEGINを承認する。
***WORKING DOCUMENT***
***働くドキュメント***
19
19
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
LISTEN with a REPLY and the index is then set-up providing that the REPLY indicates no errors. Other BEGIN or LISTEN commands for the new paths on the same index may be sent at any time after the index is set-up.
そして、REPLYが誤りを全く示さないなら、REPLYとインデックスがあるLISTENはセットアップです。 いつでも、インデックスがセットアップであったのの後で同じインデックスの新しい経路のための他のBEGINかLISTENコマンドを送るかもしれません。
The FE will send a RESPONSE command for each path on completion of its attempts to fulfill the Host's instructions. If an attempt failed (indicated by the CODE field) then the path remains closed and another BEGIN or LISTEN for that path can be sent. If the attempt was successful, then MESSAGE or INTERRUPT commands can be sent after the Host has REPLYED to the RESPONSE.
FEは試みの完成での各経路がHostの指示を実現させるRESPONSEコマンドを送るでしょう。 試みが失敗したなら(CODE分野で、示されます)、経路は閉じられたままで残っています、そして、その経路への別のBEGINかLISTENを送ることができます。 試みがうまくいったなら、HostがRESPONSEにREPLYEDを持った後にMESSAGEかINTERRUPTコマンドを送ることができます。
An INTERRUPT or END command may be sent on any opened path after receiving a REPLY for the previous command on the same path in the same direction. A MESSAGE command may be sent if in addition the READY bit was on in the last REPLY command.
同じ経路における前のコマンドのために同じ方向にREPLYを受けた後に、どんな開かれた経路でもINTERRUPTかENDコマンドを送るかもしれません。 READYビットが最後のREPLYコマンドでさらに、オンであったなら、MESSAGEコマンドを送るかもしれません。
New paths on the same index may be opened at any time after the index has been set-up, or particular paths may be ENDed and then have new BEGINs or LISTENs for them issued. An index remains set-up, even if all its paths are closed, until an END command with PATH=0 is issued for the index.
同じインデックスの新しい経路がいつでも、インデックスがセットアップであることの後で開かれるかもしれないか、特定の経路で、ENDedであり、次に、彼らのための新しいBEGINsかLISTENsを発行するかもしれません。 インデックスはセットアップのままで残っています、すべての経路が閉じられても、インデックスのためにPATH=0とのENDコマンドを発行するまで。
Communication between the Host and the FE is terminated by an END with INDEX=0 and this will abort any remaining open paths and indexes.
HostとFEとのコミュニケーションはINDEX=0と共にENDによって終えられます、そして、これはどんな残っている開いている経路とインデックスも中止するでしょう。
Broadcasting 4j
4jを放送します。
Broadcasting is an optional feature of the protocol. If it has been enabled by the installation parameter, then the Host may send a MESSAGE or INTERRUPT command on a particular index with PATH=0. This instructs the FE to send the data contained in the TEXT field of the MESSAGE command (or an interrupt) on every network connection corresponding to an open path of the specified index.
放送はプロトコルに関するオプション機能です。 それがインストールパラメタによって可能にされたなら、HostはPATH=0がある特定のインデックスでMESSAGEかINTERRUPTにコマンドを送るかもしれません。 これは、MESSAGEコマンド(または、中断)のTEXT分野に指定されたインデックスの開いている経路に対応するすべてのネットワーク接続で保管されていたデータを送るようFEに命令します。
This feature will only occur on MESSAGEs from the Host to the FE (since no utilization of it in the other direction is envisaged).
この特徴はMESSAGEsにHostからFEまで現れるだけでしょう(もう片方の方向へのそれの利用が全く考えられないので)。
A broadcast MESSAGE is replied to with one or two REPLYs in the same way as any other MESSAGE command. Flow control within the index is maintained as if broadcast MESSAGEs were sent on a separate path, i.e., flow control on other paths is not directly affected.
同様に、いかなる他のMESSAGEも命令するように放送MESSAGEは1か2REPLYsと共に答えられます。 インデックスの中のフロー制御はまるで別々の経路で放送MESSAGEsを送るかのように維持されます、すなわち、他の経路のフロー制御が直接影響を受けません。
***WORKING DOCUMENT***
***働くドキュメント***
20
20
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Note that for a broadcast MESSAGE command the FE will perform translation on the data for each path in accordance with the BEGIN or LISTEN which initiated that path. Thus, care must be taken when all paths of the particular index do not have the same format on the Host side specified in their TRANS-TYPE (see Section 6b).
放送MESSAGE命令のために、その経路を開始したBEGINかLISTENによると、FEが各経路のためのデータに翻訳を実行することに注意してください。 したがって、特定のインデックスのすべての経路がそれらのTRANS-TYPEで指定されたHost側に同じ形式を持っていないと(セクション6bを見てください)、注意しなければなりません。
Index 0 5
インデックス0 5
Introduction 5a
序論5a
Index 0 provides a control link between the Host and the FE, and thus has no network connections directly associated with it. The commands on this index are used to establish and terminate the connection between Host and FE and to control other indexes.
インデックス0には、HostとFEとのコントロールリンクを提供して、その結果、直接それに関連しているどんなネットワーク接続もいません。 このインデックスにおけるコマンドは、HostとFEとの接続を確立して、終えて、他のインデックスを制御するのに使用されます。
Path 0 5b
経路0 5b
Path 0 of Index 0 is used to pass global commands - i.e., those which do not refer to any particular index or path. The currently defined commands are :
Index0の経路0はグローバルなコマンドに合格するのに使用されます--すなわち、どんな特定のインデックスや経路も参照しないもの。 現在定義されたコマンドは以下の通りです。
MESSAGE INDEX=0 COUNT PAD TEXT
メッセージインデックス=0はパッドテキストを数えます。
where TEXT = COMMAND [PARM1] [PARM2] COMMAND is 8 bits long PARM1 and PARM2 are 16 bits long
TEXTがどこでCOMMAND[PARM1][PARM2]COMMANDと等しいかは、長さ8ビットのPARM1です、そして、PARM2は長さ16ビットです。
a) COMMAND=1 , PARM1=Hostid
a) コマンドは1、PARM1=Hostidと等しいです。
This is the "Ready for Business" command which must be sent by both Host and FE to establish communication between them. Count gives the length of the TEXT field as usual. If COUNT=8, then just the COMMAND field is present. If COUNT=24, then both the COMMAND and Hostid are present.
これはHostとFEの両方で送る、それらのコミュニケーションを確立しなければならない「ビジネスの準備ができる」コマンドです。 カウントはTEXT分野の長さを通常通りであるのに与えます。 COUNT=8であるなら、まさしくCOMMAND分野は存在しています。 COUNT=24であるなら、COMMANDとHostidの両方が存在しています。
The FE will never send a Hostid. The Host may send its Hostid in the event that the FE is connected to more than one IMP or if alternate routes to the network exist (e.g., via patch panels).
FEはHostidを決して送らないでしょう。 FEが1IMPに接続されるか、またはネットワークへの代替経路が存在しているなら(例えば、パッチ盤を通して)、HostはHostidを送るかもしれません。
Until both sides have sent this command no other command is valid.
両側がこのコマンドを送るまで、他のどんなコマンドも有効ではありません。
b) COMMAND=2 , PARM1=M , PARM2=N
b) PARM2=N、コマンドは2、PARM1=Mと等しいです。
***WORKING DOCUMENT***
***働くドキュメント***
21
21
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
This is the "CLOSING" command which is a purely information indication that the sender's FEP module has been told that communication will be terminated in M minutes for a period of N minutes (N=0 implies unknown).
これはMがしばらくNを書き留める終えられたコネが数分であるつもりであったなら送付者のFEPモジュールが情報指示ですが、純粋にaであるコマンドがそのコミュニケーションが言われた「閉鎖」です(N=0は未知を含意します)。
No action is required of the receiver, however he may be able to distribute the information to his users.
受信機はどんな動作にも要求されないで、しかしながら、彼はユーザに情報を分配できるかもしれません。
c) COMMAND=3
c) コマンド=3
This is the "CONTINUE" command which indicates that any previous CLOSING command is now no longer true.
これは前のどんな終わりのコマンドも現在もう正しくないのを示す「続行」コマンドです。
END INDEX=0 PATH+0 CODE
端インデックス=0経路+0コード
This command terminates the connection between the HOST and FE. All other paths/indexes are automatically aborted and the FE will close all network connections. The values of the CODE field are the same as in the general END command.
このコマンドはHOSTとFEとの接続を終えます。 他のすべての経路/インデックスが自動的に中止されます、そして、FEはすべてのネットワーク接続を終えるでしょう。 CODE分野の値は一般的なENDコマンドと同じです。
Path 1 5c
経路1 5c
Path 1 is reserved for commands specific to a particular path or index. No commands are presently defined; they will be at a later date when more experience has been gained on the need for them.
経路1は特定の経路かインデックスに特定のコマンドのために予約されます。 コマンドは全く現在、定義されません。 それらはその後により多くの経験がそれらの必要性で行われた時になるでしょう。
Path 2 5d
経路2 5d
Path 2 of Index 0 is used for Operator-to-Operator communication between the Host and the FE. It is an optional feature which is enabled by an installation parameter.
Index0の経路2はHostとFEとのOperatorからオペレータへのコミュニケーションに使用されます。 それはインストールパラメタによって可能にされるオプション機能です。
MESSAGE commands are formatted in the normal manner with the sender requesting that the TEXT field be displayed to the receiver's system operator.
送付者が、TEXT野原が受信機のシステムオペレーターに表示されるよう要求している状態で、MESSAGEコマンドは正常な方法でフォーマットされます。
Scenarios 6
シナリオ6
The following scenarios are included to provide the reader with a "feeling" for FEP in a varied set of applications. The examples selected relate to existing ARPANET protocols or other networking applications, and do not represent an exhaustive list of capabilities. 6a
以下のシナリオは、様々なアプリケーションでFEPに関する「感じ」を読者に提供するために含まれています。 選択された例は、既存のアルパネットプロトコルか他のネットワークアプリケーションに関連して、能力に関する完全なりストを表しません。 6a
***WORKING DOCUMENT***
***働くドキュメント***
22
22
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Fields which are variable or not relevant are not shown (for purposes of clarity) in the command strings in the following examples. 6b
可変であるか、または関連していない分野は以下の例のコマンドストリングに示されません(明快の目的のために)。 6b
Host Implementation of User TELNET 6c
ユーザtelnet6cのホスト導入
BEGIN ndxa,PATH=1,host,SKT=1,,CONN-TYPE=duplex+ICP,NPATHS=1
ndxaを始めてください、そして、経路は1、ホスト、SKT=1と等しく、コン-タイプはデュプレックス+ICP、NPATHS=1と等しいです。
The User TELNET process in the Host causes the BEGIN command to be issued. When a successful RESPONSE has been returned by the FE, a typical duplex TELNET connection will have been made to the Host specified in the BEGIN.
HostのUser TELNETプロセスは発行されるべきBEGINコマンドを引き起こします。 うまくいっているRESPONSEがFEによって返されたとき、典型的な重複のTELNET接続はBEGINで指定されたHostに作られてしまうでしょう。
Host is Providing Server TELNET 6d
ホストはProviding Server TELNET 6dです。
LISTEN ndxa,PATH-1,HOST=0,SKT=1,,CONN-TYPE=duplex+ICP,NPATHS=32
ndxa、経路-1、ホスト=0、SKT=1を聴いてください、そして、コン-タイプはデュプレックス+ICP、NPATHS=32と等しいです。
With this one command the Server TELNET process in the Host has conditioned the FE to LISTEN on Socket 1 (the well-advertised TELNET socket) and to establish as many as 32 duplex data paths. The FE, through the RESPONSE command, will report each connection as it occurs. Path 1 will represent the first such duplex connection, etc. The Host may then manage the data paths individually. Individual paths may be ended and placed back into a LISTENing state by the Host. If at any time an END command specifying this INDEX with a PATH of 0 were to be sent by the Host, all connections would be dissolved, and for all practical purposes, the Host is no longer willing to provide Server TELNET services.
そして、この1つのコマンドで、HostのServer TELNETプロセスがSocket1(よく広告を出しているTELNETソケット)の上のLISTENにFEを適合させた、最大32の重複のデータ経路を証明するために。 RESPONSEコマンドで、起こるとき、FEは各接続を報告するでしょう。 経路1は最初のあれほど重複の接続などを表すでしょう。 そして、Hostは個別にデータ経路を管理するかもしれません。 個々の経路は、HostによってLISTENing状態へ終わって、元の場所に置かれるかもしれません。 すべての接続が0のPATHと共にこのINDEXを指定するENDコマンドがいつでもHostによって送られることであるなら、溶かされます、そして、実際上は、HostはもうサービスをServer TELNETに供給することを望んでいません。
Host is Providing Server FTP 6e
ホストはProviding Server FTP6eです。
LISTEN ndxa,PATH=1,HOST=0,SKT=3,,CONN-TYPE=duplex+ICP,NPATH=1
ndxaを聴いてください、そして、経路は1、ホスト=0、SKT=3と等しく、コン-タイプはデュプレックス+ICP、NPATH=1と等しいです。
As soon as a RESPONSE for this LISTEN comes from the FE, the Host Server FTP process should select a new INDEX and issue a new LISTEN for ndxb on socket 3. The duplex connection which has been made is the control path for the file transfer. Based upon control information passed between server and user on ndxa (path 1) the server FTP will either:
このLISTENのためのRESPONSEがFEから来るとすぐに、Host Server FTPプロセスは、ソケット3の上に新しいINDEXを選択して、ndxbのために新しいLISTENを発行するはずです。 作られている重複の接続はファイル転送のためのコントロール経路です。 サーバFTPがそうするndxa(経路1)でサーバとユーザの間で通過された制御情報に基づく:
BEGIN ndxa,PATH=2,(hostid etc. from response),NPATHS=1
OR
LISTEN ndxa,PATH=2,(hostid etc. from response),NPATHS=1
NPATHS=1、NPATHS=1、ndxa、経路=2、(応答からのhostidなど)を始めるか、またはndxa、経路=2、(応答からのhostidなど)を聴いてください。
***WORKING DOCUMENT***
***働くドキュメント***
23
23
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
When a RESPONSE command has been received to the previous command, the data connection (PATH 2) will have been made and transfer of data may begin. The values for TRANS-TYPE and CONN-TYPE for the LISTEN or BEGIN will be derived from the exchange of information on the control path.
RESPONSEコマンドを前のコマンドに受け取ったとき、データ接続(PATH2)を作ってしまうでしょう、そして、データ転送は始まるかもしれません。 コントロール経路で情報交換からTRANS-TYPEのための値とLISTENかBEGINのためのコン-TYPEを得るでしょう。
Host Is User FTP 6f
ホストはユーザFTP6fです。
BEGIN NDXA,PATH=1,HOSTID,SKT-3,,CONN-TYPE-duplex+ICP,NPATH=1
コン-タイプデュプレックス+ICP、NPATH=1、NDXAを始めてください、そして、経路は1、HOSTID、SKT-3と等しいです。
when a RESPONSE to this command has been returned by the FE the control path will have been connected. The Host, after exchanging information on the control path, may then proceed by issuing a BEGIN or LISTEN as in the Server FTP example.
このコマンドへのRESPONSEがFEによって返されたとき、コントロール経路はつなげられてしまうでしょう。 そして、Hostは、コントロール経路で情報交換した後に、Server FTPの例のようにBEGINかLISTENを発行することによって、続くかもしれません。
Teleconferencing 6g
電子会議6g
An INDEX with n PATHs permits up to n otherwise disassociated conversations to be affiliated. Each path can be manipulated individually, or all paths as a group. With the broadcast option -- a MESSAGE command specifying INDEX but not specifying PATH will be broadcast to all open paths on that index. Thus each host may direct its messages to any or all parties.
そうでなければ、nまでのn PATHs許可証があるINDEXは、合併されるために会話を分離しました。 個別に各経路を操ることができますか、またはaとしてのすべての経路が分類されます。 放送オプション--INDEXを指定しますが、PATHは指定しないMESSAGEコマンドがそのインデックスのすべての開いている経路に放送されるでしょう。 したがって、各ホストはいずれかすべてのパーティーにメッセージを向けるかもしれません。
A "conference" may be initiated by any host who issues a LISTEN with multiple duplex paths on an agreed upon (but not necessarily well advertised) socket. When some foreign host connects, an ordinary TELNET connection exists. If, however, a third or forth or more parties connect, the hosts already engaged in the conversation may elect to inform the late comers of the members already involved. Each host may then elect to connect to as many other hosts as he desires. (The parties could agree as to who would BEGIN and who would LISTEN). Following this scheme [it is not a protocol] all parties participate equally, there is no moderator. Each host decides to whom he will speak. Using the initial LISTEN, a variation on this would permit the LISTENer to be moderator and require that he relay messages to other parties, as desired.
「会議」が複数の重複の経路がオンな状態でLISTENを発行するどんなホストによっても開始されるかもしれない、ソケットに同意しました(しかし、必ず、よく広告を出すというわけではありません)。 異種宿主が接続するとき、普通のTELNET接続は存在しています。 または、しかしながら、3分の1または先へ、 より多くのパーティーが接続して、既に会話に従事していたホストは、既にかかわったメンバーについてレートカマーに知らせるのを選ぶかもしれません。 そして、各ホストは、彼が望んでいるように同じくらい多くの他のホストに接するのを選ぶかもしれません。 (パーティーがだれに関して同意できたか、BEGIN、LISTEN)であるだろう この体系[それはプロトコルでない]に続いて、すべてのパーティーが等しく参加して、議長は全くいません。 各ホストはだれを話すかに決めます。 初期のLISTENを使用して、これの変化は、LISTENerが、議長であり、彼が相手にメッセージをリレーするのを必要とすることを許可するでしょう、望まれているように。
In summary, the data path mechanism permits a group of users to select an agreed upon socket, appoint a "moderator," and at a prescribed time engage in a conference without benefit of special protocol implementations in the FE or in any of the hosts (except possibly the moderator).
概要では、データ経路メカニズムが選ぶユーザのグループを可能にする、ソケットで同意されていて、「議長」を任命してください、そして、処方された時に、FEかホストのどれか(ことによると議長を除いた)の特別なプロトコル実装の利益なしで会議に従事してください。
***WORKING DOCUMENT***
***働くドキュメント***
24
24
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Example of the Use of Simplex Connections 6h
シンプレクスコネクションズ6hの使用に関する例
The Simplex connection types permits a host to LISTEN on a group of simplex sockets of a particular gender. If the host supported a group of line printers, for example, the Line Printer Applications Program could perform a LISTEN on a socket advertised to be his "Printing Socket," specifying as many receive paths as he had printers. Foreign hosts could then connect (via ICP) to his print socket. They would be given an appropriate working socket value and then connect to an available printer. In this way up to n foreign hosts may be connected to his n printers at all times. All that any needs to know to avail themselves of printing services is the server host's print socket. [1]
接続がタイプするSimplexは特定の性のシンプレクスソケットのグループでホストをLISTENに可能にします。 ホストがラインプリンタのグループを支持するなら、例えば、線Printer Applications Programは彼の「印刷ソケット」になるように広告に掲載されたソケットにLISTENを実行できるでしょうに、彼がプリンタを持っていたので多くが経路を受けるので指定して。 そして、異種宿主は彼の印刷ソケットに接続できました(ICPを通して)。 彼らは、適切な働くソケット値を与えて、次に、利用可能なプリンタに接続するでしょう。 このように、最大n異種宿主がいつも彼のnプリンタに接続されるかもしれません。 いずれも印刷サービスを自分たちに利用するのを知る必要があるすべてがサーバー・ホストの印刷ソケットです。 [1]
Host Implementation 7
ホスト導入7
Concepts 7a
概念7a
The Front-End Protocol permits a Host to make use of the network through existing low-level protocols, without requiring that it be cognizant of the implementation details of those protocols.
Front-終わりのプロトコルは、Hostがネットワークの存在するのによる使用を低レベルであるプロトコルにすることを許可します、それらのプロトコルの実現の詳細を認識している必要でない。
Implementation of FEP in the Host is in terms of the function it is performing or the service it is providing. Information regarding sockets is available to the sophisticated user, but can be ignored if not relevant to the problem at hand.
HostでのFEPの実現がそれが実行している機能かそれが提供しているサービスであります。 ソケットに関する情報は、当面の問題に洗練されたユーザにとって利用可能ですが、無視されているか、または関連している場合があります。
The Host should provide the equivalent of a BEGIN, LISTEN, MESSAGE, INTERRUPT, and END command. In other words, the human user or applications level process has at its disposal the full power of FEP.
HostはBEGIN、LISTEN、MESSAGE、INTERRUPT、およびENDコマンドの同等物を提供するはずです。 言い換えれば、人間のユーザかアプリケーション平らにすることの過程に、自由に、FEPの全出力があります。
The FEP module in the Host serves as a control mechanism to multiplex/ demultiplex traffic between itself and the FE. In appearance and function it is much like any multi-line interface driver. It handles REPLYS, reports errors, etc. The FEP module must also assume the responsibility for assignment of indexes. This could easily be implemented as a "GETINDEX" subroutine which would allow a user to ask for an index to be assigned to him. The user could then proceed to do BEGINs, LISTENs, etc. on that index.
HostのFEPモジュールは制御機構としてそれ自体とFEの間のマルチプレックス/「反-マルチプレックス」交通に機能します。 外観と機能では、それはどんなマルチラインインターフェースドライバーにも似ています。それは、REPLYSを扱って、誤りを報告しますなど。 また、FEPモジュールはインデックスの課題への責任を負わなければなりません。 ユーザが、インデックスが彼に割り当てられるように頼むことができる"GETINDEX"サブルーチンとして容易にこれを実行できました。 そして、ユーザはそのインデックスでBEGINs、LISTENsなどができかけました。
A server process makes itself available to the network at large by issuing an appropriate LISTEN. The Host FEP module would not have to be aware of what servers were implemented or in operation. The server process, when it was
サーバの過程で、それ自体は、適切なLISTENを発行することによって、全体のネットワークに利用可能になります。 Host FEPモジュールはどんなサーバが実行されるか、操作中であったかを意識している必要はないでしょう。 サーバの過程、いつであった
***WORKING DOCUMENT***
***働くドキュメント***
25
25
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
activated, could do a "GETINDEX," followed by a LISTEN on its well-advertised socket, and then proceed from there. The Host FEP module simply associates indexes to processes and passes the incoming traffic to the appropriate process for analysis and response. It maintains flow between itself and the FE through the generation and receipt of REPLYs.
活性であり、"GETINDEX"ができて、aがあとに続いて、よく広告を出しているソケットの上に聴いてください、そして、次に、そこから続いてください。 Host FEPモジュールは、分析と応答のために単にインデックスを過程に関連づけて、入って来る交通を適切な過程に通り過ぎます。 それはREPLYsの世代と受領でそれ自体とFEの間の流れを維持します。
The type of data structures, or format of information employed in the implementation of the FEP commands in the Host is, of course, up to the implementor. BEGIN could be a macro call, with the various information passed as parameters to the Host FEP module -- which would then arrange it into a command for delivery to the Front-End processor. The important consideration is not how the commands are implemented, but simply that their function is provided. It might be desirable, for instance, to implement the Host such that the front-end processor looks like a special I/O device. In this case, it may be appropriate to implement a form of OPEN [for BEGIN or LISTEN], a GET or PUT [for MESSAGE], CLOSE [for END], etc...
データ構造のタイプ、またはHostでのFEPコマンドの実現で使われた情報の形式がそうである、もちろん、作成者まで。 BEGINがマクロ呼び出しであるかもしれない、様々で、情報はパラメタとしてHost FEPモジュール次に(Front-エンドプロセッサへの配送のためのコマンドにそれをアレンジする)に終わりました。 重要な考慮すべき事柄はそれらの機能が絶対に提供されていなかったならコマンドがどのように実行されるかということではありません。 例えば、Hostを実行するのが望ましいかもしれないので、フロントエンドプロセッサは特別な入出力装置に似ています。 この場合、オープン[BEGINかLISTENのための]のフォームやGETやPUT[MESSAGEのための]、CLOSE[ENDのための]などを実行するのは適切であるかもしれません。
Regardless of the implementation details, it appears that, while it is the responsibility of one control module to assign and manage INDEXes, data paths are entirely the responsibility of the process which "owns" the INDEX.
実現の詳細にかかわらず、INDEXesを割り当てて、管理するのが、1つのコントロールモジュールの責任ですが、データ経路が完全にINDEXを「所有している」過程の責任であるように見えます。
Installation Parameters 7b
インストールパラメタ7b
To package the software for the FE for a given Host, that Host supplies a number of parameters defining what FE capabilities it requires. These parameters are input to a system-generation procedure to produce the particular FE code.
与えられたHostのためにFEのためのソフトウェアをパッケージするために、そのHostはそれがどんなFE能力を必要とするかを定義する多くのパラメタを提供します。 これらのパラメタは、特定のFEコードを作成するためにシステム生成手順に入力されます。
The parameters are:
パラメタは以下の通りです。
Byte Size
バイトサイズ
This gives the size in bits, into a multiple of which each and every field of a command string will be right-justified (i.e., the information bits come last, preceded by as many padding bits as are needed to complete the least integral number of bytes).
これはビットのサイズを与えます、コマンドストリングのありとあらゆる分野がまさしく正当になる倍数に(すなわち、情報ビットが最後に来ます、最も不可欠でないバイト数を完成するのが必要であるのと同じくらい多くの詰め物ビットが先行して)。
Its value will normally be 8 but other values will be accommodated as necessary.
値は通常8になるでしょうが、他の値は必要に応じて設備されるでしょう。
***WORKING DOCUMENT***
***働くドキュメント***
26
26
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Command String Padding
コマンドストリング詰め物
This gives the size in bits of the width of the hardware interface between the Host and the FE, such that every command string transmitted in either direction will have padding appended to complete the least multiple of this width.
これはHostとFEとのハードウェア・インタフェースの幅のビットのサイズを与えます、この幅の最少の倍数を完成するためにどちらの方向にも伝えられたあらゆるコマンドストリングで詰め物を追加するように。
In the typical implementation, this parameter will be 0 and any padding required will be appended/discarded by the line protocol underlying FEP.
典型的な実現では、線プロトコルの基本的なFEPはこのパラメタを0歳であり、追加するか、または捨てるでしょうどんな詰め物も、必要であった。
Pad Field Length
パッドフィールド長
This gives the size in bits of the PAD field in the MESSAGE command. This enable a Host to have the TEXT field start on a convenient boundary.
これはMESSAGEコマンドにおける、PAD分野のビットのサイズを与えます。 これは、HostがTEXT分野に便利な境界を始めさせるのを可能にします。
Its value can be anywhere in the range 0 to 64.
値が範囲でどこでも0〜64にあることができます。
Maximum of MESSAGE
メッセージの最大
This gives the maximum length of a MESSAGE command string.
これはMESSAGEコマンドストリングの最大の長さを与えます。
Because buffer allocation in the FE is based on this parameter, its value should be chosen with care.
FEでのバッファ配分がこのパラメタに基づいているので、値は慎重に選ばれるべきです。
Maximum number of Indexes
Indexesの最大数
This gives the maximum number of indexes which may be set-up at any one time.
これはいかなる時もセットアップであるかもしれないインデックスの最大数を与えます。
Maximum Number of Paths
最大のパスの数
This gives the maximum number of paths within one index which may be open at any one time.
これは1つのいかなる時も開くかもしれないインデックスの中で最大のパスの数を与えます。
Translation Types
翻訳タイプ
This gives the set of required values and meanings of the TRANS-TYPE field of the BEGIN/LISTEN commands. The TRANS-TYPE field is divided into two 8-bit subfields; the first giving the format of data on the
これはBEGIN/LISTENコマンドのTRANS-TYPE分野の必要な値と意味のセットに与えます。 TRANS-TYPE分野は2つの8ビットの部分体に分割されます。 1番目はデータの書式をオンに与えます。
***WORKING DOCUMENT***
***働くドキュメント***
27
27
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
network side; the second giving the format of data on the Host side. The FE is required to translate between these formats all data contained in the TEXT field of MESSAGE commands.
側をネットワークでつないでください。 Host側でデータの書式を与える秒。 FEはこれらの形式の間でMESSAGEコマンドのTEXT分野に保管されていたすべてのデータを翻訳しなければなりません。
This parameter specifies the required formats and their values in the 8-bit subfields. The value 0 is reserved to mean "bit-string" and when it appears as either (or both) of the subfields it implies no translation is to be done.
このパラメタは8ビットの部分体における必要な形式とそれらの値を指定します。 値0は、「ビット列」といつ部分体のどちらか(ともに)としてどんな翻訳もしないつもりであることであるように見えるかを意味するために予約されます。
Broadcast Option
放送オプション
This specifies whether the Host wants to be able to use the Broadcast feature (see Section 3j).
これは、HostがBroadcastの特徴を使用できるようになりたいかどうか(セクション3jを見てください)指定します。
Operator-to-Operator Communication Option
オペレータからオペレータへのコミュニケーションオプション
This specifies whether the Host wants the ability to send messages to the FE operator or to have the Host's operator receive messages from the FE.
これは、HostがFEオペレータにメッセージを送るか、またはHostのオペレータにFEからメッセージを受け取らせる能力が欲しいかどうか指定します。
Other options may be included in the protocol at some later date and these will be available through installation parameters similar to the Broadcast option.
別の選択肢はいつかの後の期日のプロトコルに含まれるかもしれません、そして、これらはBroadcastオプションと同様のインストールパラメタを通して利用可能になるでしょう。
Note that all of these parameters affect the size and complexity of the FE code. Thus it is important that their values be chosen carefully so as to maximize FE efficiency while minimizing Host implementation effort.
これらのパラメタのすべてがFEコードのサイズと複雑さに影響することに注意してください。 したがって、それらの値がHost実現の努力を最小にしている間、FE効率を最大にするために慎重に選ばれているのは、重要です。
For descriptions of individual Host implementations and a list of the options available so far, see Appendix D.
個々のHost実現の記述とオプションの今までのところ利用可能なリストに関しては、Appendix Dを見てください。
FE Implementation 8
FE実現8
FEP is device independent. For the present however, an initial implementation will be accomplished using the DEC PDP/11 computer as the FE device and the front-end software is to be based upon an extended version of the original ELF system developed at SCRL.
FEPは装置独立者です。 しかしながら、プレゼントにおいて、初期の実現は、FE装置とフロントエンドソフトウェアがSCRLで開発されたオリジナルのELFシステムの拡張版に基づくことであるのでDEC PDP/11コンピュータを使用することで実行されるでしょう。
For more detailed information, see Appendix C.
より詳細な情報に関しては、Appendix Cを見てください。
by : 9 G. W. Bailey (BAILEY@OFFICE-1) K. McCloghrie (MCCLOGHRIE@OFFICE-1)
: 9 G.W.べイリー( BAILEY@OFFICE-1 )K.McCloghrie( MCCLOGHRIE@OFFICE-1 )
***WORKING DOCUMENT***
***働くドキュメント***
28
28
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
APPENDIX A 10
付録は10です。
References
参照
[1] ICP is used in this document in a less strict manner than specified in NIC 7101, in that it is not necessarily two simplex connections that are set up as the result of the exchange of the socket number on the initial connection.
[1] ICPは本書では初期の接続のソケット番号の交換の結果としてのそれが必ずセットアップされる2つのシンプレクス接続であるというわけではないのでNIC7101で指定されるほど厳しくない方法で使用されます。
[2] An example of connections needing to be affiliated, is in the implementation of FTP, where the control connection and the data connection have a defined relationship in their socket assignments.
[2] 接続に関する例が、合併される必要があるので、定義された関係はFTPの実現彼らのソケット課題で中ですか?(そこでは、コントロール接続とデータ接続はそうしました)。
[3] Note that a range of socket numbers is reserved for use by an index when it is set-up (cf. AEN).
[3] それがセットアップであるときに、さまざまなソケット番号が使用のためにインデックスによって予約されることに注意してください。(Cf。 AEN).
However, socket numbers for the paths of an index are not necessarily contiguous. For instance, when the next path opened after a SEND path is another SEND path, or when a path other than the first of an index is opened with ICP specified. Nevertheless, if a protocol requires contiguous sockets, then the opening of the paths in a logical manner will provide the contiguity.
しかしながら、インデックスの経路のソケット番号は必ず隣接であるというわけではありません。 例えば、SEND経路がSEND経路になるのであった別後に次の経路がいつ開いたか、そして、またはインデックスの1番目を除いた経路がいつICPと共に開かれるかが指定しました。 それにもかかわらず、プロトコルが隣接のソケットを必要とすると、論理的な方法による経路の始まりは接触を提供するでしょう。
[4] One possible translation will be from a Network Virtual Terminal on the network side to a local terminal type on the Host side.
[4] ネットワーク側の上のNetwork Virtual TerminalからHost側のローカル・ターミナルタイプまで1つの可能な翻訳があるでしょう。
[5] The FE will directly equate the INTERRUPT command with the Host-Host protocol INR/INS commands.
[5] FEは直接Host-ホストプロトコルINR/INSコマンドとINTERRUPTコマンドを同一視するでしょう。
[6] Note that the READY indication in a REPLY is, in the general case, not directly related to a network RFNM; unless it is heavily loaded, the FE will be buffering possibly more than one message (in either direction) until flow control mechanism allow the messages to be sent on.
[6] REPLYのREADY指示が一般的な場合で直接ネットワークRFNMに関連しないことに注意してください。 それが大いにロードされないと、フロー制御メカニズムが転送されるべきメッセージを許容するまで、FEはことによると1つ以上のメッセージ(どちらかの方向への)をバッファリングするでしょう。
However, it is possible that a particular Host might wish to have knowledge of receipt of a previous message before transmitting the next. In this case, the FEP implementation could be set up to only indicate READY after receiving the RFNM and possibly only send RFNMs after receiving a REPLY containing an ACK.
しかしながら、次を伝える前に、特定のHostには前のメッセージの領収書に関する知識がありたいのは、可能です。 この場合、RFNMを受けた後に、READYを示すだけであり、ACKを含むREPLYを受けた後にことによるとRFNMsを送るだけであるためにFEP実現をセットアップできました。
***WORKING DOCUMENT***
***働くドキュメント***
29
29
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
APPENDIX B 11
付録B11
State Diagrams
州のダイヤグラム
In the state diagrams below the following notation is used:
以下の州のダイヤグラムで、以下の記法は使用されています:
REPLY(A) - REPLY with ACK=1, READY/NOT-READY irrelevant REPLY(N) - REPLY with NAK=1, READY/NOT-READY irrelevant REPLY(R) - REPLY with ACK=0, NAK=0, READY=1 REPLY(A+R) - REPLY with ACK=1, READY=1 REPLY(N+R) - REPLY with NAK=1, READY=1 REPLY(A+NR) - REPLY with ACK=1, NOT-READY=1 REPLY(N+NR) - REPLY with NAK=1, NOT-READY=1
REPLY(A)--READY=1 REPLY(+ NR)--ACK=1とREPLY、READY=1 REPLY(N+NR)でない--ACK=1とREPLY、READY/READYでないことの無関係のREPLY(N)--NAK=1とREPLY、READY/READYでないことの無関係のREPLY(R)--ACK=0とREPLY、NAK=0、READY=1 REPLY(+R)--ACK=1、READY=1 REPLY(N+R)とREPLY--NAK=1とREPLY、NAK=1とREPLY、READY=1でない
State Diagram for INDEX
インデックスのための州のダイヤグラム
/ ------\ /-------\ /-----\
! !BEGIN(new index) ! ! ! !
! !->--------------->-!Index ! ! !
!Index !LISTEN(new index) !Open ! ! !
!Closed ! !Pending! !Index!
! ! REPLY(N)! !REPLY(A) !Open !
! !-<---------------<-! !->------->-! !
! ! \-------/ ! !
! ! ! !
! ! /-------\ END(Path=0)! !
! ! ! !-<-------------<-! !
! ! REPLY(A)!Index ! ! !
! !-<---------<-!Close !REPLY(N) ! !
! ! !Pending!->------------->-! !
\-------/ \-------/ \-----/
/ ------\ /-------\ /-----\!BEGIN(新しいインデックス)!->。--------------->。オープン!Index!Index!LISTEN(新しいインデックス)!Closed!Pending! 索引をつけてください! ! ! 回答(N)! REPLY(A)!オープン!-<。---------------<。! ->。------->。! ! ! ! \-------/ ! ! ! ! ! ! ! ! /-------\は(経路=0)を終わらせます! ! ! ! ! -<。-------------<。! ! ! ! REPLY(A)!インデックス!-<。---------<。閉鎖!->まで回答(N)!------------->。! ! \-------/ \-------/ \-----/
***WORKING DOCUMENT***
***働くドキュメント***
30
30
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
APPENDIX B (continued)
付録B(続けられています)
State Diagram for Whole Path
全体の経路への州のダイヤグラム
/------\BEGIN /----------\
! !->-------->-! !
! !LISTEN !Connection!
!Path ! !Pending !REPLY(A) /-------\
!Closed! REPLY(N)! !->------------>-! !
! !-<--------<-! ! ! !
! ! \----------/ !Path !
! ! !Conn- !
! ! /-----\ RESPONSE(CODE>0)! ecting!
! ! ! !-<-----------------<-! !
! ! !Path ! ! !
! ! REPLY(A)!Abort! END(PATH>0)! !
! !-<--------<-!Pend-!-<-----------------<-! !
! ! ! ing ! ! !
! ! ! !REPLY(N) ! !
\------/ ! !->----------------->-! !
\-----/ ! !
! !
/-------\ ! !
! ! RESPONSE(CODE=0)! !
/----\ !Path !-<--------------<-! !
! ! !Open ! ! !
!Path! !Pending!REPLY(N) ! !
!Open! REPLY(A)! !->-------------->-! !
! !-<--------<-! ! \-------/
\----/ \-------/
/------\は/を始めます。----------\!->。-------->。! ! ! 接続を聴いてください! REPLY(A)/まで経路!-------\!閉じられる! 回答(N)! ->。------------>。! ! ! -<。--------<。! ! ! ! ! ! \----------/!経路!コン/-----\、RESPONSE(CODE>0)!ecting! ! ! ! -<。-----------------<。! ! ! ! REPLY(A)!経路!中止になってください! (経路>0)を終わらせてください! ! ! -<。--------<。Pend!-<。-----------------<。! ! ! ! ! ing!回答(N)!\------/!->。----------------->。! ! \-----/ ! ! ! ! /-------\!応答(コード=0)! ! /----\!経路!-<。--------------<。! ! ! ! オープン!経路! 回答(N)!まで、開いてください! REPLY(A)! ->。-------------->。! ! ! -<。--------<。! ! \-------/ \----/ \-------/
***WORKING DOCUMENT***
***働くドキュメント***
31
31
RFC 705 Front-End protocol
RFC705Front-終わりのプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
APPENDIX B (continued)
付録B(続けられています)
State Diagram for Each Direction of Path
経路の各指示のための州のダイヤグラム
/----\MESSAGE /-------\ /-------\
! !->---------------->-! !REPLY(A+NR) ! !
!Path!INTERRUPT !Command!->--------->-!Message!
!Open! !Blocked!REPLY(N+NR) !Blocked!
! ! ! ! ! !
! ! REPLY(A+R)! ! INTERRUPT! !
! !-<----------------<-! !-<---------<-! !
! ! REPLY(N+R)\-------/ ! !
! ! REPLY(R)! !
! !-<----------------------<---------------<-! !
! ! ! !
! !END(PATH>0) /-------\ END(PATH>0)! !
! !->---------------->-! !-<---------<-! !
! ! ! ! ! !
! ! REPLY(N+R)!Path !REPLY(N) ! !
! !-<----------------<-!Close !->--------->-! !
\----/ !Pending! \-------/
! !
/------\ REPLY(A)! !
!Path !-<--------------<-! !
!Closed! ! !
! ! \-------/
\------/
/----\メッセージ/-------\ /-------\!->。---------------->。! 回答(+ NR)!経路!中断!命令!->。--------->。メッセージ! 開いてください! (N+NR!)が妨げた回答を妨げました! ! ! ! ! ! ! ! ! 返答してください(+R)! ! 中断してください! ! ! -<。----------------<。! -<。---------<。! ! ! ! 回答(N+R)\-------/!回答(R)! ! ! -<。----------------------<、-、-、-、-、-、-、-、-、-、-、-、-、-、--、<。! ! ! ! ! ! ! 終わり(経路>0)の/-------\は(経路>0)を終わらせます! ! ! ->。---------------->。! -<。---------<。! ! ! ! ! ! ! ! ! ! 回答(N+R)!経路!回答(N)!-<。----------------<。閉鎖!->。--------->。! ! \----/!未定! \-------/ ! ! /------\REPLY(A)! ! 経路!-<。--------------<。! ! 閉じられる! ! ! ! ! \-------/ \------/
***WORKING DOCUMENT***
***働くドキュメント***
32
32
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
APPENDIX C
付録C
Front-End Implementation
フロントエンド実現
Introduction
序論
A Network Access System (NAS), developed for a DEC PDP/11 computer, supports the current Imp-Host, Host-Host and ICP protocols. The implementation of these protocols facilitate process-process communications across the network and multi-user TELNET access to foreign hosts. This NAS provides the FE environment in which FEP is implemented.
DEC PDP/11コンピュータのために開発されたNetwork Access System(NAS)は現在のImp-ホスト、Host-ホスト、およびICPにプロトコルをサポートします。 これらのプロトコルの実装は異種宿主へのネットワークとマルチユーザTELNETアクセスの向こう側にプロセス間通信を容易にします。 このNASはFEPが実装されるFE環境を提供します。
The NAS system is comprised of a Kernel or executive section and a Network Control Program (NCP) plus a collection of modules to support device interfaces, handle terminals, and implement applications, as appropriate. The software is modular and extensible.
NASシステムは、Kernelか総務部から成ってNetwork Control Program(NCP)とデバイス・インタフェースをサポートして、端末を扱って、アプリケーションを実装するモジュールの収集です、適宜。 ソフトウェアは、モジュールであって広げることができます。
The KERNEL
カーネル
The Kernel of the system consists of a set of functional modules which perform the task of resource management in a multiprocessing environment. This allows processes to be created, vie for processor service according to priority, intercommunicate, and be terminated. System primitives exist for various tasks such as process creation and synchronization, storage allocation, and sharing of the interval timer.
システムのKernelは多重処理環境における資源管理に関するタスクを実行する1セットの機能モジュールから成ります。 これは、プロセスが作成されて、順位によってプロセッササービスを競って、通信し合って、終えられるのを許容します。 システム基関数はインタバルタイマのプロセス作成や、同期や、記憶領域の割当てや、共有などの様々なタスクのために存在しています。
The term process used here describes an autonomous sequence of states brought about by the PDP-11 processor; a process' state is characterized by the set of processor registers, a stock, and process-owned storage areas. Process share storage areas which are accessed only (eq. pure code). Processes also share storage areas which may be updated (eq. control tables). In this case an allocation mechanism is utilized to prevent simultaneous ownership of an updatable storage area. The storage area is thus viewed as a sequentially sharable resource which is allocated by the process, modified, and then released.
ここで使用された用語プロセスはPDP-11プロセッサによって引き起こされた州の自治の系列について説明します。 過程の状態はプロセッサレジスタ、ストック、およびプロセスで所有されているストレージ領域のセットによって特徴付けられます。 アクセスされたシェアストレージ領域(eq純粋なコード)だけを処理してください。 また、プロセスはアップデートされるかもしれないストレージ領域(eq制御卓)を共有します。 この場合、配分メカニズムは、アップデート可能ストレージ領域の同時の所有権を防ぐのに利用されます。 ストレージ領域は、変更されたプロセスによって割り当てられる連続して共有可能なリソースとしてこのようにして見なされて、次に、リリースされます。
Processes are given control of the processor by a single procedure called the Dispatcher. Processes are said to be in a ready state or in a waiting state. When a process blocks itself, control is given to the highest priority ready process.
Dispatcherと呼ばれるただ一つの手順によるプロセッサの支配力をプロセスに与えます。 プロセスはレディ状態か待ち状態にはあると言われています。 プロセスがそれ自体を妨げるとき、最優先の持ち合わせのプロセスに支配力を与えます。
***WORKING DOCUMENT***
***働くドキュメント***
33
33
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Each process has an associated input message queue. This queue is the vehicle for interprocess communication. A process is blocked (put into a wait state) when its input message queue becomes empty (voluntary wait), or when an interrupt occurs (involuntary wait) because a higher priority process is to receive control of the processor. A process may voluntarily block itself waiting for any signal, or it may block itself for a specific event to be posted to its input message queue.
各プロセスには、関連入力メッセージキューがあります。 この待ち行列はプロセス間通信のための手段です。 入力メッセージキューが空になるか(自発的の待ち)、または、より高い優先権プロセスがプロセッサのコントロールを受けることになっているので中断が発生するとき(不本意な待ち)、プロセスは妨げられます(待ち状態に入れます)。 プロセスがどんな信号も待ちながら、自発的にそれ自体を妨げるかもしれませんか、またはそれは特定のイベントが入力メッセージキューに掲示されるためにそれ自体を妨げるかもしれません。
The Network Control Program
ネットワーク・コントロール・プログラム
The NCP provides "third level" protocol functions to local processes. It contains a process which decodes and passes messages which have been received from the IMP and placed on the IMP-Host queue. This process interacts with other processes which call the NCP to establish connections or to transmit data. Thus the NCP is essentially divided into two parts:
NCPは「3番目に平らな」プロトコル機能を地方のプロセスに提供します。 それはIMPから受け取られて、IMP-ホスト待ち行列に置かれたメッセージを解読して、通過するプロセスを含んでいます。 このプロセスは関係を樹立するか、またはデータを送るためにNCPを呼ぶ他のプロセスと対話します。 したがって、NCPは本質的には2つの部品に分割されます:
1) a process which handles incoming messages from the network,
interprets IMP-Host and Host-Host control messages, and forwards
regular messages on established connections; and
1) ネットワークからの入力メッセージを扱って、IMP-ホストとHost-ホストコントロールメッセージの機械言語に翻訳処理をして、確立した接続に関する通常のメッセージを転送するプロセス。 そして
2) a set of primitives which allow local processes to establish
connections to other processes across the network, and to perform
requests for data to be transferred on these connections.
2) 地方のプロセスがネットワークの向こう側に他のプロセスに関係を樹立して、データがこれらの接続のときに移されるという要求を実行する1セットの基関数。
There are two primary data structures used by the NCP to monitor the status of network connections. The first is called the Host Table, and describes that which is peculiar to each given host; the second is referred to as a Connection Table and contains all information on the state of a local NCP socket (connection). Connection Tables may be created either through external requests (e.q., an RFC is received from a remote host) or through internal requests (e.g., a local process performs a LISTEN).
NCPによって使用される、ネットワーク接続の状態をモニターする2つのプライマリデータ構造があります。 1番目は、Host Tableと呼ばれて、それぞれの与えられたホストにとって、独特のそれについて説明します。 2番目は、地方のNCPソケット(接続)の州にConnection Tableと呼ばれて、すべての情報を含んでいます。 接続Tablesは外部要求(e.q.、リモートホストからRFCを受け取る)を通して、または、内部の要求を通して作成されるかもしれません(例えば、地方のプロセスはLISTENを実行します)。
Flow control is that portion of the NCP which governs the flow of data on connections. There are two procedures which perform this task; one which handles receive connections and one which handles send connections. These procedures receive control when an event has occurred which may now make it possible to transfer data on a connection.
フロー制御は接続でのデータの流れを治めるNCPのその部分です。 このタスクを実行する2つの手順があります。 それのハンドルが接続を受けるものとハンドルが接続に送るもの。 これらの手順はイベントが起こったときの接続のときに今データを移すのを可能にするかもしれないコントロールを受けます。
Both send and receive flow control procedures have the responsibility of moving data between local process buffers and messages being received or transmitted over the network. In addition, they handle the formatting and unpacking of
ローカルのプロセスバッファと受け取られるメッセージの間の感動的なデータの責任を持っているか、またはネットワークの上に伝えられて、両方が、フロー制御手順を送って、受けます。 さらに、彼らは形式と荷を解くことを扱います。
***WORKING DOCUMENT***
***働くドキュメント***
34
34
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
messages received. Local processes are unaware that data is being transmitted as discrete messages.
メッセージは受信されました。 地方のプロセスはデータが離散的なメッセージとして送られているのを気づきません。
The NCP watchdog process monitors the state of network connections, checking for error conditions and performing garbage collection tasks. It receives control at periodic intervals and scans the list of known hosts, looking for existing connections. For each host to which an input or output connection exists, the Watchdog causes a Host-Host NOP message to be sent. Thus if a remote Host crashes while data is being awaited, local processes are informed of the error condition. The NCP takes notice of the remote crash when it receives a IMP--Host type 7 control message (Destination Host Dead). It then automatically closes all connections to that Host, and notifies using processes of that fact.
エラー条件がないかどうかチェックして、ガーベージコレクションタスクを実行して、NCP番犬プロセスはネットワークの状態接続をモニターします。 既存の接続を探して、それは、周期的な間隔で、コントロールを受けて、知られているホストのリストをスキャンします。 入力か出力接続が存在する各ホストに関しては、Watchdogは送られるべきHost-ホストNOPメッセージを引き起こします。 したがって、データが待たれている間、リモートHostがダウンするなら、地方のプロセスはエラー条件において知識があります。 IMPを受けるとき、NCPはリモートクラッシュに注意を払います--ホストタイプ7コントロールメッセージ(目的地Host Dead)。 それは、次に、自動的にすべての接続をそのHostに終えて、プロセスを使用することでその事実について通知します。
A second function of the NCP Watchdog is to check for connections hung because of an outstanding RFNM. If a RFNM is not received for a specified interval, the message is discarded, and the associated connection closed.
NCP Watchdogの2番目の機能は傑出しているRFNMに絞首刑にされた接続がないかどうかチェックすることです。 RFNMが指定された間隔の間、受け取られないなら、メッセージは捨てられました、そして、関連接続は閉じました。
The FEP Handler
FEP操作者
The Front-End Protocol is implemented as a collection of related, but specialized processes which manage network connections on the one side, and manage FEP paths and indexes on the other. Some FEP processes are NCP users. They cause network connections to be made, rule on incoming RFCs, and both accept and generate network data. Other FEP processes support the Host. These processes parse incoming commands, create indexes and paths, control the generation of replies and generally manage the paths. Certain FEP processes control specialized tasks such as translation of data, servicing of LISTEN commands and generation of RESPONSE commands.
Front-終わりのプロトコルは半面の上でネットワーク接続を管理して、もう片方でFEP経路とインデックスを管理する関連しますが、専門化しているプロセスの収集として実装されます。 いくつかのFEPプロセスがNCPユーザです。 彼らは、ともにネットワークデータをネットワーク接続が作られていることを引き起こして、入って来るRFCsの判決を下して、受け入れて、生成します。 他のFEPプロセスはHostをサポートします。 これらのプロセスは、受信コマンドを分析して、インデックスと経路を作成して、回答の世代を制御して、一般に、経路を管理します。 あるFEPプロセスはデータに関する翻訳や、LISTENコマンドの整備点検やRESPONSEコマンドの世代などの専門化しているタスクを制御します。
Two data structures provide control information for FEP activities. An Index Table exists for each active index. Each Index Table associates one or more Path Table entries. Information in the Path Table reflects the state of the path, the translation type specified for data on this path, and necessary information to associate the path to any appropriate NCP Connection Tables. The Path Table is the common interface for all of the FEP modules. Most FEP processes are activated to service some event which is usually associated to a path. The action of the process will likely be dictated by the state of the path as indicated by the Path Table entry, and may result in altering the state of the path or the activation of one or more other FEP processes.
2つのデータ構造がFEP活動のための制御情報を提供します。 Index Tableはそれぞれのアクティブなインデックスのために存在しています。 各Index Tableは1つ以上のPath Tableエントリーを関連づけます。 Path Tableの情報は経路の状態を反映します、と翻訳タイプがどんな適切なNCP Connection Tablesにも経路を関連づけるためにこの経路、および必要事項に関するデータに指定しました。 Path TableはFEPモジュールのすべてのための一般的なインタフェースです。 ほとんどのFEPプロセスが、通常、経路に関連づけられる何らかのイベントを修理するために動かされます。 プロセスの動作は、Path Tableエントリーで示されるように経路の州によっておそらく書き取られて、経路の状態を変更するか、他の1つ以上のFEPプロセスの起動をもたらすかもしれません。
***WORKING DOCUMENT***
***働くドキュメント***
35
35
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
Two message queues provide Host input and output to the FEP modules. A line protocol mechanism services these queues. Commands from the Host are placed on the FEP Input queue by the line protocol process and the FEP Host Input process is signaled. When an FEP Host Output module places a Command for the Host on the host Output queue it signals the line protocol process.
2つのメッセージキューがFEPモジュールに入出力されたHostを提供します。 系列プロトコルメカニズムはこれらの待ち行列を修理します。 HostからのコマンドはFEP Input待ち行列に関して系列プロトコルプロセスによって課されます、そして、FEP Host Inputプロセスは合図されます。 FEP Host OutputモジュールがHostのためにホストOutput待ち行列にCommandを置くとき、それは系列プロトコルプロセスに合図します。
The FEP implementation is basically Host independent down to the level of the Host Input and Host Output queues.
FEP実装は、基本的にHost InputのレベルまでのHost独立者とHost Output待ち行列です。
The Line Protocol Mechanism
線プロトコルメカニズム
The device interface and the line protocol between the FE and the Host are installation dependent. Because of this dependency, only a general discussion of the Line Protocol Mechanism is possible in this context. Detailed descriptions of the specific line protocols are included in the section for each Host.
FEとHostの間のデバイス・インタフェースと系列プロトコルはインストールに依存しています。 この依存のために、線プロトコルMechanismの一般的な議論だけがこのような関係においては可能です。 特定の系列プロトコルの詳述は各Hostのためのセクションに含まれています。
The communications discipline and physical device characteristics may vary considerably from host to host. All FEP line protocols, however, will show certain common characteristics. The interface between the FEP handler and the Line Protocol Mechanism will always be Host Input and Host Output queues. All line protocol mechanisms will be expected to guarantee the integrity of the data. This implies some form of flow control, error detection/correction and retransmission capability, as well as normal transmit/receive responsibilities. The Line Protocol Mechanism will be expected to report failure after unsuccessfully attempting to perform an I/O operation. The number of retries etc. before reporting failure is an installation parameter. The FEP Handler works only in terms of FEP commands. The line protocol may provide for block transfers where each physical block is comprised of one or more FEP commands. If such is the case, it is encumbent upon the Line Protocol Mechanism to deblock the incoming Host commands before placing them in the Host Input queue.
ホストによってコミュニケーション規律とフィジカル・デバイスの特性はかなり異なるかもしれません。 しかしながら、すべてのFEP系列プロトコルが、ある共通する特徴を示すでしょう。 FEP操作者と線プロトコルMechanismとのインタフェースは、いつもHost InputとHost Output待ち行列になるでしょう。 すべての系列プロトコルメカニズムがデータの保全を保証すると予想されるでしょう。 これは、何らかのフォームのフロー制御、誤り検出/修正、「再-トランスミッション」能力、および標準が責任を伝えるか、または受けるのを含意します。 入出力操作を実行するのを試みたとき後失敗した線プロトコルMechanismが失敗を報告すると予想されるでしょう。 失敗を報告する前の再試行などの数はインストールパラメタです。 FEP Handlerは単にFEPコマンドで働いています。 系列プロトコルはそれぞれの物理的なブロックが1つ以上のFEPコマンドから成るブロック転送に備えるかもしれません。 そのようなものがケースであるなら、それはHost Input待ち行列にそれらを置く前に入って来るHostコマンドを非ブロック化する線プロトコルMechanismのencumbentです。
The Line Protocol Mechanism will, in the general case, not manage any buffers. After successfully transmitting a command to the Host it is responsible for reporting the I/O complete, but the buffer space is freed or reused only by the FEP process which "owns" that space. The FEP Handler might use buffer assignment to control the rate of incoming traffic. When the FEP Host Input queue is ready to accept an additional command, it would acquire a buffer and signal the Line Protocol Mechanism, passing it a pointer to a buffer. This
一般的な場合では、線プロトコルMechanismはどんなバッファも管理しないでしょう。 首尾よくコマンドをHostに伝えた後に、入出力が完全であると報告するのにそれは責任がありますが、バッファ領域は、そのスペースを「所有している」FEPプロセスだけによって、解放されるか、または再利用されます。 FEP Handlerは、入って来るトラフィックのレートを制御するのにバッファ課題を使用するかもしれません。 FEP Host Input待ち行列が追加コマンドを受け入れる準備ができているとき、バッファを取得して、線プロトコルMechanismに合図するでしょう、バッファへの指針をそれに通過して。 これ
***WORKING DOCUMENT***
***働くドキュメント***
36
36
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
is effectively a "read" request. When the line protocol handler has filled the buffer, it adds it to the Host Input queue and signals I/O complete to the appropriate FEP process.
事実上「読むこと」は要求ですか? 系列プロトコル操作者がバッファをいっぱいにしたとき、それは適切なFEPプロセスに完全なHost Input待ち行列と信号入出力にそれを加えます。
If the nature of the physical connection is such that the FE must accept unsolicited input, it may be necessary for the Line Protocol Mechanism to have its own buffer pool, in addition. If this is the case, it must be entirely managed by the line handler and transparent to the FEP Handler.
FEが物理接続の本質がそのようなものであるので求められていない入力を受け入れなければならないなら、線プロトコルMechanismにはそれ自身のバッファプールがあるのが必要であるかもしれません、さらに。 これがそうであるなら、系列操作者によって完全に管理されていてFEP Handlerに透明であるに違いありません。
Data Translations
データ変換
The TRANS-TYPE provisions in FeP may be employed for at least two general services. First, it can be used for normal character set substitutions. This is where, in the general case, there is a one-to-one relationship between the two character sets.
FePのTRANS-TYPE条項は少なくとも2つの一般的なサービスに使われるかもしれません。 まず最初に、通常の文字集合代替にそれを使用できます。 これは2つの文字集合の間に一般的な場合には1〜1つの関係があるところです。
The second service addresses the problem of data transformation. In this case, there need not be a one-to-one relationship between incoming data and outgoing data.
セカンドサービスはデータ媒体変換のその問題を訴えます。 この場合、受信データと発信データとの1〜1つの関係がある必要はありません。
The translation mechanism uses a token (e.g., a character) from the incoming data stream to index into a translation table. The result may be one of the following:
変換メカニズムは受信データストリームからインデックスまでトークン(例えば、キャラクタ)を変換テーブルに使用します。 結果は以下の1つであるかもしれません:
a) do nothing, drop the character b) output the character unchanged c) substitute input character by output character d) substitute input character by output string e) activate a procedure indicated by the table f) change the translation g) test the translation mode and do any of the above depending on the result.
a)は何もしないで、キャラクタb)がキャラクタの変わりのないc)代わりの入力キャラクタを出力した低下はキャラクタのd)代わりの入力キャラクタを出力しました。ストリングe)が起動する出力で、手順は、テーブルf)変化で翻訳g)が結果で翻訳モードをテストして、上の依存のどれかをするのを示しました。
For each translation/transformation required by the Host a translation table must be defined. For simplicity and clarity the TRANS-TYPE field in the FEP commands allows the user to specify Host side and Network side as independent entities. In actual execution the Host/Network pair addresses a translation table which must have been previously defined. Note that for a duplex path two translation tables are necessary (A->B is not the same as A<-B).
Hostによって必要とされた各翻訳/変換において、変換テーブルを定義しなければなりません。 ユーザがFEPコマンドにおけるTRANS-TYPE分野で指定できる簡単さと明快ために、Hostは面があります、そして、Networkは独立実体として面があります。 実際の実行では、Host/ネットワーク組は以前に定義されたに違いない変換テーブルを扱います。 重複の経路に、2つの変換テーブルが必要であることに注意してください(1>のBはA<-Bと同じではありません)。
A collection of "standard" character sets will be addressed initially (EBCDIC, ASC117, ASCII8, BCD, etc.) and at least NVT. As new requirements are defined these will be added to a library which will then be available to subsequent users.
文字集合が初めは扱われる「標準(EBCDIC、ASC117、ASCII8、BCDなど)」と少なくともNVTの収集。 新しい要件が定義されるとき、これらはその時その後のユーザにとって利用可能になるライブラリに追加されるでしょう。
***WORKING DOCUMENT***
***働くドキュメント***
37
37
RFC 705 Front-End Protocol
RFC705フロントエンドプロトコル
***WORKING DOCUMENT***
***働くドキュメント***
APPENDIX D
付録D
Host Implementations
ホスト導入
To be written at a later date.
より後日書かれるために。
***WORKING DOCUMENT***
***働くドキュメント***
38
38
一覧
スポンサーリンク
