JP2005100343A - 接続管理機能を有するサーバ - Google Patents

Abstract

【課題】接続が失われたクライアントにより資源が無駄に使用されることのない接続管理機能を有するサーバを提供する。
【解決手段】クライアントが接続を要求したとき、サーバはそのクライアントを暫定的に接続し、固有ＩＤ・アプリケーションＩＤを受信し、クライアント情報テーブルから両ＩＤが一致するクライアントを探し（Ｓ４０１）、存在する場合、そのクライアント情報を削除し（Ｓ４０３）、存在しない場合、クライアント情報テーブルが満杯か否を判断し（Ｓ４０４）、満杯の場合、最終アクセス日時が最も古いクライアントをクライアント情報テーブルから探す（Ｓ４０５）。最終アクセス日時が２４時間以上前の場合、そのクライアント情報を削除する（Ｓ４０８）。そして、暫定的に接続したクライアントのクライアント情報をクライアント情報テーブルに登録する（Ｓ４０９）。
【選択図】図８

Description

本発明は、接続管理機能を有するサーバに関し、さらに詳しくは、複数のクライアントに接続可能なサーバに関する。

クライアントサーバシステムにおいては、クライアントがサーバに接続を要求し、サーバがこの要求に応じてそのクライアントとの接続を確立する。ネットワークサービスの終了後は、クライアントがサーバに切断を要求し、サーバがこの要求に応じてそのクライアントを切断する。

しかし、アプリケーションプログラムの異常終了、突然の電源遮断、ネットワークコネクタの取り外しなど、クライアント側で何らかの異常が発生すると、突然、クライアントとの接続が失われることになる。このときにネットワークサービスが休止中であれば、サーバはクライアントとの接続が失われたことを認識することができない。そのため、サーバは上述した正常な切断処理を行うことができず、接続が失われたクライアントを接続されているものとして認識し続けることになる。その結果、サーバの資源が無駄に使用されるという問題があった。

この問題を解決する方法として、サーバがクライアントに定期的にpingコマンドを送信し、応答がない場合にはクライアントとの接続は失われたと認識する方法がある。また、クライアントがサーバに定期的に接続通知を送信し、この接続通知が一定時間以上来ない場合には、サーバはクライアントとの接続は失われたと認識する方法も考えられる。

しかし、これらの方法では、サーバ又はクライアントは定期的に接続を確認しなければならない。また、接続が失われてから接続を確認するまでの間、サーバの資源が無駄に使用されることに変わりはなく、また、新たな接続要求に応えることができないという問題もあった。

また、無線ＬＡＮ（ローカルエリアネットワーク）を使用した接続では、外乱の影響により一時的に通信が途絶えている期間中に上述した接続確認が行われると、通信状態が回復すれば正常に動作するにもかかわらず、接続が失われたと誤って認識されるという問題もあった。

特開２０００−１９４６３２号公報 特開２００２−１８２９９８号公報 特開２００２−３２４０４７号公報

本発明の主な目的は、接続が失われたクライアントにより資源が無駄に使用されることのない接続管理機能を有するサーバを提供することである。

本発明のもう１つの目的は、接続が失われていないクライアントを誤って接続が失われたものとして認識することのないサーバを提供することである。

本発明によるサーバは、複数のクライアントに接続可能なサーバであって、接続情報テーブルと、満杯判断手段と、削除手段と、登録手段とを備える。接続情報テーブルは、複数のクライアントの識別情報を登録可能な複数のエントリを有する。満杯判断手段は、クライアントが接続を要求したとき、エントリの全てに識別情報が登録されているか否かを判断する。削除手段は、満杯判断手段による判断の結果、エントリの全てに識別情報が登録されている場合、その登録されている識別情報のいずれかを削除する。登録手段は、満杯判断手段による判断の結果、エントリのいずれかに識別情報が登録されていない場合、又は削除手段が識別情報を削除した場合、接続を要求したクライアントの識別情報を接続情報テーブルに登録する。ここでいうクライアントは、クライアント機器それ自体又はクライアント機器にインストールされたクライアントアプリケーションプログラムである。

このサーバでは、接続可能なクライアントの数が制限されており、接続情報テーブルによりクライアントの接続が管理される。クライアントが接続を要求したとき接続情報テーブルが満杯であれば、登録されている識別情報のいずれかが削除され、接続を要求したクライアントの識別情報が登録される。したがって、接続を要求した新しいクライアントが古いクライアントの代わりにサーバとの接続を確立することができる。その結果、接続が失われた古いクライアントによりサーバの資源が無駄に使用されることはない。また、接続を定期的に確認する方法と異なり、接続が失われていないクライアントを誤って接続が失われたものとして認識することはない。

好ましくは、サーバはさらに、検索手段を備える。検索手段は、接続情報テーブルを検索し、接続を要求したクライアントの識別情報と一致する識別情報が存在するか否かを判断する。検索手段による判断の結果、識別情報が存在する場合、削除手段はその識別情報を削除する。一方、識別情報が存在しない場合、満杯判断手段はエントリの全てに識別情報が登録されているか否かを判断する。

クライアント側で何らかの異常が発生し、接続が失われたクライアントが再びサーバに接続を要求した場合、そのクライアントの識別情報と一致する識別情報が接続情報テーブルに存在することになる。この場合、接続情報テーブルが満杯か否かに関係なく、その一致する識別情報が接続情報テーブルから削除される。したがって、接続が失われたクライアントであってもサーバとの接続を重複することなく再び確立することができる。

好ましくは、エントリの各々はさらに、対応するクライアントの最終アクセス日時を登録可能である。サーバはさらに、接続情報テーブルを検索し、最終アクセス日時が最も古いクライアントを特定する手段を備える。削除手段は、特定されたクライアントの識別情報を削除する。

この場合、サーバにアクセスしていない時間が最も長いクライアントが優先して切断される。したがって、比較的最近サーバにアクセスしたクライアントとの接続は維持される。

好ましくは、サーバはさらに、時期判断手段を備える。時期判断手段は、特定されたクライアントの最も古い最終アクセス日時が予め定められた時期よりも前か否かを判断する。時期判断手段による判断の結果、最も古い最終アクセス日時が予め定められた時期よりも前の場合、削除手段は、特定されたクライアントの識別情報を削除する。

この場合、サーバにアクセスしていない時間が最も長くかつ所定時間よりも長いクライアントが優先して切断される。したがって、サーバにアクセスしていない時間が最も長くても所定時間よりも短ければ、そのクライアントとの接続は維持される。

好ましくは、サーバはさらに、クライアントが接続を要求したとき、そのクライアントとの暫定的な接続を確立する手段と、時期判断手段による判断の結果、最も古い最終アクセス日時が予め定められた時期よりも後の場合、暫定的な接続を取り消す手段とを備える。

この場合、いずれのクライアントについてもサーバにアクセスしていない時間が所定時間よりも短いため、現在のクライアントとの接続は全て維持され、接続を要求したクライアントとの接続は確立されない。よって、接続可能なクライアントの数が制限される。

好ましくは、サーバはさらに、接続判断手段を備える。接続判断手段は、クライアントが要求した接続が最初か否かを判断する。検索手段は、接続判断手段による判断の結果、クライアントが要求した接続が最初の場合、接続を要求したクライアントの識別情報と一致する識別情報が存在するか否かを判断する。

この場合、クライアントが要求した接続が最初の場合だけ、そのクライアントの識別情報と一致する識別情報が削除される。そのため、クライアントとサーバと間に複数の接続が確立される。

好ましくは、識別情報は、クライアントの機器に特有の識別情報と、クライアントの機器にインストールされたアプリケーションに特有の識別情報とを含む。

この場合、１つのクライアントの機器に複数のアプリケーションがインストールされていても、各アプリケーションごとに接続を管理することができる。

本発明によるもう１つのサーバは、複数のクライアントに接続可能なサーバであって、接続情報テーブルと、検索手段と、削除手段と、登録手段とを備える。接続情報テーブルは、複数のクライアントの識別情報を登録可能な複数のエントリを有する。検索手段は、クライアントが接続を要求したとき、接続情報テーブルを検索し、その接続を要求したクライアントの識別情報と一致する識別情報が存在するか否かを判断する。削除手段は、検索手段による判断の結果、識別情報が存在する場合、その識別情報を削除する。登録手段は、削除手段が識別情報を削除した場合、接続を要求したクライアントの識別情報を接続情報テーブルに登録する。

このサーバでは、接続可能なクライアントの数が制限されており、接続情報テーブルによりクライアントの接続が管理される。クライアント側で何らかの異常が発生し、接続が失われたクライアントが再びサーバに接続を要求した場合、そのクライアントの識別情報と一致する識別情報が接続情報テーブルに存在することになる。この場合、その一致する識別情報が接続情報テーブルから削除される。したがって、接続が失われたクライアントであってもサーバとの接続を重複することなく再び確立することができる。その結果、接続が失われた古いクライアントによりサーバの資源が無駄に使用されることはない。また、接続を定期的に確認する方法と異なり、接続が失われていないクライアントを誤って接続が失われたものとして認識することはない。

以下、図面を参照し、本発明の実施の形態を詳しく説明する。図中同一又は相当部分には同一符号を付してその説明は繰り返さない。

［第１の実施の形態］
１．構成
図１を参照して、本発明の第１の実施の形態によるクライアントサーバシステム１０は、サーバ機器ＳＶと、複数のクライアント機器ＣＬ１〜ＣＬｎとを備える。サーバ機器ＳＶ及びクライアント機器ＣＬ１〜ＣＬｎは有線又は無線ＬＡＮ１１により相互に接続される。

サーバ機器ＳＶは、所定のサーバアプリケーションプログラムがインストールされたコンピュータである。サーバ機器とサーバアプリケーションプログラムとを特に区別することなく、単に「サーバ」と呼ぶこともある。

クライアント機器ＣＬ１〜ＣＬｎの各々は、複数のクライアントアプリケーションプログラム（以下「クライアントアプリ」という）がインストールされたコンピュータである。クライアント機器とクライアントアプリとを特に区別することなく、単に「クライアント」と呼ぶこともある。クライアント機器ＣＬ１〜ＣＬｎの各々は、複数のクライアントアプリを同時にかつ独立して実行させることが可能である。

図２を参照して、サーバ機器ＳＶは、ＣＰＵ（中央演算処理装置）１２と、ＲＡＭ（ランダムアクセスメモリ）やＲＯＭ（リードオンリーメモリ）などのメモリ１３と、ハードディスク１４と、ＬＡＮコントローラ１５とを備える。

ハードディスク１４には、接続情報テーブル１７が格納される。接続情報テーブル１７は、図３に示すように、複数のエントリ１６を有する。各エントリ１６には、サーバ機器ＳＶに接続されているクライアントアプリに関する接続情報が登録される。エントリ１６の数は、サーバ機器ＳＶの容量に応じて決定される。本例では、サーバ機器ＳＶに接続可能なクライアントアプリの数は「８個」と予め決定されている。

各エントリ１６には、接続情報として、機器ＩＤ、アプリケーションＩＤ、最終アクセス日時、ソケット番号などが登録される。機器ＩＤは、各クライアント機器ＣＬ１〜ＣＬｎに固有の識別情報で、たとえばネットワークインターフェースのＭＡＣアドレス又はこれから生成したデータ列である。アプリケーションＩＤは、各クライアントアプリに特有の識別情報である。同一クライアント機器内においては、同一アプリケーションＩＤを有する複数のクライアントアプリが存在することは許されない。したがって、機器ＩＤ及びアプリケーションＩＤの組み合わせにより唯一のクライアントアプリが特定され、他のクライアントアプリと区別される。最終アクセス日時は、クライアントアプリがサーバ機器ＳＶにアクセスした最終の日時である。ソケット番号は、接続処理時に生成されるソケットの識別番号である。上述した各エントリ１６の情報は、新規登録、更新及び消去が可能である。

たとえば図４に示すように、クライアントアプリＣＡ１がクライアント機器ＣＬ１にインストールされ、サーバ機器ＳＶに接続されている場合（接続１）、接続情報テーブル１７のエントリ（接続１）には、クライアント機器ＣＬ１の機器ＩＤ（ＭＩＤ１）及びクライアントアプリＣＡ１のアプリケーションＩＤ（ＡＩＤ１）が登録される。また、クライアントアプリＣＡ１がクライアント機器ＣＬ２にインストールされ、サーバ機器ＳＶに接続されている場合（接続２）、接続情報テーブル１７のエントリ（接続２）には、クライアント機器ＣＬ２の機器ＩＤ（ＭＩＤ２）及びクライアントアプリＣＡ１のアプリケーションＩＤ（ＡＩＤ１）が登録される。また、クライアントアプリＣＡ１及びＣＡ２がクライアント機器ＣＬ３にインストールされ、サーバ機器ＳＶに接続されている場合（接続３及び４）、接続情報テーブル１７のエントリ（接続３）には、クライアント機器ＣＬ３の機器ＩＤ（ＭＩＤ３）及びクライアントアプリＣＡ１のアプリケーションＩＤ（ＡＩＤ１）が登録され、接続情報テーブル１７のエントリ（接続４）には、クライアント機器ＣＬ３の機器ＩＤ（ＭＩＤ３）及びクライアントアプリＣＡ２のアプリケーションＩＤ（ＡＩＤ２）が登録される。

サーバ機器ＳＶには、クライアントアプリとの接続管理機能を有するアプリケーションプログラムがインストールされる。このプログラムは、図５に示した各ステップをサーバ機器ＳＶに実行させる。

２．動作
次に、図５のフロー図を参照して、サーバ機器ＳＶの主な動作を説明する。

最初に、サーバ機器ＳＶは接続情報テーブル１７を初期化する（Ｓ１）。具体的には、サーバ機器ＳＶは接続情報テーブル１７の全ての情報を消去し、８個のエントリ１６全てを未接続状態にする。

続いて、サーバ機器ＳＶはクライアントアプリからのアクセス待ちを開始する（Ｓ２）。具体的には、サーバ機器ＳＶはクライアントアプリからコマンドが送信されて来るのを待つ。

サーバ機器ＳＶは、接続要求コマンド、ＩＤ通知コマンド、動作要求コマンド、又は切断要求コマンドを受信すると（Ｓ３〜Ｓ６）、そのコマンドに応じた処理を実行する（Ｓ３０〜Ｓ６０）。

接続要求コマンドは、クライアントアプリがサーバ機器ＳＶに対して接続を要求するために発行するコマンドである。ＩＤ通知コマンドは、接続要求コマンドの発行後、クライアントアプリがサーバ機器ＳＶに対して機器ＩＤ及びアプリケーションＩＤを通知するために発行するコマンドである。動作要求コマンドは、クライアントアプリがサーバ機器ＳＶに対して所望のサービスを要求するために発行するコマンドである。切断要求コマンドは、クライアントアプリがサーバ機器ＳＶに対して切断を要求するために発行するコマンドである。

サーバ機器ＳＶは、接続要求コマンドを受信したか否かを判断する（Ｓ３）。判断の結果、接続要求コマンドを受信した場合、サーバ機器ＳＶは、接続要求コマンドを発行したクライアントアプリに対して暫定接続処理を実行する（Ｓ３０）。詳細は後述する。

サーバ機器ＳＶはまた、ＩＤ通知コマンドを受信したか否かを判断する（Ｓ４）。判断の結果、暫定接続を完了したクライアントアプリからＩＤ通知コマンドを受信した場合、サーバ機器ＳＶは、ＩＤ通知コマンドを発行したクライアントアプリに対して本接続処理を実行する（Ｓ４０）。詳細は後述する。

サーバ機器ＳＶはまた、動作要求コマンドを受信したか否かを判断する（Ｓ５）。判断の結果、本接続を完了したクライアントアプリから動作要求コマンドを受信した場合、サーバ機器ＳＶは、要求されたサービスをクライアントアプリに提供する（Ｓ５０）。詳細は後述する。

サーバ機器ＳＶはまた、切断要求コマンドを受信したか否かを判断する（Ｓ６）。判断の結果、本接続を完了したクライアントアプリから切断要求コマンドを受信した場合、切断処理を実行する（Ｓ６０）。詳細は後述する。

２．１．暫定接続処理
次に、図６及び図７のフロー図を参照して、暫定接続処理（Ｓ３０）の詳細を説明する。

図６を参照して、クライアントアプリは接続要求コマンドをサーバ機器ＳＶに送信する（Ｓ１１）。図５に示した通り、サーバ機器ＳＶは接続要求コマンドを受信すると（Ｓ３）、暫定接続処理を実行する（Ｓ３０）。

具体的には図７を参照して、サーバ機器ＳＶは受信した接続要求コマンドを解析し（Ｓ３０１）、その解析結果に応じて接続要求コマンドを発行したクライアントアプリを接続するためのソケットを作成する（Ｓ３０２）。このとき、作成したソケットにソケット番号を割り当て記憶する。そして、サーバ機器ＳＶは接続受付通知をそのクライアントアプリに返信する（Ｓ３０３）。

暫定接続処理は、クライアントアプリから送信されるＩＤ通知コマンドだけを受付可能にするために、そのクライアントアプリを暫定的に接続する処理である。したがって、仮に暫定的に接続されたクライアントアプリが動作要求コマンドをサーバ機器ＳＶに送信したとしても、サーバ機器ＳＶはこれを受け付けない。

２．２．本接続処理
次に、図６及び図８のフロー図を参照して、本接続処理（Ｓ４０）の詳細を説明する。

図６を参照して、クライアントアプリはサーバ機器ＳＶから接続受付通知を受信すると（Ｓ１２）、機器ＩＤ及びアプリケーションＩＤを含むＩＤ通知コマンドをサーバ機器ＳＶに送信する（Ｓ１３）。図５に示した通り、サーバ機器ＳＶはＩＤ通知コマンドを受信すると（Ｓ４）、本接続処理を実行する（Ｓ４０）。

具体的には図８及び図９を参照して、サーバ機器ＳＶは受信した機器ＩＤ及びアプリケーションＩＤを接続情報テーブル１７の各エントリ１６に登録された機器ＩＤ及びアプリケーションＩＤとそれぞれ比較し、両方が一致する接続を探す（Ｓ４０１）。

続いて、サーバ機器ＳＶは機器ＩＤ及びアプリケーションＩＤの両方が一致する接続が存在するか否かを判断する（Ｓ４０２）。存在する場合は既に本接続処理を済ませたクライアントアプリが再び接続を要求したことを意味し、存在しない場合は未だ本接続処理を済ませていないクライアントアプリが接続を要求したことを意味する。

機器ＩＤ及びアプリケーションＩＤの両方が一致する接続が存在する場合、サーバ機器ＳＶはその古い接続を切断し、そのエントリ内の接続情報を削除する（Ｓ４０３）。

その後、サーバ機器ＳＶは暫定的に接続されたクライアントアプリの機器ＩＤ及びアプリケーションＩＤを接続情報テーブル１７に登録し、かつ登録完了通知をそのクライアントアプリに送信する（Ｓ４０９）。再び図６を参照して、クライアントアプリは登録完了通知を受信すると（Ｓ１６）、サーバ機器ＳＶとの接続を完了したことになる（Ｓ１７）。これにより、クライアントアプリはサーバ機器ＳＶに動作要求コマンドを送信すれば所望のサービスを受けることができる。

一方、機器ＩＤ及びアプリケーションＩＤの両方が一致する接続が存在しない場合、サーバ機器ＳＶは接続情報テーブル１７が満杯か否かを判断する（Ｓ４０４）。具体的には、サーバ機器ＳＶは接続情報テーブル１７の全エントリに接続情報が登録されているか否かを判断する。

接続情報テーブル１７が満杯でない場合、上記と同様に、サーバ機器ＳＶは暫定的に接続されたクライアントアプリの機器ＩＤ及びアプリケーションＩＤを接続情報テーブル１７に登録し、かつ登録完了通知をそのクライアントアプリに送信する（Ｓ４０９）。

一方、接続情報テーブル１７が満杯の場合、サーバ機器ＳＶは接続情報テーブル１７の中から最終アクセス日時が最も古いクライアントアプリを探す（Ｓ４０５）。

続いて、サーバ機器ＳＶはその最も古い最終アクセス日時が２４時間以上前か否かを判断する（Ｓ４０６）。

最も古い最終アクセス日時が２４時間以上経過していない場合、サーバ機器ＳＶは暫定的に接続されたクライアントアプリに接続拒否通知を送信し、上記ステップＳ３０２で作成したソケットを消去して暫定接続を無効にする（Ｓ４０７）。再び図６を参照して、クライアントアプリは接続拒否通知を受信すると（Ｓ１４）、サーバ機器ＳＶとの接続に失敗することになる（Ｓ１５）。

一方、最も古い最終アクセス日時が２４時間以上経過している場合、サーバ機器ＳＶは最終アクセス日時が最も古いクライアントアプリとの接続を切断し、そのエントリ内の接続情報を削除する（Ｓ４０８）。これによりエントリに空きができ、新たに接続情報を登録することができる。

その後、上記と同様に、サーバ機器ＳＶは暫定的に接続されたクライアントアプリの機器ＩＤ及びアプリケーションＩＤを接続情報テーブル１７に登録し、かつ登録完了通知をそのクライアントアプリに送信する（Ｓ４０９）。

続いて、サーバ機器ＳＶはそのクライアントアプリの最終アクセス日時を現在の日時に設定する（Ｓ４１０）。

２．３．サービス処理
次に、図１０のフロー図を参照して、サービス処理（Ｓ５０）の詳細を説明する。

図５に示した通り、サーバ機器ＳＶは動作要求コマンドを受信すると（Ｓ５）、サービス処理を実行する（Ｓ５０）。具体的には、サーバ機器ＳＶは受信した動作要求コマンドを解析し（Ｓ５０１）、それに応じた所定の動作を行うことにより要求されたサービスをクライアントアプリに提供する（Ｓ５０２）。

続いて、サーバ機器ＳＶはそのクライアントアプリの最終アクセス日時を更新する（Ｓ５０３）。

２．４．切断処理
次に、図１１のフロー図を参照して、切断処理（Ｓ６０）の詳細を説明する。

図５に示した通り、サーバ機器ＳＶは切断要求コマンドを受信すると（Ｓ６）、切断処理を実行する（Ｓ６０）。具体的には、サーバ機器ＳＶは受信した切断要求コマンドを解析し（Ｓ６０１）、クライアントアプリとの接続を切断する（Ｓ６０２）。

続いて、サーバ機器ＳＶはそのクライアントアプリの接続情報を削除する（Ｓ６０３）。

３．効果
以上のように本第１の実施の形態によれば、サーバ機器ＳＶは接続情報テーブル１７により接続中のクライアントアプリの機器ＩＤ及びアプリケーションＩＤを管理しているため、クライアントアプリ側で何らかの異常が発生し、クライアントアプリとの接続が失われ、そのクライアントアプリが再び接続を要求してきたとしても、その機器ＩＤ及びアプリケーションＩＤが一致する接続を接続情報テーブル１７から探しているため、その接続を要求してきたクライアントアプリが接続を失ったクライアントアプリであることを認識することができる。そして、サーバ機器ＳＶはそのクライアントアプリとの古い接続を切断し、接続情報テーブル１７から古い接続情報を削除した上で、新しい接続情報を接続情報テーブル１７に登録しているため、サーバ機器ＳＶの資源が無駄に使用されることはない。

また、サーバ機器ＳＶは接続情報テーブル１７が満杯か否かを判断し、満杯の場合、最終アクセス日時が最も古くかつ２４時間以上前のクライアントアプリとの接続を切断し、その接続情報を接続情報テーブル１７から削除した上で、新しい接続情報を接続情報テーブル１７に登録しているため、２４時間以上もアクセスのないクライアントアプリよりも優先して、新たに接続を要求してきたクライアントアプリとの接続を確立することができる。一方、全てのクライアントアプリの最終アクセス日時が２４時間以内の場合、現在のクライアントとの接続は全て維持される。接続を要求したクライアントとの接続は確立されないが、接続可能なクライアントの数は８個以内に制限される。

［第２の実施の形態］
上記第１の実施の形態では、１つのクライアントアプリは同一サーバ機器に対して１つの接続しか確立することができない。もし１つのクライアントアプリが既に確立している接続に加え、さらにもう１つの接続を確立するためにサーバ機器に接続を要求したとすると、サーバ機器は既に確立している接続を切断してしまうからである。本第２の実施の形態は、１つのクライアントアプリが同一サーバ機器に対して複数の接続を確立できるようにしたものである。

図１２に示すように、第２の実施の形態における接続情報テーブル１７の各エントリ１６には、図３に示した情報に加え、接続ＩＤが登録される。接続ＩＤは、１つクライアントアプリと１つのサーバ機器との間で確立される複数の接続にそれぞれ付与される識別情報である。

たとえば図１３に示した例では、クライアント機器ＣＬ１にインストールされたクライアントアプリＣＡ１とサーバ機器ＳＶとの間に、１つの主接続（接続１）と２つの副接続（接続２，３）とが確立されている。また、クライアント機器ＣＬ３にインストールされたクライアントアプリＣＡ２とサーバ機器ＳＶとの間に、１つの主接続（接続４）と１つの副接続（接続５）とが確立されている。

主接続は、たとえばサーバ機器ＳＶに蓄積されているコンテンツのライブラリ情報（ファイル名、ディレクトリなど）をクライアントアプリＣＡ１，ＣＡ２がサーバ機器ＳＶから取得するための接続である。１つの副接続は、たとえばサーバ機器ＳＶからクライアントアプリＣＡ１，ＣＡ２にオーディオデータをストリーム転送するための接続である。もう１つの副接続は、たとえばサーバ機器ＳＶからクライアントアプリＣＡ１に静止画を転送するための接続である。まず主接続が確立され、次に副接続が確立される。

この場合、接続情報テーブル１７の接続１〜３の３つのエントリ１６には、同じ機器ＩＤ（ＭＩＤ１）及びアプリケーションＩＤ（ＡＩＤ１）が登録される。ただし、接続１のエントリ１６には接続ＩＤ（ＣＩＤ０）が登録され、接続２のエントリ１６には接続ＩＤ（ＣＩＤ１）が登録され、接続３のエントリ１６には接続ＩＤ（ＣＩＤ２）が登録される。また、接続情報テーブル１７の接続４及び５の２つのエントリ１６には、同じ機器ＩＤ（ＭＩＤ３）及びアプリケーションＩＤ（ＡＩＤ２）が登録される。ただし、接続４のエントリ１６には接続ＩＤ（ＣＩＤ０）が登録され、接続５のエントリ１６には接続ＩＤ（ＣＩＤ１）が登録される。

次に、主接続及び副接続を確立するためのクライアントアプリの動作を図１４及び図１５を参照して説明する。図１５に示したフロー図では、図６に示したフロー図にステップＳ１８〜Ｓ２０が追加されている。

最初にクライアントアプリは主接続の確立を試みる（Ｓ２１）。接続処理は図６に示した第１の実施の形態とほぼ同じであるが、図１５に示すように主接続の場合（Ｓ１８でＹＥＳ）、クライアントアプリは接続ＩＤを「０」に設定する（Ｓ１９）。そして、クライアントアプリは、機器ＩＤ及びアプリケーションＩＤ以外に、接続ＩＤ（ＣＩＤ０）を含むＩＤ通知コマンドをサーバ機器ＳＶに送信する（Ｓ１３）。

主接続に成功すると（Ｓ２２）、クライアントアプリはその主接続を用いてサーバ機器ＳＶからライブラリ情報を取得する（Ｓ２３）。

続いて、ユーザが所望のコンテンツを選択すると（Ｓ２４）、クライアントアプリはストリーム転送用の副接続の確立を試みる（Ｓ２５）。接続処理は図６に示した第１の実施の形態とほぼ同じであるが、図１５に示すように副接続の場合（Ｓ１８でＮＯ）、クライアントアプリは接続ＩＤをインクリメントする（Ｓ２０）。そして、クライアントアプリは、機器ＩＤ及びアプリケーションＩＤ以外に、接続ＩＤ（ＣＩＤ１）を含むＩＤ通知コマンドをサーバ機器ＳＶに送信する（Ｓ１３）。

副接続に成功すると（Ｓ２６）、クライアントアプリはその副接続を用いてサーバ機器ＳＶからオーディオデータをストリーム転送しながら音楽を再生する（Ｓ２７）。再生が完了又は強制的に停止されると（Ｓ２８）、クライアントアプリはその副接続を切断する（Ｓ２９）。

次に、上記主接続及び副接続に対応するサーバ機器ＳＶの動作を図１６を参照して説明する。図１６に示したフロー図では、図８に示したフロー図にステップＳ４００，Ｓ４１１〜Ｓ４１４が追加されている。

上記ステップＳ１３でクライアントアプリから送信されたＩＤ通知コマンドに応答して、クライアントアプリが要求している接続は主接続か否かをサーバ機器ＳＶが判断する（Ｓ４００）。具体的には、サーバ機器ＳＶはＩＤ通知コマンドに含まれる接続ＩＤが「０」か否かを判断する。主接続（ＣＩＤ０）の場合は次のステップＳ４０１に進み、副接続（ＣＩＤ１，ＣＩＤ２）の場合はステップＳ４０１及びＳ４０２をスキップしてステップＳ４０４に進む。

主接続の場合、つまりクライアントアプリがサーバ機器ＳＶに最初の接続を要求して来ている場合、サーバ機器ＳＶはＩＤ通知コマンドに含まれる機器ＩＤ及びアプリケーションＩＤを接続情報テーブル１７の各エントリ１６に登録された機器ＩＤ及びアプリケーションＩＤとそれぞれ比較し、両方が一致する主接続を探す（Ｓ４０１）。両方が一致する主接続が存在する場合（Ｓ４０２でＹＥＳ）、サーバ機器ＳＶはその古い主接続を切断し、そのエントリ内の接続情報を削除する（Ｓ４０３）。

続いて、サーバ機器ＳＶは接続ＩＤをインクリメントし（Ｓ４１１）、ステップＳ４０１に戻る。すなわち、サーバ機器ＳＶは機器ＩＤ及びアプリケーションＩＤの両方が一致する副接続を探し（Ｓ４０１）、両方が一致する副接続が存在する場合（Ｓ４０２でＹＥＳ）、サーバ機器ＳＶはその副接続を切断し、そのエントリ内の接続情報を削除する（Ｓ４０３）。

要するに、既に主接続処理を済ませたクライアントアプリが再び主接続を要求して来たとき、サーバ機器ＳＶはその古い主接続を接続情報テーブル１７から削除し、さらにその主接続に従属する全ての副接続を接続情報テーブル１７から削除する。

次に、サーバ機器ＳＶは接続情報テーブル１７が満杯か否かを判断し（Ｓ４０４）、満杯の場合、再びクライアントアプリが要求している接続が主接続か否かを判断する（Ｓ４１２）。主接続（ＣＩＤ０）の場合は次のステップＳ４０５に進み、副接続（ＣＩＤ１，ＣＩＤ２）の場合はステップＳ４０７に進む。

主接続の場合（Ｓ４１２でＹＥＳ）、サーバ機器ＳＶは、最終アクセス日時が最も古く２４時間以上経過している主接続を接続情報テーブル１７から削除した後（Ｓ４０８）、その削除した主接続と機器ＩＤ及びアプリケーションＩＤの両方が一致する接続（副接続）が存在するか否かを判断する（Ｓ４１３）。存在する場合（Ｓ４１３でＹＥＳ）、サーバ機器ＳＶはその一致する接続（副接続）を接続情報テーブル１７から削除する（Ｓ４１４）。そして、サーバ機器ＳＶは接続ＩＤをインクリメントし（Ｓ４１５）、ステップＳ４１３に戻る。その結果、サーバ機器ＳＶは、削除した主接続に従属する全ての副接続を接続情報テーブル１７から削除する。

その後、サーバ機器ＳＶは暫定的に接続されたクライアントアプリの機器ＩＤ及びアプリケーションＩＤを接続情報テーブル１７に登録し、かつ登録完了通知をそのクライアントアプリに送信し（Ｓ４０９）、そのクライアントアプリの最終アクセス日時を現在の日時に設定する（Ｓ４１０）。

一方、クライアントアプリが要求している接続が副接続の場合（Ｓ４１２でＮＯ）、サーバ機器ＳＶは暫定的に接続されたクライアントアプリに接続拒否通知を送信し、上記ステップＳ３０２で作成したソケットを消去して暫定接続を無効にする（Ｓ４０７）。

以上のように本第２の実施の形態によれば、クライアントアプリが要求している接続が主接続か否かを判断し（Ｓ４０１）、主接続の場合だけ機器ＩＤ及びアプリケーションＩＤが一致する接続を削除し（Ｓ４０３）、副接続の場合は、たとえ機器ＩＤ及びアプリケーションＩＤが一致する接続が存在していてもその接続を削除しない。そのため、１つのクライアントアプリと１つのサーバ機器との間に、主接続に加え、副接続を確立することができる。

なお、上記第１及び第２の実施の形態では、エントリ１６の数は８個であるが、この数はサーバ機器ＳＶの容量に応じて任意に設定、変更することが可能である。また、クライアントアプリがサーバ機器ＳＶにアクセスしていない時間が２４時間以上であるときそのクライアントアプリとの接続を切断しているが、この時間も任意に設定、変更することが可能である。また、クライアント機器ＣＬ１〜ＣＬｎの各々にクライアントアプリが複数インストールされているが、１つだけインストールされていてもよい。この場合、アプリケーションＩＤは不要である。

以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。

本発明による接続管理機能を有するサーバは、たとえば、多数の音楽コンテンツを蓄積したサーバと、サーバから配信された音楽コンテンツに基づいて音楽を再生するオーディオクライアントとを備えたネットワークオーディオシステムに利用可能である。

本発明の第１の実施の形態によるクライアントサーバシステムの全体構成を示す機能ブロック図である。 図１中のサーバ機器の構成を示す機能ブロック図である。 図１中のサーバ機器に登録される接続情報テーブルの構成を示す図である。 図１中のサーバ機器とクライアント機器との接続例を示す機能ブロック図である。 図１中のサーバ機器の動作を示すフロー図である。 図１中のクライアント機器の動作を示すフロー図である。 図５中の暫定接続処理の詳細を示すフロー図である。 図５中の本接続処理の詳細を示すフロー図である。 図８中のステップＳ４０１を説明するための図である。 図５中のサービス処理の詳細を示すフロー図である。 図５中の切断処理の詳細を示すフロー図である。 本発明の第２の実施の形態における接続情報テーブルの構成を示す図である。 本発明の第２の実施の形態におけるサーバ機器とクライアント機器との接続例を示す機能ブロック図である。 本発明の第２の実施の形態におけるクライアント機器の動作を示すフロー図である。 図１４中の主接続又は副接続の動作を示すフロー図である。 本発明の第２の実施の形態におけるサーバ機器の本接続処理を示すフロー図である。

符号の説明

１０ クライアントサーバシステム
１６ エントリ
ＣＬ１-ＣＬｎ クライアント機器
ＳＶ サーバ機器

Claims (10)

1. 複数のクライアントに接続可能なサーバであって、
   前記複数のクライアントの識別情報を登録可能な複数のエントリを有する接続情報テーブルと、
   前記クライアントが接続を要求したとき、前記エントリの全てに識別情報が登録されているか否かを判断する満杯判断手段と、
   前記満杯判断手段による判断の結果、前記エントリの全てに識別情報が登録されている場合、その登録されている識別情報のいずれかを削除する削除手段と、
   前記満杯判断手段による判断の結果、前記エントリのいずれかに識別情報が登録されていない場合、又は前記削除手段が識別情報を削除した場合、前記接続を要求したクライアントの識別情報を前記接続情報テーブルに登録する登録手段とを備えたことを特徴とする接続管理機能を有するサーバ。
2. 請求項１に記載のサーバであってさらに、
   前記接続情報テーブルを検索し、前記接続を要求したクライアントの識別情報と一致する識別情報が存在するか否かを判断する検索手段を備え、
   前記検索手段による判断の結果、前記識別情報が存在する場合、前記削除手段は、その識別情報を削除し、
   前記検索手段による判断の結果、前記識別情報が存在しない場合、前記満杯判断手段は、前記エントリの全てに識別情報が登録されているか否かを判断することを特徴とする接続管理機能を有するサーバ。
3. 請求項１又は請求項２に記載のサーバであって、
   前記エントリの各々はさらに、対応するクライアントの最終アクセス日時を登録可能で、
   前記サーバはさらに、
   前記接続情報テーブルを検索し、前記最終アクセス日時が最も古いクライアントを特定する手段を備え、
   前記削除手段は、前記特定されたクライアントの識別情報を削除することを特徴とする接続管理機能を有するサーバ。
4. 請求項３に記載のサーバであってさらに、
   前記特定されたクライアントの最も古い最終アクセス日時が予め定められた時期よりも前か否かを判断する時期判断手段を備え、
   前記時期判断手段による判断の結果、前記最も古い最終アクセス日時が前記予め定められた時期よりも前の場合、前記削除手段は、前記特定されたクライアントの識別情報を削除することを特徴とする接続管理機能を有するサーバ。
5. 請求項４に記載のサーバであってさらに、
   前記クライアントが接続を要求したとき、そのクライアントとの暫定的な接続を確立する手段と、
   前記時期判断手段による判断の結果、前記最も古い最終アクセス日時が前記予め定められた時期よりも後の場合、前記暫定的な接続を取り消す手段とを備えたことを特徴とする接続管理機能を有するサーバ。
6. 請求項２に記載のサーバであってさらに、
   前記クライアントが要求した接続が最初か否かを判断する接続判断手段を備え、
   前記検索手段は、前記接続判断手段による判断の結果、前記クライアントが要求した接続が最初の場合、前記接続を要求したクライアントの識別情報と一致する識別情報が存在するか否かを判断することを特徴とする接続管理機能を有するサーバ。
7. 請求項１〜請求項６のいずれか１項に記載のサーバであって、
   前記識別情報は、前記クライアントの機器に特有の識別情報と、前記クライアントの機器にインストールされたアプリケーションに特有の識別情報とを含むことを特徴とする接続管理機能を有するサーバ。
8. 複数のクライアントに接続可能なサーバであって、
   前記複数のクライアントの識別情報を登録可能な複数のエントリを有する接続情報テーブルと、
   前記クライアントが接続を要求したとき、前記接続情報テーブルを検索し、その接続を要求したクライアントの識別情報と一致する識別情報が存在するか否かを判断する検索手段と、
   前記検索手段による判断の結果、前記識別情報が存在する場合、その識別情報を削除する削除手段と、
   前記削除手段が識別情報を削除した場合、前記接続を要求したクライアントの識別情報を前記接続情報テーブルに登録する登録手段とを備えたことを特徴とする接続管理機能を有するサーバ。
9. 請求項８に記載のサーバであってさらに、
   前記クライアントが要求した接続が最初か否かを判断する接続判断手段を備え、
   前記検索手段は、前記接続判断手段による判断の結果、前記クライアントが要求した接続が最初の場合、前記接続を要求したクライアントの識別情報と一致する識別情報が存在するか否かを判断することを特徴とする接続管理機能を有するサーバ。
10. 請求項１〜請求項９のいずれか１項に記載のサーバとしてコンピュータを機能させるためのプログラム。
    

Images