RFC65 日本語訳
0065 Comments on Host/Host Protocol document #1. D.C. Walden. August 1970. (Format: TXT=5628 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Dave Walden Request for Comments: 65 A/S Norsk Data-Elektonikk August 29, 1970
コメントを求めるワーキンググループデーヴウォルデンRequestをネットワークでつないでください: 65 1970年8月29日の/S Norskデータ-Elektonikk
Comments on Host-Host Protocol Document No. 1 (S. Crocker - 8/3/70)
ホスト兼ホストプロトコルドキュメントNo.1のコメント(S.クロッカー--8/3/70)
Page 3. Eliminate marking. Instead, make all regular messages into two message: The first containing just the leader and indicating that the data follows in the second (next) message. Do this both from the source Host to its IMP and from the destination IMP to its Host. Thus, no more hunting for the beginning of the data is necessary. Once this adjustment is made, an additional simplification is available. If the maximum message length is a common multiple of the word sizes of all the computers in the network (perhaps 2880*2 bits), successive messages of long files can be dropped in place without shifting.
3ページ。 マークを排除してください。 代わりに、すべての通常のメッセージを2メッセージに作りかえてください: 最初に、まさしくリーダーを含んで、データが(次)の2番目のメッセージで従うのを示します。 ソースHostからIMPまで目的地IMPからそのHostまでこれをしてください。 したがって、データの始まりの間の、より多くの狩りは必要ではありません。 いったんこの調整をすると、追加簡素化は利用可能です。 最大のメッセージ長がネットワーク(恐らく2880*2ビット)における、すべてのコンピュータの語長の公倍数であるなら、移行しないで、長いファイルの連続したメッセージを適所に落とすことができます。
Page 4. Control messages should be sent to and from the _control socket_ -- not over the control link. The concept of the control link causes a great big, unnecessary special case.
4ページ。 コントロールリンクから送るのではなく、_と_制御ソケット_からコントロールメッセージを送るべきです。 コントロールリンクの概念はどでかくて、不要な特別なケースを引き起こします。
Page 5. Assigning sockets permanently to certain network resources should be encouraged and a directory of the socket/resource associations should be available somewhere in the network, perhaps in physical book form at each site.
5ページ。 永久にあるネットワーク資源にソケットを割り当てるのは奨励されるべきです、そして、ソケット/リソース協会のディレクトリはネットワークにおけるどこかで入手できるべきです、恐らく各サイトの物理的な本のフォームで。
Page 6. Links have no Host-Host purpose other than identifying a connection so that socket numbers don't have to be included in all messages and to simplify table look-ups in the NCPs. However, since there are possibly 512 links* with the same number, links don't aid table look-ups very much. Also finding the next available link to a particular destination is very ugly . Therefore, I suggest limiting the number of links to a total of n (where n = 32, 64, or 256 or some other good number) for all destinations. In other words, a particular link is only in use to one destination at a time(actually from one destination at a time since the receiver picks the link to be used for a connection). This change makes picking the next available link very simple and,I feel,is a worthwhile change if only for this reason. The question of simplifying table look-ups is a little more complex. It is easy to use the link directly as an index into tables in the receive portion of the NCP since the receiver picks the link. But a hash table or linear search or something is still necessary in the send portion of the NCP. This too can be fixed with the following changes. Add to STR a _pseudo link_ chosen by the sender. This link is sent in all non-control messages in the 8 -------------------------------------- *A destination number is 9 bits.
6ページ。 リンクには接続を特定する以外のHost-ホスト目的が全くないので、ソケット番号は、すべてのメッセージに含まれていて、NCPのテーブルルックアップを簡素化する必要はありません。 しかしながら、同じ数との512個のリンク*がことによるとあるので、リンクはテーブルルックアップをあまり支援しません。 また、特定の目的地への次の利用可能なリンクを見つけるのは非常に醜いです。したがって、私は、リンクの数を合計すべての目的地へのn(nが32、64、256またはある他の良い数と等しいところ)に制限することを提案します。 言い換えれば、特定のリンクは一度に(実際に受信機が接続に使用されるためにリンクを選んで以来の時間の1つの目的地から)、1つの目的地にしか使用中ではありません。 私はこの変化が次の利用可能なリンクを選ぶのを非常に簡単にして、単にこの理由で価値がある変化であると感じます。 テーブルルックアップを簡素化する問題はもう少し複雑です。 直接インデックスとして中でテーブルにリンクを使用するのが簡単である、受信機がリンクを選ぶので、NCPの部分を受けてください。 しかし、ハッシュ表、リニアサーチまたはものが中でまだ何か必要である、NCPの部分を送ってください。 以下の変化でこれも修理できます。 _送付者によって選ばれて、_疑似リンクをSTRに加えてください。 8におけるすべての非コントロールメッセージでこのリンクを送ります。-------------------------------------- *目的地番号は9ビットです。
Walden [Page 1] RFC 65 Comments on Host-Host Protocol August 1970
ウォルデン[1ページ]RFC65は1970年8月にホスト兼ホストプロトコルを批評します。
bits to the right of the link in the leader. The IMP must preserve these bits and return them with RFNMs and the receiver must use the pseudo link instead of the link in RET and INR. The extra memory necessary to store the pseudo link in the NCP receive tables (which are indexed by link) and the link in the NCP send tables (which are indexed by pseudo link) is certainly less than the overhead necessary to maintain associative tables.
リーダーのリンクの右へのビット。 IMPはこれらのビットを保存して、RFNMsと共にそれらを返さなければなりません、そして、受信機はRETとINRのリンクの代わりに疑似リンクを使用しなければなりません。 確かに、NCPに疑似リンクを格納するために、テーブル(リンクによって索引をつけられる)を受けてください。そうすれば、NCPのリンクがテーブル(疑似リンクによって索引をつけられる)を送るのが必要な余分なメモリーは結合しやすいテーブルを維持するのに必要なオーバーヘッドより少ないです。
Page 8. The allocate mechanism seems very inconvenient for the receive portion of the NCP to use. The receiver wants the allocation to be used up in units of the receiver's buffer size not in units of sender messages which may be variable length. Otherwise the receiver has a memory compaction problem.
8ページ。 割り当て、メカニズムが非常に不便に見える、使用するNCPの部分を受けてください。 受信機は可変長であるかもしれないユニットの送付者メッセージでないところの受信機のユニットのバッファサイズで配分を使いきるのを必要があります。 さもなければ、受信機には、メモリ圧縮問題があります。
Page 9. The new irregular message to make the "cease" mechanism work are unnecessary, I think. The sender can keep track (probably with a one bit counter) of ALLs and GVBs and ignore GVB 0s for which resume ALLs have already arrived. This the receiver need not know whether the cease has been sent or not.
9ページ。 私は、「やんでください」というメカニズムを働かせる新しい不規則なメッセージが不要であると思います。 送付者は、ALLsとGVBsの道(たぶん1ビットのカウンタがある)を保って、履歴書ALLsが既に到着したGVB0sを無視できます。 やんでください。受信機が知る必要はないこれ、送りました。
Page 15. If I implemented an NCP, all ERRs would be treated like NOP. As an error control mechanism ERR is complicated and insufficient. Who wants to debug a complicated mechanism which only catches bugs due to the primary mechanism being undebugged. The one error control mechanism I would provide is a receive process to send process acknowledgment on every message. If this is not received for too long, the send process can send the message again if it has been saving it. This acknowledgment catches errors causing message loss at the process/NCP, NCP/NCP, Host/IMP, IMP/IMP, etc. levels. Currently the Host/IMP interface is particularly lacking in useful error controls. I wouldn't worry about kinds of errors check-sums are designed to pick up. If dropped and picked up bits ever become a problem either add hardware to more interfaces or let the receive process not send the process to process acknowledgment if a software checksum does not check.
15ページ。 私がNCPを実行するなら、すべてのERRsがNOPのように扱われるでしょうに。 誤り制御メカニズムとして、ERRは複雑であって、不十分です。 だれが非デバッグされる一次機構のためバグを捕らえるだけである複雑なメカニズムをデバッグしたがっていますか? 私が提供する1つの誤り制御メカニズムが過程承認をあらゆるメッセージに送る受信の過程です。 それを救っていて、これが長い間受け取られ過ぎるというわけではないと、発信の過程は再びメッセージを送ることができます。 この承認は、誤りが過程/NCP、NCP/NCP、Host/IMP、IMP/IMP、などレベルでメッセージの損失をもたらすのを捕らえます。 現在の、Host/IMPインタフェースは役に立つ誤り制御で特に欠けています。 誤りチェックサムの種類に関して、回復するために、設計されています私が、心配しないだろう。 落とされて、拾われて、ビットが問題になるなら、より多くのインタフェースにハードウェアを言い足すか、またはソフトウェアチェックサムがチェックしないなら、受信の過程に承認を処理するために過程を送らせないでください。
The page 3 and page 6 comments involve a change to the IMP program. I feel a tiny bit guilty suggesting changes I don't have to implement any more. However, I trust Crowther and Cosell will, as always, resist bad changes while making sensible ones. The page 9 comment is aimed at avoiding a change in the IMP program.
3ページと6ページコメントはIMPプログラムへの変化にかかわります。 私は、私がもう実行する必要はない変化を示しながら、小さいビットが有罪であると感じます。 しかしながら、私は、クラウザーとコーセルがいつものように分別があるものを作っている間悪い変化に抵抗すると信じます。 9ページコメントはIMPプログラムにおける変化を避けるのを目的とされます。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Luke Hollins 8/99]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ルーク・ホリンズ8/99によるオンラインRFCアーカイブへの]
Walden [Page 2]
ウォルデン[2ページ]
一覧
スポンサーリンク