JP4956603B2 - 分散システムおよび論理時間調整方法 - Google Patents

Description

本発明は、ネットワークに接続されたｎ台のコンピュータのうちの（ｎ−ｔ）台以上のコンピュータが相互にパケットを送受信してｔ−耐故障ビザンチン合意アルゴリズムを用いて合意を取ることにより分散処理を行う分散システムに係り、特に論理時間とシステム時間とを同期させるのに好適な分散システムおよび論理時間調整方法に関する。

近年、コンピュータ技術やネットワーク技術の向上は目覚ましく、これに伴って業務のコンピュータ化が広く行われている。また、その業務の内容によっては故障などによる中断が許されないものも多く、最近では分散システムを構築することが一般的になりつつある。

分散システムとは、ネットワークで接続された複数のコンピュータが、相互に情報を授受しながら、１つの処理を行うシステムである。この分散システムでは、当該システムを構成する複数のコンピュータが一貫性、整合性を保つために、コンピュータ間で合意を取っている。

特許文献１には、コンピュータ間で合意を取る処理において、ｔ−耐故障ビザンチン合意アルゴリズムを用いて多重化制御および時間管理をする分散システムが記載されている。ｔ−耐故障ビザンチン合意アルゴリズムとは、ｔ個のプロセスでビザンチン型の故障（故障時の振る舞いに条件を置かない故障）が発生した場合でも、正常プロセス間で共通の値を保持するためのアルゴリズムである。

特許文献１に記載の分散システムによれば、このようなｔ−耐故障ビザンチン合意アルゴリズムを用いて、当該分散システムを構成するｎ台のコンピュータのうち（ｎ−ｔ）台以上で入力データの合意を取ることにより、ｔ台までの故障・停滞ならば、スプリットブレインなくリアルタイムに動作し続けることができる。つまりスプリットブレインを防止し、かつ故障発生時におけるリアルタイム性の確保を両立させることができる。

特許文献１に記載の分散システムを構成するｎ台のコンピュータは、それぞれシステム時刻をカウントするシステム時計とは別に、仮想時刻をカウントする仮想時計を有している。仮想時計は、仮想時刻カウンタによって構成される。ｎ台のコンピュータ内では、仮想時刻を用いてアプリケーションプログラムが実行される。

そこで特許文献１に記載の分散システムでは、各コンピュータの仮想時刻（つまり仮想時刻カウンタの値）が、第１の時間間隔で第１の時間に相当する値だけインクリメントされるように、当該インクリメントのタイミングについてｔ−耐故障ビザンチン合意アルゴリズムを用いて合意を取るようにしている。また、特許文献１に記載の分散システムでは、ｎ台のコンピュータの中で最も進んだシステム時刻の合意を、ｔ−耐故障ビザンチン合意アルゴリズムを用いて第２の時間間隔（但し、第２の時間間隔＞第１の時間間隔）で取ることにより、その合意したシステム時刻に合わせるように、当該ｎ台のコンピュータの仮想時刻のインクリメント値が設定される。この設定されたインクリメント値は、最も進んだシステム時刻の合意を取る次のタイミングが到来するまで、上記第１の時間に相当する値として用いられる。これにより、ｎ台のコンピュータがアプリケーションプログラムの実行時に用いる仮想時刻を各コンピュータで一致させることができる。

特許第３６５５２６３号公報

近年の分散システムでは、当該分散システムが起動されてからの経過時間、つまり論理時間が用いられる。そこで、分散システムを構成する複数のコンピュータのそれぞれの論理時間を調整するのに、特許文献１に記載の分散システムで適用されているような仮想時刻を調整する技術（以下、従来技術と称する）を利用することが考えられる。

しかしながら、従来技術では、たとえ分散システムを構成するコンピュータ間で仮想時刻をインクリメントするタイミングの合意が取れたとしても、その合意を取るのに多大な時間を要した場合には、システム時刻に対して仮想時刻が大きくずれてしまう可能性がある。このため、論理時間を調整するのに従来技術を利用しても、合意処理に多大な時間を要した場合には、論理時間が実際の経過時間から大きくずれてしまう可能性がある。この問題について以下に詳細に説明する。

特許文献１に記載されているような、ｔ−耐故障ビザンチン合意アルゴリズムを適用する分散システムでは、当該分散システムを構成するｎ台のコンピュータのうちｔ台までの故障・停滞ならば、上述のようにスプリットブレインなくリアルタイムに動作し続けることができる。このことは逆に、（ｔ＋１）台以上のコンピュータで例えば停滞が発生すると、合意処理が進まなくなるため、リアルタイム性が確保されなくなることを意味する。

ここで、（ｔ＋１）台のコンピュータで停滞が発生し、その後（ｔ＋１）台のうちの１台が停滞から復帰したものとする。すると、（ｎ−ｔ）台のコンピュータで合意処理が行われるようになる。

しかし、（ｎ−ｔ）台のコンピュータで論理時間をインクリメントするタイミングの合意が取れたとしても、従来技術を利用して、その時点において設定されているインクリメント値を用いて論理時間をインクリメントしたのでは、論理時間が分散システムおける実際の経過時間（いわゆるシステム時間）から大きくずれてしまう可能性がある。近年の分散システムでは、フェイルオーバ時間やモニタなどのタイムアウト時間は、論理時間を用いて計測しているため、論理時間が遅延すると、フェイルオーバ時間やタイムアウト時間も遅延するという問題がある。

本発明は上記事情を考慮してなされたものでその目的は、論理時間のインクリメント値を、当該論理時間をインクリメントするタイミングについて合意が取れた時間間隔を合意によって決定し、その決定された時間間隔に合わせて論理時間を調整することにより、論理時間とシステム時間とを同期させることができる分散システムおよび論理時間調整方法を提供することにある。

本発明の１つの観点によれば、ネットワークに接続されたｎ台のコンピュータのうちのｎ＞ｔ＞０を満たす整数ｔで規定される（ｎ−ｔ）台以上のコンピュータの整列マルチキャスト手段で相互にパケットを送受信してｔ−耐故障ビザンチン合意アルゴリズムを用いて合意を取ることにより分散処理を行う分散システムが提供される。この分散システムにおいて、前記ｎ台のコンピュータの各々は、第１の時間間隔で実行される合意処理によって更新される論理時間の情報を記憶するための論理時間記憶手段と、前記論理時間の情報が前回更新されたシステム時刻としての第１の時刻および前々回更新されたシステム時刻としての第２の時刻の情報を記憶するための更新時刻記憶手段と、前記更新時刻記憶手段に記憶されている情報の示す前記第１の時刻と前記第２の時刻との時間間隔から、前記論理時間の情報を更新するのに用いられるインクリメント値の候補を計算する論理時間管理手段であって、インクリメント値の候補に基づきｔ−耐故障ビザンチン合意アルゴリズムを用いてインクリメント値を決定し、決定したインクリメント値で前記論理時間の情報を更新する論理時間管理手段とを具備する。

本発明によれば、ｎ台のコンピュータの各々は、論理時間を更新する更新時刻について前回の更新時刻を示すシステム時刻としての第１の時刻と前々回の更新時刻を示すシステム時刻としての第２の時刻の情報を更新時刻記憶手段に記憶しておき、論理時間のインクリメント値を、前回の更新時刻と前々回の更新時刻との時間間隔から、ｔ−耐故障ビザンチン合意アルゴリズムを用いて合意によって決定するようにしているので、その決定された時間間隔に合わせて論理時間を調整することにより、論理時間とシステム時間とを同期させることができる。

本発明の一実施形態に係る分散システムの構成を示すブロック図。 図１に示されるコンピュータの構成を示すブロック図。 入力パケットデータのデータ構造例を示す図。 整列マルチキャストプロトコルデータのレイアウトを示す図。 同実施形態で適用される論理時間の調整方法の手順を示すフローチャート。 分散システム内のコンピュータの停滞により合意が遅延した場合の各コンピュータにおける合意時間間隔の一例を示す図。 分散システム内のコンピュータの停滞により合意が遅延した場合の、各コンピュータにおけるシステム時間と論理時間との関係の一例を簡略化して示す図。

以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係る分散システムの構成を示すブロック図である。図１において、分散システム１０は、ｔ−耐故障ビザンチン合意アルゴリズム（ｔ＞０）による多重化を保証するのに必要な台数以上のコンピュータ、例えば４（ｎ＝４）台のコンピュータ１００-1（＃１）〜１００-4（＃４）から構成されているものとする。また本実施形態では、ｔは１であるものとする。

コンピュータ１００-1〜１００-4は、ネットワークＡを介してクライアント装置２００と接続されている。コンピュータ１００-1〜１００-4は、クライアント装置２００以外のクライアント装置（図示せず）ともネットワークＡを介して接続されているものとする。本実施形態においてネットワークＡはパブリックネットワーク（外部ネットワーク）である。コンピュータ１００-1〜１００-4間は、ネットワークＢを介して接続されている。本実施形態においてネットワークＢはプライベートネットワーク（内部ネットワーク）である。

コンピュータ１００-1〜１００-4は、前記特許文献１に記載された分散システムにおけるコンピュータと同様に、ネットワークＡを介して合意に必要な情報を送受信し、合意の判定を行っている。ｔ−耐故障ビザンチン合意アルゴリズムでは、ｔ台までの故障停止が許容されるものとし、（ｎ−ｔ）台以上のコンピュータで合意が得られた時点で、合意情報を確定する。そのため、故障や停滞などにより合意に間に合わなかったコンピュータが存在しても、この条件を満たした時点で先に進むため、タイムアウトによる合意の遅延が発生せず、リアルタイム性が確保される。ただし、（ｔ＋１）台以上のコンピュータが一時的に停滞したり、ネットワークの負荷により合意情報の授受に時間がかかったりした場合は、合意情報を確定するのに時間がかかるため、合意処理が遅延することになる。

コンピュータ１００-1〜１００-4は、それぞれ同一のアプリケーションプログラム３（図２参照）を有している。コンピュータ１００-1〜１００-4は、同一の初期状態から始まる。その後、クライアント装置２００から分散システムに入力されるデータは、必ず整列マルチキャストを通して、コンピュータ１００-1〜１００-4に同一順序で配送される。これにより、コンピュータ１００-1〜１００-4においてそれぞれのアプリケーションプログラム３が実行される。

コンピュータ１００-1〜１００-4がそれぞれ有するアプリケーションプログラム３への入力データ列は、整列マルチキャストにより同一順序となっている。このため、前記特許文献１に記載されているような整列マルチキャストを用いた決定性のプログラムの特徴により、コンピュータ１００-1〜１００-4の状態が同一に保たれ、出力データ列もすべて同じとなる。つまり、プログラムの実行が多重化される。

図２は、図１に示されるコンピュータ１００-i（ｉ＝１，２，…４）の構成を示すブロック図である。図２において、クライアント装置２００からネットワークＡを介してコンピュータ１００-iに送信されて、当該コンピュータ１００-iの入力受付キュー部（以下、受付キューと称する）１で受け付けられたパケットは候補パケットとして、当該受付キュー１に受付順に積まれる。受付キュー１に積まれた候補パケットは、整列マルチキャスト部２（内の入力パケット確定判定部２６に含まれている合意部２６２）によってアプリケーションプログラム３または後述する論理時間管理部６に入力パケットとして配送される。なお、受付キュー１に積まれる候補パケットには、クライアント装置２００から送られる処理種別が「アプリケーション」の候補パケットの他に、論理時間管理部６から送られる処理種別が「論理時間」の候補パケットがある。

アプリケーションプログラム３は、配送された入力パケットを受けて、プログラム状態管理部４に保存されている状態に従って当該入力パケットを処理し、出力パケットを生成する。生成された出力パケットは、出力フィルタ部５で選別されてから、ネットワークＡを介してクライアント装置２００に返却される（出力）。

次に、コンピュータ１００-iの整列マルチキャスト部２の構成について説明する。整列マルチキャスト部２は、前記特許文献１に記載された整列マルチキャスト部と同様に、入力順序番号記憶部２１、入力パケットジャーナル記憶部２２、整列マルチキャストプロトコルデータ送受信部（以下、プロトコルデータ送受信部と称する）２３、ステップ番号記憶部２４、候補パケット記憶部２５、入力パケット確定判定部２６、最大確定入力順序番号記憶部２７、遅延記憶部２８およびスキップ判定部２９の周知の構成を含んでいる。

入力順序番号記憶部２１は、整列マルチキャストによってコンピュータ１００-iへ次に配送される入力パケットの順序番号（つまり整列マルチキャストにシリアルに付される最新の順序番号）を格納する。入力パケットジャーナル記憶部２２は、整列マルチキャストによってコンピュータ１００-iへの配送が確定した入力パケットの列を最近のものから一定の量だけ格納する。このため、入力パケットジャーナル記憶部２２に一定の量の入力パケットの列が格納されている状態で、最新の確定済み入力パケットを当該記憶部２２に格納する場合には、その時点で最も古い確定済み入力パケットが当該記憶部２２から削除される。

プロトコルデータ送受信部２３は、他のコンピュータのプロトコルデータ送受信部２３とネットワークＢを介して整列マルチキャストプロトコルデータを授受する。プロトコルデータ送受信部２３は、候補パケットブロードキャスト部２３０を含む。候補パケットブロードキャスト部２３０は、候補パケット（後述する候補種類の整列マルチキャストプロトコルデータ）を、他のすべてのコンピュータにブロードキャスト送信する。

本実施形態では、クライアント装置２００とコンピュータ１００-iとの間のデータの授受と、コンピュータ１００-i相互間のデータの授受とで、使用するネットワークが切り替えられる。これによりネットワーク負荷が軽減される。しかし、クライアント装置２００とコンピュータ１００-iとの間のデータの授受と、コンピュータ１００-i相互間のデータの授受とが、例えばネットワークＡを介して行われる構成であっても構わない。またネットワークＡが必ずしもパブリックネットワークである必要はない。

ステップ番号記憶部２４、候補パケット記憶部２５および入力パケット確定判定部２６は、整列マルチキャストによってコンピュータ１００-iのアプリケーションプログラム３へ次に配送される入力パケットを決定するアルゴリズムで用いられる。

ステップ番号記憶部２４は、プロトコルのステップを示すステップ番号を格納する。候補パケット記憶部２５は、そのステップにおける各コンピュータの「入力候補」となる入力パケットを計ｎ個格納する。

入力パケット確定判定部２６は、候補パケット記憶部２５の情報から入力パケットの確定の判定および次ステップの「入力候補」の決定を行う。入力パケット確定判定部２６はさらに、入力パケットをアプリケーションプログラム３および論理時間管理部６のいずれに渡すかを決定する。この決定のために、受付キュー１に積まれる候補パケットには、処理種別を示す処理種別情報が付加される。入力パケット確定判定部２６は、入力候補収集部２６１および合意部２６２を含む。

図３は受付キュー１に積まれるデータ（入力パケットデータ）のデータ構造例を示す。図３に示されるように、入力パケットデータは、処理種別および入力パケットの各フィールドを含む。入力パケットフィールドには入力パケットが格納（設定）され、処理種別フィールドには処理種別情報が格納される。

本実施形態において処理種別情報は、入力パケットフィールドに格納されている入力パケットをアプリケーションプログラム３または論理時間管理部６のいずれに渡すかを入力パケット確定判定部２６の合意部２６２が決定するための処理種別を示す。そのため、処理種別情報の示す処理種別は、（１）アプリケーションと（２）論理時間とに分けられる。処理種別が「アプリケーション」の場合、入力パケットが外部のクライアント装置２０から入力されたものであることをも示し、処理種別が「論理時間」の場合、入力パケットが分散システム１０を構成するいずれかのコンピュータの論理時間管理部６から当該いずれかのコンピュータの受付キュー１に入力されたものであることをも示す。

再び図２を参照すると、最大確定入力順序番号記憶部２７は、他のコンピュータも含め、配送が確定したことがわかっている最大の入力順序番号を格納する。遅延記憶部２８は、他の（ｎ−１）台（ｎ＝４）のコンピュータよりも遅延しているかどうかを示す（ｎ−１）個の遅延フラグ（ｎ＝４の本実施形態では、３個のフラグ）を格納する。スキップ判定部２９は、遅延記憶部２８の情報からスキップ動作の必要性を判定およびスキップ動作を実行する。

以降の説明では、入力順序番号記憶部２１に格納された入力順序番号を該当入力順序番号と呼び、ステップ番号記憶部２４に格納されたステップ番号を該当ステップ番号と呼ぶ。最大確定入力順序番号記憶部２７に格納された入力順序番号を、該当最大確定入力順序番号と呼ぶ。コンピュータ１００-iの整列マルチキャスト部２に含まれている候補パケット記憶部２５に格納されているｎ個の「入力候補」のうち、当該コンピュータ１００-i自身（自コンピュータ）に対応する「入力候補」を自候補と呼び、当該自候補以外の「入力候補」を他候補と呼ぶ。

次に、プロトコルデータ送受信部２３によって送受信される整列マルチキャストプロトコルデータについて説明する。
図４は、整列マルチキャストプロトコルデータのレイアウトを示す図である。図４に示されるように、プロトコルデータ送受信部２３によって送受信される整列マルチキャストプロトコルデータは、種類、送信者、入力順序番号、ステップ番号（整列マルチキャストステップ番号）、最大確定入力順序番号、処理種別および入力パケットの各フィールドを含む。図４に示される整列マルチキャストプロトコルデータが前記特許文献１に記載されているプロトコルデータと相違するのは、前述の処理種別フィールドが追加されている点にある。

整列マルチキャストプロトコルデータは先頭の種類フィールドによって、次の３つに使い分けられる。
（１）候補種類
入力順序番号フィールド、ステップ番号フィールド、入力パケットフィールドには、それぞれ、送信者（送信側コンピュータ）の送信時における該当入力順序番号、該当ステップ番号、自候補が格納される。

（２）確定種類
その入力順序番号（入力順序番号フィールドに格納されている入力順序番号）に対応する入力パケットが、送信者の送信時における入力パケットジャーナル記憶部２２にあることを示し、入力パケットフィールドには、その入力パケットが格納される。この場合、ステップ番号フィールドは使用されない。

（３）遅延種類
その入力順序番号に対応する入力パケットが、送信者の送信時における入力パケットジャーナル記憶部２２にないことを示す。この場合、ステップ番号フィールドおよび入力パケットフィールドは使用されない。

いずれの種類の整列マルチキャストプロトコルデータにおいても、最大確定入力順序番号フィールドには、送信者（送信側コンピュータ）からの整列マルチキャストプロトコルデータ送信時における該当最大確定入力順序番号が格納される。また、整列マルチキャストプロトコルデータの受信側コンピュータにおける該当最大確定入力順序番号は、当該受信側コンピュータで確定された入力パケットの順序番号と、当該受信側コンピュータで受信された整列マルチキャストプロトコルデータ中の最大確定入力順序番号とのうち、最も大きいものに更新される。

本実施形態では、分散システム１０のコンピュータ１００-iは、前記特許文献１に記載されたコンピュータと異なり、分散システム１０が起動してからの経過時間である論理時間を調整するための新規の構成を含む。即ちコンピュータ１００-iは、図２に示されるように、論理時間管理部６、論理時間記憶部７、更新時刻記憶部８およびシステム時計９をさらに有する。

論理時間管理部６は、論理時間をインクリメントするのに用いられるインクリメント値の候補となる値を計算し、整列マルチキャストを用いてインクリメント値を決定する。論理時間管理部６は、決定したインクリメント値に基づいて論理時間を更新する。論理時間記憶部７は、論理時間管理部６によって更新された最新の論理時間の情報を格納する。更新時刻記憶部８は、論理時間管理部６によって前回に論理時間が更新された時刻（第１の時刻）と前々回に論理時間が更新された時刻（第２の時刻）の情報を格納する。システム時計９は、分散システム１０の実時刻であるシステム時刻を計時する。

次に、本実施形態で適用される論理時間の調整方法の手順について図５のフローチャートを参照して説明する。
コンピュータ１００-iの論理時間管理部６は、ステップ番号記憶部２４に格納されている該当ステップ番号が初期値であるときは受付キュー１を監視しており、前回論理時間を更新してから第１の所定時間が経過していて（ステップ５０１のＹＥＳ）、かつ当該受付キュー１に論理時間のインクリメントを要求する候補パケット（以下、論理時間更新要求パケットと称することもある）が存在するかを判定する（ステップ５０２）。第１の所定時間は、論理時間更新のタイミングを決定するための、予め設定されている基準となる更新時間間隔である。

もし、前回論理時間を更新してから第１の所定時間が経過していて（ステップ５０１のＹＥＳ）、かつ受付キュー１に論理時間更新要求パケットが候補パケットとして存在しない場合（ステップ５０２のＮＯ）、論理時間管理部６は論理時間更新要求パケットを作成する（ステップ５０３）。作成された論理時間更新要求パケットの処理種別フィールドおよび入力パケットフィールドには、それぞれ、論理時間を示す処理種別情報およびインクリメント値の候補が設定されている。本実施形態では、論理時間を更新するのに用いられるインクリメント値の候補には、前回の合意にかかった時間、つまり前々回に論理時間が更新された時刻（以下、前々回更新時刻と称する）と前回に論理時間が更新された時刻（以下、前回更新時刻と称する）との時間間隔（以下、合意時間間隔）が用いられる。そのため論理時間管理部６は、更新時刻記憶部８から前回と前々回の更新時刻を取得し、その差をインクリメント値の候補とする。

論理時間管理部６は論理時間更新要求パケットを作成すると（ステップ５０３）、当該作成した論理時間更新要求パケットを候補パケットとして受付キュー１に投入する（ステップ５０４）。受付キュー１に投入された候補パケット（論理時間更新要求パケット）は、従来技術においてクライアント装置２００からのアプリケーションの候補パケットが受付キュー１に積まれた場合と同様に、コンピュータ１００-iの入力パケット確定判定部２６内の合意部２６２による合意処理の対象となり、例えば前記特許文献１に記載されているアルゴリズム１〜４（特許文献１の図５および６参照）を利用して次のように処理される。

入力パケット確定判定部２６の入力候補収集部２６１は、当該入力パケット確定判定部２６の合意部２６２による合意処理に際し、前記特許文献１に記載されているアルゴリズム１〜３（特許文献１の図６参照）を実行する候補一覧作成手段として機能して、合意処理の対象となる（ｎ−ｔ）個以上の候補パケットを候補パケット記憶部２５に収集するための周知の候補一覧作成処理を行う。収集すべき（ｎ−ｔ）個以上の候補パケットは、（ｎ−ｔ）個以上のコンピュータがそれぞれ次に処理する候補として選択したパケット（ここでは、論理時間更新要求パケット）である。

候補一覧作成処理において入力候補収集部２６１は、ステップ番号記憶部２４に格納されている該当ステップ番号を次に進める一方、受付キュー１に積まれている論理時間の候補パケットを自候補として候補パケット記憶部２５に格納し、かつ、この自候補が入力パケットフィールドに設定された候補種類の整列マルチキャストプロトコルデータをプロトコルデータ送受信部２３内の候補パケットブロードキャスト部２３０によりネットワークＢを介して他のすべてのコンピュータ（つまり分散システム１０を構成するコンピュータ１００-1〜１００-4のうち、コンピュータ１００-i自身を除くすべてのコンピュータ）にブロードキャスト送信させる。このとき入力候補収集部２６１は、候補パケット記憶部２５内のすべての他候補を空にする。

コンピュータ１００-iのプロトコルデータ送受信部２３内の候補パケットブロードキャスト部２３０によってブロードキャストされた候補種類の整列マルチキャストプロトコルデータは、他のコンピュータのプロトコルデータ送受信部２３で受信されて、当該他のコンピュータの入力候補収集部２６１によって収集される。つまり他のコンピュータの入力候補収集部２６１は、該当ステップ番号が初期値でないか、または受付キュー１に候補パケットがないとき、入力順序番号記憶部２１に格納されている該当入力順序番号に一致する入力順序番号（が設定された入力順序番号フィールド）を持つ候補種類の整列マルチキャストプロトコルデータであって、当該整列マルチキャストプロトコルデータのステップ番号フィールドに設定されているステップ番号が該当ステップ番号よりも大きい候補種類の整列マルチキャストプロトコルデータがプロトコルデータ送受信部２３によって受信されているならば、当該受信された整列マルチキャストプロトコルデータ内の入力パケットフィールドに設定されているパケットを自候補として候補パケット記憶部２５に格納する。また他のコンピュータの入力候補収集部２６１は、自候補とした候補パケットが入力パケットフィールドに設定された候補種類の整列マルチキャストプロトコルデータを当該他のコンピュータのプロトコルデータ送受信部２３内の候補パケットブロードキャスト部２３０によりネットワークＢを介してブロードキャストさせる。このとき上記他のコンピュータの入力候補収集部２６１は、自候補とした候補パケットを、当該候補パケットを含んでいた受信された整列マルチキャストプロトコルデータの送信者に対応する他候補として、候補パケット記憶部２５に格納する。

コンピュータ１００-iの入力候補収集部２６１は、他のコンピュータのプロトコルデータ送受信部２３内の候補パケットブロードキャスト部２３０によってブロードキャスト送信された候補種類の整列マルチキャストプロトコルデータが当該コンピュータ１００-iのプロトコルデータ送受信部２３によって受信された場合、当該受信された整列マルチキャストプロトコルデータに含まれている候補パケット（ここでは、論理時間更新要求パケット）を収集する。即ち入力候補収集部２６１は、他のコンピュータから受信された整列マルチキャストプロトコルデータ内のステップ番号フィールドに設定されているステップ番号が該当ステップ番号よりも大きくなく、かつ当該受信された整列マルチキャストプロトコルデータ内のステップ番号と該当ステップ番号とが等しいならば、当該受信された整列マルチキャストプロトコルデータ内の候補パケットを、当該受信された整列マルチキャストプロトコルデータの送信者に対応する他候補として候補パケット記憶部２５に格納する。

コンピュータ１００-iの合意部２６２は、入力候補収集部２６１による上述の候補一覧作成処理によって（ｎ−ｔ）個以上（ｎ＝４、ｔ＝１の本実施形態では３個以上）の候補パケット（空でない入力候補）が候補パケット記憶部２５に収集されると、前記特許文献１に記載されているアルゴリズム４（特許文献１の図５参照）を利用した処理（以下、合意処理と称する）を次のように実行する。まず、合意部２６２は第１の入力候補選定制御手段として機能して、収集された（ｎ−ｔ）個以上の候補パケットの中に（ｎ−ｔ）個以上の同一内容の候補パケットが存在するかを判定する。

もし、（ｎ−ｔ）個以上の同一内容の候補パケットが存在するならば、合意部２６２は、その候補パケットを次に処理する入力パケットとして確定する。つまり合意部２６２は、論理時間管理部６によって受付キュー１に投入された候補パケットについて、（ｎ−ｔ）台以上のコンピュータの整列マルチキャスト部２によって合意を取ることにより、入力パケットとして確定する。このとき合意部２６２は、最大確定入力順序番号記憶部２７に格納されている該当最大確定入力順序番号を該当入力順序番号に更新する。また合意部２６２は、確定された入力パケットが候補パケットとして受付キュー１に存在するならば、当該候補パケットを受付キュー１から削除する。

これに対し、（ｎ−ｔ）個以上の同一内容の候補パケットが存在せず、つまり（ｎ−ｔ）個以上の候補パケットの合意が取れず、したがって次に処理する入力パケットを確定できない場合、合意部２６２は第１の入力候補選定制御手段として機能する。そして合意部２６２は、収集された（ｎ−ｔ）個以上の候補パケットの中に過半数以上の同一の候補が存在するかによって、次のように自候補を決定する。

まず、収集された（ｎ−ｔ）個以上の候補パケットの中に過半数以上の同一の候補パケットが存在するならば、合意部２６２は、その過半数以上の同一の候補パケットを選択して自候補として候補パケット記憶部２５に格納し、かつ、この自候補が入力パケットフィールドに設定された候補種類の整列マルチキャストプロトコルデータをプロトコルデータ送受信部２３内の候補パケットブロードキャスト部２３０によりネットワークＢを介して他のすべてのコンピュータにブロードキャスト送信させる。このとき合意部２６２は、候補パケット記憶部２５に格納されているすべての他候補を破棄して、入力候補収集部２６１による候補パケットの収集を再実行させる。

これに対し、過半数以上の同一の候補パケットが存在しないならば、合意部２６２は第３の入力候補選定制御手段として機能する。そして合意部２６２は、候補パケット記憶部２５に格納されている入力候補の中からランダムに候補（入力パケット）を自候補として選択し、かつ、この自候補が入力パケットフィールドに設定された候補種類の整列マルチキャストプロトコルデータをプロトコルデータ送受信部２３内の候補パケットブロードキャスト部２３０によりネットワークＢを介して他のすべてのコンピュータに送信させる。このとき合意部２６２は、候補パケット記憶部２５に格納されているすべての他候補を破棄する。

合意部２６２は、該当入力順序番号における入力パケットを確定すると、つまり該当入力順序番号における入力パケットに関して合意が取られて、整列マルチキャストが確定すると、候補出力先切り替え手段として機能して次の処理を実行する。即ち合意部２６２は、確定された入力パケットに付されている処理種別情報の示す処理種別が「論理時間」であるか否（「アプリケーション」である）か、つまり確定された入力パケットが論理時間のインクリメントを要求する論理時間更新要求パケットであるかを判定する。

もし、処理種別が「論理時間」であるならば、合意部２６２は確定された入力パケットを論理時間管理部６に渡すとともに、当該入力パケットを入力パケットジャーナル記憶部２２に格納する。これに対し、処理種別が「アプリケーション」であるならば、合意部２６２は確定された入力パケットをアプリケーションプログラム３に配送するとともに、当該入力パケットを入力パケットジャーナル記憶部２２に格納する。このように入力パケットが、処理種別に応じて論理時間管理部６またはアプリケーションプログラム３に選択的に渡される点で、入力パケットがアプリケーションプログラム３に渡される特許文献１とは相違する。

論理時間管理部６は、論理時間更新要求パケットを候補パケットとして受付キュー１に投入すると（ステップ５０４）、ステップ５０５に進む。ステップ５０５において論理時間管理部６は、当該論理時間管理部６に合意部２６２から論理時間更新要求パケットが入力パケットとして配送されたかによって、当該論理時間更新要求パケットが入力パケットとして確定されたかを判定する。

論理時間管理部６はまた、前回論理時間を更新してから第１の所定時間が経過していない場合には（ステップ５０１のＮＯ）、ステップ５０２乃至５０４をスキップして、候補パケットを作成することなくステップ５０５に進む。また論理時間管理部６は、前回論理時間を更新してから第１の所定時間が経過し（ステップ５０１のＹＥＳ）、かつ論理時間更新要求パケットが受付キュー１に候補パケットとして存在する場合には（ステップ５０２のＹｅｓ）、ステップ５０３乃至５０４をスキップして、候補パケットを作成することなくステップ５０５に進む。

論理時間管理部６はステップ５０５において、論理時間更新要求パケットが入力パケットとして確定されたかを、合意部２６２から論理時間更新要求パケットが配送されたかによって判定する。論理時間管理部６は、論理時間更新要求パケットが入力パケットとして確定されたと判定した場合（ステップ５０５のＹＥＳ）、当該確定された入力パケット（論理時間更新要求パケット）に設定されているインクリメント値の候補を、合意確定がなされたインクリメント値として決定する。

このように論理時間管理部６は、インクリメント値の候補となる値を計算し、整列マルチキャストを用いてインクリメント値を決定する。論理時間管理部６は、決定したインクリメント値が第２の所定時間以上であるかを判定する（ステップ５０６）。本実施形態において第２の所定時間は、第１の所定時間と同一の時間に設定される。

もし、決定したインクリメント値が第２の所定時間未満であるならば（ステップ５０６のＮＯ）、論理時間管理部６は入力パケットを無視し、論理時間を更新することなくステップ５０１に戻る。決定したインクリメント値が第２の所定時間未満となるのは、つまり基準となる更新時間間隔（第１の所定時間）よりも短くなるのは、例えば、停滞していたコンピュータ１００-iが後述する追いかけ処理により、合意時間間隔が短くなった場合である。

本実施形態では上述のように、第２の所定時間が、第１の所定時間と同一の時間に設定される。一方、合意時間間隔は、後述するように、コンピュータ１００-iが停滞しなくても、基準となる更新時間間隔（ここでは１秒）に対して誤差が生じる。この誤差により、合意時間間隔が基準となる更新時間間隔よりも短くなる可能性がある。そこで、第２の所定時間を、例えば基準となる更新時間間隔に対する許容される誤差Δだけ、第１の所定時間よりも短い時間に設定してもよい。

次に、決定したインクリメント値が第２の所定時間以上であるものとする（ステップ５０６のＹＥＳ）。この場合、論理時間管理部６は、その時点において論理時間記憶部７に格納されている論理時間の情報を、当該論理時間が当該インクリメント値だけインクリメントされるように更新する（ステップ５０７）。つまり論理時間管理部６は、決定したインクリメント値だけ、論理時間を進める。このとき論理時間管理部６は、更新時刻記憶部８に格納されている前々回の更新時刻を示す情報を、当該更新時刻記憶部８に格納されている前回の更新時刻を示す情報で更新する（ステップ５０８）。即ち論理時間管理部６は、前回の更新時刻を前々回の更新時刻として設定する。ステップ５０８において論理時間管理部６は、更新時刻記憶部８に格納されている前回の更新時刻を示す情報を、システム時計９によって示される現在の時刻で更新する。即ち論理時間管理部６は、現在の時刻を前回の時刻として設定する。

次に論理時間管理部６は、確定された入力パケットが候補パケットとして受付キュー１に存在するかを判定する（ステップ５０９）。確定された入力パケットが候補パケットとして受付キュー１に存在するのは、他のコンピュータの論理時間管理部６によって作成された候補パケットが入力パケットとして確定された場合である。論理時間管理部６は、確定された入力パケットが候補パケットとして受付キュー１に存在する場合（ステップ５０９のＹＥＳ）、当該受付キュー１に存在する候補パケットを削除する（ステップ５１０）。

これにより、他のコンピュータの論理時間管理部６によって作成された候補パケットが入力パケットとして確定された場合、コンピュータ１００-iでは、当該コンピュータ１００-iの論理時間管理部６によって作成された候補パケットによる合意処理は行われなくなる。つまりコンピュータ１００-iでは、他のコンピュータの論理時間管理部６によって作成されて、一番最初に合意された候補パケットが、入力パケットとして用いられる。

インクリメント値の候補、即ち合意時間間隔の候補値は、コンピュータ１００-1〜１００-5の各々で、システム時計９に基づいてそのコンピュータでの論理時間の更新時刻から計算される。このため、ネットワーク遅延などにより合意処理自体に時間を要しても、論理時間とシステム時間との差は数ミリ秒のオーダーの範囲に収まる。この誤差は、（ｔ＋１）台以上のコンピュータの停滞が発生したために発生する合意処理の遅延時間（一般に数秒〜数分）に比べて極めて小さい。

コンピュータ１００-iの論理時間管理部６は、図５のフローチャートに従う上述の処理を繰り返し行うことにより、論理時間とシステム時間との差をできるだけ少なくし、フェイルオーバ時間やタイムアウト時間の精度を高くすることができる。

なお、分散システム１０の起動後における各コンピュータ１００-iでの最初の合意処理では、前回の合意時間間隔は得られない。このため、図５のフローチャートでは省略されているが本実施形態では、前回の合意時間間隔が得られるまでは、前記第１の所定時間がインクリメント値として用いられる。また本実施形態では、前回の合意時間間隔がインクリメント値として用いられるため、実際の時間とは１回分ずれが生じる。しかし、合意時間間隔が短い場合はずれも小さいため、問題にはならない。

ところで、各コンピュータ１００-iの整列マルチキャスト部２は、前記特許文献１に記載されているアルゴリズム５および６（特許文献１の図７および８参照）を用いて実現される追いかけ機能を有している。追いかけ機能とは、短い時間停滞していたコンピュータが停滞（つまりｔ−耐故障ビザンチン合意アルゴリズムを用いた合意処理に参加できない状態）から復帰した場合に、多重化実行の短い遅延を解消するための機能である。

追いかけ機能に基づく追いかけ処理について、短い時間停滞していたコンピュータがコンピュータ１００-4である場合を例に以下に詳述する。ここで短い時間とは、停滞していたコンピュータの復帰時の該当入力番号に対応する入力パケットが他のコンピュータの入力パケットジャーナル記憶部２２から削除されずに当該記憶部２２に残されている程度の時間を指す。

今、コンピュータ１００-4が短い停滞から復帰して、候補種類の整列マルチキャストプロトコルデータを当該コンピュータ１００-4のプロトコルデータ送受信部２３内の候補パケットブロードキャスト部２３０によりブロードキャストしたものとする。

コンピュータ１００-4以外のコンピュータ１００-j（ｊ＝１，２，３）の整列マルチキャスト部２内の合意部２６２は、該当入力順序番号より小さい入力順序番号を持つ候補種類の整列マルチキャストプロトコルデータがプロトコルデータ送受信部２３によって受信された場合に、その入力順序番号に対応する入力パケットが入力パケットジャーナル記憶部２２に存在するかを判定する。このような候補種類の整列マルチキャストプロトコルデータの送信者は、短い停滞から復帰したコンピュータである可能性が高い。

もし、短い多重化実行の遅延のために、該当入力順序番号より小さい入力順序番号に対応する確定済みの入力パケットが入力パケットジャーナル記憶部２２に存在するならば、コンピュータ１００-jの合意部２６２は、その入力パケットが入力パケットフィールドに設定された確定種類の整列マルチキャストプロトコルデータをプロトコルデータ送受信部２３により上記候補種類の整列マルチキャストプロトコルデータの送信者であるコンピュータ１００-jに返送させる。

コンピュータ１００-4の合意部２６２は、該当入力順序番号に一致する入力順序番号を持つ確定種類の整列マルチキャストプロトコルデータが返送された場合、その確定種類の整列マルチキャストプロトコルデータ内の入力パケットを入力パケットとして確定する。つまり候補種類の整列マルチキャストプロトコルデータの送信者の合意部２６２は、短い停滞の期間に他の（ｎ−ｔ）台以上のコンピュータ間で合意が取られた入力パケットを取得して、入力パケットとして確定する。もし、確定した入力パケットが受付キュー１に存在するならば、合意部２６２は当該入力パケットを受付キュー１から削除すると共に、当該入力パケットを処理種別に応じてアプリケーションプログラム３または論理時間管理部６に配送する。また合意部２６２は、次工程へ移行すべく、入力順序番号記憶部２１に格納されている該当入力順序番号を次に進め（１インクリメントし）、ステップ番号記憶部２４に格納されている該当ステップ番号を初期化する。また合意部２６２は、候補パケット記憶部２５に格納されているすべての候補を破棄し、遅延記憶部２８に格納されている（ｎ−１）個の遅延フラグをすべてリセットする。

論理時間管理部６は、合意部２６２から確定した入力パケットが配送された場合（ステップ５０５のＹＥＳ）、当該確定した入力パケットを取得する。論理時間管理部６は、取得した確定した入力パケットに設定されているインクリメント値が第２の所定時間以上であるならば（ステップ５０６のＹＥＳ）、論理時間を当該インクリメント値だけ進める（ステップ５０７）。
一方、アプリケーションプログラム３は合意部２６２から確定した入力パケットが配送された場合、当該確定した入力パケットを処理する。

以上の追いかけ処理が繰り返されることで、コンピュータ１００-4は、多重化実行の遅延を解消し、論理時間を含めて、他のコンピュータ１００-1〜１００-3における最終入力順序番号の状態に追いつくことができる。つまりコンピュータ１００-4は、ｔ−耐故障ビザンチン合意アルゴリズムを用いた合意処理に参加できない状態から復帰した場合に、その間に他のコンピュータ１００-1〜１００-3で合意が確定されたパケットを追いかけ処理によって取得することにより、インクリメント値を含めて、他のコンピュータ１００-1〜１００-3に同期した状態に追いつくことができる。

次に、上述の合意時間間隔をインクリメント値の候補とする候補パケットを用いた合意処理について、コンピュータ１００-1〜１００-4のうちの（ｔ＋１）台、つまり２台が停滞する期間が発生した場合を例に図６および図７を参照して説明する。なお、図６は、このような期間が発生した場合の、各コンピュータ１００-i（ｉ＝１，２，３，４）における合意時間間隔の一例を示す。また図７は、このような場合の各コンピュータ１００-iにおける、システム時間と論理時間との関係の一例を簡略化して示す。

まず、図７の例のように、分散システム１０の起動時ｔ₀から合意時間間隔に関して、基準となる更新時間間隔である第１の所定時間間隔、例えば１秒間隔で合意処理が行われて、合意が確定したものとする（１回目の合意確定）。ここでは、図６の例のように、コンピュータ１００-1〜１００-4のすべてで合意処理が行われて、合意が確定したものとする。そして１回目の合意確定の後、図６に示すようにコンピュータ１００-4が停滞したものとする。

ｔが１である本実施形態では、コンピュータ１００-4が停滞しても、残りのコンピュータ１００-1〜１００-3でｔ−耐故障ビザンチン合意アルゴリズムを用いた合意処理を行って合意を確定することができる。これによりコンピュータ１００-1〜１００-3で、図７に示すように、１回目の合意確定時から第１の所定時間間隔である１秒後に２回目の合意確定がなされる。この２回目の合意確定の後、図６に示すようにコンピュータ１００-3が新たに停滞したものとする。このときコンピュータ１００-4は依然として停滞しているものとする。

このように、コンピュータ１００-3および１００-4の２台が停滞している場合、ｔ＝１の本実施形態では、残りのコンピュータ１００-1および１００-2だけでｔ−耐故障ビザンチン合意アルゴリズムを用いた合意処理を行うことができない。このため、合意処理は遅延する。

その後、図６に示すようにコンピュータ１００-3が停滞から復帰したものとする。これによりコンピュータ１００-1〜１００-3の３台で、合意時間間隔に関して再びｔ−耐故障ビザンチン合意アルゴリズムを用いた合意処理が行われる。その結果、図７に示すように、２回目の合意確定時よりも３秒後に３回目の合意確定がなされたものとする。ここでは、説明の簡略化のためにシステム時刻の誤差を考慮せずに、前回の合意時間間隔、即ち２回目（前回）の合意確定時の論理時間の更新時刻と１回目（前々回）の合意確定時の論理時間の更新時刻との時間間隔が、第１の所定時間に一致する１秒であるものとする。この場合、コンピュータ１００-1〜１００-3の論理時間は、図７に示すように、２回目の合意確定時の２秒から３秒に更新される。

前述したように更新時刻は、各コンピュータ１００-iのシステム時計９の示すシステム時刻に基づいて決定される。このため各コンピュータ１００-iが停滞しなくても、合意時間間隔は１秒に対して誤差が生じる。この誤差はコンピュータ１００-i毎に異なるため、候補パケットに設定されるインクリメント値の候補に用いられる合意時間間隔はコンピュータ１００-i毎に異なる。そして一番最初に合意された候補パケットに設定されているインクリメント値の候補が、合意に参加した各コンピュータ１００-iの論理時間を更新するためのインクリメント値として用いられる。

３回目の合意確定時の論理時間は、２回目の合意確定時以降のコンピュータ１００-3および１００-4の停滞による遅延が反映されないため、図７に示されるように、システム時間から、ほぼ「実際の遅延時間−第１の所定時間（１秒）」だけずれる。しかし、このずれは、以下に述べるように、次の４回目の合意確定時に解消される。

ここで、３回目の合意確定の後、図７に示すようにコンピュータ１００-4が停滞から復帰したものとする。するとコンピュータ１００-4は、上述の追いかけ処理により、当該コンピュータ１００-4が停滞している間に他のコンピュータ１００-1〜１００-3によって合意が取られた、確定済みの入力パケットの列を入力順序番号順に取得する。取得した確定済みの入力パケットの列には、インクリメント値に関する確定済みの入力パケット（ここでは２つの入力パケット）が含まれている。

コンピュータ１００-4の論理時間管理部６は、インクリメント値に関する確定済みの入力パケットを取得する毎に、当該確定済みの入力パケットに設定されているインクリメント値に基づいて、論理時間を当該インクリメント値だけ進める（ステップ５０６，５０７）。

このように本実施形態においては、コンピュータ１００-4が短い時間停滞していた間に他のコンピュータ１００-1〜１００-3で行われた、インクリメント値（つまり合意時間間隔）に関する２回目の合意確定と３回目の合意確定とを、図６に示すように、当該コンピュータ１００-4が停滞から復帰した際に追いかけ処理を利用して実行している。これによりコンピュータ１００-4の論理時間を他のコンピュータ１００-1〜１００-3の論理時間に同期させることができる。

またコンピュータ１００-4の論理時間管理部６は論理時間を更新する毎に、前回の更新時刻を前々回の更新時刻として設定すると共に、システム時計９の示す現在の時刻を前回の更新時刻として設定する（ステップ５０８）。追いかけ処理を用いて行われる、合意時間間隔に関する合意の確定（より詳細には、合意の確定に基づく論理時間の更新）は、図７に示されるように、通常状態における合意時間間隔に関する合意の確定よりも短い時間間隔で行われる。

さて、コンピュータ１００-4が、論理時間を含めて、他のコンピュータ１００-1〜１００-3における最終入力順序番号の状態に追いつくと、再びコンピュータ１００-1〜１００-4で、合意時間間隔に関する合意の確定が行われる。この合意確定のための合意処理に用いられる候補パケットに設定されているインクリメント値の候補には、３回目（前回）の合意確定時の論理時間の更新時刻と２回目（前々回）の合意確定時の論理時間の更新時刻との時間間隔が用いられる。もし、一番最初に合意された候補パケット（論理時間更新要求パケット）が、コンピュータ１００-1〜１００-3のいずれかの論理時間管理部６によって作成されたものであるならば、インクリメント値の候補には、誤差を考慮しないものとすると３秒が用いられる。これに対し、一番最初に合意された候補パケットが、コンピュータ１００-4の論理時間管理部６によって作成されたものであるならば、インクリメント値の候補には、上述の追いかけ処理に起因して、通常状態における合意時間間隔に関する合意の確定よりも十分短い時間間隔、つまり第２の所定時間よりも短い時間間隔が用いられる。

このため、一番最初に合意された候補パケットが、コンピュータ１００-4の論理時間管理部６によって作成されたものである場合、当該候補パケットに設定されているインクリメント値の候補は第２の所定時間未満となる（ステップ５０６のＮＯ）。この場合、前述のように論理時間は更新されず、ステップ５０６からステップ５０１に戻る。

その後、コンピュータ１００-1〜１００-3のいずれかの論理時間管理部６によって作成された候補パケットに基づいて、コンピュータ１００-1〜１００-4の４台で、合意時間間隔に関して合意処理が行われ、例えば３回目の合意確定時よりも１秒後に、入力パケットとして、図６に示すように４回目の合意確定がなされたものとする（ステップ５０５のＹＥＳ）。この場合、コンピュータ１００-1〜１００-4の論理時間管理部６は、確定された入力パケットに設定されているインクリメント値の候補である３秒を、確定されたインクリメント値として決定し、当該インクリメント値に基づいて、自身が管理する論理時間を更新する（ステップ５０６，５０７）。これによりコンピュータ１００-1〜１００-4の論理時間は、図７に示すように、３回目の合意確定時の３秒から６秒に更新され、システム時間に同期する。

ところで、複数のコンピュータで時刻合わせをする仕組みとして、ネットワークタイムプロトコル（Network Time Protocol: ＮＴＰ）のように通信時間を考慮して調整する方法などが知られている。このような方法と異なり、本実施形態では、ｔ−耐故障ビザンチン合意アルゴリズムを用いてインクリメント値を決定するため、分散システム内のどのコンピュータが故障、あるいは停滞しても正確な時間に調整することが可能になる。また本実施形態では、インクリメント値の候補として、各コンピュータで前回と前々回に論理時間が更新されたシステム時刻から計算される合意時間間隔を用いているため、各コンピュータ間でシステム時刻が異なっていても問題とならない。

一般に、各コンピュータで合意が開始されてから合意が確定するまでに数ミリ秒程度時間がかかり、その時間はコンピュータ毎に異なる。しかし、この数ミリ秒程度の時間は、停滞により遅延する時間（数秒、あるいはそれ以上）と比較すると十分無視できる値である。このため本実施形態では説明の簡略化のために、各コンピュータでの合意処理に要する時間はゼロとし、ほぼ同時に合意が確定するものとしている。

なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。

１…入力受付キュー部（受付キュー）、２…整列マルチキャスト部、３…アプリケーションプログラム、４…プログラム状態管理部、５…出力フィルタ部、６…論理時間管理部、７…論理時間記憶部、８…更新時刻記憶部、９…システム時計、１０…分散システム、２１…入力順序番号記憶部、２２…入力パケットジャーナル記憶部、２３…プロトコルデータ送受信部、２４…ステップ番号記憶部、２５…候補パケット記憶部、２６…入力パケット確定判定部、２７…最大確定入力順序番号記憶部、２８…遅延記憶部、２９…スキップ判定部、１００-1〜１００-4，１００-i…コンピュータ、２６１…入力候補収集部、２６２…合意部、Ａ，Ｂ…ネットワーク。

Claims (5)

1. ネットワークに接続されたｎ台のコンピュータのうちのｎ＞ｔ＞０を満たす整数ｔで規定される（ｎ−ｔ）台以上のコンピュータの整列マルチキャスト手段で相互にパケットを送受信してｔ−耐故障ビザンチン合意アルゴリズムを用いて合意を取ることにより分散処理を行う分散システムにおいて、
   前記ｎ台のコンピュータの各々は、
   第１の時間間隔で実行される合意処理によって更新される論理時間の情報を記憶するための論理時間記憶手段と、
   前記論理時間の情報が前回更新されたシステム時刻としての第１の時刻および前々回更新されたシステム時刻としての第２の時刻の情報を記憶するための更新時刻記憶手段と、
   前記更新時刻記憶手段に記憶されている情報の示す前記第１の時刻と前記第２の時刻との時間間隔から、前記論理時間の情報を更新するのに用いられるインクリメント値の候補を計算する論理時間管理手段であって、インクリメント値の候補に基づきｔ−耐故障ビザンチン合意アルゴリズムを用いてインクリメント値を決定し、決定したインクリメント値で前記論理時間の情報を更新する論理時間管理手段と
   を具備することを特徴とする分散システム。
2. 前記ｎ台のコンピュータの各々はシステム時計を備えており、
   前記ｎ台のコンピュータの前記論理時間管理手段は、前記論理時間の情報を更新した場合、前記システム時計の示すシステム時刻および前記第１の時刻に基づいて、それぞれ、前記第１の時刻および前記第２の時刻の情報を更新する
   ことを特徴とする請求項１記載の分散システム。
3. 第２の時間間隔を前記第１の時間間隔以下の時間間隔であるとすると、前記決定されるインクリメント値が前記第２の時間間隔以上となる時間間隔であることを特徴とする請求項２記載の分散システム。
4. 前記ｎ台のコンピュータの前記整列マルチキャスト手段は、対応するコンピュータが、前記ｔ−耐故障ビザンチン合意アルゴリズムを用いた合意処理に参加できない状態から復帰した場合に、その間に前記ｎ台のコンピュータのうちの他の（ｎ−ｔ）台以上のコンピュータで合意が確定したパケットを取得することにより、前記インクリメント値を含めて、前記他の（ｎ−ｔ）台以上のコンピュータに同期した状態に追いつくための追いかけ手段を含むことを特徴とする請求項３記載の分散システム。
5. ネットワークに接続されたｎ台のコンピュータのうちのｎ＞ｔ＞０を満たす整数ｔで規定される（ｎ−ｔ）台以上のコンピュータの整列マルチキャスト手段で相互にパケットを送受信してｔ−耐故障ビザンチン合意アルゴリズムを用いて合意を取ることにより分散処理を行う分散システムであって、前記ｎ台のコンピュータの各々が、第１の時間間隔で実行される合意処理によって更新される論理時間の情報を記憶するための論理時間記憶手段と、前記論理時間の情報が前回更新されたシステム時刻としての第１の時刻および前々回更新されたシステム時刻としての第２の時刻の情報を記憶するための更新時刻記憶手段とを有する分散システムに適用される論理時間調整方法において、
   前記ｎ台のコンピュータのうちの（ｎ−ｔ）台以上のコンピュータが、前記更新時刻記憶手段に記憶されている情報の示す前記第１の時刻と前記第２の時刻との時間間隔から、前記論理時間の情報を更新するのに用いられるインクリメント値の候補を計算するステップと、
   前記（ｎ−ｔ）台以上のコンピュータが、インクリメント値の候補に基づきｔ−耐故障ビザンチン合意アルゴリズムを用いてインクリメント値を決定するステップと、
   前記（ｎ−ｔ）台以上のコンピュータが、前記決定されたインクリメント値で前記論理時間の情報を更新するステップと
   を具備することを特徴とする論理時間調整方法。

Images