ZeroMQ: Messaging for Many Applications

ZeroMQ: Messaging for Many Applications

Pieter Hintjens

Language: English

Pages: 516

ISBN: 1449334067

Format: PDF / Kindle (mobi) / ePub


Dive into ØMQ (aka ZeroMQ), the smart socket library that gives you fast, easy, message-based concurrency for your applications. With this quick-paced guide, you’ll learn hands-on how to use this scalable, lightweight, and highly flexible networking tool for exchanging messages among clusters, the cloud, and other multi-system environments.

ØMQ maintainer Pieter Hintjens takes you on a tour of real-world applications, using extended examples in C to help you work with ØMQ’s API, sockets, and patterns. Learn how to use specific ØMQ programming techniques, build multithreaded applications, and create your own messaging architectures. You’ll discover how ØMQ works with several programming languages and most operating systems—with little or no cost.

  • Learn ØMQ’s main patterns: request-reply, publish-subscribe, and pipeline
  • Work with ØMQ sockets and patterns by building several small applications
  • Explore advanced uses of ØMQ’s request-reply pattern through working examples
  • Build reliable request-reply patterns that keep working when code or hardware fails
  • Extend ØMQ’s core pub-sub patterns for performance, reliability, state distribution, and monitoring
  • Learn techniques for building a distributed architecture with ØMQ
  • Discover what’s required to build a general-purpose framework for distributed applications

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

are making release notes to push those without having to create an issue, which would then affect the release notes, leading to stress on the space-time fabric and possibly involuntary rerouting backwards in the fourth dimension to before the invention of cold beer. Shudder. It is simpler to agree that release notes aren’t changes to the software. Creating Stable Releases We want some guarantee of stability for a production system. In the past, this meant taking unstable code and then over

we leave the second job to developers, that gives them a lot of room to interpret. As we make more ambitious protocols (file transfer + heartbeating + credit + authentication), it becomes less and less sane to try to implement clients and servers by hand. Yes, people do this almost systematically. But the costs are high, and they’re avoidable. In this section I’ll explain how to model protocols using state machines, and how to generate neat and solid code from those models. My initial

ourselves that we can turn the normal blocking DEALER socket into a non-blocking socket. Example 8-16 creates a normal DEALER socket, connects it to some endpoint (so there’s an outgoing pipe and the socket will accept messages), sets the high-water mark to 4, and then sets the send timeout to 0. Example 8-16. Checking EAGAIN on DEALER socket (eagain.c) // // Shows how to provoke EAGAIN when reaching HWM // #include int main (void) { zctx_t *ctx = zctx_new (); void *mailbox =

Freelance client - Model One // Uses REQ socket to query one or more services // #include "czmq.h" #define REQUEST_TIMEOUT 1000 #define MAX_RETRIES 3 // Before we abandon static zmsg_t * s_try_request (zctx_t *ctx, char *endpoint, zmsg_t *request) { printf ("I: trying echo service at %s...\n", endpoint); void *client = zsocket_new (ctx, ZMQ_REQ); zsocket_connect (client, endpoint); // Send request, wait safely for reply zmsg_t *msg = zmsg_dup (request); zmsg_send (&msg, client); zmq_pollitem_t

Example 5-18. Key-value message class (kvsimple.c): send method void kvmsg_send (kvmsg_t *self, void *socket) { assert (self); assert (socket); int frame_nbr; for (frame_nbr = 0; frame_nbr < KVMSG_FRAMES; frame_nbr++) { zmq_msg_t copy; zmq_msg_init (©); if (self->present [frame_nbr]) zmq_msg_copy (©, &self->frame [frame_nbr]); zmq_msg_send (©, socket, (frame_nbr < KVMSG_FRAMES - 1)? ZMQ_SNDMORE: 0); zmq_msg_close (©); } } The key methods in Example 5-19 let the caller get and

Download sample

Download