RFC467 日本語訳
0467 Proposed change to Host-Host Protocol: Resynchronization ofconnection status. J.D. Burchfiel, R.S. Tomlinson. February 1973. (Format: TXT=14325 bytes) (Updated by RFC0492) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Burchfiel
Request for Comments: 467 R. Tomlinson
NIC: 14741 Bolt Beranek and Newman
20 February 1973
Burchfielがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 467 R.トムリンスンNIC: 14741 ボルトBeranekとニューマン1973年2月20日
Proposed Change To Host-Host Protocol
Resynchronization Of Connection Status
接続形態のホスト兼ホストプロトコルResynchronizationへの変更案
I. Introduction
I. 序論
The current Host-Host protocol (NIC #8246) contains no provisions for resynchronizing the status information kept at the two ends of each connection. In particular, if either host suffers a service interruption, or if a control message is lost or corrupted in an interface or in the subnet, the status information at the two ends of the connection will be inconsistent.
現在のHost-ホストプロトコル(NIC#8246)はそれぞれの接続の2つの終わりに保たれた状態情報を再連動させるための条項を全く含んでいません。 コントロールメッセージがインタフェースかサブネットでどちらのホストも停電に苦しむか、失われているか、または崩壊すると、接続の2つの終わりの状態情報は特に、矛盾するようになるでしょう。
Since the current protocol provides no way to correct this condition, the NCP's at the two ends stay "confused" forever. A frequent and frustrating symptom of this effect is the "lost allocate" phenomenon, where the receiving NCP believes that it has bit and message allocations outstanding, while the sending NCP believes that it does not have any allocation. As a result, information flow over that connection can never be restarted.
この効果の頻繁でいらだたしい兆候が現在のプロトコルがこの条件(滞在がいつまでも「混乱させた」2つの終わりのNCPのもの)を修正する方法を全く提供しないからである「失われて、」 現象を割り当ててください、受信NCPが、噛み付いて、送付NCPが信じている間のそれがする未払いのメッセージ配分が少しの配分も持っていないと信じているところで。 その結果、その接続の上の情報流動を決して再開できません。
Use of the Host-Host RST (reset) command is inappropriate here, as it destroys all connections between the two hosts. What is needed is a way to reset only the affected connection without disturbing any others.
2人のホストの間のすべての接続を滅ぼすとき、Host-ホストRST(リセット)コマンドの使用はここで不適当です。 必要であるものはどんな他のものも心をかき乱さないで影響を受ける接続だけをリセットする方法です。
A second troublesome symptom of inconsistency in status information is the "half-closed" connection: after a service interruption or network partitioning, one NCP may believe that a connection is still open, while the other believes that the connection is closed. (Does not exist.) When such an inconsistency is discovered, the "open" end of the connection should be closed.
状態情報における、矛盾の2番目の厄介な兆候は「半開きな」接続です: 停電かネットワーク仕切りの後に、1つのNCPが、接続がまだオープンであると信じるかもしれません、もう片方が、接続が閉じられると信じていますが。 (存在していません。) そのような矛盾が発見されるとき、接続の「開いている」終わりは閉じられるべきです。
Burchfiel [Page 1] RFC 467 February 1973
Burchfiel[1ページ]RFC467 1973年2月
II. The RCR and RCS Commands
II。 RCRとRCSコマンド
To achieve resynchronization of allocation, we propose the addition of the following two commands to the host-host protocol.
配分の再同期を達成するために、私たちはホスト兼ホストプロトコルへの以下の2つのコマンドの追加を提案します。
8 8
+-----------+-----------+
| RCS | link | Reset connection by sender
+-----------+-----------+
8 8 +-----------+-----------+ | RCS| リンク| 送付者+によるリセット接続-----------+-----------+
8 8
+-----------+-----------+
| RCR | link | Reset connection by receiver
+-----------+-----------+
8 8 +-----------+-----------+ | RCR| リンク| 受信機+で接続をリセットしてください。-----------+-----------+
The RCS command is sent from the host sending on "link" to the host receiving on "link". This command may be sent whenever the sending host desires to re-synch the status information associated with the connection. Some circumstances in which the sending Host may choose to do this are:
「リンクしてください」と転送するホストから「リンク」で受信しているホストにRCSコマンドを送ります。 送付ホストが接続に関連している状態情報を再の同時性に望んでいるときはいつも、このコマンドを送るかもしれません。 発信しているHostがこれをするのを選ぶかもしれないいくつかの事情は以下の通りです。
1.) After a timeout when there is traffic to move but no
allocation. (Assumes that an allocation has been lost)
1.) 動かす交通がありますが、どんな配分もないときのタイムアウトの後に。 (配分が失われたと仮定します)
2.) When an inconsistent event occurs associated with that
connection (e.g. an outstanding allocation in excess of 2^32 bits
or 2^16 messages.
2.) 矛盾したイベントがいつ起こるかはその接続と交際しました。(例えば、2^32ビットか2^16のメッセージを超えた傑出している配分。
The mechanics of re-synchronizing the allocations is simply:
配分を再同時にさせる整備士は単に以下の通りです。
1.) Empty all messages and allocates from the "pipeline".
1.) すべてを空にしてください。「パイプライン」から通信して、割り当てます。
2.) Zero the variables at both ends indicating bit and message
allocation.
2.) ビットとメッセージ配分を示す両端で変数のゼロを合わせてください。
3.) Restart allocate/message exchanges in the normal way.
3.) 再開は正常な方法で/交換処理を割り当てます。
This resynchronization scheme is race-free because the RCS and RCR commands are used as a positive acknowledgement pair.
RCSとRCRコマンドが積極的な承認組として使用されるので、この再同期計画はレースなしです。
III. Resynchronization by Sender
III。 送付者によるResynchronization
To initiate resynchronization, the sending NCP should:
再同期を開始するために、送付NCPはそうするべきです:
1.) Put the connection in a "waiting-for-RCR-reply" state. No
more regular messages may be transmitted over this connection
until the RCR reply is received.
1.) 「RCR回答を待ち」状態に接続を置いてください。 RCR回答が受け取られているまで、それ以上の通常のメッセージはこの接続の上に送られないかもしれません。
Burchfiel [Page 2] RFC 467 February 1973
Burchfiel[2ページ]RFC467 1973年2月
2.) Wait until the message pipeline is empty, i.e. until a RFNM
has been received for each regular message sent over this
connection. This synchronizes the control and data activity, and
also assures that the data stream will not be corrupted during the
control re-synchronization exchange.
2.) メッセージパイプラインが空になるまで、待ってください、すなわち、この接続の上に送られたそれぞれの通常のメッセージのためにRFNMを受け取るまで。 これは、コントロールとデータ活動を同時にさせて、また、データ・ストリームがコントロール再同期交換の間汚されないことを保証します。
3.) Send the RCS command.
3.) RCSコマンドを送ってください。
4.) Continue to process allocates normally, updating the variables
which indicate outstanding bit and message allocation.
4.) 続けてください。過程は傑出しているビットとメッセージ配分を示す変数を通常アップデートに割り当てます。
When the receiving NCP receives the RCS, it should:
受信NCPがRCSを受けるとき、受けるべきです:
1.) Zero the variables indicating outstanding bit and message
allocation.
1.) 傑出しているビットとメッセージ配分を示す変数のゼロを合わせてください。
2.) Reset the connection to the state which indicates readiness to
accept a message.
2.) メッセージを受け入れる準備を示す州に接続をリセットしてください。
3.) Confirm the re-synchronization by sending the RCR reply.
3.) RCR回答を送ることによって、再同期を確認してください。
4.) Reconsider bit and message allocation, and send an ALL command
for any allocation it cares to do.
4.) ビットとメッセージ配分を再考してください、そして、それがするのを気にかけるどんな配分のためのすべてのコマンドも送ってください。
When the sending host receives the RCR reply, it should:
送付ホストがRCR回答を受け取るとき、受け取るべきです:
1.) Zero the variables indicating outstanding bit and message
allocate.
1.) 傑出しているビットを示して、メッセージが割り当てる変数のゼロを合わせてください。
2.) Put the connection into the "ready-to-send-message" state in
preparation for any forthcoming ALL commands.
2.) 置かれて、どんな今度のすべてに備えた「メッセージを送るのにおいて準備ができる」状態との接続は命令します。
At this point, the "pipeline" contains no messages and no allocates, and the outstanding allocation variables at both ends are in agreement. (With value zero)
ここに、「パイプライン」はいいえをメッセージといいえが割り当てる含みます、そして、両端における傑出している配分変数は合意しています。 (値ゼロがある)
IV. Resynchronization By Receiver
IV。 受信機によるResynchronization
The re-synchronization sequence may be triggered by the receiving NCP. Such resynchronization could be initiated manually by TIP and TELNET users who are expecting output but receiving none. Again assuming that allocation has been lost, the appropriate action is to reset the connection by sending an RCR command. This action is also appropriate if an inconsistent event occurs with respect to the connection. (e.g. arrival of a message which exceeds allocation).
再同期系列は受信NCPによって引き起こされるかもしれません。 出力を予想しますが、なにも受けていないTIPとTELNETユーザは手動でそのような再同期を開始できました。 再び配分が失われたと仮定して、適切な行動はRCRコマンドを送ることによって接続をリセットすることです。 また、矛盾したイベントが接続に関して起こるなら、この動きも適切です。 (例えば、配分を超えているメッセージの到着。)
Burchfiel [Page 3] RFC 467 February 1973
Burchfiel[3ページ]RFC467 1973年2月
To initiate re-synchronization, the receiving NCP should:
再同期を開始するために、受信NCPはそうするべきです:
1.) Put the connection into a "waiting-for-RCS-reply" state. No
more allocates may be transmitted for this connection until the
RCS reply is received.
1.) 「RCS回答を待ち」状態に接続を入れてください。 RCS回答が受け取られているまで、いいえは以上が割り当てるこの接続のために伝えられるかもしれません。
2.) Send the RCR command.
2.) RCRコマンドを送ってください。
3.) Continue to process regular messages normally, updating the
variables which indicate outstanding bit and message allocation.
3.) 傑出しているビットとメッセージ配分を示す変数をアップデートして、通常、通常のメッセージを処理し続けてください。
When the sending NCP receives the RCR command, it should:
送付NCPがRCRコマンドを受け取るとき、受け取るべきです:
1.) Wait until the message pipeline is empty, i.e. until the RFNM
has been received for each regular message sent over the
connection. This synchronizes the control and data activity, and
also assures that the data stream will not be corrupted during the
control re-synchronization exchange.
1.) メッセージパイプラインが空になるまで、待ってください、すなわち、接続の上に送られたそれぞれの通常のメッセージのためにRFNMを受け取るまで。 これは、コントロールとデータ活動を同時にさせて、また、データ・ストリームがコントロール再同期交換の間汚されないことを保証します。
2.) Zero the variables indicating outstanding bit and message
allocation.
2.) 傑出しているビットとメッセージ配分を示す変数のゼロを合わせてください。
3.) Put the connection into the "ready-to-send-message" state in
preparation for any forthcoming ALL commands.
3.) 置かれて、どんな今度のすべてに備えた「メッセージを送るのにおいて準備ができる」状態との接続は命令します。
4.) Confirm the re-synchronization by sending the RCS reply.
4.) RCS回答を送ることによって、再同期を確認してください。
When the receiving host receives the RCS reply, it should:
受信ホストがRCS回答を受け取るとき、受け取るべきです:
1.) Zero the variables indicating outstanding bit and message
allocation.
1.) 傑出しているビットとメッセージ配分を示す変数のゼロを合わせてください。
2.) Reset the connection to the state which indicates readiness to
accept a message.
2.) メッセージを受け入れる準備を示す州に接続をリセットしてください。
3.) Reconsider bit and message allocation, and send an ALL command
for any allocation it cares to do.
3.) ビットとメッセージ配分を再考してください、そして、それがするのを気にかけるどんな配分のためのすべてのコマンドも送ってください。
V. Simultaneous Resynchronization
V。 同時のResynchronization
This specification for a re-synchronization exchange is guaranteed to restore the allocation information at the two ends to a consistent state. This happens correctly whether the re-synchronization is triggered by the sender, the receiver, or both at the same time. When both ends initiate a command at the same time, (the RCS and RCR commands cross in the pipeline) each interprets the other's command as a confirmation reply; thus, the resynchronization happens correctly independent of the relative timing.
再同期交換のためのこの仕様は、一貫した状態の2つの端のときに配分情報を回復するために保証されます。 再同期が同時に送付者、受信機、または両方によって引き起こされるか否かに関係なく、これは正しく起こります。 両端が同時にのコマンドと、(パイプラインで交差しているRCSとRCRコマンド)を開始するとき、それぞれが確認回答としてもう片方のコマンドを解釈します。 したがって、再同期は相対的なタイミングの如何にかかわらず正しく起こります。
Burchfiel [Page 4] RFC 467 February 1973
Burchfiel[4ページ]RFC467 1973年2月
The essential factor here is that when either end receives the reset request, it is sure that the other end will take no further actions which could affect the allocation variables. The activity which occurs during simultaneous resynchronization by both ends is as follows:
ここの必須な要素はどちらの終わりがもリセット要求を受け取るとき、もう一方の端がこれ以上配分変数に影響するかもしれない行動を取らないのが、確かであるということです。 同時の再同期の間に両端に起こる活動は以下の通りです:
The sending NCP:
送付NCP:
1. Puts the connection into a "waiting-for-RCR-reply" state. No
more regular messages may be transmitted over this connection
until the RCR reply is received.
1. 「RCR回答を待ち」状態に接続を入れます。 RCR回答が受け取られているまで、それ以上の通常のメッセージはこの接続の上に送られないかもしれません。
2. Waits until the message pipeline is empty, i.e. until a RFNM
has been received for each regular message sent over this
connection. This synchronizes the control and data activity, and
also assures that the data stream will not be corrupted during the
control re-synchronization exchange.
2. メッセージパイプラインまでのウェイツは空です、すなわち、この接続の上に送られたそれぞれの通常のメッセージのためにRFNMを受け取るまで。 これは、コントロールとデータ活動を同時にさせて、また、データ・ストリームがコントロール再同期交換の間汚されないことを保証します。
3. Sends the RCS command.
3. RCSコマンドを送ります。
4. Continues to process allocates normally, updating the variables
which indicate outstanding bit and message allocation.
4. 続行、処理するのは通常、傑出しているビットを示す変数をアップデートして、メッセージ配分を割り当てます。
Concurrently with 1, 2, 3 and 4 above, the receiving NCP:
同時に、1と2と3と上の4、受信NCPで:
5. Puts the connection into a "waiting-for-RCS-reply" state. No
more allocates may be transmitted for this connection until the
RCS reply is received.
5. 「RCS回答を待ち」状態に接続を入れます。 RCS回答が受け取られているまで、いいえは以上が割り当てるこの接続のために伝えられるかもしれません。
6. Sends the RCR command.
6. RCRコマンドを送ります。
7. Continues to process regular messages normally.
7. 通常、通常のメッセージを処理し続けています。
The RCS and RCR commands cross somewhere in the pipeline. When the sender receives the RCR command, it interprets it as a reply to its own RCS command. It then:
RCSとRCRコマンドはパイプラインのどこかと交差しています。 送付者がRCRコマンドを受け取るとき、それは回答としてそれ自身のRCSコマンドにそれを解釈します。 それ、その時:
8. Zeroes the variables indicating outstanding bit and message
allocation.
8. 傑出しているビットとメッセージ配分を示す変数のゼロを合わせます。
9. Puts the connection into the "ready-to-send-message" state in
preparation for any forthcoming ALL commands.
9. どんな今度のすべてに備えた「メッセージを送るのにおいて準備ができる」状態との接続のためにコマンドを置きます。
Concurrently with 8 and 9 above, the receiving NCP will receive the RCS command. It will interpret it as a reply to its own RCR command. It then:
同時に、8と9が上であるなら、受信NCPはRCSコマンドを受け取るでしょう。 それは回答としてそれ自身のRCRコマンドにそれを解釈するでしょう。 それ、その時:
Burchfiel [Page 5] RFC 467 February 1973
Burchfiel[5ページ]RFC467 1973年2月
10. Zeroes the variables indicating outstanding bit and message
allocation.
10. 傑出しているビットとメッセージ配分を示す変数のゼロを合わせます。
11. Resets the connection to the state which indicates readiness
to accept a message.
11. メッセージを受け入れる準備を示す州に接続をリセットします。
12. Reconsiders bit and message allocation, and sends an ALL
command for any allocation it cares to do.
12. それがするのを気にかけるどんな配分のためにもビットとメッセージ配分を再考して、すべてのコマンドを送ります。
VI. The Problem Of Half-closed Connections
VI。 半開きなコネクションズの問題
The above procedures provide a way to resynchronize a connection after a brief lapse by a communications component, which results in lost messages or allocates for an open connection.
上の手順は無くなった状態でコミュニケーションコンポーネントによる簡潔な過失の後のなる接続を再連動させる方法を提供します。オープンな接続のために通信するか、または割り当てます。
A longer and more severe interruption of communication may result from a partitioning of the subnet or from a service interruption on one of the communicating hosts. It is undesirable to tie up resources indefinitely under such circumstances, so the user is provided with the option of freeing up these resources (including himself) by unilaterally dissolving the connection. Here "unilaterally" means sending the CLS command and closing the connection without receiving the CLS acknowledgement. Note that this is legal only if the subnet indicates that the destination is dead.
コミュニケーションの、より長くて、より厳しい中断はサブネットの停電からの1人の交信しているホストかひとり仕切りから生じるかもしれません。 一方的に接続を溶かすことによってこれらのリソース(自分を含んでいる)を開けるオプションをユーザに提供して、無期限に下のそのような事情をリソースに結ぶのは望ましくありません。 ここの、「一方的に」というCLSコマンドを送って、CLS承認を受けないで接続を終える手段。 サブネットが、目的地が死んでいるのを示す場合にだけこれが法的であることに注意してください。
When service is restored after such an interruption, the status information at the two ends of the connection is out of synchronization. One end believes that the connection is open, and may proceed to use the connection. The disconnecting end believes that the connection is closed (does not exist), and may proceed to re-initialize communication by opening a new connection (RTS or STR command) using the same local socket.
サービスがそのような中断の後に復元されるとき、接続の2つの終わりの状態情報は同期から脱しています。 片端は、接続がオープンであると信じて、接続を使用しかけるかもしれません。 断線終わりは、接続が閉じられると(存在していません)信じて、同じ地方のソケットを使用することで新しい接続(RTSかSTRコマンド)を開くことによって、コミュニケーションを再初期化しかけるかもしれません。
The re-synchronization needed here is to properly close the open end of the connection when the inconsistency is detected. We propose to accomplish this by changing the semantics of three existing host-host protocol commands.
ここで必要であった再同期は適切に、矛盾が検出される接続の開いている端を閉じることです。 私たちは、3つの既存のホスト兼ホストプロトコルコマンドの意味論を変えることによってこれを達成するよう提案します。
VII. Redefinition of RTS, STR, ERR (link) to Handle Half-closed Connections
VII。 RTSのRedefinition(STR)は、半開きなコネクションズを扱うために間違えます(リンクします)。
The "missing CLS" situation described above can manifest itself in two ways. The first way involves action taken by the NCP at the "open" end of the connection. It may continue to send regular messages on the link of the half-closed connection, or control messages referencing its link. The NCP at the "closed" end should respond with the ERR message, specifying that the link is unknown. (Error code = 5 does not correspond to an open connection). On
上で説明された「なくなったCLS」状況は2つの方法で現れることができます。 最初の道は接続の「開いている」終わりのNCPによって取られた行動を伴います。 それは、半開きな接続、またはリンクに参照をつけるコントロールメッセージのリンクに通常のメッセージを送り続けるかもしれません。 リンクが未知であると指定して、「閉じている」終わりのNCPはERRメッセージで応じるべきです。 (エラーコード=5はオープンな接続と食い違っています。) オン
Burchfiel [Page 6] RFC 467 February 1973
Burchfiel[6ページ]RFC467 1973年2月
receipt of such an ERR message, the NCP at the "open" end should close the connection by modifying its tables, (without sending any CLS command) thereby bringing both ends into agreement.
そのようなERRメッセージの領収書、「開いている」終わりのNCPはテーブルを変更することによって、接続を終えるべきです、その結果、両端を協定に運び込みます(どんなCLSコマンドも送らないで)。
The second way this inconsistency can show up involves actions initiated by the NCP at the "closed" end. It may (thinking the connection is closed) send an STR or RTS to reopen the connection. The NCP at the "open" end will detect an inconsistency when it receives such an RTS or STR command, because it specifies the same foreign socket as an existing open connection. In this case, the NCP at the "open" end should close the connection (without sending any CLS command) to bring the two ends into agreement before responding to the RTS/STR.
この矛盾が現れることができる2番目の方法は「閉じている」終わりにNCPによって開始された動作を伴います。 それは、接続を再開させるためにSTRかRTSを送るかもしれません(接続が閉じられると思います)。 それがそのようなRTSかSTRコマンドを受け取るとき、「開いている」終わりのNCPは矛盾を検出するでしょう、既存のオープンな接続と同じ外国ソケットを指定するので。 この場合、「開いている」終わりのNCPは、RTS/STRに応じる前に2つの終わりを協定に運び込むように、接続(どんなCLSコマンドも送ることのない)を終えるべきです。
VIII. Conclusions
VIII。 結論
The scheme presented in Section II to resynchronize allocation has one very important property: the data stream is preserved through the exchange. Since no data is lost, it is safe to initiate re- synchronization from either end at any time. When in doubt, re- synchronize.
配分を再連動させるようにセクションIIに提示された計画は1つの非常に重要な特性を持っています: データ・ストリームは交換を通して保存されます。 どんなデータも無くならないので、いつでもどちらの終わりからも再同期を開始するのは安全です。 疑問で連動するときには、再連動してください。
The changes in the semantics of RTS, STR, and ERR(code 5) commands provide the synchronization needed to complete the closing of "half- closed" connections.
RTS、STR、およびERR(コード5)コマンドの意味論における変化は「半分閉じている」接続の閉鎖を完成するのに必要である同期を提供します。
The protocol changes above will make the host-host protocol far more robust, in that useful work can continue in spite of lapses by the communications components.
過失にもかかわらず、上の変化がその実質的な仕事ではるかに強健なホスト兼ホストプロトコルをするプロトコルはコミュニケーションコンポーネントで続くことができます。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Via Genie 08/00]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Via Genie08/00によるオンラインRFCアーカイブへの]
Burchfiel [Page 7]
Burchfiel[7ページ]
一覧
スポンサーリンク
