(57)【要約】  本発明の実施例は、マルチ・チャネル・データ伝送方法及び装置、並びにコンピュータ可読記憶媒体及び電子機器を提供する。前記マルチ・チャネル・データ伝送方法は、マルチ・チャネルを介して複数の上りリンク・データ・パケットを並列受信し；前記複数の上りリンク・データ・パケットを解析し、複数のターゲット・サービス・データ・パケット及び複数の上りリンク・パケット・ヘッダーを取得し；前記複数の上りリンク・パケット・ヘッダーに基づいて、前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行い；重複除去処理後に残されたターゲット・サービス・データ・パケットをターゲット・サービス・サーバに送信するステップを含む。各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含む。本発明の実施例における技術的手段により、マルチ・チャネルを介して上りリンク・データ・パケットを並列伝送することができ、また、重複除去処理を行うことで、ターゲット・サービス・データ・パケットの信頼性のある伝送を実現することができる。
2021521749.tif 000002
【特許請求の範囲】
【請求項１】
プロキシ・サーバに適用されるマルチ・チャネル・データ伝送方法であって、
前記プロキシ・サーバが、
マルチ・チャネルを介して複数の上りリンク・データ・パケットを並列受信するステップと、
前記複数の上りリンク・データ・パケットを解析し、複数のターゲット・サービス・データ・パケット及び複数の上りリンク・パケット・ヘッダーを取得するステップと、
前記複数の上りリンク・パケット・ヘッダーに基づいて、前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行うステップと、
重複除去処理後に残されるターゲット・サービス・データ・パケットをターゲット・サービス・サーバに送信するステップと、
を含み、
各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含む、方法。
【請求項２】
請求項1に記載の方法であって、
前記複数の上りリンク・パケット・ヘッダーに基づいて、前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行うステップは、
(MaxSeqno-curSeqno)＞recvThredである場合、対応するターゲット・サービス・データ・パケットをドロップし、(MaxSeqno-curSeqno)≦recvThredであり、且つcurSeqnoが未受信パケット集合に存在しない場合、対応するターゲット・サービス・データ・パケットをドロップするステップと、
curSeqno＞MaxSeqnoである場合、対応するターゲット・サービス・データ・パケットを残すステップと、
(MaxSeqno-curSeqno)≦recvThredであり、且つcurSeqnoが前記未受信パケット集合に存在する場合、対応するターゲット・サービス・データ・パケットを残すステップと、
を含み、
curSeqnoは、上りリンク・データ・パケットのパケット・シーケンス番号であり、MaxSeqnoは、クライアント最大受信パケット・シーケンス番号であり、recvThredは、第一閾値である、方法。
【請求項３】
請求項1に記載の方法であって、
前記複数の上りリンク・パケット・ヘッダーに基づいて、前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行うステップは、
上りリンク・データ・パケットのパケット・シーケンス番号がシーケンス番号キューにおけるパケット・シーケンス番号の何れとも異なる場合、該上りリンク・データ・パケットのパケット・シーケンス番号を前記シーケンス番号キューに追加し、対応するターゲット・サービス・データ・パケットを残すステップと、
上りリンク・データ・パケットのパケット・シーケンス番号が前記シーケンス番号キューにおけるパケット・シーケンス番号の何れか1つと同じである場合、対応するターゲット・サービス・データ・パケットをドロップするステップと、
を含む、方法。
【請求項４】
請求項1に記載の方法であって、
各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのチャネルＩＤ及びチャネル情報をさらに含み、
前記方法は、
前記プロキシ・サーバが、
チャネルＩＤに基づいて上りリンク・データ・パケットのチャネル・タイプを判断するステップと、
上りリンク・データ・パケットのパケット・シーケンス番号が、対応するチャネル・タイプのチャネル最大受信パケット・シーケンス番号よりも大きく、且つ対応するチャネル情報が、記憶されている対応するチャネル・タイプのチャネル情報と不一致である場合、対応するチャネル・タイプのチャネル情報を更新するステップと、
をさらに含む、方法。
【請求項５】
請求項4に記載の方法であって、
前記プロキシ・サーバが、
前記ターゲット・サービス・サーバが前記ターゲット・サービス・データ・パケットに応じて生成する応答データ・パケットを受信するステップと、
各チャネル・タイプの最新のチャネル情報に基づいて、それぞれ対応する下りリンク・パケット・ヘッダーを前記応答データ・パケットに付加してカプセル化を行い、複数の下りリンク・データ・パケットを生成するステップと、
前記複数の下りリンク・データ・パケットを、前記マルチ・チャネルを介してサービス・クライアントに並列送信するステップと、
をさらに含む、方法。
【請求項６】
サービス・クライアントに適用されるマルチ・チャネル・データ伝送方法であって、
前記サービス・クライアントが、
ターゲット・サービス・データ・パケットを取得するステップと、
前記ターゲット・サービス・データ・パケットに上りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化を行い、複数の上りリンク・データ・パケットを形成するステップと、
マルチ・チャネルを介して前記複数の上りリンク・データ・パケットをプロキシ・サーバに並列送信するステップと、
を含み、
各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含む、方法。
【請求項７】
請求項6に記載の方法であって、
前記サービス・クライアントが、
前記マルチ・チャネルを介して、前記ターゲット・サービス・データ・パケットに応じて生成される複数の下りリンク・データ・パケットを並列受信するステップと、
前記複数の下りリンク・データ・パケットを解析し、複数の応答データ・パケット及び複数の下りリンク・パケット・ヘッダーを取得するステップと、
前記複数の下りリンク・パケット・ヘッダーに基づいて、前記複数の応答データ・パケットに対して重複除去処理を行うステップと、
をさらに含む、方法。
【請求項８】
請求項6又は7に記載の方法であって、
前記ターゲット・サービス・データ・パケットを取得するステップは、
サービス・コンフィグレーションに基づいて制御サーバにリクエストし、ターゲット・サービス・サーバ情報を取得するステップと、
前記ターゲット・サービス・サーバ情報に基づいてフィルタリング・ポリシーを設定するステップと、
前記フィルタリング・ポリシーに基づいて前記ターゲット・サービス・データ・パケットのみを取得するステップと、
を含む、方法。
【請求項９】
マルチ・チャネル・データ伝送装置であって、
マルチ・チャネルを介して複数の上りリンク・データ・パケットを並列受信するための上りリンク・データ受信モジュールと、
前記複数の上りリンク・データ・パケットを解析し、複数のターゲット・サービス・データ・パケット及び複数の上りリンク・パケット・ヘッダーを取得するための上りリンク・データ解析モジュールと、
前記複数の上りリンク・パケット・ヘッダーに基づいて、前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行うための上りリンク・データ重複除去モジュールと、
重複除去処理後に残されるターゲット・サービス・データ・パケットをターゲット・サービス・サーバに転送する上りリンク・データ転送モジュールと、
を含み、
各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含む、装置。
【請求項１０】
マルチ・チャネル・データ伝送装置であって、
ターゲット・サービス・データ・パケットを取得するためのターゲット・データ取得モジュールと、
前記ターゲット・サービス・データ・パケットに上りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化を行い、複数の上りリンク・データ・パケットを形成するための上りリンク・パケット・ヘッダー・カプセル化モジュールと、
マルチ・チャネルを介して前記複数の上りリンク・データ・パケットをプロキシ・サーバに並列送信するための上りリンク・データ送信モジュールと、
を含み、
各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含む、装置。
【請求項１１】
マルチ・チャネル・データ伝送システムであって、
ターゲット・サービス・データ・パケットを取得し、前記ターゲット・サービス・データ・パケットに上りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化を行い、複数の上りリンク・データ・パケットを形成し送信するように構成されるサービス・クライアントと、
マルチ・チャネルを介して前記複数の上りリンク・データ・パケットを並列受信し、前記複数の上りリンク・データ・パケットを解析し、複数のターゲット・サービス・データ・パケット及び複数の上りリンク・パケット・ヘッダーを取得し、前記複数の上りリンク・パケット・ヘッダーに基づいて、前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行い、重複除去処理後に残されるターゲット・サービス・データ・パケットをターゲット・サービス・サーバに送信するように構成されるプロキシ・サーバと、
を含む、システム。
【請求項１２】
請求項11に記載のシステムであって、
前記プロキシ・サーバは、さらに、前記ターゲット・サービス・サーバが前記ターゲット・サービス・データ・パケットに応じて生成する応答データ・パケットを受信し、各チャネル・タイプの最新のチャネル情報に基づいて、それぞれ対応する下りリンク・パケット・ヘッダーを前記応答データ・パケットに付加してカプセル化を行い、複数の下りリンク・データ・パケットを生成し送信するように構成され、
前記サービス・クライアントは、さらに、前記マルチ・チャネルを介して前記複数の下りリンク・データ・パケットを並列受信し、前記複数の下りリンク・データ・パケットを解析し、複数の応答データ・パケット及び複数の下りリンク・パケット・ヘッダーを取得し、前記複数の下りリンク・パケット・ヘッダーに基づいて、前記複数の応答データ・パケットに対して重複除去処理を行うように構成される、システム。
【請求項１３】
請求項11又は12に記載のシステムであって、
前記マルチ・チャネルを介して前記複数の上りリンク・データ・パケットを並列受信し、上りリンク・パケット・ヘッダーに基づいて前記複数の上りリンク・データ・パケットのプロキシ・サーバを決定し、前記複数の上りリンク・データ・パケットを、前記マルチ・チャネルを介して前記プロキシ・サーバに並列送信するように構成されるロード・バランシング・サーバをさらに含む、システム。
【請求項１４】
コンピュータに、請求項1乃至5のうちの何れか1項に記載のマルチ・チャネル・データ伝送方法、又は、請求項6乃至8のうちの何れか1項に記載のマルチ・チャネル・データ伝送方法を実行させるためのプログラム。
【請求項１５】
電子機器であって、
1つ又は複数の処理器と、
1つ又は複数のコンピュータ・プログラムを記憶した記憶装置と、
を含み、
前記コンピュータ・プログラムは、前記処理器により実行されるときに、前記処理器に、請求項1乃至5のうちの何れか1項に記載のマルチ・チャネル・データ伝送方法、又は、請求項6乃至8のうちの何れか1項に記載のマルチ・チャネル・データ伝送方法を実行させる、電子機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、2018年08月15日に中国専利局に出願した、出願番号が2018109310957、発明の名称が「マルチ・チャネル・データ伝送方法及び装置」である中国特許出願に基づく優先権を主張するものであり、その全内容を参照によりここに援用する。
【０００２】
本発明は、コンピュータ技術分野に関し、特に、データ伝送技術に関する。
【背景技術】
【０００３】
今のところ、データの伝送が一般的にWiFi（Wireless  Fidelity、ワイヤレス・フィディリティー）チャネル又はセルラー・ネットワークにより実現され、前記セルラー・ネットワークは、GSM（Global  System  for  Mobile  Communication、グローバル移動通信システム）ネットワーク、CDMA（Code  Division  Multiple  Access、コード分割多元接続）ネットワーク、FDMA（frequency  division  multiple  access、周波数分割多元接続）ネットワーク、TDMA（time  division  multiple  access、時間分割多元接続）ネットワーク、及び3G／4G／5Gチャネルを含んでも良い。3GPP（3rd  Generation  Partnership  Project、第三世代パートナーシップ・プロジェクト）の目標は、2Gネットワークから3G／4G／5Gネットワークへのスムーズな移行を実現し、将来のテクノロジーの下位互換性を確保し、簡単なネットワーク構築並びにシステム間のローミング及び互換性をサポートすることにある。ここで、WiFiチャネルを介したデータ送信にはレイテンシが低いという利点があるが、WiFiチャネルは不安定であり、チャネル干渉、帯域内干渉、信号強度低下などの現象が発生しやすい。そのため、端末からWiFiホット・スポットまでの間のレイテンシが増加したり、パケット紛失が発生したりすることがある。また、セルラー・ネットワーク（例えば、4G）は相対的に安定であるが、レイテンシがWiFiよりも高い。
【０００４】
即ち、関連技術では、端末がどのようなネットワークを選択してデータを伝送するかにもかかわらず、ユーザー・エクスペリエンスに影響を与える可能性があり、特に、ゲーム・データを伝送するときに、このような影響はより明らかである。これは、リアル・タイムのモバイル・ゲームなどの類似したアプリケーションがすべてクライアント側とサービング側との間の頻繁な通信に直面し、且つ高周波数の小さなパケットを主とし、このようなアプリケーションのネットワーク環境への要求がかなり高く、低レイテンシや高安定性の特徴がこのようなアプリケーションの強いニーズになるからである。これと同時に、WiFi自体のCSMA／CA（Carrier  Sense  multiple  Access／Collision  Avoidance、即ち、キャリア・センス多元接続／衝突回避）メカニズム・原理が原因で、チャネルの競合、無線WiFiチャネルのオーバーラップ、帯域内干渉、信号の違いなどによって、サービス（業務）パケットの紛失又はレイテンシの増加を引き起こすことが存在する。
【０００５】
関連技術では、ゲーム・データの伝送効果を改善するために、WiFi及び4Gチャネル優先をサポートする単一チャネル・パケット送信スキームがあり、即ち、WiFi信号が悪くなる場合、4Gチャネルを使用してパケットを送信する。しかしながら、このような単一チャネル・パケット送信スキームは、少なくとも、以下のような欠点が存在する。
【０００６】
第1に、WiFiネットワークの調子が悪くなっている場合のみ、4Gチャネル伝送への切り替え操作を開始し、これは、事後対処に属し、このときには、ユーザー・エクスペリエンスが損なわれている。
【０００７】
第2に、ネットワーク環境の切り替えなどの操作に起因するゲーム・クライアントのネットワーク切り替えにユーザーが順応することが困難であるため、ユーザーに深刻な途切れ（頻繁な途切れ）体験をもたらす可能性がある。
【０００８】
第3に、ネットワークにジッターがあるときに、データをネットワークの悪いルートから良いルートにのみ切り替えることができ、例えば、WiFi信号が悪くなるときに4Gチャネルを用いて一部のデータ・パケットを送信することができるが、WiFi又は4Gネットワークにジッターがあるときに、データ・パケット紛失及び高レイテンシを回避することができない。
【０００９】
まとめると、今のところ、安定したデータ伝送を保証するために新しいデータ伝送方法が要されることが分かる。
【００１０】
なお、上述の背景技術の部分に開示される情報は、本発明の背景への理解を深めるためにのみ使用されるので、当業者に知られている従来技術を構成しない情報を含み得る。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
本発明の目的は、従来のデータ伝送プロセスに存在するネットワーク接続途切れ、パケット紛失、高レイテンシなどの問題を未然に防止するために、マルチ・チャネル・データ伝送方法及び装置、並びにコンピュータ可読記憶媒体及び電子機器を提供することにある。
【００１２】
本発明の他の特徴及び利点は、以下の詳細な説明から明らかになり、或いは、本発明の実施により部分的に取得され得る。
【課題を解決するための手段】
【００１３】
本発明の一側面によれば、プロキシ・サーバに適用されるマルチ・チャネル・データ伝送方法が提供され、該方法は、マルチ・チャネルを介して複数の上りリンク・データ・パケットを並列受信し；前記複数の上りリンク・データ・パケットを解析し、複数のターゲット・サービス・データ・パケット及び複数の上りリンク・パケット・ヘッダーを取得し；前記複数の上りリンク・パケット・ヘッダーに基づいて、前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行い；及び、重複除去後に残されるターゲット・サービス・データ・パケットをターゲット・サービス・サーバに送信するステップを含み、ここで、各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含む。
【００１４】
本発明の1つの例示的な実施例において、前記複数の上りリンク・パケット・ヘッダーに基づいて、前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行うステップは、(MaxSeqno-curSeqno)＞recvThredである場合、対応するターゲット・サービス・データ・パケットをドロップし；(MaxSeqno-curSeqno)≦recvThredであり、且つcurSeqnoが未受信パケット集合にない場合、対応するターゲット・サービス・データ・パケットをドロップし；curSeqno＞MaxSeqnoである場合、対応するサービス・データ・パケットを残し；(MaxSeqno-curSeqno)≦recvThredであり、且つcurSeqnoが前記未受信パケット集合にある場合、対応するターゲット・サービス・データ・パケットを残すステップを含み、ここで、curSeqnoは、上りリンク・データ・パケットのパケット・シーケンス番号であり、MaxSeqnoは、クライアント最大受信パケット・シーケンス番号であり、recvThredは、第一閾値である。
【００１５】
本発明の1つの例示的な実施例において、前記複数の上りリンク・パケット・ヘッダーに基づいて、前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行うステップは、上りリンク・データ・パケットのパケット・シーケンス番号がシーケンス番号キューにおけるパケット・シーケンス番号の何れとも異なる場合、上りリンク・データ・パケットのパケット・シーケンス番号を前記シーケンス番号キューに追加し、また、対応するターゲット・サービス・データ・パケットを残し；及び、上りリンク・データ・パケットのパケット・シーケンス番号が前記シーケンス番号キューにおけるパケット・シーケンス番号の何れか1つと同じである場合、対応するターゲット・サービス・データ・パケットをドロップするステップを含む。
【００１６】
本発明の1つの例示的な実施例において、各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのチャネルＩＤ及びチャネル情報をさらに含む。前記方法は、チャネルＩＤに基づいて上りリンク・データ・パケットのチャネル・タイプを判断し；上りリンク・データ・パケットのパケット・シーケンス番号が、対応するチャネル・タイプのチャネル最大受信パケット・シーケンス番号よりも大きく、且つ対応するチャネル情報が、対応するチャネル・タイプに格納されるチャネル情報と不一致である場合、対応するチャネル・タイプのチャネル情報を更新するステップをさらに含む。
【００１７】
本発明の1つの例示的な実施例において、前記方法は、前記ターゲット・サービス・サーバが前記ターゲット・サービス・データ・パケットに応じて生成した応答データ・パケットを受信し；各チャネル・タイプの最新のチャネル情報に基づいて、前記応答データ・パケットにその対応する下りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化（encapsulation）を行い、複数の下りリンク・データ・パケットを生成し；及び、前記複数の下りリンク・データ・パケットを、前記マルチ・チャネルを介してサービス・クライアントに並列送信するステップをさらに含む。
【００１８】
本発明の一側面によれば、サービス・クライアントに適用されるマルチ・チャネル・データ伝送方法が提供され、該方法は、ターゲット・サービス・データ・パケットを取得し；前記ターゲット・サービス・データ・パケットに上りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化を行い、複数の上りリンク・データ・パケットを形成し；及び、マルチ・チャネルを介して前記複数の上りリンク・データ・パケットをプロキシ・サーバに並列送信するステップを含み、ここで、各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含む。
【００１９】
本発明の1つの例示的な実施例において、前記方法は、前記マルチ・チャネルを介して、前記ターゲット・サービス・データ・パケットに応じて生成された複数の下りリンク・データ・パケットを並列受信し；前記複数の下りリンク・データ・パケットを解析し、複数の応答データ・パケット及び複数の下りリンク・パケット・ヘッダーを取得し；及び、前記複数の下りリンク・パケット・ヘッダーに基づいて、前記複数の応答データ・パケットに対して重複除去処理を行うステップをさらに含む。
【００２０】
本発明の1つの例示的な実施例において、前記ターゲット・サービス・データ・パケットを取得するステップは、サービス・コンフィグレーション（configuration）に基づいて制御サーバにリクエストし、ターゲット・サービス・サーバ情報を取得し；前記ターゲット・サービス・サーバ情報に基づいてフィルタリング・ポリシーを設定し；及び、前記フィルタリング・ポリシーに基づいて、前記ターゲット・サービス・データ・パケットのみを取得するステップを含む。
【００２１】
本発明の一側面によれば、マルチ・チャネル・データ伝送装置が提供され、該装置は、マルチ・チャネルを介して複数の上りリンク・データ・パケットを並列受信するように構成される上りリンク・データ受信モジュール；前記複数の上りリンク・データ・パケットを解析し、複数のターゲット・サービス・データ・パケット及び複数の上りリンク・パケット・ヘッダーを取得するように構成される上りリンク・データ解析モジュール；前記複数の上りリンク・パケット・ヘッダーに基づいて前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行うように構成される上りリンク・データ重複除去モジュール；及び、重複除去後に残されたターゲット・サービス・データ・パケットをターゲット・サービス・サーバに送信するように構成される上りリンク・データ転送モジュールを含み、ここで、各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含む。
【００２２】
本発明の一側面によれば、マルチ・チャネル・データ伝送装置が提供され、該装置は、ターゲット・サービス・データ・パケットを取得するように構成されるターゲット・データ取得モジュール；前記ターゲット・サービス・データ・パケットに上りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化を行い、複数の上りリンク・データ・パケットを形成するように構成される上りリンク・パケット・ヘッダー・カプセル化モジュール；及び、マルチ・チャネルを介して前記複数の上りリンク・データ・パケットをプロキシ・サーバに並列送信するように構成される上りリンク・データ送信モジュールを含み、ここで、各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含む。
【００２３】
本発明の一側面によれば、マルチ・チャネル・データ伝送システムが提供され、該システムは、ターゲット・サービス・データ・パケットを取得し、前記ターゲット・サービス・データ・パケットに上りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化を行い、複数の上りリンク・データ・パケットを形成し送信するように構成されるサービス・クライアント；及び、マルチ・チャネルを介して前記複数の上りリンク・データ・パケットを並列受信し、前記複数の上りリンク・データ・パケットを解析し、複数のターゲット・サービス・データ・パケット及び複数の上りリンク・パケット・ヘッダーを取得し、前記複数の上りリンク・パケット・ヘッダーに基づいて前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行い、重複除去後に残されたターゲット・サービス・データ・パケットをターゲット・サービス・サーバに送信するように構成されるプロキシ・サーバを含む。
【００２４】
本発明の1つの例示的な実施例において、前記プロキシ・サーバは、さらに、前記ターゲット・サービス・サーバが前記ターゲット・サービス・データ・パケットに応じて生成した応答データ・パケットを受信し、各チャネル・タイプの最新のチャネル情報に基づいて前記応答データ・パケットにその対応する下りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化を行い、複数の下りリンク・データ・パケットを生成し送信するように構成され；前記サービス・クライアントは、さらに、前記マルチ・チャネルを介して前記複数の下りリンク・データ・パケットを並列受信し、前記複数の下りリンク・データ・パケットを解析し、複数の応答データ・パケット及び複数の下りリンク・パケット・ヘッダーを取得し、前記複数の下りリンク・パケット・ヘッダーに基づいて前記複数の応答データ・パケットに対して重複除去処理を行うように構成される。
【００２５】
本発明の1つの例示的な実施例において、前記システムは、前記マルチ・チャネルを介して前記複数の上りリンク・データ・パケットを並列受信し、上りリンク・パケット・ヘッダーに基づいて前記複数の上りリンク・データ・パケットのプロキシ・サーバを決定し、前記複数の上りリンク・データ・パケットを、前記マルチ・チャネルを介して前記プロキシ・サーバに並列送信するように構成されるロード・バランシング・サーバ（load  balancing  server）をさらに含む。
【００２６】
本発明の一側面によれば、コンピュータ・プログラムを記憶しているコンピュータ可読記憶媒体が提供され、前記プログラムは、処理器により実行されるときに、処理器に、上述のような実施例に記載の方法を実現させる。
【００２７】
本発明の一側面によれば、電子機器が提供され、それは、1つ又は複数の処理器；及び、1つ又は複数のコンピュータ・プログラムを記憶している記憶装置を含み、前記1つ又は複数のコンピュータ・プログラムは、前記1つ又は複数の処理器により実行されるときに、前記1つ又は複数の処理器に、上述のような実施例に記載の方法を実現させる。
【００２８】
本発明の幾つかの実施例により提供される技術的手段によれば、マルチ・チャネルを介して複数の上りリンク・データ・パケットを並列受信し、そして、複数の上りリンク・データ・パケットを解析することで、複数のターゲット・サービス・データ・パケット及び複数の上りリンク・パケット・ヘッダーを取得し、それから、複数の上りリンク・パケット・ヘッダーに基づいて複数のターゲット・サービス・データ・パケットに対して重複除去処理を行い、その後、重複除去後に残されたターゲット・サービス・データ・パケットをターゲット・サービス・サーバに送信し、ここで、各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含む。これにより、一方では、マルチ・チャネルを介してパケットを同時に受信することで、ターゲット・サービス・データ・パケットの伝送安定性及び有効性を確保することができ、他方では、並列受信した上りリンク・データ・パケットをアグリゲート（aggregate）して重複除去処理した後にターゲット・サービス・サーバに転送することで、ターゲット・サービス・サーバに対してネットワークの変化をシールド（遮断）し、ターゲット・サービス・サーバが異なるネットワーク環境の変化に気づかないように保証することができ、そのため、ターゲット・サービス・サーバの動作に影響を与えることがない。
【００２９】
理解すべきは、上記の一般的な説明及び以下の詳細な説明は、本発明を例示及び解釈するためのものに過ぎず、本発明を限定するためのものでないということである。
【図面の簡単な説明】
【００３０】
ここでの図面は、本明細書に組み込まれて本明細書の一部を構成し、本発明の実施例を示し、また本明細書とともに本発明の原理を解釈するために用いられる。明らかのように、これらの図面は、本発明の幾つかの実施例を示すためのものに過ぎず、当業者は、創造性のある労働をせずに、これらの図面に基づいて他の図面を得ることもできる。
【図１】本発明の実施例におけるマルチ・チャネル・データ伝送方法又はマルチ・チャネル・データ伝送装置を適用し得る例示的なシステム・アーキテクチャを示す図である。
【図２】本発明の実施例における電子機器に適用され得るコンピュータ・システムの構成を示す図である。
【図３】本発明の一実施例におけるマルチ・チャネル・データ伝送方法のフローチャートである。
【図４】本発明の他の実施例におけるマルチ・チャネル・データ伝送方法のフローチャートである。
【図５】本発明の一実施例におけるマルチ・チャネル・データ伝送システムを示す図である。
【図６】本発明の他の実施例におけるマルチ・チャネル・データ伝送システムを示す図である。
【図７】本発明の一実施例におけるマルチ・チャネル・データ伝送方法の全体フローを示す図である。
【図８】本発明の一実施例におけるクライアントAPPがマルチ・チャネルを介して上りリンク・データ・パケットを送信することを示す図である。
【図９】本発明の一実施例におけるクライアントAPPがマルチ・チャネルを介して下りリンク・データ・パケットを受信することを示す図である。
【図１０】本発明の一実施例におけるデータ・パケット重複除去方法のフローチャートである。
【図１１】図10に示すデータ・パケット重複除去方法による一例を示す図である。
【図１２】本発明の他の実施例におけるデータ・パケット重複除去方法のフローチャートである。
【図１３】本発明の一実施例におけるロード・バランシング・サーバを示す図である。
【図１４】本発明の一実施例におけるロード・バランシング・サーバとプロキシ・サーバとの内部インタラクションのロジカル・シーケンス図である
【図１５】本発明の一実施例におけるロード・バランシング・サーバのプロキシ・サービス・マッピング・モジュールを示す図である。
【図１６】本発明の他の実施例におけるロード・バランシング・サーバのプロキシ・サービス・マッピング・モジュールを示す図である。
【図１７】本発明の他の実施例におけるロード・バランシング・サーバのプロキシ・サービス・マッピング・モジュールを示す図である。
【図１８】本発明の他の実施例におけるロード・バランシング・サーバのプロキシ・サービス・マッピング・モジュールを示す図である。
【図１９】本発明の一実施例におけるプロキシ・サーバのロジカル・シーケンス図である。
【図２０】本発明の一実施例におけるプロキシ・サーバがマルチ・チャネルを介して下りリンク・データ・パケットを送信することを示す図である。
【図２１】本発明の一実施例におけるマルチ・チャネル・データ伝送装置を示すブロック図である
【図２２】本発明の他の実施例におけるマルチ・チャネル・データ伝送装置を示すブロック図である。
【発明を実施するための形態】
【００３１】
以下、図面を参照しながら例示的な実施形態を詳細に説明する。なお、以下の例示的な実施形態は、複数の形で実施することができ、また、ここで説明される範例に限定されると理解してはならない。逆に、これらの実施形態を提供することにより、本発明をより完全にし、また、例示的な実施形態の技術思想をより良く当業者に伝えることができる。
【００３２】
また、説明される特徴、構造又は特性は、任意の適切な方式で1つ又は複数の実施例に組み合わせることができる。以下の説明では、本発明の実施例を十分に理解するために、多くの具体的な細部が提供される。しかしながら、当業者が理解すべきは、このような細部のうちの1つ又は複数がなくても、或いは、他の方法、構成要素、装置、ステップなどを採用することによっても、本発明の技術的手段を実施することができるということである。また、本発明の様々な態様を不明瞭にしないようにするために、周知の方法、装置、実装又は動作を詳細に示さない又は説明しない場合もある。
【００３３】
図面に示されるブロック図は、単なる機能エンティティ（実体）であり、必ずしも物理的に独立したエンティティに対応しているわけでない。つまり、これらの機能エンティティは、ソフトウェアの形で実現し、1つ又は複数のハードウェア・モジュール又は集積回路で実現し、或いは、異なるネットワークやプロセッサ・デバイス、マイクロ・コントローラ・デバイスで実現することができる。
【００３４】
また、図面に示されるフローチャートは、例示的な説明に過ぎず、必ずしも全ての内容及び操作／ステップを含むわけでなく、説明された順序で実行される必要もない。例えば、幾つかの操作／ステップを分解したり、幾つかの操作／ステップを全部又は部分的に組み合わせたりすることができる。よって、実際の実行順序は、実際の状況に応じて変更される場合がある。
【００３５】
図1は、本発明の実施例におけるマルチ・チャネル・データ伝送方法又はマルチ・チャネル・データ伝送装置を適用し得る例示的なシステム・アーキテクチャ100を示す図である。
【００３６】
図1に示すように、システム・アーキテクチャ100は、端末装置101、102、103のうちの何れか1つ又は複数、ネットワーク104、及びサーバ105を含んでも良い。ネットワーク104は、端末装置101、102、103と、サーバ105との間で通信リンクの媒体を提供するために用いられる。ネットワーク104は、様々な接続類型、例えば、有線、無線通信リンク、光ファイバー・ケーブルなどを含んでも良い。
【００３７】
理解すべきは、図1における端末装置、ネットワーク及びサーバの数は例示に過ぎないということである。実現のニーズに応じて、任意の数の端末装置、ネットワーク及びサーバを有して良い。例えば、サーバ105は、複数のサーバからなるサーバ群などであっても良い。
【００３８】
ユーザーは、端末装置101、102、103を用いてネットワーク104を介してサーバ105とインタラクションを行うことで、メッセージなどを受信又は送信することができる。端末装置101、102、103は、データ伝送機能を有する各種の電子機器、例えば、スマート・フォン、タブレット・コンピュータ、ポータブル・コンピュータ、デスクトップ・コンピュータ、スマート・チャット（チャット・ボット）などを含んでも良いが、これらに限定されない。
【００３９】
サーバ105は、関連サービスを提供するサーバである。例えば、ユーザーは、端末装置103（端末装置101又は102であっても良い）を利用してサーバ105に、ゲームに関する情報及び／又はリソースを得るためのリクエストを送信する。サーバ105は、その受信した、ゲームに関する情報及び／又はリソースのリクエスト情報に基づいて、対応して、ゲームに関する情報及び／又はリソースを取得し、そして、ゲームに関する情報及び／又はリソースを端末装置103にフィードバックすることができる。これにより、端末装置103は、その受信した、ゲームに関する情報及び／又はリソースを表示することができる。また、ユーザーは、端末装置103に表示されているゲームに関する情報及び／又はリソースに基づいて、端末装置103（端末装置101又は102であっても良い）を利用してサーバ105にゲーム操作指令を送信する。サーバ10は、その受信したゲーム操作指令に基づいて、対応して、端末装置103に該ゲーム操作指令の実行結果を返すことができる。これにより、端末装置103は、対応して、その受信したゲーム操作指令の実行結果を表示することができる。
【００４０】
図2は、本発明の実施例を実現するために適した電子機器の構造を示す図である。
【００４１】
なお、図2に示す電子機器のコンピュータ・システム200は、一例にすぎず、本発明の実施例の機能や使用範囲を限定するものではない。
【００４２】
図2に示すように、コンピュータ・システム200は、中央処理装置（CPU）201を含み、それは、リード・オンリー・メモリ（ROM）202に記憶されるプログラム、又は記憶部208からランダム・アクセス・メモリ（RAM）203にロードされるプログラムに基づいて、各種の適切な動作及び処理を実行することができる。RAM  203には、システムの動作に必要な各種のプログラム及びデータがさらに記憶される。CPU  201、ROM  202及びRAM  203は、バス204を介して相互に接続される。入力／出力（I／O）インターフェース205も、バス204に接続される。
【００４３】
次のよう部品がI／Oインターフェース205に接続され、即ち、キーボード、マウスなどを含む入力部206、ブラウン管（CRT）、液晶ディスプレイ（LCD）など及びスピーカなどを含む出力部207、ハード・ディスクなどを含む記憶部208、及びLANカード、モデムなどのネットワーク・インターフェース・カードを含む通信部209である。通信部209は、例えば、インターネットなどのネットワークを介して通信処理を実行する。ドライブ210も、必要に応じてI／Oインターフェース205に接続される。リムーバブル・メディア211、例えば、磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどが、必要に応じてドライブ210に装着され、これにより、その中から読み出されたコンピュータ・プログラムは、ニーズに応じて記憶部208にインストールすることができる。
【００４４】
特に、本発明の実施例によれば、以下にフローチャートを参照して説明されるプロセスがコンピュータ・ソフトウェア・プログラムとして実現され得る。例えば、本発明の実施例は、コンピュータ・プログラム・プロダクトを含み、それは、コンピュータ可読記憶媒体にキャリー（Carry）されるコンピュータ・プログラムを含み、前記コンピュータ・プログラムは、フローチャートに示す方法を実行するためのプログラム・コードを含む。このような実施例では、前記コンピュータ・プログラムは、通信部209を介してネットワークからダウンロード及びインストールすることができ、及び／又は、リムーバブル・メディア211からインストールすることができる。前記コンピュータ・プログラムは、中央処理装置（CPU）201により実行されるときに、本発明による方法及び／又は装置における各種の機能を実行することができる。
【００４５】
なお、本発明に示すコンピュータ可読記憶媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体又は両者の任意の組み合わせであっても良い。コンピュータ可読記憶媒体は、例えば、電気、磁気、光、電磁気、赤外線又は半導体のシステム、装置又は部品、或いはその任意の組み合わせであっても良いが、これらに限られない。コンピュータ可読記憶媒体のより具体的な例は、1つ又は複数の導線を有する電気的な接続、ポータブル・コンピュータ・ディスク、ハード・ディスク、ランダム・アクセス・メモリ（RAM）、リード・オンリー・メモリ（ROM）、消去可能なプログラマブル・リード・オンリー・メモリ（EPROM又はフラッシュ・メモリ）、光ファイバー、ポータブル・コンパクト・ディスクリード・オンリー・メモリ（CD-ROM）、光学記憶装置、磁気記憶装置、又はその任意の適切な組み合わせを含んでも良いが、これらに限定されない。本発明では、コンピュータ可読記憶媒体は、プログラムを含む又は記憶する任意の有形記憶媒体であっても良く、前記プログラムは、指令実行システム、装置又はデバイスに使用されても良く、或いは、それと組み合わせて使用されても良い。また、本発明では、コンピュータ可読信号媒体は、ベース・バンドにおいて又はキャリア（Carrier）の一部として伝播するデータ信号を含んでも良く、その中には、コンピュータ可読プログラム・コードがキャリー（Carry）される。このように伝播するデータ信号は、複数の形、例えば、電磁信号、光信号又はその任意の適切な組み合わせを採用しても良い。コンピュータ可読信号媒体は、さらに、コンピュータ可読記憶媒体以外の任意のコンピュータ可読媒体であっても良く、前記コンピュータ可読媒体は、指令実行システム、装置又はデバイスにより使用され又はそれと組み合わせて使用されるプログラムに対して送信、伝播又は伝送を行うことができる。コンピュータ可読媒体に含まれるプログラム・コードは、任意の適切な媒体、例えば、無線、ワイヤー、光ケーブル、RFなど又はその任意の適切な組み合わせにより伝送されても良いが、これらに限られない。
【００４６】
図面におけるフローチャート及びブロック図は、本発明の各種の実施例による方法、装置及びコンピュータ・プログラム・プロダクトの実現可能なシステム・アーキテクチャ、機能及び動作を示す。この点に関して、フローチャート又はブロック図における各ブロックは、1つのモジュール、プログラム・セグメント、又はコードの一部を表しても良く、これらのモジュール、プログラム・セグメント、又はコードの一部は、所定の論理機能を実現するための1つ又は複数の実行可能な指令を含む。なお、幾つかの代替実現では、ブロックで示される機能は、図面で示される順序とは異なる順序で発生することがある。例えば、接続されるように示される2つのブロックは、実際には、実質的に並列に実行し、また、逆の順序で実行する場合があり、これは、関連する機能に依存する。また、ブロック図又はフローチャートにおける各ブロック、及びブロック図又はフローチャートにおけるブロックの組み合わせは、所定の機能又は動作を実行する専用のハードウェア・ベースのシステムにより実現されても良く、又は、専用ハードウェアとコンピュータ指令との組み合わせにより実現されても良い。
【００４７】
本発明の実施例において説明されるモジュール及び／又はユニットは、ソフトウェアの方式で実現されても良く、ハードウェアの方式で実現されても良い。また、説明されるモジュール及び／又はユニットは、処理器に設けることもできる。なお、これらのモジュール及び／又はユニットの名前は、前記モジュール及び／又はユニット自体を制限するものでない。
【００４８】
他の側面によれば、本発明は、さらに、コンピュータ可読記憶媒体を提供し、このようなコンピュータ可読記憶媒体は、上述の実施例に述べた電子機器に含まれるものであっても良く、電子機器に組み込まれることなく単独で存在するものであっても良い。上述のコンピュータ可読記憶媒体に1つ又は複数のプログラムがキャリー（Carry）され、該1つ又は複数のプログラムは、前記電子機器により実行されるときに、前記電子機器に、以下の実施例に記載される方法を実現させることができる。例えば、前記電子機器は、図3乃至図20に係る実施例の何れか1つに示す各ステップを実現することができる。
【００４９】
図3は、本発明の一実施例におけるマルチ・チャネル・データ伝送方法のフローチャートである。
【００５０】
図3に示すように、本発明の実施例によるマルチ・チャネル・データ伝送方法は、以下のようなステップを含んでも良い。なお、本発明の実施例による方法は、例えば、プロキシ・サーバにより実行されても良いが、本発明は、これに限定されない。
【００５１】
ステップS310では、マルチ・チャネルを介して複数の上りリンク・データ・パケットを並列受信する。
【００５２】
本発明の実施例では、チャネルの数及びタイプについて限定せず、チャネルの数は、クライアントとプロキシ・サーバとの間でサポートし得る通信チャネルの数に基づいて決定されても良く、例えば、WiFiチャネル、3G／4G／5Gチャネル、有線チャネルなどのうちの少なくとも2つを含んでも良い。
【００５３】
本発明の実施例では、各上りリンク・データ・パケットは、上りリンク・パケット・ヘッダー及びターゲット・サービス・データ・パケットを含んでも良い。そのうち、前記上りリンク・パケット・ヘッダーは、さらに、上りリンク内部通信パケット・ヘッダー及び上りリンク・チャネル・パケット・ヘッダーを含んでも良く、ここで、前記上りリンク内部通信パケット・ヘッダーは、プロキシ・サーバに前記上りリンク・データ・パケットを送信するためのサービス・クライアント・アドレスを含んでも良い。
【００５４】
ステップS320では、前記複数の上りリンク・データ・パケットを解析し、複数のターゲット・サービス・データ・パケット及び複数の上りリンク・パケット・ヘッダーを取得する。
【００５５】
本発明の実施例では、各上りリンク・データ・パケットにおける上りリンク・パケット・ヘッダーを該上りリンク・データ・パケットから除去することで、ターゲット・サービス・データ・パケットを取得することができる。
【００５６】
ステップS330では、前記複数の上りリンク・パケット・ヘッダーに基づいて前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行う。
【００５７】
ここで、各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含む。
【００５８】
例示な実施例において、各上りリンク・パケット・ヘッダーは、さらに、各上りリンク・データ・パケットのチャネルＩＤ及びチャネル情報を含んでも良い。ここで、前記チャネルＩＤは、現在の上りリンク・データ・パケットがどのチャネルを介して送信してきたかを識別するために用いられる。前記チャネル情報は、前記現在の上りリンク・データ・パケットを送信するチャネル・アドレス、例えば、WiFiチャネルのIPアドレス（Internet  Protocol  Address、インターネット・プロトコール・アドレス）又はポートを含んでも良い。
【００５９】
例示的な実施例において、前記複数の上りリンク・パケット・ヘッダーに基づいて前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行うステップは、次のようステップことを含んでも良く、即ち、(MaxSeqno-curSeqno)＞recvThredである場合、ターゲット・サービス・データ・パケットをドロップし；(MaxSeqno-curSeqno)≦recvThredであり、且つcurSeqnoが未受信パケット集合にない場合、対応するターゲット・サービス・データ・パケットをドロップし；curSeqno＞MaxSeqnoである場合、ターゲット・サービス・データ・パケットを残し（リザーブ（reserve）し）；及び、(MaxSeqno-curSeqno)≦recvThredであり、且つパケット・シーケンス番号が前記未受信パケット集合にある場合、対応するターゲット・サービス・データ・パケットを残すステップであり、ここで、curSeqnoは、上りリンク・データ・パケットのパケット・シーケンス番号であり、MaxSeqnoは、クライアント最大受信パケット・シーケンス番号であり、recvThredは、第一閾値である。
【００６０】
例えば、前記第一閾値recvThredが10であるとし、現在のクライアント最大受信パケット・シーケンス番号MaxSeqnoが20であり、現在に受信した上りリンク・データ・パケットのパケット・シーケンス番号curSeqnoが5であるときに、MaxSeqno-curSeqno＝20-5＝15＞10であるため、このときには、該パケット・シーケンス番号が5である上りリンク・データ・パケットをドロップする。
【００６１】
また、例えば、前記第一閾値recvThredが10であるとし、現在のクライアント最大受信パケット・シーケンス番号MaxSeqnoが20であり、現在に受信した上りリンク・データ・パケットのパケット・シーケンス番号curSeqnoが15であるときに、MaxSeqno-curSeqno＝20-15＝5＜10であり、且つこのときの未受信パケット集合にパケット・シーケンス番号15が含まれず、この場合は、同様に該パケット・シーケンス番号が15である上りリンク・データ・パケットをドロップする。
【００６２】
また、例えば、前記第一閾値recvThredが10であるとし、現在のクライアント最大受信パケット・シーケンス番号MaxSeqnoが20であり、現在に受信した上りリンク・データ・パケットのパケット・シーケンス番号curSeqnoが15であるときに、MaxSeqno-curSeqno＝20-15＝5＜10であり、且つこのときの未受信パケット集合にパケット・シーケンス番号15が含まれており、この場合、該パケット・シーケンス番号が15である上りリンク・データ・パケットを残すと同時に、パケット・シーケンス番号15を前記未受信パケット集合から削除する。
【００６３】
例示的な実施例において、前記複数の上りリンク・パケット・ヘッダーに基づいて前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行うステップは、次のようなステップを含んでも良く、即ち、上りリンク・データ・パケットのパケット・シーケンス番号がシーケンス番号キューにおけるパケット・シーケンス番号のうちの何れとも異なる場合、上りリンク・データ・パケットのパケット・シーケンス番号を前記シーケンス番号キューに追加し、また、対応するターゲット・サービス・データ・パケットを残し；及び、上りリンク・データ・パケットのパケット・シーケンス番号が前記シーケンス番号キューにおけるパケット・シーケンス番号のうちの何れか1つと同じである場合、対応するターゲット・サービス・データ・パケットをドロップするステップである。
【００６４】
例示的な実施例において、前記方法は、さらに、次のようなステップを含んでも良く、即ち、チャネルＩＤに基づいて上りリンク・データ・パケットのチャネル・タイプを判断し；及び、上りリンク・データ・パケットのパケット・シーケンス番号が、対応するチャネル・タイプのチャネル最大受信パケット・シーケンス番号よりも大きく、且つ対応するチャネル情報が、対応するチャネル・タイプに格納されるチャネル情報と不一致である場合、対応するチャネル・タイプのチャネル情報を更新するステップである。
【００６５】
ステップS340では、重複除去処理後に残されたターゲット・サービス・データ・パケットをターゲット・サービス・サーバに送信する。
【００６６】
例示的な実施例において、前記方法は、さらに、次のようなステップを含んでも良く、即ち、前記ターゲット・サービス・サーバが前記ターゲット・サービス・データ・パケットに応じて生成した応答データ・パケットを受信し；各チャネル・タイプの最新のチャネル情報に基づいて、前記応答データ・パケットにその対応する下りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化を行い、複数の下りリンク・データ・パケットを生成し；及び、前記複数の下りリンク・データ・パケットを、前記マルチ・チャネルを介してサービス・クライアントに並列送信するステップである。
【００６７】
本発明の実施例によるマルチ・チャネル・データ伝送方法によれば、マルチ・チャネルを介して複数の上りリンク・データ・パケットを並列受信し、そして、複数の上りリンク・データ・パケットを解析して複数のターゲット・サービス・データ・パケット及び複数の上りリンク・パケット・ヘッダーを取得し、それから、複数の上りリンク・パケット・ヘッダーに基づいて、複数のターゲット・サービス・データ・パケットに対して重複除去処理を行い、その後、重複除去処理後に残されたターゲット・サービス・データ・パケットをターゲット・サービス・サーバに送信し、ここで、各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含む。これにより、一方では、マルチ・チャネルを介してパケットを同時に受信することで、ターゲット・サービス・データ・パケットの伝送安定性及び有効性を確保することができ、他方では、並列受信した上りリンク・データ・パケットをアグリゲートして重複除去処理した後にターゲット・サービス・サーバに転送することで、ターゲット・サービス・サーバに対してネットワークの変化をシールド（遮断）し、ターゲット・サービス・サーバが異なるネットワーク環境の変化に気づかないように保証することができ、そのため、ターゲット・サービス・サーバの動作に影響を与えることがない。
【００６８】
図4は、本発明の他の実施例におけるマルチ・チャネル・データ伝送方法のフローチャートである。なお、本発明の実施例による方法は、例えば、サービス・クライアントにより実行されても良いが、本発明は、これに限られない。
【００６９】
図4に示すように、本発明の実施例により提供されるマルチ・チャネル・データ伝送方法は、以下のようなステップを含んでも良い。
【００７０】
ステップS410では、ターゲット・サービス・データ・パケットを取得する。
【００７１】
例示的な実施例において、前記ターゲット・サービス・データ・パケットを取得するステップは、次のようなステップを含んでも良く、即ち、サービス・コンフィグレーション（configuration）に基づいて制御サーバにリクエストし、ターゲット・サービス・サーバ情報を取得し；前記ターゲット・サービス・サーバ情報に基づいてフィルタリング・ポリシーを設定し；及び、前記フィルタリング・ポリシーに基づいて前記ターゲット・サービス・データ・パケットのみを取得するステップである。
【００７２】
以下の実施例では、前記制御サーバがクラウド制御サーバであり、前記ターゲット・サービス・サーバがゲーム・サーバであり、前記ターゲット・サービス・データ・パケットがゲーム・データ・パケットであることを例として説明を行うが、本発明は、これに限定されず、具体的な適用シナリオに応じてその対応する設定を行っても良い。
【００７３】
ステップS420では、前記ターゲット・サービス・データ・パケットに上りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化を行い、複数の上りリンク・データ・パケットを形成する。
【００７４】
そのうち、各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含んでも良い。
【００７５】
ステップS430では、マルチ・チャネルを介して前記複数の上りリンク・データ・パケットをプロキシ・サーバに並列送信する。
【００７６】
例示的な実施例において、前記方法は、さらに、次のようなステップを含んでも良く、即ち、前記マルチ・チャネルを介して、前記ターゲット・サービス・データ・パケットに応じて生成された複数の下りリンク・データ・パケットを並列受信し；前記複数の下りリンク・データ・パケットを解析し、複数の応答データ・パケット及び複数の下りリンク・パケット・ヘッダーを取得し；及び、前記複数の下りリンク・パケット・ヘッダーに基づいて、前記複数の応答データ・パケットに対して重複除去処理を行うステップを含む。
【００７７】
図5は、本発明の一実施例におけるマルチ・チャネル・データ伝送システムを示す図である。
【００７８】
図5に示すように、本発明の実施例によるマルチ・チャネル・データ伝送システム500は、サービス・クライアント510及びプロキシ・サーバ520を含み、サービス・クライアント510とプロキシ・サーバ520との間は、マルチ・チャネル、例えば、チャネル1、チャネル2、…、チャネルn（ここで、nは、2以上の正の整数である）を介して、データの並列伝送を行うことができる。
【００７９】
ここで、サービス・クライアント510は、ターゲット・サービス・データ・パケットを取得し、前記ターゲット・サービス・データ・パケットに上りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化を行い、複数の上りリンク・データ・パケットを形成し送信するように構成されても良い。
【００８０】
プロキシ・サーバ520は、マルチ・チャネルを介して前記複数の上りリンク・データ・パケットを並列受信し、前記複数の上りリンク・データ・パケットを解析し、複数のターゲット・サービス・データ・パケット及び複数の上りリンク・パケット・ヘッダーを取得し、前記複数の上りリンク・パケット・ヘッダーに基づいて、前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行い、重複除去処理後に残されたターゲット・サービス・データ・パケットをターゲット・サービス・サーバ530に送信するように構成されても良い。
【００８１】
例示的な実施例において、プロキシ・サーバ520は、さらに、ターゲット・サービス・サーバ530が前記ターゲット・サービス・データ・パケットに応じて生成した応答データ・パケットを受信し、各チャネル・タイプの最新のチャネル情報に基づいて、前記応答データ・パケットにその対応する下りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化を行い、複数の下りリンク・データ・パケットを生成し送信するように構成されても良く、サービス・クライアント510は、さらに、前記マルチ・チャネルを介して前記複数の下りリンク・データ・パケットを並列受信し、前記複数の下りリンク・データ・パケットを解析し、複数の応答データ・パケット及び複数の下りリンク・パケット・ヘッダーを取得し、前記複数の下りリンク・パケット・ヘッダーに基づいて、前記複数の応答データ・パケットに対して重複除去処理を行うように構成されても良い。
【００８２】
図6は、本発明の他の実施例におけるマルチ・チャネル・データ伝送システムを示す図である。
【００８３】
図6に示すように、本発明の実施例により提供されるマルチ・チャネル・データ伝送システム600は、サービス・クライアント610、ロード・バランシング・サーバ620及びプロキシ・サーバ630を含んでも良い。そのうち、サービス・クライアント610及びプロキシ・サーバ630は、上述の図5に係る実施例におけるサービス・クライアント510及びプロキシ・サーバ520を参照することができるため、ここでは、その詳しい説明を省略する。
【００８４】
上述の図5に示す実施例との相違点は、本発明の実施例によるマルチ・チャネル・データ伝送システム600はさらにロード・バランシング・サーバ620を含むことにある。そのうち、ロード・バランシング・サーバ620は、前記マルチ・チャネルを介して前記複数の上りリンク・データ・パケットを並列受信し、上りリンク・パケット・ヘッダーに基づいて前記複数の上りリンク・データ・パケットのプロキシ・サーバ630を決定し、そして、前記複数の上りリンク・データ・パケットを、前記マルチ・チャネルを介してプロキシ・サーバ630に並列送信するように構成されても良い。
【００８５】
本発明の実施例では、前記方法は、さらに、次のようなステップを含んでも良く、即ち、プロキシ・サーバ630が前記複数の上りリンク・データ・パケットに対して重複除去処理を行った後に、重複除去後のターゲット・サービス・データ・パケットをターゲット・サービス・サーバ640に送信するステップである。或いは、プロキシ・サーバ630は、さらに、ターゲット・サービス・サーバ640がその受信したターゲット・サービス・データ・パケットに応じて返した応答データ・パケットに対して処理を行い、複数の下りリンク・データ・パケットを生成し、そして、チャネル1乃至チャネルnを介して、複数の下りリンク・データ・パケットをロード・バランシング・サーバ620に並列送信し、それから、ロード・バランシング・サーバ620により、チャネル1乃至チャネルnを介して、前記複数の下りリンク・データ・パケットをサービス・クライアント610に並列送信しても良い。
【００８６】
以下、具体例に基づいて上述の方法及びシステムについてさらに説明するが、本発明は、これに限定されない。
【００８７】
図7は、本発明の一実施例によるマルチ・チャネル・データ伝送方法の全体フローを示す図である。ここで、WiFi及び4Gのデュアル・チャネルを用いて、携帯電話クライアントとプロキシ・サーバとの間のデータ伝送チャネルを確立することを例とする。しかしながら、実際には、本発明の実施例による方法は、3つのチャネル又はそれよりも多くのチャネルを実現することもできる。
【００８８】
デュアル・チャネル技術のアーキテクチャは、図7に示すように、WiFi及び4Gネットワークに基づくデュアル・チャネル・パケット同時送信方法を提供する。本発明の実施例における方法は、クライアントSDK（Software  Development  Kit、ソフトウェア開発キット）及びクライアントAPP（application、アプリケーション）の2種類の接続方式に適用することができる。図7では、クライアントAPP  713を例にとって説明し、具体的には、WiFi及び4Gのデュアル・チャネルを介して、同じゲーム・データ・パケットをプロキシ・サーバ740に送信し、プロキシ・サーバ740は、ゲーム・データ・パケットをアグリゲート（aggregate）して重複除去処理を行った後に、重複除去後のゲーム・データ・パケットをゲーム・サーバ750に送信し、プロキシ・サーバ740は、ゲーム・サーバ750の応答データ・パケットを受信したときに、それぞれ、クライアント710と確立されたWiFiチャネル及び4Gチャネルを介してその応答データ・パケットを送信し、これにより、ゲーム・データ・パケットの伝送安定性を確保し、サービスはゼロ・コストでアクセスすることができる。
【００８９】
デュアル・チャネルのクライアントのロジックは、以下のようなステップを含んでも良い。
【００９０】
まず、クライアント710（例えば、携帯電話クライアントであるが、これに限られず、任意のタイプの端末装置であっても良い）は、ゲーム・クライアント711及びクライアントAPP  713を開始（起動）する。クライアントAPP  713が起動すると、クライアントAPP  713は、仮想（バーチャル）ネットワーク・カード7131を生成し、また、WiFiチャネル及び4Gチャネルをバインド（bind）する2つのスレッド（thread）も生成する。
【００９１】
本発明の実施例では、クライアントAPP  713は、対応するゲーム・サービス・コンフィグレーション（configuration）に従ってクラウド制御サーバ720にリクエストを送信することができる。クラウド制御サーバ720は、前記リクエストに基づいて、クライアントAPP  713にゲーム・サーバIPを送信することができる。クライアントAPP  713は、このゲーム・サーバIPに基づいてiptablesフィルタリング・ポリシーを設定し、ゲーム・クライアント711のゲーム・データ・パケットのみをリアル・ネットワーク・カード712から取得し、そして、仮想ネットワーク・カード7131に転送する。これは、携帯電話クライアントにおいてゲーム・データ・パケットでない多くの他のサービス・データ・パケットが同時に存在する可能性があるからである。本発明の実施例では、設定されたゲーム・データ・パケットのみを、デュアル・チャネルを介して送信することができる。ゲーム・データ・パケットでない他のサービス・データ・パケットは、依然として、単一チャネルを用いて送受信される。これにより、使用されるネットワーク・トラフィックを低減することができる。ここで、さらに、どのゲーム・サーバ又はどのようなゲーム・データ・パケットがデュアル・チャネルを介して送受信を行う必要があるかを予め設定してクラウド制御サーバ720に記憶することができる。クライアントAPP  713は、デュアル・チャネルによる送信を必要とするゲーム・データ・パケットのみを得て仮想ネットワーク・カード7131に転送することができる。
【００９２】
本発明の実施例では、クライアントAPP  713は、仮想ネットワーク・カード7131から前記ゲーム・データ・パケットを受信した後に、上りリンク処理モジュール7132により、上りリンク・チャネル・パケット・ヘッダーを付加してカプセル化を行うことで、2つの上りリンク・データ・パケットを形成し、そして、この2つの上りリンク・データ・パケットをそれぞれWiFi及び4Gの2つのチャネルを介してロード・バランシング・サーバ731及びロード・バランシング・サーバ732を送信することができる。
【００９３】
本発明の実施例では、カプセル化のために付加された上りリンク・チャネル・パケット・ヘッダーは、以下のような情報を含んでも良い。
【００９４】
typedef  struct  MutiTunnelUPHead{
uint32_t  m_bussId;  //ゲームＩＤ
uint8_t  ver;  //入力されるメイン・チャネルＩＤ
uint8_t  type;  //チャネルＩＤ、即ち、現在の上りリンク・データ・パケットのチャネル番号又はパケット・タイプ
uint32_t  seqno;  //パケット・シーケンス番号
uint32_t  clientKey;  //クライアントの一意のＩＤ
uint32_t  devKey;  //携帯電話装置の一意のＩＤ
uint32_t  dst_ip;  //ターゲットip
uint16_t  dst_port;  //ターゲットport
uint8_t  mutisetID;  //メイン・チャネルのオペレーターID
}MutiTunnelUPHead;  //新バージョンのプロトコール・コード
ここで、デフォルトとしてWiFiチャネルがメイン・チャネルである。WiFiチャネルのチャネル番号を0と記す場合、メイン・チャネルＩＤは0であり、対応して、チャネルＩＤが0であることは、現在の上りリンク・データ・パケットのチャネル・タイプがWiFiチャネルであることを表し、チャネルＩＤが1であることは、現在の上りリンク・データ・パケットのチャネル・タイプが4Gチャネルであることを表す。クライアントの一意のＩＤclientkeyは、hash32アルゴリズムを採用して算出され得る。
【００９５】
本発明の実施例では、WiFiチャネル及び4Gチャネルがそれぞれ異なるオペレーターに属し、且つWiFiチャネルがメイン・チャネルである場合、メイン・チャネルのオペレーターＩＤmutisetIDフィールドは、WiFiチャネルのオペレーターＩＤであり、プロキシ・サーバ群を決定するために用いられ得る。
【００９６】
本発明の実施例では、クライアントAPP  713は、さらに、下りリンク処理モジュール7133により、ロード・バランシング・サーバ731がWiFiチャネルを介して、及びロード・バランシング・サーバ732が4Gチャネルを介して並列送信した複数の下りリンク・データ・パケットを受信し、そして、下りリンク処理モジュール7133により下りリンク・データ・パケットにおける下りリンク・パケット・ヘッダーを除去し、それから、重複除去ロジックにより重複除去を行い、その後、順次、仮想ネットワーク・カード7131及び真実ネットワーク712を経由してゲーム・クライアント711に送信することができる。
【００９７】
本発明の実施例では、前記下りリンク・パケット・ヘッダーは、以下のような情報を含んでも良い。
【００９８】
typedef  struct  MutiTunnelDownHead{
uint32_t  seqno;  //パケット・シーケンス番号
char  data[0];  //パケット内容
}MutiTunnelDownHead
図7におけるロード・バランシング・サーバ731は、さらに、プロキシ・サービス・マッピング・モジュール7311、上りリンク・スレッド7312及び下りリンク・スレッド7313を含んでも良く、ロード・バランシング・サーバ732は、さらに、プロキシ・サービス・マッピング・モジュール7321、上りリンク・スレッド7322及び下りリンク・スレッド7323を含んでも良い。プロキシ・サーバ740は、さらに、スレッド・メンテナンス・モジュール741、通信メンテナンス・モジュール742、及びクライアント1スレッド、クライアント2スレッド、…、クライアントnスレッドを含んでも良く、ここで、クライアントnスレッド743がさらに下りリンク処理モジュール7431及び上りリンク処理モジュール7432を含んでも良いとする。具体的な実現機能は、以下の実施例を参照することができる。
【００９９】
なお、図7に示す実施例では、WiFiチャネル及び4Gチャネルが異なるオペレーターにより提供されることを例とするため、2つのロード・バランシング・サーバ731及び732が必要とされる。同様に、本発明の実施例による方法を3つのチャネル又はそれよりも多くのマルチ・チャネルに適用する場合、前記マルチ・チャネルは、幾つかのオペレーターにより提供され、この場合は、対応して、幾つかのロード・バランシング・サーバが必要とされる。また、前述のマルチ・チャネルが同じオペレーターにより提供される場合は、1つのみのロード・バランシング・サーバが要される。
【０１００】
また、図7には、1つのみのプロキシ・サーバが示されているが、実際の場合は、1つのプロキシ・サーバ群であっても良い。本発明の実施例では、前記ロード・バランシング・サーバにより、クライアントがマルチ・チャネルを介して並列送信した複数の上りリンク・データ・パケットを同一プロキシ・サーバに送信するために、ロード・バランシング・サーバは、上りリンク・データ・パケットの上りリンク・パケット・ヘッダーにおける情報に基づいて、プロキシ・サーバ群における同一プロキシ・サーバ（プロキシ・サービス・ノートと称されても良い）を決定する必要がある。同様に、前記マルチ・チャネルがそれぞれ複数のオペレーターにより提供される場合、対応する複数のプロキシ・サーバ群が存在し、このときには、上りリンク・パケット・ヘッダーにおけるメイン・チャネルＩＤに基づいて、メイン・チャネルに対応するプロキシ・サーバ群を、前記同一プロキシ・サーバを決定するためのターゲット・プロキシ・サーバ群として決定することができる。
【０１０１】
本発明の実施例におけるマルチ・チャネル・データ伝送方法によれば、WiFi及び4Gの2つの个チャネルを介して、同じゲーム・データ・パケットを同時に送信し、そのうちの1つのネットワーク・チャネルを介したゲーム・データ・パケットが正常に到着することができれば、ユーザー・エクスペリエンスを正常に保つことができ、即ち、クライアント側−サービング側のデータ送受信ネットワーク・チャネルに対してディザスタ・リカバリ（disaster  recovery）処理を行うことで、WiFi又は4Gネットワークのジッターによるパケット紛失、高レイテンシなどの問題を未然に防止することができる。さらに、プロキシ・サーバにより、ゲーム・クライアント及びゲーム・サーバに対してネットワークの変化をシールド（遮断）することで、ゲーム・クライアント及びゲーム・サーバは、異なるネットワーク環境の切り替え動作に気づくことがない。これにより、スムーズな切り替えを行うことができる。他の側面によれば、本発明の実施例における方法は、複雑なモバイル・ネットワークの環境下で、リアル・タイム・ゲームの頻繁な途切れを避けることができ、無線WiFi又は4Gネットワークの調子が悪い場合でも、データ伝送の有効性を依然として保証することができ、特に、一般的なWiFi無線干渉の場合、最適化率は90%にもなることがある。
【０１０２】
図8は、本発明の一実施例におけるクライアントAPPがマルチ・チャネルを介して上りリンク・データ・パケットを送信することを示す図である。
【０１０３】
図8に示すように、クライアントAPP  713における仮想ネットワーク・カード7131は、ゲーム・データ・パケットを上りリンク処理モジュール7132に送信し、上りリンク処理モジュール7132は、前記ゲーム・データ・パケットに上りリンク・パケット・ヘッダーを付加してカプセル化を行った後に、2つの上りリンク・データ・パケットを生成し、そして、それぞれWiFiチャネル及び4Gチャネルを介してこの2つの上りリンク・データ・パケットを送信する。
【０１０４】
図9は、本発明の一実施例におけるクライアントAPPがマルチ・チャネルを介して下りリンク・データ・パケットを受信することを示す図である。
【０１０５】
図9に示すように、クライアントAPP  713における下りリンク処理モジュール7133は、下りリンク・パケット・ヘッダーに基づいて下りリンク・データ・パケットに対して重複除去処理を行い、そして、重複除去処理より下りリンク・データ・パケットにおける下りリンク・パケット・ヘッダーが除去された後のゲーム・データ・パケットを仮想ネットワーク・カード7131に送信し、仮想ネットワーク・カード7131は、それをリアル・ネットワーク・カード712に転送する。
【０１０６】
図10は、本発明の一実施例におけるデータ・パケット重複除去方法のフローチャートである。なお、図10乃至図12において提供される2種類のデータ・パケット重複除去方法は、クライアントに適用されても良く、プロキシ・サーバに適用されても良い。
【０１０７】
図10に示すように、本発明の実施例によるデータ・パケット重複除去方法は、以下のようなステップを含んでも良い。
【０１０８】
ステップS1001では、新しいパケットを受信する。
【０１０９】
ここで、クライアントについて言えば、受信したのは、1つの新しい下りリンク・データ・パケットであり、プロキシ・サーバについて言えば、受信したのは、1つの新しい上りリンク・データ・パケットである。
【０１１０】
ステップS1002では、該新しいパケットのパケット・シーケンス番号curSeqnoがそのチャネル最大受信パケット・シーケンス番号よりも大きいかを判断し、該新しいパケットのパケット・シーケンス番号curSeqnoがそのチャネル最大受信パケット・シーケンス番号よりも大きい場合、ステップS1003に進み、該新しいパケットのパケット・シーケンス番号curSeqnoがそのチャネル最大受信パケット・シーケンス番号以下である場合、ステップS1006にジャンプ（jump）する。
【０１１１】
ここで、受信した新しいパケットのパケット・シーケンス番号がcurSeqnoであるとし、そのパケット・ヘッダー（上りリンク・パケット・ヘッダー又は下りリンク・パケット・ヘッダー）におけるチャネルＩＤに基づいて該新しいパケットのチャネル・タイプを判断することができ、例えば、該新しいパケットのチャネルＩＤが0である場合、該新しいパケットがWiFiチャネルを介して送信されるものであることを把握することができる。このときには、該新しいパケットに対応するWiFiチャネル最大受信パケット・シーケンス番号を得ることができ、該新しいパケットのパケット・シーケンス番号curSeqnoがWiFiチャネル最大受信パケット・シーケンス番号よりも大きい場合、WiFiチャネルについて言えば、それは1つの新しく受信したパケットであることを意味し、該新しいパケットのパケット・シーケンス番号curSeqnoがWiFiチャネル最大受信パケット・シーケンス番号以下である場合、WiFiチャネルについて言えば、それは前に既に受信したパケットであることを意味する。
【０１１２】
なお、本発明の実施例では、チャネル最大受信パケット・シーケンス番号とは、対応するチャネルの前に受信した最大パケット・シーケンス番号を指すが、前記マルチ・チャネルについて言えば、このチャネル最大受信パケット・シーケンス番号は、必ずしも後述のクライアント最大受信パケット・シーケンス番号に等しくない。
【０１１３】
ステップS1003では、そのチャネル最大受信パケット・シーケンス番号を更新する。
【０１１４】
例えば、該新しいパケットがWiFiチャネルからきたものであり、そのパケット・シーケンス番号が2であるが、WiFiチャネル最大受信パケット・シーケンス番号が1である場合、WiFiチャネル最大受信パケット・シーケンス番号を2に更新する。
【０１１５】
ステップS1004では、該新しいパケットのチャネル情報が前に格納されたそのチャネルのチャネル情報と一致するかを判断し、該新しいパケットのチャネル情報が前に格納されたそのチャネルのチャネル情報と不一致である場合、ステップS1006にジャンプし、該新しいパケットのチャネル情報が前に格納されたそのチャネルのチャネル情報と一致した場合、ステップS1005に進む。
【０１１６】
例えば、該新しいパケットがWiFiチャネルについて言えば、前に受信したことのない1つの新しいパケットである場合、このときには、該新しいパケットのチャネル情報、例えば、チャネル・アドレスが前に格納されたWiFiチャネルのチャネル・アドレスと一致するかを判断することができ、両者が不一致である場合、WiFiチャネルのチャネル・アドレスを更新する。このようにして、格納されるのが常に最新のチャネル・アドレスであることを保証することができるため、クライアントとプロキシ・サーバとの間の正確な接続を保つことができる。
【０１１７】
ステップS1005では、そのチャネルのチャネル情報を更新する。
【０１１８】
なお、上述のステップS1003及びS1004は並列実行することもできる。
【０１１９】
ステップS1006では、該新しいパケットのパケット・シーケンス番号curSeqnoがクライアント最大受信パケット・シーケンス番号MaxSeqnoよりも大きいかを判断し、該新しいパケットのパケット・シーケンス番号curSeqnoが前記クライアント最大受信パケット・シーケンス番号MaxSeqnoよりも大きい場合、ステップS1007に進む。
【０１２０】
なお、本発明の実施例では、前記クライアント最大受信パケット・シーケンス番号MaxSeqnoとは、WiFiチャネル及び4Gチャネルの前に受信した、残されて転送された最大パケット・シーケンス番号を指す。
【０１２１】
curSeqno＞MaxSeqnoである場合、該新しいパケットが前に受信したことのない新しいパケットであることを意味し、このときには、該新しいパケットを残す。
【０１２２】
ステップS1007では、該新しいパケットのパケット・シーケンス番号curSeqno、及び、前記クライアント最大受信パケット・シーケンス番号MaxSeqnoとの間でスキップされたパケット・シーケンス番号を未受信パケット集合に入れる。
【０１２３】
本発明の実施例では、時間順に並べ替えられて順次送信されるパケットは、到着時間が必ずしも一致しない。例えば、パケット・シーケンス番号が大きいパケットが後で送信されるが、先に到着する可能性があり、このときに、該新しいパケットのパケット・シーケンス番号は、前記クライアント最大受信パケット・シーケンス番号MaxSeqnoよりも1以上大きい場合があり、例えば、MaxSeqnoが1に等しく、curSeqnoが4である場合、4-1＝3＞1であり、即ち、パケット・シーケンス番号2及び3であるパケットは、スキップされたが、まだ受信されてない。このときには、パケット・シーケンス番号2及び3を未受信パケット集合に入れる。
【０１２４】
ステップS1008では、前記未受信パケット集合のサイズsizeが第一閾値recvThredよりも大きいかを判断し、size＞recvThredである場合、ステップS1009に進み、size≦recvThredである場合、ステップS1011にジャンプする。
【０１２５】
例えば、前記第一閾値は10に設定されても良いが、本発明はこれに限られない。
【０１２６】
ステップS1009では、最小の幾つかの未受信パケット・シーケンス番号を前記未受信パケット集合から削除する。
【０１２７】
このステップの目的は、未受信パケット集合のサイズを制限し、未受信パケット集合におけるパケット・シーケンス番号の数が前記第一閾値範囲内にあるように保つことにある。
【０１２８】
ステップS1010では、前記クライアント最大受信パケット・シーケンス番号MaxSeqnoを更新する。
【０１２９】
ステップS1011では、このパケットを残して転送する。
【０１３０】
なお、上述のステップS1009、S1010及びS1011は、実行順序がなくても良く、並列実行されても良い。
【０１３１】
ステップS1012では、前記クライアント最大受信パケット・シーケンス番号MaxSeqnoから該新しいパケットのパケット・シーケンス番号を引いた後の値が前記第一閾値よりも大きいかを判断し、(MaxSeqno-curSeqno)≦recvThredである場合、ステップS1013に進み、(MaxSeqno-curSeqno)＞recvThredである場合、ステップS1015にジャンプする。
【０１３２】
本発明の実施例では、該新しいパケットのパケット・シーケンス番号が前記クライアント最大受信パケット・シーケンス番号MaxSeqnoよりも第一閾値recvThred小さい場合、該新しいパケットをドロップする。
【０１３３】
例えば、該新しいパケットのパケット・シーケンス番号が7であり、前記クライアント最大受信パケット・シーケンス番号MaxSeqnoが20であり、第一閾値recvThredが10である場合、20-7＝13＞10であり、このときには、パケット・シーケンス番号が7である該新しいパケットをドロップする。
【０１３４】
なお、この第一閾値の値は調整可能であり、その目的は、プロキシ・サーバ又はクライアントが或るパケットを待つ時間長を制限するためであり、このときには、ある程度の数のパケット紛失を許容することができる。レスポンス・レベルが高い場合、前記第一閾値を小さく設定しても良く、例えば、10に設定しても良く、レスポンス・レベルが低い場合、前記第一閾値を大きく設定しても良く、例えば、100に設定しても良い。ひいては、前記第一閾値を全てのパケット・シーケンス番号のうちの最大値に設定しても良く、このときには、無期限に待機し得ることに相当し、パケット紛失がない。
【０１３５】
ステップS1013では、該新しいパケットのパケット・シーケンス番号curSeqnoが前記未受信パケット集合に存在するかを判断し、該新しいパケットのパケット・シーケンス番号curSeqnoが前記未受信パケット集合に存在する場合、ステップS1014に進み、該新しいパケットのパケット・シーケンス番号curSeqnoが前記未受信パケット集合に存在しない場合、ステップS1015にジャンプする。
【０１３６】
ステップS1014では、該新しいパケットのパケット・シーケンス番号curSeqnoを前記未受信パケット集合から削除し、そして、ステップS1011にジャンプし、ステップS1011では、該新しいパケットを残して転送する。
【０１３７】
ここで、再び、前記クライアント最大受信パケット・シーケンス番号MaxSeqnoが20であり、第一閾値recvThredが10であることを例とする。該新しいパケットのパケット・シーケンス番号が17であるとし、このときに、20-17＝3＜10であり、且つ前にパケット・シーケンス番号が17であるパケットを受信したことがなく、即ち、未受信パケット集合に17というパケット・シーケンス番号があり、この場合は、該新しいパケットを受信する。逆に、前にパケット・シーケンス番号が17であるパケットを受信したことがあり、即ち、未受信パケット集合に17というパケット・シーケンス番号がない場合は、同様に該新しいパケットをドロップする。
【０１３８】
ステップS1015では、該新しいパケットをドロップする。
【０１３９】
例示的な実施例において、前記方法は、さらに、次のようなステップを含んでも良く、即ち、各チャネルの先に到着したパケットの数、及び、各チャネルの到着パケットの数を更新するステップであり、これにより、それらを各チャネルのデータ伝送効果を統計するために用いることができる。
【０１４０】
図11は、図10に示すデータ・パケット重複除去方法による一例を示す図である。
【０１４１】
図11に示すように、WiFiチャネルにおけるクライアント送信シーケンスのパケット・シーケンス番号が順に1、2、3、4であり、4Gチャネルにおけるクライアント送信シーケンスのパケット・シーケンス番号も順に1、2、3、4であり、プロキシ・サーバの受信シーケンスのパケット・シーケンス番号が順にWiFiチャネルの1、4Gチャネルの1、WiFiチャネルの4、4Gチャネルの2、WiFiチャネルの2及び3、並びに4Gチャネルの3及び4であるとする。
【０１４２】
ここで、プロキシ・サーバが最初に、WiFiチャネルのパケット・シーケンス番号が1であるパケットを受信し、このパケットを残して転送し、MaxSeqno＝1と更新するとする。
【０１４３】
続いて、プロキシ・サーバは、4Gチャネルのパケット・シーケンス番号が1であるパケットを受信する。このときに、ケース（case）1：MaxSeqno＝1且つMaxSeqno＝curSeqnoに対応し、このパケットをドロップする。
【０１４４】
続いて、プロキシ・サーバは、WiFiチャネルのパケット・シーケンス番号が4であるパケットを受信する。このときに、ケース（case）2：MaxSeqno＝1且つMaxSeqno＜curSeqno&curSeqno-MaxSeqno＞1に対応し、MaxSeqno＝4と更新し、スキップされたパケット・シーケンス番号2及び3を未受信パケット集合に入れ、このパケットを残す。
【０１４５】
続いて、プロキシ・サーバは、4Gチャネルのパケット・シーケンス番号が2であるパケットを受信する。このときに、ケース（case）3：MaxSeqno＝4且つMaxSeqno＞curSeqno&MaxSeqno-curSeqno＜10に対応し、前記未受信パケット集合のうちからパケット・シーケンス番号2を見つけ、このパケットを残し、そして、パケット・シーケンス番号2を前記未受信パケット集合から削除し、このときには、未受信パケット集合には、パケット・シーケンス番号3のみが残される。
【０１４６】
その結果、プロキシ・サーバの転送シーケンスのパケット・シーケンス番号は順に、WiFiチャネルの1、WiFiチャネルの4、4Gチャネルの2、及びWiFiチャネルの3である。
【０１４７】
図12は、本発明の他の実施例におけるデータ・パケット重複除去方法のフローチャートである。
【０１４８】
図12に示すように、本発明の実施例におけるデータ・パケット重複除去方法は、以下のようなステップを含んでも良い。
【０１４９】
ステップS1201では、新しいパケットを受信する。
【０１５０】
ステップS1202では、シーケンス番号キューが空であるかを判断し、前記シーケンス番号キューが空である場合、ステップS1208にジャンプし、前記シーケンス番号キューが空でない場合、ステップS1203に進む。
【０１５１】
本発明の実施例では、該クライアントに対応するシーケンス番号キューが空である場合、該シーケンス番号キューに該新しいパケットのパケット・シーケンス番号及びこのときのタイム・スタンプを追加し、このパケットを残して転送する。
【０１５２】
ステップS1203では、前記シーケンス番号キューを順方向にトラバーサル（traversal）する。
【０１５３】
ステップS1204では、タイム・アウトのパケット・シーケンス番号を前記シーケンス番号キューから削除する。
【０１５４】
本発明の実施例では、前記シーケンス番号キューが空でない場合、前記シーケンス番号キューを順方向にトラバーサルし、シーケンス番号キューにおいて追加の時間と現在の時間との時間差が第二閾値（例えば、500ms）を超えたパケット・シーケンス番号を決定し、該パケット・シーケンス番号及びそのタイム・スタンプを前記シーケンス番号キューから除去する。
【０１５５】
なお、前記第二閾値も調整可能な値であり、具体的には、このシーケンス番号キューの時間長の制限をメンテナンスし、このキューにおけるパケット・シーケンス番号が多すぎないようにする。このようなやり方により、例えば、500msの前に受信されたパケット・シーケンス番号がシーケンス番号キューから移除されたので、500msの後に同じパケット・シーケンス番号がもう1回受信される可能性があり、即ち、パケットが再受信される可能性があるが、パケット紛失が生じない。
【０１５６】
ステップS1205では、前記シーケンス番号キューを逆方向にトラバーサルする。
【０１５７】
なお、上述のステップにおける順方向のトラバーサル及び逆方向のトラバーサルは、実行時間を節約するためだけのものであり、実際にはこれについて限定しない。
【０１５８】
ステップS1206では、該新しいパケットのパケット・シーケンス番号が前記シーケンス番号キューにあるかを判断し、該新しいパケットのパケット・シーケンス番号が前記シーケンス番号キューにある場合、ステップS1207に進む。
【０１５９】
ステップS1207では、この新しいパケットをドロップする。
【０１６０】
前記シーケンス番号キューにおける或るパケット・シーケンス番号が該新しいパケットのパケット・シーケンス番号と同じである場合、該新しいパケットをドロップする。
【０１６１】
ステップS1208では、前記シーケンス番号キューに該新しいパケットのパケット・シーケンス番号及びこのときのタイム・スタンプを追加する。
【０１６２】
前記シーケンス番号キューにおける全てのシーケンス番号が該新しいパケットのパケット・シーケンス番号とはすべて異なる場合、前記シーケンス番号キューに該新しいパケットのパケット・シーケンス番号及びこのときのタイム・スタンプを追加し、この新しいパケットを残して転送する。
【０１６３】
ステップS1209では、この新しいパケットを残して転送する。
【０１６４】
なお、本発明の実施例では、重複除去ロジックは、列挙された上述の2つの方法に限定されず、実際の状況に応じて、任意の適切な重複除去方法を採用してパケットに対して重複除去を行っても良い。
【０１６５】
図13は、本発明の一実施例におけるロード・バランシング・サーバを示す図である。
【０１６６】
外部ネットワーク・ユーザーがアクセスするときに、WiFiと4Gのクロス・ネットワーク（cross  network）（異なるオペレーター間）が存在る場合がある。例えば、WiFiのオペレーターが「チャイナ・モバイル」であり、4Gのオペレーターが「チャイナ・テレコム」であるとする。このような問題を解決するために、デュアル・チャネル・バックグランド・アクセス層においてロード・バランシング・サービスを提供する必要がある。
【０１６７】
図13に示すのは、デュアル・チャネルのサービング側におけるロード・バランシング・サーバ・ロジックである。ここで、ロード・バランシング・サーバ731を例として説明を行う。
【０１６８】
クライアントAPPは、WiFiチャネル又は4Gチャネルの上りリンク・データ・パケットを対応するオペレーターのアクセス・ポイントに送信する。
【０１６９】
ロード・バランシング・サーバ731は、WiFiチャネルを介して上りリンク・データ・パケットを受信し、このときに、前記上りリンク・データ・パケットは、上りリンク・チャネル・パケット・ヘッダー及びゲーム・データ・パケットを含む。ロード・バランシング・サーバ731は、上りリンク・チャネル・パケット・ヘッダーを解析し、パケット・ヘッダーにおけるclientkey値及びmutisetIDフィールドに対応するメイン・チャネルのオペレーターIDを取得することで、受信した上りリンク・データ・パケットをどのオペレーターのプロキシ・サーバ群におけるプロキシ・サーバに送信するかを把握することができる。具体的には、ロード・バランシング・サーバ731におけるプロキシ・サービス・マッピング・モジュール7311は、clientkey値に基づいてプロキシ・サービス・ノードを算出することができる。
【０１７０】
本発明の実施例では、ロード・バランシング・サーバ731における上りリンク・スレッド7312は、前述の受信した上りリンク・データ・パケットに上りリンク内部通信パケット・ヘッダーをさらに付加してカプセル化を行い、前記上りリンク内部通信パケット・ヘッダー、前記上りリンク・チャネル・パケット・ヘッダー及び前記ゲーム・データ・パケットを含む上りリンク・データ・パケットを形成し、そして、上述の算出されたプロキシ・サーバ740に転送する。
【０１７１】
本発明の実施例では、前記上りリンク内部通信パケット・ヘッダーには、次のようなクライアント・アドレス情報が含まれても良い。
【０１７２】
typedef  struct  InerPkg{
struct  sockaddr_in  clientInfo;  //クライアント・アドレス情報
char  data[0];
}InerPkg
図14は、本発明の一実施例におけるロード・バランシング・サーバとプロキシ・サーバとの内部インタラクションのロジカル・シーケンス図である。
【０１７３】
図14に示すように、次のようなステップが含まれている。
【０１７４】
ステップS1：クライアントが各チャネルを介して上りリンク・データ・パケットをロード・バランシング・サーバに送信し、具体的には、ロード・バランシング・サーバの上りリンク・スレッド・モニタリング・ポート19000（一例に過ぎず、これに限らない）に送信する。
【０１７５】
ステップS2：ロード・バランシング・サーバにおけるプロキシ・サービス・マッピング・モジュールがredisと双方向通信を行い、最新のプロキシ・サービス・ノード情報を取得し、また、プロキシ・サービス・マッピング・モジュールは、受信した上りリンク・データ・パケットの上りリンク・チャネル・パケット・ヘッダーにおけるclientkeyに基づいて、現在に受信した上りリンク・データ・パケットの送信先となるクライアント専用プロキシ・サービス・ノードを計算する。
【０１７６】
本発明の実施例では、redisは、1つのデータベースと見なすことができる。プロキシ・サーバ群におけるプロキシ・サーバが変わる可能性があり、例えば、新しいプロキシ・サーバを追加したり、古いプロキシ・サーバを削除したり、元のプロキシ・サーバを置き換えたりする可能性があるので、プロキシ・サービス・マッピング・モジュールが正確な専用プロキシ・サービス・ノードを算出するには、これらの最新のプロキシ・サーバ情報をredisに保存する必要があり、その後、ロード・バランシング・サーバのプロキシ・サービス・マッピング・モジュールは、現在のパケットの転送先となるプロキシ・サービス・ノードを計算するときに、から最新のプロキシ・サーバ情報を読み取って計算を行うことができる。
【０１７７】
なお、プロキシ・サーバ情報を記憶する記憶装置は、redisに限定されず、他の任意のタイプの記憶装置であっても良い。
【０１７８】
ステップS3：ロード・バランシング・サーバがその受信した上りリンク・データ・パケットをもとに、引き続き上りリンク内部通信パケット・ヘッダーを付加してカプセル化を行い、そして、それをステップS2で見つかった専用プロキシ・サービス・ノードに転送する。
【０１７９】
ステップS4：プロキシ・サーバのメイン・スレッドによりクライアント専用スレッドを生成し、該クライアント専用スレッドにより前記上りリンク・データ・パケットの上りリンク内部通信パケット・ヘッダー及び上りリンク・チャネル・パケット・ヘッダーを除去し、そして、重複除去後の上りリンク・データ・パケットにおけるゲーム・データ・パケットをゲーム・サーバに送信する。
【０１８０】
本発明の実施例では、プロキシ・サーバは、各クライアントのために1つの専用スレッドを、各クライアント及びゲーム・サーバに新しいパケットが送信されてきたかをモニタリングするために開始（起動）することができる。
【０１８１】
ステップS5：プロキシ・サーバが、前記クライアント専用スレッドにより、前記ゲーム・サーバがその受信したゲーム・データ・パケットに応じて返した応答データ・パケットを受信する。
【０１８２】
ステップS6：プロキシ・サーバが、前記応答データ・パケットに下りリンク内部通信パケット・ヘッダー及び下りリンク・チャネル・パケット・ヘッダーを付加してカプセル化を行った後に下りリンク・データ・パケットを形成し、そして、各チャネルを介して下りリンク・データ・パケットをロード・バランシング・サーバに返す。
【０１８３】
ステップS7：ロード・バランシング・サーバがポート19001により下りリンク・データ・パケットを、各チャネルを介しいて前記クライアントに送信する。
【０１８４】
図15は、本発明の一実施例におけるロード・バランシング・サーバのプロキシ・サービス・マッピング・モジュールを示す図である。
【０１８５】
本発明の実施例では、前記プロキシ・サービス・マッピング・モジュールは、オペレーターに基づいて、プロキシ・サーバを幾つかの群、例えば、「チャイナ・テレコム」、「チャイナ・モバイル」、「チャイナ・ユニコム」、及び「他のオペレーター」という4つの群に分ける。前記プロキシ・サービス・マッピング・モジュールは、各群のN（Nは、0以上の整数である）個のプロキシ・サービス・ノードを0〜4294967295（この値は例示に過ぎず、本発明はこれに限らない）の範囲内に均一に割り当てる。
【０１８６】
本発明の実施例では、clientkey値を用いて対応するプロキシ・サービス・ノードを計算し、計算公式は、以下の通りである。
【０１８７】
svrNum（デュアル・チャネル・プロキシ・ノード数）  //ここで、4であるとする
MAX  //最大値であり、ここで、＝4294967295とする
svrInterval＝MAX/svrNum  //ここで、1073741823.75であるとする
index＝(clientkey/svrInterval)%svrNum  //%は、剰余演算子である
そのうち、indexは、算出されたプロキシ・ノード番号であり、各ノード番号は、1つのプロキシ・サーバのアドレスを表す。
【０１８８】
図15には、以下のように示されている。
【０１８９】
0≦clientkey＜1073741823の場合、0ノードに該当し；
1073741823≦clientkey＜2147483647の場合、1ノードに該当し；
2147483647≦clientkey＜3221225471の場合、2ノードに該当し；
3221225471≦clientkey＜4294967295の場合、3ノードに該当する。
【０１９０】
本発明の実施例では、各クライアントが1つの専用スレッドを有し、即ち、同一回の伝送チャネルが確立された後に、WiFiチャネル及び4Gチャネルを介して送信される複数の上りリンク・データ・パケットのclientkey値はすべて同じである。今回の伝送チャネルが切断された場合、同じクライアントが伝送チャネルを再確立した後に、clientkey値が変わる。
【０１９１】
本発明の実施例では、プロキシ・サーバに対してオンラインで並行して動的に容量を増やすことができるようにすることで、送受信のデータ・パケットの増加に伴ってプロキシ・サーバを拡充することができるように保証するために、プロキシ・サービス・マッピング・モジュールは、所定の時間ごとに、例えば、1秒ごとに、redis群にアクセスし、最新のプロキシ・サーバ・リストを取得する。最新のプロキシ・サーバ・ノードと不一致である場合、増加、削除又は交換の操作を行う。
【０１９２】
図16は、本発明の他の実施例におけるロード・バランシング・サーバのプロキシ・サービス・マッピング・モジュールを示す図である。
【０１９３】
図16は、ノード更新ロジックの例示的な説明図である。ノード3の後にノード4を増やすとし、上述のindexの計算公式によれば、svrIntervalが等間隔であるから、ここで、元の各ノードの後に1つの仮想ノード、例えば、仮想ノード0、1、2を増やすことで、上述のノード計算公式の一致性を保つ必要がある。ここで、仮想ノード及びその前の1つのノードが表すプロキシ・サーバアドレス情報は同じであり、このときには、ノードの数svrNumが倍になり、例えば、svrNumは8に等しい。
【０１９４】
なお、新しく増やしたノードは、任意の位置に追加されても良く、ノード3の後に追加することに限定されない。
【０１９５】
図17は、本発明の他の実施例におけるロード・バランシング・サーバのプロキシ・サービス・マッピング・モジュールを示す図である。
【０１９６】
図17に示すのは、プロキシ・サービス・ノードの削除の一例である。ノード3が削除されるとする場合、削除された位置を埋めるために仮想ノード2を追加する必要があり、同様に、等間隔の特徴を保つために、仮想ノードのアドレス情報は、前の1つのノードと同じである。
【０１９７】
図18は、本発明の他の実施例におけるロード・バランシング・サーバのプロキシ・サービス・マッピング・モジュールを示す図である。
【０１９８】
図18に示すのは、プロキシ・サービス・ノードの交換の一例である。古いノード3が置換されるとする場合、ノード3の情報を新しいノード4の情報に置換すれば良い。例えば、或るプロキシ・サーバの性能が劣化した場合、新しいプロキシ・サーバでそれを置換しても良い。
【０１９９】
図19は、本発明の一実施例におけるプロキシ・サーバのロジカル・シーケンス図である。
【０２００】
図19に示すように、以下のようなステップが含まれる。
【０２０１】
ステップS1：プロキシ・サーバが上りリンク・データ・パケットを受信する。
【０２０２】
ステップS2：プロキシ・サーバが、前記上りリンク・データ・パケットの上りリンク・チャネル・パケット・ヘッダー及び上りリンク内部通信パケット・ヘッダーを除去し、重複除去処理を行った後に、ゲーム・データ・パケットをゲーム・サーバに送信する。また、プロキシ・サーバが、スレッド・メンテナンス・モジュールを更新し、このクライアントのために、プロキシ・サーバで1つのサービング用の専用スレッドを生成し、また、スレッド・メンテナンス・モジュールにおける情報を更新する。
【０２０３】
本発明の実施例では、プロキシ・サーバは、1つのクライアントが送信した上りリンク・データ・パケットを新しく受信したときに、該上りリンク・データ・パケットの上りリンク・チャネル・パケット・ヘッダー及び上りリンク内部通信パケット・ヘッダーを除去し、クライアント・アドレス情報を取得し、そして、それを通信メンテナンス・モジュールに記録する。このようにして、その後、スレッド・メンテナンス・モジュールは、下りリンク・パケット・ヘッダーに対してカプセル化を行うときに、前記通信メンテナンス・モジュールのうちから対応するクライアント・アドレス情報をコピーして下りリンク内部通信パケット・ヘッダーに付加してカプセル化を行うことができる。これにより、プロキシ・サーバは、下りリンク・データ・パケットがどのクライアントに転送されるかを把握することができる。
【０２０４】
本発明の実施例では、クライアントは、リアル・タイムでプロキシ・サーバに上りリンク・データ・パケットの所在するチャネルの情報を送信する。これにより、プロキシ・サーバがチャネルの切り替えを行うことで、4G又はWiFiチャネルに切り替え異常が発生するときに、プロキシ・サーバができるだけ早めにクライアントに対応するチャネル情報を更新するように保証することができる。このチャネル情報がメンテナンスするのは、チャネル・パケット・ヘッダーのver及びtypeフィールドである。
【０２０５】
なお、上述のチャネル切り替えとは、主に、4Gの内部切り替え又はWiFiの内部切り替えを指す。4Gのアドレス及びWiFiのアドレスが変わる可能性があるので、本発明の実施例は、最新のチャネル情報に基づいて、クライアントとプロキシ・サーバとの間の接続を保つことができる。
【０２０６】
もう１つの異常なケースは、例えば、WiFiがメイン・チャネルであり、WiFiに異常が生じれば、ネットワークに接続することができなくなることである。このときに、4Gをメイン・チャネルに切り替え、それ相応にチャネル・パケット・ヘッダーのverフィールドも変えることができる。このときに、4Gチャネルのみを介して下りリンク・データ・パケットをクライアントに送信することができる。しかしながら、このときには、依然として、WiFiに対応するオペレーターのプロキシ・サーバ群におけるプロキシ・サーバを用いて下りリンク・パケット・ヘッダーの付加（カプセル化）などの操作を完成することができ、即ち、4Gオペレーターのプロキシ・サーバ群に切り替える必要がない。
【０２０７】
本発明の実施例では、プロキシ・サーバは、上りリンク・データ・パケットにおける上りリンク・チャネル・パケット・ヘッダーのクライアントの一意のＩＤclientkey値に基づいて、4G及びWiFiチャネルから送信されてきたクライアント・データを識別し、重複除去処理を行うことができる。なお、重複除去アルゴリズムは、上述の図10乃至図12に係る実施例を参照することができる。
【０２０８】
本発明の実施例では、プロキシ・サーバは、クライアント及びゲーム・サーバのために、1つの一意のリンクを確立し、重複除去後のゲーム・データ・パケットを前記ゲーム・サーバに送信する。
【０２０９】
ステップS3：ゲーム・サーバが前記ゲーム・データ・パケットに応じて応答データ・パケットを返す。
【０２１０】
ステップS4：プロキシ・サーバが、通信メンテナンス・モジュールからクライアント・アドレスを取得し、前記応答データ・パケットの下りリンク内部通信パケット・ヘッダーに付加してカプセル化を行い、そして、前記応答データ・パケットに下りリンク・チャネル・パケット・ヘッダーを付加してカプセル化を行った後に、前記応答データ・パケットを転送する。
【０２１１】
本発明の実施例では、プロキシ・サーバが生成するクライアント・スレッドは、プロキシ・サーバとゲーム・サーバとの間で確立された専用リンクをモニタリングし、ゲーム・サーバから返された応答データ・パケットを受信した後に、前記通信メンテナンス・モジュールにおける最新のWiFiチャネル及び4Gチャネルのアドレス情報に基づいて、下りリンク・チャネル・パケット・ヘッダー及び下りリンク内部通信パケット・ヘッダーを付加してカプセル化を行った後に、形成した2つの下りリンク・データ・パケットをそれぞれ2つのチャネルへ送信する。
【０２１２】
本発明の実施例では、プロキシ・サーバは、さらに、定期的にクライアント・チャネル情報をクリアすることができ、例えば、タイム・アウト期間内でクライアントからのデータがプロキシ・サーバを通過しない場合、このクライアントのスレッド及びチャネル情報データを消去する。
【０２１３】
図20は、本発明の一実施例におけるプロキシ・サーバがマルチ・チャネルを介して下りリンク・データ・パケットを送信することを示す図である。
【０２１４】
図20に示すように、プロキシ・サーバ740は、それぞれ、WiFiチャネル及び4Gチャネルを介して、下りリンク内部通信パケット・ヘッダー及び下りリンク・チャネル・パケット・ヘッダーが付加（カプセル化）された応答データ・パケット、即ち、下りリンク・データ・パケットをそれぞれロード・バランシング・サーバ731及びロード・バランシング・サーバ732に送信する。
【０２１５】
ロード・バランシング・サーバ731は、前記下りリンク・データ・パケットの下りリンク内部通信パケット・ヘッダーを除去した後に、WiFiチャネルを介してサービス・クライアント（図未せず）に送信する。
【０２１６】
ロード・バランシング・サーバ732は、前記下りリンク・データ・パケットの下りリンク内部通信パケット・ヘッダーを除去した後に、4Gチャネルを介してサービス・クライアント（図未せず）に送信する。
【０２１７】
本発明の実施例では、ロード・バランシング・サーバにおける下りリンク・スレッドは、プロキシ・サーバが送信した下りリンク・データ・パケットを受信した後に、下りリンク内部通信パケット・ヘッダーを除去し、クライアント・アドレス情報を取得し、そして、下りリンク・チャネル・パケット・ヘッダー及び応答データ・パケットを含む下りリンク・データ・パケットをサービス・クライアントに転送する。
【０２１８】
本スキームでは、デュアル・チャネル・ロード・バランシング・サーバの主要な役割は、プロキシ・サービス・マッピング・モジュールにより、WiFiチャネル及び4Gチャネルの異なるオペレーターのデータ・パケットを同一デュアル・チャネル・プロキシ・サーバに送信することにあり、オペレーターが1つ以上あれば、対応して1つ以上のデュアル・チャネル・プロキシ・サーバ群がある。しかしながら、本スキームでは、メイン・チャネル（デフォルトとしてWiFiチャネルである）に対応するオペレーターのデュアル・チャネル・プロキシ・サーバ群のみを用いることができ、その後、WiFiチャネルの異常な切断が発生しても、ver及びtypeフィールドにより、メイン・チャネルを4Gチャネルに切り替えることができ、このときには、加速が完了し、初期化が完了しているため、WiFiチャネルに対応するオペレーターのデュアル・チャネル・プロキシ・サーバ群により下りリンク・データ・パケットを送信することができる。幾つかの場合、下りリンク・パケットは、メイン・チャネルのみを介して送信されても良いが、本スキームでは、下りリンク・パケットは、デュアル・チャネルを介して送信されるのである。
【０２１９】
本発明の実施例による方法は、比較的柔軟であり、殆どのサービスは、変更や適応なしにゼロ・コストでアクセスすることができる。また、WiFi又は4Gの上位層ネットワーク故障が生じるときに、ユーザーが完全に気づかず、且つ70％以上のクライアントの頻繁な途切れを防ぐことができ、特に、WiFiネットワークがより複雑な場合、効果はより大きくなる。
【０２２０】
以下、本発明の装置の実施例を説明し、それは、上述のマルチ・チャネル・データ伝送方法を実行するために用いられる。なお、本発明の装置の実施例に開示されていない詳細については、上述のマルチ・チャネル・データ伝送方法の実施例を参照することができる。
【０２２１】
図21は、本発明の一実施例におけるマルチ・チャネル・データ伝送装置のブロック図である。
【０２２２】
図21に示すように、本発明の実施例によるマルチ・チャネル・データ伝送装置2100は、上りリンク・データ受信モジュール2110、上りリンク・データ解析モジュール2120、上りリンク・データ重複除去モジュール2130及び上りリンク・データ転送モジュール2140を含んでも良い。
【０２２３】
そのうち、上りリンク・データ受信モジュール2110は、マルチ・チャネルを介して複数の上りリンク・データ・パケットを並列受信するために用いられる。
【０２２４】
上りリンク・データ解析モジュール2120は、前記複数の上りリンク・データ・パケットを解析し、複数のターゲット・サービス・データ・パケット及び複数の上りリンク・パケット・ヘッダーを取得するために用いられる。
【０２２５】
上りリンク・データ重複除去モジュール2130は、前記複数の上りリンク・パケット・ヘッダーに基づいて、前記複数のターゲット・サービス・データ・パケットに対して重複除去処理を行うために用いられる。
【０２２６】
上りリンク・データ転送モジュール2140は、重複除去後に残されたターゲット・サービス・データ・パケットをターゲット・サービス・サーバに送信するために用いられる。
【０２２７】
ここで、各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含んでも良い。
【０２２８】
例示的な実施例において、上りリンク・データ重複除去モジュール2130は、第一パケット・ドロップ・ユニットを含んでも良く、それは、(MaxSeqno-curSeqno)＞recvThredである場合、対応するターゲット・サービス・データ・パケットをドロップし、(MaxSeqno-curSeqno)≦recvThredであり、且つcurSeqnoが未受信パケット集合にない場合、対応するターゲット・サービス・データ・パケットをドロップするために用いられる。
【０２２９】
例示的な実施例において、上りリンク・データ重複除去モジュール2130は、さらに、第一パケット・リザーブ・ユニットを含み、それは、curSeqno＞MaxSeqnoである場合、対応するターゲット・サービス・データ・パケットを残し、(MaxSeqno-curSeqno)≦recvThredであり、且つパケット・シーケンス番号が前記未受信パケット集合にある場合、対応するターゲット・サービス・データ・パケットを残すために用いられる。
【０２３０】
そのうち、curSeqnoは、上りリンク・データ・パケットのパケット・シーケンス番号であり、MaxSeqnoは、クライアント最大受信パケット・シーケンス番号であり、recvThredは、第一閾値である。
【０２３１】
例示的な実施例において、上りリンク・データ重複除去モジュール2130は、上りリンク・データ・パケットのパケット・シーケンス番号がシーケンス番号キューにおけるパケット・シーケンス番号のうちの何れとも異なる場合、上りリンク・データ・パケットのパケット・シーケンス番号を前記シーケンス番号キューに追加し、対応するターゲット・サービス・データ・パケットを残すために用いられる第二パケット・リザーブ・ユニット；及び、上りリンク・データ・パケットのパケット・シーケンス番号が前記シーケンス番号キューにおけるパケット・シーケンス番号のうちの何れか1つと同じである場合、対応するターゲット・サービス・データ・パケットをドロップするために用いられる第二パケット・ドロップ・ユニットを含んでも良い。
【０２３２】
例示的な実施例において、各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのチャネルＩＤ及びチャネル情報をさらに含む。
【０２３３】
例示的な実施例において、マルチ・チャネル・データ伝送装置2100は、さらに、チャネルＩＤに基づいて上りリンク・データ・パケットのチャネル・タイプを判断するためのチャネル・タイプ判断モジュール；及び、上りリンク・データ・パケットのパケット・シーケンス番号が、対応するチャネル・タイプのチャネル最大受信パケット・シーケンス番号よりも大きく、且つ対応するチャネル情報が、対応するチャネル・タイプに格納されるチャネル情報と不一致である場合、対応するチャネル・タイプのチャネル情報を更新するためのチャネル情報更新モジュールを含んでも良い。
【０２３４】
例示的な実施例において、マルチ・チャネル・データ伝送装置2100は、さらに、前記ターゲット・サービス・サーバが前記ターゲット・サービス・データ・パケットに応じて生成した応答データ・パケットを受信するための応答データ受信モジュール；各チャネル・タイプの最新のチャネル情報に基づいて前記応答データ・パケットにそれぞれ対応する下りリンク・パケット・ヘッダーを付加してカプセル化を行い、複数の下りリンク・データ・パケットを生成するための下りリンク・データ生成モジュール；及び、前記マルチ・チャネルを介して前記複数の下りリンク・データ・パケットをサービス・クライアントに並列送信するための下りリンク・データ送信モジュールを含んでも良い。
【０２３５】
図22は、本発明の他の実施例におけるマルチ・チャネル・データ伝送装置のブロック図である。
【０２３６】
図22に示すように、本発明の実施例により提供されるマルチ・チャネル・データ伝送装置2200は、ターゲット・データ取得モジュール2210、上りリンク・パケット・ヘッダー・カプセル化モジュール2220及び上りリンク・データ送信モジュール2230を含んでも良い。
【０２３７】
ここで、ターゲット・データ取得モジュール2210は、ターゲット・サービス・データ・パケットを取得するために用いられる。
【０２３８】
上りリンク・パケット・ヘッダー・カプセル化モジュール2220は、前記ターゲット・サービス・データ・パケットに上りリンク・パケット・ヘッダーをそれぞれ付加してカプセル化を行い、複数の上りリンク・データ・パケットを形成するために用いられる。
【０２３９】
上りリンク・データ送信モジュール2230は、マルチ・チャネルを介して前記複数の上りリンク・データ・パケットをプロキシ・サーバに並列送信するために用いられる。
【０２４０】
ここで、各上りリンク・パケット・ヘッダーは、各上りリンク・データ・パケットのパケット・シーケンス番号を含んでも良い。
【０２４１】
例示的な実施例において、マルチ・チャネル・データ伝送装置2200は、さらに、前記マルチ・チャネルを介して、前記ターゲット・サービス・データ・パケットに応じて生成された複数の下りリンク・データ・パケットを並列受信するための下りリンク・データ受信モジュール；前記複数の下りリンク・データ・パケットを解析し、複数の応答データ・パケット及び複数の下りリンク・パケット・ヘッダーを取得するための下りリンク・データ解析モジュール；及び、前記複数の下りリンク・パケット・ヘッダーに基づいて、前記複数の応答データ・パケットに対して重複除去処理を行うための下りリンク・データ重複除去モジュールを含んでも良い。
【０２４２】
例示的な実施例において、ターゲット・データ取得モジュール2210は、サービス・コンフィグレーション（configuration）に基づいて制御サーバにリクエストし、ターゲット・サービス・サーバ情報を取得するためのサービス・サーバ情報取得ユニット；前記ターゲット・サービス・サーバ情報に基づいてフィルタリング・ポリシーを設定するためのフィルタリング・ポリシー設定ユニット；及び、前記フィルタリング・ポリシーに基づいて前記ターゲット・サービス・データ・パケットのみを取得するためのターゲット・サービス・データ取得ユニットを含んでも良い。
【０２４３】
なお、上記の詳細な説明では、動作を実行するための装置における幾つかのモジュール又はユニットについて言及されたが、このような区別は必須でない。実際には、本発明の実施例によれば、上述の2つ又はそれよりも多くのモジュール又はユニットの特徴及び機能は、1つのモジュール又はユニットにおいて具体化することができる。逆に、上述の1つのモジュール又はユニットの特徴及び機能は、複数のモジュール又はユニットにおいて具体化することができる。
【０２４４】
以上の実施例の説明により、当業者が理解すべきは、ここで記載された例示的な実施例は、ソフトウェアにより実現されても良く、ソフトウェと必要なハードウェアとの組み合わせにより実現されても良いということである。よって、本発明の実施例による技術的手段は、ソフトウェア・プロダクトの形で具現化することができ、このようなソフトウェア・プロダクトは、計算装置（コンピュータ、サーバ、タッチ端末、ネットワーク装置など）に本発明の実施例における方法を実行させるための複数の指令（プログラム）を含み、且つ不揮発性記憶媒体（CD-ROM、Uディスク、モバイル・ハード・ディスクなど）中又はネットワーク上に記憶することができる。
【０２４５】
当業者は、本明細書を検討し、ここで公開された発明を実施した後に、本発明の他の実施例を容易に想到し得る。本発明は、本発明の任意の変形、用途又は適応変化をカバーすることを目的としており、これらの変形、用途又は適応変化は、本発明の一般原則に従い、且つ本発明で開示されていない本技術分野における周知技術や慣用手段を含む。また、本明細書及び実施例は、例示に過ぎず、本発明の技術思想及び技術的範囲は、特許請求の範囲に基づいて定められる。
【０２４６】
以上、本発明の好ましい実施形態を説明したが、本発明はこのような実施形態に限定されず、本発明の趣旨を逸脱しない限り、本発明に対するあらゆる変更は本発明の技術的範囲に属する。
【図１】
2021521749.tif 000003
【図２】
2021521749.tif 000004
【図３】
2021521749.tif 000005
【図４】
2021521749.tif 000006
【図５】
2021521749.tif 000007
【図６】
2021521749.tif 000008
【図７】
2021521749.tif 000009
【図８】
2021521749.tif 000010
【図９】
2021521749.tif 000011
【図１０】
2021521749.tif 000012
【図１１】
2021521749.tif 000013
【図１２】
2021521749.tif 000014
【図１３】
2021521749.tif 000015
【図１４】
2021521749.tif 000016
【図１５】
2021521749.tif 000017
【図１６】
2021521749.tif 000018
【図１７】
2021521749.tif 000019
【図１８】
2021521749.tif 000020
【図１９】
2021521749.tif 000021
【図２０】
2021521749.tif 000022
【図２１】
2021521749.tif 000023
【図２２】
2021521749.tif 000024
【国際調査報告】
2021521749.tif 000025
2021521749.tif 000026
2021521749.tif 000027
2021521749.tif 000028