JP4458799B2

JP4458799B2 - ネットサービス機能を有する情報処理装置およびネットサービス提供方法

Info

Publication number: JP4458799B2
Application number: JP2003323538A
Authority: JP
Inventors: 学中村; 孝治藤永
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2003-09-16
Filing date: 2003-09-16
Publication date: 2010-04-28
Anticipated expiration: 2023-09-16
Also published as: JP2005092456A

Description

本発明はネットサービス機能を有する情報処理装置およびネットサービス提供方法に関するものである。

近年、プリンタ、コピー、ファクシミリ、スキャナ等の各装置の機能を一つの筐体内に収納した、複合機あるいは融合機と呼ばれる画像形成装置が提供されるに至っている。更に、これらの画像形成装置は、オフィス内のイントラネット等に接続可能とされ、Ｗｅｂサービス等の各種のネットサービスを提供する機能も有している。

ところで、上述したネットサービス機能を有した従来の画像形成装置にあっては、ブラウザ等のＨＴＴＰクライアントからのリクエストをＨＴＴＰデーモン（ｈｔｔｐｄ）と呼ばれるサーバプログラムで処理しており、ＨＴＴＰデーモンはリクエストに含まれるＵＲＬパスに従って対応するＷｅｂアプリケーションに処理をディスパッチ（振り分け）し、処理のレスポンスをＨＴＴＰクライアントに戻すまでの処理を行っている。ここで、ＨＴＴＰデーモン（ｈｔｔｐｄ）と呼ばれるサーバプログラムは、一般には単一のポート番号（例えば「８０」）で識別され単独でＷｅｂサービスを提供するもの（例えばフリーのＷｅｂサーバソフトで有名な「Ａｐａｃｈｅ」等）を意味することが多いが、画像形成装置の分野では上述したような意味で用いられている。これは、画像形成装置に要求される多数の機能を満たすため、一般のネットサービスよりも細分化されたプロトコルを処理する必要があるためである。

ネットサービス機能を有した従来の画像形成装置におけるＨＴＴＰデーモンの動作をより詳しく説明すると次のようになる。

先ず、ＨＴＴＰデーモンはサービスに固定的に割り当てられたポートを起動時に全てオープンする。例えば、通常のＨＴＴＰ通信はポート「８０」、ＳＳＬ（ＳｅｃｕｒｅＳｏｃｋｅｔｓＬａｙｅｒ）を使ったＨＴＴＰ通信はポート「４４３」、画像形成装置に特有のＩＰＰ（ＩｎｔｅｒｎｅｔＰｒｉｎｔｉｎｇＰｒｏｔｏｃｏｌ）はポート「６３１」といったものである。

次いで、ＨＴＴＰデーモンは自己がオープンしたポートで受け付けたＨＴＴＰリクエストに対し、ＨＴＴＰリクエストに含まれるＵＲＬパスのチェックを行い、対応するＷｅｂアプリケーションに処理をディスパッチする。例えば、Ｗｅｂアプリケーション「Ｗｅｂｓｙｓ」のＵＲＬパスが「／ｗｅｂｓｙｓ／ａａａ」と定めてあった場合、ＨＴＴＰリクエストにＵＲＬパス「／ｗｅｂｓｙｓ／ａａａ」が指定されていた場合はＷｅｂアプリケーション「Ｗｅｂｓｙｓ」に処理をディスパッチする。このとき特にポート番号のチェックは行わず、ＵＲＬパスのチェックが通ればどのポート番号で受け付けたＨＴＴＰリクエストであっても対応するＷｅｂアプリケーションにディスパッチが行われる。なお、対応するＵＲＬパスが存在しない場合はエラーを返すことになる。

その後、Ｗｅｂアプリケーションで処理が行われ、結果としてＨＴＭＬ，ＸＭＬ，ＴＥＸＴ等の文書が生成されると、ＨＴＴＰデーモンはリクエスト元のＨＴＴＰクライアントに結果を返す。

一方、装置内のアドレス可能な部分（例えば、プロセス）へのメッセージの経路をポート番号を用いて選択する先行技術が開示されている（例えば、特許文献１参照。）。
特表２００２−５２３９２４号公報

上述した従来のネットサービス機能を有した画像形成装置におけるＨＴＴＰデーモンの動作は一般のＷｅｂサーバとは異なる特徴的なものであるが、次のような問題点があった。

すなわち、ＵＲＬパスのチェックが通ればどのポート番号で受け付けたＨＴＴＰリクエストであっても対応するＷｅｂアプリケーションに処理が渡ってしまうことから、Ｗｅｂアプリケーションが想定していないポート番号からのＨＴＴＰアクセスを受け付けてしまう可能性があり、セキュリティ上の問題（セキュリティホールになりかねないという問題）があった。

また、遠隔診断サービス：ＮＲＳ（ＮｅｗＲｅｍｏｔｅＳｅｒｖｉｃｅ）と呼ばれるような契約した特別なユーザしか使用しないアプリケーションに対応するポートがオープンされている可能性もあり、そのポートを介した不正アクセスなど、実際に使用していないポートがオープンされていることによるセキュリティ上の問題（セキュリティホールになりかねないという問題）があった。なお、実際に使用していないポートがオープンされる場合としては、上記のＮＲＳの他に、ファックスボードが実装されていない場合にファックスアプリケーション用のポートがオープンされる場合など、画像形成装置では多くの原因が考えられる。

一方、予め定められたポート番号が固定的に割り当てられてしまうため、独自のポート番号を用いた通信を行うことができず、Ｗｅｂアプリケーション側の自由度が低いという問題もあった。

以上の点はＨＴＴＰデーモンについてだけでなく、ＦＴＰデーモン（ｆｔｐｄ）等の他のネットサービスを扱うプロトコルデーモンについても同様に言える問題である。

本発明は上記の問題点に鑑み提案されたものであり、その目的とするところは、画像形成装置を含む情報処理装置において、ポートアクセスにおけるセキュリティの向上を図ると共にアプリケーション側のポート選定の自由度を高めることのできるネットサービス機能を有する情報処理装置およびネットサービス提供方法を提供することにある。

上記課題を解決するため、本発明は、請求項１に記載されるように、複数のポートから入ってくるリクエストをプロトコルデーモンが受け付け、当該リクエストに含まれるアプリケーションを特定する情報に基づいてアプリケーションに処理のディスパッチを行うネットサービス機能を有する情報処理装置において、上記リクエストを受け付けたときに上記アプリケーションに対応するポート識別子を取得して当該リクエストが入ってきたポート番号に対応するポート識別子と一致するか否かをチェックし、一致した場合にのみアプリケーションへのディスパッチを行うリクエスト処理部を上記プロトコルデーモン内に備えるように構成している。

これにより、想定しないポートからのリクエストがアプリケーションに渡ることがなくなり、セキュリティの向上を図ることができる。

また、本発明は、請求項２に記載されるように、複数のポートから入ってくるリクエストをプロトコルデーモンが受け付け、当該リクエストに含まれるアプリケーションを特定する情報に基づいてアプリケーションに処理のディスパッチを行う情報処理装置のネットサービス提供方法において、上記プロトコルデーモンが、上記リクエストを受け付けたときに上記アプリケーションに対応するポート識別子を取得して当該リクエストが入ってきたポート番号に対応するポート識別子と一致するか否かをチェックする手順と、一致した場合にのみ、上記プロトコルデーモンが、アプリケーションへのディスパッチを行う手順とを備えるネットサービス提供方法として構成することができる。

本発明によれば、想定しないポートからのリクエストがアプリケーションに渡ることがなくなると共に、使われないポートについて不用意にオープンとされることがなくなり、ポートアクセスにおけるセキュリティの向上を図ることができる。また、アプリケーション毎に処理を受け付けるポートを登録するため、アプリケーション側のポート選定の自由度を高めることができる。更に、ポート識別子という概念を導入してポートの管理を行うことにより、ポート番号を一斉に変更するような場合に容易に対応することができる。

以下、本発明の実施の形態を図面に基づいて説明する。

図１は本発明を画像形成装置に適用した一実施例に係る画像形成装置の機能構成を示すブロック図である。

図１において、画像形成装置１は、アプリケーション層２とプラットフォーム層４とエンジン部８とを含む。インタフェース３はアプリケーション層２に対するプラットフォーム層４の提供するインタフェース（ＡＰＩ）であり、インタフェース７はプラットフォーム層４とエンジン部８との間のインタフェース（エンジンＩ／Ｆ）である。

アプリケーション層２は画像形成装置１における個別の処理を行うソフトウェア群であり、コピー用のアプリケーションであるコピーアプリケーション２１と、ファックス用のアプリケーションであるファックスアプリケーション２２と、プリンタ用のアプリケーションであるプリンタアプリケーション２３と、ネットワークを介してファイルのやりとりを行うネットファイル用のアプリケーションであるネットファイルアプリケーション２４とを含む。また、Ｗｅｂアプリケーション２０はＨＴＴＰプロトコルによるＷｅｂサービスを行うアプリケーション群であり、ブラウザを使って機器の状態を見たり、機器のネットワーク設定等をすることができるＷｅｂアプリケーション（Ｗｅｂｓｙｓ）２５と、ネットファイルアプリケーション２４の機能を使い、ブラウザを使って文書の引き取りおよび文書管理を行うＷｅｂアプリケーション（ｗｅｂｄｏｃｂｏｘ）２６と、プリンタのジョブ履歴（スプールの状態）等を表示するＷｅｂアプリケーション（ＧＰＳ−ｗｅｂ）２７と、ファックスの初期設定やファックスの通信管理レポート（通信履歴）を表形式で見ることのできるＷｅｂアプリケーション（Ｆａｘ−ｗｅｂ）２８とを含む。

また、ＮＲＳアプリケーション２９は従来技術の部分でも説明したように、遠隔診断サービス：ＮＲＳ（ＮｅｗＲｅｍｏｔｅＳｅｒｖｉｃｅ）と呼ばれる、契約した特別なユーザに提供される遠隔診断サービスを行うアプリケーションである。

なお、図では省略してあるが、アプリケーションとインタフェース３の間にはアプリケーションに対して共通的な機能を提供しソフトウェア開発を容易にするためのライブラリ（プラットフォーム）が適宜に設けられる。

一方、プラットフォーム層４はアプリケーション層２のアプリケーション２１〜２９に対してインタフェース３を介して共通的なサービス機能を提供するソフトウェア群であり、サービス層５とＯＳ層６に分かれる。サービス層５には、アプリケーション管理、操作部制御、システム画面表示、ＬＥＤ表示、リソース管理、および割り込み制御等の複数の機能を有するＳＣＳ５１と、ファックス機能のＡＰＩを提供するＦＣＳ５２と、エンジン部の制御を行うＥＣＳ５３と、メモリ制御を行うＭＣＳ５４と、オペレータ（操作者）とのインタフェースとなる操作部（オペレーションパネル）の制御を行うＯＣＳ５５と、ネットワーク入出力を必要とするアプリケーションに対して共通に利用できるサービスを提供するＮＣＳ５６とが含まれる。ＯＳ層６にはＯＳ（ＬＰＵＸ）６１が含まれる。

一方、エンジン部８には、プロッタ８１、スキャナ８２、その他ハードウェアリソース８３等のエンジンと、これらのエンジンを制御するエンジン制御ボード８４とが含まれる。

図２は図１に示す画像形成装置のハードウェア構成を示すブロック図である。

図２において、画像形成装置１は、画像形成装置における主たる制御動作を行うコントローラ１０１にオペレーションパネル１１３とファックスコントロールユニット１１４とプロッタ８１とスキャナ８２とその他ハードウェアリソース８３とが接続されて構成されている。

コントローラ１０１は、画像処理用途向けのＩＣであるＡＳＩＣ１０２にブリッジとしてのＮＢ１０５を介して一般制御用のＩＣであるＣＰＵ１０６が接続され、ＮＢ１０５のバス（ＰＣＩＢＵＳ）に、周辺デバイス等との接続を行うブリッジであるＳＢ１０８と、ネットワーク通信を制御するＮＩＣ１０９と、ＵＳＢインタフェースを提供するＵＳＢ１１０と、ＩＥＥＥ１３９４インタフェースを提供するＩＥＥＥ１３９４１１１と、セントロニクスインタフェースを提供するセントロニクス１１２とが接続され、ＡＳＩＣ１０２に記憶装置としてのＭＥＭ−Ｃ１０３とＨＤＤ１０４が接続され、ＮＢ１０５に記憶装置としてのＭＥＭ−Ｐ１０７が接続されて構成されている。

図３は図１に示す画像形成装置のネットサービス機能に関する部分の機能構成を示すブロック図である。

図３において、ＮＣＳ５６は図１のサービス層５におけるものと同じであり、本発明の機能に関係する内部構成のみを示している。なお、図３の上部に同名のＮＣＳ５６Ａが示されており、ＮＣＳ５６と一体をなすものであるが、機能的に分けて示してある。

ＮＣＳ５６にはインタフェース３を介し、Ｗｅｂアプリライブラリ２０２およびＷｅｂページライブラリ２０１を挟んで、Ｗｅｂアプリケーション（Ｗｅｂｓｙｓ）２５およびＷｅｂアプリケーション（ｗｅｂｄｏｃｂｏｘ）２６を含むＷｅｂアプリケーション２０が配置されている。また、ＮＣＳ５６にはインタフェース３を介し、ＮＲＳアプリケーション２９も配置されている。

一方、ＮＣＳ５６にはＨＴＴＰのプロトコルに関する処理を行うＨＴＴＰデーモン５６１と、ＦＴＰのプロトコルに関する処理を行うＦＴＰデーモン５６４が含まれており、ＨＴＴＰデーモン５６１にはＩＰＰライブラリ２０３を介してプリンタアプリケーション２３が配置されている。ここで、ＩＰＰライブラリ２０３はＨＴＴＰのプロトコルを使った印刷であるＩＰＰ（ＩｎｔｅｒｎｅｔＰｒｉｎｔｉｎｇＰｒｏｔｏｃｏｌ）に対応させるためのものであり、ＨＴＴＰデーモン５６１から直接にＩＰＰライブラリ２０３を経由してプリンタアプリケーション２３にジョブを渡すようにしている。

一方、ＨＴＴＰクライアント９はネットワークを経由してリクエストを出しレスポンスを受ける部分であり、通常はパーソナルコンピュータ上で稼動するブラウザである。

ＨＴＴＰデーモン５６１の内部構成について説明すると、ＨＴＴＰデーモン５６１には、アプリケーション（２５，２６，２３，２９等）毎に処理を受け付けるポートを対応付けて登録する処理等を行うポート登録部５６２と、ネットワークを経由してＨＴＴＰクライアント９からリクエストを受け付けたときにアプリケーションに対応するポートを取得して当該リクエストのポートとが一致するか否かをチェックし、一致した場合にのみアプリケーションへのディスパッチを行うリクエスト処理部５６３と、アプリケーションを識別するアプリＩＤとＵＲＬパスとを対応付けて管理するアプリＩＤ／ＵＲＬパス対応テーブルＴ２と、アプリケーションを識別するアプリＩＤとポート識別子とを対応付けて管理するアプリＩＤ／ポート識別子対応テーブルＴ３とを含んでいる。

ここで、「ＵＲＬパス」とはＨＴＴＰリクエストを例えば「http://xxx.xxx.xxx.xxx/web/user/ja/websys/webArch/mainFrame.cgi」とした場合、ホスト「xxx.xxx.xxx.xxx」の次から最後までの「web/user/ja/websys/webArch/mainFrame.cgi」部分を意味するものである。ちなみに、ホスト「xxx.xxx.xxx.xxx」に続く１階層分の「web」部分は「アプリケーションパス」と呼ばれる。

また、アプリＩＤ／ＵＲＬパス対応テーブルＴ２およびアプリＩＤ／ポート識別子対応テーブルＴ３はＨＴＴＰデーモン５６１の管理するメモリ上に配置される。これは、他のプロセスでは使用されないデータであると共に、セキュリティの確保からデータを適切に管理するためである。なお、アプリＩＤ／ＵＲＬパス対応テーブルＴ２およびアプリＩＤ／ポート識別子対応テーブルＴ３は画像形成装置１の起動直後は空の状態であり、その後のポート登録部５６２の動作によりデータが登録されていく。

一方、ＮＣＳ５６の外にポート識別子と実際のポート番号とを対応付けて管理するポート識別子／ポート番号対応テーブルＴ１が設けられている。このポート識別子／ポート番号対応テーブルＴ１はハードディスク装置等にファイルとして存在すると共に、画像形成装置１の起動後はメモリ上にコピーされて使用されるものである。これは、ポート識別子とポート番号の対応を示すに過ぎないものであると共に、他のプロセス、例えばＦＴＰデーモン５６４等によって参照される可能性のあるデータであるからである。なお、ポート識別子／ポート番号対応テーブルＴ１は予めポート識別子とポート番号とが管理者等によって登録されているものである。

図４はポート登録の処理手順を示すシーケンス図である。

以下、図４に沿ってポート登録の処理手順を説明する。

先ず、画像形成装置１の起動後の任意の時点でいずれかのアプリケーション（２５，２６，２３等）から、利用するＵＲＬパスの登録の依頼がＨＴＴＰデーモン５６１に対して行われると（ステップＳ１）、ＨＴＴＰデーモン５６１のポート登録部５６２は依頼元のアプリケーションを識別するアプリＩＤと指定されたＵＲＬパスを対応付けてアプリＩＤ／ＵＲＬパス対応テーブルＴ２に登録する（ステップＳ２）。

次いで、アプリケーションから自己へのアクセスを許可するリクエストのポートに対応するポート識別子の登録の依頼が行われると（ステップＳ３）、ＨＴＴＰデーモン５６１のポート登録部５６２は依頼元のアプリケーションを識別するアプリＩＤと指定されたポート識別子を対応付けてアプリＩＤ／ポート識別子対応テーブルＴ３に登録する（ステップＳ４）。

次いで、ＨＴＴＰデーモン５６１のポート登録部５６２はポート識別子／ポート番号対応テーブルＴ１を参照し、登録の完了したポート識別子に対応するポート番号を取得し（ステップＳ５）、そのポート番号のポートがオープンされているか否かを判断した上でオープンされていない場合（クローズの場合）はそのポートを動的にオープンする（ステップＳ６）。

図５は上記のポート登録におけるアプリケーションからの依頼とテーブルに登録される内容の関係を示す図である。

図５において、Ｗｅｂアプリケーション（Ｗｅｂｓｙｓ）２５，Ｗｅｂアプリケーション（ｗｅｂｄｏｃｂｏｘ）２６，プリンタアプリケーション２３からそれぞれ依頼Ｄ１，Ｄ２，Ｄ３が前後して行われた場合、図４に示した処理手順により、アプリＩＤ／ＵＲＬパス対応テーブルＴ２およびアプリＩＤ／ポート識別子対応テーブルＴ３にデータが登録される。すなわち、例えば依頼Ｄ１については、依頼元のアプリケーションを識別するアプリＩＤ「Ｗｅｂｓｙｓ」と指定されたＵＲＬパス「／ｗｅｂｓｙｓ／ａａａ」「／ｗｅｂｓｙｓ／ｂｂｂ」が対応付けられてアプリＩＤ／ＵＲＬパス対応テーブルＴ２に登録され、アプリＩＤ「Ｗｅｂｓｙｓ」と指定されたポート識別子「ＨＴＴＰ」「ＨＴＴＰＳ」が対応付けられてアプリＩＤ／ポート識別子対応テーブルＴ３に登録される。

そして、個々の依頼Ｄ1〜Ｄ３につき、アプリＩＤ／ポート識別子対応テーブルＴ３への登録が完了した時点でポート識別子／ポート番号対応テーブルＴ１の参照を経由してポートがオープンされる。

このように、画像形成装置１の起動後に依頼のあったポートについてのみ登録を行い、動的にオープンするようにしているので、使われていないサービスに対応するポートが不用意にオープンされることがなくなり、不正なアクセスを低減させてセキュリティを向上させることができる。

図６はリクエスト受付時の処理手順を示すシーケンス図である。

図６において、ＨＴＴＰクライアント９からネットワークを経由してリクエストが行われると（ステップＳ１１）、ＮＣＳ５６のＨＴＴＰデーモン５６１がそのリクエストを受け付ける。

そして、ＨＴＴＰデーモン５６１のリクエスト処理部５６３はリクエストを受け付けたポート番号を認識した上でポート識別子／ポート番号対応テーブルＴ１を参照し、そのポート番号に対応するポート識別子を取得する（ステップＳ１２）。

次いで、ＨＴＴＰデーモン５６１のリクエスト処理部５６３はリクエストで指定されたＵＲＬパスを認識した上でアプリＩＤ／ＵＲＬパス対応テーブルＴ２を参照し、そのＵＲＬパスに対応するアプリＩＤを取得する（ステップＳ１３）。

次いで、ＨＴＴＰデーモン５６１のリクエスト処理部５６３は取得したアプリＩＤに基づき、アプリＩＤ／ポート識別子対応テーブルＴ３を参照し、そのアプリＩＤに対応するポート識別子を取得する（ステップＳ１４）。

そして、ステップＳ１２で取得したポート識別子とステップＳ１４で取得したポート識別子とを比較し、一致する場合にはＵＲＬパスで指定されるアプリケーションにリクエストをディスパッチし（ステップＳ１５）、一致しない場合にはＨＴＴＰクライアント９に対してエラーを返す（ステップＳ１６）。

図７は上記のリクエスト受付時のポートのチェックにおけるリクエストとテーブルの内容の関係を示す図である。

図７において、到来したリクエストＲ１がポート番号「４４３」、ＵＲＬパス「／ｗｅｂｓｙｓ／ａａａ」であったとすると、図６に示した処理手順により、リクエストＲ１のポート番号「４４３」からポート識別子／ポート番号対応テーブルＴ１の参照によりポート識別子「ＨＴＴＰＳ」が得られる。一方で、リクエストＲ１のＵＲＬパス「／ｗｅｂｓｙｓ／ａａａ」からアプリＩＤ／ＵＲＬパス対応テーブルＴ２の参照によりアプリＩＤ「Ｗｅｂｓｙｓ」が得られ、このアプリＩＤ「Ｗｅｂｓｙｓ」に基づきアプリＩＤ／ポート識別子対応テーブルＴ３の参照によりポート識別子「ＨＴＴＰ」「ＨＴＴＰＳ」が得られる。

ここで、両者が比較されることになるが、比較はリクエストのポート番号とＵＲＬパスとからそれぞれ求めたポート識別子に共通のものがあるか否かという観点で一致を見るため、ポート識別子「ＨＴＴＰＳ」が両者に存在するため一致すると判断され、アプリケーションへのディスパッチが行われる。

このように、アプリケーションが予め登録したポートからのリクエストしかディスパッチしないようにしているので、想定しないポートからのリクエストがアプリケーションに渡ることがなくなり、セキュリティの向上を図ることができる。

上記の実施例においては、ＨＴＴＰデーモン５６１について説明したが、ＦＴＰデーモン５６４（図３）等の他のプロトコルデーモンについても同様である。すなわち、プロトコルデーモン内にポート登録部、リクエスト処理部、アプリＩＤ／ＵＲＬパス対応テーブル、アプリＩＤ／ポート識別子対応テーブルを設けることにより、他のプロトコルにおいても、想定しないポートからのリクエストを防止し、使用しないポートの不用意なオープンを防止することができる。

本発明の一実施例に係る画像形成装置の機能構成を示すブロック図である。図１に示す画像形成装置のハードウェア構成を示すブロック図である。図１に示す画像形成装置のＷｅｂサービス機能に関する部分の機能構成を示すブロック図である。ポート登録の処理手順を示すシーケンス図である。ポート登録におけるアプリケーションからの依頼とテーブルに登録される内容の関係を示す図である。リクエスト受付時の処理手順を示すシーケンス図である。リクエスト受付時のポートのチェックにおけるリクエストとテーブルの内容の関係を示す図である。

符号の説明

１画像形成装置
２０Ｗｅｂアプリケーション
２５Ｗｅｂアプリケーション（Ｗｅｂｓｙｓ）
２６Ｗｅｂアプリケーション（ｗｅｂｄｏｃｂｏｘ）
５６ＮＣＳ
５６１ＨＴＴＰデーモン
５６２ポート登録部
５６３リクエスト処理部
Ｔ１ポート識別子／ポート番号対応テーブル
Ｔ２アプリＩＤ／ＵＲＬパス対応テーブル
Ｔ３アプリＩＤ／ポート識別子対応テーブル

Claims

複数のポートから入ってくるリクエストをプロトコルデーモンが受け付け、当該リクエストに含まれるアプリケーションを特定する情報に基づいてアプリケーションに処理のディスパッチを行うネットサービス機能を有する情報処理装置において、
上記リクエストを受け付けたときに上記アプリケーションに対応するポート識別子を取得して当該リクエストが入ってきたポート番号に対応するポート識別子と一致するか否かをチェックし、一致した場合にのみアプリケーションへのディスパッチを行うリクエスト処理部を上記プロトコルデーモン内に備えたことを特徴とするネットサービス機能を有する情報処理装置。
複数のポートから入ってくるリクエストをプロトコルデーモンが受け付け、当該リクエストに含まれるアプリケーションを特定する情報に基づいてアプリケーションに処理のディスパッチを行う情報処理装置のネットサービス提供方法において、
上記プロトコルデーモンが、上記リクエストを受け付けたときに上記アプリケーションに対応するポート識別子を取得して当該リクエストが入ってきたポート番号に対応するポート識別子と一致するか否かをチェックする手順と、
一致した場合にのみ、上記プロトコルデーモンが、アプリケーションへのディスパッチを行う手順とを備えたネットサービス提供方法。