RFC386 日本語訳

Network Working Group                    Bernard P. Cosell
Request For Comments # 386               David C. Walden
NIC # 11358                              Bolt Beranek and Newman Inc.
Categories:                              August 16, 1972
Updates:
Obsoletes:

コメント#386デヴィッドC.ウォルデンNIC#11358ボルトBeranekとニューマン株式会社Categoriesを求めるワーキンググループバーナードP.コーセルの要求をネットワークでつないでください: 1972年8月16日アップデート: 時代遅れにします:

                        LETTER TO TIP USERS -- 2

ユーザにチップを与えさせる手紙--2

     This is the second letter to TIP users.  The first was RFC #365.
There will be more letters to TIP users as they seem to us to be a
good way to keep you informed about what's going on.  We suggest you
keep these letters with your TIP User's Guide (TUG) as we will use the
letters to provide documentation of TIP system changes which are made
before we can get TUG revisions printed and distributed. (It is almost
inevitable that the TUG revisions follow actual system changes.
Further- more, these letters will allow us more discussion of new
commands than in TUG.)

これはTIPユーザへの2番目の手紙です。 1番目はRFC#365でした。 彼らが、起こっていることに関してあなたに知らせ続ける早道であるように私たちにとって思えるようにTIPユーザへの、より多くの手紙があるでしょう。 私たちは、私たちが私たちがTUG改正が印刷されて、広げられるのをさせることができる前に作られるTIPシステム変更のドキュメンテーションを提供するのに手紙を使用するつもりであるときあなたがあなたのTIP Userのガイド(TUG)でこれらの手紙を保管することを提案します。 (TUG改正が実際のシステム変更に続くのは、ほとんど必然です。 さらに多くであり、これらの手紙は新しいコマンドのTUGより多くの議論を私たちに許すでしょう。)

     Some of the changes we will be making to the TIP have been
suggested by TIP users. We won't bother with acknowledg- ments.

私たちがTIPにする変更のいくつかがTIPユーザによって提案されました。 私たちはacknowledg- mentsを苦にするつもりではありません。

     The @PROTOCOL TO LOGIN and @PROTOCOL TO CLOSE BOTH commands will
be removed very soon. We presume no one uses these commands any more
since they have been replaced by @LOGIN and @CLOSE.

@PROTOCOLのTO LOGINと@PROTOCOL TO CLOSE BOTHコマンドはすぐ、取り外されるでしょう。 私たちは、だれもそれらを@LOGINと@CLOSEに取り替えたのでそれ以上これらのコマンドを使用しないと推定します。

     As we warned in TIP Letter 1, the @LOGIN command will be given a
parameter soon, the Host number up to now given with the @HOST
command.  At the same time, @HOST will be changed so it does a
simultaneous @RECEIVE FROM HOST and @SEND TO HOST.  Presently, @HOST
is the same as @SEND TO HOST.

私たちがTIP Letter1で警告したように、すぐ@LOGINコマンドにパラメタを与えるでしょう、これまで@HOSTコマンドと共に与えられたHost番号。 それは、同時に@HOSTを変えるので、同時の@RECEIVE FROM HOSTと@SEND TO HOSTをします。現在、@HOSTは@SEND TO HOSTと同じです。

     Several changes will be made to the @TRANSMIT commands very soon.
First @TRANSMIT ON NO CHARACTERS and @TRANSMIT ON EVERY CHARACTER will
be removed. Their functions will be covered by the other @TRANSMIT
commands. @TRANSMIT NOW will continue to function as at present; it
will cause the one message presently being accumulated to be sent as
soon as possible.  @TRANSMIT ON LINEFEED and @TRANSMIT ON MESSAGE-END
will continue to cause the message being accumulated to be sent on
linefeed and CONTROL-S. However, they will additionally cause the
message being accumulated to be sent when the character buffer is
almost full. Thus, it will no longer be necessary to give a @TRANSMIT
EVERY <big number> with @TRANSMIT ON LINEFEED and @TRANSMIT ON
MESSAGE-END.  @TRANSMIT EVERY # will continue to cause the message
being accumulated to be sent as near as possible to every #th
character.  However, values of # which are bigger than the size of the

すぐ、いくつかの変更を@TRANSMITコマンドにするでしょう。 最初の@TRANSMIT ONいいえキャラクターと@TRANSMIT ON EVERYキャラクターを取り除くでしょう。 それらの機能は他の@TRANSMITコマンドでカバーされているでしょう。 @TRANSMITは、現在、プレゼントのように機能し続けるでしょう。 それで、できるだけ早く、現在蓄積される1つのメッセージを送るでしょう。 @TRANSMIT ON LINEFEEDと@TRANSMIT ON MESSAGE-ENDは、蓄積されるメッセージがラインフィードとCONTROL-Sに送られることを引き起こし続けるでしょう。 しかしながら、文字バッファがほとんど完全であるときに、彼らは蓄積されるメッセージをさらに、送らせるでしょう。 したがって、もう、@TRANSMIT ON LINEFEEDと@TRANSMIT ON MESSAGE-ENDと共に@TRANSMIT EVERYの<の大きい数の>に与えるのは必要でないでしょう。 @TRANSMIT EVERY#、が、あらゆる#、に可能な状態で近い状態で送るために蓄積されるメッセージを引き起こし続ける、第キャラクタ。 しかしながら、#のサイズより大きい値

                                                                [Page 1]

RFC # 386                                                     NIC #11358

[1ページ] RFC#386NIC#11358

input buffer will cause transmission when the buffer is almost full;
and a value of 0 for # will reset the terminal to its initial setting
-- TRANSMIT-ON-LINEFEED mode off, TRANSMIT ON MESSAGE- END mode off,
and transmitting every character. Thus, TRANSMIT EVERY 0 has the
effect of the removed @TRANSMIT ON NO CHARACTER command, and @TRANSMIT
EVERY 1 has the effect of the removed @TRANSMIT ON EVERY CHARACTER
command.

バッファがほとんど完全であるときに、入力バッファはトランスミッションを引き起こすでしょう。 そして、#のための0の値は初期設定に端末をリセットするでしょう--オフな下にあるTRANSMIT ON MESSAGE- ENDモードでTRANSMIT-ON-LINEFEEDモードとすべてのキャラクタを伝えること。 したがって、TRANSMIT EVERY0には、取り除かれた@TRANSMIT ONいいえキャラクターコマンドの効果があります、そして、@TRANSMIT EVERY1には、取り除かれた@TRANSMIT ON EVERYキャラクターコマンドの効果があります。

     There are two ways outside of letters and the telephone to
communicate your suggestions and complaints to us: log into BBN-TENEX
and SNDMSG to WALDEN or use the NIC Journal system to send a message
to DCW3. Dave likes letters best, incidentally.

2つの方法で、あなたの提案と苦情を私たちに伝えるために、手紙の外部と電話があります: BBN-TENEXとSNDMSGにウォルデンにログインするか、またはNIC Journalシステムを使用して、メッセージをDCW3に送ってください。 デーヴは最もよく、そして、偶然に手紙が好きです。

     We are going to remove the "NEWS" herald from the TIP's HELLO
message. The problem is that we don't know when everybody has read the
latest news so that we can turn off the herald.  Therefore, we can't
turn it off. Therefore, it is useless.  Check the NEWS every time you
use the TIP. If once the news begins printing you discover you have
already seen it, you can stop it by typing @CLOSE _LF_ (on a 2741 hit
"attention" first).

私たちは「ニュース」を取り除く行くのが、ティップのものからこんにちはを告知するということです。メッセージ。 問題は私たちが、私たちが告知の興味を失わせることができるようにみんながいつ最新ニュースを読んだかを知らないということです。 したがって、私たちはそれをオフにすることができません。 したがって、それは役に立ちません。 TIPを使用するときはいつも、NEWSをチェックしてください。 ニュースがいったん印刷し始めると既にそれを見たと発見するなら、あなたは、@CLOSE_LF_(2741ヒット「注意」1番目の)をタイプすることによって、それを止めることができます。

     A new TIP message will have been added by the time you get this
letter, the message TIP GOING DOWN. This message will be printed on
every TIP terminal shortly before the TIP is taken down for preventive
maintenance, new software releases, etc. (see RFC #381 for further
discussion of this topic). When this message is printed, all TIP users
should cleanly stop what they are doing with a Host. Eventually, this
message will include information on how long until the TIP will go
down, for how long it will be down, and why.

あなたがこの手紙、メッセージTIP GOING DOWNを手に入れる時までに新しいTIPメッセージは加えられてしまうでしょう。 TIPが予防保守、新しいソフトウェアリリースなどのために降ろされるすぐ前にこのメッセージはあらゆるTIP端末に印刷されるでしょう。 (この話題のさらなる議論に関してRFC#381を見ます。) このメッセージが印刷されるとき、すべてのTIPユーザが清潔に、彼らがHostと共にしていることを止めるべきです。 結局、TIPが落ちるまで、このメッセージはどれくらい長さの情報を含むだろうか、どれくらい長い間下にと、なぜになるように。

     While we are on the subject of TIP messages, let us mention that
we will be adding a number of new messages which we believe will
remove some of the present confusion about what the TIP is doing.
Unfortunately, we don't have the space to store the message text
strings, so, we will use numbers for the new messages. The format of
these messages will probably be something like M46 for message 46.
Perhaps when the TIPs get more core we can replace the number-messages
by text-messages.

私たちがTIPメッセージの問題を扱っている間、私たちが、私たちが信じている多くの新しいメッセージがTIPがしていることに関して何らかの現在の混乱を取り除くと言い足すと言及しましょう。 残念ながら、メッセージテキスト文字列を格納するスペースがないので、私たちは新しいメッセージの数を使用するつもりです。 これらのメッセージの形式はたぶんメッセージ46のためのM46に似るでしょう。 恐らくTIPsが、より多くのコアを得るとき、私たちは数メッセージをテキスト・メッセージに置き換えることができます。

     We are thinking of changing all the TIP LOGIN commands to OPEN
commands which would be more opposite to the CLOSE commands and not so
liable to confusion with Host LOGIN.

私たちは、すべてのTIP LOGINコマンドをよりCLOSEコマンドと反対の、そして、それほどHost LOGINへの混乱に責任がないオープン命令に変えることを考えています。

     On page 12 of the TUG is a description of how Hosts can send
commands to a TIP terminal. Be warned, if you decide to use this
facility, that we are changing the TIP command language slowly and we
will not be constrained in these changes by the fact that some Hosts
are sending TIP commands.  Therefore, if a Host is going to send a

12TUGページに、HostsがどうTIP端末にコマンドを送ることができるかに関する記述があります。 この施設を使用すると決めるなら、私たちがゆっくりTIPコマンド言語を変えていて、いくつかのHostsがコマンドをTIPに送るという事実によってこれらの変化で抑制されないと警告されてください。 したがって、Hostであるなら、送る行くのはaですか?

                                                                [Page 2]

RFC # 386                                                     NIC #11358

[2ページ] RFC#386NIC#11358

command to a TIP it ought to implement this in a manner that can be
changed easily.

容易に変えることができる方法でこれを実行するべきであるとTIPに命令してください。

     Some TIP users have been seeing the following problem.  They are
communicating with a Host when suddenly they get the message DEAD. If
they try to LOGIN to the Host again they do not get the DEAD message,
but the Host refuses to allow the LOGIN by either doing nothing,
closing, or refusing. The problem was that occasionally the network
partitioned briefly; for instance, one of the two cross-country lines
was down and the other got flaky for a few seconds. If, during a
period when the network is partitioned, a TIP user sends a message to
a Host which cannot be reached, the TIP types DEAD and closes the
connection to the Host. The Host, on the other hand, may not have been
trying to send to the TIP when the network partitioned; in that case
it might not have noticed that the network partitioned and therefore
still thinks it has an open connection to the TIP.  When the TIP then
tries to re-LOGIN to the Host, the Host refuses because it already has
an open connection with that particular TIP device.

何人かのTIPユーザが以下の問題を認めています。 彼らは、突然、いつメッセージDEADを手に入れるかをHostと伝えています。 再びHostへのLOGINに試みるなら、彼らはDEADメッセージを得ませんが、Hostは、何もしないか、閉じるか、または拒否することによってLOGINを許容するのを拒否します。 そんなに時折問題は簡潔に仕切られたネットワークでした。 例えば、2つのクロスカントリーの線の1つは下がっていました、そして、もう片方が数秒間、風変わりになりました。 TIPユーザがネットワークが仕切られる期間、達することができないHostにメッセージを送るなら、TIPはHostにDEADをタイプして、接続を終えます。 ネットワークであるときに、仕切られて、他方では、HostはTIPに発信しようとしていなかったかもしれません。 その場合、まだしたがって、仕切られていたネットワークが、TIPにはオープンな接続があると思うのに気付いていないかもしれません。 次に、TIPがHostへの再LOGINに試みるとき、それにはその特定のTIP装置とのオープンな接続が既にあるので、Hostは拒否します。

     Now that we have three independent cross-country paths we do not
expect this problem to occur often, but if it does we see no
short-term solution. We can't just let a CLOSE reset the connection
since the user's immediately preceeding LOGIN destroyed the Host
supplied socket numbers. One can get out of this state by executing
the Host/Host protocol command from the TIP which resets _all_ TIP
users at the given TIP talking to the given Host; but this is a little
gross. What is maybe needed is a Host/Host protocol command to reset
the Host's connections with a particular user (TIP) socket; we will
try to understand the ramifications of such a command and perhaps
undertake promotion of a Host/Host protocol change. In the meantime,
frequently when the above problem happens some other TIP terminal can
still LOGIN to the Host and then halt the hung terminal's job from the
Host side.  If it is not possible to get through on another
connection, a telephone call to the Host, asking them to log the job
out, may be necessary. Or, if there is really no other user talking to
the particular Host, the reset command can be executed -- this command
is not documented but we will tell a responsible person at each TIP
site how to execute the command.

それがそうするなら、私たちには3つの独立しているクロスカントリーの経路があるので、この問題が頻出すると予想しませんが、私たちはどんな短期的な解決策も見ません。 ユーザのもの以来私たちはCLOSEにすぐに、接続をリセットさせることができません。ソケット番号を供給して、preceeding LOGINはHostを破壊しました。 1つは_与えられたTIP話におけるすべての_TIPユーザを与えられたHostにリセットするTIPからHost/ホストプロトコルコマンドを実行することによって、この状態を出ることができます。 しかし、これは少し総計です。 特定のユーザ(TIP)ソケットで多分必要であるものはHostの接続をリセットするHost/ホストプロトコルコマンドです。 私たちは、そのようなコマンドの分岐を理解して、恐らくHost/ホストプロトコル変化の販売促進を引き受けようとするでしょう。 差し当たり、上の問題が起こると、頻繁に、ある他のTIP端末は停止できます、それでも、Hostとその時までのLOGINはHost側から掛かっている端末の仕事を止めます。 別の接続のときに通るのが可能でないなら、仕事をログアウトするように彼らに頼んで、Hostとの通話が必要であるかもしれません。 または、特定のHostと話している他のユーザが全く本当にいなければ、リセットコマンドを実行できます--このコマンドは記録されませんが、私たちはそれぞれのTIPサイトの責任者にコマンドを実行する方法を教えるつもりです。

     There is a problem related to the above problem which some TIP
users have seen. Occasionally, an IMP crashes somewhere in the network
and takes a packet of a message along with it.  Eventually, the source
of the message gets an incomplete transmission message from the
network. When the TIP gets this message, it closes the connection and
calls the destination dead. This is what most other Hosts do also, we
understand. A more reasonable thing to do might be to retransmit the
message or to tell the user and then let him continue; we would like
to do one of these. But before retransmission or letting the user

何人かのTIPユーザが認めた上の問題に関連する問題があります。 IMPは時折、ネットワークにおけるどこかでクラッシュして、それに伴うメッセージのパケットを取ります。 結局、メッセージの源はネットワークから不完全なトランスミッションメッセージを得ます。 TIPがこのメッセージを得るとき、それは、接続を終えて、目的地が死んでいると言います。 私たちは、これがまた他のほとんどのHostsがすることであることを理解しています。 するより妥当なことは、メッセージを再送するか、ユーザに言って、または次に、彼を続かせることであるかもしれません。 これらの1つをしたいと思います。 以前、「再-トランスミッション」かユーザをさせること。

                                                                [Page 3]

RFC # 386                                                     NIC #11358

[3ページ] RFC#386NIC#11358

continue, the TIP and Host's allocate counters must be resynchronized.
However, there is no Host/Host protocol way to synchronize simple
enough for the TIP to use. What may be needed is a simple Host/Host
protocol reset allocate command. We will try to understand this issue
and, again, perhaps undertake promotion of a Host/Host protocol
change.

続いてください、そして、TIPとHostのものはカウンタを割り当てます。再連動しなければなりません。 しかしながら、TIPが使用するほど簡単な状態で連動するHost/ホストプロトコル方法が全くありません。 必要であるかもしれないものは純真なHost/ホストプロトコルリセット割り当て命令です。 私たちは、この問題を理解して、再び恐らくHost/ホストプロトコル変化の販売促進を引き受けようとするでしょう。

     The above two problems explain part of the "lost allocates" but
not all. We have now instrumented the TIP program in a manner which we
hope will help us find the rest of the lost allocate problem soon.

上の2つの問題で部分がわかる、「無くなる、」 すべてを割り当てるというわけではありません。 私たちは現在、私たちが私たちが、無くなることの残りがすぐ問題を割り当てるのがわかったのを助けることを望んでいる方法によるTIPプログラムに器具を取り付けました。

     The TIP's logger (opener?) has been causing users some problems.
Upon examination, the problems were seen to originate from basic
design assumptions within the logger which we are working on changing.
In the short term, however, we think that a discussion of what the
logger is doing and how it works will alleviate some of the grief.

TIPのきこり(オープナー?)はいくつかの問題をユーザに引き起こしています。試験のときに、問題はきこりの中の私たちが変化を扱っている基本的なデザイン仮定から発すると認められました。 しかしながら、短期で、私たちは、きこりが何をしているか、そして、どのように働くかに関する議論が何らかの深い悲しみを軽減すると思います。

     For the user, opening proceeds in three phases. In the first, the
user is queued up waiting to "get" the TIP's logger.  In the second,
the user has gotten the TIP's logger and is beginning the login
sequence. In the third, the user has completed the login sequence and
is waiting for the Host to open up the actual data connections.  Many
of the problems stem from the fact that _only_one_user_ may be
proceeding through phase 2 at a time.  Hence the need for the queue of
phase 1.  Any single user may tie up phase 2 for at most about 1
minute.  This is the canonical "timeout" in the logger.  Notice that
this does not include the times in either the first or third phases.
Thus, the actual delay before you get a "timeout" after you type @L
can be 1 minute, 2 minutes, 3 minutes...depending on how many other
people are having difficulty logging in at the same time.  Abort Login
(@A L) does three different things depending on which phase of logging
in the user is in.  In phase 2 it resets the timer to be close to
overflowing so that it is responded to with a "timeout" shortly after
the command is given.  In phase 3 it does nothing at all, and in phase
1 it merely removes the user (silently) from the logging queue.

ユーザに関しては、始まりは三相で続きます。 1番目では、TIPのきこりを「得ること」を待ちながら、ユーザは列を作られます。 2番目では、ユーザは、TIPのきこりを得て、ログイン系列を始めています。 3番目では、ユーザは、ログイン系列を完了して、Hostが実際のデータ接続を開けるのを待っています。 問題の多くが__1_ユーザだけ_が一度にフェーズ2を通して続いているかもしれないという事実によります。 したがって、フェーズ1の待ち行列の必要性。 どんなシングルユーザーも高々およそ1分間フェーズ2をタイアップするかもしれません。 これはきこりの正準な「タイムアウト」です。 これが1番目か3番目のフェーズのどちらかに回を含んでいないのに注意してください。 したがって、@Lをタイプした後にあなたが「タイムアウト」を得る前に実際の遅れは1分であるかもしれません、2分、3分…何人の他の人々が同時にログインするのに苦労しているかによります。 アボートLogin(@A L)はユーザがいるログインするどのフェーズに依存する3つの別物をします。 フェーズ2では、オーバフローの近くにあるようにタイマをリセットするので、コマンドを与えたすぐ後に「タイムアウト」でそれに応じます。 フェーズ3では、全く何もしません、そして、フェーズ1では、伐採待ち行列から単に、ユーザ(静かである)を外します。

     We will, medium term, have the TIP type out something like "YOUR
LOGGER" when you get off the queue and the logger begins trying to
open your connections.  This will at least alleviate user uncertainty
as to whether he is in phase 1 or phase 2.  Long term, we will
probably make the logging process reentrant so that users will not
interact with one another quite so destructively.  In the short term,
here is a small "cookbook" on how to undo a login that seems to not be
working.

私たち、意志、中期で、あなたが待ち行列ときこりを離すとき、「あなたのきこり」があなたの接続を開こうとし始めるようにTIPはタイプで打ちます。 彼がフェーズ1かフェーズ2にいるかに関してこれはユーザの不確実性を少なくとも軽減するでしょう。 長い期間、私たちは、ユーザがお互いにそんなに破壊的に対話しないように、たぶん伐採を過程リエントラントにするつもりです。 短期で、ここに、どう働いていないように思えるログインを元に戻すかに関する小さい「料理の本」があります。

     When you have waited as long as you would like to for the login
to take place, you may type "@A L".  If the TIP responds with
"TIMEOUT" in a few second and has not typed T OPEN or R OPEN, then you

あなたがログインのために待ちたいのと同じくらい長い間行われるのを待っているとき、あなたは"@A L"をタイプできます。 TIPはいくつかで「タイムアウト」で2番目に、応じて、T戸外をタイプしていないか、そして、R開いていて、当時のあなた

                                                                [Page 4]

RFC # 386                                                     NIC #11358

[4ページ] RFC#386NIC#11358

are aborted and may attempt logging in again.  If it types "TIMEOUT"
but has typed out T OPEN or R OPEN then you should type @C and wait
for that to be responded to (You _must_ wait.) If you get no response
at all to @A L, and the TIP has typed that one or the other connection
is open, you should type @C and wait, as above.  Finally, if the TIP
makes no response and has not opened any connection, than you are free
to proceed.

中止されて、再びログインするのを試みるかもしれません。 それが「タイムアウト」をタイプしますが、T戸外かR戸外をタイプで打ったならあなたがそれが反応する@Cと待ちをタイプするべきである、(あなた、_必須_待ち)。 あなたが応答を@A Lに全く得ないで、TIPが、1かもう片方の接続がオープンであることをタイプしたなら、あなたは、@Cをタイプして、待つべきです、上です。 TIPがあなたを自由に続かせることができるより最終的に応答がなくて、また少しの接続も開いていないなら。

     From now on the name of the DEVICE CODE EXECUPORT command will be
DEVICE CODE EXTRA-PADDING, since there are a number of other terminals
which require this feature.  The latest to be added to the list is the
DATAPOINT 3300.

これから先、DEVICE CODE EXECUPORTコマンドの名前はDEVICE CODE EXTRA-PADDINGになるでしょう、この特徴を必要とする他の多くの端末があるので。 リストに追加されるべき最新のものはDATAPOINT3300です。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                      1/97 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの指示。 1/97 ]

                                                                [Page 5]

[5ページ]