RFC1080 日本語訳

1080 Telnet remote flow control option. C.L. Hedrick. November 1988. (Format: TXT=6688 bytes) (Obsoleted by RFC1372) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                         C. Hedrick
Request for Comments: 1080                            Rutgers University
                                                           November 1988

コメントを求めるワーキンググループC.ヘドリックの要求をネットワークでつないでください: 1080 ラトガース大学1988年11月

                   Telnet Remote Flow Control Option

telnetのリモートフロー制御オプション

Status of This Memo

このメモの状態

   This RFC specifies a standard for the Internet community.  Hosts on
   the Internet that do remote flow control within the Telnet protocol
   are expected to adopt and implement this standard.  Distribution of
   this memo is unlimited.

このRFCはインターネットコミュニティの規格を指定します。 インターネットのTelnetプロトコルの中でリモートフロー制御をするホストは、この規格を採用して、実装すると予想されます。 このメモの分配は無制限です。

Motivation

動機

   This memo describes a method of remotely toggling flow control
   between a user telnet process and the attached terminal.  Only flow
   control of data being transmitted from the telnet process to the
   terminal is considered.  Many systems will also allow flow control of
   data from the terminal to the telnet process.  However there is
   seldom need to change this behavior repeatedly during the session.

このメモはユーザtelnetプロセスと付属端末の間のフロー制御を離れて切り換えるメソッドを説明します。 telnetプロセスから端末まで送られるデータのフロー制御だけが考えられます。 また、多くのシステムが端末からtelnetプロセスまでのデータのフロー制御を許容するでしょう。 しかしながら、セッションの間に繰り返してこの振舞いを変える必要がめったにありません。

   There are two common ways of doing flow control: hardware and
   software.  Hardware flow control uses signals on wires dedicated for
   this purpose.  Software flow control uses one or two specific
   characters sent along the same path as normal input data.  Most
   commonly, XOFF (control-S) and XON (control-Q) are used to stop and
   start output, respectively.  The option described herein is useful
   primarily where software flow control is being used.  (Since hardware
   flow control does not preempt any characters, there is normally no
   need to disable it.)

フロー制御をする2つの一般的な方法があります: ハードウェアとソフトウェア。 ハードウェアフロー制御はこのために捧げられたワイヤの上の信号を使用します。 ソフトウェア・フロー制御は正常な入力データと同じ経路に沿って送られた1か2つの特定のキャラクタを使用します。 最も一般的に、XOFF(コントロールS)とXON(コントロールQ)はそれぞれ出力された停止と始めに使用されます。 ここに説明されたオプションは主としてソフトウェア・フロー制御が使用されているところで役に立ちます。 (ハードウェアフロー制御が少しのキャラクタも先取りしないので、それを無効にする必要は全く通常ありません。)

   The primary difficulty with software flow control is that it preempts
   one or two characters.  Host software often requires the user to be
   able to input every possible ASCII character.  (Certain editors are
   notorious for having XOFF and XON as commonly-used commands.)  For
   this reason, operating systems often allow programs to disable flow
   control.  While it is disabled, the characters that normally signal
   flow control may be read as normal input.  In a telnet environment,
   flow control is normally done by the user telnet process, not by the
   host computer.  Thus this RFC defines a way to propagate flow control
   status from the host computer to the user telnet process.

ソフトウェア・フロー制御におけるプライマリ困難は1か2つのキャラクタを先取りするということです。 ホストソフトウェアは、しばしばユーザがすべての可能なASCII文字を入力できるのを必要とします。 (一般的に使用されたコマンドとしてXOFFとXONを持っているのに、確信しているエディタは悪名高いです。) この理由で、オペレーティングシステムで、プログラムはしばしばフロー制御を無効にすることができます。 それは障害がある間、通常、フロー制御を示すキャラクタが通常の入力と読まれるかもしれません。 telnet環境で、通常、ユーザtelnetプロセスはホストコンピュータでするのではなく、フロー制御をします。 したがって、このRFCはホストコンピュータからユーザtelnetプロセスまでフロー制御状態を伝播する方法を定義します。

Hedrick                                                         [Page 1]

RFC 1080           Telnet Remote Flow Control Option       December 1988

フロー制御オプション1988年12月にリモートなヘドリック[1ページ]RFC1080telnet

1. Command Name and Code

1. コマンド名とコード

      TOGGLE-FLOW-CONTROL

トグルフロー制御

      Code = 33

コード=33

2. Command Meanings

2. コマンド意味

      IAC WILL TOGGLE-FLOW-CONTROL

IACウィルトグルフロー制御

         Sender is willing to enable and disable flow control upon
         command.

送付者は、コマンドのときにフロー制御を可能にし、無効にしても構わないと思っています。

      IAC WON'T TOGGLE-FLOW-CONTROL

IACがそうしない、トグルフロー制御

         Sender refuses to enable and disable flow control.  Nothing is
         implied about whether sender does or does not use flow control.
         It is simply unwilling to enable and disable it using this
         protocol.

送付者は、フロー制御を可能にして、無効にするのを拒否します。 送付者がするか、またはフロー制御を使用しないかに関して何も含意されません。 それを可能にして、無効にするのは、このプロトコルを使用することで単に不本意です。

      IAC DO TOGGLE-FLOW-CONTROL

IACはトグルフロー制御をします。

         Sender is willing to send commands to enable and disable flow
         control.

送付者は、フロー制御を可能にして、無効にするコマンドを送っても構わないと思っています。

      IAC DON'T TOGGLE-FLOW-CONTROL

IACはフロー制御を切り換えてしません。

         Sender refuses to send command to enable and disable flow
         control.

送付者は、フロー制御を可能にして、無効にするコマンドを送るのを拒否します。

      IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE

IAC SEのIAC SBトグルフロー制御

         Sender requests receiver to disable flow control.  The code for
         OFF is 0.

送付者は、フロー制御を無効にするために受信機を要求します。 OFFのためのコードは0です。

      IAC SB TOGGLE-FLOW-CONTROL ON IAC SE

IAC SEの上のIAC SBトグルフロー制御

         Sender requests receiver to enable flow control.  The code for
         ON is 1.

送付者は、フロー制御を可能にするよう受信機に要求します。 ONのためのコードは1です。

3. Default

3. デフォルト

      WON'T TOGGLE-FLOW-CONTROL

トグルフロー制御であるだろう

         Flow control information will not be exchanged.

フロー制御情報は交換されないでしょう。

Hedrick                                                         [Page 2]

RFC 1080           Telnet Remote Flow Control Option       December 1988

フロー制御オプション1988年12月にリモートなヘドリック[2ページ]RFC1080telnet

      DON'T TOGGLE-FLOW-CONTROL

フロー制御を切り換えて、しないでください。

         Flow control information will not be exchanged.

フロー制御情報は交換されないでしょう。

4. Description of the Option

4. オプションの記述

   Use of the option requires two phases.  In the first phase, the
   telnet processes agree that one of them will TOGGLE-FLOW-CONTROL.
   WILL and DO are used only in this first phase.  In general there will
   be only one exchange of WILL and DO for a session.  Subnegotiations
   must not be issued until DO and WILL have been exchanged.  It is
   permissible for either side to turn off the option by sending a WONT
   or DONT.  Should this happen, no more subnegotiations may be sent,
   unless the option is reenabled by another exchange of DO and WILL.

オプションの使用は二相を必要とします。 第1段階では、telnetプロセスは、それらの1つはTOGGLE-FLOW-CONTROLがそうするのに同意します。 してください。そして、この第1段階だけでは、使用されるでしょう。 一般に、ウィルの1回の交換だけであり、セッションのためにするでしょう。 してください。そうすれば、ウィルを交換するまでSubnegotiationsを発行してはいけません。 どちらの側もWONTかドントを送ることによってオプションをオフにするのは、許されています。 してください。これが起こるなら、より多くの副交渉を送るかもしれません、オプションが別の交換で再可能にされない場合そして、ウィル。

   Once the hosts have exchanged a WILL and a DO, the sender of the DO
   TOGGLE-FLOW-CONTROL is free to send subnegotiations to enable and
   disable flow control in the other process.  Normally, the sender of
   the DO will be a host, and the other end will be a user telnet
   process, which is connected to a terminal.  Thus the protocol is
   normally asymmetric.  However it may be used in both directions
   without confusion should need for this arise.

ホストがいったんウィルとaがするaを交換すると、DO TOGGLE-FLOW-CONTROLの送付者は、もう片方のプロセスでフロー制御を可能にして、無効にするために自由に副交渉を送ることができます。 通常送付者、終わりがユーザtelnetがプロセスであったならそうするaに接されるホスト、およびもう片方が端末であったなら、意志をしてください。 したがって、通常、プロトコルは非対称です。 しかしながら、この必要性が起こるなら、それは混乱なしで両方の方向に使用されるかもしれません。

   As soon as the DO and WILL have been exchanged, the sender of the
   WILL must enable flow control.  This allows flow control to begin in
   a known state.  Should the option be disabled by exchange of DONT and
   WONT, flow control may revert to an implementation-defined default
   state.  It is not safe to assume that flow control will remain in the
   state requested by the most recent subnegotiation.

すぐに、してください、そして、交換していて、ウィルの送付者がフロー制御を可能にしなければならないということであってしまうでしょう。 これで、フロー制御は知られている状態で始まります。 オプションがドントとWONTの交換で無効にされるなら、フロー制御は実装で定義されたデフォルト状態に戻るかもしれません。 フロー制御が最新の副交渉によって要求された州に残ると仮定するのは安全ではありません。

   Currently, only two command codes are defined for the
   subnegotiations: flow control off (code 0) and flow control on (code
   1).  Neither of these codes requires any additional data.  However it
   is possible that additional commands may be added.  Thus
   subnegotiations having command codes other than 0 and 1 should be
   ignored.

現在、2つのコマンドコードだけが副交渉のために定義されます: (コード0)のフロー制御と(コード1)に関するフロー制御。 これらのコードのどちらも追加データを必要としません。 しかしながら、追加コマンドが加えられるのは、可能です。 したがって、0と1以外のコマンドコードを持っている副交渉は無視されるべきです。

      Here is an example of use of this option:

ここに、このオプションで役に立つ例があります:

         Host1: IAC DO TOGGLE-FLOW-CONTROL

Host1: IACはトグルフロー制御をします。

         Host2: IAC WILL TOGGLE-FLOW-CONTROL

Host2: IACウィルトグルフロー制御

         (Host1 is now free to send commands to change flow control.
         Note that host2 must now have enabled flow control.)

(Host1は現在、自由にフロー制御を変えるコマンドを送ることができます。 host2が現在フロー制御を可能にしたに違いないことに注意してください。)

Hedrick                                                         [Page 3]

RFC 1080           Telnet Remote Flow Control Option       December 1988

フロー制御オプション1988年12月にリモートなヘドリック[3ページ]RFC1080telnet

         Host1: IAC SB TOGGLE-FLOW-CONTROL OFF IAC SE

Host1: IAC SEのIAC SBトグルフロー制御

         Host1: IAC SB TOGGLE-FLOW-CONTROL ON IAC SE

Host1: IAC SEの上のIAC SBトグルフロー制御

Author's Address:

作者のアドレス:

   Charles Hedrick
   Rutgers University
   Center for Computer and Information Services
   Hill Center, Busch Campus
   P.O. Box 879
   Piscataway, NJ 08855-0879

コンピュータと情報のためのチャールズヘドリックラトガース大学センターはヒルセンターにサービスを提供して、ブッシュキャンパス私書箱は879ピスキャタウェイ、ニュージャージー08855-0879です。

   Phone: (201) 932-3088

以下に電話をしてください。 (201) 932-3088

   Email: HEDRICK@ARAMIS.RUTGERS.EDU

メール: HEDRICK@ARAMIS.RUTGERS.EDU

Hedrick                                                         [Page 4]

ヘドリック[4ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

CREATE INDEX インデックスを作成する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る