RFC357 日本語訳
0357 Echoing strategy for satellite links. J. Davidson. June 1972. (Format: TXT=30103 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group John Davidson
Request for Comments: 357 University of Hawaii
NIC: 10599 Will Crowther
Categories: Remote Controlled Echoing, Satellite, TELNET BBN
References: RFC's 346, 355, 358, 318 John McConnell
ILLIAC
Jon Postel
UCLA
June 26, 1972
コメントを求めるワーキンググループJohn Davidson Requestをネットワークでつないでください: 357 ハワイ大学NIC: 10599 ウィルクラウザーCategories: 遠隔操作の反響、衛星、telnet BBN参照: 1972年6月26日のRFCの346、355、358、318ジョンマッコネールILLIACジョンポステルUCLA
An Echoing Strategy For Satellite Links
衛星中継への反響戦略
I. Introduction
I. 序論
As mentioned in RFC 346 ("Satellite Considerations" by Jon Postel)
those interactive systems which provide echoing for full-duplex
terminals over the ARPANET become more awkward to use as transmission
delays increase. The reason, of course, is that a character's round
trip time is added to the inherent echo delay of the server with the
result that the terminal echoing appears extremely sluggish.
RFC346(ジョン・ポステルが「衛星問題」)で言及されるように、トランスミッション遅れが増加するのに従って、アルパネットの上で全二重端末に反響しながら提供されるそれらの対話的なシステムは使用するために、より無器用になります。 理由はもちろんキャラクタの周遊旅行時間がサーバの固有のエコー遅れに加えられて、その結果、端末の反響が非常にのろく見えるという、ことです。
For a terminal separated from its server by a single satellite link, the delay will be such that even if echoing at the server were instantaneous, the latency between keying and printing of an input character will be nearly half a second. If, in addition, the character is routed thru a portion of the surface net, the delay will be of course increase. It is estimated that echo delays of at least one second will not be uncommon.
サーバで反響するのが瞬時に起こったとしても、入力キャラクタの合わせるのと印刷の間の潜在がほとんど半分の2番目になるように遅れは単一の衛星中継によってサーバと切り離された端末に関してはものになるでしょう。 キャラクタが表面ネットの部分を通ってさらに、発送されると、遅れはもちろん増加でしょう。 少なくとも1秒のエコー遅れが珍しくならないと見積もられています。
This document describes a strategy which will eliminate the delay associated with simple echoing and allow the transmission delay to be hidden in the cost of computation only. This scheme is proposed as an optional addition to existing User TELNETs; its use requires the explicit support of a cooperating server process.
このドキュメントは簡単な反響に関連している遅れを排除して、トランスミッション遅れが計算だけの費用に隠されるのを許容する戦略を説明します。 この体系は任意の追加として既存のUser TELNETsに提案されます。 使用は協力関係を持っているサーバプロセスの明白なサポートを必要とします。
II. Standard Echo Strategy
II。 標準のエコー戦略
Echoing for locally connected full-duplex terminals is normally provided at the server by a resident system task called the (e.g.) Terminal Handler. The Terminal Handler echoes on a one-for-one or simple replacement basis and buffers all typed input on behalf of the user process.
局所的に接続された全二重端末に反響するのが、居住者によるサーバでは、通常、システムタスクが呼んだかどうかということである、(例えば) 端末の操作者。 Terminal Handlerは個人的には1か簡単交換ベースで反響して、ユーザ・プロセスを代表してすべてのタイプされた入力をバッファリングします。
To let the user process operate most efficiently, the Terminal Handler should collect characters until a complete command or parameter (or whatever) has been typed. Then, presumably, the process can do some significant computing. Since the user process
ユーザ・プロセスが最も効率的に作動するように、完全なコマンドかパラメタ(または、何でも)がタイプされるまで、Terminal Handlerはキャラクタを集めるはずです。 そして、おそらく、プロセスは何らかの重要なコンピューティングができます。 ユーザ・プロセス以来
Davidson [Page 1] RFC 357 An Echoing Strategy For Satellite Links June 1972
衛星中継1972年6月のための反響戦略あたりディヴィッドソン[1ページ]RFC357
knows the syntax of the string it expects, it can specify to the Terminal Handler those characters which delimit completed parameters. Such characters are called 'Wakeup Characters' since the user process is awakened as they are echoed.
それが予想するストリングの構文であり、完成したパラメタを区切るそれらのキャラクタはTerminal Handlerに指定できるのを知っています。 それらが反響されるときユーザ・プロセスが目を覚ますので、そのようなキャラクタは'Wakeupキャラクター'と呼ばれます。
Certain commands keyed by the user will require an output response from the process. In order that the typed commands be followed by its response and be separated from succeeding commands, the Terminal Handler must suspend echoing of user type-ahead. It can resume echoing (starting for type-ahead - with the unechoed characters in the buffer) as soon as the process has stated (implicitly or explicitly) that it has completed the output response.
ユーザによって合わせられたあるコマンドはプロセスから出力応答を必要とするでしょう。 タイプされたコマンドが続くコマンドと応答があとに続いていて、切り離されるために、Terminal Handlerは先のユーザタイプの反響を中断させなければなりません。 それは、プロセスが、出力応答を終了したと述べると(それとなくか明らかに)すぐに、反響するのを(先のタイプに、バッファの非反響しているキャラクタと共に出発します)再開できます。
Characters which cause the Terminal Handler to suspend echoing are called 'break characters' They are specified by the user process based upon the syntax of the expected input. Normally break characters are also wakeup characters. As examples:
Terminal Handlerが反響を中断させるキャラクターは呼ばれた'区切り文字'Theyが予想された入力の構文に基づくユーザ・プロセスで指定されるということです。 通常、また、区切り文字はwakeupキャラクタです。 例として:
1. A text editor may gobble up typed English sentences every time
a period or question mark is echoed. The two characters are
wakeup characters only. There is no need to suspend echoing.
1. 期間か疑問符が反映されるときはいつも、テキストエディタはタイプされた英文を取り込むかもしれません。 2つのキャラクタがwakeupキャラクタ専用です。 反響を中断させる必要は全くありません。
2. In some systems, an ESC character is used to invoke command
recognition. The user who types
2. いくつかのシステムでは、ESCキャラクタは、コマンド認識を呼び出すのに使用されます。 タイプするユーザ
CO [ESC] ABC [ESC] XYZ
CO[ESC]ABC[ESC]XYZ
should see as output
出力されるように見るべきです。
COPY (FROM FILE) ABC (TO FILE) XYZ
コピー(ファイルからの)ABC(ファイルする)XYZ
The ESC is both a break and a wakeup. The printout should be
the same no matter how fast the user types.
ESCは中断とwakeupの両方です。 ユーザがどれくらい速くタイプしても、プリントアウトは同じであるべきです。
The server must provide a means for each user process to communicate the following to the Terminal Handler:
サーバは各ユーザ・プロセスが以下をTerminal Handlerに伝える手段を提供しなければなりません:
1. the set of wakeup characters,
2. the set of break characters,
3. which break characters should and which should not be echoed,
(Some break characters - such as ESC in example 2 - should not
be echoed).
4. completion of an output response,
5. whether or not to echo characters. (Not echoing is useful in
"hide your input" applications.)
1. wakeupキャラクタ2 (区切り文字(例2のESCなどの何人かの区切り文字の言葉を繰り返すべきではありません)のセット)のセット。その区切り文字は、キャラクタは3 それの中断がそうするべきであり、言葉を繰り返されるべきではありません。 4. 出力応答、5の完成、キャラクタの言葉を繰り返すのであるかどうか (反響でないのは「入力を隠してください」というアプリケーションで役に立ちます。)
Davidson [Page 2] RFC 357 An Echoing Strategy For Satellite Links June 1972
衛星中継1972年6月のための反響戦略あたりディヴィッドソン[2ページ]RFC357
As far as implementation, 1. and 2. could be communicated by allowing the user process to specify a 128-bit (for an ASCII device) table with 1's set for each wakeup character, and another table with 1's set for each break character. This approach becomes fairly expensive in terms of core memory as the number of terminals becomes large; the system must store these bit tables itself since in most cases the user process will not be in core while echoing is being done by the Terminal Handler.
実装と同じくらい詳しく、それぞれのwakeupキャラクタあたり1セットで128ビット(ASCIIデバイスのための)のテーブルを指定して、ユーザ・プロセスは各区切り文字あたり1セットで別のテーブルを指定するのを許容することによって、1と2を伝えることができるでしょう。 端末の数が大きくなるのに応じて、このアプローチはコアメモリでかなり高価になります。 反響がTerminal Handlerによって行っていることにされるのである間、ユーザ・プロセスが多くの場合コアにないので、システムはそれ自体でこれらのビット・テーブルを保存しなければなりません。
To reduce the storage requirements, the system can make known to all its programmers a limited number, say 4, of supported break characters for his process from, for example:
ストレージ要件、缶がすべてのプログラマにとって限られた数を知って、彼のプロセスのために4人のサポートしている区切り文字を言うのをさせるシステムを減少させるために例えば:
a. alphanumeric characters,
b. punctuation characters,
c. echoable control characters (including the bell and CR, etc.),
or
d. non-echoable control characters (Control-C, etc.),
a. 英数字、b.句読文字、c.は制御文字(ベルとCRなどを含んでいる)、またはd.非反響可能制御文字(コントロールCなど)を反響可能します。
by specifying in a system call which break set(s) should be used. This requires no more than 4 bits of system storage per terminal, and a single table to identify the set(s) to which each of the 128 possible ASCII characters belongs.
システムコールでどれが壊れるかを指定することによって、セットは使用されるべきです。 これは、128人の可能なASCII文字各人が属するセットを特定するために1端末あたりのシステムストレージの4ビット未満、および単一のテーブルを必要とします。
For the user process to communicate (3) to the Terminal Handler (which break characters should and which should not have echoed), the process can specify another 4 bit field with 1's set for those break classes whose members should be echoed. For the 4 classes above, only 3 bits would be required since members of class (d) are defined to be non-echoable.
ユーザ・プロセスがTerminal Handler(区切り文字がそうするべきであり、反響するべきでなかった)に(3)を伝えるように、プロセスは、それらの中断のクラスのための1セットでだれのメンバーが言葉を繰り返されるべきであるかを別の4ビットの分野に指定できます。 4つのクラスにおいて、クラス(d)のメンバーが非反響可能になるように定義されるので、上では、3ビットだけが必要でしょう。
To communicate the completion of an output response (4), the user process could issue an explicit system call; or, the Terminal Handler could assume completion when the user process requests input of the first character following the break.
出力応答(4)の完成を伝えるために、ユーザ・プロセスは明白なシステムコールを発行するかもしれません。 中断に続いて、ユーザ・プロセスが最初のキャラクタの入力を要求するとき、または、Terminal Handlerは完成を仮定できました。
"Hide your input" (5) would be communicated by a system call which specifies either:
「入力を隠してください」という(5)は指定するシステムコールで伝えられるでしょう:
(a) "break on every character and don't echo any break characters",
or, for example
(b) "don't echo anything and break on punctuation, or any control
character" for an alphanumeric password,
(a) 「キャラクタをすべてのキャラクタの上で調教して、どんな中断の間も、言葉を繰り返さないでください」か(b) 例えば、英数字のパスワードに関する「何とも句読における中断か、どんな制御文字も反映しないでください」
depending on the syntax of the expression to be hidden.
隠されるために式の構文によります。
Davidson [Page 3] RFC 357 An Echoing Strategy For Satellite Links June 1972
衛星中継1972年6月のための反響戦略あたりディヴィッドソン[3ページ]RFC357
III. Definitions
III。 定義
Several new terms need to be defined, some of which are direct extensions of the terms used in the "standard echo strategy" description. There is no reason to insist that the four buffers presented all be implemented as individual constructs; they are logically separated for clarity in the discussions which follow.
いくつかの新学期が、定義される必要があります、「標準のエコー戦略」記述に使用される用語の直接的拡張であるもののいくつか。 すべてが提示された4つのバッファが個々の構造物として実装されると主張する理由が全くありません。 それらは続く議論における明快ために論理的に切り離されます。
Remote Controlled Echoing (RCE)
遠隔操作の反響(RCE)
This is the name for the echo strategy described in this document.
Echoing will be controlled by the (remote) server but performed by
the User TELNET.
これは本書では説明されたエコー戦略のための名前です。 反響は、(リモート)のサーバによって制御されますが、User TELNETによって実行されるでしょう。
Input Buffer
入力バッファ
This is a logical buffer used by a User TELNET to hold characters
in sequence as they are received from the terminal keyboard (after
they have been converted to NVT characters).
これは連続して端末のキーボードから彼らを受け取るように(彼らがNVTキャラクタに変換された後に)キャラクタを保持するのにUser TELNETによって使用された論理的なバッファです。
Transmission Buffer
トランスミッションバッファ
This is a logical buffer used by a User TELNET to hold NVT
characters which have been typed but have not yet been transmitted
to the server.
これはタイプされましたが、まだサーバに伝えられていないNVTキャラクタを保持するのにUser TELNETによって使用された論理的なバッファです。
Output Buffer
出力バッファ
This is a logical buffer used by a User TELNET to hold the NVT
characters received from the server.
これはNVTキャラクタがサーバから受け取られるままにするのにUser TELNETによって使用された論理的なバッファです。
Print Buffer
印刷バッファ
This is a logical buffer residing in the User TELNET from which
characters will be sent in sequence to the terminal printer. (The
output buffer contains NVT characters which may have to be
converted to characters employed by the actual terminal.)
これはキャラクタが連続して端末のプリンタに送られるUser TELNETにある論理的なバッファです。 (出力バッファは実際の端末によって雇われたキャラクタに変換されなければならないかもしれないNVTキャラクタを含んでいます。)
Break Classes
クラスを壊してください。
The 128 possible (7-bit) ASCII characters employed by the Network
Virtual Terminal can be partitioned into several quasi-equivalence
classes (for example alphabetic, numeric, punctuation characters,
etc.). These classes can be defined so that each character is a
member of at least one class, although it may belong to more than
one.
Network Virtual Terminalによって雇われた(7ビット)の可能な128人のASCII文字はいくつかの準同値類(例えば、アルファベットの、そして、数値の句読文字など)に仕切ることができます。 これらのクラスを定義できるので、各キャラクタは少なくとも1つのクラスのメンバーです、1つ以上に属すかもしれませんが。
Davidson [Page 4] RFC 357 An Echoing Strategy For Satellite Links June 1972
衛星中継1972年6月のための反響戦略あたりディヴィッドソン[4ページ]RFC357
A server process may indicate to a User TELNET that certain of
these classes (or all, or none) are to be considered break
classes. That is, a break class is an equivalence class which is
of special significance to the server process. In terms of the
discussion of section II, the Server recognized 4 equivalence
classes any combination of which might be designated as break
class by a particular process.
サーバプロセスは、クラス(または、すべて、またはなにも)が中断のクラスであると考えられることになっているのをこれらがそんなに確かなUser TELNETに示すかもしれません。 すなわち、中断のクラスはサーバプロセスへの特別な意味のものである同値類です。 セクションIIの議論で、Serverは、それのどんな組み合わせも任じられる4つの同値類が特定のプロセスでクラスを壊すと認めました。
The RCE implementation will have more than 4 equivalence classes
(perhaps as many as 8) to provide more flexibility in the choice
of break character sets.
RCE実装には、等価性が区切り文字セットの選択により多くの柔軟性を提供するために分類する(最大恐らく8)4以上があるでしょう。
Break Action
動作を壊してください。
Two break actions are possible:
2つの中断動作が可能です:
(1) a break character encountered in the input buffer IS moved to
the print buffer at the appropriate time, or
(2) a break character encountered in the input buffer IS NOT moved
to the print buffer.
(1) 入力バッファで遭遇する区切り文字が適切な時期で印刷バッファに動かされるか、または(2) 入力バッファで遭遇する区切り文字は印刷バッファに動かされません。
The server process will specify which break action should be
followed. (The two actions correspond to echoing or not echoing
the break character.)
サーバプロセスは、どの中断動作が続かれるべきであるかを指定するでしょう。 (2つの動作が反響するか、または区切り文字の言葉を繰り返さないと対応しています。)
IV. Description
IV。 記述
(This description is written in terms of the TIP which, of course, embodies a User TELNET.)
(この記述はもちろんUser TELNETを具体化するTIPに関して書かれています。)
Remote Controlled Echoing is an attempt to remove the echo responsibility from the Terminal Handler and push it off into the TIP; wakeup processing is still handled at the server. The process' interface (system calls, etc.) to the server's Terminal Handler need not change, but the (abbreviated) Terminal Handler (actually a Server TELNET) must find a way to relay the process' echo requirements to the TIP. It does this with TELNET commands and control information. System calls and echo parameters (break classes, etc.) peculiar to a particular serving Host must be interpreted by the Server Telnet commands.
リモートControlled EchoingはTerminal Handlerからエコー責任を移して、TIPにそれを押し出す試みです。 wakeup処理はサーバでまだ扱われています。サーバのTerminal Handlerへの過程のインタフェース(システムコールなど)は変化ではなく、Handler(実際にServer TELNET)が過程のエコー要件をTIPにリレーする方法を見つけなければならない(簡略化されています)端末がそうしなければなりません。 それはTELNETコマンドと制御情報でこれをします。 Server Telnetコマンドで特定の給仕Hostに独特のシステムコールとエコーパラメタ(クラスなどを壊す)を解釈しなければなりません。
Character Flow
キャラクター流動
Refer to figure 1. A character received from a full-duplex
terminal will be converted to its NVT equivalent and placed in
both the transmission AND the input buffers. The TIP's
transmission strategy determines when it will be removed from the
transmission buffer; the server's RCE control commands dictate
1について計算するには、参照してください。 全二重端末から受け取られたキャラクタは、NVT同等物に変換されて、トランスミッションと入力バッファの両方に置かれるでしょう。 TIPのトランスミッション戦略は、それがいつトランスミッションバッファから取り除かれるかを決定します。 サーバのRCE制御コマンドは命令します。
Davidson [Page 5] RFC 357 An Echoing Strategy For Satellite Links June 1972
衛星中継1972年6月のための反響戦略あたりディヴィッドソン[5ページ]RFC357
when it will be removed from the input buffer.
入力バッファからそれを取り除くとき。
A character received from the server will be placed in the output
buffer.
サーバから受け取られたキャラクタは出力バッファに置かれるでしょう。
Of the three labeled paths DISCARD, ECHO and OUTPUT, exactly one
is enabled at all times. RCE commands dictate which one. Thus
characters may
3のラベルされた経路DISCARDでは、ECHOとOUTPUT、ちょうど1はいつも有効にされます。 RCEコマンドはどれを決めるか。 したがって、キャラクタはそうするかもしれません。
(DISCARD:) be removed in sequence from the input buffer and
discarded,
(ECHO:) be removed in sequence from the input buffer and
placed in the print buffer, of
(OUTPUT:) be removed in sequence from the output buffer and
placed in the print buffer.
(DISCARD:、)、連続して入力バッファから取り除かれて捨てられてください、(ECHO:、)、連続して入力バッファから移されて印刷バッファに置かれてください、(OUTPUT:、)、連続して出力バッファから移されて印刷バッファに置かれてください。
From the print buffer they will be converted from NVT characters
and be immediately send to the terminal's printer.
印刷バッファから、それらは、NVTキャラクタから変換されて、すぐに端末のプリンタに発信するためにことになるでしょう。
+----------------------+
| Terminal Keyboard |
+----------------------+
|
Convert to NVT characters
To +-------------------+ |
Server <----|Transmission Buffer| |
+-------------------+ | +-----From Server
^ | |
|------------------+ |
V V
+-----------------+ +-----------------+
| Input Buffer | | Output Buffer |
+-----------------+ +-----------------+
| | |
DISCARD | +--ECHO---+ +---+ OUTPUT
| | |
V V V
To +----------------------+
Oblivion | Print Buffer |
+----------------------+
|
Convert from
NVT Characters
|
V
To Terminal Printer
+----------------------+ | 端末のキーボード| +----------------------+ | NVTキャラクタTo+に変えてください。-------------------+ | サーバ<。----|トランスミッションバッファ| | +-------------------+ | +-----サーバ^から| | |------------------+ | +に対するV-----------------+ +-----------------+ | 入力バッファ| | 出力バッファ| +-----------------+ +-----------------+ | | | 破棄| +--反響してください。---+ +---+ 出力| | | +へのV V V----------------------+ 忘却| 印刷バッファ| +----------------------+ | NVTキャラクターから、変えてください。| 端末のプリンタへのV
Figure 1. Character Flow within the TIP
図1。 チップの中のキャラクター流動
Davidson [Page 6] RFC 357 An Echoing Strategy For Satellite Links June 1972
衛星中継1972年6月のための反響戦略あたりディヴィッドソン[6ページ]RFC357
Commands: Server to Host
コマンド: ホスティングするサーバ
The following are the proposed TELNET commands sent by the server
process to the TIP. Commands (2) thru (5) should not be sent if
RCE is not being used.
↓これはサーバプロセスによってTIPに送られた提案されたTELNETコマンドです。 RCEを使用していないなら、コマンド(2)から(5)を送るべきではありません。
(1) Use Remote Controlled Echoing. The server asks the TIP to
employ the echo strategy described in this document. The
TIP can respond either YES (I will use it) or NO. (It is
suggested that the response YES also be "Use RCE" to
eliminate race conditions.)
(1) 遠隔操作の反響を使用してください。 サーバは、本書では説明されたエコー戦略を使うようにTIPに頼みます。 TIPははい(私はそれを使用するつもりである)かNO.のどちらかを反応させることができます。 (また、応答はいが競合条件を排除するのに「RCEを使用する」ことであると示唆されます。)
(2) Set Break Action. This is actually 2 commands. The server
can set the break action to echo or not echo a break
character.
(2) 中断動作を設定してください。 これは実際に2つのコマンドです。 サーバは、中断動作に反響しない、または区切り文字の言葉を繰り返さないように設定できます。
(3) Set Break Classes. This command specifies those equivalence
classes which are to be considered break classes. It will
be a two (8-bit) byte command.
(3) 中断のクラスを設定してください。 このコマンドは中断のクラスであると考えられることになっているそれらの同値類を指定します。 それは2(8ビット)バイトのコマンドになるでしょう。
Note: The envisioned implementation requires the TIP to have
a table with one entry per ASCII character. Each entry is
formatted with one bit position for each equivalence class,
and a bit is set or reset according as the given character
is or is not a member of that class. The server sends a
"Set Break Classes" command (1st byte) followed by a
formatted control word (2nd byte) to the TIP with bit
positions set for those equivalence classes which represent
break classes for the server process.
以下に注意してください。 思い描かれた実装は、TIPには1ASCII文字あたり1つのエントリーがあるテーブルがあるのを必要とします。 各エントリーは、与えられたキャラクタがフォーマットされるように1でビットが少し各同値類のために置いて、設定されるか、またはリセットされるフォーマットされるか、そのクラスのメンバーではありません。 サーバはビット位置があるTIPへの(2番目のバイト)がサーバプロセスのために中断のクラスを表すそれらの同値類のためにセットしたというフォーマットされた規制単語をコマンド(最初のバイト)が続けた「セット中断のクラス」を送ります。
When a (virtual) character is taken from the input buffer
the TIP does a table look-up indexed by the character. If a
simple ANDing of the table entry with the terminal's control
word yields a non-zero result, a break was received.
(Receipt of a break character enables the OUTPUT path.)
(仮想)のキャラクタが入力バッファから抜粋されるとき、TIPはキャラクタによって索引をつけられたテーブル索引をします。 端末の規制単語によるテーブル項目の簡単なANDingが非ゼロ結果をもたらすなら、中断を受けました。 (区切り文字の領収書はOUTPUT経路を可能にします。)
(4) Move to Break (MTB). This command directs the TIP to move
characters in sequence from the input buffer to the print
buffer until a break character is encountered. The break
character will be moved or discarded depending on the
previously-specified break action. (Essentially, MTB
enables the ECHO path.)
(4) 移行して、(MTB)を壊してください。 このコマンドは、区切り文字が遭遇するとき連続して入力バッファから印刷バッファまでキャラクタを動かすようTIPに指示します。 以前に指定された中断動作によって、区切り文字は、動かされるか、または捨てられるでしょう。 (本質的には、MTBはECHO経路を可能にします。)
(5) Delete to Break (DTB). This command directs the TIP to move
characters in sequence from the input buffer and discard
them until a break character is encountered. The break
character will also be discarded. This provides a
convenient mechanism for hiding a user's input. (DTB
(5) 中断まで(DTB)を削除してください。 このコマンドは連続して入力バッファからキャラクタを動かして、区切り文字が遭遇するまで彼らを捨てるようTIPに指示します。 また、区切り文字は捨てられるでしょう。 これはユーザの入力を隠すのに便利なメカニズムを提供します。 (DTB
Davidson [Page 7] RFC 357 An Echoing Strategy For Satellite Links June 1972
衛星中継1972年6月のための反響戦略あたりディヴィッドソン[7ページ]RFC357
enables the DISCARD path.)
DISCARD経路を可能にします。)
Commands: User to Server
コマンド: サーバへのユーザ
The USER may send (via TIP) a request to the server process
requesting that it "Use Remote Controlled Echoing" to which
the server must respond "YES" or "NO".
USERはサーバが「はい」を反応させなければならないそれが「遠隔操作の反響を使用する」よう要求するサーバプロセスに要求を送るかもしれませんか(TIPを通して)、「いいえ。」
General Operation
一般操作
Very simply, the Remote Controlled Echoing strategy works as
follows: The Server TELNET will tell the TIP to (essentially)
非常に単に、Remote Controlled Echoing戦略は以下の通り利きます: Server TELNETはTIPに言うでしょう。(本質的には)
(1) echo a message,
(2) print the process' response to that message,
(3) echo the next message
(4) print the response to that message
. . .
(1) メッセージを反映してください、そして、(2) そのメッセージへの過程の応答を印刷してください、そして、(3) (4)がそのメッセージへの応答を印刷するという次のメッセージを反映してください…
etc., to effect an orderly listing of inputs and responses much as
would be imposed when using a half-duplex device.
など、半二重デバイスを使用するとき、課されるように入力と応答の規則的なリストに作用するように。
The actual interaction depends on the control commands. When a
terminal-serving process is invoked on behalf of a TIP user, the
Server TELNET will send the "Use RCE" command; the TIP will
respond "YES". Then the Server TELNET will send the "Set Break
Action" and "Set Break Classes" commands to properly reflect the
break strategy requested by the terminal-serving process. Lastly
the Server TELNET will send an MTB command. This enables the ECHO
path.
実際の相互作用は制御コマンドによります。 端末に役立つプロセスがTIPユーザを代表して呼び出されるとき、Server TELNETは「RCEを使用してください」というコマンドを送るでしょう。 TIPは「はい」を反応させるでしょう。 次に、Server TELNETは「セット中断動作」を送るでしょう、そして、「セット中断のクラス」は適切に端末に役立つプロセスによって要求された中断戦略を反映すると命令します。 最後に、Server TELNETはMTBコマンドを送るでしょう。 これはECHO経路を可能にします。
The TIP removes characters from the input buffer and places them
in the print buffer. When it encounters a break character, it
performs the break action specified, and enables the OUTPUT path.
TIPは入力バッファからキャラクタを外して、印刷バッファに彼らを置きます。 区切り文字に遭遇すると、それは、動作が指定した中断を実行して、OUTPUT経路を可能にします。
Characters are then moved in sequence from the output buffer to
the print buffer. When an MTB (or, DTB) is encountered, it is
discarded and the ECHO (DISCARD) path is enabled.
そして、キャラクターは連続して出力バッファから印刷バッファまで動かされます。 または、MTBである、(DTB)、遭遇していて、それは捨てられて、ECHO(DISCARD)経路は可能にされます。
Etcetera.
種々のもの。
The Server TELNET may change the break action or break classes
after an interaction, but should normally do so prior to sending
the MTB or DTB commands. It should only send an MTB (DTB) after
all process output from the previous message has been sent.
Server TELNETは中断動作を変えるか、または相互作用の後にクラスを壊すかもしれませんが、MTBかDTBにコマンドを送る前に、通常、そうするはずです。 前のメッセージからのすべてのプロセス出力を送った後にそれはMTB(DTB)を送るだけであるべきです。
Davidson [Page 8] RFC 357 An Echoing Strategy For Satellite Links June 1972
衛星中継1972年6月のための反響戦略あたりディヴィッドソン[8ページ]RFC357
Why Does This Work?
これはなぜ働いていますか?
The RCE strategy described above produces the correct result at
the user's terminal because it is in essence the same scheme used
by the Terminal Handler which normally provides the echoing at the
serving site. Initially, the characters are echoed as they are
typed; then a break character is keyed, echoing is suspended. If
the process produces any output response, it is printed before
echoing of subsequent input.
同じ体系が通常、給仕サイトで反響を提供するTerminal Handlerで使用した本質にはそれがあるので、上で説明されたRCE戦略はユーザの端末に正しい結果を生みます。 初めは、彼らがタイプされるとき、キャラクタは言葉を繰り返されます。 次に、区切り文字が合わせられる、反響は吊しています。 プロセスが何か出力応答を起こすなら、その後の入力をまねる前に、それは印刷されます。
Echoing of the next command begins, if there is type-ahead, with
the characters in the input buffer, and even if the input buffer
is emptied immediate echoing of keyed input from the terminal is
provided since the ECHO path remains enabled up to a break.
次のコマンドの反響は始まります、入力バッファには先のタイプがキャラクタと共にあって、入力バッファを空にしてもECHO経路が中断まで可能にされたままで残っているので端末からの合わせられた入力の即座の反響を提供するなら。
An Example
例
(In the following, we assume all break characters are also wakeup
characters and (carelessly) treat the two interchangeably.)
(以下では、私たちは、また、すべての区切り文字がwakeupキャラクタであると思って、(不注意に)2を互換性を持って扱います。)
Suppose a TIP user attempts to login to a remote server with the
properly formatted message
TIPユーザが、適切にフォーマットされたメッセージでリモートサーバにログインするのを試みると仮定してください。
LOG NAME PASSWORD [CR]
ログ名前パスワード[CR]
and that the Server TELNET has requested the use of RCE.
Presuming that the break (and wakeup) characters sets are
appropriately defined to include space and CR (and that the break
action specifies they should be echoed), the primary sequence of
RCE commands which will drive the TIP to produce the correct
printout at the user's terminal is:
そして、Server TELNETはRCEの使用を要求しました。 中断(そして、wakeup)キャラクタセットがスペースとCRを含むように適切に定義されると推定する、(中断動作が指定する、それらが反響されるべきである、)、正しいプリントアウトをユーザの端末に起こすようにTIPに追い立てるRCEコマンドのプライマリ系列は以下の通りです。
(1) MTB (to print "LOG "), and since the space is a break
character,
(2) MTB (to print "NAME "),
(3) DTB (to delete "PASSWORD [CR]" (See section VI, number
11)), and perhaps a message followed by
(4) MTB (to reenable the echo path).
(1) MTB("LOG"を印刷する)、スペース以来、区切り文字、(2)MTB("NAME"を印刷する)、(3)DTB(「パスワード[CR]」(セクションVIを見てください、No.11)を削除する)、および恐らく(4) MTBによって従われたメッセージ(エコー経路を再可能にする)はそうです。
We investigate in some detail how interaction at the
process/Server TELNET interface causes these commands to be send
to the TIP.
私たちは、プロセス/サーバTELNETインタフェースでの相互作用がどのようにTIPに発信することであるこれらのコマンドを引き起こすかを何らかの詳細に調査します。
When the EXEC is invoked, it issues a system call to set its break
classes. The Server TELNET interprets the system call in terms of
the classes supported by RCE, and sends the appropriate two-byte
"Set Break Classes" (SBC) command to the TIP. A space is among
the characters of the break set.
EXECが呼び出されるとき、それは、中断のクラスを設定するためにシステムコールを発行します。 Server TELNETはRCEによってサポートされたクラスに関してシステムコールを解釈して、適切な2バイトの「セット中断のクラス」(SBC)にTIPへのコマンドを送ります。 スペースは中断セットのキャラクタの中のひとりです。
Davidson [Page 9] RFC 357 An Echoing Strategy For Satellite Links June 1972
衛星中継1972年6月のための反響戦略あたりディヴィッドソン[9ページ]RFC357
The EXEC asks for input, so the Server TELNET send MTB ((1)
above). We presume the EXEC blocks until some input is available.
Server TELNETがMTBを送って、EXECが入力のために((1) 上で尋ねる、) 何らかの入力が利用可能になるまで、私たちはEXECブロックを推定します。
The EXEC is awakened when the first space arrives; it recognizes
the LOG command to be a call upon the LOGIN subsystem which it
(promptly!) invokes.
最初のスペースが到着すると、EXECは目を覚まします。 それは(即座に)!呼び出すLOGINサブシステムで呼び出しであるLOGコマンドを認識します。
The LOGIN process issues a system call to set its break classes
(this time both space and CR are included, and, as before, the
Server TELNET forwards the command as an SBC). Then it asks for
input (so the Server TELNET sends MTB ((2) above)), and blocks
until the second space arrives.
LOGINプロセスは、中断のクラスを設定するためにシステムコールを発行します(今回スペースとCRの両方が含まれています、そして、従来と同様、Server TELNETはSBCとしてコマンドを進めます)。 そして、それは入力(Server TELNETが上のMTB((2)を送って)、および2番目のスペースが到着するまでのブロックを求めます。
When the LOGIN process has verified the existence of a user with
name NAME, it issues a system call to suppress printing of the
next parameter (the password). In compliance, the Server TELNET
sends DTB ((3) above).
LOGINプロセスが名前NAMEと共にユーザの存在について確かめたとき、それは、次のパラメタ(パスワード)の印刷を抑圧するためにシステムコールを発行します。 承諾では、Server TELNETが上のDTB((3)を送る、)
Once the password has been examined and verified, a message like
一度、調べられて、確かめられたパスワード、メッセージは好きです。
[CR][LF] LOGIN COMPLETED [CR][LF]
[CR][LF]ログインの完成した[CR][LF]
can be sent, followed by a request for input. The Server TELNET
thus forwards an MTB ((4) above) and the sequence is completed.
入力に関する要求があとに続いていて、送ることができます。 その結果、Server TELNETが上のMTB((4)を進める、)、系列は完了しています。
Another example
別の例
Suppose in the above example the user had typed
上記の例でユーザがタイプしたと仮定してください。
LOG NAME[CR]
ログ名[CR]
When the LOGIN process regained control, it would have noted that
the break was a CR instead of a space. It then could have issued
LOGINプロセスがコントロールを取り戻したとき、それは、中断がスペースの代わりにCRであることに注意したでしょう。 そして、それは発行されていた状態で持っているかもしれません。
[LF]password =
[LF]パスワード=
which the Server TELNET would follow (when LOGIN requests print
suppression) with DTB. When the TIP had finished its output, the
DISCARD path would be enabled and the user's terminal would have
printed:
Server TELNETはDTBと共に続きます(LOGIN要求が抑圧を印刷するとき)。 TIPが出力を終えたとき、DISCARD経路は可能にされたでしょう、そして、ユーザの端末は印刷したでしょう:
LOG NAME[CR]
password =
^
LOG NAME[CR]パスワード=^
with the cursor positioned just after the =. The TIP will hide
the characters of the password.
カーソルが=のすぐ後に置かれている状態で. TIPはパスワードのキャラクタを隠すでしょう。
Davidson [Page 10] RFC 357 An Echoing Strategy For Satellite Links June 1972
衛星中継1972年6月のための反響戦略あたりディヴィッドソン[10ページ]RFC357
Another Example
別の例
Suppose a user were using a text editor, TEXT, to create a source
file of English sentences. The TEXT subprocess might allow only
non-formatting control characters (e.g., "Control-C") as break
characters. The RCE strategy would allow the user to receive
immediate echoing for all his input until he typed such a control
character.
ユーザが英文に関するソースファイルを作成するのにテキストエディタ、TEXTを使用していたと仮定してください。 TEXTサブプロセスは区切り文字として非形式制御文字(例えば、「コントロールC」)だけを許容するかもしれません。 RCE戦略で、ユーザはそのような制御文字をタイプするまで彼のすべての入力のための即座の反響を受け取ることができるでしょう。
V. Discussion
V。 議論
The Remote Controlled Echoing Strategy is designed to provide echoing for a full-duplex terminal as if it were locally connected to its server. The effect of the long transmission delays will only be evident as an increase in the processing performed at a break. Only in the most interactive systems will such a delay be consistently noticeable. For example if a user invokes a long FORTRAN compilation, the fact that its start is delayed for half a second will not normally be evident.
Remote Controlled Echoing Strategyは、まるでそれが局所的にサーバに接続されるかのように全二重端末に反響しながら提供するように設計されています。単に処理の増加が休み中に働いたので、長いトランスミッション遅れの効果は明白になるでしょう。 最も対話的なシステムだけでは、そのような遅れは一貫してめぼしくなるでしょう。 例えば、ユーザが長いFORTRAN編集を呼び出すと、通常、始めが半分の2番目のために遅れるという事実は明白にならないでしょう。
Furthermore, users who are able to type several messages ahead may only notice a processing delay as a result of the first break- interaction; both transmission and processing of successive messages may occur during the printing of "echoes" and responses to previous messages.
その上、先でいくつかのメッセージをタイプできるユーザは最初中断の相互作用の結果、処理遅れに気付くだけであるかもしれません。 トランスミッションと連続したメッセージの処理の両方が「エコー」と前のメッセージへの応答の印刷の間、起こるかもしれません。
Transmission considerations:
トランスミッション問題:
In the standard echoing scheme, characters are buffered at the
same server as they are keyed. But the user process does not see
them until a wakeup character has been typed. This means a TIP
using RCE could buffer characters in the transmission buffer until
a wakeup occurs and then send off the whole bunch. Unfortunately
we have chosen, for simplicity, to keep all knowledge of wakeup
characters at the serving site. This means that the TIP may
buffer beyond a wakeup (if it is not also a break) and delay the
process from doing some useful work. However, since in this case
no output is expected from the process, no noticeable delay is
visible to the user, except that the next break interaction may
take a little longer.
標準の反響体系では、彼らが合わせられるようにキャラクタは同じサーバでバッファリングされます。 しかし、wakeup文字がタイプされるまで、ユーザ・プロセスはそれらを見ません。 これは、RCEを使用するTIPがwakeupが現れるまでトランスミッションバッファでキャラクタをバッファリングして、次に、たくさんを送ることができたことを意味します。 残念ながら、私たちは、給仕サイトにwakeupキャラクタに関するすべての知識を保つのを簡単さに選びました。 これは、TIPがいくらかの実質的な仕事をするのでwakeup(また、それが中断でないなら)と遅れを超えてプロセスをバッファリングするかもしれないことを意味します。 しかしながら、この場合出力が全くプロセスから予想されないので、ユーザにとって、どんなめぼしい遅れも目に見えません、次の中断相互作用が少し時間がかかるかもしれないのを除いて。
If the TIP chooses to buffer input before transmission, it will
transmit AT LEAST at every break character. The SERVER should be
able to instruct the TIP to transmit more often if it is
appropriate.
TIPが、トランスミッションの前に入力をバッファリングするのを選ぶと、それはすべての区切り文字でAT LEASTを伝えるでしょう。 それが適切であるなら、SERVERは、よりしばしば伝わるようTIPに命令するはずであることができます。
Davidson [Page 11] RFC 357 An Echoing Strategy For Satellite Links June 1972
衛星中継1972年6月のための反響戦略あたりディヴィッドソン[11ページ]RFC357
An Example:
例:
Conversational output LINKING is an example where transmission
strategy is separate from the break and wakeup strategies.
Transmission should occur on every character so that the character
can be promptly printed at each linked terminal, but no break or
wakeup need occur until a special escape character is typed (this
reawakens the EXEC, for example).
会話の出力LINKINGはトランスミッション戦略が中断とwakeup戦略から別々である例です。 トランスミッションがそれぞれの繋がっている端末にもかかわらず、どんな休み中にも即座に文字を印刷できないようにすべてのキャラクタの上に起こるべきですか、または特別な拡張文字がタイプされるまで(例えば、これはEXECに再び目を覚まさせます)、wakeupは現れなければなりません。
Conversational output linking also introduces another funny:
また、会話の出力リンクはおかしい状態で別のものを導入します:
Unsolicited Output:
求められていない出力:
What happens when the ECHO (or DISCARD) path is enabled, but the
input buffer is empty (i.e. immediate echoing is occurring) and
something arrives in the output buffer? This "something" cannot be
a response to a previously keyed command, or the ECHO path would
be disabled. (This proof is left to the reader!) It is most likely
a system message like
ECHO(または、DISCARD)経路が可能にされますが、入力バッファが空であり(すなわち、即座の反響は発生です)、何かが出力バッファに到着すると、何が起こりますか? この「何か」は以前に合わせられたコマンドへの応答であるはずがありませんかECHO経路が無効にされるでしょう。 (この証拠は読者に任せます!) それはたぶんaシステムメッセージ同様です。
[CR][LF]SYSTEM WILL GO DOWN IN 5 MINUTES[CR][LF]
[CR][LF]システムは5分[CR]後に落ちるでしょう。[LF]
or, a character arriving from another linked terminal.
または、別のものから到着するキャラクタは端末をリンクしました。
Since such output does not fit neatly into our RCE scheme, the
following kludge is proposed. Unsolicited output should cause the
OUTPUT path to be enabled. The occurrence of either an MTB (DTB)
Or Empty Output Buffer will reenable the ECHO (DISCARD) path.
そのような出力が私たちのRCE体系にきちんと収まらないので、以下のクラッジは提案されます。 求められていない出力で、OUTPUT経路を可能にするべきです。 MTB(DTB)かEmpty Output Bufferのどちらかの発生はECHO(DISCARD)経路を再可能にするでしょう。
IV. Orthogonal Issues
IV。 直交した問題
Several other mechanisms may reasonably be incorporated within this proposed addition to TELNET. The problems which need some further discussion include:
他の数個のメカニズムがTELNETへのこの提案された追加の中に合理的に組み込んでいるかもしれません。 何らかのさらなる議論を必要とする問題は:
1) Some means should be provided for the server to clear the
input, transmission, print and output buffers.
2) Some means should be provided for the user to immediately
clear the output buffer (i.e. suppress printing of lengthy
output).
3) The server may want to ask about the number of characters
remaining to be printed.
4) A special tag character may be required to note where
clearing of the input buffer occurred.
5) The TIP's transmission strategy should be specifiable by
the server; perhaps a "Set Wakeup Classes" command should
be implemented.
1) サーバが入力、トランスミッション、印刷、および出力バッファをきれいにするように、いくつかの手段を提供するべきです。 2) ユーザがすぐに出力バッファをきれいにするように、いくつかの手段を提供するべきです(すなわち、長い出力の印刷を抑圧してください)。 3) サーバは印刷されるために残っているキャラクタのおよそ数を尋ねたがっているかもしれません。 4) 特別なタグキャラクタが、入力バッファをきれいにするのがどこに起こったかに注意するのに必要であるかもしれません。 5) TIPのトランスミッション戦略はサーバで明記できるべきです。 恐らく、「Wakeupのクラスを設定してください」というコマンドは実装されるべきです。
Davidson [Page 12] RFC 357 An Echoing Strategy For Satellite Links June 1972
衛星中継1972年6月のための反響戦略あたりディヴィッドソン[12ページ]RFC357
6) The server should be able to cause the TIP to break on the
n-th input character regardless of whatever a break
character has been encountered.
7) Should the TIP or the server be responsible for properly
echoing a formatting control character such as a TAB?
8) The proper equivalence classes of ASCII characters have to
be finalized.
9) How should a CR be echoed?
10) Should one-for-one echo replacement (e.g. "$" for ESC) or
multi-character substitution (e.g. "^A" for Control-A) be
provided by the TIP?
11) The proposed DTB command directs the TIP to also discard
the delimiting break character. Should the break character
discard rather be dependent on setting the Break Action to
"don't echo" before sending the DTB?
6) サーバは、TIPが区切り文字がことなら何でもであるかにかかわらずn番目の入力キャラクタの上で遭遇しているのに壊れることを引き起こすことができるべきです。 7) TIPかサーバが適切にTABなどの形式制御文字を反映するのに原因となるべきですか? 8) 適切な同値類のASCII文字は成立させられなければなりません。 9) CRはどのように反響されるべきですか? 10) 「個人的には交換(例えば、ESCの「$」)かマルチキャラクタ代替をまねるべきである、(」 例えば、^A」、コントロールa)、チップを提供しましたか? 11) 提案されたDTBコマンドは、また、区切っている区切り文字を捨てるようTIPに指示します。 Break ActionにDTBを送る前に「反響しない」ように設定するのに区切り文字破棄はむしろ依存しているべきですか?
Several of these issues will be addressed in RFC 358.
これらのいくつかの問題がRFC358で扱われるでしょう。
VII. Conclusion
VII。 結論
This document has presented a proposed optional addition to the User TELNET. The next step is to perform some simulations and to incorporate RCE into an experimental version of TELNET.
このドキュメントは提案された任意の追加をUser TELNETに提示しました。 次のステップは、いくつかのシミュレーションを実行して、TELNETの実験バージョンにRCEを組み入れることです。
No recommendation is made that the current TELNET be discarded. For example RCE should not be used for those half-duplex devices which perform their own "echoing". If RCE is adopted as an alternate means of echoing, changes to those TELNETs choosing not to implement it should be minimal. Switching from RCE to the current echo mechanism is an immediate result of either user or server sending a "You Echo" (or "I'll Echo").
現在のTELNETが捨てられるという推薦状を全くしません。 それら自身の「反響」を実行するそれらの半二重デバイスに例えばRCEを使用するべきではありません。 RCEが反響する代替の手段として採用されるなら、それを実装しないのを選ぶそれらのTELNETsへの変化は最小限であるべきです。 RCEから現在のエコーメカニズムに切り替わって、ユーザかサーバのどちらかがaを送るという即座の結果は「あなたは反響する」(「私は反響する」)ですか?
Much of the machinery required to implement RCE already exists at the interface between the server process and its Terminal Handler or Server TELNET. This means that no server process need be changed, but that the process' means of specifying break classes, break actions and echoing conventions must be interpreted by the Terminal Handler and reissued to the TIP in terms of the corresponding RCE commands.
RCEを実装するのに必要である機械の多くがそのサーバプロセスとTerminal HandlerかServer TELNETとのインタフェースに既に存在しています。 これは、対応するRCEコマンドで過程の中断のクラスを指定する手段と、中断動作とコンベンションを反響するのをサーバプロセスを全く変える必要はありませんが、Terminal Handlerが解釈して、TIPに再発行しなければならないことを意味します。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Erik J. Verbruggen 12/97 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ エリック・J.フェアブルッヘン12/97によるオンラインRFCアーカイブに]
Davidson [Page 13]
ディヴィッドソン[13ページ]
一覧
スポンサーリンク
