What about encodings - is this "left as an exercise for the console"? I love ZMQ but couldn't imagine using a netcat-like tool without ability to specify inbound or outbound text encoding, or serialization format / protobuf, etc.
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?
ZMQ is specifically content agnostic. It looks like zmqc is too. As zacharyvoase pointed out, you'd just pipe the output of messages to other tools that can handle JSON/MsgPack/Protobufs/whatever.
I'm having a hard time understanding what the usefulness of 'messaging' is. Could someone point them out or point me to a few real world applications? I've checked the wiki and I'm still puzzled.
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.
Thank you, it's clearer now. From what I understand, messaging can also be useful as a way to simplify client/server communication in client-server architectures, correct?
For me, the radically interesting thing about messaging is that it's asynchronous. You send a message, and the message could be picked up and acted upon hours later (although usually it's more like milliseconds, or in pub/sub, it could be never).
This is unlike client-server, where basically you always sit waiting for a reply immediately.
However there are some people using messaging for client-server. Notably OpenStack is using RabbitMQ this way.
Another aspect to this is scaling: you might send a message to a mailbox, and on the other end [the sender doesn't know this] there could be a whole set of worker processes picking messages and working on them. Of course client-server can do that, but it requires changes to the client usually to make that happen.
On the subject of ZeroMQ: while broker systems (qpid, RabbitMQ, etc) might seem a bit "boring" and "old fashioned", there's a good reason for setting up mailboxes and persisting messages, particularly when you're trying to make scalable, safe architectures.
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.
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.
There's a similar (but simpler IMHO) project like this already: https://github.com/quackingduck/mp. Either tool is great for learning and debugging ØMQ.
