サーバネットワークノードにより実施される方法であって、該サーバネットワークノードによりホストされているサーバアプリケーションに接続されているクライアントネットワークノードの1つ又は2つ以上の対を決定し、その各対の構成要素となるクライアントネットワークノードが、それぞれのデータストリームコンテンツタイプの相補的なソース及びシンクの1つ又は2つ以上のアクティブな組を有しており、該決定されたクライアントネットワークノードの各対毎に、該対の構成要素となるクライアントネットワークノードの各々に、該対の構成要素となるクライアントネットワークノード間のネットワーク接続を介したそれぞれのピアツーピアセッションを定義するそれぞれのセッション定義を送信する、という各ステップからなる、サーバネットワークノードにより実施される方法。前記クライアントネットワークノードの各々にそれぞれの一意のステーション識別子が割り当てられており、前記サーバネットワークノードにより、前記サーバアプリケーションに接続されているクライアントネットワークノードの各々に、他のクライアントネットワークノードに割り当てられているそれぞれの一意のステーション識別子を送信する、というステップを更に含む、請求項1に記載の方法。前記サーバネットワークノードにより、前記クライアントネットワークノードの各々毎に、それぞれのステーション識別子と1つ又は2つ以上のエントリとを含むそれぞれのステーション定義を決定し、その各エントリが、それぞれのコネクションレス型トランスポートプロトコルアドレスと、該クライアントネットワークノード上のプロトコルポートのそれぞれのプロトコルポート識別子とを含み、前記ステーション識別子を送信する前記ステップが、それぞれのステーション定義を、前記サーバアプリケーションに接続されている他のクライアントネットワークノードの各々に送信するステップを含む、という各ステップを更に含む、請求項2に記載の方法。前記クライアントネットワークノードの各々毎に、それぞれのステーション定義を決定する前記ステップが、前記サーバネットワークノードにより、それぞれのネットワークアドレス及びクライアントネットワークノード上のプロトコルポートのそれぞれのプロトコルポート識別子を、前記クライアントネットワークノードから受信した1つ又は2つ以上のメッセージの各々から抽出するステップを含む、請求項3に記載の方法。前記サーバネットワークノードにより、前記決定されたクライアントネットワークノードの各対毎に、それぞれのセッション定義を生成し、該セッション定義が、該対の構成要素となるクライアントネットワークノードに割り当てられているそれぞれのステーション識別子と、該対の構成要素となるクライアントネットワークノード間のネットワーク接続を確立するためのコネクションレス型トランスポートプロトコルに関連付けられているトランスポート識別子とを含む、というステップを更に含む、請求項3に記載の方法。前記サーバネットワークノードにより、前記決定されたクライアントネットワークノードの各対毎に、それぞれのセッション定義を生成し、該セッション定義が、該対の構成要素となるクライアントネットワークノード間のネットワーク接続で伝送されるデータを暗号化するための暗号化プロセスに関連付けられた暗号化識別子を含む、というステップを更に含む、請求項5に記載の方法。前記サーバネットワークノードにより、プロキシサーバのステーション定義を、前記サーバアプリケーションに接続されているクライアントネットワークノードの各々に送信し、該ステーション定義が、前記プロキシサーバに割り当てられているそれぞれのステーション識別子と、1つ又は2つ以上のエントリとを含み、その各エントリが、それぞれのネットワークアドレスと、該プロキシサーバ上のプロトコルポートのそれぞれのプロトコルポート識別子とを含む、というステップを更に含む、請求項1に記載の方法。前記サーバネットワークノードにより、前記決定されたクライアントネットワークノードの各対毎に、該対の構成要素となるクライアントネットワークノード間のそれぞれのデータストリームコンテンツタイプの相補的なソース及びシンクのアクティブな組の各々毎に、該対の構成要素となるクライアントネットワークノード間のネットワーク接続を介したセッションで伝送されるデータを論理的に分割するそれぞれのチャネルの定義を決定する、というステップを更に含む、請求項1に記載の方法。前記チャネル定義のうちの1つ又は2つ以上の各々が、それぞれのチャネルでのデータの伝送を他の任意のチャネルでのデータの伝送とは無関係に制御する1つ又は2つ以上のトランスポートパラメータ値からなるそれぞれの組を含む、請求項8に記載の方法。前記チャネル定義のうちの1つ又は2つ以上の各々が、それぞれの信頼可能性トランスポートパラメータ値を含み、該信頼可能性トランスポートパラメータ値が、それぞれのチャネル上のデータが、損失したデータパケットを再送信する信頼できるトランスポートプロトコルによって伝送されるか又は損失したデータパケットを棄却する信頼できないトランスポートプロトコルによって伝送されるかを示すものである、請求項9に記載の方法。前記チャネル定義のうちの1つ又は2つ以上の各々が、それぞれの圧縮トランスポートパラメータ値を含み、該圧縮トランスポートパラメータ値が、それぞれのチャネル上のデータを完全な状態で処理することが必要とされるか否かを示すものである、請求項9に記載の方法。前記チャネル定義のうちの1つ又は2つ以上の各々が、それぞれの順序付けトランスポートパラメータ値を含み、該順序付けトランスポートパラメータ値が、それぞれのチャネル上のデータを順序通りに処理すべきか任意の順序で処理すべきかを示すものである、請求項9に記載の方法。前記チャネル定義のうちの1つ又は2つ以上の各々が、それぞれの圧縮識別子を含み、該圧縮識別子が、それぞれのチャネルで伝送されたデータを圧縮するためのそれぞれの圧縮プロセスを指定するものである、請求項9に記載の方法。前記チャネル定義のうちの1つ又は2つ以上の各々が、それぞれの一意のコンテンツ識別子に関連付けられており、該コンテンツ識別子が、チャネルに割り当てられているそれぞれのデータストリームコンテンツタイプを識別するものである、請求項8に記載の方法。前記サーバネットワークノードにより、前記サーバアプリケーションに接続されているクライアントネットワークノードの各々とそれぞれのサーバセッションを確立し、該サーバセッションの各々を介して、コンテンツタイプにより制御メッセージを論理的に分割する異なるそれぞれのチャネルで異なるコンテンツタイプの制御メッセージを送信する、という各ステップを更に含む、請求項1に記載の方法。前記制御メッセージの各々が、サーバセッションに割り当てられている一意のサーバセッション識別子と、該制御メッセージのコンテンツタイプを識別するそれぞれのコンテンツ識別子と共に送信される、請求項15に記載の方法。前記サーバネットワークノードにより、前記クライアントネットワークノードのうちの所与の1つからの、前記サーバアプリケーションとの接続を切断するためのメッセージの受信に応じて、該所与のクライアントネットワークノードとのそれぞれのセッションを終了させるためのそれぞれの命令を、該所与のクライアントネットワークノードとのそれぞれのセッションを有する他のクライアントネットワークノードに送信する、というステップを更に含む、請求項1に記載の方法。装置であって、コンピュータ読み取り可能命令を格納しているコンピュータ読み取り可能メモリと、該メモリに接続されたデータ処理手段であって、前記命令を実行するよう動作することが可能であり、及び該命令の実行に少なくとも部分的に基づいて、該装置によりホストされているサーバアプリケーションに接続されているクライアントネットワークノードの1つ又は2つ以上の対を決定し、その各対の構成要素となるクライアントネットワークノードが、それぞれのデータストリームコンテンツタイプの相補的なソース及びシンクの1つ又は2つ以上のアクティブな組を有しており、該決定されたクライアントネットワークノードの各対毎に、該対の構成要素となるクライアントネットワークノードの各々に、該対の構成要素となるクライアントネットワークノード間のネットワーク接続を介したそれぞれのピアツーピアセッションを定義するそれぞれのセッション定義を送信する、という各動作を実行するよう動作することが可能である、データ処理手段とを備えている装置。コンピュータ読み取り可能プログラムコードが内部に組み込まれた少なくとも1つのコンピュータ読み取り可能記憶装置であって、該コンピュータ読み取り可能プログラムコードが、コンピュータにより実行されて、該コンピュータによりホストされているサーバアプリケーションに接続されているクライアントネットワークノードの1つ又は2つ以上の対を決定し、その各対の構成要素となるクライアントネットワークノードが、それぞれのデータストリームコンテンツタイプの相補的なソース及びシンクの1つ又は2つ以上のアクティブな組を有しており、該決定されたクライアントネットワークノードの各対毎に、該対の構成要素となるクライアントネットワークノードの各々に、該対の構成要素となるクライアントネットワークノード間のネットワーク接続を介したそれぞれのピアツーピアセッションを定義するそれぞれのセッション定義を送信する、という各ステップからなる方法を実施するよう構成されたものである、コンピュータ読み取り可能記憶装置。所与のクライアントネットワークノードにより実施される方法であって、サーバネットワークノードによりホストされているサーバアプリケーションに接続し、該サーバネットワークノードには1つ又は2つ以上の他のクライアントネットワークノードが接続されており、該所与のクライアントネットワークノード及び該1つ又は2つ以上の他のクライアントネットワークノードの各々が、それぞれのデータストリームコンテンツタイプの1つ又は2つ以上のソース及びシンクを有しており、前記他のクライアントネットワークノードであって、該他のクライアントネットワークノードの前記1つ又は2つ以上のソース及びシンクのうちのアクティブなものと相補的な関係にある少なくとも1つのアクティブなソース又はシンクを前記所与のクライアントネットワークノードが有している、該他のクライアントネットワークノードの各々毎に、該所与のクライアントネットワークノードと該他のクライアントネットワークノードのうちのそれぞれのセッションパートである1つとの間のそれぞれのセッション定義を前記サーバネットワークノードから受信し、該受信したセッション定義の各々毎に、該セッション定義に基づいて前記所与のクライアントネットワークノードと前記それぞれのセッションパートナーのクライアントネットワークノードとの間のそれぞれのネットワーク接続を介したそれぞれのピアツーピアセッションを確立する、という各ステップからなる、所与のクライアントネットワークノードにより実施される方法。前記セッション定義のうちの少なくとも1つが、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続をネゴシエートするための複数のそれぞれのアドレスに関連付けられており、前記所与のクライアントネットワークノードにより、前記少なくとも1つのセッション定義の各々毎に、該セッション定義に関連付けられている前記複数のそれぞれのアドレスの全てについてそれぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続の確立を試行する、というステップが更に実施される、請求項20に記載の方法。前記所与のクライアントネットワークノードにより、該所与のクライアントネットワークノードが前記他のクライアントネットワークノードとの複数の同時のネットワーク接続を成功裏に確立した該セッションパートナーのクライアントネットワークノードの各々毎に、該セッションパートナーのクライアントネットワークノードとの前記複数のネットワーク接続のうちの1つを選択し、該選択したネットワーク接続を介したそれぞれのセッションを該セッションパートナーのクライアントネットワークノードと確立する、というステップが更に実施される、請求項21に記載の方法。前記所与のクライアントネットワークノードにより、該所与のクライアントネットワークノードが前記他のクライアントネットワークノードとの複数の同時のネットワーク接続を成功裏に確立した該セッションパートナーのクライアントネットワークノードの各々毎に、該セッションパートナーのクライアントネットワークノードとの前記複数の同時のネットワーク接続のうちの未選択のものの1つ又は2つ以上を、前記選択されたネットワーク接続を介して確立されたそれぞれのセッション中に存続させる、というステップが更に実施される、請求項22に記載の方法。前記所与のクライアントネットワークノードにより、前記サーバアプリケーションに接続されている前記他のクライアントネットワークノードのうちの1つ又は2つ以上の各々毎にそれぞれのステーション定義を前記サーバネットワークノードから受信し、該ステーション定義の各々が、それぞれの前記他のクライアントネットワークノードに割り当てられているそれぞれの一意のステーション識別子と、1つ又は2つ以上のエントリとを含み、その各エントリが、それぞれのネットワークアドレスと、前記それぞれの他のクライアントネットワークノードのプロトコルポートのそれぞれのプロトコルポート識別子とを含み、前記セッション定義の各々が、それぞれのセッションパートナーのクライアントネットワークノードに割り当てられている一意のステーション識別子を含み、前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノードにより、セッション定義中のステーション識別子に基づいて前記それぞれのセッションパートナーのクライアントネットワークノードのステーション定義中の1つ又は2つ以上のエントリを決定し、該エントリの各々毎に、前記それぞれのネットワークアドレス及び前記それぞれのプロトコルポート識別子を介して前記それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続の確立を試行する、というステップが更に実施される、請求項21に記載の方法。前記セッション定義の各々が、前記ネットワーク接続を確立するためのコネクションレス型トランスポートプロトコルに関連付けられているトランスポート識別子を含み、前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノードにより、前記それぞれのセッション定義中の前記トランスポート識別子に関連付けられている前記コネクションレス型トランスポートプロトコルに従って前記それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続の確立を試行する、というステップを含む、請求項24に記載の方法。前記セッション定義の各々が、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続をネゴシエートするための1つ又は2つ以上のそれぞれのネットワークアドレスに関連付けられており、前記所与のクライアントネットワークノードにより、プロキシサーバネットワークノードのそれぞれのアドレスを前記サーバネットワークノードから受信し、前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノードにより、前記セッション定義に関連付けられている1つ又は2つ以上のそれぞれのアドレスの各々について及び前記プロキシサーバネットワークノードの前記それぞれのアドレスについて前記それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続の確立を試行する、というステップを更に含む、請求項20に記載の方法。前記セッション定義の各々が、前記所与のクライアントネットワークノード及び前記それぞれの他のクライアントネットワークノードの各々に割り当てられているそれぞれの一意のステーション識別子に関連付けられており、前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノードにより、前記それぞれのセッションパートナーのクライアントネットワークノードに割り当てられている前記それぞれのステーション識別子を含む1つ又は2つ以上のインバウンドメッセージの各々からそれぞれのソースネットワークアドレスを抽出し、それぞれのセッションパートナーのクライアントネットワークノードに割り当てられているステーション識別子により索引付けされているローカルで格納しているステーション定義を、該ローカルで格納しているステーション定義にまだ含まれていない各々の抽出されたソースネットワークアドレスを含めるよう更新させる、という各ステップを含む、請求項20に記載の方法。前記セッション定義の各々が、前記所与のクライアントネットワークノード及び前記それぞれの他のクライアントネットワークノードの各々に割り当てられているそれぞれの一意のステーション識別子に関連付けられており、前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノードにより、該所与のクライアントネットワークノードに割り当てられている一意のステーション識別子を含むアウトバウンドメッセージをそれぞれのセッションパートナーのクライアントネットワークノードへ送信し、前記アウトバウンドメッセージに応答するインバウンドメッセージであって、前記それぞれのセッションパートナーのクライアントネットワークノードに割り当てられている一意のステーション識別子を含むインバウンドメッセージを受信したことに応じて、該インバウンドメッセージからそれぞれのソースネットワークアドレスを抽出して、前記それぞれのセッションパートナーのクライアントネットワークノードを該抽出されたソースネットワークアドレスにバインドする、という各ステップを含む、請求項20に記載の方法。前記セッション定義の各々が、それぞれの一意のステーション識別子に関連付けられており、前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノードにより、前記それぞれのセッションパートナーのクライアントネットワークノードがバインドされた前記ネットワークアドレスにアドレス指定されたトランスポートストリームを介して、該それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのセッションに割り当てられた一意のセッション識別子を含む別のアウトバウンドメッセージを送信し、該別のアウトバウンドメッセージに応じたインバウンドメッセージであって、前記それぞれのセッションに割り当てられた一意のセッション識別子を含むインバウンドメッセージを受信したことに応じて、前記トランスポートストリームを、前記それぞれのセッションでデータを送信するのに有効なものとして指定する、という各ステップを含む、請求項28に記載の方法。前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノードにより、前記それぞれのセッションパートナーのクライアントネットワークノードと複数のネットワーク接続を生成し、該生成された複数のネットワーク接続のうちの選択された1つを介してそれぞれのセッションを確立し、前記生成されたネットワーク接続のうちの未選択のもののうちの1つ又は2つ以上を、、前記選択されたネットワーク接続を介して確立されたセッション中に存続させる、という各ステップを含む、請求項20に記載の方法。前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記生成された複数のネットワーク接続のうちの所与の1つの失敗に応じて、前記所与のクライアントネットワークノードにより、前記それぞれのセッションパートナーのクライアントネットワークノードとの前記所与のネットワーク接続の再生成を試行するステップを含む、請求項30に記載の方法。前記所与のクライアントネットワークノードにより、該所与のクライアントネットワークノードから公開することができるローカル公開チャネルの識別子を前記サーバネットワークノードから受信し、前記確立されたピアツーピアセッションの各々で前記ローカル公開チャネルを公開する、というステップを更に含む、請求項20に記載の方法。前記所与のクライアントネットワークノードにより、前記確立された複数のピアツーピアセッションのうちの所与の1つにおいて複数の前記ローカル公開チャネルのうちの所与の1つを購読する要求を受信したことに応じて、前記所与のローカル公開チャネルに関連付けられているデータを前記それぞれのセッションパートナーのクライアントネットワークノードに送信する、というステップを更に含む、請求項32に記載の方法。前記所与のクライアントネットワークノードにより、該所与のクライアントネットワークノード上の1つ又は2つ以上のローカルソフトウェアエンティティに関連付けられているローカル購読チャネルを決定し、前記確立された複数のピアツーピアセッションのうちの所与の1つにおいて1つ又は2つ以上のリモート公開チャネルの公開を受信したことに応じて、該リモート公開チャネルのそれぞれに対応するローカル購読チャネルの各々を購読する要求を前記それぞれのセッションパートナーのクライアントネットワークノードに送信する、という各ステップを更に含む、請求項32に記載の方法。前記所与のクライアントネットワークノードにより、前記ローカル購読チャネルのそれぞれに対応する前記リモート公開チャネルのそれぞれにおいて前記所与のピアツーピアセッションでデータを受信したことに応じて、該受信したデータを、前記対応するローカル購読チャネルに関連付けられているローカルソフトウェアエンティティの各々に渡す、というステップを更に含む、請求項34に記載の方法。前記所与のクライアントネットワークノードにより、データストリームコンテンツタイプにより複数の前記セッションのうちの所与の1つで伝送されるデータを論理的に分割するそれぞれのチャネルの定義を前記サーバネットワークノードから受信し、前記データストリームのコンテンツタイプに従って、それぞれのチャネルで前記所与のセッションで前記それぞれのセッションパートナーのクライアントネットワークノードへデータストリームを送信する、という各ステップを更に含む、請求項20に記載の方法。前記チャネル定義の各々が、前記それぞれのチャネルに割り当てられているそれぞれのデータストリームコンテンツタイプを識別するそれぞれの一意のコンテンツ識別子を含み、前記データストリームを送信する前記ステップが、前記複数のチャネルのそれぞれの1つで、前記データストリームの前記コンテンツタイプに対応する複数の前記コンテンツ識別子のうちの1つをそれぞれ含むパケットという形で前記データストリームの各々を送信するステップを含む、請求項36に記載の方法。前記チャネル定義の各々が、それぞれのチャネルでのデータの伝送を、前記所与のセッションにおける他の任意のチャネルでのデータの伝送とは無関係に制御する、1つ又は2つ以上のトランスポートパラメータ値からなるそれぞれの組を含む、請求項36に記載の方法。前記チャネル定義の各々が、それぞれの信頼可能性トランスポートパラメータ値を含み、該信頼可能性トランスポートパラメータ値が、前記それぞれのチャネル上のデータが、損失したデータパケットを再送信する信頼できるトランスポートプロトコルによって伝送されるか又は損失したデータパケットを棄却する信頼できないトランスポートプロトコルによって伝送されるかを示すものである、請求項38に記載の方法。前記送信ステップが、前記所与のクライアントネットワークノードにより、信頼できるトランスポートプロトコルによるチャネルでデータが伝送されることを示す信頼可能性トランスポート値によって定義される前記所与のセッションにおける前記チャネルの各々毎に、前記チャネルでデータパケットを送信し、送信されたデータパケットであってその受信が前記セッションパートナーのクライアントネットワークノードによりアクノリッジされていないデータパケットの個数が、前記セッションパートナーのクライアントネットワークノードにより指定されたウィンドウしきい値を越えたという判定に応じて、前記送信されたデータパケットのそれぞれを前記チャネルで再送信する、という各ステップを含む、請求項39に記載の方法。前記送信ステップが、前記所与のクライアントネットワークノードにより、信頼できるトランスポートプロトコルによるチャネルでデータが伝送されることを示す信頼可能性トランスポート値によって定義される前記所与のセッションにおける前記チャネルの各々毎に、前記チャネルで送信したデータパケットを保持し、送信されたデータパケットが前記セッションパートナーのクライアントネットワークノードにより受信されたことのアクノリッジメントの受信に応じて、該送信されたデータパケットに対応する前記保持したデータバケットを解放する、という各ステップを含む、請求項40に記載の方法。前記所与のクライアントネットワークノードにより、送信ウィンドウサイズ番号及び受信ウィンドウサイズ番号を含むセッションメンテナンスメッセージを前記それぞれのセッションパートナーのクライアントネットワークノードから受信し、送信されたデータパケットであって前記セッションパートナーのクライアントネットワークノードによりその受信がアクノリッジされていない送信されたデータパケットが前記送信ウィンドウサイズ番号に達するまで、前記それぞれのセッションパートナーのクライアントネットワークノードにデータパケットを送信し、先行するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノードに送られた後に少なくとも前記受信ウィンドウサイズ番号のデータパケットを該セッションパートナーのクライアントネットワークノードから受信したことに応答するそれぞれのセッションメンテナンスメッセージを前記それぞれのセッションパートナーのクライアントネットワークノードに送信する、という各ステップを更に含む、請求項36に記載の方法。前記所与のクライアントネットワークノードにより送信される前記それぞれのセッションメンテナンスメッセージが、アクティブ状態にある複数のチャネルの各々毎に、該チャネルで受信されるパケットのそれぞれの最大パケットシーケンス番号の指示を含む、請求項42に記載の方法。前記それぞれのセッションパートナーのクライアントネットワークノードから一連のデータパケットを受信し、その各データパケットが、それぞれの逐次のチャネルレベルのパケット番号とそれぞれの一意のセッションレベルのパケット識別子とを含み、前記セッションメンテナンスメッセージを送信する前記ステップが、前記それぞれのセッションパートナーのクライアントネットワークノードへ送信される前記それぞれのセッションメンテナンスメッセージ内に、各チャネルで前記所与のクライアントネットワークノードにより処理されたデータパケットの逐次のパケット番号のうちの最高のパケット番号に対応する、各チャネル毎のそれぞれの値と、前記所与のセッションで複数のチャネルの全てにわたって前記所与のクライアントネットワークノードにより処理されたデータパケットのうち最も最近のデータパケットのそれぞれの一意のパケット識別子とを組み込むステップを含む、という各ステップを更に含む、請求項42に記載の方法。前記所与のクライアントネットワークノードにより送信された前記それぞれのセッションメンテナンスメッセージが、アクティブ状態にある各チャネル毎に、該チャネルで受信されていない損失パケットのそれぞれの識別子を含む、請求項42に記載の方法。前記所与のクライアントネットワークノードにより、第1時間パラメータ値及び第2時間パラメータ値を含むセッションメンテナンスメッセージを前記それぞれのセッションパートナーのクライアントネットワークノードから受信し、前記所与のセッションがアクティブ状態にあるとの判定に応じて、パケット受信アクノリッジメントセッションメンテナンスメッセージを、前記第1時間パラメータ値により設定された最大間隔で前記セッションパートナーのクライアントネットワークノードへ送信し、前記所与のセッションがアイドル状態にあるとの判定に応じて、パケット受信アクノリッジメントセッションメンテナンスメッセージを、前記第2時間パラメータ値により設定された最大間隔で前記セッションパートナーのクライアントネットワークノードへ送信する、という各ステップを更に含む、請求項20に記載の方法。前記クライアントネットワークノードにより、2つの連続するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノードへ前記所与のクライアントネットワークノードにより送信される前に少なくとも1つのデータパケットが該セッションパートナーのクライアントネットワークノードから受信されたとの判定に応じて、前記所与のセッションがアクティブ状態にあると判定し、2つの連続するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノードへ前記所与のクライアントネットワークノードにより送信される前に該セッションパートナーのクライアントネットワークノードからデータパケットを全く受信していないとの判定に応じて、前記所与のセッションがアイドル状態にあると判定する、という各ステップを更に含む、請求項46に記載の方法。装置であって、コンピュータ読み取り可能命令を格納しているコンピュータ読み取り可能メモリと、該メモリに接続されたデータ処理手段であって、前記命令を実行するよう動作することが可能であり、及び該命令の実行に少なくとも部分的に基づいて、サーバネットワークノードによりホストされているサーバアプリケーションに接続し、該サーバネットワークノードには1つ又は2つ以上の他のクライアントネットワークノードが接続されており、所与のクライアントネットワークノード及び前記1つ又は2つ以上の他のクライアントネットワークノードの各々が、それぞれのデータストリームコンテンツタイプの1つ又は2つ以上のソース及びシンクを有しており、前記他のクライアントネットワークノードであって、該他のクライアントネットワークノードの前記1つ又は2つ以上のソース及びシンクのうちのアクティブなものと相補的な関係にある少なくとも1つのアクティブなソース又はシンクを前記所与のクライアントネットワークノードが有している、該他のクライアントネットワークノードの各々毎に、該所与のクライアントネットワークノードと該他のクライアントネットワークノードのうちのそれぞれのセッションパートである1つとの間のそれぞれのセッション定義を前記サーバネットワークノードから受信し、該受信したセッション定義の各々毎に、該セッション定義に基づいて、該装置と前記それぞれのセッションパートナーのクライアントネットワークノードとの間のそれぞれのネットワーク接続を介したそれぞれのピアツーピアセッションを確立する、という各動作を実行するよう動作することが可能である、データ処理手段とを備えている装置。コンピュータ読み取り可能プログラムコードが内部に組み込まれた少なくとも1つのコンピュータ読み取り可能記憶装置であって、該コンピュータ読み取り可能プログラムコードが、コンピュータにより実行されて、サーバネットワークノードによりホストされているサーバアプリケーションに接続し、該サーバネットワークノードには1つ又は2つ以上の他のクライアントネットワークノードが接続されており、所与のクライアントネットワークノード及び前記1つ又は2つ以上の他のクライアントネットワークノードの各々が、それぞれのデータストリームコンテンツタイプの1つ又は2つ以上のソース及びシンクを有しており、前記他のクライアントネットワークノードであって、該他のクライアントネットワークノードの前記1つ又は2つ以上のソース及びシンクのうちのアクティブなものと相補的な関係にある少なくとも1つのアクティブなソース又はシンクを前記コンピュータが有している、該他のクライアントネットワークノードの各々毎に、前記所与のクライアントネットワークノードと該他のクライアントネットワークノードのうちのそれぞれのセッションパートである1つとの間のそれぞれのセッション定義を前記サーバネットワークノードから受信し、該受信したセッション定義の各々毎に、該セッション定義に基づいて、前記コンピュータと前記それぞれのセッションパートナーのクライアント成功を収める通信システムは一般に、現在利用可能なコンピューティング装置及び制約のあるネットワーク帯域幅を使用してリアルタイム通信性能を達成することができるように比較的低い計算リソース要件を有するべきである。更に、かかるシステムは典型的には、広範なネットワークトポロジにわたり様々な異なる装置間で高い接続可能性を達成するように、及び通信装置に対するストリームの伝送に関して適当な制御を提供して所望の通信経験を達成することができるように、実施されるべきである。以下の説明では、同様の符号は同様の構成要素を識別するために使用される。更に、各図面は、一実施形態の主な特徴を図式的に示すことを意図したものである。同図面は、実際の実施形態のあらゆる特徴を示すこと、図示の各構成要素の相対的な寸法を示すこと、及び実物大で示すことを意図したものではない。I.用語の定義通信者とは、1つ又は2つ以上のネットワーク接続を介して他の人と通信し又はその他の対話を行う人のことであり、この場合、該通信又は対話は、仮想領域との関連で生じても生じなくても良い。ユーザとは、説明を目的とした特定の全体像を画定する特定のネットワークノードを操作している通信者である。コンピュータとは、コンピュータ読み取り可能媒体上に一時的に又は永久的に格納されているコンピュータ読み取り可能命令に従ってデータ処理を行うあらゆる機械、装置、又は設備である。コンピュータオペレーティングシステムとは、タスクの実行並びに計算及びハードウェアリソースの共有を管理し調整するコンピュータシステムのソフトウェア構成要素である。ソフトウェアアプリケーションソフトウェア、アプリケーション、コンピュータソフトウェア、コンピュータアプリケーション、プログラム、及びコンピュータプログラムとも称すとは、1つ又は2つ以上の特定のタスクを実行するためにコンピュータが翻訳し実行することができる一組の命令である。コンピュータデータファイルとは、ソフトウェアアプリケーションにより使用するデータを永続的に格納している情報ブロックである。データベースとは、コンピュータにより検索することができる標準化された形式で提示される組織化されたレコードの収集体である。データベースは、単一のコンピュータ上の単一のコンピュータ読み取り可能データ記憶媒体上に格納することが可能であり、又は1つ若しくは2つ以上のコンピュータ上の複数のコンピュータ読み取り可能データ記憶媒体にわたって分散させることが可能である。データシンク本書では単にシンクと称すとは、データを受信する装置例えばコンピュータ、装置の一部、又はソフトウェアである。データソース本書では単にソースと称すとは、データを送出する装置例えばコンピュータ、装置の一部、又はソフトウェアである。ネットワークノードノードとも称すとは、通信ネットワーク内の分岐合流点又は接続点である。例示的なネットワークノードとして、端末、コンピュータ、及びネットワークスイッチが挙げられる但し、それらには限定されない。サーバネットワークノードとは、情報又はサービスの要求に応答するネットワーク上のホストコンピュータである。クライアントネットワークノードとは、情報又はサービスをサーバに要求するネットワーク上のコンピュータである。用語ローカルネットワークノードとは、現在議論の主題となっているネットワークノードを指すものである。用語リモートネットワークノードとは、ネットワーク通信リンクによりローカルネットワークノードに接続されているネットワークノードを指すものである。ネットワークアドレスとは、メッセージの出所又は宛先のプロトコル固有の符号化された表現であり、ネットワーク上のネットワークノードを一意に識別するために使用される。ソケットとは、ネットワーク通信エンドポイントである。アプリケーションプログラムは典型的には、アプリケーションプログラムをホストしているオペレーティングシステムのネットワークサービスアプリケーションプログラミングインタフェイスAPIをコールすることによりネットワークを介して通信を行うためにソケットを生成することができる。プロトコルポート又は単にポートとは、ネットワークノード内の通信エンドポイントとして働くアプリケーション固有の又はプロセス固有のソフトウェアコンストラクトである。トランスポートプロトコルは、1つのネットワークノード内の複数の異なるエンドポイントを識別するために、一意の数字を各ポートに割り当てる。ネットワーク接続又は単に接続とは、2つのネットワークノード間のデータ通信経路である。所与のネットワークノードから見ると、トランスポートストリーム又は単にストリームは、該所与のネットワークノードと他のネットワークノードとの間の直接的な接続である。セッションとは、2つのエンドポイントネットワークノード本書ではセッションパートナーと称す間の論理的な接続であり、該セッションが確立されたときから該セッションが解体されるときまで2つのネットワークノード間でメッセージを交換するという状況を提供するものである。所与のネットワークノードから見ると、1セッションは1つのトランスポートストリームで伝送され、この場合、該トランスポートストリームは、セッションパートナーへアドレス指定することもしないことも可能である。例えば、トランスポートストリームは、セッションパートナーにセッションを橋渡しするプロキシサーバーへアドレス指定することが可能である。ピアツーピアP2Pセッションとは、2つのネットワークノード間のセッションであり、その各ネットワークノードは、P2Pセッションを開始することができ、及び該P2Pセッション中にクライアント及びサーバとして働くものである。UUIDUniversallyUniqueIdentifierGUIDとも称すは、コンピュータシステム内又はネットワーク例えばインターネット上のオブジェクトを一意に識別するために使用される数字である。UUIDは、集中型サービス又は管理権限を必要とすることなく生成される。UUIDは典型的には、16オクテット128ビットのオクテット列である。UUIDを生成するための特定の機構に依存して、UUIDは、他の如何なるUUIDとも異なること又は少なくとも他の如何なるUUIDとも異なる可能性が極めて高いことが保証される。周知のUUIDとは、ネットワークを介して永続オブジェクトを高い信頼性で識別するために使用されるUUIDである。同期会議とは、複数の通信者が同時に参加する通信を称するものである。同期会議は、インスタントメッセージング例えば、テキストチャット、オーディオ会議、ビデオ会議、アプリケーション共有、及びファイル共有技術を含む、全ての種類のネットワーク化されたコラボレーション技術を包含するものである。リアルタイムデータストリームとは、連続的な流れで構築され処理されるデータであり、遅延なく又は知覚不能な遅延を伴って受信されるよう設計されるものである。リアルタイムデータストリームは、ボイス、ビデオ、ユーザの動き、顔の表情、及びその他の物理的な現象のディジタル表現、並びに、高速送信、高速実行、又は高速送信及び高速実行の両方から恩恵を受け得るコンピューティング環境内のデータ例えば、アバター移動命令、テキストチャット、リアルタイムデータフィード例えば、センサデータ、マシン制御命令、トランザクションストリーム、及び株価情報フィード、及びファイル転送を含むを含むものである。仮想領域領域又は場所とも称すとは、コンピュータにより管理される空間又はシーンを表現したものである。仮想領域は典型的には、1次元、2次元、又は3次元で表現したものであるが、実施形態によっては、仮想領域は、単一の点に対応するものとすることが可能である。多くの場合、仮想領域は、物理的な実世界の空間をシミュレートするよう設計される。例えば、従来のコンピュータモニタを使用して、コンピュータにより生成された3次元空間の2次元グラフィックとして、仮想領域を視覚化することが可能である。しかし、仮想領域は、スイッチングルールの実施に関連する視覚化を必要としない。仮想領域は典型的には、仮想領域スキーマのインスタンスを称し、ここで、該スキーマは、変数に関して仮想領域の構造及びコンテンツを定義し、該インスタンスは、特定のコンテキストから求められた値に関して仮想領域の構造及びコンテンツを定義するものである。仮想領域アプリケーション仮想領域仕様とも称すとは、仮想環境の生成に使用される仮想領域の記述である。仮想領域アプリケーションは典型的には、仮想領域の1つ又は2つ以上のゾーンに関連付けれたジオメトリ、物理特性、及びリアルタイムスイッチングルールの定義を含む。仮想領域通信アプリケーションとは、リアルタイムオーディオ通信及び潜在的には他のリアルタイム通信例えば、ビデオ、チャット、及びその他のリアルタイムデータストリームを仮想領域内の対話の視覚的表現と統合させるクライアント通信アプリケーションである。仮想環境とは、少なくとも1つの仮想領域を含み、及び複数の通信者間のリアルタイム通信をサポートする、コンピュータにより管理される空間を表現したものである。ゾーンとは、少なくとも1つのスイッチングルール又は統制ルールに関連付けられた仮想領域中の一領域である。スイッチングルールとは、1つ又は2つ以上の前提条件下にある1つ又は2つ以上のリアルタイムデータソース及び1つ又は2つ以上のリアルタイムデータシンクの接続又は切断を指定する指示である。スイッチングルールは、仮想領域に関連して通信する複数のネットワークノード間でのリアルタイムデータストリームのスイッチング例えば、ルーティング、接続、及び切断を制御する。統制ルールは、リソース例えば、領域、領域中の一領域、又は該領域又は該一領域のコンテンツに対する通信者のアクセス、該アクセスの範囲、及び該アクセスの後続の結果例えば、該アクセスに関する監査記録を記録しなければならないという要件を制御する。レンダリング可能ゾーンとは、個々の視覚化に関連付けられるゾーンである。仮想領域内の位置とは、仮想領域内の一点又は一面積又は一体積の場所を称するものである。一点は典型的には、仮想領域中の1つの小領域を画定する一組の1次元、2次元、又は3次元座標例えば、xyzにより表される。一面積は典型的には、仮想領域中の閉じた2次元形状の境界を画定する3つ又は4つ以上の同一平面上の頂点の3次元座標により表される。一体積は典型的には、仮想領域中の3次元形状の閉じた境界を画定する4つ又は5つ以上の同一平面上にない複数の頂点の3次元座標により表される。仮想領域に関して、オブジェクト場合によってはプロップとも称すとは、仮想領域の幾何学的構造とは別個に便利に扱うことができる該仮想領域中のあらゆるタイプの離散的要素である。例示的なオブジェクトとして、ドア、入口、窓、ビュースクリーン、及びスピーカーフォンが挙げられる。オブジェクトは典型的には、仮想領域の属性及びプロパティとは別個の異なる属性又はプロパティを有する。アバター本書ではスプライトとも称すとは、仮想領域中の通信者を表すオブジェクトである。本書で用いる場合、用語含むとは、含むがそれに限定されないことを意味し、用語含んでいるとは、含んでいるがそれに限定されないことを意味している。用語~に基づきとは、少なくとも部分的に基づくことを意味している。II.序論本書で説明する実施形態は、個々のネットワークノードで操作を行っている複数の通信者の間のリアルタイムネットワーク通信をサポートするストリームトランスポートプロトコルを提供するものである。該ストリームトランスポートプロトコルは、現在利用可能な広範なコンピューティング装置及びネットワーク接続を使用してリアルタイム通信性能を達成することができるように、比較的低い計算リソース要件を有するものである。実施形態によっては、該ストリームトランスポートプロトコルは、クライアント通信セッションのリモート管理、オーディオエンジン及びグラフィックレンダリングエンジンのリモートコンフィギュレーション及び実行、並びにリモートでホストされているサーバアプリケーションから受信した命令定義とも称すに応じたデータストリームのスイッチングをサポートする。このようにして、ストリームトランスポートプロトコルは、アプリケーションの開発者が、リモートクライアントネットワークノード上の通信環境の提示を介して制御を維持することを可能にし、これにより、広範な異なるタイプの仮想領域の開発が促進され、及びかかる通信システムの導入を所望するユーザの数が増大する。該ストリームトランスポートプロトコルは、接続切断並びに伝送の効率が良いものである。実施形態によっては、該ストリームトランスポートプロトコルは、所与のトランスポートプロトコル例えば、UDP、TCP、HTTP、及びPPPを介したコネクション型の暗号化接続を提供する。該ストリームトランスポートプロトコルは更に、クライアントアプリケーションによる介在を必要とすることなく失敗した接続の再確立を自動的に試行する再接続機構をクライアントアプリケーションとトランスポート層との間に提供し、これにより、元来信頼性できない通信プロトコルの上に信頼性が追加される。III.概説図1は、例示的なネットワーク通信環境10の一実施形態を示しており、該ネットワーク通信環境10は、互いにネットワーク20により相互接続された、第1のクライアントネットワークノード12クライアントノードA、第2のクライアントネットワークノード14クライアントノードB、サーバノード16、及び随意選択的なプロキシノード18を含む。第1のクライアントネットワークノード12は、有形のコンピュータ読み取り可能メモリ22、プロセッサ24、及び入力/出力IOハードウェア26ディスプレイを含むを含む。プロセッサ24は、メモリ22に格納されている少なくとも1つの通信アプリケーション28を実行する。第2のクライアントネットワークノード14は典型的には、実質的に前記第1のクライアントネットワークノード12と全体的に同様に構成され、少なくとも1つの通信アプリケーション32を格納した有形のコンピュータ読み取り可能メモリ30、プロセッサ34、及び入力/出力IOハードウェア36ディスプレイを含むを有する。サーバノード16は典型的には、クライアントノード1214間の1つ又は2つ以上の種類の通信例えば、インスタントメッセージング例えば、テキストチャット、オーディオ会議、ビデオ会議、アプリケーション共有、及びファイル共有をサポートする同期会議サーバノードである。通信アプリケーション2832及びサーバノード16は共に、一定のストリームトランスポートプロトコルに従ってネットワークノード1214を操作している通信者間の通信を管理するためのプラットフォーム本書ではプラットフォームと称すを提供し、該ストリームトランスポートプロトコルは、クライアント通信セッションのリモート管理、ストリーム処理エンジンのリモートコンフィギュレーション及び実行、並びにサーバノード16によりホストされるサーバアプリケーション38により指定されるリアルタイムデータストリームのリモート制御によるスイッチングをサポートする。ネットワーク20は、ローカルエリアネットワークLAN、メトロポリタンエリアネットワークMAN、及びワイドエリアネットワークWAN例えばインターネットの何れを含むことも可能である。該ネットワーク20は典型的には、ネットワークノード間で広範な種類の異なるメディアタイプ例えば、テキスト、ボイス、オーディオ、及びビデオの送信をサポートする多数の異なるコンピューティングプラットフォーム及び伝送設備を含む。図2は、クライアントノード1214とサーバノード16との間で確立することができる例示的な一組のセッションを示している。この例では、クライアントノード1214の各々は、サーバノード16とそれぞれのサーバセッション4042を確立する。該サーバセッション4042の各々は、クライアントノード1214のそれぞれとサーバノード16との間のそれぞれのネットワーク接続を介して確立される。更に、クライアントノード1214の各々はまた、該クライアントノード1214間のネットワーク接続を介してピアツーピアP2Pセッション44を確立する。クライアントノード1214はまた、クライアントノード1214間の当初のP2Pセッションに失敗した場合に該P2Pセッションを再確立するためのフェイルオーバー接続として用いることが可能な1つ又は2つ以上の代替的な又は予備の接続464850を確立し維持することが可能である。図示の実施形態では、代替的なネットワーク接続50はプロキシノード18を介して確立される。該プロキシノード18は、クライアントノード1214間のメッセージセッションネゴシエーションメッセージを含むを単純に中継するものである。ネットワークノード1214の各々は、1つ又は2つ以上のソースからなる一組のソース5254をそれぞれ有し、及び1つ又は2つ以上のシンクからなる例示的な一組のシンク5658をそれぞれ有する。各ソースは、特定のデータストリームコンテンツタイプのデータを送出する装置又はコンポーネントであり、各シンクは、特定のデータストリームコンテンツタイプのデータを受容する装置又はコンポーネントである。同じデータストリームコンテンツタイプのソース及びシンクを本書では相補的であると称する。例示的なソースとして、オーディオソース例えば、マイク等のオーディオ捕捉装置、ビデオソース例えば、ビデオカメラ等のビデオ捕捉装置、チャットソース例えば、キーボード等のテキスト捕捉装置、モーションデータソース例えば、マウス等のポインティング装置、及びその他のソース例えば、ファイル共有ソース又は特別なリアルタイムデータストリームのソースが挙げられる。例示的なシンクとして、オーディオシンク例えば、スピーカ又はヘッドフォン等のオーディオ演奏装置、ビデオシンク例えば、ディスプレイモニタ等のビデオ表示装置、チャットシンク例えば、ディスプレイモニタ等のテキスト表示装置、モーションデータシンク例えば、ディスプレイモニタ等の運動描画装置、及びその他のシンク例えば、共有されたファイルを印刷するためのプリンタ、上述したものとは異なるリアルタイムデータストリームをレンダリングするための装置、又は分析もしくは特別な表示のためにリアルタイムストリームを処理するソフトウェアが挙げられる。各ソースは、アクティブ状態及び非アクティブ状態を有し、アクティブ状態では、データを送出するためにソースを利用することが可能であり、非アクティブ状態では、データを送出するためにソースを利用することができない。同様に、各シンクは、アクティブ状態及び非アクティブ状態を有し、アクティブ状態では、データを受容するためにシンクを利用することが可能であり、非アクティブ状態では、データを受容するためにシンクを利用することができない。ソース及びシンクの状態は典型的には、通信アプリケーション2832により提供される制御を介して、クライアントノード1214を操作している通信者により制御することが可能である。例えば、実施形態によっては、通信アプリケーション2832は、クライアントノード1214においてローカルマイク及びローカルスピーカ例えば、ヘッドセットの電源をオン/オフさせるためのユーザ制御を提供する。以下で詳述するように、サーバセッション4042において、サーバノード16は、クライアントノード1214の各々へプロビジョニングメッセージ6062を送り、該プロビジョニングメッセージ6062は、サーバアプリケーション38で指定されたスイッチングルールに従って相補的なソース及びシンクのうちアクティブなものの間のそれぞれのデータストリームを相互接続するようにクライアントノード1214を設定するものである。様々なクライアントノードにおいてソースとシンクとの間で接続が確立される態様をサーバアプリケーションの開発者が制御することを可能にすることにより、該プラットフォームは、通信者がネットワーク通信環境10において互いに通信を行い又は対話する際の該通信者の体験をアプリケーションの開発者が制御することを可能にする。このようにして、サーバアプリケーションの開発者は、通信者間の通信を特定の通信目的について又は特定の通信環境例えば、仮想チャットルーム、仮想アートギャラリー、仮想コンサートホール、仮想ホール、仮想会議室、及び仮想クラブハウスについて最適化することが可能となる。IV.ストリームトランスポート通信プロトコルを実施したシステム及び方法の実例A.序論図3は、ストリームトランスポートサービス72及びその他のクライアントプロセス74を含むクライアントノード1214の一方又は両方の一実施形態70を示しており、該ストリームトランスポートサービス72及びその他のクライアントプロセス74は共に、サーバノード16から受信した命令に従って通信環境をレンダリングするためのシンクライアント通信アプリケーションを構成する。該ストリームトランスポートサービス72及びその他のクライアントプロセス74は、オーディオ及びグラフィクスレンダリング構成を介してネットワーク機能とは異なるレベルで動作する。ストリームトランスポートサービス72は、クライアントネットワークノード70とその他のネットワークノードとの間のセッションを管理する。このプロセスで、ストリームトランスポートサービス72は典型的には、アプリケーション層のクライアントプロセス74にチャネル及びセッションをエクスポートするローカルAPIと、サーバネットワークノード16上で動作している通信サービスとサーバセッションで通信するための及びリモートAPIとを提供する。実施形態によっては、クライアントノード1214上の通信アプリケーション2832は典型的には、通信者の対話の視覚化及び制御を行うための視覚的なインタフェイスを提供するそれぞれのグラフィカルユーザーインタフェイスGUIアプリケーションを含む。これらのGUIアプリケーションは、ローカルストリームトランスポートサービスAPIを介してサーバアプリケーション38と通信するよう構成される。実施形態によっては、該GUIアプリケーションは、ローカルAPIを実施するそれぞれのクライアントプロセス74へユーザ入力例えば、マウス入力を渡し及びそれらクライアントプロセス74から受信したグラフィカルデータ例えば、画面共有データ等のチャットデータ及びグラフィカルコンテンツを描画するよう構成されたリモート制御端末アプリケーションである。ローカルAPI通信を実施するこれらのクライアントプロセス74は、適当なセッション及びチャネルでユーザ入力の定義を含むメッセージを公開するために、並びに適当なセッション及びチャネルでリモートネットワークノードから受信したデータを購読するために、ストリームトランスポートサービス72と通信する。更に、複数のクライアントプロセス74のうちの1つ又は2つ以上は、サーバネットワークノード16上の通信サービスから受信した命令によりリモートで設定されて、他のクライアントネットワークノードから受信した到来データを処理するためのデータ処理要素グラフを生成する及びティアダウンする。例えば、実施形態によっては、リアルタイムカーネルのリモート設定されるオーディオ処理サービスを含み、該サービスは、サーバネットワークノード16上の通信サービスから受信した定義に応じてオーディオ処理要素のグラフを生成しティアダウンする。リモート設定可能な処理要素を含むリアルタイムカーネルの一例に関する更なる詳細については、2009年12月4日出願の米国特許出願第12630973号で開示されている。1セッション中に、データは、トランスポートプロトコルソケットを介して定義レコードとしてクライアントネットワークノード70とその他のネットワークノードとの間で共有される。シンクライアントアーキテクチャは、サーバセッションで受信した定義レコードを介してサーバノード16からコンフィギュレーション命令を受信する。シンクライアントアーキテクチャはまた、他のクライアントネットワークノードとのそれぞれのセッションでコンテンツ固有のチャネルで受信した定義レコードを介して、該他のクライアントネットワークノードからコンテンツを受信する。データは、公開/購読モデルに従って共有される。ストリームトランスポートサービス72は、クライアントネットワークノード70により必要とされるデータのみ購読する。購読するために、ストリームトランスポートサービス72は、他のネットワークノードと確立したセッションでチャネルをネゴシエートする。該チャネルは、特定のサーバアプリケーション38の周知のGUIDによりネゴシエートされる。定義レコードは、トランスポートプロトコルソケットの他端に購読者が存在する場合にのみ送信される。ストリームトランスポートサービス72により受信される定義レコードは、その到着時に、複数のクライアントプロセス74のうち購読を行っているものへ配信される。図3に示すように、ストリームトランスポートサービス72は、トランスポートストリーム78上のセッション76を管理する。実施形態によっては、ストリームトランスポートプロトコルセッションとのからみでのトランスポートストリームは、一対のIPポートアドレス及びトランスポートGUIDによって定義され、これにより、該ストリームを生成するために使用されるトランスポートプロトコル例えば、UDPが定義される。セッション76は、ゼロ又は1つ以上の論理チャネルからなり、この場合、1チャネルは、特定のクライアントプロセス74例えば、グラフィクスエンジン、オーディオマネージャ、及びストリームスイッチングマネージャに適した一連の定義レコードである。このため、単一ソケット上の同じトランスポートストリーム78が、複数の異なるチャネルに複数の定義レコードを伝送することができ、その各定義レコードは、複数のクライアントプロセス74のうちのゼロ、1つ、又は2つ以上によって購読することが可能である。図示の実施形態では、ストリームトランスポートサービス72は、2種類のチャネル、すなわち、ストリーミングメディアレコード86例えば、オーディオパケットを含むメディアチャネル80、及び定義レコード88を含む定義レコードチャネル82を管理する。メディアレコード86の例としてオーディオコーデック及びテキストが挙げられる。定義レコード88の例として、セッションメンテナンス定義例えば、キープアライブ/アクノリッジメント定義レコード、クライアントプロビジョニング定義例えば、オーディオ処理要素等のグラフ処理要素の定義、3Dレンダリング資産例えば、テクスチャ及びメッシュの定義、及びRDS例えば、アバターモーションチェックポイントの定義が挙げられる。定義レコード88及びメディアレコード86は、ストリームトランスポートプロトコルレコード内にカプセル化される。該ストリームトランスポートプロトコルレコードは、暗号化プロセス84によって暗号化され、パケット番号で順序づけされ、及びメッセージ完全性フィールドを含む。該ストリームトランスポートプロトコルレコードの順序づけは、レコードのソース又は目的とは無関係であり、順序が違うレコード又は損失したレコードを検出するために使用されるリンクレベルの機能である。ストリームトランスポートプロトコルレコードは、チャネルによって識別される。GUIDは、チャネル識別子として使用される。定義レコード88及びメディアレコード86は、ストリームトランスポートプロトコルレコードのカプセル化とは別個に、それぞれのチャネル固有の圧縮手段9092を使用してチャネルレベルで圧縮することが可能である。各ストリームトランスポートプロトコルレコードは典型的には、1つ又は2つ以上の定義レコード88又は1つのメディアパケット96を含む。ストリームトランスポートプロトコルレコードは、トランスポートプロトコル例えば、UDP、TCP、HTTP、及びPPPに従ってフォーマットされたパケットのペイロードとして、トランスポートストリーム78を介して配信される。図3に示す一実施形態では、ストリームトランスポートサービス72は、アプリケーション層91、トランスポート層93、ネットワーク層95、及びリンク層97を含む4層プロトコルスイートの1コンポーネントである。アプリケーション層91は、通信者をネットワークにインタフェイスするユーザレベルプロセスを含む。トランスポート層93は、ストリームトランスポートサービス72及びトランスポートプロトコル99例えば、UDPUserDatagramProtocolを含み、アプリケーション層91をネットワーク層95にインタフェイスする。ネットワーク層95は、1つ又は2つ以上のプロトコル例えば、IPInternetProtocol、ICMPInternetControlMessageProtocol、及びIGMPInternetGroupManagementProtocolに従ってネットワークを通るデータの動きを管理する。リンク層97は、ネットワークメディア例えば、Ethernetケーブル等との物理的なインタフェイスの詳細を管理し、典型的には、クライアントノード70のオペレーティングシステム及び物理的なネットワークのハードウェアコンポーネント例えば、NICNetworkInterfaceCardのデバイスドライバコンポーネントを含む。B.公開及び購読データ共有モデル実施形態によっては、データは、典型的にはコネクションレス型の公開/購読モデルに従って複数のネットワークノードにより共有される。かかる実施形態では、クライアントノード1214は、それらが必要とするデータのみを購読する。サーバノード16は、クライアントノード1214の各々によりどのチャネルが必要とされるかを、それらのソース及びシンクのそれぞれの状態すなわち、アクティブ又は非アクティブに基づいて判定する。サーバアプリケーション38は、クライアントノード1214の各々へ、如何なる情報ストリームが該クライアントにとって利用可能であるかを示す各ストリームにGUIDハンドルをタグ付けするそれぞれの公開メッセージを送る。各クライアントノードで動作する複数のクライアントプロセス74の各々は、ゼロ又は1つ以上のチャネルを購読することが可能である。1つのチャネルを購読するクライアントプロセス74は、チャネルレコードの到着時にチャネル状態の変化及び該チャネルレコードの通知を受信するためにローカルストリームトランスポートサービス72に登録する。次いで各クライアントノードは、サーバアプリケーション38により指定される周知のチャネルGUIDを使用して他のクライアントノードからの所望のチャネルを購読する。特定のチャネルについてのサーバデータに対するあらゆる変更は、該チャネルを購読している全てのクライアントへ定義レコードとして送信されることになる。図4は、クライアントネットワークノード1214が公開及び購読データ共有モデルに従って互いにデータを共有する方法の一実施形態を示している。この方法では、ローカルクライアントネットワークノードは、該ローカルクライアントネットワークノードから公開することができるローカル公開チャネルの識別子をサーバネットワークノードから受信する図4のブロック101。これらの公開チャネルは、該ローカルクライアントネットワークノードから提供することができるコンテンツに対応するものである。該ローカルクライアントネットワークノードは、該ローカルクライアントネットワークノードから公開することができるローカル公開チャネルと、該ローカルクライアントネットワークノード上の1つ又は2つ以上のローカルソフトウェアエンティティに関連付けられたローカル購読チャネルとを識別するレジスタを格納する図4のブロック103。該ローカルクライアントネットワークノードは、リモートクライアントネットワークノードとピアツーピアセッションを確立する図4のブロック105。該ローカルクライアントネットワークノードは、該ピアツーピアセッションで、前記ローカル公開チャネル及び前記ローカル購読チャネルを公開する図4のブロック107。該ピアツーピアセッションで1つ又は2つ以上のリモート公開チャネルの公開を受信したことに応じて、該ローカルクライアントネットワークノードは、前記リモート公開チャネルのそれぞれに対応する前記ローカル購読チャネルの各々毎に、前記リモートクライアントネットワークノードへ購読要求を送信する図4のブロック109。前記ローカル購読チャネルのそれぞれに対応するコンテンツチャネルにおいてピアツーピアセッションでデータを受信したことに応じて、該ローカルクライアントネットワークノードは、前記対応するローカル購読チャネルに関連付けられた前記ローカルソフトウェアエンティティの各々に前記受信したデータを渡す図4のブロック111。前記セッションで前記ローカル公開チャネルのそれぞれを購読するための要求を受信したことに応じて、該ローカルクライアントネットワークノードは、前記それぞれのローカル公開チャネルに関連付けられたデータを前記リモートクライアントネットワークノードへ送信する図4のブロック113。図3を再び参照すると、ストリームトランスポートサービス72は、ローカル公開及び購読エントリのレジスタ94例えば、テーブルを維持する。該リスト中の各エントリは、以下に示すものを含む。該エントリを生成したローカルクライアントプロセス74の識別子サーバ識別子チャネル識別子該エントリが公開エントリであるか購読エントリであるかの識別子購読用の1つ又は2つ以上の伝送パラメータ公開及び購読エントリのレジスタ94は、ストリームトランスポートサービスIDGUIDNULLセッションチャネルID購読信頼可能非圧縮により初期化される。このようにして、ストリームトランスポートサービスIDにより識別されるストリームトランスポートサービス72は、あらゆるセッションチャネルに到着した全ての定義レコード88公開及び購読定義レコードを含むを購読する。GUIDNULLチャネルは決して公開されず、あらゆるサーバは、該GUIDNULLチャネルを、あらゆるトランスポートストリームにおいて周知のチャネルIDで購読されるべきものとみなす。ストリームトランスポートサービス72はまた、ローカルリストに購読が遅れて登録される場合に使用するために、到着した全ての公開定義のレジスタ96を維持する。IDクライアントIDサーバIDチャネルここで、IDクライアントとは、特定のクライアントプロセス74のおそらくNULLのGUIDであり該チャネルは該クライアントプロセス74を意図したものであり、IDチャネルは、所与の1チャネルの周知のGUIDである。ストリームトランスポートサービス72が別のステーションに対する接続のためのセッション定義を受信すると、該ストリームトランスポートサービス72は、ストリームを確立し、セッション定義を送信し、次いで定義レコードに格納されているローカル公開エントリの全てをセッションチャネルで送信する。公開定義がストリームトランスポートサービス72に到着すると、ストリームトランスポートサービス72は、該定義を公開定義テーブルに入力し、次いで公開レコード内の対応するチャネルIDを有するローカルリスト中の各購読エントリ毎に購読定義を前記セッションチャネルで送信する。購読定義が到着すると、ストリームトランスポートサービス72は、公開側サーバアプリケーション38から送られてくる定義アップデートの送信を、該定義についての定義レコードを含む所与の定義レコードチャネルで開始する。該定義レコードは、2つ以上のチャネルで送信することが可能である。クライアントプロセス74がサーバとのチャネルに参加することを所望する場合には、該クライアントプロセス74は、何れかのサーバに対するトランスポートストリームが存在するか否かにかかわらず購読要求を定義する。サーバアプリケーション38がその後に公開した場合すなわち、ストリームが確立された後には、ローカルテーブルの変化がリモート公開定義テーブル96中の公開エントリの再送をトリガし、これは、トランスポートストリームの他端における潜在的な購読を自動的にトリガするものとなる。クライアントプロセス74が後に購読を行い、及び公開テーブル96中にエントリが存在する場合には、ストリームトランスポートサービス72は購読要求を自動的に送信する。このプロセスは、受信側が所望する場合にのみチャネルデータをトランスポートストリームを介して送信することを確実にする。C.SODA定義レコード実施形態によっては、ネットワークノードにより送信される定義レコードは、SODASococoDefinitionArchitectureレコードである。各SODAレコードは、1つ又は2つ以上のSODA定義を含む。SODA定義の例として、セッションメンテナンス定義例えば、キープアライブ/アクノリッジメント定義レコード、クライアントプロビジョニング定義例えば、オーディオ処理要素等のグラフ処理要素の定義、3Dレンダリング資産例えば、テクスチャ及びメッシュの定義、及びRDS例えば、アバターモーションチェックポイントの定義が挙げられる。SODAレコードは、最初のGUIDIDと1つ又は2つ以上のSODA定義とを有するネスト構造である。1つのSODA定義は、1つの定義タイプ、1つの定義長さ、及びゼロ又は1つ以上のフィールドを有する。該定義タイプは、周知のGUID例えば、guidAsset及びguidAudioMixである。前記定義長さは、全てのフィールドを含めたSODA定義の全体的な大きさを示す。前記フィールドは、タイプ固有の一定のフィールドと、ネストされた複数のSODA定義との組み合わせである。すなわち、SODAレコード:ガイドIDSODA定義...SODA定義:ガイド定義タイプ長期間;フィールド-定義タイプによって決まるフィールド:固定フィールド又はSODA定義であり、例えば、次の通りとなる。D.STRAWチャネル及びSTRAWパケット様々なネットワークノード上で動作するストリームトランスポートサービスのインスタンスは、セッショントラフィックを論理的に細分したものである複数のチャネルを介して通信する。実施形態によっては、該チャネルは、STRAWSococoTRAnsportforWANチャネルにより実施され、その各チャネルは、チャネルIDによって識別され、及び、コンテンツID、圧縮ID、一組のフラグ、及び圧縮プリロードデータストリングとして定義される。これらの実施形態では、1チャネルは、2つのネットワークノード間でSODA又はメディアレコードを1セッションで伝送する論理的な構成である。1チャネルは、信頼可能、信頼不能、圧縮、又は非圧縮とすることが可能である。チャネルのコンテンツは、コンテンツIDによって識別される。コンテンツIDは、周知のUUIDであり、及びアプリケーションの開発者が該アプリケーションを処理するためのサービスを書き込むことができるようにヘッダファイルに配置されデータベースで公開される。サーバノード16上の通信サービスは、メッセージのコンテンツタイプがチャネルのコンテンツIDと一致するように適当なチャネルでメッセージを送信する例えば、チャットメッセージがチャットチャネルで送信され、及びRDSメッセージがRDSチャネルで送信されるよう構成される。サービスは、誤ったチャネルで送信されたメッセージを無視することになる。あらゆるセッションのあらゆるチャネルは、異なるチャネルIDを有する。サービス例えばクライアントプロセス74は、コンテンツIDを使用してチャネルデータにバインドする。チャネル定義の他のフィールドの全ては、ストリームトランスポートサービス72がチャネルデータの送信及び優先順位付けに使用するためのものである。フラグは、以下のものを含む。信頼可能全てのデータパケットを配信キーフレームユーザデータパケットはキーフレームフラグを使用することが可能圧縮データパケットは完全な状態で処理されなければならない。例えば、ストリームとして細分されてはならない順序非依存パケットは受信時の任意の順序で処理することが可能サービスチャネルコンテンツタイプの例は、以下の通りである。オーディオモノフラグキーフレームユーザを有するオーディオコンテンツ信頼可能フラグの欠如は、ストリームが信頼性をもって配信されない損失したパケットが再送されないことを示唆している。順序非依存フラグの欠如は、ストリームデータを受信時の順序通りに処理しなければならないことを示唆している。圧縮フラグの欠如は、データがSTRAWにより圧縮されていないオーディオコーデックが既にデータを圧縮していることを示唆している。KVMMEDIAフラグ信頼可能、キーフレームユーザを有する画面共有コンテンツ。信頼可能フラグは、全てのパケットが受信されるまで再送信されなければならないことを示唆している。順序非依存フラグの欠如は、ストリームデータが受信時の順序通りに処理されなければならないことを示唆している。圧縮フラグの欠如は、データがSTRAWにより圧縮されていないオーディオコーデックが既にデータを圧縮していることを示唆している。セッションフラグ信頼可能を有するセッションコンテンツ。このチャネル上の全てのパケットはSodaレコードを含む;その全ては信頼性をもって送信され順序通りに処理されなければならない。必要に応じて圧縮フラグもまた存在することが可能である。チャネルレコードは、同じヘッダチャネルIDを共有し並びにパケット連番及びMACフィールドを有する一連のSTRAWレコードで送信される。MAC計算は、一方向のみの所与のチャネルにおけるパケット順によって決まる。単一チャネルで送信されたSTRAWレコードの全ては、一組のコンフィギュレーションパラメータ例えば、クライアント、信頼可能、圧縮を共有する。単一チャネル上の複数のレコードは、以下に示すように1つの直列ストリームとして圧縮される。通常は信頼可能チャネルのみ圧縮することができる。実施形態によっては、各キーフレーム毎に圧縮が再開する圧縮プロセスを用いて信頼不能チャネルを圧縮することができる。信頼不能チャネルでパケットが損失した場合には、キーフレームに達するまで該チャネル上のレコードが棄却される順序通りでないと解凍することができないため。実施形態によっては、各クライアントネットワークノード上の圧縮ダイナミックリンクライブラリを使用して定義レコードが圧縮される。圧縮を改善するために、チャネル定義は、圧縮手段を介して実行することができるが送信することはできないプリロードデータを含むことが可能である。その目的は、共通のフレーズを用いて圧縮状態テーブルを準備することにある。該圧縮状態テーブルは、キーフレームが受信される度にリセットされ再構築される。ストリームトランスポートサービス72は、それぞれのチャネル識別子を含むストリームトランスポートプロトコルレコード内にSODA定義をカプセル化する。該ストリームトランスポートサービス72は次いで、該ストリームトランスポートプロトコルレコードをトランスポートプロトコル99へ送って更なるカプセル化を行った後にその下方に位置するネットワーク層95及びリンク層97へ送信する。図5は、ストリームトランスポートプロトコルレコード本書ではSTRAWパケットと称すの一実施形態100を示している。該STRAWパケット100はSTRAWレコード102で始まる。該STRAWレコード102は、128ビットのチャネルIDUUID、16ビットのフラグフィールド、8ビットのバージョンフィールド、8ビットのキーフィールド、64ビットのクッキーフィールド、32ビットのMACフィールド、16ビットのパケット番号、8ビットの拡張子タイプフィールド、8ビットの拡張子長さフィールド、及び随意選択の拡張子プロトコルフィールドを有する。前記キーフィールドは、メッセージの暗号化に使用される暗号鍵を特定するものである0は暗号化しないことを意味する。前記パケット番号は、ゼロから始まり、ストリーム中の各パケットで増分する。パケット番号は、65535に達するとゼロに戻ってカウントをし続ける。パケット番号及びフラグは、ビッグエンディアン順である。STRAWレコード102に続くのが、SODAレコードを含むデータパケット104である。該フラグは、以下のものを含む。TFキーフレーム1TFネイキッド2TFメディア4TF圧縮8TFセッションメンテナンス16TFローカルパケット32TF第164TFプロキシ128TFマルチ256TF再送512TFウィンドウ遅延1024TFフレーム開始2048各パケットは、必要に応じてフラグをセットする。あらゆるチャネルは、任意のパターンでセットされたフラグを有するパケットを含むことが可能である。全ての組み合わせが有効であるとは限らない。キーフレームビットは、ストリームで送信された帯域外情報を示唆する。このフラグは、通常はメディアストリームで送信されるパラメータパケットにセットされる。このフラグの意味は、完全に通信者サービス固有のものである。ネイキッドフラグは、SODAレコードヘッダが存在しないであろうことを意味する。メディアフラグは、STRAWレコードに続く全てのパケットバイトの解釈が通信者サービス固有のものであることを意味する。圧縮フラグは、コンテンツがチャネルサービスにより圧縮されていることを意味する。このフラグの意味は、STRAWの定義の範囲外のものである。セッションメンテナンスフラグは、パケットが、STRAWプロトコルを意図したものであり、信頼できるチャネル上であっても信頼できないものであり、冪等元であり、及びパケット番号フィールドが解釈されないことになることを意味する。ローカルパケットフラグは、パケットが、局所的に送出されたものであり、及び実際には送信バッファ内にないことを意味する。このフラグは、ループバック式テストのためにセットされ、又は局所的に生成されたパケットを処理中のストリーム内に挿入することを必要とするアプリケーションによりセットされる。第1フラグは、待ち行列の先頭で送信すべくメッセージを待ち行列に入れるべきことを意味する内部的なSTRAWスタックフラグである。プロキシフラグは、パケットがプロキシにより転送されたことを意味する。マルチは、STRAWヘッダがマルチプロトコル拡張を含むべきことを意味する内部的なSTRAWスタックフラグである。再送フラグは、パケットが以前に送信されたものであり、そのコピーが複製されたことを意味する。ウィンドウ遅延フラグは、意味する。フレーム開始フラグは、コンテンツが複数のパケットへと分割されており、そのパケットがその一連のパケットのうちの最初のパケットであることを意味する。MACフィールドは、MACフィールドに続くあらゆるものパケットの残り例えば、soda定義又はメディアを含むについて計算されたハッシュである。MACは、クイックチェック計算及び包括チェック計算を有する。クイックチェックは、UDPパケットがSTRAWパケットを含むことを検証するために、ルータ、リレー、プロトコルスニファ、又はトランスポート層により使用することが可能である。クイックチェックの一例が上位ワードXOR下位ワードチェック値である。包括チェックの一例は、XOR上位ワードである。拡張子タイプバイトは、STRAWレコードの直後に続くものを判定する。拡張形式が0である場合には、プロトコル拡張は存在しない。拡張子タイプが1であり拡張子長さが6である場合には、プロトコル拡張は、16ビットのパケット第1フィールド、16ビットのパケット最終フィールド、及び16ビットのパケット長フィールドを有するマルチ構造である。マルチは、以下に示すように単一のUDPペイロード内に収まるものよりも長いパケットを定義する複数の逐次パケットをグループ化するために使用される。マルチパケットシーケンス内のパケットは、第1パケットから最終パケットまでの範囲内のパケット番号を有する。該シーケンスにより定められる総パケット長は、大きさバイトによるパケット長である。該シーケンスを構成する全てのパケットは、同一のフィールド値を有するマルチ拡張子を有していなければならない。該シーケンス内の何れかのパケットが信頼できないチャネル上で損失した場合には、該シーケンス全体が棄却され、大きなパケットが落ちたものとみなされる。該シーケンス内の何れかのパケットが信頼できるチャネル上で損失した場合には、該損失したパケットを受信側で要求して再送させることが可能である。パケット長が16ビットであるため、マルチを用いて定義することができる最大パケット長は32767バイト拡張子フィールドを有するSTRAWレコードフィールドを除くである。STRAWレコード102に続くのがデータパケット104である。該データパケット104の長さは、STRAWパケット100をネットワークを介して送信するのに使用されるトランスポートプロトコル例えば、UDPのペイロードサイズから決定される。データパケット104の長さは典型的には、各ネットワークノードのオペレーティングシステムにより提供されるトランスポートプロトコルネットワークAPIによってストリームトランスポートサービス72へ帯域外で送信される。該データパケットのフォーマットは、チャネルコンテンツIDに固有のものである。図5に示すように、STRAWパケット100は、ネットワークを介して送信されるリンク層フレーム106のペイロードとして送信される。図示の実施形態では、リンク層フレーム106は、リンク層ヘッダ、ネットワーク層ヘッダ、及びトランスポート層ヘッダで始まり、リンク層トレーラで終わる。一般に、該トランスポートプロトコルパケット106は、あらゆるタイプのリンク層プロトコルに対応することが可能である。図6は、一実施形態を示したものであり、この場合、STRAWパケット100はEthernetフレーム108内にカプセル化されており、該Ethernetフレーム108は、Ethernetヘッダ、IPヘッダ、及びUDPヘッダで始まり、Ethernetトレーラで終わる。E.セッション1.序論複数のネットワークノード間のセッションは、あらゆるタイプのシリアル通信プロトコルストリーム例えば、UDP、TCP、HTTP、及びPPPを介して確立することが可能である。実施形態によっては、1つのストリームは、2つのIPアドレス/ポート対及び1つのトランスポートGUIDにより定められる2つのネットワークノード間の双方向UDPソケットである。1つのストリームは、複数のチャネルの複数のセッションをサポートする。1つのセッションは論理的なノード間接続である。複数のセッションは、2つのノードについて複数のチャネルを伝送する。複数のセッションは、1つ又は2つ以上のプロキシノードを通過することが可能であり、及び複数のセッションを含むことが可能な複数のストリームを介して伝送される。クライアントノード1214及びサーバノード16は、それぞれの対をなすセッションを介して互いに通信し、この場合、クライアントノード1214の各々は、それぞれのサーバセッション4042をサーバノード16と確立し、及びクライアントノード1214の他方とピアツーピアP2Pセッション44を確立する。これらのセッション4044は、STRAWレコード102の第1フィールドすなわち、チャネルIDフィールド;図5参照に含まれる識別子により識別される複数のチャネルへと論理的に分割される。該チャネルの一例として、ステーションチャネル及びコンテンツチャネルが挙げられる。セッションチャネルは、STRAWレコード102のチャネルIDフィールド内のセッション識別子の存在によって識別され、及びセッション管理タスクに関連するデータ例えば、ストリーム状態メッセージ、Pingメッセージ、及びキープアライブメッセージを伝送するために指定される。ステーションチャネルは、STRAWレコード102のチャネルIDフィールド内のステーション識別子の存在によって識別され、及びネットワークアドレス解決タスクに関連するデータを伝送するために指定される。コンテンツチャネルは、STRAWレコード102のチャネルIDフィールド内のコンテンツ識別子の存在によって識別され、及びコンテンツデータ例えば、オーディオデータ、チャットデータ、及び画面共有データを伝送するために指定される。図7は、ネットワーク通信環境10の一実施形態を示しており、この場合、クライアント及びサーバネットワークノード1216は、ネットワークノード1216間で確立されたそれぞれのセッション4044において様々なチャネルで通信する。図示の実施形態では、サーバノード16は、サーバセッション4042においてそれぞれのサーバセッションチャネル110112でクライアントノード1214の各々と通信し、クライアントノード1214は、ピアツーピアセッション44においてステーションチャネル114、セッションチャネル116、及びコンテンツチャネル118で互いに通信する。実施形態によっては、データは、既述の公開/購読モデルに従い、STRAWソケットを介して、定義レコードとしてのセッションにおいてそれぞれのノード間で共有される。クライアントノード1214上で動作するストリームトランスポートサービス72のインスタンスは、該クライアントネットワークノードにより必要とされるデータのみ購読する。購読するために、ストリームトランスポートサービスのインスタンスは、サーバアプリケーション38のために定義された名前空間における周知のUUIDである特定のチャネルIDをネゴシエートすることにより、対象となるネットワークノードに対してSTRAWチャネルを生成する。サーバノード16は、サーバアプリケーション38に従って通信を行うようクライアントノード1214を設定するためのデータを維持する。サーバノード16が維持する類のデータとして、ステーション定義117、セッション定義119、チャネル定義121、及びコンテンツ定義123が挙げられる。実施形態によっては、複数のクライアントネットワークノードの各々にそれぞれの一意のステーション識別子が割り当てられる。複数のクライアントネットワークノードの各々毎に、サーバネットワークノードはそれぞれのステーション定義を決定し、該ステーション定義は、それぞれのステーション識別子と1つ又は2つ以上のエントリとを含み、その各エントリは、それぞれのコネクションレス型トランスポートプロトコルアドレスと、クライアントネットワークノード上のプロトコルポートのそれぞれのプロトコルポート識別子とを含む。実施形態によっては、各ステーション定義117は、それぞれのネットワークノードを一意に識別する永続的ステーションIDと、それぞれのネットワークノードに関連付けられた一組のソースアドレス例えば、IPアドレス、ソケットポート、プロトコルIDエントリとを含む。実施形態によっては、サーバネットワークノードは、クライアントネットワークノードから受信した1つ又は2つ以上のメッセージの各々から、それぞれのネットワークアドレスと該クライアントネットワークノード上のプロトコルポートのそれぞれのプロトコルポート識別子とを抽出することにより、該クライアントネットワークノードのためのステーション定義内のエントリを決定する。実施形態によっては、各セッション定義119は、それぞれのセッションを一意に識別するセッションID、それぞれのセッションを介して通信するよう設計された構成要素となるネットワークノードを識別する一対のステーションID、それぞれのセッションで使用されるべきトランスポートプロトコルを識別するトランスポートID、及びそれぞれのセッションで使用されるべき暗号化プロトコルを識別する暗号化IDを含む。実施形態によっては、前記暗号化IDは、以下のフィールドを有するSODA定義である一組の暗号鍵定義へと置換される。SOIDsoidStrawCipher;暗号鍵の周知のGUID例えば、DESSOIDsoidKeyPurpose;データtx、データrx、キーtx、キーrxSDDatasdKeyData;暗号化に適した実際のキー例えば、DES56ビットステーションIDは一組のソースアドレス例えば、IPアドレス、ソケットポート対を含むステーション定義を解決するため、セッション定義はネットワークノード間の通信を試みるのに十分なものである。実施形態によっては、複数のチャネル定義121のうちの1つ又は2つ以上は、それぞれの一意のコンテンツ識別子に関連付けられる。該コンテンツ識別子は、チャネルに割り当てられたそれぞれのデータストリームコンテンツタイプを識別するものである。これらの実施形態によっては、各チャネル定義121は、一意のチャネルID、周知のコンテンツID、圧縮ID、一組のフラグ、及び圧縮プリロードデータストリングを含む。各コンテンツ定義123は、定義タイプ、定義長さ、及び1つ又は2つ以上のフィールドを有するそれぞれのSODA定義である。これらの実施形態によっては、前記フラグの1つ又は2つ以上は、それぞれのチャネルにおけるデータのトランスポートを他の如何なるチャネルにおけるデータのトランスポートにもかかわらず制御するトランスポートパラメータ値に対応する。実施形態によっては、チャネル定義のうちの1つ又は2つ以上は、それぞれの信頼可能性トランスポートパラメータ値を含み、該信頼可能性トランスポートパラメータ値は、それぞれのチャネル上のデータが、損失したデータパケットを再送信する信頼できるトランスポートプロトコルによって伝送されるか又は損失したデータパケットを棄却する信頼できないトランスポートプロトコルによって伝送されるかを示すものである。実施形態によっては、チャネル定義のうちの1つ又は2つ以上は、それぞれの圧縮トランスポートパラメータ値を含み、該圧縮トランスポートパラメータ値は、それぞれのチャネル上のデータを完全な状態で処理することが必要とされるか否かを示すものである。実施形態によっては、チャネル定義のうちの1つ又は2つ以上は、それぞれの順序付けトランスポートパラメータ値を含み、該順序付けトランスポートパラメータ値は、それぞれのチャネル上のデータを順序通りに処理すべきか任意の順序で処理すべきかを示すものである。実施形態によっては、チャネル定義のうちの1つ又は2つ以上は、それぞれの圧縮識別子を含み、該圧縮識別子は、それぞれのチャネルにおいて伝送されたデータを圧縮するためのそれぞれの圧縮プロセスを指定するものである。サーバノード16はまた、サーバアプリケーションに接続されているクライアントノードのカレントレジスタ127を含む大域状態情報125と、該クライアントノードのデータソース及びシンク並びに該ソース及びシンクのそれぞれの状態すなわち、アクティブ又は非アクティブを識別するインタフェイスデータ129131とを維持する。サーバネットワークノードは、セッションパートナー間における現在アクティブな相補的なソース及びシンクの各対毎に普遍的に一意のチャネルIDを生成する。このため、現在利用可能なチャネルの各々は、クライアントネットワークノード間の現在の対話に対して一意であるそれぞれのチャネルIDによって識別され、該チャネルIDと共に送信されたメッセージは、真正なセッションパートナーからのものとして信頼することができる。例えば、ローカルマイクをオフにするための第1のセッションパートナーからのメッセージの受信に応じて、サーバノード16は、第2のセッションパートナーに対し、マイクオーディオチャネル処理グラフをティアダウンするよう指示し、及び、ローカルマイクを元に戻すための第1のセッションパートナーからのメッセージに応じて、サーバノード16は、新たな一意のチャネルIDを有する新たなオーディオチャネルを生成し、及び、該新たなオーディオチャネルを購読して該新たなオーディオチャネルでマイクデータを処理するための新たなマイクオーディオ処理グラフを生成するようよう第2のセッションパートナーに指示する。第2のセッションパートナーは、当初のマイクオーディオチャネル処理グラフをティアダウンするための指示の受信後に当初のオーディオチャネルで受信したあらゆるパケットを無視することになる。サーバノード16は、それぞれのサーバセッションチャネル110112を介して定義レコードを送信することにより、サーバアプリケーション38に従って通信を行うようクライアントノード1214の各々を設定する。このプロセスで、サーバノード16は、GUIDハンドルが各々タグ付けされたクライアントノード1214に対して利用可能となるチャネルを示す公開メッセージを送信する。クライアントノード1214上で動作しているストリームトランスポートサービス72のインスタンスは、所望のデータストリームについての購読メッセージをサーバノード16へ送信する。購読したチャネルについてのプロビジョニングデータに対するあらゆる変更は、それらのチャネルを購読している全てのクライアントネットワークノードに対して定義レコードとして送信される。各サーバセッションを介して、サーバネットワークノードは、コンテンツタイプにより制御メッセージを論理的に分割する異なるそれぞれのチャネルで異なるコンテンツタイプの制御メッセージを伝送する。該制御メッセージの各々は典型的には、サーバセッションに割り当てられた一意のサーバセッション識別子、並びに制御メッセージのコンテンツタイプを識別するそれぞれのコンテンツ識別子と共に送信される。実施形態によっては、サーバネットワークノードは、サーバアプリケーションに接続されているクライアントネットワークノードの各々に、その他のクライアントネットワークノードに割り当てられているそれぞれの一意のステーション識別子を送信する。かかる実施形態によっては、サーバネットワークノードはまた、プロキシサーバのステーション定義を、サーバアプリケーションに接続されているクライアントネットワークノードの各々に送信する。該プロキシサーバのステーション定義は典型的には、該プロキシサーバに割り当てられたそれぞれのステーション識別子と1つ又は2つ以上のエントリとを含み、その各エントリは、それぞれのネットワークアドレスと該プロキシサーバのプロトコルポートについてのそれぞれのプロトコルポート識別子とを含む。サーバノード16からの定義レコードの受信に応じて、クライアントノード1214上で動作しているストリームトランスポートサービス72のそれぞれのインスタンスは、チャネル定義113115、ステーション定義120122、セッション定義124126、及びコンテンツ定義128130を含むローカルに格納されたテーブルを更新させる。これらの定義は、到来するデータパケットを処理すべきか否かを判定するため、及びストリームトランスポートサービス72及びその他のクライアントプロセス74による消費のために到来するパケットを如何に逆多重化すべきかを判定するために、ストリームトランスポートサービス72のインスタンスにより使用される。実施形態によっては、所与のクライアントネットワークノードは、前記サーバアプリケーションに接続されている前記その他のクライアントネットワークノードのうちの1つ又は2つ以上の各々毎のそれぞれのステーション定義をサーバネットワークノードから受信する。受信したセッション定義の各々毎にそれぞれのセッションを確立するプロセスにおいて、前記所与のクライアントネットワークノードは、前記セッション定義におけるステーション識別子に基づいて、それぞれのセッションパートナーのクライアントネットワークノードの前記ステーション定義における1つ又は2つ以上のエントリを決定し、その各エントリ毎に、それぞれのネットワークアドレス及びそれぞれのプロトコルポート識別子を介したそれぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続の確立を試行する。かかる実施形態によっては、該セッション定義の各々は、ネットワーク接続を確立するためにコネクションレス型トランスポートプロトコルに関連付けられたトランスポート識別子を含む。受信したセッション定義の各々毎にそれぞれのセッションを確立するプロセスにおいて、前記所与のクライアントネットワークノードは、それぞれのセッション定義におけるトランスポート識別子に関連付けられたコネクションレス型トランスポートプロトコルに従って、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続の確立を試行する。実施形態によっては、受信したセッション定義の各々毎にそれぞれのセッションを確立するプロセスにおいて、前記所与のクライアントネットワークノードは、それぞれのセッションパートナーのクライアントネットワークノードと複数のネットワーク接続を生成し、該生成した複数のネットワーク接続のうちの選択された1つを介してそれぞれのセッションを確立し、及び該選択されたネットワーク接続を介してセッションが確立されている間、前記生成された複数のネットワーク接続のうちの未選択のネットワーク接続のうちの1つ又は2つ以上を存続させる。実施形態によっては、前記セッション定義のうちの1つ又は2つ以上は、それぞれのネットワーク接続についてそれぞれのセッションパートナーのクライアントネットワークノードとネゴシエートするために複数のそれぞれのアドレスに関連付けられる。かかる実施形態では、少なくとも1つのセッション定義の各々毎に、所与のクライアントネットワークノードは、該セッション定義に関連付けられている複数のそれぞれのアドレスの全てについて、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続の確立を試行することになる。前記所与のクライアントネットワークノードが前記その他のクライアントネットワークノードとの複数の同時のネットワーク接続を成功裏に確立した場合に、該所与のクライアントネットワークノードのセッションパートナーのクライアントネットワークノードの各々毎に、該所与のクライアントネットワークノードは、該セッションパートナーのクライアントネットワークノードとの前記複数のネットワーク接続のうちの1つを選択し、該選択したネットワーク接続を介して該セッションパートナーのクライアントネットワークノードとのそれぞれのセッションを確立する。実施形態によっては、前記所与のクライアントネットワークノードが前記その他のクライアントネットワークノードとの複数の同時のネットワーク接続を成功裏に確立した場合に、該所与のクライアントネットワークノードのセッションパートナーのクライアントネットワークノードの各々毎に、該所与のクライアントネットワークノードは、前記セッションパートナーとの前記複数の同時のネットワーク接続のうちの1つ又は2つ以上の未選択のネットワーク接続を、選択されたネットワーク接続を介して確立されたそれぞれのセッション中に存続させる。実施形態によっては、所与のクライアントネットワークノードは、プロキシサーバネットワークノードのそれぞれのアドレスをサーバネットワークノードから受信する。かかる実施形態では、該所与のクライアントネットワークノードは、前記セッション定義に関連付けられた1つ又は2つ以上のそれぞれのアドレスの各々について、及び前記プロキシサーバのそれぞれのアドレスを介して、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続の確立を試行する。実施形態によっては、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのセッションを確立するプロセスにおいて、所与のクライアントネットワークノードは、それぞれのセッションパートナーのクライアントネットワークノードに割り当てられたそれぞれのステーション識別子を含む1つ又は2つ以上のインバウンドメッセージの各々からそれぞれのソースネットワークアドレスを抽出する。該所与のクライアントネットワークノードはまた、それぞれのセッションパートナーのクライアントネットワークノードに割り当てられているステーション識別子により索引付けされているローカルで格納しているステーション定義を更新させて、該ローカルで格納されているステーション定義にまだ含まれていない各々の抽出されたソースネットワークアドレスが含まれるようにする。実施形態によっては、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのセッションを確立するプロセスにおいて、所与のクライアントネットワークノードは、該所与のクライアントネットワークノードに割り当てられている一意のステーション識別子を含むアウトバウンドメッセージをそれぞれのセッションパートナーのクライアントネットワークノードへ送る。該アウトバウンドメッセージに応答するインバウンドメッセージであって、それぞれのセッションパートナーのクライアントネットワークノードに割り当てられている一意のステーション識別子を含むインバウンドメッセージを受信したことに応じて、前記所与のクライアントネットワークノードは、該インバウンドメッセージからそれぞれのソースネットワークアドレスを抽出して、それぞれのセッションパートナーのクライアントネットワークノードを該抽出されたソースネットワークアドレスにバインドする。実施形態によっては、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのセッションを確立するプロセスにおいて、所与のクライアントネットワークノードは、それぞれのセッションパートナーのクライアントネットワークノードがバインドされた前記ネットワークアドレスにアドレス指定されたトランスポートストリームを介して、該それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのセッションに割り当てられた一意のセッション識別子を含む別のアウトバウンドメッセージを送る。前記別のアウトバウンドメッセージに応じたインバウンドメッセージであって、それぞれのセッションに割り当てられた一意のセッション識別子を含むインバウンドメッセージを受信したことに応じて、前記所与のクライアントネットワークノードは、前記トランスポートストリームを、前記それぞれのセッションでデータを送信するのに有効なものとして指定する。前記生成された複数のネットワーク接続のうちの所与のネットワーク接続が失敗したことに応じて、前記所与のクライアントネットワークノードは典型的には、それぞれのセッションパートナーのクライアントネットワークノードとの前記所与のネットワーク接続の再生成を試行する。実施形態によっては、所与のクライアントネットワークノードから公開することができるローカル公開チャネルの識別子を受信したことに応じて、所与のクライアントネットワークノードは、確立されたピアツーピアセッションの各々で該ローカル公開チャネルを公開する。前記確立された複数のピアツーピアセッションのうちの所与の1つにおいて複数の前記ローカル公開チャネルのうちの所与の1つを購読する要求を受信したことに応じて、前記所与のクライアントネットワークノードは、前記所与のローカル公開チャネルに関連付けられているデータをそれぞれのセッションパートナーのクライアントネットワークノードへ送る。前記所与のクライアントネットワークノードは、該所与のクライアントネットワークノード上の1つ又は2つ以上のローカルソフトウェアエンティティに関連付けられているローカル購読チャネルを決定する。前記確立された複数のピアツーピアセッションのうちの所与の1つにおいて1つ又は2つ以上のリモート公開チャネルの公開を受信したことに応じて、該所与のクライアントネットワークノードは、前記リモート公開チャネルのそれぞれに対応するローカル購読チャネルの各々を購読する要求をそれぞれのセッションパートナーのクライアントネットワークノードへ送る。前記ローカル購読チャネルのそれぞれに対応する前記リモート公開チャネルのそれぞれにおいて所与のピアツーピアセッションでデータを受信したことに応じて、前記所与のクライアントネットワークノードは、該受信したデータを、前記対応するローカル購読チャネルに関連付けられているローカルソフトウェアエンティティの各々に渡す。実施形態によっては、所与のクライアントネットワークノードは、データストリームを、該データストリームのコンテンツタイプに従って、それぞれのチャネルにおいて所与のセッションでそれぞれのセッションパートナーのクライアントネットワークノードへ送信する。このプロセスにおいて、前記所与のクライアントネットワークノードは典型的には、前記データストリームの各々を、該データストリームのコンテンツタイプに対応する複数のコンテンツ識別子のそれぞれを含む複数のパケットにおいて複数の前記チャネルのそれぞれで送信する。信頼できるトランスポートプロトコルによるチャネルでデータが送信されることを示す信頼可能性トランスポート値により定義される所与のセッションにおいて複数のチャネルの各々毎に、前記所与のクライアントネットワークノードは、前記チャネルでデータパケットを送信し、及び、セッションパートナーのクライアントネットワークノードにより受信がアクノリッジされていない送信済みのデータパケットの個数が、該セッションパートナーのクライアントネットワークノードにより指定されたウィンドウしきい値を越えているとの判定に応じて、該送信済みパケットのそれぞれを前記チャネルで再送信する。信頼できるトランスポートプロトコルによるチャネルでデータが送信されることを示す信頼可能性トランスポート値により定義される所与のセッションにおいて前記チャネルの各々毎に、前記所与のクライアントネットワークノードは、前記チャネルで送信されるデータパケットを保持し、及び、送信済みのデータパケットのうちの対応するデータパケットが前記セッションパートナーのクライアントネットワークノードにより受信されたことのアクノリッジメントを受信したことに応じて、前記保持したデータパケットを解放する。実施形態によっては、前記所与のクライアントネットワークノードは、送信ウィンドウサイズ番号及び受信ウィンドウサイズ番号を含むセッションメンテナンスメッセージをそれぞれのセッションパートナーのクライアントネットワークノードから受信する。前記所与のクライアントネットワークノードは、前記セッションパートナーのクライアントネットワークノードにより受信したことがアクノリッジされていない送信済みデータパケットが送信ウィンドウサイズ番号に達するまで、それぞれのセッションパートナーのクライアントネットワークノードへデータパケットを送信する。該所与のクライアントネットワークノードは、先行するセッションメンテナンスメッセージがセッションパートナーのクライアントネットワークノードに送られた後に少なくとも受信ウィンドウサイズ番号のデータパケットを該セッションパートナーのクライアントネットワークノードから受信したことに応答するそれぞれのセッションメンテナンスメッセージをそれぞれのセッションパートナーのクライアントネットワークノードへ送る。該所与のクライアントネットワークノードにより送られる該それぞれのセッションメンテナンスメッセージは典型的には、アクティブ状態にある複数のチャネルの各々毎に、該チャネルで受信されるパケットのそれぞれの最大パケットシーケンス番号の指示を含む。該所与のクライアントネットワークノードにより送られる該それぞれのセッションメンテナンスメッセージは典型的には、アクティブ状態にある複数のチャネルの各々毎に、該チャネルで受信されない損失パケットのそれぞれの識別を含む。実施形態によっては、前記所与のクライアントネットワークノードは、第1時間パラメータ値及び第2時間パラメータ値を含むセッションメンテナンスメッセージを、前記それぞれのセッションパートナーのクライアントネットワークノードから受信する。前記所与のセッションがアクティブ状態にあるとの判定に応じて、前記所与のクライアントネットワークノードは、パケット受信アクノリッジメントセッションメンテナンスメッセージを、前記第1時間パラメータ値により設定された最大間隔でセッションパートナーのクライアントネットワークノードへ送信する。前記所与のセッションがアイドル状態にあるとの判定に応じて、前記所与のクライアントネットワークノードは、パケット受信アクノリッジメントセッションメンテナンスメッセージを、前記第2時間パラメータ値により設定された最大間隔でセッションパートナーのクライアントネットワークノードへ送信する。実施形態によっては、クライアントネットワークノードは、2つの連続するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノードへ前記所与のクライアントネットワークノードにより送信される前に少なくとも1つのデータパケットが該セッションパートナーのクライアントネットワークノードから受信されたとの判定に応じて、前記所与のセッションがアクティブ状態にあると判定する。かかる実施形態では、前記所与のクライアントネットワークノードは、2つの連続するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノードへ前記所与のクライアントネットワークノードにより送信される前に該セッションパートナーのクライアントネットワークノードからデータパケットを全く受信していないとの判定に応じて、前記所与のセッションがアイドル状態にあると判定する。2.クライアントノードのプロビジョニング本例示の実施形態では、1つのネットワークノード上で動作しているストリームトランスポートサービスインスタンスは、別のネットワークノードのステーション定義を用いてプロビジョニングが行われた後、その他のネットワークノードとのセッションの確立を試行する。実施形態によっては、該プロビジョニングプロセスは、ネットワークノードがプラットフォームに対して認証された際に開始される。ネットワークノードは、その認証後に、サーバノード16のステーション定義を受信する。該ネットワークノードは、サーバノードのステーション定義を使用して、サーバノード16とのサーバセッションチャネルを介したセッションを確立し、該サーバノード16が、サーバアプリケーション38に接続されている他のネットワークノードとの通信のために該ネットワークノードのプロビジョニングを行う。サーバノード16がサーバセッションチャネルを介してクライアントノードへ送る例示的なタイプの定義として、ステーション定義、セッション定義、公開及び購読定義、トランスポートレポート要求、プロキシノード定義、セッションをティアダウンすることをクライアントに指示するステーションダウンメッセージ、及びpingメッセージが挙げられる。ネットワーク認証は典型的には、通信アプリケーション2832がクライアントノード1214上で起動される度に一回行われる。実施形態によっては、アカウントサービスを使用して、クライアントノード1214を認証し及び通信者のためのリアルユーザ識別子RUIDを確立する。該アカウントサービスは、サーバノード16又はそれとは別のサーバノード例えば、専用のアカウントサーバノードにより提供することが可能である。該認証プロセスは、アカウントサービスに接続し、認証を行い、及びクライアントノード1214をそれぞれ操作している通信者を識別する、通信アプリケーション2832によって開始される。図8は、アカウントサービスがクライアントノード12からのログインメッセージに応答する方法の一実施形態を示している。該ログインメッセージは典型的には、アカウントサービスに帯域外で例えば、SOAP等のウェブサービス交換を介して送信される。図8の方法によれば、アカウントサービスは、クライアントノード12のソースアドレスを含むログインメッセージをクライアント通信アプリケーション28から受信する図8のブロック140。該ソースアドレスは典型的には、該ログインメッセージを含むパケットのヘッダに埋め込まれる。該ログインメッセージは典型的には、クライアントノード12に通信アプリケーション28がインストールされた際に該クライアントノード12に割り当てられたステーションIDを含む。ログインサービスとクライアント通信アプリケーション2832との間の通信は典型的には、ウェブサービス交換例えば、SOAPを介した帯域外通信であり、又は別のセッションを介したものとなる。該ログインメッセージに応じて、アカウントサービスは、クライアントネットワークノード12を認証する図8のブロック142。このプロセスで、アカウントサービスは、トークンを生成し、及びクライアントノード12が他のサーバ例えば、サーバアプリケーション38をホストしているサーバノード16に対するそれ自体の認証を行うように該クライアントノード12に前記トークンを提供する。実施形態によっては、アカウントサービスはまた、ランダムな128ビットのチャレンジャフレーズをクライアントネットワークノード12に提供する。該クライアントネットワークノード12は、通信者により提供されたパスワードの暗号化ダイジェストを使用して前記チャレンジャフレーズのハッシュを生成し、これを応答として返す。アカウントサーバはまた、該通信者のための以前に取得したダイジェストを使用して前記チャレンジャフレーズのハッシュを生成して、前記クライアントネットワークノード12からの応答が一致するか否かを確認する。これでネットワーク接続が認証され、通信者が秘密鍵の所有者として識別される。実施形態によっては、ログインプロセスの一部として、アカウントサービスが、暗号、目的、及び暗号鍵を含む一組の暗号鍵をセキュアな接続例えば、SSL又は暗号化された帯域内リンクを介してクライアントネットワークノード12へ送る。クライアントネットワークノード12を認証した後、アカウントサービスは、クライアントノード1214から受信したログインメッセージに関連付けられたソースアドレスを抽出し、該抽出したソースアドレスをクライアントネットワークノードのステーション定義に組み込む図8のブロック144。アカウントサービスは典型的には、該アカウントサービスをホストしているオペレーティングシステムのネットワークサービスAPIをコールする例えば、Microsoft登録商標Windows登録商標オペレーティングシステムにより提供されるWinsockAPIを介して提供されるネットワークサービスをコールすることにより、ログインメッセージに関連付けられたソースアドレスを抽出することができる。アカウントサービスは、クライアントネットワークノード12、サーバノード16、及びプロキシノード18存在する場合のステーション定義を、クライアントネットワークノード12に送る図8のブロック146。上述したように、各ステーション定義は、関連付けられているネットワークノードを一意に識別する永続的なステーションIDと、それぞれのネットワークノードに関連付けられている一組をなす1つ又は2つ以上のアドレス例えば、IPアドレス、ソケットポート、プロトコルIDエントリとを含む。アカウントサービスはまた、クライアントネットワークノード12とサーバネットワークノード16との間のセッションの定義を該クライアントネットワークノード12に送る図8のブロック148。該セッション定義は、それぞれのセッションを一意に識別するセッションID、クライアントノード12のステーションID、サーバノード16のステーションID、それぞれのセッションに使用されるべきトランスポートプロトコルを識別するトランスポートID、及びそれぞれのセッションに使用されるべき暗号化プロトコルを識別する暗号化IDを含む。実施形態によっては、暗号化IDは、一組の暗号定義に置換される。図9は、クライアントノード1214上で動作しているストリームトランスポートサービス72のインスタンスがアカウントサービスからのステーション定義の受信に応答する方法の一実施形態を示している。図9の方法によれば、ストリームトランスポートサービス72は、クライアントネットワークノード、サーバネットワークノード16、及びプロキシネットワークノード18のそれぞれのステーション定義を該クライアントネットワークノード上にローカルに格納する図9のブロック150。これらのステーション定義は典型的には、ステーション定義テーブル120に格納される図7参照。ストリームトランスポートサービス72は、前記セッション定義に基づいてサーバネットワークノード16とのセッションを確立する図9のブロック152。プロキシノード18が存在する場合には、ストリームトランスポートサービス72はまた、プロキシネットワークノードステーション定義に基づいて該プロキシネットワークノード18とのトランスポートストリームを確立する図9のブロック154。クライアントノード12が、サーバノード16とセッションを確立するプロセス、及びプロキシノード18とトランスポートストリームを確立するプロセスについて、以下で説明する。クライアントノード1214がサーバノード16とセッションを確立した後図9のブロック152、該サーバノード16は、サーバアプリケーション38で規定されたスイッチングルールに従って通信を行うようクライアントノード1214のプロビジョニングを行う。このプロセスにおいて、サーバノード16は中央管理手段として働く。各クライアントノードは、他のクライアントノードと通信するよう明示的にプロビジョニングが行われ、及び明示的にプロビジョニングが行われていない未プロビジョニングネットワークノードとは通信しないことになる。未プロビジョニングネットワークノードが、サーバノード16を介した最初の認証なしでクライアントノードとの通信を試行した場合には、該クライアントノードは通信することができず、未プロビジョニングネットワークノードからの通信は無視されることになる。サーバノード16が、クライアントノード12と未プロビジョニングネットワークノードとの間のセッション定義を生成して、それら両方のノードにセッション定義とそれらノード間で利用することができるチャネルの定義とを提供するまで、クライアントノード12が未プロビジョニングネットワークノードと通信する方法はない。この方法において、クライアントノード及び未プロビジョニングネットワークノードは、互いを発見することはなく、また自立的に動作することはなく、サーバノード16が、クライアントノード間で可能となる通信を定義する。この方法は、ウィルスその他の攻撃の可能性を排除するものである。明示的に認証されておらずプロビジョニングされていないネットワークノードからの通信を各クライアントノードが無視するからである。図10は、互いに通信するようサーバアプリケーション38に接続されているクライアントノードのプロビジョニングをサーバノード16が行う方法の一実施形態を示している。図10の方法によれば、所与のクライアントネットワークノードは、サーバネットワークノード16によりホストされているサーバアプリケーション38であって、1つ又は2つ以上の他のクライアントネットワークノードが接続されているサーバアプリケーション38に接続し、この場合、該所与のクライアントネットワークノード及び該1つ又は2つ以上の他のクライアントネットワークノードの各々は、それぞれのデータストリームコンテンツタイプの1つ又は2つ以上のソース及びシンクを有している図10のブロック160。クライアントノードがサーバノード16とセッションを確立するプロセスについては以下のセクションで説明する。サーバノード16は、サーバネットワークノード16によりホストされているサーバアプリケーション38に接続されているクライアントネットワークノードの1つ又は2つ以上の対を決定し、この場合、その各対の構成要素となるクライアントネットワークノードは、それぞれのデータストリームコンテンツタイプの相補的なソース及びシンクの1つ又は2つ以上のアクティブな組を有する図10のブロック162。このプロセスにおいて、サーバノード16は、該サーバノード16がクライアントノード1214の各々毎に維持しているインタフェイスデータ129131に対し、サーバアプリケーション38により許可されている各データストリームコンテンツタイプのシンクの相補的なアクティブなソースを検索して、少なくとも一組のアクティブな相補的なソース及びシンクを有するクライアントノード対を決定する。アクティブな組をなす相補的なソース及びシンクの例として、クライアントノード上のアクティブなマイク及び別のクライアントノード上のアクティブなスピーカ、1つのクライアントノードによるアクティブな画面の共有及び別のクライアントノードによるアクティブな画面の参照、並びに2つのクライアントノードにおけるそれぞれのアクティブなチャットウィンドウが挙げられる。決定されたクライアントネットワークノードの各対毎に、サーバノード16は、該対の構成要素となるクライアントネットワークノードの各々に、該対の構成要素となるクライアントネットワークノード間のネットワーク接続を介したそれぞれのピアツーピアセッションを定義するそれぞれのセッション定義を送信する図10のブロック164。決定されたクライアントネットワークノードの各対毎に、サーバネットワークノードは典型的には、それぞれのセッション定義を生成し、該セッション定義は、i該対の構成要素となるクライアントネットワークノードに割り当てられているそれぞれのステーション識別子と、ii該対の構成要素となるクライアントネットワークノード間でネットワーク接続を確立するためのコネクションレス型トランスポートプロトコルに関連付けられているトランスポート識別子とを含む。決定されたクライアントネットワークノードの各対毎に、サーバネットワークノードはまた、典型的には、前記対の構成要素となるクライアントネットワークノード間のネットワーク接続で伝送されるデータを暗号化するための暗号化プロセスに関連付けられた暗号化識別子または一組の暗号定義を含むそれぞれのセッション定義を生成する。実施形態によっては、各セッション定義は、それぞれのセッションを一意に識別するセッションID、前記構成要素となるクライアントノードのうちの第1のクライアントノードのステーションID、前記構成要素となるクライアントノードのうちの第2のクライアントノードのステーションID、それぞれのセッションで前記構成要素となるクライアントノードにより使用されるべきトランスポートプロトコルを識別するトランスポートID、及びそれぞれのセッションで前記構成要素となるクライアントノードにより使用されるべき暗号化プロトコルを識別する暗号化IDを含む。実施形態によっては、前記暗号化IDは、一組の暗号定義に置換される。前記サーバノード16はまた、典型的には、前記構成要素となるクライアントネットワークノードの各々に、前記セッションで利用可能となるチャネルの定義を送信する。前記所与のクライアントネットワークノードは、前記サーバネットワークノード16から、該所与のクライアントネットワークノードと他のクライアントネットワークノードの各々との間のそれぞれのセッション定義を受信し、ここで、該所与のクライアントネットワークノードは、該他のクライアントネットワークノードの1つ又は2つ以上のソース及びシンクのうちのアクティブなものと相補的な少なくとも1つのアクティブなソースまたはシンクを有するものである図10のブロック166。受信したセッション定義の各々毎に、該所与のクライアントネットワークノードは、該セッション定義に基づいて、該所与のクライアントネットワークノードとそれぞれの前記他のクライアントネットワークノードとの間のそれぞれのネットワーク接続を介してそれぞれのピアツーピアセッションを確立する図10のブロック168。2つのクライアントネットワークノードが互いにピアツーピアセッションを確立するプロセスについて以下のセクションで説明する。3.セッションの確立最初に互いのデータ交換を所望するあらゆる2つのネットワークノードは、該ネットワークノードのステーション定義を参照する及び随意選択的にトランスポートID及び暗号化IDまたは代替的に一組の暗号定義を含むセッション定義を用いてプロビジョニングされる。各ネットワークノード上のストリームトランスポートサービス72は、前記セッション定義を使用して他のセッションパートナーネットワークノードのステーションIDを判定し、及びローカルで格納している該他のセッションパートナーネットワークノードのステーション定義を調べて、該他のネットワークノードとのそれぞれのネットワーク接続をネゴシエートするための1つ又は2つ以上のアドレスからなる一組のアドレスを見いだす。上述のように、セッション定義及びステーション定義の両方は、ネットワークノードにより予め帯域外で受信されたものである。セッションパートナーのステーションIDに関連付けられた1つ又は2つ以上のアドレスを判定した後、各ローカルネットワークノード上のストリームトランスポートサービス72は、各アドレス例えば、IPポート対に、該ローカルネットワークノードのステーションチャネルですなわち、該ローカルネットワークノードのステーションIDをチャネルIDとして用いてストリーム状態メッセージを送信する。このセッションパートナーアドレスの各々に対するバースト送信は典型的には、指数関数的に増大するバックオフ遅延を伴って繰り返され、該バックオフ遅延は、例えば、50ミリ秒msから開始し、3秒を越える値に達するこの時点では3秒毎にバーストが発生するまで、各バースト後に15倍の割合で増大する。実施形態によっては、各ストリーム状態メッセージは、チャネル例えば、ステーションチャネルまたはセッションチャネルを識別するチャネルIDと、SODAIDフィールド及び損失パケットカウントフィールドを有するSODAレコードからなるペイロードとを有する、STRAWパケットである。典型的には、セッションパートナーは、該セッションパートナーの一方または双方がストリーム状態メッセージを受信するまで、それぞれのストリーム状態メッセージを互いに同時に送信する。何れかのストリーム状態メッセージをチャネルIDにより識別されるリモートネットワークノードから受信したとき、ローカルネットワークノードは、ストリーム状態メッセージから該リモートネットワークノードのアドレス例えば、IPポートアドレスを抽出する。実施形態によっては、ローカルネットワークノード上のストリームトランスポートサービス72が、該ローカルネットワークノード上で実行しているオペレーティングシステムのネットワーキングアプリケーションプログラミングインタフェイスAPIを介してサービスをコールすることにより、ストリーム状態メッセージに関連付けられているアドレスを抽出する。例えば、Windows登録商標オペレーティングシステムを実行しているネットワークノードでは、WinsockAPIに含まれるサービスを介してアドレス抽出機能が提供される。ストリーム状態メッセージからリモートノードのアドレスを抽出した後、ローカルネットワークノードは、該ローカルネットワークノードのステーションチャネルで、該抽出されたアドレスにストリーム選択メッセージを送り返す。各ストリーム選択メッセージは、SODAIDフィールド及び全長フィールドを有するSODAレコードからなるペイロードを有するSTRAWパケットである。ローカルネットワークノードは、そのステーションIDを該STRAWパケットのチャネルIDとして使用することにより、そのステーションチャネルでストリーム選択メッセージを送信する。ストリーム選択メッセージを何れかのリモートネットワークノードから受信すると、ローカルネットワークノードは、該受信したストリーム選択メッセージから抽出したネットワークアドレスに該リモートネットワークノードをバインドする。このプロセスで、該ローカルネットワークノード上のストリームトランスポートサービス72は、ローカルで格納している該リモートネットワークノードの定義にビットをセットすることにより、前記ストリーム選択メッセージから抽出したアドレスを現在のネットアドレスnetaddresscurrentにプロモートする。この現在のネットアドレスのビットをセットすることにより、リモートネットワークノードとのセッションを確立するためにローカルネットワークノードにより使用することが有効なものとして該アドレスがマークされる。この時点で、リモートネットワークノードのネットワークアドレスは解決されており、ローカルネットワークノードとリモートネットワークノードとの間でトランスポートストリームが確立されている。ストリーム状態メッセージを送信し及びリモートネットワークノードからのストリーム選択メッセージの受信を待機するプロセスは、現在のネットアドレスへ送信されたローカルネットワークノードからのメッセージをリモートネットワークノードが受信すること、並びに現在のネットアドレスからのリモートネットワークノードによるメッセージをローカルネットワークノードが受信することを確実にする。図11は、第1及び第2のネットワークノード例えば、ネットワークノードA及びネットワークノードBが互いにリンクをネゴシエートする方法の一実施形態を示している。図12は、図11の方法の例示的な実施形態においてネットワークノードAとネットワークノードBとの間で送信される一組の例示的なメッセージを含む相互作用図を示している。図10及び図11を参照すると、他のネットワークノードとのセッションの定義を受信したことに応じて、各ネットワークノードは、該セッション定義内の他のネットワークノードのステーションIDを、ローカルに格納されているステーション定義テーブルへの索引として適用して、他のネットワークノードに関連付けられている全てのアドレスを判定する図11のブロック170。各ネットワークノードは、それ自体のステーションIDチャネルで、ストリーム状態メッセージ例えば、図12のメッセージ172176を、他のネットワークノードに関連付けられているアドレスの各々へ送信する図11のブロック174。受信側ネットワークノードのステーションチャネルで他のネットワークノードからのストリーム状態メッセージ例えば、図12のメッセージ176172を受信したことに応じて、各ネットワークノードは、該ストリーム状態メッセージに関連付けられているソースアドレスを抽出し、及びそれ自体のステーションIDチャネルでストリーム選択メッセージ例えば、図12のメッセージ178182を前記抽出されたソースアドレスへ送信する図11のブロック180。他のネットワークノードのステーションIDチャネルでストリーム選択メッセージ例えば、図12のメッセージ182178を受信したことに応じて、各ネットワークノードは、該ストリーム選択メッセージに関連付けられているソースアドレスを抽出し、該抽出したソースアドレスを他のネットワークノードにバインドする図11のブロック184。何れかのネットワークノードが特定のアドレスにバインドされると、ローカルネットワークノード上のストリームトランスポートサービス72が該リモートネットワークノードにセッションチャネルでPingメッセージの送信を開始する。各Pingメッセージは、SODAIDフィールド及びタイムスタンプフィールドを有するSODAレコードからなるペイロードを有するSTRAWパケットである。該ローカルネットワークノードは、該PingメッセージのチャネルIDをセッションIDに設定することにより、該Pingメッセージをセッションチャネルで送信する。リモートネットワークノードからのセッションチャネルでのPingメッセージがローカルネットワークノードにより受信されると、該ローカルネットワークノードと該リモートネットワークノードとの間でトランスポートストリームが確立される。ここで、該トランスポートストリームは、一対のアドレス例えば、IPポート及びトランスポートGUIDにより画定される。Pingメッセージの受信に応じて、ローカルネットワークノードは、ローカルで格納しているステーション定義テーブルにおけるリモートネットワークノードに関連付けられているビットを使用のために有効とマークする。何れかのリモートネットワークノードが有効とマークされると、ローカルネットワークノード上のストリームトランスポートサービス72は、該ローカルネットワークノードとリモートネットワークノードとの間で確立されている全てのトランスポートストリームを調べて、該トランスポートストリームのうちの最高優先順位または最高ランクのトランスポートストリームを、該リモートネットワークノードとのセッションを介してメッセージを送るために選択する。ローカルネットワークノード上のストリームトランスポートサービス72は、リモートネットワークノードの現在のネットアドレスへセッションチャネルでストリーム選択メッセージを送信することにより、前記選択されたトランスポートストリームを介してリモートネットワークノードとのセッションを確立する。図13は、第1及び第2のネットワークノード例えば、ネットワークノードA及びネットワークノードBがトランスポートストリームを介して互いにセッションを確立する方法の一実施形態を示している。図14は、図13の例示的な実施形態においてネットワークノードAとネットワークノードBとの間で送信される一組の例示的なメッセージを含む相互作用図を示している。図13及び図14を参照すると、各ネットワークノードは、他のネットワークノードにバインドされたアドレスへセッションIDチャネルでPingメッセージ図14のメッセージ190194を送信する図13のブロック192。前記他のネットワークノードにバインドされた前記アドレスからの前記セッションIDチャネルでのPingメッセージ図14のメッセージ194190の受信に応じて、各ネットワークノードは、前記他のネットワークノードにバインドされた前記アドレスへ前記セッションIDチャネルでストリーム選択メッセージ図14のメッセージ196200を送信する図13のブロック198。前記他のネットワークノードにバインドされた前記アドレスからの前記セッションIDチャネルでのストリーム選択メッセージ図14のメッセージ200196の受信に応じて、各ネットワークノードは、該他のネットワークノードとのトランスポートストリームを使用のために有効とマークする図13のブロック202。有効なトランスポートストリームが1つしか存在しない場合には図13のブロック204、各ネットワークノードは、該有効なトランスポートストリームを介して前記他のネットワークノードとトランスポートストリームを確立する図13のブロック206。有効なトランスポートストリームが複数存在する場合には図13のブロック204、各ネットワークノードは、該複数の有効なトランスポートストリームのうちの1つを選択し、該選択したトランスポートストリームを介して前記他のネットワークノードとセッションを確立する図13のブロック208。実施形態によっては、所与のクライアントネットワークノードが、他のクライアントネットワークノードと複数の同時のネットワーク接続を成功裏に確立している場合に、そのセッションパートナーのクライアントネットワークノードの各々毎に、該所与のクライアントネットワークノードが、該セッションパートナーとの該複数の同時のネットワーク接続のうちの未選択のネットワーク接続のうちの1つ又は2つ以上を、選択されたネットワーク接続を介して確立されたセッションにわたって存続させる。実施形態によっては、ストリームトランスポートサービス72は、Pingをセッションパートナーへ定期的に例えば、3秒毎に送信することにより、それらのストリームを生かし続ける。応答側のPingが受信されない場合には、ストリームトランスポートサービス72は、セッションパートナーとのトランスポートストリームを確立するプロセスを繰り返すことが可能である図13及び図14参照。該プロセスに失敗した場合には、ストリームトランスポートサービス72は、ネットワークアドレス解決プロセス例えば、図11及び図12参照及びそれに続くトランスポートストリーム確立プロセス例えば、図13及び図14参照を繰り返すことが可能である。実施形態によっては、トランスポートサービス72は、特定のソケットアドレスすなわち、特定のIPアドレス及びプロトコルポート番号にバインドされるが如何なる特定の宛先アドレスにもバインドされない単一のプロトコルソケット例えば、UDPソケットを生成する。このようにして、複数の宛先アドレスとトランスポートストリームを生成することが可能である。ソケットプロトコルポートがUDPIPプロトコルポートである実施形態では、トランスポートサーバが、エンドポイントネットワークノードの宛先アドレスすなわち、IPアドレスプロトコルポート番号を取得するsendtoAPI機能を使用して単一のプロトコルポートを介してデータを送信する。ネットワーク層プロトコルすなわち、IPは、ソケットプロトコルポートでパケットを受信するための一組のバッファを管理するスレッドを維持する。該バッファのうちの1つにパケットが到来すると、該スレッドは、パケットをチェック例えば、チェックサムを検証し、該パケットが暗号化されている場合にはそれを復号し、該パケットが有効である例えば、フラグ、チェックサム、及びMACが有効である場合には、前記スレッドは、チャネルIDのトランスポートを操作するよう指定された1つ又は2つ以上のターゲットとなるトランスポートサービスを決定するために、チャネル定義テーブルに列挙されているトランスポートIDにより識別される全てのトランスポートサービスに対する該チャネルIDの突き合わせを試行する。ターゲットとなるトランスポートサービスが発見された場合には、該トランスポートサービスが、パケットのチャネルIDに対応するチャネルで該パケットが到着したことをストリームトランスポートサービス72に通知する。ストリームトランスポートサービス72は、該パケットのコンテンツIDを判定し、該コンテンツIDを購読している複数のクライアントプロセス74の各々にパケットペイロードを送信する。このプロセスで、ストリームトランスポートサービス72は、ペイロードを待ち行列にポストし、及び該待ち行列で待機しているスレッドに公開する。ターゲットとなるトランスポートサービスがチャネル定義テーブルで発見されない場合には、ストリームトランスポートサービス72は、セッション定義テーブル及びステーション定義テーブルのエントリに対する前記チャネルIDの突き合わせを試行する。一致するエントリが発見された場合には、ストリームトランスポートサービス72は、例えば、ネットワークアドレス解決またはセッションメンテナンス処理のために前記パケットを処理する。ターゲットとなるトランスポートサービスが、チャネル定義テーブル、セッション定義テーブル、及びステーション定義テーブルの何れでも発見されなかった場合には、前記パケットは棄却される。複数のチャネルは、同一のソケットを介して他の複数のチャネルとは別個に送信される。1つのチャネルにおける如何なるパケットの損失も、他のチャネルの完全性に影響しない。以下で説明するように、ストリームトランスポートサービスは、チャネル毎のフロー制御機能を提供し、この場合、各チャネルは異なる優先順位を有することができる。4.セッションの終結所与のクライアントネットワークノード上の通信者が通信セッションを終了させるためのコマンドを入力した場合、ストリームトランスポートサービスはサーバノードへ終了メッセージを送信する。該終了メッセージの受信に応じて、サーバノードは、サーバアプリケーションに接続されている他のクライアントネットワークノードへ、それらの前記所与のクライアントネットワークノードとのセッションをティアダウンすることをストリームトランスポートサービス72のそれぞれのインスタンスに指示する定義レコードを送信する。それら定義レコードの受信に応じて、前記他のクライアントネットワークノードの各々は、前記所与のクライアントネットワークノードとのセッションと、該所与のクライアントネットワークノードとの通信のために生成されたチャネルに関連付けられている全てのオーディオ及び画面共有処理コンポーネントとをティアダウンする。5.プロキシノード実施形態によっては、ネットワークノード間のセッションは、サーバノード16により提供される1つ又は2つ以上のプロキシノードプロキシ中継局とも呼ばれるを含むネットワーク接続を介して確立される。プロキシノードは、それ自体のためのセッションをネゴシエートしない。あらゆるセッションネゴシエーションは、クライアントノードによりエンドツーエンドで行われ、プロキシノードは単にそれらクライアント間のメッセージを中継するだけである。プロキシノードはセッション層のフロー制御に参加しないため、プロキシノードのトランスポートインプリメンテーションは、セッションの両方の参加者から連絡があるまで単にセッションメッセージを棄却する。Pingメッセージが交換されるまで何れのクライアントノードもトラフィックを送らないため、リンクを介したネットワークトラフィックは殆ど存在しない。サーバノード16は、各クライアントノードが何らかの経路を介して所望の各クライアントノードとP2P通信を行うことができるように、様々なプロトコル及び優先順位のステーション定義を用いてクライアントノードのプロビジョニングを行う。1つ又は2つ以上のプロキシノードが利用可能である場合には、サーバノード16は、プロキシノードのためのセッション定義及びステーション定義をクライアントノード1214へ送り、この場合、各プロキシノードのステーション定義は、プロキシステーションID、トランスポート変数ID、及び暗号化変数IDを含む。利用可能なプロキシが2つ以上存在する場合には、エリアサービスは、現在の負荷にとって最善のプロキシを選択し、及び各プロキシがそのトラフィックを経路指定すべき場所を決定し、該トラフィックは1つ又は2つ以上の他のプロキシステーションを介して中継することが可能である。実施形態によっては、エリアサービスは、最小トラフィックメッシュに基づいてネットワークにおけるボトルネックの最小化を試行するネットワークトラフィック平衡化プロセスを実行することにより、各セッション毎にそれぞれの経路を選択する。クライアントノードとプロキシノードとの間のトランスポートストリームは、クライアントノードが他の何れかのノードとトランスポートストリームを確立する場合と同様に、ストリーム状態メッセージを使用して確立される。プロキシノードトランスポートインプリメンテーションは、それ自体のステーションアドレスを使用してクライアントノードリンクについてネゴシエートする。プロキシノードは、該プロキシノードと接触するあらゆるクライアントステーションについてメッセージを受信し転送することが可能でありプロミスキャスリレー、または該プロキシノードにとって未知のステーションチャネル上のストリーム状態メッセージを無視することが可能であるプロビジョンドリレー。許可されたクライアントノードのためのステーション定義のプロビジョニングは、帯域外で行われる。リンクが生じるとすなわち、何らかのネットワークアドレスからのストリーム選択メッセージをクライアントノードがプロキシステーションチャネルで受容すると、該クライアントノードはそのネットワークアドレスにプロキシノードをバインドする。該アドレスにプロキシノードがバインドされた後、該クライアントノードは、トランスポートストリームをアクティブに保つために3秒間隔で該プロキシノードにストリーム状態メッセージを送信する。セッションチャネルでプロキシノードからのPingが受信されると、該プロキシノードが使用のために有効とマークされる。何れかのプロキシノードが有効とマークされると、全てのプロキシノードの優先順位が検査されて、後続のセッションメッセージを送信するのに最善な1つが選択される。該選択されたプロキシノードにストリーム選択メッセージがセッションチャネルで送信される。この選択は、該セッションの寿命にわたり、ネットワークの接続性が変化して異なる優先順位のプロキシノードが利用可能となり又は利用不能となる度に多数回変更し得るものである。これら実施形態において、サーバノード16は、2つのクライアントノード間のセッションのためのプロキシを、プロキシノードのプロキシステーションID及び該セッションに割り当てられるセッションIDを含む帯域外プロキシセッションメッセージを使用してプロビジョニングする。プロキシノードのプロビジョニングが行われると、サーバノード16は、該プロキシノードのプロキシステーションIDをその考え得るリレーステーションのリストに含めるようセッション定義を修正する。実施形態によっては、プロキシノードは、サーバノード16によってサーバデータベース内のトランシーバテーブルからプロビジョニングされる。アクティブなプロキシノードのリストがサーバ起動時に読み込まれ、トランシーバテーブルに対する変更の結果として、サーバノード16に対する通知イベントが生じ、該サーバノード16がアクティブなプロキシノードの追加又は削除を行うことが可能となる。サーバノード16とプロキシノードとの間のセッションはサーバノード16により開始される。サーバノード16は、サーバノードステーションID及び一意のセッションIDを含むトランシーバセッション開始メッセージをプロキシノードへ最初に送信する。接続が失われて再確立された場合には、セッションIDが変化し、旧いセッション及びチャネルバインディングを除去するためのクリーンナップ段階がプロキシノード上でトリガされることになる。プロキシノードは、トランシーバセッション開始メッセージを受信すると、上述したようにストリーム状態メッセージで応答する。ストリーム状態メッセージの受信を受信することにより、サーバノード16は、該プロキシノードをアクティブにして、該プロキシノードを、該サーバノードのプロキシ選択ヒューリスティックにより決定されるように、クライアント/サーバ及びピアツーピアセッションのために使用し始める。プロキシノードがアクティブにされると、選択された各セッション毎に以前に確立されたセッション/チャネルバインディングが該プロキシノードに通知される。プロキシノードには、セッション及び2つのエンドポイントクライアントノードを定義するためのStrawセッションメッセージが送信される。セッションについての公開された各チャネル毎に、セッションIDに対してチャネルIDをマップするチャネルバインドメッセージがプロキシノードに送られる。新たなセッションが確立されてプロキシノードが選択されると、該選択されたプロキシノードに該新たなセッションが通知されると同時にクライアントノードに該セッションが通知される。新たなチャネルが被プロキシセッションで公開される際に、チャネルバインドメッセージが送信されると同時に該チャネルが公開される。被プロキシセッションが終了すると、該セッションに関与していた各クライアントノード毎にステーションID及びセッションIDを提供する2つのトランシーバセッション停止メッセージがプロキシノードに通知される。サーバノード16がプロキシノードからの切断を必要とする場合には、該サーバノード16は、該サーバノード16のステーションID及びサーバ/プロキシセッションIDと共にトランシーバセッション停止メッセージを送信する。これにより、プロキシノードは、該セッションで以前に提供された全てのセッションマッピングを削除することになる。6.セッションメンテナンスa.セッションプロトコルパケットSTRAWパケット中のセッションメンテナンスフラグがセットされる場合、該パケットは、STRAWセッションプロトコルパケットであり、これは信頼できないものであり、これは冪等元であり、パケット番号フィールドは解釈されないことになる。STRAWセッションプロトコルパケットの一例として、キープアライブ及びアクノリッジメントACKが挙げられる。i.キープアライブセッションプロトコルキープアライブセッションは通常のSTRAWレコードで始まり、該STRAWレコードは、セッションIDに等しいチャネルIDを有し、セッションメンテナンスフラグがセットされ、ゼロ拡張子タイプ及び長さ、並びにそれに継ぐSODAIDを有する単一のSODA定義データパケットを有するguidSodaSESSIONKeepAliveAck。セッションメンテナンスがフラグフィールドにセットされている場合には、NAKEDフラグフィールドがセットされているすなわち、SODAレコードヘッダが全く存在しないことになるものと想定される。図15を参照すると、STRAWレコードに続くパケットはSODA定義210であり、該SODA定義210は、通常の128ビットのSODAIDと値30を有する16ビットの長さとを有し、続いて32ビットの符号なしアクティブタイムアウトフィールド、32ビットの符号なしアイドルタイムアウトフィールド、16ビットの符号なし送信ウィンドウサイズフィールド、及び16ビットの符号なし受信ウィンドウサイズフィールドを有する。アクティブタイムアウト値は、送信されたSTRAWパケットSTRAWプロトコルパケットを含まないに応じて受信側ステーションにより送信されるべきACK間で生じるミリ秒の最大数を指定するものである。アイドルタイムアウト値は、ステーションにより送信されたACKを最後に受信してからSTRAWプロトコルパケット以外のSTRAWパケットが送信されていない場合に受信側ステーションにより送信されるべきキープアライブメッセージ間で生じるミリ秒の最大数を指定するものである。送信ウィンドウサイズ値は、受信側ステーションがACKを送信するのを待つ前に該ステーションにより送信されるべき最大パケット数を指定するものである。受信ウィンドウサイズ値は、受信側ステーションにACKを送信する前に該ステーションにより受信されるべき最小パケット数を指定するものである。この値は一般に送信ウィンドウサイズよりも小さくなると思われる。かかる場合には、一連の送信済みパケットに対してアクノリッジメントが行われた後、送信側がフロー制御送信停止をトリガし、プロトコルで時間を浪費することなく1セッションの全帯域幅を満たすことが可能である。ii.ACKセッションプロトコルACKプロトコルパケットは、キープアライブパケットとして始まるが、30よりも大きいSODA長さ値を有する。SodaSESSIONKeepAliveAckSODA定義に続くのが、一組のSDSESSIONChannelAckSODA定義であり、これは、セッションについて定義されるアクティブな信頼できる各チャネル毎に1つずつ存在する。図16を参照すると、各SodaSESSIONKeepAliveAckSODA定義212は、値guidSodaSESSIONChannelAckを有する通常の128ビットのSODAIDで始まり、これに値36又はそれ以上の値を有するSODA長さフィールドが続く。これに、128ビットのチャネルID、16ビットの最大パケット番号フィールド、及びゼロ又は1つ以上の損失パケット番号フィールドが続く。損失パケット番号フィールドの個数は、36を上回ったSODA長さ値を2で除算することにより求められる。例えば、SODA長さ値が40である場合には、403622個の損失パケット番号フィールドが存在する。b.フロー制御STRAWセッションパケットフローは、キープアライブ/ACKパケットにより制御される。それらは、セッションチャネルで送信される冪等元の信頼できないメンテナンスメッセージであり、ACKインターバル時間、パケットウィンドウサイズ、及びチャネルアクノリッジメントを含む。それらは、1セッションの複数のチャネルの全てのパケットフローを追跡することの全責務を負うものである。キープアライブメッセージは決してフロー制御されない。キープアライブメッセージは優先順位メッセージとして待ち行列の先頭に入れられ、それが落ちた場合に定期的に再送される。キープアライブメッセージは、インバウンドフローに応じて送信され、パケットが流れている場合にはより高頻度に、最後のインターバルからパケットが発生していない場合にはより低頻度に送信される。これらのメッセージはエンドツーエンドで渡される。このため、プロキシを介した送信は該メッセージを変更しない。STRAWは、あらゆるシリアルチャネル例えば、UDP、TCP、HTTP、更にはPPPを介して送信することが可能である。キープアライブメッセージは、如何なるチャネルであっても使用されます。i.ACKインターバル時間各セッションのキープアライブメッセージで送られる2つのインターバルcMsActive及びcMsIdleが存在する。これらは、キープアライブメッセージ間の最大インターバルを制御する。1パケットの受信時に1セッションがアクティブになり、複数のキープアライブメッセージが少なくともcMsActiveの頻度で送られる。キープアライブを送ったパケットと次のパケットとの間でパケットが全く受信されなかった場合には、該セッションはアイドル状態になり、それ以降のキープアライブメッセージは少なくともcMsIdleの頻度で送られる。このアイドルインターバル中にパケットが受信された場合には、該セッションがアクティブ状態を再開する。通常は、これらのインターバルは、メッセージ間で変更されることはないが、キープアライブが受信される度に、該インターバルは新たな値として解釈されるべきである。両方のインターバルがゼロとなる特殊な場合が存在する。これは、キープアライブメッセージを繰り返しの要求とマークするものである。ステーションは、その指定されたインターバルそれが送るインターバルが満了したがキープアライブがパートナーステーションから受信されていない場合にこのメッセージを送信する。繰り返しを受信するステーションは、全ての購読されているチャネルについてアクノリッジメントと共にキープアライブを直ちに送ることが予想される。ステーションは、幾つかのインターバルを試行することが可能であり、幾つかのackインターバルについて何も受信されない場合には、セッションが失われたものとみなすことが可能である。繰り返しはまた、フロー制御がチャネルを長期間シャットダウンした場合に送ることができる。これは、キープアライブが落ちた場合に生じ得るものでありそれらが信頼できないものであることを想起されたい、該落ちたキープアライブは、後続のキープアライブには存在しないチャネルアクノリッジメントを含むものである。図17は、アクノリッジメントメッセージのフローの制御でストリームトランスポートサービス72の一実施形態により実施される方法の一実施形態を示している。図17の方法によれば、セッションがアクティブである場合図17のブロック214、ストリームトランスポートサービス72は、少なくともセッションパートナーノードから受信した最後のキープアライブ値で指定されているmsActiveパラメータ値の頻度でキープアライブメッセージを送る図17のブロック216。パケットが受信されると図17のブロック218、該セッションがアクティブ状態にあり図17のブロック220、ストリームトランスポートサービス72が、少なくとも、前記セッションパートナーノードから受信した最後のキープアライブ値で指定されているmsActiveパラメータ値の頻度で、キープアライブメッセージを送る図17のブロック216。パケットが受信されない場合には図17のブロック218、ストリームトランスポートサービス72は、2つの連続するキープアライブメッセージが送信される前にセッションパートナーノードからパケットが受信されたか否かを判定する図17のブロック222。最後のパケットがセッションパートナーノードからのものであるため、2つの連続するキープアライブメッセージが送信されていない場合には図17のブロック222、トランスポートサービス72は、パケットが受信されるのを待機する図17のブロック218。最後のパケットがセッションパートナーノードからのものであるため、2つの連続するキープアライブメッセージが送信されていない場合には図17のブロック222、ストリームトランスポートサービス72は、該セッションをアイドル状態にセットする図17のブロック224。該セッションがアイドル状態になると図17のブロック224、ストリームトランスポートサービス72は、少なくとも、セッションパートナーノードから受信した最後のキープアライブ値で指定されているmsIdleの頻度で、キープアライブメッセージを送る図17のブロック226。パケットが受信された場合には図17のブロック228、該セッションがアクティブ状態になり図17のブロック220、ストリームトランスポートサービス72が、少なくとも、セッションパートナーノードから受信した最後のキープアライブ値で指定されているmsActiveパラメータ値の頻度で、キープアライブメッセージを送る図17のブロック216。iiウィンドウサイズ各セッションのキープアライブメッセージで送られる2つのウィンドウサイズsSendWindow及びsRcvWindowが存在する。これらは、一対ではなく、2つの異なるストリームのフローを制御する。送信ウィンドウは、アクノリッジされていないインバウンドパケットを制限する。受信ウィンドウは、アクノリッジされていないアウトバウンドパケットを制限する。2つのパートナーP1P2が互いにそれぞれのウィンドウサイズP1sendP1rcvP2sendP2rcvと称すを送信している場合を想定する。P1から見ると、2つのストリームSOut及びSInが存在する。ストリームP1SOutは、P2send及びP1rcvにより制御される。セッションパートナーノードP1は、ストリームを遮断する前に、アクノリッジされていないパケットをP2sendに送ることになる。P2は、最後にアクノリッジした後にP1rcvパケットを受信した場合にストリームにアクノリッジすることになる。通常、P1rcvは、P2sendから計算され、それよりも一層小さなものとなる。P1rcvは、P2sendの1/2に設定することが可能であり、P1がしばらくの間ストリームを遮断する必要がなかった場合に少し大きく調節し、P1がストリームをブロックしなければならなくなる度に少し小さく調節することが可能である。これは、P2アクノリッジメントの個数及び頻度を妥当なレベルに制御し、ネットワークが許す程度に高速にストリームの流れを高速に保つ。ストリームP1SInは、P1send及びP2rcvによって制御される。セッションパートナーノードP2は、ストリームを遮断する前に、アクノリッジされていないパケットをP1send送ることになる。P1は、最後にアクノリッジした後にP2rcvパケットを受信した場合にストリームにアクノリッジすることになる。通常、P1sendは、公称値10程度に設定され、スキップしたパケット番号混雑に起因して欠落したパケットが生じている場合には一段階小さく調節される。ストリームトランスポートサービスで再送信が生じていない場合には、P1sendを徐々に大きく調節することが可能である。図18A-18Cは、セッションパートナーノードP1P2間のパケットの流れを制御するためにストリームトランスポートサービス72の一実施形態により実施される方法の一実施形態を示している。図18Aは、セッションパートナーノードP1P2間におけるキープアライブメッセージの交換を示しており、この場合、セッションパートナーノードP1により送信されるキープアライブメッセージは、ウィンドウサイズP1send及びP1rcvを含み、セッションパートナーノードP2により送信されるキープアライブメッセージは、ウィンドウサイズP2send及びP2rcvを含む。図18Bは、セッションパートナーノードP1からのパケットの流れを示している。セッションパートナーノードP1により送信されるパケットの流れは、ウィンドウサイズP2send及びP1rcvにより制御される。図示の実施形態では、ウィンドウサイズP2sendは、8パケットとなるようにセッションパートナーP2により設定される。このため、セッションパートナーノードP1は、ストリームを遮断する前に、アクノリッジされていない8パケットを送信することになる。パケット1についてのアクノリッジメントがセッションパートナーノードP2から受信されると、セッションパートナーノードP1がパケット9を送信することができるようにP2sendウィンドウがスライドする。図18Cは、セッションパートナーノードP1上で動作しているストリームトランスポートサービス72がセッションパートナーノードP2からのパケットの受信にアクノリッジするための方法の一実施形態を示している。この方法によれば、セッションパートナーノードP1により最後のアクノリッジメントメッセージが送信された後にセッションパートナーノードP2からP2rcvパケットが受信された場合に図18Cのブロック230、セッションパートナーノードP1がアクノリッジメントメッセージをセッションパートナーノードP2に送信する。それ以外の場合には、最後のアクノリッジメントメッセージがセッションパートナーノードP1により送信された後にセッションパートナーノードP2からP2rcvパケットが受信されるまでセッションパートナーノードP1は待機する図18Cのブロック230。7.チャネルプロトコルi.信頼できないチャネルプロトコル信頼できないものとして定義されたチャネル定義中に信頼可能ビットを有さないチャネルを介して送信されたパケットは、二度と再送信されない。それらのSTRAWレコードヘッダは、信頼できるチャネルを介して送信されたパケットと同じであり、STRAWは、増分していくパケット番号値及び計算されたMAC値を等しく含む全てのヘッダフィールドを計算する。しかし、到来するパケットが、不正なMAC値を有する場合、又は次に予想されるパケット番号値をスキップしている場合には、そのSTRAWは、そのチャネルを購読しているローカルサービスにパケットが損失したことを報告する。適切に応答する例えば、それら自体のアプリケーション層シグナリングを使用し又は損失したオーディオ値を隠蔽すべくオーディオデータのフィルタリングにより損失データを合成するのが該サービスの責務である。ii.信頼できるチャネルプロトコル信頼できるものとして定義されたチャネル定義中に信頼可能ビットを有するチャネルを介して送信されたパケットは、アクノリッジされるまで再送信される。信頼可能性は、STRAWレコードパケット番号フィールドと受信したACKセッションプロトコルパケットとの組み合わせを介して達成される。実施形態によっては、ストリームトランスポートサービス72は、次のようにしてパケットを信頼可能性をもって送信する。ストリームトランスポートサービス72は、アクノリッジされていない送信済みパケットの数が送信ウィンドウサイズを越えるまで、待ち行列に入っているパケットを送信する。送信済みパケットは、アクノリッジされるまでストリームトランスポートサービス72によって保持される。受信したACKは、該ACKが、パケットのチャネルに一致するチャネルID、及びパケットのパケット番号と一致し又はそれを上回る最大パケット番号値を有するSodaSESSIONKeepAliveAckレコードを含む場合に、番号付けされたパケットを受信したことをアクノリッジするものであり、該パケットのパケット番号は、如何なる損失パケット番号値で表されるものでもない。アクノリッジが完了すると、該送信済みパケットの出所であるストリームトランスポートサービスは解放される。ストリームトランスポートサービス72は、損失パケット番号フィールドにパケット番号をリストアップしたSodaSESSIONKeepAliveAckメッセージを受信した場合、又は送信済みパケットのパケット番号を下回る最大パケット番号値を有する2つのACKを当該チャネルについて受信した場合に、アクノリッジされていないパケットを再送する。ストリームトランスポートサービス72は、アクノリッジされていないパケットを引き止めておく例えば、アクティブタイムアウト値×2ms以内にチャネルACKを受信しない場合に、アクティブタイムアウト値0及びアイドルタイムアウト値0を有する特殊な早期Keepaliveを送信することが可能である。このメッセージは繰り返し要求と呼ばれる。これは、パートナーステーションがアクティブ状態にあるかアイドル状態にあるかを全てのチャネルに直ちにアクノリッジしなければならないことを該パートナーステーションに指示するものである。この特殊な全チャネルACKは繰り返しメッセージと呼ばれる。Reiterate繰り返しは、損失したACKパケットから回復する。ACKパケットは冪等元であり、送信側及び受信側は該Reiterateの受信後に同期することになる。STRAWは、ACKメッセージが受信されるまでアクティブタイムアウトインターバルで繰り返し要求を送信し、又はその忍耐の限界を超えてセッションが終了されるバインドしない。図19は、ストリームトランスポートサービス72が所与のセッションパートナーノードと所与の1セッションにおいて信頼できるチャネルでパケットを送信する一実施形態を示している。図19の方法によれば、ストリームトランスポートサービス72は、信頼できるチャネルでパケットを送信する図19のブロック240。ストリームトランスポートサービス72は、送信したパケットのコピーを保持する図19のブロック242。ACKが受信されなかった場合には図19のブロック244、ストリームトランスポートサービス72は、アクノリッジされていないパケットの数が送信ウィンドウサイズパラメータ値を越えるまでパケットを送信し続ける図19のブロック246。アクノリッジされていないパケットの数が送信ウィンドウサイズパラメータ値を越えた場合には図19のブロック246、ストリームトランスポートサービス72は、最後のACKを受信してからの時間がストール期間例えば、アクティブタイムアウト値×2msよりも大きいか否かを判定する図19のブロック248。最後のACKを受信してからの時間がストール期間よりも大きい場合には図19のブロック248、ストリームトランスポートサービス72は、繰り返し要求をセッションパートナーノードに送信する図19のブロック250。該繰り返し要求に応じてセッションパートナーノードから繰り返しメッセージが受信された場合には図19のブロック252、ストリームトランスポートサービス72は、アクノリッジされていないパケットを再送信して図19のブロック254信頼できるチャネルでのパケットの送信を続行し図19のブロック240、それ以外の場合には、ストリームトランスポートサービス72はセッションを終了させる図19のブロック256。最後のACKを受信してからの時間がストール期間以下である場合には図19のブロック248、ストリームトランスポートサービス72は、アクノリッジされていないパケットを再送信して図19のブロック254信頼できるチャネルでのパケットの送信を続行する図19のブロック240。ACKが受信された場合には図19のブロック244、ストリームトランスポートサービス72は、保持しているパケットのうちアクノリッジされたものを、セッションパートナーノードによる受信が完了しているため解放する図19のブロック258。ACKで識別された損失パケットが存在する場合には図19のブロック260、ストリームトランスポートサービス72は、該識別された損失パケットを再送信する図19のブロック262。実施形態によっては、送信側及び受信側ネットワークノード上で動作しているストリームトランスポートサービス72は、送信側ネットワークノードによるパケットの再送信を最適化するために、STRAWレコード102図5参照のクッキーフィールドを使用する。かかる実施形態では、送信側ネットワークノードは、STRAWレコードのクッキーフィールドで一意のセッションレベルクッキー値を送信する。該送信側ネットワークノードは、所与のデータ構造例えば、テーブル168で該クッキー値の順序づけされたリストを格納する。受信側ネットワークノードは、各アクノリッジメントパケットACKと共に、該ACKパケットと共に送信されるSTRAWレコードのクッキーフィールドで、受信側ネットワークノードにより処理された最後のパケットのクッキー値を送信する。上述した複数の実施形態の場合のように、各ACKパケットはまた、最大受信パケット番号の値及び損失したパケットのパケット番号を、該ACKパケットで送信されるACKSODA定義の最大パケット番号フィールド及び損失パケット番号フィールド内に含む図16参照。ACKパケットを受信した際に、送信側ネットワークノードは、受信側ネットワークノードにより処理された最後のパケットのクッキー値を抽出する。送信側ネットワークノードは、図19に示す方法のブロック246でこの情報を使用する。詳細には、送信側ネットワークノードは、該抽出されたクッキー値の後に送信されたクッキー値を有するパケットを、アクノリッジされていないパケットの数に含めない図19のブロック246参照。このようにして、送信側ネットワークノードは、受信側ネットワークノードにより受信されたが該受信されたパケットの処理における不可避のレイテンシの結果として処理が完了していない該パケットの再送信を回避する。前記クッキー値は、1セッション中のパケットを一意に識別する任意のタイプのデータ例えば、タイムスタンプ値又は反復しないカウンタ値とすることが可能である。上記で説明したように、パケット番号は、それぞれのチャネルでパケットに割り当てられる一意の一連の反復する番号である。ACK処理は全てのチャネルについてセッションレベルで生じるため、前記クッキーは、チャネルレベルのパケット番号のみでは提供されない追加情報を提供する。これは、クッキーがパケットストリーム全体内のマーカーである一方、パケット番号が各チャネルのパケットストリーム内のマーカーであるからである。図20は、上記段落で説明した実施形態に従って送信側ノード264によりパケットを送信し及び受信側ノード266により受信したパケットのアクノリッジメントを行う方法の一実施形態を示している。この例では、送信側ネットワークノード264は、それぞれの一意のクッキー値C106C107C108を有する一連のパケットをその送信待ち行列TXQueueから受信側ネットワークノード266へと送信する。該受信側ネットワークノード266は、送信されたパケットをその受信待ち行列RXQueue内に受信し、該RXQueueで該パケットの処理を開始する。クッキー値C108を有するパケットの処理後、受信側ネットワークノード266は、送信側ネットワークノードから受信したパケットから抽出された最高の受信パケット番号値PNM最大パケット番号及びクッキー値C108を含むACKパケット267を送信側ネットワークノードに送信する。該ACKパケット267を受信する前に、送信側ネットワークノードは、それぞれの一意のクッキー値C109C110を有する一連のパケットを、その送信待ち行列TXQueueから受信側ネットワークノード266へ送信する。送信側ネットワークノードがACKパケット267を受信すると、該送信側ネットワークノードは、上述したように最高の受信パケット番号値に基づいてリソースを解放する。送信側ネットワークノードはまた、テーブル中のクッキー値を参照して、受信側ネットワークノードにより処理された最後のパケットを判定する。送信側ネットワークノードは、クッキー値C108の後に送信されたクッキー値を有するパケットを、アクノリッジされていないパケットの数に含めない図19のブロック246参照。受信側ネットワークノードが、アクノリッジされていないパケットを損失し、且つそれが一連のパケット中の最後のパケットであった場合、受信側ネットワークノードは、セッションをアイドル状態にマークすることが可能であり、送信側ネットワークノードは、数秒間にわたり受信側ネットワークノードからの他のACKを確認しないことが可能である。しかし、このシナリオは、パケットの損失に通ずるものではない。詳細には、図19の方法によれば、送信側ネットワークノードは、アクティブ状態にセットされたセッションを現在有しているがストール期間よりも長くACKを受信していない場合図19のブロック248参照、送信側ネットワークノードは、繰り返しメッセージを発行して図19のブロック250、受信側ネットワークノードに直ちに完全なACKを送信させる。送信側ネットワークノードは、該繰り返しメッセージに応じて送信された該ACKにおけるクッキー値を現在値として扱い、それが受信側ネットワークノードに送信された最後のパケットを網羅していない場合には、該送信側ネットワークノードは、かかる送信された最後のパケットを損失したパケットとマークしてそれらパケットを再送信する図19のブロック254。実施形態によっては、ストリームトランスポートサービス72は、次のようにしてパケットを信頼性をもって受信する。ストリームトランスポートサービス72は、無プロトコルパケットの受信時に最後に受信したアクティブタイムアウト値についてセッションACKタイマを開始させる該タイマがまだ開始されていない場合。該タイマが満了すると、ストリームトランスポートサービス72は、アクティブな最後のACK後にパケットを受信した全てのチャネルについてSodaSESSIONKeepAliveAckレコードを含むACKを送信する。次いで、該タイマが開始されてから何れかのパケットが受信された場合には、該タイマがアクティブタイムアウト値にリセットされ、それ以外の場合にはアイドルタイムアウト値にセットされる。ストリームトランスポートサービス72は、パケットが順序違いで受信された際にACKを送信する。ストリームトランスポートサービス72は、受信ウィンドウサイズに達した際、すなわち、受信したパケット番号が受信ウィンドウサイズによる最後のアクノリッジ済みのパケット番号よりも大きい場合に、ACKを送信する。ストリームトランスポートサービス72は、セッションがバインドされた際にACKを送信する。ストリームトランスポートサービス72は、繰り返し要求が受信された際にACKを送信する。ACKが送信される場合には、全てのアクティブなチャネル又はセッションが繰り返し要求を受信した場合には全てのチャネルがSodaSESSIONKeepAliveAckレコードで表される。複製したメッセージそのチャネルで既にアクノリッジ済みのパケット番号を有するものが受信された場合には、ストリームトランスポートサービス72は、次のACKで繰り返すよう該セッションをマークする。図21は、ストリームトランスポートサービス72が所与のセッションパートナーノードと所与の1セッションにおいて信頼できるチャネルでパケットを受信する一実施形態を示している。図21の方法によれば、無プロトコルパケットの受信に応じて図21のブロック270、ストリームトランスポートサービス72は、セッションパートナーノードから受信した最後のアクティブタイムアウト期間にセッションタイマをセットする図21のブロック272。ストリームトランスポートサービス72は次いで、次のパケットが受信されるのを待機する図21のブロック274。セッション時間が満了する前にパケットが受信されなかった場合図21のブロック276、ストリームトランスポートサービス72は、全てのアクティブなチャネルについてACKを送信して図21のブロック278、セッション時間をアイドルタイムアウト期間にセットする図21のブロック280。セッション時間が満了する前にパケットが受信された場合には図21のブロック276、ストリームトランスポートサービス72は、該受信したパケットが順序違いのものである場合図21のブロック282284、該受信したパケットによって受信ウィンドウサイズに達した場合図21のブロック286288、該受信したパケットが当該セッションにバインドする場合図21のブロック290292、又は該受信したパケットが繰り返し要求メッセージである場合図21のブロック294296に、ACKを送信する。8.プロトコル拡張子実施形態によっては、ストリームトランスポートプロトコルは、拡張子:シングルトン及びマルチを含む。ほぼ全てのパケットは、ゼロの拡張子タイプ及びゼロの拡張長さを有するシングルトンで送信される。これらのパケットは、受信時に直ちに処理される。マルチで送信されたパケットは、オーバーサイズレコードUDPペイロードが許可するよりも大きなレコードの送信を意図したものである。かかるパケットのデータペイロードは、単純にパケット番号順に加えられたものであり、一連のSTRAWパケットが全て受信された際に単一のデータパケットとして処理される。信頼できないチャネルでマルチを使用した場合には、該マルチシーケンス中の1パケットを損失した結果として、該シーケンス中の全てのパケットを破棄して、購読されているサービスに損失したと報告することになる。V.例示的な適用環境A.序論ストリームトランスポートプロトコルは、通信アプリケーション2830及びサーバノード16により提供されるプラットフォームの様々な異なる適用環境をサポートする。例示的な実施形態では、リアルタイムチャット対話上での複数の空間メタファの視覚化のうちの1つ又は2つ以上を適用する。これらの視覚化は、リアルタイムチャット対話に伴う現在の通信状態を表現するためのコンテキストを提供する。前記空間メタファはまた、リアルタイムチャット対話に参加するために通信者により使用される様々なインタフェイス要素の提示を編成するためのコンテキストを提供する。該空間メタファの視覚化は、インターネット又は何らかの形態の内部的なネットワーク/イントラネットを介した2又は3以上の通信者間のリアルタイムでのテキストベース通信を提供する随意選択的に、オーディオ、ビデオ、ファイル共有、及びアプリケーション共有チャネル等の1つ又は2つ以上の他のリアルタイム通信チャネルを有するあらゆるタイプのインスタントメッセージングプラットフォームに適用することが可能である。例えば、本実施形態は、AOL登録商標インスタントメッセンジャー、MSN登録商標メッセンジャー、Yahoo登録商標メッセンジャー、Google登録商標Talk、及びSkype登録商標といった現在利用可能なインスタントメッセージングプラットフォームの何れと統合させることも可能である。図22は、ネットワーク通信環境10図1参照の一実施形態300を示しており、この場合、サーバノードは仮想環境生成手段302により実施されている。該仮想環境生成手段302は、ネットワークインフラストラクチャサービス環境306を提供する少なくとも1つのサーバネットワークノード304を含む。通信アプリケーション2832及びネットワークインフラストラクチャサービス環境306は共に、上述した複数の空間メタファの視覚化の1つ又は2つ以上を含む空間的仮想通信環境本書では単に仮想環境とも称すを生成するためのプラットフォームを提供する。ネットワークインフラストラクチャサービス環境306は、仮想領域アプリケーション310に従って仮想領域308内の第1及び第2のクライアントノード1214のセッションを管理する。仮想領域アプリケーション310は、仮想領域308によってホストされ、仮想領域308の記述を含む。第1及び第2のクライアントネットワークノード1214上で動作する通信アプリケーション2830は、ネットワークインフラストラクチャサービス環境306から受信したデータに従って仮想領域308のそれぞれのビューを提供し、並びに通信者からのコマンドを受信するため及び上述のような通信者間のリアルタイム通信を強化する空間的なインタフェイスを提供するためのそれぞれのインタフェイスを提供する。通信者は典型的には、それぞれのアバターにより仮想領域308内で表現され、該アバターは典型的には、それぞれのネットワークノードで通信者により入力されるコマンドに応じて仮想領域308内を動き回る。仮想領域308の各通信者のビューは典型的には、通信者のアバターの視点で提示され、これにより通信者が経験する没入のレベルが増大する。各通信者は典型的には、自分自身のアバターの周囲の仮想領域308のあらゆる部分を見ることが可能である。実施形態によっては、通信アプリケーション2830は、仮想領域308内の通信者のアバターの位置に基づいて、該仮想領域308を共有している第1及び第2のクライアントネットワークノード1214と他のネットワークノードとの間のリアルタイムデータストリーム接続を確立する。ネットワークインフラストラクチャサービス環境306はまた、通信者間の対話記録311を含む関係データベース309を維持する。各対話記録311は、一対の通信者間の対話状況を記述したものである。。B.ネットワークインフラストラクチャサービスネットワークインフラストラクチャサービス環境306は典型的には、クライアントノード1214と他のネットワークノードとの間のネットワーク接続を確立し管理するプロセスで通信アプリケーション2830と協働する1つ又は2つ以上のネットワークインフラストラクチャサービスを含む図1及び図22参照。該ネットワークインフラストラクチャサービスは、単一のネットワークノード上で実行することが可能であり、又は複数のネットワークノードにわたって分散させることが可能である。ネットワークインフラストラクチャサービスは典型的には、1つ又は2つ以上の専用のネットワークノード例えば、サーバコンピュータ又は1つ又は2つ以上のエッジサービスルーティング及びスイッチング等を実行するネットワーク装置上で実行される。しかし、実施形態によっては、複数のネットワークインフラストラクチャサービスのうちの1つ又は2つ以上は、複数の通信者の複数のネットワークノードのうちの少なくとも1つで実行される。ネットワークインフラストラクチャサービス環境30の例示的な実施形態に含まれるネットワークインフラストラクチャサービスとして、アカウントサービス、セキュリティサービス、領域サービス、ランデブーサービス、及び対話サービスが挙げられる。アカウントサービスアカウントサービスは、仮想環境のための通信者のアカウントを管理する。アカウントサービスはまた、あらゆるネットワークインフラストラクチャサービスに対してクライアントネットワークノードの認証を行うために該クライアントネットワークノードにより使用することができる認証トークンの生成及び発行を管理する。セキュリティサービスセキュリティサービスは、仮想環境の資源その他のリソースに対する通信者のアクセスを管理する。セキュリティサービスにより実施されるアクセス制御方法は典型的には、1つ又は2つ以上の能力この場合、適切な能力又は許可を有するエンティティに対してアクセスが許可される及びアクセス制御リストこの場合、該リスト上に存在する識別子を有するエンティティに対してアクセスが許可されるに基づくものである。リソースに対する特定の通信者のアクセスが許可された後、該通信者は典型的には、他のネットワークインフラストラクチャサービスにより提供される機能を使用してネットワーク通信環境300内で対話を行う。領域サービス領域サービスは仮想領域を管理する。実施形態によっては、領域サービスは、一組の制約312図22参照を受ける仮想領域アプリケーション308に従って、第1及び第2のクライアントネットワークノード1214上で動作している通信アプリケーション2832のリモートコンフィギュレーションを行う。該制約312は典型的には、仮想領域に対するアクセスの制御を含む。このアクセス制御は典型的には、1つ又は2つ以上の能力この場合、適切な能力又は許可を有する通信者又はクライアントノードに対してアクセスが許可される及びアクセス制御リストこの場合、該リスト上に存在する識別子を有する通信者又はクライアントノードに対してアクセスが許可されるに基づくものである。領域サービスはまた、要求側エンティティの能力の影響下にある仮想領域に関連付けられたネットワーク接続を管理し、仮想領域に関する大域状態情報を維持し、及び仮想領域308により画定される状況で共有通信セッションに参加しているクライアントネットワークノードのためのデータサーバとして働く。該大域状態情報は、仮想領域内にある全てのオブジェクト及び該オブジェクトのそれぞれの仮想領域内の場所のリストを含む。領域サービスは、クライアントネットワークノードのコンフィギュレーションを行う命令を送信する。領域サービスはまた、通信セッションへの参加を要求する他のクライアントネットワークノードを登録し、及び該他のクライアントネットワークノードへ初期化情報を送信する。この過程で、領域サービスは、参加中の各クライアントネットワークノードへ、仮想領域アプリケーション310に従ってクライアントネットワークノード上に仮想領域308をレンダリングするために必要となるコンポーネント例えばプラグインのリストを送信することが可能である。領域サービスはまた、通信障害が発生した場合にクライアントネットワークノードが所定の大域状態に同期できることを確実にする。領域サービスは典型的には、仮想領域に関連付けられた統制ルールを介して仮想領域との通信者の対話を管理する。ランデブーサービスランデブーサービスは、存在情報の収集、格納、及び配布を管理し、及び要求側エンティティの能力の影響下で例えば、接続ハンドルの配布を管理することによりネットワークノードが互いに通信するための機構を提供する。ランデブーサービスは典型的には、存在情報を存在データベースに格納する。ランデブーサービスは典型的には、通信者のプライバシープリファレンスを介して通信者相互の対話を管理する。対話サービス対話サービスは、通信者間の対話の記録311を含む関係データベース36を維持する。通信者間の各対話毎に、ネットワークインフラストラクチャサービス環境306の1つ又は2つ以上のサービス例えば、領域サービスが対話データを対話サービスへ送信する。これに応じて、対話サービスは、1つ又は2つ以上のそれぞれの対話記録を生成し、それを関係データベースに格納する。各対話記録は、一対の通信者間の対話状況を記述したものである。例えば、実施形態によっては、対話記録は、各通信者に関する識別子、対話の場所例えば、仮想領域インスタンスに関する識別子、対話場所の階層の記述例えば、対話部屋の一層大きな領域に対する関係の記述、対話の開始時刻及び終了時刻、及び対話中に共有され又は記録された全てのファイル及びその他のデータストリームのリストを含む。このため、各リアルタイム対話毎に、対話サービスは、該対話が発生したとき、該対話が発生した場所、関与する通信者に関して対話中に生じたこと例えば、参加及び退出、アクティブ又は非アクティブにされたオブジェクト、及び共有されたファイルを追跡する。対話サービスはまた、要求側エンティティの能力の影響下で関係データベースの照会をサポートする。対話サービスは、対話データベース記録についての照会の結果を仮想領域に基づいてソートされた所定の順序例えば頻度順又は時刻順で提示する。該照会結果を使用して、通信者がどの仮想領域でどの人に会ったかに関する接触頻度でのソート、仮想領域とは無関係に通信者が会った人によるソート、及び通信者が最も多く出入りしている仮想領域によるソートを行うことが可能である。該照会結果はまた、関係に基づいて特定のタスクを自動化するヒューリスティックシステムの一部としてアプリケーションの開発者が使用することが可能なものである。この種のヒューリスティックの一例が、特定の仮想領域を6回以上訪れた通信者がノックすることなくデフォルトで入ることを許可するヒューリスティック、又は特定の時刻に特定の領域内に存在する通信者が、それと同じ時刻に同じ領域内に存在する別の通信者により作成されたファイルを修正し削除することを可能にするヒューリスティックである。関係データベース309の照会は、他の検索と組み合わせることが可能である。例えば、関係データベースの照会を、ネットワークインフラストラクチャサービス環境306の領域外にある通信システム例えば、Skype登録商標、Facebook登録商標、及びFlickr登録商標を使用した接触との対話について生成された接触履歴データの照会と組み合わせることが可能である。C.仮想領域通信アプリケーション2832及びネットワークインフラストラクチャサービス環境306は典型的には、仮想領域のインスタンスにより画定される通信状況においてネットワークノードとのリアルタイム接続を管理する。仮想領域インスタンスは、抽象座標に関して定義される抽象的非幾何学的仮想空間に対応することが可能である。代替的に、仮想領域インスタンスは、特定の視覚化に関連付けられた1次元、2次元、又は3次元の幾何学座標に関して定義される視覚的仮想空間に対応することが可能である。抽象的仮想領域は、個々の視覚化に関連付けることも関連付けないことも可能であり、一方、視覚的仮想領域は、個々の視覚化に関連付けられる。上述のように、通信者は典型的には、関連する視覚化を有する仮想領域内の個々のアバター例えば、スプライトによって表現される。該アバターは、それぞれのネットワークノードにおいて通信者により入力されたコマンドに応じて仮想領域内を移動する。実施形態によっては、仮想領域インスタンスの通信者のビューは典型的には、通信者のアバターの視点から提供され、各通信者は典型的には、該通信者のアバターの周囲の視覚的仮想領域のあらゆる部分を見ることが可能であり、これにより該通信者が経験する没入のレベルが増大する。仮想領域は典型的には、仮想領域内の複数のアバターにより表現される複数のネットワークノード間の複数のリアルタイムデータストリームのスイッチングを支配するそれぞれのルールに関連付けられた1つ又は2つ以上のゾーンを含む。該スイッチングルールは、ネットワークノードの各々で実行されるローカル接続プロセスが他のネットワークノードとの通信を確立する態様を仮想領域のゾーン内の通信者のアバターの場所に基づいて指示するものである。仮想領域は典型的には、仮想領域の幾何学的要素の記述及び1つ又は2つ以上のルールスイッチングルール及び統制ルールを含むを含む仕様によって定義される。該スイッチングルールは、複数のネットワークノード間のリアルタイムストリーム接続を支配する。該統制ルールは、仮想領域自体、仮想領域内の領域、及び仮想領域内のオブジェクトといったリソースに対する通信者のアクセスを制御するものである。実施形態によっては、仮想領域の幾何学的要素は、COLLADADigitalAssetSchemaRelease141April2006仕様httpwwwkhronosorgcolladaから入手可能に従って記述され、スイッチングルールは、米国特許出願第11923649号及び11923634号に記載されるCOLLADAStreamsReference仕様に従ってXMLExtensibleMarkupLanguageテキスト形式本書では仮想空間記述形式VSDLと称すを用いて記述される。仮想領域の幾何学的要素は典型的には、仮想領域の物理ジオメトリ及びコリジョンジオメトリを含む。該物理ジオメトリは、仮想領域の形状を記述するものである。該物理ジオメトリは典型的には、三角形、四角形、又は多角形の表面から形成される。該物理ジオメトリ上に色及びテクスチャがマッピングされて、仮想領域のための一層現実的な外観が生成される。例えば、視覚的ジオメトリ上に光をペイントし、及び該光の近くのテクスチャ、色、又は明度を変更することにより、照明効果を与えることが可能である。前記コリジョンジオメトリは、オブジェクトが仮想領域内を移動することができる態様を画定する不可視表面を記述するものである。該コリジョンジオメトリは、視覚的ジオメトリと一致させること、視覚的ジオメトリの一層単純な近似に対応させること、又は仮想領域の設計者の特定用途向けの要件に関連するものとすることが可能である。前記スイッチングルールは典型的には、仮想領域の位置に関してリアルタイムデータストリームのソース及びシンクを接続するための条件の記述を含む。各ルールは典型的には、該ルールの適用対象となるリアルタイムデータストリームのタイプと、該ルールが適用される仮想領域内の1つ又は2つ以上の場所とを画定する属性を含む。実施形態によっては、各ルールは、随意選択的に、必要とされるソースの役割、必要とされるシンクの役割、ストリームの優先順位、及び必要とされるストリーム操作トポロジーを指定する、1つ又は2つ以上の属性を含むことが可能である。実施形態によっては、仮想領域の特定部分について定義された明示的なスイッチングルールが存在しない場合に、1つ又は2つ以上の暗黙又はデフォルトのスイッチングルールを該仮想領域の該部分に適用することが可能である。1つの例示的なデフォルトスイッチングルールが、ポリシールールの支配下で一領域内のあらゆるソースをあらゆる互換性を有するシンクへと接続するルールである。ポリシールールは、複数のクライアントノード間の全ての接続に対して大域的に適用することが可能であり、又は個々のクライアントノードとの個々の接続に対してのみ適用することが可能である。ポリシールールの一例が、仮想領域内で互いに所定の距離又は半径内にあるそれぞれのオブジェクトに関連付けられている互換性を有するシンクとのソースの接続のみを可能とする近接ポリシールールである。実施形態によっては、統制ルールは、仮想領域にアクセスする者、そのコンテンツにアクセスする者、仮想領域のコンテンツに対するアクセスの範囲例えば、該コンテンツに対してユーザができること、及びそれらコンテンツへのアクセスに後続する結果例えば、監査ログ及び支払要求といった記録の保持を制御するために仮想領域に関係する。実施形態によっては、仮想領域全体又は仮想領域の1つのゾーンが統制網governancemeshに関連付けられる。実施形態によっては、統制網は、米国特許出願第11923629号及び第11923634号に記載されているゾーン網の実施形態と類似した態様で実施される。統制網は、ソフトウェアアプリケーションの開発者が、統制ルールを一仮想領域又は一仮想領域の一ゾーンに関連付けることを可能にする。これにより、仮想領域内のあらゆるファイルについてそれぞれの許可を生成する必要がなくなり、及び同一ドキュメントをコンテキストに応じて異なる態様で扱う必要がある場合に生じ得る複雑さに対処する必要がなくなる。実施形態によっては、仮想領域は、該仮想領域の1つ又は2つ以上のゾーンをディジタル著作権管理DRM機能に関連付ける統制網に関連付けられる。DRM機能は、仮想領域の1つ又は2つ以上、仮想領域内の1つ又は2つ以上のゾーン、又は仮想領域内のオブジェクトに対するアクセスを制御する。DRM機能は、通信者が仮想領域内で統制網の境界を越えるたびにトリガされる。DRM機能は、トリガ動作が許可されているか否かを判定し、トリガ動作が許可されている場合には、許可されている動作の範囲、支払いが必要か否か、及び監査記録を生成する必要があるか否かを判定する。仮想領域の例示的な実施態様では、関連付けられた統制網は、通信者が仮想領域に入ることができる場合に該通信者が該仮想領域に関連付けられた全てのドキュメントについて動作ドキュメントの操作、ドキュメントの閲覧、ドキュメントのダウンロード、ドキュメントの削除、ドキュメントの変更、及びドキュメントの再アップロードを含むを実行することができるように構成される。このようにして、仮想領域は、該仮想領域により定義されたコンテキストで共有され議論された情報の保存場所となることができる。仮想領域の仕様に関する更なる詳細が、米国特許出願第61042714号2008年4月4日出願、第11923629号2007年10月24日出願、及び第11923634号2007年10月24日出願に記載されている。D.通信アプリケーション実施形態によっては、通信アプリケーション26は、以下のものを含む。a.ローカルHIDHumanInterfaceDevices及びオーディオプレイバック装置b.So3Dグラフィカルディスプレイ、アバター、及び物理エンジンc.システムデータベース及び格納設備ローカルHIDHumanInterfaceDevices及びオーディオプレイバック装置ローカルHIDは、通信者が、仮想領域通信セッションに参加している間に命令及びその他の信号をクライアントネットワークノードに入力することを可能にするものである。例示的なHIDとして、コンピュータキーボード、コンピュータマウス、タッチスクリーンディスプレイ、及びマイクが挙げられる。オーディオプレイバック装置は、通信者が仮想領域通信セッション中に受信したオーディオ信号を再生することを可能にする。例示的なオーディオプレイバック装置として、オーディオ信号の操作例えば、ミキシング及び特殊効果の適用を行うためのオーディオ処理ハードウェア例えば、サウンドカード及び音声を出力するためのスピーカが挙げられる。So3Dグラフィカルディスプレイ、アバター、及び物理エンジンSo3Dエンジンは、ディスプレイモニタにおける仮想領域及び該仮想領域内のオブジェクトの個々のビューの表示を制御する3次元視覚化エンジンである。So3Dエンジンは典型的には、グラフィカルユーザインタフェイスドライバ及びHIDデバイスと協働して仮想領域のビューを表示し、及び通信者が通信アプリケーション26の動作を制御することを可能にする。実施形態によっては、So3Dエンジンは、領域サービスからのグラフィクスレンダリング命令を受信する。So3Dエンジンはまた、仮想領域内に通信者のアバターを描画するために必要なイメージを含むローカル通信者アバターデータベースに対して読み出しを行うことが可能である。この情報に基づいて、So3Dエンジンは、仮想領域及び該仮想領域内のオブジェクトの視覚的表現すなわち、イメージを該仮想領域内の通信者のアバターの視点位置及び向きから生成する。この視覚的な表現は典型的には、オペレーティングシステムのグラフィクスレンダリング要素へと渡され、該要素がグラフィクスレンダリングハードウェアを駆動して仮想領域の視覚的表現をクライアントネットワークノード上でレンダリングする。通信者は、HIDデバイス例えば、コンピュータマウスを介してビュー制御コマンドを入力することにより、表示される仮想領域のビューを制御することが可能である。So3Dエンジンは、該ビュー制御コマンドに従って仮想領域のビューを更新させる。So3Dエンジンはまた、領域サービスから受信した更新されたオブジェクト位置情報に従って、ディスプレイモニタ上の仮想領域のグラフィック表現を更新させる。E.システムデータベース及び格納設備システムデータベース及び格納設備は、該プラットフォームにより使用される様々な種類の情報を格納する。該格納設備により一般に格納される例示的な情報として、存在データベース、関係データベース、アバターデータベース、リアルユーザIDRUIDデータベース、アートキャッシュデータベース、及び領域アプリケーションデータベースが挙げられる。この情報は、単一のネットワークノード上に格納することが可能であり、又は複数のネットワークノードに渡って分散させることが可能である。F.クライアントノードアーキテクチャ通信は典型的には、クライアントネットワークノードからネットワーク20へ接続する。クライアントネットワークノードは典型的には、汎用コンピュータシステム又は専用の通信コンピュータシステム又はネットワーク対応型ビデオゲームコンソール等のコンソールにより実施される。クライアントネットワークノードは、他のネットワークノードとのリアルタイムデータストリーム接続を確立する通信プロセスを実行し、典型的には通信者が入った各仮想領域のビューを提供する視覚化レンダリングプロセスを実行する。図23は、コンピュータシステム320により実施されたクライアントネットワークノードの一実施形態を示している。該コンピュータシステム320は、プロセッサユニット322、システムメモリ324、及び該プロセッサユニット322を該コンピュータシステム320の様々な要素に接続するシステムバス326を含む。該プロセッサユニット322は、1つ又は2つ以上のデータプロセッサを含むことが可能であり、その各プロセッサは、市販の様々なコンピュータプロセッサの何れの形態をとることも可能である。システムメモリ324は、1つ又は2つ以上のコンピュータ読み取り可能媒体を含み、典型的には、ソフトウェアアプリケーションに対して利用可能となるアドレスを画定するソフトウェアアプリケーションアドレス指定空間が関連付けられる。該システムメモリ324は、コンピュータシステム320のための起動ルーチンを含むBIOSBasicInputOutputSystemを格納したROMReadOnlyMemory、及びRAMRandomAccessMemoryを含むことが可能である。システムバス326は、メモリバス、周辺機器用バス、又はローカルバスとすることが可能であり、及び様々なバスプロトコルPCI、VESA、MCAMicrochannel、ISA、及びEISAを含むの何れと互換性を有するものとすることも可能である。コンピュータシステム320はまた、永続記憶メモリ328例えば、ハードディスクドライブ、フロッピーディスクドライブ、CDROMドライブ、磁気テープドライブ、フラッシュメモリデバイス、及びディジタルビデオディスクを含むことが可能であり、該永続記憶メモリ328は、システムバス326に接続され、データ、データ構造、及びコンピュータ実行可能命令の不揮発性の又は永続的な記憶を提供するて1つ又は2つ以上のコンピュータ読み取り可能媒体ディスクを含む。通信者は、1つ又は2つ以上の入力装置330例えば、1つ又は2つ以上のキーボード、コンピュータマウス、マイク、カメラ、ジョイスティック、Wii登録商標入力装置等の物理モーションセンサ、及びタッチパッドを使用してコンピュータシステム320と対話する例えば、コマンド又はデータを入力することが可能である。情報は、ディスプレイコントローラ334により制御されるディスプレイモニタ332上で通信者に提示されるGUIGraphicalUserInterfaceを介して提示することが可能である。コンピュータシステム320はまた、他の入出力装置例えば、スピーカ及びプリンタ等の出力用周辺機器を含むことが可能である。コンピュータシステム320は、ネットワークアダプタ336ネットワークインタフェースカード又はNICとも呼ばれるを介して他のネットワークノードと接続する。APIApplicationProgrammingInterface338、OSOperatingSystem340例えば、MicrosoftCorporationRedmondWashingtonUSAから入手可能なWindowsXP登録商標オペレーティングシステム、通信アプリケーション26、ドライバ342例えば、GUIドライバ、ネットワーク転送プロトコル344、及びデータ346例えば、入力データ、出力データ、プログラムデータ、レジストリ、及びコンフィギュレーション設定を含む、多数のプログラムモジュールをシステムメモリ324に格納することが可能である。G.サーバノードアーキテクチャ実施形態によっては、仮想環境生成手段16の1つ又は2つ以上のサーバネットワークノードは、その各サーバネットワークノードが典型的には1つ又は2つ以上のサーバソフトウェアアプリケーションを含むことを除き、クライアントネットワークノード320と同じタイプのそれぞれの汎用コンピュータシステムによって実施される。別の実施形態では、仮想環境生成手段302の1つ又は2つ以上のサーバネットワークノードは、エッジサービス例えば、ルーティング及びスイッチングを実行するそれぞれのネットワーク装置によって実施される。VI.結論本書で説明した実施形態は、個々のネットワークノードを操作している通信者間のリアルタイムネットワーク通信をサポートするストリームトランスポートプロトコルを提供する。該ストリームトランスポートプロトコルは、比較的低い計算上のリソース要件を有するものであり、このため、現在利用可能な広範なコンピューティング装置及びネットワーク接続を使用してリアルタイム通信性能を達成することができる。他の実施形態は、特許請求の範囲内のものである。