JP2005276181A - 動的ピアツーピア環境における相互排除技法 - Google Patents

動的ピアツーピア環境における相互排除技法 Download PDF

Info

Publication number
JP2005276181A
JP2005276181A JP2005045429A JP2005045429A JP2005276181A JP 2005276181 A JP2005276181 A JP 2005276181A JP 2005045429 A JP2005045429 A JP 2005045429A JP 2005045429 A JP2005045429 A JP 2005045429A JP 2005276181 A JP2005276181 A JP 2005276181A
Authority
JP
Japan
Prior art keywords
client
clients
logical
replica
peer
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.)
Granted
Application number
JP2005045429A
Other languages
English (en)
Other versions
JP4837929B2 (ja
Inventor
Qiao Lian
リアン チィヤオ
Shiding Lin
リン シディング
Zheng Zhang
ティアン ティエン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of JP2005276181A publication Critical patent/JP2005276181A/ja
Application granted granted Critical
Publication of JP4837929B2 publication Critical patent/JP4837929B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/526—Mutual exclusion algorithms
    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F24—HEATING; RANGES; VENTILATING
    • F24F—AIR-CONDITIONING; AIR-HUMIDIFICATION; VENTILATION; USE OF AIR CURRENTS FOR SCREENING
    • F24F13/00—Details common to, or for air-conditioning, air-humidification, ventilation or use of air currents for screening
    • F24F13/02—Ducting arrangements
    • F24F13/029—Duct comprising an opening for inspection, e.g. manhole
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
    • H04L67/1065—Discovery involving distributed pre-established resource-based relationships among peers, e.g. based on distributed hash tables [DHT] 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Combustion & Propulsion (AREA)
  • Mechanical Engineering (AREA)
  • Chemical & Material Sciences (AREA)
  • Computer And Data Communications (AREA)
  • Hardware Redundancy (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

【課題】 動的ピアツーピア環境において使用するための相互排除技法を提供する。
【解決手段】 一実施態様では、本発明の方法は、複数の論理的レプリカのそれぞれにおいて、クライアントから要求を受信することを含む。それぞれの論理的レプリカはキューを含み、１つのクライアントと排他的に関連づけられる。要求は、複数の資源のうちの１つにアクセスすることを求める要求である。論理的レプリカのうちの特定の１つが別の１つのクライアントと排他的に関連づけられていると、要求は、その特定の論理的レプリカのキューに格納される。
【選択図】 図１

Description

本発明は、包括的にはピアツーピア（peer-to-peer）ネットワークに関し、より詳細には、動的ピアツーピア環境における相互排除技法(mutual exclusion technique)に関する。
最近、ピアツーピアネットワークが産学双方においてますます注目を集めている。ピアツーピアネットワークは、適応、自己組織化、負荷分散、フォールトトレランス(耐故障性)、低コスト、高可用性、スケーラビリティ（拡張可能性）等の多くの望ましい特徴を備え、大規模な資源（リソース）のプール（集まり）を提供するように構成することができる。ピアツーピアネットワークは、ピアツーピアウェブサイトを通じてのダウンロードのために利用可能なものとして参照される楽曲をピアがダウンロードすること等によって、大量のデータを共有するための人気のある方法として出現した。
複数のクライアントによる使用のために資源を提供する場合、２つ以上のクライアントが特定の資源へのアクセスを希望する状況が生じることがある。これは「衝突（コリジョン）」とも呼ばれる。相互排除技法とは、特定の資源へのアクセスを希望する相異なるクライアントが衝突して望ましくない相互作用を引き起こすことがないように、資源を共有するために用いられ得る技法のことである。相互排除技法を用いることにより、クライアントは、使われている特定の相互排除技法によって指定されるところに従って、資源にアクセスする「権利」を取得することができる。
相互排除技法の一例として、セマフォ（semaphore）の利用がある。セマフォは、各クライアントがチェックしてから変更することができる値である。見出される値に応じて、クライアントは、資源を使用することができる場合もあり、あるいは、既に使用中であることを知り再試行する場合もある。通常、セマフォを使用するクライアントは、その値をチェックして、他のクライアントが資源を使用していない場合、その資源がそのクライアントによって使用されていることを反映するようにその値を変更し、その特定の資源が使用中であることを後のクライアントが「知る」ようにする。こうして、セマフォは、複数のクライアントが、特定のファイルへのアクセスを共有する場合のように、同一資源に対して競合するアクティビティ（活動）を調整し同期させるための技法を提供する。
I. Clarke, B. Wiley, O. Sanberg, and T. Hong 「Freenet: A Distributed Anonymous Information Storage and Retrieval System」（Proc. Int. Workshop on Design Issues in Anonymity and Unobservability, Springer Verlag, LNCS 2009, 2001） I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, H. Balakrishnan 「Chord A Scalable Peer-to-peer Lookup Service for Internet Applications」（Proc. ACM SIGCOMM'0l, San Diego, California, USA, 2001） S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker 「A Scalable Content-Addressable Network」（Proc. ACM SIGCOMM'0l, San Diego, California, USA, 2001） A. Rowstron and P. Druschel 「Pastry: Scalable, Decentralized Object Location and Routing for Large-Scale Peer-to-Peer Systems」（IFIP/ACM Int. Conf. Distributed Systems Platforms (Middleware), 2001） Tapestry。B. Y. Zhao, J. Kubiatowicz, and A. D. Joseph 「Tapestry: An Infrastructure for Fault-tolerant Wide-Area Location and Routing」（Technical Report No. UCB/CSD-01-1141, Univ. of California, Berkeley）。
しかし、従来の相互排除技法では、特定の資源の利用を希望するクライアント間の衝突によって引き起こされる問題が、クライアントの「貪欲な」挙動によって拡大してしまう。例えば、複数のクライアントがある資源へのアクセスを希望し、相互排除技法の使用により１つのクライアントのみがその資源にアクセスする権利を「勝ち取る」場合を考える。その場合、資源にアクセスする権利が得られなかった「敗者の」クライアントは、要求を継続的に再送することによって権利を獲得しようと再試行する。要求の反復再送は、資源を提供するピアと、資源へのアクセスを取得しようとするクライアントのハードウェアおよびソフトウェアの資源を浪費する。また、反復再送は、クライアントとピアの間のネットワーク帯域幅も浪費する。この問題は、同じ資源へのアクセスを希望するクライアントの数が増大するにつれてさらに拡大し、一層非効率になるという結果を招いていた。
さらに、ピアツーピアネットワーク内の複数のクライアントと複数のピアとの間の通信は、互いに異なる通信遅延を受けることがある。例えば、複数のクライアントから受信される、特定の資源にアクセスすることを求める要求は、クライアントとピアの間の通信遅延の変動により、異なる時刻に異なるピアに到達することがある。
したがって、動的ピアツーピア環境において使用するための相互排除技法の必要性が引き続き存在している。
動的ピアツーピア環境において使用するための相互排除技法が記載される。一例では、相互排除技法はクライアントとピアの間の通信遅延の変動を解決するために、キュー（queue:待行列）を利用する。ピアが、要求がいつ受信されたかについての一貫したビュー（一覧）を得ることにより、キューに基づいて資源へのアクセスを与えることができるように、要求を格納するために、ピアによってキューは利用されることが可能である。別の例では、クライアントが資源にアクセスすることを求める要求を継続的に再送しようとしないように、キューに要求を格納することによって、キューの使用によりクライアントの「貪欲な」挙動を低減する。
一実施態様では、本発明の方法は、複数の論理的レプリカ（logical replica）のそれぞれにおいて、クライアントから要求を受信することを含む。それぞれの論理的レプリカ(複製)はキューを含み、１つのクライアントと排他的に関連づけられる。要求は、複数の資源のうちの１つにアクセスすることを求める要求である。論理的レプリカのうちの特定の１つが別の１つのクライアントと排他的に関連づけられていると、要求は、その特定の論理的レプリカのキューに格納される。
さらなる実施態様では、本発明の方法は、複数の論理的レプリカへの通信のためにクライアントが要求を形成することを含む。要求は、複数の資源のうちの１つの資源に対する要求である。クライアントは、複数の論理的レプリカから複数の応答を受信し、クライアントが上記１つの資源の利用を許可されるのかどうかを判断する。クライアントは、別のクライアントが上記１つの資源の利用を許可されている場合には、別の要求を送信することなく、別の複数の応答を待機する。
別の実施態様では、本発明の方法は、複数のクライアントのそれぞれにおいて、複数の論理的レプリカへの通信のために、複数の資源のうちの１つの資源を求める要求を形成することを含む。複数の応答が、複数の論理的レプリカから複数のクライアントで受信される。それぞれのクライアントは、上記複数の応答を使用することによって、複数のクライアントのうちの１つが上記１つの資源の利用を許可されているかどうかを判断する。複数のクライアントのいずれも上記１つの資源の利用を許可されていない場合には、複数の論理的レプリカのうちの１つまたは複数への通信のために、移譲メッセージ（yield message）が、少なくとも１つのクライアントによって形成される。移譲メッセージにより、１つまたは複数の論理的レプリカのそれぞれは、１つまたは複数のクライアントから受信されたこれまでの要求を格納するそれぞれのキューから別の応答を形成する。
さらに別の実施態様では、ピアツーピアネットワークは、コーラムコンセンサス(quorum consensus：定足数合意)プロトコルを用いて資源アクセスを許可する論理的レプリカを含む。
さらに別の実施態様では、本発明のシステムは、ネットワーク、複数のクライアント、およびネットワークに通信可能に結合した複数のコンピューティングデバイスを含む。複数のコンピューティングデバイスは、複数の論理的レプリカを含む。それぞれの論理的レプリカは、任意の一特定時刻において複数のクライアントのうちの１つのクライアントと排他的に関連づけられるように構成される。また、それぞれの論理的レプリカは、その論理的レプリカが別のクライアントと排他的に関連づけられる時に資源にアクセスするために、１つのクライアントからの要求を格納するためのキューも含む。
明細書および図面の全体を通じて、同一番号は同一のコンポーネントおよび特徴部を参照するために用いられる。
［概要］
動的ピアツーピア環境において使用するための相互排除技法が記載される。一例では、相互排除技法はクライアントとピアの間の通信遅延の変動を解決するためにキューを利用する。既に述べたように、複数のクライアントから受信される、特定の資源にアクセスすることを求める要求は、クライアントとピアの間の通信遅延の変動により、異なる時刻に異なるピアに到達することがある。したがって、ピアは、資源へのアクセスを要求しているクライアントについて、それぞれのクライアントがそのようなアクセスを要求した場合等には、一貫したビューを有しないことがある。キューは、ピアが、要求がいつ受信されたかについての一貫したビューを得ることにより、キューに基づいて資源へのアクセスを提供することができるように、要求を格納するためにピアによって利用されることが可能である。
さらに、キューは、クライアントの「貪欲な」挙動を低減する。例えば、クライアントが資源にアクセスすることを求める要求を継続的に再送しようとしないように、クライアントからの要求を格納するためにキューを利用することができる。したがって、クライアントは、要求に対するピアからの応答を待機する「アクティブウェイティング（稼動中待機）」の状態にあるとみなしてもよい。要求に対する応答が、規定期間（specified period）後に受信されない場合にクライアントが要求を再送することができるように、インフォームドバックオフメカニズム(informed backoff mechanism：情報に基づく一時退避機構)を使用してもよい。
［例示的環境］
図１は、ピアツーピアネットワークを提供するように構成された環境１００を示す例示的実施態様の図である。環境１００は、複数のクライアント１０２（ａ）を含む。ここでａは１からＡまでの任意の整数をとり得る。複数のクライアント１０２（ａ）は、ネットワーク１０６を通じて複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）に通信可能に接続する。この実施態様では、複数のクライアント１０２（ａ）および複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）はそれぞれ、ネットワーク１０６内のノードを表す。ノードは、他のノードにデータを提供する再配信ポイント、および／または、データの宛先および／またはソースであるエンドポイントのような、データを送信するための接続ポイントとみなしてもよい。
複数のクライアント１０２（ａ）および複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）は、さまざまな方法で構成され得る。例えば、クライアント１０２（ａ）およびコンピューティングデバイス１０４（１）〜１０４（Ｂ）は、無線電話機（例えばコンピューティングデバイス１０４（１））、タブレットコンピュータ（例えばコンピューティングデバイス１０４（２））、ノートブックコンピュータ（例えばコンピューティングデバイス１０４（３））、デスクトップコンピュータ（例えばコンピューティングデバイス１０４（４））、サーバ（例えばコンピューティングデバイス１０４（５）〜１０４（６））、メインフレームコンピュータ（例えばコンピューティングデバイス１０４（Ｂ））、ならびに移動局、娯楽機器、セットトップボックス等の他のコンピューティングデバイスのように、ネットワーク１０６を通じて通信可能なコンピュータとして構成されてもよい。例示的なコンピューティングデバイスについては、さらに図７に関して説明される。したがって、複数のクライアント１０２（ａ）およびコンピューティングデバイス１０４（１）〜１０４（Ｂ）は、大量のメモリおよびプロセッサ資源を有するフル資源デバイス（例えば、パーソナルコンピュータ、ハードディスク付きテレビレコーダ）から、メモリおよび／またはプロセッサ資源が限定された低資源デバイス（例えば従来のセットトップボックス）までさまざまであり得る。また、クライアント１０２（ａ）は、そのクライアントを操作する人および／またはエンティティに関係していてもよい。すなわち、クライアント１０２（ａ）は、ユーザおよび／またはマシンを含む論理クライアントを記述するものであってもよい。
ネットワーク１０６は、ピアツーピアネットワークとして構成される。ピアツーピアネットワークにより、ネットワーク１０６のノードは、それぞれのノード、すなわち、複数のクライアント１０２（ａ）および複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）に配置された共有資源にアクセスすることができる。これまでに知られ、使用されているピアツーピアネットワークの例としては以下のものがある。
・フリーネット（Feenet；草の根ネット、無料ネット）、非特許文献１に記載。
・コード(Chord)、 非特許文献２に記載。
・キャン(CAN)、 非特許文献３に記載。
・ペストリー(Pastry)、 非特許文献４に記載。
・タペストリー(Tapestry)、非特許文献５に記載。
ピアツーピアネットワークは、冗長性およびフォールトトレランス（耐故障性）のようなさまざまな特徴を備えることができる。例えば、ピアツーピアネットワークに格納されたデータは、データがピアツーピアネットワークのノードによって複製されるにつれて徐々に拡散し得る。したがって、ピアツーピアネットワークにおいてデータは高度に冗長となるため、データの信頼性および可用性を向上させることができる。
ピアツーピアネットワークを用いて、データ、処理サイクル、データストレージ等のようなさまざまな資源（リソース）を交換することができる。したがって、ピアツーピアネットワークを利用して、複数のクライアント１０２（ａ）および複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）の集団パワーを活用することができる。ピアツーピアは、各ピアすなわち「メンバ」が、別のメンバと直接に、および／または介在するサーバを通じて、通信することができる通信モデルである。
ネットワーク１０６は、クライアント１０２（ａ）と複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）の間でメッセージをルーティングするためのインタフェースとして作用する分散ハッシュテーブル（ＤＨＴ）１０８を含む。ＤＨＴ１０８は、（key(キー)，value(値)）の対を格納するハッシュテーブルデータ構造の分散バージョンとみなすことができる。例えば、キーはファイル名に対応し、値はファイルの内容に対応するとしてよい。ネットワーク１０６内の各ピア、例えばコンピューティングデバイス１０４（１）〜１０４（Ｂ）は、（key，value）の対のペアのサブセットを格納する。こうして、ＤＨＴ１０８は、対応するキーを受け持つノードを見つけるために利用される。すなわち、ＤＨＴ１０８は、クライアント１０２（ａ）と複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）の間でメッセージをルーティングするために、キーをノードにマッピングする。ＤＨＴ１０８の「上（on-top）」に、ファイル共有サービス、アーカイブ(archival)ストレージサービス（例えばウェブアーカイビング）、データベース、名前付けサービス、サービスディスカバリ、アプリケーション層マルチキャスト、イベント通知、チャットサービス、ランデブー方式の通信、問合せと索引付け、データ公開／サブスクリプション等のようなさまざまなサービスを構築することができる。
ＤＨＴ１０８は、複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）によって提供される資源を複数のバケット１１０（１）〜１１０（８）に分割する。複数のバケット１１０（１）〜１１０（８）のそれぞれは、資源のゾーンとみなすことができる。例えば、前述のように、ＤＨＴ１０８は資源をキーと関連づける。キーは、ＤＨＴ１０８を用いて複数のバケット１１０（１）〜１１０（８）のうちの特定の１つを見つけるためにハッシュされる。複数のバケット１１０（１）〜１１０（８）は、さまざまな方法で提供され得る。例えば、図１では、バケット１１０（１）は、コンピューティングデバイス１０４（１）によって提供されるものとして図示されている。同様に、バケット１１０（２）、１１０（３）、１１０（４）、１１０（５）、１１０（６）はそれぞれ、コンピューティングデバイス１０４（２）、１０４（３）、１０４（４）、１０４（５）、１０４（６）によって提供される。さらに、１つのコンピューティングデバイスが複数のバケットを提供してもよい。これについて、図１では、バケット１１０（７）、１１０（８）がコンピューティングデバイス１０４（Ｂ）によって提供されるものとして図示されている。
環境１００は、ＤＨＴ１０８を使用するピアツーピアネットワークとして構成される場合、参加するピアを構成員とする仮想空間を提供する。この仮想空間は、メンバシップ（会員）変更中の過渡的期間中を除いて、「穴」がないように提供することができる。例えば、コンピューティングデバイス１０４（６）が、ハードウェア、ソフトウェア、および／またはネットワークのエラー等により利用不能となった場合、コンピューティングデバイス１０４（６）によって提供されるバケット１１０（６）は、別のコンピューティングデバイス、例えばコンピューティングデバイス１０４（Ｂ）によって提供され得る。このように、ネットワーク１０６は動的であるため、ネットワークを途絶させることなくノードがネットワークに出入りすることができる。
ＤＨＴ１０８を用いると、複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）から集合的に、穴のない論理空間を形成することができるので、論理的レプリカ１１２（１）〜１１２（４）（レプリカ）のセットを実装することができる。例えば、与えられた資源Ｒに対して、それに関連づけられたコンピューティングデバイスＣＳ（Ｒ）は〈論理的〉であることが可能である。例として、「／ｆｏｏ／ｂａｒ：ｉ」という名前のｎ個のレプリカがあるとする。ここで、ｉ∈［１．．ｎ］である。これらの名前をハッシュしてキーを導出し、各キーのホスティングノードをレプリカとすることができる。名前付けと実際のコンピューティングデバイスの分離により、「仮想コンピューティングデバイス」が提供される。この仮想コンピューティングデバイスは、「always〈常時〉」利用可能とみなせるが、ランダムな時点でメモリ喪失を被る可能性がある。さらに、後で図３および図６に関してさらに詳細に説明するように、複数のレプリカの導入は、クライアントとこれらのレプリカの間の遅延が変動することにより、パフォーマンスに影響を及ぼし得ることを意味する。
このように、クライアント１０２（ａ）の視点から見ると、レプリカ１１２（１）〜１１２（４）は常時利用可能、例えば「オンライン」である。しかし、前に述べたように、レプリカ１１２（１）〜１１２（４）のいずれも、時に完全なメモリ喪失を被る可能性がある。例えば、レプリカ１１２（１）〜１１２（４）のうちの特定の１つを提供するコンピューティングデバイス１０４（１）〜１０４（Ｂ）のうちの１つが利用不能となり、コンピューティングデバイス１０４（１）〜１０４（Ｂ）のうちの別のコンピューティングデバイスで置き換えられると、ランダムなリセットが起こることがある。
また、レプリカ１１２（１）〜１１２（４）は、複数のクライアントが同一資源にアクセスしようとする時に、その複数のクライアント１０２（ａ）のうちの２つ以上の間の衝突を管理するためのメカニズムを提供してもよい。例えば、レプリカ１１２（１）〜１１２（４）は、同一資源へのアクセスを希望する複数のクライアントのうちの１つにアクセスを許可するために用いられるコーラム（quorum）コンセンサスプロトコルを使用する相互排除技法を利用してもよい。この状況は、以下の説明の一部では「クリティカルセクション(critical section:重要域)」とも呼ばれ、数式および図面では「ＣＳ」と記載される。レプリカ１１２（１）〜１１２（４）は、クライアント１０２（ａ）がクリティカル（重要）な資源へのアクセスをシリアライズする（順番に並べる）のを助けるプロセスとみなしてもよい。レプリカは、〈仮想名〉によって識別され、これは環境１００全体に既知であるとしてもよい。レプリカが環境１００を離脱した場合（例えばクラッシュした場合）、「新規な」レプリカが古いレプリカを置き換え、同じ仮想名をとる。実際には、このような仮想名は、ドメインネームサーバによって、あるいはピアツーピアシステム内のＤＨＴ１０８等によって、実装することができる。このような仮想名前付けメカニズムのため、システム内のレプリカの数は、システムの寿命を通じて固定することができる。相互排除技法の実行については、図３〜図５に関してさらに説明される。
このように、環境１００は、クライアント１０２（ａ）によって「常時」利用可能とみなされるレプリカ１１２（１）〜１１２（４）を提供することができる。しかし、論理的レプリカ１１２（１）〜１１２（４）の内部状態は、ランダムにリセットされ得る。さらに、環境１００内のクライアント１０２（ａ）の数は予測不能であっても、非常に大きくてもよい。
クライアント１０２（ａ）およびレプリカ１１２（１）〜１１２（４）は、要求および応答のようなメッセージを用いることによって、ネットワーク１０６を通じて通信することができる。これについては、図６に関してさらに説明される。一実施態様では、クライアント１０２（ａ）およびレプリカ１１２（１）〜１１２（４）を通信可能に結合するネットワーク１０６は、信頼できなくてもよい。すなわち、メッセージが複製および／または喪失される可能性がある。以下の説明との関連では、クライアント１０２（ａ）およびレプリカ１１２（１）〜１１２（４）は両方ともＤＨＴ１０８内のピアである。しかし、別の実施態様では、レプリカ１１２（１）〜１１２（４）のみがＤＨＴ１０８内のピアとして認識される。
レプリカ１１２（１）〜１１２（４）は、さまざまな方法でコンピューティングデバイス１０４（１）〜１０４（Ｂ）によって提供される資源へのアクセスを許可するために利用することができる。例えば、それぞれのレプリカ１１２（１）〜１１２（４）が、「擬似先着順」で特定の資源へのアクセスの許可を与えることができる。例として、各レプリカ１１２（１）〜１１２（４）は、要求がクライアント１０２（ａ）からレプリカ１１２（１）〜１１２（４）によって受信された順序に基づいて、その特定の資源へのアクセスの許可を与えることができる。レプリカがクライアントに許可を与えた（すなわち投票した）場合、そのクライアントはそのレプリカの〈オーナ〉(owner)と呼ばれる。すなわち、レプリカは、そのように所有されている間は、別のクライアントによって所有されることができないように、そのクライアントと排他的に関連づけられる。レプリカのオーナシップ（所有権）の過半数を集めたクライアントは、相互排除プロトコルのその実行の〈勝者〉(winner)であるといい、それにより資源へのアクセスが許可される。応答の使用によるレプリカのオーナシップおよび投票については、図３および図６に関してさらに説明される。
７個のコンピューティングデバイス１０４（１）〜１０４（Ｂ）が図示されているが、多様なコンピューティングデバイスを環境内に実装することができる。さらに、複数のクライアント１０２（ａ）がピアツーピアネットワーク内の「ピア」として構成されてもよい。
［相互排除］
相互排除は、ピアツーピアＤＨＴを使用するように構成されたネットワーク環境の上に一般的なシステムおよびアプリケーションを実装するための基本的プリミティブ（primitive）の１つである。このようなプリミティブは、必要な時に１つまたは複数の任意の資源を保護するためにピアツーピアＤＨＴの上で実行されるアプリケーションが利用するための基本的サービスも提供することができる。例えば、相互排除は、ミュータブル（mutable:易変）分散ファイルシステムのための並行処理制御メカニズムを提供することができる。ノードの追加および／または削除のような図１の環境１００における変化をサポートするため、このようなプリミティブは、ピアツーピアＤＨＴの〈内部〉に実装される。したがって、相互排除プロトコルの実装は分散していてもよい。
ピアツーピア環境、例えば図１の環境１００のオープンで動的な性質は、さまざまな課題をもたらす。例えば、従来の相互排除プロトコルでは、ノード数が比較的少なく、一定である閉じた（クローズド）システムを仮定していることが多い。このような従来のシステム内のノードは、コンセンサス（合意）に達するために相互に通信する。しかし、この解決法は、クライアント数が予測不能の場合、および／または多数のクライアントを含む場合には、用いることができない。以下では、協調的ストラテジ（方策、戦略）を用いて遅延変動およびコンテンション（競合）を回避することによってクライアントとレプリカの間の高いネットワーク遅延変動を解決し、それによりスケーラビリティ（拡張可能性）およびロバスト性（堅牢性、信頼性）を達成する相互排除技法について説明する。また、レプリカの状態をインテリジェント（知的）に再構築することにより、レプリカのランダムなリセットに対処する〈インフォームドバックオフ〉メカニズムについて説明する。
［例示的プロトコル］
特定の資源に対する衝突する要求を解決するために利用可能な相互排除プロトコルについて説明する。例えば、クリティカルセクション（ＣＳ）（例えば特定の資源）の利用を希望している複数のクライアント１０２（ａ）のうちの２つ以上が、それぞれのレプリカ１１２（１）〜１１２（４）に要求を送信し、応答を待機する。それぞれのレプリカ１１２（１）〜１１２（４）は、それが他のクライアントによって所有されていない場合、リース（賃貸）を与える。それ以外の場合、それぞれのレプリカ１１２（１）〜１１２（４）は、要求を拒絶し、（拒絶された）要求側クライアントに対して、どのクライアント１０２（ａ）が現在のオーナであるかを通知する。ｎ個のレプリカのうちのｍ個を所有するクライアント１０２（ａ）がこのラウンドの勝者であり、したがってクリティカルセクション（ＣＳ）へのアクセスが許可されるように、コーラムコンセンサス技法を使用することができる。ここで、ｍはコーラムの数であり、ｎはレプリカの数である。コーラムは、ｍ＞ｎ／２等のさまざまな方法で決定することができる。従来、ＣＳへのアクセスが許可されないクライアント、すなわちそのラウンドの「敗者」は、獲得した票（もしあれば）を解放し、バックオフ（後退）し、要求を再試行していた。
しかし、レプリカ１１２（１）〜１１２（４）はランダムなリセットを被った後、過去の決定を忘却し、新たな要求を受けることがある。この「心変わり」の結果、相互排除が破れる可能性がある。例えば、ノードの平均寿命がＴであると仮定すると、ノードが期間ｔの間にクラッシュする確率はｔ／Ｔである。ｍ個の投票されたレプリカのうちの任意のｋ個がリセットする確率は次のとおりであることが示される。
Figure 2005276181
上式で示されるように、ｔの間に２ｍ−ｎ回以上のリセットが起こる場合に安全性が破れる。その確率は次のように表される。
Figure 2005276181
したがって、ｋ個までのレプリカのリセットを許容するには、ｎ＝３ｋ＋１およびｍ＝２ｋ＋１であるのが望ましい。そこで、設計上の選択事項として、ｍの値を大きくしてもよい。
図２は、図１のクライアント１０２（ａ）およびレプリカ１１２（ｉ）のアーキテクチャを示すシステム２００の例示的実施態様をさらに詳細に示す図である。ここで、ｉは１からＩまでの任意の整数をとり得る。クライアント１０２（ａ）は、クライアントＩＤ２０２および応答配列２０４を含むように示されている。クライアントＩＤ２０２は、レプリカ１１２（１）がクライアント１０２（ａ）を識別するためのものである。応答配列２０４は、図１の複数のレプリカ１１２（１）〜１１２（４）からの複数の応答２０６（ｉ）を格納するように構成される。例えば、応答２０６（ｉ）は、「ｉ番目」のレプリカ、すなわちレプリカ１１２（ｉ）から得られる応答を格納するために利用されることが可能であり、対応するレプリカのオーナ２０８（ｉ）を示すデータと、形成された応答２０６（ｉ）の元になった要求をレプリカが受信した時を示す関連するタイムスタンプ２１０（ｉ）を含む。
レプリカ１１２（ｉ）は、複数のクライアント１０２（ａ）のうちの（もしあれば）いずれのクライアントがレプリカ１１２（ｉ）を所有しているかを示すためのオーナシップフィールド２１２（ｉ）を保持する。オーナシップフィールド２１２（ｉ）は、図２に示すように「Ｃｏｗｎｅｒ」とも表される。オーナシップフィールド２１２（ｉ）の値が「ｎｉｌ」であることは、レプリカ１１２（ｉ）がクライアント１０２（ａ）のいずれかに対して投票していないことを意味する。すなわち、レプリカ１１２（ｉ）は、現在、クライアントと排他的に関連づけられていない。タイムスタンプフィールド２１２（ｉ）「Ｔｏｗｎｅｒ」は、要求がレプリカ１１２（ｉ）によって受信された時のタイムスタンプを格納する。
レプリカ１１２（ｉ）は、複数のクライアント１０２（ａ）から受信された要求２１６（ａ）を格納するキュー２１４（ｉ）を含む。キューに格納される各要求２１６（ａ）は、複数のクライアント１０２（ａ）の１つに対応することができる。キュー２１４（ｉ）は、それぞれの要求２１６（ａ）が受信された順序で要求２１６（ａ）を格納するように構成され得る。例えば、キュー２１４（ｉ）は、ランポート(Lamport)の論理クロックのようなクロックを利用して、それぞれの要求２１６（ａ）に対するタイムスタンプ（時刻印）２１８（ａ）を生成することができる。そして、キュー２１４（ｉ）は、それぞれのタイムスタンプ２１８（ａ）に基づいて、要求２１６（ａ）を編成することができる。別の例として、各要求は、クライアント１０２（ａ）自身によってタイムスタンプが付けられてもよい。図１のクライアント１０２（ａ）および複数のレプリカ１１２（１）〜１１２（４）のオペレーションの一例は、以下の実施態様に示される。
［例示的手続き］
以下では、前述のアーキテクチャを利用して実施され得る相互排除技法について説明する。各手続きの態様は、ハードウェア、ファームウェア、もしくはソフトウェア、またはそれらの組合せのいずれで実施してもよい。手続きは、１つまたは複数のデバイスによって実行されるオペレーションを指定するブロックのセットとして示される。
図３は、図１のクライアント１０２（ａ）がピアツーピアネットワーク内の複数のピアのうちの１つまたは複数によって提供される資源へのアクセスを要求する例示的実施態様における手続き３００を示す流れ図である。ブロック３０２で、クライアント１０２（ａ）は、要求３０４を形成し、複数のレプリカ１１２（１）〜１１２（４）のそれぞれに伝達する。複数のレプリカ１１２（１）〜１１２（４）のそれぞれがクライアント１０２（ａ）を互いに区別することができるように、要求３０４は、ピアツーピア環境において提供される複数の資源のうちの特定の１つを識別し、図２のクライアントＩＤ２０２を含む。
ブロック３０６で、レプリカ１１２（１）〜１１２（４）はオーナシップを判定する。例えば、それぞれのレプリカ１１２（１）〜１１２（４）が、それぞれのオーナシップフィールド２１２（１）〜２１２（４）について問い合わせてもよい。オーナシップフィールド２１２（１）〜２１２（４）の値は、どのクライアント（もしあれば）がそれぞれのレプリカ１１２（１）〜１１２（４）を所有するかを示す。例えば、レプリカ１１２（１）のオーナシップフィールド２１２（１）は仮想線で「ｎｉｌ（空）」であるように示されているが、これは、レプリカ１１２（１）が現在クライアントによって所有されていないことを示す。同様に、それぞれのレプリカ１１２（２）、１１２（３）のオーナシップフィールド２１２（２）、２１２（３）もまた、それぞれ「ｎｉｌ」値であるように示されている。したがって、レプリカ１１２（１）〜１１２（３）は、特定のクライアントによるオーナシップの「投票」がなされていない。
これに対して、レプリカ１１２（４）のオーナシップフィールド２１２（４）は、レプリカ１１２（４）がクライアント１０２（１）によって所有されていることを示す値を含むように示されている。このオーナシップの判定に基づいて、レプリカ１１２（４）はキュー２１４（４）に要求３０４を格納するので、クライアント１０２（ａ）は要求を再送する必要がない。これについては、図５に関してさらに詳細に説明する。
ブロック３０８で、それぞれのレプリカ１１２（１）〜１１２（４）が、それぞれの応答３１０〜３１６を形成し、クライアント１０２（ａ）に伝達する。それぞれの応答３１０〜３１６は、それぞれのレプリカ１１２（１）〜１１２（４）のオーナシップの指示を含む。例えば、それぞれの応答３１０〜３１６は、それぞれのレプリカ１１２（１）〜１１２（４）からのオーナシップフィールド（Ｃｏｗｎｅｒ）の値を含んでもよい。
ブロック３１８で、クライアント１０２（ａ）は、応答３１０〜３１６に基づいて資源へのアクセスが許可されるかどうかを判定する。例えば、レプリカ１１２（１）からの応答３１０は、レプリカ１１２（１）が別のクライアントによって所有されなかったことを示すブロック３０６での判定結果を含んでもよい。そのため、レプリカ１１２（１）は今度クライアント１０２（ａ）によって所有される。そのことは、ブロック３１８では、応答３１０に点線ボックスとクライアント１０２（ａ）を記述するテキストが含まれることで示されている。同様に、それぞれのレプリカ１１２（２）、１１２（３）からの応答３１２、３１４もまた、ブロック３０６でのそれぞれの判定結果を含む。例えば、応答３１２、３１４の両方とも、それぞれのレプリカ１１２（２）、１１２（３）が別のクライアントによって所有されなかったことを示しているので、両方のレプリカ１１２（２）、１１２（３）は今度クライアント１０２（ａ）によって所有される。しかし、応答３１６は、対応するレプリカ１１２（４）が別のクライアント、例えばクライアント１０２（１）によって所有されていることを示すブロック３０６での判定結果を含む。
クライアント１０２（ａ）は、応答３１０〜３１６に基づいて資源の利用が許可されるかどうかを判断するためにさまざまな相互排除技法を利用することができる。例えば、クライアント１０２（ａ）は、クライアント１０２（ａ）がｎ個のレプリカ１１２（１）〜１１２（４）のうちのｍ個のオーナシップを取得した場合に資源の利用が許可されるというコーラムコンセンサスプロトコルを使用してもよい。ここで、ｍはコーラムの数であり、ｎはレプリカの数である。すなわち、それぞれのレプリカ１１２（１）〜１１２（４）は、一度にいずれか１つの特定のクライアントと排他的に関連づけられるように構成される。この排他的関連づけを利用することにより、各レプリカは、現在の排他的関連づけが当該特定のクライアントのオーナシップフィールド（Ｃｏｗｎｅｒ）で示されるクライアントに「投票」することができる。
コーラムは、ｍ＞ｎ／２等のさまざまな方法で決定することができる。したがって、クライアント１０２（ａ）は、要求３０４に対するそれぞれの応答３１０〜３１６で示されるレプリカ１１２（１）〜１１２（４）のオーナシップに基づいて、特定の資源へのアクセスが許可されるかどうかを判定することができる。ブロック３０８に示した例では、ｍが３以下である場合、クライアント１０２（ａ）はレプリカ１１２（１）〜１１２（４）のオーナシップのコーラムを有するので、資源の利用が許可される。別の例として、ｍが４に等しい場合、クライアント１０２（ａ）は資源へのアクセスが許可されない。しかし、クライアント１０２（ａ）は、直ちに要求３０４を再送するのではなく、別の応答の受信を待機することができる。というのは、ブロック３０６で要求はキュー２１２（４）に格納されているからである。したがって、クライアント１０２（ａ）が勝っていない場合、クライアントは、レプリカ１１２（１）〜１１２（４）から次の応答を待機する「アクティブウェイティング」の状態に置かれる。キューの利用およびアクティブウェイティングについては、図４および図５に関してさらに説明される。
こうして、例示的手続き３００に示したように、相互排除技法は、応答間を調整するためにレプリカ１１２（１）〜１１２（４）が相互に通信しないように構成され得る。例えば、各レプリカは、自己のローカルな状態のみに基づいてクライアントへ自己の応答を送信することができる。これにより、レプリカ間での調整にかかる時間が節約されるので、クライアントがクリティカルセクションへのアクセスを許可される機会がより高速に提供される。したがって、クライアントは、レプリカからの決定を受動的に待機するのではなく、クライアント選択プロセスに能動的（アクティブ）に関わることができる。
図４は、複数の資源のうちの特定の１つの利用が許可されるかどうかをクライアントが判断する例示的実施態様における手続き４００を示す流れ図である。ブロック４０２で、クライアントは、複数の資源のうちの特定の１つを利用することを求める要求を形成する。要求は、クロック（例えばランポートの論理クロック）から得られるタイムスタンプと、クライアントのＩＤ（例えば図２のクライアントＩＤ２０２）を含む。ブロック４０４で、クライアントは、特定の資源と関連づけられた複数のレプリカのそれぞれに要求を送信し、それにより、それぞれのレプリカが要求のうちの１つを受信する（ブロック４０６）ようにする。
判断ブロック４０８で、それぞれのレプリカは、対応するオーナシップフィールド値が「ｎｉｌ」値であるかどうか、すなわち、そのレプリカが前のクライアントと排他的に関連づけられていないかどうかを判定する。オーナシップフィールド値がｎｉｌである場合、ブロック４１０で、要求からのクライアントＩＤをレプリカのオーナシップフィールド（例えばＣｏｗｎｅｒ）内の値として格納する。さらに、要求内のタイムスタンプの値をレプリカのタイムスタンプフィールド（例えばＴｏｗｎｅｒ）に格納する。ブロック４０８でオーナシップフィールド値が「ｎｉｌ」でない場合、要求は、クライアントＩＤおよびタイムスタンプを含めて、それぞれのレプリカのキューに挿入される。ブロック４１０またはブロック４１２に記載のアクションを実行した後、手続き４００はブロック４１４に進む。
ブロック４１４で、オーナシップフィールドおよびタイムスタンプフィールドのそれぞれの値を含む応答が、それぞれのレプリカによって形成される。ブロック４１６で、レプリカはクライアントへ応答を送信する。例えば、それぞれのレプリカは、図１のネットワーク１０６を通じて応答を通信してもよい。ブロック４１８で、クライアントは、図２の応答配列２０４のような応答配列に応答を格納する。判断ブロック４２０で、勝者を計算するのに十分な応答を受信したかどうかを判定する。この判定はさまざまな方法で実行することができる。例えば、クライアントは、コーラムを形成するのに十分な応答を受信したかどうか、あるいは、要求を受信したそれぞれのレプリカから応答が受信されたかどうか、等を判定することができる。
十分な応答を受信した場合（ブロック４２０）、クライアントは勝者を計算する（ブロック４２２）。勝者はさまざまな方法で計算することができる。例えば、前述のように、クライアントは、ｎ個のレプリカのうちのｍ個のように、クライアントがレプリカのコーラムのオーナシップを取得したかどうかを判定してもよい。
判断ブロック４２４で、クライアントは、勝者が当該クライアントであるかどうかを判定する。勝者が当該クライアントである場合（ブロック４２４）、成功メッセージを当該クライアントへ送信し（ブロック４２６）、特定の資源へのアクセスが許可されたことを当該クライアントが「知る」ようにする。勝者が当該クライアントでない場合（ブロック４２４）、手続き４００は判断ブロック４２８に進む。
判断ブロック４２８で、勝者が別のクライアントであるかどうかを判定する。勝者が別のクライアントである場合、手続きはブロック４３０に進む。ブロック４３０で、クライアントは別の応答を待機し、手続き４００はブロック４１８に戻る。このようにして、クライアントは、前に求めた要求を再送する必要がないような「アクティブウェイティング」の状態に置かれるため、クライアントと論理的レプリカを提供するコンピューティングデバイスのハードウェアおよびソフトウェアの資源、ならびにクライアントとコンピューティングデバイスの間の通信のためのネットワーク資源が節約される。
勝者が別のクライアントでない場合（ブロック４２８）、勝者は今回の「ラウンド」では見つけることができない。例えば、ｊｓａｍｅ＋ｎ−ｊ＜ｍ（ここで、ｊは返された応答の数であり、ｊが同じ項目の最大数がｊｓａｍｅである）である場合、特定の資源へのアクセスを要求するクライアントのうちには、その資源へのアクセスの許可を「勝ち取る」ものはない。したがって、ブロック４３２で、クライアントは、勝者が見つかるように、クライアントによって所有されているそれぞれのレプリカへ移譲メッセージ（yield message）を送信するための移譲オペレーション(yield operation)を開始する。その例については、以下の実施態様でさらに詳細に説明する。
図５は、図４の移譲オペレーションの実行が示される例示的実施態様５００における手続きを示す流れ図である。ブロック５０２で、クライアントを指定するオーナシップフィールド値を有するそれぞれの応答について、その応答を形成し発信した対応するレプリカへ移譲メッセージを送信する。例えば、図３のブロック３１８で、クライアント１０２（ａ）は、クライアント１０２（ａ）がそれぞれのレプリカ１１２（１）〜１１２（３）を所有する（すなわち、それらのレプリカと排他的に関連づけられる）ことを示す対応する応答３１０〜３１４を送信したレプリカ１１２（１）〜１１２（３）へ、移譲メッセージを送信してもよい。
ブロック５０４で、クライアントによって所有されているレプリカが移譲メッセージを受信する。移譲メッセージは、その移譲メッセージを送信したクライアントを識別するためのクライアントＩＤを含む。判断ブロック５０６で、それぞれのレプリカは、クライアントＩＤがそれぞれのレプリカのオーナシップフィールド（Ｃｏｗｎｅｒ）の値に等しいかどうかを判定する。クライアントによって所有されているレプリカにのみ移譲メッセージが送信される実施態様では、判断ブロック５０６は、エラーをチェックする役割を果たし得る。例えば、クライアントＩＤがオーナシップフィールドの値に一致しない場合、エラーがクライアントへ送信される（ブロック５０８）。別の実施態様として、移譲メッセージはすべてのレプリカへ送信されてもよく、その場合、判断ブロック５０６の実行は、それぞれのレプリカによって、移譲メッセージが当該レプリカに「関連性がある」かどうかを判定するために利用され得る。
クライアントＩＤがオーナシップフィールドの値に等しい場合（ブロック５０６）、ブロック５１０で、オーナシップフィールド値およびタイムスタンプフィールド値をキューに挿入する。例えば、オーナシップフィールド値およびタイムスタンプフィールド値をキューにコピーしてもよい。次に、ブロック５１２で、レプリカのオーナシップフィールド値およびタイムスタンプフィールド値をキューの「前」からリセットし、それらの値をセットするために用いられている対応するエントリをキューから削除する。例えば、キューは、最も古いエントリがキューの「前」に位置する（例えば、読み出される最初のエントリとなる）ように、タイムスタンプに従ってキュー内のエントリを編成することにより、例えば擬似的な「先着順」メカニズムを提供してもよい。したがって、ブロック５１０、５１２で、キューからの最新から最も遠い（すなわち最も古い）エントリを用いてオーナシップフィールドおよびタイムスタンプフィールドの値をリセットし、オーナシップフィールドおよびタイムスタンプフィールドの前の値をキューに挿入する。
ブロック５１４で、それぞれのレプリカが、オーナシップフィールドおよびタイムスタンプフィールドのそれぞれの値を含む応答を形成する。ブロック５１６で、応答がレプリカによってクライアントへ送信される。このように、移譲オペレーションの実行は本質的に協調的である。移譲オペレーションの意味は、レプリカが別のクライアントによる所有のために解放され、要求がキューに挿入されるという点で、「解放＋要求」とみなすことができる。解放および要求のオペレーションについては、図６に関してさらに詳細に説明される。こうして、レプリカは、移譲メッセージを受信すると、勝者の地位からクライアントを（すなわち、オーナシップフィールド（Ｃｏｗｎｅｒ）の値を）削除し、それをキューに挿入する。そして、レプリカは、キューから最先のクライアントを選択し、その勝者に通知する。
移譲機能の結果、キューの入れ替えが起こる。例えば、図４でどのクライアントも「勝者」でないことは、クライアントの間にコンテンション（競合）が起きたことを示している。このことは、キューはできているが、ネットワーク遅延等のため、勝者が不適切であるかもしれないことも意味する。移譲メッセージを発行することによって、クライアントは、レプリカに対して、互いに一貫したビューを作ることにより勝者を選択する機会を提供する。手続き５００は、勝者が計算されるまで複数回繰り返してもよい。
［例示的な相互排除プロトコルのアーキテクチャ］
図６は、図４および図５に関して説明したように、図２のクライアント１０２（ａ）およびレプリカ１１２（ｉ）により実行される相互排除プロトコルの一実施態様のアーキテクチャ６００を示すブロック図である。アーキテクチャ６００は、矢印を用いて、図１のクライアント１０２（ａ）とレプリカ１１２（ｉ）の間のメッセージの交換を示している。アーキテクチャ６００は、クライアント１０２（ａ）およびレプリカ１１２（ｉ）のそれぞれのメッセージハンドラを用いて記述することができる。それぞれの例示的オペレーションは、それぞれのデバイスにより実行される例示的な擬似コードに関連して説明される。１つまたは複数のオペレーションが独立に、および／または他のオペレーションの内部に示されているが、オペレーションは、さまざまな方法で組み合わせ、再配置することが可能である。
クライアント１０２（ａ）およびレプリカ１１２（ｉ）はそれぞれ、前述の相互排除を提供するさまざまなオペレーションをサポートすることができる。以下では、クライアント１０２（ａ）とレプリカ１１２（ｉ）の間の通信が、クライアントまたはレプリカ１１２（ｉ）により実行可能なメッセージハンドラを用いて示されるように、オペレーションの実行およびメッセージの交換の例示的順序を説明する。
クライアント１０２（ａ）は、以下の状態変数をサポートする。すなわち、ｉｄは、クライアント１０２（ａ）の識別子（例えば、図２のクライアントＩＤ２０２）であり、ｒｅｓｐ［］は、図２の応答配列２０４のように、レプリカからの応答を格納するために利用される。クライアント１０２（ａ）は、request（要求）６０２オペレーションを開始することにより、資源へのアクセスを制御するために利用されるそれぞれのレプリカに対する要求を形成する。これは、次の擬似コードの実行を通じて実行することができる。
Request(CS) {
timestamp := GetLogicalClock(); // ランポートのクロック
for each R[i] of CS
SendRequest(R[i], id, timestamp);
}
クライアント１０２（ａ）は、複数の資源のうちの特定の１つへのアクセスを希望している。これは、擬似コードにおいて、「ＣＳ」、すなわちクリティカルセクションとして表されている。Ｒ［ｉ］は、クリティカルセクションへのアクセスを許可するために利用される複数のレプリカ、例えばレプリカ１１２（ｉ）のそれぞれを表すために用いられる。「SendRequest」６０４オペレーションは、request６０２オペレーションの「サブオペレーション」として示されているが、各レプリカＲ［ｉ］へ要求を送信するために実行され、クライアント「ｉｄ」およびクロックからのタイムスタンプを含む。
レプリカ１１２（ｉ）は、前述のとおり、以下の状態変数をサポートする。すなわち、Ｃｏｗｎｅｒは、クライアントのオーナであり、Ｔｏｗｎｅｒは、Ｃｏｗｎｅｒ値に対するタイムスタンプである。要求を格納するためにキューが用いられる。クライアント１０２（ａ）から要求を受信すると、レプリカ１１２（ｉ）は、OnRequest６０６オペレーションを実行する。その例示的な擬似コードは次のように表される。
OnRequest(C, timestamp) {
if (Cowner = nil) {
Cowner := C;
Towner := timestamp;
}
else
Queue.Insert(C, timestamp);
SendResponse(C, Cowner, Towner);
}
擬似コードに示したように、レプリカ１１２（ｉ）は、「Ｃ」として表されるクライアントＩＤと、クライアント１０２（ａ）からの要求のタイムスタンプを含む要求を受信する。次に、OnRequest６０６オペレーションは、レプリカオーナシップフィールドＣｏｗｎｅｒが空であるかどうかを判定し、空である場合、クライアントＩＤをオーナシップフィールドに格納し、タイムスタンプをタイムスタンプフィールドＴｏｗｎｅｒに格納する。レプリカオーナシップフィールドがｎｉｌでない場合、キュー(queue)オペレーション６１０のinsert（挿入）６０８オペレーションを実行することによって、クライアントＩＤ「Ｃ」およびタイムスタンプがキューに挿入される。OnRequest６０６オペレーションおよび／またはinsert６０８オペレーションの実行後、レプリカ１１２（ｉ）は、SendResponse６１２オペレーションを実行することにより、クライアント１０２（ａ）「Ｃ」へ、オーナシップフィールドおよびタイムスタンプフィールドの値（ＣｏｗｎｅｒおよびＴｏｗｎｅｒ）を送信する。
レプリカ１１２（ｉ）から１つまたは複数の応答を受信すると、クライアント１０２（ａ）は、OnResponse６１４オペレーションを開始する。これは次のように表すことができる。
OnResponse(R[i], owner, timestamp) {
resp[i].owner := owner;
resp[i].timestamp := timestamp;
擬似コードに示したように、OnResponse６１４オペレーションは、それぞれのレプリカ１１２（ｉ）に対応するそれぞれの配列内の位置に、応答および応答内のタイムスタンプを格納することができる。
続いて、OnResponse６１４オペレーションの実行は、次の擬似コードに示すように、勝者を計算する。
if (enough responses received) {
winner := ComputeWinner();
if (winner = self) // 場合１
return success;
図４に関して前述し、擬似コードに示したように、クライアント１０２（ａ）は、まず、クライアント１０２（ａ）が資源へのアクセスの許可を「勝ち取った」かどうかを計算することができる。勝ち取った場合、クライアント１０２（ａ）はそのように通知される。そうでない場合、OnResponse６１４オペレーションの実行は以下に示すように続く。
else if (winner = nil) { // 場合３
for each resp[i].owner is self {
SendYield(R[i], id);
Clear(resp[i]); // 状態をリセット
}
}
// 場合２：他が勝った場合、待機
}
}
図４および図５に関して前述したように、特定の資源、すなわちクリティカルセクション（ＣＳ）へのアクセスの許可を勝ち取ったクライアントがない場合、クライアント１０２（ａ）は、SendYield６１６オペレーションを開始することにより、クライアント１０２（ａ）によって所有されているそれぞれのレプリカ１１２（ｉ）へ移譲メッセージを送信する。クライアント１０２（ａ）は、別のクライアントが勝者である場合、待機する。そして、クライアント１０２（ａ）は、次の応答を受信するために、自己の状態をリセットする。
レプリカ１１２（ｉ）は、移譲メッセージに応答して、OnYield６１８オペレーションを実行する。これは次のように表すことができる。
OnYield(C) {
if (C = Cowner) {
Queue.Insert(C, Towner);
RespQueue();
}
}
RespQueue() { // ヘルパルーチン
<Cowner, Towner> := Queue.Front();
SendReponse(Cowner, Cowner, Towner);
Queue.Remove(Cowner);
}
擬似コードに示したように、レプリカ１１２（ｉ）がクライアント１０２（ａ）によって所有されている場合、オーナシップフィールドおよびタイムスタンプフィールドからの値がキューに挿入され、新たな勝者が計算される。OnYield６１８オペレーションは、キューオペレーション６１０のコレクションを利用するRespQueueオペレーションを開始してもよい。例えば、QueueFront６２０オペレーションをまず実行し、キュー内で最も古いエントリを、例えばそれぞれのエントリのタイムスタンプを調べることによって、判定する。次に、SendResponse６１２オペレーションを実行して、QueueFront６２０オペレーションからのキューから選択されるクライアントを指定する別の応答を送信する。そして、remove６２２オペレーションを実行して、レプリカ１１２（ｉ）のＣｏｗｎｅｒフィールドおよびＴｏｗｎｅｒフィールドに入れるために、選択されたクライアントをキューから削除する。
また、クライアントは、release（解放）６２４オペレーションも含む。これは、次の擬似コードを用いて表すことができる。
Release(CS) {
for all R[i] of CS
SendRelease(R[i], id);
}
release６２４オペレーションは、レプリカのオーナシップを放棄するため、またはクライアントによって形成され送信された対応する要求をキューから削除するために実行される。例えば、レプリカは、releaseメッセージを受信した後、OnRelease６２８オペレーションを実行してもよい。これは次のように表される。
OnRelease(C) {
if (C = Cowner) {
Cowner := nil;
if (not Queue.Empty())
RespQueue();
}
else if (Queue.Contains(C))
Queue.Remove(C);
}
擬似コードに示したように、レプリカ１１２（ｉ）がクライアント１０２（ａ）によって所有されている場合、クライアント１０２（ａ）は、ＣｏｗｎｅｒフィールドおよびＴｏｗｎｅｒフィールドから削除される。さらに、QueueEmpty６３０オペレーションを実行して、キューが空であるかどうかを判定する。QueueContains６３２オペレーションは、クライアント１０２（ａ）がレプリカ１１２（ｉ）の現在のオーナでない場合に、キューがクライアント１０２（ａ）からの要求を含むかどうかを判定するために実行される。含む場合、QueueRemove６２２オペレーションを実行して、要求（例えば、クライアントＩＤおよびタイムスタンプ）をキューから削除する。
レプリカは、利用可能な資源の対応するシェアに対して投票するように構成されてもよい。例えば、すべてのコーラムメンバがＤＨＴを形成する場合、各メンバは、代わりに、自己の空間〈シェア〉に投票することができる。そこで、コンセンサスに達するのは、クライアントが全空間のうちｆ＝ｍ／ｎの全〈割合〉を集めた場合である。したがって、動的メンバシップ変化に適応するために同じ性質を保ちながら、レプリカが一定数であることを要しない。
［環境における障害］
上記の相互排除プロトコルは、図１の環境１００における障害を解決するためにも利用可能である。例えば、レプリカは、前のクライアントに既に投票していたかもしれないが、それにもかかわらず、クラッシュ後に、新たなクライアントに投票（すなわち、新たな応答を発行）してもよい。そこで、安全性を破る確率を下げるために、ｍ／ｎの比を高くしてもよい。別の例として、キュー内の各エントリが失われるかもしれないが、その場合、クライアントが、来ることのない応答を待機することになる可能性がある。この例に対処するため、次のセクションで説明する〈インフォームドバックオフ〉メカニズムを利用して、レプリカのメモリを再構築することができる。さらに別の例として、特定の資源（すなわちＣＳ）を現在利用中のクライアントが終了前にクラッシュすることにより、レプリカが「身動きがとれなく」なってしまうことがある。そこで、レプリカは、更新可能なリース付きでクライアントに許可を与えてもよい。リースが満期になると、レプリカは、キュー内の次のクライアント（もしあれば）に許可を与える。さらに別の例として、クライアントとレプリカの間の信頼できない通信チャネルもまた同様の問題が生じる。
［インフォームドバックオフ］
〈インフォームドバックオフ〉は、再起動されなかった他のレプリカに過負荷をかけることなく、再起動されたレプリカの状態を再構築するために利用可能なメカニズムである。要求があると、レプリカは、予想待機時間Ｔｗを予測し、それをクライアントに伝達する。予想待機時間は、次の再試行、すなわち要求再送の前に、その時間だけ待機するようにクライアントに通知する。例えば、Ｔｗの経験的計算式は、Ｔｗ＝ＴＣＳ×（Ｐ＋１／２）である。ここで、Ｐはキュー内のクライアントの位置であり、ＴＣＳは、任意の２つの連続する解放オペレーションの間の時間間隔についてレプリカによって観測される平均のＣＳ継続時間である。式中の１／２は、レプリカの現在のオーナを考慮に入れるために用いられている。一実施態様では、Ｔｗは、再試行の受信ごとに更新される。
インフォームドバックオフメカニズムの使用は、クライアントとレプリカの「正常な」オペレーションを妨げないように構成されることも可能である。例えば、レプリカがクラッシュしていないと仮定する。クライアントが、予定された再試行の前に応答を受信すれば、最小限の追加資源がそのクライアントによって利用される。さらに、クライアントが再試行、すなわち要求再送をしない場合、通知されるＴｗは正確でない可能性がある。そのような場合、クライアントは、再試行のためにＴｗを更新してもよい。そこで、レプリカが実際にリセットすれば、キューは、もとの順序と類似の順序で再構成される。
［例示的なコンピューティングデバイス］
本明細書に記載される種々のコンポーネントおよび機能は、いくつかのコンピュータを用いて実施される。図７は、参照番号７０２で示すコンピュータを含む、コンピュータ環境７００の典型例のコンポーネントを示している。コンピュータ７０２は、図１の複数のクライアント１０２（ａ）および複数のコンピューティングデバイス１０４（１）〜１０４（Ｂ）と同一であっても異なっていてもよい。図７に示すコンポーネントは単なる例であり、本発明の機能の範囲に関するいかなる限定を示唆することも意図していない。本発明は、必ずしも、図７に示す特徴に依存しない。
一般的に、さまざまな汎用または専用のコンピューティングシステム構成が使用可能である。本発明とともに使用するのに好適であり得る周知のコンピューティングシステム、環境、および／または構成の例としては、以下のものに限定されないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド型またはラップトップ型デバイス、マルチプロセッサシステム、マイクロプロセッサ方式のシステム、セットトップボックス、プログラム可能な消費者電子機器、ネットワークＰＣ、ネットワーク対応デバイス、ミニコンピュータ、メインフレームコンピュータ、そして、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境等がある。
コンピュータの機能は、多くの場合、コンピュータによって実行されるソフトウェアコンポーネントのようなコンピュータ実行可能命令によって具現化される。一般的に、ソフトウェアコンポーネントは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。タスクは、通信ネットワークを通じてリンクされたリモート処理デバイスによって実行されてもよい。分散コンピューティング環境では、ソフトウェアコンポーネントは、図１および図６に関して前述したように、ローカルおよびリモートの両方のコンピュータ記憶媒体に配置されてもよい。
命令および／またはソフトウェアコンポーネントは、コンピュータの一部であるか、またはコンピュータによって読み取り可能な種々のコンピュータ可読媒体に、さまざまな時に格納される。通常、プログラムは、例えばフロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、または変調信号のような何らかの形態の通信媒体で配布される。そこから、プログラムはコンピュータの二次メモリにインストールまたはロードされる。実行時に、プログラムはコンピュータの一次電子メモリに少なくとも部分的にロードされる。
説明の目的上、本明細書では、オペレーティングシステムのようなプログラムおよびその他の実行可能プログラムコンポーネントは、個別のブロックとして示される。ただし、このようなプログラムおよびコンポーネントは、種々の時にコンピュータのさまざまな記憶コンポーネントに存在し、コンピュータのデータプロセッサ（複数可）によって実行されると認められる。
図７を参照すると、コンピュータ７０２のコンポーネントとしては、処理ユニット７０４、システムメモリ７０６、およびシステムメモリを含む種々のシステムコンポーネントを処理ユニット７０４に結合するシステムバス７０８が挙げられるが、これらには限定されない。システムバス７０８は、さまざまなバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含む、いくつかのタイプのバス構造のいずれでもよい。
コンピュータ７０２は通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ７０２がアクセスすることができるいかなる利用可能な媒体であってもよく、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体の両方がある。例として、限定ではないが、コンピュータ可読媒体としては、コンピュータ記憶媒体および通信媒体が挙げられる。「コンピュータ記憶媒体」としては、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータのような情報の記憶のための任意の方法または技術で実現された揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体がある。コンピュータ記憶媒体としては、以下のものに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ等のメモリ技術、ＣＤ−ＲＯＭ、ディジタルビデオディスク（ＤＶＤ）等の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ等の磁気記憶デバイス、または所望の情報を記憶するために使用可能でありコンピュータ７０２によりアクセス可能な任意の他の媒体がある。通信媒体は通常、キャリア波等の変調データ信号または他のトランスポートメカニズムでコンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータを具現化し、いかなる情報配信媒体も含む。「変調データ信号」という用語は、信号中に情報を符号化するように１つまたは複数の信号の特性が設定または変更された信号を意味する。例として、限定ではないが、通信媒体としては、有線ネットワークまたは直接有線コネクションのような有線媒体、および音響、ＲＦ、赤外線等の無線媒体のような無線媒体がある。上記のいずれかの組合せもまた、コンピュータ可読媒体の範囲内に含まれるべきである。
システムメモリ７０６は、読み出し専用メモリ（ＲＯＭ）７１０およびランダムアクセスメモリ（ＲＡＭ）７１２のような揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動中等にコンピュータ７０２内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム７１４（ＢＩＯＳ）が通常ＲＯＭ７１０に記憶される。ＲＡＭ７１２は通常、処理ユニット７０４から直ちにアクセス可能な、および／または処理ユニット７０４が現在作用しているデータおよび／またはソフトウェアコンポーネントを含む。例として、限定ではないが、図７は、オペレーティングシステム７１６、アプリケーション７１８、ソフトウェアコンポーネント７２０、およびプログラムデータ７２２を示している。
また、コンピュータ７０２は、他のリムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータ記憶媒体を含んでもよい。単なる例として、図７は、非リムーバブル不揮発性磁気媒体の読み書きを行うハードディスクドライブ７２４、リムーバブル不揮発性磁気ディスク７２８の読み書きを行う磁気ディスクドライブ７２６、およびＣＤ−ＲＯＭ等の光媒体のようなリムーバブル不揮発性光ディスク７３２の読み書きを行う光ディスクドライブ７３０を示している。例示的オペレーティング環境で使用可能な他のリムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータ記憶媒体としては、以下のものに限定されないが、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭ等がある。ハードディスクドライブ７２４は通常、データメディアインタフェース７３４のような非リムーバブルメモリインタフェースを通じてシステムバス７０８に接続され、磁気ディスクドライブ７２６および光ディスクドライブ７３０は通常、リムーバブルメモリインタフェースによりシステムバス７０８に接続される。
前述し図７に示したドライブおよびそれらに関連するコンピュータ記憶媒体は、コンピュータ７０２のためのコンピュータ可読命令、データ構造、ソフトウェアコンポーネント、および他のデータの記憶を行う。例えば図７において、ハードディスクドライブ７２４は、オペレーティングシステム７１６′、アプリケーション７１８′、ソフトウェアコンポーネント７２０′、およびプログラムデータ７２２′を記憶するように示されている。なお、これらのコンポーネントは、オペレーティングシステム７１６、アプリケーション７１８、ソフトウェアコンポーネント７２０、およびプログラムデータ７２２と同じでも異なってもよいことに留意されたい。オペレーティングシステム７１６′、アプリケーション７１８′、ソフトウェアコンポーネント７２０′、およびプログラムデータ７２２′は、それらが少なくとも別のコピーであることを示すためにここでは異なる番号が与えられている。ユーザは、キーボード７３６、およびマウス、トラックボール、またはタッチパッドと一般的に呼ばれるポインティングデバイス（図示せず）のような入力デバイスを通じてコンピュータ７０２にコマンドおよび情報を入力することができる。他の入力デバイスとしては、ソースデバイス（ストリーミングデータを提供するマイクロフォン７４０やカメラ７３８等）、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ等が挙げられる。これらおよび他の入力デバイスは、システムバスに結合した入出力（Ｉ／Ｏ）インタフェース７４２を通じて処理ユニット７０２に接続されることが多いが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）等の他のインタフェースおよびバス構造により接続されてもよい。モニタ７４４または他のタイプのディスプレイデバイスもまた、ビデオアダプタ７４６のようなインタフェース経由でシステムバス７０８に接続される。モニタ７４４に加えて、コンピュータは、他のレンダリングデバイス（例えばスピーカ）や１つまたは複数のプリンタを含んでもよく、これらはＩ／Ｏインタフェース７４２を通じて接続され得る。
コンピュータは、リモートデバイス７５０のような１つまたは複数のリモートコンピュータへの論理コネクションを用いたネットワーク環境で動作し得る。リモートデバイス７５０は、パーソナルコンピュータ、ネットワーク対応デバイス、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の一般的なネットワークノードであってよく、通常、コンピュータ７０２に関して前述した要素の多くまたはすべてを含む。図７に示す論理コネクションは、ローカルエリアネットワーク（ＬＡＮ）７５２および広域ネットワーク（ＷＡＮ）７５４を含む。図７に示すＷＡＮ７５４はインターネットであるが、ＷＡＮ７５４は他のネットワークを含んでもよい。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット等で一般的である。
ＬＡＮネットワーキング環境で使用される場合、コンピュータ７０２はネットワークインタフェースすなわちアダプタ７５６を通じてＬＡＮ７５２に接続される。ＷＡＮネットワーキング環境で使用される場合、コンピュータ７０２は通常、インターネット７５４を通じて通信を確立するためのモデム７５８等の手段を含む。モデム７５８は、内蔵でも外付けでもよいが、Ｉ／Ｏインタフェース７４２、または他の適当なメカニズムを通じてシステムバス７０８に接続され得る。ネットワーク環境では、コンピュータ７０２に関して図示したプログラムモジュールまたはその部分は、リモートメデバイス７５０に記憶されてもよい。例として、限定ではないが、図７は、リモートソフトウェアコンポーネント７６０がリモートデバイス７５０上に存在するように示している。図示したネットワークコネクションは例示であり、コンピュータ間に通信リンクを確立する他の手段を使用してもよいことが理解されるであろう。
［結論］
ピアツーピアネットワークにおけるシステムダイナミズムを扱うために、論理的レプリカおよびコーラムコンセンサスを利用し得る相互排除技法について説明した。本明細書に記載の技法によって提供されるクライアントとレプリカの間の準一貫性および協調を利用して、ネットワーク遅延変動およびコンテンションを回避することができる。また、相互排除技法は、インフォームドバックオフを利用する等によって、障害にも対処する。
以上、本発明は、構造的な特徴および／または方法上の行為に固有の用語で説明されているが、添付の特許請求の範囲に規定される本発明は、必ずしも上記の具体的な特徴または行為に限定されないことが理解されるべきである。むしろ、これら具体的な特徴および行為は、特許請求の範囲に記載の発明を実施するための例示的形態として開示されているものである。
ピアツーピアネットワークを提供するように構成された環境を示す例示的実施態様の図である。 図１のクライアントおよびレプリカのアーキテクチャをさらに詳細に示すシステムの例示的実施態様の図である。 図１のクライアントがピアツーピアネットワークにおける複数のピアのうちの１つまたは複数によって提供される資源へのアクセスを要求する例示的実施態様における手続きを示す流れ図である。 複数の資源のうちの特定の１つの利用が許可されるかどうかをクライアントが判断する例示的実施態様における手続きを示す流れ図である。 図４の移譲オペレーションの実行を示す例示的実施態様における手続きを示す流れ図である。 図４および図５に関連して説明される、図２のクライアントおよびレプリカにより実行される相互排除プロトコルの一実施態様のアーキテクチャを示すブロック図である。 例示的なコンピューティングデバイスの図である。
符号の説明
１００ 環境
１０２ クライアント
１０４ コンピューティングデバイス
１０６ ネットワーク
１０８ 分散ハッシュテーブル（ＤＨＴ）
１１０ バケット
１１２ 論理的レプリカ
２０２ クライアントＩＤ
２０４ 応答配列
２０６ 応答
２０８ オーナ
２１０ タイムスタンプ
２１２ オーナシップフィールド
２１４ キュー
２１６ 要求
２１８ タイムスタンプ
３０４ 要求
３１０〜３１６ 応答
６０２ request（要求）オペレーション
６０４ SendRequestオペレーション
６０６ OnRequestオペレーション
６０８ insert（挿入）オペレーション
６１０ キューオペレーション
６１２ SendResponseオペレーション
６１４ OnResponseオペレーション
６１６ SendYieldオペレーション
６１８ OnYieldオペレーション
６２０ QueueFrontオペレーション
６２２ remove（移動）オペレーション
６２４ release（解除）オペレーション
６２８ OnReleaseオペレーション
６３０ QueueEmptyオペレーション
６３２ QueueContainsオペレーション
７００ コンピュータ環境
７０２ コンピュータ
７０４ 処理ユニット
７０６ システムメモリ
７０８ システムバス
７１０ 読み出し専用メモリ（ＲＯＭ）
７１２ ランダムアクセスメモリ（ＲＡＭ）
７１４ 基本入出力システム（ＢＩＯＳ）
７１６，７１６′ オペレーティングシステム
７１８，７１８′ アプリケーション
７２０，７２０′ ソフトウェアコンポーネント
７２２，７２２′ プログラムデータ
７２４ ハードディスクドライブ
７２６ 磁気ディスクドライブ
７２８ リムーバブル不揮発性磁気ディスク
７３０ 光ディスクドライブ
７３２ リムーバブル不揮発性光ディスク
７３４ データメディアインタフェース
７３６ キーボード
７３８ カメラ
７４０ マイクロフォン
７４２ 入出力（Ｉ／Ｏ）インタフェース
７４４ モニタ
７４６ ビデオアダプタ
７５０ リモートデバイス
７５２ ローカルエリアネットワーク（ＬＡＮ）
７５４ 広域ネットワーク（ＷＡＮ）
７５６ ネットワークインタフェース
７５８ モデム
７６０ リモートソフトウェアコンポーネント

Claims (41)

  1. 複数の論理的レプリカのそれぞれにおいて、クライアントから要求を受信するステップであって、
    それぞれの前記論理的レプリカが１つの前記クライアントと排他的関連づけがされるように構成され、
    それぞれの前記論理的レプリカがキューを含み、
    前記要求が、複数の資源のうちの１つの資源にアクセスすることを求める要求である、クライアントから要求を受信するステップと、
    特定の論理的レプリカが別のクライアントと排他的に関連づけられている場合には、該特定の論理的レプリカのキューに前記要求を格納するステップと
    を含むことを特徴とする方法。
  2. それぞれの前記論理的レプリカにおいて、該論理的レプリカの排他的関連づけを識別する、前記クライアントへ伝達するための応答を形成するステップをさらに含むことを特徴とする請求項１に記載の方法。
  3. それぞれの前記応答は、前記クライアントによる前記１つの資源へのアクセスが許可されるかどうかを前記クライアントが判断するための応答であることを特徴とする請求項２に記載の方法。
  4. それぞれの前記応答は、前記クライアントによる前記１つの資源へのアクセスが許可されるかどうかを前記クライアントが判断するための応答であり、
    前記クライアントは、前記クライアントが前記複数の論理的レプリカのコーラム（quorum:定員）と排他的に関連づけられる場合に許可される
    ことを特徴とする請求項２に記載の方法。
  5. それぞれの前記応答は、前記クライアントによる前記１つの資源へのアクセスが許可されるかどうかを前記クライアントが判断するための応答であり、
    前記クライアントは、別のクライアントが許可される場合にはそれぞれの前記論理的レプリカからの別の応答を待機する
    ことを特徴とする請求項２に記載の方法。
  6. 前記クライアントは複数のクライアントのうちの１つであり、
    それぞれの前記応答は、前記複数のクライアントのうちの１つによる前記１つの資源へのアクセスが許可されるかどうかを判断するための応答であり、
    前記複数のクライアントのいずれも許可されない場合には、少なくとも１つの前記クライアントが、
    前記複数の論理的レプリカへの伝達、および
    前記複数の論理的レプリカに別の応答を形成させること
    のための移譲（Yield）メッセージを形成する
    ことを特徴とする請求項２に記載の方法。
  7. 前記別の応答が、それぞれの前記キューに格納されたこれまでの要求から形成されることを特徴とする請求項６に記載の方法。
  8. 前記複数の資源が、分散ハッシュテーブル（ＤＨＴ）を用いて分割され、
    前記ＤＨＴが、前記複数の資源のそれぞれを複数のバケットのそれぞれのバケットに分割し、
    前記複数のバケットが、ピアツーピアネットワーク内の複数のコンピューティングデバイスによって提供される
    ことを特徴とする請求項１に記載の方法。
  9. それぞれの前記バケットを提供する１つの前記コンピューティングデバイスが前記クライアントにとって利用可能でない場合、該バケットが別の前記コンピューティングデバイスによって利用可能にされるように、前記複数のコンピューティングデバイスがフェイルオーバ（障害迂回）機能を備えたことを特徴とする請求項８に記載の方法。
  10. コンピュータ実行可能命令を含む１つまたは複数のコンピュータ可読媒体において、コンピュータ上で実行される時に、該コンピュータに、請求項１に記載の方法を実行させることを特徴とするコンピュータ可読媒体。
  11. クライアントが複数の論理的レプリカへ伝達するための要求を形成するステップであって、該要求が複数の資源のうちの１つの資源を求める要求である、要求を形成するステップと、
    前記クライアントにおいて、前記複数の論理的レプリカから複数の応答を受信するステップと、
    前記複数の応答から、前記クライアントによる前記１つの資源の利用が許可されるかどうかを判定するステップと、
    前記クライアントが、別のクライアントが許可される場合に別の要求を送信することなく別の複数の応答を待機するステップと
    を含むことを特徴とする方法。
  12. 前記クライアントは複数のクライアントのうちの１つであり、
    それぞれの前記レプリカがキューを含み、
    前記複数のクライアントのいずれも許可されない場合、少なくとも１つの前記クライアントが、
    前記複数の論理的レプリカへの伝達、および
    前記複数の論理的レプリカにそれぞれの前記キューから別の複数の前記応答を形成させること
    のための移譲メッセージを形成する
    ことを特徴とする請求項１１に記載の方法。
  13. それぞれの前記応答が、それぞれの前記論理的レプリカが前記クライアントによって所有されているかどうかを識別するように構成されることを特徴とする請求項１１に記載の方法。
  14. それぞれの前記応答が、それぞれの前記論理的レプリカが前記クライアントによって所有されているかどうかを識別するように構成され、
    前記クライアントが、前記複数の論理的レプリカのコーラムと排他的に関連づけられる場合に前記１つの資源の利用が許可される
    ことを特徴とする請求項１１に記載の方法。
  15. ＤＨＴが、前記複数の資源を複数のバケットに分割し、
    前記複数のバケットが、ピアツーピアネットワーク内の複数のコンピューティングデバイスによって提供され、
    それぞれの前記バケットを提供する１つの前記コンピューティングデバイスが前記複数のクライアントにとって利用可能でない場合、該バケットが別の前記コンピューティングデバイスによって利用可能にされるように、前記複数のコンピューティングデバイスがフェイルオーバ機能を提供する
    ことを特徴とする請求項１１に記載の方法。
  16. それぞれの前記論理的レプリカが１つまたは複数の前記要求を格納するキューを含み、
    前記キュー内のそれぞれの前記要求は、該要求がそれぞれの前記論理的レプリカによっていつ受信されたかに従って編成される
    ことを特徴とする請求項１１に記載の方法。
  17. コンピュータ実行可能命令を含む１つまたは複数のコンピュータ可読媒体において、コンピュータ上で実行される時に、該コンピュータに、請求項１１に記載の方法を実行させることを特徴とするコンピュータ可読媒体。
  18. 複数のクライアントのそれぞれにおいて、複数の論理的レプリカへの伝達のために複数の資源のうちの１つの資源を求める要求を形成するステップと、
    前記複数のクライアントにおいて、前記複数の論理的レプリカから複数の応答を受信するステップと、
    それぞれの前記クライアントにおいて前記複数の応答を用いて、前記複数のクライアントのうちの１つに前記１つの資源の利用が許可されるかどうかを判定するステップと、
    前記複数のクライアントのいずれも前記１つの資源の利用が許可されない場合、少なくとも１つの前記クライアントが、
    前記複数の論理的レプリカのうちの１つまたは複数の論理的レプリカへの伝達、および
    前記１つまたは複数の論理的レプリカのそれぞれに、１つまたは複数の前記クライアントから受信された前の要求を格納するそれぞれのキューから別の応答を形成させること
    のための移譲メッセージを形成するステップと
    を含むことを特徴とする方法。
  19. それぞれの前記応答が、それぞれの前記論理的レプリカが前記複数のクライアントのうちの１つと排他的に関連づけられているかどうかを識別するように構成され、
    前記キュー内のそれぞれの前記前の要求は、該前の要求がそれぞれの前記論理的レプリカによっていつ受信されたかに従って編成され、
    前記移譲メッセージが、前記１つまたは複数の論理的レプリカに、それぞれの前記キュー内の最先の前記前の要求に基づいて前記別の応答においてオーナシップを識別させる
    ことを特徴とする請求項１８に記載の方法。
  20. 前記移譲メッセージは、前記少なくとも１つのクライアントによって所有されるそれぞれの前記論理的レプリカに、前記それぞれのキューに基づいて異なる前記クライアントを選択させることを特徴とする請求項１９に記載の方法。
  21. 前記１つの資源の利用は、前記複数のクライアントのうちの１つが前記複数の論理的レプリカのコーラムと排他的に関連づけられる場合に許可されることを特徴とする請求項１８に記載の方法。
  22. １つの前記クライアントによる前記資源へのアクセスが許可される場合、許可されない１つまたは複数の他の前記クライアントが別の複数の応答を待機することを特徴とする請求項１８に記載の方法。
  23. 前記複数の資源が、分散ハッシュテーブル（ＤＨＴ）を用いて分割され、
    前記ＤＨＴが、前記複数の資源を複数のバケットに分割し、
    前記複数のバケットが、ピアツーピアネットワーク内の複数のコンピューティングデバイスによって提供され、
    それぞれの前記バケットを提供する１つの前記コンピューティングデバイスが前記複数のクライアントにとって利用可能でない場合、該バケットが別の前記コンピューティングデバイスによって利用可能にされるように、前記複数のコンピューティングデバイスがフェイルオーバ機能を備えた
    ことを特徴とする請求項１８に記載の方法。
  24. コンピュータ実行可能命令を含む１つまたは複数のコンピュータ可読媒体において、コンピュータ上で実行される時に、該コンピュータに、請求項１８に記載の方法を実行させることを特徴とするコンピュータ可読媒体。
  25. コーラムコンセンサスプロトコルを用いて資源アクセスを許可するための論理的レプリカを備えたことを特徴とするピアツーピアネットワーク。
  26. それぞれの前記論理的レプリカが、複数のコンピューティングデバイスのうちの１つまたは複数によって実行可能なピアであることを特徴とする請求項２５に記載のピアツーピアネットワーク。
  27. 前記コーラムコンセンサスプロトコルが、前記論理的レプリカのコーラムと排他的に関連づけられたクライアントへの資源アクセスを許可するために用いられることを特徴とする請求項２５に記載のピアツーピアネットワーク。
  28. それぞれの前記論理的レプリカが、資源アクセスを求める１つまたは複数のクライアントから受信される要求を格納するためのキューを含むことを特徴とする請求項２５に記載のピアツーピアネットワーク。
  29. それぞれの前記キューは、それぞれの前記論理的レプリカが別のクライアントと排他的に関連づけられる場合に、前記１つのクライアントから受信される要求を格納するためのキューであることを特徴とする請求項２８に記載のピアツーピアネットワーク。
  30. 前記資源アクセスが、分散ハッシュテーブルを用いて分割された複数の資源のうちの１つまたは複数に対する資源アクセスであることを特徴とする請求項２５に記載のピアツーピアネットワーク。
  31. それぞれの前記論理的レプリカが、資源アクセスを求める要求に対する応答を受信するための予想待機時間をクライアントに提供するインフォームドバックオフメカニズムを使用し、
    前記予想待機時間は、前記要求を再送する前に前記クライアントが待機すべき時間の長さを定める
    ことを特徴とする請求項２５に記載のピアツーピアネットワーク。
  32. ネットワークと、
    前記ネットワークに通信可能に結合した複数のクライアントと、
    前記ネットワークに通信可能に結合し複数の論理的レプリカを含む複数のコンピューティングデバイスと
    を備えたシステムにおいて、それぞれの前記論理的レプリカが、
    任意の一特定時刻において前記複数のクライアントのうちの１つのクライアントと排他的に関連づけられるように構成され、
    前記論理的レプリカが別のクライアントと排他的に関連づけられる場合に資源にアクセスすることを求める前記１つのクライアントからの要求を格納するためのキューを含む
    ことを特徴とするシステム。
  33. それぞれの前記論理的レプリカが、前記別のクライアントを識別する要求に対する応答を形成するようにさらに構成されることを特徴とする請求項３２に記載のシステム。
  34. それぞれの前記クライアントは、それぞれの前記応答から、前記複数のクライアントのうちの１つによる前記１つの資源へのアクセスが許可されるかどうかを判定するように構成されることを特徴とする請求項３３に記載のシステム。
  35. それぞれの前記論理的レプリカは、１つの前記クライアントが該論理的レプリカをいつ所有するかを識別する、前記要求に対する応答を形成するようにさらに構成され、
    それぞれの前記クライアントは、それぞれの前記応答から、前記複数のクライアントのうちの１つによる前記１つの分割された資源の利用が許可されるかどうかを判定するように構成され、
    前記１つのクライアントが前記複数の論理的レプリカのコーラムと排他的に関連づけられる場合に許可が得られる
    ことを特徴とする請求項３２に記載のシステム。
  36. それぞれの前記論理的レプリカは、１つの前記クライアントが該論理的レプリカと排他的に関連づけられるかどうかを識別する、前記要求に対する応答を形成するようにさらに構成され、
    それぞれの前記応答は、それぞれの前記クライアントが、該クライアントによる前記１つの分割された資源へのアクセスが許可されるかどうかを判定するための応答であり、許可されない場合、該クライアントが別の応答を待機する
    ことを特徴とする請求項３２に記載のシステム。
  37. それぞれの前記論理的レプリカは、１つの前記クライアントが該論理的レプリカと排他的に関連づけられるかどうかを識別する、前記要求に対する応答を形成するようにさらに構成され、
    それぞれの前記応答は、前記複数のクライアントが、１つの前記クライアントによる前記１つの資源の利用が許可されるかどうかを判定するための応答であり、
    前記複数のクライアントのいずれも許可されない場合、少なくとも１つの前記クライアントが、
    前記複数の論理的レプリカのうちの１つまたは複数の論理的レプリカへの伝達、および
    前記１つまたは複数の論理的レプリカのそれぞれに、１つまたは複数の前記クライアントから受信された前の要求を格納するそれぞれの前記キューから別の応答を形成させること
    のための移譲メッセージを形成する
    ことを特徴とする請求項３２に記載のシステム。
  38. 分散ハッシュテーブルが、前記複数の資源を複数のバケットに分割し、
    前記複数のバケットが、ピアツーピアネットワーク内の前記複数のコンピューティングデバイスによって提供され、
    それぞれの前記バケットを提供する１つの前記コンピューティングデバイスが前記複数のクライアントにとって利用可能でない場合、該バケットが別の前記コンピューティングデバイスによって利用可能にされるように、前記複数のコンピューティングデバイスがフェイルオーバ機能を備えた
    ことを特徴とする請求項３２に記載のシステム。
  39. それぞれの前記論理的レプリカが、応答を受信するための予想待機時間を提供するインフォームドバックオフメカニズムを使用し、
    前記予想待機時間は、それぞれの前記要求を再送する前に前記クライアントが待機すべき時間の長さを定める
    ことを特徴とする請求項３２に記載のシステム。
  40. 資源を求める複数の要求を形成する手段と、
    前記形成する手段を通信可能な結合でネットワーキングする手段と、
    前記資源を提供する手段と
    を備えたシステムにおいて、前記提供する手段が、前記ネットワーキングする手段に通信可能に結合するとともに、複数の論理的レプリカ手段を含み、該論理的レプリカ手段は、
    前記形成する手段のいずれがそれぞれの前記論理的レプリカ手段を所有するかを識別する、前記複数の要求のそれぞれに対する応答を形成し、
    １つまたは複数の前記要求を格納する
    ことを特徴とするシステム。
  41. 前記提供する手段が、
    ピアツーピアネットワークを形成するように通信可能に結合した複数のコンピューティングデバイスと、
    分散ハッシュテーブルと
    を含み、
    前記形成する手段が、複数のクライアントを含む
    ことを特徴とする請求項４０に記載のシステム。
JP2005045429A 2004-02-25 2005-02-22 動的ピアツーピア環境における相互排除技法 Expired - Fee Related JP4837929B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US54745704P 2004-02-25 2004-02-25
US60/547,457 2004-02-25
US10/886,794 2004-07-08
US10/886,794 US7526672B2 (en) 2004-02-25 2004-07-08 Mutual exclusion techniques in a dynamic peer-to-peer environment

Publications (2)

Publication Number Publication Date
JP2005276181A true JP2005276181A (ja) 2005-10-06
JP4837929B2 JP4837929B2 (ja) 2011-12-14

Family

ID=34864594

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005045429A Expired - Fee Related JP4837929B2 (ja) 2004-02-25 2005-02-22 動的ピアツーピア環境における相互排除技法

Country Status (4)

Country Link
US (1) US7526672B2 (ja)
EP (1) EP1571801A3 (ja)
JP (1) JP4837929B2 (ja)
KR (1) KR101120844B1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007063944A1 (ja) * 2005-11-30 2007-06-07 International Business Machines Corporation 無停止トランザクション処理システム
JP2010157204A (ja) * 2008-09-11 2010-07-15 Nec Lab America Inc 検索可能なブロックを用いた連想記憶システムおよびその方法
JP2011154631A (ja) * 2010-01-28 2011-08-11 Fujitsu Ltd 確定クロック判定プログラム及び方法、並びにノード装置
JP2019175222A (ja) * 2018-03-29 2019-10-10 日本電気株式会社 電文保証システムおよび電文保証方法

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8365301B2 (en) * 2005-02-22 2013-01-29 Microsoft Corporation Peer-to-peer network communication
US7849303B2 (en) * 2005-02-22 2010-12-07 Microsoft Corporation Peer-to-peer network information storage
US20070143446A1 (en) * 2005-12-21 2007-06-21 Morris Robert P Methods, systems, and computer program products for installing an application from one peer to another including application configuration settings and data
US8171144B2 (en) * 2006-02-06 2012-05-01 Panasonic Corporation AV server apparatus and connection management method
US8041784B1 (en) * 2006-06-27 2011-10-18 Qurio Holdings, Inc. Redundant hybrid P2P content sharing
US8028019B2 (en) * 2007-02-28 2011-09-27 Solid State Networks, Inc. Methods and apparatus for data transfer in networks using distributed file location indices
US7984158B2 (en) * 2007-03-20 2011-07-19 Microsoft Corporation Web service for coordinating actions of clients
EP2023683B1 (en) * 2007-08-09 2011-05-18 Nokia Siemens Networks Oy Mobile communication terminal, communication station, communication network, and communication method
JP5171167B2 (ja) * 2007-09-05 2013-03-27 キヤノン株式会社 通信パラメータの設定処理を行う通信装置、当該通信装置の制御方法、並びにコンピュータプログラム
US20090144333A1 (en) * 2007-11-30 2009-06-04 Yahoo! Inc. System for maintaining a database
US20100174863A1 (en) * 2007-11-30 2010-07-08 Yahoo! Inc. System for providing scalable in-memory caching for a distributed database
US20090144338A1 (en) * 2007-11-30 2009-06-04 Yahoo! Inc. Asynchronously replicated database system using dynamic mastership
US20090144220A1 (en) * 2007-11-30 2009-06-04 Yahoo! Inc. System for storing distributed hashtables
WO2009088513A1 (en) * 2008-01-10 2009-07-16 Hewlett-Packard Development Company, L.P. Multiway peer-to-peer media streaming
US7937482B1 (en) * 2008-03-27 2011-05-03 Amazon Technologies, Inc. Scalable consensus protocol
WO2009134772A2 (en) * 2008-04-29 2009-11-05 Maxiscale, Inc Peer-to-peer redundant file server system and methods
JP5168055B2 (ja) * 2008-09-26 2013-03-21 ブラザー工業株式会社 通信システム、端末装置及びコンテンツ情報取得方法
US20110225120A1 (en) * 2010-03-11 2011-09-15 Yahoo! Inc. System for maintaining a distributed database using leases
US20110225121A1 (en) * 2010-03-11 2011-09-15 Yahoo! Inc. System for maintaining a distributed database using constraints
TWI464580B (zh) 2012-12-24 2014-12-11 Ind Tech Res Inst 資料儲存方法、採用此方法的資料儲存系統及需求節點
EP3449450B1 (en) 2016-04-29 2022-06-15 Nchain Holdings Limited Implementing logic gate functionality using a blockchain
GB201607477D0 (en) * 2016-04-29 2016-06-15 Eitc Holdings Ltd A method and system for controlling the performance of a contract using a distributed hash table and a peer to peer distributed ledger

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0981438A (ja) * 1995-09-20 1997-03-28 Nec Corp クライアントサーバシステムにおける自動排他制御システム
JP2000020423A (ja) * 1998-06-30 2000-01-21 Toshiba Corp リアルタイム情報配信方法
JP2001117807A (ja) * 1999-07-28 2001-04-27 Matsushita Electric Ind Co Ltd ネットワークに接続された記憶装置のためのスケーラブルなマルチメディアファイルシステム

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5553298A (en) * 1994-04-14 1996-09-03 Merryman, Deceased; Philip I. Method and apparatus for mutual exclusion in self-directed distributed systems
US5913213A (en) 1997-06-16 1999-06-15 Telefonaktiebolaget L M Ericsson Lingering locks for replicated data objects
US6178441B1 (en) * 1998-09-21 2001-01-23 International Business Machines Corporation Method and system in a computer network for the reliable and consistent ordering of client requests
US7133891B1 (en) * 2000-05-31 2006-11-07 International Business Machines Corporation Method, system and program products for automatically connecting a client to a server of a replicated group of servers
US7155524B1 (en) * 2000-12-04 2006-12-26 Lucent Technologies Inc. Backoff protocols and methods for distributed mutual exclusion and ordering
US7231554B2 (en) * 2002-03-25 2007-06-12 Availigent, Inc. Transparent consistent active replication of multithreaded application programs
US6928577B2 (en) * 2002-07-29 2005-08-09 Eternal Systems, Inc. Consistent message ordering for semi-active and passive replication
US7917646B2 (en) * 2002-12-19 2011-03-29 Intel Corporation Speculative distributed conflict resolution for a cache coherency protocol

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0981438A (ja) * 1995-09-20 1997-03-28 Nec Corp クライアントサーバシステムにおける自動排他制御システム
JP2000020423A (ja) * 1998-06-30 2000-01-21 Toshiba Corp リアルタイム情報配信方法
JP2001117807A (ja) * 1999-07-28 2001-04-27 Matsushita Electric Ind Co Ltd ネットワークに接続された記憶装置のためのスケーラブルなマルチメディアファイルシステム

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007063944A1 (ja) * 2005-11-30 2007-06-07 International Business Machines Corporation 無停止トランザクション処理システム
JP4871296B2 (ja) * 2005-11-30 2012-02-08 インターナショナル・ビジネス・マシーンズ・コーポレーション 無停止トランザクション処理システム
TWI416901B (zh) * 2005-11-30 2013-11-21 Ibm 故障容忍之異動處理系統
JP2010157204A (ja) * 2008-09-11 2010-07-15 Nec Lab America Inc 検索可能なブロックを用いた連想記憶システムおよびその方法
JP2011154631A (ja) * 2010-01-28 2011-08-11 Fujitsu Ltd 確定クロック判定プログラム及び方法、並びにノード装置
JP2019175222A (ja) * 2018-03-29 2019-10-10 日本電気株式会社 電文保証システムおよび電文保証方法
JP7124384B2 (ja) 2018-03-29 2022-08-24 日本電気株式会社 電文保証システムおよび電文保証方法

Also Published As

Publication number Publication date
JP4837929B2 (ja) 2011-12-14
KR101120844B1 (ko) 2012-03-15
US7526672B2 (en) 2009-04-28
EP1571801A2 (en) 2005-09-07
US20050188085A1 (en) 2005-08-25
EP1571801A3 (en) 2011-03-02
KR20060043196A (ko) 2006-05-15

Similar Documents

Publication Publication Date Title
JP4837929B2 (ja) 動的ピアツーピア環境における相互排除技法
JP5798644B2 (ja) フェデレーションインフラストラクチャ内の一貫性
US6889253B2 (en) Cluster resource action in clustered computer system incorporation prepare operation
US8108455B2 (en) Mobile agents in peer-to-peer networks
US7254608B2 (en) Managing distribution of content using mobile agents in peer-topeer networks
US8037202B2 (en) Presence detection using mobile agents in peer-to-peer networks
JP6059216B2 (ja) 分散構成管理のための方法および装置
TW201007489A (en) Peer-to-peer redundant file server system and methods
Lin et al. A practical distributed mutual exclusion protocol in dynamic peer-to-peer systems
US11620087B2 (en) Implicit leader election in a distributed storage network
US20100322256A1 (en) Using distributed timers in an overlay network
Shen et al. A proximity-aware interest-clustered P2P file sharing system
Temkow et al. PaxonDHT: Achieving consensus in distributed hash tables
JP2009230686A (ja) コンテンツ管理サーバ及びコンテンツ管理プログラム
CN100581109C (zh) 动态对等网络环境中的互斥系统和方法
Shafaat Partition tolerance and data consistency in structured overlay networks
Luntovskyy et al. Architectural transformations in distributed systems
Frank et al. Picsou: Enabling Efficient Cross-Consensus Communication
Campos et al. Improving the scalability of DPWS-based networked infrastructures
Bashir Distributed Consensus
Jothen Acropolis: aggregated client request ordering by Paxos
JP2006107118A (ja) Ｐ２ｐ環境におけるビザンチン耐故障ファイル共有の応答高速化方法
Lu Improving data consistency management and overlay multicast in Internet-scale distributed systems
Abouzamazem Efficient and scalable replication of services over wide-area networks
Yu et al. Atomic distributed semaphores for accessing networked data

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080205

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101019

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110119

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20110415

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110811

RD13 Notification of appointment of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7433

Effective date: 20110812

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20110812

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20110901

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: 20110922

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: 20110929

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20141007

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees
S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R371 Transfer withdrawn

Free format text: JAPANESE INTERMEDIATE CODE: R371