

Zmqc: netcat for ØMQ - zacharyvoase
http://zacharyvoase.github.com/zmqc/

======
switz
Aside from the functionality, this is how every _man_ page should look.

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

~~~
wglb
Agreed. Man page for rsync is another one done quite well.

------
zdw
This looks like it would be a killer debugging tool.

Tried to get licensing information on this, but the "unlicense.org" site
appears to not resolve. Part of me wonders if this is a very sly tech joke.

~~~
ComputerGuru
Not at all. Unlicense is just public domain:

[http://webcache.googleusercontent.com/search?sourceid=chrome...](http://webcache.googleusercontent.com/search?sourceid=chrome&ie=UTF-8&q=cache%3Aunlicense.org)

------
sk5t
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.

~~~
zacharyvoase
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?

~~~
sk5t
Aahhh, I didn't have my head on straight from writing so many non-console
programs with ZMQ; you are certainly right about using iconv here.

------
ZephyrP
Calumny! I've found salvation in a git repo!

I can't believe I didn't think of writing this earlier with all the tcpdump
I've done on ØMQ today.

A small shrine shall be erected in your honor, Mr. Zacharyvoase

------
_exec
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.

~~~
rwmj
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.

~~~
_exec
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?

~~~
rwmj
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.

------
chrislloyd
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.

------
bambambazooka
Just wrote a Arch Linux package:
<https://aur.archlinux.org/packages.php?ID=58283>

