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ページ]
一覧
スポンサーリンク