第1のホストに接続される第1の処理部と、第2のホストに接続される第2の処理部と、前記第1の処理部及び第2の処理部が利用する記憶部と、を有する共有装置において、前記第1の処理部が前記第1のホストからの第1のメッセージの送信要求を受け取ると、前記第2の処理部に対してリクエストを送信し、当該リクエストを受信した前記第2の処理部が前記メッセージを前記第2のホストに送信すると共にリプライを前記第1の処理部に送信し、前記リプライを受け取った第1の処理部は当該リプライが前記第1のメッセージの送信要求に応じたリプライであるか否かを判断し、前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第1の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする共有装置。請求項1に記載の共有装置において、前記判断に際して、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第1の処理部のブート及びリブートの回数、が一致した場合には当該リプライが正当なものであると判断して前記第1のホストに対してリプライ処理を行い一致しなかった場合は当該リプライが正当なものでないと判断して当該リプライを廃棄することを特徴とする共有装置。請求項1又は2に記載の共有装置において、前記第1の処理部は前記リクエストを送信する際に前記記憶部に自身のブート及びリブートの回数を記録し、前記第2の処理部は前記リクエストを受け取るとともに前記記録されたブート及びリブートの回数を読み込んで自身が記憶し、前記第2の処理部は前記リプライを送信するとともに前記自身が記憶したブート及びリブートの回数を前記記憶部に記録し、前記第1の処理部は自身が前記記憶部に記録したブート及びリブートの回数と前記第2の処理部が前記記憶部に記録したブート及びリブートの回数を比較することにより前記判断を行うことを特徴とする共有装置。請求項1乃至3の何れか1項に記載の共有装置において、前記第1の処理部が第2の処理部としても動作し、前記第2の処理部が第1の処理部としても動作することを特徴とする共有装置。第1のホストに接続される第1の処理部と、第2のホストに接続される第2の処理部と、前記第1の処理部及び第2の処理部が利用する記憶部と、を有する共有装置並びに当該共有装置に接続された前記第1のホスト及び前記第2のホストを含んだクラスタシステムにおいて、前記第1のホスト及び前記第2のホストは前記共有装置を介して通信を行い、前記共有装置は請求項1乃至4の何れか1項に記載の共有装置であることを特徴とするクラスタシステム。第1のホストに接続される第1の処理部と、第2のホストに接続される第2の処理部と、前記第1の処理部及び第2の処理部が利用する記憶部と、を有する共有装置が行う不整合検出方法において、前記第1の処理部が前記第1のホストからの第1のメッセージの送信要求を受け取ると、前記第2の処理部に対してリクエストを送信し、当該リクエストを受信した前記第2の処理部が前記メッセージを前記第2のホストに送信すると共にリプライを前記第1の処理部に送信し、前記リプライを受け取った第1の処理部は当該リプライが前記第1のメッセージの送信要求に応じたリプライであるか否かを判断し、前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第1の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする不整合検出方法。請求項6に記載の不整合検出方法において、前記判断に際して、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第1の処理部のブート及びリブートの回数、が一致した場合には当該リプライが正当なものであると判断して前記第1のホストに対してリプライ処理を行い一致しなかった場合は当該リプライが正当なものでないと判断して当該リプライを廃棄することを特徴とする不整合検出方法。請求項6又は7に記載の不整合検出方法において、前記第1の処理部は前記リクエストを送信する際に前記記憶部に自身のブート及びリブートの回数を記録し、前記第2の処理部は前記リクエストを受け取るとともに前記記録されたブート及びリブートの回数を読み込んで自身が記憶し、前記第2の処理部は前記リプライを送信するとともに前記自身が記憶したブート及びリブートの回数を前記記憶部に記録し、前記第1の処理部は自身が前記記憶部に記録したブート及びリブートの回数と前記第2の処理部が前記記憶部に記録したブート及びリブートの回数を比較することにより前記判断を行うことを特徴とする不整合検出方法。請求項6乃至8の何れか1項に記載の不整合検出方法において、前記第1の処理部が第2の処理部としても動作し、前記第2の処理部が第1の処理部としても動作することを特徴とする不整合検出方法。第1のホストに接続される第1の処理部と、第2のホストに接続される第2の処理部と、前記第1の処理部及び第2の処理部が利用する記憶部と、を有する共有装置並びに当該共有装置に接続された前記第1のホスト及び前記第2のホストを含んだクラスタシステムが行う不整合検出において、前記第1のホスト及び前記第2のホストは前記共有装置を介して通信を行い、前記共有装置は請求項6乃至8の何れか1項に記載の不整合検出方法を行うことを特徴とする不整合検出方法。上述したように、特許文献1に記載の技術等を用いることにより各処理を識別することが可能となる。しかしながら、特許文献1に記載の技術等では、各処理毎に電文識別子を変化させる必要があり、電文識別子の付与及び確認に伴う処理が煩雑になるという問題があった。また、特許文献1に記載の技術等は、ホストたる各サーバが電文識別子を管理する必要があるという問題があった。加えて、特許文献1に記載の技術等は、共有装置の処理部のリブートを考慮したものではなく、リブートが生じたタイミングによっては処理部間ですれ違いによる不整合が発生してしまうという課題を直接解決するものではなかった。そこで、本実施形態では、ホストにおいて電文識別子を管理させることなく、且つ、各処理毎に電文識別子を変化させる必要がない方法で、リブートに伴う処理部間での不整合を検出することが可能な、障害によるリブートを考慮した処理部間の不整合検出方法並びに共有装置及びクラスタシステムを提供することを目的とする。本発明の第1の観点によれば、第1のホストに接続される第1の処理部と、第2のホストに接続される第2の処理部と、前記第1の処理部及び第2の処理部が利用する記憶部と、を有する共有装置において、前記第1の処理部が前記第1のホストからの第1のメッセージの送信要求を受け取ると、前記第2の処理部に対してリクエストを送信し、当該リクエストを受信した前記第2の処理部が前記メッセージを前記第2のホストに送信すると共にリプライを前記第1の処理部に送信し、前記リプライを受け取った第1の処理部は当該リプライが前記第1のメッセージの送信要求に応じたリプライであるか否かを判断し、前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第1の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする共有装置が提供される。本発明の第2の観点によれば、第1のホストに接続される第1の処理部と、第2のホストに接続される第2の処理部と、前記第1の処理部及び第2の処理部が利用する記憶部と、を有する共有装置が行う不整合検出方法において、前記第1の処理部が前記第1のホストからの第1のメッセージの送信要求を受け取ると、前記第2の処理部に対してリクエストを送信し、当該リクエストを受信した前記第2の処理部が前記メッセージを前記第2のホストに送信すると共にリプライを前記第1の処理部に送信し、前記リプライを受け取った第1の処理部は当該リプライが前記第1のメッセージの送信要求に応じたリプライであるか否かを判断し、前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第1の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする不整合検出方法が提供される。本発明によれば、共有装置内のブートカウンタエリアの値を要因とすることによりリブートが発生してもリクエストとリプライの対応づけをすることが出来ることから、ホストにおいて電文識別子を管理させることなく、且つ、各処理毎に電文識別子を変化させる必要がない方法で、リブートに伴う処理部間での不整合を検出することが可能となる。次に、本発明の実施形態について図面を用いて詳細に説明する。図1を参照すると、本実施形態は、共有装置1000と第1のホスト2000と第2のホスト3000とを有している。そして、本実施形態においては、第1のホスト2000と第2のホスト3000が、共有装置1000を介して相互にデータをやり取りしながら処理を行う。なお、やり取りされるデータはどのような規格やプロトコルに準拠したものであってもよい。本実施形態は、任意の通信方式に準拠して実装することが可能である。共有装置1000は、記憶部110と第1の処理部120と第2の処理部130とを有している。また、第1の処理部120は、第1のホスト2000とは直接接続されているが第2のホスト3000とは直接接続されていない。同様に、第2の処理部130は、第2のホスト3000とは直接接続されているが第1のホスト2000とは直接接続されていない。なお、各ホストとの接続は任意の方式により行うことが可能であり、接続方式に特に制限は無い。記憶部110は、記憶装置であり、その用途に応じて複数の領域を有している。具体的には、記憶部110は、ブートカウンタ領域、リクエスト領域、リプライ領域及び通信データ領域を有している。そして、これらの各領域は処理部毎に1つずつ用意されている。そのため、本実施形態では、第1の処理部120用の領域として、第1のブートカウンタ領域111、第1のリクエスト領域113、第1のリプライ領域115及び第1の通信データ領域117を有している。加えて、第2の処理部130用の領域として、第2のブートカウンタ領域112、第2のリクエスト領域114、第2のリプライ領域116、及び第2の通信データ領域118を有している。これらの各領域の具体的用途に関しては後述する。第1の処理部120及び第2の処理部130は、ローカルメモリ以下の説明及び図中においては、適宜LMと呼ぶ。121及び131を有している。また、第1の処理部120及び第2の処理部130は、それぞれ、ブート回数登録部122及び132と、ホスト要求処理部123及び133と、他処理部要求処理部124及び134と、他処理部リプライ処理部125及び135を有する。ブート回数登録部122及び132は、第1の処理部120及び第2の処理部130のブート時と、リブート時に記憶部110のブートカウンタ領域にインクリメントしたブート回数を登録する機能を有する。ホスト要求処理部123及び133は、自身が接続されているホストから送信要求を受け取った際に、他の処理部に要求を出す機能を有する。他処理部要求処理部124及び134は、他処理部のホスト要求処理部から要求を受け取った際に、自身が接続されているホストにメッセージを送信し、送信成功後に要求元のホスト要求処理部に応答以下、適宜リプライと呼ぶを返す機能を有する。他処理部リプライ処理部125及び135は、他処理部の他処理部要求処理部からリプライを受け取った際に自身が接続されているホストにリプライを返す機能を有する。次に、図2乃至図5のフローチャートを参照して本実施形態の有する各部の動作について詳細に説明する。図2は、ブート回数登録部122及び132の動作を表すフローチャートである。ブート回数登録部122及び132は自身が含まれている処理部がブートする際及びリブートする際に動作を行う。図2を参照すると、ブート時及びリブート時に、ブート回数登録部122及び132は、記憶部110内の自処理部に割り当てられているブートカウンタ領域の値を読み出すステップA1。次に、読み出した値とブートカウンタが取り得る最大値を比較するステップA2。ステップA2における比較の結果、両値が等しければステップA2においてYesブートカウンタ領域に1を登録するステップA3。すなわち、処理後のブートカウンタ値は1となる。一方、ステップA2における比較の結果、両値が等しくなければステップA2においてNo、現在のブートカウンタ領域の値に1を加算するステップA4。すなわち、処理後のブートカウンタ値は現在のブートカウンタ値1となる。以上で、ブート回数登録部122及び132の動作は終了する。図3は、ホスト要求処理部123及び133の動作を表すフローチャートである。図3を参照すると、ホスト要求処理部123及び133は、ホストからの通信要求を受信するまで待機をするステップB1においてNo。通信要求を受信するとステップB1においてYes、受信した通信要求に付随する通信メッセージを、通信先ホストが接続されている処理部に割り当てられている通信データ領域に格納するステップB2。次に、記憶部110の自処理部に割り当てられているブートカウンタ領域の値を読み出しステップB3、読み出した値を記憶部110の通信先ホストが接続されている処理部に割り当てられているリクエスト領域に格納するステップB4。その後、再び、ステップB1に戻り、ホストからの通信要求を受信するまで待機をする。図4は、他処理部要求処理部124及び134の動作を表すフローチャートである。図4を参照すると、他処理部要求処理部124及び134は、記憶部110の自処理部に割り当てられているリクエスト領域の値の監視をするステップC1。そして、記憶部110の自処理部に割り当てられているリクエスト領域に0以外の値が書き込まれるまで待機をするステップC2においてNo。0以外の値が書き込まれるとステップC2においてYes、書き込まれた値を自処理部内のLMに一時保存する。また、LMに書き込まれた値を一時保存するに伴いリクエスト領域を0でクリアするステップC3。次に、記憶部110の自処理部に割り当てられた通信データ領域に格納されている通信メッセージを読み出すステップC4。そして、自身に接続されているホストにステップC4において読み出した通信メッセージを送信しステップC5、ホストからの応答リプライを受信するまで待機をするステップC6においてNo。そして、ホストからの応答を受信するとステップC6においてYes、リクエスト領域からLMに一時保存していた値を、リクエストの要求元の処理部に割り当てられている記憶部110のリプライ領域に格納するステップC7その後、再びステップC1に戻り、リクエスト領域の値の監視をする。図5は、他処理部リプライ処理部125及び135の動作を表すフローチャートである。図5を参照すると、他処理部リプライ処理部125及び135は、記憶部110の自処理部に割り当てられているリプライ領域の値の監視をするステップD1。記憶部110の自処理部に割り当てられているリプライ領域に0以外の値が書き込まれるまで待機をするステップD2においてNo。0以外の値が書き込まれるとステップC2においてYes、書き込まれた値を自処理部内のLMに一時保存する。また、LMに書き込まれた値を一時保存するに伴いリプライ領域を0でクリアするステップD3。次に、一時保存した値と記憶部110の自処理部に割り当てられているブートカウンタ領域の値を比較するステップD4。ステップD4における比較の結果、両値が等しければステップD4においてYes、自身に接続されているホストに通信完了を報告するステップD5。そして、ステップD1に戻る。一方、ステップD4における比較の結果、両値が等しくなければステップD4においてNo、何もせずにステップD1に戻る。すなわち、この場合には自身に接続されているホストに通信完了は報告されないこととなる。以上が本実施形態における各部の動作である。次に、本実施形態の動作について、具体的な例を挙げて詳細に説明する。今回の具体例では、第1のホスト2000から第2のホスト3000へのメッセージ通信を行う際に、処理の途中で、第1の処理部120が障害でリブートする、というケースを例に取って説明する。説明の為、このときの第1のブートカウンタ領域111の値は1であったと仮定するステップS4。第1のホスト2000が第1の処理部120にメッセージ通信を要求する。すると、ホストからの通信要求を監視している第1の処理部120のホスト要求処理部123が要求の受信を認識するステップB1においてYes。ホスト要求処理部123は受信した通信要求に付随する通信メッセージを通信先ホストに接続された処理部である第2の処理部130に割り当てられている、第2の通信データ領域118に格納するステップB2。次に、第2の処理部130にリクエストを出すために、第1のブートカウンタ領域111の値を読み出すステップB3。そして、ステップB3において読み出した値を第2のリクエスト領域114に格納するステップB4。次に、自身に割り当てられている第2のリクエスト領域114を監視している第2の処理部130の他処理部要求部134は、第2のリクエスト領域114に0以外の値が書き込まれたことを確認するステップC2においてYes。他処理部要求部134は、書き込まれた値をLM131に一時保存し、第2のリクエスト領域114を0でクリアするステップC3。次に、第2の通信データ領域118に格納されている通信メッセージを読み出しステップC4、第2のホスト3000に当該通信メッセージを送信しステップC5、第2のホスト3000からの応答を待つステップC6。そして、第2のホスト3000からの応答を受信するとステップC6においてYes、第2のリクエスト領域114からLM131に一時保存していた値を、第1のリプライ領域115に格納するステップC7。次に、自身に割り当てられている第1のリプライ領域115を監視している第1の処理部120の他処理部リプライ処理部125は第1のリプライ領域115に0以外の値が書き込まれたことを認識するとステップD2においてYes、書き込まれた値をLM121に一時保存し、第1のリプライ領域115を0でクリアするステップD3。次に、LM121に一時保存した値と第1のブートカウンタ領域111の値を比較するステップD4。ここで、通常は2つの値は等しくなるためステップD4においてYes、第1のホスト2000に対して通信完了の応答を返すステップD5。ここで、第1の処理部120が、第2の処理部130にリクエストを出した直後にリブートしたとする。このとき、第1の処理部120は、リブート直後にブート回数登録部122によって、第1のブートカウンタ領域111の値が2に更新されるステップA1、A2においてYes、A3。この状態で、第2の処理部130からリプライを受け取ると、先の、LM121に一時保存した値と第1のブートカウンタ領域111の値を比較する処理ステップD4において、一時保存した値はリブート前の値の1だが、第1のブートカウンタ領域111の値はリブート後の2になっているため、比較は不一致となりステップD4においてNo、第1のホスト2000に対して通信完了の応答は行われない。以上説明した本発明の実施形態は、以下に示すような多くの効果を奏する。第1の効果は、確実に処理部間の通信正常終了を確認出来ることである。その理由はブートカウンタ領域の値を要因とすることによりリブートが発生してもリクエストとリプライの対応づけをすることが出来る為である。リクエストとリプライの対応にずれが生じるのはリブートが発生したときのみである。第2の効果は、処理が軽いことである。その理由はブート処理リブート処理含むで一度リクエスト要因であるブートカウンタ領域の値をインクリメントしたらその後、リブートが発生するまで値をインクリメントせずともよい為である。通信発行毎にリクエスト要因をインクリメントする方法と比較し、少ない処理で同等の効果を得ることが出来る。なお、本発明の実施形態である共有装置は、ハードウェアにより実現することもできるが、コンピュータをその共有装置として機能させるためのプログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。また、本発明の実施形態による不整合検出方法は、ハードウェアにより実現することもできるが、コンピュータにその方法を実行させるためのプログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。また、上述した実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。加えて、本実施形態は、一般的な技術と比べ下記の点で有利な効果を奏している。一般的な技術では、処理要求毎に電文識別子を変化させている。しかし、本実施形態では識別子を処理要求毎に変化させておらず異なる。すなわち、本実施形態では装置がブートしたときのみインクリメントしており、識別子の更新を最小限に留めることで負荷を軽減させることが可能となるという効果を奏する。また、一般的な技術では、例えば各ブートデバイスのブート回数に制限をかける為、ブート回数を利用している。それに対し、本実施形態では処理部間の通信のすれ違いを防止する為、ブート回数を利用できるという効果を奏する。上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。付記1第1のホストに接続される第1の処理部と、第2のホストに接続される第2の処理部と、前記第1の処理部及び第2の処理部が利用する記憶部と、を有する共有装置において、前記第1の処理部が前記第1のホストからの第1のメッセージの送信要求を受け取ると、前記第2の処理部に対してリクエストを送信し、当該リクエストを受信した前記第2の処理部が前記メッセージを前記第2のホストに送信すると共にリプライを前記第1の処理部に送信し、前記リプライを受け取った第1の処理部は当該リプライが前記第1のメッセージの送信要求に応じたリプライであるか否かを判断し、前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第1の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする共有装置。付記2付記1に記載の共有装置において、前記判断に際して、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第1の処理部のブート及びリブートの回数、が一致した場合には当該リプライが正当なものであると判断して前記第1のホストに対してリプライ処理を行い一致しなかった場合は当該リプライが正当なものでないと判断して当該リプライを廃棄することを特徴とする共有装置。付記3付記1又は2に記載の共有装置において、前記第1の処理部は前記リクエストを送信する際に前記記憶部に自身のブート及びリブートの回数を記録し、前記第2の処理部は前記リクエストを受け取るとともに前記記録されたブート及びリブートの回数を読み込んで自身が記憶し、前記第2の処理部は前記リプライを送信するとともに前記自身が記憶したブート及びリブートの回数を前記記憶部に記録し、前記第1の処理部は自身が前記記憶部に記録したブート及びリブートの回数と前記第2の処理部が前記記憶部に記録したブート及びリブートの回数を比較することにより前記判断を行うことを特徴とする共有装置。付記4付記1乃至3の何れか1に記載の共有装置において、前記第1の処理部が第2の処理部としても動作し、前記第2の処理部が第1の処理部としても動作することを特徴とする共有装置。付記5第1のホストに接続される第1の処理部と、第2のホストに接続される第2の処理部と、前記第1の処理部及び第2の処理部が利用する記憶部と、を有する共有装置並びに当該共有装置に接続された前記第1のホスト及び前記第2のホストを含んだクラスタシステムにおいて、前記第1のホスト及び前記第2のホストは前記共有装置を介して通信を行い、前記共有装置は付記1乃至4の何れか1項に記載の共有装置であることを特徴とするクラスタシステム。付記6第1のホストに接続される第1の処理部と、第2のホストに接続される第2の処理部と、前記第1の処理部及び第2の処理部が利用する記憶部と、を有する共有装置が行う不整合検出方法において、前記第1の処理部が前記第1のホストからの第1のメッセージの送信要求を受け取ると、前記第2の処理部に対してリクエストを送信し、当該リクエストを受信した前記第2の処理部が前記メッセージを前記第2のホストに送信すると共にリプライを前記第1の処理部に送信し、前記リプライを受け取った第1の処理部は当該リプライが前記第1のメッセージの送信要求に応じたリプライであるか否かを判断し、前記判断は、前記記憶部上で、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第1の処理部のブート及びリブートの回数を照らし合わせることにより行われることを特徴とする不整合検出方法。付記7付記6に記載の不整合検出方法において、前記判断に際して、前記リクエスト及び前記リプライにそれぞれ対応付けられた、前記第1の処理部のブート及びリブートの回数、が一致した場合には当該リプライが正当なものであると判断して前記第1のホストに対してリプライ処理を行い一致しなかった場合は当該リプライ正当なものでないと判断して当該リプライを廃棄することを特徴とする不整合検出方法。付記8付記6又は7に記載の不整合検出方法において、前記第1の処理部は前記リクエストを送信する際に前記記憶部に自身のブート及びリブートの回数を記録し、前記第2の処理部は前記リクエスト受け取るとともに前記記録されたブート及びリブートの回数を読み込んで自身が記憶し、前記第2の処理部は前記リプライを送信するとともに前記自身が記憶したブート及びリブートの回数を前記記憶部に記録し、前記1の処理部は自身が前記記憶部に記録したブート及びリブートの回数と前記第2の処理部が前記記憶部に記録したブート及びリブートの回数を比較することにより前記判断を行うことを特徴とする不整合検出方法。付記9付記6乃至8の何れか1に記載の不整合検出方法において、前記第1の処理部が第2の処理部としても動作し、前記第2の処理部が第1の処理部としても動作することを特徴とする不整合検出方法。付記10第1のホストに接続される第1の処理部と、第2のホストに接続される第2の処理部と、前記第1の処理部及び第2の処理部が利用する記憶部と、を有する共有装置並びに当該共有装置に接続された前記第1のホスト及び前記第2のホストを含んだクラスタシステムが行う不整合検出において、前記第1のホスト及び前記第2のホストは前記共有装置を介して通信を行い、前記共有装置は付記6乃至8の何れか1に記載の不整合検出方法を行うことを特徴とする不整合検出方法。