RFC718 日本語訳
0718 Comments on RCTE from the Tenex Implementation Experience. J.Postel. June 1976. (Format: TXT=3829 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group Jon Postel (SRI-ARC) Request For Comments: 718 Jun 1976 NIC #35874
コメントを求めるワーキンググループのジョン・ポステル(様アーク)Requestをネットワークでつないでください: 718 Jun1976NIC#35874
The following memo was a page of a document describing changes in version 1.34 of the Tenex system. I believe that the author is Ray Tomlinson or someone else in the BBN-RCC Tenex group. In any case Ray has agreed that these comments should be circulated to the to the network community, rather than to only the Tenex community.
以下のメモはTenexシステムのバージョン1.34における変化について説明するドキュメントの1ページでした。 私は、作者がBBN-RCC Tenexグループでレイ・トムリンスンか他の誰かであると信じています。 どのような場合でも、レイが、これらのコメントに循環するべきであるのに同意した、Tenex共同体だけにというよりむしろネットワーク共同体に。
Comments on RCTE from the TENEX Implementation Experience
TENEX実装経験からのRCTEのコメント
The code to implement the RCTE option of the new TELNET protocol for TENEX has been completed. The RCTE option permits a reduction in network traffic by deferring the transmission of characters which will not cause the receiving user program to be activated until a character which will cause the user program to be activated. A further reduction is achieved by minimizing the flow of echo characters back to the user TELNET program. This is done by having the server instruct the user TELNET to echo the group of characters up through the next wakeup character. By sending this command as the user program is about to read the first character of that group, the echo is guaranteed to follow any response to the preceding group of characters.
TENEXのためにRCTEが新しいTELNETプロトコルのオプションであると実装するコードは完成しました。 RCTEオプションは、受信にユーザ・プログラムを引き起こさないキャラクタの遺伝を延期するのによるネットワークトラフィックでの減少がユーザ・プログラムを動かせるキャラクタまで起動されることを許可します。 一層の減少は、ユーザTELNETプログラムへのエコーキャラクタの流れを最小にすることによって、達成されます。 サーバに次のwakeupキャラクタを通してキャラクタのグループを反映するようユーザTELNETに命令させることによって、これをします。 ユーザ・プログラムがそのグループの最初のキャラクタを読もうとしているときこのコマンドを送ることによって、エコーはキャラクタの前のグループへのどんな応答にも続くように保証されます。
Significant problems with the RCTE protocol were encountered. The handling of spontaneous output was specified in a way that made the implementation extremely difficult to do correctly (if, indeed, a correct implementation is possible). The solution here was to completely isolate the control of input transmission and echoing from the characters flowing in the output stream. Synchronization of input and output then occurs directly by virtue of the embedding of control information in the output stream. This approach permits a simplified coding of both the user TELNET and server TELNET.
RCTEプロトコルに関する重大な問題は遭遇しました。 自然発生的な出力の取り扱いは正しく実装をするのを非常に難しくした方法で指定されました(正しい実装が本当に可能であるなら)。 ここのソリューションは入力送信と出力ストリームで流れるキャラクタから反響するコントロールを完全に隔離することでした。 そして、入出力の同期は直接出力ストリームへの制御情報の埋め込みによって起こります。 このアプローチはユーザTELNETとサーバTELNETの両方の簡易型のコード化を可能にします。
A second problem was the handling of interrupt characters. The RCTE protocol fails to provide an explicit mechanism for interrupt characters thus necessitating the handling of interrupt characters as program wakeup characters. Since the interrupt characters are not actually handled as program wakeup characters and, in fact, bypass the terminal input buffer, a special provision had to be made to get the command sent back to the user TELNET to indicate that the character stream should be echoed beyond the point where the interrupt character was typed. The transmission must be synchronized with the processing of the terminal input buffer so that it will be sent at the proper time. This was achieved by putting a marker in the input buffer at the point where the interrupt character was. This marker is never given to the user's program and must not be counted as an input character. A new counter was installed indicating the number of such markers in the input buffer and the SIBE JSYS modified to indicate "empty" only if the difference of the total characters in the buffer and the number of markers in the buffer is greater than 0.
2番目の問題は中断キャラクタの取り扱いでした。 その結果、RCTEプロトコルは、プログラムwakeupキャラクタとして中断キャラクタの取り扱いを必要としながら、明白なメカニズムを中断キャラクタに提供しません。 以来、中断キャラクタは、実際にプログラムwakeupキャラクタとして扱われないで、事実上、端末の入力バッファを迂回させて、コマンドは、キャラクタストリームが中断文字がタイプされたポイントを超えて反響されるべきであるのを示すために特別条項によってユーザTELNETに送り返さされなければなりませんでした。 トランスミッションは、適切な時にそれを送るように端末の入力バッファの処理と同時にしなければなりません。 これは、中断キャラクタがそうであったポイントで入力バッファにマーカーを入れることによって、達成されました。 このマーカーを、ユーザープログラムに決して与えないで、入力キャラクタにみなしてはいけません。 新しいカウンタは、総キャラクタのバッファの違いとバッファのマーカーの数が0以上である場合にだけ「空になってください」と示すように変更された入力バッファとSIBE JSYSのそのようなマーカーの数を示しながら、インストールされました。
-1-
-1-
A third problem is handling the case where the input buffer is cleared. Since the buffer may contain various wakeup characters and special markers, when the buffer is cleared, the user TELNET and SERVER may get out of sync. It is infeasible to scan the buffer and send a RCTE command for each such wakeup character or special marker. instead, a command is sent to the user TELNET meaning "clear your input buffer and reset your counters". This command is implemented by sending "WILL RCTE". This is the reverse case from a normal RCTE (i.e. DO RCTE) and thus cannot be confused with the normal use of the RCTE option. This saves adding a new option.
3番目の問題は入力バッファがきれいにされるケースを扱っています。 バッファがきれいにされるとき、バッファが様々なwakeupキャラクタと特別なマーカーを入れてあるかもしれないので、ユーザTELNETとSERVERは同期しないかもしれません。 そのようなそれぞれのwakeupキャラクタか特別なマーカーのためにバッファをスキャンして、RCTEコマンドを送るのは実行不可能です。代わりに、「あなたの入力バッファをきれいにして、あなたのカウンタをリセットします」と意味するユーザTELNETにコマンドを送ります。 このコマンドは、「ウィルRCTE」を送ることによって、実装されます。 これは、正常なRCTE(すなわち、DO RCTE)からの逆のケースであり、その結果、RCTEオプションの通常の使用に混乱できません。 これは、付加が新しいオプションであると保存します。
-2-
-2-
一覧
スポンサーリンク