The Game of Distributed Systems Programming. Which Level Are You?

http://blog.incubaid.com/2012/03/28/the-game-of-distributed-systems-programming-which-level-are-you/

by nicolast • 14 years ago

26 6 14 years ago

blog.incubaid.com

setori88• 14 years ago

Im pretty certain that the 'final' level that he talks about doesn't make use of timeouts, but stream monitors that raise temp fault, perm failure and okay flags.

he makes no mention of streams nor of the concept of a port which (in oz) is used to corden of nondeterminism.

pvanroy• 14 years ago

This is a very nice classification. It does ring true in my experience, although I would put a few more levels between level 3 and level 4. Very few people are anywhere near level 4.

Your level 3 makes a few "level 2 mistakes". For example, time outs are evil, since they force a decision to be made at the wrong level of the system. Protocol stacks shouldn't use time outs. Rather, they should pass the request to stop or continue waiting to the right level of the system (which can go all the way up to the application level and even to the user level!). Unfortunately, the most-used protocol stacks either don't implement this or it's not exposed to the application programmer. And so we still have a long way to go.

nicolast2• 14 years ago

The 'timeout' as referred to in the list of possible actions ('schedule a timeout') refers to the timeout mechanism used to implement master election in Arakoon, our product on which some of the experience in the article is based, where we attempt to be at level 3 in the rewrite we're currently working on.

When this action is evaluated (in the impure part of the system), an action will be scheduled with the threading system for execution sometime later, at which point some new message will be sent through the machinery, just like any other message received from another node on the network.

It's not about timeouts on message transmission or anything alike.

sausagefeet2• 14 years ago

Does this mean channels, like in CSP (what Go does), are unfit for distributed envs because they are synchronous?

nicolast2• 14 years ago

Why would CSP be 'synchronous'? There's a difference between how things appear (API) and how the implementation works: it's certainly possible to have an API which looks synchronous, yet everything is async at runtime. Think about Haskell's do-notation with GHC's IO manager, the Erlang approach, something like Gevent/Greenlets in Python,...

sausagefeet2• 14 years ago

Because, AFAIK, CSP is defined by synchronous message passing:

- CSP message-passing fundamentally involves a rendezvous between the processes involved in sending and receiving the message, i.e. the sender cannot transmit a message until the receiver is ready to accept it.

- Programs in the original CSP were written as a parallel composition of a fixed number of sequential processes communicating with each other strictly through synchronous message-passing.

- The PAT process language extends CSP with support for ..., asynchronous message passing, ...

http://en.wikipedia.org/wiki/Communicating_sequential_proces...

GHC's IO, Erlang, and Gevent are not implementations of CSP. Go is, though, which makes me wonder if Go is not a good tool to implement distribution in if they added inter-vm channels.

The Game of Distributed Systems Programming. Which Level Are You?

Related Stories