ZeroMQ

Design Notes

The hardest part of making FileMQ wasn’t implementing the protocol, but maintaining accurate state internally. An FTP or HTTP server is essentially stateless, but a publish-subscribe server has to maintain subscriptions, at least.

So, I’ll go through some of the design aspects:

• The client detects if the server has died by the lack of heartbeats (HUGZ) coming from the server. It then restarts its dialog by sending an OHAI. There’s no timeout on the OHAI since the ØMQ DEALER socket will queue an outgoing message indefinitely.

• The server detects if a client has died by its lack of response (HUGZ-OK) to a heartbeat. In that case, it deletes all state for the client, including its subscriptions.

• The client API holds subscriptions in memory and replays them when it has connected successfully. This means the caller can subscribe at any time (and doesn’t care when connections and authentication actually happen).

• The server and client use virtual paths, much like an HTTP or FTP server. You publish one or more “mount points,” each corresponding to a directory on the server. Each of these maps to some virtual path; for instance, “/” if you have only one mount point. Clients then subscribe to virtual paths, and files arrive in an inbox directory. We don’t send physical filenames across the network.

• There are some timing issues: if the server is creating its mount points while clients are connected and subscribing, the subscriptions won’t attach to the right mount ...