RFC492 日本語訳

Network Working Group                                           E. Meyer
Request for Comments: 492                                    MIT-Multics
NIC: 15357                                                 18 April 1973
                          RESPONSE TO RFC 467

コメントを求めるワーキンググループE.マイヤー要求をネットワークでつないでください: 492MIT-Multics NIC: 15357 RFC467への1973年4月18日の応答

   Jerry Burchfiel and Ray Tomlinson of Bolt, Beranek, and Newman, Inc,
   have issued a Network Request for Comments (#467) which proposes a
   solution to two problems which have been annoying to Network users.
   This document will briefly describe the problems and proposed
   solutions, and offer comments and alternative suggestions.

Bolt、Beranekとニューマン、IncのジェリーBurchfielとレイ・トムリンスンは2つのNetworkユーザにとって、煩わしい問題の解決を提案するComments(#467)のためにNetwork Requestを発行しました。 このドキュメントは、簡潔に問題について説明して、解決策を提案して、コメントと代替の提案を提供するでしょう。

BACKGROUND

バックグラウンド

   To establish a data connection between two hosts through the network,
   the Host-Host protocol requires that one host send a Request for
   Connection and that the second Host reply affirmatively.  If the
   desired socket("port") at the target host is already in use, the
   target host replies negatively.  Once a connection is established,
   data transmission may proceed, controlled by data allocation messages
   dispatched by the host at the read end of the connection.  The host
   on the write side is constrained by protocol to send only as much
   data as has been permitted by the read side.  If it exhausts the
   allocation it must wait until a new data allocation control message
   is received.  Then it can send more.

ネットワークを通して2人のホストの間のデータ接続を証明するために、Host-ホストプロトコルは、1人のホストがConnectionのためにRequestを送って、第2Hostがうんと言うのを必要とします。 目標ホストの必要なソケット(「ポート」)が既に使用中であるなら、目標ホストは否定的に返答します。 接続がいったん確立される後、データ伝送を続かせるかもしれなくて、読みのホストによって派遣されたデータ配分メッセージによって制御されて、接続に終わってください。 ホスト、オンである、プロトコルで抑制された側を書いて、せいぜい読書側によって受入れられるくらいのデータだけを送ってください。 配分がそれでくたくたになるなら、新しいデータ配分コントロールメッセージが受信されるまで、それは待たなければなりません。 そして、それはさらに発信できます。

   One of the problems arises from the fact that messages apparently are
   lost somewhere in the transmission path with a low but regular
   frequency.  If an allocate control message concerning an open
   connection is lost, a situation can occur in which data transmission
   over the connection ceases permanently.  This can happen because the
   host at the send side believes it has exhausted its allocation, and
   sits holding back data to end because it is waiting for a new data
   allocation message to come from the read side.  However, the read
   side has actually sent out the allocation, but it was lost.  It
   thinks that the send side may proceed and sits waiting for data to
   come in over the connection.  This is known as the "lost allocate"
   phenomenon.  However, similar symptoms can occur if a data message is
   lost and the send side exhausts its allocation before a new
   allocation is given by the read side.  The send side waits for a new
   allocation, but the read side has not received one of the data
   messages and believes there is still some allocation left.  In either
   case, the result is a permanently blocked connection.  This appears
   to happen with enough regularity to be annoying to users who connect
   typewriters to foreign hosts through the Network.  When it happens,
   the only current solution is to disconnect and to establish a new
   connection.

問題の1つはメッセージがトランスミッション経路のどこかで明らかに低い、しかし、通常の頻度に失われているという事実から起こります。 メッセージが無くなって、接続の上のどのデータ伝送が永久にやむかで状況が起こることができるということであることがオープンな接続に関係があるコントロールを割り当ててください。 側を送ってください。これが起こることができる、ホスト、それが配分を消耗させて、読みから面がありに来るのを新しいデータ配分メッセージを待つので終わるためにデータを抑えながら座ると信じています。 しかしながら、側にはある読みが実際に配分を出しましたが、それは失われました。 側を送ってください。それを考える、データが接続の上で入るのを待っていて、続くかもしれなくて、座っています。 これが知られている、「失われて、」 現象を割り当ててください。 そして、しかしながら、データメッセージが無くなるなら同様の兆候が起こることができる、読書側で新しい配分を与える前にサイド排気に配分を送ってください。 新しい配分のためのサイド待ちを送ってくださいが、読書側は、データメッセージの1つを受け取っていなくて、何らかの配分がまだ残っていると信じています。 どちらかの場合では、結果は永久に妨げられた接続です。 これはNetworkを通してタイプライタを異種宿主に接続するユーザにとって煩わしいことができるくらいの規則性で起こるように見えます。 起こると、唯一の現在の解決策は、連絡を断って、新しい接続を確立することです。

Meyer                                                           [Page 1]

RFC 492                   RESPONSE TO RFC 467              18 April 1973

RFC467 1973年4月18日へのマイヤー[1ページ]RFC492応答

   The solution to this problem which RFC 467 proposes is to establish a
   pair of allocation-resetting control messages, one for use by the
   send side (RCS) and the other for the read side (RCR).  Whenever it
   wishes, either side may initiate the allocation-resetting sequence by
   setting its own allocation counter to zero and dispatching an RCS or
   RCR control message to the other side.  The host receiving it will
   set its own allocation counter for that connection to zero and send
   an RCR or RCS in reply.  Now the allocations for both sides are in
   synchronization (they are zero), and data transmission can begin
   again when a new allocation is sent by the receive side.  This
   procedure is intended to be initiated whenever either side thinks the
   connection has been quiescent for a suspiciously long time.  The
   actual specification of this control message pair in RFC 467 is more
   complex in that the pipeline between the two sides must be empty of
   data messages before the send side may dispatch an RCS control
   message.

RFC467が提案するこの問題の解決が1組の配分をリセットするコントロールメッセージ、使用のためのものを確立することである、読みのための(RCS)ともう片方が面がある側(RCR)を送ってください。 願っているときはいつも、どちらの側もそれ自身の配分カウンタをゼロに設定して、RCSを派遣するのによる配分をリセットする系列か反対側へのRCRコントロールメッセージを開始するかもしれません。 それを受けるホストは、その接続のためのそれ自身の配分カウンタをゼロに設定して、回答でRCRかRCSを送るでしょう。 現在、両側のための配分が同期中であり(それらはゼロです)、新しい配分で発信するときデータ伝送がやり直すことができる、側を受け取ってください。 どちらの側も、接続がいぶかしげに長い時間静かであると思うときはいつも、この手順が開始されることを意図します。 側を送ってください。2つの側の間のパイプラインは以前データメッセージがないに違いないのでRFC467のこのコントロールメッセージ組の実際の仕様が、より複雑である、RCSコントロールメッセージを派遣してもよいです。

   The second problem arises when the host at one side of an open
   connection crashes and purges its tables when it comes back up, while
   the host at the other end of the connection does not notice that
   anything has happened. (A similar situation occurs when the Network
   path temporarily fails between the two hosts, but only one host
   notices the failure and closes the connection.) If the host which
   crashed attempts to re-establish the connection, the host at the
   other end refuses to do so because the socket to which the connection
   request is targeted is seemingly already involved in an open
   connection.  Given the idiosyncrasies of the terminal support
   software of some systems, users at some consoles may be unable to
   reconnect to the distant system they were connected with when the
   local system supporting his terminal crashed.  This can continue
   indefinitely until the system which believes the original connections
   to be still open resets its internal state.  This is call the "half-
   closed" phenomenon, and a solution is proposed in RFC 467.  The basic
   principle of the RFC 467 proposal is that the side which has the open
   connection is able to detect an inconsistency whenever either side
   performs communication regarding this connection.  When it does, it
   is supposed to silently (without regard to normal protocol) close the
   connection and be ready to handle connection requests to the
   previously connected port.

来て戻るとき、オープンな接続の半面のホストがテーブルを墜落して、掃除するとき、2番目の問題は起こります、接続のもう一方の端のホストが、何も起こったのに気付きませんが。 (Network経路が2人のホストの間で一時失敗すると同様の状況が起こりますが、1人のホストだけが、失敗に気付いて、接続を終えます。) ホストであるなら、どれがクラッシュしたかが接続を復職させるのを試みて、もう一方の端のホストは、接続要求が狙うソケットが外観上既にオープンな接続にかかわるのでそうするのを拒否します。 彼の端末を支えるローカルシステムがクラッシュしたとき、いくつかのシステムの端末の支援ソフトウェアの特異性を考えて、いくつかのコンソールのユーザはそれらが接続された遠方のシステムに再接続できないかもしれません。 オリジナルの接続がまだオープンであると信じているシステムが内部の状態をリセットするまで、これは無期限に続くことができます。 これは「半分閉じている」現象を呼ぶことです、そして、解決策はRFC467で提案されます。 RFC467提案の基本原理はどちらの側がもこの接続に関するコミュニケーションを実行するときはいつも、オープンな接続がある側が矛盾を検出できるということです。 扱うとき、それは、静かに接続を終えて(正常なプロトコルへの尊敬なしで)、以前接続されたポートに接続要求を扱う準備ができているべきです。

   There are two types of interactions in which "half-closed"
   inconsistency is uncovered.  The first case occurs when the connected
   side sends a message over a write connection.  The side which has
   lost the connection receives this as a data message which does not
   correspond to an open connection and replies with an Error Report
   control message.  When the connected side receives it, it realizes
   that the connection actually no longer exists and deletes it from its
   own tables.  The second case occurs when the host which has lost the

「半開きな」矛盾がむき出しである2つのタイプの相互作用があります。 接続側がaの上のメッセージが接続に書くaを送るとき、最初のケースは現れます。 接続を失った側はError Reportコントロールメッセージでオープンな接続と回答と食い違っているデータメッセージとしてこれを受けます。 接続側がそれを受けるとき、それは、接続が実際にもう存在しないとわかって、それ自身のテーブルからそれを削除します。 ホストであるときに、2番目のケースは現れます(損をしました)。

Meyer                                                           [Page 2]

RFC 492                   RESPONSE TO RFC 467              18 April 1973

RFC467 1973年4月18日へのマイヤー[2ページ]RFC492応答

   connection sends a connection request to the other host specifying
   the same sockets as were involved in the previous connection.  The
   host receiving this request recognizes the inconsistency, because not
   only is the local socket already connected, it is connected to the
   same foreign socket as specified in the connection request.  It
   internally deletes its record of the connection, making the local
   socket free, and responds to the connection request normally.

接続は前の接続にかかわったのと同じソケットを指定するもう片方のホストに接続要求を送ります。 この要求を受け取るホストが矛盾を認める、地方のソケットが既に接続されるだけではなく、それは接続要求における指定されるのと同じ外国ソケットに接続されます。 通常、それは、地方のソケットを自由にして、内部的に接続に関する記録を削除して、接続要求に応じます。

COMMENTS AND ALTERNATIVE PROPOSALS

コメントと代案

   The Project MAC Computer Systems Research Division opposes both
   protocol change proposals in this RFC.  We have moderate opposition
   to the proposal to handle half-closed connections because it fails to
   consider all aspects of the problem and it further complicates the
   protocol, but very strong opposition to the proposal for allocation
   resynchronization because it attacks a symptom, not the disease, and
   furthermore tends to mask diagnosis of a potentially very serious
   network problem.

Project MACコンピュータシステムズResearch事業部はこのRFCでの両方のプロトコル変化提案に反対します。 問題の全面を考えないで、さらにプロトコルを複雑にするので半開きな接続を扱うという提案に適度の反対を持っていますが、病気ではなく、兆候を攻撃して、その上、潜在的に非常に重大なネットワーク問題の診断にマスクをかける傾向があるので、私たちは配分再同期のための提案に非常に強い反対を持っています。

   RFC 467 proposes the addition of two control messages, Reset
   Connection by Sender (RCS) and Reset Connection by Receiver (RCR)
   whose sole purpose is to resynchronize the allocation counters at
   both ends of a connection.  In this way the "lost allocate"
   phenomenon, in which allocate (ALL) control messages somehow are lost
   in transmission so that the sending side is unable to continue
   transmitting data is solved.  If it were truly a "lost allocate"
   problem, this would be viable solution.  However, I feel that this is
   really a "lost message" problem, in which messages of all kinds are
   being lost in transmission, which is much more serious.  ALL messages
   may be very frequent in communications with some hosts and these may
   be the ones most often lost, but if messages are actually lost in the
   network, it may also be data messages that are being lost, which
   would provide similar symptoms.  A lost message in a Telnet
   connection can be detected and overcome by the human user, but an
   undetected lost message from the middle of a transmitted file can
   have disastrous consequences, especially because the invalid file, if
   ever detected, can perhaps not be corrected.  Because this "solution"
   tends to paper over the immediate problem and to propagate it to a
   point far removed in both space and time at which it appears as an
   incomprehensible disaster, it should be strongly opposed.

接続の両端で配分カウンタを再連動させる唯一の目的がことであるReceiver(RCR)でRFC467は2つのコントロールメッセージの添加、Reset Connectionごとに提案します。 このよう、「失われて、」 現象を割り当ててください、どれがメッセージがどうにか失われている(すべて)のコントロールにトランスミッションを割り当てるかで解決されて。 本当に、それがaである、「失われて、」 問題を割り当ててください、そして、これは実行可能な解決策でしょう。 しかしながら、私は、これが本当に「無くなっているメッセージ」問題であると感じます。(すべての種類に関するメッセージはトランスミッションでそれで失われています)。(それは、はるかに重大です)。 すべてのメッセージが何人かのホストとのコミュニケーションで非常に頻繁であるかもしれません、そして、これらはたいてい失われたものであるかもしれませんが、メッセージが実際にネットワークで失われているなら、また、それは負けられていて、同様の兆候を供給するデータメッセージであるかもしれません。Telnet接続における無くなっているメッセージは、人間のユーザで検出されて、打ち勝つことができます; しかし、伝えられたファイルの中央からの非検出された無くなっているメッセージは惨憺たる結果を持つことができます、特に今までに検出されるなら恐らく無効のファイルを修正できないので。 この「解決策」は手近な問題の上で紙の傾向があって、それがそれが不可解な災害として現れるスペースと時間の両方で遠くに移されたポイントにそれを伝播するために強く反対されるべきであるので。

   The real problem appears to be the random undetected loss of messages
   somewhere in the transmission path.  A true solution to this problem
   is either a) to eliminate the cause of undetected loss of messages,
   or b) to move to a new protocol which is designed to cope with an
   unreliable physical transmission path.  Either of these solutions is

実際の問題はトランスミッション経路のどこかのメッセージの無作為の非検出された損失であるように見えます。 この問題の真溶液は、メッセージの非検出された損失の原因を排除するa)か頼り無い物理的なトランスミッション経路に対処するように設計されている新しいプロトコルに動かすb)のどちらかです。 これらの解決策のどちらかがそうです。

Meyer                                                           [Page 3]

RFC 492                   RESPONSE TO RFC 467              18 April 1973

RFC467 1973年4月18日へのマイヤー[3ページ]RFC492応答

   some distance away.  A proposed interim solution which modifies the
   existing GVB and RET commands and which has the additional feature of
   simplifying them somewhat is outlined below.

何らかの距離で遠くへ。 既存のGVBとRETコマンドを変更して、それらを簡素化する付加的な機能を持っている提案された当座の解決策は以下にいくらか概説されています。

   A receiving host may at an arbitrary time issue a Give-Back
   allocation (GVB) control message for a connection.

受信ホストは任意の時に接続のためにGive逆配分(GVB)コントロールメッセージを発行するかもしれません。

             8       8        8        8
         +-------+-------+--------+--------+
         |  GVB  | link  | f =255 | f =255 |
         |       |       |  m     |  b     |
         +-------+-------+--------+--------+

8 8 8 8 +-------+-------+--------+--------+ | GVB| リンク| f=255| f=255| | | | m| b| +-------+-------+--------+--------+

   The format of this GVB message is the same as that currently defined,
   except that the fraction fields f(m) and f(b) are required to all 1s.
   This is designed to provide a measure of upward compatibility.  A
   host operating under the modified protocol will ignore the fraction
   fields, but under the current protocol this message means return
   everything.  A sending host which receives a GVB control message
   immediately ceases transmission on the specified link.  When the RFNM
   from the last message transmitted is received (indicating an empty
   pipeline), the sending host issues a Return Allocation (RET) control
   message, returning the remaining allocation.

このGVBメッセージの形式は現在定義されているそれと同じです、断片分野のf(m)とf(b)がすべての1に必要であるのを除いて。 これは、上位互換性の基準を提供するように設計されています。 変更されたプロトコルの下で働いているホストは断片分野を無視するでしょうが、現在のプロトコルの下では、このメッセージは、すべてを返すことを意味します。 すぐにGVBコントロールメッセージを受け取る送付ホストは指定されたリンクの上にトランスミッションをやめます。 送られた最後のメッセージからのRFNMが受け取られているとき(空のパイプラインを示して)、送付ホストはReturn Allocation(RET)コントロールメッセージを発行します、残っている配分を返して。

              8      8        16         32
          +------+------+-----------+-----------+
          | RET  | link | msg space | bit space |
          +------+------+-----------+-----------+

8 8 16 32 +------+------+-----------+-----------+ | 浸水してください。| リンク| msgスペース| 噛み付いているスペース| +------+------+-----------+-----------+

   The modified RET command has the same format as that currently
   defined.  The two differences are that it can not be sent until data
   transmission ceases and the last RFNM is received, and that it must
   return all remaining allocation for the send link (i.e., the
   allocation counters are set to zero).

変更されたRETコマンドには、現在定義されているそれと同じ形式があります。 2つの違いがそれがデータ伝送がやんで、最後のRFNMが受け取られているまでそれを送ることができないで、すべての残っている配分を返さなければならないそれである、リンク(すなわち、合わせてくださいカウンタが設定されるゼロ配分)を送ってください。

   When the host on the read side of the connection receives the RET
   message, the allocation counters at the send side are zero and the
   pipeline is empty.  Therefore, if no error has occurred during the
   connection, the allocation returned in the RET message should be the
   same as the allocation in the counters of the read side of the
   connection.  If so, the read side can proceed to send a new
   allocation secure in the knowledge that no message has been lost.  If
   the two sets of values do not agree, some error in the transmitted
   data may have occurred.  What to do in that case is a local host
   option.  Some hosts may choose to close the connection, while others
   may choose to resume transmission by sending a new allocation to the

発信してください。読みのホストであるときに、接続の側面はRETメッセージを受け取ります、と配分が反対する、側がゼロとパイプラインが空であるということです。 したがって、読みのカウンタでの配分と同じくらいが接続の側面であるべきであり、誤りが全く接続の間、発生していないなら、配分はRETメッセージで戻りました。 そうだとすれば、読書側はメッセージが全く失われていないという知識で安全な新しい配分を送ることができかけます。 2セットの値が同意しないなら、伝えられたデータにおける何らかの誤りが発生したかもしれません。 するべきことはその場合ローカル・ホストオプションです。 他のものが、新しい配分を送るトランスミッションを再開するのを選ぶかもしれない間の接続を終えます何人かのホストが、選ぶかもしれない。

Meyer                                                           [Page 4]

RFC 492                   RESPONSE TO RFC 467              18 April 1973

RFC467 1973年4月18日へのマイヤー[4ページ]RFC492応答

   sending side.  I feel that as a minimum a host should send a message
   indicating the error both to the user and to some human being at the
   host responsible for monitoring network performance.

側を送ります。 私は、最小限として、ホストがメッセージにモニターしているネットワーク性能に責任があるホストでユーザと、そして、人間に誤りを示させるべきであると感じます。

   This modified control message pair is capable of both its originally
   intended function,and of detecting errors and resynchronizing
   allocations (if desired) when initiated by the receiving side.  I
   feel that the inability of this scheme to initiate allocation
   checking from either side is only a minor disadvantage which is more
   than compensated for by its positive features: this scheme gives
   positive indication that an error has occurred (the proposed RCS/RCR
   method conceals errors), and this minor change to the protocol may
   mean a correspondingly minor change to NCP's.

受信側によって開始されると、この変更されたコントロールメッセージ組は、両方の元々意図した機能で、誤りを検出して、配分を再連動させることができます(望まれているなら)。 私は、この計画がどちらの側からもチェックする配分を開始できないことが上向きの特徴によって補われるより多い小さい方の不都合であるにすぎないと感じます: この計画が誤りが発生したという(提案されたRCS/RCR方法は誤りを隠します)積極的な指示を与えて、プロトコルへのこのマイナーチェンジが意味するかもしれない、対応、マイナーチェンジ、NCPのものに。

   I have negative feelings regarding the solution to the "half-closed"
   problem proposed in RFC 467.  To put additional burden on the RTS and
   STR commands not only unduly complicates the protocol, but in some
   sense can make operation less fail-safe and problems more obscure.
   My main objection concerns the action to be taken when control
   messages are received which conflict with the current state of the
   receiving NCP.  This proposal suggests that an NCP receiving an STR
   or RTS for a socket it believes to be connected assume something
   about the state of the foreign NCP (that the foreign NCP has closed
   the connection) and automatically change its own state to agree with
   the assumed state at the other end (close the connection at its end).
   This may work fine if the assumption is correct and the
   implementations are free from bugs.  However, the following
   situations could cause problems that are perhaps hard to diagnose: 1)
   the foreign NCP has a bug which causes it to send an RTS or STR for a
   connected socket, 2) the foreign NCP chooses to interpret the queuing
   option of the current protocol as permitting RFC's to be sent for
   already connected sockets, or 3) the local NCP has a bug which
   erroneously causes it to regard RFC's coming from a different host or
   from the particular foreign host but concerning a different foreign
   socket as pertaining to the open connection attached to the target
   socket.

私には、RFC467で提案された「半開きな」問題の解決に関する負の感情があります。 RTSとSTRコマンドに追加負担を置くのは、何らかの意味で操作をよりフェールセイフでなくして、プロトコルを過度に複雑にするだけではありませんが、問題は、より不鮮明になる場合があります。 コントロールメッセージが受信されているとき、私の主な異論は、行動が取られるのが関係があります(受信NCPの現状と衝突します)。 外国NCPは閉じました。この提案が、それが接続されると信じているソケットのためのSTRを受けるNCPかRTSが外国NCPの状態に関して何かを仮定するのを示す、(それ、接続) そして、自動的にそれ自身のものがもう一方の端(接続を終わりに終える)のときに想定された状態に同意するために述べる変化。 仮定が正しく、実現がバグを持っていないなら、これはきめ細かに働くかもしれません。 しかしながら、以下の状況は恐らく診断しにくい問題を引き起こす場合がありました: 1) 外国NCPはそれが目標ソケットに取り付けられたオープンな接続に関係するとそれが誤ってRFCのものを見なすバグがRFCを可能にします既に接続されたソケット、または3のために送られる) ローカルのNCPで異なったホスト、または、特定の異種宿主から来ますが、異なった外国ソケットに関して現在のプロトコルの列を作りオプションを解釈するためにRTSか接続ソケット、外国NCPが選ぶ2のための)STRを送るバグを持っています。

   A second objection is that this proposal does not cover all
   possibilities.  Two likely possibilities are: another socket (from
   any host) attempts to connect to the socket involved in the dead
   connection.  Second, the host that lost a connection attached to one
   of its read sockets makes another connection with different sockets,
   but uses the same link number that implemented the previous
   connection.  The second case can be handled by additional
   complications to the protocol.  However, the first case is
   symptomatically identical to the situation in which an RFC is issued
   for a genuinely already-connected socket.  It can not be handled
   using this approach.

2番目の異論はこの提案がすべての可能性をカバーするというわけではないということです。 2つのありそうな可能性は以下の通りです。 別のソケット(どんなホストからのも)は、停止コネクションにかかわるソケットに接続するのを試みます。 2番目に、読書ソケットの1つに付けられた接続を失ったホストは、異なったソケットとの別の接続を作りますが、前の接続を実行したのと同じリンク番号を使用します。 プロトコルへの追加複雑さで2番目のケースを扱うことができます。 しかしながら、最初のケースはRFCが既に本当に接続されたソケットのために発行される状況と徴候的に同じです。 このアプローチを使用することでそれを扱うことができません。

Meyer                                                           [Page 5]

RFC 492                   RESPONSE TO RFC 467              18 April 1973

RFC467 1973年4月18日へのマイヤー[5ページ]RFC492応答

   I believe that a more rigorous use of the existing Reset Host (RST)
   control message would eliminate most of the causes of the "half-
   closed" phenomenon; viz. one of the hosts involved in a connection
   goes down without sending an RST when it comes back up; or the
   network between the two hosts partitions, and only one host notes it.
   If it were deemed necessary, a pair of Reset Link control commands to
   reset an individual link could be added to the protocol to cope with
   instance of the "half-closed" phenomenon due to other causes.

私は、既存のReset Host(RST)コントロールメッセージの、より厳しい使用が「半分閉じている」現象の原因の大部分を排除すると信じています。 つまり、来て戻るときRSTを送らないで、接続にかかわるホストのひとりは落ちます。 または、2つの間のネットワークはパーティションを主催します、そして、1人のホストだけがそれに注意します。 それが必要であると考えられるなら、他の原因による「半開きな」現象の例に対処するために個々のリンクをリセットするReset Link規制命令の1組をプロトコルに追加できるでしょうに。

   I'd like to set down here a number of principles which I think are at
   least peripherally concerned with alleviating the "half-closed"
   phenomenon.  None of these is explicitly stated in the current Host-
   Host protocol document, but I believe that their enunciation would
   tend to alleviate confusion caused by network and host failures.

ここに私が周囲に「半開きな」現象を軽減するのに少なくとも関すると思う多くの原則を置きたいと思います。 これらのいずれも現在のHostホストプロトコルドキュメントに明らかに述べられていませんが、私は、彼らの発音が、ネットワークとホスト障害によって引き起こされた混乱を軽減する傾向があると信じています。

      1. A NCP which receives an Imp-to-Host message type 7 (Host Dead)
         concerning a host should consider all connections or connection
         attempts with that host as dead and should purge them from its
         tables.

1. ホストに関してImpからホストへのメッセージタイプ7(ホストDead)を受けるNCPは、そのホストとのすべての接続か接続試みが死んでいると考えるべきであり、それらからテーブルから追放するべきです。

      2. When after noting a foreign host as dead (by receiving a "Host
         Dead" Imp-to-Host message), an NCP receives any message from
         that host other than a Reset Host (RST) control message, it
         should delete the message and respond with an RST.  It should
         respond normally to a received RST.

2. それは、メッセージを削除して、Reset Host(RST)コントロールメッセージを除いて、NCPがそのホストからどんなメッセージも全く(「ホスト死者」Impからホストへのメッセージを受け取ることによって)受け取るので異種宿主に注意した後にRSTと共に応じるべきです。通常、容認されたRSTに応じるはずです。

      3. Two hosts must exchange the RST - RRP reset control message
         pair prior to any other form of communications.  An RST must
         first be sent by an NCP wishing to start communications with a
         foreign host if that host pair has not been previously reset
         since the local NCP came up or it noted the foreign NCP as
         down.  Note that this does not require an NCP to send resets to
         all other hosts each time it comes up.

3. 2人のホストがいかなる他のフォームに関するコミュニケーションのRRPリセットコントロールメッセージ組前にもRSTを交換しなければなりません。 ローカルのNCPが来たか、または外国NCPを書き留めて以来そのホスト組が以前にリセットされていないなら異種宿主とのコミュニケーションを始めたがっているNCPは最初に、RSTを送らなければなりません。 これが来るたびに他のすべてのホストにリセットを送るためにNCPを必要としないことに注意してください。

      4. An NCP which receives an Imp-to-Host message type 9 (Incomplete
         Transmission) concerning a write link implementing an open
         connection, may at its option make several tries to retransmit
         the last message until a RFNM is received or the NCP gives up.
         However, unless the message is eventually successfully
         transmitted to the foreign host the NCP must abort the
         connection, sending out a CLS control message.  The successful
         implementation of retransmission depends on the retransmitting
         host to wait for a RFNM on a data link before sending a
         subsequent message and on all hosts to be able to discard
         messages which are not completely received.

4. RFNMが受け取られているまでImpからホストへのaに関するタイプ9(不完全なTransmission)がオープンな接続を実行するリンクを書いて、最終を再送するいくつかのトライに任意に通信させるかもしれないメッセージを受け取るNCPかNCPがあきらめます。 しかしながら、メッセージが結局首尾よく異種宿主に送られない場合、NCPは接続を中止しなければなりません、CLSコントロールメッセージを出して。 「再-トランスミッション」のうまくいっている実現は、その後のメッセージを送る前のデータ・リンクの上と、そして、すべてのホストの上のRFNMが完全に受け取られるというわけではないメッセージを捨てることができるのを待つために再送しているホストに頼っています。

Meyer                                                           [Page 6]

RFC 492                   RESPONSE TO RFC 467              18 April 1973

RFC467 1973年4月18日へのマイヤー[6ページ]RFC492応答

      5. An NCP which receives a message from a foreign host that seems
         inconsistent with its current state should take no action to
         modify that state.  Rather it should send an ERR error control
         message specifying the type of inconsistency and discard the
         inconsistent message.  An NCP receiving an ERR message should
         log it for human inspection and is then allowed to silently
         modify its internal state or send out control messages in order
         to remove the inconsistency. (This is an extension of the
         proposal in RFC 467 that an NCP should delete a connection when
         it receives an ERR message specifying that the link involved is
         unknown.)

5. 現状で矛盾しているように見える異種宿主からメッセージを受け取るNCPは、その状態を変更するために行動を全く取るべきではありません。 むしろそれは、ERR誤り制御メッセージに矛盾のタイプを指定させて、矛盾したメッセージを捨てるべきです。 ERRメッセージを受け取るNCPは、矛盾を取り除くために人間の点検のためにそれを登録して、次に、静かに内部の状態を変更するのが許容されるべきであるか、またはコントロールメッセージを出すべきです。 (これはかかわるリンクが未知であると指定するERRメッセージを受け取るとき、NCPが接続を削除するべきであるというRFC467での提案の拡大です。)

        [This RFC was put into machine readable form for entry]
   [into the online RFC archives by Helene Morin, Via Genie,12/1999]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ヘレーネのモーリン、Via GenieによるオンラインRFCアーカイブへの12/1999]

Meyer                                                           [Page 7]

マイヤー[7ページ]