ongardie

9 ms·

1.
by ongardie 2y ago
The issue if realms stored HMAC(realm_id + PIN), where PINs are presumed to be low-entropy, then an individual realm could brute-force the PIN. Specifically, an adversary with access to a single realm's database could enumerate PINs, r
2.
by ongardie 11y ago
I included the paper proof for Raft in my PhD dissertation, but there's a good chance it contains errors. Here's a quote from the intro: "The proof shows that the specification preserves the State Machine Safety property. The
3.
by ongardie 11y ago
If the network is split into AB and CDE, then only CDE will be able to reach a quorum. If a client is on the AB side of that split, no consensus algorithm could guarantee freshness on a read. LogCabin clients will continually retry until th
4.
by ongardie 11y ago
Raft implementations can choose to implement reads in various ways. In LogCabin reads are linearizable, meaning that the results are current as of sometime after the read request was initiated, and it doesn't rely on bounded clock drif
5.
by ongardie 11y ago
Yes, good point. I welcome Mr. McCaffrey to give it a spin, if he's so willing. And though there may be critical bugs left to find, I don't feel like I've misrepresented the current state of LogCabin.
6.
by ongardie 11y ago
Good timing then, and I'd be happy to talk more about whether LogCabin is a good fit for your use. RAMCloud used to depend on an earlier version of LogCabin (before the data model was a key-value tree), then John rewrote the RAMCloud e
7.
by ongardie 11y ago
I guess the answer is no, I haven't really looked at it. Anyone have experience with it in a large-ish project outside of Node?
8.
by ongardie 11y ago
Maybe, but I don't think it matters much. The comment there explains the issue, and I vaguely remember my measurements showing that this wasn't a big deal. I do think it's an interesting (dare I say) limitation of epoll, and
9.
by ongardie 11y ago
In part that's because I don't see other Raft implementations as competitors. A major goal in Raft was to enable many implementations. It'd be a huge fail if everyone switched to LogCabin and abandoned all the other Raft impl
10.
by ongardie 11y ago
This question came up at the CoreOS Fest earlier today too. I think everyone wants libraries as well as services, and I'd like that too for LogCabin one day. It's just a bit harder when you start thinking about the details. It&#x2
11.
by ongardie 11y ago
It's a good question, and I don't really know where the community as a whole sits on Byzantine vs non-Byzantine. A few thoughts: Byzantine is more complex, and most people in industry aren't doing it: there are a lot of Byzan
12.
by ongardie 11y ago
There's not currently an extern "C" wrapper, but I don't think that'd be too much work to write.
13.
by ongardie 11y ago
Compaction in LogCabin uses a snapshotting approach. It writes a header to a snapshot file, then forks off a child process to write the data into a snapshot. The data is just each node in the tree serialized as a protobuf using a pre-order
14.
by ongardie 11y ago
You end up needing consensus for a lot of fault-tolerant systems that need to provide consistent results. For example, if your system allows users to choose their own usernames, and you're trying to guarantee that all usernames are uni
15.
by ongardie 11y ago
I've certainly been to that page before :) I come from an academic lineage of log-based projects, from log-structured filesystems [1] which structure disks as a log, to RAMCloud [2][3][4] whose durability/recovery aspects are a di
16.
by ongardie 11y ago
I think I'd have to agree with you now: REST APIs seem to help with adoption. LogCabin was initially created for use with RAMCloud ( http://ramcloud.stanford.edu ), which mostly hand-rolls its RPC serialization to achieve i
17.
by ongardie 11y ago
LogCabin uses its event loop for network operations but then hands requests off to threads to process. I started out with libevent2, but the problem is it doesn't deal with having multiple threads very well (error-prone and inefficient