Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZeroMQ: High-Performance Concurrency Framework

zeromq.org

Post reply on HN
Print view View original

31–40 of 58 posts

Re: ZeroMQ: High-Performance Concurrency Framework

#31

Post by bheadmaster »

ohnoesjmr wrote: post #27
sigmonsays wrote: post #13

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.

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?" me…

> 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.

Re: ZeroMQ: High-Performance Concurrency Framework

#35

Post by taspeotis »

jvanderbot wrote: post #4
thesuperbigfrog wrote: post #3

ZeroMQ was followed by nanomsg ( https://nanomsg.org/ ) and nng ( https://nng.nanomsg.org/ ) Some of Martin's rationale here: https://250bpm.com/blog:23/index.html ZeroMQ is still widely used and popular, but I am not sure if it is still actively developed.

I've used zeromq, nanomsg, and nng. The differences are subtle and focused on native library support, background threading model, and other systems level things. All of them are based on specs that are widely published. I've had zero problems implementing real robotic systems in nng, zmq, etc. And it is so damn easy to use it's amazing to me the whole world doesn't use it.

> it's amazing to me the whole world doesn't use it.

I Googled nng and apparently it's this? [1]

It's written in C so if you click the issues tab the second and third issues are "IPC - Use After Free" and "Setting TLS config option via nng_socket_set_ptr causes access violation if you free config."

Why would you want the world to build other software on this?

[1] https://github.com/nanomsg/nng

Re: ZeroMQ: High-Performance Concurrency Framework

#36

Post by CharlieDigital »

masfoobar wrote: post #20
nlnn wrote: post #19

Earlier quoted context omitted.

I've been looking at these recently for a project. nng looks promising, but the guide from zmq seemed like a killer feature. It describes all sorts of high level patterns, gotchas, etc. For nng I mostly found API documentation, which made me a bit more cautious (though to be fair, I've not tried it yet).

I have used ZeroMQ with C, Dlang, and Python -- mostly for learning. However, I have used NetMQ.. a C# implementation of ZeroMQ in live software and the results are very positive! I used a Pub-Sub pattern for one program to keep users informed on progress of a task, which could have taken hours to complete. They had a GUI program which spits out updates. It worked really well. I was also tasked updating a Till softwa…

In 2014, I was tasked with rebuilding an event processing engine to increase throughput and performance. Used ZeroMQ with C# and also had a very positive experience.

It was very easy to build a multi-node, distributed event processing engine (think Apache Flink) that could scale by simply adding more nodes or threads. ZMQ makes coordination and management of messages easy and low-fanfare.

In our use case, it was stable and it was the least problematic part of a relatively complex platform.

Re: ZeroMQ: High-Performance Concurrency Framework

#37

Post by mindslight »

exe34 wrote: post #25
mindslight wrote: post #8

Earlier quoted context omitted.

I looked at 0mq et al, and what I couldn't understand is why sockets have a single exclusive type. Like say I want a process that generally sends out streaming broadcast updates, but is also controlled through request-reply. It would need two separate sockets. Then I'd have to reinvent some sort of ordering protocol across the two (as well as program logic to handle the partially-connected state), which would defeat…

news = -setup broadcast socket- orders = -setup req rep socket- while 1: ----order = orders.read (with timeout) ----orders.send(ack) ----if order: --------do stuff differently ----news.send(status)

And then how does a client know whether an `order` was processed before or after a specific `status`? If you start talking about adding sequence numbers or duplicating application data between `status` and `order` (and its reply), that's the creation of an ad-hoc ordering protocol I'm talking about.

Re: ZeroMQ: High-Performance Concurrency Framework

#39

Post by mindslight »

nurettin wrote: post #22
mindslight wrote: post #8

Earlier quoted context omitted.

I looked at 0mq et al, and what I couldn't understand is why sockets have a single exclusive type. Like say I want a process that generally sends out streaming broadcast updates, but is also controlled through request-reply. It would need two separate sockets. Then I'd have to reinvent some sort of ordering protocol across the two (as well as program logic to handle the partially-connected state), which would defeat…

Without knowing any details, it sounds like a hard problem whether you use 0mq or not.

The problem generally needs to be solved by the transport protocol. Having two sockets communicating in parallel means the problem needs to be solved again.

Re: ZeroMQ: High-Performance Concurrency Framework

#40

Post by packetlost »

sigmonsays wrote: post #13

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.

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).
Post reply on HN