JP2016529786A

JP2016529786A - プロキシノードおよび方法

Info

Publication number: JP2016529786A
Application number: JP2016526464A
Authority: JP
Inventors: ラザビ，ルーズベフ; クラウゼン，ホルガー
Original assignee: アルカテル−ルーセント
Priority date: 2013-07-15
Filing date: 2014-07-03
Publication date: 2016-09-23
Anticipated expiration: 2034-07-03
Also published as: US20160143076A1; EP2827555A1; JP6181298B2; WO2015007370A1; US9918349B2

Abstract

プロキシノード、プロキシノードの方法およびコンピュータプログラム製品が開示される。プロキシノードは、通信リンクを介して第２のノードに送信されるデータを第１のノードから受信するよう動作可能な受信ロジックと、プロキシノードのグループから、選択されるプロキシノードが、プロキシノード、選択されるプロキシノードと第２のノードとの間の通信リンクの通信リンク特性、およびプロキシノードと第２のノードとの間の通信リンクの通信リンク特性の差が、閾値量の範囲に収まる場合はプロキシノードのグループの１つである選択されるプロキシノードを決定するよう動作可能な決定ロジックと、選択されるプロキシノードとのデータ転送のためのレートレス符号化通信リンクを確立するよう動作可能な送信ロジックとを含む。このようにして、プロキシノードは、既存のノードへの変更を必要とすることなくレートレス符号化を利用するために必要な機能を提供することができる。特に、プロキシノードはデータを第２のノードに送信する際に経由する他のプロキシノードをグループから選択し得るが、その選択されるノードを介する通信リンクは依然として必要な特性を得ることができる。つまり、通信リンクの特性は、プロキシノードと第２のノードとの間の直接的なリンクと比較して少しだけ劣るかもしれないが、これらの特性が閾値量の範囲に収まる限り、プロキシノードと第２のノードとの間のエンドツーエンドの改善は、プロキシノードと第２のプロキシノードとの間のレートレス符号化を使用することで依然として実現することができる。

Description

本発明は、プロキシノード、プロキシノードの方法およびコンピュータプログラム製品に関する。

ネットワークのノード間でのデータ転送のために、通信ネットワークが存在する。ネットワークノード間でデータが転送される通信リンクが、ネットワークのノード間で提供される。通信リンクを介してネットワークノード間でデータが転送される方法を定義する、異なるプロトコルが存在する。配置され得る、様々な分類のノードが存在する。このようなネットワークはノード間でのデータ転送を可能にするが、予期されない結果が生じることがある。したがって、ノード間でデータを転送するための改善された技術を提供することが望ましい。

米国特許出願公開第２０１２／００５４５８３（Ａ１）号は、データパケットを受信し、データパケットをサブパケットに分割し、ネットワークを介した送信のために消失訂正符号を使用してサブパケットを符号化する、サブパケットの誤り訂正方法を開示している。実施形態において、データパケットは高損失ネットワークを介した送信のために第１のプロキシサーバで受信され、符号化サブパケットは復号および再結合のために高損失ネットワークを介して第２のプロキシサーバで受信される。

米国特許出願公開第２０１２／００５４５８３号明細書

第１の態様に基づいて、請求項１に記載のプロキシノードが提供される。

第１の態様は、クラウドサービスの採用に関して言えば、レイテンシが主要な懸案事項であるとみなされていることを認識している。さらに、適切なサービス品質（ＱｏＳ）の仕組みの欠如およびトラフィック需要に対するネットワークの過少利用は、クラウドベースサービスの配備に遅れをきたす。

伝送制御プロトコル（ＴＣＰ）は現在、主要なトランスポートプロトコルとみなされている。研究に基づけば、ＴＣＰは世界全体のトラフィックのうち８９％を上回る量を伝送している。しかしながら、ＴＣＰのパフォーマンスはパケットロスや遅れたパケットから大きな影響を受ける。特に、ＴＣＰの積極的なバックオフ挙動は、リンクの過少利用や遅れの増加をもたらし得る。つい最近の研究は、ＴＣＰの挙動を変更することにより、ネットワークでのスループットが１６倍改善する可能性があることを示している。図１は、達成可能なスループット対パケットロスという観点からの、ＴＣＰのパフォーマンスの例を示している。図示されるように、パケットのドロップ率のわずかな上昇に伴って、スループットが著しく減少する（これはほとんどのネットワークにおいてよくあることである）。

ＴＣＰバックオフ挙動によるレイテンシの増加は、サービス品質保証契約（ＳＬＡ）違反がクラウドプロバイダに経済的な罰則をもたらし得るクラウドベースサービスを考えると、特に問題となり得る。残念ながら、そのような過度の遅れは、ネットワークに輻輳がある時に頻繁に生じやすく、その時こそＴＣＰの効果が最も明らかになる時なのである。輻輳に加えて、モバイルデータ使用量の著しい増加により、無線リンクがほとんどのエンドツーエンド通信に統合されてきている。無線チャネルでは通常パケットドロップが起こりやすく、したがってＴＣＰは無線チャネルにとって最善の選択肢ではないと知られている（したがって無線アクセスプロトコル（ＷＡＰ）などのプロトコルは独自のトランスポートプロトコルである、無線トランスポートプロトコル（ＷＴＰ）を持つ）。

このようなマイナスの側面はあるが、ＴＣＰは依然としてそのパフォーマンスの信頼性という点で評価されている。他のいずれの解決策も、帯域幅のオーバーヘッドを著しく増加させることなくパケット配信の信頼性を確保しなければならない。これから説明されるように、レートレス符号ベースのトランスポートプロトコルは、レイテンシを最小化しつつ信頼性を確保する効率的な方法である。このエンドツーエンドプロトコルはすでに実装され、測定は、ＴＣＰの代わりにこのトランスポートプロトコルを使用すると、スループットを４倍改善できる（有線回線を介して。無線リンクを介すると最大１１倍）ことを示している。このような著しい改善は、他のつい最近の研究報告で観察された数量と一致している。

上述のように、ＴＣＰは積極的なバックオフや帯域幅の過少利用がもたらすレイテンシの増加から影響を受ける。一方で、ユーザデータグラムプロトコル（ＵＤＰ）はより単純なプロトコルであるが、パケット配信プロセスの信頼性を何も保証しない。従来の固定レート誤り訂正符号の使用は、パケットドロップ（全パケット消失）に対処する上で非効率的である。さらに、パケットレベルの誤り訂正符号は、帯域幅と信頼性のトレードオフをもたらし、前方誤り訂正（ＦＥＣ）符号による帯域幅の不必要な使用を生じさせることがある。ハイブリッド自動再送要求（ＡＲＱ）という技術は概してより効率的であるが、そのパフォーマンスはパラメータの最適性、およびフィードバックチャネルの信頼性に著しく依存する。

しかしながら、第１の態様はまた、ＴＣＰまたは他の何らかのプロトコルの置き換えを目的とした何らかの方式の導入に伴う主要な課題は、その方式の採用であることも認識している。ほとんどのアプリケーションはトランスポートプロトコルとしてＴＣＰまたは他のプロトコルを使用しているので、新しいプロトコルがＴＣＰに取って代わるためには長い時間／努力が必要になるだろう。したがって、レガシーアプリケーション／ネットワークエンドノードが、それらのノードに何ら変更を加える必要なく新しいプロトコルの恩恵を受けることを可能にする仕組みが必要である。

それで、プロキシノードが提供される。プロキシノードは、通信リンクを介して第２のノードに送信されるデータを第１のノードから受信し得る受信ロジックを含み得る。プロキシリンクはまた、プロキシノードのグループから、選択される１つのプロキシノードを決定し得る決定ロジックを含み得る。決定ロジックは、プロキシノードと第２のノードとの間の通信リンクの通信リンク特性を決定し、プロキシノード、選択されるノードおよび第２のノードとの間の通信リンク特性を決定することにより、プロキシノードを選択し得る。この差が閾値量の範囲に収まる場合、プロキシノードはグループから選択され得る。プロキシノードはまた、選択されるプロキシノードとのデータの転送のための、レートレス符号化通信リンクまたは噴水符号化通信リンクを確立し得る、送信ロジックを含み得る。このようにして、プロキシノードは、既存のノードへの変更を何ら必要とすることなくレートレス符号化を利用するために必要な機能を提供することができる。特に、プロキシノードはデータを第２のノードに送信する際に経由する他のプロキシノードをグループから選択し得るが、その選択されるノードを介する通信リンクは依然として必要な特性を得ることができる。つまり、通信リンクの特性は、プロキシノードと第２のノードとの間の直接的なリンクと比較して少しだけ劣るかもしれないが、これらの特性が閾値量の範囲に収まる限り、プロキシノードと第２のノードとの間のエンドツーエンドの改善は、プロキシノードと選択されるプロキシノードとの間のレートレス符号化を使用することで依然として実現することができる。これにより、第１のノードから第２のノードに送信されるデータは、例えばネイティブプロトコルに従ってプロキシノードに受信され、次いでより効率的なレートレス符号化を使用してプロキシノードと選択されたプロキシノードとの間で送信され、そして例えばネイティブプロトコルを使用して選択されたプロキシノードにより第２のノードに転送されることが可能である。これにより、第１のノードか第２のノードのどちらにおいても何の変更も必要とすることなく、可能であればいつでもより効率的なレートレス符号化が使用されるようにすることができる。

一実施形態において、決定ロジックは、プロキシノードグループの複数のプロキシノードを選択されるプロキシノードとして選択できる場合、通信リンクの特性がプロキシノードと第２のノードとの間の通信リンクの通信リンク特性に最も近い、複数のプロキシノードのうちの１つを選択するように動作可能である。したがって、グループ内の複数のプロキシノードが必要な通信リンク特性を実現できる場合、最高の特性（つまり、プロキシと第２のノードとの間の通信リンク特性に最も近いか、それを上回るもの）を示すプロキシノードが選択され得る。これにより、最適なプロキシノードが選択され得る。

一実施形態において、受信ロジックは、データ転送と関連付けられているユーザのクラスおよびサービスタイプのうち少なくとも１つに基づいて、決定ロジックが選択されるプロキシノードを決定しないようにし、その代わりに送信ロジックに第２のノードとのデータ転送のための通信リンクを確立させるように動作可能である。したがって、レートレス符号化の使用は、データと関連付けられたサービスタイプに基づいて、またはデータ転送を実行するユーザのクラスに基づいて、提供されるか拒否され得る。これにより、レートレス符号化の使用を特定のユーザタイプまたは特定のアプリケーションに限定することができる。

一実施形態において、通信リンク特性は、ノードの近接性およびノード間の距離のうち少なくとも１つを含む。したがって、ノード間の物理的な距離は、通信リンク特性の指示を提供し得る。

一実施形態において、決定ロジックは、プロキシノードのサブグループおよび第２のノードのアドレスから決定可能な推定近接性に基づいて、プロキシノードのサブグループから、選択されるプロキシノードを決定するよう動作可能である。

一実施形態において、通信リンク特性は、通信遅延、ホップ数および通信リンクの容量のうち少なくとも１つを含む。したがって、通信リンクのレイテンシまたは容量の違いは、レートレス符号化を使用することがより効率的かどうかを決定するために比較され得る。

一実施形態において、決定ロジックは、プロキシノードグループのプロキシノードと第２のノードとの間の、そのプロキシノードが測定し報告する通信リンクの通信リンク特性に基づいて、選択されるプロキシノードを決定するよう動作可能である。したがって、グループ内の特定のプロキシノードと第２のノードとの間のリンクの特性は、グループ内の各プロキシノードによって測定され報告され得る。これにより、特性の正確な評価が、グループ内の各プロキシノードにより可能になる。

一実施形態において、閾値量は、レートレス符号化通信リンクのパラメータに基づいて適合される。レートレス符号化通信リンクを確立するために使用されるレートレス符号化方式のパラメータを変更することにより、その方式の効率または特定の状況下でのその適切性は変化し、閾値を変化させることによりこれを反映させることができることが理解されよう。

一実施形態において、プロキシノードは、ノードとの通信リンクの通信リンク特性を決定するようにとのリクエスト側プロキシノードからのリクエストを受信し、ノードとの通信リンクの通信リンク特性を確立し、通信リンク特性をリクエスト側プロキシノードに報告するよう動作可能な、通信リンク特性ロジックを含む。したがって、プロキシノードは、通信リンク特性決定のリクエストを受信すると、それらの特性を決定し、それらをリクエスト側ノードに報告を返すことができる。

一実施形態において、プロキシノードは、データを抽出するために受信したレートレス符号化通信リンクを復号し、ソースノードを識別するソースアドレスをプロキシノードを識別するソースアドレスに置換し、データを受信側ノードに転送するよう動作可能な、復号ロジックを含む。したがって、プロキシノードはレートレス符号化通信リンクを受信し、データをリンクから抽出し、レートレス符号化データを送信したノードのアドレスをプロキシノードのソースアドレスに置換し、次いでプロキシノードを示すソースアドレスを持つ復号されたデータを受信側ノードに転送することができる。こうすることで、受信側ノードが次いで、データのソースではなくプロキシノードに対して確実に応答するようにできる。

一実施形態において、プロキシノードは、データを抽出し、受信側ノードによるアクセスのためにデータを格納するために、受信したレートレス符号化通信リンクを復号するよう動作可能な、復号ロジックを含む。したがって、プロキシノードは、受信側ノードによってアクセスできるように復号されたデータを格納することができる。実施形態において、プロキシノードは次いで、受信側ノードからのリクエストに応じて、格納された復号されたデータを提供することができる。

一実施形態において、送信ロジックは第１のノードに対して選択されたプロキシノードを識別するよう動作可能である。したがって、プロキシノードは、選択されたプロキシノードで受信側ノードのために格納されたデータを受信側ノードがリクエストできるように、第１のノードが受信側ノードに情報を伝えるために、第１のノードに選択されたプロキシノードの識別子を伝え得る。

一実施形態において、プロキシノードは、プロキシノードを識別する宛先アドレスを他のプロキシノードを識別する宛先アドレスに置換し、他のプロキシノードとのデータの転送のためのレートレス符号化通信リンクを利用するよう動作可能な、符号化ロジックを含む。

一実施形態において、プロキシノードは、確認の指示が受信側ノードから受信されない場合、拒否の指示をソースノードに転送するよう動作可能な拒否ロジックを含む。したがって、ノードがプロキシノードからのデータ受信の確認に失敗した場合（これはデータ転送が例えばファイアウォールにブロックされていることの指示であり得る）、データがブロックされた可能性があること、あるいは受信されていないことの指示が、プロキシノードにより、プロキシノードが配信しようとしているデータのソースであるノードに対して提供され得る。

一実施形態において、受信ロジックは、拒否の指示を受信すると、決定ロジックが選択されるプロキシノードを決定しないようにし、その代わりに送信ロジックに第２のノードとのデータ転送のための通信リンクを確立させるよう動作可能である。したがって、拒否の指示がプロキシノードによって受信された場合、選択されるプロキシを介してデータを配信しようとする試みは取り消され、代わりに、データはプロキシと第２のノードとの間の通信リンクを介して配信され得る。

一実施形態において、プロキシノードは、データを抽出するためにレートレス符号化通信リンクを復号し、プロキシノードを特定する宛先アドレスを第１のノードを特定する宛先アドレスに置換し、データを第１のノードに転送するよう動作可能な、変更ロジックを含む。

一実施形態において、プロキシノードは、送信側ノードから確認データを受信し、レートレス符号化をせずに確認データを受信側ノードに転送するよう動作可能な、転送ロジックを含む。したがって確認データは、そのような確認データをより速くより急速に配信するために、レートレス符号化の対象になることを避けることができる。

第２の態様に基づいて、請求項１４に記載のプロキシノードの方法が提供される。

一実施形態において、決定ステップは、プロキシノードグループの複数のプロキシノードを選択されるプロキシノードとして選択できる場合、通信リンクの特性がプロキシノードと第２のノードとの間の通信リンクの通信リンク特性に最も近い、複数のプロキシノードのうちの１つを選択するステップを含む。

一実施形態において、方法は、データ転送と関連付けられているユーザのクラスおよびサービスタイプのうち少なくとも１つに基づいて、決定ステップが選択されるプロキシノードを決定しないようにし、その代わりに第２のノードとのデータ転送のための通信リンクを確立させるステップを含む。

一実施形態において、通信リンク特性は、ノードの近接性およびノード間の距離のうち少なくとも１つを含む。

一実施形態において、通信リンク特性は、通信遅延、ホップ数および通信リンクの容量のうち少なくとも１つを含む。

一実施形態において、決定ステップは、プロキシノードのサブグループおよび第２のノードのアドレスから決定可能な推定近接性に基づいて、プロキシノードのサブグループから、選択されるプロキシノードを決定するステップを含む。

一実施形態において、決定ステップは、プロキシノードグループのプロキシノードと第２のノードとの間の、そのプロキシノードによって測定、報告される通信リンクの通信リンク特性に基づいて、選択されるプロキシノードを決定するステップを含む。

一実施形態において、方法は、ノードとの通信リンクの通信リンク特性を決定するようにとのリクエスト側プロキシノードからのリクエストを受信し、ノードとの通信リンクの通信リンク特性を確立し、通信リンク特性をリクエスト側プロキシノードに報告するステップを含む。

一実施形態において、方法は、データを抽出するために受信したレートレス符号化通信リンクを復号し、ソースノードを識別するソースアドレスをプロキシノードを識別するソースアドレスに置換し、データを受信側ノードに転送するステップを含む。

一実施形態において、方法は、データを抽出し、受信側ノードによってアクセスするためにデータを格納するために、受信したレートレス符号化通信リンクを復号するステップを含む。

一実施形態において、方法は、第１のノードに対して選択されたプロキシノードを識別するステップを含む。

一実施形態において、方法は、プロキシノードを識別する宛先アドレスを他のプロキシノードを特定する宛先アドレスに置換し、他のプロキシノードとのデータの転送のためのレートレス符号化通信リンクを利用するステップを含む。

一実施形態において、方法は、確認の指示が受信側ノードから受信されない場合、拒否の指示をソースノードに転送するステップを含む。

一実施形態において、方法は、拒否の指示を受信すると、決定ロジックが選択されるプロキシノードを決定しないようにし、その代わりに第２のノードとのデータ転送のための通信リンクを確立させるステップを含む。

一実施形態において、方法は、データを抽出するためにレートレス符号化通信リンクを復号し、プロキシノードを識別する宛先アドレスを第１のノードを識別する宛先アドレスに置換し、データを第１のノードに転送するステップを含む。

一実施形態において、方法は、送信側ノードから確認データを受信し、レートレス符号化をせずに確認データを受信側ノードに転送するステップを含む。

第３の態様に基づいて、コンピュータで実行された時に、第２の態様の方法のステップを実施するよう動作可能なコンピュータプログラム製品が提供される。

さらなる特定の好ましい態様は、付随する独立請求項および従属請求項で定められる。従属請求項の特徴は、必要に応じて独立請求項の特徴と結合され、また請求項で明示されている場合を除き組み合わせられ得る。

装置の特徴が機能を提供するよう動作可能であると説明されている場合、このことがその機能を提供するか、またはその機能を提供するように適合されるか、もしくは構成される装置の特徴を含むことが理解されよう。

本発明の実施形態は、付随する図面と関連してさらに説明される。

達成可能なスループット対パケットロスという観点からの、ＴＣＰパフォーマンスの例を示す図である。Ｌｕｂｙ定理符号の、２部グラフに基づく説明を示す図である。ＴＣＰとレートレス符号に基づく送信方式を比較する例を示す概略図である。符号化の方策について、元のパケットの復号を成功させるために必要なレートレス符号化パケットの実際の数の例を示すヒストグラムである。符号化の方策について、元のパケットの復号を成功させるために必要なレートレス符号化パケットの実際の数の例を示すヒストグラムである。ＴＣＰベースのデータ伝送を、有線通信シナリオの実施形態と比較するいくつかのスナップショットである。プロキシサーバの使用を示す簡略図である。レートレス符号トランスポートプロトコルを可能にするためにプロキシサーバを使用する実施形態を示す図である。分散プロキシサーバを使用する、配備シナリオの簡単な例を示す図である。分散プロキシサーバを使用する、配備シナリオの簡単な例を示す図である。ＹｏｕＴｕｂｅ（登録商標）の物理サーバの位置を示す図である。データ配信レイテンシを減少させるために多数のプロキシサーバが配備された実施形態の簡略図である。データ配信レイテンシを減少させるために多数のプロキシサーバが配備された実施形態の簡略図である。

概要
実施形態をより詳細に説明する前に、まず概要が提供される。実施形態は、第１のノードと第２のノードとの間のデータ送信が第１のプロキシノードによって受信される技術を提供する。第１のプロキシノードは、通信リンクを第２のネットワークノードと直接確立することにより、より良いパフォーマンスが実現されるどうか、または選択されるプロキシノードとのレートレス通信リンクを確立し、次いで第２のネットワークノードとの通信リンクを確立するかどうかを決定する。実施形態は、選択されるプロキシノードを介して通信リンクを確立することはレイテンシを増加させ得るが、このレイテンシの増加は、レートレス符号化通信リンクによって提供されるスループットの増加により、十二分に埋め合わせ得ることを認識している。特に、２つのプロキシノード間では高レイテンシを持つが、選択されるプロキシノードと第２のノードとの間では低レイテンシを持つプロキシノードを選択することで、プロキシノードは、レートレス符号化を最大限利用するためにプロキシノードと第２のノードとの間の通信リンク全体の大部分がレートレス符号化されるように、選択されるプロキシノードは第２のノードに可能な限り近いと合理的に確信できる。この構成は、選択されるプロキシノードが宛先ノードに可能な限り近くなるように選択されるサービスプロバイダや、選択されるプロキシノードが、リクエストしたデータを取得するためにプロキシノードにリダイレクトされるエンドユーザに可能な限り近くなるようにするコンテンツ配信者のどちらにも使用できる。

実施形態は、既存のインターネットインフラを使用して、遅延に敏感な（または高品質の）トラフィックフローを配信するための、レートレス符号の使用を可能にする方法を提供する。レートレス符号は比較的新しく、フィードバックが得られないチャネルで主に使用される（例えば、ブロードキャストアプリケーション）。その特別な性質のため、レートレス符号の配備は、遅延に敏感なサービスに優先順位を付け、ネットワークを最大限利用するために使用され得る。これによりサービス品質の改善や通信レイテンシの減少がもたらされる。エンドツーエンドレートレス符号ベースのパケット配信を使用する実装されたシステムでは、有線ネットワークでは最大４倍、有線および無線のハイブリッドネットワークでは最大１１倍のスループット改善が、従来のＴＣＰベーストランスポートプロトコルと比較して観察された。

実施形態は、分散プロキシサーバに基づく仕組みを提供する。これにより、すべてのレガシーエンドポイント（ユーザおよびサーバ）が、この方式の使用がそれらに対して透過的でありながら、レートレス符号の利点から恩恵を受けることを可能にする。この手法の一部として、ソースノードはどのプロキシサーバ／ルートがデータ伝送に使用されるかを決定する必要がある。

実施形態をより詳細に説明する前に、まずレートレス符号の概要が提供される。

レートレス符号
消失チャネルを介した送信のためのレートレス符号化の符号化および復号技術の原理について説明する。ＬＴ（Ｌｕｂｙｔｒａｎｓｆｏｒｍ）符号は、レートレス符号を初めて実用的に実現したものであり、これらはレートレス符号の原理を説明するために使用できる（他の多くの実装も可能である）。

符号化手順
データメッセージが、Ｋ個の入力（ソース）シンボルｖ＝［ｖ_１ｖ_２．．．ｖ_Ｋ］で構成されると仮定する。各シンボルは任意のビット数を持つ。レートレス符号を紹介する原論文で使用されている専門用語は、元のデータメッセージｖを「ファイル」と呼んでいる。便宜上、ベクトルｖ＝［００１０１１０１］で与えられる４つの２ビットシンボルを含むデータメッセージの仮定的例を考慮する。

続いて、ＬＴ符号化シンボルｃ＝［ｃ_ｊ］、２ｊ＝１、．．．、Ｎは単に、一様にランダムに選ばれたｄ_ｃの異なる入力シンボルの、２を法とする和（つまり、排他的論理和（ＸＯＲ））である。符号化される各シンボルの実際のｄ_ｃ値は、次いで、時に出力分布とも称される事前定義済み分布ｆ（ｄ_ｃ）から選択される。ｆ（ｄ_ｃ）からサンプリングされた第１のｄｃ値が２であると仮定する。結果として、２つの入力シンボルがｖからランダムに選ばれる。２つの選択されたソースシンボルが、ｖの第１および第２のシンボルに対応すると仮定する。この場合、ｃ_１は

として計算される（「

」は、ＸＯＲ関数を意味する）。

符号化アルゴリズムも、ｆ（ｄ_ｃ）から疑似ランダムにサンプリングされたｄｃ値を選択し、符号化されたシンボルを、疑似ランダムに選択されたソースシンボルのｄｃ数のＸＯＲの積に基づいて計算するたびに、同様に進行する。通信チャネルへのＬＴ符号の自然な適用可能性ゆえに、符号化されたシンボルを「ＬＴ符号化パケット」と呼ぶことを好む人もいることが理解されよう。

入力シンボルと出力シンボルとの間の関係はまた、図２に示されているように、２部グラフによって図式的に表すことができる。グラフ関連の専門用語を使用すると、ＬＴ符号化シンボルはチェックノードとみなされる一方で、入力ソースシンボルは可変ノードと称され得る。各チェックノードから出てくるエッジの数は、ｆ（ｄ_ｃ）からサンプリングされたｄｃ値に対応し、そのため、ｄｃはチェック次数と称されることがある。

図２は、ソースシンボル（可変ノード）およびＬＴ符号化シンボル（チェックノード）を示すＬＴ符号の２部グラフに基づく説明を示している。シンボルは、任意の大きさであって良い。例えばｃ４は、この２部グラフで描かれている特定の例でのｖ２およびｖＫの２を法とする和（ＸＯＲの積）により計算される。

復号手順
ｃの符号化シンボルが後の送信中に消失される、消失チャネルを考慮する。簡潔に言って、復号器の作業は、消失されたシンボルを消失されていないものから回復することである。復号プロセスは、次数１の入力シンボル（つまり、他のものとＸＯＲ結合されていないシンボル）を特定することにより開始する。復号器は次いで、このシンボルの値を２を法として、その値に依存するすべてのＬＴ符号化シンボルに加え、さらに対応する２を法とする関係を削除する。各関係は、関連する２部グラフ（図２を参照）上のエッジで表されている。復号手順はこれを繰り返し、毎回次数１のシンボルから開始する。

フィードバックありレートレス符号
上記に基づいて、また効率的な実施態様により、Ｎ個の元のパケットはいずれも、いずれかのＮ個のレートレス符号化パケットを使用して、高い確率で復号できる。このことは、送信機にドロップしたか訂正不能な誤りを含んで受信したデータパケットを再送信させる必要がなくなるので、特に重要である（誤り訂正符号が使用されている場合）。代わりに、送信機はＮ個のパケットが受信されるまでレートレス符号化パケットを送信し続けることができる。この時点で受信機は単一の確認パケットを送信でき、送信機は次のパケットのグループに進むことができる。このことは、特にＴＣＰ輻輳ウィンドウが小さい場合の輻輳状況下で、ＴＣＰと比較して送信のレイテンシを著しく改善できる。

図３は、ＴＣＰとレートレス符号に基づく送信方式を比較する例を示す概略図である。このレートレス方式では、まず各バッチに含まれるパケット数が決定され、受信機と通信される。バッチの最適なサイズを得ることについては以下で説明される。このレートレス符号ベースのトランスポートプロトコルは、送信機が結果としてデータパケットを送信するという点で、ＵＤＰに非常に似ている。しかしながら、受信機側で十分な量の正確なパケットが修復されたら、受信機は確認を送信し、送信機は次のバッチへと進む。バッチのサイズが変化した場合、その変化は受信機に対して通信される。

すべてのレートレス符号化パケットは、元のパケットに関するマッピング情報を含むことに留意されたい。図３において、例えばＲＳＰｋｔ１は元のパケット５および３のＸＯＲ演算の結果であり得る。レートレス符号化パケットの各バッチは元のパケットの特定の範囲をカバーするので、受信機は、受信された各パケットが特定のバッチに属することを容易に決定できる。確認（ａｃｋ）メッセージがドロップする可能性があるので、受信機が以前に確認したバッチに属するＲＳパケットを受信し続ける場合、受信機はａｃｋメッセージが受信されていないと推測し、ａｃｋメッセージを再送信できる。

パケット伝送のこの方法は通常、遅延に敏感であるか高品質のサービスに対してのみ、パケット配信に優先順位を付ける手段として使用されることが推奨される。さらに、レートレス符号化のランダムな性質ゆえに、いくつかの符号化パケットが重複したり、所与の符号化パケット数のうちいくつかの特定のパケットが失われたりすることがあり得る。したがって実際には、レートレス符号化パケットの復号を確実に成功させるために、幾らかのオーバーヘッドが必要とされることがある。しかしながら、このオーバーヘッドはわずかである（１−８％）。実際のオーバーヘッドは符号化パラメータに依存する。例えば、既存の符号化方法では、オーバーヘッドの平均が、大きな分散に対して小さくなるように符号化パラメータを選択するか、代わりに平均してより大きなオーバーヘッドを必要とするがより小さな分散を持つ方策を使用することもできる。

図４Ａおよび図４Ｂは、２つの異なる符号化の方策について、１０，０００の元のパケットの復号を成功させるために必要なレートレス符号化パケットの実際の数の例を示すヒストグラムである。図４Ａは、図４Ｂと比較して必要なパケットの平均数は少ないが、分散は大きいケースを示している。

レートレス符号ベースのトランスポートプロトコルのパフォーマンス
この完全なエンドツーエンド伝送の解決策が、上述のレートレス符号に基づくトランスポートプロトコルの実行可能性を調査し、パフォーマンス改善を評価するために実装された。従来のＴＣＰベースの伝送と比較して、実施形態は有線リンクを考慮した場合は約４倍、無線リンクから構成される通信パスの場合は最大１１倍のスループット改善を提供する。

図５は、ＴＣＰベースのデータ伝送を、有線通信シナリオの実施形態と比較するいくつかのスナップショットを示す。この例では、ファイル転送が２つの方式のスループットを比較するためのケーススタディとして使用された。

レートレス符号の簡単な採用のためのプロキシサーバの使用
レートレス符号に基づくトランスポートプロトコルの採用を容易にするため、プロキシノード／サーバが、元のＴＣＰパケットをレートレス符号化パケットに符号化し、リモート側で元のＴＣＰパケットに復号し返すために使用できる。こうすることで、エンドノード（ＴＣＰ送信機／受信機）は、通信パス内のプロキシサーバが実行する変換に気付くことすらないことがある。最も簡単な形式では、プロキシサーバは単にＴＣＰパケットをレートレス符号化パケットにカプセル化し、ＴＣＰパケットをレートレス符号化パケットから逆カプセル化する。ソース（符号器）プロキシサーバは、レートレス符号化パケットに対して、リモート（復号器）プロキシサーバのＩＰアドレスを使用する。確認パケットが、何の変更も加えずにソースに渡されることになる。

図６は、プロキシサーバの使用の簡略図を示す。この手法にはいくつかの利点がある。エンドノードはレートレス符号化トランスポートプロトコルに気付かなくて良い。このことは、モバイル端末からエンドサーバ（または、この方式がアプリケーションレベルで実装されるのであればアプリケーション）までの今日存在する多岐にわたるエンドノードを考えると重要である。符号化および特に復号の負荷は、エンドポイントよりもプロキシサーバにかかる。レートレス符号トランスポートプロトコルを使用する副産物として、データは２つのサイト／データセンター間を移動する際に「暗号化される」。いくつかの不都合もある。通信パス内にプロキシサーバ（符号器および復号器）が設置されている必要があり、理想としてはソースおよび宛先に近い位置である（そうでなければ、プロキシ間のパスが通信パス全体と比較して短い場合、改善はわずかである）。２つのエンドポイントが、伝送パスの途中で発生するいずれのプロトコル変換プロセスにも完全に気付かないことが理想なので、ルーティングパスは必ずしもプロキシサーバを経由する必要はない。したがって、この方式の適用は、通信パス内にそのようなプロキシサーバの存在が保証されるシナリオに限られる。良い例は、それらのプロキシサーバが異なるデータセンターのゲートウェイに配備され得る、データセンター間のデータ伝送である。これらのプロキシサーバは、宛先データセンターの相手側のアドレスを知っているので、互いに通信可能である。同様に、他の類似の種類の企業内通信も、この方式から恩恵を受けることができる。

図７は、レートレス符号トランスポートプロトコルを可能にするためにプロキシサーバを使用するこの方式を使用する例示的な実施形態を示す。

さらなる実施形態
上述の実施形態は、企業内／データセンター間通信が、レートレス符号トランスポートプロトコルからどのように恩恵を受けられるかを示している。さらなる実施形態は、サービスプロバイダおよびコンテンツプロバイダが、エンドノード（ユーザおよびサーバ）に何の変更も加えずにレートレス符号トランスポートプロトコルからさらに恩恵を受けることを可能にする方法を提供する。

サービスプロバイダ
実施形態は、サービスプロバイダが、ユーザ／サーバ側に何の変更も加えることなく、すべてのユーザがレートレス符号トランスポートプロトコルから恩恵を受けることを可能にする解決策を提供する。これは困難なことではあるが、同時にレートレス符号の採用を非常に簡単にし、かつ可能性を高めることができるので、見返りが大きいことでもある。

実施形態は２つの主要な課題に取り組む。１）適切なプロキシサーバをどのように選択するか。および２）どのように効率的にＴＣＰ接続およびトラフィックフローを扱うか。

この解決策を配備するのはオペレータなので、ユーザに近いプロキシサーバを選択するのは問題ではない。これは例えば、オペレータのローカルゲートウェイ（つまりＰＯＰ）において実現できる。しかしながら、挑戦となる作業は、宛先ノードに近い適切な（もしあれば）プロキシサーバを選択することである。この解決策は、地理的に分散しており、理想としては主要なデータセンターの近くに位置している多くのプロキシサーバを利用できることを想定している。これは、著しい経済的な投資を必要とすることなく世界中の仮想マシンを借りることが可能なので、非現実的な想定ではない（例えば、ＡｍａｚｏｎＥｌａｓｔｉｃＣｏｍｐｕｔｅｒＣｌｏｕｄ［ＥＣ２］提供）。

図８は、分散プロキシサーバが使用される、配備シナリオの簡単な例を示している。

次の作業は、適切なリモートプロキシサーバを選択することである。この目的のために、ソースプロキシサーバは最終宛先のアドレスを、すべての分散プロキシサーバに転送する。一実施形態として、ソースプロキシサーバは、最終宛先により近いと思われるいくつかの分散プロキシサーバを事前に選択することができる。リモートプロキシサーバは次いで、最終宛先への近接性を推定しようとする。このような推定は、遅延測定（例えば、ＩＣＭＰプロトコルを使用）、ホップ数および／またはリンク容量推定などに基づき得る。プロキシサーバは次いで、これら測定結果をソースプロキシサーバに報告し返す。最終宛先までの許容範囲内にある近接性を持つプロキシサーバが見つかった場合、ソースプロキシサーバは、エンドユーザからサーバへパケットを配信するために、レートレス符号ベースのトランスポートプロトコルを使用することを決定する。あるいは、トラフィックを迂回させることが著しい遅延をもたらすのであれば、ソースプロキシサーバはレートレス符号ベースのプロトコルを使用しないと決定することがある。さらに、ソースプロキシサーバは、レートレス符号トランスポートプロトコルを適用するかどうかを決定する上で、既存の輻輳／帯域幅推定技術からさらに恩恵を受けることができる。通常、ソースプロキシサーバは、最終宛先および候補となるリモートプロキシサーバに対する測定を実施する。次いで、測定報告をリモートプロキシサーバから受信した後、ソースプロキシサーバはレートレス符号トランスポートプロトコルを使用するかしないかを決定する。

２つ目の課題は、トラフィックフローをどのように扱うかに関する。分散プロキシサーバの使用に関連する問題は、リターントラフィックパス（リモートサーバからユーザまで）がリモートプロキシサーバを経由する保証がないことである。このことは、サービスプロバイダにとってほとんどの状況で、ダウンリンクトラフィック（サーバからユーザへ）が多くを占めるので、特に重要である。

図９は、リターントラフィックパスが、リモートプロキシサーバを含まない異なるルートを経由する可能性があることを示す例を図示している。

このため、プロキシサーバの機能（少なくともリモートプロキシサーバ）は変更されるべきである。リモートサーバがリモートプロキシサーバと確実に通信するようにするため、リモートプロキシサーバによってＴＣＰ接続が切断され、再確立される。言い換えれば、リモートプロキシサーバがパケットを受信し復号すると、サーバはパケットのソースアドレスを自身のＩＰアドレスに変更する。事実上、その名前が暗示しているように、プロキシサーバはユーザの代理として、パケットをリモートサーバに送信する。続いて、リモートサーバからパケットを受信すると、プロキシサーバはパケットをユーザに転送し返す（つまり、サーバはパケットの宛先アドレスを変更する）。概して、ＡＣＫパケットはレートレス符号トランスポートプロトコルを使用して送信される必要はない。その場合、リモートサーバは単にＡＣＫパケットを、符号化せずに直接ユーザに転送することができる。

この解決策と関連する１つの潜在的な問題は、プロキシサーバがリモートサーバとの接続を確立しようとするので、場合によっては元のＩＰアドレスからの接続のみを許可するファイアウォールにより、接続がブロックされてしまうことである。しかしながら、多くのサービスプロバイダがＮＡＴを使用していることと、リクエストされるサービスの多くがパブリックサーバを宛先としていることを考えると、このシナリオはそれほど頻繁にあるわけではない。しかしながら、このことが発生した場合、リモートプロキシサーバは、サーバへの接続の確立を拒否されることになる。この場合、リモートサーバはこの情報をソースプロキシにシグナリングし返し、次いでソースプロキシはパケットをリモートサーバに、レートレス符号化をせずに直接転送する。さらに、ソースプロキシサーバはレートレス符号トランスポートプロトコルを、スループットの最大化がユーザ体験の質向上という観点から有益である一連のサービスに対してのみ適用できる。サービスの種類は、ソースおよび宛先ポート番号を含む様々な測定基準に基づいて決定できる。さらに、レートレス符号トランスポートプロトコルは、ユーザのサブセット（例えば、プレミアムユーザ）に対してのみ有効にすることができる。

まとめると、以下のステップが実施される。ユーザのパケットを受信すると、オペレータのゲートウェイに配置されたソースプロキシサーバは、レートレス符号トランスポートプロトコルの適用について、最初の決定を下す。この最初の評価に関係する要素は典型的に、リクエストされたサービスの種類、サービスをリクエストしているユーザ、および新しいレートレス符号ベースのフローを扱うプロキシサーバの性能（計算およびメモリ）である。この選択肢を考慮することに決定された場合、ソースプロキシサーバは宛先サーバ／ノードのＩＰアドレスを、ソースおよび宛先ポート番号と共に、リモートプロキシサーバのすべて／サブセットに転送する。ソースプロキシサーバはさらに、候補となるリモートプロキシサーバおよび宛先サーバに対する測定を実施する。ソースプロキシサーバからのリクエストを受信すると、リモートプロキシサーバは最終宛先に対する測定を実施し、宛先サーバの所与のポート番号と通信できるかどうかを評価する。結果は、レートレス符号化トランスポートプロトコルを使用するかどうかを決定し、使用する場合どのプロキシサーバを使用するかを決定するソースプロキシサーバに転送される。リモートプロキシサーバを選択するより簡単な方法（次善の方法でもある）は、宛先サーバのＩＰアドレスに基づく固定のルックアップテーブルを使用することである。

ソースプロキシサーバが所与のフローにレートレス符号トランスポートプロトコルを適用することに決定した場合、その所与のフロー（ソースおよび宛先ＩＰアドレスおよびポート番号により特定される）に属するすべてのパケットがレートレス符号を使用して符号化されリモートプロキシサーバに転送される（カプセル化されたパケットとして）ことを示す新しいルールを、パケット転送ポリシーデータベース／テーブルに作成する。ＡＣＫパケットは任意で省くこともできる。

一方で、リモートプロキシサーバは、ソースプロキシサーバから受信したパケットを逆カプセル化し、ソースアドレスを自身のアドレスに変更し、パケットを最終宛先サーバに転送する。また、ソースノード（ＩＰおよびポート番号）を宛先ノード（ＩＰおよびポート番号）に関連付けるエントリを、パケット転送ルールデータベース／テーブルに作成する。サーバからパケットを受信すると、対応するソースノード（ユーザ）を探してパケットの宛先アドレスをそれに変更するためにテーブルを確認し、次いでレートレス符号を使用してパケットを符号化し、それをソースプロキシサーバに転送する。

ソースプロキシサーバはパケットを復号し、それをユーザに転送する。

トラフィック状況に応じて、プロキシサーバは、トラフィックの一方向にのみレートレス符号トランスポートを使用すると決定することができる。リターンパスを符号化する必要がない場合、リモートプロキシサーバは単にパケットを復号し、ソースプロキシからのパケットをサーバに転送することができ、サーバはユーザに直接通信し返すことができる。

任意選択で、プロキシサーバは、他の通信エンドの代理として、エンドノードへのローカルリンクのパケット送信レートを増加させる（ＴＣＰウィンドウを増加させる）ために、ＡＣＫをエンドノードに送信することができる。これにより、プロキシサーバは、最終宛先への確認パケットの配信を確約することができる。この方法は通信プロセスを複雑にする可能性がある（例えば、ソースエンドノードはＡＣＫが受信されたのでパケットの受信は成功したと推測しているのに、プロキシが実際にパケットを配信する前に宛先エンドノードが故障した場合など）とはいえ、このような手法は見返りとして順調に実行された場合はスループットをさらに向上させるので、特定の（つまり、それほど敏感ではない）アプリケーションに対してのみ考慮することができる。

コンテンツ配信業者
データの需要がますます大きくなっているので、コンテンツ配信ネットワーク（ＣＤＮ）の役割は不可欠になってきている。このことは、動画の増加がインターネットトラフィックソースの主流であることを考えるととりわけそうである。Ｙｏｕｔｕｂｅなどのコンテンツプロバイダは、ユーザの期待がますます大きくなっているのに対して配信ネットワーク／インフラの増強が遅れを取ることがあり、困難な課題に直面し得る。実施形態は、ユーザおよびエンドサーバに変更を加える必要なく、レートレス符号トランスポートプロトコルによって提供される利点から恩恵を受けられるようにする、ＣＤＮのための解決策をさらに提供する。関係する仕組みをより良く理解するために、巨大なＣＤＮの一例としてＹｏｕｔｕｂｅについて考慮する。この特定のコンテンツ配信業者は、単に一例として、実際の状況において物理サーバがどのように選択されるかを示すために選択されることが理解されよう。

Ｙｏｕｔｕｂｅにおいて４０億本を上回る動画が毎日閲覧されていることを考えると、動画配信クラウドはできる限り最適化されていなければならない。ＹｏｕＴｕｂｅ動画配信ネットワークは、３つの主要な要素から構成されている。動画ＩＤスペース、複数の論理ＤＮＳネームスペースを使用して表される階層的な論理動画サーバ、および３層物理サーバキャッシュ階層である。

ＹｏｕＴｕｂｅは、様々な物理サーバで負荷を分散させるために、３つの異なる手法を使用している。ハッシュベースの仕組みを使用する静的負荷分散−ＹｏｕＴｕｂｅは各動画ＩＤを、階層ＤＮＳベースのホストネームスペース内の各ネームスペースにある一意のホストネームにマッピングする。これにより、等しい数の動画を、プライマリネームスペースの各ホストネームに配分する、極めて粒度の荒い負荷分散が提供される。位置認識ＤＮＳ解決を使用する半動的手法−ＹｏｕＴｕｂｅは、各ＤＮＳホストネームを、ユーザの位置および現在の要求に基づいて、物理的な動画のキャッシュを表すＩＰアドレスにマッピングする。ＹｏｕＴｕｂｅはユーザを、「通常」時は地理的に近いキャッシュ位置にリダイレクトする。しかしながら、「込み合っている」時には、地理的なホットスポットを回避するために、ユーザを少し遠い位置に誘導するためにＤＮＳベースの解決を使用する。およびＨＴＴＰリダイレクトを使用する動的負荷分散−最後に、異なる物理サーバ上でさらに負荷を分散させるために、ＹｏｕＴｕｂｅキャッシュはユーザを込み合っているサーバからそれほど込み合っていない動画サーバに誘導するために、ＨＴＴＰリダイレクトを使用する。これにより、動画の人気度と自然発生的な動画の要求の組み合わせによって引き起こされる、ゆがんだ負荷分散を軽減することができる。

図１０は、２５か国の４５の都市に配置されたＹｏｕＴｕｂｅの物理サーバの位置を示している。

さらに多くの地理的位置においてフットプリントを増やすことは明らかに、データ配信レイテンシを減少させユーザ体験の質を改善することができるが、著しいＣａｐｅｘおよびＯｐｅｘ投資を必要とする。ＹｏｕＴｕｂｅと比較して、他のＣＤＮはこの数のデータセンターでさえ提供することはできないかもしれない。したがって、レートレス符号トランスポートプロトコルは、データ配信のレイテンシを最小化する上でＣＤＮにとって望ましい。この目的のために、ＣＤＮは世界中の分散プロキシサーバを大量に使用することができる。物理データセンターとは対照的に、そのようなプロキシサーバを借りて維持することは、データをキャッシュ／格納する必要はないので、多額の費用を必要とはしない。

ユーザからのリクエストを受信すると、最も近い（または最も適切な）物理キャッシュサーバおよびユーザに最も近いプロキシサーバが識別される。ユーザは次いでプロキシサーバにリダイレクトされる。

プロキシサーバは次いで要求されたコンテンツを物理キャッシュサーバにリクエストし、そのコンテンツをユーザに転送する。しかしながら、物理キャッシャサーバに配置されたゲートウェイおよび分散プロキシサーバは、配信レイテンシを著しく減少させるレートレス符号トランスポートプロトコルを使用して通信できる。

図１１は、ＣＤＮのデータ配信レイテンシを減少させるために多数のプロキシサーバ（データセンターと比較して）が配備された実施形態の簡略図を示している。

前の実施形態（サービスプロバイダ）と比較して、ＣＤＮがユーザを最も近い分散プロキシサーバにリダイレクトでき、したがってどちらのプロキシサーバにおいてもアドレスの操作が必要ない、より簡単なケースである。適切なリモートプロキシサーバを識別するために、前の実施形態と類似の方法を適用できる。

分散プロキシサーバは、サービスプロバイダのＰＯＰの近くに配置されるのが理想である。こうすることでユーザ体験の質が向上するので、ＣＤＮおよびサービスプロバイダ両方にとって相互利益がある。ユーザにとってのサービス品質（ＱｏＳ）の向上に加えて、減少した配信レイテンシがさらに、異なるデータセンターを選択するための柔軟性をもたらし、１つの特定のサイトでの輻輳を避けることができるので、この方式はＣＤＮにとって特に魅力的である。選択されるデータセンターが少し遠いとしても、遅延はレートレストランスポートプロトコルを適用することにより埋め合わせられる（通常のＴＣＰと比較して、レートレス方式は遅延を、有線ネットワークの場合は４分の１に減少させることができる）。さらに経済的な観点からも、提案された方式を使用すれば、ＣＤＮは様々な地理上の位置に実際のデータセンターを設置する必要がなくなり得る。

クラウドコンピューティングの配備に関して言えば、セキュリティおよび制御されないレイテンシは、データに関する２つの主要な懸案事項である。レートレス符号トランスポートプロトコルを使用することで、ＴＣＰと比較してレイテンシは著しく改善できることが示された。さらに、レートレスパケットは符号化されているので、データの暗号化がこの方式の無料の副産物としてもたらされる。既存のトランスポートプロトコルと比較して、レートレス符号ベースのプロトコルは、著しい改善を提供する。特に、ＵＤＰはデータパケット配信の成功を保証せず、したがって信頼性が厳密に求められる多くのアプリケーションにおいて使用されていない。一方でＴＣＰは、特に長い高帯域幅のパイプ上では非常に非効率的な、数十年前のトランスポートプロトコルである。

ＴＣＰをより良いトランスポートプロトコルで置き換えることがスループットの極めて大きな改善をもたらすことを示す、つい最近の研究や測定がいくつもある。

ＴＣＰなどの成熟したプロトコルを置き換えることに伴う主要な課題は、両方のエンドノードでの変更が必要となるので、新しいプロトコルの採用である。実施形態は、エンドノードを変更せずにレートレス符号ベースのトランスポートプロトコルから恩恵を受けることを可能にする、効率的な方法を提供する。これらの実施形態は３つの主要なシナリオを説明している。企業内／データセンター間通信、サービスプロバイダの例、およびコンテンツ配信業者のシナリオである。

当業者は、様々な上述した方法のステップがプログラム式のコンピュータにより実施され得ることを容易に認識するであろう。本明細書では、いくつかの実施形態はまた、例として機械またはコンピュータが読み取り可能で、機械実行可能またはコンピュータ実行可能な命令のプログラムを符号化する、デジタルデータ記憶媒体などのプログラム記憶装置を網羅することを意図している。前記命令は、前記上述の方法のステップのいくつかまたはすべてを実施する。プログラム記憶装置は、例えばデジタルメモリ、磁気ディスクや磁気テープなどの磁気記憶媒体、ハードドライブ、または光学的に読み取り可能なデジタルデータ記憶媒体などであり得る。実施形態はまた、上述の方法の前記ステップを実施するためにプログラムされたコンピュータを網羅することを意図している。

「プロセッサ」または「ロジック」と呼ばれている任意の機能ブロックを含め、図に示されている様々な要素の機能は、専用ハードウェアおよび適切なソフトウェアと関連付けられているソフトウェアを実行可能なハードウェアの使用により提供され得る。プロセッサにより提供される場合、機能は単一の専用プロセッサ、単一の共有プロセッサ、または一部が共有であり得る複数の個別のプロセッサにより提供され得る。さらに、「プロセッサ」、「コントローラ」または「ロジック」という用語の明示的な使用は、ソフトウェアを実行可能なハードウェアに排他的に言及していると解釈されるべきでなく、デジタルシグナルプロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）および不揮発性記憶装置を暗黙的に含み得るが、これらに限定されるものではない。さらに、従来のおよび／またはカスタムの他のハードウェアも含まれ得る。同様に、図に示されているスイッチはどれも概念的なものでしかない。これらの機能はプログラムロジックの動作、専用のロジック、プログラム制御と専用のロジックの相互作用により、または手動によってでさえ実現され得る。文脈からより具体的に理解できるように、特定の技術は開発者により選択され得る。

本明細書の各ブロック図は、本発明の原理を具体化する電気回路の実例の概念図を示していることが、当業者により理解されよう。同様に、各フローチャート、フロー図、状態遷移図、疑似コード等は、コンピュータ可読媒体内で実質的に表現されており、コンピュータまたはプロセッサが明示的に表示されているかどうかに関わりなくそのようなコンピュータまたはプロセッサにそのように実行される、様々なプロセスを表していることが理解されよう。

説明および図は、本発明の原理を示しているに過ぎない。それで、当業者は、本明細書に明示的に説明または示されていないとしても、本発明の原理を具体化しその趣旨および範囲に含まれる様々な構成を考案することができることが理解されよう。さらに、本明細書で言及されているすべての例は主に、読者が本発明の原理、および当技術を向上させるために発明者によって提供された概念を理解できるように助けるという教育的な目的のみを明確に意図しており、このような特に言及されている例および状況に限定されるものではないと解釈されるべきである。さらに、本明細書で本発明の原理、態様および実施形態に言及しているすべての陳述、およびその特定の例は、その均等物を包含することを意図している。

Claims

プロキシノードであって、
通信リンクを介して第２のノードに送信されるデータを第１のノードから受信するよう動作可能な受信ロジックと、
プロキシノードのグループから選択されるプロキシノードを決定するように動作可能な決定ロジックであって、前記選択されるプロキシノードが、前記プロキシノード、前記選択されるプロキシノードと前記第２のノードとの間の通信リンクの通信リンク特性、および前記プロキシノードと前記第２のノードとの間の通信リンクの通信リンク特性の差が、閾値量の範囲に収まる場合は前記プロキシノードのグループの１つである前記選択されるプロキシノードを決定し、そうでなければ前記第２のノードを選択するように動作可能である、決定ロジックと、
前記決定ロジックによって選択された場合は、前記選択されるプロキシノードとの前記データ転送のためのレートレス符号化通信リンクを確立し、そうでなければ前記第２のノードとの前記データの直接転送のための通信リンクを確立するよう動作可能な、送信ロジックとを含む、
プロキシノード。
前記決定ロジックが、前記プロキシノードグループの複数のプロキシノードを前記選択されるプロキシノードとして選択できる場合、通信リンクの特性が前記プロキシノードと前記第２のノードとの間の前記通信リンクの前記通信リンク特性に最も近い、前記複数のプロキシノードのうちの１つを選択するよう動作可能である、請求項１に記載のプロキシノード。
前記受信ロジックが、前記データ転送と関連付けられているユーザのクラスおよびサービスタイプのうち少なくとも１つに基づいて、前記決定ロジックが選択されるプロキシノードを決定しないようにし、その代わりに前記送信ロジックに前記第２のノードとのデータ転送のための通信リンクを確立させるよう動作可能である、請求項１または２に記載のプロキシノード。
前記通信リンク特性が、通信遅延、ホップ数および前記通信リンクの容量のうち少なくとも１つを含む、請求項１から３のいずれか一項に記載のプロキシノード。
前記決定ロジックが、前記プロキシノードグループのプロキシノードと前記第２のノードとの間の、そのプロキシノードによって測定、報告される通信リンクの通信リンク特性に基づいて、前記選択されるプロキシノードを決定するよう動作可能である、請求項１から４のいずれか一項に記載のプロキシノード。
前記閾値量が、前記レートレス符号化通信リンクのパラメータに基づいて適合される、請求項１から５のいずれか一項に記載のプロキシノード。
ノードとの通信リンクの通信リンク特性を決定するようにとのリクエスト側プロキシノードからのリクエストを受信し、前記ノードとの前記通信リンクの前記通信リンク特性を確立し、前記通信リンク特性を前記リクエスト側プロキシノードに報告するよう動作可能な、通信リンク特性ロジックを含む、
請求項１から６のいずれか一項に記載のプロキシノード。
データを抽出するために受信したレートレス符号化通信リンクを復号し、ソースノードを識別するソースアドレスを、前記プロキシノードを識別するソースアドレスに置換し、前記データを受信側ノードに転送するよう動作可能な、復号ロジックを含む、
請求項１から７のいずれか一項に記載のプロキシノード。
データを抽出し、受信側ノードによってアクセスするために前記データを格納するために、受信したレートレス符号化通信リンクを復号するよう動作可能な、復号ロジックを含む、
請求項１から８のいずれか一項に記載のプロキシノード。
前記プロキシノードを識別する宛先アドレスを他のプロキシノードを識別する宛先アドレスに置換し、前記他のプロキシノードとの前記データの転送のためのレートレス符号化通信リンクを利用するよう動作可能な、符号化ロジックを含む、
請求項１から９のいずれか一項に記載のプロキシノード。
確認の指示が前記受信側ノードから受信されない場合、前記拒否の指示をソースノードに転送するよう動作可能な拒否ロジックを含む、
請求項１から１０のいずれか一項に記載のプロキシノード。
前記受信ロジックが、前記拒否の前記指示を受信すると、前記決定ロジックが選択されるプロキシノードを決定しないようにし、その代わりに前記送信ロジックに前記第２のノードとのデータ転送のための通信リンクを確立させるよう動作可能である、請求項１１に記載のプロキシノード。
データを抽出するためにレートレス符号化通信リンクを復号し、前記プロキシノードを識別する宛先アドレスを前記第１のノードを識別する宛先アドレスに置換し、前記データを前記第１のノードに転送するよう動作可能な、変更ロジックを含む、
請求項１から１２のいずれか一項に記載のプロキシノード。
プロキシノードの方法であって、
通信リンクを介して第２のノードに送信されるデータを第１のノードから受信するステップと、
プロキシノードのグループから選択されるプロキシノードを決定することであって、前記選択されるプロキシノードが、前記プロキシノード、前記選択されるプロキシノードと前記第２のノードとの間の通信リンクの通信リンク特性、および前記プロキシノードと前記第２のノードとの間の通信リンクの通信リンク特性の差が、閾値量の範囲に収まる場合は前記プロキシノードのグループの１つである前記選択されるプロキシノードを決定することをおこない、そうでなければ前記第２のノードを選択するステップと、
選択された場合は、前記選択されるプロキシノードとの前記データ転送のためのレートレス符号化通信リンクを確立し、そうでなければ前記第２のノードとの前記データの直接転送のための通信リンクを確立するステップとを含む、
プロキシノードの方法。
コンピュータで実行された時に、請求項１４に記載の方法のステップを実施するよう動作可能なコンピュータプログラム製品。