KONOEパラメータデータベース階層

1.はじめに

KONOEはネットワークに分散したシステムですが、全体が協調して動作できる ようにするためには、それらのプロセスが共通に参照する環境変数が必要です。 あるプロセスがその値を変更すると、それがネットワーク全体に伝搬するという 機構を用意する必要があります。

その機構が保持すべき情報には、いろいろなものを考えることができます。 極言するとネットワークオブジェクトデータベースのようなものにすることも 可能です。しかしここでは、非常に単純な実装を考えます。まさにUNIXの 環境変数のような、名前に文字列の値を与えるだけのものからスタートします。 KONOEでは名前空間(Name Space)と呼びます。

2.ネットワーク透過な名前空間

ネットワーク透過ということから、KONOEに所属する様々なプロセスが共有する 論理名空間ということになります。同じホストの上であれば共有メモリーを使用する ことが自然な解決方法でしょう。残念ながら現在のUNIXではネットワークを越えて プロセスが共有できる共有メモリーは実装されていません。そのような機構を 作り込む必要があります。

あるホストのテーブルが書き換えられると、それがすべてのホストに伝搬すれば よいのですが、伝搬には何らかの通信が必要です。通常はソケット通信を使うことに なるでしょう。そうすると、名前空間の利用者が値を書き換えたいときは、 その要求をあるデーモンに投げることになります。そのデーモンはそれを ネットワーク全体に放送します。

名前空間を読むだけの利用者はできるだけオーバーヘッドを減らして簡便に アクセスがしたいでしょう。読むたびにシステムコールを発行するようなことは さけたいものです。そこで、読み出し専用利用者は共有メモリーとしてテーブルを 参照します。プロセスのメモリー空間に共有メモリーをマップすることで オーバーヘッドの少ない高速なアクセスが可能です。

3.実装様式の検討

プログラム上は共有メモリー上にオブジェクトを置きたいのですが、ここでも オブジェクト永続性の問題が出てきます。特に、プロセスごとで異なった 仮想メモリーアドレスに共有メモリーがマップされることから、例えば ポインターメンバーを持つオブジェクトは正しく扱われません。昔の計算機 用語でいえばリロケータブルなオブジェクトでなければなりません。相互参照が その位置からのオフセットを用いてなされるような工夫が必要です。

現在の実装では単一の名前空間のみ実装されていますが、場合によっては 異なった名前空間を扱う、あるいは複数の名前空間を扱いたい場合があり得ます。 また、ネットワーク透過でない、ホストに局所的な名前空間、さらにはプロセスに 閉じた名前空間なども必要になってきます。これらの実装も検討する必要があります。

概要へ戻る  目次へ戻る 次章「KONOEを構成するプロセス」へ


[intro/database.html] Last Modified : 14-Mar-2001.

KONOEコラボレーション konoe-req@konoe.kek.jp