RFC690 日本語訳

Network Working Group                                       Jon Postel
RFC # 690                                                   USC-ISI
NIC # 32699                                                 June 6, 1975

1975年6月6日にワーキンググループジョンポステルRFC#690USC-ISI NIC#32699をネットワークでつないでください。

           Comments on the proposed Host/IMP Protocol Change

提案されたHost/IMPプロトコルChangeのコメント

This is a set of comments on Dave Walden's RFC 687 suggesting a set of
changes to the host--imp protocol.  Dave's points are reproduced here
with my comments underneath.

これはデーヴ・ウォルデンのRFC687における1セットのホストへの変化を示す1セットのコメントです--悪童プロトコル。 デーヴのポイントは下部でここで私のコメントで再生します。

1. Expanded Leader Size.  The leader will be expanded from two to five
16-bit words.  This will provide space for necessary field expansions
and additions.

1. リーダーサイズを広げました。 リーダーは2〜5つの拡張16ビットの単語になるでしょう。 これは必要な分野拡張と追加にスペースを提供するでしょう。

    The existing protocols set the host header at 40 bits so that taken
    together with the leader the length was 72 bits; a nice boundary for
    both 8 bit and 36 bit machines.  This suggestion would result in a
    prefix of 80 + 40 = 120 bits, not so nice (unless the host header is
    extended to 64 bits for a total prefix of 144 bits).

既存のプロトコルが40ビットでホストヘッダーを設定するので、リーダーと共に取って、長さは72ビットでした。 8ビットと36ビットのマシンの両方のための良い境界。 この提案は80+40 = 120ビットの接頭語をもたらすでしょう、それほど良くはありません(ホストヘッダーが144ビットの総接頭語のために64ビットまで広げられない場合)。

2. Expanded Address Field.  The address field will be expanded to 24
bit, 16 bits of IMP address and 8 bits of host address.  This expansion
is more than adequate for any foreseeable ARPA Network growth.

2. 拡張アドレス分野。 アドレス・フィールドは24ビット、IMPアドレスの16ビット、およびホスト・アドレスの8ビットに広げられるでしょう。 どんな予見できるアーパネットの成長にも、この拡張は十二分に適切です。

    Just a few years ago 256 seemed like a lot of hosts, perhaps, a
    extensible scheme might be more appropriate. (I concede 16,777,216,
    is big)

わずか数年前に、256は、恐らく多くのホストのように広げることができる体系が、より適切であるかもしれないように思えました。 (私は、1677万7216が大きいと認めます)

3. New Message Length Field.  A new field will be added which will allow
the source host to optionally specify the message length (in bits) to
the IMP subnetwork.  The IMP subnetwork may be able to use this
information (when available) to better utilize network buffer storage.
The destination host may also be able to use this information to better
utilize its buffer storage.  This field will be 13 bits wide.

3. 新しいメッセージ長分野。 送信元ホストが任意に、メッセージ長(ビットの)をIMPサブネットワークに指定できる新しい分野は加えられるでしょう。 IMPサブネットワークは、ネットワーク緩衝記憶装置をよりよく利用するのに、この情報(利用可能であるときに)を使用できるかもしれません。 また、あて先ホストは、緩衝記憶装置をよりよく利用するのにこの情報を使用できるかもしれません。 この分野は幅13ビットでしょう。

    This sound very useful, but if we every want to have longer messages
    than now the field should be wider, say 16 bits.

しかし、これが非常に役に立つように聞こえる、私たちである、あらゆる、より多くの広さと、たとえば、現在の分野であるべきであるより長いメッセージが16ビット欲しいです。

4. Expanded Handling Type Field.  The handling type field which now is
used to distinguish between priority and non-priority message streams,
etc., will be expanded to eight bits.  This expanded field will provide
for the possibility of a number of parallel message streams having
different handling characteristics between pairs of hosts; e.g.,
priority, non-priority, varying numbers of packets per message (see
below), unordered messages (i.e. the present type-3 messages), a message
stream requiring guaranteed capacity, etc, Note that only some of these

4. タイプがさばく取り扱いを広げました。 現在優先権を見分けるのに使用される取り扱いタイプ分野と非至急メッセージストリームなどは8ビットに広げられるでしょう。 この拡張分野はホストの組の間の異なった取り扱いの特性を持っている多くの平行なメッセージストリームの可能性に備えるでしょう。 例えば、優先権、非優先権です、異なった数のメッセージ(以下を見る)あたりのパケット、順不同のメッセージ(すなわち、現在のタイプ-3つのメッセージ)、aメッセージストリーム必要さはこれらについて容量、など、Noteにそれをいくつかだけ保証しました。

Postel                                                          [Page 1]

RFC 690    Comments on the proposed Host/IMP Protocol Change   June 1975

提案されたHost/IMPプロトコルChange1975年6月のポステル[1ページ]RFC690Comments

facilities will be available in the near term.

施設は近いうちに利用可能になるでしょう。

    This sounds like a good extension.

これは良い拡大のように聞こえます。

5. Source Host Control of Packets per Message.  The possibility will
exist for the source host to specify a message stream which will use a
given number of packets per multi-packet message (e.g. two packets per
message or five packets per message).  Since the IMP network will not
have to use eight packet-buffers for reassembly purposes, as at present,
this may result in better services for such messages.  This will help
users who need both low delay and high throughput.

5. 1メッセージあたりのパケットの送信元ホストコントロール。 送信元ホストが与えられた数のマルチパケットメッセージ(例えば、1メッセージあたり2つのパケットか1メッセージあたり5つのパケット)あたりのパケットを使用するメッセージストリームを指定するように、可能性は存在するでしょう。 IMPネットワークが再アセンブリ目的に8つのパケットバッファを使用する必要はないので、プレゼントのように、これはそのようなメッセージのための、より良いサービスをもたらすかもしれません。 これは低い遅れと高生産性の両方を必要とするユーザを助けるでしょう。

    This seems strange, why not use the message length (as provided in 3
    above) to determine the number of packets needed for this message.

これは奇妙に見えて、なぜ、このメッセージに必要であるパケットの数を測定するのに、メッセージ長(上の3に提供するように)を使用しませんか?

6. Unordered (type-3) Message Change.  Unordered messages will be
indicated by a handling type rather than by a message type as at
present.  This is compatible with the need to check the host access
control capabilities of all messages.  This will provide a slight
backward incompatibility for the three or so hosts which presently use
type-3 messages in their research.

6. 順不同の(タイプ-3)メッセージ変化。 順不同のメッセージはプレゼントのようにメッセージタイプでというよりむしろ取り扱いタイプによって示されるでしょう。 これはすべてのメッセージのホストアクセス制御能力をチェックする必要性と互換性があります。 これはわずかな後方の不一致をおよそ3人のホストに供給するでしょう(現在、彼らの研究にタイプ-3つのメッセージを使用します)。

    Good, a current special case becomes a general facility.

いいぞ、現在の特別なケースは一般的な施設になります。

7. Change in Format of Fake Host Addresses.  The For/From IMP bit will
be eliminated.  The fake host addresses will be the four highest host
numbers (e.g. IMP Teletype will be host 252).

7. にせのホスト・アドレスの形式では、変化してください。 IMPビットからのFor/は排除されるでしょう。 にせのホスト・アドレスは4つの最も高いホスト番号(例えばIMPテレタイプはホストにな252る)でしょう。

    Another change for the better.

より良い別の変化。

8. Addition of a Parameter to the IMP to Host NOP.  The IMP to host NOP
will have added to it a parameter specifying the address (IMP and host
number) of the host.

8. ホストNOPへの悪童へのパラメタの追加。 ホストNOPへのIMPはホストのアドレス(IMPとホスト番号)を指定するパラメタをそれに加えてしまうでしょう。

    Ah, a clever touch, very handy.

ああ、賢明な接触で、非常に便利です。

9. Backward Compatibility.  The old and new formats will be supported in
parallel in the IMPs for the foreseeable future to allow gradual
phaseover of host software.   A host will be able to specify to its IMP
whether the old or new formats are to be used; thus, it will be possible
for the host to specify switching back and forth between the two modes
for debugging purposes.  The specification of the mode to be used will
be possible via a proper choice of format in the host to IMP NOP
message;  The IMP will use the mode of the Host to IMP NOP message the
IMP has received.  Further, a host may select to use either the old or
new format without needing to know more about the other format message
than to discard them should they arrive.  The IMP will initialize by
sending several NOP messages of each type to give the hosts its choice.

9. 後方の互換性。 予見できる未来がホストソフトウェアのゆるやかなphaseoverを許容するように、古くて新しい形式はIMPsで平行でサポートされるでしょう。 ホストは、古いか新しい形式が使用されているかどうかことであるとIMPに指定できるでしょう。 したがって、ホストが指定するのは、デバッグ目的のために2つのモードを前後に切り換えながら、可能でしょう。 使用されるべきモードの仕様はホストでの形式の適切な選択でIMP NOPメッセージに可能になるでしょう。 IMPはIMPが受け取ったIMP NOPメッセージにHostのモードを使用するでしょう。 さらに、到着するならそれらを捨てるよりもう片方の形式メッセージに関する以上を知る必要はなくて、ホストは古いか新しい形式を使用に選択するかもしれません。 IMPは各タイプがホストに与えるいくつかのNOPメッセージを送るのによる選択を初期化するでしょう。

Postel                                                          [Page 2]

RFC 690    Comments on the proposed Host/IMP Protocol Change   June 1975

提案されたHost/IMPプロトコルChange1975年6月のポステル[2ページ]RFC690Comments

Although a host not implementing the new format will not be able to
address hosts on IMPs with IMP-number greater than 63, the IMPs will
wherever possible do the conversion necessary to permit hosts using the
old format to communicate with hosts using the new format and the
reverse.  Finally, it will be possible to convert the leader format from
old to new or the reverse without knowledge of the message type.

新しい形式を実装しないホストはできないでしょうが、どこでも、可能であるところで63以上、IMPsがそうするIMP-数があるIMPsの上のホストに演説するには、古い方式を使用しているホストがホストとコミュニケートすることを新しい形式と逆を使用することで許可するのに必要な変換をしてください。 最終的に、メッセージタイプに関する知識なしで古いのから新しくなるまでのリーダー形式か逆を変換するのは可能でしょう。

    This sounds difficult to implement, but it is all in the imp, so
    fine.  Of course, something along these lines is crucial in an
    operating environment.  But I am beginning to get concerned about
    changes to host--host protocol and network control programs.

これが実装するのが難しく聞こえますが、それは、すべて悪童にあるので、すばらしいです。 もちろん、これらの系列に沿った何かが操作環境で重要です。 しかし、私は主催する変化に関して心配し始めています--ホストプロトコルとネットワーク・コントロール・プログラム。

[What happened to 10?]

[10はどうなりましたか?]

11. Non-blocking Host Interface.  A mechanism will be provided which
allows the IMP to refuse a message from a host without blocking the host
interface.  This mechanism will permit the IMP to gather the necessary
resources to send the refused message and then ask the host to resend
the message.  Finally, the host will be permitted to ask to be able to
send a message and be notified when it is possible without requiring the
message to actually be sent and refused.

11. 非ブロッキングホスト・インターフェース。 IMPがホストからホスト・インターフェースを妨げないでメッセージを拒否できるメカニズムを提供するでしょう。 このメカニズムは、IMPが拒否されたメッセージを送って、次に、メッセージを再送するようにホストに頼むために必要なリソースを集めるのを可能にするでしょう。 最終的に、ホストは、メッセージを送ることができると尋ねることが許可されていて、それが実際に送られるべきメッセージを必要としないで可能であるときに、通知されて、拒否されるでしょう。

    This is another welcome addition.

これは別の歓迎された追加です。

12. Maximum Message Length.  The maximum number of bits of data in a
message may be reduced by a few bits.

12. 最大のメッセージ長。 メッセージのビットのデータの最大数は数ビットによって減少させられるかもしれません。

    I don't see why, but it doesn't matter much.

私は理由を見ませんが、それはあまり重要ではありません。

On the whole a fine set of suggestion, though I am concerned about
changes to host--host protocol implied here or made more desirable by
these suggestions.  A rough guess is that there is easily a couple of
person-months of system programmer time for each operating system on the
net implied here.  Say 24 systems times 2 person-months each equals 48
person-months equals 4 person-years.  And this may be the lower bound.

私が主催する変化に関して心配していますが、--罰金が設定した提案の全体では、ホストプロトコルで、以上は、これらの提案で望ましくここで含意したか、またはなりました。 荒い推測はここで暗示しているネットに関する各オペレーティングシステムのためのシステム・プログラマ時間の2、3人カ月が容易にあるということです。 月の2人がそれぞれ月の48人と等しいという24システム回が年間の4人と等しいと言ってください。 そして、これは下界であるかもしれません。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.            11/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社11/99]

Postel                                                          [Page 3]

ポステル[3ページ]