JP7154399B2 - データ伝送方法、装置、コンピュータ読み取り可能な媒体および電子デバイス - Google Patents

Description

［関連出願への相互参照］
本願は、２０１９年１月３日に中国特許庁へ出願された、出願番号が２０１９１０００４５４０．Ｘであり、出願名称が「データ伝送方法、装置、コンピュータ読み取り可能な媒体および電子デバイス」である中国特許出願の優先権を主張し、その全ての内容が参照することにより本願に組み込まれる。

本願は、コンピュータおよび通信技術の分野に関し、具体的に、データ伝送方法、装置、コンピュータ読み取り可能な媒体および電子デバイスに関する。

技術の発展に伴い、アプリケーションの通信プロセスはますます頻繁になり、例えば、ゲームクライアントは、サーバ側と頻繁に通信する必要があり、このようなアプリケーションは、ネットワーク環境に対する要求が非常に高く、低遅延および高い安定性の特性が、このようなアプリケーションの需要になっている。

無線環境の複雑性および無線通信プロトコルの特性のため、無線通信では、干渉、エアインタフェースの輻輳などの原因によるネットワークジッタ状況が生じることは避けられない。Ｗｉ－Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ、無線フィディリティ）は、周波数スペクトルが広いため、干渉をさらに受けやすくなるが、そのネットワークトポロジ層が少ないため、遅延が低い。移動通信ネットワーク（例えば、３Ｇ／４Ｇ／５Ｇなど）は、周波数スペクトルが狭いため、干渉を受けにくくなるが、データ伝送が、事業者のアクセス層を通過する必要があり、さらに、より高い遅延をもたらし、また、事業者の基地局デバイスの配置および容量により、高い遅延および輻輳の問題も引き起こされる。

本願の実施例は、サーバによって実行されるデータ伝送方法を提供し、当該方法は、第１デバイスによって複数のデータチャネルを介して送信された第１データパケットを受信するステップと、前記第１データパケットを解析して前記第１デバイスのアドレス情報を取得し、前記第１データパケットのデータパケットヘッダーに基づいて、前記第１データパケットに対して集約処理を実行して、第２データパケットを取得するステップと、前記第２データパケットのソースアドレス情報を指定アドレス情報に変更して、第３データパケットを取得するステップと、前記第３データパケットを第２デバイスに送信するステップであって、前記第２デバイスは、前記第１デバイスがアクセスする必要のあるデバイスであるステップと、を含む。

本願の実施例は、データ伝送装置を提供し、当該装置は、第１デバイスによって複数のデータチャネルを介して送信された第１データパケットを受信する受信ユニットと、前記第１データパケットを解析して前記第１デバイスのアドレス情報を取得し、前記第１データパケットのデータパケットヘッダーに基づいて、前記第１データパケットに対して集約処理を実行して、第２データパケットを取得する第１処理ユニットと、前記第２データパケットのソースアドレス情報を指定アドレス情報に変更して、第３データパケットを取得する第２処理ユニットと、前記第３データパケットを第２デバイスに送信する送信ユニットであって、前記第２デバイスは、前記第１デバイスがアクセスする必要のあるデバイスである送信ユニットと、を含む。

本願の実施例は、コンピュータプログラムが記憶されているコンピュータ読み取り可能な媒体をさらに提供し、前記コンピュータプログラムは、プロセッサによって実行される場合、上記の実施例に記載のデータ伝送方法を実現する。

本願の実施例は、電子デバイスをさらに提供し、該当電子デバイスは、１つまたは複数のプロセッサと、１つまたは複数のプログラムを記憶する記憶装置と、を含み、前記１つまたは複数のプログラムが前記１つまたは複数のプロセッサによって実行される場合、前記１つまたは複数のプロセッサに、上記の実施例に記載のデータ伝送方法を実現させる。

ここでの図面は、本明細書に組み込まれて、本明細書の一部を構成し、本願に適合する実施例を示し、明細書とともに本願の原理を説明するために使用される。明らかに、以下の説明における図面は、本願の一部の実施例にすぎず、当業者にとって、創造的な労働をしない前提で、これらの図面に基づいて他の図面を得ることもできる。

本願の実施例の技術案を適用できる例示的なシステムアーキテクチャを示す概略図である。 本願の一実施例によるデータ伝送方法を概略的に示すフローチャートである。 本願の一実施例によるデータ伝送方法を概略的に示すフローチャートである。 本願の一実施例による、第２デバイスによって送信されるデータパケットから、第１デバイスに送信する必要のある第４データパケットを決定することを概略的に示すフローチャートである。 本願の一実施例によるデュアルチャネル通信システムの構造を示す概略図である。 本願の一実施例によるデュアルチャネル通信システムの構造を示す概略図である。 本願の一実施例によるデュアルチャネル通信プロセスを概略的に示すフローチャートである。 本願の一実施例による、デュアルチャネルクライアントがｉｐメッセージにデュアルチャネルパケットヘッダーを付加することを示す概略図である。 本願の一実施例による、受信したデータメッセージに対してデュアルチャネルクライアントが処理することを概略的に示すフローチャートである。 本願の一実施例による、デュアルチャネルプロキシサーバとアプリケーションサーバとの間のインタラクションを概略的に示すフローチャートである。 本願の一実施例による、デュアルチャネルプロキシサーバとデュアルチャネル負荷分散サーバとの間のインタラクションを概略的に示すフローチャートである。 本願の一実施例による、無線ローカルエリアネットワークチャネルと有線チャネルからなるデュアルチャネルシステムを示す概略図である。 本願の一実施例による、無線ローカルエリアネットワークチャネルとブルートゥース（登録商標）チャネルからなるデュアルチャネルシステムを示す概略図である。 本願の一実施例によるデータ伝送装置を概略的に示すブロック図である。 本願の実施例を実現する電子デバイスに適するコンピュータシステムの構造を示す概略図である。

現在、図面を参照しながら、例示的な実施形態をより包括的に説明する。しかしながら、例示的な実施形態は、様々な形態で実施されることができ、本明細書に記載の例に限定されるものであると理解されるべきではなく、逆に、これらの実施形態を提供することにより、本願は、より包括的かつ完全なものになり、例示的な実施形態の構想を当業者に包括的に伝える。

また、説明される特徴、構造または特性は、任意の適切な方式で１つまたはより多くの実施例に組み込まれることもできる。以下の説明では、多くの具体的な詳細を提供することにより、本願の実施例に対する十分な理解が与えられる。しかしながら、当業者は、特定の詳細のうちの１つまたは複数なしで、本願の技術案を実践することができるか、または他の方法、構成要素、装置、ステップなどを採用することができる、ということを認識する。他の場合には、本願の各態様を曖昧にすることを回避するために、周知の方法、装置、実装または操作について詳細に図示または説明されていない。

図面に示されているブロック図は、単なる機能エンティティにすぎず、必ずしも物理的に独立したエンティティに対応する必要がなく。すなわち、これらの機能エンティティは、ソフトウェアの形式で実装されてもよく、またはこれらの機能エンティティは、１つまたは複数のハードウェアモジュールまたは集積回路において実装されてもよいし、あるいはこれらの機能エンティティは、異なるネットワークおよび／またはプロセッサ装置および／またはマイクロコントローラ装置において実装されてもよい。

図面に示されているフローチャートは、単なる例示的な説明にすぎず、必ずしもすべてのコンテンツおよび操作／ステップを含む必要がなく、必ずしも説明された順序に従って実行する必要もない。例えば、ある操作／ステップは分解されてもよいが、ある操作／ステップは統合または部分的に統合されてもよいし、そのため、実際に実行される順序は、実際の状況に応じて変更される可能性もある。

図１は、本願の実施例の技術案を適用できる例示的なシステムアーキテクチャを示す概略図である。

図１に示すように、システムアーキテクチャは、端末デバイス１０１と、マルチチャネルプロキシサーバ１０２と、アプリケーションサーバ１０３とを含むようにしてよい。マルチチャネルプロキシサーバ１０２は、端末デバイス１０１によって複数のデータチャネルを介して送信されたデータに対して集約処理を実行して、それをアプリケーションサーバ１０３に送信するために使用され、かつ、アプリケーションサーバ１０３によって送信されたデータを、複数のデータチャネルを介して端末デバイス１０１に返信するために使用される。

ここで、前記端末デバイス１０１は、スマートフォン、タブレットコンピュータおよびポータブルコンピュータのうちの１つまたは複数であってもよく、デスクトップコンピュータなどであってもよい。

図１の端末デバイス１０１、マルチチャネルプロキシサーバ１０２およびアプリケーションサーバ１０３の数は単なる例示的なものにすぎない、ということを理解されたい。実現の必要に応じて、任意の数の端末デバイス１０１、マルチチャネルプロキシサーバ１０２およびアプリケーションサーバ１０３を有してもよい。ここで、アプリケーションサーバ１０３は、ゲームサーバであってもよく、当該ゲームサーバは、単独のサーバであってもよく、複数のサーバからなるサーバクラスタなどであってもよい。

本願の一実施例では、端末デバイス１０１がスマートフォン（無論、タブレットコンピュータまたはポータブルコンピュータなどであってもよい）である場合、マルチチャネルプロキシサーバ１０２は、スマートフォンによって送信されたリンクデータを受信した後、スマートフォンに１つの仮想ポートを割り当てることができ、そして、当該仮想ポートをスマートフォンの実アドレス情報と関連付けて記憶するとともに、スマートフォンがアクセスするアプリケーションサーバのＶＩＰ（Ｖｉｒｔｕａｌ ＩＰ Ａｄｄｒｅｓｓ、仮想ＩＰアドレス）を記録する。マルチチャネルプロキシサーバ１０２は、スマートフォンによって複数のデータチャネルを介して送信されたアプリケーションサービスデータパケットを受信してから集約処理（例えば、重複排除処理）を行い、それから、重複排除処理後のアプリケーションサービスデータパケットのソースアドレス情報を、マルチチャネルプロキシサーバ１０２のアドレス情報（前述の仮想ポートが含まれる）に変更し、さらに、アプリケーションサーバ１０３に送信する。ここで、上記の複数のデータチャネルは、Ｗｉ－Ｆｉチャネルなどのような無線ローカルエリアネットワークチャネル、および４Ｇチャネルなどのような移動通信チャネルを含むようにしてよい。

マルチチャネルプロキシサーバ１０２は、アプリケーションサーバ１０３によって送信されたデータパケットを受信した後、当該データパケットのソースアドレス情報およびその前に記録されたＶＩＰ情報に基づいて、スマートフォンに送信する必要のあるデータパケットをフィルタリングし、そして、記録した仮想ポートおよびスマートフォンの実アドレス情報に基づいて、フィルタリングしたデータパケットの宛先アドレス情報を、スマートフォンの実アドレス情報に修正し、さらに、複数のデータチャネルを介してスマートフォンに送信することができる。

ここから分かるように、本願の実施例の技術案は、複数のデータチャネルを介してデータパケットを共同に伝送することによりデータパケットの伝送の安定性を保証することができ、データ伝送プロセスにおける高いパケットロス率および高い遅延の問題を効果的に解決し、かつ、フルスタックのマルチチャネルデータ伝送プロセスを実現して、様々な通信シーンでのサービスニーズを満たすことができる。

以下、図１に示すシステムアーキテクチャに基づいて、本願の実施例の技術案の実現詳細について詳細に説明する。

図２は、本願の一実施例によるデータ伝送方法を概略的に示すフローチャートであり、当該データ伝送方法は、サーバによって実行されてもよく、当該サーバは、１つのプロキシサーバであってもよく、例えば、図１に示すマルチチャネルプロキシサーバ１０２であってもよい。図２を参照すると、当該データ伝送方法は、少なくともステップＳ２１０～ステップＳ２４０を含み、詳細は以下のとおりであり、即ち、
ステップＳ２１０で、第１デバイスによって複数のデータチャネルを介して送信された第１データパケットを受信する。

本願の一実施例では、複数のデータチャネルは、Ｗｉ－Ｆｉチャネル、ブルートゥース（登録商標）チャネル、有線チャネル、移動通信ネットワーク（例えば３Ｇ／４Ｇ／５Ｇなど）などのようなデータチャネルのうちの２つ以上を含むようにしてよい。

本願の一実施例では、第１デバイスによって複数のデータチャネルを介して送信されたデータパケットは、完全に同じであってもよいし、１つのデータチャネルを介してフル量のデータパケットが送信される一方、他のデータチャネルを介して非フル量のデータパケットが送信されてもよく（例えば、５つごとに２つのデータパケットのみが送信されてもよいなど）、また、複数のデータチャネルを介して非フル量のデータパケットがそれぞれ送信されてもよく、これにより、受信側は、集約処理を実行して完全なデータパケットを取得することができる。

本願の一実施例では、第１デバイスによって送信された第１データパケットは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、伝送制御プロトコル）データパケットであってもよく、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ、ユーザデータグラムプロトコル）データパケットであってもよいし、またはＩＰデータパケットであってもよい。

本願の一実施例では、マルチチャネルプロキシサーバは、第１デバイスとのＴＣＰ接続を確立するプロセスにおいて、受信した、第１デバイスによって送信された１番目のＴＣＰデータメッセージがＴＣＰ接続を確立するためのデータメッセージ（例えばｓｙｎメッセージ）ではない場合、接続をリセットするためのデータメッセージ（例えばｒｓｔメッセージ）を第１デバイスに送信することにより、第１デバイスがマルチチャネルプロキシサーバとの接続をできるだけ早く再確立することができる、ということを確保する。

本願の一実施例では、マルチチャネルプロキシサーバは、第１デバイスによって送信された、ＴＣＰ接続を切断するためのデータメッセージ（例えばｆｉｎメッセージ）を受信すると、所定の期間を経過した後、記憶されている、第１デバイスに関連する情報（例えば第１デバイスのアドレス情報、第１デバイスに割り当てられた仮想ポートの情報、第１デバイスがアクセスする必要のあるアドレス情報など）を削除することができる。

ステップＳ２２０で、前記第１データパケットを解析して前記第１デバイスのアドレス情報を取得し、前記第１データパケットのデータパケットヘッダーに基づいて、前記第１データパケットに対して集約処理を実行して、第２データパケットを取得する。

本願の一実施例では、第１デバイスのアドレス情報には、第１デバイスのイントラネットＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ、インターネットプロトコル）アドレスおよびイントラネットポート情報などが含まれてもよい。

本願の一実施例では、第１データパケットのデータパケットヘッダーに基づいて、第１データパケットに対して集約処理を実行することは、フル量でかつ重複していないデータパケットを取得するために、第１デバイスによって複数のデータチャネルを介して送信されたデータパケットに対して、重複排除処理および／または統合処理を実行することであってもよい。例えば、第１データパケットのデータパケットヘッダーにおけるパケット番号に基づいて、重複排除処理（例えば、パケット番号が重複しているデータパケットを削除する処理）および／または統合処理（例えば、パケット番号が異なっているデータパケットを統合する処理）を実行してもよい。

ステップＳ２３０において、前記第２データパケットのソースアドレス情報を指定アドレス情報に変更して、第３データパケットを取得する。

本願の一実施例では、指定アドレス情報には、マルチチャネルプロキシサーバのＩＰアドレス、およびマルチチャネルプロキシサーバによって第１デバイスに割り当てられた仮想ポート情報が含まれてもよい。ここで、マルチチャネルプロキシサーバは、第１デバイスに仮想ポート情報を割り当てた後、当該仮想ポート情報を第１デバイスの実アドレス情報と関連付けて記憶することができ、さらに、他のデバイスによって送信されたデータパケットを受信すると、当該データパケットに含まれる仮想ポート情報に基づいて、当該データパケットが第１デバイスに送信されるデータパケットであるかどうかを決定することができる。

ステップＳ２４０において、前記第３データパケットを第２デバイスに送信する。

本願の一実施例では、第２デバイスは、第１デバイスがアクセスする必要のあるデバイスであってもよく、例えば、アプリケーションサーバなどであってもよい。

本願の一実施例では、第１デバイスによって送信された第１データパケットを解析して、第１デバイスがアクセスする必要のあるアドレス情報を取得し、そして、第１デバイスがアクセスする必要のあるアドレス情報に基づいて、第２デバイスを決定することができる。第２デバイスがアプリケーションサーバである場合、第１デバイスがアクセスする必要のあるアドレス情報は、アプリケーションサーバのＶＩＰであってもよく、ここで、アプリケーションサーバの１つのＶＩＰは、１つの第１デバイスに対応する。

本願の一実施例では、マルチチャネルプロキシサーバは、さらに、第２デバイスによって送信されるデータメッセージのメッセージセグメントの最大長さを設定することができる。例えば、ＴＣＰメッセージプロトコルのｍｓｓフィールドを設定することにより、メッセージセグメントの最大長さを設定する。

図２に示す実施例の技術案は、複数のデータチャネルを介してデータパケットを共同に伝送することによりデータパケットの伝送の安定性を保証することができ、データ伝送プロセスにおける高いパケットロス率および高い遅延の問題を効果的に解決するとともに、集約処理により、第２デバイスが同じデータを繰り返して受信する必要がないことも保証でき、第２デバイスが感知しないマルチデータチャネル伝送プロセスを実現でき、また、第２データパケットのソースアドレス情報を指定アドレス情報（例えばプロキシサーバのアドレス情報）に変更してから第２デバイスに送信するため、第１デバイスとマルチチャネルプロキシサーバとの間でどのような通信方式を採用しても、マルチデータチャネルでの伝送を行うことができ、フルスタックのマルチチャネルデータ伝送プロセスを実現して、様々な通信シーンでのサービスニーズを満たすことができた。

図２に示す実施例の技術案に基づき、図３は、本願の一実施例によるデータ伝送方法を概略的に示すフローチャートであり、当該データ伝送方法は、サーバによって実行されてもよく、当該サーバは、図１に示すマルチチャネルプロキシサーバ１０２であってもよい。図３を参照すると、当該データ伝送方法は、少なくともステップＳ３１０～ステップＳ３３０を含み、詳細は以下のとおりであり、即ち、
ステップＳ３１０で、前記第２デバイスによって送信されたデータパケットから、前記第１デバイスに送信する必要のある第４データパケットを決定する。

本願の一実施例では、第４データパケットは、ＩＰデータパケットであってもよく、即ち、第２デバイスは、ＩＰデータパケットを直接的にマルチチャネルプロキシサーバに送信することができ、さらに、フルスタックネットワークのマルチチャネル伝送がシームレスにサポートされることができる。

本願の一実施例では、マルチチャネルプロキシサーバは、第１デバイスによって送信された第１データパケットを受信した後、当該第１データパケットを解析して、第１デバイスがアクセスする必要のあるアドレス情報を取得し、そして、当該アドレス情報を記憶することができ、第２デバイスによって送信されたデータパケットを受信した後、記憶されている、第１デバイスがアクセスする必要のあるアドレス情報に基づいて、第１デバイスに送信する必要のある第４データパケットを決定することができる。

図４は、本願の実施例において、第２デバイスによって送信されたデータパケットから、第１デバイスに送信する必要のある第４データパケットを決定するフローチャートである。図４に示すように、具体的には、下記のステップを含み、即ち、
ステップＳ４１０、前記第２デバイスによって送信されたデータパケットのソースアドレス情報を決定する。

本願の一実施例では、第２デバイスによって送信されたデータパケットを解析することにより当該データパケットのソースアドレス情報を取得することができる。第２デバイスがアプリケーションサーバである場合、第２デバイスによって送信されたデータパケットのソースアドレス情報は、アプリケーションサーバの仮想アドレス情報であってもよい。

ステップＳ４２０、前記第１デバイスがアクセスする必要のあるアドレス情報に基づいて、前記第２デバイスによって送信されたデータパケットから、前記ソースアドレス情報と前記第１デバイスがアクセスする必要のあるアドレス情報とがマッチングしているデータパケットをフィルタリングし、フィルタリングされたデータパケットを前記第４データパケットとする。

本願の一実施例では、第２デバイスによって送信されたデータパケットは、すべて、第１デバイスに送信されるものであるわけではないが、第１デバイスに送信されるデータパケットのソースアドレス情報は、第１デバイスによって送信されたデータパケットにおける宛先アドレス情報と同じであり、そのため、第２デバイスによって送信されたデータパケットから、ソースアドレス情報と第１デバイスがアクセスする必要のあるアドレス情報とがマッチングしているデータパケットをフィルタリングすることができ、これを第１デバイスに送信する必要のある第４データパケットとすることができる。

引き続き図３を参照すると、ステップＳ３２０で、前記第４データパケットの宛先アドレス情報を前記第１デバイスのアドレス情報に変更して、第５データパケットを取得する。

本願の一実施例では、マルチチャネルプロキシサーバは、第１デバイスに仮想ポートを事前に割り当て、そして、第１デバイスに割り当てられた仮想ポートを第１デバイスのアドレス情報と関連付けて記憶することができ、また、第４データパケットの宛先アドレス情報には、マルチチャネルプロキシサーバのＩＰアドレスと、マルチチャネルプロキシサーバが第１デバイスに割り当てた仮想ポートの情報とが含まれ、そのため、この仮想ポートの情報に基づいて、記憶されている仮想ポートとアドレス情報との関連関係から、第１デバイスのアドレス情報を検索することができ、そして、第４データパケットの宛先アドレス情報を第１デバイスのアドレス情報に変更する。ここで、第１デバイスのアドレス情報には、第１デバイスのイントラネットアドレスおよびイントラネットポートが含まれてもよい。

ステップＳ３３０において、前記第５データパケットを前記第１デバイスに送信する。

本願の一実施例では、データパケットの伝送の安定性を確保し、さらに、データ伝送プロセスにおける高いパケットロス率および高い遅延の問題を解決するために、第５データパケットを、複数のデータチャネルを介して第１デバイスに送信することができる。第１デバイスは、複数のデータチャネルを介して伝送されたデータパケットを受信した後、集約処理を行うこともでき、当該集約処理は、フル量かつ重複しないデータパケットを取得するように、第１デバイスによって複数のデータチャネルを介して受信されたデータパケットに対して行う重複排除処理および／または統合処理であってもよい。

本願の一実施例では、第１デバイスは、さらに、第１データパケットを伝送するためのデータチャネルの情報をマルチチャネルプロキシサーバに送信するために使用され、具体的な送信方式は、リアルタイム送信、周期的送信、変化が発生した場合に送信するなどの方式であってもよく、マルチチャネルプロキシサーバは、当該データチャネルの情報を受信した後、記憶することができ、さらに、マルチチャネルプロキシサーバは、第５データパケットを第１デバイスに送信する際に、記憶している最新のデータチャネル情報に基づいて、第５データパケットを第１デバイスに送信することができ、これにより、マルチチャネルプロキシサーバは、最新のデータチャネル情報を認識し採用して第１デバイスにデータパケットを送信できる、ということが確保される。

本願の一実施例では、マルチチャネルプロキシサーバは、さらに、第１デバイスによって送信された第１データパケットに対する受信状況、または他のデータパケットに対する受信状況に基づいて、第１デバイスがデータパケットを送信する際に採用したデータチャネルのネットワーク状態、例えば遅延状況、輻輳状況などを決定し、さらに、マルチチャネルプロキシサーバは、第５データパケットを第１デバイスに送信するとき、第１デバイスがデータパケットを送信する際に採用したデータチャネルのネットワーク状態の優劣に基づいて、１つまたは複数のデータチャネルを選択して第５データパケットを第１デバイスに送信することができる。例えば、あるデータチャネルのネットワーク状態が良い場合、当該ネットワーク状態が良いであるデータチャネルのみを介して第５データパケットを伝送することができるため、さらに、データチャネルへの占有およびトラフィックへの消費が削減されることができる一方、複数のデータチャネルのネットワーク状態がいずれも悪い場合、複数のデータチャネルを介して第５データパケットを伝送することができるため、さらに、データパケットの伝送の安定性が保証され、データ伝送中に高いパケットロス率および高い遅延が発生するという問題が回避されることができる。

本願の一実施例では、第１デバイスがデータパケットを送信する際に採用したデータチャネルのネットワーク状態を決定することは、第１デバイスによって送信されたデータパケットを受信した第１時刻と、第１デバイスによって送信されたデータパケットに含まれている第２時刻とに基づいて、第１デバイスによって送信されたデータパケットの遅延を計算し、そして、第１デバイスによって送信されたデータパケットの遅延に基づいて、第１デバイスがデータパケットを送信する際に採用したデータチャネルのネットワーク状態を決定することであることができる。ここで、第１デバイスによって送信されたデータパケットの遅延が大きいほど、第１デバイスがデータパケットを送信する際に採用したデータチャネルのネットワーク状態が悪くなるということが説明され、第１デバイスによって送信されたデータパケットの遅延が小さいほど、第１デバイスがデータパケットを送信する際に採用したデータチャネルのネットワーク状態が良くなるということが説明される。

本願の一実施例では、上記の第２時刻は、第１デバイスがデータパケットを送信する時刻と、プロキシサーバと第１デバイスとの間のクロック同期補償値とに基づいて決定されたものである。具体的には、第１デバイスは、一定の期間ごとに、マルチチャネルプロキシサーバにマルチチャネルプロキシサーバのタイムスタンプを要求するとともに、毎回のマルチチャネルプロキシサーバからの返信遅延を記録することができ、平均により、第１デバイスとマルチチャネルプロキシサーバとの間の平均遅延ａｖｇＤｅｌａｙを取得し、そして、第１デバイスは、記録した、最後の一回にサーバに要求したときに返信されたマルチチャネルプロキシサーバのタイムスタンプｓｖｒＴｉｍｅ、および、このときの第１デバイスの時間ｌｏｃａｌＳｔａｒｔＴｉｍｅに基づいて、このときのマルチチャネルプロキシサーバの時間ｓｖｒＳｔａｒｔＴｉｍｅ＝ｓｖｒＴｉｍｅ＋ａｖｇＤｅｌａｙ／２を計算し、さらに、ｓｖｒＳｔａｒｔＴｉｍｅ－ｌｏｃａｌＳｔａｒｔＴｉｍｅを、マルチチャネルプロキシサーバと第１デバイスとの間のクロック同期補償値とし、第１デバイスがデータパケットを送信した時刻がｃｕｒＴｉｍｅであると仮定すると、上記の第２時刻は、ＣＳｔｉｍｅ＝ｃｕｒＴｉｍｅ＋ｓｖｒＳｔａｒｔＴｉｍｅ－ｌｏｃａｌＳｔａｒｔＴｉｍｅである。

本願の一実施例では、マルチチャネルプロキシサーバは、さらに、第１デバイスがデータパケットを受信する際に採用したデータチャネルのネットワーク状態、例えば遅延状況、輻輳状況などを決定するように、第１デバイスからフィードバックされた、第１デバイスに伝送されたデータパケットに対する受信状況を受信することができ、さらに、マルチチャネルプロキシサーバは、第５データパケットを第１デバイスに送信するとき、第１デバイスがデータパケットを受信する際に採用したデータチャネルのネットワーク状態の優劣に基づいて、１つまたは複数のデータチャネルを選択して第５データパケットを第１デバイスに送信することができる。例えば、あるデータチャネルのネットワーク状態が良い場合、当該ネットワーク状態が良いであるデータチャネルのみを介して第５データパケットを伝送することができるため、さらに、データチャネルへの占有およびトラフィックへの消費が削減されることができる一方、複数のデータチャネルのネットワーク状態がいずれも悪い場合、複数のデータチャネルを介して第５データパケットを伝送ことができるため、さらに、データパケットの伝送の安定性が保証され、データ伝送中に高いパケットロス率および高い遅延が発生する問題が回避されることができる。

本願の一実施例では、マルチチャネルプロキシサーバは、さらに、第１デバイスによって送信された第１データパケットに対する受信状況、または他のデータパケットに対する受信状況に基づいて、第１デバイスがデータパケットを送信する際に採用したデータチャネルのネットワーク状態を決定することができ、そして、第１デバイスがデータパケットを送信する際に採用したデータチャネルのネットワーク状態を第１デバイスに送信し、これにより、第１デバイスが当該ネットワーク状態に基づいて、データパケットを再び送信する際に、採用したデータチャネルを選択する。例えば、あるデータチャネルのネットワーク状態が良い場合、第１デバイスは、データパケットを再び送信するとき、当該ネットワーク状態が良いであるデータチャネルのみを介して、マルチチャネルプロキシサーバにデータパケットを送信することができるため、さらに、データチャネルへの占有およびトラフィックへの消費が削減されることができる一方、複数のデータチャネルのネットワーク状態がいずれも悪い場合、第１デバイスは、データパケットを再び送信するとき、複数のデータチャネルを介して、マルチチャネルプロキシサーバにデータパケットを送信することができるため、さらに、データパケットの伝送の安定性が保証され、データ伝送中に高いパケットロス率および高い遅延が発生する問題が回避されることができる。

本願の一実施例では、第１デバイスは、さらに、マルチチャネルプロキシサーバに送信される第１データパケットの受信状況に基づいて、第１デバイスがデータパケットを送信する際に採用したデータチャネルのネットワーク状態を決定し、そして、当該ネットワーク状態に基づいて、データパケットを送信する時に、採用したデータチャネルを選択することができる。例えば、あるデータチャネルのネットワーク状態が良い場合、第１デバイスは、当該ネットワーク状態が良いであるデータチャネルのみを介して、プロキシサーバにデータパケットを送信することができるため、さらに、データチャネルへの占有およびトラフィックへの消費が削減されることができる一方、複数のデータチャネルのネットワーク状態がいずれも悪い場合、第１デバイスは、複数のデータチャネルを介して、プロキシサーバにデータパケットを送信することができるため、さらに、データパケットの伝送の安定性が保証され、データ伝送中に高いパケットロス率および高い遅延が発生する問題が回避されることができる。

以下、第１デバイスをデュアルチャネルクライアントとし、プロキシサーバをデュアルチャネルプロキシサーバ（即ち、以下では、２つのデータチャネルを介してデータを伝送することを例として説明する）とし、第２デバイスをアプリケーションサーバとすることを例として、本願の実施例の技術案の実現詳細について、詳細に説明する。

本願の一実施例では、図５に示すように、本願の一実施例によるデュアルチャネル通信システムは、主に、ユーザ端末５１と、デュアルチャネル負荷分散サーバ５０２と、デュアルチャネルプロキシサーバ５０３と、アプリケーションサーバ５０４とを含む。ここで、ユーザ端末５１には、アプリケーションクライアント５０５と、ネットワークカード５０６と、デュアルチャネルクライアント５０１とが配置され、デュアルチャネルクライアント５０１は、ネットワークカードを介してアプリケーションクライアント５０５と通信する。

本願の一実施例では、アプリケーションクライアント５０５とデュアルチャネルクライアント５０１との間で、ｔｃｐメッセージおよびｕｄｐメッセージを送信することができる。デュアルチャネルクライアント５０１は、アプリケーションクライアント５０５によって送信されたｕｄｐメッセージを受信した後、デュアルチャネル（例えばＷｉ－Ｆｉチャネルおよび４Ｇチャネル）を介して、デュアルチャネル負荷分散サーバ５０２に送信することができ、そして、デュアルチャネル負荷分散サーバ５０２によってデュアルチャネルプロキシサーバ５０３に転送され、デュアルチャネルプロキシサーバ５０３は、受信したｕｄｐメッセージに対して重複排除を行ってから、アプリケーションサーバ５０４に転送する。

本願の一実施例では、デュアルチャネルプロキシサーバ５０３は、アプリケーションサーバ５０４によって送信されたｕｄｐメッセージを受信した後、当該ｕｄｐメッセージを、デュアルチャネル（例えばＷｉ－Ｆｉチャネルおよび４Ｇチャネル）を介して、デュアルチャネル負荷分散サーバ５０２に送信することができ、そして、デュアルチャネル負荷分散サーバ５０２によってデュアルチャネルクライアント５０１に転送され、デュアルチャネルクライアント５０１は、受信したｕｄｐメッセージに対して重複排除を行ってから、ネットワークカードを介してアプリケーションクライアント５０５に転送する。

本願の一実施例では、デュアルチャネルクライアント５０１は、ネットワークカード５０６から、ｔｃｐのｓｙｎメッセージ（ｓｙｎメッセージは、接続を確立するためのメッセージを表すものである）をインターセプトした後、デュアルチャネルクライアント５０１は、宛先アドレス情報に基づいて、直ちにアプリケーションサーバ５０４とｔｃｐリンクを確立する。ｔｃｐリンクが確立された後、デュアルチャネルクライアント５０１は、ネットワークカード５０６を介して、アプリケーションクライアント５０５にｔｃｐのａｃｋ＋ｓｙｎメッセージ（ａｃｋ＋ｓｙｎメッセージは、接続の確立を確認するメッセージを表すものである）を送信し、後続のｔｃｐリンクの確立フローを続行する。デュアルチャネルクライアント５０１は、アプリケーションクライアント５０５とのｔｃｐ仮想リンクの確立を完成した後、ｆｄ１（アプリケーションクライアント５０５と通信）とｆｄ２（アプリケーションサーバ５０４と通信）とをブリッジングし、そして、アプリケーションクライアント５０５がアプリケーションサーバ５０４に送信した上りｔｃｐメッセージを転送するとともに、アプリケーションサーバ５０４がアプリケーションクライアント５０５に送信した下りｔｃｐメッセージを転送する。

前述の問題に基づいて、本願の一実施例では、図６に示すように、本願の一実施例によるデュアルチャネル通信システムは、主に、ユーザ端末６１と、デュアルチャネル負荷分散サーバ６０２（デュアルチャネル負荷分散サーバ６０２ａおよびデュアルチャネル負荷分散サーバ６０２ｂ）と、デュアルチャネルプロキシサーバ６０３と、アプリケーションサーバ６０４とを含む。ここで、ユーザ端末６１には、アプリケーションクライアント６０５と、ネットワークカード６０６と、デュアルチャネルクライアント６０１とが配置されている。説明すべきものとして、図６に示すデュアルチャネル負荷分散サーバ６０２の数は、例示にすぎず、本願の他の実施例において、任意の数のデュアルチャネル負荷分散サーバを配置してもよく、デュアルチャネル負荷分散サーバを配置しなくてもよい。

本願の一実施例では、デュアルチャネルプロキシサーバ６０３は、あるデュアルチャネルクライアント６０１によって送信されたｔｃｐリンクのｆｉｎパケットを受信した場合、このデュアルチャネルクライアント６０１のｔｃｐリンクの状態をｆｉｎ状態としてマークし、ｆｉｎＯｕｔＴｉｍｅ（デフォルトは１０秒）の後、当該ｔｃｐリンク情報を、クライアント情報モジュール６０３１から削除し、ｆｉｎＯｕｔＴｉｍｅタイムアウト時間は、ｔｃｐリンクの４ウェイウェイウェーブハンド（Ｆｏｕｒ－Ｗａｙ Ｗａｖｅｈａｎｄ）が正常に終了できることを保証するために使用されたものである。

本願の一実施例では、デュアルチャネルプロキシサーバ６０３は、あるデュアルチャネルクライアントのｔｃｐリンクを新たに確立するとき、当該ｔｃｐリンクの１番目のｔｃｐメッセージが３ウェイハンドシェイク（３－ｗａｙ ｈａｎｄｓｈａｋｅ）のｓｙｎメッセージであるかどうかを判断し、そうであれば、ｔｃｐリンク情報を確立してクライアント情報モジュール６０３１に記憶し、そうでなければ、当該デュアルチャネルクライアントにｒｓｔメッセージを返信し、当該不正なｔｃｐリンクを中断し、これにより、デュアルチャネルクライアントが当該ｔｃｐリンクを迅速に再確立することができる、ということが保証される。

本願の一実施例では、デュアルチャネルクライアント６０１は、アプリケーションクライアント６０５によって送信されたｔｃｐリンクのｓｙｎメッセージを受信した場合、ｔｃｐメッセージプロトコルのｍｓｓフィールドの値を設定することができ、これにより、アプリケーションサーバ６０４によって送信されたデータパケットのいずれかが制御可能な長さ範囲内（ｔｃｐメッセージの長さは、ｍｓｓ値および送信ウィンドウ値のうちの最小値を取る）にある、ということが保証され、データパケットが大きすぎることでバッファーオーバーフローを引き起こすという問題と、伝送効率に影響を与えるという問題とが防止される。

本願の一実施例では、デュアルチャネルプロキシサーバ６０３は、アプリケーションサーバ６０４から返信されたｔｃｐリンクのｓｙｎ＋ａｃｋメッセージを受信した場合、ｔｃｐメッセージプロトコルのｍｓｓフィールドを設定することができ、これにより、アプリケーションクライアントによって送信されたデータパケットのいずれかが制御可能な長さ範囲内にある、ということが保証され、データパケットが大きすぎることでバッファーオーバーフローを引き起こすという問題と、伝送効率に影響を与えるという問題とが防止される。

本願の一実施例では、デュアルチャネルプロキシサーバ６０３は、ｔｃｐリンクのｍｓｓ値の設定が有効になることを保証するために、ネットワークカードを最適化するための次のいくつかのオプション、即ち、ＧＲＯ（Ｇｅｎｅｒｉｃ Ｒｅｃｅｉｖｅ Ｏｆｆｌｏａｄｉｎｇ、汎用受信オフロード）、ＴＳＯ（ＴＣＰ Ｓｅｇｍｅｎｔａｔｉｏｎ Ｏｆｆｌｏａｄ、ＴＣＰセグメンテーションオフロード）、ＧＳＯ（Ｇｅｎｅｒｉｃ Ｓｅｇｍｅｎｔａｔｉｏｎ Ｏｆｆｌｏａｄ、汎用セグメンテーションオフロード）、ＬＲＯ（Ｌａｒｇｅ Ｒｅｃｅｉｖｅ Ｏｆｆｌｏａｄ、大規模受信オフロード）をそれぞれオフにすることができる。

図６および図７に示すように、デュアルチャネルクライアント６０１を起動した後、仮想ネットワークカード６０７（当該仮想ネットワークカードは、携帯電話におけるエンティティネットワークカードを介してアプリケーションクライアントと通信する）を作成するとともに、２つのスレッド（即ち、上りスレッドおよび下りスレッド）を確立し、同時に、２つのｕｄｐのｓｏｃｋｅｔリンクを確立して、例えばＷｉ－Ｆｉチャネルおよび第４世代移動通信（略称４Ｇ）チャネルなどの無線チャネルにバインディングすることができる。

本願の一実施例では、デュアルチャネルクライアント６０１は、対応するアプリケーションサービス構成に従って、クラウド制御サーバに、アプリケーションサーバ６０４のＩＰアドレスを下り送信するように要求する。このＩＰアドレスに従って、ｉｐｔａｂｌｅｓフィルタリングポリシーを設定して、アプリケーションクライアント６０５によって送信されたＩＰメッセージを、ネットワークカード６０６を介してインターセプトして、仮想ネットワークカード６０７に転送する。

本願の一実施例では、図８に示すように、デュアルチャネルクライアント６０１は、仮想ネットワークカード６０７から、アプリケーションクライアント６０５によって送信されたｉｐメッセージを受信した後、デュアルチャネルパケットヘッダーを付加して、「デュアルチャネルパケットヘッダー＋アプリケーションサービスＩＰメッセージ」フォーマットのデュアルチャネル上りメッセージを形成することができ、そして、ｕｄｐプロトコルに基づいて、かつ、例えばＷｉ－Ｆｉなどの無線ローカルエリアネットワークチャネルおよび例えば４Ｇチャネルなどの移動通信チャネル、この２つのチャネルを介して送信することができる。

本願の一実施例では、図６に示すように、デュアルチャネルクライアント６０１は、デュアルチャネルを介して送信するとき、先に、デュアルチャネル負荷分散サーバ６０２に送信し、そして、デュアルチャネル負荷分散サーバ６０２によってデュアルチャネルプロキシサーバ６０３の上りスレッドに転送され、さらに、デュアルチャネルプロキシサーバ６０３によって重複排除処理を行ってからアプリケーションサーバ６０４に転送されることもできる。

本願の一実施例では、図７に示すように、デュアルチャネルクライアント６０１は、デュアルチャネルを介して送信するとき、直接的にデュアルチャネルプロキシサーバ６０３に送信し、そして、デュアルチャネルプロキシサーバ６０３によって重複排除処理を行ってからアプリケーションサーバ６０４に転送されることもできる。

本願の一実施例では、アプリケーションサービスがゲームサービスである場合、デュアルチャネルクライアント６０１によって送信されたデュアルチャネル上りメッセージのプロトコルフィールドは、以下のとおりであり、即ち、
ｔｙｐｅｄｅｆ ｓｔｒｕｃｔ ＭｕｔｉＴｕｎｎｅｌＵＰＨｅａｄ｛
ｕｉｎｔ３２＿ｔ ｍ＿ｂｕｓｓＩｄ；／／ゲーム識別子
ｕｉｎｔ８＿ｔ ｖｅｒ；／／メインチャネル識別子
ｕｉｎｔ８＿ｔ ｔｙｐｅ；／／タイプ、現在の上りパケットのチャネル番号またはパケットタイプ
ｕｉｎｔ３２＿ｔ ｓｅｑｎｏ；／／パケット番号
ｕｉｎｔ３２＿ｔ ｄｅｖＫｅｙ；／／モバイルデバイスの一意の識別子
ｕｉｎｔ８＿ｔ ｍｕｔｉｓｅｔＩＤ；／／メインチャネルの事業者ＩＤ
｝ＭｕｔｉＴｕｎｎｅｌＵＰＨｅａｄ；／／フルスタックバージョンのプロトコルコード

本願の一実施例では、図９に示すように、デュアルチャネルクライアント６０１は、デュアルチャネルを介して送信された「デュアルチャネルパケットヘッダー＋アプリケーションサービスＩＰメッセージ」フォーマットのデュアルチャネル下りメッセージを受信した後、重複排除ロジックにより、受信したデュアルチャネル下りメッセージに対して重複排除処理を行い、かつ、デュアルチャネル下りメッセージのパケットヘッダーを除去した後、ｄａｔａ（データ）フィールドを直接的にＩＰメッセージに格納して、当該ＩＰメッセージを仮想ネットワークカード６０７に送信し、これにより、仮想ネットワークカード６０７が、当該アプリケーションサービスＩＰメッセージを、ネットワークカード６０６を介してアプリケーションクライアント６０５に送信して、当該アプリケーションサービスＩＰメッセージは、ゲームＩＰメッセージであってもよい。

本願の一実施例では、デュアルチャネルクライアント６０１が受信したデュアルチャネル下りメッセージのプロトコルフィールドは、以下のとおりであり、即ち、
ｔｙｐｅｄｅｆ ｓｔｒｕｃｔ｛
ｕｉｎｔ３２＿ｔ ｓｅｑｎｏ；／／パケット番号
ｕｉｎｔ３２＿ｔ ｄｅｖｋｅｙ；／／クライアントの一意の識別子
ｃｈａｒ ｄａｔａ［０］；／／パケットコンテンツ
｝ＭｕｔｉＴｕｎｎｅｌＤｏｗｎＨｅａｄ

本願の一実施例では、図６に示すように、デュアルチャネルクライアント６０１が受信したデュアルチャネル下りメッセージは、アプリケーションサーバ６０４がアプリケーションサービスＩＰメッセージをデュアルチャネルプロキシサーバ６０３に送信するための下りスレッドに、デュアルチャネルプロキシサーバ６０３がデュアルチャネルパケットヘッダーを付加してから生成されたものであってもよい。デュアルチャネルプロキシサーバ６０３がデュアルチャネル下りメッセージを生成した後、それをデュアルチャネル負荷分散サーバ６０２に送信し、そして、デュアルチャネル負荷分散サーバ６０２によってデュアルチャネルクライアント６０１に転送される。

本願の一実施例では、図７に示すように、デュアルチャネルプロキシサーバ６０３は、デュアルチャネル下りメッセージを生成した後、直接的にデュアルチャネルクライアント６０１に送信してもよい。そして、デュアルチャネルクライアント６０１は、重複排除処理を行って、デュアルチャネル下りメッセージのパケットヘッダーを除去した後、ｄａｔａ（データ）フィールドを直接的にＩＰメッセージに格納して、当該ＩＰメッセージをアプリケーションクライアント６０５に送信する。

以下、図１０を参照しながら、本願の実施例におけるデュアルチャネルプロキシサーバとアプリケーションサーバとの間のインタラクションフローについて詳細に説明し、当該アプリケーションサーバは、ゲームサーバであってもよい。

図１０に示すように、本願の一実施例によるデュアルチャネルプロキシサーバとアプリケーションサーバとの間のインタラクションフローは、下記のステップを含み、即ち、

ステップＳ１００１で、デュアルチャネルプロキシサーバは、デュアルチャネルクライアント（デュアルチャネルクライアントによって送信されたデータパケットを直接的に受信するか、または負荷分散サーバを介して間接的に受信することができる）によってデュアルチャネルを介して送信された上りデータパケットを受信する。

ステップＳ１００２、デュアルチャネルプロキシサーバは、受信したデュアルチャネルパケットヘッダーおよび内部通信パケットヘッダーを除去するとともに重複排除を行い、そして、ＩＰメッセージにおけるアドレスおよびポートを偽装してからアプリケーションサーバに送信する。

本願の一実施例では、デュアルチャネルプロキシサーバは、デュアルチャネルクライアントによって送信された上りデータパケットを受信した後、当該上りデータパケットのパケットヘッダーに含まれているデュアルチャネルクライアントの実アドレス情報（イントラネットＩＰおよびイントラネットポートが含まれる）をクライアント情報モジュールに記録して、仮想ポートプールモジュールにより、当該デュアルチャネルクライアントに１つの仮想のローカルポートを割り当てるとともに、当該上りデータパケットがアクセスする必要のあるアプリケーションサーバアドレスに基づいて、ＶＩＰ情報モジュールを更新し、アクセスしようとするアプリケーションサーバのＶＩＰを当該モジュールに追加する。

本願の一実施例では、デュアルチャネルプロキシサーバは、上りデータパケットのパケットヘッダーに含まれるクライアントの一意の識別子に従って、４ＧおよびＷｉ－Ｆｉチャネルから送信されたクライアントＩＰメッセージを識別して、重複排除処理を行うことができる。

本願の一実施例では、デュアルチャネルプロキシサーバがＩＰメッセージにおけるアドレスおよびポート情報を偽装することは、主に、重複排除処理後の上りＩＰメッセージにおけるアドレス情報を、自機のアドレス情報（デュアルチャネルプロキシサーバのＩＰアドレスと、デュアルチャネルクライアントに割り当てられた仮想ポートとが含まれる）として偽装し、そして、ｉｐ、ｔｃｐまたはｕｄｐメッセージヘッダーのｃｈｅｃｋｓｕｍフィールドを再び計算して、Ｒａｗソケット（ＲａｗＳｏｃｋｅｔ）スレッドを介してアプリケーションサーバに送信する。

ステップ１００３で、デュアルチャネルプロキシサーバの下りスレッドは、ｒａｗＳｏｃｋｅｔ受信ＩＰメッセージを作成し、そして、ＶＩＰ情報モジュールに記録されているアプリケーションサーバのＩＰ情報により、ＩＰメッセージのソースアドレス（ｓｒｃＡｄｄｒ）に従って、ＩＰメッセージをフィルタリングすることにより、デュアルチャネルクライアントに送信する必要のあるＩＰメッセージを取得し、また、ＩＰメッセージにおける宛先ポート（ｄｓｔＰｏｒｔ）に従って、クライアント情報モジュールから当該リンクの情報を検出し、即ち、デュアルチャネルクライアントの実アドレス情報を検出し、そして、当該デュアルチャネルクライアントのイントラネットＩＰおよびイントラネットポートを、アプリケーションサービス下りＩＰメッセージ内に偽装して、ｉｐ、ｔｃｐ、あるいはｕｄｐメッセージヘッダーのｃｈｅｃｋｓｕｍフィールドを再び計算する。

本願の一実施例では、デュアルチャネルクライアントは、デュアルチャネルプロキシサーバに、データパケットが位置しているチャネルの情報をリアルタイムに送信することができ、これにより、プロキシサーバは、チャネルの切り替えを容易に行い、すなわち、４ＧまたはＷｉ－Ｆｉチャネルが異常に切り替えた場合、プロキシサーバは、クライアントに対応するチャネルの情報を直ちに更新できる、ということが保証されることができる。デュアルチャネルクライアントによって送信されたチャネル情報は、デュアルチャネルプロトコルヘッダーのｖｅｒおよびｔｙｐｅフィールドに維持されることができる。例えば、ｖｅｒ＝１は、メインチャネルを示し、ｖｅｒ＝０は、サブチャネルを示し、ｔｙｐｅ＝１は、４Ｇ通信を示し、ｔｙｐｅ＝０は、Ｗｉ－Ｆｉ通信を示す。

ステップＳ１００４で、デュアルチャネルプロキシサーバは、デュアルチャネルクライアントによって送信された最新の、Ｗｉ－Ｆｉおよび４Ｇチャネルの情報に基づいて、アプリケーションサービス下りＩＰメッセージの前に、デュアルチャネル下りパケットヘッダーおよびデュアルチャネルエンド内部プロトコルパケットヘッダーを付加してから、デュアルチャネル内でデュアルチャネルクライアントに送信する。デュアルチャネルプロキシサーバは、ｕｄｐプロトコルに基づいて、処理後のデータメッセージをデュアルチャネルクライアント送信することができる。

本願の一実施例では、図１１に示すように、デュアルチャネルプロキシサーバは、また、デュアルチャネルパケットヘッダーおよびデュアルチャネルエンド内部パケットヘッダーが付加されたアプリケーションサービスＩＰメッセージを、まず、デュアルチャネル負荷分散サーバに送信し、そして、デュアルチャネル負荷分散サーバによってデュアルチャネルエンド内部パケットヘッダーを除去してからデュアルチャネルクライアントに送信することができる。

本願の一実施例では、デュアルチャネルプロキシサーバは、定時的にデュアルチャネルクライアントのチャネル情報のクリーンアップを実行することができ（図６に示す定時タスクモジュールによってトリガーされることができる）、例えば、タイムアウト時間内に、デュアルチャネルプロキシサーバを経過するデュアルチャネルクライアントデータがない場合、このデュアルチャネルクライアントのスレッドおよびチャネル情報データをクリアする。

本願の実施例では、デュアルチャネルプロキシサーバは、デュアルチャネルクライアントとアプリケーションサーバとの間のＩＰメッセージ（デュアルチャネルクライアントのＩＰメッセージは、アプリケーションクライアントからのものである）に対して透過的な転送を実行することができるため、したがって、ｕｄｐプロトコルおよびｔｃｐプロトコルのフルスタックネットワークプロトコルのマルチチャネルデータ伝送をサポートすることができ、これにより、下記の問題が回避され、即ち、デュアルチャネルクライアントとアプリケーションサーバとの間のネットワークが悪いことによる、アプリケーションサーバと通信するｔｃｐリンクを適時に確立できなく、さらに、アプリケーションクライアントと通信するｔｃｐリンクの確立が失敗になり、ｔｃｐリンクが継続的に再接続されてしまい、ユーザ体験が悪くなってしまう。

本願の一実施例では、デュアルチャネル伝送プロセスにおいて、さらに、データチャネルのネットワーク状態を判断することにより、トラフィックをスマートに節約する伝送を実現することができ、具体的なプロセスは、次のとおりであり、即ち、
１、デュアルチャネルクライアントとデュアルチャネルプロキシサーバとは、クロック同期を行い、具体的なプロセスは、次のとおりであり、即ち、
１）デュアルチャネルクライアントは、デュアルチャネルプロキシサーバに、デュアルチャネルプロキシサーバのタイムスタンプ（例えば、毎回５００ｍｓ間隔で、１０回要求することができる）を要求するとともに、毎回のデュアルチャネルプロキシサーバの返信遅延を記録し、平均により、デュアルチャネルクライアントとデュアルチャネルプロキシサーバの平均遅延ａｖｇＤｅｌａｙを取得し、
２）デュアルチャネルクライアントは、最後の一回にデュアルチャネルプロキシサーバに要求したときに返信されたデュアルチャネルプロキシサーバタイムスタンプｓｖｒＴｉｍｅと、このときのデュアルチャネルクライアント時間ｌｏｃａｌＳｔａｒｔＴｉｍｅを記録し、
３）デュアルチャネルクライアントは、このときのサーバ時間ｓｖｒＳｔａｒｔＴｉｍｅ＝ｓｖｒＴｉｍｅ＋ａｖｇＤｅｌａｙ／２を計算し、
４）デュアルチャネルクライアントによって送信された各データパケットのいずれかに、現在のサーバ時間、即ちＣＳｔｉｍｅ＝ｃｕｒＴｉｍｅ－ｌｏｃａｌＳｔａｒｔＴｉｍｅ＋ｓｖｒＳｔａｒｔＴｉｍｅが付けられ、また、デュアルチャネルプロキシサーバによって送信された各下りパケットのいずれかに、デュアルチャネルプロキシサーバの現在タイムスタンプＳｔｉｍｅが付けられる。

２、Ｗｉ－Ｆｉおよび４Ｇチャネルを介してデータを伝送すると仮定すると、デュアルチャネルプロキシサーバは、上りパケットの遅延（デュアルチャネルプロキシサーバの現在時間－ＣＳｔｉｍｅ）に従って、現在のＷｉ－Ｆｉチャネルのフリーズレベルを判断し、これにより、４Ｇチャネルのパケット伝送ルールを策定し、例えば、Ｗｉ－Ｆｉチャネルのネットワーク状態が良い場合、ユーザの下りトラフィックを節約するように、４Ｇチャネルでパケットを伝送しないか、または非フル量のパケットを伝送してもよい。

本願の一実施例では、デュアルチャネルプロキシサーバは、デュアルチャネルクライアントからフィードバックされた下りパケットの遅延を受信し、そして、現在のＷｉ－Ｆｉチャネルのフリーズレベルを判断することができ、これにより、４Ｇチャネルのパケット伝送ルールを策定する。

３、デュアルチャネルクライアントは、下りパケットの遅延（デュアルチャネルクライアントの現在時間－Ｓｔｉｍｅ）に従って、現在のＷｉ－Ｆｉチャネルのフリーズレベルを判断し、これにより、４Ｇチャネルのパケット伝送ルールを策定し、例えば、Ｗｉ－Ｆｉチャネルのネットワーク状態が良い場合、ユーザの下りトラフィックを節約するように、４Ｇチャネルでパケットを伝送しないか、または非フル量のパケットを伝送してもよい。

本願の一実施例では、デュアルチャネルクライアントは、デュアルチャネルプロキシサーバからフィードバックされた上りパケットの遅延を受信し、そして、現在Ｗｉ－Ｆｉチャネルのフリーズレベルを判断し、これにより、４Ｇチャネルのパケット伝送ルールを策定することもできる。

本願の上記実施例の技術案は、Ｗｉ－Ｆｉチャネルと４Ｇチャネルを例として、デュアルチャネルのデータ伝送技術案について詳細に説明する。本願の他の実施例では、図１２に示すように、デュアルチャネルは、さらに、無線チャネルおよび有線チャネルであってもよく、無線チャネルは、Ｗｉ－Ｆｉチャネルであってもよく、有線チャネルは、ＯＴＧ（Ｏｎ－Ｔｈｅ－Ｇｏ）回線からネットワーク回線に変換接続することによりネットワークにアクセスするものであってもよい。または、図１３に示すように、デュアルチャネルは、無線チャネルとブルートゥース（登録商標）チャネルであってもよく、無線チャネルは、Ｗｉ－Ｆｉチャネルであってもよく、ブルートゥース（登録商標）チャネルは、ブルートゥース（登録商標）ネットワーク共有デバイスを介してネットワークにアクセスするものであってもよい。ここで、ブルートゥース（登録商標）ネットワーク共有デバイスは、特定用途の共有デバイスであってもよく、携帯電話のブルートゥース（登録商標）ネットワークのホットスポットまたはコンピュータのホットスポットであってもよい。無論、デュアルチャネルは、さらに、有線チャネルとブルートゥース（登録商標）チャネル、または有線チャネルと４Ｇチャネル、ブルートゥース（登録商標）チャネルと４Ｇチャネルなどであってもよい。

また、本願の他の実施例では、３つのチャネルまたはより多くのチャネルを介してデータ伝送を実現することもでき、ここで、これらのデータチャネルには、Ｗｉ－Ｆｉチャネル、ブルートゥース（登録商標）チャネル、有線チャネル、移動通信ネットワーク（例えば３Ｇ／４Ｇ／５Ｇなど）のデータチャネルなどが含まれてもよい。

本願の実施例のマルチチャネルデータ伝送技術案は、その実現がフレキシブルであり、ほとんどのサービスがゼロコストでアクセスすることができ、サービスがいかなる変更や適応を行う必要もなく、かつ、例えばゲームサービスなどの、すべてのタイプのサービスおよびアプリケーションがサポートされることができる。また、そのうちのあるデータチャネルにネットワーク故障が発生した場合、ユーザは、全く感知せず、かつ、クライアントネットワークのフリーズ状況の７０％以上が効果的に予防されることができ、特に、Ｗｉ－Ｆｉネットワークが複雑である場合、その効果がより顕著になる。トーナメントネットワークにおいて、ほとんどのＷｉ－Ｆｉ無線干渉状況が予防されることができ、ｔｃｐリンクおよびデュアルチャネルアクセラレーションの問題が完璧に解決された。

以下、本願の上記実施例におけるデータ伝送方法の実行に使用できる本願の装置の実施例について説明する。本願の装置の実施例に開示されていない詳細については、本願の上記のデータ伝送方法の実施例を参照してください。

図１４は、本願の一実施例によるデータ伝送装置を概略的に示すブロック図である。

図１４を参照すると、本願の一実施例によるデータ伝送装置１４００は、受信ユニット１４０２と、第１処理ユニット１４０４と、第２処理ユニット１４０６と、送信ユニット１４０８とを含む。

ここで、受信ユニット１４０２は、第１デバイスによって複数のデータチャネルを介して送信された第１データパケットを受信するために使用され、第１処理ユニット１４０４は、前記第１データパケットを解析して前記第１デバイスのアドレス情報を取得し、前記第１データパケットのデータパケットヘッダーに基づいて、前記第１データパケットに対して集約処理を実行して、第２データパケットを取得するために使用され、第２処理ユニット１４０６は、前記第２データパケットのソースアドレス情報を指定アドレス情報に変更して、第３データパケットを取得するために使用され、送信ユニット１４０８は、前記第３データパケットを第２デバイスに送信するために使用され、ここで、前記第２デバイスは、前記第１デバイスがアクセスする必要のあるデバイスである。

本願の一実施例では、データ伝送装置１４００は、さらに、前記第２デバイスによって送信されたデータパケットから、前記第１デバイスに送信する必要のある第４データパケットを決定するために使用される第１決定ユニットを含み、前記第２処理ユニット１４０６は、さらに、前記第４データパケットの宛先アドレス情報を前記第１デバイスのアドレス情報に変更して、第５データパケットを取得するために使用され、前記送信ユニット１４０８は、さらに、前記第５データパケットを前記第１デバイスに送信するために使用される。

本願の一実施例では、データ伝送装置１４００は、第１記憶ユニットをさらに含み、ここで、前記第１処理ユニット１４０４は、さらに、前記第１データパケットを解析して、前記第１デバイスがアクセスする必要のあるアドレス情報を取得し、前記第１デバイスがアクセスする必要のあるアドレス情報に基づいて、前記第２デバイスを決定するために使用され、前記第１記憶ユニットは、前記第１デバイスがアクセスする必要のあるアドレス情報を記憶するように構成される。

本願の一実施例では、前記第１決定ユニットは、前記第２デバイスによって送信されたデータパケットのソースアドレス情報を決定し、前記第１デバイスがアクセスする必要のあるアドレス情報に基づいて、前記第２デバイスによって送信されたデータパケットから、前記ソースアドレス情報と前記第１デバイスがアクセスする必要のあるアドレス情報とがマッチングしているデータパケットをフィルタリングし、フィルタリングされたデータパケットを前記第４データパケットとするように構成される。

本願の一実施例では、データ伝送装置１４００は、さらに、前記第１デバイスに仮想ポートを割り当てるために使用される割り当てユニットと、前記第１デバイスのアドレス情報を前記第１デバイスに割り当てられた仮想ポートと関連付けて記憶するために使用される第２記憶ユニットであって、ここで、前記指定アドレス情報には、前記第１デバイスに割り当てられた仮想ポートが含まれる第２記憶ユニットと、を含む。

本願の一実施例では、第２処理ユニット１４０６は、さらに、前記第４データパケットの宛先アドレス情報を、前記第１デバイスのアドレス情報に変更する前に、前記第４データパケットの宛先アドレス情報に含まれる仮想ポートの情報に基づいて、記憶されている前記第１デバイスのアドレス情報を取得するために使用される。

本願の一実施例では、受信ユニット１４０２は、さらに、前記第１デバイスによって送信された、前記第１データパケットを伝送するためのデータチャネルの情報を受信して記憶するために使用され、前記送信ユニット１４０８は、記憶されている最新のデータチャネル情報に基づいて、前記第５データパケットを前記第１デバイスに送信するように構成される。

本願の一実施例では、データ伝送装置１４００は、さらに、前記第１デバイスによって送信された第１データパケットに対する受信状況に基づいて、前記第１デバイスが第１データパケットを送信する際に採用したデータチャネルのネットワーク状態を決定するために使用される第２決定ユニットを含み、前記送信ユニット１４０８は、前記第１デバイスが第１データパケットを送信する際に採用したデータチャネルのネットワーク状態の優劣に基づいて、１つまたは複数のデータチャネルを選択して前記第５データパケットを前記第１デバイスに送信するように構成される。

本願の一実施例では、前記第２決定ユニットは、前記第１デバイスによって送信されたデータパケットを受信した第１時刻と、前記第１デバイスによって送信されたデータパケットに含まれる第２時刻とに基づいて、前記第１デバイスによって送信されたデータパケットの遅延を計算し、ここで、前記第２時刻は、前記第１デバイスがデータパケットを送信する時刻と、前記プロキシサーバと前記第１デバイスとの間のクロック同期補償値とに基づいて決定されたものであり、前記第１デバイスによって送信されたデータパケットの遅延に基づいて、前記第１デバイスがデータパケットを送信する際に採用したデータチャネルのネットワーク状態を決定するように構成される。

本願の一実施例では、データ伝送装置１４００は、さらに、前記第１デバイスがデータパケットを受信する際に採用したデータチャネルのネットワーク状態を決定するために、前記第１デバイスからフィードバックされた、前記第１デバイスに伝送されたデータパケットの受信状況を受信するために使用される第３決定ユニットを含み、前記送信ユニット１４０８は、前記第１デバイスがデータパケットを受信する際に採用したデータチャネルのネットワーク状態の優劣に基づいて、１つまたは複数のデータチャネルを選択して前記第５データパケットを前記第１デバイスに送信するように構成される。

本願の一実施例では、データ伝送装置１４００は、さらに、前記第１デバイスによって送信された第１データパケットに対する受信状況に基づいて、前記第１デバイスが第１データパケットを送信する際に採用したデータチャネルのネットワーク状態を決定するために使用される第４決定ユニットを含み、前記送信ユニット１４０８は、さらに、第１デバイスがネットワーク状態に基づいて、データパケットを再び送信する際に、採用されたデータチャネルを選択するように、前記第１デバイスが第１データパケットを送信する際に採用したデータチャネルのネットワーク状態を前記第１デバイスに送信するために使用される。

本願の一実施例では、データ伝送装置１４００は、さらに、前記第１デバイスによって送信された、ＴＣＰ接続を切断するためのデータメッセージを受信すると、所定の期間を経過した後、記憶されている、前記第１デバイスに関連する情報を削除し、および／または、前記第１デバイスとＴＣＰ接続を確立するプロセスにおいて、受信した、前記第１デバイスによって送信された１番目のＴＣＰデータメッセージがＴＣＰ接続を確立するためのデータメッセージではない場合、接続をリセットするためのデータメッセージを前記第１デバイスに送信し、および／または、前記第２デバイスによって送信されるデータメッセージのメッセージセグメントの最大長さを設定するために使用される第３処理ユニットを含む。

図１５は、本願の実施例を実現するための電子デバイスに適するコンピュータシステムの構造を示す概略図である。

説明すべきものとして、図１５に示す電子デバイスのコンピュータシステム１５００は、１つの例示にすぎず、本願の実施例の機能および使用範囲に対していかなる制限ももたらしてはならない。

図１５に示すように、コンピュータシステム１５００は、中央処理ユニット（ＣＰＵ：Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１５０１を含み、読み取り専用メモリ（ＲＯＭ：Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）１５０２に記憶されているプログラムまたは記憶部１５０８からランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１５０３にロードされたプログラムに従って、様々な適切な動作および処理を実行でき、例えば、上記実施例に記載の方法を実行する。ＲＡＭ１５０３には、システム操作に必要な様々なプログラムおよびデータも記憶されている。ＣＰＵ１５０１と、ＲＯＭ１５０２と、ＲＡＭ１５０３とは、バス１５０４を介して互いに接続される。入力／出力（Ｉ／Ｏ：Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）インターフェース１５０５も、バス１５０４に接続される。

キーボード、マウスなどを含む入力部１５０６、陰極線管（ＣＲＴ：Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）と、液晶ディスプレイ（ＬＣＤ：Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）などと、スピーカーなどとを含む出力部１５０７、ハードディスクなどを含む記憶部１５０８、およびローカルエリアネットワーク（ＬＡＮ：Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）カードと、モデムなどのネットワークインターフェースカードとを含む通信部１５０９などの部品は、Ｉ／Ｏインターフェース１５０５に接続される。通信部１５０９は、インターネットなどのネットワークを介して通信処理を実行する。ドライバ１５１０も、必要に応じてＩ／Ｏインターフェース１５０５に接続される。磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどの取り外し可能な媒体１５１１は、必要に応じてドライバ１５１０に取り付けられ、これにより、その媒体１５１１から読み取られたコンピュータプログラムは、必要に応じて記憶部１５０８にインストールされる。

特に、本願の実施例によれば、以下にフローチャートを参照して説明するプロセスは、コンピュータソフトウェアプログラムとして実現されることができる。例えば、本願の実施例は、コンピュータプログラム製品を含み、それは、コンピュータ読み取り可能な媒体に搭載されているコンピュータプログラムを含み、当該コンピュータプログラムは、フローチャートに示される方法を実行するためのプログラムコードを含む。このような実施例において、当該コンピュータプログラムは、通信部１５０９を介してネットワークからウンロードしてインストールされるか、および／または、取り外し可能な媒体１５１１からインストールされることができる。当該コンピュータプログラムは、中央処理ユニット（ＣＰＵ）１５０１によって実行されると、本願のシステムに限定されている各機能を実行する。

説明すべきもとして、本願の実施例に示すコンピュータ読み取り可能な媒体は、コンピュータ読み取り可能な信号媒体、またはコンピュータ読み取り可能な記憶媒体、あるいは上記両者の任意の組合せであってもよい。コンピュータ読み取り可能な記憶媒体は、例えば電気、磁気、光学、電磁気、赤外線、または半導体のシステム、装置またはデバイス、あるいは以上の任意の組合せであってもよいが、これらに限定されない。コンピュータ読み取り可能な記憶媒体のさらなる具体的な例は、１つまたは複数のワイヤを有する電気的接続、ポータブルコンピュータ磁気ディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能なプログラマブル読み取り専用メモリ（ＥＰＲＯＭ：Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ラッシュメモリ、光ファイバ、ポータブルコンパクト磁気ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、光記憶デバイス、磁気デバイス、または上記の任意の適切な組み合わせを含むが、これらに限定されない。本願において、コンピュータ読み取り可能な記憶媒体は、プログラムを含むかまたは記憶する任意の有形の媒体であってもよく、当該プログラムは、命令実行システム、装置またはデバイスによって使用されるか、またはそれらと組み合わせて実行されることができる。本願において、コンピュータ読み取り可能な信号媒体は、ベースバンド内でまたは搬送波の一部として伝搬されるデータ信号を含んでもよく、ここで、コンピュータ読み取り可能なプログラムコードが搭載されている。このような伝搬されるデータ信号は、複数の形式を採用することができ、電磁気信号、光信号あるいは上記の任意の適切な組み合わせを含むが、これらに限定されない。コンピュータ読み取り可能な信号媒体は、さらに、コンピュータ読み取り可能な記憶媒体以外の任意のコンピュータ読み取り可能な媒体であってもよく、当該コンピュータ読み取り可能な媒体は、命令実行システム、装置またはデバイスによって使用されるかまたはそれらと組み合わせて使用されるためのプログラムを、送信、伝搬または伝送することができる。コンピュータ読み取り可能な媒体に含まれるプログラムコードは、任意の適切な媒体で伝送されることができ、無線、有線など、または上記の任意の組合せを含むが、これらに限定されない。

図面におけるフローチャートおよびブロック図は、本願の各実施例によるシステム、方法およびコンピュータプログラム製品が実現可能なアーキテクチャ、機能および操作を図示した。この点で、フローチャートまたはブロック図における各ブロックは、１つのモジュール、プログラムセグメント、またはコードの一部を代表することができ、上記モジュール、プログラムセグメント、またはコードの一部は、所定のロジック機能を実現するための１つまたは複数の実行可能な命令を含む。一部の代替的なものとしての実現では、ブロックにマークされた機能は、図面にマークされた順序と異なる順序で発生してもよい、ということにも留意されたい。例えば、連続的に表示された２つのブロックは、基本的に並行で実行されてもよく、時には、逆の順序で実行されてもよいし、これは関連する機能に従って決定される。ブロック図またはフローチャートにおける各々のブロック、およびブロック図またはフローチャートにおけるブロックの組合せは、所定の機能や操作を実行するための特定用途のハードウェアに基づくシステムで実現されてもよく、または特定用途ハードウェアとコンピュータ命令との組み合わせで実現されてもよい、ということにも注意されたい。

本願に記述された実施例に係るユニットは、ソフトウェアの方式で実現されてもよく、ハードウェアの方式で実現されてもよいし、説明されたユニットは、プロセッサに設置されてもよい。ここで、これらのユニットの名称は、ある場合には、当該ユニット自体に対する限定を構成しない。

別の態様として、本願は、コンピュータ読み取り可能な媒体を提供し、当該コンピュータ読み取り可能な媒体は、上記の実施例に記載の電子デバイスに含まれるものであってもよく、当該電子デバイスに組み込まれず、単独で存在するものであってもよい。上記のコンピュータ読み取り可能な媒体には、１つまたは複数のプログラムが搭載されており、上記１つまたは複数のプログラムが当該電子デバイスによって実行される場合、当該電子デバイスに、上記の実施例に記載の方法を実施させる。

上記の詳細な説明に、動作を実行するためのデバイスのいくつかのモジュールまたはユニットを言及したが、このような区分は必須ではない、ということに留意されたい。実際に、本願の実施形態によれば、以上で説明した２つ以上のモジュールまたはユニットの特徴および機能は、１つのモジュールまたはユニットで具現化されてもよい。逆に、以上で説明した１つのモジュールまたはユニットの特徴および機能は、さらに、複数のモジュールまたはユニットによって具現化されるように区分されてもよい。

以上の実施形態の説明により、当業者であれば、本明細書に説明した例示的な実施形態は、ソフトウェアで実現されてもよいし、ソフトウェアと必要なハードウェアとを組み合わせる方式で実現されてもよい、ということを容易に理解できる。したがって、本願の実施形態による技術案は、ソフトウェア製品の形態で具現化され、当該ソフトウェア製品は、不揮発性記憶媒体（ＣＤ－ＲＯＭ、ＵＳＢ、移動ハードディスクなどであり得る）またはネットワークに記憶されてもよく、コンピューティングデバイス（パーソナルコンピュータ、サーバ、タッチ端末、またはネットワークデバイスなどであり得る）に本願の実施形態による方法を実行させるいくつかの命令を含む。

当業者は、明細書を検討し、本明細書に開示されている発明を実践した後、本願の他の実施方案を容易に想到することができる。本願は、本願のいかなる変形、用途または適応性変更を包含すること意図し、これらの変形、用途または適応性変更は、本願の一般的な原理に従い、かつ、本願に開示されていない本技術分野の周知の知識または慣用的な技術的手段を含む。

本願は、上記に説明され、図面に示された正確な構造に限定されず、その範囲から逸脱しない限り、様々な修正および変更をなされ得ることを理解すべきである。本願の範囲は、添付の特許請求の範囲のみによって限定される。

1400 データ伝送装置
1402 受信ユニット
1404 第１処理ユニット
1406 第２処理ユニット
1408 送信ユニット
1505 Ｉ／Ｏインターフェース
1506 入力部
1507 出力部
1508 記憶部
1509 通信部
1510 ドライバ
1511 取り外し可能な媒体

Claims (19)

1. サーバによって実行されるデータ伝送方法であって、
   第１デバイスによって複数のデータチャネルを介して送信された第１データパケットを受信するステップと、
   前記第１データパケットを解析して前記第１デバイスのアドレス情報を取得し、前記第１データパケットのデータパケットヘッダーに基づいて、前記第１データパケットに対して集約処理を実行して、第２データパケットを取得するステップと、
   前記第２データパケットのソースアドレス情報を指定アドレス情報に変更して、第３データパケットを取得するステップと、
   前記第３データパケットを第２デバイスに送信するステップであって、前記第２デバイスは、前記第１デバイスがアクセスする必要のあるデバイスであるステップと、
   前記第１デバイスが第１データパケットを送信する際に採用したデータチャネルのネットワーク状態を前記第１デバイスに送信することにより、前記第１デバイスが前記ネットワーク状態に基づいてデータパケットを再び送信する際に、採用したデータチャネルを選択するステップと、
   を含むことを特徴とするデータ伝送方法。
2. 前記第１デバイスによって複数のデータチャネルを介して送信された第１データパケットを受信した後、前記第１データパケットを解析して、前記第１デバイスがアクセスする必要のあるアドレス情報を取得し、前記第１デバイスがアクセスする必要のあるアドレス情報に基づいて、前記第２デバイスを決定するステップと、
   前記第１デバイスがアクセスする必要のあるアドレス情報を記憶するステップと、をさらに含む、
   ことを特徴とする請求項１に記載のデータ伝送方法。
3. 前記記憶されている、第１デバイスがアクセスする必要のあるアドレス情報に基づいて、前記第２デバイスによって送信されたデータパケットから、前記第１デバイスに送信する必要のある第４データパケットを決定するステップと、
   前記第４データパケットの宛先アドレス情報を前記第１デバイスのアドレス情報に変更して、第５データパケットを取得するステップと、
   前記第５データパケットを、１つまたは複数のデータチャネルを介して前記第１デバイスに送信するステップと、をさらに含む、
   ことを特徴とする請求項２に記載のデータ伝送方法。
4. 前記記憶されている、第１デバイスがアクセスする必要のあるアドレス情報に基づいて、前記第２デバイスによって送信されたデータパケットから、前記第１デバイスに送信する必要のある第４データパケットを決定するステップは、
   前記第２デバイスによって送信されたデータパケットのソースアドレス情報を決定するステップと、
   前記第１デバイスがアクセスする必要のあるアドレス情報に基づいて、前記第２デバイスによって送信されたデータパケットから、前記ソースアドレス情報と、前記第１デバイスがアクセスする必要のあるアドレス情報とがマッチングしているデータパケットをフィルタリングし、フィルタリングされたデータパケットを前記第４データパケットとするステップと、を含む、
   ことを特徴とする請求項３に記載のデータ伝送方法。
5. 前記第１デバイスによって送信された第１データパケットを受信した場合、前記データ伝送方法は、
   前記第１デバイスに仮想ポートを割り当てるステップと、
   前記第１デバイスのアドレス情報を、前記第１デバイスに割り当てられた仮想ポートと関連付けて記憶するステップであって、前記指定アドレス情報には、前記第１デバイスに割り当てられた仮想ポートが含まれるステップと、をさらに含む、
   ことを特徴とする請求項３に記載のデータ伝送方法。
6. 前記第４データパケットの宛先アドレス情報には、前記仮想ポートの情報が含まれ、前記第４データパケットの宛先アドレス情報を前記第１デバイスのアドレス情報に変更する前に、前記データ伝送方法は、
   前記第４データパケットの宛先アドレス情報に含まれる仮想ポートの情報に基づいて、記憶されている前記第１デバイスのアドレス情報を取得するステップ、をさらに含む、
   ことを特徴とする請求項５に記載のデータ伝送方法。
7. 前記第１デバイスによって送信された、前記第１データパケットを伝送するためのデータチャネルの情報を受信して記憶するステップ、をさらに含み、
   前記第５データパケットを、１つまたは複数のデータチャネルを介して前記第１デバイスに送信するステップは、記憶されている最新のデータチャネル情報に基づいて、前記第５データパケットを前記第１デバイスに送信するステップ、を含む、
   ことを特徴とする請求項３に記載のデータ伝送方法。
8. 前記第１デバイスによって送信された第１データパケットに対する受信状況に基づいて、前記第１デバイスが第１データパケットを送信する際に採用したデータチャネルのネットワーク状態を決定するステップ、をさらに含み、
   前記第５データパケットを、１つまたは複数のデータチャネルを介して前記第１デバイスに送信するステップは、前記第１デバイスが第１データパケットを送信する際に採用したデータチャネルのネットワーク状態に基づいて、１つまたは複数のデータチャネルを選択して前記第５データパケットを前記第１デバイスに送信するステップ、を含む、
   ことを特徴とする請求項３に記載のデータ伝送方法。
9. 前記第１デバイスによって送信された第１データパケットに対する受信状況に基づいて、前記第１デバイスが第１データパケットを送信する際に採用したデータチャネルのネットワーク状態を決定するステップは、
   前記第１デバイスによって送信された第１データパケットを受信した第１時刻と、前記第１デバイスによって送信された第１データパケットに含まれる第２時刻とに基づいて、前記第１デバイスによって送信された第１データパケットの遅延を計算するステップであって、前記第２時刻は、前記第１デバイスが第１データパケットを送信した時刻と、前記サーバと前記第１デバイスとの間のクロック同期補償値とに基づいて決定されたものであるステップと、
   前記第１デバイスによって送信された第１データパケットの遅延に基づいて、前記第１デバイスが第１データパケットを送信する際に採用したデータチャネルのネットワーク状態を決定するステップと、を含む、
   ことを特徴とする請求項８に記載のデータ伝送方法。
10. 前記第１デバイスからフィードバックされた、前記第１デバイスに伝送されたデータパケットに対する受信状況を受信することにより、前記第１デバイスがデータパケットを受信する際に採用したデータチャネルのネットワーク状態を決定するステップを、さらに含み、
    前記第５データパケットを、１つまたは複数のデータチャネルを介して前記第１デバイスに送信するステップは、前記第１デバイスがデータパケットを受信する際に採用したデータチャネルのネットワーク状態に基づいて、１つまたは複数のデータチャネルを選択して前記第５データパケットを前記第１デバイスに送信するステップ、を含む、
    ことを特徴とする請求項３に記載のデータ伝送方法。
11. 前記第１デバイスによって送信された第１データパケットに対する受信状況に基づいて、前記第１デバイスが第１データパケットを送信する際に採用したデータチャネルのネットワーク状態を決定するステップをさらに含む、
    ことを特徴とする請求項１に記載のデータ伝送方法。
12. 前記第１デバイスによって送信された、伝送制御プロトコルＴＣＰ接続を切断するためのデータメッセージを受信すると、所定の期間を経過した後、記憶されている、前記第１デバイスに関連する情報を削除するステップ、をさらに含む、
    ことを特徴とする請求項１～請求項１１のいずれか１項に記載のデータ伝送方法。
13. 前記第１デバイスとＴＣＰ接続を確立するプロセスにおいて、受信した、前記第１デバイスによって送信された１番目のＴＣＰデータメッセージが、ＴＣＰ接続を確立するためのデータメッセージではない場合、接続をリセットするためのデータメッセージを前記第１デバイスに送信するステップ、をさらに含む、
    ことを特徴とする請求項１～請求項１１のいずれか１項に記載のデータ伝送方法。
14. データ伝送装置であって、
    第１デバイスによって複数のデータチャネルを介して送信された第１データパケットを受信する受信ユニットと、
    前記第１データパケットを解析して前記第１デバイスのアドレス情報を取得し、前記第１データパケットのデータパケットヘッダーに基づいて、前記第１データパケットに対して集約処理を実行して、第２データパケットを取得する第１処理ユニットと、
    前記第２データパケットのソースアドレス情報を指定アドレス情報に変更して、第３データパケットを取得する第２処理ユニットと、
    前記第３データパケットを第２デバイスに送信する送信ユニットであって、前記第２デバイスは、前記第１デバイスがアクセスする必要のあるデバイスである送信ユニットと、
    を含み、
    前記送信ユニットは、前記第１デバイスがネットワーク状態に基づいてデータパケットを再び送信する際に、採用したデータチャネルを選択するように、前記第１デバイスが第１データパケットを送信する際に採用したデータチャネルの前記ネットワーク状態を前記第１デバイスに送信することを特徴とするデータ伝送装置。
15. 前記装置は、第１記憶ユニットをさらに含み、
    前記第１処理ユニットは、さらに、前記第１データパケットを解析して、前記第１デバイスがアクセスする必要のあるアドレス情報を取得し、前記第１デバイスがアクセスする必要のあるアドレス情報に基づいて、前記第２デバイスを決定するために使用され、
    第１記憶ユニットは、前記第１デバイスがアクセスする必要のあるアドレス情報を記憶するために使用される、
    ことを特徴とする請求項１４に記載の装置。
16. 前記装置は、前記記憶されている、第１デバイスがアクセスする必要のあるアドレス情報に基づいて、前記第２デバイスによって送信されたデータパケットから、前記第１デバイスに送信する必要のある第４データパケットを決定する第１決定ユニット、をさらに含み、
    前記第２処理ユニットは、さらに、前記第４データパケットの宛先アドレス情報を前記第１デバイスのアドレス情報に変更して、第５データパケットを取得するために使用され、
    前記送信ユニットは、さらに、前記第５データパケットを、１つまたは複数のデータチャネルを介して前記第１デバイスに送信するために使用される、
    ことを特徴とする請求項１５に記載の装置。
17. 前記第１決定ユニットは、前記第２デバイスによって送信されたデータパケットのソースアドレス情報を決定し、前記第１デバイスがアクセスする必要のあるアドレス情報に基づいて、前記第２デバイスによって送信されたデータパケットから、前記ソースアドレス情報と、前記第１デバイスがアクセスする必要のあるアドレス情報とがマッチングしているデータパケットをフィルタリングし、フィルタリングされたデータパケットを前記第４データパケットとするために使用される、
    ことを特徴とする請求項１６に記載の装置。
18. コンピュータプログラムが記憶されているコンピュータ読み取り可能な媒体であって、
    前記コンピュータプログラムは、プロセッサによって実行される場合、請求項１～請求項１３のいずれか１項に記載のデータ伝送方法を実現する、
    ことを特徴とするコンピュータ読み取り可能な媒体。
19. １つまたは複数のプロセッサと、
    １つまたは複数のプログラムを記憶する記憶装置と、を含み、
    前記１つまたは複数のプログラムが前記１つまたは複数のプロセッサによって実行される場合、前記１つまたは複数のプロセッサに、請求項１～請求項１３のいずれか１項に記載のデータ伝送方法を実現させる、
    ことを特徴とする電子デバイス。

Images