RFC426 日本語訳
0426 Reconnection Protocol. R. Thomas. January 1973. (Format: TXT=26548 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Bob Thomas Request for Comments: 426 BBN-TENEX NIC: 13011 23 January 1973 Categories: Protocols, TELNET References: 36,318,333,435
コメントを求めるワーキンググループボブトーマスRequestをネットワークでつないでください: 426BBN-TENEX NIC: 13011 1973年1月23日のカテゴリ: プロトコル、telnet参照: 36,318,333,435
Reconnection Protocol
再接続プロトコル
There are situations in which it is desirable to move one or both ends of a communication path from one host to another. This note describes several situations in which the ability to reconnect is useful, presents a mechanism to achieve reconnection, sketches how the mechanism could be added to Host-Host or TELNET protocol, and recommends a place for the mechanism in the protocol hierarchy.
1人のホストから別のホストまで1つを動かすのが望ましい状況か通信路の両端があります。 この注意は、再接続する能力が役に立ついくつかの状況について説明して、再接続を達成するためにメカニズムを提示して、Host-ホストにメカニズムを加えることができたか、またはTELNETがどう議定書を作るかをスケッチして、メカニズムのためにプロトコル階層で場所を推薦します。
1. Some Examples:
1. いくつかの例:
A. Consider the case of an executive program which TIP users could use to get network status information, send messages, link to other users, etc. Due to the TIP's limited resources the executive program would probably not run on the TIP itself but rather would run on one or more larger hosts who would be willing to share some of their resources with the TIP (see Figure 1).
A。 TIPユーザが使用できた管理プログラムに関するケースがネットワーク状態情報を得ると考えてください、そして、メッセージを送ってください、そして、他のユーザなどにリンクしてください。 TIPの限りある資源のため、管理プログラムは、たぶんTIP自身の上で作業しないでしょうが、むしろ彼らのリソースのいくつかをTIPと共有しても構わないと思っている1人以上のより大きいホストで動くでしょう(図1を見てください)。
The TIP user could access the executive by typing a command such as
"@ EXEC"; the TIP would then ICP to Host1's executive port. After
obtaining the latest network news and perhaps sending a few messages,
the user would be ready to log into Host2 (in general not the same as
Host1) and do some work. At that point he would like to tell the
executive program that he is ready to use Host2 and have executive
hand him off to Host2. To do this the executive program would first
interact with Host2, telling it to expect a call from TIP, and then
would instruct the TIP to reconnect to Host2. When the user logs off
Host2 he could be passed back to the executive at Host1 prepatory to
doing more work elsewhere. The reconnection activity would be
invisible to the TIP user.
Reconnection
______ | ______
| | | | |
| EXEC |<-------------+------------>| USER |
|______| | / |______|
Host1 V / TIP
______ /
| |<------/
|______|
Host2
Figure 1
「」 @幹部などのコマンドをタイプすることによって、TIPユーザは幹部社員にアクセスできるでしょう」。 TIPは次に、Host1の幹部社員ポートへのICPがそうするでしょう。 そして、最新のネットニュースを得て、恐らくいくつかのメッセージを送った後にユーザがHost2にログインする準備ができているだろう、(一般に、Host1と同じくらいでない)、いくらかの仕事をしてください。 その時、彼は、幹部社員にHost2を使用して、彼をHost2に渡させる準備ができていると管理プログラムに言いたがっています。 管理プログラムは、これをするために、TIPから呼び出しを予想するようにそれに言って、最初にHost2と対話して、次に、Host2に再接続するようTIPに命令するでしょう。 ユーザがHost2からログオフするとき、ほかの場所で、より多くの仕事をすることへのHost1 prepatoryの幹部社員に彼を戻すことができました。 TIPユーザにとって、再接続活動は目に見えないでしょう。 再接続______ | ______ | | | | | | 幹部| <、-、-、-、-、-、-、-、-、-、-、-、--+------------>| ユーザ| |______| | / |______| Host1V/チップ______ / | | <、-、-、-、-、--/ |______| Host2数値1
Thomas [Page 1] RFC 426 Reconnection Protocol January 1973
トーマス[1ページ]RFC426再接続プロトコル1973年1月
B. Imagine a scenario in which a user could use the same name and password (and perhaps account) to log into any server on the network. For reasons of security and economy it would be undesirable to have every name and password stored at every site. A user wanting to use a Host that doesn't have his name or password locally would connect to it and attempt to log in as usual (See Figure 2). The Host, discovering that it doesn't know the user, would hand him off to a network authentication service which can determine whether the user is who he claims to be. If the user passes the authentication test he can be handed back to Host which can then provide him service. The idea is that the shuffling of the user back and forth between Host and Authenticator should invisible to the user.
B。 ユーザが同じ名前とパスワード(恐らく説明する)を使用できたシナリオがネットワークのどんなサーバにもログインすると想像してください。 セキュリティと経済の理由で、あらゆるサイトにあらゆる名前とパスワードを格納させるのは、望ましくないでしょう。 局所的に彼の名前かパスワードを持っていないHostを使用したがっているユーザは、それに接続して、いつものようにログインするのを試みるでしょう(図2を見てください)。 それがユーザを知らないと発見して、Hostはユーザが彼が主張する人であるかどうか決定できるネットワーク認証サービスに彼を渡すでしょう。 ユーザが認証テストに合格するなら、次にサービスを彼に提供できるHostに彼を返すことができます。 HostとAuthenticatorの間で前後にユーザにシャッフルするのは目に見えなくあるべきです。考えがそれである、ユーザにとって、目に見えません。
(a) ______ for authentication ______
| | | | |
| |<-----------+------------->| User |
|______| | / |______|
Host |/
X
/|
_______ / |
| | / v
| |<---
|_______|
Authenticator
(a)______ 認証のために______ | | | | | | | <、-、-、-、-、-、-、-、-、-、--+------------->| ユーザ| |______| | / |______| ホスト|/X/| _______ / | | | /v| | <、-、-- |_______| 固有識別文字
(b)
______ ______
| | | |
| |<--\ ^ /-->| User |
|______| \ | / |______|
Host \ | /
------------+--/
| /
|/
|
/|
/ |
/ | authentication
_______ / | complete
| | /
| |<------
|_______|
Authenticator
(b)______ ______ | | | | | | <--\ ^ /-->| ユーザ| |______| \ | / |______| ホスト\| / ------------+--/ | / |/ | /| / | / | 認証_______ / | 完全| | / | | <、-、-、-、-、-- |_______| 固有識別文字
Figure 2
図2
Thomas [Page 2] RFC 426 Reconnection Protocol January 1973
トーマス[2ページ]RFC426再接続プロトコル1973年1月
If the user doesn't trust the Host and is afraid that it might read his password rather than pass him off to the authenticator he could connect directly to the authentication service. After authentication, the Authenticator can pass him off to the Host.
ユーザが固有識別文字に彼をそらすよりむしろHostを信じないで、彼のパスワードを読むかもしれないのを恐れているなら、彼は直接認証サービスに接続するかもしれません。 認証の後に、AuthenticatorはHostに彼をそらすことができます。
C. The McROSS air traffic simulation system (see 1972 SJCC paper) already supports reconnection. It permits an on-going simulation to reconfigure itself by allowing parts to move from computer to computer. For example, in a simulation of air traffic in the Northeast the program fragment simulating the New York Enroute air space could move from Host2 to Host5 (see Figure 3). As part of the reconfiguration process the New York Terminal area simulator and Boston Enroute area simulators break their connections with New York Enroute simulator at Host2 and reconnect to it at Host5.
C。 McROSS航空交通シミュレーション・システム(1972年のSJCC紙を見る)は既に再接続を支持します。 それは、部品がコンピュータからコンピュータまで動くのを許容することによって継続しているシミュレーションがそれ自体を再構成することを許可します。 例えば、東北における、航空交通のシミュレーションで、ニューヨークEnrouteエアスペースをシミュレートするプログラム断片はHost2からHost5まで動くことができるでしょう(図3を見てください)。 再構成の過程の一部として、ニューヨークTerminal領域シミュレータとボストンEnroute領域シミュレータは、Host2でニューヨークEnrouteシミュレータとの彼らの接続を調教して、Host5でそれに再接続されます。
NY Terminal NY Enroute Boston Enroute Boston Terminal
_____ _____ _____ _____
| | / | | \ | | | |
|Host1|<----/--->|Host2|<---\---->|Host3|<----->|Host4|
|_____| \ / |_____| \ / |_____| |_____|
X move X
/ \ | / \
| \ V / |
V \ _____ / V
reconnect \ | | / reconnect
->|Host5|<-
|_____|
NY Enroute
途中ニューヨークの端末のニューヨーク、途中ボストン、ボストン端末_____ _____ _____ _____ | | / | | \ | | | | |Host1| <、-、-、--/--->|Host2| <、-、--\---->|Host3| <、-、-、-、--、>|Host4| |_____| \ / |_____| \ / |_____| |_____| X移動X/\| / \ | \対/| V\_____ /Vは\を再接続します。| | /が再接続される、->|Host5| <、- |_____| 途中ニューヨーク
Figure 3
2. A Reconnection Mechanism
図3 2。 再接続メカニズム
The mechanism proposed here could be added to the existing Host-Host protocol or to the TELNET protocol. The mechanism is first described and then its adaptation to each of the protocols is discussed.
既存のHost-ホストプロトコル、または、TELNETプロトコルにここで提案されたメカニズムは追加できました。 メカニズムは最初に説明されます、そして、次に、それぞれのプロトコルへの適合について議論します。
The reconnection mechanism includes four commands:
再接続メカニズムは4つのコマンドを含んでいます:
Reconnect Request: RRQ <path>
Reconnect OK: ROK <path>
Reconnect No: RNO <path>
Reconnect Do: RDO <path> <new destination>
要求を再接続してください: RRQ<経路>はOKを再接続します: ROK<経路>はいいえを再接続します: <経路>が再接続するRNOは以下をします。 RDOの<の経路の>の<の新しい目的地>。
where <path> is the communication path to be redirected to <new destination>.
<経路>が<の新しい目的地>に向け直されるべき通信路であるところ。
Assume that H1 wants to move its end of communication path A-C from itself to port D at H3 (See figure 4).
そのH1が端を動かしたがっていると仮定してください、通信路、A-C、それ自体からH3(4が計算するのがわかる)のポートDまで。
Thomas [Page 3] RFC 426 Reconnection Protocol January 1973
トーマス[3ページ]RFC426再接続プロトコル1973年1月
(a) situation (b) desired situation
(a) (b)の必要な状況状況
H2 H3 H2 H3
___ ___ ___ ___
| | | | | | | |
| C|<-+ |D | | C|<------>|D |
|___| | |___| |___| |___|
|
|
| ___ ___
| | | | |
+->|A | |A |
|___| |___|
H1 H1
H2 H3 H2 H3___ ___ ___ ___ | | | | | | | | | C| <、-+ |D| | C| <、-、-、-、-、--、>|D| |___| | |___| |___| |___| | | | ___ ___ | | | | | +->|A| |A| |___| |___| H1 H1
Figure 4
図4
The reconnection proceeds by steps:
再接続は以下のステップで続きます:
a. H1 arranges for the reconnection by sending RRQ to
H2:
H1->H2: RRQ (path A-C)
a。 H1はRRQをH2に送ることによって、再接続を準備します: H1、-、>H2: RRQ(経路、A-C)
b. H2 agrees to reconnect and acknowledges with ROK:
b。 H2は再接続するのに同意して、ROKと共に以下を認めます。
H2->H1: ROK (path C-A)
H2、-、>H1: ミヤマガラス(経路、C-a)
c. H1 notes that H2 has agreed to reconnect and
instructs H2 to perform the reconnection:
c。 H1は、H2が、再接続するのに同意したことに注意して、再接続を実行するようH2に命令します:
H1->H2: RDO (path A-C) (Host H3, Port D)
H1、-、>H2: RDO、(経路、A-C)(ホストH3、ポートD)
d. H1 breaks paths A-C.
H2 breaks path C-A and initiates path C-D.
d。 H1は経路A-Cを破ります。 H2が経路を壊す、C-Aと開始道、C-D。
In order for the reconnection to succeed H1 must, of course, have arranged for H3's cooperation. One way H1 could do this would be to establish the path B-D and then proceed through the reconnection protocol exchange with H3 concurrently with its exchange with H2 (See Figure 5):
再接続が成功する命令では、H1はもちろんH3の協力を準備したに違いありません。 H1がこれができた1つの方法が、同時にH2との交換で経路B-Dを設立して、次に、H3との再接続プロトコル交換を通して続くことになっているでしょう(図5を見てください):
H1->H3: RRQ (path B-D)
H3->H1: ROK (path D-B)
H1->H3: RDO (path B-D) (Host H2, Port C)
H1、-、>H3: RRQ(経路B-D)H3->H1: ROK(経路D-B)H1->H3: RDO(経路B-D)(ホストH2、ポートC)
Thomas [Page 4] RFC 426 Reconnection Protocol January 1973
トーマス[4ページ]RFC426再接続プロトコル1973年1月
H2 H3
______ ______
| | | |
| C | | D |
---\-- -/----
\ /--> <--\ /
\- -/--- --- --- --- --- \---/
\ / \ /
X X
/ \ / \
/ \ / \
reconnection \ / reconnection
\ ________ /
---|A B|---
| |
|________|
H1
H2 H3______ ______ | | | | | C| | D| ---\-- -/---- \/--><--\/\/--- --- --- --- --- \---/\/\/X X/\/\/\/\再接続\/再接続\________ / ---|B|--- | | |________| H1
Figure 5
図5
Either of the parties may use the RNO command to refuse or abort the reconnection. H2 could respond to H1's RRQ with RNO; H1 can abort the reconnection by responding to ROK with RNO rather than RDO.
パーティーのどちらかが再接続を拒否するか、または中止するRNOコマンドを使用するかもしれません。 H2はRNOと共にH1のRRQに応じることができました。 H1は、RDOよりむしろRNOと共にROKに応じることによって、再接続を中止できます。
It is easy to insure that messages in transit are not lost during the reconnection. Receipt of the ROK message by H1 is taken to mean that no further messages are coming from H2; similarly receipt of RDO from H1 by H2 is taken to mean that no further messages are coming from H1.
トランジットにおけるメッセージが再接続の間失われていないのを保障するのは簡単です。 さらなるメッセージが全くH2から来ないことを意味するためにH1によるROKメッセージの領収書を取ります。 同様に、さらなるメッセージが全くH1から来ないことを意味するためにH2によるH1からのRDOの領収書を取ります。
To complete the specification of the reconnection mechanism consider the situation in which two "adjacent" entities initiate reconnections:
再接続メカニズムの仕様を完成するには、2つの「隣接している」実体が再接続を開始する状況を考えてください:
(a) situation (b) desired situation
(a) (b)の必要な状況状況
H1 H4 H1 H4
____ ____ ____ ____
| | | | | | | |
| C| |E | | C|--------|E |
|____| |____| |____| |____|
H1 H4 H1 H4____ ____ ____ ____ | | | | | | | | | C| |E| | C|--------|E| |____| |____| |____| |____|
H2 H3 H2 H3
____ ____ ____ ____
| | | | | | | |
| B|--------|D | | B| |D |
|____| |____| |____| |____|
H2 H3 H2 H3____ ____ ____ ____ | | | | | | | | | B|--------|D| | B| |D| |____| |____| |____| |____|
Thomas [Page 5] RFC 426 Reconnection Protocol January 1973
トーマス[5ページ]RFC426再接続プロトコル1973年1月
H2 and H3 "simultaneously" try to arrange for reconnection:
H2とH3は「同時、」再接続を準備しようとします:
H2->H3: RRQ (path B-D)
H3->H2: RRQ (path D-B)
H2、-、>H3: RRQ(経路B-D)H3->H2: RRQ(経路D-B)
Thus, H2 sees an RRQ from H3 rather than an ROK or RNO in response to its RRQ to H3. This "race" situation can be resolved by having the reconnections proceed in series rather than in parallel: first one entity (say H2) performs its reconnect and then the other (H3) performs its reconnect. There are several means that could be used to decide which gets to go first. Perhaps the simplest is to base the decision on sockets and site addresses: the entity for which the 40 bit number formed by concatenating the 32 bit socket number with the 8 bit site address is largest gets to go first. Using this mechanism the rule is the following:
したがって、H2はRRQに対応したROKかRNOよりむしろH3からH3にRRQを見ます。 再接続を平行であるというよりむしろ連続的に続かせることによって、この「レース」状況を決議できます: 最初に、1つの実体(H2を言う)が働く、それ、再接続してください。そうすれば、次に、もう片方の(H3)が働く、それ、再接続してください。 どれが、最初に行き始めるかを決めるのに使用できたいくつかの手段があります。 恐らく最も簡単であるのは、決定をソケットとサイトアドレスに基礎づけることです: 8ビットのサイトアドレスで32ビットのソケット番号を連結することによって形成される中で40ビットの数が最も大きい実体は、最初に行き始めます。 このメカニズムを使用して、規則は以下です:
If H2 receives an RRQ from H3 in response to an RRQ of its own:
(let NH2,NH3 = the 40 bit numbers corresponding to H2 and H[2])
H2がそれ自身のRRQに対応してH3からRRQを受けるなら: (H2とH[2])に対応する40ビットのNH2、NH3=数をさせてください。
a. if NH2>NH3 then both H2 and H3 interpret H3's RRQ as an ROK in
response to H2's RRQ.
a. そしてNH3のNH2>両方であるなら、H2とH3はROKとしてH2のRRQに対応してH3のRRQを解釈します。
b. if NH2<NH3 then both interpret H3's RRQ as an RNO in response
to H2's RRQ. This would be the only case in which it makes
sense to "ignore" the refusal and try again - of course,
waiting until completion of the first reconnect before doing
so.
b. NH2<NH3であるなら、両方がRNOとしてH2のRRQに対応してH3のRRQを解釈します。 これはそれが拒否を「無視し」て、再試行する意味になる唯一のそうでしょう--もちろん、1つの番目ものの完成まで待って、そうする前に、再接続してください。
Once an ordering has been determined the reconnection proceeds as though there was no conflict.
かつて、注文はまるで闘争が全くないかのように再接続が続くことを決定しています。
The following diagram describes the legal protocol command/response exchange sequences for a reconnection initiated by P:
以下のダイヤグラムはPによって開始された再接続のために法的なプロトコルコマンド/応答交換系列について説明します:
Thomas [Page 6] RFC 426 Reconnection Protocol January 1973
トーマス[6ページ]RFC426再接続プロトコル1973年1月
___ ___
| P |---------------| Q |
|___| |___|
____________________
| P --> Q || R R Q |
|_________||_________|
|
+---------+
|
____V_______________________________________
| || | | |
| Q --> P || R O K | R N O ----| R R Q |
| || | | E | |
|_________||_________|_________|___|_________|
| |
+------------+ v
| Yes +----------+ No
| +------------------------| NP > NQ? |------+
| | +----------+ |
__v___v_______________________________ |
| || | | |
| P --> Q || R D O ----| R N O ----| |
| || | E | | E | |
|_________||_________|___|_________|___| |
|
+--------------------------------------------+
|
____v_________________________________
| || | |
| Q --> P || R D O ----| R N O ----|
| || | E | | E |
|_________||_________|___|_________|___|
___ ___ | P|---------------| Q| |___| |___| ____________________ | P-->Q|| R R Q| |_________||_________| | +---------+ | ____V_______________________________________ | || | | | | Q-->P|| R O K| R N O----| R R Q| | || | | E| | |_________||_________|_________|___|_________| | | +------------+ v| はい+----------+ いいえ| +------------------------| Np>NQ? |------+ | | +----------+ | __v___v_______________________________ | | || | | | | P-->Q|| R D O----| R N O----| | | || | E| | E| | |_________||_________|___|_________|___| | | +--------------------------------------------+ | ____v_________________________________ | || | | | Q-->P|| R D O----| R N O----| | || | E| | E| |_________||_________|___|_________|___|
NP and NQ are the 40 bit numbers for P and Q; E indicates end of sequence.
NPとNQはPとQの40ビットの数です。 Eは系列の終わりを示します。
3. Adding the Reconnection Mechanism to Host-Host Protocol
3. ホスト兼ホストプロトコルに再接続メカニズムを追加します。
The four reconnect commands could be included directly in
Host-Host protocol as follows:
直接以下のHost-ホストプロトコルに4つの再接続コマンドを含むことができました:
RRQ <my socket> <your socket>
ROK <my socket> <your socket>
RNO <my socket> <your socket>
RDO <my socket> <your socket> <new host> <new socket>
RRQ<、私のソケット><、あなたのソケット>ROK<、私のソケット><、あなたのソケット>RNO<、私のソケット><、あなたのソケット>RDO<、私のソケット><、あなたのソケットの>の<の新しいホスト>の<の新しいソケット>。
The ROK and RDO commands for a send connection should not be sent until there are no messages in transit over the connection. The RDO
接続の上のトランジットにはメッセージが全くないまで、aのためのコマンドが接続に送るROKとRDOを送るべきではありません。 RDO
Thomas [Page 7] RFC 426 Reconnection Protocol January 1973
トーマス[7ページ]RFC426再接続プロトコル1973年1月
command is to be interpreted as a CLS.
コマンドはCLSとして解釈されることです。
The reconnection:
再接続:
H2 H3 H2 H3
___ ___ ___ ___
| | | | | C|--------|D |
|_C_| |_D_| |___| |___|
| |
| | ===>
| ____ | ____
---|A B|--- | |
|____| |____|
H1 H1
H2 H3 H2 H3___ ___ ___ ___ | | | | | C|--------|D| |_C_| |_D_| |___| |___| | | | | ===>|____ | ____ ---|B|--- | | |____| |____| H1 H1
could be accomplished as follows:
以下の通り達成できました:
H1->H2: RRQ A C
H1->H3: RRQ B D
H2->H1: ROK C A
H3->H1: ROK D B
H1->H2: RDO A C H3 D
H1->H3: RDO B D H2 C
H2->H1: CLS C A
H3->H1: CLS D B
H2->H3: STR C D size
H3->H2: RTS D C link
H1、-、>H2: RRQ A C H1->、H3: RRQ B D H2->、H1: ミヤマガラスC A H3->、H1: ミヤマガラスD B H1->、H2: RDO A C H3D H1->、H3: RDO B D H2C H2->、H1: CLS C A H3->、H1: CLS D B H2->、H3: STR C DサイズH3->、H2: RTS D Cリンク
Note that it is possible for the STR from H2 to arrive at H3 before the RDO from H1. H3 must be prepared to queue such an RFC until it gets an RDO or RNO from H1. Stated differently, transmission of an ROK for a local socket causes the socket to move from an "open" state to a "reconnect pending" state and indicates willingness to queue subsequent RFC's until receipt of a "matching" RDO or RNO.
H2からのSTRがH1からRDOの前のH3に到着するのが、可能であることに注意してください。 H1からRDOかRNOを手に入れるまでそのようなRFCを列に並ばせるようにH3を準備しなければなりません。 地方のソケットのためのROKのトランスミッションが「開いている」状態から「未定の状態で、再接続してください」状態までソケットを異なって、動かすと述べて、「合わせている」RDOかRNOの領収書までその後のRFCのものを列に並ばせる意欲を示します。
4. Reconnection in TELNET Protocol
4. telnetプロトコルにおける再接続
Independently of whether Host-Host protocol directly supports reconnection, the reconnection mechanism could be included in TELNET with the addition to the TELNET protocol of the five commands:
Host-ホストプロトコルが直接再接続を支持するかどうかの如何にかかわらず、TELNETに5つのコマンドのTELNETプロトコルへの追加で再接続メカニズムを含むことができました:
RRQ
ROK
RNO
RDO <host> <socket>
RWT <host> <socket>
RRQ ROK RNO RDO<ホスト><ソケット>RWT<ホスト><ソケット>。
Thomas [Page 8] RFC 426 Reconnection Protocol January 1973
トーマス[8ページ]RFC426再接続プロトコル1973年1月
where RRQ, ROK, RNO, RDO, and RWT are appropriately chosen characters in the range 128 to 255. The first three commands require no parameters since they refer to the connections they are received on. For RDO and RWT, <host> is an 8 bit (= 1 TELNET character) host address and <socket> is a 32 bit (= 4 TELNET characters) number that specifies a TELNET receive socket at the specified host.
範囲のRRQ、ROK、RNO、RDO、およびRWTが適切に128〜255にキャラクタに選ばれているところ。 彼らが受け取られる接続について言及するので、最初の3つのコマンドはパラメタを全く必要としません。 RDOとRWTに関しては、<ホスト>は8ビット(1つのTELNETキャラクタと等しい)のホスト・アドレスであり、<ソケット>によるTELNETを指定する32ビット(4つのTELNETキャラクタと等しい)の数が指定されたホストでソケットを受けるということです。
A pending reconnection can be activated with either RDO or RWT. The response to either is to first break the TELNET connection with the sender and then reopen the TELNET connection to the host and sockets specified. For RDO, the connection is to be reopened by sending two RFC's; for RWT, by waiting for two RFC's.
RDOかRWTのどちらかと共に未定の再接続を起動できます。 どちらかへの応答が最初に、送付者と共にTELNET接続を調教して、次に、TELNET接続をホストに再開させることであり、ソケットは指定しました。 RDOに関しては、接続は2RFCを送ることによって、再開することになっています。 2RFCを待つのによるRWTのために。
The RWT command is introduced to avoid races such as the one between the STR and CLS (RDO) discussed above. In Host-Host protocol the race is avoided by putting a connection into "reconnect pending" state upon transmission of ROK. For TELNET the race can be avoided by the initiator of the reconnection by judicious use of RWT and RDO. For example the reconnection:
RWTコマンドは、上で議論したSTRとCLS(RDO)の間のものなどのレースを避けるために紹介されます。 Host-ホストプロトコルでは、レースは、ROKのトランスミッションの「未定の状態で、再接続してください」状態に接続を入れることによって、避けられます。 TELNETに関しては、再接続の創始者はRWTとRDOの賢明な使用でレースを避けることができます。 例えば、再接続:
H2 H3 H2 H3
+---+ +---+ +---+ M +---+
| |----+ +---->| | | |------->| |
| Y | N | | Q | Z | ==> | Y | N | Z |
| |<-+ | H1 | +---| | | |<-------| |
+---+ | | M +---+ P | | +---+ +---+ +---+
| +--->| |----+ |
| | X | | H1
+------| |<-----+ +---+
+---+ | |
H1 | X |
| |
+---+
could be accomplished as follows:
H2 H3 H2 H3+---+ +---+ +---+ M+---+ | |----+ +---->|、|、| |、-、-、-、-、-、--、>|、|、| Y| N| | Q| Z| ==>| Y| N| Z| | | <、-+ | H1| +---| | | | <、-、-、-、-、-、--、|、| +---+ | | M+---+ P| | +---+ +---+ +---+ | +--->| |----+ | | | X| | H1+------| | <、-、-、-、--+ +---+ +---+ | | H1| X| | | +---以下の通り+によって達成されるかもしれません:
X->Y: RRQ
X->Z: RRQ
Y->X: ROK
Z->X: ROK
X->Y: RWT H3 P
X closes connections to Y
Y closes connections to X
Y waits for STR and RTS from H3
X->Z: RDO H2 N
X closes connections to Z
Z closes connections to X
Z sends STR and RTS to H2 which Y answers with
matching RTS and STR to complete reconnection
X>Y: RRQ X>Z: RRQ Y>X: ミヤマガラスZ>X: ミヤマガラスX>Y: RWT H3P XはSTRとRTSのために接続をH3X>ZからX Yとの接続が待つY Y閉鎖に終えます: RDO H2N XはX Zとの接続がSTRを送るZ Z閉鎖との接続とYが再接続を終了するために合っているRTSとSTRと共に答えるH2へのRTSを終えます。
Thomas [Page 9] RFC 426 Reconnection Protocol January 1973
トーマス[9ページ]RFC426再接続プロトコル1973年1月
The reconnection mechanism for TELNET can be made to fit nicely into the command format suggested by Cosell and Walden in RFC #435. Consider the addition of three new commands to TELNET:
TELNETのための再接続メカニズムはRFC#435でコーセルとウォルデンによって提案されたコマンド形式にしっくり合わされることができます。 3つの新しいコマンドのTELNETへの添加を考えてください:
Prepare for Reconnect: RCP
Begin Reconnect by sending RFC's: RCS
Begin Reconnect by waiting for RFC's: RCW
用意、再接続します: RFCを送るのによるRCP Begin Reconnect: RFCを待つのによるRCS Begin Reconnect: RCW
Using these three command and the DO, DON'T, WILL, WON'T commands of RFC #435, the commands proposed earlier become:
そして、これらを使用して、3が命令する、してください、ウィル、RFC#435のコマンドであり、より早く提案されたコマンドはなります:であるだろう
RRQ => DO RCP
ROK => WILL RCP
RNO => WON'T RCP ;for responses to DO RCP
DON'T RCP ;for responses to WILL RCP
;i.e. used to cancel an RCP.
RDO <host> <socket> => DO RCS <host> <socket>
RWT <host> <socket> => DO RCW <host> <socket>
>>RRQ=DO RCP ROK=WILL RCP RNOはDO RCP DON'T RCPへの応答、WILL RCPへの応答のために>WON'T RCPと等しいです; すなわち、以前はよくRCPを取り消していました。 RDO<ホスト><ソケット>=>は>がRCW<ホスト><ソケット>をするRCS<ホスト><ソケット>RWT<ホスト><ソケット>=をします。
As RFC #435 notes the nice thing about this structure is that a host choosing not to implement reconnection does not even have to know what RCP means. All that it need do in response to DO RCP is to transmit WON'T RCP.
RFC#435が注意するように、この構造の周りの良いものは再接続を実行しないのを選ぶホストがRCPが言っていることがわかる必要さえないということです。 それがDO RCPに対応してしなければならないすべてはWON'T RCPを伝えることです。
5. Recommendation
5. 推薦
I feel that reconnection is a basic notion and that its proper place within the protocol hierarchy is at the Host-Host level where it would be available for use in all higher level protocols. The difficulty is that placing it there would, of course, require NCP rewrites. Reluctance to make NCP modifications would probably be sufficient to kill interest in the proposal.
私は再接続が基本的な概念であり、プロトコル階層の中の適所がそれがすべての、より高い平らなプロトコルにおける使用のように入手できるところにHost-ホストレベルにあると感じます。 困難はそれをそこに置くのがもちろんNCP書き直しを必要とするだろうということです。 NCP変更をするという不本意は、提案への関心を抑えるためにたぶん十分でしょう。
Therefore, for pragmatic reasons, I recommend that the reconnection mechanism be included in TELNET as an "option" in the spirit of RFC #435. This can be accomplished with the addition to the TELNET protocol of the RCP, RCS, RCW commands as described in Section 4. Modification of user- and server-TELNET programs to handle these new commands should be straightforward. If a reconnection option is made part of TELNET protocol the TENEX hosts will support it. In addition, the TIP guys (Walden and Cosell) have said that they like the reconnection mechanism and have agreed, in principle, to implement it for TIPs if it is accepted as part of TELNET protocol.
したがって、実践的な理由で、私は、再接続メカニズムが「オプション」としてTELNETにRFC#435の精神で含まれることを勧めます。 RCPのTELNETプロトコルへの追加でこれを達成できます、RCS、セクション4で説明されるRCWコマンド。 これらの新しいコマンドを扱うユーザとサーバ-TELNETプログラムの変更は簡単であるべきです。 再接続オプションがTELNETプロトコルの人工部分であるなら、TENEXホストはそれを支持するでしょう。 さらに、それがTELNETプロトコルの一部として認められるなら、TIP奴(ウォルデンとコーセル)は、彼らが再接続メカニズムが好きであると言って、TIPsのためにそれを実行するのに原則的に同意しました。
Thomas [Page 10] RFC 426 Reconnection Protocol January 1973
トーマス[10ページ]RFC426再接続プロトコル1973年1月
Addition of reconnection at the TELNET level rather than the Host- Host level is admittedly a compromise. However, with it, activity of the sort described in Examples A and B of Section 1 will be possible.
HostホストレベルよりむしろTELNETレベルにおける再接続の添加は明白に妥協です。 しかしながら、それでは、セクション1のExamples AとBで説明された種類の活動は可能になるでしょう。
6. Additional Remarks
6. 付記
A. Reconnection is not a new notion. An early proposal for Host-Host protocol (RFC #36) included facilities to support reconnection. The reconnection mechanism in RFC #36 supposes a configuration in which entities are "daisy-chained" together by connections:
A。 再接続は新しい概念ではありません。 Host-ホストプロトコル(RFC#36)のための早めの提案は、再接続を支持するために施設を含んでいました。 RFC#36における再接続メカニズムは、実体が一緒に「ひな菊でチェーニングされている」構成であると接続で思います:
__ __ __ __ __
___| |____| |____| |____| |____| |___
|__| |__| |__| |__| |__|
__ __ __ __ __ ___| |____| |____| |____| |____| |___ |__| |__| |__| |__| |__|
and specifies how one or more entities can break out of the chain. As suggested above (Figure 5) the mechanism proposed in this note supports that kind of reconnection.
そして、1つ以上の実体がどうチェーンから抜け出すことができるかを指定します。 (図5)を超えて示されるように、この注意で提案されたメカニズムはその種類の再接続を支持します。
B. In practice one would expect simultaneous initiation of reconnects by adjacent entities to be relatively rare.
B。 中と、ものが同時の開始を予想する習慣は、比較的まれになるように隣接している実体によって再接続されます。
C. The approach taken in RFC #36 to handle simultaneous reconnection attempts by entities adjacent in the chain is to accomplish the reconnect as a single, carefully coordinated, global reconnect. I feel that the sequence of locally coordinated reconnects as proposed above is preferable. When N adjacent entities simultaneously attempt reconnection the single, globally coordinated reconnect as outlined in RFC #36 requires ~N^2 control messages whereas the sequential locally coordinated reconnect requires ~N.
C。 ハンドルの同時の再接続への中に入れているRFC#36、がチェーンで隣接している実体で試みるアプローチはシングルとして再接続して、慎重に調整されていて、グローバルを達成するのに再接続されるということです。 私は、提案された上が望ましいので局所的に調整されていることの系列が再接続されると感じます。 ~36が必要とするRFC#に概説されていて、N^2つのコントロールメッセージにもかかわらず、局所的に調整された連続するのが再接続されるときN隣接している実体が同時にいつ単一で、グローバルに連携が再接続する再接続を試みるかが~、をN必要とします。
D. A word about security is in order. It should be clear that the decision to accept or reject a particular reconnection request is the responsibility of the entity (person at a terminal or process) using the connection. In many cases the entity may choose to delegate that responsibility to its NCP or TELNET (e.g., Example A, Section 1). However, the interface a Host provides to the reconnection mechanism should include means for local entities to exercise control over response to remotely initiated reconnection requests. For example, a user-TELNET might support several modes of operation with respect to remotely initiated reconnections:
D。 セキュリティに関する単語は整然としています。 特定の再接続要求を受け入れるか、または拒絶するという決定が実体(端末か過程における人)が接続を使用する責任であることは明確であるはずです。 多くの場合、実体は、そのNCPかTELNET(例えば、Example A、セクション1)へその責任を代表として派遣するのを選ぶかもしれません。 しかしながら、Hostが再接続メカニズムに供給するインタフェースはローカル要素が離れて開始している再接続要求への応答にコントロールを及ぼす手段を含むべきです。 例えば、ユーザ-TELNETは離れて開始している再接続に関していくつかの運転モードを支持するかもしれません:
1. transparent: all requested reconnections are to be performed in a
way that is invisible to the user;
1. 透明: すべてが、再接続がユーザにとって、目に見えない方法で実行されることであるよう要求しました。
2. visible: all requested reconnections are to be performed and the
user is to be informed whenever a reconnection occurs;
2. 目に見える: すべてが、再接続が実行されることであるよう要求しました、そして、再接続が起こるときはいつも、ユーザは知識があることになっています。
Thomas [Page 11] RFC 426 Reconnection Protocol January 1973
トーマス[11ページ]RFC426再接続プロトコル1973年1月
3. confirmation: the user is to be informed of each reconnection
request which he may accept or reject;
3. 確認: ユーザは受け入れるか、または拒絶するかもしれないそれぞれの再接続要求において知識があることになっています。
4. rejection: all requested reconnects are to be rejected.
4. 拒絶: 要求されたすべてが再接続されます。拒絶されることになっています。
E. Reconnection can be achieved almost trivially within the Message Switched Protocol (MSP) proposed by Bressler, Murphy and Walden in RFC #333 (within MSP, "reconnection" is probably not the correct term). For example use of the following conventions with that MSP (expressed in the terminology of RFC #333) support reconnection:
E。 RFC#333でBressler、マーフィー、およびウォルデンによって提案されたMessage Switchedプロトコル(MSP)の中で再接続をほぼ些細なことに達成できます(「再接続」はたぶんMSPの中では、正しい用語ではありません)。 例えば、そのMSP(RFC#333の用語で、言い表される)サポート再接続がある以下のコンベンションの使用:
1. unless a reconnection is in progress, rendezvous is to occur at
the sending site;
1.再接続が進行していない場合、ランデブーは送付サイトに起こることになっています。
2. the receiving end of a communication path can be moved by passing
the names of the rendezvous site and the ports to the new
receiver;
2. ランデブーサイトとポートの名前を新しい受信機に通過することによって、通信路の犠牲者を動かすことができます。
3. receipt of an OUT message for which the source site differs from
the rendezvous site signals that the sending end is being moved;
the source site should be used as the rendezvous site for
subsequent IN messages;
3. ソースサイトがランデブーサイトと異なっているOUTメッセージの領収書は、送信側が動かされているのを示します。 ソースサイトはその後のINメッセージにランデブーサイトとして使用されるべきです。
4. the sending end of a communication path can be moved by passing
the names of the ports to the new sender; to complete the move the
new sender uses the previous sender's site as rendezvous site for
its first OUT message and its own site as rendezvous for
subsequent OUT messages.
4. ポートの名前を新しい送付者に渡すことによって、通信路の送信側を動かすことができます。 移動を終了するために、新しい送付者は最初のOUTメッセージのためのランデブーサイトとその後のOUTメッセージのためのランデブーとしてのそれ自身のサイトとして前の送付者のサイトを使用します。
As simple and appealing as this procedure seems, I doubt that it would be used in practice if MSP were to be implemented as a replacement for or alternative to existing Host-Host protocol. The reason is that the ability to pass ports from Host to Host (needlessly) complicates port name allocation by requiring cooperation among Hosts to manage the allocation (e.g., before a Host can safely allocate a port name for use by a local process it must not only insure that the port is not in use locally but also that no process out in the network is using it.) The inter-Host cooperation required to support the passage of ports among Hosts can probably not be reliably achieved in practice. Therefore port passage of the sort described in RFC #333 should not be supported at the Host-Host protocol level. For this reason, I feel that within an MSP "reconnection" would be best handled by a mechanism such as the one proposed in this note.
この手順は簡単で魅力的に見えますが、私は、MSPが既存のHost-ホストプロトコルへの交換か代替手段として実行されることになっているならそれが実際には使用されるのを疑問に思っています。 理由は(不必要に)HostからHostまでポートを通り過ぎる能力が配分を管理するためにHostsの中で協力を必要とすることによってポート名前配分を複雑にするという(例えば、Hostが使用のためにローカルの工程で安全にポート名を割り当てることができる前にそれは、ポートが局所的に使用中ではありませんが、ネットワークにおけるどんな過程もそれをまた使用しないことでもあることを保障するだけでよくはありません。)ことです。 たぶん実際にはHostsの中でポートの通路を支持するのに必要である相互Host協力は確かに達成できません。 したがって、Host-ホストプロトコルレベルでRFC#333で説明された種類のポート通路を支持するべきではありません。 この理由で、私は、この注意で提案されたものなどのメカニズムでMSP「再接続」の中のそれを扱うのが最も良いと感じます。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Anthony Anderberg 4/99 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][アンソニーAnderberg4/99によるオンラインRFCアーカイブへの]
Thomas [Page 12]
トーマス[12ページ]
一覧
スポンサーリンク
