4 ms·

I would rather use sockets. Not getting errors when a client times out is a bad api design to me. I've used zeromq an only kept it around for IPC. I may have

I would rather use sockets. Not getting errors when a client times out is a bad api design to me. I've used zeromq an only kept it around for IPC. 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.

haneul 2y ago
Imo, ZMQ is more of an abstraction with which to design protocols, rather than a message queue ready to use, Kafka-style. I found unexpectedly that I needed to really read the entire manual and work through the worked examples and some of my own to start getting it, rather than the usual incremental read. 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.
- otabdeveloper4 2y ago
  I don't see what ZMQ abstracts that you don't get in TCP already. Is this all just about having a common cross-language API for TCP? Wasn't "BSD sockets" supposed to be that?
  - haneul 2y ago
    For me, the benefit was a lot of convenience. 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.
ohnoesjmr 2y ago
Pretty much this. 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.
- bheadmaster 2y ago
  > at which point it would have been easier to just use tcp 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.
packetlost 2y ago
We've used ZMQ rather successfully, but step 1 of ZMQ is don't use REQ/REP at all, ever. It has advantages primarily around throughput and abstracting details across different mediums (which is sometimes actually a detriment).

haneul 2y ago

Imo, ZMQ is more of an abstraction with which to design protocols, rather than a message queue ready to use, Kafka-style. I found unexpectedly that I needed to really read the entire manual and work through the worked examples and some of my own to start getting it, rather than the usual incremental read. 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.

otabdeveloper4 2y ago
I don't see what ZMQ abstracts that you don't get in TCP already. Is this all just about having a common cross-language API for TCP? Wasn't "BSD sockets" supposed to be that?
- haneul 2y ago
  For me, the benefit was a lot of convenience. 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.

ohnoesjmr 2y ago

Pretty much this. 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.

bheadmaster 2y ago
> at which point it would have been easier to just use tcp 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.

packetlost 2y ago

We've used ZMQ rather successfully, but step 1 of ZMQ is don't use REQ/REP at all, ever. It has advantages primarily around throughput and abstracting details across different mediums (which is sometimes actually a detriment).