(57)【要約】【課題】クライアント・サーバ・システム及びサーバ制御方法に関し、サーバ主導によりクライアントとの間のセッションをクローズする。【解決手段】サーバ１と複数のクライアント２とを含み、クライアント２からネットワーク３を介してサーバ１に対するセッションを確立し、サーバ１からクライアント２の要求するファイルを転送するクライアント・サーバ・システム及びサーバ制御方法であって、サーバ１は、複数のクライアント２が要求するファイルを保持するデータベース１２と、クライアント２の要求ファイル対応のＵＲＩを登録する登録テーブル１３と、制御処理部１１とを有し、ネットワーク３を介したクライアント２からの要求によるセッション確立し、クライアントの要求ファイルを転送し、登録テーブル１３を参照してＵＲＩ対応のファイル転送完了を識別して、セッションをクローズする。【選択図】図１
2009217445.tif 000002
【特許請求の範囲】
【請求項１】
サーバと複数のクライアントとを含み、クライアントからネットワークを介してサーバに対するセッションを確立し、前記サーバからクライアントの要求するファイルを転送するクライアント・サーバ・システムに於いて、
前記サーバは、前記複数のクライアントがそれぞれ要求する各種ファイルを保持するデータベースと、前記クライアントの要求ファイル対応のＵＲＩを登録する登録テーブルとを有すると共に、前記ネットワークを介した前記クライアントからの要求によるセッション確立制御処理手段及びセッション確立によるクライアントの要求ファイルの転送処理制御手段及び前記登録テーブルを参照して前記ＵＲＩ対応のファイル転送完了により前記セッションをクローズする処理制御手段を含む制御処理部を有する
ことを特徴とするクライアント・サーバ・システム。
【請求項２】
前記サーバの前記制御処理部は、前記クライアントとの間のセッション確立数を監視し、最大設定セッション確立数を超えた時のセッション確立要求を受付けない制御手段と、セッション確立後のセッション継続時間を監視し、設定時間を超えた時にセッションをクローズする制御手段とを含むことを特徴とする請求項１記載のクライアント・サーバ・システム。
【請求項３】
ネットワークを介してサーバとクライアントとの間のセッション確立を行って、該クライアントからの要求するファイルをサーバから転送するサーバ制御方法に於いて、
前記サーバと前記クライアントとの間のセッション確立による該クライアントの要求ファイル対応のＵＲＩを該クライアント対応に登録テーブルに登録する過程と、該登録テーブルに登録されたＵＲＩ対応のファイルを転送する毎に当該ＵＲＩを削除し、最終ＵＲＩ対応のファイル転送に対する前記クライアントからのＡＣＫ受信により当該セッションをクローズする過程とを含むことを特徴とするサーバ制御方法。
【請求項４】
前記サーバは、前記クライアントとの間のセッション確立数を監視し、最大設定セッション確立数を超えた時のセッション確立要求を受付けない制御を行うと共に、セッション確立後のセッション継続時間を監視し、設定時間を超えた時に当該セッションをクローズする制御する過程を含むことを特徴とする請求項３記載のサーバ制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバと複数のクライアントとを含み、クライアントからサーバに対するセッション確立を効率良く実行できるクライアント・サーバ・システム及びサーバ制御方法に関する。
【背景技術】
【０００２】
ネットワークを介してルータ等の複数の各種の通信制御装置を接続したデータ伝送システムに於いて、監視制御装置により、各種の通信制御装置の設定制御や監視制御を行うシステムが知られており、その場合の監視制御装置は、ルータ等の通信制御装置のバージョンや種別等にそれぞれ対応したソフトウェアをインストールしておく必要がある。このような監視制御システムに於いては、例えば、ＴＥＬＮＥＴ，ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ），ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）等を適用して、通信制御装置の監視及び制御を行う手段が適用されている。
【０００３】
前述のＴＥＬＮＥＴを適用した場合、総てキーボード操作による操作を必要とし、制御コマンドと、機能とをオペレータが記憶しておく必要があり、且つ通信制御装置対応に制御コマンドが異なる場合が多く、多種多様の通信制御装置に対する監視及び制御を実行する場合、操作が煩雑となる。又ＳＮＭＰを適用した場合、ＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）オブジェクトにより、ＭＩＢブラウザを介して制御するもので、標準ＭＩＢにより制御できない機能については拡張ＭＩＢを適用することになるが、それぞれの通信制御装置対応にＭＩＢ名称と機能とが相違する場合が多く、多種多様の装置構成対応にオペレータが対応する必要がある。又ＨＴＴＰを適用した場合、オペレータの操作により、ＨＴＭＬを適用した場合、オペレータの操作により、ＷＥＢブラウザにＨＴＭＬ文書を送信して、監視及び制御を行うことになる。しかし、自発的なレスポンスや定期的な更新処理等ができないものである。その場合、ＪＡＶＡ（登録商標）等により擬似的な動作を行わせることができるが、総てのレスポンスや時限的な動作については対応していない。又監視制御装置をパソコン（パーソナルコンピュータ）により構成した場合、各種の通信制御装置対応の監視及び制御を実行するソフトウェアを実装することが考えられるが、比較的小規模構成であることにより、リソース不足となって、所望の監視及び制御を実行することは困難である。
【０００４】
又大型汎用コンピュータをホストとし、このホストコンピュータの資源を活用するサーバを設け、パソコン等をクライアントとし、複数のクライアントからそれぞれネットワークを介した各種の要求をサーバにより受付け、サーバはホストコンピュータが管理している各種情報の中から要求された情報を取り出してクライアントに供給するクライアント・サーバ・システムが知られている（例えば、特許文献１参照）。又サーバに於いて管理する各種アプリケーションソフトを、クライアントからの要求に従って、そのクライアントが正規のクライアントであるか否かを先ず確認し、正規なクライアントに対してのみ、要求されたアプリケーションソフトをダウンロードする手段が知られている（例えば、特許文献２参照）。
【０００５】
又クライアントの機能種別をサーバ側で判断して、要求された情報を転送するシステムに於いて、ＨＴＭＬとコンパクトＨＴＭＬとによる制御命令の何れかを使用するクライアントが混在し、クライアントからの要求により、サーバは、そのクライアントがＨＴＭＬ記述言語の制御命令の実行機能を有するか、又はコンパクトＨＴＭＬ記述言語の制御命令の実行機能を有するかを、セッション情報に含まれる機能種別情報により判断し、外部記憶装置に格納したコンパクトＨＴＭＬ記述言語の制御命令を含むＨＴＭＬ記述言語を読出して、クライアントがコンパクトＨＴＭＬ記述言語の制御命令に対応可能の場合は、コンパクトＨＴＭＬ記述言語の制御命令をクライアントに転送し、ＨＴＭＬ記述言語の制御命令のみに対応可能の場合は、ＨＴＭＬ記述言語の制御命令を転送するシステムが提案されている（例えば、特許文献３参照）。又複数の組み込み機器をクライアントとし、その稼動状況をサーバにより監視し、組み込み機器のソフトウェアの更新を、組み込み機器の一時的な動作停止可能の稼働状況に於いてサーバからダウンロードする手段が提案されている（例えば、特許文献４参照）。
【特許文献１】特開２０００−１８７６３０号公報
【特許文献２】特開２００２−２４４７５１号公報
【特許文献３】特開２００３−１６２５２２号公報
【特許文献４】特開２００４−２０６３９０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ネットワークを介してデータの伝送を制御するルータ等の通信制御装置は、前述のように各種の構成を含むと共に、同一種別であっても製造年次の相違等を含むものであり、それらの総てに対応して監視及び制御を行う為の監視制御装置は大型化し、コストアップとなる問題がある。そこで、パソコン等による小規模の監視制御装置により、監視及び制御を行うことが考えられる。その場合、総ての種別の通信制御装置に対する監視及び制御用のソフトウェアを監視制御装置に実装することは、前述のように、リソースの関係上不可能に近いものである。そこで、監視制御装置をクライアントとし、必要なソフトウェアを要求できるサーバを設けることが考えられる。即ち、前述の従来例のようなクライアント・サーバ・システムを構成することが考えられる。その場合、比較的小規模構成のクライアントを多数設けて、それぞれのクライアントからサーバにアクセスして、必要とするソフトウェアを要求することになる。
【０００７】
その場合、クライアントからサーバに対するアクセスは、例えば、ＨＴＴＰ１．０準拠の場合、ソケット作成、接続を行った後に開放することを繰り返すもので、複数のクライアントに対する比較的小規模のサーバは、接続、開放処理の繰り返しが多いことから処理負担が大きくなる問題がある。又ＨＴＴＰ１．１準拠サーバの場合は、サーバのソケット作成、開放を繰り返すことなく、持続的な接続機能を有するものであり、例えば、図５のフローチャートに示すように、サーバは、クライアントからの接続要求により、ソケット作成、接続を行い（Ｃ１）、クライアントからのＨＴＴＰ要求によりＨＴＴＰレスポンスを送出し（Ｃ２）、セッション確立を行い、セッションタイムアウトカウンタを起動して設定値からのダウンカウントを開始する（Ｃ３）。そして、クライアントからの切断要求の有無を判定し（Ｃ４）、切断要求がない場合、タイムアウトカウンタがダウンカウント処理により、０となったか否かを判定し（Ｃ５）、０でない場合はステップ（Ｃ４）に移行し、接続状態を維持する。又タイムアウトカウンタが０となると、セッションクローズとする（Ｃ６）。又クライアントからの切断要求があった場合も、セッションクローズとする。サーバに対して或るクライアントがアクセスしてセッション確立後、そのセッションクローズ迄を、クライアント対応の処理区間Ａとすると、この処理区間Ａが短い程、サーバに対して多数のクライアントがアクセス可能となる。
【０００８】
図６は、従来例のシーケンスチャートであり、サーバＳＶに対してクライアントＣＬ１〜ＣＬ３がアクセスする場合に於いて、クライアントＣＬ１とサーバＳＶとの間のＴＣＰ接続によるセッション１を確立し、同様に、クライアントＣＬ２とサーバＳＶとの間のＴＣＰ接続によるセッション２を確立し、クライアントＣＬ１からのＨＴＴＰ要求（ＨＴＴＰ−ＲＥＱ）をサーバＳＶに送出し、サーバＳＶからのＨＴＴＰ応答（ＨＴＴＰ−ＲＥＱ）を受信し、クライアントＣＬ２についても同様に、クライアントＣＬ２からのＨＴＴＰ要求（ＨＴＴＰ−ＲＥＱ）をサーバＳＶに送出し、サーバＳＶからのＨＴＴＰ応答（ＨＴＴＰ−ＲＥＱ）を受信した状態に於いては、サーバＳＶとクライアントＣＬ１との間のセッション１と、サーバＳＶとクライアントＣＬ２との間のセッション２とが確立された状態となる。これは、前述のＨＴＴＰ１．１準拠の持続的な接続状態となる。
【０００９】
この場合に、例えば、サーバＳＶとクライアントとの間のセッション確立数を最大２に設定されているとすると（なお、実際には、サーバＳＶの規模に応じて更に多数の最大設定セッション確立数とすることが可能であるが、説明の便宜上、最大設定セッション確立数を２とした場合について説明する）、クライアントＣＬ３がサーバＳＶにアクセスした場合に、既に、クライアントＣＬ１，ＣＬ２との間で２セッションが確立されているから、×印で示すように、クライアントＣＬ３からの要求を受付けることはできない状態となる。その為に、クライアントＣＬ１，ＣＬ２の何れかの切断要求待ちとなる。この場合、サーバＳＶは、図５に於ける処理区間Ａに於いて、クライアントＣＬ１，ＣＬ２の何れかのタイムアウトか、又はクライアントＣＬ１，ＣＬ２の何れかからの切断要求待ちとなる。そして、例えば、クライアントＣＬ１がＴＣＰ切断により、クライアントＣＬ１とサーバＳＶとの間のセッション１を開放すると、クライアントＣＬ２とサーバＳＶとの間のセッション２のみとなり、セッション確立数１となるから、クライアントＣＬ３の要求を受付けることができる。
【００１０】
前述のように、持続的な接続機能によりセッション確立を維持し、最大設定セッション確立数となると、クライアント側からの切断要求があるか、又はタイムアウトによりサーバ側で切断処理するかの何れかにより、待機中の新たなクライアントからの要求を受付けることが可能となる。従って、比較的小規模のサーバを備えたクライアント・サーバ・システムに於いては、多数のクライアントに対するサーバからのサービス提供を円滑に行うことが困難である問題がある。又前記従来例の特許文献１〜４に於いても、このような問題は提起されていない。
【００１１】
本発明は、前述の従来の問題点を解決することを目的とし、比較的小規模のサーバを備えたシステムに於いても、多数のクライアントに対するサービスを実行可能とするものである。
【課題を解決するための手段】
【００１２】
本発明のクライアント・サーバ・システムは、サーバと複数のクライアントとを含み、クライアントからネットワークを介してサーバに対するセッションを確立し、前記サーバからクライアントの要求するファイルを転送するクライアント・サーバ・システムであって、サーバは、複数のクライアントがそれぞれ要求する各種ファイルを保持するデータベースと、クライアントの要求ファイル対応のＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を登録する登録テーブルとを有すると共に、ネットワークを介したクライアントからの要求によるセッション確立制御処理手段及びセッション確立によるクライアントの要求ファイルの転送処理制御手段及び登録テーブルを参照してＵＲＩ対応のファイル転送完了により、セッションをクローズする処理制御手段を含む制御処理部を有するものである。
【００１３】
又サーバの制御処理部は、クライアントとの間のセッション確立数を監視し、最大設定セッション確立数を超えた時のセッション確立要求を受付けない制御手段と、セッション確立後のセッション継続時間を監視し、設定時間を超えた時にセッションをクローズする制御手段とを含む構成を有する。
【００１４】
又本発明のサーバ制御方法は、ネットワークを介してサーバとクライアントとの間のセッション確立を行って、該クライアントからの要求するファイルをサーバから転送するサーバ制御方法であって、サーバとクライアントとの間のセッション確立による該クライアントの要求ファイル対応のＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を、クライアント対応に登録テーブルに登録する過程と、この登録テーブルに登録されたＵＲＩ対応のファイルを転送する毎に当該ＵＲＩを削除し、最終ＵＲＩ対応のファイル転送に対する前記クライアントからのＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）受信により、そのセッションをクローズする過程とを含むものである。
【００１５】
又サーバは、クライアントとの間のセッション確立数を監視し、最大設定セッション確立数を超えた時のセッション確立要求を受付けない制御を行うと共に、セッション確立後のセッション継続時間を監視し、設定時間を超えた時に当該セッションをクローズする制御する過程を含むものである。
【発明の効果】
【００１６】
サーバは、セッションを確立したクライアントからの要求に従ったファイルの転送が終了したか否かを登録テーブルに登録したＵＲＩを基に識別し、ファイル転送終了により、サーバは、クライアントとの間のセッションをクローズする。即ち、サーバの主導によりセッションをクローズするもので、比較的小規模のサーバであっても、多数のクライアントに対するサービス提供を順次実行できる利点がある。
【発明を実施するための最良の形態】
【００１７】
本発明のクライアント・サーバ・システムは、図１を参照すると、サーバ１と複数のクライアント２とを含み、クライアント２からネットワーク３を介してサーバ１に対するセッションを確立し、サーバ１からクライアント２の要求するファイルを転送するクライアント・サーバ・システムであって、サーバ１は、複数のクライアント２がそれぞれ要求する各種ファイルを保持するデータベース１２と、クライアント２の要求ファイル対応のＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を登録する登録テーブル１３とを有すると共に、ネットワーク３を介したクライアント２からの要求によるセッション確立制御処理手段及びセッション確立によるクライアントの要求ファイルの転送処理制御手段及び登録テーブルを参照してＵＲＩ対応のファイル転送完了により、セッションをクローズする処理制御手段を含む制御処理部１１を有するものである。
【００１８】
本発明のサーバ制御方法は、ネットワーク３を介してサーバ１とクライアント２との間のセッション確立を行って、クライアント２からの要求するファイルをサーバ１から転送するサーバ制御方法であって、サーバ１とクライアント２との間のセッション確立による該クライアント２の要求ファイル対応のＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を、クライアント２対応に登録テーブル１３に登録する過程と、この登録テーブル１３に登録されたＵＲＩ対応のファイルを転送する毎に当該ＵＲＩを削除し、最終ＵＲＩ対応のファイル転送に対する前記クライアント２からのＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）受信により、そのセッションをクローズする過程とを含むものである。
【実施例１】
【００１９】
図１は、本発明の実施例１の説明図であり、１はサーバ、２はクライアント、３はネットワーク、４は被監視装置、１１は制御処理部、１２はデータベース、１３はＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）の登録テーブル、１４は入出力インタフェース部を示す。サーバ１に対してネットワーク３を介して複数のクライアント２がアクセス可能の構成を有し、又各クライアント２は、単一又は複数の被監視装置４に対する設定や監視制御等を行う機能を有するものであり、その設定及び監視の制御の為のソフトウェアをサーバ１に要求してダウンロードする。又サーバ１は、各部を制御する制御処理部１１と、各種のデータを格納したデータベース１２と、クライアント２から要求に対応して、関連するＵＲＩのリストをサーチし、このＵＲＩリストをクライアント対応に作成する登録テーブル１３と、入出力処理を行う入出力インタフェース部１４とを含むものである。
【００２０】
サーバ１の制御処理部１１は、クライアント２との間のセッション確立数を管理し、予め設定した最大設定セッション確立数を超える場合のクライアントからの接続要求は受付けない制御手段と、セッション確立により起動するタイマにより、タイムアウトとなった場合、そのセッションをクローズする制御手段とを備えると共に、クライアント２の要求に従ったファイル転送終了によりセッションをクローズする制御手段を備える。このファイル転送終了を判断する為に、登録テーブル１３を設けるものであり、クライアント２からの要求に従ったＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）を登録する。その場合のＵＲＩは、単一又は複数となるが、要求クライアント対応に登録し、例えば、関連する複数のＵＲＩが存在する場合は、登録テーブル１３にそれらが登録されるので、順次登録されたＵＲＩに従ったＨＴＭＬファイルをデータベース１２から読出してクライアント２に送出し、且つ送出したＨＴＭＬファイル対応のＵＲＩを登録テーブル１３から順次消去する。従って、クライアント２からの要求によるＨＴＭＬファイルを総て転送すると、登録テーブル１３には、そのクライアント２対応の登録ＵＲＩは零となり、制御処理部１１は、そのクライアント２との間のセッションをクローズする。従って、クライアント２からの要求に従ったＨＴＭＬファイルの転送終了により、セッションをクローズし、最大設定セッション確立数となる状態を回避することができ、多数のクライアントに対するサービス提供が可能となる。
【００２１】
図２及び図３は、本発明の実施例１のフローチャートであり、図２は、ＷＥＢサーバ起動時に、登録ＵＲＩとそれに対応するＨＴＭＬスクリプト実行上、関連してリクエストされるＵＲＩをサーチして、前述の登録テーブル１３に登録する場合の処理フローを示し、クライアント２からの要求により、登録ＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）のＨＴＭＬファイルをオープンし（Ａ１）、ファイルロード上、リクエスト発行の有無を判定し（Ａ２）、有りの場合は、テーブルにＵＲＩパスを登録し（Ａ４）、無しの場合は、ＨＴＭＬファイルの最後を検出したか否かを判定し（Ａ３）、検出した場合は、ステップ（Ａ６）へ移行し、検出しない場合は、スクリプトの次行に移行し（Ａ５）、前のステップ（Ａ２）へ移行する。又ステップ（Ａ６）に於いては、次の登録ＵＲＩファイルを参照し、次の登録ＵＲＩの有無を判定し（Ａ７）、有りの場合は、最初のステップ（Ａ１）へ移行し、無しの場合は、処理を終了とする。即ち、クライアントから順次要求されるファイルについて、登録テーブル１３に単一又は複数のＵＲＩを登録する。それにより、サーバ１は、セッション確立したクライアント２が登録ＵＲＩ数に従った繰り返し要求の有無を予測することができる。
【００２２】
図３は、本発明の実施例１のサーバ主導によるセッション開放処理を実行する場合のフローチャートを示すもので、クライアント２からの接続要求により、ソケット作成、接続の処理を行い（Ｂ１）、クライアント２からのＨＴＴＰ要求に対して、ＨＴＴＰレスポンスを送信し（Ｂ２）、スクリプトの最後を送信したか否かを判定し（Ｂ３）、最後を送信していない場合は、ステップ（Ｂ２）へ移行し、送信した場合は、それに対するクライアントからのＡＣＫを受信したか否かを判断する（Ｂ４）。受信していない場合は、タイムカウンタが０になったか否かを判定する（Ｂ５）。このタイムカウンタは、図示を省略しているが、セッション確立により起動する。又ステップ（Ｂ４）に於いて、ＡＣＫ受信の場合は、ＴＣＰレイヤにＲＳＴパケット送信要求を行い（Ｂ７）、セッションクローズとする（Ｂ７）。又ステップ（Ｂ５）に於いて、タイムアウトカウンタが０となると、セッションクローズとする（Ｂ８）。即ち、サーバ１の主導により、タイムアウトカウンタが０となった場合と、クライアントからの要求ＵＲＩリストを検索して求め、そのリストに従ったファイルを送信して、クライアントからのＡＣＫ受信により、そのクライアントとの間のセッションをクローズする。
【００２３】
図４は、本発明の実施例１のシーケンスチャートであり、サーバ１とクライアント２−１〜２−３との間について示し、最大設定セッション確立数を２とした場合（なお、前述のように、サーバ１の規模に応じて更に多数の最大設定セッション確立数とするものであるが、説明の便宜上、最大設定セッション確立数を２とした場合について説明する）、サーバ１とクライアント２−１との間のＴＣＰ接続によりセッション１、次にサーバ１とクライアント２−２との間のＴＣＰ接続によりセッション２が順次確立して、最大設定セッション確立数２となる。この状態ではクライアント２−３等の他のクライアントはセッション確立ができないことになる。そして、クライアント２−１からサーバ１に対するＨＴＴＰ−ＲＥＱ（要求）送出、それに対するサーバ１からクライアント２−１に対するＨＴＴＰ−ＲＥＳ（応答）送出を行い、前述のように、スクリプトの最後に相当する応答送出に対してクライアント２−１からのＡＣＫ受信により、サーバ１はクライアント２−１との間のＴＣＰ切断を行い、セッション１を開放する。即ち、サーバ１主導によるセッションクローズ処理を行う。このように、セッション１開放により、最大設定セッション確立数２以下のセッション確立数となり、サーバ１は、他のクライアントのセッション確立要求を受け入れることが可能となる。
【００２４】
同様に、クライアント２−２からサーバ１に対するＨＴＴＰ−ＲＥＱ（要求）送出、それに対するサーバ１からクライアント２−２に対するＨＴＴＰ−ＲＥＳ（応答）送出を行い、前述のように、スクリプトの最後に相当する応答送出に対してクライアント２−２からのＡＣＫ受信により、サーバ１はクライアント２−２との間のＴＣＰ切断を行い、セッション２を開放する。この時点では、セッション１，２は開放となっているから、サーバ１に対するクライアント２−３のセッション確立要求を、丸印で示すように、受け入れることが可能となる。従って、サーバ主導によるコネクションクローズ処理を行うことにより、小規模のサーバであっても、多数のクライアントからの要求を順次受け入れることが可能となる。
【図面の簡単な説明】
【００２５】
【図１】本発明の実施例１の説明図である。
【図２】本発明の実施例１のフローチャートである。
【図３】本発明の実施例１のフローチャートである。
【図４】本発明の実施例１のシーケンスチャートである。
【図５】従来例のフローチャートである。
【図６】従来例のシーケンスチャートである。
【符号の説明】
【００２６】
１  サーバ
２  クライアント
３  ネットワーク
４  被監視装置
１１  制御処理部
１２  データベース
１３  登録テーブル
１４  入出力インタフェース部
【図１】
2009217445.tif 000003
【図２】
2009217445.tif 000004
【図３】
2009217445.tif 000005
【図４】
2009217445.tif 000006
【図５】
2009217445.tif 000007
【図６】
2009217445.tif 000008