Ø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
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.
Background to AMQP
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.
Community Makes the Market
We explain our vision of the market, and our guidelines in deciding what to build to serve that market. Centrally, we argue that the market grows from a community, and that the community grows from a set of good standards. Our goal, therefore, is to build ØMQ as a set of standards, along with technology that "seeds" the market.
Market analysis
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.