Zmqc: netcat for ØMQ

50% examples, love it. Never understood why man authors are so afraid of them.

Not at all. Unlicense is just public domain:

http://webcache.googleusercontent.com/search?sourceid=chrome...

I guess you can contribute serialisisaion formats to the project.

The UNIX way is, indeed, to leave this as an exercise to the console. You can use a tool like iconv to convert between encodings; the primary draw of zmqc is that everything is on stdin/stdout. For example:

    zmqc ... | iconv -f iso-8859-1 -t utf-8

If I'd added information on serialisation formats to the program, it would have become very bloated very quickly. JSON, BSON, XML, protobuf, bencode…where does one stop? And besides, since it's stdout, how does one losslessly represent that format without using the format itself?

I have never used zmq, but while working in finance all the servers I worked on used a comercial messaging package to communicate with each other. It simplifies communication between processes running on the same or different machines by abstracting away network topologies. See it as a simplified UDP.

A good way to think about it is "email for applications". Email is a convenient asynchronous way for two people to talk, and (with a bit of formalization) it can be a good way for two or more processes to talk. "Email" here usually means a formal XML message with a standard header and app-defined body.

For example, a process can do part of a job, and pass it along to a mailbox. Another process can (perhaps later, or on a different machine) pick up work from this mailbox and finish it. This can hide the network topology (although in practice, that's not really so true) and also makes it easier to manage because you can take down or restart systems without losing work.

Messaging systems like Apache / Red Hat's qpid are getting very advanced, for example offering guaranteed latency, guarantees against loss of messages, and multiple ways to set up communications. You can set it up so one process "publishes" data while other processes "subscribe" to that feed of data. You can have 1-N, N-1 and N-M mailboxes. You can have edge-triggered or level-triggered data in some message systems.

In the majority of messaging systems, you have a process known as the "broker" which runs on all/most machines, and basically acts as the mailbox, persistent storage and router. It's kind of like sendmail on steroids.

Zero MQ is unusual because there is no broker, and it acts more like an advanced sockets library. There are reasons why this is both good and bad compared to ordinary broker systems.

This explains how flickr leverages message queues to gain scalability:

http://highscalability.com/strategy-flickr-do-essential-work...

Messaging is most useful when you want to communicate between separate servers (or at least processes) and you control both sides. Within a process it is usually overkill. On a public interface with independent implementations you probably want a protocol that can be implemented in any language rather than be tied to a specific messaging library. Between separate parts of one system, messaging can be a convenient and efficient way to send around information. This used to be most common in large complex systems ("enterprise"), but with distributed scaling it is getting more useful for startups and hobbyists.

An alternative in the same space is remote procedure call (RPC). RPC is synchronous while messaging is asynchronous.