RFC39 日本語訳

0039 Comments on Protocol Re: NWG/RFC #36. E. Harslem, J.F. Heafner. March 1970. (Format: TXT=4779 bytes) (Updates RFC0036) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                         E. Harslem
Request for Comments: 39                                      J. Heafner
                                                                    RAND
                                                           25 March 1970

Harslemがコメントのために要求するワーキンググループE.をネットワークでつないでください: 39 J.Heafner底ならし革1970年3月25日

                  COMMENTS ON PROTOCOL RE: NWG/RFC #36

プロトコルRE:のコメント NWG/RFC#36

   We offer the following suggestions to be considered as additions to
   the April 28th 1970 protocol grammar specifications.

私たちは、1970年4月28日のプロトコル文法仕様への追加であるとみなされるために以下の提案を提供します。

   ERROR MESSAGES

エラーメッセージ

        <ERR> <Code> <Command in error>

<のCodeの>の<のCommandの間違ったERR><>。

   It is desirable to include debugging aids in the initial protocol for
   checking out Network Control Programs, etc.

Network Control Programsなどを調べるための初期のプロトコルにデバッギング・エイドを含んでいるのは望ましいです。

   There are three classes of errors--content errors, status errors, and
   resource allocation or exhaustion. <Code> specifies the class and the
   offending member of the class.  The command is returned to the
   sending NCP for identification and analysis.

3つのクラスの誤り--満足している誤りがあって、状態が誤りであり、リソースは、配分か疲労困憊です。 <コード>はクラスと怒っているクラスの一員を指定します。 識別と分析のために送付NCPにコマンドを返します。

   Examples of status errors are: messages sent over blocked links and
   attempts to unblock an unblocked link.  Examples of content errors
   are: an invalid RFC complete; a message sent on a link not connected;
   closing of an unconnected link; and an attempt to unblock an
   unconnected link.  Examples of resource errors are:  a request for a
   non-existent program and connection table overflow, etc.  Resource
   errors should be followed by a <CLS> in response to the <RFC>.

状態誤りに関する例は以下の通りです。 移動されたメッセージは、リンクを妨げて、「非-妨げ」られたリンクを非ブロックに試みます。 満足している誤りに関する例は以下の通りです。 RFCが完成する病人。 メッセージは、リンクが接続しなかったのを転送しました。 無関係のリンクの閉鎖。 そして、無関係のリンクを「非-妨げ」る試み。 リソース誤りに関する例は以下の通りです。 実在しないプログラムと接続テーブルオーバーフローを求める要求など リソース誤りは<RFC>に対応して<CLS>によって続かれるはずです。

   QUERIES

質問

        <QRY> <My   Socket>  < >

<QRY><は私のソケット><>です。

   or   <QRY> <Your Socket>  <Text>

<QRY><はあなたのソケット><テキスト>をそうします。

   Queries provide an extension to the <ERR> facility as well as limited
   error recovery, thus avoiding re-initialization of an NCP.

質問は限られたエラー回復と同様に<ERR>施設に拡大を提供して、その結果、NCPの再初期化を避けます。

   The first command requests the remote NCP to supply the status of all
   connections to the user specified by the user number in <My socket>.
   The second is the reply; <Text> contains the connection status
   information.  If an NCP wants the status of all connections to a
   remote HOST, the <My Socket> is zero.

最初のコマンドは、<Myソケット>でユーザ番号によって指定されたユーザにすべての接続の状態を供給するようリモートNCPに要求します。 2番目は回答です。 <テキスト>は接続形態情報を含んでいます。 NCPがすべての接続の状態をリモートHOSTに必要とするなら、<My Socket>はゼロです。

Harlsem & Heafner                                               [Page 1]

RFC 39            COMMENTS ON PROTOCOL RE: NWG/RFC #36        March 1970

プロトコルRE:のHarlsem&Heafner[1ページ]RFC39コメント 1970年のNWG/RFC#3月36日

   PROGRAM TERMINATION NOTIFICATION

プログラム終了処理通知

        <TER> <My Socket>

<TER><は私のソケット>です。

   This command supplements rather than replaces <CLS>.  It severs all
   communication between a program and those programs in a given HOST to
   which it is connected.  This command performs what would otherwise be
   handled by multiple <CLS> commands. <My Socket> contains the sender's
   user number.

このコマンドは<CLS>を取り替えるよりむしろ補われます。 それは接続されている与えられたHOSTでプログラムとそれらのプログラムとのすべてのコミュニケーションを断ち切ります。 このコマンドはそうでなければ複数の<CLS>コマンドで扱われることを実行します。 <、私のSocket>は送付者のユーザ番号を含んでいます。

   HOST STATUS

ホスト状態

        <HCU>
        <HGD>

<HCU><HGD>。

   These messages (HOST coming up and HOST voluntarily going down) are
   compatible with asynchronous, interrupt-driven programs, as opposed
   to the more conventional post/poll method.

これらのメッセージ(来るHOSTと自発的に落ちるHOST)は非同期で、中断駆動のプログラムと互換性があります、より従来のポスト/投票メソッドと対照的に。

   TRANSMIT AND BROADCAST

AND放送を伝えてください。

        <TRN> <Body>
        <BDC> <Body>

<TRN><ボディー><BDC><ボディー>。

   Unlike the previous commands, these are not sent over the control
   link, but rather over links assigned to user programs.  The prefix of
   <TRN> or <BDC> indicates, to the receiving NCP, the disposition of
   the message body. <TRN> indicates a message to be passed to a single
   process. <BDC> specifies to the destination NCP that the message is
   to be distributed over all receiving connections linked to the
   sender.  In response to a system call by the user to an NCP
   requesting <BDC>, the NCP generates one <BDC> to each HOST to which
   the sender is connected.

前のコマンドと異なって、これらはコントロールリンク、しかし、むしろユーザ・プログラムに割り当てられたリンクの上に送られません。<TRN>か<BDC>の接頭語はメッセージ本体の気質を受信NCPに示します。 <TRN>は単一のプロセスに通過するべきメッセージを示します。 <BDC>は、メッセージが送付者にリンクされた接続を受けながらすべて上に分配されることであると目的地NCPに指定します。 <BDC>を要求するNCPへのユーザによるシステムコールに対応して、NCPは、1<がBDC>であると送付者が接続されている各HOSTに生成します。

   RFC AND DYNAMIC RECONNECTION

RFCとダイナミックな再接続

   This protocol is complex; it proliferates control messages; it causes
   queues (to become associated with re-entrant procedures) that are
   artificially imposed via the protocol (remote AEN assignment); and
   discounts the situation where only controlling process "A" has
   knowledge that slave process "B" should be "rung out" in a dynamic
   reconnection.

このプロトコルは複雑です。 それはコントロールメッセージを増殖させます。 それはプロトコル(リモートAEN課題)で人工的に課される待ち行列(リエントラント手順に関連するようになる)を引き起こします。 そして、プロセス「A」を制御するだけであるなら奴隷プロセス「B」がダイナミックな再接続で「外では、鳴らされるべきである」という知識が持たれている状況を無視します。

   The <ERR>, etc., are suggestions for inclusion as additions in the
   April 28th protocol specifications.  The above criticism is, of
   course, not intended to affect modification of the RFC structure by
   April 28th, nor to reflect on those who planned it.  We have not
   studied the problem.  It is meant, however, to voice our concern

4月の追加が28番目に仕様を議定書の中で述べるとき、<ERR>などは包含のための提案です。 上の批評は、4月28日までにRFC構造の変更に影響して、それを計画していた人をよく考えることをもちろん意図しません。 私たちは問題を研究していません。 しかしながら、それは私たちの関心を声に出すことになっています。

Harlsem & Heafner                                               [Page 2]

RFC 39            COMMENTS ON PROTOCOL RE: NWG/RFC #36        March 1970

プロトコルRE:のHarlsem&Heafner[2ページ]RFC39コメント 1970年のNWG/RFC#3月36日

   about complexity and resulting response times.  This is a difficult
   problem and it deserves more study after we have exercised the
   current RFC specifications.  We hope to offer constructive
   suggestions with respect to the RFC in the future.

複雑さと結果として起こる応答時間に関して。 これは難問です、そして、私たちが現在のRFC仕様を運動させた後にそれは、より多くの研究に値します。 私たちは、将来RFCに関して建設的な提案を提供することを望んでいます。

   JFH:hs

JFH: hs

         [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Mario Vitale 08/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][マリオ・ビターレ08/99によるオンラインRFCアーカイブへの]

Harlsem & Heafner                                               [Page 3]

Harlsem&Heafner[3ページ]

一覧

 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 

スポンサーリンク

/= 演算子

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

上に戻る