分散環境における ネットワークストリーミング管理制御機構の構築

卒業論文 2006 年度 ( 平成 18 年度 )

分散環境における

ネットワークストリーミング管理制御機構の構築

慶應義塾大学 環境情報学部 氏名：遠峰 隆史

担当教員

慶應義塾大学 環境情報学部 村井 純

徳田 英幸 楠本 博之

中村 修 高汐 一紀 湧川 隆次

平成 18 年 7 月 21 日

卒業論文要旨- 2006年度 (平成18年度)

分散環境における

ネットワークストリーミング管理制御機構の構築

本研究は，メディアストリーミングにおいて，多様化するデバイス，映像フォーマット，

利用方法を統一的に管理，制御する機構を構築した．

インターネットを用いた映像などのメディアストリーミングは，一般向け計算機の高機 能化や，デジタル映像機器の一般化，データリンクの広帯域化に伴い，エンドユーザにお いても様々な用途で用いられるようになってきた．エンドユーザ間のメディアストリーミ ングにおいては，開始前に必要な情報の共有方法や，アプリケーション依存のフォーマッ トといった様々な問題があった．また，コンテンツ制作，配信の中でも，インターネット 上で多様な機器を組み合わせることで，柔軟なシステムが構築されている．このような環 境の中で，メディアストリーミングに必要な情報の管理，および，制御を統一的に行う手 法に対する要求があった．

本研究では，インターネットを用いたメディアストリーミングにおける，必要な情報の 流通手法として，エンドノードにおける管理サーバの自動的な探索，および，管理された 情報の可視化と，その情報に基づく統一的な操作を可能にするシステムを開発した．

エンドノードにおける管理サーバの自動的な探索を行うために，管理サーバをネット ワークごとに配置した．これにより，エンドノードはブロードキャストドメイン内での探 索を行うことができ，管理サーバの探索が容易になる．

管理サーバは，自分の存在するネットワーク内のエンドノードの情報を収集し，管理す る．この情報を，IPマルチキャストを用い，他ネットワークの管理サーバと交換するこ とにより，ネットワークを超えた情報共有が可能になった．

本手法を用いることにより，これまでストリーミングを構築する技術や，アプリケー ションに結びつき，個別に行われてきたセッション管理を，統一的，かつ自律的に管理で きるようになった．また，ブロードキャストドメインを超えた，サービスロケーションの 一例を示した．

キーワード

1．ストリーミング, 2．セッション管理, 3．サービスロケーション

慶應義塾大学 環境情報学部

遠峰 隆史

Abstract of Bachelor’s Thesis

Academic Year 2006

Implementation of Network Streaming Session Management and Control System in Distributed Environment

We developed unified media streaming session management and control system in di- versing AV device, video format and processing.

Media streaming over the Internet by end users for various purposes are now pupular, because of popularization of degital video devices and broadband detalink. Informationg sharing method and application dependent format are the problems for Media streaming between end users. In contents creation and delivery system, many devices and application are combined. In this environment, cotroling a information which is required for media streaming and unified control method is required.

In this research, we provided following functional capability negotiating as media stream- ing information via the Internet.

• automatic management server search.

• visiualization managed session information

• unified control interface based on gathered streaming information.

We set management server per broadcast domain to detect automatically by end nodes, and management servers share these end nodes’ information using Any Source.

In streaming system, session was binding on streaming elements and its application.

This system realized unified and autonomous session management. We also proposed one of global domain service location system.

Keywords :

1. STREAMING, 2. Session Management, 3. Service Location

Keio University, Faculty of Environmental Information

Takashi Tomine

目 次

第1章 序論: 分散環境における映像配信とその管理 1

1.1 背景 . . . . 1

1.2 現状 . . . . 1

1.3 本研究の目的 . . . . 4

1.4 本論文の構成 . . . . 4

第2章 既存のシステムモデルと問題点 5 2.1 ネットワークにおける技術 . . . . 5

2.2 メディアを取り扱うための技術 . . . . 6

2.2.1 DV . . . . 6

2.2.2 HDV . . . . 6

2.2.3 H.264 . . . . 7

2.2.4 異なるフォーマット間の相互利用 . . . . 8

2.3 アプリケーションにおける課題 . . . . 10

2.3.1 Skype . . . . 10

2.3.2 MSN Messenger . . . . 10

2.3.3 iChat AV . . . . 10

2.3.4 Polycom . . . . 10

2.3.5 DVTS . . . . 11

2.3.6 DV Session Manager . . . . 11

2.3.7 複数アプリケーション混在環境における課題 . . . . 12

2.4 接続機器における課題 . . . . 13

2.5 接続管理における課題 . . . . 14

2.6 問題点のまとめ . . . . 15

第3章 アプローチ 16 3.1 ネットワークストリーミング管理制御機構の提案 . . . . 16

3.1.1 本機構の目標 . . . . 16

3.1.2 システムの提案 . . . . 17

第4章 ネットワークストリーミング管理制御機構の設計 20 4.1 設計要件 . . . . 20

4.2 設計概要 . . . . 20

4.3 Clientのサービス解決 . . . . 20

4.3.1 サービス解決概要 . . . . 20

4.3.2 通信の詳細 . . . . 21

4.3.3 Client情報のデータ構造 . . . . 22

4.4 Managerにおける処理 . . . . 23

4.4.1 Client情報の受信 . . . . 23

4.4.2 Manager間の情報共有 . . . . 24

4.4.3 Client情報の視覚化. . . . 25

4.4.4 Clientへの制御情報の送信 . . . . 25

第5章 ネットワークストリーミング管理制御機構の実装 26 5.1 実装概要 . . . . 26

5.2 Client . . . . 26

5.2.1 実装環境 . . . . 27

5.2.2 取得部 . . . . 27

5.2.3 通信部 . . . . 27

5.2.4 制御部 . . . . 27

5.3 Manager . . . . 28

5.3.1 実装環境 . . . . 28

5.3.2 応答部 . . . . 28

5.3.3 通信部 . . . . 28

5.3.4 情報管理部 . . . . 29

5.3.5 情報交換部 . . . . 30

5.3.6 Web Interface部 . . . . 30

第6章 評価 31 6.1 評価概要 . . . . 31

6.2 定性評価 . . . . 31

6.2.1 メディアストリーミング情報の管理制御機構としての機能評価 . . . 31

第7章 結論 33 7.1 まとめ . . . . 33

7.2 今後の課題 . . . . 34

7.3 今後の展望 . . . . 34

図 目 次

1.1 映像コンテンツ制作，配信システムの例 . . . . 2

1.2 Video会議 . . . . 2

1.3 メディアストリーミングの手順 . . . . 3

2.1 DV データ構成 . . . . 7

2.2 GOP概要図 . . . . 8

2.3 トランスコーディング . . . . 9

2.4 PowerPlay社 DV Session Manager . . . . 11

2.5 収録・再生環境 . . . . 14

3.1 提案するシステムのモデル . . . . 17

4.1 システムモデル . . . . 21

4.2 Service resolution : diagram . . . . 22

4.3 Client node information : Data Structure . . . . 23

4.4 Client node information : Node information description . . . . 23

4.5 Client node information : Node information description : Sample . . . . . 24

表 目 次

2.1 各アプリケーションの実現状況 . . . . 13

4.1 Managerで扱われる情報 . . . . 22

5.1 Client部: 開発環境 . . . . 27

5.2 Manager部: 開発環境 . . . . 28

5.3 database: MANAGER . . . . 29

5.4 table: MANAGER INFO . . . . 29

5.5 table: NODE INFO . . . . 29

5.6 table: FOREIGN NODE INFO . . . . 30

6.1 情報の取得の自動化状況 . . . . 31

第 1 章 序論 : 分散環境における映像配信 とその管理

1.1 背景

一般向け計算機の高性能化や，デジタル映像機器の普及に伴い，計算機上でDV(Digital Video)[1]やMPEG2(Moving Picture Image Coding Expert Group Phase 2)[2] をはじめ とした高品質映像が取り扱われるようになってきた．また，インターネットの普及に伴い，

一般的に使われるデータリンクも広帯域化してきており，エンドユーザまで広帯域なデー タリンクが広がっている．

このような環境の変化に伴い，インターネットを用いてDVTS[3]やMPEG2-TS over IPなどを用いた映像転送をエンドユーザ間で行う事が可能になった．

また，映像転送においても，様々な用途で用いられるようになっている．映像を片方向 に転送して，授業などの情報提供を目的とする用途や，双方向に転送して，会議などの双 方向のコミュニケーションを目的とした用途などが挙げられる．最近では，映像をネット ワーク越しに保存して，保存された映像データを再びネットワーク越しに再配信を行うと いった用いられ方もされるようになってきている．

それに伴い，映像の活用形態も多様化している．一地点から他地点への映像転送から，

収録される映像をネットワーク越しに保存，保存した映像データを再転送して映像を出力 するなどである．

エンドユーザにおいても，移動可能な計算機を用いて，様々なネットワークからイン ターネットに接続することが可能になった．様々なネットワークから，自分の資源を用い て，遠隔地の会議に参加することも可能になった．

このように，様々な活用の変化形態に対応した，転送の管理手法が求められている．

1.2 現状

インターネットを用いたメディアストリーミングは，映像入力機器が接続された計算機 から，映像出力機器が接続された計算機へ，映像データをインターネット経由で転送す ることによって実現されている．インターネットを用いたメディアストリーミングを行う 際には，送受信相互で，同じフォーマットに対応した機器とアプリケーションを用いなけ ればならない．また，送信元では，送信先のIPアドレスとポート番号をアプリケーショ ンで指定する必要があり，受信側では，アプリケーションを受信待機状態にする必要があ

1.2. 現状 第 1章 序論: 分散環境における映像配信とその管理

図 1.1: 映像コンテンツ制作，配信システムの例

S IP S e rv e r

図 1.2: Video会議

る．インターネットを用いたメディアストリーミングは，このような手順を踏むことによ り実現されている．メディアストリーミングを行う際の流れを，図1.3に示す．

メディアストリーミングは，はじめに，1)受信側のUser Bから送信側のUser Aに，受 信ノードNode BのIPアドレスを教える．2)User AはUser Bから教わったIPアドレス の情報を用いて，送信ノードとなるNode Aのメディアストリーミングアプリケーション

1.2. 現状 第 1章 序論: 分散環境における映像配信とその管理

図 1.3: メディアストリーミングの手順

で送信先を指定し，メディアデータの送出を開始する．3)User AはUser Bに，メディア データの送出を開始した旨を伝える．4)メディアデータの送出を伝えられたUser Bは，

受信ノードとなるNode Bのメディアストリーミングアプリケーションでメディアデータ の受信を開始する．5)以上の手順により，メディアストリーミングが開始される．

このように，インターネットを用いたメディアストリーミングにおいて，ユーザは電話，

電子メール，インスタントメッセンジャなどの別の手段を用いて，情報の共有や，状況の 通知などのコミュニケーションを取る必要がある．

しかし，メディアストリーミングをテレビ会議のような用途で，双方向で行う場合や，

複数のメディアストリーミングを同時に行う場合など，ユーザが取り扱い，管理をしなけ ればならない情報が増大し，利用時の負担となっている．

そのため，インターネットを用いたメディアストリーミングを行うために必要な情報を 蓄積し，蓄積した情報を元に，各計算機ノードの送受信の制御を行うことができる機構が 求められている．

1.3. 本研究の目的 第 1章 序論: 分散環境における映像配信とその管理

1.3 本研究の目的

本研究では，インターネットを用いたメディアストリーミングを行う際に発生するユー ザの負担を軽減するために，メディアストリーミングにおいて必要な情報の管理を，自動 的，かつ統一的に行い，管理している情報を元に，各計算機ノードの送受信の制御を可能 にする機構の構築を目的とする．

本機構の構築における目標を以下に挙げる．

• ユーザが事前に取得すべき情報をなくす

サービス探索を自動で行うことにより，ユーザが管理サーバの情報を取得する必要 をなくす．

• 運用時に必要な情報を減らす

本機構の運用側においても，事前に共有すべき情報をできるだけ減らす．

• メディアストリーミングに必要な情報を共有する

メディアストリーミングに必要な情報を，統一的に管理する．

1.4 本論文の構成

本論文は7章から構成される．第2章において，ネットワークを用いたメディアスト リーミング手法の課題として，アプリケーション，接続機器，ストリーミング技術，およ び接続管理のそれぞれについての課題を述べ，その上で，それらの問題点をまとめる．第 3章において，第2章で述べた課題における問題点を導き出し，その解決手法について述 べる．第4章において，その手法を実現するための設計に関して述べ，第5章で実装に関 して述べる．第6章において，本研究の実装を定性的・定量的な側面から評価する．最後 に第7章で本研究の結論と，今後の指針を述べる．

第 2 章 既存のシステムモデルと問題点

本章では，ネットワークを用いたメディアストリーミング手法の課題として，以下の6 点を挙げる．

• ネットワーク

 接続媒体としてインターネットを用いることに寄る問題点について述べる

• メディアフォーマット

 メディアフォーマットの多様性によって発生する問題点について述べる

• アプリケーション

 アプリケーションの多様性とその相互協調について述べる

• 接続機器

 接続機器の多様性と，その問題点について述べる

• 接続管理

 収録・接続環境に存在するネットワーク，メディアフォーマット，アプリケーショ ン，接続機器などを 統合的に扱うための接続管理手法について述べる

• 既存システム

 既存のストリーミングシステムを相互利用する際に発生する問題点について述 べる．

アプリケーション，接続機器，ストリーミング技術，および接続管理のそれぞれについ て議論を行う．その上で，それらの問題点をまとめる．

2.1 ネットワークにおける技術

ネットワークを取り扱う上で必要な技術には，IP[4]，UDP[5]，TCP[6]がある．

IPは，インターネットを用いる上で必要な基本的な技術であり，このプロトコルによっ て各ノードのネットワークインターフェイスにアドレスが付与される．現在運用されてい るIPにはIPv4とIPv6がある．IPv4とIPv6はそれぞれ別のアドレス体系を持っており，

ネットワーク上のルーティングなども別々に行われている．各ノードにおいても基本的 には別々に取り扱われる．そのため，同じバージョン間においてのみ通信が可能であり，

バージョン相互間の通信は不可能である．

2.2. メディアを取り扱うための技術 第 2章 既存のシステムモデルと問題点

TCP，UDPはIP層の上で動作する，トランスポート層のプロトコルである．TCPは

コネクション指向のプロトコルで，このプロトコルを用いると接続された2ノード間でコ ネクションが確立され，このコネクションの中で，輻輳制御や，欠損したパケットに対す る再送などの処理が行われる．このような処理を行うため，TCPはデータの確実性が求 められる転送で用いられる．UDPはコネクションレスのプロトコルで，このプロトコル を用いると送信元ノードは送信先ノードへデータの転送を制御なく行う．このため，UDP はリアルタイム性が求められる転送で用いられるが，再送は行われないのでデータの確実 性は保証されない．これらのトランスポート層のプロトコルは，それぞれ別の接続形態を とり，それぞれのプロトコルに基づいた転送を行うため，別のプロトコル間の通信は不可 能である．

2.2 メディアを取り扱うための技術

本節では現在インターネット上で多く用いられている映像フォーマットについて述べ，

その特徴を示す．

2.2.1 DV

DV(Digital Video)[1][7]は，1999年にHDデジタルVCR協議会により規格化されたフ レーム内圧縮方式を用いたフォーマットである．

画質はフルフレーム時で720×480×19.97f psであり，圧縮率は一定である．DVを構 成する最小単位は80バイトのDIF Blockであり，150 DIF Blockから構成される1 DIF Sequesnceという単位がある．1フレームは10 DIF Sequenceから構成される．DVのデー タ構成を図2.1に示す．

2.2.2 HDV

HDV(High Definition Video)[8]は2003年にCanon, Sharp, Sony, Victorにより規格化 されたフォーマットである．MPEG2[2]形式で圧縮されたデータをDV, mini-DVテープ に保存することができるようにしたものである．

MPEG2フォーマットは，フレーム間圧縮方式を用いたフォーマットである．MPEG[9]

におけるフレーム間圧縮の概要を図2.2に示す．MPEGではGOP(Group Of Picture)と呼 ばれる圧縮・再生・編集の単位となる数フレームから構成される．GOPで扱われるフレーム はIピクチャ(Intra Picture)，Pピクチャ(Predictive Picture)，Bピクチャ(Bidirectionally

Picture)から構成される．それぞれの概要を以下に示す．

• Iピクチャ

基準となるピクチャであり，単体で画像を復元できる．

2.2. メディアを取り扱うための技術 第 2章 既存のシステムモデルと問題点

Data in one video frame

DIF Sequence 0

DIF Sequence 1

DIF Sequence (n-1)

Header Section

Subcode Section

VAUX Section

Audio and Video Section

DIF block 0

DIF block 1

DIF block 2

DIF block 3

DIF block 148

DIF block 149

ID Data

0 3 Byte position number 79

. . . . . . . . DIF sequences

Structure of a DIF sequence

DIF blocks

Structure of a DIF block

n = 10 for 525-60 system n = 12 for 625-50 system

図 2.1: DV データ構成

• Pピクチャ

フレーム間順方向予測符号化画像とも呼ばれる．時間軸的に過去のIピクチャ，Pピ クチャからの相関情報で表現される．

• Bピクチャ

双方向予測符号化画像と呼ばれる．時間軸的に前後する画面からの相関情報で表現 される．

MPEG2のビットレートは2Mbpsから60Mbps程度まで幅広く存在する．DVと同じ

SDの画質を再現するために必要なビットレートは，4Mbpsから8Mbps程度である．ま た，VBR(Variable Bit Rate)の適用も可能である．

このようにMPEGフォーマットは前述したDVフォーマットに比べ，少ないビットレー トで多くの画像情報を保存する事ができる．

2.2.3 H.264

H.264[10]はITU-TとISO/IECが共同で策定した国際標準規格であり，MPEG-4 Part 10 AVCとも呼ばれる．従来のMPEG4[11]に比べ，30%から最大2倍の圧縮率を実現する．

DVと同じSDの画質を再現するために必要なビットレートは1Mbps以下である．H.264 に含まれる主な技術を以下に述べる．

2.2. メディアを取り扱うための技術 第 2章 既存のシステムモデルと問題点

図 2.2: GOP概要図

• 可変マクロブロックサイズ

MPEGでは，画面をマクロブロックという単位で分割する．MPEG2では16x16ピ クセル，MPEG4では8x8ピクセルであるが，H.264では4x4〜16x16ピクセルまで の様々なサイズを選択できる．エンコーダは映像の内容に合わせてマクロブロック の大きさを変更する．

• 遠隔参照フレーム

MPEG2，MPEG4では前後のフレームの差分のみを取っていたが，H.264では最大

5フレーム前のフレームの参照を行う．

• フレーム内予測

Iフレームに対し，類似するマクロブロックを探し，その差分を取って圧縮する．

• ループフィルタ

従来のMPEGでは，デコード後の画像に対し，フィルタ演算をすることでブロック ノイズの削減を行なうことができた．H.264では，エンコード時にフィルタ演算を 踏まえたエンコードを行う．これにより，特に低ビットレート時のブロックノイズ 減少に効果がある．

2.2.4 異なるフォーマット間の相互利用

メディアを取り扱う上で必要な技術には，エンコードとトランスコーディングがある．

メディアを取り扱う機器から入力されるデータは様々である．映像や音声など，メディ アの元データはアナログであることが多い．しかし，計算機を用いたメディアストリーミ ングではアナログデータをそのまま扱うことはできない．そのため，アナログデータから デジタルデータへのエンコードが必要である．デジタルAVフォーマットには様々なもの

2.2. メディアを取り扱うための技術 第 2章 既存のシステムモデルと問題点

がある．映像であれば，DVやMPEG2などが挙げられる．それらの変換されたデジタル AVフォーマットは，同じフォーマットに対応した機器やアプリケーションを用いなけれ ば復号化できない．

また，符号化したデータを復号化する際の出力形態は様々である．機器に依存した形態 であったり，出力先の計算機資源によっても変化する．そのために，符号化したデータを 相手の出力形態にあったデータフォーマットに変更するためのトランスコーディングが必 要になる．トランスコーディングの様子を図2.3に示す．

DV Encoder DV-MPEG2 Trance coder DVフォーマット MPEG2フォーマット

アナログ映像 DVフォーマット

DV decoder MPEG2 decoder

図 2.3: トランスコーディング

しかし，トランスコーディングを行う際には相手の出力形態を予め知っておく必要があ る．また，トランスコーディングには多くの計算機資源を必要とするため，計算機資源の 少ないノードにおいて行われるべきではない．

このように，ネットワークを用いたメディアストリーミングにおいては，様々な技術が 用いられている．現状ではメディアストリーミングを行う際には，双方で同じ技術を用い る場合が多く，メディアストリーミングを行う双方で，人間による別の手段を用いた上で のコミュニケーションが必須となっている．

2.3. アプリケーションにおける課題 第 2章 既存のシステムモデルと問題点

2.3 アプリケーションにおける課題

ネットワークを用いたメディアストリーミングを行うアプリケーションには様々なもの がある．ここでは，例としてSkype，MSN Messenger，iChat AV，Polycom，DVTSを挙 げそれぞれのアプリケーションにおけるメディアストリーミングの特徴を挙げる．

2.3.1 Skype

Skype[12]は，Skype社によって開発されたアプリケーションで，ネットワークを用い

た音声，映像，文字による通信を可能にしている．Skypeでは，アプリケーションによっ て管理されたフレンドリストにより，通信相手の接続状況を確認することができる．各 ノードの接続状況は，独自のP2Pネットワークにおいて交換され，それによって得られ た情報をユーザに示す．

2.3.2 MSN Messenger

MSN Messenger[13]は，Microsoft社によって開発されたアプリケーションで，ネットワー クを用いた音声，映像，文字による通信を可能にしている．MSN Messengerは，Microsoft 社によって運営される専用サーバにユーザの接続状況を蓄積する．ユーザは，専用サーバ から自分のアカウントに登録されているコンタクトリストの内容を取得し，通信相手の 接続状況を確認することができる．文字による通信は専用サーバを経由して行われるが，

映像，音声による通信はユーザ同士で直接行われる．

2.3.3 iChat AV

iChat AV[14]は，Apple社によって開発されたアプリケーションで，ネットワークを用

いた音声，映像，文字による通信を可能にしている．iChat AVは，Apple社によって運 営される専用サーバと，AOL社によって運営されるAIMとの共用サーバの双方を利用し てユーザの接続状況を蓄積する．ユーザは，専用サーバから自分のアカウントに登録され ているコンタクトリストの内容を取得し，通信相手の接続状況を確認することができる．

2.3.4 Polycom

Polycom[15]は，Polycom社によって開発されたアプリケーション，および機器で，映像 による双方向のビデオ会議を可能にしている．Polycomでは，直接接続先のIPアドレスと 品質を指定することにより，通信を開始する．また，Polycom専用のディレクトリサービ スがあり，そのサービスを用いて通信相手を指定することも可能である．映像のフォーマッ トはH.261，H.263+，H.263++，H.264が用いられ，音声にはG.722.1 AnnexC (Polycom Siren 14)，G.722[16]，G.722.1[17]，G.711[18]，G.728[19]，G.729A[20]，セッションの開 始にはH.323[21]およびH.320，SIP[22]が用いられている．

2.3. アプリケーションにおける課題 第 2章 既存のシステムモデルと問題点

2.3.5 DVTS

DVTSは，DVを用いて映像の通信を可能にするアプリケーションである．転送される 映像の制御には，RTP，RTCPが用いられている．用いられる映像フォーマットはDVで ある．DVTSにおける，セッション情報を管理，操作する機構にDV Session Manager[23]

がある．DV Session Managerについては，次項で詳しく述べる．

2.3.6 DV Session Manager

DV Session Managerは，PowerPlay社が販売するシステムであり，同社の販売する Smart Location Systemという，DVTSの送受信に特化したノードをWebを用いて一括 管理し，また，Smart Location Systemに対しての操作を可能にすることにより，登録さ れたSmart Location System間のDVTSセッションの操作を可能にしたものである．DV Session Managerのシステムの概要を図2.4に示す．

図 2.4: PowerPlay社 DV Session Manager

このシステムでは，Smart Location Systemが起動された際にClient用のdaemonが動 き，設定ファイルに記述された方法にしたがって，DV Session Managerへ自ノードの情 報を登録する．この際，情報の交換はhttpsを用いて行われる．登録された情報は，DV Session Managerに外部からWebアクセスをすることにより閲覧可能で，表示されたWeb ページからSmart Location Systemの送信、受信、再起動、シャットダウンの操作を行う

2.3. アプリケーションにおける課題 第 2章 既存のシステムモデルと問題点

ことが可能である．個々のSmart Location Systemは，それぞれ独自のIDを持っており，

これによってDV Session Managerは機器を識別する．

しかし，DV Session Managerでは，基本的に専用のSmart Location Systemで用いられ ることを想定しており，他の個人の計算機を登録することはできない．また，ClientはDV

Session Managerのアドレスが予め登録されていなければ動作できないので，ある一ヶ所

に，固定のDV Session Managerを設置し，その上でDV Session ManagerのIPアドレス をユーザ間で共有しておかなければならない．また，現在DV Session ManagerはDVTS のみに対応しており，多フォーマットで取り扱うことはできない．

このように，DV Session Managerは閉じた環境での利用が想定されている．そのため，

個人用の計算機など，専用ノード以外を登録して利用することが困難となっている．

2.3.7 複数アプリケーション混在環境における課題

このように，様々なネットワークを用いたメディアストリーミングを行うアプリケー ションが存在するが，それぞれのアプリケーション間における通信はできない．そのた め，メディアストリーミングを行うにあたって用いられるアプリケーションを，予め通信 をするユーザ間で共有しておく必要がある．また，様々なアプリケーションを有効に活用 するために統合的な管理機構が必要である．

前節で述べたように，ネットワークを用いたメディアストリーミング技術には，様々な 運用上の課題がある．ネットワークを用いたメディアストリーミングでは，様々な技術が 組み合わされて成り立っており，各々の技術は，基本的に相互接続性がない．そのため，

今まではどの技術を使うかという情報は，メディアストリーミングに用いる手法とは別の 手段によって，各拠点のユーザ間で共有しておく必要がある．また，その情報を共有した 上で，ユーザによってその情報を反映させ，運用を行う必要がある．

各アプリケーションにおける，以下の各項目に対する実現状況を表2.1に示す．

• 自動登録

管理サーバへの登録が自動化されているか

• 移動透過性

移動に伴うIPアドレスの変更に柔軟に対応可能か

• 複数フォーマット

複数フォーマットを相手の状況によって使い分けることが可能か

• 多様な機器

多様な機器を用いた出入力に対応しているか

• 多様な機能

送受信以外の機能に対応しているか

このように，本章で挙げた各アプリケーションは，多様な用途で用いられるメディアス トリーミングに対し，柔軟な対応ができていないということがわかる．

2.4. 接続機器における課題 第 2章 既存のシステムモデルと問題点

表 2.1: 各アプリケーションの実現状況

自動登録 移動透過性 複数フォーマット 多様な機器 多様な機能

Skype × ○ × × ×

MSN Messenger × ○ × × ×

iChat AV × ○ × × ×

Polycom × × × ○ ×

Session Manager ○ × × × △

2.4 接続機器における課題

収録・再生環境の多様化が進んでいる．収録・再生環境の概要図を図2.5に示す．か つての収録・再生環境におけるコンテンツの流れは，放送を受信・録画する，ビデオに記 録されたデータを再生する，といった限定的なものであった．しかし現在では，HDDに 保存したものをネットワークを用いて再送する，ネットワークから取得したものをトラン スコーディングした上でディスクに保存する，といったように，様々なコンテンツの流れ が存在する．収録・再生環境は大きく以下の3つに分ける事ができる．

1. 入力処理

収録機器からの入力や，ネットワーク伝送などの，コンテンツ入力の為の処理が含 まれる．

2. 内部処理

出力先に適した形に変更する為の処理が含まれる．トランスコーディングなどの他 にディスクから読み取ったデータをネットワーク伝送する為にIPヘッダを付加する などのステップも含まれる．

3. 出力処理

再生機器への出力や，HDDへの書き出し，ネットワーク伝送といったコンテンツ出 力の為の処理が含まれる．

このように収録・再生環境によってコンテンツが処理される手法やステップ数は多用で ある．今後もこうした収録・再生環境の多様性は広がりを続けるものと考えられる．

ネットワーク上でのストリーミング管理を行うためには，メディアストリーミングを行 うアプリケーションにおいて，接続された機器を適切に設定する必要がある．また，機器 に依存した映像フォーマットがあるため，メディアストリーミングにおいて取り扱う映像 フォーマットの情報を，予めストリーミングを行う双方において，別の手段を用いて共有 する必要がある．

2.5. 接続管理における課題 第 2章 既存のシステムモデルと問題点

図 2.5: 収録・再生環境

2.5 接続管理における課題

ネットワークを用いたメディアストリーミングにおいて，接続を行うにあたって必要な 情報が多数ある．たとえば，複数地点間におけるメディアストリーミングを行うにあたっ ては，双方のIPアドレス，メディア転送に用いられるポート番号などが挙げられる．これ らの情報は，接続を行う前に予め別の手段によって，各地点のユーザ間において共有しな ければならない．この情報共有を自動的に行う手法としては，Skypeや，MSN Messenger，

Polycomなどが用いているディレクトリサービスがある．Skypeにおいては，これらの情

報は独自のP2Pネットワークにおいて交換される．また，MSN Messenger，Polycomに おいては，それぞれの独自のサーバに情報が蓄積され，この情報を共有するという手法が 用いられている．しかし，これらのどのサービスにおいても，専用のアプリケーションを 用いることによって利用できるものである．そのため，情報の共有や利用という観点にお いて，サービスの中に閉じられてしまっているため，他のサービスから利用することはで きない．

また，ネットワークを使ったメディアストリーミングにおいては，接続を希望する相手 先ノードが別のノードと接続中である場合，資源の問題などにより新たな接続を行うこ とが困難であることが多い．しかし，現状のシステムではそこまでの情報の管理は為され ていないため，相手先ノードの資源利用状況の把握は困難である．そのため，現状では接

2.6. 問題点のまとめ 第 2章 既存のシステムモデルと問題点

続可能か否かの判断を各ノードにいる人間の間で，別途コミュニケーションを取る必要が ある．

2.6 問題点のまとめ

これまでに述べたように，ネットワークを用いたメディアストリーミング技術には，様々 な運用上の課題がある．ネットワークを用いたメディアストリーミングでは，様々な技術 が組み合わされて成り立っており，各々の技術は，基本的に相互接続性がない．そのため，

今まではどの技術を使うかという情報は，メディアストリーミングに用いる手法とは別の 手段によって，各拠点のユーザ間で共有しておく必要があった．以下に，ネットワークを 用いたメディアストリーミングを行う上で必要な情報を挙げる．

• 利用可能アプリケーションの情報

• 利用可能機器の情報

• 利用可能メディアフォーマットの情報

• 接続ノードのIPアドレス

• 接続ノードの利用状況

また，その情報を共有した上で，ユーザによってその情報を反映させ，運用を行う必要 があった．そのため，それらの情報を統一的に管理し，活用するためのシステムが必要で ある．

第 3 章 アプローチ

本章では，2章で述べた，既存のモデルの問題点をふまえ，分散環境におけるネットワー クストリーミング管理制御機構を提案する．その上で，実現のために必要なアプローチを 述べ，具体化する．

3.1 ネットワークストリーミング管理制御機構の提案

本節では，2.6節で述べた問題点をふまえた上で，分散環境におけるネットワークスト リーミング管理制御について議論し，そのシステムの提案を行う．

2.6節で述べた点をふまえ，様々な計算機がネットワーク上に分散して存在する環境に おける，ネットワークストリーミングを円滑かつ容易に行うことのできる環境を実現する ためのアプローチを述べる．

3.1.1 本機構の目標

1.3節で述べた目的を満たすシステムに必要な要件を以下に挙げる．

• ユーザの負担を軽減する

オペレータの補助により，ユーザによる情報の入力を可能な限り減らし，機器の設 置を行うだけでメディアストリーミングの運用を可能とする．

• 共有すべき情報をできるだけ少なくする

ネットワークを用いたメディアストリーミングを行う際に必要な情報の収集を自動 化し，オペレータにおいても共有すべき情報を最小限に抑えた上で，メディアスト リーミングの運用を行うことができるようにする．

• メディアストリーミングに必要な情報の集約，閲覧，操作

上記の事項を実現した上で，ネットワークを用いたメディアストリーミングを行う 上で必要な情報を集約し，閲覧，およびその情報を用いて各ノードの操作を可能に する．

これらの要件を満たすことにより，本システムを実現する．

3.1. ネットワークストリーミング管理制御機構の提案 第 3章 アプローチ

3.1.2 システムの提案

3.1.1項で述べた目標を達成するための，システムのモデル図を図3.1に示す．

図 3.1: 提案するシステムのモデル

本研究で提案するシステムにおけるメディアストリーミング開始の手順を以下に示す．

1. メディアストリーミングに用いられるノードが，自身の存在するネットワーク内の 管理サーバを探索し，発見した管理サーバに自ノードの機器情報を登録する 2. 各ネットワークドメインに存在する管理サーバ同士で，管理しているノード情報を

交換する

3. ユーザは，最寄りの管理サーバにアクセスし，管理されているノード情報をもとに 操作を行う

4. 管理サーバは，ユーザが操作を要求するノードが所属するネットワークの管理サー バに，ユーザの要求を伝える

5. 管理サーバが，ユーザが操作を要求するノードへ制御情報を送信する

6. 管理サーバから制御情報を受信したノードが，適切なアプリケーションを用いてメ ディアストリーミングを開始する

3.1. ネットワークストリーミング管理制御機構の提案 第 3章 アプローチ

本システムを実現するために必要な機能を挙げ，その実現方法を以下で述べる．

ノードの資源情報の収集

2.6節で述べたように，現状ではネットワークを用いたメディアストリーミングを開始 する前に，様々な情報を収集し，それを予め交換しなければならない．そのような情報を 予め収集しておき，情報を管理するサーバに蓄積しておく．これにより，予めユーザが別 の手段で情報を交換することなく，ネットワークを用いたメディアストリーミングを行う ことが可能となる．

この情報を蓄積するサーバを”Manager”と定義し，メディアストリーミングにおいて必 要な情報を各ノードにおいて管理するサービスを”Client”と定義する．

情報収集サーバの配置

ネットワークを用いたメディアストリーミングにおいて必要な情報を，Clientが各ノー ドに常駐することによって収集することが可能になった．しかし，それらの情報を蓄積す

るManagerへ情報を送信する際に，Managerがある一定の場所においてのみ設置されて

いる環境では，ManagerのIPアドレスを予め知っておく必要がある．

そのため，Managerをメディアストリーミングが行われる各ネットワークに配置する．

これによりClientは，Local Areaにおけるサービス探索を行うことが可能となり，予め

Managerのアドレスを取得しておく必要がなくなる．また，Managerは自身の存在する

ネットワークの情報のみ収集することが可能なので，ネットワークの属性情報を各ノード の情報に付加することができる．これにより，ノードの所属情報，およびおおまかな所在 情報を識別することが可能となる．

Managerのアドレスを自動的に取得できることにより，エンドノードのIPアドレスの

変更が発生した場合や，ノードが移動した場合にも，ユーザが設定を変更することなく，

運用を行うことが可能となる．

情報収集サーバ間における情報共有

ManagerはClientによるサービス探索のために，メディアストリーミングが行われる

ネットワークごとに配置した．そのため，他ネットワークに存在するノードとのメディ アストリーミングを行いたい場合には，他ネットワークのManagerに蓄積された情報が 必要となる．そのため，本機構ではManager間で情報の交換，共有を行う．これにより，

各ネットワーク内のManagerにアクセスすることで，他ネットワークを含め，すべての

Managerで管理されるノードの情報の閲覧，管理，操作が可能となる．

本機構では，この情報交換にIP Multicastを用いる．ASM(Any Source Multicast)を用 いて，特定のマルチキャストアドレスをグループ内で共有し，同じマルチキャストアドレ スに対して情報を送信することにより，グループ内でManagerのIPアドレスを別の手段

3.1. ネットワークストリーミング管理制御機構の提案 第 3章 アプローチ

で予め交換することなく，情報の共有を行うことが可能になる．これにより，共有すべき 情報がマルチキャストアドレスのみで良いことになる．

情報収集サーバに蓄積された情報の視覚化

Managerは，自ネットワーク，他ネットワークを含め収集された情報を，Web Interface により視覚化することで，ユーザからの操作を可能にする．また，ユーザによって，各 ノードに付加的な情報を加えることも可能にする．

情報収集サーバによる各ノードの操作

ClientはManagerと，生存確認のために起動中はずっと接続を保っている．この接続

を用いて，Managerで視覚化されたClient情報を元にユーザが操作を行い，その操作に 応じた命令をClientに送信する．Clientはその送信された情報を元に，メディアストリー ミングに用いられるアプリケーションの起動，操作を行い，メディアストリーミングを開 始することが可能となる．メディアストリーミングの終了時も同様に，ユーザの操作に応 じてManagerからClientへ命令が送信され，Clientはメディアストリーミングの終了操 作を行う．

第 4 章 ネットワークストリーミング管理 制御機構の設計

本章では，3章で述べた目的を達成するために必要な設計を行う．

4.1 設計要件

必要になる要件と，それを満たすための機能を以下にまとめる．

• Clientによる，Managerの自動探索

• Manager間の情報共有および同期

• Managerの情報の閲覧，および，操作のインターフェイス

• ManagerからClientの制御

4.2 設計概要

本節では，前節の要件と機能を実装するために行った設計の概要を述べる．図4.1に設 計の概略図を示す．本実装は，大きく分けてサービス解決，情報共有，操作と制御の3パー トに分けられる．以下で，各パートの詳細を述べる．

4.3 Client のサービス解決

ClientによるManagerのサービス解決は自動で行われる必要がある．そのために必要

な通信の手順を以下で定義する．

4.3.1 サービス解決概要

サービス解決は，以下のような手順で行われる．

1. Link Localの通信によるManagerの呼び出し

4.3. CLIENTのサービス解決 第 4章 ネットワークストリーミング管理制御機構の設計

N e tw o rk B = P la c e B

N e tw o rk A = P la c e A

M a n a g e r A

P C 1

T y p e : M e d ia S e n d e r /

M e d ia R e c e iv e r

F o rm a t: D V M a n a g e r B

P C 2

T y p e : M e d ia S e n d e r /

M e d ia R e c e iv e r

F o rm a t: M P E G - 2 (S e n d / R e c v ) /

D V (R e cv ) S to ra g e 1

T y p e : M e d ia S to re r

F o rm a t: M P E G - 2 / D V D isp la y 1

T y p e : M e d ia R e c e iv e r

F o rm a t: M P E G - 2 / D V

E x c h a n g e In fo rm a tio n R e g is t

F e e d In fo r m a tio n

C o n tro l

U s e r 1 U s e r 2

S tre a m

図 4.1: システムモデル

2. Managerの応答

3. Clientからの情報の登録 4. ManagerからのAck

5. Client - Manager間のkeepalive

4.3.2 通信の詳細

サービス解決の際に行われる，通信の様子を図4.2に示す．

Clientは，Managerの発見のために，Link Localの通信のよりManagerを呼び出す．

Managerは，MGR RESOLVを受信すると，送信者に対してMGR ACKを返し，自分のIP アドレスをClientに対して通知する．Clientは，取得したManagerのIPアドレスに対 して接続をし，登録要求MGR REQUESTを送信する．その返答としてMGR ACKを受信 すると，Managerへ自身のノード情報をMGR REGISTとして送信する．Clientが，MGR ACKを受信する事により，ClientのManagerへの情報の登録作業を完了する．

Clientは，情報の登録作業が完了したら，Managerとの間で，一定間隔でkeepaliveの パケットを交換することにより，Clientの生存確認を行う．

4.3. CLIENTのサービス解決 第 4章 ネットワークストリーミング管理制御機構の設計

図 4.2: Service resolution : diagram

4.3.3 Client 情報のデータ構造

ネットワークを用いたメディアストリーミングを行うために必要な情報を，Managerに 蓄積する．その際に，Managerで扱われる情報を，表4.1に示す．

表 4.1: Managerで扱われる情報

要素 格納情報 例

MANAGER Manager識別子(IPアドレス) 203.178.xxx.xxx NODE ノード識別子(IPアドレス) 203.178.xxx.xxx

FUNCTION 映像転送における機能 send, recv

FORMAT 映像転送で利用可能なフォーマット DV, MPEG2

DEVICE 映像の出入力に用いられる機器 DV Cam, Display

また，Managerにおいて，上記のようなClientのノード情報は図4.3のような構造で管 理される．

このようなデータ構造に基づき，ClientはMGR REGIST送信の際に，Managerへ図4.4 のような記述で自身のノード情報を送信する．

4.4. MANAGERにおける処理第 4章 ネットワークストリーミング管理制御機構の設計

N O D E A S e n d

R e c e iv e D V

M P E G 2 D V C a m

H D V C a m

D V

M P E G 2

R a w H D D V D e v ic e

D is p la y

1 3 9 4 D e v ic e

D is p la y

S D I O u t

N O D E F U N C T I O N F O R M A T D E V IC E

図 4.3: Client node information : Data Structure

¶ ³

Function,Format,Output(,port number)

µ ´

図 4.4: Client node information : Node information description

MGR REGISTメッセージ送信の際に，ノード情報を1行につき1つずつ記述する．ア プリケーションがデフォルトで用いるポート番号以外のポートを用いる場合には，追加し て記述する．ノードが複数のFunction，Format，および，Outputに対応している場合に は，複数行に渡って記述を行う．ノード情報を記述する前の行に，Clientノードのこのシ ステムで用いるホスト名を記述する．また，最終行の次の行には，終端文字として”.”を 挿入する．図4.3に対応するデータ送信の記述は，図4.5に示す．

Clientにおいて，扱うことのできるストリーミングの情報が変化した場合には，自身の

情報を再度送信し，再登録する．

4.4 Manager における処理

Managerにおいて行われる処理は，Client情報の受信，Manager間の情報共有，Client 情報の視覚化，および，Clientへの操作情報の送信の4つである．以下では，各々の処理 の設計を述べる．

4.4.1 Client 情報の受信

Managerは，Clientから受信したノード情報を次のように処理する．

4.4. MANAGERにおける処理第 4章 ネットワークストリーミング管理制御機構の設計

¶ ³

MGR REGIST hostname

Send,DV,DV Cam Send,MPEG2,HDV Cam Recv,DV,DV Device Recv,DV,Display

Recv,MPEG2,1394 Device Recv,MPEG2,Display

Recv,Raw HD,SDI Out,10001

µ. ´

図 4.5: Client node information : Node information description : Sample

Managerは，ClientからMGR REGISTメッセージを受信すると，その後の行から記述 されているノード情報を読み込み，データベースへ格納する．この際に，それぞれの情 報に一意なIDと，メッセージの送信元IPアドレスを追加する．受信したMGR REGIST メッセージが複数回目であった場合には，メッセージの送信元IPアドレスをキーとして，

データベースから登録済み情報を削除し，再度，受信したノード情報のデータベースへの 格納を行う．

ノード情報の受信後は，接続されたソケットを保持し，keepaliveパケットの交換を一 定間隔おきに行う．一定回数keepaliveに返答がない場合には，そのソケットにバインド されているIPアドレスをキーとして，データベースから登録情報を削除する．また，こ のソケットは，ManagerからClientを制御する際に使用される．

4.4.2 Manager 間の情報共有

Managerは，自分のLocal Area Network内で得られたClient情報を，他Managerと共 有するための動作を以下に述べる．

Managerは，収集したClientのノード情報を他Managerと交換するために，予め共有 されたマルチキャストアドレスにJoinする．その後に，そのマルチキャストアドレスに対 してMGR JOINメッセージと，自身のデータベースに格納されている全ノード情報を送信 する．また，他ManagerからのMGR JOINメッセージを受信した場合には，そのManager へ自身の保持する全ノード情報を送信する．受信した他Managerのノード情報は，自身 の管理するノード情報とは別テーブルに格納する．この際，受信したノード情報に，一意 なIDと情報送信元ManagerのIPアドレスを追加する．

Managerの保持するノード情報に変化があった場合には，MGR CHANGEメッセージと

変更情報を，情報共有に用いられるマルチキャストアドレスに送信する．変更情報を受信 した際には，他Manager情報が格納されているテーブルに変更情報を反映する．

4.4. MANAGERにおける処理第 4章 ネットワークストリーミング管理制御機構の設計

4.4.3 Client 情報の視覚化

Managerは，収集し，データベースに格納されたClientのノード情報をWebによりユー ザへ提供する．ユーザは，この画面を用いて，管理されているノードの操作，制御を行う．

4.4.4 Client への制御情報の送信

Managerは，Web Interfaceを通じて行われたユーザの操作に基づき，Clientへ制御情報 の送信を行う．Clientは，この情報に基づき，各メディアストリーミングアプリケーショ ンの操作を行う．

第 5 章 ネットワークストリーミング管理 制御機構の実装

本章では，4章で述べた設計をもとに，ネットワークストリーミング管理制御機構の実 装について述べる．

5.1 実装概要

本研究では，インターネットを用いたメディアストリーミングに必要な情報を集約し，

集約した情報をWebを用いて閲覧可能にし，ユーザがWebインターフェイスを用いて，

メディアストリーミングに用いられるノードの操作を可能にする機構の実装を行った．

本機構は，その実装において大きく分けて，ネットワークストリーミングに必要な情報 を収集，登録し，送受信の制御をされるClientと，Clientの情報を蓄積，および交換を行 い，その情報に基づきClientの制御を行うManagerの2要素で構成される．

5.2 Client

本節では，ネットワークストリーミングに必要な情報を収集，登録し，送受信の制御を

されるClient部の実装について述べる．

Clientは，機器情報の取得部，Managerとの通信部，アプリケーションの制御を行う

制御部によって構成される．基本的な処理の流れは，まず機器情報を取得し，自ノード のメディアストリーミングに関わる情報を収集し，Managerへ送信可能な形にまとめる．

その後に，通信部がManagerのサービス探索を行い，ManagerのIPアドレスを取得し，

記録する．記録したManagerのIPアドレスに対してコネクションを張り，Managerに取 得部によってまとめられた自ノード情報を送信し，登録する．登録処理の完了後は，登 録時に張ったコネクションを切断せずに，keepaliveメッセージの交換を一定間隔で行う．

Managerからネットワークストリーミングの送受信開始の制御情報を受信したら，制御

部が受信した情報を処理し，アプリケーションにパラメータを与えた形で実行し，送受信 停止の制御情報を受信したら，制御部はアプリケーションの終了処理を行う．Clientの終 了時には，通信部がManagerへ登録解除メッセージを送信し，Clientを終了する．

以下各項で，各部の実装について述べる．

5.2. CLIENT 第 5章 ネットワークストリーミング管理制御機構の実装

5.2.1 実装環境

本機構におけるClient部の実装環境を表5.1に示す．

表 5.1: Client部: 開発環境 OS Linux kernel 2.6 開発言語 C言語 コンパイラ gcc 4.0.1 メディア転送 DVTS アプリケーション MPEG2-TS

5.2.2 取得部

取得部では，自ノードの機器情報を取得し，Managerへ登録可能な形に整形する．本実 装では，機器情報を機器情報設定ファイルから取得する．デフォルトの機器情報設定ファ イル名は，”node info.conf”とする．

5.2.3 通信部

通信部では，大きく分けて以下の処理を行う．

• サービス解決

Managerのアドレスを自動的に取得

• Managerとの通信

4.3.2項で述べたManagerへの登録処理，およびManagerとのkeepalive，Manager からの制御情報の受信

5.2.4 制御部

制御部では，Managerから受信した制御情報に基づき，メディアストリーミングに用 いられるアプリケーションの操作，および終了を行う．この際，Managerへは出入力機器 名を用いて登録しているため，出入力機器名と実行環境におけるデバイスファイル名との 対応情報をファイルから取得する．デフォルトの対応情報ファイル名は，”device.conf”と する．

5.3. MANAGER 第 5章 ネットワークストリーミング管理制御機構の実装

5.3 Manager

本節では，Clientの情報を蓄積，および交換を行い，その情報に基づきClientの制御を

行うManager部の実装について述べる．

Managerは，Clientのサービス探索への応答部，Clientとの通信部，Clientのノード情 報管理部，Manager間の情報交換部，Web Interface部によって構成される．基本的な処 理の流れは，Clientからのコネクションを通信部が受け付け，Clientのノード情報を受信 する．情報管理部が，受信したClientのノード情報を処理し，データベースに情報を格 納する．情報交換部は，予め指定されたマルチキャストグループアドレスへJoinし，自 Managerが保持するClientのノード情報を送信し，また，他ManagerのClientのノード 情報を受信する．情報交換部が受信した他ManagerのClientのノード情報も，情報管理 部によってデータベースに格納される．Web Interface部は，データベースに格納された ノード情報を，Webから閲覧可能な形にする．Web Interfaceは，Clientノードを操作す る機能をもち，ユーザが操作をすると，情報管理部によりユーザの操作に対応するノード の情報が参照され，その情報に基づき，通信部がClientへ制御情報を送信する．

以下各項で，各部の実装について述べる．

5.3.1 実装環境

本機構におけるManager部の実装環境を表5.2に示す．

表 5.2: Manager部: 開発環境

OS Linux kernel 2.6

通信部開発言語 C言語 コンパイラ gcc 4.0.1

Web server Apache 2

Webインターフェイス開発言語 PHP 4 データベース MySQL

5.3.2 応答部

応答部では，Clientが送信したサービス探索リクエストを受信すると，リクエストに応 答し，Clientに自身のアドレスを通知する．

5.3.3 通信部

通信部では，Clientとの通信を行い，Clientからの登録要求の受付，およびClientとの keepalive，Clientへの制御情報の送信を行う．

5.3. MANAGER 第 5章 ネットワークストリーミング管理制御機構の実装

5.3.4 情報管理部

情報管理部では，Clientや他Managerから受信したノード情報を処理し，データベー スに格納する．

情報管理部によって管理されるデータベースのテーブル構成を表5.3に示す．

表 5.3: database: MANAGER

table 説明

MANAGER INFO 他Manager情報

NODE INFO 自Managerで管理しているClientノード情報 FOREIGN NODE INFO 他Managerが管理しているClientノード情報

また，それぞれのテーブルにおける，フィールド構成をそれぞれ表5.4，表5.5，表5.6 に示す．

表 5.4: table: MANAGER INFO

Field Type 説明

manager id bigint 一意なID

manager addr varchar 情報を管理しているManagerのIPアドレス manager hostname varchar Managerのホスト名

表 5.5: table: NODE INFO

Field Type 説明

id bigint 一意なID

address varchar Clientノードのアドレス

hostname varchar 本機構で用いられるClientノードのホスト名

function varchar 映像転送における機能

format varchar 映像転送で利用可能なフォーマット

device varchar 映像の出入力に用いられる機器

port int ポート番号(optional)

subscribe date timestamp 登録日時

out av int 送信構成フラグ

in av int 受信構成フラグ

in use bigint 使用状況

5.3. MANAGER 第 5章 ネットワークストリーミング管理制御機構の実装

表 5.6: table: FOREIGN NODE INFO

Field Type 説明

id bigint 一意なID

manager id bigint 情報を管理しているManagerのID foreign id bigint 管理しているManagerでのID

address varchar ClientノードのIPアドレス

hostname varchar 本機構で用いられるClientノードのホスト名

function varchar 映像転送における機能

format varch