RFC68 日本語訳
0068 Comments on Memory Allocation Control Commands: CEASE, ALL, GVB,RET, and RFNM. M. Elie. August 1970. (Format: TXT=5041 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Elie Request for Comments #68 31 August 70 UCLA
コメント#68 1970年8月31日UCLAを求めるネットワークワーキンググループM.エリー要求
Comments on memory allocation control commands CEASE, ALL, GVB, RET) and RFNM
メモリアロケーション制御コマンドCEASEのコメント、GVB、RET)、RFNM
The protocol provides a scheme for buffer allocation. This scheme is rather complicated because it necessitates two parallel mechanisms. It is not obvious that both are necessary. In fact it is suggested that this scheme could be probably replaced by a slightly different conception of the Request for Next Message (RFNM). Now the RFNM is sent back from the receiving imp after the message has been reconstituted and the first packet transmitted to the host. Nothing insures that the whole message has been accepted and correctly received by the host; also the design of the host imp interface permits the host to stop accepting data from the imp during any length of time; as the link has been already unblocked by sending back the RFNM another message may be transmitted by the sending foreign host which will congest the imp's memory. On the other hand it is prob- able that usually the host is able to accept data from the imp at a higher rate than it is transmitted on the network, e.g. 200k bits/sec; thus the time to transmit a full message from the imp to the host would be approximately 1/20th of a second which is 10 times less than the average delay of transmission of a message over the network. This indicates that to send a RFNM after the reception of a full message by the host would not increase significantly the response time on the network.
プロトコルはバッファ配分の計画を提供します。 2台のパラレル・メカニズムを必要とするので、この計画はかなり複雑です。両方が必要であることは、明白ではありません。 事実上、Next Message(RFNM)のためにたぶんこの計画をRequestのわずかに異なった概念に取り替えることができたことが提案されます。 もう、メッセージが再編成されて、最初のパケットがホストに伝わった後にRFNMは受信悪童から返送されます。 何も、全体のメッセージが受け入れられて、ホストによって正しく受け取られたのを保障しません。 また、ホスト悪童インタフェースのデザインは、ホストが、どんな長さの時間も悪童からデータを受け入れるのを止めることを許可します。 リンクがRFNMを返送することによって既に「非-妨げ」られたとき、別のメッセージは送付異種宿主によって送られるかもしれません(悪童の記憶を充血させるでしょう)。 他方では、通常、ホストが、それより高いレートにおける悪童からのデータがネットワークで伝えられると受け入れることができるのは、probできます、例えば、200kビット/秒。 したがって、悪童からホストまで完全なメッセージを送る時間はネットワークの上では、メッセージの伝達の平均した遅れより10倍少ない1秒のおよそ1/20番目でしょう。 これは、ホストによる完全なメッセージのレセプションがネットワークで応答時間をかなり増加させなかった後にRFNMを送るためにそれを示します。
In this case there is no reason why the RFNM could not be initiated by the receiving host as an acknowledgment of the correct reception of the message (ACK), and take the form of either a host imp or a control command message. This RFNM could have the two forms
この場合、受信ホストがメッセージ(ACK)の正しいレセプションの承認としてRFNMを開始できなかった理由が全くありません、そして、ホスト悪童か制御コマンドメッセージのどちらかの形を取ってください。 このRFNMは2つのフォームを持つことができました。
ACK (CONTINUE) or ACK (CEASE)
ACK(続けている)かACK(やめます)
This would permit to add to the message some error detection redundancy, such as check sum bits as proposed in [DELO 69]. In the present design nothing insures that one or several bits of the text has not been altered, e.g., by an interference or a deficiency of one of the host imp interfaces. This could have important consequences, e.g. if the text is used to update a centralized data base. Also, if the user has a way of detecting the error, but none of correcting it, it has no way of asking for the retransmission of the message, which has probably been discarded at the sending end upon reception of the RFNM. In fact it seems not up to the user to have to detect errors in
これは何らかの誤り検出冗長をメッセージに追加するのを可能にするでしょう、[DELO69]で提案されるチェックサムビットなどのように。 現在のデザインでは、何も、テキストの1か数ビットが変更されていないのを保障しません、例えば、ホスト悪童インタフェースの1つの干渉か欠乏で。 これには、例えば、テキストが集結されたデータベースをアップデートするのに使用されるなら、重要な結果があるかもしれません。 ユーザにそれを修正するのにおいて、送信側にたぶんRFNMのレセプションで捨てられたメッセージの「再-トランスミッション」を求める方法を全く持っていないというしかし、誤り、なにも検出しない方法がまた、あるなら。 事実上、それは誤りを検出しなければならないいずれのユーザまでも見えません。
[Page 1] Network Working Group M. Elie Request for Comments #68 31 August 70 UCLA
[1ページ] コメント#68 1970年8月31日UCLAを求めるネットワークワーキンググループM.エリー要求
its text but rather up to the NCP: the user process must as much as possible act as if it was talking to some other local process. So a third kind of RFNM sent by the NCP could be:
テキストにもかかわらず、むしろNCPまで: ユーザ・プロセスはまるである他のローカルの過程と話しているかのようにできるだけ行動しなければなりません。 それで、NCPによって送られたRFNMの3番目の種類は以下の通りであるかもしれません。
NAK(REPEAT)
NAK(反復)
Repetition would also be initiated in case of no reply.
また、反復は回答の場合にではなく開始されるでしょう。
Thus we see that it seems worthwhile to make these slight modifications which would permit to use between the sending host and the receiving host a very simple point-to-point transmission procedure which would insure control of the data transmitted from end-to-end.
したがって、私たちは、送付ホストと受信ホストの間で終わらせる終わりから送られたデータのコントロールを保障する非常に簡単な二地点間トランスミッション手順を用いるのを可能にするこれらのわずかな変更をするのが価値があるように思えるのがわかります。
It could also replace the memory allocation mechanism: ACK (CONTINUE) would only be sent if space was available for a new message on this connection and/or ACK (CEASE) would be sent if no more space was available; it corresponds to the WABT of classic transmission procedures [USAS69]; transmission could be resumed by an ACK (CONTINUE) or a RESUME from the receiving end. The user process is not mixed at all with this memory allocation which is a function of the system (or NCP): it only sees a varying global transmission speed of its data on a connection. The imp programs take care of the routing of the data according to the distributed nature of the network, and neither the user nor the system (or NCP) is concerned with it. Other improvements to the protocol may be found after experiencing it.
また、それはメモリアロケーションメカニズムを置き換えるかもしれません: スペースがこの接続に関する新しいメッセージに利用可能である場合にだけ、ACK(CONTINUE)を送るでしょうに、そして、それ以上のスペースが利用可能でないなら、ACK(CEASE)を送るでしょうに。 それは古典的なトランスミッション手順[USAS69]のWABTに対応しています。 ACK(CONTINUE)かRESUMEが犠牲者からトランスミッションを再開できました。 ユーザ・プロセスはシステム(または、NCP)の機能であるこのメモリアロケーションに全く混ぜられません: それは接続に関するデータの異なったグローバルな伝送速度を見るだけです。 ネットワークの分配された本質によると、悪童プログラムはデータのルーティングの世話をします、そして、ユーザもシステム(または、NCP)もそれに関係がありません。 それを経験した後に、プロトコルへの他の改良は見つけられるかもしれません。
Finally note that this solution does not immobilize the imp memory any longer than the actual solution, because it is not the imp which has to repeat a message, but the sending host.
この解決策がもう実際の解決策ほど悪童メモリを固定しないことに最終的に注意してください、それが悪童でないので(メッセージ、しかし、送付ホストを繰り返さなければなりません)。
______________________________________________
______________________________________________
DELO 69 DELOCHE G. Implementation of the Host-Host Software Procedures in GORDO Network Working Group RFC #11 Aug 1969
ゴードーネットワークワーキンググループRFC#1969年8月11日のホスト兼ホストソフトウェア手順のDELO69DELOCHE G.実現
USAS 69 Proposed USA standard data communication control procedures for USASCII CACM Vol. 12 NB 3 March 1969 PB 166-178
USASCII CACM Vol.12ネブラスカ1969年3月3日のPB166-178のためのUSAS69のProposedの米国の標準のデータ通信制御手順
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Kai Henningsen 6/97 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][カイ・ヘニングセン6/97によるオンラインRFCアーカイブへの]
[Page 2]
[2ページ]
一覧
スポンサーリンク