サーバー及びデータ受信方法
【課題】アプリケーションプログラムがサポートするＩＰバージョンに依存せずにデータを受信する。
【解決手段】アプリケーションプログラム（ＡＰＰ）１８の識別情報とＡＰＰ１８がサポートするＩＰバージョンとをデータベース１５に登録する。データベース１５を参照し、ＡＰＰ１８用のソケットであって、ＡＰＰ１８がサポートするＩＰバージョンに対応したソケットを生成する。ＡＰＰ１８は、生成されたソケットを介してデータを受信する。
【解決手段】アプリケーションプログラム（ＡＰＰ）１８の識別情報とＡＰＰ１８がサポートするＩＰバージョンとをデータベース１５に登録する。データベース１５を参照し、ＡＰＰ１８用のソケットであって、ＡＰＰ１８がサポートするＩＰバージョンに対応したソケットを生成する。ＡＰＰ１８は、生成されたソケットを介してデータを受信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションプログラムがサポートするＩＰバージョンに依存せずにデータを受信するための技術に関する。
【背景技術】
【０００２】
ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）のバージョンは、従来から利用されているＩＰｖ４（ＩＰバージョン４）と、近年導入が進んでいるＩＰｖ６（ＩＰバージョン６）とがある。ＩＰｖ４からＩＰｖ６への移行期においては、ＩＰｖ４とＩＰｖ６とが併存する。
【０００３】
そこで、特許文献１には、ＩＰｖ４パケット処理部とＩＰｖ６パケット処理部を共通化したネットワークデバイスが記載されている。
【０００４】
また、アプリケーションプログラムには、ＩＰｖ４のみサポートするもの、ＩＰｖ６のみサポートするもの（以上、シングルスタック）、及びＩＰｖ４及びＩＰｖ６の両方をサポートするもの（デュアルスタック）が存在する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１−１８６１８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
各アプリケーションプログラムは、自らがサポートしているＩＰバージョンに対応したソケットを作成し、それぞれの受信処理を行う必要がある。つまり、デュアルスタックであれば、一つのアプリケーションが二つのソケットを作成し、それぞれの受信処理を行う必要がある。これらの処理は、それぞれのアプリケーションプログラムに実装されている。従って、あるアプリケーションプログラムにおいてサポートするＩＰバージョンを変更する場合には、プログラムの修正が必要となる。
【０００７】
また、一般に、ソフトウェアを開発する際、利用するＩＰバージョンを意識しない、つまりＩＰバージョンに依存しない実装にすることが望ましい。一方で、デュアルスタックのアプリケーションプログラムでは、ＩＰｖ４、ＩＰｖ６でそれぞれ異なるモジュールにデータを受信させたい場合もある。
【０００８】
そこで、本発明の目的は、アプリケーションプログラムがサポートするＩＰバージョンに依存せずにデータを受信することである。
【０００９】
本発明の別の目的は、ＩＰバージョンに依存してデータを受信するモジュールが異なるようなアプリケーションプログラムの場合には、ＩＰバージョンを把握できるようにすることである。
【課題を解決するための手段】
【００１０】
本発明の一つの実施態様に従う、アプリケーションプログラムが動作しているサーバーは、前記アプリケーションプログラムの識別情報と前記アプリケーションプログラムがサポートするＩＰバージョンとを対応付けて記憶したデータベースと、前記データベースを参照し、前記アプリケーションプログラム用のソケットであって前記ＩＰバージョンに対応したソケットを生成するソケットユーティリティーと、を備え、前記アプリケーションプログラムは、前記生成されたソケットを介してデータを受信する。
【００１１】
これにより、アプリケーションプログラムは、自らがサポートしているＩＰバージョンに依存することなくデータを受信できる。
【００１２】
好適な実施形態では、前記生成されたソケットのソケットハンドルを取得し、前記ソケットハンドルに含まれている前記アプリケーションプログラムの識別情報により定まるアプリケーションプログラムを呼び出すディスパッチャーを、さらに備え、前記呼び出されたアプリケーションプログラムが前記生成されたソケットを介してデータを受信するようにしてもよい。
【００１３】
これにより、ディスパッチャーが存在する場合であっても、アプリケーションプログラムは、自らがサポートしているＩＰバージョンに依存することなくデータを受信できる。
【００１４】
好適な実施形態では、前記ディスパッチャーは、前記ソケットハンドルに含まれている、前記アプリケーションプログラムがサポートするＩＰバージョンに対応する前記アプリケーションプログラムのモジュールを呼び出すようにしてもよい。
【００１５】
これにより、アプリケーションプログラムがＩＰバージョンに応じて異なるモジュールがデータを受信する場合でも、ディスパッチャーがＩＰバージョンを把握できるので、適切なモジュールがデータを受信できる。
【００１６】
好適な実施形態では、前記ＩＰバージョンは、ＩＰｖ４またはＩＰｖ６であってもよい。
【００１７】
好適な実施形態では、前記アプリケーションプログラムが、ＩＰｖ４及びＩＰｖ６の双方をサポートするデュアルスタックである場合、前記データベースには、前記アプリケーションプログラムの識別情報に、ＩＰｖ４を示す情報及びＩＰｖ６を示す情報が対応付けて登録されていて、前記ソケットユーティリティーは、ＩＰｖ４に対応するソケット及びＩＰｖ６に対応するソケットを生成してもよい。
【００１８】
これにより、デュアルスタックのアプリケーションプログラムは、ＩＰｖ４に対応するソケット及びＩＰｖ６に対応するソケットがそれぞれ自動的に生成される。
【００１９】
好適な実施形態では、前記ソケットユーティリティーは、前記アプリケーションプログラムに、前記ＩＰｖ４に対応するソケット及び前記ＩＰｖ６に対応するソケットを交互に利用させてデータを受信させるようにしてもよい。
【００２０】
これにより、デュアルスタックのアプリケーションプログラムは、ＩＰｖ４及びＩＰｖ６で、それぞれほぼ均等にデータを受信することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の第１の実施形態に係るサーバーで機能する各プログラムのプロトコル階層図。
【図２】本発明の第２の実施形態に係るサーバーで機能する各プログラムのプロトコル階層図。
【図３】サーバーがネットワークを介して接続されたクライアントと通信を行うときの処理手順を示すフローチャート
【図４】受信ポートの登録処理の詳細な手順を示すフローチャート。
【図５】受信ソケットの選択処理の詳細な手順を示すフローチャート。
【図６】本発明の実施例におけるネットワークシステムの概略構成図。
【図７】クライアントの内部構成を示す説明図。
【図８】プリントサーバー装置の内部構成を示す説明図。
【図９】プリンターの内部構成を示す説明図。
【図１０】登録テーブル１２５の具体例を概念的に示す説明図。
【図１１】サーバー装置の起動処理の処理ルーチンを示すフローチャート。
【図１２】ＨＴＴＰリクエストに対する処理の処理ルーチンを示すフローチャート。
【図１３】ＨＴＴＰリクエストの一例を概念的に示す説明図。
【発明を実施するための形態】
【００２２】
以下、本発明の一実施形態に係るサーバー及びネットワークシステムについて、図面を参照して説明する。
【００２３】
本実施形態に係るサーバーは、例えば、ＣＰＵ、メモリー及びネットワーク通信装置などを備えた汎用的なコンピュータシステムにより構成され、以下に説明する個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。
【００２４】
図１は、本発明の第１の実施形態に係るサーバーで機能する各プログラムのプロトコル階層を示す図である。
【００２５】
同図に示すように、サーバー１では、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）１１と、ソケットユーティリティー１２と、データベース１５と、複数のアプリケーションプログラム（ＡＰＰ）１８とが実行されている。
【００２６】
ＯＳ１１には、ＴＣＰ／ＩＰスタック１１ａが含まれている。ＴＣＰ／ＩＰスタック１１ａにおけるＩＰスタックには、ＩＰｖ４スタックとＩＰｖ６スタックとが含まれる。
【００２７】
各ＡＰＰ１８は、それぞれ所定の処理を行う。各ＡＰＰ１８は、ＩＰｖ４またはＩＰｖ６のいずれか、または双方をサポートしている。すなわち、各ＡＰＰ１８は、ＩＰｖ４またはＩＰｖ６のみをサポートするシングルスタックか、またはｖ４及びｖ６の両方をサポートするデュアルスタックである。
【００２８】
データベース１５には、各ＡＰＰ１８がサポートしているＩＰバージョンが、各ＡＰＰ１８のサービス名（識別情報）と対応付けて登録されている。この登録は、例えば、各ＡＰＰ１８の起動時に行うようにしても良い。
【００２９】
ソケットユーティリティー１２は、ＡＰＰ１８がＴＣＰ／ＩＰで通信を行うためのソケットを生成する。例えば、ソケットユーティリティー１２は、ＡＰＰ１８のサービス名とそのＡＰＰ１８のためのポート番号を取得すると、データベース１５を参照して、ＡＰＰ１８のサービス名と対応付けられているＩＰバージョンを取得する。そして、ソケットユーティリティー１２は、上記の取得した情報に基づいて、ソケットを生成する。例えば、デュアルスタックのＡＰＰ１８ａのサービス名を取得すると、ソケットユーティリティー１２は、ＡＰＰ１８ａ用のＩＰｖ４対応のソケットとＩＰｖ６対応のソケットを生成する。つまり、ソケットユーティリティー１２は、ＡＰＰ１８ａ向けのポート番号を確保しＩＰｖ４のＩＰアドレス及びこのポート番号に基づいてＩＰｖ４用ソケットを生成する。さらに、ソケットユーティリティー１２は、ＩＰｖ６のＩＰアドレス及びＩＰｖ４と同じポート番号でＩＰｖ６用ソケットを生成する。
【００３０】
これにより、各ＡＰＰ１８が自らソケット生成を行わなくても、ソケットユーティリティー１２が全ＡＰＰ１８に適したソケットを生成し、各ＡＰＰ１８がそのソケットを利用して自在に通信を行うことができる。また、各ＡＰＰ１８が、自らがサポートするＩＰバージョンをデータベース１５に登録すれば、ソケットユーティリティー１２によって、登録されているＩＰバージョンに対応するソケットを自動的に生成される。その結果、各ＡＰＰ１８は、通信を行う際にはＩＰバージョンに依存せずに通信を行うことができる。
【００３１】
次に、図２は、本発明の第２の実施形態に係るサーバーで機能する各プログラムのプロトコル階層を示す図である。
【００３２】
本実施形態では、ソケットユーティリティー１２上でディスパッチャーが動作する場合のプロトコル階層を示す。ディスパッチャーは、上位のアプリケーションへのデリバリー条件を判断するためにＩＰバージョンを必要とする場合がある。例えば、デュアルスタックのアプリケーションが、ＩＰのバージョンに応じて異なる処理を用意しているときは、ディスパッチャーが、受信データが転送されてきたＩＰバージョンに対応する処理を呼び出す。そのために、本実施形態では、ソケットユーティリティー１２からディスパッチャーへＩＰバージョンを通知する。ここでは、ディスパッチャーとしてＨＴＴＰサーバーを用いた場合を例にとって説明する。
【００３３】
なお、本実施形態において、第１の実施形態と同じ構成については、同じ符号を付して詳細な説明を省略する場合がある。
【００３４】
図２に示すように、サーバー１では、ＯＳ１１と、ソケットユーティリティー１２と、ＨＴＴＰサーバー１３と、ＷＥＢサーバー１４と、データベース１５と、複数のアプリケーションプログラム（ＡＰＰ）１８とが実行されている。
【００３５】
本実施形態では、データベース１５には、ＨＴＴＰサーバー１３が、ＩＰｖ４及びＩＰｖ６をサポートするデュアルスタックとして登録される。さらに、各ＡＰＰ１８がサポートしているＩＰバージョンは、各ＡＰＰ１８のサービス名と対応付けてＨＴＴＰサーバー１３の管理下に登録される。デュアルスタックのＡＰＰ１８については、それぞれのＩＰバージョンに対応するモジュール名などがＨＴＴＰサーバー１３の管理下に登録される。これによって、各ＡＰＰ１８に対するリクエスト及び各ＡＰＰ１８が発行するリクエストは、すべてＨＴＴＰサーバー１３を介して通信される。つまり、ＨＴＴＰサーバー１３は、ソケットユーティリティー１２に対するインターフェースとなる。
【００３６】
ソケットユーティリティー１２は、第１の実施形態と同様に、データベース１５を参照して、ソケットを生成する。ここでは、ソケットユーティリティー１２は、各ＡＰＰ１８のためのポート番号をそれぞれ取得して、各ポート番号に対して、ＨＴＴＰサーバー１３の向けのＩＰｖ４及びＩＰｖ６のソケットを生成する。ここで生成された各ソケットがデータを受信した際、そのソケットのソケットハンドルには、少なくとも、ＩＰバージョン、送信元アドレス、送信元ポート、及び自らのサービス名が格納される。ＨＴＴＰサーバー１３は、このソケットハンドルを取得することにより、そのソケットが受信したデータの送信元を把握できるとともに、ＩＰバージョンを把握することもできる。ＨＴＴＰサーバー１３は、ソケットハンドルに含まれる情報に対応するＡＰＰ１８のモジュールを呼び出す。例えば、ソケットハンドルに含まれるサービス名（または受信ポート番号）によってＡＰＰ１８が特定され、ＩＰバージョンによってその特定されたＡＰＰ１８のいずれのモジュールを呼び出すかが特定される。
【００３７】
例えば、あるＡＰＰ１８ｂがＩＰｖ４のみをサポートするシングルスタックであるときでも、そのＡＰＰ１８ｂに対応する、ＨＴＴＰサーバー１３のソケットは２つ生成される（つまり、ＨＴＴＰサーバー１３としてはデュアルスタック）。そして、ＨＴＴＰサーバー１３が、例えば、ＩＰｖ４でＡＰＰ１８ｂに対するリクエストを受信すると、ＨＴＴＰサーバー１３はＡＰＰ１８ｂを呼び出し、ＩＰｖ６でＡＰＰ１８ｂに対するリクエストを受信すると、ＨＴＴＰサーバー１３はＡＰＰ１８ｂを呼び出さず、そのリクエストは無視される。
【００３８】
また、あるＡＰＰ１８ｃがＩＰｖ４及びＩＰｖ６をサポートするデュアルスタックであるときは、ＨＴＴＰサーバー１３にＩＰｖ４のときに呼び出すモジュール及びＩＰｖ６のときに呼び出すモジュールをそれぞれ登録しておくと、ＨＴＴＰサーバー１３は、受信したソケットに対応するモジュールを呼び出す。
【００３９】
このようにすると、ＩＰｖ４でデータを受信した場合とＩＰｖ６でデータを受信した場合で、異なるモジュールにデータを受信させることができる。これにより、同一のＡＰＰであって、ＩＰｖ４でデータを受信した場合とＩＰｖ６でデータを受信した場合で、別々の処理を実行することができる。
【００４０】
次に、上述した第１及び第２の実施形態におけるデータ受信処理の処理手順を図３〜図５のフローチャートを参照して説明する。
【００４１】
図３は、図１及び図２に示すプロトコル階層に従うプログラムが、ネットワークを介して接続されたクライアントと通信を行うときの処理手順を示すフローチャートである。
【００４２】
まず、サーバー１の起動時に、ソケットユーティリティー１２は初期化処理を行う（Ｓ１０）。この初期化処理には、例えば、各ＡＰＰ１８が自らのサービス名及びサポートするＩＰバージョンをデータベース１５に登録する処理を含む。次に、ソケットユーティリティー１２は、受信ポートごとにソケットを生成して、受信ポートの登録処理を行う（Ｓ１２）。受信ポートの登録処理の詳細は後述する。ソケットユーティリティー１２は、すべての受信ポートの登録処理が完了するまで、ステップＳ１２を繰り返して行う（Ｓ１４）。
【００４３】
全受信ポートの登録が完了すると（Ｓ１４：Ｙｅｓ）、ステップＳ１２で生成したソケットでのデータ受信及び受信ソケットの選択処理を行う（Ｓ１６）。受信ソケットの選択処理の詳細は後述する。
【００４４】
ステップＳ１６で選択されたソケットを使って、受信したデータに基づいてＡＰＰ１８が通信処理を行う（Ｓ１８）。ソケットユーティリティー１２が終了するまでの間、ステップＳ１６及びＳ１８の処理が繰り返される（Ｓ２０）。
【００４５】
図４は、ステップＳ１２の受信ポートの登録処理の詳細な手順を示すフローチャートである。
【００４６】
まず、ソケットユーティリティー１２は、サーバー１で動作しているＡＰＰ１８のサービス名及びそのＡＰＰ１８が使用する受信ポート番号を取得する（Ｓ１２０）。ソケットユーティリティー１２は、データベース１５を参照して、ステップＳ１２０で取得したサービス名のＡＰＰ１８がサポートするＩＰバージョンを特定する（Ｓ１２２）。そして、ソケットユーティリティー１２がソケットを生成し（S１２４）、生成したソケットの受信ポート番号及びＩＰバージョンに、それぞれステップＳ１２０，Ｓ１２２で取得した受信ポート番号及びＩＰバージョンを設定する（Ｓ１２６）。
【００４７】
ソケットユーティリティー１２は、ステップＳ１２２で取得したすべてのＩＰバージョンの設定が完了したか否かを判定する（Ｓ１２８）。未設定のＩＰバージョンがあれば（Ｓ１２８：Ｎｏ）、ステップＳ１２４以降を繰り返し、全ＩＰバージョンについてソケットを生成する。たとえば、デュアルスタックのＡＰＰであれば、それぞれのＩＰバージョンに対するソケットを生成する。
【００４８】
最後に、ソケットユーティリティー１２は、この処理で生成した全ソケットに関する情報を、所定の記憶部に登録する（Ｓ１３０）。
【００４９】
図５は、ステップＳ１６の受信ソケットの選択処理の詳細な手順を示すフローチャートである。
【００５０】
まず、ソケットユーティリティー１２は、ステップＳ１２で登録されたソケットを、受信待ちソケットとして設定する（Ｓ１６０）。ここで、各ソケットは、データ受信待ち状態となる（Ｓ１６２、Ｓ１６４）。そして、いずれかのソケットにデータが到着すると（Ｓ１６４：Ｙｅｓ）、ソケットユーティリティー１２は、受信したソケットが前回通信したソケットであるか否かを判定する（Ｓ１６６）。
【００５１】
例えば、デュアルスタックのＡＰＰ１８の場合、そのＡＰＰ１８用のソケットは二つある。このとき、ＡＰＰ１８が一方のソケットのみを連続して用いて通信を行うと、他方のソケットにデータが到着していても、ＡＰＰ１８と通信が行われないということが起こりうる。そこで、本実施形態では、これを防止するために、二つのソケットに交互に通信を行わせる様に調整する。そのため、ステップＳ１６６では、デュアルスタックのＡＰＰ１８について、今回データを受信したソケットが前回通信したソケットであるか否かを判定する。ここで、今回データを受信したソケットが前回通信をしたソケットでないときは（Ｓ１６６：Ｎｏ）、以降の処理をスキップし、当該ソケットが通信を行うソケットとして選択される。なお、シングルスタックの場合には、ステップＳ１６６の判定は常にＮｏである。
【００５２】
一方、今回データを受信したソケットが前回通信をしたソケットであるときは（Ｓ１６６：Ｙｅｓ）、ソケットユーティリティー１２は、前回通信をしたソケット以外の他のソケットにデータが到着しているか否かを判定する（Ｓ１６８）。他のソケットにデータが到着してれば（Ｓ１６８：Ｙｅｓ）、そのデータが到着している他のソケットを通信対象のソケットとして設定する（Ｓ１７０）。他のソケットにデータが到着していなければ（Ｓ１６８：Ｎｏ）、ステップＳ１７０をスキップし、データが到着しているソケットを通信対象のソケットとして選択する。
【００５３】
これにより、デュアルスタックの場合に、一つのソケットだけが集中して通信を行い、他のソケットが通信できないということを防止できる。
【００５４】
次に、上述の第２の実施形態で説明したプロトコル階層に基づく一つの実施例について説明する。
【００５５】
図６は、本発明の実施例におけるネットワークシステムの概略構成図である。ネットワークシステム１０００は、図６に示すように、クライアントコンピュータ（以下、単にクライアントという。）ＣＬ１、ＣＬ２と、サーバー装置１００と、プリンターＰＲＴ１、ＰＲＴ２を含む。クライアントＣＬ１、ＣＬ２と、サーバー装置１００とは、ローカルエリアネットワーク（ＬＡＮ）に、それぞれ接続されている。プリンターＰＲＴ１、ＰＲＴ２は、それぞれ、ＵＳＢ（Universal Serial Bus）ケーブルＣＶを用いてサーバー装置１００に接続されている。サーバー装置１００は、クライアントＣＬ１、ＣＬ２から印刷要求を受け付け、プリンターＰＲＴ１、ＰＲＴ２を用いて印刷を実行するプリントサーバーとして機能する。すなわち、プリンターＰＲＴ１、ＰＲＴ２は、その印刷機能を、サーバー装置１００を介して、クライアントＣＬ１、ＣＬ２に提供する。
【００５６】
図７〜図９を参照してネットワークシステム１０００に含まれる各機器の構成について説明する。図７は、クライアントの内部構成を示す説明図である。図８は、プリントサーバー装置の内部構成を示す説明図である。図９は、プリンターの内部構成を示す説明図である。
【００５７】
クライアントＣＬ１、ＣＬ２は、周知の計算機であり、図７に示すように、中央演算装置（ＣＰＵ）２１０と、メモリー２２０と、ネットワークインターフェースカード（ＮＩＣ）２３０と、表示装置２４０を備えている。ＣＰＵ２１０は、メモリー２２０に格納された各種プログラムを実行することによりクライアントとしての機能を実現する。ＮＩＣ２３０は、ネットワークに接続するための通信インターフェースであり、具体的には、イーサネット（登録商標）の仕様に対応したケーブルを介して、ＬＡＮと接続される。
【００５８】
メモリー２２０には、種々のプログラムやデータが格納されており、図７においては、本実施例における処理に必要な構成を選択的に図示し、本明細書においては、図示された構成について説明する。メモリー２２０には、ＨＴＴＰクライアントプログラム２２１が格納されている。ＨＴＴＰクライアントプログラム２２１は、サーバー装置１００からサービスの提供を受けるために用いられるプログラムであり、例えば、ＷＥＢサービスの提供を受けるためのブラウザ機能、プリントサービスの提供を受けるためのプリンタードライバ機能を実現する。ＨＴＴＰクライアントプログラム２２１は、要求送信部２２１１と、応答受信部２２１２とを含んでいる。要求送信部２２１１は、ＬＡＮ上に接続されたサーバー装置１００に対してサービスの提供を要求するＨＴＴＰリクエストを送信する。ＨＴＴＰリクエストは、ＨＴＴＰ（HyperText Transfer Protocol）に従って、作成される。応答受信部２２１２は、ＬＡＮ上に接続されたサーバー装置１００から上述したＨＴＴＰリクエストに対する応答であるＨＴＴＰレスポンスを受信する。ＨＴＴＰリクエストの送信やＨＴＴＰレスポンスの受信は、ＨＴＴＰ、および、ＨＴＴＰの下位プロトコルであるＴＣＰ／ＩＰを用いて実行される。
【００５９】
サーバー装置１００は、図８に示すように、ＣＰＵ１１０と、メモリー１２０と、ＮＩＣ１３０と、ＵＳＢホストＩ／Ｆ部１４０を備えている。ＣＰＵ１１０は、メモリー１２０に格納されている各種プログラムを実行することにより、サーバー装置１００の機能を実現する。ＮＩＣ１３０は、ＬＡＮを介して、クライアントＣＬ１、ＣＬ２をはじめとするネットワーク上の機器と通信するためのインターフェースであり、具体的には、イーサネット（登録商標）の仕様に対応したケーブルを介して、ＬＡＮと接続される。ＵＳＢホストＩ／Ｆ部１４０は、ＵＳＢケーブルＣＶを接続するためのＵＳＢホストコネクタ１４１〜１４３を備え、ＵＳＢケーブルＣＶを介して、ＵＳＢデバイス（図６に示す例では、プリンターＰＲＴ１〜ＰＲＴ３）と接続される。ＵＳＢホストＩ／Ｆ部１４０は、ＵＳＢデバイスと通信するためのインターフェースであり、ＵＳＢ規格に従ったデータ通信を、接続されたＵＳＢデバイスとの間で実行する。
【００６０】
メモリー１２０には、種々のプログラムやデータが格納されており、図８においては、本実施例における処理に必要な構成を選択的に図示し、本明細書においては、図示された構成について説明する。メモリー１２０には、複数種類のサービスプログラム、すなわち、ＷＥＢサービスプログラム１２１およびプリントサービスプログラム１２２と、ＨＴＴＰサーバープログラム１２３と、登録テーブル１２５と、ソケットユーティリティープログラム１２７と、ソケットユーティリティープログラム１２７が参照するデータベース１２８とが、格納されている。
【００６１】
ＷＥＢサービスプログラム１２１は、クライアントからのＨＴＴＰリクエストに応じて、クライアントに対してＷＥＢサービスを提供するプログラムである。ＷＥＢサービスは、例えば、ＷＥＢページを介して、プリンターＰＲＴ１〜３あるいはサーバー装置１００に関する情報の提供、プリンターＰＲＴ１〜３あるいはサーバー装置１００に関する設定（例えば、サーバー装置１００のＩＰアドレスの設定）を行うために用いられる。
【００６２】
プリントサービスプログラム１２２は、クライアントからのＨＴＴＰリクエストに応じて、プリントサービスを提供する、すなわち、プリンターＰＲＴ１〜ＰＲＴ３を用いて印刷を実行するプログラムである。このようなＨＴＴＰを使用した印刷は、例えば、ＩＰＰ（Internet Printing Protocol）として標準化されている。
【００６３】
ＷＥＢサービスプログラム１２１およびプリントサービスプログラム１２２は、それぞれ、情報登録実行部１２１１、１２２１を備えている。情報登録実行部１２１１、１２２１は、後述する登録情報を登録テーブル１２５及びデータベース１２８に登録する。登録テーブル１２５及びデータベース１２８への登録は、例えば、各サービスプログラム１２１、１２２が起動された時に、サービスプログラムごとに実行される。
【００６４】
ＨＴＴＰサーバープログラム１２３は、主として、クライアントＣＬ１、ＣＬ２と、サービスプログラムとのデータのやり取り（リクエストやレスポンスのやり取り）を中継する。ＨＴＴＰサーバープログラム１２３は、登録情報取得部１２３１と、要求中継部１２３２と、送受信部１２３３とを含んでいる。登録情報取得部１２３１は、登録テーブル１２５に登録されている登録情報を取得する。登録情報には、後述する選択条件および設定情報が含まれる。登録テーブル１２５の具体的な内容については後述する。送受信部１２３３は、クライアントからＨＴＴＰリクエストを受信すると共に、クライアントに対してＨＴＴＰレスポンスを送信する。送受信部１２３３は、ＨＴＴＰリクエストの受信やＨＴＴＰレスポンスの送信を、ＨＴＴＰ、および、ＨＴＴＰの下位プロトコルであるＴＣＰ／ＩＰを用いて実行するが、これらのプロトコルの設定は、登録情報取得部１２３１により取得された登録情報に含まれる設定情報に従って実行される。要求中継部１２３２は、受信されたＨＴＴＰリクエストを与えるサービスプログラムを上述した複数種類のサービスプログラムの中から選択すると共に、選択されたサービスプログラムを呼び出す（コールする）。要求中継部１２３２は、選択されたサービスプログラムに、受信されたＨＴＴＰリクエストを与える。サービスプログラムの選択は、ＨＴＴＰリクエストに含まれる情報と、登録情報取得部１２３１により取得された登録情報に含まれる選択条件とを比較することにより実行される。
【００６５】
ソケットユーティリティープログラム１２７は、データベース１２８を参照して、ＷＥＢサービスプログラム１２１及びプリントサービスプログラム１２２がＨＴＴＰサーバープログラム１２３を介して通信を行うためのソケットを生成する。例えば、データベース１２８には、ＨＴＴＰサーバープログラム１２３がデュアルスタックとして登録されている。また、ＷＥＢサービスプログラム１２１及びプリントサービスプログラム１２２のサービス名と、ＷＥＢサービスプログラム１２１及びプリントサービスプログラム１２２がそれぞれサポートしているＩＰバージョンとは、登録テーブル１２５に対応付けて登録されている。ソケットユーティリティープログラム１２７は、登録テーブル１２５及びデータベース１２８を参照して、登録テーブル１２５に登録されている各サービス宛のＨＴＴＰリクエストを、ＨＴＴＰサーバープログラム１２３が受信するためのＩＰｖ４用ソケット及びＩＰｖ６用のソケットを生成し、各ソケットを受信可能状態とする。
【００６６】
サーバー装置１００と接続されるＵＳＢデバイスであるプリンターＰＲＴ１〜ＰＲＴ３について説明する。以下の説明において、各プリンターＰＲＴ１〜ＰＲＴ３を区別する必要がない場合には、符号の末尾の数字を省略し、プリンターＰＲＴと表記する。プリンターＰＲＴは、図９に示すように、コントローラ３１０と、プリントエンジン３２０と、ＵＳＢデバイスＩ／Ｆ部３４０とを備えている。コントローラ３１０は、プリンター全体を制御する計算機であり、ＣＰＵ３１１と、メモリー３１２を備えている。メモリー３１２には、プリンターＰＲＴの制御プログラム３１３が格納されており、ＣＰＵ３１１は、制御プログラム３１３を実行することによりプリンターＰＲＴを制御する。プリントエンジン３２０は、実際に印刷を行う機構部分であり、本実施例では、静電気によってトナー粉が付着する現象を利用して印刷用紙上に画像を形成するいわゆるレーザー式のプリントエンジンである。ＵＳＢデバイスＩ／Ｆ部３４０は、サーバー装置１００と接続するためのＵＳＢデバイスコネクタ３４５を備え、ＵＳＢケーブルＣＶを介して、サーバー装置１００と接続される。ＵＳＢデバイスＩ／Ｆ部３４０は、サーバー装置１００と通信するためのインターフェースであり、ＵＳＢ（Universal Serial Bus）規格に従ったデータ通信を、サーバー装置１００との間で実行する。
【００６７】
図１０を参照して、サーバー装置１００のメモリー１２０に格納されている登録テーブル１２５について、説明する。図１０は、登録テーブル１２５の具体例を概念的に示す説明図である。登録テーブル１２５は、各サービスプログラム１２１、１２２と、ＨＴＴＰサーバープログラム１２３が、それぞれアクセス可能に構成されている。登録テーブル１２５には、登録情報が、上述したサービスプログラム１２１、１２２の各情報登録実行部１２１１、１２２１により、サービスプログラムごとに登録されている。図１０において登録情報１の列に記述されている登録情報は、ＷＥＢサービスプログラム１２１について登録された情報であり、登録情報２の列に記述されている登録情報は、プリントサービスプログラム１２２について登録された情報である。登録情報は、呼び出すサービスプログラムを特定するサービス名（図１０：１行目）と共に、上述した選択条件（図１０：２〜７行目）と、上述した設定情報（図１０：８〜１３行目）とを含む。本実施例において、図１０に示すように、選択条件の項目は、ＨＴＴＰメソッド、リクエストＵＲＩ、受信ポート番号、受信プロトコル、ＩＰバージョン、ＵＲＩ判定条件を含んでおり、設定情報の項目は、使用スタックサイズ、受信タイムアウト、送信タイムアウト、コネクション保持時間、マルチキャストアドレス、ループバックを含んでいる。各項目については、ＨＴＴＰサーバープログラム１２３の処理について説明する際に、後述する。
【００６８】
図１１を参照して、サーバー装置１００が、起動時に実行する処理（起動処理）について説明する。図１１は、サーバー装置の起動処理の処理ルーチンを示すフローチャートである。サーバー装置１００が起動されると、メモリー１２０に格納された各プログラム、すなわち、ＷＥＢサービスプログラム１２１、プリントサービスプログラム１２２、ＨＴＴＰサーバープログラム１２３、及びソケットユーティリティープログラム１２７が起動される（ステップＳ１０２）。
【００６９】
続いて、起動された各サービスプログラム１２１、１２２の情報登録実行部１２１１、１２２１は、登録テーブル１２５に、図１０において説明した登録情報を登録する。さらに、ＨＴＴＰサーバープログラム１２３は、データベース１２８に、ＨＴＴＰサーバープログラム１２３をＩＰｖ４及びＩＰｖ６の双方をサポートするデュアルスタックとして登録する（ステップＳ１０４）。例えば、ＷＥＢサービスプログラム１２１の情報登録実行部１２１１は、図１０に示す登録情報１の列に記述された情報を登録する。また、プリントサービスプログラム１２２の情報登録実行部１２２１は、図１０に示す登録情報２の列に記述された情報を登録する。
【００７０】
ソケットユーティリティープログラム１２７は、上述したように、ＷＥＢサービスプログラム１２１及びプリントサービスプログラム１２２をサポートするＨＴＴＰサーバープログラム１２３のためのソケットを生成する（ステップＳ１０５）。このとき、ソケットユーティリティープログラム１２７は、登録テーブル１２５から、受信ポート番号（図１０：４行目）を取得する。そして、図１０の例では、ソケットユーティリティープログラム１２７は、受信ポート番号「８０」及び「６３１」のそれぞれについて、ＩＰｖ４及びＩＰｖ６のソケットを生成する。
【００７１】
ＨＴＴＰサーバープログラム１２３の送受信部１２３３は、ステップＳ１０５で生成したソケットで、ＨＴＴＰリクエストの着信を待つ（ステップＳ１０６）。つまり、送受信部１２３３は、受信ポート番号「８０」が割り当てられているＩＰｖ４及びＩＰｖ６のソケットと、受信ポート番号「６３１」のが割り当てられているＩＰｖ４及びＩＰｖ６のソケットで、ＨＴＴＰリクエストの着信を待つ。
【００７２】
登録されているソケットにデータが到着すると、ＨＴＴＰサーバープログラム１２３の送受信部１２３３は、そのソケットから到着したデータを取得し、ＨＴＴＰリクエストが着信する（ステップＳ１０８）。ＨＴＴＰリクエストが着信すると（ステップＳ１０８：ＹＥＳ）、送受信部１２３３は、着信したＨＴＴＰリクエストに対する処理を呼び出し（ステップＳ１１０）、再びＨＴＴＰリクエストの着信を待つ。送受信部１２３３は、ＨＴＴＰリクエストが着信しない場合には（ステップＳ１１０：ＮＯ）、ＨＴＴＰリクエストの着信を待ち続ける。
【００７３】
図１２および図１３を参照して、上述した起動処理におけるステップＳ１１０において呼び出されるＨＴＴＰリクエストに対する処理について説明する。図１２は、ＨＴＴＰリクエストに対する処理の処理ルーチンを示すフローチャートである。図１３は、ＨＴＴＰリクエストの一例を概念的に示す説明図である。
【００７４】
着信したＨＴＴＰリクエストに対する処理は、ＨＴＴＰサーバープログラム１２３によって実行される。本処理が開始されると、送受信部１２３３は、ＨＴＴＰリクエストの先頭部分を受信する（ステップＳ２０２）。図１３に示すように、ＨＴＴＰリクエスト５００は、先頭から順に、リクエストライン、ヘッダ、ボディを備えている。本ステップでは、少なくともリクエストラインを含むＨＴＴＰリクエスト５００の先頭部分を受信する。
【００７５】
続いて、ＨＴＴＰサーバープログラム１２３の要求中継部１２３２は、登録テーブル１２５に登録された選択条件と、ＨＴＴＰリクエスト５００の備える属性と比較する（ステップＳ２０４）。ここで、選択条件と比較されるＨＴＴＰリクエスト５００の属性（比較属性）は、ＨＴＴＰメソッドと、リクエストＵＲＩと、受信ポート番号と、受信プロトコルと、ＩＰバージョンである。ＨＴＴＰメソッドと、リクエストＵＲＩは、ステップＳ２０２において受信されたＨＴＴＰリクエスト５００の先頭部分に含まれるリクエストラインに記述されている（図１３）。
【００７６】
ＨＴＴＰメソッドは、ＨＴＴＰリクエスト５００がサーバー装置１００に実行を要求する処理を示すコマンドであり、例えば、「ＧＥＴ」「ＰＯＳＴ」などである。リクエストＵＲＩは、ＨＴＴＰリクエスト５００が処理の対象を指定する識別子であり、例えば、ＨＴＴＰリクエストが送信を要求するデータを特定するために用いられる。リクエストＵＲＩは、スキーム名（例えば、http）、ホスト名（例えば、xxx.co.jp）、パス名（例えば、/aaa/bbb）を含む絶対パスと、パス名のみからなる相対パスとが使用されるが、本実施例において、選択条件との比較属性として使用されるのは、パス名の部分のみである。受信ポート番号は、ＨＴＴＰリクエスト５００の宛先とされたポート番号である。受信プロトコルは、ＨＴＴＰリクエスト５００の送信に用いられた通信プロトコルであり、本実施例ではトランスポート層の通信プロトコル（ＴＣＰあるいはＵＤＰ）が選択条件として用いられる。上述したようにＩＰｖ４用ソケット及びＩＰｖ６用ソケットが、それぞれ生成されているので、ＩＰバージョンは受信ソケットにより定まる。
【００７７】
具体的には、要求中継部１２３２は、登録テーブル１２５に登録された選択条件（図１０：２〜６行目）と、処理対象のＨＴＴＰリクエスト５００の比較属性を１つずつ比較して、一致する場合には、その選択条件は満足していると判断する。例えば、ＨＴＴＰリクエスト５００のリクエストラインに記述されたメソッドが、「ＰＯＳＴ」であれば、登録情報２（図１０）について、ＨＴＴＰメソッドに関する選択条件は満たされていると判断される。
【００７８】
さらに、登録情報２のリクエストＵＲＩに関する選択条件は、「/IPP_printer」であり（図１０：３行目）であり、ＵＲＩ判定条件は、「前方一致」となっている（図１０：７行目）。かかる場合には、ＨＴＴＰリクエスト５００のリクエストラインに記述されたＵＲＩのパス名が、「/IPP_printer」と前方一致する場合に、登録情報２について、リクエストＵＲＩに関する選択条件は満たされていると判断される。さらに具体例を挙げて説明すると、ＨＴＴＰリクエスト５００のリクエストラインに記述されたリクエストＵＲＩが、「/IPP_printer/aaa」あるいは「/IPP_printer/bbb/ccc」である場合には、いずれも、登録情報２（図１０）について、ＨＴＴＰメソッドに関する選択条件は満たされていると判断される。一方、もし、ＵＲＩ判定条件が「完全一致」とされている場合には、ＨＴＴＰリクエスト５００のリクエストラインに記述されたＵＲＩのパス名が、「/IPP_printer」と完全一致する場合に限って、リクエストＵＲＩに関する選択条件は満たされていると判断される。例えば、ＨＴＴＰリクエスト５００のリクエストラインに記述されたリクエストＵＲＩが、「/IPP_printer」である場合に限って、登録情報２（図１０）について、ＨＴＴＰメソッドに関する選択条件は満たされていると判断され、リクエストＵＲＩが、「/IPP_printer」「/IPP_printer/aaa」あるいは「/IPP_printer/bbb/ccc」である場合には、いずれも、登録情報２について、ＨＴＴＰメソッドに関する選択条件は満たされていないと判断される。
【００７９】
ここで、図１０において、登録情報１の列におけるＨＴＴＰメソッドおよびリクエストＵＲＩに関する選択条件は、「特別な条件」と記述されている。かかる場合は、ＨＴＴＰリクエスト５００の各比較属性が、他の登録情報についての選択条件を満足しない場合には、登録情報１について、ＨＴＴＰメソッドおよびリクエストＵＲＩに関する選択条件は、満たされていると判断される。例えば、図１０の例では、ＨＴＴＰリクエスト５００の比較属性のいずれかが、登録情報２について登録されている選択条件を満たさない場合に、登録情報１について、ＨＴＴＰメソッドおよびリクエストＵＲＩに関する選択条件は満たされていると判断される。
【００８０】
続いて、要求中継部１２３２は、登録テーブル１２５に登録された選択条件（図１０：２〜６行目）と、ＨＴＴＰリクエスト５００の属性との比較結果に基づいて、選択条件と合致するサービスプログラムを選択する（ステップＳ２０６）。具体的には、先のステップＳ２０４において、処理対象のＨＴＴＰリクエスト５００の属性が、図１０の２〜６行目までの選択条件を全て満たしていると判断される登録情報がある場合には、その登録情報の１行目に記述されているサービスプログラムが選択される。具体例を挙げて説明すると、例えば、処理対象のＨＴＴＰリクエスト５００のＨＴＴＰメソッド、リクエストＵＲＩ、受信ポート番号、受信プロトコル、ＩＰバージョンが、それぞれ、「ＰＯＳＴ」、「/IPP_printer/aaa」、「６３１」、「ＴＣＰ」、「ｖ６」である場合には、要求中継部１２３２は、プリントサービスプログラム１２２を選択する。一方、処理対象のＨＴＴＰリクエスト５００のＨＴＴＰメソッド、リクエストＵＲＩ、受信ポート番号、受信プロトコル、ＩＰバージョンが、それぞれ、「ＧＥＴ」、「/config/ccc」、「８０」、「ＴＣＰ」、「ｖ６」である場合には、要求中継部１２３２は、ＷＥＢサービスプログラム１２１を選択する。もし、選択条件と合致するサービスプログラムが登録テーブル１２５に登録されていない場合には、ＨＴＴＰサーバープログラム１２３は、クライアントに対して、エラーを通知するＨＴＴＰレスポンスを送信することとしても良い。
【００８１】
サービスプログラムが選択されると、登録情報取得部１２３１は、選択されたサービスプログラムに応じた設定情報（図１０：８〜１３行目）を、登録テーブル１２５から取得する（ステップＳ２０８）。本ステップで取得された設定情報は、以降の処理におけるサーバー装置１００の動作設定に用いられる。
【００８２】
設定情報が取得されると、要求中継部１２３２は、ステップＳ２０６において選択されたサービスプログラムを呼び出す（ステップＳ２１０）。ここで、要求中継部１２３２は、サービスプログラムを呼び出す際に、呼び出されたサービスプログラムが使用するスタック領域を、メモリー１２０上に割り当てる。割り当てられるスタック領域のサイズは、ステップＳ２０８において取得された設定情報に含まれる使用スタックサイズの値（図１０：８行目）に設定される。スタック領域は、自動変数、関数の引数、戻り値、リターンアドレス等、サービスプログラムにより処理中に一時的に使用されるデータが格納されるメモリー領域である。要求中継部１２３２は、サービスプログラムを呼び出す際に、呼び出されたサービスプログラムに対して、処理中のＨＴＴＰリクエスト５００のうち、ステップＳ２０２において受信済みの先頭部分を与える。この結果、サービスプログラムは、ＨＴＴＰリクエスト５００に応じてサービスを提供する処理、例えば、ＷＥＢサービスプログラム１２１であればＷＥＢデータをクライアントに提供する処理、プリントサービスプログラム１２２であれば印刷を実行する処理を実行するこができる。
【００８３】
ＨＴＴＰサーバープログラム１２３の送受信部１２３３は、ステップＳ２１０において呼び出されたサービスプログラムの処理に応じて、データの送受信を実行する（ステップＳ２１２）。例えば、呼び出されたサービスプログラムは、与えられたＨＴＴＰリクエスト５００の先頭部分に続くデータ、例えば、図８におけるＨＴＴＰボディのデータを受信する必要があるため、送受信部１２３３はサービスプログラムの要求に応じて、これらのデータをクライアントから受信する。また、呼び出されたサービスプログラムは、与えられたＨＴＴＰリクエスト５００に対するＨＴＴＰレスポンスを作成すると、送受信部１２３３は、ＨＴＴＰレスポンスを、クライアントに対して送信する。本ステップにおける送受信部１２３３によるデータの送受信に関する動作設定は、ステップＳ２０８において取得された設定情報に含まれる受信タイムアウト、送信タイムアウト、ｋｅｅｐ−ａｌｉｖｅタイムアウト、マルチキャストアドレス、ループバックの有効または無効の各値（図１０：９〜１３行目）に設定される。
【００８４】
なお、設定情報は、全てが登録される必要はなく、必要な情報だけ登録されれば良い。例えば、ＷＥＢサービスプログラム１２１とプリントサービスプログラム１２２についての設定情報は、図１０に示すように、マルチキャストアドレスと、ループバックの有効または無効に関して、登録されていない。
【００８５】
以上、説明した本実施例におけるサーバー装置１００によれば、データベース１２８に登録されたＩＰバージョンのソケットが、ソケットユーティリティープログラム１２７により自動的に生成され、これによってＨＴＴＰサーバープログラム１２３の送受信部１２３３がＨＴＴＰリクエスト５００を受信できる。この結果、データベース１２８にサービスプログラムごとのＩＰバージョンを登録するだけで、ＨＴＴＰサーバープログラム１２３がＨＴＴＰリクエスト５００を受信できるようになる。さらに、上述のサーバー装置１００によれば、サービスプログラムごとに登録テーブル１２５に登録された選択条件と、ＨＴＴＰリクエスト５００の属性とを比較することにより、複数種類のサービスプログラムの中からＨＴＴＰリクエスト５００について処理すべきサービスプログラムを呼び出す。この結果、登録テーブル１２５に選択条件を登録するだけで、ＨＴＴＰサーバープログラム１２３は、ＨＴＴＰリクエスト５００を処理すべきサービスプログラムを容易に選択することができる。さらに、サービスプログラムごとに登録テーブル１２５に登録された設定情報を用いて、サービスプログラムごとに、ＨＴＴＰサーバープログラム１２３の動作が設定される。この結果、ＨＴＴＰサーバープログラム１２３の動作設定が容易になる。
【００８６】
以上の説明から解るように、本実施例におけるサーバー装置１００は、新たにサービスプログラムを追加する場合、新たなサービスプログラムをインストールして、データベース１２８及び登録テーブル１２５に必要な情報を登録するだけで良い。このため、新たなサービスプログラムの追加に伴い、ＨＴＴＰサーバープログラム１２３に改造を加える必要がない。この結果、新たにサービスプログラムを追加することが容易になると共に、新たなサービスプログラムの開発が容易になる。
【００８７】
さらに、各サービスプログラムは、起動時に自身に関するＩＰバージョンをデータベース１２８に、選択条件および設定情報を登録テーブル１２５にそれぞれ登録する情報登録実行部を備える。この結果、新たなサービスプログラムを追加した場合には、サービスプログラム自身がデータベース１２８及び登録テーブル１２５に、自身の動作に必要な情報を登録するので、ユーザの設定負担が軽減される。従って、新たにサービスプログラムを追加することが、さらに、容易になる。
【００８８】
また、ソケットユーティリティープログラム１２７は、データベース１２８を参照することにより、新たに追加されたサービスプログラムがサポートするＩＰバージョンを認識できるので、プログラムを変更することなく、ＩＰバージョンの変更に対応することができる。
【００８９】
さらに、ＨＴＴＰサーバープログラム１２３は、新たなサービス部が追加された場合、登録テーブル１２５を参照することにより、新たなサービス部の存在を認識して、新たなサービス部に関する送受信処理をサポートするので、新たなサービス部の追加に伴うＨＴＴＰサーバープログラム１２３の改造や、再設定を、ユーザ等が行う必要もない。
【００９０】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【符号の説明】
【００９１】
１ サーバー
１１ ＯＳ
１２ ソケットユーティリティー
１３ ＨＴＴＰサーバー
１４ ＷＥＢサーバー
１５ データベース
１００ サーバー装置
１２１ ＷＥＢサービスプログラム
１２２ プリントサービスプログラム
１２３ ＨＴＴＰサーバープログラム
１２５ 登録テーブル
１２７ ソケットユーティリティープログラム
１２８ データベース
【技術分野】
【０００１】
本発明は、アプリケーションプログラムがサポートするＩＰバージョンに依存せずにデータを受信するための技術に関する。
【背景技術】
【０００２】
ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）のバージョンは、従来から利用されているＩＰｖ４（ＩＰバージョン４）と、近年導入が進んでいるＩＰｖ６（ＩＰバージョン６）とがある。ＩＰｖ４からＩＰｖ６への移行期においては、ＩＰｖ４とＩＰｖ６とが併存する。
【０００３】
そこで、特許文献１には、ＩＰｖ４パケット処理部とＩＰｖ６パケット処理部を共通化したネットワークデバイスが記載されている。
【０００４】
また、アプリケーションプログラムには、ＩＰｖ４のみサポートするもの、ＩＰｖ６のみサポートするもの（以上、シングルスタック）、及びＩＰｖ４及びＩＰｖ６の両方をサポートするもの（デュアルスタック）が存在する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１−１８６１８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
各アプリケーションプログラムは、自らがサポートしているＩＰバージョンに対応したソケットを作成し、それぞれの受信処理を行う必要がある。つまり、デュアルスタックであれば、一つのアプリケーションが二つのソケットを作成し、それぞれの受信処理を行う必要がある。これらの処理は、それぞれのアプリケーションプログラムに実装されている。従って、あるアプリケーションプログラムにおいてサポートするＩＰバージョンを変更する場合には、プログラムの修正が必要となる。
【０００７】
また、一般に、ソフトウェアを開発する際、利用するＩＰバージョンを意識しない、つまりＩＰバージョンに依存しない実装にすることが望ましい。一方で、デュアルスタックのアプリケーションプログラムでは、ＩＰｖ４、ＩＰｖ６でそれぞれ異なるモジュールにデータを受信させたい場合もある。
【０００８】
そこで、本発明の目的は、アプリケーションプログラムがサポートするＩＰバージョンに依存せずにデータを受信することである。
【０００９】
本発明の別の目的は、ＩＰバージョンに依存してデータを受信するモジュールが異なるようなアプリケーションプログラムの場合には、ＩＰバージョンを把握できるようにすることである。
【課題を解決するための手段】
【００１０】
本発明の一つの実施態様に従う、アプリケーションプログラムが動作しているサーバーは、前記アプリケーションプログラムの識別情報と前記アプリケーションプログラムがサポートするＩＰバージョンとを対応付けて記憶したデータベースと、前記データベースを参照し、前記アプリケーションプログラム用のソケットであって前記ＩＰバージョンに対応したソケットを生成するソケットユーティリティーと、を備え、前記アプリケーションプログラムは、前記生成されたソケットを介してデータを受信する。
【００１１】
これにより、アプリケーションプログラムは、自らがサポートしているＩＰバージョンに依存することなくデータを受信できる。
【００１２】
好適な実施形態では、前記生成されたソケットのソケットハンドルを取得し、前記ソケットハンドルに含まれている前記アプリケーションプログラムの識別情報により定まるアプリケーションプログラムを呼び出すディスパッチャーを、さらに備え、前記呼び出されたアプリケーションプログラムが前記生成されたソケットを介してデータを受信するようにしてもよい。
【００１３】
これにより、ディスパッチャーが存在する場合であっても、アプリケーションプログラムは、自らがサポートしているＩＰバージョンに依存することなくデータを受信できる。
【００１４】
好適な実施形態では、前記ディスパッチャーは、前記ソケットハンドルに含まれている、前記アプリケーションプログラムがサポートするＩＰバージョンに対応する前記アプリケーションプログラムのモジュールを呼び出すようにしてもよい。
【００１５】
これにより、アプリケーションプログラムがＩＰバージョンに応じて異なるモジュールがデータを受信する場合でも、ディスパッチャーがＩＰバージョンを把握できるので、適切なモジュールがデータを受信できる。
【００１６】
好適な実施形態では、前記ＩＰバージョンは、ＩＰｖ４またはＩＰｖ６であってもよい。
【００１７】
好適な実施形態では、前記アプリケーションプログラムが、ＩＰｖ４及びＩＰｖ６の双方をサポートするデュアルスタックである場合、前記データベースには、前記アプリケーションプログラムの識別情報に、ＩＰｖ４を示す情報及びＩＰｖ６を示す情報が対応付けて登録されていて、前記ソケットユーティリティーは、ＩＰｖ４に対応するソケット及びＩＰｖ６に対応するソケットを生成してもよい。
【００１８】
これにより、デュアルスタックのアプリケーションプログラムは、ＩＰｖ４に対応するソケット及びＩＰｖ６に対応するソケットがそれぞれ自動的に生成される。
【００１９】
好適な実施形態では、前記ソケットユーティリティーは、前記アプリケーションプログラムに、前記ＩＰｖ４に対応するソケット及び前記ＩＰｖ６に対応するソケットを交互に利用させてデータを受信させるようにしてもよい。
【００２０】
これにより、デュアルスタックのアプリケーションプログラムは、ＩＰｖ４及びＩＰｖ６で、それぞれほぼ均等にデータを受信することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の第１の実施形態に係るサーバーで機能する各プログラムのプロトコル階層図。
【図２】本発明の第２の実施形態に係るサーバーで機能する各プログラムのプロトコル階層図。
【図３】サーバーがネットワークを介して接続されたクライアントと通信を行うときの処理手順を示すフローチャート
【図４】受信ポートの登録処理の詳細な手順を示すフローチャート。
【図５】受信ソケットの選択処理の詳細な手順を示すフローチャート。
【図６】本発明の実施例におけるネットワークシステムの概略構成図。
【図７】クライアントの内部構成を示す説明図。
【図８】プリントサーバー装置の内部構成を示す説明図。
【図９】プリンターの内部構成を示す説明図。
【図１０】登録テーブル１２５の具体例を概念的に示す説明図。
【図１１】サーバー装置の起動処理の処理ルーチンを示すフローチャート。
【図１２】ＨＴＴＰリクエストに対する処理の処理ルーチンを示すフローチャート。
【図１３】ＨＴＴＰリクエストの一例を概念的に示す説明図。
【発明を実施するための形態】
【００２２】
以下、本発明の一実施形態に係るサーバー及びネットワークシステムについて、図面を参照して説明する。
【００２３】
本実施形態に係るサーバーは、例えば、ＣＰＵ、メモリー及びネットワーク通信装置などを備えた汎用的なコンピュータシステムにより構成され、以下に説明する個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。
【００２４】
図１は、本発明の第１の実施形態に係るサーバーで機能する各プログラムのプロトコル階層を示す図である。
【００２５】
同図に示すように、サーバー１では、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）１１と、ソケットユーティリティー１２と、データベース１５と、複数のアプリケーションプログラム（ＡＰＰ）１８とが実行されている。
【００２６】
ＯＳ１１には、ＴＣＰ／ＩＰスタック１１ａが含まれている。ＴＣＰ／ＩＰスタック１１ａにおけるＩＰスタックには、ＩＰｖ４スタックとＩＰｖ６スタックとが含まれる。
【００２７】
各ＡＰＰ１８は、それぞれ所定の処理を行う。各ＡＰＰ１８は、ＩＰｖ４またはＩＰｖ６のいずれか、または双方をサポートしている。すなわち、各ＡＰＰ１８は、ＩＰｖ４またはＩＰｖ６のみをサポートするシングルスタックか、またはｖ４及びｖ６の両方をサポートするデュアルスタックである。
【００２８】
データベース１５には、各ＡＰＰ１８がサポートしているＩＰバージョンが、各ＡＰＰ１８のサービス名（識別情報）と対応付けて登録されている。この登録は、例えば、各ＡＰＰ１８の起動時に行うようにしても良い。
【００２９】
ソケットユーティリティー１２は、ＡＰＰ１８がＴＣＰ／ＩＰで通信を行うためのソケットを生成する。例えば、ソケットユーティリティー１２は、ＡＰＰ１８のサービス名とそのＡＰＰ１８のためのポート番号を取得すると、データベース１５を参照して、ＡＰＰ１８のサービス名と対応付けられているＩＰバージョンを取得する。そして、ソケットユーティリティー１２は、上記の取得した情報に基づいて、ソケットを生成する。例えば、デュアルスタックのＡＰＰ１８ａのサービス名を取得すると、ソケットユーティリティー１２は、ＡＰＰ１８ａ用のＩＰｖ４対応のソケットとＩＰｖ６対応のソケットを生成する。つまり、ソケットユーティリティー１２は、ＡＰＰ１８ａ向けのポート番号を確保しＩＰｖ４のＩＰアドレス及びこのポート番号に基づいてＩＰｖ４用ソケットを生成する。さらに、ソケットユーティリティー１２は、ＩＰｖ６のＩＰアドレス及びＩＰｖ４と同じポート番号でＩＰｖ６用ソケットを生成する。
【００３０】
これにより、各ＡＰＰ１８が自らソケット生成を行わなくても、ソケットユーティリティー１２が全ＡＰＰ１８に適したソケットを生成し、各ＡＰＰ１８がそのソケットを利用して自在に通信を行うことができる。また、各ＡＰＰ１８が、自らがサポートするＩＰバージョンをデータベース１５に登録すれば、ソケットユーティリティー１２によって、登録されているＩＰバージョンに対応するソケットを自動的に生成される。その結果、各ＡＰＰ１８は、通信を行う際にはＩＰバージョンに依存せずに通信を行うことができる。
【００３１】
次に、図２は、本発明の第２の実施形態に係るサーバーで機能する各プログラムのプロトコル階層を示す図である。
【００３２】
本実施形態では、ソケットユーティリティー１２上でディスパッチャーが動作する場合のプロトコル階層を示す。ディスパッチャーは、上位のアプリケーションへのデリバリー条件を判断するためにＩＰバージョンを必要とする場合がある。例えば、デュアルスタックのアプリケーションが、ＩＰのバージョンに応じて異なる処理を用意しているときは、ディスパッチャーが、受信データが転送されてきたＩＰバージョンに対応する処理を呼び出す。そのために、本実施形態では、ソケットユーティリティー１２からディスパッチャーへＩＰバージョンを通知する。ここでは、ディスパッチャーとしてＨＴＴＰサーバーを用いた場合を例にとって説明する。
【００３３】
なお、本実施形態において、第１の実施形態と同じ構成については、同じ符号を付して詳細な説明を省略する場合がある。
【００３４】
図２に示すように、サーバー１では、ＯＳ１１と、ソケットユーティリティー１２と、ＨＴＴＰサーバー１３と、ＷＥＢサーバー１４と、データベース１５と、複数のアプリケーションプログラム（ＡＰＰ）１８とが実行されている。
【００３５】
本実施形態では、データベース１５には、ＨＴＴＰサーバー１３が、ＩＰｖ４及びＩＰｖ６をサポートするデュアルスタックとして登録される。さらに、各ＡＰＰ１８がサポートしているＩＰバージョンは、各ＡＰＰ１８のサービス名と対応付けてＨＴＴＰサーバー１３の管理下に登録される。デュアルスタックのＡＰＰ１８については、それぞれのＩＰバージョンに対応するモジュール名などがＨＴＴＰサーバー１３の管理下に登録される。これによって、各ＡＰＰ１８に対するリクエスト及び各ＡＰＰ１８が発行するリクエストは、すべてＨＴＴＰサーバー１３を介して通信される。つまり、ＨＴＴＰサーバー１３は、ソケットユーティリティー１２に対するインターフェースとなる。
【００３６】
ソケットユーティリティー１２は、第１の実施形態と同様に、データベース１５を参照して、ソケットを生成する。ここでは、ソケットユーティリティー１２は、各ＡＰＰ１８のためのポート番号をそれぞれ取得して、各ポート番号に対して、ＨＴＴＰサーバー１３の向けのＩＰｖ４及びＩＰｖ６のソケットを生成する。ここで生成された各ソケットがデータを受信した際、そのソケットのソケットハンドルには、少なくとも、ＩＰバージョン、送信元アドレス、送信元ポート、及び自らのサービス名が格納される。ＨＴＴＰサーバー１３は、このソケットハンドルを取得することにより、そのソケットが受信したデータの送信元を把握できるとともに、ＩＰバージョンを把握することもできる。ＨＴＴＰサーバー１３は、ソケットハンドルに含まれる情報に対応するＡＰＰ１８のモジュールを呼び出す。例えば、ソケットハンドルに含まれるサービス名（または受信ポート番号）によってＡＰＰ１８が特定され、ＩＰバージョンによってその特定されたＡＰＰ１８のいずれのモジュールを呼び出すかが特定される。
【００３７】
例えば、あるＡＰＰ１８ｂがＩＰｖ４のみをサポートするシングルスタックであるときでも、そのＡＰＰ１８ｂに対応する、ＨＴＴＰサーバー１３のソケットは２つ生成される（つまり、ＨＴＴＰサーバー１３としてはデュアルスタック）。そして、ＨＴＴＰサーバー１３が、例えば、ＩＰｖ４でＡＰＰ１８ｂに対するリクエストを受信すると、ＨＴＴＰサーバー１３はＡＰＰ１８ｂを呼び出し、ＩＰｖ６でＡＰＰ１８ｂに対するリクエストを受信すると、ＨＴＴＰサーバー１３はＡＰＰ１８ｂを呼び出さず、そのリクエストは無視される。
【００３８】
また、あるＡＰＰ１８ｃがＩＰｖ４及びＩＰｖ６をサポートするデュアルスタックであるときは、ＨＴＴＰサーバー１３にＩＰｖ４のときに呼び出すモジュール及びＩＰｖ６のときに呼び出すモジュールをそれぞれ登録しておくと、ＨＴＴＰサーバー１３は、受信したソケットに対応するモジュールを呼び出す。
【００３９】
このようにすると、ＩＰｖ４でデータを受信した場合とＩＰｖ６でデータを受信した場合で、異なるモジュールにデータを受信させることができる。これにより、同一のＡＰＰであって、ＩＰｖ４でデータを受信した場合とＩＰｖ６でデータを受信した場合で、別々の処理を実行することができる。
【００４０】
次に、上述した第１及び第２の実施形態におけるデータ受信処理の処理手順を図３〜図５のフローチャートを参照して説明する。
【００４１】
図３は、図１及び図２に示すプロトコル階層に従うプログラムが、ネットワークを介して接続されたクライアントと通信を行うときの処理手順を示すフローチャートである。
【００４２】
まず、サーバー１の起動時に、ソケットユーティリティー１２は初期化処理を行う（Ｓ１０）。この初期化処理には、例えば、各ＡＰＰ１８が自らのサービス名及びサポートするＩＰバージョンをデータベース１５に登録する処理を含む。次に、ソケットユーティリティー１２は、受信ポートごとにソケットを生成して、受信ポートの登録処理を行う（Ｓ１２）。受信ポートの登録処理の詳細は後述する。ソケットユーティリティー１２は、すべての受信ポートの登録処理が完了するまで、ステップＳ１２を繰り返して行う（Ｓ１４）。
【００４３】
全受信ポートの登録が完了すると（Ｓ１４：Ｙｅｓ）、ステップＳ１２で生成したソケットでのデータ受信及び受信ソケットの選択処理を行う（Ｓ１６）。受信ソケットの選択処理の詳細は後述する。
【００４４】
ステップＳ１６で選択されたソケットを使って、受信したデータに基づいてＡＰＰ１８が通信処理を行う（Ｓ１８）。ソケットユーティリティー１２が終了するまでの間、ステップＳ１６及びＳ１８の処理が繰り返される（Ｓ２０）。
【００４５】
図４は、ステップＳ１２の受信ポートの登録処理の詳細な手順を示すフローチャートである。
【００４６】
まず、ソケットユーティリティー１２は、サーバー１で動作しているＡＰＰ１８のサービス名及びそのＡＰＰ１８が使用する受信ポート番号を取得する（Ｓ１２０）。ソケットユーティリティー１２は、データベース１５を参照して、ステップＳ１２０で取得したサービス名のＡＰＰ１８がサポートするＩＰバージョンを特定する（Ｓ１２２）。そして、ソケットユーティリティー１２がソケットを生成し（S１２４）、生成したソケットの受信ポート番号及びＩＰバージョンに、それぞれステップＳ１２０，Ｓ１２２で取得した受信ポート番号及びＩＰバージョンを設定する（Ｓ１２６）。
【００４７】
ソケットユーティリティー１２は、ステップＳ１２２で取得したすべてのＩＰバージョンの設定が完了したか否かを判定する（Ｓ１２８）。未設定のＩＰバージョンがあれば（Ｓ１２８：Ｎｏ）、ステップＳ１２４以降を繰り返し、全ＩＰバージョンについてソケットを生成する。たとえば、デュアルスタックのＡＰＰであれば、それぞれのＩＰバージョンに対するソケットを生成する。
【００４８】
最後に、ソケットユーティリティー１２は、この処理で生成した全ソケットに関する情報を、所定の記憶部に登録する（Ｓ１３０）。
【００４９】
図５は、ステップＳ１６の受信ソケットの選択処理の詳細な手順を示すフローチャートである。
【００５０】
まず、ソケットユーティリティー１２は、ステップＳ１２で登録されたソケットを、受信待ちソケットとして設定する（Ｓ１６０）。ここで、各ソケットは、データ受信待ち状態となる（Ｓ１６２、Ｓ１６４）。そして、いずれかのソケットにデータが到着すると（Ｓ１６４：Ｙｅｓ）、ソケットユーティリティー１２は、受信したソケットが前回通信したソケットであるか否かを判定する（Ｓ１６６）。
【００５１】
例えば、デュアルスタックのＡＰＰ１８の場合、そのＡＰＰ１８用のソケットは二つある。このとき、ＡＰＰ１８が一方のソケットのみを連続して用いて通信を行うと、他方のソケットにデータが到着していても、ＡＰＰ１８と通信が行われないということが起こりうる。そこで、本実施形態では、これを防止するために、二つのソケットに交互に通信を行わせる様に調整する。そのため、ステップＳ１６６では、デュアルスタックのＡＰＰ１８について、今回データを受信したソケットが前回通信したソケットであるか否かを判定する。ここで、今回データを受信したソケットが前回通信をしたソケットでないときは（Ｓ１６６：Ｎｏ）、以降の処理をスキップし、当該ソケットが通信を行うソケットとして選択される。なお、シングルスタックの場合には、ステップＳ１６６の判定は常にＮｏである。
【００５２】
一方、今回データを受信したソケットが前回通信をしたソケットであるときは（Ｓ１６６：Ｙｅｓ）、ソケットユーティリティー１２は、前回通信をしたソケット以外の他のソケットにデータが到着しているか否かを判定する（Ｓ１６８）。他のソケットにデータが到着してれば（Ｓ１６８：Ｙｅｓ）、そのデータが到着している他のソケットを通信対象のソケットとして設定する（Ｓ１７０）。他のソケットにデータが到着していなければ（Ｓ１６８：Ｎｏ）、ステップＳ１７０をスキップし、データが到着しているソケットを通信対象のソケットとして選択する。
【００５３】
これにより、デュアルスタックの場合に、一つのソケットだけが集中して通信を行い、他のソケットが通信できないということを防止できる。
【００５４】
次に、上述の第２の実施形態で説明したプロトコル階層に基づく一つの実施例について説明する。
【００５５】
図６は、本発明の実施例におけるネットワークシステムの概略構成図である。ネットワークシステム１０００は、図６に示すように、クライアントコンピュータ（以下、単にクライアントという。）ＣＬ１、ＣＬ２と、サーバー装置１００と、プリンターＰＲＴ１、ＰＲＴ２を含む。クライアントＣＬ１、ＣＬ２と、サーバー装置１００とは、ローカルエリアネットワーク（ＬＡＮ）に、それぞれ接続されている。プリンターＰＲＴ１、ＰＲＴ２は、それぞれ、ＵＳＢ（Universal Serial Bus）ケーブルＣＶを用いてサーバー装置１００に接続されている。サーバー装置１００は、クライアントＣＬ１、ＣＬ２から印刷要求を受け付け、プリンターＰＲＴ１、ＰＲＴ２を用いて印刷を実行するプリントサーバーとして機能する。すなわち、プリンターＰＲＴ１、ＰＲＴ２は、その印刷機能を、サーバー装置１００を介して、クライアントＣＬ１、ＣＬ２に提供する。
【００５６】
図７〜図９を参照してネットワークシステム１０００に含まれる各機器の構成について説明する。図７は、クライアントの内部構成を示す説明図である。図８は、プリントサーバー装置の内部構成を示す説明図である。図９は、プリンターの内部構成を示す説明図である。
【００５７】
クライアントＣＬ１、ＣＬ２は、周知の計算機であり、図７に示すように、中央演算装置（ＣＰＵ）２１０と、メモリー２２０と、ネットワークインターフェースカード（ＮＩＣ）２３０と、表示装置２４０を備えている。ＣＰＵ２１０は、メモリー２２０に格納された各種プログラムを実行することによりクライアントとしての機能を実現する。ＮＩＣ２３０は、ネットワークに接続するための通信インターフェースであり、具体的には、イーサネット（登録商標）の仕様に対応したケーブルを介して、ＬＡＮと接続される。
【００５８】
メモリー２２０には、種々のプログラムやデータが格納されており、図７においては、本実施例における処理に必要な構成を選択的に図示し、本明細書においては、図示された構成について説明する。メモリー２２０には、ＨＴＴＰクライアントプログラム２２１が格納されている。ＨＴＴＰクライアントプログラム２２１は、サーバー装置１００からサービスの提供を受けるために用いられるプログラムであり、例えば、ＷＥＢサービスの提供を受けるためのブラウザ機能、プリントサービスの提供を受けるためのプリンタードライバ機能を実現する。ＨＴＴＰクライアントプログラム２２１は、要求送信部２２１１と、応答受信部２２１２とを含んでいる。要求送信部２２１１は、ＬＡＮ上に接続されたサーバー装置１００に対してサービスの提供を要求するＨＴＴＰリクエストを送信する。ＨＴＴＰリクエストは、ＨＴＴＰ（HyperText Transfer Protocol）に従って、作成される。応答受信部２２１２は、ＬＡＮ上に接続されたサーバー装置１００から上述したＨＴＴＰリクエストに対する応答であるＨＴＴＰレスポンスを受信する。ＨＴＴＰリクエストの送信やＨＴＴＰレスポンスの受信は、ＨＴＴＰ、および、ＨＴＴＰの下位プロトコルであるＴＣＰ／ＩＰを用いて実行される。
【００５９】
サーバー装置１００は、図８に示すように、ＣＰＵ１１０と、メモリー１２０と、ＮＩＣ１３０と、ＵＳＢホストＩ／Ｆ部１４０を備えている。ＣＰＵ１１０は、メモリー１２０に格納されている各種プログラムを実行することにより、サーバー装置１００の機能を実現する。ＮＩＣ１３０は、ＬＡＮを介して、クライアントＣＬ１、ＣＬ２をはじめとするネットワーク上の機器と通信するためのインターフェースであり、具体的には、イーサネット（登録商標）の仕様に対応したケーブルを介して、ＬＡＮと接続される。ＵＳＢホストＩ／Ｆ部１４０は、ＵＳＢケーブルＣＶを接続するためのＵＳＢホストコネクタ１４１〜１４３を備え、ＵＳＢケーブルＣＶを介して、ＵＳＢデバイス（図６に示す例では、プリンターＰＲＴ１〜ＰＲＴ３）と接続される。ＵＳＢホストＩ／Ｆ部１４０は、ＵＳＢデバイスと通信するためのインターフェースであり、ＵＳＢ規格に従ったデータ通信を、接続されたＵＳＢデバイスとの間で実行する。
【００６０】
メモリー１２０には、種々のプログラムやデータが格納されており、図８においては、本実施例における処理に必要な構成を選択的に図示し、本明細書においては、図示された構成について説明する。メモリー１２０には、複数種類のサービスプログラム、すなわち、ＷＥＢサービスプログラム１２１およびプリントサービスプログラム１２２と、ＨＴＴＰサーバープログラム１２３と、登録テーブル１２５と、ソケットユーティリティープログラム１２７と、ソケットユーティリティープログラム１２７が参照するデータベース１２８とが、格納されている。
【００６１】
ＷＥＢサービスプログラム１２１は、クライアントからのＨＴＴＰリクエストに応じて、クライアントに対してＷＥＢサービスを提供するプログラムである。ＷＥＢサービスは、例えば、ＷＥＢページを介して、プリンターＰＲＴ１〜３あるいはサーバー装置１００に関する情報の提供、プリンターＰＲＴ１〜３あるいはサーバー装置１００に関する設定（例えば、サーバー装置１００のＩＰアドレスの設定）を行うために用いられる。
【００６２】
プリントサービスプログラム１２２は、クライアントからのＨＴＴＰリクエストに応じて、プリントサービスを提供する、すなわち、プリンターＰＲＴ１〜ＰＲＴ３を用いて印刷を実行するプログラムである。このようなＨＴＴＰを使用した印刷は、例えば、ＩＰＰ（Internet Printing Protocol）として標準化されている。
【００６３】
ＷＥＢサービスプログラム１２１およびプリントサービスプログラム１２２は、それぞれ、情報登録実行部１２１１、１２２１を備えている。情報登録実行部１２１１、１２２１は、後述する登録情報を登録テーブル１２５及びデータベース１２８に登録する。登録テーブル１２５及びデータベース１２８への登録は、例えば、各サービスプログラム１２１、１２２が起動された時に、サービスプログラムごとに実行される。
【００６４】
ＨＴＴＰサーバープログラム１２３は、主として、クライアントＣＬ１、ＣＬ２と、サービスプログラムとのデータのやり取り（リクエストやレスポンスのやり取り）を中継する。ＨＴＴＰサーバープログラム１２３は、登録情報取得部１２３１と、要求中継部１２３２と、送受信部１２３３とを含んでいる。登録情報取得部１２３１は、登録テーブル１２５に登録されている登録情報を取得する。登録情報には、後述する選択条件および設定情報が含まれる。登録テーブル１２５の具体的な内容については後述する。送受信部１２３３は、クライアントからＨＴＴＰリクエストを受信すると共に、クライアントに対してＨＴＴＰレスポンスを送信する。送受信部１２３３は、ＨＴＴＰリクエストの受信やＨＴＴＰレスポンスの送信を、ＨＴＴＰ、および、ＨＴＴＰの下位プロトコルであるＴＣＰ／ＩＰを用いて実行するが、これらのプロトコルの設定は、登録情報取得部１２３１により取得された登録情報に含まれる設定情報に従って実行される。要求中継部１２３２は、受信されたＨＴＴＰリクエストを与えるサービスプログラムを上述した複数種類のサービスプログラムの中から選択すると共に、選択されたサービスプログラムを呼び出す（コールする）。要求中継部１２３２は、選択されたサービスプログラムに、受信されたＨＴＴＰリクエストを与える。サービスプログラムの選択は、ＨＴＴＰリクエストに含まれる情報と、登録情報取得部１２３１により取得された登録情報に含まれる選択条件とを比較することにより実行される。
【００６５】
ソケットユーティリティープログラム１２７は、データベース１２８を参照して、ＷＥＢサービスプログラム１２１及びプリントサービスプログラム１２２がＨＴＴＰサーバープログラム１２３を介して通信を行うためのソケットを生成する。例えば、データベース１２８には、ＨＴＴＰサーバープログラム１２３がデュアルスタックとして登録されている。また、ＷＥＢサービスプログラム１２１及びプリントサービスプログラム１２２のサービス名と、ＷＥＢサービスプログラム１２１及びプリントサービスプログラム１２２がそれぞれサポートしているＩＰバージョンとは、登録テーブル１２５に対応付けて登録されている。ソケットユーティリティープログラム１２７は、登録テーブル１２５及びデータベース１２８を参照して、登録テーブル１２５に登録されている各サービス宛のＨＴＴＰリクエストを、ＨＴＴＰサーバープログラム１２３が受信するためのＩＰｖ４用ソケット及びＩＰｖ６用のソケットを生成し、各ソケットを受信可能状態とする。
【００６６】
サーバー装置１００と接続されるＵＳＢデバイスであるプリンターＰＲＴ１〜ＰＲＴ３について説明する。以下の説明において、各プリンターＰＲＴ１〜ＰＲＴ３を区別する必要がない場合には、符号の末尾の数字を省略し、プリンターＰＲＴと表記する。プリンターＰＲＴは、図９に示すように、コントローラ３１０と、プリントエンジン３２０と、ＵＳＢデバイスＩ／Ｆ部３４０とを備えている。コントローラ３１０は、プリンター全体を制御する計算機であり、ＣＰＵ３１１と、メモリー３１２を備えている。メモリー３１２には、プリンターＰＲＴの制御プログラム３１３が格納されており、ＣＰＵ３１１は、制御プログラム３１３を実行することによりプリンターＰＲＴを制御する。プリントエンジン３２０は、実際に印刷を行う機構部分であり、本実施例では、静電気によってトナー粉が付着する現象を利用して印刷用紙上に画像を形成するいわゆるレーザー式のプリントエンジンである。ＵＳＢデバイスＩ／Ｆ部３４０は、サーバー装置１００と接続するためのＵＳＢデバイスコネクタ３４５を備え、ＵＳＢケーブルＣＶを介して、サーバー装置１００と接続される。ＵＳＢデバイスＩ／Ｆ部３４０は、サーバー装置１００と通信するためのインターフェースであり、ＵＳＢ（Universal Serial Bus）規格に従ったデータ通信を、サーバー装置１００との間で実行する。
【００６７】
図１０を参照して、サーバー装置１００のメモリー１２０に格納されている登録テーブル１２５について、説明する。図１０は、登録テーブル１２５の具体例を概念的に示す説明図である。登録テーブル１２５は、各サービスプログラム１２１、１２２と、ＨＴＴＰサーバープログラム１２３が、それぞれアクセス可能に構成されている。登録テーブル１２５には、登録情報が、上述したサービスプログラム１２１、１２２の各情報登録実行部１２１１、１２２１により、サービスプログラムごとに登録されている。図１０において登録情報１の列に記述されている登録情報は、ＷＥＢサービスプログラム１２１について登録された情報であり、登録情報２の列に記述されている登録情報は、プリントサービスプログラム１２２について登録された情報である。登録情報は、呼び出すサービスプログラムを特定するサービス名（図１０：１行目）と共に、上述した選択条件（図１０：２〜７行目）と、上述した設定情報（図１０：８〜１３行目）とを含む。本実施例において、図１０に示すように、選択条件の項目は、ＨＴＴＰメソッド、リクエストＵＲＩ、受信ポート番号、受信プロトコル、ＩＰバージョン、ＵＲＩ判定条件を含んでおり、設定情報の項目は、使用スタックサイズ、受信タイムアウト、送信タイムアウト、コネクション保持時間、マルチキャストアドレス、ループバックを含んでいる。各項目については、ＨＴＴＰサーバープログラム１２３の処理について説明する際に、後述する。
【００６８】
図１１を参照して、サーバー装置１００が、起動時に実行する処理（起動処理）について説明する。図１１は、サーバー装置の起動処理の処理ルーチンを示すフローチャートである。サーバー装置１００が起動されると、メモリー１２０に格納された各プログラム、すなわち、ＷＥＢサービスプログラム１２１、プリントサービスプログラム１２２、ＨＴＴＰサーバープログラム１２３、及びソケットユーティリティープログラム１２７が起動される（ステップＳ１０２）。
【００６９】
続いて、起動された各サービスプログラム１２１、１２２の情報登録実行部１２１１、１２２１は、登録テーブル１２５に、図１０において説明した登録情報を登録する。さらに、ＨＴＴＰサーバープログラム１２３は、データベース１２８に、ＨＴＴＰサーバープログラム１２３をＩＰｖ４及びＩＰｖ６の双方をサポートするデュアルスタックとして登録する（ステップＳ１０４）。例えば、ＷＥＢサービスプログラム１２１の情報登録実行部１２１１は、図１０に示す登録情報１の列に記述された情報を登録する。また、プリントサービスプログラム１２２の情報登録実行部１２２１は、図１０に示す登録情報２の列に記述された情報を登録する。
【００７０】
ソケットユーティリティープログラム１２７は、上述したように、ＷＥＢサービスプログラム１２１及びプリントサービスプログラム１２２をサポートするＨＴＴＰサーバープログラム１２３のためのソケットを生成する（ステップＳ１０５）。このとき、ソケットユーティリティープログラム１２７は、登録テーブル１２５から、受信ポート番号（図１０：４行目）を取得する。そして、図１０の例では、ソケットユーティリティープログラム１２７は、受信ポート番号「８０」及び「６３１」のそれぞれについて、ＩＰｖ４及びＩＰｖ６のソケットを生成する。
【００７１】
ＨＴＴＰサーバープログラム１２３の送受信部１２３３は、ステップＳ１０５で生成したソケットで、ＨＴＴＰリクエストの着信を待つ（ステップＳ１０６）。つまり、送受信部１２３３は、受信ポート番号「８０」が割り当てられているＩＰｖ４及びＩＰｖ６のソケットと、受信ポート番号「６３１」のが割り当てられているＩＰｖ４及びＩＰｖ６のソケットで、ＨＴＴＰリクエストの着信を待つ。
【００７２】
登録されているソケットにデータが到着すると、ＨＴＴＰサーバープログラム１２３の送受信部１２３３は、そのソケットから到着したデータを取得し、ＨＴＴＰリクエストが着信する（ステップＳ１０８）。ＨＴＴＰリクエストが着信すると（ステップＳ１０８：ＹＥＳ）、送受信部１２３３は、着信したＨＴＴＰリクエストに対する処理を呼び出し（ステップＳ１１０）、再びＨＴＴＰリクエストの着信を待つ。送受信部１２３３は、ＨＴＴＰリクエストが着信しない場合には（ステップＳ１１０：ＮＯ）、ＨＴＴＰリクエストの着信を待ち続ける。
【００７３】
図１２および図１３を参照して、上述した起動処理におけるステップＳ１１０において呼び出されるＨＴＴＰリクエストに対する処理について説明する。図１２は、ＨＴＴＰリクエストに対する処理の処理ルーチンを示すフローチャートである。図１３は、ＨＴＴＰリクエストの一例を概念的に示す説明図である。
【００７４】
着信したＨＴＴＰリクエストに対する処理は、ＨＴＴＰサーバープログラム１２３によって実行される。本処理が開始されると、送受信部１２３３は、ＨＴＴＰリクエストの先頭部分を受信する（ステップＳ２０２）。図１３に示すように、ＨＴＴＰリクエスト５００は、先頭から順に、リクエストライン、ヘッダ、ボディを備えている。本ステップでは、少なくともリクエストラインを含むＨＴＴＰリクエスト５００の先頭部分を受信する。
【００７５】
続いて、ＨＴＴＰサーバープログラム１２３の要求中継部１２３２は、登録テーブル１２５に登録された選択条件と、ＨＴＴＰリクエスト５００の備える属性と比較する（ステップＳ２０４）。ここで、選択条件と比較されるＨＴＴＰリクエスト５００の属性（比較属性）は、ＨＴＴＰメソッドと、リクエストＵＲＩと、受信ポート番号と、受信プロトコルと、ＩＰバージョンである。ＨＴＴＰメソッドと、リクエストＵＲＩは、ステップＳ２０２において受信されたＨＴＴＰリクエスト５００の先頭部分に含まれるリクエストラインに記述されている（図１３）。
【００７６】
ＨＴＴＰメソッドは、ＨＴＴＰリクエスト５００がサーバー装置１００に実行を要求する処理を示すコマンドであり、例えば、「ＧＥＴ」「ＰＯＳＴ」などである。リクエストＵＲＩは、ＨＴＴＰリクエスト５００が処理の対象を指定する識別子であり、例えば、ＨＴＴＰリクエストが送信を要求するデータを特定するために用いられる。リクエストＵＲＩは、スキーム名（例えば、http）、ホスト名（例えば、xxx.co.jp）、パス名（例えば、/aaa/bbb）を含む絶対パスと、パス名のみからなる相対パスとが使用されるが、本実施例において、選択条件との比較属性として使用されるのは、パス名の部分のみである。受信ポート番号は、ＨＴＴＰリクエスト５００の宛先とされたポート番号である。受信プロトコルは、ＨＴＴＰリクエスト５００の送信に用いられた通信プロトコルであり、本実施例ではトランスポート層の通信プロトコル（ＴＣＰあるいはＵＤＰ）が選択条件として用いられる。上述したようにＩＰｖ４用ソケット及びＩＰｖ６用ソケットが、それぞれ生成されているので、ＩＰバージョンは受信ソケットにより定まる。
【００７７】
具体的には、要求中継部１２３２は、登録テーブル１２５に登録された選択条件（図１０：２〜６行目）と、処理対象のＨＴＴＰリクエスト５００の比較属性を１つずつ比較して、一致する場合には、その選択条件は満足していると判断する。例えば、ＨＴＴＰリクエスト５００のリクエストラインに記述されたメソッドが、「ＰＯＳＴ」であれば、登録情報２（図１０）について、ＨＴＴＰメソッドに関する選択条件は満たされていると判断される。
【００７８】
さらに、登録情報２のリクエストＵＲＩに関する選択条件は、「/IPP_printer」であり（図１０：３行目）であり、ＵＲＩ判定条件は、「前方一致」となっている（図１０：７行目）。かかる場合には、ＨＴＴＰリクエスト５００のリクエストラインに記述されたＵＲＩのパス名が、「/IPP_printer」と前方一致する場合に、登録情報２について、リクエストＵＲＩに関する選択条件は満たされていると判断される。さらに具体例を挙げて説明すると、ＨＴＴＰリクエスト５００のリクエストラインに記述されたリクエストＵＲＩが、「/IPP_printer/aaa」あるいは「/IPP_printer/bbb/ccc」である場合には、いずれも、登録情報２（図１０）について、ＨＴＴＰメソッドに関する選択条件は満たされていると判断される。一方、もし、ＵＲＩ判定条件が「完全一致」とされている場合には、ＨＴＴＰリクエスト５００のリクエストラインに記述されたＵＲＩのパス名が、「/IPP_printer」と完全一致する場合に限って、リクエストＵＲＩに関する選択条件は満たされていると判断される。例えば、ＨＴＴＰリクエスト５００のリクエストラインに記述されたリクエストＵＲＩが、「/IPP_printer」である場合に限って、登録情報２（図１０）について、ＨＴＴＰメソッドに関する選択条件は満たされていると判断され、リクエストＵＲＩが、「/IPP_printer」「/IPP_printer/aaa」あるいは「/IPP_printer/bbb/ccc」である場合には、いずれも、登録情報２について、ＨＴＴＰメソッドに関する選択条件は満たされていないと判断される。
【００７９】
ここで、図１０において、登録情報１の列におけるＨＴＴＰメソッドおよびリクエストＵＲＩに関する選択条件は、「特別な条件」と記述されている。かかる場合は、ＨＴＴＰリクエスト５００の各比較属性が、他の登録情報についての選択条件を満足しない場合には、登録情報１について、ＨＴＴＰメソッドおよびリクエストＵＲＩに関する選択条件は、満たされていると判断される。例えば、図１０の例では、ＨＴＴＰリクエスト５００の比較属性のいずれかが、登録情報２について登録されている選択条件を満たさない場合に、登録情報１について、ＨＴＴＰメソッドおよびリクエストＵＲＩに関する選択条件は満たされていると判断される。
【００８０】
続いて、要求中継部１２３２は、登録テーブル１２５に登録された選択条件（図１０：２〜６行目）と、ＨＴＴＰリクエスト５００の属性との比較結果に基づいて、選択条件と合致するサービスプログラムを選択する（ステップＳ２０６）。具体的には、先のステップＳ２０４において、処理対象のＨＴＴＰリクエスト５００の属性が、図１０の２〜６行目までの選択条件を全て満たしていると判断される登録情報がある場合には、その登録情報の１行目に記述されているサービスプログラムが選択される。具体例を挙げて説明すると、例えば、処理対象のＨＴＴＰリクエスト５００のＨＴＴＰメソッド、リクエストＵＲＩ、受信ポート番号、受信プロトコル、ＩＰバージョンが、それぞれ、「ＰＯＳＴ」、「/IPP_printer/aaa」、「６３１」、「ＴＣＰ」、「ｖ６」である場合には、要求中継部１２３２は、プリントサービスプログラム１２２を選択する。一方、処理対象のＨＴＴＰリクエスト５００のＨＴＴＰメソッド、リクエストＵＲＩ、受信ポート番号、受信プロトコル、ＩＰバージョンが、それぞれ、「ＧＥＴ」、「/config/ccc」、「８０」、「ＴＣＰ」、「ｖ６」である場合には、要求中継部１２３２は、ＷＥＢサービスプログラム１２１を選択する。もし、選択条件と合致するサービスプログラムが登録テーブル１２５に登録されていない場合には、ＨＴＴＰサーバープログラム１２３は、クライアントに対して、エラーを通知するＨＴＴＰレスポンスを送信することとしても良い。
【００８１】
サービスプログラムが選択されると、登録情報取得部１２３１は、選択されたサービスプログラムに応じた設定情報（図１０：８〜１３行目）を、登録テーブル１２５から取得する（ステップＳ２０８）。本ステップで取得された設定情報は、以降の処理におけるサーバー装置１００の動作設定に用いられる。
【００８２】
設定情報が取得されると、要求中継部１２３２は、ステップＳ２０６において選択されたサービスプログラムを呼び出す（ステップＳ２１０）。ここで、要求中継部１２３２は、サービスプログラムを呼び出す際に、呼び出されたサービスプログラムが使用するスタック領域を、メモリー１２０上に割り当てる。割り当てられるスタック領域のサイズは、ステップＳ２０８において取得された設定情報に含まれる使用スタックサイズの値（図１０：８行目）に設定される。スタック領域は、自動変数、関数の引数、戻り値、リターンアドレス等、サービスプログラムにより処理中に一時的に使用されるデータが格納されるメモリー領域である。要求中継部１２３２は、サービスプログラムを呼び出す際に、呼び出されたサービスプログラムに対して、処理中のＨＴＴＰリクエスト５００のうち、ステップＳ２０２において受信済みの先頭部分を与える。この結果、サービスプログラムは、ＨＴＴＰリクエスト５００に応じてサービスを提供する処理、例えば、ＷＥＢサービスプログラム１２１であればＷＥＢデータをクライアントに提供する処理、プリントサービスプログラム１２２であれば印刷を実行する処理を実行するこができる。
【００８３】
ＨＴＴＰサーバープログラム１２３の送受信部１２３３は、ステップＳ２１０において呼び出されたサービスプログラムの処理に応じて、データの送受信を実行する（ステップＳ２１２）。例えば、呼び出されたサービスプログラムは、与えられたＨＴＴＰリクエスト５００の先頭部分に続くデータ、例えば、図８におけるＨＴＴＰボディのデータを受信する必要があるため、送受信部１２３３はサービスプログラムの要求に応じて、これらのデータをクライアントから受信する。また、呼び出されたサービスプログラムは、与えられたＨＴＴＰリクエスト５００に対するＨＴＴＰレスポンスを作成すると、送受信部１２３３は、ＨＴＴＰレスポンスを、クライアントに対して送信する。本ステップにおける送受信部１２３３によるデータの送受信に関する動作設定は、ステップＳ２０８において取得された設定情報に含まれる受信タイムアウト、送信タイムアウト、ｋｅｅｐ−ａｌｉｖｅタイムアウト、マルチキャストアドレス、ループバックの有効または無効の各値（図１０：９〜１３行目）に設定される。
【００８４】
なお、設定情報は、全てが登録される必要はなく、必要な情報だけ登録されれば良い。例えば、ＷＥＢサービスプログラム１２１とプリントサービスプログラム１２２についての設定情報は、図１０に示すように、マルチキャストアドレスと、ループバックの有効または無効に関して、登録されていない。
【００８５】
以上、説明した本実施例におけるサーバー装置１００によれば、データベース１２８に登録されたＩＰバージョンのソケットが、ソケットユーティリティープログラム１２７により自動的に生成され、これによってＨＴＴＰサーバープログラム１２３の送受信部１２３３がＨＴＴＰリクエスト５００を受信できる。この結果、データベース１２８にサービスプログラムごとのＩＰバージョンを登録するだけで、ＨＴＴＰサーバープログラム１２３がＨＴＴＰリクエスト５００を受信できるようになる。さらに、上述のサーバー装置１００によれば、サービスプログラムごとに登録テーブル１２５に登録された選択条件と、ＨＴＴＰリクエスト５００の属性とを比較することにより、複数種類のサービスプログラムの中からＨＴＴＰリクエスト５００について処理すべきサービスプログラムを呼び出す。この結果、登録テーブル１２５に選択条件を登録するだけで、ＨＴＴＰサーバープログラム１２３は、ＨＴＴＰリクエスト５００を処理すべきサービスプログラムを容易に選択することができる。さらに、サービスプログラムごとに登録テーブル１２５に登録された設定情報を用いて、サービスプログラムごとに、ＨＴＴＰサーバープログラム１２３の動作が設定される。この結果、ＨＴＴＰサーバープログラム１２３の動作設定が容易になる。
【００８６】
以上の説明から解るように、本実施例におけるサーバー装置１００は、新たにサービスプログラムを追加する場合、新たなサービスプログラムをインストールして、データベース１２８及び登録テーブル１２５に必要な情報を登録するだけで良い。このため、新たなサービスプログラムの追加に伴い、ＨＴＴＰサーバープログラム１２３に改造を加える必要がない。この結果、新たにサービスプログラムを追加することが容易になると共に、新たなサービスプログラムの開発が容易になる。
【００８７】
さらに、各サービスプログラムは、起動時に自身に関するＩＰバージョンをデータベース１２８に、選択条件および設定情報を登録テーブル１２５にそれぞれ登録する情報登録実行部を備える。この結果、新たなサービスプログラムを追加した場合には、サービスプログラム自身がデータベース１２８及び登録テーブル１２５に、自身の動作に必要な情報を登録するので、ユーザの設定負担が軽減される。従って、新たにサービスプログラムを追加することが、さらに、容易になる。
【００８８】
また、ソケットユーティリティープログラム１２７は、データベース１２８を参照することにより、新たに追加されたサービスプログラムがサポートするＩＰバージョンを認識できるので、プログラムを変更することなく、ＩＰバージョンの変更に対応することができる。
【００８９】
さらに、ＨＴＴＰサーバープログラム１２３は、新たなサービス部が追加された場合、登録テーブル１２５を参照することにより、新たなサービス部の存在を認識して、新たなサービス部に関する送受信処理をサポートするので、新たなサービス部の追加に伴うＨＴＴＰサーバープログラム１２３の改造や、再設定を、ユーザ等が行う必要もない。
【００９０】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【符号の説明】
【００９１】
１ サーバー
１１ ＯＳ
１２ ソケットユーティリティー
１３ ＨＴＴＰサーバー
１４ ＷＥＢサーバー
１５ データベース
１００ サーバー装置
１２１ ＷＥＢサービスプログラム
１２２ プリントサービスプログラム
１２３ ＨＴＴＰサーバープログラム
１２５ 登録テーブル
１２７ ソケットユーティリティープログラム
１２８ データベース
【特許請求の範囲】
【請求項１】
アプリケーションプログラムが動作しているサーバーであって、
前記アプリケーションプログラムの識別情報と前記アプリケーションプログラムがサポートするＩＰバージョンとを対応付けて記憶したデータベースと、
前記データベースを参照し、前記アプリケーションプログラム用のソケットであって前記ＩＰバージョンに対応したソケットを生成するソケットユーティリティーと、を備え、
前記アプリケーションプログラムは、前記生成されたソケットを介してデータを受信することを特徴とするサーバー。
【請求項２】
前記生成されたソケットのソケットハンドルを取得し、前記ソケットハンドルに含まれている前記アプリケーションプログラムの識別情報により定まるアプリケーションプログラムを呼び出すディスパッチャーを、さらに備え、
前記呼び出されたアプリケーションプログラムが前記生成されたソケットを介してデータを受信する、請求項１記載のサーバー。
【請求項３】
前記ＩＰバージョンは、ＩＰｖ４またはＩＰｖ６である、請求項１または２に記載のサーバー。
【請求項４】
前記ディスパッチャーは、前記ソケットハンドルに含まれている、前記アプリケーションプログラムがサポートするＩＰバージョンに対応する前記アプリケーションプログラムのモジュールを呼び出す、請求項２記載のサーバー。
【請求項５】
前記アプリケーションプログラムが、ＩＰｖ４及びＩＰｖ６の双方をサポートするデュアルスタックである場合、
前記データベースには、前記アプリケーションプログラムの識別情報に、ＩＰｖ４を示す情報及びＩＰｖ６を示す情報が対応付けて登録されていて、
前記ソケットユーティリティーは、ＩＰｖ４に対応するソケット及びＩＰｖ６に対応するソケットを生成する、請求項１〜３のいずれかに記載のサーバー。
【請求項６】
前記ソケットユーティリティーは、前記アプリケーションプログラムに、前記ＩＰｖ４に対応するソケット及び前記ＩＰｖ６に対応するソケットを交互に利用させてデータを受信させる、請求項５記載のサーバー。
【請求項７】
アプリケーションプログラムの識別情報と前記アプリケーションプログラムがサポートするＩＰバージョンとをデータベースに登録するステップと、
前記データベースを参照し、前記アプリケーションプログラム用のソケットであって前記ＩＰバージョンに対応したソケットを生成するステップと、
前記アプリケーションプログラムは、前記生成されたソケットを介してデータを受信するステップと、を行うデータ受信方法。
【請求項１】
アプリケーションプログラムが動作しているサーバーであって、
前記アプリケーションプログラムの識別情報と前記アプリケーションプログラムがサポートするＩＰバージョンとを対応付けて記憶したデータベースと、
前記データベースを参照し、前記アプリケーションプログラム用のソケットであって前記ＩＰバージョンに対応したソケットを生成するソケットユーティリティーと、を備え、
前記アプリケーションプログラムは、前記生成されたソケットを介してデータを受信することを特徴とするサーバー。
【請求項２】
前記生成されたソケットのソケットハンドルを取得し、前記ソケットハンドルに含まれている前記アプリケーションプログラムの識別情報により定まるアプリケーションプログラムを呼び出すディスパッチャーを、さらに備え、
前記呼び出されたアプリケーションプログラムが前記生成されたソケットを介してデータを受信する、請求項１記載のサーバー。
【請求項３】
前記ＩＰバージョンは、ＩＰｖ４またはＩＰｖ６である、請求項１または２に記載のサーバー。
【請求項４】
前記ディスパッチャーは、前記ソケットハンドルに含まれている、前記アプリケーションプログラムがサポートするＩＰバージョンに対応する前記アプリケーションプログラムのモジュールを呼び出す、請求項２記載のサーバー。
【請求項５】
前記アプリケーションプログラムが、ＩＰｖ４及びＩＰｖ６の双方をサポートするデュアルスタックである場合、
前記データベースには、前記アプリケーションプログラムの識別情報に、ＩＰｖ４を示す情報及びＩＰｖ６を示す情報が対応付けて登録されていて、
前記ソケットユーティリティーは、ＩＰｖ４に対応するソケット及びＩＰｖ６に対応するソケットを生成する、請求項１〜３のいずれかに記載のサーバー。
【請求項６】
前記ソケットユーティリティーは、前記アプリケーションプログラムに、前記ＩＰｖ４に対応するソケット及び前記ＩＰｖ６に対応するソケットを交互に利用させてデータを受信させる、請求項５記載のサーバー。
【請求項７】
アプリケーションプログラムの識別情報と前記アプリケーションプログラムがサポートするＩＰバージョンとをデータベースに登録するステップと、
前記データベースを参照し、前記アプリケーションプログラム用のソケットであって前記ＩＰバージョンに対応したソケットを生成するステップと、
前記アプリケーションプログラムは、前記生成されたソケットを介してデータを受信するステップと、を行うデータ受信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１０−１７６１６４（Ｐ２０１０−１７６１６４Ａ）
【公開日】平成２２年８月１２日（２０１０．８．１２）
【国際特許分類】
【出願番号】特願２００９−１４９８６（Ｐ２００９−１４９８６）
【出願日】平成２１年１月２７日（２００９．１．２７）
【出願人】（０００００２３６９）セイコーエプソン株式会社 (51,324)
【Ｆターム（参考）】
【公開日】平成２２年８月１２日（２０１０．８．１２）
【国際特許分類】
【出願日】平成２１年１月２７日（２００９．１．２７）
【出願人】（０００００２３６９）セイコーエプソン株式会社 (51,324)
【Ｆターム（参考）】
[ Back to top ]