I may have been doing it wrong, but i personally want to know when clients disconnect/reconnect/etc. the API seems to hide all that from you and your send or recv just block.
So, you can set up a protocol using ZMQ such that you become aware when a client times out, and you can set behavior regarding the high water mark, and other things, but you have to actually do it explicitly - it's not required that you do it, because you can choose to maximize throughput or minimize latency instead.
But, whatever protocol behavior / performance you want, you can pretty much build it with ZMQ. In Python, ZMQ was the only "feasible for my not-a-network-engineer-self" to get a system with 100μs latency with sufficient throughput and guarantees (when used for IPC, although not using the IPC transport type). gRPC was a lot less performant for me, granted it would've been more convenient, but the low latency was a hard need.
Although, networks are one of my noobier areas, so I might be blind in many ways here.
Is this all just about having a common cross-language API for TCP? Wasn't "BSD sockets" supposed to be that?
And, the component was just "a component" and not "the purpose" of what I was building, so went with ZMQ.
I'm also highly inexperienced in that area, so ZMQ having a singular, well-written, linear manual was a huge benefit.
I always found it crazy how zmq gained any traction at all.
"Oh, I have a req/resp workload" - one of the sides restarts, goes out of rhythm with the state of the connection (whether its req or resp), unrecoverable errors.
Every system I've seen use zmq usually use it without these fancy patterns (use yeet messages in any order), and usually have some sort of "Is anybody there on the other side?" message to combat the fact there is no way to introspect connection state (otherwise your writes just block at the high water mark), at which point it would have been easier to just use tcp.
The whole thing to me reeks of mongo. It's great if you are completely incapable/incompetent of solving the problem properly.
Funny, I always used ZeroMQ as a message-oriented TCP-like protocol that reconnects automatically.
> It's great if you are completely incapable/incompetent of solving the problem properly.
Oof. I think it's great if you don't want to mess with low-level socket details and just want to write a actor-like messaging protocol.