4 ms·

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

26 points by nicolast 15y ago

setori88 15y 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 15y 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.
- nicolast 15y 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.
sausagefeet 15y ago
Does this mean channels, like in CSP (what Go does), are unfit for distributed envs because they are synchronous?
- nicolast 15y 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,...
  - sausagefeet 15y 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_processes 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.

26 points by nicolast 15y 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 15y 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.

nicolast 15y 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.

sausagefeet 15y ago

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

nicolast 15y 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,...
- sausagefeet 15y 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_processes 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.