RFC38 日本語訳
0038 Comments on Network Protocol from NWG/RFC #36. S.M. Wolfe. March 1970. (Format: TXT=2536 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Stephen M. Wolfe Request for Comments: 38 UCLA CCN 20 March 1970
コメントを求めるワーキンググループスティーブンのM.ウルフ要求をネットワークでつないでください: 38 UCLA CCN1970年3月20日
Comments on Network Protocol from NWG/RFC #36
NWG/RFC#36からのネットワーク・プロトコルのコメント
The proposed protocol does not allow for the possible multiplexing of connections over links.
提案されたプロトコルはリンクの上の接続の可能なマルチプレクシングを考慮しません。
Generally, this presents no problem, but it might cause loading restrictions in the future. Two cases where routing multiple connections over the same link are apparent:
一般に、これは問題を全く提示しませんが、それは将来、ローディング制限をもたらすかもしれません。 2つのケースが同じリンクの上に複数の接続を発送するところで明らかです:
a) Where a user has several high speed connections, such as between processes that transmit files over the network. Assigning these connections to the same link limits the percentage of network resources that may be used by that user. This becomes particularly important when several store-and-forward IMP's are used by the network to effect the communication. b) When two hosts each have their own independent network and desire to allow access to the other hosts's network over the ARPA net, a shortage of links may develop. Again, the assignment of several connections to the same link could help solve the problem.
a) ユーザがネットワークの上にファイルを送るプロセスなどのいくつかの高速接続がいるところ。 同じくらいとのこれらの接続がリンクする割り当てはそのユーザによって使用されるかもしれないネットワーク資源の割合を制限します。 店とフォワードIMPの数個ものがコミュニケーションに作用するのにネットワークによって使用されるとき、これが特に重要になる、b) それぞれ2人のホストにそれら自身の独立しているネットワークとARPAネットの上で他のホストsのネットワークへのアクセスを許す願望があるとき、リンクの不足は展開するかもしれません。 一方、同じリンクとのいくつかの接続の課題は、問題を解決するのを助けるかもしれません。
The following changes in the protocol would make possible the future use of multiplexed links. It is not necessary to add the multiplexing, itself, to the protocol at this time.
プロトコルにおける以下の変化で、多重送信されたリンクの今後の使用は可能になるでしょう。 マルチプレクシングを加えるのは必要でない、それ自体、今回のプロトコルに。
a) The END and RDY must specify relevant sockets in addition to the link number. Only the local socket name need be supplied. b) Problems arise with the RSM and SPD commands. Should they refer to an entire link, or just to a given connection? Since there is a proposal to modify the RFNM to accommodate these commands, it might be better to add another set of commands to block and unblock a connection, but I am not convinced that that is the best solution. c) The destintation socket must be added to the header of each message on the data link. Presumably this would consist of 32 bits immediately after the header and before the marking.
a) ENDとRDYはリンク番号に加えて関連ソケットを指定しなければなりません。 . b)をローカルのソケット名だけに供給しなければなりません。 問題はRSMとSPDコマンドで起こります。 彼らは全体のリンク、またはまさしく与えられた接続を参照するべきですか? そこ. これらのコマンドに対応するようにRFNMを変更するために、接続を妨げて、「非-妨げ」るもう1セットのコマンドを加えるほうがよいかもしれませんが、私がそれが最も良いソリューションであると確信していないという提案はc)です。 データ・リンクに関するそれぞれのメッセージのヘッダーにdestintationソケットを加えなければなりません。 おそらく、これはヘッダービットに直後マークの前に32から成るでしょう。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Karl Reinsch 1/97 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][カール・ラインシュ1/97によるオンラインRFCアーカイブへの]
[Page 1]
[1ページ]
一覧
スポンサーリンク