JP2013524632A - ネットワークノード間のネットワーク通信の管理及びストリームトランスポートプロトコル - Google Patents

ネットワークノード間のネットワーク通信の管理及びストリームトランスポートプロトコル Download PDF

Info

Publication number
JP2013524632A
JP2013524632A JP2013502658A JP2013502658A JP2013524632A JP 2013524632 A JP2013524632 A JP 2013524632A JP 2013502658 A JP2013502658 A JP 2013502658A JP 2013502658 A JP2013502658 A JP 2013502658A JP 2013524632 A JP2013524632 A JP 2013524632A
Authority
JP
Japan
Prior art keywords
session
network node
client network
channel
given
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2013502658A
Other languages
English (en)
Inventor
アルトマイアー，ジョセフ
バトラー，ロバート
ヴァン・ウィー，デイヴィッド
Original Assignee
ソーシャル・コミュニケーションズ・カンパニー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ソーシャル・コミュニケーションズ・カンパニー filed Critical ソーシャル・コミュニケーションズ・カンパニー
Publication of JP2013524632A publication Critical patent/JP2013524632A/ja
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

ストリームトンランスポートプロトコルは、個々のクライアントネットワークノード(12,14)で操作を行っている複数の通信者の間のリアルタイムネットワーク通信をサポートする。該ストリームトランスポートプロトコルは、対の構成要素となるクライアントネットワークノード(12,14)間のネットワーク接続を介したそれぞれのピア・ツー・ピア・セッションを定義するそれぞれのセッション定義を用いたクライアントネットワークノード(12,14)の各対のプロビジョニングを含む、クライアント通信セッションのリモート管理をサポートする。該ストリームトンランスポートプロトコルは、現在利用可能な広範なコンピューティング装置及びネットワーク接続を使用してリアルタイム通信性能を達成することができるように、比較的低い計算リソース要件を有するものである。
【選択図】

Description

面と向かっての対話が実際的でない場合、人々は、１つ又は２つ以上の技術的な解決策に依存して自身の対話の必要性を満たすことが多い。かかる解決策は典型的には、面と向かっての対話の１つ又は２つ以上の特徴をシミュレートするよう設計される。従来の電話システムは、電話をかける者の間での音声通信を可能にするものである。インスタントメッセージング（「チャット」とも呼ばれる）通信システムは、インスタントメッセージサーバによって相互接続された複数のインスタントメッセージコンピュータクライアントを介してユーザがテキストメッセージをリアルタイムで通信することを可能にする。インスタントメッセージングシステムによっては、更に、ユーザ制御可能なグラフィックオブジェクト（「アバター」と呼ばれる）によって仮想環境内にユーザを表現することを可能にする。対話型の仮想現実通信システムは、遠隔地にいる複数のユーザが多数のリアルタイムチャネルを介して通信すること及び各ユーザのアバターを仮想空間内で操作することにより互いに対話することを可能にする。
成功を収める通信システムは一般に、現在利用可能なコンピューティング装置及び制約のあるネットワーク帯域幅を使用してリアルタイム通信性能を達成することができるように比較的低い計算リソース要件を有するべきである。更に、かかるシステムは典型的には、広範なネットワークトポロジにわたり様々な異なる装置間で高い接続可能性を達成するように、及び通信装置に対するストリームの伝送に関して適当な制御を提供して所望の通信経験を達成することができるように、実施されるべきである。
第１のクライアントネットワークノード、第２のクライアントネットワークノード、及びサーバノードを含む、ネットワーク通信環境の一実施形態の説明図である。 複数のネットワークノード間の例示的な一組のネットワーク接続及びセッションを示す、図１のネットワーク通信環境の一実施形態の説明図である。 クライアントネットワークノードの一実施形態の説明図である。 発行及び購読データ共有モデルによる複数のネットワークノード間のデータ共有方法の一実施形態を示している。 ストリームトランスポートプロトコルレコードの一実施形態を示している。 Ethernetフレーム内にカプセル化されたストリームトランスポートプロトコルレコードの一実施形態を示している。 クライアントネットワークノード及びサーバネットワークノードがそれらネットワークノード間で確立されるそれぞれのセッションにおいて様々なチャネルで通信する図１のネットワーク通信環境の一実施形態を示している。 クライアントノードからのログインメッセージに応答する方法の一実施形態を示している。 アカウントサービスからのステーション定義の受信に応答する方法の一実施形態を示している。 互いに通信するようクライアントノードのプロビジョニングを行う方法の一実施形態を示している。 クライアントネットワークノード間のリンクをネゴシエートする方法の一実施形態を示している。 図１１の方法の一実施形態において複数のクライアントネットワークノード間で送信される一組の例示的なメッセージを含む例示的な対話図を示している。 トランスポートストリームを介して複数のクライアントネットワークノード間でセッションを確立する方法の一実施形態を示している。 図１３の方法の一実施形態において複数のクライアントネットワークノード間で送信される一組の例示的なメッセージを含む例示的な対話図を示している。 キープアライブ定義レコードの一実施形態を示している。 キープアライブアクノリッジメント定義レコードの一実施形態を示している。 アクノリッジメントメッセージのフローを制御する方法の一実施形態を示している。 本発明の一実施形態による複数のセッションパートナーノード間でのキープアライブメッセージの例示的な交換を示している。 本発明の一実施形態によるセッションパートナーノードからのパケットの例示的なフローを示している。 セッションパートナーノードからのパケットの受信にアクノリッジする方法の一実施形態を示している。 セッション中に信頼できるチャネルでパケットを送信する方法の一実施形態を示している。 本発明の一実施形態に従って送信側ノードによりパケットを送信し及び受信側ノードにより受信したパケットをアクノリッジする方法の一実施形態を示している。 セッション中に信頼できるチャネルでパケットを受信する方法の一実施形態を示している。 ネットワーク通信環境の一実施形態を示している。 クライアントネットワークノードの一実施形態を示している。
以下の説明では、同様の符号は同様の構成要素を識別するために使用される。更に、各図面は、一実施形態の主な特徴を図式的に示すことを意図したものである。同図面は、実際の実施形態のあらゆる特徴を示すこと、図示の各構成要素の相対的な寸法を示すこと、及び実物大で示すことを意図したものではない。
I．用語の定義
「通信者」とは、１つ又は２つ以上のネットワーク接続を介して他の人と通信し又はその他の対話を行う人のことであり、この場合、該通信又は対話は、仮想領域との関連で生じても生じなくても良い。「ユーザ」とは、説明を目的とした特定の全体像を画定する特定のネットワークノードを操作している通信者である。
「コンピュータ」とは、コンピュータ読み取り可能媒体上に一時的に又は永久的に格納されているコンピュータ読み取り可能命令に従ってデータ処理を行うあらゆる機械、装置、又は設備である。「コンピュータオペレーティングシステム」とは、タスクの実行並びに計算及びハードウェアリソースの共有を管理し調整するコンピュータシステムのソフトウェア構成要素である。「ソフトウェアアプリケーション」（ソフトウェア、アプリケーション、コンピュータソフトウェア、コンピュータアプリケーション、プログラム、及びコンピュータプログラムとも称す）とは、１つ又は２つ以上の特定のタスクを実行するためにコンピュータが翻訳し実行することができる一組の命令である。「コンピュータデータファイル」とは、ソフトウェアアプリケーションにより使用するデータを永続的に格納している情報ブロックである。
「データベース」とは、コンピュータにより検索することができる標準化された形式で提示される組織化されたレコードの収集体である。データベースは、単一のコンピュータ上の単一のコンピュータ読み取り可能データ記憶媒体上に格納することが可能であり、又は１つ若しくは２つ以上のコンピュータ上の複数のコンピュータ読み取り可能データ記憶媒体にわたって分散させることが可能である。
「データシンク」（本書では単に「シンク」と称す）とは、データを受信する装置（例えばコンピュータ）、装置の一部、又はソフトウェアである。
「データソース」（本書では単に「ソース」と称す）とは、データを送出する装置（例えばコンピュータ）、装置の一部、又はソフトウェアである。
「ネットワークノード」（「ノード」とも称す）とは、通信ネットワーク内の分岐合流点又は接続点である。例示的なネットワークノードとして、端末、コンピュータ、及びネットワークスイッチが挙げられる（但し、それらには限定されない）。「サーバ」ネットワークノードとは、情報又はサービスの要求に応答するネットワーク上のホストコンピュータである。「クライアントネットワークノード」とは、情報又はサービスをサーバに要求するネットワーク上のコンピュータである。用語「ローカルネットワークノード」とは、現在議論の主題となっているネットワークノードを指すものである。用語「リモートネットワークノード」とは、ネットワーク通信リンクによりローカルネットワークノードに接続されているネットワークノードを指すものである。
「ネットワークアドレス」とは、メッセージの出所又は宛先のプロトコル固有の符号化された表現であり、ネットワーク上のネットワークノードを一意に識別するために使用される。
「ソケット」とは、ネットワーク通信エンドポイントである。アプリケーションプログラムは典型的には、アプリケーションプログラムをホストしているオペレーティングシステムのネットワークサービスアプリケーションプログラミングインタフェイス（ＡＰＩ）をコールすることによりネットワークを介して通信を行うためにソケットを生成することができる。
「プロトコルポート」（又は単に「ポート」）とは、ネットワークノード内の通信エンドポイントとして働くアプリケーション固有の又はプロセス固有のソフトウェアコンストラクトである。トランスポートプロトコルは、１つのネットワークノード内の複数の異なるエンドポイントを識別するために、一意の数字を各ポートに割り当てる。
「ネットワーク接続」（又は単に「接続」）とは、２つのネットワークノード間のデータ通信経路である。所与のネットワークノードから見ると、「トランスポートストリーム」（又は単に「ストリーム」）は、該所与のネットワークノードと他のネットワークノードとの間の直接的な接続である。
「セッション」とは、２つのエンドポイントネットワークノード（本書では「セッションパートナー」と称す）間の論理的な接続であり、該セッションが確立されたときから該セッションが解体されるときまで２つのネットワークノード間でメッセージを交換するという状況を提供するものである。所与のネットワークノードから見ると、１セッションは１つのトランスポートストリームで伝送され、この場合、該トランスポートストリームは、セッションパートナーへアドレス指定することもしないことも可能である。例えば、トランスポートストリームは、セッションパートナーにセッションを橋渡しするプロキシサーバーへアドレス指定することが可能である。「ピア・ツー・ピア」（P2P）セッションとは、２つのネットワークノード間のセッションであり、その各ネットワークノードは、P2Pセッションを開始することができ、及び該P2Pセッション中にクライアント及びサーバとして働くものである。
「UUID（Universally Unique Identifier）」（GUID (Globally Unique Identifier)とも称す）は、コンピュータシステム内又はネットワーク（例えばインターネット）上のオブジェクトを一意に識別するために使用される数字である。UUIDは、集中型サービス又は管理権限を必要とすることなく生成される。UUIDは典型的には、16オクテット（128ビット）のオクテット列である。UUIDを生成するための特定の機構に依存して、UUIDは、他の如何なるUUIDとも異なること又は少なくとも他の如何なるUUIDとも異なる可能性が極めて高いことが保証される。「周知のUUID」とは、ネットワークを介して永続オブジェクトを高い信頼性で識別するために使用されるUUIDである。
同期会議とは、複数の通信者が同時に参加する通信を称するものである。同期会議は、インスタントメッセージング（例えば、テキストチャット）、オーディオ会議、ビデオ会議、アプリケーション共有、及びファイル共有技術を含む、全ての種類のネットワーク化されたコラボレーション技術を包含するものである。
「リアルタイムデータストリーム」とは、連続的な流れで構築され処理されるデータであり、遅延なく又は知覚不能な遅延を伴って受信されるよう設計されるものである。リアルタイムデータストリームは、ボイス、ビデオ、ユーザの動き、顔の表情、及びその他の物理的な現象のディジタル表現、並びに、高速送信、高速実行、又は高速送信及び高速実行の両方から恩恵を受け得るコンピューティング環境内のデータ（例えば、アバター移動命令、テキストチャット、リアルタイムデータフィード（例えば、センサデータ、マシン制御命令、トランザクションストリーム、及び株価情報フィード）、及びファイル転送を含む）を含むものである。
「仮想領域」（「領域」又は「場所」とも称す）とは、コンピュータにより管理される空間又はシーンを表現したものである。仮想領域は典型的には、１次元、２次元、又は３次元で表現したものであるが、実施形態によっては、仮想領域は、単一の点に対応するものとすることが可能である。多くの場合、仮想領域は、物理的な実世界の空間をシミュレートするよう設計される。例えば、従来のコンピュータモニタを使用して、コンピュータにより生成された３次元空間の２次元グラフィックとして、仮想領域を視覚化することが可能である。しかし、仮想領域は、スイッチングルールの実施に関連する視覚化を必要としない。仮想領域は典型的には、仮想領域スキーマのインスタンスを称し、ここで、該スキーマは、変数に関して仮想領域の構造及びコンテンツを定義し、該インスタンスは、特定のコンテキストから求められた値に関して仮想領域の構造及びコンテンツを定義するものである。
「仮想領域アプリケーション」（「仮想領域仕様」とも称す）とは、仮想環境の生成に使用される仮想領域の記述である。仮想領域アプリケーションは典型的には、仮想領域の１つ又は２つ以上のゾーンに関連付けれたジオメトリ、物理特性、及びリアルタイムスイッチングルールの定義を含む。
「仮想領域通信アプリケーション」とは、リアルタイムオーディオ通信（及び潜在的には他のリアルタイム通信（例えば、ビデオ、チャット、及びその他のリアルタイムデータストリーム））を仮想領域内の対話の視覚的表現と統合させるクライアント通信アプリケーションである。
「仮想環境」とは、少なくとも１つの仮想領域を含み、及び複数の通信者間のリアルタイム通信をサポートする、コンピュータにより管理される空間を表現したものである。
「ゾーン」とは、少なくとも１つのスイッチングルール又は統制ルールに関連付けられた仮想領域中の一領域である。「スイッチングルール」とは、１つ又は２つ以上の前提条件下にある１つ又は２つ以上のリアルタイムデータソース及び１つ又は２つ以上のリアルタイムデータシンクの接続又は切断を指定する指示である。スイッチングルールは、仮想領域に関連して通信する複数のネットワークノード間でのリアルタイムデータストリームのスイッチング（例えば、ルーティング、接続、及び切断）を制御する。統制ルールは、リソース（例えば、領域、領域中の一領域、又は該領域又は該一領域のコンテンツ）に対する通信者のアクセス、該アクセスの範囲、及び該アクセスの後続の結果（例えば、該アクセスに関する監査記録を記録しなければならないという要件）を制御する。「レンダリング可能ゾーン」とは、個々の視覚化に関連付けられるゾーンである。
仮想領域内の「位置」とは、仮想領域内の一点又は一面積又は一体積の場所を称するものである。一点は典型的には、仮想領域中の１つの小領域を画定する一組の１次元、２次元、又は３次元座標（例えば、x,y,z）により表される。一面積は典型的には、仮想領域中の閉じた２次元形状の境界を画定する３つ又は４つ以上の同一平面上の頂点の３次元座標により表される。一体積は典型的には、仮想領域中の３次元形状の閉じた境界を画定する４つ又は５つ以上の同一平面上にない複数の頂点の３次元座標により表される。
仮想領域に関して、「オブジェクト」（場合によっては「プロップ」とも称す）とは、仮想領域の幾何学的構造とは別個に便利に扱うことができる該仮想領域中のあらゆるタイプの離散的要素である。例示的なオブジェクトとして、ドア、入口、窓、ビュースクリーン、及びスピーカーフォンが挙げられる。オブジェクトは典型的には、仮想領域の属性及びプロパティとは別個の異なる属性又はプロパティを有する。「アバター」（本書では「スプライト」とも称す）とは、仮想領域中の通信者を表すオブジェクトである。
本書で用いる場合、用語「含む」とは、含むがそれに限定されないことを意味し、用語「含んでいる」とは、含んでいるがそれに限定されないことを意味している。用語「〜に基づき」とは、少なくとも部分的に基づくことを意味している。
II．序論
本書で説明する実施形態は、個々のネットワークノードで操作を行っている複数の通信者の間のリアルタイムネットワーク通信をサポートするストリームトランスポートプロトコルを提供するものである。該ストリームトランスポートプロトコルは、現在利用可能な広範なコンピューティング装置及びネットワーク接続を使用してリアルタイム通信性能を達成することができるように、比較的低い計算リソース要件を有するものである。
実施形態によっては、該ストリームトランスポートプロトコルは、クライアント通信セッションのリモート管理、オーディオエンジン及びグラフィックレンダリングエンジンのリモートコンフィギュレーション及び実行、並びにリモートでホストされているサーバアプリケーションから受信した命令（定義とも称す）に応じたデータストリームのスイッチングをサポートする。このようにして、ストリームトランスポートプロトコルは、アプリケーションの開発者が、リモートクライアントネットワークノード上の通信環境の提示を介して制御を維持することを可能にし、これにより、広範な異なるタイプの仮想領域の開発が促進され、及びかかる通信システムの導入を所望するユーザの数が増大する。
該ストリームトランスポートプロトコルは、接続・切断並びに伝送の効率が良いものである。実施形態によっては、該ストリームトランスポートプロトコルは、所与のトランスポートプロトコル（例えば、UDP、TCP、HTTP、及びPPP）を介したコネクション型の暗号化接続を提供する。該ストリームトランスポートプロトコルは更に、クライアントアプリケーションによる介在を必要とすることなく失敗した接続の再確立を自動的に試行する再接続機構をクライアントアプリケーションとトランスポート層との間に提供し、これにより、元来信頼性できない通信プロトコルの上に信頼性が追加される。
III．概説
図１は、例示的なネットワーク通信環境10の一実施形態を示しており、該ネットワーク通信環境10は、互いにネットワーク20により相互接続された、第１のクライアントネットワークノード12（クライアントノードA）、第２のクライアントネットワークノード14（クライアントノードB）、サーバノード16、及び随意選択的なプロキシノード18を含む。第１のクライアントネットワークノード12は、有形のコンピュータ読み取り可能メモリ22、プロセッサ24、及び入力／出力（I/O）ハードウェア26（ディスプレイを含む）を含む。プロセッサ24は、メモリ22に格納されている少なくとも１つの通信アプリケーション28を実行する。第２のクライアントネットワークノード14は典型的には、実質的に前記第1のクライアントネットワークノード12と全体的に同様に構成され、少なくとも１つの通信アプリケーション32を格納した有形のコンピュータ読み取り可能メモリ30、プロセッサ34、及び入力／出力（I/O）ハードウェア36（ディスプレイを含む）を有する。サーバノード16は典型的には、クライアントノード12,14間の１つ又は２つ以上の種類の通信（例えば、インスタントメッセージング（例えば、テキストチャット）、オーディオ会議、ビデオ会議、アプリケーション共有、及びファイル共有）をサポートする同期会議サーバノードである。
通信アプリケーション28,32及びサーバノード16は共に、一定のストリームトランスポートプロトコルに従ってネットワークノード12,14を操作している通信者間の通信を管理するためのプラットフォーム（本書では「プラットフォーム」と称す）を提供し、該ストリームトランスポートプロトコルは、クライアント通信セッションのリモート管理、ストリーム処理エンジンのリモートコンフィギュレーション及び実行、並びにサーバノード16によりホストされるサーバアプリケーション38により指定されるリアルタイムデータストリームのリモート制御によるスイッチングをサポートする。ネットワーク20は、ローカルエリアネットワーク（ＬＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、及びワイドエリアネットワーク（ＷＡＮ）（例えばインターネット）の何れを含むことも可能である。該ネットワーク20は典型的には、ネットワークノード間で広範な種類の異なるメディアタイプ（例えば、テキスト、ボイス、オーディオ、及びビデオ）の送信をサポートする多数の異なるコンピューティングプラットフォーム及び伝送設備を含む。
図２は、クライアントノード12,14とサーバノード16との間で確立することができる例示的な一組のセッションを示している。この例では、クライアントノード12,14の各々は、サーバノード16とそれぞれのサーバセッション40,42を確立する。該サーバセッション40,42の各々は、クライアントノード12,14のそれぞれとサーバノード16との間のそれぞれのネットワーク接続を介して確立される。更に、クライアントノード12,14の各々はまた、該クライアントノード12,14間のネットワーク接続を介してピア・ツー・ピア（P2P）セッション44を確立する。クライアントノード12,14はまた、クライアントノード12,14間の当初のP2Pセッションに失敗した場合に該P2Pセッションを再確立するためのフェイルオーバー接続として用いることが可能な１つ又は２つ以上の代替的な（又は予備の）接続46,48,50を確立し維持することが可能である。図示の実施形態では、代替的なネットワーク接続50はプロキシノード18を介して確立される。該プロキシノード18は、クライアントノード12,14間のメッセージ（セッションネゴシエーションメッセージを含む）を単純に中継するものである。
ネットワークノード12,14の各々は、１つ又は２つ以上のソースからなる一組のソース52,54をそれぞれ有し、及び１つ又は２つ以上のシンクからなる例示的な一組のシンク56,58をそれぞれ有する。各ソースは、特定のデータストリームコンテンツタイプのデータを送出する装置又はコンポーネントであり、各シンクは、特定のデータストリームコンテンツタイプのデータを受容する装置又はコンポーネントである。同じデータストリームコンテンツタイプのソース及びシンクを本書では「相補的」であると称する。例示的なソースとして、オーディオソース（例えば、マイク等のオーディオ捕捉装置）、ビデオソース（例えば、ビデオカメラ等のビデオ捕捉装置）、チャットソース（例えば、キーボード等のテキスト捕捉装置）、モーションデータソース（例えば、マウス等のポインティング装置）、及びその他のソース（例えば、ファイル共有ソース又は特別なリアルタイムデータストリームのソース）が挙げられる。例示的なシンクとして、オーディオシンク（例えば、スピーカ又はヘッドフォン等のオーディオ演奏装置）、ビデオシンク（例えば、ディスプレイモニタ等のビデオ表示装置）、チャットシンク（例えば、ディスプレイモニタ等のテキスト表示装置）、モーションデータシンク（例えば、ディスプレイモニタ等の運動描画装置）、及びその他のシンク（例えば、共有されたファイルを印刷するためのプリンタ、上述したものとは異なるリアルタイムデータストリームをレンダリングするための装置、又は分析もしくは特別な表示のためにリアルタイムストリームを処理するソフトウェア）が挙げられる。
各ソースは、アクティブ状態及び非アクティブ状態を有し、アクティブ状態では、データを送出するためにソースを利用することが可能であり、非アクティブ状態では、データを送出するためにソースを利用することができない。同様に、各シンクは、アクティブ状態及び非アクティブ状態を有し、アクティブ状態では、データを受容するためにシンクを利用することが可能であり、非アクティブ状態では、データを受容するためにシンクを利用することができない。ソース及びシンクの状態は典型的には、通信アプリケーション28,32により提供される制御を介して、クライアントノード12,14を操作している通信者により制御することが可能である。例えば、実施形態によっては、通信アプリケーション28,32は、クライアントノード12,14においてローカルマイク及びローカルスピーカ（例えば、ヘッドセット）の電源をオン／オフさせるためのユーザ制御を提供する。
以下で詳述するように、サーバセッション40,42において、サーバノード16は、クライアントノード12,14の各々へプロビジョニングメッセージ60,62を送り、該プロビジョニングメッセージ60,62は、サーバアプリケーション38で指定されたスイッチングルールに従って相補的なソース及びシンクのうちアクティブなものの間のそれぞれのデータストリームを相互接続するようにクライアントノード12,14を設定するものである。様々なクライアントノードにおいてソースとシンクとの間で接続が確立される態様をサーバアプリケーションの開発者が制御することを可能にすることにより、該プラットフォームは、通信者がネットワーク通信環境10において互いに通信を行い又は対話する際の該通信者の体験をアプリケーションの開発者が制御することを可能にする。このようにして、サーバアプリケーションの開発者は、通信者間の通信を特定の通信目的について又は特定の通信環境（例えば、仮想チャットルーム、仮想アートギャラリー、仮想コンサートホール、仮想ホール、仮想会議室、及び仮想クラブハウス）について最適化することが可能となる。
IV．ストリームトランスポート通信プロトコルを実施したシステム及び方法の実例
Ａ．序論
図３は、ストリームトランスポートサービス72及びその他のクライアントプロセス74を含むクライアントノード12,14の一方又は両方の一実施形態70を示しており、該ストリームトランスポートサービス72及びその他のクライアントプロセス74は共に、サーバノード16から受信した命令に従って通信環境をレンダリングするためのシンクライアント通信アプリケーションを構成する。該ストリームトランスポートサービス72及びその他のクライアントプロセス74は、オーディオ及びグラフィクスレンダリング構成を介してネットワーク機能とは異なるレベルで動作する。ストリームトランスポートサービス72は、クライアントネットワークノード70とその他のネットワークノードとの間のセッションを管理する。このプロセスで、ストリームトランスポートサービス72は典型的には、アプリケーション層のクライアントプロセス74にチャネル及びセッションをエクスポートするローカルAPIと、サーバネットワークノード16上で動作している通信サービスとサーバセッションで通信するための及びリモートAPIとを提供する。
実施形態によっては、クライアントノード12,14上の通信アプリケーション28,32は典型的には、通信者の対話の視覚化及び制御を行うための視覚的なインタフェイスを提供するそれぞれのグラフィカルユーザーインタフェイス（GUI）アプリケーションを含む。これらのGUIアプリケーションは、ローカルストリームトランスポートサービスAPIを介してサーバアプリケーション38と通信するよう構成される。実施形態によっては、該GUIアプリケーションは、ローカルAPIを実施するそれぞれのクライアントプロセス74へユーザ入力（例えば、マウス入力）を渡し及びそれらクライアントプロセス74から受信したグラフィカルデータ（例えば、画面共有データ等のチャットデータ及びグラフィカルコンテンツ）を描画するよう構成されたリモート制御端末アプリケーションである。ローカルAPI通信を実施するこれらのクライアントプロセス74は、適当なセッション及びチャネルでユーザ入力の定義を含むメッセージを公開するために、並びに適当なセッション及びチャネルでリモートネットワークノードから受信したデータを購読するために、ストリームトランスポートサービス72と通信する。更に、複数のクライアントプロセス74のうちの１つ又は２つ以上は、サーバネットワークノード16上の通信サービスから受信した命令によりリモートで設定されて、他のクライアントネットワークノードから受信した到来データを処理するためのデータ処理要素グラフを生成する（及びティアダウンする）。例えば、実施形態によっては、リアルタイムカーネルのリモート設定されるオーディオ処理サービスを含み、該サービスは、サーバネットワークノード16上の通信サービスから受信した定義に応じてオーディオ処理要素のグラフを生成しティアダウンする。リモート設定可能な処理要素を含むリアルタイムカーネルの一例に関する更なる詳細については、2009年12月4日出願の米国特許出願第12/630,973号で開示されている。
１セッション中に、データは、トランスポートプロトコルソケットを介して定義レコードとしてクライアントネットワークノード70とその他のネットワークノードとの間で共有される。シンクライアントアーキテクチャは、サーバセッションで受信した定義レコードを介してサーバノード16からコンフィギュレーション命令を受信する。シンクライアントアーキテクチャはまた、他のクライアントネットワークノードとのそれぞれのセッションでコンテンツ固有のチャネルで受信した定義レコードを介して、該他のクライアントネットワークノードからコンテンツを受信する。データは、公開／購読モデルに従って共有される。ストリームトランスポートサービス72は、クライアントネットワークノード70により必要とされるデータのみ購読する。購読するために、ストリームトランスポートサービス72は、他のネットワークノードと確立したセッションでチャネルをネゴシエートする。該チャネルは、特定のサーバアプリケーション38の周知のGUIDによりネゴシエートされる。定義レコードは、トランスポートプロトコルソケットの他端に購読者が存在する場合にのみ送信される。ストリームトランスポートサービス72により受信される定義レコードは、その到着時に、複数のクライアントプロセス74のうち購読を行っているものへ配信される。
図３に示すように、ストリームトランスポートサービス72は、トランスポートストリーム78上のセッション76を管理する。実施形態によっては、ストリームトランスポートプロトコルセッションとのからみでのトランスポートストリームは、一対の{IP,ポート}アドレス及びトランスポートGUIDによって定義され、これにより、該ストリームを生成するために使用されるトランスポートプロトコル（例えば、UDP）が定義される。セッション76は、ゼロ又は１つ以上の論理チャネルからなり、この場合、１チャネルは、特定のクライアントプロセス74（例えば、グラフィクスエンジン、オーディオマネージャ、及びストリームスイッチングマネージャ）に適した一連の定義レコードである。このため、単一ソケット上の同じトランスポートストリーム78が、複数の異なるチャネルに複数の定義レコードを伝送することができ、その各定義レコードは、複数のクライアントプロセス74のうちのゼロ、１つ、又は２つ以上によって購読することが可能である。図示の実施形態では、ストリームトランスポートサービス72は、２種類のチャネル、すなわち、ストリーミングメディアレコード86（例えば、オーディオパケット）を含むメディアチャネル80、及び定義レコード88を含む定義レコードチャネル82を管理する。メディアレコード86の例としてオーディオコーデック及びテキストが挙げられる。定義レコード88の例として、セッションメンテナンス定義（例えば、キープアライブ／アクノリッジメント定義レコード）、クライアントプロビジョニング定義（例えば、オーディオ処理要素等のグラフ処理要素の定義）、3Dレンダリング資産（例えば、テクスチャ及びメッシュ）の定義、及びRDS（例えば、アバターモーションチェックポイント）の定義が挙げられる。
定義レコード88及びメディアレコード86は、ストリームトランスポートプロトコルレコード内にカプセル化される。該ストリームトランスポートプロトコルレコードは、暗号化プロセス84によって暗号化され、パケット番号で順序づけされ、及びメッセージ完全性フィールドを含む。該ストリームトランスポートプロトコルレコードの順序づけは、レコードのソース又は目的とは無関係であり、順序が違うレコード又は損失したレコードを検出するために使用されるリンクレベルの機能である。ストリームトランスポートプロトコルレコードは、チャネルによって識別される。GUIDは、チャネル識別子として使用される。定義レコード88及びメディアレコード86は、ストリームトランスポートプロトコルレコードのカプセル化とは別個に、それぞれのチャネル固有の圧縮手段90,92を使用してチャネルレベルで圧縮することが可能である。各ストリームトランスポートプロトコルレコードは典型的には、１つ又は２つ以上の定義レコード88又は１つのメディアパケット96を含む。ストリームトランスポートプロトコルレコードは、トランスポートプロトコル（例えば、UDP、TCP、HTTP、及びPPP）に従ってフォーマットされたパケットのペイロードとして、トランスポートストリーム78を介して配信される。
図３に示す一実施形態では、ストリームトランスポートサービス72は、アプリケーション層91、トランスポート層93、ネットワーク層95、及びリンク層97を含む４層プロトコルスイートの１コンポーネントである。アプリケーション層91は、通信者をネットワークにインタフェイスするユーザレベルプロセスを含む。トランスポート層93は、ストリームトランスポートサービス72及びトランスポートプロトコル99（例えば、UDP（User Datagram Protocol））を含み、アプリケーション層91をネットワーク層95にインタフェイスする。ネットワーク層95は、１つ又は２つ以上のプロトコル（例えば、IP（Internet Protocol）、ICMP（Internet Control Message Protocol）、及びIGMP（Internet Group Management Protocol））に従ってネットワークを通るデータの動きを管理する。リンク層97は、ネットワークメディア（例えば、Ethernetケーブル等）との物理的なインタフェイスの詳細を管理し、典型的には、クライアントノード70のオペレーティングシステム及び物理的なネットワークのハードウェアコンポーネント（例えば、NIC（Network Interface Card））のデバイスドライバコンポーネントを含む。
Ｂ．公開及び購読データ共有モデル
実施形態によっては、データは、（典型的にはコネクションレス型の）公開／購読モデルに従って複数のネットワークノードにより共有される。かかる実施形態では、クライアントノード12,14は、それらが必要とするデータのみを購読する。サーバノード16は、クライアントノード12,14の各々によりどのチャネルが必要とされるかを、それらのソース及びシンクのそれぞれの状態（すなわち、アクティブ又は非アクティブ）に基づいて判定する。サーバアプリケーション38は、クライアントノード12,14の各々へ、如何なる情報ストリームが該クライアントにとって利用可能であるかを示す（各ストリームにGUIDハンドルをタグ付けする）それぞれの公開メッセージを送る。各クライアントノードで動作する複数のクライアントプロセス74の各々は、ゼロ又は１つ以上のチャネルを購読することが可能である。１つのチャネルを購読するクライアントプロセス74は、チャネルレコードの到着時にチャネル状態の変化及び該チャネルレコードの通知を受信するためにローカルストリームトランスポートサービス72に登録する。次いで各クライアントノードは、サーバアプリケーション38により指定される周知のチャネルGUIDを使用して他のクライアントノードからの所望のチャネルを購読する。特定のチャネルについてのサーバデータに対するあらゆる変更は、該チャネルを購読している全てのクライアントへ定義レコードとして送信されることになる。
図４は、クライアントネットワークノード12,14が公開及び購読データ共有モデルに従って互いにデータを共有する方法の一実施形態を示している。この方法では、ローカルクライアントネットワークノードは、該ローカルクライアントネットワークノードから公開することができるローカル公開チャネルの識別子をサーバネットワークノードから受信する（図４のブロック101）。これらの公開チャネルは、該ローカルクライアントネットワークノードから提供することができるコンテンツに対応するものである。該ローカルクライアントネットワークノードは、該ローカルクライアントネットワークノードから公開することができるローカル公開チャネルと、該ローカルクライアントネットワークノード上の１つ又は２つ以上のローカルソフトウェアエンティティに関連付けられたローカル購読チャネルとを識別するレジスタを格納する（図４のブロック103）。該ローカルクライアントネットワークノードは、リモートクライアントネットワークノードとピア・ツー・ピアセッションを確立する（図４のブロック105）。該ローカルクライアントネットワークノードは、該ピア・ツー・ピアセッションで、前記ローカル公開チャネル及び前記ローカル購読チャネルを公開する（図４のブロック107）。該ピア・ツー・ピアセッションで１つ又は２つ以上のリモート公開チャネルの公開を受信したことに応じて、該ローカルクライアントネットワークノードは、前記リモート公開チャネルのそれぞれに対応する前記ローカル購読チャネルの各々毎に、前記リモートクライアントネットワークノードへ購読要求を送信する（図４のブロック109）。前記ローカル購読チャネルのそれぞれに対応するコンテンツチャネルにおいてピア・ツー・ピアセッションでデータを受信したことに応じて、該ローカルクライアントネットワークノードは、前記対応するローカル購読チャネルに関連付けられた前記ローカルソフトウェアエンティティの各々に前記受信したデータを渡す（図４のブロック111）。前記セッションで前記ローカル公開チャネルのそれぞれを購読するための要求を受信したことに応じて、該ローカルクライアントネットワークノードは、前記それぞれのローカル公開チャネルに関連付けられたデータを前記リモートクライアントネットワークノードへ送信する（図４のブロック113）。
図３を再び参照すると、ストリームトランスポートサービス72は、ローカル公開及び購読エントリのレジスタ94（例えば、テーブル）を維持する。該リスト中の各エントリは、以下に示すものを含む。
・該エントリを生成したローカルクライアントプロセス74の識別子
・サーバ識別子
・チャネル識別子
・該エントリが公開エントリであるか購読エントリであるかの識別子
・（購読用の）１つ又は２つ以上の伝送パラメータ
公開及び購読エントリのレジスタ94は、
{ストリームトランスポートサービスID, GUID_NULL, セッションチャネルID, 購読,
信頼可能, 非圧縮}
により初期化される。
このようにして、（ストリームトランスポートサービスIDにより識別される）ストリームトランスポートサービス72は、あらゆるセッションチャネルに到着した全ての定義レコード88（公開及び購読定義レコードを含む）を購読する。GUID_NULLチャネルは決して公開されず、あらゆるサーバは、該GUID_NULLチャネルを、あらゆるトランスポートストリームにおいて周知のチャネルIDで購読されるべきものとみなす。
ストリームトランスポートサービス72はまた、ローカルリストに購読が遅れて登録される場合に使用するために、到着した全ての公開定義のレジスタ96を維持する。
{IDクライアント, IDサーバ, IDチャネル}
ここで、IDクライアントとは、特定のクライアントプロセス74の（おそらくNULLの）GUIDであり（該チャネルは該クライアントプロセス74を意図したものであり）、IDチャネルは、所与の１チャネルの周知のGUIDである。
ストリームトランスポートサービス72が別のステーションに対する接続のためのセッション定義を受信すると、該ストリームトランスポートサービス72は、ストリームを確立し、セッション定義を送信し、次いで定義レコードに格納されているローカル公開エントリの全てをセッションチャネルで送信する。公開定義がストリームトランスポートサービス72に到着すると、ストリームトランスポートサービス72は、該定義を公開定義テーブルに入力し、次いで公開レコード内の対応するチャネルIDを有するローカルリスト中の各購読エントリ毎に購読定義を前記セッションチャネルで送信する。購読定義が到着すると、ストリームトランスポートサービス72は、（公開側サーバアプリケーション38から送られてくる）定義アップデートの送信を、該定義についての定義レコードを含む所与の定義レコードチャネルで開始する。該定義レコードは、２つ以上のチャネルで送信することが可能である。
クライアントプロセス74がサーバとのチャネルに参加することを所望する場合には、該クライアントプロセス74は、何れかのサーバに対するトランスポートストリームが存在するか否かにかかわらず購読要求を定義する。サーバアプリケーション38がその後に公開した場合（すなわち、ストリームが確立された後）には、ローカルテーブルの変化がリモート公開定義テーブル96中の公開エントリの再送をトリガし、これは、トランスポートストリームの他端における潜在的な購読を自動的にトリガするものとなる。クライアントプロセス74が後に購読を行い、及び公開テーブル96中にエントリが存在する場合には、ストリームトランスポートサービス72は購読要求を自動的に送信する。このプロセスは、受信側が所望する場合にのみチャネルデータをトランスポートストリームを介して送信することを確実にする。
Ｃ．SODA定義レコード
実施形態によっては、ネットワークノードにより送信される定義レコードは、SODA（Sococo Definition Architecture）レコードである。各SODAレコードは、１つ又は２つ以上のSODA定義を含む。SODA定義の例として、セッションメンテナンス定義（例えば、キープアライブ／アクノリッジメント定義レコード）、クライアントプロビジョニング定義（例えば、オーディオ処理要素等のグラフ処理要素の定義）、3Dレンダリング資産（例えば、テクスチャ及びメッシュ）の定義、及びRDS（例えば、アバターモーションチェックポイント）の定義が挙げられる。
SODAレコードは、最初のGUID IDと１つ又は２つ以上のSODA定義とを有するネスト構造である。１つのSODA定義は、１つの定義タイプ、１つの定義長さ、及びゼロ又は１つ以上のフィールドを有する。該定義タイプは、周知のGUID（例えば、guidAsset 及び guidAudioMix）である。前記定義長さは、全てのフィールドを含めたSODA定義の全体的な大きさを示す。前記フィールドは、タイプ固有の一定のフィールドと、ネストされた複数のSODA定義との組み合わせである。すなわち、
SODAレコード：
ガイドID
SODA定義
…
SODA定義：
ガイド定義タイプ
長期間；
[フィールド]−定義タイプによって決まる
フィールド：
固定フィールド
又は SODA定義
であり、例えば、次の通りとなる。
Figure 2013524632
Ｄ．STRAWチャネル及びSTRAWパケット
様々なネットワークノード上で動作するストリームトランスポートサービスのインスタンスは、セッショントラフィックを論理的に細分したものである複数のチャネルを介して通信する。実施形態によっては、該チャネルは、STRAW（Sococo TRAnsport for WAN）チャネルにより実施され、その各チャネルは、チャネルIDによって識別され、及び、コンテンツID、圧縮ID、一組のフラグ、及び圧縮プリロードデータストリングとして定義される。これらの実施形態では、１チャネルは、２つのネットワークノード間でSODA又はメディアレコードを１セッションで伝送する論理的な構成である。１チャネルは、信頼可能、信頼不能、圧縮、又は非圧縮とすることが可能である。
チャネルのコンテンツは、コンテンツIDによって識別される。コンテンツIDは、周知のUUIDであり、及びアプリケーションの開発者が該アプリケーションを処理するためのサービスを書き込むことができるようにヘッダファイルに配置されデータベースで公開される。サーバノード16上の通信サービスは、メッセージのコンテンツタイプがチャネルのコンテンツIDと一致するように適当なチャネルでメッセージを送信する（例えば、チャットメッセージがチャットチャネルで送信され、及びRDSメッセージがRDSチャネルで送信される）よう構成される。サービスは、誤ったチャネルで送信されたメッセージを無視することになる。
あらゆるセッションのあらゆるチャネルは、異なるチャネルIDを有する。サービス（例えばクライアントプロセス74）は、コンテンツIDを使用してチャネルデータにバインドする。チャネル定義の他のフィールドの全ては、ストリームトランスポートサービス72がチャネルデータの送信及び優先順位付けに使用するためのものである。
フラグは、以下のものを含む。
信頼可能 全てのデータパケットを配信
キーフレームユーザ データパケットはキーフレームフラグを使用することが可能
圧縮 データパケットは完全な状態で処理されなければならない。
（例えば、ストリームとして細分されてはならない）
順序非依存 パケットは受信時の任意の順序で処理することが可能
サービスチャネルコンテンツタイプの例は、以下の通りである。
オーディオモノ フラグ{キーフレームユーザ}を有するオーディオコンテンツ
信頼可能フラグの欠如は、ストリームが信頼性をもって配信さ
れない（損失したパケットが再送されない）ことを示唆してい
る。順序非依存フラグの欠如は、ストリームデータを受信時の
順序通りに処理しなければならないことを示唆している。
圧縮フラグの欠如は、データがSTRAWにより圧縮されていない
（オーディオコーデックが既にデータを圧縮している）ことを
示唆している。
KVMMEDIA フラグ{信頼可能、キーフレームユーザ}を有する画面共有コン
テンツ。信頼可能フラグは、全てのパケットが受信されるまで 再送信されなければならないことを示唆している。順序非依存
フラグの欠如は、ストリームデータが受信時の順序通りに処理
されなければならないことを示唆している。圧縮フラグの欠如
は、データがSTRAWにより圧縮されていない（オーディオコー
デックが既にデータを圧縮している）ことを示唆している。
セッション フラグ{信頼可能}を有するセッションコンテンツ。このチャネ
ル上の全てのパケットはSodaレコードを含む；その全ては信頼
性をもって送信され順序通りに処理されなければならない。必
要に応じて圧縮フラグもまた存在することが可能である。
チャネルレコードは、同じヘッダ「チャネルID」を共有し並びにパケット連番及びMACフィールドを有する一連のSTRAWレコードで送信される。MAC計算は、一方向のみの所与のチャネルにおけるパケット順によって決まる。単一チャネルで送信されたSTRAWレコードの全ては、一組のコンフィギュレーションパラメータ（例えば、{クライアント、信頼可能、圧縮}）を共有する。単一チャネル上の複数のレコードは、以下に示すように１つの直列ストリームとして圧縮される。
Figure 2013524632
通常は信頼可能チャネルのみ圧縮することができる。実施形態によっては、各キーフレーム毎に圧縮が再開する圧縮プロセスを用いて信頼不能チャネルを圧縮することができる。信頼不能チャネルでパケットが損失した場合には、キーフレームに達するまで該チャネル上のレコードが棄却される（順序通りでないと解凍することができないため）。実施形態によっては、各クライアントネットワークノード上の圧縮ダイナミックリンクライブラリを使用して定義レコードが圧縮される。圧縮を改善するために、チャネル定義は、圧縮手段を介して実行することができるが送信することはできないプリロードデータを含むことが可能である。その目的は、共通のフレーズを用いて圧縮状態テーブルを準備することにある。該圧縮状態テーブルは、キーフレームが受信される度にリセットされ再構築される。
ストリームトランスポートサービス72は、それぞれのチャネル識別子を含むストリームトランスポートプロトコルレコード内にSODA定義をカプセル化する。該ストリームトランスポートサービス72は次いで、該ストリームトランスポートプロトコルレコードをトランスポートプロトコル99へ送って更なるカプセル化を行った後にその下方に位置するネットワーク層95及びリンク層97へ送信する。
図５は、ストリームトランスポートプロトコルレコード（本書ではSTRAWパケットと称す）の一実施形態100を示している。該STRAWパケット100はSTRAWレコード102で始まる。該STRAWレコード102は、128ビットのチャネルID（UUID）、16ビットのフラグフィールド、8ビットのバージョンフィールド、8ビットのキーフィールド、64ビットのクッキーフィールド、32ビットのMACフィールド、16ビットのパケット番号、8ビットの拡張子タイプフィールド、8ビットの拡張子長さフィールド、及び随意選択の拡張子プロトコルフィールドを有する。前記キーフィールドは、メッセージの暗号化に使用される暗号鍵を特定するものである（０は暗号化しないことを意味する）。前記パケット番号は、ゼロから始まり、ストリーム中の各パケットで増分する。パケット番号は、65535に達するとゼロに戻ってカウントをし続ける。パケット番号及びフラグは、「ビッグエンディアン」順である。STRAWレコード102に続くのが、SODAレコードを含むデータパケット104である。該フラグは、以下のものを含む。
TF_キーフレーム=1
TF_ネイキッド=2
TF_メディア=4
TF_圧縮=8
TF_セッションメンテナンス=16
TF_ローカルパケット=32
TF_第１=64
TF_プロキシ=128
TF_マルチ=256
TF_再送=512
TF_ウィンドウ遅延=1024
TF_フレーム開始=2048
各パケットは、必要に応じてフラグをセットする。あらゆるチャネルは、任意のパターンでセットされたフラグを有するパケットを含むことが可能である。全ての組み合わせが有効であるとは限らない。
キーフレームビットは、ストリームで送信された帯域外情報を示唆する。このフラグ
は、通常はメディアストリームで送信されるパラメータパケットにセットされる。この
フラグの意味は、完全に通信者サービス固有のものである。
ネイキッドフラグは、SODAレコードヘッダが存在しないであろうことを意味する。
メディアフラグは、STRAWレコードに続く全てのパケットバイトの解釈が通信者サー
ビス固有のものであることを意味する。
圧縮フラグは、コンテンツがチャネルサービスにより圧縮されていることを意味する
。このフラグの意味は、STRAWの定義の範囲外のものである。
セッションメンテナンスフラグは、パケットが、STRAWプロトコルを意図したもので
あり、信頼できるチャネル上であっても信頼できないものであり、冪等元であり、及び
パケット番号フィールドが解釈されないことになることを意味する。
ローカルパケットフラグは、パケットが、局所的に送出されたものであり、及び実際
には送信バッファ内にないことを意味する。このフラグは、「ループバック」式テスト
のためにセットされ、又は局所的に生成されたパケットを処理中のストリーム内に挿入
することを必要とするアプリケーションによりセットされる。
第１フラグは、待ち行列の先頭で送信すべくメッセージを待ち行列に入れるべきこと
を意味する内部的なSTRAWスタックフラグである。
プロキシフラグは、パケットがプロキシにより転送されたことを意味する。
マルチは、STRAWヘッダがマルチプロトコル拡張を含むべきことを意味する内部的なS
TRAWスタックフラグである。
再送フラグは、パケットが以前に送信されたものであり、そのコピーが複製されたこ
とを意味する。
ウィンドウ遅延フラグは、意味する。
フレーム開始フラグは、コンテンツが複数のパケットへと分割されており、そのパケ
ットがその一連のパケットのうちの最初のパケットであることを意味する。
MACフィールドは、MACフィールドに続くあらゆるもの（パケットの残り（例えば、soda定義又はメディア）を含む）について計算されたハッシュである。MACは、クイックチェック計算及び包括チェック計算を有する。クイックチェックは、UDPパケットがSTRAWパケットを含むことを検証するために、ルータ、リレー、プロトコルスニファ、又はトランスポート層により使用することが可能である。クイックチェックの一例が（上位ワードXOR下位ワード==チェック値）である。包括チェックの一例は、（XOR(パケットID、パケット番号、及び16ビットワードとしての拡張子フィールド)==上位ワード）である。
拡張子タイプバイトは、STRAWレコードの直後に続くものを判定する。拡張形式が０である場合には、プロトコル拡張は存在しない。拡張子タイプが１であり拡張子長さが６である場合には、プロトコル拡張は、16ビットのパケット第１フィールド、16ビットのパケット最終フィールド、及び16ビットのパケット長フィールドを有するマルチ構造である。マルチは、以下に示すように単一のUDPペイロード内に収まるものよりも長いパケットを定義する複数の逐次パケットをグループ化するために使用される。
Figure 2013524632
マルチパケットシーケンス内のパケットは、第１パケットから最終パケットまでの範囲内のパケット番号を有する。該シーケンスにより定められる総パケット長は、大きさ（バイト）によるパケット長である。該シーケンスを構成する全てのパケットは、同一のフィールド値を有するマルチ拡張子を有していなければならない。該シーケンス内の何れかのパケットが信頼できないチャネル上で損失した場合には、該シーケンス全体が棄却され、大きなパケットが落ちたものとみなされる。該シーケンス内の何れかのパケットが信頼できるチャネル上で損失した場合には、該損失したパケットを受信側で要求して再送させることが可能である。パケット長が16ビットであるため、マルチを用いて定義することができる最大パケット長は32767バイト（拡張子フィールドを有するSTRAWレコードフィールドを除く）である。
STRAWレコード102に続くのがデータパケット104である。該データパケット104の長さは、STRAWパケット100をネットワークを介して送信するのに使用されるトランスポートプロトコル（例えば、UDP）のペイロードサイズから決定される。データパケット104の長さは典型的には、各ネットワークノードのオペレーティングシステムにより提供されるトランスポートプロトコルネットワークAPIによってストリームトランスポートサービス72へ帯域外で送信される。該データパケットのフォーマットは、チャネルコンテンツIDに固有のものである。
図５に示すように、STRAWパケット100は、ネットワークを介して送信されるリンク層フレーム106のペイロードとして送信される。図示の実施形態では、リンク層フレーム106は、リンク層ヘッダ、ネットワーク層ヘッダ、及びトランスポート層ヘッダで始まり、リンク層トレーラで終わる。一般に、該トランスポートプロトコルパケット106は、あらゆるタイプのリンク層プロトコルに対応することが可能である。図６は、一実施形態を示したものであり、この場合、STRAWパケット100はEthernetフレーム108内にカプセル化されており、該Ethernetフレーム108は、Ethernetヘッダ、IPヘッダ、及びUDPヘッダで始まり、Ethernetトレーラで終わる。
Ｅ．セッション
１．序論
複数のネットワークノード間のセッションは、あらゆるタイプのシリアル通信プロトコルストリーム（例えば、UDP、TCP、HTTP、及びPPP）を介して確立することが可能である。実施形態によっては、１つのストリームは、２つのIPアドレス／ポート対及び１つのトランスポートGUIDにより定められる２つのネットワークノード間の双方向UDPソケットである。１つのストリームは、複数のチャネルの複数のセッションをサポートする。１つのセッションは論理的なノード間接続である。複数のセッションは、２つのノードについて複数のチャネルを伝送する。複数のセッションは、１つ又は２つ以上のプロキシノードを通過することが可能であり、及び複数のセッションを含むことが可能な複数のストリームを介して伝送される。
クライアントノード12,14及びサーバノード16は、それぞれの対をなすセッションを介して互いに通信し、この場合、クライアントノード12,14の各々は、それぞれのサーバセッション40,42をサーバノード16と確立し、及びクライアントノード12,14の他方とピア・ツー・ピア（P2P）セッション44を確立する。これらのセッション40-44は、STRAWレコード102の第１フィールド（すなわち、チャネルIDフィールド；図５参照）に含まれる識別子により識別される複数のチャネルへと論理的に分割される。該チャネルの一例として、ステーションチャネル及びコンテンツチャネルが挙げられる。セッションチャネルは、STRAWレコード102のチャネルIDフィールド内のセッション識別子の存在によって識別され、及びセッション管理タスクに関連するデータ（例えば、ストリーム状態メッセージ、Pingメッセージ、及びキープアライブメッセージ）を伝送するために指定される。ステーションチャネルは、STRAWレコード102のチャネルIDフィールド内のステーション識別子の存在によって識別され、及びネットワークアドレス解決タスクに関連するデータを伝送するために指定される。コンテンツチャネルは、STRAWレコード102のチャネルIDフィールド内のコンテンツ識別子の存在によって識別され、及びコンテンツデータ（例えば、オーディオデータ、チャットデータ、及び画面共有データ）を伝送するために指定される。
図７は、ネットワーク通信環境10の一実施形態を示しており、この場合、クライアント及びサーバネットワークノード12-16は、ネットワークノード12-16間で確立されたそれぞれのセッション40-44において様々なチャネルで通信する。図示の実施形態では、サーバノード16は、サーバセッション40,42においてそれぞれのサーバセッションチャネル110,112でクライアントノード12,14の各々と通信し、クライアントノード12,14は、ピア・ツー・ピアセッション44においてステーションチャネル114、セッションチャネル116、及びコンテンツチャネル118で互いに通信する。実施形態によっては、データは、既述の公開／購読モデルに従い、STRAWソケットを介して、定義レコードとしてのセッションにおいてそれぞれのノード間で共有される。クライアントノード12,14上で動作するストリームトランスポートサービス72のインスタンスは、該クライアントネットワークノードにより必要とされるデータのみ購読する。購読するために、ストリームトランスポートサービスのインスタンスは、サーバアプリケーション38のために定義された名前空間における周知のUUIDである特定のチャネルIDをネゴシエートすることにより、対象となるネットワークノードに対してSTRAWチャネルを生成する。
サーバノード16は、サーバアプリケーション38に従って通信を行うようクライアントノード12,14を設定するためのデータを維持する。サーバノード16が維持する類のデータとして、ステーション定義117、セッション定義119、チャネル定義121、及びコンテンツ定義123が挙げられる。
実施形態によっては、複数のクライアントネットワークノードの各々にそれぞれの一意のステーション識別子が割り当てられる。複数のクライアントネットワークノードの各々毎に、サーバネットワークノードはそれぞれのステーション定義を決定し、該ステーション定義は、それぞれのステーション識別子と１つ又は２つ以上のエントリとを含み、その各エントリは、それぞれのコネクションレス型トランスポートプロトコルアドレスと、クライアントネットワークノード上のプロトコルポートのそれぞれのプロトコルポート識別子とを含む。実施形態によっては、各ステーション定義117は、それぞれのネットワークノードを一意に識別する永続的ステーションIDと、それぞれのネットワークノードに関連付けられた一組のソースアドレス（例えば、{IPアドレス、ソケットポート、プロトコルID}エントリ）とを含む。実施形態によっては、サーバネットワークノードは、クライアントネットワークノードから受信した１つ又は２つ以上のメッセージの各々から、それぞれのネットワークアドレスと該クライアントネットワークノード上のプロトコルポートのそれぞれのプロトコルポート識別子とを抽出することにより、該クライアントネットワークノードのためのステーション定義内のエントリを決定する。
実施形態によっては、各セッション定義119は、それぞれのセッションを一意に識別するセッションID、それぞれのセッションを介して通信するよう設計された構成要素となるネットワークノードを識別する一対のステーションID、それぞれのセッションで使用されるべきトランスポートプロトコルを識別するトランスポートID、及びそれぞれのセッションで使用されるべき暗号化プロトコルを識別する暗号化IDを含む。実施形態によっては、前記暗号化IDは、以下のフィールドを有するSODA定義である一組の暗号鍵定義へと置換される。
・SOID soidStrawCipher；- 暗号鍵の周知のGUID（例えば、DES）
・SOID soidKeyPurpose ；- データtx、データrx、キーtx、キーrx
・SDData<unisigned char *> sdKeyData；- 暗号化に適した実際のキー
（例えば、DES 56ビット）
ステーションIDは一組のソースアドレス（例えば、{IPアドレス、ソケットポート}対）を含むステーション定義を解決するため、セッション定義はネットワークノード間の通信を試みるのに十分なものである。
実施形態によっては、複数のチャネル定義121のうちの１つ又は２つ以上は、それぞれの一意のコンテンツ識別子に関連付けられる。該コンテンツ識別子は、チャネルに割り当てられたそれぞれのデータストリームコンテンツタイプを識別するものである。これらの実施形態によっては、各チャネル定義121は、一意のチャネルID、周知のコンテンツID、圧縮ID、一組のフラグ、及び圧縮プリロードデータストリングを含む。各コンテンツ定義123は、定義タイプ、定義長さ、及び１つ又は２つ以上のフィールドを有するそれぞれのSODA定義である。これらの実施形態によっては、前記フラグの１つ又は２つ以上は、それぞれのチャネルにおけるデータのトランスポートを他の如何なるチャネルにおけるデータのトランスポートにもかかわらず制御するトランスポートパラメータ値に対応する。実施形態によっては、チャネル定義のうちの１つ又は２つ以上は、それぞれの信頼可能性トランスポートパラメータ値を含み、該信頼可能性トランスポートパラメータ値は、それぞれのチャネル上のデータが、損失したデータパケットを再送信する信頼できるトランスポートプロトコルによって伝送されるか又は損失したデータパケットを棄却する信頼できないトランスポートプロトコルによって伝送されるかを示すものである。実施形態によっては、チャネル定義のうちの１つ又は２つ以上は、それぞれの圧縮トランスポートパラメータ値を含み、該圧縮トランスポートパラメータ値は、それぞれのチャネル上のデータを完全な状態で処理することが必要とされるか否かを示すものである。実施形態によっては、チャネル定義のうちの１つ又は２つ以上は、それぞれの順序付けトランスポートパラメータ値を含み、該順序付けトランスポートパラメータ値は、それぞれのチャネル上のデータを順序通りに処理すべきか任意の順序で処理すべきかを示すものである。実施形態によっては、チャネル定義のうちの１つ又は２つ以上は、それぞれの圧縮識別子を含み、該圧縮識別子は、それぞれのチャネルにおいて伝送されたデータを圧縮するためのそれぞれの圧縮プロセスを指定するものである。
サーバノード16はまた、サーバアプリケーションに接続されているクライアントノードのカレントレジスタ127を含む大域状態情報125と、該クライアントノードのデータソース及びシンク並びに該ソース及びシンクのそれぞれの状態（すなわち、アクティブ又は非アクティブ）を識別するインタフェイスデータ129,131とを維持する。
サーバネットワークノードは、セッションパートナー間における現在アクティブな相補的なソース及びシンクの各対毎に普遍的に一意のチャネルIDを生成する。このため、現在利用可能なチャネルの各々は、クライアントネットワークノード間の現在の対話に対して一意であるそれぞれのチャネルIDによって識別され、該チャネルIDと共に送信されたメッセージは、真正なセッションパートナーからのものとして信頼することができる。例えば、ローカルマイクをオフにするための第１のセッションパートナーからのメッセージの受信に応じて、サーバノード16は、第２のセッションパートナーに対し、マイクオーディオチャネル処理グラフをティアダウンするよう指示し、及び、ローカルマイクを元に戻すための第１のセッションパートナーからのメッセージに応じて、サーバノード16は、新たな一意のチャネルIDを有する新たなオーディオチャネルを生成し、及び、該新たなオーディオチャネルを購読して該新たなオーディオチャネルでマイクデータを処理するための新たなマイクオーディオ処理グラフを生成するようよう第２のセッションパートナーに指示する。第２のセッションパートナーは、当初のマイクオーディオチャネル処理グラフをティアダウンするための指示の受信後に当初のオーディオチャネルで受信したあらゆるパケットを無視することになる。
サーバノード16は、それぞれのサーバセッションチャネル110,112を介して定義レコードを送信することにより、サーバアプリケーション38に従って通信を行うようクライアントノード12,14の各々を設定する。このプロセスで、サーバノード16は、GUIDハンドルが各々タグ付けされたクライアントノード12,14に対して利用可能となるチャネルを示す公開メッセージを送信する。クライアントノード12,14上で動作しているストリームトランスポートサービス72のインスタンスは、所望のデータストリームについての購読メッセージをサーバノード16へ送信する。購読したチャネルについてのプロビジョニングデータに対するあらゆる変更は、それらのチャネルを購読している全てのクライアントネットワークノードに対して定義レコードとして送信される。
各サーバセッションを介して、サーバネットワークノードは、コンテンツタイプにより制御メッセージを論理的に分割する異なるそれぞれのチャネルで異なるコンテンツタイプの制御メッセージを伝送する。該制御メッセージの各々は典型的には、サーバセッションに割り当てられた一意のサーバセッション識別子、並びに制御メッセージのコンテンツタイプを識別するそれぞれのコンテンツ識別子と共に送信される。実施形態によっては、サーバネットワークノードは、サーバアプリケーションに接続されているクライアントネットワークノードの各々に、その他のクライアントネットワークノードに割り当てられているそれぞれの一意のステーション識別子を送信する。かかる実施形態によっては、サーバネットワークノードはまた、プロキシサーバのステーション定義を、サーバアプリケーションに接続されているクライアントネットワークノードの各々に送信する。該プロキシサーバのステーション定義は典型的には、該プロキシサーバに割り当てられたそれぞれのステーション識別子と１つ又は２つ以上のエントリとを含み、その各エントリは、それぞれのネットワークアドレスと該プロキシサーバのプロトコルポートについてのそれぞれのプロトコルポート識別子とを含む。
サーバノード16からの定義レコードの受信に応じて、クライアントノード12,14上で動作しているストリームトランスポートサービス72のそれぞれのインスタンスは、チャネル定義113,115、ステーション定義120,122、セッション定義124,126、及びコンテンツ定義128,130を含むローカルに格納されたテーブルを更新させる。これらの定義は、到来するデータパケットを処理すべきか否かを判定するため、及びストリームトランスポートサービス72及びその他のクライアントプロセス74による消費のために到来するパケットを如何に逆多重化すべきかを判定するために、ストリームトランスポートサービス72のインスタンスにより使用される。
実施形態によっては、所与のクライアントネットワークノードは、前記サーバアプリケーションに接続されている前記その他のクライアントネットワークノードのうちの１つ又は２つ以上の各々毎のそれぞれのステーション定義をサーバネットワークノードから受信する。受信したセッション定義の各々毎にそれぞれのセッションを確立するプロセスにおいて、前記所与のクライアントネットワークノードは、前記セッション定義におけるステーション識別子に基づいて、それぞれのセッションパートナーのクライアントネットワークノードの前記ステーション定義における１つ又は２つ以上のエントリを決定し、その各エントリ毎に、それぞれのネットワークアドレス及びそれぞれのプロトコルポート識別子を介したそれぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続の確立を試行する。かかる実施形態によっては、該セッション定義の各々は、ネットワーク接続を確立するためにコネクションレス型トランスポートプロトコルに関連付けられたトランスポート識別子を含む。受信したセッション定義の各々毎にそれぞれのセッションを確立するプロセスにおいて、前記所与のクライアントネットワークノードは、それぞれのセッション定義におけるトランスポート識別子に関連付けられたコネクションレス型トランスポートプロトコルに従って、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続の確立を試行する。
実施形態によっては、受信したセッション定義の各々毎にそれぞれのセッションを確立するプロセスにおいて、前記所与のクライアントネットワークノードは、それぞれのセッションパートナーのクライアントネットワークノードと複数のネットワーク接続を生成し、該生成した複数のネットワーク接続のうちの選択された１つを介してそれぞれのセッションを確立し、及び該選択されたネットワーク接続を介してセッションが確立されている間、前記生成された複数のネットワーク接続のうちの未選択のネットワーク接続のうちの１つ又は２つ以上を存続させる。実施形態によっては、前記セッション定義のうちの１つ又は２つ以上は、それぞれのネットワーク接続についてそれぞれのセッションパートナーのクライアントネットワークノードとネゴシエートするために複数のそれぞれのアドレスに関連付けられる。かかる実施形態では、少なくとも１つのセッション定義の各々毎に、所与のクライアントネットワークノードは、該セッション定義に関連付けられている複数のそれぞれのアドレスの全てについて、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続の確立を試行することになる。前記所与のクライアントネットワークノードが前記その他のクライアントネットワークノードとの複数の同時のネットワーク接続を成功裏に確立した場合に、該所与のクライアントネットワークノードのセッションパートナーのクライアントネットワークノードの各々毎に、該所与のクライアントネットワークノードは、該セッションパートナーのクライアントネットワークノードとの前記複数のネットワーク接続のうちの１つを選択し、該選択したネットワーク接続を介して該セッションパートナーのクライアントネットワークノードとのそれぞれのセッションを確立する。実施形態によっては、前記所与のクライアントネットワークノードが前記その他のクライアントネットワークノードとの複数の同時のネットワーク接続を成功裏に確立した場合に、該所与のクライアントネットワークノードのセッションパートナーのクライアントネットワークノードの各々毎に、該所与のクライアントネットワークノードは、前記セッションパートナーとの前記複数の同時のネットワーク接続のうちの１つ又は２つ以上の未選択のネットワーク接続を、選択されたネットワーク接続を介して確立されたそれぞれのセッション中に存続させる。
実施形態によっては、所与のクライアントネットワークノードは、プロキシサーバネットワークノードのそれぞれのアドレスをサーバネットワークノードから受信する。かかる実施形態では、該所与のクライアントネットワークノードは、前記セッション定義に関連付けられた１つ又は２つ以上のそれぞれのアドレスの各々について、及び前記プロキシサーバのそれぞれのアドレスを介して、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続の確立を試行する。
実施形態によっては、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのセッションを確立するプロセスにおいて、所与のクライアントネットワークノードは、それぞれのセッションパートナーのクライアントネットワークノードに割り当てられたそれぞれのステーション識別子を含む１つ又は２つ以上のインバウンドメッセージの各々からそれぞれのソースネットワークアドレスを抽出する。該所与のクライアントネットワークノードはまた、それぞれのセッションパートナーのクライアントネットワークノードに割り当てられているステーション識別子により索引付けされているローカルで格納しているステーション定義を更新させて、該ローカルで格納されているステーション定義にまだ含まれていない各々の抽出されたソースネットワークアドレスが含まれるようにする。
実施形態によっては、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのセッションを確立するプロセスにおいて、所与のクライアントネットワークノードは、該所与のクライアントネットワークノードに割り当てられている一意のステーション識別子を含むアウトバウンドメッセージをそれぞれのセッションパートナーのクライアントネットワークノードへ送る。該アウトバウンドメッセージに応答するインバウンドメッセージであって、それぞれのセッションパートナーのクライアントネットワークノードに割り当てられている一意のステーション識別子を含むインバウンドメッセージを受信したことに応じて、前記所与のクライアントネットワークノードは、該インバウンドメッセージからそれぞれのソースネットワークアドレスを抽出して、それぞれのセッションパートナーのクライアントネットワークノードを該抽出されたソースネットワークアドレスにバインドする。実施形態によっては、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのセッションを確立するプロセスにおいて、所与のクライアントネットワークノードは、それぞれのセッションパートナーのクライアントネットワークノードがバインドされた前記ネットワークアドレスにアドレス指定されたトランスポートストリームを介して、該それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのセッションに割り当てられた一意のセッション識別子を含む別のアウトバウンドメッセージを送る。前記別のアウトバウンドメッセージに応じたインバウンドメッセージであって、それぞれのセッションに割り当てられた一意のセッション識別子を含むインバウンドメッセージを受信したことに応じて、前記所与のクライアントネットワークノードは、前記トランスポートストリームを、前記それぞれのセッションでデータを送信するのに有効なものとして指定する。前記生成された複数のネットワーク接続のうちの所与のネットワーク接続が失敗したことに応じて、前記所与のクライアントネットワークノードは典型的には、それぞれのセッションパートナーのクライアントネットワークノードとの前記所与のネットワーク接続の再生成を試行する。
実施形態によっては、所与のクライアントネットワークノードから公開することができるローカル公開チャネルの識別子を受信したことに応じて、所与のクライアントネットワークノードは、確立されたピア・ツー・ピア・セッションの各々で該ローカル公開チャネルを公開する。前記確立された複数のピア・ツー・ピア・セッションのうちの所与の１つにおいて複数の前記ローカル公開チャネルのうちの所与の１つを購読する要求を受信したことに応じて、前記所与のクライアントネットワークノードは、前記所与のローカル公開チャネルに関連付けられているデータをそれぞれのセッションパートナーのクライアントネットワークノードへ送る。前記所与のクライアントネットワークノードは、該所与のクライアントネットワークノード上の１つ又は２つ以上のローカルソフトウェアエンティティに関連付けられているローカル購読チャネルを決定する。前記確立された複数のピア・ツー・ピア・セッションのうちの所与の１つにおいて１つ又は２つ以上のリモート公開チャネルの公開を受信したことに応じて、該所与のクライアントネットワークノードは、前記リモート公開チャネルのそれぞれに対応するローカル購読チャネルの各々を購読する要求をそれぞれのセッションパートナーのクライアントネットワークノードへ送る。前記ローカル購読チャネルのそれぞれに対応する前記リモート公開チャネルのそれぞれにおいて所与のピア・ツー・ピア・セッションでデータを受信したことに応じて、前記所与のクライアントネットワークノードは、該受信したデータを、前記対応するローカル購読チャネルに関連付けられているローカルソフトウェアエンティティの各々に渡す。
実施形態によっては、所与のクライアントネットワークノードは、データストリームを、該データストリームのコンテンツタイプに従って、それぞれのチャネルにおいて所与のセッションでそれぞれのセッションパートナーのクライアントネットワークノードへ送信する。このプロセスにおいて、前記所与のクライアントネットワークノードは典型的には、前記データストリームの各々を、該データストリームのコンテンツタイプに対応する複数のコンテンツ識別子のそれぞれを含む複数のパケットにおいて複数の前記チャネルのそれぞれで送信する。信頼できるトランスポートプロトコルによるチャネルでデータが送信されることを示す信頼可能性トランスポート値により定義される所与のセッションにおいて複数のチャネルの各々毎に、前記所与のクライアントネットワークノードは、前記チャネルでデータパケットを送信し、及び、セッションパートナーのクライアントネットワークノードにより受信がアクノリッジされていない送信済みのデータパケットの個数が、該セッションパートナーのクライアントネットワークノードにより指定されたウィンドウしきい値を越えているとの判定に応じて、該送信済みパケットのそれぞれを前記チャネルで再送信する。信頼できるトランスポートプロトコルによるチャネルでデータが送信されることを示す信頼可能性トランスポート値により定義される所与のセッションにおいて前記チャネルの各々毎に、前記所与のクライアントネットワークノードは、前記チャネルで送信されるデータパケットを保持し、及び、送信済みのデータパケットのうちの対応するデータパケットが前記セッションパートナーのクライアントネットワークノードにより受信されたことのアクノリッジメントを受信したことに応じて、前記保持したデータパケットを解放する。
実施形態によっては、前記所与のクライアントネットワークノードは、送信ウィンドウサイズ番号及び受信ウィンドウサイズ番号を含むセッションメンテナンスメッセージをそれぞれのセッションパートナーのクライアントネットワークノードから受信する。前記所与のクライアントネットワークノードは、前記セッションパートナーのクライアントネットワークノードにより受信したことがアクノリッジされていない送信済みデータパケットが送信ウィンドウサイズ番号に達するまで、それぞれのセッションパートナーのクライアントネットワークノードへデータパケットを送信する。該所与のクライアントネットワークノードは、先行するセッションメンテナンスメッセージがセッションパートナーのクライアントネットワークノードに送られた後に少なくとも受信ウィンドウサイズ番号のデータパケットを該セッションパートナーのクライアントネットワークノードから受信したことに応答するそれぞれのセッションメンテナンスメッセージをそれぞれのセッションパートナーのクライアントネットワークノードへ送る。該所与のクライアントネットワークノードにより送られる該それぞれのセッションメンテナンスメッセージは典型的には、アクティブ状態にある複数のチャネルの各々毎に、該チャネルで受信されるパケットのそれぞれの最大パケットシーケンス番号の指示を含む。該所与のクライアントネットワークノードにより送られる該それぞれのセッションメンテナンスメッセージは典型的には、アクティブ状態にある複数のチャネルの各々毎に、該チャネルで受信されない損失パケットのそれぞれの識別を含む。
実施形態によっては、前記所与のクライアントネットワークノードは、第１時間パラメータ値及び第２時間パラメータ値を含むセッションメンテナンスメッセージを、前記それぞれのセッションパートナーのクライアントネットワークノードから受信する。前記所与のセッションがアクティブ状態にあるとの判定に応じて、前記所与のクライアントネットワークノードは、パケット受信アクノリッジメントセッションメンテナンスメッセージを、前記第１時間パラメータ値により設定された最大間隔でセッションパートナーのクライアントネットワークノードへ送信する。前記所与のセッションがアイドル状態にあるとの判定に応じて、前記所与のクライアントネットワークノードは、パケット受信アクノリッジメントセッションメンテナンスメッセージを、前記第２時間パラメータ値により設定された最大間隔でセッションパートナーのクライアントネットワークノードへ送信する。実施形態によっては、クライアントネットワークノードは、２つの連続するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノードへ前記所与のクライアントネットワークノードにより送信される前に少なくとも１つのデータパケットが該セッションパートナーのクライアントネットワークノードから受信されたとの判定に応じて、前記所与のセッションがアクティブ状態にあると判定する。かかる実施形態では、前記所与のクライアントネットワークノードは、２つの連続するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノードへ前記所与のクライアントネットワークノードにより送信される前に該セッションパートナーのクライアントネットワークノードからデータパケットを全く受信していないとの判定に応じて、前記所与のセッションがアイドル状態にあると判定する。
２．クライアントノードのプロビジョニング
本例示の実施形態では、１つのネットワークノード上で動作しているストリームトランスポートサービスインスタンスは、別のネットワークノードのステーション定義を用いてプロビジョニングが行われた後、その他のネットワークノードとのセッションの確立を試行する。実施形態によっては、該プロビジョニングプロセスは、ネットワークノードがプラットフォームに対して認証された際に開始される。ネットワークノードは、その認証後に、サーバノード16のステーション定義を受信する。該ネットワークノードは、サーバノードのステーション定義を使用して、サーバノード16とのサーバセッションチャネルを介したセッションを確立し、該サーバノード16が、サーバアプリケーション38に接続されている他のネットワークノードとの通信のために該ネットワークノードのプロビジョニングを行う。サーバノード16がサーバセッションチャネルを介してクライアントノードへ送る例示的なタイプの定義として、ステーション定義、セッション定義、公開及び購読定義、トランスポートレポート要求、プロキシノード定義、セッションをティアダウンすることをクライアントに指示するステーションダウンメッセージ、及びpingメッセージが挙げられる。
ネットワーク認証は典型的には、通信アプリケーション28,32がクライアントノード12,14上で起動される度に一回行われる。実施形態によっては、アカウントサービスを使用して、クライアントノード12,14を認証し及び通信者のためのリアルユーザ識別子（RUID）を確立する。該アカウントサービスは、サーバノード16又はそれとは別のサーバノード（例えば、専用のアカウントサーバノード）により提供することが可能である。該認証プロセスは、アカウントサービスに接続し、認証を行い、及びクライアントノード12,14をそれぞれ操作している通信者を識別する、通信アプリケーション28,32によって開始される。
図８は、アカウントサービスがクライアントノード12からのログインメッセージに応答する方法の一実施形態を示している。該ログインメッセージは典型的には、アカウントサービスに帯域外で（例えば、SOAP等のウェブサービス交換を介して）送信される。
図８の方法によれば、アカウントサービスは、クライアントノード12のソースアドレスを含むログインメッセージをクライアント通信アプリケーション28から受信する（図８のブロック140）。該ソースアドレスは典型的には、該ログインメッセージを含むパケットのヘッダに埋め込まれる。該ログインメッセージは典型的には、クライアントノード12に通信アプリケーション28がインストールされた際に該クライアントノード12に割り当てられたステーションIDを含む。ログインサービスとクライアント通信アプリケーション28,32との間の通信は典型的には、ウェブサービス交換（例えば、SOAP）を介した帯域外通信であり、又は別のセッションを介したものとなる。
該ログインメッセージに応じて、アカウントサービスは、クライアントネットワークノード12を認証する（図８のブロック142）。このプロセスで、アカウントサービスは、トークンを生成し、及びクライアントノード12が他のサーバ（例えば、サーバアプリケーション38をホストしているサーバノード16）に対するそれ自体の認証を行うように該クライアントノード12に前記トークンを提供する。実施形態によっては、アカウントサービスはまた、ランダムな128ビットのチャレンジャフレーズをクライアントネットワークノード12に提供する。該クライアントネットワークノード12は、通信者により提供されたパスワードの暗号化ダイジェストを使用して前記チャレンジャフレーズのハッシュを生成し、これを応答として返す。アカウントサーバはまた、該通信者のための以前に取得したダイジェストを使用して前記チャレンジャフレーズのハッシュを生成して、前記クライアントネットワークノード12からの応答が一致するか否かを確認する。これでネットワーク接続が認証され、通信者が秘密鍵の所有者として識別される。実施形態によっては、ログインプロセスの一部として、アカウントサービスが、暗号、目的、及び暗号鍵を含む一組の暗号鍵をセキュアな接続（例えば、SSL又は暗号化された帯域内リンク）を介してクライアントネットワークノード12へ送る。
クライアントネットワークノード12を認証した後、アカウントサービスは、クライアントノード12,14から受信したログインメッセージに関連付けられたソースアドレスを抽出し、該抽出したソースアドレスをクライアントネットワークノードのステーション定義に組み込む（図８のブロック144）。アカウントサービスは典型的には、該アカウントサービスをホストしているオペレーティングシステムのネットワークサービスAPIをコールする（例えば、Microsoft（登録商標）Windows（登録商標）オペレーティングシステムにより提供されるWinsock APIを介して提供されるネットワークサービスをコールする）ことにより、ログインメッセージに関連付けられたソースアドレスを抽出することができる。
アカウントサービスは、クライアントネットワークノード12、サーバノード16、及びプロキシノード18（存在する場合）のステーション定義を、クライアントネットワークノード12に送る（図８のブロック146）。上述したように、各ステーション定義は、関連付けられているネットワークノードを一意に識別する永続的なステーションIDと、それぞれのネットワークノードに関連付けられている一組をなす１つ又は２つ以上のアドレス（例えば、{IPアドレス、ソケットポート、プロトコルID}エントリ）とを含む。
アカウントサービスはまた、クライアントネットワークノード12とサーバネットワークノード16との間のセッションの定義を該クライアントネットワークノード12に送る（図８のブロック148）。該セッション定義は、それぞれのセッションを一意に識別するセッションID、クライアントノード12のステーションID、サーバノード16のステーションID、それぞれのセッションに使用されるべきトランスポートプロトコルを識別するトランスポートID、及びそれぞれのセッションに使用されるべき暗号化プロトコルを識別する暗号化IDを含む。実施形態によっては、暗号化IDは、一組の暗号定義に置換される。
図９は、クライアントノード12,14上で動作しているストリームトランスポートサービス72のインスタンスがアカウントサービスからのステーション定義の受信に応答する方法の一実施形態を示している。図９の方法によれば、ストリームトランスポートサービス72は、クライアントネットワークノード、サーバネットワークノード16、及びプロキシネットワークノード18のそれぞれのステーション定義を該クライアントネットワークノード上にローカルに格納する（図９のブロック150）。これらのステーション定義は典型的には、ステーション定義テーブル120に格納される（図７参照）。ストリームトランスポートサービス72は、前記セッション定義に基づいてサーバネットワークノード16とのセッションを確立する（図９のブロック152）。プロキシノード18が存在する場合には、ストリームトランスポートサービス72はまた、プロキシネットワークノードステーション定義に基づいて該プロキシネットワークノード18とのトランスポートストリームを確立する（図９のブロック154）。クライアントノード12が、サーバノード16とセッションを確立するプロセス、及びプロキシノード18とトランスポートストリームを確立するプロセスについて、以下で説明する。
クライアントノード12,14がサーバノード16とセッションを確立した後（図９のブロック152）、該サーバノード16は、サーバアプリケーション38で規定されたスイッチングルールに従って通信を行うようクライアントノード12,14のプロビジョニングを行う。このプロセスにおいて、サーバノード16は中央管理手段として働く。各クライアントノードは、他のクライアントノードと通信するよう明示的にプロビジョニングが行われ、及び明示的にプロビジョニングが行われていない未プロビジョニングネットワークノードとは通信しないことになる。未プロビジョニングネットワークノードが、サーバノード16を介した最初の認証なしでクライアントノードとの通信を試行した場合には、該クライアントノードは通信することができず、未プロビジョニングネットワークノードからの通信は無視されることになる。サーバノード16が、クライアントノード12と未プロビジョニングネットワークノードとの間のセッション定義を生成して、それら両方のノードにセッション定義とそれらノード間で利用することができるチャネルの定義とを提供するまで、クライアントノード12が未プロビジョニングネットワークノードと通信する方法はない。この方法において、クライアントノード及び未プロビジョニングネットワークノードは、互いを発見することはなく、また自立的に動作することはなく、サーバノード16が、クライアントノード間で可能となる通信を定義する。この方法は、ウィルスその他の攻撃の可能性を排除するものである。明示的に認証されておらずプロビジョニングされていないネットワークノードからの通信を各クライアントノードが無視するからである。
図１０は、互いに通信するようサーバアプリケーション38に接続されているクライアントノードのプロビジョニングをサーバノード16が行う方法の一実施形態を示している。
図１０の方法によれば、所与のクライアントネットワークノードは、サーバネットワークノード16によりホストされているサーバアプリケーション38であって、１つ又は２つ以上の他のクライアントネットワークノードが接続されているサーバアプリケーション38に接続し、この場合、該所与のクライアントネットワークノード及び該１つ又は２つ以上の他のクライアントネットワークノードの各々は、それぞれのデータストリームコンテンツタイプの１つ又は２つ以上のソース及びシンクを有している（図１０のブロック160）。クライアントノードがサーバノード16とセッションを確立するプロセスについては以下のセクションで説明する。
サーバノード16は、サーバネットワークノード16によりホストされているサーバアプリケーション38に接続されているクライアントネットワークノードの１つ又は２つ以上の対を決定し、この場合、その各対の構成要素となるクライアントネットワークノードは、それぞれのデータストリームコンテンツタイプの相補的なソース及びシンクの１つ又は２つ以上のアクティブな組を有する（図１０のブロック162）。このプロセスにおいて、サーバノード16は、該サーバノード16がクライアントノード12,14の各々毎に維持しているインタフェイスデータ129,131に対し、サーバアプリケーション38により許可されている各データストリームコンテンツタイプのシンクの相補的なアクティブなソースを検索して、少なくとも一組のアクティブな相補的なソース及びシンクを有するクライアントノード対を決定する。アクティブな組をなす相補的なソース及びシンクの例として、クライアントノード上のアクティブなマイク及び別のクライアントノード上のアクティブなスピーカ、１つのクライアントノードによるアクティブな画面の共有及び別のクライアントノードによるアクティブな画面の参照、並びに２つのクライアントノードにおけるそれぞれのアクティブなチャットウィンドウが挙げられる。
決定されたクライアントネットワークノードの各対毎に、サーバノード16は、該対の構成要素となるクライアントネットワークノードの各々に、該対の構成要素となるクライアントネットワークノード間のネットワーク接続を介したそれぞれのピア・ツー・ピア・セッションを定義するそれぞれのセッション定義を送信する（図１０のブロック164）。決定されたクライアントネットワークノードの各対毎に、サーバネットワークノードは典型的には、それぞれのセッション定義を生成し、該セッション定義は、（i）該対の構成要素となるクライアントネットワークノードに割り当てられているそれぞれのステーション識別子と、（ii）該対の構成要素となるクライアントネットワークノード間でネットワーク接続を確立するためのコネクションレス型トランスポートプロトコルに関連付けられているトランスポート識別子とを含む。決定されたクライアントネットワークノードの各対毎に、サーバネットワークノードはまた、典型的には、前記対の構成要素となるクライアントネットワークノード間のネットワーク接続で伝送されるデータを暗号化するための暗号化プロセスに関連付けられた暗号化識別子（または一組の暗号定義）を含むそれぞれのセッション定義を生成する。実施形態によっては、各セッション定義は、それぞれのセッションを一意に識別するセッションID、前記構成要素となるクライアントノードのうちの第１のクライアントノードのステーションID、前記構成要素となるクライアントノードのうちの第２のクライアントノードのステーションID、それぞれのセッションで前記構成要素となるクライアントノードにより使用されるべきトランスポートプロトコルを識別するトランスポートID、及びそれぞれのセッションで前記構成要素となるクライアントノードにより使用されるべき暗号化プロトコルを識別する暗号化IDを含む。実施形態によっては、前記暗号化IDは、一組の暗号定義に置換される。前記サーバノード16はまた、典型的には、前記構成要素となるクライアントネットワークノードの各々に、前記セッションで利用可能となるチャネルの定義を送信する。
前記所与のクライアントネットワークノードは、前記サーバネットワークノード16から、該所与のクライアントネットワークノードと他のクライアントネットワークノードの各々との間のそれぞれのセッション定義を受信し、ここで、該所与のクライアントネットワークノードは、該他のクライアントネットワークノードの１つ又は２つ以上のソース及びシンクのうちのアクティブなものと相補的な少なくとも１つのアクティブなソースまたはシンクを有するものである（図１０のブロック166）。
受信したセッション定義の各々毎に、該所与のクライアントネットワークノードは、該セッション定義に基づいて、該所与のクライアントネットワークノードとそれぞれの前記他のクライアントネットワークノードとの間のそれぞれのネットワーク接続を介してそれぞれのピア・ツー・ピア・セッションを確立する（図１０のブロック168）。２つのクライアントネットワークノードが互いにピア・ツー・ピア・セッションを確立するプロセスについて以下のセクションで説明する。
３．セッションの確立
最初に互いのデータ交換を所望するあらゆる２つのネットワークノードは、該ネットワークノードのステーション定義を参照する（及び随意選択的にトランスポートID及び暗号化ID（または代替的に一組の暗号定義）を含む）セッション定義を用いてプロビジョニングされる。各ネットワークノード上のストリームトランスポートサービス72は、前記セッション定義を使用して他のセッションパートナーネットワークノードのステーションIDを判定し、及びローカルで格納している該他のセッションパートナーネットワークノードのステーション定義を調べて、該他のネットワークノードとのそれぞれのネットワーク接続をネゴシエートするための１つ又は２つ以上のアドレスからなる一組のアドレスを見いだす。上述のように、セッション定義及びステーション定義の両方は、ネットワークノードにより予め帯域外で受信されたものである。
セッションパートナーのステーションIDに関連付けられた１つ又は２つ以上のアドレスを判定した後、各ローカルネットワークノード上のストリームトランスポートサービス72は、各アドレス（例えば、IP/ポート対）に、該ローカルネットワークノードのステーションチャネルで（すなわち、該ローカルネットワークノードのステーションIDをチャネルIDとして用いて）ストリーム状態メッセージを送信する。このセッションパートナーアドレスの各々に対するバースト送信は典型的には、指数関数的に増大するバックオフ遅延を伴って繰り返され、該バックオフ遅延は、例えば、50ミリ秒（ms）から開始し、3秒を越える値に達する（この時点では3秒毎にバーストが発生する）まで、各バースト後に1.5倍の割合で増大する。実施形態によっては、各ストリーム状態メッセージは、チャネル（例えば、ステーションチャネルまたはセッションチャネル）を識別するチャネルIDと、SODA IDフィールド及び損失パケットカウントフィールドを有するSODAレコードからなるペイロードとを有する、STRAWパケットである。
典型的には、セッションパートナーは、該セッションパートナーの一方または双方がストリーム状態メッセージを受信するまで、それぞれのストリーム状態メッセージを互いに同時に送信する。何れかのストリーム状態メッセージを（チャネルIDにより識別される）リモートネットワークノードから受信したとき、ローカルネットワークノードは、ストリーム状態メッセージから該リモートネットワークノードのアドレス（例えば、IP/ポートアドレス）を抽出する。実施形態によっては、ローカルネットワークノード上のストリームトランスポートサービス72が、該ローカルネットワークノード上で実行しているオペレーティングシステムのネットワーキングアプリケーションプログラミングインタフェイス（API）を介してサービスをコールすることにより、ストリーム状態メッセージに関連付けられているアドレスを抽出する。例えば、Windows（登録商標）オペレーティングシステムを実行しているネットワークノードでは、Winsock APIに含まれるサービスを介してアドレス抽出機能が提供される。ストリーム状態メッセージからリモートノードのアドレスを抽出した後、ローカルネットワークノードは、該ローカルネットワークノードのステーションチャネルで、該抽出されたアドレスにストリーム選択メッセージを送り返す。各ストリーム選択メッセージは、SODA IDフィールド及び全長フィールドを有するSODAレコードからなるペイロードを有するSTRAWパケットである。ローカルネットワークノードは、そのステーションIDを該STRAWパケットのチャネルIDとして使用することにより、そのステーションチャネルでストリーム選択メッセージを送信する。
ストリーム選択メッセージを何れかのリモートネットワークノードから受信すると、ローカルネットワークノードは、該受信したストリーム選択メッセージから抽出したネットワークアドレスに該リモートネットワークノードをバインドする。このプロセスで、該ローカルネットワークノード上のストリームトランスポートサービス72は、ローカルで格納している該リモートネットワークノードの定義にビットをセットすることにより、前記ストリーム選択メッセージから抽出したアドレスを現在のネットアドレス（net address current）にプロモートする。この現在のネットアドレスのビットをセットすることにより、リモートネットワークノードとのセッションを確立するためにローカルネットワークノードにより使用することが有効なものとして該アドレスがマークされる。この時点で、リモートネットワークノードのネットワークアドレスは解決されており、ローカルネットワークノードとリモートネットワークノードとの間でトランスポートストリームが確立されている。ストリーム状態メッセージを送信し及びリモートネットワークノードからのストリーム選択メッセージの受信を待機するプロセスは、現在のネットアドレスへ送信されたローカルネットワークノードからのメッセージをリモートネットワークノードが受信すること、並びに現在のネットアドレスからのリモートネットワークノードによるメッセージをローカルネットワークノードが受信することを確実にする。
図１１は、第１及び第２のネットワークノード（例えば、ネットワークノードA及びネットワークノードB）が互いにリンクをネゴシエートする方法の一実施形態を示している。図１２は、図１１の方法の例示的な実施形態においてネットワークノードAとネットワークノードBとの間で送信される一組の例示的なメッセージを含む相互作用図を示している。
図１０及び図１１を参照すると、他のネットワークノードとのセッションの定義を受信したことに応じて、各ネットワークノードは、該セッション定義内の他のネットワークノードのステーションIDを、ローカルに格納されているステーション定義テーブルへの索引として適用して、他のネットワークノードに関連付けられている全てのアドレスを判定する（図１１のブロック170）。各ネットワークノードは、それ自体のステーションIDチャネルで、ストリーム状態メッセージ（例えば、図１２のメッセージ172,176）を、他のネットワークノードに関連付けられているアドレスの各々へ送信する（図１１のブロック174）。
受信側ネットワークノードのステーションチャネルで他のネットワークノードからのストリーム状態メッセージ（例えば、図１２のメッセージ176,172）を受信したことに応じて、各ネットワークノードは、該ストリーム状態メッセージに関連付けられているソースアドレスを抽出し、及びそれ自体のステーションIDチャネルでストリーム選択メッセージ（例えば、図１２のメッセージ178,182）を前記抽出されたソースアドレスへ送信する（図１１のブロック180）。他のネットワークノードのステーションIDチャネルでストリーム選択メッセージ（例えば、図１２のメッセージ182,178）を受信したことに応じて、各ネットワークノードは、該ストリーム選択メッセージに関連付けられているソースアドレスを抽出し、該抽出したソースアドレスを他のネットワークノードにバインドする（図１１のブロック184）。
何れかのネットワークノードが特定のアドレスにバインドされると、ローカルネットワークノード上のストリームトランスポートサービス72が該リモートネットワークノードにセッションチャネルでPingメッセージの送信を開始する。各Pingメッセージは、SODA IDフィールド及びタイムスタンプフィールドを有するSODAレコードからなるペイロードを有するSTRAWパケットである。該ローカルネットワークノードは、該PingメッセージのチャネルIDをセッションIDに設定することにより、該Pingメッセージをセッションチャネルで送信する。リモートネットワークノードからのセッションチャネルでのPingメッセージがローカルネットワークノードにより受信されると、該ローカルネットワークノードと該リモートネットワークノードとの間でトランスポートストリームが確立される。ここで、該トランスポートストリームは、一対のアドレス（例えば、{IP,ポート}）及びトランスポートGUIDにより画定される。Pingメッセージの受信に応じて、ローカルネットワークノードは、ローカルで格納しているステーション定義テーブルにおけるリモートネットワークノードに関連付けられているビットを使用のために「有効」とマークする。何れかのリモートネットワークノードが「有効」とマークされると、ローカルネットワークノード上のストリームトランスポートサービス72は、該ローカルネットワークノードとリモートネットワークノードとの間で確立されている全てのトランスポートストリームを調べて、該トランスポートストリームのうちの最高優先順位または最高ランクのトランスポートストリームを、該リモートネットワークノードとのセッションを介してメッセージを送るために選択する。ローカルネットワークノード上のストリームトランスポートサービス72は、リモートネットワークノードの現在のネットアドレスへセッションチャネルでストリーム選択メッセージを送信することにより、前記選択されたトランスポートストリームを介してリモートネットワークノードとのセッションを確立する。
図１３は、第１及び第２のネットワークノード（例えば、ネットワークノードA及びネットワークノードB）がトランスポートストリームを介して互いにセッションを確立する方法の一実施形態を示している。図１４は、図１３の例示的な実施形態においてネットワークノードAとネットワークノードBとの間で送信される一組の例示的なメッセージを含む相互作用図を示している。
図１３及び図１４を参照すると、各ネットワークノードは、他のネットワークノードにバインドされたアドレスへセッションIDチャネルでPingメッセージ（図１４のメッセージ190,194）を送信する（図１３のブロック192）。前記他のネットワークノードにバインドされた前記アドレスからの前記セッションIDチャネルでのPingメッセージ（図１４のメッセージ194,190）の受信に応じて、各ネットワークノードは、前記他のネットワークノードにバインドされた前記アドレスへ前記セッションIDチャネルでストリーム選択メッセージ（図１４のメッセージ196,200）を送信する（図１３のブロック198）。前記他のネットワークノードにバインドされた前記アドレスからの前記セッションIDチャネルでのストリーム選択メッセージ（図１４のメッセージ200,196）の受信に応じて、各ネットワークノードは、該他のネットワークノードとのトランスポートストリームを使用のために「有効」とマークする（図１３のブロック202）。有効なトランスポートストリームが１つしか存在しない場合には（図１３のブロック204）、各ネットワークノードは、該有効なトランスポートストリームを介して前記他のネットワークノードとトランスポートストリームを確立する（図１３のブロック206）。有効なトランスポートストリームが複数存在する場合には（図１３のブロック204）、各ネットワークノードは、該複数の有効なトランスポートストリームのうちの１つを選択し、該選択したトランスポートストリームを介して前記他のネットワークノードとセッションを確立する（図１３のブロック208）。
実施形態によっては、所与のクライアントネットワークノードが、他のクライアントネットワークノードと複数の同時のネットワーク接続を成功裏に確立している場合に、そのセッションパートナーのクライアントネットワークノードの各々毎に、該所与のクライアントネットワークノードが、該セッションパートナーとの該複数の同時のネットワーク接続のうちの未選択のネットワーク接続のうちの１つ又は２つ以上を、選択されたネットワーク接続を介して確立されたセッションにわたって存続させる。実施形態によっては、ストリームトランスポートサービス72は、Pingをセッションパートナーへ定期的に（例えば、３秒毎に）送信することにより、それらのストリームを生かし続ける。応答側のPingが受信されない場合には、ストリームトランスポートサービス72は、セッションパートナーとのトランスポートストリームを確立するプロセスを繰り返すことが可能である（図１３及び図１４参照）。該プロセスに失敗した場合には、ストリームトランスポートサービス72は、ネットワークアドレス解決プロセス（例えば、図１１及び図１２参照）及びそれに続くトランスポートストリーム確立プロセス（例えば、図１３及び図１４参照）を繰り返すことが可能である。
実施形態によっては、トランスポートサービス72は、特定のソケットアドレス（すなわち、特定のIPアドレス及びプロトコルポート番号）にバインドされるが如何なる特定の宛先アドレスにもバインドされない単一のプロトコルソケット（例えば、UDPソケット）を生成する。このようにして、複数の宛先アドレスとトランスポートストリームを生成することが可能である。ソケットプロトコルポートがUDP/IPプロトコルポートである実施形態では、トランスポートサーバが、エンドポイントネットワークノードの宛先アドレス（すなわち、IPアドレス/プロトコルポート番号）を取得する「sendto()」API機能を使用して単一のプロトコルポートを介してデータを送信する。
ネットワーク層プロトコル（すなわち、IP）は、ソケットプロトコルポートでパケットを受信するための一組のバッファを管理するスレッドを維持する。該バッファのうちの１つにパケットが到来すると、該スレッドは、パケットをチェック（例えば、チェックサムを検証）し、該パケットが暗号化されている場合にはそれを復号し、該パケットが有効である（例えば、フラグ、チェックサム、及びMACが有効である）場合には、前記スレッドは、チャネルIDのトランスポートを操作するよう指定された１つ又は２つ以上のターゲットとなるトランスポートサービスを決定するために、チャネル定義テーブルに列挙されている（トランスポートIDにより識別される）全てのトランスポートサービスに対する該チャネルIDの突き合わせを試行する。ターゲットとなるトランスポートサービスが発見された場合には、該トランスポートサービスが、パケットのチャネルIDに対応するチャネルで該パケットが到着したことをストリームトランスポートサービス72に通知する。ストリームトランスポートサービス72は、該パケットのコンテンツIDを判定し、該コンテンツIDを購読している複数のクライアントプロセス74の各々にパケットペイロードを送信する。このプロセスで、ストリームトランスポートサービス72は、ペイロードを待ち行列にポストし、及び該待ち行列で待機しているスレッドに公開する。ターゲットとなるトランスポートサービスがチャネル定義テーブルで発見されない場合には、ストリームトランスポートサービス72は、セッション定義テーブル及びステーション定義テーブルのエントリに対する前記チャネルIDの突き合わせを試行する。一致するエントリが発見された場合には、ストリームトランスポートサービス72は、（例えば、ネットワークアドレス解決またはセッションメンテナンス処理のために）前記パケットを処理する。ターゲットとなるトランスポートサービスが、チャネル定義テーブル、セッション定義テーブル、及びステーション定義テーブルの何れでも発見されなかった場合には、前記パケットは棄却される。
複数のチャネルは、同一のソケットを介して他の複数のチャネルとは別個に送信される。１つのチャネルにおける如何なるパケットの損失も、他のチャネルの完全性に影響しない。以下で説明するように、ストリームトランスポートサービスは、チャネル毎のフロー制御機能を提供し、この場合、各チャネルは異なる優先順位を有することができる。
４．セッションの終結
所与のクライアントネットワークノード上の通信者が通信セッションを終了させるためのコマンドを入力した場合、ストリームトランスポートサービスはサーバノードへ終了メッセージを送信する。該終了メッセージの受信に応じて、サーバノードは、サーバアプリケーションに接続されている他のクライアントネットワークノードへ、それらの前記所与のクライアントネットワークノードとのセッションをティアダウンすることをストリームトランスポートサービス72のそれぞれのインスタンスに指示する定義レコードを送信する。それら定義レコードの受信に応じて、前記他のクライアントネットワークノードの各々は、前記所与のクライアントネットワークノードとのセッションと、該所与のクライアントネットワークノードとの通信のために生成されたチャネルに関連付けられている全てのオーディオ及び画面共有処理コンポーネントとをティアダウンする。
５．プロキシノード
実施形態によっては、ネットワークノード間のセッションは、サーバノード16により提供される１つ又は２つ以上のプロキシノード（「プロキシ中継局」とも呼ばれる）を含むネットワーク接続を介して確立される。プロキシノードは、それ自体のためのセッションをネゴシエートしない。あらゆるセッションネゴシエーションは、クライアントノードによりエンド・ツー・エンドで行われ、プロキシノードは単にそれらクライアント間のメッセージを中継するだけである。プロキシノードはセッション層のフロー制御に参加しないため、プロキシノードのトランスポートインプリメンテーションは、セッションの両方の参加者から連絡があるまで単にセッションメッセージを棄却する。Pingメッセージが交換されるまで何れのクライアントノードもトラフィックを送らないため、リンクを介したネットワークトラフィックは殆ど存在しない。
サーバノード16は、各クライアントノードが何らかの経路を介して所望の各クライアントノードとP2P通信を行うことができるように、様々なプロトコル及び優先順位のステーション定義を用いてクライアントノードのプロビジョニングを行う。１つ又は２つ以上のプロキシノードが利用可能である場合には、サーバノード16は、プロキシノードのためのセッション定義及びステーション定義をクライアントノード12,14へ送り、この場合、各プロキシノードのステーション定義は、プロキシステーションID、トランスポート変数ID、及び暗号化変数IDを含む。利用可能なプロキシが２つ以上存在する場合には、エリアサービスは、現在の負荷にとって最善のプロキシを選択し、及び各プロキシがそのトラフィックを経路指定すべき場所を決定し、該トラフィックは１つ又は２つ以上の他のプロキシステーションを介して中継することが可能である。実施形態によっては、エリアサービスは、最小トラフィックメッシュに基づいてネットワークにおけるボトルネックの最小化を試行するネットワークトラフィック平衡化プロセスを実行することにより、各セッション毎にそれぞれの経路を選択する。
クライアントノードとプロキシノードとの間のトランスポートストリームは、クライアントノードが他の何れかのノードとトランスポートストリームを確立する場合と同様に、ストリーム状態メッセージを使用して確立される。プロキシノードトランスポートインプリメンテーションは、それ自体のステーションアドレスを使用してクライアントノードリンクについてネゴシエートする。プロキシノードは、該プロキシノードと接触するあらゆるクライアントステーションについてメッセージを受信し転送することが可能であり（プロミスキャスリレー）、または該プロキシノードにとって未知のステーションチャネル上のストリーム状態メッセージを無視することが可能である（プロビジョンドリレー）。許可されたクライアントノードのためのステーション定義のプロビジョニングは、帯域外で行われる。リンクが生じると（すなわち、何らかのネットワークアドレスからのストリーム選択メッセージをクライアントノードがプロキシステーションチャネルで受容すると）、該クライアントノードはそのネットワークアドレスにプロキシノードをバインドする。
該アドレスにプロキシノードがバインドされた後、該クライアントノードは、トランスポートストリームをアクティブに保つために３秒間隔で該プロキシノードにストリーム状態メッセージを送信する。セッションチャネルでプロキシノードからのPingが受信されると、該プロキシノードが使用のために有効とマークされる。何れかのプロキシノードが有効とマークされると、全てのプロキシノードの優先順位が検査されて、後続のセッションメッセージを送信するのに最善な１つが選択される。該選択されたプロキシノードにストリーム選択メッセージがセッションチャネルで送信される。この選択は、該セッションの寿命にわたり、ネットワークの接続性が変化して異なる優先順位のプロキシノードが利用可能となり又は利用不能となる度に多数回変更し得るものである。
これら実施形態において、サーバノード16は、２つのクライアントノード間のセッションのためのプロキシを、プロキシノードのプロキシステーションID及び該セッションに割り当てられるセッションIDを含む帯域外プロキシセッションメッセージを使用してプロビジョニングする。プロキシノードのプロビジョニングが行われると、サーバノード16は、該プロキシノードのプロキシステーションIDをその考え得るリレーステーションのリストに含めるようセッション定義を修正する。
実施形態によっては、プロキシノードは、サーバノード16によってサーバデータベース内のトランシーバテーブルからプロビジョニングされる。アクティブなプロキシノードのリストがサーバ起動時に読み込まれ、トランシーバテーブルに対する変更の結果として、サーバノード16に対する通知イベントが生じ、該サーバノード16がアクティブなプロキシノードの追加又は削除を行うことが可能となる。
サーバノード16とプロキシノードとの間のセッションはサーバノード16により開始される。サーバノード16は、サーバノードステーションID及び一意のセッションIDを含むトランシーバセッション開始メッセージをプロキシノードへ最初に送信する。接続が失われて再確立された場合には、セッションIDが変化し、旧いセッション及びチャネルバインディングを除去するためのクリーンナップ段階がプロキシノード上でトリガされることになる。プロキシノードは、トランシーバセッション開始メッセージを受信すると、上述したようにストリーム状態メッセージで応答する。ストリーム状態メッセージの受信を受信することにより、サーバノード16は、該プロキシノードをアクティブにして、該プロキシノードを、該サーバノードのプロキシ選択ヒューリスティックにより決定されるように、クライアント／サーバ及びピア・ツー・ピアセッションのために使用し始める。
プロキシノードがアクティブにされると、選択された各セッション毎に以前に確立されたセッション／チャネルバインディングが該プロキシノードに通知される。プロキシノードには、セッション及び２つのエンドポイントクライアントノードを定義するためのStrawセッションメッセージが送信される。セッションについての公開された各チャネル毎に、セッションIDに対してチャネルIDをマップするチャネルバインドメッセージがプロキシノードに送られる。新たなセッションが確立されてプロキシノードが選択されると、該選択されたプロキシノードに該新たなセッションが通知されると同時にクライアントノードに該セッションが通知される。新たなチャネルが被プロキシセッションで公開される際に、チャネルバインドメッセージが送信されると同時に該チャネルが公開される。被プロキシセッションが終了すると、該セッションに関与していた各クライアントノード毎にステーションID及びセッションIDを提供する２つのトランシーバセッション停止メッセージがプロキシノードに通知される。サーバノード16がプロキシノードからの切断を必要とする場合には、該サーバノード16は、該サーバノード16のステーションID及びサーバ／プロキシセッションIDと共にトランシーバセッション停止メッセージを送信する。これにより、プロキシノードは、該セッションで以前に提供された全てのセッションマッピングを削除することになる。
６．セッションメンテナンス
ａ．セッションプロトコルパケット
STRAWパケット中のセッションメンテナンスフラグがセットされる場合、該パケットは、STRAWセッションプロトコルパケットであり、これは信頼できないものであり、これは冪等元であり、パケット番号フィールドは解釈されないことになる。STRAWセッションプロトコルパケットの一例として、キープアライブ及びアクノリッジメント（ACK）が挙げられる。
ｉ．キープアライブセッションプロトコル
キープアライブセッションは通常のSTRAWレコードで始まり、該STRAWレコードは、セッションIDに等しいチャネルIDを有し、セッションメンテナンスフラグがセットされ、ゼロ拡張子タイプ及び長さ、並びにそれに継ぐSODA IDを有する単一のSODA定義データパケットを有する（guidSodaSESSION_KeepAliveAck）。セッションメンテナンスがフラグフィールドにセットされている場合には、NAKEDフラグフィールドがセットされている（すなわち、SODAレコードヘッダが全く存在しないことになる）ものと想定される。
図１５を参照すると、STRAWレコードに続くパケットはSODA定義210であり、該SODA定義210は、通常の128ビットのSODA IDと値30を有する16ビットの長さとを有し、続いて32ビットの符号なしアクティブタイムアウトフィールド、32ビットの符号なしアイドルタイムアウトフィールド、16ビットの符号なし送信ウィンドウサイズフィールド、及び16ビットの符号なし受信ウィンドウサイズフィールドを有する。アクティブタイムアウト値は、送信されたSTRAWパケット（STRAWプロトコルパケットを含まない）に応じて受信側ステーションにより送信されるべきACK間で生じるミリ秒の最大数を指定するものである。アイドルタイムアウト値は、ステーションにより送信されたACKを最後に受信してからSTRAWプロトコルパケット以外のSTRAWパケットが送信されていない場合に受信側ステーションにより送信されるべきキープアライブメッセージ間で生じるミリ秒の最大数を指定するものである。送信ウィンドウサイズ値は、受信側ステーションがACKを送信するのを待つ前に該ステーションにより送信されるべき最大パケット数を指定するものである。受信ウィンドウサイズ値は、受信側ステーションにACKを送信する前に該ステーションにより受信されるべき最小パケット数を指定するものである。この値は一般に送信ウィンドウサイズよりも小さくなると思われる。かかる場合には、一連の送信済みパケットに対してアクノリッジメントが行われた後、送信側がフロー制御（送信停止）をトリガし、プロトコルで時間を浪費することなく１セッションの全帯域幅を満たすことが可能である。
ｉｉ．ACKセッションプロトコル
ACKプロトコルパケットは、キープアライブパケットとして始まるが、30よりも大きいSODA長さ値を有する。SodaSESSION_KeepAliveAck SODA定義に続くのが、一組のSDSESSION_ChannelAck SODA定義であり、これは、セッションについて定義されるアクティブな信頼できる各チャネル毎に１つずつ存在する。
図１６を参照すると、各SodaSESSION_KeepAliveAck SODA定義212は、値（guidSodaSESSION_ChannelAck）を有する通常の128ビットのSODA IDで始まり、これに値36又はそれ以上の値を有するSODA長さフィールドが続く。これに、128ビットのチャネルID、16ビットの最大パケット番号フィールド、及びゼロ又は１つ以上の損失パケット番号フィールドが続く。損失パケット番号フィールドの個数は、36を上回ったSODA長さ値を２で除算することにより求められる。例えば、SODA長さ値が40である場合には、（40-36）/2=2個の損失パケット番号フィールドが存在する。
ｂ．フロー制御
STRAWセッションパケットフローは、キープアライブ／ACKパケットにより制御される。それらは、セッションチャネルで送信される冪等元の信頼できないメンテナンスメッセージであり、ACKインターバル時間、パケットウィンドウサイズ、及びチャネルアクノリッジメントを含む。それらは、１セッションの複数のチャネルの全てのパケットフローを追跡することの全責務を負うものである。
キープアライブメッセージは決してフロー制御されない。キープアライブメッセージは優先順位メッセージとして待ち行列（の先頭）に入れられ、それが落ちた場合に定期的に再送される。キープアライブメッセージは、インバウンドフローに応じて送信され、パケットが流れている場合にはより高頻度に、最後のインターバルからパケットが発生していない場合にはより低頻度に送信される。
これらのメッセージはエンド・ツー・エンドで渡される。このため、プロキシを介した送信は該メッセージを変更しない。
STRAWは、あらゆるシリアルチャネル（例えば、UDP、TCP、HTTP、更にはPPP）を介して送信することが可能である。キープアライブメッセージは、如何なるチャネルであっても使用されます。
i．ACKインターバル時間
各セッションのキープアライブメッセージで送られる２つのインターバル（cMsActive及びcMsIdle）が存在する。これらは、キープアライブメッセージ間の最大インターバルを制御する。１パケットの受信時に１セッションがアクティブになり、複数のキープアライブメッセージが少なくともcMsActiveの頻度で送られる。キープアライブを送ったパケットと次のパケットとの間でパケットが全く受信されなかった場合には、該セッションはアイドル状態になり、それ以降のキープアライブメッセージは少なくともcMsIdleの頻度で送られる。このアイドルインターバル中にパケットが受信された場合には、該セッションがアクティブ状態を再開する。
通常は、これらのインターバルは、メッセージ間で変更されることはないが、キープアライブが受信される度に、該インターバルは新たな値として解釈されるべきである。
両方のインターバルがゼロとなる特殊な場合が存在する。これは、キープアライブメッセージを「繰り返しの要求」とマークするものである。ステーションは、その指定されたインターバル（それが送るインターバル）が満了したがキープアライブがパートナーステーションから受信されていない場合にこのメッセージを送信する。繰り返しを受信するステーションは、全ての購読されているチャネルについてアクノリッジメントと共にキープアライブを直ちに送ることが予想される。ステーションは、幾つかのインターバルを試行することが可能であり、幾つかのackインターバルについて何も受信されない場合には、セッションが失われたものとみなすことが可能である。
繰り返しはまた、フロー制御がチャネルを長期間シャットダウンした場合に送ることができる。これは、キープアライブが落ちた場合に生じ得るものであり（それらが信頼できないものであることを想起されたい）、該落ちたキープアライブは、後続のキープアライブには存在しないチャネルアクノリッジメントを含むものである。
図１７は、アクノリッジメントメッセージのフローの制御でストリームトランスポートサービス72の一実施形態により実施される方法の一実施形態を示している。
図１７の方法によれば、セッションがアクティブである場合（図１７のブロック214）、ストリームトランスポートサービス72は、少なくともセッションパートナーノードから受信した最後のキープアライブ値で指定されているmsActiveパラメータ値の頻度でキープアライブメッセージを送る（図１７のブロック216）。パケットが受信されると（図１７のブロック218）、該セッションがアクティブ状態にあり（図１７のブロック220）、ストリームトランスポートサービス72が、少なくとも、前記セッションパートナーノードから受信した最後のキープアライブ値で指定されているmsActiveパラメータ値の頻度で、キープアライブメッセージを送る（図１７のブロック216）。パケットが受信されない場合には（図１７のブロック218）、ストリームトランスポートサービス72は、２つの連続するキープアライブメッセージが送信される前にセッションパートナーノードからパケットが受信されたか否かを判定する（図１７のブロック222）。最後のパケットがセッションパートナーノードからのものであるため、２つの連続するキープアライブメッセージが送信されていない場合には（図１７のブロック222）、トランスポートサービス72は、パケットが受信されるのを待機する（図１７のブロック218）。
最後のパケットがセッションパートナーノードからのものであるため、２つの連続するキープアライブメッセージが送信されていない場合には（図１７のブロック222）、ストリームトランスポートサービス72は、該セッションをアイドル状態にセットする（図１７のブロック224）。該セッションがアイドル状態になると（図１７のブロック224）、ストリームトランスポートサービス72は、少なくとも、セッションパートナーノードから受信した最後のキープアライブ値で指定されているmsIdleの頻度で、キープアライブメッセージを送る（図１７のブロック226）。パケットが受信された場合には（図１７のブロック228）、該セッションがアクティブ状態になり（図１７のブロック220）、ストリームトランスポートサービス72が、少なくとも、セッションパートナーノードから受信した最後のキープアライブ値で指定されているmsActiveパラメータ値の頻度で、キープアライブメッセージを送る（図１７のブロック216）。
ii.ウィンドウサイズ
各セッションのキープアライブメッセージで送られる２つのウィンドウサイズ（sSendWindow及びsRcvWindow）が存在する。これらは、一対ではなく、２つの異なるストリームのフローを制御する。送信ウィンドウは、アクノリッジされていないインバウンドパケットを制限する。受信ウィンドウは、アクノリッジされていないアウトバウンドパケットを制限する。
２つのパートナーP1,P2が互いにそれぞれのウィンドウサイズ（P1.send, P1.rcv, P2.send, P2.rcvと称す）を送信している場合を想定する。P1から見ると、２つのストリームSOut及びSInが存在する。
ストリームP1.SOutは、P2.send及びP1.rcvにより制御される。セッションパートナーノードP1は、ストリームを遮断する前に、アクノリッジされていないパケットをP2.sendに送ることになる。P2は、最後にアクノリッジした後にP1.rcvパケットを受信した場合にストリームにアクノリッジすることになる。通常、P1.rcvは、P2.sendから計算され、それよりも一層小さなものとなる。P1.rcvは、P2.sendの１／２に設定することが可能であり、P1がしばらくの間ストリームを遮断する必要がなかった場合に少し大きく調節し、P1がストリームをブロックしなければならなくなる度に少し小さく調節することが可能である。これは、P2アクノリッジメントの個数及び頻度を妥当なレベルに制御し、ネットワークが許す程度に高速にストリームの流れを高速に保つ。
ストリームP1.SIｎは、P1.send及びP2.rcvによって制御される。セッションパートナーノードP2は、ストリームを遮断する前に、アクノリッジされていないパケットをP1.send送ることになる。P1は、最後にアクノリッジした後にP2.rcvパケットを受信した場合にストリームにアクノリッジすることになる。通常、P1.sendは、公称値（10程度）に設定され、スキップしたパケット番号（混雑に起因して欠落したパケット）が生じている場合には一段階小さく調節される。ストリームトランスポートサービスで再送信が生じていない場合には、P1.sendを徐々に大きく調節することが可能である。
図１８Ａ−１８Ｃは、セッションパートナーノードP1,P2間のパケットの流れを制御するためにストリームトランスポートサービス72の一実施形態により実施される方法の一実施形態を示している。
図１８Ａは、セッションパートナーノードP1,P2間におけるキープアライブメッセージの交換を示しており、この場合、セッションパートナーノードP1により送信されるキープアライブメッセージは、ウィンドウサイズP1.send及びP1.rcvを含み、セッションパートナーノードP2により送信されるキープアライブメッセージは、ウィンドウサイズP2.send及びP2.rcvを含む。
図１８Ｂは、セッションパートナーノードP1からのパケットの流れを示している。セッションパートナーノードP1により送信されるパケットの流れは、ウィンドウサイズP2.send及びP1.rcvにより制御される。図示の実施形態では、ウィンドウサイズP2.sendは、８パケットとなるようにセッションパートナーP2により設定される。このため、セッションパートナーノードP1は、ストリームを遮断する前に、アクノリッジされていない８パケットを送信することになる。パケット1についてのアクノリッジメントがセッションパートナーノードP2から受信されると、セッションパートナーノードP1がパケット9を送信することができるようにP2.sendウィンドウがスライドする。
図１８Ｃは、セッションパートナーノードP1上で動作しているストリームトランスポートサービス72がセッションパートナーノードP2からのパケットの受信にアクノリッジするための方法の一実施形態を示している。この方法によれば、セッションパートナーノードP1により最後のアクノリッジメントメッセージが送信された後にセッションパートナーノードP2からP2.rcvパケットが受信された場合に（図１８Ｃのブロック230）、セッションパートナーノードP1がアクノリッジメントメッセージをセッションパートナーノードP2に送信する。それ以外の場合には、最後のアクノリッジメントメッセージがセッションパートナーノードP1により送信された後にセッションパートナーノードP2からP2.rcvパケットが受信されるまでセッションパートナーノードP1は待機する（図１８Ｃのブロック230）。
７．チャネルプロトコル
i．信頼できないチャネルプロトコル
信頼できないものとして定義された（チャネル定義中に信頼可能ビットを有さない）チャネルを介して送信されたパケットは、二度と再送信されない。それらのSTRAWレコードヘッダは、信頼できるチャネルを介して送信されたパケットと同じであり、STRAWは、増分していくパケット番号値及び計算されたMAC値を等しく含む全てのヘッダフィールドを計算する。しかし、到来するパケットが、不正なMAC値を有する場合、又は次に予想されるパケット番号値をスキップしている場合には、そのSTRAWは、そのチャネルを購読しているローカルサービスにパケットが損失したことを報告する。適切に応答する（例えば、それら自体のアプリケーション層シグナリングを使用し又は損失したオーディオ値を隠蔽すべくオーディオデータのフィルタリングにより損失データを合成する）のが該サービスの責務である。
ii．信頼できるチャネルプロトコル
信頼できるものとして定義された（チャネル定義中に信頼可能ビットを有する）チャネルを介して送信されたパケットは、アクノリッジされるまで再送信される。信頼可能性は、STRAWレコードパケット番号フィールドと受信したACKセッションプロトコルパケットとの組み合わせを介して達成される。
実施形態によっては、ストリームトランスポートサービス72は、次のようにしてパケットを信頼可能性をもって送信する。ストリームトランスポートサービス72は、アクノリッジされていない送信済みパケットの数が送信ウィンドウサイズを越えるまで、待ち行列に入っているパケットを送信する。送信済みパケットは、アクノリッジされるまでストリームトランスポートサービス72によって保持される。受信したACKは、該ACKが、パケットのチャネルに一致するチャネルID、及びパケットのパケット番号と一致し又はそれを上回る最大パケット番号値を有するSodaSESSION_KeepAliveAckレコードを含む場合に、番号付けされたパケットを受信したことをアクノリッジするものであり、該パケットのパケット番号は、如何なる損失パケット番号値で表されるものでもない。アクノリッジが完了すると、該送信済みパケットの出所であるストリームトランスポートサービスは解放される。
ストリームトランスポートサービス72は、損失パケット番号フィールドにパケット番号をリストアップしたSodaSESSION_KeepAliveAckメッセージを受信した場合、又は送信済みパケットのパケット番号を下回る最大パケット番号値を有する２つのACKを当該チャネルについて受信した場合に、アクノリッジされていないパケットを再送する。
ストリームトランスポートサービス72は、アクノリッジされていないパケットを引き止めておく（例えば、アクティブタイムアウト値×２ms以内にチャネルACKを受信しない）場合に、アクティブタイムアウト値「０」及びアイドルタイムアウト値「０」を有する特殊な早期Keepaliveを送信することが可能である。このメッセージは「繰り返し要求」と呼ばれる。これは、パートナーステーションがアクティブ状態にあるかアイドル状態にあるかを全てのチャネルに直ちにアクノリッジしなければならないことを該パートナーステーションに指示するものである。この特殊な全チャネルACKは「繰り返しメッセージ」と呼ばれる。
Reiterate（繰り返し）は、損失したACKパケットから回復する。ACKパケットは冪等元であり、送信側及び受信側は該Reiterateの受信後に同期することになる。STRAWは、ACKメッセージが受信されるまでアクティブタイムアウトインターバルで繰り返し要求を送信し、又はその忍耐の限界を超えてセッションが終了される（バインドしない）。
図１９は、ストリームトランスポートサービス72が所与のセッションパートナーノードと所与の１セッションにおいて信頼できるチャネルでパケットを送信する一実施形態を示している。
図１９の方法によれば、ストリームトランスポートサービス72は、信頼できるチャネルでパケットを送信する（図１９のブロック240）。ストリームトランスポートサービス72は、送信したパケットのコピーを保持する（図１９のブロック242）。
ACKが受信されなかった場合には（図１９のブロック244）、ストリームトランスポートサービス72は、アクノリッジされていないパケットの数が送信ウィンドウサイズパラメータ値を越えるまでパケットを送信し続ける（図１９のブロック246）。アクノリッジされていないパケットの数が送信ウィンドウサイズパラメータ値を越えた場合には（図１９のブロック246）、ストリームトランスポートサービス72は、最後のACKを受信してからの時間がストール期間（例えば、アクティブタイムアウト値×２ms）よりも大きいか否かを判定する（図１９のブロック248）。最後のACKを受信してからの時間がストール期間よりも大きい場合には（図１９のブロック248）、ストリームトランスポートサービス72は、繰り返し要求をセッションパートナーノードに送信する（図１９のブロック250）。該繰り返し要求に応じてセッションパートナーノードから繰り返しメッセージが受信された場合には（図１９のブロック252）、ストリームトランスポートサービス72は、アクノリッジされていないパケットを再送信して（図１９のブロック254）信頼できるチャネルでのパケットの送信を続行し（図１９のブロック240）、それ以外の場合には、ストリームトランスポートサービス72はセッションを終了させる（図１９のブロック256）。最後のACKを受信してからの時間がストール期間以下である場合には（図１９のブロック248）、ストリームトランスポートサービス72は、アクノリッジされていないパケットを再送信して（図１９のブロック254）信頼できるチャネルでのパケットの送信を続行する（図１９のブロック240）。
ACKが受信された場合には（図１９のブロック244）、ストリームトランスポートサービス72は、保持しているパケットのうちアクノリッジされたものを、セッションパートナーノードによる受信が完了しているため解放する（図１９のブロック258）。ACKで識別された損失パケットが存在する場合には（図１９のブロック260）、ストリームトランスポートサービス72は、該識別された損失パケットを再送信する（図１９のブロック262）。
実施形態によっては、送信側及び受信側ネットワークノード上で動作しているストリームトランスポートサービス72は、送信側ネットワークノードによるパケットの再送信を最適化するために、STRAWレコード102（図５参照）のクッキーフィールドを使用する。かかる実施形態では、送信側ネットワークノードは、STRAWレコードのクッキーフィールドで一意のセッションレベルクッキー値を送信する。該送信側ネットワークノードは、所与のデータ構造（例えば、テーブル168）で該クッキー値の順序づけされたリストを格納する。受信側ネットワークノードは、各アクノリッジメントパケット（ACK）と共に、該ACKパケットと共に送信されるSTRAWレコードのクッキーフィールドで、受信側ネットワークノードにより処理された最後のパケットのクッキー値を送信する。上述した複数の実施形態の場合のように、各ACKパケットはまた、最大受信パケット番号の値及び損失したパケットのパケット番号を、該ACKパケットで送信されるACK SODA定義の最大パケット番号フィールド及び損失パケット番号フィールド内に含む（図１６参照）。ACKパケットを受信した際に、送信側ネットワークノードは、受信側ネットワークノードにより処理された最後のパケットのクッキー値を抽出する。送信側ネットワークノードは、図１９に示す方法のブロック246でこの情報を使用する。詳細には、送信側ネットワークノードは、該抽出されたクッキー値の後に送信されたクッキー値を有するパケットを、アクノリッジされていないパケットの数に含めない（図１９のブロック246参照）。このようにして、送信側ネットワークノードは、受信側ネットワークノードにより受信されたが該受信されたパケットの処理における不可避のレイテンシの結果として処理が完了していない該パケットの再送信を回避する。
前記クッキー値は、１セッション中のパケットを一意に識別する任意のタイプのデータ（例えば、タイムスタンプ値又は反復しないカウンタ値）とすることが可能である。上記で説明したように、パケット番号は、それぞれのチャネルでパケットに割り当てられる一意の一連の反復する番号である。ACK処理は（全てのチャネルについて）セッションレベルで生じるため、前記クッキーは、チャネルレベルのパケット番号のみでは提供されない追加情報を提供する。これは、クッキーがパケットストリーム全体内のマーカーである一方、パケット番号が各チャネルのパケットストリーム内のマーカーであるからである。
図２０は、上記段落で説明した実施形態に従って送信側ノード264によりパケットを送信し及び受信側ノード266により受信したパケットのアクノリッジメントを行う方法の一実施形態を示している。この例では、送信側ネットワークノード264は、それぞれの一意のクッキー値C106,C107,C108を有する一連のパケットをその送信待ち行列（TX Queue）から受信側ネットワークノード266へと送信する。該受信側ネットワークノード266は、送信されたパケットをその受信待ち行列（RX Queue）内に受信し、該RX Queueで該パケットの処理を開始する。クッキー値C108を有するパケットの処理後、受信側ネットワークノード266は、送信側ネットワークノードから受信したパケットから抽出された最高の受信パケット番号値（PNM,最大パケット番号）及びクッキー値C108を含むACKパケット267を送信側ネットワークノードに送信する。該ACKパケット267を受信する前に、送信側ネットワークノードは、それぞれの一意のクッキー値C109,C110を有する一連のパケットを、その送信待ち行列（TX Queue）から受信側ネットワークノード266へ送信する。送信側ネットワークノードがACKパケット267を受信すると、該送信側ネットワークノードは、上述したように最高の受信パケット番号値に基づいてリソースを解放する。送信側ネットワークノードはまた、テーブル中のクッキー値を参照して、受信側ネットワークノードにより処理された最後のパケットを判定する。送信側ネットワークノードは、クッキー値C108の後に送信されたクッキー値を有するパケットを、アクノリッジされていないパケットの数に含めない（図１９のブロック246参照）。
受信側ネットワークノードが、アクノリッジされていないパケットを損失し、且つそれが一連のパケット中の最後のパケットであった場合、受信側ネットワークノードは、セッションをアイドル状態にマークすることが可能であり、送信側ネットワークノードは、数秒間にわたり受信側ネットワークノードからの他のACKを確認しないことが可能である。しかし、このシナリオは、パケットの損失に通ずるものではない。詳細には、図１９の方法によれば、送信側ネットワークノードは、アクティブ状態にセットされたセッションを現在有しているがストール期間よりも長くACKを受信していない場合（図１９のブロック248参照）、送信側ネットワークノードは、繰り返しメッセージを発行して（図１９のブロック250）、受信側ネットワークノードに直ちに完全なACKを送信させる。送信側ネットワークノードは、該繰り返しメッセージに応じて送信された該ACKにおけるクッキー値を現在値として扱い、それが受信側ネットワークノードに送信された最後のパケットを網羅していない場合には、該送信側ネットワークノードは、かかる送信された最後のパケットを損失したパケットとマークしてそれらパケットを再送信する（図１９のブロック254）。
実施形態によっては、ストリームトランスポートサービス72は、次のようにしてパケットを信頼性をもって受信する。ストリームトランスポートサービス72は、無プロトコルパケットの受信時に最後に受信したアクティブタイムアウト値についてセッションACKタイマを開始させる（該タイマがまだ開始されていない場合）。該タイマが満了すると、ストリームトランスポートサービス72は、アクティブな（最後のACK後にパケットを受信した）全てのチャネルについてSodaSESSION_KeepAliveAckレコードを含むACKを送信する。次いで、該タイマが開始されてから何れかのパケットが受信された場合には、該タイマがアクティブタイムアウト値にリセットされ、それ以外の場合にはアイドルタイムアウト値にセットされる。ストリームトランスポートサービス72は、パケットが順序違いで受信された際にACKを送信する。ストリームトランスポートサービス72は、受信ウィンドウサイズに達した際、すなわち、受信したパケット番号が受信ウィンドウサイズによる最後のアクノリッジ済みのパケット番号よりも大きい場合に、ACKを送信する。ストリームトランスポートサービス72は、セッションがバインドされた際にACKを送信する。ストリームトランスポートサービス72は、繰り返し要求が受信された際にACKを送信する。ACKが送信される場合には、全てのアクティブなチャネル（又はセッションが繰り返し要求を受信した場合には全てのチャネル）がSodaSESSION_KeepAliveAckレコードで表される。複製したメッセージ（そのチャネルで既にアクノリッジ済みのパケット番号を有するもの）が受信された場合には、ストリームトランスポートサービス72は、次のACKで繰り返すよう該セッションをマークする。
図２１は、ストリームトランスポートサービス72が所与のセッションパートナーノードと所与の１セッションにおいて信頼できるチャネルでパケットを受信する一実施形態を示している。
図２１の方法によれば、無プロトコルパケットの受信に応じて（図２１のブロック270）、ストリームトランスポートサービス72は、セッションパートナーノードから受信した最後のアクティブタイムアウト期間にセッションタイマをセットする（図２１のブロック272）。ストリームトランスポートサービス72は次いで、次のパケットが受信されるのを待機する（図２１のブロック274）。セッション時間が満了する前にパケットが受信されなかった場合（図２１のブロック276）、ストリームトランスポートサービス72は、全てのアクティブなチャネルについてACKを送信して（図２１のブロック278）、セッション時間をアイドルタイムアウト期間にセットする（図２１のブロック280）。セッション時間が満了する前にパケットが受信された場合には（図２１のブロック276）、ストリームトランスポートサービス72は、該受信したパケットが順序違いのものである場合（図２１のブロック282,284）、該受信したパケットによって受信ウィンドウサイズに達した場合（図２１のブロック286,288）、該受信したパケットが当該セッションにバインドする場合（図２１のブロック290,292）、又は該受信したパケットが繰り返し要求メッセージである場合（図２１のブロック294,296）に、ACKを送信する。
８．プロトコル拡張子
実施形態によっては、ストリームトランスポートプロトコルは、拡張子：シングルトン及びマルチを含む。ほぼ全てのパケットは、ゼロの拡張子タイプ及びゼロの拡張長さを有するシングルトンで送信される。これらのパケットは、受信時に直ちに処理される。マルチで送信されたパケットは、オーバーサイズレコード（UDPペイロードが許可するよりも大きなレコード）の送信を意図したものである。かかるパケットのデータペイロードは、単純にパケット番号順に加えられたものであり、一連のSTRAWパケットが全て受信された際に単一のデータパケットとして処理される。信頼できないチャネルでマルチを使用した場合には、該「マルチ」シーケンス中の１パケットを損失した結果として、該シーケンス中の全てのパケットを破棄して、購読されているサービスに「損失した」と報告することになる。
Ｖ．例示的な適用環境
Ａ．序論
ストリームトランスポートプロトコルは、通信アプリケーション28,30及びサーバノード16により提供されるプラットフォームの様々な異なる適用環境をサポートする。
例示的な実施形態では、リアルタイムチャット対話上での複数の空間メタファの視覚化のうちの１つ又は２つ以上を適用する。これらの視覚化は、リアルタイムチャット対話に伴う現在の通信状態を表現するためのコンテキストを提供する。前記空間メタファはまた、リアルタイムチャット対話に参加するために通信者により使用される様々なインタフェイス要素の提示を編成するためのコンテキストを提供する。該空間メタファの視覚化は、インターネット又は何らかの形態の内部的なネットワーク／イントラネットを介した２又は３以上の通信者間のリアルタイムでのテキストベース通信を提供する（随意選択的に、オーディオ、ビデオ、ファイル共有、及びアプリケーション共有チャネル等の１つ又は２つ以上の他のリアルタイム通信チャネルを有する）あらゆるタイプのインスタントメッセージングプラットフォームに適用することが可能である。例えば、本実施形態は、AOL（登録商標）インスタントメッセンジャー、MSN（登録商標）メッセンジャー、Yahoo!（登録商標）メッセンジャー、Google（登録商標）Talk、及びSkype（登録商標）といった現在利用可能なインスタントメッセージングプラットフォームの何れと統合させることも可能である。
図２２は、ネットワーク通信環境10（図１参照）の一実施形態300を示しており、この場合、サーバノードは仮想環境生成手段302により実施されている。該仮想環境生成手段302は、ネットワークインフラストラクチャサービス環境306を提供する少なくとも１つのサーバネットワークノード304を含む。通信アプリケーション28,32及びネットワークインフラストラクチャサービス環境306は共に、上述した複数の空間メタファの視覚化の１つ又は２つ以上を含む空間的仮想通信環境（本書では単に「仮想環境」とも称す）を生成するためのプラットフォームを提供する。
ネットワークインフラストラクチャサービス環境306は、仮想領域アプリケーション310に従って仮想領域308内の第１及び第２のクライアントノード12,14のセッションを管理する。仮想領域アプリケーション310は、仮想領域308によってホストされ、仮想領域308の記述を含む。第１及び第２のクライアントネットワークノード12,14上で動作する通信アプリケーション28,30は、ネットワークインフラストラクチャサービス環境306から受信したデータに従って仮想領域308のそれぞれのビューを提供し、並びに通信者からのコマンドを受信するため及び上述のような通信者間のリアルタイム通信を強化する空間的なインタフェイスを提供するためのそれぞれのインタフェイスを提供する。通信者は典型的には、それぞれのアバターにより仮想領域308内で表現され、該アバターは典型的には、それぞれのネットワークノードで通信者により入力されるコマンドに応じて仮想領域308内を動き回る。仮想領域308の各通信者のビューは典型的には、通信者のアバターの視点で提示され、これにより通信者が経験する没入のレベルが増大する。各通信者は典型的には、自分自身のアバターの周囲の仮想領域308のあらゆる部分を見ることが可能である。実施形態によっては、通信アプリケーション28,30は、仮想領域308内の通信者のアバターの位置に基づいて、該仮想領域308を共有している第１及び第２のクライアントネットワークノード12,14と他のネットワークノードとの間のリアルタイムデータストリーム接続を確立する。
ネットワークインフラストラクチャサービス環境306はまた、通信者間の対話記録311を含む関係データベース309を維持する。各対話記録311は、一対の通信者間の対話状況を記述したものである。。
Ｂ．ネットワークインフラストラクチャサービス
ネットワークインフラストラクチャサービス環境306は典型的には、クライアントノード12,14と他のネットワークノードとの間のネットワーク接続を確立し管理するプロセスで通信アプリケーション28,30と協働する１つ又は２つ以上のネットワークインフラストラクチャサービスを含む（図１及び図２２参照）。該ネットワークインフラストラクチャサービスは、単一のネットワークノード上で実行することが可能であり、又は複数のネットワークノードにわたって分散させることが可能である。ネットワークインフラストラクチャサービスは典型的には、１つ又は２つ以上の専用のネットワークノード（例えば、サーバコンピュータ又は１つ又は２つ以上のエッジサービス（ルーティング及びスイッチング等）を実行するネットワーク装置）上で実行される。しかし、実施形態によっては、複数のネットワークインフラストラクチャサービスのうちの１つ又は２つ以上は、複数の通信者の複数のネットワークノードのうちの少なくとも１つで実行される。ネットワークインフラストラクチャサービス環境30の例示的な実施形態に含まれるネットワークインフラストラクチャサービスとして、アカウントサービス、セキュリティサービス、領域サービス、ランデブーサービス、及び対話サービスが挙げられる。
・アカウントサービス
アカウントサービスは、仮想環境のための通信者のアカウントを管理する。アカウントサービスはまた、あらゆるネットワークインフラストラクチャサービスに対してクライアントネットワークノードの認証を行うために該クライアントネットワークノードにより使用することができる認証トークンの生成及び発行を管理する。
・セキュリティサービス
セキュリティサービスは、仮想環境の資源その他のリソースに対する通信者のアクセスを管理する。セキュリティサービスにより実施されるアクセス制御方法は典型的には、１つ又は２つ以上の能力（この場合、適切な能力又は許可を有するエンティティに対してアクセスが許可される）及びアクセス制御リスト（この場合、該リスト上に存在する識別子を有するエンティティに対してアクセスが許可される）に基づくものである。リソースに対する特定の通信者のアクセスが許可された後、該通信者は典型的には、他のネットワークインフラストラクチャサービスにより提供される機能を使用してネットワーク通信環境300内で対話を行う。
・領域サービス
領域サービスは仮想領域を管理する。実施形態によっては、領域サービスは、一組の制約312（図２２参照）を受ける仮想領域アプリケーション308に従って、第１及び第２のクライアントネットワークノード12,14上で動作している通信アプリケーション28,32のリモートコンフィギュレーションを行う。該制約312は典型的には、仮想領域に対するアクセスの制御を含む。このアクセス制御は典型的には、１つ又は２つ以上の能力（この場合、適切な能力又は許可を有する通信者又はクライアントノードに対してアクセスが許可される）及びアクセス制御リスト（この場合、該リスト上に存在する識別子を有する通信者又はクライアントノードに対してアクセスが許可される）に基づくものである。
領域サービスはまた、要求側エンティティの能力の影響下にある仮想領域に関連付けられたネットワーク接続を管理し、仮想領域に関する大域状態情報を維持し、及び仮想領域308により画定される状況で共有通信セッションに参加しているクライアントネットワークノードのためのデータサーバとして働く。該大域状態情報は、仮想領域内にある全てのオブジェクト及び該オブジェクトのそれぞれの仮想領域内の場所のリストを含む。領域サービスは、クライアントネットワークノードのコンフィギュレーションを行う命令を送信する。領域サービスはまた、通信セッションへの参加を要求する他のクライアントネットワークノードを登録し、及び該他のクライアントネットワークノードへ初期化情報を送信する。この過程で、領域サービスは、参加中の各クライアントネットワークノードへ、仮想領域アプリケーション310に従ってクライアントネットワークノード上に仮想領域308をレンダリングするために必要となるコンポーネント（例えばプラグイン）のリストを送信することが可能である。領域サービスはまた、通信障害が発生した場合にクライアントネットワークノードが所定の大域状態に同期できることを確実にする。領域サービスは典型的には、仮想領域に関連付けられた統制ルールを介して仮想領域との通信者の対話を管理する。
・ランデブーサービス
ランデブーサービスは、存在情報の収集、格納、及び配布を管理し、及び要求側エンティティの能力の影響下で（例えば、接続ハンドルの配布を管理することにより）ネットワークノードが互いに通信するための機構を提供する。ランデブーサービスは典型的には、存在情報を存在データベースに格納する。ランデブーサービスは典型的には、通信者のプライバシープリファレンスを介して通信者相互の対話を管理する。
・対話サービス
対話サービスは、通信者間の対話の記録311を含む関係データベース36を維持する。通信者間の各対話毎に、ネットワークインフラストラクチャサービス環境306の１つ又は２つ以上のサービス（例えば、領域サービス）が対話データを対話サービスへ送信する。これに応じて、対話サービスは、１つ又は２つ以上のそれぞれの対話記録を生成し、それを関係データベースに格納する。各対話記録は、一対の通信者間の対話状況を記述したものである。例えば、実施形態によっては、対話記録は、各通信者に関する識別子、対話の場所（例えば、仮想領域インスタンス）に関する識別子、対話場所の階層の記述（例えば、対話部屋の一層大きな領域に対する関係の記述）、対話の開始時刻及び終了時刻、及び対話中に共有され又は記録された全てのファイル及びその他のデータストリームのリストを含む。このため、各リアルタイム対話毎に、対話サービスは、該対話が発生したとき、該対話が発生した場所、関与する通信者に関して対話中に生じたこと（例えば、参加及び退出）、アクティブ又は非アクティブにされたオブジェクト、及び共有されたファイルを追跡する。
対話サービスはまた、要求側エンティティの能力の影響下で関係データベースの照会をサポートする。対話サービスは、対話データベース記録についての照会の結果を仮想領域に基づいてソートされた所定の順序（例えば頻度順又は時刻順）で提示する。該照会結果を使用して、通信者がどの仮想領域でどの人に会ったかに関する接触頻度でのソート、仮想領域とは無関係に通信者が会った人によるソート、及び通信者が最も多く出入りしている仮想領域によるソートを行うことが可能である。該照会結果はまた、関係に基づいて特定のタスクを自動化するヒューリスティックシステムの一部としてアプリケーションの開発者が使用することが可能なものである。この種のヒューリスティックの一例が、特定の仮想領域を６回以上訪れた通信者がノックすることなくデフォルトで入ることを許可するヒューリスティック、又は特定の時刻に特定の領域内に存在する通信者が、それと同じ時刻に同じ領域内に存在する別の通信者により作成されたファイルを修正し削除することを可能にするヒューリスティックである。関係データベース309の照会は、他の検索と組み合わせることが可能である。例えば、関係データベースの照会を、ネットワークインフラストラクチャサービス環境306の領域外にある通信システム（例えば、Skype（登録商標）、Facebook（登録商標）、及びFlickr（登録商標））を使用した接触との対話について生成された接触履歴データの照会と組み合わせることが可能である。
Ｃ．仮想領域
通信アプリケーション28,32及びネットワークインフラストラクチャサービス環境306は典型的には、仮想領域のインスタンスにより画定される通信状況においてネットワークノードとのリアルタイム接続を管理する。仮想領域インスタンスは、抽象座標に関して定義される抽象的（非幾何学的）仮想空間に対応することが可能である。代替的に、仮想領域インスタンスは、特定の視覚化に関連付けられた１次元、２次元、又は３次元の幾何学座標に関して定義される視覚的仮想空間に対応することが可能である。抽象的仮想領域は、個々の視覚化に関連付けることも関連付けないことも可能であり、一方、視覚的仮想領域は、個々の視覚化に関連付けられる。
上述のように、通信者は典型的には、関連する視覚化を有する仮想領域内の個々のアバター（例えば、スプライト）によって表現される。該アバターは、それぞれのネットワークノードにおいて通信者により入力されたコマンドに応じて仮想領域内を移動する。実施形態によっては、仮想領域インスタンスの通信者のビューは典型的には、通信者のアバターの視点から提供され、各通信者は典型的には、該通信者のアバターの周囲の視覚的仮想領域のあらゆる部分を見ることが可能であり、これにより該通信者が経験する没入のレベルが増大する。
仮想領域は典型的には、仮想領域内の複数のアバターにより表現される複数のネットワークノード間の複数のリアルタイムデータストリームのスイッチングを支配するそれぞれのルールに関連付けられた１つ又は２つ以上のゾーンを含む。該スイッチングルールは、ネットワークノードの各々で実行されるローカル接続プロセスが他のネットワークノードとの通信を確立する態様を仮想領域のゾーン内の通信者のアバターの場所に基づいて指示するものである。仮想領域は典型的には、仮想領域の幾何学的要素の記述及び１つ又は２つ以上のルール（スイッチングルール及び統制ルールを含む）を含む仕様によって定義される。該スイッチングルールは、複数のネットワークノード間のリアルタイムストリーム接続を支配する。該統制ルールは、仮想領域自体、仮想領域内の領域、及び仮想領域内のオブジェクトといったリソースに対する通信者のアクセスを制御するものである。実施形態によっては、仮想領域の幾何学的要素は、COLLADA-Digital Asset Schema Release 1.4.1 April 2006仕様（http://www.khronos.org/collada/から入手可能）に従って記述され、スイッチングルールは、米国特許出願第11/923,649号及び11/923,634号に記載される COLLADA Streams Reference 仕様に従ってXML（Extensible Markup Language）テキスト形式（本書では仮想空間記述形式（VSDL）と称す）を用いて記述される。
仮想領域の幾何学的要素は典型的には、仮想領域の物理ジオメトリ及びコリジョンジオメトリを含む。該物理ジオメトリは、仮想領域の形状を記述するものである。該物理ジオメトリは典型的には、三角形、四角形、又は多角形の表面から形成される。該物理ジオメトリ上に色及びテクスチャがマッピングされて、仮想領域のための一層現実的な外観が生成される。例えば、視覚的ジオメトリ上に光をペイントし、及び該光の近くのテクスチャ、色、又は明度を変更することにより、照明効果を与えることが可能である。前記コリジョンジオメトリは、オブジェクトが仮想領域内を移動することができる態様を画定する不可視表面を記述するものである。該コリジョンジオメトリは、視覚的ジオメトリと一致させること、視覚的ジオメトリの一層単純な近似に対応させること、又は仮想領域の設計者の特定用途向けの要件に関連するものとすることが可能である。
前記スイッチングルールは典型的には、仮想領域の位置に関してリアルタイムデータストリームのソース及びシンクを接続するための条件の記述を含む。各ルールは典型的には、該ルールの適用対象となるリアルタイムデータストリームのタイプと、該ルールが適用される仮想領域内の１つ又は２つ以上の場所とを画定する属性を含む。実施形態によっては、各ルールは、随意選択的に、必要とされるソースの役割、必要とされるシンクの役割、ストリームの優先順位、及び必要とされるストリーム操作トポロジーを指定する、１つ又は２つ以上の属性を含むことが可能である。実施形態によっては、仮想領域の特定部分について定義された明示的なスイッチングルールが存在しない場合に、１つ又は２つ以上の暗黙又はデフォルトのスイッチングルールを該仮想領域の該部分に適用することが可能である。１つの例示的なデフォルトスイッチングルールが、ポリシールールの支配下で一領域内のあらゆるソースをあらゆる互換性を有するシンクへと接続するルールである。ポリシールールは、複数のクライアントノード間の全ての接続に対して大域的に適用することが可能であり、又は個々のクライアントノードとの個々の接続に対してのみ適用することが可能である。ポリシールールの一例が、仮想領域内で互いに所定の距離（又は半径）内にあるそれぞれのオブジェクトに関連付けられている互換性を有するシンクとのソースの接続のみを可能とする近接ポリシールールである。
実施形態によっては、統制ルールは、仮想領域にアクセスする者、そのコンテンツにアクセスする者、仮想領域のコンテンツに対するアクセスの範囲（例えば、該コンテンツに対してユーザができること）、及びそれらコンテンツへのアクセスに後続する結果（例えば、監査ログ及び支払要求といった記録の保持）を制御するために仮想領域に関係する。実施形態によっては、仮想領域全体又は仮想領域の１つのゾーンが「統制網（governance mesh）」に関連付けられる。実施形態によっては、統制網は、米国特許出願第11/923,629号及び第11/923,634号に記載されているゾーン網の実施形態と類似した態様で実施される。統制網は、ソフトウェアアプリケーションの開発者が、統制ルールを一仮想領域又は一仮想領域の一ゾーンに関連付けることを可能にする。これにより、仮想領域内のあらゆるファイルについてそれぞれの許可を生成する必要がなくなり、及び同一ドキュメントをコンテキストに応じて異なる態様で扱う必要がある場合に生じ得る複雑さに対処する必要がなくなる。
実施形態によっては、仮想領域は、該仮想領域の１つ又は２つ以上のゾーンをディジタル著作権管理（DRM）機能に関連付ける統制網に関連付けられる。DRM機能は、仮想領域の１つ又は２つ以上、仮想領域内の１つ又は２つ以上のゾーン、又は仮想領域内のオブジェクトに対するアクセスを制御する。DRM機能は、通信者が仮想領域内で統制網の境界を越えるたびにトリガされる。DRM機能は、トリガ動作が許可されているか否かを判定し、トリガ動作が許可されている場合には、許可されている動作の範囲、支払いが必要か否か、及び監査記録を生成する必要があるか否かを判定する。仮想領域の例示的な実施態様では、関連付けられた統制網は、通信者が仮想領域に入ることができる場合に該通信者が該仮想領域に関連付けられた全てのドキュメントについて動作（ドキュメントの操作、ドキュメントの閲覧、ドキュメントのダウンロード、ドキュメントの削除、ドキュメントの変更、及びドキュメントの再アップロードを含む）を実行することができるように構成される。このようにして、仮想領域は、該仮想領域により定義されたコンテキストで共有され議論された情報の保存場所となることができる。
仮想領域の仕様に関する更なる詳細が、米国特許出願第61/042714号（2008年4月4日出願）、第11/923,629号（2007年10月24日出願）、及び第11/923,634号（2007年10月24日出願）に記載されている。
Ｄ．通信アプリケーション
実施形態によっては、通信アプリケーション26は、以下のものを含む。
ａ．ローカルHID（Human Interface Devices）及びオーディオプレイバック装置
ｂ．So3Dグラフィカルディスプレイ、アバター、及び物理エンジン
ｃ．システムデータベース及び格納設備
ローカルHID（Human Interface Devices）及びオーディオプレイバック装置
ローカルHIDは、通信者が、仮想領域通信セッションに参加している間に命令及びその他の信号をクライアントネットワークノードに入力することを可能にするものである。例示的なHIDとして、コンピュータキーボード、コンピュータマウス、タッチスクリーンディスプレイ、及びマイクが挙げられる。
オーディオプレイバック装置は、通信者が仮想領域通信セッション中に受信したオーディオ信号を再生することを可能にする。例示的なオーディオプレイバック装置として、オーディオ信号の操作（例えば、ミキシング及び特殊効果の適用）を行うためのオーディオ処理ハードウェア（例えば、サウンドカード）及び音声を出力するためのスピーカが挙げられる。
So3Dグラフィカルディスプレイ、アバター、及び物理エンジン
So3Dエンジンは、ディスプレイモニタにおける仮想領域及び該仮想領域内のオブジェクトの個々のビューの表示を制御する３次元視覚化エンジンである。So3Dエンジンは典型的には、グラフィカルユーザインタフェイスドライバ及びHIDデバイスと協働して仮想領域のビューを表示し、及び通信者が通信アプリケーション26の動作を制御することを可能にする。
実施形態によっては、So3Dエンジンは、領域サービスからのグラフィクスレンダリング命令を受信する。So3Dエンジンはまた、仮想領域内に通信者のアバターを描画するために必要なイメージを含むローカル通信者アバターデータベースに対して読み出しを行うことが可能である。この情報に基づいて、So3Dエンジンは、仮想領域及び該仮想領域内のオブジェクトの視覚的表現（すなわち、イメージ）を該仮想領域内の通信者のアバターの視点（位置及び向き）から生成する。この視覚的な表現は典型的には、オペレーティングシステムのグラフィクスレンダリング要素へと渡され、該要素がグラフィクスレンダリングハードウェアを駆動して仮想領域の視覚的表現をクライアントネットワークノード上でレンダリングする。
通信者は、HIDデバイス（例えば、コンピュータマウス）を介してビュー制御コマンドを入力することにより、表示される仮想領域のビューを制御することが可能である。So3Dエンジンは、該ビュー制御コマンドに従って仮想領域のビューを更新させる。So3Dエンジンはまた、領域サービスから受信した更新されたオブジェクト位置情報に従って、ディスプレイモニタ上の仮想領域のグラフィック表現を更新させる。
Ｅ．システムデータベース及び格納設備
システムデータベース及び格納設備は、該プラットフォームにより使用される様々な種類の情報を格納する。該格納設備により一般に格納される例示的な情報として、存在データベース、関係データベース、アバターデータベース、リアルユーザID（RUID）データベース、アートキャッシュデータベース、及び領域アプリケーションデータベースが挙げられる。この情報は、単一のネットワークノード上に格納することが可能であり、又は複数のネットワークノードに渡って分散させることが可能である。
Ｆ．クライアントノードアーキテクチャ
通信は典型的には、クライアントネットワークノードからネットワーク20へ接続する。クライアントネットワークノードは典型的には、汎用コンピュータシステム又は専用の通信コンピュータシステム（又はネットワーク対応型ビデオゲームコンソール等の「コンソール」）により実施される。クライアントネットワークノードは、他のネットワークノードとのリアルタイムデータストリーム接続を確立する通信プロセスを実行し、典型的には通信者が入った各仮想領域のビューを提供する視覚化レンダリングプロセスを実行する。
図２３は、コンピュータシステム320により実施されたクライアントネットワークノードの一実施形態を示している。該コンピュータシステム320は、プロセッサユニット322、システムメモリ324、及び該プロセッサユニット322を該コンピュータシステム320の様々な要素に接続するシステムバス326を含む。該プロセッサユニット322は、１つ又は２つ以上のデータプロセッサを含むことが可能であり、その各プロセッサは、市販の様々なコンピュータプロセッサの何れの形態をとることも可能である。システムメモリ324は、１つ又は２つ以上のコンピュータ読み取り可能媒体を含み、典型的には、ソフトウェアアプリケーションに対して利用可能となるアドレスを画定するソフトウェアアプリケーションアドレス指定空間が関連付けられる。該システムメモリ324は、コンピュータシステム320のための起動ルーチンを含むBIOS（Basic Input/Output System）を格納したROM（Read Only Memory）、及びRAM（Random Access Memory）を含むことが可能である。システムバス326は、メモリバス、周辺機器用バス、又はローカルバスとすることが可能であり、及び様々なバスプロトコル（PCI、VESA、MCA（Microchannel）、ISA、及びEISAを含む）の何れと互換性を有するものとすることも可能である。コンピュータシステム320はまた、永続記憶メモリ328（例えば、ハードディスクドライブ、フロッピーディスクドライブ、CD-ROMドライブ、磁気テープドライブ、フラッシュメモリデバイス、及びディジタルビデオディスク）を含むことが可能であり、該永続記憶メモリ328は、システムバス326に接続され、データ、データ構造、及びコンピュータ実行可能命令の不揮発性の又は永続的な記憶を提供するて１つ又は２つ以上のコンピュータ読み取り可能媒体ディスクを含む。
通信者は、１つ又は２つ以上の入力装置330（例えば、１つ又は２つ以上のキーボード、コンピュータマウス、マイク、カメラ、ジョイスティック、Wii（登録商標）入力装置等の物理モーションセンサ、及びタッチパッド）を使用してコンピュータシステム320と対話する（例えば、コマンド又はデータを入力する）ことが可能である。情報は、ディスプレイコントローラ334により制御されるディスプレイモニタ332上で通信者に提示されるGUI（Graphical User Interface）を介して提示することが可能である。コンピュータシステム320はまた、他の入出力装置（例えば、スピーカ及びプリンタ等の出力用周辺機器）を含むことが可能である。コンピュータシステム320は、ネットワークアダプタ336（「ネットワークインタフェースカード」又はNICとも呼ばれる）を介して他のネットワークノードと接続する。
API（Application Programming Interface）338、OS（Operating System）340（例えば、Microsoft Corporation（Redmond, Washington U.S.A.）から入手可能なWindows XP（登録商標）オペレーティングシステム）、通信アプリケーション26、ドライバ342（例えば、GUIドライバ）、ネットワーク転送プロトコル344、及びデータ346（例えば、入力データ、出力データ、プログラムデータ、レジストリ、及びコンフィギュレーション設定）を含む、多数のプログラムモジュールをシステムメモリ324に格納することが可能である。
Ｇ．サーバノードアーキテクチャ
実施形態によっては、仮想環境生成手段16の１つ又は２つ以上のサーバネットワークノードは、その各サーバネットワークノードが典型的には１つ又は２つ以上のサーバソフトウェアアプリケーションを含むことを除き、クライアントネットワークノード320と同じタイプのそれぞれの汎用コンピュータシステムによって実施される。
別の実施形態では、仮想環境生成手段302の１つ又は２つ以上のサーバネットワークノードは、エッジサービス（例えば、ルーティング及びスイッチング）を実行するそれぞれのネットワーク装置によって実施される。
VI．結論
本書で説明した実施形態は、個々のネットワークノードを操作している通信者間のリアルタイムネットワーク通信をサポートするストリームトランスポートプロトコルを提供する。該ストリームトランスポートプロトコルは、比較的低い計算上のリソース要件を有するものであり、このため、現在利用可能な広範なコンピューティング装置及びネットワーク接続を使用してリアルタイム通信性能を達成することができる。
他の実施形態は、特許請求の範囲内のものである。

Claims (71)

  1. サーバネットワークノード(16)により実施される方法であって、
    該サーバネットワークノード(16)によりホストされているサーバアプリケーション(38)に接続されているクライアントネットワークノード(12,14)の１つ又は２つ以上の対を決定し、その各対の構成要素となるクライアントネットワークノード(12,14)が、それぞれのデータストリームコンテンツタイプの相補的なソース及びシンクの１つ又は２つ以上のアクティブな組を有しており、
    該決定されたクライアントネットワークノード(12,14)の各対毎に、該対の構成要素となるクライアントネットワークノード(12,14)の各々に、該対の構成要素となるクライアントネットワークノード(12,14)間のネットワーク接続を介したそれぞれのピア・ツー・ピア・セッションを定義するそれぞれのセッション定義を送信する、
    という各ステップからなる、サーバネットワークノード(16)により実施される方法。
  2. 前記クライアントネットワークノード(12,14)の各々にそれぞれの一意のステーション識別子が割り当てられており、
    前記サーバネットワークノード(16)により、前記サーバアプリケーション(38)に接続されているクライアントネットワークノード(12,14)の各々に、他のクライアントネットワークノード(12,14)に割り当てられているそれぞれの一意のステーション識別子を送信する、
    というステップを更に含む、請求項１に記載の方法。
  3. 前記サーバネットワークノード(16)により、
    前記クライアントネットワークノード(12,14)の各々毎に、
    それぞれのステーション識別子と１つ又は２つ以上のエントリとを含むそれぞれのステーション定義を決定し、その各エントリが、それぞれのコネクションレス型トランスポートプロトコルアドレスと、該クライアントネットワークノード上のプロトコルポートのそれぞれのプロトコルポート識別子とを含み、
    前記ステーション識別子を送信する前記ステップが、それぞれのステーション定義を、前記サーバアプリケーション(38)に接続されている他のクライアントネットワークノード(12,14)の各々に送信するステップを含む、
    という各ステップを更に含む、請求項２に記載の方法。
  4. 前記クライアントネットワークノード(12,14)の各々毎に、
    それぞれのステーション定義を決定する前記ステップが、前記サーバネットワークノード(16)により、それぞれのネットワークアドレス及びクライアントネットワークノード上のプロトコルポートのそれぞれのプロトコルポート識別子を、前記クライアントネットワークノードから受信した１つ又は２つ以上のメッセージの各々から抽出するステップを含む、請求項３に記載の方法。
  5. 前記サーバネットワークノード(16)により、
    前記決定されたクライアントネットワークノード(12,14)の各対毎に、それぞれのセッション定義を生成し、該セッション定義が、(i) 該対の構成要素となるクライアントネットワークノード(12,14)に割り当てられているそれぞれのステーション識別子と、(ii) 該対の構成要素となるクライアントネットワークノード(12,14)間のネットワーク接続を確立するためのコネクションレス型トランスポートプロトコルに関連付けられているトランスポート識別子とを含む、
    というステップを更に含む、請求項３に記載の方法。
  6. 前記サーバネットワークノード(16)により、
    前記決定されたクライアントネットワークノード(12,14)の各対毎に、それぞれのセッション定義を生成し、該セッション定義が、該対の構成要素となるクライアントネットワークノード(12,14)間のネットワーク接続で伝送されるデータを暗号化するための暗号化プロセスに関連付けられた暗号化識別子を含む、
    というステップを更に含む、請求項５に記載の方法。
  7. 前記サーバネットワークノード(16)により、
    プロキシサーバのステーション定義を、前記サーバアプリケーション(38)に接続されているクライアントネットワークノード(12,14)の各々に送信し、該ステーション定義が、前記プロキシサーバに割り当てられているそれぞれのステーション識別子と、１つ又は２つ以上のエントリとを含み、その各エントリが、それぞれのネットワークアドレスと、該プロキシサーバ上のプロトコルポートのそれぞれのプロトコルポート識別子とを含む、
    というステップを更に含む、請求項１に記載の方法。
  8. 前記サーバネットワークノード(16)により、
    前記決定されたクライアントネットワークノード(12,14)の各対毎に、
    該対の構成要素となるクライアントネットワークノード(12,14)間のそれぞれのデータストリームコンテンツタイプの相補的なソース及びシンクのアクティブな組の各々毎に、該対の構成要素となるクライアントネットワークノード(12,14)間のネットワーク接続を介したセッションで伝送されるデータを論理的に分割するそれぞれのチャネルの定義を決定する、
    というステップを更に含む、請求項１に記載の方法。
  9. 前記チャネル定義のうちの１つ又は２つ以上の各々が、それぞれのチャネルでのデータの伝送を他の任意のチャネルでのデータの伝送とは無関係に制御する１つ又は２つ以上のトランスポートパラメータ値からなるそれぞれの組を含む、請求項８に記載の方法。
  10. 前記チャネル定義のうちの１つ又は２つ以上の各々が、それぞれの信頼可能性トランスポートパラメータ値を含み、該信頼可能性トランスポートパラメータ値が、それぞれのチャネル上のデータが、損失したデータパケットを再送信する信頼できるトランスポートプロトコルによって伝送されるか又は損失したデータパケットを棄却する信頼できないトランスポートプロトコルによって伝送されるかを示すものである、請求項９に記載の方法。
  11. 前記チャネル定義のうちの１つ又は２つ以上の各々が、それぞれの圧縮トランスポートパラメータ値を含み、該圧縮トランスポートパラメータ値が、それぞれのチャネル上のデータを完全な状態で処理することが必要とされるか否かを示すものである、請求項９に記載の方法。
  12. 前記チャネル定義のうちの１つ又は２つ以上の各々が、それぞれの順序付けトランスポートパラメータ値を含み、該順序付けトランスポートパラメータ値が、それぞれのチャネル上のデータを順序通りに処理すべきか任意の順序で処理すべきかを示すものである、請求項９に記載の方法。
  13. 前記チャネル定義のうちの１つ又は２つ以上の各々が、それぞれの圧縮識別子を含み、該圧縮識別子が、それぞれのチャネルで伝送されたデータを圧縮するためのそれぞれの圧縮プロセスを指定するものである、請求項９に記載の方法。
  14. 前記チャネル定義のうちの１つ又は２つ以上の各々が、それぞれの一意のコンテンツ識別子に関連付けられており、該コンテンツ識別子が、チャネルに割り当てられているそれぞれのデータストリームコンテンツタイプを識別するものである、請求項８に記載の方法。
  15. 前記サーバネットワークノード(16)により、
    前記サーバアプリケーション(38)に接続されているクライアントネットワークノード(12,14)の各々とそれぞれのサーバセッション(40,42)を確立し、
    該サーバセッション(40,42)の各々を介して、コンテンツタイプにより制御メッセージを論理的に分割する異なるそれぞれのチャネルで異なるコンテンツタイプの制御メッセージを送信する、
    という各ステップを更に含む、請求項１に記載の方法。
  16. 前記制御メッセージの各々が、サーバセッション(40,42)に割り当てられている一意のサーバセッション(40,42)識別子と、該制御メッセージのコンテンツタイプを識別するそれぞれのコンテンツ識別子と共に送信される、請求項１５に記載の方法。
  17. 前記サーバネットワークノード(16)により、
    前記クライアントネットワークノード(12,14)のうちの所与の１つからの、前記サーバアプリケーション(38)との接続を切断するためのメッセージの受信に応じて、該所与のクライアントネットワークノードとのそれぞれのセッションを終了させるためのそれぞれの命令を、該所与のクライアントネットワークノードとのそれぞれのセッションを有する他のクライアントネットワークノード(12,14)に送信する、
    というステップを更に含む、請求項１に記載の方法。
  18. 装置(16)であって、
    コンピュータ読み取り可能命令を格納しているコンピュータ読み取り可能メモリと、
    該メモリに接続されたデータ処理手段であって、前記命令を実行するよう動作することが可能であり、及び該命令の実行に少なくとも部分的に基づいて、
    該装置(16)によりホストされているサーバアプリケーション(38)に接続されているクライアントネットワークノード(12,14)の１つ又は２つ以上の対を決定し、その各対の構成要素となるクライアントネットワークノード(12,14)が、それぞれのデータストリームコンテンツタイプの相補的なソース及びシンクの１つ又は２つ以上のアクティブな組を有しており、
    該決定されたクライアントネットワークノード(12,14)の各対毎に、該対の構成要素となるクライアントネットワークノード(12,14)の各々に、該対の構成要素となるクライアントネットワークノード(12,14)間のネットワーク接続を介したそれぞれのピア・ツー・ピア・セッションを定義するそれぞれのセッション定義を送信する、
    という各動作を実行するよう動作することが可能である、データ処理手段と
    を備えている装置(16)。
  19. コンピュータ読み取り可能プログラムコードが内部に組み込まれた少なくとも１つのコンピュータ読み取り可能記憶装置であって、該コンピュータ読み取り可能プログラムコードが、コンピュータ(16)により実行されて、
    該コンピュータ(16)によりホストされているサーバアプリケーション(38)に接続されているクライアントネットワークノード(12,14)の１つ又は２つ以上の対を決定し、その各対の構成要素となるクライアントネットワークノード(12,14)が、それぞれのデータストリームコンテンツタイプの相補的なソース及びシンクの１つ又は２つ以上のアクティブな組を有しており、
    該決定されたクライアントネットワークノード(12,14)の各対毎に、該対の構成要素となるクライアントネットワークノード(12,14)の各々に、該対の構成要素となるクライアントネットワークノード(12,14)間のネットワーク接続を介したそれぞれのピア・ツー・ピア・セッションを定義するそれぞれのセッション定義を送信する、
    という各ステップからなる方法を実施するよう構成されたものである、コンピュータ読み取り可能記憶装置。
  20. 所与のクライアントネットワークノード(12)により実施される方法であって、
    サーバネットワークノード(16)によりホストされているサーバアプリケーション(38)に接続し、該サーバネットワークノード(16)には１つ又は２つ以上の他のクライアントネットワークノード(14)が接続されており、該所与のクライアントネットワークノード及び該１つ又は２つ以上の他のクライアントネットワークノード(14)の各々が、それぞれのデータストリームコンテンツタイプの１つ又は２つ以上のソース及びシンクを有しており、
    前記他のクライアントネットワークノード(14)であって、該他のクライアントネットワークノードの前記１つ又は２つ以上のソース及びシンクのうちのアクティブなものと相補的な関係にある少なくとも１つのアクティブなソース又はシンクを前記所与のクライアントネットワークノードが有している、該他のクライアントネットワークノード(14)の各々毎に、該所与のクライアントネットワークノードと該他のクライアントネットワークノード(14)のうちのそれぞれのセッションパートである１つとの間のそれぞれのセッション定義を前記サーバネットワークノード(16)から受信し、
    該受信したセッション定義の各々毎に、該セッション定義に基づいて前記所与のクライアントネットワークノードと前記それぞれのセッションパートナーのクライアントネットワークノードとの間のそれぞれのネットワーク接続を介したそれぞれのピア・ツー・ピア・セッションを確立する、
    という各ステップからなる、所与のクライアントネットワークノード(12)により実施される方法。
  21. 前記セッション定義のうちの少なくとも１つが、それぞれのセッションパートナーのクライアントネットワークノードとのそれぞれのネットワーク接続をネゴシエートするための複数のそれぞれのアドレスに関連付けられており、
    前記所与のクライアントネットワークノード(12)により、
    前記少なくとも１つのセッション定義の各々毎に、該セッション定義に関連付けられている前記複数のそれぞれのアドレスの全てについてそれぞれのセッションパートナーのクライアントネットワークノード(14)とのそれぞれのネットワーク接続の確立を試行する、
    というステップが更に実施される、請求項２０に記載の方法。
  22. 前記所与のクライアントネットワークノード(12)により、
    該所与のクライアントネットワークノード(12)が前記他のクライアントネットワークノード(14)との複数の同時のネットワーク接続を成功裏に確立した該セッションパートナーのクライアントネットワークノード(14)の各々毎に、該セッションパートナーのクライアントネットワークノードとの前記複数のネットワーク接続のうちの１つを選択し、該選択したネットワーク接続を介したそれぞれのセッションを該セッションパートナーのクライアントネットワークノード(14)と確立する、
    というステップが更に実施される、請求項２１に記載の方法。
  23. 前記所与のクライアントネットワークノード(12)により、
    該所与のクライアントネットワークノード(12)が前記他のクライアントネットワークノード(14)との複数の同時のネットワーク接続を成功裏に確立した該セッションパートナーのクライアントネットワークノード(14)の各々毎に、該セッションパートナーのクライアントネットワークノード(14)との前記複数の同時のネットワーク接続のうちの未選択のものの１つ又は２つ以上を、前記選択されたネットワーク接続を介して確立されたそれぞれのセッション中に存続させる、
    というステップが更に実施される、請求項２２に記載の方法。
  24. 前記所与のクライアントネットワークノード(12)により、
    前記サーバアプリケーション(38)に接続されている前記他のクライアントネットワークノード(14)のうちの１つ又は２つ以上の各々毎にそれぞれのステーション定義を前記サーバネットワークノード(16)から受信し、該ステーション定義の各々が、それぞれの前記他のクライアントネットワークノード(14)に割り当てられているそれぞれの一意のステーション識別子と、１つ又は２つ以上のエントリとを含み、その各エントリが、それぞれのネットワークアドレスと、前記それぞれの他のクライアントネットワークノード(14)のプロトコルポートのそれぞれのプロトコルポート識別子とを含み、
    前記セッション定義の各々が、それぞれのセッションパートナーのクライアントネットワークノードに割り当てられている一意のステーション識別子を含み、
    前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノード(12)により、セッション定義中のステーション識別子に基づいて前記それぞれのセッションパートナーのクライアントネットワークノード(14)のステーション定義中の１つ又は２つ以上のエントリを決定し、該エントリの各々毎に、前記それぞれのネットワークアドレス及び前記それぞれのプロトコルポート識別子を介して前記それぞれのセッションパートナーのクライアントネットワークノード(14)とのそれぞれのネットワーク接続の確立を試行する、
    というステップが更に実施される、請求項２１に記載の方法。
  25. 前記セッション定義の各々が、前記ネットワーク接続を確立するためのコネクションレス型トランスポートプロトコルに関連付けられているトランスポート識別子を含み、
    前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノード(12)により、前記それぞれのセッション定義中の前記トランスポート識別子に関連付けられている前記コネクションレス型トランスポートプロトコルに従って前記それぞれのセッションパートナーのクライアントネットワークノード(14)とのそれぞれのネットワーク接続の確立を試行する、というステップを含む、請求項２４に記載の方法。
  26. 前記セッション定義の各々が、それぞれのセッションパートナーのクライアントネットワークノード(14)とのそれぞれのネットワーク接続をネゴシエートするための１つ又は２つ以上のそれぞれのネットワークアドレスに関連付けられており、
    前記所与のクライアントネットワークノード(12)により、
    プロキシサーバネットワークノード(16)のそれぞれのアドレスを前記サーバネットワークノード(16)から受信し、
    前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノード(12)により、前記セッション定義に関連付けられている１つ又は２つ以上のそれぞれのアドレスの各々について及び前記プロキシサーバネットワークノード(16)の前記それぞれのアドレスについて前記それぞれのセッションパートナーのクライアントネットワークノード(14)とのそれぞれのネットワーク接続の確立を試行する、というステップを更に含む、請求項２０に記載の方法。
  27. 前記セッション定義の各々が、前記所与のクライアントネットワークノード(12)及び前記それぞれの他のクライアントネットワークノード(14)の各々に割り当てられているそれぞれの一意のステーション識別子に関連付けられており、
    前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノード(12)により、
    前記それぞれのセッションパートナーのクライアントネットワークノード(14)に割り当てられている前記それぞれのステーション識別子を含む１つ又は２つ以上のインバウンドメッセージの各々からそれぞれのソースネットワークアドレスを抽出し、
    それぞれのセッションパートナーのクライアントネットワークノード(14)に割り当てられているステーション識別子により索引付けされているローカルで格納しているステーション定義を、該ローカルで格納しているステーション定義にまだ含まれていない各々の抽出されたソースネットワークアドレスを含めるよう更新させる、
    という各ステップを含む、請求項２０に記載の方法。
  28. 前記セッション定義の各々が、前記所与のクライアントネットワークノード(12)及び前記それぞれの他のクライアントネットワークノード(14)の各々に割り当てられているそれぞれの一意のステーション識別子に関連付けられており、
    前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノード(12)により、
    該所与のクライアントネットワークノード(12)に割り当てられている一意のステーション識別子を含むアウトバウンドメッセージをそれぞれのセッションパートナーのクライアントネットワークノード(14)へ送信し、
    前記アウトバウンドメッセージに応答するインバウンドメッセージであって、前記それぞれのセッションパートナーのクライアントネットワークノード(14)に割り当てられている一意のステーション識別子を含むインバウンドメッセージを受信したことに応じて、該インバウンドメッセージからそれぞれのソースネットワークアドレスを抽出して、前記それぞれのセッションパートナーのクライアントネットワークノード(14)を該抽出されたソースネットワークアドレスにバインドする、
    という各ステップを含む、請求項２０に記載の方法。
  29. 前記セッション定義の各々が、それぞれの一意のステーション識別子に関連付けられており、
    前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノード(12)により、
    前記それぞれのセッションパートナーのクライアントネットワークノード(14)がバインドされた前記ネットワークアドレスにアドレス指定されたトランスポートストリームを介して、該それぞれのセッションパートナーのクライアントネットワークノード(14)とのそれぞれのセッションに割り当てられた一意のセッション識別子を含む別のアウトバウンドメッセージを送信し、
    該別のアウトバウンドメッセージに応じたインバウンドメッセージであって、前記それぞれのセッションに割り当てられた一意のセッション識別子を含むインバウンドメッセージを受信したことに応じて、前記トランスポートストリームを、前記それぞれのセッションでデータを送信するのに有効なものとして指定する、
    という各ステップを含む、請求項２８に記載の方法。
  30. 前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記所与のクライアントネットワークノード(12)により、
    前記それぞれのセッションパートナーのクライアントネットワークノード(14)と複数のネットワーク接続を生成し、
    該生成された複数のネットワーク接続のうちの選択された１つを介してそれぞれのセッションを確立し、
    前記生成されたネットワーク接続のうちの未選択のもののうちの１つ又は２つ以上を、、前記選択されたネットワーク接続を介して確立されたセッション中に存続させる、
    という各ステップを含む、請求項２０に記載の方法。
  31. 前記受信したセッション定義の各々毎にそれぞれのセッションを確立する前記ステップが、前記生成された複数のネットワーク接続のうちの所与の１つの失敗に応じて、前記所与のクライアントネットワークノード(12)により、前記それぞれのセッションパートナーのクライアントネットワークノード(14)との前記所与のネットワーク接続の再生成を試行するステップを含む、請求項３０に記載の方法。
  32. 前記所与のクライアントネットワークノード(12)により、
    該所与のクライアントネットワークノード(12)から公開することができるローカル公開チャネルの識別子を前記サーバネットワークノード(16)から受信し、
    前記確立されたピア・ツー・ピア・セッションの各々で前記ローカル公開チャネルを公開する、
    というステップを更に含む、請求項２０に記載の方法。
  33. 前記所与のクライアントネットワークノード(12)により、
    前記確立された複数のピア・ツー・ピア・セッションのうちの所与の１つにおいて複数の前記ローカル公開チャネルのうちの所与の１つを購読する要求を受信したことに応じて、前記所与のローカル公開チャネルに関連付けられているデータを前記それぞれのセッションパートナーのクライアントネットワークノード(14)に送信する、
    というステップを更に含む、請求項３２に記載の方法。
  34. 前記所与のクライアントネットワークノード(12)により、
    該所与のクライアントネットワークノード(12)上の１つ又は２つ以上のローカルソフトウェアエンティティに関連付けられているローカル購読チャネルを決定し、
    前記確立された複数のピア・ツー・ピア・セッションのうちの所与の１つにおいて１つ又は２つ以上のリモート公開チャネルの公開を受信したことに応じて、該リモート公開チャネルのそれぞれに対応するローカル購読チャネルの各々を購読する要求を前記それぞれのセッションパートナーのクライアントネットワークノード(14)に送信する、
    という各ステップを更に含む、請求項３２に記載の方法。
  35. 前記所与のクライアントネットワークノード(12)により、
    前記ローカル購読チャネルのそれぞれに対応する前記リモート公開チャネルのそれぞれにおいて前記所与のピア・ツー・ピア・セッションでデータを受信したことに応じて、該受信したデータを、前記対応するローカル購読チャネルに関連付けられているローカルソフトウェアエンティティの各々に渡す、
    というステップを更に含む、請求項３４に記載の方法。
  36. 前記所与のクライアントネットワークノード(12)により、
    データストリームコンテンツタイプにより複数の前記セッションのうちの所与の１つで伝送されるデータを論理的に分割するそれぞれのチャネルの定義を前記サーバネットワークノード(16)から受信し、
    前記データストリームのコンテンツタイプに従って、それぞれのチャネルで前記所与のセッションで前記それぞれのセッションパートナーのクライアントネットワークノード(14)へデータストリームを送信する、
    という各ステップを更に含む、請求項２０に記載の方法。
  37. 前記チャネル定義の各々が、前記それぞれのチャネルに割り当てられているそれぞれのデータストリームコンテンツタイプを識別するそれぞれの一意のコンテンツ識別子を含み、前記データストリームを送信する前記ステップが、前記複数のチャネルのそれぞれの１つで、前記データストリームの前記コンテンツタイプに対応する複数の前記コンテンツ識別子のうちの１つをそれぞれ含むパケットという形で前記データストリームの各々を送信するステップを含む、請求項３６に記載の方法。
  38. 前記チャネル定義の各々が、それぞれのチャネルでのデータの伝送を、前記所与のセッションにおける他の任意のチャネルでのデータの伝送とは無関係に制御する、１つ又は２つ以上のトランスポートパラメータ値からなるそれぞれの組を含む、請求項３６に記載の方法。
  39. 前記チャネル定義の各々が、それぞれの信頼可能性トランスポートパラメータ値を含み、該信頼可能性トランスポートパラメータ値が、前記それぞれのチャネル上のデータが、損失したデータパケットを再送信する信頼できるトランスポートプロトコルによって伝送されるか又は損失したデータパケットを棄却する信頼できないトランスポートプロトコルによって伝送されるかを示すものである、請求項３８に記載の方法。
  40. 前記送信ステップが、前記所与のクライアントネットワークノード(12)により、
    信頼できるトランスポートプロトコルによるチャネルでデータが伝送されることを示す信頼可能性トランスポート値によって定義される前記所与のセッションにおける前記チャネルの各々毎に、
    前記チャネルでデータパケットを送信し、
    送信されたデータパケットであってその受信が前記セッションパートナーのクライアントネットワークノード(14)によりアクノリッジされていないデータパケットの個数が、前記セッションパートナーのクライアントネットワークノードにより指定されたウィンドウしきい値を越えたという判定に応じて、前記送信されたデータパケットのそれぞれを前記チャネルで再送信する、
    という各ステップを含む、請求項３９に記載の方法。
  41. 前記送信ステップが、前記所与のクライアントネットワークノード(12)により、
    信頼できるトランスポートプロトコルによるチャネルでデータが伝送されることを示す信頼可能性トランスポート値によって定義される前記所与のセッションにおける前記チャネルの各々毎に、
    前記チャネルで送信したデータパケットを保持し、
    送信されたデータパケットが前記セッションパートナーのクライアントネットワークノード(14)により受信されたことのアクノリッジメントの受信に応じて、該送信されたデータパケットに対応する前記保持したデータバケットを解放する、
    という各ステップを含む、請求項４０に記載の方法。
  42. 前記所与のクライアントネットワークノード(12)により、
    送信ウィンドウサイズ番号及び受信ウィンドウサイズ番号を含むセッションメンテナンスメッセージを前記それぞれのセッションパートナーのクライアントネットワークノード(14)から受信し、
    送信されたデータパケットであって前記セッションパートナーのクライアントネットワークノード(14)によりその受信がアクノリッジされていない送信されたデータパケットが前記送信ウィンドウサイズ番号に達するまで、前記それぞれのセッションパートナーのクライアントネットワークノード(14)にデータパケットを送信し、
    先行するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノード(14)に送られた後に少なくとも前記受信ウィンドウサイズ番号のデータパケットを該セッションパートナーのクライアントネットワークノード(14)から受信したことに応答するそれぞれのセッションメンテナンスメッセージを前記それぞれのセッションパートナーのクライアントネットワークノード(14)に送信する、
    という各ステップを更に含む、請求項３６に記載の方法。
  43. 前記所与のクライアントネットワークノード(12)により送信される前記それぞれのセッションメンテナンスメッセージが、アクティブ状態にある複数のチャネルの各々毎に、該チャネルで受信されるパケットのそれぞれの最大パケットシーケンス番号の指示を含む、請求項４２に記載の方法。
  44. 前記それぞれのセッションパートナーのクライアントネットワークノード(14)から一連のデータパケットを受信し、その各データパケットが、それぞれの逐次のチャネルレベルのパケット番号とそれぞれの一意のセッションレベルのパケット識別子とを含み、
    前記セッションメンテナンスメッセージを送信する前記ステップが、前記それぞれのセッションパートナーのクライアントネットワークノード(14)へ送信される前記それぞれのセッションメンテナンスメッセージ内に、各チャネルで前記所与のクライアントネットワークノード(12)により処理されたデータパケットの逐次のパケット番号のうちの最高のパケット番号に対応する、各チャネル毎のそれぞれの値と、前記所与のセッションで複数のチャネルの全てにわたって前記所与のクライアントネットワークノード(12)により処理されたデータパケットのうち最も最近のデータパケットのそれぞれの一意のパケット識別子とを組み込むステップを含む、
    という各ステップを更に含む、請求項４２に記載の方法。
  45. 前記所与のクライアントネットワークノード(12)により送信された前記それぞれのセッションメンテナンスメッセージが、アクティブ状態にある各チャネル毎に、該チャネルで受信されていない損失パケットのそれぞれの識別子を含む、請求項４２に記載の方法。
  46. 前記所与のクライアントネットワークノード(12)により、
    第１時間パラメータ値及び第２時間パラメータ値を含むセッションメンテナンスメッセージを前記それぞれのセッションパートナーのクライアントネットワークノード(14)から受信し、
    前記所与のセッションがアクティブ状態にあるとの判定に応じて、パケット受信アクノリッジメントセッションメンテナンスメッセージを、前記第１時間パラメータ値により設定された最大間隔で前記セッションパートナーのクライアントネットワークノード(14)へ送信し、
    前記所与のセッションがアイドル状態にあるとの判定に応じて、パケット受信アクノリッジメントセッションメンテナンスメッセージを、前記第２時間パラメータ値により設定された最大間隔で前記セッションパートナーのクライアントネットワークノード(14)へ送信する、
    という各ステップを更に含む、請求項２０に記載の方法。
  47. 前記クライアントネットワークノード(12)により、
    ２つの連続するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノード(14)へ前記所与のクライアントネットワークノードにより送信される前に少なくとも１つのデータパケットが該セッションパートナーのクライアントネットワークノード(14)から受信されたとの判定に応じて、前記所与のセッションがアクティブ状態にあると判定し、
    ２つの連続するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノード(14)へ前記所与のクライアントネットワークノード(12)により送信される前に該セッションパートナーのクライアントネットワークノード(14)からデータパケットを全く受信していないとの判定に応じて、前記所与のセッションがアイドル状態にあると判定する、
    という各ステップを更に含む、請求項４６に記載の方法。
  48. 装置(12)であって、
    コンピュータ読み取り可能命令を格納しているコンピュータ読み取り可能メモリ(22)と、
    該メモリに接続されたデータ処理手段(24)であって、前記命令を実行するよう動作することが可能であり、及び該命令の実行に少なくとも部分的に基づいて、
    サーバネットワークノード(16)によりホストされているサーバアプリケーション(38)に接続し、該サーバネットワークノード(16)には１つ又は２つ以上の他のクライアントネットワークノード(14)が接続されており、所与のクライアントネットワークノード及び前記１つ又は２つ以上の他のクライアントネットワークノード(14)の各々が、それぞれのデータストリームコンテンツタイプの１つ又は２つ以上のソース及びシンクを有しており、
    前記他のクライアントネットワークノード(14)であって、該他のクライアントネットワークノードの前記１つ又は２つ以上のソース及びシンクのうちのアクティブなものと相補的な関係にある少なくとも１つのアクティブなソース又はシンクを前記所与のクライアントネットワークノードが有している、該他のクライアントネットワークノード(14)の各々毎に、該所与のクライアントネットワークノードと該他のクライアントネットワークノード(14)のうちのそれぞれのセッションパートである１つとの間のそれぞれのセッション定義を前記サーバネットワークノード(16)から受信し、
    該受信したセッション定義の各々毎に、該セッション定義に基づいて、該装置(12)と前記それぞれのセッションパートナーのクライアントネットワークノード(14)との間のそれぞれのネットワーク接続を介したそれぞれのピア・ツー・ピア・セッションを確立する、
    という各動作を実行するよう動作することが可能である、データ処理手段(24)と
    を備えている装置(12)。
  49. コンピュータ読み取り可能プログラムコードが内部に組み込まれた少なくとも１つのコンピュータ読み取り可能記憶装置(22)であって、該コンピュータ読み取り可能プログラムコードが、コンピュータ(12)により実行されて、
    サーバネットワークノード(16)によりホストされているサーバアプリケーション(38)に接続し、該サーバネットワークノード(16)には１つ又は２つ以上の他のクライアントネットワークノード(14)が接続されており、所与のクライアントネットワークノード及び前記１つ又は２つ以上の他のクライアントネットワークノード(14)の各々が、それぞれのデータストリームコンテンツタイプの１つ又は２つ以上のソース及びシンクを有しており、
    前記他のクライアントネットワークノード(14)であって、該他のクライアントネットワークノードの前記１つ又は２つ以上のソース及びシンクのうちのアクティブなものと相補的な関係にある少なくとも１つのアクティブなソース又はシンクを前記コンピュータ(12)が有している、該他のクライアントネットワークノード(14)の各々毎に、前記所与のクライアントネットワークノードと該他のクライアントネットワークノード(14)のうちのそれぞれのセッションパートである１つとの間のそれぞれのセッション定義を前記サーバネットワークノード(16)から受信し、
    該受信したセッション定義の各々毎に、該セッション定義に基づいて、前記コンピュータ(12)と前記それぞれのセッションパートナーのクライアントネットワークノード(14)との間のそれぞれのネットワーク接続を介したそれぞれのピア・ツー・ピア・セッションを確立する、
    という各ステップからなる方法を実施するよう構成されたものである、コンピュータ読み取り可能記憶装置(22)。
  50. 所与のクライアントネットワークノード(12)により、
    セッションパートナーのクライアントネットワークノード(14)とのそれぞれのネットワーク接続をネゴシエートするための複数のアドレスを格納し、
    セッション定義に関連付けられている前記複数のアドレスのそれぞれの全てについて前記セッションパートナーのクライアントネットワークノード(14)とのそれぞれのネットワーク接続の確立を試行する、
    という各ステップを含む方法。
  51. 前記所与のクライアントネットワークノード(12)により、
    前記セッションパートナーのクライアントネットワークノード(14)との複数の同時のネットワーク接続を成功裏に確立したことに応じて、該複数の同時のネットワーク接続のうちの１つを選択し、前記セッションパートナーのクライアントネットワークノード(14)と前記選択したネットワーク接続を介してそれぞれのセッションを確立する、
    という各ステップを更に含む、請求項５０に記載の方法。
  52. 前記所与のクライアントネットワークノード(12)により、
    前記セッションパートナーのクライアントネットワークノード(14)との前記複数の同時のネットワーク接続のうち未選択のネットワーク接続のうちの１つ又は２つ以上を、前記選択されたネットワーク接続を介して確立されたそれぞれのセッション中に存続させる、
    というステップを更に含む、請求項５１に記載の方法。
  53. 前記試行ステップが、前記所与のクライアントネットワークノード(12)により、
    １つ又は２つ以上の前記アドレスの各々について、及びプロキシサーバネットワークノード(16)のそれぞれのアドレスについて、前記セッションパートナーのクライアントネットワークノード(14)とのそれぞれのネットワーク接続の確立を試行する、
    というステップを含む、請求項５０に記載の方法。
  54. 前記所与のクライアントネットワークノード(12)により、
    前記セッションパートナーのクライアントネットワークノード(14)に割り当てられているそれぞれのステーション識別子を含む１つ又は２つ以上のインバウンドメッセージの各々からそれぞれのソースネットワークアドレスを抽出し、
    各々の非冗長の抽出されたソースネットワークアドレスを、前記セッションパートナーのクライアントネットワークノード(14)とのそれぞれのネットワーク接続をネゴシエートするためのそれぞれのアドレスとして格納する、
    という各ステップを更に含む、請求項５０に記載の方法。
  55. 所与のクライアントネットワークノード(12)により実施される方法であって、
    セッションパートナーのクライアントネットワークノード(14)とのネットワーク接続を確立し、該確立ステップが、
    前記所与のクライアントネットワークノード(12)に割り当てられている一意のステーション識別子を含むアウトバウンドメッセージを前記セッションパートナーのクライアントネットワークノード(14)に送信し、
    前記アウトバウンドメッセージに応答するインバウンドメッセージであって、前記セッションパートナーのクライアントネットワークノード(14)に割り当てられている一意のステーション識別子を含むインバウンドメッセージを受信したことに応じて、該インバウンドメッセージからソースネットワークアドレスを抽出し、該抽出したソースネットワークアドレスに前記セッションパートナーのクライアントネットワークノード(14)をバインドする、
    という各ステップを含む、所与のクライアントネットワークノード(12)により実施される方法。
  56. 前記所与のクライアントネットワークノード(12)により、
    前記それぞれのセッションパートナーのクライアントネットワークノード(14)がバインドされた前記ネットワークアドレスにアドレス指定されたトランスポートストリームを介して、該セッションパートナーのクライアントネットワークノード(14)とのセッションに割り当てられた一意のセッション識別子を含む別のアウトバウンドメッセージを送信し、
    該別のアウトバウンドメッセージに応じたインバウンドメッセージであって、前記それぞれのセッションに割り当てられた一意のセッション識別子を含むインバウンドメッセージを受信したことに応じて、前記トランスポートストリームを、前記それぞれのセッションでデータを送信するのに有効なものとして指定する、
    という各ステップを更に含む、請求項５５に記載の方法。
  57. 所与のクライアントネットワークノード(12)により実施される方法であって、
    セッションパートナーのクライアントネットワークノード(14)とピア・ツー・ピア・セッションを確立し、
    該確立されたピア・ツー・ピア・セッションで、前記所与のクライアントネットワークノード(12)から利用することが可能な複数のローカル公開チャネルを公開し、該チャネルが、データストリームコンテンツタイプによりピア・ツー・ピア・セッションで伝送されるデータを論理的に分割するものである、
    という各ステップを含む、所与のクライアントネットワークノード(12)により実施される方法。
  58. 前記所与のクライアントネットワークノード(12)により、
    前記確立されたピア・ツー・ピア・セッションで前記複数のローカル公開チャネルのうちの所与の１つを購読する要求を受信したことに応じて、該所与のローカル公開チャネルに関連付けられているデータを前記セッションパートナーのクライアントネットワークノード(14)に送信する、
    というステップを更に含む、請求項５７に記載の方法。
  59. 前記所与のクライアントネットワークノード(12)により、
    該所与のクライアントネットワークノード(12)上の１つ又は２つ以上のローカルソフトウェアエンティティに関連付けられているローカル購読チャネルを決定し、
    前記確立されたピア・ツー・ピア・セッションで１つ又は２つ以上のリモート公開チャネルの公開を受信したことに応じて、該リモート公開チャネルのそれぞれに対応するローカル購読チャネルの各々を購読する要求を前記セッションパートナーのクライアントネットワークノード(14)に送信する、
    という各ステップを更に含む、請求項５７に記載の方法。
  60. 前記所与のクライアントネットワークノード(12)により、
    前記ローカル購読チャネルのそれぞれに対応する前記リモート公開チャネルのそれぞれにおいて前記ピア・ツー・ピア・セッションでデータを受信したことに応じて、該受信したデータを、前記対応するローカル購読チャネルに関連付けられているローカルソフトウェアエンティティの各々に渡す、
    というステップを更に含む、請求項５９に記載の方法。
  61. 所与のクライアントネットワークノード(12)により実施される方法であって、
    セッションパートナーのクライアントネットワークノード(14)とピア・ツー・ピア・セッションを確立し、
    データストリームコンテンツタイプにより前記ピア・ツー・ピア・セッションで伝送されるデータを論理的に分割するそれぞれのチャネルの定義を格納し、
    データストリームのコンテンツタイプに従ってそれぞれのチャネルにおいてピア・ツー・ピア・セッションで前記セッションパートナーのクライアントネットワークノード(14)にデータストリームを送信する、
    という各ステップを含む、所与のクライアントネットワークノード(12)により実施される方法。
  62. 前記チャネル定義の各々が、前記それぞれのチャネルに割り当てられているそれぞれのデータストリームコンテンツタイプを識別するそれぞれの一意のコンテンツ識別子を含み、前記送信ステップが、前記データストリームの前記コンテンツタイプに対応する複数の前記コンテンツ識別子のうちの１つをそれぞれ含むパケットという形で前記データストリームの各々を前記複数のチャネルのそれぞれの１つで送信するステップを含む、請求項６１に記載の方法。
  63. 前記チャネル定義の各々が、それぞれのチャネルでのデータの伝送を、前記所与のセッションにおける他の任意のチャネルでのデータの伝送とは無関係に制御する、１つ又は２つ以上のトランスポートパラメータ値からなるそれぞれの組を含む、請求項６１に記載の方法。
  64. 前記送信ステップが、前記所与のクライアントネットワークノード(12)により、
    信頼できるトランスポートプロトコルによるチャネルでデータが伝送されることを示す信頼可能性トランスポート値によって定義される前記ピア・ツー・ピア・セッションにおける前記チャネルの各々毎に、
    前記チャネルでデータパケットを送信し、
    送信されたデータパケットであって前記セッションパートナーのクライアントネットワークノード(14)によりその受信がアクノリッジされていないデータパケットの個数が、該セッションパートナーのクライアントネットワークノード(14)により指定されたウィンドウしきい値を越えたという判定に応じて、前記送信されたデータパケットのそれぞれを前記チャネルで再送信する、
    という各ステップを含む、請求項６３に記載の方法。
  65. 前記送信ステップが、前記所与のクライアントネットワークノード(12)により、
    信頼できるトランスポートプロトコルによるチャネルでデータが伝送されることを示す信頼可能性トランスポート値によって定義される前記ピア・ツー・ピア・セッションにおける前記チャネルの各々毎に、
    前記チャネルで送信したデータパケットを保持し、
    送信したデータパケットが前記セッションパートナーのクライアントネットワークノード(14)により受信されたことのアクノリッジメントの受信に応じて、該データパケットに対応する前記保持したデータバケットを解放する、
    という各ステップを含む、請求項６４に記載の方法。
  66. 前記所与のクライアントネットワークノード(12)により、
    送信ウィンドウサイズ番号及び受信ウィンドウサイズ番号を含むセッションメンテナンスメッセージを前記セッションパートナーのクライアントネットワークノード(14)から受信し、
    送信されたデータパケットであって前記セッションパートナーのクライアントネットワークノード(14)によりその受信がアクノリッジされていない送信されたデータパケットが前記送信ウィンドウサイズ番号に達するまで、該セッションパートナーのクライアントネットワークノード(14)にデータパケットを送信し、
    先行するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノード(14)に送られた後に少なくとも前記受信ウィンドウサイズ番号のデータパケットを該セッションパートナーのクライアントネットワークノード(14)から受信したことに応答するそれぞれのセッションメンテナンスメッセージを該セッションパートナーのクライアントネットワークノード(14)に送信する、
    という各ステップを更に含む、請求項６１に記載の方法。
  67. 前記所与のクライアントネットワークノード(12)により送信される前記セッションメンテナンスメッセージが、アクティブ状態にある複数のチャネルの各々毎に、該チャネルで受信されるパケットのそれぞれの最大パケットシーケンス番号の指示を含む、請求項６６に記載の方法。
  68. 前記それぞれのセッションパートナーのクライアントネットワークノード(14)から一連のデータパケットを受信し、その各データパケットが、それぞれの逐次のチャネルレベルのパケット番号とそれぞれの一意のセッションレベルのパケット識別子とを含み、前記セッションメンテナンスメッセージを送信する前記ステップが、前記それぞれのセッションパートナーのクライアントネットワークノード(14)へ送信される前記それぞれのセッションメンテナンスメッセージ内に、前記チャネルで前記所与のクライアントネットワークノード(12)により処理されたデータパケットの逐次のパケット番号のうちの最高のパケット番号に対応する、各チャネル毎のそれぞれの値と、所与のセッションで複数のチャネルの全てにわたって前記所与のクライアントネットワークノード(12)により処理されたデータパケットのうち最も最近のデータパケットのそれぞれの一意のパケット識別子とを組み込むステップを含む、という各ステップを更に含む、請求項６６に記載の方法。
  69. 前記所与のクライアントネットワークノード(12)により送信された前記セッションメンテナンスメッセージが、アクティブ状態にある各チャネル毎に、該チャネルで受信されていない損失パケットのそれぞれの識別子を含む、請求項６６に記載の方法。
  70. 所与のクライアントネットワークノード(12)により実施される方法であって、
    セッションパートナーのクライアントネットワークノード(14)とピア・ツー・ピア・セッションを確立し、
    第１時間パラメータ値及び第２時間パラメータ値を含むセッションメンテナンスメッセージを前記セッションパートナーのクライアントネットワークノード(14)から受信し、
    前記ピア・ツー・ピア・セッションがアクティブ状態にあるとの判定に応じて、パケット受信アクノリッジメントセッションメンテナンスメッセージを、前記第１時間パラメータ値により設定された最大間隔で前記セッションパートナーのクライアントネットワークノード(14)へ送信し、
    前記ピア・ツー・ピア・セッションがアイドル状態にあるとの判定に応じて、パケット受信アクノリッジメントセッションメンテナンスメッセージを、前記第２時間パラメータ値により設定された最大間隔で前記セッションパートナーのクライアントネットワークノード(14)へ送信する、
    という各ステップを含む、所与のクライアントネットワークノード(12)により実施される方法。
  71. 前記クライアントネットワークノード(12)により、
    ２つの連続するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノード(14)へ前記所与のクライアントネットワークノード(12)により送信される前に少なくとも１つのデータパケットが該セッションパートナーのクライアントネットワークノード(14)から受信されたとの判定に応じて、前記ピア・ツー・ピア・セッションがアクティブ状態にあると判定し、
    ２つの連続するセッションメンテナンスメッセージが前記セッションパートナーのクライアントネットワークノード(14)へ前記所与のクライアントネットワークノード(12)により送信される前に該セッションパートナーのクライアントネットワークノード(14)からデータパケットを全く受信していないとの判定に応じて、前記所与のセッションがアイドル状態にあると判定する、
    という各ステップを更に含む、請求項７０に記載の方法。
JP2013502658A 2010-03-26 2011-03-24 ネットワークノード間のネットワーク通信の管理及びストリームトランスポートプロトコル Withdrawn JP2013524632A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US31815610P 2010-03-26 2010-03-26
US61/318,156 2010-03-26
US12/825,512 US8732236B2 (en) 2008-12-05 2010-06-29 Managing network communications between network nodes and stream transport protocol
US12/825,512 2010-06-29
PCT/US2011/029723 WO2011119793A2 (en) 2010-03-26 2011-03-24 Managing network communications between network nodes and stream transport protocol

Publications (1)

Publication Number Publication Date
JP2013524632A true JP2013524632A (ja) 2013-06-17

Family

ID=44673862

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013502658A Withdrawn JP2013524632A (ja) 2010-03-26 2011-03-24 ネットワークノード間のネットワーク通信の管理及びストリームトランスポートプロトコル

Country Status (6)

Country Link
US (1) US8732236B2 (ja)
EP (1) EP2553874A2 (ja)
JP (1) JP2013524632A (ja)
KR (1) KR20120136371A (ja)
CN (1) CN102823196A (ja)
WO (1) WO2011119793A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5734525B2 (ja) * 2012-12-11 2015-06-17 ＶｉｅｗＳｅｎｄ ＩＣＴ株式会社 医療支援システムおよびその方法

Families Citing this family (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8397168B2 (en) * 2008-04-05 2013-03-12 Social Communications Company Interfacing with a spatial virtual communication environment
US7769806B2 (en) 2007-10-24 2010-08-03 Social Communications Company Automated real-time data stream switching in a shared virtual area communication environment
US8407605B2 (en) 2009-04-03 2013-03-26 Social Communications Company Application sharing
US20130073978A1 (en) * 2011-09-16 2013-03-21 Social Communications Company Capabilities based management of virtual areas
US8191001B2 (en) 2008-04-05 2012-05-29 Social Communications Company Shared virtual area communication environment based apparatus and methods
US9514444B2 (en) 2009-01-15 2016-12-06 Sococo, Inc. Encapsulating virtual area based communicant assemblies
US9853922B2 (en) 2012-02-24 2017-12-26 Sococo, Inc. Virtual area communications
US9319357B2 (en) 2009-01-15 2016-04-19 Social Communications Company Context based virtual area creation
US20130283169A1 (en) 2012-04-24 2013-10-24 Social Communications Company Voice-based virtual area navigation
US8738780B2 (en) * 2009-01-22 2014-05-27 Citrix Systems, Inc. System and method for hybrid communication mechanism utilizing both communication server-based and direct endpoint-to-endpoint connections
CN101854311A (zh) * 2009-03-31 2010-10-06 国际商业机器公司 在web服务器上传递上下文信息的方法和装置
US8629866B2 (en) * 2009-06-18 2014-01-14 International Business Machines Corporation Computer method and apparatus providing interactive control and remote identity through in-world proxy
EP2556480A4 (en) 2010-04-07 2014-05-28 Hewlett Packard Development Co DEVICE MESSAGING
US8990411B2 (en) * 2010-04-22 2015-03-24 Microsoft Technology Licensing, Llc Dynamic connection management on mobile peer devices
US9276972B2 (en) * 2010-12-14 2016-03-01 Microsoft Technology Licensing, Llc Real-time media optimization over remoted sessions
US8655955B2 (en) 2011-08-18 2014-02-18 International Business Machines Corporation Stream processing using a client-server architecture
US9330154B2 (en) * 2011-08-22 2016-05-03 Sybase, Inc. Multicast database replication
US9036185B2 (en) 2011-09-28 2015-05-19 Hewlett-Packard Development Company, L.P. Managing network connections
WO2013078062A1 (en) * 2011-11-23 2013-05-30 Social Communications Company Creating and managing virtual areas
CN102611947B (zh) * 2011-11-24 2017-11-17 中兴通讯股份有限公司 创建组播频道的方法、系统和媒体服务器
JP5887507B2 (ja) * 2011-11-28 2016-03-16 パナソニックＩｐマネジメント株式会社 通信機器間の接続確立方法、通信機器、及びサーバ装置
US9374613B2 (en) * 2011-12-07 2016-06-21 Verizon Patent And Licensing Inc. Media content flicking systems and methods
JP6340668B2 (ja) 2012-02-29 2018-06-13 グローバル ファイル システムズ ホールディングス、エルエルシー ストリーム認識およびフィルタリング
KR101758681B1 (ko) * 2012-03-27 2017-07-14 한화테크윈 주식회사 통신 시스템 및 통신 시스템에서의 데이터 송수신 방법
WO2013181026A1 (en) 2012-06-02 2013-12-05 Social Communications Company Interfacing with a spatial virtual communications environment
US10009445B2 (en) * 2012-06-14 2018-06-26 Qualcomm Incorporated Avoiding unwanted TCP retransmissions using optimistic window adjustments
US10452769B1 (en) 2012-08-31 2019-10-22 United Services Automobile Association (Usaa) Concurrent display of application between devices
US9146790B1 (en) * 2012-11-02 2015-09-29 Symantec Corporation Performing fencing operations in multi-node distributed storage systems
CN103034615B (zh) * 2012-12-07 2016-04-13 无锡美森微电子科技有限公司 一种适用于流应用多核处理器的存储管理方法
US9549024B2 (en) 2012-12-07 2017-01-17 Remote Media, Llc Routing and synchronization system, method, and manager
KR102070727B1 (ko) * 2013-02-13 2020-01-29 삼성전자주식회사 무선 통신 시스템의 전송 제어 프로토콜 통신 방법 및 장치
CN105191272B (zh) * 2013-05-05 2018-02-23 领特德国公司 使用准备加入群组来训练经向量化系统中的多个线路的优化
CN104469949B (zh) * 2013-09-23 2018-10-12 中国移动通信集团公司 无线网络中的保活方法、装置及系统
US10516735B2 (en) * 2013-10-08 2019-12-24 Iotic Labs Limited Internet of things
US9398058B2 (en) * 2013-10-28 2016-07-19 Instamedica Inc. Systems and methods for video-conference network system suitable for scalable, private tele-consultation
US9558148B2 (en) * 2014-04-30 2017-01-31 Intel Corporation Method to optimize network data flows within a constrained system
EP2990970A1 (en) * 2014-08-26 2016-03-02 Dassault Systèmes Execution of sequential update
EP2990969A1 (en) * 2014-08-26 2016-03-02 Dassault Systèmes Criterion for sequential update
US9665340B2 (en) * 2014-10-13 2017-05-30 Daniel Kuniansky Systems and methods for temporarily sharing audio over a network
CN104284237A (zh) * 2014-10-13 2015-01-14 中安消技术有限公司 视频传输方法及系统
WO2016073315A1 (en) * 2014-11-05 2016-05-12 NCS Technologies, Inc. Zero client device with cached connections
US9646163B2 (en) 2014-11-14 2017-05-09 Getgo, Inc. Communicating data between client devices using a hybrid connection having a regular communications pathway and a highly confidential communications pathway
WO2016081809A1 (en) * 2014-11-20 2016-05-26 Superchat, LLC Multi-network chat system
US10219242B2 (en) * 2015-01-20 2019-02-26 Futurewei Technologies, Inc. System and method for delivering notifications
US9701135B2 (en) * 2015-01-30 2017-07-11 S-Printing Solution Co., Ltd. Image forming apparatus, recording medium, terminal, server, note printing method, and storage medium
US10402372B2 (en) 2015-07-27 2019-09-03 Sas Institute Inc. Distributed data storage grouping
CN105072050A (zh) * 2015-08-26 2015-11-18 联想(北京)有限公司 一种数据传输方法及装置
TWI584617B (zh) * 2015-11-18 2017-05-21 Walton Advanced Eng Inc Auxiliary data transmission
CN106547529A (zh) * 2015-09-23 2017-03-29 百度在线网络技术（北京）有限公司 页面构建方法及装置
US10412088B2 (en) * 2015-11-09 2019-09-10 Silvercar, Inc. Vehicle access systems and methods
CN105721491B (zh) * 2016-03-22 2018-10-26 同济大学 一种用于面向高速磁浮交通仿真的通信方法
US10264314B2 (en) * 2016-04-29 2019-04-16 Pccw Vuclip (Singapore) Pte. Ltd. Multimedia content management system
US10609093B2 (en) * 2016-05-06 2020-03-31 Facebook, Inc. Instantaneous call sessions over a communications application
WO2017210209A1 (en) * 2016-05-31 2017-12-07 Brocade Communications Systems, Inc. Keepalive scheduler in a network device
CN107579949B (zh) * 2016-07-05 2021-05-28 阿里巴巴集团控股有限公司 数据报文处理方法及装置
US11075886B2 (en) * 2016-12-15 2021-07-27 Keysight Technologies Singapore (Sales) Pte. Ltd. In-session splitting of network traffic sessions for server traffic monitoring
WO2018213481A1 (en) * 2017-05-16 2018-11-22 Sportscastr.Live Llc Systems, apparatus, and methods for scalable low-latency viewing of integrated broadcast commentary and event video streams of live events, and synchronization of event information with viewed streams via multiple internet channels
US10404810B2 (en) 2017-06-20 2019-09-03 Futurewei Technologies, Inc. Session layer communications using an ID-oriented network
US20190141009A1 (en) * 2017-11-07 2019-05-09 General Electric Company Session moderator for turn-pattern tcp-packet relay with websocket instantiation
JP7032652B2 (ja) * 2018-08-03 2022-03-09 日本電信電話株式会社 仮想世界構築システム及び方法
CN110958151B (zh) * 2018-09-26 2023-06-23 上海欣诺通信技术股份有限公司 保活检测方法、装置、节点、存储介质及通信系统
US10964158B2 (en) * 2018-10-05 2021-03-30 Jcm American Corporation Apparatus for retrofit of auxiliary serial communication port(s) in a slot accounting system
US20220053033A1 (en) * 2018-11-13 2022-02-17 Sony Corporation Methods and devices for establishing a streaming session in a framework for live uplink streaming
CN109861790B (zh) * 2019-01-16 2022-04-19 顺丰科技有限公司 数据传输方法和装置
US20220200973A1 (en) * 2019-04-15 2022-06-23 Bear System, LLC Blockchain schema for secure data transmission
US11483143B2 (en) * 2019-04-15 2022-10-25 Smart Security Systems, Llc Enhanced monitoring and protection of enterprise data
CN112187414B (zh) * 2019-07-04 2022-05-24 华为技术有限公司 指示数据传输情况的方法和装置
CN110442366B (zh) * 2019-08-09 2021-06-15 广州视源电子科技股份有限公司 一种传屏处理方法、装置、设备和存储介质
US11297147B2 (en) * 2019-11-22 2022-04-05 Amazon Technologies, Inc. Managed data export to a remote network from edge devices
US11463547B2 (en) * 2019-12-12 2022-10-04 Google Llc Reliable transport protocol and hardware architecture for datacenter networking
CN111800311B (zh) * 2020-06-22 2021-10-08 中科边缘智慧信息科技（苏州）有限公司 分散计算状态实时感知方法
US11349937B2 (en) * 2020-09-18 2022-05-31 EMC IP Holding Company LLC Passive management of network connections
KR20220074108A (ko) * 2020-11-27 2022-06-03 삼성전자주식회사 전자 장치 및 그의 동작 방법
US11811877B2 (en) 2021-05-13 2023-11-07 Agora Lab, Inc. Universal transport framework for heterogeneous data streams
US11842190B2 (en) * 2022-01-18 2023-12-12 Lemon Inc. Synchronizing multiple instances of projects

Family Cites Families (118)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US1615973A (en) 1923-11-17 1927-02-01 Marietta Mfg Company Process of coloring glassware
US5193151A (en) * 1989-08-30 1993-03-09 Digital Equipment Corporation Delay-based congestion avoidance in computer networks
AU650242B2 (en) * 1989-11-28 1994-06-16 International Business Machines Corporation Methods and apparatus for dynamically managing input/output (I/O) connectivity
US6594688B2 (en) * 1993-10-01 2003-07-15 Collaboration Properties, Inc. Dedicated echo canceler for a workstation
US5434913A (en) * 1993-11-24 1995-07-18 Intel Corporation Audio subsystem for computer-based conferencing system
US6343263B1 (en) * 1994-08-02 2002-01-29 Apple Computer, Inc. Real-time signal processing system for serially transmitted data
US5721922A (en) * 1994-10-13 1998-02-24 Intel Corporation Embedding a real-time multi-tasking kernel in a non-real-time operating system
US5903752A (en) * 1994-10-13 1999-05-11 Intel Corporation Method and apparatus for embedding a real-time multi-tasking kernel in a non-real-time operating system
US5619733A (en) * 1994-11-10 1997-04-08 International Business Machines Corporation Method and apparatus for synchronizing streaming and non-streaming multimedia devices by controlling the play speed of the non-streaming device in response to a synchronization signal
US6260057B1 (en) * 1995-03-01 2001-07-10 Sun Microsystems, Inc. Apparatus and method for high performance implementation of system calls
US6466962B2 (en) * 1995-06-07 2002-10-15 International Business Machines Corporation System and method for supporting real-time computing within general purpose operating systems
US5960173A (en) * 1995-12-22 1999-09-28 Sun Microsystems, Inc. System and method enabling awareness of others working on similar tasks in a computer work environment
IL116708A (en) * 1996-01-08 2000-12-06 Smart Link Ltd Real-time task manager for a personal computer
US6405255B1 (en) * 1996-07-01 2002-06-11 Sun Microsystems, Inc. Mixing and splitting multiple independent audio data streams in kernel space
US5913038A (en) * 1996-12-13 1999-06-15 Microsoft Corporation System and method for processing multimedia data streams using filter graphs
US5995745A (en) * 1996-12-23 1999-11-30 Yodaiken; Victor J. Adding real-time support to general purpose operating systems
US6317774B1 (en) * 1997-01-09 2001-11-13 Microsoft Corporation Providing predictable scheduling of programs using a repeating precomputed schedule
US6006279A (en) 1997-01-21 1999-12-21 Canon Information Systems, Inc. Plug-in module host framework
US6771594B1 (en) * 1997-03-31 2004-08-03 Intel Corporation Reliable/non-reliable transmission of voice using TCP/UDP based on network quality of service
US6016515A (en) * 1997-04-04 2000-01-18 Microsoft Corporation Method, computer program product, and data structure for validating creation of and routing messages to file object
US6273622B1 (en) * 1997-04-15 2001-08-14 Flash Networks, Ltd. Data communication protocol for maximizing the performance of IP communication links
US6076114A (en) * 1997-04-18 2000-06-13 International Business Machines Corporation Methods, systems and computer program products for reliable data transmission over communications networks
US5991836A (en) * 1997-05-02 1999-11-23 Network Computing Devices, Inc. System for communicating real time data between client device and server utilizing the client device estimating data consumption amount by the server
US5991402A (en) * 1997-09-23 1999-11-23 Aegisoft Corporation Method and system of dynamic transformation of encrypted material
US6349344B1 (en) * 1997-12-16 2002-02-19 Microsoft Corporation Combining multiple java class files into a run-time image
US6216173B1 (en) * 1998-02-03 2001-04-10 Redbox Technologies Limited Method and apparatus for content processing and routing
US6148336A (en) * 1998-03-13 2000-11-14 Deterministic Networks, Inc. Ordering of multiple plugin applications using extensible layered service provider with network traffic filtering
US6141686A (en) * 1998-03-13 2000-10-31 Deterministic Networks, Inc. Client-side application-classifier gathering network-traffic statistics and application and user names using extensible-service provider plugin for policy-based network control
US7065553B1 (en) * 1998-06-01 2006-06-20 Microsoft Corporation Presentation system with distributed object oriented multi-user domain and separate view and model objects
US6324564B1 (en) * 1998-06-02 2001-11-27 Nettech Systems, Inc. Optimized wireless communication system
US6243753B1 (en) * 1998-06-12 2001-06-05 Microsoft Corporation Method, system, and computer program product for creating a raw data channel form an integrating component to a series of kernel mode filters
US6604136B1 (en) * 1998-06-27 2003-08-05 Intel Corporation Application programming interfaces and methods enabling a host to interface with a network processor
US7159222B1 (en) * 1998-09-09 2007-01-02 Microsoft Corporation Highly componentized system architecture with object mutation
US6807667B1 (en) * 1998-09-21 2004-10-19 Microsoft Corporation Method and system of an application program interface for abstracting network traffic control components to application programs
US6182125B1 (en) * 1998-10-13 2001-01-30 3Com Corporation Methods for determining sendable information content based on a determined network latency
US6219706B1 (en) * 1998-10-16 2001-04-17 Cisco Technology, Inc. Access control for networks
US6470397B1 (en) * 1998-11-16 2002-10-22 Qlogic Corporation Systems and methods for network and I/O device drivers
US6549538B1 (en) * 1998-12-31 2003-04-15 Compaq Information Technologies Group, L.P. Computer method and apparatus for managing network ports cluster-wide using a lookaside list
US6490611B1 (en) 1999-01-28 2002-12-03 Mitsubishi Electric Research Laboratories, Inc. User level scheduling of inter-communicating real-time tasks
US6862735B1 (en) * 1999-02-11 2005-03-01 Sun Microsystems, Inc. Mechanism by which platform independent software may bind to and access platform dependent software
US6615278B1 (en) * 1999-03-29 2003-09-02 International Business Machines Corporation Cross-platform program, system, and method having a global registry object for mapping registry equivalent functions in an OS/2 operating system environment
US6493324B1 (en) * 1999-03-29 2002-12-10 Worldcom, Inc. Multimedia interface for IP telephony
US6779027B1 (en) * 1999-04-30 2004-08-17 Hewlett-Packard Development Company, L.P. Intelligent management module application programming interface with utility objects
US6438603B1 (en) * 1999-04-30 2002-08-20 Microsoft Corporation Methods and protocol for simultaneous tuning of reliable and non-reliable channels of a single network communication link
US6587875B1 (en) * 1999-04-30 2003-07-01 Microsoft Corporation Network protocol and associated methods for optimizing use of available bandwidth
US6742176B1 (en) * 1999-06-14 2004-05-25 Lycos, Inc. Secure flexible plugin software architecture
US20010044904A1 (en) * 1999-09-29 2001-11-22 Berg Ryan J. Secure remote kernel communication
US7140015B1 (en) 1999-09-29 2006-11-21 Network Appliance, Inc. Microkernel for real time applications
US7213054B2 (en) * 1999-12-15 2007-05-01 Microsoft Corporation Methods and apparatuses for handling single-user applications in multi-user computing environments
SE517156C2 (sv) * 1999-12-28 2002-04-23 Global Ip Sound Ab System för överföring av ljud över paketförmedlade nät
US7197017B1 (en) * 2000-01-04 2007-03-27 Qualcomm, Incorporated Method and apparatus for channel optimization during point-to-point protocol (PPP) session requests
US7069590B1 (en) * 2000-02-17 2006-06-27 Microsoft Corporation System and method for protecting data streams in hardware components
US6990669B1 (en) * 2000-03-21 2006-01-24 Microsoft Corporation Real-time scheduler
US6871345B1 (en) * 2000-04-04 2005-03-22 Motive, Inc. Self managing software agents with introspection
US8020176B2 (en) * 2000-04-06 2011-09-13 Infineon Technologies Ag Virtual machine interface for hardware reconfigurable and software programmable processors
US6646195B1 (en) * 2000-04-12 2003-11-11 Microsoft Corporation Kernel-mode audio processing modules
US6961631B1 (en) * 2000-04-12 2005-11-01 Microsoft Corporation Extensible kernel-mode audio processing architecture
EP1170673A1 (en) 2000-07-05 2002-01-09 Sony International (Europe) GmbH Portal application
US6763176B1 (en) * 2000-09-01 2004-07-13 Matrox Electronic Systems Ltd. Method and apparatus for real-time video editing using a graphics processor
US7599753B2 (en) * 2000-09-23 2009-10-06 Microsoft Corporation Systems and methods for running priority-based application threads on a realtime component
US7263550B1 (en) * 2000-10-10 2007-08-28 Juniper Networks, Inc. Agent-based event-driven web server architecture
US7203741B2 (en) 2000-10-12 2007-04-10 Peerapp Ltd. Method and system for accelerating receipt of data in a client-to-client network
US7313593B1 (en) 2000-10-24 2007-12-25 International Business Machines Corporation Method and apparatus for providing full duplex and multipoint IP audio streaming
US6961942B1 (en) * 2000-11-06 2005-11-01 Microsoft Corporation Bluetooth TDI and winsock interface
US7149314B2 (en) 2000-12-04 2006-12-12 Creative Technology Ltd Reverberation processor based on absorbent all-pass filters
US20020080822A1 (en) * 2000-12-22 2002-06-27 Brown Michael K. Address defined session management over stateless communications channels
US7296226B2 (en) 2001-02-15 2007-11-13 Accenture Gmbh XML-based multi-format business services design pattern
US7386356B2 (en) * 2001-03-05 2008-06-10 Microsoft Corporation Dynamic audio buffer creation
US7376475B2 (en) * 2001-03-05 2008-05-20 Microsoft Corporation Audio buffer configuration
US7107110B2 (en) 2001-03-05 2006-09-12 Microsoft Corporation Audio buffers with audio effects
US20020165973A1 (en) * 2001-04-20 2002-11-07 Doron Ben-Yehezkel Adaptive transport protocol
US6996832B2 (en) * 2001-05-30 2006-02-07 Bea Systems, Inc. System and method for software component plug-in framework
US7562306B2 (en) 2001-05-31 2009-07-14 International Business Machines Corporation System and method for reducing memory use associated with the graphical representation of a list control
US6918093B2 (en) * 2001-05-31 2005-07-12 International Business Machines Corp. Inheritance of background color in a containment hierarchy of objects in a graphical user interface
US7017162B2 (en) * 2001-07-10 2006-03-21 Microsoft Corporation Application program interface for network software platform
US7254610B1 (en) * 2001-09-19 2007-08-07 Cisco Technology, Inc. Delivery of services to a network enabled telephony device based on transfer of selected model view controller objects to reachable network nodes
US7254814B1 (en) * 2001-09-28 2007-08-07 Emc Corporation Methods and apparatus for managing plug-in services
US7987491B2 (en) * 2002-05-10 2011-07-26 Richard Reisman Method and apparatus for browsing using alternative linkbases
US7631318B2 (en) * 2002-06-28 2009-12-08 Microsoft Corporation Secure server plug-in architecture for digital rights management systems
US6782424B2 (en) * 2002-08-23 2004-08-24 Finite State Machine Labs, Inc. System, method and computer program product for monitoring and controlling network connections from a supervisory operating system
US20040064210A1 (en) * 2002-10-01 2004-04-01 Puryear Martin G. Audio driver componentization
US20080242327A1 (en) * 2002-10-17 2008-10-02 Gabriel Manny M System and method for sending sms and text messages
CN100463469C (zh) * 2002-10-25 2009-02-18 国际商业机器公司 在多通道上共享应用程序会话信息的方法、装置和系统
US20040088704A1 (en) * 2002-10-30 2004-05-06 Advanced Simulation Technology, Inc. Method for running real-time tasks alongside a general purpose operating system
DE60325099D1 (de) * 2003-01-16 2009-01-15 Research In Motion Ltd System und verfahren zum austausch von identifizierungsinformation für mobile stationen
US20060253539A1 (en) * 2003-08-07 2006-11-09 Simple Com Tools, Llc Realtime electronic communications system and method
US20050060137A1 (en) * 2003-09-12 2005-03-17 Lanus Mark S. Method and apparatus to emulate an execution environment
ATE423417T1 (de) * 2003-10-27 2009-03-15 Nokia Corp Verfahren und einrichtung für weitergeleitete peer-to-peer-kommunikation zwischen endgeräten in mobil-netzwerken
JP2005196286A (ja) * 2003-12-26 2005-07-21 Okuma Corp リアルタイムアプリケーションプログラムを動作可能なオペレーティングシステム及びその制御方法、共有ライブラリをロードする方法
US20060031779A1 (en) 2004-04-15 2006-02-09 Citrix Systems, Inc. Selectively sharing screen data
US20070192818A1 (en) * 2004-10-12 2007-08-16 Mikael Bourges-Sevenier System and method for creating, distributing, and executing rich multimedia applications
US20060168114A1 (en) * 2004-11-12 2006-07-27 Arnaud Glatron Audio processing system
JP2008530835A (ja) 2005-02-08 2008-08-07 テレフオンアクチーボラゲット エル エム エリクソン（パブル） パケット交換ネットワーク上のオンデマンドマルチチャネルストリーミングセッション
US20070043804A1 (en) * 2005-04-19 2007-02-22 Tino Fibaek Media processing system and method
US20070064851A1 (en) * 2005-09-02 2007-03-22 Sbc Knowledge Ventures Lp Method for synchronizing a customer edge router or customer premise equipment associated therewith
US20060244818A1 (en) * 2005-04-28 2006-11-02 Comotiv Systems, Inc. Web-based conferencing system
US8606950B2 (en) * 2005-06-08 2013-12-10 Logitech Europe S.A. System and method for transparently processing multimedia data
ATE550756T1 (de) * 2005-08-04 2012-04-15 Nuance Communications Inc Sprachdialogsystem
EP1938184A4 (en) * 2005-08-19 2009-12-02 Google Inc SOFTWARE ARCHITECTURE FOR DISPLAYING INFORMATION CONTENT FROM PLUG-IN MODULES ON A USER INTERFACE
US7509654B2 (en) * 2005-09-29 2009-03-24 Avaya Inc. Data-driven and plug-in defined event engine
US8498629B2 (en) * 2005-10-18 2013-07-30 Harris Corporation Extensible human machine interface (HMI) plugin architecture for radio software system and related method
US20070240134A1 (en) * 2006-02-28 2007-10-11 Joydeep Buragohain Software packaging model supporting multiple entity types
US8374191B2 (en) 2006-03-14 2013-02-12 Nokia Corporation Allocation of a communications channel to a data transfer session
US20070250540A1 (en) * 2006-04-20 2007-10-25 Hsu Mike S C A Computer System with File Attribute Extension
ATE527810T1 (de) 2006-05-11 2011-10-15 Global Ip Solutions Gips Ab Tonmischung
US20070280206A1 (en) 2006-05-31 2007-12-06 Samsung Electronics Co., Ltd. Method for consuming heterogeneous services on heterogeneous devices using script plugins
US7643459B2 (en) * 2006-06-16 2010-01-05 Alcatel-Lucent Usa Inc. Methods, devices and architectures for establishing peer-to-peer sessions
US20080005721A1 (en) * 2006-06-29 2008-01-03 Augusta Systems, Inc. Method and System for Rapidly Developing Sensor-Enabled Software Applications
US8798075B2 (en) * 2006-06-30 2014-08-05 Sony Corporation Peer to peer connection
US7940653B2 (en) * 2006-08-29 2011-05-10 Verizon Data Services Llc Audiovisual data transport protocol
US8817668B2 (en) * 2006-09-15 2014-08-26 Microsoft Corporation Distributable, scalable, pluggable conferencing architecture
US20080085502A1 (en) * 2006-10-04 2008-04-10 Ecollege.Com Web service api for student information and course management systems
CN101170572A (zh) 2006-10-23 2008-04-30 日电（中国）有限公司 基于p2p sip技术实现的多媒体网络通信系统
FR2909823B1 (fr) * 2006-12-06 2012-12-14 Soc Fr Du Radiotelephone Sfr Procede et systeme de gestion de sessions multimedia, permettant de controler l'etablissement de canaux de communication
WO2008082441A1 (en) * 2006-12-29 2008-07-10 Prodea Systems, Inc. Display inserts, overlays, and graphical user interfaces for multimedia systems
US7688762B2 (en) * 2007-03-21 2010-03-30 Cisco Technology, Inc. Mesh backhaul network planning
DE102008004729A1 (de) 2008-01-16 2009-07-23 T-Mobile Internationale Ag Verfahren zur Versendung einer E-Mail an eine beliebige Rufnummer
KR101085629B1 (ko) * 2009-03-16 2011-11-22 삼성전자주식회사 이동통신 단말에서 ⅰｐ 통신의 네트워크 설정 방법 및 장치

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5734525B2 (ja) * 2012-12-11 2015-06-17 ＶｉｅｗＳｅｎｄ ＩＣＴ株式会社 医療支援システムおよびその方法
US9372960B2 (en) 2012-12-11 2016-06-21 ViewSend ICT Co., Ltd. Medical support system and method thereof

Also Published As

Publication number Publication date
US20100274848A1 (en) 2010-10-28
WO2011119793A2 (en) 2011-09-29
EP2553874A2 (en) 2013-02-06
WO2011119793A3 (en) 2012-01-19
US8732236B2 (en) 2014-05-20
CN102823196A (zh) 2012-12-12
KR20120136371A (ko) 2012-12-18

Similar Documents

Publication Publication Date Title
US8732236B2 (en) Managing network communications between network nodes and stream transport protocol
US11882165B2 (en) Realtime kernel
EP1593231B1 (en) Systems and methods for collaborative communication
KR101150110B1 (ko) 인스턴트 메시징을 위한 트랜스포트 시스템
JP4564697B2 (ja) 通信マネージャを備えたコンピュータ・システムによるアクティビティに基づいたコラボレーションのための方法及びその装置
US7493413B2 (en) APIS to build peer to peer messaging applications
US7543023B2 (en) Service support framework for peer to peer applications
JP4463999B2 (ja) 通信ネットワークにおける方法及び装置
US20130132058A1 (en) Creating and managing virtual areas
CN1917512B (zh) 一种建立对等直连通道的方法
US20140337478A1 (en) Peer-to-peer network communications
JP2006319910A (ja) 通信方法、ネットワーク、および情報処理装置
TW200924460A (en) Automated real-time data stream switching in a shared virtual area communication environment
Bu-Sung et al. Design and implementation of a Java-based meeting space over Internet
Guo et al. ShAppliT: A Novel Broker-mediated Solution to Generic Application Sharing in a Cluster of Closed Operating Systems
Eraslan VESIR-6: Virtual environment supporting multi-user interaction over IPv6.
Smith et al. Towards a standards-based, message-oriented advanced collaboration system
JP2004120039A (ja) 通信確立方法及びそれを用いた端末装置及び通信確立プログラム

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20140603