RFC57 日本語訳

0057 Thoughts and Reflections on NWG/RFC 54. M. Kraley, J. Newkirk. June 1970. (Format: TXT=8360 bytes) (Updates RFC0054) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                              Mike Kraley (Harvard)
Request for Comments #57                          John Newkirk (Harvard)

ネットワークワーキンググループマイクKraley(ハーバード)はコメント#57のためにジョン・ニューカークを要求します。(ハーバード)

                                                   June 19, 1970

1970年6月19日

                Thoughts and Reflections on NWG/RFC #54

NWG/RFC#54に関する考えとReflections

       In the course of writing NWG/RFC #54 several new ideas became
apparent.  Since these ideas had not previously been discussed by the
NWG, or were sufficiently imprecise, it was decided not to include them
in the official protocol proffering.  We thought, however, that they
might be proper subjects for discussion and later inclusion in the
second level protocol.

NWG/RFC#54を書くことの間に、いくつかの新しいアイデアが明らかになりました。 これらの考えが以前にNWGによって議論されていなかったか、または十分不正確であったので、それは公式のプロトコル提供にそれらを含まないように決められました。 しかしながら、私たちは、それらが議論のための適切な対象と2番目の平らなプロトコルでの、より遅い包含であるかもしれないと思いました。

I.  Errors and Overflow

I. 誤りとオーバーフロー

       In line with the discussion in NWG/RFC #48, we felt that two
types of errors should be distinguished.  One is a real error, such as
an RFC composed of two send sockets.  This type of error can only be
generated by a broken NCP.  In the absence of hardware and software
bugs, these events should never occur; the correct response upon
detection of such an event was outlined in the description of the ERR
command in NWG/RFC #54.
       The other "error" is an overflow condition arising because
finite system resources are exhausted.  An overflow condition could
occur if an RFC was received, but there was no room to create the
requisite tables and queues.  This is not a real error, in the sense
that no one has done anything incorrect (expect perhaps the system
planners in not providing sufficient table space, etc.)  Further, a

NWG/RFC#48における議論に沿って、私たちは、2つのタイプの誤りが区別されるべきであると感じました。 1つが本当の誤りである、RFCが2で構成したので、そのようなものはソケットを送ります。 このタイプの誤りは壊れているNCPで発生できるだけです。 ハードウェアとソフトウェアのバグがないとき、これらの出来事は決して起こるべきではありません。 そのような出来事の検出の正しい応答はNWG/RFC#54における、ERRコマンドの記述に概説されました。 もう片方の「誤り」は有限の体系リソースが疲れ果てているので起こるオーバーフロー条件です。 RFCを受け取りましたが、必要なテーブルと待ち行列を作成する余地が全くなければ、オーバーフロー条件は現れるかもしれないでしょうに。 これは本当の誤りではありません、だれも何も不正確なことをしていないという(恐らく十分なテーブルスペースなどを提供しない際にシステム・プランナを予想してください)意味で 一層、a

                                                                [Page 1]

RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970

[1ページ] 1970に関する年NWG/RFC#6月54日RFC57考えとReflections

recovery procedure can be well defined, and simply entails repeating the
request at a future time.  Thus, we believe an overflow condition should
be distinguished from a real error.
       In NWG/RFC #54 an overflow condition was reported by returning
a CLS, as if the connection had been refused.  This sequence performs
the necessary functions, and leaves the connection in the correct state,
but the initiating user is misinformed.  He is deluded into thinking
that he was refused by the foreign process, when, in fact, this was not
the case.  In certain algorithms this difference is crucial.
       In further defining error conditions, we felt that it would
be helpful to specify why the error was detected, in addition to
specifying what caused the error.  While writing the pseudo-Algol
program mentioned in NWG/RFC #55 we differentiated 9 types of errors
(listed below).  We would, therefore, like to propose the extension of
the ERR message to include an 8-bit field following the op code to
designate the type of error.  This would be followed by the length and
text fields, as before.  We propose these error types;

リカバリ手順は、よく定義できて、将来の時間に要求を繰り返すのを単に伴います。 したがって、私たちは、オーバーフロー条件が本当の誤りと区別されるべきであると信じています。 NWG/RFC#54では、オーバーフロー条件は、まるで接続が拒否されたかのようにCLSを返すことによって、報告されました。 この系列は、必要な機能を実行して、正しい状態に接続を残しますが、開始しているユーザが得ている情報は間違っています。 彼が外国過程によって拒否されたと思うのに彼は欺かれます、事実上、これがそうでなかったときに。 あるアルゴリズムで、この違いは重要です。 さらにエラー条件を定義する際に、私たちは、誤りがなぜ検出されたかを指定するのに役立っていると感じました、誤りを引き起こしたことを指定することに加えて。 書いている間、疑似アルゴルプログラムは、NWG/RFC#55で私たちが9つのタイプの誤り(以下では、記載されている)を微分したと言及しました。 したがって、誤りのタイプを任命するためにオペコードに従って、8ビットの分野を含むERRメッセージの拡大を提案したいと思います。 長さとテキストフィールドは従来と同様これのあとに続いているでしょう。 私たちはこれらの誤りタイプを提案します。

       0.  UNSPECIFIED ERROR
       1.  HOMOSEX  (invalid send/rcv pair in an RFC)
       2.  ILLEGAL OP CODE
       3.  ILLEGAL LEADER (bad message type, etc.)
       4.  ILLEGAL COMMAND SEQUENCE
       5.  ILLEGAL SOCKET SPECIFICATION - COMMAND
       6.  ILLEGAL COMMAND LENGTH (last command in message was too short)
       7.  CONNECTION NOT OPEN - DATA
       8.  DATA OVERFLOW (message longer than advertised available
           buffer space)
       9.  ILLEGAL SOCKET SPECIFICATION - DATA (socket does not exist)

0. 不特定の誤り1。 HOMOSEX(病人はRFCで/rcv組を送る)2。 不法なオペコード3。 ILLEGAL LEADER(悪いメッセージタイプなど) 4. 不正コマンド系列5。 不法なソケット仕様--6を命令してください。 ILLEGAL COMMAND LENGTH(メッセージにおける持続コマンドは短過ぎた)7。 戸外ではなく、接続--データ8。 DATA OVERFLOW(メッセージの広告を出すより長い利用可能なバッファ領域)9。 不法なソケット仕様--データ(ソケットは存在していません)

                                                                [Page 2]

RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970

[2ページ] 1970に関する年NWG/RFC#6月54日RFC57考えとReflections

       In light of the other considerations mentioned earlier, we
would also like to propose an additional control command to singify
overflow:

また、より早く言及された他の問題の観点から、オーバーフローをsingifyするように追加制御コマンドを提案したいと思います:

        +-------------+-------------------+---------------------+
        |     OVF     |     my socket     |     your socket     |
        +-------------+-------------------+---------------------+

+-------------+-------------------+---------------------+ | OVF| 私のソケット| あなたのソケット| +-------------+-------------------+---------------------+

The format of the message is similar to that of the CLS message, which
it replaces in this context.  The socket numbers are 32 bits long and
correspond to the socket numbers in the RFC which is being rejected.
The semantics of an incoming OVF should be indentical to an incoming
CLS; in addition, the user should be informed that he has not been
refused but rather has overtaxed the foreign host's resources.
       An alternative to creating a separate control command can be
realized by considering the similarity between a CLS and an OVF.
Conceivably, an eight-bit field could be added to the CLS command to
define its derivation.  We believe, however, that this alternative is
conceptually inferior and practically more difficult to implement.
       Overflow does not require serious consideration if it is a
significantly rare occurrence.  We do not believe this will be the case,
and we further believe that its absence will be an unnecessary
restriction upon the user.

メッセージの形式はCLSメッセージのものと同様です。(それはこのような関係においてはメッセージを置き換えます)。 ソケット番号は、長さ32ビットであり、拒絶されているRFCのソケット番号に対応しています。 入って来るOVFの意味論は入って来るCLSへのindenticalであるべきです。 さらに、ユーザに拒否されていませんが、むしろ異種宿主のリソースを酷使したと知らされるべきです。 CLSとOVFの間の類似性を考えることによって、別々の制御コマンドを作成することへの代替手段を実現できます。 多分、派生を定義するCLSコマンドに8ビットの分野を追加できました。 しかしながら、私たちは、この代替手段は概念的に劣って実行するのが実際により難しいと信じています。 オーバーフローはそれがかなりまれな発生であるなら真剣な考慮を必要としません。 私たちは、これがそうになると信じていません、そして、さらに、不在がユーザでの不要な制限であると信じています。

                                                                [Page 3]

RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970

[3ページ] 1970に関する年NWG/RFC#6月54日RFC57考えとReflections

II.  Host Up and Host Down

II。 下に上とホストを接待してください。

       Significant problems can arise when a host goes down and then
attempts to restart.  Two cases can easily be distinguished.  The first
is a "soft" crash, where the system has prior notice that the machine is
going down; sufficient time is available to execute pre-recovery
procedures.  The other case can be termed a "hard" crash, often the
result of a system failure.  Insignificant warning is usually given; but
more important, the state of the machine after recovery is rarely
predictable.
       When a host returns from a hard crash, the network will be
in an undefined state.  Very probably the NCP's data structures are
destroyed or are meaningless.  The network has declared the host dead --
but only to processes which attempted data transmission and were
refused.  The only alternative for the crashed host is re-initialization
of its tables.  What are the alternatives for the foreign hosts?
       We would like to propose the addition of two control commands:
RESET (RST) and RESET REPLY (RSR).  Each would consist solely of an op
code with no parameters.  Upon receipt of an RST, a host would
immediately terminate all connections with the sending host, but would
not issue any CLS's.  The receiver of the RST would also note that the
originator of the RST was alive, and would then echo an RSR to the
sender.  When a host receives an RSR, he sould then note that the
echoing host is alive.  (The function of RST can be partially simulated
if a host will immediately close all relevant table entries upon
discovering that another host is down.)
       Thus, after a hard crash, all connections and request for
connections are terminated.  The RST also informs all foreign hosts that
we are again alive, and an RSR is received from every functioning NCP.
A host live table (see NWG/RFC #55) can easily be

ホストが、落ちて、次に、再開するのを試みるとき、重大な問題は起こることができます。 容易に2つのケースを区別できます。 1番目はシステムにはマシンが下っている予告があるところの「柔らかい」クラッシュです。 十分な時間は、プレリカバリ手順を実行するために空いています。 「困難な」クラッシュ、しばしばシステム障害の結果ともう片方のケースを呼ぶことができます。 通常、意味をなさない警告を与えます。 しかし、より重要であることで、回復の後のマシンの状態はめったに予測できません。 ホストが困難なクラッシュから戻るとき、ネットワークが未定義の状態にあるでしょう。 非常にたぶんNCPのデータ構造は、破壊されるか、または無意味です。 ネットワークは、ホストが死んでいると宣言しました--しかしデータ伝送を試みて、拒否された過程だけに。 墜落しているホストのための唯一の選択肢はテーブルの再初期化です。 異種宿主のための代替手段は何ですか? 2つの制御コマンドの添加を提案したいと思います: (RST)とリセット回答(RSR)をリセットしてください。 それぞれがパラメタなしで唯一オペコードから成るでしょう。 RSTを受け取り次第、ホストは、すぐに送付ホストとのすべての接続を終えるでしょうが、CLSの少しのものも発行しないでしょう。 また、RSTの受信機はRSTの創始者が生きていて、次に、送付者にRSRを反響することに注意するでしょう。 aであるときに、ホストはRSRを受け取って、彼は反響しているホストが生きているというsouldの当時のメモです。 (ホストがすぐに別のホストが下がっていると発見するときのすべての関連テーブル項目を終えるなら、RSTの機能を部分的にシミュレートできます。) したがって、困難なクラッシュの後に、接続を求めるすべての接続と要求は終えられます。 また、RSTは、私たちが再び、生きていて、RSRがあらゆる機能しているNCPから受け取られることをすべての異種宿主に知らせます。 ホストの動いているテーブル(NWG/RFC#55を見る)が容易にあることができます。

                                                                [Page 4]

RFC 57          Thoughts and Reflections on NWG/RFC #54        June 1970

[4ページ] 1970に関する年NWG/RFC#6月54日RFC57考えとReflections

assembled, and establishment of connections can resume.
       Related problems also crop up when we consider attempting
to synchronize the network, which may still be carrying messages
generated prior to the crash, with an NCP which has an initialized
environment.  We lack the facilities for unblocking links, discarding
messages, etc. -- facilities which this proposal will necessitate.
Further interaction with BBN should resolve these difficulties.
       The problems associated with "soft" crashes are not nearly
as pressing, and they demand more sophisticated (i.e., complex)
solutions.  Our preliminary experimentation with the network
demonstrates that a good initialization and recovery protocol are far
more necessary.

組み立てられる、そして、接続缶の履歴書の確立。 また、私たちが、まだクラッシュの前に発生したメッセージを伝えているかもしれないネットワークを同期させるのを試みると考えるとき、関連問題は現れます、初期化している環境を持っているNCPで。 私たちはメッセージなどを捨てて、リンクを「非-妨げ」るための施設を欠いています。 -- この提案が必要とする施設。 BBNとの一層の相互作用はこれらの困難を決議するべきです。 「柔らかい」クラッシュに関連している問題は決して同じくらい緊急ではありません、そして、彼らは、より精巧な(すなわち、複雑な)解決策を要求します。 ネットワークによる私たちの予備の実験は、良い初期化と回復プロトコルがはるかに必要であることを示します。

       Many of the ideas presented herin wre germinated and/or
jelled through conversations with Steve Crocker and Jon Postel.  We
would also like to acknowledge the assistance of Jim Balter and Charles
Kline of UCLA, who devoted a great deal of effort toward helping develop
the pseudo-Algol program which was the predecessor of much of our recent
documentation.

herin wreが寄贈された考えの多くが、スティーブ・クロッカーとジョン・ポステルとの会話で発芽する、そして/または、固められました。 また、ジム・ボルターの支援とUCLAのチャールズ・クラインを承諾したいと思います。(UCLAは私たちの最近のドキュメンテーションの多くの前任者であった疑似アルゴルプログラムを開発するのを助ける大きな努力を注ぎました)。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by  Katsunori Tanaka 2/98 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Katsunori田中2/98によるオンラインRFCアーカイブへの]

                                                                [Page 5]

[5ページ]

一覧

 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 

スポンサーリンク

EXISTS演算子 存在するか

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

上に戻る