RFC151 日本語訳
0151 Comments on a proffered official ICP: RFCs 123, 127. A. Shoshani. May 1971. (Format: TXT=3623 bytes) (Updates RFC0127) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
NWG/RFC # 151 A. Shoshani SDC NIC #6755 May 10, 1971
NWG/RFC#151A.Shoshani SDC NIC#6755 1971年5月10日
COMMENTS ON A PROFERRED OFFICIAL ICP (RFCs 123, 127)
PROFERREDの公式のICPのコメント(RFCs123、127)
Bob Long at SDC noticed that the order in which messages go out to the network depend on the local NCP. In particular commands may be given priority over data and therefore in the sequence specified for server in RFC 123 (top of Page 3), the last two INIT commands may go out before the data = S on socket = L is sent. (This is the case in the current implementation of SDC's NCP.) The implication is that the user's NCP should be prepared to keep the INIT's it received from the server until the user process gets the data = S and issues two INITs in response.
SDCのボブLongは、メッセージがネットワークに出かけるオーダーがローカルのNCPによるのに気付きました。 特に、コマンドはデータに優先するかもしれません、そして、ソケット=Lのデータ=Sを送る前に、したがって、RFC123(3ページの上部)のサーバに指定された系列では、最後の2つのINITコマンドが出かけるかもしれません。 (これはSDCのNCPの現在の実現でそうです。) 含意はユーザのNCPが応答でSとユーザ・プロセスがデータを得るまでそれがサーバから受けたINITのもの=問題が2INITsであることを保つように準備されるべきであるということです。
This case is brought up now so that people will think about it before the Atlantic City meeting and comment whether their NCP can tolerate it. It may be necessary to make it explicit in the ICP that the two INITs sent by the server should go out only after the data = S is sent, or even after the user process acknowledges its receipt.
本件は、現在、彼らのNCPがそれを許容できるか否かに関係なく、人々がアトランティックシティーのミーティングとコメントの前にそれについて考えるように、持って来られます。 データ=Sが送るか、またはユーザ・プロセスの後にさえ領収書を受け取ったことを知らせた後にだけサーバによって送られた2INITsが出かけるはずであるのをICPで明白にするのが必要であるかもしれません。
I have a more general remark about the ICP. This is a third level protocol and therefore should not alter or ignore procedures of the second level protocol (Host-Host protocol). In particular three remarks seem appropriate:
私には、ICPに関する、より一般的な注意があります。 したがって、これは、2番目の平らなプロトコル(ホスト兼ホストプロトコル)の手順を3番目の平らなプロトコルであり、変更するべきではありませんし、また無視するべきではありません。 特に、3つの所見が適切に見えます:
Kreznar [Page 1] RFC 19 October 1969
Kreznar[1ページ]RFC1969年10月19日
1. In RFC 123 (bottom of Page 2) it is suggested that the byte size for the connection to the server socket L is 32. However, in the modifications to second level protocol (RDC 107) it is specified that it is up to the sending process to chose the byte size. According to the Host-Host protocol, NCPs should be prepared to accept messages in any byte size (1<= size <=255); therefore there is no need to impose a size of 32 in this case. Furthermore, since it is up to the sender to choose the byte size, some Hosts may choose a particular byte size (for simplicity and convenience) and their NCP may not be geared to transmit in an imposed byte size.
1. RFC123(2ページの下部)では、サーバソケットLとの接続のためのバイトサイズが32であると示唆されます。 しかしながら、指定されていた状態で平らなプロトコル(RDC107)を後援するそれが送付の過程まである変更では、バイトサイズは選ばれていました。 Host-ホストプロトコルによると、NCPはどんなバイトサイズでもメッセージを受け入れるように準備されるべきです(1<がサイズ<=255と等しいです)。 したがって、この場合32のサイズを課す必要は全くありません。 その上、いくつかのHostsがバイトサイズを選ぶのが、送付者次第であるので、サイズ(簡単さと便宜のための)を特定のバイト選ぶかもしれません、そして、彼らのNCPは課されたバイトサイズで伝わるように連動しないかもしれません。
2. In RFCs 66 and 80, an ALL is expected on the connection to the server socket before data can be sent. In RFCs 123 and 127 the ALL requirement disappeared. But the ALL is a Host-Host protocol requirement and not requiring it creates special case. A particular NCP implementation may cause the ALL to be sent internally when a connection is created, without the user process having control of it. Relaxing this requirement will create a special case for the receiving NCP not to send the ALL and for the sending NCP to send the data = S without first receiving an ALL.
2. RFCs66と80で予想する、データを送ることができる前に接続のときにサーバソケットにすべてを予想します。 RFCs123と127、すべての要件が見えなくなりました。 しかし、すべてがHost-ホストプロトコル要件であり、それを必要としないのは特別なケースを引き起こします。 特定のNCP実現が引き起こすかもしれない、すべて、接続であるときに、内部的に送るのは作成されます、ユーザ・プロセスがそれを管理しないで。 この要件を弛緩すると受信NCPが送らない特別なケースが引き起こされる、すべてと送付NCP、データ=Sを送る最初に、受信、すべて。
3. In RFC 127, I disagree with the comment "send 32 bits of data in one message" because it is a second level protocol decision that a message can be sent in any size pieces and the size is to be specified through the ALL mechanism. In particular, there may be hosts which are not prepared to accept more than few bytes at a time (TIPs).
3. それがどんなサイズ断片にもメッセージを送ることができて、サイズで指定することになっているという2番目の平らなプロトコル決定であるのでRFC127では、私が「1つのメッセージの32ビットのデータを送ってください」というコメントと意見を異にする、すべてのメカニズム 特に、一度に数バイトより受け入れる用意ができていないホスト(TIPs)がいるかもしれません。
In general we should not make second level decisions in a third level protocol.
一般に、私たちは第3のレベルにおける2番目の平らな決定について議定書の中で述べさせるべきではありません。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by BBN Corp. under the ] [ direction of Alex McKenzie. 12/96 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの指示。 12/96 ]
Kreznar [Page 2]
Kreznar[2ページ]
一覧
スポンサーリンク