2 Ruby/TkORCA とは 2005 年度下期未踏ソフトウェア創造事業 ネット公開を目的としたマルチウィンドウアプリ用フレームワーク での開発物 正式名称 Ruby/Tk On Remote-Frame-Buffered Canvas ( Ruby/Tk On RFB Canvas ) 通称

Transcription

1 1 ネット公開マルチウィンドウ GUI アプリ用フレームワーク Ruby/TkORCA におけるウィジェット操作権限の分離手法 九州工業大学情報工学部知能情報工学科 永井秀利 2006/09/02

2 2 Ruby/TkORCA とは 2005 年度下期未踏ソフトウェア創造事業 ネット公開を目的としたマルチウィンドウアプリ用フレームワーク での開発物 正式名称 Ruby/Tk On Remote-Frame-Buffered Canvas ( Ruby/Tk On RFB Canvas ) 通称 ( 略称 ) Ruby/TkORCA ルビー ティーケー オルカ 開発目的ローカルのウィンドウシステム上に限られていた GUI プログラミング技術の対象領域を, 広くネットワーク GUI アプリにまで拡張する コンセプト ローカルからネットまで お気軽に GUI プログラミングを楽しめるようにしたい どこでも GUI! ( GUI, Anywhere! )

3 3 現状でのネット GUI アプリ作成時の問題点 基本傾向として, 能力が高い枠組ほど制約も厳しく, 想定範囲を越えようとすると実現が非常に困難だったり不可能だったりが多い Flash 等の独自フレームワーク 開発者に特有の技量を要求 インストールされたクライアント用プログラムのバージョンに依存するため, 適用可能範囲が狭く, 発展や機能改良も鈍重 Ajax ( Asynchronous JavaScript + XML ) サーバ / クライアントの連携やクライアントの差異への配慮が面倒 機能向上に対し, 開発コストや情報漏洩リスク等が急激に増大 VNC ( Virtual Network Computing ) 接続を許可した相手を信用し過ぎており, 監視や制御ができない 不特定多数をサービス対象とする仕組みが欠落している X window system (X protocol) 初期化が非常に重く,LAN クラスの速度でなければ起動を待ち切れない アプリケーションサービス側からの攻撃には脆弱

4 4 Ruby/TkORCA の思想 VNC の利点を活かしつつ, その問題点を回避した枠組とする 高度なインタラクティブ性や, プログラムやデータをクライアントに送らないことによる低い情報漏洩リスクなどの利点はそのままに享受 問題の源になる一般的ウィンドウマネージャは動かさず, 相当機能の実装によりウィンドウ操作も監視や制御の対象とする 不特定多数の他者へのサービス提供に利用できるものとする 開発者に対して, 特有で特殊な技量を要求しない ローカル用とネット用とでソース変更をほとんど必要としない 監視や制御の機構をあらかじめ組み込んでいなくても, アプリケーションの監視や制御を可能に ( 改良 強化も容易に ) する 援用する他のソフトには一切手を加えない 導入コスト低減や, 他ソフトの強化 改良からの最大限の受益のため 広く使われているものに 似て異なるもの を開発する愚は避ける

5 5 Ruby/TkORCA の構造 アプリケーションサービス Ruby/TkORCA プロセス family mother 用設定 mother daughter 用設定 オプション 監視 制御 監視 制御生成 停止 daughter sandbox load application ログ出力 処理代行変換 操作 + daughter load application 監視付ウィンドウマネージャ相当機能 access HOME ディレクトリ ( 固定または一時生成 ) 描画 イベント xauth ファイル RFB 通信 VNCserver (Xvnc) プロセス

6 6 Ruby/TkORCA サーバの構成概略図 Pod 監視 制御 ログ出力 ログファイル 接続要求 サービスデーモン (1) ランダム名で生成 xauth ファイル 不正利用回避のためディレクトリエントリは参照不可に設定 (3) ランダム名で生成 監視 制御 ログ出力 参照 参照 HOME ディレクトリ 複数サービスの同時提供 (2) fork アプリケーションサービス (4) fork 参照 実行環境設定ファイル RFB 通信 VNCserver プロセス 描画 Ruby/TkORCA プロセス daughter daughter mother 用スクリプト daughter 用スクリプト 複数アプリの同時実行 Application Application

7 7 なぜ Ruby/Tk なのか 手軽に使える GUI ツールキットの一つ 多くの OS で使える高いポータビリティ 手軽に GUI を作れる Tcl/Tk にオブジェクト指向の殻を被せてさらに手軽に ウィジェットパス名に悩まされない, 新しいウィジェットクラスの作成も容易に, 等 ウィジェットは Tcl/Tk インタープリタに依存して存在 デフォルトの IP は, ライブラリのロード時に自動生成して定数に保持 ウィジェットオブジェクトは依存する IP の情報を持たない オブジェクトを入手しただけでは操作できず,IP の操作権獲得も必須 スレーブ Tk インタープリタの生成が可能 マスターからスレーブを操作することはできるが, 逆は不可 手軽さ + mother/daughter を実装できる素地 を持つ

8 8 問題点 (1) ウィジェットのコンストラクタやインスタンスメソッドには,Tk インタープリタを指定する引数がない スクリプトのコンテキストに基づいて, 対象となる Tk インタープリタを自動選択する必要がある context A ( for IP1) IP1 上に生成されたボタンウィジェット TkButton.new ( ボタンウィジェットの生成 ) context B ( for IP2) IP2 上に生成されたボタンウィジェット

9 9 問題点 (2) 同じ手続きオブジェクトを異なるコンテキストで評価できる必要がある ( 例えばコールバック処理などでの手続き流用 ) 手続きオブジェクトの生成時に固定してしまうようなことはできず, 動的に定める必要がある context A ( for IP1) x.call(...) context A での評価 ( IP1 を使用 ) context B ( for IP2) 手続きオブジェクト x x.call(...) context B での評価 ( IP2 を使用 )

10 10 問題点 (3) スクリプトにおいて, デフォルトの Tk インタープリタを保持する定数を直接参照してメソッド呼び出しを行うことがある スレッドの存在に注意が必要 処理中のスレッド切替えを考えると, 選択すべき Tk インタープリタの情報はスレッド固有である必要がある 新しいスレッドが生成される際, 自動的に確実に Tk インタープリタの情報を新しいスレッドの固有情報として引き継げる保証がない 1 2 context (IP) の情報はどこに保持すべきか? 生成 3

11 11 スレッドグループの活用 Ruby のスレッドグループを活用 スレッドグループの enclosed という状態を活用 以前に提案し, 導入してもらったもの 新たなスレッドを生成することはできるが, スレッドを別のスレッドグループに移したり, 別のスレッドグループからスレッドを追加したりすることができないという状態 コンテキストはカレントスレッドが属するスレッドグループによって規定 新たなスレッドを生成してもコンテキストの維持が保証できる Group Group Group OK NG NG OK NG NG OK New OK New NG New Group Group Group normal 不可逆 enclosed 不可逆 frozen

12 12 MultiTkIp クラス MultiTkIp クラス スレッドグループとそれに対応付けた Tk インタープリタとで構築 クラスメソッド呼び出しは現コンテキストの IP のメソッド呼び出しとなる IP が現コンテキストの IP か, その直接のスレーブである場合にのみメソッド呼び出しが許可される 命令は, 手続きオブジェクト化して評価 queue に投入される 評価 queue でシリアライズされた命令を評価スレッドで順に評価し, 必要なら結果を返す ( 値の返却には例外生起を活用 ) 手続き 評価スレッド watchdog スレッド Group Tk インタープリタ

13 13 ウィジェット集合の封じ込め MultiTkIp オブジェクトを中心として daughter (sandbox) を構築 daughterごとのウィジェット集合の封じ込めを実現 包み込むことでMultiTkIpオブジェクトへのアクセスを制約 Tcl/Tkコマンドやメソッドのwrapによる監視と処理依頼の実装 手続き 評価スレッド wrapper watchdog スレッド Group Tk インタープリタ wrapper マスターインタープリタ mother 上での評価

14 14 ウィンドウマネージャ機能の構築 ウィジェット集合を封じ込めただけではダメ ウィンドウマネージャが存在しないため, ウィンドウ操作不能 daughter toplevel Xvnc のフレームバッファ mother に属するマスター Tk インタープリタのキャンバスウィジェット上にウィンドウマネージャ機能を構築 マスター IP のコンテナにスレーブ IP のトップレベルウィジェットを埋め込む daughter toplevel frame container window item motherのcanvasウィジェット Xvnc のフレームバッファ

15 15 Tcl/Tk コマンドの wrap 一般的なウィンドウマネージャは稼働していない daughter 上でのウィンドウマネージャ関係コマンドは, ほぼすべてが機能しない motherのウィンドウマネージャ機能を呼び出す必要あり daughter の Tk インタープリタ上のウィンドウマネージャに係わるコマンドのすべてを wrap する daughter の IP はスレーブインタープリタであるので, マスターインタープリタである mother の IP による支配的操作が可能 toplevel, wm, winfo, grab 等のコマンドを wrap ( mother への処理依頼や情報問い合わせ ) daughter からは, 普通にコマンドを実行しているだけに見える ウィンドウ操作がすべて mother の処理を経由する ウィンドウ操作のすべてを mother の監視 制御の下に置ける daughter 上の GUI アプリの全体 ( アプリ内部から UI まで ) をきめ細やかに監視 制御することも可能

16 16 例 :toplevel コマンドの wrap Ruby/Tk スクリプト daughter mother : : toplevel 生成 toplevel コマンドの wrapper の起動 処理依頼 処理の正当性の検査 : : ERROR invali d 例外 ( エラー ) の発行 valid 隠蔽 本来の toplevel コマンド 隠蔽されたコマンドの発行 daughter は, 普通に toplevel コマンドを実行しているつもり fail ERROR succeed toplevel window の獲得 埋め込み window frame の生成 ERROR!! toplevel ウィジェットのオブジェクト mother 上の疑似ウィンドウマネージャ機能の監視下に

17 17 デモンストレーション C 言語で作られた外部ライブラリを使用し, コンソール出力もするようなアプリケーション OpenGL (Mesa) を用いているアプリケーション 複数アプリケーションの同時サービス 5 分で作るネットワーク GUI アプリ などから, 時間が許す範囲で

18 18 まとめ ネットワーク GUI アプリ用フレームワーク Ruby/TkORCA において, 一つのプロセス上で, ウィジェット集合の操作権限を分離しつつ, アプリケーション実行環境とウィンドウマネージャ機能とを実装するために用いた方法を示した Ruby/TkORCA を用いれば, 小物の GUI ツールを手間をかけずにリモートアプリ化したり, 特殊なライブラリや機密情報を一切見せることなく外部公開したりといったことも簡単にできる 具体的な性能数値計測が優先課題 操作による画面更新がなければ通信量はわずかなので, 接続のみなら最大の 99 クライアント (Xvnc の仕様による制限 ) でも十分に対応可能 一般の VNC サーバは通信帯域制限の機構を持たないため, 高レートのアニメーションなどで画面更新が非常に頻繁なものを最高クラスの品質で無条件に提供すると, 数クライアントでも通信帯域を使い切ってしまう場合がある ( 大規模サービスでは通信帯域制限が必須 ) サービスの品質と (OS による ) 通信帯域制限との組み合わせに対し, どの程度の数のクライアントの実用に耐えうるかの計測が必要