JP3785343B2 - クライアントサーバシステム及びクライアントサーバシステムにおけるデータ通信方法 - Google Patents
クライアントサーバシステム及びクライアントサーバシステムにおけるデータ通信方法 Download PDFInfo
- Publication number
- JP3785343B2 JP3785343B2 JP2001306321A JP2001306321A JP3785343B2 JP 3785343 B2 JP3785343 B2 JP 3785343B2 JP 2001306321 A JP2001306321 A JP 2001306321A JP 2001306321 A JP2001306321 A JP 2001306321A JP 3785343 B2 JP3785343 B2 JP 3785343B2
- Authority
- JP
- Japan
- Prior art keywords
- client
- server
- connection
- data
- connections
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、クライアントサーバシステムに関するものである。
【０００２】
【従来の技術】
インターネットに代表されるＴＣＰ／ＩＰプロトコルスイートを用いたネットワーク上のクライアントサーバシステムでは、サーバのアドレス、ポート番号とクライアントのアドレス、ポート番号との間でコネクションの確立が行われた後、これらの間のデータのやりとりはＩＰデータグラムというパケットに分割されて、インターネット上を転送させる。インターネットではルータがＩＰデータグラムに付与された宛先ＩＰアドレスを確認し、それぞれルータが持つ経路テーブルに基づいてパケットが転送され、サーバ、クライアント間のデータのやりとりが行われる。現状、ルータは経路テーブルをＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆａｓｔ）等のルーティングプロトコルを用いてメンテナンスしている。ＯＳＰＦなどのルーティングプロトコルでは自分に隣接するルータまでのコスト（通常はインタフェイス速度の逆数）をＬＳＡ（Ｌｉｎｋ Ｓｔａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔ）として自分に隣接するルータに広告通知する。この広告通知されたＬＳＡにより各ルータは経路テーブルを構築する。この経路テーブルを用いることで宛先ＩＰアドレスに対し、最小コストの経路が選択され、ルータから転送される。したがって障害などによる経路情報の変化がなければ、任意のＩＰアドレス間のデータ転送経路は一意に定まり、常にこの経路をパケットが通過することになる。
【０００３】
従来のクライアントサーバシステムにおけるファイルデータ転送について、以下に説明する。まず、従来のルータ装置の構成について図６を参照して説明する。
【０００４】
図６は、従来のクライアントサーバシステムにおけるファイルデータ転送の例を示す図である。符号１はクライアント、２はサーバ、３はルータ、４はアクセスリンク、５はネームサーバ、６はインタネット上のリンクである。
【０００５】
例として、クライアント１がｆｔｐ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｃｏｌ）を用いてサーバ２からファイルを転送する場合を取り上げる。クライアント１は、まず、ｆｒｐのためのＴＣＰコネクションをサーバ２との間で確立する。次に、クライアント１は、ネームサーバ５へサーバ２のアドレスを問い合わせる。そして、ネームサーバ５より回答されたサーバ２のＩＰアドレスに対し、クライアント１はｆｔｐのためのＴＣＰのコネクションを確立し、ｆｔｐのコマンド等をサーバ２との間でやりとりする。確立されたＴＣＰコネクション上のデータは、ＩＰデータグラム（パケット）に（必要があれば分割されて）格納され、アクセスリンク４，ルータ３，ルータ間を結ぶリンク６を介してクライアントサーバ間をやりとりされる。この時、サーバ、クライアント間のパケットが流れる経路は各ルータによって選択されるがＯＳＰＦなどのルーティングプロトコルは最小コスト経路を常に選択するため、障害などでリンクが不通となっている場合などを除いて常に同一経路が選択されて転送される。
【０００６】
【発明が解決しようとする課題】
上記のように従来のクライアントサーバシステムでは、データのやりとりにインターネット上の一つの経路が利用される。画像などのマルチメディアアプリケーションや大きなファイルの転送のように高速でのデータのやり取りが必要なユーザはＡＤＳＬやケーブルモデム、ＦＴＴＨといった高速のアクセスリンクを契約し、クライアントサーバ間で高速データ転送を試みる。しかし、アクセスリンクが高速であってもインターネット上の経路は一定であり、他のパケットとそれぞれのリンクでの使用可能帯域をシェアすることになる。このため、サーバ・クライアント間のスループットは経路上のリンクの最小帯域に制限される。また、経路上の何れかのリンクが混雑していれば、他のリンクが空いていたとしても迂回することができず、他のパケットと同様にスループットの低下を招いてしまう。このように従来のクライアントサーバシステムではサーバ・クライアント間に最小コスト経路が設定されてしまうため、アクセスリンクに高速リンクを用意したとしてもサーバクライアント間に高スループットを期待することができず、また混雑時の迂回や障害を避けるために最小コスト以外の経路による冗長な転送が不可能であった。
【０００７】
本発明は、上記事情に鑑みてなされたものであり、その目的とするところは、高速アクセスリンクを持つクライアントサーバシステムのスループットを向上させ、またネットワークの混雑時や障害時のスループット低下を改善するクライアントサーバシステムを提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、本発明では、サーバ・クライアント間に複数の異なる経路のコネクションを確立し、該コネクション上でデータ通信を行うものを提案する。また、サーバ・クライアント間のデータ通信は、両者間で直接データをやり取りするのではなく、コネクション毎にプロキシによりサーバ・クライアント間のデータ転送を中継する方法を提案する。本発明によれば、一つのアプリケーションに対し、複数のコネクションを同時に利用し、更にそれぞれの経路を変更することでサーバ・クライアント間のスループット向上を図り、混雑や障害によるスループット低下を改善する。
【０００９】
さらに、本発明では、中継するプロキシを一段ではなく、多段接続するものを提案する。これは、一端経路が分散された複数のコネクションが同一リンク上を通過することを防ぐことを目的としており、経路分散を確実にすることでスループット向上を図る。
【００１０】
さらに、本発明では、ネームサーバの変わりに負荷分散装置を用いて各コネクションを中継するプロキシを選択するものを提案する。ネームサーバに特定サーバのアドレスとして複数のプロキシのアドレスを登録しておくのではなく、通常どおりのサーバのアドレスを格納しておく。サーバ・クライアント間の経路上、例えばクライアントの隣接する位置に負荷分散装置を設置し、同一のサーバへの複数コネクション（クライアントのポート番号が異なるため識別可能）によるアクセスをそれぞれ異なるプロキシへ振ることにより経路を分散させる。
【００１１】
さらに、本発明では、サーバ・クライアント間の経路分散化されたコネクションをデータ転送に信頼性向上の目的で、データを誤り訂正符号化する方法を提案する。サーバ側で誤り訂正符号化し、クライアント側で復号化することにより、一部の経路上に障害が生じた場合でも、もとのデータを復元することができる。
【００１２】
【発明の実施の形態】
（第１の実施の形態）
本発明の第１の実施形態にかかるクライアントサーバシステムについて図面を参照して詳細に説明する。
【００１３】
図１は本発明の実施形態にかかるネットワークの構成図である。図中、１０はネットワーク、１１はクライアント、１２はサーバ、１３はルータ、１４はアクセスリンク、１５はネームサーバ、１６はネットワーク上のリンク、１７はプロキシ、１８はコネクションである。ここで、ネットワーク１０としては、例えばインターネットなどのＴＣＰ／ＩＰプロトコルスイートを用いたネットワークを用いた。また、アクセスリンク１４、リンク１６はコネクション１８の下位の層である。本実施の形態ではネットワーク１０としてＴＣＰ／ＩＰを用いてるので、ＩＰ層以下に相当するものでありＯＳＩ参照モデルのネットワーク層以下にほぼ相当する。また、本実施の形態では、コネクション１８はＴＣＰ／ＵＤＰ層でありＯＳＩ参照モデルのトランスポート層にほぼ相当する。
【００１４】
本実施の形態ではサーバからクライアントへのファイル転送を例として説明する。また、ここでは、並列経路を使ってファイルを転送するアプリケーションを想定し、このアプリケーションのためのサーバ側のポート番号ｘがクライアント側で既知であるとする。
【００１５】
クライアント１１は、ｆｔｐと同様にサーバ１２のポート番号ｘへのコネクション１８を確立するため、ネームサーバ１５へサーバ１２のＩＰアドレスを問い合わせる。この時、ネームサーバ１５には、実際のサーバ１２のＩＰアドレスではなく、サーバ・クライアント間のデータ転送を中継するプロキシ１７のアドレスが格納されており、ネームサーバ１５はこれをサーバ１２のＩＰアドレスへの問い合わせに対する回答として答える。クライアント１１は、サーバのポート番号ｘに対して複数のＴＣＰコネクション１８を確立しようとし、そのたびにネームサーバ１５へＩＰアドレスを問い合わせる。
【００１６】
ネームサーバ１５は複数登録されているプロキシ１７のアドレスを例えばラウンドロビンなどのルールで順次クライアント１１へ回答する。具体的にはネームサーバ１５にはサーバ１２のアドレス（例えばsss.sss.sss.sss）の代わりに、以下のようにプロキシサーバのＩＰアドレスがＡレコードとして加えられている。 servername A xxx.xxx.xxx.xxx(第１のプロキシのＩＰアドレス)
servername A yyy.yyy.yyy.yyy(第２のプロキシのＩＰアドレス)
servername A zzz.zzz.zzz.zzz(第３のプロキシのＩＰアドレス)
これにより、ネームサーバ１５はクライアント１１からのＩＰアドレスの問い合わせに対して、サーバ１２のＩＰアドレスではなく、プロキシ１５のＩＰアドレスを問い合わせ順にラウンドロビンで回答する。
【００１７】
ネームサーバ１５からＩＰアドレスの返答を受けたクライアント１１はサーバへ１２のＴＣＰコネクション１８の確立要求”ＳＹＮ（Ｓｙｎｃｈｒｏｎｉｚｅの意）”をコネクション１８ごとに異なるプロキシ１７のポート番号ｘへ送信する。
【００１８】
各プロキシ１７は、ポート番号ｘへのアクセスを並列転送であると認識し、サーバ１２のＩＰアドレス、ポート番号ｘへ中継する。すなわち、プロキシ１７には、クライアント１１からのアクセスをサーバ１２へ中継するために予めＴＣＰデリゲイトが設定されている。例えば、「ｄｅｌｅｇａｔｅｄ」というプロキシプログラムを用いる場合、
delegated -P5000 SERVER=tcprelay://sss.sss.sss.sss:6000
という設定がなされている。ここで、sss.sss.sss.sssはサーバ１２のＩＰアドレス、6000はサーバ１２における並列転送のためのポート番号であるとする。また、5000はプロキシ１７のポート番号ｘで、クライアント１１から5000番のＴＣＰポートにアクセスされた場合、クライアント１１からのアクセスをサーバ１２に中継するという意味である。プロキシ１７は、クライアント１１からアクセスされたポート番号によって中継する先のサーバ１２を識別することができる。
【００１９】
なお、クライアント１１とサーバ１２間のコネクション１８においてプロキシ１７による中継点は２以上あってもよい。すなわち、図１に示すように、一部のプロキシ１７のポート番号ｘへのアクセスをサーバ１２へ中継するのではなく、多段接続のため、他のプロキシ１７へ中継してもよい。この場合には、多段接続の最終プロキシ１７が最終的にサーバ１２のＩＰアドレス、ポート番号ｘへコネクション確立要求を転送する。
【００２０】
プロキシ１７を介してクライアント１１から複数のコネクション確立要求”ＳＹＮ”を受けたサーバ１２は、ポートｘへのアクセスに対して、これらを並列転送のアプリケーションと認識してそれぞれＴＣＰコネクション１８を確立する。これらは並列転送のためのコネクション１８であるため、同時に複数のＴＣＰコネクション１８の利用を想定して、同一ポートｘに対する複数のコネクション要求を受け付ける。プロキシ１７を経由しているため、この時バインドされるクライアント側のアドレスはプロキシ１７のＩＰアドレスとなる（プロキシ１７が多段接続されている場合は最終段のプロキシ１７のＩＰアドレス）。ＴＣＰコネクション１８の確立要求に対して、サーバ１２は、”ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅの意）”と同時にサーバ１２からクライアント１１側への逆方向のＴＣＰコネクション要求”ＳＹＮ”を送信する。サーバ１２からそれぞれのプロキシ１７に対して送信されたＡＣＫ、ＳＹＮはクライアント１１からサーバ１２への転送中継経路の逆を辿ってクライアント１１へ到着する。
【００２１】
プロキシ１７を介してサーバ１２からのＡＣＫ、ＳＹＮを受け取ったクライアント１１は、ＡＣＫによりプロキシ１７への送信ＴＣＰコネクション１８が確立されたことを知り、またＳＹＮにより、サーバ１２からクライアント１１への逆方向へのＴＣＰコネクション１８の確立要求に対してＡＣＫを返す。これにより、サーバ１２・クライアント１１間にプロキシ１７を介した複数の双方向ＴＣＰコネクション１８が確立されたことにある。以上、ＴＣＰサーバ・クライアント間のコネクション確立にかかるハンドシェイク図を図２に示す。また、図３に本発明による並列転送のプロトコルスタックを示す。図３に示すように、ユーザプログラムがＴＣＰコネクション１８を利用する際のインタフェースを”ソケット”と呼ぶ。
【００２２】
コネクション１８が確立された後、クライアント１１は確立されたＴＣＰコネクション１８の何れかを用いてアクセスするファイル名をサーバ１２に送信する。ファイル名の転送は、クライアント１１側ではＴＣＰソケットへのライトであり、サーバ１２側ではＴＣＰソケットからのリードである。クライアント１１は、コネクション１８が確立された後、ライト可能な、即ちソケットバッファに空きが存在するＴＣＰソケットの何れかを選択し、ファイル名をライトする。サーバ１２側では、リード可能な、即ちソケットバッファが空き状態ではないＴＣＰソケットを選択し、リードする。クライアント１１側、サーバ１２側のプログラムはそれぞれＴＣＰソケットの状態（バッファの空きの有無など）をポーリングしており、ライト可能、リード可能なＴＣＰソケットを選択するようにする。ＴＣＰコネクション１８によるデータの転送中、これを中継するプロキシ１７では転送にかかるＩＰパケットの送り元アドレスをプロキシ１７自身へ、宛先アドレスをプロキシ１７自身のアドレスから中継経路上の次のアドレス（サーバ１２、クライアント１１、あるいは次の中継プロキシ１７のアドレス）へ変更する。
【００２３】
ＴＣＰコネクション１８の何れかによりファイル名を受信したサーバ１２は、自身に格納するファイルにアクセスし、ファイルデータをＴＣＰコネクション１８を通じてクライアント１１へ送信する。サーバ１２のプログラム（以下サーバプログラムと言う。）は、クライアント１１側でファイルデータを再構築できるように、ファイルデータをＴＣＰコネクション１８に送信する際（ＴＣＰソケットへライトする際）、データのファイル上における位置をシーケンス番号としてライトする。サーバプログラムは、ライト可能な（すなわち、ソケットバッファに空きがある）ＴＣＰソケットをポーリングにより識別し、順にファイルデータをシーケンス番号を付与しながらライトしていく。プロキシ１７により中継されたファイルデータがクライアント１１側のＴＣＰソケットに到着するとソケットバッファのデータ量が空き状態から変化する。クライアント１１側のプログラムはポーリングにより、ソケットバッファへのデータの到着を認識し、空きでないソケットバッファから順次ファイルデータを読み出す。データにはシーケンス番号が付与されているため、複数のＴＣＰコネクション１８による並列転送でファイルデータの到着順序が入れ替わった場合でも、クライアント１１側のプログラムはファイルデータの再構築ができる。
【００２４】
本実施形態ではサーバ１２・クライアント１１間のコネクション１８にＴＣＰを用いているため、ネットワーク上でＩＰデータグラムのパケットロスやエラーが発生した場合、再送要求・再送を行い、確実にデータを転送する。転送の発生や、輻輳による遅延などにより、ＴＣＰのスループットは、経路により異なる。サーバ側のプログラムはバッファに空きが発生したＴＣＰソケットをポーリングにより検知し、順次ファイルデータをライトする。パケットの到着を確認するＡＣＫがクライアントから返されなければ、再送の可能性があるためバッファはデータを捨てることができず、バッファは空き状態とならない。すなわち、ライト可能なＴＣＰソケットを順次利用することでそれぞれＴＣＰコネクション１８のスループットに応じてサーバプログラムはファイルデータの転送量を変化させることができる。クライアント１１側では各ＴＣＰコネクション１８毎のスループットを観測できる。そこで、各ＴＣＰコネクション１８のスループットを観測し、更にその合計値が要求条件（動画像ファイルをダウンロードしながら再生する疑似ストリーミングの再生速度等）を満たさない場合、クライアント１１側からの上述の手順により更にＴＣＰコネクション１８の確立要求をサーバ１２側に送信し、あらたにコネクション１８を追加することにより、全体のスループットを改善するという方法も取りうる。
【００２５】
サーバプログラムは全てのファイルデータの転送が終了した後、ライト可能となったＴＣＰソケットに対し、ＥＯＦ（Ｅｎｄ ｏｆ Ｆｉｌｅ）を転送する。クライアント１１側でＥＯＦを受信したＴＣＰソケットはファイルデータの終了と認識し、ＴＣＰコネクション１８をクローズする。全てのコネクション１８がクローズされた場合、ファイルデータは全て受信されたこととなり、クライアント１１側のファイル転送プログラムは終了する。
【００２６】
次に、クライアント・サーバ間の通信データを複数のコネクション１８に分散して送受信する際の、元の通信データと各コネクション１８を通るデータとの関係について説明する。
【００２７】
本実施の形態では、データを誤り訂正符号化により冗長な情報に符号化し、これを複数の経路に分散して転送することにより、経路上のパケットロスやエラーが存在しても、もとのデータを復元できるというものである。例えばサーバ１２では誤り訂正符号としてリードソロモン符号を用いて各々のファイルデータのバイト列情報を符号化し、データＤとチェックサムＣを生成する（チェックサムはＶａｎｄｅｒｍｏｎｄｅ行列Ｆにより算出するものとする）。このとき、上述の例とは異なり、ソケットにＴＣＰではなくＵＤＰを使用することも考えられる。ＵＤＰはＴＣＰと違い、再送メカニズムを持たず、信頼性のある転送を行うことができないが、フローコントロール等の複雑な転送メカニズムを持たないため、簡便で高速な転送が可能である（フローコントロールを行わないため、それぞれのコネクション１８の転送速度については上限を設けるなどして他のＴＣＰフローへの影響を考慮する必要がある）。クライアント１１では各コネクション１８から得られた情報をもとに復号化を行い、もとの情報を復号する。復号化に使う行列はサーバ１２側と同様にＶａｎｄｅｒｍｏｎｄｅ行列である。
【００２８】
符号化・復号化の例を以下に示す。ここではデータ（バイト列）を表現する行列をＤ、チェックサムを表現する行列をＣとして表現する（例では３バイトの情報｛ｄ１，ｄ２，ｄ３｝＝Ｄ、これに対するチェックサム｛ｃ１，ｃ２，ｃ３｝＝Ｃとして表現する。したがって転送経路は｛ｄ１，ｄ２，ｄ３，ｃ１，ｃ２，ｃ３｝を転送するための６経路とする。Ｖａｎｄｅｒｍｏｎｄｅ行列をＦ、対角行列をＩと表現する。符号化・復号化は、それぞれ以下のように表される。この時、Ｆの各要素はガロア体の乗算で求められる。
【００２９】
【数１】
【００３０】
Ｄを３行の行列とすると、
【００３１】
【数２】
【００３２】
である。
【００３３】
いま例として、ｄ１＝３、ｄ２＝１、ｄ３＝９というデータ列を考える（図４参照）。上の式でチェックサムを計算すると、ｃ１＝１１，ｃ２＝９，ｃ３＝１２となる。すなわち、
【００３４】
【数３】
【００３５】
これら合計６つのデータを別々の経路を通じてクライアント１１に送信する。送信途中で仮に３つの経路に障害があり、ｄ２，ｄ３，ｃ３のデータが失われたと仮定する。しかし、クライアント１１側では正常に受信され他３つデータからこれらを復元することができる。具体的には、復号化では届かなかったｄ２，ｄ３，ｃ３に対応する行を上の式から消去すればよく、
【００３６】
【数４】
【００３７】
となる。これからガウスの消去法で逆行列を計算すると、
【００３８】
【数５】
【００３９】
となり、もとのデータｄ１＝３，ｄ２＝１，ｄ３＝９をクライアント１２側で復元することができるというものである。これにより、例え信頼性の低いＵＤＰコネクションを用いたとしても、誤り訂正符号を用いて経路を分散して送信することで、信頼性を向上させることができる。
【００４０】
（第２の実施の形態）
本発明の第２の実施形態にかかるクライアントサーバシステムについて図５を参照して詳細に説明する。図５は第２の実施の形態にかかるクライアントサーバシステムの全体構成図である。なお、図中、第１の実施の形態と同様の構成には同一の符号を付した。
【００４１】
本実施の形態にかかるクライアントサーバシステムが第１の実施の形態と異なる点は、プロキシ１７のアドレスを取得するために、ネームサーバの代わりに負荷分散装置２１を用いる点にある。ネームサーバ２５は通常どおり、サーバ１２の実際のアドレスをクライアント１１に回答する。クライアント１１からの複数のＴＣＰコネクション確立要求は全てサーバ１２のアドレスに向けて送信されるが、この経路上（例えば図５のようにクライアント１１に隣接の位置）に存在する負荷分散装置２１がサーバ１２のＩＰアドレス毎に複数のプロキシ１７のＩＰアドレスを登録しておき、サーバ１２のＩＰアドレス、ポート番号ｘ向けのＴＣＰコネクション要求を複数の異なるプロキシ１７へ経路を分散し、送信する。これにより、ネームサーバ２５にプロキシのアドレスを登録することなく、同一サーバ１２へのＴＣＰコネクション１８の経路を分散させることができる。その他の構成・方法については第１の実施の形態と同様である。
【００４２】
以上本発明の実施形態について説明したが本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲によって示されており、全ての変形例は本発明に含まれるものである。
【００４３】
例えば、上記各実施の形態では、クライアント・サーバ間の全てのコネクションがプロキシを介して形成されているが、コネクションが異なる経路で複数経路で形成できれば、プロキシを介さないコネクションを含んでいてもよい。この場合、プロキシを介さないコネクションについては、従来のルーティングルールにより形成すればよい。
【００４４】
また、上記第２の実施の形態では、負荷分散装置をクライアントの近傍に設けたが他の場所であってもよい。
【００４５】
さらに、上記各実施の形態では、ネットワーク１０としてインターネットを例示したが他のネットワークでもあってもよい。また、データ通信に用いるプロトコルもＴＣＰ／ＩＰ以外のプロトコルであってもよい。
【００４６】
【発明の効果】
以上のように本発明では、サーバ・クライアント間のデータ転送を異なる経路を持つ複数のコネクションにより実現する。このため、１）高速アクセスリンクを用意した場合でもデータ転送経路が１つであるためアクセスリンク速度に見合った高スループットが得られない、２）経路上の一部のリンクが輻輳や障害があった場合に直接その影響を受ける、といった問題点を改善することができる。また、経路を分散させることにより、個別のコネクションが低スループットであっても全体で高スループットを実現でき、更に誤り訂正符号を用いるなど冗長な情報を経路を分散させて転送させることで、従来の１ルートのみによる転送に比べて信頼性を向上させることができる。
【図面の簡単な説明】
【図１】第１の実施形態にかかるクライアントサーバシステムの構成図
【図２】サーバ・クライアント間のコネクション確立にかかるハンドシェイク図
【図３】並列転送のプロトコルスタックを説明する図
【図４】複数の経路における障害が発生した場合の処理を説明する図
【図５】第２の実施形態にかかるクライアントサーバシステムの構成図
【図６】従来のネットワークにおける通信経路を説明する図
【符号の説明】
１０…ネットワーク、１１…クライアント、１２…サーバ、１３…ルータ、１４…アクセスリンク、１５、２５…ネームサーバ、１６…リンク、１７…プロキシ、１８…コネクション、２１…負荷分散装置
【発明の属する技術分野】
本発明は、クライアントサーバシステムに関するものである。
【０００２】
【従来の技術】
インターネットに代表されるＴＣＰ／ＩＰプロトコルスイートを用いたネットワーク上のクライアントサーバシステムでは、サーバのアドレス、ポート番号とクライアントのアドレス、ポート番号との間でコネクションの確立が行われた後、これらの間のデータのやりとりはＩＰデータグラムというパケットに分割されて、インターネット上を転送させる。インターネットではルータがＩＰデータグラムに付与された宛先ＩＰアドレスを確認し、それぞれルータが持つ経路テーブルに基づいてパケットが転送され、サーバ、クライアント間のデータのやりとりが行われる。現状、ルータは経路テーブルをＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆａｓｔ）等のルーティングプロトコルを用いてメンテナンスしている。ＯＳＰＦなどのルーティングプロトコルでは自分に隣接するルータまでのコスト（通常はインタフェイス速度の逆数）をＬＳＡ（Ｌｉｎｋ Ｓｔａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔ）として自分に隣接するルータに広告通知する。この広告通知されたＬＳＡにより各ルータは経路テーブルを構築する。この経路テーブルを用いることで宛先ＩＰアドレスに対し、最小コストの経路が選択され、ルータから転送される。したがって障害などによる経路情報の変化がなければ、任意のＩＰアドレス間のデータ転送経路は一意に定まり、常にこの経路をパケットが通過することになる。
【０００３】
従来のクライアントサーバシステムにおけるファイルデータ転送について、以下に説明する。まず、従来のルータ装置の構成について図６を参照して説明する。
【０００４】
図６は、従来のクライアントサーバシステムにおけるファイルデータ転送の例を示す図である。符号１はクライアント、２はサーバ、３はルータ、４はアクセスリンク、５はネームサーバ、６はインタネット上のリンクである。
【０００５】
例として、クライアント１がｆｔｐ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｃｏｌ）を用いてサーバ２からファイルを転送する場合を取り上げる。クライアント１は、まず、ｆｒｐのためのＴＣＰコネクションをサーバ２との間で確立する。次に、クライアント１は、ネームサーバ５へサーバ２のアドレスを問い合わせる。そして、ネームサーバ５より回答されたサーバ２のＩＰアドレスに対し、クライアント１はｆｔｐのためのＴＣＰのコネクションを確立し、ｆｔｐのコマンド等をサーバ２との間でやりとりする。確立されたＴＣＰコネクション上のデータは、ＩＰデータグラム（パケット）に（必要があれば分割されて）格納され、アクセスリンク４，ルータ３，ルータ間を結ぶリンク６を介してクライアントサーバ間をやりとりされる。この時、サーバ、クライアント間のパケットが流れる経路は各ルータによって選択されるがＯＳＰＦなどのルーティングプロトコルは最小コスト経路を常に選択するため、障害などでリンクが不通となっている場合などを除いて常に同一経路が選択されて転送される。
【０００６】
【発明が解決しようとする課題】
上記のように従来のクライアントサーバシステムでは、データのやりとりにインターネット上の一つの経路が利用される。画像などのマルチメディアアプリケーションや大きなファイルの転送のように高速でのデータのやり取りが必要なユーザはＡＤＳＬやケーブルモデム、ＦＴＴＨといった高速のアクセスリンクを契約し、クライアントサーバ間で高速データ転送を試みる。しかし、アクセスリンクが高速であってもインターネット上の経路は一定であり、他のパケットとそれぞれのリンクでの使用可能帯域をシェアすることになる。このため、サーバ・クライアント間のスループットは経路上のリンクの最小帯域に制限される。また、経路上の何れかのリンクが混雑していれば、他のリンクが空いていたとしても迂回することができず、他のパケットと同様にスループットの低下を招いてしまう。このように従来のクライアントサーバシステムではサーバ・クライアント間に最小コスト経路が設定されてしまうため、アクセスリンクに高速リンクを用意したとしてもサーバクライアント間に高スループットを期待することができず、また混雑時の迂回や障害を避けるために最小コスト以外の経路による冗長な転送が不可能であった。
【０００７】
本発明は、上記事情に鑑みてなされたものであり、その目的とするところは、高速アクセスリンクを持つクライアントサーバシステムのスループットを向上させ、またネットワークの混雑時や障害時のスループット低下を改善するクライアントサーバシステムを提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、本発明では、サーバ・クライアント間に複数の異なる経路のコネクションを確立し、該コネクション上でデータ通信を行うものを提案する。また、サーバ・クライアント間のデータ通信は、両者間で直接データをやり取りするのではなく、コネクション毎にプロキシによりサーバ・クライアント間のデータ転送を中継する方法を提案する。本発明によれば、一つのアプリケーションに対し、複数のコネクションを同時に利用し、更にそれぞれの経路を変更することでサーバ・クライアント間のスループット向上を図り、混雑や障害によるスループット低下を改善する。
【０００９】
さらに、本発明では、中継するプロキシを一段ではなく、多段接続するものを提案する。これは、一端経路が分散された複数のコネクションが同一リンク上を通過することを防ぐことを目的としており、経路分散を確実にすることでスループット向上を図る。
【００１０】
さらに、本発明では、ネームサーバの変わりに負荷分散装置を用いて各コネクションを中継するプロキシを選択するものを提案する。ネームサーバに特定サーバのアドレスとして複数のプロキシのアドレスを登録しておくのではなく、通常どおりのサーバのアドレスを格納しておく。サーバ・クライアント間の経路上、例えばクライアントの隣接する位置に負荷分散装置を設置し、同一のサーバへの複数コネクション（クライアントのポート番号が異なるため識別可能）によるアクセスをそれぞれ異なるプロキシへ振ることにより経路を分散させる。
【００１１】
さらに、本発明では、サーバ・クライアント間の経路分散化されたコネクションをデータ転送に信頼性向上の目的で、データを誤り訂正符号化する方法を提案する。サーバ側で誤り訂正符号化し、クライアント側で復号化することにより、一部の経路上に障害が生じた場合でも、もとのデータを復元することができる。
【００１２】
【発明の実施の形態】
（第１の実施の形態）
本発明の第１の実施形態にかかるクライアントサーバシステムについて図面を参照して詳細に説明する。
【００１３】
図１は本発明の実施形態にかかるネットワークの構成図である。図中、１０はネットワーク、１１はクライアント、１２はサーバ、１３はルータ、１４はアクセスリンク、１５はネームサーバ、１６はネットワーク上のリンク、１７はプロキシ、１８はコネクションである。ここで、ネットワーク１０としては、例えばインターネットなどのＴＣＰ／ＩＰプロトコルスイートを用いたネットワークを用いた。また、アクセスリンク１４、リンク１６はコネクション１８の下位の層である。本実施の形態ではネットワーク１０としてＴＣＰ／ＩＰを用いてるので、ＩＰ層以下に相当するものでありＯＳＩ参照モデルのネットワーク層以下にほぼ相当する。また、本実施の形態では、コネクション１８はＴＣＰ／ＵＤＰ層でありＯＳＩ参照モデルのトランスポート層にほぼ相当する。
【００１４】
本実施の形態ではサーバからクライアントへのファイル転送を例として説明する。また、ここでは、並列経路を使ってファイルを転送するアプリケーションを想定し、このアプリケーションのためのサーバ側のポート番号ｘがクライアント側で既知であるとする。
【００１５】
クライアント１１は、ｆｔｐと同様にサーバ１２のポート番号ｘへのコネクション１８を確立するため、ネームサーバ１５へサーバ１２のＩＰアドレスを問い合わせる。この時、ネームサーバ１５には、実際のサーバ１２のＩＰアドレスではなく、サーバ・クライアント間のデータ転送を中継するプロキシ１７のアドレスが格納されており、ネームサーバ１５はこれをサーバ１２のＩＰアドレスへの問い合わせに対する回答として答える。クライアント１１は、サーバのポート番号ｘに対して複数のＴＣＰコネクション１８を確立しようとし、そのたびにネームサーバ１５へＩＰアドレスを問い合わせる。
【００１６】
ネームサーバ１５は複数登録されているプロキシ１７のアドレスを例えばラウンドロビンなどのルールで順次クライアント１１へ回答する。具体的にはネームサーバ１５にはサーバ１２のアドレス（例えばsss.sss.sss.sss）の代わりに、以下のようにプロキシサーバのＩＰアドレスがＡレコードとして加えられている。 servername A xxx.xxx.xxx.xxx(第１のプロキシのＩＰアドレス)
servername A yyy.yyy.yyy.yyy(第２のプロキシのＩＰアドレス)
servername A zzz.zzz.zzz.zzz(第３のプロキシのＩＰアドレス)
これにより、ネームサーバ１５はクライアント１１からのＩＰアドレスの問い合わせに対して、サーバ１２のＩＰアドレスではなく、プロキシ１５のＩＰアドレスを問い合わせ順にラウンドロビンで回答する。
【００１７】
ネームサーバ１５からＩＰアドレスの返答を受けたクライアント１１はサーバへ１２のＴＣＰコネクション１８の確立要求”ＳＹＮ（Ｓｙｎｃｈｒｏｎｉｚｅの意）”をコネクション１８ごとに異なるプロキシ１７のポート番号ｘへ送信する。
【００１８】
各プロキシ１７は、ポート番号ｘへのアクセスを並列転送であると認識し、サーバ１２のＩＰアドレス、ポート番号ｘへ中継する。すなわち、プロキシ１７には、クライアント１１からのアクセスをサーバ１２へ中継するために予めＴＣＰデリゲイトが設定されている。例えば、「ｄｅｌｅｇａｔｅｄ」というプロキシプログラムを用いる場合、
delegated -P5000 SERVER=tcprelay://sss.sss.sss.sss:6000
という設定がなされている。ここで、sss.sss.sss.sssはサーバ１２のＩＰアドレス、6000はサーバ１２における並列転送のためのポート番号であるとする。また、5000はプロキシ１７のポート番号ｘで、クライアント１１から5000番のＴＣＰポートにアクセスされた場合、クライアント１１からのアクセスをサーバ１２に中継するという意味である。プロキシ１７は、クライアント１１からアクセスされたポート番号によって中継する先のサーバ１２を識別することができる。
【００１９】
なお、クライアント１１とサーバ１２間のコネクション１８においてプロキシ１７による中継点は２以上あってもよい。すなわち、図１に示すように、一部のプロキシ１７のポート番号ｘへのアクセスをサーバ１２へ中継するのではなく、多段接続のため、他のプロキシ１７へ中継してもよい。この場合には、多段接続の最終プロキシ１７が最終的にサーバ１２のＩＰアドレス、ポート番号ｘへコネクション確立要求を転送する。
【００２０】
プロキシ１７を介してクライアント１１から複数のコネクション確立要求”ＳＹＮ”を受けたサーバ１２は、ポートｘへのアクセスに対して、これらを並列転送のアプリケーションと認識してそれぞれＴＣＰコネクション１８を確立する。これらは並列転送のためのコネクション１８であるため、同時に複数のＴＣＰコネクション１８の利用を想定して、同一ポートｘに対する複数のコネクション要求を受け付ける。プロキシ１７を経由しているため、この時バインドされるクライアント側のアドレスはプロキシ１７のＩＰアドレスとなる（プロキシ１７が多段接続されている場合は最終段のプロキシ１７のＩＰアドレス）。ＴＣＰコネクション１８の確立要求に対して、サーバ１２は、”ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅの意）”と同時にサーバ１２からクライアント１１側への逆方向のＴＣＰコネクション要求”ＳＹＮ”を送信する。サーバ１２からそれぞれのプロキシ１７に対して送信されたＡＣＫ、ＳＹＮはクライアント１１からサーバ１２への転送中継経路の逆を辿ってクライアント１１へ到着する。
【００２１】
プロキシ１７を介してサーバ１２からのＡＣＫ、ＳＹＮを受け取ったクライアント１１は、ＡＣＫによりプロキシ１７への送信ＴＣＰコネクション１８が確立されたことを知り、またＳＹＮにより、サーバ１２からクライアント１１への逆方向へのＴＣＰコネクション１８の確立要求に対してＡＣＫを返す。これにより、サーバ１２・クライアント１１間にプロキシ１７を介した複数の双方向ＴＣＰコネクション１８が確立されたことにある。以上、ＴＣＰサーバ・クライアント間のコネクション確立にかかるハンドシェイク図を図２に示す。また、図３に本発明による並列転送のプロトコルスタックを示す。図３に示すように、ユーザプログラムがＴＣＰコネクション１８を利用する際のインタフェースを”ソケット”と呼ぶ。
【００２２】
コネクション１８が確立された後、クライアント１１は確立されたＴＣＰコネクション１８の何れかを用いてアクセスするファイル名をサーバ１２に送信する。ファイル名の転送は、クライアント１１側ではＴＣＰソケットへのライトであり、サーバ１２側ではＴＣＰソケットからのリードである。クライアント１１は、コネクション１８が確立された後、ライト可能な、即ちソケットバッファに空きが存在するＴＣＰソケットの何れかを選択し、ファイル名をライトする。サーバ１２側では、リード可能な、即ちソケットバッファが空き状態ではないＴＣＰソケットを選択し、リードする。クライアント１１側、サーバ１２側のプログラムはそれぞれＴＣＰソケットの状態（バッファの空きの有無など）をポーリングしており、ライト可能、リード可能なＴＣＰソケットを選択するようにする。ＴＣＰコネクション１８によるデータの転送中、これを中継するプロキシ１７では転送にかかるＩＰパケットの送り元アドレスをプロキシ１７自身へ、宛先アドレスをプロキシ１７自身のアドレスから中継経路上の次のアドレス（サーバ１２、クライアント１１、あるいは次の中継プロキシ１７のアドレス）へ変更する。
【００２３】
ＴＣＰコネクション１８の何れかによりファイル名を受信したサーバ１２は、自身に格納するファイルにアクセスし、ファイルデータをＴＣＰコネクション１８を通じてクライアント１１へ送信する。サーバ１２のプログラム（以下サーバプログラムと言う。）は、クライアント１１側でファイルデータを再構築できるように、ファイルデータをＴＣＰコネクション１８に送信する際（ＴＣＰソケットへライトする際）、データのファイル上における位置をシーケンス番号としてライトする。サーバプログラムは、ライト可能な（すなわち、ソケットバッファに空きがある）ＴＣＰソケットをポーリングにより識別し、順にファイルデータをシーケンス番号を付与しながらライトしていく。プロキシ１７により中継されたファイルデータがクライアント１１側のＴＣＰソケットに到着するとソケットバッファのデータ量が空き状態から変化する。クライアント１１側のプログラムはポーリングにより、ソケットバッファへのデータの到着を認識し、空きでないソケットバッファから順次ファイルデータを読み出す。データにはシーケンス番号が付与されているため、複数のＴＣＰコネクション１８による並列転送でファイルデータの到着順序が入れ替わった場合でも、クライアント１１側のプログラムはファイルデータの再構築ができる。
【００２４】
本実施形態ではサーバ１２・クライアント１１間のコネクション１８にＴＣＰを用いているため、ネットワーク上でＩＰデータグラムのパケットロスやエラーが発生した場合、再送要求・再送を行い、確実にデータを転送する。転送の発生や、輻輳による遅延などにより、ＴＣＰのスループットは、経路により異なる。サーバ側のプログラムはバッファに空きが発生したＴＣＰソケットをポーリングにより検知し、順次ファイルデータをライトする。パケットの到着を確認するＡＣＫがクライアントから返されなければ、再送の可能性があるためバッファはデータを捨てることができず、バッファは空き状態とならない。すなわち、ライト可能なＴＣＰソケットを順次利用することでそれぞれＴＣＰコネクション１８のスループットに応じてサーバプログラムはファイルデータの転送量を変化させることができる。クライアント１１側では各ＴＣＰコネクション１８毎のスループットを観測できる。そこで、各ＴＣＰコネクション１８のスループットを観測し、更にその合計値が要求条件（動画像ファイルをダウンロードしながら再生する疑似ストリーミングの再生速度等）を満たさない場合、クライアント１１側からの上述の手順により更にＴＣＰコネクション１８の確立要求をサーバ１２側に送信し、あらたにコネクション１８を追加することにより、全体のスループットを改善するという方法も取りうる。
【００２５】
サーバプログラムは全てのファイルデータの転送が終了した後、ライト可能となったＴＣＰソケットに対し、ＥＯＦ（Ｅｎｄ ｏｆ Ｆｉｌｅ）を転送する。クライアント１１側でＥＯＦを受信したＴＣＰソケットはファイルデータの終了と認識し、ＴＣＰコネクション１８をクローズする。全てのコネクション１８がクローズされた場合、ファイルデータは全て受信されたこととなり、クライアント１１側のファイル転送プログラムは終了する。
【００２６】
次に、クライアント・サーバ間の通信データを複数のコネクション１８に分散して送受信する際の、元の通信データと各コネクション１８を通るデータとの関係について説明する。
【００２７】
本実施の形態では、データを誤り訂正符号化により冗長な情報に符号化し、これを複数の経路に分散して転送することにより、経路上のパケットロスやエラーが存在しても、もとのデータを復元できるというものである。例えばサーバ１２では誤り訂正符号としてリードソロモン符号を用いて各々のファイルデータのバイト列情報を符号化し、データＤとチェックサムＣを生成する（チェックサムはＶａｎｄｅｒｍｏｎｄｅ行列Ｆにより算出するものとする）。このとき、上述の例とは異なり、ソケットにＴＣＰではなくＵＤＰを使用することも考えられる。ＵＤＰはＴＣＰと違い、再送メカニズムを持たず、信頼性のある転送を行うことができないが、フローコントロール等の複雑な転送メカニズムを持たないため、簡便で高速な転送が可能である（フローコントロールを行わないため、それぞれのコネクション１８の転送速度については上限を設けるなどして他のＴＣＰフローへの影響を考慮する必要がある）。クライアント１１では各コネクション１８から得られた情報をもとに復号化を行い、もとの情報を復号する。復号化に使う行列はサーバ１２側と同様にＶａｎｄｅｒｍｏｎｄｅ行列である。
【００２８】
符号化・復号化の例を以下に示す。ここではデータ（バイト列）を表現する行列をＤ、チェックサムを表現する行列をＣとして表現する（例では３バイトの情報｛ｄ１，ｄ２，ｄ３｝＝Ｄ、これに対するチェックサム｛ｃ１，ｃ２，ｃ３｝＝Ｃとして表現する。したがって転送経路は｛ｄ１，ｄ２，ｄ３，ｃ１，ｃ２，ｃ３｝を転送するための６経路とする。Ｖａｎｄｅｒｍｏｎｄｅ行列をＦ、対角行列をＩと表現する。符号化・復号化は、それぞれ以下のように表される。この時、Ｆの各要素はガロア体の乗算で求められる。
【００２９】
【数１】
Ｄを３行の行列とすると、
【００３１】
【数２】
である。
【００３３】
いま例として、ｄ１＝３、ｄ２＝１、ｄ３＝９というデータ列を考える（図４参照）。上の式でチェックサムを計算すると、ｃ１＝１１，ｃ２＝９，ｃ３＝１２となる。すなわち、
【００３４】
【数３】
これら合計６つのデータを別々の経路を通じてクライアント１１に送信する。送信途中で仮に３つの経路に障害があり、ｄ２，ｄ３，ｃ３のデータが失われたと仮定する。しかし、クライアント１１側では正常に受信され他３つデータからこれらを復元することができる。具体的には、復号化では届かなかったｄ２，ｄ３，ｃ３に対応する行を上の式から消去すればよく、
【００３６】
【数４】
となる。これからガウスの消去法で逆行列を計算すると、
【００３８】
【数５】
となり、もとのデータｄ１＝３，ｄ２＝１，ｄ３＝９をクライアント１２側で復元することができるというものである。これにより、例え信頼性の低いＵＤＰコネクションを用いたとしても、誤り訂正符号を用いて経路を分散して送信することで、信頼性を向上させることができる。
【００４０】
（第２の実施の形態）
本発明の第２の実施形態にかかるクライアントサーバシステムについて図５を参照して詳細に説明する。図５は第２の実施の形態にかかるクライアントサーバシステムの全体構成図である。なお、図中、第１の実施の形態と同様の構成には同一の符号を付した。
【００４１】
本実施の形態にかかるクライアントサーバシステムが第１の実施の形態と異なる点は、プロキシ１７のアドレスを取得するために、ネームサーバの代わりに負荷分散装置２１を用いる点にある。ネームサーバ２５は通常どおり、サーバ１２の実際のアドレスをクライアント１１に回答する。クライアント１１からの複数のＴＣＰコネクション確立要求は全てサーバ１２のアドレスに向けて送信されるが、この経路上（例えば図５のようにクライアント１１に隣接の位置）に存在する負荷分散装置２１がサーバ１２のＩＰアドレス毎に複数のプロキシ１７のＩＰアドレスを登録しておき、サーバ１２のＩＰアドレス、ポート番号ｘ向けのＴＣＰコネクション要求を複数の異なるプロキシ１７へ経路を分散し、送信する。これにより、ネームサーバ２５にプロキシのアドレスを登録することなく、同一サーバ１２へのＴＣＰコネクション１８の経路を分散させることができる。その他の構成・方法については第１の実施の形態と同様である。
【００４２】
以上本発明の実施形態について説明したが本発明はこれに限定されるものではない。本発明の範囲は特許請求の範囲によって示されており、全ての変形例は本発明に含まれるものである。
【００４３】
例えば、上記各実施の形態では、クライアント・サーバ間の全てのコネクションがプロキシを介して形成されているが、コネクションが異なる経路で複数経路で形成できれば、プロキシを介さないコネクションを含んでいてもよい。この場合、プロキシを介さないコネクションについては、従来のルーティングルールにより形成すればよい。
【００４４】
また、上記第２の実施の形態では、負荷分散装置をクライアントの近傍に設けたが他の場所であってもよい。
【００４５】
さらに、上記各実施の形態では、ネットワーク１０としてインターネットを例示したが他のネットワークでもあってもよい。また、データ通信に用いるプロトコルもＴＣＰ／ＩＰ以外のプロトコルであってもよい。
【００４６】
【発明の効果】
以上のように本発明では、サーバ・クライアント間のデータ転送を異なる経路を持つ複数のコネクションにより実現する。このため、１）高速アクセスリンクを用意した場合でもデータ転送経路が１つであるためアクセスリンク速度に見合った高スループットが得られない、２）経路上の一部のリンクが輻輳や障害があった場合に直接その影響を受ける、といった問題点を改善することができる。また、経路を分散させることにより、個別のコネクションが低スループットであっても全体で高スループットを実現でき、更に誤り訂正符号を用いるなど冗長な情報を経路を分散させて転送させることで、従来の１ルートのみによる転送に比べて信頼性を向上させることができる。
【図面の簡単な説明】
【図１】第１の実施形態にかかるクライアントサーバシステムの構成図
【図２】サーバ・クライアント間のコネクション確立にかかるハンドシェイク図
【図３】並列転送のプロトコルスタックを説明する図
【図４】複数の経路における障害が発生した場合の処理を説明する図
【図５】第２の実施形態にかかるクライアントサーバシステムの構成図
【図６】従来のネットワークにおける通信経路を説明する図
【符号の説明】
１０…ネットワーク、１１…クライアント、１２…サーバ、１３…ルータ、１４…アクセスリンク、１５、２５…ネームサーバ、１６…リンク、１７…プロキシ、１８…コネクション、２１…負荷分散装置
Claims (12)
- ネットワーク上にクライアント・サーバ間のコネクションを確立し、このコネクションを用いてクライアント・サーバ間でデータ通信を行うクライアントサーバシステムにおいて、
クライアントからのサーバの名前解決問い合わせに対してプロキシのアドレスを提供する名前解決手段と、
クライアントからサーバへのコネクション確立要求に対して、前記名前解決手段を用いてサーバの名前からプロキシのアドレスを取得し、ネットワーク上に互いに異なる経路を有する複数のコネクションを、少なくとも１つ以上のコネクションがプロキシを介するように確立するコネクション確立手段と、
送信データを前記複数のコネクションに分散させて送信するとともに複数のコネクションを介して受信した分散データから元のデータを復元する分散化手段とを備えた、
ことを特徴とするクライアントサーバシステム。 - ネットワーク上にクライアント・サーバ間のコネクションを確立し、このコネクションを用いてクライアント・サーバ間でデータ通信を行うクライアントサーバシステムにおいて、
クライアントとサーバとの間に負荷分散装置を介在させ、
該負荷分散装置は、
クライアントからサーバへのコネクション確立要求に対して、予め登録されているプロキシのアドレスを用いて、ネットワーク上に互いに異なる経路を有する複数のコネクションを、少なくとも１つ以上のコネクションがプロキシを介するように確立するコネクション確立手段と、
送信データを前記複数のコネクションに分散させて送信するとともに複数のコネクションを介して受信した分散データから元のデータを復元する分散化手段とを備えた、
ことを特徴とするクライアントサーバシステム。 - 前記コネクション確立手段により確立された複数のコネクションのうち少なくとも１つ以上のコネクションは複数のプロキシを介する
ことを特徴とする請求項１又は２何れか１項記載のクライアントサーバシステム。 - 各コネクションのスループットを観測する手段を備えるとともに、前記コネクション確立手段は前記スループット観測手段で観測された各スループットの合計が所定の要求条件を満たさない場合に新たなコネクションを追加する
ことを特徴とする請求項１乃至３何れか１項記載のクライアントサーバシステム。 - 前記分散化手段は、データを誤り訂正符号化する手段と、誤り訂正符号化されたデータを復号化する手段とを備え、送信データを符号化手段で誤り訂正符号化し、この誤り訂正符号化された送信データを複数のコネクションに分散して送信するとともに、復元されたデータを復号化手段で復号化する
ことを特徴とする請求項１乃至４何れか１項記載のクライアントサーバシステム。 - 前記ネットワークはＴＣＰ／ＩＰプロトコルスイートを用いており、前記コネクションはＴＣＰ層に形成されている
ことを特徴とする請求項１乃至５何れか１項記載のクライアントサーバシステム。 - ネットワーク上にクライアント・サーバ間のコネクションを確立し、このコネクションを用いてクライアント・サーバ間でデータ通信を行うクライアントサーバシステムにおいて、
クライアントからサーバへのコネクション確立要求に対して、名前解決手段を用いてサーバの名前からプロキシのアドレスを取得し、ネットワーク上に互いに異なる経路を有する複数のコネクションを、少なくとも１つ以上のコネクションがプロキシを介するように確立し、
データ通信時には、送信データを前記複数のコネクションに分散させて送信するとともに複数のコネクションを介して受信した分散データから元のデータを復元する
ことを特徴とするクライアントサーバシステムにおけるデータ通信方法。 - ネットワーク上にクライアント・サーバ間のコネクションを確立し、このコネクションを用いてクライアント・サーバ間でデータ通信を行うクライアントサーバシステムにおいて、
クライアントとサーバとの間に介在する負荷分散装置が、クライアントからサーバへのコネクション確立要求に対して、予め登録されているプロキシのアドレスを取得し、ネットワーク上に互いに異なる経路を有する複数のコネクションを、少なくとも１つ以上のコネクションがプロキシを介するように確立し、
データ通信時には、送信データを前記複数のコネクションに分散させて送信するとともに複数のコネクションを介して受信した分散データから元のデータを復元する
ことを特徴とするクライアントサーバシステムにおけるデータ通信方法。 - 前記コネクションの確立時には、少なくとも１つ以上のコネクションが複数のプロキシを介するようにコネクションを確立する
ことを特徴とする請求項７又は８何れか１項記載のクライアントサーバシステムにおけるデータ通信方法。 - 各コネクションのスループットを観測し、スループット観測手段で観測された各スループットの合計が所定の要求条件を満たさない場合に新たなコネクションを追加する
ことを特徴とする請求項７乃至９何れか１項記載のクライアントサーバシステムにおけるデータ通信方法。 - 送信データを符号化手段で誤り訂正符号化し、この誤り訂正符号化された送信データを複数のコネクションに分散して送信するとともに、復元されたデータを復号化手段で復号化する
ことを特徴とする請求項７乃至１０何れか１項記載のクライアントサーバシステムにおけるデータ通信方法。 - 前記ネットワークはＴＣＰ／ＩＰプロトコルスイートを用いており、前記コネクションはＴＣＰ層に形成されている
ことを特徴とする請求項７乃至１１何れか１項記載のクライアントサーバシステムにおけるデータ通信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001306321A JP3785343B2 (ja) | 2001-10-02 | 2001-10-02 | クライアントサーバシステム及びクライアントサーバシステムにおけるデータ通信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001306321A JP3785343B2 (ja) | 2001-10-02 | 2001-10-02 | クライアントサーバシステム及びクライアントサーバシステムにおけるデータ通信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003110604A JP2003110604A (ja) | 2003-04-11 |
| JP3785343B2 true JP3785343B2 (ja) | 2006-06-14 |
Family
ID=19125975
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001306321A Expired - Lifetime JP3785343B2 (ja) | 2001-10-02 | 2001-10-02 | クライアントサーバシステム及びクライアントサーバシステムにおけるデータ通信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3785343B2 (ja) |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7853699B2 (en) | 2005-03-15 | 2010-12-14 | Riverbed Technology, Inc. | Rules-based transaction prefetching using connection end-point proxies |
| WO2005039150A1 (ja) * | 2003-10-22 | 2005-04-28 | Nec Corporation | 通信装置およびその通信方法ならびにプログラム |
| US8484441B2 (en) | 2004-03-31 | 2013-07-09 | Icera Inc. | Apparatus and method for separate asymmetric control processing and data path processing in a configurable dual path processor that supports instructions having different bit widths |
| US7949856B2 (en) | 2004-03-31 | 2011-05-24 | Icera Inc. | Method and apparatus for separate control processing and data path processing in a dual path processor with a shared load/store unit |
| US9047094B2 (en) | 2004-03-31 | 2015-06-02 | Icera Inc. | Apparatus and method for separate asymmetric control processing and data path processing in a dual path processor |
| JP4394541B2 (ja) | 2004-08-23 | 2010-01-06 | 日本電気株式会社 | 通信装置、データ通信方法およびプログラム |
| US20060248194A1 (en) | 2005-03-18 | 2006-11-02 | Riverbed Technology, Inc. | Connection forwarding |
| JP4587053B2 (ja) | 2007-08-28 | 2010-11-24 | 日本電気株式会社 | 通信装置、通信システム、パケット欠落検出方法、およびパケット欠落検出プログラム |
| JP4930856B2 (ja) * | 2008-03-04 | 2012-05-16 | 九州日本電気ソフトウェア株式会社 | 通信システム、ゲートウェイ装置、クライアント装置、コンピュータ名変換方法およびプログラム |
| JP2011139303A (ja) * | 2009-12-28 | 2011-07-14 | Nec Corp | 通信システム、制御装置、通信制御方法、およびプログラム |
| US20140280715A1 (en) * | 2013-03-15 | 2014-09-18 | First Principles, Inc. | Real time remote desktop |
| JP6256904B2 (ja) | 2013-04-18 | 2018-01-10 | インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ | 処理の要求を振り分ける装置及び方法 |
| JP6105163B2 (ja) * | 2013-06-27 | 2017-03-29 | 徐 正 煥ＳＥＯ， Ｊｅｏｎｇ Ｈｏａｎ | インターネットプロトコルを利用したサービスのための多重連結システム及びその方法 |
-
2001
- 2001-10-02 JP JP2001306321A patent/JP3785343B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003110604A (ja) | 2003-04-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10819826B2 (en) | System and method for implementing application functionality within a network infrastructure | |
| US7143169B1 (en) | Methods and apparatus for directing messages to computer systems based on inserted data | |
| JP3785343B2 (ja) | クライアントサーバシステム及びクライアントサーバシステムにおけるデータ通信方法 | |
| US6032193A (en) | Computer system having virtual circuit address altered by local computer to switch to different physical data link to increase data transmission bandwidth | |
| KR100337221B1 (ko) | 중복성 음성/미디어 프레임의 전송에 의한 인터넷 실시간 미디어 전송의 서비스 품질 개선 | |
| US6934257B2 (en) | Transferring transmission control protocol packets | |
| FI107421B (fi) | Yhteyksien valintamenetelmä | |
| US8051185B2 (en) | Network communication through a specified intermediate destination | |
| US20020059451A1 (en) | System and method for highly scalable high-speed content-based filtering and load balancing in interconnected fabrics | |
| US20140317309A1 (en) | System and devices facilitating dynamic network link acceleration | |
| JP2002508133A (ja) | 拡張ネットワーク通信 | |
| CN104539531A (zh) | 数据传输方法及装置 | |
| US20050120140A1 (en) | Method of and system for multi-patch communication | |
| US9137271B2 (en) | System for switching between communication devices, switching method, and switching program | |
| Natarajan et al. | SCTP: An innovative transport layer protocol for the web | |
| US7289433B1 (en) | Method and system for providing robust connections in networking applications | |
| US7945648B2 (en) | Methods and systems for dynamically configuring a network component to reroute media streams | |
| CN103548307A (zh) | 通过计算机网络传输数据的方法和系统 | |
| EP2173077A1 (en) | Shared content addressing protocol | |
| JP2004510394A (ja) | 仮想ｉｐフレームワーク及びインターフェイス接続方法 | |
| US7543072B1 (en) | Method and system capable of performing a data stream over multiple TCP connections or concurrent interleave of multiple data streams over multiple TCP connections | |
| EP1872556A2 (en) | Method for the establishing of connections in a communication system | |
| JP4656415B2 (ja) | 通信装置およびその通信方法ならびにプログラム | |
| Bhagwat et al. | MSOCKS+: an architecture for transport layer mobility | |
| JP3614006B2 (ja) | 非対称経路利用通信システム、および、非対称経路利用通信方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040218 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050413 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050524 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050722 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060314 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060317 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3785343 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090324 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100324 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110324 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110324 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120324 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130324 Year of fee payment: 7 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |