RFC516 日本語訳

Network Working Group                           Jonathan B. Postel
RFC # 516                                          UCLA-NMC
NIC # 16683                                         May 18, 1973

1973年5月18日にワーキンググループジョナサンB.ポステルRFC#516UCLA-NMC NIC#16683をネットワークでつないでください。

                         LOST MESSAGE DETECTION

無くなっているメッセージ検出

I have three suggestions for detecting the loss of messages by the
communications subsystem.  The first of these is perhaps the more
powerful and simpler to implement since it uses no new concepts and has
the power to retransmit the message detected as lost.

私には、コミュニケーションサブシステムによるメッセージの損失を検出するための3つの提案があります。 どんな新しい概念も使用しないで、失われているように検出されたメッセージを再送するパワーを持っているので、これらの1番目は、恐らくより強力であって、実行するのは、より簡単です。

The first scheme:

最初の計画:

    If upon sending a message the host saved a copy of that message and
    waited until either:

メッセージを送ることに関してホストは、そのメッセージのコピーを保存して、どちらかまで待ちました:

        a RFNM was returned, in which case everything is ok and the next
        message is processed.

RFNMを返しました、そして、その場合、すべてが間違いありません、そして、次のメッセージを処理します。

        a INCOMPLETE TRANSMISSION is returned, in which case the copy of
        the message is retransmitted (this could be a loop so put a
        finite upper bound on the number of times to retransmit the same
        message).

INCOMPLETE TRANSMISSIONを返します、その場合、メッセージのコピーを再送します(これが輪であるかもしれないので有限上限を回数に置いて、同じメッセージを再送してください)。

        a DESTINATION DEAD is returned, in which case mark the
        destination down and require the exchange of reset commands
        before further communication is allowed.

さらなるコミュニケーションが許容される前に、どのケースが目的地を記録して、リセットコマンドの交換を必要とするかでDESTINATION DEADを返します。

        something else is received indicating an error in the network or
        local IMP, in which case at least log the error, and probably
        close the conversation.

ものはネットワークか地方のIMPで誤りを示すのにおいて他の何か受け取られています、そして、その場合、誤りを少なくとも登録してください、そして、たぶん会話を終えてください。

    Following the above procedures either on a per host basis or a per
    link basis should prevent a lost message problem from
    developing.

ホスト基礎あたりのaかリンク基礎あたりのaの上の手順に従うのは、無くなっているメッセージ問題が発生するのを防ぐべきです。

The second scheme:

2番目の計画:

    If on a per host basis, message numbers are included in the host to
    host header of messages,, and messages are delivered in order (this
    is currently the case in the network, except for priority messages
    so this proposal requires that each host either send everything as
    priority or nothing as priority) then each receiving host can detect
    a missing message by comparing the message number of the received
    message with the previously received message.

メッセージ番号がホストでホスト基礎あたりのaでメッセージのホストヘッダーに含められているならそして、渡されたコネが注文(現在これが至急メッセージ以外のネットワークのそうであるので、この提案は、各ホストが優先権としての優先権か無としてすべてを送るのを必要とします、)であり、次に、各受信ホストが受信されたメッセージのメッセージ番号を以前に受信されたメッセージにたとえることによってなくなったメッセージを検出できるという、メッセージ。

        On exchanging resets the sequence numbers between that pair of

それの間の一連番号が対にするリセットを交換することに関して

Postel                                                          [Page 1]

RFC 516                  LOST MESSAGE DETECTION                 May 1973

メッセージ検出1973年5月になくされたポステル[1ページ]RFC516

        hosts is set to zero.

ホストはゼロに用意ができています。

        Each time a message is sent the current send message number is
        entered into a field in the message header, and the current send
        message number is incremented (modulo N, say N=256)

メッセージが送って、電流がメッセージ番号を送るということである各回はメッセージヘッダーのフィールドの中に入力されます、そして、電流は増加されたメッセージ番号を送ります。(たとえば、法N、N=256)

        Each time a message is received the message number from the
        message is compared to the current receive message number and:

そして、メッセージが受け取って、メッセージからのメッセージ番号が電流と比較されるということである各回メッセージ番号を受けてください、:

            if the received message is the expected one then the message
            is acceptable and current receive message number is
            incremented (modulo N);

受信されたメッセージが予想された次に、メッセージが許容できるか、そして、増加されたメッセージ番号(法N)を受けます;電流が許容できるか、そして、電流は受けます。

            if the received message is not the expected one then a
            message has been lost.

受信されたメッセージが予想されたものでないなら、メッセージは失われました。

    What to do when a missing message is detected, not clear, but at
    least can be logged and reported to the network control center.  A
    missing message may not be fatal to an interactive conversation, but
    it is critical in a file transfer, thus I suggest that missing
    messages which are not recovered be cause to close the conversation.

なくなったメッセージをネットワークに少なくともクリアするのではなく、検出されますが、登録して、報告できるときするべきことはセンターを制御します。 それがファイル転送で批判的である、なくなったメッセージは対話的な会話に致命的でないかもしれませんが、その結果、私は回復されないなくなったメッセージが会話を終える原因であると示唆します。

The third scheme:

3番目の計画:

    Host to host acknowledgements could be required.  Such an
    acknowledgement scheme could be implemented similarly to the IMP to
    IMP scheme.  This is a serious change to the current protocols so I
    will not elaborate on it here, feeling that deeper study will be
    necessary to fully specify a reasonable host to host acknowledgement
    strategy.

承認を主催するホストを必要とすることができました。 同様にIMP計画へのIMPにそのような承認計画を実行できました。 私はこれが現在のプロトコルへの重大な変化であるので、ここにそれについて詳しく説明するつもりではありません、より深い研究がホスト承認戦略に合理的なホストを完全に指定するために必要になるのを感じて。

Of these three suggestions the first is the most immediately practical
and implementable;  in fact several hosts all ready do this.  These
schemes also are non-conflicting, they could be implemented and used
simultaneously.

これらの3つの提案では、第1は、最もすぐに、実用的であって、実行可能です。 事実上、すべてが準備する数人のホストがこれをします。 これらの計画も非闘争であり、同時に、それらを実行して、使用できました。

       [ 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]

Postel                                                          [Page 2]

ポステル[2ページ]