受信プログラム、送信プログラム、送受信システム、および送受信方法
【課題】高スループットだがデータの到達を保証しないプロトコルを使って、高スループットと高信頼性という利点を兼ね備えた通信を可能とする。
【解決手段】送信元コンピュータ１０１は、異なるパケット間の送信順序を示す送信順序情報１０４を管理し、同じ送信対象データ１０３に対しては同じ送信順序情報１０４を付加して二つのパケット１０５と１０６を作成し、それぞれ経路１０７と１０８を介して送信先コンピュータ１０２に送信する。送信先コンピュータ１０２は、過去に受信したパケットに含まれる送信順序情報にもとづいて、次に受信されると期待されるパケットに対応する順序を表す受信順序情報１１１を管理し、受信したパケット１０５または１０６から送信順序情報１０９または１１０を取得して受信順序情報１１１と比較し、比較の結果、パケットの重複や消失を判断する。
【解決手段】送信元コンピュータ１０１は、異なるパケット間の送信順序を示す送信順序情報１０４を管理し、同じ送信対象データ１０３に対しては同じ送信順序情報１０４を付加して二つのパケット１０５と１０６を作成し、それぞれ経路１０７と１０８を介して送信先コンピュータ１０２に送信する。送信先コンピュータ１０２は、過去に受信したパケットに含まれる送信順序情報にもとづいて、次に受信されると期待されるパケットに対応する順序を表す受信順序情報１１１を管理し、受信したパケット１０５または１０６から送信順序情報１０９または１１０を取得して受信順序情報１１１と比較し、比較の結果、パケットの重複や消失を判断する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データの到達を保証しないプロトコルによるデータの送信の信頼性を、送信経路を多重化することにより高める技術に関する。
【背景技術】
【０００２】
従来から、様々な分野でネットワークを介したデータの転送が行われている。データの転送は様々なプロトコルにしたがって行われるが、特に、ＴＣＰ（Transmission Control
Protocol）とＵＤＰ（User Datagram Protocol）は広く利用されているプロトコルである。ＴＣＰとＵＤＰはいずれもＯＳＩ（Open Systems Interconnection）参照モデルのトランスポート層（レイヤ４ともいう）のプロトコルであり、ネットワーク層（レイヤ３ともいう）のプロトコルであるＩＰ（Internet Protocol）と組み合わされて広く利用されている。
【０００３】
ＴＣＰとＵＤＰには以下のような違いがあるので、利用分野の性質に応じて、ＴＣＰとＵＤＰのうち適切な方のプロトコルが使われる。
・ＴＣＰは送信先までデータが到達することを保証するプロトコルだが、ＵＤＰはそのような保証をしないプロトコルである。
【０００４】
・送信にエラーが生じた場合、ＴＣＰによるデータ転送では自動的にパケットが再送されるが、ＵＤＰによるデータ転送では単にパケットが破棄されるだけである。
・ＴＣＰは実際の通信を開始する前にコネクションを確立するコネクション型のプロトコルだが、ＵＤＰはコネクションレス型のプロトコルである。
【０００５】
・以上のように、ＴＣＰはデータの送信自体以外の様々な処理が必要なのに対して、ＵＤＰはそのような処理を行わない。したがって、ＴＣＰによるデータ転送よりＵＤＰによるデータ転送の方が高速であり、スループットが高い。逆に言うと、ＴＣＰによるデータ転送は送達確認や再送制御をともなうため信頼性が高いが、ＵＤＰによるデータ転送は信頼性が低い。
【０００６】
ＴＣＰとＵＤＰのどちらのプロトコルを利用するかは、データの量、データを送信する目的、データの種類など、種々の要因を考慮に入れて決められる。一般には、信頼性を重視するアプリケーションではＴＣＰが利用され、処理速度を重視するアプリケーションではＵＤＰが利用されることが多い。しかし、高スループットと高信頼性を両立することが求められる場合もある。
【０００７】
例えば、フォールトトレラントなシステムでは、２台のコンピュータを組にして、一方をアクティブ（現用）装置、他方をスタンバイ（待機）装置として利用することがある。このような構成を採用すると、アクティブ装置に障害が発生しても、アクティブ装置とスタンバイ装置を切り換えることにより、外部にサービスを提供し続けることが可能である。つまり、このような構成により、サービスの可用性（アベイラビリティ）を高められる。
【０００８】
アクティブ装置とスタンバイ装置の切り換えを行うには、まず、アクティブ装置が保持するデータをスタンバイ装置に引き継ぎ、データを同期化する必要がある。アクティブ装置とスタンバイ装置がネットワークを介して接続されている場合、データの引き継ぎは、ネットワークを介したデータ転送をともなう。
【０００９】
サービスの可用性という観点からは、明らかに、アクティブ装置とスタンバイ装置の切り換えにかかる時間は短いほど好ましい。よって、データ同期化のためのデータ転送は、高速であることが望ましい。一方で、このような多重化されたシステムにおいては、現在のアクティブ装置が保持するデータが確実に現在のスタンバイ装置に引き継がれることも必要である。
【００１０】
このような例においては、高スループットというＵＤＰの利点と、ＴＣＰのような高信頼性を両立することが求められている。
ＵＤＰのようにデータの到達を保証しない通信プロトコルを使う場合に、信頼性を高める方法には、一般的に次の第一の方法と第二の方法がある。
【００１１】
第一の方法は、ＵＤＰなどの通信プロトコルを呼び出す上位層のソフトウェアにより、受信側ではデータパケットを受信したら送達確認パケットを返信するよう制御し、送信側では送達確認パケットが受信されなければデータパケットを再送するよう制御する方法である。これにより、通信プロトコル自体に送達確認や再送制御が組み込まれていなくても、送達確認と再送が実現され、信頼性が向上する。
【００１２】
しかし、この方法には、データ送信にエラーが生じると、再送までにある程度の待ち時間がかかってしまうという欠点がある。つまり、エラーの発生がスループットの低下に直結する。もともと、データの到達を保証しない通信プロトコルを使うのは、高スループットが要求される場合が多いので、このように明らかなスループットの低下をともなう方法は望ましくない。
【００１３】
第二の方法は、伝送路を多重化する方法である。すべての伝送路に同時に障害が生じる確率が、無視しても問題がない程度に低ければ、複数の異なる伝送路を介してそれぞれ同じデータを送信することにより、事実上、少なくとも一つの伝送路を介してデータが確実に送信先に届く。しかし、この方法の問題は、データの送信先、すなわち受信側から見ると、複数の伝送路から重複してデータが送られることである。
【００１４】
この問題を解決する一つの方法は、特許文献１と２に記載されているように、受信側の装置が、データを受信する伝送路を選択的に切り換えて、一つの伝送路だけからデータを受信する方法である。
【００１５】
特許文献１のバス型二重化伝送装置は、二つのバス型伝送路にそれぞれ接続された、二つの送信器と、二つの受信器と、二つの異常検出回路とを備える。異常検出回路は、それぞれの伝送路の異常を検出し、その出力は系切換制御回路に接続されている。データ送信時には、二つの送信器から二つのバス型伝送路に同じデータが送信される。データ受信時には、系切換制御回路が系選択器に正常な伝送路を選択させ、選択された伝送路に接続された受信器がデータを受信する。
【００１６】
特許文献２の二重化伝送路切換方式は、二重化された伝送路を介して互いに送受信する伝送装置が、送信時に二つの伝送路を同時に選択し、受信時には正常な一方の伝送路を選択する方式である。特許文献２の発明は、受信する伝送路の切換に伴って発生する次の１フレーム分のデータの棄却の割合、および、前回のフレームに対する診断では正常と診断されていたがフレーム外で異常が発生した伝送路を先着系と誤認する割合を低減することを目的としている。なお、先着系とは、二つの伝送路がともに正常な場合において先にデータを受信した系を指し、受信する伝送路として優先的に選択される。
【特許文献１】特開平８−１６３１５３号公報
【特許文献２】特開平８−２２３１８５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１７】
しかしながら、上記のとおり第一の方法には、データ送信にエラーが生じると、再送までにある程度の時間がかかってしまうという欠点がある。また、上記第二の方法では、伝送路を二重化した利点が十分に活かされないことがある。
【００１８】
例えば、実際には第一の伝送路に故障が発生しており、第二の伝送路は正常なのに、両者とも正常だと誤って判断されて、その結果、第一の伝送路が偶然、データを受信すべき伝送路として選択されることがありうる。このようなことは、伝送路の異常を検出する回路に故障が発生した場合や、伝送路が正常だと判断された直後に実際の故障が発生し、データが送信される場合などに起こりうる。
【００１９】
この例では、実際には第二の伝送路からは正常にデータが送信されているにもかかわらず、受信側の装置は、第二の伝送路がデータを受信すべき伝送路として選択していないため、正常なデータを受信することができない。つまり、第二の伝送路を介して送信された正常なデータを無駄に捨ててしまうことにより、データが正しく送信先に届く割合が低下している。
【００２０】
そこで本発明の目的は、高スループットだがデータの到達を保証しないプロトコルを使って、高スループットと高信頼性という利点を兼ね備えた通信を可能とすることであり、特に、スループットおよび／または信頼性が無駄に低下することを避けることである。
【課題を解決するための手段】
【００２１】
本発明による受信プログラムは、データの到達を保証しないプロトコルにより送信元コンピュータから複数の経路のそれぞれを介して、異なるパケット間の送信順序を示す送信順序情報を含めて送信された同内容のパケットを受信して、パケットの重複および消失を判別する処理を送信先コンピュータに制御させる。
【００２２】
前記受信プログラムは、前記複数の経路のいずれを介して送信された前記パケットでも受信する受信ステップと、受信した前記パケットから、前記送信順序情報を取得する送信順序情報取得ステップと、過去に受信した前記パケットの前記送信順序情報にもとづいて管理され、次に受信されると期待されるパケットに対応する順序を表す受信順序情報を、格納手段から取得する受信順序情報取得ステップと、前記送信順序情報が表す第一の順序と前記受信順序情報が表す第二の順序を比較する比較ステップと、前記第一の順序が前記第二の順序よりも前の場合に、前記受信ステップで受信した前記パケットが、過去に受信した他のパケットと重複すると判断する重複判断ステップと、前記第一の順序と前記第二の順序が等しい場合に、前記格納手段に格納された前記受信順序情報が表す順序が前記第二の順序の次の順序になるよう前記格納手段を更新する正常処理ステップと、前記第一の順序が前記第二の順序よりも後の場合に、パケットの消失が生じたと判断する消失判断ステップと、を前記送信先コンピュータに実行させる。
【００２３】
また、本発明による送信プログラムは、前記送信順序情報を格納手段から取得する送信順序情報取得ステップと、前記格納手段に格納されている前記送信順序情報を更新する送信順序情報更新ステップと、同じ前記送信順序情報および同じ送信対象のデータを含む、前記複数の経路のそれぞれに対応する複数のパケットを作成するパケット作成ステップと、前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記送信先コンピュータに送信する送信ステップと、を前記送信元コンピュータに実行させる。
【００２４】
パケットの送信先と送信元のコンピュータが、それぞれ前記受信プログラムと前記送信プログラムにしたがって動作することにより、少なくとも一つの経路が正常ならば、必ず
パケットが送信先コンピュータに届く。また、複数の経路が正常な場合、複数の同内容のパケットが送信先コンピュータに届くが、重複して届いたパケットは重複したと判断される。一方、送信先コンピュータは、パケットの順序が入れ替わって受信された場合や、複数の経路のすべてが異常でパケットが消失した場合など、送信された順序どおりにパケットを受信することができなかった場合を、上記消失判断ステップにより判別することができる。
【００２５】
本発明は、前記送信元コンピュータおよび前記送信先コンピュータを含むシステム、および前記送信元コンピュータが前記送信先コンピュータにパケットを送信する方法も提供する。
【発明の効果】
【００２６】
本発明によれば、少なくとも一つの経路が正常ならば必ずパケットが送信先コンピュータに届き、重複や消失を送信先コンピュータが判別することができるので、データの到達を保証しないプロトコルを利用していても信頼性が高い。
【００２７】
また、送信先コンピュータは、パケットを受信する経路を切り換えるのではなく、複数の経路のいずれを介して送信されたパケットでも受信する。つまり、送信先コンピュータに到達したパケットは漏れなく受信される。よって、切り換え処理のタイミングや切り換え処理の不具合が原因で信頼性が低下することはない。
【００２８】
データの到達を保証するための種々の処理を含まないプロトコルは、それら種々の処理を含む他のプロトコルに比べて、高スループットという特徴がある。本発明では、そのような高スループットのプロトコルを利用してパケットの送信が行われる。
【００２９】
また、一つの経路のみを利用し、その経路での送信が失敗したことを検知してから再送処理を行う方法では必然的に遅延時間が発生する。しかし、本発明では、一つの経路に異常が発生しても他の経路が正常ならば、特段の遅延時間を必要とせずに、パケットが送信先コンピュータに到達する。
【００３０】
すなわち、本発明によれば、データの到達を保証しないプロトコルを利用して、高信頼性と高スループットを両立させることができる。
【発明を実施するための最良の形態】
【００３１】
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。説明の順序は次のとおりである。まず、図１を参照して本発明の原理を説明した後、図２を参照して本発明を利用したシステムの構成を説明する。その後は、図２の実施形態を例にして、図３のデータ転送制御表、図４のスレッドの構成、図５のパケットの構成、図６〜図９のフローチャート、図１０〜図１３の処理シーケンス図について説明する。その後、本発明のプログラムを実行するコンピュータのブロック図である図１４について説明し、最後に、様々な変形例について説明する。
【００３２】
図１は、本発明の原理を示す図である。図１は、送信対象データ１０３が送信元コンピュータ１０１から送信先コンピュータ１０２に送信される流れを示している。
送信元コンピュータ１０１から送信先コンピュータ１０２に送信する対象のデータは、送信対象データ１０３である。送信元コンピュータ１０１と送信先コンピュータ１０２は複数の通信経路（以下、単に「経路」という）により接続されている。各経路は、有線、無線、またはその組み合わせによる経路である。図１には二つの経路１０７と１０８を図示してある。経路１０７と１０８を介した通信は、データの到達を保証しないプロトコルにより行われる。また、データはそのプロトコルで定義されたパケットの形式で送信され
る。プロトコルの例はＵＤＰである。
【００３３】
送信対象データ１０３が確実に送信先コンピュータ１０２に到達するという意味での信頼性を高めるために、送信元コンピュータ１０１は、複数の経路のそれぞれを介して、同じ送信対象データ１０３を含むパケット１０５と１０６を送信先コンピュータ１０２に送信する。
【００３４】
送信先コンピュータ１０２は、受信したパケットに含まれる送信対象データ１０３を利用して、実施形態に応じた処理を行う。しかし、単に送信元コンピュータ１０１が同内容のパケットを複数送信し、送信先コンピュータ１０２が同じ処理を重複して行うのでは、無駄が多い。よって、重複したパケットを受信した場合はそのパケットを破棄して無駄な処理を回避することが可能なように、送信先コンピュータ１０２に重複を判別させる必要がある。
【００３５】
また、ごくまれに、複数の経路のすべてに異常が同時に発生し、複数のパケットのすべてが消失（ロスト）することもある。経路の状態によっては、複数の異なるパケットが送信された順序とは違う順序で送信先コンピュータ１０２に到達することもある。
【００３６】
一般に、順序の入れ替わりと消失の判別には一定の待ち時間が必要である。例えば、パケットＡ、Ｂがこの順序で送信され、パケットＢがパケットＡよりも先に受信された場合、一定の時間内にパケットＡが受信されれば、順序の入れ替わりが発生したと判明する。そうでなければタイムアウトによりパケットＡが消失したと判断される。よって、順序の入れ替わりの判明にはパケットＢの受信からパケットＡの受信までの待ち時間が必要であり、順序の入れ替わりと消失を区別するにはさらに待ち時間が必要である。
【００３７】
一方、本発明は高信頼性と高スループットの両立を目的としている。高スループットは、処理が速いことの結果得られる特徴である。したがって、以下では、待ち時間を減らして処理を高速化するために、順序の入れ替わりと消失を区別せず、順序の入れ替わりも消失の一種と見なして処理する方法について説明する。
【００３８】
以上のことを考慮して、送信先コンピュータ１０２がパケットの重複や消失を判別することができるように、図１のシステムは構成されている。具体的には、送信元コンピュータ１０１が送信順序情報１０４を管理して、パケット１０５と１０６に送信順序情報１０４を含めて送信先コンピュータ１０２に送信する。送信先コンピュータ１０２は、受信順序情報１１１を管理し、受信したパケット１０５または１０６から送信順序情報１０９または１１０を取得し、取得した送信順序情報１０９または１１０と受信順序情報１１１が表す順序とを比較する。比較の結果、パケットの重複や消失が判断される。なお、送信順序情報１０９と１１０の内容は送信順序情報１０４と同じである。
【００３９】
図１には送信対象データ１０３を表すブロックを一つだけ示したが、実際の環境では、送信元コンピュータ１０１から送信先コンピュータ１０２に、様々なデータに対応する様々なパケットを順々に送信するのが一般的である。送信順序情報１０４は、そのような異なるパケット間の送信順序を示す情報であり、例えば番号を含む。その番号の大小により、送信順序の前後が示される。送信順序情報１０４は、送信元コンピュータ１０１が備える不図示の格納部に格納されており、送信元コンピュータ１０１が備える不図示の送信順序情報更新部により読み取られ、更新される。例えば、格納部はＲＡＭ（Random Access Memory）により実現され、送信順序情報更新部は本発明による送信プログラムを実行するＣＰＵ（Central Processing Unit）により実現される。
【００４０】
送信元コンピュータ１０１が備える不図示のパケット作成部は、同じ送信対象データ１
０３に対しては同じ送信順序情報１０４を付加して、二つのパケット１０５と１０６を作成する。送信元コンピュータ１０１が備える不図示の送信部は、パケット１０５と１０６をそれぞれ経路１０７と１０８を介して送信先コンピュータ１０２に送信する。例えば、パケット作成部は本発明による送信プログラムを実行するＣＰＵにより実現され、送信部はそのＣＰＵと通信インターフェイスにより実現される。
【００４１】
二つの経路がともに正常なら、送信先コンピュータ１０２の不図示の受信部はパケット１０５と１０６を正常に受信する。送信先コンピュータ１０２の不図示の比較判断部は、パケット１０５をパケット１０６より早く受信した場合は、パケット１０６を重複したパケットだと判断する。逆に、パケット１０６をパケット１０５より早く受信した場合は、比較判断部は、パケット１０５を重複したパケットだと判断する。例えば、受信部は本発明の受信プログラムを実行するＣＰＵと通信インターフェイスにより実現され、比較判断部も同じＣＰＵにより実現される。
【００４２】
このようにパケットの重複を判別することができるのは、送信先コンピュータ１０２が受信順序情報１１１を管理しているためである。受信順序情報１１１は、送信先コンピュータ１０２が過去に受信したパケットに含まれる送信順序情報にもとづいて管理され、送信先コンピュータ１０２が備える不図示の格納部に格納されている。格納部は例えばＲＡＭである。受信順序情報１１１は、次に受信されると期待されるパケットに対応する順序を表す。
【００４３】
送信順序情報１０４と受信順序情報１１１について、理解を容易にするため、簡単な例で説明する。送信順序情報１０４は昇順で順序を表す番号を含み、その番号により順序が表される。つまり、この例では、「１」が表す順序の次の順序は「２」により表され、「２」が表す順序の次の順序は「３」により表される。
【００４４】
送信元コンピュータ１０１から送信先コンピュータ１０２に送信されるデータのうち、送信対象データ１０３は「２」が表す順序に対応すると仮定する。また、「１」が表す順序に対応する別のパケットは、既に送信先コンピュータ１０２に正常に送信されており、パケット１０５がパケット１０６よりも先に受信されたと仮定する。
【００４５】
送信順序情報１０４が「２」という番号を含む場合、送信先コンピュータ１０２の比較判断部は受信したパケット１０５と１０６からそれぞれ、「２」という番号を含む送信順序情報１０９と１１０を取得することができる。また、送信先コンピュータ１０２は「１」が表す順序に対応する別のパケットを過去に受信済みなので、パケット１０５を受信した時点では、次に「２」が表す順序に対応するパケットが受信されることを期待している。この期待している順序を表す情報が受信順序情報１１１である。受信順序情報１１１も送信順序情報１０４と同様に昇順で順序を表す番号を含んでいてもよい。例えば、この時点における受信順序情報１１１は、「２」という番号を含んでもよい。
【００４６】
以上の仮定のもとで送信先コンピュータ１０２の受信部がパケット１０５を受信すると、パケット１０５から取得した送信順序情報１０９が表す順序と受信順序情報１１１が表す順序が等しい。このことは、期待していたとおりの順序に対応するパケットが正常に受信されたことを表す。よって、送信先コンピュータ１０２は、パケット１０５に含まれる送信対象データ１０３を利用して、実施形態に応じた必要な処理を行う。また、パケット１０５の受信により、次に受信されると期待されるパケットに対応する順序は一つ後ろにずれ、「３」により表される順序となる。よって、送信先コンピュータ１０２の不図示の正常処理部は、受信順序情報１１１が含む番号を「３」に更新する。例えば、正常処理部は本発明の受信プログラムを実行するＣＰＵにより実現される。
【００４７】
その後、送信先コンピュータ１０２の受信部はパケット１０６を受信する。パケット１０６から取得される送信順序情報１１０は「２」という番号を含み、上記で更新された受信順序情報１１１は「３」という番号を含む。つまり、送信順序情報１１０の方が受信順序情報１１１よりも早い順序を表す。したがって、パケット１０６は過去に受信した他のパケットと重複していると送信先コンピュータ１０２の比較判断部が判断する。実際、パケット１０６は、パケット１０５と同じ送信対象データ１０３および同じ送信順序情報１０４を含んでおり、パケット１０５と重複している。送信先コンピュータ１０２において、重複していると判断されたパケット１０６が含む送信対象データ１０３は利用されず、破棄される。それにより、同じデータに対して無駄に重複して同じ処理を行う時間をなくしている。
【００４８】
次に、パケットの消失について、上記とは一部仮定を変えて説明する。まず、「１」が表す順序に対応するパケットを送信先コンピュータ１０２が正常に受信済みであり、「２」が表す順序に対応するパケットは、経路１０７と１０８の双方で消失したと仮定する。この段階で、送信先コンピュータ１０２が次に受信すると期待しているパケットは「２」が表す順序に対応するから、受信順序情報１１１は「２」という番号を含む。
【００４９】
その後、「３」が表す順序に対応して、送信元コンピュータ１０１は、「３」という番号を含む送信順序情報１０４と送信対象データ１０３とを含むパケット１０５と１０６を作成し、経路１０７と経路１０８のそれぞれを介して送信先コンピュータ１０２に送信する。以下では、パケット１０５がパケット１０６よりも先に受信されたと仮定する。
【００５０】
すると、送信先コンピュータ１０２の比較判断部は、パケット１０５から送信順序情報１０９を取得する。そして、送信順序情報１０９が含む「３」という番号は、受信順序情報１１１が含む「２」という番号よりも後の順序であることから、送信先コンピュータ１０２の比較判断部は、パケットの消失が生じたと判断することができる。
【００５１】
図２は、本発明を利用してデータの同期化を行う二重化システムの構成図である。図２の二重化システムは、同様の構成を有する二つのコンピュータ２０１と２０２を組にして、一方をアクティブ装置、他方をスタンバイ装置として運用するシステムである。アクティブ装置に故障が発生した場合や、アクティブ装置のハードウェアを交換する必要がある場合などには、アクティブ装置とスタンバイ装置が切り換えられる。このようにシステムを二重化することにより、システムはフォールトトレラントなものとなり、サービスの可用性が向上する。
【００５２】
以下では、アクティブ装置とスタンバイ装置の切換に必要なデータの同期化のために、ＵＤＰによるデータ転送が行われる場合を例に説明する。本発明を利用することにより、図２のシステムにおいてデータの即時的な同期化が可能となる。なお、以下では特に断らない限り、「パケット」という語はＵＤＰパケットを意味する。
【００５３】
図２は、左側に示したコンピュータ２０１がアクティブ装置として運用され、右側に示したコンピュータ２０２がスタンバイ装置として運用されている状態を表している。なお、「アクティブ装置」と「スタンバイ装置」という呼び方は相対的であり、切り換えが生じれば逆転する。しかし、以下では特に断らない限り、図２の状態を前提とし、これら2台のコンピュータを単に「アクティブ装置２０１」および「スタンバイ装置２０２」と表現する。２台のコンピュータのどちらをアクティブ装置として運用している状態であるかに関わらず、コンピュータ自体を識別する必要がある場合にのみ、２台のコンピュータを「コンピュータ２０１」および「コンピュータ２０２」と表現する。
【００５４】
アクティブ装置２０１は一般的なコンピュータであり、スタンバイ装置２０２と同期化
すべきデータが格納される共有メモリ２０５と、不図示のＣＰＵとを備える。共有メモリ２０５はＲＡＭなどの揮発性メモリであり、ハードディスクなどの不揮発性領域に比べてアクセス速度が格段に速い。なお、同期化の処理自体に必要なデータを格納する不図示の他のメモリ領域もコンピュータ２０１は備えている。その領域を以下では「制御用データ領域」と呼ぶ。本実施形態では、コンピュータ２０１が備えるＲＡＭの一部が共有メモリ２０５として利用され、その残りが制御用データ領域として利用される。制御用データ領域には、図１の送信順序情報１０４や受信順序情報１１１が格納される。スタンバイ装置２０２も共有メモリ２０６と不図示のＣＰＵを備え、アクティブ装置２０１と同様に構成されている。
【００５５】
図２のシステムは、アクティブ装置２０１とスタンバイ装置２０２の切換時間を短縮するために、共有メモリ２０５と２０６に格納されたデータを即時的に同期化する。本実施形態では、同期化にかかるわずかな時間を除き、共有メモリ２０５と２０６は常に同じデータを格納した状態である。よって、仮想的には、アクティブ装置２０１とスタンバイ装置２０２が一つのメモリ領域を共有していると見なすこともできる。そのため、共有メモリ２０５と２０６をまとめて仮想共有メモリ２０３と表している。また、共有メモリ２０５と２０６の名称に「共有」という語がつくのは、仮想共有メモリ２０３の構成要素であるためである。
【００５６】
アクティブ装置２０１の不図示のＣＰＵにより、一つ以上のユーザアプリケーション２０７が実行されている。なお、各種の処理を実行するのは正確にはＣＰＵだが、以下では表記の簡略化のため、「ユーザアプリケーション２０７が処理を実行する」などの表現することがある。
【００５７】
アクティブ装置２０１には、ＯＳ（Operating System）に加えて、ＯＳとユーザアプリケーション２０７を仲介する種々のミドルウェアからなるミドルウェア群２１１がインストールされている。ミドルウェア群２１１に含まれるミドルウェアの一つが、ＵＤＰを使ったデータの同期化を制御する。図２ではそのミドルウェアを、共有メモリ制御部２１３という機能的なブロックで表している。共有メモリ制御部２１３を実現するミドルウェアは、本実施形態における本発明の送信プログラムおよび受信プログラムを含む。
【００５８】
アクティブ装置２０１とスタンバイ装置２０２は同様の構成を備えている。すなわち、スタンバイ装置２０２にもＯＳとミドルウェア群２１２がインストールされており、ミドルウェア群２１２は共有メモリ制御部２１４を含む。なお、ユーザアプリケーション２０７と同様のユーザアプリケーションがスタンバイ装置２０２にもインストールされているが、スタンバイ状態においては実行されていないので、図示していない。
【００５９】
ユーザアプリケーション２０７の実行は、一般に、共有メモリ２０５のデータの変更をともなう。よって、共有メモリ２０５と２０６の同期を保つために、本実施形態では、共有メモリ２０５のデータが変更されるたびに、必ずスタンバイ装置２０２の共有メモリ２０６にその変更が反映される。共有メモリ２０５や２０６のような揮発性メモリ領域へのアクセスは、ハードディスクなどの不揮発性領域へのアクセスに比べて高速なので、その反映は高速に行うことが可能である。また、その反映のためにアクティブ装置２０１とスタンバイ装置２０２の間で行われるデータ送信は、本発明を利用することにより、スループットと信頼性がともに高い。高スループットは、換言すれば、処理が高速であることを意味する。結局、共有メモリ２０５と２０６は、非常に迅速に同期化される。
【００６０】
共有メモリ２０５と２０６の同期化には、アクティブ装置２０１とスタンバイ装置２０２の間の複数の通信路が利用される。本実施形態における通信路の数は２であり、以下では二つの通信路を第一経路２１５および第二経路２１６と呼ぶ。また、本実施形態で使わ
れる通信プロトコルはＵＤＰである。ＵＤＰによる通信機能は一般にＯＳにより提供されるので、ＯＳの上位のミドルウェアにより実現される共有メモリ制御部２１３および２１４は、ＵＤＰを利用して第一経路２１５または第二経路２１６を介した通信を行うことができる。
【００６１】
図２において、ユーザアプリケーション２０７がデータ２０９を共有メモリ２０５に書き込む操作を「（１）Ｗｒｉｔｅ」と表記し、ユーザアプリケーション２０７から共有メモリ２０５への矢印により表した。
【００６２】
この書き込み操作の後、ユーザアプリケーション２０７は共有メモリ制御部２１３を呼び出し、共有メモリ２０５と２０６を同期化させる。この同期化の操作を図２では「（２）Ｃｏｍｍｉｔ」と表記した。また、同期化が終了するまでユーザアプリケーション２０７が待つことを図２では「（３）Ｗａｉｔ」と表記した。
【００６３】
図２の「（２）Ｃｏｍｍｉｔ」から「（３）Ｗａｉｔ」までの処理の流れを、矢印に沿って説明すれば次のごとくである。
まず、ユーザアプリケーション２０７から点Ａまでの線に示すように、ユーザアプリケーション２０７は、（１）の書き込み操作で共有メモリ２０５に書き込んだデータ２０９と同じデータを共有メモリ制御部２１３に与える。矢印は点Ａで二つに分岐し、一方は第一経路２１５を介して点Ｂへ進み、他方は第二経路２１６を介して点Ｄに進む。この分岐は、共有メモリ制御部２１３が、データ２０９を含むパケットを二つの経路のそれぞれを介してスタンバイ装置２０２に送信することを表す。
【００６４】
二つの経路を介して送信されたパケットは、いずれも、スタンバイ装置２０２の共有メモリ制御部２１４が受信する。図２では、第一経路２１５を介して送信されたパケットの方が、第二経路２１６を介して送信されたパケットよりも早く受信されたと仮定している。前者の受信は点Ｂに対応し、後者の受信は点Ｄに対応する。点Ｂでは、矢印が二つに分岐し、後続の処理に続くことを示している。
【００６５】
一方、点Ｄは矢印の終点である。点Ｄが終点であることは、第二経路２１６を介して受信したパケットが破棄されることに対応する。破棄されるのは、既に第一経路２１５を介して受信したパケットと重複するパケットだと共有メモリ制御部２１４により判断されるためである。
【００６６】
点Ｂで分岐した一方の矢印は、共有メモリ２０６内のデータ２１０を指している。これは、共有メモリ制御部２１４が、受信したデータを共有メモリ２０６に書き込むことを表す。
【００６７】
点Ｂで分岐した他方の矢印は、点Ｃに進み、点Ｃでさらに二つに分岐している。点Ｃは、共有メモリ制御部２１４がアクティブ装置２０１に処理結果を伝えるメッセージ、具体的には後述のＡＣＫパケットを送信することに対応する。点Ｃでの分岐は、ＡＣＫパケットが第一経路２１５と第二経路２１６のそれぞれを介して送られることを表す。
【００６８】
図２では、第二経路２１６を介して送信されたＡＣＫパケットの方が、第一経路２１５を介して送信されたＡＣＫパケットよりも早く受信されたと仮定している。前者は、点Ｃで分岐して第二経路２１６と共有メモリ制御部２１３を通り、ユーザアプリケーション２０７で終わる矢印に対応し、後者は、点Ｃで分岐して第一経路２１５を通り点Ｅで終わる矢印に対応する。つまり、共有メモリ制御部２１３からユーザアプリケーション２０７への通知は、先に共有メモリ制御部２１３で受信された一方のＡＣＫパケットにのみもとづいてなされる。ユーザアプリケーション２０７はその通知をもって共有メモリ２０５と２
０６の同期化が終了したことを検知し、（３）の待ち状態から脱する。
【００６９】
点Ｅは、他方のＡＣＫパケットが後で共有メモリ制御部２１３に受信されることに対応する。つまり、点Ｅは、データ２０９の同期化に関する応答であるＡＣＫパケットを、第二経路２１６から受信した後の時点に対応しているので、点Ｅで二度目に受信したＡＣＫパケットは不要である。よって、共有メモリ制御部２１３はこの不要なＡＣＫパケットを無視する。
【００７０】
以上のようにして、ユーザアプリケーション２０７がデータ２０９を共有メモリ２０５に書き込むたびに、同じ内容のデータ２１０が共有メモリ２０６にも書き込まれ、共有メモリ２０５と２０６が同期化される。
【００７１】
また、この同期化に使われる通信プロトコルはＵＤＰなので、同期化のためのデータ送信にかかる時間は、ＴＣＰを使う場合に比べて短時間である。一方で、第一経路２１５と第二経路２１６という二つの異なる経路に同時に故障が発生することはほとんどないので、ほぼ確実に、データの同期化を達成することができる。
【００７２】
また、第一経路２１５と第二経路２１６のうち一方に故障が発生しても、正常な経路を介して正常に受信されたデータを共有メモリ制御部２１４が共有メモリ２０６に書き込むことにより同期化が達成される。つまり、各経路を介した送信にかかる時間のばらつきが極端に大きくなければ、たとえ一方の経路に故障が発生しても、両経路とも正常な場合の同期化のタイミングに比べて同期化のタイミングが大きく遅れることはない。この点も、データの同期化が高速であるという特徴に寄与している。
【００７３】
次に、図３を参照して、図２のコンピュータ２０１と２０２がそれぞれ管理するデータ転送制御表３０１と３０２の例を説明する。図３に示すように、データ転送制御表３０１と３０２は、同じ形式であり、それぞれ例えばＲＡＭ上の制御用データ領域に格納されている。
【００７４】
データ転送制御表３０１と３０２の内容は、コンピュータ２０１と２０２のどちらがアクティブ装置として運用されているかに関係ない。つまり、データ転送制御表３０１と３０２は、図２の状態を前提としていない。よって、図３の説明においては、「アクティブ装置２０１」と「スタンバイ装置２０２」ではなく、「コンピュータ２０１」と「コンピュータ２０２」と表現する。
【００７５】
データ転送制御表３０１は、第一経路２１５と第二経路２１６についてそれぞれ、「自分のＩＰアドレス」、「通信相手のＩＰアドレス」、「自分のポート番号」、「通信相手のポート番号」、「状態」というフィールドを有している。データ転送制御表３０２も同様の形式である。
【００７６】
ＵＤＰを用いた通信では、送信先と送信元が、ＩＰアドレスとポート番号の組であるソケットアドレスにより表される。よって、第一経路２１５のコンピュータ２０１側の端点は、データ転送制御表３０１の「自分のＩＰアドレス」と「自分のポート番号」を組にした「１９２．１６８．１．１００：６１００」である。このソケットアドレスは、データ転送制御表３０２では逆に、「通信相手のＩＰアドレス」と「通信相手のポート番号」の組により表される。
【００７７】
一方、第一経路２１５のコンピュータ２０２側の端点は、データ転送制御表３０１の「通信相手のＩＰアドレス」と「通信相手のポート番号」を組にした「１９２．１６８．１．２００：６２００」である。このソケットアドレスは、データ転送制御表３０２では「
自分のＩＰアドレス」と「自分のポート番号」の組により表される。
【００７８】
データ転送制御表３０１と３０２の「状態」は、「正常」または「異常」という値を取る。データ転送制御表３０１の「状態」の値は、第一経路２１５と第二経路２１６の監視結果に応じて、動的に書き換えられる。データ転送制御表３０２についても同様である。
【００７９】
図３の例では、第一経路２１５が「１９２．１６８．１．１００：６１００」と「１９２．１６８．１．２００：６２００」という二つのソケットアドレスにより定義され、第二経路２１６が「１０．１．１．１００：７１００」と「１０．１．１．２００：７２００」という二つのソケットアドレスにより定義されている。つまり、第一経路２１５と第二経路２１６では、ＩＰアドレスもポート番号も異なる。
【００８０】
例えば、コンピュータ２０１に２枚のＮＩＣ（Network Interface Card）を取り付け、それぞれのＮＩＣに別のＩＰアドレスを割り当てることにより、図３の例のように、１台のコンピュータ２０１に異なる二つのＩＰアドレスを割り当てることが可能である。さらに、第一経路２１５と第二経路２１６は、ケーブルなどの物理的な媒体も異なることが望ましい。
【００８１】
なお、実施形態によっては、例えば、第一経路２１５または第二経路２１６のコンピュータ２０１側のＩＰアドレスが同じであってもよい。たとえＩＰアドレスが同じでも、異なるポート番号を用いることにより、二つの経路を区別することができるからである。
【００８２】
また、図３のような設定であっても、経路の物理的な媒体自体は、第一経路２１５と第二経路２１６が共有することも可能である。例えば、コンピュータ２０１と２０２が、１台のスイッチングハブを介して接続され、コンピュータ２０１とスイッチングハブの間およびコンピュータ２０２とスイッチングハブの間はそれぞれ１本のケーブルで接続されていてもよい。ただし、このように複数の経路が物理的な媒体を共有すると、一つの媒体のトラフィック量が多くなるために、データの衝突（コリジョン）などが発生しやすくなり、結果的に全体的な処理速度の低下を招くことがある。よって、異なる経路は異なる物理的媒体により実現することが望ましい。
【００８３】
図４は、共有メモリ制御部２１３と２１４を実現するミドルウェアを構成するスレッドのブロック図である。図２に示したように、本実施形態では、コンピュータ２０１と２０２が同様の構成を備え、アクティブ装置とスタンバイ装置は切り換え可能である。したがって、共有メモリ制御部２１３には、コンピュータ２０１がアクティブ装置として運用される場合のために、データをコンピュータ２０２に送信する機能が必要であり、コンピュータ２０１がスタンバイ装置として運用される場合のために、データをコンピュータ２０２から受信して共有メモリ２０５に反映する機能が必要である。共有メモリ制御部２１４も共有メモリ制御部２１３と同様である。
【００８４】
具体的には、共有メモリ制御部２１３と２１４はそれぞれ、ＵＤＰポート４１１と４１２を介して第一経路２１５へのデータ送信および第一経路２１５からのデータ受信が可能なように構成されている。また、共有メモリ制御部２１３と２１４はそれぞれ、ＵＤＰポート４１３と４１４を介して第二経路２１６へのデータ送信および第二経路２１６からのデータ受信が可能なようにも構成されている。
【００８５】
共有メモリ制御部２１３と２１４を実現するミドルウェアは、図４の実施形態ではマルチスレッド・プログラムである。具体的には、コンピュータ２０１の不図示のＣＰＵがヘルスチェックスレッド４０１、データ送信スレッド４０３、データ受信スレッド４０５、第一経路受信スレッド４０７、および第二経路受信スレッド４０９を実行することにより
共有メモリ制御部２１３が実現される。同様に、コンピュータ２０２の不図示のＣＰＵがヘルスチェックスレッド４０２、データ送信スレッド４０４、データ受信スレッド４０６、第一経路受信スレッド４０８、および第二経路受信スレッド４１０を実行することにより、共有メモリ制御部２１４が実現される。
【００８６】
以下では共有メモリ制御部２１３について説明するが、共有メモリ制御部２１４でも同様である。
ヘルスチェックスレッド４０１は、第一経路２１５と第二経路２１６の状態を監視する。具体的には、ヘルスチェックスレッド４０１は、一定間隔でコンピュータ２０２から送信される、経路の状態を監視するためのパケットの受信間隔にもとづいて、経路の状態を判断する。その監視用のパケットを以下では「ヘルスチェックパケット」と呼び、具体的な形式は図５とあわせて後述する。
【００８７】
コンピュータ２０２からヘルスチェックパケットが送信される間隔ｈ１は予め決められており、例えばｈ１＝１秒である。コンピュータ２０２から第一経路２１５を介して送信されたヘルスチェックパケットは、第一経路受信スレッド４０７により受信される。第一経路受信スレッド４０７は、ヘルスチェックパケットを受信すると、ヘルスチェックパケットの受信をヘルスチェックスレッド４０１に通知する。
【００８８】
ヘルスチェックスレッド４０１は、第一経路受信スレッド４０７からの今回の通知と、前回の通知との間隔ｈを調べる。その間隔ｈが規定時間ｈ２以内であれば、ヘルスチェックスレッド４０１はデータ転送制御表３０１の「第一経路」レコードの「状態」フィールドの値を「正常」に設定し、そうでなければ「異常」に設定する。規定時間ｈ２は、経路の状態を正常と見なしうる許容範囲を示す値で、予め決められたヘルスチェックパケットの送信間隔ｈ１よりも少しだけ大きな値である。送信間隔ｈ１と規定時間ｈ２は、実験等から適切な値を定めることが望ましい。
【００８９】
第二経路２１６についても同様にして、ヘルスチェックスレッド４０１が状態を監視し、その監視の結果をデータ転送制御表３０１に反映する。
コンピュータ２０２において、コンピュータ２０１にヘルスチェックパケットを送信するのは、具体的にはヘルスチェックスレッド４０２である。ヘルスチェックスレッド４０２は、第一経路２１５と第二経路２１６のそれぞれについて、データ転送制御表３０２を参照して「通信相手のＩＰアドレス」と「通信相手のポート番号」宛てのヘルスチェックパケットを生成する。ヘルスチェックスレッド４０２は、第一経路２１５へはＵＤＰポート４１２から、第二経路２１６へはＵＤＰポート４１４から、生成したヘルスチェックパケットを送出する。
【００９０】
また、ヘルスチェックスレッド４０２も、上記と同様の方法で第一経路２１５と第二経路２１６の状態を監視し、データ転送制御表３０２の「状態」フィールドの値を動的に設定している。そして、ヘルスチェックスレッド４０１も、ヘルスチェックスレッド４０２が第一経路２１５と第二経路２１６の状態を監視することができるように、送信間隔ｈ１でヘルスチェックパケットをコンピュータ２０２に二つの経路を介して送信している。
【００９１】
すなわち、本実施形態では、コンピュータ２０１と２０２のどちらがアクティブ装置であるかに関わらず、ヘルスチェックスレッド４０１と４０２は両方とも、ヘルスチェックパケットの送信、およびヘルスチェックパケットの受信間隔ｈにもとづく経路の状態の監視を行っている。
【００９２】
データ送信スレッド４０３は、コンピュータ２０１がアクティブ装置として運用されているとき、送信対象のデータ、すなわち共有メモリ２０５に書き込まれたデータ２０９を
、スタンバイ装置として運用されているコンピュータ２０２へ送信する。データ２０９は図１の送信対象データ１０３に相当する。データ２０９はＵＤＰパケットの形式で送信される。そのＵＤＰパケットを以下では「共有メモリデータパケット」と呼び、形式は図５とあわせて後述する。共有メモリデータパケットは、図１のパケット１０５と１０６に相当する。
【００９３】
また、データ送信スレッド４０３は、コンピュータ２０１がスタンバイ装置として運用されているとき、アクティブ装置として運用されているコンピュータ２０２から送信されたパケットに対する送達確認をコンピュータ２０２へ送信する。この送達確認も、具体的にはＵＤＰパケットの一種であり、以下では「ＡＣＫパケット」と呼ぶ。ＡＣＫパケットの形式の詳細は図５とあわせて後述する。
【００９４】
いずれの場合も、データ送信スレッド４０３は、送信すべきＵＤＰパケット、より正確には、そのＵＤＰパケットをカプセル化して得られるＩＰパケットを生成する。その生成に際して、データ送信スレッド４０３は、データ転送制御表３０１を参照して送信元と送信先のＩＰアドレスおよびポート番号を設定する。また、データ送信スレッド４０３はデータ転送制御表３０１を参照して、「状態」フィールドの値が「正常」である経路だけから生成したパケットを送信する。
【００９５】
共有メモリ制御部２１４におけるデータ送信スレッド４０４も、データ送信スレッド４０３と同様である。
データ受信スレッド４０５は、第一経路受信スレッド４０７および第二経路受信スレッド４０９が受信したデータを適宜処理する。具体的には、データ受信スレッド４０５は、コンピュータ２０１がアクティブ装置として運用されているか否かによらず、コンピュータ２０２から送られた各種の制御用パケットを処理する。また、コンピュータ２０１がスタンバイ装置として運用されているとき、データ受信スレッド４０５はさらに、共有メモリデータパケットを処理する。その処理は、共有メモリデータパケットの重複や消失を判断すること、重複していない共有メモリデータパケットの内容を共有メモリ２０５に反映すること、必要に応じてＡＣＫパケットを送信するようデータ送信スレッド４０３に要求すること、を含む。
【００９６】
第一経路受信スレッド４０７は、データ転送制御表３０１の「第一経路」レコードの「自分のＩＰアドレス」と「自分のポート番号」の値が宛先に指定されたパケットを待ち合わせる。つまり、第一経路受信スレッド４０７は、第一経路２１５を介してＵＤＰポート４１１にパケットが送信されるのを常に監視し、送信されたパケットを受信する。そして、第一経路受信スレッド４０７は、受信したパケットがヘルスチェックパケットか否かを判断し、ヘルスチェックパケットならヘルスチェックスレッド４０１にヘルスチェックパケットの受信を通知し、そうでなければ受信したパケットの処理をデータ受信スレッド４０５に要求する。
【００９７】
第二経路受信スレッド４０９も同様に、データ転送制御表３０１の「第二経路」レコードの「自分のＩＰアドレス」と「自分のポート番号」の値が宛先に指定されたパケットを待ち合わせる。そして、第二経路受信スレッド４０９は、受信したパケットがヘルスチェックパケットか否かを判断し、ヘルスチェックパケットならヘルスチェックスレッド４０１にヘルスチェックパケットの受信を通知し、そうでなければ受信したパケットの処理をデータ受信スレッド４０５に要求する。
【００９８】
共有メモリ制御部２１４におけるデータ受信スレッド４０６、第一経路受信スレッド４０８、および第二経路受信スレッド４１０も、上記と同様である。
なお、受信に関してはデータ受信スレッド４０５と第一経路受信スレッド４０７と第二
経路受信スレッド４０９の三つがあるのに対し、送信に関してはデータ送信スレッド４０３のみである理由は、図３がスレッドを示す図だからである。パケットはいつ受信されるかが不明なため、本実施例では、常にＵＤＰポート４１１を監視する第一経路受信スレッド４０７と、常にＵＤＰポート４１３を監視する第二経路受信スレッド４０９と、受信したパケットに関する実質的な処理を行うデータ受信スレッド４０５を分けてある。一方、パケットを送信する場合は、送信のタイミング、送信元のＵＤＰポート、送信するパケットの種別はすべてデータ送信スレッド４０３が把握している。よって、データ送信スレッド４０３だけで、送信すべきパケットの生成から実際の送信までを行うことが容易でもあり自然でもある。
【００９９】
次に、図５を参照して、本実施形態において利用される各種パケットの形式を説明する。上記のとおり、本実施形態では通信プロトコルとしてＵＤＰが利用される。また、周知のように、ＵＤＰパケットはＵＤＰヘッダとオプションのペイロード部分からなり、ＵＤＰヘッダは送信元と送信先のポート番号を含む。図５に示した五種のパケットは、いずれもＵＤＰパケットであり、本実施形態に特有の独自のフィールドをペイロード部分に有する。それらの独自のフィールドの値によって、図５に示した五種のパケットは判別される。
【０１００】
具体的には、ヘルスチェックパケット５０１は、ペイロード部に「ＴＹＰＥ１」というフィールドのみを含み、その値は括弧内に示したように、本実施形態では「１」である。リフレッシュ要求パケット５０２とリフレッシュ応答パケット５０３は、ペイロード部に「ＴＹＰＥ１」と「ＴＹＰＥ２」と「リフレッシュＩＤ」という三つのフィールドを含む。リフレッシュ要求パケット５０２とリフレッシュ応答パケット５０３の役割については後述する。共有メモリデータパケット５０４は、ペイロード部に「ＴＹＰＥ１」と「ＴＹＰＥ２」と「リフレッシュＩＤ」と「通番」と「共有メモリデータ」という五つのフィールドを含む。ＡＣＫパケット５０５は、ペイロード部に「ＴＹＰＥ１」と「ＴＹＰＥ２」と「リフレッシュＩＤ」と「通番」という四つのフィールドを含む。各フィールドの長さは、実施形態に応じて適宜決めてよい。
【０１０１】
ＴＹＰＥ１とＴＹＰＥ２は、パケットの種別を示すフィールドである。ＴＹＰＥ１が上位の分類を表し、ＴＹＰＥ２が下位の分類を表す。図５では値の例を括弧の中に示したが、その値の例からも分かるように、五種のパケットは、ＴＹＰＥ１フィールドの値によりヘルスチェックパケット５０１とそれ以外のものの二種類に分類される。後者はさらに、ＴＹＰＥ２フィールドの値によって、四種類に分類される。
【０１０２】
図４の第一経路受信スレッドまたは第二経路受信スレッド４０７〜４１０は、ＵＤＰヘッダとＴＹＰＥ１フィールドのみをチェックする。ＵＤＰヘッダが適切であり、ＴＹＰＥ１フィールドの値が１なら、第一経路受信スレッドまたは第二経路受信スレッド４０７〜４１０は、受信したパケットがヘルスチェックパケット５０１であると判断し、ヘルスチェックパケット５０１の受信をヘルスチェックスレッド４０１または４０２に通知する。
【０１０３】
一方、ＵＤＰヘッダが適切であり、ＴＹＰＥ１フィールドの値が２なら、第一経路受信スレッドまたは第二経路受信スレッド４０７〜４１０は、受信したパケットがヘルスチェックパケット５０１以外であると判断し、受信したパケットの処理をデータ受信スレッド４０５または４０６に要求する。データ受信スレッド４０５と４０６は、ヘルスチェックパケット５０１以外の種別のパケットのみを処理する。データ受信スレッド４０５と４０６は、ＴＹＰＥ２フィールドの値にもとづいてパケットの種別を判別し、パケットの種別に応じた処理を行う。
【０１０４】
リフレッシュＩＤフィールドと通番フィールドの値は、データ送信スレッド４０３また
は４０４により設定される。この二つのフィールドの値を組み合わせた情報が、図１の送信順序情報１０４に相当する。
【０１０５】
共有メモリデータフィールドは、共有メモリデータパケット５０４にのみ含まれる。図５では、図２のように共有メモリ２０５と２０６のデータの同期化のためのデータを送信する実施形態を前提としているので、パケットの種別やフィールドの名称に「共有メモリデータ」という語を使っている。しかし、一般的に述べるなら、共有メモリデータフィールドの内容は送信対象のデータそのものであり、共有メモリデータパケット５０４は送信対象のデータを送信するためのパケットであり、他の種別のパケットは諸々の制御用のパケットである。つまり、共有メモリデータフィールドの内容は図１の送信対象データ１０３に相当する。
【０１０６】
次に、図６〜図９のフローチャートを参照して、上記の各スレッドの動作について説明する。図６〜図９に関しては、コンピュータ２０１がアクティブ装置として運用され、コンピュータ２０２がスタンバイ装置として運用されている、図２の状態を前提として説明する。
【０１０７】
図６は、共有メモリ制御部２１３が共有メモリデータパケット５０４をスタンバイ装置２０２に送信する共有メモリデータ送信処理のフローチャートである。共有メモリデータ送信処理は、図２のユーザアプリケーション２０７から点Ａへ向かい、点Ａで分岐して点Ｂと点Ｄに向かう矢印に対応する。つまり、共有メモリデータ送信処理が開始される契機は、ユーザアプリケーション２０７が、共有メモリ２０５に書き込んだのと同じデータ２０９をスタンバイ装置２０２の共有メモリ２０６にも反映するよう、共有メモリ制御部２１３に要求することである。
【０１０８】
ステップＳ１０１で、データ送信スレッド４０３が、第一経路２１５と第二経路２１６を介して送信すべき二つの共有メモリデータパケット５０４を作成する。以下では、二つの共有メモリデータパケット５０４を区別する必要がある場合は「５０４‐１」と「５０４‐２」なる符号を用いる。共有メモリデータパケット５０４‐１と５０４‐２を作成する過程において、通番管理テーブル６０１の送信通番フィールドが更新される。
【０１０９】
通番管理テーブル６０１は、例えば、共有メモリ制御部２１３が参照可能なＲＡＭ上の制御用データ領域に格納され、共有メモリデータパケット５０４の順序を管理するための情報を保持している。具体的には、通番管理テーブル６０１は「送信通番」、「受信通番」、および「リフレッシュＩＤ」というフィールドを有する。本実施形態では、送信通番と受信通番は１バイトで表される０〜２５５の整数であり、リフレッシュＩＤは日時を表す値である。詳しくは後述するが、本実施形態では、三つのフィールドのいずれも、有効な値に初期化される前の例外的な初期値は０である。図６には、通番管理テーブル６０１の二つの状態を符号「６０１ａ」と「６０１ｂ」により区別して示した。
【０１１０】
また、詳細は後述するが、１回目に使われた２５５という送信通番よりも、２回目に使われた１という送信通番の方が後の順序を示すことが、共有メモリデータパケット５０４から判断可能でなくてはならない。リフレッシュＩＤは、再利用された同じ値の送信通番同士を識別するための識別情報である。
【０１１１】
ステップＳ１０１でデータ送信スレッド４０３は、通番管理テーブル６０１の送信通番フィールドを更新し、送信通番を、現在の値に１を足した値とする。つまり、共有メモリデータパケットの送信がユーザアプリケーション２０７から依頼されるたびに、送信通番はカウントアップされる。データ送信スレッド４０３は、この更新後の送信通番を共有メモリデータパケット５０４‐１と５０４‐２の通番フィールドにそれぞれ設定する。
【０１１２】
また、データ送信スレッド４０３は、データ転送制御表３０１の「第一経路」レコードから、自分のポート番号と通信相手のポート番号を読み取り、第一経路２１５を介して送信すべき共有メモリデータパケット５０４‐１のＵＤＰヘッダに読み取ったポート番号を設定する。同様に、データ送信スレッド４０３は、「第二経路」レコードから自分のポート番号と通信相手のポート番号を読み取り、第二経路２１６を介して送信すべき共有メモリデータパケット５０４‐２のＵＤＰヘッダに読み取ったポート番号を設定する。
【０１１３】
共有メモリデータパケット５０４‐１と５０４‐２の双方で、ＴＹＰＥ１、ＴＹＰＥ２、リフレッシュＩＤ、および共有メモリデータの各フィールドは共通である。つまり、図５に示すように、データ送信スレッド４０３は、ＴＹＰＥ１を２に、ＴＹＰＥ２を３に設定する。また、データ送信スレッド４０３は、通番管理テーブル６０１からリフレッシュＩＤを読み取って、共有メモリデータパケット５０４‐１と５０４‐２のリフレッシュＩＤフィールドに設定する。共有メモリデータフィールドの内容は、共有メモリデータ送信処理を呼び出したユーザアプリケーション２０７が共有メモリ制御部２１３に与えたデータであり、データ２０９に等しい。
【０１１４】
以上がステップＳ１０１の処理だが、正確には、上記の送信通番の更新処理は単純なインクリメントではなく、以下のような処理である。
本実施形態では、コンピュータ２０１に電源が投入されたとき、または再起動されたとき、通番管理テーブル６０１の三つのフィールドの値はどれも自動的に０に設定され、図６の通番管理テーブル６０１ａの状態になると仮定している。つまり、本実施形態では、０という値は有効な値に初期化される前の例外的な値である。そして、電源が投入された後、または再起動された後の１回目の共有メモリデータパケット５０４の送信時には、ステップＳ１０１において送信通番が１に設定される。
【０１１５】
一方で、上記のとおり送信通番は２５５までの整数である。よって、２５５個より多くの共有メモリデータパケット５０４を送信しようとすると、送信通番はオーバーフローする。そこで、同じ番号を再利用する必要がある。現在の送信通番が２５５の場合、単純に２５５に１を足すと、オーバーフローの結果、０なる値に送信通番が更新される。しかし、０は初期化の前の例外的な値であるから、共有メモリデータパケット５０４の通番フィールドに０が設定されることは避けるべきである。
【０１１６】
そこで、ステップＳ１０１での送信通番の更新においては、まず、データ送信スレッド４０３は送信通番を、現在の値に１を足した値とする。そして、その結果の送信通番が０なら、データ送信スレッド４０３は再度、送信通番に１を足す。データ送信スレッド４０３は、こうして得られた１という送信通番を共有メモリデータパケット５０４の通番フィールドに設定する。そのため、通番フィールドの値が２５５の共有メモリデータパケット５０４の次に送信される共有メモリデータパケット５０４の通番フィールドの値は、１である。
【０１１７】
以上のようにして、１〜２５５のいずれかの値が通番フィールドに設定された共有メモリデータパケット５０４‐１と５０４‐２をステップＳ１０１で作成すると、データ送信スレッド４０３はステップＳ１０２において、通番管理テーブル６０１に格納された送信通番が１か否かを判定する。送信通番が１の場合、判定は「ＹＥＳ」となって処理はステップＳ１０３に移行し、それ以外の場合、判定は「ＮＯ」となって処理はステップＳ１０６に移行する。
【０１１８】
ステップＳ１０３〜Ｓ１０５は、ステップＳ１０２の判定が「ＹＥＳ」の場合のみ実行される。ステップＳ１０３で、データ送信スレッド４０３は現在の日時を取得し、取得し
た日時を表す値Ａを通番管理テーブル６０１のリフレッシュＩＤフィールドに登録する。その結果は、図６の通番管理テーブル６０１ｂのとおりである。
【０１１９】
続くステップＳ１０４で、データ送信スレッド４０３は、第一経路２１５と第二経路２１６を介して送信すべき二つのリフレッシュ要求パケット５０２を作成して、スタンバイ装置２０２に送信する。以下では二つのリフレッシュ要求パケット５０２を区別する必要がある場合は「５０２‐１」と「５０２‐２」なる符号を用いる。ステップＳ１０４の処理は、アクティブ装置２０１とスタンバイ装置２０２の間で足並みを揃えてそれぞれの送信通番と受信通番とリフレッシュＩＤを初期化するための処理である。
【０１２０】
データ送信スレッド４０３は、データ転送制御表３０１の「第一経路」レコードと「第二経路」レコードのそれぞれから自分のポート番号と通信相手のポート番号を読み取って、リフレッシュ要求パケット５０２‐１と５０２‐２それぞれのＵＤＰヘッダに設定する。ＴＹＰＥ１、ＴＹＰＥ２、リフレッシュＩＤの三つのフィールドは、リフレッシュ要求パケット５０２‐１と５０２‐２で共通である。データ送信スレッド４０３が、ＴＹＰＥ１を２に設定し、ＴＹＰＥ２を１に設定し、リフレッシュＩＤを通番管理テーブル６０１から読み取ってリフレッシュ要求パケット５０２‐１と５０２‐２のリフレッシュＩＤフィールドに設定する。
【０１２１】
そして、データ送信スレッド４０３は、データ転送制御表３０１を参照して第一経路２１５と第二経路２１６の状態をチェックする。データ送信スレッド４０３は、第一経路２１５が正常なら第一経路２１５を介してリフレッシュ要求パケット５０２‐１をスタンバイ装置２０２へ送信する。また、データ送信スレッド４０３は、第二経路２１６が正常なら第二経路２１６を介してリフレッシュ要求パケット５０２‐２をスタンバイ装置２０２へ送信する。
【０１２２】
続くステップＳ１０５では、データ送信スレッド４０３はスリープ状態であり、データ受信スレッド４０５が、スタンバイ装置２０２からの応答、すなわちリフレッシュ応答パケット５０３の受信を待ち合わせている。リフレッシュ応答パケット５０３の受信の詳細は図８とともに後述するが、リフレッシュ応答パケット５０３の受信を契機として、スリープ状態のデータ送信スレッド４０３が起床させられて、処理がステップＳ１０６に移行する。
【０１２３】
ステップＳ１０６でデータ送信スレッド４０３は、データ転送制御表３０１の「第一経路」レコードの「状態」フィールドを参照し、第一経路２１５が正常か否かを判定する。「状態」フィールドの値が「正常」なら判定は「ＹＥＳ」となって処理がステップＳ１０７に移行し、そうでなければ判定は「ＮＯ」となって処理がステップＳ１０８に移行する。
【０１２４】
ステップＳ１０７で、データ送信スレッド４０３は、まず、データ転送制御表３０１の「第一経路」レコードの自分のＩＰアドレスと通信相手のＩＰアドレスを読み取る。そして、データ送信スレッド４０３は読み取ったＩＰアドレスを含むＩＰヘッダを共有メモリデータパケット５０４‐１に付加して、共有メモリデータパケット５０４‐１をカプセル化する。そして、データ送信スレッド４０３は、ＵＤＰポート４１１から第一経路２１５を介してスタンバイ装置２０２へ、カプセル化したＩＰパケットを送信する。
【０１２５】
続くステップＳ１０８とＳ１０９からなる処理は、ステップＳ１０６とＳ１０７からなる処理と同様である。違いは、ステップＳ１０６とＳ１０７は第一経路２１５に対応する処理であるのに対し、ステップＳ１０８とＳ１０９は第二経路２１６に対応する処理である点のみである。
【０１２６】
ステップＳ１０８で「ＮＯ」と判定された後、またはステップＳ１０９の実行後、図６の共有メモリデータ送信処理は終了する。
図７は、図６のステップＳ１０４で送信されたリフレッシュ要求パケット５０２をスタンバイ装置２０２が受信するリフレッシュ要求受信処理のフローチャートである。
【０１２７】
まず、第一経路受信スレッド４０８または第二経路受信スレッド４１０が、パケットを受信し、ＴＹＰＥ１フィールドの値にもとづいてヘルスチェックパケット５０１ではないと判断し、受信したパケットの処理をデータ受信スレッド４０６に要求する。次に、データ受信スレッド４０６が受信したパケットのＴＹＰＥ２フィールドの値にもとづいて、受信したパケットがリフレッシュ要求パケット５０２であると判断する。この判断を契機として、リフレッシュ要求受信処理が開始される。リフレッシュ要求受信処理には、どちらの経路を介してリフレッシュ要求パケット５０２を受信したかは関係がない。
【０１２８】
また、通番管理テーブル６０１と同様の通番管理テーブル６０２が、コンピュータ２０２のＲＡＭ上の制御用データ領域にも格納されている。なお、図７には通番管理テーブル６０２の二つの状態を符号「６０２ａ」と「６０２ｂ」により区別して示した。コンピュータ２０２に電源が投入された直後またはコンピュータ２０２が再起動された直後には、通番管理テーブル６０２ａのように、三つのフィールドの値はすべて０である。
【０１２９】
リフレッシュ要求受信処理が開始されると、まずステップＳ２０１で、データ受信スレッド４０６は、受信したリフレッシュ要求パケット５０２のリフレッシュＩＤフィールドの値と通番管理テーブル６０２のリフレッシュＩＤフィールドの値が一致するか否かを判定する。両者が一致していれば判定は「ＹＥＳ」となって、リフレッシュ要求受信処理を終了し、そうでなければ判定は「ＮＯ」となって、ステップＳ２０２に移行する。判定が「ＹＥＳ」となるのは、処理済みのリフレッシュ要求パケット５０２と同じ内容のリフレッシュ要求パケット５０２を、別の経路を介して受信した場合である。
【０１３０】
ステップＳ２０２において、データ受信スレッド４０６は、受信したリフレッシュ要求パケット５０２のリフレッシュＩＤフィールドの値を通番管理テーブル６０２のリフレッシュＩＤフィールドに設定する。これにより、通番管理テーブル６０２のリフレッシュＩＤフィールドの値が更新される。図７では、更新後のリフレッシュＩＤフィールドの値を図６と同じく符号「Ａ」により示している。
【０１３１】
続いてステップＳ２０３において、データ受信スレッド４０６は、通番管理テーブル６０２の受信通番フィールドの値を１に初期化する。その結果は、通番管理テーブル６０２ｂとして図７に示したとおりである。また、データ受信スレッド４０６は、次のステップＳ２０４の処理を実行するよう、データ送信スレッド４０４に要求する。
【０１３２】
ステップＳ２０４において、データ送信スレッド４０４は、第一経路２１５と第二経路２１６を介して送信すべき二つのリフレッシュ応答パケット５０３を作成し、アクティブ装置２０１に送信する。以下では二つのリフレッシュ応答パケット５０３を区別する必要がある場合は「５０３‐１」と「５０３‐２」なる符号を用いる。
【０１３３】
データ送信スレッド４０４は、データ転送制御表３０２の「第一経路」レコードと「第二経路」レコードのそれぞれから自分のポート番号と通信相手のポート番号を読み取って、リフレッシュ応答パケット５０３‐１と５０３‐２それぞれのＵＤＰヘッダに設定する。ＴＹＰＥ１、ＴＹＰＥ２、リフレッシュＩＤの三つのフィールドは、リフレッシュ応答パケット５０３‐１と５０３‐２で共通である。データ送信スレッド４０４が、ＴＹＰＥ１を２に設定し、ＴＹＰＥ２を２に設定し、ステップＳ２０１でリフレッシュ要求パケッ
ト５０２から読み取ったリフレッシュＩＤをリフレッシュ応答パケット５０３‐１と５０３‐２のリフレッシュＩＤフィールドに設定する。また、データ送信スレッド４０４は、データ転送制御表３０２の自分のＩＰアドレスと通信相手のＩＰアドレスを参照して適切なＩＰヘッダをリフレッシュ応答パケット５０３‐１と５０３‐２に付加する。
【０１３４】
そして、データ送信スレッド４０４は、データ転送制御表３０２を参照して第一経路２１５と第二経路２１６の状態をチェックする。データ送信スレッド４０４は、第一経路２１５が正常なら第一経路２１５を介してリフレッシュ応答パケット５０３‐１をアクティブ装置２０１へ送信し、第二経路２１６が正常なら第二経路２１６を介してリフレッシュ応答パケット５０３‐２をアクティブ装置２０１へ送信する。
【０１３５】
以上のようにしてリフレッシュ要求受信処理が終了する。第一経路２１５と第二経路２１６の少なくとも一方が正常なら、ステップＳ２０４で送信されたリフレッシュ応答パケット５０３は、その後、アクティブ装置２０１で受信される。第一経路受信スレッド４０７または第二経路受信スレッド４０９は、リフレッシュ応答パケット５０３を受信すると、ヘルスチェックパケット５０１ではないと判断し、受信したパケットの処理をデータ受信スレッド４０５に要求する。データ受信スレッド４０５は、受信したパケットのＴＹＰＥ２フィールドの値にもとづいて、受信したパケットがリフレッシュ応答パケット５０３であると判断する。この判断を契機として、図８のフローチャートに示したリフレッシュ応答受信処理が開始される。リフレッシュ応答受信処理には、どちらの経路を介してリフレッシュ応答パケット５０３を受信したかは関係がない。
【０１３６】
また、リフレッシュ応答受信処理が実行されるのは図６のステップＳ１０５の待ち合わせ中なので、図８には、図６の通番管理テーブル６０１ｂと同じ状態の通番管理テーブル６０１ｂを示してある。
【０１３７】
ステップＳ３０１でデータ受信スレッド４０５は、受信したリフレッシュ応答パケット５０３からリフレッシュＩＤを読み取り、読み取ったリフレッシュＩＤと通番管理テーブル６０２のリフレッシュＩＤが一致するか否かを判定する。両者が一致していれば判定は「ＹＥＳ」となって処理がステップＳ３０２に移行し、そうでなければ判定は「ＮＯ」となってリフレッシュ応答受信処理を終了する。判定が「ＮＯ」となるのは、異なるリフレッシュＩＤに対応するリフレッシュ応答パケット５０３が時間的に近接して送信され、何らかの理由で送信順序とは違う順序で受信された場合など、例外的な場合である。
【０１３８】
ステップＳ３０２において、データ受信スレッド４０５は、受信したリフレッシュ応答パケット５０３の待ち合わせ先であるデータ送信スレッド４０３を起床させる。すなわち、データ受信スレッド４０５は、図６のステップＳ１０５で待ち続けているデータ送信スレッド４０３に対し、次のステップＳ１０６に進むべきことを通知する。そして、リフレッシュ応答受信処理が終了する。つまり、この起床通知は、アクティブ装置２０１の通番管理テーブル６０１とスタンバイ装置２０２の通番管理テーブル６０２がそれぞれ保持するリフレッシュＩＤを同期化させる処理が完了したことを示す通知である。
【０１３９】
次に、図９を参照して、共有メモリデータパケット５０４をスタンバイ装置２０２が受信する共有メモリデータ受信処理について説明する。図９の全体はループを構成している。図９は、ステップＳ４０１で共有メモリデータパケット５０４を受信するたびに、ステップＳ４０２〜Ｓ４０７の処理を実行し、次の共有メモリデータパケット５０４の受信に備えてステップＳ４０１に戻ることを表している。
【０１４０】
ステップＳ４０１で、スタンバイ装置２０２が共有メモリデータパケット５０４を受信する。具体的には、図６のステップＳ１０７で第一経路２１５を介して送信された共有メ
モリデータパケット５０４‐１を第一経路受信スレッド４０８が受信するか、ステップＳ１０９で第二経路２１６を介して送信された共有メモリデータパケット５０４‐２を第二経路受信スレッド４１０が受信する。
【０１４１】
第一経路受信スレッド４０８または第二経路受信スレッド４１０は、受信したパケットのＴＹＰＥ１フィールドの値にもとづき、受信したパケットがヘルスチェックパケット５０１ではないと判断し、受信したパケットの処理をデータ受信スレッド４０６に要求する。データ受信スレッド４０６は受信したパケットのＴＹＰＥ２フィールドの値にもとづき、受信したパケットが共有メモリデータパケット５０４であると判断する。以下の処理には、どちらの経路を介して共有メモリデータパケット５０４を受信したかは関係がない。
【０１４２】
次のステップＳ４０２では、データ受信スレッド４０６が、受信した共有メモリデータパケット５０４からリフレッシュＩＤを読み取り、読み取ったリフレッシュＩＤと通番管理テーブル６０２のリフレッシュＩＤが一致するか否かを判定する。両者が一致していれば判定は「ＹＥＳ」となって処理がステップＳ４０３に移行し、そうでなければ判定は「ＮＯ」となってステップＳ４０１に戻る。
【０１４３】
「ＮＯ」という判定は、直前のステップＳ４０１で受信した共有メモリデータパケット５０４が、過去に受信した他の共有メモリデータパケット５０４と重複する、ということを意味する。換言すれば、「ＮＯ」という判定は、図１の受信順序情報１１１が送信順序情報１０９または１１０よりも後の順序を示すことを意味する。よって、判定が「ＮＯ」となる場合、直前のステップＳ４０１で受信した共有メモリデータパケット５０４の共有メモリデータフィールドの内容に関する処理は何も行われない。つまり、この共有メモリデータパケット５０４は破棄される。
【０１４４】
ステップＳ４０３では、データ受信スレッド４０６が、受信した共有メモリデータパケット５０４の通番フィールドの値ｐを読み取り、通番管理テーブル６０２の受信通番フィールドの値ｔと比較する。比較の結果に応じて、処理は三通りに分岐する。
【０１４５】
（１）ｐ＜ｔの場合
ｐ＜ｔとなるのは、過去に受信して処理済みの共有メモリデータパケット５０４と同内容の共有メモリデータパケット５０４を、別の経路を介して重複して受信した場合である。つまり、図６のステップＳ１０１で一緒に作成された二つの共有メモリデータパケット５０４のうちの一方が過去の図９のループにおいて受信されて処理済みであり、他方が今回のループのステップＳ４０１で受信された場合に、ｐ＜ｔとなる。「ｐ＜ｔ」なる式は、図１の受信順序情報１１１が送信順序情報１０９または１１０よりも後の順序を示すことに対応する。
【０１４６】
図６のステップＳ１０１で一緒に作成された二つの共有メモリデータパケット５０４は、ＵＤＰヘッダ以外のすべてのフィールドの内容が等しい。過去に受信した共有メモリデータパケット５０４の共有メモリデータは処理済みなので、今回のループで受信した共有メモリデータパケット５０４の共有メモリデータを処理する必要はない。そこで、今回のループのステップＳ４０１で受信した共有メモリデータパケット５０４は破棄され、その共有メモリデータフィールドの内容に関する処理は何も行われない。次の共有メモリデータパケット５０４の受信を待つために、処理はステップＳ４０１に戻る。
【０１４７】
（２）ｐ＝ｔの場合
ｐ＝ｔとなるのは、次に処理すべき共有メモリデータパケット５０４を受信した場合である。なお「処理すべき」とは、本実施形態では、共有メモリデータフィールドの内容を共有メモリ２０６に反映する処理を行うべきことを意味する。この場合、その処理を行う
ためにステップＳ４０５に移行する。つまり、「ｐ＝ｔ」とは、次に受信されると期待される順序に対応するパケットが、まさに今回のループで受信されたことを表し、図１の受信順序情報１１１が送信順序情報１０９または１１０と同じ順序を示す場合に該当する。
【０１４８】
（３）ｐ＞ｔの場合
ｐ＞ｔとなるのは、連続してアクティブ装置２０１から送信された、異なる順序に対応する複数の共有メモリデータパケット５０４のうちの一つ以上が、何らかの理由でスタンバイ装置２０２に到達しなかった場合である。つまり、ｐ＞ｔのとき、スタンバイ装置２０２から見ると、連続する複数の共有メモリデータパケット５０４のうちの一部が消失した状態である。「ｐ＞ｔ」なる式は、図１の受信順序情報１１１が送信順序情報１０９または１１０よりも前の順序を示すことに対応する。
【０１４９】
なお、二つの経路を介して送信された二つの共有メモリデータパケット５０４のうちの一方がネットワーク上で消失しても、他方が正常な経路を介してスタンバイ装置２０２に正しい順序で到達すれば、ｐ＞ｔとはならず、「消失」とは見なされない。ｐ＞ｔの場合、処理はステップＳ４０４に移行する。
【０１５０】
ステップＳ４０４は、受信した共有メモリデータパケット５０４の通番フィールドの値ｐが通番管理テーブル６０２の受信通番フィールドの値ｔより大きい場合に実行される。上記のように、この場合は連続してアクティブ装置２０１から送信された、異なる順序に対応する複数の共有メモリデータパケット５０４のうちの一つ以上が、正しい順序でスタンバイ装置２０２に受信されず、抜け落ちている。しかし、今回のループのステップＳ４０１で受信した共有メモリデータパケット５０４は未処理のデータを共有メモリデータフィールドに含む。本実施形態では、この未処理のデータは処理すべきデータであり、破棄せずに利用する。
【０１５１】
そこで、ステップＳ４０４では、今回のループのステップＳ４０１で受信した共有メモリデータパケット５０４が処理の対象であることを、通番管理テーブル６０２にも反映するための処理をデータ受信スレッド４０６が行う。具体的には、データ受信スレッド４０６は、通番管理テーブル６０２の受信通番フィールドに、今回のループのステップＳ４０１で受信した共有メモリデータパケット５０４の通番フィールドの値を設定する。これにより、次回のループでは、こうして更新された受信通番にもとづいてステップＳ４０３の判定が行われる。
【０１５２】
ステップＳ４０４の実行後、またはステップＳ４０３でｐ＝ｔと判定された場合、ステップＳ４０５〜Ｓ４０７が実行される。
ステップＳ４０５では、今回のループのステップＳ４０１で受信された共有メモリデータパケット５０４の共有メモリデータフィールドの内容を、データ受信スレッド４０６が共有メモリ２０６に反映する。ステップＳ４０５は、図２で点Ｂから共有メモリ２０６に向かう矢印に対応する。ステップＳ４０５の処理を終えるとデータ受信スレッド４０６は、ステップＳ４０６の処理を行うようデータ送信スレッド４０４に要求する。
【０１５３】
ステップＳ４０６では、データ送信スレッド４０４がＡＣＫパケット５０５をアクティブ装置２０１に返信する。ＡＣＫパケット５０５は、スタンバイ装置２０２が共有メモリデータパケット５０４を受信し、その共有メモリデータフィールドの内容を共有メモリ２０６に反映したという結果をアクティブ装置２０１に通知するためのパケットである。データ送信スレッド４０４は、第一経路２１５と第二経路２１６を介して送信すべき二つのＡＣＫパケット５０５を作成し、アクティブ装置２０１に送信する。以下では二つのＡＣＫパケット５０５を区別する必要がある場合は「５０５‐１」と「５０５‐２」なる符号を用いる。
【０１５４】
データ送信スレッド４０４は、データ転送制御表３０２の「第一経路」レコードと「第二経路」レコードのそれぞれから自分のポート番号と通信相手のポート番号を読み取って、ＡＣＫパケット５０５‐１と５０５‐２それぞれのＵＤＰヘッダに設定する。ＴＹＰＥ１、ＴＹＰＥ２、リフレッシュＩＤ、通番の四つのフィールドは、ＡＣＫパケット５０５‐１と５０５‐２で共通である。データ送信スレッド４０４が、ＴＹＰＥ１を２に設定し、ＴＹＰＥ２を４に設定し、通番管理テーブル６０２からリフレッシュＩＤを読み取って、読み取ったリフレッシュＩＤをＡＣＫパケット５０５‐１と５０５‐２のリフレッシュＩＤフィールドに設定する。また、データ送信スレッド４０４は、データ転送制御表３０２の自分のＩＰアドレスと通信相手のＩＰアドレスを参照して適切なＩＰヘッダをＡＣＫパケット５０５‐１と５０５‐２に付加する。
【０１５５】
そして、データ送信スレッド４０４は、データ転送制御表３０２を参照して第一経路２１５と第二経路２１６の状態をチェックする。データ送信スレッド４０４は、第一経路２１５が正常なら第一経路２１５を介してＡＣＫパケット５０５‐１をアクティブ装置２０１へ送信し、第二経路２１６が正常なら第二経路２１６を介してＡＣＫパケット５０５‐２をアクティブ装置２０１へ送信する。
【０１５６】
続くステップＳ４０７では、データ受信スレッド４０６が、通番管理テーブル６０２の受信通番フィールドを更新し、受信通番を、現在の値に１を足した値とする。この処理は、正確には図６のステップＳ１０１と同様に、２５５に１を足した場合はオーバーフローして０となり、０を避けるために再度１を足して受信通番を１とする処理である。受信通番の更新後、処理はステップＳ４０１に戻る。
【０１５７】
次に、図１０〜図１３の処理シーケンス図を参照して、処理の具体例を説明する。図１０〜図１３でも、図２のようにコンピュータ２０１がアクティブ装置２０１として運用され、コンピュータ２０２がスタンバイ装置２０２として運用されている状態を前提とする。
【０１５８】
また、図１０〜図１３では、アクティブ装置２０１に格納された通番管理テーブル６０１の状態を左列の矩形内に、スタンバイ装置２０２に格納された通番管理テーブル６０２の状態を右列の矩形内に、それぞれ示した。図１０〜図１３では、通番管理テーブル６０１と６０２に格納された送信通番、受信通番、およびリフレッシュＩＤをそれぞれ「ｓｎｄ＿ｓｅｑ」、「ｒｃｖ＿ｓｅｑ」、「ｒｅｆｒｅｓｈ＿ｉｄ」なる符号により表した。また、各種パケットの種別を矢印の上に書き、そのパケットのリフレッシュＩＤフィールドと通番フィールドの値を、それぞれ矢印の上に添えた「ｒｅｆｒｅｓｈ＿ｉｄ」と「ｓｅｑ」なる符号により表した。
【０１５９】
なお、図１０〜図１３は、二つの経路のいずれかを介して最終的にスタンバイ装置２０２に共有メモリデータパケット５０４が到達するか否かという点と、アクティブ装置２０１の通番管理テーブル６０１とスタンバイ装置２０２の通番管理テーブル６０２がどのように連携されるかという点に注目した図である。よって、図１０〜図１３では、二つの経路がともに正常な場合の、パケットの重複に関する処理は省略して図示した。
【０１６０】
図１０は、初期状態と、その後に続く正常な処理の結果を示す。状態ＡＣ１０１と状態ＳＴ１０１はそれぞれ通番管理テーブル６０１と６０２の初期状態である。どちらも、三つのフィールドすべての値が０である。
【０１６１】
この状態で、ユーザアプリケーション２０７がデータ２０９をスタンバイ装置２０２にも反映するよう共有メモリ制御部２１３に要求すると、図６のステップＳ１０１〜Ｓ１０
３により、通番管理テーブル６０１は状態ＡＣ１０２になる。ここで、送信通番が１、リフレッシュＩＤがＡである。
【０１６２】
次に、図６のステップＳ１０４でリフレッシュ要求パケット５０２がスタンバイ装置２０２に送信される。スタンバイ装置２０２がリフレッシュ要求パケット５０２を受信したときの通番管理テーブル６０２の状態は、状態ＳＴ１０１と同じ状態ＳＴ１０２である。スタンバイ装置２０２では、図７のステップＳ２０１の判定が「ＮＯ」となるので、ステップＳ２０２とＳ２０３により通番管理テーブル６０２が更新されて状態ＳＴ１０２から状態ＳＴ１０３へと変わる。ここで、受信通番が１、リフレッシュＩＤがＡである。
【０１６３】
そして、スタンバイ装置２０２から図７のステップＳ２０４でリフレッシュ応答パケット５０３がアクティブ装置２０１へ送信される。アクティブ装置２０１がリフレッシュ応答パケット５０３を受信したときの通番管理テーブル６０１の状態は、状態ＡＣ１０２と同じ状態ＡＣ１０３である。
【０１６４】
そして、図８のステップＳ３０１の判定が「ＹＥＳ」となるため、図６のステップＳ１０６〜Ｓ１０９が実行される。その際の通番管理テーブル６０１の状態は状態ＡＣ１０３と同じ状態ＡＣ１０４であるから、ステップＳ１０７とＳ１０９で送信される共有メモリデータパケット５０４の通番フィールドの値は１、リフレッシュＩＤフィールドの値はＡである。
【０１６５】
この共有メモリデータパケット５０４をスタンバイ装置２０２が受信したときの通番管理テーブル６０２の状態は状態ＳＴ１０３と同じ状態ＳＴ１０４である。この場合、図９のステップＳ４０３でｐ＝ｔと判定されるので、ステップＳ４０６でＡＣＫパケット５０５がアクティブ装置２０１に送信され、ステップＳ４０７で受信通番が２に更新されて、通番管理テーブル６０２が状態ＳＴ１０５のようになる。
【０１６６】
ステップＳ４０６で送信されるＡＣＫパケット５０５のリフレッシュＩＤフィールドと通番フィールドの値はＡと１である。アクティブ装置２０１がＡＣＫパケット５０５を受信するときの通番管理テーブル６０１の状態は、状態ＡＣ１０４と同じ状態ＡＣ１０５であるから、受信したＡＣＫパケット５０５のリフレッシュＩＤフィールドの値と通番管理テーブル６０１のリフレッシュＩＤは等しく、かつ、受信したＡＣＫパケット５０５の通番フィールドの値と通番管理テーブル６０１の送信通番は等しい。
【０１６７】
よって、共有メモリ制御部２１３のデータ受信スレッド４０５は、直前に送信した共有メモリデータパケット５０４に対応するＡＣＫパケット５０５が正常に返信されたことを検知することができる。正常にＡＣＫパケット５０５が返信されたことを検知すると、共有メモリ制御部２１３はその旨をユーザアプリケーション２０７に通知する。また、ＡＣＫパケット５０５の正常な受信を契機として、共有メモリ制御部２１３は、ユーザアプリケーション２０７からの次のデータ送信の要求を受け付けることが可能になる。
【０１６８】
そこで、共有メモリ２０６にデータを反映するためのデータ送信を次にユーザアプリケーション２０７が共有メモリ制御部２１３に要求すると、図６のステップＳ１０１により通番管理テーブル６０１の送信通番が２に更新され、更新後の状態は状態ＡＣ１０６となる。そして、この状態ＡＣ１０６でステップＳ１０２の判定は「ＮＯ」となり、ステップＳ１０６〜Ｓ１０９が実行される。それにより送信される共有メモリデータパケット５０４の通番フィールドの値は２、リフレッシュＩＤフィールドの値はＡである。
【０１６９】
この共有メモリデータパケット５０４をスタンバイ装置２０２が受信したときの通番管理テーブル６０２の状態は状態ＳＴ１０５のままである。この場合も図９のステップＳ４
０３でｐ＝ｔと判定されるので、ステップＳ４０６でＡＣＫパケット５０５がアクティブ装置２０１に送信される。また、ステップＳ４０７で受信通番が３に更新されて通番管理テーブル６０２は状態ＳＴ１０６のようになる。
【０１７０】
ステップＳ４０６で送信されるＡＣＫパケット５０５のリフレッシュＩＤフィールドと通番フィールドの値はＡと２である。アクティブ装置２０１がＡＣＫパケット５０５を受信するときの通番管理テーブル６０１の状態は、状態ＡＣ１０６と同じ状態ＡＣ１０７なので、受信したＡＣＫパケット５０５のリフレッシュＩＤフィールドの値と通番管理テーブル６０１のリフレッシュＩＤはともにＡであり、かつ、受信したＡＣＫパケット５０５の通番フィールドの値と通番管理テーブル６０１の送信通番はともに２である。
【０１７１】
よって、共有メモリ制御部２１３のデータ受信スレッド４０５は、直前に送信した共有メモリデータパケット５０４に対応するＡＣＫパケット５０５が正常に返信されたことを検知することができる。
【０１７２】
次に、図１１を参照して、共有メモリデータパケット５０４が消失する場合の例を説明する。
図１１のうち、状態ＡＣ２０１、状態ＳＴ２０１、状態ＡＣ２０２からなる部分と、状態ＳＴ２０１から状態ＳＴ２０２への更新を表す部分は、正常な送信に対応する部分である。すなわち、通番フィールドの値が１の共有メモリデータパケット５０４が問題なくアクティブ装置２０１から送信されてスタンバイ装置２０２で受信され、対応するＡＣＫパケット５０５が問題なくスタンバイ装置２０２からアクティブ装置２０１へ返信され、通番管理テーブル６０２の受信通番が１から２に更新されるまでの過程は正常である。状態ＡＣ２０１、状態ＳＴ２０１、状態ＡＣ２０２、状態ＳＴ２０２はそれぞれ図１０の状態ＡＣ１０４、状態ＳＴ１０４、状態ＡＣ１０５、状態ＳＴ１０５と同様である。
【０１７３】
通番管理テーブル６０１が状態ＡＣ２０２のとき、共有メモリ２０６へのデータ２０９の反映を、ユーザアプリケーション２０７が共有メモリ制御部２１３に要求する。すると、図６のステップＳ１０１により通番管理テーブル６０１の送信通番が２に更新され、更新後の状態は状態ＡＣ２０３となる。この状態ＡＣ２０３でステップＳ１０２の判定は「ＮＯ」となり、ステップＳ１０６〜Ｓ１０９が実行される。それにより送信される共有メモリデータパケット５０４の通番フィールドの値は２、リフレッシュＩＤフィールドの値はＡである。
【０１７４】
図１１では、第一経路２１５と第二経路２１６を介して送信された二つの共有メモリデータパケット５０４がともに消失したと仮定する。よって、通番フィールドの値が２で、リフレッシュＩＤフィールドの値がＡの共有メモリデータパケット５０４は、スタンバイ装置２０２には届かない。当然、この共有メモリデータパケット５０４に対応するＡＣＫパケット５０５はアクティブ装置２０１に返信されない。よって、アクティブ装置２０１の共有メモリ制御部２１３は、共有メモリデータパケット５０４の送信から所定の時間内に適切なＡＣＫパケット５０５を受信することができないため、タイムアウトする。
【０１７５】
共有メモリ制御部２１３は、ユーザアプリケーション２０７に共有メモリデータパケット５０４の送信が失敗したことを通知する。その通知によりユーザアプリケーション２０７は、データ２０９の反映が失敗したことを認識する。その後、ユーザアプリケーション２０７は、データ２０９を共有メモリ２０６に反映するよう、再度共有メモリ制御部２１３に要求してもよい。本実施形態における再送制御は、共有メモリ制御部２１３ではなくユーザアプリケーション２０７の責任において行われる。もちろん、他の実施形態では共有メモリ制御部２１３がタイムアウト後に再送を試みてもよい。
【０１７６】
一方、共有メモリ制御部２１３は、タイムアウトすることにより、ユーザアプリケーション２０７からのデータ送信の要求を受け付けることが可能になる。
そこで、次にユーザアプリケーション２０７が共有メモリ２０６へのデータ２０９の反映を共有メモリ制御部２１３に要求すると、図６のステップＳ１０１により通番管理テーブル６０１の送信通番が３に更新され、更新後の状態は状態ＡＣ２０４となる。そして、この状態ＡＣ２０４でステップＳ１０２の判定は「ＮＯ」となり、ステップＳ１０６〜Ｓ１０９が実行される。それにより送信される共有メモリデータパケット５０４の通番フィールドの値は３、リフレッシュＩＤフィールドの値はＡである。
【０１７７】
この共有メモリデータパケット５０４をスタンバイ装置２０２が受信したときの通番管理テーブル６０２の状態は、状態ＳＴ２０２と同じ状態ＳＴ２０３である。この場合、図９のステップＳ４０３でｐ＞ｔと判定される。よって、ステップＳ４０４で受信通番が３に更新されて、通番管理テーブル６０２が状態ＳＴ２０４のようになり、ステップＳ４０５で共有メモリデータフィールドの内容が共有メモリ２０６に反映され、ステップＳ４０６でＡＣＫパケット５０５がアクティブ装置２０１に送信される。また、ステップＳ４０７で受信通番が４に更新されて通番管理テーブル６０２は状態ＳＴ２０５のようになる。
【０１７８】
ここで送信されるＡＣＫパケット５０５のリフレッシュＩＤフィールドと通番フィールドの値はＡと３である。アクティブ装置２０１がＡＣＫパケット５０５を受信するときの通番管理テーブル６０１の状態は、状態ＡＣ２０４と同じ状態ＡＣ２０５なので、受信したＡＣＫパケット５０５のリフレッシュＩＤフィールドの値と通番管理テーブル６０１のリフレッシュＩＤはともにＡであり、かつ、受信したＡＣＫパケット５０５の通番フィールドの値と通番管理テーブル６０１の送信通番はともに３である。
【０１７９】
よって、共有メモリ制御部２１３のデータ受信スレッド４０５は、直前に送信した共有メモリデータパケット５０４に対応するＡＣＫパケット５０５が正常に返信されたことを検知することができる。
【０１８０】
なお、図１１では、共有メモリデータパケット５０４が二つとも経路上で消失したと仮定したが、共有メモリデータパケット５０４が二つとも大幅に遅延してスタンバイ装置２０２に届いた場合も図１１のように処理される。なぜなら、共有メモリ制御部２１３は、所定の時間が過ぎても適切なＡＣＫパケット５０５を受信することができないとき、消失と遅延を区別することができないからである。
【０１８１】
さらに、図６のステップＳ１０６とＳ１０８の両方で「ＮＯ」と判定されて、共有メモリデータパケット５０４の送信が省略された場合も、図１１と同様である。
図１１のとおり、通番フィールドの値が１の共有メモリデータパケット５０４を受信することにより、通番管理テーブル６０２は状態ＳＴ２０２の状態となる。つまり、スタンバイ装置２０２は次に処理すべき共有メモリデータパケット５０４として、通番フィールドの値が２のものを期待している状態になる。
【０１８２】
一方で、図６のステップＳ１０１で送信通番が１から２に更新されて通番管理テーブル６０１が状態ＡＣ２０３となった後、ステップＳ１０６とＳ１０８の両方で「ＮＯ」と判定されると、通番フィールドの値が２の共有メモリデータパケット５０４は送信されない。この場合、共有メモリ制御部２１３は、ＡＣＫパケット５０５が返信されるはずがないことを認識可能である。よって、共有メモリ制御部２１３は、即座にユーザアプリケーション２０７からの次の要求を受け付けてもよい。すると、次の要求を受け付けることにより、ステップＳ１０１で送信通番が２から３に更新されて通番管理テーブル６０１が状態ＡＣ２０４となる。この時点で少なくとも一方の経路が正常なら、図１１の処理の流れとまったく同様に、通番フィールドの値が３の共有メモリデータパケット５０４が送信され
る。
【０１８３】
以上のとおり、実際に起きた現象が消失、遅延、送信の省略のいずれであっても、同様の方法によって通番管理テーブル６０１と６０２は適切に更新される。
次に、図１２を参照して、アクティブ装置２０１を再起動した場合の例を説明する。図１２の状態ＡＣ３０１、状態ＳＴ３０１、状態ＡＣ３０２、状態ＳＴ３０２からなる部分は、リフレッシュＩＤがＡの状態で、通番フィールドの値が２０の共有メモリデータパケット５０４が正常に送信されて受信され、対応するＡＣＫパケット５０５が正常に送信されて受信されることを表している。この部分は、具体的な数値以外は、図１０の状態ＡＣ１０４、状態ＳＴ１０４、状態ＡＣ１０５、状態ＳＴ１０５からなる部分と同様である。
【０１８４】
通番管理テーブル６０１が状態ＡＣ３０２のときにアクティブ装置２０１が再起動されると、通番管理テーブル６０１の送信通番、受信通番、リフレッシュＩＤはいずれも０という例外的な初期値に変化してしまう。
【０１８５】
図１０に示すとおり、共有メモリデータパケット５０４とＡＣＫパケット５０５を適切に送受信するには、通番管理テーブル６０１と６０２が同じ値のリフレッシュＩＤを保持している状態でなくてはならない。しかし、アクティブ装置２０１の再起動によって、通番管理テーブル６０１から「Ａ」というリフレッシュＩＤの値が消えてしまう。そこで、図６にしたがってアクティブ装置２０１が動作することにより、下記のごとく、再び通番管理テーブル６０１と６０２が同じ値のリフレッシュＩＤを保持している状態とする。その結果、共有メモリデータパケット５０４とＡＣＫパケット５０５を適切に送受信することが可能になる。
【０１８６】
すると、再起動後初めてユーザアプリケーション２０７がデータ２０９をスタンバイ装置２０２の共有メモリ２０６に反映するよう共有メモリ制御部２１３に要求したとき、通番管理テーブル６０１は図６のステップＳ１０１〜Ｓ１０３により初期化されて状態ＡＣ３０３になる。ここで、送信通番が１、リフレッシュＩＤがＢである。
【０１８７】
次に、図６のステップＳ１０４でリフレッシュ要求パケット５０２がスタンバイ装置２０２に送信される。スタンバイ装置２０２がリフレッシュ要求パケット５０２を受信したときの通番管理テーブル６０２の状態は、状態ＳＴ３０２と同じ状態ＳＴ３０３なので、通番管理テーブル６０２における受信通番は２１、リフレッシュＩＤはＡである。
【０１８８】
よって、図７のステップＳ２０１の判定が「ＮＯ」となるので、ステップＳ２０２とＳ２０３により通番管理テーブル６０２が更新されて状態ＳＴ３０３から状態ＳＴ３０４へと変わる。ここで、受信通番が１、リフレッシュＩＤがＢであり、状態ＳＴ３０４は初期化された状態である。
【０１８９】
以降の処理は、リフレッシュＩＤの値が異なる以外は、図１０と同様である。すなわち、図１２の状態ＡＣ３０４、状態ＡＣ３０５、状態ＳＴ３０５、状態ＡＣ３０６、状態ＳＴ３０６が、それぞれ、図１０の状態ＡＣ１０３、状態ＡＣ１０４、状態ＳＴ１０４、状態ＡＣ１０５、状態ＳＴ１０５に対応する。
【０１９０】
次に、図１３を参照して、送信通番および受信通番のオーバーフローについて説明する。図１３は、リフレッシュＩＤの必要性を示す例でもある。また、たとえ送信通番と受信通番のオーバーフローが起こる直前で共有メモリデータパケット５０４が消失しても、図６〜図９に示した処理により共有メモリデータパケット５０４同士の前後関係を正しく共有メモリ制御部２１４が把握することができることを、図１３の例は示している。
【０１９１】
図１３の状態ＡＣ４０１、状態ＳＴ４０１、状態ＡＣ４０２、状態ＡＣ４０３、および状態ＳＴ４０２からなる部分は、具体的な数値が１と２ではなく２５４と２５５である点以外は、図１１の状態ＡＣ２０１、状態ＳＴ２０１、状態ＡＣ２０２、状態ＡＣ２０３、および状態ＳＴ２０２からなる部分と同様である。つまり、図１３は、通番フィールドの値が２５４の共有メモリデータパケット５０４は正常に送信および受信され、対応するＡＣＫパケット５０５も正常に送信および受信された後、通番フィールドの値が２５５の共有メモリデータパケット５０４が消失したことを表している。
【０１９２】
この時点の通番管理テーブル６０２は状態ＳＴ４０２なので、スタンバイ装置２０２の共有メモリ制御部２１４は、次に処理すべき共有メモリデータパケット５０４として、リフレッシュＩＤフィールドの値がＡで、通番フィールドの値が２５５の共有メモリデータパケット５０４を期待して待っている状態である。
【０１９３】
一方で、アクティブ装置２０１の共有メモリ制御部２１３は、通番フィールドの値が２５５の共有メモリデータパケット５０４に対応する適切なＡＣＫパケット５０５を所定の時間内に受信することができないので、タイムアウトし、ユーザアプリケーション２０７からの次の要求を受け付ける。
【０１９４】
その結果、図６のステップＳ１０１で、共有メモリ制御部２１３のデータ送信スレッド４０３は、２５５に１を足してオーバーフローした値である０を算出し、算出した０に再度１を足して１を算出し、こうして得られた１を通番管理テーブル６０１の送信通番に設定する。また、ステップＳ１０２の判定が「ＹＥＳ」となるため、ステップＳ１０３で通番管理テーブル６０２のリフレッシュＩＤフィールドには「Ｂ」なる新たな値が設定される。その結果、通番管理テーブル６０２は状態ＡＣ４０４のようになる。
【０１９５】
そして、ステップＳ１０４でリフレッシュ要求パケット５０２がスタンバイ装置２０２に送信される。スタンバイ装置２０２がリフレッシュ要求パケット５０２を受信したときの通番管理テーブル６０２の状態は、状態ＳＴ４０２と同じ状態ＳＴ４０３である。よって、図７のステップＳ２０１の判定が「ＮＯ」となるので、ステップＳ２０２とＳ２０３により通番管理テーブル６０２が更新されて状態ＳＴ４０３から状態ＳＴ４０４へと変わる。ここで、受信通番が１、リフレッシュＩＤがＢであり、状態ＳＴ４０４は初期化された状態である。
【０１９６】
そして、スタンバイ装置２０２から図７のステップＳ２０４でリフレッシュ応答パケット５０３がアクティブ装置２０１へ送信される。アクティブ装置２０１がリフレッシュ応答パケット５０３を受信したときの通番管理テーブル６０１の状態は、状態ＡＣ４０４と同じ状態ＡＣ４０５である。
【０１９７】
以降の処理は、リフレッシュＩＤの具体的な値が異なる以外は図１０と同様であり、正常な共有メモリデータパケット５０４の送受信に関する処理である。つまり、オーバーフローの直前に消失した共有メモリデータパケット５０４があっても、オーバーフロー後の値を通番フィールドにもつ共有メモリデータパケット５０４は適切に処理される。具体的には、図１３の状態ＡＣ４０６、状態ＳＴ４０５、状態ＡＣ４０７、状態ＳＴ４０６からなる部分は、図１０の状態ＡＣ１０４、状態ＳＴ１０４、状態ＡＣ１０５、状態ＳＴ１０５からなる部分と同様である。
【０１９８】
もし、リフレッシュＩＤおよびそれに関する種々の処理がなければ、送信通番のオーバーフロー後に共有メモリデータパケット５０４を受信したとき、スタンバイ装置２０２の共有メモリ制御部２１４は判断を誤る。つまり、共有メモリ制御部２１４は、実際には重複していないパケットを、過去に受信した別のパケットと重複していると誤認する。リフ
レッシュＩＤは同じ値の通番同士を識別する値であり、この誤認を防ぐために利用される。なお、リフレッシュＩＤが識別する「通番」は、送信通番と受信通番の双方である。
【０１９９】
もし、リフレッシュＩＤおよびそれに関する種々の処理がなければ、スタンバイ装置２０２は、通番管理テーブル６０２の受信通番が２５５の状態のまま、通番フィールドの値が１の共有メモリデータパケット５０４を受信してしまう。この場合、図９のステップＳ４０２はリフレッシュＩＤに関する処理なので存在しない。よって、ステップＳ４０１の直後にステップＳ４０３が実行され、１＜２５５なのでステップＳ４０１に戻ってしまう。しかし、これは誤った処理である。
【０２００】
この誤認を防ぐためにリフレッシュＩＤが使われ、共有メモリデータパケット５０４に含まれる送信通番とリフレッシュＩＤの組み合わせが表す順序と、通番管理テーブル６０２に含まれる受信通番とリフレッシュＩＤの組み合わせが表す順序とが比較される。リフレッシュＩＤおよびそれに関する種々の処理により、オーバーフローをはさんでも共有メモリ制御部２１４が正しく共有メモリデータパケット５０４の順序を判定することができ、さらに、オーバーフローの前後に共有メモリデータパケット５０４が消失してさえ、正しい判定が可能となる。
【０２０１】
次に、本発明のプログラムを実行するコンピュータのブロック図である図１４について説明する。本発明のプログラムには送信プログラムと受信プログラムがある。図１の送信元コンピュータ１０１は送信プログラムを実行し、送信先コンピュータ１０２は受信プログラムを実行し、図２のコンピュータ２０１および２０２は送信プログラムと受信プログラムの双方を実行する。送信元コンピュータ１０１、送信先コンピュータ１０２、コンピュータ２０１、およびコンピュータ２０２はいずれも、図１４のコンピュータ７００のような一般的なハードウェア構成を備える。
【０２０２】
図１４のコンピュータ７００は、ＣＰＵ７０１、ＲＯＭ（Read Only Memory）７０２、ＲＡＭ７０３、通信インターフェイス７０４、入力装置７０５、出力装置７０６、記憶装置７０７、可搬型記憶媒体７１０の駆動装置７０８を備え、これらのすべてがバス７０９によって接続されている。
【０２０３】
また、コンピュータ７００は、通信インターフェイス７０４を介してネットワーク７１１に接続されており、ネットワーク７１１を介して通信相手のコンピュータ７１３と通信を行うことができる。つまり、図１の例ではネットワーク７１１が経路１０７と経路１０８を含み、図２の例ではネットワーク７１１が第一経路２１５と第二経路２１６を含む。通信インターフェイス７０４は、コンピュータ７００に元から組み込まれていてもよく、後からコンピュータ７００に取り付けられたＮＩＣでもよい。また、図１４には通信インターフェイス７０４として一つのブロックのみを示したが、通信インターフェイス７０４が物理的には２枚のＮＩＣであり、二つの経路のそれぞれに対応していてもよい。
【０２０４】
コンピュータ７００が送信元コンピュータ１０１の場合は通信相手のコンピュータ７１３が送信先コンピュータ１０２であり、コンピュータ７００が送信先コンピュータ１０２の場合は通信相手のコンピュータ７１３が送信元コンピュータ１０１である。同様に、コンピュータ７００がコンピュータ２０１の場合は通信相手のコンピュータ７１３がコンピュータ２０２であり、コンピュータ７００がコンピュータ２０２の場合は通信相手のコンピュータ７１３がコンピュータ２０１である。
【０２０５】
コンピュータ７００と通信相手のコンピュータ７１３は、例えば、ＬＡＮ（Local Area
Network）内の同じセグメントに含まれるなど、ネットワーク上の位置が近いことが好ましい。なぜなら、ルータによるルーティングを必要とするような、ネットワーク上で離れ
た位置にコンピュータ７００と通信相手のコンピュータ７１３があると、複数の経路が重なってしまうことが多く、経路を多重化する効果が薄れるからである。例えば、複数の経路のすべてが特定のルータを経由する場合、そのルータの不具合が全経路に影響する。また、一般的に、コンピュータ７００と通信相手のコンピュータ７１３のネットワーク上の位置が遠いほど、パケットの消失も起こりがちである。パケットの消失が多いほど、本発明を適用したシステム全体の性能も低下する。
【０２０６】
図２の共有メモリ２０５や２０６は、例えばＲＡＭ７０３の所定の領域である。ＲＡＭ７０３の残りの領域は、図１の送信順序情報１０４または受信順序情報１１１、より具体的には通番管理テーブル６０１または６０２を格納するための制御用データ領域として利用される。図３のデータ転送制御表３０１または３０２も、制御用データ領域に格納される。
【０２０７】
入力装置７０５は、マウスなどのポインティングデバイスやキーボードである。出力装置７０６は例えば液晶ディスプレイなどの表示装置である。記憶装置７０７はハードディスクなどの磁気ディスク装置でもよく、他の種類の記憶装置でもよい。
【０２０８】
記憶装置７０７またはＲＯＭ７０２には、本発明によるプログラムが格納されている。本発明によるプログラムの具体例は、図２の共有メモリ制御部２１３または２１４を実現するミドルウェアのプログラムである。本発明によるプログラムをＣＰＵ７０１が実行することにより、図６〜図９の処理が行われる。
【０２０９】
本発明によるプログラムは、ＬＡＮまたはインターネットなどのネットワーク７１１を介して、プログラム提供者７１２から提供され、記憶装置７０７に記憶され、ＣＰＵ７０１によって実行されてもよい、また、本発明によるプログラムを格納した可搬型記憶媒体７１０が駆動装置７０８にセットされて、格納されたプログラムがＲＡＭ７０３にロードされてＣＰＵ７０１により実行されてもよい。可搬型記憶媒体７１０の例は、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disk）などの光ディスク、光磁気ディスク、フレキシブルディスクなどである。
【０２１０】
なお、本発明は上記の実施形態に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。
上記では主に、２台の装置間のデータの同期化のためのデータ送信に本発明を利用する場合について説明したが、当然その他の目的のデータ送信にも本発明は適用可能である。データ送信の目的によって、受信したパケットの内容を使って具体的にどのような処理を行うかも異なる。
【０２１１】
図２〜図１３の実施形態におけるデータ送信の目的は、データの同期化である。よって、図２のコンピュータ２０２がスタンバイ装置として運用されているとき、共有メモリ制御部２１４は、図９のステップＳ４０５において、受信した共有メモリデータパケット５０４の共有メモリデータフィールドの内容を共有メモリ２０６に反映する。
【０２１２】
しかし、受信したパケットの内容を使うこのような処理は、実施形態に固有のものである。例えば、一般に、ＵＤＰはマルチキャストやブロードキャストにも利用され、リアルタイム性が重視されるストリーミングデータの送信にも利用される。ＵＤＰによるストリーミングデータの送信に本発明を適用する場合は、データ送信の目的はストリーミングデータの再生であろう。その場合、「共有メモリデータパケット」や「共有メモリデータフィールド」という名称は適切ではないものの、共有メモリデータパケット５０４と類似の形式のパケットが送信され、図９のステップＳ４０５は、送信されたパケットに含まれるストリーミングデータを再生する処理、またはストリーミングデータの再生を再生用アプ
リケーションに要求する処理に置き換えられる。
【０２１３】
本発明の適用対象は、ステップＳ４０５以外にも影響することがある。例えば、ある別の実施形態では、パケットの消失が生じた場合に、消失したパケットより後の順序に対応するパケットに関する処理を行わない。例えば、送信通番が「３」のパケットが消失したら、送信通番が「４」のパケットは受信されても破棄される。そのような実施形態では、図９のステップＳ４０４の実行後、ステップＳ４０５は実行されず、処理がステップＳ４０６に進む。
【０２１４】
パケットが消失したときの動作には、共有メモリ制御部２１３を呼び出すユーザアプリケーションの数も影響する。図２には一つのユーザアプリケーション２０７のみを示したが、一般には、複数のユーザアプリケーションが共有メモリ制御部２１３にデータ２０９の反映を要求する。
【０２１５】
例えば、共有メモリ制御部２１３は、ユーザアプリケーションＡ１からの要求を「４」なる送信通番で処理し、ユーザアプリケーションＡ２からの要求を「５」なる送信通番で処理するかもしれない。この場合、「４」なる送信通番に対応する共有メモリデータパケット５０４が消失しても、ユーザアプリケーションＡ２には関係がない。よって、「５」なる送信通番に対応する共有メモリデータパケット５０４は、もし正常にスタンバイ装置２０２で受信されたならば、破棄されるべきではない。その共有メモリデータパケット５０４の共有メモリデータフィールドの内容は、共有メモリ２０６に反映されるべきである。
【０２１６】
一方で、一つのユーザアプリケーションＡ１からのみ共有メモリ制御部２１３が要求を受け付ける実施形態においては、消失したパケットＰ１と、その次のパケットＰ２は必ず同じユーザアプリケーションＡ１のデータを含む。よって、データの整合性を保つために、共有メモリ制御部２１４は、パケットＰ１の消失を検知したらパケットＰ２を破棄したほうがよい場合もある。
【０２１７】
また、データの一部が欠損することを許容するある種のアプリケーションは、パケットが消失してもパケットを再送しない。そのようなユーザアプリケーションと組み合わせて本発明を利用する場合、共有メモリ制御部２１３は、共有メモリデータパケット５０４の送信後、一定時間内にＡＣＫパケット５０５を受信することができずにタイムアウトしたとき、送信が失敗したことをユーザアプリケーションに通知しなくてもよい。
【０２１８】
図９の実施形態では、パケットが消失した場合もステップＳ４０６でＡＣＫパケット５０５を返信している。しかし、消失を示す別種のパケットである「ＡＣＫ‐ＮＧパケット」を定義し、ＡＣＫ‐ＮＧパケットを返信するように図９の処理を変形してもよい。
【０２１９】
もちろん、図９の処理であっても、図１１のシーケンス図から分かるように、送信側の共有メモリ制御部２１３が消失を検知することは可能である。すなわち、連続する二つのＡＣＫパケット５０５の通番フィールドとリフレッシュＩＤフィールドが、連続する順序を表していなければ、共有メモリ制御部２１３は、その不連続の部分でパケットが消失したことを検知することができる。つまり、あるパケットの消失後に正常に受信された別のパケットに対するＡＣＫパケット５０５は、消失を通知する役割も兼ねている。しかし、ＡＣＫ‐ＮＧパケットを適切に定義すれば、共有メモリ制御部２１３は、単にＴＹＰＥ２フィールドの値を読み取るだけで、パケットが生じたか否かを検知することができる。
【０２２０】
なお、リフレッシュ応答パケット５０３などの制御用パケットは、実施形態によっては、一つの経路のみを介して送信してもよい。仮にその一つの経路が異常で、リフレッシュ
応答パケット５０３が正常に受信されなくても、通番管理テーブル６０１と６０２のリフレッシュＩＤを適切に同期させることは可能である。そのためには、例えば、アクティブ装置２０１の共有メモリ制御部２１３がタイムアウトして、再度リフレッシュ要求パケット５０２の送信からやり直せばよい。リフレッシュ要求パケット５０２やＡＣＫパケット５０５も同様に、少なくとも一つの経路を介して送信すればよく、すべての経路を介して送信しなくてもよい。
【０２２１】
また、図２の例では、アクティブ装置とスタンバイ装置が交互に切り換えられるという前提があるので、共有メモリ制御部２１３と２１４はともに、データを送信するための機能と受信するための機能の双方を備えている。しかし、実施形態によっては、一方の装置にはデータを送信する機能のみが組み込まれており、他方の装置にはデータを受信する機能のみが組み込まれていてもよい。
【０２２２】
なお、データを送信するための機能と受信するための機能の双方を備えた二つの装置を組にする例は、図２の例に限らない。図２では、共有メモリデータパケット５０４は必ずアクティブ装置２０１からスタンバイ装置２０２へ送信される。しかし、データの同期化以外の目的で、二つの装置ＸとＹの間でデータをやりとりする通信の場合、装置Ｘから装置Ｙへの送信と、装置Ｙから装置Ｘへの送信の両方が、予測不可能な順序でランダムに生じることがある。そのような場合にも、本発明を適用することは可能である。その場合、リフレッシュＩＤを更新するタイミングが、図２の実施形態とは異なっていてもよい。
【０２２３】
図２の実施形態では、アクティブ装置とスタンバイ装置が切り換えられるたびに、リフレッシュ要求パケット５０２とリフレッシュ応答パケット５０３が送受信され、通番管理テーブル６０１と６０２のリフレッシュＩＤが更新されることを前提としている。この前提は、必須の前提条件ではないものの、管理の簡潔さなどの面から、切り換えをまたいで同じ値のリフレッシュＩＤを使い続けるよりも好ましい。
【０２２４】
一方で、装置Ｘから装置Ｙへの送信と、装置Ｙから装置Ｘへの送信の両方がランダムに生じる場合には、例えば装置Ｘから装置Ｙへの送信があった後で装置Ｙが装置Ｘにパケットを送信しようとするたびにリフレッシュＩＤを更新すると、リフレッシュＩＤの更新が頻繁になりすぎることがある。よって、この場合、送信順序情報のオーバーフロー時と装置の再起動時にのみリフレッシュＩＤを更新するように装置ＸとＹを構成してもよい。
【０２２５】
図２では、共有メモリ制御部２１３と２１４を実現するミドルウェアとして本発明を実施する例を示した。しかし、本発明によるプログラムは、ＯＳに組み込まれていてもよく、アプリケーションプログラムであってもよい。また、本発明によるプログラムは、マルチスレッド・プログラムでなくてもよい。また、本発明は、ソフトウェアすなわちプログラムにより実現されるだけでなく、ハードウェア、ファームウェア、またはこれらの任意の組み合わせにより実現することも可能である。
【０２２６】
上記では、経路の数が２の場合の例について説明したが、三つ以上の経路を用いて本発明を実施することもできる。例えば、三つの経路を用いる場合、図４には、第一経路受信スレッドと第二経路受信スレッド４０７〜４１０のほかに、第三経路受信スレッドを共有メモリ制御部２１３と２１４にそれぞれ追加する必要があり、図３のデータ転送制御表３０１と３０２には、第三経路に関するレコードを追加する必要がある。しかし、三つ以上の経路を用いる場合でも、フローチャートに示した処理の流れは二つの経路を用いる場合と同様である。ただし、実用上は、次のような理由から、二つの経路を利用することが最適である場合が多い。
【０２２７】
・経路の数を増やすことはケーブルなどのハードウェアの増設をともない、費用がかか
る。
・ハードウェアの増設を避けるために、複数の経路がハードウェアを共有することは可能である。しかし、同じハードウェアを共有する経路の数が増えるほど、そのハードウェアでエラーが発生しやすくなる。例えば、同一のケーブルを共有する経路の数を増やすほど、そのケーブル上のトラフィック量が増加し、そのケーブル内で衝突などのエラーが発生しやすくなる。
【０２２８】
・ハードウェアを共有しない二つの経路に故障が同時に発生することは、事実上ほとんどないので、二つの経路だけで実用上十分な信頼性を得ることができる。
また、図５に示したパケットの形式も、実施形態に応じて変形することができる。各フィールドの長さやフィールドの並び順は実施形態によって任意である。また、パケットの種別をＴＹＰＥ１とＴＹＰＥ２により階層的に分類せず、一つのフィールドだけでパケットの種別を示してもよいことは当然である。また、実施形態によってはリフレッシュＩＤフィールドが不要なこともある。
【０２２９】
つまり、送信通番と受信通番の桁数が、実用上、同じ番号を再利用する可能性がないと見なせる程度に十分多い場合などには、リフレッシュＩＤを使う必要がない。このとき、各種パケットにはリフレッシュＩＤフィールドが不要であり、通番管理テーブル６０１と６０２にもリフレッシュＩＤフィールドは不要である。
【０２３０】
例えば、装置を一定の間隔で再起動させるという規則にしたがってシステムが運用される場合、送信通番と受信通番の桁数と、再起動の間隔との関係によっては、リフレッシュＩＤフィールドが不要となる場合がありうる。
【０２３１】
また、上記実施形態の送信通番と受信通番の値は、順序が前であるほど小さい値である。しかし、別の実施形態では、順序が前であるほど大きい値であってもよい。当然その場合は、図６のステップＳ１０２の加算を減算に変え、図９のステップＳ４０３の判定で「より大きい」と「未満」を逆転させる、などの変更をあわせて行う必要がある。
【０２３２】
さらに、送信順序情報と受信順序情報は、順序の前後関係を比較することが可能な情報でさえあれば、上記の実施形態以外の任意の形式でよい。例えば、上記の例の受信通番は、次に受信されると期待されるパケットの送信通番そのものの値である。しかし、別の実施形態では、最後に受信したパケットの送信通番を通番管理テーブル６０１や６０２に受信通番として格納し、格納された受信通番に１を足した値を、受信した共有メモリデータパケット５０４の通番フィールドの値と比較することによって、順序の前後を判定してもよい。この場合、具体的に使われる値が最後に受信したパケットの送信通番であるという点が図６などの例とは異なる。しかし、受信通番が、次に受信されると期待されるパケットの順序を示すための値であることに変わりはない。同様に、送信順序情報と受信順序情報の一部である識別情報も、上記のようなリフレッシュＩＤ以外の任意の形式の情報であってよい。
【０２３３】
以上説明したことを概観すれば本発明は以下のような構成を備えるものである。
（付記１）
データの到達を保証しないプロトコルにより送信元コンピュータから複数の経路のそれぞれを介して、異なるパケット間の送信順序を示す送信順序情報を含めて送信された同内容のパケットを受信して、パケットの重複および消失を判別する処理を送信先コンピュータに制御させる受信プログラムであって、
前記複数の経路のいずれを介して送信された前記パケットでも受信する受信ステップと、
受信した前記パケットから、前記送信順序情報を取得する送信順序情報取得ステップと
、
過去に受信した前記パケットの前記送信順序情報にもとづいて管理され、次に受信されると期待されるパケットに対応する順序を表す受信順序情報を、格納手段から取得する受信順序情報取得ステップと、
前記送信順序情報が表す第一の順序と前記受信順序情報が表す第二の順序を比較する比較ステップと、
前記第一の順序が前記第二の順序よりも前の場合に、前記受信ステップで受信した前記パケットが、過去に受信した他のパケットと重複すると判断する重複判断ステップと、
前記第一の順序と前記第二の順序が等しい場合に、前記格納手段に格納された前記受信順序情報が表す順序が前記第二の順序の次の順序になるよう前記格納手段を更新する正常処理ステップと、
前記第一の順序が前記第二の順序よりも後の場合に、パケットの消失が生じたと判断する消失判断ステップと、
を前記送信先コンピュータに実行させることを特徴とする受信プログラム。
（付記２）
前記受信順序情報は番号を含み、
前記正常処理ステップでは、前記受信順序情報に含まれる前記番号に１を加算または減算することにより、前記受信順序情報が更新される、
ことを特徴とする付記１に記載の受信プログラム。
（付記３）
前記正常処理ステップでさらに前記送信先コンピュータに、前記パケットの送達確認を前記送信元コンピュータへ送信させることを特徴とする付記１に記載の受信プログラム。（付記４）
前記消失判断ステップでさらに前記送信先コンピュータに、前記送信順序情報にもとづいて前記格納手段を更新させることを特徴とする付記１に記載の受信プログラム。
（付記５）
前記消失判断ステップでさらに前記送信先コンピュータに、パケットの消失を前記送信元コンピュータに通知させることを特徴とする付記１に記載の受信プログラム。
（付記６）
前記送信順序情報と前記受信順序情報はいずれも、有限の桁数の番号と、同じ値の前記番号同士を識別するための識別情報の双方を含み、
前記送信元コンピュータから送信された、前記識別情報の更新を要求するリフレッシュ要求パケットを受信した場合は、
前記受信順序情報に含まれる前記識別情報が、前記リフレッシュ要求パケットが指定する値になるよう前記格納手段を更新する識別情報更新ステップと、
前記リフレッシュ要求パケットの送達確認を前記送信元コンピュータへ送信する送達確認ステップと、
をさらに前記送信先コンピュータに実行させることを特徴とする付記１に記載の受信プログラム。
（付記７）
前記比較ステップでは、前記受信ステップで受信した前記パケットに含まれる前記識別情報と、前記受信順序情報に含まれる前記識別情報が等しくなければ、前記第一の順序が前記第二の順序よりも前だと判断される、
ことを特徴とする付記６に記載の受信プログラム。
（付記８）
前記識別情報は、日付または時刻の少なくとも一方にもとづく情報であることを特徴とする付記６に記載の受信プログラム。
（付記９）
前記プロトコルはＵＤＰであることを特徴とする付記１に記載の受信プログラム。
（付記１０）
データの到達を保証しないプロトコルによる送信先コンピュータへのデータの送信処理を送信元コンピュータに制御させる送信プログラムであって、
異なるパケット間の送信順序を示す送信順序情報を格納手段から取得する送信順序情報取得ステップと、
前記格納手段に格納されている前記送信順序情報を更新する送信順序情報更新ステップと、
同じ前記送信順序情報および同じ送信対象のデータを含む、複数の経路のそれぞれに対応する複数のパケットを作成するパケット作成ステップと、
前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記送信先コンピュータに送信する送信ステップと、
を前記送信元コンピュータに実行させることを特徴とする送信プログラム。
（付記１１）
前記送信順序情報は番号を含み、
前記送信順序情報更新ステップでは、前記送信順序情報に含まれる前記番号に１を加算または減算することにより、前記送信順序情報が更新される、
ことを特徴とする付記１０に記載の送信プログラム。
（付記１２）
前記送信順序情報は、有限の桁数の番号と、同じ値の前記番号同士を識別するための識別情報とを含み、
前記番号が所定の値に等しい場合に、前記送信プログラムは、前記送信ステップよりも前に、
前記識別情報を更新する識別情報更新ステップと、
更新された前記識別情報を前記送信先コンピュータに設定するよう要求するリフレッシュ要求パケットを前記送信先コンピュータに送信するリフレッシュ要求ステップと、
前記リフレッシュ要求パケットの送達確認が前記送信先コンピュータから送信されるのを待つ送達確認待ちステップと、
を前記送信元コンピュータに実行させる、
ことを特徴とする付記１０に記載の送信プログラム。
（付記１３）
前記識別情報更新ステップにおいて前記識別情報は、該識別情報更新ステップが実行される日付または時刻の少なくとも一方にもとづいて更新されることを特徴とする付記１２に記載の送信プログラム。
（付記１４）
前記複数の経路のそれぞれの状態を監視する監視ステップをさらに前記送信元コンピュータに実行させ、
前記送信ステップにおいて、前記送信元コンピュータに、前記監視ステップにより前記状態が悪いと判断された前記経路を介した送信を省略させる、
ことを特徴とする付記１０に記載の送信プログラム。
（付記１５）
前記監視ステップは、所定の間隔で前記送信先コンピュータが前記複数の経路のそれぞれを介して前記送信元コンピュータに送信する監視用パケットを受信し、前記監視用パケットの受信間隔にもとづいて前記複数の経路のそれぞれの前記状態を判断するステップであることを特徴とする付記１４に記載の送信プログラム。
（付記１６）
データの到達を保証しないプロトコルにより複数の経路のそれぞれを介して第一のコンピュータが第二のコンピュータにパケットを送信するシステムであって、
前記第一のコンピュータが、
異なるパケット間の送信順序を示す送信順序情報を格納する送信順序情報格納手段と、
前記送信順序情報を取得してから、前記送信順序情報格納手段に格納された前記送信順序情報を更新する送信順序情報更新手段と、
取得された同じ前記送信順序情報および同じ送信対象のデータを含む、前記複数の経路のそれぞれに対応する複数のパケットを作成するパケット作成手段と、
前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記第二のコンピュータに送信する送信手段とを備え、
前記第二のコンピュータが、
前記複数の経路のいずれを介して送信された前記パケットでも受信する受信手段と、
過去に受信した前記パケットの前記送信順序情報にもとづいて管理され、次に受信されると期待されるパケットに対応する順序を表す受信順序情報を格納する受信順序情報格納手段と、
受信した前記パケットに含まれる前記送信順序情報が表す第一の順序と、前記受信順序情報が表す第二の順序を比較して、前記第一の順序が前記第二の順序よりも前の場合は受信した前記パケットが過去に受信した他の前記パケットと重複すると判断し、前記第一の順序が前記第二の順序よりも後の場合はパケットの消失が生じたと判断する比較判断手段と、
前記第一の順序と前記第二の順序が等しい場合に、前記受信順序情報が表す順序が前記第二の順序の次の順序になるよう前記受信順序情報格納手段を更新する正常処理手段と、
を備えることを特徴とするシステム。
（付記１７）
前記第一のコンピュータが、前記第二のコンピュータと同様の受信手段、受信順序情報格納手段、比較判断手段、および正常処理手段を備え、
前記第二のコンピュータが、前記第一のコンピュータと同様の送信順序情報格納手段、送信順序情報更新手段、パケット作成手段、および送信手段を備え、
前記第一のコンピュータから前記第二のコンピュータへの前記パケットの送信と、前記第二のコンピュータから前記第一のコンピュータへの前記パケットの送信の双方が行われる、
ことを特徴とする付記１６のシステム。
（付記１８）
前記第一のコンピュータが第一の記憶装置を備え、
前記第二のコンピュータが第二の記憶装置を備え、
前記第一のコンピュータと前記第二のコンピュータが、それぞれ現用装置と該現用装置に対応する待機装置として機能し、
前記第一の記憶装置に格納されたデータを前記第一のコンピュータが前記第二のコンピュータに送信し、受信したデータを前記第二のコンピュータが前記第二の記憶装置に上書きすることにより、前記第一の記憶装置と前記第二の記憶装置がそれぞれ格納するデータが同期化される、
ことを特徴とする付記１６に記載のシステム。
（付記１９）
データの到達を保証しないプロトコルにより複数の経路のそれぞれを介して、第一の装置が第二の装置に、異なるパケット間の送信順序を示す送信順序情報を含めてパケットを送信する方法であって、
前記第一の装置において、
同じ前記送信順序情報および同じ送信対象のデータを含む、前記複数の経路に対応する複数のパケットを作成し、
前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記第二の装置に送信し、
前記第二の装置において、
前記複数の経路の一つから受信した前記パケットの前記送信順序情報が、過去に受信したパケットの前記送信順序情報と重複する場合は、前記パケットを破棄する、
ことを特徴とする方法。
（付記２０）
前記第二の装置において、
次に受信されると期待されるパケットに対応する順序を表す情報を、過去に受信した前記パケットの前記送信順序情報にもとづいて、受信順序情報として管理し、
受信した前記パケットの前記送信順序情報と前記受信順序情報が表す順序が等しければ、受信した前記パケットを処理する、
ことを特徴とする付記１９に記載の方法。
【図面の簡単な説明】
【０２３４】
【図１】本発明の原理を示す図である。
【図２】本発明を利用してデータの同期化を行う二重化システムの構成図である。
【図３】データ転送制御表の例である。
【図４】共有メモリ制御部を実現するミドルウェアを構成するスレッドのブロック図である。
【図５】各種パケットの形式を説明する図である。
【図６】共有メモリデータ送信処理のフローチャートである。
【図７】リフレッシュ要求受信処理のフローチャートである。
【図８】リフレッシュ応答受信処理のフローチャートである。
【図９】共有メモリデータ受信処理のフローチャートである。
【図１０】初期状態と、その後に続く正常な処理の結果を示す処理シーケンス図である。
【図１１】共有メモリデータパケットが消失する場合の処理シーケンス図である。
【図１２】アクティブ装置を再起動した場合の処理シーケンス図である。
【図１３】送信通番および受信通番のオーバーフローを説明する処理シーケンス図である。
【図１４】本発明のプログラムを実行するコンピュータのブロック図である。
【符号の説明】
【０２３５】
１０１ 送信元コンピュータ
１０２ 送信先コンピュータ
１０３ 送信対象データ
１０４、１０９、１１０ 送信順序情報
１０５、１０６ パケット
１０７、１０８ 経路
１１１ 受信順序情報
２０１ コンピュータ、アクティブ装置
２０２ コンピュータ、スタンバイ装置
２０３ 仮想共有メモリ
２０５、２０６ 共有メモリ
２０７ ユーザアプリケーション
２０９、２１０ データ
２１０ データ
２１１、２１２ ミドルウェア群
２１３、２１４ 共有メモリ制御部
２１５ 第一経路
２１６ 第二経路
３０１、３０２ データ転送制御表
４０１、４０２ ヘルスチェックスレッド
４０３、４０４ データ送信スレッド
４０５、４０６ データ受信スレッド
４０７、４０８ 第一経路受信スレッド
４０９、４１０ 第二経路受信スレッド
４１１〜４１４ ＵＤＰポート
５０１ ヘルスチェックパケット
５０２ リフレッシュ要求パケット
５０３ リフレッシュ応答パケット
５０４ 共有メモリデータパケット
５０５ ＡＣＫパケット
６０１ａ、６０１ｂ、６０２ａ、６０２ｂ 通番管理テーブル
７００ コンピュータ
７０１ ＣＰＵ
７０２ ＲＯＭ
７０３ ＲＡＭ
７０４ 通信インターフェイス
７０５ 入力装置
７０６ 出力装置
７０７ 記憶装置
７０８ 駆動装置
７０９ バス
７１０ 可搬型記憶媒体
７１１ ネットワーク
７１２ プログラム提供者
７１３ 通信相手のコンピュータ
【技術分野】
【０００１】
本発明は、データの到達を保証しないプロトコルによるデータの送信の信頼性を、送信経路を多重化することにより高める技術に関する。
【背景技術】
【０００２】
従来から、様々な分野でネットワークを介したデータの転送が行われている。データの転送は様々なプロトコルにしたがって行われるが、特に、ＴＣＰ（Transmission Control
Protocol）とＵＤＰ（User Datagram Protocol）は広く利用されているプロトコルである。ＴＣＰとＵＤＰはいずれもＯＳＩ（Open Systems Interconnection）参照モデルのトランスポート層（レイヤ４ともいう）のプロトコルであり、ネットワーク層（レイヤ３ともいう）のプロトコルであるＩＰ（Internet Protocol）と組み合わされて広く利用されている。
【０００３】
ＴＣＰとＵＤＰには以下のような違いがあるので、利用分野の性質に応じて、ＴＣＰとＵＤＰのうち適切な方のプロトコルが使われる。
・ＴＣＰは送信先までデータが到達することを保証するプロトコルだが、ＵＤＰはそのような保証をしないプロトコルである。
【０００４】
・送信にエラーが生じた場合、ＴＣＰによるデータ転送では自動的にパケットが再送されるが、ＵＤＰによるデータ転送では単にパケットが破棄されるだけである。
・ＴＣＰは実際の通信を開始する前にコネクションを確立するコネクション型のプロトコルだが、ＵＤＰはコネクションレス型のプロトコルである。
【０００５】
・以上のように、ＴＣＰはデータの送信自体以外の様々な処理が必要なのに対して、ＵＤＰはそのような処理を行わない。したがって、ＴＣＰによるデータ転送よりＵＤＰによるデータ転送の方が高速であり、スループットが高い。逆に言うと、ＴＣＰによるデータ転送は送達確認や再送制御をともなうため信頼性が高いが、ＵＤＰによるデータ転送は信頼性が低い。
【０００６】
ＴＣＰとＵＤＰのどちらのプロトコルを利用するかは、データの量、データを送信する目的、データの種類など、種々の要因を考慮に入れて決められる。一般には、信頼性を重視するアプリケーションではＴＣＰが利用され、処理速度を重視するアプリケーションではＵＤＰが利用されることが多い。しかし、高スループットと高信頼性を両立することが求められる場合もある。
【０００７】
例えば、フォールトトレラントなシステムでは、２台のコンピュータを組にして、一方をアクティブ（現用）装置、他方をスタンバイ（待機）装置として利用することがある。このような構成を採用すると、アクティブ装置に障害が発生しても、アクティブ装置とスタンバイ装置を切り換えることにより、外部にサービスを提供し続けることが可能である。つまり、このような構成により、サービスの可用性（アベイラビリティ）を高められる。
【０００８】
アクティブ装置とスタンバイ装置の切り換えを行うには、まず、アクティブ装置が保持するデータをスタンバイ装置に引き継ぎ、データを同期化する必要がある。アクティブ装置とスタンバイ装置がネットワークを介して接続されている場合、データの引き継ぎは、ネットワークを介したデータ転送をともなう。
【０００９】
サービスの可用性という観点からは、明らかに、アクティブ装置とスタンバイ装置の切り換えにかかる時間は短いほど好ましい。よって、データ同期化のためのデータ転送は、高速であることが望ましい。一方で、このような多重化されたシステムにおいては、現在のアクティブ装置が保持するデータが確実に現在のスタンバイ装置に引き継がれることも必要である。
【００１０】
このような例においては、高スループットというＵＤＰの利点と、ＴＣＰのような高信頼性を両立することが求められている。
ＵＤＰのようにデータの到達を保証しない通信プロトコルを使う場合に、信頼性を高める方法には、一般的に次の第一の方法と第二の方法がある。
【００１１】
第一の方法は、ＵＤＰなどの通信プロトコルを呼び出す上位層のソフトウェアにより、受信側ではデータパケットを受信したら送達確認パケットを返信するよう制御し、送信側では送達確認パケットが受信されなければデータパケットを再送するよう制御する方法である。これにより、通信プロトコル自体に送達確認や再送制御が組み込まれていなくても、送達確認と再送が実現され、信頼性が向上する。
【００１２】
しかし、この方法には、データ送信にエラーが生じると、再送までにある程度の待ち時間がかかってしまうという欠点がある。つまり、エラーの発生がスループットの低下に直結する。もともと、データの到達を保証しない通信プロトコルを使うのは、高スループットが要求される場合が多いので、このように明らかなスループットの低下をともなう方法は望ましくない。
【００１３】
第二の方法は、伝送路を多重化する方法である。すべての伝送路に同時に障害が生じる確率が、無視しても問題がない程度に低ければ、複数の異なる伝送路を介してそれぞれ同じデータを送信することにより、事実上、少なくとも一つの伝送路を介してデータが確実に送信先に届く。しかし、この方法の問題は、データの送信先、すなわち受信側から見ると、複数の伝送路から重複してデータが送られることである。
【００１４】
この問題を解決する一つの方法は、特許文献１と２に記載されているように、受信側の装置が、データを受信する伝送路を選択的に切り換えて、一つの伝送路だけからデータを受信する方法である。
【００１５】
特許文献１のバス型二重化伝送装置は、二つのバス型伝送路にそれぞれ接続された、二つの送信器と、二つの受信器と、二つの異常検出回路とを備える。異常検出回路は、それぞれの伝送路の異常を検出し、その出力は系切換制御回路に接続されている。データ送信時には、二つの送信器から二つのバス型伝送路に同じデータが送信される。データ受信時には、系切換制御回路が系選択器に正常な伝送路を選択させ、選択された伝送路に接続された受信器がデータを受信する。
【００１６】
特許文献２の二重化伝送路切換方式は、二重化された伝送路を介して互いに送受信する伝送装置が、送信時に二つの伝送路を同時に選択し、受信時には正常な一方の伝送路を選択する方式である。特許文献２の発明は、受信する伝送路の切換に伴って発生する次の１フレーム分のデータの棄却の割合、および、前回のフレームに対する診断では正常と診断されていたがフレーム外で異常が発生した伝送路を先着系と誤認する割合を低減することを目的としている。なお、先着系とは、二つの伝送路がともに正常な場合において先にデータを受信した系を指し、受信する伝送路として優先的に選択される。
【特許文献１】特開平８−１６３１５３号公報
【特許文献２】特開平８−２２３１８５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１７】
しかしながら、上記のとおり第一の方法には、データ送信にエラーが生じると、再送までにある程度の時間がかかってしまうという欠点がある。また、上記第二の方法では、伝送路を二重化した利点が十分に活かされないことがある。
【００１８】
例えば、実際には第一の伝送路に故障が発生しており、第二の伝送路は正常なのに、両者とも正常だと誤って判断されて、その結果、第一の伝送路が偶然、データを受信すべき伝送路として選択されることがありうる。このようなことは、伝送路の異常を検出する回路に故障が発生した場合や、伝送路が正常だと判断された直後に実際の故障が発生し、データが送信される場合などに起こりうる。
【００１９】
この例では、実際には第二の伝送路からは正常にデータが送信されているにもかかわらず、受信側の装置は、第二の伝送路がデータを受信すべき伝送路として選択していないため、正常なデータを受信することができない。つまり、第二の伝送路を介して送信された正常なデータを無駄に捨ててしまうことにより、データが正しく送信先に届く割合が低下している。
【００２０】
そこで本発明の目的は、高スループットだがデータの到達を保証しないプロトコルを使って、高スループットと高信頼性という利点を兼ね備えた通信を可能とすることであり、特に、スループットおよび／または信頼性が無駄に低下することを避けることである。
【課題を解決するための手段】
【００２１】
本発明による受信プログラムは、データの到達を保証しないプロトコルにより送信元コンピュータから複数の経路のそれぞれを介して、異なるパケット間の送信順序を示す送信順序情報を含めて送信された同内容のパケットを受信して、パケットの重複および消失を判別する処理を送信先コンピュータに制御させる。
【００２２】
前記受信プログラムは、前記複数の経路のいずれを介して送信された前記パケットでも受信する受信ステップと、受信した前記パケットから、前記送信順序情報を取得する送信順序情報取得ステップと、過去に受信した前記パケットの前記送信順序情報にもとづいて管理され、次に受信されると期待されるパケットに対応する順序を表す受信順序情報を、格納手段から取得する受信順序情報取得ステップと、前記送信順序情報が表す第一の順序と前記受信順序情報が表す第二の順序を比較する比較ステップと、前記第一の順序が前記第二の順序よりも前の場合に、前記受信ステップで受信した前記パケットが、過去に受信した他のパケットと重複すると判断する重複判断ステップと、前記第一の順序と前記第二の順序が等しい場合に、前記格納手段に格納された前記受信順序情報が表す順序が前記第二の順序の次の順序になるよう前記格納手段を更新する正常処理ステップと、前記第一の順序が前記第二の順序よりも後の場合に、パケットの消失が生じたと判断する消失判断ステップと、を前記送信先コンピュータに実行させる。
【００２３】
また、本発明による送信プログラムは、前記送信順序情報を格納手段から取得する送信順序情報取得ステップと、前記格納手段に格納されている前記送信順序情報を更新する送信順序情報更新ステップと、同じ前記送信順序情報および同じ送信対象のデータを含む、前記複数の経路のそれぞれに対応する複数のパケットを作成するパケット作成ステップと、前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記送信先コンピュータに送信する送信ステップと、を前記送信元コンピュータに実行させる。
【００２４】
パケットの送信先と送信元のコンピュータが、それぞれ前記受信プログラムと前記送信プログラムにしたがって動作することにより、少なくとも一つの経路が正常ならば、必ず
パケットが送信先コンピュータに届く。また、複数の経路が正常な場合、複数の同内容のパケットが送信先コンピュータに届くが、重複して届いたパケットは重複したと判断される。一方、送信先コンピュータは、パケットの順序が入れ替わって受信された場合や、複数の経路のすべてが異常でパケットが消失した場合など、送信された順序どおりにパケットを受信することができなかった場合を、上記消失判断ステップにより判別することができる。
【００２５】
本発明は、前記送信元コンピュータおよび前記送信先コンピュータを含むシステム、および前記送信元コンピュータが前記送信先コンピュータにパケットを送信する方法も提供する。
【発明の効果】
【００２６】
本発明によれば、少なくとも一つの経路が正常ならば必ずパケットが送信先コンピュータに届き、重複や消失を送信先コンピュータが判別することができるので、データの到達を保証しないプロトコルを利用していても信頼性が高い。
【００２７】
また、送信先コンピュータは、パケットを受信する経路を切り換えるのではなく、複数の経路のいずれを介して送信されたパケットでも受信する。つまり、送信先コンピュータに到達したパケットは漏れなく受信される。よって、切り換え処理のタイミングや切り換え処理の不具合が原因で信頼性が低下することはない。
【００２８】
データの到達を保証するための種々の処理を含まないプロトコルは、それら種々の処理を含む他のプロトコルに比べて、高スループットという特徴がある。本発明では、そのような高スループットのプロトコルを利用してパケットの送信が行われる。
【００２９】
また、一つの経路のみを利用し、その経路での送信が失敗したことを検知してから再送処理を行う方法では必然的に遅延時間が発生する。しかし、本発明では、一つの経路に異常が発生しても他の経路が正常ならば、特段の遅延時間を必要とせずに、パケットが送信先コンピュータに到達する。
【００３０】
すなわち、本発明によれば、データの到達を保証しないプロトコルを利用して、高信頼性と高スループットを両立させることができる。
【発明を実施するための最良の形態】
【００３１】
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。説明の順序は次のとおりである。まず、図１を参照して本発明の原理を説明した後、図２を参照して本発明を利用したシステムの構成を説明する。その後は、図２の実施形態を例にして、図３のデータ転送制御表、図４のスレッドの構成、図５のパケットの構成、図６〜図９のフローチャート、図１０〜図１３の処理シーケンス図について説明する。その後、本発明のプログラムを実行するコンピュータのブロック図である図１４について説明し、最後に、様々な変形例について説明する。
【００３２】
図１は、本発明の原理を示す図である。図１は、送信対象データ１０３が送信元コンピュータ１０１から送信先コンピュータ１０２に送信される流れを示している。
送信元コンピュータ１０１から送信先コンピュータ１０２に送信する対象のデータは、送信対象データ１０３である。送信元コンピュータ１０１と送信先コンピュータ１０２は複数の通信経路（以下、単に「経路」という）により接続されている。各経路は、有線、無線、またはその組み合わせによる経路である。図１には二つの経路１０７と１０８を図示してある。経路１０７と１０８を介した通信は、データの到達を保証しないプロトコルにより行われる。また、データはそのプロトコルで定義されたパケットの形式で送信され
る。プロトコルの例はＵＤＰである。
【００３３】
送信対象データ１０３が確実に送信先コンピュータ１０２に到達するという意味での信頼性を高めるために、送信元コンピュータ１０１は、複数の経路のそれぞれを介して、同じ送信対象データ１０３を含むパケット１０５と１０６を送信先コンピュータ１０２に送信する。
【００３４】
送信先コンピュータ１０２は、受信したパケットに含まれる送信対象データ１０３を利用して、実施形態に応じた処理を行う。しかし、単に送信元コンピュータ１０１が同内容のパケットを複数送信し、送信先コンピュータ１０２が同じ処理を重複して行うのでは、無駄が多い。よって、重複したパケットを受信した場合はそのパケットを破棄して無駄な処理を回避することが可能なように、送信先コンピュータ１０２に重複を判別させる必要がある。
【００３５】
また、ごくまれに、複数の経路のすべてに異常が同時に発生し、複数のパケットのすべてが消失（ロスト）することもある。経路の状態によっては、複数の異なるパケットが送信された順序とは違う順序で送信先コンピュータ１０２に到達することもある。
【００３６】
一般に、順序の入れ替わりと消失の判別には一定の待ち時間が必要である。例えば、パケットＡ、Ｂがこの順序で送信され、パケットＢがパケットＡよりも先に受信された場合、一定の時間内にパケットＡが受信されれば、順序の入れ替わりが発生したと判明する。そうでなければタイムアウトによりパケットＡが消失したと判断される。よって、順序の入れ替わりの判明にはパケットＢの受信からパケットＡの受信までの待ち時間が必要であり、順序の入れ替わりと消失を区別するにはさらに待ち時間が必要である。
【００３７】
一方、本発明は高信頼性と高スループットの両立を目的としている。高スループットは、処理が速いことの結果得られる特徴である。したがって、以下では、待ち時間を減らして処理を高速化するために、順序の入れ替わりと消失を区別せず、順序の入れ替わりも消失の一種と見なして処理する方法について説明する。
【００３８】
以上のことを考慮して、送信先コンピュータ１０２がパケットの重複や消失を判別することができるように、図１のシステムは構成されている。具体的には、送信元コンピュータ１０１が送信順序情報１０４を管理して、パケット１０５と１０６に送信順序情報１０４を含めて送信先コンピュータ１０２に送信する。送信先コンピュータ１０２は、受信順序情報１１１を管理し、受信したパケット１０５または１０６から送信順序情報１０９または１１０を取得し、取得した送信順序情報１０９または１１０と受信順序情報１１１が表す順序とを比較する。比較の結果、パケットの重複や消失が判断される。なお、送信順序情報１０９と１１０の内容は送信順序情報１０４と同じである。
【００３９】
図１には送信対象データ１０３を表すブロックを一つだけ示したが、実際の環境では、送信元コンピュータ１０１から送信先コンピュータ１０２に、様々なデータに対応する様々なパケットを順々に送信するのが一般的である。送信順序情報１０４は、そのような異なるパケット間の送信順序を示す情報であり、例えば番号を含む。その番号の大小により、送信順序の前後が示される。送信順序情報１０４は、送信元コンピュータ１０１が備える不図示の格納部に格納されており、送信元コンピュータ１０１が備える不図示の送信順序情報更新部により読み取られ、更新される。例えば、格納部はＲＡＭ（Random Access Memory）により実現され、送信順序情報更新部は本発明による送信プログラムを実行するＣＰＵ（Central Processing Unit）により実現される。
【００４０】
送信元コンピュータ１０１が備える不図示のパケット作成部は、同じ送信対象データ１
０３に対しては同じ送信順序情報１０４を付加して、二つのパケット１０５と１０６を作成する。送信元コンピュータ１０１が備える不図示の送信部は、パケット１０５と１０６をそれぞれ経路１０７と１０８を介して送信先コンピュータ１０２に送信する。例えば、パケット作成部は本発明による送信プログラムを実行するＣＰＵにより実現され、送信部はそのＣＰＵと通信インターフェイスにより実現される。
【００４１】
二つの経路がともに正常なら、送信先コンピュータ１０２の不図示の受信部はパケット１０５と１０６を正常に受信する。送信先コンピュータ１０２の不図示の比較判断部は、パケット１０５をパケット１０６より早く受信した場合は、パケット１０６を重複したパケットだと判断する。逆に、パケット１０６をパケット１０５より早く受信した場合は、比較判断部は、パケット１０５を重複したパケットだと判断する。例えば、受信部は本発明の受信プログラムを実行するＣＰＵと通信インターフェイスにより実現され、比較判断部も同じＣＰＵにより実現される。
【００４２】
このようにパケットの重複を判別することができるのは、送信先コンピュータ１０２が受信順序情報１１１を管理しているためである。受信順序情報１１１は、送信先コンピュータ１０２が過去に受信したパケットに含まれる送信順序情報にもとづいて管理され、送信先コンピュータ１０２が備える不図示の格納部に格納されている。格納部は例えばＲＡＭである。受信順序情報１１１は、次に受信されると期待されるパケットに対応する順序を表す。
【００４３】
送信順序情報１０４と受信順序情報１１１について、理解を容易にするため、簡単な例で説明する。送信順序情報１０４は昇順で順序を表す番号を含み、その番号により順序が表される。つまり、この例では、「１」が表す順序の次の順序は「２」により表され、「２」が表す順序の次の順序は「３」により表される。
【００４４】
送信元コンピュータ１０１から送信先コンピュータ１０２に送信されるデータのうち、送信対象データ１０３は「２」が表す順序に対応すると仮定する。また、「１」が表す順序に対応する別のパケットは、既に送信先コンピュータ１０２に正常に送信されており、パケット１０５がパケット１０６よりも先に受信されたと仮定する。
【００４５】
送信順序情報１０４が「２」という番号を含む場合、送信先コンピュータ１０２の比較判断部は受信したパケット１０５と１０６からそれぞれ、「２」という番号を含む送信順序情報１０９と１１０を取得することができる。また、送信先コンピュータ１０２は「１」が表す順序に対応する別のパケットを過去に受信済みなので、パケット１０５を受信した時点では、次に「２」が表す順序に対応するパケットが受信されることを期待している。この期待している順序を表す情報が受信順序情報１１１である。受信順序情報１１１も送信順序情報１０４と同様に昇順で順序を表す番号を含んでいてもよい。例えば、この時点における受信順序情報１１１は、「２」という番号を含んでもよい。
【００４６】
以上の仮定のもとで送信先コンピュータ１０２の受信部がパケット１０５を受信すると、パケット１０５から取得した送信順序情報１０９が表す順序と受信順序情報１１１が表す順序が等しい。このことは、期待していたとおりの順序に対応するパケットが正常に受信されたことを表す。よって、送信先コンピュータ１０２は、パケット１０５に含まれる送信対象データ１０３を利用して、実施形態に応じた必要な処理を行う。また、パケット１０５の受信により、次に受信されると期待されるパケットに対応する順序は一つ後ろにずれ、「３」により表される順序となる。よって、送信先コンピュータ１０２の不図示の正常処理部は、受信順序情報１１１が含む番号を「３」に更新する。例えば、正常処理部は本発明の受信プログラムを実行するＣＰＵにより実現される。
【００４７】
その後、送信先コンピュータ１０２の受信部はパケット１０６を受信する。パケット１０６から取得される送信順序情報１１０は「２」という番号を含み、上記で更新された受信順序情報１１１は「３」という番号を含む。つまり、送信順序情報１１０の方が受信順序情報１１１よりも早い順序を表す。したがって、パケット１０６は過去に受信した他のパケットと重複していると送信先コンピュータ１０２の比較判断部が判断する。実際、パケット１０６は、パケット１０５と同じ送信対象データ１０３および同じ送信順序情報１０４を含んでおり、パケット１０５と重複している。送信先コンピュータ１０２において、重複していると判断されたパケット１０６が含む送信対象データ１０３は利用されず、破棄される。それにより、同じデータに対して無駄に重複して同じ処理を行う時間をなくしている。
【００４８】
次に、パケットの消失について、上記とは一部仮定を変えて説明する。まず、「１」が表す順序に対応するパケットを送信先コンピュータ１０２が正常に受信済みであり、「２」が表す順序に対応するパケットは、経路１０７と１０８の双方で消失したと仮定する。この段階で、送信先コンピュータ１０２が次に受信すると期待しているパケットは「２」が表す順序に対応するから、受信順序情報１１１は「２」という番号を含む。
【００４９】
その後、「３」が表す順序に対応して、送信元コンピュータ１０１は、「３」という番号を含む送信順序情報１０４と送信対象データ１０３とを含むパケット１０５と１０６を作成し、経路１０７と経路１０８のそれぞれを介して送信先コンピュータ１０２に送信する。以下では、パケット１０５がパケット１０６よりも先に受信されたと仮定する。
【００５０】
すると、送信先コンピュータ１０２の比較判断部は、パケット１０５から送信順序情報１０９を取得する。そして、送信順序情報１０９が含む「３」という番号は、受信順序情報１１１が含む「２」という番号よりも後の順序であることから、送信先コンピュータ１０２の比較判断部は、パケットの消失が生じたと判断することができる。
【００５１】
図２は、本発明を利用してデータの同期化を行う二重化システムの構成図である。図２の二重化システムは、同様の構成を有する二つのコンピュータ２０１と２０２を組にして、一方をアクティブ装置、他方をスタンバイ装置として運用するシステムである。アクティブ装置に故障が発生した場合や、アクティブ装置のハードウェアを交換する必要がある場合などには、アクティブ装置とスタンバイ装置が切り換えられる。このようにシステムを二重化することにより、システムはフォールトトレラントなものとなり、サービスの可用性が向上する。
【００５２】
以下では、アクティブ装置とスタンバイ装置の切換に必要なデータの同期化のために、ＵＤＰによるデータ転送が行われる場合を例に説明する。本発明を利用することにより、図２のシステムにおいてデータの即時的な同期化が可能となる。なお、以下では特に断らない限り、「パケット」という語はＵＤＰパケットを意味する。
【００５３】
図２は、左側に示したコンピュータ２０１がアクティブ装置として運用され、右側に示したコンピュータ２０２がスタンバイ装置として運用されている状態を表している。なお、「アクティブ装置」と「スタンバイ装置」という呼び方は相対的であり、切り換えが生じれば逆転する。しかし、以下では特に断らない限り、図２の状態を前提とし、これら2台のコンピュータを単に「アクティブ装置２０１」および「スタンバイ装置２０２」と表現する。２台のコンピュータのどちらをアクティブ装置として運用している状態であるかに関わらず、コンピュータ自体を識別する必要がある場合にのみ、２台のコンピュータを「コンピュータ２０１」および「コンピュータ２０２」と表現する。
【００５４】
アクティブ装置２０１は一般的なコンピュータであり、スタンバイ装置２０２と同期化
すべきデータが格納される共有メモリ２０５と、不図示のＣＰＵとを備える。共有メモリ２０５はＲＡＭなどの揮発性メモリであり、ハードディスクなどの不揮発性領域に比べてアクセス速度が格段に速い。なお、同期化の処理自体に必要なデータを格納する不図示の他のメモリ領域もコンピュータ２０１は備えている。その領域を以下では「制御用データ領域」と呼ぶ。本実施形態では、コンピュータ２０１が備えるＲＡＭの一部が共有メモリ２０５として利用され、その残りが制御用データ領域として利用される。制御用データ領域には、図１の送信順序情報１０４や受信順序情報１１１が格納される。スタンバイ装置２０２も共有メモリ２０６と不図示のＣＰＵを備え、アクティブ装置２０１と同様に構成されている。
【００５５】
図２のシステムは、アクティブ装置２０１とスタンバイ装置２０２の切換時間を短縮するために、共有メモリ２０５と２０６に格納されたデータを即時的に同期化する。本実施形態では、同期化にかかるわずかな時間を除き、共有メモリ２０５と２０６は常に同じデータを格納した状態である。よって、仮想的には、アクティブ装置２０１とスタンバイ装置２０２が一つのメモリ領域を共有していると見なすこともできる。そのため、共有メモリ２０５と２０６をまとめて仮想共有メモリ２０３と表している。また、共有メモリ２０５と２０６の名称に「共有」という語がつくのは、仮想共有メモリ２０３の構成要素であるためである。
【００５６】
アクティブ装置２０１の不図示のＣＰＵにより、一つ以上のユーザアプリケーション２０７が実行されている。なお、各種の処理を実行するのは正確にはＣＰＵだが、以下では表記の簡略化のため、「ユーザアプリケーション２０７が処理を実行する」などの表現することがある。
【００５７】
アクティブ装置２０１には、ＯＳ（Operating System）に加えて、ＯＳとユーザアプリケーション２０７を仲介する種々のミドルウェアからなるミドルウェア群２１１がインストールされている。ミドルウェア群２１１に含まれるミドルウェアの一つが、ＵＤＰを使ったデータの同期化を制御する。図２ではそのミドルウェアを、共有メモリ制御部２１３という機能的なブロックで表している。共有メモリ制御部２１３を実現するミドルウェアは、本実施形態における本発明の送信プログラムおよび受信プログラムを含む。
【００５８】
アクティブ装置２０１とスタンバイ装置２０２は同様の構成を備えている。すなわち、スタンバイ装置２０２にもＯＳとミドルウェア群２１２がインストールされており、ミドルウェア群２１２は共有メモリ制御部２１４を含む。なお、ユーザアプリケーション２０７と同様のユーザアプリケーションがスタンバイ装置２０２にもインストールされているが、スタンバイ状態においては実行されていないので、図示していない。
【００５９】
ユーザアプリケーション２０７の実行は、一般に、共有メモリ２０５のデータの変更をともなう。よって、共有メモリ２０５と２０６の同期を保つために、本実施形態では、共有メモリ２０５のデータが変更されるたびに、必ずスタンバイ装置２０２の共有メモリ２０６にその変更が反映される。共有メモリ２０５や２０６のような揮発性メモリ領域へのアクセスは、ハードディスクなどの不揮発性領域へのアクセスに比べて高速なので、その反映は高速に行うことが可能である。また、その反映のためにアクティブ装置２０１とスタンバイ装置２０２の間で行われるデータ送信は、本発明を利用することにより、スループットと信頼性がともに高い。高スループットは、換言すれば、処理が高速であることを意味する。結局、共有メモリ２０５と２０６は、非常に迅速に同期化される。
【００６０】
共有メモリ２０５と２０６の同期化には、アクティブ装置２０１とスタンバイ装置２０２の間の複数の通信路が利用される。本実施形態における通信路の数は２であり、以下では二つの通信路を第一経路２１５および第二経路２１６と呼ぶ。また、本実施形態で使わ
れる通信プロトコルはＵＤＰである。ＵＤＰによる通信機能は一般にＯＳにより提供されるので、ＯＳの上位のミドルウェアにより実現される共有メモリ制御部２１３および２１４は、ＵＤＰを利用して第一経路２１５または第二経路２１６を介した通信を行うことができる。
【００６１】
図２において、ユーザアプリケーション２０７がデータ２０９を共有メモリ２０５に書き込む操作を「（１）Ｗｒｉｔｅ」と表記し、ユーザアプリケーション２０７から共有メモリ２０５への矢印により表した。
【００６２】
この書き込み操作の後、ユーザアプリケーション２０７は共有メモリ制御部２１３を呼び出し、共有メモリ２０５と２０６を同期化させる。この同期化の操作を図２では「（２）Ｃｏｍｍｉｔ」と表記した。また、同期化が終了するまでユーザアプリケーション２０７が待つことを図２では「（３）Ｗａｉｔ」と表記した。
【００６３】
図２の「（２）Ｃｏｍｍｉｔ」から「（３）Ｗａｉｔ」までの処理の流れを、矢印に沿って説明すれば次のごとくである。
まず、ユーザアプリケーション２０７から点Ａまでの線に示すように、ユーザアプリケーション２０７は、（１）の書き込み操作で共有メモリ２０５に書き込んだデータ２０９と同じデータを共有メモリ制御部２１３に与える。矢印は点Ａで二つに分岐し、一方は第一経路２１５を介して点Ｂへ進み、他方は第二経路２１６を介して点Ｄに進む。この分岐は、共有メモリ制御部２１３が、データ２０９を含むパケットを二つの経路のそれぞれを介してスタンバイ装置２０２に送信することを表す。
【００６４】
二つの経路を介して送信されたパケットは、いずれも、スタンバイ装置２０２の共有メモリ制御部２１４が受信する。図２では、第一経路２１５を介して送信されたパケットの方が、第二経路２１６を介して送信されたパケットよりも早く受信されたと仮定している。前者の受信は点Ｂに対応し、後者の受信は点Ｄに対応する。点Ｂでは、矢印が二つに分岐し、後続の処理に続くことを示している。
【００６５】
一方、点Ｄは矢印の終点である。点Ｄが終点であることは、第二経路２１６を介して受信したパケットが破棄されることに対応する。破棄されるのは、既に第一経路２１５を介して受信したパケットと重複するパケットだと共有メモリ制御部２１４により判断されるためである。
【００６６】
点Ｂで分岐した一方の矢印は、共有メモリ２０６内のデータ２１０を指している。これは、共有メモリ制御部２１４が、受信したデータを共有メモリ２０６に書き込むことを表す。
【００６７】
点Ｂで分岐した他方の矢印は、点Ｃに進み、点Ｃでさらに二つに分岐している。点Ｃは、共有メモリ制御部２１４がアクティブ装置２０１に処理結果を伝えるメッセージ、具体的には後述のＡＣＫパケットを送信することに対応する。点Ｃでの分岐は、ＡＣＫパケットが第一経路２１５と第二経路２１６のそれぞれを介して送られることを表す。
【００６８】
図２では、第二経路２１６を介して送信されたＡＣＫパケットの方が、第一経路２１５を介して送信されたＡＣＫパケットよりも早く受信されたと仮定している。前者は、点Ｃで分岐して第二経路２１６と共有メモリ制御部２１３を通り、ユーザアプリケーション２０７で終わる矢印に対応し、後者は、点Ｃで分岐して第一経路２１５を通り点Ｅで終わる矢印に対応する。つまり、共有メモリ制御部２１３からユーザアプリケーション２０７への通知は、先に共有メモリ制御部２１３で受信された一方のＡＣＫパケットにのみもとづいてなされる。ユーザアプリケーション２０７はその通知をもって共有メモリ２０５と２
０６の同期化が終了したことを検知し、（３）の待ち状態から脱する。
【００６９】
点Ｅは、他方のＡＣＫパケットが後で共有メモリ制御部２１３に受信されることに対応する。つまり、点Ｅは、データ２０９の同期化に関する応答であるＡＣＫパケットを、第二経路２１６から受信した後の時点に対応しているので、点Ｅで二度目に受信したＡＣＫパケットは不要である。よって、共有メモリ制御部２１３はこの不要なＡＣＫパケットを無視する。
【００７０】
以上のようにして、ユーザアプリケーション２０７がデータ２０９を共有メモリ２０５に書き込むたびに、同じ内容のデータ２１０が共有メモリ２０６にも書き込まれ、共有メモリ２０５と２０６が同期化される。
【００７１】
また、この同期化に使われる通信プロトコルはＵＤＰなので、同期化のためのデータ送信にかかる時間は、ＴＣＰを使う場合に比べて短時間である。一方で、第一経路２１５と第二経路２１６という二つの異なる経路に同時に故障が発生することはほとんどないので、ほぼ確実に、データの同期化を達成することができる。
【００７２】
また、第一経路２１５と第二経路２１６のうち一方に故障が発生しても、正常な経路を介して正常に受信されたデータを共有メモリ制御部２１４が共有メモリ２０６に書き込むことにより同期化が達成される。つまり、各経路を介した送信にかかる時間のばらつきが極端に大きくなければ、たとえ一方の経路に故障が発生しても、両経路とも正常な場合の同期化のタイミングに比べて同期化のタイミングが大きく遅れることはない。この点も、データの同期化が高速であるという特徴に寄与している。
【００７３】
次に、図３を参照して、図２のコンピュータ２０１と２０２がそれぞれ管理するデータ転送制御表３０１と３０２の例を説明する。図３に示すように、データ転送制御表３０１と３０２は、同じ形式であり、それぞれ例えばＲＡＭ上の制御用データ領域に格納されている。
【００７４】
データ転送制御表３０１と３０２の内容は、コンピュータ２０１と２０２のどちらがアクティブ装置として運用されているかに関係ない。つまり、データ転送制御表３０１と３０２は、図２の状態を前提としていない。よって、図３の説明においては、「アクティブ装置２０１」と「スタンバイ装置２０２」ではなく、「コンピュータ２０１」と「コンピュータ２０２」と表現する。
【００７５】
データ転送制御表３０１は、第一経路２１５と第二経路２１６についてそれぞれ、「自分のＩＰアドレス」、「通信相手のＩＰアドレス」、「自分のポート番号」、「通信相手のポート番号」、「状態」というフィールドを有している。データ転送制御表３０２も同様の形式である。
【００７６】
ＵＤＰを用いた通信では、送信先と送信元が、ＩＰアドレスとポート番号の組であるソケットアドレスにより表される。よって、第一経路２１５のコンピュータ２０１側の端点は、データ転送制御表３０１の「自分のＩＰアドレス」と「自分のポート番号」を組にした「１９２．１６８．１．１００：６１００」である。このソケットアドレスは、データ転送制御表３０２では逆に、「通信相手のＩＰアドレス」と「通信相手のポート番号」の組により表される。
【００７７】
一方、第一経路２１５のコンピュータ２０２側の端点は、データ転送制御表３０１の「通信相手のＩＰアドレス」と「通信相手のポート番号」を組にした「１９２．１６８．１．２００：６２００」である。このソケットアドレスは、データ転送制御表３０２では「
自分のＩＰアドレス」と「自分のポート番号」の組により表される。
【００７８】
データ転送制御表３０１と３０２の「状態」は、「正常」または「異常」という値を取る。データ転送制御表３０１の「状態」の値は、第一経路２１５と第二経路２１６の監視結果に応じて、動的に書き換えられる。データ転送制御表３０２についても同様である。
【００７９】
図３の例では、第一経路２１５が「１９２．１６８．１．１００：６１００」と「１９２．１６８．１．２００：６２００」という二つのソケットアドレスにより定義され、第二経路２１６が「１０．１．１．１００：７１００」と「１０．１．１．２００：７２００」という二つのソケットアドレスにより定義されている。つまり、第一経路２１５と第二経路２１６では、ＩＰアドレスもポート番号も異なる。
【００８０】
例えば、コンピュータ２０１に２枚のＮＩＣ（Network Interface Card）を取り付け、それぞれのＮＩＣに別のＩＰアドレスを割り当てることにより、図３の例のように、１台のコンピュータ２０１に異なる二つのＩＰアドレスを割り当てることが可能である。さらに、第一経路２１５と第二経路２１６は、ケーブルなどの物理的な媒体も異なることが望ましい。
【００８１】
なお、実施形態によっては、例えば、第一経路２１５または第二経路２１６のコンピュータ２０１側のＩＰアドレスが同じであってもよい。たとえＩＰアドレスが同じでも、異なるポート番号を用いることにより、二つの経路を区別することができるからである。
【００８２】
また、図３のような設定であっても、経路の物理的な媒体自体は、第一経路２１５と第二経路２１６が共有することも可能である。例えば、コンピュータ２０１と２０２が、１台のスイッチングハブを介して接続され、コンピュータ２０１とスイッチングハブの間およびコンピュータ２０２とスイッチングハブの間はそれぞれ１本のケーブルで接続されていてもよい。ただし、このように複数の経路が物理的な媒体を共有すると、一つの媒体のトラフィック量が多くなるために、データの衝突（コリジョン）などが発生しやすくなり、結果的に全体的な処理速度の低下を招くことがある。よって、異なる経路は異なる物理的媒体により実現することが望ましい。
【００８３】
図４は、共有メモリ制御部２１３と２１４を実現するミドルウェアを構成するスレッドのブロック図である。図２に示したように、本実施形態では、コンピュータ２０１と２０２が同様の構成を備え、アクティブ装置とスタンバイ装置は切り換え可能である。したがって、共有メモリ制御部２１３には、コンピュータ２０１がアクティブ装置として運用される場合のために、データをコンピュータ２０２に送信する機能が必要であり、コンピュータ２０１がスタンバイ装置として運用される場合のために、データをコンピュータ２０２から受信して共有メモリ２０５に反映する機能が必要である。共有メモリ制御部２１４も共有メモリ制御部２１３と同様である。
【００８４】
具体的には、共有メモリ制御部２１３と２１４はそれぞれ、ＵＤＰポート４１１と４１２を介して第一経路２１５へのデータ送信および第一経路２１５からのデータ受信が可能なように構成されている。また、共有メモリ制御部２１３と２１４はそれぞれ、ＵＤＰポート４１３と４１４を介して第二経路２１６へのデータ送信および第二経路２１６からのデータ受信が可能なようにも構成されている。
【００８５】
共有メモリ制御部２１３と２１４を実現するミドルウェアは、図４の実施形態ではマルチスレッド・プログラムである。具体的には、コンピュータ２０１の不図示のＣＰＵがヘルスチェックスレッド４０１、データ送信スレッド４０３、データ受信スレッド４０５、第一経路受信スレッド４０７、および第二経路受信スレッド４０９を実行することにより
共有メモリ制御部２１３が実現される。同様に、コンピュータ２０２の不図示のＣＰＵがヘルスチェックスレッド４０２、データ送信スレッド４０４、データ受信スレッド４０６、第一経路受信スレッド４０８、および第二経路受信スレッド４１０を実行することにより、共有メモリ制御部２１４が実現される。
【００８６】
以下では共有メモリ制御部２１３について説明するが、共有メモリ制御部２１４でも同様である。
ヘルスチェックスレッド４０１は、第一経路２１５と第二経路２１６の状態を監視する。具体的には、ヘルスチェックスレッド４０１は、一定間隔でコンピュータ２０２から送信される、経路の状態を監視するためのパケットの受信間隔にもとづいて、経路の状態を判断する。その監視用のパケットを以下では「ヘルスチェックパケット」と呼び、具体的な形式は図５とあわせて後述する。
【００８７】
コンピュータ２０２からヘルスチェックパケットが送信される間隔ｈ１は予め決められており、例えばｈ１＝１秒である。コンピュータ２０２から第一経路２１５を介して送信されたヘルスチェックパケットは、第一経路受信スレッド４０７により受信される。第一経路受信スレッド４０７は、ヘルスチェックパケットを受信すると、ヘルスチェックパケットの受信をヘルスチェックスレッド４０１に通知する。
【００８８】
ヘルスチェックスレッド４０１は、第一経路受信スレッド４０７からの今回の通知と、前回の通知との間隔ｈを調べる。その間隔ｈが規定時間ｈ２以内であれば、ヘルスチェックスレッド４０１はデータ転送制御表３０１の「第一経路」レコードの「状態」フィールドの値を「正常」に設定し、そうでなければ「異常」に設定する。規定時間ｈ２は、経路の状態を正常と見なしうる許容範囲を示す値で、予め決められたヘルスチェックパケットの送信間隔ｈ１よりも少しだけ大きな値である。送信間隔ｈ１と規定時間ｈ２は、実験等から適切な値を定めることが望ましい。
【００８９】
第二経路２１６についても同様にして、ヘルスチェックスレッド４０１が状態を監視し、その監視の結果をデータ転送制御表３０１に反映する。
コンピュータ２０２において、コンピュータ２０１にヘルスチェックパケットを送信するのは、具体的にはヘルスチェックスレッド４０２である。ヘルスチェックスレッド４０２は、第一経路２１５と第二経路２１６のそれぞれについて、データ転送制御表３０２を参照して「通信相手のＩＰアドレス」と「通信相手のポート番号」宛てのヘルスチェックパケットを生成する。ヘルスチェックスレッド４０２は、第一経路２１５へはＵＤＰポート４１２から、第二経路２１６へはＵＤＰポート４１４から、生成したヘルスチェックパケットを送出する。
【００９０】
また、ヘルスチェックスレッド４０２も、上記と同様の方法で第一経路２１５と第二経路２１６の状態を監視し、データ転送制御表３０２の「状態」フィールドの値を動的に設定している。そして、ヘルスチェックスレッド４０１も、ヘルスチェックスレッド４０２が第一経路２１５と第二経路２１６の状態を監視することができるように、送信間隔ｈ１でヘルスチェックパケットをコンピュータ２０２に二つの経路を介して送信している。
【００９１】
すなわち、本実施形態では、コンピュータ２０１と２０２のどちらがアクティブ装置であるかに関わらず、ヘルスチェックスレッド４０１と４０２は両方とも、ヘルスチェックパケットの送信、およびヘルスチェックパケットの受信間隔ｈにもとづく経路の状態の監視を行っている。
【００９２】
データ送信スレッド４０３は、コンピュータ２０１がアクティブ装置として運用されているとき、送信対象のデータ、すなわち共有メモリ２０５に書き込まれたデータ２０９を
、スタンバイ装置として運用されているコンピュータ２０２へ送信する。データ２０９は図１の送信対象データ１０３に相当する。データ２０９はＵＤＰパケットの形式で送信される。そのＵＤＰパケットを以下では「共有メモリデータパケット」と呼び、形式は図５とあわせて後述する。共有メモリデータパケットは、図１のパケット１０５と１０６に相当する。
【００９３】
また、データ送信スレッド４０３は、コンピュータ２０１がスタンバイ装置として運用されているとき、アクティブ装置として運用されているコンピュータ２０２から送信されたパケットに対する送達確認をコンピュータ２０２へ送信する。この送達確認も、具体的にはＵＤＰパケットの一種であり、以下では「ＡＣＫパケット」と呼ぶ。ＡＣＫパケットの形式の詳細は図５とあわせて後述する。
【００９４】
いずれの場合も、データ送信スレッド４０３は、送信すべきＵＤＰパケット、より正確には、そのＵＤＰパケットをカプセル化して得られるＩＰパケットを生成する。その生成に際して、データ送信スレッド４０３は、データ転送制御表３０１を参照して送信元と送信先のＩＰアドレスおよびポート番号を設定する。また、データ送信スレッド４０３はデータ転送制御表３０１を参照して、「状態」フィールドの値が「正常」である経路だけから生成したパケットを送信する。
【００９５】
共有メモリ制御部２１４におけるデータ送信スレッド４０４も、データ送信スレッド４０３と同様である。
データ受信スレッド４０５は、第一経路受信スレッド４０７および第二経路受信スレッド４０９が受信したデータを適宜処理する。具体的には、データ受信スレッド４０５は、コンピュータ２０１がアクティブ装置として運用されているか否かによらず、コンピュータ２０２から送られた各種の制御用パケットを処理する。また、コンピュータ２０１がスタンバイ装置として運用されているとき、データ受信スレッド４０５はさらに、共有メモリデータパケットを処理する。その処理は、共有メモリデータパケットの重複や消失を判断すること、重複していない共有メモリデータパケットの内容を共有メモリ２０５に反映すること、必要に応じてＡＣＫパケットを送信するようデータ送信スレッド４０３に要求すること、を含む。
【００９６】
第一経路受信スレッド４０７は、データ転送制御表３０１の「第一経路」レコードの「自分のＩＰアドレス」と「自分のポート番号」の値が宛先に指定されたパケットを待ち合わせる。つまり、第一経路受信スレッド４０７は、第一経路２１５を介してＵＤＰポート４１１にパケットが送信されるのを常に監視し、送信されたパケットを受信する。そして、第一経路受信スレッド４０７は、受信したパケットがヘルスチェックパケットか否かを判断し、ヘルスチェックパケットならヘルスチェックスレッド４０１にヘルスチェックパケットの受信を通知し、そうでなければ受信したパケットの処理をデータ受信スレッド４０５に要求する。
【００９７】
第二経路受信スレッド４０９も同様に、データ転送制御表３０１の「第二経路」レコードの「自分のＩＰアドレス」と「自分のポート番号」の値が宛先に指定されたパケットを待ち合わせる。そして、第二経路受信スレッド４０９は、受信したパケットがヘルスチェックパケットか否かを判断し、ヘルスチェックパケットならヘルスチェックスレッド４０１にヘルスチェックパケットの受信を通知し、そうでなければ受信したパケットの処理をデータ受信スレッド４０５に要求する。
【００９８】
共有メモリ制御部２１４におけるデータ受信スレッド４０６、第一経路受信スレッド４０８、および第二経路受信スレッド４１０も、上記と同様である。
なお、受信に関してはデータ受信スレッド４０５と第一経路受信スレッド４０７と第二
経路受信スレッド４０９の三つがあるのに対し、送信に関してはデータ送信スレッド４０３のみである理由は、図３がスレッドを示す図だからである。パケットはいつ受信されるかが不明なため、本実施例では、常にＵＤＰポート４１１を監視する第一経路受信スレッド４０７と、常にＵＤＰポート４１３を監視する第二経路受信スレッド４０９と、受信したパケットに関する実質的な処理を行うデータ受信スレッド４０５を分けてある。一方、パケットを送信する場合は、送信のタイミング、送信元のＵＤＰポート、送信するパケットの種別はすべてデータ送信スレッド４０３が把握している。よって、データ送信スレッド４０３だけで、送信すべきパケットの生成から実際の送信までを行うことが容易でもあり自然でもある。
【００９９】
次に、図５を参照して、本実施形態において利用される各種パケットの形式を説明する。上記のとおり、本実施形態では通信プロトコルとしてＵＤＰが利用される。また、周知のように、ＵＤＰパケットはＵＤＰヘッダとオプションのペイロード部分からなり、ＵＤＰヘッダは送信元と送信先のポート番号を含む。図５に示した五種のパケットは、いずれもＵＤＰパケットであり、本実施形態に特有の独自のフィールドをペイロード部分に有する。それらの独自のフィールドの値によって、図５に示した五種のパケットは判別される。
【０１００】
具体的には、ヘルスチェックパケット５０１は、ペイロード部に「ＴＹＰＥ１」というフィールドのみを含み、その値は括弧内に示したように、本実施形態では「１」である。リフレッシュ要求パケット５０２とリフレッシュ応答パケット５０３は、ペイロード部に「ＴＹＰＥ１」と「ＴＹＰＥ２」と「リフレッシュＩＤ」という三つのフィールドを含む。リフレッシュ要求パケット５０２とリフレッシュ応答パケット５０３の役割については後述する。共有メモリデータパケット５０４は、ペイロード部に「ＴＹＰＥ１」と「ＴＹＰＥ２」と「リフレッシュＩＤ」と「通番」と「共有メモリデータ」という五つのフィールドを含む。ＡＣＫパケット５０５は、ペイロード部に「ＴＹＰＥ１」と「ＴＹＰＥ２」と「リフレッシュＩＤ」と「通番」という四つのフィールドを含む。各フィールドの長さは、実施形態に応じて適宜決めてよい。
【０１０１】
ＴＹＰＥ１とＴＹＰＥ２は、パケットの種別を示すフィールドである。ＴＹＰＥ１が上位の分類を表し、ＴＹＰＥ２が下位の分類を表す。図５では値の例を括弧の中に示したが、その値の例からも分かるように、五種のパケットは、ＴＹＰＥ１フィールドの値によりヘルスチェックパケット５０１とそれ以外のものの二種類に分類される。後者はさらに、ＴＹＰＥ２フィールドの値によって、四種類に分類される。
【０１０２】
図４の第一経路受信スレッドまたは第二経路受信スレッド４０７〜４１０は、ＵＤＰヘッダとＴＹＰＥ１フィールドのみをチェックする。ＵＤＰヘッダが適切であり、ＴＹＰＥ１フィールドの値が１なら、第一経路受信スレッドまたは第二経路受信スレッド４０７〜４１０は、受信したパケットがヘルスチェックパケット５０１であると判断し、ヘルスチェックパケット５０１の受信をヘルスチェックスレッド４０１または４０２に通知する。
【０１０３】
一方、ＵＤＰヘッダが適切であり、ＴＹＰＥ１フィールドの値が２なら、第一経路受信スレッドまたは第二経路受信スレッド４０７〜４１０は、受信したパケットがヘルスチェックパケット５０１以外であると判断し、受信したパケットの処理をデータ受信スレッド４０５または４０６に要求する。データ受信スレッド４０５と４０６は、ヘルスチェックパケット５０１以外の種別のパケットのみを処理する。データ受信スレッド４０５と４０６は、ＴＹＰＥ２フィールドの値にもとづいてパケットの種別を判別し、パケットの種別に応じた処理を行う。
【０１０４】
リフレッシュＩＤフィールドと通番フィールドの値は、データ送信スレッド４０３また
は４０４により設定される。この二つのフィールドの値を組み合わせた情報が、図１の送信順序情報１０４に相当する。
【０１０５】
共有メモリデータフィールドは、共有メモリデータパケット５０４にのみ含まれる。図５では、図２のように共有メモリ２０５と２０６のデータの同期化のためのデータを送信する実施形態を前提としているので、パケットの種別やフィールドの名称に「共有メモリデータ」という語を使っている。しかし、一般的に述べるなら、共有メモリデータフィールドの内容は送信対象のデータそのものであり、共有メモリデータパケット５０４は送信対象のデータを送信するためのパケットであり、他の種別のパケットは諸々の制御用のパケットである。つまり、共有メモリデータフィールドの内容は図１の送信対象データ１０３に相当する。
【０１０６】
次に、図６〜図９のフローチャートを参照して、上記の各スレッドの動作について説明する。図６〜図９に関しては、コンピュータ２０１がアクティブ装置として運用され、コンピュータ２０２がスタンバイ装置として運用されている、図２の状態を前提として説明する。
【０１０７】
図６は、共有メモリ制御部２１３が共有メモリデータパケット５０４をスタンバイ装置２０２に送信する共有メモリデータ送信処理のフローチャートである。共有メモリデータ送信処理は、図２のユーザアプリケーション２０７から点Ａへ向かい、点Ａで分岐して点Ｂと点Ｄに向かう矢印に対応する。つまり、共有メモリデータ送信処理が開始される契機は、ユーザアプリケーション２０７が、共有メモリ２０５に書き込んだのと同じデータ２０９をスタンバイ装置２０２の共有メモリ２０６にも反映するよう、共有メモリ制御部２１３に要求することである。
【０１０８】
ステップＳ１０１で、データ送信スレッド４０３が、第一経路２１５と第二経路２１６を介して送信すべき二つの共有メモリデータパケット５０４を作成する。以下では、二つの共有メモリデータパケット５０４を区別する必要がある場合は「５０４‐１」と「５０４‐２」なる符号を用いる。共有メモリデータパケット５０４‐１と５０４‐２を作成する過程において、通番管理テーブル６０１の送信通番フィールドが更新される。
【０１０９】
通番管理テーブル６０１は、例えば、共有メモリ制御部２１３が参照可能なＲＡＭ上の制御用データ領域に格納され、共有メモリデータパケット５０４の順序を管理するための情報を保持している。具体的には、通番管理テーブル６０１は「送信通番」、「受信通番」、および「リフレッシュＩＤ」というフィールドを有する。本実施形態では、送信通番と受信通番は１バイトで表される０〜２５５の整数であり、リフレッシュＩＤは日時を表す値である。詳しくは後述するが、本実施形態では、三つのフィールドのいずれも、有効な値に初期化される前の例外的な初期値は０である。図６には、通番管理テーブル６０１の二つの状態を符号「６０１ａ」と「６０１ｂ」により区別して示した。
【０１１０】
また、詳細は後述するが、１回目に使われた２５５という送信通番よりも、２回目に使われた１という送信通番の方が後の順序を示すことが、共有メモリデータパケット５０４から判断可能でなくてはならない。リフレッシュＩＤは、再利用された同じ値の送信通番同士を識別するための識別情報である。
【０１１１】
ステップＳ１０１でデータ送信スレッド４０３は、通番管理テーブル６０１の送信通番フィールドを更新し、送信通番を、現在の値に１を足した値とする。つまり、共有メモリデータパケットの送信がユーザアプリケーション２０７から依頼されるたびに、送信通番はカウントアップされる。データ送信スレッド４０３は、この更新後の送信通番を共有メモリデータパケット５０４‐１と５０４‐２の通番フィールドにそれぞれ設定する。
【０１１２】
また、データ送信スレッド４０３は、データ転送制御表３０１の「第一経路」レコードから、自分のポート番号と通信相手のポート番号を読み取り、第一経路２１５を介して送信すべき共有メモリデータパケット５０４‐１のＵＤＰヘッダに読み取ったポート番号を設定する。同様に、データ送信スレッド４０３は、「第二経路」レコードから自分のポート番号と通信相手のポート番号を読み取り、第二経路２１６を介して送信すべき共有メモリデータパケット５０４‐２のＵＤＰヘッダに読み取ったポート番号を設定する。
【０１１３】
共有メモリデータパケット５０４‐１と５０４‐２の双方で、ＴＹＰＥ１、ＴＹＰＥ２、リフレッシュＩＤ、および共有メモリデータの各フィールドは共通である。つまり、図５に示すように、データ送信スレッド４０３は、ＴＹＰＥ１を２に、ＴＹＰＥ２を３に設定する。また、データ送信スレッド４０３は、通番管理テーブル６０１からリフレッシュＩＤを読み取って、共有メモリデータパケット５０４‐１と５０４‐２のリフレッシュＩＤフィールドに設定する。共有メモリデータフィールドの内容は、共有メモリデータ送信処理を呼び出したユーザアプリケーション２０７が共有メモリ制御部２１３に与えたデータであり、データ２０９に等しい。
【０１１４】
以上がステップＳ１０１の処理だが、正確には、上記の送信通番の更新処理は単純なインクリメントではなく、以下のような処理である。
本実施形態では、コンピュータ２０１に電源が投入されたとき、または再起動されたとき、通番管理テーブル６０１の三つのフィールドの値はどれも自動的に０に設定され、図６の通番管理テーブル６０１ａの状態になると仮定している。つまり、本実施形態では、０という値は有効な値に初期化される前の例外的な値である。そして、電源が投入された後、または再起動された後の１回目の共有メモリデータパケット５０４の送信時には、ステップＳ１０１において送信通番が１に設定される。
【０１１５】
一方で、上記のとおり送信通番は２５５までの整数である。よって、２５５個より多くの共有メモリデータパケット５０４を送信しようとすると、送信通番はオーバーフローする。そこで、同じ番号を再利用する必要がある。現在の送信通番が２５５の場合、単純に２５５に１を足すと、オーバーフローの結果、０なる値に送信通番が更新される。しかし、０は初期化の前の例外的な値であるから、共有メモリデータパケット５０４の通番フィールドに０が設定されることは避けるべきである。
【０１１６】
そこで、ステップＳ１０１での送信通番の更新においては、まず、データ送信スレッド４０３は送信通番を、現在の値に１を足した値とする。そして、その結果の送信通番が０なら、データ送信スレッド４０３は再度、送信通番に１を足す。データ送信スレッド４０３は、こうして得られた１という送信通番を共有メモリデータパケット５０４の通番フィールドに設定する。そのため、通番フィールドの値が２５５の共有メモリデータパケット５０４の次に送信される共有メモリデータパケット５０４の通番フィールドの値は、１である。
【０１１７】
以上のようにして、１〜２５５のいずれかの値が通番フィールドに設定された共有メモリデータパケット５０４‐１と５０４‐２をステップＳ１０１で作成すると、データ送信スレッド４０３はステップＳ１０２において、通番管理テーブル６０１に格納された送信通番が１か否かを判定する。送信通番が１の場合、判定は「ＹＥＳ」となって処理はステップＳ１０３に移行し、それ以外の場合、判定は「ＮＯ」となって処理はステップＳ１０６に移行する。
【０１１８】
ステップＳ１０３〜Ｓ１０５は、ステップＳ１０２の判定が「ＹＥＳ」の場合のみ実行される。ステップＳ１０３で、データ送信スレッド４０３は現在の日時を取得し、取得し
た日時を表す値Ａを通番管理テーブル６０１のリフレッシュＩＤフィールドに登録する。その結果は、図６の通番管理テーブル６０１ｂのとおりである。
【０１１９】
続くステップＳ１０４で、データ送信スレッド４０３は、第一経路２１５と第二経路２１６を介して送信すべき二つのリフレッシュ要求パケット５０２を作成して、スタンバイ装置２０２に送信する。以下では二つのリフレッシュ要求パケット５０２を区別する必要がある場合は「５０２‐１」と「５０２‐２」なる符号を用いる。ステップＳ１０４の処理は、アクティブ装置２０１とスタンバイ装置２０２の間で足並みを揃えてそれぞれの送信通番と受信通番とリフレッシュＩＤを初期化するための処理である。
【０１２０】
データ送信スレッド４０３は、データ転送制御表３０１の「第一経路」レコードと「第二経路」レコードのそれぞれから自分のポート番号と通信相手のポート番号を読み取って、リフレッシュ要求パケット５０２‐１と５０２‐２それぞれのＵＤＰヘッダに設定する。ＴＹＰＥ１、ＴＹＰＥ２、リフレッシュＩＤの三つのフィールドは、リフレッシュ要求パケット５０２‐１と５０２‐２で共通である。データ送信スレッド４０３が、ＴＹＰＥ１を２に設定し、ＴＹＰＥ２を１に設定し、リフレッシュＩＤを通番管理テーブル６０１から読み取ってリフレッシュ要求パケット５０２‐１と５０２‐２のリフレッシュＩＤフィールドに設定する。
【０１２１】
そして、データ送信スレッド４０３は、データ転送制御表３０１を参照して第一経路２１５と第二経路２１６の状態をチェックする。データ送信スレッド４０３は、第一経路２１５が正常なら第一経路２１５を介してリフレッシュ要求パケット５０２‐１をスタンバイ装置２０２へ送信する。また、データ送信スレッド４０３は、第二経路２１６が正常なら第二経路２１６を介してリフレッシュ要求パケット５０２‐２をスタンバイ装置２０２へ送信する。
【０１２２】
続くステップＳ１０５では、データ送信スレッド４０３はスリープ状態であり、データ受信スレッド４０５が、スタンバイ装置２０２からの応答、すなわちリフレッシュ応答パケット５０３の受信を待ち合わせている。リフレッシュ応答パケット５０３の受信の詳細は図８とともに後述するが、リフレッシュ応答パケット５０３の受信を契機として、スリープ状態のデータ送信スレッド４０３が起床させられて、処理がステップＳ１０６に移行する。
【０１２３】
ステップＳ１０６でデータ送信スレッド４０３は、データ転送制御表３０１の「第一経路」レコードの「状態」フィールドを参照し、第一経路２１５が正常か否かを判定する。「状態」フィールドの値が「正常」なら判定は「ＹＥＳ」となって処理がステップＳ１０７に移行し、そうでなければ判定は「ＮＯ」となって処理がステップＳ１０８に移行する。
【０１２４】
ステップＳ１０７で、データ送信スレッド４０３は、まず、データ転送制御表３０１の「第一経路」レコードの自分のＩＰアドレスと通信相手のＩＰアドレスを読み取る。そして、データ送信スレッド４０３は読み取ったＩＰアドレスを含むＩＰヘッダを共有メモリデータパケット５０４‐１に付加して、共有メモリデータパケット５０４‐１をカプセル化する。そして、データ送信スレッド４０３は、ＵＤＰポート４１１から第一経路２１５を介してスタンバイ装置２０２へ、カプセル化したＩＰパケットを送信する。
【０１２５】
続くステップＳ１０８とＳ１０９からなる処理は、ステップＳ１０６とＳ１０７からなる処理と同様である。違いは、ステップＳ１０６とＳ１０７は第一経路２１５に対応する処理であるのに対し、ステップＳ１０８とＳ１０９は第二経路２１６に対応する処理である点のみである。
【０１２６】
ステップＳ１０８で「ＮＯ」と判定された後、またはステップＳ１０９の実行後、図６の共有メモリデータ送信処理は終了する。
図７は、図６のステップＳ１０４で送信されたリフレッシュ要求パケット５０２をスタンバイ装置２０２が受信するリフレッシュ要求受信処理のフローチャートである。
【０１２７】
まず、第一経路受信スレッド４０８または第二経路受信スレッド４１０が、パケットを受信し、ＴＹＰＥ１フィールドの値にもとづいてヘルスチェックパケット５０１ではないと判断し、受信したパケットの処理をデータ受信スレッド４０６に要求する。次に、データ受信スレッド４０６が受信したパケットのＴＹＰＥ２フィールドの値にもとづいて、受信したパケットがリフレッシュ要求パケット５０２であると判断する。この判断を契機として、リフレッシュ要求受信処理が開始される。リフレッシュ要求受信処理には、どちらの経路を介してリフレッシュ要求パケット５０２を受信したかは関係がない。
【０１２８】
また、通番管理テーブル６０１と同様の通番管理テーブル６０２が、コンピュータ２０２のＲＡＭ上の制御用データ領域にも格納されている。なお、図７には通番管理テーブル６０２の二つの状態を符号「６０２ａ」と「６０２ｂ」により区別して示した。コンピュータ２０２に電源が投入された直後またはコンピュータ２０２が再起動された直後には、通番管理テーブル６０２ａのように、三つのフィールドの値はすべて０である。
【０１２９】
リフレッシュ要求受信処理が開始されると、まずステップＳ２０１で、データ受信スレッド４０６は、受信したリフレッシュ要求パケット５０２のリフレッシュＩＤフィールドの値と通番管理テーブル６０２のリフレッシュＩＤフィールドの値が一致するか否かを判定する。両者が一致していれば判定は「ＹＥＳ」となって、リフレッシュ要求受信処理を終了し、そうでなければ判定は「ＮＯ」となって、ステップＳ２０２に移行する。判定が「ＹＥＳ」となるのは、処理済みのリフレッシュ要求パケット５０２と同じ内容のリフレッシュ要求パケット５０２を、別の経路を介して受信した場合である。
【０１３０】
ステップＳ２０２において、データ受信スレッド４０６は、受信したリフレッシュ要求パケット５０２のリフレッシュＩＤフィールドの値を通番管理テーブル６０２のリフレッシュＩＤフィールドに設定する。これにより、通番管理テーブル６０２のリフレッシュＩＤフィールドの値が更新される。図７では、更新後のリフレッシュＩＤフィールドの値を図６と同じく符号「Ａ」により示している。
【０１３１】
続いてステップＳ２０３において、データ受信スレッド４０６は、通番管理テーブル６０２の受信通番フィールドの値を１に初期化する。その結果は、通番管理テーブル６０２ｂとして図７に示したとおりである。また、データ受信スレッド４０６は、次のステップＳ２０４の処理を実行するよう、データ送信スレッド４０４に要求する。
【０１３２】
ステップＳ２０４において、データ送信スレッド４０４は、第一経路２１５と第二経路２１６を介して送信すべき二つのリフレッシュ応答パケット５０３を作成し、アクティブ装置２０１に送信する。以下では二つのリフレッシュ応答パケット５０３を区別する必要がある場合は「５０３‐１」と「５０３‐２」なる符号を用いる。
【０１３３】
データ送信スレッド４０４は、データ転送制御表３０２の「第一経路」レコードと「第二経路」レコードのそれぞれから自分のポート番号と通信相手のポート番号を読み取って、リフレッシュ応答パケット５０３‐１と５０３‐２それぞれのＵＤＰヘッダに設定する。ＴＹＰＥ１、ＴＹＰＥ２、リフレッシュＩＤの三つのフィールドは、リフレッシュ応答パケット５０３‐１と５０３‐２で共通である。データ送信スレッド４０４が、ＴＹＰＥ１を２に設定し、ＴＹＰＥ２を２に設定し、ステップＳ２０１でリフレッシュ要求パケッ
ト５０２から読み取ったリフレッシュＩＤをリフレッシュ応答パケット５０３‐１と５０３‐２のリフレッシュＩＤフィールドに設定する。また、データ送信スレッド４０４は、データ転送制御表３０２の自分のＩＰアドレスと通信相手のＩＰアドレスを参照して適切なＩＰヘッダをリフレッシュ応答パケット５０３‐１と５０３‐２に付加する。
【０１３４】
そして、データ送信スレッド４０４は、データ転送制御表３０２を参照して第一経路２１５と第二経路２１６の状態をチェックする。データ送信スレッド４０４は、第一経路２１５が正常なら第一経路２１５を介してリフレッシュ応答パケット５０３‐１をアクティブ装置２０１へ送信し、第二経路２１６が正常なら第二経路２１６を介してリフレッシュ応答パケット５０３‐２をアクティブ装置２０１へ送信する。
【０１３５】
以上のようにしてリフレッシュ要求受信処理が終了する。第一経路２１５と第二経路２１６の少なくとも一方が正常なら、ステップＳ２０４で送信されたリフレッシュ応答パケット５０３は、その後、アクティブ装置２０１で受信される。第一経路受信スレッド４０７または第二経路受信スレッド４０９は、リフレッシュ応答パケット５０３を受信すると、ヘルスチェックパケット５０１ではないと判断し、受信したパケットの処理をデータ受信スレッド４０５に要求する。データ受信スレッド４０５は、受信したパケットのＴＹＰＥ２フィールドの値にもとづいて、受信したパケットがリフレッシュ応答パケット５０３であると判断する。この判断を契機として、図８のフローチャートに示したリフレッシュ応答受信処理が開始される。リフレッシュ応答受信処理には、どちらの経路を介してリフレッシュ応答パケット５０３を受信したかは関係がない。
【０１３６】
また、リフレッシュ応答受信処理が実行されるのは図６のステップＳ１０５の待ち合わせ中なので、図８には、図６の通番管理テーブル６０１ｂと同じ状態の通番管理テーブル６０１ｂを示してある。
【０１３７】
ステップＳ３０１でデータ受信スレッド４０５は、受信したリフレッシュ応答パケット５０３からリフレッシュＩＤを読み取り、読み取ったリフレッシュＩＤと通番管理テーブル６０２のリフレッシュＩＤが一致するか否かを判定する。両者が一致していれば判定は「ＹＥＳ」となって処理がステップＳ３０２に移行し、そうでなければ判定は「ＮＯ」となってリフレッシュ応答受信処理を終了する。判定が「ＮＯ」となるのは、異なるリフレッシュＩＤに対応するリフレッシュ応答パケット５０３が時間的に近接して送信され、何らかの理由で送信順序とは違う順序で受信された場合など、例外的な場合である。
【０１３８】
ステップＳ３０２において、データ受信スレッド４０５は、受信したリフレッシュ応答パケット５０３の待ち合わせ先であるデータ送信スレッド４０３を起床させる。すなわち、データ受信スレッド４０５は、図６のステップＳ１０５で待ち続けているデータ送信スレッド４０３に対し、次のステップＳ１０６に進むべきことを通知する。そして、リフレッシュ応答受信処理が終了する。つまり、この起床通知は、アクティブ装置２０１の通番管理テーブル６０１とスタンバイ装置２０２の通番管理テーブル６０２がそれぞれ保持するリフレッシュＩＤを同期化させる処理が完了したことを示す通知である。
【０１３９】
次に、図９を参照して、共有メモリデータパケット５０４をスタンバイ装置２０２が受信する共有メモリデータ受信処理について説明する。図９の全体はループを構成している。図９は、ステップＳ４０１で共有メモリデータパケット５０４を受信するたびに、ステップＳ４０２〜Ｓ４０７の処理を実行し、次の共有メモリデータパケット５０４の受信に備えてステップＳ４０１に戻ることを表している。
【０１４０】
ステップＳ４０１で、スタンバイ装置２０２が共有メモリデータパケット５０４を受信する。具体的には、図６のステップＳ１０７で第一経路２１５を介して送信された共有メ
モリデータパケット５０４‐１を第一経路受信スレッド４０８が受信するか、ステップＳ１０９で第二経路２１６を介して送信された共有メモリデータパケット５０４‐２を第二経路受信スレッド４１０が受信する。
【０１４１】
第一経路受信スレッド４０８または第二経路受信スレッド４１０は、受信したパケットのＴＹＰＥ１フィールドの値にもとづき、受信したパケットがヘルスチェックパケット５０１ではないと判断し、受信したパケットの処理をデータ受信スレッド４０６に要求する。データ受信スレッド４０６は受信したパケットのＴＹＰＥ２フィールドの値にもとづき、受信したパケットが共有メモリデータパケット５０４であると判断する。以下の処理には、どちらの経路を介して共有メモリデータパケット５０４を受信したかは関係がない。
【０１４２】
次のステップＳ４０２では、データ受信スレッド４０６が、受信した共有メモリデータパケット５０４からリフレッシュＩＤを読み取り、読み取ったリフレッシュＩＤと通番管理テーブル６０２のリフレッシュＩＤが一致するか否かを判定する。両者が一致していれば判定は「ＹＥＳ」となって処理がステップＳ４０３に移行し、そうでなければ判定は「ＮＯ」となってステップＳ４０１に戻る。
【０１４３】
「ＮＯ」という判定は、直前のステップＳ４０１で受信した共有メモリデータパケット５０４が、過去に受信した他の共有メモリデータパケット５０４と重複する、ということを意味する。換言すれば、「ＮＯ」という判定は、図１の受信順序情報１１１が送信順序情報１０９または１１０よりも後の順序を示すことを意味する。よって、判定が「ＮＯ」となる場合、直前のステップＳ４０１で受信した共有メモリデータパケット５０４の共有メモリデータフィールドの内容に関する処理は何も行われない。つまり、この共有メモリデータパケット５０４は破棄される。
【０１４４】
ステップＳ４０３では、データ受信スレッド４０６が、受信した共有メモリデータパケット５０４の通番フィールドの値ｐを読み取り、通番管理テーブル６０２の受信通番フィールドの値ｔと比較する。比較の結果に応じて、処理は三通りに分岐する。
【０１４５】
（１）ｐ＜ｔの場合
ｐ＜ｔとなるのは、過去に受信して処理済みの共有メモリデータパケット５０４と同内容の共有メモリデータパケット５０４を、別の経路を介して重複して受信した場合である。つまり、図６のステップＳ１０１で一緒に作成された二つの共有メモリデータパケット５０４のうちの一方が過去の図９のループにおいて受信されて処理済みであり、他方が今回のループのステップＳ４０１で受信された場合に、ｐ＜ｔとなる。「ｐ＜ｔ」なる式は、図１の受信順序情報１１１が送信順序情報１０９または１１０よりも後の順序を示すことに対応する。
【０１４６】
図６のステップＳ１０１で一緒に作成された二つの共有メモリデータパケット５０４は、ＵＤＰヘッダ以外のすべてのフィールドの内容が等しい。過去に受信した共有メモリデータパケット５０４の共有メモリデータは処理済みなので、今回のループで受信した共有メモリデータパケット５０４の共有メモリデータを処理する必要はない。そこで、今回のループのステップＳ４０１で受信した共有メモリデータパケット５０４は破棄され、その共有メモリデータフィールドの内容に関する処理は何も行われない。次の共有メモリデータパケット５０４の受信を待つために、処理はステップＳ４０１に戻る。
【０１４７】
（２）ｐ＝ｔの場合
ｐ＝ｔとなるのは、次に処理すべき共有メモリデータパケット５０４を受信した場合である。なお「処理すべき」とは、本実施形態では、共有メモリデータフィールドの内容を共有メモリ２０６に反映する処理を行うべきことを意味する。この場合、その処理を行う
ためにステップＳ４０５に移行する。つまり、「ｐ＝ｔ」とは、次に受信されると期待される順序に対応するパケットが、まさに今回のループで受信されたことを表し、図１の受信順序情報１１１が送信順序情報１０９または１１０と同じ順序を示す場合に該当する。
【０１４８】
（３）ｐ＞ｔの場合
ｐ＞ｔとなるのは、連続してアクティブ装置２０１から送信された、異なる順序に対応する複数の共有メモリデータパケット５０４のうちの一つ以上が、何らかの理由でスタンバイ装置２０２に到達しなかった場合である。つまり、ｐ＞ｔのとき、スタンバイ装置２０２から見ると、連続する複数の共有メモリデータパケット５０４のうちの一部が消失した状態である。「ｐ＞ｔ」なる式は、図１の受信順序情報１１１が送信順序情報１０９または１１０よりも前の順序を示すことに対応する。
【０１４９】
なお、二つの経路を介して送信された二つの共有メモリデータパケット５０４のうちの一方がネットワーク上で消失しても、他方が正常な経路を介してスタンバイ装置２０２に正しい順序で到達すれば、ｐ＞ｔとはならず、「消失」とは見なされない。ｐ＞ｔの場合、処理はステップＳ４０４に移行する。
【０１５０】
ステップＳ４０４は、受信した共有メモリデータパケット５０４の通番フィールドの値ｐが通番管理テーブル６０２の受信通番フィールドの値ｔより大きい場合に実行される。上記のように、この場合は連続してアクティブ装置２０１から送信された、異なる順序に対応する複数の共有メモリデータパケット５０４のうちの一つ以上が、正しい順序でスタンバイ装置２０２に受信されず、抜け落ちている。しかし、今回のループのステップＳ４０１で受信した共有メモリデータパケット５０４は未処理のデータを共有メモリデータフィールドに含む。本実施形態では、この未処理のデータは処理すべきデータであり、破棄せずに利用する。
【０１５１】
そこで、ステップＳ４０４では、今回のループのステップＳ４０１で受信した共有メモリデータパケット５０４が処理の対象であることを、通番管理テーブル６０２にも反映するための処理をデータ受信スレッド４０６が行う。具体的には、データ受信スレッド４０６は、通番管理テーブル６０２の受信通番フィールドに、今回のループのステップＳ４０１で受信した共有メモリデータパケット５０４の通番フィールドの値を設定する。これにより、次回のループでは、こうして更新された受信通番にもとづいてステップＳ４０３の判定が行われる。
【０１５２】
ステップＳ４０４の実行後、またはステップＳ４０３でｐ＝ｔと判定された場合、ステップＳ４０５〜Ｓ４０７が実行される。
ステップＳ４０５では、今回のループのステップＳ４０１で受信された共有メモリデータパケット５０４の共有メモリデータフィールドの内容を、データ受信スレッド４０６が共有メモリ２０６に反映する。ステップＳ４０５は、図２で点Ｂから共有メモリ２０６に向かう矢印に対応する。ステップＳ４０５の処理を終えるとデータ受信スレッド４０６は、ステップＳ４０６の処理を行うようデータ送信スレッド４０４に要求する。
【０１５３】
ステップＳ４０６では、データ送信スレッド４０４がＡＣＫパケット５０５をアクティブ装置２０１に返信する。ＡＣＫパケット５０５は、スタンバイ装置２０２が共有メモリデータパケット５０４を受信し、その共有メモリデータフィールドの内容を共有メモリ２０６に反映したという結果をアクティブ装置２０１に通知するためのパケットである。データ送信スレッド４０４は、第一経路２１５と第二経路２１６を介して送信すべき二つのＡＣＫパケット５０５を作成し、アクティブ装置２０１に送信する。以下では二つのＡＣＫパケット５０５を区別する必要がある場合は「５０５‐１」と「５０５‐２」なる符号を用いる。
【０１５４】
データ送信スレッド４０４は、データ転送制御表３０２の「第一経路」レコードと「第二経路」レコードのそれぞれから自分のポート番号と通信相手のポート番号を読み取って、ＡＣＫパケット５０５‐１と５０５‐２それぞれのＵＤＰヘッダに設定する。ＴＹＰＥ１、ＴＹＰＥ２、リフレッシュＩＤ、通番の四つのフィールドは、ＡＣＫパケット５０５‐１と５０５‐２で共通である。データ送信スレッド４０４が、ＴＹＰＥ１を２に設定し、ＴＹＰＥ２を４に設定し、通番管理テーブル６０２からリフレッシュＩＤを読み取って、読み取ったリフレッシュＩＤをＡＣＫパケット５０５‐１と５０５‐２のリフレッシュＩＤフィールドに設定する。また、データ送信スレッド４０４は、データ転送制御表３０２の自分のＩＰアドレスと通信相手のＩＰアドレスを参照して適切なＩＰヘッダをＡＣＫパケット５０５‐１と５０５‐２に付加する。
【０１５５】
そして、データ送信スレッド４０４は、データ転送制御表３０２を参照して第一経路２１５と第二経路２１６の状態をチェックする。データ送信スレッド４０４は、第一経路２１５が正常なら第一経路２１５を介してＡＣＫパケット５０５‐１をアクティブ装置２０１へ送信し、第二経路２１６が正常なら第二経路２１６を介してＡＣＫパケット５０５‐２をアクティブ装置２０１へ送信する。
【０１５６】
続くステップＳ４０７では、データ受信スレッド４０６が、通番管理テーブル６０２の受信通番フィールドを更新し、受信通番を、現在の値に１を足した値とする。この処理は、正確には図６のステップＳ１０１と同様に、２５５に１を足した場合はオーバーフローして０となり、０を避けるために再度１を足して受信通番を１とする処理である。受信通番の更新後、処理はステップＳ４０１に戻る。
【０１５７】
次に、図１０〜図１３の処理シーケンス図を参照して、処理の具体例を説明する。図１０〜図１３でも、図２のようにコンピュータ２０１がアクティブ装置２０１として運用され、コンピュータ２０２がスタンバイ装置２０２として運用されている状態を前提とする。
【０１５８】
また、図１０〜図１３では、アクティブ装置２０１に格納された通番管理テーブル６０１の状態を左列の矩形内に、スタンバイ装置２０２に格納された通番管理テーブル６０２の状態を右列の矩形内に、それぞれ示した。図１０〜図１３では、通番管理テーブル６０１と６０２に格納された送信通番、受信通番、およびリフレッシュＩＤをそれぞれ「ｓｎｄ＿ｓｅｑ」、「ｒｃｖ＿ｓｅｑ」、「ｒｅｆｒｅｓｈ＿ｉｄ」なる符号により表した。また、各種パケットの種別を矢印の上に書き、そのパケットのリフレッシュＩＤフィールドと通番フィールドの値を、それぞれ矢印の上に添えた「ｒｅｆｒｅｓｈ＿ｉｄ」と「ｓｅｑ」なる符号により表した。
【０１５９】
なお、図１０〜図１３は、二つの経路のいずれかを介して最終的にスタンバイ装置２０２に共有メモリデータパケット５０４が到達するか否かという点と、アクティブ装置２０１の通番管理テーブル６０１とスタンバイ装置２０２の通番管理テーブル６０２がどのように連携されるかという点に注目した図である。よって、図１０〜図１３では、二つの経路がともに正常な場合の、パケットの重複に関する処理は省略して図示した。
【０１６０】
図１０は、初期状態と、その後に続く正常な処理の結果を示す。状態ＡＣ１０１と状態ＳＴ１０１はそれぞれ通番管理テーブル６０１と６０２の初期状態である。どちらも、三つのフィールドすべての値が０である。
【０１６１】
この状態で、ユーザアプリケーション２０７がデータ２０９をスタンバイ装置２０２にも反映するよう共有メモリ制御部２１３に要求すると、図６のステップＳ１０１〜Ｓ１０
３により、通番管理テーブル６０１は状態ＡＣ１０２になる。ここで、送信通番が１、リフレッシュＩＤがＡである。
【０１６２】
次に、図６のステップＳ１０４でリフレッシュ要求パケット５０２がスタンバイ装置２０２に送信される。スタンバイ装置２０２がリフレッシュ要求パケット５０２を受信したときの通番管理テーブル６０２の状態は、状態ＳＴ１０１と同じ状態ＳＴ１０２である。スタンバイ装置２０２では、図７のステップＳ２０１の判定が「ＮＯ」となるので、ステップＳ２０２とＳ２０３により通番管理テーブル６０２が更新されて状態ＳＴ１０２から状態ＳＴ１０３へと変わる。ここで、受信通番が１、リフレッシュＩＤがＡである。
【０１６３】
そして、スタンバイ装置２０２から図７のステップＳ２０４でリフレッシュ応答パケット５０３がアクティブ装置２０１へ送信される。アクティブ装置２０１がリフレッシュ応答パケット５０３を受信したときの通番管理テーブル６０１の状態は、状態ＡＣ１０２と同じ状態ＡＣ１０３である。
【０１６４】
そして、図８のステップＳ３０１の判定が「ＹＥＳ」となるため、図６のステップＳ１０６〜Ｓ１０９が実行される。その際の通番管理テーブル６０１の状態は状態ＡＣ１０３と同じ状態ＡＣ１０４であるから、ステップＳ１０７とＳ１０９で送信される共有メモリデータパケット５０４の通番フィールドの値は１、リフレッシュＩＤフィールドの値はＡである。
【０１６５】
この共有メモリデータパケット５０４をスタンバイ装置２０２が受信したときの通番管理テーブル６０２の状態は状態ＳＴ１０３と同じ状態ＳＴ１０４である。この場合、図９のステップＳ４０３でｐ＝ｔと判定されるので、ステップＳ４０６でＡＣＫパケット５０５がアクティブ装置２０１に送信され、ステップＳ４０７で受信通番が２に更新されて、通番管理テーブル６０２が状態ＳＴ１０５のようになる。
【０１６６】
ステップＳ４０６で送信されるＡＣＫパケット５０５のリフレッシュＩＤフィールドと通番フィールドの値はＡと１である。アクティブ装置２０１がＡＣＫパケット５０５を受信するときの通番管理テーブル６０１の状態は、状態ＡＣ１０４と同じ状態ＡＣ１０５であるから、受信したＡＣＫパケット５０５のリフレッシュＩＤフィールドの値と通番管理テーブル６０１のリフレッシュＩＤは等しく、かつ、受信したＡＣＫパケット５０５の通番フィールドの値と通番管理テーブル６０１の送信通番は等しい。
【０１６７】
よって、共有メモリ制御部２１３のデータ受信スレッド４０５は、直前に送信した共有メモリデータパケット５０４に対応するＡＣＫパケット５０５が正常に返信されたことを検知することができる。正常にＡＣＫパケット５０５が返信されたことを検知すると、共有メモリ制御部２１３はその旨をユーザアプリケーション２０７に通知する。また、ＡＣＫパケット５０５の正常な受信を契機として、共有メモリ制御部２１３は、ユーザアプリケーション２０７からの次のデータ送信の要求を受け付けることが可能になる。
【０１６８】
そこで、共有メモリ２０６にデータを反映するためのデータ送信を次にユーザアプリケーション２０７が共有メモリ制御部２１３に要求すると、図６のステップＳ１０１により通番管理テーブル６０１の送信通番が２に更新され、更新後の状態は状態ＡＣ１０６となる。そして、この状態ＡＣ１０６でステップＳ１０２の判定は「ＮＯ」となり、ステップＳ１０６〜Ｓ１０９が実行される。それにより送信される共有メモリデータパケット５０４の通番フィールドの値は２、リフレッシュＩＤフィールドの値はＡである。
【０１６９】
この共有メモリデータパケット５０４をスタンバイ装置２０２が受信したときの通番管理テーブル６０２の状態は状態ＳＴ１０５のままである。この場合も図９のステップＳ４
０３でｐ＝ｔと判定されるので、ステップＳ４０６でＡＣＫパケット５０５がアクティブ装置２０１に送信される。また、ステップＳ４０７で受信通番が３に更新されて通番管理テーブル６０２は状態ＳＴ１０６のようになる。
【０１７０】
ステップＳ４０６で送信されるＡＣＫパケット５０５のリフレッシュＩＤフィールドと通番フィールドの値はＡと２である。アクティブ装置２０１がＡＣＫパケット５０５を受信するときの通番管理テーブル６０１の状態は、状態ＡＣ１０６と同じ状態ＡＣ１０７なので、受信したＡＣＫパケット５０５のリフレッシュＩＤフィールドの値と通番管理テーブル６０１のリフレッシュＩＤはともにＡであり、かつ、受信したＡＣＫパケット５０５の通番フィールドの値と通番管理テーブル６０１の送信通番はともに２である。
【０１７１】
よって、共有メモリ制御部２１３のデータ受信スレッド４０５は、直前に送信した共有メモリデータパケット５０４に対応するＡＣＫパケット５０５が正常に返信されたことを検知することができる。
【０１７２】
次に、図１１を参照して、共有メモリデータパケット５０４が消失する場合の例を説明する。
図１１のうち、状態ＡＣ２０１、状態ＳＴ２０１、状態ＡＣ２０２からなる部分と、状態ＳＴ２０１から状態ＳＴ２０２への更新を表す部分は、正常な送信に対応する部分である。すなわち、通番フィールドの値が１の共有メモリデータパケット５０４が問題なくアクティブ装置２０１から送信されてスタンバイ装置２０２で受信され、対応するＡＣＫパケット５０５が問題なくスタンバイ装置２０２からアクティブ装置２０１へ返信され、通番管理テーブル６０２の受信通番が１から２に更新されるまでの過程は正常である。状態ＡＣ２０１、状態ＳＴ２０１、状態ＡＣ２０２、状態ＳＴ２０２はそれぞれ図１０の状態ＡＣ１０４、状態ＳＴ１０４、状態ＡＣ１０５、状態ＳＴ１０５と同様である。
【０１７３】
通番管理テーブル６０１が状態ＡＣ２０２のとき、共有メモリ２０６へのデータ２０９の反映を、ユーザアプリケーション２０７が共有メモリ制御部２１３に要求する。すると、図６のステップＳ１０１により通番管理テーブル６０１の送信通番が２に更新され、更新後の状態は状態ＡＣ２０３となる。この状態ＡＣ２０３でステップＳ１０２の判定は「ＮＯ」となり、ステップＳ１０６〜Ｓ１０９が実行される。それにより送信される共有メモリデータパケット５０４の通番フィールドの値は２、リフレッシュＩＤフィールドの値はＡである。
【０１７４】
図１１では、第一経路２１５と第二経路２１６を介して送信された二つの共有メモリデータパケット５０４がともに消失したと仮定する。よって、通番フィールドの値が２で、リフレッシュＩＤフィールドの値がＡの共有メモリデータパケット５０４は、スタンバイ装置２０２には届かない。当然、この共有メモリデータパケット５０４に対応するＡＣＫパケット５０５はアクティブ装置２０１に返信されない。よって、アクティブ装置２０１の共有メモリ制御部２１３は、共有メモリデータパケット５０４の送信から所定の時間内に適切なＡＣＫパケット５０５を受信することができないため、タイムアウトする。
【０１７５】
共有メモリ制御部２１３は、ユーザアプリケーション２０７に共有メモリデータパケット５０４の送信が失敗したことを通知する。その通知によりユーザアプリケーション２０７は、データ２０９の反映が失敗したことを認識する。その後、ユーザアプリケーション２０７は、データ２０９を共有メモリ２０６に反映するよう、再度共有メモリ制御部２１３に要求してもよい。本実施形態における再送制御は、共有メモリ制御部２１３ではなくユーザアプリケーション２０７の責任において行われる。もちろん、他の実施形態では共有メモリ制御部２１３がタイムアウト後に再送を試みてもよい。
【０１７６】
一方、共有メモリ制御部２１３は、タイムアウトすることにより、ユーザアプリケーション２０７からのデータ送信の要求を受け付けることが可能になる。
そこで、次にユーザアプリケーション２０７が共有メモリ２０６へのデータ２０９の反映を共有メモリ制御部２１３に要求すると、図６のステップＳ１０１により通番管理テーブル６０１の送信通番が３に更新され、更新後の状態は状態ＡＣ２０４となる。そして、この状態ＡＣ２０４でステップＳ１０２の判定は「ＮＯ」となり、ステップＳ１０６〜Ｓ１０９が実行される。それにより送信される共有メモリデータパケット５０４の通番フィールドの値は３、リフレッシュＩＤフィールドの値はＡである。
【０１７７】
この共有メモリデータパケット５０４をスタンバイ装置２０２が受信したときの通番管理テーブル６０２の状態は、状態ＳＴ２０２と同じ状態ＳＴ２０３である。この場合、図９のステップＳ４０３でｐ＞ｔと判定される。よって、ステップＳ４０４で受信通番が３に更新されて、通番管理テーブル６０２が状態ＳＴ２０４のようになり、ステップＳ４０５で共有メモリデータフィールドの内容が共有メモリ２０６に反映され、ステップＳ４０６でＡＣＫパケット５０５がアクティブ装置２０１に送信される。また、ステップＳ４０７で受信通番が４に更新されて通番管理テーブル６０２は状態ＳＴ２０５のようになる。
【０１７８】
ここで送信されるＡＣＫパケット５０５のリフレッシュＩＤフィールドと通番フィールドの値はＡと３である。アクティブ装置２０１がＡＣＫパケット５０５を受信するときの通番管理テーブル６０１の状態は、状態ＡＣ２０４と同じ状態ＡＣ２０５なので、受信したＡＣＫパケット５０５のリフレッシュＩＤフィールドの値と通番管理テーブル６０１のリフレッシュＩＤはともにＡであり、かつ、受信したＡＣＫパケット５０５の通番フィールドの値と通番管理テーブル６０１の送信通番はともに３である。
【０１７９】
よって、共有メモリ制御部２１３のデータ受信スレッド４０５は、直前に送信した共有メモリデータパケット５０４に対応するＡＣＫパケット５０５が正常に返信されたことを検知することができる。
【０１８０】
なお、図１１では、共有メモリデータパケット５０４が二つとも経路上で消失したと仮定したが、共有メモリデータパケット５０４が二つとも大幅に遅延してスタンバイ装置２０２に届いた場合も図１１のように処理される。なぜなら、共有メモリ制御部２１３は、所定の時間が過ぎても適切なＡＣＫパケット５０５を受信することができないとき、消失と遅延を区別することができないからである。
【０１８１】
さらに、図６のステップＳ１０６とＳ１０８の両方で「ＮＯ」と判定されて、共有メモリデータパケット５０４の送信が省略された場合も、図１１と同様である。
図１１のとおり、通番フィールドの値が１の共有メモリデータパケット５０４を受信することにより、通番管理テーブル６０２は状態ＳＴ２０２の状態となる。つまり、スタンバイ装置２０２は次に処理すべき共有メモリデータパケット５０４として、通番フィールドの値が２のものを期待している状態になる。
【０１８２】
一方で、図６のステップＳ１０１で送信通番が１から２に更新されて通番管理テーブル６０１が状態ＡＣ２０３となった後、ステップＳ１０６とＳ１０８の両方で「ＮＯ」と判定されると、通番フィールドの値が２の共有メモリデータパケット５０４は送信されない。この場合、共有メモリ制御部２１３は、ＡＣＫパケット５０５が返信されるはずがないことを認識可能である。よって、共有メモリ制御部２１３は、即座にユーザアプリケーション２０７からの次の要求を受け付けてもよい。すると、次の要求を受け付けることにより、ステップＳ１０１で送信通番が２から３に更新されて通番管理テーブル６０１が状態ＡＣ２０４となる。この時点で少なくとも一方の経路が正常なら、図１１の処理の流れとまったく同様に、通番フィールドの値が３の共有メモリデータパケット５０４が送信され
る。
【０１８３】
以上のとおり、実際に起きた現象が消失、遅延、送信の省略のいずれであっても、同様の方法によって通番管理テーブル６０１と６０２は適切に更新される。
次に、図１２を参照して、アクティブ装置２０１を再起動した場合の例を説明する。図１２の状態ＡＣ３０１、状態ＳＴ３０１、状態ＡＣ３０２、状態ＳＴ３０２からなる部分は、リフレッシュＩＤがＡの状態で、通番フィールドの値が２０の共有メモリデータパケット５０４が正常に送信されて受信され、対応するＡＣＫパケット５０５が正常に送信されて受信されることを表している。この部分は、具体的な数値以外は、図１０の状態ＡＣ１０４、状態ＳＴ１０４、状態ＡＣ１０５、状態ＳＴ１０５からなる部分と同様である。
【０１８４】
通番管理テーブル６０１が状態ＡＣ３０２のときにアクティブ装置２０１が再起動されると、通番管理テーブル６０１の送信通番、受信通番、リフレッシュＩＤはいずれも０という例外的な初期値に変化してしまう。
【０１８５】
図１０に示すとおり、共有メモリデータパケット５０４とＡＣＫパケット５０５を適切に送受信するには、通番管理テーブル６０１と６０２が同じ値のリフレッシュＩＤを保持している状態でなくてはならない。しかし、アクティブ装置２０１の再起動によって、通番管理テーブル６０１から「Ａ」というリフレッシュＩＤの値が消えてしまう。そこで、図６にしたがってアクティブ装置２０１が動作することにより、下記のごとく、再び通番管理テーブル６０１と６０２が同じ値のリフレッシュＩＤを保持している状態とする。その結果、共有メモリデータパケット５０４とＡＣＫパケット５０５を適切に送受信することが可能になる。
【０１８６】
すると、再起動後初めてユーザアプリケーション２０７がデータ２０９をスタンバイ装置２０２の共有メモリ２０６に反映するよう共有メモリ制御部２１３に要求したとき、通番管理テーブル６０１は図６のステップＳ１０１〜Ｓ１０３により初期化されて状態ＡＣ３０３になる。ここで、送信通番が１、リフレッシュＩＤがＢである。
【０１８７】
次に、図６のステップＳ１０４でリフレッシュ要求パケット５０２がスタンバイ装置２０２に送信される。スタンバイ装置２０２がリフレッシュ要求パケット５０２を受信したときの通番管理テーブル６０２の状態は、状態ＳＴ３０２と同じ状態ＳＴ３０３なので、通番管理テーブル６０２における受信通番は２１、リフレッシュＩＤはＡである。
【０１８８】
よって、図７のステップＳ２０１の判定が「ＮＯ」となるので、ステップＳ２０２とＳ２０３により通番管理テーブル６０２が更新されて状態ＳＴ３０３から状態ＳＴ３０４へと変わる。ここで、受信通番が１、リフレッシュＩＤがＢであり、状態ＳＴ３０４は初期化された状態である。
【０１８９】
以降の処理は、リフレッシュＩＤの値が異なる以外は、図１０と同様である。すなわち、図１２の状態ＡＣ３０４、状態ＡＣ３０５、状態ＳＴ３０５、状態ＡＣ３０６、状態ＳＴ３０６が、それぞれ、図１０の状態ＡＣ１０３、状態ＡＣ１０４、状態ＳＴ１０４、状態ＡＣ１０５、状態ＳＴ１０５に対応する。
【０１９０】
次に、図１３を参照して、送信通番および受信通番のオーバーフローについて説明する。図１３は、リフレッシュＩＤの必要性を示す例でもある。また、たとえ送信通番と受信通番のオーバーフローが起こる直前で共有メモリデータパケット５０４が消失しても、図６〜図９に示した処理により共有メモリデータパケット５０４同士の前後関係を正しく共有メモリ制御部２１４が把握することができることを、図１３の例は示している。
【０１９１】
図１３の状態ＡＣ４０１、状態ＳＴ４０１、状態ＡＣ４０２、状態ＡＣ４０３、および状態ＳＴ４０２からなる部分は、具体的な数値が１と２ではなく２５４と２５５である点以外は、図１１の状態ＡＣ２０１、状態ＳＴ２０１、状態ＡＣ２０２、状態ＡＣ２０３、および状態ＳＴ２０２からなる部分と同様である。つまり、図１３は、通番フィールドの値が２５４の共有メモリデータパケット５０４は正常に送信および受信され、対応するＡＣＫパケット５０５も正常に送信および受信された後、通番フィールドの値が２５５の共有メモリデータパケット５０４が消失したことを表している。
【０１９２】
この時点の通番管理テーブル６０２は状態ＳＴ４０２なので、スタンバイ装置２０２の共有メモリ制御部２１４は、次に処理すべき共有メモリデータパケット５０４として、リフレッシュＩＤフィールドの値がＡで、通番フィールドの値が２５５の共有メモリデータパケット５０４を期待して待っている状態である。
【０１９３】
一方で、アクティブ装置２０１の共有メモリ制御部２１３は、通番フィールドの値が２５５の共有メモリデータパケット５０４に対応する適切なＡＣＫパケット５０５を所定の時間内に受信することができないので、タイムアウトし、ユーザアプリケーション２０７からの次の要求を受け付ける。
【０１９４】
その結果、図６のステップＳ１０１で、共有メモリ制御部２１３のデータ送信スレッド４０３は、２５５に１を足してオーバーフローした値である０を算出し、算出した０に再度１を足して１を算出し、こうして得られた１を通番管理テーブル６０１の送信通番に設定する。また、ステップＳ１０２の判定が「ＹＥＳ」となるため、ステップＳ１０３で通番管理テーブル６０２のリフレッシュＩＤフィールドには「Ｂ」なる新たな値が設定される。その結果、通番管理テーブル６０２は状態ＡＣ４０４のようになる。
【０１９５】
そして、ステップＳ１０４でリフレッシュ要求パケット５０２がスタンバイ装置２０２に送信される。スタンバイ装置２０２がリフレッシュ要求パケット５０２を受信したときの通番管理テーブル６０２の状態は、状態ＳＴ４０２と同じ状態ＳＴ４０３である。よって、図７のステップＳ２０１の判定が「ＮＯ」となるので、ステップＳ２０２とＳ２０３により通番管理テーブル６０２が更新されて状態ＳＴ４０３から状態ＳＴ４０４へと変わる。ここで、受信通番が１、リフレッシュＩＤがＢであり、状態ＳＴ４０４は初期化された状態である。
【０１９６】
そして、スタンバイ装置２０２から図７のステップＳ２０４でリフレッシュ応答パケット５０３がアクティブ装置２０１へ送信される。アクティブ装置２０１がリフレッシュ応答パケット５０３を受信したときの通番管理テーブル６０１の状態は、状態ＡＣ４０４と同じ状態ＡＣ４０５である。
【０１９７】
以降の処理は、リフレッシュＩＤの具体的な値が異なる以外は図１０と同様であり、正常な共有メモリデータパケット５０４の送受信に関する処理である。つまり、オーバーフローの直前に消失した共有メモリデータパケット５０４があっても、オーバーフロー後の値を通番フィールドにもつ共有メモリデータパケット５０４は適切に処理される。具体的には、図１３の状態ＡＣ４０６、状態ＳＴ４０５、状態ＡＣ４０７、状態ＳＴ４０６からなる部分は、図１０の状態ＡＣ１０４、状態ＳＴ１０４、状態ＡＣ１０５、状態ＳＴ１０５からなる部分と同様である。
【０１９８】
もし、リフレッシュＩＤおよびそれに関する種々の処理がなければ、送信通番のオーバーフロー後に共有メモリデータパケット５０４を受信したとき、スタンバイ装置２０２の共有メモリ制御部２１４は判断を誤る。つまり、共有メモリ制御部２１４は、実際には重複していないパケットを、過去に受信した別のパケットと重複していると誤認する。リフ
レッシュＩＤは同じ値の通番同士を識別する値であり、この誤認を防ぐために利用される。なお、リフレッシュＩＤが識別する「通番」は、送信通番と受信通番の双方である。
【０１９９】
もし、リフレッシュＩＤおよびそれに関する種々の処理がなければ、スタンバイ装置２０２は、通番管理テーブル６０２の受信通番が２５５の状態のまま、通番フィールドの値が１の共有メモリデータパケット５０４を受信してしまう。この場合、図９のステップＳ４０２はリフレッシュＩＤに関する処理なので存在しない。よって、ステップＳ４０１の直後にステップＳ４０３が実行され、１＜２５５なのでステップＳ４０１に戻ってしまう。しかし、これは誤った処理である。
【０２００】
この誤認を防ぐためにリフレッシュＩＤが使われ、共有メモリデータパケット５０４に含まれる送信通番とリフレッシュＩＤの組み合わせが表す順序と、通番管理テーブル６０２に含まれる受信通番とリフレッシュＩＤの組み合わせが表す順序とが比較される。リフレッシュＩＤおよびそれに関する種々の処理により、オーバーフローをはさんでも共有メモリ制御部２１４が正しく共有メモリデータパケット５０４の順序を判定することができ、さらに、オーバーフローの前後に共有メモリデータパケット５０４が消失してさえ、正しい判定が可能となる。
【０２０１】
次に、本発明のプログラムを実行するコンピュータのブロック図である図１４について説明する。本発明のプログラムには送信プログラムと受信プログラムがある。図１の送信元コンピュータ１０１は送信プログラムを実行し、送信先コンピュータ１０２は受信プログラムを実行し、図２のコンピュータ２０１および２０２は送信プログラムと受信プログラムの双方を実行する。送信元コンピュータ１０１、送信先コンピュータ１０２、コンピュータ２０１、およびコンピュータ２０２はいずれも、図１４のコンピュータ７００のような一般的なハードウェア構成を備える。
【０２０２】
図１４のコンピュータ７００は、ＣＰＵ７０１、ＲＯＭ（Read Only Memory）７０２、ＲＡＭ７０３、通信インターフェイス７０４、入力装置７０５、出力装置７０６、記憶装置７０７、可搬型記憶媒体７１０の駆動装置７０８を備え、これらのすべてがバス７０９によって接続されている。
【０２０３】
また、コンピュータ７００は、通信インターフェイス７０４を介してネットワーク７１１に接続されており、ネットワーク７１１を介して通信相手のコンピュータ７１３と通信を行うことができる。つまり、図１の例ではネットワーク７１１が経路１０７と経路１０８を含み、図２の例ではネットワーク７１１が第一経路２１５と第二経路２１６を含む。通信インターフェイス７０４は、コンピュータ７００に元から組み込まれていてもよく、後からコンピュータ７００に取り付けられたＮＩＣでもよい。また、図１４には通信インターフェイス７０４として一つのブロックのみを示したが、通信インターフェイス７０４が物理的には２枚のＮＩＣであり、二つの経路のそれぞれに対応していてもよい。
【０２０４】
コンピュータ７００が送信元コンピュータ１０１の場合は通信相手のコンピュータ７１３が送信先コンピュータ１０２であり、コンピュータ７００が送信先コンピュータ１０２の場合は通信相手のコンピュータ７１３が送信元コンピュータ１０１である。同様に、コンピュータ７００がコンピュータ２０１の場合は通信相手のコンピュータ７１３がコンピュータ２０２であり、コンピュータ７００がコンピュータ２０２の場合は通信相手のコンピュータ７１３がコンピュータ２０１である。
【０２０５】
コンピュータ７００と通信相手のコンピュータ７１３は、例えば、ＬＡＮ（Local Area
Network）内の同じセグメントに含まれるなど、ネットワーク上の位置が近いことが好ましい。なぜなら、ルータによるルーティングを必要とするような、ネットワーク上で離れ
た位置にコンピュータ７００と通信相手のコンピュータ７１３があると、複数の経路が重なってしまうことが多く、経路を多重化する効果が薄れるからである。例えば、複数の経路のすべてが特定のルータを経由する場合、そのルータの不具合が全経路に影響する。また、一般的に、コンピュータ７００と通信相手のコンピュータ７１３のネットワーク上の位置が遠いほど、パケットの消失も起こりがちである。パケットの消失が多いほど、本発明を適用したシステム全体の性能も低下する。
【０２０６】
図２の共有メモリ２０５や２０６は、例えばＲＡＭ７０３の所定の領域である。ＲＡＭ７０３の残りの領域は、図１の送信順序情報１０４または受信順序情報１１１、より具体的には通番管理テーブル６０１または６０２を格納するための制御用データ領域として利用される。図３のデータ転送制御表３０１または３０２も、制御用データ領域に格納される。
【０２０７】
入力装置７０５は、マウスなどのポインティングデバイスやキーボードである。出力装置７０６は例えば液晶ディスプレイなどの表示装置である。記憶装置７０７はハードディスクなどの磁気ディスク装置でもよく、他の種類の記憶装置でもよい。
【０２０８】
記憶装置７０７またはＲＯＭ７０２には、本発明によるプログラムが格納されている。本発明によるプログラムの具体例は、図２の共有メモリ制御部２１３または２１４を実現するミドルウェアのプログラムである。本発明によるプログラムをＣＰＵ７０１が実行することにより、図６〜図９の処理が行われる。
【０２０９】
本発明によるプログラムは、ＬＡＮまたはインターネットなどのネットワーク７１１を介して、プログラム提供者７１２から提供され、記憶装置７０７に記憶され、ＣＰＵ７０１によって実行されてもよい、また、本発明によるプログラムを格納した可搬型記憶媒体７１０が駆動装置７０８にセットされて、格納されたプログラムがＲＡＭ７０３にロードされてＣＰＵ７０１により実行されてもよい。可搬型記憶媒体７１０の例は、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disk）などの光ディスク、光磁気ディスク、フレキシブルディスクなどである。
【０２１０】
なお、本発明は上記の実施形態に限られるものではなく、様々に変形可能である。以下にその例をいくつか述べる。
上記では主に、２台の装置間のデータの同期化のためのデータ送信に本発明を利用する場合について説明したが、当然その他の目的のデータ送信にも本発明は適用可能である。データ送信の目的によって、受信したパケットの内容を使って具体的にどのような処理を行うかも異なる。
【０２１１】
図２〜図１３の実施形態におけるデータ送信の目的は、データの同期化である。よって、図２のコンピュータ２０２がスタンバイ装置として運用されているとき、共有メモリ制御部２１４は、図９のステップＳ４０５において、受信した共有メモリデータパケット５０４の共有メモリデータフィールドの内容を共有メモリ２０６に反映する。
【０２１２】
しかし、受信したパケットの内容を使うこのような処理は、実施形態に固有のものである。例えば、一般に、ＵＤＰはマルチキャストやブロードキャストにも利用され、リアルタイム性が重視されるストリーミングデータの送信にも利用される。ＵＤＰによるストリーミングデータの送信に本発明を適用する場合は、データ送信の目的はストリーミングデータの再生であろう。その場合、「共有メモリデータパケット」や「共有メモリデータフィールド」という名称は適切ではないものの、共有メモリデータパケット５０４と類似の形式のパケットが送信され、図９のステップＳ４０５は、送信されたパケットに含まれるストリーミングデータを再生する処理、またはストリーミングデータの再生を再生用アプ
リケーションに要求する処理に置き換えられる。
【０２１３】
本発明の適用対象は、ステップＳ４０５以外にも影響することがある。例えば、ある別の実施形態では、パケットの消失が生じた場合に、消失したパケットより後の順序に対応するパケットに関する処理を行わない。例えば、送信通番が「３」のパケットが消失したら、送信通番が「４」のパケットは受信されても破棄される。そのような実施形態では、図９のステップＳ４０４の実行後、ステップＳ４０５は実行されず、処理がステップＳ４０６に進む。
【０２１４】
パケットが消失したときの動作には、共有メモリ制御部２１３を呼び出すユーザアプリケーションの数も影響する。図２には一つのユーザアプリケーション２０７のみを示したが、一般には、複数のユーザアプリケーションが共有メモリ制御部２１３にデータ２０９の反映を要求する。
【０２１５】
例えば、共有メモリ制御部２１３は、ユーザアプリケーションＡ１からの要求を「４」なる送信通番で処理し、ユーザアプリケーションＡ２からの要求を「５」なる送信通番で処理するかもしれない。この場合、「４」なる送信通番に対応する共有メモリデータパケット５０４が消失しても、ユーザアプリケーションＡ２には関係がない。よって、「５」なる送信通番に対応する共有メモリデータパケット５０４は、もし正常にスタンバイ装置２０２で受信されたならば、破棄されるべきではない。その共有メモリデータパケット５０４の共有メモリデータフィールドの内容は、共有メモリ２０６に反映されるべきである。
【０２１６】
一方で、一つのユーザアプリケーションＡ１からのみ共有メモリ制御部２１３が要求を受け付ける実施形態においては、消失したパケットＰ１と、その次のパケットＰ２は必ず同じユーザアプリケーションＡ１のデータを含む。よって、データの整合性を保つために、共有メモリ制御部２１４は、パケットＰ１の消失を検知したらパケットＰ２を破棄したほうがよい場合もある。
【０２１７】
また、データの一部が欠損することを許容するある種のアプリケーションは、パケットが消失してもパケットを再送しない。そのようなユーザアプリケーションと組み合わせて本発明を利用する場合、共有メモリ制御部２１３は、共有メモリデータパケット５０４の送信後、一定時間内にＡＣＫパケット５０５を受信することができずにタイムアウトしたとき、送信が失敗したことをユーザアプリケーションに通知しなくてもよい。
【０２１８】
図９の実施形態では、パケットが消失した場合もステップＳ４０６でＡＣＫパケット５０５を返信している。しかし、消失を示す別種のパケットである「ＡＣＫ‐ＮＧパケット」を定義し、ＡＣＫ‐ＮＧパケットを返信するように図９の処理を変形してもよい。
【０２１９】
もちろん、図９の処理であっても、図１１のシーケンス図から分かるように、送信側の共有メモリ制御部２１３が消失を検知することは可能である。すなわち、連続する二つのＡＣＫパケット５０５の通番フィールドとリフレッシュＩＤフィールドが、連続する順序を表していなければ、共有メモリ制御部２１３は、その不連続の部分でパケットが消失したことを検知することができる。つまり、あるパケットの消失後に正常に受信された別のパケットに対するＡＣＫパケット５０５は、消失を通知する役割も兼ねている。しかし、ＡＣＫ‐ＮＧパケットを適切に定義すれば、共有メモリ制御部２１３は、単にＴＹＰＥ２フィールドの値を読み取るだけで、パケットが生じたか否かを検知することができる。
【０２２０】
なお、リフレッシュ応答パケット５０３などの制御用パケットは、実施形態によっては、一つの経路のみを介して送信してもよい。仮にその一つの経路が異常で、リフレッシュ
応答パケット５０３が正常に受信されなくても、通番管理テーブル６０１と６０２のリフレッシュＩＤを適切に同期させることは可能である。そのためには、例えば、アクティブ装置２０１の共有メモリ制御部２１３がタイムアウトして、再度リフレッシュ要求パケット５０２の送信からやり直せばよい。リフレッシュ要求パケット５０２やＡＣＫパケット５０５も同様に、少なくとも一つの経路を介して送信すればよく、すべての経路を介して送信しなくてもよい。
【０２２１】
また、図２の例では、アクティブ装置とスタンバイ装置が交互に切り換えられるという前提があるので、共有メモリ制御部２１３と２１４はともに、データを送信するための機能と受信するための機能の双方を備えている。しかし、実施形態によっては、一方の装置にはデータを送信する機能のみが組み込まれており、他方の装置にはデータを受信する機能のみが組み込まれていてもよい。
【０２２２】
なお、データを送信するための機能と受信するための機能の双方を備えた二つの装置を組にする例は、図２の例に限らない。図２では、共有メモリデータパケット５０４は必ずアクティブ装置２０１からスタンバイ装置２０２へ送信される。しかし、データの同期化以外の目的で、二つの装置ＸとＹの間でデータをやりとりする通信の場合、装置Ｘから装置Ｙへの送信と、装置Ｙから装置Ｘへの送信の両方が、予測不可能な順序でランダムに生じることがある。そのような場合にも、本発明を適用することは可能である。その場合、リフレッシュＩＤを更新するタイミングが、図２の実施形態とは異なっていてもよい。
【０２２３】
図２の実施形態では、アクティブ装置とスタンバイ装置が切り換えられるたびに、リフレッシュ要求パケット５０２とリフレッシュ応答パケット５０３が送受信され、通番管理テーブル６０１と６０２のリフレッシュＩＤが更新されることを前提としている。この前提は、必須の前提条件ではないものの、管理の簡潔さなどの面から、切り換えをまたいで同じ値のリフレッシュＩＤを使い続けるよりも好ましい。
【０２２４】
一方で、装置Ｘから装置Ｙへの送信と、装置Ｙから装置Ｘへの送信の両方がランダムに生じる場合には、例えば装置Ｘから装置Ｙへの送信があった後で装置Ｙが装置Ｘにパケットを送信しようとするたびにリフレッシュＩＤを更新すると、リフレッシュＩＤの更新が頻繁になりすぎることがある。よって、この場合、送信順序情報のオーバーフロー時と装置の再起動時にのみリフレッシュＩＤを更新するように装置ＸとＹを構成してもよい。
【０２２５】
図２では、共有メモリ制御部２１３と２１４を実現するミドルウェアとして本発明を実施する例を示した。しかし、本発明によるプログラムは、ＯＳに組み込まれていてもよく、アプリケーションプログラムであってもよい。また、本発明によるプログラムは、マルチスレッド・プログラムでなくてもよい。また、本発明は、ソフトウェアすなわちプログラムにより実現されるだけでなく、ハードウェア、ファームウェア、またはこれらの任意の組み合わせにより実現することも可能である。
【０２２６】
上記では、経路の数が２の場合の例について説明したが、三つ以上の経路を用いて本発明を実施することもできる。例えば、三つの経路を用いる場合、図４には、第一経路受信スレッドと第二経路受信スレッド４０７〜４１０のほかに、第三経路受信スレッドを共有メモリ制御部２１３と２１４にそれぞれ追加する必要があり、図３のデータ転送制御表３０１と３０２には、第三経路に関するレコードを追加する必要がある。しかし、三つ以上の経路を用いる場合でも、フローチャートに示した処理の流れは二つの経路を用いる場合と同様である。ただし、実用上は、次のような理由から、二つの経路を利用することが最適である場合が多い。
【０２２７】
・経路の数を増やすことはケーブルなどのハードウェアの増設をともない、費用がかか
る。
・ハードウェアの増設を避けるために、複数の経路がハードウェアを共有することは可能である。しかし、同じハードウェアを共有する経路の数が増えるほど、そのハードウェアでエラーが発生しやすくなる。例えば、同一のケーブルを共有する経路の数を増やすほど、そのケーブル上のトラフィック量が増加し、そのケーブル内で衝突などのエラーが発生しやすくなる。
【０２２８】
・ハードウェアを共有しない二つの経路に故障が同時に発生することは、事実上ほとんどないので、二つの経路だけで実用上十分な信頼性を得ることができる。
また、図５に示したパケットの形式も、実施形態に応じて変形することができる。各フィールドの長さやフィールドの並び順は実施形態によって任意である。また、パケットの種別をＴＹＰＥ１とＴＹＰＥ２により階層的に分類せず、一つのフィールドだけでパケットの種別を示してもよいことは当然である。また、実施形態によってはリフレッシュＩＤフィールドが不要なこともある。
【０２２９】
つまり、送信通番と受信通番の桁数が、実用上、同じ番号を再利用する可能性がないと見なせる程度に十分多い場合などには、リフレッシュＩＤを使う必要がない。このとき、各種パケットにはリフレッシュＩＤフィールドが不要であり、通番管理テーブル６０１と６０２にもリフレッシュＩＤフィールドは不要である。
【０２３０】
例えば、装置を一定の間隔で再起動させるという規則にしたがってシステムが運用される場合、送信通番と受信通番の桁数と、再起動の間隔との関係によっては、リフレッシュＩＤフィールドが不要となる場合がありうる。
【０２３１】
また、上記実施形態の送信通番と受信通番の値は、順序が前であるほど小さい値である。しかし、別の実施形態では、順序が前であるほど大きい値であってもよい。当然その場合は、図６のステップＳ１０２の加算を減算に変え、図９のステップＳ４０３の判定で「より大きい」と「未満」を逆転させる、などの変更をあわせて行う必要がある。
【０２３２】
さらに、送信順序情報と受信順序情報は、順序の前後関係を比較することが可能な情報でさえあれば、上記の実施形態以外の任意の形式でよい。例えば、上記の例の受信通番は、次に受信されると期待されるパケットの送信通番そのものの値である。しかし、別の実施形態では、最後に受信したパケットの送信通番を通番管理テーブル６０１や６０２に受信通番として格納し、格納された受信通番に１を足した値を、受信した共有メモリデータパケット５０４の通番フィールドの値と比較することによって、順序の前後を判定してもよい。この場合、具体的に使われる値が最後に受信したパケットの送信通番であるという点が図６などの例とは異なる。しかし、受信通番が、次に受信されると期待されるパケットの順序を示すための値であることに変わりはない。同様に、送信順序情報と受信順序情報の一部である識別情報も、上記のようなリフレッシュＩＤ以外の任意の形式の情報であってよい。
【０２３３】
以上説明したことを概観すれば本発明は以下のような構成を備えるものである。
（付記１）
データの到達を保証しないプロトコルにより送信元コンピュータから複数の経路のそれぞれを介して、異なるパケット間の送信順序を示す送信順序情報を含めて送信された同内容のパケットを受信して、パケットの重複および消失を判別する処理を送信先コンピュータに制御させる受信プログラムであって、
前記複数の経路のいずれを介して送信された前記パケットでも受信する受信ステップと、
受信した前記パケットから、前記送信順序情報を取得する送信順序情報取得ステップと
、
過去に受信した前記パケットの前記送信順序情報にもとづいて管理され、次に受信されると期待されるパケットに対応する順序を表す受信順序情報を、格納手段から取得する受信順序情報取得ステップと、
前記送信順序情報が表す第一の順序と前記受信順序情報が表す第二の順序を比較する比較ステップと、
前記第一の順序が前記第二の順序よりも前の場合に、前記受信ステップで受信した前記パケットが、過去に受信した他のパケットと重複すると判断する重複判断ステップと、
前記第一の順序と前記第二の順序が等しい場合に、前記格納手段に格納された前記受信順序情報が表す順序が前記第二の順序の次の順序になるよう前記格納手段を更新する正常処理ステップと、
前記第一の順序が前記第二の順序よりも後の場合に、パケットの消失が生じたと判断する消失判断ステップと、
を前記送信先コンピュータに実行させることを特徴とする受信プログラム。
（付記２）
前記受信順序情報は番号を含み、
前記正常処理ステップでは、前記受信順序情報に含まれる前記番号に１を加算または減算することにより、前記受信順序情報が更新される、
ことを特徴とする付記１に記載の受信プログラム。
（付記３）
前記正常処理ステップでさらに前記送信先コンピュータに、前記パケットの送達確認を前記送信元コンピュータへ送信させることを特徴とする付記１に記載の受信プログラム。（付記４）
前記消失判断ステップでさらに前記送信先コンピュータに、前記送信順序情報にもとづいて前記格納手段を更新させることを特徴とする付記１に記載の受信プログラム。
（付記５）
前記消失判断ステップでさらに前記送信先コンピュータに、パケットの消失を前記送信元コンピュータに通知させることを特徴とする付記１に記載の受信プログラム。
（付記６）
前記送信順序情報と前記受信順序情報はいずれも、有限の桁数の番号と、同じ値の前記番号同士を識別するための識別情報の双方を含み、
前記送信元コンピュータから送信された、前記識別情報の更新を要求するリフレッシュ要求パケットを受信した場合は、
前記受信順序情報に含まれる前記識別情報が、前記リフレッシュ要求パケットが指定する値になるよう前記格納手段を更新する識別情報更新ステップと、
前記リフレッシュ要求パケットの送達確認を前記送信元コンピュータへ送信する送達確認ステップと、
をさらに前記送信先コンピュータに実行させることを特徴とする付記１に記載の受信プログラム。
（付記７）
前記比較ステップでは、前記受信ステップで受信した前記パケットに含まれる前記識別情報と、前記受信順序情報に含まれる前記識別情報が等しくなければ、前記第一の順序が前記第二の順序よりも前だと判断される、
ことを特徴とする付記６に記載の受信プログラム。
（付記８）
前記識別情報は、日付または時刻の少なくとも一方にもとづく情報であることを特徴とする付記６に記載の受信プログラム。
（付記９）
前記プロトコルはＵＤＰであることを特徴とする付記１に記載の受信プログラム。
（付記１０）
データの到達を保証しないプロトコルによる送信先コンピュータへのデータの送信処理を送信元コンピュータに制御させる送信プログラムであって、
異なるパケット間の送信順序を示す送信順序情報を格納手段から取得する送信順序情報取得ステップと、
前記格納手段に格納されている前記送信順序情報を更新する送信順序情報更新ステップと、
同じ前記送信順序情報および同じ送信対象のデータを含む、複数の経路のそれぞれに対応する複数のパケットを作成するパケット作成ステップと、
前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記送信先コンピュータに送信する送信ステップと、
を前記送信元コンピュータに実行させることを特徴とする送信プログラム。
（付記１１）
前記送信順序情報は番号を含み、
前記送信順序情報更新ステップでは、前記送信順序情報に含まれる前記番号に１を加算または減算することにより、前記送信順序情報が更新される、
ことを特徴とする付記１０に記載の送信プログラム。
（付記１２）
前記送信順序情報は、有限の桁数の番号と、同じ値の前記番号同士を識別するための識別情報とを含み、
前記番号が所定の値に等しい場合に、前記送信プログラムは、前記送信ステップよりも前に、
前記識別情報を更新する識別情報更新ステップと、
更新された前記識別情報を前記送信先コンピュータに設定するよう要求するリフレッシュ要求パケットを前記送信先コンピュータに送信するリフレッシュ要求ステップと、
前記リフレッシュ要求パケットの送達確認が前記送信先コンピュータから送信されるのを待つ送達確認待ちステップと、
を前記送信元コンピュータに実行させる、
ことを特徴とする付記１０に記載の送信プログラム。
（付記１３）
前記識別情報更新ステップにおいて前記識別情報は、該識別情報更新ステップが実行される日付または時刻の少なくとも一方にもとづいて更新されることを特徴とする付記１２に記載の送信プログラム。
（付記１４）
前記複数の経路のそれぞれの状態を監視する監視ステップをさらに前記送信元コンピュータに実行させ、
前記送信ステップにおいて、前記送信元コンピュータに、前記監視ステップにより前記状態が悪いと判断された前記経路を介した送信を省略させる、
ことを特徴とする付記１０に記載の送信プログラム。
（付記１５）
前記監視ステップは、所定の間隔で前記送信先コンピュータが前記複数の経路のそれぞれを介して前記送信元コンピュータに送信する監視用パケットを受信し、前記監視用パケットの受信間隔にもとづいて前記複数の経路のそれぞれの前記状態を判断するステップであることを特徴とする付記１４に記載の送信プログラム。
（付記１６）
データの到達を保証しないプロトコルにより複数の経路のそれぞれを介して第一のコンピュータが第二のコンピュータにパケットを送信するシステムであって、
前記第一のコンピュータが、
異なるパケット間の送信順序を示す送信順序情報を格納する送信順序情報格納手段と、
前記送信順序情報を取得してから、前記送信順序情報格納手段に格納された前記送信順序情報を更新する送信順序情報更新手段と、
取得された同じ前記送信順序情報および同じ送信対象のデータを含む、前記複数の経路のそれぞれに対応する複数のパケットを作成するパケット作成手段と、
前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記第二のコンピュータに送信する送信手段とを備え、
前記第二のコンピュータが、
前記複数の経路のいずれを介して送信された前記パケットでも受信する受信手段と、
過去に受信した前記パケットの前記送信順序情報にもとづいて管理され、次に受信されると期待されるパケットに対応する順序を表す受信順序情報を格納する受信順序情報格納手段と、
受信した前記パケットに含まれる前記送信順序情報が表す第一の順序と、前記受信順序情報が表す第二の順序を比較して、前記第一の順序が前記第二の順序よりも前の場合は受信した前記パケットが過去に受信した他の前記パケットと重複すると判断し、前記第一の順序が前記第二の順序よりも後の場合はパケットの消失が生じたと判断する比較判断手段と、
前記第一の順序と前記第二の順序が等しい場合に、前記受信順序情報が表す順序が前記第二の順序の次の順序になるよう前記受信順序情報格納手段を更新する正常処理手段と、
を備えることを特徴とするシステム。
（付記１７）
前記第一のコンピュータが、前記第二のコンピュータと同様の受信手段、受信順序情報格納手段、比較判断手段、および正常処理手段を備え、
前記第二のコンピュータが、前記第一のコンピュータと同様の送信順序情報格納手段、送信順序情報更新手段、パケット作成手段、および送信手段を備え、
前記第一のコンピュータから前記第二のコンピュータへの前記パケットの送信と、前記第二のコンピュータから前記第一のコンピュータへの前記パケットの送信の双方が行われる、
ことを特徴とする付記１６のシステム。
（付記１８）
前記第一のコンピュータが第一の記憶装置を備え、
前記第二のコンピュータが第二の記憶装置を備え、
前記第一のコンピュータと前記第二のコンピュータが、それぞれ現用装置と該現用装置に対応する待機装置として機能し、
前記第一の記憶装置に格納されたデータを前記第一のコンピュータが前記第二のコンピュータに送信し、受信したデータを前記第二のコンピュータが前記第二の記憶装置に上書きすることにより、前記第一の記憶装置と前記第二の記憶装置がそれぞれ格納するデータが同期化される、
ことを特徴とする付記１６に記載のシステム。
（付記１９）
データの到達を保証しないプロトコルにより複数の経路のそれぞれを介して、第一の装置が第二の装置に、異なるパケット間の送信順序を示す送信順序情報を含めてパケットを送信する方法であって、
前記第一の装置において、
同じ前記送信順序情報および同じ送信対象のデータを含む、前記複数の経路に対応する複数のパケットを作成し、
前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記第二の装置に送信し、
前記第二の装置において、
前記複数の経路の一つから受信した前記パケットの前記送信順序情報が、過去に受信したパケットの前記送信順序情報と重複する場合は、前記パケットを破棄する、
ことを特徴とする方法。
（付記２０）
前記第二の装置において、
次に受信されると期待されるパケットに対応する順序を表す情報を、過去に受信した前記パケットの前記送信順序情報にもとづいて、受信順序情報として管理し、
受信した前記パケットの前記送信順序情報と前記受信順序情報が表す順序が等しければ、受信した前記パケットを処理する、
ことを特徴とする付記１９に記載の方法。
【図面の簡単な説明】
【０２３４】
【図１】本発明の原理を示す図である。
【図２】本発明を利用してデータの同期化を行う二重化システムの構成図である。
【図３】データ転送制御表の例である。
【図４】共有メモリ制御部を実現するミドルウェアを構成するスレッドのブロック図である。
【図５】各種パケットの形式を説明する図である。
【図６】共有メモリデータ送信処理のフローチャートである。
【図７】リフレッシュ要求受信処理のフローチャートである。
【図８】リフレッシュ応答受信処理のフローチャートである。
【図９】共有メモリデータ受信処理のフローチャートである。
【図１０】初期状態と、その後に続く正常な処理の結果を示す処理シーケンス図である。
【図１１】共有メモリデータパケットが消失する場合の処理シーケンス図である。
【図１２】アクティブ装置を再起動した場合の処理シーケンス図である。
【図１３】送信通番および受信通番のオーバーフローを説明する処理シーケンス図である。
【図１４】本発明のプログラムを実行するコンピュータのブロック図である。
【符号の説明】
【０２３５】
１０１ 送信元コンピュータ
１０２ 送信先コンピュータ
１０３ 送信対象データ
１０４、１０９、１１０ 送信順序情報
１０５、１０６ パケット
１０７、１０８ 経路
１１１ 受信順序情報
２０１ コンピュータ、アクティブ装置
２０２ コンピュータ、スタンバイ装置
２０３ 仮想共有メモリ
２０５、２０６ 共有メモリ
２０７ ユーザアプリケーション
２０９、２１０ データ
２１０ データ
２１１、２１２ ミドルウェア群
２１３、２１４ 共有メモリ制御部
２１５ 第一経路
２１６ 第二経路
３０１、３０２ データ転送制御表
４０１、４０２ ヘルスチェックスレッド
４０３、４０４ データ送信スレッド
４０５、４０６ データ受信スレッド
４０７、４０８ 第一経路受信スレッド
４０９、４１０ 第二経路受信スレッド
４１１〜４１４ ＵＤＰポート
５０１ ヘルスチェックパケット
５０２ リフレッシュ要求パケット
５０３ リフレッシュ応答パケット
５０４ 共有メモリデータパケット
５０５ ＡＣＫパケット
６０１ａ、６０１ｂ、６０２ａ、６０２ｂ 通番管理テーブル
７００ コンピュータ
７０１ ＣＰＵ
７０２ ＲＯＭ
７０３ ＲＡＭ
７０４ 通信インターフェイス
７０５ 入力装置
７０６ 出力装置
７０７ 記憶装置
７０８ 駆動装置
７０９ バス
７１０ 可搬型記憶媒体
７１１ ネットワーク
７１２ プログラム提供者
７１３ 通信相手のコンピュータ
【特許請求の範囲】
【請求項１】
データの到達を保証しないプロトコルにより送信元コンピュータから複数の経路のそれぞれを介して、異なるパケット間の送信順序を示す送信順序情報を含めて送信された同内容のパケットを受信して、パケットの重複および消失を判別する処理を送信先コンピュータに制御させる受信プログラムであって、
前記複数の経路のいずれを介して送信された前記パケットでも受信する受信ステップと、
受信した前記パケットから、前記送信順序情報を取得する送信順序情報取得ステップと、
過去に受信した前記パケットの前記送信順序情報にもとづいて管理され、次に受信されると期待されるパケットに対応する順序を表す受信順序情報を、格納手段から取得する受信順序情報取得ステップと、
前記送信順序情報が表す第一の順序と前記受信順序情報が表す第二の順序を比較する比較ステップと、
前記第一の順序が前記第二の順序よりも前の場合に、前記受信ステップで受信した前記パケットが、過去に受信した他のパケットと重複すると判断する重複判断ステップと、
前記第一の順序と前記第二の順序が等しい場合に、前記格納手段に格納された前記受信順序情報が表す順序が前記第二の順序の次の順序になるよう前記格納手段を更新する正常処理ステップと、
前記第一の順序が前記第二の順序よりも後の場合に、パケットの消失が生じたと判断する消失判断ステップと、
を前記送信先コンピュータに実行させることを特徴とする受信プログラム。
【請求項２】
前記正常処理ステップでさらに前記送信先コンピュータに、前記パケットの送達確認を前記送信元コンピュータへ送信させることを特徴とする請求項１に記載の受信プログラム。
【請求項３】
前記消失判断ステップでさらに前記送信先コンピュータに、前記送信順序情報にもとづいて前記格納手段を更新させることを特徴とする請求項１に記載の受信プログラム。
【請求項４】
前記送信順序情報と前記受信順序情報はいずれも、有限の桁数の番号と、同じ値の前記番号同士を識別するための識別情報の双方を含み、
前記送信元コンピュータから送信された、前記識別情報の更新を要求するリフレッシュ要求パケットを受信した場合は、
前記受信順序情報に含まれる前記識別情報が、前記リフレッシュ要求パケットが指定する値になるよう前記格納手段を更新する識別情報更新ステップと、
前記リフレッシュ要求パケットの送達確認を前記送信元コンピュータへ送信する送達確認ステップと、
をさらに前記送信先コンピュータに実行させることを特徴とする請求項１に記載の受信プログラム。
【請求項５】
データの到達を保証しないプロトコルによる送信先コンピュータへのデータの送信処理を送信元コンピュータに制御させる送信プログラムであって、
異なるパケット間の送信順序を示す送信順序情報を格納手段から取得する送信順序情報取得ステップと、
前記格納手段に格納されている前記送信順序情報を更新する送信順序情報更新ステップと、
同じ前記送信順序情報および同じ送信対象のデータを含む、複数の経路のそれぞれに対応する複数のパケットを作成するパケット作成ステップと、
前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記送信先コンピュータに送信する送信ステップと、
を前記送信元コンピュータに実行させることを特徴とする送信プログラム。
【請求項６】
前記送信順序情報は、有限の桁数の番号と、同じ値の前記番号同士を識別するための識別情報とを含み、
前記番号が所定の値に等しい場合に、前記送信プログラムは、前記送信ステップよりも前に、
前記識別情報を更新する識別情報更新ステップと、
更新された前記識別情報を前記送信先コンピュータに設定するよう要求するリフレッシュ要求パケットを前記送信先コンピュータに送信するリフレッシュ要求ステップと、
前記リフレッシュ要求パケットの送達確認が前記送信先コンピュータから送信されるのを待つ送達確認待ちステップと、
を前記送信元コンピュータに実行させる、
ことを特徴とする請求項５に記載の送信プログラム。
【請求項７】
データの到達を保証しないプロトコルにより複数の経路のそれぞれを介して第一のコンピュータが第二のコンピュータにパケットを送信するシステムであって、
前記第一のコンピュータが、
異なるパケット間の送信順序を示す送信順序情報を格納する送信順序情報格納手段と、
前記送信順序情報を取得してから、前記送信順序情報格納手段に格納された前記送信順序情報を更新する送信順序情報更新手段と、
取得された同じ前記送信順序情報および同じ送信対象のデータを含む、前記複数の経路のそれぞれに対応する複数のパケットを作成するパケット作成手段と、
前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記第二のコンピュータに送信する送信手段とを備え、
前記第二のコンピュータが、
前記複数の経路のいずれを介して送信された前記パケットでも受信する受信手段と、
過去に受信した前記パケットの前記送信順序情報にもとづいて管理され、次に受信されると期待されるパケットに対応する順序を表す受信順序情報を格納する受信順序情報格納手段と、
受信した前記パケットに含まれる前記送信順序情報が表す第一の順序と、前記受信順序情報が表す第二の順序を比較して、前記第一の順序が前記第二の順序よりも前の場合は受信した前記パケットが過去に受信した他の前記パケットと重複すると判断し、前記第一の順序が前記第二の順序よりも後の場合はパケットの消失が生じたと判断する比較判断手段と、
前記第一の順序と前記第二の順序が等しい場合に、前記受信順序情報が表す順序が前記第二の順序の次の順序になるよう前記受信順序情報格納手段を更新する正常処理手段と、
を備えることを特徴とするシステム。
【請求項８】
データの到達を保証しないプロトコルにより複数の経路のそれぞれを介して、第一の装置が第二の装置に、異なるパケット間の送信順序を示す送信順序情報を含めてパケットを送信する方法であって、
前記第一の装置において、
同じ前記送信順序情報および同じ送信対象のデータを含む、前記複数の経路に対応する複数のパケットを作成し、
前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記第二の装置に送信し、
前記第二の装置において、
前記複数の経路の一つから受信した前記パケットの前記送信順序情報が、過去に受信し
たパケットの前記送信順序情報と重複する場合は、前記パケットを破棄する、
ことを特徴とする方法。
【請求項１】
データの到達を保証しないプロトコルにより送信元コンピュータから複数の経路のそれぞれを介して、異なるパケット間の送信順序を示す送信順序情報を含めて送信された同内容のパケットを受信して、パケットの重複および消失を判別する処理を送信先コンピュータに制御させる受信プログラムであって、
前記複数の経路のいずれを介して送信された前記パケットでも受信する受信ステップと、
受信した前記パケットから、前記送信順序情報を取得する送信順序情報取得ステップと、
過去に受信した前記パケットの前記送信順序情報にもとづいて管理され、次に受信されると期待されるパケットに対応する順序を表す受信順序情報を、格納手段から取得する受信順序情報取得ステップと、
前記送信順序情報が表す第一の順序と前記受信順序情報が表す第二の順序を比較する比較ステップと、
前記第一の順序が前記第二の順序よりも前の場合に、前記受信ステップで受信した前記パケットが、過去に受信した他のパケットと重複すると判断する重複判断ステップと、
前記第一の順序と前記第二の順序が等しい場合に、前記格納手段に格納された前記受信順序情報が表す順序が前記第二の順序の次の順序になるよう前記格納手段を更新する正常処理ステップと、
前記第一の順序が前記第二の順序よりも後の場合に、パケットの消失が生じたと判断する消失判断ステップと、
を前記送信先コンピュータに実行させることを特徴とする受信プログラム。
【請求項２】
前記正常処理ステップでさらに前記送信先コンピュータに、前記パケットの送達確認を前記送信元コンピュータへ送信させることを特徴とする請求項１に記載の受信プログラム。
【請求項３】
前記消失判断ステップでさらに前記送信先コンピュータに、前記送信順序情報にもとづいて前記格納手段を更新させることを特徴とする請求項１に記載の受信プログラム。
【請求項４】
前記送信順序情報と前記受信順序情報はいずれも、有限の桁数の番号と、同じ値の前記番号同士を識別するための識別情報の双方を含み、
前記送信元コンピュータから送信された、前記識別情報の更新を要求するリフレッシュ要求パケットを受信した場合は、
前記受信順序情報に含まれる前記識別情報が、前記リフレッシュ要求パケットが指定する値になるよう前記格納手段を更新する識別情報更新ステップと、
前記リフレッシュ要求パケットの送達確認を前記送信元コンピュータへ送信する送達確認ステップと、
をさらに前記送信先コンピュータに実行させることを特徴とする請求項１に記載の受信プログラム。
【請求項５】
データの到達を保証しないプロトコルによる送信先コンピュータへのデータの送信処理を送信元コンピュータに制御させる送信プログラムであって、
異なるパケット間の送信順序を示す送信順序情報を格納手段から取得する送信順序情報取得ステップと、
前記格納手段に格納されている前記送信順序情報を更新する送信順序情報更新ステップと、
同じ前記送信順序情報および同じ送信対象のデータを含む、複数の経路のそれぞれに対応する複数のパケットを作成するパケット作成ステップと、
前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記送信先コンピュータに送信する送信ステップと、
を前記送信元コンピュータに実行させることを特徴とする送信プログラム。
【請求項６】
前記送信順序情報は、有限の桁数の番号と、同じ値の前記番号同士を識別するための識別情報とを含み、
前記番号が所定の値に等しい場合に、前記送信プログラムは、前記送信ステップよりも前に、
前記識別情報を更新する識別情報更新ステップと、
更新された前記識別情報を前記送信先コンピュータに設定するよう要求するリフレッシュ要求パケットを前記送信先コンピュータに送信するリフレッシュ要求ステップと、
前記リフレッシュ要求パケットの送達確認が前記送信先コンピュータから送信されるのを待つ送達確認待ちステップと、
を前記送信元コンピュータに実行させる、
ことを特徴とする請求項５に記載の送信プログラム。
【請求項７】
データの到達を保証しないプロトコルにより複数の経路のそれぞれを介して第一のコンピュータが第二のコンピュータにパケットを送信するシステムであって、
前記第一のコンピュータが、
異なるパケット間の送信順序を示す送信順序情報を格納する送信順序情報格納手段と、
前記送信順序情報を取得してから、前記送信順序情報格納手段に格納された前記送信順序情報を更新する送信順序情報更新手段と、
取得された同じ前記送信順序情報および同じ送信対象のデータを含む、前記複数の経路のそれぞれに対応する複数のパケットを作成するパケット作成手段と、
前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記第二のコンピュータに送信する送信手段とを備え、
前記第二のコンピュータが、
前記複数の経路のいずれを介して送信された前記パケットでも受信する受信手段と、
過去に受信した前記パケットの前記送信順序情報にもとづいて管理され、次に受信されると期待されるパケットに対応する順序を表す受信順序情報を格納する受信順序情報格納手段と、
受信した前記パケットに含まれる前記送信順序情報が表す第一の順序と、前記受信順序情報が表す第二の順序を比較して、前記第一の順序が前記第二の順序よりも前の場合は受信した前記パケットが過去に受信した他の前記パケットと重複すると判断し、前記第一の順序が前記第二の順序よりも後の場合はパケットの消失が生じたと判断する比較判断手段と、
前記第一の順序と前記第二の順序が等しい場合に、前記受信順序情報が表す順序が前記第二の順序の次の順序になるよう前記受信順序情報格納手段を更新する正常処理手段と、
を備えることを特徴とするシステム。
【請求項８】
データの到達を保証しないプロトコルにより複数の経路のそれぞれを介して、第一の装置が第二の装置に、異なるパケット間の送信順序を示す送信順序情報を含めてパケットを送信する方法であって、
前記第一の装置において、
同じ前記送信順序情報および同じ送信対象のデータを含む、前記複数の経路に対応する複数のパケットを作成し、
前記複数の経路のそれぞれを介して前記プロトコルにより前記複数のパケットを前記第二の装置に送信し、
前記第二の装置において、
前記複数の経路の一つから受信した前記パケットの前記送信順序情報が、過去に受信し
たパケットの前記送信順序情報と重複する場合は、前記パケットを破棄する、
ことを特徴とする方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２００８−２１１６８２（Ｐ２００８−２１１６８２Ａ）
【公開日】平成２０年９月１１日（２００８．９．１１）
【国際特許分類】
【出願番号】特願２００７−４８１４３（Ｐ２００７−４８１４３）
【出願日】平成１９年２月２７日（２００７．２．２７）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２０年９月１１日（２００８．９．１１）
【国際特許分類】
【出願日】平成１９年２月２７日（２００７．２．２７）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]