At the end of Chapter 1, the ZeroMQ guide mentions that
Traditional network programming is built on the general assumption that one socket talks to one connection, one peer. There are multicast protocols, but these are exotic. When we assume “one socket = one connection”, we scale our architectures in certain ways. We create threads of logic where each thread work with one socket, one peer. We place intelligence and state in these threads.
When I first read this paragraph, it’s a bit unclear why using ZeroMQ a paradigm shift. After exploring a bit more code, I find this is actually straightward. For instance, we can use this pattern to receive data from multiple endpoints.
use context = new Context()
use receiver = Context.pull context
connect receiver "tcp://*:5555"
connect receiver "tcp://*:5556"
connect receiver "tcp://*:5557"
connect receiver "tcp://*:5558"
let msg = receiver |> recv |> decode
...The last receiver |> recv |> decode would block wait on one of the push endpoints. It works like golang‘s fan-in channel. Think of pulling data from multiple weather stations, and you wait for the first piece of data coming from one of the stations. I don’t need to deal with many sockets, just one socket rules them all. This definitely simplifies tons of code.