RFC875 日本語訳

     RFC 875                                            September 1982
                                                                M82-51

RFC875 1982年9月のM82-51

                  Gateways, Architectures, and Heffalumps

ゲートウェイ、構造、およびHeffalumps

                              M.A. PADLIPSKY
                           THE MITRE CORPORATION
                          Bedford, Massachusetts

M.A.PADLIPSKY斜め継ぎ会社のベッドフォード(マサチューセッツ)

                                 ABSTRACT

要約

          The growth of autonomous intercomputer networks has led to a
     desire on the part of their respective proprietors to "gateway"
     from one to the other.  Unfortunately, however, the implications
     and shortcomings of gateways which must translate or map between
     differing protocol suites are not widely understood.  Some
     protocol sets have such severe functionality mismatches that
     proper T/MG's cannot be generated for them; all attempts to mesh
     heterogeneous suites are subject to numerous problems, including
     the introduction of "singularity points" on logical connections
     which would otherwise be able to enjoy the advantages of
     communications subnetwork alternate routing, loss of
     functionality, difficulty of Flow Control resolution, higher cost
     than non-translating/mapping Gateways, and the necessity of
     re-creating T/MG's when a given suite changes.  The preferability
     of a protocol-compatible internet is also touched upon, as is the
     psychology of those soi-disant architects who posit T/MG's.

自治のintercomputerネットワークの成長は1からのもう片方への「ゲートウェイ」への彼らのそれぞれの所有者側の願望につながりました。 残念ながら、しかしながら、異なるときプロトコル群を翻訳しなければならないか、または写像しなければならないゲートウェイの含意と短所は広く理解されていません。 いくつかのプロトコルセットに、適切なMGのT/ものがそれらのために発生できないくらい厳しい機能性ミスマッチがあります。 異種のスイートを網の目にかけるすべての試みが多数の問題を被りやすいです、そうでなければコミュニケーションサブネットワーク迂回中継の利点を楽しむことができる論理的な接続の「特異性ポイント」の導入を含んでいて、機能性の損失、Flow Control解決の困難、非翻訳/マッピングGateways、および与えられたスイートが変化するときT/MGを作り直すという必要性より高い費用。 また、プロトコルコンパチブルインターネットの一層良いことは触れられます、MGのT/ものを置くsoi-disant建築家の心理のように。

                                     i

i

                  Gateways, Architectures, and Heffalumps

ゲートウェイ、構造、およびHeffalumps

                              M. A. Padlipsky

M.A.Padlipsky

          In our collective zeal to remain (or become) abreast of the
     State of the Art, we sometimes fall into one or the other (or
     both) of a couple of pitfalls.  Only one of these pitfalls is
     particularly well-known:  "Buzzwords" -- and even here merely
     knowing the name doesn't necessarily effect a spontaneous
     solution.  The other deserves more attention:  inadequate
     familiarity with The Relevant Literature.

Artの州と並行して残っている(なってください)私たちの集合的な熱意で、私たちは時々2、3の落とし穴の1かもう片方(ともに)になります。 これらの落とし穴の1つだけが特に周知です: 「専門用語、」 ここでさえ、単に名前を知っていると、自然発生的な解決策は必ず作用するというわけではありません。 もう片方が、より多くの注意に値します: Relevant Literatureへの不十分な親しみ。

          The key is the notion of what's really relevant.  Often,
     it's the Oral Tradition that matters; published papers, in their
     attempts to seem scholarly, offer the wrong levels of abstraction
     or, because of the backgrounds of their authors, are so
     ill-written as to fail to communicate well.  Sometimes, however,
     that which is truly relevant turns out to be unfindable by a
     conventional literature searcher because it isn't "in" the field
     of search.

キーは本当に関連していることに関する概念です。 しばしば、重要であるのは、Oral Traditionです。 彼らの作者のバックグラウンドのために、よく交信しないで、発行された書類は、学究的に見える彼らの試みで間違ったレベルの抽象化を提供するか、または非常にほとんど書かれていません。 しかしながら、時々、本当に、関連しているそれはそれが“in"でないので従来の文学捜索者で「非-見つけ-可能」であると判明します。捜索範囲。

          I wandered into an instructive case in point recently, when
     it took me over an hour to convince a neophyte to the mysteries
     of intercomputer networking (who is quite highly regarded in at
     least one other area of computer science, and is by no means a
     dummy) that a particular Local Area Network architecture proposal
     which casually appealed to the notion of "gatewaying" to three or
     four other networks it didn't have protocols in common with was a
     Very Bad Thing.  "Gateways" is, of course, another one of those
     bloody buzzwords, and in some contexts it might have been enough
     just to so label it.  But this was a conversation with a bright
     professional who'd recently been reading up on networks and who
     wanted really to understand what was so terrible.

と共用して私は最近適切な具格の中までさまよいました、何気なく概念それがそうしない他の3か4つのネットワークに"gatewayingする"であるの好みに合った特定のローカル・エリア・ネットワーク構造提案がプロトコルを持っていると新改宗者にintercomputerネットワーク(コンピュータサイエンスの他の少なくとも1つの領域で全く高く評価されて、決してダミーでない)の神秘に納得させるのに1時間私を要したときVery Bad Thingがそうです。 「ゲートウェイ」がそうである、もちろん、別のものはそれらのひどい専門用語の1つです、そして、いくつかの文脈では、したがって、まさしくそれをラベルするのが十分であったかもしれません。 しかし、これは最近、ネットワークについて研究し続けていて、何がそれほどひどかったかを本当に理解したがっていた利口な専門家との会話でした。

          So I started by appealing to the Oral Tradition, pointing
     out that in the ARPA internetworking research community (from
     which we probably got the term "Gateway" in the first place --
     and from which we certainly get the proof of concept for
     internets) it had been explicitly decided that it would be too
     hard to deal with connecting autonomous networks whose protocol
     sets differed "above" the level of
     Host-to-Communications-Subnetwork-Processor protocol.  That is,
     the kind of Gateway we know how to build -- and, indeed, anything
     one might call a Gateway -- attaches to two (or more) comm
     subnets as if it were a Host on each, by appropriately
     interpreting their respective H-CSNP protocols and doing the
     right things in hardware (see Figure 1), but for ARPA Internet
     Gateways each net attached to is assumed to have the same
     Host-Host Protocol (TCP/IP, in fact

それで、私はOral Traditionに求めることによって、始めました、ARPAインターネットワーキング研究団体(私たちが第一に、たぶん「ゲートウェイ」という用語を得て、確かに、私たちがインターネットのために概念の証拠を得る)では、それがHostからコミュニケーションサブネットワークプロセッサへのプロトコルのレベルはプロトコルが異なった“above"を設定する接続の自治のネットワークを取扱うことができないくらい困難であると明らかに決められたと指摘して。 すなわち、私たちが1がそうするかもしれない体格、および本当にものは何にでもゲートウェイを電話をしてください--2つ(さらに)のcommサブネットへの大使館員がまるで適切にそれらのそれぞれのH-CSNPプロトコルを解釈して、ハードウェア(図1を見る)で正しいことをするのによるそれぞれのHostでしたが、HostであるかのようにARPAインターネットGatewaysのためにどうそれぞれ添付の網状になるかを知っているゲートウェイの種類が同じHost-ホストプロトコルを持っていると思われる、(TCP/IP、事実上

                                     1
     RFC 875                                            September 1982

1RFC875の1982年9月

     or, anyway, IP and either TCP or some other common-to-both-nets
     protocol above it), and the same process level protocols (e.g.,
     Telnet, FTP, or whatever).  The reason for this assuming of
     protocol set homogeneity is that they "knew" the alternative was
     undesirable, because it would involve the translation or mapping
     between different protocol sets in the Gateways and such T/MG's
     were obviously to be avoided.

とにかくそれの上のIPとTCPか両方のネットに共通のプロトコルのどちらかある他の)、同じ加工処理した平らなプロトコル(例えば、Telnet、FTP、または何でも)。 プロトコルセットの同質のこの仮定の理由は代替手段が望ましくないのを「知っていた」ということです、Gatewaysの異なったプロトコルセットの間の翻訳かマッピングにかかわって、明らかにMGのそのようなT/ものが避けられることになっていたので。

          Well, that didn't do the trick.  "Why is a T/MG a Bad
     Thing?" he wanted to know.  "Because of the possibility of
     irreconcilable mismatches in functionality."  "For instance?"
     "Addressing is the most commonly cited."  "Addressing?"

さて、それは所期の目的を達成しませんでした。 彼は、「T/MGはなぜBad Thingですか?」と知りたがっていました。 「機能性の和解できないミスマッチの可能性。」 「例えば、」 「アドレシングは最も一般的に引用されます。」 「アドレシング?」

          Assuming the reader is as bored as I am with the dialogue
     bit, I'll try to step through some specifics of the sorts of
     incompatibility one can find between protocol sets in a less
     theatric manner.  Note that the premise of it all is that we
     don't want to change either pre-existing protocol set.  Let's
     assume for convenience that we are trying to attach just two nets
     together with a T/MG, and further assume that one of the nets
     uses the original ARPANET "NCP" -- which consists, strictly
     speaking, of the unnamed original ARPANET Host-Host Protocol and
     the unfortunately named "1822", or ARPANET Host-IMP Protocol --
     and the other uses TCP/IP.

読者が私が対話ビットでいるのと同じくらい退屈していると仮定すると、私は1つが、より少ない芝居がかった言動方法におけるプロトコルセットの間で見つけることができる不一致の種類のいくつかの詳細を通して踏もうとするでしょう。 プロトコルセットを先在させながら変化したいと思わないというそれのすべての前提がそうであるメモ。 便宜のために私たちがT/MGと共にちょうど2つのネットを付けようとしていると仮定して、ネットの1つがオリジナルのアルパネット「NCP」を使用して(厳密に言うと、どれが無名オリジナルのアルパネットホスト兼ホストプロトコルと残念ながら、「1822」と命名されているか、アルパネットホスト悪童プロトコルから成るか)、もう片方がTCP/IPを使用するとさらに仮定しましょう。

          Host addressing is the most significant problem.  NCP-using
     hosts have "one-dimensional" addresses.  That is, there's a field
     in the Host-IMP "leader" where the Host number goes.  When you've
     assigned all the available values in that field, your net is full
     until and unless you go back and change all the IMP's and NCP's
     to deal with a bigger field.  Using IP, on the other hand,
     addresses of Hosts are "two-dimensional".  That is, there's an IP
     header field in which to designate the foreign network and
     another field in which to designate the foreign Host.  (The
     foregoing is a deliberate oversimplification, by the way.)  So if
     you wanted a Host on an NCP-based net to communicate with a Host
     on another, TCP-based net you'd have a terrible time of it if you
     also didn't want to go mucking around inside of all the different
     NCP implementations, because you don't have a way of expressing
     the foreign address within your current complement of addressing
     mechanisms.

ホストアドレシングは最も重要な問題です。 ホストが「一次元」に持っているNCP使用アドレス。 すなわち、分野がHost番号が行くHost-IMP「リーダー」にあります。 そして、あなたがその分野ですべての利用可能な値を割り当てたとき、あなたのネットが完全である、行かないなら、すべてのIMPとNCPのものを支持して、変えて、より大きい分野に対処してください。 IPを使用して、他方では、Hostsのアドレスは「二次元です」。 すなわち、外国ネットワークを指定するIPヘッダーフィールドと外国Hostを指定する別の分野があります。 (方法によって上記は慎重な簡略化のしすぎです。) それで、あなたがNCPベースの別のものでHostとコミュニケートすることにおけるネットの、そして、TCPベースのネットでHostが欲しく、また、あなたが異なったNCP実現に肥料を施しにすべての内部へ周りに行きたくないなら、それのひどい時間を過すでしょうに、あなたにはあなたのアドレシングメカニズムの現在の補数の中に外国アドレスを表す方法がないので。

          There are various tricks available, of course.  You could
     find enough spare bits in the Host-IMP leader or Host-Host header
     perhaps, and put the needed internet address there.  Or you could
     change the Initial Connection Protocol, or even make the internet
     address be the first thing transmitted as "data" by the User side
     of each process-level protocol.  The common failing of all such
     ploys is that you're changing the pre-existing protocols, though,
     and if

利用可能な様々なトリックがある、もちろん。 あなたは、十分が恐らくHost-IMPリーダーかHost-ホストヘッダーでビットを割いて、必要なインターネットアドレスをそこへ置くのを見つけることができました。 または、あなたは、Initial Connectionプロトコルを変えるか、またはインターネットアドレスがそれぞれの過程レベルのUser側のそばの「データ」が議定書を作るのに従って伝えられた最初のことであることを作ることさえできました。 そしてそのようなすべての仕事の一般的な失敗がもっとも、あなたが先在のプロトコルを変えているということである。

                                     2
     RFC 875                                            September 1982

2 RFC875 1982年9月

     that sort of thing were viewed with equanimity by system
     proprietors you might as well go the whole hog and change over to
     the new protocol set across the board.  Granted, that's a big
     jump; but it must be realized that this is just the first of
     several problems.

その種類のものは新しいプロトコルセットに全体の豚と変化をよく調べるときあなたがそうするかもしれないシステム所有者による全面的な平静で見られました。 与えて、それは大きいジャンプです。 しかし、これがまさしくいくつかの問題の1番目であると実感しなければなりません。

          (It is the case that you could get around the addressing
     problem by having the T/MG become more nearly a real Host and
     terminate the NCP-based side in an application program which
     would "ask" the user what foreign Host he wants to talk to on the
     TCP-based side -- at least for Telnet connections.  When there's
     no user around, though, as would be the case in most file
     transfers, you lose again, unless you fiddle your FTP.  In
     general, this sort of "Janus Host" -- after the Roman deity with
     two faces, who was according to some sources the god of gateways
     (!) -- confers extremely limited functionality anyway; but in
     some practical cases it can be better than trying for full
     functionality and coming up empty.)

(あなたがほとんど本当のHostがT/MGをならせるのによるアドレシング問題の周りで、より多くなって、少なくともTelnet接続のためにTCPベースの側で彼がどんな外国Hostと話したがっているかをユーザに「尋ねる」アプリケーション・プログラムでNCPベースの側を終えることができたのは、事実です。 いつに、あなたのFTPをバイオリンで弾かないならほとんどのファイル転送でそうであるようにあなたが再び損をして、ユーザが全く周囲にいませんか? 一般に、2つの表面をもっているローマ神の後のいくつかに従ってあったこの種類の「ヤヌスホスト」はゲートウェイ(!)の神の出典を明示します。 -- とにかく非常に限られた機能性を与えます。 しかし、いくつかの実用的な場合では、それは完全な機能性に挑戦して、来るのが空になるより良い場合があります。)

          Then there's the question of what to do about RFNM's.  That
     is, NCP's follow the discipline of waiting until the foreign IMP
     indicates a Ready for Next Message state exists before sending
     more data on a given logical connection, but if you're talking to
     a T/MG, its IMP is the one you'll get the RFNM from (the real
     foreign Host might not even be attached to an IMP).  Now, I've
     actually seen a proposal that suggested solving this problem by
     altering the T/MG's IMP to withhold RFNM's, but that doesn't make
     me think it's a viable solution.  At the very least, the T/MG is
     going to have to go in for buffering in a big way (see Figure 2).
     In a possible worst case, the foreign net might not even let you
     know your last transmission got through without changing its
     protocols.

そして、RFNMのところの周りでするべきことに関する質問があります。 すなわち、NCPのものは外国IMPが、与えられた論理的な接続により多くのデータを送りますが、あなたがT/MGと話しているなら、IMPがものになる(全く外国のHostはIMPに取り付けられてさえいないかもしれません)あなたがRFNMを手に入れる前にNext Message状態へのReadyが存在するのを示すまで待つ規律に従います。 今、私は実際にRFNMのものを差し控えるためにT/MGのIMPを変更することによってこの問題を解決するのを示しましたが、それが実行可能な解決策であると考えない提案を見ました。 少なくとも、T/MGはバッファリングに大きく興味をもたなければならないでしょう(図2を見てください)。 可能な最悪の場合では、外国ネットはプロトコルを変えないで通り抜けられたあなたの最後のトランスミッションをあなたに知らせてさえいないかもしれません。

          Going beyond the NCP-TCP example, a generic topic fraught
     with the peril of functionality mismatch is that of the
     Out-of-Band Signal.  (There are some who claim it's also an
     NCP-TCP problem.) The point is that although "any good Host-Host
     protocol" should have some means of communicating aside from
     normal messages "on" logical connections, the mechanizations and
     indeed the semantics of such Out-of-Band Signals often differ.
     The fear is that the differences may lead to  incompatibilities.
     For example, in NCP the OOBS is an Interrupt command "on" the
     control link, whereas in TCP it's an Urgent bit in the header of
     a message "on" the socket.  If you want Urgent to be usable in
     order to have a "virtual quit button", the semantics of the
     protocol must make it very clear that Urgent is not merely the
     sort of thing the NBS/ECMA Host-Host protocol calls "Expedited
     Data".  If, that is, the intent of the mechanism is to cause the
     associated process/job/task to take special action rather than
     merely the associated protocol interpreter (which need not be

NCP-TCPの例を越えて、機能性ミスマッチの危険について悲惨な一般的な話題はバンドのOut Signalのものです。 (また、それがNCP-TCP問題であると主張する何かがあります。) ポイントは「どんな良いHost-ホストプロトコルも」には正常なメッセージは別として“on"の論理的な接続を伝えるいくつかの手段があるべきですが、そのようなバンドのOut Signalsの機械化と本当に意味論がしばしば異なるということです。 恐怖は違いが両立し難いことにつながるかもしれないということです。 例えば、OOBSはNCPでは、コントロールがリンクするInterruptコマンド“on"ですが、TCPでは、Urgentがメッセージ“on"のヘッダーでソケットに噛み付いたということです。 あなたが、「仮想の辞任ボタン」を持つためにUrgentに使用可能であって欲しいなら、プロトコルの意味論で、Urgentが単にものの種類NBS/ECMA Host-ホストプロトコル呼び出し「速められたデータ」でないことは非常に明確にならなければなりません。 メカニズムの意図がすなわち、関連過程/仕事/タスクが単に関連プロトコルインタプリタよりむしろ特別な行動を取ることを引き起こすことである、(どれがある必要はないか。

                                     3
     RFC 875                                            September 1982

3 RFC875 1982年9月

     part of the process), you'd better say so -- and none of the
     ISO-derived protocols I've seen yet does so.  And there's not
     much a T/MG  can do if it gets an NCP Interrupt on a control
     link, notices a Telnet Interrupt Process control code on the
     associated socket, and doesn't have anything other than
     Expediting Data to do with it on its other side.  (Expedited
     Data, it may be noted, bears a striking resemblance to taking an
     SST across the Atlantic, only to find no one on duty in the
     Customs shed -- and the door locked from the other side.)

過程の一部)、あなたは見ましたが、IがそうをするISOによって派生させられたプロトコルのたとえば、そうと、いずれもそうしないほうがよいです。 そして、コントロールリンクにNCP Interruptを乗せて、関連ソケットの上にTelnet Interrupt Process制御コードに気付いて、Expediting Data以外に、反対側にそれを処理するために何も持っていないなら、T/MGができる多くのことがありません。 (速められたDataは大西洋の向こう側にSSTを持って行くとの税関で勤務中であることの人はだれも落ちなかったのがわかる衝撃的な類似を持って、それが注意されるかもしれないドアは反対側からロックされました。)

          Functionality mismatch is not, of course, limited to
     Host-Host protocols.  Indeed, the following interesting situation
     was observed at University College London:  In their "Terminal
     Gateway", which translates/maps ARPANET Telnet and "Triple X"
     (CCITT X.25, X.28, X.29), they were able to get data across, as
     might be expected, but only one option (echoing), which is rather
     worse than might be expected.  (And the UCL people are quite
     competent, so the problem almost certainly doesn't have to do
     with inadequate ingenuity.)

機能性ミスマッチはもちろんHost-ホストプロトコルに制限されません。 本当に、以下のおもしろい状況はユニバーシティ・カレッジロンドンで観測されました: アルパネットTelnetと「三重X」(CCITT X.25、X.28、X.29)を翻訳するか、または写像する自己の「端末のゲートウェイ」では、それらはデータについて説明できる1つのオプションだけ(反響)でした。(その)は予想であるかもしれないよりかなり悪いです)。 (そして、UCLの人々がかなり有能であるので、問題はほぼ確実に不十分な巧みさと関係がありません。)

          It could be argued that the real problem with Expedite Data
     and Triple X is that some protocol sets are a lot worse than
     others.  I wouldn't dispute that.  But it's still the case, to
     re-use a Great Network One-liner, that:

Expedite DataとTriple Xの実際の問題がいくつかのプロトコルセットが他のものよりはるかに悪いということであると主張できました。 私はそれについて議論しないでしょう。 しかし、それでも、それがすばらしいNetwork One-ライナーを再使用するためにはケースである、それ:

                   sometimes, when you try to turn an apple into an
                   orange, you get back a lemon.

りんごをオレンジに変えようとするとき、時々、あなたはレモンを取り戻します。

          Nor is the likelihood of encountering irresolvable
     functionality  mismatches the only technical shortcoming of
     Translating/Mapping Gateways.  A somewhat subtle but rather
     fascinating point arises if we ask what happens when traffic is
     heavy enough to warrant more than one T/MG between a given pair
     of protocol-incompatible nets (or even if we'd like to add some
     reliability, regardless of traffic).  What happens, if we think
     about it a little, is a big problem.  Suppose you actually could
     figure out a way to translate/map between two given sets of
     protocols.  That would mean that for each logical connection you
     had open, you'd have a wealth of state information about it for
     each net you were gatewaying.  But "you" now stand revealed as a
     single T/MG -- and your clone next door doesn't have that state
     information, so any logical connection that started its life with
     you has to spend its life with you, in a state of perpetual
     monogamy, as it were.  Naturally, this epoxied pair-bonding could
     perhaps be dealt with by still another new protocol between
     T/MG's, but it's abundantly clear that there will be no easy
     analogue to no-fault divorce.  That is, to put it less
     metophorically, it becomes at best extremely complex to do
     translating/mapping at more

また、分解できない機能性ミスマッチに遭遇するという見込みはTranslating/マッピングGatewaysの唯一の技術的な短所ではありません。 私たちが、交通が与えられた組のプロトコル両立しないネットの間の1T/MGを保証できるくらい激しいときに(交通にかかわらず何らかの信頼性を加えたいと思っても)、何が起こるかを尋ねるなら、いくらか微妙な、しかし、かなり魅惑的なポイントは起こります。 私たちがそれについて少し考えるなら起こることは重要な問題です。 実際に2の間で与えられたセットのプロトコルを翻訳するか、または写像する方法を理解できたと仮定してください。 それは、開くようにしたそれぞれの論理的な接続のために、あなたにはあなたがgatewayingしていた各ネットのためのそれの豊富な州の情報があることを意味するでしょう。 しかし、「あなた」が現在、独身のT/MGとして明らかにされた状態で立って、隣のあなたのクローンにはその州の情報がないので、あなたから人生を始めたどんな論理的な接続もまるで永久の一夫一婦主義の事情で、あなたと人生を過ごさなければなりません。 当然、恐らくMGのT/ところの間のまだ別の新しいプロトコルでこのepoxied組接着に対処できましたが、無過失離婚へのどんな簡単なアナログもないのは、豊富にクリアすることです。 すなわち、それほどそれを置かないように、metophoricallyに、以上で翻訳/マッピングをするのはせいぜい非常に複雑になります。

                                     4
     RFC 875                                            September 1982

4 RFC875 1982年9月

     than one T/MG for the same logical connection.  As with the
     broader issue of reconciling given protocol sets at all, doing so
     at multiple loci of control may or may not turn out to be
     feasible in practice and certainly will be a delicate and complex
     design task.

同じ論理的な接続のためのものT/MGより。 全くプロトコルセットに和解の広範な問題を与えていると、そうコントロールの複数の座にするのは実際には可能であると判明するかもしれなくて、確かに、デリケートで複雑なデザインタスクになるでしょう。

          One more NCP/TCP problem:  When sending mail on an NCP-based
     net, the mail (actually, File Transfer) protocol currently only
     uses the addressee's name, because the Host was determined by the
     Host-Host Protocol.  If you're trying to get mail from an
     NCP-based net to a TCP-based net, though, you're back in the Host
     addressing bind already discussed.  If you don't want to change
     NCP (which, after all, is being phased out), you have to do
     something at the process level.  You can, but the "Simple Mail
     Transfer Protocol" to do it takes 62 pages to specify in ARPANET
     Request for Comments 788.

もうひとつのNCP/TCP問題: 現在NCPベースのネットにメールを送るとき、メール(実際にFile Transfer)プロトコルは受け取り人の名前を使用するだけです、HostがHost-ホストプロトコルで決定したので。 もっとも、NCPベースのネットからTCPベースのネットまでメールを受け取ろうとしているなら、あなたは既に議論したひもを記述するHostに戻っています。 NCP(結局段階的に廃止されている)を変えたくないなら、あなたは過程レベルで何かをしなければなりません。 あなたは取ることができますが、それをする「シンプルメールトランスファプロトコル」は、アルパネットRequestでComments788に指定するために62ページ取ります。

          If things get that complicated when going from NCP to TCP,
     where there's a close evolutionary link between the Host-Host
     protocols, and the process-level protocols are nominally the
     same, what happens when you want to go from DECNET, or from SNA,
     or from the as-yet incomplete NBS or ISO protocol sets?  There
     may or may not turn out to be any aspects that no amount of
     ingenuity can reconcile, but it's abundantly clear that
     Translating/Mapping Gateways are going to have to be far more
     powerful systems than IP Gateways (which are what you use if both
     nets use the same protocol sets above the Host to Comm Subnet
     Processor protocol).  And you're going to need a different T/MG
     for each pair of protocol sets.  And you may have to tinker with
     CSNP internals....  An analogy to the kids' game of Telephone (or
     Gossip) comes to mind:  How much do you lose each time you
     whisper to your neighbor who in turn whispers to the next
     neighbor?  What, for that matter, if we transplant the game to
     the United Nations and have the whisperers be translators who
     have speakers of different languages on each side?

NCPからTCPまで行くとき、いろいろなことがそんなに複雑になって、過程レベルプロトコルが名目上は同じであるなら、あなたがDECNETか、SNAか、まだ不完全NBSから行きたがっているか、またはISOがセットについて議定書の中で述べると、何が起こりますか?そこに、Host-ホストプロトコルの間には、近い進化論のリンクがあります。 巧みさのどんな量も和解させることができないどんな局面も判明するかもしれないでしょうが、Translating/マッピングGatewaysがIP Gatewaysよりはるかに強力なシステムでなければならないこと(両方のネットが同じプロトコルを使用するならどれがあなたが使用する何であるかがHostの上にComm Subnet Processorプロトコルにセットする)は豊富にクリアすることです。 そして、あなたはそれぞれの組のプロトコルセットに異なったT/MGを必要とするでしょう。 そして、あなたはCSNPインターナルをへたにいじくり回さなければならないかもしれません… 子供のTelephone(または、Gossip)のゲームへの類推は思い浮かびます: あなたは順番に次の隣人にささやく隣人にささやく各回をどれほど失いますか? こと、さらに言えば、私たちに、ゲームを国連に移植して、密告者がいるなら、異なった言語のスピーカーがそれぞれの側にいる翻訳者はそうです。

          Other problem areas could be adduced.  For example, it's
     clear that interpreting two protocol sets rather than one would
     take more time, even if it could be done.  Also, it should be
     noted that the RFNM's Problem generalizes into a concern over
     resolving Flow Control mismatches for any pair of protocol sets,
     and could lead to the necessity of having more memory for buffers
     on the T/MG than on any given Host even for those cases where
     it's doable in principle. But only one other problem area seems
     particularly major, and that is the old Moving Target bugaboo:
     For when any protocol changes, so must all the T/MG's involving
     it, and as there have already been three versions of SNA,
     presumably a like number of versions of DECNET, and as there are
     at least two additional levels which ISO should be acknowledging
     the existence of, the fear of having to re-do T/MG's should serve
     as a considerable deterrent to doing them

他の問題領域を提出できました。 例えば、1よりむしろ2つのプロトコルセットを解釈するのがさらに多くの時間がかかるのは、明確です、それができても。 また、それが原則としてできるそれらのケースさえのためのHostを考えて、RFNMのProblemがどんな組のプロトコルセットのためにもFlow Controlミスマッチを決議することに関する心配に総合して、T/MGの上のバッファのための何より多くの記憶力を持っているという必要性に通じることができたことに注意されるべきです。 しかし、他の1つの問題領域だけが特に主要に見えます、そして、それは古いMoving Targetおばけです: どんなプロトコルも変化する時の間、ISOが存在を承認しているはずである少なくとも2つの追加レベルがあって、すべてのT/MGがそれにまたかかわるのは機能しなければならなくて、SNAの3つのバージョン、おそらくDECNETの同様の数のバージョンが既にあったとき、T/MGをやり直さなければならないことへの恐怖はそれらをすることへのかなりの抑止力として機能するべきです。

                                     5
     RFC 875                                            September 1982

5 RFC875 1982年9月

     in the first place.  (This apparent contravention of the
     Padlipsky's Law to the effect that Implemented Protocols Have
     Barely Finite Inertia Of Rest is explained by a brand-new
     Padlipsky's Law:  To The Technologically Naive, Change Equals
     Progress; To Vendors, Change Equals Profit.)

第一に。 (ImplementedプロトコルHave Barely Finite Inertia Of Restが真新しいPadlipskyの法によって説明されるという効果へのPadlipskyの法のこの見かけの違反: Technologically Naive、Vendors、Change Equals ProfitへのChange Equals Progressに。)

          At any rate, it's just not clear that a given Translating/
     Mapping Gateway can even be built; you have to look very closely
     at the protocol sets in question to determine even that.  It's
     abundantly clear that if a given one can be built it won't be
     easy to do (see Figure 3).  Yet "system architect" after "system
     architect", apparently in good faith, toss such things into their
     block diagrams.  Assuming that the architectural issue isn't
     resolved by a fondness for the Gothic in preference to the more
     modern view that form should follow function, let's pause briefly
     to visualize an immense, turreted, crenellated, gargoyled  ...
     microprocessor, and return to the question of why this sort of
     thing happens.

いずれにせよ、与えられたTranslating/マッピングゲートウェイを建てることさえできるのはただ明確ではありません。 あなたは非常にしっかりそれさえ決定するために問題のプロトコルセットを見なければなりません。 与えられたものを築き上げることができるとするのが簡単でないことは(図3を見てください)、豊富にクリアすることです。 明らかに誠実に、それらのブロック図にそのようなものを投げ込んでください。しかし、次々と「システム建築家「システム建築家」、構造的な問題がフォームが機能に続くはずであるというより現代の意見に優先してゴシックに関する愛好心によって解決されていないと仮定して、簡潔に止まって、莫大で、小塔があって、銃眼模様の、そして、gargoyledされた…マイクロプロセッサを想像して、この種類のことが起こる理由に関する質問に戻りましょう。

          It's clear that buzzwording is a factor.  After all, "system
     architects" in our context are usually employees of contractors
     and their real role in life is not to build more stately mansions
     but to get contracts, so it's not surprising to find appeal to
     the sort of salesmanship that relies more heavily on fast patter
     than precision. Another good analogy: I once went to one of the
     big chain electronics stores in response to an ad for a cassette
     recorder that "ran on batteries or house current" for $18, only
     to find that they wanted an additional $9 for the (outboard) AC
     adaptor.  Given the complexities of T/MG's, however, in our case
     it's more like an $18 recorder and a $36 adaptor.

buzzwordingが要素であることは明確です。 人生における彼らの本当の役割が結局、通常、私たちの文脈の「システム建築家」が契約者の従業員であり、より堂々の大邸宅を建設するのではなく、契約を得ることであるので、それが、より大いに速いことを精度よりしっくりと当てにされるのは、販売術の種類への掘り出し物の上告に驚くべきものではありません。 別の良い類推: 私は一度18ドルで「バッテリーか家の電流で動いた、彼らが(船外)の交流アダプターの追加9ドルが欲しかったのが単にわかった」カセットレコーダーのための広告に応えて大きいチェーン電器店の1つに行きました。 しかしながら、T/MGの複雑さを考えて、私たちの場合では、それはさらに18ドルのレコーダーと36ドルのアダプターに似ています。

          But is buzzwording all there is?  Clearly not, for as
     mentioned earlier there's also ignorance of the Oral Tradition in
     play. Whether the ignorance is willful or not is probably better
     left unexamined, but if we're willing to entertain the notion
     that it's not all a bait-and-switch job akin to the
     separately-priced AC adaptor, we see that those who casually
     propose T/MG's haven't done enough homework as to the real state
     of the art.

しかし、すべてあるbuzzwordingはそうですか? 明確にそうしないで、先に述べたようにそこに、プレーのOral Traditionへの無知もそうですか? 無知が意図的であるか、またはたぶん非審査されるように残されないほうがよいのですが、私たちがそれがすべて別々に値を付けられた交流アダプターと同系のおとり販売仕事でないという概念をいだくなら、私たちは、何気なくMGのT/ものを提案する人が芸術の実況に関して十分な宿題をしていないのがわかります。

                                     6
     RFC 875                                            September 1982

6 RFC875 1982年9月

          What ever became of that early reference to The Relevant
     Literature, though?  Surely you didn't think I'd never ask.  The
     answers are both implied in the assertion that:

もっとも、いったい何がRelevant Literatureのその早めの参照を一体どうならせましたか? 確実に、あなたは、私が決して尋ねないと思いませんでした。 答えは以下のことという主張でともに含意されます。

                          Gateways are Heffalumps

ゲートウェイはHeffalumpsです。

     as you'll plainly see once you've been reminded of what
     Heffalumps are.  Dipping into The Relevant Literature, then,
     let's reproduce the opening of the Heffalumps story:

一度明らかに見るように、あなたはHeffalumpsが何であるかについて思い出させられました。 Relevant Literatureを浸して、次に、Heffalumps小説の始まりを再生させましょう:

                  One day, when Christopher Robin and Winnie-the-Pooh
             and Piglet were all talking together, Christopher Robin
             finished the mouthful he was eating and said carelessly:
             "I saw a Heffalump today, Piglet."
                  "What was it doing?"  asked Piglet.
                  "Just lumping along," said Christopher Robin.
             "I don't think it saw me."
                  "I saw one once," said Piglet. "At least, I think
             I did," he said.  "Only perhaps it wasn't."
                  "So did I," said Pooh, wondering what a Heffalump
             was like.
                  "You don't often see them," said Christopher Robin
             carelessly.
                  "Not now," said Piglet.
                  "Not at this time of year," said Pooh.
                  Then they all talked about something else, until it
             was time for Pooh and Piglet to go home together.

クリストファー・ロビン、くまのプーさん、およびPigletがある日すべて一緒に話していたとき、クリストファー・ロビンは、彼が口であったのが食べ終えて、不注意に以下を言いました。 「Piglet、私は今日、Heffalumpを見ました。」 「何をしていましたか?」はPigletに尋ねました。 「ただ、ずっと一かたまりになります。」と、クリストファー・ロビンは言いました。 「私は、それが私を見たと思いません。」 「私は一度1つを見ました。」と、Pigletは言いました。 「少なくとも、私は、私がしたと思います。」と、彼は言いました。 「恐らくだけそれはそうではありませんでした。」 Heffalumpが何に似ていたかと思って、「私もそうしました。」と、くまのプーさんは言いました。 「あなたはしばしばそれらを見るというわけではありません。」と、クリストファー・ロビンは不注意に言いました。 「現在でない」と、Pigletは言いました。 「年にこのときでない」と、くまのプーさんは言いました。 そして、彼らは皆、他の何かに関してくまのプーさんとPigletがもう一緒に家に帰るべき時間になるまで話しました。

          (To satisfy the lazy reader -- who'd actually be better off
     searching for it in both -- it's from Winnie-the Pooh, not The House  at
     Pooh Corner.)

(実際に両方でそれを捜し求めるほうがよいだろう怠惰な読者を満たすために、それはプー・コーナーの下院ではなく、くまのプーさんから来ています。)

          Pooh, in case you still don't recall, decides to make a Heffalump
     Trap.  (Piglet is sorry he didn't think of it first.)  He baits it with
     a jar of honey, after making sure that it really was honey all the way
     to the bottom, naturally.  In the middle of the night, he goes to the
     Trap to get what's left of the honey and gets his head stuck in the jar.
     Along comes Piglet, who sees this strange creature with a jar-like head
     making frightful noises, and, having known no more than Pooh what
     Heffalumps really were, assumes that a Heffalump has indeed been Trapped
     and is duly terrified.

あなたがまだ思い出していないといけないので、くまのプーさんは、Heffalump Trapを作ると決めます。 (子豚は彼が最初にそれを考えなかったのが残念です。) 彼ははちみつのきしる音でそれに餌を付けます、それが本当に自然に下部までのいっぱいにはちみつであることを確実にした後に。 夜中に、彼は、いなくなったはちみつのものを得にTrapに行って、瓶で頭を刺させます。 ずっと、Piglet(瓶のようなヘッドがものすごい音を出しているこの奇妙な生物を考えて、Heffalumpsが本当に何であるかをくまのプーさんほどもう少しでない知っていたので、Heffalumpが本当にTrappedであり、正しく脅かされると仮定する)は来ます。

                                     7
     RFC 875                                            September 1982

7 RFC875 1982年9月

          It would probably be too moralistic to wonder how much Christopher
     Robin actually knew about Heffalumps in the first place. The
     "Decorator", based on the picture on page 60 of my edition, clearly
     thinks C.R. thought they were elephants, but I still wonder. At best,
     though, he knew no more about them than the contractor did about
     Gateways in the proposal that started this whole tirade off.

どのくらいのクリストファー・ロビンが第一に実際にHeffalumpsに関して知ったかと思うのはたぶん道学的過ぎるでしょう。 私の60の版ページの上の絵に基づく「室内装飾家」は明確に、それらが象であったのにもかかわらずの、私がまだ不思議に思っているというC.R.考えを考えます。 もっとも、せいぜい、彼は、いいえが契約者よりそれらに関してGatewaysの周りでこの全体の激論を始めた提案でしたのを知っていました。

          NOTE:  FIGURE 1.  Defining Characteristic of All Flavors of
     Gateways, FIGURE 2.  Gateway and Translating/Mapping Gateway,
     Approximately to Scale, and FIGURE 3.  Respective Internals Schematics,
     may be obtained by writing to:  Mike Padlipsky, MITRE Corporation, P.O.
     Box 208, Bedford, Massachusetts, 01730, or sending computer mail to
     Padlipsky@ISIA.

以下に注意してください。 図1 ゲートウェイのすべての風味の特性、図2を定義します。 3をスケーリングして、周囲で計算するためにゲートウェイをゲートウェイ、翻訳するか、または写像すること。 それぞれのInternals Schematics、以下のことのために書くことによって、得るかもしれません。 マイクPadlipsky、MITRE社、私書箱208、ベッドフォード、マサチューセッツ、01730、またはコンピュータメールを Padlipsky@ISIA に送ること。

                                     8

8