JP2001223743A

JP2001223743A - 遠隔復旧機能を有する通信装置および通信方法並びに記録媒体

Info

Publication number: JP2001223743A
Application number: JP2000030955A
Authority: JP
Inventors: Kinya Takahashi; 欣也高橋
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2000-02-08
Filing date: 2000-02-08
Publication date: 2001-08-17

Abstract

(57)【要約】【課題】障害が発生していると判断される機器が遠隔
に位置している場合であっても、他のホストから復旧を
可能にする。【解決手段】ネットワーク機能再起動用の特殊なリセ
ットパケットを予め定義しておき、パケット監視部２１
２が、物理的通信媒体により近い部位のプログラムでそ
のリセットパケットを検知し、そのリセットパケットを
検知したらネットワーク・プロトコル・スタックを再起
動する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、遠隔復旧機能を有
する通信装置および通信方法並びに記録媒体に関し、特
にネットワーク上に置かれた通信機器の障害回復技術に
関する。

【０００２】

【従来の技術】図１１は、従来の一般的なネットワーク
機器の構成を示す。クライアントホスト１１０２や１１
０３は、ネットワーク１１００を介して連結するサーバ
・ホスト１１０１に要求して何らかのサービスを受ける
ことができる。サービスそのものを提供するのがサーバ
・ホスト１１０１のサーバプログラム１１０４である。
また、サーバ・ホスト１１０１には、ネットワーク１１
００を介してサービスをクライアントホスト１１０２、
１１０３へ提供するためのデータ通信のためにネットワ
ーク・プロトコル・スタック１１０５が存在する。ネッ
トワーク・プロトコル・スタック１１０５は、ネットワ
ーク層ごとのプロトコルを実現したプログラムの集合で
ある。例えば、ＴＣＰ／ＩＰプロトコルでは、ＵＤＰ
（ユーザ・データグラム・プロトコル）１１０６、ＴＣ
Ｐ（トランスミッション・コントロール・プロトコル）
１１０７などのトランスポート層のプログラム、および
ネットワーク層であるＩＰ（インターネット・プロトコ
ル）プログラム１１０８などから構成される。

【０００３】また、サーバ・ホスト１１０１には、物理
的な通信線にアクセスするために、ネットワーク・デバ
イス１１１０と、それを動作させるネットワーク・ドラ
イバ１１０９がある。これらは、どのような種類のネッ
トワークを利用するかによって異なり、例えばイーサネ
ットを利用する場合には、イーサネットカードやイーサ
ネット・ドライバが必要になる。

【０００４】従来、このようなネットワーク通信機器に
おいて、何らかの原因でネットワーク機能に障害が発生
して、ネットワーク機能が動作不能になった場合には、
障害が起きている機器自身の機械的なスイッチを用い
て、機器を再起動するという対処をとるのが一般的であ
る。

【０００５】

【発明が解決しようとする課題】しかしながら、上記の
サーバ・ホスト１１０１が管理者と距離的に離れた位置
に設置されている場合には、通信不能の障害が検知され
てから、すぐには復旧できないという解決すべき課題が
ある。

【０００６】特に、サーバ・ホスト１１０１が組み込み
機器の専用サーバなどでは、操作者が容易に近づけない
場所に設置される場合も考えられ、その場合の通信不能
の障害が検知されてから、すぐには復旧できないという
課題は顕著である。

【０００７】本発明の目的は、上述のような課題を解決
すべく、障害が発生していると判断される機器が遠隔に
位置している場合であっても、他のホストから復旧を可
能にすることにある。

【０００８】

【課題を解決するための手段】上記目的を達成するた
め、請求項１の遠隔復旧機能を有する通信装置の発明
は、復旧を指示するデータを送信する送信手段と、前記
データを受信する受信手段と、該受信手段が受信した受
信データの特定の部分を通信媒体に近い受信処理におい
て監視することで、当該受信データが前記復旧を指示す
るデータか否かを判定する判定手段と、前記受信データ
は前記復旧を指示するデータであるとの前記判定手段の
判定結果に応じて通信装置の再起動を実行する再起動実
行手段とを有することを特徴とする。

【０００９】ここで、前記送信手段は、常時、一定間隔
で正常な通信が可能か否かを検査する検査プログラムを
実行し、その際送ったテストデータが正常に返ってこな
い時に前記復旧を指示するデータを送信することを特徴
とすることができる。

【００１０】また、前記再起動実行手段は、通信装置の
再起動を実行する際に、ネットワーク・プロトコル・ス
タックの停止処理をする手段と、その後に該ネットワー
ク・プロトコル・スタックの起動処理をする手段とを含
むことを特徴とすることができる。

【００１１】また、前記再起動実行手段は、通信に係わ
る部分を再起動する手段と、オペレーション・システム
を含めた機器全体を再起動する手段とを含むことを特徴
とすることができる。

【００１２】また、前記復旧を指示するデータは、ＵＤ
Ｐパケットを利用した特殊パケットであり、ＵＤＰポー
ト番号がある決められた値になっているものを機器をリ
セットするためのパケットとして予め定義されることを
特徴とすることができる。

【００１３】また、前記判定手段は、さらに前記復旧を
指示するデータが機器リセットを許可されたホストを表
わす特定のＩＰアドレスからきたデータか否かを判定
し、前記再起動実行手段は、前記復旧を指示するデータ
が前記特定のＩＰアドレスからきたデータであるとの前
記判定手段の判定結果に応じて、通信装置の再起動を実
行することを特徴とすることができる。

【００１４】上記目的を達成するため、請求項７の通信
方法の発明は、復旧を指示するデータを送信する送信ス
テップと、前記データを受信する受信ステップと、該受
信ステップが受信した受信データの特定の部分を通信媒
体に近い受信処理において監視することで、当該受信デ
ータが前記復旧を指示するデータか否かを判定する判定
ステップと、前記受信データは前記復旧を指示するデー
タであるとの前記判定ステップの判定結果に応じて通信
装置の再起動を実行する再起動実行ステップとを有する
ことを特徴とする。

【００１５】上記目的を達成するため、請求項１３の記
録媒体の発明は、コンピュータにより通信装置を遠隔復
旧するためのプログラムを記録した記録媒体において、
該プログラムはコンピュータに対し、受信手段が受信し
た受信データの特定の部分を通信媒体に近い受信処理に
おいて監視させることで、当該受信データが復旧を指示
するデータか否かを判定させ、該復旧を指示するデータ
であるとの判定結果に応じて通信装置の再起動を実行さ
せることを特徴とする。

【００１６】（作用）本発明では、ネットワーク機能再
起動用の特殊パケットを定義し、物理的通信媒体により
近い部位のプログラムでその特殊パケットを検知し、そ
の検知に基づいてネットワーク機能を再起動するように
したので、障害が発生していると判断される機器が遠隔
に位置していても、他のホストから復旧することができ
る。

【００１７】

【発明の実施の形態】以下、図面を参照して本発明の実
施の形態を詳細に説明する。

【００１８】（第１の実施形態）図１は本発明の第１の
実施形態におけるネットワーク機器のブロック構成を示
す。本実施形態においては、ＴＣＰ／ＩＰによるネット
ワークでイーサネット（登録商標）を利用するものとす
る。ここで、１０１はＣＰＵ（中央演算処理ユニッ
ト）、１０２はＲＯＭ（リードオンリメモリ）、１０３
はＲＡＭ（ランダムアクセスメモリ）、１０４は通信デ
バイス、１０５はバス、１０６は通信線である。ＲＯＭ
１０２にはＣＰＵ１０１が使用する主にプログラムを格
納するが、それには、ＯＳ（オペレーション・システ
ム）１１０、ネットワーク・デバイス・ドライバ１０
９、ネットワーク・プロトコル・スタック１０８、アプ
リケーション・プログラム１０７などが含まれる。

【００１９】ＲＡＭ１０３内の主な領域を説明する。Ｓ
ＩＰ（ストアＩＰ）１１１は、このホストのＩＰ（イン
タネット・プロトコル）アドレスを格納している。この
ＩＰアドレスは通常は他の不揮発性のメモリやディスク
などに保存されており、起動時にＳＩＰ１１１にロード
される。

【００２０】ＲＳＴ＿ＰＯＲＴ（リカバリ・ポート）１
１２には、再起動を指示するためのパケットのポート番
号を格納している。このポート番号は、再起動を指示す
る相手ホストとの取り決めで予め適当な値に設定してお
く。

【００２１】ＲＳＴ＿ＤＩＰ（リカバリ・ダイナミック
ＩＰ）１１３は再起動を指示するホストのＩＰアドレス
が格納される。これは後述の本発明の第２の実施形態に
おいて使用する。

【００２２】ＢＵＦ（バッファ）１１４は、プロトコル
スタックが使用するパケットの領域であり、各プロトコ
ル層間でパケットを伝達して処理する場合に使用し、通
常は複数パケットを扱えるような大きさを確保し、パケ
ット単位に分割して活用される。ＳＢ（センディング・
バッファ）１１５およびＲＢ（レシーバ・バッファ）１
１６は、それぞれネットワーク・ドライバが使用する送
信バッファと受信バッファである。

【００２３】図２は本発明の第１の実施形態におけるネ
ットワーク構成を、ネットワーク・アーキテクチャの面
から示する。ここで、２０１はサーバ・ホスト、２０２
はクライアント・ホストである。サーバ・ホスト２０１
内部には、アプリケーションソフトであるサーバプログ
ラム２０３があり、また、他のホストと通信するための
プロトコル・スタック２０４があり、さらに、イーサネ
ット・デバイス２１１をアクセスするためのイーサネッ
ト・ドライバ２０６がある。

【００２４】サーバプログラム２０３からデータを他の
ホストへ送信する場合には、サーバプログラム２０３か
らデータがプロトコル・スタック２０４に渡され、デー
タは、そこでＴＣＰ（トランスミッション・コントロー
ル・プロトコル）あるいはＵＤＰ（ユーザ・データグラ
ム・プロトコル）のＩＰ（インターネット・プロトコ
ル）パケットに姿を変え、イーサネット・ドライバ２０
６へ渡される。プロトコル・スタック２０４とイーサネ
ット・ドライバ２０６間はＢＵＦ（バッファ）２０５を
介してパケットが渡される。

【００２５】イーサネット・ドライバ２０６ではＩＰパ
ケットをイーサネット・パケットに変換し、ネットワー
クデバイス２０８へ渡すと、パケットがネットワーク２
００に出される。データを受信する場合には、上記と逆
の経路を辿ることになる。

【００２６】クライアント・ホスト２０２は、その内部
構成の詳細をここでは記述していないが、その機能とし
て、サーバのサービスを利用するためのクライアント・
プログラム２１３がなければならない。本発明では、さ
らにリセット・プログラム２１４をクライアント・ホス
ト２０２内に備える。このリセット・プログラム２１４
は、サーバ・ホスト２０１が異常事態になった時に、そ
のホスト２０１をリセットするための特殊パケットを送
信するプログラムである。

【００２７】イーサネット・ドライバ部２０６をさらに
細かく分類すると、イーサネット・ドライバ部２０６
は、ＩＰパケットＩ／Ｆ（インターフェース）部２０
７、デバイスＩ／Ｆ（インターフェース）部２０８、お
よび本発明の特徴的な機能であるパケット監視部２１２
から構成される。パケットは、送信バッファ（ＳＢ）２
０９と受信バッファ（ＲＢ）２１０を介して、イーサネ
ット・デバイス２１１とやり取りされる。

【００２８】以下に、本発明に係わる部分であるイーサ
ネット・ドライバ２０６の動作の詳細を説明する。な
お、本発明ではパケット受信処理だけが関係するため、
受信処理のみについて説明する。また、この実施形態で
はイーサネット・ドライバ２０６を扱うが、他のデバイ
スのドライバでも同様に適用可能である。

【００２９】図３のフローチャートは、図２のイーサネ
ット・ドライバ２０６のパケット受信時の動作手順を示
す。ここで、ステップ３０１から３０６までは、デバイ
スＩ／Ｆ部２０８の処理手順であり、ステップ３０７か
ら３１２までは、ＩＰパケットＩ／Ｆ部２０７の処理手
順である。また、ステップ３１３および３１４は、パケ
ット監視部２１２の処理手順にあたる。

【００３０】まず、イーサネット・デバイス２１１がネ
ットワーク２００からパケットを受信すると、割り込み
を発生する（ステップ３０１）。本実施形態でのイーサ
ネット・デバイス２１１は、１つのイーサネット・パケ
ットのデータのすべてを受信バッファ（ＲＢ）２１０に
書き込み終えたら、割り込みを発生する仕様とする。ま
た、受信バッファ（ＲＢ）２１０には、パケットの書き
込みに先だって、パケットのデータ長が書き込まれるこ
ととする。受信バッファ２１０のアドレスは、初期設定
時にイーサネット・デバイス２１１に設定する。

【００３１】割り込みが発生した後、ステップ３１３で
パケットの検査をする。これは受信バッファ２１０の特
定のバイトの値を基にそのパケットがリセットのための
特殊パケットか否かを判定する部分である。この処理に
ついては後述する。もし、通常のパケットであるなら
ば、プロトコル・スタックで使用するスタック・バッフ
ァの確保をＩＰパケットＩ／Ｆ部２０７に要求する。こ
のスタック・バッファは図１ではＢＵＦ１１４、図２で
は、ＢＵＦ２０５に対応するものである。

【００３２】一方、ＩＰパケットＩ／Ｆ部２０７では、
そのスタック・バッファの要求を待って（ステップ３０
７）、その要求がきたら、スタック・バッファを１パケ
ット分確保する。これは、ＲＡＭ上のＢＵＦ領域１１４
から、現在地で使われていないバッファ領域を割り当て
るものである。スタック・バッファを１パケット分確保
できたら、この確保できたことをデバイスＩ／Ｆ部２０
８に通知する（ステップ３０９）。

【００３３】デバイスＩ／Ｆ部では、スタック・バッフ
ァが確保されるのを待って（ステップ３０３）、それが
確保されたら、受信バッファ２１０からパケットをその
確保されたスタック・バッファにコピーする。図２で
は、そのパケットはＢＵＦ２０５にコピーされることに
なる。この時、コピーされるのはイーサネットヘッダ部
分を除いたＩＰパケット部分のデータである。

【００３４】ＩＰパケット部分のデータがＢＵＦ２０５
にコピーし終ったら、コピー終了をＩＰパケットＩ／Ｆ
部２０７に通知する。ステップ３１０で待ち受けていた
ＩＰパケットＩ／Ｆ部２０７はそのコピー終了の通知を
受けると、受信処理を実行する。この受信処理の内容
は、受信したＩＰパケットをプロトコルスタックへ渡す
ことである。これは、プロトコルスタックの実装方法に
よって異なるが、例えば、プロトコルスタックが、各プ
ロトコル層（ＴＣＰ，ＵＤＰ，ＩＰ）ごとにタスクで実
現されているような構成になっている場合、ＩＰパケッ
トが格納されているスタック・バッファをＩＰタスクが
所有しているメッセージ・キューへキューイングする処
理となる。

【００３５】このキューイングされたＩＰタスクは、起
動してそのパケットを処理し、処理したパケットを上位
層へと渡していくことになる。この処理が終了したら、
ステップ３１２で受信処理の完了通知をデバイスＩ／Ｆ
部２０８に対して行い、以後次のパケットの処理が可能
となる。

【００３６】次に、リセットのための特殊パケットにつ
いて説明する。本実施形態では、特殊パケットとして非
常に簡単なプロトコルとなっているＵＤＰ（ユーザ・デ
ータグラム・プロトコル）パケットを利用する。本発明
では、既存のプロトコルのパケットをリセットのための
パケットとして使うことができるため、既存のネットワ
ーク上で既存のプロトコルを利用できる。したがって、
既存のネットワーク通信と共存でき、また、特別なハー
ドウェアの変更を必要としない。さらに、本発明では、
サーバ機器をリセットするためのパケットを送信するホ
ストも、そのためのアプリケーションプログラムだけが
あればよく、プロトコル・スタックやネットワークデバ
イスおよびそのドライバをなんら変更する必要がない利
点がある。

【００３７】図４はＵＤＰパケットを含んだイーサネッ
トパケットのフォーマットの一例を示す。これは、イー
サネットの規格とＩＰ（インターネット・プロトコル）
とＵＤＰ（ユーザ・データグラム・プロトコル）の仕様
に準じたフォーマットであり、各項目の説明はここでは
省略する。本実施形態では、ＵＤＰポート番号がある決
められた値になっているものを、機器をリセットするた
めのパケットと定義する。このポート番号は、そのサー
バ・ホスト内で使われていないポート番号でなければな
らない。また、このポート番号は、安全のため著明なサ
ーバで使われている、いわゆる、ウエルノンポート（we
ll Known Port）で使われている番号は、避けた方が無
難である。このポート番号は、予めの取り決め事とし
て、サーバ／クライアント間で定義しておく、または、
機器が正常の間にリセット用のポート番号をネットワー
クを通じてクライアントに知らせる独自のプロトコルを
利用して伝達してもよい。この機器リセット用のポート
番号は、図１のＲＳＴ＿ＰＯＲＴ１１２に保持される。

【００３８】機器リセット用のパケットを送信するクラ
イアントホストは、単にポート番号がＲＳＴ＿ＰＯＲＴ
に等しいＵＤＰパケットを送信すればよい。このプログ
ラムが図２のリセット・プログラム２１４になる。

【００３９】図５は、機器リセット用のパケットか否か
を判定する条件をフローチャートで表わしたものであ
る。このフローは図３のステップ３１３の詳細図にな
る。

【００４０】まず、ステップ５０１では、イーサネット
ヘッダの先頭から３６バイト目の２バイトの値、すなわ
ちそのパケットがＵＤＰパケットであったとしたら、そ
の宛先ポート番号（図４参照）が格納されているべきと
ころの値が、ＲＳＴ＿ＰＯＲＴ１１２の値に等しいか否
かを調べる。その位置がポート番号が格納されているか
否かはこの時点では特定できないが、リセット用のパケ
ットでなければ、多くのパケットはこの条件を満たさな
いはずであり、１つの条件判断で済むためオーバヘッド
は少ない。

【００４１】もしも、宛先ポート番号が格納されている
べきところの値が、ＲＳＴ＿ＰＯＲＴの値に一致してい
る場合は、リセット用のパケットである可能性がある。
その場合は、したがって、ステップ５０２で今度はイー
サネットヘッダの先頭から２３バイト目の１バイトが、
すなわちＩＰヘッドヘッダのプロトコル番号（図４参
照）が１７、すなわちＵＤＰパケットか否かを判定す
る。

【００４２】もしステップ５０２が肯定判定ならば、さ
らに宛先ＩＰアドレスがサーバホストのＩＰアドレスと
一致しているか否かをステップ５０３で判定する。この
判定はブロードキャストアドレスなどの場合を排除する
ためである。宛先ＩＰアドレスは、イーサネットヘッダ
の先頭から３０バイト目の４バイトである（図４参
照）。また、このサーバホストのＩＰアドレスは、図１
のＳＩＰ１１１に保持されている。

【００４３】以上の各条件の全てを満たせば、受信した
パケットは機器のリセット用のパケットであると判断す
る。なお、本実施形態のイーサネットデバイスは、自分
のＭＡＣ（media access control:媒体アクセス制御）
アドレスとＩＰパケットのみをフィルタリングして受信
するモードに設定してあると仮定している。もし、ＩＰ
パケット以外も受信バッファＲＢ２１０に転送される場
合には、イーサネットヘッダのフレーム・タイプも判定
に加えるなどしなければならない。

【００４４】機器リセット用の特殊パケットが受信され
たならば、イーサネット・ドライバはリセットを実行す
る。これは図３のステップ３１４に対応する。本実施形
態では、ネットワーク・プロトコル・スタックが暴走し
ていると仮定し、ネットワーク機能の再起動を行う。図
６はその際のプロトコル・スタックの停止処理、図７は
プロトコル・スタックの起動処理を表すフローチャート
である。

【００４５】ネットワーク・プロトコル・スタックの停
止処理と起動処理のプログラムエントリをイーサネット
・ドライバが知っていて、ＲＯＭ内のそれらを順にコー
ルすれば、ネットワークの再起動が実現される。なお、
本実施形態では、プロトコルスタックは、プロトコル層
毎にタスクで構成された実装であると仮定している。そ
の実装方法が異なれば、図６、図７で示したと同一の処
理内容にはならないが、同様のことを実行するようにす
ればよい。

【００４６】まず、図６のプロトコル・スタックの停止
処理を説明する。ステップ６０１では、ＴＣＰタスクの
停止を行う。ＴＣＰで使用しているＯＳの資源、例えば
セマフォ（semaphore），メッセージ・キュー，イベン
ト・フラグなど削除し、タスクを削除する。同様に、ス
テップ６０２，ステップ６０３では、ＵＤＰタスクおよ
びＩＰタスクに係わる停止処理をする。最後にステップ
６０４では、各プロトコル間で共有している大域的な資
源を開放する。

【００４７】次に、図７のプロトコル・スタックの起動
処理を説明する。ステップ７０１ではまず、各プロトコ
ル間で共有する資源を確保し、初期化する。以降、ステ
ップ７０２，ステップ７０３，ステップ７０４では、Ｔ
ＣＰ，ＵＤＰ，ＩＰのそれぞれのタスクを生成し、タス
クで使用する資源を確保し、初期化した後、タスクを起
動していく。以上で、ネットワーク・プロトコル・スタ
ックの再起動が実現されることになる。

【００４８】以上説明したように、本実施形態によれ
ば、他のホストがネットワークを介して障害が発生して
いるであろうと思われるホトスのネットワーク機能を復
旧することができる。

【００４９】（第２の実施形態）上述した本発明の第１
の実施形態では、機器リセット用のポート番号がわかっ
ていれば、任意のホストにより機器のリセットの実行が
できてしまう。これは安全上好ましくない状況が考えら
れる。従って、機器リセットができるホストを限定する
機能を設けたのが、以下に説明する本発明の第２の実施
形態である。

【００５０】図８は本発明の第２の実施形態におけるイ
ーサネット・ドライバの機器リセット用パケットの判定
フローを示す。ステップ８０１〜８０３は第１の実施形
態における図５の条件ステップ５０１〜５０３と同じで
ある。本実施形態では、これら条件ステップに、さらに
ステップ８０４を加え、特定のＩＰアドレスからきたパ
ケットだけをリセット用パケットとして有効にしてい
る。この特定のＩＰアドレスとしての、リセットを許可
するホストのＩＰアドレスを予めＲＳＴ＿ＤＩＰ（図１
の１１３）に保持しておく、もし、このアドレスを複数
用意すれば、複数のホストに機器リセットを許可するこ
とも可能である。

【００５１】（第３の実施形態）上述した本発明の第１
の実施形態では、機器リセット用のパケットを送信する
ホストは、クライアント・プログラムを起動していて、
サーバにアクセスできないことをオペレータが確認して
から、手動でリセット・プログラムを起動するという手
順を遂行している。

【００５２】これに対し、本発明の第３の実施形態で
は、正規のクライアント・プログラムではなく、正常な
通信が可能か否かを調べる特定のテスト・プログラムを
一定間隔で走らせ、もしそれが失敗した場合には、サー
バ・マシンが不良であると自動的に判断して、機器リセ
ット用のパケットを自動的に送っている。

【００５３】図９はクライアント・マシンで行うテスト
・プログラムのフローを示す。ステップ９０１では、通
信テストを実行する。ここでは、Well Known Port （周
知ポート）の一つであるＥＣＨＯ（エコー）ポートに所
定のデータを送信し、送ったデータが正常に返ってくる
か否かを検査する。その際、そのデータにＴＣＰプロト
コルおよびＵＤＰプロトコルの両方を使用する方がより
テストの信頼性は向上する。もし失敗したら、つまり送
ったデータが正常に返ってこなかったら（ステップ９０
２）、リセット用のパケットを送信する（ステップ９０
３）。

【００５４】これにより、自動的に、サーバホストの異
常を知り、サーバ・マシンを復旧させることができる。

【００５５】（第４の実施形態）これまで説明した本発
明の第１〜第３の実施形態では、通信ができない原因は
ネットワーク・プロトコル・スタックに障害が起こった
ためであると仮定してきたが、障害がそれ以外に及んで
いる場合も十分に考えられる。

【００５６】以下に説明する本発明の第４の実施形態
は、機器リセット用のパケットが受信されたら、ＯＳか
ら再起動することにより、サーバ・ホストの復旧を実現
するものである。

【００５７】図１０は第４の実施形態におけるそのＯＳ
の再起動の処理フローの一例を示す。ステップ１００１
では、ＯＳを再起動する。例えば、イーサネット・ドラ
イバ２０１がＣＰＵ１０１のリセット命令を実行するこ
とにより、再立ち上げが可能である。以降、ドライバ類
の初期化（ステップ１００２）、ネットワークの初期化
と起動（ステップ１００３）、およびサーバアプリケー
ションの起動（ステップ１００４）を行う。

【００５８】本実施形態では、イーサネット・ドライバ
の機器リセットパケットの判定まで、正常に動作できる
状況であれば、サーバ・ホストをほぼ完全に復旧するこ
とが可能である。

【００５９】（他の実施の形態）なお、本発明は、複数
の機器（例えば、ホストコンピュータ、インターフェー
ス機器、リーダ、プリンタなど）から構成されるシステ
ムに適用しても、１つの機器からなる装置（例えば、複
写機、ファクシミリ装置など）に適用してもよい。

【００６０】また、本発明の目的は、前述した実施の形
態の機能を実現するソフトウエアのプログラムコードを
記録した記録媒体（記憶媒体）を、システムあるいは装
置に供給し、そのシステムあるいは装置のコンピュータ
（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプロ
グラムコードを読み出し、実行することによっても、達
成されることは言うまでもない。

【００６１】この場合、記録媒体から読み出されたプロ
グラムコード自体が前述した実施の形態の機能を実現す
ることになり、そのプログラムコードを記録した記録媒
体は本発明を構成することになる。

【００６２】そのプログラムコードを記録し、またテー
ブル等の変数データを記録する記録媒体としては、例え
ばフロッピディスク（ＦＤ）、ハードディスク、光ディ
スク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気
テープ、不揮発性のメモリカード（ＩＣメモリカー
ド）、ＲＯＭなどを用いことができる。

【００６３】また、コンピュータが読み出したプログラ
ムコードを実行することにより、前述の実施の形態の機
能が実現されるだけでなく、そのプログラムコードの指
示に基づいて、コンピュータ上で稼動しているＯＳ（オ
ペレーティングシステム）などが実際の処理の一部また
は全部を行ない、その処理によって前述した実施の形態
の機能が実現される場合も含まれることは言うまでもな
い。

【００６４】

【発明の効果】以上説明してきたように、本発明によれ
ば、障害が発生して通信機能が利用不可になっているホ
ストをネットワークを介して他のホストから復旧するこ
とが可能となる。

【００６５】サーバ機器では、長時間連続運用するた
め、思わぬ障害が顕現化する可能性がある。特に組み込
み機器にそれが生じた場合には、機器が無人の場所に設
置されている可能性もある。したがって、本発明を用い
ることで、遠隔で復旧操作ができる効果は大きい。

【図面の簡単な説明】

【図１】本発明の第１の実施形態におけるネットワーク
機器のブロック構成を示すブロック図である。

【図２】本発明の第１の実施形態におけるネットワーク
構成を、ネットワーク・アーキテクチャの面から示すネ
ットワーク構成図である。

【図３】図２のイーサネット・ドライバ２０６のパケッ
ト受信時の動作手順を示すフローチャートである。

【図４】ＵＤＰパケットを含んだイーサネットパケット
のフォーマットの一例を示すアドレスマップを示す図で
ある。

【図５】本発明の第１実施形態における機器リセット用
のパケットか否かを判定する手順を示すフローチャート
である。

【図６】本発明の第１実施形態におけるプロトコル・ス
タックの停止処理の手順を示すフローチャートである。

【図７】本発明の第１実施形態におけるプロトコル・ス
タックの起動処理の手順を示すフローチャートである。

【図８】本発明の第２実施形態における機器リセット用
のパケットが否かを判定する手順を示すフローチャート
である。

【図９】本発明の第３実施形態におけるテクライアント
・マシンで行うテスト・プログラムの処理手順を示すフ
ローチャートである。

【図１０】本発明の第４実施形態におけるＯＳの再起動
の手順を示すフローチャートである。

【図１１】従来の一般的なネットワーク機器の構成を示
すネットワーク構成図である。

【符号の説明】

１０１ＣＰＵ１０２ＲＯＭ１０３ＲＡＭ１０４通信デバイス１０５バス１０６通信線１０７アップリケーション・プログラム１０８ネットワーク・プロトコル・スタック１０９ネットワーク・デバイス・ドライバ１１０ＯＳ１１１ＳＩＰ（ホストのＩＰアドレス）１１２ＲＳＴ＿ＰＯＲＴ（リセットパケットのポート
番号）１１３ＲＳＴ＿ＤＩＰ（リセットを許可するホストの
ＩＰアドレス）１１４ＢＵＦ（プロトコルスタックが使用するパケッ
トの領域）１１５ＳＢ（送信バッファ）１１６ＲＢ（受信バッファ）２０１クライアント・ホスト２００ネットワーク２０２サーバ・ホスト２０３サーバプログラム２０４プロトコル・スタック２０５ＢＵＦ２０６インサーネット・ドライバ部２０７ＩＰパケットＩ／Ｆ部２０８デバイスＩ／Ｆ部２０９ＳＢ（送信バッファ）２１０ＲＢ（受信バッファ）２１１インサーネット・デバイス２１２ネットワーク・ドライバのパケット監視部２１３クライアント・プログラム２１４リセット・プログラム

───────────────────────────────────────────────────── フロントページの続きＦターム(参考） 5B089 GA21 GB02 HB10 JA35 JB22 KA12 KC30 MC12 ME14 5K030 GA12 HA08 HB06 HB28 JA10 JT06 LE07 MA06 MC09 MD01 5K032 AA06 BA08 CC11 CD03 DA02 DB28 EA03 EA05 EB03 5K035 AA03 BB04 DD01 LL01 LL07 9A001 BB04 CC06 CC07 JJ27 KK56 LL05

Claims

【特許請求の範囲】

【請求項１】復旧を指示するデータを送信する送信手
段と、前記データを受信する受信手段と、該受信手段が受信した受信データの特定の部分を通信媒
体に近い受信処理において監視することで、当該受信デ
ータが前記復旧を指示するデータか否かを判定する判定
手段と、前記受信データは前記復旧を指示するデータであるとの
前記判定手段の判定結果に応じて通信装置の再起動を実
行する再起動実行手段とを有することを特徴とする遠隔
復旧機能を有する通信装置。
【請求項２】前記送信手段は、常時、一定間隔で正常
な通信が可能か否かを検査する検査プログラムを実行
し、その際送ったテストデータが正常に返ってこない時
に前記復旧を指示するデータを送信することを特徴とす
る請求項１に記載の通信装置。
【請求項３】前記再起動実行手段は、通信装置の再起
動を実行する際に、ネットワーク・プロトコル・スタッ
クの停止処理をする手段と、その後に該ネットワーク・
プロトコル・スタックの起動処理をする手段とを含むこ
とを特徴とする請求項１または２に記載の通信装置。
【請求項４】前記再起動実行手段は、通信に係わる部
分を再起動する手段と、オペレーション・システムを含
めた機器全体を再起動する手段とを含むことを特徴とす
る請求項１または２に記載の通信装置。
【請求項５】前記復旧を指示するデータは、ＵＤＰパ
ケットを利用した特殊パケットであり、ＵＤＰポート番
号がある決められた値になっているものを機器をリセッ
トするためのパケットとして予め定義されることを特徴
とする請求項１ないし４のいずれかに記載の通信装置。
【請求項６】前記判定手段は、さらに前記復旧を指示
するデータが機器リセットを許可されたホストを表わす
特定のＩＰアドレスからきたデータか否かを判定し、前記再起動実行手段は、前記復旧を指示するデータが前
記特定のＩＰアドレスからきたデータであるとの前記判
定手段の判定結果に応じて、通信装置の再起動を実行す
ることを特徴とする請求項１ないし５のいずれかに記載
の通信装置。
【請求項７】復旧を指示するデータを送信する送信ス
テップと、前記データを受信する受信ステップと、該受信ステップが受信した受信データの特定の部分を通
信媒体に近い受信処理において監視することで、当該受
信データが前記復旧を指示するデータか否かを判定する
判定ステップと、前記受信データは前記復旧を指示するデータであるとの
前記判定ステップの判定結果に応じて通信装置の再起動
を実行する再起動実行ステップとを有することを特徴と
する通信方法。
【請求項８】前記送信ステップは、常時、一定間隔で
正常な通信が可能か否かを検査する検査プログラムを実
行し、その際送ったテストデータが正常に返ってこない
時に前記復旧を指示するデータを送信することを特徴と
する請求項７に記載の通信方法。
【請求項９】前記再起動実行ステップは、通信装置の
再起動を実行する際に、ネットワーク・プロトコル・ス
タックの停止処理をするステップと、その後に該ネット
ワーク・プロトコル・スタックの起動処理をするステッ
プとを含むことを特徴とする請求項７または８に記載の
通信方法。
【請求項１０】前記再起動実行ステップは、通信に係
わる部分を再起動するステップと、オペレーション・シ
ステムを含めた機器全体を再起動するステップとを含む
ことを特徴とする請求項７または８に記載の通信方法。
【請求項１１】前記復旧を指示するデータは、ＵＤＰ
パケットを利用した特殊パケットであり、ＵＤＰポート
番号がある決められた値になっているものを機器をリセ
ットするためのパケットとして予め定義されることを特
徴とする請求項７ないし１０のいずれかに記載の通信方
法。
【請求項１２】前記判定ステップは、さらに前記復旧
を指示するデータが機器リセットを許可されたホストを
表わす特定のＩＰアドレスからきたデータか否かを判定
し、前記再起動実行ステップは、前記復旧を指示するデータ
が前記特定のＩＰアドレスからきたデータであるとの前
記判定ステップの判定結果に応じて、通信装置の再起動
を実行することを特徴とする請求項７ないし１１のいず
れかに記載の通信方法。
【請求項１３】コンピュータにより通信装置を遠隔復
旧するためのプログラムを記録した記録媒体において、
該プログラムはコンピュータに対し、受信手段が受信した受信データの特定の部分を通信媒体
に近い受信処理において監視させることで、当該受信デ
ータが復旧を指示するデータか否かを判定させ、該復旧を指示するデータであるとの判定結果に応じて通
信装置の再起動を実行させることを特徴とする遠隔復旧
用プログラムを記録した記録媒体。
【請求項１４】前記プログラムはコンピュータに対
し、常時、一定間隔で正常な通信が可能か否かを検査する検
査プログラムを実行させ、その際送ったテストデータが
正常に返ってこない時に前記復旧を指示するデータを送
信させることを特徴とする請求項１３に記載の記録媒
体。
【請求項１５】前記プログラムはコンピュータに対
し、通信装置の再起動を実行する際に、ネットワーク・プロ
トコル・スタックを停止処理させ、その後に該ネットワーク・プロトコル・スタックを起動
処理させることを特徴とする請求項１３または１４に記
載の記録媒体。
【請求項１６】前記プログラムはコンピュータに対
し、通信に係わる部分を再起動させ、オペレーション・システムを含めた機器全体を再起動さ
せることを特徴とする請求項１３または１４に記載の記
録媒体。
【請求項１７】前記復旧を指示するデータは、ＵＤＰ
パケットを利用した特殊パケットであり、ＵＤＰポート
番号がある決められた値になっているものを機器をリセ
ットするためのパケットとして予め定義されることを特
徴とする請求項１３ないし１６のいずれかに記載の記録
媒体。
【請求項１８】前記プログラムはコンピュータに対
し、さらに前記復旧を指示するデータが機器リセットを許可
されたホストを表わす特定のＩＰアドレスからきたデー
タか否かを判定させ、前記復旧を指示するデータが前記特定のＩＰアドレスか
らきたデータであるとの判定結果に応じて、通信装置の
再起動を実行させることを特徴とする請求項１３ないし
１７のいずれかに記載の記録媒体。