RFC346 日本語訳
0346 Satellite Considerations. J. Postel. May 1972. (Format: TXT=2778 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group Jon Postel Request for Comments: 346 Computer Science UCLA-NMC NIC : 10425 30 May 72
コメントを求めるワーキンググループジョンポステルRequestをネットワークでつないでください: 346 コンピュータサイエンスUCLA-NMC NIC: 10425 1972年5月30日
Categories : Echo Plex, Satellite References : RFC's 1, 5, 51
カテゴリ: Plex、衛星参照を反映してください: 1、5、RFCの51
Satellite Considerations
衛星問題
The consideration of using space satellite transmission links in the ARPANET should be cause for some thought by the parties making use of the network. The satellite transmission path will not necessarily affect the transmission rate but it will affect the delay. The change in the delay characteristics can be approximated by the change in path length. Thus if the satellite is in synchronous orbit about 22,000 miles above the earth, the path length is about 44,000 miles compared to (worst case) 3,000 miles or about a 15 to 1 increase in path length and delay. (The time for light to travel 3,000 miles is .016 seconds, to travel 44,000 miles is .236 seconds.) In the current (surface) ARPANET delays are such that interactive servers with character-at-a-time remote echo are only marginally useful. While I believe that this delay (unmeasured) is largely due to the host systems, adding a half second transmission delay will cause these marginal systems to become unusable. Thought should also be given to buffer allocations. If a receiving system allows only one line of text to be buffered at a time and refreshes the allocation as each line is output to a human user there will be at least a half second delay between the arrival of each line at the receiving system. This need not be a problem until the speed of the output device is above about 150 characters/second. This "small buffer" problem can be expected to occur even with lower speed devices since host delays are estimated to be in the range 0.1 second to 1.0 second. I suggest that it is appropriate to resume a discussion of measures to circumvent the difficulties brought about by these large delay characteristics. Some areas of discussion could be: buffer sizes in servers and users, echo plex techniques, moving part of the input processing to the user system. If it is decided to move the echo plex functions to the user system, it would be wise to try for a "standard" package, thus reducing a M times N problem to a M plus N problem. Please dig out and read RFC's #1 Crocker, #5 Rulifson, #51 Elie to see some previous thinking about this type of problem.
アルパネットに人工衛星トランスミッションリンクを使用する考慮はネットワークを利用するパーティーによって考えられたいくつかの原因であるべきです。 衛星通信経路は必ず通信速度に影響するというわけではないでしょうが、それは遅れに影響するでしょう。 経路の長さにおける変化は遅れの特性における変化に近似できます。 したがって、地球のおよそ2万2000マイル上に衛星が同期軌道にあるなら、3,000マイルか経路の長さと遅れの15〜1つの増加の周りに関して(最悪の場合)と比べて、経路の長さはおよそ4万4000マイルです。 (光が3,000マイル伝わる時間が.016秒である、4万4000マイル旅行するのは、.236秒です。) 現在の(表面)アルパネットでは、遅れがそのようなものであるので、一度にキャラクタリモートエコーがある対話的なサーバはわずかにだけ役に立ちます。 私が、この遅れ(果てしない)が主にホストシステムのためであると信じている間、半分2番目のトランスミッション遅れを加えることによって、これらのマージンのシステムは使用不可能になるでしょう。 また、配分をバッファリングするように考えを与えるべきです。 受電方式が1個のテキスト行だけが一度にバッファリングされるのを許容して、各線が人間のユーザへの出力であるので配分をリフレッシュすると、受電方式でそれぞれの線の到着の間で半分2番目の少なくとも遅れるでしょう。 およそ150キャラクタ/秒より上には出力装置の速度があるまで、これが問題である必要はありません。 ホスト遅れが範囲0.1に2番目〜2番目にあるように見積もられているのでこの「小さいバッファ」問題が下側の速度装置があっても起こると予想できます。 私は、これらの大きい遅れの特性によって引き起こされた困難を回避する測定の議論を再開するのが適切であると示唆します。 議論のいくつかの領域は以下の通りであるかもしれません。 サーバとユーザ、エコーplexのテクニック、入力処理の可動部でユーザシステムにサイズをバッファリングしてください。 それがエコーplex機能をユーザシステムに動かすために決められるなら、「標準」のパッケージに挑戦するのは賢明でしょう、その結果、M回のN問題をMとN問題に減少させます。 RFCの#1クロッカーを掘り出して、読んでください、#5Rulifson、このタイプの問題についての前のいくつかの考えを見る#51エリーをお願いします。
[ 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 ]
[Page 1]
[1ページ]
一覧
スポンサーリンク