Comments
Description
Transcript
修士論文 Web上でリアルタイムコンテンツサービス を実現するプッシュ型
修士論文 上でリアルタイムコンテンツサービス を実現するプッシュ型イベント配信機構の研究 田中 久夫 年 月 日 奈良先端科学技術大学院大学 情報科学研究科 情報システム学専攻 本論文は奈良先端科学技術大学院大学情報科学研究科に 修士 工学 授与の要件として提出した修士論文である。 田中 久夫 審査委員： 山本 平一 教授 （主指導教員） 砂原 秀樹 教授 （副指導教員） 岡田 実 助教授 （委員） 上でリアルタイムコンテンツサービス を実現するプッシュ型イベント配信機構の研究£ 田中 久夫 内容梗概 デジタル放送開始に伴って提供されているサービスとしてデータ放送がある． データ放送サービスのうち，特に，番組と連動してリアルタイムに番組関連情報 を提供できる番組連動型サービスは，テレビの本番組をより魅力的にできるもの として期待されている．しかし，高いコンテンツ作成コストのため，提供コンテ ンツがかなり限定されていることから，魅力的なサービスが提供されてないのが 現状である． 本研究では，このような番組連動型情報サービスをインターネット上で提供す る，サービスシステムのフレームワークの構築を目標とする．特に，多数のユー ザに対する同報性の高いサービスを提供する際のスケーラビリティやコンテンツ 同期の問題に焦点を当てたプッシュ型情報配信機構の提案をし，実装を行う．マ イクロベンチマークプログラムを用いて提案システムの評価実験を行い，現実の サービスを提供する際に要求される高いスケーラビリティ，そして，動的にイベ ントが発生したり，高いリアルタイム性を有する生放送番組にも対応できること を検証し，リアルタイムな イベント配信を実現する本提案配信機構の有効 性について示す． キーワード プッシュ，同報性，スケーラビリティ，通信放送融合，ウェブ，リアルタイムコ ンテンツサービス 奈良先端科学技術大学院大学 情報科学研究科 情報システム学専攻 修士論文 年 月 日 £ ! "## $ # % &' ()* *#+ "# % ), ), & " * $ $, % ), , ,- # % ), , .*' /" ! # ## )& $ # & # $" ), ) &*' # $ # # , $,"- # ! "## *#+ "# % ), "# " ' # # ! ) )&# * ,#, # ,- # " " * "# #& ) " ' # &*! $& # * , $ # ,), $ # * ,#,' # )$, , " 0, * ,#,- 0),' ! # ))* $ # ,#, " * $ % ), &# ,! )! " ),' ## !" #$ " ## ! #$% &'" )&#! ,&& ! *! ,,& ! "! , 目次 第 第 章 ' ' '' '' 章 本論文の構成 同報型コンテンツ配信技術 本研究の背景 本研究の目的と意義 既存関連技術のまとめと本研究の位置づけ 2 番組連動型情報サービスシステム ' ' プッシュ型通信における関連技術 '' マルチキャスト技術 '' 第 序論 章 ' ' '' '' '' ' ' 1 ' ' 1（ )) 1） '' 1 マルチキャスト '' アプリケーションレベルマルチキャスト サービス概要 サービス利点 技術課題 '' '' '' '' '' 低コストなコンテンツ生成 スケーラブルでかつリアルタイム性の高い同報型配信 同期したサービス要求 クライアントの初回接続への対応 本研究のアプローチと焦点 サービスシステム概要 3 3 '' '' '' '' 第 章 ' ' '' '' 第 第 章 ' ' '' '' '' 章 ' ' '' '' 放送番組の特徴 プッシュ型配信（制御サーバ） プル型配信（コンテンツサーバ 4 クライアント） リアルタイム性の要求分析 提案サービスシステム設計 コンテンツダウンロードの時間的分散 3 3 提案サービスシステム実装 システムの参照モデル ' ' ' ' 制御サーバ クライアント プッシュ型配信系設計 '' '' 表示制御情報のデータフォーマット 表示制御情報の管理 実装概要 制御サーバ クライアント ベンチマークプログラム '' '' '' '' 入出力モデル ノンブロッキング 時間の記録 現実ネットワーク環境のエミュレート 提案サービスシステムの評価 実験の概要 ベンチマーク実験環境 評価実験 '' '' '' 性能評価尺度 パラメータ測定 実験方法 2 2 '' '' '' 第 第 章 ' ' '' '' '' 章 2 実験結果 考察 評価実験のまとめ 今後の課題 サービス実用化に向けたサービスシステムの構築及び実証実験 2 2 結論 低コストな番組連動コンテンツ作成管理フレームワークの検討 システム全体の高いスケーラビリティの確保 コンテンツの暗号化 謝辞 参考文献 図目次 ' 1 プッシュアーキテクチャ ' 1 マルチキャスト ' アプリケーションレベルマルチキャスト ' ' ' ' ' ' ' ' ' ' '2 ' ' ' ' ' ' ' 番組連動型情報サービスの概略 提案システムの概略 コンテンツセット構造 制御サーバの参照モデル クライアントの参照モデル 録画放送の場合のデータ構造 生放送の場合のデータ構造 緊急放送の場合のデータ構造 コンテンツセットの構造例 コンテンツダウンロードの時間的分散 録画放送のダウンロード手法 3 3 制御サーバの実装詳細 クライアントの実装詳細 ベンチマーク実験環境 サービス遅延時間の定義 アプリケーションレベルでのサービス遅延時間 )56 アプリケーションレベルでのサービス遅延時間 )5' 6 アプリケーションレベルでのサービス遅延時間 )5 6 3 ' ' '2 '3 ' ' 各グループの遅延時間分布 各グループの遅延時間分布 サーバにおけるソケット " 時間 プッシュ配信時のピークスループット プッシュ配信時の 718 とメモリの使用率 予測される全体のサービス遅延時間分布 表目次 ' ' ' ' ' ' 代表的なテレビ放送番組の特徴 リアルタイム性の高いデータと低いデータ 計算機環境 評価実験の測定条件 評価実験の測定条件 カーネルパラメータチューニング 0 2 第 章 序論 本研究の背景 年 月 日，9 デジタル放送が始まった．また， 年には 7 デジタ ル放送， 年 月に 大首都圏に地上デジタル放送が開始された．従来のア ナログ放送に比べ，デジタル放送の大きな特徴は多チャネルハイビジョン放送と 高機能である．高画質，高品質な番組視聴はもちろんのこと，双方向サービスに よる視聴者が放送番組に参加することやマルチメディアサービスであるデータ放 送による情報の取得が可能になった．データ放送サービスでは，文字，図形，静 止画，映像，音声などの個々の表現メディアを組み合わせて情報を構成して放送 する．視聴者はリモコン操作などによって対話的に情報を選ぶなどして，欲しい 情報を得ることができる．たとえば，最新ニュースのダイジェスト，天気予報を チェックしたりすることができる．特に，本放送番組と連動してリアルタイムに 番組関連情報を提供できる番組連動型サービスは，テレビの本番組をより魅力的 にできるものとして期待されている．たとえば，テレビドラマであれば，役者の プロフィール情報，身に付けている衣装やアクセサリなどの関連情報などを視聴 者に表示したり，サッカーなどのスポーツ中継番組であれば，チームやプレーヤ の関連情報，試合の対戦結果などの有用な情報をスポーツファンにリアルタイム に提供したりすることで，本放送番組をより充実させ，メディアとしての娯楽性， 広告効果を最大限に伸ばすことができると考えられる． 一方，:! ;/ に代表される高速な常時接続サービスが急速に普及して きており，これらのブロードバンド加入者数（平成 年 3 月末時点）が 万契 約を超え，アクセス速度が最大 )∼ <) にも達している = >．また，屋 内に限らず，屋外では携帯電話や 1 といったモバイル機器の通信速度も劇的 に向上していることから， 「いつでも，どこでも」高速にネットワークへアクセス できる環境が整えつつある．また，テレビを視聴できるいわゆる「テレパソ」17 が広く普及し，そして， 年 月に携帯端末向けデジタル放送が開始され，さ らには ブラウザを搭載したテレビなども登場してきていることから，今後 はテレビを視聴しながらインターネットを利用するといった生活スタイルがさら に浸透していくと考えられる． このように，技術革新によって放送と通信の垣根が無くなってきており，今後 は双方の利点を生かした放送通信融合サービスが大きく成長するものとして期待 されている．その一つの例としては，冒頭で説明したデジタル放送の双方向サー ビスによる視聴者の番組参加が挙げられる．しかし，デジタル放送でもう一つ期 待されているサービスであるデータ放送は，ごく限られた番組でしか提供されて いないのが現状である．これには，さまざまな問題点があり，一番大きな問題は 高い制作コストのため少量のコンテンツしか提供できていないことが挙げられる． 本研究では，より魅力的で柔軟な番組連動型情報サービスをインターネット上で 提供する，サービスシステムのフレームワークの構築を目標とする． 本研究の目的と意義 番組連動型サービスのようなリアルタイム性及び同報性の高い通信は，イン ターネットが本質的に苦手としている分野である．本提案サービスの利用者数は， 番組視聴率によって数万から場合によっては 万もの規模のサービスユーザが 存在することがあり得る．そのため，単純に 上でこうした情報サービスを 実現することは，現実的には非常に難しい． 現在，インターネット上で同報型通信を実現する技術として，マルチキャスト 技術に期待が寄せられている．マルチキャストには，1 マルチキャストとオー バーレイネットワークなどを用いたアプリケーションレベルマルチキャストがあ る．通信のリアルタイム性などを考慮すると，1 マルチキャストを用いた方が 望ましいが，1 マルチキャストのアーキテクチャに本質的に起因する多数の問題 で，インターネットへの広域な展開が為されていない問題がある =>．また，本 提案サービスはサービスのパーソナル化を目指しているため，マルチキャスト上 でこのようなことを実現することには限界があり，問題が多い． そこで，本研究はユニキャストを用いてスケーラブルな同報型の情報配信機構 を構築することを目的とする．具体的には，クライアントへのデータ配信のうち， リアルタイム性の高いデータとリアルタイム性の低いデータを分離して扱う．リ アルタイム性の高いデータは完全なサーバプッシュ型配信を用いる．一方，リア ルタイム性の低いデータは従来の /1 => によるプル型配信を行い配信機構の スケラービリティを確保する．本研究では，特に番組連動型サービスを提供する 際のコンテンツ同期の問題に焦点を当て，リアルタイムなイベント配信を実現す るサーバプッシュ型の配信機構を提案し，実装を行う．マイクロベンチマークプ ログラムを用いた提案配信機構の評価実験により，現実のサービスを提供する際 に要求される高いスケーラビリティ，そして，動的にイベントが発生したり，高 いリアルタイム性を有する生放送番組にも対応できることを検証し，リアルタイ ムな イベント配信を実現する本提案配信機構の有効性について示した． ここで，本論文で扱うリアルタイム性の定義について補足を行う．一般的に， リアルタイム性にはハード・リアルタイムとソフト・リアルタイムがある．本論 文におけるリアルタイム性は一般的に用いられる厳密的な定義ではないことに注 意する． 本論文の構成 本論文の構成は以下の通りである．まず， 章で既存の同報型コンテンツ配信 技術について述べ，次に 章で本研究で実現しようとしている番組連動型サービ スの概要と実現する際の技術課題を明確にし，それに対するアプローチについて 述べる，そして， 章と 章で提案サービスを実現するため，コンテンツ配信の 部分に主に着目したサービスシステム全体の設計，ベンチマークまで含めた実装 について述べる． 章では提案システムがどこまでの性能を保証できるかの指標 を出すため，ベンチマークプログラムを用いたシステムの性能を定量的に評価す る． 章で今後の課題を挙げ，最後に 2 章で研究のまとめを述べる． 第章 同報型コンテンツ配信技術 本研究では，同報性の高い番組連動型情報サービスをインターネット上で実現す ることを目標としている．本章では，既存の同報型コンテンツ配信技術について 述べ，本研究の位置づけを示す． プッシュ型通信における関連技術 これまでのプッシュ型情報配信技術は大きく２種類に分けることができる．１ つは，９０年代後半に に代わる情報サービスとして非常に多くの注目を集め たプッシュ型情報サービスである．代表例として 17 のような情報配信サー ビス => が挙げられる．もう１つは携帯端末向け通信プロトコルの 1（ )) 1）におけるプッシュ通信である．ここで，これらの技術の特 徴や問題点について述べる． 1 は，ユーザのコンピュータ画面に最新のニュースが表示される，イ ンターネットでの情報提供サービスである．提供される情報のジャンルは株価情 報，お天気，ニュース，スポーツ情報などがあり，ユーザは興味のあるジャンル を設定しておくと，その設定された項目に従って専用のクライアントが自動的に 情報を収集する．ユーザはジャンルを選択するのみで，ほしい情報を探し回るこ となく，自動的にクライアントに ”プッシュ ”される．クライアントプログラム は，ユーザの設定に従って /1 を用いてサーバから情報を取得する． 17 に代表されるプッシュ型情報配信に用いられている方式は疑似プッ PAP (Push Access Protocol) PushOTA (Over the Air) PPG PI (Push Initiator) 移動機 （Push Proxy Gateway） 図 ' 1 プッシュアーキテクチャ シュ（スマートプル）とよばれている．スマートプルの欠点として，不必要なデー タ問い合わせにより無駄なトラフィックが発生することや，更新されたデータが 即時にクライアントに提供できない問題点 => がある．そのため，リアルタイム 性の高いコンテンツ配信を実現することができない． （ ） 1 は移動通信型の携帯端末からインターネット上の情報にアクセスするた めの通信プロトコルである．従来の 1 '0 は独自プロトコルを用いたが，現在 の 1' では通信プロトコルを 71?1 を採用することで，インターネット上 のホストとほぼシームレスに通信を行えるようになった．1' では，音声，画 像，テキストなどのメッセージの送受信が可能な 機能のほかに，リアルタ イムに情報が送れる 1 1&# の機能も提供している．図 ' に 1 プッシュ アーキテクチャを示す =>．1 プッシュアーキテクチャは，プッシュメッセージ の送信ホストである 1（1&# ! メッセージプッシュのプロキシ機能及び 移動機のアドレス解決等を行う 11<（1&# 10* <"* =>，及び移動機か らなる．1 と 11< の間では 11（1&# 1 =2> が用いられ，11 は @: により記述されるプロトコルであり，メッセージのプッシュ，結果通知 等の機能を持つ．11< と移動機間の無線ネットワーク部では，1&# A（A # =3> が用いられている．1&# A は，11< から移動機へのデータのプッ シュ機能の実現や，移動機アプリケーションのアドレッシング及び各種制御情報 の交換等の機能を提供する．また，コンテンツのプッシュ配信は /1 の 1A 図 ' 1 マルチキャスト メソッドを送信することで実現されている．このことから，1 を用いたプッ シュ型通信モデルは無線通信特有の処理を除いて，単にクライアントとサーバの 地位を逆転したモデルであり，プッシュ機能を提供する場合，クライアントが増 えた場合のスケーラビリティが問題となる． マルチキャスト技術 マルチキャスト技術は大規模なファイル配信やストリーム配信，ネットワーク コラボレーションなどのアプリケーションのような，同一のデータを複数のホス トに一斉配信を実現する技術である．マルチキャストにはルータによるサポート を用いる 1 マルチキャスト = > とオーバレイネットワークなどを利用したアプ リケーションレベルマルチキャストがある．以下にそれぞれの特徴と現状の問題 点について述べる． マルチキャスト 1 マルチキャスト技術は，一対多，多対多の通信を効率的に実現する 1 層の 技術である．1 マルチキャストの概念図を図 ' に示す．図に示してあるように， 1 マルチキャストは，ルータを基礎とする 1 ネットワークを通信基盤としてお 図 ' アプリケーションレベルマルチキャスト り，送信ノードが送出したパケットは配送経路の分岐点に位置するルータにおい て適宜複製，転送されるため，ユニキャストを用いて一対多通信を行う場合と比 べネットワーク資源の大幅な効率的運用が可能である．しかし，1 マルチキャス トは，インタードメインルーティングの困難さ，スケーラブルなマルチキャスト ルーティングプロトコルの欠如，信頼性保証，セキュリティ保護が困難であるな ど，実装に向けてまだ多くの技術課題を抱えており，インターネットへの広域な展 開が為されていない．これらの問題の一部を解決するアーキテクチャ = ! ! > がいくつか提案されているが，根本的な解決にはなっていない． アプリケーションレベルマルチキャスト 1 マルチキャストのアーキテクチャに本質的に起因する諸問題で普及が遅れ ていることから，これを代わる現実解として，広く普及しているユニキャストの みを用いてマルチキャスト通信を実現するアプリケーションレベルマルチキャス ト（以下 :）が提案されている = ! ! >．: の概念図を図 ' に示す． : 技術は実ネットワークの上で構築される論理的なトポロジ上マルチキャスト を実現する．図に示すように，: では，ルータに代わってエンドホストがマル チキャスト転送機能を提供し，データはエンドホスト間をユニキャストの中継に よって伝送される．このため，マルチキャスト対応ルータなどインフラストラク チャのサポートのない状況でマルチキャスト通信を実現できる．しかし，: で は，冗長配送経路による遅延時間の増加，重複パケットによる帯域の消費，専用 設計されたルータと比較して相対的に安定性の低いエンドホストの障害（ホスト や接続リンクの故障，アプリケーションの不正終了など）に起因するマルチキャ ストツリーの分割などの諸問題 = > がある．また，通信のリアルタイム性の観点 から 1 マルチキャストの方が望ましい． 既存関連技術のまとめと本研究の位置づけ 同報性の高い本提案サービスを実現する技術としてマルチキャスト技術が適し ていると言えるが，一番優位性のある 1 マルチキャストがなかなか普及してい ないのが現状である．近年のコンピュータシステムの性能向上やネットワークの 広帯域化が進んでいることから，ユニキャストを用いた同報型配信が現実味を増 してきている．本研究では，インターネット上での同報型通信をコンテンツその もののダウンロードと，クライアントへの制御情報を分離することで，システム のスケーラビリティを確保し，リアルタイム性を一定保障することを目指す．特 に，同報型配信を行う際，リアルタイムな イベント配信を実現することは 意義が大きいと考えられる． 2 第章 番組連動型情報サービスシス テム 本章では，提案サービスとそれを実現するサービスシステムの概要について述 べる． サービス概要 本研究で実現する番組連動型情報サービスの概略を図 ' に示す．本提案サー ビスはテレビで放送されている番組と，インターネット上で配信するコンテンツ などを同期させるものである．図にはテレビショッピングの画面構成例を示して ある．これは 17 での操作を想定している．左側にテレビ画面があり，右側にお いて関連商品の説明や サイトへのリンク情報が番組と同期して表示される ようになっている．つまり，本番組放送を視聴しながら同時に表示されるコンテ ンツもチェックすることができる．今現在想定している提供コンテンツはまだ画 像やテキスト情報のみとなっているが，将来的には，ネットワーク帯域の増加や 配信システムの性能向上により，よりリッチな関連コンテンツの提供を目指す． サービス利点 本研究で実現しようとしている番組連動型情報サービスは，いくつかの利点を 有する．一つは，本提案サービスはインターネットでの利用を想定しているため， 従来の固定されたテレビから開放され，パーソナルコンピュータ，モバイルノー ト 17 や携帯電話，1 などすでに普及している情報端末を利用することができ 3 バナー 天気予報 番組タイトル 大阪 最高 4 最低 -1 その他の天気 月月 日日水水 12 12 28 28 (( ))5:20 5:20--6:44 6:44 おはようコール おはようコール テレショップセンター テレショップセンター 笑金テーマソング「ココロ花」（特典 笑金テーマソング「ココロ花」（特典 付付 • • http://www.asahi.co.jp/call/index.html http://www.asahi.co.jp/call/index.html • ABC • ABC http://abc-shop.b-smile.jp/consumer/ http://abc-shop.b-smile.jp/consumer/ DVD ) • DVD ) • http://abc-shop.bhttp://abc-shop.bsmile.jp/consumer/goods/00112.html smile.jp/consumer/goods/00112.html • • http://abc-shop.bhttp://abc-shop.bsmile.jp/consumer/goods/00025.html smile.jp/consumer/goods/00025.html タイガース タイガースメッシュジャージホーム用 メッシュジャージホーム用 テレビ番組 図 ' 番組関連コンテンツ メニュー ニュース 芸 能 スポーツ 料 理 天 気 その他 番組連動型情報サービスの概略 る．よって，従来サービスに比べ，より一層のサービス利便性を高めることが可 能である． 二つ目の利点は，現状のデータ放送サービスよりももっとリッチな情報が提供 されることである．データ放送は，放送サービスの一環として行われるため，公 共性が重視される．そのため，コンテンツに関する規制が存在する．また，データ 放送で利用可能なデータ転送帯域が限られていることや良質なコンテンツを確保 するための情報空間が限定されていることから，魅力のあるコンテンツを提供で きていないのが現状である．このような番組連動型情報サービスをインターネッ ト上に構築することによって，インターネットの持つ広大な情報空間を利用して， 比較的低い制作費でより魅力なコンテンツを提供することができる． 最後の利点は，ユーザの好みや嗜好などに合わせてパーソナライズ化された情 報提供を行うことが可能であること．現状では，居住している地域に合わせた天 気予報程度しか提供されていないが，本提案サービスは，視聴者の特性情報を集 計することが可能であるため，そういった情報を活用して，たとえば，特定の視 聴者に対して広告を提示したり，地域情報を提供したりすることが可能である． また，効果的に番組関連情報を提供できると言う点から，現在の放送局の広告ビ ジネスモデルとの相乗効果を期待できる． 技術課題 このような番組連動型情報サービスを実現する際に求められる技術課題を以下 にまとめる． 低コストなコンテンツ生成 番組連動型サービスを提供する際に，まずその提供コンテンツの製作コストを いかに低く抑えることが重要であると言える．そのため，現在の放送局にある既 存の番組制作現場との親和性を充分に考慮したコンテンツの生成や管理のフレー ムワークを構築する必要がある．具体的には，番組の台本情報や番組制作現場に おいて随時発生する番組の進行情報などを構造化して一元管理できるコンテンツ のデータベースの構築や，番組編集現場におけるコンテンツの自動作成支援手法 が挙げられる． スケーラブルでかつリアルタイム性の高い同報型配信 テレビ番組の特徴として，リアルタイムに番組が放映されいることとその視聴 者数の多さである（国内に限定した場合に，単一番組の同時視聴者数は 万を 超える可能性がある）．一般的に，放送型の同報通信を行うためにはマルチキャ ストが効率的であると言える．しかし，小規模なマルチキャストネットワークの 相互接続の努力がみられるものの，未だにインターネット規模でマルチキャスト を利用できないのが現状であり，今後数年でこのような状況が大きく変わるとは 考えられない．そのため，本研究ではユニキャストを用いる．しかし，短期間に かつ大規模なユーザに対してユニキャストでコンテンツ配信するには非常に高い システムパフォーマンスが要求される．たとえば， 万ユーザに対して -9 の データを 秒で配信する場合を考えると，プロトコルのオーバーヘッドを除いて も実に <) のネットワーク帯域が必要となる．そのため，本提案システムは 現状を充分に考慮した設計をしなければならない． 同期したサービス要求 本提案サービスは放送番組に連動して番組関連情報を提供するため，表示イベ ントが切り替わるごとに大量のクライアントが同期してサービスを要求する可能 性がある．そのため，サーバの過負荷を引き起こし最悪の場合大規模なサービス 障害が発生する恐れがある．本提案システムを構築するに当たっては，クライア ントからのアクセスの一極集中を避ける手法を導入する必要がある． クライアントの初回接続への対応 提案サービスで提供されるコンテンツは時系列に表示を行う．そのため，クラ イアントがサービスを開始した直後は，非常に短時間で現在表示すべきコンテン ツをダウンロードして表示することが望ましい．このような状況に対応するため に，時間的制約を満たし，配信コンテンツの最適なスケジューリングや配信タイ ミングを考慮したコンテンツ配信方式を構築する必要がある． 本研究のアプローチと焦点 本研究では，プッシュ型とプル型の情報配信機構を併用した，高いスケーラビ リティとリアルタイム性を有するサービスシステムを提案する．具体的には，ク ライアントへのデータ配信のうち，リアルタイム性の高いデータとリアルタイム 性の低いデータを分離して扱う．リアルタイム性の高いデータはサーバプッシュ 型配信を行う．具体的には，サーバとクライアント間に永続的な 71 セッショ ンを保持した上で，サーバからクライアントに対してデータ送信を行う．このと き，サーバは基本的に接続確立以外はクライアントからのリクエストを受け付け ないようにする．また，多数のクライアントへのリアルタイム性の高いデータ配 信はシステムに与える負荷が高いため，データサイズを非常に小さくする必要が ある．一方，リアルタイム性の低いデータは 7 * "-（7 ） のような従来の情報配信インフラを最大限に活用するため，/1 によるプル型 配信を行う．そこでは，できる限り配信コンテンツのデータ圧縮などを行うこと コンテンツ 生成・管理 ・リンク情報 ・表示シナリオ コンテンツ セット コンテンツ 配信 HTTPによる コンテンツセットの PULL型ダウンロード リンク情報 番組シナリオ DB 情報 コンテンツ生成 プログラム Webサーバ インターネット ' 表示制御情報 制御サーバ 独自のプロトコル による制御情報 push型配信 クライアント群 コンテンツ 受信 図 製作現場から 随時発生する 表示制御命令 Webブラウザ 提案システムの概略 で転送データサイズを削減し，さらにクライアントからのデータダウンロードの タイミングを分散させることでサーバへの負荷の集中を回避してシステムの全体 のスケーラビリティを確保する．本研究では主に，データ配信のリアルタイム性 を実現するためのサーバプッシュ型配信機構に焦点を当てる． サービスシステム概要 本提案サービスを実現するためのサービスシステムの概略を図 ' に示す．こ のように，本提案システムはコンテンツ生成・管理，コンテンツ配信（サーバ）， コンテンツ受信（クライアント）からなる． 提案システムのデータフローについて説明する．まず，クライアント上に表示 されるコンテンツは，8B: データベースと番組シナリオを用いて作成され，パッ ケージングを行い，コンテンツサーバ（ サーバ）に格納することによって ダウンロード可能になる．表示コンテンツの表示開始終了時刻，コンテンツの識 別子といった制御情報は，独自プロトコルにより制御サーバからクライアントに 対して純粋にプッシュ配信される．制御情報の配信タイミングは番組前や番組放 送中のような場合が考えられる．クライアントは，コンテンツサーバからダウン ロードしたコンテンツと，制御サーバから受信した表示制御情報に基づいて自動 的に ブラウザ上でコンテンツの表示を行う． 放送番組の特徴 本提案システムのアプローチを実現するためには，まず，放送番組の特徴につ いて分析する必要がある．以下にそれぞれの代表的な放送番組について詳説する． テレビ放送番組は大まかに，ドラマなどの録画放送番組，ニュース番組，スポー ツ中継などの生放送，緊急ニュース速報などの緊急放送に分けることができる． 以下に放送番組のそれぞれの特徴について説明する（表 ' ）． 録画放送の場合，録画放送番組は，放送開始時刻が変更されたり，番組途中で 緊急ニュースなどの番組が挿入されたりしない限り，あらかじめ決められたシナ リオ通りに進行する．生放送は番組シナリオがある程度存在する場合とほとんど 存在しない場合がある．番組シナリオが放送前に製作されれば，表示コンテンツ を事前に用意することが可能である．そして，番組の進行にあわせてコンテンツ の表示タイミングを時系列の前後調整だけで済む場合が多い．また，スポーツ中 継のようなシナリオが存在しない場合でも，チームや選手などの情報を放送前に ある程度入手できるため，表示コンテンツ自体は事前に用意することが可能であ る．しかし，シナリオがないため，次にどういうイベントが発生するのか事前に 決定することができない．よって，コンテンツ表示イベントを任意のタイミング で生成できる手法が必要になる．緊急ニュース速報の場合はコンテンツを事前に 用意できない，かつ表示制御情報とコンテンツは共に緊急度が高く，できるだけ 早くユーザに送信しなければならない． プッシュ型配信（制御サーバ） 本提案サービスでやり取りされるデータは，上述した放送番組のそれぞれの特 徴を考慮して，リアルタイム性の高低に分類できる（表 '）．本提案システムで は，リアルタイム性の高いデータについては制御サーバからクライアントに対し 表 ' 番組 生放送 代表的なテレビ放送番組の特徴 特徴 ニュース速報 コンテンツを事前に用意できない． 表示緊急度が一番高い． スポーツ中継 コンテンツを事前に用意できる． 次の表示イベントは事前に決定できず，細粒度の表示調整を行う． 一般ニュース コンテンツを事前に用意できる． 番組シナリオにより，時系列への前後表示調整を行う． 非生放送 ドラマ 表 ' コンテンツと表示制御情報を事前に用意できる． リアルタイム性の高いデータと低いデータ テレビ番組 緊急放送 （災害時のニュース速報など） シナリオのある生放送番組 （ニュースなど） シナリオのない生放送番組 （スポーツ中継など） 非生放送番組 （ドラマなど） リアルタイム性高いデータ リアルタイム性低いデータ 緊急メッセージ コンテンツ表示制御情報 表示制御調整情報 表示コンテンツ 表示制御情報 表示コンテンツ 放送時間の変更 表示制御情報・表示コンテンツ て完全プッシュ型配信される．具体的には，制御サーバとクライアント間に 71 セッションを保持した上で，必要に応じて自由なタイミングでクライアントに対 して送信する．この際，クライアントからのコネクション確立，切断要求以外に は制御サーバに対して要求を一切送らないようにする．このことは，サーバ内部 における ?A イベントの管理を簡略することが可能となり ，従来の サーバ などと比較して，サーバ 台あたりの性能が大きく向上される．また，プッシュ 型配信により送られる表示制御情報には，コンテンツの識別子と表示開始終了時 刻などが含まれる．これらの情報は，可能な限り小さくすることがシステムのス ケーラビリティの確保のために重要である．たとえば， 万人に対して， 秒 で バイトのデータを配信することを考えると，プロトコルオーバーヘッドを 除いても，) の帯域が必要となる．そのため，このプッシュ型配信はバイ ナリフォーマットによる独自プロトコルを設計し用いる． プル型配信（コンテンツサーバ クライアント） リアルタイム性の低いデータは 7 や 11 技術といった従来のコンテンツ配 信技術を活用できるように，従来のプル型の /1 を用いた配信を行う．コンテ ンツサーバは通常の サーバを用いる．本提案システムでは，/1 プロト コルのオーバーヘッドをできるだけ減らすために，一定時間分の配信コンテンツ をパッケージ化してコンテンツサーバより配信する．ここで，パッケージされた コンテンツをコンテンツセットと呼ぶ． 本提案システムにおいて，放送番組の特徴にあわせて最適なコンテンツセット を作成することが望ましい．前述したように，緊急ニュース速報のような場合を 除いて，基本的に事前にある程度表示コンテンツを作成することが可能である． ここで，こういった番組に適したコンテンツセットの構造（図 '）について述べ る．図のように，コンテンツセットは基本的に階層構造になっており，一つのコ ンテンツセットにはさらに複数のコンテンツセットの情報（上位コンテンツセッ ト（親）の識別子，自分自身の識別子，表示開始終了時間，下位コンテンツセッ ½ サーバ性能のボトルネックとなることの多い，$#() や が不要となる． $$() のような *+ イベント管理 番組A（１時間） A Aa Ac0 Ab Ac1 Ac Ac2 Ad Ac3 Ac2_0 Ac2_1 Ac2_2 図 ' コンテンツセット（１５分） Ac4 コンテンツセット(3分) コンテンツ（１分） コンテンツセット構造 ト（子）の識別子）を，最下位のコンテンツセットには具体的な表示コンテンツ 情報（表示コンテンツ識別子，表示開始終了時間，テキスト，リンクなどのコン テンツ情報）を格納している．ここで示した例では， 時間分の番組 のコンテ ンツセットの中には，さらに粒度の細かい 分ごとのコンテンツセット ∼ が存在し，そして， には長さ 分のコンテンツセット ∼ を含んでお り，その中にそれぞれ長さ 分のコンテンツが入っている．また，これらの情報 はすべて @: の形式でファイルに記述されるものとする．クライアント側では 必要に応じて @: ファイルを解析したり，ブラウザに表示できるよう加工した りする． 一方，番組連動型コンテンツ配信では，クライアントが同期してサーバに対し てダウンロードを行う可能性が高いため，サーバへの負荷の一極集中を避ける手 法を導入する必要がある．前節で述べたように，放送番組はそれぞれ番組の特徴 があり，その特性に応じて一極集中を回避するダウンロード手法を適用しなけれ ばならない．' 節でそれぞれのダウンロード手法について詳説する． リアルタイム性の要求分析 本研究では，表示コンテンツと表示制御情報を分離することによって，現実の サービスに要求されるリアルタイム性と規模拡張性を達成することを目標として いる．ここで，実際サービスでどこまでのリアルタイム性が要求されるかについ て述べる．本提案サービスで提供される番組関連情報の表示間隔は，実際の番組 のシーンの変化によって粒度が変わってくるが，視聴者の立場から考えると，表 示間隔が 秒∼ 秒程度が妥当であると考えられる．'' で述べた番組の特徴 から，緊急放送の場合を除いて生放送番組が一番リアルタイム性を要すると言え る．今回実際に朝のニュース番組の C シート（番組の進行台本）に基づいて分析 を行った．その結果，あらかじめ番組のシナリオ通りに番組進行するのはごく一 部だけであり，それ以外は基本的に進行を動的に編成していたことが分かった． 実際の生放送番組では 7 の放送枠時間が決まっているため，基本的に 7 の放 送時間を目安に番組進行の前後の遅れを調整することが多い．今回分析を行った 対象のニュース番組では，7 の予定放送時間より 秒∼ 秒の遅れが発生し ていた．以上のことを総合的に判断すると，現実のサービスにおいて，およそ ∼ 秒以内に表示制御情報を通知できることが望ましい． 2 第章 提案サービスシステム設計 本章では，提案システムの詳細な設計について述べる． システムの参照モデル 本研究で提案するプッシュ型の情報配信システムをより汎用性のあるものにす るため，システム参照モデルをここで定義する．システムの構成要素で制御サー バとクライアントのシステム参照モデルをそれぞれ図 ' と図 ' に示す．参照モ デル全体は大きく上位レイヤのサービスモジュールと下位レイヤの通信モジュー ル，両者間のイベントを仲介する役割をもつイベント・マネージャにより構成さ れる．以下に参照モデルの構成について詳しく述べる． 制御サーバ 制御サーバは主に表示シナリオの管理，各クライアントの状態管理，多数のコ ネクションハンドリングなどの機能を持つ．ここでは，制御サーバの参照モデル の構成モジュールについて説明する' ¯ ドラマ，バラエティなどの録画放送番組では，番組進行シナリオがあらか じめ用意されている．番組シナリオから作られる静的な表示制御情報はこ こで管理される．放送時間の変更に伴う表示制御情報の時系列の前後への 調整を除いて，基本的に表示制御情報を更新しない． ¯ *, 生放送のような，動的に生成される表示制御情報をここで管理する．生放 3 Static Dynamic Content Client Scenario Scenario Manager Manager Manager Manager Event Manager Control Communication Handler 図 ' 制御サーバの参照モデル 送は番組のシナリオのある ニュース ，ない スポーツ中継 の２種類に 分類される．いずれも番組の進行は常に変化しているため，コンテンツの 表示制御情報も番組にあわせて逐次生成，変更をする必要がある．また，緊 急ニュース速報のような，完全に動的な表示制御情報を生成する場合もこ こで管理する． ¯ ¯ 7 配信されるコンテンツをここで一意的な を用いて管理する． 7 ここで，制御サーバに接続されている各クライアントの接続状態 受信中， 終了したなど ，接続情報 1 アドレス，ポート，接続時間など などを管 理する．接続が終了したクライアントに関する情報は逐次削除する必要が ある． ¯ ( 上位と下位のレイヤのイベントのやり取りの管理をここで行う．上位レイ ヤはサービス機能を実装し，下位レイヤはクライアントとの通信機能を実 装する． ¯ 7 7,,& / 表示制御情報や緊急放送時の表示コンテンツをクライアントに対して直接 プッシュ型配信される．クライアントからのリクエストを受け付けること はない． Presentation Scenario Content Communication Manager Manager Manager Manager Event Manager Control Data Communication Communication Handler Handler 図 ' クライアントの参照モデル クライアント クライアントは表示データのシナリオ管理，データの通信管理，表示タイミン グ制御などの機能を持つ．本節では，クライアントの実装モデルの構成モジュー ルについて説明する． ¯ 1 シナリオとコンテンツを管理するモジュールと連携して，番組と同期して クライアント上で番組関連コンテンツの表示を行う． ¯ 制御サーバから受信した表示制御情報をここで管理する．もし，録画放送 番組の場合で放送時間の変更情報がなければ，表示制御情報をそのままタ イムテーブルとして利用する．それ以外の場合は，情報表示のためにタイ ムテーブルを動的に構築して，準備が出来次第 1 に供 給される． ¯ 7 受信した表示制御情報に基づいて サーバからダウンロードした表示コ ンテンツをここで管理する．ここで，効率的にコンテンツデータを管理する ためにコンテンツのデータベースを構築することが望ましいと考えられる． ¯ 7,,& クライアントの通信状態を管理し，ダウンロードタイミングの時間的分散 などを制御する． ¯ ( 制御サーバと同様に，上位サービスレイヤと下位の通信レイヤ間のイベン トのやり取りの管理を行う． ¯ 7 7,,& / 制御サーバからプッシュ配信される表示制御情報や緊急時の表示コンテン ツの受信をここで行う．制御サーバに対して基本的にリクエストを発行し ない． ¯ 7,,& / プル型のリアルタイム性の低い配信をここで行う．具体的には受信した表 示制御情報に基づいて， サーバに対して /1 のリクエストが送信さ れ， サーバからのコンテンツを受信する． プッシュ型配信系設計 本提案システムの配信系の部分はコンテンツ配信（制御サーバ＆ウェブサーバ）， コンテンツ受信（クライアント）からなる．上で述べたシステムの参照モデルに 基づいて，以下にそれぞれプッシュ配信に用いられるデータフォーマットとクラ イアントにおける時間的分散を行うダウンロード手法について述べる． 表示制御情報のデータフォーマット ここで，制御サーバからクライアントへのプッシュ配信に用いられるデータ フォーマットについて述べる． 章で述べたように，それぞれテレビ番組の特質 に応じてデータフォーマットを設計する必要がある．これらのことを考慮して， リアルタイム性の比較的低い録画放送番組には図 ' のデータ構造を，生放送番 ' のデータ構造を，そして，表示緊急度が一番高い緊急 放送のような場合は図 ' のデータ構造を用いる．以下にそれぞれのデータ構造 組のような場合には図 について詳説する． 0 7 8 Version 図 ' 15 16 Type Total Length Program ID Content Set ID Display Start Time Display End Time Download Start Time 31 header payload 録画放送の場合のデータ構造 まず，すべてのデータ構造のヘッダー部は バイトの固定長フィールドを持つ． ヘッダー部には % フィールド，*) フィールド， :# フィールド からなる．*) フィールドには 種類の値を持ち，それぞれ 0 は録画系の番 組を，0 は生放送系の番組を，0 は放送時間変更を，0 は緊急の場合を 表している．そして，ペイロード部はそれぞれ各番組によって異なっている．録 画放送の場合は一つのコンテンツセット情報サイズ（ バイト）を基本単位とし， 個々のコンテンツセット情報をリスト構造により可変数構成することが可能であ る．従って，ペイロード全体のサイズは バイト ¢ コンテンツセット数になる． 前述したように，録画放送番組の場合，放送開始時刻が変更されたり，番組途中 で緊急ニュースなどの番組が挿入しない限り，あらかじめ決められたシナリオ通 りに番組を進行する．そのため，表示シナリオが変更されない場合では，クライ アントのサービス開始時に，即時表示すべきコンテンツセットの情報をクライア ントに対してプッシュ型配信すればよい．その後は，クライアント側で主導的に コンテンツダウンロードを制御することが可能である．そのため，図 ' のよう な構造が適していると考えられる． 一方，生放送番組の場合では，コンテンツの表示イベントは常に時系列に変わっ ていくため，新しいイベントが発生した場合に即座に変更情報をクライアント側 に対してプッシュ配信する必要がある．図 ' のようなデータ構造を用いること で，そういった変更情報を反映されることが可能であると考えられる．また，プッ 0 7 8 Version 図 0 ' 15 16 Type Total Length Content ID Display Start Time Display End Time Next ID 図 15 16 Type Total Length emergency information ' header payload 生放送の場合のデータ構造 7 8 Version 31 31 header payload 緊急放送の場合のデータ構造 シュ型配信する際に，システムのスケーラビリティを確保するためには，このよ うな表示制御情報のデータサイズは可能な限り小さくすることが重要である．今 回はペイロード部はすべて バイトとなっている．また，図 ' のような緊急放 送の場合では，すぐに表示したい緊急メッセージを直接ペイロードに付加する構 造になっている．この場合，)* 部はサイズ不定である． 表示制御情報の管理 実際のサービス場面において，本提案サービス利用者は基本的に任意のタイミ ングにおいてサービス接続を行うため，接続を完了した際に配信されるコンテン ツの表示制御情報を効率よく管理することが重要であると言える．ここでは，制 御サーバの参照モデルのシナリオマネージャーにおいて管理される表示制御情報 を管理する設計例について述べる． 本提案システムで提供されるコンテンツは，基本的に一定時間分の配信データ がパッケージ化される． 章でこれをコンテンツセットと定義した．そして，そ <?xml version="1.0" encoding="SHIFT-JIS"?> <program> <programinfo> <channel>ABCテレビ</channel> 番組概要 <date>10月28日(金)</date> <time>21:00～21:54</time> <programname>笑いの金メダル</programname> <mc>三宅裕司, くりぃむしちゅー</mc> </programinfo> <contentset ID="ABCAA120"> <programID>ABCAA000</programID> <parentID>ABCAA100</parentID> <starttime>1130501100</starttime> 表示制御情報 <endtime>1130501400</endtime> <nextsetID>0</nextsetID> <contentitem ID="ABCAA121"> 表示コンテンツ <parentID>ABCAA120</parentID> 情報 <starttime>1130501100</starttime> <endtime>1130501250</endtime> <nextsetID>ABCAA122</nextsetID> <title>笑いの金メダル</title> <url>http://www.asahi.co.jp/waraking</url> <description>番組ホームページ</description> </contentitem> <contentitem ID="ABCAA122"> <parentID>ABCAA120</parentID> <starttime>1130501250</starttime> <endtime>1130501400</endtime> <nextsetID>-1</nextsetID> <title>過去の金メダルリスト</title> <url>http://www.asahi.co.jp/waraking/medal</url> <description>金メダリストの笑い芸人チェック</description> </contentitem> </contentset> </program> 図 ' コンテンツセットの構造例 れぞれのコンテンツセットは階層構造で @: 形式のファイルで記述される．こ こで，録画放送の場合のコンテンツセットの構造例を図 ' に示す．大きく番組 概要説明，コンテンツ表示制御情報と実際に表示されるコンテンツからなる．図 からわかるように，表示コンテンツにはそれぞれ )，0 の ようなタグがあり，さらに ) で示されたコンテンツセットには自分自 身の親を示す ) がある．このようにして，階層構造を実現している． シナリオマネージャーではコンテンツ表示制御情報について管理を行う．ここ で示された表示制御情報には，表示コンテンツ識別子，表示開始終了時刻と次に 表示すべきコンテンツ識別子が含まれている．シナリオマネージャーはこういっ た情報を時系列的に関連付けを行い，現時刻で表示すべきコンテンツの制御情報 をタイムテーブルにて常に保持して更新していく．このようにすれば，クライア ントの任意のタイミングでのアクセスに対応できるようになる． ダウンロードタイミング 即時ダウンロード のランダム化 コンテンツセットの 表示時間 ダウンロード ダウンロード 開始可能時刻 開始最終期限 図 ' 時間 コンテンツダウンロードの時間的分散 番組B 番組A コンテンツセットA(1時間) コンテンツセットB(45分) Aa Ab Ac Ad Ac0 Ac1 Ac2 Ac3 Ac4 Ac1_0 Ac1_1 Ac1_2 時間 コンテンツセットAｃ(15分) コンテンツセットAc1(３分) コンテンツ 図 '2 録画放送のダウンロード手法 コンテンツダウンロードの時間的分散 コンテンツダウンロード時のサーバへの負荷の集中を防ぐために，クライアン トは決められた時間内に時間的な分散を行う．ダウンロードの時間的分散の概念 図を図 ' に示す．ダウンロードの開始タイミングはダウンロード開始可能時間 から最終期限までの間にランダムに決定される．もし，最終期限を過ぎてしまっ ている場合は即時ダウンロードを開始する．実際のダウンロード手法は番組の特 性に応じて考慮する必要があり，ここでは，録画放送の場合のダウンロード手法 について説明する． 録画放送の場合，すべてのコンテンツセットは表示開始時刻と表示終了時刻が あらかじめ決定されている．図 '2 は図 ' のコンテンツセットの表示時間の部分 を詳細化したものである．ここでは録画放送番組 と 9 を想定している．図 に示すように，今クライアントの接続時刻がちょうどコンテンツ '2 の表示時 間内であると仮定すると，制御サーバはクライアントに対してコンテンツセット ，，，， の表示制御情報をプッシュ配信を行う．そして，クラ イアント側では受信した制御情報に基づき，今すぐ表示しなければならないコン テンツセット の即時ダウンロードを行う．そして，ダウンロードしたコンテ ンツをブラウザに表示する．また，それと並行して，次のコンテンツの表示開始 時刻を考慮し，バックグラウンドで番組 の残りのコンテンツセットを即時ダウ ンロードか，時間的分散ダウンロードをするようスケジューリングを行う．この ように，ダウンロードタイミングは制御サーバからのヒントをもとに，すべてク ライアント側のみで決定することで，処理の効率化を図る． このようにして，クライアント側では決められた時間内に時間的な分散を行う ことで，コンテンツダウンロード時のサーバへの負荷の集中を防ぐことができる． また，クライアント側での工夫だけではなく，7 や 11 技術といった従来の サーバにおけるコンテンツ配信技術を活用することによって，システム全体のス ケーラビリティを高める． 第章 提案サービスシステム実装 前章で述べたシステムの設計モデルに基づき，現実のサービス利用を想定して サービスシステムの実装を行った．システムは 7 言語を用いて実装し，開発及び 実行環境は，:&0（-'' ）を利用した．本章では，提案サービスシステ ムの実装について述べる． 実装概要 システムの実装コストを考慮して，提案システムをマルチスレッドモデルに基 づいて，データ送信プログラムである制御サーバとクライアントの受信プログラ ムを実装した．それぞれ実装モデルの基本構成は大きくサービス諸機能を提供す るサービススレッド群と，通信機能を提供する通信スレッドに分かれる．また実 装ではライブラリには )#，@:= 2> ファイルの作成，解析には 0,= 3> を用いた．制御サーバとクライアントの実装モデル図をそれぞれ図 ' と図 ' に示す．以下にそれぞれの実装の詳細について述べる． 制御サーバ 制御サーバは大きくサービス処理を行う部分と通信処理を行う部分に分けられ る．ここで，プロトタイプ実装した制御サーバの各モジュールについて述べる． 各モジュールはイベント駆動型で独立的に動作している． 2 シナリオスレッド 外部 緊急命令 コンテンツスレッド 緊急コンテンツ 作成 push済みコンテンツ 制御情報受信 静的シナリオ 動的シナリオ テーブル作成 テーブル作成 キュー コンテンツ情報 シナリオ キュー 緊急用キュー スケジューラ 送信スレッド 図 表示スレッド ' キュー search 表示コントローラ 接続状況監視 キュー クライアントの 状態テーブル クライアントの 接続情報 状態変化 接続リスト クライアントへ送信 通信スレッド 制御サーバの実装詳細 シナリオスレッド 通知 表示タイムテーブル 静的シナリオ 動的シナリオ 生成 生成 表示制御 情報 ブラウザ Client管理スレッド 受信ヘッダー解析 緊急コンテンツ バッファ コンテンツスレッド DB store コンテンツ格納 処理 キュー パーサー XML 受信スレッド ダウンロード キュー スケジューラ 制御サーバより コンテンツ Webサーバへ 表示制御情報受信 通信スレッド 受信 HTTPリクエスト 図 ' クライアントの実装詳細 3 サービススレッド群 サービススレッド群はシナリオスレッド（今回は静的なシナリオのみについて しか考慮していない），コンテンツスレッド，7 管理スレッドで構成されて いる． シナリオスレッドは外部より発生したシナリオの受信イベントによりシナリオ テーブルを作成する．テーブルのデータ構造は今回ヘッダーフォーマットを考慮 してリスト型を用いた．もし，クライアントから接続がきた場合，接続情報が接 続リストに追加され，接続時刻により，現在放送中の番組に関連するコンテンツ セットの表示制御情報をクライアントに対してプッシュ配信する．プッシュ配信 されるデータ量は現時点でのシナリオテーブル上に存在する情報の合計サイズと する．そして，次のイベント発生（新たなシナリオ情報到着）までシナリオスレッ ドは待機する． 管理スレッドは接続してきたクライアントの状態管理を行う．上で述べ たように，本サービスの利用者数は場合によって 万人以上の規模もあり得る ため，効率的な状態管理手法を実現することが重要である．今回の実装では，1 アドレスのツリー構造によって個々のクライアントを特定できるようにし，そし て，ツリーの各末端ノードにクライアントの接続情報（ポート番号，ファイルディ スクリプタ，フラグなど）を一意的に関連づけを行う方法を用いた．また，接続 が終了した場合，クライアントに関する情報を状態テーブルから開放する． イベント管理 今回の実装コストを考慮して，図 ' に示すように，サービスモジュールから 通信モジュールへのリクエストの通知はリクエストキューを通じて直接やり取り する手法を用いた．こちらはクライアント側の実装においても同様に適用される． 通信スレッド 通信インタフェースとして，8 @ の標準的なソケットインタフェースを使用 している．また，リクエストキューには優先度付けをし，サービススレッドから のリクエストの緊急度に応じてリクエストキューへの振り分けを行う．こうする ことで，放送局からの緊急命令を割り込ませることが可能になる．通信スレッド は基本的にクライアントからのリクエストを受け付けないことで，制御サーバの スケーラビリティを高める． クライアント ここで，プロトタイプ実装したクライアントの各モジュールについて述べる． サービススレッド群 サービススレッド群は表示スレッド，シナリオスレッド（今回は静的なシナリ オのみについてしか考慮していない），コンテンツスレッドで構成されている． 表示スレッドはシナリオスレッドで作られる表示タイムテーブルに基づき，適 切なタイミングで番組関連コンテンツを " ブラウザ上で表示する．シナリオス レッドにおける表示タイムテーブル作成方法は制御サーバの場合と同様に適用で きる．表示コンテンツの例外に緊急ニュース速報情報の表示がある．この場合は， 現在の表示コンテンツを一旦退避させるなどの工夫が必要になる．また，表示コ ンテンツは専用のコンテンツデータベース（9）で一元管理されることが望ま しいが，今回の実装では個々のファイルで管理している． 通信スレッド 通信スレッドは制御サーバからの制御データ受信スレッドと /1 によるダ ウンロードスレッドによって構成されている．表示コンテンツがどこまでダウン ロードしたかといったステータスや，次にダウンロードすべき項目のスケジュー リングはすべてダウンロードスレッドによって自己管理される．このような独立 性を持たせることで，制御サーバへの負担を軽減でき，システム全体のスケーラ ビリティを高めることができる． ベンチマークプログラム 本提案システムは実際のサービス場面におけるユーザのアクセス環境を考慮す る必要があるため，実際のサービス場面をエミュレートできるベンチマークプロ グラムを実装した．以下にその詳細について述べる． 入出力モデル 本システムでは，制御サーバとクライアントの間で複数のコネクションを同時に 扱うために，入出力を多重化する必要がある．今回は入出力の多重化は システムコールを用いて実現する．対象とする複数個のディスクリプタのリスト を作り を呼び出す． は，指定したディスクリプタの一つ以上 で入出力の準備ができた場合に返る．この時，結果として準備のできたファイル ディスクリプタの数が返される． ノンブロッキング 複数のコネクションを同時に確立させるために，ノンブロッキング を用いる．71 ソケットをノンブロッキングに設定し，このソケットに対して を呼び出すと即座に ( 1BA<B( エラーが返される．しかし，71 のコネクション確立処理である ウェイハンドシェークは引き続き実行される． 実際にコネクション確立が成功したかどうかは，前述の を用いて判別 することができる．これにより， の終了を待たずに次の処理が可能で， サーバとクライアント間に大きなネットワーク遅延を挿入した場合でも，リクエ ストを大量に送信することが可能である． コネクション確立が成功した場合は，そのディスクリプタは書き込み可能にな り，コネクションが失敗した場合には，ディスクリプタは書き込みと読み出しが 同時に可能になる． 時間の記録 制御サーバとクライアントのプログラムを実行時に各接続ずみコネクションに 対してそれぞれ送信開始時刻，受信完了時刻を記録ようにしている．それらの記 録時刻を持ってサービスの遅延時間を算出する．また，時間の測定には，8 @ の を用いた． は，システムクロックの値を返 し，少なくともミリ秒の精度を持つ． 現実ネットワーク環境のエミュレート 実際のネットワーク環境をエミュレートするために，本研究では => により，キューと帯域幅の制限，パケットの遅延やパケット ロスでのシミュレーションを行うことができる．また， は : 8@ カーネ を用いる． ルモジュールとして実装されており，ルータとして動作させることができる．今 回実装した制御サーバの送信プログラムから配信されるデータはすべて を通過するようにし，それぞれのコネクションにネットワーク遅延，パケットロ ス率などを付加してできるだけ現実のネットワーク環境に近づくようにした． 第章 第 提案サービスシステムの評価 章で述べたように，本提案システムは現実のサービスを想定した場合に非常 に大規模なサービスユーザにも耐えるシステムの規模拡張性，そしてある一定の 時間内にイベント通知ができるリアルタイム性が確保されなければならない．そ こで，本章では，実際のサービスを想定したシステムの性能評価により，本提案 システムの有効性について示す． ! 実験の概要 本提案システムはコンテンツの表示制御情報とコンテンツ自体の配信をそれぞ れ分けて処理しており，表示制御情報をプッシュ配信する部分はシステムの高い リアルタイム性を確保する上で特に重要であると言える．そこで，本評価実験は， リアルタイムに配信可能なプッシュ型配信機構を性能評価の対象とする．評価実 験では大規模なサービスユーザのアクセス環境をエミュレートして，ネットワー ク遅延やシステムの同時接続ユーザ数が増加した場合，提案配信機構がどこまで リアルタイム性やシステムの規模拡張性を達成できるかについて明らかにする． ! ベンチマーク実験環境 ここで，性能評価実験で用いたベンチマーク実験環境について述べる．具体的 には，2 台のクライアントホストと 台のルータとして設定した 17 ホストと 台 のサーバホストをギガビットイーサネットで接続し，クライアントは制御サーバ に対して多数の同時コネクションをあらかじめ確立し，それらの上である一定の 時間間隔で制御サーバがイベントをクライアント群に対して一斉に送信するもの 表 制御サーバ !" ' # $ % 計算機環境 クライアント（8台） 制御サーバ（1台） NISTNet 1Gbps 1Gbps 図 ' # % クライアント # % ベンチマーク実験環境 である．制御サーバの送信プログラムとクライアント側の受信プログラムはそれ ぞれ今回実装したものを用いる．また，現実のサービス利用を想定して，大規模 なサービスユーザアクセスを生成できる独自のリクエストジェネレータプログラ ムを実装した．ネットワーク上での様々な状態を再現するために，制御サーバと クライアント群の間に設置された 17 ルータ上に => をインストール し，現実のネットワーク環境のエミュレートを行う．実験で用いた計算機環境を 表 ' に，ベンチマーク実験環境を図 ' に示す． ! 評価実験 本評価実験の目的は，実際にサービスを提供する際に必要とされるイベント配 信のリアルタイム性及びシステムの規模拡張性をどこまで保証できるか，提案配 信機構の性能指標を明らかにする所にある． 性能評価尺度 以下に本提案サービスシステムの性能を表す評価尺度について述べる． サーバがソケット に書き込む時間 時間 クライアント群の 読み出し時間 最大サービス遅延時間 図 ' サービス遅延時間の定義 ¯ サービス遅延時間分布 サービス遅延時間は大きく制御サーバからの表示制御情報の受信時間と サーバからの表示コンテンツ受信時間に分けられる．本評価実験ではイベ ントのリアルタイム配信を評価対象にしているため，制御サーバにおいて 何らかのイベントが発生してからクライアントに対してプッシュ配信する までの時間をサービス遅延時間と定義する．具体的には，制御サーバがソ ケットテーブルに基づいて接続済みリストの最初から最後までソケットバッ ファにイベント情報を書き込むまでの時間と，実際にクライアント側でイベ ント情報をアプリケーションレベルで受信するまでのアプリケーションレ ベルの遅延時間に分けることができる（図 '）．このサービス遅延時間分 布はシステム全体の性能の許容範囲を表す主要な指標であると言える．特 に，初回接続時の場合や途中での緊急放送の割り込みが発生する場合の応 答遅延時間が重要である． ¯ ネットワークの消費帯域 本提案システムはユニキャストを用いているため，システムの性能はサー ビス利用者数の著しい増加により大きく影響される可能性がある．したがっ て，サービスの同時利用者数が増加した場合にネットワークの消費帯域率を 計測することによって，本提案サービスの同時利用者数をどこまでサポー トできるかをあきらかにすることができる． 表 プッシュ回数 プッシュ間隔 & 秒 表 ' 評価実験の測定条件 表示制御情報サイズ（ 回あたり） 同時コネクション数 ' ∼ () 万刻み* ' 評価実験の測定条件 ネットワーク遅延設定 ネットワーク帯域 パケットロス率 ++ ++&++ + なし，&'% ,+ ,+ , パラメータ測定 まず，サービスの遅延時間の測定について述べる．制御サーバは前述したよう に，基本的にクライアントからのリクエストを受信しないため，クライアント側 においてリクエストが送信された時刻を知ることができない．そこで，本評価実 験において，制御サーバとクライアントを外部の 1 サーバにより時刻同期を 行い，サーバ側のイベント送信時刻とクライアントの受信時刻をそれぞれ記録 することにより，アプリケーションレベルでのサービス遅延時間の測定を可能に している．時間の測定は実装プログラムの内部の ,$* を用いて測定を 行った． また，制御サーバ内部とクライアントの性能調査には * = > を用いる． * はシステムの動作に関するさまざまな統計情報を取得することができる． 今回の評価実験では，* を用いて，制御サーバ及びクライアントの 718 使 用率，空きメモリ，ネットワークのトラフィックなどの内部情報のモニタリング を行った． 実験方法 本評価実験では，実際のサービス場面において，最も制御サーバの性能を必要 とする生放送番組に関連した表示制御情報を想定して測定を行った．実験をある 程度簡略化するために，制御サーバはまずあらかじめ用意された番組のシナリ オから作られたシナリオタイムテーブルに基づいて，時間の経過と共に常にプッ 表 ' カーネルパラメータチューニング パラメータ 値 -." （サーバ） % "/" % 0（クライアント） / / /12 '/3"0 %2/% '/3"0 %2/% %2/% 5 %2/% $& ($ 4& 44$ ($ $& & 4 ($$ $ &(& $ シュすべき最新の表示制御情報を更新しながらクライアントからの接続を待つ． '! ' に示す測定条件をもとに，2 台のクライアントホストを順にそれぞれ ,! ,! ,! ,! ,! ,! ,! , の片道ネットワーク遅延を両 方向について設定し，ネットワーク帯域を制限しない，) の場合，パケッ トロス率を 6! ' 6! 6，そして，制御サーバとクライアント間の同時コネク ション数を ! !¡ ¡ ¡ ! 3 万刻み のように増やした場合にシステム 表 全体のサービス遅延時間分布，ネットワークの消費帯域及びサーバリソースの消 費状況がどのように変化していくか測定を行った．また， 回あたりの表示制御 情報は バイト ヘッダー部 D ペイロード部 であり，制御サーバからクライア ントに対して表示制御情報をプッシュ配信しはじめるタイミングは，決められた 同時コネクション数を全部確立したときとする．各クライアントホストはそれぞ れ同等数で制御サーバに対して 71 接続を行う． 表 ' からわかるように，今回の評価実験では大量の同時コネクション数を対象 にしているため，このような多数のコネクションをクライアントとサーバ間に確 立させるために，クライアントホストとサーバホストにおけるさまざまなカーネ ルのパラメータチューニングを行った．具体的なパラメータ設定は表 ' に示す． 実験結果 本評価実験は '' で述べた評価尺度に基づいてそれぞれアプリケーションレ ベル遅延時間，ソケット " 時間，ネットワークのスループット，そして，プッ 2 drop=0% 200 bandwidth=30Mbps RTT=30ms 150 )s m( yc ne t al 100 le ve -ln oi ta ci 50 lp pa 0 10 30 50 70 90 110 130 150 170 190 x1000 number of connection 図 ' アプリケーションレベルでのサービス遅延時間 )56 シュ配信時の制御サーバ負荷状況を観測するため，サーバの 718，メモリ使用 率のような内部情報について測定を行った．以下にそれぞれ評価実験で得られた 結果について述べる． アプリケーションレベル遅延時間 図 '! 図 '! 図 ' にそれぞれパケットロス率を 6! ' 6! 6に変え，同時コ ネクション数を順に増やした場合のアプリケーションレベルでの遅延時間の箱ひ げ図を示す．図から，同時コネクション数が増加するにつれて，アプリケーショ ンレベルでの遅延時間が増加していくことが分かる．また，パケットロスがそれ ぞれ ' 6! 6の場合において，6の場合と比較して 71 の再送制御によって 最大遅延時間がその分だけ増加していることが分かる．また，パケットロス率が 6の場合は ' 6に比べて 回目の再送により，最大サービス遅延時間がほぼ 倍になっていることが分かる． '，図 ' にネットワーク帯域が )，同時コネクション数がそれぞれ 万，3 万，パケットロス率を 6! ' 6! 6に変えた場合のすべての遅延グループ 図 3 500 400 ) s m ( y c 300 n e t a l l e v e l - 200 n o i t a c i l p 100 p a 0 10 30 50 70 90 110 130 150 170 190 number of connection 図 ' アプリケーションレベルでのサービス遅延時間 )5' 6 drop=1% 1000 bandwidth=30Mbps RTT=30ms 800 ) s m ( y c n 600 e t a l l e v e 400 l n o i t a c i l p 200 p a 0 10 30 50 70 90 110 130 150 170 190 x1000 number of connection 図 ' アプリケーションレベルでのサービス遅延時間 )5 6 200 240 180 drop=0% bandwidth=30Mbps connection=30000 160 drop=0.1% bandwidth=30Mbps connection=30000 220 drop=0.1% bandwidth=30Mbps connection=90000 180 drop=1% bandwidth=30Mbps connection=30000 )s 140 (ym c n120 te al l e v100 e l n o tia 80 lic a p p a 60 drop=0% bandwidth=30Mbps connection=90000 200 drop=1% bandwidth=30Mbps connection=90000 )s m160 (y c n 140 te la l e v120 e l n o ti 100 a lic a p 80 p a 60 40 40 20 0 図 20 1 2 ' 3 4 5 遅延グループ 6 7 0 8 各グループの遅延時間分布 図 1 2 ' 3 4 5 遅延グループ 6 7 8 各グループの遅延時間分布 2 はそれぞれ 2 台のクライアントホストで対応している．本評価実験では，2 におけるアプリケーションレベル遅延時間分布について示す．また，横軸の ∼ 台のクライアントホストにそれぞれ異なるネットワーク遅延時間を挿入している． 図 ' より，全体の同時コネクション数が 万と比較的少ないの場合，パケット ロス率の影響によって各グループのアプリケーションレベルの遅延時間がわずか 増加しており，そして，グラフの傾きはほぼ各グループに挿入したネットワーク 遅延時間の差に比例している．一方，図 ' から，同時接続数を 3 万に増やした ことによって，アプリケーションレベルでの各グループの全体の遅延時間はおよ そ , だけ上乗せされて増加していることが分かる． ソケット 時間 '2 に制御サーバにおけるソケットの " 時間分布について示す．図の結 果は全クライアントに対して表示制御情報を 回プッシュ配信した場合の平均で ある．また，実験データの信頼区間を 36とした．図より，同時コネクション数 図 が増加するにつれてすべての接続済みソケットテーブルに対してデータを書き終 えるまでにかかる時間がほぼ直線的に増加しており，たとえば，同時コネクショ ン数が 万の場合では 秒ほどになっていることが分かる． 10000 9000 8000 write time 7000 )s 6000 m (e im t 5000 eit rw 4000 3000 2000 1000 0 10000 30000 50000 図 '2 70000 90000 110000 130000 number of connection 150000 170000 190000 サーバにおけるソケット " 時間 18000 16000 drop=1% bandwidth=1Gbps drop=1% bandwidth=30Mbps 14000 12000 ) s p b K ( 10000 t u p h g 8000 u o r th 6000 4000 2000 0 10000 30000 図 50000 '3 70000 90000 110000 130000 150000 170000 190000 number of connection プッシュ配信時のピークスループット 100 110 90 100 90 80 80 70 % d se u yr 60 o m e m 50 f o ge tan 40 se re p 30 70 60 50 40 30 20 20 10 0 led i U P C f o eg at ne sr ep 10 8 :3 4 1 : 2 8 :4 4 1 : 2 8 :5 4 1 : 2 8 :0 5 1 : 2 8 :1 5 1 : 2 図 8 :2 5 1 : 2 8 :3 5 1 : 2 8 :4 5 1 : 2 ' 8 :5 5 1 : 2 8 :0 6 1 : 2 8 :1 6 1 : 2 8 :2 6 1 : 2 8 :3 6 1 : 2 8 :4 6 1 : 2 8 :5 6 1 : 2 80 :7 1: 2 81 :7 1: 2 82 :7 1: 2 83 :7 1: 2 84 :7 1: 2 85 :7 1: 2 80 :8 1: 2 81 :8 1: 2 82 :8 1: 2 83 :8 1: 2 84 :8 1: 2 85 :8 1: 2 80 :9 1: 2 81 :9 1: 2 82 :9 1: 2 83 :9 1: 2 84 :9 1: 2 85 :9 1: 2 80 :0 2: 2 81 :0 2: 2 82 :0 2: 2 83 :0 2: 2 0 プッシュ配信時の 718 とメモリの使用率 スループット 図 '3 に同時コネクション数が順に増加した場合，サーバが制御情報をプッシュ 配信した時のピークスループットを示す．図中にそれぞれネットワーク帯域がそ れぞれ <)! ) に制限し，パケットロス率を 6にした場合について示し てある．この図から同時接続数が ∼ 3 までの間でサーバにおけるピー クスループットがおよそ ') であると読み取れる．同時コネクション数が 万の時のサーバのスループットの論理値は ) より小さいため，ネット ワーク帯域の制限による影響は見られなかった． サーバの ，メモリ使用率 ' に制御サーバが表示制御情報を接続済みの全クライアント（同時接続 数 万）に対してプッシュ配信した時のサーバの 718 アイドル率，メモリ使用 図 率を示す．プッシュ配信を開始する前はメモリキャッシュのため，メモリの使用 率が 6となっており，すべてのコネクションが確立され，サーバから表示制御 4400 4350 合計サービス遅延時間予測値 drop=1% bandwidth=30Mbps Connection=90000 ) 4300 s m ( y c n e t a l e4250 ic v r e s l a t o t 4200 4150 4100 1 2 図 ' 3 4 5 遅延グループ 6 7 8 予測される全体のサービス遅延時間分布 情報をプッシュしている間では 36にも達していることが分かる．サーバホスト には <9 のメモリを搭載していることから， 万の同時コネクションに対して 提案システムのメモリ使用率はおよそ 9 であると計算できる． また，図から分かるように制御サーバがプッシュ配信している間ではサーバの 718 アイドル率がほぼ 6となっている．プッシュ配信している間だけサーバが 高負荷になっていることが分かる． 考察 本評価実験では現実のネットワーク環境，サービス場面を想定して，ネットワー ク遅延，ネットワーク帯域，パケットロス率を変化させ，同時コネクション数を 順に増やした場合に本提案配信機構がどこまでイベント配信のリアルタイム性， システムの規模拡張性を保証できるかについて検証した． まず，図 ' から，アプリケーションレベルでの遅延時間は同時コネクション 数が増加するにつれて増えていることが分かる．これは同時コネクション数が増 加することによって，カーネルの処理負荷が上昇し，自然とカーネル内での処理 時間が増加してしまうものと考えられる．これは図 '，' に示されているすべ ての遅延グループのアプリケーションレベル遅延時間分布についても同様な傾向 が見られる．また，図 '! ' のように，パケットロスが発生した場合，71 に おいて廃棄されたパケットの再送により，パケットロスが発生しない図 ' と比 較して，71 の初回の再送タイムアウト値の分だけ遅延時間が増加している．今 回の評価実験で制御サーバから個別のクライアントに対して一回あたり パケッ トの制御情報しか送られないために， 回目以降パケットが落ちる確率はかなり 低い．よって，パケットロスによる発生する遅延時間がほぼ一定の範囲に抑えら れている． ' から，ネットワークの往復遅延時間 B5,，ネットワーク帯 域が ) に制限されている場合，同時コネクション数が 3 万の時の最大の アプリケーションレベルでの遅延時間がおよそ 2, であることが読み取れる． また，図 サーバがこのような大量のコネクション数を処理しているのにもかかわらず，ア プリケーションレベルの遅延時間はそれほど大きくない値になっている．これは 本研究で提案しているサーバプッシュ型のイベント配信機構は従来の サー バソフトウェアのアキテクチャーとの違いに起因していると考えられる．具体的 には，' ' で述べたように，本提案イベント配信機構は接続確立要求以外にクラ イアントからのリクエストを受け付けない設計になっている．そのため，サーバ 内部における ?A イベント管理を簡略化でき，同時コネクション数の増加による カーネルの負荷の増加はそれほど大きくないと考えられる． また，図 '2 から同時コネクション数が 3 万時サーバがすべての接続済みソケッ トに対して表示制御情報を書き終えるまでの時間がおよそ 秒である．'' 節で 述べたように，システム全体の最大サービス遅延時間は大きく見積もってアプリ ケーションレベルでの遅延時間とソケットの " 時間の合計であると考えられ る．そのため，図 ' と図 '2 の結果から，同時コネクション数が 3 万の場合に ネットワーク遅延が一様ではなくかつパケットロスが発生する現実のネットワー ク環境において，システムの全体のサービス遅延時間分布は図 測することができると考えられる． ' のように予 評価実験のまとめ 評価実験では，提案イベント配信機構が特にリアルタイム性を有する生放送 番組のイベント配信において，どこまでリアルタイム性やシステムの規模拡張 性を達成できるかについて明らかにすることを目的とした．実際マイクロベンチ マークを用いた評価実験により，ネットワーク遅延 B5,，パケットロス率 ' 6のネットワーク環境において，サーバ 台当り 3 万の同時接続数に対して， イベント配信における最大サービス遅延時間がおよそ ' 秒以内にイベント通知 することが可能であることを検証した．これは '' 節で述べた実際のサービス のリアルタイム性に対する要求に満足することができると考えられる．また，高 い性能を達成するためには，図 ' の結果からサーバマシーンの処理能力が重要 な要素である． また，本評価実験結果から，サービスの全体の遅延時間を低く抑えサービスの リアルタイム性を実現するには，パケットロス率が低いネットワーク環境である ことが求められる．これは，現実のネットワーク環境において，サーバと各ユー ザ間で確立されたセッション状態は違っており，パケットロスが頻繁に発生する ような場合において 71 のタイムアウト値が指数的に増加するため，一定のサー ビス遅延時間を満足することができなくなると考えられる． 第章 今後の課題 本研究で提案する番組連動型サービスをより現実的なものとして実現するために は，さまざまな側面を考慮しなればならない．本章では，本研究において明らか になった課題について述べる． " 低コストな番組連動コンテンツ作成管理フレーム ワークの検討 本研究では主に，コンテンツの配信部分について議論した．現実的な番組連動 型情報サービスを実現するためには，その提供コンテンツの製作コストをいかに 低く抑えることが重要であると言える．そのため，現在の放送局にある既存の番 組制作現場との親和性を充分に考慮したコンテンツの生成や管理のフレームワー クを構築する必要がある．具体的には，番組の台本情報や番組制作現場において 随時発生する番組の進行情報などを構造化して一元管理できるコンテンツのデー タベースの構築や，番組編集現場におけるコンテンツの自動作成システムを構築 する必要がある．これにより，放送番組制作現場と，コンテンツ製作現場との効 率的な情報共用システムが実現される． " システム全体の高いスケーラビリティの確保 本研究では，同報型通信をコンテンツデータのダウンロードとクライアント制 御情報に分離したサーバプッシュ型のイベント配信機構を提案した．配信機構の 設計や実装は主にイベント配信の部分に注力しており，実際のコンテンツデータ をダウンロードする際に要求される高いスケーラビリティをどのように確保する かについて詳細に検討する必要がある．具体的なアプローチとして，まず ' 節 での述べたクライアントが同期してサービス要求により，サーバの負荷の一極集 中が発生することが予想されるため，クライアントからのアクセスタイミングを 時間方向に分散させる手法は有効であると考えられる．この分散手法の基本設計 はすでに ' 章で述べた．また，サービスユーザ数が著しく増加した場合には， サーバ負荷をできるだけ均一化する分散手法には一定の限界があることが考えら れるため，システム全体を考慮した高いスケーラビリティを達成するには，本研 究で提案した手法に加え，既存の 7 のようなコンテンツ配信技術も組み合わ せて用いる必要がある． " コンテンツの暗号化 ' 節で述べたように，放送番組にはそれぞれの番組の特質が存在する．本研 究では，コンテンツを事前に用意できる場合は，積極的に事前ダウンロードを行 うことによって，サーバへの負荷を減らし，コンテンツ配信の効率化を高める手 法を提案した．また，コンテンツは時系列に表示を行うため，すでに番組先のコ ンテンツをダウンロードし終え，まだ表示タイミングになっていない連動型コン テンツを事前に暗号化して配信する必要があると考えられる． " サービス実用化に向けたサービスシステムの構築 及び実証実験 本研究の特徴の一つは，放送局で使用可能な実際的なシステムフレームワーク の構築である．ベンチマークによる性能評価テストだけではなく，放送局の協力 を得て実際のインターネット環境を利用した実証実験を通して，システムの実装 へのフィードバックを行うことで，現実のサービスシステムの完成度の向上を目 指していく． 2 第章 結論 放送と通信のさまざまな技術革新により，双方の垣根が無くなってきており，今 後は双方の利点を生かした放送通信融合サービスが大きく成長するものとして期 待されている．しかし，様々な理由から，テレビ受信機によるいろいろなコンテ ンツサービスを利用するには制限が多く，まだまだ難しいのが現状である．本研 究は現在データ放送でサービスが展開されている番組連動型情報サービスをイン ターネット上で実現するためのコンテンツサービスフレームワークを構築するこ とを目標としている．本サービスをインターネット上に実現することによって比 較的低コストでより魅力なサービスを提供できるようになる． 番組連動型サービスのような同報性の高い通信は，インターネットが本質的に 苦手としている分野である．本研究では，同報型通信をコンテンツデータのダウ ンロードとクライアント制御情報に分離したサーバプッシュ型のイベント配信機 構を提案し，実装を行った．そして，マイクロベンチマークプログラムを用いて提 案配信機構の評価実験により，本提案イベント配信配信機構はスケーラビリティ を確保しつつ，高いリアルタイム性を有する生放送番組にも対応できることを検 証した．また，生放送番組に限らず，録画放送番組の放送時刻変更，緊急放送の ような緊急度の高いイベント表示にも対応できると考えられる．よって，本提案 イベント配信機構は現実のサービスに適用した際に有効であると結論付けできる． 今後は，連動型コンテンツの生成コストを十分に考慮したコンテンツ生成管理 フレームワークを構築するとともに，システム全体として高いスケーラビリティ を達成できる包括的な配信システムの構築により，現実的なサービスモデルを完 成していきたい． 3 謝辞 本研究を進めるにあたり，快適な研究設備，環境を与えて頂き，暖かくご指導 してくださいました奈良先端科学技術大学院大学情報コミュニケーション講座の 山本平一教授に心から感謝致します．本研究の副指導教官であり御指導を賜わり ました同インターネット・アーキテクチャ講座の砂原秀樹教授に心から感謝致し ます．本研究の審査委員であり，研究に対して重要な指針を与えて頂きました同 大学情報コミュニケーション講座の岡田実助教授に心から感謝致します． 御自身が非常にお忙しいにも関わらず，本研究全般にわたり，熱心に研究方針 や実装，論文指導など直接的に御指導を賜りました同大学情報コミュニケーショ ン講座の河合栄治助手に心から感謝致します． 論文執筆の際に貴重な御指導，御助言を頂きました同大学情報コミュニケーショ ン講座の斉藤将人助手，原孝雄助手に心から感謝致します． 本論文をまとめるにあたり，細部にわたる御協力を頂きました同大学情報コミュ ニケーション講座の田口直樹氏，田村和哉氏に深く感謝致します． 研究活動のみならず，日常生活において支えていただきました情報コミュニケー ション講座の皆様に深く感謝致します． 最後に研究活動を影で支えてくれました家族に深く感謝致します． 参考文献 = > 総務省' 平成 年版情報通信白書' => 7' ! 9' ' : ! 9' :*! /' E,! ' 9$' )*, & $ # 1 & #&' ! %' ! ' ! F&* ' => F' &! /' ;**-! ' 9:! B' ;! F' <*' /*)0 $ )' ! 33' => $ /&"# # F+*' 7,) 7,,& $ 1&# *,' ! ), 333' => 神場知成! 坂上秀和! 古関義幸' プッシュ型とプル型を統合したパーソナライ ズ情報配信システムの提案と実装' 情報処理学会論文誌! G ! 332' %' 3! ' ! ))' => 1 ;&,H 1 1&# #& A "! ") )&## " ' ' => 1 ;&,H 1&# 10* <"* )I! 13 11< ' ' =2> 1 ;&,H 1&# 1 )I，111 3 ' ' =3> 1 ;&,H 1&# A 1 )I! 11&#A ' ' = > ' ' & B& "- (0 : ' ! %' ! ' ! && 322' = > /' /- ' 7#' 1 & 7#H (@1B( &) ) $ : & ))' ! ), 333' = > /' /- 9' 7' &)I & $ 1' !"#$!%%&!"!'! # ' = > B' 1,! 7'J' :! F' 7"$! K' ! 7' ! F' #! ' <' ,) &H $ ,)! :" # & ' !(#&!%)&(#!&*#)%!+'! A 333' = > ' 7! 1' &#! ' ' E,! ' B"' 7B9(H + )) ,& $&&' ,*# # % ) &&*))% -,.! ' = > ' 1-! ' #! ' %,! ' ' :H )) : & $&&' + / 0 1&(%)*& 2"#3)% 4 1%&%! # ' = > 1' ;' JH (0 # & #&' "(5))31) ! ) ' = > ' (*! %'B! :' #*' & * $ 1) $ <&) 7,,& ' ! %' ! ' ! F'?;' ' = 2> 7&,H' (0 -&) :&（@:） '' 332' = 3> :0,' #)H??0,$'?' => ' #)H??''' ???' = > J' #)H??)'"'$?'?'