分散共有空間(3)

並列分散ソフトウェア

                                       電子・情報工学系
                                       新城 靖
                                       <yas@is.tsukuba.ac.jp>

このページは、次の URL にあります。
http://www.hlla.is.tsukuba.ac.jp/~yas/sie/pdsoft-2001/2002-02-21
あるいは、次のページから手繰っていくこともできます。
http://www.hlla.is.tsukuba.ac.jp/~yas/sie/
http://www.is.tsukuba.ac.jp/~yas/index-j.html
http://www.hlla.is.tsukuba.ac.jp/~yas/index-j.html

■今日の重要な話

Jini
名前サービスの重要性
分散型プログラミング言語

参考文献

Marko Boger: Java in Distributed Systems: Concurrency, Distribution and Persistence, John Wiley & Sons, 2001. ISBN: 0471498386

http://www.dpunkt.de/produkte/dejay

■フィードバック

★WWWアクセスカウンタ

アクセス・カウンタに使えるオブジェクトが作れればよい。実際に、アプレットまで作る必要はない。

逆に、表面的にアクセスカウンタができたとしても、内部的に JavaSpaces を使っていなければ、不可。

複数のアクセスカウンタが、きちんと区別されて動作することを示しなさい。 URL は、単なるデータではなくて、identity を示すためのものなので、 take/read する時には、null にしてはいけない。

■Jini

Jini (ジニー)は、Java を中核にした、情報家電製品を相互接続するための通信技術。

1999年に、サン・マイクロシステムズ社のビル・ジョイらによって開発され発表された。

Jini の目標は、ネットワークで Plug & Play を実現すること。機器をネットワークに接続しただけで、特別な設定をしなくてもすぐに利用可能になること。

目標

「サービス」の提供者と利用者が、お互いに事前の知識なしでつながる。
- (IP)アドレス
- 名前サーバの位置(/etc/resolv.conf)
サービスの位置がわからなくてもよい。
古典的な「ネットワーク管理者」を廃したい。

サービスには、ハード的なもの（プリンタ、ディジタルカメラ、CD Player）の他に、ソフト的なもの(スペルチェック、翻訳、アドレス帳)がふくまれる。

JavaSpaces は、内部的に Jini のルックアップ・サービスの実現で使われている。JavaSpaces も、Jini でアクセス可能なサービスの１つと考えることもできる。

◆UPnP (Universal Plugand Play)

Microsoft の、Jini に対抗した技術。

◆ルックアップ・サービス

Jini中心的な技術が、ルックアップ・サービス。

サービスの登録と検索

インタフェース
属性

ルックアップ・サービス自身も、最初から知られている必要はない。ネットワーク上で自動的に探される。 Discovery と Join。

◆リース

サービスは、永続的に登録されるではなくて、特定の時間だけ利用可能になる。

この仕組みが、leasing。Java のオブジェクトが lease。

リース期間は、延長することができる。延長されなかった lease は、ルックアップ・サービスから削除される。登録されているサービスを明示的に削除する仕組みは、存在しない。

サービスが削除された時には、分散型イベント配送サービスにより関係している所に知らされる。

トランザクションのインタフェースは定められているが、具体的な実現は各サービスにまかされている。

◆Jiniを使うのに必要とされているもの

Java JDK 1.2以降, JavaVM
ネットワーク
- TCP/IP
- 無線、Bluetooth
- USB

◆サービス

サービスは、Java のオブジェクトで実現される。

サービスの提供者と利用者の間は、最終的にはに RMI で接続される。

ServiceIDLister インタフェースを implements する。

package com.sun.jini.lookup;
public interface ServiceIDListener extends java.util.EventListener {
    void serviceIDNotify(net.jini.core.lookup.ServiceID serviceID);
}

◆Discoveery と Join

各ネットワークには、ルックアップ・サーバを置く。

図

Discovery: Jini を使うには、まず、ルックアップ・サーバを探す。
Join
サービスの提供者が、インタフェースと属性をルックアップ・サーバに登録する。

Discovery の実現方法

マルチキャスト(グループ通信)。 UDP で 224.0.1.85: 4160 に要求を投げる。
ユニキャスト(IPアドレスを事前に知っている必要がある)

ルックアップ・サーバは、起動時、再起動時、224.0.1.84:4160 にMulticast Announcement Protocol で、利用可能性を広告する。

Ball.java

◆グループ

サービスのグループ化。名前(文字列)で区別される。

◆JoinManager(サーバ側)

Discovery と Join は、規格上は、ネットワーク・プロトコルになっている。 Java には、JoinManager という API がある。


    public JoinManager(Object obj,  Entry[] attrSets,
                       ServiceIDListener callback,
                       LeaseRenewalManager leaseMgr)
        throws IOException
    public JoinManager(Object obj, Entry[] attrSets, String[] groups,
                       LookupLocator[] locators,
                       ServiceIDListener callback,
                       LeaseRenewalManager leaseMgr )
        throws IOException

BallStarter.java

◆Lookup(クライアント側)

サービスは、次の３つで区別される。

ServiceID. 128ビット。ルックアップ・サービスが生成する。
インタフェース( Class オブジェクト )
属性。JavaSpaces の Entry クラスと同じ。

null を指定すれば、ワイルドカード。


    public ServiceTemplate(ServiceID serviceID,
                           Class[] serviceTypes,
                           Entry[] attrSetTemplates)

サービス(オブジェクト)の探し方

LookupLocator により、マルチキャスト、または、ユニキャストでルックアップ・サービスを探す。
ルックアップ・サービスのプロキシ ServiceRegistrar を作る。
テンプレートを作り、ServiceRegistrar に渡す。

サービスを見つける過程で、サービス(オブジェクト)のRMI のスタブ(クライアント側スタブ)が転送される。

Bat.java

◆Leasing

信頼性が低いネットワークと、どう戦う方法の１つ。

lease には、期限がある。

期限切れ時の処理

延長(通常)
終了

期限の長さは、交渉可能。期限が短い(1分以下、数秒)というのは、あまり想定されていない。

リースの利点

情報を最新のものにできる。
古い情報を安全に消すことができる。


public interface Lease {
    long FOREVER = Long.MAX_VALUE;
...
    long getExpiration();
    void renew(long duration)
        throws LeaseDeniedException, UnknownLeaseException, RemoteException;
    void cancel() throws UnknownLeaseException, RemoteException;
...
}

getExpiration() で、リースの残り時間がわかる。ミリ秒単位。

renew() で延長する。延長できない時には、LeaseDeniedException が変えされる。

もう使わなくなった時には、cancel() できる。期限切れと同じことになる。

◆セキュリティ

本当に、アクセス制御はなくてもいいのか。

■分散型プログラミング言語

プログラミング言語は、ネットワークの存在や通信をさまざまな度合いで隠している。

問題:

どこまで隠せば分散型プログラミング言語と呼んでもよいか？

「socket があれば、分散型プログラミング言語」とは、定義したくない。

◆分散型ＯＳとネットワークＯＳ

ネットワーク・オペレーティング・システム

ネットワークの機能はある。

利用者は、常にどの計算機を使っているのかを意識する必要がある。

コマンド

sh <-> rsh
cp <-> rcp
ls, less <-> WWW ブラウザ

システムコール

pipe <-> socket
/../host1/usr/local/bin (スーパールート)

分散型オペレーティング・システム

利用者は、仮想的な１台の計算機を使っているように感じ、計算機と計算機の境界線が見えなくなる。分散透明性（network transparency）が実現されている。

目標

負荷均衡(load balncing)。プログラムを走らせると、自動的に空いている計算機に送られ、実行される。
フォールト・トレランス。障害が発生したとしても、自動的に復旧させたり、自動的に他の計算機に仕事を回す。
集中型システムで開発されたプログラムを一切変更することなく、ネットワーク上の資源を利用することができるようになる。

現在の技術

NFS。ネットワーク・ファイル・システム。分散型ファイルシステムではない。
NIS。パスワード・ファイルの共有。

注意: 負荷分散の分散(load sharing/balancing)とこの講義のタイトルの分散 (distributed)は意味が違う。

◆Emerald

初期(1980年代)の分散型言語。オブジェクト指向。

Emerald の目標。

分散透明性。メソッド呼出しは、ローカルとリモートで同じ。
オブジェクトレベルの移動性。オブジェクトは、いくつねに、コンピュータの境界を越えて移動可能である。オブジェクトが自分自身を移動(migrate)させることがある。
効率。ローカル・オブジェクトへのアクセスは、(分散ではない言語と同じように)可能な限り直接的に効率よく行われる。ネットワーク通信なしにローカルの呼出しかリモートの呼出しかを決められる。

分散透明性と移動は、矛盾している。

◆Emeraldの参照

Emerald では、オブジェクトのアクセスは、参照(reference)を通じて行われる。参照は、ローカルもリモートも区別がない。 (分散透明性が実現されている)。

メソッド呼出しの引数も参照で渡される。オブジェクトの場所が違うと、重たい。コピーの方が速い。

◆Emeraldのオブジェクト・マイグレーション

Emerald には効率を挙げるために、オブジェクトを移動(migrate)させる機能がある。

move X to Y: オブジェクト X を、オブジェクト Y のあるホストに移動。ヒント。
fix X at Y: オブジェクト X を、オブジェクト Y のあるホストに移動して、さらに動かないように固定する。
unfix X: オブジェクト X を、再び移動可能にする。
refix X at Z: fix されているオブジェクト X を、オブジェクト Z のあるホストに移動して、さらに動かないように固定する。全体が atomic に行われる。

Call by reference が重たい。

call by move: 引数をオブジェクトの方に移動させる。
call by visit: メソッドがリターンすると、オブジェクトも戻ってくる。
call by move return: 結果のオブジェクトも戻ってくる。

移動の粒度が重要。オブジェクトのグループ化。 attached キーワードがついていると、いっしょに移動する。

◆ローカルとリモートの統合

RPC、ORB、コンポーネントと発展してきた。

分散の難しい問題は、解決されない。

例:

部分的に落ちている(partial failure)
レイテンシ。光の速度は越えられない
参照。ポインタを動するか
並行性
- 非決定性の扱い
- 同期の難しさ

◆RMI付Javaは、分散型プログラミング言語か

public しか呼べない。
オブジェクト・マイグレーションはない。
リモートのコンストラクタが呼べない。名前サービスを通じてアクセスする。factory object (オブジェクトを生成するオブジェクト)を使えばよいが、ローカルとリモートの透明性は下がっている。
非同期的な呼出しはできない。スレッドでエミュレート可能ではある。標準で並列性がまったく出ない。

◆分散型プログラミング言語の要件

位置と型の直行。
遠隔オブジェクト生成
ローカルとリモートを区別したい時には区別できる
ローカルとリモートを区別したくない時には区別しないでよい
Garbage colection
オブジェクト・マイグレーション
グループ化
同期呼出しと非同期呼出しの両方の支援
分散でも、並行性を言語で支援したい

分散の難しい問題は、まだ汎用的に解ける技術はない。汎用性がないと、プログラミング言語には採り入れにくい。

◆分散型プログラミング言語で分散システムが作れるか

分散ＯＳ上で分散システムが走るか。

↑[もどる] ←[2月14日] ・[2月21日]

Last updated: 2002/02/21 02:38:52

Yasushi Shinjo / <yas@is.tsukuba.ac.jp>