ZeroMQ

Features of a Higher-Level API

My solution is to use three fairly natural and obvious concepts: string helpers (already the basis for our s_send() and s_recv()), frames (a message frame), and messages (a list of one or more frames). Here is the worker code, rewritten onto an API using these concepts:

while (true) {
    zmsg_t *msg = zmsg_recv (worker);
    zframe_reset (zmsg_last (msg), "OK", 2);
    zmsg_send (&msg, worker);
}

Cutting the amount of code we need to read and write complex messages is great: the results are easy to read and understand. Let’s continue this process for other aspects of working with ØMQ. Here’s a wish list of things I’d like in a higher-level API, based on my experience with ØMQ so far:

• Automatic handling of sockets. I find it cumbersome to have to close sockets manually, and to have to explicitly define the linger timeout in some (but not all) cases. It’d be great to have a way to close sockets automatically when I close the context.

• Portable thread management. Every nontrivial ØMQ application uses threads, but POSIX threads aren’t portable. A decent high-level API should hide this under a portable layer.

• Portable clocks. Even getting the time to a millisecond resolution, or sleeping for some milliseconds, is not portable. Realistic ØMQ applications need portable clocks, so our API should provide them.

• A reactor to replace zmq_poll(). The poll loop is simple, but clumsy. Writing a lot of these, we end up doing the same work over and over: calculating timers, ...