RFC642 日本語訳

0642 Ready line philosophy and implementation. J.D. Burchfiel. July 1974. (Format: TXT=8414 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                    Jerry Burchfiel
Request for Comments: 642                                            BBN
NIC: 30872                                                  July 5, 1974

ネットワークワーキンググループジェリーBurchfielはコメントのために以下を要求します。 642BBN NIC: 30872 1974年7月5日

                Ready Line Philosophy and Implementation

持ち合わせの線哲学と実装

I.  Introduction

I. 序論

   BBN Report #1822, Specifications for the Interconnection of a Host
   and an IMP, gives a complete specification of the Host-IMP interface.
   However, the authors of this document bent over backward to avoid
   issuing arbitrary dictatorial directives to host interface
   implementors.  They succeeded admirably in this goal by describing
   the IMP implementation, and suggesting similar behavior on the part
   of the host.

BBN Report#1822(HostとIMPのInterconnectionのためのSpecifications)はHost-IMPインタフェースの完全な仕様を与えます。 しかしながら、このドキュメントの作者は、任意の独裁指示をホスト・インターフェース作成者に発行するのを避けるのに懸命に取り組みました。 IMP実装について説明して、ホスト側の同様の振舞いを示すことによって、彼らはこの目標に見事に成功しました。

   ARPA has appointed a PDP-11 local host interface standardization
   committee composed of myself, Dave Retz of SCRL, and Yuval Peduel of
   MIT Lincoln Labs.  During our review of various interfaces designed
   by the ARPA community, we have found total chaos, confusion and
   misunderstanding about the recommended host interface implementation.

ARPAは自分で構成されたPDP-11ローカル・ホストインターフェースの標準化委員会、SCRLのデーヴ・レス、およびMITのYuval PeduelをリンカーンLabsに任命しました。 私たちのARPA共同体によって設計された様々なインタフェースのレビューの間、私たちはお勧めのホスト・インターフェース実装に関する全面的な混乱状態、混乱、および誤解を見つけています。

   This note is an attempt to make explicit the recommendations which
   are implicit in Report #1822.  It provides a cookbook for interface
   implementors, including a set of recommended do's and don't's in the
   common problem areas.  This document has been reviewed and approved
   by the BBN IMP group.

この注意は1822年にReport#暗黙であることの推薦状を明白にする試みです。 そしてインタフェース作成者、お勧めでセットされたaがそうする包含に料理の本を提供する。 このドキュメントは、BBN IMPグループによって再検討されて、承認されました。

II.  Ready-line Philosophy

II。 準備ができる系列哲学

   The following is an attempt to spell out in detail a consistent plan
   for operation of the IMP ready line and host ready line with the
   following objectives:

↓これは詳細にIMPの持ち合わせの系列の操作のための一貫したプランについて詳しく説明して、以下の目的で持ち合わせの系列を接待する試みです:

      1.  Reliably resynchronize and resume transmission after a
          temporary lapse of service and possible loss of state
          information by either system.

1. 一時的なサービスの過失と州の情報の可能な損失の後にどちらのシステムでもトランスミッションを確かに再連動して、再開してください。

      2.  Make the programming of the host interface as simple as
          possible.  This will minimize bugs, and make it possible to
          create a small ROM network-bootstrap loader.

2. ホスト・インターフェースのプログラミングをできるだけ簡単にしてください。 これで、バグを最小にして、小さいROMネットワークブートストラップ・ローダを作成するのは可能になるでしょう。

   First, consider the IMP ready line.  When it drops, the IMP has
   suffered a possible loss of state, so the message in transit from the
   IMP to the host (if any) is likely to be incomplete.  Similarly, the
   message in transit from the host to the IMP (if any) is likely to be
   incomplete.  Both the host and the IMP must recognize this explicitly

まず最初に、IMPの持ち合わせの系列を考えてください。 低下するとき、IMPが状態の可能な損失を受けるので、IMPからホスト(もしあれば)までのトランジットにおけるメッセージは不完全である傾向があります。 同様に、ホストからIMP(もしあれば)までのトランジットにおけるメッセージは不完全である傾向があります。 ホストとIMPの両方が明らかにこれを認識しなければなりません。

Burchfiel                                                       [Page 1]

RFC 642         Ready Line Philosophy and Implementation       July 1974

Burchfiel[1ページ]RFC642の持ち合わせの線哲学と実装1974年7月

   by sending a message intended to be thrown away* (which may he
   appended to the current message) and throw away the message currently
   being received.  (Both the host - IMP message and the IMP - host
   message).

捨てられることを意図するメッセージを送る、*、(そうするかもしれない、彼が現在のメッセージに追加した、)、現在受け取られるメッセージを無駄にしてください。 (ともに、ホスト(IMPメッセージとIMP)はメッセージをホスティングします。)

   The simplest arrangement for the host's interface driver is a pair of
   processes, one sending messages and the other receiving messages.
   This drop of the IMP's ready line must be provided as an error status
   bit to each process.  However, the two processes will need to clear
   this condition independently: the simplest implementation is an Input
   Error flop and an Output Error flop.  Both flops are set by a drop of
   the IMP's ready line, and they are cleared independently under
   program control.

ホストのインタフェースドライバーのための最も簡単なアレンジメントは、1組のプロセスと、1つの発信しているメッセージと他の受信メッセージです。 誤りステータスビットとしてIMPの持ち合わせの系列のこの低下を各プロセスに提供しなければなりません。 しかしながら、2つのプロセスが、独自にこの状態をクリアする必要があるでしょう: 最も簡単な実装は、Input Error失敗とOutput Error失敗です。 両方の失敗は1滴のIMPの持ち合わせの系列によって設定されます、そして、それらはプログラムの制御の下で独自にきれいにされます。

   When the IMP raises its ready line, each contact bounce will again
   set the Error flops in the host's interface.  To insure that messages
   are not flowing across the interface at this time, assertions of the
   signals "there's your IMP bit" and "ready for next host bit" have
   been delayed sufficiently in the IMP to guarantee that the IMP ready
   line has stabilized.

IMPが持ち合わせの系列を上げると、各接点跳動は再びホストのインタフェースにError失敗をはめ込むでしょう。 メッセージがこのときインタフェースの向こう側に流れていないのを保障するなら、IMPの持ち合わせの系列が安定していたのを保証するほど「あなたのIMPビットがあっ」て「次のホストビットの準備ができる」信号の主張はIMPで遅れました。

III.  Programming

III。 プログラミング

   The interface driver processes can be described simply:

単にインタフェースドライバープロセスについて説明できます:

   INPUT:  Wait until an input buffer is available
           Wait until IMP ready
           Start input
           Wait until input is complete
           IF Input Error
           THEN clear Input Error  // Flush smashed message.  Input
                                   // buffer will be reused.
           ELSE queue message on input queue
           GOTO INPUT

以下を入力してください。 Input Error THENが平らにInput Error//をクリアするなら入力が完全になるまでIMPの持ち合わせのStart入力Waitがメッセージをつぶすまで入力バッファが利用可能なWaitになるまで待ってください。 入力//バッファは再利用されるでしょう。 入力キューGOTO INPUTに関するELSE待ち行列メッセージ

   OUTPUT: Wait until a message is present on output queue
           Wait until IMP ready
           Start output
           Wait until output is complete
           IF Output Error
           THEN clear Output Error  // smashed message is flushed
           ELSE deque message from output queue  // Free up
                                                 // output buffer
           GOTO 0UTPUT

出力: Output Error THENの明確なOutput Error//がメッセージをつぶしたなら出力が完全になるまでIMPの持ち合わせのStart出力Waitが洗い流されて、//に自由な出力キュー//からのELSE dequeメッセージがバッファゴトー0UTPUTを出力したということであるときに、メッセージが出力キューWaitで現在まで、待ってください。

   ----------
   *The standard convention uses the host-IMP NOP message.

---------- *一般的なコンベンションはホスト-IMP NOPメッセージを使用します。

Burchfiel                                                       [Page 2]

RFC 642         Ready Line Philosophy and Implementation       July 1974

Burchfiel[2ページ]RFC642の持ち合わせの線哲学と実装1974年7月

   The only initialization required for system startup or restart is
   clearing the host READY flop, waiting 1/2 second, and setting the
   host READY flop.  Simply starting (or restarting) the above processes
   will properly resynchronize host-IMP communication.  As explained in
   RFC #636, the IMP ready line (and error flops) should only affect the
   two processes above: this resynchronization should be invisible to
   the NCP, and should have no effect on the connection data base.  The
   NCP will be resynchronized or reinitialized by the type 10 IMP-to-
   host message "interface was reset."

唯一の初期化がシステム起動に必要である、または再開はバタンとホストREADYをきれいにしています、2番目に、1/2を待っていて、バタンとホストREADYを設定して。 単に上のプロセスを始めると(または、再開します)、ホスト-IMPコミュニケーションは適切に再連動するでしょう。 RFC#636で説明されるように、IMPの持ち合わせの系列(誤りは音を立てて動く)は以下の上で2つのプロセスしか影響するべきではありません。 この再同期は、NCPに目に見えないはずであり、接続データベースの上で効き目があるはずがありません。 NCPは、「インタフェースはリセットでした」というタイプ10IMPからホストへのメッセージによって再連動するか、または再初期化されるでしょう。

   Actually, it is possible to share a single Error flop between the
   input and output processes by implementing Input Error and Output
   Error as software flags.  A process testing for error must test both
   the Error flop and its own flag.  An interlock is required (e.g.  a
   mutual exclusion  semaphore) to guarantee that only one process at a
   time is testing and modifying the flags.  If the Error flop is set,
   the process must copy it into the other process' flag before clearing
   the flop and its own flag.

実際に、入出力プロセスの間でソフトウェアが弛むのでInput ErrorとOutput Errorを実装することによってバタンと独身のErrorを共有するのは可能です。 誤りがないかどうかテストされるプロセスはError失敗とそれ自身の旗の両方を検査しなければなりません。 インタロックが、一度に1つのプロセスだけが旗を検査して、変更しているのを保証するのに必要です(例えば、相互排除腕木信号機)。 Error失敗が設定されるなら、失敗とそれ自身の旗をきれいにする前に、プロセスはもう片方の過程の旗にそれをコピーしなければなりません。

IV.  Host Ready Line Implementation

IV。 持ち合わせの線実装を接待してください。

   When the host drops and raises its ready line, the IMP behaves in a
   fashion symmetric to that outlined above.  Of course, this drop
   indicates that the state of the host's interface driver, as well as
   the current incoming and outgoing messages, are likely to be lost.
   The appropriate action is triggered by setting the Error flop or
   flops in the host interface, and the processes specified above will
   correctly resynchronize message flow in both directions.  Of course,
   to guarantee that messages are not flowing across the interface while
   the host ready line is undergoing contact bounce, the host must delay
   transmission until its ready line has stabilized.  This may be done
   in two ways:

ホストが持ち合わせの系列を下げて、上げると、IMPは上に概説されたそれに左右対称のファッションで振る舞います。 もちろん、この低下はホストのインタフェースドライバーの状態、および現在の送受信のメッセージが失われそうであるのを示します。 適切な行動はError失敗か失敗をホスト・インターフェースにはめ込むことによって、引き起こされます、そして、上で指定されたプロセスは両方の方向でのメッセージ流動を正しく再連動させるでしょう。 もちろん、メッセージがホストである間インタフェースの向こう側に流れていないのを保証するために、持ち合わせの系列は接点跳動を受けていて、持ち合わせの系列が安定するまで、ホストはトランスミッションを遅らせなければなりません。 これは2つの方法で完了しているかもしれません:

      Hardware: an integrating one-shot driven by the host ready line
           flop is ANDed with "there's your host bit" and "ready for
           next IMP bit" to guarantee that message transfer will not
           start until the ready flop has been on for 1/2 second.

ハードウェア: 統合1回限り、ホストによって運転されて、持ち合わせの系列失敗は持ち合わせの失敗が1/2秒間、進行中までメッセージ転送が始まらないという保証への「あなたのホストビットがあっ」て「次のIMPビットの準備ができること」があるANDedです。

      Software: the initialization program executes a 1/2 second wait
           after setting the host ready flop before permitting input or
           output to begin.

ソフトウェア: 可能にする前の持ち合わせの失敗が入力したホストを設定するか、または始まるように出力された後に初期化プログラムは1/2 2番目の待ちを実行します。

Burchfiel                                                       [Page 3]

RFC 642         Ready Line Philosophy and Implementation       July 1974

Burchfiel[3ページ]RFC642の持ち合わせの線哲学と実装1974年7月

V.  Summary

V。 概要

   This determines the specification READY line controls for the host's
   interface to the IMP:

これは仕様READYライン制御をIMPへのホストのインタフェースに決定します:

      1.  It contains a program settable/clearable host READY flop which
          drives a relay closure to the IMP.

1. それはリレー閉鎖をIMPに動かすプログラムsettable/clearableホストREADY失敗を含んでいます。

      2.  It detects the IMP's ready signal as a program-readable status
          condition.  (But not an interrupt condition)

2. それはプログラム読み込み可能な状態状態としてIMPの持ち合わせの信号を検出します。 (しかし、中断状態でない)

      3.  It contains one or two ERROR flops set when either the host
          READY flop is off or the IMP ready signal is off.  The flop
          (flops) is a program-readable and program-clearable status
          condition.  (But not an interrupt condition).  These status
          flops must not be cleared by system initialization.

3. それはホストREADY失敗がオフであるか、またはIMPの持ち合わせの信号がオフであるときに設定された1か2つのERROR失敗を含んでいます。 失敗(失敗)はプログラム読み込み可能でプログラム「明確-可能」な状態状態です。 (しかし、中断状態でない。) システム初期化でこれらの状態失敗をクリアしてはいけません。

      4.  If hardware stabilization of the host's READY line is
          provided, it is a 1/2 second integrating one-shot driven by
          the host READY flop.  This signal is ANDed with "there's your
          host bit" and "ready for next IMP bit".

4. ホストのREADY系列のハードウェア安定化を提供するなら、ホストREADY失敗による駆動であることでa1/2 2番目の統合1回限りです。 この信号は「あなたのホストビットがあっ」て「次のIMPビットの準備ができること」があるANDedです。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.           2/2000 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社2/2000]

Burchfiel                                                       [Page 4]

Burchfiel[4ページ]

一覧

 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 

スポンサーリンク

Windowsでユーザアカウントを無効にする方法

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

上に戻る