RFC660 日本語訳

0660 Some changes to the IMP and the IMP/Host interface. D.C. Walden. October 1974. (Format: TXT=4991 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                       D. Walden (BBN-NET)
Request for Comments: 660                                              Oct 1974
NIC #31202

コメントを求めるワーキンググループのD.のウォルデンの(BBNネット)の要求をネットワークでつないでください: 660 1974年10月のNIC#31202

       SOME CHANGES TO THE IMP AND THE IMP/HOST INTERFACE

悪童へのいくつかの変化と悪童/ホスト・インターフェース

In the next few weeks several changes will be made to the IMP
software including changes to the IMP/Host software interface
as specified in BBN Report No. 1822, Specifications for the
Interconnection of a Host and an IMP. These changes come in
four areas: a) decoupling of the message number sequences of
Hosts; b) Host/Host access control; c) expansion of the
message number window from four to eight; and d) provision for
messages outside the normal message number mechanism. All changes
are backward compatible with possible minor exceptions in timing.

この数週間で、いくつかの変更をBBN Report No.1822の指定されるとしてのIMP/ホストソフトウェア・インタフェースへの変化、HostのInterconnectionのためのSpecifications、およびIMPを含むIMPソフトウェアにするでしょう。 これらの変化は4つの領域に入ります: a) Hostsのメッセージ数順のデカップリング。 b) アクセスコントロールを主催するか、または主催してください。 メッセージ番号ウィンドウの4〜8までのc)拡張。 そして、正常なメッセージ番号メカニズムの外におけるメッセージへのd)支給。 すべての変化がタイミングにおける可能な小さい方の例外と互換性があった状態で後方です。

a. Decoupling of the Host/Host message number sequences:
   Since 1972 the IMP system has provided for exactly four
   messages to be outstanding at a time between any pair of
   IMPs, and thus, a total of only four messages between
   all the possible pairs of Hosts on the two IMPs. Because
   all the pairs of Hosts on the two IMPs have had to share
   the four outstanding messages, it has been quite possible
   for the various Hosts to interfere with each other. To
   remove this possibility of interference, the IMP's
   message number logic will soon be changed to allow a
   separate message number sequence between each pair of Hosts.

a。 Host/ホストメッセージ数順のデカップリング: 1972年以来、IMPシステムは一度に2IMPsの上のすべての可能な組のHostsの間でその結果、どんな組のIMPsと、4つのメッセージだけの合計の間でも傑出しているまさに4つのメッセージに備えています。 2IMPsの上のすべての組のHostsが4つの傑出しているメッセージを共有しなければならなかったので、様々なHostsが互いを妨げるのは、かなり可能です。 干渉のこの可能性を取り除くと、すぐ、各組のHostsの間の別々のメッセージ数順を許容するためにIMPのメッセージ番号論理を変えるでしょう。

   To keep manageable the space required to maintain the
   Host/Host message sequences above that presently are required
   for the IMP/IMP message sequences, the Host/Host sequences
   will be taken dynamically from a limited pool of possible
   sequences. The pool will be sufficiently large to seldom
   interfere with a pair of Hosts wishing to communicate. In
   no case will Hosts be prevented from communicating. In
   the event that the Hosts on an IMP desire to simultaneously
   communicate with so many other Hosts that the pool would
   be exhausted, the space in the pool is quickly multiplexed
   in time among all the desired Host/Host conversations
   so that none is stopped although all are possibly slowed.

処理しやすい状態で保つのに、スペースがそれの上のHost/ホストメッセージ系列が現在IMP/IMPメッセージ系列に必要であると主張するのが必要であり、可能な系列の限られたプールからHost/ホスト系列をダイナミックに取るでしょう。 プールはめったに交信したがっている1組のHostsを妨げることができないくらい大きくなるでしょう。 Hostsは決して、交信してもよいでしょう。 同時になりまでのIMP願望のHostsがプールが消耗している他のとても多くのHostsとコミュニケートする場合、時間内にすべての必要なHost/ホストの会話の中ですばやくプールのスペースを多重送信するので、すべてがことによると遅くされますが、なにも止められません。

b. Host/Host access control:
   Upon instructions from ARPA, we will soon add a Host/Host
   access control mechanism to the IMPs. Any pair of Hosts
   wishing to communicate is checked (via bits in the IMP)
   to verify that they have administrative permission to
   communicate. This check normally is made whenever a pair
   of Hosts attempts to communicate after not having
   communicated for two minutes. If the pair of Hosts is
   not allowed to communicate, a special type of Destination
   Dead Message (sub-code 3) is returned to the source
   Host. The default case initially will be to allow all
   Hosts to communicate with each other.

b。 アクセスコントロールを主催するか、または主催してください: ARPAからの指示のときに、私たちはすぐ、Host/ホストアクセス管理機構をIMPsに加えるつもりです。 交信したがっているどんな組のHostsも、それらには交信する管理許可があることを確かめるためにチェックされます(IMPのビットで)。 1組のHostsが、2分間交信していなかった後に交信するのを試みるときはいつも、通常このチェックをします。 Hostsの組が交信できないなら、Destination Dead Message(サブコード3)の特別なタイプをソースHostに返します。 初めは、すべてのHostsが互いにコミュニケートするのを許容するために、不履行格はあるでしょう。

                              -1-


-1-

c. Message number window.:
   Once the message number sequences are on a Host/Host
   rather than IMP/IMP basis, the number of messages that
   will be permitted to be outstanding at a time between
   a pair of Hosts will be expanded from four to eight,
   permitting increased Host/Host throughput in some cases.

c。 メッセージ番号ウィンドウ、: IMP/IMP基礎よりむしろHost/ホストの上にメッセージ数順がいったんあると、一度に1組のHostsの間で傑出していることが許可されているメッセージの数は4〜8に広げられるでしょう、いくつかの場合、増強されたHost/ホストスループットを可能にして。

d. Message outside the normal mechanism:.
   For certain limited experiments which are being carried on
   using the network, it is thought to be desirable
   for specified Hosts to be able to communicate outside the
   normal ordered, error controlled message sequences.
   Thus, the following expansion to the IMP/Host protocol is being
   provided.

d。 正常なメカニズムの外におけるメッセージ: . ネットワークを使用するとき運ばれる予定である限られた実験であり、それが考えられるのを指定されたHostsが標準の外でコミュニケートできるのにおいて望ましいのが確信するForは注文しました、誤りの制御メッセージ系列。 したがって、IMP/ホストプロトコルへの以下の拡張を供給しています。

i. a single packet message coming from the source Host
   to the source IMP with a (new) special message type,
   3, will be put directly into the IMP store-and-forward
   logic with a mark saying the packet is this special
   kind of message. A multi-packet message of type 3
   will be discarded.

i. マークが、パケットがこの特別な種類に関するメッセージであると言っていて、(新しい)の特別教書タイプでソースHostからソースIMPに登場するただ一つのパケットメッセージ(3)は直接IMP店とフォワード論理に置かれるでしょう。 タイプ3に関するマルチパケットメッセージは捨てられるでしょう。

ii. such messages (packets) are routed normally to the
   destination IMP, possibly arriving out of order.

iiことによると故障していた状態で到着して、通常、そのようなメッセージ(パケット)は目的地IMPに発送されます。

iii. at the destination IMP, messages of the special
   type will be put directly on the destination Host
   output queue skipping the reassembly logic and marked
   with a special (new) IMP to Host message type, also 3.

iii目的地IMPでは、特別なタイプに関するメッセージは直接3歳のHostメッセージタイプにも再アセンブリ論理をスキップして、特別な(新しい)IMPと共にマークされた目的地Host出力キューを置くためにことになるでしょう。

iv. there is no source-to-destination retransmission
   logic, no reassembly, no RFNMs, no incomplete
   transmissions, etc.

ivソースから目的地への「再-トランスミッション」論理がない、再アセンブリがない、RFNMsがない、どんな不完全なトランスミッションもありませんなど。

v. if at any time there are insufficient resources in the
   network to handle one of these special messages
   (e.g., the destination Host won't take it), the
   message will be discarded.

v. これらの特別教書の1つを扱うためにネットワークに不十分なリソースがいつでもあると(例えば、目的地Hostはそれを取らないでしょう)、メッセージは捨てられるでしょう。

vi. by using the special message type between the Host
   and the IMP, the normal message number mechanism is
   preserved for all the Host/Host transmissions which
   presently depend on it.

vi HostとIMPの間の特別教書タイプを使用することによって、正常なメッセージ番号メカニズムは現在それによるすべてのHost/ホストトランスミッションのために保存されます。

Because the uncontrolled use of this mechanism will degrade the
performance of the network for all users, the set of Hosts permitted
to use this mechanism will be regulated by the Network Control
Center.

このメカニズムの非制御の使用がすべてのユーザのためにネットワークの性能を下げるので、このメカニズムを使用することが許可されたHostsのセットはNetwork Controlセンターによって規制されるでしょう。

Please file this note with your copy of BBN Report 1822 until
that document is updated.

BBN Report1822のコピーでそのドキュメントをアップデートするまでこの注意をファイルしてください。

                              -2-

-2-

一覧

 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 

スポンサーリンク

Googleカレンダーの共有の予定をiPhoneに表示させる方法

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

上に戻る