RFC928 日本語訳
0928 Introduction to proposed DoD standard H-FP. M.A. Padlipsky. December 1984. (Format: TXT=60461 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. A. Padlipsky
Request for Comments: 928 Mitre Corp.
December 1984
A.Padlipskyがコメントのために要求するワーキンググループM.をネットワークでつないでください: 928 斜め継ぎ社の1984年12月
INTRODUCTION TO PROPOSED DOD STANDARD H-FP
提案されたDOD標準のH-fpへの序論
Status Of This Memo
このメモの状態
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-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。
Important Prefatory Note
重要な巻頭言
The broad outline of the Host-Front End Protocol introduced here and described in RFC 929 is the result of the deliberations of a number of experienced H-FP designers, who sat as a committee of the DoD Protocol Standards Technical Panel under the author's chairmanship. The particular protocol to be described is, however, the result of the deliberations of a small, ad hoc group, who sat as a de facto subcommittee of the H-FP committee, also under the author's chairmanship. The protocol, then, follows the consensus of the full group as to what the new H-FP should "look like," but has not benefitted from painstaking study by a large number of experienced H-FP designers and implementers. (It has been looked at before release as an RFC by several of them, though.) Even if that were not the case, it would still be the intent of the designers that the protocol be subjected to multiple test implementations and probable iteration before being agreed upon as any sort of "standard". Therefore, the first order of business is to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second order of business is to request that any readers of these documents who are able to do test implementations (a) do so and (b) coordinate their efforts with the author (617-271-2978 or Padlipsky@USC-ISI.ARPA.).
ここで紹介されて、RFC929で説明されたHost-前部Endプロトコルの広いアウトラインは多くの経験豊富なH-FPデザイナーの熟考の結果です。(そのデザイナーは、DoDプロトコルStandards Technical Panelの委員会として作者の議長職の下で座りました)。 しかしながら、説明されるべき特定のプロトコルはH-FP委員会の事実上の小委員会として開会した小さくて、臨時のグループの熟考の結果です、作者の議長職の下でも。 プロトコルは、次に、新しいH-FPが「似ているはずである」ことに関して完全なグループのコンセンサスに続きますが、多くの経験豊富なH-FPデザイナーとimplementersで勤勉な研究の利益を得ていません。 (もっとも、それはリリースの前にRFCとして彼らの数個が見られました。) それがそうでなかったとしても、そうでしょうに、それでも、プロトコルがいるデザイナーの意図が倍数にかけられたなら、どんな種類の「規格」としても同意される前に実現とありえそうな繰り返しをテストしてください。 したがって、最初の議題がA FINAL STANDARD、および2番目の議題ではなく、THIS IS A PROPOSALが、テスト実現(a)ができるこれらのドキュメントのどんな読者もそうするよう要求することになっていると宣言することであり、(b) 座標は作者(617-271-2978か Padlipsky@USC-ISI.ARPA )との彼らの努力です。
Historical/Philosophical Context
歴史的であるか哲学的な関係
Late in May of 1971, the author was presenting a status report on whether the Multics ARPANET implementation would be ready by the July 1 deadline declared by the sponsor earlier that month. Some controversy developed over the fact that the Multics "NCP" (Network Control Program--actually a blanket term covering the Host-Host and Host-IMP protocol interpreters) did not queue requests for connections. As the specification explicitly declared the topic to be one of implementors' choice, the author attempted to avoid the argument by asking the interrogator what he was up to these days. The answer was, "Oh, I'm working on the High-Speed Modular IMP now" (later the Pluribus IMP). And the proverbial coin dropped: The author replied, "I've got a great idea. Now that we've got some space to program in the IMP, why don't we separate out most of the
1971年5月遅く、作者はMulticsアルパネット実現がその月の上旬にスポンサーによって宣言された7月1日締め切りで準備ができるだろうかどうかに関する現状報告を提示していました。 何らかの論争がMultics「NCP」(ネットワーク・コントロール・プログラム--実際にホスト兼ホストとホスト悪童プロトコルインタプリタに関する毛布用語)が接続を求める要求を列に並ばせなかったという事実の上で展開しました。 仕様が、話題が作成者の選択の1つであると明らかに宣言したとき、作者は、最近まで彼が何であったかを質問者に尋ねることによって議論を避けるのを試みました。 答えが「おお、私は現在、High-速度Modular IMPに勤めています」ということであった、(後である、Pluribus IMP) そして、ことわざのコインは低下しました: 作者は、「私には、すばらしい考えがあります。」と返答しました。 IMPでプログラムを作るために何らかのスペースがあるので、私たちはなぜ最も分離しないか。
Padlipsky [Page 1]
Padlipsky[1ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
NCP and do it outboard: the only thing that really matters in the Host is associating sockets with processes, and if we had common implementations of all the bit-diddling stuff in the IMPs, we wouldn't have disputes over the interpretation of the spec and we'd also save a lot of Host CPU cycles!"
そして、NCP、船外でそれをしてください: 「唯一の本当にHostで重要なものがソケットを過程に関連づけています、そして、私たちにIMPsでのすべてのビットをだますものの一般的な実現があるなら、仕様の解釈に関する論争がないでしょうに、そして、また、私たちはHost CPU何サイクルも節約します!」
As far as the author knows, that incident was the beginning of what came to be called "Network Front-Ends" and, more recently, "Outboard Processing Environments." (The name change, by the way, was motivated by a desire to prevent further confusion between NETWORK Front Ends--always conceived of as distributed processing mechanisms for the offloading of intercomputer networking protocols from Hosts--and traditional communications front-ends, which have no connotation of bearing protocol interpreters invokable by Host-side programs.) At least, the idea was original to him and he later was a principal designer and the primary author of the first Host-Front End Protocol. So, on the one hand, the present document might be marred for some readers by undertones of parental pride, but on the other hand, if you like primary sources....
作者が知っている限り、その事件は何が「ネットワークフロントエンド」と、より最近「船外の処理環境」と呼ばれるようになったかに関する始めでした。 (改名はNETWORK Front Ends(intercomputerネットワーク・プロトコルの陸揚のための分散処理メカニズムとしてHostsからいつも想像される)の間のさらなる混乱を防ぐ願望と伝統的なコミュニケーションフロントエンドによってところで、動機づけられました。)(ベアリングプロトコルインタプリタの含蓄は全くフロントエンドによってHost-サイドプログラムで「呼び出-可能」されません)。 後で、彼は、最初のHost-前部Endプロトコルの彼にとって、アイデアが少なくとも、オリジナルであり、主要なデザイナーと第一の作者でした。 そのように、一方では、しかし、他方では、現在のドキュメントは何人かの読者のために親のプライドの低音によって損なわれるかもしれません、あなたが一次資料が好きであるなら…
The evolution of the outboard processing idea has been dealt with elsewhere [1]. For present purposes, it should suffice to observe that some half-a-dozen implementors of "NFE's" of various sorts are known to the author to have met with success. The topic of why use an explicit protocol in the first place (as opposed to emulating a device, or devices, already known to the Host/operating system) deserves a word or two here, however. ([2] deals with it in more general terms.) The crucial consideration is that in the general case you wind up "not doing real networking" if you attach a Host to a network by known device emulation, where real networking is taken to mean what has been called "resource sharing" in the ARPANET literature, and what appears to be dubbed "open system interconnection" in the ISO literature: Operating systems' built-in assumptions about known devices--whether terminals, terminal controllers, or RJE stations--tend to get in the way of the sort of process-process and eventually procedure-procedure communications that serve as the basis for applications more interesting than simple remote login. To those unfamiliar with the outboard processing approach, the premise that the way to attach is via an explicit protocol may be difficult to accept, but to those who have done it, it makes almost perfect sense.
船外の処理考えの発展はほかの場所で対処されました。[1]。 現在の目的のために、それは十分であるべきです。十分であって、様々な種類の「NFEのもの」のおよそ半ダース人の作成者が成功を得たのが作者にとって知られているのを観測してください。 話題、なぜ第一に、明白なプロトコルを使用するか(既に知られていた装置、または装置を見習うことと対照的にHost/オペレーティングシステム) より一般的な用語で. それとの単語かしかしながら、ここのふたり、([2]取引に値します。)。 重要な考慮は本当のネットワークが何がアルパネット文学に「リソース・シェアリング」と呼ばれるか、そして、何がISO文学に「開放形システム相互接続」と呼ばれると載っているかを意味するために取られる知られている装置エミュレーションでHostをネットワークに取り付けるなら一般的な場合では、あなたが結局「本当のネットワークをしない」ということです: 端末、端末制御装置、またはRJEステーションであることにかかわらず知られている装置に関するオペレーティングシステムの内蔵の仮定は、簡単なリモート・ログインよりおもしろいアプリケーションの基礎として過程過程と結局手順手順コミュニケーションの種類の方法でそのサーブを得る傾向があります。 船外の処理アプローチになじみがないそれらに、付く方法が明白なプロトコルを使用するという前提は受け入れるのが難しいかもしれませんが、それはほとんど完全な意味をそれをした人にします。
To those, by the way, who have worked in intercomputer networking from the perspective of inboard (Host-side) implementations of protocol suites, the outboard processing idea often seems to lead to less than optimal results, especially as to maximizing throughput. And it is difficult to argue that if a given Host were well and truly
内側にの見解(ホスト側)からプロトコル群の実現をネットワークでつなぎながらintercomputerで働いていた方法によるものにおいて船外の処理考えは最適の結果以下に通じるようにしばしば思えます、特にスループットを最大にすることに関して。 そして、与えられたHostがよく、そして、本当にそうなら、それについて論争するのは難しいでしょうに。
Padlipsky [Page 2]
Padlipsky[2ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
fine-tuned to "do networking" the insertion of an extra processor could somehow lead to better networking. However, for Hosts where conservation of CPU cycles is an issue, or even where memory is scarce (i.e., where it's desirable to conserve the resources being shared), outboarding is clearly the way to go. For that matter, viewing outboard processing aright (as a form of distributed processing) it can be argued that even for extremely powerful "intelligent work stations"/"personal computers" which have the resources to spare it still makes sense to outboard in order not to have to do new implementations of entire protocol suites for each new such system--always assuming, of course, that the Host-Front End protocol in play is noticeably less complex than the offloaded protocols.
余分なプロセッサの挿入がネットワークでつなぐほうがよいのをどうにか通じることができた「ネットワークでつないでください」に微調整されています。 しかしながら、CPUサイクルの保護が問題かメモリがどこで不十分でさえあるかという(すなわち、どこで、共有される資源を節約するのは望ましいですか)ことであるHostsのために外到達するのは、明確に行く方法です。 さらに言えば、船外の処理を正しさに(分散処理のフォームとして)見て、割くリソースを持っている非常に強力な「知的なワークステーション」/「パーソナルコンピュータ」に関してさえまだ船外へのプレーのHost-前部Endプロトコルがもちろんいつも仮定しているそのようにシステムですが、それぞれのために新しい状態で全体のプロトコル群の新しい実現をするために顕著に持っていないオーダーにおける意味を積み下ろされたプロトコルほど複雑でなくしていると主張できます。
None of this is meant to imply that outboard processing is the ONLY way to do intercomputer networking, of course. It is, however, meant to suggest that outboard processing can be advantageous in a number of contexts. Indeed, given the joint advents of microprocessors and Local Area Networks, a generic bus interface unit which also plays the role of a NFE (that is, is an Outboard Processing Environment) even allows for the original intent of "offloading to the IMP" to be realized, so that a free-standing, possibly fairly expensive NFE need not be interposed between Host and net. Note, by the way, that nothing in the OPE approach requires that ALL Hosts employ OPEs. That is, the only protocols "seen" beyond the Comm Subnet Processor are the common intercomputer networking protocols (e.g., all DDN IMPs see and read IP datagrams). H-FP is strictly a matter between a Host and its OPE.
船外の処理がintercomputerネットワークをする唯一の方法である、もちろんをこのなにも含意することになっていません。 しかしながら、それは、船外の処理が多くの文脈で有利である場合があると示唆することになっています。 本当に、マイクロプロセッサとローカル・エリア・ネットワークの共同到来を考えて、また、NFE(すなわち、Outboard Processing Environmentである)の役割を果たす一般的なバス・インタフェース・ユニットは「IMPへの陸揚」が実感される当初の意図を考慮さえします、無料の地位の、そして、ことによるとかなり高価なNFEがHostとネットの間で挿入される必要はないように。 OPEアプローチにおける何も、すべてのHostsがOPEsを使うのを必要としないことにところで、注意してください。 すなわち、Comm Subnet Processorを超えて「見られた」唯一のプロトコルが一般的なintercomputerネットワーク・プロトコル(例えばすべてのDDN IMPsがIPデータグラムを見て、読む)です。 H-FPによる厳密に、aがHostとそのOPEの間で重要であるということです。
It is also important to be aware that, given the advent of several different suites of protocols in the networking world, it might well be the case that the only reasonable way to achieve "interoperability" might well be to use a suitable H-FP (such as the one to be presented in the companion RFC) and an Outboard Processing Environment which is capable of parallel invocation of protcol suites (with the choice of suite for a given connection being dependent, of course, on the native suite of the desired target Host and/or application).
また、意識しているのも重要である、それネットワーク世界のプロトコルのいくつかの異なったスイートの到来を考えて、; たぶん、たぶん適当なH-FP(仲間RFCに提示されるものなどの)とprotcolスイートの平行な実施ができるOutboard Processing Environment(与えられた接続のためのスイートの選択がもちろん必要な目標Host、そして/または、アプリケーションのネイティブの一組に依存している)を「相互運用性」を達成する唯一の合理的な方法がことである使用するだろうというのは、事実でしょう。
The unquestionable advantages, then, of the approach, based on ten or more years of experience and analysis, would seem to be as follows--always recalling the assumption that the work to implement and execute the H-FP in play is small compared to the full protocol suite in question: As noted, common implementation of a protocol suite has the automatic advantage of mutual consistency; further, particularly in the DOD context, it's far easier to procure common
いつも問題の完全なプロトコル群と比べて、プレーでH-FPを実行して、実行する仕事が小さいという仮定を思い出して、次にアプローチについて10年間以上の経験と分析に基づく明白な利点は以下の通りであるように思えるでしょう: 注意されるように、プロトコル群の一般的な実現には、互いの一貫性の自動利点があります。 さらに、そして、特にDOD文脈では、コモンを調達するのははるかに簡単です。
Padlipsky [Page 3]
Padlipsky[3ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
implementations of standard protocols than to procure different ones on a per-Host type basis. Also as noted, if the resources to be shared are viewed as being the participating Hosts'
ホストの上で異なったものを調達するより標準プロトコルの実現は基礎をタイプします。 また、注意されるように、共有されるのはリソースであるなら参加しているHostsであるとして見なされます。
CPU cycles and memories, these resources are conserved by doing as much as possible of the networking protocols in an OPE rather than in the mainframe. Another, less evident advantage is that having an OPE effectively insulates a Host against changes in the outboarded/offloaded protocols--or even changes of the protocols, should the nascent international protocol standards ever mature sufficiently to supplant the in-place DOD standards. (That is, given an abstract enough interface--in the spirit of the Principle of Layering--a Host could, for example, go from doing TCP as its "Host-Host" protocol to, say, ECMA Class 4 as its "Transport" protocol without taking any particular cognizance of the change, however unattractive such a change would be to advocates of the APRANET Reference Model such as the author. See [3] for more on the implied "Reference Model" issues.) Finally, although a few rather specialized points could also be adduced, it should be noted that for network security architectures which are predicated on the ability to control all means of egress from and ingress to "the net", uniform use of OPEs is clearly desirable.
メインフレームでというよりむしろOPEのネットワーク・プロトコルができるだけすることによって、CPUサイクルと思い出、これらの資源は節約されます。 それほど明白でない利点は有効にOPEを持っているとHostが外到達されたか積み下ろされたプロトコルにおける変化、またはプロトコルの変化に対してさえ絶縁されるということです、別のもの、初期の国際的なプロトコル標準がDOD規格を適所にあるのに取って代わることができるくらい熟させるなら。 (すなわち、要約を考えて、十分はLayeringのPrincipleの精神で連結します--例えば、Hostは「ホスト兼ホスト」プロトコルとして変化のどんな特定の認識も取らないでたとえば、「輸送」プロトコルとしてのECMA Class4にTCPをするのから行くことができて、しかしながら、APRANET Reference Modelの作者などの支持者にはつまらないそのようなa変化があるでしょう。 「規範モデル」という暗示している問題で以上のための[3]を見てください。) 最終的に、また、かなり専門化している数ポイントを提出できましたが、能力ですべてが意味する「ネット」への出口とイングレスのコントロールに叙述されるネットワークセキュリティー体系には、OPEsの一定の使用が明確に望ましいことに注意するべきです。
If we can stipulate that an OPE is/can be a good thing, then the remaining problem is just what the protocol interpreted by a Host and its OPE ought to be, once it's observed that a standard protocol is desirable in order to allow for as much commonality as possible among Host-side interpreters of the protocol. That is, we envision the evolution of paradigmatic H-FP PIs which can more or less straightforwardly be integrated with various operating systems, on the one hand, and the ability simply to transplant an H-FP PI from one instance of a given operating system to other instances of the same system, much as is currently being attempted in the DODIIS NFE program. Again, the major motivation in the DOD context is the minimizing of procurement problems.
私たちが、OPEが利益がものであったかもしれないなら/であることを規定できるなら、残った問題はちょうどHostによって解釈されたプロトコルとそのOPEが何であるかということであるべきです、標準プロトコルがプロトコルのHost-サイドインタプリタの中で同じくらい可能な同じくらい多くの共通点を考慮するために望ましいのをいったん観測すると。 すなわち、私たちは一方では、多少様々なオペレーティングシステムとまっすぐ統合できる範列的なH-FP PIsの発展と与えられたオペレーティングシステムの1つの例から同じシステムの他の例まで単にH-FP PIを移植する能力を思い描きます、現在DODIIS NFEプログラムで試みられている多く。 一方、DOD文脈の主要な動機は調達問題を最小にすることです。
Technical Context
技術的な関係
As noted, some half-a-dozen Host-Front End protocols have been seen by the author. Indeed, in December of 1982, a meeting was convened to allow the developers of those H-FPs to compare their experiences, with an eye to coming up with a proposal for a DOD standard H-FP; this paper is a direct result of that meeting. In the current section, we present the consensus of the meeting as to the broad outline of the protocol; in the accompanying document, the current version of the proposed protocol will be presented, as detailed by the author and Richard Mandell and Joel Lilienkamp (both of SDC).
注意されるように、およそ半ダースのHost-前部Endプロトコルが作者によって見られました。 本当に、1982年12月にミーティングはそれらのH-FPsの開発者が彼らの経験を比較するのを許容するために召集されました、DODの標準のH-FPのために提案を示すことへの目で。 この紙はそのミーティングの直接の結果です。 現在のセクションでは、私たちはプロトコルの広いアウトラインに関してミーティングのコンセンサスを示します。 添付書類では、提案されたプロトコルの最新版は示されるでしょう、作者、リチャード・マンデル、およびジョエルLilienkamp(SDCの両方)によって詳しく述べられるように。
Padlipsky [Page 4]
Padlipsky[4ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
Note, by the way, that in some sense we should probably have changed the name from H-FP to H-OPEP (or something), but the habit of saying "H-FP" seems too deeply engrained, despite the fact that it does seem worthwhile to stop saying "NFE" and start saying "OPE." (Besides, H-OPEP looks rather silly.)
何らかの意味で、私たちがたぶんH-FPから(例えば、)H-OPEPに改称するべきでしたが、「H-fp」を言う習慣がそれが思える事実にもかかわらず、あまりに深くengrainedされているように"NFE"を言うのを止めて、"OPE"を言い始めるために価値があった状態で見えることにところで、注意してください。 (そのうえ、H-OPEPはかなり愚かに見えます。)
A final preliminary: all the designers and implementors of H-FPs present at the December meeting concurred that the true test of any protocol is how well it implements. Therefore, until several implementations of the "new" protocol have been performed and assessed, it must be understood that the proposed protocol is precisely that: a proposal, not a standard.
最終的な準備段階: 12月のミーティングの現在のH-FPsのすべてのデザイナーと作成者が、どんなプロトコルの本当のテストもどのようにであるかを同意しました。それが実行する井戸。 したがって、「新しい」プロトコルのいくつかの実現が実行されて、評価されるまで、まさに、提案されたプロトコルが以下のことということであることを理解しなければなりません。 規格ではなく、提案。
Not too surprisingly, the first point on which consensus was reached is that there are three separable aspects (or "layers") to an H-FP: At bottom, there must be some physical means for conveying bits from Host to OPE and from OPE to Host. As it has always been a premise of outboard processing that the Host's convenience is paramount, just what this physical layer is can vary: typically, a bit-serial interface is customary, but parallel/DMA interfaces, if available for the Host and interfaceable to a given OPE, are fair game. (So would teleporting the bits be, for that matter.)
あまりに驚いたことにない、コンセンサスに達した最初のポイントはH-FPへの3つの分離できる局面(または、「層」)があるということです: 実は、OPEからHostからOPEまでビットを運んで、Hostまでいくつかの物理的な手段があるに違いありません。 いつもそれがHostの便利が最高のであるという船外の処理の前提であるときに、この物理的な層がちょうど何であるかが異なることができます: しばらくシリアルインタフェースは通常、通例ですが、Hostに利用可能であって、与えられたOPEに「インタフェース-可能」であるなら、平行/DMAインタフェースはかもです。 (それで、ビットを瞬間移動させるのがあるだろう、さらに言えば)。
In the middle, there must be a layer to manage the multiplexing of network "connections" and the control of the flow between Host and OPE. If we agree to call the lowest layer the Link and the middle layer the Channel, one thing which must be noted is that between the two of them, the Link and Channel layers must be responsible for reliably conveying the bits between Host and OPE. After all, an OPE'd Host should not be "weaker" than one with an inboard implementation of a robust Host-Host protocol such as TCP. It should be noted that any Host which "comes with" a suitable implementation of the X.25 interface protocol (where the definition of "suitable" is rather too complex to deal with here) could, given an OPE conditioned to accept it, quite cheerfully satisfy the requirements of the lower two layers. This is not to say that X.25 "is" the mechanization of H-FP's Link and Channel layers, however; merely that it could be used. The protocol spec itself will detail an alternative, less cumbersome channel layer for Hosts which don't have or want X.25.
中央に、HostとOPEの間には、ネットワーク「接続」のマルチプレクシングと流れのコントロールを管理する層があるに違いありません。 私たちが、最も低い層をLinkと中間層英仏海峡と呼ぶのに同意するなら、注意しなければならない1つのことはそれらの2つの間では、LinkとChannel層がHostとOPEの間のビットを確かに運ぶのに原因となるに違いないということです。 OPEが」であった後に、Hostは「TCPなどの強健なHost-ホストプロトコルの機内の実現がある1より弱いべきではありません」。 それが注意されるべきである、それ、どんなHost、もどれ、「来るか、」 X.25の適当な実現に、それを受け入れるように条件とするOPEを考えて、インタフェースプロトコル(「適当」の定義がかなりここで対処できないくらい複雑であるところ)は全く喜んで低級2つの層の要件を満たすかもしれません。 これは機械化をH-FPのものを「ある」というそのX.25Linkでとは言わないまでもあります、そして、しかしながら、Channelは層にします。 単に、それを使用できました。 プロトコル仕様自体はX.25が持っていないか、または欲しくないHostsのために代替手段、それほど扱いにくくないチャンネル層について詳述するでしょう。
The top layer of H-FP is the most important: we refer to it as the Command layer. Here is where the peer H-FP modules in a given Host and OPE communicate with each other. Indeed, the segregation of JUST multiplexing and flow control (plus reliability) into the Channel Layer is done--in addition to making it easier for Hosts that possess preexisting software/hardware which could be turned to the purpose--so as to clarify "what the H-FP is": it's the commands and
The top layer of H-FP is the most important: we refer to it as the Command layer. Here is where the peer H-FP modules in a given Host and OPE communicate with each other. Indeed, the segregation of JUST multiplexing and flow control (plus reliability) into the Channel Layer is done--in addition to making it easier for Hosts that possess preexisting software/hardware which could be turned to the purpose--so as to clarify "what the H-FP is": it's the commands and
Padlipsky [Page 5]
Padlipsky [Page 5]
RFC 928 December 1984 Introduction to H-FP
RFC 928 December 1984 Introduction to H-FP
responses of the Command layer wherewith the Host's processes are able to manipulate the outboard implementations of the members of a protocol suite. The use of the phrase "commands and responses" is rather significant, as it happens. For in the protocol to be proposed for DOD standardization, unlike all but one of its predecessors, binary encoded "headers" are not employed; rather, the H-FP commands are indeed ASCII strings, and the responses (following the practice of ARPANET FTP) ASCII-encoded numbers.
responses of the Command layer wherewith the Host's processes are able to manipulate the outboard implementations of the members of a protocol suite. The use of the phrase "commands and responses" is rather significant, as it happens. For in the protocol to be proposed for DOD standardization, unlike all but one of its predecessors, binary encoded "headers" are not employed; rather, the H-FP commands are indeed ASCII strings, and the responses (following the practice of ARPANET FTP) ASCII-encoded numbers.
There are various reasons for this departure, which initially stemmed
from a desire to have the same NFE be usable for terminal traffic as
well as Host offloading, but the one that seemed to dominate when
consensus was arrived on it as the basis for the new standard is that
it is very much in the original spirit of H-FP. That is, if you want
to "make things as easy as possible for the Host", it makes a great
deal of sense to offload in a fashion that only requires some sort of
scenario or script ("exec-com"/"command file"/"shell command" are
approximations on some systems) in the Host, rather than requiring a
program, possibly of more complexity than we would like. This is not
to say that we envision all--or even most--Hosts will take the
scenario approach to H-FP mechanization, but rather that the command
orientation chosen allows for the possibility. (It would be useful to
recall that the Channel layer does all the necessary
multiplexing/demultiplexing, so that each channel's metaphorical
state machine--at least on the Host side--really has very little to
worry about other than "doing its thing.")
There are various reasons for this departure, which initially stemmed from a desire to have the same NFE be usable for terminal traffic as well as Host offloading, but the one that seemed to dominate when consensus was arrived on it as the basis for the new standard is that it is very much in the original spirit of H-FP. That is, if you want to "make things as easy as possible for the Host", it makes a great deal of sense to offload in a fashion that only requires some sort of scenario or script ("exec-com"/"command file"/"shell command" are approximations on some systems) in the Host, rather than requiring a program, possibly of more complexity than we would like. This is not to say that we envision all--or even most--Hosts will take the scenario approach to H-FP mechanization, but rather that the command orientation chosen allows for the possibility. (It would be useful to recall that the Channel layer does all the necessary multiplexing/demultiplexing, so that each channel's metaphorical state machine--at least on the Host side--really has very little to worry about other than "doing its thing.")
It should be noted that the proposed protocol provides a mechanism for offloading "all" protocols. That is, although most "first generation NFEs" only handled ARPANET Reference Model Layers II and I (Host-Host and Network Interface--approximately ISO levels 4-1, with some of L5's functionality included when it comes to service identifications being handled via Well-Known Sockets in L II), it is assumed that OPEs will be evolved to handle L III offloading as well (ISO 5-7). Indeed, it should also be noted that what is being addressed here is "the protocol", not "the" OPE. More will be said on this topic below, and in the protocol spec itself, but it is important to realize from the outset that the H-FP being proposed is intended to be implementable by any number of OPE suppliers/vendors, so "an" OPE may or may not choose to implement, say, a given file transfer protocol, but provided it says so in proper H-FP terms and does offload some other protocols it's still an OPE in our sense of the term. (Cf. "Issues" and "Non-Issues", below.)
It should be noted that the proposed protocol provides a mechanism for offloading "all" protocols. That is, although most "first generation NFEs" only handled ARPANET Reference Model Layers II and I (Host-Host and Network Interface--approximately ISO levels 4-1, with some of L5's functionality included when it comes to service identifications being handled via Well-Known Sockets in L II), it is assumed that OPEs will be evolved to handle L III offloading as well (ISO 5-7). Indeed, it should also be noted that what is being addressed here is "the protocol", not "the" OPE. More will be said on this topic below, and in the protocol spec itself, but it is important to realize from the outset that the H-FP being proposed is intended to be implementable by any number of OPE suppliers/vendors, so "an" OPE may or may not choose to implement, say, a given file transfer protocol, but provided it says so in proper H-FP terms and does offload some other protocols it's still an OPE in our sense of the term. (Cf. "Issues" and "Non-Issues", below.)
Padlipsky [Page 6]
Padlipsky [Page 6]
RFC 928 December 1984 Introduction to H-FP
RFC 928 December 1984 Introduction to H-FP
Issues
Issues
The following items are either in some sense still open issues or bear special emphasis:
The following items are either in some sense still open issues or bear special emphasis:
Command Approach
Command Approach
The most striking feature of the new H-FP, especially to those who
have seen older H-FPs, is the decision to employ
character-oriented commands rather than the more conventional
binary-oriented headers at the Command Layer. As noted, the
primary motivation was the report that the approach worked well
when it was employed in an H-FP for the Platform Network called
NAP (Network Access Protocol) [4]. In discussions with NAP's
originator, Gerry Bailey, the author was convinced of the
fundamental reasonableness of the approach, but of course that
doesn't have to convince others. Additional rationales emerged in
discussions with Gary Grossman, the originator of the DCA/DTI
H-FP [5], which is probably the best-known current H-FP and which
furnished the default Channel Layer for the new one: In the first
place, the text approach makes parsing for the ends of
variable-length parameters easier. In the second place, it allows
for the possibility of creating a terminal-supporting OPE in a
very straightforward fashion should any OPE developer elect to do
so. (See below for more on the distinction between OPE developers
and H-FP implementors.) Finally, there's nothing sacred about
binary headers anyway, and just because the text approach is
different doesn't make it "wrong". So, although it's not out of
the question that the new protocol should back off from the text
approach if reviewers and/or implementors come up with compelling
reasons for doing so, the already frequently encountered reaction
of "it feels funny" isn't compelling. (It was, indeed, the
author's own initial reaction.) Besides, "nobody" (not even Gary)
really liked the top layer of the DCA/DTI H-FP.
The most striking feature of the new H-FP, especially to those who have seen older H-FPs, is the decision to employ character-oriented commands rather than the more conventional binary-oriented headers at the Command Layer. As noted, the primary motivation was the report that the approach worked well when it was employed in an H-FP for the Platform Network called NAP (Network Access Protocol) [4]. In discussions with NAP's originator, Gerry Bailey, the author was convinced of the fundamental reasonableness of the approach, but of course that doesn't have to convince others. Additional rationales emerged in discussions with Gary Grossman, the originator of the DCA/DTI H-FP [5], which is probably the best-known current H-FP and which furnished the default Channel Layer for the new one: In the first place, the text approach makes parsing for the ends of variable-length parameters easier. In the second place, it allows for the possibility of creating a terminal-supporting OPE in a very straightforward fashion should any OPE developer elect to do so. (See below for more on the distinction between OPE developers and H-FP implementors.) Finally, there's nothing sacred about binary headers anyway, and just because the text approach is different doesn't make it "wrong". So, although it's not out of the question that the new protocol should back off from the text approach if reviewers and/or implementors come up with compelling reasons for doing so, the already frequently encountered reaction of "it feels funny" isn't compelling. (It was, indeed, the author's own initial reaction.) Besides, "nobody" (not even Gary) really liked the top layer of the DCA/DTI H-FP.
X.25 Appropriateness
X.25 Appropriateness
Of more concern than how text "feels" is whether X.25 "works".
That is, we understand that many system proprietors would greatly
prefer being able to use "off-the-shelf" software and hardware to
the greatest extent feasible and still be able to do intercomputer
networking according to DOD Standards, which is a major reason why
we decided to take the H-FP commands out of the Channel Layer of
the DCA/DTI H-FP even before we decided to encode them as text.
However, it is by no means clear that any old vendor supplied
"X.25" will automatically be usable as a new H-FP Channel and Link
layer mechanization. As noted, it all depends upon how Host
Of more concern than how text "feels" is whether X.25 "works". That is, we understand that many system proprietors would greatly prefer being able to use "off-the-shelf" software and hardware to the greatest extent feasible and still be able to do intercomputer networking according to DOD Standards, which is a major reason why we decided to take the H-FP commands out of the Channel Layer of the DCA/DTI H-FP even before we decided to encode them as text. However, it is by no means clear that any old vendor supplied "X.25" will automatically be usable as a new H-FP Channel and Link layer mechanization. As noted, it all depends upon how Host
Padlipsky [Page 7]
Padlipsky [Page 7]
RFC 928 December 1984 Introduction to H-FP
RFC 928 December 1984 Introduction to H-FP
programs (the Command Layer/H-FP Protocol Interpreter in
particular) are able to invoke X.25 on particular systems. Also,
there might be peculiarities in the handling of some constructs
(the Group and Member fields--or whatever they're called--are a
strong candidate) which could militate against getting JUST
demultiplexing and flow control out of X.25-as-Channel
Link/Layers. For that matter, it's conceivable that on some
systems only one process can "own" the presumed DCE, but there's
no interprocess communication available between it and the
processes that want to use H-FP. What that all amounts to, then,
is that we don't pretend to be sufficiently versed in the vagaries
of vendor-idiosyncratic X.25 implementations to claim more than
that we THINK the new H-FP Command Layer should fit "on top of"
X.25 in a Host such that a suitably crafted OPE could look like a
DCE to the low-level Host software and still be an OPE in our
sense of the term. Finally, some reports on bit-transfer rates
attainable through typical X.25 interfaces give rise to concern as
to whether such a lash-up would be "good" even if it were
feasible.
programs (the Command Layer/H-FP Protocol Interpreter in particular) are able to invoke X.25 on particular systems. Also, there might be peculiarities in the handling of some constructs (the Group and Member fields--or whatever they're called--are a strong candidate) which could militate against getting JUST demultiplexing and flow control out of X.25-as-Channel Link/Layers. For that matter, it's conceivable that on some systems only one process can "own" the presumed DCE, but there's no interprocess communication available between it and the processes that want to use H-FP. What that all amounts to, then, is that we don't pretend to be sufficiently versed in the vagaries of vendor-idiosyncratic X.25 implementations to claim more than that we THINK the new H-FP Command Layer should fit "on top of" X.25 in a Host such that a suitably crafted OPE could look like a DCE to the low-level Host software and still be an OPE in our sense of the term. Finally, some reports on bit-transfer rates attainable through typical X.25 interfaces give rise to concern as to whether such a lash-up would be "good" even if it were feasible.
DCA/DTI Channel Layer Appropriateness
DCA/DTI Channel Layer Appropriateness
The Channel Layer of the DCA/DTI H-FP has been implemented for a
few Host types already, and is being implemented for others (in
particular, as part of the DODIIS NFE project). A delicate
decision is whether to alter the header structure (e.g.--and
perhaps i.e.--to remove the now-superfluous command and response
fields). On the "con" side are the considerations that
implementations DO exist, and that it's well specified. On the
"pro" side are that keeping the header as it is is in some sense
"wasteful" and that somebody's going to have to go over the spec
again anyway, to remove that which no longer applies. (It should
be noted that Gary Grossman was initially tempted to scuttle the
Group and Member trick, but the presence of a similar
dichotomizing in X.25 seems to rule that out.) One of the
interesting issues during the review phase of the new H-FP, then,
will be the decision about which way to go on the Channel Layer
header in its non-X.25 version. (NOBODY considers going X.25
only, be it noted.) By the time the protocol is finalized, it
will, of course, be made clear in the protocol spec, but I'll
probably leave this in the final version of the Introduction just
for historical interest anyway.
The Channel Layer of the DCA/DTI H-FP has been implemented for a few Host types already, and is being implemented for others (in particular, as part of the DODIIS NFE project). A delicate decision is whether to alter the header structure (e.g.--and perhaps i.e.--to remove the now-superfluous command and response fields). On the "con" side are the considerations that implementations DO exist, and that it's well specified. On the "pro" side are that keeping the header as it is is in some sense "wasteful" and that somebody's going to have to go over the spec again anyway, to remove that which no longer applies. (It should be noted that Gary Grossman was initially tempted to scuttle the Group and Member trick, but the presence of a similar dichotomizing in X.25 seems to rule that out.) One of the interesting issues during the review phase of the new H-FP, then, will be the decision about which way to go on the Channel Layer header in its non-X.25 version. (NOBODY considers going X.25 only, be it noted.) By the time the protocol is finalized, it will, of course, be made clear in the protocol spec, but I'll probably leave this in the final version of the Introduction just for historical interest anyway.
Syntax
Syntax
Another point which probably needs close scrutiny during the
review process is the "syntax" of the command lines. Basically,
Another point which probably needs close scrutiny during the review process is the "syntax" of the command lines. Basically,
Padlipsky [Page 8]
Padlipsky [Page 8]
RFC 928 December 1984 Introduction to H-FP
RFC 928 December 1984 Introduction to H-FP
we just took our best shot, but without any claims that it's the
best possible way to express things. So comments and/or
alternatives are earnestly solicited on this one.
we just took our best shot, but without any claims that it's the best possible way to express things. So comments and/or alternatives are earnestly solicited on this one.
L III Offloading
L III Offloading
Contrary to the expectations of some, we are allowing for the
offloading of Process/Applications Layer (ARPANET Reference Model
L III) protocols. Both Bailey and Grossman reported favorably on
the feasibility of this. Two points should be made, however: It's
perfectly fair for a GIVEN OPE implementation not to offload a
given L III protocol, although it would presumably not sell as
well as ones which did. That is, we're not claiming that by
inventing a mechanization of the feature in the spec we levy a
constraint on everybody who implements "the protocol", (Cf.
Fabrication under Non-Issues, below). Just as we were feeling our
way on syntax in general, we're really feeling our way when it
comes to the L III stuff. (I'm not even sure I managed to convey
what I meant for "mediation level" to Joel and Dick.) Again,
suggestions are solicited.
Contrary to the expectations of some, we are allowing for the offloading of Process/Applications Layer (ARPANET Reference Model L III) protocols. Both Bailey and Grossman reported favorably on the feasibility of this. Two points should be made, however: It's perfectly fair for a GIVEN OPE implementation not to offload a given L III protocol, although it would presumably not sell as well as ones which did. That is, we're not claiming that by inventing a mechanization of the feature in the spec we levy a constraint on everybody who implements "the protocol", (Cf. Fabrication under Non-Issues, below). Just as we were feeling our way on syntax in general, we're really feeling our way when it comes to the L III stuff. (I'm not even sure I managed to convey what I meant for "mediation level" to Joel and Dick.) Again, suggestions are solicited.
Security
Security
During the detailed design pass, we had an intensive discussion
with some of the Blacker design team on the interplay between the
new H-FP and a meant-to-be multilevel-secure OPE such as Blacker.
The conclusion was that by and large "Security" is to be an aspect
of an enhanced H-FP, rather than the standard one. The reasoning
was rather involved, but seems to amount to the following: Hosts
that are NOT MLS (or "Compartmented") have two significant
properties in our context: They're in the vast majority of
present-day systems. They have no legitimate need even to tell
their OPEs what they "think" their current System High or
Dedicated Mode level is; that information should be furnished by
some trusted portion of a network security architecture (e.g., a
security enhanced OPE, or a table in a "secure" comm subnet
processor).
During the detailed design pass, we had an intensive discussion with some of the Blacker design team on the interplay between the new H-FP and a meant-to-be multilevel-secure OPE such as Blacker. The conclusion was that by and large "Security" is to be an aspect of an enhanced H-FP, rather than the standard one. The reasoning was rather involved, but seems to amount to the following: Hosts that are NOT MLS (or "Compartmented") have two significant properties in our context: They're in the vast majority of present-day systems. They have no legitimate need even to tell their OPEs what they "think" their current System High or Dedicated Mode level is; that information should be furnished by some trusted portion of a network security architecture (e.g., a security enhanced OPE, or a table in a "secure" comm subnet processor).
Thus, even having the optional security label/level field in the
Begin command is in some sense overkill, because we're not sure of
any sensible circumstances in which it would be useful, but we put
it in "just in case". On the other hand, Hosts that ARE
MLS/Compartmented by definition can be permitted to assert what
the level of a given transmission (or perhaps of a given
connection) should be, and their OPEs need to have a mechanism for
learning this. But it is by no means clear that a given Host (or
even a given OPE) will be so structured as to make the H-FP PI,
Thus, even having the optional security label/level field in the Begin command is in some sense overkill, because we're not sure of any sensible circumstances in which it would be useful, but we put it in "just in case". On the other hand, Hosts that ARE MLS/Compartmented by definition can be permitted to assert what the level of a given transmission (or perhaps of a given connection) should be, and their OPEs need to have a mechanism for learning this. But it is by no means clear that a given Host (or even a given OPE) will be so structured as to make the H-FP PI,
Padlipsky [Page 9]
Padlipsky [Page 9]
RFC 928 December 1984 Introduction to H-FP
RFC 928 December 1984 Introduction to H-FP
the Channel PI, and the Link PI ALL trustworthy--as they'd have to
be if the security labeling were part of H-FP. So, we envision
the labeling's being handled by trusted code in both Host and OPE
that will be inserted into the normal processing route at the
appropriate point for the given architecture (presumably "at the
very bottom" of the Host, and "the very top" of the OPE), and that
will place the label in a convenient, known position in the
Host-OPE transmission "chunk" (block/packet/data unit) as the
circumstances dictate. (It's likely--but we wouldn't swear to
it--that a good place would be just before the H-FP command, and
if that's the case then semi-clearly the security enhanced H-FP
PIs would have to "make room" for it in the sense of handing the
Channel Layer a suitably lengthened "chunk".)
the Channel PI, and the Link PI ALL trustworthy--as they'd have to be if the security labeling were part of H-FP. So, we envision the labeling's being handled by trusted code in both Host and OPE that will be inserted into the normal processing route at the appropriate point for the given architecture (presumably "at the very bottom" of the Host, and "the very top" of the OPE), and that will place the label in a convenient, known position in the Host-OPE transmission "chunk" (block/packet/data unit) as the circumstances dictate. (It's likely--but we wouldn't swear to it--that a good place would be just before the H-FP command, and if that's the case then semi-clearly the security enhanced H-FP PIs would have to "make room" for it in the sense of handing the Channel Layer a suitably lengthened "chunk".)
The Host and its OPE should be viewed as a single entity with
regard to labeling requirements in the non-MLS/C case, and either
the OPE will be conditioned to emit the right label or the CSNP
will "know" anyway; in the MLS/C Host and OPE case (and it should
be noted that it's just about impossible to envision a MLS/C Host
which IS outboarded which DOESN'T have a MLS/C OPE) it will depend
on the given security architectures as to whether each "chunk"
needs labeling (i.e., there COULD be trusted H-FP, Channel, and
Link PIs, so that only at channel establishment time does the
label need to be passed), but it seems likely each "chunk" would
need labeling, and we can see how that would happen (as sketched
above).
The Host and its OPE should be viewed as a single entity with regard to labeling requirements in the non-MLS/C case, and either the OPE will be conditioned to emit the right label or the CSNP will "know" anyway; in the MLS/C Host and OPE case (and it should be noted that it's just about impossible to envision a MLS/C Host which IS outboarded which DOESN'T have a MLS/C OPE) it will depend on the given security architectures as to whether each "chunk" needs labeling (i.e., there COULD be trusted H-FP, Channel, and Link PIs, so that only at channel establishment time does the label need to be passed), but it seems likely each "chunk" would need labeling, and we can see how that would happen (as sketched above).
This is all, of course, subject to reappraisal when the full-time
Security folks get in the act, but for now, H-FP per se is viewed
as playing no direct role in "Security"--except indirectly, as
noted below under the Symmetric Begins Non-Issue. (In case
anybody's worrying about the case where the OPE is physically
remote from its Host, by the way, that line would have to be
protected anyway, so the Host/OPE-asa-single-unit view should hold
up.)
フルタイムのSecurity人々が行為に入りますが、そういうもののH-FPが当分「セキュリティ」における直接的な役割を全くプレーしないと見なされるとき、以下にSymmetric Begins Non-問題の下で間接的に述べられるのを除いて、これはもちろん再検討を条件としてすべてです。 (だれかが、OPEがどこで立ち並ぶ方法によるHostから物理的にリモートであるかをケースに心配するのがとにかく保護されなければならないといけないでしょう、したがって、したがって、Host/OPE-asa-1セット視点は有効であるべきです。)
How It Implements
それが実行するどのように
The final issue to take note of is that one of the central
premises of the Outboard Processing approach has always been that
H-FPs can be invented which implement more compactly on the Host
side than the code they're allowing to be offloaded. We certainly
think the new H-FP will fulfill that condition, but we'd certainly
like to hear of any evidence to the contrary.
注目する最終的な問題はOutboard Processingアプローチの中央の構内の1つがいつも彼らが積み下ろされるのを許しているコードよりどちらの道具にHostでさらにコンパクトに面があるH-FPsを発明できるということであるということです。 私たちは、新しいH-FPがその条件を達成すると確かに思いますが、確かに、どんな反対の証拠も知りたいと思います。
Padlipsky [Page 10]
Padlipsky[10ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
Non-Issues
どうでもいい問題
The following items are declared to be non-issues, in the sense that even though some people have expressed concern over them we believe that they are either "not part of the protocol" or resolved already for reasons that were overlooked by those worried about them:
以下の項目はどうでもいい問題であると申告されます、何人かの人々が彼らの上で懸念を示しましたが、私たちが、彼らが、「プロトコルの一部でない」であるか理由でそれがそれらを心配するものによって見落とされたと既に決議したと信じているという意味で:
Fabrication
製作
Who builds OPEs isn't within our purview, except to the extent of
hoping a few volunteers come forward to do testcase
implementations of what is, at present, only a paper protocol.
However, beyond agreeing that a few points should be marked as
"Notes to Entrepreneurs" in the spec, we didn't attempt to dictate
how an OPE vendor would behave, beyond the explicit and implicit
dictates of the protocol per se. For example, if a given OPE
doesn't offload SMTP, it jolly well ought to respond with the
appropriate "Function not implemented" code, and if a vendor
claims to accept X.25 for Channel and Link disagreements over what
X.25 "is" are the province of the vendor and the customer, not of
the H-FP spec. As OPE'S are supposed to be offloading COMMON
protocols in a COMMON fashion, a given OPE should be able to
interoperate with another Host irrespective of whether that Host
even has an OPE, much less whose OPE it is if it's there. Thus,
for example, even though you'd expect to find OPEs that "come
with" their own LANs as a fairly frequent product, we don't appeal
to the notion in the conceptual model; nor do we attempt to
dictate "chunk" sizes at the Channel level. A protocol spec isn't
an implementation spec.
私たちの範囲の中に数人のボランティアが現在のところ紙のプロトコルであるにすぎないことに関するtestcase実現をするために進み出ることを望む範囲以外に、だれがOPEsを造るかがありません。 しかしながら、数ポイントが仕様の「企業家への注意」としてマークされるべきであるのに同意することを超えて、私たちは、OPE業者がどう振る舞うだろうかを書き取るのを試みませんでした、そういうもののプロトコルの明白で暗黙の命令を超えて。 OPEがSMTPを積み下ろさないで、よく明るく冗談を言うという当然のことがそうするべきであるなら、例えば、どんな「存在X.25」がH-FP仕様ではなく、業者と顧客の州であるかの上で「実行されなかった機能」適切なコード、業者が、ChannelのためにX.25を受け入れると主張するか、そして、およびLink不一致で応じてください。 OPEのものがCOMMONファッションでCOMMONプロトコルを積み下ろすべきであるとき、そのHostにありさえするかどうかの如何にかかわらずさえ与えられたOPEは別のHostと共に共同利用するはずであることができます、そこにあるならそれがだれのOPEであるかという多くの以下。 このようにして、例えば、あなたは、かなり頻繁な製品としてそれが「来る」OPEsにそれら自身のLANを見つけると予想するでしょうが、私たちは概念モデルの概念に求めません。 また、私たちは、英仏海峡レベルにおける「塊」サイズを書き取るのを試みません。 プロトコル仕様は実現仕様ではありません。
Symmetric Begins
左右対称である、始まり
For almost as long as there have been H-FPs, there has been
disagreement over whether only the Host can begin a connection or
if the OPE can also take the initiative. I am delighted to be
able to resolve this one finally: It turns out there IS a
compelling reason for insisting that THE PROTOCOL include
provision for OPE --> Host Begins, so it's "in" the protocol--but
any Host that doesn't need to deal with them doesn't have to (just
"spell" the "Function not implemented" response code correctly).
ほとんどH-FPsがあった限り、Hostだけが接続を始めることができるかどうか、またはまた、OPEがイニシアチブを取ることができるかどうかに関して不一致がありました。 最終的にこれを喜んで決議できます: それはむこうにターンします。それがプロトコルはOPEへの支給を含んでいます-->Host Begins、そのようにと主張するための、“in"である無視できない理由はプロトコルですが、彼らに対応する必要はないどんなHostもプロトコルである必要はありません(まさしく、正しく「実行されなかった機能」応答コードを「つづります」)。
(In case anybody cares, the compelling reason is that if you HAD
an MLS OPE which happened to use a security kernel and a process
per level, you'd need IT to be listening for incoming connection
requests "from the net" rather than having the Host tell it to do
so, for various esoteric reasons--but in order to cater to the
possibility, we want the function in the protocol from the
(だれでも気にかけるといけないので、やむにやまれない理由はHostに様々な難解な理由でそうをするようにそれに言わせるよりたまたまaセキュリティカーネルを使用したMLS OPEとaがレベル単位で処理するHAD、あなたがあなたであるならITを必要とするだろうというのがむしろ入って来る接続の聞こうとしているのに「ネット」を要求しますが、私たちが、可能性に満たすためにプロトコルでの機能が欲しいと思うということです。
Padlipsky [Page 11]
Padlipsky[11ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
beginning, on the grounds that we can envision SOME other uses for
it even in non-MLS environments [unlike the security labeling
trick discussed above, which only seems to make sense for MLS
Hosts/OPEs--that is, it doesn't burden the Host to reject a Begin
every once in a while but it would to go around labeling "chunks"
unnecessarily all the time].)
私たちが非MLS環境[絶えず不必要に「塊」をラベルして回るために上で議論したMLS Hosts/OPEs()、時々Beginを拒絶するためにHostを負いませんが、負うでしょう、したがって、理解できるように思えるだけであるトリックをラベルするセキュリティと異なった]でさえそれへのSOME他の用途を思い描くことができるので始め
Routing
ルート設定
Concern has been voiced over the issue of what provisions the
protocol should make to deal with the situation where a Host,
probably for traffic/load reasons, has multiple OPEs and the
question arises of which OPE to use/route to. I claim this is a
non-issue at the protocol level. If the Host-side H-FP PI gets a
"No resources" response to a Begin, it can go off to another OPE
if it wants to. "Not our department". The conceptual model is
that of a Host and AN OPE--which "ought to" be expandable to carry
more load at some level. If you want multiple links for some
reason, the simplest solution would seem to be to have multiple
Channel Layers as well, but the whole thing just gets too iffy to
have anything sensible to prescribe in the protocol. In other
words, extending the concept to deal with discrete multiple OPEs
is either a Fabrication sort of thing, or a Notes to Host-side
Implementors sort of thing on a per specific OPE basis.
関心は、たぶん交通/負荷理由で、Hostには複数のOPEsがあって、質問がどのOPEを使用するか、または発送するかが起こるところに時局に処するためにプロトコルがどんな条項を作るべきであるかに関する問題の上で声に出されました。 私は、これがプロトコルレベルにおいてどうでもいい問題であると主張します。 去りたいなら、Host-サイドH-FP PIがBeginへの「いいえリソース」応答を得るなら、それは別のOPEへ去ることができます。 「私たちの部でない。」 概念モデルはHostとAN OPEのものです--どの“ought to"がある意味でより多くの積載物を運ぶのにおいて拡張可能ですか? あなたがある理由で複数のリンクが欲しいなら、最も簡単な解決策はまた、複数のChannel Layersを持つことになっているように思えるでしょうが、全体のものはただプロトコルで処方する分別があるものは何も持つことができないくらい不確かになります。 言い換えれば、離散的な倍数OPEsに対処するために概念について敷衍するのは、aの特定のOPE基礎あたりのものにちょっと、もののFabrication種類かHost-サイドImplementorsへのNotesのどちらかです。
Operator Interface
オペレータ・インタフェース
It's probably implicit in the foregoing, but it might be worth
saying explicitly that the operator interface to a specific OPE is
a non-issue in terms of the protocol, beyond the provision we're
made for "Shutdown coming" responses as a reflection of a probable
operator interface action we imagine most operator interfaces
would provide. (It might also be worth noting that if your Host
does "color changes", your OPE had better have a trustworthy way
of being told to change the label it plops on all IP datagrams it
emits, but that comes under the heading of an Aside to Specialized
Implementors.)
それはたぶん上記で暗に示されていますが、特定のOPEへのオペレータ・インタフェースがプロトコルでどうでもいい問題であると明らかに言う価値があるかもしれません、支給を超えて私たちが「閉鎖の来る」応答のために私たちがほとんどのオペレータ・インタフェースであると想像するありえそうなオペレータ・インタフェース動作の反映が提供されるようにされる。 (また、あなたのHostが「色の変化」をするなら、あなたのOPEには言われるのがそれが放つすべてのIPデータグラムでどぶんと落とすラベルを変えるAsideに関する見出しにSpecialized Implementorsに該当する信頼できる方法があるほうがよいことに注意する価値があるかもしれません。)
Padlipsky [Page 12]
Padlipsky[12ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
Fine Points
委細
There are a couple of known "loose ends" which are exceedingly fine points in some sense that do bear separate mention:
何らかの意味で別々の言及に堪えるきわめてすばらしいポイントである2、3の知られている「未処理事項」があります:
The Allocate Event
出来事を割り当ててください。
While mentally testing to see if the new H-FP would indeed
off-load TCP, we came up against an interesting question: Viewing
H-FP as "just an interface at a distance" to a TCP PI, what about
the Allocate "Interface Event" in the TCP spec? As far as I'm
concerned, this could be classed as a non-issue, because I submit
that the spec is wrong in declaring that there is such a thing as
a MANDATORY Interface Event whereby the user of a TCP PI lets the
PI know how much data it can take. Granted, you might find such a
thing in most implementations, but what if you were in a virtual
memory environment with segment sharing (or a distributed
supervisor) and you wanted to avoid copies, so all that passed at
the interface to the PI (or even at the interface from the PI) was
a pointer? That is, the "DOD version" of the TCP spec has fallen
into the trap of assuming things about the execution environment
that it shouldn't have.
本当に、新しいH-FPがTCPを積み下ろすかどうかを見るために精神的にテストしている間、私たちは面白い質問に直面していました: TCP仕様に基づくTCP PIへの「まさしく距離のインタフェース」であるとH-FPをみなすAllocate「インタフェース出来事」はどうですか? 私の考えとしては、どうでもいい問題としてこれを分類できました、私が、TCP PIのユーザが、それがどのくらいのデータを取ることができるかをPIに知らせるMANDATORY Interface Eventのようなものがあると宣言する際に仕様が間違っているのを提出するので。 インタフェースでPI(またはPIからのインタフェースでさえ)に通過されたそのすべてがポインタであっ、与えて、ほとんどの実現でそのようなものを見つけるかもしれませんが、仮想記憶環境にはあなたがセグメント共有(または、分配された監督)と共にいて、あなたがコピーを避けたかった場合、どうなるでしょうか? すなわち、TCP仕様の「DODバージョン」はそれが持つべきでない実行環境に関して仮定ものの罠になりました。
One moral of this is that
この1つの教訓がそれです。
AN INTERFACE TO AN INTERPRETER OF A PROTOCOL IS N*O*T "THE
PROTOCOL".
プロトコルのインタプリタへのインタフェースはN*O*T「プロトコル」です。
Another moral is that the interface to the Host-side H-FP PI is
hard to say much about, but is where the equivalent functionality
will be found if you've offloaded TCP. That is, it's reasonable
to let the user "tell" the outboard PI at Begin time if big or
small buffers are expected to be in play "net-ward" as part of the
protocol, but the outboard PI is expected to deliver bits to the
Host as they come unless throttled by the Channel Layer, or by
some to-be-invented other discipline to force the OPE to buffer.
(For present purposes, we envision letting the Channel Layer
handle it, but nifty mechanizations of encouraging the OPE to
"make like a buffer" would be at least looked at.) As a
Fabrication issue, it is the case that "equity" has to be dealt
with with regard to the use of the OPE's resources (especially
buffers) across H-FP connections/channels, but that's a different
issue anyway, touched upon in the final fine point.
Host-サイドH-FP PIへのインタフェースがたくさん言いにくいということですが、別の教訓は、あなたがTCPを積み下ろしたなら同等な機能性が見つけられるところです。 英仏海峡Layer、またはOPEにバッファリングさせる何らかの他の発明された規律によって阻止されない場合、来るときユーザに大きいか小さいバッファが予想されるならしかし、プロトコルの一部、船外のPIとしての「ネットの区」のプレーにあるのが予想されるBegin時にビットが配送されていると船外のPIにHostに「言わせること」がすなわち、それは妥当です。 (現在の目的のために、英仏海峡Layerにそれを扱わせるしかし、「バッファをまねてください」へのOPEが少なくとも見られる奨励のかっこよい機械化を私たちは思い描きます。) Fabrication問題として、「公平さ」がH-FP接続/チャンネルの向こう側にOPEのリソース(特にバッファ)の使用に関して対処されなければならないのが、事実ですが、それはとにかく別問題です、最終的なすばらしいポイントでは、触ります。
Padlipsky [Page 13]
Padlipsky[13ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
Precedence
先行
Clearly, the existence of a notion of Precedence in DOD protocols
has to get reflected in the outboard PI's implementations. Just
what, if any, role it has in the H-FP, per se, is, however, by no
means clear. That is, if the Host doesn't take Begins from the
OPE and is "full up" on the number of Server Telnet connections
it's willing to handle, what should happen if a high precedence
SYN comes in on the Telnet Well-Known Socket (in present day
terms)? Probably the OPE should arbitrarily close a low
precedence connection to make room for the new one, and signal the
Host, but even that assumes the Host will always hurry to be
prepared to do a new passive Begin. Perhaps we've stumbled across
still another argument in favor of "Symmetric Begins".... At any
rate, Precedence does need further study--although it shouldn't
deter us from making "the rest" of the protocol work while we're
waiting for inspiration on how to handle Precedence too.
明確に、DODプロトコルのPrecedenceの概念の存在は船外のPIの実現に反映されなければなりません。 しかしながら、それがH-FPにそういうものとして持っている役割がどんなであるもちょうど何であるかが決してクリアされません。 それはいます、そして、Hostがそうしないなら、OPEからBeginsを取ってください、そして、「完全」がTelnet Wellによって知られているSocket(近代の用語による)にそれが扱っても構わないと思っているServer Telnet接続、SYNが来る高い先行であるなら起こるべきであることに関する数にありますか? たぶん、OPEは新しいもの、および信号の場所をHostにするように任意に低い先行接続を終えるはずですが、それさえ、Hostが新しい受け身のBeginをするように準備されるためにいつも急ぐと仮定します。 を支持して、恐らく、私たちがまだ別の議論を偶然見つけた、「左右対称である、始まり、」、… いずれにせよ、私たちがどうPrecedenceも扱うかにおけるインスピレーションを待っている間、プロトコル仕事の「残り」を作るのから私たちを妨げるべきではありませんが、Precedenceはさらなる研究を必要とします。
A Note on Host Integration
ホスト統合に関する注
The most important thing about Hosts in any intercomputer network is that they furnish the resources to be shared. The most significant obstacle to sharing those resources, however, is the fact that almost invariably they were designed under the assumption that the Host was a fully autonomous entity. That is, few operating systems currently deployed "expect" to be members of a heterogeneous community of operating systems. In many cases, this built-in insularity goes so far as to have applications programs cognizant of the particular type of terminal from which they will be invoked.
どんなintercomputerネットワークでもHostsの周りの最も重要なものは彼らが共有されるためにリソースを提供するということです。 しかしながら、それらのリソースを共有することへの最も重要な障害はほぼ不変的に、それらがHostが完全に自治の実体であったという仮定で設計されたという事実です。 すなわち、現在配備されているわずかなオペレーティングシステムしか、オペレーティングシステムの種々雑多な共同体のメンバーであると「予想しません」。多くの場合、この内蔵の島であることで、アプリケーションプログラムはそれらが呼び出される特定のタイプの端末において認識力があるようになりさえします。
Intercomputer networking protocols attempt to resolve the problems of heterogeneity by virtue of presenting appropriate common intermediate representations (or "virtualizations") of the constructs and concepts necessary to do resource sharing. A Host-Host protocol such as TCP "is" a virtual interprocess communication mechanism; a virtual terminal protocol such as Telnet obviously is a mechanism for defining and dealing with virtual terminals; FTP offers common representations of files; and so on. It cannot be stressed strongly enough, though, that this entire approach to intercomputer networking is predicated on the assumption that the modules which interpret the protocols (PIs, as we'll refer to them often) will be PROPERLY integrated into the various participating operating systems. Even in the presence of powerful OPEs, wherein the bulk of the work of the various PIs is performed outboard of the Host, the inboard "hooks" which serve to interface the outboard PIs to the native system must not only be present, they must be "right". The argument parallels the analysis of the flexible vs. rigid front-ending attachment
Intercomputerネットワーク・プロトコルは、リソース・シェアリングをするのに必要な構造物と概念の適切な共通中間体表現(または、「仮想化」)を提示することによって異種性の問題を解決するのを試みます。 Host-ホストは「存在TCPなど」のように仮想のプロセス間通信メカニズムについて議定書の中で述べます。 Telnetなどの仮想端末プロトコルは明らかに仮想端末を定義して、対処するためのメカニズムです。 FTPはファイルの共通表現を提供します。 など。 もっとも、intercomputerネットワークへのこの全体のアプローチがプロトコル(PIs、私たちがそうするつもりであるように、しばしば彼らを参照する)を解釈するモジュールが強力なOPEsの面前で同等の様々な参加オペレーティングシステムと統合されたPROPERLYになるという前提で叙述されると十分強く強調できません; 様々なPIsの仕事の大半が船外でHostについて実行されるところに船外のPIsを固有のシステムに接続するのに役立つ機内の「フック」が存在しているだけであるはずがない、彼らは「まさしく」ということであるに違いありません。 議論は堅い前の結末に対してフレキシブルな付属の分析に沿います。
Padlipsky [Page 14]
Padlipsky[14ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
strategy issue of [1]; to borrow an example, if you attempt to integrate FTP by "looking like" a native terminal user and the operator forces a message to all terminals, you've got an undetected pollution of your data stream. So the key issue in attaching Hosts to networks is not what sort of hardware is required or what sort of protocol is interpreted by the Host and the OPE (or comm subnet processor, for that matter), but how the PIs (full or partial) are made to interrelate with the pre-existing environment.
[1]の戦略問題。 例を借りるために、あなたが、ネイティブの端末ユーザが「似」であることによってFTPを統合するのを試みて、オペレータがすべての端末にメッセージを強制するなら、あなたにはあなたのデータ・ストリームの非検出された汚染があります。 それで、ネットワークへの付けHostsの主要な問題はどういうハードウェアが必要であるかではなく、どういうプロトコルがHostとOPE(または、さらに言えば、サブネットプロセッサをcommする)によって解釈されるか、しかし、PIs(完全であるか部分的な)は先在の環境でどのように相互に関係づけさせられるかということです。
It would be well beyond the scope of this document to attempt even to sketch (much less specify) how to integrate H-FP PIs into each type of operating system which will be found in the DoD. An example, though, should be of use and interest. Therefore, because it is the implementation with which we are most intimately familiar, even though it's been several years, we propose to sketch the Multics operating system integration of the original ARPANET Network Control Program (NCP)--which is functionally equivalent to an H-FP PI for offloading ARM L II and L I--and Telnet. (A few comments will also be made about FTP.) Note, by the way, that the sketch is for a "full-blown" H-FP; that is, shortcuts along the lines of the scenario-driven approach mentioned above are not dealt with here.
それは、どうDoDで見つけられるそれぞれのタイプのオペレーティングシステムとH-FP PIsを統合するかをスケッチするのさえ(まして、指定します)試みるためにかなりこのドキュメントの範囲を超えているでしょう。 もっとも、例は使用と関心のものであるべきです。 したがって、それがそれが数年ですが、私たちが親密に最も詳しい実現であるので、オリジナルのアルパネットNetwork Control Program(NCP)のMulticsオペレーティングシステム統合についてスケッチするよう提案します--LのARM L IIを積み下ろすのに、どれがH-FP PIに機能上同等であるか、そして、私、およびTelnet。 (また、FTPに関していくつかのコメントをするでしょう。) スケッチが「花盛り」のH-FPのためのものであることにところで、注意してください。 すなわち、前記のようにシナリオ駆動のアプローチの線に沿った近道はここで対処されていません。
One of the particularly interesting features of Multics is the fact that each process possesses an extremely large "segmented virtual memory". That is, memory references other than to the segment at hand (which can itself be up to 256K 36-bit words long) indirect through a descriptor segment, which is in principle "just another segment", by segment number and offset within the segment, so that a single process--or "scheduling and access control entity"--can contain rather impressive amounts of code and data. Given that the code is "pure procedure" (or "re-entrant"), a "distributed supervisor" approach is natural; each process, then, appears to have in its address space a copy of each procedure segment (with system-wide and process-specific data segments handled appropriately). Without going too far afield, the distributed supervisor approach allows interrupts to be processed by whichever process happens to be running at a given time, although, of course, interprocess communication may well be a consequence of processing a particular interrupt.
Multicsの特におもしろい特徴の1つは各過程が非常に大きい「区分された仮想記憶」を所有しているという事実です。 すなわち、手元のセグメント以外のメモリ参照、(どの缶自体が、「スケジューリングとアクセス管理実体」というただ一つの過程がかなり印象的な量のコードとデータを含むことができるように、セグメント番号に従って原則として「ただのセグメント」である記述子セグメントを通して間接的な最大256K36ビットの単語長さであり、セグメントの中で相殺されますか? コードが「純粋な手順」(または、「リエントラント」)であるなら、「分配された監督」アプローチは当然です。 そして、各過程はアドレス空間でそれぞれの手順セグメント(システム全体の、そして、過程特有のデータ・セグメントが適切に扱われている)のコピーを持っているように見えます。 遠くで度が過ぎないで、分配された監督アプローチは、中断が一時にたまたま走るどの工程で処理されるかを許容します、プロセス間通信がもちろんたぶん特定の中断を処理する結果でしょうが。
A few other necessary background points: A distinguished process, called the Answering Service, exists, originally to field interrupts from terminals and in general to create processes after authenticating them. Other shared resources such as line printers are also managed by distinguished processes, generically known as "Daemons". Device driver code, as is customary on many operating systems, resides at least in part in the supervisor (or hard core
他の必要なバックグラウンド数ポイント: 一般に、Answering Serviceと呼ばれる顕著なプロセスは、それらを認証した後にプロセスを作成するために元々端末からの分野中断するのに存在しています。 ラインプリンタなどの他の共用資源は、また、顕著なプロセスによって管理されていて、「デーモン」として一般的に知られています。 デバイスドライバコードが監督に常として多くのオペレーティングシステムに少なくとも一部ある、(中核
Padlipsky [Page 15]
Padlipsky[15ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
operating system). Finally (for our purposes, at least), within a process all interfaces are by closed subroutine calls and all I/O is done by generic function calls on symbolically named streams; also, all system commands (and, of course, user written programs which need to) use the streams "user_input" and "user_output" for the obvious purposes. (At normal process creation time, both user I/O streams are "attached" to the user's terminal, but either or both can be attached to any other I/O system interface module instead--including to one which reads and writes files, which is handy for consoleless processes.)
オペレーティングシステム) 最終的に(私たちの目的のために少なくとも)、プロセスの中に、すべてのインタフェースが閉じたサブルーチン呼び出しであります、そして、象徴的に命名されたストリームでジェネリックファンクションコールですべての入出力をします。 また、すべてのシステム・コマンド(もちろん必要があるユーザ書面計画)が明白な目的に「ユーザ_は入力した」ストリームと「ユーザ_出力」を使用します。 (正常なプロセス作成時間に、両方のユーザ入出力ストリームをユーザの端末に「付けられています」が、代わりにどちらかかともにいかなる他の入出力システムインタフェース・モジュールにも付けることができます--どれがファイルを読み書きするかを1つに含めますconsolelessプロセスに、便利な)
All that almost assuredly doesn't do justice to Multics, but equally likely is more than most readers of this document want to know, so let's hope it's enough to make the following integration sketch comprehensible. (There will be some conscious omissions in the sketch, and doubtless some unconscious ones, but if memory serves, no known lies have been included.)
そのすべてがほぼ確かにMulticsを公平に扱いませんが、このドキュメントのほとんどの読者が知りたがっているより等しくおそらく多いので、以下の統合スケッチを分かりやすくするのが十分であることを望みましょう。 (スケッチにおける省略であり、いくつかの無意識のものであり記憶が確かであるなら、確かに、知られている偽りが全く含まれていないのを意識がある何かがあるでしょう。)
Recalling that NCP is functionally equivalent to H-FP, let's start with it. In the first place, the device driver for the 1822 spec hardware interface resides in the supervisor. (For most systems, the PI for H-FP's link protocol probably would too.) In Multics, interrupt time processing can only be performed by supervisor segments, so in the interests of efficiency, both the IMP-Host (1822 software) Protocol PI and the multiplexing/demultiplexing aspects of the Host-Host Protocol PI also reside in the supervisor. (An H-FP PI would probably also have its multiplexing/demultiplexing there; that is, that portion of the Channel Layer code which mediates access to the OPE and/or decides what process a given message is to be sent to might well be in the supervisor for efficiency reasons. It is not, however, a hard and fast rule that it would be so. The system's native interprocess communications mechanism's characteristics might allow all the Channel Layer to reside outside of the supervisor.)
NCPがH-FPに機能上同等であると思い出して、それから始めましょう。 第一に、1822年の仕様ハードウェア・インタフェースへのデバイスドライバは監督にあります。 (ほとんどのシステムのために、H-FPのリンク・プロトコルのためのPIはたぶんまた、そうするでしょう。) Multicsでは、監督セグメントで中断時間処理を実行できるだけであるので、効率のために、IMP-ホスト(1822年のソフトウェア)プロトコルPIとHost-ホストプロトコルPIのマルチプレクシング/逆多重化局面の両方がまた、監督にあります。 (また、H-FP PIはたぶんそこにマルチプレクシング/逆多重化を持っているでしょう。 すなわち、OPEへのアクセスを調停する、そして/または、与えられたメッセージがたぶんであることができるどんなプロセスに送られることになっているかを決める英仏海峡Layerコードのその部分は効率のための監督で推論します。 しかしながら、それはそうであるだろうという鉄則ではありません。 システムの固有のプロセス間通信メカニズムの特性で、すべての英仏海峡Layerが監督の外に住むことができるかもしれません。)
Even with a very large virtual memory, though, there are administrative biases against putting too much in the supervisor, so "everything else" lives outside the supervisor. In fact, there are two places where the rest of the Host-Host Protocol is interpreted on Multics, although it is not necessarily the case that an H-FP PI would follow the same partitioning even on Multics, much less on some other operating system. However, with NCP, because there is a distinguished "control link" over which Host-Host commands are sent in the NCP's Host-Host protocol, the Multics IMP-Host Protocol PI relegates such traffic to a Network Daemon process, which naturally is a key element in the architecture. (Things would be more efficient, though, if there weren't a separate Daemon, because other processes then have to get involved with interprocess communication
もっとも、監督を入れ過ぎることに反対して管理偏見がいるので、非常に大きい仮想記憶があっても、「他の何もかも」は監督の外に生きています。 事実上、2つの場所がHost-ホストプロトコルの残りがMulticsで解釈されるところにあります、H-FP PIがMulticsさえの同じ仕切りに続くのが、必ず事実であるというわけではありませんが、まして、ある他のオペレーティングシステムで。 しかしながら、NCPで、Host-ホストコマンドがNCPのHost-ホストプロトコルで送られる顕著な「コントロールリンク」があるので、Multics IMP-ホストプロトコルPIはそのようなトラフィックをNetwork Daemonプロセスに左遷します。(自然に、それは、アーキテクチャの主要な要素です)。 (もっとも、別々のDaemonがなければ、いろいろなことは、より効率的でしょうに、次に、他のプロセスがプロセス間通信にかかわらなければならないので
Padlipsky [Page 16]
Padlipsky[16ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
to it; H-FP PI designers take note.) To avoid traversing the Daemon for all traffic, though, normal reads and writes (i.e., noncontrol link traffic) are done by the appropriate user process. By virtue of the distributed supervisor approach, then, there is a supervisor call interface to "the NCP" available to procedures (programs) within user processes. (The Daemon process uses the same interface, but by virtue of its ID has the ability to exercise certain privileged primitives as well.)
それに。 H-FP PIデザイナーはノートを取ります。) もっとも、横断するのを避けるために、適切なユーザ・プロセスですべてのトラフィックのためのDaemonをします標準が、読んで、書く(すなわち、非コントロールリンクトラフィック)。 そして、分配された監督アプローチによって、ユーザ・プロセスの中で手順(プログラム)に利用可能な「NCP」へのスーパーバイザコールインタフェースがあります。 (Daemonプロセスには、同じインタフェースを使用しますが、IDによるまた、ある特権がある基関数を運動させる能力があります。)
If a native process (perhaps one meaning to do "User Telnet", but not limited to that) wanted to use the network, it would call the open primitive of "the NCP", do reads and writes, and so on. An interesting point has to do with just how this interface works: The reads are inherently asynchronous; that is, you don't know just when the data from the net are going to be available. In Multics, there's an "event" mechanism that's used in the NCP interface that allows the calling process to decide whether or not it will go blocked waiting for input when it reads the net (it might want to stay active in order to keep outputting, but need to be prepared for input as well), so asynchrony can be dealt with. In the version of Unix (tm) on which an early NFE was based, however, native I/O was always synchronous; so in order to deal with both input from the terminal and input from the net, that system's User Telnet had to consist of two processes (which is not very efficient of system resources). Similar considerations might apply to other operating systems integrating H-FP; native I/O and interprocess communication disciplines have to be taken into account in designing. (Nor can one simply posit a brand new approach for "the network", because Telnet will prove to rely even more heavily on native mode assumptions.)
ネイティブのプロセス(「ユーザtelnet」、他にそれをする恐らく1つの意味)であるなら、ネットワークを使用して欲しくて、それは、など戸外が「NCP」で原始的であると言って、読書して、書きます。 おもしろいポイントはこのインタフェースがいったいどう働いているかと関係があります: 読書は本来非同期です。 すなわち、あなたは、ネットからのデータがいったいいつ利用可能になるかを知りません。 Multicsでは、呼び出しプロセスがネットを読むとき(それは、出力し続けるためにアクティブなままでありたいのですが、また、入力のために準備される必要があるかもしれません)、入力を待ちながらそれが妨げられるのに行くかどうか決めることができるNCPインタフェースで使用される「イベント」メカニズムがあるので、非同期に対処できます。 しかしながら、前のNFEが基づいたUnix(tm)のバージョンでは、ネイティブの入出力はいつも同時でした。 それで、端末と入力からネットから入力された両方に対処するために、そのシステムのUser Telnetは2つのプロセスから成らなければなりませんでした(システム資源でそれほど効率的ではありません)。 同様の問題はH-FPを統合しながら、他のオペレーティングシステムに適用されるかもしれません。 ネイティブの入出力とプロセス間通信規律は設計で考慮に入れられなければなりません。 (または、Telnetが、さらに大いにネイティブモード仮定に依存すると判明するので、1つは「ネットワーク」のための真新しいアプローチを絶対に置くことができません。)
The other aspect of NCP integration which we should at least touch on--especially because process-level protocols make no sense without it--is how "Well-Known Sockets" (WKSs) work. In broad terms, on Multics the Network Daemon initially "owns" all sockets. For Well-Known Sockets, where a particular process-level protocol will be in effect after a successful connection to a given WKS, code is added to the Answering Service to call upon the NCP at system initialization time to be the process "listening" on the WKSs. (This is a consequence of the fact that the Answering Service is/was the only Multics process which can create processes; strategies on other systems would differ according to their native process creation disciplines.) How to get the "right kind of process" will be sketched in the discussions of the process level protocols, but the significant notion for now is that typically SOME sort of prior arrangement would be done by any networked Host to associate the right kind of process with a WKS.
特にプロセスレベルプロトコルがそれなしで意味をなさないので私たちが少なくとも触れるべきであるNCP統合のもう片方の局面は「よく知られるソケット」(WKSs)がどう働いているかということです。 大きく見ると、Multicsでは、Network Daemonは初めは、すべてのソケットを「所有しています」。 Wellによって知られているSocketsに関しては、コードは、WKSsのプロセス「聴取」であるシステム初期化時にNCPを訪問するためにAnswering Serviceに加えられます。そこでは、特定のプロセスレベルプロトコルがうまくいっている接続の後に与えられたWKSに有効になるでしょう。 (これによるAnswering Serviceが/である事実の結果はプロセスを作成できる唯一のMulticsプロセスでした; それらの固有のプロセス作成規律によると、他のシステムの戦略が異なるだろうということです。) 得るために、「プロセスの正しい種類」はどうWKSがあるプロセスのことになるだろうか描き加えられて、プロセスの議論がプロトコルを平らにします、しかし、通常、どんなネットワークでつながれたHostも正しい種類を関連づけるために先のアレンジメントのSOME種類をするだろうという重要な概念が当分あるという。
Padlipsky [Page 17]
Padlipsky[17ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
Now, we don't expect that the foregoing will enable even the world's greatest system jock to go out and design the integration of an H-FP PI for a system that had never been networked (in the ARPANET style of networking) before. But we propose to stop there and turn to some comments on process level protocols, for two reasons: In the first place, it would take us much too far afield to go into significantly greater detail; and in the second place, because of the functional equivalence of H-FP and NCP combined with the number of operating systems which have integrated NCP and, for that matter, TCP/IP, which are also functionally equivalent to H-FP (used for offloading L II and L I), models are available in the ARPANET community and concerned H-FP PI implementors can follow them.
今、私たちは、上記が、世界の最も偉大なシステム運動選手さえ出かけて、以前一度もネットワークでつながれたことがなかった(ネットワークのアルパネットスタイルで)システムのためにH-FP PIの統合を設計するのを可能にすると予想しません。 しかし、私たちは、2つの理由にプロセスで平らなプロトコルをそこで止めて、いくつかのコメントにターンするよう提案します: 第一に、かなりすばらしい詳細を調べるのに遠くで私たちを非常にはるかに要し過ぎるでしょう。 そして、また、H-FP(L IIとL Iを積み下ろすために、使用される)に機能上同等なNCPとさらに言えば、TCP/IPを統合したオペレーティングシステムの数に結合されたH-FPとNCPの機能的な等価性で、第二に、モデルはアルパネット共同体に手があいています、そして、関係があるH-FP PI作成者は彼らの後をつけることができます。
Turning to Telnet integration, and returning to Multics as an example, we note that "User Telnet" is straightforward. "All you need" (for small values of "all") from an INBOARD User Telnet is a command that gives the user some sort of interface, converts between the native Multics character set and terminal discipline and the Network Virtual Terminal equivalents (and as Multics is very generic when it comes to I/O, that's not hard), and writes and reads "the net" (more accurately, calls upon the Host-Host protocol PI--or upon the H-FP PI to get at the H-HP--appropriately). (One point that's not obvious: make the Well-Known Socket "on the other side" a parameter, defaulting to the Telnet WKS, because you'll want to use the same command to get at other process-level protocols.) If there's an OPE in play which offloads User Telnet, however, things can be even simpler: the inboard command just reads and writes the terminal and lets the OUTBOARD User Telnet PI handle the conversion to and from the Virtual Terminal form (presumably, from and to the desired local form).
Telnet統合に変わって、例としてMulticsに戻って、私たちは、「ユーザtelnet」が簡単であることに注意します。 「あなたが必要とするすべて、」 (「すべて」の小さい値のための) INBOARD User Telnetから、「ネット」をある種のインタフェース、ネイティブのMultics文字集合と端末の規律の間の転向者、およびNetwork Virtual Terminal同等物(入出力のこととなるとMulticsがまさしくそのジェネリックであるので、それは困難でない)をユーザに与えて、書いて、読み込むコマンドは来ています(PIについて議定書の中で述べるか、または、より正確に、Host-ホストでの呼び出しは適切にH-HPに達するためにH-FP PIでそうします)。 (明白でない1ポイント: 「反対側」のWellによって知られているSocketをパラメタにしてください、Telnet WKSをデフォルトとして、あなたが他のプロセスレベルプロトコルに達する同じコマンドを使用したくなるので。) しかしながら、User Telnetを積み下ろすプレーにOPEがあれば、いろいろなことはさらに簡単である場合があります: 機内のコマンドで、フォームとVirtual Terminalフォーム(おそらく、そして、フォームと必要な地方のフォームへの)からただ端末を読み書きして、OUTBOARD User Telnet PIは変換を扱います。
When it comes to the incoming ("Server") aspects of Telnet, life can
get complicated on some systems for an inboard implementation.
However, fortunately for our purposes,
Telnetの入って来る(「サーバ」)局面のこととなると、寿命は機内の実装のいくつかのシステムの上でこじれることができます。 しかしながら、幸い、私たちの目的のために
Multics' native mechanisms lend themselves readily to integration; an awareness of the inboard issues will be useful even if in response to a connection attempt on the Telnet WKS, the (Server) Host is obligated to associate the connection (the actual logic is somewhat more complex under the ARPANET Host-Host Protocol, which employs paired simplex connections) with a process that is prepared to translate between Telnet and native mode representations and otherwise "look like" a local user process--that is, in particular the connection becomes an I/O source/sink to the native command processor on time-sharing systems. As indicated, process creation is taken care of in Multics by having the Answering Service process listen on the WKS. Because the Answering Service is in some sense
Multicsの固有のメカニズムは容易に自分たちを統合に与えます。 Telnet WKSへの接続試みに対応して(サーバ)ホストがTelnetとネイティブモード表現の間で翻訳して、別の方法で、ローカルのユーザ・プロセス()に「似る」ように準備されるプロセスとの接続(実際の論理はアルパネットHost-ホストプロトコルの下でいくらか複雑であり、その雇用はシンプレクス接続を対にした)を関連づけるのが義務付けられても、機内の問題の認識は役に立ちます; システムを時分割するとき、特に、接続はネイティブのコマンドプロセサへの入出力ソース/流し台になります; 示されるように、Answering ServiceプロセスをWKSで聴かせることによって、プロセス作成はMulticsで世話をされます。 何らかの意味にはAnswering Serviceがあるので
Padlipsky [Page 18]
Padlipsky[18ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
just another Multics process, it too does user I/O through the normal system mechanisms. So while for local terminals the user I/O streams are attached through a module called "ttydim" (where "dim" stands for "device interface module"), NVTs are attached through a functionally equivalent and identically invoked module called "nttydim" (the Answering Service knows which DIM to use based on the symbolic designator of the "line" on which it received the interrupt, as it happens).
ただのMulticsプロセス、それも正常なシステム機構を通したユーザ入出力をします。したがって、ユーザ入出力ストリームはローカル・ターミナルに関して"ttydim"(「薄暗くしてください」が「デバイスインタフェース・モジュール」を表すところ)と呼ばれるモジュールで付けられていますが、NVTsは"nttydim"と呼ばれる機能上同等で同様に呼び出されたモジュールで取り付けられます(Answering Serviceは、それが中断を受けた「系列」のシンボリックな指示子に基づいてどのDIMを使用したらよいかを知っています、たまたま)。
[The notion of "attaching" the streams bears a bit more explanation: Attach is a primitive of the Multics generic I/O mechanism which associates a stream name and a particular DIM (or I/O system interface module in later terminology); the other I/O primitives (read, write, etc.) are invoked with the stream name as a parameter and an I/O "switch" causes the entry point corresponding to the primitive to be invoked in whichever DIM the stream is currently attached to. So a Server Telnet process starts life attached through nttydim to a particular network connection, while a local process starts life attached through ttydim to a particular physical line, and both processes proceed indistinguishably (viewed from outside the I/O switch, anyway).]
[ストリームの「付け」であるという概念はもう少しの説明に堪えます: 付く、ストリーム名を関連づけるMulticsジェネリック入出力メカニズムと特定のDIM(または、後の用語の入出力システムインタフェース・モジュール)に関する基関数です。 パラメタと入出力「スイッチ」がストリームが現在付けられるどのDIMで原始に対応するエントリー・ポイントを呼び出させるかとき、他の入出力基関数(読んで、書きますなど)はストリーム名で呼び出されます。 それで、Server Telnetプロセスはnttydimを通して特定のネットワーク接続に愛着している寿命を始めます、地方のプロセスがttydimを通して特定の物理行に付けられた寿命を始めます、そして、両方のプロセスは見分けのつかないほど(入出力がとにかく切り換える外部から、見られる)続きますが。]
The pre-existing orderliness that makes things easy on Multics does not, unfortunately, appear in all operating systems. Indeed, delicate choices occasionally have to be made as to WHICH native terminal to map to on systems that don't do generic I/O in native mode, and it is likely that for some systems the particular mapping to bring into play in Server Telnet might be determined by the particular application program invoked. This issue can become very touchy when the application "expects" a "data entry terminal", say. The Server Telnet for such a system would naturally attempt to negotiate the "DET" option with the corresponding User Telnet. But the user might be at a physical terminal that isn't a member of the DET class, so that User Telnet must either refuse to negotiate the option or--and we would recommend this alternative strongly, as it seems to be within the "spirit" of the protocol--offer some sort of simulation, however crude, of the behavior of a DET. Also, something sensible has to be done on systems where there is no clear analog of the command processor expected to be managing the Server process. (Say, when a "menu" of applications is always displayed on an available terminal in native mode.)
残念ながら、事態をMulticsで簡単にする先在の規則的はオペレーティングシステム本当に、デリケートな選択が時折WHICHネイティブに関してされなければならないすべてで写像するためにネイティブモードにおけるジェネリック入出力をしないシステムの上で端末に見えません、そして、いくつかのシステムにおいて、Server Telnetでのプレーにもたらす特定のマッピングは呼び出された特定用途プログラムで決定しそうです。 この問題は、アプリケーションが「データ・エントリ端末」を「予想する」とき、非常に扱いにくくなって、言うことができます。 そのようなシステムのためのServer Telnetは、"DET"オプションを対応するユーザtelnetと交渉するのを自然に試みるでしょう。 または、しかし、ユーザはDETのクラスのメンバーでない物理端末にいるかもしれません、User Telnetが、オプションを交渉するのを拒否しなければならないように--私たちが強くこの代替手段を推薦するでしょう、プロトコルの「精神」の中にあるように思えるように--ある種のシミュレーションを提供してください、どんなに粗雑であってもDETの動きで。 また、Serverプロセスを管理していると予想されたコマンドプロセサのどんな明確なアナログもないシステムの上で何か分別があることをしなければなりません。 (たとえば利用可能な端末にネイティブモードでアプリケーションの「メニュー」をいつも表示するとき。)
A final Telnet integration issue (although other points could be noted, we're not pretending to be exhaustive and this should be enough to "give the flavor"): The Telnet Interrupt Process generic function calls for particularly careful integration. Here, the intent of the function is to virtualize what is called the "quit
最終的なTelnet統合問題(他のポイントに注意できました、そして、私たちは、徹底的であるふりをしていません、そして、これは「風味を与える」ために十分であるべきですが): Telnet Interrupt Processジェネリック機能は特に慎重な統合を求めます。 ここで、機能の意図はいわゆる「辞任」をvirtualizeすることです。
Padlipsky [Page 19]
Padlipsky[19ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
button" on some systems. That is, the user wants the system to interrupt his process (which may, for example, be in a loop) and get back to the command processor (or "the system" itself). On native character-at-a-time systems, the native mechanism is usually the entering of a particular "control character"; on native line-at-a-time systems, the native mechanism is usually the striking of the "ATTN" or Interrupt button or the "Break" key (sometimes more than once, to distinguish it from a communication to the executing program). But the native mechanisms typically involve interrupt time code, and Server Telnet typically wouldn't be executing at that level, so the solution (omitting the intricacies of the interaction with the NCP or the H-FP PI, which also get into the act) would be to make use of--in the Multics case--a pre-existing INTRAprocess signal, or to add such a mechanism (unless the architecture chosen has a Server Telnet Daemon of some sort, in which case an INTERprocess signal would be needed).
いくつかのシステムすなわち、ユーザがシステムが欲しい「ボタン」は、彼のプロセス(例えば、輪にあるかもしれない)を中断して、コマンドプロセサ(または、「システム」自体)に戻ります。 固有の一度にキャラクタシステムに、通常、固有のメカニズムは特定の「制御文字」について入ることです。 通常、固有の一度に系列システムに、固有のメカニズムが"ATTN"、中断ボタンまたは「中断」キーの打撃であることである、(一度時々以上、コミュニケーションからプログラムを実行までそれを区別する、) したがって、ソリューション(また、加わるNCPかH-FP PIとの相互作用の複雑さを省略する)は、しかし、固有のメカニズムが中断時間コードに通常かかわります、そして、Server Telnetがおまけに、レベルを通常実行していないだろうか、Multics場合で先在のINTRAprocess信号を利用するか、またはそのようなメカニズムを加えるだろう(選ばれたアーキテクチャがある種のServer Telnet Daemonを持っていない場合、その場合、INTERprocess信号が必要でしょう)ことです。
The extension of the foregoing to an outboard Server Telnet may not be obvious, but we won't expend a great deal of time on it here. Even if "the protocol" is being handled in an OPE, the Host-side software must be able to associate an H-FP connection with the command language interpreter of a user process and to respond appropriately to an H-FP Signal command if it arrives, and the OPE must know not only the desired character set but also the local equivalents of Erase and Kill, at the minimum.
船外のServer Telnetへの上記の拡大は明白でないかもしれませんが、私たちは多くの時間ここでそれを使うつもりではありません。 「プロトコル」がOPEで扱われても、Host-サイドソフトウェアは、ユーザ・プロセスのコマンド言語インタプリタとのH-FP接続を関連づけて、到着して、OPEが必要な文字集合だけではなく、EraseとKillの地方の同等物も知らなければならないなら、適切にH-FP Signalコマンドに応じることができなければなりません、最小限で。
We'll skip FTP integration, on the grounds that this note is already too lengthy, except to mention that in the OUTBOARD case it's still going to be necessary to convey the name of the appropriate file and directory to/from some appropriate Host-side code. (Similar problems must be dealt with for outboard handling of "mail" if it's not part of FTP.)
私たちはFTP統合をサボるつもりです、この注意が既に長過ぎるので、OUTBOARD場合では、何らかの適切なHost-サイドコードからの/に適切なファイルとディレクトリの名前を伝えるのがまだ必要であると言及するのを除いて。 (それがFTPの一部でないなら「メール」の船外の取り扱いのために同様の問題に対処しなければなりません。)
One other "integration" issue, which has been hinted at earlier and about which not much can be said beyond some general guidelines: The "top edge" of a Host-side H-FP protocol interpreter (i.e., the Host user program interface, for
1他の「統合」冊:(それに関して、より早くほのめかして、いくつかの一般的ガイドラインで多くを言うことができるというわけではありません)。 Host-サイドH-FPの「先頭の縁」はインタプリタについて議定書の中で述べます。(すなわち、Hostユーザ・プログラムは連結します。
Hosts that are "doing real networking" rather than just using the OPE to get at User Telnet and/or FTP and to offer Server Telnet and/or FTP [and maybe "mail"], presumably in the "scenario-driven" fashion sketched earlier) MUST BE APPROPRIATE TO THE HOST. In other words, on Multics, where "everything" is closed subroutines, there would presumably be a closed subroutine interface with event channels for reads, pointers to buffers, and all that sort of thing, but on some other style of operating system, the interface to the H-FP PI might turn out to be "all" interprocess communication, or to "look like" a
User Telnet、そして/または、FTPに達して、Server Telnet、そして/または、FTP[そして、多分「メール」]を提供するのにただOPEを使用するよりむしろ「本当のネットワークをしている」ホストさらに早くおそらく「シナリオ駆動」のファッションでスケッチされて、 MUST BE APPROPRIATE TO THE HOST言い換えれば、Multicsの上に読書のためのイベントチャンネルとの閉じたサブルーチンインタフェース、バッファへの指針、およびそのすべての種類のものがおそらくあるでしょうが、ある他のスタイルのオペレーティングシステムでは、H-FP PIへのインタフェースは、「all」のプロセス間通信であるかaに「似る」ように判明するかもしれません。そこでは、「すべて」が閉じたサブルーチンです。
Padlipsky [Page 20]
Padlipsky[20ページ]
RFC 928 December 1984 Introduction to H-FP
H-fpへのRFC928 1984年12月の序論
device of some special class, or "all" system calls/JSYSs/EOTs/Whatevers. We can't be much more specific, but we'd be remiss to convey any impression that H-FP is a "free lunch". As noted, an H-FP PI requires the same kind of integration as a generic NCP--it's just smaller, and serves as insulation against changes (in the offloaded protocols in general, or in the proximate comm subnet in particular).
何らかの特別なクラスのデバイス、または「all」のシステムコール/JSYSs/EOTs/Whatevers。 はるかに特定であるはずがありませんが、私たちは、H-FPが「無料の昼食」であるというどんな印象も伝えるために怠慢でしょう。 注意されるように、H-FP PIはジェネリックNCPへの同じ種類の統合を必要とします--それは、ただ小さく、絶縁として変化に対して機能します(一般に、積み下ろされたプロトコル、または特に最も近いcommサブネットで)。
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.、「ホストフロントエンドプロトコルアプローチ」、MTR3996、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。
Padlipsky [Page 21]
Padlipsky[21ページ]
一覧
スポンサーリンク
