後期博士課程セミナー発表

後期博士課程セミナー発表 生活支援型インターネットを実現させる協調型システムアーキテクチャモデルの研究杉浦一徳 uhyo@mag.keio.ac.jp 1999年03月10日本研究の目的

本研究の目的 • オペレーティングシステムとアプリケーションの協調動作 • Application Aware なオペレーティングシステムの実現 • デバイス、ネットワークの状態情報を抽象化 • APM：HDD、CPUやPCMCIAと電源管理に関する情報 • ネットワーク：輻輳、遅延や切断などの状態に関する情報 • 統一的な手法でアプリケーション、ユーザに提供 • ネットワーク及び，計算機環境の動的な変化に対してアプリケーションおよびユーザが適応処理を行う

発表内容 • 現在のインターネットアーキテクチャ • オペレーティングシステムの役割とアプリケーション • Application Awarenessという視点から見た現在のアーキテクチャの問題点 • Application Aware Operating Systemの開発次:App aware な OS

Application Awareなオペレーティングシステム Internet ルータルータ PC PC

アプリケーションの動作 • コンピュータの持つ資源を利用 • ハードディスク • メモリ • CPU • ディスプレイ • キーボード • マウス次:OSの役割

オペレーティングシステムの役割 • 資源の管理と提供 • プロセス管理・スケジューリング • デバイス管理(簡素化した入出力インターフェースの提供) • イベントロギング(ハンドリング) • アプリケーション(ユーザ)に対して抽象化、隠蔽

時代の変化とともに利用形態 • 状況に応じて変化する環境 • APM • PCMCIA カード • 1394 • ネットワーク

APM • APMで提供する機能 • 電池の残量 • APMによって管理されるデバイスの状態(state) • 動作速度 • 動作状態 • ON • Power Managed • Low Power • Off

PCMCIA • PCMCIAで提供する機能 • PCMCIAデバイスの種類(ネットワークなのか，ストレージなのか．．．) • デバイスのIoport IRQ • device state

IEEE1394 • 高速シルアルインターフェース • Isochronous 転送のサポート • 抜き差しに動的に適応する • Bus Reset メカニズム • IEEE1394を用いたホームネットワーク • HAVi • HWW

ネットワーク・インターネット • Best effort 型のネットワーク • アプリケーションにとっては，ネットワークに転送する情報は宅急便… • どのように扱われるかは，分からない • アプリケーションとの協調を前提としたい新しいプロトコル体系 • RED RED+ECN • RTP + RTSP

これらの共通する点: • 動作状態が絶えず変化する． • 状態の変化 • ネットワークの輻輳 • 節電機能による処理変化 • 動作できない状況になりうる． • ネットワークの切断 • 動作する必要のない時がある． • 利用する環境の状態を知る必要性 • デバイス，ネットワークから見ると，ユーザ(アプリケーション)からの対応が必要になってきた．

これらの必要性に対する現状の問題点 • ユーザ(アプリケーション)からカーネル内部の状態情報の取得が困難 • シグナリング • 取得できる情報は限定されている • ポーリング • 動的な状態取得ができない • ユーザの積極的な対処 • OSのApplication Unawareness 結果として

シグナリング • OSからユーザにシステムイベント情報を通達する機能 • オペレーティングシステムが機能する上でのアプリケーション側が行った違反の通達 • アプリケーションの停止，再会，中断，終了

ポーリング • 一定期間毎の情報収集 • kmemから得られる情報のポーリング • レジストリから得られる情報のポーリング • 統一されたインターフェースが提供できない • 変化の動的な検知は不可能． • イベントハンドリングではない．結局，効率的な方法は，ユーザの認識

ユーザの積極的な確認手法 • user-aware なインターフェース • ユーザが状態の変化を認識し，その管理を行う • 状況を判断する能力が問われる． • 状況を常に認識できれば，問題はない…

現在のオペレーティングシステムの問題点 • Application Unawareness • ユーザ(アプリケーション)はOSの管理する資源の状態情報を利用できない • 計算機環境の状態変化に適応したアプリケーションサービスの提供ができない • Application Unawareness = Programmer Unawareness • アプリケーション開発にも支障が生じる．

アプリケーション開発環境から見た問題点 • アプリケーションを開発する視点 • 開発者は: • 状況に対応したアプリケーションの作成がしたい． • 状況の変化に応じたライブラリの作成 • 電池残量に応じたアプリケーションの動作変化 • ネットワークスループットに応じたデータストリームの変更状況(State)をどのような形で抽象化するかが，問題: 状況の持つ多様性

本研究での解決策 • オペレーティングシステムとアプリケーションの協調機構を実現(Application Aware Operating System) • デバイス，ネットワークの変化する状況を統一的な手法でアプリケーションに通達 • OSからの通達に応じた対応にアプリケーションは協力 • 携帯型計算機の有効な資源利用 • ネットワークの輻輳制御 OSからアプリへ状態変化の通達

状態変化の通達(設計) • アプリケーションに対して • 変化した状態情報を提供・未来の状態を想定し提供 • メッセージパッシング • メタな情報の提供方法としてメッセージパッシングを行う． • 具体例: シグナル • 「状況変化」という事象のみの報告 • システムコールによる状態の取得 • getstate → メタ関数 • アプリケーション、ユーザによる対応動作次:全体の構成図

Application Aware OS State handling Library State Handler Daemon Application Application ユーザー空間メッセージパッシングカーネル空間 State Handler Scheduler TCP/IP APM Device 次:state handlerの役割

State Handler • オペレーティングシステムの持つ • 状況(state) • 資源 • をアプリケーションに統一した形でメッセージパッシングとして，通達する． • デバイス，モジュールからの状況情報をメタデータベースとして保持する．次:メッセージパッシング

メッセージパッシング • State Handlerからアプリケーションへの • メッセージパッシング • Signalの利用． • 単一メッセージの報告(状況変化) • アプリケーションは必要に応じて問い合わせ State handling Library State Handler Daemon Application Application State Handler 次:daemon

State Handler Daemon • カーネル空間のState Handlerの持つ情報をアプリケーションに通達するためのデーモン • 「state」の内容について統一的なアクセス方式をデーモンから提供． • 柔軟性を確保 • state oriented Application Libraryの作成 State handling Library State Handler Daemon Application Application State Handler

Stateの抽象化 • ある程度，統一されたカテゴライズが必要 • ネットワークの状態: • データストリームのバースト転送力 • 平均データ転送能力 • Congestion Notification(ECN) • 電源の状態 • ○○の状態 • 状態の種類の多様性の対処方法

状態の追加 • アプリケーションには統一されたメッセージパッシングのみが行われる． • アプリケーション側からは， • メッセージパッシングを無視 • メッセージの詳細をState handler daemonに聞く • 状態の追加に対するアプリケーションの対応は不変

応用例1:APM • 変化する事象: APM のSMI(System Management Interrupt)の制御節電機能によるシステムの動作変化電力消費によって抽象化したアーキテクチャの開発バッテリー容量を把握

応用例2:インターネットによるDV映像の送信 IEEE1394 IEEE1394 Internet IP IP

Frame Video data in frame audio data in frame DV Packet with Audio DV Packet without Audio 状況に応じたデータストリームの処理機能の実現 • Full rate digital video stream • Half rate digital video stream • 1/3 rate digital video stream 次:アプリケーション開発の例

アプリケーション開発の例: • APM: • 電池容量警告シグナルのためのライブラリー開発 • 通常モードとGreenモード • ネットワーク: • ECN検知によるデータストリームの容量変更

応用例②　ホームネットワーク • インターフェース技術 • USB(Universal Serial Bus), IEEE1394 • HomePNA(Phoneline networking Appliance) • CDMA(無線LAN) = HomeRF • AC-LAN = PLANET • インターネットチップ • iReady Internet Tuner Chip • ホームネットワーク • HAPI(Home API) • HAVi(Home A/V Interoperability)

ホームネットワーク機器から取得できる状態情報ホームネットワーク機器から取得できる状態情報 • 何がつながるのかは未知数提供される情報としては，デバイスタイプデータストリームのパケット数(量) 次:関連研究

関連研究 • APMの応用，Application awareness • Scheduling for Reduced CPU Energy(USENIX) • Application-Aware Adaptation for Mobil Computing(ACM) • Application aware Operating System • System Support for Mobile Multimedia Applications(John Inouye NOSSDAV 97) • System Support for Mobility(John Inouye ACM SIGOPS 96) • Network and Application Oriented • Network Support for Application Oriented OS( Peter Steenkiste(ICNP 98)

本研究の特徴 • 本研究の着目点 • Application Awareness • アプリケーションが利用するネットワーク，資源に対して: • アプリケーションが能動的になるべき • もっとアプリケーション側から制御するべき • メッセージパッシングの方法 • 統一的な方法で状況をアプリケーションに伝える

本研究の評価方針 • state driven と，従来の方式による • ネットワークの効率的な利用 • 電力の効率的な利用 • Object Oriented OS・Module OSとの比較 • Apertos • Inferno • RTMach with QoS Server • オーバーヘッド • massive alert(signal)の対応 • Race Condition(Alert loop)

Massive Alert • 状態変化の粒度． • 状態の抽象度のレベル • 細かくしすぎると，常に状態の報告を行うようになる． • オーバーヘッドとの兼ね合い • State の抽象度 • アプリケーション開発における視点 • alertを積極的に受け入れるか • 徹底的に無視するか

現在までの研究 • APMとオペレーティングシステム • Power Management for Portable Computers(RT-Mach Workshop) • Abstract of demand based Operating Systems • 携帯型計算機の有効な資源利用(情報処理学会コンピュータシステムシンポジウム) • DV Over IP • Design and Implementation of DV Stream over Internet (IWS)

研究プロセス • IEEE Mascots(5/1) • Transferring DV Stream Over Internet Using Application Aware Operating Systems • ACM MultiMedia • Design of Universal Translation Gateway

おしまい

後期博士課程 セミナー発表