JP4654407B2 - サーバ・ソケットで受け取ったイベントを扱うための方法および装置 - Google Patents

Description

【０００１】
（発明の背景）
本発明はコンピュータ・システムの分野に関する。より詳細には、複数のクライアント接続が共用しているサーバ・ソケットで受け取ったイベントを扱うための方法および装置が提供される。
【０００２】
コンピュータ・システムは、他のコンピュータ・システムとの通信を扱うためにソケットを作成して使用する。サーバなどのいくつかのシステムは、自らが通信しなければならない他のコンピュータ・システム（例えば、クライアント）が多数あるので、多数のソケットを確立するように構成されている。コンピュータ・サーバは、通信する各クライアント・システムごとに複数のソケットをセットアップし、専用にすることもある。その理由は、各ソケットが、１つのタイプの接続だけを扱う、１つの通信プロトコルだけを扱う、１つのタイプのタスクだけをディスパッチするなどのように、限られた機能性を有するように構成できるからである。
【０００３】
例えば、ＱｕｉｃｋＴｉｍｅメディアをクライアントにストリーミングするように構成されたサーバでは、１つのサーバ・ソケットを、制御機能を扱うように（例えば、ＲＴＳＰ（Real-Time Streaming Protocol）を使用して）各クライアント・メディア・ストリームに割り振り、別のソケットを、メディアをクライアントに伝送するために（例えば、ＲＴＰ（Real-Time Transport Protocol）に従って）割り振り、さらに別のソケットを、クライアントからステータス情報を受け取るように（例えば、ＲＴＣＰ（Real-Time Transport Control Protocol）を介して）割り振ることができる。
【０００４】
ただし、そのようなシステムは、クライアントの数が増加するにつれ、サーバが維持しなければならないソケットの数も比例して増加するので、拡張可能性が限られる。また、各ソケットには、通常、プロセッサ・リソースの応分の割合が（例えば、専用スレッドの形態で）割り振られるので、プロセッサ時間に対する結果の競合により、サーバが扱うことができるソケットまたはクライアントの数に上限が課される。個々のソケットまたは個々のメディア・ストリームに対してプロセッサ時間を要求する多数のプロセス、スレッド、デーモン、またはその他のエンティティが存在するため、サーバは、コンテキストスイッチを行うことに尋常でない多くの時間を費やす。また、他の非メディア・タスクには必要なリソースが拒否される可能性がある。
【０００５】
他のシステムは、クライアント通信を扱うすべてのソケットの間で、または特定のタイプまたは形態のクライアント通信を扱うすべてのソケットの間で、１つのプロセッサ・スレッド、またはプロセッサ時間の１期間を割り振ることにより、この競合および拡張可能性の欠如を回避しようと試みる。しかし、メディア・ストリームおよびソケットの数が増加するにつれ、所与のソケットまたは所与のストリーム（特にリアルタイム・メディア・ストリーム）に不十分なリソースが割り振られる危険が存在する。
【０００６】
（概要）
したがって、本発明の一実施態様では、サーバが、クライアントまたは他のコンピュータ・システムと通信する複数のソケットの間でサーバの処理能力を（例えば、実行スレッドの態様で）共用する装置および方法が提供される。サーバを、クライアントに対してメディアをストリーミングする、データを取り扱う、またはその他のサービスを提供するように構成することが可能である。また、複数のクライアント接続を単一の共用ソケットを介して確立する、または管理することが可能である。
【０００７】
この実施態様では、サーバ・ソケットを複数の集合に配分し、各集合に１つまたは複数のスレッドが割り振られるようにすることが可能である。イベント（例えば、接続要求、メディア・ストリーミング・コマンド、データ・パケット、データ要求）をソケットで受け取ったとき、スレッドは、そのイベントをソケットの登録されたコンシューマに渡す。コンシューマは、必要なタスクを発行または実行することによってイベントを扱うように構成されている。例えば、複数の通信接続の間で共用されるソケットでイベントを受け取ったとき、担当するコンシューマが、受け取ったイベントのタイプを特定すること、そのイベントを開始したクライアントまたは他のエンティティを特定することなどを行うことが可能である。
【０００８】
一実施態様では、特定のソケット・コンシューマが、イベントを扱うための基本インターフェースを提供するアブストラクトベースのクラスから導出され、特定のタイプのイベント（例えば、新しいクライアント接続、メディア・ストリームのクライアント要求、メディア・ストリームに関するステータス情報）を扱うのに必要な機能性が追加される。したがって、それぞれの新しいソケットごとに適切なコンシューマ・オブジェクトがインスタンス化されることが可能であり、またオブジェクト自体およびオブジェクトのソケットが、様々なソケットを監視して新しいイベントを検出するポーリング機構に登録されることが可能である。
【０００９】
本発明の別の態様では、コンピュータ・サーバ内部のソケットで受け取ったイベント（例えば、クライアント接続、ストリーミングされたメディア、メディア・ストリーミング・コマンド）を扱うための方法が提供される。この方法では、１つまたは複数のソケットが、イベントを検出するためにソケットをポーリングするポーリング・モジュールに登録される。それぞれの登録されたソケットは、そのソケットで受け取ったイベントを担当するイベント・コンシューマに関連付けられる。登録されたソケットにイベントを受け取ると、関連するイベント・コンシューマが通知を受け、必要に応じてタスクを発行してイベントの扱いを円滑にする。本発明のこの実施態様では、登録されたソケットを複数の集合に分けることができる。各集合内部で、１つのプロセッサ・スレッドが、イベントを検出し、イベント・コンシューマに通知を行うためにソケットの間で共用される。また、スレッドのプールが、様々なイベント・コンシューマによって発行されたタスクを実行するために割り振られる。
【００１０】
（詳細な説明）
以下の説明は、当分野の任意の技術者が本発明を作成および使用できるようにするために提示され、本発明の特定の応用例およびその要件という状況で提供される。当分野の技術者であれば、開示された実施形態に対する様々な修正が容易に明らかとなり、本明細書に定義された一般的な原理は、本発明の精神および範囲を逸脱することなく他の実施形態および応用例に適用することができる。したがって本発明は、例示された実施形態に限定されるものではなく、本明細書に開示された原理および特徴に適合する最も広い範囲が与えられる。
【００１１】
本発明の実施形態が実行されるプログラム環境は、汎用コンピュータまたは特定用途向けデバイスを含んでいる。例えば、ほぼすべての構成のコンピュータまたは通信デバイス（たとえば、有線、無線、携帯用、デスクトップなど）に対してデータまたは媒体ストリーミング・サービスを提供するように構成されたコンピュータ・サーバなどを組み込んでいる。こうしたコンピュータおよび他のデバイス（たとえば処理装置、メモリ、データ記憶装置、ディスプレイなど）の詳細はよく知られているため、理解しやすいように省略されている。さらに、本発明は、オブジェクト指向プログラミング環境で実施できるものとして記載されている。当分野の技術者であれば理解されるように、実施形態の好適な変形形態は、他のプログラミング・モデルまたはフレームワークを使用して実施することが可能である。
【００１２】
本発明の技法は、様々な技術を使用して実施できることも理解されたい。たとえば、本明細書に記載された方法は、コンピュータ・システムで実行中のソフトウェアで実現可能であるかまたは、マイクロプロセッサまたは他の特別に設計されたアプリケーション特有の集積回路の組合せ、プログラム可能論理デバイス、あるいはそれらの様々な組合せのいずれかを使用するハードウェアで実現可能である。具体的には、本明細書に記載された方法は、搬送波などの記憶媒体、ディスク・ドライブ、またはコンピュータ読取り可能媒体上に常駐する一連のコンピュータ実行可能命令に実装可能である。搬送波の例示的な形式は、ローカル・ネットワークまたはインターネットなどの公衆がアクセス可能なネットワークに沿ってデジタル・データ・ストリームを搬送する、電気、電磁、または光の信号形態を取ることができる。
【００１３】
本発明の一実施形態では、メディア・ストリーミング・サーバまたはデータ・ストリーミング・サーバが、メディアを１つまたは複数のクライアントにストリーミングするように構成される。サーバは、クライアントと通信するのに使用するソケットを作成し、維持する。ソケットは、複数の集合に分けることができ、適切なプロセッサ・リソースが集合に割りられる。所与のソケットは、複数のストリーム、複数のクライアントまたは複数のクライアント接続、複数タイプのイベント等で使用するように構成することができる。
【００１４】
イベントをサーバ・ソケットで受け取ったとき、ソケット・コンシューマ、つまりソケットに関して関心があることを登録したプログラム・モジュールまたはプログラム・オブジェクトが通知を受ける。新しいクライアント接続要求を扱うリスナ・コンシューマ、メディア・ストリーミング・コマンドを扱う接続コンシューマ、ステータス情報を受け取る又はメディア・ストリーミングの反射モードで別のメディア・サーバからサーバにストリーミングされたメディアを受け取るレシーバ・コンシューマなどの、異なるタイプのコンシューマを異なるタイプのイベントに対して生成することができる。
【００１５】
例として、ソケットに到着したイベントが、適切なコンシューマに迅速に渡され、ソケットにイベントを受け取る専用のスレッドが、自らの注意を自らの集合のソケットに戻すことができるようになっている。これにより、限られた数のスレッドが、イベントを損失する、またはイベントを遅延させることなく、多数のソケットに役立てられることが可能になる。イベントを受け取るソケット・コンシューマはイベントを扱う１つまたは複数の適切なタスクを生成することができる。タスクは、別々のタスク・オブジェクトとして発行されることが可能で、タスクの実行に割り振られたスレッドのプールを共用することが可能である。
【００１６】
スレッドが、制御された仕方で共用され、割り振られるため、本発明のこの実施形態は、イベントをサーバにサブミットする様々な数のクライアントまたはその他のエンティティに合せて拡大縮小することができる。
【００１７】
本発明特有の実施形態について、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，ＩｎｃのＳｏｌａｒｉｓ（商標）オペレーティング・システムを実行中のシステムなどの、ＵＮＩＸ（登録商標）ベースのコンピュータ・システムからＱｕｉｃｋＴｉｍｅ媒体をストリーミングするために実装するものとして以下に説明する。以下の詳細な説明からわかるように、こうした実施形態は、他のタイプの媒体および他のコンピュータ・システムで使用するように修正することができる。
【００１８】
例示的な媒体ストリーミング・サーバ
媒体ストリーミングとは、ユーザがプログラムまたはプレゼンテーション全体を自分のクライアント・デバイスにダウンロードしてしまうまで待つ必要なしに、媒体コンテンツを受信して楽しむことができるようにするものである。たとえばユーザは、プログラム全体を受け取るまで待つことなく、すでに記録されたプログラムを楽しむか、またはライブ・イベントをリアルタイムで体験することができる。
【００１９】
媒体は、ユニキャスト・モードまたはマルチキャスト・モードでストリーミング可能である。ユニキャスト・モードの場合、ストリーミング・サーバはそれぞれの受信側クライアント・デバイスへの専用接続を維持し、ユーザに対して自分のストリームを介したかなりの制御権を認める。たとえばユーザは、ストリームの一時停止、ストリーミングされた媒体の巻戻しまたは早送り、あるいは他の制御機能の実行が可能である。ただし、これによって、多数のユーザが十分な帯域幅を使用できなくなる可能性がある。マルチキャスト・モードの場合、媒体ストリーミング・サーバは、より少ない帯域幅を使用して、複数のユーザにプログラムを同時にストリーミングする。したがってこのタイプのストリーミングは、従来の同報通信に類似しており、ユーザは個々のストリームを介した制御権をほとんど持たない。ライブ・イベントは、多数のユーザにサービスを提供するために効率が良いことから、通常はマルチキャスト・モードでストリーミングされる。また、ライブ・イベントはリアルタイムで楽しむものであることから、ストリーミングされた媒体を操作する必要もほとんどない。
【００２０】
本発明の実施形態による媒体ストリーミング・サーバは、「反射」モード・オペレーションで動作することが可能であり、サーバは、媒体ストリームを別のストリーミング・システムまたはサーバから（通常はマルチキャスト・モードで）受け取り、その媒体を１人または複数のユーザに（ユニキャストまたはマルチキャスト・モードで）転送する。
【００２１】
リアルタイム媒体ストリーミングは、媒体の各フレームまたは他のユニットの配信が指定された順序および一定の時間枠内で実行されなければならないため、発行元サーバに制約を与える。したがって媒体ストリーミング・サーバは、サービスを提供するクライアントの数にかかわらず、ユーザに提供するサービスの質が許容できないレベルまで下がることのないように、リアルタイム媒体ストリーミングの要求に合わせるよう努力しなければならない。たとえば、プログラムのタイプ（すなわちライブまたは事前記録済み）およびストリーミングのモード（すなわちユニキャストまたはマルチキャスト）にかかわらず、ストリーミングされる媒体は、一般に、移行時に消費する帯域幅を減らすために圧縮されるため、クライアントへのタイムリーな媒体の配信を確実にすることができる。
【００２２】
本発明の一実施形態に従った媒体ストリーミング・サーバは、ＱｕｉｃｋＴｉｍｅ媒体および／または他の形式の媒体を、ユニキャストまたはマルチキャスト・モードで、専用ネットワーク又はインターネットなどの公衆アクセス可能なネットワークを介してストリーミングするように構成されている。媒体ストリームは、伝送媒体に適合するプロトコル・セットに従ってフォーマット化される。具体的に言えば、ＱｕｉｃｋＴｉｍｅ媒体をストリーミングする場合、サーバは、クライアントの媒体ストリーム制御を容易にするためのＲＴＳＰ（Real-Time Streaming Protocol）用、クライアントへのストリームの配信および／または他のソースからの媒体の受信のためのＲＴＰ（Real-Time Transport Protocol）用、ストリームの品質に関する情報の受信または交換のためのＲＴＣＰ（Real-Time Transport Control Protocol）用、クライアントに媒体を記述するためのＳＤＰ（Session Description Protocol）用などに構成することができる。他の実施形態を他の媒体プロトコル用に構成することもできる。
【００２３】
図１は、本発明の実施形態に従ってＱｕｉｃｋＴｉｍｅ媒体をストリーミングするように構成された、媒体ストリーミング・サーバ１０２を示す図である。図１では、媒体ストリーミング・サーバ１０２がクライアント１１０、１１２にサービスを提供する。クライアントに向けてストリーミングされる媒体は、記憶デバイス１０４から取り出されるすでに記録されたプログラム、またはサーバ１３０から（たとえばマルチキャスト同報通信１３０ａの一部として）受信されるリアルタイム・プログラムを含むことができる。したがって媒体ストリーミング・サーバ１０２は、ライブ・イベント（たとえばコンサート、ニュース放送、スポーツ・イベント）、映画、ドキュメンタリ、トレーニング・ビデオ、教育用の番組またはクラスなどをストリーミングすることができる。
【００２４】
媒体ストリーミングは、媒体ストリーミング・サーバ１０２とクライアントとの間に複数の接続を必要とする場合がある。図１に示された実施形態では、第１の接続はクライアントが媒体ストリームを制御できるようにするためのＲＴＳＰ（たとえば接続１１０ａ、接続１１２ａ）用である。具体的に言えば、クライアントはＲＴＳＰ接続を使用してコマンドを媒体ストリーミング・サーバに送信する。この実施形態でクライアントがサーバに提示できる媒体ストリーム・コマンドには、サポートされているコマンドのリストを受け取るためのＯｐｔｉｏｎｓ、媒体プログラムを記述するようにサーバにプロンプトを出すためのＤｅｓｃｒｉｂｅ、受け取りたい所望のトラック（各トラックはビデオ、オーディオなどの異なる媒体形式であってよい）を識別するためのＳｅｔｕｐ、媒体トラックまたはプログラムを再生するためのＰｌａｙ、ストリーミングを一時的に停止するためのＰａｕｓｅ、ストリームを終了させるためのＴｅａｒｄｏｗｎ、などのコマンドが含まれる。したがってクライアント１１０は、たとえばサーバ１０２とのＲＴＳＰ接続１１０ａを確立し、Ｄｅｓｃｒｉｂｅコマンドを発行して、ストリーミングに使用可能なコンテンツおよびトラックの記述を受け取ることができる。その後クライアント１１０は、１つまたは複数のトラックに対してＳｅｔｕｐ要求を提示することができる。
【００２５】
クライアントがサーバに対してＳｅｔｕｐコマンドを発行すると、サーバは、選択されたトラックに対してＲＴＰ接続（たとえば接続１１０ｂ、接続１１２ｂ）およびＲＴＣＰ接続（たとえば接続１１０ｃ、接続１１２ｃ）を確立する。Ｐｌａｙコマンドを受け取ると、サーバはＲＴＰ接続を介してクライアントへの媒体パケットのストリーミングを開始する。サーバおよびクライアントは、ＲＴＣＰ接続を介して、ストリームの品質を記述したＲＴＣＰパケットを交換することができる。Ｔｅａｒｄｏｗｎコマンドが発行されると、サーバは、発行元クライアントとの関連するストリーム接続を閉じる。
【００２６】
媒体ストリーミング・サーバによって使用される様々な接続は、サーバおよびクライアントがそれを介して通信する（たとえばインターネット）、互換通信媒体用のＴＣＰ（Transport Control Protocol）ソケットを使用することができる。本発明の他の実施形態では、ソケットを異なるプロトコル（たとえば、HTTP-HyperText Transport Protocol、FTP-File Transfer Protocol）に従って構成することができる。
【００２７】
すでに述べたように、図１の媒体ストリーミング・サーバ１０２は、リアルタイムまたはライブの媒体をクライアントにストリーミングすることが可能であり、すでに記録された媒体をストリーミングすることも可能である。さらに、反射モード・オペレーションでは、媒体ストリーミング・サーバは、他のサーバ（たとえばサーバ１３０）からのライブ・イベント、ビデオ・カメラ、同報通信など、他のエンティティから受け取った媒体を、クライアントに転送することができる。この状況では、媒体ストリーミング・サーバ１０２はクライアントとして動作し、エンティティとの間で確立されたＲＴＰ接続を介して媒体パケットを受け取る。
【００２８】
クライアント１１０、１１２は、媒体ストリーミング・サーバ１０２からストリーミングされた媒体を再生するのに好適な媒体プレーヤを備える。ＱｕｉｃｋＴｉｍｅ媒体ストリーミングの場合、クライアントは、Ａｐｐｌｅ Ｃｏｍｐｕｔｅｒ，Ｉｎｃから入手可能なものと同様に、ＱｕｉｃｋＴｉｍｅプレーヤを操作することができる。クライアント・コンピューティング・デバイスは、好適な媒体プレーヤが使用可能なほぼすべてのオペレーティング・システム（たとえば、Ｓｏｌａｒｉｓ、Ｍａｃ ＯＳ、Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ）を動作させることができる。クライアント・デバイスは、比較的低い帯域幅の通信機能（たとえば５６Ｋモデム）を備えることができるため、媒体ストリームは、比較的遅いビット・レートで送信することができる。もちろん、より高い帯域幅能力を有するクライアントに対しては、より速いビット・レートも実施可能である。クライアントは、ＵＲＬ（Uniform Resource Locator）、ファイル名、プログラム名（たとえば映画の名前、歌の題名）などを提示することによって、ストリーミングされてくる媒体を識別することができる。
【００２９】
メディア・ストリーミング・サーバに受け取ったイベントの扱い
本発明の一実施形態では、図１のサーバ１０２などのメディア・ストリーミング・サーバが、複数のクライアントにメディアをストリーミングし、サーバに受け取ったイベントまたはデータに関して必要とされる様々なタスクを行うように構成される。イベントは、クライアント接続要求、メディア・ストリーミング・コマンド、ストリームの品質に関する情報、またはクライアントからの他の何らかの情報を含み、または上流のメディア・サーバまたは上流のその他のソースから受け取ったデータまたはその他の信号を含むことができる。イベントまたはデータの受信に応答して、様々なタスクを開始することができる。
【００３０】
この実施形態では、イベントおよびデータは、適切な通信プロトコルに従って構成されたサーバ・ソケットに受信される。イベントを検出して受信し、所与のイベントに関して達せられるべきタスクを決定し、そのタスクを行うため、効率的であり、拡張可能でフレキシブルな方法が実施される。詳細には、システム・リソース（例えば、プロセッサ時間）が、オーバーヘッド（例えば、コンテキストスイッチ）および競合を減少させるが、メディア・ストリームの要求を満たすのに必要なリソースを抑えないことを目的とする仕方で割り振られる。詳細には、プロセッサ・サイクル（および／またはその他のリソース）の割振りに対してより大きく制御することにより、メディア・ストリーミング・サーバが、メディア・ストリーミング・サービスも、その他のサーバ・サービスもあまり低下させることなく、より多数のクライアントを扱うことができるのが可能である。
【００３１】
この実施形態の一実施形態では、サーバ・ソケットで受け取ったイベントは、イベントのタイプ、および／または、ソケットの識別ではなく、イベントを開始したクライアントまたはその他のエンティティに基づいて処理される。この結果、１つのソケットを複数のクライアント接続および／または複数タイプのイベントのために使用することができる。これは、クライアントのためにメディアをストリーミングするのに必要なソケットの全体数を抑えるのに役立つ。
【００３２】
より具体的には、ＱｕｉｃｋＴｉｍｅメディアをストリーミングするとき、メディア・サーバは、クライアントとの各ＲＴＳＰ制御接続ごとに別個のソケットを作成する。ただし、１つのサーバ・ソケットを介して複数のクライアントとの複数のＲＴＰ接続を確立することができる。同様に、複数のＲＴＣＰ接続に対して１つのソケットを使用することができる。ただし、共用ソケットを介する各接続が固有ペアのクライアントとサーバ・アドレス（例えば、タプル）を有するのを確実にするため、各個別クライアントは、所与のサーバ・ソケットを介して１つのＲＴＰ接続または１つのＲＴＣＰ接続だけに参加することができる。詳細には、ソケットを介する各接続に関して、サーバ・アドレスは同一であることが可能であるが、クライアント・アドレスは異なる。
【００３３】
図２は、共用ソケットを有する複数のクライアントにサービスを提供するように構成されたメディア・サーバを示している。メディア・ストリーミング・サーバ２００は、クライアント１〜Ｎにサービスを提供するための複数のソケットを備えている。示す実施形態では、ソケット１およびＮ＋２はそれぞれ、クライアント１およびＮとのＲＴＳＰ接続に専用である。ただし、ソケット２は、両方のクライアントのＲＴＰ接続のために使用され、一方、ソケット３は、両方のクライアントのＲＴＣＰ接続のために使用される。
【００３４】
次に、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．によるＳｏｌａｒｉｓ（商標）オペレーティング・システムを実行するシステムなどのＵＮＩＸベースのコンピュータ・システムにおいて実施することができる本発明の一実施形態を説明する。この実施形態では、いくつかのオブジェクト指向プログラム・モジュールが使用され、以下に説明するとおり、処理スレッドが割り振られる。本発明の他の実施形態では、プログラミングを行う他の方法、およびプロセッサ・リソースを割り振る他の方法を使用して、異なるタイプのコンピュータ・システムを使用することができる。
【００３５】
この実施形態では、Ｐｏｌｌｅｒは、ソケット、パイプ、およびその他のポーリング可能なファイル記述子をポーリングするように構成されたプログラム・モジュールまたはプログラム・オブジェクトを含む。クライアント接続、関与する他のサーバまたは他のエンティティに対する接続のために使用されているポーリング可能なファイル記述子が、１つまたは複数のＰｏｌｌＴａｂｌｅにグループ化される。各ＰｏｌｌＴａｂｌｅは、構成可能な数のエントリ（例えば、２５６）を含み、所与のファイル記述子をオープン・エントリを有する任意のＰｏｌｌＴａｂｌｅに登録することができ、必要に応じて新しいＰｏｌｌＴａｂｌｅを作成することができる。１つまたは複数のプロセッサ・スレッドが、登録されたファイル記述子で受け取ったイベントを検出し、そのイベントに応答するため、各ＰｏｌｌＴａｂｌｅに専用であることが可能である。
【００３６】
イベント（例えば、クライアント接続、ストリーミング・コマンド・データ）が、ＰｏｌｌＴａｂｌｅに登録されたソケットで受け取ったとき、ＰｏｌｌＴａｂｌｅは、例としてＣｒｅａｔｅＴａｓｋ（）と命名する必要とされるメソッドを最低限実装するＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトにそのイベントを渡す。ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトは、抽象ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒインターフェース・クラスから導出される。このクラスは、ＣｒｅａｔＴａｓｋ（）メソッドだけを含むことが可能である。したがって、特定タイプのイベントを扱うため、多数の異なるＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトを生成することが可能である。
【００３７】
したがって、オブジェクトのＬｉｓｔｎｅｒクラスが、ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒクラスの１つのサブクラスを表し、新しい接続要求を検出する、または聴取するように構成されることが可能である。オブジェクトのＣｏｎｎｅｃｔｉｏｎクラスは、クライアントまたはその他のエンティティと確立された（メディア・ストリーミング・コマンドまたはその他のコマンドを実行または処理するため）接続を扱うための、ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒクラスの別のサブクラスを表すことが可能である。また、他の様々なサブクラスもインプリメントすることが可能であり、複数タイプの特定のオブジェクトをその様々なサブクラスから導出することができる。
【００３８】
例えば、ＲＴＳＰＣｏｎｎｅｃｔｉｏｎオブジェクトが、Ｃｏｎｎｅｃｔｏｎサブクラスから導出された１つのＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトであり、ＲＴＳＰソケットで受け取ったメディア・ストリーミング・コマンドを扱うように特に構成されている。他の特定のＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトには、ＲＴＣＰＣｏｎｎｅｃｔｉｏｎオブジェクト（ＲＴＣＰイベントを扱うための）、新しいＲＴＳＰ接続要求を聴取するためのＲＴＳＰＬｉｓｔｅｎｅｒオブジェクト等が含まれるいてもよい。要するに、様々なＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトをインプリメントして様々なイベントを扱うことができる。
【００３９】
特定のＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトは、ソケットまたはその他のファイル記述子に対する自らの関心を示し、Ｐｏｌｌｅｒに自らを登録し、またファイル記述子を登録することにより、そのソケットにイベントを受け取った場合、通知を受けるようにする。１つのオブジェクトが、複数のソケットのコンシューマとして登録することが可能である。
【００４０】
Ｔａｓｋオブジェクトと呼ばれる別の系列のプログラム・オブジェクトまたはプログラム・モジュールをインプリメントして、イベントの扱いに関連する特定のタスクを達することができる。ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトは、イベントの通知を受けたとき、必要なタスクを行うように構成されたＴａｓｋオブジェクトを作成する、または呼び出すことができる。したがって、ＲＴＳＰ接続を介して受け取った（例えば、ストリーミング・セッションの一環として）クライアント・コマンドのケースでは、ＲＴＳＰＣｏｎｎｅｃｔｉｏｎオブジェクトが、クライアントのコマンド（例えば、記述する、再生する、一時停止する）を実行するように構成されたＲＴＳＰＴａｓｋオブジェクトを呼び出すことができる。
【００４１】
別の例として、ＲＴＰソケットを介して別のメディア・サーバから（例えば、反射中に）メディア・ストリーミング・サーバに受け取ったメディアまたはその他のデータに関して、ＰｏｌｌＴａｂｌｅは、担当するＲＴＰＲｅｃｅｉｖｅｒオブジェクト（ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒインターフェースのＲｅｃｉｅｖｅｒサブクラスから導出された）に警報することができる。次に、ＲＴＰＲｅｃｅｉｖｅｒオブジェクトは、ＲｅｃｅｉｖｅＤａｔａタスク・オブジェクトを呼び出してデータを実際に読み取る、または処理することができる。
【００４２】
この実施形態では、特定のＰｏｌｌＴａｂｌｅに割り振られたスレッドが、そのＰｏｌｌＴａｂｌｅに排他的に専用であることが可能である。したがって、ＰｏｌｌＴａｂｌｅスレッドは、単にイベントを検出し、イベントをそれぞれのコンシューマに渡す働きだけをすることが可能である。このようにして、１つのスレッドを各ソケット専用にしなければならず、それにより、過度の競合（例えば、多数のスレッドが利用される際）を招く、または別の仕方でプロセッサ時間を非効率的に使用することなく、イベントを迅速に検出することができる。登録されたファイル記述子に受け取られたイベントによって必要とされる様々なタスクを行うため、スレッドのプールまたはセットを割り振ることができる。詳細には、タスク待ち行列を実装して、ソケット・コンシューマによって呼び出された様々なタスク・オブジェクトを実行し、スレッド・プールに割り振られたスレッドでそれらのオブジェクトを実行することができる。
【００４３】
また、本発明のこの実施形態では、パイプをＰｏｌｌＴａｂｌｅに登録し、ソケットおよびその他のタイプのファイル記述子とともにポーリングすることができる。パイプは、Ｐｏｌｌｅｒとその他のプログラム・オブジェクトの間における通信のために使用することができる。例えば、パイプは、登録されるべき新しいファイル記述子（例えば、ソケット）をＰｏｌｌｅｒに通知するため、特定のファイル記述子に関してポーリングが再開されることを要求するため、Ｐｏｌｌｅｒがソケットを登録解除することを要求する（例えば、メディア・ストリームが取り払われたとき）などのためにＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトによって使用されることが可能である。例として、イベントをソケットで受け取ったとき、そのイベントが扱われ、Ｐｏｌｌｅｒがソケットに対するポーリングを再開するよう命令を受けるまで、そのソケットに対してポーリングがサスペンドされる。
【００４４】
図３は、本発明の一実施形態によるメディア・ストリーミング・サーバ内部のイベントを扱うための様々なプログラム・オブジェクトのクラスの間の関係を描いている。示す実施形態では、ＰｏｌｌＴａｂｌｅを作成して管理し、ＰｏｌｌＴａｂｌｅ内部のメディア・サーバ・ソケット（およびその他の登録されたファイル記述子）のポーリングを制御するように構成された単独クラスをＰｏｌｌｅｒ３０２が表している。この実施形態では、ファイル記述子がＰｏｌｌｅｒ３０２に登録され、ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトがその記述子を介して受け取ったイベントまたはデータの通知を受ける必要があるとき、ＰｏｌｌＴａｂｌｅの中に入れられる。
【００４５】
ＰｏｌｌＴａｂｌｅ３０４は、Ｐｏｌｌｅｒに登録されたポーリング可能なファイル記述子の集合を表す。ＰｏｌｌＴａｂｌｅは、テーブル、またはその他の構造を維持し、Ｐｏｌｌｅｒ３０２によって指示されるとおりにエントリを挿入し、削除する。各エントリは、特定のファイル記述子、およびその記述子で受け取ったイベントの通知を受けるべきＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトを特定する。ＰｏｌｌＴａｂｌｅの中に入れることの可能なファイル記述子の数は設定可能であり、また、複数のＰｏｌｌＴａｂｌｅを実装することができる。ファイル記述子には、パイプ、ソケット、ならびに実質的に他のあらゆるポーリング可能なエンティティが含まれることができる。例として、単一のプロセッサ・スレッド、またはプロセッサ時間の割振りが、単一のＰｏｌｌＴａｂｌｅのファイル記述子の間で共用されて、それらの記述子がイベントに対してポーリングされることが可能である。
【００４６】
ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒ３１０は、ポーリング・サービスを必要とする、またはサーバに受け取ったイベントに応答して何らかのアクションが行われることを必要とするオブジェクトのためのインターフェースを提供するアブストラクトベースのクラスを表している。様々なサブクラスをＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒクラスから作成することができ、例として、ＣｒｅａｔｅＴａｓｋ（）メソッドをインプリメントしなければならない。図３は、３つのＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒサブクラス、Ｌｉｓｔｅｎｅｒ、Ｃｏｎｎｅｃｔｉｏｎ、およびＲｅｃｅｉｖｅｒを示している。
【００４７】
Ｌｉｓｔｅｎｅｒ３１２は、サーバ・ポートにおけるイベント（例えば、新しい制御接続の要求）を聴取するように構成されたリスナ（例えば、リスナ・ソケット）を表している。異なるプロトコル（例えば、ＲＴＳＰ、ＦＴＰ、ＨＴＴＰ、Ｔｅｌｎｅｔ）に対して様々なタイプのＬｉｓｔｅｎｅｒオブジェクトをインスタンス化することが可能であり、また１つのタイプのＬｉｓｔｅｎｅｒの複数のインスタンスを生成することができる。例として、各タイプのＬｉｓｔｅｎｅｒオブジェクトが、異なるタイプの制御接続を作成するように構成される。
【００４８】
Ｃｏｎｎｅｃｔｉｏｎ３１４は、サーバ・ソケットを介して外部のエンティティ（例えば、クライアント、別のメディア・サーバ）と確立された接続を表している。例として、ＬｉｓｔｅｎｅｒオブジェクトがＴＣＰ接続を検出したとき、新しいＣｏｎｎｅｃｔｉｏｎオブジェクトが生成されることが可能である。Ｃｏｎｎｅｃｔｉｏｎ３１４は、Ｃｏｎｎｅｃｔｉｏｎオブジェクトがそれを介して制御コマンド（例えば、メディア・ストリームを確立または操作する）、またはその他のイベントを受け取るソケット（例えば、ソケットのオブジェクト指向カプセル化を表すソケット３１６）を含む。様々なタイプの接続（例えば、ＲＴＳＰ、ＲＴＰ、ＲＴＣＰ、ＨＴＴＰ）を異なるＣｏｎｎｅｃｔｉｏｎオブジェクトで実現することができ、また、単一タイプの複数のインスタンスを作成することができる。
【００４９】
Ｒｅｃｅｉｖｅｒ３１８は、所与のソケットを介してサーバに受け取ったデータまたは情報を処理するように構成されたデータ・レシーバまたは情報レシーバを表す。例えば、本発明の示す実施形態では、Ｌｉｓｔｅｎｅｒ３１２のＲＴＳＰＬｉｓｔｅｎｅｒ実装形態が、新しいメディア・ストリームを確立することを望むクライアントから新しいＲＴＳＰ制御接続を受け取ることが可能である。ＲＴＳＰＬｉｓｔｅｎｅｒオブジェクトは、新しいソケットのために新しいＲＴＳＰＣｏｎｎｅｃｔｉｏｎオブジェクトを生成する（例えば、Ｃｏｎｎｅｃｔｉｏｎ３１４のＲＴＳＰＣｏｎｎｅｃｔｉｏｎサブクラスから）。ＲＴＳＰＣｏｎｎｅｃｔｉｏｎオブジェクトが、選択されたメディア・トラックを再生するコマンドを受信したとき、サーバが、クライアントに対するＲＰＴパケットの伝送を開始し、ＲＴＣＰＲｅｃｅｉｖｅｒオブジェクトをインスタンス化して（例えば、Ｒｅｃｅｉｖｅｒ３１８のＲＴＣＰＲｅｃｅｉｖｅｒサブクラスから）、クライアントからストリーム品質データを収集することが可能である。
【００５０】
前述したとおり、１つのＲＴＣＰソケットが、サーバと複数のクライアントの間における複数のＲＴＣＰ接続の間で共用されることが可能である。したがって、この場合、１つだけのＲＴＣＰＲｅｃｅｉｖｅｒオブジェクトが必要とされ、かつ、このオブジェクトは、イベントを受信したとき、どのＲＴＣＰ接続、またはどのクライアントが、そのイベントを開始したかを判定する（例えば、クライアントのネットワーク・アドレスにより）。
【００５１】
メディア・サーバが、１つまたは複数のクライアントに転送するために別のサーバからメディアを受け取る反射モードの動作では、メディア・サーバは、ＲＴＰＲｅｃｅｉｖｅｒ（例えば、Ｒｅｃｅｉｖｅｒ３１８の別のサブクラスとして）をインプリメントしてＲＴＰメディア・パケットを受け取ることができる。
【００５２】
ＴａｓｋＱｕｅｕｅ３０６は、Ｐｏｌｌｅｒ３０２に登録されたファイル記述子で受け取ったイベントに関連するタスクを処理または実行するための待ち行列を表している。例として、ＴａｓｋＱｕｅｕｅ３０６は、先入れ先出し（ＦＩＦＯ）待ち行列として動作して、様々なＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトによって呼び出されたタスクを実行する。
【００５３】
Ｔａｓｋ３２０は、別のオブジェクト（例えば、Ｐｏｌｌｅｒ、ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクト）によってインプリメントされるアブストラクト・クラスを表している。Ｔａｓｋは、ＴａｓｋＱｕｅｕｅ３０６上に配置され、待ち行列から取り出されたとき、プロセッサ・スレッドによって実行される。例えば、メディア・ストリームの確立、制御、および監視を行うのに必要な様々なアクションが、Ｔａｓｋオブジェクトとして担当のＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトによって渡されることが可能である。例として、プロセッサ・スレッドのプールが、ＴａｓｋＱｕｅｕｅの中に入れられたＴａｓｋの実行に割り振られる。
【００５４】
本発明の示す実施形態では、Ｐｏｌｌｅｒに登録されたファイル記述子を介してメディア・サーバに受け取ったイベントまたはデータが、対応するＰｏｌｌＴａｂｌｅに関連するスレッドがＰｏｌｌＴａｂｌｅエントリをポーリングしたときに検出される。ファイル記述子に関するＰｏｌｌＴａｂｌｅエントリが検査されて、担当のＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトが特定され、イベントがそのオブジェクトに渡される。次に、ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトは、ＣｒｅａｔｅＴａｓｋ（）メソッドをインプリメントしてイベントを扱う、またはデータを処理するタスクを作成する。例として、イベントを検出したＰｏｌｌＴａｂｌｅスレッドは、単にそのイベントをＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトに渡して、より多くの活動を扱うように迅速に可用になるようにし、その場合、異なるスレッドが、ＣｒｅａｔｅＴａｓｋ（）メソッドを実行する。
【００５５】
ただし、別法では、イベントに少しの処理しか必要とされない場合、ＣｒｅａｔｅＴａｓｋ（）メソッドの実行が、実際にタスクの作成をもたらさないことが可能である。代りに、ＣｒｅａｔｅＴａｓｋ（）メソッドを実行したプロセッサ・スレッド（例えば、ＰｏｌｌＴａｂｌｅのスレッド）が、イベント処理も扱うことが可能である。
【００５６】
ソケットにおけるイベントが検出され、適切なＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトに渡された後、Ｐｏｌｌｅｒは、そのイベントが処理された（例えば、ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクト、またはＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトによって呼び出されたＴａｓｋオブジェクトにより）ことの通知を受けるまで、ソケットのポーリングを停止する。
【００５７】
例として、新しいソケットをポーリングのために登録するとき（例えば、新しいクライアント・セッションまたは新しいストリームがセットアップされるとき）、そのソケットを担当するＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトが、パイプを介してＰｏｌｌｅｒに通知する。このパイプは、別のファイル記述子としてＰｏｌｌＴａｂｌｅの中に登録されていることが可能である。Ｐｏｌｌｅｒは、パイプを介する活動が存在するとき通知を受けるということで、パイプに関してＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトと同様に動作することが可能である。単一のパイプまたは複数のパイプ（例えば、各ＰｏｌｌＴａｂｌｅの中に１つづづの）を維持することが可能である。
【００５８】
図４Ａ、４Ｂは、複数のソケットを介してサーバに受け取ったイベント（例えば、クライアント要求、データ）を扱う本発明の実施形態を実施する例としての方法を描いている。この示す方法は、図３に描いたものと同様に、サーバが初期設定される際の必要なプログラム・オブジェクトの作成、ならびにイベントが受け取った際のオブジェクトの利用を示している。サーバは、ＱｕｉｃｋＴｉｍｅメディアをストリーミングするように構成されたメディア・ストリーミング・サーバであってよく、その場合、サーバは、適切なプロトコル（すなわち、ＲＴＳＰ、ＲＴＰ、ＲＴＣＰ、ＳＤＰ）で構成される。
【００５９】
図４Ａの状態４０２では、Ｐｏｌｌｅｒが作成される（例えば、サーバの初期設定の一環として）。この時点で、Ｐｏｌｌｅｒは、ＰｏｌｌＴａｂｌｅの空のリストだけを維持し、ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトは、全く作成されていない。ただし、Ｐｏｌｌｅｒは、他のプロセスまたは他のオブジェクトと通信するためのパイプを備えていることが可能である。本発明の代替の実施形態では、Ｐｏｌｌｅｒが作成されたとき、第１のＰｏｌｌＴａｂｌｅが自動的に生成される。
【００６０】
状態４０４で、第１のＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトが、適切なＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒクラスまたはＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒサブクラスからインスタンス化されて、新しいクライアント接続を聴取する。クライアントにサービス（例えば、メディア・ストリーミング・サービス、Ｗｅｂサービス）を提供するように構成されたサーバにおいて、クライアントがサーバと接続を確立するのに使用する特定のプロトコル（例えば、ＲＴＳＰ、ＨＴＴＰ、ＦＴＰ）に合せて第１のＬｉｓｔｅｎｅｒオブジェクトを構成することができる。より具体的には、Ｌｉｓｔｅｎｅｒクラスを抽象基本ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒクラスから導出して、様々なタイプのリスナ・ソケットに対応することができる。Ｌｉｓｔｅｎｅｒクラスは、ＣｒｅａｔｅＴａｓｋ（）メソッドを含め、ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒクラスから継承を行い、１つまたは複数の特定タイプのＬｉｓｔｅｎｅｒに必要とされる機能性を追加することができる。
【００６１】
ＬｉｓｔｅｎｅｒクラスからＲＴＳＰＬｉｓｔｅｎｅｒクラスおよびＲＴＳＰＬｉｓｔｅｎｅｒオブジェクトを導出して、ＲＴＳＰ接続を聴取することができ、ＨＴＴＰＬｉｓｔｅｎｅｒクラスおよびＨＴＴＰＬｉｓｔｅｎｅｒオブジェクトを導出して、ＨＴＴＰ接続を聴取することなどができる。したがって、ＲＴＳＰＬｉｓｔｅｎｅｒオブジェクトおよびＨＴＴＰＬｉｓｔｅｎｅｒオブジェクトは、多くの可能なＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトおよびＬｉｓｔｅｎｅｒオブジェクトのなかの２つに過ぎない。ＣｒｅａｔｅＴａｓｋ（）メソッドの他、ＲＴＳＰＬｉｓｔｅｎｅｒオブジェクトまたは他の特定のＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトは、その他のメソッドもインプリメントして、詳細には、クライアント要求に応答して新しい制御接続を確立することができる。
【００６２】
また、その他の役割をするその他のサブクラスも、以下に説明するとおり、ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒクラスから導出することができ、またその他のタイプのＬｉｓｔｅｎｅｒクラスを異なるプロトコルまたは異なるタイプの制御接続のために導出することができる。
【００６３】
状態４０６で、新しいＲＴＳＰＬｉｓｔｅｎｅｒオブジェクトが、リスナ・ソケットを作成して新しいＲＴＳＰ制御接続を聴取する。ソケットは、適切な通信プロトコルに従って作成することができ、構成可能であること、または所定であることが可能である。
【００６４】
状態４０８で、ＲＴＳＰＬｉｓｔｅｎｅｒが、新たに作成されたソケットのことをＰｏｌｌｅｒに（例えば、パイプを介して）通知する。これにより、ソケットの登録が開始され、登録は、完了したとき、Ｐｏｌｌｅｒが、イベント（例えば、新しい制御接続要求）に関してソケットをポーリングするのを可能にする。
【００６５】
状態４１０において、Ｐｏｌｌｅｒは新しいＰｏｌｌＴａｂｌｅを作成する。というのは、Ｐｏｌｌｅｒは、新しいリスナ・ソケットを登録する余地を有するＰｏｌｌＴａｂｌｅを全く有していないからである。Ｐｏｌｌｅｒは、アクティブＰｏｌｌＴａｂｌｅを特定するためのリストまたはその他の構造の中に新しいＰｏｌｌＴａｂｌｅに対するリファレンスを記憶することができる。
【００６６】
本発明のこの実施形態では、ＰｏｌｌＴａｂｌｅは、登録されたファイル記述子（例えば、ソケット、パイプ、ドア）を記録し、イベントが受け取ったときに通知を受けるＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトを特定するためのテーブルまたはその他の構造を含む。例として、１つまたは複数のプロセッサ・スレッドが、各ＰｏｌｌＴａｂｌｅに専用であり、ＰｏｌｌＴａｂｌｅのファイル記述子をポーリングすること、イベントを検出すること、および担当のＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクトに通知することを担う。ＰｏｌｌＴａｂｌｅの中のエントリの数は、ファイル記述子が追加され（例えば、新しいクライアント接続のため）、除去される（例えば、クライアント接続が終了されたため）につれて変動することが可能である。エントリの最大数は、構成可能であり、複数のＰｏｌｌＴａｂｌｅが維持される場合、そのポピュレーションの均衡をとり、またはエントリを隔離して、各ＰｏｌｌＴａｂｌｅを最も効率的に操作できるようにすることが可能である。
【００６７】
状態４１２で、新しいＰｏｌｌＴａｂｌｅが、ファイル記述子を記憶するために自らのテーブルを初期設定する。また、ＰｏｌｌＴａｂｌｅは、Ｐｏｌｌｅｒと通信するためのパイプを自動的に記入し、自らのテーブルの中で識別されるファイル記述子のポーリングを開始する。
【００６８】
状態４１４で、ＰｏｌｌＴａｂｌｅは、新しいリスナ・ソケットを登録する必要性を検出する（例えば、パイプ上のイベントのため）。したがって、ＰｏｌｌＴａｂｌｅは、ＲＴＳＰＬｉｓｔｅｎｅｒオブジェクトによって作成されたソケットにＲＴＳＰＬｉｓｔｅｎｅｒに対するポインタまたはリファレンスを記入する。例として、新しいソケットは、担当するＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクト（すなわち、ＲＴＳＰＬｉｓｔｅｎｅｒ）が、そのソケットがポーリングされることを要求するまでポーリングされない。
【００６９】
次に、Ｐｏｌｌｅｒが、登録が完了したことをＲＴＳＰＬｉｓｔｅｎｅｒオブジェクトに通知し、ソケットが記入されたＰｏｌｌＴａｂｌｅを特定することが可能である。
【００７０】
状態４１６で、ＲＴＳＰＬｉｓｔｅｎｅｒが、Ｐｏｌｌｅｒにコンタクトしてソケット上のイベントをイネーブルにし、これにより、そのソケットが、ポーリング・ルーチンに追加される。この時点で、サーバは、クライアント接続およびその他のイベントを受け取る準備ができている。
【００７１】
状態４１８で、クライアント接続が、ＲＴＳＰＬｉｓｔｅｎｅｒソケットに受信され、これにより、ＰｏｌｌＴａｂｌｅスレッドが呼び起こされる。スレッドは、ＰｏｌｌＴａｂｌｅテーブルを検査して、そのソケットを担当するＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクト、つまりＲＴＳＰＬｉｓｔｅｎｅｒオブジェクトを特定する。
【００７２】
状態４２０で、ＰｏｌｌＴａｂｌｅオブジェクトが、ＲＴＳＰＬｉｓｔｅｎｅｒオブジェクトのＣｒｅａｔｅＴａｓｋ（）メソッドを呼び出す。ＰｏｌｌＴａｂｌｅは、イベント・マスク、または生じたイベントのタイプおよびイベントが生じたファイル記述子（ソケット）を示す他の手段を介して、ＲＴＳＰＬｉｓｔｅｎｅｒオブジェクトに対するイベントを特定することができる。次に、Ｐｏｌｌｅｒは、再開を命令されるまで、ＲＴＳＰＬｉｓｔｅｎｅｒソケットのポーリングを自動的に停止する。
【００７３】
状態４２２で、ＣｒｅａｔｅＴａｓｋ（）メソッドが、場合により、Ｔａｓｋオブジェクトの一環として実行され、ＲＴＳＰ接続を受け入れる。受入れ手続きの一環として、接続に対して新しいソケットが生成される。
【００７４】
状態４２４で、別のタイプのＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒ、すなわち、ＲＴＳＰＣｏｎｎｅｃｔｉｏｎオブジェクトがインスタンス化される。このオブジェクトは、例えば、ＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒクラスのＣｏｎｎｅｃｔｉｏｎサブクラスから生成することができる。Ｌｉｓｔｅｎｅｒサブクラスと同様に、Ｃｏｎｎｅｃｔｉｏｎサブクラスは、ＣｒｅａｔｅＴａｓｋ（）メソッドを継承するが、機能性を追加することができる。この場合、Ｃｏｎｎｅｃｔｉｏｎサブクラスは、サーバによって確立された新しい制御接続を表し、ＲＴＳＰＣｏｎｎｅｃｔｉｏｎクラスおよびＲＴＳＰＣｏｎｎｅｃｔｉｏｎオブジェクトは、特定タイプの制御接続を表す。ＲＴＳＰＣｏｎｎｅｃｔｉｏｎオブジェクトは、状態４２２で生成されたソケットにおいて制御コマンドを聴取する。
【００７５】
例として、前述したクライアント接続の扱い（すなわち、接続を受け入れる、ソケットを生成する、ＲＴＳＰＣｏｎｎｅｃｔｉｏｎオブジェクトを作成する）は、単純な手続きであることが可能であり、その場合、ＣｒｅａｔｅＴａｓｋ（）メソッドの呼出しが、新しいＴａｓｋオブジェクトを生成しなくてもよい。ただし、以下に説明するとおり、他のイベントが、より複雑な手続きを必要とする可能性があり、その場合、ＴａｓｋオブジェクトおよびＴａｓｋＱｕｅｕｅの使用が妥当である可能性がある。
【００７６】
状態４２６において、ＲＴＳＰリスナ・ソケットに関して前述したのと同様の手続きで、新しいＲＴＳＰ接続のためのソケットがＰｏｌｌｅｒに登録され、ＰｏｌｌＴａｂｌｅに記入される。また、Ｐｏｌｌｅｒが、ＲＴＳＰＣｏｎｎｅｃｔｉｏｎソケットのポーリングを開始するように命令を受ける。
【００７７】
状態４２８で、メディア・コマンドが、ＲＴＳＰ接続を介してサーバにおいてＲＴＳＰＣｏｎｎｅｃｔｉｏｎオブジェクトによって登録されたソケットに受信される。前述したとおり、ＰｏｌｌＴａｂｌｅスレッドが呼び起こされ、イベントを検出し、担当のＰｏｌｌＥｖｅｎｔＣｏｎｓｕｍｅｒオブジェクト（すなわち、ＲＴＳＰＣｏｎｎｅｃｔｉｏｎ）を特定する。
【００７８】
状態４３０で、ＲＴＳＰＣｏｎｎｅｃｔｉｏｎのＣｒｅａｔｅＴａｓｋ（）メソッドが呼び出される。ＲＴＳＰＴａｓｋオブジェクトが作成され、コマンドを扱う、または処理するための必要な情報（例えば、イベントのタイプ、およびイベントが受け取ったソケット）を備える。
【００７９】
状態４３２で、ＲＴＳＰＴａｓｋが、タスク待ち行列に入れられ、最終的に取り出されて実行される。例として、タスク待ち行列がＦＩＦＯ待ち行列として動作し、タスクに割り振るためのスレッドのプールを有することが可能である。タスク待ち行列は、扱われる様々なタイプのイベントに応じて様々なタイプのタスクを受け入れることができる。別法では、異なるタスク待ち行列を異なるタイプのタスクを受け入れるように構成することが可能である。コマンド（例えば、記述する、再生する、一時停止する、取り払う）に応じて、異なるアクションを実行することが可能である。例として、このイベントが完了する前に追加のイベント（例えば、コマンド）がＲＴＳＰＣｏｎｎｅｃｔｉｏｎソケットで受け取った場合、その追加のイベントが、同じＲＴＳＰＴａｓｋオブジェクトによって処理されることが可能である。
【００８０】
ＲＴＳＰＴａｓｋは、完了したとき、状態４３４でＰｏｌｌｅｒにＲＴＳＰＣｏｎｎｅｃｔｉｏｎソケットのポーリングを再開するよう命令する。
【００８１】
図４に関連して説明した手続きは、メディア・ストリーミング・サーバに受け取ったイベントを扱う一方法に過ぎないことが、当分野の技術者には理解されよう。有利なことに、この方法を実施するのに必要とされるプロセッサ・スレッドの数は、イベントを扱う従来の方法と比べて限られたものであり、したがって、非クライアント・イベントのためにより多くのシステム・リソースを残す。詳細には、各クライアント・メディア・ストリームごとに複数の専用ソケットを作成し、スレッドを各ソケットに割り振るのではなく、１つのスレッドが、複数のソケットにおけるイベントを検出するのを担うことが可能である。さらに、それぞれに別々のスレッドが割り振られた複数のＰｏｌｌＴａｂｌｅを使用することができるため、各ソケットに十分な注意が払われることになる。したがって、示した方法は、非常に拡張可能性が高い。
【００８２】
本発明の実施形態の以上の説明は、例示および説明の目的でだけ提示してきた。以上の説明は、すべてを網羅するもの、または本発明を開示した形態に限定するものではない。多くの変更形態および変形形態が当分野の技術者には明白であろう。したがって、以上の開示は、本発明を限定するものではなく、本発明の範囲は、頭記の特許請求の範囲によって定義される。
【図面の簡単な説明】
【図１】 本発明の実施形態によるメディアをストリーミングするように構成されたサーバを描いたブロック図である。
【図２】 本発明の実施形態による複数のクライアント接続の間で通信ソケットを共用するように構成されたメディア・ストリーミング・サーバの一構成を示すブロック図である。
【図３】 本発明の実施形態によるメディア・ストリーミングに関連するイベントを扱うように協働するプログラム・オブジェクトの一構成を描いた図である。
【図４Ａ】 本発明の実施形態によるメディア・ストリーミング・イベントを扱う一方法を示す流れ図である。
【図４Ｂ】 本発明の実施形態によるメディア・ストリーミング・イベントを扱う一方法を示す流れ図である。

Claims (23)

1. サーバ・クライアントにサービスを提供するように構成されたコンピュータ・サーバ中のソケットで受け取ったイベントを扱う方法であって、
   ソケットをポーリングして前記ソケットで受け取ったイベントを検出するように構成されたポーリング・モジュールを実行することと、
   それぞれのソケットがイベント・コンシューマに関連づけられている第１の複数のソケットを前記ポーリング・モジュールに登録することと、
   前記第１の複数のソケットのなかの第１のソケットにおいて第１のイベントが受け取られたとき、該第１のソケットに関連付けられている第１のイベント・コンシューマに通知することと、
   該第１のイベント・コンシューマが前記第１のイベントを扱うタスクを呼び出すことと
   を含み、
   前記コンピュータ・サーバはストリーミング・サーバであり、前記ソケットは、
   前記サーバ・クライアントからのストリーミング要求を受信するためのＲＴＳＰソケットであって該サーバ・クライアント専用のＲＴＳＰソケットと、
   前記ストリーミング・サーバによって該要求にしたがったストリーミングを開始するためのＲＴＰソケットであって、複数のサーバ・クライアントに共有されるＲＴＰソケットと
   を有している方法。
2. 前記サーバ・ソケットは、さらに、サーバ・クライアントとストリーミング・サーバとの間で、品質情報を交換するためのＲＴＣＰソケットであって、複数のサーバ・クライアントに共有されるＲＴＣＰソケットを含む請求項１に記載の方法。
3. 前記ポーリングのために前記第１の複数のソケットの間で第１のプロセッサ・スレッドが共用され、
   前記イベント・コンシューマによって呼び出されたタスクの前記実行に１つまたは複数のプロセッサ・スレッドが割り振られる請求項２に記載の方法。
4. 前記ポーリング・モジュールに第２の複数のソケットが登録され、前記第２の複数のソケットの中の前記ソケットの各々が、イベント・コンシューマに関連付けられることをさらに含み、
   前記第２の複数のソケットの間で第２のプロセッサ・スレッドが共用される請求項３に記載の方法。
5. 前記イベント・コンシューマが、プログラム・オブジェクトであり、かつ前記イベント・コンシューマの各々が、 接続要求イベントを扱うように構成されたリスナ・コンシューマ、 メディア・ストリーミング・コマンド・イベントを扱うように構成された接続コンシューマ、およびメディア・ストリーム品質イベントを扱うように構成されたレシーバ・コンシューマのセットのなかのどれかである、
   前記リスナ・コンシューマ、前記接続コンシューマ、および前記レシーバ・コンシューマが、単一イベント・コンシューマ・インターフェース・クラスの実装形態である請求項４に記載の方法。
6. 前記第１のイベントが、クライアントからの接続要求を含み、前記第１のイベント・コンシューマが、前記接続要求に応答して第２のソケットを介してクライアント接続を確立するように構成されたリスナ・イベント・コンシューマである請求項３に記載の方法。
7. 前記第１のイベントが、メディア・ストリーミング・コマンドを含み、前記第１のイベント・コンシューマが、前記メディア・ストリーミング・コマンドを実行するように構成された接続コンシューマである請求項４に記載の方法。
8. 前記第１のイベントが、メディア・ストリーム品質情報を含み、かつ前記第１のイベント・コンシューマが、前記メディア・ストリーム品質情報に従って前記メディア・ストリームを調整するように構成されたレシーバ・コンシューマである請求項４に記載の方法。
9. クライアントにメディアをストリーミングするように構成されたサーバによって受け取られるイベントを扱う方法であって、
   前記サーバの登録されたソケットにて受け取られるイベントを検出するよう１つまたは複数の登録されたソケットをポーリングすることであって、該それぞれの登録されたソケットは前記受け取られるイベントを扱うように構成されたイベント・コンシューマに関連している、ポーリングすることと、
   特定のクライアントに専用の第１のソケットにおいて該特定のクライアントからのストリーミングの要求を第１の接続を介して受け取ることと、
   前記要求を、前記第１のソケットに関連している第１のイベント・コンシューマに通知することと、
   前記要求に応答して確立された第２の接続を介して前記メディアのストリーミングを開始するための第２のソケットであって複数のクライアントによって共有される第２のソケットを登録することと、
   を含む方法。
10. 前記要求に応答して確立された第３の接続を介してストリーミングされるメディアの品質に関するデータを受け取るための第３のソケットであって複数のクライアントによって共有される第３のソケットを登録すること
    をさらに含む請求項９に記載の方法。
11. コンピュータによって実行されたとき、クライアントにメディアをストリーミングするように構成されたサーバによって受け取られるイベントを扱う方法を、前記コンピュータに行わせる命令を記憶するコンピュータ可読記憶媒体であって、前記方法が、
    前記サーバに受け取られたイベントに関して１つまたは複数の登録されたサーバ・ソケットをポーリングすることであって、該それぞれの登録されたソケットは前記受け取ったイベントを扱うように構成されたイベント・コンシューマに関連している、ポーリングすることと、
    特定のクライアント専用の第１のソケットにおいて該特定のクライアントからのストリーミング要求を第１の接続を介して受け取ることと、
    前記ストリーミング要求を、該第１のソケットに関連している第１のイベント・コンシューマに通知することと、
    前記ストリーミング要求に応答して確立された第２の接続を介してメディアをストリーミングするための第２のソケットであって複数のクライアントによって共有される第２のソケットを登録することと、
    を含む、媒体。
12. 前記方法が、前記ストリーミング要求に応答して確立された第３の接続を介して前記クライアントにストリーミングされるメディアの品質に関するデータを受け取るようための第３のソケットであって複数のクライアントによって共有される第３のソケットを登録すること、をさらに含む、媒体。
13. サーバ中のサーバ・ソケットで受け取ったイベントを扱うためのデータ構造を含むコンピュータ可読記憶媒体であって、前記データ構造が、
    イベントを受け取るように確立されたサーバ・ソケットを特定するようにそれぞれが構成された複数のソケット識別子と、
    前記ソケットの各々に関連づけられたイベント・コンシューマであって、１組のタスクを呼び出すことによってイベントを扱うように構成されたイベント・コンシューマを特定するためのリファレンスと
    を含み、
    前記イベントを受け取ったサーバ・ソケットのソケット識別子を得るために前記複数のソケットの間で単一のプロセッサ・スレッドが共用され、
    前記得られたソケット識別子を持つサーバ・ソケットに関連づけられたイベント・コンシューマであって前記リファレンスによって特定されたイベント・コンシューマによって呼び出された前記タスクの前記実行に１組のプロセッサ・スレッドが割り振られるよう構成され、
    さらに、
    前記サーバはメディア・ストリーミング・サーバであり、前記サーバ・ソケットは、
    サーバ・クライアントからのストリーミング要求を受信するためのＲＴＳＰソケットであって該サーバ・クライアント専用のＲＴＳＰソケットと、
    前記ストリーミング・サーバによって該要求にしたがったストリーミングを開始するためのＲＴＰソケットであって、複数のサーバ・クライアントに共有されるＲＴＰソケットと
    を有する媒体。
14. 前記サーバ・ソケットは、さらに、サーバ・クライアントとストリーミング・サーバとの間で、品質情報を交換するためのＲＴＣＰソケットであって、複数のサーバ・クライアントに共有されるＲＴＣＰソケットを含む、請求項１３に記載の媒体。
15. メディア・ストリーミング・イベントを扱うための装置であって、
    クライアントからメディア・ストリーミング・イベントを受け取るように構成されたソケットをポーリングするように構成されたポーリング・モジュールと、
    前記ポーリング・モジュールによってポーリングされる第１のセットのソケットを含むポールテーブルと、
    前記第１のセットのソケットのなかの第１のソケットを介してメディア・ストリーミング制御接続の要求を受信し、前記第１のセットのソケットのなかの第２のソケットを介して前記要求されたメディア・ストリーミング制御接続を確立するように構成されたリスナ・モジュールと、
    前記第２のソケットを介してメディア・ストリーミング・コマンドを受け取るように構成された接続モジュールと、
    メディアをストリーミングするように構成された第３のソケットと
    を含み、
    前記第２のソケットが特定のクライアント専用であり、前記第３のソケットが複数のクライアントに共有される装置。
16. さらに、複数のクライアントに共有される第４のソケットであって、クライアントに品質情報を送るための第４のソケットを有した請求項１５記載の装置。
17. メディア・ストリームに関する品質情報を受け取るように構成されたレシーバ・モジュールをさらに含む請求項１５に記載の装置。
18. 前記第３のソケットを介して前記クライアントにストリーミングを行うため、メディア・サーバからメディアを受け取るように構成されたレシーバ・モジュールをさらに含む請求項１５に記載の装置。
19. 前記リスナ・モジュールおよび前記接続モジュールのどちらかによって呼び出されたタスクを待ち行列に入れるように構成されたタスク待ち行列をさらに含み、前記タスク待ち行列の中に入れられたタスクを実行するために１組のスレッドが割り振られる請求項１５に記載の装置。
20. 前記第２のソケットを作成するように前記リスナ・モジュールによって呼び出されるタスク・モジュールをさらに含む請求項１５に記載の装置。
21. 前記接続モジュールを作成するように前記リスナ・モジュールによって呼び出されるタスク・モジュールをさらに含む請求項１５に記載の装置。
22. 前記メディア・ストリーミング・コマンドを実行するように前記接続モジュールによって呼び出されるタスク・モジュールをさらに含む請求項１５に記載の装置。
23. 前記リスナ・モジュールおよび前記接続モジュールが、メディア・ストリーミング・イベントを受け取るように構成されたプログラム・オブジェクト・クラスから生成されるプログラム・オブジェクトである請求項１５に記載の装置。

Images