RFC56 日本語訳

Network Working Group                                Ed Belove (Harvard)
Request for Comments: 56                            Dave Black (Harvard)
                                                       Bob Flegel (Utah)
                                                 Lamar G. Farquar (Utah)
                                                               June 1970

Belove(ハーバード)がコメントのために要求するワーキンググループ教育をネットワークでつないでください: 56 デーヴ黒人の(ハーバード)ボブ・フレーゲル(ユタ)ラマールG.Farquar(ユタ)1970年6月

                          Third Level Protocol

3番目にプロトコルを平らにしてください。

                            Logger Protocol

きこりのプロトコル

                          General Description

概説

In our view of the world each host has a set of four programs to allow a
user teletype to communicate with a foreign monitor. The exact
implementation of these programs is highly installation-dependent.  Thus
all explanations are meant to describe functional characteristics rather
than design.

私たちの世界観では、各ホストはユーザテレタイプが外国人のモニターとコミュニケートするのを許容する4つのプログラムのセットを持っています。 これらのプログラムの正確な実現はインストール非常に依存しています。 したがって、すべての説明がデザインよりむしろ機能特性について説明することになっています。

The four programs come in two male/female pairs. A user employs a send-
logger at his site to communicate with receive-logger at the appropriate
foreign site in order to establish a full duplex link between the user's
teletype and the foreign machine's monitor. This puts him in the
equivalent of a pre-logged in state at the other machine.  After the
link has been established, the two loggers drop out of the picture, and
the user is left talking to a sender in his machine, whose main function
is to take input from the user's teletype and send it down the link that
was established by the loggers to the receiver in the foreign host which
passes it along to its monitor (making it look like input from a local
teletype). Replies from the foreign monitor are given by it to the
receiver, which transmits them back along the link to the sender, which
outputs them on the user's teletype. The sender and receiver in each
machine must either exist in multiple copies, one for each network user,
or there must be a single copy which can handle all of the network
users. The loggers, however, need be able to handle only one user at a
time, since their task is quickly accomplished, leaving them free to
satisfy other requests.  However there should be some method of queuing
requests that can not be satisfied immediately. A less satisfactory
alternative would be to give a busy message to any user who tries to use
the logger while it is busy. (This, of course, does not preclude the
possibility of an installation having a re-entrant logger, or of having
multiple copies of the logger.)

4つのプログラムが男性の、または、女性の2組に入ります。 雇用aがユーザのテレタイプと外国マシンのモニターとの全二重リンクを設立するために適切できこりを受信している海外サイトと伝える彼のサイトできこりを送るユーザ。 これはもう片方で状態であらかじめ登録されたマシンの同等物に彼を入れます。 リンクが設立されて、2人のきこりが関係ない状態で低下して、ユーザが彼のマシンの送付者への話にままにされた後に、だれの主な機能は、ユーザのテレタイプから入力を取って、きこりによって異種宿主のそれをモニターに回す受信機に設立されたリンクの下側にそれを送る(地方のテレタイプから入力を似させて)ことですか? それは外国人のモニターからの回答を受信機に与えます。(それは、ユーザのテレタイプの上でそれらを出力する送付者へのリンクに沿ってそれらを伝えます)。 各マシンの送付者と受信機は複本でいなければなりません、各ネットワーク利用者あたり1つ、またはネットワーク利用者のすべてを扱うことができるただ一つのコピーがあるに違いありません。 しかしながら、きこりは一度に1人のユーザしか扱うことができなくなければなりません、彼らのタスクがすぐに達成されるので、彼らを他の要望に応じるのにおいて自由なままにして。 しかしながら、すぐに応じることができない要望を列に並ばせる何らかの方法があるべきです。 それほど満足できない代替手段はそれが忙しい間にきこりを使用しようとするどんなユーザにも忙しいメッセージを与えるだろうことです。 (これはもちろん、インストールにはリエントラントきこりがいるか、またはきこりの複本を持っている可能性を排除しません。)

The receive-logger should be user zero in every machine and should
always be listening to socket zero. (This same thing can be accomplished
by having the NCP intercept all messages to user zero, socket zero, and
send them to the receive-logger; but it is simpler and cleaner to have

きこりを受信するのは、あらゆるマシンのユーザゼロであるべきである、いつもソケットゼロを聞くべきです。 (この同じものを達成できる、すべてがユーザゼロ、ソケットゼロへ通信して、それらを送るNCPインタセプトを持っていることによって、きこりを受信します;、それは、持つために、より簡単であって、より清潔です。

                                                                [Page 1]

the logger actually be user zero and have the NCP handle its messages
the same as everyone else's.)

[1ページ] きこりは、他の人皆のものとして同じように実際にユーザゼロであり、NCPにメッセージを扱わせます。)

When the send-logger is called, it pulls a pair of unused sockets (2N
and 2N+1) from a pool of free sockets and CONNECT from 2N+1 to User 0,
Socket 0 in the desired foreign host. This activates the receive-logger,
which accepts the connection if it has an available slot for the foreign
teletype. He then immediately closes down this connection to allow links
from other sources to be initiated. If, on the other hand, there is no
room for the foreign teletype (or if, for some other reason, the
receive-logger does not wish to connect) the attempted link to socket
zero is refused. This notifies the send-logger that he cannot log on the
foreign host and it then notifies the user of this fact. There is no
guarantee, however, that the close was actually sent by the foreign
logger. It could have been sent by the NCP if, for example, the pending
call queue for the socket was overloaded.

きこりを発信させるのが呼ばれるとき、それは無料のソケットとCONNECTのプールから1組の未使用のソケット(2Nと2N+1)を2N+1からUser0(必要な異種宿主のSocket0)まで引きます。 これは、きこりを受信するのを動かします。(それに外国テレタイプのための利用可能なスロットがあるなら、それは、接続を受け入れます)。 そして、彼は、すぐに、他のソースからのリンクが開始されるのを許容するためにこの接続を閉鎖します。 外国テレタイプの余地が全く他方ではなければ(きこりを受信するのがある他の理由で接続したくないなら)、ソケットゼロへの試みられたリンクは拒否されます。 これは彼が異種宿主にログオンできないで、次に、この事実についてユーザに通知するようにきこりを発信させるのに通知します。 しかしながら、保証が全くありません。外国人のきこりによって送られて、閉鎖は実際にそうでした。 例えば、ソケットのための未定の呼び出し待ち行列を積みすぎたなら、NCPはそれを送ったかもしれません。

If the link to socket zero has been accepted (thus indicating that the
receive-logger can accommodate the request) after closing that link, the
receive-logger picks an available pair of sockets (2M and 2M+1) from its
pool, and connects from 2M+1 to 2N. (It found the identity of 2N when
its listen was answered by the link with 2N+1.)  The send-logger has
meanwhile listened to socket 2N and now accepts the link, and CONNECTS
from 2N+1 to 2M. The receive-logger has been listening to this socket
and accepts the attempted link.

そのリンクを閉じた後にソケットゼロへのリンクを受け入れたなら(その結果、きこりを受信するのが要求に対応できるのを示します)、きこりを受信するのは、プールからソケット(2Mと2M+1)の手があいている組を選んで、2M+1から2Nまで接続します。 聴いてください。(2Nのアイデンティティにいつかを見つけた、それ、2N+1とのリンクによって答えられた、) きこりを発信させるのは、一方、ソケット2Nを聞いて、今、リンク、およびCONNECTSを2N+1から2Mに受け入れます。 きこりを受信するのは、このソケットを聞いていて、試みられたリンクを受け入れます。

At this point, there is a full duplex connection between the two
loggers. They then activate the sender and receiver, which handle all
other communication between the user and the foreign monitor.  (The
senders and receivers can be part of the loggers, or can be called by
them, etc.)

ここに、2人のきこりの間には、全二重接続があります。 そして、彼らは送付者と受信機を動かします。(それは、ユーザと外国人のモニターとの他のすべてのコミュニケーションを扱います)。 (送付者と受信機は、きこりの一部であることができる、または彼らなどで呼ぶことができます)

When the user is finished and escapes back to his monitor, it is up to
the sender to close down the links. On the receiving end, it would be
highly desirable for the NCP to notify the receiver of this fact, so it
could log the user off (if he had failed to do that himself) and could
free any resources that he had been using.

ユーザが終わって、彼のモニターに逃げて戻るとき、リンクを閉鎖するのは、送付者次第です。 受ける側になって、NCPがこの事実の受信機に通知するのは、ユーザからログオフできて(彼が自分でそれをしていなかったなら)、彼が使用し続けていたどんなリソースも解放できるように非常に望ましいでしょう。

A more formal outline of the proposed protocol described in the scenario
above follows:

上のシナリオで説明された提案されたプロトコルの、より正式なアウトラインは従います:

                                                                [Page 2]

   1. Stable state: receive-logger at foreign host listening to User 0,
   Socket 0.

[2ページ] 1。 安定状態: User0、Socket0を聞いている異種宿主できこりを受信します。

   2. Local user calls send-logger.

2. 地元のユーザはきこりを発信させて電話をします。

   3. Send-logger calls CONNECT (port, 2N+1, <foreign host#,0,0>).

3. きこりを発信させている呼び出しCONNECT(ポート、2N+1、<異種宿主#、0、0>)。

   4. Send-logger calls LISTEN (port, <local host#, user#, 2N>).

4. きこりを発信させている呼び出しLISTEN(ポート、<ローカル・ホスト#、ユーザ#、2N>)。

   5. Foreign logger's LISTEN is answered, and he is told local user
   number, host and #2N+1.

5. 外国人のきこりのLISTENは答えられます、そして、彼は地元のユーザ数、ホスト、および#2N+1に言われます。

   6. Foreign logger looks for available sockets (2M and 2M+1).  If they
   exist and it is able to establish connection, it accepts and then
   immediately closes the link.

6. 外国人のきこりは利用可能なソケット(2Mと2M+1)を探します。 存在していて、接続を確立できるなら、それは、受け入れて、すぐに、リンクを閉じます。

   7. Foreign logger calls CONNECT (port, 2M+1, <local host#, user#,
   2N>).

7. 外国人のきこりは、CONNECTと呼びます(<ローカル・ホスト#、ユーザ#、2N>を2M+1移植してください)。

   8. Foreign logger calls LISTEN (port, <local host#, user#, 2M>).

8. 外国人のきこりは、LISTENを(ポート、<ローカル・ホスト#、ユーザ#、2Mの>)と呼びます。

   9. Send-logger has listened to 2N and accepts link, then calls
   CONNECT (port, 2N+1, <foreign host#, user#,2M>).

9. きこりを発信させる、2Nを聞いて、リンクを受け入れて、次に、CONNECTを(ポート、2N+1、<異種宿主#、ユーザ#、2Mの>)と呼びます。

   10. Receive-logger, which is listening on 2M, accepts link.

10. きこりを受信して、どれが、2Mで聴いていて、リンクを受け入れますか?

   11. Loggers activate appropriate handlers.

11. きこりは適切な操作者を動かします。

   12. When the user is finished, sender closes down both links.

12. ユーザが終わっているとき、送付者は両方のリンクを閉鎖します。

This basic method of establishing a full duplex connection should be
standard throughout the network. The particular way each installation
handles the implementation of the sender, receiver, and the two loggers
is of no consequence to the network and is highly machine dependent.
(Even the fact of needing a sender and receiver is machine dependent in
that some members of the network might be able to handle their functions
in other ways.) However, some conventions must be established regarding
communication between the sender and receiver, or their equivalents.

全二重接続を確立するこの基本的方法はネットワーク中で標準であるべきです。 各インストールが送付者、受信機、および2人のきこりの実現を扱う特定の方法は、ネットワークには結果が全くなくて、マシンに非常に依存しています。 (ネットワークの何人かのメンバーが他の方法で彼らの機能を扱うことができるかもしれないので、送付者と受信機を必要とする事実さえマシン依存です。) しかしながら、送付者と受信機とのコミュニケーション、またはそれらの同等物に関していくつかのコンベンションを設立しなければなりません。

Network Standard Code

標準のコードをネットワークでつないでください。

In order to facilitate use of the network, we propose the convention
that all teletype-to-foreign-monitor communication be done using 128
character USASCII. (This is the code used by the IMP's and is in the
appendix to the IMP operating manual.) It makes sense to require
machines to make only one conversion to a standard code, than to have to
make conversions to every code on the net.

ネットワークの使用を容易にするために、私たちは128キャラクタUSASCIIを使用することでしていた状態でテレタイプから外国人のモニターへのすべてのコミュニケーションがあるコンベンションを提案します。 (これは、IMPのものによって使用されたコードであり、IMP操作マニュアルには付録にあります。) それは1つだけを変換にするようにマシンを必要とする意味を標準のコードにします、変換をネットのあらゆるコードにしなければならないより。

                                                                [Page 3]

In addition, since most of the network machines use ASCII as their
internal character code, it will be no trouble for them. Even those
machines that use a different code must translate to and from ASCII in
order to communicate with local teletypes. Extending this translation to
the network should cause very little trouble. We envision this
translation as taking place in the sender and receiver, but again that
is implementation dependent.

[3ページ] さらに、ネットワークマシンの大部分がそれらの内部のキャラクタコードとしてASCIIを使用するので、それはそれらのためにどんな問題にもならないでしょう。 異なったコードを使用するそれらのマシンさえ、地方のテレタイプで交信するためにASCIIとASCIIから翻訳されなければなりません。 この翻訳をネットワークに広げていると、問題はほとんど引き起こされるべきではありません。 私たちは送付者と受信機で行われるとこの翻訳を思い描きますが、一方、それは実現に依存しています。

If ASCII is adopted as a standard, we would suggest that all non-ASCII
machines create a monitor to the machine's internal code. This would
make the complete character set available to those who wished to use it
(and were willing to write a simple conversion routine for the local
machine.) In this way, those users who wanted to could use any machine
on the net from their teletype, without requiring their machines to have
records of all the network codes, and yet could use the full power of
the foreign machine if they wanted.

ASCIIが規格として採用されるなら、私たちは、非ASCIIマシンがすべて、マシンの内部のコードにモニターを創造することを提案するでしょう。 これで、完全な文字の組はそれ(そして、地方のマシンのために簡単な変換ルーチンを書くことを望んでいた)を使用したがっていた人に利用可能になるでしょう。 このように、そうしたがっていたユーザは、彼らのマシンにはすべてのネットワークコードに関する記録がある必要でない彼らのテレタイプからネットのどんなマシンも使用できましたが、彼らが望んでいるなら、外国マシンの全出力を使用できるでしょうに。

Again, this standard applies only for teletype-to-foreign-monitor
communication.

一方、この規格はテレタイプから外国人のモニターへのコミュニケーションだけに申し込みます。

Break Characters

区切り文字

A standard way of handling the break character has to be established for
the network and be included in the protocol. Problems with the break
character arise in several contexts. First, there are two distinct
purposes served by the break character. One is as a panic button. This
says, "I do not care what is happening, stop and get me out to monitor
level now." This command is executed immediately upon receipt, and is
most commonly used to get out of a program that one does not want to be
in (e.g., one that is in an infinite loop, etc.)

区切り文字を扱う標準の方法は、ネットワークのために確立されて、プロトコルに含まれなければなりません。 区切り文字に関する問題はいくつかの文脈に起こります。 まず最初に、区切り文字によって勤められた2つの異なった目的があります。 非常ボタンとして1つがあります。 「私は、何が起こっているかを気にかけて、止まって、現在レベルをモニターするために私を出しません。」と、これは言います。 このコマンドは、すぐ領収書で実行されて、人がいたがっていないプログラムを出るのに最も一般的に使用されます。(例えば無限ループなどにはあるもの)

The other purpose that is served is that of an exit from a subsystem, or
on a machine with a forking structure as a method to get back to the
next higher level fork. This second purpose is not an immediate one in
that the user wants the system to finish all that he has told it to do
before exiting.

役立たれているもう片方の目的は、サブシステムからの出口のものであるか次の、より高い平らなフォークに戻る方法としての分岐構造があるマシンの上でそうです。 ユーザが、システムに彼が出る前にすると言ったすべてを終えて欲しいので、この2番目の目的は即座のものではありません。

We assume that there does not exist in every system 1) a way of
performing each of these functions, or 2) a clear cut distinction
between the calling and operation of the two. Furthermore, there are
subtle distinctions as to how each system treats the commands.

私たちは、それぞれのこれらの機能、または呼ぶのと2つのものの操作の間の明確なカット区別あたり2つの機能を)実行する方法があらゆるシステム1)に存在するというわけではないと思います。 その上、各システムがどうコマンドを扱うかに関して微細な区別があります。

The panic button function can easily be performed by the proposed
control command <INT>. This function must be accomplished by using a
control command, since a program can enter a state where it is accepting
no input: hence, the program cannot be aborted by sending it a message
down the teletype link. There is no reason to worry about the race
condition caused by sending this command down the control link since its

提案された制御コマンド<INT>は容易に非常ボタン機能を実行できます。 制御コマンドを使用することによって、この機能を達成しなければなりません、プログラムがそれが入力を全く受け入れていない状態に入ることができるので: したがって、テレタイプリンクでメッセージをそれに送ることによって、プログラムを中止できません。 このコマンドを下に降ろすことによって引き起こされた競合条件を心配するどんな理由も以来そこでは、コントロールリンクでない、それ

                                                                [Page 4]

whole purpose is to force the machine to disregard everything else the
user has sent.

[4ページ] 全体の目的はマシンにユーザが送った他の何もかもを無視させることです。

In our implementation of this, we would ask the user to specify to the
logger a seldom used character that he wants to be his foreign panic
button. Then, it would be a simple task for the sender to map this
character into an <INT> command, which the foreign machine must
interpret properly. This scheme would work well for most machines, but
some may lend themselves to different ways of generating the <INT>.

この実現では、私たちは、彼が彼の外国非常ボタンになりたがっているめったに使用されなかったキャラクタをきこりに指定するようにユーザに頼むでしょう。 そして、それは、送付者が<INT>コマンドにこのキャラクタを写像するためには簡単な仕事でしょう。(外国マシンは適切にコマンドを解釈しなければなりません)。 この計画はほとんどのマシンにうまくいくでしょうが、或るものは<INT>を発生させる異なった方法に自分たちを与えるかもしれません。

The other problem that presents itself is what to do if the foreign
machine's "exit" character is the same as the local machine's.  The
problem is that while a user is talking to a foreign machine, he would
want to be in a transparent mode, where everything he types is sent
directly to the other machine. The way he would get himself out of this
mode is to type either his machine's "exit" character or its panic
button. Thus, if the foreign machine has the same one, there would be no
way to send it. The way out of this is the same as above--merely a
mapping of another seldom used character into the foreign machine's
"exit" character. This type of mapping can be carried as far as each
installation deems necessary. Giving the user complete control over
translation is helpful in that it allows him to user characters that his
teletype cannot generate.

外国マシンの「出口」キャラクタが地方のマシンのものと同じであるなら、浮かぶもう片方の問題はするべきことです。 問題はユーザが外国マシンと話している間、透過モードには彼がいたがっているだろうということです。((そこでは、直接もう片方のマシンに送られます)彼がタイプするすべて)。 彼がこのモードから自分に得るだろうという方法は彼のマシンの「出口」キャラクタかその非常ボタンのどちらかをタイプすることです。 したがって、外国マシンに同じ1つがあるなら、それを送る方法が全くないでしょう。 これからの道は単に別のものに関するマッピングが上でめったに外国マシンの「出口」キャラクタにキャラクタを使用しなかったのと同じです。 各インストールが、必要であると考えるのと同じくらい遠くにこのタイプに関するマッピングを運ぶことができます。 彼のテレタイプが発生させることができないユーザキャラクタに彼を許容するので、翻訳のユーザの完全な支配力を与えるのは役立っています。

Command Message Formats

コマンドメッセージ・フォーマット

Each site should establish its now conventions about when to send a
monitor command string, and in what size chunks. When performing a
routine operation, one might want to send several command lines as a
single message. If working with the monitor as usual, a reasonable break
point might be at every carriage return. When using a highly interactive
language such as QED, one might decide character-by-character
transmission was a necessity. We feel that each user should have the
choice between these three methods (and possible more). Furthermore, the
user should be able to change between each mode at will. The differences
in syntax of the send-message commands mentioned above should be noted.
For the first, a special send-message command character must be defined,
and it should not be sent along with the message. For the second, the
carriage return acts dually as the send-message command and as a command
delimiter. Therefore it must be sent with the message. Finally, the case
of character-by-character transmission with its implicit send command
should pose no significant problems.

各サイトが設立するべきである、それ、現在のコンベンション、いつモニタ・コマンドストリングを送るかの周りと、そして、どんなサイズ塊に。 通常の操作を実行するとき、人はただ一つのメッセージとしていくつかのコマンドラインを送りたがっているかもしれません。 モニターが通常通りで働いているなら、あらゆる復帰には妥当なブレークポイントがあるかもしれません。 QEDなどの非常に対話的な言語を使用するとき、人は、キャラクタごとのトランスミッションが必要性であったと決めるかもしれません。 私たちは、各ユーザがこれらの3つの方法(そして、可能な以上)の間に選択を持つべきであると感じます。 その上、ユーザは各モードの間で自由自在に変化できるべきです。 前記のようにメッセージを発信させているコマンドの構文の違いは注意されるべきです。 1番目に関しては、メッセージを発信させている特別なコマンドキャラクタを定義しなければなりません、そして、メッセージと共にそれを送るべきではありません。 2番目のために、復帰はメッセージを発信させているコマンドとしてコマンドデリミタとして二元的に行動します。 したがって、メッセージと共にそれを送らなければなりません。 最終的に、キャラクタごとの暗黙の発信コマンドによるトランスミッションに関するケースは重大な問題を全く引き起こすはずがありません。

                                                                [Page 5]

The preceding discussion is meant to imply also that the receiver must
be able to buffer up each of the above types of transmission into a form
acceptable to its own monitor interface.

前の議論が含意することになっている受信機がそれ自身のモニターインタフェースに許容しているフォームへの上のタイプのそれぞれのトランスミッションにバッファリングできなければならない[5ページ。]も

In addition, all echoing should be done in the local host, with the
foreign machine suppressing its echoes (if it can.)

さらに、外国マシンがエコーを抑圧している状態で、ローカル・ホストですべての反響をするべきです。(そうすることができるなら。)

We would like to thank Carl Ellison (of Utah) for his valuable
suggestions and criticisms of this work, and Jim Curry (of Utah) for his
encouragement and support of the effort.

この仕事の彼の貴重な提案と批評のためのカール・エリソン(ユタの)、および彼の努力の奨励とサポートのためのジムCurry(ユタの)に感謝申し上げます。

       [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Jon Ribbens 7/97 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ジョン・リーベンス7/97によるオンラインRFCアーカイブへの]

                                                                [Page 6]

[6ページ]