RFC663 日本語訳
0663 Lost message detection and recovery protocol. R. Kanodia. November 1974. (Format: TXT=44702 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Rajendra K. Kanodia Request for Comments #663 MIT, Project MAC NIC #31387 November 29, 1974
ネットワークワーキンググループRajendra K.Kanodiaは1974年11月29日にコメントのために#663MIT、プロジェクトMAC NIC#31387を要求します。
A LOST MESSAGE DETECTION AND RECOVERY PROTOCOL
無くなっているメッセージ検出と回復プロトコル
1.0 INTRODUCTION
1.0 序論
The current Host-to-Host protocol does not provide for the following three aspects of network communication:
Hostからホストへの現在のプロトコルはネットワークコミュニケーションの以下の3つの局面に備えません:
1. detection of messages lost in the transmission path
2. detection of errors in the data
3. procedures for recovery in the event of lost messages or
data errors.
1. メッセージの検出は無くなっているメッセージかデータ誤りの場合、データにおける、誤りのトランスミッション経路2検出で回復のための3つの手順を失いました。
In this memo we propose an extension to the Host-to-Host protocol that will allow detection of lost messages and an orderly recovery from this situation. If Host-to-Host protocol were to be amended to allow for detection of errors in the data, it is expected that the recovery procedures proposed here will apply.
このメモでは、私たちはHostからホストへのこの状況からの無くなっているメッセージと規則的な回復の検出を許すプロトコルに拡大を提案します。 Hostからホストへのプロトコルがデータにおける、誤りの検出を考慮するために修正されることであったなら、ここで提案されたリカバリ手順が適用されると予想されます。
With the present protocol, it may some times be possible to detect loss of messages in the transmission path. However, often a lost message (especially one on a control link) simply results in an inconsistent state of a network connection. One frequent (and frustrating) symptom of a message loss on a control link has been the "lost allocate" problem which results in a "paralyzed" connection. The NCP (Network Control Program) at the receiving site believes that sender has sufficient allocation for a connection, whereas the NCP of the sending host believes that it has no allocation (due to either loss of or error in a message that contained the allocate command). The result is that the sending site can not transmit any more messages over the connection. This problem was reported in the NWG-RFC #467 by Burchfiel and Tomlinson. They also proposed an extension to the Host-to-Host protocol which allows for resynchronization of the connection status. Their proposed solution was opposed by Edwin Meyer (NWG-RFC #492) and Wayne Hathaway (NWG-RFC #512) on the grounds that it tended to mask the basic problem of loss of messages and they suggested that the fundamental problem of message loss should be solved rather than its symptoms. As an alternative to the solution proposed in NWG-RFC #467, Wayne Hathaway suggested that Host-to-Host protocol header could be extended to include a "Sequence Control Byte" to allow detection of lost messages. At about the same time Jon Postel suggested a similar scheme using message numbers (NWG-RFC #516). A little later David Walden proposed that four unused bits of the message sequence number (in the IMP leader) be utilized for sequencing
現在のプロトコルで、それは数回可能であるかもしれません。トランスミッション経路のメッセージの損失を検出するのにおいて、可能であってください。 しかしながら、しばしば、無くなっているメッセージ(特にコントロールリンクの1)は単にネットワーク接続の矛盾した状態をもたらします。 コントロールリンクにおけるメッセージの損失の1回の頻繁で(いらだたしい)の兆候があった、「失われて、」 「麻痺している」接続をもたらす問題を割り当ててください。 受信サイトのNCP(ネットワークControl Program)は、送付者には接続に、十分な配分があると信じていますが、送付ホストのNCPは、それに配分(割り当てコマンドを含んだメッセージにおける損失か誤りによる)が全くないと信じています。 結果は送付サイトがそれ以上のメッセージを接続の上に送ることができないということです。 この問題はNWG-RFC#467でBurchfielとトムリンスンによって報告されました。 また、彼らはHostからホストへの接続形態の再同期を考慮するプロトコルに拡大を提案しました。 メッセージの損失の基本的問題にマスクをかける傾向があったので、彼らの提案された解決策はエドウィン・マイヤー(NWG-RFC#492)とウェインハザウェイ(NWG-RFC#512)によって反対されました、そして、それらはメッセージの損失の基本的な問題が兆候よりむしろ解決されるべきであると示唆しました。NWG-RFC#467で提案された解決策に代わる手段として、ウェインハザウェイは、無くなっているメッセージの検出を許すために「シーケンス制御バイト」を含むようにHostからホストへのプロトコルヘッダーを広げることができるのを示しました。 ほぼ同じ頃、ジョン・ポステルは、メッセージ番号(NWG-RFC#516)を使用することで同様の計画を勧めました。 少し遅いデヴィッド・ウォルデンは、メッセージ通番(IMPリーダーの)の未使用の4ビットが配列に利用されるよう提案しました。
- 1 -
- 1 -
messages (NWG-RFC #534). His scheme is similar to those proposed by Postel and Hathaway; however it has the advantage that Host-to-Host protocol mechanisms can be tied into the IMP-to-Host protocol mechanisms.
メッセージ(NWG-RFC#534)。 彼の計画はポステルとハザウェイによって提案されたものと同様です。 それにホストへのHostが議定書の中で述べる利点がどのようにあっても、メカニズムをIMPからホストへのプロトコルメカニズムに結び付けられることができます。
The protocol extension proposed here uses the four bits of the message sequence number in the message leader for detection of lost messages. However, to facilitate recovery, it uses another eight bit field (presently unused) in the 72 bit header of the regular messages. In the next section of this paper we discuss some of the basic ideas underlying our protocol. In section 3, we provide a description of the protocol. It is our intention that section 3 be a self-contained and complete description of the protocol.
ここで提案されたプロトコル拡大は無くなっているメッセージの検出にメッセージリーダーのメッセージ通番の4ビットを使用します。 しかしながら、回復を容易にするために、それは通常のメッセージの72ビットのヘッダーで別の8ビットの分野を使用します(現在未使用の)。 この紙の次のセクションで、私たちは私たちのプロトコルの基礎となる基本的な考え方のいくつかについて議論します。 セクション3に、私たちはプロトコルの記述を供給します。 それはセクション3がプロトコルの自己充足的で完全な記述であるという私たちの意志です。
2.0 BASIC IDEAS
2.0 基本的な考え
The purpose of this section is to provide a gentle introduction to the central ideas on which this protocol is based. Roughly speaking, our protocol can be divided into three major components. First is the mechanism for detecting loss of messages. Second is the exchange of information between the sender and the receiver in the event of a message loss. For reasons that will soon become obvious, we have termed this area as "Exchange of Control Messages". The third component of our protocol is the method of retransmission of lost messages. In this section, we have reversed the order of discussion for the second and third components, because the mechanisms for exchange of control messages depend heavily upon the retransmission methods.
このセクションの目的はこのプロトコルが基づいている主要な考えにゆるやかな序論を提供することです。 大まかに言えば、私たちのプロトコルを3個の主要コンポーネントに分割できます。 まず最初に、メッセージの損失を検出するためのメカニズムがあります。 2番目に、送付者と受信機の間には、情報交換がメッセージの損失の場合、あります。 すぐ明白になる理由で、私たちは「コントロールメッセージの交換」としてこの領域を呼びました。 私たちのプロトコルの3番目の成分は無くなっているメッセージの「再-トランスミッション」の方法です。 このセクションでは、私たちは2番目と3番目のコンポーネントのための議論の注文を逆にしました、コントロールメッセージの交換のためのメカニズムが大いに「再-トランスミッション」方法によるので。
A careful reader will find that several minor issues have been left unresolved in this section. He (or she) should remember that this section is not intended to be a complete description of the protocol. Hopefully, we have resolved most of these issues in the formal description of the protocol provided in the section 3.
慎重な読者は、いくつかの小さな問題がこのセクションに未定の状態でおかれたのがわかるでしょう。 彼(または、彼女)は、このセクションがプロトコルの完全な記述であることを意図しなかったのを覚えているべきです。 うまくいけば、私たちはセクション3に提供されたプロトコルの形式的記述におけるこれらの問題の大部分を解決しました。
2.1 DETECTION OF LOSS OF MESSAGES
2.1 メッセージの損失の検出
The 32 bit Host-to-IMP and IMP-to-Host leaders contain a 12 bit message-id in bit positions 17 to 28 (BBN Report #1822). The Host-to-Host protocol (NIC 8246) uses 8 bits of the message-id (bit positions 17 to 24) as a link number. The remaining 4 bits of the message-id (bits 25 to 28) are presently unused. For the purposes of the protocol to be presented here, we define these
32ビットのHostからIMPとIMPからホストへのリーダーはビット位置に17〜28(BBN Report#1822)に12ビットのメッセージイドを含みます。 Hostからホストへのプロトコル(NIC8246)はリンク番号としてメッセージイド(17〜24に位置に噛み付く)の8ビットを使用します。 メッセージイド(ビット25〜28)の残っている4ビットは現在、未使用です。 プロトコルの目的がここに提示されるために、私たちはこれらを定義します。
- 2 -
- 2 -
four bits to be the message sequence number (MSN in short) associated with the link. Thus message-id consists of an eight bit link number and a four bit message sequence number. The four bit MSN provides a sixteen element sequence number for each link. A network connection has a sending host (referred to as "sender" henceforth), a receiving host (referred to as receiver henceforth), and a link on which messages are transmitted. In our protocol the sender starts communication with the value of MSN set to one (i.e. the first message on any link has one in its MSN field.) For the next message on the same link the value of MSN is increased by one. When the value of MSN becomes 15 the next value chosen is one. This results in the following sequence 1, 2, ...., 13, 14, 15, 1, 2, ...., etc. The receiver can detect loss of messages by examining this sequence. Each hole corresponds to a lost message. Notice that the detection mechanism will fail if a sequence of exactly 15 messages were to be lost. For the time being, we shall assume that the probability of loosing a sequence of exactly 15 messages is negligible. However, we shall later provide a status exchange mechanism (Section 2.6) that can be used to prevent this failure.
4ビット、メッセージ通番(要するに、MSN)であることはリンクと交際しました。 したがって、メッセージイドは8ビットのリンク番号と4ビットのメッセージ通番から成ります。 4の噛み付いているMSNは16要素一連番号を各リンクに供給します。 ネットワーク接続は送付ホスト(今後は、「送付者」と呼ばれる)、受信ホスト(今後は、受信機と呼ばれる)、およびメッセージが送られるリンクを持っています。 私たちのプロトコルでは、送付者は1つに用意ができているMSNの値とのコミュニケーションを始めます(すなわち、どんなリンクに関する最初のメッセージでも、MSN分野の1つがあります。)。 同じリンクに関する次のメッセージに関しては、MSNの値は1つ増加します。 MSNの値が15になると、選ばれた次の値は1です。 これが以下の系列1、2をもたらす、…, 13, 14, 15, 1, 2, ...., など 受信機は、この系列を調べることによって、メッセージの損失を検出できます。 各穴は無くなっているメッセージに対応しています。 検出メカニズムがまさに15のメッセージの系列が失われることであったなら失敗するのに注意してください。 当分の間、私たちは、まさに15のメッセージの系列を発射するという確率が取るにたらないと思うつもりです。 しかしながら、私たちは後でこの失敗を防ぐのに使用できる状態交換メカニズム(セクション2.6)を提供するつもりです。
Notice that in the sequence described above we have omitted the value zero. Following a suggestion made by Hathaway (NWG-RFC #512) and Walden (NWG-RFC #534) the new protocol uses the value zero to indicate to the receiving host that the sending host is not using message sequence numbers. We, in fact, extend the meaning associated with the MSN value zero to imply that the sending host has not implemented the detection and error recovery protocol being proposed here.
上で説明された系列では私たちが値ゼロを省略したのに注意してください。 ハザウェイ(NWG-RFC#512)によってされた提案とウォルデン(NWG-RFC#534)に続いて、新しいプロトコルは、送付ホストがメッセージ通番を使用していないのを受信ホストに示すのに値ゼロを使用します。 事実上、私たちは、送付ホストがここで提案される検出とエラー回復プロトコルを実行していないのを含意するためにMSN値ゼロに関連している意味について敷衍します。
2.2 COMPATIBILITY
2.2 互換性
The discussion above brings us to the issue of compatibility between the present and the new protocols. Let us define the hosts with the present protocol to be type A and the hosts with the new protocol to be type B. We have three situations:
上の議論は私たちを現在のプロトコルと新しいプロトコルとの互換性の問題に導きます。 タイプAになるように現在のプロトコルでホストを定義させてください。そうすれば、タイプB.Weである新しいプロトコルをもっているホストは3つの状況を持っています:
1. Type A communicating with type A: there is no
difference from the present situation.
2. Type A communicating with type B: from the zero value
MSNs in messages sent by the type A host, the type B
host can detect the fact that the other host is a type A
host. Therefore the type B host can simulate the
behaviour of a type A host in its communication with the
other host, and the type A host will not be confused.
As we will see later that this simulation is really
simple and can be easily applied selectively.
3. Type B host communicating with type B: Both hosts can
detect the fact that the other host is a type B host and
1. タイプA:とコミュニケートするAをタイプしてください。 現在の状況からの違いが全くありません。 2. タイプBと以下を伝えるAをタイプしてください。 ゼロから、メッセージの値のMSNsはタイプAホストで発信して、タイプBホストはもう片方のホストがタイプAホストであるという事実を検出できます。 したがって、タイプBホストはもう片方のホストとのコミュニケーションにおける、タイプAホストのふるまいをシミュレートできます、そして、タイプAホストは混乱しないでしょう。 私たちは後でこのシミュレーションが本当に簡単であることがわかって、容易に選択的に申し込むことができるので。 3. タイプBはタイプBとの交信を接待します: そして両方のホストがもう片方のホストがタイプBホストであるという事実を検出できる。
- 3 -
- 3 -
use the message detection and error recovery protocol.
メッセージ検出とエラー回復プロトコルを使用してください。
There is one difficulty here that we have not yet resolved. When starting communication how does a type B host know whether the other host is type A or type B? This difficulty can be resolved by assuming that a type A host will not be confused by a non-zero MSN in the messages that it receives. This assumption is not unreasonable because a type A host can easily meet this requirement by making a very simple change to its NCP (the Network Control Program), if it does not already satisfy this requirement. Another assumption that is crucial to our protocol, is that the type A hosts always set the MSN field of messages (they send out) to zero. As of this writing, the author believes that no hosts are using the MSN field and therefore no compatibility problem should arise.
私たちがまだ決議していない1つの困難がここにあります。 コミュニケーションを始めるとき、タイプBホストは、どのようにもう片方のホストがタイプAであるかどうかを知っていますか、Bをタイプしますか? タイプAホストが受信するというメッセージの非ゼロMSNによって混乱しないと仮定することによって、この困難を決議できます。 タイプAホストがNCPへの非常に簡単な変更を(Network Control Program)にすることによって容易にこの必要条件を満たすことができるので、この仮定は無理ではありません、既にこの要件を満たさないなら。 私たちのプロトコルに重要な別の仮定はタイプAホストがいつもメッセージ(それらは出す)のMSN分野をゼロに設定するということです。 この書くこと現在、作者は、どんなホストもMSN分野を使用していないと信じています、そして、したがって、互換性の問題は全く起きるべきではありません。
2.3 RETRANSMISSION OF MESSAGES
2.3 メッセージのRETRANSMISSION
Before getting down to the details of the actual protocol, we will attempt here to explain the essential ideas underlying this protocol by considering a somewhat simplified situation. Consider a logical communication channel X, which has at its disposal an inexhaustible supply of physical communication channels C(1), C(2), C(3), ........, etc. (See footnote #1) Channel X is to be used for transmission of messages. In addition to carrying the data, these messages contain (1) the channel name X, and (2) a Message Sequence Number (MSN). Let us denote the sender on this channel by S and the receiver by R. Let us also assume that at the start of the communication, R and S are synchronized such that R is prepared to receive messages for logical channel X on the physical channel C(1) and S is prepared for sending these messages on C(1). S starts by pumping a sequence of messages M(1), M(2), M(3), ........, M(n) into channel C(1). Since these messages contain sequence numbers, R is able to detect loss of messages on the channel C(1). Suppose now that R discovers that message number K (where K <n) was lost in the transmission path. Let us further assume that having _________________________________________________________________
実際のプロトコルの詳細を突き止める前に、私たちは、いくらか簡易型の状況を考えることによってこのプロトコルの基礎となりながら、ここで不可欠の考えについて説明するのを試みるつもりです。 論理的な通信チャネルがXであると考えてください…(Xには、自由に、物理的な通信チャネルC(1)、C(2)、C(3)の無尽蔵の供給があります)。, など (脚注#1を見ます) チャンネルXはメッセージの伝達に使用されることになっています。 データを運ぶことに加えて、これらのメッセージは(1) チャンネル名X、および(2) Message Sequence Number(MSN)を含んでいます。 このチャンネルの上にSと受信機で送付者を指示させてください、R.Letで私たち、また、コミュニケーションの始めでは、RとSが連動するのでRが物理的なチャンネルC(1)で論理チャネルXへのメッセージを受け取るように準備されて、SがこれらのメッセージをC(1)に送りながら用意をすると仮定してください。 SはメッセージM(1)、M(2)、M(3)の系列をポンプで送ることによって、始まります…, チャンネルC(1)へのM(n)。 これらのメッセージが一連番号を含んでいるので、RはチャンネルC(1)におけるメッセージの損失を検出できます。 Rが、メッセージ番号K(どこK<n)がトランスミッション経路で失われたかと発見するので、思ってください。 さらに、それが持っていると仮定しましょう。_________________________________________________________________
(1) One method of recovery may be to let the receiver save all properly received messages and require the sender to retransmit only those messages that were lost. This method requires the receiver to have the ability to reassemble the messages to build the data stream. A second method of recovery may be to abort and restart the transmission at the error point. This method requires that the receiving host be able to distinguish between legitimate messages and messages to be ignored. For simplicity we have chosen the second method and an inexhaustible supply of physical channels serves to provide the distinction among messages.
(1) 回復のある方法は受信機セーブに適切にメッセージをすべて受け取って、送付者が失われたそれらのメッセージだけを再送するのを必要とさせることであるかもしれません。 この方法は、受信機にはデータ・ストリームを組み込むメッセージを組み立て直す能力があるのを必要とします。 回復の2番目の方法は、誤りポイントでのトランスミッションを中止して、再開することであるかもしれません。 この方法は、受信ホストが正統のメッセージと無視されるべきメッセージを見分けることができるのを必要とします。 簡単さのために、私たちは2番目の方法を選びました、そして、物理的なチャンネルの無尽蔵の供給は区別をメッセージに提供するのに役立ちます。
- 4 -
- 4 -
discovered loss of a message, R can communicate this fact to S by sending an appropriate control message on another logical channel that is explicitly reserved for transmission of control messages from R to S. This channel, named Y, is assumed to be completely reliable.
メッセージの発見された損失、RはコントロールメッセージのRからS.までの伝達のために明らかに予約される別の論理チャネルで適切なコントロールメッセージを送ることによって、この事実をSに伝えることができます。YというThisチャンネルを完全に信頼できさせると思われます。
We now provide a rather simplistic recovery protocol for the scenario sketched above. Having detected the loss of message M(K) on channel X, R takes the following series of actions:
私たちは現在、かなり安易な回復プロトコルを上にスケッチされたシナリオに提供します。 チャンネルXにおけるメッセージM(K)の損失を検出したので、Rは以下のシリーズの行動を取ります:
1- R stops reading messages on C(1),
2- R discards those messages that were received on C1 and
are placed after M(K) in the logical message sequence,
3- R prepares itself to read messages M(K), M(K+1), .....,
etc. on the physical channel C(2),
and 4- R sends a control message to S on control channel Y,
which will inform S to the effect that there was an
error on logical channel X while using physical channel
C(1) in message number K.
1 Rは、C1に受け取られて、M(K)後に論理メッセージ系列に置かれるそれらのメッセージをC(1)に関するメッセージ、2R破棄に読み込むのを止めて、3RはメッセージM(K)、M(K+1)を読むために準備します…, Rが制御チャンネルYでSへのコントロールメッセージを送る物理的なチャンネルC(2)、および4に関するなど。(4は誤りがメッセージ番号Kに物理的なチャンネルC(1)を使用している間論理チャネルXにあったことを効果へのSに知らせるでしょう)。
When S receives this control message on Y, it takes the following action:
SがYに関するこのコントロールメッセージを受け取るとき、以下の行動を取ります:
1- S stops sending messages on C(1),
and 2- begins transmission of messages starting with the
sequence number K, on the physical channel C(2).
Sが送付メッセージを止める1C(1)、および2 物理的なチャンネルC(2)で一連番号Kから始まるメッセージの伝達を始めます。
This resynchronization protocol is executed every time R detects an error. If physical channel C(CN) was being used at the time of the error, then the next channel to be used is C(CN+1). We can define a "receiver synchronization state" for the channel X, as the triplet R(C, CN, MSN), where C is the name of the group of physical channels, CN is the number of the physical channel in use, and MSN is the number of message expected. (See footnote #1) We can specify a message received on a given C-channel as M(MSN). When R receives the message M(R.MSN) on the channel C(R.CN), the synch-state changes from R(C, CN, MSN) to R(C, CN, MSN+1). However if M.MSN for the message received is greater than R.MSN then a message has been lost, and R changes the synch-state to R(C, CN+1, MSN). What really happens may be described as follows: upon detection of error in a logical channel X, we merely discard the physical channel that was in use at the time of error, and restart communication on a new physical channel at the point where break occurred. _________________________________________________________________
Rが誤りを検出するときはいつも、この再同期プロトコルは実行されます。 物理的なチャンネルC(CN)が誤り時点で使用されていたなら、次期使用されるべきチャンネルはC(CN+1)です。 私たちは三つ子RとしてのチャンネルX(C、CN、MSN)のために「受信機同期状態」を定義できます。そこでは、Cが物理的なチャンネルのグループの名前であり、CNが使用中の物理的なチャンネルの数であり、MSNは予想されたメッセージの数です。 (脚注#1を見ます) 私たちはM(MSN)として与えられたC-チャンネルで受け取られたメッセージを指定できます。 RがチャンネルC(R. CN)に関するメッセージM(R. MSN)を受け取るとき、R(C、CN、MSN+1)によって同時性状態は変化します。 しかしながら、メッセージが受信されたのでM. MSNがR. MSNより大きいなら、メッセージは失われました、そして、Rは同時性状態をR(C、CN+1、MSN)に変えます。 何が本当に起こるかは以下の通り説明されるかもしれません: 論理チャネルXにおけるエラーの発見のときに、私たちは、誤り時点で単に使用中であった物理的なチャンネルを捨てて、中断が起こったポイントの新しい物理的なチャンネルの上にコミュニケーションを再開します。 _________________________________________________________________
(1) Notice that we have prefixed this triplet by the letter R (for the receiver.) We will prefix other similarly defined quantities by different letters. For example M can be used for messages. This notation permits us to write expressions like M.MSN = R.MSN, where M.MSN stands for the message sequence number of the message.
(1) 文字R(受信機のための)で私たちがこの三つ子を前に置いたのに注意してください。 私たちは異なった手紙で他の同様に定義された量を前に置くつもりです。 メッセージに例えばMを使用できます。 M. MSNがR. MSN(M. MSNはメッセージのメッセージ通番を表す)と等しいようにこの記法は、私たちが表現を書くことを許可します。
- 5 -
- 5 -
This scheme provides a reliable transmission path X, even though the physical channels involved are unreliable. In this scheme we have assumed that (1) a completely reliable channel Y is available for exchange of control messages, and (2) that there is a large supply of physical channels available for use of X. In the paragraphs that follow we shall revise our protocol to use a single physical channel and then apply this protocol to the channel Y in such a way that Y would become "self-correcting."
かかわった物理的なチャンネルは頼り無いのですが、この計画は信頼できるトランスミッション経路Xを提供します。 X.Inの使用に利用可能なたくさんの物理的なチャンネルがいうことになるパラグラフです。この計画では、(1) そこの(2)コントロールメッセージと、その交換について、完全に高信頼のチャンネルYがあると思った、私たちは、Yが「自動修正に」なるような方法で単独の物理的なチャンネルを使用して、次に、このプロトコルをチャンネルYに適用するためにプロトコルを改訂するつもりです。
Now suppose that channel X has only one physical channel (named X') available for its use rather than the inexhaustible supply of physical channels. Our protocol would still work, if we could somehow simulate the effect of a large number of C-channels using the single channel X'. One method of providing this simulation is to include in each message the name of the C-channel on which it is being sent, and send it on X'. Now the receiver must examine each message received on X' to determine the C-channel on which this message was sent. Our protocol still works except for one minor difference, namely, the receiver must now discard messages corresponding to C-channels that are no longer in use, whereas in the previous system the C-channels no longer being used were simply discarded. To be sure, X' can be multiplexed among only a finite number of C-channels; however, we can provide a sufficiently large number of C-channels so that during the life time of the logical channel X, the probability of exhausting the supply of C-channels would be very low. And even if we were to exhaust the supply of C-channels, we could recycle them just as we recycle the message sequence numbers.
Now suppose that channel X has only one physical channel (named X') available for its use rather than the inexhaustible supply of physical channels. Our protocol would still work, if we could somehow simulate the effect of a large number of C-channels using the single channel X'. One method of providing this simulation is to include in each message the name of the C-channel on which it is being sent, and send it on X'. Now the receiver must examine each message received on X' to determine the C-channel on which this message was sent. Our protocol still works except for one minor difference, namely, the receiver must now discard messages corresponding to C-channels that are no longer in use, whereas in the previous system the C-channels no longer being used were simply discarded. To be sure, X' can be multiplexed among only a finite number of C-channels; however, we can provide a sufficiently large number of C-channels so that during the life time of the logical channel X, the probability of exhausting the supply of C-channels would be very low. And even if we were to exhaust the supply of C-channels, we could recycle them just as we recycle the message sequence numbers.
A physical message received on X' can now be characterized by a pair of C-channel number and a message sequence number, as M(CN, MSN). The receiver synchronization state becomes a triplet R(X', CN, MSN). This state tells us that R is ready to receive a message for X on the physical channel X' and for this message M.CN should be equal to R.CN and M.MSN should be equal to R.MSN. All messages with M.CN less than R.CN will be ignored. If for the next message received on X', M.CN = R.CN and M.MSN = R.MSN, then R changes the synch state to R(X', CN, MSN+1). If M.CN = R.CN but M.MSN > R.MSN then a message has been lost and the synch-state R(X', CN, MSN) changes to R(X', CN+1, MSN). Notice that we have not yet said anything about the situation M.CN > R.CN. We will later describe a scheme for using this case to provide for error correction on the control channel itself.
A physical message received on X' can now be characterized by a pair of C-channel number and a message sequence number, as M(CN, MSN). The receiver synchronization state becomes a triplet R(X', CN, MSN). This state tells us that R is ready to receive a message for X on the physical channel X' and for this message M.CN should be equal to R.CN and M.MSN should be equal to R.MSN. All messages with M.CN less than R.CN will be ignored. If for the next message received on X', M.CN = R.CN and M.MSN = R.MSN, then R changes the synch state to R(X', CN, MSN+1). If M.CN = R.CN but M.MSN > R.MSN then a message has been lost and the synch-state R(X', CN, MSN) changes to R(X', CN+1, MSN). Notice that we have not yet said anything about the situation M.CN > R.CN. We will later describe a scheme for using this case to provide for error correction on the control channel itself.
2.4 EXCHANGE OF CONTROL INFORMATION
2.4 EXCHANGE OF CONTROL INFORMATION
So far we have discussed two schemes for the detection and retransmission aspects of the lost-message problem. In this
So far we have discussed two schemes for the detection and retransmission aspects of the lost-message problem. In this
- 6 -
- 6 -
section, we discuss methods by which the receiver communicates to the sender the fact of loss of messages.
section, we discuss methods by which the receiver communicates to the sender the fact of loss of messages.
We continue with the scenario developed in the above section with a small change. For the purposes of the discussion that is about to follow we shall assume that there are actually two perfect channels available for exchange of control messages. One channel from S to R named S->R, and the other from R to S named R->S. The purpose of S->R will become clear in a moment. In order to let R communicate the fact of loss of messages to S, We provide a control message called L__o_s_t__M_e_s_s_a_g_e__f_r_o_m__R_e_c_e_i_v_e_r (LMR) which is of the following form: LMR(X, CN, MSN), where X is the name of the channel, CN is the new C-channel number, and MSN is the message sequence number of the lost message. If more than one message has been lost, then R uses the MSN of the first message only. When S receives this message, it can restart communication at the point where the break occurred using the C-channel specified by the LMR message. This will restore the communication path X. What happens if S can not restore communication at the break point because it does not have the relevant messages any more? This issue can be solved in one of the two ways: either let the protocol specify a fixed rule that S will be required to close the connection, or the protocol could allow S and R (and may be the users on whose behalf S and R are communicating on X) to negotiate the action to be taken. For the protocol to be presented here, we have taken the approach that S may, at its option, either close the connection or negotiate with R. What action a specific host takes can either be built into its NCP or determined dynamically. Those hosts that do not have very powerful machines will probably chose the static option of closing the connection; other hosts may make the decision depending upon the circumstances. For example, a host may decide that loss of messages is not acceptable during file transfers whereas loss of a single message can be ignored for terminal output to interactive users. A host might even let the user processes decide the course of action to be taken. If S determines that it can not retransmit lost messages, it may want to let R decide what action is to be taken. If S so decides, then it may communicate this fact to R by transmitting a _L_o_s_t__M_e_s_s_a_g_e__f_r_o_m__S_e_n_d_e_r (LMS) control message to R on the channel S->R. An LMS message is of the following form: LMS(X, CN, MSN, COUNT), where X is the name of the channel, CN is the name of the C-channel obtained from the LMR message, MSN is the message sequence number of the first message in the sequence of lost messages, and COUNT is the number of messages in the sequence. S resets its own synch-state for connection X to S(X, CN, MSN+COUNT). When S has informed R of its inability to retransmit lost messages, the burden of the decision falls on R, and S simply awaits R's reply before taking any action for the channel X. When R receives the LMS, it may either decide that loss is unacceptable and close the connection, or it may decide to let S continue. In the later case R informs S of its decision
We continue with the scenario developed in the above section with a small change. For the purposes of the discussion that is about to follow we shall assume that there are actually two perfect channels available for exchange of control messages. One channel from S to R named S->R, and the other from R to S named R->S. The purpose of S->R will become clear in a moment. In order to let R communicate the fact of loss of messages to S, We provide a control message called L__o_s_t__M_e_s_s_a_g_e__f_r_o_m__R_e_c_e_i_v_e_r (LMR) which is of the following form: LMR(X, CN, MSN), where X is the name of the channel, CN is the new C-channel number, and MSN is the message sequence number of the lost message. If more than one message has been lost, then R uses the MSN of the first message only. When S receives this message, it can restart communication at the point where the break occurred using the C-channel specified by the LMR message. This will restore the communication path X. What happens if S can not restore communication at the break point because it does not have the relevant messages any more? This issue can be solved in one of the two ways: either let the protocol specify a fixed rule that S will be required to close the connection, or the protocol could allow S and R (and may be the users on whose behalf S and R are communicating on X) to negotiate the action to be taken. For the protocol to be presented here, we have taken the approach that S may, at its option, either close the connection or negotiate with R. What action a specific host takes can either be built into its NCP or determined dynamically. Those hosts that do not have very powerful machines will probably chose the static option of closing the connection; other hosts may make the decision depending upon the circumstances. For example, a host may decide that loss of messages is not acceptable during file transfers whereas loss of a single message can be ignored for terminal output to interactive users. A host might even let the user processes decide the course of action to be taken. If S determines that it can not retransmit lost messages, it may want to let R decide what action is to be taken. If S so decides, then it may communicate this fact to R by transmitting a _L_o_s_t__M_e_s_s_a_g_e__f_r_o_m__S_e_n_d_e_r (LMS) control message to R on the channel S->R. An LMS message is of the following form: LMS(X, CN, MSN, COUNT), where X is the name of the channel, CN is the name of the C-channel obtained from the LMR message, MSN is the message sequence number of the first message in the sequence of lost messages, and COUNT is the number of messages in the sequence. S resets its own synch-state for connection X to S(X, CN, MSN+COUNT). When S has informed R of its inability to retransmit lost messages, the burden of the decision falls on R, and S simply awaits R's reply before taking any action for the channel X. When R receives the LMS, it may either decide that loss is unacceptable and close the connection, or it may decide to let S continue. In the later case R informs S of its decision
- 7 -
- 7 -
to continue by transmitting a L__o_s_s__o_f__M_e_s_s_a_g_e__A_c_c_e_p_t_a_b_l_e (LMA) control message to S. Upon receiving the LMA control message, S resumes transmission on X. To avoid the possibility of errors in exchange of control messages, the LMA control message is specified to be an exact replica of the LMS control message, except for the message code which determines whether a control message is LMA or LMS or something else.
to continue by transmitting a L__o_s_s__o_f__M_e_s_s_a_g_e__A_c_c_e_p_t_a_b_l_e (LMA) control message to S. Upon receiving the LMA control message, S resumes transmission on X. To avoid the possibility of errors in exchange of control messages, the LMA control message is specified to be an exact replica of the LMS control message, except for the message code which determines whether a control message is LMA or LMS or something else.
In general, a sending host has only a limited amount of memory available for storing messages for possible retransmission later. In section 2.6 we provide a status exchange mechanism that can be used to determine when to discard these messages.
In general, a sending host has only a limited amount of memory available for storing messages for possible retransmission later. In section 2.6 we provide a status exchange mechanism that can be used to determine when to discard these messages.
2.5 RECOVERY ON CONTROL LINKS
2.5 RECOVERY ON CONTROL LINKS
We continue our discussion with the scenario developed in the previous section. The receiver R may detect loss of messages on control channels by examining the message sequence numbers on the messages. When R detects that a message has been lost on the channel S->R, it (R) may transmit an LMR to S on R->S communicating the fact of loss of messages. When S receives the LMR for the control link, it must either retransmit the lost messages, or "close" the connection. (In the context of Host-to-Host protocol, closing the network connection for control link implies exchange of reset commands, which has the effect of reinitializing all communication between R and S.) For control links, S does not have the option of sending an LMS to the receiver. If S can not retransmit the lost messages then it aborts the output queue (if any) for the channel S->R, and inserts a Reset command at the break point. Essentially, we are specifying that if S can not retransmit lost control messages then the error would be considered irrecoverable and fatal. All user communication between S and R is broken and must be restarted from the beginning.
We continue our discussion with the scenario developed in the previous section. The receiver R may detect loss of messages on control channels by examining the message sequence numbers on the messages. When R detects that a message has been lost on the channel S->R, it (R) may transmit an LMR to S on R->S communicating the fact of loss of messages. When S receives the LMR for the control link, it must either retransmit the lost messages, or "close" the connection. (In the context of Host-to-Host protocol, closing the network connection for control link implies exchange of reset commands, which has the effect of reinitializing all communication between R and S.) For control links, S does not have the option of sending an LMS to the receiver. If S can not retransmit the lost messages then it aborts the output queue (if any) for the channel S->R, and inserts a Reset command at the break point. Essentially, we are specifying that if S can not retransmit lost control messages then the error would be considered irrecoverable and fatal. All user communication between S and R is broken and must be restarted from the beginning.
In the above paragraph, we considered the situation in which R was able to detect the loss of messages. It is however possible that it is the last message transmitted on S->R that is lost. In this case, R will not be aware of the loss. In this situation, recovery can be initiated only if S can either positively determine or simply suspect that a message has been lost. In general, after having transmitted a control message, S would be expecting some sort of response from R. For example, if S transmits a Request-for-Connection (RFC) control message to R, S expects R to reply either with a Close (CLS) command or another RFC. If, after an appropriate time interval has elapsed and S has received no reply from R, our protocol specifies that S may retransmit the control message. In retransmitting, S must use
In the above paragraph, we considered the situation in which R was able to detect the loss of messages. It is however possible that it is the last message transmitted on S->R that is lost. In this case, R will not be aware of the loss. In this situation, recovery can be initiated only if S can either positively determine or simply suspect that a message has been lost. In general, after having transmitted a control message, S would be expecting some sort of response from R. For example, if S transmits a Request-for-Connection (RFC) control message to R, S expects R to reply either with a Close (CLS) command or another RFC. If, after an appropriate time interval has elapsed and S has received no reply from R, our protocol specifies that S may retransmit the control message. In retransmitting, S must use
- 8 -
- 8 -
the same C-channel and MSN values that were used for the original message. Since R can, now, receive duplicate copies, we stipulate that if R receives a duplicate of the message that it has already received, it may simply ignore the duplicate.
the same C-channel and MSN values that were used for the original message. Since R can, now, receive duplicate copies, we stipulate that if R receives a duplicate of the message that it has already received, it may simply ignore the duplicate.
2.6 SOME OTHER PROBLEMS
2.6 SOME OTHER PROBLEMS
There are two problems that have not yet been solved. First, a sending host will usually have only a limited amount of buffer space in which it can save messages for possible later retransmission. So far, we have not provided any method by which a host may positively determine whether the receiver has correctly received a certain message or not. Thus it has no firm basis on which it may decide to release the space used up by messages that have been already transmitted. The second problem is created by our recycling the message sequence numbers. For the MSN mechanism to work correctly, it is essential that at any given instant of time there be no more than 15 messages in the transmission path. If there were more than 15 messages, some of these messages would have same MSN and LRN, and if one of these messages were to be lost, it would be impossible to identify the lost message. However, the second problem should not arise in the ARPA Network, since the IMP sub-network will not allow more than eight outstanding messages between any host pair (NWG-RFC #660).
There are two problems that have not yet been solved. First, a sending host will usually have only a limited amount of buffer space in which it can save messages for possible later retransmission. So far, we have not provided any method by which a host may positively determine whether the receiver has correctly received a certain message or not. Thus it has no firm basis on which it may decide to release the space used up by messages that have been already transmitted. The second problem is created by our recycling the message sequence numbers. For the MSN mechanism to work correctly, it is essential that at any given instant of time there be no more than 15 messages in the transmission path. If there were more than 15 messages, some of these messages would have same MSN and LRN, and if one of these messages were to be lost, it would be impossible to identify the lost message. However, the second problem should not arise in the ARPA Network, since the IMP sub-network will not allow more than eight outstanding messages between any host pair (NWG-RFC #660).
We can solve both these problems by a simple yet highly flexible scheme. In this scheme, there are two new control messages. One of these, called R__e_q_u_e_s_t S__t_a_t_u_s _f_r_o_m S__e_n_d_e_r (RSS), can be used by the sending host to query the receiver regarding the receiver's synch-state. The receiver can supply its copies of C-channel number and MSN for a transmission path by sending a S__t_a_t_u_s _f_r_o_m R__e_c_e_i_v_e_r (SFR) control message over the control channel. An SFR provides positive acknowledgement; differing with the usual acknowledgement schemes in only that here acknowledgement is provided only upon demand. Upon receiving SFR, the sender knows exactly which messages have been properly delivered, and it may free the buffer space used by these messages. The RSS and SFR scheme can also be used to ensure that there are no more than fifteen messages in the transmission path at any given time.
We can solve both these problems by a simple yet highly flexible scheme. In this scheme, there are two new control messages. One of these, called R__e_q_u_e_s_t S__t_a_t_u_s _f_r_o_m S__e_n_d_e_r (RSS), can be used by the sending host to query the receiver regarding the receiver's synch-state. The receiver can supply its copies of C-channel number and MSN for a transmission path by sending a S__t_a_t_u_s _f_r_o_m R__e_c_e_i_v_e_r (SFR) control message over the control channel. An SFR provides positive acknowledgement; differing with the usual acknowledgement schemes in only that here acknowledgement is provided only upon demand. Upon receiving SFR, the sender knows exactly which messages have been properly delivered, and it may free the buffer space used by these messages. The RSS and SFR scheme can also be used to ensure that there are no more than fifteen messages in the transmission path at any given time.
- 9 -
- 9 -
3.0 LOST MESSAGE DETECTION AND RECOVERY PROTOCOL
3.0 LOST MESSAGE DETECTION AND RECOVERY PROTOCOL
This protocol is proposed as an amendment to the Host-to-Host Protocol for the purpose of letting hosts detect the loss of messages in the network. It also provides recovery procedures from such losses. This protocol is divided into two parts. Part 1 states the compatibility requirements. Part 2 states the new protocol and must be implemented by hosts that desire to have the ability to recover from loss of messages in the network. The reader will find many comments interspersed throughout the description of this protocol. These comments are not part of the protocol and are provided solely for the purpose of improving the reader's understanding of this protocol.
This protocol is proposed as an amendment to the Host-to-Host Protocol for the purpose of letting hosts detect the loss of messages in the network. It also provides recovery procedures from such losses. This protocol is divided into two parts. Part 1 states the compatibility requirements. Part 2 states the new protocol and must be implemented by hosts that desire to have the ability to recover from loss of messages in the network. The reader will find many comments interspersed throughout the description of this protocol. These comments are not part of the protocol and are provided solely for the purpose of improving the reader's understanding of this protocol.
The terminology used in this protocol is similar to that used in the Host-to-Host protocol. We speak of a "network connection" between a pair of hosts, called the "receiver" and the "sender." A network connection is described by a pair of socket numbers, and once established, a network connection is associated with a link (which is described by a link number.) A network connection is a logical communication path and the link assigned to it is a physical communication path. In addition to links associated with the network connections, there are "control-links" for the transmission of "control commands." When we use the term "connection" it may refer to either a network connection or the link assigned to it; the context decides which one. The term "links" encompasses the connection-associated-links as well as control-links. Notice that a receiver of a connection may transmit control commands regarding this connection.
The terminology used in this protocol is similar to that used in the Host-to-Host protocol. We speak of a "network connection" between a pair of hosts, called the "receiver" and the "sender." A network connection is described by a pair of socket numbers, and once established, a network connection is associated with a link (which is described by a link number.) A network connection is a logical communication path and the link assigned to it is a physical communication path. In addition to links associated with the network connections, there are "control-links" for the transmission of "control commands." When we use the term "connection" it may refer to either a network connection or the link assigned to it; the context decides which one. The term "links" encompasses the connection-associated-links as well as control-links. Notice that a receiver of a connection may transmit control commands regarding this connection.
3.1 DEFINTIONS
3.1 DEFINTIONS
3.1.1 HOST TYPE "A"
3.1.1 HOST TYPE "A"
Those hosts that have not adopted the part 2 of this protocol amendment will be known as type A hosts.
Those hosts that have not adopted the part 2 of this protocol amendment will be known as type A hosts.
(Comment: All existing hosts are type A hosts.)
(Comment: All existing hosts are type A hosts.)
3.1.2 HOST TYPE "B"
3.1.2 HOST TYPE "B"
Those hosts, that adopt the part 2 of this protocol amendment will be known as type B hosts.
Those hosts, that adopt the part 2 of this protocol amendment will be known as type B hosts.
- 10 -
- 10 -
3.1.3 MESSAGE SEQUENCE NUMBER (MSN)
3.1.3 MESSAGE SEQUENCE NUMBER (MSN)
A four bit number associated with regular messages and contained in the bits 25 through 28 of the Host-to-IMP and IMP-to-Host leaders for regular messages [BBN Report No. 1822]. This number is used by the type B hosts to detect loss of messages on a given link. Type A hosts always set the MSN (for the messages they send out) to zero. When in use by a type B host, the first message on a link (after the connection has been established) has the MSN value of one. For each successive message on this link, the MSN value is increased by one until it reaches a value of 15. The next message has the MSN value of one.
A four bit number associated with regular messages and contained in the bits 25 through 28 of the Host-to-IMP and IMP-to-Host leaders for regular messages [BBN Report No. 1822]. This number is used by the type B hosts to detect loss of messages on a given link. Type A hosts always set the MSN (for the messages they send out) to zero. When in use by a type B host, the first message on a link (after the connection has been established) has the MSN value of one. For each successive message on this link, the MSN value is increased by one until it reaches a value of 15. The next message has the MSN value of one.
(Comments: Type B hosts will use the MSN mechanism only when communicating with other type B hosts. If a type B host is communicating with a type A host, the type B host will essentially simulate the behaviour of a type A host and use zero MSN values for this communication.)
(Comments: Type B hosts will use the MSN mechanism only when communicating with other type B hosts. If a type B host is communicating with a type A host, the type B host will essentially simulate the behaviour of a type A host and use zero MSN values for this communication.)
3.1.4 LINK RESYNCH NUMBER (LRN)
3.1.4 LINK RESYNCH NUMBER (LRN)
The Link Resynch Number is an eight bit number associated with a link and used for resynchronizing the communication. For links associated with a network connection (i.e. user links), it is intially set to zero. For control links, it is set to zero at the time of the Network Control Program (NCP) initialization. For a given link, its current LRN value is copied into the LRN field of all messages sent out on the link. The LRN values may be manipulated by type B hosts in accordance with the protocol described later.
The Link Resynch Number is an eight bit number associated with a link and used for resynchronizing the communication. For links associated with a network connection (i.e. user links), it is intially set to zero. For control links, it is set to zero at the time of the Network Control Program (NCP) initialization. For a given link, its current LRN value is copied into the LRN field of all messages sent out on the link. The LRN values may be manipulated by type B hosts in accordance with the protocol described later.
(Comments: Our protocol specifies that for all communication involving a type A host, the LRN value will never change from zero. Since the LRN field is presently unused, all hosts set it to zero even though they do not explicitly recognize this field as an LRN field. This guarantees compatibility.)
(コメント: 私たちのプロトコルは、タイプAホストにかかわるすべてのコミュニケーションに関してLRN値がゼロから決して変化しないと指定します。 LRN分野が現在未使用であるので、彼らは、この分野がLRN分野であると明らかに認めませんが、すべてのホストがゼロにそれを設定します。 これは互換性を保証します。)
3.1.5 LRN FIELD
3.1.5 LRN分野
An eight bit field in the bits 33 through 40 of the Host-to-Host message header.
Hostからホストへのメッセージヘッダーのビット33〜40の8ビットの分野。
- 11 -
- 11 -
3.2 NEW CONTROL COMMANDS
3.2 新しい制御コマンド
3.2.1 LMR - LOST MESSAGE FROM RECEIVER
3.2.1 LMR--受信機からのメッセージを失います。
___8______8_______8_______8____ | I I I I I LMR | link | LRN | MSN I I______I_______I_______I______I_
___8 ______8 _______8 _______8 ____ | I I I I I LMR| リンク| LRN| MSN I I______I_______I_______I______I_
The LMR command is sent by a receiving host to let the sending host know that one or more messages have been lost. The MSN field specifies the message sequence number of the first message lost. The LRN field specifies the new LRN value that must be used if and when communication is restored.
送付ホストに1つ以上のメッセージが失われたのを知らせるように、LMRコマンドは受信ホストによって送られます。 MSN分野は失われた最初のメッセージのメッセージ通番を指定します。 LRN分野はコミュニケーションが回復するなら使用しなければならない新しいLRN値を指定します。
(Comments: As will be seen later, the LMR command also has the effect of resetting the bit and message allocation in the sending host to zero. In order to permit a sender to restore communication, an LMR command will be usually accompanied with an allocate command. However notice that these comments do not apply to the control links because there is no allocation mechanism for the control links.)
(コメント: また、後で見られるように、LMRコマンドには送付ホストにビットとメッセージ配分をゼロにリセットするという効果があります。 送付者がコミュニケーションを回復することを許可するために、通常、LMRコマンドは割り当てコマンドで伴われるでしょう。 しかしながら、コントロールリンクへの配分メカニズムが全くないのでこれらのコメントがコントロールリンクに適用されないのに注意してください。)
3.2.2 LMS - LOST MESSAGE FROM SENDER
3.2.2 LMS--送付者からのメッセージを失います。
____8_________8________8__________8_________8_____ I I I I I I I LMS I Link I LRN I MSN I COUNT I I__________I________I_________I__________I________I_
____8 _________8 ________8 __________8 _________8 _____ I I I I I I I LMS IリンクI LRN I MSN IはI I_を数えます。_________I________I_________I__________I________I_
This command is sent by a sender host in reply to an LMR command if it (the sender) can not retransmit the lost messages specified by the LMR command. The purpose of this command is to query the receiver whether or not the loss of messages is acceptable. After sending this command, the sender waits for a reply before transmitting any messages over the link involved. This command may not be sent for control links. The LRN and MSN values are same as those specified by the LMR command. COUNT specifies the number of messages lost.
それ(送付者)がLMRコマンドで指定された無くなっているメッセージを再送できないなら、このコマンドはLMRコマンドに対して送付者ホストによって送られます。 このコマンドの目的はメッセージの損失が許容できるか否かに関係なく、受信機について質問することです。 このコマンドを送った後に、かかわったリンクの上にどんなメッセージも送る前に、送付者は回答を待ちます。 このコマンドはコントロールリンクに送られないかもしれません。 LRNとMSN値はものがLMRコマンドで指定したのと同じです。 COUNTは失われたメッセージの数を指定します。
3.2.3 LMA - LOSS OF MESSAGES ACCEPTABLE
3.2.3 LMA--許容できるメッセージの損失
This command is identical to the LMS command accept for the command code. Upon receipt of an LMS command, a receiver may
このコマンドは、コマンドコードのために受け入れるためにLMSが、命令する同じです。 LMSコマンドを受け取り次第、受信機はそうするかもしれません。
- 12 -
- 12 -
send this command to the sender to let the sender know that loss of messages is acceptable. All fields in this command are set to corresponding values in the LMS command.
このコマンドを送付者に送って、送付者にメッセージの損失が許容できるのを知らせてください。 このコマンドにおけるすべての分野がLMSコマンドにおける換算値に設定されます。
3.2.4 CLS2 - CLOSE2
3.2.4 CLS2--CLOSE2
____8___________3_2_______________3_2_____________8_______8______ I I I I I I I CLS2 I my socket I your socket I LRN I MSN I I________I_______________I__________________I________I_______I_
____8 ___________3 _2 _______________3 _2 _____________8 _______8 __ ____ I I I I I I I CLS2I、私のソケットI、あなたのソケットI LRN I MSN I I________I_______________I__________________I________I_______I_
The CLS2 command is similar to the current CLS command except for the LRN and MSN fields included in the new command. Both the receiving and sending hosts copy their values of LRN and MSN into the CLS2 command. Upon receiving a CLS2 command, a host compares the LRN and MSN values contained in the CLS2 command with its own values for the connection involved. If these values do not match, then an error has occurred and a host may initiate recovery procedures.
新しいコマンドに分野を含んでいて、CLS2コマンドはLRNとMSN以外の現在のCLSコマンドと同様です。 受信と送付ホストの両方が彼らのLRNとMSNの値をCLS2コマンドにコピーします。 CLS2コマンドを受け取ると、ホストは値が接続のためのそれ自身の値があるコマンドがかかわったCLS2に含んだLRNとMSNを比較します。 これらの値が合っていないなら、誤りは発生しました、そして、ホストはリカバリ手順に着手するかもしれません。
(Comments: The purpose of this command is to ensure that the last message transmitted on a connection has been received succesfully.)
(コメント: このコマンドの目的は接続に送られた最後のメッセージがsuccesfullyに受け取られたのを保証することです。)
3.2.5 ECLS - ERROR CLOSE
3.2.5 ECLS--誤り閉鎖
_____8___________3_2___________3_2_________ I I I I I ECLS I my socket I your socketI I_________I______________I______________I_
_____8 ___________3 _2 ___________3 _2 _________ I I I I I ECLS I、私のソケットI、あなたのsocketI I_________I______________I______________I_
The ECLS command is similar to the current CLS command. It is used for closing connections which have sufferred an irrecoverable loss of messages.
ECLSコマンドは現在のCLSコマンドと同様です。 それは、メッセージの取り返しのつかない損失をsufferredした接続を終えるのに使用されます。
(Comments: A connection may be closed in any one of the following three ways:
(コメント: 接続は以下の3つの方法のどれかに閉店するかもしれません:
1. A connection which has not yet been opened succesfully
may be closed by the CLS command. All connections
involving type A hosts must be closed using the CLS
command.
2. Connections between type B hosts may be closed using
CLS2 command. A connection is considered closed only
if matching CLS2 commands have been exchanged between
1. まだ開かれていない接続はCLSコマンドでsuccesfullyに閉店するかもしれません。 タイプAホストにかかわるすべての接続が、CLSコマンドを使用することで閉店しなければなりません。 2. タイプBホストの間のコネクションズは、CLS2コマンドを使用することで閉じられるかもしれません。 間に合っているCLS2コマンドを交換した場合にだけ、閉じられると接続を考えます。
- 13 -
- 13 -
the sender and the receiver.
3. Those connections between type B hosts, that have
sufferred an irrecoverable loss of messages, must be
closed by the ECLS command.)
送付者と受信機、3 タイプBホストの間のそれらの接続であり、それをメッセージの取り返しのつかない損失をsufferredして、ECLSコマンドで閉じなければなりません。)
3.2.6 RSS - REQUEST STATUS FROM SENDER
3.2.6 RSS--送付者から状態を要求してください。
____8_______8______ I I I I RSS I LINK I I_______I_________I_
____8 _______8 ______ I I I I RSS IリンクI I_______I_________I_
A sending host may issue an RSS command to find out about the status of transmission on a particular connection or the control link.
送付ホストは特定の接続かコントロールリンクの上にトランスミッションの状態を見つけるRSSコマンドを発行するかもしれません。
3.2.7 RSR - REQUEST STATUS FROM RECEIVER
3.2.7 RSR--受信機から状態を要求してください。
____8_________8_____ I I I I RSR I LINK | I________I_________I_
____8 _________8 _____ I I I I RSR Iリンク| I________I_________I_
A receiver can issue an RSR command to find out about the status of transmission on a particular connection or the control link.
受信機は特定の接続かコントロールリンクの上にトランスミッションの状態を見つけるRSRコマンドを発行できます。
3.2.8 SFR - STATUS FROM RECEIVER
3.2.8 SFR--受信機からの状態
____8_________8_________8_________8____ I I I I I I SFR I LINK I LRN I MSN I I_________I_________I_________I________I_
____8 _________8 _________8 _________8 ____ I I I I I I SFR IリンクI LRN I MSN I I_________I_________I_________I________I_
A receiving host may issue this command to inform the sender about the state of a particular connection or the control link.
受信ホストは特定の接続の状態かコントロールリンクに関して送付者に知らせるこのコマンドを発行するかもしれません。
3.2.9 SFS - STATUS FROM SENDER
3.2.9 SFS--送付者からの状態
- 14 -
- 14 -
____8_________8_________8_________8____ I I I I I I SFS I LINK I LRN I MSN I I_________I_________I_________I________I_
____8 _________8 _________8 _________8 ____ I I I I I I SFS IリンクI LRN I MSN I I_________I_________I_________I________I_
A sending host may issue this command to inform the receiver about the state of a particular connection or the control link.
送付ホストは特定の接続の状態かコントロールリンクに関して受信機を知らせるこのコマンドを発行するかもしれません。
3.3 THE PROTOCOL
3.3 プロトコル
3.3.1 PART ONE
3.3.1 パート1
All type A hosts must use zero MSN and LRN values on the messages sent out by them. When communicating with a host of type A, a type B host must simulate the behaviour of type A host.
すべてのタイプAホストがメッセージのMSNとLRN値がそれらによる外に送ったゼロを使用しなければなりません。 タイプAのホストとコミュニケートするとき、タイプBホストはタイプAホストのふるまいをシミュレートしなければなりません。
(Comments: Notice that this simulation is not complicated at all. All that is required is that hosts that adopt this protocol must not use it when communicating with the hosts that have not adopted it.)
(コメント: このシミュレーションが全く複雑にされないのに注意してください。 必要であるすべてはそれを採用しないホストとコミュニケートするとき、このプロトコルを採用するホストがそれを使用してはいけないということです。)
3.3.2 PART TWO
3.3.2 パートTWO
This part of the protocol is stated as a set of rules which must be observed by all type B hosts when communicating with other type B hosts.
他のタイプBホストとコミュニケートするとき、すべてで守らなければならない1セットの規則がBホストをタイプするとき、プロトコルのこの部分は述べられます。
3.3.2.1 RESPONSIBILITIES OF HOSTS AS SENDERS
3.3.2.1 送付者としてのホストの責任
(1). A type B sending host must use message sequence numbers
on all regular messages that it sends to other type B
hosts as specified in the definition of the message
sequence numbers (Section 3.1.3).
(2). A type B sending host must use link resynch numbers on
all regular messages that it sends to other type B
hosts as specified in the definition of link resynch
number (Section 3.1.4).
(3). A sending host may retransmit a message if it suspects
that the message may have been lost in the network
during previous transmission.
(4). A sending host may issue an RSS command to the receiver
to determine the state of transmission on any link.
(5). A sending host must use the ECLS command to close a
connection, if the connection is being closed due to an
(1). タイプB送付ホストはメッセージ通番(セクション3.1.3)の定義における指定されるとしての他のタイプBホストに発信するというすべての通常のメッセージでメッセージ通番を使用しなければなりません。 (2). タイプB送付ホストはリンク「再-同時性」番号(セクション3.1.4)の定義における指定されるとしての他のタイプBホストに発信するというすべての通常のメッセージのリンク「再-同時性」番号を使用しなければなりません。 (3). 前のトランスミッションの間、メッセージがネットワークで失われているかもしれないと疑うなら、送付ホストはメッセージを再送するかもしれません。 (4). 送付ホストは、どんなリンクの上にもトランスミッションの状態を決定するためにRSSコマンドを受信機に発行するかもしれません。 (5). 送付ホストは接続を終えるECLSコマンドを使用しなければなりません、接続が当然の状態で閉店しているなら
- 15 -
- 15 -
irrecoverable transmission error. Otherwise, it must the CLS2 command.
回復しがたい伝送エラー。 そうでなければ、それはそうしなければなりません。CLS2コマンド。
3.3.2.2 RESPONSIBILITIES OF HOSTS AS RECEIVERS
3.3.2.2 受信機としてのホストの責任
(1). A receiver host will maintain LRN and MSN values for
each link on which it receives messages. Initial value
of LRN will be zero, and initial value of MSN will be
one. For each receive link, the host should be
prepared to receive a message with LRN and MSN values
specified by its tables. When the host has received
the expected message on a given link, it will change
its table MSN value as specified in the definition of
MSN.
(2). On a given link, if a host receives a message with an
LRN value smaller than the one in use, it will ignore
the message.
(3). If a host receives a duplicate message (same LRN and
MSN values), it will ignore the duplicate.
(4). A host will examine the MSN values on all regular
messages that it receives to detect loss of messages.
If on any link, one or more messages are found missing,
it will concern itself with only the first message lost
and take the following series of action:
(1). 受信ホストはそれがメッセージを受け取る各リンクにLRNとMSN値を維持するでしょう。 LRNの初期の値はゼロになるでしょう、そして、MSNの初期の値は1になるでしょう。 ホストはLRNと共にメッセージを受け取るために用意ができているべきでした、そして、それぞれに関しては、リンクを受けてください、そして、MSN値はテーブルで指定しました。 ホストが与えられたリンクに関する予想されたメッセージを受け取ったとき、それはMSNの定義における指定されるとしてのテーブルMSN価値を変えるでしょう。 (2). 与えられたリンクの上では、LRN値が使用中のものより小さい状態でホストがメッセージを受け取ると、それはメッセージを無視するでしょう。 (3). ホストが写しメッセージ(同じLRNとMSN値)を受け取ると、それは写しを無視するでしょう。 (4). ホストはメッセージの損失を検出するために受信するというすべての通常のメッセージのMSN値を調べるでしょう。 どんなリンクの上にも1つ以上のメッセージがなくなるのがわかると、最初のメッセージだけが失われている状態でタッチしていて、以下のシリーズの行動を取るでしょう:
1. Increase its own LRN value for this link by
one.
2. Send an LMR command to the sending host with
LRN field set to the new value and MSN field
set to the sequence number of the first
message lost.
3. Realizing that LMR command will cause the
allocation to be reset to zero, it will send
more allocation. This is not applicable to
the control links.
1. それ自身のLRN値をこのリンクに1つ増加させてください。 2. 新しい値にセットしたLRN分野と最初のメッセージの一連番号へのなくされているMSN分野セットの送付ホストにLMRコマンドを送ってください。 3. LMRコマンドでゼロに配分をリセットするとわかって、それは、より多くの配分を送るでしょう。 これはコントロールリンクに適切ではありません。
However, if a host does not want to initiate the
recovery procedures, it may simply close the connection
by an ECLS command.
(5). A receiver host may issue the RSR command to determine
the state of transmission on any link.
(6). If a connection is being closed due to an irrecoverable
error, a receiving host must use the ECLS command.
Otherwise it must use the CLS2 command.
しかしながら、ホストがリカバリ手順に着手したくないなら、それはECLSコマンドで単に接続を終えるかもしれません。 (5). 受信ホストはどんなリンクの上にもトランスミッションの状態を決定するRSRコマンドを発行するかもしれません。 (6). 接続が回復しがたい誤りのため閉店しているなら、受信ホストはECLSコマンドを使用しなければなりません。 さもなければ、それはCLS2コマンドを使用しなければなりません。
- 16 -
- 16 -
3.3.2.3 SENDING HOST'S RESPONSE TO CONTROL MESSAGES
3.3.2.3 メッセージを制御するためにホストの応答を送ること。
(1). RSR command: the sender must transmit a SFS command to
the receiver for the link involved.
(2). ECLS command: The sender must cease transmission, if it
has not already done so, and issue an ECLS command if
it has not already issues either a ECLS or CLS2
command.
(3) CLS2 command: The sender must compare the LRN and MSN
values of the CLS2 command with its own values of the
LRN and MSN for the connection involved. If an error
is indicated, it may either close the connection with
an ECLS, or initiate recovery action as specified in
the section 3.3.2.1.
(4). LMR command for a connection (i.e., not a control
link): The sender may follow any one of the following
three courses of action:
(1). RSRは命令します: 送付者はリンクへの受信機へのコマンドがかかわったSFSを伝えなければなりません。 (2). ECLSは命令します: それに既にECLSかCLS2のどちらかが命令する問題がないなら、送付者は、既にそうしていないならトランスミッションをやめて、ECLSコマンドを発行しなければなりません。 (3) CLS2は命令します: 送付者は伴われるそれ自身の接続のためのLRNとMSNの値にCLS2コマンドのLRNとMSN値をたとえなければなりません。 誤りが示されるなら、それは、ECLSと共に接続を終えるか、またはセクション3.3.2で指定されているとして.1に回復動作を開始するかもしれません。 (4). LMRは接続(すなわち、コントロールリンクでない)のために命令します: 送付者は動作の以下の3つの方針のどれかに従うかもしれません:
1. Close the connection with an ECLS command.
2. Set the allocations for the link involved to
zero, set LRN to that specified in the LMR
command, and restart communication at the
point of break.
3. Set the allocations for the link involved to
zero, set the LRN to that specified in the
LMR command, and send an LMS command to the
receiver host informing him that one or more
of the lost messages can not be
retransmitted. After sending an LMS command,
a sending host must not transmit any more
messages on the link involved until and
unless it receives an LMA command from the
receiver host.
1. ECLSコマンドとの関係を終えてください。 2. ゼロにかかわるリンクのための配分を設定してください、とそれへのセットLRNは中断のポイントでLMRコマンド、および再開コミュニケーションで指定しました。 3. ゼロにかかわるリンクのための配分を設定してください、そして、LMRコマンドで指定されたそれにLRNを設定してください、そして、無くなっているメッセージの1つ以上を再送できないことを彼に知らせる受信ホストにLMSコマンドを送ってください。 そして、LMSコマンドを送った後に送付ホストがかかわったリンクに関するそれ以上のメッセージを送ってはいけない、受信ホストからLMAコマンドを受け取らない場合。
(Comments: As we have mentioned before (Section 2.3), the decision regarding which course of action to follow depends upon a number of factors. For example, if a host has implemented only the detection of lost messages aspect of our protocol (and no recovery), then it will chose the first option of closing the connection.)
(コメント: 私たちが以前(セクション2.3)言及したことがあるように、どの行動に続いたらよいかに関する決定は多くの要因に依存します。 例えば、ホストが私たちのプロトコル(そして、回復がない)の無くなっているメッセージ局面の検出だけを実行したなら、それがそうするその時は接続を終える第1の選択を選びました。)
(5). LMR for a control link: The sender may take one of the
following two actions:
(5). コントロールのためのLMRはリンクします: 送付者は以下の2つの動作の1つを取るかもしれません:
1. Set the LRN to that specified in the LMR
command and begin retransmission of lost
messages
2. Set the LRN to that specified by the LMR
command, and insert a Reset command at the
break point.
1. LMRコマンドで指定されたそれにLRNを設定してください、そして、無くなっているメッセージ2の「再-トランスミッション」を始めてください。 LMRコマンドで指定されたそれにLRNを設定してください、そして、ブレークポイントでResetコマンドを挿入してください。
- 17 -
- 17 -
(Comment: If a sending host can not retransmit messages lost on a control link, then this protocol requires that all communication between the two host be broken, and reinitialized. We do not explicitly specify the actions that are associated with the exchange of Reset commands. These actions are specified by the Host-to-Host protocol.)
(コメント: 送付ホストがコントロールリンクの上に失われたメッセージを再送できないなら、このプロトコルは、2ホストのすべてのコミュニケーションが壊されて、再初期化されるのを必要とします。 私たちは明らかにResetコマンドの交換に関連している動作を指定しません。 これらの動作はHostからホストへのプロトコルによって指定されます。)
(6). LMA command: When a sending host receives an LMA
command matching an LMS command previously issued by
it, it may resume transmission.
(6). LMAは命令します: 送付ホストが以前にそれによって発行されたLMSコマンドに合っているLMAコマンドを受け取るとき、それはトランスミッションを再開するかもしれません。
(Comments: The protocol does not require the sending host to take any specific action with regard to a SFR. However, a sending host may use the information contained in the SFR command regarding the state of transmission. From a SFR command a sender host may determine what messages have been received properly. The sender may use this information to cleanup its buffer space or retransmit messages that it might suspect are lost.)
(コメント: プロトコルは、送付ホストがSFRに関してどんな特定の行動も取るのを必要としません。 しかしながら、送付ホストはトランスミッションの状態に関するSFRコマンドに含まれた情報を使用するかもしれません。 SFRコマンドから、送付者ホストは、どんなメッセージが適切に受け取られたかを決心するかもしれません。 送付者は、バッファが区切るクリーンアップにこの情報を使用するか、またはそれが無くなると疑うかもしれないメッセージを再送するかもしれません。)
3.3.2.4 RECEIVING HOST'S RESPONSE TO CONTROL MESSAGES
3.3.2.4 メッセージを制御する受信ホストの応答
(1). RSS command: A receiver is obligated to transmit a SFR
to the sender for the link involved.
(1). RSSは命令します: 受信機がかかわったリンクのためにSFRを送付者に伝えるのが義務付けられます。
(2). ECLS command: The receiver must close the connection
by issuing an ECLS command if it has not already done
so.
(2). ECLSは命令します: 受信機は、既にそうしていないならECLSコマンドを発行することによって、接続を終えなければなりません。
(3). CLS2 command: A receiver must compare the LRN and MSN
values of the command with its own values for the
connection involved. If an error is indicated, it may
either close the connection by an ECLS command or
initiate recovery procedures as specified in section
3.3.2.2.
(3). CLS2は命令します: 受信機は接続のためのそれ自身の値があるコマンドの値がかかわったLRNとMSNを比較しなければなりません。 誤りが示されるなら、それは、ECLSコマンドで接続を終えるか、またはセクション3.3.2で指定されているとして.2にリカバリ手順に着手するかもしれません。
(4). LMS command: The receiver may take one of the following
two courses of action:
(4). LMSは命令します: 受信機は動作の以下の2つの方針の1つを取るかもしれません:
(1). Close the connection specified by the LMS
command, by issuing an ECLS command.
(2). Set the link involved to be prepared to
receive messages starting with the sequence
number MSN + COUNT, where MSN and COUNT are
those specified by the LMS command.
(Comment: This action implies that receiver
is willing to accept the loss of messages
specified by the LMS command.)
(1). 近くでは、接続が、LMSコマンド、ECLSコマンドを発行することによって、指定しました。 (2). 準備されるためにかかわるリンクにMSNとCOUNTがLMSコマンドで指定されたものである一連番号MSN+COUNTから始まって、メッセージを受け取るように設定してください。 (コメント: この動作は、受信機が、LMSコマンドで指定されたメッセージの損失を受け入れても構わないと思っているのを含意します。)
(Comments: The protocol does not require the receiver to take any specific action with regard to a SFS command. However a receiver
しかしながら、(コメント: プロトコルはSFSコマンドに関してどんな特定の行動も取るのに受信機が必要でない、受信機
- 18 -
- 18 -
host may use the information contained in it.)
ホストはそれに含まれた情報を使用するかもしれません。)
4.0 CONCLUDING REMARKS
4.0 所見を結論づけること。
The design of this protocol has been governed by three major principles. First, we believe that to be useful within the ARPA Network, any new protocol must be compatible with the existing protocols, so that each host can make the transition to the new protocol at its own pace and without large investment. Secondly, the protocol should tie into the recovery mechanism of the IMP-to-Host Protocol. The price we pay for this is the small MSN field and a message oriented protocol rather than a byte stream oriented protocol. The third consideration has been flexibility. While this protocol guarantees detection of lost messages, the philosophy behind the recovery procedures is that a host should have several options, each option providing a different degree of sophistication. A host can implement a recovery procedure that is most suitable for its needs and the capabilities of its machine. Even though two hosts may have implemented different recovery procedures, they can communicate with each other in a compatible way. In a network of independent machines of widely varying capabilities and requirements, this seems to be the only way of implementing such a protocol. Even though this protocol provides a variety of options in a given error situation, the choice of a specific action must be consistent with the basic requirements of the communication path. For example, partial recovery is not acceptable during file transfers. We fully expect the File Transfer Protocol to specify that if an irrecoverable error occurs, the file transfer must be aborted.
このプロトコルのデザインは3つの主要な原則によって支配されました。 まず最初に、私たちは、アーパネットの中で役に立つように、どんな新しいプロトコルも既存のプロトコルと互換性がなければならないと信じています、各ホストがそれ自身のペースにおいて多額の投資なしで新しいプロトコルへの変遷をすることができるように。 第二に、プロトコルはIMPからホストへのプロトコルの回収機構を激しく攻撃するべきです。 これが小さいMSN分野であり、メッセージがバイト・ストリームよりむしろプロトコルを適応させたので、私たちが支払う価格はプロトコルを適応させました。 3番目の考慮は柔軟性です。 このプロトコルは無くなっているメッセージの検出を保証しますが、リカバリ手順の後ろの哲学はホストにはいくつかのオプション(異なった度合いに関する洗練を提供する各オプション)があるべきであるということです。 ホストは必要性に最も適したリカバリ手順とマシンの能力を実装することができます。 2人のホストが、異なった回復が手順であると実装したかもしれませんが、彼らはコンパチブル方法で互いにコミュニケートできます。 広く能力と要件を変える独立しているマシンのネットワークでは、これは唯一の道にそのようなプロトコルを実装するのがあるように思えます。 このプロトコルはさまざまなオプションを与えられたエラー状態に提供しますが、特定の動作の選択は通信路に関する基本的な要件と一致しているに違いありません。 例えば、部分的な回復はファイル転送の間、許容できません。 私たちは、File Transferプロトコルが、回復しがたい誤りが発生するなら、ファイル転送を中止しなければならないと指定すると完全に予想します。
- 19 -
- 19 -
一覧
スポンサーリンク
