ZMQ Notes

basic_patterns.md

ZMQ Notes

Basic Patterns

• Request/Reply
• Pub/Sub
• Pipleline

Request Reply

Read this w/o taking notes. Might backfill later.

Pub Sub

Read this w/o taking notes. Might backfill later.

Pipeline

This pattern involves three entities that I'll name as following: The initiator, the worker(s), and the collector. The initiator and collector are designed to be constant. Adding more workers requires no configuration changes.

Initiator

This entity is in charge of sending work to the worker(s).

Sends a message to the collector notifying that workers are ready. This is to ensure that work is done in parallel. Upon receiving this message, the collector will start listening for workers to report that they've finished.

The initiator must have two ZMQ_PUSH sockets. One to push work to the worker(s), and the other to tell the collector that this "batch" of work has started.

Worker

A worker receives work from the initiator. It has two ZMQ sockets, a ZMQ_PULL receiver socket to get work, and a ZMQ_PUSH socket, to push results to the collector. Since all workers connect to the same initiator, and bind to the same collector, individual workers don't need separate configuration. Workers can be easily taken up and down.

Collector

The collector has one ZMQ_PULL socket. It receives 1 message from the initiator telling that a batch of work has begun, and many subsequent messages from workers, reporting the result of their work. Worker messages are received using fair queuing behind the scenes.

Gotchas

Since we'd like work to be done in parallel, the initiator is required to send a batch initiation message. Due to a worker's connect taking a non-trivial amount of time, if we didn't wait till workers were ready, a bunch of messages would be sent to the first workers to connect. To get around this, the collector expects the first message it receives to be from the initiator, telling it that optimal time has been given to the workers to connect. It is now okay to start recv-ing the result of their work.

Misc

• Always close a message the moment you are done with it.
• If you are opening and closing a lot of sockets, you might have architected poorly.
• When you exit the program always close your sockets and call zmq_term. If you don't kill sockets first, zmq term will hang.

intermediate_stuff.md

Intermediate Stuff

Differences between zmq connections and ye olde TCP

• arbitrary transport (inproc, ipc, tcp, pgm or epgm)
• They only exist when a client does zmq_connect to an endpoint (regardless if server has done zmq_bind!!!)
• Have queues that exist in the ether
• Pattern is determined when you create the socket
• One socket can have M-M incoming/outgoing connections
• There is no accept method, it automatically starts accepting messages
• You can't touch connections directly.

The same socket can bind to many endpoints, but you can't bind to the same endpoint twice