RFC636 日本語訳
0636 TIP/Tenex reliability improvements. J.D. Burchfiel, B. Cosell,R.S. Tomlinson, D.C. Walden. June 1974. (Format: TXT=19914 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
NWG/RFC# 636 JDB BPC RST DCW3 MLK 23-OCT-75 22:27 30490 TIP/TENEX Reliability Improvements
NWG/RFC#636JDB BPC RST DCW3 MLK23 10月の75 22: 27 30490のチップ/TENEX信頼性の改良
RFC 636 J. Burchfiel - BBN-TENEX
B. Cosell - BBN-NET
NIC 30490 R. Tomlinson - BBN-TENEX
D. Walden - BBN-NET
10 June 1974
RFC636J.Burchfiel--BBN-TENEX B.コーセル--BBNネットのNIC30490R.トムリンスン--BBN-TENEX D.ウォルデン--BBN-ネット1974年6月10日
TIP/TENEX Reliability Improvements
チップ/TENEX信頼性の改良
During the past months we have felt strong pressure to improve the reliability of TIP/TENEX network connection as improvement in the reliability of users' connections between TENEXs and TIPs would have major impact on the appearance of overall network reliability due to the large number and high visibility of TENEXs and TIPs. Despite the emphasis on TIP/TENEX interaction, all work done applies equally well to interactions between Hosts of any type.
過去の数カ月の間、私たちはTENEXsとTIPsとのユーザの接続の信頼性における改良が大きい数による総合的なネットワークの信頼性の外観とTENEXsとTIPsの高い視度に強い影響を持っているようにTIP/TENEXネットワーク接続の信頼性を改良する強い圧力を感じています。 TIP/TENEX相互作用への強調にもかかわらず、行われたすべての仕事が等しくどんなタイプのHostsの間の相互作用に井戸を適用します。
The remainder of this RFC gives a sketch of our plan for improving the reliability of connections bettween TIPs and TENEXs. Major portions of this plan have already been implemented (TIP version 322; TENEX version 1.32) and are now undergoing final test prior to release throughout the network. Completion of the implementation of the plan is expected in the next quarter.
このRFCの残りは接続bettween TIPsとTENEXsの信頼性を改良するための私たちのプランのスケッチを与えます。 このプランの主要部は、既に実行されて(TIPバージョン322; TENEXバージョン1.32)、リリースの前に現在、ネットワーク中で最終テストを受ける予定です。 プランの実現の完成は次の四半期に予想されます。
Our plan for improving the reliability of TIP/TENEX connections is concerned with obtaining and maintaining TIP/TENEX connections, gracefully recovering from lost connections, and providing clear messages to the user whenever the state of his connection changes.
迷子になった接続から優雅に回復して、彼の接続の状態が変化するときはいつも、明確なメッセージをユーザに提供して、TIP/TENEX接続の信頼性を改良するための私たちのプランはTIP/TENEX接続を得て、維持するのに関係があります。
When a TIP user attempts to open a connection to any Host, the Host may be down. In this case it would be helpful to provide the user with information about the extent of the Host's unavailability. To facilitate this, we modified the IMP program to accept and utilize information from a Host about when the Host will be back up and for what reason it is down. TENEX is to be modified to supply such information before it goes down, or through manual means, after it has gone down. When the TIP user then attempts to connect to the down TENEX, the IMP local to the TENEX returns the information about why and for how long TENEX will be down. The TIP is to be modified to report this sort of information to the user; e.g., "Host unavailable because of hardware maintenance -- expected available Tuesday at 16:30 GMT".
TIPユーザが、どんなHostにも接続を開くのを試みるとき、Hostは下がっているかもしれません。 この場合、Hostの使用不能の範囲の情報をユーザに提供するのは役立っているでしょう。 これを容易にするなら、私たちは、Hostがダウンしてそれがあるどんな理由がダウンするようにものになる時に関してHostからの情報を受け入れて、利用するようにIMPプログラムを変更しました。 落ちるか、またはそれの後の手動の手段で落ちる前にTENEXは、そのような情報を提供するように変更されることになっています。 TENEX、次に、TIPユーザが、下であるのに接続するのを試みるとき、TENEXへの地方のIMPは理由とTENEXがどれくらい長い間下がるか情報を返します。 TIPはこの種類の情報をユーザに報告するように変更されることになっています。 例えば、「ハードウェアの保守管理--空いている火曜日のグリニッジ標準時16時30分に予想されて、入手できないホスト。」
The TIP's logger is presently not reentrant. Thus, no single TIP user can be allowed to tie up the logger for too long at a time; and the TIP
現在、TIPのきこりはリエントラントではありません。 したがって、どんな独身のTIPユーザも一度に、長い間きこりをタイアップし過ぎることができるというわけではありません。 そして、チップ
NWG/RFC# 636 JDB BPC RST DCW3 MLK 23-OCT-75 22:27 30490 TIP/TENEX Reliability Improvements
NWG/RFC#636JDB BPC RST DCW3 MLK23 10月の75 22: 27 30490のチップ/TENEX信頼性の改良
therefore enforces a timeout of arbitrary length (about 60 seconds) on logger use. However, a heavily loaded Host cannot be guaranteed always to respond within 60 seconds to a TIP login request, and at present TIP users sometimes cannot get connected to a heavily loaded TENEX. To correct this problem, the TIP logger will be made reentrant and the timeout on logger use will be eliminated.
したがって、きこりの使用での任意の長さ(およそ60秒)のタイムアウトを実施します。 しかしながら、60秒以内にTIPログイン要求と、現在のTIPで応じるために、時々大いに積み込まれたTENEXにユーザを接続できないのをいつも大いに積み込まれたHostは保証できるというわけではありません。 この問題、きこりが作られているTIPを修正するために、きこりの使用でのリエントラントとタイムアウトは排除されるでしょう。
One notorious soft spot in the Host/Host protocol which degrades the reliability of connections is the Host/Host protocol incremental allocate mechanism. Low frequency software bugs, intermittant hardware bugs, etc., can lead to the incremental allocates associated with a connection getting out of synchronization. When this happens it usually appears to the user as if the connection just "hung up". A slight addiition to the Host/Host protocol to allow connection allocates to be resynchronized has been designed and implemented for both the TIP and TENEX.
接続の信頼性を下げるHost/ホストプロトコルにおける1つの悪名高い弱みはHost/ホストが増加で議定書を作るということです。メカニズムを割り当てます。 長波ソフトウェアのバグ、intermittantハードウェアバグ、など、同期から出る接続に関連づけられて、増加へのリードが割り当てる缶。 これが起こると、通常、まるで接続がまさしく「ハングアップするかの」ようにユーザにとって見えます。 接続を許すHost/ホストプロトコルへのわずかなaddiitionは、設計されていて、TIPとTENEXの両方のために実行されて、再連動するのを割り当てます。
TENEX has a number of internal consistency checks (called "bughalts") which occasionally cause TENEX to halt. Frequently, after diagnosis by system personnel, TENEX can be made to proceed without loss from the viewpoint of local users. A mechanism is being provided which allows TENEX to proceed in this case from the point of view of TIP users of TENEX.
TENEXには、TENEXが時折停止する多くの内的整合性チェック("bughalts"と呼ばれる)があります。 システム人員による診断の後に、頻繁に、TENEXは地元のユーザの観点からの損失なしで続かされることができます。 メカニズムは提供することですTENEXがこの場合TENEXのTIPユーザの観点から進むことができる。
The appropriate mechanism entails the following: TENEX will not drop its ready line during a bughalt (from which TENEX can usually proceed successfully), nor will it clear its NCP tables and abort all connections. Instead, after a bughalt TENEX will: discard the message it is currently receiving, as the IMP has returned an Incomplete Transmission to the source for this message; reinitialize the interface to the IMP; and resynchronize, on all connections possible, Host/Host protocol allocate inconsistencies due to lost messages, RFNMs etc. The latter is done with the same mechanism described above. This procedure is not guaranteed to save all data -- a tiny bit may be lost -- but this is of secondary importance to maintaining the connection over the TENEX bughalt.
適切な手段は以下を伴います: TENEXがbughalt(通常、TENEXが首尾よく続くことができる)の間、持ち合わせの線を落とさないで、それは、NCPテーブルをきれいにして、すべての接続を中止するというわけではないでしょう。 代わりに、後に、a bughalt TENEXは望んでいます: それが現在受け取っているメッセージを捨ててください、IMPがこのメッセージのためにIncomplete Transmissionをソースに返したとき。 再初期化、IMPへのインタフェース。 可能なHost/ホストプロトコルが無くなっているメッセージによる矛盾を割り当てるすべての接続のときに、RFNMsなどを再連動させます。 同じメカニズムが上で説明されている状態で、後者をします。 この手順はすべてのデータを保存するために保証されませんが(小さいビットはなくされるかもしれません)、これは二次にTENEX bughaltの上の接続を維持するのに重要です。
The TIP user must be kept fully informed as TENEX halts and then continues. Therefore, the TIP has been modified to report "Host not responding -- connection suspended" when it senses that TENEX has halted (it does this by properly interpreting messages returned by the destination IMP). When TENEX resumes service after proceeding from a bughalt, the above procedure notifies the TIP that service is restored, and the TIP has been modified to report "Service resumed" to all users of that Host.
TENEXが停止して、次に、続けているようにTIPユーザを完全に知識があるように保たなければなりません。 したがって、TENEXが停止したと感じると(それは適切に目的地IMPによって返されたメッセージを解釈することによって、これをします)、TIPは「応じないことを接待してください--停学になった接続」と報告するように変更されました。 TENEXがbughaltから進んだ後にサービスを再開すると、上の手順は、サービスが復元されて、TIPが「再開されたサービス」をそのHostのすべてのユーザに報告するように変更されたことをTIPに通知します。
On the other hand, the service interruption may not be proceedable and
そして他方では、停電が「続-可能」でないかもしれない。
1
1
NWG/RFC# 636 JDB BPC RST DCW3 MLK 23-OCT-75 22:27 30490 TIP/TENEX Reliability Improvements
NWG/RFC#636JDB BPC RST DCW3 MLK23 10月の75 22: 27 30490のチップ/TENEX信頼性の改良
TENEX may have to do a total system reload and restart. In this case TENEX will clear its NCP connection tables and send a Host/Host protocol reset command to all other Hosts. On receiving this reset command, the TIP will report "Host reset -- connection closed" to all users of that Host with suspended connections. The TIP user can then re-login to the TENEX or to some other Host.
TENEXはトータル・システム再ロードをして、再開しなければならないかもしれません。 この場合、TENEXは他のすべてのHostsにNCP接続テーブルをきれいにして、Host/ホストプロトコルリセットコマンドを送るでしょう。 このリセットコマンドを受け取ると、TIPは、吊した接続があるそのHostのすべてのユーザに「ホストリセット--接続は閉じた」と報告するでしょう。 そして、TIPユーザはTENEX、または、ある他のHostに再ログインできます。
Of couse, the user may not have the patience to wait for service to resume after a TENEX bughalt. Instead, he may unilaterally choose to connect to some other Host, ignoring the previously suspended connection. If TENEX is then able to proceed, its NCP will still think its connection to the TIP is good and suitable for use. Thus, we have a connection which the TIP thinks is closed and TENEX thinks is open, a phenomenon known as the "half-closed connection". An automatic procedure for cleanly completing the closing of such a connection has been specified and implemented for the TIP and TENEX.
couseでは、ユーザはサービスがTENEX bughaltの後に再開するのを待つ忍耐を持っていないかもしれません。 代わりに、以前に吊した接続を無視して、彼は、ある他のHostに接続するのを一方的に選ぶかもしれません。 次に、TENEXが続くことができると、それでも、NCPは、TIPとの接続が使用に良くて、適していると思うでしょう。 したがって、私たちには、接続があります(TIPが、思う閉じられて、開くTENEXが、思うことです)、「半開きな接続」として知られている現象。 清潔にそのような接続の閉鎖を完成するための自動手順は、TIPとTENEXのために指定されて、実行されました。
Since TENEX will maintain connections across service interruptions, the TIP user will be required to take the security procedure telling the TIP to "forget" his suspended connection before abandoning his terminal. The command @H 0 (for example) will guarantee that his connection will not be reestablished on resumpption of service. Otherwise, his job would be left at the mercy of anyone who acquires that terminal.
TENEXが停電の向こう側に接続を維持するので、TIPユーザは彼の端末を捨てる前に彼の吊した接続を「忘れる」ようにTIPに言うセキュリティ手順を取らなければならないでしょう。 コマンド@H0(例えば)は、彼の接続がサービスのresumpptionで回復しないのを保証するでしょう。 さもなければ、仕事はその端末を入手するだれもの思うままにやめられるでしょう。
An appendix follows which describes the Host/Host protocol changes made. These changes are backward compatible (with the exception that Hosts which have not implemented these changes will sometimes receive unrecognizable Host/Host protocol commands which they presumably discard without suffering harm). These protocol changes are ad hoc in nature but in light of their backward compatibility and potential utility, ARPA okayed their addition to the TIP and TENEX NCPs without (we believe) any implication that other Hosts have to implement them (although we would encourage their widespread implementation).
付録は従います(変化が作ったHost/ホストプロトコルについて説明します)。 これらの変化は互換性があった状態で(例外で、これらの変化を実行していないそのHostsが時々おそらく、それらが苦しみ害なしで捨てる認知できないHost/ホストプロトコルコマンドを受け取るでしょう)後方です。 これらのプロトコル変化は現実に臨時ですが、それらの後方の互換性と潜在的ユーティリティの観点から、ARPAは他のHostsが彼らを実行しなければならないという(私たちが彼らの広範囲の実現を奨励するでしょうが)少しも(私たちは信じています)含意なしでTIPとTENEX NCPへの彼らの追加を承認しました。
2
2
NWG/RFC# 636 JDB BPC RST DCW3 MLK 23-OCT-75 22:27 30490 TIP/TENEX Reliability Improvements
NWG/RFC#636JDB BPC RST DCW3 MLK23 10月の75 22: 27 30490のチップ/TENEX信頼性の改良
Appendix - Ad Hoc Change to Host-Host Protocol
付録--ホスト兼ホストプロトコルへの臨時の変化
A.1 Introduction
A.1序論
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 NCPs at the two ends stay "confused" forever. An
occasional 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 resynchronize 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が、接続がまだオープンであると信じるかもしれません、もう片方が、接続が閉じられると(存在していません)信じていますが。 そのような矛盾が発見されるとき、接続の「開いている」終わりは閉じられるべきです。
A.2 The RAR, RAS and RAP commands
A.2RAR、RAS、およびRAPコマンド
To achieve resynchronization of allocation, we add the following
three commands to the host-host protocol.
配分の再同期を達成するために、私たちはホスト兼ホストプロトコルに以下の3つのコマンドを追加します。
8 bits 8 bits
-------------------
! ! !
16 ! RAR ! link !
! ! !
-------------------
Reset Allocation by Receiver
8ビット8ビット------------------- ! ! ! 16! RAR!はリンクします!------------------- 受信機で配分をリセットしてください。
8 bits 8 bits
-------------------
! ! !
8ビット8ビット------------------- ! ! !
3
3
NWG/RFC# 636 JDB BPC RST DCW3 MLK 23-OCT-75 22:27 30490 TIP/TENEX Reliability Improvements
NWG/RFC#636JDB BPC RST DCW3 MLK23 10月の75 22: 27 30490のチップ/TENEX信頼性の改良
17 ! RAS ! link !
! ! !
-------------------
Reset Allocation by Sender
17!RAS!リンクしてください!------------------- 送付者によるリセット配分
8 bits 8 bits
-------------------
! ! !
20 ! RAP ! link !
! ! !
-------------------
Reset Allocation Please
8ビット8ビット------------------- ! ! ! 20! RAP!はリンクします!------------------- 配分をリセットしてください。
The RAS 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 resynch the status information associated
with the connection (and doesn't have a message in transit through
the network). Some circumstances in which the sending Host may
choose to do this are:
「リンクしてください」と転送するHostから「リンク」で受信するHostにRASコマンドを送ります。 発信しているHostが接続(そして、ネットワークを通したトランジットにおけるメッセージを持っていない)に関連している状態情報を「再-同時性」に望んでいるときはいつも、このコマンドを送るかもしれません。 発信している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のメッセージを超えた傑出している配分)と交際しました。
3) After the sending host has suffered an interruption of
network service;
3) 発信の後に、ホストはネットワーク・サービスの中断に苦しみました。
4) In response to a RAP (see below).
4) RAP(以下を見る)に対応して。
The RAR command is sent from the Host receiving on "link" to the
Host sending on "link" in response to an RAS. It marks the
completion of the connection resynchronization. When the RAR is
returned the connection is in the known state of having no
messages in transit in either direction and the allocations are
zero. The receiving Host may then start afresh with a new
allocation and normal message transmission can proceed. Since the
RAR may be sent ONLY in response to an RAS, there are no races in
the resynchronization. All of the initiative lies with the
sending Host.
「リンク」で受信するHostからRASに対応して「リンク」を転送するHostにRARコマンドを送ります。 それは接続再同期の完成をマークします。 RARを返すとき、接続がトランジットにおけるメッセージを全くどちらの方向にも持たない知られている状態にあります、そして、配分はゼロです。 次に、受信Hostは新たに新しい配分から始まるかもしれません、そして、通常のメッセージ送信は続くことができます。 RASに対応してだけRARを送るかもしれないので、人種は全く再同期にいません。 発信しているHostにはイニシアチブのすべてがあります。
If the receiving Host detects an anomalous situation, however,
there is no way to inform the sending Host that a
resynchronization is desirable. For this purpose, the RAP command
is provided. It constitutes a "suggestion" on the part of the
しかしながら、受信Hostが変則的な状況を検出するなら、再同期が望ましいことを発信しているHostに知らせる方法が全くありません。 このために、RAPコマンドを提供します。 側のそれが「提案」を構成する。
4
4
NWG/RFC# 636 JDB BPC RST DCW3 MLK 23-OCT-75 22:27 30490 TIP/TENEX Reliability Improvements
NWG/RFC#636JDB BPC RST DCW3 MLK23 10月の75 22: 27 30490のチップ/TENEX信頼性の改良
receiving Host that the sending Host resynchronize; the sending
Host is free to honor it or not as it sees fit. Since there is no
obligatory response to a RAP, the receiving Host may send them as
frequently as it chooses and no harm can occur. For example, if a
message in excess of the allocate arrives, the receiving Host
might send RAPs every few seconds until the sending Host replies
with no fears of races if one or more RAPs pass a RAS in the
network.
Hostを受ける、それ、発信しているHost resynchronize。 発信しているHostは適していると決めるように自由にそれを光栄に思うことができます。 RAPへのどうしてもしなければならない返答が全くないので、Hostが選ぶのと同じくらい頻繁にそれらを送るかもしれない受信を生じますが、どんな害も起こることができません。 例えばメッセージである、より多くの割り当て、到着する、あらゆる数秒のHostがRAPsを送るかもしれない1RAPsがネットワークでRASを通過するなら発信しているHostがレースへの恐怖なしで返答するまでの受信。
A.3 Resynchronization Procedure
A.3 Resynchronization手順
The resynchronization sequence below may be initiated only by the
sender either for internally generated reasons or upon the receipt
of a RAP.
以下の再同期系列は内部的に発生した理由かRAPの領収書で単に送付者によって開始されるかもしれません。
a) Sender - decision to resynch
a) 送付者--「再-同時性」との決定
1) Set state to "Wait-for-RAR" (Defer transmission of
message.)
2) Wait until no RFNM outstanding
3) Send RAS
4) Zero allocation
5) Ignore allocates until RAR received
6) Set state to "Open" (Resume normal message transmission
subject to flow control.)
1) 状態に「RARを待つ」ように設定してください(メッセージの伝達を延期してください。)。 2) どんな傑出しているRFNM3時までも)待たないでください。 RAS4)を送ってください。 配分5)のゼロを合わせてください。 無視、RARが6を)受け取るまで、割り当てます。 状態に「開く」ように設定してください。(フロー制御を条件として通常のメッセージ送信を再開してください。)
b) Receiver - receipt of RAS
b) 受信機--RASの領収書
1) Send RAR
2) Zero allocation
3) Send a new allocation
1) RAR2)を送ってください。 配分3)のゼロを合わせてください。 新しい配分を送ってください。
When the sender is in the "Wait-for-RAR" state it is not permitted
to send new regular messages. (Note that steps 4 and 5 will
insure this in the normal course of events.) With the return of
the RAR the pipeline contains no messages and no allocates, the
outstanding allocation variables at both ends are forced into
agreement by setting them both to zero. The receiver will then
reconsider bit and message allocation, and send an ALL command for
any allocation it cares to do.
送付者が「RARのための待ち」状態にあるとき、新しい通常のメッセージを送ることは許可されません。 (ステップ4と5が事の当然の成り行き上これを保障することに注意してください。) RARの復帰で、パイプラインはいいえをメッセージといいえが割り当てる含んでいて、両端における傑出している配分変数は、それらの両方をゼロに設定することによって、協定に強制されます。 受信機は、次に、ビットとメッセージ配分を再考して、それがするのを気にかけるどんな配分のためのすべてのコマンドも送るでしょう。
A.4 The Problem of Half-closed Connections
半開きなコネクションズのA.4問題
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.
上の手順は無くなった状態でコミュニケーションコンポーネントによる簡潔な過失の後のなる接続を再連動させる方法を提供します。オープンな接続のために通信するか、または割り当てます。
5
5
NWG/RFC# 636 JDB BPC RST DCW3 MLK 23-OCT-75 22:27 30490 TIP/TENEX Reliability Improvements
NWG/RFC#636JDB BPC RST DCW3 MLK23 10月の75 22: 27 30490のチップ/TENEX信頼性の改良
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 ater 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 socket pair or same link.
サービスであるときに、回復しているaterがそのような中断であるので、接続の2つの終わりの状態情報は同期から脱しています。 片端は、接続がオープンであると信じて、接続を使用しかけるかもしれません。 断線終わりは、接続が閉じられると(存在していません)信じて、同じソケット組か同じリンクを使用することで新しい接続(RTSかSTRコマンド)を開くことによって、コミュニケーションを再初期化しかけるかもしれません。
The resynchronization needed here is to properly close the open
end of the connection when the inconsistency is detected. We will
accomplish this by specifying consistency checks and adding a new
pair of commands.
ここで必要であった再同期は適切に、矛盾が検出される接続の開いている端を閉じることになっています。 私たちは、一貫性チェックを指定して、コマンドの新しいペアを加えることによって、これを達成するつもりです。
A.5 The NXS and NXR Commands
A.5のNXSとNXRコマンド
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 closed end should respond with
an NXS if the message referred to a non-existent transmit link
(e.g. was an ALL) or NXR if the message referred to a non-existent
receive link (e.g. a data message). On receipt of such an NXS or
NXR 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.
上で説明された「なくなったCLS」状況は2つの方法で現れることができます。 最初の道は接続の「開いている」終わりのNCPによって取られた行動を伴います。 それは、半開きな接続、またはリンクに参照をつけるコントロールメッセージのリンクに通常のメッセージを送り続けるかもしれません。 a実在しないのが参照されたメッセージがリンクを伝えるならクローズドエンドがNXSと共に応じるべきである、(例えば、すべて)、メッセージがa実在しないのを参照したなら、NXRはリンク(例えば、データメッセージ)を受けます。 そのようなNXSかNXRメッセージを受け取り次第、「開いている」終わりのNCPは、その結果、両端を協定に運び込みながらテーブル(どんなCLSコマンドも送ることのない)を変更することによって、接続を終えるべきです。
8 bits 8 bits
-------------------
! ! !
21 ! NXR ! link !
! ! !
-------------------
Non-existent Receive Link
8ビット8ビット------------------- ! ! ! 21! NXR!はリンクします!------------------- 実在しなさ、リンクを受けてください。
8 bits 8 bits
8ビット8ビット
6
6
NWG/RFC# 636 JDB BPC RST DCW3 MLK 23-OCT-75 22:27 30490 TIP/TENEX Reliability Improvements
NWG/RFC#636JDB BPC RST DCW3 MLK23 10月の75 22: 27 30490のチップ/TENEX信頼性の改良
-------------------
! ! !
22 ! NXS ! link !
! ! !
-------------------
Non-existent Send Link
------------------- ! ! ! 22!NXS!リンクしてください!------------------- 実在しなさ、リンクを送ってください。
A.6 Consistency Checks
A.6の一貫性はチェックします。
A 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 should detect the inconsistency when it
receives such an RTS or STR command, because it specifies the same
socket pair as an existing open connection, or, in the case of an
RTS, the same link. 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は矛盾を検出するべきです、既存のオープンな接続と同じソケット組、またはRTSの場合における同じリンクを指定するので。 この場合、「開いている」終わりのNCPは、RTS/STRに応じる前に2つの終わりを協定に運び込むように、接続(どんなCLSコマンドも送ることのない)を終えるべきです。
A.7 Conclusion
A.7結論
The scheme presented in Section A.2 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 resynchronization from either end at any time. When in
doubt, resynchronize.
配分を再連動させるようにセクションA.2に提示された計画は1つの非常に重要な特性を持っています: データ・ストリームは交換を通して保存されます。 どんなデータも無くならないので、いつでもどちらの終わりからも再同期を開始するのは安全です。 疑問で再連動
The consistency checks for RTS and STR, and the NXR and NXS
commands provide the synchronization needed to complete the
closing of "half-closed" connections.
一貫性はRTSとSTRがないかどうかチェックします、そして、NXRとNXSコマンドは「半開きな」接続の閉鎖を完成するのに必要である同期を提供します。
The protocol changes above
プロトコルは上で変化します。
一覧
スポンサーリンク
