ネットワークシステム
【課題】Ｐ２Ｐ方式のネットワークにおいてセッションへの参加ノード数に上限がある場合であっても、当該上限を超えた数のノードで情報共有するための技術を提供する。
【解決手段】Ｍ個（Ｍは２以上の整数）を上限とする複数個のノードにより形成されるノード群であるセッションを複数個含むネットワークシステムであって、同じセッションに参加しているノード同士は互いに情報を送受信することが可能であり、それぞれのセッションは、複数のセッションに参加しているノードである接続ノードを少なくとも一つ含んでおり、接続ノードが情報を中継することにより、異なるセッションに参加しているノード同士で情報が送受信されることを特徴とするネットワークシステムを用いる。
【解決手段】Ｍ個（Ｍは２以上の整数）を上限とする複数個のノードにより形成されるノード群であるセッションを複数個含むネットワークシステムであって、同じセッションに参加しているノード同士は互いに情報を送受信することが可能であり、それぞれのセッションは、複数のセッションに参加しているノードである接続ノードを少なくとも一つ含んでおり、接続ノードが情報を中継することにより、異なるセッションに参加しているノード同士で情報が送受信されることを特徴とするネットワークシステムを用いる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置がピアツーピア方式で形成するネットワークシステムに関する。
【背景技術】
【０００２】
インターネットのように、情報処理装置が回線を通じて通信を行うネットワークが広く利用されている。例えばゲームの分野においても、通信機能を持つゲーム機等の情報処理装置（以下、「ノード」とも呼ぶ）を操作してネットワーク上で他のノードと通信し、対戦やチャット、情報共有を行うことが普通になっている。そして、かかるネットワークの構成として様々な形態が存在する。
【０００３】
まず一つの構成として、クライアント／サーバ方式がある。この場合、各ノードがクライアントとなり、ネットワークを通じてサーバに処理要求を送信する。処理要求を受信したサーバは、自身の資源を利用して情報処理を行い、必要に応じてノードに情報を送り返す。
【０００４】
しかし、かかるクライアント／サーバ方式では、ネットワークが大規模化するにつれて、サーバの処理能力およびネットワークの負荷の点で問題が生じる。すなわち、クライアント数が増えるとサーバに要求される処理件数も増加し、ユーザへのレスポンスが悪化する。それに対応するためには高性能な情報処理装置を使用する必要があり、結果的にネットワークを運営するコストが増大する。また、クライアント数の増加により通信量が多くなると、データ伝送帯域が増大し、ネットワーク上のボトルネックとなる。このように、クライアント／サーバ方式におけるネットワークの大規模化は、サービス品質の低下や運営コストの増加につながる。
【０００５】
もう一つの構成として、Ｐ２Ｐ（ピアツーピア）方式がある。Ｐ２Ｐ方式においては、ネットワークに参加する各ノードがピアとなり、他のノードと接続して情報を送受信する。Ｐ２Ｐネットワークで提供できるサービスとして、情報の共有、ストリーミングによるデータ配信、メッセージングなどがある（特許文献１、２参照）。Ｐ２Ｐ方式においては、情報処理の負荷が各ノードに分散されることや、ネットワーク伝送経路が分散されることから、上記のクライアント／サーバ方式に比べて個々の情報処理装置の規模を小さくでき、かつ、ネットワークの帯域も抑制できる。したがって、サービスへの参加ノード数の増加した時の拡張性に優れている。さらに、サーバとＰ２Ｐ方式のネットワークと組み合わせてさらなる性能向上を図ることも可能である。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−２６８８４４号公報
【特許文献２】特開２０１０−１０９９７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、Ｐ２Ｐ方式のネットワークにおいて、提供されるサービスに参加可能なノード数が制限される場合がある。かかる制限は、主にサービスを提供するシステム側の都合による。例えば、ゲーム機がノードとなり、Ｐ２Ｐネットワークを形成してオンラインで対戦可能とするサービスについて検討する。なおこれ以降、サービスを受ける際に互いに通信して情報を共有するノード群を「セッション」とも呼ぶ。
【０００８】
ここで、あるゲーム機を用いたサービスでは、一つのセッションに参加可能なノード数を３２台までに制限されているとする。この場合、３３台目以降のノードは同じゲームに参加することができず、大人数でのゲームを享受するための支障となる。また、Ｐ２Ｐ方式の利点の一つである、参加ノード数の増大に対する拡張性を十分に生かせないことになる。
【０００９】
本発明は上記の課題に鑑みてなされたものであり、その目的とするところは、Ｐ２Ｐ方式のネットワークにおいてセッションへの参加ノード数に上限がある場合であっても、当該上限を超えた数のノードで情報共有するための技術を提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明は以下の構成を採用する。すなわち、Ｍ個（Ｍは２以上の整数）を上限とする複数個のノードにより形成されるノード群であるセッションを複数個含むネットワークシステムであって、同じセッションに参加しているノード同士は互いに情報を送受信することが可能であり、それぞれのセッションは、複数のセッションに参加しているノードである接続ノードを少なくとも一つ含んでおり、前記接続ノードが情報を中継することにより、異なるセッションに参加しているノード同士で情報が送受信されることを特徴とするネットワークシステムである。
【００１１】
このようなネットワークシステムによれば、たとえセッションに参加できるノード数が制限されている場合であっても、接続ノードの中継により、異なるセッションに属するノードの間で情報の送受信が行われる。その結果、上限を超えた数のノードの間で情報の共有が可能になり、Ｐ２Ｐネットワークの利点を多数のユーザが享受することができる。
【００１２】
また、上記のネットワークシステムにおいて、前記ネットワークシステムに参加しているノードは、一つの親ノードにＭ−１個を上限とする子ノードが接続する木構造を形成し、前記セッションは、木構造において上流側に位置する一つの親ノードと、木構造において前記親ノードの下流側に接続する子ノードからなるものであり、前記接続ノードは、当該接続ノードが子ノードとして参加するセッションと、当該接続ノードが親ノードとして参加するセッションとの間で情報を中継するような構成を取ることができる。
このようなネットワークシステムによれば、セッション間の階層構造を単純化することができるので、情報の送受信の方向が明確になる。また、接続ノードによる情報の送受信の回数を抑制することが可能になる。
【００１３】
また、ネットワークシステムが、各ノードが同じデータを保持することにより同じ内容を参照できる電子掲示板を提供する場合、前記電子掲示板に書き込みを追加するノードである注目ノードは、書き込みの内容を含む書き込み要求を、同じセッションに参加するノードに送信し、前記注目ノードと同じセッションに参加するノードは、前記注目ノードからの書き込み要求を受信すると、保持するデータに前記書き込みを行い、前記注目ノードと異なるセッションに参加するノードは、前記接続ノードが中継してきた前記データ書き込み要求を受信して、保持するデータに前記書き込みを行うような構成を取ることができる。
このようなネットワークシステムによれば、上限を超えた数のノードによる、追記式の電子掲示板への書き込みや参照が可能になる。
【００１４】
また、ネットワークシステムが、同じセッションに参加しているノード同士が行う対戦型ゲームの内容を他のノードに伝える観戦システムを提供しており、前記ネットワークシステムに参加しているノードは表示装置を含む場合に、前記対戦型ゲームを行うノードである注目ノードは、ゲームの対戦の状況に関するパラメータを、同じセッションに参加す
るノードに送信し、前記注目ノードと同じセッションに参加するノードは、前記注目ノードからのパラメータを受信して、ユーザが視聴可能な形式で表示装置に表示し、前記注目ノードと異なるセッションに参加するノードは、前記接続ノードが中継してきた前記パラメータを受信して、ユーザが視聴可能な形式で表示装置に表示するような構成を取ることができる。
このようなネットワークシステムによれば、上限を超えた数のノードによる、対戦型ゲームの観戦システムを実現できる。
【００１５】
また、ネットワークシステムが、各ノードが同じ内容の更新可能なデータである同期情報を保持し、いずれかのノードによる更新内容が他のノードにおいて同期されるサービスを提供する場合に、前記ネットワークシステムは、木構造における根ノードを含むセッションである最上位セッションに参加しており、前記同期情報の更新の排他制御を行う調停ノードを含み、前記同期情報を更新するノードである注目ノードは、更新内容を含む更新要求を、前記接続ノードの中継により前記調停ノードに送信し、前記注目ノードからの更新要求を受信した前記調停ノードは、前記ネットワークシステムに参加する各ノードに更新内容を含む更新指示を送信するような構成を取ることができる。
このようなネットワークシステムによれば、調停ノードのみが情報の更新指示を行うことにより排他制御がなされるので、上限を超えた数のノードの間で書き換え可能な情報を共有し、同期が取れた状態にすることができる。
【００１６】
また、ネットワークシステムに参加するノードが通常のノードとストリクトノードを含み、当該ストリクトノード同士では直接的に通信を行うことができない場合に、前記通常のノードが前記セッションの親ノードとなるような構成を取ることができる。
このようなネットワークシステムによれば、ストリクトノードの存在により一部のノード間の通信が制約を受ける場合であっても、ネットワークの木構造の上流と下流の情報伝達を保証できる。
【発明の効果】
【００１７】
本発明によれば、Ｐ２Ｐ方式のネットワークにおいてセッションへの参加ノード数に上限がある場合であっても、当該上限を超えた数のノードで情報共有することが可能になる。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施例１における掲示板への書き込み要求の伝達を説明する模式図である。
【図２】本発明のノードの構成を説明するブロック図である。
【図３】本発明の実施例１における掲示板への書き込み要求の伝達を説明するフローチャートである。
【図４】本発明の実施例１におけるデータ構造を説明する図である。
【図５】本発明の実施例３における同期情報の更新要求の伝達を説明する模式図である。
【図６】本発明の実施例３における同期情報の更新指示の伝達を説明する模式図である。
【図７】本発明の実施例３における同期情報の更新要求の伝達を説明するフローチャートである。
【図８】本発明の実施例３における同期情報の更新指示の伝達を説明するフローチャートである。
【図９】本発明の実施例３の変形例における同期情報のブロックを説明する図である。
【図１０】本発明の実施例４におけるノード間の通信の制限を説明する図である。
【発明を実施するための形態】
【００１９】
本発明は情報処理装置である複数のノードが集まってセッションを形成し、互いに通信を行って構成される、ピアツーピア（Ｐ２Ｐ）方式のネットワークを前提としている。以下、各実施例に共通するノードとセッションの構造について説明する。さらに、複数のセッションの集合であるセッションクラスタについても説明する。セッションクラスタは、本発明における「ネットワークシステム」に相当する。
【００２０】
（ノードの説明）
図２は、各ノードの構成を説明するブロック図である。
以下の実施例において、各ノードはほぼ同程度の処理能力を持つコンピュータ等の情報処理装置を想定している。具体的には、家庭用のゲーム機やＰＣを利用できる。以下の実施例では、ユーザが家庭用のゲーム機を用いて他のユーザと共通のネットワークにログインし、掲示板機能による連絡、ゲームのオンライン対戦や、書き換え可能な情報の共有等を行うシステムを想定している。
【００２１】
ノード２０は、情報処理部２０１、記憶部２０２および通信部２０３を備える。情報処理部２０１は情報処理機能を備えるプロセッサである。情報処理部２０１は、光学ディスクや記憶装置等に格納されたゲームのデータや、ネットワークを経由して取得した他のユーザの行動に関するデータ等に基づいて、ユーザに表示する画像・音声を作成する。情報処理部２０１はまた、ユーザの操作を受け付けて、ゲームの規定に従った処理を行い、必要に応じてノード２０のユーザにフィードバックしたり、他のノードのユーザに情報送信したりする。記憶部２０２はデータの記憶装置であり、例えばＨＤＤ装置やフラッシュメモリを利用できる。
【００２２】
通信部２０３はネットワークを経由して他のノードと情報の送受信を行う通信装置である。ネットワークは他のノードと通信可能なものであれば種類は問わず、ゲームに専用の回線であっても良いし、インターネットのようにオープンな形式でも良い。また有線無線の別も問わない。ここでは、各ノードのネットワーク速度は同程度であるものとする。
【００２３】
ノード２０には、ユーザインターフェースとして表示装置２１と入力装置２２が接続されている。表示装置２１はユーザに情報を提示するためのディスプレイ装置である。表示装置に加えて、ユーザに音声や振動でゲームの進行を伝える装置を設けても良い。入力装置２２はユーザによる操作を受け付ける装置であり、ゲームコントローラやキーボード、マイク等が用いられる。あるいは、ノードが携帯型のゲーム機であれば、ノード本体と表示装置や入力装置が一体となって構成されていても良い。
【００２４】
（ネットワーク構成の説明）
図１（ａ）を用いて、ノードの集合であるセッション、および、セッションの集合であるセッションクラスタの構成例を説明する。
図中の円形は、それぞれがノードを表わす。また、符号１１１、１１２、１１３および１１４で示される円錐はそれぞれ、セッションを模式的に表わしたものである。基本的には、同じセッションに属するノード同士は相互に情報の送受信が可能であるものとする。
【００２５】
セッションに参加できるノードの数は、あらかじめシステムの前提として定められている。この例では、一つのセッションに参加できる上限ノード数は７個である。また、この例では、あるノードが３つ以上のセッションに参加することはないものとしている。ただしこれらの条件は、接続ノードの処理能力やネットワークの帯域に応じて適宜変更できる。
【００２６】
あるセッションに参加しているノードは、もう一つ別のセッションに参加することも可能であり、このようなノードを接続ノードと呼ぶ。図中で言えば、ノード１０２はセッション１１１と１１２に、ノード１０４はセッション１１２と１１３に、ノード１０５はセッション１１１と１１４に、それぞれ重複して参加している。したがって、二つのセッションに参加している接続ノードは、一方のセッションの参加ノードから情報を受信することもできるし、当該受信した情報を、もう一方のセッションの参加ノードに送信することもできる。このように接続ノードが情報を中継してセッションをまたがるノード同士での情報の送受信を実現することにより、本発明のセッションクラスタが形成される。
【００２７】
以下の実施例では、接続ノードが中継するセッションの間には、木構造における上位と下位の概念がある。図中で言えば、セッション１１１が最上位セッションであり、これより上位のセッションは存在しない。セッション１１２とセッション１１４は、最上位セッションに直に接続する下位セッションである。セッション１１３は、セッション１１２のさらに下位に接続している。結局セッションクラスタは、一つの最上位セッションと、それに次々と連なる下位セッションから構成される木構造となっている。このような木構造は、階層構造を単純化でき、情報伝達の方向を明確化できる点で好ましい。特に、ノードの数が増えてくると（例えば１千個〜１万個程度）、階層構造が単純な方が情報の中継回数を少なくできる点で好ましい。
【００２８】
ただしこのような木構造は一例であり、セッションを網目状につないだり、循環的に連結させたりする方法でもセッションクラスタは実現できる。
【００２９】
なお、図１（ａ）は模式図であるため、最上位セッション内のノードで下位セッションを持たないものが存在する。しかし、先に最上位セッション内の全てのノードが下位セッションを持ったことを確認してから、更に下位のセッションを設けるように順序を制御しても良い。これにより、セッション間の中継回数を減少させることができる。
【００３０】
（セッションの形成）
以下の実施例では、セッションは一つのノードがセッションオーナとなって作成し、他のノードが参加することによって形成される。
すなわち、ユーザがゲーム機（ノード）を操作してオンライン機能を利用しようとした時、ノードはネットワーク上に参加できるセッションがあるかどうかを検索する。この検索方法は任意であるが、例えばゲーム機に、サーバを利用したあるいはアドホック機能による既存のマッチングシステムが存在する場合、それを利用すれば良い。ただしサーバを利用した場合であっても、セッションが形成された後はＰ２Ｐ方式で通信が行われる。セッションオーナとなるノードは、ユーザにとっては通常のゲーム機として機能するが、背後ではセッションへのノードの参加などを管理する。
【００３１】
また、セッションクラスタの最上位セッション１１１には、最上位ノード１０１が存在する。最上位ノード１０１は、最上位セッション１１１のセッションオーナでもある。最上位ノードは木構造の根ノードにあたり、最上位セッションは根ノードとその子ノードからなる。
以下の実施例ではまた、下位セッションのセッションオーナは、上位のセッションとの間の接続ノードとなっている。すなわち、セッションオーナは上位のセッションにメンバとして参加している。
このようにすれば、当該セッションが、最上位セッションから連なる木構造の中に参加していることが保証される。具体的に見ると、図中、セッション１１２のセッションオーナであるノード１０２は上位セッション１１１のメンバでもある。
【００３２】
したがって、セッションクラスタ全体でみると、最上位ノードが最上位セッションを作
成し、最上位セッションに参加した各ノードが下位セッションを持つことにより木構造が形成される。言い換えると、あるノードを取りだして親ノードと見た時、そのノードと、そのノードに接続される子ノードが一つのセッションとなる。上位セッションと下位セッションの接続においては、別個に作成されたセッションが所定の方法で接続されても良いし、最上位セッションの参加ノードがセッションを作成し参加者を受け付ける方法でも良い。下位セッションの参加ノードがさらにセッションを作成することで、木構造の枝が成長する。
【００３３】
（ノード離脱）
セッションに参加しているノードが、何らかの理由でＰ２Ｐネットワークから離脱した場合、そのノードの役割に応じて残りのノードの動作は変わる。ノードの離脱は、ノード間の通信が一定時間以上途絶えたことにより検知できる。
セッションオーナではない通常のノードの離脱であれば、特に必要な動作はないが、セッションの参加者数が上限値よりも少なくなるので、セッションクラスタへの参加を希望するノードをより上位のセッションに参加させることができる。
【００３４】
セッションオーナが離脱した場合、セッション内の他のノードが代わりにセッションオーナとなる。新たにセッションオーナになったノードは、上位のセッションとの接続を回復する。どのノードがオーナとなるかは、ノード間の通信によって決定してもよい。あるいは、離脱したセッションオーナが接続ノードとして参加していた上位のセッション内のノードが、当該離脱したノード以外の下位のセッション内のノードの情報を保持している場合、離脱を検知した上位のセッションが指示を出しても良い。
最上位ノードが離脱した場合、最上位セッション内のノードの中から後継を決める。
【００３５】
運営者が存在するネットワークの場合、最上位ノードだけは運営者が維持しておくことにより、セッションクラスタの継続性を増すことができる。この場合であっても、処理能力の高いサーバ機を用意する方式よりも維持コストを減らすことができる。
【００３６】
＜実施例１＞
実施例１では、ゲーム機等のノード同士がＰ２Ｐ方式で形成するネットワークにおいてユーザが利用する掲示板システムについて説明する。ここで掲示板とは、ＢＢＳ(Bulletin Board System)とも呼ばれる電子掲示板を指す。本実施例の掲示板システムは追記型で
あり、各ユーザは情報を書き込んだり、他人の書き込みを読んだり、返信したりすることができる。しかし、書き込みの削除や修正は行われないことを前提とする。かかる掲示板システムを実現するために、本実施例では、特定のサーバを設ける代わりに、セッションクラスタに参加するノードのいずれもが同じコンテンツを保持する方式を取る。
【００３７】
（データ構造）
図４（ａ）は、掲示板のＧＵＩの一例を示す図である。また図４（ｂ）は、掲示板に使用されるデータ構造を示す図である。図４（ｂ）において、各エントリーは掲示板への一つの書き込みに相当する。各エントリーには、書き込みを一意に識別するための個別ＩＤ(MSG_ID)、書き込み日時(TIMESTAMP)、書き込み要求したユーザ(USER_ID)、他の書き込みへの返信であるかどうか、および、返信であれば対象の書き込み(REPLY_TO)、書き込み内容(CONTENT)の各フィールドを持つ。このデータはノードの記憶部２０２に保管される。
ただしこの図に示したデータ構造およびＧＵＩは一例であり、実際には必要に応じて任意に決定することができる。
【００３８】
あるノードが掲示板への書き込み要求を行う時は、まず、入力装置２２によりユーザからの書き込み内容を受け付ける。続いて、情報処理部２０１は、各フィールドの内容を埋めた後、あらかじめ定められたプロトコルに従い、通信部２０３から他のノードに書き込
み要求を送信する。例えば図４（ｂ）の１行目のデータであれば、情報処理部２０１は、ユーザ名とユーザ自身の通し番号からMSG_IDを生成し、現在時刻からTIMESTAMPを入力し
、他のユーザへの返信ではないのでRESPONSE_TOにNULLを入力し、ユーザが書き込む内容
でCONTENTを埋める。
【００３９】
続いて、他のノードは、書き込み要求を通信部２０３で受信すると、その内容を一つのエントリーとして記憶部２０２に保管する。そして、情報処理部２０１は、各フィールドの内容に基づいて、図４（ａ）のように表示装置２１に掲示板を表示する。
【００４０】
（構造）
再度、図１（ａ）を用いて本実施例のセッションクラスタについて述べる。
図中、黒く塗られたノード１０３は、注目ノードである。注目ノード１０３は、セッションクラスタの各ノードに対し、掲示板への書き込みを要求する。注目ノード以外のセッションクラスタの構成要素は上述した通りである。
【００４１】
（処理の流れ）
図３は、処理の全体的な流れを示すフローチャートである。
ステップＳ１０１において、注目ノード１０３が同じセッション１１２に参加しているノードに対して、掲示板への書き込み要求を送信する。
【００４２】
ステップＳ１０２において、書き込み要求を受信したノード（セッション１１２内の各ノード）が、記憶部２０２にエントリーを追加し、表示装置２１の掲示板ＧＵＩを更新する。これにより、セッション１１２内の各ノードの掲示板に書き込みが追記される。本実施例の場合、図１（ｂ）に網掛けで示したノードがこれに相当する。
【００４３】
ステップＳ１０３において、要求を受信したノードは、自身がセッション１１２以外のセッションにも参加しているかどうかを判定する。参加していない場合（Ｓ１０３＝ＮＯ）、そのノードの処理は終了する。参加している場合（Ｓ１０３＝ＹＥＳ）、Ｓ１０４に進む。本実施例の場合、上位のセッション１１１にも参加しているノード１０２と、下位のセッション１１３にも参加しているノード１０４がＹＥＳと判定する。
【００４４】
ステップＳ１０４において、他のセッションにも参加しているノードは、当該他のセッション内のノードに対して、掲示板への書き込みを要求する。本実施例の場合、ノード１０２からセッション１１１内の各ノードに、ノード１０４からセッション１１３内の各ノードに書き込み要求がなされる。
【００４５】
続いて再度ステップＳ１０２に進み、書き込み要求を受信した各ノードが自身の掲示板に追記する。本実施例の場合、図１（ｃ）に網掛けで示したノードの掲示板に書き込みが追記される。
【００４６】
本実施例においては、セッション１１１に参加しているノード１０５は、他のセッション１１４にも参加しているので、再度ステップＳ１０３においてＹＥＳの判定がなされ、セッション１１４内のノードにも書き込み要求が出される。その要求を受信したセッション１１４内のノードが書き込みを追記した結果、図１（ｄ）に示すように、セッションクラスタに参加している全てのノードの掲示板に書き込みが行われた状態になる。
【００４７】
（効果）
本実施例の方式によれば、セッションへの参加ノード数に上限があるＰ２Ｐネットワークにおいて、複数のセッションを一つのセッションクラスタとして扱うことができるようになる。そして、異なるセッションに属するノード間で掲示板のような形式で情報を共有
することが可能となる。これにより、ユーザは自身がどのセッションに参加しているかを意識することなく、ゲームに参加している（セッションクラスタに属する）多数のノード全体を対象として、掲示板への書き込みや返信などを行うことが可能となる。
本実施例の情報送受信の方式は、電子掲示板システムのみではなく、書き換えが起こらない情報を共有するシステム全般に適用可能である。
【００４８】
＜実施例２＞
実施例２では、ゲーム機等のノード同士がＰ２Ｐ方式で形成するネットワークにおける、対戦型ゲームの観戦システムについて説明する。すなわち、セッションクラスタに参加するノードのうちいくつかのノードが対戦型ゲームを行い、他のノードはその模様を観戦するシステムである。
【００４９】
（ゲーム内容）
対戦型ゲームの具体的な例について述べる。ここでは、対戦者は２人のユーザであり、それぞれがノード（ゲーム機）を操作する。この例では、図１（ａ）のセッション１１１に属するノード１０２およびノード１０５が対戦者であるものとする。ゲームの内容は、対戦ユーザのそれぞれに対応する２台の機体がディスプレイに表示され、各ユーザは入力装置を通じて自分の機体を操作し、ゲームのルールが定める所定の条件を満たして対戦相手の撃破を目指すものである。
【００５０】
例えばノード１０２のユーザは、入力装置２２から、機体の移動や相手への攻撃の指示を入力する。ノード１０２の情報処理部２０１は、指示の内容をパラメータ化した後、所定のプロトコルにしたがって通信部２０３から対戦相手のノード１０５に送信する。パラメータの内容は、機体の移動方向や距離、攻撃の手段や方向などである。
【００５１】
対戦相手のノード１０５の情報処理部は、受信したパラメータに基づき、ノード１０２の指示の内容やタイミングを解析する。そして、ノード１０５のユーザが入力した指示の内容と比較し、双方の攻撃の成否やダメージの度合いを判定する。この判定結果は、パラメータ化されてノード１０２にも送信される。したがって、ゲーム開始の時点で通信を行い、互いの機体の位置やダメージの状態などの初期状態を合わせておけば、パラメータをやり取りすることにより、ゲームの現状が対戦者間で共有される。
【００５２】
なお、この例で双方のノードが同じセッションに属することとしたのは、セッションをまたがる通信において接続ノードが情報を中継する際に生じるタイムラグを避けるためである。また、双方のノードが最上位セッション１１１に属することとしたのは、各セッションへの情報伝達時の中継回数を減らすためである。ただし、ゲームの種類、セッションクラスタの規模、ネットワークの速度、および当該ゲームにおける即応性の優先度などを考慮した上で、対戦者を互いに異なるセッションや最上位セッション以外に所属させても構わない。
【００５３】
（観戦システム）
本実施例のセッションクラスタの構成は、実施例１で図１（ａ）を用いて説明したものと同じ構成を取るものとする。かかる観戦システムにおいては、上述したように、対戦者の間でパラメータを次々と送受信することにより、ゲームの最新の状態を共有しながら対戦が行われる。
【００５４】
したがって、対戦者以外のノードがこのパラメータを利用すれば、刻々と変化する対戦の現状を把握することができる。対戦者と同じセッション１１１にあるノードについては、対戦者がセッション内に同報的にパラメータを送信するようにすれば、容易に現状を把握することが可能である。また、対戦者と異なるセッションにあるノードについても、複
数のセッションに参加している接続ノードが受信したパラメータを中継することにより、中継時間分のタイムラグはあるものの、現状を把握することができる。
ここでは２台のゲーム機を用いた対戦型のゲームを例として説明したが、ノードの種類、対戦者の人数、アプリケーションの種類、および、送受信するパラメータの内容などは、Ｐ２Ｐネットワークの目的に応じて任意に設定できることは言うまでもない。
【００５５】
（効果）
本実施例の方式によれば、セッションへの参加ノード数に上限があるＰ２Ｐネットワークで対戦型ゲームが行われる場合であっても、上限数を超えた数のノードが対戦の状況を把握することが可能となる。
【００５６】
（変形例）
本実施例の観戦システムは、単独で用いるだけにとどまらず、実施例１の掲示板システムと組み合わせて利用出来る。すなわち、対戦者間で送受信されるパラメータが接続ノードにより中継されてセッションクラスタ内の各ノードに送信され、対戦の現状を共有するとともに、各ノードが掲示板に書き込んだ内容も中継されて各ノードに表示される、掲示板兼観戦システムである。かかるシステムを用いれば、観戦者が対戦の内容に応じてリアルタイムに感想や応援等を書き込み、情報を共有できる。掲示板のＧＵＩとしては実施例１と同様のウィンドウを用いて、対戦の実況画面の近傍に表示しても良い。あるいは、対戦の実況画面に観戦者の書き込みを重ねて表示しても良い。
【００５７】
＜実施例３＞
実施例３では、ゲーム機等のノード同士がＰ２Ｐ方式で形成するネットワークにおいて、書き換え可能な形で情報を共有する方法について説明する。サーバ／クライアント方式のネットワークであれば、サーバに共有情報を配置して各ノードが書き換え要求を行うようにすれば、排他制御は容易である。一方、Ｐ２Ｐネットワークにおいて書き換え可能な情報を共有するためには、別の方法で排他制御を行う必要がある。
本実施例では、ネットワーク内部に排他制御を担当する「調停ノード」を設けて排他制御を行う方法を説明する。本実施例においても、セッションの参加人数に上限がある場合に、上限値を超えた数のノードでの処理を実現する点は、実施例１、２と共通する。
【００５８】
（データ構造）
サーバを用いない本実施例の方式では、情報を共有するといっても、実際に同じメモリ領域にあるデータの構造体などにアクセスして読み書きするわけではない。その代わりに、セッションクラスタ内の各ノードが同じ内容の情報を保持し、同期して書き換えることにより、同じデータを共有しているのと同じ状態にする。以下、このような情報のことを「同期情報」とも記載する。更新に際しては、現在の内容との差分情報ではなく、同期情報の全体を送受信することが、ノード内での整合性を保証できる点で好ましい。
【００５９】
（セッションクラスタの構成）
本実施例においても、各ノードの構成は、図２を用いて上で説明したものと同様である。
また、セッションおよびセッションクラスタの構成も、基本的には上で説明したものと同様である。図５が本実施例のセッションおよびセッションクラスタの構成である。符号３１１、３１２、３１３および３１４で示される円錐はそれぞれセッションを示す。セッション内のノード同士は互いのネットワーク上の位置情報を保持しており、通信可能な状態である。
【００６０】
最上位ノード３０１は、最上位セッション３１１のセッションオーナである。
本実施例の最上位ノードは、最上位セッション内のノードから１つの調停ノードを選ぶ
ものとする。ここではノード３０５が調停ノードとなる。調停ノードがＰ２Ｐネットワークから離脱した場合、最上位ノードが速やかに次の調停ノードを選択する。
【００６１】
本実施例では、セッションクラスタ内に１つの調停ノードが存在する。そして、ノードからの同期情報の更新要求の内容を、各ノードへの更新指示として送信する。その際、複数のノードから更新要求があった場合など、必要があれば排他制御を行う。これにより、最新の情報が明確になる。
【００６２】
ノード３０２は、最上位セッション３１１および注目ノードを含むセッション３１２の両方に参加しているノードであり、双方の接続ノードとして機能する。
注目ノード３０３は、各ノードの情報の更新を要求するノードである。
ノード３０４は、セッション３１２および下位セッション３１３の両方に参加しており、双方の接続ノードとして機能する。このようにセッション３１１〜３１４は接続ノードがメッセージを中継することにより接続されており、全体で一つのセッションクラスタを構成していると言える。
【００６３】
なお、図５（ａ）、図５（ｂ）、図６（ａ）、図６（ｂ）および図６（ｃ）において、網掛けで示したノードは、注目ノードからの更新要求メッセージを受け取ったノードである。また、黒く塗ったノードは、同期情報が更新されたノードである。
【００６４】
（更新要求の受付）
図７は、注目ノードからの更新要求を調停ノードが受け付けるまでの流れを示すフローチャートである。図５（ａ）、図５（ｂ）は、このときのセッションクラスタの様子である。
ステップＳ３０１において、注目ノード３０３が同じセッション３１２に参加しているノードに対して、更新要求を含むメッセージを送信する。このメッセージには、更新対象の情報と、更新内容が含まれる。このとき、図５（ａ）に示すように、セッション３１２に属するノードは更新要求メッセージを保持している。
【００６５】
ステップＳ３０２において、書き込み要求を受信したノードは、自身が調停ノードかどうかを判定する。ここで、セッション３１２内の各ノードは調停ノードではない（Ｓ３０２＝ＮＯ）ので、ステップＳ３０３に進む。
【００６６】
ステップＳ３０３において、調停ノードでないと判断されたノードは、自身が上位セッションにも参加しているかどうかを判定する。この処理は、上位セッションがなくなるまで、すなわち最上位セッションに到達するまで繰り返される。本実施例では、ノード３０２が上位のセッション３１１にも参加している（Ｓ３０３＝ＹＥＳ）ので、ステップＳ３０４に進む。一方、ノード３０２以外のノードは上位セッションに参加していない（Ｓ３０３＝ＮＯ）ので、処理を終了する。
なお、ここで上位セッションへの参加の有無のみ判定し、下位セッションについて判定していないのは、本実施例においては調停ノードを最上位セッションに配置したためである。
【００６７】
ステップＳ３０４において、ノード３０２は、上位のセッション３１１内のノードに更新要求を送信する。このとき、図５（ｂ）に示すように、セッション３１１および３１２に属するノードは更新要求メッセージを保持している。ただし、Ｓ３０３の後で、ノード３０２以外のノードは更新要求メッセージを破棄しても構わない。
続いて、再度ステップＳ３０２の判定が行われる。ここで、ノード３０５は、最上位セッション３１１に属する調停ノードである（Ｓ３０２＝ＹＥＳ）ため、更新要求の制御処理に進む。
【００６８】
（更新指示の反映）
図８は、更新要求を受け付けた調停ノードが、セッションクラスタ内の各ノードに対して同期情報の更新指示を行う際のフローチャートである。図６（ａ）、図６（ｂ）および図６（ｃ）は、このときのセッションクラスタの様子である。
【００６９】
ステップＳ４０１において、調停ノード３０５が、自身の同期情報を更新するとともに、自身が参加しているセッション（本実施例ではセッション３１１および３１４）内に更新指示のメッセージを送信する。このときの様子を図６（ａ）に示す。
このステップで調停ノードが複数のノードからの更新要求を受け付けた場合、要求を受け付けた順序が早い方を選択する等の排他制御を行う。この場合、もう片方のノードが、自身の更新要求が受け付けられなかったことを知るために、タイムアウトを検知する方法を取ることができる。すなわち、更新要求を出してから一定時間が経過しても要求内容に従った更新指示が受信できない場合、更新が失敗したと認識できる。
【００７０】
ステップＳ４０２において、更新指示を受信したノードは、その内容にしたがって、記憶部２０２に保管されている同期情報を更新する。このときの様子を図６（ｂ）に示す。
【００７１】
ステップＳ４０３において、同期情報を更新したノードは、自身が他のセッション（更新指示を送信してきたノードとは別のセッション）にも参加しているかどうかを判定する。参加していない場合（Ｓ４０３＝ＮＯ）、そのノードの処理は終了する。参加している場合（Ｓ４０３＝ＹＥＳ）、Ｓ４０４に進む。本実施例の場合、セッション３１２にも参加しているノード３０２が該当する。
【００７２】
ステップＳ４０４において、他のセッションにも参加しているノードは、当該他のセッション内のノードに対して更新指示のメッセージを送信する。本実施例の場合、ノード３０２からセッション３１２内の各ノードに更新が指示される。
【００７３】
以下同様に、下位のセッションとの接続ノードが更新指示を伝達することにより、セッションクラスタ内のすべてのノードの同期情報が更新される。最終的に、図６（ｃ）に示すように、セッション内のすべてのノードの同期情報が、注目ノード３０３からの要求にしたがって更新される。
【００７４】
（効果）
本実施例の方式によれば、セッションへの参加ノード数に上限があるＰ２Ｐネットワークにおいて、複数のセッションを一つのセッションクラスタとして扱い、ノード間で情報を共有したり、同期して更新したりすることが可能となる。さらに、かかる同期情報を用いて各ノードが恊働して情報処理を行うこともできる。
【００７５】
なお、本実施例では、調停ノードは最上位セッションにあるものとしたので、更新要求や更新指示のメッセージが流れる方向を単純化することが可能となっているが、必ずしもこの必要はない。
【００７６】
また、セッションクラスタ内の適切な場所に、最新の同期情報をバックアップするノードを設けても良い。そして、調停ノードからの更新指示をまずバックアップノードに反映し、その後各ノードに更新指示を出すようにする。これにより、調停ノードがセッションクラスタから離脱したときなどに、同期情報を復元することができる。バックアップノードは調停ノードとネットワーク上の近い位置（例えば、同じセッション内）にあることが好ましい。さらに、このようなバックアップを複数の世代にわたって保存することにより、同期情報のロールバックに利用することもできる。
【００７７】
（変形例１）
上の記載では、図７のフローチャートのステップＳ３０１において、注目ノード３０３は、セッション３１２内の全てのノードに更新要求を送信している。しかし、セッション３１２から上位のセッションへの接続ノードはノード３０２だとあらかじめ分かっていれば、ノード３０２にのみ更新要求を送信すれば良い。
【００７８】
また上の記載では、接続ノード３０２は、最上位セッション３１１内の全てのノードに更新要求を中継している。しかし、最上位セッション３１１内のノードが、自身は最上位セッションにいること、および、調停ノードはノード３０５だということをあらかじめ分かっていれば、ノード３０５にのみ更新要求を中継すれば良い。どのノードが調停ノードであるかは、最上位ノードから各メンバへの通知により知ることができる。
このような本変形例の構成は、セッション内の全ノードに同報通信をする場合に比べて、情報伝達時のネットワーク負荷を抑制することができる点で好ましい。
【００７９】
（変形例２）
上の記載では調停ノードは一つだけとなっている。しかしこの場合、全てのノードからの更新要求を一つのノードで処理するため、ノードの処理能力を超えて処理が遅延する可能性がある。また、ネットワークの負荷が一つの調停ノードに集中する。さらに、複数のノードからの更新要求が衝突する可能性が高まり、排他制御が行われる結果、更新が実現されない確率が増える。
【００８０】
そこで、図９に示すように、共有情報を複数のブロックに分割し、それぞれのブロックの排他制御を別々の調停ノードに担当させることにより、処理の負担を分散させることが考えられる。
共有情報をブロックに分割する基準としては、データの内容、サイズ、使用目的など、状況に応じて定めることができる。また分割する際には、最上位ノードが各ブロックの内容および排他制御を担当する調停ノードを指定すれば良い。また、ブロックのデータサイズを固定長とした場合、情報が追加されてサイズを超えそうな時には、最上位ノードが監視して、適宜ブロックを分割すれば良い。また、一つの調停ノードが複数のブロックを管理しても構わない。
【００８１】
＜実施例４＞
実施例４では、Ｐ２Ｐネットワーク内の一部のノードが、通信を制限されている場合について述べる。
一般に、ホームネットワークやオフィスネットワークを構築してゲーム機などのノードをインターネットに接続する場合、ＮＡＴ（Network Address Translation）機能を用い
ることがある。このとき、ＮＡＴの設定によっては、ノード間の通信が不可能となる。
【００８２】
設定の一例を図１０に示す。本実施例では、ノードにはオープンノードとストリクトノードの２種類があるものとする。オープンノード同士、または、オープンノードとストリクトノードの間では通信が可能であり、ストリクトノード同士では通信が不可能である。
【００８３】
したがって、一つのセッション内において、セッションオーナはオープンノードであることが好ましい。もしストリクトノードがオーナになると、他のストリクトノードがセッションに参加できなくなる。また、セッションオーナがオープンノードであれば、セッション内の他のノードからのメッセージ（掲示板への書き込み要求や同期情報の更新要求）受信や、他のノードへのメッセージ（同期情報の更新指示）送信が可能であることを保証できる。
【００８４】
また、セッションクラスタ全体においては、オープンノードはなるべく上位の（最上位により近い）セッションに参加し、ストリクトノードはなるべく下位のセッションに参加するよう制御することが好ましい。これにより、セッションクラスタの階層を浅くし、情報伝達のステップ数を減らすことができる。
本実施例の方式によれば、ネットワーク上の事情によりノード間の通信が制限される場合であっても、セッションクラスタ内の情報送受信の性能への影響を抑えることができる。
【符号の説明】
【００８５】
１０１：最上位ノード
１０２，１０４，１０５：接続ノード
１０３：注目ノード
１１１：最上位セッション
１１２〜１１４：下位セッション
【技術分野】
【０００１】
本発明は、情報処理装置がピアツーピア方式で形成するネットワークシステムに関する。
【背景技術】
【０００２】
インターネットのように、情報処理装置が回線を通じて通信を行うネットワークが広く利用されている。例えばゲームの分野においても、通信機能を持つゲーム機等の情報処理装置（以下、「ノード」とも呼ぶ）を操作してネットワーク上で他のノードと通信し、対戦やチャット、情報共有を行うことが普通になっている。そして、かかるネットワークの構成として様々な形態が存在する。
【０００３】
まず一つの構成として、クライアント／サーバ方式がある。この場合、各ノードがクライアントとなり、ネットワークを通じてサーバに処理要求を送信する。処理要求を受信したサーバは、自身の資源を利用して情報処理を行い、必要に応じてノードに情報を送り返す。
【０００４】
しかし、かかるクライアント／サーバ方式では、ネットワークが大規模化するにつれて、サーバの処理能力およびネットワークの負荷の点で問題が生じる。すなわち、クライアント数が増えるとサーバに要求される処理件数も増加し、ユーザへのレスポンスが悪化する。それに対応するためには高性能な情報処理装置を使用する必要があり、結果的にネットワークを運営するコストが増大する。また、クライアント数の増加により通信量が多くなると、データ伝送帯域が増大し、ネットワーク上のボトルネックとなる。このように、クライアント／サーバ方式におけるネットワークの大規模化は、サービス品質の低下や運営コストの増加につながる。
【０００５】
もう一つの構成として、Ｐ２Ｐ（ピアツーピア）方式がある。Ｐ２Ｐ方式においては、ネットワークに参加する各ノードがピアとなり、他のノードと接続して情報を送受信する。Ｐ２Ｐネットワークで提供できるサービスとして、情報の共有、ストリーミングによるデータ配信、メッセージングなどがある（特許文献１、２参照）。Ｐ２Ｐ方式においては、情報処理の負荷が各ノードに分散されることや、ネットワーク伝送経路が分散されることから、上記のクライアント／サーバ方式に比べて個々の情報処理装置の規模を小さくでき、かつ、ネットワークの帯域も抑制できる。したがって、サービスへの参加ノード数の増加した時の拡張性に優れている。さらに、サーバとＰ２Ｐ方式のネットワークと組み合わせてさらなる性能向上を図ることも可能である。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−２６８８４４号公報
【特許文献２】特開２０１０−１０９９７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、Ｐ２Ｐ方式のネットワークにおいて、提供されるサービスに参加可能なノード数が制限される場合がある。かかる制限は、主にサービスを提供するシステム側の都合による。例えば、ゲーム機がノードとなり、Ｐ２Ｐネットワークを形成してオンラインで対戦可能とするサービスについて検討する。なおこれ以降、サービスを受ける際に互いに通信して情報を共有するノード群を「セッション」とも呼ぶ。
【０００８】
ここで、あるゲーム機を用いたサービスでは、一つのセッションに参加可能なノード数を３２台までに制限されているとする。この場合、３３台目以降のノードは同じゲームに参加することができず、大人数でのゲームを享受するための支障となる。また、Ｐ２Ｐ方式の利点の一つである、参加ノード数の増大に対する拡張性を十分に生かせないことになる。
【０００９】
本発明は上記の課題に鑑みてなされたものであり、その目的とするところは、Ｐ２Ｐ方式のネットワークにおいてセッションへの参加ノード数に上限がある場合であっても、当該上限を超えた数のノードで情報共有するための技術を提供することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するために、本発明は以下の構成を採用する。すなわち、Ｍ個（Ｍは２以上の整数）を上限とする複数個のノードにより形成されるノード群であるセッションを複数個含むネットワークシステムであって、同じセッションに参加しているノード同士は互いに情報を送受信することが可能であり、それぞれのセッションは、複数のセッションに参加しているノードである接続ノードを少なくとも一つ含んでおり、前記接続ノードが情報を中継することにより、異なるセッションに参加しているノード同士で情報が送受信されることを特徴とするネットワークシステムである。
【００１１】
このようなネットワークシステムによれば、たとえセッションに参加できるノード数が制限されている場合であっても、接続ノードの中継により、異なるセッションに属するノードの間で情報の送受信が行われる。その結果、上限を超えた数のノードの間で情報の共有が可能になり、Ｐ２Ｐネットワークの利点を多数のユーザが享受することができる。
【００１２】
また、上記のネットワークシステムにおいて、前記ネットワークシステムに参加しているノードは、一つの親ノードにＭ−１個を上限とする子ノードが接続する木構造を形成し、前記セッションは、木構造において上流側に位置する一つの親ノードと、木構造において前記親ノードの下流側に接続する子ノードからなるものであり、前記接続ノードは、当該接続ノードが子ノードとして参加するセッションと、当該接続ノードが親ノードとして参加するセッションとの間で情報を中継するような構成を取ることができる。
このようなネットワークシステムによれば、セッション間の階層構造を単純化することができるので、情報の送受信の方向が明確になる。また、接続ノードによる情報の送受信の回数を抑制することが可能になる。
【００１３】
また、ネットワークシステムが、各ノードが同じデータを保持することにより同じ内容を参照できる電子掲示板を提供する場合、前記電子掲示板に書き込みを追加するノードである注目ノードは、書き込みの内容を含む書き込み要求を、同じセッションに参加するノードに送信し、前記注目ノードと同じセッションに参加するノードは、前記注目ノードからの書き込み要求を受信すると、保持するデータに前記書き込みを行い、前記注目ノードと異なるセッションに参加するノードは、前記接続ノードが中継してきた前記データ書き込み要求を受信して、保持するデータに前記書き込みを行うような構成を取ることができる。
このようなネットワークシステムによれば、上限を超えた数のノードによる、追記式の電子掲示板への書き込みや参照が可能になる。
【００１４】
また、ネットワークシステムが、同じセッションに参加しているノード同士が行う対戦型ゲームの内容を他のノードに伝える観戦システムを提供しており、前記ネットワークシステムに参加しているノードは表示装置を含む場合に、前記対戦型ゲームを行うノードである注目ノードは、ゲームの対戦の状況に関するパラメータを、同じセッションに参加す
るノードに送信し、前記注目ノードと同じセッションに参加するノードは、前記注目ノードからのパラメータを受信して、ユーザが視聴可能な形式で表示装置に表示し、前記注目ノードと異なるセッションに参加するノードは、前記接続ノードが中継してきた前記パラメータを受信して、ユーザが視聴可能な形式で表示装置に表示するような構成を取ることができる。
このようなネットワークシステムによれば、上限を超えた数のノードによる、対戦型ゲームの観戦システムを実現できる。
【００１５】
また、ネットワークシステムが、各ノードが同じ内容の更新可能なデータである同期情報を保持し、いずれかのノードによる更新内容が他のノードにおいて同期されるサービスを提供する場合に、前記ネットワークシステムは、木構造における根ノードを含むセッションである最上位セッションに参加しており、前記同期情報の更新の排他制御を行う調停ノードを含み、前記同期情報を更新するノードである注目ノードは、更新内容を含む更新要求を、前記接続ノードの中継により前記調停ノードに送信し、前記注目ノードからの更新要求を受信した前記調停ノードは、前記ネットワークシステムに参加する各ノードに更新内容を含む更新指示を送信するような構成を取ることができる。
このようなネットワークシステムによれば、調停ノードのみが情報の更新指示を行うことにより排他制御がなされるので、上限を超えた数のノードの間で書き換え可能な情報を共有し、同期が取れた状態にすることができる。
【００１６】
また、ネットワークシステムに参加するノードが通常のノードとストリクトノードを含み、当該ストリクトノード同士では直接的に通信を行うことができない場合に、前記通常のノードが前記セッションの親ノードとなるような構成を取ることができる。
このようなネットワークシステムによれば、ストリクトノードの存在により一部のノード間の通信が制約を受ける場合であっても、ネットワークの木構造の上流と下流の情報伝達を保証できる。
【発明の効果】
【００１７】
本発明によれば、Ｐ２Ｐ方式のネットワークにおいてセッションへの参加ノード数に上限がある場合であっても、当該上限を超えた数のノードで情報共有することが可能になる。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施例１における掲示板への書き込み要求の伝達を説明する模式図である。
【図２】本発明のノードの構成を説明するブロック図である。
【図３】本発明の実施例１における掲示板への書き込み要求の伝達を説明するフローチャートである。
【図４】本発明の実施例１におけるデータ構造を説明する図である。
【図５】本発明の実施例３における同期情報の更新要求の伝達を説明する模式図である。
【図６】本発明の実施例３における同期情報の更新指示の伝達を説明する模式図である。
【図７】本発明の実施例３における同期情報の更新要求の伝達を説明するフローチャートである。
【図８】本発明の実施例３における同期情報の更新指示の伝達を説明するフローチャートである。
【図９】本発明の実施例３の変形例における同期情報のブロックを説明する図である。
【図１０】本発明の実施例４におけるノード間の通信の制限を説明する図である。
【発明を実施するための形態】
【００１９】
本発明は情報処理装置である複数のノードが集まってセッションを形成し、互いに通信を行って構成される、ピアツーピア（Ｐ２Ｐ）方式のネットワークを前提としている。以下、各実施例に共通するノードとセッションの構造について説明する。さらに、複数のセッションの集合であるセッションクラスタについても説明する。セッションクラスタは、本発明における「ネットワークシステム」に相当する。
【００２０】
（ノードの説明）
図２は、各ノードの構成を説明するブロック図である。
以下の実施例において、各ノードはほぼ同程度の処理能力を持つコンピュータ等の情報処理装置を想定している。具体的には、家庭用のゲーム機やＰＣを利用できる。以下の実施例では、ユーザが家庭用のゲーム機を用いて他のユーザと共通のネットワークにログインし、掲示板機能による連絡、ゲームのオンライン対戦や、書き換え可能な情報の共有等を行うシステムを想定している。
【００２１】
ノード２０は、情報処理部２０１、記憶部２０２および通信部２０３を備える。情報処理部２０１は情報処理機能を備えるプロセッサである。情報処理部２０１は、光学ディスクや記憶装置等に格納されたゲームのデータや、ネットワークを経由して取得した他のユーザの行動に関するデータ等に基づいて、ユーザに表示する画像・音声を作成する。情報処理部２０１はまた、ユーザの操作を受け付けて、ゲームの規定に従った処理を行い、必要に応じてノード２０のユーザにフィードバックしたり、他のノードのユーザに情報送信したりする。記憶部２０２はデータの記憶装置であり、例えばＨＤＤ装置やフラッシュメモリを利用できる。
【００２２】
通信部２０３はネットワークを経由して他のノードと情報の送受信を行う通信装置である。ネットワークは他のノードと通信可能なものであれば種類は問わず、ゲームに専用の回線であっても良いし、インターネットのようにオープンな形式でも良い。また有線無線の別も問わない。ここでは、各ノードのネットワーク速度は同程度であるものとする。
【００２３】
ノード２０には、ユーザインターフェースとして表示装置２１と入力装置２２が接続されている。表示装置２１はユーザに情報を提示するためのディスプレイ装置である。表示装置に加えて、ユーザに音声や振動でゲームの進行を伝える装置を設けても良い。入力装置２２はユーザによる操作を受け付ける装置であり、ゲームコントローラやキーボード、マイク等が用いられる。あるいは、ノードが携帯型のゲーム機であれば、ノード本体と表示装置や入力装置が一体となって構成されていても良い。
【００２４】
（ネットワーク構成の説明）
図１（ａ）を用いて、ノードの集合であるセッション、および、セッションの集合であるセッションクラスタの構成例を説明する。
図中の円形は、それぞれがノードを表わす。また、符号１１１、１１２、１１３および１１４で示される円錐はそれぞれ、セッションを模式的に表わしたものである。基本的には、同じセッションに属するノード同士は相互に情報の送受信が可能であるものとする。
【００２５】
セッションに参加できるノードの数は、あらかじめシステムの前提として定められている。この例では、一つのセッションに参加できる上限ノード数は７個である。また、この例では、あるノードが３つ以上のセッションに参加することはないものとしている。ただしこれらの条件は、接続ノードの処理能力やネットワークの帯域に応じて適宜変更できる。
【００２６】
あるセッションに参加しているノードは、もう一つ別のセッションに参加することも可能であり、このようなノードを接続ノードと呼ぶ。図中で言えば、ノード１０２はセッション１１１と１１２に、ノード１０４はセッション１１２と１１３に、ノード１０５はセッション１１１と１１４に、それぞれ重複して参加している。したがって、二つのセッションに参加している接続ノードは、一方のセッションの参加ノードから情報を受信することもできるし、当該受信した情報を、もう一方のセッションの参加ノードに送信することもできる。このように接続ノードが情報を中継してセッションをまたがるノード同士での情報の送受信を実現することにより、本発明のセッションクラスタが形成される。
【００２７】
以下の実施例では、接続ノードが中継するセッションの間には、木構造における上位と下位の概念がある。図中で言えば、セッション１１１が最上位セッションであり、これより上位のセッションは存在しない。セッション１１２とセッション１１４は、最上位セッションに直に接続する下位セッションである。セッション１１３は、セッション１１２のさらに下位に接続している。結局セッションクラスタは、一つの最上位セッションと、それに次々と連なる下位セッションから構成される木構造となっている。このような木構造は、階層構造を単純化でき、情報伝達の方向を明確化できる点で好ましい。特に、ノードの数が増えてくると（例えば１千個〜１万個程度）、階層構造が単純な方が情報の中継回数を少なくできる点で好ましい。
【００２８】
ただしこのような木構造は一例であり、セッションを網目状につないだり、循環的に連結させたりする方法でもセッションクラスタは実現できる。
【００２９】
なお、図１（ａ）は模式図であるため、最上位セッション内のノードで下位セッションを持たないものが存在する。しかし、先に最上位セッション内の全てのノードが下位セッションを持ったことを確認してから、更に下位のセッションを設けるように順序を制御しても良い。これにより、セッション間の中継回数を減少させることができる。
【００３０】
（セッションの形成）
以下の実施例では、セッションは一つのノードがセッションオーナとなって作成し、他のノードが参加することによって形成される。
すなわち、ユーザがゲーム機（ノード）を操作してオンライン機能を利用しようとした時、ノードはネットワーク上に参加できるセッションがあるかどうかを検索する。この検索方法は任意であるが、例えばゲーム機に、サーバを利用したあるいはアドホック機能による既存のマッチングシステムが存在する場合、それを利用すれば良い。ただしサーバを利用した場合であっても、セッションが形成された後はＰ２Ｐ方式で通信が行われる。セッションオーナとなるノードは、ユーザにとっては通常のゲーム機として機能するが、背後ではセッションへのノードの参加などを管理する。
【００３１】
また、セッションクラスタの最上位セッション１１１には、最上位ノード１０１が存在する。最上位ノード１０１は、最上位セッション１１１のセッションオーナでもある。最上位ノードは木構造の根ノードにあたり、最上位セッションは根ノードとその子ノードからなる。
以下の実施例ではまた、下位セッションのセッションオーナは、上位のセッションとの間の接続ノードとなっている。すなわち、セッションオーナは上位のセッションにメンバとして参加している。
このようにすれば、当該セッションが、最上位セッションから連なる木構造の中に参加していることが保証される。具体的に見ると、図中、セッション１１２のセッションオーナであるノード１０２は上位セッション１１１のメンバでもある。
【００３２】
したがって、セッションクラスタ全体でみると、最上位ノードが最上位セッションを作
成し、最上位セッションに参加した各ノードが下位セッションを持つことにより木構造が形成される。言い換えると、あるノードを取りだして親ノードと見た時、そのノードと、そのノードに接続される子ノードが一つのセッションとなる。上位セッションと下位セッションの接続においては、別個に作成されたセッションが所定の方法で接続されても良いし、最上位セッションの参加ノードがセッションを作成し参加者を受け付ける方法でも良い。下位セッションの参加ノードがさらにセッションを作成することで、木構造の枝が成長する。
【００３３】
（ノード離脱）
セッションに参加しているノードが、何らかの理由でＰ２Ｐネットワークから離脱した場合、そのノードの役割に応じて残りのノードの動作は変わる。ノードの離脱は、ノード間の通信が一定時間以上途絶えたことにより検知できる。
セッションオーナではない通常のノードの離脱であれば、特に必要な動作はないが、セッションの参加者数が上限値よりも少なくなるので、セッションクラスタへの参加を希望するノードをより上位のセッションに参加させることができる。
【００３４】
セッションオーナが離脱した場合、セッション内の他のノードが代わりにセッションオーナとなる。新たにセッションオーナになったノードは、上位のセッションとの接続を回復する。どのノードがオーナとなるかは、ノード間の通信によって決定してもよい。あるいは、離脱したセッションオーナが接続ノードとして参加していた上位のセッション内のノードが、当該離脱したノード以外の下位のセッション内のノードの情報を保持している場合、離脱を検知した上位のセッションが指示を出しても良い。
最上位ノードが離脱した場合、最上位セッション内のノードの中から後継を決める。
【００３５】
運営者が存在するネットワークの場合、最上位ノードだけは運営者が維持しておくことにより、セッションクラスタの継続性を増すことができる。この場合であっても、処理能力の高いサーバ機を用意する方式よりも維持コストを減らすことができる。
【００３６】
＜実施例１＞
実施例１では、ゲーム機等のノード同士がＰ２Ｐ方式で形成するネットワークにおいてユーザが利用する掲示板システムについて説明する。ここで掲示板とは、ＢＢＳ(Bulletin Board System)とも呼ばれる電子掲示板を指す。本実施例の掲示板システムは追記型で
あり、各ユーザは情報を書き込んだり、他人の書き込みを読んだり、返信したりすることができる。しかし、書き込みの削除や修正は行われないことを前提とする。かかる掲示板システムを実現するために、本実施例では、特定のサーバを設ける代わりに、セッションクラスタに参加するノードのいずれもが同じコンテンツを保持する方式を取る。
【００３７】
（データ構造）
図４（ａ）は、掲示板のＧＵＩの一例を示す図である。また図４（ｂ）は、掲示板に使用されるデータ構造を示す図である。図４（ｂ）において、各エントリーは掲示板への一つの書き込みに相当する。各エントリーには、書き込みを一意に識別するための個別ＩＤ(MSG_ID)、書き込み日時(TIMESTAMP)、書き込み要求したユーザ(USER_ID)、他の書き込みへの返信であるかどうか、および、返信であれば対象の書き込み(REPLY_TO)、書き込み内容(CONTENT)の各フィールドを持つ。このデータはノードの記憶部２０２に保管される。
ただしこの図に示したデータ構造およびＧＵＩは一例であり、実際には必要に応じて任意に決定することができる。
【００３８】
あるノードが掲示板への書き込み要求を行う時は、まず、入力装置２２によりユーザからの書き込み内容を受け付ける。続いて、情報処理部２０１は、各フィールドの内容を埋めた後、あらかじめ定められたプロトコルに従い、通信部２０３から他のノードに書き込
み要求を送信する。例えば図４（ｂ）の１行目のデータであれば、情報処理部２０１は、ユーザ名とユーザ自身の通し番号からMSG_IDを生成し、現在時刻からTIMESTAMPを入力し
、他のユーザへの返信ではないのでRESPONSE_TOにNULLを入力し、ユーザが書き込む内容
でCONTENTを埋める。
【００３９】
続いて、他のノードは、書き込み要求を通信部２０３で受信すると、その内容を一つのエントリーとして記憶部２０２に保管する。そして、情報処理部２０１は、各フィールドの内容に基づいて、図４（ａ）のように表示装置２１に掲示板を表示する。
【００４０】
（構造）
再度、図１（ａ）を用いて本実施例のセッションクラスタについて述べる。
図中、黒く塗られたノード１０３は、注目ノードである。注目ノード１０３は、セッションクラスタの各ノードに対し、掲示板への書き込みを要求する。注目ノード以外のセッションクラスタの構成要素は上述した通りである。
【００４１】
（処理の流れ）
図３は、処理の全体的な流れを示すフローチャートである。
ステップＳ１０１において、注目ノード１０３が同じセッション１１２に参加しているノードに対して、掲示板への書き込み要求を送信する。
【００４２】
ステップＳ１０２において、書き込み要求を受信したノード（セッション１１２内の各ノード）が、記憶部２０２にエントリーを追加し、表示装置２１の掲示板ＧＵＩを更新する。これにより、セッション１１２内の各ノードの掲示板に書き込みが追記される。本実施例の場合、図１（ｂ）に網掛けで示したノードがこれに相当する。
【００４３】
ステップＳ１０３において、要求を受信したノードは、自身がセッション１１２以外のセッションにも参加しているかどうかを判定する。参加していない場合（Ｓ１０３＝ＮＯ）、そのノードの処理は終了する。参加している場合（Ｓ１０３＝ＹＥＳ）、Ｓ１０４に進む。本実施例の場合、上位のセッション１１１にも参加しているノード１０２と、下位のセッション１１３にも参加しているノード１０４がＹＥＳと判定する。
【００４４】
ステップＳ１０４において、他のセッションにも参加しているノードは、当該他のセッション内のノードに対して、掲示板への書き込みを要求する。本実施例の場合、ノード１０２からセッション１１１内の各ノードに、ノード１０４からセッション１１３内の各ノードに書き込み要求がなされる。
【００４５】
続いて再度ステップＳ１０２に進み、書き込み要求を受信した各ノードが自身の掲示板に追記する。本実施例の場合、図１（ｃ）に網掛けで示したノードの掲示板に書き込みが追記される。
【００４６】
本実施例においては、セッション１１１に参加しているノード１０５は、他のセッション１１４にも参加しているので、再度ステップＳ１０３においてＹＥＳの判定がなされ、セッション１１４内のノードにも書き込み要求が出される。その要求を受信したセッション１１４内のノードが書き込みを追記した結果、図１（ｄ）に示すように、セッションクラスタに参加している全てのノードの掲示板に書き込みが行われた状態になる。
【００４７】
（効果）
本実施例の方式によれば、セッションへの参加ノード数に上限があるＰ２Ｐネットワークにおいて、複数のセッションを一つのセッションクラスタとして扱うことができるようになる。そして、異なるセッションに属するノード間で掲示板のような形式で情報を共有
することが可能となる。これにより、ユーザは自身がどのセッションに参加しているかを意識することなく、ゲームに参加している（セッションクラスタに属する）多数のノード全体を対象として、掲示板への書き込みや返信などを行うことが可能となる。
本実施例の情報送受信の方式は、電子掲示板システムのみではなく、書き換えが起こらない情報を共有するシステム全般に適用可能である。
【００４８】
＜実施例２＞
実施例２では、ゲーム機等のノード同士がＰ２Ｐ方式で形成するネットワークにおける、対戦型ゲームの観戦システムについて説明する。すなわち、セッションクラスタに参加するノードのうちいくつかのノードが対戦型ゲームを行い、他のノードはその模様を観戦するシステムである。
【００４９】
（ゲーム内容）
対戦型ゲームの具体的な例について述べる。ここでは、対戦者は２人のユーザであり、それぞれがノード（ゲーム機）を操作する。この例では、図１（ａ）のセッション１１１に属するノード１０２およびノード１０５が対戦者であるものとする。ゲームの内容は、対戦ユーザのそれぞれに対応する２台の機体がディスプレイに表示され、各ユーザは入力装置を通じて自分の機体を操作し、ゲームのルールが定める所定の条件を満たして対戦相手の撃破を目指すものである。
【００５０】
例えばノード１０２のユーザは、入力装置２２から、機体の移動や相手への攻撃の指示を入力する。ノード１０２の情報処理部２０１は、指示の内容をパラメータ化した後、所定のプロトコルにしたがって通信部２０３から対戦相手のノード１０５に送信する。パラメータの内容は、機体の移動方向や距離、攻撃の手段や方向などである。
【００５１】
対戦相手のノード１０５の情報処理部は、受信したパラメータに基づき、ノード１０２の指示の内容やタイミングを解析する。そして、ノード１０５のユーザが入力した指示の内容と比較し、双方の攻撃の成否やダメージの度合いを判定する。この判定結果は、パラメータ化されてノード１０２にも送信される。したがって、ゲーム開始の時点で通信を行い、互いの機体の位置やダメージの状態などの初期状態を合わせておけば、パラメータをやり取りすることにより、ゲームの現状が対戦者間で共有される。
【００５２】
なお、この例で双方のノードが同じセッションに属することとしたのは、セッションをまたがる通信において接続ノードが情報を中継する際に生じるタイムラグを避けるためである。また、双方のノードが最上位セッション１１１に属することとしたのは、各セッションへの情報伝達時の中継回数を減らすためである。ただし、ゲームの種類、セッションクラスタの規模、ネットワークの速度、および当該ゲームにおける即応性の優先度などを考慮した上で、対戦者を互いに異なるセッションや最上位セッション以外に所属させても構わない。
【００５３】
（観戦システム）
本実施例のセッションクラスタの構成は、実施例１で図１（ａ）を用いて説明したものと同じ構成を取るものとする。かかる観戦システムにおいては、上述したように、対戦者の間でパラメータを次々と送受信することにより、ゲームの最新の状態を共有しながら対戦が行われる。
【００５４】
したがって、対戦者以外のノードがこのパラメータを利用すれば、刻々と変化する対戦の現状を把握することができる。対戦者と同じセッション１１１にあるノードについては、対戦者がセッション内に同報的にパラメータを送信するようにすれば、容易に現状を把握することが可能である。また、対戦者と異なるセッションにあるノードについても、複
数のセッションに参加している接続ノードが受信したパラメータを中継することにより、中継時間分のタイムラグはあるものの、現状を把握することができる。
ここでは２台のゲーム機を用いた対戦型のゲームを例として説明したが、ノードの種類、対戦者の人数、アプリケーションの種類、および、送受信するパラメータの内容などは、Ｐ２Ｐネットワークの目的に応じて任意に設定できることは言うまでもない。
【００５５】
（効果）
本実施例の方式によれば、セッションへの参加ノード数に上限があるＰ２Ｐネットワークで対戦型ゲームが行われる場合であっても、上限数を超えた数のノードが対戦の状況を把握することが可能となる。
【００５６】
（変形例）
本実施例の観戦システムは、単独で用いるだけにとどまらず、実施例１の掲示板システムと組み合わせて利用出来る。すなわち、対戦者間で送受信されるパラメータが接続ノードにより中継されてセッションクラスタ内の各ノードに送信され、対戦の現状を共有するとともに、各ノードが掲示板に書き込んだ内容も中継されて各ノードに表示される、掲示板兼観戦システムである。かかるシステムを用いれば、観戦者が対戦の内容に応じてリアルタイムに感想や応援等を書き込み、情報を共有できる。掲示板のＧＵＩとしては実施例１と同様のウィンドウを用いて、対戦の実況画面の近傍に表示しても良い。あるいは、対戦の実況画面に観戦者の書き込みを重ねて表示しても良い。
【００５７】
＜実施例３＞
実施例３では、ゲーム機等のノード同士がＰ２Ｐ方式で形成するネットワークにおいて、書き換え可能な形で情報を共有する方法について説明する。サーバ／クライアント方式のネットワークであれば、サーバに共有情報を配置して各ノードが書き換え要求を行うようにすれば、排他制御は容易である。一方、Ｐ２Ｐネットワークにおいて書き換え可能な情報を共有するためには、別の方法で排他制御を行う必要がある。
本実施例では、ネットワーク内部に排他制御を担当する「調停ノード」を設けて排他制御を行う方法を説明する。本実施例においても、セッションの参加人数に上限がある場合に、上限値を超えた数のノードでの処理を実現する点は、実施例１、２と共通する。
【００５８】
（データ構造）
サーバを用いない本実施例の方式では、情報を共有するといっても、実際に同じメモリ領域にあるデータの構造体などにアクセスして読み書きするわけではない。その代わりに、セッションクラスタ内の各ノードが同じ内容の情報を保持し、同期して書き換えることにより、同じデータを共有しているのと同じ状態にする。以下、このような情報のことを「同期情報」とも記載する。更新に際しては、現在の内容との差分情報ではなく、同期情報の全体を送受信することが、ノード内での整合性を保証できる点で好ましい。
【００５９】
（セッションクラスタの構成）
本実施例においても、各ノードの構成は、図２を用いて上で説明したものと同様である。
また、セッションおよびセッションクラスタの構成も、基本的には上で説明したものと同様である。図５が本実施例のセッションおよびセッションクラスタの構成である。符号３１１、３１２、３１３および３１４で示される円錐はそれぞれセッションを示す。セッション内のノード同士は互いのネットワーク上の位置情報を保持しており、通信可能な状態である。
【００６０】
最上位ノード３０１は、最上位セッション３１１のセッションオーナである。
本実施例の最上位ノードは、最上位セッション内のノードから１つの調停ノードを選ぶ
ものとする。ここではノード３０５が調停ノードとなる。調停ノードがＰ２Ｐネットワークから離脱した場合、最上位ノードが速やかに次の調停ノードを選択する。
【００６１】
本実施例では、セッションクラスタ内に１つの調停ノードが存在する。そして、ノードからの同期情報の更新要求の内容を、各ノードへの更新指示として送信する。その際、複数のノードから更新要求があった場合など、必要があれば排他制御を行う。これにより、最新の情報が明確になる。
【００６２】
ノード３０２は、最上位セッション３１１および注目ノードを含むセッション３１２の両方に参加しているノードであり、双方の接続ノードとして機能する。
注目ノード３０３は、各ノードの情報の更新を要求するノードである。
ノード３０４は、セッション３１２および下位セッション３１３の両方に参加しており、双方の接続ノードとして機能する。このようにセッション３１１〜３１４は接続ノードがメッセージを中継することにより接続されており、全体で一つのセッションクラスタを構成していると言える。
【００６３】
なお、図５（ａ）、図５（ｂ）、図６（ａ）、図６（ｂ）および図６（ｃ）において、網掛けで示したノードは、注目ノードからの更新要求メッセージを受け取ったノードである。また、黒く塗ったノードは、同期情報が更新されたノードである。
【００６４】
（更新要求の受付）
図７は、注目ノードからの更新要求を調停ノードが受け付けるまでの流れを示すフローチャートである。図５（ａ）、図５（ｂ）は、このときのセッションクラスタの様子である。
ステップＳ３０１において、注目ノード３０３が同じセッション３１２に参加しているノードに対して、更新要求を含むメッセージを送信する。このメッセージには、更新対象の情報と、更新内容が含まれる。このとき、図５（ａ）に示すように、セッション３１２に属するノードは更新要求メッセージを保持している。
【００６５】
ステップＳ３０２において、書き込み要求を受信したノードは、自身が調停ノードかどうかを判定する。ここで、セッション３１２内の各ノードは調停ノードではない（Ｓ３０２＝ＮＯ）ので、ステップＳ３０３に進む。
【００６６】
ステップＳ３０３において、調停ノードでないと判断されたノードは、自身が上位セッションにも参加しているかどうかを判定する。この処理は、上位セッションがなくなるまで、すなわち最上位セッションに到達するまで繰り返される。本実施例では、ノード３０２が上位のセッション３１１にも参加している（Ｓ３０３＝ＹＥＳ）ので、ステップＳ３０４に進む。一方、ノード３０２以外のノードは上位セッションに参加していない（Ｓ３０３＝ＮＯ）ので、処理を終了する。
なお、ここで上位セッションへの参加の有無のみ判定し、下位セッションについて判定していないのは、本実施例においては調停ノードを最上位セッションに配置したためである。
【００６７】
ステップＳ３０４において、ノード３０２は、上位のセッション３１１内のノードに更新要求を送信する。このとき、図５（ｂ）に示すように、セッション３１１および３１２に属するノードは更新要求メッセージを保持している。ただし、Ｓ３０３の後で、ノード３０２以外のノードは更新要求メッセージを破棄しても構わない。
続いて、再度ステップＳ３０２の判定が行われる。ここで、ノード３０５は、最上位セッション３１１に属する調停ノードである（Ｓ３０２＝ＹＥＳ）ため、更新要求の制御処理に進む。
【００６８】
（更新指示の反映）
図８は、更新要求を受け付けた調停ノードが、セッションクラスタ内の各ノードに対して同期情報の更新指示を行う際のフローチャートである。図６（ａ）、図６（ｂ）および図６（ｃ）は、このときのセッションクラスタの様子である。
【００６９】
ステップＳ４０１において、調停ノード３０５が、自身の同期情報を更新するとともに、自身が参加しているセッション（本実施例ではセッション３１１および３１４）内に更新指示のメッセージを送信する。このときの様子を図６（ａ）に示す。
このステップで調停ノードが複数のノードからの更新要求を受け付けた場合、要求を受け付けた順序が早い方を選択する等の排他制御を行う。この場合、もう片方のノードが、自身の更新要求が受け付けられなかったことを知るために、タイムアウトを検知する方法を取ることができる。すなわち、更新要求を出してから一定時間が経過しても要求内容に従った更新指示が受信できない場合、更新が失敗したと認識できる。
【００７０】
ステップＳ４０２において、更新指示を受信したノードは、その内容にしたがって、記憶部２０２に保管されている同期情報を更新する。このときの様子を図６（ｂ）に示す。
【００７１】
ステップＳ４０３において、同期情報を更新したノードは、自身が他のセッション（更新指示を送信してきたノードとは別のセッション）にも参加しているかどうかを判定する。参加していない場合（Ｓ４０３＝ＮＯ）、そのノードの処理は終了する。参加している場合（Ｓ４０３＝ＹＥＳ）、Ｓ４０４に進む。本実施例の場合、セッション３１２にも参加しているノード３０２が該当する。
【００７２】
ステップＳ４０４において、他のセッションにも参加しているノードは、当該他のセッション内のノードに対して更新指示のメッセージを送信する。本実施例の場合、ノード３０２からセッション３１２内の各ノードに更新が指示される。
【００７３】
以下同様に、下位のセッションとの接続ノードが更新指示を伝達することにより、セッションクラスタ内のすべてのノードの同期情報が更新される。最終的に、図６（ｃ）に示すように、セッション内のすべてのノードの同期情報が、注目ノード３０３からの要求にしたがって更新される。
【００７４】
（効果）
本実施例の方式によれば、セッションへの参加ノード数に上限があるＰ２Ｐネットワークにおいて、複数のセッションを一つのセッションクラスタとして扱い、ノード間で情報を共有したり、同期して更新したりすることが可能となる。さらに、かかる同期情報を用いて各ノードが恊働して情報処理を行うこともできる。
【００７５】
なお、本実施例では、調停ノードは最上位セッションにあるものとしたので、更新要求や更新指示のメッセージが流れる方向を単純化することが可能となっているが、必ずしもこの必要はない。
【００７６】
また、セッションクラスタ内の適切な場所に、最新の同期情報をバックアップするノードを設けても良い。そして、調停ノードからの更新指示をまずバックアップノードに反映し、その後各ノードに更新指示を出すようにする。これにより、調停ノードがセッションクラスタから離脱したときなどに、同期情報を復元することができる。バックアップノードは調停ノードとネットワーク上の近い位置（例えば、同じセッション内）にあることが好ましい。さらに、このようなバックアップを複数の世代にわたって保存することにより、同期情報のロールバックに利用することもできる。
【００７７】
（変形例１）
上の記載では、図７のフローチャートのステップＳ３０１において、注目ノード３０３は、セッション３１２内の全てのノードに更新要求を送信している。しかし、セッション３１２から上位のセッションへの接続ノードはノード３０２だとあらかじめ分かっていれば、ノード３０２にのみ更新要求を送信すれば良い。
【００７８】
また上の記載では、接続ノード３０２は、最上位セッション３１１内の全てのノードに更新要求を中継している。しかし、最上位セッション３１１内のノードが、自身は最上位セッションにいること、および、調停ノードはノード３０５だということをあらかじめ分かっていれば、ノード３０５にのみ更新要求を中継すれば良い。どのノードが調停ノードであるかは、最上位ノードから各メンバへの通知により知ることができる。
このような本変形例の構成は、セッション内の全ノードに同報通信をする場合に比べて、情報伝達時のネットワーク負荷を抑制することができる点で好ましい。
【００７９】
（変形例２）
上の記載では調停ノードは一つだけとなっている。しかしこの場合、全てのノードからの更新要求を一つのノードで処理するため、ノードの処理能力を超えて処理が遅延する可能性がある。また、ネットワークの負荷が一つの調停ノードに集中する。さらに、複数のノードからの更新要求が衝突する可能性が高まり、排他制御が行われる結果、更新が実現されない確率が増える。
【００８０】
そこで、図９に示すように、共有情報を複数のブロックに分割し、それぞれのブロックの排他制御を別々の調停ノードに担当させることにより、処理の負担を分散させることが考えられる。
共有情報をブロックに分割する基準としては、データの内容、サイズ、使用目的など、状況に応じて定めることができる。また分割する際には、最上位ノードが各ブロックの内容および排他制御を担当する調停ノードを指定すれば良い。また、ブロックのデータサイズを固定長とした場合、情報が追加されてサイズを超えそうな時には、最上位ノードが監視して、適宜ブロックを分割すれば良い。また、一つの調停ノードが複数のブロックを管理しても構わない。
【００８１】
＜実施例４＞
実施例４では、Ｐ２Ｐネットワーク内の一部のノードが、通信を制限されている場合について述べる。
一般に、ホームネットワークやオフィスネットワークを構築してゲーム機などのノードをインターネットに接続する場合、ＮＡＴ（Network Address Translation）機能を用い
ることがある。このとき、ＮＡＴの設定によっては、ノード間の通信が不可能となる。
【００８２】
設定の一例を図１０に示す。本実施例では、ノードにはオープンノードとストリクトノードの２種類があるものとする。オープンノード同士、または、オープンノードとストリクトノードの間では通信が可能であり、ストリクトノード同士では通信が不可能である。
【００８３】
したがって、一つのセッション内において、セッションオーナはオープンノードであることが好ましい。もしストリクトノードがオーナになると、他のストリクトノードがセッションに参加できなくなる。また、セッションオーナがオープンノードであれば、セッション内の他のノードからのメッセージ（掲示板への書き込み要求や同期情報の更新要求）受信や、他のノードへのメッセージ（同期情報の更新指示）送信が可能であることを保証できる。
【００８４】
また、セッションクラスタ全体においては、オープンノードはなるべく上位の（最上位により近い）セッションに参加し、ストリクトノードはなるべく下位のセッションに参加するよう制御することが好ましい。これにより、セッションクラスタの階層を浅くし、情報伝達のステップ数を減らすことができる。
本実施例の方式によれば、ネットワーク上の事情によりノード間の通信が制限される場合であっても、セッションクラスタ内の情報送受信の性能への影響を抑えることができる。
【符号の説明】
【００８５】
１０１：最上位ノード
１０２，１０４，１０５：接続ノード
１０３：注目ノード
１１１：最上位セッション
１１２〜１１４：下位セッション
【特許請求の範囲】
【請求項１】
Ｍ個（Ｍは２以上の整数）を上限とする複数個のノードにより形成されるノード群であるセッションを複数個含むネットワークシステムであって、
同じセッションに参加しているノード同士は互いに情報を送受信することが可能であり、
それぞれのセッションは、複数のセッションに参加しているノードである接続ノードを少なくとも一つ含んでおり、
前記接続ノードが情報を中継することにより、異なるセッションに参加しているノード同士で情報が送受信される
ことを特徴とするネットワークシステム。
【請求項２】
前記ネットワークシステムに参加しているノードは、一つの親ノードにＭ−１個を上限とする子ノードが接続する木構造を形成し、
前記セッションは、木構造において上流側に位置する一つの親ノードと、木構造において前記親ノードの下流側に接続する子ノードからなるものであり、
前記接続ノードは、当該接続ノードが子ノードとして参加するセッションと、当該接続ノードが親ノードとして参加するセッションとの間で情報を中継するものである
ことを特徴とする請求項１に記載のネットワークシステム。
【請求項３】
前記ネットワークシステムは、各ノードが同じデータを保持することにより同じ内容を参照できる電子掲示板を提供するものであり、
前記電子掲示板に書き込みを追加するノードである注目ノードは、書き込みの内容を含む書き込み要求を、同じセッションに参加するノードに送信し、
前記注目ノードと同じセッションに参加するノードは、前記注目ノードからの書き込み要求を受信すると、保持するデータに前記書き込みを行い、
前記注目ノードと異なるセッションに参加するノードは、前記接続ノードが中継してきた前記データ書き込み要求を受信して、保持するデータに前記書き込みを行う
ことを特徴とする請求項２に記載のネットワークシステム。
【請求項４】
前記ネットワークシステムは、同じセッションに参加しているノード同士が行う対戦型ゲームの内容を他のノードに伝える観戦システムを提供するものであり、
前記ネットワークシステムに参加しているノードは表示装置を含み、
前記対戦型ゲームを行うノードである注目ノードは、ゲームの対戦の状況に関するパラメータを、同じセッションに参加するノードに送信し、
前記注目ノードと同じセッションに参加するノードは、前記注目ノードからのパラメータを受信して、ユーザが視聴可能な形式で表示装置に表示し、
前記注目ノードと異なるセッションに参加するノードは、前記接続ノードが中継してきた前記パラメータを受信して、ユーザが視聴可能な形式で表示装置に表示する
ことを特徴とする請求項２に記載のネットワークシステム。
【請求項５】
前記ネットワークシステムは、各ノードが同じ内容の更新可能なデータである同期情報を保持し、いずれかのノードによる更新内容が他のノードにおいて同期されるサービスを提供するものであり、
前記ネットワークシステムは、木構造における根ノードを含むセッションである最上位セッションに参加しており、前記同期情報の更新の排他制御を行う調停ノードを含み、
前記同期情報を更新するノードである注目ノードは、更新内容を含む更新要求を、前記接続ノードの中継により前記調停ノードに送信し、
前記注目ノードからの更新要求を受信した前記調停ノードは、前記ネットワークシステムに参加する各ノードに更新内容を含む更新指示を送信する
ことを特徴とする請求項２に記載のネットワークシステム。
【請求項６】
前記ネットワークシステムに参加するノードが通常のノードとストリクトノードを含み、当該ストリクトノード同士では直接的に通信を行うことができない場合に、
前記通常のノードが前記セッションの親ノードとなる
ことを特徴とする請求項２ないし５のいずれか１項に記載のネットワークシステム。
【請求項１】
Ｍ個（Ｍは２以上の整数）を上限とする複数個のノードにより形成されるノード群であるセッションを複数個含むネットワークシステムであって、
同じセッションに参加しているノード同士は互いに情報を送受信することが可能であり、
それぞれのセッションは、複数のセッションに参加しているノードである接続ノードを少なくとも一つ含んでおり、
前記接続ノードが情報を中継することにより、異なるセッションに参加しているノード同士で情報が送受信される
ことを特徴とするネットワークシステム。
【請求項２】
前記ネットワークシステムに参加しているノードは、一つの親ノードにＭ−１個を上限とする子ノードが接続する木構造を形成し、
前記セッションは、木構造において上流側に位置する一つの親ノードと、木構造において前記親ノードの下流側に接続する子ノードからなるものであり、
前記接続ノードは、当該接続ノードが子ノードとして参加するセッションと、当該接続ノードが親ノードとして参加するセッションとの間で情報を中継するものである
ことを特徴とする請求項１に記載のネットワークシステム。
【請求項３】
前記ネットワークシステムは、各ノードが同じデータを保持することにより同じ内容を参照できる電子掲示板を提供するものであり、
前記電子掲示板に書き込みを追加するノードである注目ノードは、書き込みの内容を含む書き込み要求を、同じセッションに参加するノードに送信し、
前記注目ノードと同じセッションに参加するノードは、前記注目ノードからの書き込み要求を受信すると、保持するデータに前記書き込みを行い、
前記注目ノードと異なるセッションに参加するノードは、前記接続ノードが中継してきた前記データ書き込み要求を受信して、保持するデータに前記書き込みを行う
ことを特徴とする請求項２に記載のネットワークシステム。
【請求項４】
前記ネットワークシステムは、同じセッションに参加しているノード同士が行う対戦型ゲームの内容を他のノードに伝える観戦システムを提供するものであり、
前記ネットワークシステムに参加しているノードは表示装置を含み、
前記対戦型ゲームを行うノードである注目ノードは、ゲームの対戦の状況に関するパラメータを、同じセッションに参加するノードに送信し、
前記注目ノードと同じセッションに参加するノードは、前記注目ノードからのパラメータを受信して、ユーザが視聴可能な形式で表示装置に表示し、
前記注目ノードと異なるセッションに参加するノードは、前記接続ノードが中継してきた前記パラメータを受信して、ユーザが視聴可能な形式で表示装置に表示する
ことを特徴とする請求項２に記載のネットワークシステム。
【請求項５】
前記ネットワークシステムは、各ノードが同じ内容の更新可能なデータである同期情報を保持し、いずれかのノードによる更新内容が他のノードにおいて同期されるサービスを提供するものであり、
前記ネットワークシステムは、木構造における根ノードを含むセッションである最上位セッションに参加しており、前記同期情報の更新の排他制御を行う調停ノードを含み、
前記同期情報を更新するノードである注目ノードは、更新内容を含む更新要求を、前記接続ノードの中継により前記調停ノードに送信し、
前記注目ノードからの更新要求を受信した前記調停ノードは、前記ネットワークシステムに参加する各ノードに更新内容を含む更新指示を送信する
ことを特徴とする請求項２に記載のネットワークシステム。
【請求項６】
前記ネットワークシステムに参加するノードが通常のノードとストリクトノードを含み、当該ストリクトノード同士では直接的に通信を行うことができない場合に、
前記通常のノードが前記セッションの親ノードとなる
ことを特徴とする請求項２ないし５のいずれか１項に記載のネットワークシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１２−８８９６０（Ｐ２０１２−８８９６０Ａ）
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願番号】特願２０１０−２３５５４８（Ｐ２０１０−２３５５４８）
【出願日】平成２２年１０月２０日（２０１０．１０．２０）
【出願人】（３９９１１３９０５）株式会社フロム・ソフトウェア (3)
【Ｆターム（参考）】
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願日】平成２２年１０月２０日（２０１０．１０．２０）
【出願人】（３９９１１３９０５）株式会社フロム・ソフトウェア (3)
【Ｆターム（参考）】
[ Back to top ]