ZeroMQ

Public API

The public API consists of two classes (as we sketched earlier):

• fmq_client provides the client API, with methods to connect to a server, configure the client, and subscribe to paths.

• fmq_server provides the server API, with methods to bind to a port, configure the server, and publish a path.

These classes provide a multithreaded API, a model we’ve used a few times now. When you create an API instance (i.e., fmq_server_new() or fmq_client_new()), this method kicks off a background thread that does the real work—that is, runs the server or the client. The other API methods then talk to this thread over ØMQ sockets (a “pipe” consisting of two PAIR sockets over inproc).

If I was a keen young developer eager to use FileMQ in another language, I’d probably spend a happy weekend writing a binding for this public API, then stick it in a subdirectory of the filemq project called, say, “bindings/,” and make a pull request.

The actual API methods come from the state machine description, like this (for the server):

<method name = "publish">
<argument name = "location" type = "string" />
<argument name = "alias" type = "string" />
mount_t *mount = mount_new (location, alias);
zlist_append (self->mounts, mount);
</method>

Which gets turned into this code:

void
fmq_server_publish (fmq_server_t *self, const char *location, const char *alias)
{
    assert (self);
    assert (location);
    assert (alias);
    zstr_sendm (self->pipe, "PUBLISH");
    zstr_sendfm (self->pipe, "%s", location);
    zstr_sendf ...