RFC929 日本語訳
0929 Proposed Host-Front End Protocol. J. Lilienkamp, R. Mandell, M.A.Padlipsky. December 1984. (Format: TXT=135042 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Joel Lilienkamp (SDC)
Request for Comments: 929 Richard Mandell (SDC)
Michael Padlipsky (Mitre Corp.)
December 1984
ネットワークワーキンググループジョエルLilienkamp(SDC)はコメントのために以下を要求します。 929 リチャード・マンデル(SDC)マイケルPadlipsky(斜め継ぎ社) 1984年12月
PROPOSED HOST-FRONT END PROTOCOL
提案されたホストフロントエンドプロトコル
Status Of This Memo
このメモの状態
The reader should be aware of several things in regard to what the present document is up to. First and foremost, IT IS A PROPOSAL FOR A STANDARD, NOT A STANDARD ITSELF. Next, it assumes that the separate document, RFC 928, which is an introduction to the present document, has been read before it is. Next, it should be understood that "final cut" over this version of the document has been exercised by the author of RFC 928, not by the primary author of the present document, so any readers bothered by style considerations should feel free to blame the former, who's used to it, rather than the latter, who may well be guiltless. (Editing at a distance finally become too hard to manage, so if I'm typing it myself I'm going to fiddle with it myself too, including, but not limited to, sticking my own section on the Conceptual Model in before Joel's words start, rather than leaving it in the Introduction. MAP)
読者は現在のドキュメントがあることに関して数個のものを意識しているべきです。 まず第一に、ITはA STANDARD ITSELFではなく、A PROPOSAL FOR A STANDARDです。 次に、仮定する前にそれは、別々のドキュメント(現在のドキュメントへの序論であるRFC928)が読まれたと仮定します。 次にドキュメントのこのバージョンの上の「最終的なカット」が現在のドキュメントの第一の作者ではなく、RFC928の作者によって運動させられたのが理解されるべきであるので、スタイル問題によって苦しめられたどんな読者も遠慮なく前者を非難するべきです。(前者は、後者よりむしろそれに使用して、たぶん無実でしょう)。 (離れたまま編集して、自分でそれをタイプしているなら私が自分でまた、それをいじくるつもりであるように、最終的に管理できないくらい困難になってください、含んでいます、他、ジョエルの言葉がIntroductionにそれを残すよりむしろ始まる前にConceptual Modelの上の私自身のセクションにはまり込んで。 地図)
Finally, it should be noted that this is not a finished document. That is, the intent is eventually to supply appendices for all of the protocol offloadings, describing their uses of protocol idiosyncratic parameters and even their interpretations of the standard per-command parameters, but in order to get what we've got into circulation we haven't waited until all such appendices have been written up. (We do have notes on how to handle FTP, e.g., and UDP will be pretty straightforward, but getting them ready would have delayed things into still another calendar year, which would have been very annoying ... not to say embarrassing.) For that matter, it's not even a finished document with respect to what is here. Not only is it our stated intention to revise the protocol based upon implementation experience gained from volunteer test implementations, but it's also the case that it hasn't proven feasible to iron out all known wrinkles in what is being presented. For example, the response codes almost certainly need clarification and expansion, and at least one of us doesn't think mandatory initial parameters need control flags. However, to try too hard for polish would be to stay in subcommittee for the better part of forever, so what you see is what we've got, but certainly isn't meant to be what you or we are stuck with.
最終的に、これが完成ドキュメントでないことに注意されるべきです。 しかし、彼らのプロトコルの特有のパラメタの用途と彼らの1コマンドあたりの標準のパラメタの解釈さえ説明して、結局、プロトコルoffloadingsのすべてのための供給付録にはすなわち、意図が、そのようなすべての付録が詳しく書かれるまで私たちが待っていない流通に得たものを得るためにあります。 (私たちには、例えばどうFTPを扱うかに関する注があって、UDPはかなり簡単になるでしょうが、それらを用意すると、ものはまだ別の暦年まで遅れたでしょう。)(暦年は当惑させとは言わないまでも非常に煩わしかったでしょう)。 さらに言えば、それはここにあるものに関する完成ドキュメントになりさえしません。 また、それがボランティアテスト実現から行われた実現経験に基づくプロトコルを改訂するという私たちの述べられた意志だけであるのではなく、提示されていることにおけるすべての知られているしわを解決するのが可能であると判明しなかったのは、事実です。 少なくとも私たちのひとりは義務的な初期値パラメタが指揮旗を必要とすると考えません例えば、応答コードはほぼ確実に明確化と拡大が必要があります、そして、。 しかしながら、つや出しのためにあまりに一生懸命試みるのは小委員会でいつまでもの大部分に滞在することになっているでしょう、あなたがわかることが、私たちが持っているものですが、したがって、確かに、あなたか私たちが何で刺されるかということであることは意味されません。
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。
Lilienkamp & Mandell & Padlipsky [Page 1]
Lilienkamp、マンデル、およびPadlipsky[1ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
Conceptual Model
概念モデル
There are two fundamental motivations for doing outboard processing. One is to conserve the Hosts' resources (CPU cycles and memory) in a resource sharing intercomputer network, by offloading as much of the required networking software from the Hosts to Outboard Processing Environments (or "Network Front-Ends") as possible. The other is to facilitate procurement of implementations of the various intercomputer networking protocols for the several types of Host in play in a typical heterogeneous intercomputer network, by employing common implementations in the OPE. A third motivation, of basing a network security approach on trusted mandatory OPEs, will not be dealt with here, but is at least worthy of mention.
船外の処理をすることに関する2つの基本的な動機があります。 ものはリソース・シェアリングintercomputerネットワークでHostsの資源(CPUサイクルとメモリ)を節約することになっています、できるだけ多くのHostsからOutboard Processing Environments(または、「ネットワークフロントエンド」)までの必要なネットワークソフトウェアを積み下ろすことによって。 もう片方はプレーのHostのいくつかのタイプのために典型的な種々雑多なintercomputerネットワークで様々なintercomputerネットワーク・プロトコルの実現の調達を容易にすることです、OPEで一般的な実現を使うことによって。 ネットワークセキュリティアプローチを信じられた義務的なOPEsに基礎づける3番目の動機は、ここで対処されませんが、言及に少なくともふさわしいです。
Neither motivation should be allowed to detract from the underlying, assumed desire to perform true intercomputer networking, however. Therefore, it is further assumed that OPEs will be attached to Hosts via a flexible attachment strategy, as described in [1]. That is, at the software level an explicit Host-Front End Protocol (H-FP) will be employed between Hosts and OPEs, rather than having OPEs emulate devices or device controllers already "known" to Host operating systems (in order to avoid introducing new code into the Host).
どちらの動機でしかしながら、正しいintercomputerネットワークを実行する基本的で、想定された願望を損なわれることができるべきです。したがって、OPEsがフレキシブルな付属戦略でHostsに取り付けられるとさらに思われます、[1]で説明されるように。 すなわち、ソフトウェアレベルでは、明白なHost-前部Endプロトコル(H-FP)はOPEsに既にHostオペレーティングシステムに「知られていた」装置か装置コントローラを見習わせるよりHostsとOPEsの間でむしろ使われるでしょう(Hostに新法を紹介するのを避けるために)。
For reasons discussed in the Introduction, an H-FP resolves into three layers. The Link layer enables the exchange of bits between Host and OPE. The Channel layer enables the bit streams to be demultiplexed and flow controlled (both the Channel and Link layers may use preexisting per-Host mechanizations, it should be recalled). The Command (or "Service Access") layer is our primary concern at present. It serves as the distributed processing mechanism which allows processes on Hosts to manipulate protocol interpreters (PIs) in OPEs on their behalf; for convenience, it will be referred to as "the H-FP" here. (It should be noted that the Link and Channel layers may be viewed as roughly equivalent to the inboard processing investment for a Host-comm subnet processor PI and device driver, so in practical terms the savings of resources achieved by outboard processing come from making the H-FP "smaller" than the inboard implementations of the protocols it allows to be offloaded.)
Introductionで議論した理由で、H-FPは3つの層に変えます。 Link層はHostとOPEの間のビットの交換を可能にします。 英仏海峡層は、ビットストリームが反多重送信されるのを可能にします、そして、流れは制御されました(英仏海峡とLink層の両方が1ホストあたりの先在の機械化を使用するかもしれなくて、それは思い出されるべきです)。 現在のところ、Command(または、「サービスアクセス」)層は私たちの第一の関心です。 それはOPEsで彼らに代わってプロトコルインタプリタ(PIs)を操るためにHostsに過程を許容する分散処理メカニズムとして機能します。 便利において、それはここに「H-fp」と呼ばれるでしょう。 (実際的な言い方をするなら船外の処理で達成されたリソースの貯蓄がH-FPを「それが積み下ろされるのを許容するプロトコルの機内の実現より小さく」するのから来て、LinkとChannel層がおよそHost-commサブネットプロセッサPIのための機内の処理投資とデバイスドライバに同じくらい同等な状態で見られるかもしれないことに注意されるべきです。)
The crucial property of the H-FP conceptually is that it stands as the interface between a (Host) process and a PI (which is actually outboard). Usually, the model is that of a closed subroutine interface, although in some cases an interprocess communication mechanism model must be appealed to. That is, the interactions between cooperating H-FP PIs in some sense mimic subroutine or IPC calls, from the perspective of Host processes calling upon their own H-FP PIs, which in turn are of course interfacing via just such
H-FPの重要な特性は概念的に(ホスト)の過程とPI(実際に船外である)とのインタフェースの候補に立つということです。 通常、モデルは閉じたサブルーチンインタフェースのものです、いくつかの場合プロセス間通信メカニズムモデルを求めなければなりませんが。 すなわち、何らかの意味における協力H-FP PIsの間の相互作用がサブルーチンをまねるか、またはIPCは呼びます、もちろんまさしくそのようなものを通して順番に連結しているそれら自身のH-FP PIsを訪問するHostの過程の見解から
Lilienkamp & Mandell & Padlipsky [Page 2]
Lilienkamp、マンデル、およびPadlipsky[2ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
mechanisms themselves. Another way of putting it is that "if the protocols were inboard," the processes invoking H-FP wouldn't know the difference. H-FP, then, may be viewed as a roundabout way of letting Host processes "get at" various PIs.
メカニズム自体。 それを置く別の方法は「プロトコルが内側にあった」なら、H-FPを呼び出す過程が違いを知らないだろうということです。 そして、H-FPはHostの過程に様々なPIsを「達する」にさせるのである回りくどい方法として見なされるかもしれません。
Naturally, the mechanization of the desired concept cannot be particularly literal. After all, the Hosts and the OPEs are different processors, so we're not envisioning a passing through of parameters in an exact fashion. However, in broad terms the model is just that of a somewhat funny interface between a process and a PI. (This should not be construed as ruling out the occurrence of events which prompt the OPE to initiate an exchange of commands with the Host, though; see the Introduction for more on the topic of "Symmetric Begins.")
当然、必要な概念の機械化は特に文字通りであるはずがありません。 結局、HostsとOPEsが異なったプロセッサであるので、私たちは正確なファッションによるパラメタを通すことを思い描いていません。 しかしながら、大きく見るとモデルはただ過程とPIとのいくらかおかしいインタフェースのものです。 (もっとも、OPEがHostとのコマンドの交換を起こすようにうながす出来事の発生を除外するのにこれを理解するべきではありません; 詳しい情報については、話題に関してIntroductionを見てください、「左右対称である、始まり、」、)。
Interaction Discipline
相互作用規律
The interaction between the Host and the OPE must be capable of providing a suitable interface between processes (or protocol interpreters) in the Host and the off-loaded protocol interpreters in the OPE. This interaction must not, however, burden the Host more heavily than would have resulted from supporting the protocols inboard, lest the advantage of using an OPE be overridden.
HostとOPEとの相互作用はOPEで過程(または、プロトコルインタプリタ)の間の適当なインタフェースをHostと積み下ろされたプロトコルインタプリタに供給できなければなりません。 しかしながら、この相互作用は内側にプロトコルをサポートするのからなっただろうより大いにHostを負ってはいけません、OPEを使用する利点がくつがえされるといけないので。
Channel Level Interaction
チャンネルレベル相互作用
As stated elsewhere, the Channel level protocol (implicitly in conjunction with the Link level) provides two major functions. These are demultiplexing the traffic from the Link level into distinct data streams, and providing flow control between the Host and the OPE on a per stream basis. These hold even if the Host-OPE attachment is DMA.
に関連して別記のとおり英仏海峡レベルプロトコル、(それとなく、Linkレベル) 2つの主要な機能を提供します。 これらは、異なったデータへのLinkレベルからの交通が流す逆多重化と、流れの基礎あたりのaのHostとOPEの間にフロー制御を供給することです。 これらはHost-OPE付属がDMAであっても成立します。
The data streams between the Host and the OPE are bidirectional. In this document, the basic unit of data transferred by the Channel level is referred to as a "chunk". The primary motivation for this terminology is that the H-FP permits the Channel level to be one of several possible protocols, each with its own terminology. For example, a chunk on an X.25 Channel would be a packet, while a chunk on the DTI H-FP channel would be a message. While the Command level is, in a sense, "more efficient" when the chunk size is permitted to be large, the flexibility permitted in the choice of protocols at the Channel level precludes any assumptions about the chunk size.
HostとOPEの間のデータ・ストリームは双方向です。 本書では、英仏海峡レベルによって移されたデータの原単位は「塊」と呼ばれます。 この用語に関する第一の動機はH-FPが、英仏海峡レベルがいくつかの可能なプロトコルの1つであることを可能にするということです、それぞれそれ自身の用語で。 例えば、X.25 Channelの上の塊はパケットでしょう、DTI H-FPチャンネルの上の塊がメッセージでしょうが。 塊サイズが大きいことが許可されているとき、Commandレベルはある意味で「より効率的です」が、プロトコルの選択で英仏海峡レベルで受入れられた柔軟性は塊サイズに関するどんな仮定も排除します。
Each data stream is fully asynchronous. A Channel protocol user can send data at any time, once the channel has been properly opened. (The Command level's logic may render some actions meaningless, however.) The data transfer service provided by the Channel protocol
それぞれのデータ・ストリームは完全に非同期です。 チャンネルがいったん適切に開けられると、Channelプロトコルユーザはいつでも、データを送ることができます。 (しかしながら、Commandレベルの論理はいくつかの動作を無意味にするかもしれません。) 英仏海峡プロトコルによって提供されたデータ転送サービス
Lilienkamp & Mandell & Padlipsky [Page 3]
Lilienkamp、マンデル、およびPadlipsky[3ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
is reliable; this entails delivery in the correct order, without duplication, and checked for bit errors. All retransmission, error checking, and duplicate detection is provided by this protocol in a way that is transparent to the user. (If the attachment is DMA, stream identification and chunk length must still be provided for.)
信頼できます。 これは、複製なしで正しいオーダーにおける配送を伴って、噛み付いている誤りがないかどうかチェックしました。 このプロトコルはユーザにとって、見え透いた方法ですべての「再-トランスミッション」、誤りの照合、および写し検出を提供します。 (付属がDMAであるなら、まだ流れの識別と塊の長さに備えなければなりません。)
The flow control at the Channel level is provided to prevent the OPE and the Host from overloading each other's resources by excessive transmissions. In general, this flow control should not directly affect the outboard protocol interpreters' operation. On the other had, this flow control has the same effect as explicit interface events that provide flow control between the user and the protocol interpreter (e.g., the Allocate event of the interface specification for TCP found in MIL-STD 1778). Hence, such events do not need to be communicated explicitly at the Command level. (If the attachment is DMA, flow control must still be provided for.)
OPEとHostが過度のトランスミッションで互いのリソースを積みすぎるのを防ぐために英仏海峡レベルにおけるフロー制御を提供します。 一般に、このフロー制御は直接船外のプロトコルインタプリタの操作に影響するべきではありません。 オンである、もう片方が持っていた、このフロー制御には、ユーザとプロトコルインタプリタ(例えば、軍規格1778で見つけられたTCPのためのインターフェース仕様のAllocate出来事)の間にフロー制御を提供する明白なインタフェース出来事と同じ効果があります。 したがって、そのような出来事はCommandレベルで明らかにコミュニケートする必要はありません。 (付属がDMAであるなら、まだフロー制御に備えなければなりません。)
Should Hosts require an OPE to be attached via a Link Level that furnishes physical demultiplexing (e.g., a group of RS232 ports), any attempt to avoid furnishing reliability and explicit flow control, is done at their peril; we have not chosen to assist such an enterprise, but neither have we precluded it. (It would certainly violate the spirit of the thing, however.)
Hostsが、OPEが物理的な逆多重化を提供するLink Levelを通して取り付けられるのを必要とするなら、あえて危険を冒しても、(例えば、RS232ポートのグループ)(供給の信頼性と明白なフロー制御を避けるどんな試み)をします。 そのような企業を補助するのを選んでいませんが、どちらも、私たちはそれを排除していません。 (しかしながら、確かに、それはものの精神に違反するでしょう。)
Command Level Interaction
平らな相互作用を命令してください。
The approach chosen for this H-FP is to base the interaction on a small set of commands, separately applicable to a given Channel Level channel. The commands are simple, but sufficiently flexible to permit the off-loading of the interpreters of the large number of protocols at various levels in the hierarchy. This flexibility is made possible in part by the similar nature of the interfaces to most protocols, combined with the provision of "protocol idiosyncratic parameters". These parameters are defined for each offloaded protocol interpreter in the OPE. The use of such parameters does not complicate the basic design of the OPE, since it must be customized for each off-loaded protocol anyway, and all that is required of the OPE for those parameters is to pass them to the off-loaded protocol interpreter. Hence, an interface tailored to a particular protocol can be created in a straightforward and cost-effective way.
このH-FPに選ばれたアプローチは別々に相互作用を小さいコマンドに与えられたChannel Levelチャンネルに適切な状態で基礎づけることです。 コマンドは、簡単ですが、様々なレベルで多くのプロトコルのインタプリタの陸揚を階層構造で可能にするのにおいて十分フレキシブルです。 「プロトコルの特有のパラメタ」の支給に結合されたほとんどのプロトコルへのインタフェースの同様の自然はこの柔軟性を可能に一部します。 これらのパラメタはOPEのそれぞれの積み下ろされたプロトコルインタプリタのために定義されます。 そのようなパラメタの使用はOPEの基本的なデザインを複雑にしません、OPEがそれらのパラメタのために要求されるすべてがそれぞれの積み下ろされたプロトコルのためにとにかくそれをカスタム設計しなければならなくて、積み下ろされたプロトコルインタプリタにそれらを渡すことであるので。 したがって、簡単で費用対効果に優れた方法で特定のプロトコルに適合したインタフェースは作成できます。
The command dialog is more or less asynchronous. Commands can be issued at any particular time (except when there is a pending command, which will be discussed below), and there is no need for dummy traffic on a channel when no commands are issued.
コマンド対話は多少非同期です。 特定の何時(以下で議論する未定のコマンドがある時を除いた)でもコマンドを発行できます、そして、コマンドを全く発行しないとき、チャンネルにおけるダミーの交通の必要は全くありません。
Associated with each command is a response. The purpose of this
各コマンドに関連づけられているのは、応答です。 この目的
Lilienkamp & Mandell & Padlipsky [Page 4]
Lilienkamp、マンデル、およびPadlipsky[4ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
response is to indicate, at some level that depends in part on the particular protocol interpreter that is offloaded to the OPE, whether the command was successfully executed, and if unsuccessful, the reason. Often, generating the response involves interaction with the protocol interpreter before a response can be generated.
応答はOPEへ積み下ろされる特定のプロトコルインタプリタの上に何らかのレベルで場合によりけりですを一部示すことです、コマンドが首尾よく実行されて、失敗しているなら、理由。 応答を発生させると、応答が発生できる前にしばしば、プロトコルインタプリタとの相互作用はかかわります。
When a command is issued, the issuer must wait for a response before another command is issued. The nature of the communication between the Host and the OPE is thus a lock step command/response dialog. There are two major exceptions to this principle, however. One exception is the abrupt form of the End command, which can be issued at any time to cancel any previously issued commands, and indicate that services are no longer desired. The other exception is the Signal command. Since a Signal is out-of-band and usually of high importance, forcing it to wait on a response would be undesirable. Hence, a Signal command can be issued while commands (other than Signal) are pending. However, a Signal command should not be issued before a successful response to the Begin command has been received. Since it is possible for more than one command of different types to be pending at one time, a mechanism to distinguish responses is needed. Since there are never two commands of the same type pending, including the command name in the response is sufficient to make this distinction.
コマンドを発行するとき、別のコマンドを発行する前に発行人は応答を待たなければなりません。 その結果、HostとOPEとのコミュニケーションの本質はロックステップコマンド/応答対話です。 しかしながら、この原則への2つの主要な例外があります。1つの例外がEndコマンドの突然のフォームです。(いつでも、どんな以前に発行されたコマンドも中止して、サービスがもう望まれていないのを示すためにそれを発行できます)。 もう片方の例外はSignalコマンドです。 以来、バンドの外でSignalはそうです、そして、通常、高い重要性では、応答で待たせているのは望ましくないでしょう。 したがって、コマンド(Signalを除いた)が未定である間、Signalコマンドを発行できます。 しかしながら、Beginコマンドへのうまくいっている応答を受ける前にSignalコマンドを発行するべきではありません。 1つ以上のコマンドに、異なったタイプがひところ未定であるために可能であるので、応答を区別するメカニズムが必要です。 同じタイプの未定の2つのコマンドが決してないので、応答にコマンド名を含んでいるのはこの区別をするように十分です。
A special case command is the Transmit command. Details of the Transmit command are provided in the next section. Essentially, the Transmit command is used to invoke the data transfer services of the off-loaded protocol (when issued by the Host) or to indicate the arrival of new data from the network (when issued by the OPE). The nature of specific protocol interfaces for these events varies widely between protocols. Some may block until the data is accepted by the remote counterpart (or "peer") protocol interpreter, while others may not. Hence, there is a special parameter which indicates the nature of the Transmit command interface. It can either require that the response should be generated immediately after determining the Transmit command is complete and formed properly, or can indicate that the response should not be generated until the appropriate interface event is given by the remote protocol interpreter. The default action for all Transmit commands can be initialized using the Begin command and changed using the Condition command. Also, the default action can be temporarily overridden by specifying a parameter with the Transmit command. The net result of this mechanism is to allow the Host to determine within reason just how lock-stepped transmissions are to be. (It is assumed that the usual case will be to transfer the burden of buffering to the OPE by taking immediate responses, provided that doing so "makes sense" with the particular offloaded protocol in play.)
特別なケースコマンドはTransmitコマンドです。 Transmitコマンドの詳細は次のセクションに明らかにされます。 本質的には、Transmitコマンドは、積み下ろされたプロトコル(Hostによって発行されると)のデータ転送サービスを呼び出すか、またはネットワークからの新しいデータの到着を示すのに使用されます(OPEによって発行されると)。 これらのイベントのための特定のプロトコルインタフェースの自然はプロトコルの間でばらつきが大きいです。 データがリモート対応者(「じっと見る」)プロトコルインタプリタによって受け入れられるまで、或るものは立ち塞がるかもしれませんが、他のものはそうしないかもしれません。 したがって、Transmitコマンドインタフェースの自然を示す特別なパラメタがあります。 それは、応答がTransmitコマンドが完全であることを決定する直後生成されて、適切に形成されるべきであるのが必要であることができる、または適切なインタフェースイベントがリモートプロトコルインタプリタによって与えられるまで応答が生成されるべきでないのを示すことができます。 Conditionコマンドを使用することですべてのTransmitコマンドのためのデフォルト動作をBeginコマンドを使用することで初期化して、変えることができます。 また、Transmitコマンドでパラメタを指定することによって、一時デフォルト動作をくつがえすことができます。 このメカニズムの結果が理由の中でトランスミッションが錠によっていったいどれくらい踏まれるかを決定するHostは許容することになっているネット。 (普通のケースが即時型反応を取ることによってOPEへのバッファリングの負担を移すことであると思われます、特定の積み下ろされたプロトコルがプレーにある状態でそうするのが「理解できれ」ば。)
Lilienkamp & Mandell & Padlipsky [Page 5]
Lilienkamp、マンデル、およびPadlipsky[5ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
Some protocols provide a block-oriented data transfer service rather than a stream-oriented one. With such a service, the data associated with a transfer request is viewed as an integral unit. For actual network transmission, the protocol may permit these units to be grouped or fragmented. However, the receiving end must deliver the data in the original, integral units. Protocols that conform to this model include some datagram protocols such as IP and UDP, and also some connection protocols such as NBS TP.
いくつかのプロトコルがストリーム指向のものよりむしろブロック指向のデータ転送サービスを提供します。 そのようなサービスで、転送要求に関連しているデータは不可欠のユニットとして見なされます。 実際のネットワーク送信のために、プロトコルは、これらのユニットが分類されるか、または断片化されることを許可するかもしれません。 しかしながら、犠牲者はオリジナルの、そして、不可欠のユニットのデータを提供しなければなりません。 このモデルに従うプロトコルは、IPやUDPなどのいくつかのデータグラムプロトコルを含んでいて、また、NBS TPなどのいくつかの接続プロトコルを含んでいます。
To cater to these types of protocols, it is a convention that commands, their parameters, and any associated data be transferred between the Host and the OPE in a single chunk. Any data associated with an H-FP command is viewed as an integral unit which is used in the corresponding service request given to the outboard protocol interpreter or delivered as a complete unit to the process in the Host. Operation of stream-oriented protocols such as TCP will not be adversely affected by this convention.
これらのタイプのプロトコルに満たすために、ただ一つの塊でコマンド、それらのパラメタ、およびどんな関連データもHostとOPEの間に移すのは、コンベンションです。 対応するサービスのリクエストで使用される不可欠のユニットがHostのプロセスへの完成品一式として船外のプロトコルインタプリタに与えたか、または配送されたので、H-FPコマンドに関連しているどんなデータも見られます。 このコンベンションはTCPなどのストリーム指向のプロトコルの操作を悪影響を受けさせないでしょう。
To accommodate Channel protocols that do not provide for arbitrarily large chunks, a mechanism at the Command level is required to permit the linking of multiple chunks into a single command, in order to transfer the burden of buffering as much as possible from the Host to the OPE. The facility proposed here would consist of an indication at the beginning of each chunk which would distinguish integral commands, fragments of a command for which more fragments are yet to arrive, and the final fragment of a command. The details of this mechanism are discussed in the section on the syntax of commands and responses.
Commandレベルにおけるメカニズムが複数の塊のリンクをただ一つのコマンドに可能にするのに必要です、任意に大きい塊に備えないChannelプロトコルに対応するならバッファリングの負担をできるだけHostからOPEまで移すために。 ここで提案された施設は不可欠のコマンドを区別するそれぞれの塊の始まり、まだ到着していないより多くの断片がことであるコマンドの断片、およびコマンドの最終的な断片で指示から成るでしょう。 コマンドと応答の構文のセクションでこのメカニズムの細部について議論します。
It is a convention for this H-FP that any data associated with a command must start on a word boundary (as defined by the local system). Consequently, there is a need to provide padding within the commands. Such padding is used only to fill to the next appropriate boundary, and has no semantic significance to the command interpreter (i.e., two commands that are identical except for the amount of padding should behave identically). The details of this padding are discussed in the section on the syntax of commands and responses.
どんなデータもコマンドに関連づけたこのH-FPのためのコンベンションが語境界を始めなければならないという(ローカルシステムによって定義されるように)ことです。 その結果、提供するコマンドの中でそっと歩く必要があります。 そのような詰め物は、使用されますが、次の適切な境界にいっぱいになって、どんな意味意味もコマンドインタープリタに持っていません(すなわち、2つの詰め物の量以外に、同じコマンドが同様に振る舞うべきです)。 コマンドと応答の構文のセクションでこの詰め物の詳細について議論します。
Lilienkamp & Mandell & Padlipsky [Page 6]
Lilienkamp、マンデル、およびPadlipsky[6ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
Syntax Rules
シンタックス・ルール
At the Command Level, communication between the Host and the OPE takes the form of commands and responses. A command is a request for some particular action, and the response indicates the success or failure of performing the requested action.
Command Levelでは、HostとOPEとのコミュニケーションはコマンドと応答の形を取ります。 何らかの特定の動作を求めてコマンドは要求です、そして、応答は要求された動作を実行する成否を示します。
All commands and responses are coded in ASCII characters. (Nothing precludes OPEs from accepting EBCDIC from Hosts that use it in native mode, but that is not required.) These characters are sent in some way convenient for the Host, and the OPE is sufficiently flexible to interpret them. (i.e., OPEs are expected to accommodate Host idiosyncracies in regard to such things as use of 7-bit ASCII in a 9-bit field.) This approach offers several advantages:
すべてのコマンドと応答はASCII文字でコード化されます。 (何もネイティブモードにそれを使用しますが、必要でないHostsからEBCDICを受け入れるので、OPEsを排除しません。) Hostに、便利な何らかの方法でこれらのキャラクタを送ります、そして、OPEは彼らを解釈するのにおいて十分フレキシブルです。 (すなわち、OPEsが9ビットの分野での7ビットのASCIIの使用のようなものにHost特異性を収容すると予想されます。) このアプローチはいくつかの利点を示します:
Adaptabilities in most Hosts: Most Hosts have the ability to generate and interpret ASCII character streams. Hence, integrating H-FP into a Host will not require difficult software.
ほとんどのホストの適応性: ほとんどのHostsには、ASCII文字ストリームを生成して、解釈する能力があります。したがって、H-FPをHostと統合するのは難しいソフトウェアを必要としないでしょう。
Script generation: Generation of test and operational command scripts will be simplified, since they will not need to contain special characters.
スクリプト世代: 特殊文字を含む必要はないので、テストと操作上のコマンドスクリプトの世代は簡素化されるでしょう。
Terminal Operation: Using simple command streams simplifies the conversion of an OPE to a generic virtual terminal support machine. This is particularly useful during development and testing.
端末の操作: 簡単なコマンドストリームを使用すると、OPEの変換はジェネリック仮想端末サポートマシンに簡略化します。 これは開発とテストの間、特に役に立ちます。
Testing: Testing will not require special hardware to interpret commands and responses. A terminal or data line analyzer would be adequate.
テストします: テストは、コマンドと応答を解釈するために特別なハードウェアを必要としないでしょう。 端末かデータライン分析器が適切でしょう。
The specific format for the commands and responses will be discussed in the sections that follow. In those sections, the quote character is used to indicate strings. The symbols "<" and ">" (referred to as angle brackets) are used as meta-characters.
従うセクションでコマンドと応答のための特定の形式について議論するでしょう。 それらのセクションでは、引用文字は、ストリングを示すのに使用されます。 シンボルの"<"と">"(角ブラケットと呼ばれる)はメタ文字として使用されます。
Syntax of Commands
コマンドの構文
As alluded to in the section discussing the interaction discipline between the Host and the OPE, a function is provided by which a chunk can be used to carry either a complete command or a fragment of a command. The mechanism chosen to provide this function entails use of the first character position in the chunk as a chunk usage identifier. The character "C" in the first position indicates a chunk containing a single, complete command. "F" in the first position indicates a chunk which is the first part of a multichunk command. "M" in the first position indicates the chunk is a middle
HostとOPEの間の相互作用規律について論ずるセクションで暗示されるように、コマンドの完全なコマンドか断片のどちらかを運ぶのに塊を使用できる機能を提供します。 この機能を提供するために選ばれたメカニズムは塊用法識別子として塊における最初の欄の使用を伴います。 第1ポジションのキャラクタ「C」は単一の、そして、完全なコマンドを含む塊を示します。 第1ポジションの「F」は「マルチ-塊」コマンドの最初の部分である塊を示します。 第1ポジションの「M」は、塊が中央であることを示します。
Lilienkamp & Mandell & Padlipsky [Page 7]
Lilienkamp、マンデル、およびPadlipsky[7ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
part (neither the first nor the last chunk) of a command. Finally, "L" indicates the chunk is the last chunk of a multi-chunk command. Hence, the following sequences of chunks (the letter corresponds to the chunk usage identifier in each chunk, and the angle brackets enclose a chunk) are legal:
コマンドの一部(どちらも1番目か最後の塊)。 最終的に、「L」は、塊がマルチ塊コマンドの最後の塊であることを示します。 したがって、塊(手紙は各塊における塊用法識別子に一致しています、そして、角ブラケットは塊を同封する)の以下の系列は法的です:
<C>
<F><L>
<F><M><M><L>
<C><F><L><F><M><M><L>。
while the following are not legal:
以下は法的ではありませんが:
<L>
<M><L>
<F><C>
<L><M><L><F><C>。
Tactics for handling multiple chunks with regard to OPE buffering limits are left to the ingenuity of OPE builders. The spirit is to take as much as you can, in order to relieve the Host of the necessity of buffering itself.
限界をバッファリングするOPEに関して複数の塊を扱うための戦術はOPEビルダーの巧みさに残されます。 精神はあなたが取ることができるくらい取ることになっています、それ自体をバッファリングするという必要性をHostに取り除くために。
A command always begins immediately following the indicator character, with possible intervening spaces. This implies a chunk can contain at most one complete command. The end of the command (not including the data) is signified by a newline (denoted as <nl> in this document) that does not appear inside a quoted string (see below). The end of the data is designated by the end of the last chunk.
コマンドはすぐに、いつも可能な介入している空間でインディケータキャラクタに続き始めます。 これは、塊が最も1つに完全なコマンドを含むことができるのを含意します。 引用文字列に現れないニューライン(<nl>として、本書では指示される)によってコマンド(データを含んでいない)の終わりは意味されています(以下を見てください)。 データの終わりは最後の塊の終わりまでに指定されます。
Commands take the form of an ASCII string. The command identifier is the first word of the chunk. It consists of at least the first two letters of the command, in either upper or lower case (e.g., the sequences "BE", "Be", "bE", and "be" all identify the Begin command). Additional letters of the command name can be included if desired to aid readability of the command stream.
コマンドはASCIIストリングの形を取ります。 コマンド識別子は塊の最初の単語です。 それは少なくとも上側のコマンドの最初の2個の手紙か小文字から成ります(例えば、系列「いてください」、「いてください」、「いてください」、および「いる」はすべて、始まりコマンドを特定します)。 コマンドストリームの読み易さを支援することが望まれているなら、コマンド名の追加手紙を含むことができます。
Following the command identifier is a list of parameters. These parameters are also represented as ASCII strings, although the specific format will depend on the particular parameter. The data to be transmitted is not considered a control parameter, however, and need not be ASCII data.
コマンド識別子に従うのは、パラメタのリストです。 特定の形式は特定のパラメタによるでしょうが、また、これらのパラメタはASCIIストリングとして表されます。 伝えられるべきデータは、しかしながら、管理パラメータであることは考えられないで、ASCIIデータである必要はありません。
Parameters are separated by one or more spaces. Tabs, newlines, and other white space are not legal parameter separators.
パラメタは1つ以上の空間によって切り離されます。 タブ、ニューライン、および他の余白は法的なパラメタ分離符ではありません。
Parameter strings may be quoted, using the character <">. Any
キャラクタ<">"を使用して、パラメタストリングは引用されるかもしれません。 いくらか
Lilienkamp & Mandell & Padlipsky [Page 8]
Lilienkamp、マンデル、およびPadlipsky[8ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
characters between the <"> characters are a part of the parameter, including spaces and newlines. The character <"> that is part of the parameter is represented inside a quoted string as <"">.
キャラクタ、<の間では、「>キャラクタは空間とニューラインを含むパラメタのa部分です」。 キャラクタ<「パラメタの一部である>は<として引用文字列で表される」">"。
The order in which the parameters appear within the command is significant to their interpretation by the Host and by the OPE. Optional parameters may be skipped by using the characters ",," to indicate a NULL parameter. Such a NULL parameter takes its default value. Alternatively, each parameter has a MULTICS/UNIX style Control Argument/Flag associated with it that can be used to identify the parameter, without placing NULL parameters for each parameter skipped. This flag consists of one or two ASCII characters, and either upper or lower case may be used. For example, if the fourth parameter of a command had a flag of "-p" and the user wished the first three parameters to be null, he could use:
パラメタがコマンドの中に現れるオーダーはHostとOPEによる彼らの解釈に重要です。 「任意のパラメタはキャラクタを使用することによって、スキップされるかもしれない」、」 ヌルパラメタを示すために。 そのようなNULLパラメタはデフォルト値を取ります。 あるいはまた、各パラメタには、パラメタを特定するのに使用できるそれに関連しているMULTICS/UNIXスタイルControl Argument/旗があります、各パラメタのためのパラメタがスキップした置くNULLなしで。 この旗は1か2人のASCII文字から成ります、そして、上側の、または、低いケースは使用されるかもしれません。 例えば、ヌルであるためにコマンドの4番目のパラメタで最初の3つのパラメタであることを"-p"とユーザの旗を願っているなら、彼は以下を使用できるでしょうに。
command -p value
コマンド-p価値
or
または
command -P value
コマンド-P価値
instead of
instead of
command ,, ,, ,, value
命令してください、値
if it were more convenient for the Host to do so. Flagged parameters must still appear in the correct sequence within the command, however.
Hostがそうするようにより都合がよければ。 しかしながら、旗を揚げさせられたパラメタはコマンドの中に正しい系列にまだ現れなければなりません。
There may be data associated with some of the commands. Any such data is placed into the chunk following all the parameters and the unquoted newline. Padding can be provided by placing spaces between the end of the final parameter string and the newline, so that data begins on a word boundary. The OPE will always pad to a host word boundary. Padding by hosts is optional.
コマンドのいくつかに関連しているデータがあるかもしれません。 すべてのパラメタと引用を終わっているニューラインに従って、どんなそのようなデータも塊に置かれます。 最終的なパラメタストリングの端とニューラインの間の空間を置くことによって、詰め物を提供できます、データが語境界で始まるように。 OPEはいつもホスト語境界にそっと歩くでしょう。 ホストでそっと歩くのは任意です。
Syntax of Responses
応答の構文
Responses are actually just a special form of a command. It is
anticipated that all responses would fit into a single channel chunk,
although the mechanisms described for multichunk commands can
certainly be used in responses. The ASCII string used to uniquely
identify the response command is "RE" ("Re", "rE", and "re" are also
permitted).
応答は実際にただコマンドの特別なフォームです。 すべての応答がただ一つのチャンネル塊に収まると予期されます、確かに応答に「マルチ-塊」コマンドのために説明されたメカニズムは使用できますが。 唯一応答命令を特定するのに使用されるASCIIストリングは「re」(また、「re」、「re」、および「re」は受入れられる)です。
After the response command identifier is the original command
応答コマンド識別子がオリジナルのコマンドであった後に
Lilienkamp & Mandell & Padlipsky [Page 9]
Lilienkamp、マンデル、およびPadlipsky[9ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
identifier, so the response can be associated with the proper command. Following this identifier is a three ASCII digit response code, a set of protocol idiosyncratic parameters, and a textual message. The protocol idiosyncratic parameters are used to transfer interface information between the Host and the OPE, and may not be needed when off-loading some protocol interpreters. The textual message is intended for human interpretation of the response codes, and is not required by the protocol. The three digits uniquely identify the semantics of the response, at least within the context of a particular command and particular outboarded protocol interpreter.
適切なコマンドに応答を関連づけることができるように識別子。 この識別子に従うのは、3ASCIIケタ応答コードと、1セットのプロトコルの特有のパラメタと、原文のメッセージです。 プロトコルの特有のパラメタは、HostとOPEの間にインターフェース情報を移すのに使用されて、何人かのプロトコルインタプリタを積み下ろすとき、必要でないかもしれません。 原文のメッセージは、応答コードの人間の解釈のために意図して、プロトコルによって必要とされません。 3ケタは少なくとも特定のコマンドと特定の外到達されたプロトコルインタプリタの文脈の中で唯一応答の意味論を特定します。
Responses are numerically grouped by the type of information they convey. The first digit identifies this group, and the last two digits further qualify the reply. The following list illustrates this grouping.
応答は彼らが伝える情報の種類によって数の上で分類されます。 最初のケタはこのグループを特定します、そして、下2ケタはさらに回答に資格を与えます。 以下のリストはこの組分けを例証します。
0XX Successful: The command was executed successfully. The
response code may contain further information.
0XXうまくいく: コマンドは首尾よく実行されました。 応答コードは詳細を含むかもしれません。
1XX Conditional Success: The command was executed successfully,
but not exactly according to the service and flow control
suggestions. If those suggestions were particularly important
to the requester, he may wish to issue an End command. The
response code contains information on what suggestion or
suggestions could not be followed.
1XXの条件付きの成功: コマンドは、首尾よく実行されましたが、ちょうどサービスとフロー制御提案に従って、実行されたというわけではありません。 それらの提案が特にリクエスタに重要であったなら、彼はEndコマンドを発行したがっているかもしれません。 応答コードはどんな提案か提案に続くことができなかったかの情報を含んでいます。
2XX Command Level Error: An error at the command level has
occurred. This could include requesting services of a
protocol not supported, or a problem in the way those services
were requested. This level does not include problems with the
syntax of the command or its parameters.
2XXは平らな誤りを命令します: コマンドレベルにおける誤りは発生しました。 これはそれらのサービスが要求された方法でプロトコルのサービスがサポートしなかった要求、または問題を含むかもしれません。 このレベルはコマンドかそのパラメタの構文に関する問題を含んでいません。
3XX Syntax and Parameter Errors: An error in the syntax of the
command or a problem with one of its parameters has occurred.
A problem with a parameter may be other than syntactical, such
as illegal address.
3XX構文とパラメタ誤り: コマンドの構文における誤りかパラメタの1つに関する問題が発生しました。 不法なアドレスなどのような構文を除いて、パラメタに関する問題があるかもしれません。
4XX Off-loaded Protocol Interpreter Problems: Some problem with
the particular off-loaded protocol has occurred.
4XXはプロトコルインタプリタ問題を積み下ろしました: 特定の積み下ろされたプロトコルに関する何らかの問題が起こりました。
5XX Local OPE Internal Problems: Problems, such as insufficient
OPE resources, or problems with OPE to subnet interface.
5XXのローカルのOPE内部の問題: 不十分なOPEリソース、またはサブネットへのOPEに関する問題などの問題は連結します。
6XX Security Problem: Some problem with Host, network, or OPE
security has occurred. The response code indicates the
problem.
6XX警備上の問題: Host、ネットワーク、またはOPEセキュリティに関する何らかの問題が起こりました。 応答コードは問題を示します。
Lilienkamp & Mandell & Padlipsky [Page 10]
Lilienkamp、マンデル、およびPadlipsky[10ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
7XX Reserved for Future Expansion
今後の拡張のために予約された7XX
8XX Reserved for Future Expansion
今後の拡張のために予約された8XX
9XX Protocol Idiosyncratic Errors: Some error occurred that is
idiosyncratic to the particular off-loaded protocol being
used. The response code indicates the error.
9XXは特有の誤りについて議定書の中で述べます: 使用される特定の積み下ろされたプロトコルに特有である何らかの誤りが発生しました。 応答コードは誤りを示します。
Description of the Commands
コマンドの記述
As stated above, communication between the Host and the OPE at the Command Level is accomplished using commands and responses. Commands may be issued by either the Host or the OPE, and are used to stimulate activity in the other entity. Some commands may only have a meaningful interpretation in one direction, however. A response indicates that the activity started by the command was completed, and a code indicates success or failure of the command, and perhaps other information related to the command as well.
上に述べられているように、Command LevelのHostとOPEとのコミュニケーションはコマンドと応答を使用するのに優れています。 コマンドは、HostかOPEのどちらかによって発行されるかもしれなくて、もう片方の実体における活動を刺激するのに使用されます。 しかしながら、いくつかのコマンドが重要な解釈を一方向に持っているだけであるかもしれません。応答は、コマンドで始められた活動が終了して、コードがコマンドの成否、および恐らくまた、コマンドに関連する他の情報を示すのを示します。
Associated with each command is a set of parameters. The order in which the parameters appear is significant to the correct operation of the protocols. More information on the syntax of command parameters can be found in the syntax descriptions.
各コマンドに関連づけられているのは、1セットのパラメタです。 パラメタが現れるオーダーはプロトコルの正しい操作に重要です。 構文記述でコマンドパラメタの構文に関する詳しい情報を見つけることができます。
The commands are:
コマンドは以下の通りです。
- Begin: initiate communication between a process in the Host and
an off-loaded protocol interpreter in the OPE. (A Channel level
stream/connection will typically have been opened as a prior step.
All other commands, except No-op, apply to a stream on which a
successful Begin has been done.)
- 始まります: OPEでHostのプロセスと積み下ろされたプロトコルインタプリタとのコミュニケーションを開始してください。 (Channelの平らなストリーム/接続は先のステップとして通常開かれてしまうでしょう。 オプアート以外の他のすべてのコマンドがうまくいっているBeginが行われたストリームに適用されます。)
- Transmit: transmit data between a process in the Host and an
off-loaded protocol interpreter in the OPE.
- 伝えます: HostのプロセスとOPEの積み下ろされたプロトコルインタプリタの間にデータを送ってください。
- Signal: cause an out-of-band signal to be sent by the
off-loaded protocol interpreter to its peer, or indicate the
arrival of such a signal from the remote side.
- 以下に合図してください。 バンドで出ている信号が積み下ろされたプロトコルインタプリタによって同輩に送られることを引き起こすか、または遠隔地側からのそのような信号の到着を示してください。
- Condition: alter the off-loaded protocol interpreter's
operational characteristics.
- 以下を条件とさせてください。 積み下ろされたプロトコルインタプリタの操作上の特性を変更してください。
- Status: transfer status requests or information between a
process in the Host and an off-loaded protocol interpreter in the
OPE.
- 状態: HostのプロセスとOPEの積み下ろされたプロトコルインタプリタの間に状態要求か情報を移してください。
Lilienkamp & Mandell & Padlipsky [Page 11]
Lilienkamp、マンデル、およびPadlipsky[11ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
- End: indicate that services from the off-loaded protocol
interpreter are no longer required, or will no longer be provided.
- 以下を終わらせてください。 積み下ろされたプロトコルインタプリタからのサービスがもう必要でない、またはもう提供されないのを示してください。
- No-op: performs no operation, but facilitates testing.
- オプアートがありません: 操作を全く実行しませんが、テストするのを容易にします。
These commands will be discussed in the following sections. Each of these sections includes a discussion of the purpose of the command, a description of each of the parameters used with the command, a list of responses for the command, an example of the command, and a set of notes for the implementor. (An appendix will eventually be furnished for each protocol offloading, showing the use of its protocol idiosyncratic parameters as well as of the general parameters on a per-command basis. Initially, only representative offloadings will be treated in appendices, with others to be added after the protocol gains acceptance.)
以下のセクションでこれらのコマンドについて議論するでしょう。 それぞれのこれらのセクションは作成者へのコマンドの目的の議論、コマンドと共に使用されるそれぞれのパラメタの記述、コマンドのための応答のリスト、コマンドに関する例、および1セットの注意を含んでいます。 (結局それぞれのプロトコル陸揚のために付録を提供するでしょう、1コマンドあたり1個のベースにおけるパラメタと一般的指標における特有のプロトコルの使用を示して。 初めは、offloadings代表だけが、プロトコルが承認を獲得した後に加えられるために他のものと共に付録で扱われるでしょう。)
Begin
始まってください。
Purpose of the Begin Command
始まりコマンドの目的
The purpose of a Begin command is to initiate communication
between the Host and the OPE on a particular stream or channel
(the channel is opened as a separate step, of course). The
interpretation of the command is somewhat dependent upon
whether it was issued by the Host of the OPE.
Beginコマンドの目的は特定のストリームかチャンネルの上にHostとOPEとのコミュニケーションを開始する(チャンネルが別々のステップとして開けられる、もちろん)ことです。 コマンドの解釈はそれがOPEのHostによって発行されたかどうかにいくらか依存しています。
- If the command was issued by the Host, it means some process
in the Host is requesting services of a protocol that was
off-loaded to the OPE. The user request results in the
establishment of a channel connection between the Host and the
OPE, and a Begin command to the Command interpreter in the OPE.
- コマンドがHostによって発行されたなら、それは、HostのあるプロセスがOPEへ積み下ろされたプロトコルのサービスを要求していることを意味します。 ユーザ要求はHostとOPEの間のチャンネル接続の設立、およびCommandインタプリタへのOPEのBeginコマンドをもたらします。
- If the command was issued by the OPE, it means some protocol
interpreter in the OPE has data for some process in the Host
which is not currently known by the OPE. An example would be
an incoming UDP datagram on a new port, or if no Begin for UDP
had been issued at all by the Host. (An incoming TCP
connection request could be handled by a response to the user's
Passive Open request, which had previously caused a Begin
request from the Host; an incoming TCP connection request to a
port on which no Listen had been issued would cause an OPE
generated Begin, however.)
- コマンドがOPEによって発行されたなら、それは、OPEのプロトコルインタプリタが現在OPEによって知られていないHostに、あるプロセスのためのデータを持っていることを意味します。 例は新しいポートかそれともUDPのためのBeginがHostによって全く発行されていなかったかどうかの入って来るUDPデータグラムでしょう。 (ユーザのPassiveオープン要求への応答で入って来るTCP接続要求を扱うことができるでしょう; Listenが全く発行されていなかったポートへの入って来るTCP接続要求はしかしながら、Beginであると生成されたOPEを引き起こすでしょう。)応答は以前に、HostからのBegin要求を引き起こしました。
As indicated earlier, any particular Host is not required to
support two-way Begins.
より早く示されるように、特定のHostがツーウェイBeginsをサポートしている必要はないいずれでもあります。
Lilienkamp & Mandell & Padlipsky [Page 12]
Lilienkamp、マンデル、およびPadlipsky[12ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
Parameters of the Begin Command
始まりコマンドのパラメタ
The Begin command has several parameters associated with it.
These parameters contain information needed by the offloaded
protocol to provide an adequate level of network service. This
information includes protocol, source and destination
addresses, and also type of service and flow control advice.
These parameters are discussed in detail below.
Beginコマンドには、それに関連しているいくつかのパラメタがあります。 これらのパラメタは適切なレベルのネットワーク・サービスを提供するために積み下ろされたプロトコルによって必要とされた情報を含んでいます。 この情報は、プロトコル、ソース、および送付先アドレスを含んでいて、また、サービスとフロー制御アドバイスのタイプを含んでいます。 以下で詳細にこれらのパラメタについて議論します。
Protocol
プロトコル
The protocol parameter identifies that off-loaded protocol in
the OPE to which Begin is directed, or which issued the Begin
to the Host. For example, if the user wished to utilize TCP
services, and the TCP software was off-loaded into the OPE,
then the Protocol parameter for the Begin command would be TCP.
プロトコルパラメタはBeginが向けられるOPEのHostにBeginを発行したその積み下ろされたプロトコルを特定します。 例えば、ユーザがTCPサービスを利用したがっていて、TCPソフトウェアがOPEへ積み下ろされるなら、BeginコマンドのためのプロトコルパラメタはTCPでしょうに。
There are two categories of protocol parameters -- generic and
specific. A generic parameter identifies a type of protocol
service required, but does not identify the actual protocol.
Use of generic protocols allows a Host process to obtain
network services without specific knowledge of what protocol is
being used; this could be appropriate for use in situations
where no specific aspect(s) of a specific protocol is/are
required. For example, the user may select a generic
Host-to-Host connection protocol, and (at some point in the
future) may actually receive services from either TCP or the
NBS Transport Protocol, depending on the network (or even the
foreign Host) in question. A specific protocol parameter
identifies some particular protocol, e.g., TCP, whose use is
required for the given channel.
プロトコルパラメタの2つのカテゴリがあります--ジェネリックで特定です。 ジェネリックパラメタは、サービスが必要とした一種のプロトコルを特定しますが、実際のプロトコルは特定しません。 ジェネリックプロトコルの使用で、Hostプロセスはどんなプロトコルが使用されるかに関する特定の知識なしでネットワーク・サービスを得ることができます。 状況における使用に、これは特定のプロトコルの特定の局面がないのが/が必要であるということであるところで適切であるかもしれません。 例えば、ユーザは、ジェネリックHostからホストへの接続プロトコルを選択して、実際にTCPかNBS Transportプロトコルのどちらかからのサービスを受けるかもしれません(未来の何らかのポイントで)、問題のネットワーク(または、外国Hostさえ)によって。 特定のプロトコルパラメタは何らかの特定のプロトコル、例えば使用が与えられたチャンネルに必要であるTCPを特定します。
The valid entries for the protocol field include:
プロトコル分野のための有効なエントリーは:
Generic Specific Comment
ジェネリックの特定のコメント
GIP IP Datagram Internetwork Protocol
HHP TCP Connection Transport/Host-Host Protocol
GDP UDP Datagram Transport/Host-Host Protocol
VTP TEL Virtual Terminal (Telnet) Protocol
GFP FTP File Transfer Protocol
MAIL SMTP Mail Transfer Protocol
PROX PROX Proximate Net Interface Protocol
GIP IPデータグラムインターネットワークプロトコルHHP TCP接続輸送/ホストホスト兼プロトコルGDP UDPデータグラム輸送/ホストのホスト兼メール転送プロトコルのPROX PROXの最も近いネットのインタフェースプロトコルVTP TEL仮想端末(telnet)プロトコルGFP FTPファイル転送プロトコルメールSMTPプロトコル
(Note that the final line is meant to allow for a process in an
OPE'd Host's getting at the PI of the Network Interface
Protocol for whatever the proximate network is. Of course, so
(もちろん最終的な系列が最も近いネットワークがことなら何でもであるかためにNetwork InterfaceプロトコルのPIで中のHostが得るOPEがそうするプロセスを考慮することになっていることに注意してくださいので。
Lilienkamp & Mandell & Padlipsky [Page 13]
Lilienkamp、マンデル、およびPadlipsky[13ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
doing only makes sense in specialized contexts. We conceive of
the desirability of "pumping bits at a peripheral" on a LAN,
though, and don't want to preclude it, even if it would be
impossible on many LAN's to deal with the problem of
distinguishing traffic coming back on the LAN in this "raw"
mode from normal, IP traffic. Indeed, in some contexts it is
likely that administrative considerations would preclude
avoidance of IP even if technical considerations allowed it,
but it's still the case that "the protocol" should provide a
hook for going directly to the L I protocol in play.)
するのは専門化している関係で理解できるだけです。 もっとも、LANの「周辺機器におけるビットをポンプで送ります」の願わしさを想像して、それを排除したいと思いません、この「生」のモードによるLANで標準から戻るトラフィックを区別するという問題にLANがことである対処するのが多くで不可能であっても、IPトラフィック。 本当に、いくつかの文脈では、技術的な問題がそれを許容したとしても管理問題がIPの回避を排除しますが、それでも、「プロトコル」が直接私がプレーで議定書の中で述べるLに行くためのフックを提供するべきであるのが、事実であることはありそうです。)
There is no default value for this parameter. If it is not
present, the Begin command is in error. The control flag for
this parameter is -pr.
このパラメタのためのデフォルト値が全くありません。 それが存在していないなら、Beginコマンドは間違っています。 このパラメタのための指揮旗は-prです。
Active/Passive
アクティブであるか、または受け身です。
The Active/Passive parameter indicates whether the issuer of
the Begin command desires to be the Active or Passive user of
the protocol. This parameter is particularly relevant to
connection-oriented protocols such as TCP, where the user may
actively pursue connection establishment, or else may passively
wait for the remote entity to actively establish the
connection; it also allows some process to establish itself as
the Host "fielder" of incoming traffic for a connectionless
protocol such as IP.
Active/受け身のパラメタは、Beginコマンドの発行人が、プロトコルのActiveかPassiveユーザであることを望んでいるかどうかを示します。 このパラメタは特にユーザが、活発にコネクション確立を追求するか、またはリモート実体が活発に接続を確立するのを受け身に待つかもしれないTCPなどの接続指向のプロトコルに関連しています。 また、それで、あるプロセスがIPなどのコネクションレスプロトコルのために入って来るトラフィックのHost「野手」として定着します。
Active is requested using the single character "A". Passive is
indicated using the character "P". The default value of this
parameter is "A". Also, when the OPE issues the Begin command,
the value must be "A". The control flag for this parameter is
-ap.
能動態は、単独のキャラクタ「A」を使用することで要求されています。 受動態は、キャラクタ「P」を使用することで示されます。 このパラメタのデフォルト値は「A」です。 また、OPEがBeginコマンドを発行するとき、値は「A」でなければなりません。 このパラメタのための指揮旗は-apです。
Foreign Address Primary Component
外国アドレスプライマリ構成要素
The addressing structure supported by H-FP is two level. Each
address has two components, the primary and the secondary. The
exact interpretation of these two components is protocol
specific, but some generalities do apply. The primary
component of the address identifies where the protocol is to
deliver the information. The secondary component identifies
which recipient at that location is to receive the information.
For example, the TCP primary address component is the Host's
Internet Address, while the secondary address component is the
TCP port. Similarly, IP's primary address component is the
Host's Internet Address, and the secondary address component is
the IP ULP field. Some protocols provide only a single level
H-FPによって支えられたアドレシング構造は2レベルです。 各アドレスには、2つのコンポーネント、予備選挙、およびセカンダリがあります。 これらの2つのコンポーネントの正確な解釈はプロトコル特有ですが、いくつかの一般性が適用されます。 アドレスのプライマリ構成要素は、プロトコルが情報をどこに提供するかことであることを特定します。 伴星は、その位置のどの受取人が知らせを聞くことになっているかを特定します。 例えば、TCPのプライマリアドレス構成要素はHostのインターネットAddressです、セカンダリアドレス構成要素がTCPポートですが。 同様に、IPのプライマリアドレス構成要素はHostのインターネットAddressです、そして、セカンダリアドレス構成要素はIP ULP分野です。 いくつかのプロトコルがただ一つのレベルだけを提供します。
Lilienkamp & Mandell & Padlipsky [Page 14]
Lilienkamp、マンデル、およびPadlipsky[14ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
of addressing, or the secondary level can be deduced from some
other information (e.g., Telnet). In these cases, only the
primary component is used. To cater to such cases, the
secondary component parameter comes later in the parameter
list.
アドレシング、またはセカンダリレベルがそうであることができます。ある他の情報(例えば、Telnet)から、推論されます。 これらの場合プライマリ構成要素だけは使用されています。 そのような場合に満たすために、伴星パラメタは後でパラメータ・リストに入ります。
The Foreign Address Primary Component parameter contains the
primary component of the destination address. It may be in
either a numeric or symbolic form. (Note that this allows for
the OPE to exercise a Name Server type of protocol if
appropriate, as well as freeing the Host from the necessity of
maintaining an in-board name to address table.) The default
value for this parameter, although it only makes sense for
Passive Begins, is "Any Host". The control flag for this
parameter is -fp.
Foreign Address Primary Componentパラメタは送付先アドレスのプライマリ構成要素を含んでいます。 それは数値か記号形式のどちらかにあるかもしれません。 (機内の名前を維持するという必要性からアドレス・テーブルまでHostを解放することと同様に適切であるなら、これが、OPEがプロトコルのName Serverタイプを運動させるのを許容することに注意してください。) Passive Beginsのために理解できるだけですが、このパラメタのためのデフォルト値は「どんなホストも」です。 このパラメタのための指揮旗はfpです。
Mediation Level
仲介レベル
The mediation level parameter is an indication of the role the
Host wishes the OPE to play in the operation of the protocol.
The extreme ranges of this mediation would be the case where
the Host wished to remain completely uninvolved, and the case
where the Host wished to make every possible decision. The
specific interpretation of this parameter is dependent upon the
particular off-loaded protocol.
仲介レベルパラメタはHostが、OPEにプロトコルの操作でプレーして欲しい役割のしるしです。 この仲介の最大射距離は、Hostが完全に無関心なままで残りたがっていたケースと、Hostがあらゆる可能な決定をしたがっていたケースでしょう。 このパラメタの特定の解釈は特定の積み下ろされたプロトコルに依存しています。
The concept of mediation level can best be clarified by means
of example. A full inboard implementation of the Telnet
protocol places several responsibilities on the Host. These
responsibilities include negotiation and provision of protocol
options, translation between local and network character codes
and formats, and monitoring the well-known socket for incoming
connection requests. The mediation level indicates whether
these responsibilities are assigned to the Host or to the OPE
when the Telnet implementation is outboard. If no OPE
mediation is selected, the Host is involved with all
negotiation of the Telnet options, and all format conversions.
With full OPE mediation, all option negotiation and all format
conversions are performed by the OPE. An intermediate level of
mediation might have ordinary option negotiation, format
conversion, and socket monitoring done in the OPE, while
options not known to the OPE are handled by the Host.
例によって仲介レベルの概念をはっきりさせることができるのは最も良いです。 Telnetプロトコルの完全な機内の実装は連帯責任をHostに置きます。 これらの責任は、プロトコルオプションに関する交渉と条項と、地方とネットワークキャラクタコードと形式の間の翻訳と、接続要求要求のためによく知られるソケットをモニターするのを含んでいます。 仲介レベルは、Telnet実装が船外であるときに、これらの責任がHost、または、OPEに割り当てられるかどうかを示します。 OPE仲介が全く選択されないなら、HostはTelnetオプションのすべての交渉、およびすべてのフォーマット変換にかかわります。 完全なOPE仲介で、すべてのオプション交渉とすべてのフォーマット変換がOPEによって実行されます。 OPEでして、普通のオプション交渉、フォーマット変換、およびソケットは中間的レベルの仲介によってモニターされるかもしれません、OPEにおいて知られないオプションがHostによって扱われますが。
The parameter is represented with a single ASCII digit. The
value 9 represents full OPE mediation, and the value 0
represents no OPE mediation. Other values may be defined for
パラメタは1ASCIIケタで表されます。 値9は完全なOPE仲介を表します、そして、値0はOPE仲介を全く表しません。 値が定義されるかもしれないもう一方
Lilienkamp & Mandell & Padlipsky [Page 15]
Lilienkamp、マンデル、およびPadlipsky[15ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
some protocols (e.g., the intermediate mediation level
discussed above for Telnet). The default value for this
parameter is 9. The control flag for this parameter is -m.
いくつかのプロトコル(例えばTelnetのために上で議論した中間的仲介レベル)。 このパラメタのためのデフォルト値は9です。 このパラメタのための指揮旗は-mです。
Transmit Response Discipline
応答規律を伝えてください。
The Transmit Response Discipline parameter is used to set the
desired action on the OPE's part for generating responses to
Transmit commands. Essentially the parameter determines when
the OPE's response to the transmit command occurs (i.e.,
immediately or delayed).
Transmit Response Disciplineパラメタは、Transmitコマンドへの応答を生成するのにOPEの部分への必要な動作を設定するのに使用されます。 すなわち、本質的にはパラメタが、伝えコマンドへのOPEの応答がいつ起こるかを決定する、(すぐに、延着する、)
The Transmit Response Discipline value is represented by a
single ASCII character. The character "N" is used for
nonblocking Transmit commands, which implies that responses for
Transmit commands should be generated as soon as the command
has been examined for correctness (i.e., that the syntax is
good and the parameters appear reasonable). In other words,
the outboard protocol interpreter has the data in its queue,
but hasn't necessarily transmitted it to the net. The
character "B" is used for blocking Transmit commands, which
requests that the response not be generated until the protocol
interpreter has successfully transmitted the data (unless, of
course, the Transmit command was badly formed). The default
value for this parameter is "N", or a nonblocking Transmit
command. The control flag for this parameter is -tr.
(Depending on the protocol in play, "successfully transmitted"
might well imply that an acknowledgment of some sort has been
received from the foreign Host, but for other protocols it
might only mean that the given collection of bits has been
passed from the OPE to the proximate net.)
Transmit Response Discipline値は単独のASCII文字によって表されます。 キャラクタ「N」は、伝えコマンドを「非-妨げ」るのに使用されます(コマンドが正当性がないかどうか調べられると(すなわち、構文が利益とパラメタであるように妥当に見えます)すぐに、伝えコマンドのための応答が生成されるべきであるのを含意します)。 言い換えれば、船外のプロトコルインタプリタは、待ち行列でデータを持っていますが、必ずそれをネットに伝えるというわけではありませんでした。 キャラクタ「B」は、伝えコマンドを妨げるのに使用されます(プロトコルインタプリタが首尾よくデータを送るまで(伝えコマンドがもちろんひどく形成されなかったなら)応答が生成されないよう要求します)。 このパラメタのためのデフォルト値は「N」であるか「非-妨げ」は伝えコマンドです。 このパラメタのための指揮旗は-trです。 (プレーのプロトコルによって、「首尾よく伝えられ」て、ある種の承認が外国Hostから受けられたのをたぶん含意するでしょうが、他のプロトコルのために、それは、ビットの与えられた収集がOPEから最も近いネットまで合格されたことを意味するだけであるかもしれません。)
Foreign Address Secondary Component
外国アドレス伴星
The addressing mechanisms supported by this level of H-FP are
discussed above. The Foreign Address Secondary Component
parameter contains the value of the destination address's
secondary component. Some protocols do not require this
parameter, or can obtain it from other information. Therefore,
the default value for this parameter is NULL. A NULL secondary
component might be an error for some protocols, however. The
secondary component can be expressed either numerically or
symbolically. The control flag for this parameter is -fs.
(Note that it is intended to be "legal" to specify a Secondary
Component other than the Well-Known Socket for the protocol in
play; in such cases, the result should be that the virtualizing
of the given protocol be applied to the stream, in the
上でH-FPのこのレベルでサポートされたアドレシングメカニズムについて議論します。 Foreign Address Secondary Componentパラメタは送付先アドレスsの伴星の値を含んでいます。 いくつかのプロトコルが、このパラメタを必要としないか、または他の情報からそれを得ることができます。 したがって、このパラメタのためのデフォルト値はNULLです。 しかしながら、NULL伴星はいくつかのプロトコルのための誤りであるかもしれません。数の上でか象徴的に伴星は急送できます。 このパラメタのための指揮旗は-fsです。 (プレーのプロトコルのためのWellによって知られているSocket以外のSecondary Componentを指定するために「法的」であることが意図していることに注意してください; そのような場合、結果は当然のことのプロトコルのvirtualizingがストリームに適用されるということであるべきです、コネ
Lilienkamp & Mandell & Padlipsky [Page 16]
Lilienkamp、マンデル、およびPadlipsky[16ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
expectation that that's what the other side is expecting. This
is to cater to, for example, a Terminal-Terminal protocol that
merely "does Telnet" to a socket other than the usual Logger.)
期待、それは反対側が予想していることです。 これは例えば、単に普通のLogger以外のソケットに「Telnetをする」Terminal-端末プロトコルに満たすためのものです。)
Local Address Secondary Component
ローカルアドレス伴星
The Local Address Secondary Component parameter contains the
value of the local address's secondary component. (The primary
component is assumed to be the default for the Host, but can be
altered as well; see below.) Some protocols do not require this
parameter, or can obtain it from other information. In some
cases, the OPE may already know the value for this parameter
and therefore not require it. The default value of this
parameter is NULL. The local address secondary component can
be expressed either numerically or symbolically. The control
flag for this parameter is -ls.
Local Address Secondary Componentパラメタはローカルアドレスの伴星の値を含んでいます。 (プライマリ構成要素をHostのためのデフォルトであると思われますが、また、変更できます; 以下を見てください。) いくつかのプロトコルが、このパラメタを必要としないか、または他の情報からそれを得ることができます。 いくつかの場合、OPEはこのパラメタで既に値を知って、したがって、それを必要としないかもしれません。 このパラメタのデフォルト値はNULLです。 数の上でか象徴的にローカルアドレス伴星を急送できます。 このパラメタのための指揮旗は-lsです。
Begin Timeout Interval
タイムアウト間隔を始めてください。
After a Begin command is issued, a timer can be started. If
the activity requested cannot be performed within some timed
interval, then the Begin command may expire. An expired Begin
command returns a response code indicating a Begin timeout
occurred. The Begin Timeout Interval parameter contains the
length of time the timer will run before the Begin timeout
occurs.
Beginコマンドを発行した後に、タイマを始動できます。 いくつかの調節された間隔以内に要求された活動を実行できないなら、Beginコマンドは期限が切れるかもしれません。 満期のBeginコマンドはBeginタイムアウトが起こったのを示す応答コードを返します。 Beginタイムアウトが起こる前にBegin Timeout Intervalパラメタはタイマが実行する時間の長さを含んでいます。
The parameter is represented as a string of ASCII digits
indicating the time interval in seconds. The default value of
this parameter is infinity (i.e., the Begin command will never
timeout). The control flag for this parameter is -bt.
パラメタは秒に時間間隔を示す一連のASCIIケタとして表されます。 このパラメタのデフォルト値は無限(すなわち、Beginは、タイムアウトを決して望まないように命令する)です。 このパラメタのための指揮旗は-btです。
Type of Service Advice
サービスアドバイスのタイプ
The Type of Service Advice parameter contains information on
the service characteristics the user desires from the offloaded
protocol. Included in this parameter is the precedence of the
data transfer, and also indication of whether high throughput,
fast response time, or low error rate is the primary goal.
Service AdviceパラメタのTypeはユーザが積み下ろされたプロトコルから望んでいるサービスの特性の情報を含んでいます。 このパラメタに含まれているのは、データ転送の先行と、また、高生産性、速い応答時間、または低誤り率がプライマリ目標であるかどうかしるしです。
The format of this parameter is a letter immediately (i.e. no
intervening spaces) followed by a digit. The letter "T"
indicates that high throughput is desired. The letter "R"
indicates minimal response time is the goal. The letter "E"
indicates that low error rates are the goal. The letter "N"
indicates there are no special service requirements to be
conveyed. The digit immediately following the character
このパラメタの形式はケタがすぐにいうことになった(すなわち、空間に介入しません)手紙です。 文字「T」は、高生産性が望まれているのを示します。 文字「R」は、最小量の応答時間が目標であることを示します。 文字「E」は、低誤り率が目標であることを示します。 文字「N」は、運ばれるというどんな特別なサービス要件もないのを示します。 すぐにキャラクタに続くケタ
Lilienkamp & Mandell & Padlipsky [Page 17]
Lilienkamp、マンデル、およびPadlipsky[17ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
indicates the desired precedence level, with zero being the
lowest, and nine being the highest. The specific
interpretation of this parameter is dependent on what service
options are provided by the protocol. The default value of
this parameter is the lowest precedence (ROUTINE), and no
special service requests. The control flag for this parameter
is -ts.
ゼロが最も低く、9が最も高い状態で必要な先行レベルを示します。 このパラメタの特定の解釈はサービスオプションがプロトコルによって提供されることに依存しています。 最も低い先行(ROUTINE)にもかかわらず、このパラメタのデフォルト値は特別なサービスのリクエストではありません。 このパラメタのための指揮旗はtです。
Flow Control Advice
フロー制御アドバイス
The Flow Control Advice parameter contains information on the
flow characteristics desired by the user. Some applications
such as file transfer operate more efficiently if the data is
transferred in large pieces, while other, more interactive
applications are more efficiently served if smaller pieces are
used. This parameter then indicates whether large or small
data blocks should be used. It is only relevant in stream or
connection-oriented protocols, where the user sends more than a
single piece of data.
Flow Control Adviceパラメタはユーザによって望まれていた流れの特性の情報を含んでいます。 大きい断片にデータを移すなら、ファイル転送などのいくつかの応用が、より効率的に作動します、他間より小さい断片が使用されているなら、より対話的なアプリケーションは、より効率的に役立たれています。 そして、このパラメタは、大きいかわずかなデータ・ブロックが使用されるべきであるかどうかを示します。 それはストリームか接続指向のプロトコルだけで関連しています。そこでは、ユーザが1片のデータより発信します。
This parameter is represented by a single ASCII digit. A value
0 means the data should be sent in relatively small blocks
(e.g., character or line oriented applications), while a value
9 means the data should be sent in relatively large blocks
(e.g., block or file oriented applications). Other values
represent sizes between those extremes. The character "N"
indicates that no special flow control advice is provided. The
actual interpretation of this parameter is dependent on the
particular protocol in the OPE. The default value of this
parameter is no flow control advice. In this case, the protocol
in the OPE will operate based only on information available in
the OPE. The control flag for this parameter is -fc.
このパラメタは1ASCIIケタによって表されます。 値0は、データが比較的わずかなブロックで送られるべきであることを(例えば、キャラクタか系列がアプリケーションを適応させました)意味します、値9は、データが比較的大きいブロックで送られるべきであることを(例えば、指向のアプリケーションを妨げるか、またはファイルしてください)意味しますが。 他の値はそれらの極端の間のサイズを表します。 キャラクタ「N」は、どんな特別なフロー制御アドバイスも提供されないのを示します。 このパラメタの実際の解釈はOPEの特定のプロトコルに依存しています。 このパラメタのデフォルト値はフロー制御アドバイスではありません。 この場合、OPEのプロトコルはOPEで利用可能な情報だけに基づいた状態で作動するでしょう。 このパラメタのための指揮旗は-fcです。
Local Address Primary Component
ローカルアドレスのプライマリ構成要素
This parameter contains the local address primary component. It
is anticipated that under most circumstances, this component is
known to both the Host and the OPE. Consequently, this
parameter is seldom required. It would be useful if the Host
desired to select one of several valid addresses, however. The
control flag for this parameter is -lp.
このパラメタはローカルアドレスのプライマリ構成要素を含んでいます。 ほとんどの状況で、このコンポーネントがHostとOPEの両方に知られていると予期されます。 その結果、このパラメタはめったに必要ではありません。 Hostが、しかしながら、いくつかの有効なアドレスの1つを選択することを望んでいるなら、役に立つでしょうに。このパラメタのための指揮旗は-lpです。
Security
セキュリティ
The security parameters contain a set of security level,
compartment, community of interest, and handling restriction
information. Currently, security is provided by performing all
セキュリティパラメタは1セットのセキュリティー・レベル、コンパートメント、利益共同体、および取り扱い制限情報を含んでいます。 現在、すべてを実行することによって、セキュリティを提供します。
Lilienkamp & Mandell & Padlipsky [Page 18]
Lilienkamp、マンデル、およびPadlipsky[18ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
processing at system high level or at a single level.
Consequently, these parameters are probably redundant, since
the security information is known. In the future, however,
these parameters may be required. Therefore a field is
provided. The control flag for this parameter is -s.
システム・ハイレベルにおいて、または、ただ一つのレベルにおいて処理します。 その結果、セキュリティ情報が知られているので、これらのパラメタはたぶん余分です。 しかしながら、将来、これらのパラメタが必要であるかもしれません。 したがって、野原を供給します。 このパラメタのための指揮旗は-sです。
Protcol Idiosyncratic Parameters
Protcolの特有のパラメタ
The remaining parameters are protocol idiosyncratic. That is,
each protocol that is off-loaded may have a set of these
parameters, which are documented with a description of the
off-loaded protocol. The default value for these parameters is
NULL, unless otherwise specified by a particular offloaded
protocol. The control flag for this set of parameters is -pi,
which identifies the first protocol idiosyncratic parameters.
Control flags for other protocol idiosyncratic parameters must
be defined for each off-loaded protocol.
残っているパラメタはプロトコル特有です。 積み下ろされるすなわち各プロトコルはこれらのパラメタのセットを持っているかもしれません。(パラメタは積み下ろされたプロトコルの記述によって記録されます)。 別の方法で特定の積み下ろされたプロトコルによって指定されない場合、これらのパラメタのためのデフォルト値はNULLです。 このセットのパラメタのための指揮旗はパイの特有のパラメタです。(それは、最初のプロトコルを特定します)。 特有のパラメタを定義しなければならない他のプロトコルのための指揮旗はそれぞれプロトコルを積み下ろしました。
Data
データ
After the Protocol Idiosyncratic Parameters, if any, and the
required <nl>, if the protocol in play allows for it at this
juncture the rest of the chunk will be interpreted as data to
be transmitted. That is, in connection oriented protocols data
may or may not be permitted at connection initiation time, but
in connectionless protocols it certainly makes sense to allow
the H-FP Begin command to convey data. (This will also be
useful when we get to the Condition command.)
プロトコルIdiosyncratic Parametersの後に、塊の残りは、いずれかと、必要な<nl>であるなら、プレーのプロトコルがこの際それを考慮すると伝えられるためにデータとして解釈されるでしょう。 すなわち、接続では、指向のプロトコルデータは接続開始時間に受入れられるかもしれませんが、コネクションレスプロトコルでは、確かに、それはデータを伝えるH-FP Beginコマンドを許容する意味になります。 (また、私たちがConditionコマンドを始めるとき、これも役に立ちます。)
Responses
応答
The following responses have been identified for the Begin
command:
以下の応答はBeginコマンドのために特定されました:
000 Command completed successfully
101 Throughput not available; using maximum
102 Reliability not available; using maximum
103 Delay not available; using minimum
110 Flow Control advice not followed; smaller blocks used
111 Flow Control advice not followed; larger blocks used
201 Failed; Begin not implemented in this direction
202 Failed; timeout
203 Failed; Begin command on already active channel
300 Problem with multiple chunks
301 Syntax problem with Begin command
302 Protocol not supported in OPE/Host
303 Active service not available
000 コマンドは首尾よく利用可能でない101Throughputを完成しました。 利用可能でない使用最大の102Reliability。 利用可能でない使用最大の103Delay。 最小の110Flow Controlアドバイスを使用するということになりませんでした。 よりわずかな中古さブロックである111Flow Controlアドバイスは従いませんでした。 より大きいブロックは201Failedを使用しました。 この方向202Failedで実装されないで、始まってください。 タイムアウト203Failed。 Beginコマンド302プロトコルに関する複数の塊301Syntax問題がある300Problemが利用可能でないOPE/ホスト303Activeサービスで支えなかった既に活発なチャンネルの上にコマンドを始めてください。
Lilienkamp & Mandell & Padlipsky [Page 19]
Lilienkamp、マンデル、およびPadlipsky[19ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
304 Passive service not available
305 Invalid Foreign Address Primary Component
306 Invalid Transmit Discipline
307 Invalid Foreign Address Secondary Component
308 Invalid Local Address Secondary Component
309 Invalid Timeout Interval
310 Invalid Type of Service Advice
311 Invalid Flow control Advice
312 Invalid Local Address Primary Component
401 Protocol Interpreter in OPE not responding
402 Remote Protocol Interpreter not available
403 Failed; insufficient protocol interpreter resources
501 Failed; insufficient OPE resources
601 Request violates security policy
602 Security parameter problem
304 利用可能な403Failedではなく、402RemoteプロトコルInterpreterを反応させないOPEのService Advice311Invalid FlowコントロールAdvice312Invalid Local Address Primary Component401プロトコルInterpreterの利用可能な305Invalid Foreign Address Primary Component306Invalid Transmit Discipline307Invalid Foreign Address Secondary Component308Invalid Local Address Secondary Component309Invalid Timeout Interval310Invalid Typeではなく、受け身のサービス。 不十分なプロトコルインタプリタリソース501Failed。 不十分なOPEリソース601Requestは安全保障政策602Securityパラメタ問題に違反します。
Additionally, protocol idiosyncratic responses will be defined
for each off-loaded protocol.
さらに、特有の応答が定義されるプロトコルはそれぞれプロトコルを積み下ろしました。
Example of Begin Command
始まりコマンドに関する例
The Begin command is the most complex of the H-FP Command
Level. When the off-loaded protocol is TCP, the Begin command
is used to open TCP connections. One possible example of a
Begin command issued by an inboard Telnet interpreter to open a
TCP connection to ISIA, with no begin timeout interval, is:
BeginコマンドはH-FP Command Levelの最も多くの複合体です。 積み下ろされたプロトコルがTCPであるときに、Beginコマンドは、TCP接続を開くのに使用されます。 TCP接続をISIAに開くために機内のTelnetインタプリタによって発行されたBeginコマンドの1つの可能な例、いいえは、タイムアウト間隔を始めて、あります:
C BE TCP A ISIA 9 N 23 ,, ,, N0 S <nl>
C、TCP A ISIA9N23になってください、N0 S<nl>。
Where:
どこ:
TCP The code for the protocol TCP
A Indicates Active Begin
ISIA The name of a Host at USC-ISI
9 Mediation Level 9: Full OPE mediation
N Non-blocking transmit
23 Destination Telnet Port
,, skip over parameters (Local Address Secondary,
Begin Timeout Interval)
N0 Type of Service Advice: No special Advice,
Normal Precedence
S Flow Control Advice: use small blocks
TCP、プロトコルTCP A Indicates Active Begin ISIAには、USC-ISI9Mediation Level9でHostという名前をコード化してください: 完全なOPE仲介N Non-ブロッキングが23Destination Telnet Portを伝える、Service Adviceのパラメタ(地方のAddress Secondary、Begin Timeout Interval)N0 Typeの上で以下をスキップしてください。 特別なAdviceがない、Normal Precedence S Flow Control Advice: わずかなブロックを使用してください。
This command will cause the OPE to invoke the TCP interpreter
to generate the initial SYN packet to the well-known Telnet
socket on Host ISIA. It also informs the OPE to do all TCP
related processing via the Mediation Level, accepts default
このコマンドで、OPEは、Host ISIAの上のよく知られるTelnetソケットに初期のSYNパケットを生成するためにTCPインタプリタを呼び出すでしょう。 それは、また、Mediation Levelを通して処理しながら関係づけられたすべてのTCPをするためにOPEに知らせて、デフォルトを受け入れます。
Lilienkamp & Mandell & Padlipsky [Page 20]
Lilienkamp、マンデル、およびPadlipsky[20ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
Local Address parameters, and sets the Begin Timeout Interval
to infinity. The precedence of the TCP connection is Normal,
and the TCP interpreter is informed that the data stream will
consist of primarily small blocks.
ローカルのAddressパラメタ、Begin Timeout Intervalを無限で設定します。 TCP接続の先行はNormalです、そして、TCPインタプリタにデータ・ストリームが主としてわずかなブロックから成ると知らされます。
Notes to the Implementor
作成者への注意
Response 203 might seem silly to some readers, but it's there
in case somebody goofed in using the Channel Layer.
応答203は何人かの読者にとって愚かに見えるかもしれませんが、だれかが英仏海峡Layerを使用する際に失敗するといけなかったので、それはそこにあります。
Transmit
伝わってください。
Purpose of the Transmit Command
伝えコマンドの目的
The purpose of the Transmit command is to permit the process in
the Host to send data using an off-loaded protocol interpreter
in the OPE, and also to permit the OPE to deliver data received
from the network destined for the process in the Host. The
Transmit command is particularly relevant to connection and
stream type protocols, although it has applications for
connectionless protocols as well. After the Begin command is
issued successfully and the proper Response received, Transmit
commands can be issued on the given channel. The semantics of
the Transmit command depend on whether it was issued by the
Host or the OPE.
Transmitコマンドの目的はHostのプロセスが、OPEで積み下ろされたプロトコルインタプリタを使用することでデータを送って、また、OPEがHostのプロセスのために運命づけられたネットワークから受け取られたデータを提供することを許可することを許可することです。 Transmitコマンドは特に接続とストリーム型プロトコルに関連しています、それには、また、コネクションレスプロトコルのアプリケーションがありますが。 首尾よくBeginコマンドを発行して、適切なResponseが受信した後に、与えられたチャンネルの上にTransmitコマンドを発行できます。 Transmitコマンドの意味論はそれがHostかOPEによって発行されたかどうかによります。
- If the Host issues the Transmit command, a process in the
Host wishes to send the data to the destination specified to
the off-loaded protocol interpreter that was established
(typically) by a previous Begin command on the given H-FP
channel.
- HostがTransmitコマンドを発行するなら、データを目的地に送るというHost願望におけるプロセスは与えられたH-FPチャンネルにおける前のBeginコマンドで設立された(通常)積み下ろされたプロトコルインタプリタに指定しました。
- If the OPE issues the command, the OPE has received data
destined for a process in the Host from a connection or stream
supported by the off-loaded protocol that was established by a
previous Begin command on the given H-FP channel.
- OPEが命令を発するなら、OPEはプロセスのためにHostで与えられたH-FPチャンネルにおける前のBeginコマンドで確立された積み下ろされたプロトコルによってサポートされた接続かストリームから受信データを運命づけさせています。
Parameters of the Transmit Command
伝えコマンドのパラメタ
The Transmit command has one parameter associated with it. It
is an optional parameter, to temporarily override the response
discipline for this particular transmit command. Some protocols
may have protocol-idiosyncratic parameters as well. The
transmit command also has data associated with it. All
parameters must precede the data to be transmitted.
Transmitコマンドには、それに関連している1つのパラメタがあります。 それは、この特定の伝えコマンドのために一時応答規律をくつがえすためには任意のパラメタです。 いくつかのプロトコルには、また、プロトコル特有のパラメタがあるかもしれません。 また、伝えコマンドには、それに関連しているデータがあります。 すべてのパラメタが、伝えられるためにデータに先行しなければなりません。
Lilienkamp & Mandell & Padlipsky [Page 21]
Lilienkamp、マンデル、およびPadlipsky[21ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
Response Discipline Override
応答規律オーバーライド
The Response Discipline Override parameter indicates the
desired response discipline for that individual Transmit
Command, overriding the default response discipline. A single
ASCII character is used to indicate the desired discipline.
The character "N" indicates that this Transmit command should
not block, and should return a response as soon as the data is
given to the protocol interpreter in the OPE. The character "B"
indicates that this Transmit command should block, meaning that
a response should not be generated until the data has been sent
to the destination. The default value of this parameter is the
currently defined Transmit Command response discipline. The
use of this parameter does not alter the currently defined
Transmit command response discipline; the default is changed
with the Condition command. The control flag for this
parameter is -rd.
デフォルト応答規律をくつがえして、Response Discipline Overrideパラメタはその個々のTransmit Commandのために必要な応答規律を示します。 単独のASCII文字は、必要な規律を示すのに使用されます。 この伝えコマンドが妨げるべきでなくて、データの次第応答を返すべきである「N」が示すキャラクタをOPEのプロトコルインタプリタに与えます。 キャラクタ「B」は、この伝えコマンドはブロック、応答がデータを目的地に送るまで生成されるべきでない意味がそうするべきであるのを示します。 このパラメタのデフォルト値は現在定義されたTransmit Command応答規律です。 このパラメタの使用は現在定義されたTransmitコマンド応答規律を変更しません。 Conditionコマンドによると、デフォルトを変えます。 このパラメタのための指揮旗がそうである、第-
Protocol-Idiosyncratic Parameters
プロトコル特有のパラメタ
Any other parameters to the Transmit command are
protocol-idiosyncratic. That is, each protocol that is
off-loaded has a set of these parameters, which are documented
with a description of the off-loaded protocol. The default
value for these parameters is NULL, unless otherwise specified
by a particular off-loaded protocol. The control flag for this
set of parameters is -pi, which identifies the first
protocol-idiosyncratic parameters. Control flags for other
protocol-idiosyncratic parameters must be defined for each
off-loaded protocol.
Transmitコマンドへのいかなる他のパラメタもプロトコル特有です。 積み下ろされるすなわち各プロトコルはこれらのパラメタのセットを持っています。(パラメタは積み下ろされたプロトコルの記述によって記録されます)。 別の方法で特定の積み下ろされたプロトコルによって指定されない場合、これらのパラメタのためのデフォルト値はNULLです。 このセットのパラメタのための指揮旗はパイです。(そのパイは最初のプロトコル特有のパラメタを特定します)。 それぞれの積み下ろされたプロトコルのために他のプロトコル特有のパラメタのための指揮旗を定義しなければなりません。
Responses
応答
The following responses for the Transmit command have been
identified:
Transmitコマンドのための以下の応答は特定されました:
000 Transmit Command completed successfully
201 Transmit Command not appropriate
300 Problem with multiple chunks
301 Syntax problem with Transmit Command
302 Invalid Transmit Command Response Discipline
401 Protocol Interpreter in OPE not responding
402 Failure in remote protocol interpreter
403 Failed; insufficient protocol interpreter resources
501 Failed; insufficient OPE resources
601 Request violates security policy
000は伝わります。Commandはリモートプロトコルインタプリタ403Failedで402Failureを反応させないことでOPEでTransmit Command302Invalid Transmit Command Response Discipline401プロトコルInterpreterに関する複数の塊301Syntax問題で首尾よく適切な300Problemではなく、201Transmit Commandを完成しました。 不十分なプロトコルインタプリタリソース501Failed。 不十分なOPEリソース601Requestは安全保障政策に違反します。
Lilienkamp & Mandell & Padlipsky [Page 22]
Lilienkamp、マンデル、およびPadlipsky[22ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
Additionally, protocol-idiosyncratic responses will be defined
for each off-loaded protocol.
さらに、プロトコル特有の応答はそれぞれの積み下ろされたプロトコルのために定義されるでしょう。
Example of Transmit Command
伝えコマンドに関する例
The transmit command is used in TCP to provide the TCP write
call. An example of such a transmit command would be:
伝えコマンドは提供するTCPが呼ぶと書くTCPで使用されます。 そのような伝えコマンドに関する例は以下の通りでしょう。
C TR N <nl> <DATA>
C TR N<nl><データ>。
Where N indicates non-blocking transmission discipline, <nl> is
the required command-ending newline, and <DATA> is presumed to
be the user's data that is to be transmitted.
Nが非ブロッキング送信規律を示して、<nl>が必要なコマンド結末ニューラインであり、<DATA>があえてユーザのデータであるところに、それは送られることになっています。
Notes to the Implementor
作成者への注意
If you get a 403 or a 501 response and have sent a multiple
chunk it probably makes sense to try a single chunk; if you've
sent a single chunk, it makes sense to wait a while and try
again a few times before giving up on the stream/channel.
あなたが403か501応答を得て、複数の塊を送ったなら、たぶんただ一つの塊を試みる意味になります。 あなたがただ一つの塊を送ったなら、それはストリーム/チャンネルに見切りをつける数回前にしばらく待って、再試行する意味になります。
Condition
状態
Purpose of the Condition Command
状態コマンドの目的
The primary purpose of the Condition command is to permit a
process to alter the characteristics that were originally set
up with the Begin command. (That is, "condition" is a verb.)
These characteristics include the addresses, the mediation
level, the type of service, and the flow control parameters
from Begin. They may also include protocol-idiosyncratic
characteristics. (Although Condition is usually thought of as a
Host->OPE command, it may also be used OPE->Host in some
contexts.)
Conditionコマンドのプライマリ目的はプロセスが元々Beginコマンドでセットアップされた特性を変更することを許可することです。 (すなわち、「状態」は動詞です。) これらの特性はアドレス、仲介レベル、サービスのタイプ、およびBeginからのフロー制御パラメタを含んでいます。 また、彼らはプロトコル特有の特性を含むかもしれません。 (ConditionはOPEが命令するHost->として通常考えられますが、また、それは中古のOPE->がいくつかの文脈のHostであったなら考えられるかもしれません。)
Condition is a generic command that may find little use in some
off-loaded protocols. In others, only some of the parameters
identified may make sense. For example, changing the
destination address of a TCP connection involves closing one
connection and opening another. Consequently, in may make more
sense to first issue an End command, and then a Begin with the
new address. In other protocols, such as IP or UDP, changing
the address on each datagram would be a perfectly reasonable
thing to do.
状態はいくつかにおける使用がほとんどプロトコルを積み下ろさなかったのがわかるかもしれないジェネリックコマンドであることによって。 他のものでは、特定されたパラメタのいくつかだけが理解できるかもしれません。 例えば、TCP接続の送付先アドレスを変えるのは、1つの接続を終えて、別のものを開くことを伴います。 その結果、そして、中では、Endコマンド、および次に、新しいアドレスがあるBeginは創刊号により多く理解できるかもしれません。 IPかUDPなどの他のプロトコルでは、各データグラムに関するアドレスを変えるのは、する完全に妥当なことでしょう。
Lilienkamp & Mandell & Padlipsky [Page 23]
Lilienkamp、マンデル、およびPadlipsky[23ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
Parameters of the Condition Command
状態コマンドのパラメタ
The Condition command has the same parameters as the Begin
command. Any parameters expressed in a Condition command
indicate the new values of the characteristics to be altered;
all parameters not expressed retain the current value.
Conditionコマンドには、Beginコマンドと同じパラメタがあります。 Conditionコマンドで言い表されたどんなパラメタも変更されるために特性の新しい値を示します。 パラメタが言い表さなかったすべてが現行価値を保有します。
Although it is possible to express the change of any of the
characteristics originally set up in the Begin command using
the Condition command, there are some characteristics that do
not make sense to alter, at least for some protocols. For
example, once a connection is opened, it does not make much
sense to change the Foreign Address Primary or Secondary
Components. Doing so is inconsistent with current versions of
TCP, and would require the closing of the existing connection
and opening a new one to another address. Earlier versions of
TCP did permit connections to be moved. If a protocol that
provided such a feature was implemented in the OPE, the
changing the Secondary Address Components would be a reasonable
thing to do.
元々Conditionコマンドを使用するBeginコマンドでセットアップされた特性のどれかの変化を言い表すのが可能ですが、変わる意味にならないいくつかの特性があります、少なくともいくつかのプロトコルのために。 例えば、接続がいったん開かれると、それはForeign Address PrimaryかSecondary Componentsを変える多くの意味になりません。 そうするのはTCPの最新版に矛盾していて、既存の接続と新しいものを開く閉鎖を別のアドレスに必要とするでしょう。 TCPの以前のバージョンは、接続が動かされるのを許容しました。 そのような特徴を提供したプロトコルが実装されるなら、OPE、変化におけるSecondary Address Componentsはする妥当なことでしょうに。
Responses
応答
The responses to the Condition command are the same as those to
the Begin command.
Conditionコマンドへの応答はBeginへのものが命令するのと同じです。
Example of Condition Command
状態コマンドに関する例
The Condition Command can be quite complex, and can be used for
many purposes. One conceived use of the condition command
would be to change the type of service advice associated with
the channel. An example of this (which also demonstrates the
ability to skip parameters) is:
Condition Commandはかなり複雑である場合があり、多くの目的に使用できます。 1つは、状態コマンドの使用がチャンネルに関連しているサービスアドバイスのタイプを変えることであることを発想しました。 この(また、パラメタをスキップする能力を示す)例は以下の通りです。
C -ts T <nl>
C t T<nl>。
which causes the offloaded PI associated with the current
channel to attempt to achieve high throughput (in its use of
the comm subnet(s) in play).
現在のチャンネルに関連している積み下ろされたPIに高生産性(commサブネットのプレーで使用での)を達成するのを試みさせます。
Notes to the Implementor
作成者への注意
Lilienkamp & Mandell & Padlipsky [Page 24]
Lilienkamp、マンデル、およびPadlipsky[24ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
Signal
信号
Purpose of Signal Command
信号コマンドの目的
The purpose of the Signal Command (implicitly at least) is to
permit the transfer of out-of-band signals or information
between the Host and the OPE, in order to utilize (explicitly)
out-of-band signaling services of the off-loaded protocol. The
semantics of the Signal command depend upon whether it was
issued by the Host or the OPE.
Signal Command(少なくともそれとなく)の目的はHostとOPEの間のバンドの外に関する信号か情報を転送に可能にすることです、バンドの外で積み下ろされたプロトコルのシグナリングサービスを利用する(明らかである)ために。 Signalコマンドの意味論はそれがHostかOPEによって発行されたかどうかによります。
- If the Signal command was issued by the Host, it means a
process in the Host desires to send out-of-band data or an
out-of-band signal.
- SignalコマンドがHostによって発行されたなら、それはバンドの外にデータを送るHost願望かバンドで出ている信号でプロセスを意味します。
- If the Signal command was issued by the OPE, it means
out-of-band data or an out-of-band signal arrived for the
process associated with the channel in the Host.
- SignalコマンドがOPEによって発行されたなら、それは、バンドの外でデータかバンドで出ている信号がHostのチャンネルに関連しているプロセスのために届いたことを意味します。
Parameters of the Signal Command
信号コマンドのパラメタ
The basic usage of the Signal command is with no parameters,
which sends or reports the receipt of an out-of-band signal.
Some protocols, such as the NBS Transport Protocol, permit the
user to send data with the out-of-band signal. Hence, data is
permitted to accompany the Signal command. There may also be
protocol-idiosyncratic parameters for the Signal command. If
this is the case, these parameters would come before the data.
Signalコマンドの基本的な使用がパラメタなしであります(バンドで出ている信号の領収書を送るか、または報告します)。 NBS Transportプロトコルなどのいくつかのプロトコルが、ユーザがバンドで出ている信号でデータを送ることを許可します。 したがって、データがSignalコマンドに伴うことが許可されています。 また、Signalコマンドのためのプロトコル特有のパラメタがあるかもしれません。 これがそうであるなら、これらのパラメタはデータの前に来るでしょう。
Protocol-Idiosyncratic Parameters
プロトコル特有のパラメタ
The parameters for the Signal command are protocol
idiosyncratic. That is, each protocol off-loaded has a set of
these parameters. The default value for these parameters is
their previous values. Control flags for multiple
protocol-idiosyncratic parameters must be defined for each
off-loaded protocol.
Signalコマンドのためのパラメタはプロトコル特有です。 積み下ろされたすなわち各プロトコルはこれらのパラメタのセットを持っています。 これらのパラメタのためのデフォルト値はそれらの前の値です。 それぞれの積み下ろされたプロトコルのために複数のプロトコル特有のパラメタのための指揮旗を定義しなければなりません。
Responses
応答
The following responses have been identified for the Signal
command:
以下の応答はSignalコマンドのために特定されました:
000 Command completed successfully
201 Command not appropriate
300 Problem with multiple chunks
301 Syntax problem with Command
000 コマンドはCommandに関する複数の塊301Syntax問題で首尾よく適切な300Problemではなく、201Commandを完成しました。
Lilienkamp & Mandell & Padlipsky [Page 25]
Lilienkamp、マンデル、およびPadlipsky[25ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
401 Protocol Interpreter in OPE not responding
402 Failure in remote protocol interpreter
403 Failed; insufficient protocol interpreter resources
501 Failed; insufficient OPE resources
601 Request violates security policy
401 リモートプロトコルインタプリタ403Failedで402Failureを反応させないで、OPEでInterpreterについて議定書の中で述べてください。 不十分なプロトコルインタプリタリソース501Failed。 不十分なOPEリソース601Requestは安全保障政策に違反します。
Additionally, protocol-idiosyncratic responses will be defined
for each off-loaded protocol.
さらに、プロトコル特有の応答はそれぞれの積み下ろされたプロトコルのために定義されるでしょう。
Example of Signal Command
信号コマンドに関する例
The major perceived use for the Signal command when offloading
a connection protocol is sending an out-of-band signal with no
data. In such a case, the appropriate signal command would be:
接続プロトコルを積み下ろすときのSignalコマンドの使用であると知覚された少佐はデータなしでバンドで出ている信号を送ります。 このような場合には、適切な信号コマンドは以下の通りでしょう。
C SI <nl>
C SI<nl>。
Notes to the Implementor
作成者への注意
Some protocols may allow only only one outstanding signal at a
time. For these protocols, it is an implementation issue
whether the OPE will buffer several signals, but a good case
could be made for the position that a scrupulous OPE would
reflect a 202 response back to the Host in such cases.
いくつかのプロトコルが一度に1つの傑出している信号だけを許容するかもしれません。 これらのプロトコルにおいて、OPEがいくつかの信号をバッファリングするか否かに関係なく、それは導入問題ですが、良い弁護をきちょう面なOPEがそのような場合202応答をHostに映し出すだろうという位置にすることができました。
There is some question as to the proper handling of the
"expedited data" notion of some (particularly ISO) protocols.
It might be more appropriate to deal with such a thing as a
protocol idiosyncratic parameter on the Transmit command
instead of using the Signal command (even if it's the closest
approximation to an out-of-band signal in the given protocol).
If it's provided using the Signal command, the expedited data
should not be passed as ASCII, and should appear after the
command-terminating newline character (and appropriate padding
with space characters).
いくつかの(特にISO)プロトコルの「速められたデータ」概念の適切な取り扱いに関して何らかの質問があります。 それはSignalコマンドを使用することの代わりにTransmitコマンドに関する特有のパラメタはプロトコルのようなものを取扱うのが、より適切であるかもしれません(それが当然のことのプロトコルのバンドで出ている信号への最も厳密な近似であっても)。 Signalコマンドを使用することで提供したなら、速められたデータは、ASCIIとして通過するべきでなくて、コマンドを終えるニューラインキャラクタ(そして、間隔文字による適切な詰め物)の後に現れるべきです。
Status
状態
Purpose of Status Command
状態コマンドの目的
The purpose of the Status command is to permit the Host to
request and obtain status information from the OPE, and vice
versa. This includes status request of a conventional protocol
interface (e.g., in TCP, there is a request to determine the
state of a particular connection).
Statusコマンドの目的はHostがOPEから状態情報を要求して、得ることを許可することです、逆もまた同様に。 これは従来のプロトコルインタフェースの状態要求を含んでいます(例えば、TCPに、特定の接続の状態を決定するという要求があります)。
Lilienkamp & Mandell & Padlipsky [Page 26]
Lilienkamp、マンデル、およびPadlipsky[26ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
Parameters of the Status Command
状態コマンドのパラメタ
The parameters for the Status command indicate whether it is a
request or a response, and contain the status information.
Statusコマンドのためのパラメタは、それが要求かそれとも応答であるかを示して、状態情報を含んでいます。
Request/Report
要求するか、または報告してください。
This parameter indicates whether the command is a Status
request or a Status report. It consists of a single ASCII
character. Q indicates a request (query), and R indicates a
report. It should be noted that a report may be generated
as the result of a query, or may be generated as the result
of specific protocol mechanisms.
このパラメタは、コマンドがStatus要求かそれともStatusレポートであるかを示します。 それは単独のASCII文字から成ります。 Qは要求(質問)を示します、そして、Rはレポートを示します。 レポートが質問の結果として作られるか、または特定のプロトコルメカニズムの結果として作られるかもしれないことに注意されるべきです。
Protocol-Idiosyncratic Parameters
プロトコル特有のパラメタ
The parameters to the status command are
protocol-idiosyncratic. That is, each protocol off-loaded has a
set of these parameters. The default value for these
parameters is their previous values. Among these parameters is
an identifier of the type of status information contained or
requested, and a value or set of values that contain the
particular status information. The status information itself
should be the last item in the command. The control flag for
this set of parameters is -pi, which identifies the first
protocol-idiosyncratic parameters. Control flags for other
protocol-idiosyncratic parameters must be defined for each
off-loaded protocol.
状態コマンドへのパラメタはプロトコル特有です。 積み下ろされたすなわち各プロトコルはこれらのパラメタのセットを持っています。 これらのパラメタのためのデフォルト値はそれらの前の値です。 これらのパラメタの中に、特定の状態情報を含む値の情報が含んだか、または要求した状態のタイプに関する識別子と、値かセットがあります。 状態情報自体はコマンドで最後の項目であるべきです。 このセットのパラメタのための指揮旗はパイです。(そのパイは最初のプロトコル特有のパラメタを特定します)。 それぞれの積み下ろされたプロトコルのために他のプロトコル特有のパラメタのための指揮旗を定義しなければなりません。
Responses
応答
The following responses have been identified for the Status
command:
以下の応答はStatusコマンドのために特定されました:
000 Command completed successfully
201 Command not appropriate
300 Problem with multiple chunks
301 Syntax problem with Command
302 Inappropriate status request
303 Inappropriate status response
401 Protocol Interpreter in OPE not responding
402 Failure in remote protocol interpreter
403 Failed; insufficient protocol interpreter resources
501 Failed; insufficient OPE resources
601 Request violates security policy
9xx Protocol Idiosyncratic status responses
000 コマンドはリモートプロトコルインタプリタ403Failedで402Failureを反応させないことでOPEでCommand302Inappropriate状態要求303Inappropriate状態応答401プロトコルInterpreterに関する複数の塊301Syntax問題で首尾よく適切な300Problemではなく、201Commandを完成しました。 不十分なプロトコルインタプリタリソース501Failed。 不十分なOPEリソース601Requestは安全保障政策9xxプロトコルIdiosyncratic状態応答に違反します。
Lilienkamp & Mandell & Padlipsky [Page 27]
Lilienkamp、マンデル、およびPadlipsky[27ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
Example of Status Command
状態コマンドに関する例
The status command can be particularly complex, depending on
the protocol and particular type of status information. One
possible use of the status command when off-loading TCP is to
communicate the status service request. For performing this
operation the status command would be:
プロトコルと特定のタイプの状態情報によって、状態コマンドは特に複雑である場合があります。 状態コマンドの1つの活用可能性はTCPを積み下ろすとき、状態サービスのリクエストを伝えることです。 この操作を実行するために、状態コマンドは以下の通りでしょう。
C ST Q <nl>
C、Q<nl第>。
Notes to the Implementor
作成者への注意
End
終わり
Purpose of the End Command
終わりのコマンドの目的
The purpose of the End command is to communicate that services
of the off-loaded protocol are not required. The semantics of
the End command depends upon whether it was issued by the Host
or the OPE.
積み下ろされたプロトコルのサービスがそうであるコマンドが伝えることになっているEndの目的は必要ではありません。 Endコマンドの意味論はそれがHostかOPEによって発行されたかどうかによります。
- If the Host issues the End command, it means the process in
the Host no longer requires the services of the offloaded
protocol.
- HostがEndコマンドを発行するなら、それは、Hostのプロセスがもう積み下ろされたプロトコルのサービスを必要としないことを意味します。
- If the OPE issues the End command, it means the remote entity
has no more data to send (e.g., the off-loaded protocol is TCP
and the remote user has issued a TCP close).
- OPEがEndコマンドを発行するなら、それは、リモート実体には送らないそれ以上のデータが全くあることを(例えば、積み下ろされたプロトコルがTCPです、そして、リモート・ユーザーは近くでTCPを発行しました)意味します。
Parameters of the End Command
終わりのコマンドのパラメタ
One parameter is associated with the End Command. It indicates
whether the termination should be "graceful" or "abrupt" (see
below).
1つのパラメタがEnd Commandに関連しています。 それは、終了が「優雅である」か「突然であるべきであるか」を(以下を見てください)示します。
Graceful/Abrupt
優雅であるか、または突然です。
The Graceful/Abrupt parameter indicates whether the End
should be handled gracefully or abruptly. If it is handled
gracefully, then data in transit is allowed to reach its
destination before service is actually terminated. An
abrupt End occurs immediately; all data transmitted from the
Host but still pending in the OPE is discarded, and no new
incoming data is sent to the Host from the OPE.
Graceful/ぶっきら棒なパラメタは、Endが優雅か突然に扱われるべきであるかどうかを示します。 それが優雅に扱われるなら、サービスが実際に終えられる前にトランジットにおけるデータは目的地に到着できます。 突然のEndはすぐに、起こります。 Hostから伝えられましたが、OPEでまだ未定のすべてのデータが捨てます、そして、どんな新しい受信データもOPEからHostに送りません。
Lilienkamp & Mandell & Padlipsky [Page 28]
Lilienkamp、マンデル、およびPadlipsky[28ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
The parameter is indicated by a single ASCII character. The
character "G" denotes graceful, and "A" denotes abrupt. The
default value for this parameter is graceful.
パラメタは単独のASCII文字によって示されます。 キャラクタ「G」が指示する、優雅である、「A」、指示、突然です。 このパラメタのためのデフォルト値は優雅です。
Responses
応答
The following responses have been identified for the End
command:
以下の応答はEndコマンドのために特定されました:
000 Command completed successfully
201 Command not appropriate
300 Problem with multiple chunks
301 Syntax problem with Command
302 Illegal Type of End Command
401 Protocol Interpreter in OPE not responding
402 Failure in remote protocol interpreter
403 Failed; insufficient protocol interpreter resources
501 Failed; insufficient OPE resources
601 Request violates security policy
000 コマンドはリモートプロトコルインタプリタ403Failedで402Failureを反応させないことでOPEでEnd Command401プロトコルInterpreterのCommand302Illegal Typeに関する複数の塊301Syntax問題で首尾よく適切な300Problemではなく、201Commandを完成しました。 不十分なプロトコルインタプリタリソース501Failed。 不十分なOPEリソース601Requestは安全保障政策に違反します。
Additionally, protocol idiosyncratic responses will be defined
for each off-loaded protocol.
さらに、特有の応答が定義されるプロトコルはそれぞれプロトコルを積み下ろしました。
Example of End Command
終わりのコマンドに関する例
The syntax of the End command is relatively straightforward. It
consists of a chunk that contains only a chunk usage
identifier, the end command string, and the parameter
indicating whether the end should be graceful or abrupt. A
possible valid (abrupt) End command would be:
Endコマンドの構文は比較的簡単です。 それは終わりが優雅であるか、または突然であるべきであるかを示す塊用法識別子、終わりのコマンドストリング、およびパラメタだけを含む塊から成ります。 可能な有効な(突然の)終わりのコマンドは以下の通りでしょう。
C EN A <nl>
Cアンは<nl>です。
Notes to the Implementor
作成者への注意
Once an End has been issued in a given direction any other
commands on the channel in the same direction are in error and
should be responded to appropriately.
Endがいったん与えられた方向に発行されると、同じ方向へのチャンネルにおけるいかなる他のコマンドにも間違って、適切に応じるべきです。
Lilienkamp & Mandell & Padlipsky [Page 29]
Lilienkamp、マンデル、およびPadlipsky[29ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
No-op
オプアートがありません。
Purpose of the No-op Command
オプアートがないコマンドの目的
The No-op command performs no operation. Its purpose is to
permit the Host and OPE to participate in a dialog which does
not alter the state of communication activities, both for
debugging purposes and to support features of certain protocols
(e.g., Telnet's Are You There command).
オプアートがないコマンドは操作を全く実行しません。 目的がHostとOPEがともにコミュニケーション活動の状態を変更しない対話に参加して、デバッグ目的、あるプロトコルの特徴をサポートすることを許可することである、(例えば、TelnetのAre、あなた、Thereコマンド)
Parameters of the No-op Command
オプアートがないコマンドのパラメタ
There are no parameters associated with the No-op command.
オプアートがないコマンドに関連しているどんなパラメタもありません。
Responses
応答
There are only two possible legal responses to the No-op
command. They are:
オプアートがないコマンドへの2つの可能な法的な応答しかありません。 それらは以下の通りです。
000 No-op Command Completed Correctly
300 Problem with multiple chunks
000 複数の塊があるオプアートがないCommand Completed Correctly300Problem
Example of No-op Command
オプアートがないコマンドに関する例
Syntactically the No-op command is quite simple. It consists
of a chunk that contains only the chunk usage identifier and
the string for the command, and the newline. One possible
valid No-op command is:
シンタクス上、オプアートがないコマンドはかなり簡単です。 それはコマンド、およびニューラインのための塊用法識別子とストリングだけを含む塊から成ります。 1つの可能な有効なオプアートがないコマンドは以下の通りです。
C NO <nl>
<のnlのCノー>。
Notes to the Implementor
作成者への注意
No-ops are included for use in testing and initial
synchronization. (The latter use is not mandatory, however.
That is, no exchange of No-ops is required at start-up time,
but it is conceivable that some implementations might want to
do it just for exercise.) They are also traditional.
オプアートは全くテストと初並列における使用のために含まれていません。 しかしながら、後者の使用は義務的ではありません。(すなわち、オプアートがない交換は全く準備期間に必要ではありませんが、いくつかの実装がまさしく運動のためにそれをしたがっているのが想像できます。) また、それらも伝統的です。
Lilienkamp & Mandell & Padlipsky [Page 30]
Lilienkamp、マンデル、およびPadlipsky[30ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
References
参照
(References [1]-[3] will be available in M. A. Padlipsky's "The Elements of Networking Style", Prentice Hall, 1985.)
(参照[1]--[3]はM. A. Padlipsky「ネットワーク様式のElements」、Prentice Hall、1985で利用可能になるでしょう。)
[1] Padlipsky, M. A., "The Host-Front End Protocol Approach", MTR-3996, Vol. III, MITRE Corp., 1980.
[1]Padlipsky、M.A.、「ホストフロントエンドプロトコルアプローチ」、MTR-3996、Vol.III、斜め継ぎ社、1980。
[2] Padlipsky, M. A., "The Elements of Networking Style", M81-41, MITRE Corp., 1981.
[2]Padlipsky、M.A.、「ネットワーク様式のElements」、M81-41、斜め継ぎ社、1981。
[3] Padlipsky, M. A., "A Perspective on the ARPANET Reference Model", M82-47, MITRE Corp., 1982.
[3]Padlipsky、M.A.、「アルパネット規範モデルの上の見解」、M82-47、斜め継ぎ社、1982。
[4] Bailey, G., "Network Access Protocol", S-216,718, National Security Agency Central Security Service, 1982.
[4] べイリー、G.、「ネットワークアクセス・プロトコル」、S-216,718、国家安全保障局の主要なセキュリティー・サービス、1982。
[5] Day, J. D., G. R. Grossman, and R. H. Howe, "WWMCCS Host to Front End Protocol", 78012.C-INFE.14, Digital Technology Incorporated, 1979.
[5]日、J.D.、G.R.グロースマンとR.H.ホウ、「フロントエンドプロトコルへのWWMCCSホスト」78012.C-INFE.14、法人組織のデジタル技術、1979。
Lilienkamp & Mandell & Padlipsky [Page 31]
Lilienkamp、マンデル、およびPadlipsky[31ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
APPENDIX
付録
Per-Protocol Offloading Descriptions
記述を積み下ろすプロトコル
1. Command Level Interface to an Off-loaded TCP
1. 積み下ろされたTCPに平らなインタフェースを命令してください。
This appendix discusses the use of the commands described in the
body of this document to provide an interface between a Host
process and an off-loaded interpreter of the DoD's Transmission
Control Protocol (TCP). The interface described here is
functionally equivalent to the interface found in the MIL-STD 1778
specification of TCP. It is not, however, identical, in that some
features of the interface are particularly relevant only in an
inboard implementation.
この付録はDoDの通信制御プロトコル(TCP)のHostプロセスと積み下ろされたインタプリタとのインタフェースを提供するためにこのドキュメントのボディーで説明されたコマンドの使用について議論します。 ここで説明されたインタフェースはTCPの軍規格1778仕様で見つけられたインタフェースに機能上同等です。 しかしながら、それはインタフェースのいくつかの特徴が機内の実装だけで特に関連しているという点が同じではありません。
The first section describes the mapping between the interface
events of MIL-STD 1778 and the commands and responses of this
H-FP, and highlights the unique features of the interface. The
next sections discuss the details of each command. These details
include the specialized usages of the command and the
protocol-idiosyncratic parameters for that command.
最初のセクションは、このH-FPの軍規格1778のインタフェースイベントと、コマンドと応答の間のマッピングについて説明して、インタフェースのユニークな特徴を目立たせます。 次のセクションはそれぞれのコマンドの詳細について論じます。 これらの詳細はコマンドの専門化している用法とそのコマンドのためのプロトコル特有のパラメタを含んでいます。
1.1. Relation to MIL-STD 1778 Interface
1.1. 1778年の軍規格インタフェースとの関係
Most of the requests and responses of the TCP interface
specified in MIL-STD 1778 are mapped directly to H-FP Commands
and responses. The exceptions are noted in the following
descriptions.
軍規格1778で指定されたTCPインタフェースの要求と応答の大部分は直接H-FP Commandsと応答に写像されます。 以下の記述で例外に注意します。
1.1.1. Requests
1.1.1. 要求
Unspecified Passive Open, Fully Specified Passive Open,
Active Open, and Active Open with Data requests are all
implemented using variations of the Begin command. The
distinction between Passive and Active Open is made using
the Active/Passive parameter of Begin. The distinction
between unspecified and fully specified lies in the presence
or absence of the destination address fields. An active
open with data is identical to a normal active open, except
for the presence of data following the command.
Data要求による不特定のPassiveオープン、Fully Specified Passiveオープン、Activeオープン、およびActiveオープンは、Beginコマンドの変化を使用することですべて実装されます。 BeginのActive/受け身のパラメタを使用することでPassiveとActiveオープンの区別をします。 目的地アドレス・フィールドの存在か欠如には不特定で完全に指定されているところの区別があります。 データがあるアクティブな戸外は正常なアクティブな戸外と同じです、コマンドに続くデータの存在を除いて。
The Send Service Request is implemented using the Transmit
command. Special protocol idiosyncratic parameters are
provided for Urgent, Push, and changing the ULP timeout
action and values. The response to the Transmit command
indicates that the appropriate Send call has been made.
Send Service Requestは、Transmitコマンドを使用することで実装されます。 Urgent、Push、ULPタイムアウト動作を変えて、および値に特別なプロトコル特有のパラメタを提供します。 Transmitコマンドへの応答は、適切なSend電話をかけたのを示します。
Lilienkamp & Mandell & Padlipsky [Page 32]
Lilienkamp、マンデル、およびPadlipsky[32ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
There is no corresponding response in the specified TCP
interface; its only significance is that the Host can issue
another Transmit command.
どんな対応する応答も指定されたTCPインタフェースにありません。 唯一の意味はHostが別のTransmitコマンドを発行できるということです。
The Allocate event is a specification feature of MIL-STD
1778 to indicate the willingness of the user to accept
incoming data across the interface. However, because this
is precisely the type of flow control provided by the
Channel level, the Allocate event would be a superfluous
mechanism. Thus, there is no direct analogy to that event
in the H-FP interface. A Host process indicates its
willingness to accept new data by informing the channel via
its flow control interface (if it has an explicit one).
Allocateイベントは軍規格1778がユーザがインタフェースの向こう側に受信データを受け入れる意欲を示す仕様機能です。 しかしながら、これが正確に英仏海峡レベルによって提供されたフロー制御のタイプであるので、Allocateイベントは余計なメカニズムでしょう。 したがって、そのイベントへのどんなダイレクト類推もH-FPインタフェースにありません。 Hostプロセスはフロー制御インタフェースを通してチャンネルに知らせることによって新しいデータを受け入れる意欲を示します(それに明白なものがあるなら)。
Close and Abort are provided by the End command. Close uses
the graceful version of the End command, while Abort uses
the abrupt version. The response indicates that the End
command has been received and the corresponding Close or
Abort was issued. There is no corresponding response in the
specified TCP interface.
Endコマンドで閉鎖とAbortを提供します。 閉鎖はEndコマンドの優雅なバージョンを使用しますが、Abortは突然のバージョンを使用します。 応答はEndコマンドを受け取って、対応するCloseかAbortを発行したのを示します。 どんな対応する応答も指定されたTCPインタフェースにありません。
Status is provided by using the query form of the Status
command. The response to the Status command contains the
information (see below).
Statusコマンドの質問フォームを使用することによって、状態を提供します。 Statusコマンドへの応答は情報を含んでいます(以下を見てください)。
1.1.2. Responses
1.1.2. 応答
The Open Id response is provided so that the user has a
shorthand name by which to refer to the connection. With an
outboarded TCP interpreter, there is a one-to-one mapping
between TCP connections and H-FP channels. Hence, the Open
Id event is not needed, since the channel ID is sufficient
to indicate the desired connection.
オープンId応答を提供するので、ユーザには、接続について言及する速記名があります。 outboarded TCPインタプリタと共に、TCP接続とH-FPチャンネルの間には、1〜1つのマッピングがあります。 したがって、チャンネルIDが必要な接続を示すために十分であるので、オープンIdイベントは必要ではありません。
The Open Failure and Open Success responses are provided
using OPE-generated responses to Begin commands (which
provide the Active and Passive Service response primitives)
issued by the Host. The value of the response code
indicates whether the Begin command succeeded or failed, and
can be mapped to the appropriate Open Failure or Open
Success indication by the Host.
Hostによって発行されたBeginコマンド(ActiveとPassive Serviceに応答プリミティブを供給する)へのOPEが発生している応答を使用することでオープンFailureとオープンSuccess応答を提供します。 応答コードの値は、Beginコマンドに引き継がれるか、または失敗して、Hostが適切なオープンFailureかオープンSuccess指示に写像できるかどうかを示します。
Deliver is provided by having the OPE issue a Transmit
command. As mentioned above, the "flow control" between the
TCP interpreter and the Host is provided by the Channel
layer, so no explicit interface events are needed. The
配送してください。OPE問題を持っているのによるTransmitコマンドを提供します。 以上のように、英仏海峡層のそばでTCPインタプリタとHostの間の「フロー制御」を提供するので、どんな明白なインタフェースイベントも必要ではありません。 The
Lilienkamp & Mandell & Padlipsky [Page 33]
Lilienkamp、マンデル、およびPadlipsky[33ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
response to the Transmit command indicates the data was
received by the Host process. There is no corresponding
response in the specified TCP interface.
Transmitコマンドへの応答は、データがHostプロセスによって受け取られたのを示します。 どんな対応する応答も指定されたTCPインタフェースにありません。
The Closing and Terminate service responses are provided
using the End command. Closing is indicated using the
graceful version of the command, while terminate is provided
using the abrupt version. The response indicates the End
command was received by the Host process. There is no
corresponding response in the specified TCP interface.
Endコマンドを使用することでClosingとTerminateサービス応答を提供します。 終わってください。閉鎖がコマンドの優雅なバージョンを使用することで示される、突然のバージョンを使用することで、提供します。 応答は、EndコマンドがHostプロセスによって受け取られたのを示します。 どんな対応する応答も指定されたTCPインタフェースにありません。
Status Response is provided by a response to the query
version of the Status command. The status information is
communicated via protocol-idiosyncratic parameters following
the Response code.
Statusコマンドの質問バージョンへの応答で状態Responseを提供します。 Responseコードに従って、状態情報はプロトコル特有のパラメタで伝えられます。
Error messages are reported using the spontaneously
generated version of the Status command issued by the OPE.
The error message is provided in a parameter. The response
indicates the error message was received by the Host
process. There is no corresponding event in the specified
TCP interface.
エラーメッセージは、OPEによって発行されたStatusコマンドの自然に生成しているバージョンを使用することで報告されます。 エラーメッセージをパラメタに提供します。 応答は、エラーメッセージがHostプロセスによって受け取られたのを示します。 どんな対応するイベントも指定されたTCPインタフェースにありません。
1.2. The Begin Command
1.2. 始まりコマンド
The Begin command is used in TCP in three major ways:
BeginコマンドはTCPで3つの主要な方法で使用されます:
1. To inform the OPE that a process in the Host wishes to
open a connection to a particular port on a internet
address.
1. HostのプロセスがそうしたがっていることをOPEに知らせるには、インターネット住所の指定港に接続を開いてください。
2. To inform the OPE that a process in the Host wishes to be
informed when a connection attempt is made to any or to a
specific port at this Host's internet address.
2. 接続試みであるときに知識があるというHost願望におけるプロセスをいずれも、または、このHostのインターネット住所の特定のポートにすることをOPEに知らせるために。
3. To inform the Host that a connection attempt to the OPE
has arrived, and there was no Begin of the second type
(passive open) issued by the Host relevant to that
particular port.
3. OPEへの接続試みが到着して、2番目のBeginが全くなかったことをHostに知らせるには、その指定港に関連しているHostによって発行された(受け身の戸外)をタイプしてください。
1.2.1. Specialized Usage
1.2.1. 専門化している用法
There are four major aspects to the specialized usage of the
Begin command and its parameters. These parameters are:
Beginコマンドとそのパラメタの専門化している用法への4つの主要な局面があります。 これらのパラメタは以下の通りです。
1. The meaning of the Mediation Level parameter
1. Mediation Levelパラメタの意味
Lilienkamp & Mandell & Padlipsky [Page 34]
Lilienkamp、マンデル、およびPadlipsky[34ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
2. The selection of blocking treatment of Transmit
command
2. Transmitコマンドのブロッキング処理の選択
3. The meaning of the address components
3. アドレス構成要素の意味
4. The selection of the TCP Active Open with Data
primitive.
4. Dataが原始的のTCP Activeオープンの選択。
The Mediation Level parameter has only two possible values
when offloading TCP. These are "9" and "0". The normal
usage of an off-loaded TCP uses the value "9", which means
the Host is in no way involved in the operation of TCP. The
value "0" indicates the Host wishes to negotiate with the
TCP options.
TCPを積み下ろすとき、Mediation Levelパラメタには、2つの可能な値しかありません。 これらがそうである、「9インチと「0インチ。」 積み下ろされたTCPの正常な使用法は値「9インチ」を使用します。(9インチはホストがTCPの操作に決してかかわらないことを意味します)。 「TCPオプションと交渉0インチがホストを示すしたがっている」値。
The normal TCP Send event is non-blocking. That is, when a
user issues the send command, it counts on the reliability
services of TCP, and is not explicitly notified when the
data has reached the other end of the connection and been
properly acknowledged. Hence, the default value for this
parameter with TCP is "N". There are some applications
where the user may not wish to receive a response to a
Transmit command until the data has been acknowledged by the
other end of the connection. In these cases, the value "B"
should be used for this parameter. If such a feature is not
supported by the offloaded TCP interpreter, then it is
acceptable to issue a 100 level Conditional acceptance
indicating that blocking is not supported, but the Begin
command will proceed using non-blocking Transmits.
正常なTCP Sendイベントは非ブロッキングです。 すなわち、ユーザが発信コマンドを発行するとき、それは、TCPの信頼性のサービスを頼りにして、データが接続のもう一方の端に達して、適切に承認されたとき、明らかに通知されません。 したがって、TCPがあるこのパラメタのためのデフォルト値は「N」です。 いくつかの利用がデータが接続のもう一方の端までに承認されるまでユーザがTransmitコマンドへの応答を受けたがっていないかもしれないところにあります。 これらの場合では、値「B」はこのパラメタに使用されるべきです。 そのような特徴が積み下ろされたTCPインタプリタによってサポートされないならブロッキングがサポートされないのを示す100の平らなConditional承認を発行するのが許容できますが、Beginコマンドは、非ブロッキングTransmitsを使用することで続くでしょう。
The primary address components of the local and remote
addresses refer to the internet addresses of (or a symbolic
Host name for) the respective Hosts. The secondary
components refer to the particular sockets at those internet
addresses. Normally, the secondary components (ports) are
specified numerically. They may, however, be specified by
name if the port is a well-known service port. In an Active
Begin command, the remote addresses primary and secondary
components must be specified. The local address components
need not be specified, unless the user wishes to indicate
that the connection should be from a particular port or a
particular internet address of a multi-homed Host. In a
Passive Begin command, the remote addresses are specified
only if connection attempts from one particular Host are of
interest. The local address secondary component must be
used to indicate on which port to perform the Listen.
地方の、そして、リモートなアドレスのプライマリアドレス構成要素がインターネットアドレスを参照する、(シンボリックなHost名、)、それぞれのHosts。 伴星はそれらのインターネットアドレスの特定のソケットについて言及します。 通常、伴星(ポート)は数の上で指定されます。 しかしながら、それらはポートがよく知られるサービスポートであるなら名前によって指定されるかもしれません。 Active Beginコマンド、プライマリの、そして、セカンダリの構成要素がそうしなければならないリモートアドレスでは、指定されてください。 ローカルアドレスコンポーネントは指定される必要はありません、ユーザが、接続が指定港かaの特定のインターネットアドレスからそう来ているべきであるのを示したくない場合マルチ、家へ帰り、Host。 Passive Beginコマンドでは、1特定のHostからの接続試みは興味がある場合にだけ、リモートアドレスが指定されます。 ローカルアドレス伴星はListenを実行するためにどのポートの上で示すかに使用されているに違いありません。
Lilienkamp & Mandell & Padlipsky [Page 35]
Lilienkamp、マンデル、およびPadlipsky[35ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
The way the TCP Active Open with data is provided is by
including the data with the Begin Command. This data is
included in the same Channel level chunk, immediately
following the newline. If the data is more than a single
chunk can hold, then the multi-chunk command feature of the
H-FP must be used.
データがあるTCP Activeオープンを供給する方法はBegin Commandがあるデータを含んでいることです。 すぐにニューラインに続いて、このデータは同じChannelの平らな塊に含まれています。 データが1以上であるなら、ただ一つの塊は成立できて、次に、H-FPのマルチ塊コマンド機能を使用しなければなりません。
1.2.2. Protocol-Idiosyncratic Parameters
1.2.2. プロトコル特有のパラメタ
The protocol-idiosyncratic parameter identified for the TCP
interface is the "ULP timeout" information. This
information includes whether the offloaded interpreter
should abort the connection on a ULP timeout or report it to
the inboard user, and also the numerical value of the
timeout interval. The format chosen for this parameter is a
single letter followed immediately (with no spaces) by an
ASCII number. The letter can be either "R" or "A", and
indicates that the ULP timeout should cause a report or an
abort, respectively. The number is interpreted to be the
timeout interval in seconds.
TCPインタフェースに特定されたプロトコル特有のパラメタは「ULPタイムアウト」情報です。 この情報は、積み下ろされたインタプリタがULPタイムアウトで接続を中止するはずであるか、または機内のユーザ、およびタイムアウト間隔の数値にもそれを報告するはずであるかを含んでいます。 このパラメタに選ばれた形式はASCII番号がすぐに(空間なしで)いうことになったただ一つの手紙です。 手紙は、「R」か「A」のどちらかであることができ、ULPタイムアウトがそれぞれレポートかアボートを引き起こすべきであるのを示します。 数は、秒のタイムアウト間隔になるように解釈されます。
1.2.3. Examples of the Command
1.2.3. コマンドに関する例
An example of an Active Begin command that might be issued
by an inboard user Telnet is:
機内のユーザTelnetによって発行されるかもしれないActive Beginコマンドに関する例は以下の通りです。
C BE TCP A ISIA 9 N 23 ,, 60 R 0 -pi R120 <nl>
C、TCP A ISIA9N23になってください、60R0パイR120<nl>。
ISIA is the destination Host, 23 is the well-known port
number for Telnet connections, a Begin timeout of 60 seconds
was chosen. The desired type of service is to strive for
good response time, the transmissions are expected to be in
small units, and protocol-idiosyncratic parameter R120
implies that a ULP timeout of 120 seconds should be
reported.
ISIAが目的地Hostである、23はTelnet接続(60秒のタイムアウトが選ばれたBegin)のウェルノウン・ポート番号です。 必要なタイプのサービスが良い応答時間の間、努力することであり、トランスミッションが小単位にあると予想されて、プロトコル特有のパラメタR120は、120秒のULPタイムアウトが報告されるべきであるのを含意します。
An example of a Passive Begin Command that might be issued
by an inboard server Telnet is:
機内のサーバTelnetによって発行されるかもしれないPassive Begin Commandに関する例は以下の通りです。
C BE TCP P ,, 9 N ,, 23 ,, R 0 -pi R120 <nl>
C、TCP Pになってください、9N、23、R0パイR120<nl>。
The major differences are that no remote address components
are specified, and the local secondary address component is
identified as the socket on which the Listen is being
performed. Also, the default ("infinite") timeout is taken.
主要な違いはどんなリモートアドレス構成要素も指定されないで、地方のセカンダリアドレス構成要素がListenが実行されているソケットとして特定されるということです。 また、デフォルト(「無限」の)タイムアウトを取ります。
Lilienkamp & Mandell & Padlipsky [Page 36]
Lilienkamp、マンデル、およびPadlipsky[36ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
1.3. The Transmit Command
1.3. 伝えコマンド
The Transmit command is used by the Host process to instruct
the off-loaded TCP interpreter to send data to a remote site
via the TCP connection associated with the command's channel.
It is used by the OPE to deliver incoming data from the
connection to the process in the Host.
TransmitコマンドはHostプロセスによって使用されて、コマンドのチャンネルに関連づけられたTCP接続でデータをリモートサイトに送るよう積み下ろされたTCPインタプリタに命令します。 それは、Hostで接続からプロセスまで受信データを提供するのにOPEによって使用されます。
1.3.1. Specialized Usage
1.3.1. 専門化している用法
The Transmit command must be capable of providing all the
specialized features of the Send and Deliver Event. These
special features are Urgent, Push, and modification of the
ULP Timeout action and/or interval.
TransmitコマンドはSendとDeliver Eventのすべての専門化している特徴を提供できなければなりません。 これらの特徴は、ULP Timeout動作、そして/または、間隔のUrgentと、Pushと、変更です。
Urgent is a means to communicate that some point upcoming in
the data stream has been marked as URGENT by the sender.
While the actual Urgent bit travels through the connection
out-of-band, it carries a pointer that is related to the
sequence numbers of the in-band communication. Hence, the
urgency must be indicated in the Transmit command rather
than the Signal command.
緊急であるのは、交信する今度データ・ストリーム何らかのポイントがURGENTとして送付者によってマークされた手段です。 実際のUrgentビットは接続でバンドの外に移動しますが、それはバンドにおけるコミュニケーションの一連番号に関連する指針を運びます。 したがって、SignalコマンドよりむしろTransmitコマンドで緊急を示さなければなりません。
Push is a feature of the TCP Send Event that is used to
indicate that the data in the Transmit command should be
sent immediately (within the flow control constraints),
rather than waiting for additional send commands or a
timeout. Push is indicated in the Transmit Command. The
push feature has the same meaning when sent from the OPE to
the Host. If the Host implementation does no internal
queuing, the flag has no meaning.
プッシュはTransmitコマンドにおけるデータがすぐに(フロー制御規制の中で)追加発信コマンドかタイムアウトを待っているよりむしろ送られるべきであるのを示すのに使用されるTCP Send Eventの特徴です。 プッシュはTransmit Commandで示されます。 プッシュ機能には、OPEからHostに送ると、同じ意味があります。 Host実装が内部の列を作りでないのをするなら、旗には、意味がありません。
The TCP Send event permits the user to modify the "ULP
timeout action" and/or the "ULP timeout interval" associated
with that connection. When changed, the new values take
effect for the remainder of the connection, unless changed
later with another Send. This feature is provided in this
H-FP using the Transmit Command.
TCP Sendイベントは、ユーザが「ULPタイムアウト動作」、そして/または、その接続に関連している「ULPタイムアウト間隔」を変更することを許可します。 変えて、後で別のSendと共に変えない場合、新しい値は接続の残りのために実施します。 Transmit Commandを使用することでこの特徴をこのH-FPに提供します。
1.3.2. Protocol-Idiosyncratic Parameters
1.3.2. プロトコル特有のパラメタ
The three features identified above are provided using
protocol-idiosyncratic parameters.
プロトコル特有のパラメタを使用することで上で特定された3つの特徴を提供します。
The first such parameter is the Urgent parameter. From the
point of view of the interface, it is just a flag that
indicates the data is urgent (the actual Urgent pointer is a
最初のそのようなパラメタはUrgentパラメタです。 それがただインタフェースの観点からの、データが緊急であることを示す旗である、(実際のUrgent指針はaです。
Lilienkamp & Mandell & Padlipsky [Page 37]
Lilienkamp、マンデル、およびPadlipsky[37ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
concern of the off-loaded TCP interpreter, which is keeping
track of the sequence numbers). When issued by the Host
process, the Urgent flag means the stream should be marked.
When issued by the OPE, it means the receiver should go to
(or remain in) the Urgent receive mode. If the flag is not
set in the Transmit issued by the OPE, then the receiver
should remain in (or return to) the non-urgent receive mode.
The value of this protocol-idiosyncratic parameter is "U" if
the Urgent is set, or "N" if it is not set. The default
value for this parameter is "N". Since this parameter is
the first protocol-idiosyncratic parameter for the Transmit
command, it requires no special flag, and can be indicated
using the flag -pi.
積み下ろされたTCPインタプリタの関心、)。(そのインタプリタは、一連番号の動向をおさえています)。 Hostプロセスによって発行されると、Urgent旗は、ストリームがマークされるべきであることを意味します。 OPEによって発行されると、それは、受信機が(中に残ってください)Urgentにモードを受けに行くはずであることを意味します。 または、旗がOPEによって発行されたTransmitに設定されないなら受信機が中に残っているはずである、(戻る、)、不急はモードを受けます。 緊急が設定されるか、または「N」がそれであるなら設定されないなら、このプロトコル特有のパラメタの値は「U」です。 このパラメタのためのデフォルト値は「N」です。 このパラメタがTransmitコマンドのための最初のプロトコル特有のパラメタであるので、それは、どんな特別な旗も必要としないで、旗パイを使用することで示すことができます。
The second protocol-idiosyncratic parameter is the Push
flag. This parameter is only issued by the Host, since
there is no Push in the TCP Deliver event. Its value is "P"
for push, or "N" for normal. The default value of this
parameter is "N". Its control flag is -pu.
2番目のプロトコル特有のパラメタはPush旗です。 TCP DeliverイベントにはPushが全くないので、このパラメタはHostによって発行されるだけです。 値は、プッシュのための「P」、または標準のための「N」です。 このパラメタのデフォルト値は「N」です。 指揮旗はPuです。
The third protocol-idiosyncratic parameter is the ULP
timeout action and value parameter. The action part
indicates whether the offloaded interpreter should abort the
connection on a timeout or report it to the inboard user.
The value part is the numerical value of the timeout
interval. The format used for this parameter is the same as
in the Begin command, which is a single letter followed
immediately (with no spaces) by an ASCII number. The letter
can be either "R" or "A", and indicates that the ULP timeout
should cause a report or an abort, respectively. The number
is interpreted to be the timeout interval in seconds. The
default interpretation for this parameter is its previous
value. The control flag for this parameter is -ul.
3番目のプロトコル特有のパラメタは、ULPタイムアウト動作と値のパラメタです。 動作部分は、積み下ろされたインタプリタがタイムアウトで接続を中止するはずであるか、または機内のユーザにそれを報告するはずであるかを示します。 値の部はタイムアウト間隔の数値です。 このパラメタに使用される形式はBeginコマンドと同じです。(ASCII番号はすぐに(空間なしで)、ただ一つの手紙であるとそれを、いうことになりました)。 手紙は、「R」か「A」のどちらかであることができ、ULPタイムアウトがそれぞれレポートかアボートを引き起こすべきであるのを示します。 数は、秒のタイムアウト間隔になるように解釈されます。 このパラメタのためのデフォルト解釈はその前の値です。 このパラメタのための指揮旗は-ulです。
1.3.3. Examples of the Command
1.3.3. コマンドに関する例
An example of a Transmit command issued by a Host process is
Hostプロセスによって発行されたTransmitコマンドに関する例はそうです。
C TR -pi N P R160 <nl> <DATA>
C TRパイN P R160<nl><データ>。
where <DATA> is the data contained within the chunk. This
command is for a non-urgent but pushed TCP Send event, that
also resets the timeout action and interval to Report with a
value of 160 seconds. The response mode (i.e., nonblocking)
is derived from the Begin command and not effected by
transmit.
<DATA>が塊の中に含まれたデータであるところ。 このコマンドは不急の、しかし、押されたTCP Sendイベントのためのものです、また、それは160秒の値でタイムアウト動作と間隔をReportにリセットします。 (すなわち、「非-妨げ」)がBeginコマンドを得て、作用しない応答モードは伝わります。
Lilienkamp & Mandell & Padlipsky [Page 38]
Lilienkamp、マンデル、およびPadlipsky[38ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
An example of a Transmit command issued by the OPE is
OPEによって発行されたTransmitコマンドに関する例はそうです。
C TR -pi N <nl> <DATA>
C TRパイN<nl><データ>。
where <DATA> is the data contained within the chunk. This
command is for a non-urgent delivery (presumably, after a
previous Urgent delivery).
<DATA>が塊の中に含まれたデータであるところ。 このコマンドは不急の配送(おそらく後a前のUrgent配送)のためのものです。
1.4. The Condition Command
1.4. 状態コマンド
The Condition command is used to modify the transmission
characteristics of the connection. The parameters that make
sense to modify with TCP are the Transmit Response discipline,
the Type of Service, and the Flow Control Advice.
Conditionコマンドは、接続のトランスミッションの特性を変更するのに使用されます。 TCPと共に変更する意味になるパラメタは、Transmit Response規律と、ServiceのTypeと、Flow Control Adviceです。
1.4.1. Specialized Usage
1.4.1. 専門化している用法
There is no usage of the Condition command with an offloaded
TCP interpreter that is particularly specialized.
Conditionコマンドの用法が全く特に専門にされる積み下ろされたTCPインタプリタと共にありません。
1.4.2. Protocol-Idiosyncratic Parameters
1.4.2. プロトコル特有のパラメタ
There are no protocol-idiosyncratic parameters for the
condition command for the off-loaded TCP. It would be
possible for the ULP timeout action values to be changed
with a condition command. However, this is accomplished
with the Transmit command, which more closely models the
interface specified in MIL-STD 1778. We propose that the
condition command not provide this capability.
積み下ろされたTCPのための状態コマンドのためのどんなプロトコル特有のパラメタもありません。 状態コマンドによると、ULPタイムアウト動作値を変えるのは可能でしょう。 しかしながら、これはTransmitコマンドで達成されます。(より密接に、それは、軍規格1778で指定されたインタフェースをモデル化します)。 私たちは、状態コマンドがこの能力を提供しないよう提案します。
1.4.3. Examples of the Command
1.4.3. コマンドに関する例
An example of the Condition command to change the flow
control advice for a connection is
接続のためにフロー制御アドバイスを変えるConditionコマンドに関する例はそうです。
C CO -fc 1 <nl>
1<のC CO-fc nl>。
which indicates that relatively small transmission units are
now expected.
比較的小さいトランスミッション単位が現在予想されるのを示します。
Lilienkamp & Mandell & Padlipsky [Page 39]
Lilienkamp、マンデル、およびPadlipsky[39ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
1.5. The Signal Command
1.5. 信号コマンド
As we currently understand it, TCP's URGENT feature provides an
INband signal rather than a true out-of-band signal (and at
least one of us deeply regrets this). The actual URGENT bit is
sent out-of-band, but it contains an URGENT pointer which
relates the URGENT to its position in the data stream. The
actual semantics of the URGENT is left to the higher level
protocol (e.g., Telnet says to discard all data up to the
URGENT pointer). Since the Signal command is allowed to cross
a pending Transmit in the H-FP channel, it would be potentially
dangerous to implement the interface to TCP URGENT using the
Signal command since the wrong sequence number could be used as
the urgent pointer. Barring persuasive arguments to the
contrary, it is proposed that Signal should not be used with
TCP.
私たちが現在それを理解しているとき、TCPのURGENTの特徴は本当のバンドで出ている信号よりむしろINband信号を提供します(少なくとも私たちのひとりは深くこれを後悔します)。 実際のURGENTビットをバンドの外に送りますが、それはデータ・ストリームで位置にURGENTに関連するURGENT指針を含んでいます。 URGENTの実際の意味論は、より高い平らなプロトコルに残されます(例えば、TelnetはすべてのデータをURGENT指針まで捨てるために言います)。 H-FPチャンネルでSignalコマンドが未定のTransmitに交差できるので、TCP URGENTにインタフェースを実装するのは緊急の指針として間違った一連番号を使用できたのでSignalコマンドを使用するのにおいて潜在的に危険でしょう。 それと反対に説得力のある議論を禁じて、SignalがTCPと共に使用されるべきでないよう提案されます。
1.6. The Status Command
1.6. 状態コマンド
The Status command maps directly into the TCP Status event when
issued by a Host process. It is also used for the TCP error
event when issued by the OPE. There is currently some question
as to how information from lower protocol levels (e.g., ICMP
error messages) should be reported to TCP users. When these
issues are resolved, there may be other uses for the Status
command. We solicit other ideas for the Status command with
this report.
Hostによって発行されると、直接TCP StatusイベントへのStatusコマンド地図は処理されます。 また、OPEによって発行されると、それはTCP誤りイベントに使用されます。 下側のプロトコルレベル(例えば、ICMPエラーメッセージ)からの情報がどうTCPユーザに報告されるべきであるかに関して現在何らかの質問があります。 これらの問題が解決されているとき、Statusコマンドへの他の用途があるかもしれません。 私たちはこのレポートでStatusコマンドのための他の考えに請求します。
1.6.1. Specialized Usage
1.6.1. 専門化している用法
The major specialized usage of the Status command is to
provide the error reporting service. This usage is a form
of the Status generated by the OPE.
Statusコマンドの主要な専門化している用法は誤りニュース配信を提供することです。 この用法はOPEによって生成されたStatusのフォームです。
1.6.2. Protocol-Idiosyncratic Parameters
1.6.2. プロトコル特有のパラメタ
When used as a TCP Status request (command issued by the
Host process), there are no protocol-idiosyncratic
parameters associated with the Status command. The OPE
response codes the TCP status.
TCP Statusが要求するように(Hostプロセスによって発行されたコマンド)使用される場合、Statusコマンドに関連しているどんなプロトコル特有のパラメタもありません。 OPE応答はTCP状態をコード化します。
When used as a TCP error report (command issued by the OPE),
there is one protocol-idiosyncratic parameter associated
with the Status command. It is an error description in the
form of a text string. It requires no special control flag
since the flag -pi is unambiguous and there are no other
protocol-idiosyncratic parameters.
TCPエラー・レポート(OPEによって発行されたコマンド)として使用されると、Statusコマンドに関連している1つのプロトコル特有のパラメタがあります。 それはテキスト文字列の形においてエラー記述です。 旗パイが明白であり、他のどんなプロトコル特有のパラメタもないので、それはどんな特別な指揮旗も必要としません。
Lilienkamp & Mandell & Padlipsky [Page 40]
Lilienkamp、マンデル、およびPadlipsky[40ページ]
RFC 929 December 1984 Proposed Host-Front End Protocol
RFC929 1984年12月はホストフロントエンドプロトコルを提案しました。
1.6.3. Examples of the Command
1.6.3. コマンドに関する例
An example of the Status command issued by the Host process
to request status information is
Hostプロセスによって発行された、状態情報を要求したStatusコマンドに関する例はそうです。
C ST Q <nl>
C、Q<nl第>。
The status information is returned in the response to the
status command.
状態コマンドへの応答で状態情報を返します。
An example of the Status command issued by the OPE to report
an error from the TCP interpreter is
TCPインタプリタから誤りを報告するためにOPEによって発行されたStatusコマンドに関する例はそうです。
C ST R -pi "Connection already exists" <nl>
C ST Rパイ「接続は既に存在している」<nl>。
which is issued when a TCP open (HFP Begin) is issued to an
already opened (foreign) connection.
開いているTCP(HFP Begin)が既に開かれた(外国)接続に発行されるとき、発行されます。
1.7. The End Command
1.7. 終わりのコマンド
The End command is used to indicate that TCP services are no
longer required. Thus, it can be mapped into either the TCP
Graceful Close or the TCP Abort events. It is also used as the
TCP Closing response (as contrasted with the response by the
OPE to the close command), when issued by the OPE.
Endコマンドは、TCPサービスはもう必要でないことを示すのに使用されます。 したがって、TCP Graceful CloseかTCP Abortイベントのどちらかにそれを写像できます。 また、それはTCP Closing応答(閉鎖コマンドへのOPEによる応答と比べて)として使用されます、OPEによって発行されると。
1.7.1. Specialized Usage
1.7.1. 専門化している用法
一覧
スポンサーリンク
