JP2019133438A - 情報処理装置及びその制御方法、プログラム - Google Patents

Abstract

【課題】ネットワークの安定性を保ちつつ、待機モードを利用したシャットダウン後の高速起動を実現する。【解決手段】サーブレットとクライアントとの間の接続の状態は接続リストにより管理される。待機モードへの移行イベントがあるとＨＴＴＰサーバーは、接続リストを先頭から読み込んで着目し、着目サーブレットの状態を取得し、動作中であればエラーレスポンスをクライアントに返す（Ｓ５０４）。その後接続を切断し、接続リストから切断した接続のレコードを削除し（Ｓ５０５）、それをすべての接続について繰り返す。【選択図】図５

Description

本発明は、シャットダウン処理などを行う情報処理装置とその制御方法およびプログラムに関する。

近年、情報処理装置には、消費電力を抑えた待機モードを備えることが一般的になっている。待機モードは、いわゆるＤｅｅｐＳｌｅｅｐとも呼ばれる状態である。ＤｅｅｐＳｌｅｅｐ状態の情報処理装置は、情報処理装置内のＣＰＵクロックを停止させて、内部処理動作を止めることによって、消費電力を抑えている。情報処理装置は、ＣＰＵクロックを停止させているため、ＣＰＵを動作させることで、すぐにＤｅｅｐＳｌｅｅｐから通常状態に復帰できる。

この特徴に着目し、ＤｅｅｐＳｌｅｅｐへの遷移を仮想的な電源ＯＦＦとして利用し、次回起動を高速にする高速起動モードなどが実現されている。ＤｅｅｐＳｌｅｅｐに移行すると、情報処理装置の内部で動作するサーバー機能も停止されるため、ネットワーク通信も出来なくなる。ネットワーク通信の安定性を保つために、ＤｅｅｐＳｌｅｅｐに移行する前に、ネットワーク通信の終了を待ち、サーバー機能を停止させるようなことが行われている（特許文献１）。

特開２０１５−２１５８１４号公報

しかしながら、ネットワークの状態を考慮せず、ＤｅｅｐＳｌｅｅｐを利用した高速起動モードを実現させると、ネットワーク接続先のクライアントに影響を与えてしまうという課題がある。クライアントはサーバーの動作を検知できないため、突然サーバーが動作しなくなると、クライアントはタイムアウト等によってサーバーの状態を判定するしかない。

また、ＤｅｅｐＳｌｅｅｐに移行する前に、シャットダウンシーケンスに移行し、サーバー機能を停止させることも考えられるが、その場合だとＤｅｅｐＳｌｅｅｐ移行までに時間が掛かってしまう。さらに、サーバー機能の再起動に時間を要するため、次回起動の高速化を実現できないという課題がある。

本発明は上記従来例に鑑みて成されたもので、ネットワークの安定性を保ちつつ、待機モードを利用したシャットダウン後の高速起動を実現することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。

本発明の一側面によれば、本発明は動作を停止した待機モードへの移行が可能な情報処理装置であって、
クライアントとサーバーとの間の接続ごとに前記サーバーの動作状態を管理する管理手段と、
前記待機モードへの移行通知に応じて、前記接続のそれぞれについて前記サーバーの動作状態を判定し、処理中であれば当該接続のクライアントに対してエラーを送信し、その後に当該接続を切断する接続管理手段と
を有することを特徴とする。

本発明によれば、ネットワークの安定性を保ちつつ、待機モードを利用したシャットダウン後の高速起動を実現することができる。

情報処理装置のハードウェア構成の一例を示した図 情報処理装置のソフトウェア構成の一例を示した図 情報処理装置の内部で管理するネットワーク接続先のリスト情報の一例を示した図 待機モード移行時の情報処理装置の動作の一例について示した図 本提案の実施形態を説明するフローチャート 本提案の実施形態を説明するフローチャート 本提案の実施形態を説明する図 第二実施形態を説明するフローチャート 第三実施形態を説明するフローチャート

［第一実施形態］
本実施形態は、情報処理装置が、ＣＰＵの動作を停止した待機モードに移行する際のサーバーの処理について説明するものである。本実施形態のシステム及びハードウェア構成の一例を、図１を用いて説明する。なお待機モードではＣＰＵの動作を停止するだけでもよいが、ＣＰＵおよびＣＰＵ周辺の回路への電源の供給を停めてもよい。

●システム構成
本システムは、画像形成装置１００と情報処理装置１２０がネットワーク１１０に接続されており、相互の通信が可能である。なお画像形成装置１００は、プリンタやスキャナといったデバイスを有する情報処理装置とみなすこともできるため、以下の説明では情報処理装置と呼ぶこともある。情報処理装置１００には、ＣＰＵ１０１と、ＲＡＭ１０２を備えており、プログラムはＲＡＭ１０２に展開され、ＣＰＵ１０１によって実行されて本実施形態に係る発明が実現される。またそのプログラムやデータはＲＯＭ１０３や外部記憶装置１０４に保存されている。或いはプログラムはＲＯＭ３に、該プログラムが使用するデータは外部記憶装置１０４に保存されていてもよい。

また、情報処理装置１００には、ユーザーインターフェースとして、操作を受け付けるＵＩパネル１０５や、ネットワーク制御部１０６から構成されている。各モジュールは、バス１０７によって相互に接続されており、データのやり取りを行うことが可能である。また、情報処理装置１００にはユーザーが操作可能な電源スイッチ１０８を備えている。情報処理装置１００はネットワーク制御部１０６によって、ネットワーク１１０に接続されており、情報処理装置１００がサーバーとして動作する場合のクライアントとして情報処理装置１２０がある。さらに情報処理装置１００は前述したように画像形成装置であり、プリンタデバイスやスキャナデバイスを備えた多機能周辺機器（ＭＦＰ）であってもよい。

●ソフトウェアの構成
図２は本実施例の情報処理装置１００のソフトウェアの構成の一例を示す図である。情報処理装置のハードウェアを制御するＢＩＯＳ２０２上に、ＯＳ２０３が実装されている。ＯＳ２０３上では、情報処理装置１００の電源を管理する電源管理モジュール２０８や、情報処理装置１００における内部のイベントを制御するイベント管理モジュール２０９等が動作している。他にも、ＯＳ２０３上では、ＨＴＴＰサーバー２０４が動作し、情報処理装置に搭載されているＳｅｒｖｌｅｔ（サーブレット）プログラムの管理を行っている。

ＨＴＴＰサーバー２０４は、ＯＳ２０３が提供するネットワークＡＰＩを使用し、情報処理装置１００のネットワーク制御部１０７を通じて外部と通信を行っている。

Ｓｅｒｖｌｅｔ２１１、Ｓｅｒｖｌｅｔ２１２は、ＨＴＴＰサーバー２０４を拡張するプログラムであり、ＨＴＴＰサーバー２０４の呼び出しにより動作する。ＨＴＴＰサーバー２０４上では、０個以上のＳｅｒｖｌｅｔが動作していることとなる。サーブレットはＨＴＴＰサーバーの機能を拡張することで、たとえばクライアントの要求に応じた付加的なサービスを提供するプログラムであり、ＨＴＴＰサーバー２０４と併せてサーバーと呼んでもよい。

ＨＴＴＰサーバー２０４は、リクエスト受信部２０５によって外部からのＨＴＴＰリクエストを受信すると、Ｓｅｒｖｌｅｔ管理部２０６により、受信したリクエストの内容を解析する。そして、リクエストの解析結果に応じて適切なＳｅｒｖｌｅｔを選択し、選択したＳｅｒｖｌｅｔを呼び出す。呼び出されたＳｅｒｖｌｅｔ２１１、２１２は、Ｓｅｒｖｌｅｔ管理部２０６よりＨＴＴＰリクエストのデータを受け取ると、ＨＴＴＰレスポンスデータを生成し、Ｓｅｒｖｌｅｔ管理部２０６に返す。Ｓｅｒｖｌｅｔ管理部２０６はＳｅｒｖｌｅｔからのＨＴＴＰレスポンスを、レスポンス送信部２０７を通して、リクエスト元へ返送する。ＨＴＴＰサーバー２０４は、接続しているＳｅｒｖｌｅｔとクライアントの情報を接続リストに記憶しており、リクエストの受信やレスポンスの返送の状態を記憶する。接続リストにより、たとえばひとつのクライアントとひとつのサーブレットとの間で交換される１以上のＨＴＴＰリクエストとそれに対するＨＴＴＰレスポンスの組をひとまとまりのセッションとして管理できる。ＨＴＴＰサーバー２０４は、たとえば、クライアントから新規の接続を介してＨＴＴＰリクエストがあると、接続リスト３００にそのＨＴＴＰリクエストのための接続を登録し、その接続を解放してよいことを示すＨＴＴＰリクエストがあると接続を解放して該当する項目を接続リストから消去する。接続リスト３００は、たとえばＨＴＴＰサーバー２０４により保持管理され、特にサーブレット管理部２０６により管理される。

●接続リスト
接続リストの一例を図３に示す。接続リスト３００には、接続しているクライアントや該クライアントと接続しているＳｅｒｖｌｅｔ等の情報を保持する。カラム３０１は、クライアントと接続しているＳｅｒｖｌｅｔの名称を示し、カラム３０２は接続しているクライアントの情報として、クライアントのＩＰアドレスやマシン名などが保持されている。カラム３０３は、クライアントとサーブレットログとして、最終的なやり取りの時間が保持されている。カラム３０４は、各接続の状態を記載しており、例えば「Ｗａｉｔ Ｒｅｑｕｅｓｔ」のようなステータス３１１は、「ＡｐｐＡＢＣ」Ｓｅｒｖｌｅｔが、クライアントからのリクエスト待ちであることを示している。ステータス３１２の「Ｉｎ Ｐｒｏｇｒｅｓｓ」は「ＡｐｐＯＰＱ」Ｓｅｒｖｌｅｔが何かしらの処理を行い、レスポンスを準備していることを示す。これらのステータスはＳｅｒｖｌｅｔ管理部２０６によって管理され、Ｓｅｒｖｌｅｔを呼び出した際に更新される。すなわちステータス３１１はサーブレットの動作状態を示しているということもできる。また接続リスト３００は、サーブレットとクライアントとの接続を用いたＨＴＴＰの要求／応答の状態を管理するためのテーブルなので、管理テーブルと呼ぶこともある。なお図３ではサーブレットもクライアントも重複していないが、重複していることもあり得る。たとえば一つのサーブレットが、２つの相異なるクライアントと接続している接続状態が接続テーブル３００に登録されていることもあってよい。

このように、接続リスト３００は、ＨＴＴＰサーバー２０４とクライアント１２０との間の接続を示し、そしてその接続が確立されてから解消されるまでの間に行われるＨＴＴＰのセッションの状態を示しているということもできる。

●情報処理装置１００の動作
情報処理装置１００が電源スイッチ１０８の変更を機に待機モードに入る際の内部モジュールの動作について図４を用いて説明する。

ユーザーにより電源スイッチ１０８がオフ状態にされる（４０１）と、電源スイッチ１０８の状態の変更は電源管理モジュール２０８によって検知される。そして、電源管理モジュール２０８は、他モジュールへの問い合わせを行い待機モードへの移行の可否を判定する（不図示）。そして、移行可能と判定した場合、イベント管理モジュール２０９に対して、待機モードへ移行する通知を行う（４０２）。電源管理モジュール２０８から待機モードへの移行通知を受けたイベント管理モジュール２０９は、リスナー登録されている各モジュールに対し、待機モード移行のイベントを発行する（４０３）。図４の例では、イベント管理モジュール２０９は待機モード移行のイベントをＨＴＴＰサーバー２０４、サーブレット２１１，２１２に対して発行している。ここで、電源管理モジュール２０８は、イベント管理モジュール２０９へ待機モードへの移行を通知すると、待機モードへの移行処理を開始する。

一方、待機モード移行のイベントを受信したＨＴＴＰサーバー２０４は、イベントを受信してから待機モードへの移行処理を行うことになる。このため、情報処理装置内もモジュール間では、処理の開始にタイムラグが生じることとなる。そして、実際に情報処理装置１００が待機モードに移行すると（４０４）、内部では電力消費を抑えるため、ＣＰＵが停止した状態となる。待機モードに移行すると、ＣＰＵが停止しているため、ＨＴＴＰサーバー２０４が管理するＳｅｒｖｌｅｔの動作も停止する。仮にＨＴＴＰサーバー２０４が、待機モードへの移行イベントを受信しても何の処理も行わなければ、停止したＳｅｒｖｌｅｔにリクエストを投げてレスポンスを待機していたクライアントはレスポンスを受信できなくなる。そこで本実施形態では、クライアントに対してサーブレットが停止することを通知した上でＨＴＴＰサーバー２０４とクライアントとの間の接続を解除する。この待機モードへの移行手順については後で図５等を参照して説明する。

情報処理装置１００が待機モードから復帰する場合の一例として、図４ではユーザーからの電源スイッチ１０８がオン状態にされる（４１１）ことを例にする。電源スイッチ１０８等の状態の変更は、電源管理モジュール２０８によって検知される。電源スイッチ１０８がオンにされたことが検知されると、それに応じて停止していたＣＰＵの動作が再開され、待機モードからの復帰が始まる（４１２）。電源管理モジュール２０８は待機モードからの復帰処理を開始し、イベント管理モジュール２０９に対して待機モードからの復帰を通知する（４１３）。電源管理モジュール２０８の復帰処理の開始によりＣＰＵが動作することで、ＨＴＴＰサーバー２０４の動作が開始され、Ｓｅｒｖｌｅｔも動作可能になる。

イベント管理モジュール２０９は、電源管理モジュール２０８から待機モードからの復帰の通知を受けると、リスナー登録されている各モジュールに対して、待機モードからの復帰イベントを通知する（４１４）。ＨＴＴＰサーバーのような復帰イベントを受信するモジュールは、復帰イベントを受信してから待機モードからの復帰処理を開始する。

●接続リストの追加・更新処理
図６に、ＨＴＴＰサーバー２０４がクライアントからＨＴＴＰリクエスト受けた際の、接続リスト３００に対する処理を示す。ＨＴＴＰサーバー２０４は、ＨＴＴＰリクエストに応じて指定されたコンテンツを生成したり、あるいはレスポンスを送信するといった実質的な処理を行うが、本実施形態ではその実質的な処理の部分はどのようなものでもよいことから、それについては省略している。なお図６においては、接続たとえばＴＣＰコネクションは既に確立済みであることを前提として記載している。

ＨＴＴＰサーバー２０４は、ＨＴＴＰリクエストを受信すると（Ｓ６０１）、そのリクエストが新規の接続上でのリクエストか、既存の接続上のリクエストかを判定する（Ｓ６０２）。新規の接続上でのリクエストとは、たとえばＨＴＴＰのセッションの最初のＨＴＴＰリクエストなどでよい。ステップＳ６０２では、たとえば接続リスト３００を参照し、既に登録された接続であれば既存、登録されていなければ新規と判定することで実現できる。新規の接続上でのリクエストである場合は、ＨＴＴＰサーバー２０４は、その接続に対応するＳｅｒｖｌｅｔの情報とクライアントの情報とを取得し（Ｓ６０３）、接続リスト３００の末尾に新たな接続に関する情報を追加する（Ｓ６０４）。追加された時にはＨＴＴＰリクエストを受信しているので、状態３０４は処理中（Ｉｎ Ｐｒｏｇｒｅｓｓ）とする。

一方、既存の接続上のリクエストであった場合は、リクエスト先のＳｅｒｖｌｅｔを特定し（Ｓ６０５）、特定したＳｅｒｖｌｅｔのＡＰＩを呼び出す。そして、その接続に該当する接続リスト３００の履歴３０３とステータス３０４を更新する（Ｓ６０６）。図３の接続先リストを例にすると、「ＡｐｐＯＰＱ」Ｓｅｒｖｌｅｔにリクエストが来たことにより、そのステータス３０４が「Ｗａｉｔ Ｒｅｓｐｏｎｓｅ」から「Ｉｎ Ｐｒｏｇｒｅｓｓ」に更新されることになる。逆に、ＨＴＴＰサーバー２０４がレスポンスをクライアントに送信すると、そのステータス３０４が「Ｉｎ Ｐｒｏｇｒｅｓｓ」から「Ｗａｉｔ Ｒｅｓｐｏｎｓｅ」に更新される。このようにして接続リスト３００に新たな接続が追加され、またその状態が更新される。

●ＨＴＴＰサーバーの待機モードへの移行処理
次に、前述した図４のステップ４０４における待機モードへの移行処理について説明する。本実施形態の一例について、図５のフローチャートを用いて説明する。本フローチャートは、ＨＴＴＰサーバー２０４により実行され、ＨＴＴＰサーバー２０４が待機モード移行のイベントを受信するところから始まる。図５の手順は、待機モードへの移行時の接続管理を提供する。

ＨＴＴＰサーバー２０４は、イベント管理モジュール２０９から待機モード移行のイベントを受信すると、Ｓｅｒｖｌｅｔ管理部２０６にて保持されている接続リスト３００を読み込む（Ｓ５０１）。そして、接続リスト３００の先頭から順に接続に着目し、接続しているＳｅｒｖｌｅｔの状態（あるいは接続状態ともいえる）取得し（Ｓ５０２）、該Ｓｅｒｖｌｅｔが動作中であるか否かを判定する（Ｓ５０３）。この判定は、Ｓｅｒｖｌｅｔ管理部２０６からＳｅｒｖｌｅｔのインターフェースに対して呼び出しを行う状態を基とする。Ｓｅｒｖｌｅｔ管理部２０６がＳｅｒｖｌｅｔのＡＰＩをコールし、Ｓｅｒｖｌｅｔからのレスポンスを待っている状態であれば、Ｓｅｒｖｌｅｔが動作している状況であると判別する。Ｓｅｒｖｌｅｔ管理部２０６がＳｅｒｖｌｅｔのＡＰＩ呼び出しを行っていない状況であれば、Ｓｅｒｖｌｅｔは動作していない状況であると判別する。具体的には、たとえば、ＨＴＴＰサーバー２０４が接続リスト３００中の着目接続のサーブレットのステータス３０４を参照し、処理中（Ｉｎ Ｐｒｏｇｒｅｓｓ３１２）であれば、当該サーブレットは動作中と判定し、待機中（Ｗａｉｔ Ｒｅｑｕｅｓｔ３１１）であれば、当該サーブレットは動作していないと判定してもよい。

Ｓｅｒｖｌｅｔが動作している状況であると判別するとステップＳ５０４へ進み、Ｓｅｒｖｌｅｔが動作していない状況であると判別した場合はステップＳ５０５へ進む。ステップＳ５０４では、Ｓｅｒｖｌｅｔが動作している判別した状況では、レスポンス送信部２０７がエラーレスポンス生成し、接続リスト３００に記載のクライアントに対して、エラーレスポンスを送信する。たとえば、本フローチャートの状況下では、情報処理装置１００が待機モードに移行するため、ＨＴＴＰサーバーとして５０３（Ｓｅｒｖｉｃｅ Ｕｎａｖａｉｌａｂｌｅ）エラーレスポンスを返すことが考えられる。ＨＴＴＰエラーについては、５０３エラーに限定するものではなく、それ以外のエラーであっても構わない。

ＨＴＴＰサーバー２０４は、エラーレスポンスを送信すると、ステップＳ５０５へ進む。そして、接続リスト３００の記載にクライアントとの接続（すなわち着目している接続）に対して、切断処理を行い（Ｓ５０５）、接続リストから該接続に関係する情報を削除する（Ｓ５０６）。そして、接続リスト３００にまだ接続（すなわちＳｅｒｖｌｅｔないしクライアント）が残っているか判定し（Ｓ５０７）、残っている場合は、ステップＳ５０２に戻り接続リストの先頭に着目して処理を継続する。接続リスト３００に接続（あるいはＳｅｒｖｌｅｔ）が残っていなければ、本フローチャートを終了する。

このように、待機モードに入る前に、サーブレットに接続しているクライアントへエラーレスポンスｓを送信することで、クライアントはエラーレスポンスを受信することができるので、タイムアウトを待たず、情報処理装置の状態を知ることが出来る。それにより、接続するクライアントや送受信中のデータに与える影響を少なくすることが可能となる。

［第二実施形態］
第二の実施形態について、図８を用いて説明する。本フローチャートは、第一実施形態の図６の手順に代えてＨＴＴＰサーバー２０４およびＯＳ２０３、そのうち特にＴＣＰ／ＩＰスタックのＴＣＰレイヤにより実行される。図８の手順は、ＯＳ２０３からの通信の通知、すなわちクライアントからのアクセスを検知することで開始される。クライアントからのアクセスには、ＴＣＰコネクション（すなわち接続）の確立の要求やＨＴＴＰリクエストが含まれる。

ＨＴＴＰサーバー２０４は、ＯＳ２０３からネットワーク通信の通知を受信すると（Ｓ８０１）、該ネットワーク通信が新規の接続要求か、既存の接続からのリクエストか否かを判定する（Ｓ８０２）。ステップＳ６０２は、たとえば接続リストを参照し、既に登録された接続であれば既存、登録されていなければ新規と判定することで実現できる。新規の接続要求である場合は、ＨＴＴＰサーバー２０４は、該接続に対応するＳｅｒｖｌｅｔの情報と、該接続のクライアントの情報を取得し（Ｓ８０３）、接続を確立させる（Ｓ８０４）。既存の接続からのリクエストであった場合は、リクエスト先のＳｅｒｖｌｅｔを特定し（Ｓ８０９）、該特定したＳｅｒｖｌｅｔのＡＰＩを呼び出す。そして、該接続に該当する接続先リストの履歴３０３とステータス３０４を更新する（Ｓ８１０）。図７（ａ）の接続先リストを例にすると、「ＡｐｐＧＨＩ」Ｓｅｒｖｌｅｔにリクエストが来たことにより、ステータス７０２が「Ｉｎ Ｐｒｏｇｒｅｓｓ」に更新されることになる。

新規の接続要求として確立させた接続に対し、ＨＴＴＰサーバー２０４は、情報処理装置１００の状態を判定するために、イベント管理モジュール２０９から待機モード移行のイベントを受けているか否かを判定する（Ｓ８０５）。ここでイベントを受信していなければ、情報処理装置は通常の状態であると判定し、新規の接続要求を接続リスト３００に追加する（Ｓ８１１）。

待機モード移行イベントを受信している場合、図４の待機モード移行イベントを受信し（４０３）、実際の待機モードへ移行（４０４）するまでに間に来た接続要求であると判定できる。情報処理装置１００はこの後待機モードに移行することになり、待機モードに移行すると、接続しているクライアントとリクエスト／レスポンスのやり取りが行えず、クライアントに影響を与えてしまうことになる。新規の接続は関しては、接続が確立したのちに、接続しているクライアントから、高い確率でリクエストが来ることが想定される。それゆえ、該新規の接続に関しては、図７（ａ）のレコード７０１のように、接続先リスト３００の先頭に新たな接続に対応するレコードを挿入し（Ｓ８０６）、接続先クライアントに直ぐにエラーレスポンスを返す（Ｓ８０７）、処理を行う。そして、該接続の切断処理を行い（Ｓ８０８）、本フローチャートを終了する。Ｓ８０６で挿入したレコードは図５の手順により削除される。

これにより、クライアントからのリクエスト要求が、高い確率でくると考えられる接続に対して、すぐにエラーレスポンスを返すことが可能となる。クライアントにタイムアウト処理を行わせることなく、ネットワークの切断処理を進めることが可能となる。

［第二実施形態の変形例］
本実施形態の考え方は、既存の接続先リストに対しても同様に考えることもできる。例えば、既存の接続の切断には、幾分かの時間が掛かるため、接続先リストに記載の接続が膨大である場合には、情報処理装置１００が実際に待機モードに入るまでに全ての接続が切断できるとは限らなくなる。

そういった場合に、既存の接続先の中から、優先度をつけて、切断する順番を変更することにより、クライアントへの影響を少なくすることが考えられる。例えば、待機モードに入ることでＣＰＵ停止するため、Ｓｅｒｖｌｅｔが処理中の接続、つまりクライアントがレスポンス待ちの状態であるような場合は、待機モードへの移行がクライアントへ大きな影響を与えると考えられる。さらに、「Ｗａｉｔ Ｒｅｑｕｅｓｔ」のステータスである接続の中で、前回の通信からの時間が経過している接続は、使用されない接続が維持されているＫｅｅｐＡｌｉｖｅの状態であると想定できる。このような接続ではクライアントからリクエストが来る頻度は低いことから、ＣＰＵ停止によって切断されるようなことがあっても、クライアントへの影響度は少ない想定できる。この想定のもとで、優先度を考慮し、接続先リストの順序を変更した例を図７（ｂ）に示す。図７（ｂ）では、状態３０４をキーとし、処理中（Ｉｎ Ｐｒｏｇｒｅｓｓ）を接続リスト３００の先に処理される側（例えば上）に再配置（あるいはソート）している。このように、接続先リストの順序を変えて、切断する順番を変更することで、接続するクライアントへの影響を少なくすることが可能となる。

［第三実施形態］
図９に第三実施形態のＴＣＰレイヤの処理の一例を示す。本実施形態は、第一実施形態に図9の手順が付加される形で実施される。ＯＳ２０３のＴＣＰレイヤでは、ＴＣＰ接続の要求があると（たとえばＡＣＫパケットを受信すると）、図９の手順を実行する。まず要求された接続に関する情報を取得し（Ｓ９０１）、接続を確立する（Ｓ９０２）。そしてＨＴＴＰサーバ２０４が待機モード移行イベントを受信したか判定する（Ｓ９０３）。受信していればエラーを応答して（Ｓ９０４）、接続を切断する（Ｓ９０５）。この場合には、接続リスト３００に新たなレコードが追加されることはない。ＨＴＴＰサーバー２０４は第一実施形態と同様に動作する。これにより接続が確立された状態であり、なおかつその接続でＨＴＴＰリクエストが送られていない場合には、ＨＴＴＰレベルでその接続を切断することで、クライアントへの影響を押さえることができる。なお、ＴＣＰコネクションの設定時に、たとえば最初のクライアントからＳＹＮＣパケットをサーバーが受信した時点において待機モード移行イベントが受信しているか判定し、受信していればＳＹＮＣ／ＡＣＫパケットに代えて例えばＮＡＣＫパケットをクライアントに応答してもよい。このようにすることで、待機モードへの移行直前のコネクションの確立を防ぐことができる。待機モード移行イベントはＨＴＴＰサーバー２０４に対して送信されるので、待機モード移行イベントを受信したか否かはＨＴＴＰサーバ２０４に問い合わせることになる。

［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１００ 情報処理装置、２０４ ＨＴＴＰサーバー、２０６ Ｓｅｒｖｌｅｔ管理部、２０８ 電源管理モジュール、２０９ イベント管理モジュール、３００ 接続先リスト

Claims (11)

1. 動作を停止した待機モードへの移行が可能な情報処理装置であって、
   クライアントとサーバーとの間の接続ごとに前記サーバーの動作状態を管理する管理手段と、
   前記待機モードへの移行通知に応じて、前記接続のそれぞれについて前記サーバーの動作状態を判定し、処理中であれば当該接続のクライアントに対してエラーを送信し、その後に当該接続を切断する接続管理手段と
   を有することを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記接続管理手段は、
   新たな接続が確立された場合に確立した接続の情報を接続リストに追加し、
   前記クライアントからの要求に応じて処理を行っている場合には前記サーバーの動作状態を処理中に設定し、
   前記クライアントからの要求に応じて応答を送信した場合には前記サーバーの動作状態を待機中に設定し、
   前記接続を切断した場合には当該接続の情報を前記接続リストから削除する
   ことを特徴とする情報処理装置。
3. 請求項１または２に記載の情報処理装置であって、
   前記クライアントからのアクセスが新規の接続要求である場合に、前記接続要求に対して新規の接続を確立する手段と、
   前記待機モードへの移行通知がある場合には、前記新規の接続の情報を前記接続リストの先頭に追加し、前記新規の接続を用いてエラーレスポンスを送信し、その後で前記新規の接続を切断する手段とを更に有し、
   前記接続管理手段は、前記接続リストの先頭から前記サーバーの動作状態を判定することを特徴とする情報処理装置。
4. 請求項１または２に記載の情報処理装置であって、
   前記クライアントからのアクセスが新規の接続要求である場合に、前記接続要求に対して新規の接続を確立する手段と、
   前記待機モードへの移行通知がある場合には、前記新規の接続を用いてエラーレスポンスを送信し、その後で前記新規の接続を切断する手段と
   を更に有することを特徴とする情報処理装置。
5. 請求項１乃至４のいずれか一項に記載の情報処理装置であって、
   前記サーバーは、ＨＴＴＰサーバーのサーブレットを含み、
   前記接続は前記サーブレットと前記クライアントとの間の接続であることを特徴とする情報処理装置。
6. 請求項１乃至５のいずれか一項に記載の情報処理装置であって、
   プリンタとスキャナとを更に有することを特徴とする情報処理装置。
7. 動作を停止した待機モードへの移行が可能な情報処理装置の制御方法であって、
   クライアントとサーバーとの間の接続ごとに前記サーバーの動作状態を管理する管理手段を有し、
   前記待機モードへの移行通知に応じて、前記接続のそれぞれについて前記サーバーの動作状態を判定し、処理中であれば当該接続のクライアントに対してエラーを送信し、その後に当該接続を切断する
   ことを特徴とする情報処理装置の制御方法。
8. 請求項７に記載の情報処理装置の制御方法であって、さらに、
   新たな接続が確立された場合に確立した接続の情報を接続リストに追加し、
   前記クライアントからの要求に応じて処理を行っている場合には前記サーバーの動作状態を処理中に設定し、
   前記クライアントからの要求に応じて応答を送信した場合には前記サーバーの動作状態を待機中に設定し、
   前記接続を切断した場合には当該接続の情報を前記接続リストから削除する
   ことを特徴とする情報処理装置の制御方法。
9. 請求項７または８に記載の情報処理装置の制御方法であって、さらに、
   前記クライアントからのアクセスが新規の接続要求である場合に、前記接続要求に対して新規の接続を確立し、
   前記待機モードへの移行通知がある場合には、前記新規の接続の情報を前記接続リストの先頭に追加し、前記新規の接続を用いてエラーレスポンスを送信し、その後で前記新規の接続を切断し、
   前記サーバーの動作状態の判定では、前記接続リストの先頭から前記サーバーの動作状態を判定することを特徴とする情報処理装置の制御方法。
10. 請求項７または８に記載の情報処理装置の制御方法であって、さらに、
    前記クライアントからのアクセスが新規の接続要求である場合に、前記接続要求に対して新規の接続を確立し、
    前記待機モードへの移行通知がある場合には、前記新規の接続を用いてエラーレスポンスを送信し、その後で前記新規の接続を切断する
    ことを特徴とする情報処理装置の制御方法。
11. 動作を停止した待機モードへの移行が可能なコンピュータを、
    クライアントとサーバーとの間の接続ごとに前記サーバーの動作状態を管理する管理手段と、
    前記待機モードへの移行通知に応じて、前記接続のそれぞれについて前記サーバーの動作状態を判定し、処理中であれば当該接続のクライアントに対してエラーを送信し、その後に当該接続を切断する接続管理手段と
    して機能させるためのプログラム。

Images