(57)【要約】【課題】クライアント／サーバ・システムにおいて、接続先へのパケット数を抑制することにより、安定したサービスの提供を行うことを目的とする。【解決手段】ネットワークを介して複数のクライアントと通信可能なサーバを備えるクライアント／サーバ・システムであって、前記サーバ内の所定の宛先に対する接続を要求するパケットを受信する受信手段を備え、前記受信手段が、一定時間内に同じ宛先に対する接続を要求するパケットを受信した場合、該パケットに記載されたポイント値を判定し（ステップＳ１００３）、一定時間内に同じ宛先に対する接続を要求するパケットのうちのいずれかを選択し、送信する（ステップＳ１００５）ことを特徴とする。【選択図】  図１０
2004220378.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して複数のクライアントと通信可能なサーバを備えるクライアント／サーバ・システムであって、
前記サーバ内の所定の宛先に対する接続を要求する接続要求情報を受信する受信手段と、
前記受信手段により、一定時間内に同じ宛先に対する接続を要求する接続要求情報が受信された場合に、該接続要求情報に記載された属性を識別する識別手段と、
前記識別手段により識別された属性に基づいて、前記一定時間内に同じ宛先に対する接続を要求する接続要求情報のうちのいずれかを選択する選択手段と、
前記選択手段により選択された接続要求情報を送信する送信手段と
を備えることを特徴とするクライアント／サーバ・システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、クライアント／サーバ・システムにおいて、コネクション指向のデータ通信を行う技術に関するものである。
【０００２】
【従来の技術】
通常、ＴＣＰなどコネクション型のネットワークを利用して相手ホスト（サーバホスト）とデータ通信をする場合には、サーバホストへ接続要求のパケットを送信することから始まる。サーバホストが接続要求パケットを受け付けると接続が確立される。例えば、ウェブサーバにアクセスするウェブブラウザはＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を使って通信するが、ＨＴＴＰはＴＣＰ／ＩＰの上位層のプロトコルであるため、実際にはＴＣＰのコネクションを各ホストのアプリケーション間で接続する必要がある。ＴＣＰの接続が完了した後、ウェブサーバのコンテンツデータ（データパケット）が転送されることになる。上述したＴＣＰ／ＩＰプロトコルおよびＨＴＴＰプロトコルについては、ＩＡＢ（Ｉｎｔｅｒｎｅｔ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｂｏａｒｄ）により発行されている下記ＲＦＣ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ）で詳細に記述されている。
【０００３】
【非特許文献１】
ＲＦＣ７９１（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）
【非特許文献２】
ＲＦＣ７９３（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）
【非特許文献３】
ＲＦＣ２６１６（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）
【０００４】
【発明が解決しようとする課題】
しかしながら、ネットワークのトラフィックが混んでいる状況では、往々にして接続要求のパケットは途中で失われる可能性がある。これは、発信元ホストから接続先ホストへの経路中のルータあるいはホストで、パケットを処理しきれず取りこぼすのが一つの原因である。また、サーバホストに多くのクライアントホストから接続要求が来るような状況では、接続数がサーバホストの資源の限界を越えるため、新たな接続要求を受け入れることができず接続要求を拒否するような状況がおこる。
【０００５】
このような状況においては、接続要求パケットのトラフィックにより、既に接続済みのコネクションにおけるデータパケットもトラフィックの影響を受け転送レートが下がってしまったり、あげくの果てには接続を切断する結果になる場合もある。これらはネットワーク上の全てのパケットをわけ隔てなく公平に扱うというインターネットのあり方のポリシーに基づいているがゆえに起き得る現象と言える。
【０００６】
本発明は、上記課題を鑑みてなされたものであり、コネクション型通信を行うクライアント／サーバ・システムにおいて、接続先へのパケット数の送信を抑制することにより、安定したサービスの提供を行うことを目的とする。
【０００７】
【課題を解決するための手段】
上記の目的を達成するために本発明に係るクライアント／サーバ・システムは以下のような構成を備える。即ち、
ネットワークを介して複数のクライアントと通信可能なサーバを備えるクライアント／サーバ・システムであって、
前記サーバ内の所定の宛先に対する接続を要求する前記クライアントからの接続要求情報を受信する受信手段と、
前記受信手段により、一定時間内に同じ宛先に対する接続を要求する接続要求情報が受信された場合に、該接続要求情報に記載された属性を識別する識別手段と、
前記識別手段により識別された属性に基づいて、前記一定時間内に同じ宛先に対する接続を要求する接続要求情報のうちのいずれかを選択する選択手段と、
前記選択手段により選択された接続要求情報を送信する送信手段とを備える。
【０００８】
かかる構成により、従来の絶対的な公平さの他に、競争原理による公平さをネットワークに持ち込むことが可能となる。具体的には、クライアントホストから送信する接続要求のパケットに、他のパケットと競り合うための情報を利用者の指示に従って設定し、ルータなどの中継点およびサーバホストにて、同一の宛先に対する接続要求パケットを一定時間保持し、保持されたパケットの「競り」情報からいくつかのパケットを公平なルールに従って取捨選択し、選択されたパケットのみを当該宛先に送信することが可能となる。その結果、いわば「競り勝った」パケットのみが最終的な接続先であるサーバホストへ転送され、接続処理が可能となる。
【０００９】
このように、各中継点毎に競り負けたパケットは破棄され、サーバホストへは限られた数のパケットのみが到達することになるため、トラフィックの過負荷を避けることができ、また、接続を達成できたクライアントホストには安定したサービスを提供することができる。
【００１０】
【発明の実施の形態】
【第１の実施形態】
はじめに本実施形態の概要を説明する。本実施形態では、サービスを提供するサーバホストに接続したい利用者がそのサーバホストから予め持ち点をもらい、接続時にはその持ち点以内の任意のポイントを利用者が設定した接続要求パケットを送出するものである。ポイントが設定されている接続要求パケットは通信経路上の各ルータにおいて、同一サーバホスト宛で同時期に到着した他のクライアントの接続要求パケットとポイントの大小比較を行ない、ポイントが勝っているものがルータを通過でき、劣っているパケットはその時点で破棄される。最終的になサーバホストにたどり着き接続できたパケットのクライアントの持ち点は接続要求パケットに設定されているポイント分減らされる。持ち点がなくなった時点で接続の権利はなくなる。
【００１１】
サーバホストへ接続を試みたい利用者の思惑としては、なるべく持ち点を減らさずに接続したいが、設定するポイントが少ないと他のクライアントのパケットに負けて接続できない状況になる。もし、接続できなければ、設定するポイントを上げて再接続を試みるであろう。そして、接続の欲求が低ければ、ある段階で接続を諦めるであろうし、接続の欲求が高ければ、接続できるまでどんどんポイント高く設定することもあるだろう。このようにサーバホストへの接続をめぐって一種の「競り」の状態を作り、各クライアントの駆引きを通じて接続が達成される。
【００１２】
以下、本実施形態の詳細をクライアントホスト、ルータ、サーバホストの各々について、説明する。
【００１３】
図１は、クライアントホストの構成を示した図である。
【００１４】
１０１はクライアントのコンピュータおよびそれに類するネットワーク機器である。１０２は、ネットワークを介してサーバホストにアクセスするアプリケーションソフトウェアである。例えばウェブブラウザなどのアプリケーションソフトウェアである。１０３はＯＳである。
【００１５】
１０４はネットワークプロトコルスタック、例えばＴＣＰ／ＩＰプロトコルスタックであり、アプリケーションとのＩ／Ｆ（ＡＰＩ）として、インターネットの分野でよく知られたＢｅｒｅｋｌａｙ  ｓｏｃｋｅｔ  Ｉ／Ｆ（ＢＳＤソケットＩ／Ｆともいう）（１０５）を有するものとする。
【００１６】
また、プロトコルスタック内には、各通信端点の情報を保持するためのソケット情報テーブル１０６を持つ。例えば、ソケットの送信元、送信先のＩＰアドレスやポート番号、タイムアウトの値などＴＣＰ／ＩＰを駆動する上で必要なメンバ変数を保持している。本発明ではかかる通常のメンバ変数の他にさらにポイントメンバ変数１０７を持つ。１０８はネットワークインターフェース、例えばイーサネット（登録商標）などのドライバである。１０９は通信線、例えば、イーサネット（登録商標）ケーブルである。
【００１７】
図２はクライアントホストの処理フロー図である。
【００１８】
ステップＳ２０１ではまず通信端点であるソケットを生成する。通常、ＢＳＤソケットＩ／Ｆではｓｏｃｋｅｔ（）システムコールを呼ぶことにより生成される。なお、この時ソケット情報テーブル１０６内のポイントメンバ変数１０７は０に初期化される。
【００１９】
次にステップＳ２０２ではポイントの設定を行なう。利用者が所望のポイントを引数にｓｅｔ＿ｐｏｉｎｔ（）関数を呼ぶ。所望のポイントはアプリケーション（例えば、ウェブブラウザ）のＧＵＩにポイントを指定できるフィールドを設け、接続に先立ち利用者にポイント数を指定してもらうことによって容易に得ることができる。このｓｅｔ＿ｐｏｉｎｔ（）関数は本発明を実現するために新たに設けるシステムコールである（なお、関数名に本質的な意味はない）。関数の詳細は次のような形式である。
【００２０】
ｓｅｔ＿ｐｏｉｎｔ（ｓｄ、ｐｏｉｎｔ）    関数（１）
ｓｄはｓｏｃｋｅｔ（）システムコールで得られたソケットを表す整数値である。また、ｐｏｉｎｔは、そのソケットの相手への接続に使用されるポイント数である。この関数が呼ばれると、ソケット情報テーブル１０６内のポイントメンバ変数１０７に関数の引数で与えられたｐｏｉｎｔの値を設定する。
【００２１】
ステップＳ２０３では、ＢＳＤソケットＩ／Ｆのｃｏｎｎｅｃｔ（）システムコールを呼び、ＴＣＰの接続を試みる。このｃｏｎｎｅｃｔ（）システムコール内では、先のポイントメンバ変数１０７の値に応じて従来方式のパケットを送出するか、「競り」用のパケットを送出するかを切替える。詳細については後述する。
【００２２】
ステップＳ２０４でｃｏｎｎｅｃｔ（）システムコールの返り値により接続が成功したか否かの判断をし、もし成功したならば、データ通信を行なって（ステップＳ２０５）、その後、ｃｌｏｓｅ（）システムコールにてＴＣＰ接続を切断し、通信端点を開放する（ステップＳ２０６）。一方、ｃｏｎｎｅｃｔ（）コールが失敗した場合には、ステップＳ２０７で再接続するかどうかを判断する。これは利用者に指示を仰ぐ。もし、再接続を指示された場合にはステップＳ２０２に戻り、利用者がポイントを再設定して、接続処理を再度行なうこととなる。一方、中止を指示された場合にはステップＳ２０６でクローズ処理を行なう。この場合には通信端点の開放のみを行うこととなる。
【００２３】
次に前述したステップＳ２０３のｃｏｎｎｅｃｔ（）コールについて詳細を説明する。まず一般的なｃｏｎｎｅｃｔ（）の動作についてその概要を説明する。
【００２４】
ＢＳＤソケットＩ／Ｆのｃｏｎｎｅｃｔ（）システムコールは次のような形式の関数である。
【００２５】
ｃｏｎｎｅｃｔ（ｓｄ、ａｄｄｒｅｓｓ、ａｄｄｒｅｓｓｌｅｎ）    関数（２）
ｓｄはソケット（通信端点）を表す。また、第２引数および第３引数において、接続先のＩＰアドレスおよびポート番号を指定する。
【００２６】
ＴＣＰの仕様（ＲＦＣ７９３）によれば、この関数が呼ばれると、ＴＣＰは３つのパケットの送受信により接続を確立する。まず、クライアントホストから接続要求のＳＹＮパケットを送信し、サーバホストが接続を許可するとサーバはＳＹＮ＋ＡＣＫのパケットを返す。その応答としてＡＣＫパケットをクライアントホストが返す。このようなクライアントホストとサーバホストとのやりとりが完了するとｃｏｎｎｅｃｔ関数が戻る仕様になっている。もし、接続先がなかったり、接続が拒否されて接続が失敗した場合には、その関数の戻り値によりわかるようになっている。
【００２７】
本実施形態では、最初にクライアントホストから送出されるＳＹＮパケットにルータに「競り」をさせるための付加情報を設ける。その後のＳＹＮ＋ＡＣＫパケットおよびＡＣＫパケットは従来の形式と変わらず、またその送出方法も従来のものと変わらずに用いることができる。
【００２８】
図３はｃｏｎｎｅｃｔ（）システムコール内で最初のＳＹＮパケットを送出するフロー図である。
【００２９】
まずステップＳ３０１でＴＣＰヘッダを作成する。ＴＣＰヘッダはＲＦＣ７９３に規定されているものであり、その形式を図４に示す。ＴＣＰヘッダの各項目を仕様に則り設定する。例えば、発信元ポート番号、宛先ポート番号、シーケンス番号、ヘッダ長、制御フラグ（ＵＲＧ、ＡＣＫ・・等）、ウィンドウサイズなどである。ここで設定するＴＣＰヘッダの値は既存の実装で行なう方法となんら変わりがないため詳細説明は省略する。このパケット（ＳＹＮパケット）はＴＣＰの接続要求パケットであるため、ヘッダ項目の制御フラグは、ＳＹＮフラグが１、ＡＣＫフラグが０になっている。
【００３０】
次にステップＳ３０２でＩＰヘッダを作成する。ＩＰヘッダはＲＦＣ１８８３によると図５のような形式になっている。“次ヘッダ番号”（５０１）には、ＩＰヘッダの次にＴＣＰヘッダが続くように、ＴＣＰのプロトコル番号“６”を入れておく。
【００３１】
ステップＳ３０３では、この通信端点のポイント値が０以上で、かつ、作成しているパケットがＴＣＰの接続要求パケットかどうかを判定する。このソケットにおけるポイント値はソケット情報テーブル１０６内のポイントメンバ変数１０７に保持されているのでその値を参照することにより判定できる。また、接続要求パケットかどうかは、まず、ＴＣＰのパケットであるかどうかをパケットの拡張ヘッダチェーンを辿って捜し、ＴＣＰのパケットであり、かつＴＣＰヘッダを有している場合に、その制御フラグのＳＹＮフラグとＡＣＫフラグを見ることにより判定できる。
【００３２】
ポイント値が０であった場合、通常のパケットの送信と同じなので、作成されたＳＹＮパケットをイーサネット（登録商標）ドライバ１０８に渡し、イーサ（登録商標）ネットドライバ１０８はステップＳ３０５でＳＹＮパケットを送出する。一方、ポイント値に０以外が設定されていて、かつ、ＴＣＰの接続要求パケットであるならば、ステップＳ３０４で、「競り」のためのポイント情報をＳＹＮパケットに付加する。
【００３３】
ポイント情報には、ＩＰ拡張ヘッダの一つに規定されている、中継点オプション・ヘッダを利用する。ステップＳ３０４では、ステップＳ３０２で作成されたＩＰヘッダ、続いて、中継点オプション・ヘッダ、そして、ＴＣＰヘッダの順に並ぶようにパケットを生成する。従って、ステップＳ３０２で作成されたＩＰヘッダの次ヘッダ番号の“６”をやめ、中継点オプション・ヘッダの拡張ヘッダ番号である“０”に入れ替えておく。
【００３４】
図６は中継点オプション・ヘッダの形式である。次ヘッダ番号６０１はＩＰヘッダのそれと同じ性質のものである。今度はこの次にＴＣＰヘッダがくることになるので、ＴＣＰのプロトコル番号である“６”を値として設定する。オプション・データ長６０４はオプション・データ・フィールドのバイト数をいれることになっている。この場合、４バイトを使用することにし、“４”を設定する。拡張ヘッダ長６０２は、この場合拡張ヘッダのサイズが８バイトであるので、仕様に基づくと“０”になる。オプション番号記述子６０３は、オプションの種類を表す数字である。これはＩＡＮＡ（Ｉｎｔｅｒｎｅｔ  Ａｓｓｉｇｎｅｄ  Ｎｕｍｂｅｒｓ  Ａｕｔｈｏｒｉｔｙ）への登録によって仕様化されるものであるため、本実施形態で提案するオプションは未だ規定外である。従って、いままでに登録されている以外の値を使用することとする。この値を仮に”ＯｐｔＡ”と表記することとする。オプション・データ・フィールド６０５には、ステップＳ２０２で設定されたポイントメンバ変数１０７の値を設定する。
【００３５】
このようにポイント値を持つＳＹＮパケットが作成された後は、ステップＳ２０６でイーサネット（登録商標）から接続先ホストへ向けて送出される。
【００３６】
以上がクライアントホストの動作の説明である。これにより、利用者の意思によって設定されたポイント値を持ったＴＣＰの接続要求パケットであるＳＹＮパケットを送出することができる。
【００３７】
次に中継点であるルータ（中継装置）の動作の説明に移る。
【００３８】
ルータはパケットの発信元ホストと宛先ホストとの間に存在する可能性のあるものである。通常ルータは、受信したパケットを最終宛先ホストへ届けるために最も適切な次のルータに転送する役目を持つ。本実施形態では、本来のルータの機能に加え、受信したパケットがポイント値付きパケットかどうかの判定をし、もしそうであるなら、同じ宛先ホストを持つパケットを一定期間保持して、集まったパケット間でポイント値により勝敗を決定する。勝ち残ったパケットのみが次のルータあるいはホストへと転送され、残りのパケットはこのルータで破棄されるものである。
【００３９】
図７は本実施形態のルータの構成図である。
【００４０】
７０１はＣＰＵ、７０２はＲＯＭで、ルータに必要なＩＰプロトコルスタック、イーサネット（登録商標）ドライバなどのプログラムが格納されている。７０３はＲＡＭで、パケットを転送するための経路テーブルやプログラム実行に必要な変数などを保持する。７０４はイーサネット（登録商標）コントローラ、７０５はイーサネット（登録商標）の送受信バッファ、７０６はタイマー、７０７は宛先別パケットキュー、７０８は通信線、７０９はバスである。
【００４１】
まずポイント付きパケットでない場合の動作を簡単に説明する。パケットが受信されると受信バッファ７０５に格納され、一パケット分データが揃うとイーサネット（登録商標）コントローラ７０４がＣＰＵ７０１に割込みをあげる。ＣＰＵはパケットのＩＰヘッダを解析し、指定された宛先ＩＰアドレスに対応する最も適切なイーサネット（登録商標）アドレスをＲＡＭ７０３内の経路テーブルから捜し、受信したパケットのイーサネット（登録商標）ヘッダ部を書き換えてイーサネット（登録商標）コントローラに送信要求を出す。送信が完了するとＣＰＵに割込みをあげ、完了を知らせる。通常は、パケットの取りこぼしを防止するため、複数のパケットを保持できるようにキューを用意している実装もあるが、ここでは簡略化して説明した。
【００４２】
図８は、本実施形態においてルータがパケットを受信した場合の処理フローである。
【００４３】
パケットを受信したら、ステップＳ８０１でポイント付きパケットであるかを判定する。これは、受信したパケットにＩＰ拡張ヘッダの一つである中継点オプション・ヘッダが存在し、オプションデータとしてポイント情報を持っていることを示す値ＯｐｔＡのオプション番号記述子があるかどうかで容易に判定できる。ポイント情報が付加されていない場合には、通常のパケットの受信処理ステップＳ８０２および通常のパケット送信処理ステップＳ８０３を実行する。
【００４４】
もし、ポイント情報が付いている場合には、ステップＳ８０４で宛先別パケットキュー７０７をサーチし（ステップＳ８０５）、受信したパケットと同じ宛先ＩＰアドレスのキューが既に存在するかどうかを判定する（ステップＳ８０６）。図９は宛先別パケットキューの構造を示した図である。アドレス欄９０１には宛先ＩＰアドレスが格納される。
【００４５】
パケットリスト９０２には到着したパケットが一方向リスト構造でつながる。宛先別パケットキュー７０７の宛先ＩＰアドレス内に格納されているＩＰアドレスと受信したポイント付きパケットの宛先ＩＰアドレスを順次比較することにより既に存在するかどうかがわかる。もし存在するならば、そのＩＰアドレスのパケットリストに受信したパケットを追加する（ステップＳ８０８）。一方、存在していない始めてのパケットであるならば、ステップＳ８０６で新しいアドレス項目をアドレス欄９０１に追加し、受信したパケットをパケットリスト９０２の先頭とする。
【００４６】
さらにステップＳ８０７で追加したこの宛先ＩＰアドレスに対するタイマーを起動する。タイマーは一般のＯＳに備わっているタイマーシステムコールを利用する。これを利用すれば発火時に宛先ＩＰアドレス欄９０１のインデックスあるいはメモリアドレスをパラメータとして発火関数が呼ばれ、どのキューに対するタイマーが発火したかが識別できる。
【００４７】
また、タイマーは一定期間後、一度発火するように設定する。例えば、数百ミリ秒〜数秒の間で設定する。時間が長い程、多くのパケットがキューイングさせることが可能であり、多くのクライアントを競らせることができるが、実際の接続まで遅延が生じたり、キューのためのメモリを多く必要とする。また、時間が短いと競わせるパケットが少ないため、競争の効果が薄れる。従って、時間は適宜設定することとする。
【００４８】
図１０は、ステップＳ８０７で設定したタイマーが発火した時の処理フローである。
【００４９】
ステップＳ１００１では、タイマーが満了した宛先ＩＰアドレスに対してキューイングされているパケットのポイント値の最大値を求める。これをＭａｘＰとする。ステップＳ１００２〜Ｓ１００５では、パケットリスト９０２の先頭から末尾まで順に処理を繰り返す。ステップＳ１００３でパケットのポイント値とＭａｘＰとを比較し、もしパケットのポイント値が小さければ、パケットを破棄する（ステップＳ１００４）。そうでなければ、パケットを次のホストへ転送する（ステップＳ１００５）。これはステップＳ８０３と同様の処理である。パケットリストのすべてを処理し終ったら、アドレス欄９０１を無効にしパケットキューを削除する（ステップＳ１００６）。
【００５０】
このように、ルータに宛先ＩＰアドレス毎にパケットのキューを用意し、一定期間パケットを保持し、集まったパケットに対してポイント値の演算を行い、パケットを取捨選択することにより、ポイント値で競り勝ったパケットのみが、次の中継点へ行くことができる。
【００５１】
経路上のルータで競り勝ったパケットは最終的に、最終宛先であるサーバホストに到達する。図１１はサーバホストの構成を示した図である。１１０１はサーバのコンピュータを示している。その中の構成は図１１のクライアントホストの構成図とほぼ同一であり、１１０２〜１１０９は図１の１０２〜１０９と同等のものである。１１１０は最大ポイントパケット選択部であり、受信したポイント付きパケットを一定期間保持し、その中から最大のポイント値を有するパケットを選択し、ポイントで競り負けたパケットを破棄するという、前述のルータと同等の処理をする。１１１１は持ち点テーブルであり、登録されたすべてのクライアントの持ち点を保持している。
【００５２】
図１２は持ち点テーブル１１１１の構成を示している。１２０１はクライアントホストのＩＰアドレスＣＡ（ｉ）を格納し、１２０２はそのクライアントホストの現在の持ち点ＣＰ（ｉ）を格納する。これらはシステムコールを新たに設けて設定できるようにする。例えば、
ａｌｌｏｃ＿ｐｏｉｎｔ（＜ＩＰアドレス＞、＜ポイント＞）    関数（３）
この関数を適宜コールすることにより、指定されたＩＰアドレスと持ち点とを持ち点テーブル１１１１に設定できる。
【００５３】
図１３はサーバホストで最大ポイントパケット選択部１１１０を経て最終的に競り勝った接続要求パケットに対する処理フローである。
【００５４】
ステップＳ１３０１では、パケットの送信元ＩＰアドレスと同じＩＰアドレスを持ち点テーブル１１１１からサーチする。もし見つからなければ（ステップＳ１３０２）、パケットを破棄し（ステップＳ１３０７）ＴＣＰの接続は行わない。もしアドレスＣＡ（ｉ）が存在するならば、ステップＳ１３０３でその持ち点ＣＰ（ｉ）と、到着したパケットに設定されていたポイントのチェックを行なう。
【００５５】
もし、パケットのポイント値が持ち点より多い場合には（ステップＳ１３０４）、パケットを無効とし破棄する（ステップＳ１３０７）。そうでなければ、持ち点ＣＰ（ｉ）をパケットに設定されていたポイント分を減算した値を新しい持ち点となるように更新する（ステップＳ１３０５）。その後、受け入れた接続要求パケットに対する応答パケット（ＳＹＮ＋ＡＣＫ）をクライアントホストへ送信する（ステップＳ１３０６）。以後はＴＣＰの接続が確立し、データ通信が可能となる。
【００５６】
尚、本実施形態では、競りに負けたパケットは破棄するように実現したが、そのようなパケットに対しては、送信元にＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）パケットを送信することも可能である。既存のＩＣＭＰの仕様に則るならば、「終点到達不能メッセージ」が妥当であろう。ＩＣＭＰパケットを受信した送信元は、接続要求パケットがサーバホストに届かなかったことが即座にわかる。ただし、通常のＩＣＭＰエラーメッセージでは、ポイント値で他に競り負けたのか、経路上にホストが存在しなかったのかが区別がつかない。これを区別するためには、新たなタイプのＩＣＭＰエラーメッセージを定義するのが一つの手段である。また、例えば、ＩＣＭＰパケットはエラーとなった元のパケット自身も包含するパケットであるから、元のパケットのポイント値を意図的に競り勝った相手のポイント値に入れ替えておけば、ＩＣＭＰパケットを受信した発信元が、自身が設定したはずのポイント値とＩＣＭＰパケットで戻ってきたパケットのポイント値とを比較し、異っていればポイント値で競り負けが原因でサーバホストへ到達できなかったことを判断できる。しかもこの場合には、競り勝った方のポイント値がわかるため、利用者は次に接続要求パケットを送信するときのポイント値の参考にもなる。
【００５７】
以上説明したように、本実施形態によれば、サーバホストに接続してサービスを受けたいクライアントホストは自分の持ち点以内のポイントを接続要求パケットに付加して送出する。各クライアントから送出された接続要求パケットは各中継点のルータにおいて、ポイント値による「競り」を行ない、競り勝ったパケットのみがルータを通過してサーバホストへ向かい、最終的にその時点で高いポイント値を設定したクライアントのみがサーバホストと接続を達成でき、安定したサービスを受けることができる。
【００５８】
【第２の実施形態】
上記第１の実施形態では、サーバホスト利用者が持ち点をなんらかの手段で予めサーバホストから得て、サーバホストへの接続が実現するたびにその持ち点が減って行く機構を説明した。持ち点を使い果たした時点で、サーバホストへの接続はできないため、再度、持ち点を得てからサーバホストへのアクセスが可能となる。本実施形態では、持ち点を減らすだけではなく、増やす機構を設けることにより、利用者がサーバホストへアクセスすることへの動機付けを促し、サーバ利用の活性化を計る場合について説明する。
【００５９】
本実施形態のサーバホストの構成は第１の実施形態の図１１とほぼ同じである。図１４は本実施形態における持ち点テーブルであり、第１の実施形態の１１１１に該当する。１４０１はクライアントホストのＩＰアドレスＣＡ（ｉ）を格納し、１４０２はそのクライアントホストの現在の持ち点ＣＰ（ｉ）を格納する。これらに加え本実施形態では、接続カウントＣＣ（ｉ）（１４０３）を設ける。接続カウントは、初期値は０で、サーバホストへの接続が成功するたびにインクリメントされるカウンタ値である。
【００６０】
図１５は、本実施形態におけるサーバホストの処理フローである。第１の実施形態では図１３に該当する部分である。
【００６１】
ステップＳ１５０１〜Ｓ１５０７は図１３におけるステップＳ１３０１〜Ｓ１３０７に対応する処理であり、本実施形態では新たにステップＳ１５０８、Ｓ１５０９、Ｓ１５１０の処理を加える。ステップＳ１５０４で接続可能なパケットであると判定された場合、ステップＳ１５０８で接続カウントＣＣ（ｉ）１４０３を１カウントアップする。ステップＳ１５０９でカウントアップした接続カウントＣＣ（ｉ）１４０３の値が‘ＣＴＨ’を越えたかどうかを判定する。
【００６２】
もし越えていなければ、第１の実施形態と同様ステップＳ１５０５で持ち点ＣＰ（ｉ）１４０２を到着したパケットが持っているポイント値分減算する。一方、‘ＣＴＨ’を越えていれば、ステップＳ１５１０でボーナス点として‘ＢＰ’を持ち点ＣＰ（ｉ）に加算する。ここで、接続カウントのしきい値‘ＣＴＨ’およびボーナス点‘ＢＰ’はサーバホスト側の運用に応じて適宜定める値とする。
【００６３】
以上のように持ち点を増分させる機構を設けることに、幅の広がったサービス内容を提供することができる。
【００６４】
【第３の実施形態】
上記第１および第２の実施形態はポイント値によりパケットを競わせる実施形態であったが、本実施形態ではポイント値を使わずにパケットの勝敗を決定する場合について述べる。第１の実施形態におけるポイント値の代わりに３つのシンボルを用い、それぞれをＪＲ、ＪＳ、ＪＰとする。これらシンボルを表現するためにそれぞれなんらかの固定された値を用いる。値はシステム全体で一貫していればなんでもよい。これらの３つのシンボルの間に次のようなルールを設ける。
【００６５】
2004220378.tif 000003
クライアントホストにおいて利用者は、ポイント値の代わりにＪＲ、ＪＳ、ＪＰのいずれかを指定する。クライアントホストはサーバホストへの接続要求パケットのＩＰ拡張ヘッダに指定されたシンボル値を設定し送信する。以上の処理は第１の実施形態におけるポイント値を格納する領域、具体的には、ポイントメンバ変数１０７、中継点オプション・ヘッダのオプション・データ・フィールド６０５などをそのまま利用することができる。
【００６６】
パケットを受け取ったルータの処理も、第１の実施形態とほぼ同様である。図１６は本実施形態におけるタイマー発火時の処理である。第１の実施形態の図１０に該当する。
【００６７】
ステップＳ１６０１では、キューイングされているパケットリスト９０２を順にたどり、設定されているシンボルから、勝ち残るシンボルを特定する。勝ち負けはルール（１）に従う。結果の勝利シンボルをＷｉｎＳとする。もし、勝利者がない場合には、特別な値ＮＵＬＬを設定する。
【００６８】
ステップＳ１６０２で勝利者がなければステップＳ１６０３に進み、ステップＳ１６０３でキューイングされているパケットリスト９０２の全てのパケットを破棄し、ステップＳ１６０４でアドレス欄９０１を無効にしパケットキューを削除する。勝利者が有る場合には、ステップＳ１６０５〜ステップＳ１６０８のループでパケットリスト９０２の各パケットに対して処理をする。
【００６９】
もしパケットが有するシンボルが勝利シンボルＷｉｎＳと異なるならば（ステップＳ１６０６）、パケットを破棄する（ステップＳ１６０７）。ＷｉｎＳと同じならば、パケットを次のホストへ転送する（ステップＳ１６０８）。全てのパケットに対して処理が終了したならば、ステップＳ１６０４でキューを削除する。
【００７０】
サーバホストの処理もルータの処理と同様にシンボルにより勝敗を決定し、勝ち残ったパケットに対して、ＴＣＰの接続要求を受け入れることになる。本実施形態では、持ち点がないため、サーバホストに持ち点テーブル１１１１や持ち点の減算処理ステップＳ１３０５などは必要なく、単純な構成で接続パケットの公平な取捨選択が行なえる。
【００７１】
【他の実施形態】
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【００７２】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【００７３】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００７４】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【００７５】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００７６】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００７７】
なお、本発明に係る実施態様の例を以下に列挙する。
【００７８】
［実施態様１］  ネットワークを介して複数のクライアントと通信可能なサーバを備えるクライアント／サーバ・システムであって、
前記サーバ内の所定の宛先に対する接続を要求する前記クライアントからの接続要求情報を受信する受信手段と、
前記受信手段により、一定時間内に同じ宛先に対する接続を要求する接続要求情報が受信された場合に、該接続要求情報に記載された属性を識別する識別手段と、
前記識別手段により識別された属性に基づいて、前記一定時間内に同じ宛先に対する接続を要求する接続要求情報のうちのいずれかを選択する選択手段と、
前記選択手段により選択された接続要求情報を送信する送信手段と
を備えることを特徴とするクライアント／サーバ・システム。
【００７９】
［実施態様２］  前記接続要求情報に記載された属性は、前記宛先との接続に対する優先度を示す情報であることを特徴とする実施態様１に記載のクライアント／サーバ・システム。
【００８０】
［実施態様３］  前記接続要求情報に記載された属性は、大小比較により優先度を決定可能な数値であることを特徴とする実施態様２に記載のクライアント／サーバ・システム。
【００８１】
［実施態様４］  前記接続要求情報に記載された属性は、所定の規則に従って、優先度を決定可能な記号であることを特徴とする実施態様２に記載のクライアント／サーバ・システム。
【００８２】
［実施態様５］  前記サーバはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）プロトコルを介して前記クライアントと通信することを特徴とする実施態様１に記載のクライアント／サーバ・システム。
【００８３】
［実施態様６］  前記接続要求情報とは、ＳＹＮパケットであり、前記宛先とはＩＰアドレスであることを特徴とする実施態様５に記載のクライアント／サーバ・システム。
【００８４】
［実施態様７］  前記接続要求情報に記載された属性とは、前記ＳＹＮパケットのヘッダ部に記載された、ポイント値であることを特徴とする実施態様６に記載のクライアント／サーバ・システム。
【００８５】
［実施態様８］  前記選択手段は、前記一定時間内に同じＩＰアドレスに対する接続を要求するＳＹＮパケットのうち、ポイント値が最大のものを選択することを特徴とする実施態様７に記載のクライアント／サーバ・システム。
【００８６】
［実施態様９］  クライアントとサーバとが接続されたネットワーク上の情報を中継する中継装置であって、
前記サーバ内の所定の宛先に対する接続を要求する前記クライアントからの接続要求情報を受信する受信手段と、
前記受信手段により、一定時間内に同じ宛先に対する接続を要求する接続要求情報が受信された場合に、該接続要求情報に記載された属性を識別する識別手段と、
前記識別手段により識別された属性に基づいて、前記一定時間内に同じ宛先に対する接続を要求する接続要求情報のうちのいずれかを選択する選択手段と、
前記選択手段により選択された接続要求情報を送信する送信手段と
を備えることを特徴とする中継装置。
【００８７】
［実施態様１０］  前記接続要求情報に記載された属性は、前記宛先との接続に対する優先度を示す情報であることを特徴とする実施態様９に記載の中継装置。
【００８８】
［実施態様１１］  前記接続要求情報に記載された属性は、大小比較により優先度を決定可能な数値であることを特徴とする実施態様１０に記載の中継装置。
【００８９】
［実施態様１２］  前記接続要求情報に記載された属性は、所定の規則に従って、優先度を決定可能な記号であることを特徴とする実施態様１０に記載の中継装置。
【００９０】
［実施態様１３］  前記サーバはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）プロトコルを介して前記クライアントと通信することを特徴とする実施態様９に記載の中継装置。
【００９１】
［実施態様１４］  前記接続要求情報とは、ＳＹＮパケットであり、前記宛先とはＩＰアドレスであることを特徴とする実施態様１３に記載の中継装置。
【００９２】
［実施態様１５］  前記接続要求情報に記載された属性とは、前記ＳＹＮパケットのヘッダ部に記載された、ポイント値であることを特徴とする実施態様１４に記載の中継装置。
【００９３】
［実施態様１６］  前記選択手段は、前記一定時間内に同じＩＰアドレスに対する接続を要求するＳＹＮパケットのうち、ポイント値が最大のものを選択することを特徴とする実施態様１５に記載の中継装置。
【００９４】
［実施態様１７］  クライアントとサーバとが接続されたネットワーク上の情報を中継する中継装置における情報処理方法であって、
前記サーバ内の所定の宛先に対する接続を要求する前記クライアントからの接続要求情報を受信する受信工程と、
前記受信工程が、一定時間内に同じ宛先に対する接続を要求する接続要求情報を受信した場合、該接続要求情報に記載された属性を識別する識別工程と、
前記識別工程により識別された属性に基づいて、前記一定時間内に同じ宛先に対する接続を要求する接続要求情報のうちのいずれかを選択する選択工程と、
前記選択工程により選択された接続要求情報を送信する送信工程と
を備えることを特徴とする中継装置における情報処理方法。
【００９５】
［実施態様１８］  前記接続要求情報に記載された属性は、前記宛先との接続に対する優先度を示す情報であることを特徴とする実施態様１７に記載の中継装置における情報処理方法。
【００９６】
［実施態様１９］  前記接続要求情報に記載された属性は、大小比較により優先度を決定可能な数値であることを特徴とする実施態様１８に記載の中継装置における情報処理方法。
【００９７】
［実施態様２０］  前記接続要求情報に記載された属性は、所定の規則に従って、優先度を決定可能な記号であることを特徴とする実施態様１８に記載の中継装置における情報処理方法。
【００９８】
［実施態様２１］  前記サーバはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）プロトコルを介して前記クライアントと通信することを特徴とする実施態様１７に記載の中継装置における情報処理方法。
【００９９】
［実施態様２２］  前記接続要求情報とは、ＳＹＮパケットであり、前記宛先とはＩＰアドレスであることを特徴とする実施態様２１に記載の中継装置における情報処理方法。
【０１００】
［実施態様２３］  前記接続要求情報に記載された属性とは、前記ＳＹＮパケットのヘッダ部に記載された、ポイント値であることを特徴とする実施態様２２に記載の中継装置における情報処理方法。
【０１０１】
［実施態様２４］  前記選択工程は、前記一定時間内に同じＩＰアドレスに対する接続を要求するＳＹＮパケットのうち、ポイント値が最大のものを選択することを特徴とする実施態様２３に記載の中継装置における情報処理方法。
【０１０２】
［実施態様２５］  実施態様１７乃至２４のいずれか１つに記載の情報処理方法をコンピュータによって実現させるための制御プログラム。
【０１０３】
【発明の効果】
以上説明したように本発明によれば、コネクション型通信を行うクライアント／サーバ・システムにおいて、最終到達先へのパケット数を抑制することにより、安定したサービスの提供を行うことが可能となる。
【図面の簡単な説明】
【図１】本発明の実施形態にかかるクライアント／サーバ・システムを構成するクライアントホストの構成図である。
【図２】本発明の実施形態にかかるクライアント／サーバ・システムを構成するクライアントホストの処理フローを示す図である。
【図３】本発明の実施形態にかかるクライアント／サーバ・システムを構成するクライアントホストにおける接続処理フローを示す図である。
【図４】ＴＣＰヘッダの形式の一例を示す図である。
【図５】ＩＰヘッダの形式の一例を示す図である。
【図６】中継点オプション・ヘッダの形式の一例を示す図である。
【図７】本発明の実施形態にかかるルータの構成を示す図である。
【図８】本発明の実施形態にかかるルータにおける受信処理フローを示す図である。
【図９】本発明の実施形態にかかるルータにおける宛先別パケットキューの構成を示す図である。
【図１０】本発明の第１の実施形態にかかるルータにおけるタイマー満了時の処理フローを示す図である。
【図１１】本発明の実施形態にかかるクライアント／サーバ・システムを構成するサーバホストの構成を示す図である。
【図１２】本発明の第１の実施形態にかかるクライアント／サーバ・システムを構成するサーバホストが有する持ち点テーブルの構成を示す図である。
【図１３】本発明の第１の実施形態にかかるクライアント／サーバ・システムを構成するサーバホストの処理フローを示す図である。
【図１４】本発明の第２の実施形態にかかるクライアント／サーバ・システムを構成するサーバホストが有する持ち点テーブルの構成を示す図である。
【図１５】本発明の第２の実施形態にかかるクライアント／サーバ・システムを構成するサーバホストの処理フローを示す図である。
【図１６】本発明の第３の実施形態にかかるルータにおけるタイマー満了時の処理フローを示す図である。
【図１】
2004220378.tif 000004
【図２】
2004220378.tif 000005
【図３】
2004220378.tif 000006
【図４】
2004220378.tif 000007
【図５】
2004220378.tif 000008
【図６】
2004220378.tif 000009
【図７】
2004220378.tif 000010
【図８】
2004220378.tif 000011
【図９】
2004220378.tif 000012
【図１０】
2004220378.tif 000013
【図１１】
2004220378.tif 000014
【図１２】
2004220378.tif 000015
【図１３】
2004220378.tif 000016
【図１４】
2004220378.tif 000017
【図１５】
2004220378.tif 000018
【図１６】
2004220378.tif 000019