RFC596 日本語訳
0596 Second thoughts on Telnet Go-Ahead. E.A. Taft. December 1973. (Format: TXT=11919 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Taft Request for Comments: 596 PARC-MAXC NIC: 15372 8 December 1973
コメントを求めるワーキンググループE.タフトの要求をネットワークでつないでください: 596PARC-MAXC NIC: 15372 1973年12月8日
Second Thoughts on Telnet Go-Ahead
telnet開始許可に関する考え直し
INTRODUCTION
序論
In this RFC we present objections to the requirement that hosts implement the Telnet Go-Ahead (GA) command, as specified in the Telnet Protocol Specification (NIC #15372). The thrust of these objections is in three major directions:
このRFCでは、私たちはホストが、先のTelnet Go(ジョージア)がコマンドであると実装するという要件に反論を提示します、テルネット・プロトコルSpecification(NIC#15372)で指定されるように。 3つの主要な方向にはこれらの反論の突きがあります:
1. The GA mechanism is esthetically unappealing, both to myself and to many other people I have talked to. I shall attempt to describe why this is so.
1. ジョージアメカニズムは自分と、そして、私が話した多くの他の人々に美的に非上告されています。 私は、これがなぜそうであるかを説明するのを試みるつもりです。
2. As specified in the Protocol, GA will not, in general, work; i.e. it will not serve its intended purpose unless hosts make various unwarranted assumptions about how other hosts operate.
2. プロトコルで指定されるように、一般に、ジョージアは働かないでしょう。 ホストが他のホストがどう働くかに関する様々な根拠のない推定をしないと、すなわち、それは本来の目的に役立たないでしょう。
3. GA is impossible for most hosts to implement correctly in all cases. This is certainly true of the PDP-10 operating systems with which I am familiar (10/50 and Tenex).
3. ほとんどのホストにとって、ジョージアはすべての場合で正しく実装するのが不可能です。 確かに、これは私が詳しいPDP-10オペレーティングシステム(10/50とTenex)に関して本当です。
The purpose of this RFC is to advocate either complete removal of the GA mechanism or relegating it to the status of a negotiated option whose default state is that it be suppressed.
このRFCの目的はデフォルト状態がそれが抑圧されるということである交渉されたオプションの状態にジョージアメカニズムかそれを左遷する完全な取り外しを支持することです。
TERMINOLOGY
用語
"Half-duplex" is a two-way communication discipline in which transmission takes place in only one direction at a time and the receiving party is constrained not to transmit until the transmitting party has explicitly given up control of the communication path ("turned the line around").
「半二重」はトランスミッションが一度に一方向だけに行われる双方向通信規律です、そして、伝えるパーティーが明らかに通信路(「系列を変える」)のコントロールをやめるまで受領者が伝わらないのが抑制されます。
This definition is distinct from a common (but incorrect) use of the terms "half-duplex" and "full-duplex" to designate local and remote character echoing.
この定義は地方の、そして、リモートなキャラクタ反響を指定する「半二重」と「全二重」という用語の一般的で(不正確)の使用と異なっています。
"Reverse break" is a means by which a computer connected to a terminal by a half-duplex path may regain control of the path for further typeout after previously having relinquished it.
「逆の中断」はそれを放棄して、半二重経路によって端末に接続されたコンピュータが以前に後に一層のtypeoutのために経路のコントロールを取り戻すかもしれない手段です。
Taft [Page 1] RFC 596 Second Thoughts on Telnet Go-Ahead December 1973
進行命令のtelnet1973年12月に関するタフト[1ページ]RFC596考え直し
This is the complement of the "break" or "attention" mechanism, implemented by all half-duplex terminals, by means of which the user may gain control of the line while it is in use by the computer.
これはすべての半二重端末によって実装された「中断」か「注意」メカニズムによってそれがコンピュータで使用中である間、ユーザが系列のコントロールを獲得するかもしれない補数です。
ESTHETIC OBJECTIONS TO GA
ジョージアへの美的な反論
One assumption that permeates the Telnet Protocol specification (and is explicitly stated on Page 7) is that the "normal" mode of communication between computers and terminals is half-duplex, line- at-a-time. While historically this is partially true, it is also clear, both within the ARPA Network community and elsewhere, that the trend is toward highly interactive man-machine communication systems which are difficult to implement under half-duplex communication disciplines.
テルネット・プロトコル仕様(そして、7ページに明らかに述べられている)を普及させる1つの仮定はコンピュータと端末とのコミュニケーションの「正常な」モードが半二重であるということであり、時間で立ち並んでください。 これは歴史的に部分的に本当ですが、傾向が半二重通信規律の下で実装するのが難しい非常に対話的な人間-機械通信システムに向かうのは、また、アーパネット共同体以内とほかの場所でクリアすることです。
The GA mechanism is an attempt to solve a specific problem, that of switching control between computer and user in a subset of those hosts utilizing IBM 2741 or equivalent terminals. I say "a subset" because in fact the problem arises only in the case of TIPs from 2741s (with reverse break); from what experience I have had, I think the TIP does a very good job of turning the line around at the right moments. (I am told this is also the case at Multics).
ジョージアメカニズムは特定の問題を解決する試みです、コンピュータとユーザの間のそれらのホストの部分集合における切換制御のものがIBM2741か同等な端末を利用して。 事実上、問題が2741年代(逆の中断がある)からTIPsの場合だけで起こるので、私は「部分集合」を言います。 どんな経験を持ったかから、私は、TIPが正しい瞬間に系列を変える非常に良い仕事をすると思います。 (私はまた、これがMulticsのそうであると言われます。)
Given the trend toward more interactive communication, and given the fact that terminals on the Network requiring a Go-Ahead mechanism are a distinct minority of all terminals, I think we should be reluctant to burden our protocols with kludges that are so clearly a concession to obsolete design.
先のGoメカニズムを必要とするNetworkの上の端末がすべての端末の明白な少数派であるという事実をより対話的なコミュニケーションに向かった傾向を与えて、考えて、私は、私たちがそれほど明確にデザインを時代遅れにする譲歩であるクラッジで私たちのプロトコルを負担するのに気が重いはずであると思います。
I have little doubt that before long somebody (if not IBM) will produce a full-duplex 2741-like terminal (indeed, perhaps it has already been done). There is an obvious need for a terminal with Selectric quality keyboard and hard-copy better suited to interactive applications (i.e. full-duplex).
私には、間もなくだれか(まして、IBM)が全二重の2741のような端末を作り出すという(本当に、恐らく、既にそれをしました)疑問がほとんどありません。 端末の明白な必要がSelectricの上質のキーボードと対話型アプリケーションに合うほうがよかったハードコピー(すなわち、全二重)と共にあります。
As a more practical consideration, it makes little sense to have the default state of the GA option be the one that benefits the least number of hosts and terminals.
より実用的な考慮として、それはほとんどジョージアオプションのデフォルト事情が利益を得るものであることを持つ意味をホストと端末の最少の数にしません。
There is no question that most parties to Telnet communication will immediately negotiate to suppress GA. To do otherwise will double the amount of network traffic generated by character-at-a- time typein, and will increase it by a non-negligible amount even for a line-at-a-time typein.
Telnetコミュニケーションへのほとんどのパーティーが、すぐにジョージアを抑圧するのを交渉するという疑問が全くありません。 別の方法でするのはキャラクタによって生成されたネットワークトラフィックの量を倍にするでしょう。-a-時に、非ごく小額に従って一度に系列typeinのためにさえそれを増強するためにtypeinして、望んでください。
It strikes me as worthwhile to minimize the number of such "necessary" option negotiations, especially in view of the large number of TIPs and mini-hosts on the Network. Many such hosts
それはそのような「必要な」オプション交渉の数を最小にするために価値があるように私に感じます、特にNetworkの上の多くのTIPsとミニホストから見て。 多くのそのようなホスト
Taft [Page 2] RFC 596 Second Thoughts on Telnet Go-Ahead December 1973
進行命令のtelnet1973年12月に関するタフト[2ページ]RFC596考え直し
must, due to resource constraints, implement only a limited subset of the available options. It follows, then, that the default state of all options should be the one most hosts will be willing to use.
リソース規制のため利用可能なオプションの限られた部分集合だけを実装しなければなりません。 そして、すべてのオプションのデフォルト事情がほとんどのホストが使用しても構わないと思うものであるべきであるということになります。
WHY GA WON'T WORK
ジョージアが働いていない理由
We now show that a server process's being "blocked on input" (as specified in the Protocol) is not itself a sufficient condition for sending out GA.
私たちは、現在、「入力のときに妨げられる」(プロトコルで指定されるように)サーバの過程のsがそれ自体でジョージアを出すための十分条件でないことを示します。
This is due to the fact that the user Telnet has no control over the packaging of a "line" of information sent to the server; rather, this is a function of the NCP, which must observe constraints such as allocation and buffering. Consider the following example:
これはユーザTelnetがサーバに送られた情報の「系列」のパッケージを管理しないという事実のためです。 むしろ、これはNCPの機能です。(それは、配分やバッファリングなどの規制を観測しなければなりません)。 以下の例を考えてください:
A user types a line of text, which is buffered by his host's user Telnet until he signals end-of-line. His keyboard then becomes locked (this being the behavior of half-duplex terminals while the computer has control of the line), and stays locked in anticipation of the server's eventual response and subsequent GA command.
ユーザはテキスト行をタイプします。(彼が行末に合図するまで、それは、彼のホストのユーザTelnetによってバッファリングされます)。 彼のキーボードは、次に、ロックされるようになって(コンピュータが系列を管理する間、これが半二重端末の動きであり)、サーバの最後の応答とその後のジョージアコマンドを予測してロックされていた状態で残っています。
The user Telnet transmits this text line over the connection; however, due to insufficient allocation or other conditions, the text actually gets packaged up and sent as two or more separate messages, which arrive at the server host in the correct order but separated by some amount of time.
ユーザTelnetはこのテキスト台詞を接続の上に伝えます。 しかしながら、テキストは、不十分な配分か他の状態のため、いつかの時間で実際にパッケージさせて、2以上が正しいオーダーにおけるサーバー・ホストに到着するメッセージを切り離すので発信しましたが、分離しました。
The server Telnet passes the contents of the first message to the appropriate process, which reads the partial text line and immediately blocks for further input. At this moment (assuming the second message hasn't arrived yet), the server telnet, in accordance with the Protocol, sends back a GA command.
サーバTelnetは最初のメッセージのコンテンツを適切なプロセスに通過します。部分的なテキストは、さらなる入力のためにその読書を裏打ちして、すぐに、妨げます。 この瞬間(2番目のメッセージがまだ到着していないと仮定する)、プロトコルによると、サーバtelnetはジョージアコマンドを返送します。
The rest of the text then arrives in response, the server process may generate a large volume of output. Meanwhile, however, the GA command has caused the user's keyboard to become unlocked and computer output thereby blocked. Hence we have a deadlock, which will be resolved only when the user recognizes what has happened and (manually) gives control back to the computer.
次に、テキストの残りは応答に到達して、サーバプロセスは多くの出力を生成するかもしれません。 その間、しかしながら、ジョージアコマンドはアンロックされるようになるユーザのキーボードとその結果妨げられたコンピュータ出力を引き起こしました。 したがって、私たちには、行き詰まりがあります。(それは、ユーザが起こったことを認める場合にだけ決議されて、(手動で)コントロールをコンピュータに返します)。
Of course, this particular problem is avoided if the Telnet protocol is modified to specify that the server Telnet will transmit GA only if the server process is blocked for input AND the most recent character passed to that process was end-of-line.
もちろん、Telnetプロトコルがサーバプロセスがそのプロセスに通過された入力と最新のキャラクタのために妨げられる場合にだけサーバTelnetがジョージアを伝えると指定するように変更されているのが、行末であったということであるなら、この特定の問題は避けられます。
Taft [Page 3] RFC 596 Second Thoughts on Telnet Go-Ahead December 1973
進行命令のtelnet1973年12月に関するタフト[3ページ]RFC596考え直し
I claim that this solution is bad in principle because it assumes too much knowledge on the part of the serving host as to what constitutes "end-of-line" in the using host.
私は、使用しているホストで「行末」を構成することに関する給仕のホスト側のあまりに多くの知識を仮定するのでこのソリューションが原則として悪いと主張します。
Furthermore, the Protocol explicitly (and quite rightly) specifies that the user Telnet should provide some means by which a user may signal that all buffered text should be transmitted immediately, without its being terminated by end-of-line.
その上、プロトコルは、ユーザTelnetがユーザが、すべてのバッファリングされたテキストがすぐに存在なしで行末によって終えられた状態で伝えられるべきであると合図するかもしれないいくつかの手段を提供するはずであると明らかに指定します(全く正しい)。
One must conclude, then, that in general the server Telnet has no precise way of knowing when it should send GA commands.
そして、一般に、サーバTelnetにはそれがいつジョージアコマンドを送るべきであるかを知るどんな正確な方法もないと結論を下さなければなりません。
IMPLEMENTATION PROBLEMS
実装問題
The foregoing analysis illustrates the problems that arise with the GA mechanism in communication between servers and users whose normal mode of operation is half-duplex, line-at-a-time. When we turn to hosts that provide full-duplex service, such as the PDP-10s and many other hosts on the Network, the problems are much more severe.
以上の分析は正常な運転モードが半二重であるサーバとユーザとのコミュニケーションでジョージアメカニズムを起こる問題に入れます、時間の系列。 私たちが全二重サービスを提供するNetworkの上の10PDP-年代や多くの他のホストなどのホストに頼るとき、問題ははるかに厳しいです。
This is particularly true of operating system such as Tenex that exercise such tight control over terminal behavior that they prefer to operate in server echoing, character-at-a-time mode. This will probably become less necessary as protocols such as Remote Controlled transmission and Echoing Option come into general use, enabling servers to regulate echoing and break character classes in user Telnets.
これはサーバ反響(一度にキャラクタモード)で端末の振舞いの上の彼らが、作動するのを好むくらいの厳格な管理を運動させるTenexなどのオペレーティングシステムに関して特に本当です。 Remote ControlledトランスミッションやEchoing Optionなどのプロトコルが一般的使用に入るのに応じて、これはたぶんより必要でなくなるでしょう、サーバがユーザTelnetsで反響を規制して、文字クラスを壊すのを可能にして。
Even in hosts such as 10/50 systems that provide reasonable service to line-at-a-time users for most subsystems (e.g. excluding DDT and TECO), GA is impossible to implement correctly. This is true for several reasons.
ほとんどのサブシステム(例えば、DDTとTECOを除いた)に一度に系列ユーザに対する手頃なサービスを提供する10/50台のシステムなどのホストでさえ、ジョージアは正しく実装するのが不可能です。 これはいくつかの理由で本当です。
First, there are a number of subsystems that never block for terminal input but rather poll for it or accept it on an interrupt basis. In the absence of typein, such processes go on to do other tasks, possibly generating terminal output.
まず最初に、端末の入力のために妨げますが、それのためにむしろ決して投票しない多くのサブシステムがあるか、または中断ベースでそれを受け入れてください。 typeinがないとき、ことによると期末生産高を生成して、そのようなプロセスは、他のタスクを果たし続けます。
Processes of this sort come immediately to mind. The user telnet, FTP, and RJE programs are implemented in this fashion by almost all hosts. 10/50 has a subsystem called OPSER, used to control multiple independent subjobs from a single terminal.
この種類のプロセスはすぐに、思い浮かびます。 ユーザtelnet、FTP、およびRJEプログラムはこんなやり方でほとんどすべてのホストによって実装されます。 10/50には、単一の端末から複数の独立している副仕事を制御するのに使用されるOPSERと呼ばれるサブシステムがあります。
Since these programs never block for input, GA commands will never be sent by the server Telnet in such cases even though the processes are prepared to accept terminal input at any time.
以来、プロセスはいつでも端末の入力を受け入れるようにそのような場合準備されますが、これらのプログラムはサーバTelnetによって決して送られないでしょう入力のためのブロック、ジョージアが、命令する。
Taft [Page 4] RFC 596 Second Thoughts on Telnet Go-Ahead December 1973
進行命令のtelnet1973年12月に関するタフト[4ページ]RFC596考え直し
Second, there is not necessarily a one-to-one relationship between processes and terminals, as seems to be assumed by the Telnet Protocol specification.
2番目に、プロセスと端末の間には、1〜1つの関係が必ずないあります、テルネット・プロトコル仕様によって想定されるように思えるように。
For example, in Tenex one process may be blocked for terminal input while another process is generating output to the same terminal. (Such processes are typically parallel forks of the same job).
例えば、Tenex1では、別のプロセスが同じ端末に出力を生成している間、プロセスは端末の入力のために妨げられるかもしれません。 (そのようなプロセスは同じ仕事の通常平行なフォークです。)
Third, there is the possibility of inter-terminal links, such as are provided in many systems.
3番目に、多くのシステムに供給するような相互端末リンクの可能性があります。
By this I do not mean special Telnet connections established between a pair of NVTs for the express purpose of terminal-to- terminal communication, as is suggested on page 9 of the Protocol specification. Rather, I am referring to facilities such as the Tenex LINK facility, in which any number and any mixture of local and Network terminals and processes may have their input and output streams linked together in arbitrarily complex ways. Clearly the GA mechanism will fall flat on its face in this case.
これで、私は端末から端末へのコミュニケーションのそのままなはっきりとした目的のために1組のNVTsの間で9つのプロトコル仕様ページに示された状態で確立された特別なTelnet接続を言っていません。 むしろ、私はTenex LINK施設などの施設について言及しています。(地方とNetwork端末とプロセスのどんな数とどんな混合物でも、そこでは、任意に複雑な方法で彼らの入力と出力ストリームを結びつけるかもしれません)。 明確に、ジョージアメカニズムはうつむけにこの場合受けが良くないでしょう。
Also, the notion that one user of an inter-terminal link should have to "manually signal that it is time for a GA to be sent over the Telnet connection" in order to unblock another user's keyboard offends me to no end.
また、相互端末リンクのあるユーザが別のユーザのキーボードを「非-妨げ」るために「手動で、ジョージアがもうTelnet接続の上に送られるべき時間であると合図しなければならないはずである」という概念は私を徒労に終わって怒らせます。
Finally, most systems provide means by which system personnel and processes may broadcast important messages to all terminals (e.g. SEND ALL in 10/50, NOTIFY in Tenex). Clearly such asynchronous messages will be blocked by a half-duplex terminal that has been irrevocably placed in the typein state by a previous GA.
最終的に、ほとんどのシステムがシステム人員とプロセスがすべての端末(例えば、10/50におけるSEND ALL、TenexのNOTIFY)に重要なメッセージを放送するかもしれない手段を提供します。 明確に、そのような非同期なメッセージは前のジョージアによって取消不能にtypein状態に置かれた半二重端末によって妨げられるでしょう。
This strikes me as such an obvious problem that I am forced to wonder how half-duplex hosts handle it even for their local terminals.
これは私が、半二重ホストが彼らのローカル・ターミナルのためにさえどのようにそれを扱うかとやむを得ず思うほど明白な問題と私に感じます。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Mirsad Todorovac 5/98 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Mirsad Todorovac5/98によるオンラインRFCアーカイブへの]
Taft [Page 5]
タフト[5ページ]
一覧
スポンサーリンク