A real modern communication would be something like NATS (somewhat similar to ZeroMQ in concepts). It's quite amazing, even more frictionless than ZeroMQ.
Maybe because the actual use of ZeroMQ varies a lot. Some brokerless-daisy-chain, some brokerless-mesh, some paired with brokers of different types (Zookeeper, RabbitMQ, others), and so on. So a comparison would be hard.
It took me two days to learn it's specifics 3 years ago, and after that I never-ever had a problem with it. ItJustWorks(TM).
In this sense it's a bit like Sqlite, which also JustWorks, as opposed to something like Postgres which requires more fiddling and maintenance.
And functionally, it allowed me to create a service-bus topology where multiple processes can post messages on a set of subjects that can be subscribed by multiple other processes (think stock market quotes). This pattern is surprisingly difficult to implement in other message brokers.
Enlighten me on surprisingly difficult? Topics are a pretty well known feature. The key difference between nats and rabbitmq is that nats disconnects a consumer if it is not fast enough which is the key differentiator for nats.
pipes / sockets is the mechanism but protocols is the means. what are some protocols and their elements worth knowing?
I suspect folks will point at protocols that already exist and work great. But, ideally, we wouldn't start there. But instead, unpack them from the very basic (simplex, synchronous) to the advanced.
For example, we have lists and trees as basic data structures to postgres as more advanced for managing data. At some point, you reach for the RDBMS but developers get plenty of mileage out of simpler solutions. Throughout our careers we've bumped into many protocols, I've not been able to digest, appreciate, and study their constituents. When should one mock up a quick protocol vs invest or extend an existing one?
Design protocols is fascinating to me. Compared to things that I design on a regular basis, software or APIs, it seems different.
13 comments
[ 4.6 ms ] story [ 39.6 ms ] threadhttps://nats.io/
https://github.com/nats-io
In this sense it's a bit like Sqlite, which also JustWorks, as opposed to something like Postgres which requires more fiddling and maintenance.
And functionally, it allowed me to create a service-bus topology where multiple processes can post messages on a set of subjects that can be subscribed by multiple other processes (think stock market quotes). This pattern is surprisingly difficult to implement in other message brokers.
There is SSL support everywhere, but nothing seems to support DTLS? Do people even use it?
https://ocaml.github.io/ocamlunix/index.html
I suspect folks will point at protocols that already exist and work great. But, ideally, we wouldn't start there. But instead, unpack them from the very basic (simplex, synchronous) to the advanced.
For example, we have lists and trees as basic data structures to postgres as more advanced for managing data. At some point, you reach for the RDBMS but developers get plenty of mileage out of simpler solutions. Throughout our careers we've bumped into many protocols, I've not been able to digest, appreciate, and study their constituents. When should one mock up a quick protocol vs invest or extend an existing one?
Design protocols is fascinating to me. Compared to things that I design on a regular basis, software or APIs, it seems different.