HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
zeromq
libzmq
C++2015–2024
zeromq / libzmq

libzmq

ZeroMQ core engine in C++, implements ZMTP/3.1

Systems & InfrastructureNetworkingCommunication & Social
Explore on GitHubRead Hacker News discussions
17Distinct people
20Mentions
0Explicit recommenders
11.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

ZeroMQ core engine in C++, implements ZMTP/3.1

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year20 dated mentions

Observed mentions: 2015-09-05 19:13:19 UTC to 2024-07-15 05:37:02 UTC.

02462015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC202
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC110
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC312
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC615
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303

What Hacker News says

20 sources
jillesvangurp·Jul 15, 2024
Making the software easier to use from a legal point of view was indeed the reason. They explained why they did this here: https://github.com/zeromq/libzmq/issues/2376 Bottom line is that their licensing with a static linking exception was kind of weird and creating a lot of issues combining zeromq code even with other open source licenses (like Apache 2.0). Interesting to see how they gathered permission to do this from the developer community. License changes like this are usually hard to realize unless you insist on copyright transfers. But in this case they managed to do it without that. So it was a collective decision. Hard to argue with that.
In ZeroMQ: High-Performance Concurrency Framework
imiric·Mar 31, 2024
> It's not defeatist to admit and accept that some things are ultimately out of our control. But that's the thing: deciding how software is built and which features are shipped to users _is_ under our control. The case with xz was exceptionally bad because of the state of the project, but in a well maintained project having these checks and oversight does help with delivering better quality software. I'm not saying that this type of sophisticated attack could've been prevented even if the project was well maintained, but this doesn't mean that there's nothing we can do about it. > And more importantly, that any attempt to increase control over them comes with downsides. That's a subjective opinion. I personally find linters and code reviews essential to software development, and if you think of them as being restrictions or useless bureau
Read the rest
cratic processes that prevent you from contributing to a project then you're entitled to your opinion, but I disagree. The downsides you mention are simply minimum contribution requirements, and not having any at all would ultimately become a burden on everybody, lead to a chaotic SDLC, and to more issues being shipped to users. I don't have any empirical evidence to back this up, so this is also "just" my opinion based on working on projects with well-defined guidelines. I'm sure you would agree with the Optimistic Merging methodology[1]. I'd be curious to know whether this has any tangible benefits as claimed by its proponents. At first glance, a project like https://github.com/zeromq/libzmq doesn't appear to have a more vibrant community than a project of comparable size and popularity like https://github.com/NixOS/nix, while the latter uses the criticized "Pessimistic Merging" methodology. Perhaps I'm looking at the wrong signals, but I'm not able to see a clear advantage of OM, while I can see clear disadvantages of it. libzmq does have contribution guidelines[2], but a code review process is unspecified (even though it mentions having "systematic reviews"), and there are no testing requirements besides patches being required to "pass project self-tests". Who conducts reviews and when, or who works on tests is entirely unclear, though the project seems to have 75% coverage, so someone must be doing this. I'm not sure whether all of this makes contributors happier, but I sure wouldn't like to work on a project where this is unclear. > Without people willing to contribute their time, open source cannot function. Agreed, but I would argue that no project, open source or otherwise, can function without contribution guidelines that maintain certain quality standards. [1]: https://news.ycombinator.com/item?id=39880972 [2]: https://rfc.zeromq.org/spec/42/
In XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."
throwaway9870·Oct 9, 2023
What I mean is literally have an assert with incoming data as the parameter: > assert(data_buf[4] < 8); While your protocol might guarantee that data_buf[4] should always be a value less than 8, you don't use assert() to check it because it aborts the program if the check fails. The proper thing to do is a range check that returns an error for a protocol error (malformed data, etc.). ZeroMQ literally called assert and any bad data coming in over the wire would cause your app to abort. Insane. Here is an example bug report: https://github.com/zeromq/libzmq/issues/186 Keep in mind this was a LONG time ago! So this is not an indictment of the current project!
In ZeroMQ – Relicense from LGPL3 and exceptions to MPL 2.0
diggan·Oct 9, 2023
People contacted were people who made major modifications, not every single contributor. And yeah, if the contributor don't agree to the new license, you can either don't do the license change, or remove the code they wrote as they don't agree to the new license. There is more background here: https://github.com/zeromq/libzmq/issues/2376 Sometimes companies who do "FOSS" make you sign some sort of agreement that they own the code you produce and you won't have any say about re-licensing, so maybe the projects you're thinking about have done that?
In ZeroMQ – Relicense from LGPL3 and exceptions to MPL 2.0
wallstprog·Jul 28, 2023
Unlikely, but they seem to be different things altogether. BlazingMQ appears to be a traditional message queue (think ActiveMQ), with message peristence. ZeroMQ is more of a network middleware (think Tibco Rendezvous), and does not include persistence. BlazingMQ also appears to be more of a "platform" or "service" that an app can use (sort of like Oracle, say) -- ZeroMQ includes libraries that one can use to build an app, service or platform, but none is provided "out of the box". Which makes it harder to get started with ZeroMQ, since by definition every ZeroMQ app is essentially built "from scratch". If you're interested in ZeroMQ, you may want to check out OZ (https://github.com/nyfix/OZ), which is a Rendezvous-like platform that uses the OpenMAMA API (https://github.com/finos/OpenMAMA) and ZeroMQ (https://github.com/zeromq/libzmq) t
Read the rest
ransport to provide a full-featured network middleware implementation. OZ has been used in our shop since 2020 handling approx 50MM high-value messages per day on our global FIX network.
In BlazingMQ: High-performance open source message queuing system
twic·Jul 27, 2022
I think the situation is more subtle than the poster admits. No, ZeroMQ and successors do not tell you about socket state. You can't detect disconnection or reconnection. But then if a TCP connection fails in some way that does not lead to disconnection (packets getting dropped, remote machine powers down), it can't possibly tell you about that either, but you still need to deal with it. So in any case, you need some sort of application-level error detection and recovery; you need heartbeats, and serial numbers in messages, and a protocol for explicitly restarting a connection and performing the initial handshake. And once you have that, explicit connection events from ZeroMQ are much less important. Admittedly, given that this is a TCP transport, reporting reconnections would still be useful, because TCP won't ever drop messages from the
Read the rest
interior of a sequence itself (if it delivers 15, it has delivered 1 - 14 already), so you shouldn't need the serial numbers. And if it's really not possible to detect authentication failures, than that seems rubbish. And it seems that is indeed the case: https://github.com/zeromq/libzmq/issues/3505
In What they don't teach you about sockets
wallstprog·May 21, 2020
For now, I'll just address the one point -- obsolete? NOT! We've been working with ZeroMQ a lot over the past couple of years, and have gotten to know some of the maintainers -- we've been very favorably impressed by their ability and dedication. Pieter Hintjens was the "voice" of ZeroMQ, and with his passing things have gotten a bit quieter, but no less active. (Just take a look at the commit log: https://github.com/zeromq/libzmq/commits/master).
In An introduction to RabbitMQ
defanor·Oct 11, 2019
That section focuses on ease of use, compared to raw TCP, HTTP, and so on, but I'm rather unsure whether it extends (or is any notable) for arbitrary projects (that is, not counting few for which it is suited particularly well), beyond experimental and basic ones. I used ZMQ in production 6+ years ago, and there were hard-to-reproduce bugs somewhere. Not sure if I managed to find all their sources before rewriting, but ZMQ was one of the suspects (with a reported bug that would have explained what I have observed, IIRC), certainly less stable than plain POSIX sockets, and making it harder to localize the issue. There is plenty of open issues in the core library still [0]. It's a rather common problem with dependencies and abstractions, not ZMQ-specific, but it adds quite a bit of complexity; if it isn't necessary (or at least very useful)
Read the rest
, I think it's a good idea to avoid. For the past few years I use pipes and UNIX domain sockets for IPC between successors of those programs, and it works well. Though I keep seeing programmers/software using both TCP and POSIX sockets wrong, making all kinds of wrong assumptions about their operation (and then there are libraries intended to simplify it, but complete with bugs too!); I think that's where HTTP abuse helps by providing a basic API (via relatively polished HTTP libraries) for basic use cases. Probably ZMQ (and other MQs) are indeed useful for that, and for some complex scenarios that one would have to implement from scratch otherwise, but I don't think it's fair to present/recommend as strictly better sockets. It also talks about distributed P2P, which I find exciting in general, but the example it provides further in the guide only demonstrates automated reconnects and message queuing (which is potentially useful, but not a major challenge). [0] https://github.com/zeromq/libzmq/issues
In Fixing the World (2011)

Showing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.