RFC103 日本語訳
0103 Implementation of Interrupt Keys. R.B. Kalin. February 1971. (Format: TXT=7592 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
NWG RFC 103 NIC 5764
NWG RFC103NIC5764
IMPLEMENTATION OF INTERRUPT KEYS
中断キーの実装
R B Kalin MIT Lincoln Laboratory 24 Feb 1971
R B Kalin MITリンカーン研究所1971年2月24日
The current protocol specifications contain a serious logical error in the implementation of the program interrupt function. This paper discusses the problem and offers a solution that is simple to implement.
現在のプロトコル仕様はプログラム中断機能の実装における重大な論理的な誤りを含んでいます。 この論文は、問題について議論して、実装するのが簡単なソリューションを提供します。
THE PROBLEM
問題
As found on most time-sharing systems the program interrupt key, elsewhere known as the break key, or help request button, has two functions. It suspends temporarily the user process being run, and it switches the keyboard input stream to a dormant supervisory process. Unaccepted input typed prior to the interrupt request remains buffered for the suspended user process. Subsequent typing is sent to a supervisory routine.
ほとんどの時分割システムの上で見つけられるように、中断キー、またはヘルプ要求ボタンとしてほかの場所で知られているプログラム中断キーには2つの機能があります。 それは実行されるユーザ・プロセスを一時中断させます、そして、眠っている管理のプロセスにキーボード入力ストリームを切り換えます。 割り込み要求の前にタイプされたUnaccepted入力は吊したユーザ・プロセスのためにバッファリングされたままで残っています。 その後のタイプを管理のルーチンに送ります。
The current NCP protocol implements only half this function. It pprovides, through use of INS and INR control messages, for the suspension of a remote process, but it offers no mechanism for notifying the remote host at what time the data stream should be switched. INR and INS messages are sent via the control link and because messages on this link travel concurrently with those on the user's keyboard input link, the receiving host can not rely on relative arrival times as a source of synchronizing information. Without such information the remote NCP can not know which input characters are meant for the user process and which are meant for the supervisory routine.
現在のNCPプロトコルは、唯一の半分がこの機能であると実装します。 INSの使用とリモートプロセスのサスペンションへのINRコントロールメッセージを通してpprovidesしますが、それは、データ・ストリームが切り換えられるべきである何時でリモートホストに通知するかためにメカニズムを全く提供しません。 コントロールリンクを通してINRとINSメッセージを送ります、そして、このリンクに関するメッセージが同時にユーザのキーボード入力リンクの上にそれらとともに旅するので、受信ホストは相対的な到着時間に連動情報の源として当てにすることができません。 そのような情報がなければ、リモートNCPはどの入力キャラクタがユーザ・プロセスのために意味されるか、そして、どれが管理のルーチンのために意味されるかを知ることができません。
A solution found on some systems to this problem is that of mapping the interrupt signal into some code from the character set -- typically an ASCII control-C. Unfortunately, this is not general enough to be used within the ARPA network. Some systems, eg. MULTICS, make use of all available ASCII codes for other purposes, none are available for such an assignment. Even if such an assignment could be made, there is the problem of getting the interrupt character to be recognized by the remote host. Buffers on that user link may be full and the sending host may be unable to transmit the message containing
いくつかのシステムの上でこの問題に見つけられたソリューションは割り込み信号を文字集合から何らかのコードに写像するものです--通常ASCIIコントロールC。 残念ながら、これはARPAネットワークの中で使用されているくらいには一般的ではありません。 いくつかのシステム(例えば、MULTICS)が他の目的にすべての利用可能なASCIIコードを利用して、なにもそのような課題に利用可能ではありません。 そのような課題をすることができても、リモートホストに中断キャラクタを認めさせるという問題があります。 そのユーザリンクの上のバッファは完全であるかもしれません、そして、送付ホストはメッセージ含有を伝えることができないかもしれません。
Crocker [Page 1] RFC 103 Implementation of Interrupt Keys February 1971
中断キー1971年2月のクロッカー[1ページ]RFC103実装
the interrupt code. If the remote user process loops without accepting data, there is the possibility that its input buffers will never become free and that the message will never get through.
中断コード。 リモート・ユーザープロセスがデータを受け入れないで輪にされるなら、入力バッファが自由に決してならないで、またメッセージが決して通らない可能性があります。
A partial answer is that of providing at the serving end a teletype scanner process that is always hungry for input. Because all input messages are immediately consumed, buffers remain available and interrupt codes can get through. Unfortunately, this implies that at times characters must be thrown away. After being scanned there may be no buffer space available for them. While not critical during console interactions -- users can type only when the program demands input -- this defect prevents the scanner from being driven from a text file.
部分的な答えは給仕終わりにいつも入力に飢えているテレタイプスキャナプロセスを提供するものです。 すべての入力メッセージがすぐに消費されるので、バッファは利用可能なままで残っています、そして、中断コードは通ることができます。 残念ながら、これは、時にはキャラクタを無駄にしなければならないのを含意します。 スキャンされた後に、それらに利用可能などんなバッファ領域もないかもしれません。 プログラムが入力を要求するときだけ、ユーザがタイプできるというコンソール相互作用の間重要ではありませんが、この欠陥は、スキャナがテキストファイルから動かされるのを防ぎます。
A SOLUTION
ソリューション
The following defines a solution to this problem for the case of ASCII data streams.
以下はASCIIデータ・ストリームのケースのためにこの問題とソリューションを定義します。
1) Character messages should use eight bit fields for each character code.
1) キャラクターメッセージはそれぞれのキャラクタコードに8ビットの分野を使用するべきです。
2) For all of the defined ASCII character codes the left most bit in the eight bit field shall be zero.
2) 8ビットの分野で最も噛み付かれた左は定義されたASCII文字コードのすべてに関しては、ゼロになるでしょう。
3) An interrupt sync character ( arbitrarilly given the code octal 200 ) should be placed in the data stream at the correct point in the typing sequence.
3) 中断同時性キャラクタ(arbitrarillyに、8進200をコードに与える)はタイプ系列で正しいポイントでのデータ・ストリームに置かれるべきです。
4) All codes from octal 201 to octal 377 are officially to be ignored by a receiving host. Their use is reserved for additional control information, should it become necessary. Attempts to use them as additional character codes will meet with resistance from PDP-10 systems that internally pack characters into seven bit fields. Note that this objection can not be made against the interrupt sync character because it is filtered out by the system and never appears in a user's input buffer.
4) すべての8進201から8進377までのコードは受信ホストによって公式に無視されることです。 必要になるなら、彼らの使用は追加制御情報のために控えられます。 添字コードがPDP-10システムから抵抗にそんなに内部的にあうときそれらを使用する試みは7ビットの分野にキャラクタに詰め込みます。 システムによって無視されて、ユーザの入力バッファに決して現れないので中断同時性キャラクタに対してこの異論を作ることができないことに注意してください。
5) Because of the possibility that there may be an insufficient allocation to allow the user message containing the interrupt sync character to be sent, the INR/INS mechanism currently defined must be kept. An INS control message should be sent at the time an interrupt sync character is entered into a text stream. Upon its reception by the foreign host, the attached process should be immediately suspended and the associated input stream should be scanned. If possible, all input up to the interrupt sync character should be buffered for the suspended process. Once the sync character is found, the stream
5) 中断同時性キャラクタを含むユーザメッセージが送られるのを許す不十分な配分があるかもしれない可能性のために、現在定義されているINR/INSメカニズムを保たなければなりません。 中断同時性キャラクタをテキストストリームに入れるとき、INSコントロールメッセージを送るべきです。 異種宿主によるレセプションに、付属プロセスはすぐに中断するべきです、そして、関連入力ストリームはスキャンされるべきです。 できれば、中断同時性キャラクタまでのすべての入力が吊したプロセスのためにバッファリングされるべきです。 一度、同時性キャラクタが見つけられる、ストリーム
Crocker [Page 2] RFC 103 Implementation of Interrupt Keys February 1971
中断キー1971年2月のクロッカー[2ページ]RFC103実装
should be switched to the newly activated supervisory process. If it is not possible to buffer all of the user process's input, it can be thrown away, and a error message returned to the user by the supervisory process. In either event it must be guaranteed that outstanding input will be consumed and message buffers will be freed so that pending character messages can be sent.
新たに動かされた管理のプロセスに切り換えられるべきです。 ユーザ・プロセスsの入力のすべてをバッファリングするのが可能でないなら、それを捨てることができました、そして、エラーメッセージは管理のプロセスでユーザに戻りました。 どっちみち、未定のキャラクタメッセージを送ることができるように傑出している入力が消費されて、メッセージ・バッファが解放されるのを保証しなければなりません。
6) In the event that an interrupt sync character is received before the matching INS, the user process should be suspended and the NCP should wait for the INS before proceeding.
6) 中断同時性キャラクタを合っているINSの前に受け取る場合、ユーザ・プロセスを中断させるべきです、そして、NCPは進行の前にINSを待つべきです。
7) The function of the NCP is the above discussion can, of course, be delegated a separate modulo, eg. a TELNET process. If this is done, the NCP can be transparent to message content.
7) NCPの機能は上の議論がもちろん代表として派遣されたa別々の法であるかもしれない(例えば、TELNETプロセス)ということです。 これが完了しているなら、NCPはメッセージ内容に見え透いている場合があります。
COMMENTARY
論評
The proposed change to the second level protocol described herein is not meant as a general solution, but rather as a specific patch to the current NCP design with the intent of correcting a critical error. Its more obvious deficiencies are...
ここに説明された2番目の平らなプロトコルへの変更案は一般解として意味されるのではなく、むしろ重要な誤りを修正する意図を伴う現在のNCPデザインへの特定のパッチとして意味されます。 より明白な欠乏はそうです…
1) It only works with seven bit code character streams. No extensions are allowed for EBCDIC, ASCII-8, or other large character sets. No provision is made for interrupting a process to which there is no character stream, although the author knows of no case in which the concept means more than closing the connection.
1) それは7つのビット・コードキャラクタストリームで働いているだけです。拡大は全くEBCDIC、ASCII-8、または他の大きい文字集合のために許されていません。 キャラクタストリームが全くないプロセスを中断するのに備えます、作者は概念が接続を終えるより以上を意味する場合を全く知りませんが。
2) It requires the system to scan all data coming over an interruptable connection. Presumably this means that at the time the connection is created, the receiving host must be told that this scan is to be done. Various techniques, both implicit and explicit, could be used.
2) 中断可能接続を襲うすべてのデータをスキャンするのがシステムを必要とします。 おそらく、これは、接続が創造されるときこのスキャンがすることであると受信ホストを言わなければならないことを意味します。 様々な暗黙の、そして、かつ明白なテクニックは、使用できました。
3) The technique is not immune to loss character boundaries within a message nor can it tolerate INS control messages that do not have matching sync characters, or vis versa.
3) テクニックはメッセージの中の損失文字境界に免疫ではありません、そして、それは合っている同時性のキャラクタ、またはvis versaを持っていないINSコントロールメッセージを許容できません。
4) It may not possible to get either the INS or the text message containing the interrupt sync character to a remote host. Possible reasons include user console failure, local host failure, network failure, blocked control link, insufficient allocation etc. Under such circumstances the remote process may loop indefinitely.
4) それは可能であるかもしれません。リモートホストへの中断同時性キャラクタを含んでいて、INSかテキストメッセージのどちらかを手に入れるのにおいて、可能ではありません。 可能な理由はユーザコンソール障害を含んで、ローカル・ホスト失敗(ネットワーク失敗)は不十分なコントロール配分リンクなどを妨げました。 これではリモートプロセスは無期限に輪にされるかもしれません。
The only comprehensive solution known to the interrupt synchronization problem, those that avoid the above difficulties,
中断同期問題に知られている、唯一の包括的解決、上の困難を避けるもの
Crocker [Page 3] RFC 103 Implementation of Interrupt Keys February 1971
中断キー1971年2月のクロッカー[3ページ]RFC103実装
require more than minor changes to the current NCP protocol. Unless simpler answers are suggested, their implementation must be postponed until the next major design revision.
現在のNCPプロトコルにマイナーチェンジ以上を必要としてください。 より簡単な答えが示されない場合、次の主要なデザイン改正までそれらの実装を延期しなければなりません。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Gert Doering 4/97 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ゲルトDoering4/97によるオンラインRFCアーカイブへの]
Crocker [Page 4]
クロッカー[4ページ]
一覧
スポンサーリンク