180 likes | 339 Views
DKLIC: 宣言型広域分散環境. 早稲田大学大学院理工学研究科 上田研究室 高木祐介 高山啓 松村量. 提案の背景と目的. 手続き型言語を拡張した従来の分散型言語処理系や分散ミドルウェアは、 ホスト間通信に本質的でない順序付け・同期の記述が必要である。 並行論理型言語 KL1 は、 論理変数を利用して、複雑なプロセス間通信を宣言的に記述することができる。 データフローによる自動的・宣言型の同期。. 宣言型 vs 手続き型の記述. 変数 vs load/store イベントモデル vs read/write 分散論理変数 vs send/receive
E N D
DKLIC: 宣言型広域分散環境 早稲田大学大学院理工学研究科 上田研究室 高木祐介 高山啓 松村量
提案の背景と目的 • 手続き型言語を拡張した従来の分散型言語処理系や分散ミドルウェアは、 • ホスト間通信に本質的でない順序付け・同期の記述が必要である。 • 並行論理型言語KL1は、 • 論理変数を利用して、複雑なプロセス間通信を宣言的に記述することができる。 • データフローによる自動的・宣言型の同期。
宣言型 vs 手続き型の記述 • 変数 vs load/store • イベントモデル vs read/write • 分散論理変数 vs send/receive • S = [request1(Answer1), request2(Answer2), …] • Answer1 と Answer2 の受信順序や同期は捨象されている。
並列処理 • 1つの計算機上に存在する複数プロセスが、通信を行いながら並行に実行が進む。 プロセス プロセス プロセス プロセス
分散処理 • ネットワークで接続された複数の計算機上に存在する複数のプロセスが通信を行いながら並行に実行が進む。 プロセス プロセス プロセス プロセス
既存のKL1言語処理系との比較 • KLIC処理系 http://www.klic.org/ • SMP等の並列機上での処理 • 広域分散機能はソケットのみ(手続き型) • DKLIC処理系 = KLIC + API (Runtime) • 単純な広域分散KL1言語処理系 • KL1によるKLICの拡張 • 実行時ライブラリ(ミドルウェア)
DKLICの目標 • ネットワーク透過なプロセス間通信 • クライアント/サーバ型の接続 Host1 Host2 KLIC Runtime KLIC Runtime socket DKLIC Runtime DKLIC Runtime request request Stream client server
DKLICのシステム構成 Runtime Library User Program 実装環境: KLIC-3.003 Solaris 2.6, Linux 2.2 Runtime Systemのサイズ: ソースプログラム:約2000行 KL1 KLIC Compilerによりコンパイル Runtime System Runtime Library User Program C gccによりコンパイル Runtime System Runtime Library User Program binary OS / Machine
DKLIC Runtimeの内訳 • 基本サーバ dklic: ソケットを隠蔽する • dispatch: ポートを隠蔽する • naming: ホストを隠蔽する • exec: コード移送・実行 • sandbox: 故障検出
基本サーバdklicの構造 サーバホスト クライアントホスト クライアントプロセス サーバプロセス クライアントプロセス 入力管理 出力管理 入力管理 キー管理 変数管理 変数管理 キー管理 キー管理 変数管理 出力管理 入力管理 出力管理
基本サーバdklicの変数管理 • 変数表 • ノード間の共有変数の管理 • 変数は(ID、変数の値)の組として管理 =エントリー • GCのために、不必要なエントリーの削除 • 変数の自動通信により、ネットワーク透過な実行を実現 • IDの発行 • 相手ノードとIDが衝突することを避ける • IDの名前空間を分離 • 不必要になったIDの再利用 • エントリーを受け取った側で、そのエントリーのIDを再利用)
現試作の変数管理の問題点 • KLICの制限 • 未定義変数の同一性を検査出来ない • 変数の参照数を感知出来ない • このため、第三者による中継を排除出来ない • generic object機構(C言語によるKLICの拡張)を用いて未定義変数の同一性検査を実装 • 静的解析の導入により、中継ノードに参照が残らないことを保証
ネームサービスの必要性 • 遠隔ノードの具体的な名前や場所をプログラム中には記述したくない • 経路断絶、ホスト停止、サービス停止などの度にプログラムの書き換えるのは効率が悪い • プログラム中ではサービス名の記述にとどめ、そのサービスを提供するサーバへのストリームを獲得する形式にしたい remote( ChatServerStream, ”chat”)
ネームサービスの構成 Chat Client ChatServer “hostA” Answer (“Stream to hostA”) Register ( “ChatService”, “hostA”) Lookup (“ChatService”) Name Server Answer (“Stream to hostA”) Name Server Answer (“No Server”) Lookup (“ChatService”) Lookup (“ChatService”) Name Server Server Server Server Server
ネームサービスの機能 • ServiceServerは提供できるServiceと自分の場所(address, port, etc.)をNameServerに登録(register)する • NameServerがServiceClientからServiceについて照会(lookup)されるとそのServiceを提供可能なServiceServerを教える(Answer) • Lookup内容に対応するServiceServerがNameServerに登録されていない場合は全ての隣のNameServerへ同内容のLookupを送る • Lookupの転送回数には上限値を設ける • IPにおけるホップ値に似ている
NameServerの構造 NameServer FTPServer “hostC” Lookup Name Server Request Lookup Connector Accepter Lookup Chat Client Answer Name Server Answer Answer Lookup TableController Register Answer ChatServer “hostA”
開発体制 • DKLIC開発チームは提案者3名より成る。 • KL1の研究は他の言語班に任せ、DKLIC開発チームは開発に専念する。 • 途中の成果を積極的に公開する(利用・配布条件はKLICに準じてオープンソース)。
参考文献 • http://www.ueda.info.waseda.ac.jp/~takagi/ • http://www.klic.org/ • 高木祐介, dklic: KL1による分散KL1言語処理系の実装. In Proc. JSSST Workshop on Systems for Programming and Applications (SPA2001), 2001.