Lightweight Messaging Middleware

6 Pages
  • tcp:// is a plain old TCP socket with a host and port number.
  • ipc:// uses UNIX inter-process communication such as domain sockets, MQ, or whatever is available.
  • inproc:// is an in-process transport that passes messages via memory directly between threads sharing a single 0MQ context.
  • pgm:// is reliable multicast messaging that uses raw IP layering and requires special privileges.
  • epgm:// is an encapsulated version that uses regular User Datagram Protocol (UDP) to do reliable multicast messaging.

0MQ divorces who binds and connects from the previously mentioned configurations. This means that, unlike classic sockets, who connects and who binds doesn’t matter for the direction or kind of message. All that really matters is whether the connection makes sense for your application.

N-to-N Dissemination

Conventional sockets allow only strict one-to-one, many-to-one (many clients, one server), or, in some cases, one-to-many (multicast) relationships. With the exception of ZMQ::PAIR, 0MQ sockets may be connected to multiple endpoints using zmq_connect(), while simultaneously accepting incoming connections from multiple endpoints bound to the socket using zmq_bind(). This allows many-to-many relationships.

The authors describe it best: “Traditional network programming is built on the general assumption that one socket talks to one connection, one peer. There are multicast protocols, but they’re exotic. When we assume ‘one socket = one connection,’ we scale our architectures in certain ways. We create threads of logic where each thread works with one socket, one peer. We place intelligence and state in these threads.

“In the 0MQ universe, sockets are clever multi-threaded applications that manage a whole set of connections automagically for you. You can’t see, work with, open, close, or attach state to these connections. Whether you use blocking send or receive, or poll, all you can talk to is the socket, not the connections it manages for you. The connections are private and invisible, and this is the key to 0MQ’s scalability.

“Your code, talking to a socket, can then handle any number of connections across whatever network protocols are around, without change. A messaging pattern sitting in 0MQ can scale more cheaply than a messaging pattern sitting in your application code.”

Low Overhead and Fast Messaging

Formula One racers say it’s easier to make a fast car reliable than a reliable car fast. 0MQ is quite fast, but doesn’t have the features that give such programs as WebSphere MQ their reputation for reliability. However, the component-like qualities of the 0MQ APIs and supporting routines enable reliability to be built into an application.

0MQ implements a mechanism of batch messaging that allows larger blocks of data to be sent over a link at one time for better network utilization. The algorithm used doesn’t adversely affect latency, so using 0MQ may result in better throughput than, for example, using raw sockets.

An important factor is to minimize resources the messaging system requires. Many other MOM solutions are Java-based and have a huge memory footprint. 0MQ may live in as little as two resident pages. For those writing applications to run in virtual machines or in embedded devices, this is a significant advantage.

6 Pages