JP4284993B2 - 通信システムおよび方法 - Google Patents
通信システムおよび方法 Download PDFInfo
- Publication number
- JP4284993B2 JP4284993B2 JP2002366519A JP2002366519A JP4284993B2 JP 4284993 B2 JP4284993 B2 JP 4284993B2 JP 2002366519 A JP2002366519 A JP 2002366519A JP 2002366519 A JP2002366519 A JP 2002366519A JP 4284993 B2 JP4284993 B2 JP 4284993B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- server
- group
- message
- transmitted
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【発明の属する技術分野】
本発明は、通信システムおよび方法に関し、ネットワークの動的な変化に、より好適に対応できるようにする通信システムおよび方法に関する。
【0002】
【従来の技術】
近年、IEEE(Institute of Electrical and Electronics Engineers)802.11bに準拠した無線LAN(Local Area Network)やBluetooth(登録商標)に代表される各種の無線通信技術に対応した機器が急速に普及しつつある。
【0003】
また、そのような無線通信により実現されるネットワークにおいて、固定のサーバが設けられていない場合であっても、集合した複数の端末のうちの1台がサーバとなり、他の端末との間でサーバ・クライアントモデルのアプリケーションを実行する技術が各種提案されている。
【0004】
この場合、サーバから提供されるサービスをクライアントが利用し続けるためには、例えば、サーバ機能を提供していた端末が、他の端末に対して何の予告もなくネットワークから離脱した場合に対応するための技術が必要となる。
【0005】
そこで、そのような技術として、例えば、下記特許文献1には、全てのクライアントにおいて、サーバ候補である端末の情報が記述されたリストを管理し、サーバ機能を提供していた端末がネットワークから離脱した場合であっても、他のクライアントがサーバ機能を引き継ぐことができる技術が開示されている。
【0006】
【特許文献1】
特開2000−215177号公報
【0007】
【発明が解決しようとする課題】
しかしながら、例えば、特許文献1に開示されている技術によっては、複数の端末が同時に通信不可能な状態になった場合(サーバが通信不可能な状態になると同時に、サーバを引き継ぐ端末も通信不可能な状態になった場合)に、サーバの引き継ぎをスムーズに行うことが困難であるという課題があった。
【0008】
この課題は、ネットワークのユビキタス化が進み、容易に、かつ、任意のタイミングで、様々な機器と通信を行うことができるようになるにつれ、さらに顕著なものになるおそれがある。例えば、そのような環境においては、それぞれの端末のユーザは、自分自身の端末が通信可能な状態か、不可能な状態かを意識することなく、移動しながら好みの場所で通信を行おうとすることが予想され、その結果、複数の端末が同時に通信不可能になるなど、ネットワークの構成が頻繁に変化することになる。
【0009】
本発明はこのような状況に鑑みてなされたものであり、ネットワークの動的な変化に、より好適に対応できるようにするものである。
【0010】
【課題を解決するための手段】
本発明の通信システムは、複数の情報処理装置が無線ネットワークを介して接続されることによって構成される通信システムにおいて、サーバとして機能する1つの情報処理装置は、所定の周期で、自身が管理するグループにクライアントとして属する全ての情報処理装置に対して、設定した各クライアントの優先順位を含むメッセージであるグループ告知メッセージを送信し、クライアントとして機能する各情報処理装置は、サーバとして機能する情報処理装置から送信されてきた前記グループ告知メッセージを受信し、サーバとして機能する情報処理装置から送信されるべき前記グループ告知メッセージが送信されてこないことによって、サーバとして機能する情報処理装置の離脱が発生したことを判断し、自身の優先順位を含む、自身がサーバ候補であることを通知するメッセージであるサーバ候補告知メッセージをクライアントとして機能する他の全ての情報処理装置に対して送信し、クライアントとして機能する他の全ての情報処理装置から送信されてきた前記サーバ候補告知メッセージを受信し、自身に対して設定された優先順位と、受信した前記サーバ候補告知メッセージに含まれる他の情報処理装置に設定された優先順位とを比較し、最も高い優先順位が設定されている情報処理装置は、新たにサーバとして機能するように状態を遷移させ、自身の情報のみが記述されたメッセージであるサーバ移動通知メッセージを送信し、自身が管理するグループにクライアントとして属する全ての情報処理装置に対して、各クライアントの優先順位を含むメッセージである前記グループ告知メッセージを送信し、前記サーバ移動通知メッセージを受信したクライアントとして機能する情報処理装置は、新たにサーバとして機能する情報処理装置から送信されてきた前記グループ告知メッセージを受信する。
【0012】
本発明の通信システムの通信方法は、複数の情報処理装置が無線ネットワークを介して接続されることによって構成される通信システムの通信方法において、サーバとして機能する1つの情報処理装置が、所定の周期で、自身が管理するグループにクライアントとして属する全ての情報処理装置に対して、設定した各クライアントの優先順位を含むメッセージであるグループ告知メッセージを送信し、クライアントとして機能する各情報処理装置が、サーバとして機能する情報処理装置から送信されてきた前記グループ告知メッセージを受信し、サーバとして機能する情報処理装置から送信されるべき前記グループ告知メッセージが送信されてこないことによって、サーバとして機能する情報処理装置の離脱が発生したことを判断し、自身の優先順位を含む、自身がサーバ候補であることを通知するメッセージであるサーバ候補告知メッセージをクライアントとして機能する他の全ての情報処理装置に対して送信し、クライアントとして機能する他の全ての情報処理装置から送信されてきた前記サーバ候補告知メッセージを受信し、自身に対して設定された優先順位と、受信した前記サーバ候補告知メッセージに含まれる他の情報処理装置に設定された優先順位とを比較し、最も高い優先順位が設定されている情報処理装置が、新たにサーバとして機能するように状態を遷移させ、自身の情報のみが記述されたメッセージであるサーバ移動通知メッセージを送信し、自身が管理するグループにクライアントとして属する全ての情報処理装置に対して、各クライアントの優先順位を含むメッセージである前記グループ告知メッセージを送信し、前記サーバ移動通知メッセージを受信したクライアントとして機能する情報処理装置が、新たにサーバとして機能する情報処理装置から送信されてきた前記グループ告知メッセージを受信する。
【0028】
本発明の通信システムおよび方法においては、サーバとして機能する1つの情報処理装置により、所定の周期で、自身が管理するグループにクライアントとして属する全ての情報処理装置に対して、設定した各クライアントの優先順位を含むメッセージであるグループ告知メッセージが送信され、クライアントとして機能する各情報処理装置により、サーバとして機能する情報処理装置から送信されてきた前記グループ告知メッセージが受信される。サーバとして機能する情報処理装置から送信されるべき前記グループ告知メッセージが送信されてこないことによって、サーバとして機能する情報処理装置の離脱が発生したことが判断され、自身の優先順位を含む、自身がサーバ候補であることを通知するメッセージであるサーバ候補告知メッセージがクライアントとして機能する他の全ての情報処理装置に対して送信され、クライアントとして機能する他の全ての情報処理装置から送信されてきた前記サーバ候補告知メッセージが受信される。また、自身に対して設定された優先順位と、受信された前記サーバ候補告知メッセージに含まれる他の情報処理装置に設定された優先順位とが比較され、最も高い優先順位が設定されている情報処理装置により、新たにサーバとして機能するように状態が遷移され、自身の情報のみが記述されたメッセージであるサーバ移動通知メッセージが送信され、自身が管理するグループにクライアントとして属する全ての情報処理装置に対して、各クライアントの優先順位を含むメッセージである前記グループ告知メッセージが送信される。前記サーバ移動通知メッセージを受信したクライアントとして機能する情報処理装置により、新たにサーバとして機能する情報処理装置から送信されてきた前記グループ告知メッセージが受信される。
【0032】
【発明の実施の形態】
図1は、本発明を適用した通信システムの構成例を示す図である。
【0033】
ネットワーク4は、IEEE(Institute of Electrical and Electronics Engineers)802.11bに準拠した無線LAN(Local Area Network)やBluetooth(登録商標)のPAN(Personal Area Network)プロファイルなどにより実現される無線ネットワーク、或いは、有線のネットワークであり、このネットワーク4を介して、各種の機器の間で通信が行われる。
【0034】
図1の例においては、ネットワーク4には、パーソナルコンピュータやPDA(Personal Digital Assistants)などよりなるノード1乃至ノード3が接続されている。
【0035】
ノード1乃至ノード3のそれぞれは、例えば、ネットワーク4に接続された他のノードに対して所定のサービスを提供する「サーバ」と、サーバが提供するサービスを利用する「クライアント」の両方の機能を有する。以下、適宜、サーバの機能を実現する、後述する「正式サーバ」の状態を有するノード(情報管理装置)を単にサーバと称し、クライアントの機能を実現するノード(情報処理装置)を単にクライアントと称する。
【0036】
所定のサーバと、そのサーバにより提供されるサービスを利用するクライアントにより「グループ」が構成される。所定のノードがグループに所属し、サーバにより提供されるサービスが利用可能になったとき、そのノードは、「グループ」に参加した状態となる。
【0037】
図1の例においては、ノード1乃至ノード3によりグループが構成され、ノード1がサーバとして提供する所定のサービスを、クライアントとしてのノード2、およびノード3が利用している。
【0038】
なお、サーバは、サーバ機能と同時に、クライアントの機能を実現することも可能である。また、図1においては、ノード1乃至ノード3の3つのノードが図示されているが、これ以外にも、さらに多数のノードがネットワーク4に適宜接続される。
【0039】
図2は、図1のノード1の構成例を示すブロック図である。
【0040】
ノード1は、例えば、演算処理部11と通信部12から構成される。
【0041】
演算処理部11は、例えば、パーソナルコンピュータのCPU(Central Processing Unit)などにより構成され、通信部12は、IEEE802.11a,802.11bに準拠した無線通信機能を備えるLANインタフェースボードなどにより構成される。
【0042】
通信部12は、ネットワーク4に接続され、演算処理部11の制御に基づいて、それぞれのノードとの間でIPマルチキャストの通信を行う。通信部12により取得された、他のノードから送信されてきたデータは、演算処理部11に出力される。
【0043】
なお、図2は、ノード1を実現するための最小限の構成について図示したものであり、ノード1は、例えば、図3に示されるように、マウスやキーボードなどよりなる入力部、および、ディスプレイやスピーカなどよりなる出力部などを含む、ユーザインタフェース部13を備えるようにすることもできる。
【0044】
図4は、図2のノード1の機能構成例を示すブロック図である。図4の各機能部は、図2の演算処理部11により所定のプログラムが実行されて実現される。
【0045】
通信機能部21は、図2の通信部12を制御し、ネットワーク4上に存在する他のノードと通信する機能を有する。通信機能部21により、グループ管理機能部22、サーバ機能部23、クライアント機能部24に対して通信機能が提供される。
【0046】
具体的には、通信機能部21は、グループ管理機能部22、サーバ機能部23、クライアント機能部24に対して、「ノードID」と称される識別子により指定されたノードに任意のメッセージを送信する機能、および、所定のノードから送信されてきたメッセージを受信する機能を提供する。
【0047】
通信機能部21からは、例えば、他のノードに対して所定のメッセージがマルチキャスト送信される。ここで、マルチキャスト送信とは、同一のサービスに参加している、または、参加しようとしているコンピュータ(ノード)全てに、同一のメッセージを送信することをいう。
【0048】
グループ管理機能部22は、同一のネットワーク(例えば、ネットワーク4)に接続された、他のノードと各種のメッセージを交換することにより、グループを形成し、維持する機能を有する。グループ管理機能部22は、例えば、メッセージ管理部22A、状態管理部22B、および、リスト管理部22Cを有している。
【0049】
グループ管理機能部22のメッセージ管理部22Aは、メッセージの生成、および、メッセージの送受信を管理する。
【0050】
グループ管理機能部22の状態管理部22Bは、ノード1が参加しているグループにおける自分自身の状態を管理する。グループ管理機能部22により管理される状態には、例えば、「初期状態」、「サーバ候補A」、「サーバ候補B」、「正式サーバ」、「未参加」、「参加」、「離脱」の7つの状態があり、そのときの状況に応じて、状態の遷移が行われる。
【0051】
例えば、グループ管理機能部22の状態管理部22Bは、「サーバ機能」を提供するノードがネットワーク4上に存在しない場合、自分自身の状態を「正式サーバ」に遷移させ、ネットワーク4に接続されている他のノードに「サーバ機能」を提供する。
【0052】
グループ管理機能部22のリスト管理部22Cは、グループに参加している「ノード」をリストで管理する。このリストの先頭に示されるノードが「サーバ」であり、それ以外のノードがクライアントである。
【0053】
リストは、全てのノードにより管理され、サーバにより常にアップデートされる。すなわち、最新のリストが、サーバからクライアントに対して所定の周期で配布され、それぞれのクライアントが有するリストが更新される。
【0054】
サーバ機能部23は、通信機能部21と協働し、1つ、または複数のクライアントと通信を行い、サーバ・クライアント型の所定のサービスを提供する機能を有する。サーバ機能部23は、例えば、コンピュータソフトウェアにより実現される。
【0055】
サーバ機能部23は、例えば、演算処理部11によりサービスの利用が開始されたときに起動し、クライアントからのメッセージと内部状態に基づいて、所定の演算を行い、演算結果を内部状態に反映させるとともに、結果の全部または一部を、クライアントに返すなどの処理を行う。
【0056】
例えば、クライアント機能部24は、通信機能部21と協働し、所定のノードにより実現されるサーバと通信を行い、サーバにより提供されるサーバ・クライアント型のサービスを受ける機能、および、サーバからのサービスを受け、適宜、ユーザインタフェースを介して、ユーザからの操作を受け付けたり、ユーザに所定の情報を提示するなどの機能を有する。
【0057】
なお、ノード2、およびノード3は、ノード1と同様の構成を有している。図2乃至図4に示されるノード1の構成は、必要に応じて、ノード2、およびノード3の構成としても引用される。
【0058】
図5は、グループ管理機能部22の状態管理部22Bにより管理される状態遷移の例を示す図である。
【0059】
初期状態(State1)は、グループに参加しようとするノードの状態を表す。初期状態のノードは、既に存在するグループのサーバから送信されるグループ告知メッセージを所定期間内に受信することができなかった場合、自分自身の状態をサーバ候補A(State2)に遷移させる。
【0060】
後述するように、グループに存在するサーバからは、グループ告知メッセージが所定周期でマルチキャスト送信されている。従って、所定の時間経過したにも関わらず、グループ告知メッセージが送信されてこない場合、それは、参加しようとしているグループに、サーバが存在しない可能性があることを表している。
【0061】
サーバ候補A(State2)は、サーバが存在しない可能性があるときに遷移される状態である。サーバ候補Aのノードは、自分自身のサーバ候補としての順位を含むサーバ候補告知メッセージを他のノードに送信する。
【0062】
サーバ候補Aのノードは、サーバ候補告知メッセージを送信してから所定の時間経過した場合、或いは、自分自身が、他のサーバ候補(サーバ候補Aまたはサーバ候補B)のノードよりも高い優先順位が設定されているノードであると判断した場合、その状態を、正式サーバ(State4)に遷移させる。
【0063】
一方、他のサーバ候補のノードから送信されてくるサーバ候補告知メッセージにより、自分自身よりも高い優先順位を有するノードが他に存在すると判定した場合、または、サーバから送信されるグループ告知メッセージを受信した場合、サーバ候補Aのノードは、その状態を未参加(State3)に遷移させる。
【0064】
初期状態(State1)のノードは、初期状態となってから所定の時間内にグループ告知メッセージを受信した場合、或いは、サーバ候補Aまたはサーバ候補Bのノードから送信されるサーバ候補告知メッセージを受信した場合、その状態を未参加(State3)に遷移させる。
【0065】
未参加(State3)は、未だグループに参加していない状態を表す。未参加のノードは、グループ内に存在するサーバに対してノード参加要求メッセージを送信し、それに応じて、サーバからノード参加承認メッセージが返信されてきた場合、または、サーバにより送信されるグループ告知メッセージに格納されるノードリストに、自分自身のノードが存在する場合、その状態を参加(State5)に遷移させる。
【0066】
参加(State5)は、クライアントとしてグループに参加している状態を表す。参加のノードは、最後にグループ告知メッセージを受信してから所定の時間以上、サーバからグループ告知メッセージが送信されてきていないと判定した場合、または、サーバがグループから離脱したと判定した場合、その状態をサーバ候補B(State6)に遷移させる。
【0067】
サーバ候補B(State6)は、参加状態のクライアントが必要に応じて遷移する状態である。サーバ候補Bのノードは、サーバから送信されるグループ告知メッセージを受信した場合、または、自分自身より、サーバ候補としての優先順位が高いノードが存在することを表すサーバ候補告知メッセージを受信した場合、その状態を参加(State5)に遷移させる。
【0068】
また、サーバ候補Bのノードは、サーバ候補告知メッセージを送信してから所定の時間経過した場合、或いは、グループ内に存在するサーバから送信されてきた、自分自身宛のサーバ移動通知メッセージを受信した場合、その状態を正式サーバ(State4)に遷移させる。
【0069】
正式サーバ(State4)は、サーバとしてグループを管理するノードが遷移する状態である。正式サーバのノードは、後述するサーバ離脱のシーケンスによりグループから離脱した場合、および、参加(State5)のノードが、ノード離脱のシーケンスによりグループから離脱した場合、その状態を、離脱(State7)に遷移させる。
【0070】
離脱(State7)は、グループから離脱した状態を表す。離脱状態のノードは、その後、自分自身の状態を、適宜、未参加(State3)などの状態に遷移される。
【0071】
以上のようにして、それぞれのノードの状態が遷移される。なお、上述した各メッセージの詳細については後述する。
【0072】
図6および図7は、ノードリストの例を示す図である。
【0073】
上述したように、グループに参加する各ノード(クライアント)は、サーバから送信されるグループ告知メッセージに基づいて、最新の、かつ、同一のノードリストを管理する。そして、例えば、グループのサーバが離脱した場合、ノードリストにより表される各ノードの優先順位に基づいて、次にサーバとして機能するノードが決定される。
【0074】
図6は、優先順位を数値により表したものである。この例においては、最も低い数値が割り当てられているノードが、優先順位が最も高いノードであることを表している。
【0075】
図6の例においては、数値「0」が割り当てられているノードAが、最も優先順位が高いノードであり、サーバである。また、図6の例においては、数値「1」が割り当てられているノードD、数値「2」が割り当てられているノードC、数値「3」が割り当てられているノードB、数値「4」が割り当てられているノードEの順に、優先順位が設定されている。
【0076】
図6に示されるノードリストが、ノードA乃至ノードEのノードIDを有する各ノードにより管理される。
【0077】
図7は、メモリのアドレスに応じて、優先順位が決定されるノードリストの例を示す図である。
【0078】
図7の例においては、メモリの領域31に記述されているノードAが、最も優先順位が高いノードであり、サーバである。また、図7の例においては、領域32にIDが記述されているノードD、領域33にIDが記述されているノードC、領域34にIDが記述されているノードB、領域35にIDが記述されているノードEの順に優先順位が設定されている。
【0079】
各ノードにおいては、例えば、図8乃至図10に示されるような階層構造によりノードリストが管理される。
【0080】
図8は、ノードAにより管理されるグループ管理テーブル41の例を示す図である。
【0081】
グループ管理テーブル41により、ノードAが把握しているグループの数、および、個別グループ管理テーブルの参照先が管理される。個別グループ管理テーブルには、それぞれのグループに関する情報が記述される。
【0082】
図8のグループ管理テーブル41には、ノードAが把握しているグループの数が3つであることが記述されている。また、グループAの個別グループ管理テーブル(グループA管理テーブル)の参照先(参照1)、グループBの個別グループ管理テーブル(グループB管理テーブル)の参照先(参照2)、および、グループCの個別グループ管理テーブル(グループC管理テーブル)の参照先(参照3)が記述されている。
【0083】
図9は、グループAの個別グループ管理テーブル51の例を示す図である。
【0084】
個別グループ管理テーブル51は、図8のグループ管理テーブル41に参照先として記述されている「参照1」に基づいて取得される。
【0085】
個別グループ管理テーブル51には、このテーブルにより情報が管理されるグループのグループID、グループAにおける、ノードA(自ノード)の状態、および、グループAに属するノードのノードリストの参照先が記述されている。
【0086】
図9の例においては、グループIDは「グループA」であり、ノードAの状態は「3」であり、ノードリスト管理テーブル(ノードリストとノードの数を表すテーブル)の参照先は「参照1」である。
【0087】
ノードの状態は、数値により表される。例えば、「初期状態」は「0」で表され、「サーバ候補A」は「1」で表され、「未参加」は「2」で表される。また、「正式サーバ」は「3」で表され、「参加」は「4」で表され、「サーバ候補B」は「5」で表され、「離脱」は「6」で表される。すなわち、この場合、図9の個別グループ管理テーブル51を有するノードAの状態は正式サーバである。
【0088】
図10は、グループAに属するノードのノードリスト61の例を示す図である。
【0089】
ノードリスト61は、図9の個別グループ管理テーブル51により参照先として管理される「参照1」に基づいて取得される。
【0090】
図10の例においては、グループAに属するノードの数は「4」である。また、ノードID「1」により表される「ノードA」が優先順位1位のノードとされ、サーバである。さらに、ノードID「2」により表される「ノードB」が優先順位2位のノードであり、ノードID「3」により表される「ノードC」が優先順位3位のノードであり、ノードID「4」により表される「ノードD」が優先順位4位のノードである。
【0091】
以上のような階層構造を有するテーブル情報、およびノードリストが各ノードにおいて管理される。
【0092】
図11は、各ノード間で送受信されるメッセージのフォーマットの例を示す図である。
【0093】
領域71には、メッセージの送信先を表すIDが記述される。領域71には、例えば、送信先が特定のノードである場合、そのノードの固有のノードIDが記述され、送信先がサーバである場合、送信先がサーバであることを表す、予め規定された所定のIDが記述される。また、送信先が同一のグループに属する全てのノードである場合、そのことを表す、予め規定された所定のIDが記述される。
【0094】
上述したように、メッセージは、ネットワーク4上にマルチキャスト送信される。
【0095】
ネットワーク4にマルチキャスト送信されたメッセージを受信したノードの通信機能部21は、自分自身のノードのノードIDと、領域71に記述されるIDを比較し、送信されてきたメッセージが自分自身に対して送信されてきたものであるのか否かを判断する。例えば、通信機能部21は、領域71に記述されるノードIDと、自分自身のノードIDが一致する場合、自分自身がサーバであり、領域71に、メッセージの送信先がサーバであることを表す所定のIDが記述されている場合、または、領域71に、メッセージの送信先が全てのノードであることを表す所定のIDが記述されている場合、受信したメッセージをグループ管理機能部24に出力する。
【0096】
領域72には、メッセージの送信元を表すIDが記述される。領域72には、例えば、メッセージを送信するノードのノードID、または、メッセージの送信元がサーバであることを表す予め規定されたIDなどが記述される。
【0097】
領域73には、送信されるメッセージの種別(コマンド)が記述され、領域74には、ノードリストなどを含む、所定の送信データが記述される。
【0098】
図12は、図11の領域73に記述されるコマンドと、コードの対応例を示す図である。
【0099】
送信されるメッセージがグループ告知メッセージである場合、例えば、その領域73には「0x00」が記述され、サーバ候補告知メッセージである場合、「0x01」が記述され、サーバ離脱要求メッセージである場合、「0x02」が記述され、サーバ移動通知メッセージである場合、「0x03」が記述される。
【0100】
また、送信されるメッセージがノード参加要求メッセージである場合、その領域73には「0x04」が記述され、ノード参加承認メッセージである場合、「0x05」が記述され、ノード離脱要求メッセージである場合、「0x06」が記述され、ノード離脱承認メッセージである場合、「0x07」が記述される。
【0101】
さらに、送信されるメッセージがノード参加拒否メッセージである場合、その領域73には「0x08」が記述され、サーバからクライアントに対するデータ送信メッセージである場合、「0x09」が記述され、クライアントからサーバに対するデータ送信メッセージである場合、「0x0A」が記述される。
【0102】
なお、メッセージのフォーマットは、図11に示されるものに限られない。
【0103】
次に、図1の通信システムの動作について説明する。
【0104】
始めに、図13のシーケンスを参照して、正式サーバであるノード1から、クライアントであるノード2、およびノード3に対してグループ告知メッセージが送信される処理について説明する。
【0105】
なお、以下においては、ノード1乃至ノード3を、それぞれノードA乃至ノードCとも称する。
【0106】
ステップS1において、ノードA(ノード1)のグループ管理機能部22のメッセージ管理部22Aは、通信機能部21を制御し、ノードB、およびノードCに対して、グループ告知メッセージをマルチキャスト送信する。上述したように、グループ告知メッセージには、同一のグループに属するノードのリストが含まれる。
【0107】
図14は、ステップS1において送信されるグループ告知メッセージの例を示す図である。図11と対応する部分には同一の符号が付されている。
【0108】
領域71には、送信先が、グループに属する全てのノードであることを表す「ALL」(メッセージの送信先が全てのノードであることを表す所定のID)が記述され、領域72には、メッセージの送信元のノードを表す「ノードA」(メッセージの送信元がノードAであることを表す所定のID)が記述され、領域73には、このメッセージがグループ告知メッセージであることを表すコマンド(例えば、「0x00」)が記述されている。
【0109】
領域74には、送信データとして、記述されるノードリストが「グループG」に属するノードに関するものであることを表す情報と、ノードリストが記述されている。図14の例においては、「グループG」に属するノードの数は「3」であり、「ノードA」、「ノードB」、「ノードC」の順序に、優先順位が設定されていることが記述されている。
【0110】
図13の説明に戻り、このような各種の情報を含むグループ告知メッセージが、サーバであるノードAから送信される。
【0111】
ノードAから送信されたグループ告知メッセージは、ステップS11においてノードBにより受信され、ステップS21においてノードCにより受信される。
【0112】
グループ告知メッセージは、所定の周期でサーバから送信される。すなわち、ステップS1の処理が行われてから所定時間経過後のステップS2、および、ステップS2の処理が行われてから所定時間経過後のステップS3において、それぞれ、ノードAから、ノードB、およびノードCに対してグループ告知メッセージが送信される。
【0113】
ノードBは、ノードAから送信されてきたグループ告知メッセージをステップS12およびS13において受信し、ノードCは、ステップS22およびS23において受信する。
【0114】
グループ告知メッセージを受信したノードB、およびノードC(クライアント)は、必要に応じて、受信したメッセージに含まれるノードリストに基づいて、自分自身が管理するノードリストを更新する。
【0115】
以上の処理がノードA乃至ノードCにより繰り返し実行される。
【0116】
このように、最新のグループ構成を表すノードリストが、所定の周期でサーバにより配布されるため、それぞれのクライアントは、常に最新のノードリストを有することになる。
【0117】
次に、図15のフローチャートを参照して、グループ告知メッセージを送信するノードAの処理について説明する。図15に示される処理は、基本的には、図13を参照して説明したノードAの処理と同様である。
【0118】
ステップS31において、ノードAのグループ管理機能部22のメッセージ管理部22Aは、直前にグループ告知メッセージを送信してから、所定の時間が経過したか否かを判定し、所定の時間が経過したと判定するまで待機する。
【0119】
メッセージ管理部22Aは、ステップS31において、所定の時間が経過したと判定した場合、ステップS32に進み、通信機能部21を制御し、現在のノードリストを含むグループ告知メッセージを送信する。送信されるノードリストは、リスト管理部22Cにより管理されているものである。
【0120】
その後、ステップS31に戻り、以上の処理が繰り返し実行される。
【0121】
次に、図16のフローチャートを参照して、図15の処理に対応してノードBにより実行される処理について説明する。すなわち、図16に示される処理は、基本的には、図13を参照して説明したノードBの処理と同様である。
【0122】
ステップS41において、ノードBのクライアント機能部24のメッセージ管理部22Aは、通信機能部21を制御し、サーバであるノードAから所定周期で送信されてくるグループ告知メッセージを受信する。受信されたメッセージに含まれるノードリストはリスト管理部22Cに出力される。
【0123】
ステップS42において、リスト管理部22Cは、自分自身が管理しているノードリストと、グループ告知メッセージにより送信されてきたノードリストを比較し、管理するノードリストの更新が必要であるか否かを判定する。
【0124】
リスト管理部22Cは、ステップS42において、ノードリストの更新が必要でないと判定した場合、ステップS41に戻り、以上の処理を繰り返し実行する。
【0125】
一方、ステップS42において、グループ告知メッセージにより送信されてきたノードリストにより、自分自身が管理するノードリストを更新する必要があると判定した場合、ステップS43に進み、リスト管理部22Cは、ノードリストを更新する。
【0126】
例えば、クライアント機能部24は、ノードリストに付されているタイムスタンプを参照し、自分自身が管理しているノードリストよりも、送信されてきたノードリストの方が新しいと判定した場合、ノードリストの更新を行う。
【0127】
以上の処理により、最新のノードリストがクライアントにより管理される。なお、以上の処理は、クライアントであるノードCにおいても実行される。
【0128】
次に、図17のフローチャートを参照して、ネットワーク4に接続し、グループにおける動作を開始するノードC(初期状態のノード)の処理について説明する。
【0129】
ノードCのグループ管理機能部22の状態管理部22Bは、ネットワーク4に接続されたとき、ノードCの状態を初期状態(図5のState1)とする。また、状態管理部22Bは、ネットワーク4上においてマルチキャスト送信されるメッセージを所定の期間だけ受信し、ステップS51において、受信されたメッセージの中にグループ告知メッセージがあるか否かを判定する。
【0130】
上述したように、グループに存在するサーバから、グループ告知メッセージが所定の周期でマルチキャスト送信される。従って、所定期間内にノードCがグループ告知メッセージを受信した場合、それは、ネットワーク4上に、グループを管理するサーバが既に存在することを表し、反対に、受信できない場合、ネットワーク4上にサーバが存在しない可能性があることを表している。
【0131】
ステップS51において、状態管理部22Bは、グループ告知メッセージが所定期間内に送信されてきたと判定した場合、自らを「サーバでない」と認識し、ステップS52に進み、グループ参加処理を実行する。
【0132】
このとき、ノードCの状態は、未参加(図5のState3)の状態である。ステップS52で実行されるグループ参加処理については、図18のシーケンス等を参照して後述する。
【0133】
ステップS52の処理により、クライアントしてノードCが正式にグループに参加できた場合、ステップS53において、ノードCは、クライアントとして、グループ告知メッセージの受信処理を行う。すなわち、ノードCにより、図16を参照して説明した処理が実行される。その後、グループ開始処理が終了される。
【0134】
一方、ステップS51において、所定期間内にグループ告知メッセージが送信されてきていないと判定した場合、状態管理部22Bは、ステップS54に進み、自分自身の状態をサーバ候補A(図5のState2)とし、サーバ調停処理を実行する。ステップS54で実行されるサーバ調停処理については、図26のシーケンス等を参照して後述する。
【0135】
ステップS55において、状態管理部22Bは、サーバ調停処理の結果、自分自身が正式サーバになれたか否かを判定する。
【0136】
サーバ調停処理において、ノードCに設定されているサーバ候補としての優先順位が最も高い場合、ノードCがサーバとして決定され、ノードCよりも優先順位が高いサーバ候補が存在する場合、他のノード(ノードC以外のノード)がサーバとして決定される。
【0137】
状態管理部22Bは、ステップS55において、正式サーバになれなかったと判定した場合、ステップS52に進み、グループ参加処理を実行し、反対に、正式サーバになれたと判定した場合、ステップS56に進み、正式サーバとして、グループ管理処理、すなわち、グループ告知メッセージの送信処理を開始する。
【0138】
ステップS56においては、正式サーバであるノードCにより、図15を参照して説明したグループ告知メッセージの送信処理が実行される。
【0139】
次に、図18のシーケンスを参照して、図17のステップS52において実行されるグループ参加処理について説明する。
【0140】
ステップS91において、ノードCのメッセージ管理部22Aは、状態管理部22Bからのトリガ(例えば、未参加の状態であることの通知)に応じて、通信機能部21を制御し、ノード参加要求メッセージをサーバに対して送信(マルチキャスト送信)する。
【0141】
このメッセージには、送信先を指定する情報として、サーバ(ノードA)に送信することを表すIDが記述される。従って、マルチキャスト送信により、ノード参加要求メッセージがノードBに対しても送信されるが、メッセージの領域71に記述されるIDに基づいて、ノードBの通信機能部21により破棄される。
【0142】
ノードCにより送信されたノード参加要求メッセージは、ステップS71において、正式サーバであるノードAにより受信される。
【0143】
ステップS72において、ノードAのメッセージ管理部22Aは、ノード参加承認メッセージをノードCに対して返信し、ステップS73に進み、ノードリストを更新する。すなわち、ノードCに関する情報(優先順位等)がリスト管理部22Cによりノードリストに追加される。
【0144】
ノードAから送信されたノード参加承認メッセージは、ステップS92において、ノードCにより受信される。なお、ノード参加承認メッセージには、送信先としてノードCが指定されているため、マルチキャスト送信されたノード参加承認メッセージはノードBには取得されない。
【0145】
ステップS74において、ノードAのメッセージ管理部22Aは、更新したノードリストを含むグループ告知メッセージをマルチキャスト送信する。送信されたグループ告知メッセージは、ステップS81においてノードBにより受信され、ステップS93においてノードCにより受信される。
【0146】
これにより、ノードCが、ノードAにより管理されるグループにクライアントとして参加した状態となる。
【0147】
図19乃至図23は、メッセージの例を示す図である。
【0148】
図19は、図18の処理によりノードCがグループに参加する前に、ノードAからノードBに対して送信されるグループ告知メッセージの例を示す図である。
【0149】
すなわち、領域71には、送信先として「ALL」が記述され、領域72には、送信元として「ノードA」が記述され、領域73には、このメッセージがグループ告知メッセージであることを表すコマンド(例えば、「0x00」(図12))が記述される。また、領域74には、ノードAが管理するグループのグループ名「グループG」と、そのグループに属するノードの数「2」、および、「ノードA」、「ノードB」の順に、優先順位が設定されているノードリストが記述される。
【0150】
すなわち、図19に示されるグループ告知メッセージのノードリストには、ノードCの情報がまだ含まれていない。
【0151】
図20は、図18のステップS91において、ノードCからノードAに対して送信されるノード参加要求メッセージの例を示す図である。
【0152】
図に示されるように、メッセージの送信先として「ノードA」が領域71に記述され、メッセージの送信元として「ノードC」が領域72に記述される。また、領域73には、このメッセージがノード参加要求メッセージであることを表すコマンド(例えば、「0x04」(図12))が記述され、領域74には、送信データとして、ノードCが参加を希望するグループ名「グループG」と、自分自身の名前が記述される。
【0153】
図21は、図18のステップS72において、ノードAからノードCに対して送信されるノード参加承認メッセージの例を示す図である。
【0154】
図に示されるように、メッセージの送信先として「ノードC」が領域71に記述され、メッセージの送信元として「ノードA」が領域72に記述される。また、領域73には、このメッセージがノード参加承認メッセージであることを表すコマンド(例えば、「0x05」(図12))が記述され、領域74には、送信データとして、グループ名「グループG」と、ノードCの名前が記述される。
【0155】
図22は、図18のステップS74において、ノードAから、ノードB、およびノードCに対して送信されるグループ告知メッセージの例を示す図である。
【0156】
図に示されるように、メッセージの送信先として「ALL」が領域71に記述され、メッセージの送信元として「ノードA」が領域72に記述される。また、領域73には、このメッセージがグループ告知メッセージであることを表すコマンドが記述され、領域74には、ノードAが管理するグループのグループ名「グループG」と、そのグループに属するノードの数「3」、および、「ノードA」、「ノードB」、「ノードC」の順に、優先順位が設定されているノードリストが記述される。
【0157】
すなわち、ノードCがグループに参加した後に送信される図22のグループ告知メッセージには、図19のグループ告知メッセージと比較して、ノードCに関する情報がノードリストに追加されている。
【0158】
図23は、ノードCの参加が拒否された場合に、ノードAからノードCに送信されるノード参加拒否メッセージの例を示す図である。
【0159】
図に示されるように、メッセージの送信先として「ノードC」が領域71に記述され、メッセージの送信元として「ノードA」が領域72に記述される。また、領域73には、このメッセージがノード参加拒否メッセージであることを表すコマンド(例えば、「0x08」(図12))が記述され、領域74には、送信データとして、ノードCが参加を希望していたグループ名「グループG」と、ノードCの名前が記述される。
【0160】
以上のようなメッセージが、図18を参照して説明した処理、および、その前後において送受信される。
【0161】
次に、図24のフローチャートを参照して、グループへの参加を要求するノードCの処理について説明する。
【0162】
図24に示される処理は、基本的には、図18を参照して説明したノードCの処理と同様である。
【0163】
すなわち、ステップS101において、ノードCのグループ管理機能部22のメッセージ管理部22Aは、通信機能部21を制御し、ノード参加要求メッセージをノードAに対して送信する。例えば、図20のメッセージがメッセージ管理部22Aにより生成され、送信される。
【0164】
ノードCにより送信されたノード参加要求メッセージは、ノードAにより受信され、ノードCの参加を承認するか否かが判定される(図25のステップS113)。ノードCのグループへの参加が承認された場合、ノードAからノードCに対して、ノード参加承認メッセージが送信される(図25のステップS116)。
【0165】
ステップS102において、ノードCのメッセージ管理部22Aは、ノードAからノード参加承認メッセージが送信されてきたか否かを判定し、例えば、参加拒否メッセージが送信されてきた場合、ノード参加承認メッセージが送信されてこないと判定し、ステップS103に進み、エラー処理を実行する。
【0166】
例えば、ノードAにより管理されるノードの数やノードの属性(機器の種類)などに制限があり、ノードCが参加できない場合、ノードAからノードCに対してノード参加拒否メッセージが送信される。
【0167】
ステップS103において、グループ管理機能部22は、エラー処理として、グループに参加できなかったことをユーザに提示したり、或いは、再度、グループ参加要求メッセージを送信するなどの処理を実行する。その後、処理は終了される。
【0168】
このとき、ノードCの状態は、未参加(図5のState3)のままである。
【0169】
一方、ステップS102において、ノードAから、ノード参加承認メッセージが送信されてきたと判定した場合、メッセージ管理部22Aは、ステップS104に進み、それを受信する。
【0170】
ノードCは、ステップS105において、受信されるグループ告知メッセージに含まれるノードリストを取得し、クライアントとして、ノードAが管理するグループに参加する。すなわち、メッセージ管理部22Aからの指示に応じて、状態管理部22Bにより、ノードCの状態が未参加から参加(図5のState5)に遷移されるとともに、リスト管理部22Cにより、ノードリストが管理される。
【0171】
次に、図25のフローチャートを参照して、図24の処理に対応してノードAにより実行される処理について説明する。
【0172】
図25に示される処理は、基本的には、図18を参照して説明したノードAの処理と同様である。
【0173】
ステップS111において、ノードAのメッセージ管理部22Aは、ノード参加要求メッセージがノードCから送信されてきたか否かを判定し、送信されてきたと判定するまで待機する。
【0174】
メッセージ管理部22Aは、ステップS111において、ノード参加要求メッセージが送信されてきたと判定した場合、ステップS112に進み、それを受信する。ノードCから送信されてくるノード参加要求メッセージには、メッセージの送信先として、ノードA(サーバ)が記述されている。
【0175】
ステップS113において、メッセージ管理部22Aは、ノードCの参加を承認するか否かを判定し、承認しないと判定した場合、ステップS114に進み、図23に示されるノード参加拒否メッセージをノードCに対して送信する。
【0176】
メッセージ管理部22Aは、ステップS113において、グループへの参加を承認すると判定した場合、ステップS115に進み、リスト管理部22Cを制御し、グループ内でのノードCの優先順位をノードリストに追加し、更新する。
【0177】
ステップS116において、メッセージ管理部22Aは、例えば、図21に示されるノード参加承認メッセージをノードCに対して送信する。
【0178】
その後、図15を参照して説明したグループ告知メッセージの送信処理がノードAにより実行され、ステップS115で更新されたノードリストがノードB、およびノードCに配布される。
【0179】
以上の処理が繰り返し実行され、複数のノードが参加するグループが形成される。
【0180】
以上においては、参加が承認されたノードCに対して、ノード参加承認メッセージが送信されるとしたが、ノード参加承認メッセージを送信することに代えて、ノードCに関する情報が追加されたノードリストを含むグループ告知メッセージが送信されるようにしてもよい。ノードCに関する情報が追加されたノードリストを含むグループ告知メッセージを受信し、その内容を確認することによっても、ノードCは、自分自身がグループへの参加が承認されたことを把握することができる。
【0181】
次に、図26のシーケンスを参照して、図17のステップS54において実行される調停処理について説明する。
【0182】
この調停処理は、サーバ候補(サーバ候補AまたはB)のノードの中から、1つのサーバを決定する処理である。図26においては、ノードA乃至ノードCがそれぞれサーバ候補Aの状態である場合について説明する。
【0183】
ノードAのメッセージ管理部22Aは、状態管理部22Bからサーバ候補Aに遷移したことが通知されることに応じて、ステップS121において、自分自身がサーバ候補であることを他のノードに通知するサーバ候補告知メッセージをマルチキャスト送信する。
【0184】
図27は、ノードAによりマルチキャスト送信されるサーバ候補告知メッセージの例を示す図である。
【0185】
図に示されるように、メッセージの送信先として「ALL」が領域71に記述され、メッセージの送信元として「ノードA」が領域72に記述される。また、領域73には、このメッセージがサーバ候補告知メッセージであることを表すコマンド(例えば、「0x01」(図12))が記述され、領域74には、送信データとして、形成するグループのグループ名「グループG」と、優先順位「10」が記述される。
【0186】
優先順位は、例えば、リスト管理部22Cが有する擬似乱数生成機能により生成された、0乃至255の値のうちの所定の値に基づいて設定される。例えば、より小さい値が設定されているノードが、正式サーバになる優先順位の、より高いノードとされる。
【0187】
このような優先順位を含むサーバ候補告知メッセージが、サーバ候補のノードにより送受信され、それぞれのノードにおいて行われる比較の結果、最も優先順位が高い(乱数に基づいて設定されている数値が低い)ノードがサーバとして決定される。
【0188】
図26の説明に戻り、ノードAから送信されたサーバ候補告知メッセージは、ステップS131においてノードBにより受信され、ステップS141においてノードCにより受信される。
【0189】
ステップS132において、ノードBのメッセージ管理部22Aは、自分自身がサーバ候補であることを他のノードに通知するサーバ候補告知メッセージをマルチキャスト送信する。
【0190】
図28は、ノードBによりマルチキャスト送信されるサーバ候補告知メッセージの例を示す図である。
【0191】
図28に示されるサーバ候補告知メッセージは、メッセージの送信元として「ノードB」が領域72に記述されている点、および、優先順位が「71」として設定されている点を除いて、図27に示されるものと同様であり、重複する説明は省略する。
【0192】
ノードBから送信されたサーバ候補告知メッセージは、ステップS122においてノードAにより受信され、ステップS142においてノードCにより受信される。
【0193】
ステップS143において、ノードCのメッセージ管理部22Aは、自分自身がサーバ候補であることを他のノードに通知するサーバ候補告知メッセージをマルチキャスト送信する。
【0194】
図29は、ノードCによりマルチキャスト送信されるサーバ候補告知メッセージの例を示す図である。
【0195】
図29に示されるサーバ候補告知メッセージは、メッセージの送信元として「ノードC」が領域72に記述されている点、および、優先順位が「112」として設定されている点を除いて、図27または図28に示されるものと同様である。
【0196】
ノードCから送信されたサーバ候補告知メッセージは、ステップS123においてノードAにより受信され、ステップS133においてノードBにより受信される。
【0197】
以上のように、サーバ候補であるノード同士の間でサーバ候補告知メッセージが送受信され、それぞれのノードに設定されている優先順位が取得される。
【0198】
ノードAは、ステップS124において、ノードB、およびノードCから送信されてきたサーバ候補告知メッセージに基づいてサーバ調停を行い、ノードBは、ステップS134において、ノードA、およびノードCから送信されてきたサーバ候補告知メッセージに基づいてサーバ調停を行う。また、ノードCは、ステップS144において、ノードA、およびノードBから送信されてきたサーバ候補告知メッセージに基づいてサーバの調停を行う。
【0199】
具体的には、それぞれのノードにおいて、自分自身に対して設定されている優先順位と、サーバ候補告知メッセージにより取得された、他のノードに設定されている優先順位の比較が行われ、優先順位が最も高いノードが正式サーバとして決定される。
【0200】
従って、図27乃至図29に示されるサーバ候補告知メッセージがノードA乃至ノードCの間で送受信された場合、優先順位が最も高い(設定されている数値が最も低い)ノードAが、正式サーバとして選択される。
【0201】
なお、同一の優先順位を持つノードが存在した場合、例えば、ノードIDのアスキーコードが、より小さいノードが優先順位の高いノードとされる。
【0202】
正式サーバとして決定されたノードAのグループ管理機能部22のリスト管理部22Cは、ステップS125において、ノードAの情報のみが記述されたノードリストを作成する。グループ管理機能部22のメッセージ管理部22Aは、ステップS126において、リスト管理部22Cにより作成されたノードリストを含むグループ告知メッセージをノードB、およびノードCに対して送信する。
【0203】
このとき、正式サーバとして決定されなかったノードB、およびノードCは、サーバ候補A(図5のState2)から、未参加(State3)を経て、クライアントとして参加(State5)している状態となる。
【0204】
ノードAから送信されたグループ告知メッセージは、ステップS135においてノードBにより受信され、ステップS145において、ノードCにより受信される。
【0205】
図30は、正式サーバとして新たに決定されたノードAにより送信され、ノードB、およびノードCにより受信されるグループ告知メッセージの例を示す図である。
【0206】
図30の例においては、メッセージの送信先として「ALL」が領域71に記述され、メッセージの送信元として「ノードA」が領域72に記述される。また、領域73には、このメッセージがグループ告知メッセージであることを表すコマンド(例えば、「0x00」(図12))が記述され、領域74には、送信データとして、グループ名「グループG」と、ノードAに関する情報のみが記述されたノードリストが記述される。
【0207】
以上のようにして、グループ上にサーバが存在しない場合であっても、1つのサーバのみを選択することが可能である。
【0208】
また、サーバが存在しない場合に、全てのノードがサーバ候補となり、サーバ候補告知メッセージが送受信されるようにしたため、仮に、サーバ以外にも複数のノードが同時にグループから離脱した場合であっても、効率的に、サーバとして動作するノードを決定することが可能となる。すなわち、複数のノードが同時にグループから離脱した場合であっても、グループにノードが残っている限り、その中から、サーバとして動作するノードが選択されることになる。
【0209】
なお、以上においては、サーバの調停は、乱数に基づいて設定される優先順位に基づいて行われるとしたが、当然、それ以外の情報に基づいて行われるようにしてもよい。例えば、それぞれのノードのハードウエア構成が比較され、スペックの最も高いノードがサーバとして選択されるようにしてもよいし、単に、最も先にサーバ候補告知メッセージをマルチキャスト送信したノードがサーバとして選択されるようにしてもよい。
【0210】
次に、図31のフローチャートを参照して、サーバ調停を行うノードA(サーバ候補A)の処理について説明する。
【0211】
図31に示される処理は、基本的には、図26を参照して説明したノードAの処理と同様である。
【0212】
ステップS151において、ノードAのグループ管理機能部22のメッセージ管理部22Aは、自分自身がサーバ候補であることを他のノードに通知するサーバ候補告知メッセージをマルチキャスト送信し、ステップS152に進み、他のノードから、サーバ候補告知メッセージが送信されてきたか否かを判定する。
【0213】
ステップS152において、他のノードから、サーバ候補告知メッセージが送信されてきたと判定した場合、メッセージ管理部22Aは、ステップS153に進み、それを受信する。
【0214】
ステップS152において、サーバ候補告知メッセージが送信されてきていないと判定された場合、ステップS153の処理はスキップされる。
【0215】
ステップS154において、メッセージ管理部22Aは、他のノードのものと比較して、自分自身に設定されている優先順位が最も高いか否かを判定し、高くない、すなわち、サーバ候補告知メッセージを送信してきたノードの中に、ノードAよりも優先順位の高いノードが存在すると判定した場合、ステップS155に進み、クライアントとしてグループに参加する。
【0216】
すなわち、このとき、状態管理部22Bにより、ノードAの状態が「未参加」の状態を経て「参加」に遷移される。
【0217】
一方、ステップS154において、メッセージ管理部22Aは、他のノードのものと比較して、自分自身に設定されている優先順位が最も高いと判定した場合、ステップS156に進み、サーバ候補告知メッセージを送信してから所定時間が経過したか否かを判定する。
【0218】
ステップS156において、所定時間が経過していないと判定した場合、メッセージ管理部22Aは、ステップS152に戻り、同様の処理を繰り返し実行する。これにより、それぞれのノード間において、サーバ候補告知メッセージを送受信する時間が確保される。
【0219】
このとき、他のノードに設定されている優先順位よりも、ノードAに設定されている優先順位の方が高い場合、サーバ候補Aの状態が状態管理部22Bにより維持される。
【0220】
ステップS156において、状態管理部22Bは、サーバ候補告知メッセージを送信してから所定時間が経過したと判定した場合、ステップS157に進み、ノードAの状態を、正式サーバに遷移させる。
【0221】
正式サーバになったノードAのメッセージ管理部22Aは、ステップS158において、図30に示されるグループ告知メッセージをマルチキャスト送信し、処理を終了する。
【0222】
以上の処理が、サーバ候補Aの状態を有するノードB、およびノードCのそれぞれにおいて実行され、1つのサーバが決定される。
【0223】
次に、図32のシーケンスを参照して、グループからクライアントが離脱する場合の処理について説明する。
【0224】
図32においては、ノードAが正式サーバであり、クライアントであるノードCが離脱する処理について説明する。なお、図32においては、ノードBもクライアントである。
【0225】
ステップS191において、ノードCのグループ管理機能部22のメッセージ管理部22Aは、通信機能部21を制御し、ノード離脱要求メッセージをノードAに対して送信する。
【0226】
このメッセージには、送信先として、サーバ(ノードA)に送信することを表す所定のIDが記述される。従って、ノード離脱要求メッセージは、メッセージの領域71に記述されるIDに基づいて、ノードBには取得されない。
【0227】
ノードCにより送信されたノード離脱要求メッセージは、ステップS171において、ノードAにより受信される。
【0228】
ステップS172において、ノードAのメッセージ管理部22Aは、ノード離脱承認メッセージをノードCに対して返信し、ノードAのリスト管理部22Cは、ステップS173において、ノードリストを更新する。すなわち、ノードAにより管理されるノードリストから、ノードCに関する情報が削除される。
【0229】
ノードAから送信されたノード離脱承認メッセージは、ステップS192において、ノードCにより受信される。なお、ノード離脱承認メッセージには、送信先としてノードCが指定されているため、マルチキャスト送信されたノード離脱承認メッセージは、ノードBには取得されない。
【0230】
ステップS174において、ノードAのメッセージ管理部22Aは、更新したノードリストを含むグループ告知メッセージを送信する。送信されたグループ告知メッセージは、ステップS181においてノードBにより受信され、ステップS193においてノードCにより受信される。
【0231】
これにより、ノードCが、ノードAにより管理されるグループから離脱した状態となる。
【0232】
図33乃至図36は、メッセージの例を示す図である。
【0233】
図33は、図32の処理によりノードCがグループから離脱する前に、ノードAから、ノードB、およびノードCに対して送信されるグループ告知メッセージの例を示す図である。
【0234】
すなわち、領域71には、送信先として「ALL」が記述され、領域72には、送信元として「ノードA」が記述され、領域73には、このメッセージがグループ告知メッセージであることを表すコマンド(例えば、「0x00」(図12))が記述される。また、領域74には、ノードAが管理するグループのグループ名「グループG」と、ノードA乃至ノードCに関する情報が含まれるノードリストが記述される。
【0235】
すなわち、図33に示されるグループ告知メッセージのノードリストには、ノードCに関する情報がまだ含まれている。
【0236】
図34は、図32のステップS191において、ノードCからノードAに対して送信されるノード離脱要求メッセージの例を示す図である。
【0237】
図に示されるように、メッセージの送信先として「ノードA」が領域71に記述され、メッセージの送信元として「ノードC」が領域72に記述される。また、領域73には、このメッセージがノード離脱要求メッセージであることを表すコマンド(例えば、「0x06」(図12))が記述され、領域74には、送信データとして、ノードCが離脱を希望するグループ名「グループG」と、自分自身の名前が記述される。
【0238】
図35は、図32のステップS172において、ノードAからノードCに対して送信されるノード離脱承認メッセージの例を示す図である。
【0239】
図に示されるように、メッセージの送信先として「ノードC」が領域71に記述され、メッセージの送信元として「ノードA」が領域72に記述される。また、領域73には、このメッセージがノード離脱承認メッセージであることを表すコマンド(例えば、「0x07」(図12))が記述され、領域74には、送信データとして、グループ名「グループG」と、ノードCの名前が記述される。
【0240】
図36は、図32のステップS174において、ノードAからノードB、およびノードCに対して送信されるグループ告知メッセージの例を示す図である。
【0241】
図に示されるように、メッセージの送信先として「ALL」が領域71に記述され、メッセージの送信元として「ノードA」が領域72に記述される。また、領域73には、このメッセージがグループ告知メッセージであることを表すコマンドが記述され、領域74には、ノードAが管理するグループのグループ名「グループG」と、そのグループに属するノードの数「2」、および、「ノードA」、「ノードB」の順に、優先順位が設定されているノードリストが記述される。
【0242】
すなわち、ノードCがグループから離脱した後に送信される図36のグループ告知メッセージには、図33のメッセージと比較して、ノードCに関する情報がノードリストから削除されている。
【0243】
以上のようなメッセージが、図32を参照して説明した処理、および、その前後において送受信される。
【0244】
次に、図37のフローチャートを参照して、グループからの離脱を要求するノードCの処理について説明する。
【0245】
ステップS201において、ノードCのメッセージ管理部22Aは、グループから離脱することが状態管理部22Bから通知されてくることに応じて、通信機能部21を制御し、ノード離脱要求メッセージをノードAに対して送信する。これにより、例えば、送信先としてノードAが指定される図34のメッセージがメッセージ管理部22Aにより生成され、送信される。
【0246】
ノードCにより送信されたノード離脱要求メッセージは、ノードAにより受信され、ノードCの離脱を承認するか否かが判定される(図38のステップS213)。ノードCのグループからの離脱が承認された場合、ノードAからノードCに対して、ノード離脱承認メッセージが送信される(図38のステップS215)。
【0247】
ステップS202において、ノードCのメッセージ管理部22Aは、ノードAからノード離脱承認メッセージが送信されてきたか否かを判定し、ノード離脱承認メッセージが送信されてきていないと判定した場合、ステップS203に進み、エラー処理を実行する。
【0248】
例えば、通信のエラーなどにより、ノード離脱承認メッセージが送信されてこない場合、そのことをユーザに提示するなどのエラー処理が実行される。その後、処理は終了される。このとき、ノードCの状態は、参加(図5のState5)のままである。
【0249】
一方、ステップS202において、ノードAから、ノード離脱承認メッセージが送信されてきたと判定した場合、メッセージ管理部22Aは、ステップS204に進み、それを受信する。
【0250】
メッセージ管理部22Aは、ステップS205において、ノードAから送信されてくるグループ告知メッセージを受信し、リスト管理部22Cに、管理するノードリストを更新させる。ノードAから送信されてくるグループ告知メッセージは、例えば、図36に示されるような、ノードCに関する情報が含まれていないメッセージであり、これにより、グループから離脱した状態(図5のState7)となる。
【0251】
次に、図38のフローチャートを参照して、図37の処理に対応してノードAにより実行される処理について説明する。図38に示される処理は、基本的には、図32を参照して説明したノードAの処理と同様である。
【0252】
ステップS211において、ノードAのグループ管理機能部22のメッセージ管理部22Aは、ノード離脱要求メッセージがノードCから送信されてきたか否かを判定し、送信されてきたと判定するまで待機する。
【0253】
メッセージ管理部22Aは、ステップS211において、ノード離脱要求メッセージが送信されてきたと判定した場合、ステップS212に進み、それを受信する。
【0254】
ステップS213において、メッセージ管理部22Aは、ノードCの離脱を承認するか否かを判定し、承認しないと判定した場合、ステップS214に進み、所定のエラー処理を実行した後、処理を終了する。なお、クライアントにより、グループからの離脱が要求された場合、それが必ず承認されるようにしてもよい。
【0255】
メッセージ管理部22Aは、ステップS213において、グループからの離脱を承認すると判定した場合、ステップS215に進み、図35に示されるノード離脱承認メッセージをノードCに対して送信する。
【0256】
ステップS216において、リスト管理部22Cは、グループ内でのノードCの優先順位等をノードリストから削除し、更新する。
【0257】
ステップS216で更新されたノードリストを含むグループ告知メッセージは、ステップS227において、ノードAから、ノードB、およびノードCに対して送信される。
【0258】
なお、離脱が承認されたノードCに対して、ノード離脱承認メッセージが送信されるとしたが、ノード離脱承認メッセージに代えて、ノードCの情報が削除されたノードリストを含むグループ告知メッセージが送信されるようにしてもよい。ノードCの情報が削除されたノードリストを含むグループ告知メッセージの内容によっても、ノードCは、グループからの離脱が承認されたことを確認することができる。
【0259】
以上においては、クライアントがグループから離脱する場合の処理について説明したが、次に、サーバが離脱する場合の処理について説明する。
【0260】
サーバの離脱には、サーバが離脱する旨を他のノードに通知し、明示的にグループから離脱する場合と、他のノードに離脱する旨を通知することなく、非明示的に離脱する場合とがある。
【0261】
始めに、図39のシーケンスを参照して、グループから明示的にサーバが離脱する場合の処理について説明する。図39においては、ノードAがグループから離脱するサーバであり、ノードB、およびノードCがクライアントである。
【0262】
例えば、グループ管理機能部22の状態管理部22Bから、ユーザがグループからの離脱を要求していることが通知されてきたとき、ステップS241において、ノードAのメッセージ管理部22Aは、通信機能部21を制御し、サーバ離脱要求メッセージをノードB、およびノードCに対して送信(マルチキャスト送信)する。
【0263】
送信されたサーバ離脱要求メッセージは、ステップS251においてノードBにより受信され、ステップS261においてノードCにより受信される。
【0264】
サーバ離脱要求メッセージを受信したノードB、およびノードCの状態管理部22Bは、それまでの参加状態(図5のState5)から、サーバ候補Bの状態(State6)に自らの状態を遷移させ、サーバ候補告知メッセージを送信する。
【0265】
すなわち、ステップS252において、ノードBのメッセージ管理部22Aは、ノードBがサーバ候補であることを他のノードに通知するサーバ候補告知メッセージを送信する。
【0266】
ノードBから送信されたサーバ候補告知メッセージは、ステップS242においてノードAにより受信され、ステップS262においてノードCにより受信される。
【0267】
同様に、ステップS263において、ノードCのメッセージ管理部22Aは、ノードCがサーバ候補であることを他のノードに通知するサーバ候補告知メッセージを送信する。
【0268】
ノードCから送信されたサーバ候補告知メッセージは、ステップS243においてノードAにより受信され、ステップS253においてノードBにより受信される。
【0269】
ノードB、およびノードCから送信されてきたサーバ候補告知メッセージは、ノードAのメッセージ管理部22Aにより受信され、リスト管理部22Cに出力される。リスト管理部22Cは、ステップS244において、メッセージに含まれるノードB、およびノードCの優先順位に基づいて、新たなサーバを選択する。
【0270】
上述したように、サーバ候補告知メッセージには、それを送信するノードに設定されている優先順位が含まれている。
【0271】
サーバとして新たに動作するノードとして、例えば、ノードBを選択したノードAは、ステップS245において、サーバ移動通知メッセージをノードB、およびノードCに対して送信する。このサーバ移動通知メッセージには、ノードBに対して、最も高い優先順位が設定されたノードリストが含まれている。
【0272】
ノードAから送信されたサーバ移動通知メッセージは、ステップS254においてノードBにより受信され、ステップS264においてノードCにより受信される。
【0273】
ノードAにより、新たな正式サーバとして選択されたノードBの状態管理部22Bは、その状態を、サーバ候補B(図5のState6)から正式サーバ(State4)に遷移させ、グループの管理を開始する。すなわち、ステップS255において、ノードBは、ノードA、およびノードCに対して、更新されたノードリストを含むグループ告知メッセージを送信する。
【0274】
送信されたグループ告知メッセージは、ステップS246において、ノードAにより受信され、ステップS265において、ノードCにより受信される。
【0275】
新たなサーバを選択したノードAの状態管理部22Bは、その後、自分自身の状態を正式サーバ(図5のState4)から離脱状態(State7)に遷移させ、グループから離脱する。
【0276】
なお、新たなサーバとして選択されなかったノードCの状態管理部22Bは、自分自身の状態を、サーバ候補B(図5のState6)から参加(State5)に遷移させ、クライアントとして、ノードBが新たに管理することになったグループに参加する。
【0277】
図40乃至図45は、メッセージの例を示す図である。
【0278】
図40は、図39の処理により、ノードAがグループから離脱する前に、ノードAから、ノードB、およびノードCに対して送信されるグループ告知メッセージの例を示す図である。
【0279】
領域74に記述されるノードリストには、正式サーバであるノードAが管理するグループに属するノードの数「3」、および、「ノードA」、「ノードB」、「ノードC」の順に設定されている優先順位が記述される。
【0280】
すなわち、図40に示されるグループ告知メッセージには、ノードAに関する情報がまだ含まれており、ノードAに対して最も高い優先順位が設定されている。
【0281】
図41は、図39のステップS241において、ノードAから、ノードB、およびノードCに対して送信されるサーバ離脱要求メッセージの例を示す図である。
【0282】
図に示されるように、メッセージの送信先として「ALL」が領域71に記述され、メッセージの送信元として「ノードA」が領域72に記述される。また、領域73には、このメッセージがサーバ離脱要求メッセージであることを表すコマンド(例えば、「0x02」(図12))が記述され、領域74には、送信データとして、ノードAが離脱を希望するグループ名「グループG」と、自分自身の名前が記述される。
【0283】
図42は、図39のステップS252において、ノードBから、ノードA、およびノードCに対して送信されるサーバ候補告知メッセージの例を示す図である。
【0284】
図に示されるように、メッセージの送信先として「ALL」が領域71に記述され、メッセージの送信元として「ノードB」が領域72に記述される。また、領域73には、このメッセージがサーバ候補告知メッセージであることを表すコマンド(例えば、「0x01」(図12))が記述され、領域74には、ノードBに設定されている優先順位「1」が記述される。
【0285】
図43は、図39のステップS263において、ノードCから、ノードA、およびノードBに対して送信されるグループ告知メッセージの例を示す図であり、図42のメッセージと基本的に同様である。
【0286】
なお、図43に示されるグループ告知メッセージには、メッセージの送信元として「ノードC」が領域72に記述され、領域74には、ノードCに設定されている優先順位「2」が記述される。
【0287】
例えば、図42および図43に示されるグループ告知メッセージを受信した場合、ノードAは、それぞれのメッセージに記述されている優先順位に基づいて、より優先順位の高いノードBを、新たなサーバとして選択する。
【0288】
図44は、図39のステップS245において、ノードAから、ノードB、およびノードCに対して送信されるサーバ移動通知メッセージの例を示す図である。
【0289】
図に示されるように、メッセージの送信先として「ALL」が領域71に記述され、メッセージの送信元として「ノードA」が領域72に記述される。また、領域73には、このメッセージがサーバ移動通知メッセージであることを表すコマンド(例えば、「0x03」(図12))が記述され、領域74には、グループ名と、新たにサーバとして選択されたノードを表す「ノードB」が記述される。
【0290】
図45は、図39のステップS255において、ノードBから、ノードA、およびノードCに対して送信されるグループ告知メッセージの例を示す図である。
【0291】
図に示されるように、メッセージの送信先として「ALL」が領域71に記述され、メッセージの送信元として「ノードB」が領域72に記述される。また、領域73には、このメッセージがグループ告知メッセージであることを表すコマンドが記述され、領域74には、ノードAが管理するグループのグループ名「グループG」と、そのグループに属するノードの数「2」、および、「ノードB」、「ノードC」の順に、優先順位が設定されているノードリストが記述される。
【0292】
すなわち、新たにサーバとして選択されたノードBから送信される図45のグループ告知メッセージには、図40のメッセージと比較して、ノードAに関する情報がノードリストから削除されているとともに、ノードBがサーバであることを表す情報が含まれている。
【0293】
以上のようなメッセージが、図39を参照して説明した処理、および、その前後において送受信される。
【0294】
次に、図46のフローチャートを参照して、グループから明示的に離脱するノードA(正式サーバ)の処理について説明する。図46に示される処理は、基本的には、図39を参照して説明したノードAの処理と同様である。
【0295】
ステップS281において、ノードAのメッセージ管理部22Aは、通信機能部21を制御し、例えば、図41に示されるサーバ離脱要求メッセージを、ノードB、およびノードCに対して送信(マルチキャスト送信)する。
【0296】
サーバから送信されたサーバ離脱要求メッセージは、ノードB、およびノードCにより受信され、サーバ候補Bに状態を遷移させたノードB、およびノードCから、サーバ候補告知メッセージが送信されてくる。
【0297】
ステップS282において、ノードAのメッセージ管理部22Aは、サーバ候補告知メッセージが送信されてきたか否かを判定し、送信されてきたと判定した場合、ステップS283に進み、それを受信する。
【0298】
ステップS282において、サーバ候補告知メッセージが送信されてきていないと判定された場合、ステップS283の処理はスキップされる。
【0299】
ステップS284において、メッセージ管理部22Aは、サーバ離脱要求メッセージを送信してから、所定時間経過したか否かを判定し、経過していないと判定した場合、ステップS282に戻り、それ以降の処理を繰り返し実行する。これにより、サーバ離脱要求メッセージを受信したノードB、およびノードCにより、サーバ候補告知メッセージが送信される時間が確保される。
【0300】
メッセージ管理部22Aは、ステップS284において、サーバ離脱要求メッセージを送信してから、所定時間が経過したと判定した場合、ステップS285に進む。メッセージ管理部22Aにより受信された、サーバ候補告知メッセージは、リスト管理部22Cに出力される。
【0301】
ステップS285において、リスト管理部22Cは、ノードB、およびノードCから送信されてきたサーバ候補告知メッセージに含まれる優先順位に基づいて、新たなサーバを選択する。なお、サーバ候補Bのノードがグループ内に存在しないため(グループ内にノードAしか存在しないため)、サーバ候補告知メッセージが送信されてきていない場合、処理は終了される。
【0302】
リスト管理部22Cは、サーバとして新たに動作するノードを選択したとき、それをメッセージ管理部22Aに通知する。
【0303】
ステップS286において、メッセージ管理部22Aは、リスト管理部22Cからの通知に基づいて生成したサーバ移動通知メッセージを、ノードB、およびノードCに対して送信する。このサーバ移動通知メッセージには、サーバとして新たに選択されたノードに対して、最も高い優先順位が設定されたノードリストが含まれている。
【0304】
その後、新たに正式サーバになったノードから、グループ告知メッセージが送信されてくるため、メッセージ管理部22Aは、ステップS287において、それを受信し、グループからの離脱処理を終了させる。
【0305】
これにより、ノードAは、それまで自ら管理していたグループから離脱した状態となる。
【0306】
次に、図47のフローチャートを参照して、図46の処理に対応して実行されるノードBの処理について説明する。
【0307】
ステップS301において、ノードBのメッセージ管理部22Aは、通信機能部21を制御し、グループからの離脱を要求するサーバ(ノードA)から送信されてきたサーバ離脱要求メッセージを受信する。
【0308】
状態管理部22Bは、ステップS302において、それまでクライアントとしてグループに参加していた状態(図5のState5)から、サーバ候補Bの状態(State6)にノードBの状態を遷移させる。
【0309】
ステップS303において、メッセージ管理部22Aは、サーバ候補告知メッセージを、ノードA、およびノードCに対して送信する。
【0310】
ノードBから送信されたサーバ候補告知メッセージは、ノードA、およびノードCにより受信される。ノードAにおいては、メッセージに含まれる優先順位に基づいて、ノードBがサーバとして新たに動作するか否かが選択され、それを通知するサーバ移動メッセージが送信される(図46のステップS285,S286)。
【0311】
ステップS304において、ノードBのメッセージ管理部22Aは、ノードAから送信されてきたサーバ移動メッセージを受信し、それを状態管理部22Bに出力する。
【0312】
ステップS305において、状態管理部22Bは、サーバ移動メッセージに含まれるノードリストに基づいて、ノードBが正式サーバとして選択されたか否かを判定する。サーバ移動メッセージに含まれるノードリストには、サーバとして選択されたノードに対して、最も高い優先順位が割り当てられている。
【0313】
従って、状態管理部22Bは、自分自身のノードに対して、最も高い優先順位が割り当てられていないため、サーバとして選択されていない(クライアントとして選択された)と判定した場合、ステップS306に進み、ノードBの状態を、サーバ候補B(図5のState6)から参加(State5)に遷移させ、クライアントとしてグループに参加する。
【0314】
一方、ステップS305において、正式サーバとして選択されたと判定した場合、ステップS307に進み、状態管理部22Bは、ノードBの状態を、サーバ候補B(図5のState6)から正式サーバ(State4)に遷移させ、グループの管理を開始する。
【0315】
すなわち、ステップS308において、メッセージ管理部22Aは、ノードA、およびノードCに対して、グループ告知メッセージを送信し、ノードAの離脱処理を終了させる。
【0316】
グループからサーバが離脱する場合であっても、以上の処理により、新たにサーバとして動作するノードを効率的に、かつ、確実に選択することができる。すなわち、ネットワーク構成の変化に、より好適に対応することができる。
【0317】
次に、図48のシーケンスを参照して、サーバが、非明示的にグループから離脱した場合の処理について説明する。
【0318】
非明示的なサーバの離脱は、例えば、サーバとして動作するノードが、他のノードとの通信可能範囲から出たときなどに発生する。
【0319】
なお、図48においては、サーバとして動作していたノードXが、非明示的にグループから離脱した場合の処理について説明する。また、ノードXによりそれまで管理されていたグループには、ノードA乃至ノードCがクライアントとして参加していたものとする。
【0320】
サーバ(ノードX)が非明示的にグループから離脱したことを検出したクライアント(ノードA乃至ノードC)により実行される処理は、図26の正式サーバの調停処理と同様の処理である。
【0321】
例えば、サーバから送信されてくるグループ告知メッセージが送信されてこなくなったため、サーバが離脱したと判断したノードA乃至ノードCは、その状態を、参加(図5のState5)からサーバ候補B(State6)に遷移させ、自分自身がサーバ候補であることを他のノードに通知するためのサーバ候補告知メッセージを送信する。
【0322】
すなわち、サーバ候補Bの状態を有するノードAから、ステップS321において送信されたサーバ候補告知メッセージは、ステップS341においてノードBにより受信され、ステップS361においてノードCにより受信される。
【0323】
また、サーバ候補Bの状態を有するノードBから、ステップS342において送信されたサーバ候補告知メッセージは、ステップS322においてノードAにより受信され、ステップS362においてノードCにより受信される。
【0324】
さらに、サーバ候補Bの状態を有するノードCから、ステップS363において送信されたサーバ候補告知メッセージは、ステップS323においてノードAにより受信され、ステップS343においてノードBにより受信される。
【0325】
送信されてきたサーバ候補告知メッセージを受信したノードA乃至ノードCは、ステップS324,S344,S364において、それぞれ、メッセージに含まれている優先順位に基づいて、サーバ調停を行い、最も高い優先順位が設定されているノードを、新たなサーバとして決定する。
【0326】
例えば、ノードAに対して最も高い優先順位が設定されている場合、ノードAは、その状態をサーバ候補B(図5のState6)から正式サーバ(State4)に遷移させ、ステップS325において、ノードAの情報のみが記述されたノードリストを含むサーバ移動通知メッセージを、ノードB、およびノードCに対して送信する。
【0327】
ノードAから送信されたサーバ移動通知メッセージは、ステップS345においてノードBにより受信され、ステップS365においてノードCにより受信される。
【0328】
その後、ノードAによりグループの管理が開始され、ステップS326において送信されたグループ告知メッセージが、ステップS346においてノードBにより受信され、ステップS366においてノードCにより受信される。ステップS326において送信されたグループ告知メッセージには、ノードA乃至ノードCの情報が記述されたノードリストが含まれている。
【0329】
以上のように、各クライアント間でサーバ候補告知メッセージが送受信され、優先順位に基づいて、新たなサーバが決定されることにより、サーバが非明示的にグループから離脱した場合であっても、サーバ・クライアント間のサービスの提供が継続されることになる。
【0330】
図49乃至図53は、メッセージの例を示す図である。
【0331】
図49は、図48の処理が実行される前に、ノードXから、ノードXが管理するグループに参加しているノードA乃至ノードCに対して送信されるグループ告知メッセージの例を示す図である。
【0332】
領域74に記述されるノードリストには、正式サーバであるノードXが管理するグループに属するノードの数「4」、および、「ノードX」、「ノードA」、「ノードB」、「ノードC」の順に設定されている優先順位が記述される。
【0333】
すなわち、図49に示されるグループ告知メッセージには、非明示的にグループから離脱するノードXに関する情報がまだ含まれている。
【0334】
図50は、図48のステップS321において、ノードAから、ノードB、およびノードCに対して送信されるサーバ候補告知メッセージの例を示す図である。図50に示されるサーバ候補告知メッセージは、図42、または図43に示されるサーバ候補告知メッセージと同様である。
【0335】
すなわち、領域72には、メッセージの送信元として「ノードA」が記述され、領域74には、サーバ候補Bの状態を有するノードAに設定されている優先順位「1」が記述される。
【0336】
図51は、図48のステップS342において、ノードBから、ノードA、およびノードCに対して送信されるサーバ候補告知メッセージの例を示す図である。
【0337】
領域72には、メッセージの送信元として「ノードB」が記述され、領域74には、サーバ候補Bの状態を有するノードBに設定されている優先順位「2」が記述される。
【0338】
図52は、図48のステップS363において、ノードCから、ノードA、およびノードBに対して送信されるサーバ候補告知メッセージの例を示す図である。
【0339】
領域72には、メッセージの送信元として「ノードC」が記述され、領域74には、サーバ候補Bの状態を有するノードCに設定されている優先順位「3」が記述される。
【0340】
従って、ノードA乃至ノードCにより、図50乃至図52のサーバ候補告知メッセージが送受信された場合、最も高い優先順位が設定されているノードAが、新たなサーバとして決定される。
【0341】
図53は、図48のステップS326において、ノードAから、ノードB、およびノードCに対して送信されるグループ告知メッセージの例を示す図であり、このメッセージは、例えば、図40のメッセージと同様のものである。
【0342】
すなわち、新たにサーバとして選択されたノードAに対して最も高い優先順位が割り当てられたノードリストを含むグループ告知メッセージが、ノードB、およびノードCに対して送信される。
【0343】
非明示的にサーバがグループから離脱した場合の各ノードの処理は、新たにサーバとして決定されたノードから、サーバ移動通知メッセージが送信される点を除いて、図31を参照して説明した処理と同様であるため、その説明は省略する。
【0344】
以上の各ノードの処理により、非明示的にサーバが離脱した場合であっても、効率的に、かつ、確実に、新たにサーバとして動作するノードを選択することが可能となる。
【0345】
図54は、図1のノードA(ノード1)の他の機能構成例を示すブロック図である。図4と同一の部分には、同一の符号が付されている。
【0346】
サーバ同期機能部81は、通信制御部21と協働し、サーバ機能部23に対して、サーバ機能部23が、「全てのクライアントへのメッセージの送信」、「特定のクライアントへのメッセージの送信」、「クライアントからのメッセージの受信」のそれぞれを行うためのインタフェースを提供する。また、サーバ同期機能部81は、クライアント機能部24に対して、クライアント機能部24が、「サーバへのメッセージの送信」、「サーバからのメッセージの受信」のそれぞれを行うためのインタフェースを提供する。
【0347】
なお、サーバ同期機能部81は、例えば、ノードAがクライアントとして動作しており、サーバがグループから離脱するなどしてサーバの交代が生じた場合であっても、クライアント機能部24にサーバの交代を意識させることなく、サーバとの間で通信(サーバ・クライアント間のアプリケーション層でのメッセージ交換)を行わせる機能を有する。
【0348】
図55のシーケンスを参照して、サーバから、クライアントに対してメッセージ(データ)が送信される場合の処理について説明する。
【0349】
図55においては、ノードAが正式サーバであり、ノードBがクライアントである。なお、図示は省略するが、ノードCにおいても、ノードBと同様の処理が行われる。
【0350】
正式サーバとして動作するノードAのサーバ機能部23が、サービスを受けるクライアントとして動作するノードBのクライアント機能部24に対して、所定のデータを送信するとき、ステップS411において、サーバ機能部23は、サーバ同期機能部81に対して、クライアントへのデータの送信を要求する。
【0351】
図56は、サーバ機能部23から、サーバ同期機能部81(通信機能部21)に対するデータの送信要求において用いられるAPI(Application Programming Interface)の例を示す図である。
【0352】
図56に示す「public void sendDataToClient(byte[] DATA)」インタフェースは、所定のバイト数からなるデータ(クライアントに対して送信するデータ)を引数として与える。
【0353】
この要求をステップS421において受信したサーバ同期機能部81は、ノードリストの情報に基づいて、ノードAが正式サーバであるのか否かを確認し、サーバである場合には、ステップS422に進み、要求されたデータをグループ上のクライアント機能部24に対してマルチキャスト送信する。
【0354】
図57は、ステップS422において送信されるデータの例を示す図である。
【0355】
サーバ同期機能部81により送信されるデータは、上述した各種のメッセージと同様のフォーマットを有しており、領域71には、送信先のノードを表す「ALL」が記述され、領域72には、送信元のノードを表す「ノードA」が記述される。また、領域73には、このデータが、全てのノードのクライアント機能部24に対して送信されるものであることを表す、予め設定された所定のID(クライアントID)が記述され、領域74には、グループ名「グループG」と、送信データが記述される。
【0356】
サーバ同期機能部81により送信されたデータは、ステップS401においてノードAのクライアント機能部24により受信され、ステップS431において、ノードBのサーバ同期機能部81により受信される。
【0357】
ノードBのサーバ同期機能部81は、ステップS432において、ノードAのサーバ同期機能部81から送信されてきたデータを、クライアント機能部24(ノードBのクライアント機能部24)に転送する。
【0358】
図58は、ノードBのサーバ同期機能部81(通信機能部21)から、クライアント機能部24に対するデータの転送において用いられるAPIの例を示す図である。
【0359】
図58に示す「public void receiveDataFromServer(byte[] DATA)」インタフェースは、所定のバイト数からなるデータ(サーバから送信されてきたデータ)を引数として与える。
【0360】
ノードAのクライアント機能部24は、ステップS441において、サーバ同期機能部81から転送されてきたデータを受信し、サーバから送信されてきたデータを取得する。その後、処理は終了される。
【0361】
以上のように、サーバノードのサーバ機能部23と、クライアントノードのクライアント機能部24の間で直接データが送受信されるのではなく、それぞれのサーバ同期機能部81を介して、データの送受信が行われる。
【0362】
次に、図59のシーケンスを参照して、クライアントから、サーバに対してメッセージ(データ)が送信される場合の処理について説明する。
【0363】
図59においては、ノードAがクライアントであり、ノードBが正式サーバである。なお、図示は省略するが、ノードCにおいても、ノードAと同様の処理が適宜行われる。
【0364】
クライアントとして動作するノードAのクライアント機能部24が、サービスを提供するサーバとして動作するノードBのサーバ機能部23に対して、所定のデータを送信するとき、ステップS451において、クライアント機能部24は、サーバ同期機能部81に対して、サーバへのデータの送信を要求する。
【0365】
図60は、クライアント機能部24から、サーバ同期機能部81(通信機能部21)に対するデータの送信要求において用いられるAPIの例を示す図である。
【0366】
図60に示す「public void sendDataToServer(byte[] DATA)」インタフェースは、所定のバイト数からなるデータ(サーバに対して送信するデータ)を引数として与える。
【0367】
この要求をステップS461において受信したサーバ同期機能部81は、所定のメッセージを送信するなどしてサーバが存在するか否か(調停が行われている最中か否か)を確認し、サーバが存在する場合には、ステップS462に進み、要求されたデータを、ノードBのサーバ同期機能部81に対して送信する。
【0368】
図61は、ステップS462において送信されるデータの例を示す図である。
【0369】
領域71には、送信先のノードを表す「ALL」が記述され、領域72には、送信元のノードを表す「ノードA」が記述される。領域73には、このデータが、サーバのサーバ機能部23に対して送信されるものであることを表す、予め設定された所定のID(サーバID)が記述され、領域74には、グループ名「グループG」と、送信データが記述される。
【0370】
なお、サーバに対するデータの送信が要求されときに、グループ内にサーバが存在しないと判断した場合、サーバ同期機能部81は、新たにサーバとして動作するノードが決定されるまで待機し、サーバとして動作するノードが調停により決定されたとき、データの送信を行う。
【0371】
これにより、サーバが存在しない状態を意識させることのないインタフェースが、サーバ同期機能部81からクライアント機能部24に対して提供されることになる。
【0372】
すなわち、仮に、クライアントノードのクライアント機能部24から、サーバノードのサーバ機能部23に対してデータが直接送信されるとした場合、グループ内にサーバが存在しないときには、クライアント機能部24は、新たなサーバが決定されるまで待機するなどのリカバリ処理を行わなければならないが、そのリカバリ処理が、サーバ同期機能部81により代理的に実行される。
【0373】
サーバ同期機能部81により送信されたデータは、ステップS471において、ノードBのサーバ同期機能部81により受信される。
【0374】
ノードBのサーバ同期機能部81は、ステップS472において、ノードAのサーバ同期機能部81から送信されてきたデータを、クライアント機能部24(ノードBのクライアント機能部24)に転送する。
【0375】
図62は、ノードBのサーバ同期機能部81(通信機能部21)から、クライアント機能部24に対するデータの転送において用いられるAPIの例を示す図である。
【0376】
図62に示す「public void receiveDataFromClient(int clientID, byte[] DATA)」インタフェースは、データを送信したクライアントを識別するclientID と、所定のバイト数からなるデータ(クライアントから送信されてきたデータ)を引数として与える。
【0377】
ノードBのクライアント機能部24は、ステップS481において、サーバ同期機能部81から転送されてきたデータを受信し、処理を終了させる。
【0378】
以上の処理により、クライアント機能部23からサーバ機能部24に対するデータの送信が行われる。
【0379】
なお、上述したようなインタフェースを提供するサーバ同期機能部81に、正式サーバでないクライアント上において、正式サーバと同じ状態を常時保持させておくようにすることもできる。
【0380】
この場合、例えば、サーバとして動作するノードAのサーバ同期機能部81は、サーバ機能部23の内部状態を読み出し、読み出した内部状態を表す情報(サーバのサーバ機能部23の情報)を、全てのノード(ノードB、およびノードC)のサーバ同期機能部81に対して送信する。
【0381】
サーバ機能部23の内部状態を表す情報の送信は、例えば、サーバ機能部23の内部状態が変更されたとき、または、所定の時間が経過したときなどの所定のタイミングで行われる。
【0382】
ノードB、およびノードCのサーバ同期機能部81は、送信されてきた情報に基づいて、ノードAのサーバ機能部23の内部状態を、自分自身のノードのサーバ機能部23の状態として設定することにより、クライアントであるノード上に、正式サーバと同一の機能を実現させる。
【0383】
以上の処理が、正式サーバとして動作するノードのサーバ同期機能部81、および、クライアントとして動作するノードのサーバ同期機能部81の双方において繰り返し実行されることにより、クライアントのノードにおいても、正式サーバと同じ状態を持つサーバが常時実現されることになる。
【0384】
なお、サーバ同期機能部81により送信されるサーバ機能部23の内部状態を表す情報は、例えば、既に送信されている情報との差分のみが送信されるようにしてもよい。これにより、その都度、サーバ機能部23の全ての内部状態を表す情報を送信する場合に較べて、通信量を減らすことが可能となる。
【0385】
また、通信量の削減をより可能とすべく、サーバの内部状態を表す情報を、ハッシュ関数に適用することで得られた結果のみが送信されるようにしてもよい。
【0386】
この場合、ハッシュ関数の算出結果を受信したノードは、受信した算出結果と、自分自身のノードの内部状態を表す情報を、予め用意されているハッシュ関数に適用することで得られた算出結果を比較し、それらの結果が一致しない場合にのみ、サーバのサーバ同期機能部81に対して、内部状態を表す情報の送信を要求する。すなわち、受信した算出結果と、自分自身のノードの内部状態を表す情報を、予め用意されているハッシュ関数に適用することで得られた算出結果が一致しない場合、サーバの内部状態と、クライアントの内部状態が異なることを表している。
【0387】
図63は、上述したグループ管理機能部22により実行される、グループ管理処理について説明するフローチャートである。
【0388】
例えば、初期状態(図5のState1)であるノードAのグループ管理機能部22は、ステップS501において、ユーザからの入力に基づいて、処理を終了することが指示されたか否かを判定する。
【0389】
グループ管理機能部22は、ユーザにより電源のオフが指示されたため、ステップS501において、処理を終了させると判定した場合、ステップS502に進み、全ての既知のグループに属している他のノードとの間で、離脱処理を実行する。
【0390】
例えば、後述する処理により、所定のグループにノードAがクライアントとして既に参加しているとき、ステップS502においては、他のノードとの間で、図32を参照して説明した離脱処理が実行される。また、ノードAがサーバとしてグループを管理している場合、他のノードとの間で、図39を参照して説明した離脱処理が実行される。その後、グループ管理機能部22による管理処理は終了される。
【0391】
ステップS501において、グループ管理機能部22は、処理を終了しないと判定した場合、ステップS503に進み、グループ告知メッセージやサーバ候補告知メッセージ等の、所定のメッセージが送信されてきたか否かを判定する。
【0392】
グループ管理機能部22は、ステップS503において、所定のメッセージが送信されてきていないと判定した場合、ステップS501に戻り、それ以降の処理を実行し、一方、所定のメッセージが送信されてきたと判定した場合、ステップS504に進む。
【0393】
ステップS504において、グループ管理機能部22は、送信されてきたメッセージは、既知のグループに属するノードから送信されてきたものであるか否かを判定し、既知のグループに属するノードから送信されてきたものであると判定した場合、ステップS505に進み、ノードAの状態に応じて、所定の処理を実行する。
【0394】
ステップS505においては、送信されてきたグループ告知メッセージを受信する処理、グループに参加する処理、または、サーバからの離脱要求に応じて行われる処理等の、上述した各種の処理が実行される。その後、処理はステップS501に戻り、以上の処理が繰り返し実行される。
【0395】
ステップS504において、送信されてきたメッセージが、既知のグループに属するノードから送信されてきたものでないと判定した場合、グループ管理機能部22は、ステップS506に進み、次に、送信されてきたメッセージが、グループ告知メッセージであるか否かを判定する。
【0396】
グループ管理機能部22は、ステップS506において、送信されてきたメッセージがグループ告知メッセージであると判定した場合、ステップS507に進む。
【0397】
ステップS507において、グループ管理機能部22は、グループ管理テーブル(図8)に、グループ告知メッセージを送信してきたサーバが管理するグループの情報を追加し、自分自身の状態を初期状態とする(初期状態を維持する)。
【0398】
ステップS507の処理が行われた後、および、ステップS506において、送信されてきたメッセージがグループ告知メッセージでないと判定された場合、ステップS501に戻り、それ以降の処理が繰り返し実行される。
【0399】
図64は、グループに参加しているノードAのグループ管理機能部22により所定の周期で実行される処理を説明するフローチャートである。
【0400】
ステップS511において、グループ管理機能部22は、グループに参加してから所定時間が経過したか否かを判定し、所定時間が経過したと判定するまで待機する。
【0401】
グループ管理機能部22は、ステップS511において、所定時間が経過したと判定した場合、ステップS512に進み、自ら管理している、図示せぬメモリ等に保持されているノードリストを取得する。
【0402】
ステップS513において、グループ管理機能部22は、所定の変数iに「0」を設定し、ステップS514に進み、変数iの値が、ノードリストに記述されているグループの数よりも小さいか否か(ステップS513の処理を経た場合、所定のグループの情報がノードリストに記述されているか否か)、すなわち、ノードリストに記述されている全てのグループについて、ステップS515以降の処理を行ったか否かを判定する。
【0403】
ステップS514において、変数iの値が、ノードリストに記述されているグループの数よりも大きいと判定した場合、グループ管理機能部22は、ステップS511に戻り、それ以降の処理を繰り返し実行する。
【0404】
一方、グループ管理機能部22は、ステップS514において、変数iの値が、ノードリストに記述されているグループの数よりも小さいと判定した場合、ステップS515に進み、変数iに対応するグループにおいて、ノードAの状態が正式サーバであるか否かを判定する。
【0405】
後述するように、所定のタイミングで変数iが1ずつインクリメントされるため、変数i=0に対応するグループにおけるノードAの状態、変数i=1に対応するグループにおけるノードAの状態、変数i=2に対応するグループにおけるノードAの状態、・・・といったように、それぞれのグループにおけるノードAの状態が順次判定される。
【0406】
グループ管理機能部22は、ノードAの状態が正式サーバであると判定した場合、ステップS516に進み、他のノードに対して、グループ告知メッセージを送信する。すなわち、図15を参照して説明した処理がステップS516において行われる。
【0407】
グループ管理機能部22は、ステップS516において、グループ告知メッセージを送信した後、ステップS517に進み、変数iを「1」だけインクリメントし、ステップS514に進み、それ以降の処理を繰り返し実行する。すなわち、ノードAが属するそれぞれのグループについて、ステップS515以降の処理が繰り返し実行される。
【0408】
なお、ノードAがサーバであり、変数iがグループの数よりも小さいか否かを判定し、小さいと判定した場合に、グループ告知メッセージを送信する処理(ステップS514乃至S517のループ処理)は、例えば、2秒周期で行われる。
【0409】
グループ管理機能部22は、ステップS515において、ノードAの状態が正式サーバでないと判定した場合、ステップS518に進み、そのとき設定されている変数iに対応するグループにおいて、最後にグループ告知メッセージを受信してから、例えば、10秒などの所定の時間が経過したか否かを判定する。
【0410】
グループ管理機能部22は、ステップS518において、所定の時間が経過していないと判定した場合、ステップS517に進み、それ以降の処理を繰り返し実行し、一方、最後にグループ告知メッセージを受信してから所定の時間が経過したと判定した場合、ステップS519に進む。
【0411】
ステップS519において、グループ管理機能部22は、変数iに対応するグループに、クライアントとして参加しているか否かを判定し、クライアントとして参加していると判定した場合、ステップS520に進み、ノードAの状態を、参加(図5のState5)からサーバ候補B(State6)に遷移させる。そのとき、図31を参照して説明した調停処理が行われる。
【0412】
グループ管理機能部22は、ステップS519において、クライアントとしてグループに参加していないと判定した場合、ステップS521に進み、グループ管理テーブルから、そのとき対象としている変数iに対応するグループの情報を削除する。
【0413】
ステップS520,S521の処理が行われた後、処理はステップS517に進み、それ以降の処理が繰り返し実行される。以上の処理が周期的にグループ管理機能部22により実行され、ノードAの状態が管理される。
【0414】
以上においては、各ノードにおいて利用される優先順位は、生成された乱数に基づいて設定されるとしたが、サーバ専用ノードに対してのみ割り当てられる順位の範囲、サーバ・クライアント兼用ノードに対してのみ割り当てられる順位の範囲、および、クライアント専用ノードに対してのみ割り当てられる順位の範囲などのように、ノードの属性に応じて、割り当てられる優先順位の範囲が予め設定されているようにしてもよい。
【0415】
この場合、例えば、サーバ専用ノードに対して0乃至63の優先順位が割り当てられ、サーバ・クライアント兼用ノードに対して64乃至128の優先順位が割り当てられる。また、それ以降の128乃至255の優先順位は、クライアント専用ノードに対して割り当てられる。
【0416】
このように、優先順位の範囲を予め設定しておくことにより、異なる属性を有するノードが混在する場合、より効率的に調停を行うことができ、1つのサーバを容易に決定することが可能となる。
【0417】
なお、優先順位の範囲は、0乃至255の範囲に限られるものではない。
【0418】
各ノードの優先順位は、乱数に基づいて設定されるだけでなく、それ以外の様々な方法により設定されるようにしてもよい。例えば、機器に予め組み込まれているようにしてもよいし、電源が投入される度に設定されるようにしてもよい。
【0419】
また、以上においては、各ノード間でメッセージを送受信するネットワーク4がIEEE802.11a,802.11bなどに準拠した無線LANなどである場合について説明したが、ネットワーク4を、例えば、ハードウェアが存在することなく、ソフトウェアのみで仮想的に形成されるネットワークや、通信機能同士をソフトウェアのインタフェースで直接結合して構成されるネットワークとすることも可能である。
【0420】
また、ノード1乃至ノード3(ノードA乃至ノードC)は、パーソナルコンピュータやPDAにより構成される場合について説明したが、これらのノードは、CPUと記憶装置のみからなる機器、或いは、1チップのLSI(Large Scale Integrated
Circuit)により構成することも可能である。
【0421】
さらに、以上においては、グループを管理するサーバは、必ず1つであるとしたが、グループを管理するサーバと、サービスを提供するサーバがそれぞれ用意されたり、サービスを提供するサーバが複数用意されるなど、複数のサーバが1つのネットワーク上に用意されるようにしてもよい。
【0422】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。この場合、そのソフトウェアを実行させるノードは、例えば、図65に示されるようなパーソナルコンピュータにより構成される。図65に示される構成は、図2の構成を、より詳細に表したものに相当する。
【0423】
図65において、CPU91は、ROM(Read Only Memory)92に記憶されているプログラム、または、記憶部98からRAM(Random Access Memory)93にロードされたプログラムに従って各種の処理を実行する。RAM93にはまた、CPU91が各種の処理を実行する上において必要なデータなどが適宜記憶される。
【0424】
CPU91、ROM92、およびRAM93は、バス94を介して相互に接続されている。このバス94にはまた、入出力インタフェース95も接続されている。
【0425】
入出力インタフェース95には、キーボード、マウスなどよりなる入力部96、CRT(Cathode Ray Tube),LCD(Liquid Crystal Display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部97、ハードディスクなどより構成される記憶部98、および、通信部99(通信部12)が接続されている。通信部99は、ネットワーク4を介しての通信処理を行う。
【0426】
入出力インタフェース95にはまた、必要に応じてドライブ100が接続され、磁気ディスク101、光ディスク102、光磁気ディスク103、或いは半導体メモリ104などが適宜装着され、それから読み出されたコンピュータプログラムが、必要に応じて記憶部108にインストールされる。
【0427】
一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば、汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【0428】
この記録媒体は、図65に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク101(フレキシブルディスクを含む)、光ディスク102(CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む)、光磁気ディスク103(MD(登録商標)(Mini-Disk)を含む)、もしくは半導体メモリ104などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM92や、記憶部98に含まれるハードディスクなどで構成される。
【0429】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に従って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【0430】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表わすものである。
【0431】
【発明の効果】
本発明によれば、情報管理装置により提供されるサービスを、情報処理装置が利用するシステムを実現することができる。
【0432】
また、本発明によれば、情報管理装置がグループから離脱した場合であっても、効率的に、かつ、確実に、その機能を引き継ぐ情報処理装置を選択することができる。
【図面の簡単な説明】
【図1】本発明を適用した通信システムの構成例を示す図である。
【図2】図1のノードの構成例を示すブロック図である。
【図3】図1のノードの他の構成例を示すブロック図である。
【図4】図1のノードの機能構成例を示すブロック図である。
【図5】状態遷移の例を示す図である。
【図6】ノードリストの例を示す図である。
【図7】ノードリストの他の例を示す図である。
【図8】グループ管理テーブルの例を示す図である。
【図9】個別グループ管理テーブルの例を示す図である。
【図10】ノードリストの例を示す図である。
【図11】メッセージのフォーマットの例を示す図である。
【図12】コマンドとコードの対応例を示す図である。
【図13】通信システムの処理を説明するシーケンスである。
【図14】図13の処理において送受信されるメッセージの例を示す図である。
【図15】図13のノードAの処理を説明するフローチャートである。
【図16】図15の処理に対応して実行される、ノードBの処理を説明するフローチャートである。
【図17】ノードCのグループ開始処理を説明するフローチャートである。
【図18】図17のステップS52において実行される処理を説明するシーケンスである。
【図19】図18の処理において送受信されるメッセージの例を示す図である。
【図20】図18の処理において送受信される他のメッセージの例を示す図である。
【図21】図18の処理において送受信されるさらに他のメッセージの例を示す図である。
【図22】図18の処理において送受信されるメッセージの例を示す図である。
【図23】図18の処理において送受信される他のメッセージの例を示す図である。
【図24】図18のノードCの処理を説明するフローチャートである。
【図25】図18のノードAの処理を説明するフローチャートである。
【図26】図17のステップS54において実行される処理を説明するシーケンスである。
【図27】図26の処理において送受信されるメッセージの例を示す図である。
【図28】図26の処理において送受信される他のメッセージの例を示す図である。
【図29】図26の処理において送受信されるさらに他のメッセージの例を示す図である。
【図30】図26の処理において送受信されるメッセージの例を示す図である。
【図31】図26のノードAの処理を説明するフローチャートである。
【図32】クライアントがグループから離脱する処理を説明するシーケンスである。
【図33】図32の処理において送受信されるメッセージの例を示す図である。
【図34】図32の処理において送受信される他のメッセージの例を示す図である。
【図35】図32の処理において送受信されるさらに他のメッセージの例を示す図である。
【図36】図32の処理において送受信されるメッセージの例を示す図である。
【図37】図32のノードCの処理を説明するフローチャートである。
【図38】図32のノードAの処理を説明するフローチャートである。
【図39】サーバがグループから離脱する処理を説明するシーケンスである。
【図40】図39の処理において送受信されるメッセージの例を示す図である。
【図41】図39の処理において送受信される他のメッセージの例を示す図である。
【図42】図39の処理において送受信されるさらに他のメッセージの例を示す図である。
【図43】図39の処理において送受信されるメッセージの例を示す図である。
【図44】図39の処理において送受信される他のメッセージの例を示す図である。
【図45】図39の処理において送受信されるさらに他のメッセージの例を示す図である。
【図46】図39のノードAの処理を説明するフローチャートである。
【図47】図39のノードBの処理を説明するフローチャートである。
【図48】サーバがグループから離脱する他の処理を説明するシーケンスである。
【図49】図48の処理において送受信されるメッセージの例を示す図である。
【図50】図48の処理において送受信される他のメッセージの例を示す図である。
【図51】図48の処理において送受信されるさらに他のメッセージの例を示す図である。
【図52】図48の処理において送受信されるメッセージの例を示す図である。
【図53】図48の処理において送受信される他のメッセージの例を示す図である。
【図54】ノードの他の機能構成例を示すブロック図である。
【図55】ノードAとノードB間で行われる処理を説明するシーケンスである。
【図56】図55の処理で用いられるAPIの例を示す図である。
【図57】図55の処理で送信されるデータの例を示す図である。
【図58】図55の処理で用いられるAPIの他の例を示す図である。
【図59】ノードAとノードB間で行われる他の処理を説明するシーケンスである。
【図60】図59の処理で用いられるAPIの例を示す図である。
【図61】図59の処理で送信されるデータの例を示す図である。
【図62】図59の処理で用いられるAPIの他の例を示す図である。
【図63】グループ管理機能部の処理を説明するフローチャートである。
【図64】グループ管理機能部の他の処理を説明するフローチャートである。
【図65】記録媒体の例を示す図である。
【符号の説明】
1乃至3 ノード, 4 ネットワーク, 11 演算処理部, 12 通信部, 21 通信機能部, 22 グループ管理機能部, 22A メッセージ管理部, 22B 状態管理部, 22C リスト管理部, 23 サーバ機能部, 24 クライアント機能部, 101 磁気ディスク, 102 光ディスク, 103 光磁気ディスク, 104 半導体メモリ
Claims (2)
- 複数の情報処理装置が無線ネットワークを介して接続されることによって構成される通信システムにおいて、
サーバとして機能する1つの情報処理装置は、所定の周期で、自身が管理するグループにクライアントとして属する全ての情報処理装置に対して、設定した各クライアントの優先順位を含むメッセージであるグループ告知メッセージを送信し、
クライアントとして機能する各情報処理装置は、サーバとして機能する情報処理装置から送信されてきた前記グループ告知メッセージを受信し、
サーバとして機能する情報処理装置から送信されるべき前記グループ告知メッセージが送信されてこないことによって、サーバとして機能する情報処理装置の離脱が発生したことを判断し、
自身の優先順位を含む、自身がサーバ候補であることを通知するメッセージであるサーバ候補告知メッセージをクライアントとして機能する他の全ての情報処理装置に対して送信し、
クライアントとして機能する他の全ての情報処理装置から送信されてきた前記サーバ候補告知メッセージを受信し、
自身に対して設定された優先順位と、受信した前記サーバ候補告知メッセージに含まれる他の情報処理装置に設定された優先順位とを比較し、最も高い優先順位が設定されている情報処理装置は、
新たにサーバとして機能するように状態を遷移させ、自身の情報のみが記述されたメッセージであるサーバ移動通知メッセージを送信し、
自身が管理するグループにクライアントとして属する全ての情報処理装置に対して、各クライアントの優先順位を含むメッセージである前記グループ告知メッセージを送信し、
前記サーバ移動通知メッセージを受信したクライアントとして機能する情報処理装置は、新たにサーバとして機能する情報処理装置から送信されてきた前記グループ告知メッセージを受信する
通信システム。 - 複数の情報処理装置が無線ネットワークを介して接続されることによって構成される通信システムの通信方法において、
サーバとして機能する1つの情報処理装置が、所定の周期で、自身が管理するグループにクライアントとして属する全ての情報処理装置に対して、設定した各クライアントの優先順位を含むメッセージであるグループ告知メッセージを送信し、
クライアントとして機能する各情報処理装置が、サーバとして機能する情報処理装置から送信されてきた前記グループ告知メッセージを受信し、
サーバとして機能する情報処理装置から送信されるべき前記グループ告知メッセージが送信されてこないことによって、サーバとして機能する情報処理装置の離脱が発生したことを判断し、
自身の優先順位を含む、自身がサーバ候補であることを通知するメッセージであるサーバ候補告知メッセージをクライアントとして機能する他の全ての情報処理装置に対して送信し、
クライアントとして機能する他の全ての情報処理装置から送信されてきた前記サーバ候補告知メッセージを受信し、
自身に対して設定された優先順位と、受信した前記サーバ候補告知メッセージに含まれる他の情報処理装置に設定された優先順位とを比較し、最も高い優先順位が設定されている情報処理装置が、
新たにサーバとして機能するように状態を遷移させ、自身の情報のみが記述されたメッセージであるサーバ移動通知メッセージを送信し、
自身が管理するグループにクライアントとして属する全ての情報処理装置に対して、各クライアントの優先順位を含むメッセージである前記グループ告知メッセージを送信し、
前記サーバ移動通知メッセージを受信したクライアントとして機能する情報処理装置が、新たにサーバとして機能する情報処理装置から送信されてきた前記グループ告知メッセージを受信する
通信方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002366519A JP4284993B2 (ja) | 2002-12-18 | 2002-12-18 | 通信システムおよび方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002366519A JP4284993B2 (ja) | 2002-12-18 | 2002-12-18 | 通信システムおよび方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004199349A JP2004199349A (ja) | 2004-07-15 |
JP4284993B2 true JP4284993B2 (ja) | 2009-06-24 |
Family
ID=32763698
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002366519A Expired - Fee Related JP4284993B2 (ja) | 2002-12-18 | 2002-12-18 | 通信システムおよび方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4284993B2 (ja) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006091135A (ja) * | 2004-09-21 | 2006-04-06 | Fuji Xerox Co Ltd | 画像形成装置 |
US7444409B2 (en) | 2005-01-21 | 2008-10-28 | Research In Motion Limited | System and method for determining a designated connection between components of computing devices |
JP4561704B2 (ja) * | 2005-08-09 | 2010-10-13 | ソニー株式会社 | 無線通信システム、端末およびその状態報知方法ならびにプログラム |
US9292832B2 (en) * | 2013-02-25 | 2016-03-22 | Qualcomm Incorporated | Collaborative intelligence and decision-making in an IoT device group |
-
2002
- 2002-12-18 JP JP2002366519A patent/JP4284993B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2004199349A (ja) | 2004-07-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7097525B2 (ja) | モノのインターネットのリソースサブスクリプション方法、デバイス、およびシステム | |
KR101474840B1 (ko) | UPnP 기반의 네트워크 시스템 및 그 제어 방법 | |
JP3654360B2 (ja) | 制御システムおよび方法、情報処理装置および方法、情報処理端末および方法、記録媒体、並びにプログラム | |
KR100493898B1 (ko) | 피제어 디바이스의 리스트를 제공하는 네트워크 장치,시스템 및 방법 | |
TWI404376B (zh) | 點對點之資料中繼 | |
JP5638624B2 (ja) | ピアツーピアネットワーク環境における効率的なサービス広告及び発見 | |
US8060588B2 (en) | Home network apparatus and system for cooperative work service and method thereof | |
JP2003271531A (ja) | メッセージサーバ、メッセージシステム、プレゼンス情報管理方法及びプログラム | |
Banerjee et al. | Self-organizing topology for energy-efficient ad-hoc communication networks of mobile devices | |
Osamy et al. | ADSDA: adaptive distributed service discovery algorithm for internet of things based mobile wireless sensor networks | |
JP2010532117A (ja) | 通信ネットワークにおけるデータ管理のための方法およびシステム | |
JP4284993B2 (ja) | 通信システムおよび方法 | |
JP2004102506A (ja) | プログラム、情報処理方法および装置 | |
US11190436B2 (en) | Thread network control | |
JP2013123126A (ja) | Dlna対応機器およびその探索方法 | |
da Silva Campos et al. | On the design of UPnP gateways for service discovery in wireless sensor networks | |
CN115996187A (zh) | 路由信息处理方法、装置、路由信息交互系统和路由设备 | |
JP2005252596A (ja) | 物理的信頼度を用いたp2pネットワーク構成方法及び接続状態管理装置 | |
Al-Karkhi | Task Recovery in Self-Organised Multi-Agent Systems for Distributed Domains | |
JP3826735B2 (ja) | 分散システムによるサービス提供方法及び分散システムを構成する機器 | |
JPWO2006043411A1 (ja) | 通信装置および端末存在確認方法 | |
JP2008521083A (ja) | コンフィギュレーションを提供する方法、サーバ、ソフトウェア、装置及び信号 | |
EP2090030B1 (en) | System and method for managing network connectivity disruptions in a multi-homed UPNP device | |
Carvalho | In-stream data processing for tactical environments | |
CN100574309C (zh) | 事件管理系统及方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050930 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080715 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080912 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081202 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090127 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090303 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090316 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120403 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120403 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120403 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130403 Year of fee payment: 4 |
|
LAPS | Cancellation because of no payment of annual fees |