JP2014524092A - 単一ソケットポイントツーマルチポイント性能による高信頼性仮想双方向データストリーム通信のためのシステムおよび方法 - Google Patents

Abstract

【解決手段】 信頼性を有する仮想双方向データストリーム（ＲＶＢＤＤＳ）接続用の改良されたシステムおよび方法を開示する。１つの実施例では、２つの通信装置は、コネクションレストランスポート層パケットの中に封入されるストリーミングデータパケットを作成して交換する。ストリーミングデータパケットは、２つの当該装置間のＲＶＢＤＤＳ接続を管理するのに使用される情報を含んでいる。
【選択図】 なし

Description

関連出願の相互参照
本願は、２０１１年７月１５日に出願された表題「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＲＥＬＩＡＢＬＥ ＶＩＲＴＵＡＬ ＢＩ−ＤＩＲＥＣＴＩＯＮＡＬ ＤＡＴＡ ＳＴＲＥＡＭ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＷＩＴＨ ＳＩＮＧＬＥ ＳＯＣＫＥＴ ＰＯＩＮＴ−ＴＯ−ＭＵＬＴＩＰＯＩＮＴ ＣＡＰＡＢＩＬＩＴＹ」の米国特許出願第１３／１８３，５８７号の優先権を主張するものである。

現行のパケットベースの通信システムは、一般に、特定のプロトコルを利用して通信する。しかしそのようなプロトコルは、ハイブリッド型ピアツーピアシステムなどのシステムにおいて特定の問題に取り組む際には有用にならない場合がある。したがって、改善された方法およびシステムが、そのような問題に取り組む際に必要とされる。

より完全に理解するために、ここに以下の説明を、添付の図面と併せて参照する。
信頼性のある仮想双方向データストリーム（ＲＶＢＤＤＳ）接続を介して結合された装置を示す環境の一実施形態の簡略図である。 図１のＲＶＢＤＤＳ接続と共に用いられ得るパケットの一実施形態の簡略図である。 図１のＲＶＢＤＤＳ接続と共に用いられ得るパケットの一実施形態の簡略図である。 図２Ｂのパケット内でカプセル化され得るストリーミングデータパケットの一実施形態の簡略図である。 ＲＶＢＤＤＳ接続のために図１の装置内で起こり得る状態遷移の一実施形態を示すプロトコル状態図である。 図１の一装置がＲＶＢＤＤＳ接続のために別の装置の接続に成功するシーケンスの一実施形態を示すタイミング図である。 図１の一装置がＲＶＢＤＤＳ接続を利用して別の装置に接続するのに成功しないシーケンスの一実施形態を示すタイミング図である。 図１の一装置がＲＶＢＤＤＳ接続を利用してデータを別の装置に送信するのに成功する様々なシーケンスの一実施形態を示すタイミング図である。 図１の一装置がＲＶＢＤＤＳ接続を利用してデータを別の装置に送信することができない様々なシーケンスの一実施形態を示すタイミング図である。 図１の一装置がＲＶＢＤＤＳ接続を切断するシーケンスの一実施形態を示すタイミング図である。 図１の一装置がネットワーク問題または他の装置外部の問題のためにＲＶＢＤＤＳ接続を切断するシーケンスの一実施形態を示すタイミング図である。 ラウンドトリップタイム（ＲＴＴ）を計算して、パケットの再送を制御するのに用いられ得る方法など、図１の装置が単一パケットを送信することができる方法の一実施形態のフローチャートである。 図１の装置が輻輳ウィンドウを計算して、何バイト送信され得るかを決定することができる方法の一実施形態のフローチャートである。 図１の装置により用いられ得る受信バッファの一実施形態の簡略図である。 図１の装置により用いられ得る送信バッファの一実施形態の簡略図である。 図１の装置がデータの単一セグメントを送信することができる方法の一実施形態のフローチャートである。 図１の装置がＲＶＢＤＤＳソケットを介して別の装置に接続しようと試みる方法の一実施形態のフローチャートである。 図１の装置がＲＶＢＤＤＳソケットを介して別の装置からの接続要求を受け付けようと試みる方法の一実施形態のフローチャートである。 図１の装置がＲＶＢＤＤＳソケットでデータを送信しようと試みる方法の一実施形態のフローチャートである。 図１の装置がＲＶＢＤＤＳソケットでデータを送信しようと試みる方法の一実施形態のフローチャートである。 図１の装置がＲＶＢＤＤＳソケットでデータの厳密な量を送信しようと試みる方法の一実施形態のフローチャートである。 図１の装置がＲＶＢＤＤＳソケットからデータを読み込もうと試みる方法の一実施形態のフローチャートである。 図１の装置がＲＶＢＤＤＳソケットに対応するデータおよびタイマーを取り扱う方法の一実施形態のフローチャートである。 図２０の方法でタイマーを取り扱うために用い得る方法の一実施形態のフローチャートである。 図２０の方法でタイマーを取り扱うために用い得る方法の一実施形態のフローチャートである。 図２０の方法でタイマーを取り扱うために用い得る方法の一実施形態のフローチャートである。 図２０の方法でメッセージを取り扱うために用い得る方法の一実施形態のフローチャートである。 図２０の方法でメッセージを取り扱うために用い得る方法の一実施形態のフローチャートである。 図２０の方法でメッセージを取り扱うために用い得る方法の一実施形態のフローチャートである。 図２０の方法でメッセージを取り扱うために用い得る方法の一実施形態のフローチャートである。 図２０の方法でメッセージを取り扱うために用い得る方法の一実施形態のフローチャートである。 図２０の方法でメッセージを取り扱うために用い得る方法の一実施形態のフローチャートである。 図２０の方法でメッセージを取り扱うために用い得る方法の一実施形態のフローチャートである。 本開示の実施形態において通信装置として用いられ得るコンピュータシステムの一実施形態の簡略図である。

本開示は、信頼性のある仮想双方向データストリーム通信のためのシステムおよび方法を対象とする。以下の開示が多くの異なる実施形態または実施例を提供することを、理解されたい。構成成分および配列の具体的例が、本開示を簡便化するために以下に記載されている。もちろんこれらは、単に例示であり、限定を意図するものではない。加えて本開示は、様々な実施例において参照番号および／または文字を繰り返し用いる場合がある。この繰り返しは、簡便性および明瞭性を目的としており、本質的には議論された様々な実施形態および／または構成の間にある関連性を規定するものではない。

図１を参照すると、一実施形態において、環境１００が、ネットワーク１０５を通した信頼性のある仮想双方向データストリーム（本明細書においてＲＶＢＤＤＳと称する）接続１０６により結合された２つの通信装置１０２および１０４と共に示されている。そのような通信装置の例としては、携帯電話（スマートフォンを含む）、パーソナルデジタルアシスタント（ＰＤＡ）、ネットブック、タブレット、ラップトップ、デスクトップ、ワークステーション、ならびに無線および／または有線通信リンクを用いて別のコンピューティング装置と通信し得る任意の他のコンピューティング装置が挙げられる。そのような通信は、直接的（例えば、ピアツーピアネットワーク、アドホックネットワークを介して、または直接的な接続を用いて）、間接的、例えばサーバもしくは他のプロキシ（例えば、クライアント／サーバモデルにおいて）であってもよく、または直接的接続と間接的接続の組み合わせを利用してもよい。

ネットワーク１０５は、単一ネットワークであってもよく、または異なる形式のネットワークをはじめとし、複数ネットワークを表していてもよい。例えば装置１０２は、データパケットネットワークに結合されたセルラーリンクを含むネットワークを介して、またはデータパケットネットワークに結合された広域ローカルエリアネットワーク（ＷＬＡＮ）などのデータパケットリンクを介して、装置１０４に結合されていてもよい。したがって多くの異なるネットワーク形式および構成を、通信装置１０２と１０４とを結合させるのに用いることができる。

例示的ネットワーク、システム、および接続形式としては、インターネット、ＷｉＭａｘ、ローカルエリアネットワーク（ＬＡＮ）(例えば、ＩＥＥＥ ８０２．１１ａおよび８０２．１１ｇワイファイネットワーク）、デジタル音声放送システム(例えば、ＨＤラジオ、Ｔ−ＤＭＢおよびＩＳＤＢ−ＴＳＢ)、地上デジタルテレビシステム(例えば、ＤＶＢ−Ｔ、ＤＶＢ−Ｈ、Ｔ−ＤＭＢおよびＩＳＤＢ−Ｔ)、ＷｉＭａｘ無線メトロポリタンエリアネットワーク（ＭＡＮ） (例えば、ＩＥＥＥ ８０２．１６ネットワーク)、モバイルブロードバンドワイヤレスアクセス（ＭＢＷＡ）ネットワーク(例えば、ＩＥＥＥ ８０２．２０ネットワーク)、ウルトラモバイルブロードバンド（ＵＭＢ）システム、Ｆｌａｓｈ−ＯＦＤＭセルラーシステム、およびウルトラワイドバンド（ＵＷＢ）システムが挙げられる。更に本開示は、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ（登録商標））、および／または符号分割多元接続（ＣＤＭＡ）通信システムなどの通信システムを用いることができる。そのようなネットワークの接続は、無線であってもよく、または線（例えば、デジタル加入者回線（ＤＳＬ）、ケーブル回線、および光ファイバー回線）を使用してもよい。

本開示は、単一ソケットポイントツーマルチポイント性能によるＲＶＢＤＤＳ通信を開設および維持することを対象とする。本実施形態において、装置１０２および１０４は、ピアツーピアエンドポイントであり、ＲＶＢＤＤＳ接続１０６は、ピアツーピアエンドポイントの間の通信に用いられてもよい。そのようなエンドポイントの例は、２００５年３月１５日に出願された表題「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＰＥＥＲ−ＴＯ−ＰＥＥＲ ＨＹＢＲＩＤ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ」の米国特許第７，６５６，８７０号に記載されており、それは参照により全体として本明細書に組み入れられる。そのようなエンドポイントは、２００５年８月３０日に出願された表題「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＴＲＡＶＥＲＳＩＮＧ Ａ ＮＡＴ ＤＥＶＩＣＥ ＦＯＲ ＰＥＥＲ−ＴＯ−ＰＥＥＲ ＨＹＢＲＩＤ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ」の米国特許第７，５７０，６３６号；および２０１０年２月１５日に出願された表題「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＳＴＲＡＴＥＧＩＣ ＲＯＵＴＩＮＧ ＩＮ Ａ ＰＥＥＲ−ＴＯ−ＰＥＥＲ ＥＮＶＩＲＯＮＭＥＮＴ」の米国特許出願第１２／７０５，９２５号に記載されたような様々なＮＡＴ通過およびルーティングプロセスを利用してもよく、それらの文書は両者とも参照により全体として本明細書に組み入れられる。

ＲＶＢＤＤＳ接続は、従来のクライアント／サーバアーキテクチャーにおいて動作するものなど、ピアツーピア方式で動作しない装置にも用いることができる。例えば装置１０２および１０４は、クライアント１０２およびサーバ１０４であってもよく、ＲＶＢＤＤＳ接続が、そのクライアントとサーバの間で確立されてもよい。したがって以下の実施形態の多くは、ピアツーピアエンドポイントに関して記載され、幾つかの実施形態は、ピアツーピア環境を対象とした特色を含むが、それらがピアツーピア環境に限定されず、本明細書に記載された機能が、クライアント／サーバアーキテクチャー、および通信が本明細書に記載されたＲＶＢＤＤＳ機能から利益を受け得る任意の他のネットワークアーキテクチャーに即座に適合させ得ることを、理解されたい。

ＲＶＢＤＤＳ接続は、２つの装置１０２および１０４の間で送信されたパケットが従来の意味での接続ベースではないため、仮想接続である。より具体的には装置１０２と１０４の間の通信は、予め定義されていて公的に入手できる（即ち、ノンプロプリエタリ）通信規格もしくはプロトコル（例えば、インターネットエンジニアリングタスクフォース（ＩＥＴＦ）または国際電気通信連合電気通信標準化部門（ＩＴＵ−Ｔ）により定義されたもの）、および／またはプロプリエタリプロトコルを用いて遂行されてもよい。例えばシグナリング通信（例えば、セッションセットアップ、管理、およびティアダウン）は、セッションイニシエーションプロトコル（ＳＩＰ）などのプロトコルを用いることができ、データトラフィックは、リアルタイムトランスポートプロトコル（ＲＴＰ）などのプロトコルを用いて通信することができる。本実施例において、装置１０２と１０４の間の通信セッションは、コネクションレス型である（例えば、ユーザデータグラムプロトコル（ＵＤＰ）などのコネクションレス型トランスポートプロトコルを用いる）。ＲＶＢＤＤＳ接続は、最初のパケット内の情報を使用してＲＶＢＤＳＳ属性を提供し、その後、最初のパケットを２番目のパケットにカプセル化して、実際の伝送のためにコネクションレス型属性を提供する、通信プロトコルに基づいている。ＲＶＢＤＤＳは、コネクションレス型プロトコル（例えば、ＵＤＰ）に基づいており、装置１０２および１０４の両方が、以下に記載される通りアウトバウンドメッセージを開始することができるため、先の事柄より、ＲＶＢＤＤＳ接続が、装置１０２および１０４の１つ以上に関連するネットワークアドレス変換（ＮＡＴ）装置（図１に示さない）を通過するなどのタスクを遂行することができる。

図１を引き続き参照すると、装置１０２は、本実施例においては受信バッファ１１０（インバウンドデータ用）および送信バッファ１１２（アウトバウンドデータ用）を維持する、ＲＶＢＤＤＳソケット１０８を含む。装置１０２のアプリケーション１１４が、データをソケット１０８に送信し、そしてデータをソケット１０８から受信する。同様に装置１０４は、本実施例においては受信バッファ１１８および送信バッファ１２０を維持する、ＲＶＢＤＤＳソケット１１６を含む。装置１０４のアプリケーション１２２が、データをソケット１１６に送信し、そしてデータをソケット１１６から受信する。

各ＲＶＢＤＤＳソケット１０８および１１６が、様々な方法で実装され得ることを、理解されたい。例えばＲＶＢＤＤＳソケット１０８は、装置１０２によりインスタンスを作製されるソケットオブジェクトであってもよい。ソケットオブジェクトは、１つ以上のバッファオブジェクトで順次、制御および／または通信することができる（例えば、バッファオブジェクトが単一バッファであるか、もしくは受信バッファ１１０および送信バッファ１１２の両方を含むかに応じて、または更なるバッファが存在するかどうかに応じて）。例えば、バッファ１１０、１１２、１１８、および１２０は、ソケット１０８および１１６の一部として示されているが、ソケット自体から分離されていてもよい。ソケットオブジェクトは、ソケットオブジェクトが機能するのに必要となる様々なタイマーを管理するタイマーオブジェクトで制御および／または通信することもできる。したがって特定の実装の詳細が、本明細書に議論されるが、ＲＶＢＤＤＳ接続１０６に必要とされる潜在的機能が存在する限り、ＲＶＢＤＤＳソケット１０８が多くの異なる方法で実装され得ることを、理解されたい。

ＲＶＢＤＤＳ接続１０６は、２つの装置１０２および１０４の間に示されているが、ＲＶＢＤＤＳソケット１０８は、装置１０２と装置１２６の間のＲＶＢＤＤＳ接続１２４により示された通り、ポイントツーマルチポイント接続が可能である。装置１２６は、本実施例においては受信バッファ１３０および送信バッファ１３２を維持する、ＲＶＢＤＤＳソケット１２８を含む。装置１２６のアプリケーション１３４が、データをソケット１２８に送信し、そしてデータをソケット１２８から受信する。

ＲＶＢＤＤＳ接続１０６および１２４は、例示の目的で別個の接続として示されているが、それらが仮想接続であり、ポイントツーマルチポイント性能がＲＶＢＤＤＳソケット１０８を介したマルチキャストまたはブロードキャスト機能により提供され得ることを、理解されたい。例えばアプリケーション１１４は、アプリケーション１２２および１３４に通信されてもよい。ＲＶＢＤＤＳソケット１０８を用いて、アプリケーション１１４が、パケットをアプリケーション１２２および１３４の両方にマルチキャストまたはブロードキャストすることができる。以下に記載される通り、各装置１０２、１０４、および１２６は、装置を他の装置に送信されるパケットの供給源として識別する一意識別子と関連づけられる。例えば装置１０２は、装置１０２により送信された各パケット内に挿入されて装置１０４および１２６により使用される一意識別子と関連づけられて、装置１０２を、装置１０２から装置１０４および１２６に送信される任意のパケット（ポイントツーマルチポイントパケットを含む）の供給源として識別する。本明細書には詳細に記載されていないが、ＲＶＢＤＤＳソケット１１６および１２８も、ポイントツーマルチポイントソケットであり、他のＲＶＢＤＤＳ接続が存在し得る（例えば、装置１０４と１２６の間のＲＶＢＤＤＳ接続１３６）。

図２Ａ、２Ｂ、および３を参照すると、図１のＲＶＢＤＤＳ接続１０６などのＲＶＢＤＤＳ接続に用いられ得るパケット２００の実施形態が、提供される。利便性の目的で、用語「パケット」および「セグメント」は、一般に、以下の実施形態において、ヘッダ情報およびおそらく装置に送信される、または装置から受信されるデータを表すパケット、ならびにアプリケーションに送信される、またはアプリケーションから受信されるデータを表すセグメントと共に用いられる。それゆえセグメントまたは複数セグメントの幾つかまたは全てが、パケット内に含まれていてもよい。しかしこれらの用語が利便性の目的で用いられており、限定を意図するものではないことを、理解されたい。例えばセグメントは、装置間で送信され（カプセル化の後）、幾つかの実施形態が、セグメントをパケットに挿入するプロセスを議論せずにセグメントの送信を指す場合がある。

図２Ａを具体的に参照すると、パケット２００の一実施形態は、ヘッダおよびペイロードデータを含む。本実施例において、パケット２００は、トランスポート層パケットヘッダである部分２０２と、ＲＶＢＤＤＳパケットヘッダである部分２０４と、装置１０２と１０４の間のＲＶＢＤＤＳ接続１０６のデータストリームに対応するデータを含む部分２０６と、を含むコネクションレス型トランスポート層パケットである。ＲＶＢＤＤＳパケットヘッダ２０４およびデータ部分２０６は、ＵＤＰパケット２００のペイロード内に含まれる。データ部分２０６は、ＲＶＢＤＤＳパケットヘッダ２０４から分離していてもよく、またはＲＶＢＤＤＳパケットヘッダ２０４に関連づけられたペイロード部分に含まれていてもよい（例えば、部分２０４および２０６は、単一ＲＶＢＤＤＳパケットを形成していてもよい）。

ヘッダ情報は、送信元のＩＰアドレスおよびポート（送信元の識別を援助しない場合があり、アドレスを提供して送信元に至る）、ならびに受信元のＩＰアドレスおよびポートを含む。ヘッダ情報は、ペイロードの長さ、パケットの正確さを確証するサイクリックリダンダンシチェック（ＣＲＣ）、およびこのパケット内に送信されている範囲（例えば、バイト範囲）を更に含む（データの長さは知られているため、単一数が、ペイロード内の開始バイトのストリーム内の位置を示すのに用いられてもよい）。ヘッダは、送信元により肯定応答されている受信元からのデータ（例えば、バイトの）、および受信元からデータを受信するための送信元で利用できるスペースも含み、送信元の受信バッファ内で利用できる最終バイトのストリーム内の位置を送信することにより遂行され得る。ヘッダは、送信元を一意的に識別するデータ（複数の送信元は、同じＩＰ／ポートを有していてもよい）、ならびに送信されている制御パケットの形式および任意のパディング情報についてのメタ情報も含む。

図２Ｂを具体的に参照すると、パケット２００のより具体的な実施形態が、ＵＤＰをコネクションレス型トランスポート層として実装されたＲＶＢＤＤＳと共に示される。これまで記載されたヘッダ情報の幾つかは、ネットワークパケットヘッダ（この場合、ＵＤＰヘッダ）内で既に利用可能であるため、以下の欄は、ＲＶＢＤＤＳパケット内で運ばれない：送信元のＩＰアドレスおよびポート、受信元のＩＰアドレスおよびポート、パケットの長さ、ならびにパケットの正確さを確証するＣＲＣ。

したがって本実施例において、パケット２００は、ＵＤＰヘッダである部分２０２と、ＲＶＢＤＤＳ情報を運ぶＲＶＢＤＤＳパケットヘッダである部分２０４と、装置１０２と１０４の間のＲＶＢＤＤＳ接続１０６のデータストリームに対応するデータを含む部分２０６と、を含むＵＤＰパケット（例えば、データグラム）である。ＲＶＢＤＤＳパケットヘッダ２０４およびデータ部分２０６は、ＵＤＰパケット２００のペイロード内に含まれる。データ部分２０６は、ＲＶＢＤＤＳパケットヘッダ２０４から分離していてもよく、またはＲＶＢＤＤＳパケットヘッダ２０４に関連づけられたペイロード部分に含まれていてもよい（例えば、部分２０４および２０６は、単一ＲＶＢＤＤＳパケットを形成していてもよい）。

ＵＤＰが用いられるか、または他のトランスポートプロトコルが用いられるかにかかわらず、多くの異なるパケットフォーマットが用いられ得ることを、理解されたい。例えばＲＶＢＤＤＳパケットヘッダ２０４は、再配列されても、ＵＤＰパケット２００内のどこか別の場所（未使用または空いたＵＤＰヘッダ欄内を含む）に保存されても、データ部分２０６などに関係する別の場所に保存されてもよい。したがってＵＤＰパケット２００は、ＲＶＢＤＤＳパケットヘッダ２０４およびデータ部分２０６のカプセル化を実装する多くの可能な方法の一例にすぎない。

図３を参照すると、ＲＶＢＤＤＳパケットヘッダ２０４の一実施形態が、示されている。ＲＶＢＤＤＳパケットヘッダ２０４は、送信バイト（ＳｅｎｄＢｙｔｅ）欄３０２、肯定応答（ＡＣＫ）バイト（ＡＣＫＢｙｔｅ）欄３０４、一意的ユーザ識別子（ＵＩＤ）欄３０６、ウィンドウ欄３０８、パケット形式（ＰａｃｋｅｔＴｙｐｅ）欄３１０、およびパッド欄３１２を含む。バイト（例えば、送信バイト）が例示の目的で用いられたが、他の実施形態がバイトを用いなくてもよいことを、理解されたい。

送信バイト欄３０２は、データ部分２０６に含まれるセグメントの送信ストリーム内の位置（例えば、開始バイト数）を表すＳｅｎｄＢｙｔｅの値を含む。ＡＣＫバイト欄３０４は、全てのデータが受信され終わるまでの受信ストリーム内の位置（例えば、１バイト）を表すＡＣＫＢｙｔｅの値を含む。幾つかのセグメントがＡＣＫＢｙｔｅを超えて受信されてもよいが、ＡＣＫＢｙｔｅの直後のバイトが受信されなくなってからはセグメントが肯定応答されないことに、留意されたい。ＵＩＤ欄３０６は、第一の装置と第二の装置の間のこのＲＶＢＤＤＳ接続を一意的に識別する値を含み、例えばピアツーピア環境での接続をポートマッピングするために、用いられる。ウィンドウ欄３０８は、更なるデータのために受信装置のバッファ（例えば、図１の装置１０４の受信バッファ１１８）に残されたスペース量（例えば、利用できるバイト数）を表す値を含む（ＡＣＫＢｙｔｅが、受信装置により受信された最後のバイトであると仮定する）。

パケット形式欄３１０は、以下の値を有することができる：

パケット形式Ｄａｔａは、ＲＶＢＤＤＳパケットヘッダ２０４が、ストリームに関するデータを含むことを示す。パケット形式Ｃｏｎｎｅｃｔは、パケットを送信する装置１０２または１０４が、他の装置との接続を要求することを示す。パケット形式Ａｃｃｅｐｔは、別の装置から受信された接続要求が、受け付けられたことを示す。パケット形式Ｃｌｏｓｅは、パケットを送信する装置１０２または１０４が、接続を閉鎖していることを示す。パケット形式Ｐｕｎｃｈは、ＲＶＢＤＤＳパケットヘッダ２０４が、ＮＡＴ装置などの装置を介してピンホールを維持するキープアライブメッセージとして用いられていることを示すために用いられる。

後に記載される通り、ＡＣＫは、データと共に送信されてもよく、そのような場合、純粋なＡＣＫパケットは、パケット形式Ｄａｔａを用いることができ、ＵＤＰパケットの長さは、パケットがデータを実際に運ぶか否か（即ち、パケットがＡＣＫのみを含むか、またはＡＣＫおよびデータの両方を含むか）を示すために用いることができる。パケットがデータを運ばない場合、送信バイト欄が無視され得る。パケット形式それぞれの使用法は、以下の例に記載される。パケット形式が、他の値を有し得ること、および他のパケット形式が用いられ得ることを、理解されたい。

パッド欄３１２は、任意の必要とされるパディングを表す値を含む。例えば、パケット内のバイト数が、４の倍数である場合、パッド欄３１２内の値が、データを埋め込むように設定されて、データを４の倍数にする。本実施例において、ＡＣＫバイト欄３０４およびウィンドウ欄３０８は、全てのパケットのためにポピュレートされるが、幾つかの欄は、ポピュレートする必要がない場合がある（例えば、パケットが純粋なＡＣＫパケットである場合の送信バイト欄３０２）。

ＲＶＢＤＤＳヘッダ２０４が、図３に関して記載された情報を有するヘッダを実装する多くの可能な方法の一例にすぎないことを、理解されたい。したがって、ＲＶＢＤＤＳヘッダ２０４の欄により運ばれる情報を維持しながら、長さ、編成、および他のパラメータが変動させることができる。

本明細書に記載された図（フローチャートを含む）が、様々な通信環境で起こり得る様々な例示的機能および動作を示すことを、理解されたい。これらの図が、網羅的でないこと、および様々なステップが、図から排除されて記載されている態様を明瞭化し得ることを、理解されたい。例えば幾つかのアクション、例えばネットワーク認証のプロセスおよび通知が、図の最初のステップの前に、装置１０２および１０４の一方または両方により実施されていてもよいことを、理解されたい。そのようなアクションは、ネットワークアクセスを得る方法（例えば、セルラー方式またはＷＬＡＮアクセス）をはじめとし、各通信装置１０２および１０４の特定の形式および構成に依存し得る。コールメンテナンス（ハンドオフを含む）、他の装置との通信（例えば、電子メール、テキストメッセージ、および／または音声コール（カンファレンスコールを含む））、および類似のアクションをはじめとする他のアクションが、図示されたステップの間に、または図示されたステップと同時に起こってもよい。

図４を参照すると、一実施形態において、プロトコル状態図４００が、図２Ａまたは図２Ｂのパケット２００などのパケットを用いてピアツーピア接続を確立および／または切断している装置内で起こり得る状態遷移を示す。状態図４００は、接続を要求している装置、および接続要求を受信している装置の両方を示す。例示の目的で、装置１０２は、要求している装置であり、装置１０４は、要求を受信している装置である。

装置１０２の斜視図から、装置１０２は、初期化（ｉｎｉｔ）状態４０２に入り、そこで装置１０２は、作成状態４０４に入る前にソケットを作成してそれに結合する。例えば装置１０２は、ＲＶＢＤＤＳソケット１０８を作成して、ソケットの任意の必要なリソースを割り当ててもよい。本実施形態において、送信および受信されるパケットは、ＵＤＰペイロードの全てまたは一部としてカプセル化されるため、装置１０２は、ＲＶＢＤＤＳソケット１０８をＵＤＰソケットとして作成する。装置１０２は、その後、ＲＶＢＤＤＳソケット１０８に結合して、ソケットをローカルポート番号およびＩＰアドレスに関連づけてもよい。

作成状態４０４になれば、装置１０２は、別の装置との接続準備ができる。装置１０２は、装置１０４への接続要求を送信して、接続状態４０６に入り、そこで装置１０２は、装置１０４からの応答を待つ。本実施例において、装置１０２は、タイムアウトになる前に装置１０４からの受け付けを受信して、接続状態４０８に入る。

装置１０４の斜視図から、装置１０４は、初期化（ｉｎｉｔ）状態に入り、そこで装置１０４は、作成状態４０４に入る前にソケットを作成してそれに結合する。例えば装置１０４は、ＲＶＢＤＤＳソケット１１６を作成して、ソケットの任意の必要なリソースを割り当ててもよい。本実施形態において、装置１０４は、ＲＶＢＤＤＳソケット１１６をＵＤＰソケットとして作成する。装置１０４は、その後、ＲＶＢＤＤＳソケット１１６に結合して、ソケットをローカルポート番号およびＩＰアドレスに関連づけてもよい。

作成状態では、装置１０４は、着信接続要求を待つ。装置１０２からの要求が受信されたら、装置１０４は、要求を許可して、受け付け状態４１０に移動する。受け付け状態４１０から、装置１０４は受け付けを装置１０２に送信して、接続状態４０８に移動する。

装置１０２および１０４の両方が、ＲＶＢＤＤＳ接続１０６を利用しながら、依然として接続状態４０８にある。接続状態４０８は、ネットワークエラー、装置１０２もしくは１０４のユーザによる閉鎖のシグナリング、または他の装置からの閉鎖メッセージの受信など、１つ以上の閉鎖事象の発生により終了してもよい。本実施例において、装置１０２は、閉鎖事象が起こり装置１０４に閉鎖メッセージを送信した後、閉鎖状態４１２に遷移する。装置１０４も、閉鎖状態４１２に遷移する。

図５を参照すると、タイミング図５００は、装置１０２（要求者）が装置１０４への接続に成功するシーケンスの一実施形態を示す。装置１０２は、ステップ５０２および５０６においてソケット（例えば、ソケット１０８）を作成してそのソケットに結合し、装置１０４は、ステップ５０４および５０８においてソケット（例えば、ソケット１１６）を作成してそのソケットに結合する。ステップ５１０において装置１０２は、接続を開始して、ステップ５１２において装置１０４に接続要求を送信する。装置１０４は、ステップ５１４において接続を許可し、ステップ５１６において装置１０２に受け付けを送信する。

本実施例において、装置１０２は、アプリケーション１１４からのブロッキング接続コールを示す。装置１０４は、通知によって接続がなされたことをアプリケーション１２２が知らせる、ノンブロッキングの許可を示す。したがって装置１０４は、ステップ５１８において接続がなされたことをアプリケーション１２２に通知するが、そのような通知は、装置１０２では起こらない。

図６を参照すると、タイミング図６００は、装置１０２が装置１０４への接続に成功しない（図示しない）シーケンスの一実施形態を示す。装置１０２は、ステップ６０２および６０４においてソケット１０８を作成してそのソケットに結合する。ステップ６０６において、装置１０２は、接続を開始し、ステップ６０８において装置１０４に接続要求を送信する。図６に示された通り、装置１０２は、ステップ６０８の接続要求への応答を受信せず、タイムアウト期間６１６の満了後に、接続要求がタイムアウトになる。本実施例において、装置１０２は、最初の接続要求６０８、タイムアウト期間６１８の終了後にタイムアウトになる２回目の接続要求６１０、３回目の接続要求６１２、およびタイムアウト期間６２０の満了後にタイムアウトになる２０回目の接続要求６１４を含む、合計２０回の接続要求を送信する。各接続要求は、特定の要求への応答が装置１０４から受信される前にタイムアウトになる。したがって最後の接続要求６１４がタイムアウトになった後、アプリケーション１１４が、ステップ６２２において接続不能と通知される。

接続要求の数が変更されてもよく、２０回よりも少ない、またはそれより多い接続要求が用いられ得ることを、理解されたい。更にタイムアウト期間が本実施例においては等しく示されたが、それらは変動してもよい。例えば、遅いタイムアウト期間が、早いタイムアウト期間よりも長くなるように、接続要求が送信されたら、タイムアウト期間が延長されてもよい。

図７を参照すると、タイミング図７００は、装置１０２が装置１０４にデータを送信するのに成功するシーケンスの一実施形態を示す。図７において、３つの異なるデータ伝送状況が起こり、それぞれがＡＣＫとなっている。

図７の最初のデータ伝送シナリオにおいて、装置１０２は、ステップ７０２において装置１０４にデータ（例えば、単一パケット２００）を送信する。装置１０４によるデータの受信は、ＡＣＫ遅延期間７０４を開始させる。本実施例においてＡＣＫ遅延期間７０４は、２５ミリ秒であるが、他の期間が用いられ得ることを理解されたい。ＡＣＫ遅延期間７０４の満了後に、装置１０４がステップ７０６において装置１０２にＡＣＫを送信する。

図７の２番目のデータ伝送シナリオにおいて、装置１０２は、ステップ７０８において装置１０４にデータ（例えば、単一パケット２００）を送信する。装置１０４によるデータの受信は、ＡＣＫ遅延期間７１４を開始させる。本実施例においてＡＣＫ遅延期間７１４は、２５ミリ秒であるが、他の期間が用いられ得ることを理解されたい。装置１０２は、ステップ７１０および７１２において装置１０４に追加のデータを送信し、そのデータはＡＣＫ遅延期間７１４の間に装置１０４により受信される。ステップ７１０および７１２のデータが、ＡＣＫ遅延期間７１４の開始前またはその期間の間に装置１０２により送信されてもよいことを、理解されたい。ＡＣＫ遅延期間７１４の満了後に、装置１０４は、ステップ７１６において装置１０２に単一ＡＣＫを送信して、ステップ７０８、７１０、および７１２において受信されたデータの受信を肯定応答する。

図７の３番目のデータ伝送シナリオにおいて、装置１０２は、ステップ７１８において装置１０４にデータ（例えば、単一パケット２００）を送信する。データは、既存のＡＣＫ遅延期間（例えば、ＡＣＫ遅延期間７１４）の前またはその期間の間に送信されてもよく、ＡＣＫ遅延期間が満了した後まで受信されなくてもよい。装置１０４によるデータの受信は、ＡＣＫ遅延期間７２０を開始させる。本実施例においてＡＣＫ遅延期間７２０は、２５ミリ秒であるが、他の期間が用いられ得ることを理解されたい。ＡＣＫ遅延期間７２０の満了前に、装置１０４は、ステップ７２２においてアプリケーション１２２からアプリケーションデータを受信する。その後、ＡＣＫ遅延期間７２０が満了すれば、つまり別のＡＣＫが送信される必要がなくなれば、装置１０４は、ステップ７２４において、装置１０２にアプリケーションデータおよびＡＣＫの両方を送信してもよい。ステップ７２４は、ＡＣＫ遅延期間７２０の満了後に起こるように示されているが、ステップ７２４が、ステップ７２２においてアプリケーションデータの受信により起こり得る（即ち、ＡＣＫ遅延期間７２０の満了を待たない）ことを、理解されたい。

図８を参照すると、タイミング図８００は、装置１０２が装置１０４にデータを送信しようとしている時にエラーが起こったシーケンスの一実施形態を示す。図８において、３つの異なるデータは、エラーが起こった状況を伝送している。

図８の最初のデータ伝送シナリオにおいて、装置１０２は、ステップ８０２において装置１０４にデータ（例えば、単一パケット２００）を送信する。装置１０２によるデータの送信は、送信タイムアウト期間８０４を開始させ、装置１０４によるデータの受信は、ＡＣＫ遅延期間８０６を開始させる。ＡＣＫ遅延期間８０６が終了したら、ＡＣＫは、ステップ８０８において送信される。ＡＣＫは、送信タイムアウト期間８０４の終了前に受信されないため、ステップ８０２において送信されたデータは、ステップ８１０において再送される。装置１０４による再送データの受信は、別のＡＣＫ遅延期間８１２を開始させ、ＡＣＫ遅延期間の満了時に、別のＡＣＫが、ステップ８１４において装置１０４から装置１０２に送信される。しかし、ここではステップ８０８の過去のＡＣＫは、装置１０２により受信されているため、ステップ８１４のＡＣＫは無視される。図示されていないが、ステップ８１０におけるデータの再送は、別の送信タイムアウト期間を開始させてもよいが、ステップ８０８のＡＣＫは、そのような送信タイムアウト期間の満了前に受信され、そのためデータは再度再送されないことを、理解されたい。幾つかの実施形態において、例えば装置１０２が、１回だけ再送されるように構成されていれば、２回目の送信タイムアウト期間は起こり得ない。

図８の２番目のデータ伝送シナリオにおいて、装置１０２は、ステップ８１６において装置１０４にデータ（例えば、単一パケット２００）を送信する。装置１０２によるデータの送信は、送信タイムアウト期間８１８を開始させ、装置１０４によるデータの受信は、ＡＣＫ遅延期間８２０を開始させる。ＡＣＫ遅延期間８２０が終了したら、ＡＣＫは、ステップ８２２において送信されるが、消失する（即ち、装置１０２に到達しない）。ＡＣＫは、送信タイムアウト期間８１８の終了前に受信されないため、ステップ８１６において送信されたデータは、ステップ８２４において再送される。装置１０４による再送データの受信は、別のＡＣＫ遅延期間８２６を開始させ、ＡＣＫ遅延期間の満了時に、別のＡＣＫが、ステップ８２８において装置１０４から装置１０２に送信される。ステップ８２８におけるＡＣＫは、装置１０２により受信される。図示されていないが、ステップ８２４におけるデータの再送は、別の送信タイムアウト期間を開始させてもよいが、ステップ８２８のＡＣＫは、そのような送信タイムアウト期間の満了前に受信され、そのためデータは再度再送されないことを、理解されたい。幾つかの実施形態において、例えば装置１０２が、１回だけ再送されるように構成されていれば、２回目の送信タイムアウト期間は起こり得ない。

図８の３番目のデータ伝送シナリオにおいて、装置１０２は、ステップ８３０において装置１０４にデータ（例えば、単一パケット２００）を送信する。装置１０２によるデータの送信は、送信タイムアウト期間８３２を開始させる。本実施例において、ステップ８３０において送信されたデータは、消失しており（即ち、装置１０４に到達せず）送信タイムアウト期間８３２は、装置１０４からＡＣＫを受信せずに終了し、装置１０４は、データを受信しない。したがってステップ８３４において、装置１０２は、データを再送する。装置１０４によるデータの受信は、ＡＣＫ遅延期間８３６を開始させる。ＡＣＫ遅延期間８３６が終了したら、ＡＣＫは、ステップ８３８において送信される。

図９を参照すると、タイミング図９００は、接続切断の一実施形態を示す。本実施例において、装置１０２は、切断を開始するが、いずれかの側（例えば、装置１０２および１０４のいずれか）が切断を開始しうることを、理解されたい。

ステップ９０２において、装置１０２は、装置１０４に閉鎖パケットを送信して、接続が切断されていることを装置１０４に通知する。閉鎖パケットは、装置１０４により肯定応答されることはない。他の事象後に起こるように示されているが、装置１０２は、肯定応答を待たないため、閉鎖パケットを送ると、ステップ９０４において接続を切断する。ステップ９０６において、装置１０４は、接続を利用するアプリケーション１２２に接続が切断されていることを通知する。ステップ９０８において、装置１０４は、接続を切断する。

図１０において、タイミング図１０００は、ネットワーク問題または装置外部の他の問題のために、装置（例えば、装置１０２）が接続を切断するシーケンスの一実施形態を示す。装置１０２は、送信タイムアウトが最大値を超えるまでデータを複数回、再送しようと試みる。その後、装置１０２は、再送を停止して、他の装置に閉鎖を送信し、接続が閉鎖されたことをアプリケーション１１４に通知して、接続を切断する。

したがって装置１０２は、ステップ１００２において、装置１０４にデータ（例えば、単一パケット２００）を送信する。装置１０２によりデータを送信すると、送信タイムアウト期間１００４が開始する。装置１０２は、ステップ１００２のデータに関する肯定応答を受信せず、送信データタイムアウト１００４が満了する。装置１０２は、ステップ１００６においてデータを再送する。ステップ１００６において装置１０２によりデータを再送すると、送信タイムアウト期間１００８が開始するが、それは過去の送信タイムアウト期間１００４よりも長い。装置１０２は、ステップ１００６の再送データに関する肯定応答を受信せず、送信データタイムアウト１００８が満了する。

本実施例において、装置１０２は、ＡＣＫ（本実施例においては起こらない）を受信するまで、または送信タイムアウト期間が最大値「ｎ」を超えるまで、データを再送する。送信タイムアウト期間は、送信タイムアウト（ｎ）が起こるまでデータが再送されるごとに増加する。したがって最終的な再送が、ステップ１０１２において起こり、そこで最終的な再送タイムアウト期間１０１４を開始させるように示されている。送信タイムアウト期間１０１４の満了により、装置１０２は、ステップ１０１６において装置に閉鎖パケットを送信する。ステップ１０１８において、装置１０２は、接続を利用するアプリケーション１１４に、接続が切断されていることを通知して、ソケットを閉鎖する。ステップ１０２０において、接続が切断される。送信タイムアウト期間が、増加、減少しても、または１つの時間間隔で保持されてもよいことを、理解されたい。例えば、最大期間ではなくむしろタイムアウトの最大回数が、追跡されてもよい。

タイミング図において、装置１０２および１０４の一方または両方が、ブロッキングさまたはノンブロッキングであってもよいことを、理解されたい。したがって、幾つかの実施形態は、対応するアプリケーション１１４または１２２を通知することを記載しているが、そのような通知が、ソケット１０８および１１６がブロッキングであるか、またはノンブロッキングであるかに依存し、いつも起こるとは限らないことを、理解されたい。

図１１〜図１４までの実施形態は、様々な実装詳細の例を記載している。これらの実施形態は、簡便性を目的として抽象的な非同期の例を用いて記載されたものもあるが、実際の実装が、ソケットから読み込み、そして書き込むアプリケーションスレッド、およびタイミングを取り扱う別のソケットスレッドを有し得ることを、理解されたい。これらの実施形態は、ラウンドトリップタイム（ＲＴＴ）／タイムアウト計算および再試行、輻輳ウィンドウの計算、シリーウィンドウシンドロームの回避および遅延ＡＣＫ、循環バッファの実装、タイマー管理、暗号化／パンチング／ＮＡＴ問題、ブロッキング／ノンブロッキングのアクションおよび通知、ならびにＲＶＢＤＤＳ接続の性能を改良するために用いられ得るシステムコンフィギュレーヨン変数を記載している。

図１１を参照すると、フローチャートは、ＲＴＴが計算および使用されてパケットの再送を制御する方法をはじめとし、単一パケット（例えば、単一パケット２００）の送信を示す方法１１００の一実施形態を示す。単一パケットの転送は、ＲＶＢＤＤＳパケットヘッダ２０４を実装する基本的動作である。後により詳細に議論される複数パケットの転送は、遠隔ウィンドウおよび輻輳ウィンドウのサイズに基づく。単一パケットの転送において、パケットが送信され、送信元（例えば、装置１０２）は、肯定応答を待つ。肯定応答が、タイムアウト期間内に受信されなければ、パケットが再転送される。肯定応答を受信せずに特定数の再試行が行われた後、接続が切断される。

ＲＴＴの計算は、方法１１００において重要な役割を担う。ＲＴＴは、最初、パケットごとに１つのベースで計算され、再転送がパケットに関して起こらなかった場合のみ計算される。再転送が起これば、方法１１００は、送信されたパケット（例えば、元々のパケットまたはそのパケットの再転送）のどれが肯定応答に対応するのかを決定できない。ＲＴＴの計算は、ネットワーク条件により起こるより長期の変更に応答するように設計されている。しかし、送信されたパケットに起こる各一時的遅延によりＲＴＴが急速に変化することを防ぐために、ＲＴＴは徐々に改良される。

したがってステップ１１０２において、装置１０２は、単一パケット２００を送信する。ステップ１１０４において、タイムアウト（例えば、先に記載された送信タイムアウト）は、
タイムアウト＝ＲＴＴ^＊Ｘ＋ＲＴＴｖａｒ^＊Ｙ
（ここで、ＲＴＴは、先に計算されたＲＴＴ値（ステップ１１１８参照）であり、ＲＴＴｖａｒは、先に計算されたＲＴＴ分散値（ステップ１１２０参照）であり、Ｘは、ＲＴＴの倍数であり、Ｙは、パーセント値である）として計算される。より具体的には、ＲＴＴの分散がゼロに近いとしても、タイムアウトをＲＴＴの倍数として有することが望ましい場合がある。この倍数は、Ｘにより示され、本実施例においては１．５である。顕著なＲＴＴ分散が存在する場合、パケットが減少し得る統計学的釣鐘曲線を大きなパーセント値で含むタイムアウトにすることが望ましい場合がある。このパーセント値は、Ｙにより示され、本実施例においては３である。ＸおよびＹの一方または両方の値が、より高くても、または低くてもよく、この実施例に示された値に限定されないことを、理解されたい。この方式においてタイムアウトを変動させることにより、方法１１００は、変動条件に適合させようと試みる。必要とされる時間よりも長いタイムアウトにすると、効率的方式で応答するのに十分急速にパケットロスを検出することができない。十分に長くないタイムアウトでは、パケットを不必要に再転送する可能性がある。

ステップ１１０４におけるタイムアウトの計算の後、方法１１００は、ステップ１１０６に続き、タイムアウトが起こったか、またはＡＣＫがステップ１１０２において送信されたパケットについて受信されたか、が決定される。タイムアウトが起こっていれば、方法１１００は、ステップ１１０８に移動して、現行のＲＴＴが、
ＲＴＴ^＊＝<ＲＴＴバックオフファクター>
（ここで、ＲＴＴバックオフファクターは、タイムアウトを延長させるために用いられる）として計算される。より具体的には、タイムアウトを超えた時に、再転送が起こる。アルゴリズム（例えば、カーンアルゴリズム）が、ＲＴＴ値を指数関数的にバックオフして、ＲＴＴ値をネットワーク標準値に徐々にフォールバックさせるために用いられてもよい。ネットワーク上の問題によりパケットが下降している場合、再転送は、問題の更なる深刻化に寄与する可能性がある。これを回避するために、タイマーを急速にバックオフすることが望ましい場合がある。したがってタイムアウトがあるごとに、該方法は、本実施例においては２であるＲＴＴバックオフファクターにより、ＲＴＴをバックオフする。この値がより高くても、または低くてもよく、本実施例に示された値に限定されないことを、理解されたい。

ＲＴＴバックオフファクターを適用した後、方法１１００は、ステップ１１１０に続き、タイムアウトが最大時間間隔（例えば、最大タイムアウトファクター）を超えるか、について決定される。例えば最大許容タイムアウトが、１６秒に設定されてもよい。タイムアウトが１６秒を超えると、方法１１００が、ステップ１１１２に移動して、パケットを再転送せずに終了する。装置１０２は、これが起こると接続が閉鎖されたと判断することができる。タイムアウトが１６秒を超えなければ、方法１１００は、ステップ１１０２に戻り、パケットを再送する。したがって再転送の回数は、最大タイムアウトファクターにより制御される。

再度ステップ１１０６を参照するが、ＡＣＫが受信されると、方法１１００はステップ１１１４に続く。ステップ１１１４において、パケットが再転送されたか、について決定される。パケットが再転送されていれば、方法１１００は、ステップ１１１６に移動し、そこでその方法は終了する。パケットが再転送されていなければ、方法１１００はステップ１１１８に続き、そこで新しいＲＴＴ値が
ＮｅｗＲＴＴ＋＝（ＣｕｒｒＲＴＴ−ＯｌｄＲＴＴ）^＊１／Ｍ
（ここで、ＮｅｗＲＴＴは、ＲＴＴの新しい値であり、ＣｕｒｒＲＴＴは、ＲＴＴの現在の値であり、ＯｌｄＲＴＴは、ＲＴＴの過去の値であり、Ｍは、ＲＴＴ変動ファクタである）として計算される。Ｍの値が高いほど、ＲＴＴ値をより緩やかに変動させ、低い値ほど、ＲＴＴ値をより急速に変動させる。本実施例において、Ｍは、８であるが、この値がより高くても、または低くてもよく、この実施例に示された値に限定されないことを、理解されたい。ＲＴＴの所定の値、例えば１００ｍｓが最初に用いられてもよく、ＲＴＴ値が、その後そこから発展してもよいことに、留意されたい。

ＲＴＴの新しい値が計算されたら、方法１１００は、ステップ１１２０に移動して、新しいＲＴＴ分散値が、
ＮｅｗＲＴＴｖａｒ＋＝（ＣｕｒｒＲＴＴｖａｒ−（Ａｂｓ（ＣｕｒｒＲＴＴ−ＯｌｄＲＴＴ）^＊１／Ｎ
（ここで、ＮｅｗＲＴＴｖａｒは、ＲＴＴの新しい分散値であり、ＣｕｒｒＲＴＴｖａｒは、ＲＴＴの現在の分散値であり、ＣｕｒｒＲＴＴは、このセグメントについて計算されたＲＴＴであり、ＯｌｄＲＴＴは、ＲＴＴの過去の値であり、Ｎは、ＲＴＴ分散変動ファクタである）として計算される。Ｎの値が高いほど、ＲＴＴ分散値をより緩やかに変動させ、低い値ほど、ＲＴＴ分散値をより急速に変動させる。本実施例において、Ｎは、４であるが、この値がより高くても、または低くてもよく、この実施例に示された値に限定されないことを、理解されたい。ＲＴＴ分散値を計算した後、方法１１００は、ステップ１１１６に続く。

方法１１００は、単一パケットに関して記載されるが、装置１０２が、同期的および非同期的方式で複数パケットを取り扱うように構成され得ることに、留意されたい。更に、接続の確立に関連するタイムアウトが、送信データに関連するタイムアウトと異なるように装置１０２により取り扱われ得ることに、留意されたい。例えば、方法１１００のデータパケットに関して記載されたタイムアウトの変動する間隔とは異なり、接続パケットは、固定されたタイムアウト（例えば、５秒（デフォルトによる））を有していてもよく、一定して再送されてもよい（例えば、５秒ごとに１回で最大２０回（デフォルトによる））。取り扱いにおけるこの差は、接続を確立しようと試みる時にＲＴＴが未知であることが原因となり得る。

図１２を参照すると、フローチャートは、輻輳ウィンドウが計算され得る方法を示し、何バイトが装置（例えば、装置１０２）により送信され得るかを決定する、方法１２００の一実施形態を示す。一般に、ルータの稼働は、接続によってとられる経路を横切るに連れ変動するため、ネットワーク内で利用され得るバッファは、２つの装置の間（例えば、装置１０２と１０４の間）で各接続が異なっており、時間によっても変動する。したがって装置１０２により送信されるバイト数は、変動条件を基にして調整することができる。

一般に方法１２００は、バイト数を限定しており、装置１０２（送信元として）は、装置１０２により計算される輻輳ウィンドウおよび装置１０４で利用できるウィンドウサイズの最小数に何時でも転送することができる。装置１０４で利用できるウィンドウサイズは、装置１０２が装置１０４からウィンドウサイズ広告を受信するごとに、装置１０２上で更新される。装置１０２により送信されたが装置１０２が肯定応答を受信されていないバイトは、このウィンドウサイズから差し引かれる。別のウィンドウ広告が装置１０４から受信されるまで、装置１０２がデータを送信するごとに、この値が減少する。

ステップ１２０２において、遠隔ウィンドウサイズが、装置１０２と装置１０４の間で接続を確立する間に、装置１０４から装置１０２により得られて、装置１０２により注記される。ステップ１２０４において、輻輳ウィンドウは、最大セグメントサイズとして設定される（例えば、１セグメント）。ステップ１２０６において、装置１０２は、送信するデータを待つ（例えば、図１のアプリケーション１１４から）。

ステップ１２０８において、送信バイトサイズ（例えば、装置１０２により任意の１回で送信され得るバイト数）は、装置１０２（送信元）により計算される輻輳ウィンドウ、および装置１０４（受信元）で利用できる遠隔ウィンドウサイズの小さい方として設定される。ステップ１２１０において、送信バイトサイズが肯定応答されていないバイト数よりも多いか、について決定される。もしそうでないならば、方法１２００は、送信バイトサイズが肯定応答されたバイト数よりも大きくなるまで、ステップ１２１０に戻る。送信バイトサイズが、肯定応答されたバイト数よりも大きい場合、方法１２００は、ステップ１２１２に続き、セグメントが送信される。

ステップ１２１４において、ＡＣＫが装置１０４から受信されたか、について決定される。タイムアウトが、ＡＣＫの受信前に起これば、方法１２００は、ステップ１２１６に移動し、輻輳ウィンドウが、ステップ１２０８に戻る前に減少される。この減少は、指数関数的であってもよく（例えば、図示された通り２のファクターにより）、または他の非指数関数的値を利用して遂行されてもよい。ＡＣＫが、受信される場合、方法１２００は、ＡＣＫを含むパケットから現在の遠隔ウィンドウサイズを得る。

ステップ１２２０において、輻輳ウィンドウは、最後の輻輳が起こった輻輳ウィンドウのサイズの５０％を超えているか、について決定される。もしそうでないならば、方法１２００は、ステップ１２２４に移動して、このセグメントサイズだけ輻輳ウィンドウを増加させる。したがって、装置１０２が、セグメントの設定のためにＡＣＫを受信するごとに、それは輻輳ウィンドウを、更に１セグメント増加させる。言い換えれば、装置１０２は、輻輳ウィンドウをＡＣＫが受信されたバイト数だけ増加させる。輻輳ウィンドウが、最後の輻輳が起こった輻輳ウィンドウのサイズの５０％を超えていれば、方法１２００は、ステップ１２２２に移動して、輻輳ウィンドウを、１つのセグメントサイズをスローダウンファクターで割った値だけ増加させる。スローダウンファクターは、輻輳ウィンドウが、それまでの高い値からかなり離れた時に（例えば、最後に半減された時のその値）より高くなる数である。スローダウンファクターは、それまでの高い値からはなり離れている場合には、１または１未満になる傾向があり、比較的近い場合には、より高い値（例えば、８）になる可能性がある。これにより、輻輳ウィンドウに可能な最大サイズに達し、数回半減され、その後、同じサイズに繰り返し増加された時に起こり得る振動状況が防止されることに、留意されたい。ステップ１２２２または１２２４のいずれかの後、方法１２００は、ステップ１２０６に戻り、送信する更なるデータを待つ。

別の実施形態において、シリーウィンドウシンドロームなどの問題は、以下の通り取り扱うことができる。装置１０４（受信元）が消費するよりも急速に、装置１０２（送信元）がデータを転送すれば、装置１０４のバッファが充填される。その場合、装置１０４のアプリケーションが、１回に１バイト読み込めば、それらの読み込みのそれぞれが、１つのウィンドウ広告をもたらす。これにより、装置１０２は、装置１０４に丁度１バイト送信することになる。この１回に１バイトの転送が、ネットワーク帯域幅の使用において極めて非効率的でシリーウィンドウシンドロームと呼ばれる定常状態に達する可能性がある。

装置１０２は、送信元と同様の問題に陥る可能性がある。装置１０２のアプリケーションが、データを１回に１バイト書き込む場合、そして装置１０２が、データの全てを既に送信した場合、装置１０２は、アプリケーションから受信するバイトごとに１パケットを送信し得る。これは、同じ問題をもたらすことになる。

ネットワークの別の非効率的使用が、受信元としての装置１０４により送信された肯定応答を始める。多くの場合、幾つかのデータを受信するアプリケーションは、幾つかのデータを直ちに送り返す。そのような場合、別の肯定応答は、必要ない。同じく送信元としての装置１０２は、パケットの束を送信している時に、各パケットを別個に肯定応答する必要はない。その代わりに、複数パケットが、単回の肯定応答によって肯定応答され得る。

ネットワークの非効率的使用をもたらすこれらおよび他の問題は、以下の３つのメカニズムの１つ以上により取り組むことができる。最初に、送信元としての装置１０２は、送信されるデータがセグメントの半分などの特定のサイズより小さいことを判定するように構成されていてもよい。これが起こる時、装置１０２は、利用できるウィンドウサイズが存在する場合でも、データを直ちに送信しない。その代わりに装置１０２は、タイマーを開始して装置に更なるデータ（受信していれば）を集めさせ、タイマーが満了になるか、または適切なデータが集められた時だけ、データを送信させる。タイマーが満了になった時に送信されたデータは、最初に小さすぎて送信できなかった同じデータであってもよく、タイマーが、データを送信する前に追加の時間を提供することを、理解されたい。

２番目に、受信側としての装置１０４は、小さなウィンドウ広告を送信しないように構成されていてもよい。その代わりに装置１０４は、受信元のバッファの半分よりも大きなウィンドウ広告のみを送信する。

３番目に、受信元としての装置１０４は、パケットの受信を直ちに肯定応答しないように構成されていてもよい。受信されたパケットを直ちに肯定応答する代わりに、装置１０４は、タイマーを開始する（送信タイマーが、装置１０２で既にアクティブになっていなければ）。タイマーの満了前に装置１０４により受信される他のパケットも、肯定応答されない。その代わりに、装置１０４は、タイマーが満了になった時にパケットの全てについて単回の肯定応答を送信する。単回の肯定応答は、送信される準備のできた任意のデータと共に送信されてもよい。

図１３Ａおよび１３Ｂを参照すると、それぞれ受信バッファ１３００（例えば、図１の受信バッファ１１０）および送信バッファ１３２０（例えば、図１の送信バッファ１１２）の実施形態が、示されている。各バッファ１３００および１３２０は、バッファオブジェクトまたは他のデータ構造を用いて実装されていてもよく、本実施例においては循環バッファであるが、他のバッファ形式が用いられ得ることを理解されたい。装置のソケット（例えば、装置１０２のソケット１０８）は、受信バッファ１３００および送信バッファ１３２０の両方を維持する。

図１３Ａにおいて、データは、受信されたがまだ肯定応答されていない、または肯定応答されたがまだアプリケーションにより消費されていない、として示されている。図１３Ｂにおいてデータは、送信されたがまだ肯定応答されていない、またはアプリケーションから受信されたがまだ送信されていない、として示されている。

以下のポインタおよびポジションが、以下の表２に示される受信および送信バッファ１３００および１３２０の一方または両方により用いられ得る：

各バッファ１３００および１３２０は、セグメントのリストを維持することもできる。例えばバッファ１３００は、セグメント１３０２、１３０４、１３０６、１３０８および１３１０のリストを維持することができる。バッファ１３２０は、セグメント１３２２、１３２４、１３２６、１３２８および１３３０のリストを維持することができる。各セグメントは、各自のバッファ１３００または１３２０への開始ポインタ、およびサイズにより識別される。送信バッファ１３２０は、このセグメントに関して試行される再試行の数、および再試行に関連するタイマー識別子（ＩＤ）など、セグメントに関連する他のデータも維持することができる。これにより装置１０２は、タイマーが満了になった時にどのセグメントが再転送されるか、を決定することができる。

別の実施形態において、タイマー管理は、以下の通り遂行されてもよい。装置１０２は、タイマー管理のためのタイマーオブジェクトを含む。タイマーオブジェクトは、ソケットに関連する主な選択ループも取り扱い、以下の通り動作する。タイマーオブジェクトは、タイマーのデルタリストを維持し、常に、デルタリスト内の最初のアイテムによって付与されるタイムアウトを選択に通す。タイマーオブジェクトは、選択を出ると、どのタイマーが発火して、それらを順次コールしているか、をチェックする。ソケット内にあるデータのために選択が戻った場合、タイマーオブジェクトは、ソケットオブジェクトに適切に通知する。タイマーオブジェクトは、タイマーを追加しタイマーを除去する基本要素も提供することができる。タイマーを追加すると、タイマーに関する固有識別子に戻る。このＩＤは、タイマーが満了になった時にソケット内でコールされるハンドルタイムコール内に通される。

別の実施形態において、暗号化、パンチングおよびＮＡＴ問題は、以下の通り取り扱われてもよい。例示の目的として、パケットの全てが、標準の暗号化法を利用して暗号化されてもよい。ＮＡＴ装置（例えば、ＮＡＴルータ）内のピンホールが、周期的パンチパケットを送信することにより維持することができる。例えば装置１０２は、ＮＡＴルータに関連づけることができる。ＮＡＴルータが、装置１０２（即ち、送信元）のポート番号を変更し得るため、ＵＩＤがチェックされて、他の側のアドレスのコピーが、新しいポート番号を表すように変更されてもよい。受信元のアドレスと異なるアドレスをパンチングする、という意見も存在する可能性があり、パケットトランスポートに関与するＵＤＰリフレクタが存在するならば、それが利用されてもよい。そのようなＮＡＴ通過技術の例は、これまで組み入れられた２００５年８月３０日に出願された表題「ＳＹＳＴＥＭ ＡＮＤ ＭＥＴＨＯＤ ＦＯＲ ＴＲＡＶＥＲＳＩＮＧ Ａ ＮＡＴ ＤＥＶＩＣＥ ＦＯＲ ＰＥＥＲ−ＴＯ−ＰＥＥＲ ＨＹＢＲＩＤ ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ」の米国特許第７，５７０，６３６号に記載される。そのようなプロセスによりＲＶＢＤＳＳ接続は、ピアツーピア通信における様々な要件を支持することができる。

別の実施形態において、ブロッキング／ノンブロッキングのアクションおよび通知は、以下の通り取り扱われてもよい。ＲＶＢＤＤＳソケットは、動作のブロッキングおよびノンブロッキングモードの両方を支持する。動作のブロッキングモードにおいて、Ｃｏｎｎｅｃｔ、Ａｌｌｏｗ、Ｒｅａｄ、およびＷｒｉｔｅのコールは、全てブロッキングを起こし、完了の成功または失敗の場合だけ戻る。ノーティファイヤーが、ソケット内の様々な事象のユーザに通知するのに用いられてもよい。そのような事象の例は、ソケット状態が以下の状態の１つに変化している場合：ＣＬＯＳＥＤ、ＣＲＥＡＴＥＤ、ＣＯＮＮＥＣＴＩＮＧ、ＡＣＣＥＰＴＩＮＧ、またはＣＯＮＮＥＣＴＥＤ、ソケット内に更なるデータを書き込むためのスペースが存在する場合、およびソケット内に読み取られるデータが存在する場合、である。ノンブロッキングモードにおいて、アプリケーションは、これらの通知を利用して動作の状態を知ることを必要とする。

ＲＶＢＤＤＳの実装は、ＲＶＢＤＤＳ接続の挙動を改良するために変更され得る変数を含む。そのような変数の例を、以下の通り表３に示す。

これより図１４を参照してゆくが、後続の実施形態は、さまざまな実装例の詳細を、事象が単一スレッドで発生する時刻同期法で説明する。

図１４を参照すると、フローチャートは、方法１４００の１つの実施形態を例示しており、データの単一セグメントがどのように送信され得るのかを示している。方法１４００は、複数の場所で使用し得ることを留意されたい。例えば、方法１４００は、図１１のステップ１１０２で利用することができる。

ステップ１４０２では、タイマを、送信されるセグメント用タイムアウトの現在値に登録する。例えば、タイマは、先に述べたタイマオブジェクトに登録され得る。このタイマは、ソートされたタイマリストの中に正しい箇所で挿入される。ソートされたタイマリストは、絶対時間価値および関連データを保持し得、時間価値によってソートされ得る。固有ＩＤも、このタイマに割り当てられる。この後の実施形態で説明するように、そのような固有のタイマＩＤは、どのタイマが、期限切れ（すなわち、作動終了している）なのかを判定するのに使用される。このタイマＩＤは、セグメントに記憶される。

ステップ１４０４では、パケットを、セグメントのコンテンツで構築する。本実施例では、ステップ１４０４で構築されるパケットは、図２ＢのＵＤＰパケット２００であるが、いくつかの実施形態では、ＲＶＢＤＤＳパケットヘッダ２０４が、ＵＤＰパケット２００の前に構築される場合もあることも理解されたい。ステップ１４０６では、ＵＤＰパケット２００に、図３に示すようなＲＶＢＤＤＳパケットヘッダ２０４に関する情報を提供するための多くのアクションがとられる。ステップ１４０６に関して記載されているアクションはそれぞれ、方法１４００の別々のステップであり得ることを理解されたい。

本実施例では、ステップ１４０６のアクションは、パケット形式（例えば、データ、接続、受け付け、閉鎖またはパンチ）を挿入することを含む。送信されるデータがある場合には、送信バイトをセグメントの開始位置として挿入する、あるいは、送信されるデータがない場合には、別の値（例えば、ゼロ）を挿入する。すべてのデータが受信されるまでのバイトを、ＡＣＫバイトとして取得し、挿入する。パケットが正確な長さであることを確実にするのに必要な任意のパディングバイトを挿入し、パッドバイトの数を、パッド欄に挿入する。受信バッファの空きスペースの量を取得し、ウィンドウ欄に挿入する。

ステップ１４０８では、パケットを暗号化し、ステップ１４１０では、パケットを送信する。ステップ１４１２では、送信エラーが発生したかどうかを判定する。送信エラーが発生した場合には、方法１４００はステップ１４１４に進み、エラーは、戻される。送信エラーが発生しなかった場合には、このセグメントでの再試行の数が、ステップ１４１６で増やされる。

ステップ１４１８では、作動中のＡＣＫ待機タイマがあるかどうかに関して判定する。ＡＣＫ待機タイマが作動していない場合には、方法１４００はｓｕｃｃｅｓｓを返す。作動中のＡＣＫ待機タイマがある場合には、タイマは、ステップ１４２２で登録が抹消される。その理由は、いずれのデータパケットも、肯定応答を持っており、さらなる肯定応答を別途送信する必要がないからである。

図１５を参照すると、フローチャートは、方法１５００の１つの実施形態を例示しており、装置１０２（例えば、クライアントアプリケーションとしての図１のアプリケーション１１４）上のアプリケーションが、ＲＶＢＤＤＳソケット１０８上の装置１０４（例えば、サーバアプリケーションとしてのアプリケーション１２２に）に接続しようと試みるときに発生するステップを示している。

ステップ１５０２では、ソケットが装置１０２上で作成された状態にあるかどうかに関して判定される。ソケットが作成されていなかった場合には、方法１５００は、ステップ１５０４に移動してエラーを返す。ソケットが作成されている場合には、方法１５００は、ステップ１５０６に移動して、装置１０２が接続する予定の相手局アドレスを設定する（例えば、ソケットを結合する）。ステップ１５０８では、サービス品質（ＱｏＳ）が、そのソケットに対して必要とされ、使用可能であるかどうかに関して判定される。ＱｏＳが必要とされるかどうかは、例えば、アプリケーション１１４によって決まり得る。ＱｏＳが使用可能であるかどうかは、特定のインストール（例えば、ＱｏＳが装置１０２によって提供されているかどうか）によって決まり得る。ＱｏＳが必要とされ、かつ使用可能である場合には、方法１５００は、ステップ１５１０に移動し、ＱｏＳを確立する。本実施例では、ＱｏＳを確立するには、ウィンドウズ（登録商標）（Ｗｉｎｄｏｗｓ（登録商標））上のＧＱＯＳを介してこの流れに関するパケット上でＤｉｆｆＳｅｒｖ Ｃｏｄｅ Ｐｏｉｎｔ（ＤＳＣＰ）マーキングを有効にする必要がある。しかし、他のＱｏＳ方法を用いてもよいことを理解されたい。

ＱｏＳが必要とされないまたは使用可能でない場合には、方法１５００は、ステップ１５１２に移動し、ソケットをロックする。ステップ１５１４では、接続タイマを登録し、ステップ１５１６では、接続パケットをデータなしで送信する。ステップ１５１８では、パンチタイマを始動させる。ステップ１５２０では、ステータスは、「接続中」（例えば、図４の状態４０６）に変更され、アプリケーション１１４に、ステータス変更を通知する。ステップ１５２２では、ソケット受信器／タイマスレッド（この後の実施形態で説明するように）を開始する。

ステップ１５２４では、ソケットがブロッキングしているかどうかを判定する。ソケットがブロッキングしていない場合には、方法１５００は、ステップ１５３０に進んでソケットを解放し、方法１５００は戻る。ソケットがブロッキングしている場合には、方法１５００は、ステップ１５２６に移動してソケットを解放し、ステップ１５２６からステップ１５２８まで、方法１５００は、接続信号を待つ。受け付けパケットをソケットが受信した後、ソケットは、非ブロック化され、方法１５００は、ステップ１５２８からステップ１５３０に移動する。

図１６を参照すると、フローチャートは、方法１６００の１つの実施形態を例示しており、装置１０４（例えば、サーバアプリケーションとしての図１のアプリケーション１２２）上のアプリケーションが、ＲＶＢＤＤＳソケット１１６上の装置１０２（例えば、クライアントアプリケーションとしてのアプリケーション１１４から）からの接続要求を受け入れようと試みるときに発生するステップを示している。

ステップ１６０２では、ソケットが、装置１０４上に作成された状態にあるかどうかを判定する。ソケットが作成されていなかった場合には、方法１６００は、ステップ１６０４に移動して、エラーを返す。ソケットが作成されている場合には、方法１６００は、ステップ１６０６に移動して、装置１０４が接続する予定の相手局アドレスを設定する（例えば、ソケットを結合する）。ステップ１６０８では、サービス品質（ＱｏＳ）が、そのソケットに対して必要とされ、使用可能であるかどうかに関して判定される。ＱｏＳが必要とされるかどうかは、例えば、アプリケーション１２２によって決まり得る。ＱｏＳが使用可能であるかどうかは、特定のインストール（例えば、ＱｏＳが装置１０４によって提供されているかどうか）によって決まり得る。ＱｏＳが必要とされ、かつ使用可能である場合には、方法１６００は、ステップ１６１０に移動してＱｏＳを確立させる。本実施例では、ＱｏＳを確立するには、ウィンドウズ（登録商標）（Ｗｉｎｄｏｗｓ（登録商標））上のＧＱＯＳを介してこの流れに関するパケット上にＤｉｆｆＳｅｒｖ Ｃｏｄｅ Ｐｏｉｎｔ（ＤＳＣＰ）マーキングを有効にする必要がある。しかし、他のＱｏＳ方法を用いてもよいことを理解されたい。

ＱｏＳが必要とされないまたは使用可能ではない場合には、方法１６００は、ステップ１６１２に移動し、ソケットをロックする。ステップ１６１４では、パンチパケットをデータなしで送信し、ステップ１６１６では、パンチタイマを始動させる。装置１０４（端末受信側として）は、最初に、パンチパケットを発行しなければならないことを留意されたい。その理由は、装置１０４と関連付けられるＮＡＴ装置が、（前の実施形態で示したように）針穴を必要とする場合があるからである。針穴が必要とされるそのような事例では、装置１０２（リモートサイドとして）は、パンチが発生した場合のみに、ソケットを介して装置１０４に達することが可能である。

ステップ１６１８では、ステータスは、「受け入れ中」（例えば、図４の状態４１０）に変更され、アプリケーション１２２に、ステータス変更を通知する。ステップ１６２０では、ソケット受信機／タイマスレッド（この後の実施形態で説明するように）を始動させる。

ステップ１６２２では、ソケットがブロッキングしているかどうかを判定する。ソケットがブロッキングしていない場合には、方法１６００は、ステップ１６２８に進んでソケットを解放し、方法１６００は戻る。ソケットがブロッキングしている場合には、方法１６００は、ステップ１６２４に移動してソケットを解放し、ステップ１６２４からステップ１６２６まで、方法１６００は、接続信号を待つ。接続が確立したことを示すパケットをソケットが受信した後、ソケットは、非ブロック化され、方法１６００は、ステップ１６２６からステップ１６２８に移動する。

図１７Ａおよび図１７Ｂを参照すると、フローチャートは、方法１７００の１つの実施形態を例示しており、装置１０２（例えば、図１のアプリケーション１１４）上のアプリケーションが、ＲＶＢＤＤＳソケット１０８上でデータを送信しようと試みるときに発生するステップを示している。

ステップ１７０２では、アプリケーション１１４は、送信機能に、データを送信中である（または送信することを望んでいる）ことを示すように指令する。ステップ１７０４では、ソケットをロックする。ステップ１７０８では、ソケットが接続されているかどうか（例えば、図４の接続状態４０８にある）に関して判定する。ソケットが接続されていない場合には、方法１７００は、ステップ１７０８に移動して、ソケットを解放し、エラーを返す。

ソケットが接続されている場合には、方法１７００は、ステップ１７１０に移動して、送信バッファにスペースがあるかどうかを判定する。送信バッファ１１２にスペースがない場合には、方法１７００は、ステップ１７１２に移動して、ソケットがブロッキングしているかどうかを判定する。ソケットがブロッキングしていない場合には、方法１７００は、ステップ１７１４に進んでソケットのロックを解除し、「ブロックすることになる」を返す。ソケットがブロッキングしている場合には、方法１７００は、ステップ１７１６に移動してソケットのロックを解除し、方法１７００は、書き込み可能（例えば、ソケットにスペースが存在する）の信号を待つ。書き込み可能信号を受信すると、ソケットを、ステップ１７１８でロックし、方法１７００は、ステップ１７１０に戻る。

ステップ１７２０では、ステップ１７１０で判定されたときに送信バッファ１１２に空きスペースがあれば、送信バッファがいっぱいになるまで、可能な限り多くのバイトを送信バッファにコピーする。ステップ１７２２では、送信バッファ１１２のエンドポインタを新しい終結場所のポイントに設定する。ステップ１７２４では、送信されるバイト数が、送信バッファ１１２に書き込まれたばかりのバイト数と同じであるかどうかを判定する。送信バッファ１１２には、送信することが可能であったが、何らかの理由で送信され得なかった（例えば、遠隔ウィンドウがいっぱいであるまたは輻輳ウィンドウがいっぱいである）バイトが既に存在していたことを意味していることを留意されたい。したがって、これからバイトを送信しようと試みる理由は存在せず、それらのウィンドウが解放されるときに、データは、送信される。したがって、バイト数が同じである場合には、方法１７００は、ステップ１７２６に進み、ソケットのロックを解除して、バイト数を返す。バイト数が同じでない場合には、方法１７００は、ステップ１７２８（図１７Ｂ）に進む。

ステップ１７２８では、送信バイトの最大数は、図１２に関して先に記載したように、輻輳ウィンドウおよび遠隔ウィンドウのうちの小さい方である。ステップ１７３０では、未肯定応答バイトの数を取得する。前述したように、これらは、送信されたバイトであるが、しかし、肯定応答は、受信されなかった（例えば、スタートポインタから送信バッファ１１２の送信ポインタまでのバイト）。

ステップ１７３２では、未肯定応答バイトの数が、送信可能なバイトの最大数以上であるかどうかを判定する。未肯定応答バイトの数が、送信することができるバイトの最大数以上である場合には、方法１７００は、ステップ１７３４に移動し、ソケットのロックを解除し、バッファへ書き込まれるバイト数を返す。未肯定応答バイト数が、送信することができるバイトの最大数未満である場合には、方法１７００は、ステップ１７３６に移動し、送信することができるバイトの最大数および最大セグメントサイズの小さい方を使用してパケットを作成する。ステップ１７３８では、セグメントを含むパケットを送信する。ステップ１７４０では、エラーが発生したかどうかを判定する。エラーが発生しなかった場合には、方法１７００はステップ１７２８に戻る。エラーが発生した場合には、方法１７００は、ステップ１７３４に移動し、ソケットのロックを解除し、バッファへ書き込まれたバイト数を返す。

図１８を参照すると、フローチャートは、方法１８００の１つの実施形態を例示しており、装置１０２（例えば、図１のアプリケーション１１４）上のアプリケーションが、ＲＶＢＤＤＳソケット１０８上のデータを送信しようと試みるときに発生するステップを示している。図１７Ａおよび１７Ｂの前述の実施形態では、方法１７００は、アプリケーション１１４が送信することを求めた厳密なバイト数が送信されなかったかもしれないシナリオを説明した。本実施形態が説明するシナリオでは、厳密なバイト数が送信される。方法１８００は、ブロッキングソケットとだけ連携することを留意されたい。

ステップ１８０２では、アプリケーション１１４は、送信厳密機能に、厳密な量のデータを送信している（または送信することを望んでいる）ことを示すように指令する。ステップ１８０４では、ソケットが接続されている（例えば、図４の接続状態４０８である）かどうかを判定する。

ソケットが接続されていない場合には、方法１８００は、ステップ１８１２に移動してエラーを返す。ソケットが接続されている場合には、方法１８００は、ステップ１８０６に移動して、送信されることになっているバイトが全て送信されたかどうかを判定する。バイトが全て送信されていた場合には、方法１８００は、ステップ１８１２に移動する。バイトが全て送信されていなかった場合には、方法１８００は、ステップ１８０８に移動して、残りのバイトに関する送信を指令する。ステップ１８１０では、送信にエラーがあったかどうかを判定する。送信にエラーがあった場合には、方法１８００はステップ１８１２に移動する。送信にエラーがなかった場合には、方法１８００は、ステップ１８１４に移動する、送信されたバイト数が、未だ送信されていないバイト数から減算される。次いで、方法１８００は、ステップ１８０６に戻る。

図１９を参照すると、フローチャートは、方法１９００の１つの実施形態を例示しており、装置１０２上のアプリケーション（例えば、図１のアプリケーション１１４）が、ＲＶＢＤＤＳソケット１０８からデータを読み込もうと試みるときに発生するステップを示している。

ステップ１９０２では、アプリケーション１１４は、読み込み機能が、データを読み込み中である（または読み込むことを望んでいる）ことを示すように読み込み機能に指令する。ステップ１９０４では、ソケットは、ロックされる。ステップ１９０８では、受信バッファ１１０内の消費ポインタおよびエンドポインタの間に配置された何らかのバイトがあるかどうかに関して判定する。これは、アプリケーション１１４に所与され得る、連続した、残っているバイトの数を提供する。バイトがない場合には、方法１９００は、ステップ１９０８に進み、ソケットのロックを解除して、読み込むデータがあることを示す読み込み可能な事象を待つ。ステップ１９１０では、方法１９００が、読み込み可能信号によって起動すると、方法１９００は、ステップ１９１０に移動して、ソケットが依然として接続されている（例えば、図４の接続状態４０８にある）かどうかに関して判定する。ソケットが接続されていない場合には、方法１９００は、ステップ１９１２に移動して、ソケットを解放して、エラーを返す。ソケットが接続されている場合、またはステップ１９０６で判定されたときに、消費ポインタおよびエンドポインタの間で利用可能なバイトがある場合には、方法１９００は、ステップ１９１４に移動する。

ステップ１９１４では、要求されるバイト（例えば、アプリケーション１１４によって要求されるバイト数）または消費者ポインタおよびエンドポインタの間のバイト数の内の小さい方をコピーする。ステップ１９１６では、消費ポインタが、移動されてコピーされたバイトの終結をマーキングする場所を指し示す。ステップ１９１８では、開始ポインタを、移動して、消費ポインタおよびＡＣＫポインタの内の小さい方を指し示す。バイトも、空間が利用可能になると、受信バッファ１１０の中で移動され得る。このような動きは、常に発生するわけではないが、その理由は、消費されかつ肯定応答されたデータだけが、受信バッファ１１０から除去されるからである。これは、アプリケーション１１４によって消費され、このデータ用のＡＣＫ待機タイマがまだ期限が切れていないので、肯定応答されていない、未肯定応答バイトがあり得るからである。その上、一部のデータは、肯定応答され得るが、しかし、肯定応答されたデータの全てが、消費されるわけはなく、その理由は、アプリケーション１１４が、このデータに関する読み込みを発行していないからである。このようなわけで、両方の事象が発生するまで、データは受信バッファ１１０の中で移動され得ない。

ステップ１９２０では、完全に読み込まれたセグメントを削除してもよく、データが部分的に読み込まれた最終的なセグメントを枝切りすることができる。枝切りが発生する理由は、アプリケーションが、バイトが送受信されたときに、そのバイトではなく任意のバイトを読み込み得るからであり、この場合も、バイトが、本来アプリケーションによって書き込まれる方法では必ずしもない。さらに特に、典型的ストリーミングアプリケーションでは、受信側上でバイトを読み込む際の塊のサイズは、送信側で書き込まれた塊のサイズと一致する必要はない。例えば、送信側上でのアプリケーションが、２２００バイトをＲＶＢＤＤＳ接続へ書き込んだとする。本質的に、ＲＶＢＤＤＳ接続は、これをサイズ１４００バイトおよび８００バイトの２つのパケットとしてネットワークの外へストリームに送信し得る。受信側では、アプリケーションは、最初に１２バイトのヘッダを読み込み、サイズ２１８５バイトのデータおよび３バイトのパディングの存在を認識し得る。したがって、送信側でネットワークに書き込むシーケンスは、１４００バイトおよび８００バイト用であり、受信側は、サイズ１２バイト、２１８５バイトおよび３バイトの読み込みを発行する。この不一致が原因で、キューのセグメントは、完全に除去され得ず、それらが部分的に読み込まれるときに、一部のセグメントが、バッファに残される。

ステップ１９２２では、作動中のＡＣＫ待機タイマがあるかどうかに関して判定される。ＡＣＫ待機タイマがある場合には、方法１９００は、ステップ１９２４に進み、ソケットを解放し、コピーしたバイト数を返す。ＡＣＫ待機タイマがない場合には、方法１９００は、ステップ１９２６に移動し、ＡＣＫ待機タイマを登録する。肯定応答の送信は、ウィンドウ広告も送信することを留意されたい。ウィンドウ広告は、送信される必要があり、その理由は、開始ポインタは、潜在的に移動しており、受信バッファ４００６は、付加的なバイトを受信し得るスペースを追加し得るからである。したがって、遠隔ウィンドウ広告は、肯定応答に便乗して運ばれ得る。次いで、方法１９００は、ステップ１９２４へ進む。

図２０を参照すると、フローチャートは、方法２０００の１つの実施形態を例示しており、ソケット１０８（図１）からの受信データを処理し、本明細書において記載されているタイマを処理するスレッドによって使用され得るステップを示している。複数のスレッドは、方法２０００に関して記載されている機能性を実現するのに使用され得ることを理解されたい。本実施形態では、このスレッドでは、ソケット１０８に関する大部分のアクションが発生する。

ステップ２００２では、ソケットを閉じなければならないかどうかを判定する。ソケットを閉じなければならない場合には、方法２０００は、ステップ２００４に移動して、戻る。ソケットを閉じなくてもよい場合には、方法２０００はステップ２００６に進む。

ステップ２００６では、タイマは、ロックされる。ステップ２００８では、タイマリストの先頭のタイマの期限が切れているかどうかに関して判定する。タイマが期限切れである場合には、方法２０００は、ステップ２０１０に移動し、タイマのロックを解除する。タイマを処理する（ステップ２０１２）間、追加のタイマを、追加するまたは削除することができ、タイマリストを、タイマを処理する前にロックから解除する。ステップ２０１２では、この後の実施形態（図２１Ａ）で説明するように、期限が切れたタイマを処理する。ステップ２０１４では、このタイマは、タイマリストから除去され、方法２０００は、ステップ２００６に戻る。タイマは、タイマを処理した後に初めて除去される。これは、方法２０００がタイマを処理して終了する前に（例えば、タイマを処理する機能の現れる前に）このタイマＩＤが新しいタイマで使用される状況が発生するのを防止するためである。タイマリストの先頭のタイマが、ステップ２００８で判定されたとき期限が切れていなかった場合には、方法２０００は、ステップ２０１６に移動する。

ステップ２０１６では、定義済み期間（例えば、１０ミリ秒）および第１のタイマの期限が切れるまでの残りの時間の内の小さい方に設定される。ステップ２０１８では、選択は、ソケット１０８に実行される。選択は、ステップ２０１６で設定される待機時間の間、ソケットをブロックし、一方で、ソケット１０８上の入出力アクティビティを待つ。選択は、待機時間の失効、ソケット１０８上での入出力アクティビティの検知またはエラーの検知などのさまざまな事象が発生すると終了し得る。当該エラーは、ソケット１０８が閉じられており、そのため、選択するソケットが有効ではない、という理由から起こり得る。

ステップ２０２０では、ソケットを、閉じなければならないかどうかに関して判定する。ソケットを閉じなければならない場合には、方法２０００は、ステップ２０２２に移動して、戻る。ソケットを閉じてはならない場合には、方法２０００は、ステップ２０２４に進む。ステップ２０２４では、選択でエラーが発生した（例えば、エラーが、ステップ２０１８で発生した場合）かどうかを判定する。選択でエラーが発生しなかった場合には、方法２０００は、ステップ２０２６に移動し、この後の実施形態（図２２Ａ）で説明するようにメッセージを処理する。次いで、方法２０００は、ステップ２００２に戻る。ステップ２０２４で判定したときに、選択でエラーが発生した場合には、方法２０００は、ステップ２０２８に進む。

ステップ２０２８では、ソケット１０８を閉じ、ステップ２０３０では、アプリケーション１１４に、ソケットを閉じたことを通知する。ステップ２０３２では、待機中リーダ、ライタ、コネクタおよびフラッシャに、ソケットが閉じられた信号が送られ、ステップ２０３４で、方法２０００は戻る。

図２１Ａから図２１Ｃを参照すると、フローチャートは、方法２１００の１つの実施形態を例示しており、図２０の方法によってタイマを処理するのに用いられるステップを示している。例えば、方法２１００は、図２０のステップ２０１２で用いられ得る。

本実施形態は、数種類のタイマを使用している。例えば、接続メッセージ送信時には、接続タイマが作成されて、接続応答を待つ。パンチメッセージは、ＮＡＴピンホールを開いた状態に保持するために周期的に送信され、これらは、パンチタイマを使用する。前述のように、肯定応答は直ちに送信されないことがある。その代わりに、肯定応答タイマを使用してもよく、タイマの期限が切れる場合にだけ、肯定応答は送信される。肯定応答タイマの１つの利点は、多くのセグメントが短期間の間に受信される場合には、単一の肯定応答が、それぞれに１つではなく、セグメントに対して送信されることである。さらなる利点として、通常、受信されたデータは、待機中の読み出しにアプリケーション１１４から直ちに与えられ、それは、この受信データによって占有されたスペースの一部を解放する。この短い待機期間が、大きいウィンドウサイズの広告を可能にする。

上記３つのタイマ（すなわち、接続タイマ、パンチタイマおよびＡＣＫタイマ）はすべて、単一インスタンスタイマであり、単一ソケットにこれらのタイマのそれぞれのうちの１つだけが存在していることを意味している。他のタイマは、一般的にはセグメントタイマであり、送信されるセグメントのそれぞれが、関連付けられるセグメントタイマを有している。

ステップ２１０２では、ソケット１０８をロックする。ステップ２１０４では、タイマリストの先頭のタイマ（すなわち、処理されているタイマ）がＡＣＫタイマであるかどうかを判定する。タイマがＡＣＫタイマである場合には、方法２１００は、ステップ２１０６に移動して、ソケットが接続されているかどうかに関して判定する。ソケットが接続されていない場合には、方法２１００は、ステップ２１１０に移動して、ソケットを解放し、方法は戻る。ソケットが接続されている場合には、方法２１００は、データ無しでセグメント（例えば、ＡＣＫパケット）を送信して、次いで、ステップ２１１０に移動する。ステップ２１０４で判定したときに、タイマがＡＣＫタイマではない場合には、方法２１００はステップ２１１２に移動する。

ステップ２１１２では、タイマが、接続タイマであるかどうかに関して判定する。タイマが接続タイマである場合には、方法２１００は、ステップ２１２６（図２１Ｂ）に移動する。ステップ２１２６では、ソケットが、接続状態にあるかどうかに関して判定する。ソケットが接続状態にない場合には、方法２１００は、ステップ２１３６に移動して、ソケットを解放し、方法は戻る。ソケットが接続状態にある場合には、方法はステップ２１２８に移動して、接続再試行の数が、最大値を超えるかどうか（例えば、最大数の再試行を試みるかどうか）を判定する。接続再試行の数が最大値を超える場合には、方法２１００は、ステップ２１３０に移動してソケットを閉じる。ステップ２１３２では、アプリケーション１１４にソケット閉鎖を通知する。ステップ２１３４では、任意の待機中コネクタに信号を送り、次いで、方法２１００は、ステップ２１３６に移動し、ソケットを解放し、方法は戻る。接続再試行の数が最大値を超えない場合には、方法２１００は、ステップ２１３８に移動する。

ステップ２１３８では、タイマは、次の接続試みに登録される。ステップ２１４０では、接続再試行値を増やし、ステップ２１４２では、接続パケットをデータ無しで送信する。次いで、方法２１００は、ステップ２１３６に移動し、ソケットを解放し、方法は戻る。

再び図２１Ａに戻る。ステップ２１１２で判定したときに、タイマが接続タイマでない場合には、方法２１００は、ステップ２１１４に進む。ステップ２１１４では、タイマが、パンチタイマであるかどうかに関して判定する。タイマがパンチタイマである場合には、方法２１００は、ステップ２１１６に移動し、タイマを次のパンチに登録する。ステップ２１１８では、パンチパケットは、データ無しで送信される。次いで、方法２１００は、ステップ２１１０に移動し、ソケットを解放し、方法は戻る。タイマがパンチタイマでない場合には、方法２１００は、ステップ２１２０に移動する。

この時点で、方法２１００は、タイマが、ＡＣＫタイマ、接続タイマまたはパンチタイマでないことを判定している。したがって、ステップ２１２０では、ソケットが接続されているかどうかを判定する。ソケットが接続されていない場合には、方法２１００は、ステップ２１１０に移動し、ソケットを解放し、方法は戻る。ソケットが接続されている場合には、方法２１００は、ステップ２１２２に移動し、このタイマに関連付けられるセグメントをステップ２１２２で読み出す。このステップは、受信バッファ１１０用のセグメントリストからセグメントを入手する。

ステップ２１２４では、このタイマ用セグメントが、読み出されたかどうかに関して判定する。セグメントが読み出されなかった場合には、方法２１００は、ステップ２１１０に移動し、ソケットを解放し、方法は戻る。セグメントが読み出された場合には、方法２１００は、ステップ２１４４（図２１Ｃ）に移動する。

ステップ２１４４では、輻輳が発生しているかどうかに関して判定する。本実施例では、輻輳位相が現在発生しているかどうかを追跡するのに変数（例えば、ブール変数）を使用し得る。この位相は、最初にパケットが廃棄される時点から入ることができ、有効な肯定応答が受信されたときに出ることができる。輻輳が発生している場合には、方法２１００は、ステップ２１４６に移動し、輻輳ウィンドウサイズが、最新の輻輳ウィンドウとして留意される。最新の輻輳ウィンドウは、記録され、その結果、輻輳位相が終わって、これ以前の点に近づく際に、ウィンドウサイズの増大速度は低下し得る。次いで、方法２１００は、ステップ２１４８に移動する。ステップ２１４４で判定されたときに、輻輳が発生していない場合には、方法２１００は、同様にステップ２１４８に移動する。

ステップ２１４８では、現在のセグメントの前のセグメントを読み出す。ステップ２１５０では、前のセグメントが空白だったかどうか、または、セグメントがタイムアウトを受信しなかったかどうかに関して判定する。例えば、いくつかのセグメントのシーケンスのタイムアウトの場合には、タイムアウトは、シーケンスでの初めてのパケットが、向こう側に到達しなかった（したがって、肯定応答されなかった）からであろう。第１のパケットが応答されなかったので、他のパケットも、応答されない。この時、そうしたセグメントごとに輻輳ウィンドウおよびＲＴＴをバックオフし続ける必要はない。

したがって、以前のセグメントが空白である場合には、方法２１００は、ステップ２１５２に移動し、ＲＴＴバックオフが、ＲＴＴバックオフファクタ（図１１参照）によって発生する。ステップ２１５４では、輻輳ウィンドウバックオフは、輻輳バックオフファクタによって発生する。ステップ２１５６では、輻輳ウィンドウを検査して、輻輳ウィンドウが、単一パケットのサイズを下回っていないことを確実にする。次いで、方法２１００は、ステップ２１５８に移動する。ステップ２１５０で判定したときに、以前のセグメントがタイムアウトを受信しなかった場合には、方法２１００は、同様にステップ２１５８に移動する。

ステップ２１５８では、このセグメントでの再試行の数が、再試行の最大数を超えたかどうか、すなわちＲＴＴが最大ＲＴＴを超えたかどうかに関して判定する。これらの事象のどちらも発生しなかった場合には、方法２１００は、ステップ２１６０（セグメントが再送される）に進み、セグメントを再送信する。次いで、方法２１００は、ステップ２１６２に移動し、ソケットを解放し、方法は戻る。どちらかの事象が発生した場合には、方法２１００は、ステップ２１６４に移動し、ソケットを閉じる。ステップ２１６６では、アプリケーション１１４に、ソケットが閉じられたことを通知し、ステップ２１６８では、任意の待機中リーダ、ライタまたはフラッシャに、ソケットが閉じられた信号を送る。次いで、方法２１００は、ステップ２１６２に移動し、ソケットを解放し、方法は戻る。

図２２Ａから図２２Ｇを参照すると、フローチャートは、方法２２００の１つの実施形態を例示しており、それは、図２０の方法によってメッセージを処理するのに使用し得るステップを示している。例えば、方法２２００は、図２０のステップ２０２６で用いられ得る。

ステップ２２０２では、ソケット１０８をロックする。ステップ２２０４では、パケットをソケットから受信する。ステップ２２０６では、受信エラーが発生したかどうかを判定する。受信エラーが、発生した場合には、方法２２００は、ステップ２２０８に移動し、ソケットを解放し、方法は戻る。受信エラーが発生しなかった場合には、方法２２００は、ステップ２２１０に移動し、パケットを解読する。

ステップ２２１２では、ソースＩＰアドレスおよびＵＩＤが現在のソケット情報と一致するかどうかに関して判定する。一致していない場合には、方法２２００は、ステップ２２０８に移動し、ソケットを解放し、方法は戻る。一致している場合には、方法２１００は、ステップ２２１４に移動し、ＡＣＫバイト、送信バイト、遠隔ウィンドウ、パッドおよびパケット形式をパケットから取得する。ステップ２２１６では、パケット形式は、データ、接続、受け付け、その他および閉鎖の１つとして識別される。

図２２Ｂをさらに参照する。パケットをデータパケットとして識別すると、方法２２００は、ステップ２２２８に移動する。ステップ２２２８では、ソケットが、接続されているかどうかに関して判定する。ソケットが接続されていない場合には、方法２２００は、ステップ２２０８に移動し、ソケットを解放し、方法は戻る。ソケットが接続されている場合には、方法２２００は、ステップ２２３２に移動し、遠隔ウィンドウ値をステップ２２１４で取得した値で修正する。

ステップ２２３４では、現在のＡＣＫ位置が、パケットのＡＣＫバイトと同じであるかどうかに関して判定する。それらが同じである場合には、その場合輻輳は、発生していないので、方法２２００は、ステップ２２５４（図２２Ｃ）に移動する。

ステップ２２５４では、パケット長が、ＲＶＢＤＤＳパケットヘッダ２０４のヘッダより大きいかどうかに関して判定する。長さがより大きい場合には、パケットはデータを含んでいるので、方法２２００は、ステップ２２５６に移動し、ＡＣＫが必要とされていることが留意される。ステップ２２５８では、送信バイトが、現在のエンドポインタ位置より少ないかどうかに関して判定する。送信バイトが、現在のエンドポインタ位置より少ない場合には、方法２２００は、ステップ２２７４に移動し、利用可能な遠隔ウィンドウを、遠隔ウィンドウ位置から開始ポインタ位置を減算して（すなわち、利用可能な遠隔ウィンドウ＝遠隔ウィンドウ位置―開始ポインタ位置）算出する。送信バイトが現在のエンドポインタ位置より少なくない場合には、方法２２００は、ステップ２２６０に移動し、データが受信バッファ１１０をオーバーフローさせるかどうかに関して判定する。データが受信バッファ１１０をオーバーフローさせる場合には、方法は、ステップ２２７４に移動する。データが受信バッファをオーバーフローさせない場合には、方法２２００は、ステップ２２６２に進む。

ステップ２２６２では、このデータが、連続データのエンドを指すエンドポインタを超えたセグメントの中に完全に含まれているかどうかに関して判定する。したがって、データが受信されると、データがすでに受信されたかどうかを判定するために検査を行なう。エンドポインタは、受信バッファ１１０の連続データの終結を指すだけなので、ステップ２２６２は、データがエンドポインタの範囲内にあるかどうか、およびさらに、データが、すでに受信された他の不連続セグメントのいずれかに収まっているかどうかを判定する。データが、エンドポインタを越えたセグメントの中に完全に含まれる場合には、方法２２００は、ステップ２２７４に移動する。データがエンドポインタを越えたセグメントの中に完全に含まれない場合には、方法２２００は、ステップ２２６４に移動し、新しいセグメント作成して、受信バッファ１１０の正確な位置を指し示す。ステップ２２６６では、セグメントのタイマＩＤは、空白に設定され、タイマ用再試行数は、ゼロに設定される。次いで、セグメントを挿入する。ステップ２２６８では、データをコピーする。ステップ２２７０では、エンドポインタを再計算して、受信バッファ１１０の中の連続データの終結を指し示す。ステップ２２７２では、任意の待機中リーダには、新しいデータが受信バッファ１１０にあることを示す信号が送られる。次いで、方法２２００は、ステップ２２７４に移動する。

ステップ２２７４では、利用可能な遠隔ウィンドウを、遠隔ウィンドウ位置から開始ポインタ位置を減算して（すなわち、利用可能な遠隔ウィンドウ＝遠隔ウィンドウ位置−開始ポインタ位置）算出する。ステップ２２７６では、送信バイトの最大数は、輻輳ウィンドウおよび遠隔ウィンドウの内の小さい方に設定される。ステップ２２７８では、送信バッファ１１２の未肯定応答バイト数を取得する。次いで、方法２２００は、ステップ２２８０（図２２Ｄ）に移動する。

ステップ２２８０では、未肯定応答バイト数が、送信されたバイトの最大数以上かどうかに関して判定する。未肯定応答バイト数が送信バイトの最大数以上ではない場合には、方法２２００は、ステップ２２８２に移動し、サイズ値を、送信バイトの最大数および最大ＵＤＰパケットサイズの内の小さい方に設定する。ステップ２２８４では、ステップ２２８２で設定されたサイズ値の新しいセグメントを、送信バッファ１１２から読み出す。ステップ２２８６では、セグメントを送信し、ステップ２２８８では、ＡＣＫ要求フラグが、否と設定され、ＡＣＫは、ステップ２２８４で送信されるセグメントでは必要とされないことを示す。次いで、方法２２００は、ステップ２２９０に移動し、このステップは、未肯定応答バイト数が、送信バイトの最大数以上であると、ステップ２２８０で判定された場合の、次のステップでもある。

ステップ２２９０では、ＡＣＫ要求フラグが正しい、すなわち肯定応答が必要とされることを示していると設定されているかどうかに関して判定する。ＡＣＫが必要とされない場合には、方法２２００は、ステップ２２９６に移動し、ソケットを解放し、方法は戻る。ＡＣＫが必要とされる場合には、方法２２００は、ステップ２２９２に移動し、作動中のＡＣＫ待機タイマがすでにあるかどうかについて判定する。作動中のＡＣＫ待機タイマがある場合には、方法２２００は、ステップ２２９６に移動し、ソケットを解放し、方法は戻る。作動中のＡＣＫ待機タイマがない場合には、方法２２００は、ステップ２２９４に移動し、ＡＣＫ待機タイマを登録し、その後、方法２２００は、ステップ２２９６に移動する。

再度図２２Ｂを参照すると、ステップ２２３４で判定されたときに、現在のＡＣＫ位置がパケットのＡＣＫバイトと同じではない場合には、方法２２００は、ステップ２２３６に移動する。ステップ２２３６では、方法２２００は、発生している輻輳から移動して出る。ステップ２２３８では、輻輳ウィンドウがすぐ前の輻輳ウィンドウの半分より大きい（すなわち、現在の輻輳ウィンドウ>０．５^＊すぐ前の輻輳ウィンドウ）かどうかに関して判定する。現在の輻輳ウィンドウがより大きい場合には、方法２２００は、ステップ２２４０に移動し、輻輳ウィンドウは、減速ファクタによって分割されるＡＣＫバイトの数だけ増やされる（すなわち、輻輳ウィンドウ＝輻輳ウィンドウ＋（ＡＣＫバイト／減速ファクタ）。次いで、方法２２００は、ステップ２２４２に移動する。現在の輻輳ウィンドウが、ステップ２２３８で判定されたときより大きくない場合には、方法２２００は、ステップ２２４２に移動する。

ステップ２２４２では、（受信バッファ１１０のＡＣＫポインタによって表示される）ＡＣＫ位置が、受信パケットのＡＣＫバイトより少ないかどうかを判定する。ＡＣＫ位置が、より少ない場合には、方法２２００は、ステップ２２４４に移動し、現在のＡＣＫポインタ位置でのセグメントが受信バッファ１１０から読み出される。ステップ２２４６では、このセグメント用試行数が、１に等しい（すなわち、試行数＝１）かどうかに関して判定される。試行数が１に等しい場合には、方法２２００は、ステップ２２４８に移動し、このセグメント送信時間用ＲＴＴを再算出する。次いで、方法２２００は、ステップ２２５０に移動する。このステップは、再試行の数が１に等しくない場合に、方法２２００が移動するステップでもある。ステップ２２５０では、このセグメント用タイマを登録抹消し、ステップ２２５２では、受信バッファ１１０のＡＣＫポインタの位置を、このセグメントのサイズを反映するように動かす。次いで、方法２２００は、ステップ２２４２に戻る。

ＡＣＫ位置が、ステップ２２４２で判定されたときに、より少なくなかった場合には、方法２２００は、ステップ２２９８（図２２Ｅ）に移動する。ステップ２２９８では、開始ポインタを、消費ポインタ位置およびＡＣＫポインタ位置の内の小さい方に動かす。ステップ２３００では、バッファの開始位置を下回るセグメントをすべて削除する。ステップ２３０２では、任意の待機ライタに信号を送る。ステップ２３０４では、待機中のフラッシュが、あるかどうかに関して判定する。待機中のフラッシュがある場合には、方法２２００は、ステップ２３０６に移動し、送信バッファが空であるかどうかに関して判定する。送信バッファが空である場合には、方法２２００は、ステップ２３０８に移動し、待機フラッシャに信号を送る。次いで、方法２２００は、前述したように２２５４（図２２Ｃ）および後続のステップに移動する。方法２２００は、ステップ２３０４で判定されたときに待機中フラッシュがない場合、またはステップ２３０６で判定されたときに送信バッファが空ではない場合にも、ステップ２２５４に移動する。

再度図２２Ａを参照すると、パケット形式は、接続パケットとして識別され得る。さらに図２２Ｆを参照する。パケットを接続パケットとして識別すると、方法２２００をステップ２３１０へ移動させる。ステップ２３１０では、ソケットが、接続状態にあるかどうかに関して判定する。ソケットが接続状態にない場合には、方法２２００は、ステップ２３２２に移動し、ソケットを解放し、方法は戻る。ソケットが接続状態にある場合には、方法２２００はステップ２３１２に移動し、ステータスを接続中に設定する。ステップ２３１４では、アプリケーション１１４にステータス変更を知らせる通知を送信する。ステップ２３１６では、任意の待機コネクタに信号を送る。ステップ２３１８では、遠隔ウィンドウサイズを受信パケットから取得する。ステップ２３２０では、接続タイマを登録抹消する。次いで、方法２２００は、ステップ２３２２に移動し、ソケットが解放されて、方法は戻る。

再度図２２Ａを参照すると、パケット形式は、受け付けパケットとして識別され得る。さらに図２２Ｇを参照する。パケットを受け付けパケットとして識別すると、方法２２００をステップ２３２４へ移動させる。ステップ２３２４では、ソケットが、受け付け状態にある、またはいかなるバイトも受信せずに接続しているかどうかに関して判定する。ソケットが受け付け状態にない、またはいかなるバイトも受信せずに接続している場合には、方法２２００は、ステップ２３３６に移動し、ソケットを解放し、方法は戻る。ソケットが受け付け状態にある場合、またはいかなるバイトも受信せずに接続している場合には、方法２２００はステップ２３２６に移動し、ステータスを接続中に設定する。ステップ２３２８では、アプリケーション１１４にステータス変更を知らせる通知を送信する。ステップ２３３０では、任意の待機コネクタに信号を送る。ステップ２３３２では、遠隔ウィンドウサイズを受信パケットから取得する。ステップ２３３４では、受け付けパケットをデータ無しで送信する。次いで、方法２２００は、ステップ２３３６に移動し、ソケットが解放されて、方法は戻る。

再度図２２Ａを参照すると、パケット形式は、データ、接続、受け付けまたは閉鎖、ではないパケットとして識別され得る。この例では、このパケットは、周知の形式ではない。方法２２００は、ステップ２２１８に移動し、ソケットが解放されて、方法は戻る。認知されていない形式のパケットには、他の処理工程を実施してもよいことを理解されたい。

ステップ２２１６は、さらに、パケットを閉鎖パケットとして識別し得る。そのように識別された場合には、方法２２００は、ステップ２２２０に移動し、ソケットを閉じる。ステップ２２２２では、アプリケーション１１４に、ソケット閉鎖を通知する。ステップ２２２４では、任意の待機リーダ、ライタ、コネクタおよびフラッシャにソケットを閉じた信号を送る。次いで、方法２２００は、ステップ２２２６で戻る。

図２３を参照すると、コンピュータシステム２３００の１つの実施形態が例示されている。コンピュータシステム２３００は、通信装置、文書サーバ、エンドポイントおよび／またはアクセスサーバなどの、システムコンポーネントまたは計算装置の１つの可能な例である。コンピュータシステム２３００は、制御装置（例えば、中央演算処理装置（「ＣＰＵ」））２３０２、記憶装置２３０４、入出力（「Ｉ／Ｏ」）装置２３０６およびネットワークインターフェース２３０８を含み得る。コンポーネント２３０２、２３０４、２３０６、および２３０８は、輸送システム（例えば、バス）２３１０によって相互接続されている。電源（ＰＳ）２３１２は、コンピュータシステム２３００のコンポーネント、例えばＣＰＵ２３０２および記憶装置２３０４などに、電源を供給することができる。コンピュータシステム２３００は、異なったように構成されてもよく、列挙されたコンポーネントのそれぞれは、実のところ、いくつかの異なったコンポーネントを表現し得ることを理解されたい。例えば、ＣＰＵ２３０２は、実のところ、マルチプロセッサまたは分散処理システムを表現し得る。記憶装置２３０４は、さまざまなレベルのキャッシュメモリ、メインメモリ、ハードディスクおよび遠隔記憶場所を含み得る。入出力装置２３０６は、モニタ、キーボードなどを含み得る。ネットワークインターフェース２３０８は、ネットワーク１０５（図１）との１つ以上の有線接続および／または無線接続を供給している１つ以上のネットワークカードを含み得る。したがって、広範囲にわたる適応性が、コンピュータシステム２３００の構成には予想される。

コンピュータシステム２３００は、マイクロソフト（ＷＩＮＤＯＷＳ（登録商標）など）、アップル（Ｍａｃ ＯＳ Ｘなど）、ＵＮＩＸ（登録商標）およびＬＩＮＵＸ（登録商標）によって提供されるオペレーティングシステムのさまざまなバージョンなどの、任意のオペレーティングシステム（または複数のオペレーティングシステム）を使用し得、また、コンピュータシステム２３００の使用に依存している、携帯用装置、パーソナルコンピュータおよびサーバのために特異的に開発されたオペレーティングシステムを含み得る。オペレーティングシステムは、他の命令と同様に、記憶装置２３０４に記憶することができ、プロセッサ２３０２によって実行することができる。例えば、コンピュータシステム２３００が通信装置１０２および１０４の内の１つである場合には、記憶装置２３０４は、図４から図２２Ｇに関して説明したメッセージシーケンスおよび方法の一部もしくは全部を実行する命令を含み得る。

したがって、１つの実施形態では、第１の通信装置および第２の通信装置の間で仮想双方向データストリームを使用する、データをストリーミングする方法は、第１の装置によって、ストリーミングデータパケットＤ１を作成することと、第１の装置によって、データセグメントおよびＤ１をコネクションレストランスポート層パケットのペイロードセクションの中に挿入することであって、Ｄ１およびトランスポート層パケットの少なくとも１つは、Ｄ１と共に送信されるデータセグメントのデータストリームの開始位置を識別する送信欄と、すべてのデータが第１の装置によって受信されたところまでのデータストリームの箇所を識別する肯定応答（ＡＣＫ）欄と、データストリームで第１の装置によって使用される接続を識別する固有の識別子（ＵＩＤ）と、第１の装置の受信バッファで利用可能なスペース容量を識別するウィンドウ欄と、パケット形式欄と、Ｄ１が所定の長さを有することを確実にするのに使用されるパディングの量を識別するパッド欄と、第１の装置のネットワークアドレスと、第２の装置のネットワークアドレスと、トランスポート層パケットの長さとを含んでいる、データセグメントおよびＤ１をコネクションレストランスポート層パケットのペイロードセクションの中に挿入することと、第１の装置によって、トランスポート層パケットを第２の装置に送信することと、第１の装置から第２の装置まで先に送信されたパケットの第１のＲＴＴおよび第２のＲＴＴに基づく現在のラウンドトリップ時間（ＲＴＴ）および設定可能なＲＴＴ変動ファクタを、第１の装置によって、取得することと、以前のＲＴＴ分散に基づく現在のＲＴＴ分散、第１のＲＴＴおよび第２のＲＴＴおよび設定可能なＲＴＴ分散変動ファクタを、第１の装置によって、取得することと、現在のＲＴＴおよび現在のＲＴＴ分散に基づいてＤ１用タイムアウトを第１の装置によって計算することと；タイムアウトが所定のタイムアウト制限を超えない場合には、およびＤ１用ＡＣＫが、第２の装置から受信されなかった場合には、第１の装置によってＤ１を再送することと、を含む。方法は、第１の装置から第２の装置まで先に送信されたストリーミングデータパケットＤ２用のＲＴＴとして現在のＲＴＴを、ＲＴＴ＋＝（ＣｕｒｒＲＴＴ−ＯｌｄＲＴＴ）^＊１／Ｍのように、第１の装置によって、計算することをさらに含み得、ＣｕｒｒＲＴＴは、Ｄ２の前に、第１の装置から第２の装置に送信されたストリーミングデータパケットＤ３の第１のＲＴＴを表し、ＯｌｄＲＴＴは、Ｄ３の前に、第１の装置から第２の装置に送信されたストリーミングデータパケットＤ４の第２のＲＴＴを表し、Ｍは、設定可能なＲＴＴ変動ファクタを表している。方法は、Ｄ２用に計算されたＲＴＴｖａｒとして現在のＲＴＴ分散（ＲＴＴｖａｒ）を、ＲＴＴｖａｒ＋＝（ＣｕｒｒＲＴＴＶａｒ−抗体（ＣｕｒｒＲＴＴ−ＯｌｄＲＴＴ））^＊１／Ｎのように、第１の装置によって、計算することをさらに含み得、ＣｕｒｒＲＴＴＶａｒは、Ｄ３のＲＴＴｖａｒを表し、かつ以前のＲＴＴ分散であり、Ｎは、設定可能なＲＴＴ分散変動ファクタを表している。Ｄ１用タイムアウトを、タイムアウト=ＲＴＴ ^＊ Ｘ ＋ ＲＴＴｖａｒ ^＊ Ｙとして計算し得、Ｘは、Ｄ２のＲＴＴの倍数であり、Ｙは、ストリーミングデータパケットＲＴＴの割合に基づくタイムアウト分散である。方法は、タイムアウトが所定のタイムアウト制限を超えた場合、およびＤ１用ＡＣＫが、第２の装置から受信されなかった場合には、新しいＲＴＴおよび現在のＲＴＴ分散に基づいてＤ１用新しいタイムアウトを、第１の装置よって、計算することをさらに含み得、新しいＲＴＴは、現在のＲＴＴを定義した時間バックオフファクタによって増大することによって取得される。方法は、第１の装置によってトランスポート層パケットを再送する前に、第２の装置によるＤ１の受領を肯定応答する、第２の装置からのＡＣＫを、第１の装置によって、受信することをさらに含み得、ＡＣＫの受領は、第１の装置がトランスポート層パケットを再送するのを止める。方法は、ＡＣＫが第２の装置から受信された場合には、セグメントが再送信されたかどうかを、第１の装置によって、判定することと、セグメントが再送信されなかった場合には、Ｄ１に基づいて新しいＲＴＴおよび新しいＲＴＴＶａｒを計算することをさらに含み得る。Ｄ１に基づいて新しいＲＴＴおよび新しいＲＴＴＶａｒを計算することは、ＲＴＴ＋＝（ＣｕｒｒＲＴＴ−ＯｌｄＲＴＴ）^＊１／Ｍとして、新しいＲＴＴを計算することであって、ＣｕｒｒＲＴＴは、Ｄ２のＲＴＴを表し、ＯｌｄＲＴＴは、Ｄ３のＲＴＴを表している、新しいＲＴＴを計算することと、ＲＴＴｖａｒ＋＝（ＣｕｒｒＲＴＴＶａｒ−Ａｂｓ（ＣｕｒｒＲＴＴ−ＯｌｄＲＴＴ））^＊１／Ｎとして、新しいＲＴＴｖａｒを計算することであって、ＣｕｒｒＲＴＴＶａｒは、Ｄ２のＲＴＴｖａｒを表している、新しいＲＴＴｖａｒを計算することと、を含み得る。方法は、第１の装置によって、第２の装置からストリーミングデータパケットＤ２を受信することと、第１の装置によって、ＡＣＫをＤ１のＡＣＫ欄に挿入することであって、ＡＣＫがＤ２の受領を応答している、ＡＣＫを挿入することと、をさらに含み得る。方法は、第１の装置によって、第２の装置との接続を開始することと、第１の装置によって、第２の装置とのデータストリーム用接続を確立することと、第１の装置によって、接続を確立する間に第２の装置の遠隔ウィンドウサイズを取得することであって、遠隔ウィンドウサイズは、第２の装置上でのデータストリーム用に利用可能なスペースの量を識別する、遠隔ウィンドウサイズを取得することと、をさらに含み得る。方法は、第１の装置によって、第２の装置から接続の要求を受信することと、第１の装置によって、接続を確立する間に第１の装置のウィンドウサイズを第２の装置に送信することであって、ウィンドウサイズは、第１の装置上でのデータストリーム用に利用可能なスペースの量を識別する、ウィンドウサイズを送信することと、をさらに含み得る。方法は、更新されたウィンドウサイズをＤ１のウィンドウ欄に挿入することをさらに含み得る。第１の装置および第２の装置は、互いに直接通信するピアツーピア装置でもよく、方法は、第１の装置によって、第２の装置との接続のためにピアツーピアセッションを確立することをさらに含み得る。第１の装置および第２の装置間の信号送信は、セッション確立プロトコル（ＳＩＰ）対応信号送信でもよい。トランスポート層パケットは、ユーザーデータグラムプロトコル（ＵＤＰ）パケットでもよい。

別の実施形態では、第１の装置と第２の装置の間で仮想双方向データストリームを使用する、データをストリーミングする方法は、第１の装置によって、第２の装置との仮想双方向データストリーム接続を確立することと、第１の装置によって、第２の装置からストリーミングデータパケットＤ１を受信することと、第１の装置によって、第１の装置から第２の装置に接続を介して送信されるセグメント用ストリーミングデータパケットＤ２を作成することであって、Ｄ２は、データストリームのデータセグメントの箇所を識別する送信欄と、Ｄ１用肯定応答（ＡＣＫ）欄と、第１の装置によって使用されるデータストリーム用接続を識別する固有の識別子と、パケット形式欄と、第１の装置の受信バッファで利用可能なスペースの量を識別するウィンドウ値と、を有している、ストリーミングデータパケットＤ２を作成することと、第１の装置によって、第１の装置のＩＰアドレス、第２の装置のＩＰアドレス、トランスポート層パケットの長さ、セグメントおよびＤ２を含むコネクションレストランスポート層パケットを作成することと、第１の装置によって、トランスポート層パケットを第２の装置に送信することと、第１の装置によって、ラウンドトリップ時間（ＲＴＴ）およびＲＴＴ分散に基づいてＤ２用タイムアウトを計算することであって、ＲＴＴおよびＲＴＴ分散は、第１の装置から第２の装置に先に送信されたストリーミングデータパケットＤ３およびＤ４に基づいている、Ｄ２用タイムアウトを計算することと、タイムアウトが所定のタイムアウト制限を超えない場合およびＤ２用ＡＣＫが、第２の装置から受信されなかった場合には、第１の装置によって、Ｄ２を再送することと、を含む。方法は、第１の装置によって、ＲＴＴ＋＝（ＣｕｒｒＲＴＴ−ＯｌｄＲＴＴ）^＊１／Ｍとして、新しいＲＴＴを計算することをさらに含み得、ＣｕｒｒＲＴＴは、Ｄ３のＲＴＴを表し、ＯｌｄＲＴＴは、Ｄ４のＲＴＴを表し、Ｍは、設定可能なＲＴＴ変動ファクタを表している。方法は、第１の装置によって、ＲＴＴｖａｒ＋＝（ＣｕｒｒＲＴＴＶａｒ−Ａｂｓ（ＣｕｒｒＲＴＴ−ＯｌｄＲＴＴ））^＊１／Ｎとして、新しいＲＴＴ分散（ＲＴＴｖａｒ）を計算することをさらに含み得、ＣｕｒｒＲＴＴＶａｒは、Ｄ３のＲＴＴ分散を表し、Ｎは、設定可能なＲＴＴ分散変動ファクタを表している。第１の装置によって、第２の装置からＤ１を受信することは、第１の装置によって、第２の装置からデータストリームに関連付けられるコネクションレストランスポート層パケットを受信することと、第１の装置によって、Ｄ１およびデータストリームのセグメントをトランスポート層パケットから抽出することを含み得る。方法は、第１の装置によって、Ｄ１と共に送信されるセグメントのデータストリームの開始位置を識別する送信欄と、すべてのデータが第２の装置によって受信されたところまでのデータストリームの箇所を識別する肯定応答（ＡＣＫ）欄と、データストリームのために第２の装置で使用される接続を識別する識別子（ＵＩＤ）と、第２の装置の受信バッファで利用可能なスペース容量を識別するウィンドウ欄値と、パケット形式欄値と、をＤ１から取得することをさらに含み得る。方法は、第１の装置によって、Ｄ１のウィンドウ欄値に基づいて遠隔ウィンドウ値を更新することをさらに含み得る。方法は、第１の装置によって、Ｄ１のＡＣＫ欄値に基づいて第１の装置の送信バッファの中の送信されたポインタをアップデートすることをさらに含み得る。仮想双方向データストリーム接続は、第１または第２の装置のどちらかによって開始され得る。第１の装置によって、第２の装置との仮想双方向データストリーム接続を確立することは、第１の装置および第２の装置の間にピアツーピアセッションを確立することを含み得、信号送信およびデータが、第１の装置および第２の装置の間で直接伝達される。

さらに別の実施形態では、通信装置は、無線および有線ネットワークの少なくとも１つを介して通信を送信および受信するように構成されるネットワークインターフェースと、ネットワークインターフェースに連結された制御装置と、制御装置に連結されたメモリと、を含んでおり、メモリは、その上に、制御装置によって実行されるために記憶された複数の命令を有しており、命令は、第１の装置によって、第２の通信装置との仮想双方向接続を確立することと、第１の装置によって、第２の装置からストリーミングデータパケットＤ１を受信することと、第１の装置によって、第１の装置から第２の装置に接続を介して送信されるセグメント用ストリーミングデータパケットＤ２を作成することであって、Ｄ２は、データストリームのデータセグメントの箇所を識別する送信欄と、Ｄ１用肯定応答（ＡＣＫ）欄と、第１の装置によって使用されるデータストリーム用接続を識別する固有の識別子と、パケット形式と、第１の装置の受信バッファで利用可能なスペースの量を識別するウィンドウ値と、を有している、ストリーミングデータパケットＤ２を作成することと、第１の装置によって、第１の装置のＩＰアドレス、第２の装置のＩＰアドレス、トランスポート層パケットの長さ、セグメントおよびＤ１を含むコネクションレストランスポート層パケットを作成することと、第１の装置によって、トランスポート層パケットを第２の装置に送信することと、第１の装置によって、ラウンドトリップ時間（ＲＴＴ）およびＲＴＴ分散に基づいてＤ２用タイムアウトを計算することであって、ＲＴＴおよびＲＴＴ分散は、第１の装置から第２の装置に先に送信されたストリーミングデータパケットＤ３およびＤ４に基づいている、Ｄ２用タイムアウトを計算することと、タイムアウトが所定のタイムアウト制限を超えない場合およびＤ１用ＡＣＫが、第２の装置から受信されなかった場合には、第１の装置によって、Ｄ１を再送することと、に関する命令を含んでいる。命令は、第１の装置によって、第２の装置との接続のためにピアツーピアセッションを確立することに関する命令をさらに含み得る。第１の装置および第２の装置間の信号送信は、セッション確立プロトコル（ＳＩＰ）対応信号送信でもよい。トランスポート層パケットは、ユーザーデータグラムプロトコル（ＵＤＰ）パケットでもよい。

前述の説明では、１つ以上の実施形態を示しながら説明してきたが、当業者であれば理解されるように、さまざまな形および細部の変更を、本開示の精神および範囲から逸脱することなく、そこに加えることができる。例えば、特定のシーケンス図またはフローチャートの中で例示されるさまざまなステップは、結合されても、またはさらに分割されてもよい。さらに、１つの線図またはフローチャートで述べられたステップを、別の線図またはフローチャートに組み込むことができる。その上、説明した機能性は、ハードウェアおよび／またはソフトウェアによって供給されることができ、かつ分散されても、または単一のプラットホームに結合されてもよい。加えて、特定の実施例で説明した機能性は、例示したものとは異なる方法で実現することもできるが、それでもなお本開示の範囲に含まれるものである。したがって、特許請求の範囲は、本開示と一致する、幅広い方法で解釈されなければならない。

現行のパケットベースの通信システムは、一般に、特定のプロトコルを利用して通信する。しかしそのようなプロトコルは、ハイブリッド型ピアツーピアシステムなどのシステムにおいて特定の問題に取り組む際には有用にならない場合がある。したがって、改善された方法およびシステムが、そのような問題に取り組む際に必要とされる。
この出願の発明に関連する先行技術文献情報としては、以下のものがある（国際出願日以降国際段階で引用された文献及び他国に国内移行した際に引用された文献を含む）。
（先行技術文献）
（特許文献）
（特許文献１） 国際公開第２００６／０６４０４７号
（特許文献２） 欧州特許出願公開第１６３８２７５号明細書
（特許文献３） 欧州特許出願公開第１６０３３３９号明細書

Claims (16)

1. 第１の通信装置および第２の通信装置の間で仮想双方向データストリームを使用する、データをストリーミングする方法において、
   前記第１の装置によって、ストリーミングデータパケットＤ１を作成することと、
   前記第１の装置によって、前記データセグメントおよびＤ１をコネクションレストランスポート層パケットのペイロードセクションの中に挿入することであって、Ｄ１および前記トランスポート層パケットの少なくとも１つは、Ｄ１と共に送信されるデータセグメントの前記データストリームの開始位置を識別する送信欄と、すべてのデータが前記第１の装置によって受信されたところまでの前記データストリームの箇所を識別する肯定応答（ＡＣＫ）欄と、前記データストリームのために前記第１の装置によって使用される接続を識別する固有の識別子（ＵＩＤ）と、前記第１の装置の受信バッファで利用可能なスペース容量を識別するウィンドウ欄と、パケット形式欄と、Ｄ１が所定の長さを有することを確実にするのに使用されるパディングの量を識別するパッド欄と、前記第１の装置のネットワークアドレスと、前記第２の装置のネットワークアドレスと、前記トランスポート層パケットの長さと、を含んでいる、前記データセグメントおよびＤ１をコネクションレストランスポート層パケットのペイロードセクションの中に挿入することと、
   前記第１の装置によって、前記トランスポート層パケットを前記第２の装置に送信することと、
   前記第１の装置から前記第２の装置まで先に送信されたパケットの第１のＲＴＴおよび第２のＲＴＴに基づく現在のラウンドトリップ時間（ＲＴＴ）および設定可能なＲＴＴ変動ファクタを、前記第１の装置によって、取得することと、
   以前のＲＴＴ分散に基づく現在のＲＴＴ分散、前記第１のＲＴＴおよび第２のＲＴＴ並びに設定可能なＲＴＴ分散変動ファクタを、前記第１の装置によって、取得することと、
   前記現在のＲＴＴおよび前記現在のＲＴＴ分散に基づいてＤ１用タイムアウトを前記第１の装置によって計算することと、
   前記タイムアウトが所定のタイムアウト制限を超えない場合には、およびＤ１用ＡＣＫが、前記第２の装置から受信されなかった場合には、前記第１の装置によってＤ１を再送することと、を備えていることを特徴とする方法。
2. 前記第１の装置から前記第２の装置まで先に送信されたストリーミングデータパケットＤ２用の前記ＲＴＴとして前記現在のＲＴＴを、ＲＴＴ＋＝（ＣｕｒｒＲＴＴ―ＯｌｄＲＴＴ）^＊１／Ｍのように、前記第１の装置によって、計算することをさらに備えており、ＣｕｒｒＲＴＴが、Ｄ２の前に、前記第１の装置から前記第２の装置に送信されたストリーミングデータパケットＤ３の前記第１のＲＴＴを表し、ＯｌｄＲＴＴが、Ｄ３の前に、前記第１の装置から前記第２の装置に送信されたストリーミングデータパケットＤ４の前記第２のＲＴＴを表し、Ｍが設定可能なＲＴＴ変動ファクタを表している、請求項１に記載の方法。
3. Ｄ２用に計算された前記ＲＴＴｖａｒとして前記現在のＲＴＴ分散（ＲＴＴｖａｒ）を、ＲＴＴｖａｒ＋＝（ＣｕｒｒＲＴＴＶａｒ−Ａｂｓ（ＣｕｒｒＲＴＴ−ＯｌｄＲＴＴ））^＊１／Ｎのように、前記第１の装置によって、計算することをさらに備えており、ＣｕｒｒＲＴＴＶａｒが、Ｄ３のＲＴＴｖａｒを表し、かつ前記以前のＲＴＴ分散であり、Ｎが、設定可能なＲＴＴ分散変動ファクタを表している、請求項２に記載の方法。
4. 前記Ｄ１用タイムアウトを、前記第１の装置によって、タイムアウト=ＲＴＴ^＊ Ｘ ＋ ＲＴＴｖａｒ^＊ Ｙとして計算することであって、Ｘが、前記Ｄ２のＲＴＴの倍数であり、Ｙが、ストリーミングデータパケットＲＴＴの割合に基づくタイムアウト分散である、請求項３に記載の方法。
5. 前記タイムアウトが前記所定のタイムアウト制限を超えていない場合、および前記Ｄ１用ＡＣＫが前記第２の装置から受信されなかった場合には、新しいＲＴＴおよび前記現在のＲＴＴ分散に基づいてＤ１用の新しいタイムアウトを、前記第１の装置によって、計算することをさらに備えており、前記新しいＲＴＴが、前記現在のＲＴＴを定義された時間バックオフファクタによって増大することによって取得される、請求項１に記載の方法。
6. 前記第１の装置によって前記トランスポート層パケットを再送する前に、前記第２の装置によるＤ１の受領を肯定応答する、前記第２の装置からのＡＣＫを、前記第１の装置によって、受信することをさらに備えており、前記第１の装置が前記トランスポート層パケットを再送するのを、前記ＡＣＫの受領が止める、請求項１に記載の方法。
7. 前記ＡＣＫが前記第２の装置から受信された場合には、前記セグメントが再送信されたかどうかを、前記第１の装置によって、判定することと、
   前記セグメントが再送信されなかった場合には、Ｄ１に基づいて新しいＲＴＴおよび新しいＲＴＴＶａｒを計算することと、をさらに備えている、請求項６に記載の方法。
8. Ｄ１に基づいて前記新しいＲＴＴおよび新しいＲＴＴＶａｒを計算することが、
   ＲＴＴ＋＝（ＣｕｒｒＲＴＴ−ＯｌｄＲＴＴ）^＊１／Ｍとして、前記新しいＲＴＴを計算することであって、ＣｕｒｒＲＴＴが、前記Ｄ２のＲＴＴを表し、ＯｌｄＲＴＴが、前記Ｄ３のＲＴＴを表している、前記新しいＲＴＴを計算することと、
   ＲＴＴｖａｒ＋＝（ＣｕｒｒＲＴＴＶａｒ−Ａｂｓ（ＣｕｒｒＲＴＴ−ＯｌｄＲＴＴ））^＊１／Ｎとして、前記新しいＲＴＴｖａｒを計算することであって、ＣｕｒｒＲＴＴＶａｒが、Ｄ２の前記ＲＴＴｖａｒを表している、前記新しいＲＴＴｖａｒを計算することと、を含んでなる、請求項７に記載の方法。
9. 前記第１の装置によって、前記第２の装置からストリーミングデータパケットＤ２を受信することと、
   前記第１の装置によって、ＡＣＫを前記Ｄ１のＡＣＫ欄に挿入することであって、前記ＡＣＫがＤ２の受領を肯定応答する、ＡＣＫを挿入することと、をさらに備えている、請求項１に記載の方法。
10. 前記第１の装置によって、前記第２の装置との前記接続を開始することと、
    前記第１の装置によって、前記第２の装置との前記データストリーム用接続を確立することと、
    前記第１の装置によって、前記接続の確立を行なう間に前記第２の装置の遠隔ウィンドウサイズを取得することであって、前記遠隔ウィンドウサイズが、前記第２の装置上での前記データストリーム用に利用可能なスペースの量を識別する、遠隔ウィンドウサイズを取得することと、をさらに備えている、請求項１に記載の方法。
11. 前記第１の装置によって、前記第２の装置から前記接続の要求を受信することと、
    前記第１の装置によって、前記接続の確立を行なう間に前記第１の装置のウィンドウサイズを前記第２の装置に送信することであって、前記ウィンドウサイズが、前記第１の装置上での前記データストリーム用に利用可能なスペースの量を識別する、ウィンドウサイズを送信することと、をさらに備えている、請求項１に記載の方法。
12. 更新されたウィンドウサイズを前記Ｄ１のウィンドウ欄に挿入することをさらに備えている、請求項１１に記載の方法。
13. 前記第１の装置および第２の装置が、互いに直接通信するピアツーピア装置であり、前記第１の装置によって、前記第２の装置との前記接続のためにピアツーピアセッションを確立することをさらに備えている、請求項１に記載の方法。
14. 前記第１の装置および第２の装置間の信号送信が、セッション確立プロトコル（ＳＩＰ）対応信号送信である、請求項１３に記載の方法。
15. 前記トランスポート層パケットが、ユーザーデータグラムプロトコル（ＵＤＰ）パケットである、請求項１４に記載の方法。
16. 前記第１の装置によって、前記ストリーミングデータパケットＤ１を作成することが、前記送信欄と、前記ＡＣＫ欄と、前記ＵＩＤと、前記ウィンドウ欄と、前記パケット型式欄と、前記パッド欄とを備えたＤ１を作成することを含んでおり、前記第１の装置の前記ネットワークアドレスと、前記第２の装置の前記ネットワークアドレスと、前記トランスポート層のパケット長とが、Ｄ１の中ではなく、前記トランスポート層パケットの中に含まれている、請求項１に記載の方法。

Images