ØMQ: The Theoretical Foundation
Unlike other (centralised) messaging systems which are based on the well-understood theoretical foundation, there are almost no resources regarding distributed messaging in general and ØMQ in particular that an interested reader can be pointed to.
The goal of this paper is to explain the elementary concepts of ØMQ architecture, how they fit together and what's the rationale for them to be designed the way there are.
Design of PUB/SUB subsystem in ØMQ
PUB/SUB (publish/subscribe) is a messaging pattern used to distribute data to arbitrary number of subscribers. In context of ØMQ the focus with PUB/SUB is on scalability, ie. on ability to add more subscribers to the system without overloading it.
Internal Architecture of libzmq
It seems like the number of people who are willing to peek at ØMQ internals is growing lately and while the codebase is heavily commented what's missing is an overview of the architecture, a document that would allow newcomers to dive into the code without much trouble.
ØMQ Termination Sequence
How to terminate 0MQ cleanly. The emphasis is on C++ but contains internal details of how ØMQ manages its termination that is useful for anyone that may be suffering from instability during program termination of ØMQ
An video by Oliver Smith
Short introductory video to ØMQ.
ZeroMQ an introduction
An article by Nicholas Piël.
I had some trouble understanding ZeroMQ at first and really had to reset my brain. First of all, it is not a complete messaging system such as RabbitMQ or ActiveMQ. I know the guys of Linden Research compared them, but it is apples and oranges. A full flexed messaging system gives you an out of the box experience. Unwrap it, configure it, start it up and you’re good to go once you have figured out all its complexities.
ZeroMQ is not such a system at all; it is a simple messaging library to be used programmatically. It basically gives you a pimped socket interface allowing you to quickly build your own messaging system.
In this article Pieter Hintjens and Martin Sustrik examine the difficulties of building concurrent (multithreaded) applications and what this means for enterprise computing. The authors argue that a lack of good tools for software designers means that neither chip vendors not large businesses will be able to fully benefit from more than 16 cores per CPU, let alone 64 or more. They then examine an ideal solution, and explain how the ØMQ framework for concurrent software design is becoming this ideal solution. Finally they explain ØMQ's origins, and the team behind it.
The Long and Winding Road Behind
The following is a point-by-point account of what we have achieved so far during the development of the ØMQ project. The most interesting aspect is how the project gradually evolved from "just another messaging solution" to "layer of the Internet stack".
ØMQ: A new approach to messaging
Published by Linux Weekly News
BSD sockets have been used in thousands of applications over the years, but they suffer from some limitations. The low-level nature of the socket API leads developers to reimplementing the same functionality on top of sockets over and over again. Alternatives exist in the form of various "I/O frameworks" and "enterprise messaging systems" but both of these approaches have their own set of drawbacks. The former are generally bound to a certain programming languages or paradigms, while the latter tend to be bloated, proprietary solutions with resident daemons that hog system resources.
ØMQ ("Zero-Em-Queue") is a messaging system that tackles these issues by taking a different approach. Instead of inventing new APIs and complex wire protocols, ØMQ extends the socket API, eliminating the learning curve and allowing a network programmer to master it in a couple of hours. The wire protocols are simplistic, even trivial. Performance matches and often exceeds that of raw sockets
Connect Community Webinar
There have been a webinar on messaging in general and ØMQ in particular at Connect Community on February 18th, 2010. Recording of the webinar is available at here. The slides from the presentation are availabe here. The speakers were Pieter Hintjens, iMatix CEO, who spoke about messaging in general, OpenAMQ, ØMQ and RestMS, Martin Sustrik, architect of ØMQ who spoke about the goals and concepts behind ØMQ project and Brett Cameron from Hewlett-Packard who spoke about porting OpenAMQ and ØMQ to OpenVMS.
This article describes how to perform network traffic monitoring based on business criteria. It's an update of the older whitepaper, modified to match ØMQ/2.0 API.
Bachelor work at FastMQ Inc.
Student from Slovak Technical University Patrik Csókás spent few weeks in our company to finish his Bachelor work with subject "Optimising network hardware in business messaging environments".
The term "jitter" is used to express how much do individual latencies tend to differ from the mean. To say that there's jitter in your application is not a positive statement. It means that individual tasks require different times to be processed. Say, 99% of the tasks are processed in one millisecond, while 1% hangs up for a while causing processing time to exceed one second. Such a behaviour is unwelcome at best and a showstopper at worst. This article explores the methodology and techniques for measuring and analysing latency jitter.
ØMQ Lightweight Messaging Kernel (v0.6)
Most importantly, 0.6. version of ØMQ introduces load-balancing style of messaging and on-disk offload for the queues (swapping). Support for OpenVMS and Mono are of interest as well.
ØMQ Lightweight Messaging Kernel (v0.5)
There are several new features in ØMQ/0.5. Most importantly, from this version onwards ØMQ becomes a multi-protocol messaging system. Instead relying on single wire-level protocol, user is free to choose the protocol to use. Other new features include auto-reconnect, flow control and queue limits. .NET extension is part of the new release as well.
Broker vs. Brokerless
This article presents different models of how messaging can be done. It discusses drawbacks and advantages of individual approaches. It is meant as a background reading to learn how ØMQ differs from traditional messaging systems.
ØMQ Lightweight Messaging Kernel (v0.4)
ØMQ/0.4 doesn't add much to ØMQ/0.3 in terms of design. The most visible thing in 0.4 release is support for additional OS platforms. Most importantly, Windows port allows you to use ØMQ to power your client GUI applications running on Windows PCs. Aside of Win32, QNX Neutrino, AIX, HP-UX and OpenBSD are now supported.
ØMQ Lightweight Messaging Kernel (v0.3)
ØMQ/0.3 includes many new features over ØMQ/0.2. Most importantly for application developers, it now provides the AMQP "exchange-queue-binding" semantics for message routing. Exchanges and queues are a superior way of designing loosely-coupled distributed applications, and make ØMQ/0.3 more familiar to users of AMQP messaging products such as OpenAMQ and RabbitMQ.
ØMQ Lightweight Messaging Kernel (v0.2)
Where version 0.1 of ØMQ lightweight messaging kernel was more of a proof-of-concept rather than a full-blown solution, with all the code necessary to do the basic job, but no elaborate internal design, version 0.2 has flexible internal architecture, carefully designed to support wide range of scenarios and use-cases. This document describes the architecture of ØMQ lightweight messaging kernel (version 0.2) and explains rationale behind architectural decisions.
ØMQ Lightweight Messaging Kernel (v0.1)
This document describes design decisions made for ØMQ lightweight messaging kernel (version 0.1) and rationale behind the decisions. Afterwards it foreshadows the areas of further development.
Y-suite is a set of components designed for ultra-efficient passing of messages between threads within a process. Y-suite is somehow similar to local sockets, however, it is much faster. The paper discusses its design and performance statistics.
High-speed message matching
Matching messages to requests is a typical bottleneck in a message oriented middleware server. The standard mechanism is the "selector", an SQL-like clause that is interpreted to give a true/false result. Selectors are the basic tool for "content-based routing". Given a high volume of messages and requests, the cost of selectors grows exponentially. The "topic" mechanism used by middleware servers provides a faster matching algorithm based on a hierarchical naming system, but this still acts as a bottleneck in high-volume scenarios.
Measuring messaging performance
Performance measurement is done for two basic reasons. Firstly, we want to have some figures for marketing our messaging systems, secondly we need a diagnostic tool to help us with eliminating performance problems during product development. As for marketing figures, we want to say for example that we are able to transport half a million of 512-byte messages a second with a latency up to 100 microseconds.
Messaging enabled network
The concept of "Messaging Enabled Network" has evolved from an attempt to integrate AMQP with high-performance messaging use cases, such as those encountered in stock trading business. What follows is an analysis of the bottlenecks in high-performance environments and a discussion how to avoid them. The resulting network topology is then consoled with AMQP model.
Message-oriented Middleware Analysis
We explain the rationale behind the development of AMQ as an architecture and AMQP as a new industry standard protocol. This document is designed as useful background material for people wishing to understand the AMQP design. This document was written by Pieter Hintjens in 2005-06, and formed the basis for the AMQ Protocol Specifications. Many other people contributed ideas and suggestions that were included in part or whole in this document and the AMQ architectures.
The financial sector lives off messaging technology. On "Wall Street" (the global stock trading business), capacity and latency are everything. Current infrastructure, highly tuned to get million-message per second throughputs, and sub-millisecond latencies, still fails when trading gets frantic. Huge amounts of money depend on being the first to get data, and the first to trade.
Written: 10 Aug 2007 06:47
Revised: 11 Nov 2014 10:28
If you found this page useful, please rate it up so others will find it.
Who's watching this page?Dominic Luciano
Fernando J Quintero