12 ms·
ØMQ – The Guide (2011)
- the__alchemist 6y agoI recommend changing the landing page to include a clear description of what this is.
- jgable 6y agoThis is the guide, which you would normally visit from the homepage. The homepage gives a very clear description of what it is.
- detaro 6y agoThe project landing page is very clear an clearly linked: https://zeromq.org/ https://zeromq.org/
- anaganisk 6y agoHow is it not clear its a guide for ZeroMq?
- fiatjaf 6y agoI have a feeling that ØMQ is a very good thing, but all these years I have never managed to understand what it is and what problem does it solve.
- stutonk 6y agoI believe the 'problem' that it solves is universal network transparency between pieces of anything. It's a library that can be used from basically any language that has a C FFI on any system with a C compiler to do IPC with anything else supporting same using a uniform and relatively simple API.
- justinsaccount 6y agoYou know how people often bill sqlite as a replacement for (postgresql|mysql|oracle) but it is really best thought as a replacement for fopen()? zeromq is the same way. It's not a replacement for something like kafka or rabbitmq, it's a replacement for socket()
- fnordsensei 6y agoFrom the site, ”ZeroMQ (also spelled ØMQ, 0MQ or ZMQ) is a high-performance asynchronous messaging library, aimed at use in distributed or concurrent applications. It provides a message queue, but unlike message-oriented middleware, a ZeroMQ system can run without a dedicated message broker.” I read it as a low-level abstraction for when you want to build a custom messaging infrastructure.
- omginternets 6y agoThis tells your “what” not “why”. I prefer the “replacement for socket” pitch, personally.
- deleted 6y ago[deleted]
- formerly_proven 6y agozmq is "a better socket()", but unlike sockets it's pretty hard to figure out what's going on. E.g. most (all?) socket types don't need the other side to be immediately available, it'll buffer a couple thousand or so messages and start blocking if it doesn't appear. From the app's point of view, everything seems fine until the queues are full (which you can't introspect, btw.) when suddenly everything starts blocking. It does bring some nice things to the table, but using it has always felt at least a little bit "weird" to me. The docs are a little weird, and there are random caveats sprinkled around the library (e.g. you don't need to synchronize the startup of dependent services like described above, unless you were using certain transports in older versions and so on). It used to be marketed somewhat towards developing multi-threaded applications, but it was always rather unclear what exactly the advantage of using, for example, the comparatively slow PUSH/PULL socket (ipc:// are pipes) over a MPMC (or as needed) queue ought to be. It is also marketed towards resilient distributed apps, but, perhaps I was holding it wrong, but it'd always behave much like TCP and stuff like REQ/REP would pretty much always block forever if the peer goes away, while stuff like PUSH/PULL isn't reliable when peers go away, so for a distributed app these can't really be used anyway. So for this use case it always seemed rather too low-level and its guarantees too weak / non-applicable.
- eeZah7Ux 6y ago> It is also marketed towards resilient distributed apps, but, perhaps I was holding it wrong, but it'd always behave much like TCP and stuff like REQ/REP would pretty much always block forever if the peer goes away, while stuff like PUSH/PULL isn't reliable when peers go away, I had exactly the same (disappointing) experience.
- justinsaccount 6y ago> REQ/REP would pretty much always block forever if the peer goes away unless you tell it to do otherwise, that's exactly what it will do. The guide covers this: 4. Reliable Request-Reply Patterns
- foobiekr 6y agothank you. this is exactly how I feel about it. zmq appears to be a layer that tries to hide some of the most important details that the socket layer exposes. socket programming and the state machines that tend to go along with it are some of the least difficult parts of systems programming to do well, it is well documented, well understood and there are ample tools to help measure ground truth. it was always weird to me that zmq had such a strong reputation; it basically hides what would otherwise be a few hundred lines of library code (including a framer).
- spicybright 6y agoYeah, I've never used it myself, but I think the main value is an abstraction over programs talking to each other. Like you can tell it to use sockets if the machines are remote, or different inter-process communication if they're running on the same machine, etc. It also has some common patterns like pub/sub and others.
- parhamn 6y agoSoftware is a huge domain. It’s just one of those things you’ll need when you need. Some places you might use it: real-time financial data streams, multi-agent worker task/management, distributed database syncing. It’s basically a networking lib that makes common patterns easier. E.g send this message to everyone, list connected peers, handle these messages this way if the peer can’t take the message, and so on. They support doing this in a bunch of languages over a bunch of communication protocols. Now all the Async/coroutine/ipc verbiage is mostly just because synchronization is a communication problem which is what zeroMQ happens to solve as well.
- mhdhn 6y agoAs OP points out, listing all connected peers is not supported.
- arminiusreturns 6y agoFor a long time I've wondered how applicable it could be as a potential replacement for dbus.
- eeZah7Ux 6y agoØMQ promises being "socket on steroids" but I used it quite a bit and it's not so beneficial. It hides the scalability problem of having many TCP sockets without solving it (e.g. pub-sub over TCP). It does not solve the ahead-of-line blocking issue. It requires reading a lot of documentation and doing experiments to find out what is the right combination of " fan-out, pub-sub, task distribution, and request-reply" that you have to use. e.g. https://zguide.zeromq.org/docs/chapter4/ https://zguide.zeromq.org/docs/chapter4/ https://zguide.zeromq.org/docs/chapter5/ https://zguide.zeromq.org/docs/chapter5/ https://zguide.zeromq.org/docs/chapter3/ https://zguide.zeromq.org/docs/chapter3/ Plus a lot of "magic" happening in the library involves queues that you have no control over. You get applications that hang and fill buffers instead of failing early. I suspect this is the reason why it never became a new layer in the TCP/IP stack
- omginternets 6y agoThe biggest limitation I found was the lack of reliable delivery semantics.
- umvi 6y agoYou can think of ZeroMQ as legos for building message queue-based messaging systems. ZeroMQ gives you different pieces - pushers, pullers, publishers, subscribers, routers, etc. and it's up to you to then hook them up in different ways to create the system you want. The guide gives you some different ideas of how to hook up the different pieces for common use cases, but there's nothing stopping you from building a custom one. ZeroMQ is not an out-of-the-box MQ solution. It takes some work to understand and build a functional MQ solution with ZeroMQ. If you want something that works out of the box I recommend RabbitMQ.
- avinassh 6y ago> You can think of ZeroMQ as legos for building message queue-based messaging systems. Are there are any, preferably open source, message queue based messaging systems using ZeroMQ?
- secondcoming 6y agoFor internal machine-to-machine communications you can replace your full blown HTTP server + JSON inefficencies with a simple ZMQ request/reply + binary serialisation format. It also allows one machine to broadcast a message to a 'topic' that other machines listen for. Many other things. It's not perfect, but it Just Works.
- easytiger 6y agoIt's an alternative to writing your own complex networking code for any kind of distributed communications. A lot of people these days might use something like flink or spark to build a pipeline whereas I'd prefer to write a number of small servers with various fan out or fan in operations, broadcast style operations, request/reply semantics etc where appropriate Makes way more sense and much simpler to my mind and allows much better control over performance characteristics.
- marktangotango 6y agoMongrel 2 used zeromq to proxy to workers. I don't know how popular that ever was in practice.
- m463 6y agowhat I'm wondering is: we have https://xkcd.com/927/ https://xkcd.com/927/ with sockets in frame 1, and zeromq in frame 3 Are there some clear wins of zeromq over sockets/udp/tcp?
- eeZah7Ux 6y agoIt's in no way a competing standard.
- nuxi 6y agoZMQ is not a replacement for sockets, it's a library that uses sockets (and other transport mechanisms) underneath. For more details: https://zguide.zeromq.org/docs/preface/#ZeroMQ-in-a-Hundred-Words https://zguide.zeromq.org/docs/preface/#ZeroMQ-in-a-Hundred-...
- kjeetgill 6y agoWhen people say that they mean it's a replacement for the use of sockets in your program, not that it replaces sockets ... Across the technological landscape? Within the tech stack? Hmm.
- nuxi 6y agoIf your program is the only user of sockets then okay, "use of sockets in your program" might be a valid assumption. But if you're interfacing with external components using sockets/whatever, using ZMQ will not solve anything. That's why I don't see it as a replacement/competing standard...
- jonex 6y agoI've used ZeroMQ lightly as a socket-replacement and for simple IPC and I'd say the key thing it solved was connection establishment. It turns out that opening a two way connection between two apps on the same network without a clear starting order can go wrong in many ways and become quite messy to get right. With ZeroMQ it more or less just magically worked and it allowed me to focus on the actual problem I was working on. The wide range of language support was also nice. It allowed me to test the interface using a Python notebook which came in handy for debugging.
- random3 6y ago0mq is great; however, the 0mq Guide is the golden standard for technical documentation and one of the best tech writings there are.
- m101010 6y ago100% agree. I think what stood out to me the most was that it did explain a lot of the decision making. I feel like often other docs don't explain the decisions that did go into their software at all
- random3 6y agoThis is also what sets good code comments and code level API documentation apart - explaining the reasoning and intention for both implementation and for intended use. Essentially the why and how, not that what...
- lifthrasiir 6y agoMy only complaint with the guide so far was that it was historically presented as a single huge DokuWiki page with ambiguous heading structures (probably because the page was made of several other pages, each having top-level headings by its own). The current version looks much cleaner!
- endgame 6y agoEven more impressive is that Pieter put the same attention into documenting the 0mq community's social architecture, as well: https://hintjens.gitbooks.io/social-architecture/content/ https://hintjens.gitbooks.io/social-architecture/content/
- dang 6y agoIf curious see also 2015 https://news.ycombinator.com/item?id=9633921 https://news.ycombinator.com/item?id=9633921 2011 https://news.ycombinator.com/item?id=21226822 https://news.ycombinator.com/item?id=21226822
- theamk 6y agoI looked at zeromq, but it seemed like it had very bad debug-ability and visibility into internal operations. Their FAQ [0] says things like: > How do I determine how many messages are in queue? > This isn't possible. [...] rather than provide incorrect information the library avoids providing any view into this data. > How can I retrieve a list of all connected peers? > This is not supported. Those kinds of decisions are very scary for production environment. We've had to debug network connectivity problems before, and it just possible what all the interfaces Linux kernel provides. I cannot imagine doing it with library which hides stuff from you on purpose. [0] http://wiki.zeromq.org/area:faq http://wiki.zeromq.org/area:faq
- molf 6y agoI guess this is fair criticism given the FAQ, but many features have been added over time. Setting up a monitor socket allows you to observe pretty much any event you could care about, like peer connect/disconnect/errors, etc. There is also a draft feature to access the number of queued incoming/outgoing messages (see https://github.com/zeromq/libzmq/blob/master/doc/zmq_socket_monitor_versioned.txt https://github.com/zeromq/libzmq/blob/master/doc/zmq_socket_... for details).
- justinsaccount 6y agothe [...] that you removed is > At any given time a message may be in the ZeroMQ sender queue, the sender's kernel buffer, on the wire, in the receiver's kernel buffer or in the receiver's ZeroMQ receiver queue. Furthermore, a ZeroMQ socket can bind and/or connect to many peers. Each peer may have different performance characteristics and therefore a different queue depth. Any "queue depth" number is almost certainly wrong The library doesn't hide stuff from you, it just refuses to show you information that might as well be a random number. If you want to know how many peers are connected you use heartbeats instead of just blindly trusting that 1 tcp socket = 1 available peer.
- theamk 6y agoThe reasonings assumes I don't know what's going on. This approach is precisely why I never tried ZMQ. How do you know my circumstances? Maybe this system has tuned rmem_max/wmem_max so I don't care about kernel buffers? Maybe my programs have problems with multi-gigabyte queues? Why are you assuming stuff for me? The right answer of course is you don't expose a single "queue size" value, but you don't hide it either. Instead, expose something like "list of sockets: for each, here is an fd and a size of userspace queue". I'll then query the kernel myself to get sender's and receiver's kernel buffer size and so on. Life is hard enough without libraries hiding stuff from you!
- nurgasemetey 6y agoIn 2015, in one project one "clever" co-worker decided to use "zeromq" in project where is the guarantee of delivery was must. I think that because he wanted to attach this technology as fancy stuff in his cv. Later he left and we had to rewrite message sending and converted to basic http.
- nurettin 6y ago> we had to rewrite message sending and converted to basic http. What are the delivery guarantees for basic http?
- hblanks 6y ago(Yes to the earlier post - had a similar experience with an early metrics system for Twilio in 2012-2013) The 1st issue is that ZMQ implementations generally have an IO thread handling all socket IO. REQ/REP patterns tend to work out just fine, because the client is going to wait for a reply from the server. But things like PUSH/PULL become...harder to follow. You can push things in the client, but how do you know when they've flushed out of the IO thread and made it to the server? Those sorts of things matter when shutting down a process, running integration tests, etc. In contrast, with an HTTP request, you're basically always doing REQ/REP, and so you know when the data has been pushed. The 2nd issue is that ZMQ implementations tend to be harder to observe / operate than a more common path like HTTP requests. (HTTP requests can go through a load balancer, have standard response codes, use headers for authorization, etc.) For these reasons, I've tended to avoid ZMQ ever after -- it seems like often, you're best off either using REST or GRPC if by HTTP, or raw TCP if it's purely a data push kind of operation (e.g. forwarding structured logs, with framing, to a remote TLS endpoint).
- easytiger 6y ago> But things like PUSH/PULL become...harder to follow. Surely that implies incorrect use of the socket types vis a vis their design characteristics?
- ReactiveJelly 6y ago
- pcglue 6y agoAnyone know how nanomsg (https://nanomsg.org https://nanomsg.org) or nng (https://github.com/nanomsg/nng https://github.com/nanomsg/nng) compares? Interesting that nanomsg tries to better zeromq (https://nanomsg.org/documentation-zeromq.html https://nanomsg.org/documentation-zeromq.html) and then nng tries to better nanomsg (https://nng.nanomsg.org/RATIONALE.html https://nng.nanomsg.org/RATIONALE.html) edit: just noticed nng and nanomsg share the same domain, so probably the same people behind them.
- smitty1110 6y agoIf I remember correctly, they’re written by the original zeromq author. He has a blog post about how he realized that C++ was not ideal for the architecture he was using, and decided to make a clean break. Edit: Found it. https://250bpm.com/blog:4/ https://250bpm.com/blog:4/
- ReactiveJelly 6y agoHis arguments are valid [1] but I still don't understand why that means dropping C++ entirely. Sure, C++ isn't a perfect superset of C, but you could mostly write C-style code in C++, right? I've seen this sentiment before from C enthusiasts. Maybe it makes sense on the Linux kernel, where you don't want to keep telling contributors not to use the most common C++ features. But I don't think it makes sense on very small projects, and maybe I just draw the dividing line for where it stops working at a different size of project than he did. [1] Exceptions suck and constructors suck and C++ would be better if it was just Rust with no borrow-checker.
- DominikD 6y agoHe changed his mind over time. ZeroMQ is still maintained and nanomsg is pretty much dormant.
- lllr_finger 6y agoLook up "nanomsg is not dead" and nanomsg's replacement nng for even further confusion. My takeaway is that even though these newer libs seem to be simpler and avoid some issues, they've just never caught on.
- punnerud 6y agoØ - The 28. Letter in the Norwegian alphabet, pronounced as the beginning of the sound ‘uuuuh’ (like when someone is making a sound when thinking). It’s a join between O and E, and was at first written as Ө. The same sound in Swedish is Ö
- francislavoie 6y agoIn linguistics: https://en.wikipedia.org/wiki/Close-mid_front_rounded_vowel https://en.wikipedia.org/wiki/Close-mid_front_rounded_vowel
- vlmutolo 6y ago> The Ø in ZeroMQ is all about tradeoffs. On the one hand this strange name lowers ZeroMQ’s visibility on Google and Twitter. On the other hand it annoys the heck out of some Danish folk who write us things like “ØMG røtfl”, and “Ø is not a funny looking zero!” and “Rødgrød med fløde!”, which is apparently an insult that means “may your neighbours be the direct descendants of Grendel!” Seems like a fair trade. https://zguide.zeromq.org/docs/preface/#The-Zen-of-Zero https://zguide.zeromq.org/docs/preface/#The-Zen-of-Zero
- nift 6y agoFunny - people say "Rødgrød med fløde" because very few non-danes can pronounce it correctly, making it very "funny". It's simply a dish. I don't know what is more funny ("haha") - people not being able to pronounce it or how stupid hard Danish is to speak.
- chromatin 6y agoOr, you know, U+2205, the mathematical "empty set" notation. https://en.wikipedia.org/wiki/Null_sign https://en.wikipedia.org/wiki/Null_sign
- punnerud 6y ago∅ is different, but maybe hard to distinguish if you are not used to Ø/ø(∅ see)
- harel 6y agoI am actually using it in production as an easy mechanism to add non critical rpc calls between services. The only thing I can say about it is that zeromq hasn't given me a reason to look for a replacement. Yet.
- may4m 6y agonice, we're also using it for rpc calls using protobuffs.
- DoingIsLearning 6y agoDid exactly the same in a previous job but used flatbuffers for serialization instead. I wasn't a part of the initial decision making but was pretty happy with how easy it was to work with both zmq and flatbuffers.
- harel 6y agoThe fact that it just works, and very easy to add endpoints, made it a no-brainer. I might not leave it alone with my kids but it works great as an RPC pipe.
- lllr_finger 6y agoI believe that zeromsg does not support true zero-copy messaging which might be a reason to look at nanomsg or nng if you need every last ounce of performance.
- tjkrusinski 6y agoLove zeromq. Used it in production for years and it never posed any issues. Well documented, reliable and has a clear purpose. V good.
- sgtnoodle 6y agoZeroMQ's variety of socket semantics is great, and it does a good job abstracting away the messy details of TCP. You can build rather complicated systems on top of it much easier and faster than you could using raw sockets. The implementation itself has some rough spots, such as the multi threading. I really like the elegance of nanomsg, but it never really got the same polish that ZeroMQ did. I wouldn't expect the same raw throughput as a hand-tuned TCP based protocol, but it's generally more than fast enough for most use cases. I believe the original developer passed away a few years ago?
- nathancahill 6y agoPieter Hintjens @hintjens passed away in 2016.
- deleted 6y ago[deleted]
- endgame 6y agoHe wrote very frankly about his impending death, too: http://hintjens.com/blog:123 http://hintjens.com/blog:123 EDIT: This is the post I was looking for: http://hintjens.com/blog:115 http://hintjens.com/blog:115
- mbreese 6y agoAnd discussed here: https://news.ycombinator.com/item?id=11547212 https://news.ycombinator.com/item?id=11547212
- RabbitmqGuy 6y ago> I believe the original developer passed away a few years ago? Yeah, via euthanasia. https://twitter.com/hintjens/status/783254242052206592?s=21 https://twitter.com/hintjens/status/783254242052206592?s=21
- antman 6y agoAnd he was passing away due to cancer came to HN for one of his last discussions. He also mentioned he was broke and a PayPal account for donations for his family was mentioned. nkurz on Apr 18, 2016 [–] Thanks. Does anything come to mind that you should have done more of (or instead)? PieterH on Apr 18, 2016 [–] Probably more frequent checkups, to be honest. Though it's probably moot. " https://news.ycombinator.com/item?id=11520888 https://news.ycombinator.com/item?id=11520888
- calpaterson 6y agoI have to say that I have never really had a positive impression of zeromq. I feel like it is particularly unsuccessful and that seems to be for some pretty good reasons. Zeromq is a bag of tools and it's not really clear to me how a novice would put them together safely. This is important for a message system because everyone has to start somewhere and it really shouldn't be "step 1: build your broker with our subroutines". Is that broker really going to be any good? Secondly, for many years zeromq was a kind of monty python style 'judean people's front vs people's front of judea' community. They split from the AMQP standardisation process I agree had clearly gone wildly wrong and then...split and then...split again. Right as far as I know people doing messaging are using a) RabbitMQ if they're deploying it themselves b) AWS of GCP's thing or c) some proprietary thing which has no name recognition among the public (who here has heard of AMPS?) d) Kafka. No one is using zeromq as far as I know! Look forward to anyone sharing their positive experiences using zeromq on big projects eg in banks.
- rcxdude 6y agoI agree. The basic interface design seems really neat but it's so easy to run into horrible problems with it. For one it doesn't really deal with errors very well: once you've thrown a message into it there's basically no mechanism to know if something goes wrong with it (and it certainly used to just straight up assert in many, many error cases, which sure made it hard to use the 'reliable central broker' mechanism they advocate in the docs). The implementation is also really brittle: it's basically trivial to cause all kinds of misbehaviour if the other end does not act as expected. The problem is there isn't really many good alternatives that are actually similar. Other 'message queues' are basically big databases, not a library. I feel there's room for something with the same philosophy but better execution.
- filmor 6y agoZeroMQ is used heavily in the backend of Jupyter and allows for a huge variety of non-Python kernels. It's brokerless, which sets it apart from all the other things you listed here.
- JonathonW 6y agoAs someone who's written more than my fair share of messaging code using a bunch of different middleware and frameworks, I've never really understood where ZeroMQ is supposed to fit. It's high-level enough that you have to learn something completely different than plain sockets (and have more stuff to debug when it breaks), while also being low-level enough that it can't provide many of the features I'd expect out of a message-oriented middleware-- no message broker, no anonymous pub-sub, no reliable transport, etc. unless you go and build them yourself (which they provide documentation and patterns for, but they're not things you get for free like you would with other frameworks). "Bag of tools" is about right. Where RabbitMQ/AMQP or MQTT or DDS can, depending on exactly what I want to do, provide me an end-to-end solution where, with a bit of configuration and network management, throw in a message and expect it to go where I want it to, ZeroMQ hands me a pile of pieces with which I can, presumably, build a thing that will do the same thing. That's not something I've ever found that I need-- either one of the premade solutions fills my needs, or I go and write something myself and skip ZeroMQ.
- deleted 6y ago[deleted]
- hnarn 6y agoØ is a vowel and a letter used in the Danish, Norwegian, Faroese, and Southern Sami languages. (Wikipedia) It’s not an unused letter that you can snap up as a cool way to write zero. People will read it, some will recognize it and assume it has meaning, because it has. That’s how letters work. There are zeroes with dashes through them, but if you look closely they almost always take care to keep the dash inside the (non-)circle zero to make the difference clearer. I realize most people in the world won’t care about this, but with Northern European eyes, this looks stupid.
- CivBase 6y agoIncidentally... > The Ø in ZeroMQ is all about tradeoffs. On the one hand this strange name lowers ZeroMQ’s visibility on Google and Twitter. On the other hand it annoys the heck out of some Danish folk who write us things like “ØMG røtfl”, and “Ø is not a funny looking zero!” and “Rødgrød med fløde!”, which is apparently an insult that means “may your neighbours be the direct descendants of Grendel!” Seems like a fair trade. https://zguide.zeromq.org/docs/preface/ https://zguide.zeromq.org/docs/preface/
- mrsirduke 6y agoBecause I'm sure more than one person is wondering, the literal translation of "rødgrød med fløde" is "red porridge with heavy cream", not an insult but a traditional danish dessert. Edit: missed an s in dessert.
- hnarn 6y agoI saw that, and it doesn’t do anything for me personally than paint the authors as petulant. Clearly “some danish folk” are the obvious other here and they themselves can’t be bothered because they don’t read the character. If they want to refer to the mathematical character as mentioned in other comments, why not use that instead of one from an actual alphabet? They’re free to do whatever they want but anyone familiar with the character is also free to see them as being not a little US-centric.
- stanski 6y ago
- Doman 6y agoWe are using 0mq for monitoring of electric vehicles fleet. Millions of messages every day (hundreds of GB), zero problems with bad internet connection (common in moving vehicles). Every sent message is received regardless of connectivity issues. Just a little implementation annoyances here and there but it is serving us well since 2015.
- tsimionescu 6y agoHow does 0mq achieve that? For all I have read and tried to use of it, 0mq explicitly offers no message delivery guarantees, instead relying on your own implementation to achieve them. So, I don't doubt that your system works like you described, but I think you may be overvaluing 0mq's contribution to it.
- neurostimulant 6y agoThe ZeroMQ Guide has a chapter dedicated to reliability stuff: https://zguide.zeromq.org/docs/chapter4/ https://zguide.zeromq.org/docs/chapter4/ Maybe there is no guarantee, but it can handle unreliable connection just fine, at least when I used it a few years ago.
- tsimionescu 6y agoYes, I have read the guide pretty thoroughly. What all those things have in common is that they are your responsibility to implement - all that 0mq does is reconnect the socket, and queue up messages. Anything else that could give you reliability is either TCP's problem or yours. That includes timeouts, retransmit, ACKs, keepalives, heartbeats, rate control, message storage, everything that ensures reliability - with 0mq you get to implement it. Lazy pirate indeed.
- Doman 6y agoWe implemented KISS state machine based on TCP timeouts and server response. Pseudocode: Send msg to server if socket timeout: reinit socket and send again Recv from server if recv.msg != 'ok': send again else remove msg from storage One message has from few to few hundreds Kilobytes. Messages are stored and sent as custom binary data for better compression (better that protobuffs). ZMQ takes complexity of raw tcp sockets away and this is what we needed it for. As much and as little.
- noncoml 6y agoI am sure that the developers behind zmq are(or were) far more intelligent and better programmers than I will ever be, but I have to say that as a user I would never recommend it to anyone for the following reasons: 1. A lot of gotchas and surprising behavior. For example this: > To be more explicit: after calling zmq_send the socket may become readable (and vice versa) without triggering a read event on the file descriptor. 2. The library will assert internally without actually giving you any clues what did you do wrong as a user. I would rather spend some extra time in development by using pure sockets rather than the stress of debugging problems, arising from the above, later.
- cetra3 6y agoI've implemented bindings for ZeroMQ with Tokio in rust (https://github.com/cetra3/tmq https://github.com/cetra3/tmq). I found ZeroMQ great for interop with Python/Java if you just want some simple cross-process broadcast/task management.
- avinassh 6y ago(noob here) I just looked into the ZeroMQ code and the API seems to be sync and blocking. So, how does one provide async bindings for such code?
- cetra3 6y agoZeroMQ does allow you to register file descriptors on an event queue, which if you dig into the code you'll find tmq using mio to accomplish this.