Internal Architecture

To build FileMQ I used a lot of code generation, possibly too much for a tutorial. However, the code generators are all reusable in other stacks and will be important for our final project in Chapter 8. They are an evolution of the set we saw earlier:

  • codec_c.gsl generates a message codec for a given protocol.

  • server_c.gsl generates a server class for a protocol and state machine.

  • client_c.gsl generates a client class for a protocol and state machine.

The best way to learn to use GSL code generation is to translate these into a language of your choice and make your own demo protocols and stacks. You’ll find it fairly easy. FileMQ itself doesn’t try to support multiple languages. It could, but it’d make things needlessly complex.

The FileMQ architecture actually slices into two layers. There’s a generic set of classes to handle chunks, directories, files, patches, SASL security, and configuration files. Then, there’s the generated stack: messages, client, and server. If I was creating a new project I’d fork the whole FileMQ project, and go and modify the three models:

  • fmq_msg.xml, which defines the message formats

  • fmq_client.xml, which defines the client state machine, API, and implementation

  • fmq_server.xml, which does the same for the server

You’d want to rename things to avoid confusion. Why didn’t I make the reusable classes into a separate library? The answer is twofold. First, no one actually needs this (yet). Second, it’d make things more complex ...

Get ZeroMQ now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.