Git and Github

The ØMQ Community uses the git version control system, and the GitHub cloud for its repositories.

The ØMQ Community consists of a number of projects, each with its own public git repository, or "git". Each git has an owner or owners (with admin rights), contributors (with read/write rights), and users (with read access). Each project organizes its git as it wishes. A project is "official" when it is held under the zeromq organisation at GitHub, otherwise it is "unofficial". To make your project "official", discuss on the mailing list. The zeromq organisation owners group have the privileges to create new projects.

We use github's pull request model for changes. To make a change you fork the git in question, make and test your changes, and then make a pull request. The benefit of a pull request is that it is trackable, like an issue. Pull requests only work from a fork back to the original project.

You will need a free github account to work with us. We have no hard opinion on github except that we rather like it and it seems to encourage people to work together. The process is independent of github and we could switch in the future.

At all times, remember that it's up to you, as contributor, to convince others that your work is worth including. This means: make it useful, neat, test it fully, discuss it upfront, and so on.

Getting Started

Download and install git. On Linux, apt-get install git. If you're new to git, read the git docs, and Pro git by Scott Chacon.

Ensure that your copy of git is configured with your real name and the e-mail address you wish to be associated with your contributions. This is required to correctly track authorship:

 $ git config --global user.name "Your Name" $ git config --global user.email your.name@example.com 

Create a user profile at GitHub with your real name and the same email you used to configure your git.

Configure your Bash prompt if you are on Linux by copying this into your .bashrc or .bash_profile.

Do your research. To contribute to a project, you need to know (a) the owner of that project and (b) the location of the git at github. If it's not obvious, ask on zeromq-dev.

Basic Techniques

If you're new to git, especially if you come from SVN, you work by getting full copies of the repository on your local hard disk, and then exchanging sets of changes to and from other gits. It sounds complex, and sometimes is, but it works very well for large loose groups like ours.

A git is a set of 'branches', starting with the 'master' branch. Use 'git branch' to see what branches you have.

To get a git onto your hard disk: use the 'git clone' command (using the ØMQ source git as example):

 $ git clone git://github.com/zeromq/zeromq2.git 

Behind a firewall you may need to use 'http:' instead of 'git:'.

Your clone has an origin, which is a 'remote' by that name. Use 'git remote -v' to see what remotes you have.

To make your changes: use your favorite tools to edit, compile, build, test. Do not allow your editor to reformat code you're not changing, or remove whitespaces elsewhere, this will make your patches useless.

To commit your work: use 'git add (files)' and 'git commit'. Use 'git commit —amend' to add to or fix up the previous commit.

The 'git commit' command opens an editor for you to enter a commit message. Provide a 1-line summary, followed by a blank line, followed by a description of what you changed. The commit message becomes part of the permanent history of the project if your changes are accepted, so be clear and concise. And check your sleppling.

To abandon your changes: either wipe your directory and re-clone the project git, or use the 'git reset' command. All git commands have help ('git reset —help'), and extensive explanation online.

To push a branch to a remote: 'git push <branchname> <remotename>', usually 'git push master origin'.

To pull a branch from a remote: 'git pull master origin', which fetches the master branch from the origin remote, and merges it into your local master branch.

The Pull Model

The home page for the project git has a button "Fork", which will fork the project into your own profile. Click it, and you get a fork of the project git. Now clone your forked git to your hard disk. Now work and commit your work as explained in Basic Techniques, and push your changed branches back to your fork.

When you're ready to send your work to the project owner, go to github.com and click the "pull request" button. Follow the instructions, and it should all be crystal clear.

Separate Your Changes

Separate different independent logical changes into separate commits (and thus separate patch submissions) when at all possible. This allows each change to be considered on it's own merits. Also, it is easier to review a batch of independent changes rather than one large patch.

Write Good Commit Messages

Commit messages become the public record of your changes, as such it's important that they be well-written. The basic format of git commit messages is:

• A single summary line. This should be short — no more than 70 characters or so, since it can be used as the e-mail subject when submitting your patch and also for generating patch file names by 'git format-patch'. If your change only touches a single file or subsystem you may wish to prefix the summary with the file or subsystem name.
• A blank line.
• A detailed description of your change. Where possible, write in the present tense, e.g. "Add assertions to zmq_foo()". If your changes have not resulted from previous discussion on the mailing list you may also wish to include brief rationale on your change. Your description should be formatted as plain text with each line not exceeding 80 characters.

Give Yourself Credit

Add yourself to the CONTRIBUTORS file or other lists of contributors for the project, with your commit. The maintainers won't do this, it's your choice whether you consider your patch worth a mention, or not.

You must make contributions under your real name, associated with your github account. Anonymous contributions may be made via proxies, ask on IRC if someone will help you.

Copyrights and Licenses

Make sure your contributions do not include code from projects with incompatible licenses. ZeroMQ uses the LGPLv3 with a static linking exception. If your code isn't compatible with this, it will sooner or later be spotted and removed. The best way to avoid any license issues is to write your own code.

Contributing to libzmq

Since January 2012 libzmq has a new contribution process adapted from other successful ZeroMQ commmunities such as PyZMQ.

The goals of this process are to:

1. To remove all barriers to new contributors to libzmq, so that we allow more people to become core contributors to libzmq.
2. To allow anyone with process discipline to become a maintainer of libzmq without requiring knowledge of the codebase.
3. To encourage safe experimentation and learning without risk to stable versions and existing users.
4. To reduce the number of github repositories we use, without making libzmq more complex internally.
5. To reduce the risk of human error or negligence in the delivery of packages to end users.

Philosophy

• All contributors to libzmq are equal; we all own the code and we all have equal rights to make patches.
• The economics of any patch (its relevance, accuracy, and value) are decided by end-users, not by other contributors, nor by the maintainers.
• The maintainers may have an opinion on the quality of the patch, see below.
• Contributors experiment in their own repositories and contribute patches back to libzmq when they wish to.
• The team that manages patches back to libzmq are the "maintainers". Maintainers are not developers and they have no opinion on patches; their job is to enforce process.
• Our opinion on patches is that a bad patch is better than no patch: it encourages discussion, stimulates growth of the community, and offers a beginner a way to improve.
• We also believe in getting minimal changes rapidly to real users, and encouraging organic improvement through small steps, rather than making large, dramatic, and stressful changes.
• If you want an analogy for the Maintainer role, think of Wikipedia. We enforce process, stop outright spam and abuse, but allow others to argue value.
• For a comparison with other development processes, see this article.

Patch Quality

Maintainers may reject patches or ask for improvements based on objective quality criteria. These are:

• How clearly the patch is explained and how far it is anchored on previous discussion on zeromq-dev. Patches that come from nowhere and are not lucidly explained risk being rejected.
• Whether the author of the patch is using his real name in his github account, or not.

Any contributor with opinions on the quality of a patch is encouraged to express them via further patches.

Guidelines

• Patch authors SHOULD update NEWS if their patch fixes a bug or adds functionality. All changes to NEWS should be consistent with previous style. This maintainer strongly suggests the style from ZeroMQ/2.1.

• Patch authors SHOULD NOT modify the libzmq version number. This is a maintainer decision.

• A patch MUST adhere to the ZeroMQ Coding Style Guidelines.

• Patches SHOULD NOT include substantial code from other projects, for several reasons. First, it can create licensing difficulties. Second, it creates bundled dependencies that are troublesome to keep accurate over time. Third, it creates risk for ZeroMQ since foreign code lives outside our community. Exceptions are code that you can cleanly rewrite and take ownership of.

How it Works

• The master branch of libzmq holds the latest bleeding edge version and is always assumed to build though it will always be considered "unstable".

• Releases are given their own branches using major-minor names ("3-1", "3-2"). Each release branch will progress through unstable to stable, and then legacy, with tags for each formal release.

• Anyone who wishes to make a patch to libzmq forks the repository and works on their private copy. When they are ready to contribute their patch they make a github pull request.

• All direct commits to libzmq are forbidden, no exceptions.

• The maintainers will aggressively and optimistically merge pull requests back to libzmq master, with minimal opinion on quality and relevance. The only hard requirement is that the patch can be automatically merged.

• Patches on stable releases will only be accepted for bug fixes, and require reproducible test cases. The maintainers will use these test cases to ensure that patches work.

• Experimental and raw work exists as unofficial personal forks of libzmq that maintainers (and the community) have no opinion on, do not attempt to document, or manage.

• If the maintainers do have any quality opinions on patches to master, it is that small patches are preferred over large ones. Any patch that seems oversized may be rejected on that basis alone.

• All pull requests are echoed to the zeromq-dev list and discussions of the patch will happen on the list and/or the github pull request as people like. Note: this is not yet working, so please email zeromq-dev with news of your pull request.

• Anyone who is discontent with a patch will make their own patch to fix or reverse the previous patch. Again, maintainers have no opinion on this.

To Add a New Feature

To contribute a new feature, one forks libzmq, writes and tests a minimal implementation of the new feature and makes a pull request. All pull requests are automatically published to zeromq-dev for review and comment. The maintainers at their discretion merge the pull request onto master. From then on, it will be included in automatic builds and tested by early adopters. When a minimal implementation gets consensus approval, one improves and extends it, and documents it.

How Releases are Made

Maintainers make releases in response to the flow of changes from the community. In general these rules of thumb apply:

• A formal unstable release (off master) is the main way of getting important new functionality to users, who often will not trust git master branches. So, the maintainers will make unstable packages in order to drive speculative testing of new features by real users. The right moment to make an unstable release is when a series of edits (patches) have slowed down and started to stabilize.

• When a branch is released as unstable, the maintainers may decide to create a formal major-minor branch. They may also keep some iterations on master. If they create a branch, they will need to merge commits to master to that branch. The advantage is that other changes can be continued independently of the branch.

• A major-minor branch becomes naturally more stable as issues are solved, and maintainers will use change frequency to decide how to push such a branch through from beta to stable, and finally to legacy.

To Fix a Bug in a Stable Release

To contribute a bug fix, one forks libzmq, writes and tests the bug fix, and makes a pull request to master. The maintainers check that there is a proper test case (for fixes to stable branches) and retest the fix after merging the pull request. The maintainers then merge that fix to the various branches it affects, and the bug fix is then included in automatic builds of that branch and will go into new packages. The maintainers will treat bug fixes that cannot be tested with extreme skepticism.

by mato

• Maximal line length is limited to 80 characters.
• If a statement has to be broken into two lines, second (and any subsequent) line should be indented by one level.
• Indentation is always done using spaces, tabs are never used.
• One level of indentation is 4 characters long.
• Each file starts with a header containing the short license text.

Comments

Both C and C++ style comments are allowed.

• C style comments (/* */) should be used for large block of comments, mostly at the beginning of the file.
• The code itself should be commented by C++ line comments (//).
• Code should be broken to small pieces (couple of lines each), every piece doing one simple task.
• Each piece should be preceded by a comment explaining what is its intent.
• Each code piece should be followed by a blank line.
• C++ style line comment starts with two slashes followed by two spaces.
• The text of comment begins with a capital letter and ends by a period.

 // Compute the factorial. int factorial = 1; for (int i = 2; i != 11; i++) factorial *= i; // Present the result to the user. cout << "Factorial of 10 is " << factorial << "." << endl; 

Identifiers

Identifiers are in lower case. If identifier consists of multiple words, the words are separated by underscores.

Identifiers should be meaningful rather than arbitrary. The only exception are control variables of short cycles where short names like i, it etc. can be used.

 int sum = 0; for (int i = 0; i != 100; i++) sum += i; 

The type of the variable should not be explicitly marked in the identifier. I.e. no hungarian notation.

Function arguments should end by underscore. This way we can distinguish function arguments from member variables with the same name:

 struct complex_t { complex_t (float real_, float imaginary_) : real (real_), imaginary (imaginary_) { } float real; float imaginary; }; 

Identifier for types (structs, classes, enums, typedefs) are postfixed by "_t" (e.g. complex_t).

Code blocks

For functions, structures, classes, enums and namespaces both opening bracket and closing bracket are placed on separate lines:

 void fx () { // Code goes here. } 

With for, while, if and else blocks opening bracket is on the same line as the control statement:

 if (sum > 1000) { // Code goes here. } 

Even if for, while, if or else block contains only a single statement, the statement should be placed on a separate line:

 if (end) exit (1); 

If the indenting of the controlled block incidentally collides with the control statement that's broken into two lines, second line of the control statement should be indented by 6 spaces rather than 4 to prevent confusion:

 if (very_long_variable_name == 10000 && another_horrendous_variable_name == 1000000 && ludicrously_long_variable_name == 1000000000) counter++; 

Operators

Unary operators are not separated from the expression in any way:

 counter++; 

Binary operators should be separated from adjacent expression by spaces:

 z = x + y; 

Subscripts and function calls are separated from the expression by space:

 fx (my_array [0]); 

String concatenation (PHP) should be separated by spaces:

 $foo = $bar . " " . $bat; 

Exceptions

• Assertions say that the 0MQ developers do not expect this situation to ever happen, i.e. it is an internal error that demands a fix to the 0MQ code.

• Errors say that the 0MQ developers expect this situation to happen in applications, i.e. it is an external error that suggests a fix to the application.

• C++ exceptions are not to be used within the core codebase.

Public Interfaces

Public interfaces of components must not be called by code inside the interface.

For example, this is not allowed:

 int f(int x) { return g (x); } int fsucc(int x) { return f (x) + 1; } 

Reserving public interfaces for the public is necessary for maintenance of public invariants, whilst allowing encapsulated implementation manipulators to work with weaker invariants temporarily. Even the mere existence of an otherwise correct call stands in the way of simple code changes, and particularly transparent invasions such as provided by external tracing and profiling tools. We don't want to confuse public calls to functions with internal calls, and we don't want to count inner calls when profiling.

The 0MQ system demands an invariant of socket I/O: no two threads may perform I/O at the same time. There are two ways this invariant can be maintained: by the client, or by 0MQ. In the latter case wrapping the code bodies of the function calls with a mutex lock suffices, however if one public API doing this called another there'd be an immediate deadlock.

by martin_sustrik

The GNU Smalltalk binding is in its initial stage. We have the most important core functions working.
If you are planning to write a binding for some other Smalltalk, please try to co-ordinate your
effort with us so that all bindings share a common high-level interface.

Github

https://github.com/vijaymathew/gst_zmq

Contact

moc.liamg|remehcs.eht.yajiv#moc.liamg|remehcs.eht.yajiv

Mailing List

Discussions about this language binding take place on the general zeromq-dev list.

Smalltalk variant: Pharo & Squeak

See http://www.squeaksource.com/ZeroMQ.html

by vijaymathew

General

How do I start the ØMQ daemon?

There are no services or daemons to start: ØMQ is a library. Compile and link an example and run it. ØMQ applications speak to each other directly.

How do I use a regular BSD socket to communicate with a ØMQ socket?

ØMQ has its own wire-level protocol. In order for a regular socket to communicate with it, that regular socket would need to send messages conforming to that protocol. Additionally, please read the section in the guide detailing how ØMQ is not a neutral carrier for your data.

Does ØMQ support IP multicast?

Yes, ØMQ includes Pragmatic General Multicast (RFC 3208) support using the excellent OpenPGM implementation.

Does ØMQ store messages on disk?

No. Do not even think about that. (Even when 2.1.x has a feature that looks like that)

Does ØMQ include APIs for serializing data to/from the wire representation?

No. This design decision adheres to the UNIX philosophy of "do one thing and do it well". In the case of ØMQ, that one thing is moving messages, not marshalling data to/from binary representations.

Some middleware products do provide their own serialization API. We believe that doing so leads to bloated wire-level specifications like CORBA (1055 pages). Instead, we've opted to use the simplest wire formats possible which ensure easy interoperability, efficiency and reduce the code (and bug) bloat.

If you wish to use a serialization library, there are plenty of them out there. See for example Google Protocol Buffers.

I'm trying to send data using the pgm/epgm transport and I get "Protocol not supported". Why?

You need to have ØMQ built with the —with-pgm option for this to be enabled.

How can I integrate ØMQ sockets with normal sockets? Or with a GUI event loop?

You can use the zmq_poll() function to poll for events on both ØMQ and normal sockets. The zmq_poll() function accepts a timeout so if you need to poll and process GUI events in the same application thread you can set a timeout and periodically poll for GUI events. See the zmq-camera example for a demonstration.

Why can't I use standard I/O multiplexing functions such as select() or poll() on ØMQ sockets?

ØMQ socket is not a standard POSIX socket. It would be great if it was, however, POSIX doesn't provide a mechanism to simulate file descriptors in user space. To convert ØMQ sockets into POSIX file descriptors we would have either to move ØMQ to kernel-space or hack the kernel to provide the functionality needed. In both cases we would have to sacrifice portability and stick to a single operating system. Note that there's a way to retrieve a file descriptor from ØMQ socket (ZMQ_FD socket option) that you can poll on from version 2.1 onwards, however, there are some serious caveats when using it. Check the documentation carefully before using this feature.

When sending a multipart message, my receiver doesn't get any message parts until the last part is sent. Is ØMQ broken?

The ØMQ library guarantees that multipart messages are sent and received atomically. A message cannot be delivered by the library to your application until all frames have been received. Obviously, this cannot happen while the sender still has parts pending or in queue.

There are two reasons for multipart message support in the library.

1. This function supports a scatter/gather-style for message transmission so the application can avoid memcpy'ing the (potentially) large data to a single message. Zero copy is a huge performance win particularly for large messages.
2. Multipart support may help a protocol designer to logically separate their protocol into separate frames at the application level. This may ease parsing on the receiving end since not all languages support fast bit-twiddling for binary structures like C.

How do I use the ZMQ_SWAP socket feature to persist my data to disk?

It is not the responsibility of the library to handle data persistence. If you need to make sure no messages are ever lost, you need to write application-level code to persist your data to non-volatile memory and handle the recovery modes of your application. Also, ZMQ_SWAP is deprecated and will be removed in the 3.x series of releases since it confuses many people over proper usage.

Is it possible to receive EAGAIN or to block when sending a multi-part message?

Multipart messages are sent as an atomic unit. If one part is sent successfully, then the socket is guaranteed to not block or return EAGAIN until all parts have been sent. Of course, if you run out of memory in the meantime then the guarantee doesn't mean much, so don't try to send messages that exceed available memory.

Are you trying to tell me that ØMQ won't magically save me from out-of-memory conditions?

You are a perfect candidate for using AMQP or JMS. Please use google to find more information on libraries that support those platforms and protocols.

Platform and Patterns

I want to write a program using ØMQ sockets. Which socket types should I use?

Please read the guide. It covers each socket pattern along with their use-cases. For further assistance, please join the mailing list or IRC and ask for help. Please do not be upset if the first question asked is, "Have you read the Guide yet?"

My multi-threaded program keeps crashing in weird places inside the ØMQ library. What am I doing wrong?

ØMQ sockets are not thread-safe. This is covered in some detail in the Guide.

The short version is that sockets should not be shared between threads. We recommend creating a dedicated socket for each thread.

For those situations where a dedicated socket per thread is infeasible, a socket may be shared if and only if each thread executes a full memory barrier before accessing the socket. Most languages support a Mutex or Spinlock which will execute the full memory barrier on your behalf.

For more information, please read the Guide.

Why do I see different behavior when I bind a socket versus connect a socket?

ØMQ creates queues per underlying connection, e.g. if your socket is connected to 3 peer sockets there are 3 messages queues.

With bind, you allow peers to connect to you, thus you don't know how many peers there will be in the future and you cannot create the queues in advance. Instead, queues are created as individual peers connect to the bound socket.

With connect, ØMQ knows that there's going to be at least a single peer and thus it can create a single queue immediately.

Consequently, when sending a message to bound socket with no peers, there's no queue to store the message to. Not so with connected socket.

I'm worried about my application heartbeats queueing up behind lower-priority data and causing a disconnect. How can I send a message with higher priority so it jumps forward in the queue?

There is no concept of message priority enforced by the library. We suggest opening a second set of sockets for the purposes of passing heartbeats. Alternately, modify your application so that it considers any incoming message as a renewal of the heartbeat from its source. This allows the application to save bandwidth and heartbeat only when there is no other traffic on the network.

I need to have multiple sockets share a single TCP connection (host + port). How can I accomplish this?

ØMQ cannot multiplex streams over a single connection. This is being investigated as a future enhancement. Join the mailing list or IRC and let yourself be heard.

I set a HWM (high water mark) for a socket but it isn't working!

That's not a question. Also, please be certain to read the man page for zmq_setsockopt() closely. Certain socket options only take effect for subsequent zmq_bind/zmq_connect calls. We recommend setting all socket options before making any calls to zmq_bind/zmq_connect; that way we don't have to remember these tiny implementation details and can focus on writing great code.

Also, read the next question about HWM below.

How does the HWM (high water mark) work with any socket type?

It works the following way right now:

The I/O thread reads messages from the pipe and pushes them to the network. If network is not able to accept more data (e.g. TCP backpressure is applied) it stops reading messages from the pipe and waits until the network is ready for accepting more data.

In the application thread, messages are simply pushed to the pipe when zmq_send() is called. If the pipe is full (HWM is reached) the message is dropped.

The problem with the above approach is that when you send a lot of messages is a quick sequence (e.g. sending small messages in a tight loop) the messages are stored in the pipe until it is full and the subsequent messages are simply dropped. The sender is not even notified about the fact that messages are disappearing.

The main core developer is hopeful that some community members will volunteer to assist in replacing this mechanism with a rate flow control mechanism.

When running "make test" on OSX, how do I fix the failures?

Please refer to the tuning guide for platform-specific tuning. In short, OSX has some low defaults that the tests overrun so they need to be tuned.

Performance

What is the optimal number of I/O threads for best performance?

The basic heuristic is to allocate 1 I/O thread in the context for every gigabit per second of data that will be sent and received (aggregated). Further, the number of I/O threads should not exceed (number_of_cpu_cores - 1).

The graph in the test results shows that ØMQ is slower than TCP/IP. What's the point then?

Obviously, you would expect system working on top of TCP to have higher latencies than TCP. Anything else would be - simply speaking - supernatural. However, throughput is a different matter. ØMQ gets you more throughput than TCP has using intelligent batching algorithms. Moreover ØMQ delivers value-add over the TCP. Asynchronicity, message queueing, routing based on business logic, multicast etc.

How come ØMQ has higher throughput than TCP although it's built on top of TCP?

Avoiding redundant networking stack traversals can improve throughput significantly. In other words, sending two messages down the networking stack in one go takes much less time then sending each of them separately.This technique is known as message batching.

When sending messages in batches you have to wait for the last one to send the whole batch. This would make the latency of the first message in the batch much worse, wouldn't it?

ØMQ batches messages in opportunistic manner. Rather than waiting for a predefined number of messages and/or predefined time interval, it sends all the messages available at the moment in one go. Imagine the network interface card is busy sending data. Once it is ready to send more data it asks ØMQ for new messages. ØMQ sends all the messages available at the moment. Does it harm the latency of the first message in the batch? No. The message won't be sent earlier anyway because the networking card was busy. On the contrary, latency of subsequent messages will be improved because sending single batch to the card is faster then sending lot of small messages. On the other hand, if network card isn't busy, the message is sent straight away without waiting for following messages. Thus it'll have the best possible latency.

ØMQ's latency is nice, but is there a way to make it even lower?

We are working on delivering ØMQ over alternative networking stacks, thus having advantage of features like kernel bypass, avoiding TCP/IP overhead, using high-performance networking hardware etc. That way we can get the latency as low as 10 microseconds.

Why am I only getting 40 Mbps performance when sending messages using PGM?

PGM uses rate-limiting on the sender side. By default this limit is set to 40 Mbps. You can set it using the ZMQ_RATE option to zmq_setsockopt().

Does the ØMQ library disable the Nagle algorithm (TCP NODELAY)?

Yes.

Monitoring

How do I determine how many messages are in queue?

This isn't possible. At any given time a message may be in the ØMQ sender queue, the sender's kernel buffer, on the wire, in the receiver's kernel buffer or in the receiver's ØMQ receiver queue. Furthermore, a ØMQ socket can bind and/or connect to many peers. Each peer may have different performance characteristics and therefore a different queue depth. Any "queue depth" number is almost certainly wrong, so rather than provide incorrect information the library avoids providing any view into this data.

How can I be notified that a peer has connected/disconnected from my socket?

ØMQ sockets can bind and/or connect to multiple peers simultaneously. The sockets also transparently provide asynchronous connection and reconnection facilities. At this time, none of the sockets will provide notification of peer connect/disconnect. This feature is being investigated for a future release.

How can I retrieve a list of all connected peers?

This is not supported.

How can I auto-discover services provided by a ØMQ-based application?

This type of facility is not supported by the library. Such a tool could be built on top of ØMQ.

Security

Is it true that it is not safe to use ØMQ over the internet because it will crash?

Earlier versions of the ØMQ library (before 2.1) were not very resilient against "fuzzing" attacks. A malformed packet or garbage data could cause an old version of the library to assert and exit. Since the release of 2.1, all reported cases of assertions caused by bad data have been fixed. If your testing uncovers a problem in this area, please file a bug report.

What security features does ØMQ support?

None at the moment. ØMQ does not deal with security by design but concentrates on getting your bytes over the network as fast as possible. Solutions exist for security at the transport layer which are well understood and have had many man-years of development invested in them, such as IPsec or OpenVPN.

Having said that, if you have a use case which precludes the use of transport layer security please let us know and we can discuss your needs.

I read somewhere that I have to run my application as root if I want to use PGM, is this true?

The epgm:// transport uses PGM encapsulated in UDP packets and does not require any special permissions.

If you need to use the raw pgm:// transport then your application must be able to create raw sockets, which means either running as root or with capabilities to do so. On a modern Linux distribution with capabilities enabled you can use the following to run an application with the CAP_NET_RAW capability enabled:

 $ sudo execcap 'cap_net_raw=ep' pgmsend moo 

For more details please see the relevant OpenPGM wiki page.

Building

What packages do I need to build ØMQ on Ubuntu?

You need build-essential and, for pre-ØMQ/3.0 versions, uuid-dev. So sudo apt-get install build-essential uuid-dev. You can also run sudo apt-get build-dep libzmq0 which installs all the build-dependencies of the libzmq0 ubuntu package.

After cloning the github repository, I can't build the library because the 'configure' script doesn't exist! What do I do?

You need autotools installed for your OS so that the configure script can be generated. Run this code to generate that script.

 $ ./autogen.sh 

by martin_sustrik

The Java binding requires a recent release of 0MQ, which you can download from the download area, or the latest development version, which you can download and build from the the github repository.

Build and installation

UNIX-like platforms

Get the jzmq source code by cloning the jzmq git or using github's download function, then do the following:

 $ autogen.sh $ configure $ make $ make install 

On Linux you must run the ldconfig command as root after running make install to ensure that the system library cache is updated.

Make sure that you have set the Java classpath to the directory where ØMQ classes reside.

Finally, for Java to find the libzmq and libjzmq shared libraries you must ensure that java.library.path is set to the directory where these are installed (normally /usr/local/lib on UNIX-like systems).

Example command line for running a Java test program on Linux:

 $ java -Djava.library.path=/usr/local/lib -classpath /home/user/zeromq/libjzmq/:./local_lat tcp://127.0.0.1:5555 1 100 

Fedora

Specific Fedora instructions from Steven McCoy on the mailing list:

Required packages:

  autoconf automake libtool gcc gcc-g++ make libuuid-dev git java-1.6.0-openjdk-devel 

1) Download and unpack ZeroMQ 2.1.10.

$ wget http://download.zeromq.org/zeromq-2.1.10.tar.gz
$ tar zxf zeromq-2.1.10.tar.gz

2) Build

 $ cd zeromq-2.1.10 $ ./configure --with-pgm $ make $ sudo make install 

Now libzmq.so should reside in /usr/local/lib

3) Clone JZMQ from GitHub.

 $ git clone https://github.com/zeromq/jzmq.git 

4) Build

 $ cd jzmq $ ./autogen.sh $ ./configure $ make $ sudo make install 

5) Setup environment

 $ sudo bash 

optional step #1 (not required on Debian platforms)

  # echo /usr/local/lib > /etc/ld.so.conf.d/local.conf # ldconfig 

optional step #2

  # echo CLASSPATH=/usr/local/share/java/zmq.jar:. >> /etc/environment Incredibly limiting as you will still need to override to include any other directory or JAR file. 

optional step #3

  # echo export LD_LIBRARY_PATH=/usr/local/lib > /etc/profile.d/ldlibrarypath.sh This is pretty much a workaround to a JRE defect: http://lists.fedoraproject.org/pipermail/java-devel/2011-March/004153.html 

 # exit 

Then log out and log back in again.

6) Verify new environment

 $ echo $CLASSPATH /usr/local/share/java/zmq.jar:. $ echo $LD_LIBRARY_PATH /usr/local/lib 

7) Test with Java ØMQ performance examples

 $ cd jzmq/perf $ java local_lat tcp://127.0.0.1:5000 1 100 

This will fail if zmq.jar cannot be found in the class path.
This will fail if libjzmq.so or libzmq.so cannot be found in java.library.path or LD_LIBRARY_PATH.

If you skip optional step #1 you will need to specify the library path:

 $ LD_LIBRARY_PATH=/usr/local/lib java local_lat tcp://127.0.0.1:5000 1 100 

If you skip optional step #2 you will need to specify the class path:

 $ java -cp /usr/local/share/java/zmq.jar:. local_lat tcp://127.0.0.1:5000 1 100 

Note that setting -Djava.library.path is insufficient for libjzmq.so to find libzmq.so but it is sufficient if you take optional step #1 and skip optional step #3, i.e. LD_LIBRARY_PATH is not overridden but ld.so.conf is updated.

 $ java -Djava.library.path=/usr/local/lib local_lat tcp://127.0.0.1:5000 1 100 

Windows

Get the source code, then use MSVC (2008 or later) to open the solution file builds\msvc\msvc.sln and build the projects.

Ensure that the javac binary is in the Path variable.

Note that ØMQ and JDK header file has to be on "include path" (Tools|Options|Projects and Solutions|VC++ Directories|Include files) and ØMQ libraries have to be on "library path" (Tools|Options|Projects and Solutions|VC++ Directories|Library files):

 Include files: <jdk>\include\win32 <jdk>\include <zeromq>\include Library files: <zeromq>\lib 

To run it, firstly check whether libzmq.dll is on the system PATH. Secondly, make sure that you add zmq.jar and the jzmq perf directory to the Java classpath. Thirdly, for Java to find the jzmq.dll shared library you must ensure that java.library.path is set to the directory where it is installed.

Example command to run Java test program on Windows:

 C:\zmq\java\perf> set PATH=%PATH%;C:\zmq\lib C:\zmq\java\perf> java -Djava.library.path=C:\zmq\java\lib -classpath C:\zmq\java\lib\zmq.jar;. local_lat tcp://127.0.0.1:5555 1 100 

Windows 64bit Build Instructions

Alternative Windows instructions from Steven McCoy on the mailing list:

1) Build ZeroMQ or install a prepared package. I built with SDK 7.1 but I also have MSVC 2010 Express and Pro installed.

2) Clone JZMQ from GitHub, might be easier with Cygwin.

 $ git clone https://github.com/zeromq/jzmq.git 

3) Insert attached CMakeLists.txt, you probably want to install CMake for Windows too.

4) With a suitable JDK installed prepare the build:

 c:\zeromq\jzmq\jzmq> mkdir build64 c:\zeromq\jzmq\jzmq> cd build64 c:\zeromq\jzmq\jzmq> cmake .. -G "NMake Makefiles" -- The C compiler identification is MSVC -- The CXX compiler identification is MSVC -- Check for CL compiler version -- Check for CL compiler version - 1600 -- Check if this is a free VC compiler -- Check if this is a free VC compiler - no -- Check for working C compiler: c:/Program Files (x86)/Microsoft Visual Studio10.0/VC/bin/amd64/cl.exe -- Check for working C compiler: c:/Program Files (x86)/Microsoft Visual Studio10.0/VC/bin/amd64/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: c:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/amd64/cl.exe -- Check for working CXX compiler: c:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/amd64/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Java version 1.6.0.27 configured successfully! -- Found Java: C:/Program Files/Java/jdk1.6.0_27/bin/java.exe (found version "1.6.0.27") -- Found JNI: C:/Program Files/Java/jdk1.6.0_27/lib/jawt.lib -- Configuring done -- Generating done -- Build files have been written to: C:/zeromq/jzmq/jzmq/build64 c:\zeromq\jzmq\jzmq> cmake-gui . 

Change "Debug" to "Release", hit "Configure" and "Generate".

Java version 1.6.0.27 configured successfully!

Configuring done

Generating done

5) With NSIS installed you can jump to build the package or just build the libraries.

 c:\zeromq\jzmq\jzmq> nmake package or c:\zeromq\jzmq\jzmq> nmake 

Then output similar to as follows:

 Microsoft (R) Program Maintenance Utility Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. [ 11%] Generating config.hpp [ 22%] Generating org/zeromq/ZMQ.class, org/zeromq/ZMQ$$Context.class, org/zeromq/ZMQ$$Socket.class, org/zeromq/ZMQ$$Poller.class, org/zeromq/ZMQ$$Error.class, org/zeromq/ZMQException.class, org/zeromq/ZMQQueue.class, org/zeromq/ZMQForwarder.class, org/zeromq/ZMQStreamer.class, org/zeromq/EmbeddedLibraryTools.class, org/zeromq/App.class [ 33%] Generating org_zeromq_ZMQ.h, org_zeromq_ZMQ_Error.h, org_zeromq_ZMQ_Context.h, org_zeromq_ZMQ_Socket.h, org_zeromq_ZMQ_Poller.h [ 44%] Generating lib/zmq.jar Scanning dependencies of target jzmq [ 44%] Generating org/zeromq/ZMQ.class, org/zeromq/ZMQ$$Context.class, org/zeromq/ZMQ$$Socket.class, org/zeromq/ZMQ$$Poller.class, org/zeromq/ZMQ$$Error.class, org/zeromq/ZMQException.class, org/zeromq/ZMQQueue.class, org/zeromq/ZMQForwarder.class, org/zeromq/ZMQStreamer.class, org/zeromq/EmbeddedLibraryTools.class, org/zeromq/App.class [ 44%] Generating org_zeromq_ZMQ.h, org_zeromq_ZMQ_Error.h, org_zeromq_ZMQ_Context.h, org_zeromq_ZMQ_Socket.h, org_zeromq_ZMQ_Poller.h [ 55%] Building CXX object CMakeFiles/jzmq.dir/src/Context.cpp.obj Context.cpp [ 66%] Building CXX object CMakeFiles/jzmq.dir/src/Poller.cpp.obj Poller.cpp [ 77%] Building CXX object CMakeFiles/jzmq.dir/src/Socket.cpp.obj Socket.cpp C:\zeromq\jzmq\jzmq\src\Socket.cpp(176) : warning C4267: 'argument' : conversion from 'size_t' to 'jsize', possible loss of data C:\zeromq\jzmq\jzmq\src\Socket.cpp(182) : warning C4267: 'argument' : conversion from 'size_t' to 'jsize', possible loss of data C:\zeromq\jzmq\jzmq\src\Socket.cpp(476) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data C:\zeromq\jzmq\jzmq\src\Socket.cpp(500) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data [ 88%] Building CXX object CMakeFiles/jzmq.dir/src/util.cpp.obj util.cpp [100%] Building CXX object CMakeFiles/jzmq.dir/src/ZMQ.cpp.obj ZMQ.cpp Linking CXX shared library lib\jzmq.dll Creating library lib\jzmq.lib and object lib\jzmq.exp [100%] Built target jzmq Run CPack packaging tool... CPack: Create package using NSIS CPack: Install projects CPack: - Run preinstall target for: JZMQ CPack: - Install project: JZMQ CPack: Create package CPack: - package: C:/zeromq/jzmq/jzmq/build64/JZMQ-2.1.10-win64.exe generated. 

Then to test copy all the libraries into the perf directory from the jzmq package and build some examples.

 C:\zeromq\jzmq\jzmq\perf>"\Program Files\Java\jdk1.6.0_27"\bin\javac -cp zmq.jar;. local_lat.java C:\zeromq\jzmq\jzmq\perf>"\Program Files\Java\jdk1.6.0_27"\bin\javac -cp zmq.jar;. remote_lat.java 

Then test:

 C:\zeromq\jzmq\jzmq\perf>"\Program Files\Java\jdk1.6.0_27\bin"\java -Xcheck:jni -verbose:jni,class -classpath .;zmq.jar local_lat tcp://127.0.0.1:5000 1 100 C:\zeromq\jzmq\jzmq\perf>"\Program Files\Java\jdk1.6.0_27"\bin\java -classpath .;zmq.jar remote_lat tcp://127.0.0.1:5000 1 100 message size: 1 [B] roundtrip count: 100 mean latency: 85.0 [us] 

The perf directory looks like this:

 10/26/2011 01:18 PM <DIR> . 10/26/2011 01:18 PM <DIR> .. 10/26/2011 01:09 PM 16,384 jzmq.dll 10/03/2011 12:47 PM 445,952 libzmq.dll 10/26/2011 12:53 PM 1,492 local_lat.class 10/05/2011 05:07 PM 1,723 local_lat.java 10/05/2011 05:07 PM 68 local_lat.sh 10/05/2011 05:07 PM 2,278 local_thr.java 10/05/2011 05:07 PM 68 local_thr.sh 10/05/2011 05:07 PM 512 Makefile.am 10/05/2011 05:07 PM 9,988 Makefile.in 10/26/2011 01:18 PM 1,853 remote_lat.class 10/05/2011 05:07 PM 2,049 remote_lat.java 10/05/2011 05:07 PM 69 remote_lat.sh 10/05/2011 05:07 PM 1,722 remote_thr.java 10/05/2011 05:07 PM 69 remote_thr.sh 10/26/2011 01:09 PM 15,350 zmq.jar 15 File(s) 499,577 bytes 

Example packages to download:

ZeroMQ Win64
JZQMQ Win64

Bug Reporting

http://github.com/zeromq/jzmq/issues

Mailing list

gro.qmorez.stsil|ved-qmorez#gro.qmorez.stsil|ved-qmorez

by martin_sustrik

http://hackage.haskell.org/package/zeromq-haskell (ØMQ/2.1.x)
http://hackage.haskell.org/package/zeromq3-haskell (ØMQ/3.1.x)

Source Code

http://github.com/twittner/zeromq-haskell

Installation

Note: This package depends on GHC-7.0 or higher and ØMQ (2.1.x or 3.1.x depending on the package used).

Automatic download

 $ cabal update $ cabal install zeromq-haskell # (ØMQ/2.1.x) $ cabal install zeromq3-haskell # (ØMQ/3.1.x) 

You might want to use --enable-documentation for cabal install to have the API-Documentation generated.

Manual download

Download the package and unpack it into a temporary directory. Change into it and perform the following steps:

 $ cabal install 

Note: If you have installed ØMQ into a non-standard location you may see an error message in the configure step, like:

 Setup.hs: Missing dependency on a foreign library: * Missing header file: zmq.h * Missing C library: zmq This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. 

Just follow the instructions and the installation should finish without errors.

Documentation

Documentation is available online at:

http://hackage.haskell.org/packages/archive/zeromq-haskell/latest/doc/html/System-ZMQ.html (ØMQ/2.1.x)
http://twittner.github.com/zeromq-haskell/ (ØMQ/3.1.x)

Additionally, if you did use --enable-documentation with cabal install you find the API documentation on your local system as well.

Bug Reporting

If you encounter problems please fill a bug report at:

http://github.com/twittner/zeromq-haskell/issues

or write an e-mail to:

moc.liamg|renttiw.flarot#moc.liamg|renttiw.flarot

Mailing List

Discussions about this language binding take place on the general zeromq-dev list.

by martin_sustrik

Phase 1

Initial Requirement: to be able to run and test the 0MQ Guide examples automatically, i.e. without any user intervention. The minimum requirement for this is a timeout on the process.

The next feature needed is to kill servers when the client examples complete, since the server isn't needed any more. This requires some conditional kill operations. Diagnostics will just go to standard output, so they can be redirected and examined after a test run is complete.

Next: we want to log the status of the examples, to ensure the programs didn't crash or terminate prematurely or in error. We'll need some kind of logging mechanism.

Next: we want to gather the outputs and compare with what is expected to check for correctness.

Phase 2

Here we'll generalise the overall capabilities to provide better monitoring and control, possibly including a way to view the network status on a web browser.

Phase 3

This phase will extend the capabilities to remote process management. We'll use ssh (secure shell) to start daemons on target machines, and 0MQ to communicate with them. This will allow management of a network remotely without using ssh once the daemons are started.

Phase 4

Add security and encryption to the network management.

Status

At present I have a simple process manager which launches a process together with a monitoring thread. The thread polls the process status to see if it is running.

by Yttrill

Process Manager

In Development, by John Skaller | 2012

Tools to launch and manage processes, driven by the need to actually test the 0MQ Guide examples to ensure that they compile and run as expected automatically, so the testing can be included in a background script.

Discussion Process Manager

Cocaine Distributed Application Server

In Development, by Andrey Sibiryov and Rim Zaidullin | 2011

Cocaine is a fast and lightweight multi-language (you can easily write your own language binding) event-driven (also, you can easily write your own event drivers) task-based distributed application server built on top of ZeroMQ transport and MessagePack serialization library. Yeah, it is cool.

ZmqMessage C++ library

Ready to test, by Phorm, Inc. | 2011

If your sense of beauty is not happy with code like

 zmq::message_t reply1(hello.size()); memcpy(static_cast<char*>(reply1.data()), hello.data(), hello.size()); zmq::message_t reply2(world.size()); memcpy(static_cast<char*>(reply2.data()), world.data(), world.size()); s.send(reply1,ZMQ_SNDMORE); s.send(reply2); 

 reply << hello << world << ZmqMessage::Flush; 

gevent-zeromq - ZeroMQ compatibility library for gevent (Python)

Ready to test, by Travis Cline | 29 July 2011

Combine fast, cheap green threads in Python via gevent and ZeroMQ's power gevent-zeromq.

Rsyslog ZeroMQ Input / Output Plugins

Ready to test, by Aggregate Knowledge | 26 May 2011

Aggregate Knowledge has released ZeroMQ Rsyslog Plugins open source. These plugins allow rsyslog to receive and send data over zmq push / pull sockets (pub/sub coming soon).

Objective C ZMQ Socket Helper (wrapper over czmq zmsg class)

Ready to test, by Michael Zaccari | 17 May 2011

I wrote this simple Objective C wrapper to help manage sockets within an Objective C class. This uses the zmsg class provided by iMatix. I hope this helps anyone who is looking for examples of using ZeroMQ with Objective C.

Salt (Python)

Ready to test, by Thomas S Hatch | 29 April 2011

Salt is a distributed remote execution system used to execute commands and query data. Salt is meant to solve the problem of managing large sets of servers. It was developed in order to bring the best solutions found in the world of remote execution together and make them better, faster and more malleable. Salt is a great example of secure pub-sub over ZeroMQ, and scales to hundreds or thousands of servers.

EM-ZeroMQ (Ruby)

Ready to test, by Andrew Cholakian | 5 Feb 2011

EM-ZeroMQ Is a low-level interface to ZeroMQ sockets that hooks into the reactor loop of Ruby's EventMachine library. This requires 2.1.x+ versions of ZeroMQ, as it requires ZMQ_FD support to hook into EventMachine's select/epoll loop.

Evented interface to ZeroMQ sockets (Lua)

Ready to test, by Robert G. Jakabosky | 24 Dec 2010

lua-handlers is a lua wrapper of lua-zmq & lua-ev that provides an evented interface to ZeroMQ sockets. It allows you to send & recv messages on many ZeroMQ, TCP & UDP sockets at the same time.

Zeromqt (Qt)

Pre-alpha, by Steve Atkins

Zeromqt integrates ZeroMQ (version 2.1.0 and later) into the Qt event loop, mapping ZeroMQ message events onto Qt signals. It also provides an API that is more "Qt-like" than the native ZeroMQ C or C++ APIs, allowing messages to be handled as QByteArrays and providing classes that are similar in style to QAbstractSocket.

nzmqt (Qt) - A lightweight C++ Qt binding for ZeroMQ

Ready to test, by Johann Duscher

nzmqt is a re-implementation of Zeromqt which integrates ZeroMQ into Qt's event loop. However, nzmqt builds upon ZeroMQ's official C++ binding, cleanly places code into a separate namespace, adds multi-part message support, and not only works with PUB-SUB protocol, but also with REQ-REP and PUSH-PULL protocol. Included samples show those protocols in action, together with exception handling in Qt. Furthermore, the source code is officially released under the corporate-friendly BSD license.

Soaplib (Python)

In progress, by Burak Arslan | 16 Oct 2010

Soaplib is a SOAP processing library for Python. Previously a SOAP server library that exclusively used HTTP as transport, the upcoming 2.0 release will transform Soaplib to a general, transport-agnostic SOAP processing library. Preliminary support for a ZeroMQ transport that uses REQ/REP sockets was recently incorporated to the master branch.

C++ wrapper of zmq::poll

Ready to test, by Radu Braniste | 25 Aug 2010

Why another wrapper? The usual idiom used when writing zmq::poll based code is based on a block of if_conditions, testing for the occurrence of one event or the other. This might be error prone and hard to maintain in the long run. And this is where the wrapper comes handy: it separates poll functionality from actions and state (4 different ways to do it) and provides the boiler plate of zmq::poll functionality. Hope you'll find it useful!

Electricity Monitoring

In progress, by Bob Scott | 23 Aug 2010

I am using ZeroMQ for message passing between small components running on a PlugComputer for 24/7 electricity monitoring. I use the pub-sub pattern for publishing data from the logger and request-reply for a charting client and data server. I chose ZeroMQ for this application because of its ease of use, brokerless design, flexibilty of messaging patterns and transport and large number of language bindings.

zdevices devices project

Ready to test, by iMatix Corporation | 22 August 2010

zdevices is the ZeroMQ devices collection, a repository of device packages written by and for ZeroMQ users. All code is GPLv3 licensed. Includes zdevice/1.0 that starts a built-in device from the command line.

zfl library for C

In progress, by iMatix Corporation | 22 August 2010

zfl is the ZeroMQ Function Library, a library for writing 0MQ devices and applications in C. All code is LGPLv3 licensed. Includes JSON parsing for devices.

dripdrop

In progress, by Andrew Cholakian | 16 August 2010

DripDrop is a Ruby / Javascript framework for building apps quickly using a reactor pattern. ZeroMQ is baked in at the core. It provides a common serialization format (based on BERT or JSON), and lets you seamlessly bridge HTTP, WebSockets, and ZeroMQ using a terse and readable syntax. Essentially, DripDrop exposes a common interface across a large number of protocols, letting you focus on your service, not the implementation details.

JeffMQ

In progress, by Jeff Plaisance | 16 August 2010

JeffMQ is a peer to peer message queue framework. It is built on top of ZeroMQ and uses a queue binding system similar to AMQP. There are no special nodes or single points of failure. Queues can only be accessed from the node they are created on. There is no replication, if the node dies the messages are gone.

0MQ plugin for RabbitMQ

In progress, by Michael Bridgen | 16 August 2010

The purpose of this plugin is to provision ZeroMQ sockets that relay messages into RabbitMQ. Each ZeroMQ socket type is given an idiomatic encoding in the AMQP broker model, which means AMQP clients can interoperate.

ProDataLab

In progress, by ProDataLab | 12 August 2010

ProDataLab is an FBP environment that takes advantage of every possible efficiency in processing data via streams. The intention is to build an extremely flexible, parallel, infinitely scalable, distributed application services system for every type and size of data set — processing, analyzing, learning, plotting and reporting, etc. Fast, efficient ZeroMQ messaging will be used as the core of ProDataLab's communication fabric. ProDataLab will eat extremely large data sets for breakfast.

ZMQMachine (Ruby)

Feature complete, by Chuck Remes | 4 August 2010

ZMQMachine is a Ruby library implementing the well-known reactor pattern using 0mq sockets. The API is heavily influenced by the popular Ruby Eventmachine library. All socket I/O activity is non-blocking. Program logic is implemented via asynchronous callbacks and/or handler classes that conform to a specific API. Documentation is limited, but familiarity with Eventmachine will resolve most questions.

TCP thin streams

Idea, by by Steven McCoy | 2 August 2010

A wide range of Internet-based services that use reliable transport protocols display what we call thin-stream properties. This means that the application sends data with such a low rate that the retransmission mechanisms of the transport protocol are not fully effective. In time-dependent scenarios (like online games, control systems or some sensor networks) where the user experience depends on the data delivery latency, packet loss can be devastating for the service quality. Extreme latencies are caused by TCP's dependency on the arrival of new data from the application to trigger retransmissions effectively through fast retransmit instead of waiting for long timeouts. — LWN.net

Parallel sort

In-progress, by Oliver Smith | 2 August 2010

So, I decided to try and figure out how to implement a parallel sort with ZeroMQ message passing.

Throw-nothing API (C++)

Ready-to-test, by Matt Weinstein | 1 August 2010

I've derived a "throw nothing" version of zmq.hpp. The functions are in namespace zmq::nothrow:: I've posted it up to github at: git://github.com/mjw9100/zmq_nothrow.git. Comments welcome. Best, Matt

Reactor pattern (C++)

Ready to test, by Matt Weinstein | 30 July 2010

Folks, I've submitted a reactor pattern for ØMQ to github at git://github.com/mjw9100/zmq_reactor.git. This pattern allow complex arrangements of sockets to be polled in arbitrary ways. The essential way to use this: 1- Create a bunch of zmq_reactors, 2- Link them in the right order into list, 3- Tell zmq_reactor_poll to poll them.

Async::Worker (C++)

Ready to test, by Oliver Smith | 22 July 2010

What I was looking for was a convenient C++ way of creating work-splitting tasks and work-delegating tasks. Having cut my teeth on ZeroMQ I immediately to making a worker pool system. The result is Async::Worker. It combines concepts from OpenMP and Intel's TBB. On a virtual quad-core machine building with -O0 I see a 35-40% reduction in processing time.

The Mongrel2 Web Server

Ready to test, by Zed Shaw | 22 July 2010

Mongrel2 is the complete redesign of the Mongrel web server to be an application, language, and network architecture agnostic web server. It's written by the original author of Mongrel, and uses the Mongrel HTTP parser, but everything else is new. The goal is to create a web server specifically designed for web applications over serving files.

by pieterh

To lower the risk of insufficiently tested code breaking ØMQ stable releases (which has happened a couple of times recently), we recommend (and use ourselves) this policy for moving patches into a stable release:

• Every patch MUST be identified by a clean issue (i.e. one that covers precisely that problem).
• The patch MUST be have a clear test case that reproduces the problem.
• This test case MUST be written in C and be stored in the issues repository.
• The issue SHOULD have an external reporter, i.e. a ØMQ user who can confirm an eventual fix.

Pulling patches from libzmq

When the libzmq repository is defined as a remote, you can pull specific commits from it:

 git fetch --no-tags libzmq git cherry-pick -n 43e885 (review changes) git commit -c 43e885 

On official distributions we use the issue tracker to log libzmq commits that we wish to apply to the distribution. This means we can review, discuss, and track these changes.

Making a Distribution Release

By "release" we mean a set of downloadable packages. If there were any changes to the ØMQ ABI (as defined by http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html) then the ABI version must be updated as the last thing before a public release. The ABI version is set in configure.in (search for LTVER).

To make a new distribution release:

1. Run the selftests: 'make check'.
2. Update NEWS based on the git log, and commit that.
3. Create a tag with the appropriate version number: git tag v3.1.9 -m "This is release 3.1.9"
4. Push the tag to github: git push —tags origin
5. Run ./autogen.sh and ./configure, and make dist to get .zip and .tar.gz packages.
6. If the release is not considered mature enough for production use (i.e. stable), add -alpha, -beta, or -rc before the file extension.

If you are making an official release, then also:

1. Upload the .tar.gz and .zip files to the downloads.zeromq.org site (you need access for this).
2. Recreate the SHA1 and MD5 hashes for these new files.
3. Add the new version to the reference manual at http://api.zeromq.org, and rebuild that site.
4. Update the download page at http://www.zeromq.org/intro:get-the-software
5. Email the release announcement to zeromq-dev and (separately) to zeromq-announce, so that Reply-To works properly.
6. Announce the release on Freshmeat, Twitter, and the #zeromq IRC channel.

Precautions: don't make an official release immediately after applying changes. Allow at least one day for the automated builds to test on all platforms. If the changes are not 100% safe, ask for review of the repository master on email or IRC.

Setting a new version number

Set the new version number immediately after a release, so that the release repository always holds the next in progress version. The version number is located in {{include/zmq.h}:

 #define ZMQ_VERSION_MAJOR 2 #define ZMQ_VERSION_MINOR 1 #define ZMQ_VERSION_PATCH 2 

by pieterh

Goals

The goals of these policies are to provide assurances about the nature of changes users can expect. We hope to deliver increasingly stable and reliable versions of a product, while also developing increasingly interesting functionality in parallel.

Versioning

• The product version consists of Major.Minor.Update, e.g. 2.0.7.
• The wire level protocol (ZMTP) has its own version numbers.
• The ABI has its own version numbers.
• You can apply new update to your production environment safely. Updates don't change API, ABI, command lines, wire protocol or semantics. They contain only bugfixes. If a bugfix involves change in API, ABI, command line, wire protocol or semantics, it won't be part of an update.
• New minor version allows for new functionality (i.e. new APIs), slight changes to the semantics etc. The contract for minor version will be made more precise as we go on. In overall, new minor version should at least compile with your old applications. It may even run, however, you should read the NEWS file so you are sure that changes made won't affect your application behaviour in subtle ways.
• New major version means no contract. Anything can change. Major versions are meant for delivering backwards incompatible changes. You will have to tweak your applications to work with new major version.

Current Releases

We maintain four branches of ZeroMQ at present:

• 2.0.x is the deprecated 2.x release, which receives user-contributed bug fixes only.
• 2.1.x is the stable 2.x release, which receives downstreamed bug fixes only.
• 2.2.x is the 2.x ongoing release, which receives downstreamed bug fixes, new functionality, and additional layers, e.g. czmq. This is mainly a placeholder for continuing 2.x maintenance after 2.1 is frozen. One goal with 2.2.x is to expand the ZeroMQ distribution package to include essential core language bindings.
• 3.1.0 is the new 3.x unstable release.

2.x and 3.1 implements the same wire level protocol, ZMTP/1.0. 3.0 (deprecated) uses an incompatible version of ZMTP.

by pieterh

0MQ support is built-in to the Felix standard library.
You do not need to download or install any bindings.
You may view the binding code here:

http://felix-lang.org/lib/std/io/zmq.flx

Only version 3.1 or higher is supported.

Currently you need to install libzmq yourself,
the Felix build process does not build it.

The resource location record for this library can be viewed here:

http://felix-lang.org/$/usr/local/lib/felix/felix-latest/config/zmq.fpc

and looks like this on a typical unix like box:

Name: ZeroMQ
Description: Message Passing Library
provides_dlib: -lzmq
provides_slib: -lzmq
includes: '"zmq.h"'

You will need to provide a modified version of this file if the
indicated compiler and linker switches will not locate your 0MQ
resources.

Overview

The Felix binding provides two levels of support for 0MQ.

Raw C

This is an almost direct lift of the C functional interface, except that it has been made type safe.

Felicitous

This interface is a bit higher level than the raw C one,
with shorter names, adds some support for using
Felix (C++) strings as data, and is remodelled a bit
to use higher order functions to simulate an OO feel.

—

by Yttrill

http://github.com/persan/zeromq-Ada

Development environment

Linux

A modern gcc/gnat such as http://libre.adacore.com installed.
Or GCC 4.5 or better with Ada.

Windows

A modern gcc such as http://libre.adacore.com installed.
A set of posix build tools such as cygwin, with cygwin do not install gcc or have GNAT before it in the PATH.

Build and installation

You will first need to install the latest ØMQ from the development trunk here:
http://github.com/sustrik/zeromq2
Then download the zeromq-Ada source and cd to its top-level directory:

 $ cd zeromq-Ada 

Compile the stuff

 $make 

Finally install the package by running:

 $ make install 

You may have to run this last command with sudo.

Windows

Exact the same but you need ether cygwin or mingw as build environment

Sample code

A simple client/server application

This example implements a simple "SQL server" following the client/server model. The server listens to requests using unicast TCP. Each request is a simple string. Upon receiving a request the server will send back a canned response of OK, also as a string. All the samples are part of the package.

The server application, using Ada bindings:

 with ZMQ.Sockets; with ZMQ.Contexts; with ZMQ.Messages; with Ada.Text_IO; use Ada.Text_IO; procedure ZMQ.examples.Server is ctx : ZMQ.Contexts.Context; s : ZMQ.Sockets.Socket; resultset_string : constant String := "OK"; begin -- Initialise 0MQ context, requesting a single application thread -- and a single I/O thread ctx.Initialize (1); -- Create a ZMQ_REP socket to receive requests and send replies s.Initialize (ctx, Sockets.REP); -- Bind to the TCP transport and port 5555 on the 'lo' interface s.Bind ("tcp://lo:5555"); loop declare query : ZMQ.Messages.Message; begin query.Initialize; -- Receive a message, blocks until one is available s.recv (query, 0); -- Process the query Put_Line (query.getData); declare -- Allocate a response message and fill in an example response resultset : ZMQ.Messages.Message; begin resultset.Initialize (query.getData & "->" & resultset_string); -- Send back our canned response s.Send (resultset); resultset.Finalize; end; query.Finalize; end; end loop; end ZMQ.Examples.Server; 

The client application, using Ada bindings:

 with ZMQ.Sockets; with ZMQ.Contexts; with ZMQ.Messages; with Ada.Text_IO; use Ada.Text_IO; procedure ZMQ.examples.Client is ctx : ZMQ.Contexts.Context; s : ZMQ.Sockets.Socket; begin -- Initialise 0MQ context, requesting a single application thread -- and a single I/O thread ctx.Initialize (1); -- Create a ZMQ_REP socket to receive requests and send replies s.Initialize (ctx, Sockets.REQ); -- Bind to the TCP transport and port 5555 on the 'lo' interface s.Connect ("tcp://localhost:5555"); for i in 1 .. 10 loop declare query_string : constant String := "SELECT * FROM mytable"; query : ZMQ.Messages.Message; begin query.Initialize (query_string & "(" & i'Img & ");"); s.Send (query); query.Finalize; end; declare resultset : ZMQ.Messages.Message; begin resultset.Initialize; s.recv (resultset); Put_Line ('"' & resultset.getData & '"'); resultset.Finalize; end; end loop; end ZMQ.Examples.Client; 

Finally the multi-threaded server

 with ZMQ.Sockets; with ZMQ.Contexts; with ZMQ.devices; with Ada.Strings.Unbounded; use Ada.Strings.Unbounded; procedure ZMQ.examples.Multi_Thread_Server is task type server_task (ctx : not null access ZMQ.Contexts.Context; id : Integer) is end server_task; task body server_task is msg : Ada.Strings.Unbounded.Unbounded_String; s : ZMQ.Sockets.Socket; begin s.Initialize (ctx.all, Sockets.REP); s.Connect ("inproc://workers"); loop msg := s.recv; Append (msg, "<Served by thread:" & id'Img & ">"); s.Send (msg); end loop; end server_task; ctx : aliased ZMQ.Contexts.Context; Number_Of_Servers : constant := 10; servers : array (1 .. Number_Of_Servers) of access server_task; workers : ZMQ.Sockets.Socket; clients : ZMQ.Sockets.Socket; dev : ZMQ.devices.device; begin -- Initialise 0MQ context, requesting a single application thread -- and a single I/O thread ctx.Initialize (servers'Length + 1); -- Create a ZMQ_REP socket to receive requests and send replies workers.Initialize (ctx, Sockets.XREQ); workers.Bind ("inproc://workers"); -- Bind to the TCP transport and port 5555 on the 'lo' interface clients.Initialize (ctx, Sockets.XREP); clients.Bind ("tcp://lo:5555"); for i in servers'Range loop servers (i) := new server_task (ctx'Access, i); end loop; dev.initialize (devices.Queue, clients, workers); end ZMQ.Examples.Multi_Thread_Server; 

 gprbuild -p -P zmq-examples 

You can then run bin/server and bin/client.

Documentation

The README file of the source code is the best documentation for now.

Test Suite

zeromq-Ada has an integrated test suite, to be completed!

 $ make test 

Bug Reporting

If you encounter problems please fill a bug report at:

http://github.com/persan/zeromq-Ada/issues

Discussions about this language binding take place on the general zeromq-dev list.

by martin_sustrik

pyzmq aims to support multiple versions of libzmq. pyzmq-2.1.9 supports
libzmq >= 2.1.4, and as of release 2.1.7, has experimental support for libzmq's 3.0 API.
2.1.9's 3.0 support has been updated to include changes in the 4.0 dev branch.

Binary installers

PyZMQ has binary installers that include current libzmq for Windows and OSX.
Python eggs (as found by easy_install) on pypi,
and MSI installers for Windows on GitHub.

easy_install

In many cases, pyzmq can be installed with:

 easy_install pyzmq 

You may need to install the python-dev package first. If we don't have an egg for your system (e.g. Linux), then easy_install will be building from source, and you will need to install libzmq, but easy_install pyzmq or pip install pyzmq will still work as long as libzmq was installed to a default location, such as /usr/local.

If you see a message like error while loading shared libraries: libzmq.so.1, then try rebuilding the dynamic linking cache with sudo ldconfig prior to building pyzmq.

If you are still using zeromq 2.0.10, you can install download pyzmq-2.0.10.1 from GitHub or install with:

 easy_install "pyzmq==2.0.10.1" 

Source Code

The current stable pyzmq release can be downloaded from GitHub:
pyzmq-2.1.11.tar.gz
pyzmq-2.1.11.zip

The git repository is at: http://github.com/zeromq/pyzmq. You can download the current PyZMQ development version as a zip or tar package, or clone the git repository:

 git clone git://github.com/zeromq/pyzmq.git 

If you get the source via git clone, or edit any of the pyzmq cython files (*.pyx), then you will need Cython to generate the C extensions, which can be installed with:

 easy_install cython 

If you download a zipfile or tarball, Cython is not a build dependency.

Build and installation

You need to install ØMQ first. Please use the current stable package.

Then download the PyZMQ source and cd to its top-level directory:

 $ cd pyzmq 

building pyzmq

If you are using the current pyzmq (2.1.4, or later), we have a new configuration command that should simplify building pyzmq.

If pyzmq can't find libzmq (e.g. if it's not installed to /usr/local), you can tell pyzmq where zeromq has been installed, with:

 $ python setup.py configure --zmq=/path/to/zmq/prefix 

This will be a directory containing include and lib, which contain the zmq headers and libraries respectively. If you configured zeromq with the —prefix command, this will be the same location. On Linux/OSX systems, it will likely be something like $HOME/usr/local or /usr/local/libzmq-dev. If zeromq was installed to the default location of /usr/local this step should be unnecessary.

Windows

On Windows, this prefix is likely to be the zeromq source directory. If you downloaded pyzmq and libzmq into the same directory, then you would run:

 $ python setup.py configure --zmq=../libzmq 

As of pyzmq-2.1.4, you no longer need to edit your PATH or move libzmq.dll around manually.

Building PyZMQ < 2.1.4

For PyZMQ < 2.1.4, there is not a configure command, so you must copy setup.cfg.template to setup.cfg and edit that new file to specify the library_dir and include_dirs variables to point to your ØMQ installation:

 [build_ext] # Edit these to point to your installed zeromq library and header dirs. library_dirs = /usr/local/libzmq-dev/lib include_dirs = /usr/local/libzmq-dev/include 

If you did a standard make, ØMQ will be in /usr/local/lib and /usr/local/include and a setup.cfg might not be necessary.

Finally install the package by running:

 $ python setup.py install 

You may have to run this last command with sudo, depending on your install path.

Under Linux, you will need the python-dev package installed.

Windows

Building pzymq on Windows requires either MinGW or MSVC 2008. The steps are mostly the same as for POSIX platforms, however, for pyzmq older than 2.1.4, you will need to copy the ØMQ library libzmq.dll to pyzmq\zmq before building. Please contact us if you have difficulties building or using PyZMQ on Windows. Here is a step-by-step guide.

Documentation

The README file of the source code has a quick summary of information.

We also have Sphinx generated documentation hosted on GitHub:

 http://zeromq.github.com/pyzmq/ 

The Sphinx docs contain autogenerated coverage of the API as presented in Python, as well as descriptions of where PyZMQ may differ from other ØMQ bindings.

Test Suite

PyZMQ has an integrated test suite. To run the test suite simple do:

 $ python setup.py test 

This requires that you have built the extensions in place, i.e. with:

 $ python setup.py build_ext --inplace 

otherwise you will see an ImportError when compiled extensions (such as initthreads) are imported.

You can also run the test suite with nose, trial, or py.test after installing, which do not require the build to be inplace:

 $ nosetests -vvs zmq.tests 

Bug Reporting

If you encounter problems please fill a bug report at:

http://github.com/zeromq/pyzmq/issues

or write an e-mail to:

ellisonbg AT gmail DOT com
and
benjaminrk AT gmail DOT com

Mailing List

Discussions about this language binding take place on the general zeromq-dev list.

by martin_sustrik

http://github.com/mkoppanen/php-zmq

Build and installation

You will first need to install the ØMQ (2.1.x or higher recommended)

http://www.zeromq.org/intro:get-the-software

Then obtain the php bindings for 0MQ - these work with PHP 5.2.x and above.

Building via PEAR

The extension can be built via PECL, using the zero.mq pear channel

 pear channel-discover pear.zero.mq pecl install zero.mq/zmq-beta 

You may have to add the extension to your php.ini with this line:

 extension=zmq.so 

Building from Github

 git clone git://github.com/mkoppanen/php-zmq.git 

and cd to the directory:

 $ cd php-zmq 

Next, run phpize to generate configure script and run the configure command:

 phpize && ./configure 

Finally install the package by running:

 $ make && make install 

You may have to run this last commands with sudo.

Finally add the following line to your php.ini:

 extension=zmq.so 

Windows

http://snapshot.zero.mq/

FreeBSD

In FreeBSD PHP must be configured with "Link thread lib (for threaded extensions)" option. Without this option the PHP binding will hang when creating new contexts or sockets.

Documentation

PHPdoc documentation: http://php.zero.mq
General documentation: http://wiki.github.com/mkoppanen/php-zmq/

Test Suite

The test suite can be run using:

 $ make test 

Bug Reporting

If you encounter problems please fill a bug report at:

http://github.com/mkoppanen/php-zmq/issues

or write an e-mail to:

mkoppanen (at) php dot net

Mailing List

Discussions about this language binding take place on the general zeromq-dev list.

by martin_sustrik

Development happens at:

http://github.com/lestrrat/ZeroMQ-Perl

The most recent release can always be found at:

http://search.cpan.org/dist/ZeroMQ

Build and installation

You need to install the 0MQ library and the perl headers (usually the perl-dev package on linux) before you attempt installing the Perl bindings. Once that is done, you can install the ZeroMQ Perl module like any other Perl module from CPAN (possibly as root user):

 $ cpan ZeroMQ 

This will automatically install all Perl module dependencies. You may choose to install the dependencies manually and download the release tarball from the above URL. If so, you can extract it and then simply do the following to compile, test and install the Perl bindings:

 $ perl Build.PL $ ./Build test $ sudo ./Build install 

Documentation

A fairly complete documentation can be found at

http://search.cpan.org/perldoc?ZeroMQ

Bug Reporting

If you encounter problems please fill a bug report at:

http://github.com/lestrrat/ZeroMQ-Perl/issues

Mailing List

Discussions about this language binding take place on the general zeromq-dev list. Please CC the maintainer (cf. the documentation for the contact address) in any discussion.

Also available

Bindings with less code, more parity with the C API, support for AnyEvent, and experimental zero-copy support are available from:

https://github.com/jrockway/zeromq-raw/

https://github.com/jrockway/anyevent-zeromq/

Master is considered stable and is used in production. The zero-copy branch is experimental and probably won't get you much because Perl loves copying anyway :)

The AnyEvent bindings come with a raw AnyEvent::ZeroMQ::Handle module, and comes with an OO wrapper for each message type in ZeroMQ, allowing you to use higher-level idioms in your code.

Also note that while the bindings on CPAN come with a module called ZeroMQ::Raw, the AnyEvent support in AnyEvent::ZeroMQ does not work with that one, you need the version from jrockway's github.

Please report any bugs to the ZeroMQ mailing list or on the github page. The binding has been tested with and without ithreads and multiplicity, and with Perls 5.10-5.14.

by martin_sustrik

Source Code

The current stable txZMQ release can be downloaded from PyPi: [http://pypi.python.org/pypi/txZMQ/]

It can also be installed with:

 easy_install txZMQ 

Requrements are:

• pyzmq
• Twisted

The git repository is at: https://github.com/smira/txZMQ.

 git clone git://github.com/smira/txZMQ.git make env make 

Test Suite

txZMQ has an integrated test suite. To run the test suite simple do:

 $ trial txZMQ 

Bug Reporting

If you encounter problems please fill a bug report at:

http://github.com/smira/txZMQ/issues

or write an e-mail to:

me AT smira DOT ru

by smira

Introduction

Message routing is a feature that allows for sending individual messages to different destinations based on the content of the message (also called content-based routing).

This article explores different aspects of the routing. It proposes algorithm to use for generic routing, i.e. message passing in a generic directed acyclic graph-like network.

Scope of the problem

Message routing makes sense in data-distribution messaging style. Routing in context of load-balancing messaging style has unclear semantic and little or no real-world applications.

In a point-to-point messaging style, routing can be useful is some scenarios. With 1:1 communication, routing boils down to the simple message filtering. More research should be done on routing in the context of point-to-point messaging style.

Layering

One of the problems with routing is that it requires inter-layer interactions. Think of a ØMQ (zmq.tcp) wire-level protocol where each message consist of length and message payload. Message payload is filled in by the application on the top of ØMQ - the application uses it's own wire-level protocol to format the message. Following picture shows how appication protocol is encapsulated in zmq.tcp protocol:

As can be seen, application have decided to compose the message from a string ("A" in this case) and some other data that are irrelevant for the routing.

Now, we would like ØMQ to send the message to different destinations depending on the string incorporated to the message payload by the sending application. However, ØMQ has no idea of how the application protocol looks like.

The situation is similar to traffic shaping. Traffic shaping is done mostly on layer 2 or 3 of the OSI stack while the criteria to route on (like TCP port) are defined on layers above it.

The solution used by say IOS or Linux "tc" utility is to make shaping algorithms completely generic, so that they can be used whatever the higher level protocol looks like. Thus, what you say is: "Apply this traffic shaping strategy to every packet that contains value 45 in the 32-bit value located on position 12 of the packet."

It would be nice if ØMQ can this level of generality - user can define/implement almost any routing mechanism needed. However, most common routing scenarios should be provided out of the box so that users don't have to mess with the routing details.

The current design doesn't include a mechanism to ensure that sender and receiver are using the same application protocol. Such mechanism is subject to further research.

Algorithm

Subscriptions are issued by terminal message consumers. However, routing should be moved as far upstream as possible to eliminate excessive network traffic and CPU consumption. To achieve it subscriptions are passed upstream. Following algorithm applies:

• In mux (object aggregating several feeds) subscription should be passed to each attached upstream element.
• In demux (object distributing messages to several destinations) subscription should be both kept locally (associated with the particular downstream element) and forwarded upstream. demux object does the actual message matching and passes message only to the downstream elements that have subscribed for it.
• Network protocol engines pass subscriptions upstream if technically possible.
• For performance reasons it's necessary to avoid redundant routing. Following rule applies: If all the subscriptions are passed upstream and there's exactly one element downstream (and there never was more then one element downstream), routing can be skipped.

Examples

Simple in-process messaging (1-to-1)

Messages are passed from one thread to another, subscriptions are passed in the opposite direction.

1-to-many in-process messaging

Subscriptions are passed upstream. Demux component stores the subscriptions on per-downstream-element basis. When message is to be sent, message matching is performed and the message is passed to the matching downstream elements.

Many-to-1 in-process messaging

Subscriptions are passed to each upstream element. This way client can be agnostic about number of upstream elements. Also, it's important to send all subscriptions to a newly attached upstream element. Thus, mux has to store all the subscriptions.

Over-the-network messaging

The basic principle is to pass the subscription upstream via the network connection. Note that this is not possible in some cases. Say PGM reliable multicast is uni-directional, there's no way to pass subscriptions upstream.

Following diagram shows the simplest possible scenario for over-the-network communication. Note that subscription is passed all the way upstream, thus unneeded messages are filtered out immediately in sender's API thread.

Additionally, demux object on the receiver side can skip routing as all the subscriptions are passed upstream and there's only one element downstream:

Following scenario shows the situation where the routing on receiver side cannot be skipped. There are two user threads receiving messages, each of them has different subscription ("A" vs. "B"). Both subscriptions are passed upstream over the network, meaning that both "A" and "B" messages are delivered to the receiver application. Receiver application still has to route the messages to one of the two client threads:

Here's the other situation where routing in receiver cannot be skipped. The network protocol in this case is PGM multicast. It's uni-directional thus the subscriptions cannot be passed upstream. Consequently, all the messages are multicast over the network. Receiver application has to receive all of them and filter out those matching the subscriptions.

Complex messaging topologies

Simple scenarios described above can be combined into complex networks of messaging elements. It's essential for the network to be acyclic so that the messages and subscriptions are not passed on in infinite cycles. Strategy to prevent infinite loops is a subject for further research.

Efficient message matching

Efficient algorithms for message matching are described here.

Concusion

This is the early experience with message routing in ØMQ context. The design is work in progress and subject to change.

by martin_sustrik

 zmq_push () { m=$(cat) && echo \ -e $(printf '\\x01\\x00\\x%02x\\x00%s' \ $((1 + ${#m})) "$m") | nc -q1 $@; } 

Note: this actually works. It acts as a PUSH or DEALER socket, sending one message to a PULL or ROUTER or DEALER socket. It implements the 0MQ wire level protocol.

by pieterh

Source Code

The code resides in the hxzmq github repository. To get the latest development version's source code, clone the repository:

  git clone git://github.com/rjsmith/hxzmq.git 

Alternatively, a package is maintained in the http://lib.haxe.org list that can be added to any haXe installation using:

  haxelib install hxzmq 

Note that you must also have the hxcpp project installed in order to compile the hxzmq.ndll for your own platform from the source code (installing hxzmq via haxelib as above will automatically install hxcpp if you don't have it):

  haxelib install hxcpp 

Documentation

Full build and usage instructions for Windows, Linux and MacOSX platforms are documented in the README and INSTALL files in the distro.

Bug Reporting

http://github.com/rjsmith/hxzmq/issues

Contact

rsmith ( at ) rsbatechnology (dot) co (dot) uk

by rj_smith

https://github.com/pdhborges/ocaml-zmq

https://github.com/bashi-bazouk/Caravan

by martin_sustrik