RFC563 日本語訳
0563 Comments on the RCTE Telnet option. J. Davidson. August 1973. (Format: TXT=10788 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Davidson Request for Comments: 563 University of Hawaii NIC: 18775 28 August 1973 References: RFC 357, RFC 560
コメントを求めるワーキンググループJ.ディヴィッドソン要求をネットワークでつないでください: 563 ハワイ大学NIC: 18775 1973年8月28日の参照: RFC357、RFC560
Comments on the RCTE TELNET Option
RCTE telnetオプションのコメント
RFC 560 describes a Remote Controlled Transmission and Echoing TELNET option. Its authors provide a framework wherein a serving host may control two aspects of TELNET communication over the (simplex) user- to-server path. Commands are introduced which govern 1. when (and which) characters shall be echoed by the user, and 2. when (and which) characters shall be transmitted by the user.
RFC560はRemote Controlled TransmissionとEchoing TELNETオプションについて説明します。 作者は給仕のホストが(シンプレクス)の上でTELNETコミュニケーションの2つの局面を制御するかもしれない枠組みにサーバへのユーザ道を提供します。 そして、そして、1 いつを治めるコマンドが紹介される、(どれ、)、キャラクタが2 ユーザ、およびいつまでに言葉を繰り返されるものとするか、(どれ、)、キャラクタはユーザによって伝えられるものとするか。
Motivation for the option was based on two considerations: 1. the latency between striking and printing of a character which is to be echoed by a remote server is disconcerting to the human typist, and 2. character-at-a-time transmission introduces processing inefficiencies (for IMPS, for servers, for users) and decreases effective channel thruputs over the net.
オプションに関する動機は2つの問題に基づきました: 1. リモートサーバによって言葉を繰り返されることになっているキャラクタの打撃と印刷の間の潜在が人間のタイピストに混乱させられていて、一度にキャラクタトランスミッションは、2 処理非能率(IMPS、サーバ、ユーザのための)を導入して、ネットの上で有効なチャンネルスループットを減少させます。
The author feels that the RCTE description is in error (or at least unclear [1]) in its treatment of when characters are to be transmitted. However, discussion of the subject in the RCTE specification is incomplete, so it is difficult to point to a statement which is "wrong." Rather, the present objections are based on inferences drawn from the sample TENEX interaction
作者は、RCTE記述が間違っていると感じます。(または、少なくともキャラクタが伝えられることになっている時に関する処理における不明瞭な[1])。 しかしながら、RCTE仕様に基づく、対象の議論が不完全であるので、「間違った」声明を示すのは難しいです。 むしろ、現在の反論はサンプルTENEX相互作用から得られた推論に基づいています。
Perhaps there is some misunderstanding of the original issues to which RCTE now addresses itself.
恐らく、RCTEが現在それ自体を記述するオリジナルの問題の何らかの誤解があります。
Original Motivation for Remote Controlled Echoing (RCE)
遠隔操作の反響に関するオリジナルの動機(RCE)
RFC 357 (An Echoing Strategy for Satellite Links) introduced a need for RCE for users who are separated from a service host by a satellite link. The motivation was to lessen human frustration and confusion; no consideration was given to resulting processing inefficiencies or channel thruputs.
RFC357(SatelliteリンクスのためのEchoing Strategy)は衛星中継によってサービス・ホストと切り離されるユーザのためにRCEの必要性を導入しました。 動機は人間のフラストレーションと混乱を少なくすることでした。 結果として起こる処理非能率かチャンネルスループットに対して考慮を全く払いませんでした。
(In the remainder of this RFC, we consider character transmission apart from echoing considerations.)
(このRFCの残りでは、問題を反映することは別として、私たちはキャラクタトランスミッションを考えます。)
Davidson [Page 1] RFC 563 Comments on the RCTE TELNET Option 28 August 1973
RCTE telnetオプション1973年8月28日のディヴィッドソン[1ページ]RFC563コメント
It was recognized that the human's best interests could be served if user-to-server transmission were performed on a character-by- character basis, (the implicit assumption being that this insured the most rapid server response possible). This scheme allowed for the classic overlap of (network) I/O and computation, and was thus efficient as far as the (human) user was concerned.
ユーザからサーバへの送信が役立たれているなら人間の利益のために役立つことができると認められました。基礎、キャラクタによる(これが応答可能な最も急速なサーバを保障したということである暗黙の仮定)はキャラクタに実行されます。 この計画は、(ネットワーク)入出力と計算の古典的なオーバラップを考慮して、(人間)のユーザに関する限り、その結果、効率的でした。
Concessions were made in the transmission strategy when it was accepted that the serving process could not in fact do any significant processing until a completed command was available. Ideally then, users should be able to buffer characters until they have a completed command and then fire off the entire command in a single "packet," with the resultant savings in channel usage and a greater per-packet data efficiency. The characters which delimited commands were called wakeup characters, in 357, for their effect on the serving process. RCTE calls them transmission characters for the effect they have at the User TELNET.
完成したコマンドが利用可能であったときに事実上、給仕の過程が初めて少しの重要な処理もできたと受け入れたとき、トランスミッション戦略で譲歩をしました。 ユーザは彼らは単一の「パケット」に全体のコマンドから完成したコマンドを持っていて、次に、炎を持つまでキャラクタをバッファリングできるべきです、理想的に当時でありチャンネル用法による結果の貯蓄と1パケットあたり1つのより大きいデータ効率で。 コマンドを区切ったキャラクタは給仕の過程への彼らの効果のために357でwakeupキャラクタと呼ばれました。 RCTEは、彼らがUser TELNETに持っている効果のためにそれらをトランスミッションキャラクタと呼びます。
The key here is that it is quite possible for a human, separated by a satellite link from his remote host, to type several completed commands - and to therefore initiate several packet transmissions- all the while awaiting the server's response to his first command. Again we see the overlap of I/O and computation, and again we achieve maximum efficiency from the human's viewpoint.
ここのキーによる衛星中継によって彼のリモートホストと切り離された人間にとって、いくつかの完成したコマンドをタイプして、したがって、ずっと彼の最初のコマンドへのサーバの応答を待ついくつかのパケット伝送に着手するのがかなり可能であるということです。 一方、私たちは入出力と計算のオーバラップを見ます、そして、一方、人間の観点から最高効率を達成します。
The problem, however, is that wakeup (transmission) character sets change. And there will always be a finite amount of time [the one- way transmission time] during which the set definitions will differ between server and user. This says that during such times the user will be sending off packets which do not contain completed commands, (or contain more than a single completed command), or he will be buffering characters beyond the end of a completed command. (A fourth alternative is that he may actually still be doing the right thing by chance). Buffering beyond the end of a command is the only case which lessens processing efficiency for the human, however.
しかしながら、問題はwakeup(トランスミッション)文字の組が変化するということです。 そして、セット定義がサーバとユーザの間で異なる有限時間[トランスミッションが調節される1つの方法]がいつもあるでしょう。 これが、ユーザがそうするそのような回の間のそれが完成したコマンドを含まない退場パケットであると言う、(ただ一つの完成したコマンド以上を含んでください)、彼は完成したコマンドの終わりにキャラクタをバッファリングするでしょう。 (4番目の代替手段は彼が実際にまだ偶然正しいことをしているかもしれないということです。) コマンドの終わりのバッファリングはしかしながら、人間のために処理効率を少なくする唯一のこの件です。
Dissatisfaction With RCTE
RCTEへの不満
Here is the author's complaint: RCTE [at least the sample interaction which allowed transmission (by default) only at break characters] would have the TELNET user wait until he knows exactly the wakeup (transmission) character set being used by the server ! Ideal channel utilization might be achieved, since no "unnecessary" packets are sent (and, strangely, no extra characters are allowed in the current packet) but the overlap of I/O and computation has been eliminated, and the human has an extra round-trip time added to the server's processing time. This is wrong.
ここに、作者の苦情があります: TELNETユーザは、少なくとも区切り文字だけにトランスミッション(デフォルトで)を許容したサンプル相互作用でサーバによって使用されることでまさにwakeup(トランスミッション)文字の組を知るまで待ちます!RCTE、Idealチャンネル利用は達成されるかもしれません; 入出力と計算のオーバラップは排除されました、そして、以来、「不要な」パケットを全く送りませんが(奇妙に、どんな余分なキャラクタも現在のパケットに許容されていません)、人間は余分な往復の時間をサーバの処理時間に加えさせます。 これは間違っています。
Davidson [Page 2] RFC 563 Comments on the RCTE TELNET Option 28 August 1973
RCTE telnetオプション1973年8月28日のディヴィッドソン[2ページ]RFC563コメント
An Alternative Implementation
代替の実現
Unless a round-trip time penalty is to be paid by the human at every break interaction, the user TELNET must transmit characters based on the transmission character set in effect at the moment the characters are typed. And unless the step-by-step interaction developed in the RCTE TENEX example was not a true representation of the relative temporal occurances of events, RCTE did not do this.
ユーザTELNETは往復の時間刑罰があらゆる中断相互作用で人間によって支払われるというわけではないことであるなら、事実上、トランスミッション文字の組に基づくキャラクタを伝えなければなりません、現在、文字がタイプされます。 そして、RCTE TENEXの例で開発された段階的な相互作用が出来事の相対的な時のoccurancesの正しい表現であったなら、RCTEはこれをしませんでした。
The sample TENEX interaction showed the user typing
サンプルTENEX相互作用は、ユーザがタイプするのを示しました。
(T:) LOGIN ARPA <cr>
(T:、)、ログインアルパ<cr>。
while the break set included <space> and <cr>. The only transmission characters in effect were the break characters - by default. The RCTE example showed that the LOGIN <space> phrase was, properly, a completed command; it was transmitted. But while the alternative transmission strategy of the current RFC would "recognize" the ARPA <cr> phrase as a second completed command, and thus initiate a second transmission, RCTE withholds judgment until the server respecifies the transmission classes. Response for the user suffers.
中断は含まれている<スペース>と<cr>を設定しましたが。 事実上、唯一のトランスミッションキャラクタがデフォルトで区切り文字でした。 RCTEの例は、LOGIN<スペース>句が適切に完成したコマンドであることを示しました。 それは伝えられました。 しかし、現在のRFCの代替のトランスミッション戦略は、2番目がコマンドを終了したのでARPA<cr>句を「認識し」て、その結果、2番目のトランスミッションを開始するでしょうが、RCTEはトランスミッションが分類するサーバrespecifiesまで判断を差し控えます。 ユーザのための応答に苦しみます。
One might also ask what transmission strategy was to be undertaken when two users were, say, linked thru a TENEX. Transmission should obviously be at every character. RCTE would send the first single character packet and then wait to be sure that a single character did in fact delimit the next command also. It would wait a long time it would seem, since no break interaction would occur until the end of the line (<cr>). The user would be echoing like a champ, but no characters would be transmitted for the linked party's inspection.
また、人は、どんなトランスミッション戦略がたとえば、2人のユーザがTENEXを通してリンクされたとき、引き受けられるかことであったかと尋ねるかもしれません。 トランスミッションがすべてのキャラクタに明らかにあるべきです。 RCTEは、最初の単一のキャラクタパケットを送って、次に、事実上、単独のキャラクタが次のコマンドも区切ったのを確信しているのを待っているでしょう。 それは見えるだろう長い時代に待つでしょう、中断相互作用が全く行(<cr>)の終わりまで起こらないでしょう、したがって。 ユーザはチャンピオンのように反響しているでしょうが、キャラクタは全く繋がっているパーティーの点検のために伝えられないでしょう。
If we adopt the convention that transmission decisions should be based on the transmission set [and by default, the break set] in effect at the time the character is typed, then the sample interaction might in fact look like this:
私たちがトランスミッション決定が基づくべきであるコンベンションを採用するなら、文字がタイプされるとき、事実上、トランスミッションはセットしました[デフォルトで、中断はセットしました]、次に、事実上、サンプル相互作用はこれに似るかもしれません:
P: TENEX 1.31.18, TENEX EXEC 1.50.2 <cr> <lf>@
P: TENEX1.31.18、TENEX幹部1.50.2<cr><lf>。@
T: LOGIN <space> P: LOGIN <space> } >>>>>> NOTE: Typing and printing occurs simul- U: LOGIN <space> taneously up to the <space> at which point the human "types-ahead." T: ARPA <cr>
T: ログイン<スペース>P: ログイン<スペース>。 >>>>>>注意: タイプと印刷が現れる、simul- U: どれが人間を指すかで<スペース>までのLOGIN<スペース>taneouslyは「-先では、タイプされます」。 T: アルパ<cr>。
U: ARPA <cr> <<key: the user transmits a second packet.
U: アルパ<cr><<キー: ユーザは2番目のパケットを伝えます。
Davidson [Page 3] RFC 563 Comments on the RCTE TELNET Option 28 August 1973
RCTE telnetオプション1973年8月28日のディヴィッドソン[3ページ]RFC563コメント
S: <space> <IAC> <SB> <RCTE> <0>
S: <スペース><IAC><SB><RCTE><0>。
P: <space> AR
P: <スペース>AR
S: <cr> <lf> (PASSWORD): <IAC> <SB> <RCTE> <7>
S: <cr><lf>(パスワード): <IAC><SB><RCTE><7>。
[the server sends while text is printing]
[テキストは印刷ですが、サーバは発信します]
P: PA <cr> <lf> (PASSWORD):
P: PA<cr><lf>(パスワード):
T: WASHINGTON <space>
T: ワシントン<スペース>。
U: WASHINGTON <space>
U: ワシントン<スペース>。
T: 100
T: 100
S: <space> <IAC> <SB> <RCTE> <3>
S: <スペース><IAC><SB><RCTE><3>。
P: <space> 100
P: <スペース>100
T: 0 [Again printing is simultaneous to typing]
T: 0 [一方、印刷はタイプと同時です]
P: 0
P: 0
T: <cr>
T: <cr>。
P: <cr>
P: <cr>。
U: 1000 <cr>
U: 1000<cr>。
S: <cr> <lf> JOB ...
S: <cr><lf>仕事…
The interaction will not necessarily be the same each time. It depends on the typing speed of the user and response time of the server. For this example, both channel utilization and performance for the human are perfect, since the transmission set [even though it was only the default break set] did not change.
相互作用はその都度、必ず同じになるというわけではないでしょう。 それはユーザのタイプ速度とサーバの応答時間によります。この例に関して、チャンネル利用と人間のための性能の両方が完全です、トランスミッションセット[唯一のそれはデフォルト中断セットでしたが]が変化しなかったので。
Unsolicited Output
求められていない出力
The question of unsolicited output arise again. The treatment in 560 was simplified over that of 357 only because of the RCTE transmission strategy. No output could possibly be returning for a command which hasn't been sent yet (!), so the message must be "SYSTEM GOING DOWN."
求められていない出力の問題は再び起こります。 560における処理は単にRCTEトランスミッション戦略のために357のものの上で簡素化されました。 出力が全く送られないコマンドにもかかわらず、(!)のために戻ることができなかったので、メッセージは「システム低下」であるに違いありません。
Davidson [Page 4] RFC 563 Comments on the RCTE TELNET Option 28 August 1973
RCTE telnetオプション1973年8月28日のディヴィッドソン[4ページ]RFC563コメント
RFC 357 outlines when unsolicited output can be recognized and when it should be printed, in line with the alternate transmission scheme proposed. The requirement that such system alerts be terminated by RCTE commands is of course the proper way to handle such interrupts; this clarification of the unsatisfactory solution in 357 is appreciated.
求められていない出力を認識できて、それが交互のトランスミッション計画に沿って印刷されるべきときのRFC357アウトラインは提案しました。 そのようなシステム警戒がRCTEコマンドで終えられるという要件はもちろんそのような中断を扱う適切な方法です。 357における、不満足な解決のこの明確化に感謝します。
TIP Buffering
チップバッファリング
RCTE as defined cannot allow a user to transmit when his buffer is full, else he might send a break character. [presumably the buffer fills because we are waiting for break (transmission) redefinition]. The response to the command delimited by the break character could return before the characters, of the command were "echoed." RCTE would thus demand that it be printed first, and the listing would be out of order.
彼のバッファが完全であるときに、定義されるとしてのRCTEはユーザを伝えさせることができないで、ほかに、彼は区切り文字を送るかもしれません。 [私たちが中断(トランスミッション)再定義を待っているので、おそらく、バッファはいっぱいになります。] 区切り文字によって区切られたコマンドへの応答はキャラクタの前で戻ることができて、「反響」はコマンドの、そうですか? その結果、RCTEは、それが最初に印刷されるのを要求するでしょう、そして、リストは故障しているでしょう。
The alternative transmission strategy eliminates this problem since transmission of a full buffer is no worse than guessing incorrectly that the last character in the buffer is a transmission character.
バッファにおける最後のキャラクタがトランスミッションキャラクタであると不当に推測するほど完全なバッファの伝達が悪くないので、代替のトランスミッション戦略はこの問題を解決します。
A further suggestion
さらなる提案
All server-to-user echoing could be eliminated if control bytes were sent to indicate which break sets should be echoed and which shouldn't.
どの中断セットが反響されるべきであるか、そして、どれが反響されるべきでないかを示すためにコントロールバイトを送るなら、サーバからユーザへのすべての反響を排除できるでしょうに。
Endnotes
エンドノート
[1] for example: statement 2E2F does not properly distinguish between the "occurrence" of a break character and the "occurrence" of a Transmission character. The present RFC shows that they are fundamentally different.
[1] 例えば: 2声明2E Fは適切に区切り文字の「発生」とTransmissionキャラクタの「発生」を見分けません。 現在のRFCは、それらが基本的に異なっているのを示します。
Davidson [Page 5]
ディヴィッドソン[5ページ]
一覧
スポンサーリンク