Closed Hoverbear closed 9 years ago
love it... making a mess with a few questions and edits, feel free to ignore!
Today our systems operate in extreme conditions, functioning across containers, virtual machines, infrastructure, networks, embedded systems, in our pockets, and even inside of us. Many of these systems depend on one another for operation, while others are able to operate in failing connectivity without disaster. In many cases it is preferable to have the latter, especially if the continued operation of the system is at stake. Distributed consensus represents one small part of a larger system, and offers the ability to maintain a replicated persistent log containing actions that are applied globally into a state machine. This allows n clients to communicate to a cluster of m servers in a stable and predictable manner, even in failing network conditions. Could be worth mentioning something about how the complexity of Paxos was uninviting, but now many more researchers are diving in with many more languages... or something?!
Using Ongaro and Osterhouts's Raft algorithm we are developing a fast, low level, low demands implementation of the system in an opinionated, minimal way. Might be worth clarifying exactly what you mean by "low demands" and "opinionated"?
The Raft library interfaces with custom or preexisting Log and State Machine implementations, providing a Client, Server, and Consensus Module within its core. We have chosen an asynchronous single threaded event loop model in the Rust language, allowing our implementation to have strong safety and performance characteristics with low demands. Communication, a primary performance concern, is kept as lightweight and fast as possible by using Renshaw's Cap'n Proto implementation. TODO: Talk about performance tests and testing. Absolutely---if it is possible to show yours relative to any of the others on the Raft page, that would ROCK! Updating your row there before submitting would be great as well!
We are currently exploring opportunities in trust and security as well as testing our implementation for further failure conditions.
b e a u t i f u l !
s/Rensha/David Renshaw/
@dwrensha Gosh darnit I do that all the time, I'm so sorry!
From your twitter:
@dwrensha
The 'w' comes earlier than you'd think!
@ycoady Once we get more features working and have more battle testing doing some performance measurements would be very useful, yeah. I remember Min was working on a consensus tester!
Moreso, though, I'm interested in testing reliablility and stablility.
@james-darkfox want to be included in on this? No obligations from you other than keep contributing! :)
@Hoverbear Sure!
Updated abstract with @ycoady's feedback.
Updated poster and abstract with some initial benchmarks. The abstract is too darn long!
We submitted this! Closing for now. If we get accepted I'll open a new issue!
The poster was rejected.
Rejected due to any reason specified or undisclosed why?
@ycoady suggested we consider submitting a poster to SOSP'2015!
Location: Monterey, California, USA Submission deadline (HARD, NO EXTENSIONS): July 31, 2015 (23:59PM PDT) Acceptance notification: August 7, 2015 Conference: October 4-7, 2015
Details: http://www.ssrc.ucsc.edu/sosp15/callForPosters.html
Abstract