4 ms·

Very few distributed systems have the communication volume and patterns necessary to justify explicit scheduling policy beyond round-robin and fair-queuing. In

Very few distributed systems have the communication volume and patterns necessary to justify explicit scheduling policy beyond round-robin and fair-queuing. In fact, many distributed systems get by just fine on HTTP using round-robin load balancing and even without keep alive! I've worked with some pretty big systems that use a model that look an awful lot like 0mq and perform splendidly. I've also worked on several smaller systems (games) that needed to use UDP and all kinds of custom semantics for reliability to accomplish their task. I'd imagine that if such a thing happens when you scale down, what you're saying is possible when you scale up. To anyone reading this thread: If you don't understand all the complexities of jandrewrogers' response, just assume YAGNI. In that case, if your problem lends itself to a stream oriented protocol, then ZeroMQ is a great choice. You can deal with the other complexities if the need arises.

jandrewrogers 14y ago
All the systems you are talking about are so loosely coupled that most people do not classify them as "distributed systems", certainly not in the computer science sense. The complexity is not in the number of machines but in the interactions and coupling of individual nodes required by basic operation of the cluster. Lots of things work very well with ZMQ, just not distributed systems. If your application scales efficiently on ZMQ then it is a giant pile of computers and not a "distributed system". I've seen systems that scale to thousands of nodes and also seen systems that won't scale past a few machines on ZMQ. System architects should be able to distinguish the two cases without standing up a cluster to see if it fails. All it requires is one part of your system to not fit the ZMQ case for things to start falling apart. That this is an expected result is not exotic computer science.
- snprbob86 14y ago
  > If your application scales efficiently on ZMQ then it is a giant pile of computers and not a "distributed system". At this point, I'm invoking Poe's law.

jandrewrogers 14y ago

All the systems you are talking about are so loosely coupled that most people do not classify them as "distributed systems", certainly not in the computer science sense. The complexity is not in the number of machines but in the interactions and coupling of individual nodes required by basic operation of the cluster. Lots of things work very well with ZMQ, just not distributed systems. If your application scales efficiently on ZMQ then it is a giant pile of computers and not a "distributed system". I've seen systems that scale to thousands of nodes and also seen systems that won't scale past a few machines on ZMQ. System architects should be able to distinguish the two cases without standing up a cluster to see if it fails. All it requires is one part of your system to not fit the ZMQ case for things to start falling apart. That this is an expected result is not exotic computer science.

snprbob86 14y ago
> If your application scales efficiently on ZMQ then it is a giant pile of computers and not a "distributed system". At this point, I'm invoking Poe's law.