NNG: Next-Generation Brokerless Messaging
- NNG is a brokerless messaging library that modernizes the ZeroMQ/NanoMsg design with asynchronous I/O and removal of legacy constraints.
- It emphasizes scalability, portability, and maintainability, making it suitable for low-latency, high-throughput, event-driven applications.
- Benchmark studies reveal that while NNG remains competitive in TCP and IPC settings, it exhibits higher latency variance and resource usage in certain scenarios.
NanoMsg-Next-Generation (NNG) is a brokerless messaging library presented as the successor to NanoMsg and a modern reworking of the ZeroMQ/NanoMsg design line. In the performance study "Performance Evaluation of Brokerless Messaging Libraries," NNG is described as a library that builds upon the design principles of ZeroMQ and NanoMsg, aims at scalability, portability, and robustness, removes legacy constraints from POSIX socket interfaces, eliminates NanoMsg’s complex, error-prone state machine architecture, relaxes the file-descriptor-driven implementation that contributed to NanoMsg’s poor scalability, and performs all I/O asynchronously. Within that study, NNG is situated as the newest redesign in this lineage, under active development at the time of measurement, and benchmarked against ZeroMQ and NanoMsg as a representative brokerless candidate for modern low-latency and high-throughput communication (Corte et al., 11 Aug 2025).
1. Design lineage and defining characteristics
NNG belongs to the ZeroMQ/NanoMsg family of brokerless messaging systems. The paper characterizes it not as an unrelated implementation, but as a successor to NanoMsg that preserves the design line while reworking major architectural choices. The stated design goals are scalability, portability, and robustness, and the implementation is framed as a response to limitations in earlier libraries rather than a departure from brokerless messaging as such (Corte et al., 11 Aug 2025).
Several technical attributes are central to that characterization. NNG removes legacy constraints from POSIX socket interfaces, eliminates NanoMsg’s complex, error-prone state machine architecture, and relaxes the file-descriptor-driven implementation that contributed to NanoMsg’s poor scalability. It also performs all I/O asynchronously, which the authors state makes it easier to integrate with non-blocking and event-driven applications. The library is released under the MIT license and provides a C core API.
A recurring implication in the study is that NNG’s significance is partly architectural and partly practical. Architecturally, it is the modern successor in the lineage. Practically, it was the only candidate shown as actively developed at the time of measurement. This suggests that, in the authors’ framing, NNG is not evaluated solely as a throughput or latency target, but also as a maintainable contemporary option within brokerless messaging.
2. Role in the comparative study
The study uses a two-stage selection logic: a qualitative screening followed by quantitative benchmarking. NNG was included because it matched the goal of evaluating brokerless libraries that are lightweight and direct, avoid broker overhead, support PUB/SUB and other brokerless patterns, are relevant to modern applications needing low latency and high throughput, and are practically maintainable. The final set—ZeroMQ, NanoMsg, and NNG—was chosen because the libraries shared a simple, efficient API, had strong enough community/support signals, and represented the main evolutionary line in brokerless messaging (Corte et al., 11 Aug 2025).
Within that logic, NNG had a distinct role. The authors identify it as the newest redesign in the lineage and note that, unlike NanoMsg, it is under active development. They also state that, to the best of their knowledge, no prior study had included NNG as a candidate. Its inclusion therefore addressed a literature gap rather than merely extending an already standard benchmark panel.
This positioning matters for interpreting the results. NNG is treated neither as a niche alternative nor as a baseline inherited from earlier literature. Instead, it functions as the modernized endpoint of the ZeroMQ/NanoMsg line, making the comparison simultaneously architectural, practical, and historical.
3. Benchmarking context and methodological controls
The experimental campaign evaluates NNG alongside ZeroMQ and NanoMsg under a controlled, open-source benchmarking framework. The communication pattern is PUB/SUB only. Three transports are used: In-Process, Inter-Process, and TCP, with TCP restricted to loopback on the same host. Publisher and subscribers remain on the same machine for all runs; for TCP, this isolates the overhead of the kernel TCP/IP stack while avoiding network-card, cable, or switch variability. The NNG version used is libnng v1.9.0 (Corte et al., 11 Aug 2025).
The baseline parameters are explicit. The main experiments send 5000 messages with a publisher start delay of 1000 ms. When varying message size, the number of subscribers is fixed to 1. When studying scalability, subscribers vary over 1, 2, 4, and 8. Message sizes vary from 1 KB to 512 KB in powers of two, and are fixed at 32 KB for subscriber-scaling experiments. The publishing interval is 1000 µs for latency measurements and 0 µs for throughput and CPU measurements. The paper explains that 0 µs is used for throughput and CPU to measure maximum-pressure behavior, whereas 1000 µs is used for latency to reduce queueing/interference and better isolate the library’s efficiency.
The fairness controls are similarly specified. Publisher and subscriber threads are pinned to isolated cores. Each configuration is repeated with . For multi-subscriber scenarios, the suite first averages across subscribers within a run and then across runs. CPU and memory are sampled using psutil. Memory is measured as USS (Unique Set Size), and CPU/memory values are aggregated across all processes/threads at each sample time.
The reported metrics are latency, throughput, CPU usage, jitter, memory usage, and latency percentiles. The jitter definition is given explicitly as
where are one-way transmission latencies and is the number of successfully received messages.
4. Performance in In-Process communication
For In-Process communication, latency increases with payload size for all libraries, with measured latencies ranging from under 10 µs to over 100 µs. NNG performs well on small payloads, but at 128 KB it shows a latency peak, after which performance degrades. The authors summarize the regime by stating that NanoMsg has the lowest latency with small payloads, while ZeroMQ has the lowest latency once payloads become larger; NNG is not the best in this setting (Corte et al., 11 Aug 2025).
Throughput rises with payload size and peaks at 512 KB, with peak throughput across libraries in the 3–5 GB/s range. NNG reaches approximately 3.3 GB/s, below ZeroMQ’s about 4.8 GB/s and NanoMsg’s around 3.8 GB/s. The paper states directly that, in this In-Process setting, NNG has lower throughput, higher latency, and higher CPU usage than the other two libraries. CPU consumption rises with payload size, and NNG is generally less efficient than ZeroMQ and NanoMsg.
Subscriber scaling accentuates this pattern. With message size fixed at 32 KB and subscribers increasing from 1 to 8, latency grows, especially for NNG. The study describes NNG as competitive for one subscriber, but not scaling as well as the others. Throughput decreases as subscribers increase, and NNG deteriorates faster. CPU usage also grows with subscriber count, and NNG reaches cumulative CPU peaks above 100% together with ZeroMQ. The section’s summary observation is that ZeroMQ scales best in terms of throughput, whereas NanoMsg scales best in terms of CPU usage; NNG is therefore the weakest scaler of the three in this transport.
5. Performance in Inter-Process and TCP communication
For Inter-Process communication, latency ranges from under 20 µs at 1 KB to over 400 µs at 512 KB, which the paper notes is about 2.5×–4× the In-Process latency. NanoMsg has the best latency up to 128 KB, after which ZeroMQ is better; NNG is not the latency leader. Throughput peaks in the 1–3 GB/s range. Here NNG shows higher throughput than NanoMsg for the two largest message sizes, although ZeroMQ achieves the highest overall value, around 2.9 GB/s. CPU utilization for IPC can be up to 1.6× higher than In-Process. NanoMsg has the lowest CPU usage for all message sizes, but NNG becomes more CPU-efficient than ZeroMQ for larger payloads: ZeroMQ uses less CPU than NNG up to 32 KB, and beyond that NNG becomes better on this metric. In subscriber-scaling experiments with 32 KB messages, latency growth is more evident for ZeroMQ and NNG than for NanoMsg, throughput declines more sharply for NNG as subscriber count rises, and CPU efficiency is non-linear, with NanoMsg best at 1 and 4 subscribers and ZeroMQ best at 2 and 8. The paper summarizes IPC by stating that NanoMsg scales best for average latency, whereas ZeroMQ scales best for throughput, and that ZeroMQ and NanoMsg, depending on the number of subscribers, are the most CPU efficient libraries; NNG again tends to be the middle or weaker performer (Corte et al., 11 Aug 2025).
For TCP communication on loopback, latency is comparable to IPC, suggesting relatively low loopback TCP overhead. This is the transport in which NNG is most competitive in latency. NanoMsg is best only up to 8 KB, then exhibits what the paper calls strange behavior up to 64 KB, possibly due to an internal limitation, while NNG and ZeroMQ achieve the lowest latency in the middle region and ZeroMQ becomes best for large message sizes greater than 128 KB. Throughput results show ZeroMQ reaching the highest peak, around 2.9 GB/s. NanoMsg peaks around 1.5 GB/s at 128 KB and then declines. NNG throughput monotonically increases, surpasses NanoMsg for large payloads, and peaks at about 2 GB/s. CPU usage shows NanoMsg usually as the most efficient, except at 32 KB where ZeroMQ is slightly better; NNG follows, with ZeroMQ more efficient below 32 KB and NNG more efficient above 32 KB. In subscriber-scaling experiments with 32 KB payloads, ZeroMQ and NNG scale best for latency, NanoMsg retains a latency peak, ZeroMQ stays highest in throughput in most cases except at 8 subscribers where NanoMsg beats both ZeroMQ and NNG, and CPU efficiency depends on subscriber count, with ZeroMQ best at 1, 4, and 8 subscribers and NanoMsg best at 2. The study’s summary for TCP is that, as subscriber count grows, ZeroMQ and NNG scale best for latency, NanoMsg for throughput, and the most CPU-efficient library is, depending on the scenario, either ZeroMQ or NanoMsg.
Taken together, these transport-specific results place NNG in a mixed position. It is generally not the top performer, but it is more competitive in TCP latency, in large-message TCP throughput relative to NanoMsg, and in IPC CPU efficiency at larger payloads.
6. Variability, resource usage, and identified limitations
The paper reports several secondary metrics that sharpen the interpretation of NNG’s behavior. In an IPC latency-distribution experiment with 32 KB, 1000 µs, and 1 subscriber, the authors compare minimum, average, p90, p99, and maximum latency. NNG has the widest latency distribution and the worst maximum latency. NanoMsg is best on average and at the lower percentiles, while ZeroMQ has the narrowest distribution and best worst-case latency. On this evidence, NNG appears more variable and less predictable than the other two libraries (Corte et al., 11 Aug 2025).
Jitter results reinforce that conclusion. In IPC, with a 1000 µs publishing interval, NanoMsg and ZeroMQ keep jitter around 1 µs, whereas NNG has higher jitter for all message sizes. Its average remains below 10 µs except for a spike at the largest payload. The paper identifies this as one of the clearest weak points for NNG.
Memory usage is low overall for all libraries, usually under 0.01%. Within IPC, NanoMsg is the most memory-efficient, ZeroMQ follows, and NNG uses the most memory of the three, although still at very low absolute levels. NNG is therefore not memory-heavy in absolute terms, but it is the least efficient of the three in this metric.
The paper’s caveats for NNG are explicit. These include poorer scaling than the others in multiple scenarios, especially in In-Process and IPC subscriber scaling; higher latency variance; higher jitter; and not being the most efficient on CPU or memory. The broader performance picture is therefore mixed rather than uniformly favorable. At the same time, the authors emphasize that NNG is typically within the same order of magnitude as the others, which makes it practically usable. A plausible implication is that architectural modernization and active maintenance do not automatically imply benchmark leadership across all transport modes and load regimes.
7. Practical positioning and broader significance
The study suggests that NNG is a reasonable choice when active maintenance, a modernized API and implementation, asynchronous I/O, and acceptable performance close to competitors are important considerations. It is portrayed as particularly suitable for brokerless systems needing a modern, actively maintained library, for event-driven or non-blocking applications, and for use cases where performance matters but not at the level of requiring the top result in every metric. The paper identifies TCP or IPC with larger payloads as scenarios in which NNG’s competitive behavior can make it a reasonable middle-ground choice (Corte et al., 11 Aug 2025).
The same results also delineate where other libraries are preferable under stricter optimization criteria. If the primary goal is highest throughput, ZeroMQ is usually best. If the goal is best CPU efficiency, NanoMsg is usually best. For lowest latency with small payloads, NanoMsg often wins. For lowest worst-case latency, ZeroMQ is often best. NNG is therefore not presented as a universal optimum.
An important corrective to a common simplifying narrative is embedded in the paper’s concluding assessment: NNG is the modern successor in the ZeroMQ/NanoMsg family and is architecturally improved and actively maintained, but it is usually not the top performer in the benchmark. This suggests that its principal significance lies in the combination of modern asynchronous design, practical maintainability, and performance that is often competitive, rather than in systematic dominance on latency, throughput, CPU efficiency, or memory usage alone.