RFC512 日本語訳

Network Working Group                                     Wayne Hathaway
RFC # 512                                                        AMES-67
NIC # 16443                                                  25 May 1973

ワーキンググループウェインハザウェイRFC#512エームズ-67NIC#16443 1973年5月25日をネットワークでつないでください。

                    MORE ON LOST MESSAGE DETECTION

無くなっているメッセージ検出での以上

I would like to second Edwin Meyer's (RFC #492) strong opposition to the
proposals made in RFC #467 concerning solutions to the "lost allocate"
and "half-closed" phenomena.  In particular I support all of his
principles concerning the "half-closed" phenomenon.  I also agree that
the proposed "lost allocate" solution tends to mask the real problem of
lost messages.  I would, however, like to propose the following
alternative scheme for recognizing lost messages.

解決策に関してRFC#467でされた提案へのエドウィン・マイヤー(RFC#492)の猛烈な反対を後援したいと思う、「失われて、」 「半開きな」現象を割り当ててください。 特に、私は「半開きな」現象に関して彼の原則のすべてを支持します。 失われて、」 解決策を割り当ててください。また、私がそれに同意する、提案、「無くなっているメッセージの実際の問題にマスクをかける傾向があります。 しかしながら、無くなっているメッセージを認識することの以下の代替の計画を提案したいと思います。

I propose that one of the two unused eight-bit bytes in the level 2
message leader be designated the "Sequence Control Byte" (SCB).  This
SCB would be essentially a modulo 255 message count.  Upon receipt of a
message, the receiving NCP would compare the SCB in the previous the
message with the expected SCB as computed from the SCB in the previous
message on the same link.  A discrepancy indicates a lost message, which
could then be reported immediately via an appropriate ERR message.  This
ERR message (to be defined) would contain both received and expected
SCB's, allowing possible recovery of the lost message (if sufficient
space were available in the sending host to save the last several
messages for each link).  At any rate, the lost message would be
recognized immediately, whether it was an ALL (or any control message)
or a data message.  The message with the unexpected SCB should be
processed normally, with the SCB for the next message computed from it.

私は、平らな2メッセージリーダーの未使用の8ビットの2バイトの1つが「シーケンス制御バイト」(SCB)に指定されるよう提案します。 このSCBは本質的には法255メッセージカウントでしょう。 メッセージを受け取り次第受信NCPは前でSCBを比較するでしょう。同じリンクに関する前のメッセージのSCBから計算される予想されたSCBがあるメッセージ。 食い違いは無くなっているメッセージを示します。(次に、すぐ適切なERRメッセージでそれを報告できるでしょう)。 このERRメッセージ(定義される)は受け取られていているものと同様に予想されたSCBのものを含んでいるでしょう、無くなっているメッセージの可能な回復を許して(十分なスペースが各リンクへの最後のいくつかのメッセージを保存する送付ホストで利用可能であるなら)。 いずれにせよ、無くなっているメッセージはすぐに認識されるでしょう、すべて(または、どんなコントロールメッセージも)かaデータが通信するということであったか否かに関係なく。 通常、予期していなかったSCBがあるメッセージはそれから計算された次のメッセージのためにSCBと共に処理されるはずです。

For compatibility, the SCB would be defined such that an SCB of zero
indicates that no checking is to be done.  The SCB following 255 would
thus be 1.  This would mean that current NCP's would not have to be
changed unless actual checking were desired (since the level 2 protocol
specifies that these two unused bytes must be zero.)  This special
definition of zero SCB would also allow RST's and ERR's to bypass
checking, which would be useful in avoiding possible loops.

互換性において、SCBは定義されるでしょう、したがって、ゼロのSCBはチェックでないのが完了していることになっているのを示します。 その結果、SCBの次の255は1でしょう。 これは、実際の照合が望まれていない場合(レベル2以来、プロトコルは、これらの未使用の2バイトがゼロであるに違いないと指定します。)現在のNCPのものが変えられる必要はないことを意味するでしょう。 また、SCBがないこの特別な定義で、RSTとERRのものは照合を迂回させることができるでしょう。(それは、可能な輪を避ける際に役に立つでしょう)。

This proposed scheme is similar to the second scheme suggested by Jon
Postel (RFC #516) except that it is on a per-link basis rather than a
per-host basis.  This is significant, however, as it removes the
requirement that all messages from one host to another arrive in the
order sent (which cannot be guaranteed).  It also provides for
compatibility with existing NCP's.  Jon's first proposal (save all
messages until RFNM received) is weak in two areas: first, it is
possible that the receiving IMP has sent a RFNM for a message that in
fact never gets to its host, and second, it requires (at least for
swapped systems such as ours) either that messages be saved in resident

この提案された計画はそれが1ホストあたり1つの基礎よりむしろ1リンクあたり1個のベースにあるのを除いて、ジョン・ポステル(RFC#516)によって提案された2番目の計画と同様です。 これが重要である、しかしながら、すべての1人のホストから別のホストまでのメッセージがオーダーに到達するという要件は、取り外すので、発信しました(保証できません)。 また、それは既存のNCPのものとの互換性に備えます。 ジョンの最初の提案(RFNMが受信するまで、すべてのメッセージを保存する)は2つの領域で弱いです: まず最初に、受信IMPが事実上、ホストに決して賄賂を送らないメッセージのためにRFNMを送ったのが、可能であり、2番目に、それは、メッセージが居住者に保存されるのを必要とします(少なくとも私たちのものなどの交換されたシステムのために)。

Hathaway                                                        [Page 1]

RFC 512              MORE ON LOST MESSAGE DETECTION             May 1973

さらに無くなっているメッセージ検出1973年5月のハザウェイ[1ページ]RFC512

storage (expensive) or that RFNM's be handled by a swapped process (also
expensive).  The third proposal (that of a host-to-host acknowledgment
scheme) is perhaps the best, but as that requires quite major changes to
the level 2 protocol, an interim solution such as that proposed here
seems of value.

交換された工程(高価なも)で格納(高価な)かそのRFNMが扱われました。 それが必要であるようにレベル2へのかなり主要な変化は議定書を作ります、そして、3番目の提案(ホストからホストへの承認計画のもの)は恐らく最も良いのですが、ここで提案されたそれなどの当座の解決策は価値について見えます。

       [ 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.             9/99 ]

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

Hathaway                                                        [Page 2]

ハザウェイ[2ページ]