JP6404915B2 - データの自動圧縮 - Google Patents

Description

本文書は、特にアプリケーションの分散処理の文脈において、データが符号化された様式で転送されるかを自動的に決定する制御ユニットおよびシステムに関する。

近年、データ、コンピュータプログラムおよびアプリケーションは益々、ネットワーク中心のデータセンター（「クラウド」）において格納され実行されるようになっている。しかしながら、特に、クラウドにおけるメディアデータの分散リアルタイム処理の技術分野において、帯域幅およびエンドツーエンド遅延制約のために、リアルタイムメディアの処理は、ネットワークリンクを横断した伝送データに関する敏感さを特に必要とする。

サービス型プラットフォーム（ＰａａＳ：Ｐｌａｔｆｏｒｍ−ａｓ−ａ−Ｓｅｒｖｉｃｅ）手法において、ネットワークの異なる部分に配置された処理ノード上に分離可能なソフトウェアコンポーネントから構成されるアプリケーションを自動的に配布する機能が提供される。共有データの局所性を利用して伝送ネットワーク内のトラフィックを最小化し、処理ノードのリソース利用を最適化し、ネットワーク内のユーザ一の位置に近い遅延に敏感なタスクを処理することでユーザ体験を改良するために、この配布は利用される。クラウドベースの処理環境において、別個の処理ノード上で実行される別々のソフトウェアタスクの間の異なるデータ伝送シナリオが適用され得る。典型的なシナリオは、エンドデバイスへの、およびエンドデバイスからネットワークの向こう側のメディア処理ノードへのメディアデータ伝送、単一のデータセンター内の処理ノード間のメディアデータ伝送、および異なるデータセンター内に配置された処理ノード間のメディアデータ伝送である。

サービスプラットフォーム上の分散処理から利益を得る典型的なアプリケーションシナリオは、たとえばビデオチャットである。ビデオチャットのシナリオでは、たとえば、人々のグループが、仮想の共有されたビデオ環境／ビデオチャットルームに参加する。各個人は、自身のカメラのビデオデータをクラウドにストリーミングする。ビデオチャットサービスは、そのような共有環境内に集まっているユーザの全てのメディアストリームを結合し、各参加者に対する仮想ルームの個人用ビューを生成する（すなわち、処理する）。したがって、仮想ルーム内の各個人は、全ての（他の）参加者の個人用のレンダリングされたビューを受信する。

ビデオチャットなどのアプリケーションが、クラウド内の異なる処理ノードを横断して実行される別個の処理部分（すなわち、処理コンポーネント）に分割できると仮定される。典型的なシナリオは、以下を含む：
− データ発生源の近くに位置する処理リソース上に配置されることが好ましい、カメラ信号の前処理、たとえば背景減算、顔または行動検出、たとえば「誰が話しているか」の機能。
− 仮想カメラのパン／チルトおよびズーム要素を選択することで高解像度を有する現実のカメラの信号から抽出されるべきビデオの特定の部分を決定するためのユーザのインタラクションにより制御されるモジュール。
− 全ての参加者に対して「遅延の中心」に配置されることが好ましい、クラウド内の処理リソース上のチャットルーム内の人々の異なるビデオ信号の全てをマージさせるビデオ混合機能。
− エンドユーザの対話型ジェスチャまたは他の手段などにより制御される、このユーザの近くに配置された処理リソース上に配置されることが好ましい、個人視点レンダリング。

たとえば、ビデオチャットアプリケーション内の処理部分は、背景抽出とすることができる。この部分は、色変換、実際のフレームの背景モデルとの比較、背景モデルの統計的更新、前景マスク生成などの別個のタスクを行ういくつかの処理コンポーネントから構築および構成されることがある。

たとえばプラットフォームシナリオでは、コンポーネントは、送信コンポーネントの出力ポートを１つまたは複数の受信コンポーネントの入力ポートに接続するメッセージパッシングインターフェースを介して通信することができる。開発者は、自身のアプリケーションの実行インスタンスを、そのアプリケーションを構成する異なる処理要素から構成される動的サービス論理グラフを編成することで、作成し維持することができる。

グラフの操作には、コンポーネントの作成、修正または除去、および動的な方式でコンポーネント間の接続の確立または解放が含まれる。開発者の視点からは、プラットフォームは単一の仮想処理リソースのように振る舞い、前述のように物理的な基盤リソース上へ適切にアプリケーションの異なるコンポーネントを配備するのはプラットフォームの仕事である。

典型的には、特定のタスクごとに必要な処理能力は、異なるメディアパラメータに依存する。パラメータは、画像解像度、フレームレート、参加者数などとすることができる。さらに、所望の機能を実行するのに必要なリソースの数は、リソース能力と、（すぐに変動し得る）個々の処理ノードの現在の負荷状況とに依存することがある。

したがって、どのようにアプリケーションの異なるコンポーネントが、異なる処理ノードを横断して最も効率良く配布されるかをアプリケーション開発者が予測することは一般的には困難である。プラットフォームのみが必要な情報を有するので、リソース上のサービス実行時に出現するリソースボトルネックを、このリソース上で現在実行中のいくつかの処理部分／コンポーネントを現在あまり利用されていない他のリソースへ再配布することにより解消する方法を決定するのはプラットフォームの仕事である。

しかしながら、ビデオチャットサービスなどのビデオアプリケーションのコンポーネントを配布するための根本的な問題は、多数のメディア処理コンポーネントが主に一連の画素値（すなわち、単一のビデオフレーム）に作用するので、コンポーネント間で交換されるデータの量が大量であることである。このように、コンポーネントは通常、画素値の完全なフレーム、すなわち非圧縮のビデオフレーム（生データ）をその出力ポートに送信する。これにより、生の「ビデオ」トラフィックが、異なる処理ノードを接続するネットワーク上で伝送、すなわち交換される必要があるので、アプリケーションコンポーネントを異なる処理ノードにわたって分割することが困難となり、したがって、ネットワークの輻輳をもたらすことがある。したがって、異なる処理リソース上で実行されるコンポーネント間で交換されるメディアデータは、有意義な方法で圧縮される必要がある。

開発時のサービスグラフの開発者は、どのようにプラットフォームがサービス実行時に異なるサービスコンポーネントを処理リソースにわたって分割することになるかを知らないので、必要に応じて通信経路内に圧縮（すなわち、符号化／復号）を自動的に含むプラットフォーム機能が必要である。

本文書は、特に、ネットワーク中心のデータセンターにおいて互いに接続された処理ノードなどの前記処理ノードのうちの少なくとも２つを有するシステムにおいて使用可能な制御ユニット、システムおよび方法を提供する技術的問題に対処する。制御ユニット、システムおよび方法により、データの符号化および復号が必要かを自動的に決定し、送信および受信コンポーネントの間のデータ依存圧縮メカニズムを動的にインスタンス化することが可能となる。

ヘッダおよび転送されるデータ（ペイロード）を備え、外部ネットワークインターフェースを通過する、メッセージのデータ形式を分析することで、本明細書に記載の態様は、送信機側にデータ形式依存エンコーダを挿入することと、圧縮形式（すなわちデータ形式）を示す制御メッセージを受信機側に送信することと、圧縮器のインスタンスを用いて各後続のメッセージを動的に圧縮することとを可能にする。さらに、メッセージで転送されるデータは、遠隔側で復号することができ、復号後に受信コンポーネントに配信することができる。

これら全てがそのようなサービスの開発者に透過的に実行できることに留意されたいが、その理由は、コンポーネントが同一または別個のリソース上で実行される場合にサービス論理フローからは注意が払われる必要がないためである。メディア圧縮は、基本となるプラットフォームにより自律的に、および必要な場合にのみ、コンポーネントの通信経路に含まれる。

さらに、逆の部分もカバーされていることに留意されたい。異なるリソース上で以前に動作していた２つのコンポーネントが何らかの理由でサービス実行時に同一のリソース上に配置された場合に、以前に外部であった通信経路は内部になるので、メディア符号化および復号機能はプラットフォームにより通信経路から自動的に除去されることになる。

したがって、本明細書で提示された制御ユニットおよびシステムは、通信チャネルを介して接続されたコンポーネントが、データが受信されたのはローカルのコンポーネントからか遠隔のコンポーネントからかの違いに気付かず、同時に、ネットワークリンク上のデータレートが低減されるという技術的利点を有する。したがって、圧縮方式全体が開発者から隠されており、開発者はコンポーネントのみに注意を払い、コンポーネントは、それらの接続内で圧縮が生じたことに気付かない。

具体的には、本文書は、詳細にはコンポーネント間の通信チャネルが何らかの理由でノード内部の通信チャネルの代わりに外部伝送ネットワークを使用することを検出することで、送信および受信コンポーネントの間のデータ依存圧縮メカニズムを動的にインスタンス化することができる、特にネットワーク中心のデータセンター、すなわちクラウド環境のための制御ユニット、自律システムおよび方法を提供する。

一態様によれば、制御ユニットは、２つの処理ノードの間の通信チャネルが処理ノードの境界を横断するかを判定するように構成することができる。通信チャネルが処理ノードのうちの１つの境界を横断する場合に、制御ユニットは、通信チャネルを経由して転送されるデータの符号化／復号が必要かを決定するようにさらに構成することができる。制御ユニットは、たとえば送信処理ノードまたは受信処理ノードなどの処理ノードの一部とすることができる。あるいは、またはこれに加えて、制御ユニットは、異なるデータセンターに配置された異なる処理ノードを備えるシステムの別個のエンティティにより提供することができる。

さらなる態様によれば、ネットワークにより接続された少なくとも２つの処理ノードを備え得るシステムが提供される。各ノードは、実行環境および少なくとも１つの処理コンポーネントを備えることができる。各実行環境は、データを送信するコンポーネントの発信ポートを、データを受信するコンポーネントの着信ポートに、通信チャネルを介して接続するための手段を含むことができる。システム、好ましくはシステムの制御ユニットは、上述のように、通信チャネルがノードの境界を横断するかを判定するように構成することができる。さらにシステム、好ましくはシステムの制御ユニットは、通信チャネルがノードの境界を横断する場合に、通信チャネルを経由して転送されるデータの符号化／復号が必要かを決定するように構成することができる。

ノードの境界の横断は、通信チャネルが外部伝送ネットワーク、たとえばローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）を使用する場合に、検出することができる。たとえば、ノードが、プロセッサ、記憶手段およびネットワークインターフェースを備えるユニットである場合に、外部伝送ネットワークは、ノードを、より具体的にはノードのネットワークインターフェースを互いに接続するネットワークであると定義することができる。ノードの境界の横断は、ネットワークリンクの横断と定義することができる。ノードの境界の横断は、ネットワークプロトコル、たとえばＲＴＰ、ＵＤＰ、ＴＣＰ、ＩＰが通信チャネルを経由してデータを送信するために使用される場合に検出できることが好ましい。たとえば、ある処理コンポーネントがあるネットワークノード上で動作し、最初のコンポーネントと通信する他の処理コンポーネントが他のネットワークノード上で動作する場合に、ネットワーク境界は横断される。

以下、「システム」という用語が「プラットフォーム」という単語と交換できることに留意されたい。「データ」という用語は、システムの部分／ノード／コンポーネントの間で交換／転送される情報を示すことができる。「メッセージ」という用語は、メッセージのヘッダと、送信すべきデータ（ペイロード）とを実質的に意味する。

「符号化／復号」という用語は、符号化および／または復号を示す。具体的には、メッセージ／データがそこから送信される一方の側において、データが符号化（圧縮）され、他方側すなわち受信側において、データが復号されることを意味する符号化および復号を示す。

以下では、第１のコンポーネントがデータを送信するコンポーネント、すなわち「送信コンポーネント」であること、また、第２のコンポーネントがデータを受信するコンポーネント、すなわち「受信コンポーネント」であることが仮定されることになる。

しかしながら、システムが３つ以上のノードおよび３つ以上のコンポーネントを備えることができることに留意されたい。さらに、複数の異なる通信チャネルを、２つ以上のノード間に確立することができる。具体的には、送信コンポーネントは、１つまたは複数の通信チャネルを介して少なくとも１つの受信コンポーネントに接続されるように構成することができる。

「受信ノード」および「送信ノード」という用語は、受信／送信コンポーネントを備えるノードを示す。ノードという用語は、少なくとも１つのプロセッサと、少なくとも１つの記憶デバイスと、少なくとも１つのネットワークアダプタとを好ましくは備えるコンピューティングリソースまたはホストを示すことができる。言い換えれば、ノードは、ネットワークにおいて他のノードと接続された完全に動作可能なスタンドアローンの処理ユニットであることが好ましい。

さらなる態様によれば、送信コンポーネントは、１つまたは複数の通信チャネルを介して少なくとも１つの受信コンポーネントに接続されるように構成することができる。（１つまたは複数の）コンポーネントの間に１つまたは複数の通信チャネルを確立することで、アプリケーションコンポーネントを柔軟に配布することができる。

さらに、システムは、各確立された通信チャネルに関する情報を含むテーブルを備えることができる。前記情報は、各通信チャネルに対して、その通信チャネルの送信コンポーネントおよび受信コンポーネントのポートを含むことができる。さらに、前記情報は、受信コンポーネントが送信コンポーネントと異なるノード内に配置されている場合に識別子を含むことができる。識別子は、遠隔の受信ノードのネットワーク位置を識別することができる。テーブルは、特定の（専用の）処理ノード内に配置し格納することができ、場合によりローカルコピーが各処理ノードで利用可能であることが好ましい。さらに、各処理ノードは、たとえば前記ノード上で動作する処理コンポーネントに関する情報のみを含む、テーブルの部分的なコピーを有することができる。

テーブルにより、概観を維持することができ、および、複数のコンポーネント間の接続に関して最も関連性が高い情報に素早くアクセスすることが可能となる。識別子は、ノードの境界の横断の判定が、より素早くより少ないコンピューティングリソースを用いて実行できることを支援する。

システム、特に、対応する送信コンポーネントをホストする制御ユニットおよび／または実行環境は、前記テーブル内の検索操作により通信チャネルがノードの境界を横断するかを検出するように構成することができる。検索操作は、コンポーネントが移動されたこと、すなわち処理コンポーネントの再割当を示すことができ、または、遠隔ホスト上のコンポーネントとの接続の作成を示すことができるエントリが設定されているかを検出するように構成することができる。エントリは、前記テーブルに設定される第１のフラグなどとすることができる。あるいは、またはこれに加えて、検索操作は、受信コンポーネントのノードの位置を発見するために前記識別子を読み出すように構成することができる。検索操作により、通信チャネルがノードの境界を通過するかの判定が、ほぼ即時に、コンピューティングリソースを使用し過ぎることなく実行できるようになる。

さらに、たとえば、通信チャネルが２つのコンポーネントの間に確立されているときに、送信および／または受信コンポーネントがその後あるノードから他のノードへ移動された場合に、システム、特に実行環境は、前記テーブル内の前記情報に前記エントリを追加するようにさらに構成することができる。エントリはコンポーネント移動を明示することができ、これにより、通信チャネル、特に既存の通信チャネルがノードの境界を横断するかをより素早く判定できるようにする。

さらに、システムは、転送されるデータが所定のサイズを超過した場合に符号化／復号が必要であると決定することができ得る。具体的には、送信または受信側でのデータストリームのサイズまたはボリューム（ネットワークインターフェース容量）、および／または、物理ネットワークチャネルの容量制限が、関心の対象である。典型的には、ビデオ関連データまたは高音質音声データが、符号化／復号要件をトリガする。

システムは、転送されるデータが所定のデータ形式を有する場合に、すなわちデータタイプの形式に基づいて、符号化／復号が必要であると決定することができ得る。所定のデータ形式は、たとえばメディア形式を含むことができる。これは、システムが、一般的にはメディアデータ、たとえば画像データ形式、音声データ形式、および／またはビデオデータ形式を有するデータが、あるノードから遠隔ノードへ転送される場合に、符号化された／復号するように構成することができることを意味する。

さらに、データが、フレーム単位で送信されるビデオデータである場合に、符号化／復号が必要である場合がある。コンポーネントが画素値の完全なフレーム、すなわち非圧縮ビデオフレーム（生データ）をその出力ポートに送信する場合、大量のデータがコンポーネント間で通信チャネルを介して交換される。これにより、アプリケーションコンポーネントを異なる処理ノードにわたって分割することが困難になる場合がある。しかしながら、本明細書に記載のデータの自動圧縮によって、ビデオフレームの送信も可能となるので、ビデオデータアプリケーションのコンポーネントの自動配布が可能となる。

システムは、送信および受信ノードの一方または両方が所定の作業負荷で動作する場合に符号化／復号が必要であると決定することができ得る。これは、ノードが既に高い作業負荷で動作しているときに、符号化／復号に関する追加の作業負荷が、ノードのうちの少なくとも１つのノードの過負荷をもたらすことになる場合に、符号化／符号化が初期化されないケースを含むことができる。

一態様によれば、送信処理ノードは、少なくとも１つの実行環境と、少なくとも１つの処理コンポーネントと、通信チャネルを経由してデータを送信するために受信処理ノードと通信チャネルを介して接続可能な少なくとも１つの発信ポートとを備えることができる。実行環境は、通信チャネルを確立するように構成することができる。受信処理ノードは、制御ユニットを備えることができる。さらに、送信処理ノードは、符号化が必要であると決定された場合に、エンコーダをインスタンス化し、インスタンス化されたエンコーダのタイプに関して受信処理ノードに知らせるように構成することができる。さらに、受信処理ノードは、少なくとも１つの処理コンポーネントと、通信チャネルを経由してデータを受信するために送信ノードと通信チャネルを介して接続可能な少なくとも１つの着信ポートとを備えることができる。送信処理ノードは、制御ユニットを備えることができる。受信処理ノードは、符号化が必要であると決定された場合に、送信処理ノードにおいてインスタンス化されたエンコーダのタイプに関する情報に基づいて、デコーダをインスタンス化するようにさらに構成することができる。

さらに、実行環境および少なくとも１つの処理コンポーネントを備え得る（処理）ノードを提供することができる。実行環境は、データを送信するコンポーネントの発信ポートを、異なるノードに配置され得るデータを受信するコンポーネントの着信ポートと、通信チャネルを介して接続するための手段を含むことができる。ノード（たとえば、ノードの制御ユニット）は、通信チャネルがノードの境界を横断するかを判定するように構成することができる。さらに、ノードは、通信チャネルがノードの境界を横断する場合に、外部通信チャネル、たとえばノードを接続する通信ネットワーク上のトラフィックを削減するために、通信チャネルを経由して転送されるデータの符号化／復号が必要であるかを決定するように構成することができる。

ノードは、さらなる処理ノードを備えるネットワークの一部とすることができる。ノードは、ネットワーク内で互いに接続することができる。上記で説明されたノードの利点は、データが符号化された様式で通信チャネルを経由して転送されるべきであるかをノードが自動的に決定できることである。たとえば、ノードが、少なくとも１つのプロセッサ、少なくとも１つの記憶手段、およびネットワークインターフェースを有するユニットであると仮定すると、ノードは、通信チャネルが前記インターフェースを介して前記ユニットの外部に接続する場合に、通信チャネルが前記ノードの境界を横断すると判定することができる。言い換えれば、ノードは、通信チャネルが前記ノードのネットワークインターフェースを異なるノードの異なるネットワークインターフェースに接続する場合に、前記ノードの境界が横断されると判定することができる。ノードは、通信チャネルを経由して送信されるデータのタイプが特定のタイプ、たとえば音声、画像またはビデオデータなどのメディアデータタイプである場合に、符号化が必要であるとさらに決定することができる。

上記のシステムの機能および態様を各ノードに組み込むことができることに留意されたい。たとえば、通信チャネルがノードの境界を横断するか、および符号化／復号が必要であるかの決定は、送信または受信ノードの一方、特にその実行環境により実行することができる。テーブルは、ノードの機能により取り扱うことができ、検索操作は、送信ノードなどの機能により実行することができる。あるいは、ネットワーク全体の制御インスタンスを、これらの機能を実装するために提供することができる。

さらに、システムは、各（処理）コンポーネントが個別に／別々にノードにより処理可能となるように、ノードにわたってアプリケーションの処理コンポーネントを自動的に配布できるアプリケーション配布機能を備えることができる。典型的なアプリケーションは、たとえばビデオチャット、音声チャット、ビデオストリーミングなどのマルチメディアアプリケーションの処理に関連する。

したがって、システムは、ネットワークリンクの横断（すなわち、２つのコンポーネント間の処理ノード外部通信）が検出された際に随時、サービスコンポーネント間でビデオデータまたは任意の他のメディアデータなどのデータを伝送する通信チャネルのデータストリームにおいて、動的に圧縮機能をインスタンス化し含められるようにすると有利である。

たとえば、プラットフォーム、たとえばマルチメディアコンテンツクラウドにおいて、アプリケーション開発者は、いつメッセージが２つのコンポーネント間に確立された通信チャネル上のネットワークリンクを横断するかを知らず、その理由は、コンポーネント配置決定がプラットフォームにより実行時に動的に実行されるためである。提案されたシステムでは、処理ノード境界（すなわち、外部ネットワークインターフェースまたはネットワークリンク）が通信チャネルにより通過され、および／または、予想データサイズまたはデータレートがネットワークリンクに過負荷を導入し得る場合に随時、実行環境は圧縮機能をインスタンス化する（すなわち、送信コンポーネントをホストするリソース上のエンコーダ、および受信コンポーネントをホストするリソース上のデコーダをインスタンス化する）。

そのような場合、実施形態によれば、実行環境は、基本コーデック（コーダおよびデコーダ）形式を決定し、メッセージパッシングインターフェースの一部として送信側のエンコーダおよび受信側のデコーダを自動的にインスタンス化する。たとえば、プラットフォームシナリオでは、コンポーネントは、送信コンポーネントの出力ポートを１つまたは複数の受信コンポーネントの入力ポートに接続するメッセージパッシングインターフェースを介して通信することができる。コーデックのインスタンス化は、たとえば、ローカルコンポーネントおよび遠隔コンポーネントの間の新しい通信チャネルが確立された場合、または、プラットフォームリソース管理アルゴリズムがコンポーネントの１つを他の処理リソース／ノードに移動させることを決定した際に既存のローカル接続が遠隔接続となった場合に、生じることがある。

コーデック形式は、受信コンポーネントの着信ポートまたは送信コンポーネントの出力ポートのメッセージタイプ、２つのコンポーネント間のデータ交換に使用される論理リンクの特定の（アプリケーション開発者による所定の）プロパティまたは接続に沿って通過するメッセージのタイプにより、決定することができる。

接続、すなわち通信チャネルを横断したメッセージを送信した時に、プラットフォーム機能は、データをエンコーダに渡して圧縮し、外部ネットワーク上で標準的なネットワークプロトコル（たとえばＲＴＰ、ＵＤＰ、ＴＣＰ、ＩＰ）を用いて送信し、遠隔側で復号し、最後に受信コンポーネントに元の非圧縮形式で渡す。データの伝送は、アプリケーションの分散処理を容易化するために行われる。アプリケーションのコンポーネントの処理は、ネットワークにおいて互いに接続された処理ノードにより行われる。

さらなる態様は、システム内のデータ通信のための方法に関する。システムは、少なくとも２つのノードを有することができる。ノードは、実行環境および処理コンポーネントを有することができる。実行環境は、データを送信可能な処理コンポーネントの発信／アウトバウンドポートをデータを受信可能な処理コンポーネントの着信ポートと通信チャネルを介して接続するための手段を含むことができる。方法は、通信チャネルがノードの境界を横断するかを判定するステップを備えることができる。これは、送信ノードおよび受信ノードの間の通信チャネルを確立した時などに、行うことができる。さらに、方法は、特にノードの境界が横断されると判定された場合に、通信チャネルを経由して転送されるデータの符号化／復号が必要であるかを決定することを備えることができる。方法は、符号化／復号が必要であると決定された場合に、送信コンポーネントのノード内のエンコーダと、受信コンポーネントのノード内のデコーダとを初期化することを備えることができる。方法は、転送されるデータを送信コンポーネントからエンコーダに提供し、エンコーダ内でデータを符号化することをさらに含むことができる。符号化されたデータを通信チャネルを経由して受信ノードに送信することができる。

この方法には、アプリケーションを分散的に処理する、すなわちアプリケーションが相異なる処理ノードにより処理されるシステムなどに生じるデータトラフィックを柔軟に削減できるように、通信チャネルを経由して送信されるデータを自動的に符号化／復号できるという利点がある。

さらに、エンコーダが送信コンポーネントのノード内でインスタンス化された後に、インスタンス化されたエンコーダのタイプに関する情報を含み得る制御メッセージ（情報）が、送信コンポーネントのノードの実行環境などから受信コンポーネントのノードの実行環境などに送信することができる。デコーダは、制御メッセージに含まれる情報に基づいてインスタンス化されることができる。デコーダをインスタンス化した時に、転送されるデータを送信ノードから受信ノードへ通信チャネルを経由して送信できることが好ましい。あるいは、制御情報を、転送されるデータと共に送信することができ、たとえば、転送されるデータを、送信側で適用される符号化／圧縮機能に関する制御情報も含むメッセージ内で送信することができる。制御情報および転送されるデータを１つのメッセージ内で送信することで、ネットワークトラフィックをさらに削減することができる。

したがって、コーデックをインスタンス化するための、および、ノード境界を横断する通信チャネルを経由してデータを送信するためのいくつかの代替の選択肢が存在する。エンコーダが送信側でインスタンス化された後に、制御メッセージを受信ノードに送信することができる。制御メッセージは、エンコーダタイプなどに関する情報を受信側に提出して、対応するデコーダをインスタンス化できるようにする。さらなる選択肢は、エンコーダをインスタンス化でき、転送されるデータを送信側で符号化できることでもよい。この選択肢によれば、続いて、符号化されたデータを含むメッセージであって、たとえばメッセージのヘッダ部分に符号化／圧縮に関する制御情報を含むメッセージを、受信側に転送することができる。したがって、制御情報および転送されるデータの両方は、同時に受信側に到着する。デコーダは、転送された符号化されたデータを復号する前に、メッセージ内の制御メッセージに従ってインスタンス化されることができる。さらに別の選択肢は、通信チャネルを確立した時などに、通信チャネルに対して固定的にインスタンス化され得る所定のコーデックを使用することでもよい。所定のコーデックは、通信チャネルを経由してメッセージ／データを送信する前に、インスタンス化されることができる。たとえば固定的に設定された符号化／復号が、通信チャネルを経由して転送される全てのデータに対して使用されるものとする場合に、所定のコーデックをインスタンス化する選択肢が好ましいことがある。

第２のフラグを転送されるデータに付加することができ、これは、データが圧縮されたデータである場合に、たとえば第２のフラグをデータメッセージのヘッダに設定することで行われる。これは、復号が必要であることを受信コンポーネントのノードに示して復号が必要であることを受信側で素早く検出できるようにするために、行うことができる。さらに、第２のフラグは、送信側のエンコーダにより使用された符号化タイプ形式を受信側に示すために使用することもできる。

方法は、送信側のエンコーダおよび受信側のデコーダが、通信チャネルの確立時に、および通信チャネルを経由してデータを送信する前に、インスタンス化されることを備えることができる。さらに、符号化／復号のタイプは、予想されるデータタイプ、たとえば音声データまたはビデオデータ、および／または通信チャネルを経由して転送されるデータのサイズに基づいて、通信チャネルに対して固定的に事前設定することができる。したがって、開発者は、特定の通信チャネルに対して、前記通信チャネルを経由して送信されるものとするデータなどに関する自身の知識に基づいて、好適なコーデック形式を設定することができる。たとえば、開発者は、ビデオデータのみが転送されると予想して、ビデオコーデックを指定することがある。このようにして、高速なセットアップ時間を達成することができる。

まとめると、アプリケーション開発者が詳細なコンポーネント制御に取り組む必要がなく、さらに高い柔軟性がアプリケーション設計に与えられることが、本明細書で提示された態様の利点である。利用可能なリソース上でのコンポーネントの最適なインスタンス化を発見する責任があるのはプラットフォームであり、サービスの開発者ではない。これにより、開発者は、サービス実行時に変化することさえある、リソース上へのコンポーネントの配置にもはや注意を払う必要がないので、分散クラウド中心メディアサービスを構築するための開発労力が削減される。

上記で概説された態様が、プロセッサを備えるデータ処理装置において実施可能であることに留意されたい。コンピュータメモリに記憶されたコンピュータプログラム命令は、プロセッサにより実行された場合に、態様を実施することができる。以下では、添付の図面を参照して実施形態がさらに説明される。

分散処理コンポーネントの一例の図である。 パイプライン指向メディアフレームワークの一例の図である。 開示されたシステムの主要な概念の図である。 アプリケーションの自動的に配布された処理コンポーネントの一例の図である。

実施形態が、配布可能なビデオおよび他のマルチメディアアプリケーションをホストするクラウドサーバ、エンドデバイスたとえば携帯電話、ビデオおよびマルチメディアコンテンツを記録または表示可能なネットワークカメラおよび他のエンティティ、実際の規格に準拠したネットワークデバイスと提案された符号化形式を組み込んだプラットフォームサービスとの間の接続点として機能するインターネットゲートウェイにおいて技術的に実装可能であることに留意されたい。

プロプライエタリなクラウド環境への提案された解決方法の基本的な組み込みは、標準化なしで可能なはずであるが、同様の問題が、モバイル端末が計算負荷が高いビデオ処理タスクをネットワーク中心のクラウド環境にオフロードする場合の環境などで当てはまるので、ＩＴＵ／ＩＳＯ（ＭＰＥＧ）による潜在的な採用はあり得る。

クラウドベースの処理環境において、特に、別個の処理ノード上で実行される別々のソフトウェアタスクの間の以下のデータ伝送シナリオが適用され得る。１）エンドデバイス（たとえばカメラ、ディスプレイ、スマートフォン）への、およびエンドデバイスから公衆インターネットなどのネットワークの向こう側のメディア処理ノードへのメディアデータ伝送。２）単一のデータセンター内の処理ノード間のメディアデータ伝送。メディア処理は計算が複雑（すなわち高度な処理）であるためにメディア処理タスクが単一の処理ノードから外へ簡単に拡大（ｓｃａｌｅ）するので、このセットアップは行われる。３）たとえばネットワーク内でリソースを伝送して全体のリソース消費を最適化し、たとえばユーザがいる場所の近くに処理を配置してマンマシンインタラクションに関する遅延を制限するために、異なるデータセンター内に配置された処理ノード間のメディアデータ伝送。

本実施形態が、特にケース２）および３）に対処し、エンドデバイスおよびクラウドノードの間の伝送の制御が、たとえばデバイス上で専用のソフトウェアを実行する能力を有することで提供されると仮定したケース１）もカバーすることをここでは留意されたい。

たとえば、サービスプラットフォーム上の分散処理から利益を得る典型的なアプリケーションシナリオは、たとえばビデオチャットである。ビデオチャットのシナリオでは、たとえば、人々のグループが、仮想の共有されたビデオ環境／ビデオチャットルームに参加する。各個人は、自身のカメラのビデオデータをクラウドにストリーミングする。ビデオチャットサービスは、そのような共有環境内に集まっているユーザの全てのメディアストリームを結合し、各参加者に対する仮想ルームの個人用ビューを生成する（すなわち、処理する）。したがって、仮想ルーム内の各個人は、他の参加者の個人用のレンダリングされたビューを受信する。

図１および図２は、コーデック（コーダ（符号化）５およびデコーダ（復号）６）を含む分散コンピューティングノード１への処理コンポーネント３の可能な配布を表す例である。具体的には、図１では、たとえばビデオチャットアプリケーションに関して、どのようにサービス論理およびリソースが、論理的に依存した機能に分割できるかが示されている。可能な配備では、図示されたサービス論理ブロックの各々は、最終的に異なるリソースになり得る。

図２に、パイプライン指向メディアフレームワークを、独立したパイプラインの例示的な詳細と共に示し、各パイプラインは、データ受信機およびエンコーダ／デコーダコンポーネントを、可能な転送ポイントにおいてそれぞれ有している。図２は、具体的には、たとえばカメラ処理、仮想パン／チルト／ズーム、背景抽出、ビデオ混合、および個人用ビューレンダリングなどのコンポーネントなどの異なるアプリケーションタスクを含むサービス論理インスタンス化を示す。

図３に、実施形態によるシステム（プラットフォーム）の主要な設計を示す。好ましい実施形態では、ＩＰベースのインターネット、イーサネット（登録商標）などのネットワークにより接続された少なくとも２つの処理ノード１が、システムに含まれる。システムにより処理されるものとするアプリケーションの処理コンポーネント３は、たとえば、図３の２つの図示のノード１に配布される。言い換えれば、アプリケーションは、複数の部分、たとえば処理コンポーネントまたはサブアプリケーションに分割される。アプリケーション配布機能は、システムのノード１、ここではたとえば、第１のノード１ａおよび第２のノード１ｂに、コンポーネント３を配布する。ノード１の間のデータ交換は、通信チャネル４により可能となる。データ伝送は、たとえば、あるノードから他のノードへメッセージを渡すことで実行されることが好ましい。メッセージは、ヘッダと、ペイロードすなわち送信されるデータとを備えることができる。

より具体的には、メディア処理コンポーネント３をインスタンス化し、修正し、削除するために、各ノード１上で分散処理プラットフォームが実行される。処理コンポーネント（コンポーネント）３は、前記異なるコンポーネント３に分割されるアプリケーションの処理部分である。各コンポーネント３は、プラットフォーム全体で一意の識別子を有する。

たとえば、ビデオチャットアプリケーションは、カメラ信号の前処理、たとえば背景減算、顔または行動検出、たとえば「誰が話しているか」の機能、ユーザが高解像度であり得る現実のカメラのビデオ信号の中を仮想カメラのパン、チルトおよびズーム要素を制御して移動できるようにして低解像度であり得る個人用ビューを生成する対話型モジュール、などのコンポーネントに分割することができる。さらに、コンポーネントは、（全ての参加者に対して「遅延の中心」に配置されることが好ましい）クラウド内の処理リソース上のチャットルーム内の人々の異なるビデオ信号をマージさせるビデオ混合機能、および、エンドユーザの対話型ジェスチャにより制御される、（このユーザの近くに配置された処理リソース上に配置されることが好ましい）個人視点レンダリングとすることができる。

図３は、具体的には、各ノード１が実行環境２を有することを示す。実行環境２は、少なくとも２つのコンポーネント３を、第１のコンポーネント３ａの発信すなわちアウトバウンドポートと第２のコンポーネント３ｂの着信ポートとの間に通信チャネル４をインスタンス化することで接続する手段を有する。そのような接続４は、サービス論理データフローを確立し、ノード上で動作するコンポーネント３の全ての通信チャネル４を記述したテーブルを維持することで、分散された方法で実現することができる。

実施形態では、２つのコンポーネント３の間の新しい接続が、テーブルにエントリを追加することでインスタンス化される。エントリは、どの後続のコンポーネント３が、送信コンポーネント３の発信ポートにより送信される転送データ（たとえばメディアストリーム）の受信コンポーネント３（およびそのポート）であるかを示す。前記テーブルは、プラットフォームにより制御することができる。

さらに、受信コンポーネントが遠隔ノード１に配置されている場合、これは通信チャネル４がノード境界を横断することを意味するが、プラットフォームは、遠隔ホスト（ノード）の識別子を、これはＩＰアドレスであり得るが、テーブルエントリに追加する。

図３はさらに、２つの可能なシナリオを示す。第１のシナリオは、図３の上部に示されており、ここではアプリケーションの２つのコンポーネント３が両方とも同一のノード１に配置されることが示されている。したがって、実行環境２は、エンコーダ５および／またはデコーダ６をインスタンス化することなく、２つのコンポーネント３の間にローカルな通信チャネル４をインスタンス化する。つまり、送信コンポーネント３ａから受信コンポーネント３ｂに転送されるデータ（ペイロード）は、通信チャネル４を経由して符号化されずに送信されることが好ましい。これにより、コンピューティングリソースが維持される。たとえばヘッダとデータであるメッセージの受け渡しは、メモリ参照により実行することができる。

図３の下部に、受信コンポーネント３ｂがノード１ｂ内に配置され、ノード１ｂが、送信コンポーネント３ａを含む他のノード１ａに対して遠隔で配置されることが図示されている。したがって、通信チャネル４を経由したデータ転送は、たとえばネットワークプロトコルを必要とする。２つのコンポーネント３を遠隔配置する理由は、たとえば、プラットフォームが最初にコンポーネント３を異なるノード１上に配置したこと、または、受信コンポーネント３ｂが処理中に、あるノード１から他のノード１に移動されたことであり得る。通信チャネル４が確立された後にコンポーネント３を遠隔ノード１に移動させる一例が、図３の上部に示されている。受信コンポーネント３ａ、３ｂの再配置は、「コンポーネント移動」の矢印で示されている。

一般的に、送信コンポーネント３ａから受信コンポーネント３ｂへデータが転送されるものとする場合、送信コンポーネント３ａは、メッセージタイプ、ペイロード、および、転送されるデータの送信ポートを指定するプラットフォーム機能を呼び出す。

続いて、受信機コンポーネント３ｂの識別子およびそのポートが、テーブルに対する検索操作を用いて検索される。検索操作は、転送されるメッセージの１つまたは複数の受信者が遠隔ホストに配置されているかを決定するように構成される。メッセージの受信機が送信機と同じホストに配置されている場合、メッセージはノード内部のキューに格納され、最後に対象受信コンポーネントに配信される。メッセージの受信機が遠隔ホストに配置されている場合、メッセージは送信され、遠隔ノード上のキューに格納され、最後に受信コンポーネントメッセージハンドラに渡される。このとき、送信機のポートインデックスは、受信機のポートインデックスと置換され、２つのコンポーネント３が完全に切り離される。したがって、送信コンポーネント３ａは、対応するエンドポイント、すなわちメッセージの受信機が配置されている場所を知らず、その理由は、両方のコンポーネント間の唯一のつながりが、実行環境などにより操作されコンポーネント自体がアクセスできないことがあるテーブルに格納された情報により実現されるためである。

プラットフォーム（たとえば、（図３に示されていない）システムの制御ユニット）は、検索操作から、コンポーネント３の間の接続／通信チャネル４がネットワークリンク（２つのノード１の間の境界）を横断するかを認識する。さらに、具体的にはメッセージタイプまたはペイロードサイズを分析することで、データレートによってネットワークリンクの輻輳が生じ得るかを決定することができる。自動圧縮のこの態様は、以下で、特に図３の下部に関してさらに説明される。

最初に、対応するコンポーネント３が遠隔地の処理リソース上で既にインスタンス化されているために接続が確立される場合、または、たとえば負荷分散もしくは他の性能上の理由で、プラットフォームがコンポーネント３を他の処理ノード１に移動させると決定した場合（たとえば図３参照）に、接続が外部となり得ることにさらに留意されたい。

一態様によれば、２つのコンポーネント３の間の通信チャネル４の作成の後、または遠隔ノード１へのコンポーネント３の移動（「コンポーネント移動」）の後に、それぞれのテーブルエントリに関連付けられた第１のフラグが設定される。次のメッセージが通信チャネル４を介して送信され、導入された第１のフラグが設定されている場合、プラットフォームは、メッセージヘッダを解析して、メッセージタイプを決定し、ネットワークへの潜在的な負荷を決定し、対応するメッセージタイプに対する適切なエンコーダを決定するようにする。メッセージヘッダの解析は、具体的には、以下の例示的なシナリオで実行される：通信チャネル４は、同一のノード１上に配置された２つのコンポーネント３の間に既に確立されている。そして、２つのコンポーネント３のうちの少なくとも１つが遠隔ノード１に移動され、第１のフラグがコンポーネント移動を示すために設定される。次のメッセージが通信チャネル４を経由して送信される前に、システムは、設定された第１のフラグにより、通信チャネル４がノード１の境界を通過すること、および、ペイロードデータの符号化が必要となり得ることを検出する。

メッセージが、圧縮モジュールが存在する特定のタイプのものであり、および／または、データが特性のサイズを有する場合に、プラットフォーム（たとえば、システムの制御ユニット）は、符号化／復号が通信チャネル４に対して必要であると決定することができる。さらに、通信チャネル４により接続された２つのノード１のうちの１つ、または２つのノード１のうちの少なくとも１つが特定の作業負荷で動作する場合に、符号化／復号が必要であると決定することができる。

具体的な例は、データがメディアデータ、たとえばビデオまたは音声形式データである場合に、システム（たとえば、システムの制御ユニット）が常にコーデックを初期化することでもよい。

符号化／復号が必要な場合に、および、好ましくはコーデックが転送されるデータのタイプに関して利用可能である場合に、対応するエンコーダ５が初期化され、コーデックをインスタンス化する１つの選択肢に従って、対応するデコーダ６が受信コンポーネント３をホストする遠隔リソース（ノード）１上で通信チャネル４に関して初期化される必要があることを示す制御メッセージが、受信ノード３に送信される。そして、転送される（ペイロード）データは、送信コンポーネント３からエンコーダ５に渡され、符号化される。続いて、符号化されたデータは、エンコーダ５から遠隔側に送信される。転送されるデータを備えるメッセージは、転送データが圧縮されることを示す第２のフラグをさらに備えることができる。受信コンポーネント３を含むノード１において、着信／転送データが符号化されているかを確認することができ、データが符号化されている場合、デコーダ６がインスタンス化され、デコーダ６は、データを復号した後、復号されたデータを受信コンポーネント３に転送する。可能なコーデックは、ＭＰＥＧ−１、ＭＰＥＧ−４、ＶＰＳ、Ｈ．２６４、Ｈ．２６５、ＭＥＬＰ、ＳＩＬＫなどを含むことができる。

上記により、転送されるデータを受信コンポーネント３に適切に渡すために元のデータタイプを維持することができる。たとえば、処理コンポーネントの間のデータ交換用に用いられる元のメッセージタイプのメッセージは、符号化され、それぞれのノードの実行環境の間で交換される新しいメッセージ内にカプセル化される。受信ノードの実行環境は、このメッセージを受信し、含まれている符号化された元のペイロードデータをデコーダへ渡し、元のメッセージタイプのメッセージを生成して受信コンポーネントに転送する。したがって、データ（メッセージ）符号化／復号操作は、処理コンポーネントにとって透過的である。任意選択で、必要なデコーダ６に関する情報を含み、デコーダ６をインスタンス化する必要性を示す制御情報を、符号化された転送されるデータをさらに含むメッセージに挿入することができる。これにより、エンコーダ６が正しく初期化されることを保証するための処理ノード１の間の追加の通信、たとえば別個の制御メッセージの送信などを要求しないようにすることができる。

さらなる態様によれば、エンコーダ５およびデコーダ６は、遠隔接続が確立された場合に（最初のメッセージが送信される前であっても）、初期化される。これを行うことができるのは、アプリケーション開発者が圧縮形式の性質について事前に知っており、これが接続作成システムコールによって示される場合か、または、コンポーネントの形式的記述が、予想されるメッセージタイプおよびトラフィックレートを決定するために分析される場合である。たとえば、ビデオデータのみが特定の通信チャネルを経由して転送されるので、ビデオコーデックたとえばＭＰＥＧ−４、ＶＰ８、Ｈ．２６４またはＨ．２６５がこの特定の通信チャネルに関して初期化されるかもしれないことをアプリケーション開発者が予想する、または知っていることがある。結果として、コーデックをインスタンス化するいくつかの代替の選択肢が、本明細書で開示されており、これらは上記でより詳細に説明されている。

図４に、たとえばビデオチャットサービスなどの配備されたアプリケーションの結果を示し、これは、アプリケーションの最適化された分割およびデータの自動符号化、すなわち、上記で説明されたように、データを異なるノード１の間で自動的に符号化して交換できることによって、プラットフォームの極力少数のリソースを使用する。たとえば、図４は、ビデオチャットアプリケーションのパン／チルト／ズーム（ＰＴＺ）コンポーネント３が、２つの異なるノード１’、１’’に配布されていることを示す。２つのノードのうちの一方１’は、複雑なコーデックたとえばＨ．２６４と、低解像度たとえばＶＧＡとを有するビデオデータを処理する。他方のノード１’’は、高解像度たとえば７２０ｐと、単純なコーデックたとえばＭＰ４Ｖとを有するビデオデータに対するＰＴＺを処理する。両方のＰＴＺ処理ノード１’、１’’は、さらなる別のノード１’’上に配置された背景抽出（ＢＧ：ｂａｃｋｇｒｏｕｎｄ ｅｘｔｒａｃｔｉｏｎ）コンポーネントとの通信チャネル４を確立することができる。さらに、図４の両方のＰＴＺ処理ノード１’、１’’は、通信チャネル４を介して個人用ビュー（ＰＶ：ｐｅｒｓｏｎａｌ ｖｉｅｗ）レンダリングを処理するノードにデータを送信することもできる。図４のこの例では、ノード１’’’’は高解像度ＰＶレンダリングを処理するために使用され、さらなるノード１’’’’’は低解像度ＰＶレンダリングを処理するために使用される。低解像度ＰＶレンダリングは多くのコンピューティングリソースを要求しないので、プラットフォームは、図４のこの例では、低解像度ＰＶレンダリングと同一のノード１’’’’’上にビデオ混合コンポーネント３を配置するように決定している。まとめると、図４は、自動的に配布されたビデオチャットアプリケーションの一例を示している。処理コンポーネント３の間のデータ転送は、通信チャネル４を介して実行することができる。たとえば、ＰＴＺ処理ノード１’、１’’およびＢＧ処理ノード１’’’の間の、または、ＰＴＺ処理ノード１’、１’’およびＰＶレンダリング処理ノード１’’’’、１’’’’’の間の通信チャネル４について図４に示されるように、通信チャネル４がノード１の境界を通過する場合、システムは、データトラフィックを削減するためにコーデックを自動的にインスタンス化することができる。

まとめると、提案されたノード、システムおよび方法は、分散（クラウドベースの）実行環境におけるメディアアプリケーションの柔軟な配備を可能にする。アプリケーション開発者は、リソース制約を覚えておく必要がなく、サービス論理のみを管理することができる。これは、クラウドが仮想的に単一のリソースとなることを意味する。提案方法およびこの方法を実装するシステムを適用することにより、より粒度の粗い手法、たとえば仮想マシン、またはアプリケーション開発者によって導入される専用のサービスコンポーネントすらを配備することによって実現される手法などに比べて、さらにいっそう効率的にコンピューティングリソースの間でアプリケーションのサービス論理をプラットフォームが分割できるようになるので、全体のリソース利用を改善することができる。これは、既存の解決方法に比べて約３０−４０％のより高い利用率を実現すると考えられる。サービスおよびアプリケーション開発が簡単化され、その結果、基本となるクラウドプラットフォームが広く採用されることになる。

上記では特定の実施形態により実行される特定の順序の動作を説明しているが、代替的実施形態が、異なる順序で動作を実行する、特定の動作を組み合わせる、特定の動作を重複させるなどしてもよいので、そのような順序が例示的であることは理解されたい。所与の実施形態への本明細書における言及は、記載の実施形態が特定の機能、構造または特徴を含み得ることを示すが、全ての実施形態が特定の機能、構造または特徴を必ずしも含まないことがある。

記述および図面が提案方法およびシステムの原理を例示するものにすぎないことに留意されたい。したがって、本明細書には明示的に説明または図示されていないが、様々な構成を当業者が考案できるであろうことは理解されよう。さらに、本明細書に列挙された全ての例は、主に、提案方法およびシステムの原理と、発明者により当技術の発展に捧げられた概念とを理解する際に読者を補助する教育上の目的のためのものにすぎないことが明らかに意図されており、そのような具体的に列挙された例および条件に限定されないものと解釈されたい。さらに、原理、態様、および実施形態、ならびにこれらの具体例を列挙した本明細書の全ての記述は、それらの均等物を含むものとする。

さらに、様々な上述の方法のステップおよび記載のシステムのコンポーネントが、プログラムされたコンピュータにより実施可能であることに留意されたい。本明細書では、いくつかの実施形態はまた、機械可読またはコンピュータ可読であり機械実行可能またはコンピュータ実行可能な命令のプログラムを符号化するものであって、前記命令が前記上述の方法のステップの一部または全部を実施する、デジタルデータ記憶媒体などのプログラム記憶デバイスを含むものとする。プログラム記憶デバイスは、たとえば、デジタルメモリ、磁気記憶媒体たとえば磁気ディスクおよび磁気テープ、ハードドライブ、または光学的可読デジタルデータ記憶媒体とすることができる。実施形態はまた、上述の方法の前記ステップを実施するようにプログラムされたコンピュータを含むものとする。

加えて、本特許文書に記載の様々な要素の機能を、専用ハードウェア、ならびに適切なソフトウェアと関連してソフトウェアを実行可能なハードウェアを用いて提供できることに留意されたい。これらの機能は、プロセッサにより提供する場合、単一の専用プロセッサ、単一の共有プロセッサ、または一部が共有され得る複数の個別プロセッサにより提供することができる。さらに、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行可能なハードウェアを排他的に指すように解釈されるべきではなく、暗黙的に、限定はしないが、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性記憶装置を含むことができる。他のハードウェアも、従来型および／またはカスタム型にかかわらず、同様に含むことができる。

最後に、本明細書の任意のブロック図が概念図を表すことは理解されたい。同様に、任意のフローチャート、流れ図、状態遷移図、疑似コードなどが、実質的にコンピュータ可読媒体に表現可能であって、したがってコンピュータまたはプロセッサにより、そのようなコンピュータまたはプロセッサが明示的に示されていようといまいと、実行可能である様々な処理を表すことは理解されよう。

Claims (15)

1. 分散処理サービスプラットフォームの処理ノード（１）にわたってアプリケーションの処理コンポーネント（３）を自動的に配布するように構成されたアプリケーション配布ユニットを備えた制御ユニットであって、
   ２つの処理コンポーネント（３）の間の通信チャネル（４）が処理ノード（１）の境界を横断するかを判定するように構成され、通信チャネル（４）が処理ノード（１）のうちの１つの境界を横断すると判定された場合に、通信チャネル（４）を経由して転送されるデータの符号化および／または復号が必要かを判定するようにさらに構成された、制御ユニット。
2. 少なくとも２つの処理ノード（１）を備えるシステムであって、
   少なくとも１つのノード（１）が、実行環境（２）および少なくとも１つの処理コンポーネント（３）を備え、
   前記実行環境（２）が、処理コンポーネント（３）の発信ポートおよび異なる処理コンポーネント（３）の着信ポートの間に通信チャネル（４）を確立するための手段を含み、
   前記実行環境（２）が、それぞれノード（１）上で配布された処理コンポーネント（３）をインスタンス化し、修正し、削除するようにさらに構成され、
   システムが、請求項１に記載の制御ユニットをさらに備える、
   システム。
3. システムが、前記確立された通信チャネル（４）に関する情報を含むテーブルをさらに備え、
   前記情報が、通信チャネルの送信コンポーネント（３）および受信コンポーネント（３）のポートを含み、前記情報が、受信コンポーネント（３）が送信コンポーネント（３）と異なるノード（１）内に配置されている場合に識別子をさらに含み、
   識別子が、受信ノード（１）のネットワーク位置を識別する、
   請求項２に記載のシステム。
4. システムが、前記テーブル内の検索操作により通信チャネル（４）がノード（１）の境界を横断するかを検出するように構成され、
   検索操作が、コンポーネント（３）の再割当を示すエントリが前記テーブルに設定されているかを検出し、および／または、受信コンポーネント（３）のノード（１）の位置を発見するために前記識別子を読み出すように構成された、
   請求項２または３に記載のシステム。
5. 転送されるデータが所定のサイズを超過する場合に符号化／復号が必要であると判定するようにさらに構成された、請求項２から４の少なくとも１つに記載のシステム。
6. 転送されるデータが所定のデータタイプを有する場合に符号化／復号が必要であると判定するようにさらに構成され、所定のデータタイプが、好ましくはメディアデータタイプ、たとえば画像データ、音声データ、ビデオデータである、請求項２から５の少なくとも１つに記載のシステム。
7. 送信および受信ノード（１）の一方または両方が所定の作業負荷で動作する場合に符号化／復号が必要であると判定するようにさらに構成された、請求項２から６の少なくとも１つに記載のシステム。
8. 処理コンポーネント（３）がそれぞれのノード（１）の実行環境（２）によって提供されるメッセージパッシングインターフェースを介して通信し、メッセージパッシングインターフェースが送信コンポーネント（３）の出力ポートを受信コンポーネント（３）の入力ポートと接続する、請求項２から７の少なくとも１つに記載のシステム。
9. 送信処理ノード（１）であって、
   ノード（１）上でアプリケーションの配布された処理コンポーネント（３）をインスタンス化し、修正し、削除するように構成された少なくとも１つの実行環境（２）と、
   ノード（１）上で動作する少なくとも１つの配布された処理コンポーネント（３）とを備え、
   処理コンポーネント（３）の少なくとも１つの発信ポートが、通信チャネル（４）を経由してデータを送信するために受信処理ノード（１）と通信チャネル（４）を介して接続可能であり、実行環境（２）が、通信チャネル（４）を確立するように構成され、
   送信処理ノード（１）が、請求項１に記載の制御ユニットを備え、
   符号化が必要であると判定された場合に、エンコーダ（５）をインスタンス化し、インスタンス化されたエンコーダ（５）のタイプに関して受信処理ノード（１）に知らせるように構成された、送信処理ノード。
10. 受信処理ノード（１）であって、
    ノード（１）上でアプリケーションの配布された処理コンポーネント（３）をインスタンス化し、修正し、削除するように構成された少なくとも１つの実行環境（２）と、
    ノード（１）上で動作する少なくとも１つの配布された処理コンポーネント（３）とを備え、
    通信チャネル（４）を経由してデータを受信するために送信処理ノード（１）と通信チャネル（４）を介して接続可能であり、
    受信処理ノード（１）が、請求項１に記載の制御ユニットを備え、
    符号化が必要であると判定された場合に、送信処理ノード（１）においてインスタンス化されたエンコーダ（５）のタイプに関しての、送信処理ノード（１）から受信された情報に基づいて、デコーダ（６）をインスタンス化するように構成された、受信処理ノード。
11. 少なくとも２つの処理ノード（１）を有するシステム内のデータ通信のための方法であって、
    少なくとも１つのノード（１）が、それぞれのノード（１）上で配布された処理コンポーネント（３）をインスタンス化し、修正し、削除する実行環境（２）を有し、
    前記実行環境（２）が、データを送信する処理コンポーネント（３）の発信ポートをデータを受信する処理コンポーネント（３）の着信ポートと通信チャネル（４）を介して接続するための手段を含み、
    アプリケーションの処理コンポーネントをノード（１）上に自動的に配布するステップと、
    送信処理コンポーネント（３）と受信処理コンポーネント（３）の間の通信チャネル（４）を確立するステップと、
    通信チャネル（４）がノード（１）の境界を横断するかを判定するステップと、
    ノード（１）の境界が横断されると判定された場合に、通信チャネル（４）を経由して転送されるデータの符号化／復号が必要であるかを判定するステップと、
    符号化／復号が必要であると判定された場合に、送信コンポーネント（３）のノード内のエンコーダ（５）と、受信コンポーネント（３）のノード内のデコーダ（６）とを初期化するステップと、
    転送されるデータを送信コンポーネント（３）からエンコーダ（５）に提供し、エンコーダ（５）内でデータを符号化するステップと、
    符号化されたデータを通信チャネル（４）を経由して受信ノードに送信するステップと
    を備える、方法。
12. エンコーダ（５）が送信コンポーネント（３）のノードによりインスタンス化された後に、インスタンス化されたエンコーダ（５）のタイプに関する制御情報を含むメッセージが、送信コンポーネント（３）のノードの実行環境（２）から受信コンポーネント（３）のノードの実行環境（２）に送信され、
    デコーダ（６）が、メッセージに含まれる前記制御情報に基づいてインスタンス化される、
    請求項１１に記載の方法。
13. 転送されるデータが、デコーダ（６）をインスタンス化した時に、送信ノードから受信ノード（３）へ通信チャネル（４）を経由して送信される、請求項１２に記載の方法。
14. 転送されるデータが、制御情報も含むメッセージ内で送信される、請求項１２に記載の方法。
15. 送信側のエンコーダ（５）および受信側のデコーダ（６）が、通信チャネル（４）の確立と同時に、および通信チャネル（４）を経由してデータを送信する前に、インスタンス化される、請求項１１から１４の少なくとも１つに記載の方法。

Images