41–50 of 58 posts
NATS is the ZeroMQ of today.
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.
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 behav…
Is this all just about having a common cross-language API for TCP? Wasn't "BSD sockets" supposed to be that?
NATS is the ZeroMQ of today.
They're not even remotely the same thing. You could build NATS on ZeroMQ but not the other way around. ZeroMQ is more like a network/message-passing abstraction library while NATS is a service .
Earlier quoted context omitted.
The licensing was changed about nine months ago. LGPL-3.0+ is out and MPL 2.0 is in. Very thankful for that.
Why are you thankful for the MPL instead of the LGPL? Is there any advantage to the MPL other than being easier to incorporate MPL code into proprietary software?
Earlier quoted context omitted.
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
Earlier quoted context omitted.
The licensing was changed about nine months ago. LGPL-3.0+ is out and MPL 2.0 is in. Very thankful for that.
I always get confused when I see MPL... part of me panics thinking ZeroMQ went with the "Microsoft Public License" :-)
Earlier quoted context omitted.
They're not even remotely the same thing. You could build NATS on ZeroMQ but not the other way around. ZeroMQ is more like a network/message-passing abstraction library while NATS is a service .
I'd 90% agree with this, except that NATS does have an embedded mode.[0] That plus the clustering, gateway, and leaf-node features gets it very close to what ZeroMQ is doing, though at a much higher complexity level that's maybe unnecessary depending on what you're doing. Embedding is exclusive to Go programs, so that's very limited compared to ZeroMQ. [0]: https://www.youtube.com/watch?v=cdTrl8UfcBo
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
that doesn't sound like a socket level problem, it's more like an application level problem? how long does it take to obey-orders()? do you want to keep spitting out logs while doing it? maybe give orders a number, and the logs can include the order number and the progress?
There's a similar problem with MQTT where the spec explicitly disclaims the ordering of messages across topics. Lots of people just ignore this and write software that works perfectly fine in the real world where messages generally get transported in order anyway. But it's still technically incorrect and strikes me as a breeding ground for Heisenbugs.