
NetChain: Scale-free sub-RTT coordination - signa11
https://blog.acolyer.org/2018/04/30/netchain-scale-free-sub-rtt-coordination/
======
firebacon
I'd like to understand how this system deals with failed writes. I.e. if a
switch fails while a write is in progress, is it guaranteed that the in-
progress write either becomes fully visible or not visible at all after the
reconfiguration? How is this achieved?

For example, if the head switch fails while the write is being applied on it,
it's not obvious to me how the system would still guarantee that the write
would not be lost.

On the other hand, if the tail switch fails while the write is being applied
on it, there must be some kind of rollback mechanism during the
reconfiguration phase to remove the dirty write from all the preceding
switches, no? Can somebody point me to the relevant section of the paper that
describes how this works?

~~~
ithkuil
Suggested reads: vertical paxos and primary backup replication protocols

------
signa11
and the actual paper is available here:
[https://www.usenix.org/system/files/conference/nsdi18/nsdi18...](https://www.usenix.org/system/files/conference/nsdi18/nsdi18-jin.pdf)

------
rosstex
What's the catch?

~~~
ithkuil
1\. You need to control your network equipment (and requires expensive
programmable switches)

2\. Only single key "transactions"

3\. Only small values (IIRC <200bytes)

