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.
Traffic Monitoring
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".
Measuring jitter
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.
Traffic Monitoring
This article describes how to perform network traffic monitoring based on business criteria. First it describes the underlying technology, then it introduces some example business logic and finally the whole application is monitored using Wireshark network protocol analyser.
Ø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.
Building ØMQ on QNX platform
This document and code-snippets contained inside are published under the MIT license. I also don’t take charge for completeness. The idea behind this document is to summarise required changes to get ØMQ framework to work under QNX Neutrino.
Python API for ØMQ
This whitepaper describes first version of the Python extension for ØMQ.
C API for ØMQ
This whitepaper describes first version of the C extension for ØMQ.
Java API for ØMQ
This whitepaper describes first version of the Java extension for ØMQ. It is simplified version of ØMQ interface exposed in the form of Java object. Java extension is not yet part of ØMQ package. You have to download it separately (see below) and build it by hand. Any feedback on Java extension is welcome on ØMQ developer's mailing list.
Ø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.
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.
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.
