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

生活支援型インターネットを実現させる協調型システムアーキテクチャモデルの研究

杉浦 一徳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なオペレーティングシステム

ルータ ルータ

PC

Internet

PC

アプリケーションの動作

• コンピュータの持つ資源を利用– ハードディスク– メモリ– CPU– ディスプレイ– キーボード– マウス

次 :OS の役割

オペレーティングシステムの役割

• 資源の管理と提供• プロセス管理・スケジューリング• デバイス管理 ( 簡素化した入出力イン

ターフェースの提供 )

• イベントロギング ( ハンドリング )アプリケーション ( ユーザ ) に対して

抽象化、隠蔽

時代の変化とともに 利用形態

• 状況に応じて変化する環境– APM– PCMCIA カード– 1394– ネットワーク

APM

• APM で提供する機能– 電池の残量– APM によって管理されるデバイスの状態 (st

ate)• 動作速度• 動作状態

– 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 U

nawareness– アプリケーション開発にも支障が生じる．

アプリケーション開発環境から見た問題点

• アプリケーションを開発する視点– 開発者は :– 状況に対応したアプリケーションの作成が

したい．• 状況の変化に応じたライブラリの作成

– 電池残量に応じたアプリケーションの動作変化– ネットワークスループットに応じたデータストリー

ムの変更

状況 (State) をどのような形で抽象化するかが，問題 :状況の持つ多様性

本研究での解決策

• オペレーティングシステムとアプリケーションの協調機構を実現 (Application Aware Operating System)– デバイス，ネットワークの変化する状況を統

一的な手法でアプリケーションに通達– OS からの通達に応じた対応にアプリケーショ

ンは協力• 携帯型計算機の有効な資源利用• ネットワークの輻輳制御

OS からアプリへ状態変化の通達

状態変化の通達 (設計 )

• アプリケーションに対して• 変化した状態情報を提供・未来の状態を想定し提供

メッセージパッシング• メタな情報の提供方法としてメッセージパッシングを行

う．• 具体例 : シグナル

• 「状況変化」という事象のみの報告システムコールによる状態の取得

• getstate → メタ関数

アプリケーション、ユーザによる対応動作次 :全体の構成図

Application Aware OS

Device

TCP/IP

APM

Scheduler

State Handler

Application

Application

State Handler Daemon

State handling Library

メッセージパッシング

カーネル空間

ユーザー空間

次 :state handler の役割

State Handler

• オペレーティングシステムの持つ• 状況 (state)

• 資源

– をアプリケーションに統一した形でメッセージパッシングとして，通達する．

– デバイス，モジュールからの状況情報をメタデータベースとして保持する．

次 : メッセージパッシング

メッセージパッシング• State Handler からアプリケーションへ

の• メッセージパッシング

– Signal の利用．• 単一メッセージの報告 ( 状況変化 )

• アプリケーションは必要に応じて問い合わせ

State Handler

Application

ApplicationState Handler Daemon

State handling Library

次

:daemo

n

State Handler Daemon– カーネル空間の State Handler の持つ情報をアプ

リケーションに通達するためのデーモン– 「 state」の内容について統一的なアクセス方式を

デーモンから提供．– 柔軟性を確保

• state oriented Application Library の作成

State Handler

Application

ApplicationState Handler Daemon

State handling Library

State の抽象化

• ある程度，統一されたカテゴライズが必要– ネットワークの状態 :

• データストリームのバースト転送力• 平均データ転送能力• Congestion Notification(ECN)

• 電源の状態• ○○の状態

• 状態の種類の多様性の対処方法

状態の追加

• アプリケーションには統一されたメッセージパッシングのみが行われる．– アプリケーション側からは，

• メッセージパッシングを無視• メッセージの詳細を State handler daemon に聞く

– 状態の追加に対するアプリケーションの対応は不変

応用例 1:　 APM

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

応用例 2: インターネットによる

DV映像の送信

Internet

IEEE1394

IEEE1394

IPIP

状況に応じたデータストリームの処理機能の実現

FrameVideo data in frameaudio data in frame

• Full rate digital video stream

• Half rate digital video stream

• 1/3 rate digital video stream

DV Packet with Audio

DV Packet without Audio

次 : アプリケーション開発の例

アプリケーション開発の例 :

• 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 I

nouye NOSSDAV 97)• System Support for Mobility(John Inouye ACM SIGOPS 9

6)

• Network and Application Oriented• Network Support for Application Oriented OS( Peter Steenk

iste(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-Ma

ch Workshop)

• Abstract of demand based Operating Systems

• 携帯型計算機の有効な資源利用 ( 情報処理学会 コンピュータシステムシンポジウム )

• DV Over IP• Design and Implementation of DV Stream over Inte

rnet (IWS)

研究プロセス

• IEEE Mascots(5/1)• Transferring DV Stream Over Internet Using Applic

ation Aware Operating Systems

• ACM MultiMedia• Design of Universal Translation Gateway

おしまい