JP2005275539A - 通信システム、および同システムにおけるマスターピアの異常復帰方法、ならびにコンピュータプログラム - Google Patents

Abstract

【課題】 マスターが異常終了した場合にも他のピアをマスターとしてイベント駆動型Ｐ２Ｐリアルタイムコミュニケーションを存続させる。
【解決手段】 共有空間のマスターピア４から配布された過去の信頼できるイベントを元に新しい共有空間のマスターピア１を一意に選択する仕組みを構築する。再配布されたイベントにより作成されるマスター候補リスト（マスター候補リスト生成保持部１６）により、全てのピア２、３が代替マスターピア候補を一意に決定することができる。また、マスターピア４以外のピア２、３からのマスター交代通知の正当性を確認することができ、更に、イベント再配布途中でのマスターピア４の異常終了に対しても、マスター交代完了後、最終イベントを再配布することで各ピア２、３の状態を同一に保つ。
【選択図】 図１

Description

本発明は、マスターピアを含む複数のピアがネットワーク上に仮想的な共有空間を形成し、その中のアプリケーションを共有する、通信システム、および同システムにおけるマスターピアの異常復帰方法、ならびにコンピュータプログラムに関する。

イベント駆動型Ｐ２Ｐ（ビア・ツー・ピア）リアルタイムコミュニケーションシステムは、複数のピア（ノード端末）がネットワーク上に仮想的な共有空間を形成し、その中でアプリケーションを共有するシステムである。

ところで、ブロードバンド時代の新しいネットワークココミュニケーション実現を目指し、各種アプリケーションの開発基盤となるフレームワーク作りを進める組織であるＳＯＢＡプロジェクト（Session Oriented Broadband Applications）がある（例えば、非特許文献１参照）。
Ｓｏｂａフレームワークでは、例えば、図６に示されるように、ネットワーク上の仮想的な共有空間を構築し、その共有空間上で様々なアプリケーションを共有することでコミュニケーションをはかる。言い替えれば共有空間とは複数のユーザー間でアプリケーションを共有する場であるといえる。
共有空間には複数のユーザーが随時出入りでき、また随時複数のアプリケーションを共有／共有解除できる。アプリケーションの共有機能によって、共有空間に参加している各ノード上に同じアプリケーション画面を表示することができる。また、ある参加者のアプリケーションに対する操作を、他の全参加者の画面上で確認することが可能である。

例えばホワイトボードアプリケーションで誰かが線を引くと、行為者を含めた全てのノード上のホワイトボードアプリケーション画面に線が描かれる。
アプリケーションの共有は、アプリケーションの内部状態を共有空間に参加している全てのノードで同一に保つことによって実現される。Ｓｏｂａフレームワークではイベントによる同期によってこれを実現する。ホワイトボードに線を引く例では、「Ａ点からＢ点まで色Ｃ，太さＤの線を引く」というイベントが共有空間に参加している各ノードに送られる。各ノードではそのイベントを解釈し自らが保持しているアプリケーション状態を更新し、結果として画面上に線が描かれる。イベント適用によるアプリケーションの状態は、前の状態とイベントの中身によって一意に決められる。したがって、状態を同一に保つためにはイベントの順序を保証する必要がある。

Ｓｏｂａフレームワークは、例えば、図７に示すように、マスターと呼ぶサーバーのような役割を持つノード（マスターピア７１）を設けることでイベントの順序を保証する。マスターピア７１は、アプリケーションに対するユーザー（ピア７２）からの操作要求を受け付け、他のノード（ピア７３）にイベントとして再配布する。マスターピア７１はアプリケーションごとに異なるノードを設定できる。共有空間を成立させるためには、アプリケーション状態の同期だけではなく、共有空間の状態の同期も必要になる。
共有空間の状態の同一性保持は、アプリケーションと同じようにイベントによって行われる。共有空間の状態には、参加者のリストと共有アプリケーションのリストが含まれる。共有空間の状態に関するイベントにはユーザーの参加／脱退、アプリケーションの共有／共有解除、マスターの変更などがある。各ノードにおける共有空間状態の同一性を保証するために、共有空間にもアプリケーションと同様にマスターとなるノードが存在する。

従来におけるイベント駆動型Ｐ２Ｐリアルタイムコミュニケーションシステムでは、共有空間マスター以外のピアの正常／異常終了、および共有空間マスターの正常終了については、各ピアが正しく共有空間の状態変化として知ることができた。図８にピアの異常検出処理のための動作概念が示されている。
アプリケーションマスターの脱退については、アプリケーションのマスターが共有空間を脱退する場合、共有空間のマスターに対してセッション脱退の要求を行う。これに対して共有空間のマスターはアプリケーションのマスターを他のノードに変更し、マスター変更を他のノードに通知した後に脱退処理を行う。

また、共有空間マスター以外の異常終了については、共有空間のマスターでないノードの異常終了を検出したノード（ピアＡ（８２））は、共有空間のマスター（マスターピア８１）に対し、その旨を通知する。共有空間のマスターは、そのノードが終了したことを確認すると、当該ユーザーの脱退処理を行う。異常終了のノードがアプリケーションのマスターであったときは、通常のアプリケーションマスターの脱退と同様に事前にマスターを他のノードに変更する。共有空間のマスターでないノード（アプリケーションのマスターや他の一般のノード）では正常終了と異常終了は終了の検出方法が異なる（申告によるか、回線断などの検知によるか）だけで、その後の処理方法は同じである。
共有空間マスターの脱退については、共有空間のマスターは共有空間から脱退する際、他のノードに共有空間のマスターを委譲する。共有空間マスター変更についての他ノードへの通知は旧マスターによって行われる。旧マスターは、他ノードへマスターを委譲したあと、他のノードと同様の脱退処理を行う。

Ｓｏｂａフレームワークでは個々の共有空間参加者に役割を提供することができる。さらに役割に応じた権限を設定することができる。
例えば、共有空間「教室」の参加者には「先生」の役割を設定することができる。そして、「先生」にはアプリケーションの共有ができるが「生徒」にはできないというように役割に権限を設定することができる。権限の一貫性を保つために、共有空間あるいはアプリケーションのマスターを交換する際、新マスターは旧マスターと同じ役割を持った参加者（が利用するノード）である必要がある。

ところで、上記した共有空間の管理の仕方については従来から多数の出願がなされている。例えば、マスターの端末の情報を他の端末に複製しておき、障害発生を検知したら権限を委譲して復帰する技術（例えば、特許文献１、２参照）、共有空間管理を行う端末を順次Ｐ２Ｐネットワークで回転させながら、端末の参加、脱退の情報（メンバーリスト）をイベント発生順に従い一意に管理する技術（例えば、特許文献２参照）などである。
Ｓｏｂａプロジェクト［２００４年３月１日閲覧］インターネットＵＲＬ＜ｈｔｔｐ：／／ｓｏｂａ−ｐｒｏｊｅｃｔ．ｏｒｇ／＞ 特開２００４−５１９９号公報 特開２００１−３４６１８１号公報 特開２００１−３３１４６９号公報

上記したように従来のイベント駆動型Ｐ２Ｐリアルタイムコミュニケーションシステムでは、マスターの脱退を含む共有空間に関する全てのイベントは、共有空間のマスターによって、再配布される。
Ｓｏｂａフレームワークでは、マスターをセキュリティコントロールのためのノードとしても使用しているため、マスターから受け取るイベントのみを信頼できるイベントとして処理している。従来のＳｏｂａフレームワークでは、共有空間のマスターが異常終了すると、信頼できるイベントを配布できるノードが共有空間からなくなるため、共有空間を維持できなかった。また、上記した特許文献１、２、３によっても異常発生をトリガとしたマスター復帰後のイベントの順序性を保証する記載がない。

本発明は上記事情に鑑みてなされたものであり、マスターピアが異常終了したときに他のピアをマスターピアとしてイベント駆動型Ｐ２Ｐリアルタイムコミュニケーションを存続させことのできる、通信システム、および同システムにおけるマスターピアの異常復帰方法、ならびにコンピュータプログラムを提供することを目的とする。
また、その際に、共有空間のマスターから配布された過去の信頼できるイベントを元に新しい共有空間のマスターを一意に選択する仕組みを構築することにより、全てのピアが代替マスター候補を一意に決定することができ、マスター以外のピアからのマスター交代通知の正当性を確認できる、通信システム、および同システムにおけるマスターピアの異常復帰方法、ならびにコンピュータプログラムを提供することも目的とする。
更に、イベント再配布途中でのマスターの異常終了に対しても、マスター交代完了後、最終イベントを再配布することで各ピアの状態を同一に保つことのできる、通信システム、および同システムにおけるマスターピアの異常復帰方法、ならびにコンピュータプログラムを提供することも目的とする。

上記した課題を解決するために本発明は、マスターピアを含む複数のピアがネットワーク上に仮想的な共有空間を形成し、その中のアプリケーションを共有する通信システムであって、前記それぞれのピアは、少なくとも、あるピアからイベントを受付、他のピアにそのイベントを再配布するマスター機能実行部と、前記イベントの受付順で一意に決まるマスター候補リストを生成して保持するマスター候補リスト生成保持部とを備え、前記マスターピアの通信異常を検出したとき、前記マスター候補リストから一つのマスター候補ピアを選択し、当該マスター候補ピアに対して前記マスターピアの通信異常を通知し、前記マスター候補ピアは、前記マスターピアの通信異常を確認して前記マスター候補リストを参照し、自身より上位のピアが存在しないことを確認のうえ自身が持つ前記マスター機能実行部を起動することを特徴とする。

また、本発明において、前記それぞれのピアは、前記マスター候補リストの最上位に位置するピアが既に前記共有空間に存在しない場合、次に位置するピアをマスター候補として選択して前記マスターピアの通信異常を通知する処理を、前記共有空間に存在するマスター候補ピアが発見されるまで繰り返すことを特徴とする。

また、本発明において、前記マスター機能実行部を起動した前記マスター候補ピアは、マスター交代の事実を他の全てのピアに通知し、前記他の全てのピアによる承認の処理を待って最後のイベントを再配布することを特徴とする。

また、本発明において、前記マスター候補リスト生成保持部は、前記共有空間の利用参加ユーザーが持つユーザーリストのうちのｎ番までをマスター候補として設定し、前記マスターピアと同じ役割を持つユーザーが新たに参加する場合、前記マスター候補リストのｎ＋１番目に挿入し、前記マスターピアと異なる役割を持って参加するユーザーの場合、前記マスター候補リストの最後尾に追加し、脱退するユーザーの場合、前記マスター候補リストから削除する操作を実行することを特徴とする。

また、本発明は、マスターピアを含む複数のピアがネットワーク上に仮想的な共有空間を形成し、その中のアプリケーションをコンピュータによって共有する通信システムにおけるマスターピアの異常復帰方法であって、あるピアからイベントを受付、他のピアにそのイベントを再配布するステップと、前記イベントの受付順で一意に決まるマスター候補リストを生成して保持するするステップと、前記マスターピアの通信異常を検出したとき、前記マスター候補リストから一つのマスター候補ピアを選択し、当該マスター候補ピアに対して前記マスターピアの通信異常を通知するステップと、前記マスターピアの通信異常を確認して自身が持つ前記マスター候補リストを参照し、自身より上位のピアが存在しないことを確認のうえ自身がマスターピアとなることを他のピアに通知し、前記他のピアの承認を待って最後のイベントを再配布するステップと、を有することを特徴とする。

また、本発明は、マスターピアを含む複数のピアがネットワーク上に仮想的な共有空間を形成し、その中のアプリケーションを共有する通信システムに用いられるコンピュータプログラムであって、あるピアからイベントを受付、他のピアにそのイベントを再配布する処理と、前記イベントの受付順で一意に決まるマスター候補リストを生成して保持するする処理と、前記マスターピアの通信異常を検出したとき、前記マスター候補リストから一つのマスター候補ピアを選択し、当該マスター候補ピアに対して前記マスターピアの通信異常を通知する処理と、前記マスターピアの通信異常を確認して自身が持つ前記マスター候補リストを参照し、自身より上位のピアが存在しないことを確認のうえ自身がマスターピアとなることを他のピアに通知し、前記他のピアの承認を待って最後のイベントを再配布する処理と、をコンピュータに実行させることを特徴とする。

本発明によれば、マスターピアが異常終了した場合でも、それを検出して他のピアをマスターピアとしてイベント駆動型Ｐ２Ｐリアルタイムコミュニケーションを存続させることができる。また、その際に、共有空間のマスターピアから配布された過去の信頼できるイベントを元に新しい共有空間のマスターピアを一意に選択する仕組みを構築することで、再配布されたイベントにより作成されるマスター候補リストにより、全てのピアが代替マスターピア候補を一意に決定することができる。また、マスターピア以外のピアからのマスター交代通知の正当性を確認できる。
更に、イベント再配布途中でのマスターの異常終了に対しても、マスター交代完了後最終イベントを再配布することで各ピアの状態を同一に保つことができる。すなわち、選択されたマスターピア候補は必ず最新のイベントを受信しているため、最新のイベントを各ピアに再配布することで順序性が保証される。

図１は、本発明実施形態にかかわる通信システムの構成を示すブロック図である。ここでは、マスター候補ピア１とピア２のみ示されている。
マスター候補ピア１は、マスター機能実行部１１と、最終イベント記憶部１２と、イベント処理部１３と、マスター交代管理部１４と、イベント要求部１５と、マスター候補リスト生成保持部１６で構成される。
マスター機能実行部１１は、ピア２からのイベント要求を受け付け、ピア２を含む他のピアにイベントを再配布する機能を持つ。最終イベント記憶部１２には、最後に処理したイベントがイベントに付される通番と共に記憶される。また、イベント処理部１３は、マスターピア１から再配布されたイベントを処理する機能を持つ。更に、マスター交代管理部１４は、マスター交代を実行するためにピア２との間で通知および承認のためのネゴシエーションを行う。

イベント要求部１５は、マスターピアに対してイベント実行を要求する機能を持つ。また、マスター候補リスト生成保持部１６は、イベントの受付順で一意に決まるマスター候補リストを生成して保持する機能を持ち、ここにマスター終了時の交代候補が優先度順に設定される。
なお、ピア２は、ここではマスターピアとして動作しないため、マスター機能実行部を除く全てのブロックが含まれ、ブロック名および機能はマスター候補ピアのそれと同じであるため、重複を回避する意味でここでの説明は省略する。

図２は、図１に示す本発明実施形態の動作概念図、図３は、その処理の流れをブロックチャートで示している。図２では、説明の都合上、図１に示す構成に、ピア３とマスターピア４が付加され、示されている。なお、図２に示される各ブロックに付された番号は図１に示すそれと同じとする。また、図３のピアＡは、以降で説明するピア２と同じとする。
以下、図２、図３を参照しながら、図１に示す本発明実施形態の動作について詳細に説明する。

マスターピア４は、前処理として、イベントの再送信の際に通番を付加し、マスター候補ピア１を含む各ピア２、３は、最後に受け取ったイベントとその通番を最終イベント記憶部２２に記憶する。また、各ピア１、２、３は、受け取ったイベントの順番で一意に決まるマスター候補リストを作成し、マスター候補リスト生成保持部２６に保持する。ここでいう順番とは、共有空間に現在参加しているピアのうち古くから参加している順番等をいう。詳細は後述する。また、途中から参加したピアにはマスター候補リスト作成に必要な情報が配信される。
マスターピア４は、マスター候補リストの最上位に位置するピアから順にイベントを再送信する。このことにより、マスター異常時に次のマスターとなるピアに、常に最新のイベントが配信されることが保証される（他のピアに配信されたイベントは必ず既に配信されている）。

ピア２は、マスターピア１への通信異常によりマスターピア１が異常終了したことを検出する（Ｓ３１）。そして、マスター候補リストの最上位のピア（マスター候補）にマスター異常終了を伝える（Ｓ３２、Ｓ３３）。ここで、ピア２は、マスター候補リストの最上位のピアが既に共有空間に存在しない（通信できない）場合は、マスター候補リストの次に位置するピアをマスター候補とし、マスターピア通信異常（異常終了）を伝達する。上記の処理は、共有空間に存在するマスター候補が見つかるまで繰り返される（Ｓ３４）。

一方、マスター候補ピア１は、マスターピア４の異常終了を確認し（Ｓ３５）、自分より上位のピアが存在しないことを確認できればそのピアをマスター候補としてマスター異常終了を伝える（Ｓ３６）。続いて、マスター機能実行部１１を起動する（Ｓ３７）。

マスター候補ピア１は、各ピア２、３にマスター交代通知を発行する（Ｓ３８）。これを受けたピア２、３は、マスター候補ピア１が、存在確認ができる中でマスター候補リストの最上位にあることを確認し、更に、マスターピア４の異常終了を確認することで、マスター候補ピア１がマスター被交代ピアとして正当であることを確認する（Ｓ３９）。各ピア２、３がマスター交代を承認することで（Ｓ４０）、マスター交代処理が完了する。なお、ピア２、３によるマスター交代承認処理（Ｓ４０）において、十分な時間経過後も承認されない場合、当該ピア２、３は共有空間から脱退したものと判断される。
続いて、マスター候補ピア１は、各ピア２、３に対し、マスター交代完了を通知し（Ｓ４１）、最後のイベントを再送信する（Ｓ４２）。これを受けたピア２、３を含む全てのピアは、通番を確認し、未処理イベントの場合はイベント処理部１３で処理を行う（Ｓ４３）。
このように、マスター候補リストのマスター候補の上位から順にイベントが再配布されるため、イベント再配布中にマスター交代が起っても、新マスターは最後の（途中までしか再配布されていないかもしれない）イベントを再配布することができる。

次に、マスター候補リストの作成方法について説明する。ここでは、各参加者が図４に示すユーザーリストを所持するものとする。但し、マスターピア４のみが共有空間に参加している初期状態ではｎ＝１，ｍ＝０である。図示したユーザーリストのうち、２番目からｎ番目までがマスター候補となる。
ここで、マスターピア４と同じ役割を持つ参加者が共有空間に参加する場合、ユーザーレストのｎ＋１番目に挿入され、マスターピア４とは異なる役割を持つ参加者が参加する場合はユーザーリストの最後に追加することとする。なお、参加者が脱退する場合は、ユーザーリストから削除する。

ところで、多くのアプリケーションのマスターになっているノードは一般に負荷が大きい。ここでは、負荷の大きいノードが共有空間のマスターになることを回避して負荷分散をはかるマスター候補リストの作成方法および、マスター交代手順について説明する。
まず、マスター候補リストは、共有マスター候補のうちマスターであるアプリケーションの数が少ない順に並ぶ。同数の場合は参加が早い方（遅い方でも可、ただしシステムとして統一する）とする。
マスター候補リストは、「参加」、「脱退」、「アプリケーションの共有開始」、「共有解除」操作のいずれかで順序が入れ替わる可能性がある。マスター候補リストの入れ換えが発生した場合は、入れ替わる前のリストを１世代だけ保存する必要がある。マスター候補リストの入れ換えが発生しないイベントが発生した（受け取った）時点で、旧リストを破棄する（最新のリストのみ保持する）。

マスターの変更手順について、図５に示すブロックチャートを参照しながら説明する。
まず、ピア２は、マスターピア４への通信異常によりマスターピア４が異常終了したことを検出する（Ｓ５１）。そして、最新のマスター候補リストにおける最上位のピア（マスター候補ピア１）にマスター異常終了を伝える（Ｓ５２、Ｓ５３）。この際、パラメーターとして自分が最後に受け取ったイベントの通番を付加する。また、ピア２は、マスター候補リストの最上位のピアが既に共有空間に存在しない（通信できない）場合は、マスター候補リストの次のピアをマスター候補として、マスター異常終了を伝える（Ｓ５３）。上記の処理は共有空間に存在するマスター候補が見つかるまで繰り返される（Ｓ５６）。

マスター候補ピア１は、マスターピア４の異常終了を確認し（Ｓ５４）、受け取った通番と自分が最後に受け取ったイベントの通番と比較し（Ｓ５５）、等しいあるいは小さいとき、最新のマスター候補リストを元に、自分より上位のピアが存在しないことを確認して、そのピアをマスター候補としてマスター異常終了を伝える（Ｓ５２）。このとき、マスター候補のピア１が最新のイベントを持っていないということになる。従って、このマスター候補のピア１はマスターになることができないため、マスター候補であったピア１が新しくピアＡとなってＳ５１の処理に戻る。また、自分より上位にピアが存在する場合も（Ｓ５７、Ｙｅｓ）、マスター候補であったピアが新しくピアＡとなってＳ５２の処理に遷移する。
自分より上位のピアがいないとき，マスター候補ピア１はマスター機能実行部１１を起動する（Ｓ５８）。続いて、マスター候補ピア１は、各ピア２、３にマスター交代通知を発行する（Ｓ５９）。これを受けたピア２、３は、マスター候補ピア１がマスター候補として正当であることを確認する。旧マスター候補リストがなければ最新のマスター候補リストを元に、存在確認ができる中でリストの最上位にことが正当であることの条件である。更に、マスターピア４の異常終了を確認する（Ｓ６０）。

各ピア２、３がこれを承認することで（Ｓ６１）、マスター交代処理が完了する。なお、ピア２、３によるマスター交代承認処理（Ｓ６１）において、十分な時間経過後も承認されない場合、当該ピア２、３は共有空間から脱退したものと判断される。
続いて、マスター候補ピア１は、各ピア２、３に対し、マスター交代完了を通知し（Ｓ６２）、最後のイベントを再送信する（Ｓ６３）。これを受けたピア２、３を含む全てのピアは、通番を確認し、未処理イベントの場合はイベント処理部１３で処理を行う（Ｓ６４）。

以上説明のように、本発明は、マスターピア４が異常終了した場合、それを検出して他のピア１をマスターピアとしてイベント駆動型Ｐ２Ｐリアルタイムコミュニケーションを存続させるものである。その際に、共有空間のマスターピアから配布された過去の信頼できるイベントを元に新しい共有空間のマスターピアを一意に選択する仕組みを構築することで、再配布されたイベントにより作成されるマスター候補リスト（マスター候補リスト生成保持部１６）により、全てのピア２、３が代替マスターピア候補を一意に決定することができる。
また、マスターピア４以外のピア２、３からのマスター交代通知の正当性を確認することができる。更に、イベント再配布途中でのマスターピア４の異常終了に対しても、マスター交代完了後、最終イベントを再配布することで各ピア２、３の状態を同一に保つことができる。すなわち、選択されたマスター候補ピア１は必ず最新のイベントを受信しているため、最新のイベントを各ピア２、３に再配布することで順序性が保証される。

なお、従来のイベント駆動型Ｐ２Ｐリアルタイムコミュニケーションシステムでは、マスターピア以外のピアの正常／異常終了、およびマスターの正常終了については、各ピアが正しく共有空間の状態変化として知ることができた。しかし、マスターピアが異常終了したときに、これを共有空間の状態変化としてしることができず、共有空間の機能が損なわれてしまったが、本発明によれば、マスター候補リストの存在、およびマスター交代管理を行うことより、マスターピア異常時のマスター交代をサポートし、さらに、最終イベントを記憶しておくことで、マスター交代時の各ピア間での状態の同一性を保証することができるものである。

また、図１、図２に示す、マスター機能実行部１１と、最終イベント記憶部１２と、イベント処理部１３と、マスター交代管理部１４と、イベント要求部１５と、マスター候補リスト生成保持部１６のそれぞれで実行される手順をコンピュータ読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって本発明の通信システムを実現することができる。ここでいうコンピュータシステムとは、ＯＳや周辺機器等のハードウェアを含む。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組合せで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

以上、この発明の実施形態につき、図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

本発明実施形態にかかわる通信システムの構成を示す図である。 本発明実施形態にかかわる通信システムの動作概念図である。 本発明実施形態の動作の一例を示すブロックチャートである。 本発明実施形態で使用されるマスター候補リストの一例を示す図である。 本発明実施形態の動作の一例を示すブロックチャートである。 共有空間のイメージを説明するために引用した図である。 従来の通信システムにおけるイベントの同期を説明するために引用した図である。 従来の通信システムにおけるピアの異常検出処理を説明するために引用した図である。

符号の説明

１…マスター候補ピア、２、３…ピア、４…マスターピア、１１…マスター機能実行部、１２…最終イベント記憶部、１３…イベント処理部、１４…マスター交代管理部、１５…イベント要求部、１６…マスター候補リスト生成保持部

Claims (6)

1. マスターピアを含む複数のピアがネットワーク上に仮想的な共有空間を形成し、その中のアプリケーションを共有する通信システムであって、
   前記それぞれのピアは、
   少なくとも、あるピアからイベントを受付、他のピアにそのイベントを再配布するマスター機能実行部と、前記イベントの受付順で一意に決まるマスター候補リストを生成して保持するマスター候補リスト生成保持部とを備え、前記マスターピアの通信異常を検出したとき、前記マスター候補リストから一つのマスター候補ピアを選択し、当該マスター候補ピアに対して前記マスターピアの通信異常を通知し、
   前記マスター候補ピアは、前記マスターピアの通信異常を確認して前記マスター候補リストを参照し、自身より上位のピアが存在しないことを確認のうえ自身が持つ前記マスター機能実行部を起動することを特徴とする通信システム。
2. 前記それぞれのピアは、
   前記マスター候補リストの最上位に位置するピアが既に前記共有空間に存在しない場合、次に位置するピアをマスター候補として選択して前記マスターピアの通信異常を通知する処理を、前記共有空間に存在するマスター候補ピアが発見されるまで繰り返すことを特徴とする請求項１に記載の通信システム。
3. 前記マスター機能実行部を起動した前記マスター候補ピアは、
   マスター交代の事実を他の全てのピアに通知し、前記他の全てのピアによる承認の処理を待って最後のイベントを再配布することを特徴とする請求項１または２に記載の通信システム。
4. 前記マスター候補リスト生成保持部は、
   前記共有空間の利用参加ユーザーが持つユーザーリストのうちのｎ番までをマスター候補として設定し、前記マスターピアと同じ役割を持つユーザーが新たに参加する場合、前記マスター候補リストのｎ＋１番目に挿入し、前記マスターピアと異なる役割を持って参加するユーザーの場合、前記マスター候補リストの最後尾に追加し、脱退するユーザーの場合、前記マスター候補リストから削除する操作を実行することを特徴とする請求項１に記載の通信システム。
5. マスターピアを含む複数のピアがネットワーク上に仮想的な共有空間を形成し、その中のアプリケーションをコンピュータによって共有する通信システムにおけるマスターピアの異常復帰方法であって、
   あるピアからイベントを受付、他のピアにそのイベントを再配布するステップと、
   前記イベントの受付順で一意に決まるマスター候補リストを生成して保持するするステップと、
   前記マスターピアの通信異常を検出したとき、前記マスター候補リストから一つのマスター候補ピアを選択し、当該マスター候補ピアに対して前記マスターピアの通信異常を通知するステップと、
   前記マスターピアの通信異常を確認して自身が持つ前記マスター候補リストを参照し、自身より上位のピアが存在しないことを確認のうえ自身がマスターピアとなることを他のピアに通知し、前記他のピアの承認を待って最後のイベントを再配布するステップと、
   を有することを特徴とする通信システムにおけるマスターピアの異常復帰方法。
6. マスターピアを含む複数のピアがネットワーク上に仮想的な共有空間を形成し、その中のアプリケーションを共有する通信システムに用いられるコンピュータプログラムであって、
   あるピアからイベントを受付、他のピアにそのイベントを再配布する処理と、
   前記イベントの受付順で一意に決まるマスター候補リストを生成して保持するする処理と、
   前記マスターピアの通信異常を検出したとき、前記マスター候補リストから一つのマスター候補ピアを選択し、当該マスター候補ピアに対して前記マスターピアの通信異常を通知する処理と、
   前記マスターピアの通信異常を確認して自身が持つ前記マスター候補リストを参照し、自身より上位のピアが存在しないことを確認のうえ自身がマスターピアとなることを他のピアに通知し、前記他のピアの承認を待って最後のイベントを再配布する処理と、
   をコンピュータに実行させるコンピュータプログラム。
   
   

Images