2 ms·

No, I'm familiar with CAP. My theorem is different. Reliable: A system can be available but not reliable; if a machine is down 6 minutes every hour, it's 90% a

No, I'm familiar with CAP. My theorem is different. Reliable: A system can be available but not reliable; if a machine is down 6 minutes every hour, it's 90% availabile but less than 1 hour reliable. A networked distributed system can be reliable but not accurate if you keep it online while it slowly accrues errors, such as the mentioned link/unlink race condition. The machine still works, it just has occasional corruption. It tends not to be very fast if it's reliable. Fast: You can do whatever you want quickly. Think UDP, or filesystems that don't commit their log journal frequently. Tends not to be reliable or accurate. Accurate: Whatever you do has no corrupted state. Think ACID. Most systems don't do this because it's expensive/complicated.

robertlagrant 3y ago
Apologies - fair enough. I can't quite tell if that is a genuine set of three alternatives or not[0], but I sort of see your point. Couple of unsure places: > Think ACID. Most systems don't do this because it's expensive/complicated. Is this true? A lot of systems are built on databases. > Accurate: Whatever you do has no corrupted state How does accuracy work if the system is distributed and there's a partition, and two node get different data? Presumably it's reliable if they're different, as accuracy is a different item? > Fast: You can do whatever you want quickly. Think UDP, or filesystems that don't commit their log journal frequently. Tends not to be reliable or accurate. Why wouldn't this be reliable?
- throwawaaarrgh 3y ago
  Most databases aren't ACID compliant, and even if they can be, they're often used in a non-ACID way. > How does accuracy work if the system is distributed and there's a partition, and two node get different data? You don't allow writes during a partition. All nodes (or a quorum) must confirm on each write, and if that fails then a partition is detected. Everything that was accidentally written before you detected partition is thrown away. Usually you just have one writer node for simplicity. > Fast: > Why wouldn't this be reliable? If you prioritize reliability you will need a slower method to ensure reliability. TCP is slower than UDP so it can be reliable.
  - robertlagrant 3y ago
    > You don't allow writes during a partition. All nodes (or a quorum) must confirm on each write, and if that fails then a partition is detected. Everything that was accidentally written before you detected partition is thrown away. Usually you just have one writer node for simplicity. Wouldn't this be done better with a majority/minority approach, where if enough nodes are still communicating then they still work? > If you prioritize reliability you will need a slower method to ensure reliability. TCP is slower than UDP so it can be reliable. Agree - that is true in the TCP sense of the word reliable. But in your sense of the word, as I understood it, the TCP/UDP difference is more like "accuracy", is it not? Reliability is more like availability, as I read it in your previous comment.

robertlagrant 3y ago

Apologies - fair enough. I can't quite tell if that is a genuine set of three alternatives or not[0], but I sort of see your point. Couple of unsure places: > Think ACID. Most systems don't do this because it's expensive/complicated. Is this true? A lot of systems are built on databases. > Accurate: Whatever you do has no corrupted state How does accuracy work if the system is distributed and there's a partition, and two node get different data? Presumably it's reliable if they're different, as accuracy is a different item? > Fast: You can do whatever you want quickly. Think UDP, or filesystems that don't commit their log journal frequently. Tends not to be reliable or accurate. Why wouldn't this be reliable?

throwawaaarrgh 3y ago
Most databases aren't ACID compliant, and even if they can be, they're often used in a non-ACID way. > How does accuracy work if the system is distributed and there's a partition, and two node get different data? You don't allow writes during a partition. All nodes (or a quorum) must confirm on each write, and if that fails then a partition is detected. Everything that was accidentally written before you detected partition is thrown away. Usually you just have one writer node for simplicity. > Fast: > Why wouldn't this be reliable? If you prioritize reliability you will need a slower method to ensure reliability. TCP is slower than UDP so it can be reliable.
- robertlagrant 3y ago
  > You don't allow writes during a partition. All nodes (or a quorum) must confirm on each write, and if that fails then a partition is detected. Everything that was accidentally written before you detected partition is thrown away. Usually you just have one writer node for simplicity. Wouldn't this be done better with a majority/minority approach, where if enough nodes are still communicating then they still work? > If you prioritize reliability you will need a slower method to ensure reliability. TCP is slower than UDP so it can be reliable. Agree - that is true in the TCP sense of the word reliable. But in your sense of the word, as I understood it, the TCP/UDP difference is more like "accuracy", is it not? Reliability is more like availability, as I read it in your previous comment.