第 5部

プロセス間通信163

第 1章
序論

1.1

はじめに

コンピュータネットワーク技術の発展により、分散環境におけるアプリ
ケーションが重要性を増してきている。ローカルエリアネットワークではが使わ多くのアプリケーションにれているが、もともとローカルエリアネットワークで利用されることを意識して作られているので、その機構をそのまま広域の分散環境で用いることには問題が多い。現在のネットワークでは広域分散環境における分散処理が注目を集めているが 、広域分散ネットワークの構築には適切なプロセの開発が必要不可欠である。
ス間通信、特に、適切なRPC(Remote Procedure Call) [74][73]RPC

NFS(Network File System)[75]

な分散環境では資源の共有が可能で、どにより、ユーザは遠隔資源をあたかもローカルの資源であるかのように利用できる。また、ローカルにはないサービスでもネットワークを介して受けることができる。しかし 、ネットワークが広域になると、その状況によって遠隔資源にアクセスできなかったり、遠隔のサービスを受けることができなくなってしまうことがある。遠隔ということだけでも転送時間などに関して不利なことは明らかである。様々なネットワークの接続でコンピュータの種類や オペレーティングシステムの種類も多様になり、その複雑さははかり知れない。

RPCを利用するには、よプロセス間通信の手段として広域分散環境でり効率の良い方式を採る必要がある。どこにいるどんな相手に対しても順を構築するためには、の最適利用を支援する機構を作応できるらなければならないのである。さらに、ユーザの様々な要求を取り入れらが提供されるようになれば 、有用なアプリケーションがれるような数多く作られ、ネットワーク環境がより良いものになっていくであろう。

NFS

RPC

RPC

165

166
1.2

1989 年度 WIDE 報告書
本研究の目的NFS

現在、ローカルエリアネットワークにおいては、を利用することのような高速の回線ででユーザ環境が整えられている。しかし 、のなければこのようなサービスはうまく機能していない。実際、ような低速の回線を使用したネットワーク上ではは利用されていなを用いたアプリケーションが、高い。また、広域ネットワークでは、速用に設定されているタイムアウトによって通信できない場合がある。
としてのデータ通信
本研究では、これらを改善していくために、を効率良く行なうことを考える。現在利用されているや ネットワー
クサービスを考察し 、その上で、ネットワークの状態によるデータサイズの最適利用のための支援システムを設と応答時間の関係を解析し 、計する。また、を利用する際に指定するデータサイズやタイムアウトなどのパラメータは、管理者によって経験的に設定されているが、状況に応じてその値を自動的に探るネットワーク診断システムを提案する。
を利用する際にこの機構を用いることで、より快適な環境が構築できるのである。

ethernet

RPC

9.6Kbps

NFS

RPC

RPC

RPC

NFS

RPC

1.3

本論文の構成2

この章では目的などについて述べたが、以下、本論文では、第 章で、について述べ、特に、とコンピュータネットワークとについて解析する。第 章で、現在の基盤となっているデータグラ
ム通信について考察し 、第 章で、実際のネットワークにおいて計測を行の最適利用のためになう。第 章では、第 章の計測結果をもとに提供されるべき情報を整理する。第 章で、プロトタイプの試作を試み、今後のシステムの設計への足掛かりとする。

3

5

4

RPC

4

Sun RPC NFS

RPC
6

RPC

第 2章
コンピュータネットワークと RPC

2.1

広域分散ネット ワーク

遠隔地に分散する計算機資源を共有する目的で広域ネットワークが広く構築されている。近距離の分散資源を共有するローカルエリアネットワー
ク同士を結合し 、新たに大規模なネットワークを構築するネットワーク間。
接続という技術がその基礎を支えているのである[15]

Table2.1 のローカルネットワークと広域ネットワークを比較すると、ようになる。

ローカルエリアネットワーク

広域ネットワーク

地域性

構内に閉じている。
数程度の範囲。

公衆性

一企業、一大学などプライベート。 通信業者などによって構築され、その対象となるユーザは不特定多数。

多様性

高速な単一の通信技術を利用。

通信速度

数十

表

広域。
国際的規模に及ぶものもある。

km

Mbps 程度。

性質・能力の異なる多種の通信技術が混在する。
数十

Kbps 以下が主体。

2.1: ローカルネットワークと広域ネットワークの比較

ネットワークの広域化による利点は遠隔資源を共有したり、多くの人々の間でのコミュニケーションを可能としたり、あるいは、いくつかのシステムの結合で負荷の分散ができることである。現在、広域のネットワークを利用して電子メールやニュースシステムによる情報交換が活発に行なわれたり、遠隔資源や遠隔サービスを利用したアプリケーションも考案されてきている。更に、マルチメディアを扱うネットワークコミュニケーショ
ンの研究も行なわれている。

167

168

1989 年度 WIDE 報告書

しかしながら、広域性や多様性のために生じる問題も多い。ユーザに資源の位置を意識させないために、遠隔資源をアクセスする場合にも、ローカルエリアネットワークの資源に対するアクセスと同様に高速に行なわれなければならない。更に、広域分散環境においても、ユーザに対してロー
カルエリアネットワークと同じサービスが提供され、ネットワークを意識せずに利用できる環境が構築されることが望まれる。

2.2

広域分散環境における RPC

2.2.1

クライアント ／サーバ モデル

ネットワークを利用したサービスはプロセス間通信を用いて実現されている。このプロセス間通信を行なうシステムは、クライアント／サーバモデルを用ている。クライアントはサービスの消費者で、サーバは提供者である。クライアントはサーバにパラメータを渡してサービスを要求し 、、などのコマンド
サーバは適切な処理をして応答する。 、やもこのモデルに従っている。

rsh rwho phone

RPC

2.2.2

RPC モデルRPC のモデルはローカルのプロシージャコールのモデルに似ていて、呼び出し側のプロセスはあたかも自分の中のプロシージャを呼び出しているかのように、別のプロセスのプロシージャに実行を依頼できる。これらのプロセスは独立しているため、もはや、物理的に同じ計算機上に共存しの場合はネットワークを介してている必要はないのである。ただし 、データの交換を行わなければならないので、パラメータと結果の受渡しに特別な配慮が必要である。

RPC

RPC におけるクライアント／サーバモデルは、次のように考えること

ができる。
サービス
一つ以上のリモートプログラム リモートプロシージャの集まり を集めたもの。

()

サーバ
マシンにはいくつかのネットワークサービスが実装されている。休止状態のサーバプロセスは、コールメッセージが到着すると、プロシー
ジャのパラメータを取り出して結果を計算し 、リプライメッセージをクライアントに送り返す。

第 5部

プロセス間通信169

クライアントサービスに対するリモートプロシージャを起動させるソフトウェアである。プロシージャへのパラメータを含んだコールメッセージをサー
バプロセスに送り、プロシージャからの結果の含まれるリプライメッ
セージの到着を待つ。

RPC([70][71] )の簡単な仕様を知れば 、ソケットなどのプロセス間通
ユーザは、
参照 を知らなくてもネットワークアプリケーションを信の詳細書くことができるのである。ユーザはサーバプロセスとの間でどのように通信が行なわれているかを知る必要はないのである。

170

1989 年度 WIDE 報告書

マシン A

マシン B

クライアント
プログラム

サービス
デーモン

?

-

関数呼び出しサービスの起動?サービスの呼び出し

サービスの
実行




サービスの
完了
応答

?

プログラムの再開?

図?

2.1: RPC を用いたネットワークコミュニケーション

?

第 5部
2.2.3

171

プロセス間通信広域分散環境に適した RPC

RPC

ローカルエリアネットワークでは多くのアプリケーションにが使は分散アプ リケーションを構築するのに適した手続き
われている。
型のプロセス間通信であり、広域分散環境におけるの重要性が増している。多種の通信技術が混在している中で、その詳細を意識せずに通信はのできる手続き呼出しの機構が評価されている。しかし 、従来の広域のネットワーク環境に対しては考慮されていないので、広域分散環境が必要になってくる。
に適した
広域分散環境では回線が低速であり、プロセス間の通信に比較的長い時間がかかる。従って、広域分散環境においては高速なプロセス間通信が必要になる。他のシステム上にあるプロシージャを、あたかも自分のローカ
ルなプロシージャであるかのように利用できるためには、ユーザに通信時を行なうことで、こ間の長さを意識させてはならない。効率の良いの高速化を提供しなくてはならない。
また、ネットワークの輻輳の制御はローカルエリアネットワークの場
合より複雑である。ネットワークを混雑させるような通信は、広域分散環
境においては致命的である。大量データ転送を伴う時や、サーバの負荷が大きい時には、軽率な再送処理は状況を悪化させてしまうので、状況に応としても適切じた適切な方法で再送が行なわれなければならない。
な再送制御を行なう必要がある。
更に、ネットワークが広域化する中で、クライアントの要求に対して適。
切なサーバをどのように選択するかということも考える必要がある

RPC

RPC

RPC

RPC

RPC

RPC

[51]

2.3

Sun RPCRPC

Sun Microsystem

RPC

ここでは 、既存の
として、
社の
につい
て解析する
。
クライアントはプロシージャを呼ぶことによって、サーバにデータパケットを送る。パケットが到着するとサーバはサービス処理ルーチンを呼んで要求されたサービスを実行し 、リプライパケットを送ってプロシージャ
コールがクライアントに戻される。

[73][74]

2.3.1

三つのインタフェース

Sun RPC のインタフェースは以下の三つの階層に分けられている。
 highest layer intermediate layer

172

1989 年度 WIDE 報告書

 lowest layer
2.3.1.1 highest layer
このレ イヤでは 、すでにリモートプロシージャがライブラリとして用意されているので、ローカルなプロシージャコールと同じようにプログラを意識せずに使うことができ、ユー
ムの中で使用するだけでよい。
ザに透過性を提供している。現在提供されているライブラリルーチンには、
次のようなものがある。

RPC

rnusers() 1 1 1 リモートマシンのユーザの数
rusers() 1 1 1 リモートマシンのユーザ情報
havedisk() 1 1 1 リモートマシンがディスクを持っているか
rstat() 1 1 1 リモートカーネルのパフォーマンスを得る
rwall() 1 1 1 特定のマシンへの書き込み
getmaster() 1 1 1 YP マスタの名前を得る
getrpcport() 1 1 1 RPC のポート番号を得る
yppasswd() 1 1 1 YP のユーザパスワード の更新
2.3.1.2 intermediate layer

callrpc() と registerrpc() という二つの関数を用いる。callrpc() がクライアント側、registerrpc() がサーバ側の関数である。様々なアプリケーショ
ンのために設計されていて、利用に際してソケットなどについて知る必要
はない。
はサーバの
に処理を
クライアントから呼ばれた
依頼し 、結果が戻ってくるまでブロッキングされる。 依頼を受けたは適当なプロシージャを呼んで処理し 、結果をに返す。
は 個のパラメータを持つ。リモートマシンの名前でサーバマシンを指定し 、プログラム番号、バージョン番号、プロシージャ番号で、プロシージャを指定する。さらに、プロシージャに渡すパラメータのデー
タ型とそのアドレス、プロシージャから受け取る結果のデータ型とそのアは使うべきプロシージャを全て登録してかドレスを与える。
ら無限ループに入ってサービス要求の到着を待っている。パラメータは６個で、プログラム番号、バージョン番号、プロシージャ番号、及び 、そのサービスの処理を行なうプロシージャの名前、プロシージャへのパラメー
タのデータ型、結果のデータ型を与える。
しかサポートされていないので、以上これらの関数ではのデータ転送は行なえない。また、を使いたい場合は、

callrpc()

terrpc()callrpc() 8

registerrpc()

callrpc()

regis-

registerrpc()

UDP

TCP

8Kbytelowest layer

第 5部

プロセス間通信173でプログラムを作成しなくてはならない。

2.3.1.3 lowest layer

RPC

このレ イヤではのためのライブラリルーチンが用意されていて、ソケットやネットワークライブラリルーチンを使ってを作成する。

RPC
まず、サーバ側では、svcudp create() 又は svctcp create() を用いて、
transport handle を得る。pmap unset() でポートマッパのテーブルから前のポート番号の登録を消したあとで 、svc register() で指定されたプロ

グラム番号、バージョン番号、プロシージャ番号を再登録する。最後に、でサービス要求を待つ。

svc run()gethostbyname()

クライアント側では、でサーバマシンのネットワーク
又はアドレスを得て、そのアドレスをもとにしてを用いて、のクライアントを作る。つぎに、を用いてサー
バプロセスに処理を依頼し 、結果が返ってくるまで待つ。指定したタイム
で 、関連した空間をアウト以内に戻らないと失敗になる。
は閉じない。これは、同じ
すべて解放するが、使用していたを複数のクライアントが使っている時のためである。

RPC

clntudp create()
clnt call()clnt destroy()socket2.3.2

clnttcp create()
socket

XDR

クライアントマシンとサーバマシンが異なる種類の計算機の場合、扱うデータが同じでも、異なる値を表わすことがある。これは 、計算機によってデータの評価の仕方が違うためで、プロセス間でデータの転送を行なう
場合は注意が必要である。

Sun RPC は、異なる種類の計算機間でも使用することができるようになっている。データを送り出す前に XDR(eXternal Data Representation)に換算することで任意のデータ構造が扱えるのである [69]。XDR はポー
タブルなデータ転送のための仕様である。RPC と共に用いることで、プロセス間通信のための標準入出力ライブラリを提供するので、ソケットベースのプロセス間通信の詳細には触れずにソケットにアクセスすることができるのである。整数や小数はもちろん、配列や共用体、ポインタなどに対していくつかのルーチンが提供されているが、それらを組合わせてユーザが新しいルーチンを作ることもできる。
2.3.3

port mapper program

RPC

ポートマッパプログラムはプログラム番号とバージョン番号をやのポート番号にマップする。クライアントプログラ

UDP/IP

TCP/IP174

1989 年度 WIDE 報告書

ムはサーバがサポートしているリモートプログラムのポート番号を知るた
めにポートマッパを使う。
まず、サーバプログラムはそのホスト上のポートマッパにエントリを登録する。クライアントプログラムはリモートプログラムのポート番号をコールメッセージを送り尋ね
知りたい時、サーバのポートマッパにる。サーバマシンにリモートプログラムがサポートされていれば 、ポートのリプライメッセージで返す。そしマッパは対応するポート番号をのコールメッセージを送ることて、リモートプログラムのポートにが出来るのである。

RPC

RPC
RPC

このプログラムにより、リモートプログラムの動的なバインドが可能になる。つまり、あるネットワークサービスがサーバマシンによって違うポートを持つことが出来るのである。
2.3.4

Sun RPC の評価

RPC のインタフェースは三つのレイヤで提供されていた。highest layer
では、非常に簡単にプログラムを作ることができたが、そのためのライブ
ラリルーチンとして提供されているものは少なく、物足りなさを感じる。
では 、タイムアウトを扱うことができないので、を用いて有効に機能するネットワークアプリケーションを作成するためにを使わなくてはならない。プロセス間通信の詳細を知らなは、くてもネットワークアプリケーションプログラムが書けるというでを利用するためには、やはりソケットやネットワー
あるが、有用にクライブラリルーチンを使わなくてはならないのである。従って、上位ののライブラリルーチンが作成され 、様々な要求に対応できレイヤにるようになる必要がある。

intermediate layer

RPC

lowest layer

RPC

RPC

RPC

しかし 、ある程度プロセス間通信のプログラムを扱ったことのあるユーが十分なプリミティブを提供している。プロトコル
ザには、との両方がサポートされている上、ブロードとして、も用意されている。現在、あまり使われてキャストやバッチ処理のいないが、認証確認のフィールド も用意されており、セキュリティが問題
はクライアントとサーとなる広域分散環境では有用である。また、バが同等の立場にあり、サーバがクライアントになることも可能であって、プロシージャ同士の通信も行なうことができると考えられる。

lowest layer
UDP/IP TCP/IP
RPC

RPC

Sun RPCの特徴である、ポートマッパの機能も有用である。これは、クライアントの問い合わせに対してサーバの情報を提供するものであるが、このポートマッパにより、ポート番号を意識せずに、プログラムを書くこはとができ、システムごとの異なる設定も可能となる。また、

Sun RPC第 5部

プロセス間通信クライラント マシン

175

サーバ マシン

2i

クライアント
プログラム

3i

6

- 111

ポートマッパ

1i
サーバ- ポート プログラム

1 サーバはポートマッパに登録をする
2 クライアントはポートマッパからサーバのポートを得る
3 クライアントはサーバにコールメッセージを送る

図2.2: ポートマッピング176

1989 年度 WIDE 報告書

XDR の上に構築されているので、異なる種類の計算機間で利用できるということも、特徴として挙げられる。

Sun RPC は lowest layer を用いることで、拡張性のあるパッケージであるといえるが、ネットワークアプリケーションの一部として RPC を利用する際に、その拡張をプログラマに望むのではなく、RPC として様々な機能を提供するべきである。現在、広域ネットワークでの利用についてはあまり考慮されておらず、確認応答など 、他のの機構に比べて劣っ。
は、再送に関して充分な機能が提供されていないよている
うであるが、確認応答の機構によっては再送の制御の方法も変わってくることになる。

RPC[83] Sun RPC

RPCはその性質から同期型の機構で実現されている
さらに 、多くのプロジェクトでは非同期型のが設計されている。今が、後の広域分散環境におけるネットワークアプリケーションを考えると、非同期型のが必要になる場合も数多くある。
では 、そのようなアプリケーションを有効に作成ことはできないのである。

Athena

RPC

RPC

[64]

Sun RPC

2.4

NFS と Sun RPC

2.4.1

ネットワークサービス

基本的なネットワークサービスのほとんどはクライアント／サーバモデやルに従っている。
などがそうである。
ではの機構を基にこれらのネットワークサービスを実装して。
との提供するサービスを基礎といるところに特徴があるするので、これらのネットワークサービスはネットワークアプリケーショという環境は、本質的に、更に拡ンということになり、大していく可能性のあるものであることがわかる。つまり、新たなネット
ワークサービスを容易に付加することが可能である。

Network File System(NFS) Yellow Page(YP) Database
Service[68], Network Lock Manager, Status Monitor
Sun OS RPC[72] RPC XDR
XDR/RPC/NFS

NFS はオペレーティングシステムとは独立したサービスである。これによりユーザはネットワークを介してファイルシステムの一部をマウントすることができて、それらがローカルなものであるかのように扱うことがではユーザやホストの認証確認を行なうセキュアなマできる。
ウントも加えられている。

Sun OS 4.0

YP NFSはの促進する大規模ネットワークの管理を容易にするために設計されたネットワークサービスで、読み出しのみのデータベースである。
パスワード やグループ、ネットワーク、ホストなどの情報提供に使われて
いる。

第 5部

プロセス間通信

177

Network Lock Manager は一つのファイルを同時に更新することを避けるためにファイルにロックをかける。これを実装するシステムコールは同一計算機上の別のプロセスを除外するだけでであるが、カーネルがを用いてロックマネージャにシステムコールを送るので、複数の計算機上で同一のファイルシステムを共有できるのである。このロックマネージャ
はであるので、サーバやクライアントのクラッシュに対処することができる。

RPC

stateful

Network Status Monitor はネットワークアプリケーションが計算機のリブートを検出したり、アプリケーションに固有な回復の機構を起動させることを可能にする。
2.4.2

NFS

NFS は異種類の計算機やオペレーティングシステム、ネットワークが接続される環境で、ファイルを共有するための機能である。オペレーティの機構を用いているためであングシステムの種類に対する透過性はの機構を用いているためである。
り、計算機の種類に対する透過性は
は分散オペレーティングシステムとしてではなく、ネットワークサー
ビスとして設計されており、唯一のオペレーティングシステムに限定する
ことなくネットワークサービスに対する分散アプリケーションをサポート
は必要なディスクを全て利用ですることができるのである。さらに、きるようにすることに目標をおいている。ネットワーク上にあればすべての情報にアクセスすることができ、ネットワーク上のプリンタやスーパコ。
ンピュータも利用可能になるのである

NFS

RPC
XDR
NFS

[75]

2.4.2.1

リモートファイルシステムの mountあるファイルを参照したいが 、自分の計算機にはそれが存在していなコマンド によりそのくて、他の計算機上には存在するような時、ファイルを参照することができる。これはファイルシステムを含むディレ
クトリ階層であっても可能である。つまり、他の計算機上のファイルシス
テムの部分木を自分の計算機のファイルシステムに継ぎ足すことができる。

mount

2.4.2.2

データアクセスにおける透過性

ユーザはデータのネットワークアドレスを知らなくても望みのファイルでマウントされたファイルシステム
を扱うことができる。ユーザにはは自分の計算機にあるディスクと全く同じように扱うことができる。ロー
でマウントされたディス
カルディスク上のファイルへの読み書きと、

NFS

NFS

178

1989 年度 WIDE 報告書

ク上のファイルへの読み書きには違いは全くないのである。しかし 、実際はネットワーク上の情報は分散しているのである。
また、必要な作業のためのツールのすべてを一ヶ所で供給することは不可能で、各サービスは一つのネットワークの中で統合されなければならはオペレーティングシステムに依存ない。このような統合のために、しない柔軟性を持っているのである。

NFS

2.4.2.3 NFS の実装

UNIX のファイルシステムは i ノードに対応するディレクトリやファイルから構成されている。i ノード はファイルの位置、大きさ、アクセスの許可、アクセス時間などのファイル管理情報を含んでいる。この i ノード
は一つのファイルシステムの中では唯一の番号を持つが、他のファイルシ
でマウント
ステムの ノードと同じ番号を持つことになる。従って、は ノー
した場合に ノード の一貫性が失われる。この問題に対してを設計した。
ドと呼ばれるデータ構造に基づくではネットワーク上においてもファイルが唯一に決定できる。
はやの機構を基にインタフェースを定義
このの場合には、直接クライアントマシ
し 、実装している。ローカルなンに接続されたディスク上のファイルシステムデータにアクセスされるが、の場合には、アクセス要求はネットワーク上のやリモートなのレイヤを通過することになる。現在は、プロトコルを使っとのレ イヤを通過て実装されている。そして、サーバ側ではしてサーバに要求が到着するとローカルなでアクセスするた参照 。
めに ノードを使いサービスに答えるのであるの実装は次のような５つの透過性を提供している。

i

VFS

NFS
Sun v
VFS(Virtual File System)i

VFS RPC XDR

NFS

VFS

VFS

XDR

UDP/IP
RPC XDR
VFS(Figure2.3

NFS
v
NFS

RPC

)

 ファイルシステムの種類の透過性

vnode により、様々な種類のファイルシステムを扱える。

 ファイルシステムの位置の透過性

VFS

VFS

とリモートなに違いはないのでファイルシス
ローカルな
テムデータの位置は透過的である。

 オペレーティングシステムの種類の透過性

RPC の機構により、ネットワーク上の様々なオペレーティングシス

テムとの通信が行なえる。

 計算機の種類の透過性

XDR の機構により、ネットワーク上の様々な計算機との通信が行な

第 5部

179

プロセス間通信system calls?

VFS
interface

VFS

0 @
0
@
0
@@
0
09
@R

UNIX
le
system

0 @@
0
@@
00
0
@R
UNIX

NFS
serverNFS
client

6

?

RPC/
XDR

RPC/
XDR

?

図

6

Network

2.3: NFS のサーバとクライアントのつながり

lesystem180

1989 年度 WIDE 報告書える。

 ネットワークの種類の透過性

RPC と XDR が様々なトランスポートプロトコルを扱えるので、ネッ

トワークの種類に透過的である。

2.4.2.4

クライアント ／サーバ モデル

NFS のインタフェースは lehandle と呼ばれる識別子をファイル操作に使用している。 lehandle はサーバとクライアントの間で受渡しが成される。
で、要求するファイルシ
まず、クライアントはマウントサーバにを得る。
を得たクライアントプログ
ステムに対する
プロシージャを使って別のを得たり、ファイルシ
ラムはにクライアントプログ
ステムの中を行き来することができる。
サーバの行動を示す。
ラム、マウントサーバ、NFS

lehandle

NFS

RPC
lehandlelehandle
Figuer2.4

第 5部

181

プロセス間通信1i

8* Pathname HH
HHj マウント
888
アプリケーション
2i
YHH
インタフェース H
88 サーバ8H8Filehandle
A
AA
A
AA
3i
AU Filehandle
- NFS
サーバ

1 クライアントはマウントサーバに pathname を送る
2 マウントサーバは対応する lehandle を返す
3 クライアントは NFS サーバに lehandle を送る

図2.4: マウントサーバと NFS サーバ

NFS サーバは stateless である。つまり、サーバは一つのトランザク
ションの後にそのクライアントに関して何も情報を持っていない。例えば 、という操作がインタフェースにはあるが、
にはない。
である。
操作で使うために操作における情報をこれはサーバの利点は、クライクライアントが保持しているのである。
アントやサーバやネットワークなどの失敗に対する強さである。クライア
ントが失敗してもサーバは何ら影響されない。サーバあるいはネットワー
クが失敗した時は、クライアントがサーバあるいはネットワークが回復す
操作を続ければよい。異なるシステムの混在する複雑なネッるまでトワークではこのような強さが本質的に重要になってくるのである。

open()

stateful

NFS

UNIX
NFS

UNIX
stateless

NFS

182

1989 年度 WIDE 報告書

2.4.3

RPC を用いた NFSNFS はいくつかの透過性を提供していたが、NFS の本質ともいえる位
置の透過性を実現するために VFS という機構を用いていた。そして、その VFS は RPC と XDR を利用していて、オペレーティングシステムや計算機の種類に関係なく、様々なネットワークを介して構築することができた。
でシステムコールが呼ばれると、目的のファイルのを見つけ、オペレーションルーチンが呼ばれる。このオペレーションルーチンのから目的のファイルがローカルのものかリモートのものかを中で、判断をして、ふさわしいオペレーションルーチンを呼ぶ。リモートファイは変換されてクライアントに渡され、さらに、
ルの場合には、を用いてサーバに渡される。
はの一部として利用されていて、うまく機能している。
を利用することで、のサーバとクライアント間のインタフェースを簡
は単独で簡単に利用することが単にしているのである。もちろん、できるが、むしろ、ネットワークサービスの中で利用されることを考えていて、比較的大きな規模のネットワークアプリケーションでも有効に利用
される。

NFS

vnode

vnode

vnode
RPC
NFS
RPC NFS
NFS

NFS

RPC

RPC

第 3章
データグラムによるデータ転送

TCP を用いた RPC もサポートされているが、実際に利用されているのは ほとんどが UDP である。プロシージャコールという性質から、時間をかけてコネクションを張る TCP よりも、UDP の方が効率が良いと思われるからである。

UDP

RPC

を基盤とするを広域分散環境で利用するにあた
ここでは、り、データグラムを効率よく転送をするための条件を考えてみる。

3.1

再送処理

3.1.1

再送制御の必要性

RPC

多くのでは 、クライアントはサーバにサービスを要求してから結果を受け取るまでブロッキングされる。もし 、サーバがクラッシュしたり無限にループしていたりすると、永久に結果を受け取ることはできない。
しかし 、データの転送やサービスの処理に時間がかかっている可能性もある。クライアントは返答が返ってくるかど うか、その返答を受け取るまでわからないのである。サーバの負荷が重い時には、再送を繰り返すことは更に負荷をかけることになり悪循環であるし 、サービスの処理にかかる時
間よりもタイムアウトの間隔が短いと再送が繰り返されるだけである。
再送はできるだけ避けなければならない。サーバに要求メッセージが到着しているにもかかかわらず再送を行なうことは、その通信が遅くなるば
かりではなく、ネットワークに輻輳を生じさせることにもなる。広域分散環境では、個々のアプリケーションが最小限のコストで通信できるようにとしても再送制御をする必制御していくことが重要である。そこで、では要求メッセージに対する確認応答をまず送り、要がある。
。これにより、相手ホストに対
それから処理を始めるようにしているするラウンドトリップタイムを過ぎても確認応答を受け取らないと、クライアントは要求メッセージが受理されていないことがわかる。

RPC

Sprite RPC

[83]

183

184

1989 年度 WIDE 報告書

Sun RPC
RPC

lowestでは再送に関してはあまり考慮されてない。
しかし 、で 、ユーザがに対するタイムアウトと各パケット転送のタイ
ムアウトを指定することで再送回数を指定することができるが、その数値の選択はユーザに任されている。ユーザはその値を経験的に定めるしかなとでは全く指定することができないい。
としので、刻々と変化するネットワークの状態に対応するためにはてこれらの機能を提供する必要がある。

layer

hightest layer intermediate layer

3.1.2

RPC

タイムアウト の不適当な設定による再送

再送はタイムアウトの間隔を越えても応答が返ってこない時に起こる。
タイムアウトが長過ぎるとパケットが喪失した時の発見が遅くなる。しかし 、タイムアウトが短いと、ネットワークが混雑している時やサーバの負荷が重い時には、実際に要求が受理されていても、すぐ 再送が行われてしまう。パケットが喪失したり、あるいは、サービスが適当に処理されない
ような時にのみ再送がなされるべきである。単に、ネットワークが混雑しているとか処理が遅いということで再送がされるべきではない。しかし 、のような同期型のではこれらのことを区別することは不可能である。ユーザにとっては、応答が戻ってこないということに過ぎないのである。
そこで、適切にタイムアウトを設定することが要求される。しかし 、この設定にはさまざまな要因を考慮しなければならない。 で述べるような応答時間に関するパラメータに影響されることは勿論であるが、その他にも考慮するべきことは多い。たとえば 、エラー率の大きい回線を使用する
時にはパケットが喪失する可能性が高いので、タイムアウトは短い方が全体としての効率は良くなるであろう。逆に、信頼性の高い回線を使用する
時には多少長めにタイムアウトをとっても良いと考えられる。ネットワー
クの混雑で到着の遅れた応答メッセージを受け取ることができるかも知れないからである。

Sun RPC

RPC

3.2

3.1.3

マシンの能力の限界による再送

広域ネットワークではさまざ まな計算機が接続されており、その性能は異なる。計算機によっては、あまりに速くパケットが到着するとそのす、 シリーズ
べてを受け取ることができないかもしれない。例えば 、の初期のものはそのインタフェースのアーキテクチャにより、性能の良い
インタフェースを持つ計算機とは実用上通信できないという欠陥があった。
クライアントマシンとサーバマシンだけでなく、途中のゲートウェイの性能が劣っている場合も通信はできなくなる。ゲートウェイにおける混雑がSun1 2

第 5部

185

プロセス間通信おこらないように、パケットの量を制御することはネットワーク全体がうまく機能するためにも必要である。
また、ネットワークのインタフェースは一度に転送することのできるでデータサイズが決まっている。これがを越すパケットは下位のレ イヤでフラグ メントされる。
ある。このフラグメントされたデータが連続して送られると受け取れなくなる計算機がある。転送した計算機の上位レ イヤは応答が来ないと判断すると再送のパケットを送出するが、再送を繰り返しても通信をすることは出来ないのである。このような場合は、パケットを送出する際に、時間をおくことで、パケットが連続して到着しないようにしてやることが必要である。
のように大この問題は下位レ イヤの解決すべき問題であるが 、量のデータ転送が考えられる場合にはその一部として考える必要もある。
のサポートするメッセージはデータグラムとして転送されるが 、までしか一度に送ることはできない。それ以上のデータを転送する時には 、いくつかのデータにして下位レ イヤに渡すことになる。
としてパケットの送出が速過ぎるような時には、連続して送るもし 、ことは避け、間隔をおいて送出しなければならない。あるいは、データサ
イズを減らし 、小さなパケットにして送り出さなければならない。

Maximum Transfer Unit(MTU)

MTU

NFS

UDP/IP
8Kbyte

RPC

RPC

3.2

応答時間に関するパラメータ

RPC の要求メッセージを出してから、結果を受け取るまでの応答時間がわかれば 、それに合わせてタイムアウトを指定することができる。適切なタイムアウトが指定できれば 、再送を最小限におさえることができる。
応答時間は、遅延、データサイズ、バンド 幅、処理時間などによって決る。
3.2.1

遅延

1/2

遅延はラウンドトリップタイムのであると考えられる。ローカル
エリアネットワークの場合はほとんど 無視することができ、ローカルエリ
アネットワーク上のプロトコルは通信時間が短時間であることを仮定している。しかし 、ネットワークが広域になると、もはや通信時間を無視することはできず、従来のローカルエリアネットワーク上のプロシージャコー
ルはそのままではうまく機能しない。
遅延はネットワークの状況を最も反映していて、その負荷によって決まる動的な量である。回線やゲートウェイの混雑度は時間とともに変化しており、その状況を把握することは難しい。多くのネットワークアプリケー
ションにとって必要不可欠なこの情報を、正確に、かつ迅速に得ることはま1861989 年度 WIDE 報告書だ実現されていない。その瞬間の遅延を得ることは不可能である。しかし 、データを送出する直前にラウンドトリップタイムを実際に測定すれば 、それはそのデータを転送する際の遅延と考えることができる。ただし 、この場合、小さなデータを遅延の大きなデスティネーションに転送するような時には、オーバヘッドが大きく、著しくパフォーマンスが落ちることになる。また、データ転送をする度にこのような方法をとっていてはトラフィッ
クが増えて、ネットワークに余分な負荷がかかり、実用的ではない。そこ
で、通常からネットワークの状況を監視して、その情報をキャッシュしておくことが考えられる。これは正確さに欠けるが、現在の状況を判断するのに十分な情報が提供できるのであれば有効である。
また、応答時間はデスティネーションホストまでの経路にも左右される。例えば 、衛星回線を使用する時には、専用回線を使用する時よりもその値は著しく大きくなる。しかし 、経路制御は下位レ イヤに任されているとしてこれらを扱うことはできない。定められた経路での遅延のでをいかに正確に得るかが問題になる。

RPC

3.2.2

データサイズ

通信時間に最も関わってくるのがデータサイズである。転送するデータの量が大きければ、それだけ転送にかかる時間も長くなるのは当然である。
データサイズが小さいとヘッダのオーバヘッドは大きくなるが、フラグ メ
ントのオーバヘッドはデータサイズが大きい方が大きくなる。ネットワー
クアプリケーションを作成する際には、これらの要因が実際の応答時間にのように、さど う影響してくるかを知る必要があるであろう。特に、
まざまな サイズのデータを扱う場合は、その動向を正しく把握しなければ
ならない。

NFS

3.2.3

バンド 幅

バンド 幅は回線によって決まる静的な量である。その回線を使用した時に１秒で送ることのできる最大のビット数である。
では、や、などが提供されている。また、衛星回線
専用回線はでは、もっと広いバンド 幅でサービスが行われている。

64K 19.2K 9.6K

ethernet

10 Mbps

一般に、広域ネットワークでは 、回線が低速であることが特徴として挙げられる。これはローカルエリアネットワークと大きく異なる点である。
広域分散環境におけるアプリケーションをうまく動作させるためには、この特徴を考慮しなくてはならない。

第 5部
3.2.4

プロセス間通信187

処理時間

処理時間とはサーバの計算時間のことを意味している。当然、サービスによって異なるが、サービスを実行する計算機の性能、および 、負荷によっても変わってくる。サービスの種類によって決まる固有の量はサーバ
マシンの種類や状態とは無関係で、あらかじめ予測することができる。また、サーバマシンの性能はサービスの種類とは無関係で、ホストが決まれ
ばこれも特定することができる。しかし 、サーバの負荷は他のクライアントとの関係や計算機の状態によって変わる動的な量である。
3.2.5

応答時間

Figure3.1

以上の要因により、応答時間が決定できる。
のように考える
ことができる。実際のデータサイズをバンド 幅で割ったものがデータの転送にかかる時間である。正確には、データをエンコードしたりデコード す
るときのオーバヘッドなどを考慮する必要もある。

1881989 年度 WIDE 報告書

クライアントプログラム

サーバプログラム

6 PPPPPP
6
PPP
L1/B
D1
PPPP
?P
PP ?
PPPP
PPP
PPPP
PPP
T
6
E
?










 6




6



L2/B
D2





?
?
?
6

L1, L2 : データサイズ
B : バンド 幅
D1, D2 : 遅延
E : 処理時間
T : 応答時間
T = D1 + L1/B + E + L2/B + D2

図3.1: 応答時間の解析

第 5部

(B)
(L1 L2)189

プロセス間通信

バンド 幅
は回線によって固有の量であるが 、その他の、データサ
、
、遅延
、
、処理時間
等は様々な要因によって変イズ化する量である。ネットワークの混雑の状況が遅延に関わり、サービスの種類が処理時間に関わってくる。これらのパラメータがどのように関わってくるのか、考慮するべきパラメータは何かということを把握すれば 、応
答時間の予測を行なうことができるのである。
タイムアウトは実際の応答時間よりも長くとらなければならない。もし 、短いタイムアウトを指定すると、クライアントは絶対にこの通信を成功させることはできない。低速の回線で、事実上マウントできないのは大のタ
きいデータを転送しようとすると応答時間が長くなってしまい、
イムアウトを越してしまうためである。一回の転送サイズを小さくしてタ
イムアウトを極端に長くすれば 、ユーザインタフェースは悪くても、マウ
ントすることが可能である。

(D1 D2)

(E)

NFS

第 4章
実測

4.1

データサイズと応答時間

RPC を効率良く利用するためには、適切なタイムアウトの決定を行なう必要がある。そのためには応答時間といくつかのパラメータとの関係を知らなくてはならない。ここでは 、データサイズの応答時間への影響を、実際のネットワーク上で計測をした。
実験をおっこなったネットワークの接続の状況を
4.1.1

Figure4.1に示す。

実験プログラムの説明

RPC

クライアントプログラムは指定されたデータサイズを持つ
要求
システムコールでメッセージをサーバに送り応答を待つ。その際、システムコールで応答を受け取った直データを送出する直前と、後にシステムコールで応答時間を計測する。エラーの把握のため、再送は行なっていない。

gettimeofday

recvfrom

sendto

RPC

要求メッセージが到着すると、データをデサーバプログラムは
コード する。本来は、それをサービスプロシージャに渡して、サービス処
理をするのであるが、ここではそのまま応答メッセージの中にエンコード
して、クライアントプログラムに送り返す。これにより、サーバの処理時間を無視できる。ただし 、デコードとエンコードに費やされる時間は考慮
していない。

RPC モデルとしては要求メッセージと応答メッセージはデータサイズが異なるが、この実験に関しては同じものを転送しているので、そのサイズは全く同じである。
4.1.2

net

ネットワークの接続状況との関係

ether9.6Kbps

現在、ローカルエリアネットワークでは計算機と計算機の接続にを使用しているのが一般的である。また、広域ネットワークでは

190

第 5部

191

プロセス間通信

News/1720 cs-relay
NewsOS 3.2
potatoSun3/50
SunOS 3.5

Sun4/280
cabbage SunOS
4.0
kossvax

kluna

Sun2
SunOS 3.0
Sun3/280S
SunOS 4.0.3
64KbpsnirvanaSun3/280S
SunOS 3.5

jp-gateSun4/330
SunOS 4.0.3

relay

Sun3/260
SunOS 3.5
ccutSun3/260
SunOS 4.0.3

学
9.6Kbps
X.25

Sun3/280S saturn
SunOS 3.5
News/820
NewsOS 3.2

Sparc1SunOS 4.0.3

VAX11/750
4.3BSDknightLuna
4.3BSD

kiwi

kogwy

colt


情

網


9.6Kbps
衛星回線

mtfuji

9.6KbpsSL

図

mothlaNews/821
NewsOS 3.2

4.1: ネットワーク接続図

Sun3/260
SunOS 4.0.3

1921989 年度 WIDE 報告書

64Kbpsなどの回線を使用していることが多い。利用する回線の種類ややゲートウェイの有無が、データサイズと応答時間の関係に影響してくると思われる。途中のゲートウェイでフラグ メントされる場合もあるし 、低速の回線へのゲートウェイでフロー制御のためにバッファリングされてしまうかも知れないからである。

(1) ethernet の場合
次のような場合について実験を行なった。

 同じ ethernet 上
 ゲートウェイが一つ ゲートウェイが二つ
これらのいずれの場合も、データサイズと応答時間の間に線形的な関参照 。
の場合にはゲートウェイの有係がある 付録
無によって線形的な関係が崩されることはないといってよい。
しかし 、ゲートウェイの性能により、応答時間そのものに大きな差が間にはゲートウェイとしてが１つ存在してい出る。
間にはとがゲートウェイをしている。ゲーて、間の通信の方が、ゲートウェイがトウェイが一つの場合の間の通信よりも、のデータを転送す二つの場合の倍、時間にして秒ほど長くかかっている。
る際に約(

A FigureA.1) ethernet

cabbage{kluna
cabbage{coltSun3 News
cabbage{kluna
cabbage{colt
2.7
0.12

VAX

8000byte(2) 64Kbps の専用回線の場合

 ゲートウェイ無し
 ゲートウェイが一つ

ehternetの場合と同様にデータサイズとの場合について実験を行なった。
応答時間の関係は線形的で、ゲートウェイを介さない時はほぼ完全な直線に参照 。ゲートウェイが一つ存在する場合は多なっている 付録
少傾きが大きくなっていて、応答時間も長くなっている。
間に存在するゲートウェイは、ゲートウェイが無しの場合のサーバマシンのであるので、応答時間が長くなっているのは当然である。

(

relay

A FigureA.2)

jp-gate{nirvana

T = D1 + L1/B + E + L2/B + D2の式を用いると、いま、L1 = L2 、E = 0 、であり、D1 = D2 と考えると、
jp-gate{relay 間は

第 5部

193

プロセス間通信T = 2(D1 + L1/B)
jp-gate{nirvana 間は、という応答時間になる。また、

T = 2(D10 + L1/B) + OOD1
jp-gate{nirvanaとなる。ここで、 はゲートウェイにおけるオーバヘッドである。 0 は間の遅延であり、 0 >である。
のグのグラフよりも傾きが大きく、上方にあるのがラフの方が理解される。

jp-gate{nirvana
jp-gate{relay

D1 D1(3) 9.6Kbps の回線の場合
次のような場合を考えてみた。

 X.25 網国内回線
 X.25 網衛星回線
 シリアル回線

X.25 網の国内回線と衛星回線を用いた場合は、計測結果にかなりのバ
ラツキがあった (付録 A FigureA.3 、FigureA.4参照)。平均をとると線形になっていることが読みとれるが、最長応答時間と最短応答時間には、7 秒近くの差がある場合もある。平均値をそのデータサイズに対する応答時間とすることには無理がある。もっと、バラツキを吸収するような代表値を考えなくてはならない。データサイズが大きい方が傾きが緩やかになるのは、データサイズが大きいとパケット喪失が多くなり、戻ってくるパケッ
ト数が少ないため、バラツキが小さくなるからである。
シリアル回線を使用した実験は、他のトラフィックが全くなく、計算機にも負荷はかかっていない状態で行なった。この場合は、完全な直線であっ参照 。
のて、バラツキも全くない 付録
は変数である。
は本来変数である
式を考えてみると、 は定数でが、ここでは、実験パケットしか流れていないことを考えると、ある時刻
はデータサイズには一定の値を持つと考えてよい。すると、応答時間の一時関数になるが、そのグラフは理論と一致して直線になっているこが平常から負荷のとがわかる。しかし 、上の二つの例では、ホスト大きい計算機である上、ネットワークにもかなりのトラフィックがあるので上で見たようなバラツキが現れてくるのである。

B

L1

(

A FigureA.5
L1) T = 2(D1 + L1/B)
D1
T

ccut

194

1989 年度 WIDE 報告書(4) バンド 幅の違う回線を接続した場合

jp-gate{saturn は Figure4.1 にあるように、64Kbps と 9.6Kbps の回線がゲートウェイ一つで接続されている。9.6Kbps の回線を使っているので、やはり、かなりのバラツキがある。平均をとっても、今までのように参照 。実際のネッ線形であるとはいい難いようである 付録
トワークの複雑な様子がうかがえる。

(

4.1.3

A FigureA.6)

ネットワークの混雑状況との関係

ネットワークの混雑の影響も考えられる。回線が混雑していればそれだけ通信は遅くなり、すいている時よりも応答時間は余分にかかることにをしてネットワークが混雑する状況をなる。ここでは、その回線には指定したホストに対しメッセージを連続的に作り出した。
送り、転送効率とともに相手ホストがどれだけデータを受け取れたかをテストするもので、パケット数、各パケットを転送する間隔、データサイズなどが指定できる。タイムアウトを にしてあり、応答パケットを期待しないし 、サーバプロセスも応答を返すことをしていない。指定されたサイズのデータを全て送った後で、相手ホストにいくつのパケットを受け取っで尋ねる。計測を行なう回線の外側の計算機同士でお互いにたかをを実行して、クライアントマシンとサーバマシンに負荷をかけずに、その回線を故意に混雑させた。

spray

spray

RPC

0

spray

RPC

(1) ethrnet の場合
ネットワークの混雑状況はほとんど 影響していない。平常時における参照 。実験時は、その測定と全く同じ計測結果を得た 付録
回線を使用していて、かなりネットワークが混んでいるという感じを受けのような高速の回線では応答時間には影響を及ぼさないよ
たが、
うである。

(

A FigureA.7)

ethernet(2) 64Kbps の専用回線の場合
この場合は、混雑させた時の方が、平常時よりも応答時間は長くなっていて、データサイズが大きいほどその影響を受けやすいようである 付録
参照 。
のデータ転送では平常時のときの実験と約秒の差が出た。しかし 、応答時間は長くなっているが、それでも、データ
サイズと応答時間の線形的な関係はそのままであるといって良い。

FigureA.8) 8000byte

(

A
0.4

第 5部

195

プロセス間通信(3) 9.6Kbps の回線の場合

sprayを実行しながら
シリアル回線でホスト同士を接続して、そこで実験を行なおうとしたが 、応答パケットを全く受け取ることができなかった。
の応答も受け取れなかった。
ではバンド 幅が狭いのでトラフィックが少なくてもすぐ 回線が混んでしまうようである。

spray

9.6Kbps

X.25 網の場合も spray の応答パケットが受け取れなかったので、実験プログラムは走らせなかった。
4.1.4

サーバの負荷との関係

NFS のようなアプリケーションでは 、サーバに RPC の要求メッセー
ジが過度に集中する場合も考えなくてはならない。ここでは、spray コマ
ンドを自ホストに対して実行し 、ネットワークとは関係なく、純粋にサーバのみに負荷をかけた。ロードの平均が くらいの状態を保って同じプロ
グラムを走らせた。

6(1) ethernet の場合

cabbage{kluna の通信でサーバである kluna に負荷をかけた。負荷をかけた時の方が応答時間は長くなるが、値としては負荷をかけない時とあまり変わらず、タイムアウトの値に影響するほどの差はない 付録
参照 。
秒程度の差であるので、秒単位で動いているクロックがあることを考えるとこの値は問題ではない。

) 0.01

0.02(

A FigureA.7(2) 64Kbps の専用回線の場合

jp-gate{relay の通信でサーバである relay に負荷をかけたが 、この場
合は平常時との差が全く現れなかった (付録 A FigureA.8参照)。正確には0.01 秒程度の差があることもあるが、これは応答時間が 1 秒程度であることを考えると、無視できる範囲である。
4.1.5

ゲートウェイの負荷との関係

ゲートウェイの負荷がパケットの転送に、実際にどのように影響するのかを計測した。経路制御を行なうのはゲートウェイのレ イヤで、パケットを一時的に取り込みデスティネーションに向けて送り出すのである。
ゲートウェイの負荷が大きい時にはその動作が遅くなることも予想される。
コマンドを実計測は、経路上のゲートウェイで、自ホストに対して
行して、ロード 平均が くらいの状態で行なった。

IP

6

spray

196

1989 年度 WIDE 報告書(1) ethernet の場合

potato{kluna の通信でゲートウェイの一つである cabbage に負荷をかけて実験を行なった。しかし 、全くその影響を見ることはできなかった (付録 A FigureA.9参照)。
(2)64Kbps の専用回線の場合

jp-gate{nirvana の通信で、ゲートウェイである ralay に負荷をかけた。
この場合も、全く影響は現れなかった (付録 A FigureA.8参照) 。
ここでは、ゲートウェイに負荷をかけるために、自ホストに対してを行なったが、その効果がじゅうぶんでなかったのかもしれない。

4.2

spray

エラー率

これらの負荷を考えた場合、もう一つ考慮しなくてはいけないのは、パケット喪失の起こる頻度である。エラー率というのは、再送の制御をする
際、かなり重要になってくる点である。計測に使ったプログラムでは再送を行なわないようにしてあって、エラー状況も観測できるようにした。平
もの専用回線もご く稀にしか落さず、再送制
常時には御をすればほとんど 問題はない。

ethernet

64Kbps

しかし 、ネットワークを混雑させた場合は、極端にその回線の信頼性がの場合で最大のパケットを落して落ている。実験によると、以上になると、 〜くらいは常に落してしまう。また、
いて、の専用回線では、のデータを送るのに、のパケットを落している。このプログラムの最小データサイズであるのデー
落してしまっている。
タを転送する時でさえ、

ethernet
3 4%
8000byte

4500byte
64Kbps1%

9%22%
86byteethernet
64Kbpsではデータサイズが大サーバマシンに負荷をかけた場合は、程度落した。ところが、の専用回線では平常きくなるにつれ時と変わらずほとんどすべてのパケットを受け取ることができていて、エラー率は無視できる。

10%

一方、ゲートウェイに負荷がかかった場合には、その影響は受けていな送ることができている。
いようで、平常時と同様ほぼ

100%

転送における信頼性は、再送制御によってハードウェア的なエラーをカやバーすることができるかど うかによって決まってくる。
の専用回線であれば 、再送の回数を適当に指定することで、高い信頼性がの回線ではデータサイズが大きくなるにつれ、得られる。しかし 、

ethernet 64kbps

9.6Kbps

第 5部

ト数

197

(100 のパケットのうち応答のなかったパケッ

)

(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)

プロセス間通信86[btye] 1002 2000 3000 4000 5000 6000 7000 8000
0
0
0
0
0
0
0
0
0
0
0
0 0*
{
{
{
{
{
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
2
0
0
2
2
3
4
3
9
1
2
2
3
4
8 12
7 10
0
0
0
0
0
1
0
0
0
* 2994byte

での値(1)cabbage{potato:ゲートウェイなし(2)kluna{knight:ゲートウェイなし(3)cabbage{kluna:ゲートウェイ１つ(4)cabbage-colt:ゲートウェイ２つ(5)potato{kluna:ゲートウェイなし２つ(6)cabbage{kluna:ネットワークを混雑させた場合(7)cabbage{kluna:サーバに負荷を与えた場合(8)potato{kluna:ゲートウェイに負荷を与えた場合
表

4.1: ethernet でのパケット喪失状況

198
ト数

1989 年度 WIDE 報告書(100 のパケットのうち応答のなかったパケッ)

86[btye] 1002 2000 3000 4000 5000 6000 7000 8000
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0
4
1
6 10 13 17 15 18 16 22
3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
(1)jp-gate{relay:ゲートウェイなし(2)jp-gate{nirvana:ゲートウェイ２つ(3)jp-gate-relay:ネットワークを混雑させた場合(4)jp-gate{relay:サーバに負荷を与えた場合(5)jp-gate{nirvana:ゲートウェイに負荷を与えた場合

(1)
(2)
(3)
(4)
(5)

表

ト数

)

(1)
(2)
(3)
(4)

4.2: 64Kbps 専用回線 でのパケット喪失状況(50 のパケットのうち応答のなかったパケッ

86[btye] 1002 2000 3000 4000 5000 6000 7000 8000
0
0
0
0
1
4 26 41{00022 11 27 46
{
0
0
0
0
0
0
0
0
{
2
0
0
0
8
6 20 36{(1)ccut{sarutn:国内回線 (X.25)(2)ccut{mtfuji:衛星回線 (X.25)(3)kiwi{mothla:シリアル回線(4)jp-gate{saturn:バンド 幅の違う回線の接続の場合

4.3: 9600bps 回線、及び 、バンド 幅の違う回線の接続 でのパケット喪

表
失状況

第 5部

プロセス間通信199

8000byte

パケット喪失率も大きくなっていて、のデータは送ることができなかった。このような場合にはそのエラー率を考慮して再送を制御する必
要がある。

4.3

データサイズと転送効率

経験的には 、データサイズは大きい方が転送効率が良いと考えられてのいる。計測の結果からも、ほぼそのように考えられる。例えば 、専用回線でゲートウェイを一つ介する場合、のデータを転送する、ではかかっている。
のデータをのに二回送るよりものデータを一回送る方が良いということになる。
実験を行なった他のほとんどの場合、同じ考察をすることができる。
しかし、シリアル回線を使用して他のトラフィック無しに行なった実験でのデータ転送に、は、逆の結果を得たのである。
ではを要している。多少ではあるが 、のデータを二回送った方が良いことになる。この場合は、計算機にほとんど 負荷がなく、実験パケット以外のトラフィックは全くないので実際のネットワークの状
況とは異なっているのであるが、単に、データサイズは大きい方が効率がとして、データを分割して送っ良いとは言えないことになる。また、た方が良いかど うかを考える必要がある。実際、同一ホスト上の同一プロシージャを再利用する場合はキャッシュを用いるので早い計算機の場合に以下、遅い場合は程度かかることもある。新たに転送を行
はなう場合は数百程度である。計算機の能力によって、データサイズが大きい方がいいのか小さい方がいいのかが決まってくるであろう。
ただし 、シリアル回線の実験結果は一般的なネットワークの状況とはかけ離れているので、やはり、実際のネットワーク上で行った実験の結果が有効であろう。応答時間に関してデータサイズが大き方が良いとなれば 、としてのオーバヘッドを考慮する必要ななくなる。一概に、データサ
イズが大きい方が良いとは限らないということを知った上で、状況を良く考慮してアプリケーションを作成することが大切である。

1389ms 8000byte
8000byte

4000btye
4000byte

2434ms3000byte

12751ms

RPC

10ms

RPC

ms

40ms

64Kbps6343ms 6000byte
3000btye

第 5章
RPC の最適利用のための支援システム

RPC

実際のネットワークにおけるくつかの計測をもとに、を利用する
際の最適なデータサイズとタイムアウトを決定する機構を考えてみる。

5.1

データサイズ

一般的な見方として 、転送するデータサイズは大きい方が良いということであったが、一概にそうとはいえない実験結果があった。実際に通信したいホストとのリンクではど うなのかを知らなくてはならない。いくつかの結果から、データを分けて送った方がいいのか、それとも大きい方が効率がよいのかということを判定するような機構が必要である。

RPC として一つのパケットにかかるオーバヘッドを
f (x) + 2
f (2x) +とすると、( ) (2 )の大小比較になり、この値の小さい方がよいことになる。ただし、f x ; f x
はデータサイズが x; x の時の応答時間である。
このオーバヘッド の値は、計算機の能力によって決まってくるであろう。もし 、データサイズが大きい方が効率が良いのであれば 、このオーバ
ヘッドを考慮する必要はない。データサイズが小さい方が効率が良いという時にこの値を知り、それを反映するようにする。実際には、データサイズは大きい方が効率が良いようなので、このオーバヘッドについてはあまり細かい考察をしないことにする。

2

そこで、データサイズは大きい方が良いとなると、相手ホストに対して送ることのできる最大のデータサイズを知らなくてはならない。
やの専用回線では、のデータを送ることができた。しかの回線ではのデータはエラー率は高くても何とか送し、れるが、のデータは一つも送ることができなかった。また、

64Kbps
9.6Kbps8000byte

8000byte
7500byte

200

ethernet
Sun1

第 5部

Sun2

プロセス間通信

201

3000byte

やでは、以上のデータは受け取ることができなかった。つまり、ネットワークの状況や計算機の種類によって送ることのできる最大のデータサイズというものが決まってくる。安定した通信を行なうためには、エラー率を考慮して安全に送れる最大データサイズを知ることが必要である。
この回線のエラー率は再送するべき回数にも影響するが 、すでに再送回数が決定されているとすると、その再送の後、応答を受け取ることのでにおけるエラー率と考えることもできる。このにきない率をおけるエラー率がある数字以下になるようなデータサイズが 、安定した通信を行なえるデータサイズということになる。信頼性が低く、パケット喪失の多い回線では、ある確率で必ずパケットが戻ってくるようなデータサ
イズを、転送するべきデータサイズとする必要がある。しかし 、のように信頼性があり、再送によってとしてのエラーがほとんどな
いような回線では、単純に送ることのできる最大のデータサイズが最適な
データサイズということになる。

RPC

RPC

ethernet

RPC

送ることのできる最大データサイズを知る方法として通常からトラフィッ
クを監視しておく方法と、必要な時に実際に送ってみるという方法が考えを問題なく使える環境を作るられる。目的は、どんな相手に対してもことであるので、最終的にはネットワークの通常のトラフィックから情報を最適な効率で利用できるように、デーを得るのがよい。ここでは、タサイズとタイムアウトを適切に選択するようなシステムを作ることを考えているので、実際に測定用データを送る方法をとる。このシステムがうの中に組み込むことを考える。
まく動作するようになった後で、

NFS

RPC

NFS

最大データサイズを得るには、応答パケットが戻ってくるに十分な時
間待たなければならない。十分な時間の待機の後、戻ってこなければ小さいサイズのパケットを、戻ってきたならば大きいサイズのパケットを送ってみることにする。そして、最終的に求めるべきデータサイズというものに収束させる。

5.2

タイムアウト

転送するデータサイズはそのリンクで安全に送れる最大のデータサイズが良いということであった。ここでいう 安全 にという言葉は再送にの失敗を回避することができるという意味である。その安全
よって、に送れる最大データサイズを送受するのにかかる応答時間を知ることができれば 、タイムアウトをその応答時間から適切に決めることができる。

RPC

\

"

パケットが必ず返ってくるという保証があるのならタイムアウトは長202

1989 年度 WIDE 報告書

ethernet

を使用しているローカルエリアネットワーク
く取った方がよい。
では、信頼性も高く、応答時間も無視できるほどであるのでタイムアウト
は多少長く取っても問題はない。むしろ、このような回線では長くとるべきである。回線が混雑しているときやサーバマシンに負荷のかかっている
ときには一割程度のエラーがあるが、それでも、応答時間が短いので、再送がなされても効率が極端に落ちることはない。
問題は、信頼性の低い回線を使用する際のタイムアウトの決定である。
の専用回線では平常時にはパケットを落すことはほとんどないが、
ネットワークが混雑している時にはかなりの率でパケットを喪失するようの回線では、データサイズが大きくなると極端にである。また、
信頼性が落ちていた。このような場合は、何パーセントのパケットが返ってくるかという指定が必要になってくる。その値を満たすようなデータサ
イズを見つけ出さなければならない。そして、そのデータサイズのパケッ
トが送り出されて戻ってくるまでの応答時間を知り、その値にしたがってタイムアウトを決定するべきである。
さらに 、適切なタイムアウトの決定には 、応答時間のバラツキを無視することはできない。このバラツキは、最大値をとれば 、平均値をとった、
参時と同様に線形になることがうかがえる 付録
照 。平均値のグラフの傾きと最大値のグラフの傾きとの関係は何ともいえ間ではほぼ同じ傾きのであるし 、間では最ない。
大値のグラフの傾きの方が大きい。
間でも、やはり、最大値のグラフの傾きの方が大きい。しかし 、いずれの場合も、データサイズ
が大きくなってパケット喪失率が大きくなると、最大値として予想される
時間待っても、パケットは返ってこなことがわかる。
最適なサイズのデータを送受するのにかかる応答時間がわかったとす
ると、タイムアウトは次のように決定することができる。
をそのデータサイズに対する平均の応答時間、 を回線によって定まる応答時間のバラツキ度、 を上乗せ値として、

64Kbps

9.6Kbps()

ccut{saturn

A FigureA.3 FigureA.4

jp-gate{saturnT

ccut{mtfuji

ftimeout = T 3 f +のようになる。バラツキは f で考慮されているので、この上乗せ値は応答時間の何割というような指定で良いと考える。

5.3

再送回数

再送はパケットが喪失したときにのみ行なわれるべきである。パケットが喪失したかど うかは十分長い時間待たなければわからないが、回線のエ第 5部

プロセス間通信203

ラー率というものがわかっていればある程度予測することができる。実験やの専用回線では平均的な応の結果から、平常時には、答時間を越えて返ってこないパケットはほとんどなく、再送を行なうことが失敗することは回避される。
ででは再送の回数をという変数によってマウント時に設定のデフォルトは３回である。信頼性のある回することになっていて、の回線のように信頼性の高く線では十分な値と思われる。また、ない場合は、再送回数が３回ぐらいでも安全に通信できるようなデータサ
イズを選択することが必要である。

ethernet 64Kbps

RPC
NFS

retransSun

9.6Kbps

第 6章
プロト タイプの試作

6.1

データサイズとタイムアウト の決定

5

RPC

第 章で考えてきたように、を最適に利用するためのネットワー
クの診断システムは、様々な要因を考慮しなくてはならない。ここでは 、指定した相手ホストに対して送ることのできる最大データサイズと、そのときのタイムアウトを知ることを考える。

6.1.1

最大データサイズの決定

二分探索のアルゴリズムを用いてデータサイズを決定することにする。
すなわち、あるデータサイズのパケットを送ってみて、応答が返らなければデータサイズを小さくして送り、応答が返ればデータサイズを大きくして送る。

RPC

500byte

8000byteからである。初期値として転送するデータの範囲はとを指定しておくと、転送するデータサイズの初期値はとの中間値であるとなる。 回の転送のうち回応答が返ってこないとデータサイズをとの中間値にして転送してみる。 回だけ応答が返らず 回応答がであるとの中間値である
返るか、 回応答が返ってきたら、のデータサイズを持つ
パケットを転送する。以後、これを繰り返す。成功した時に、転送できなかったデータサイズとの差が以下であったら、終了し、そのときのデータサイズを返す。
のデーを相手ホストに対して行なうことはできないとタが送れないときはであることから決判断する。これは、 の最小パケットサイズが定した。

250byte 8250byte
250byte 8250byte
22250byte
106250byte

4250byte
104250byte 250byte
1
94250byte 8250byte
RPC

500byte500byte

RPC
IP

512byte

1 回の RPC では 3 回の再送を行う。RPC の応答が返ってこないということは UDP のパケットを 4 回続けて喪失したことになる。
204

第 5部
6.1.2

205

プロセス間通信

タイムアウト の決定

RPC を行なう毎に応答時間を測定している。lowest layer に提供されているライブラリの中で、sendto システムコールを行なう直前から recvfrom
システムコールの直後までの時間を測定する。

RPC に与えるタイムアウトは、データサイズを大きくする時は、その時のデータサイズを転送するのにかかった応答時間の最大値の 3 倍の値を使う。データサイズを小さくする時は、返ってきた応答パケットがあればその応答時間の最大値の 倍を、なければ 、そのときに使っていたタイム
アウトをそのまま使う。

2

返す値は、定まったデータサイズに対する応答時間の平均値の一割増しの値である。

6.2

結果B
ethernet や 64Kbps の専用回線の場合には 8000byte まで送ることができていて、その応答時間も安定していることがわかる。kluna{knight(sun1.5)の場合には、実際、2994byte までのデータしか送ることはできない。この場合の結果は、2875byte であるので、適当と思われる。
9600bps の場合はかなり不規則であることがうかがえる。例えば、ccut{
saturn 間の通信では、十分と思われるタイムアウトで 、5281byte のデー
タは送れないが、5265byte のデータは 9 回続けて送れて、成功している。
結果を付録 に示す。

6.3

評価

500byte 8000byte
RPC

実際に転送してみるデータサイズをからに限定したが、これは、初期値の与え方で設定できるし 、に与えるタイムアウトの初期値も同様である。こういった変数をコマンド 行から入力する方法も考えられる。ある程度、回線の様子がわかっている場合にはその方が良いでで、サーバがの場合は、あろう。たとえば 、クライアントが上にあり、タイムアウトの初期値としては長過ぎ同じる。応答が返ってくるのであればいいが、この場合は、がであり、最初の 回の転送は全て失敗するのであるから、タイムアウトが長いことは不都合である。タイムアウトの初期値の与え方を、コマンド 行
からの入力にするか、あるいは、回線のバンド 幅によって決めるなどの対処があっても良かった。

kluna

ethernet

10knight20000ms
knight Sun1.5

206

1989 年度 WIDE 報告書

cabbage{colt kluna{、
応答時間の一割増しの値をタイムアウトとしたが、、、の通信では、実際にその値よりも長い応答時間で戻ってきているパケットがある。これは、バラツキを考慮していないためである。ローカルエリアネットワークのように応答時間の短い通信では、計算機のクロックの性能により誤差が出てくる場合も考えられるが、バラツキを考慮するなら、上乗せ値 としては、一割程度の増分で良いと思われる。
の通信の結果を見ると 、で送れなかったのが 、の 回目から送れるようになっている。この回線は、バラツキが大きかったのであるが、 分探索のアルゴ リズムでは、もし 、急に、ネッ
トワークが混雑し始めて応答時間が長くなったとすると、一度送ることができると判断したデータサイズよりも小さいパケットを送ることはしない
ので、結果は収束しないことになる。本当に、ネットワークの状況がそれほど 頻繁に変化しているのならば 、 分探索のアルゴ リズムをそのまま使うのではなく、応用して使わなければならない。

knight ccut{saturn jp-gate{saturnccut{saturn5265byte 25281byte

2

2

6.4

今後の課題

今後の拡張に関して次のようなことが挙げられる。

 10 回に 9 回応答が返ればいいということにしたが 、エラー率というRPCものを正しく扱わなければならない。
としてのエラー率を指定
し 、その範囲内で応答の返ってくるようなデータサイズを探さなければならない。

 バラツキについて何も考慮していないが、必要不可欠な要因である。
バラツキによっては、タイムアウトの設定に大きな違いがあるし、デー
タサイズが小さい時の方が大きいときよりも、応答時間が長くなることもあり得る。応答時間の最大値も、また、データサイズと線形的な関係があったことをもっと考慮するべきである。さらに、バラツキの分散を知ることも必要なのかも知れない。

 実時間で行なっているが、低速の回線では、結果が出されるまでにかなりの時間がかかる。実時間で計測することの長所は 、その瞬間のネットワークの状況を知ることができることである。しかし 、将来、などのシステムでの利用を考えるとそのネットワークの全体的な状況を把握した方が良いということも考えられる。また、統計情報
は多い方が良い値を導くことができるかもしれない。現在の状況を反映する範囲で、通常からの監視により、情報を集める方がよい。ネッ

NFS

第 5部

207

プロセス間通信

トワークを診断するために、ネットワークのトラフィックを増やすこともなくなる。

 効率のよい転送を考えなくてはならないのであるが、今回は転送効率について評価していない。返されたデータサイズとタイムアウトで転送した場合の転送効率も、値として返すべきであろう。

 UDP を用いた RPC ということで、8Kbyte までのデータしか扱わ

ethernet

なかった。しかし 、これは、拡張されるべきものと考える。
のように信頼性が高く、かつ、高速の回線を利用して通信を行なう場
合には、もっと大きなデータを転送した方が効率は良いのかも知れなのプロトコルとしては何も規定していないので、としい。
て、この値を大きくとることができるのではないだろうか。現在は、ではのデータを送ることができないが 、おそらく、この拡張は可能であろう。

UDP

RPC

RPC

8Kbyte付録 A
データサイズと応答時間の関係

4

第 章で行なったデータサイズと応答時間の関係の計測の結果を以下
に示す。

208

第 5部

プロセス間通信図A.1: ethernet の場合

209

210

1989 年度 WIDE 報告書

図A.2: 64Kbps 専用回線の場合

第 5部

図

プロセス間通信A.3: 9.6Kbps 国内回線の場合

211

212

1989 年度 WIDE 報告書

図A.4: 9.6Kbps 衛星回線の場合

第 5部

図

プロセス間通信A.5: 9.6Kbps シリアル回線の場合

213

214

1989 年度 WIDE 報告書

図A.6: バンド 幅の違う回線接続の場合

第 5部

図

プロセス間通信A.7: ethernet に負荷をかけた場合

215

216

1989 年度 WIDE 報告書

図A.8: 64Kbps 専用回線に負荷をかけた場合

第 5部

図

プロセス間通信A.9: ゲートウェイに負荷をかけた場合 (ethernet での接続)

217

218

1989 年度 WIDE 報告書

図A.10: ゲートウェイに負荷をかけた場合 (64kbps 専用回線での接続)

付録 B
結果
yasuko*cabbage[43] getsizetime potato
check up ! to potato
4250 byte (20000.ms)
29. 19. 20. 19. 19. 20. 19. 20. 29. 29.
6250 byte (87.ms)
29. 30. 29. 30. 29. 30. 39. 39. 30. 29.
7250 byte (117.ms)
39. 29. 29. 40. 39. 29. 29. 29. 29. 39.
7750 byte (120.ms)
39. 39. 30. 39. 39. 50. 49. 39. 30. 39.
8000 byte (150.ms)
39. 39. 39. 40. 39. 39. 40. 39. 30. 39.
max data size = 8000 byte
RTT = 38 ms timeout = 41 ms
yasuko*cabbage[50] getsizetime kluna
check up ! to kluna
4250 byte (20000.ms)
109. 109. 110. 110. 129. 109. 109. 119. 109. 109.
6250 byte (387.ms)
169. 159. 169. 149. 150. 159. 150. 159. 149. 150.
7250 byte (507.ms)
179. 170. 169. 169. 169. 170. 179. 179. 179. 189.
7750 byte (567.ms)
189. 180. 199. 189. 249. 180. 189. 199. 189. 219.
8000 byte (747.ms)
189. 190. 189. 190. 209. 199. 189. 189. 189. 189.
max data size = 8000 byte
RTT = 192 ms timeout = 211 ms

219

220

1989 年度 WIDE 報告書

yasuko*cabbage[52] getsizetime colt
check up ! to colt
4250 byte (20000.ms)
49. 39. 39. 40. 39. 39. 39. 39. 39. 49.
6250 byte (147.ms)
50. 59. 49. 49. 49. 50. 50. 59. 59. 59.
7250 byte (177.ms)
60. 59. 60. 59. 59. 69. 69. 60. 69. 60.
7750 byte (207.ms)
69. 60. 69. 69. 60. 60. 69. 69. 69. 69.
8000 byte (207.ms)
79. 69. 60. 69. 69. 60. 69. 69. 69. 70.
max data size = 8000 byte
RTT = 68 ms timeout = 74 ms
yasuko@potato[9] getsizetime kluna
check up ! to kluna
4250 byte (20000.ms)
159. 120. 119. 120. 119. 119. 119. 139. 120. 119.
6250 byte (477.ms)
199. 179. 159. 160. 159. 180. 200. 180. 200. 179.
7250 byte (600.ms)
200. 199. 199. 199. 199. 179. 179. 180. 179. 219.
7750 byte (657.ms)
219. 219. 199. 239. 180. 199. 200. 199. 199. 220.
8000 byte (717.ms)
220. 239. 219. 219. 219. 219. 239. 200. 219. 219.
max data size = 8000 byte
RTT = 221 ms timeout = 243 ms

第 5部

プロセス間通信

221

yasuko*kluna[34] getsizetime knight
check up ! to knight4250 byte (20000.ms)*<5> *<5>2250 byte (20000.ms)
66. 49. 49. 49. 49. 49. 49. 49. 49. 49.
3250 byte (198.ms)*<5> *<5>2750 byte (198.ms)
49. 49. 49. 49. 49. 49. 49. 49. 49. 49.
3000 byte (147.ms)*<5> *<5>2875 byte (147.ms)
49. 49. 49. 49. 66. 66. 49. 49. 49. 49.
max data size = 2875 byte
RTT = 52 ms timeout = 57 ms
yasuko*jp-gate[10] getsizetime relay.cc.u-tokyo.ac.jp
check up ! to relay.cc.u-tokyo.ac.jp
4250 byte (20000.ms)
1130. 1129. 1129. 1120. 1130. 1129. 1119. 1130. 1129.
6250 byte (2260.ms)
1649. 1650. 1649. 1650. 1649. 1650. 1649. 1649. 1660.
7250 byte (3320.ms)
1920. 1900. 1910. 1909. 1920. 1900. 1910. 1899. 1909.
7750 byte (3840.ms)
2030. 2039. 2040. 2030. 2040. 2139. 2030. 2029. 2030.
8000 byte (4278.ms)
2100. 2099. 2099. 2110. 2100. 2100. 2100. 2090. 2100.
max data size = 8000 byte
RTT = 2099 ms timeout = 2308 ms

1119.
1649.
1909.
2039.
2099.

222

1989 年度 WIDE 報告書

yasuko*jp-gate[11] getsizetime nirvana.cs.titech.ac.jp
check up ! to nirvana.cs.titech.ac.jp
4250 byte (20000.ms)
2709. 1660. 1539. 1690. 1599. 1610. 1470. 1529. 1530.
6250 byte (5418.ms)
2050. 2129. 2160. 2109. 2210. 2239. 2099. 2088. 2169.
7250 byte (4580.ms)
2300. 2280. 2240. 2240. 2350. 2620. 2380. 2620. 2590.
7750 byte (5458.ms)
2809. 2930. 2910. 2410. 2500. 2800. 2770. 2480. 2630.
8000 byte (5860.ms)
2439. 2438. 2450. 2410. 2430. 2760. 2580. 2639. 2700.
max data size = 8000 byte
RTT = 2556 ms timeout = 2811 ms

1800.
2290.
2729.
2369.
2720.

yasuko*ccut[12] getsizetime saturn.center.osaka-u.ac.jp
check up ! to saturn.center.osaka-u.ac.jp
4250 byte (20000.ms)
12560. 13220. 10860. 14260. 13400. 12300. 13140. 13100. 13000. 11520.
6250 byte (42780.ms)*<5> *<5>5250 byte (42780.ms)
14700. 13400. 13960. 12980. 11840. 15280. *<5> 17220. 14240. 13860.
5750 byte (51660.ms)*<5> *<5>5500 byte (51660.ms)*<5> *<5>5375 byte (51660.ms)
14680. *<5> *<5>5312 byte (29360.ms)*<5> *<5>5281 byte (29360.ms)*<5> *<5>5265 byte (29360.ms)*<5> 13920. 13160. 13180. 11560. 12580. 14820. 11420. 14960. 11700.
max data size = 5265 byte
RTT = 13033 ms timeout = 14336 ms

第 5部

プロセス間通信

223

yasuko*jp-gate[14] getsizetime saturn.center.osaka-u.ac.jp
check up ! to saturn.center.osaka-u.ac.jp
4250 byte (20000.ms)
15229. 10359. *<5> *<5>2250 byte (15229.ms)
8098. 7150. 9860. 8859. 8420. 9710. 14478. 7710. 9920. 9609.
3250 byte (28956.ms)
11930. *<5> 10910. 12190. 10279. 10380. 10980. 8368. 7750. 9830.
3750 byte (24380.ms)
8759. 8450. 10420. 9049. 8378. 8810. 9900. 8279. 8810. 10600.
4000 byte (21200.ms)
8928. 9050. 10740. 8919. 9120. 10480. 9289. 9639. 9920. 8549.
max data size = 4000 byte
RTT = 9463 ms timeout = 10409 ms

224

1989 年度 WIDE 報告書