PDF Publication Title:
Text from PDF Page: 062
62 3.8. EPOCHS Conversely, we could increase the number of roles, for example we could add a reader role, a participant who asks acceptors for the last accepted proposal to try to determine if the value has been decided and what that value is or a recovery proposer who acts like a proposer except if no values are returned in phase one then they exit instead of returning a value. 3.8 Epochs Earlier we specified that epochs, E, are required to be an infinite totally ordered set (Definition 2) and that each proposer should be given a disjoint subset of the epochs. Our pseudocode remains general and does not specific how epoch such be generated. Many different mechanisms could be utilised to allocate epochs. The approach used in our examples is that epochs are natural numbers E = N0, which have been divided round robin between the proposers. Alternatively, epochs could be lexicographically ordered tuples of the form (sid, pid), where sid is the proposal sequence number (persistent state) and pid is the unique proposer id (config). The current sid must be written to persistent storage before use by the proposer to ensure proposal uniqueness. Since sid is monotonically increasing, only the most recent sid need be stored11. Both these approaches require each proposal to begin with a synchronous write to persistent storage. This can be avoided by instead using epochs of the form (sid, pid, vid), where sid is the sequence number (volatile state), pid is the unique proposer id (config) and vid is the proposer version number (persistent state). Proposers must increment vid each time they restart to ensure uniqueness of epochs, without writing sid updates to persistent storage. Alternatively, we can avoid most synchronous writes by writing an upper bound on epoch e to persistent storage and only updating it as needed12. Epochs could otherwise be of the form (sid, pid), where sid is stored in volatile state but an upper bound is stored on persistent state. This approach of writing an upper bound on a epoch to persistent storage can also be applied to the last promised epoch on acceptors. This removes the need for a synchronous writing to persistent each time an acceptor promises. In practice, the write to persistent storage does not need to be completed until the start of phase two to maintain proposal uniqueness. As such, updating E and execution of phase one can be completed concurrently, mitigating the latency of a synchronous write to persistent storage. 11Note that with this scheme, pid and sid would replace E. 12This is equivalent to batch pre-executing the writes to persistent storage.PDF Image | Distributed consensus
PDF Search Title:
Distributed consensusOriginal File Name Searched:
UCAM-CL-TR-935.pdfDIY PDF Search: Google It | Yahoo | Bing
Cruise Ship Reviews | Luxury Resort | Jet | Yacht | and Travel Tech More Info
Cruising Review Topics and Articles More Info
Software based on Filemaker for the travel industry More Info
The Burgenstock Resort: Reviews on CruisingReview website... More Info
Resort Reviews: World Class resorts... More Info
The Riffelalp Resort: Reviews on CruisingReview website... More Info
| CONTACT TEL: 608-238-6001 Email: greg@cruisingreview.com | RSS | AMP |