francois-normandin
commented
4 years ago I'll make the graphics better for the final doc, but here is the message path for a PUBLISH message and the PUBACK reply.
The top depicts the client publishing a payload to the server. The bottom depicts a server publishing a payload to a particular client, when it matches an active subscription.
As you can see, the paths are completely symmetric, which is the basis for choosing the architecture where both the client and the server inherit from the MQTT Base class, and both client and server share a common "Session" class that acts as a mediator for the transport layer.
The session itself is composed of a Connection, which decouples the transport protocol from the session itself.
The difference between a client and a server thus resides almost entirely in the extra ability of the server to maintain multiple sessions as well as a subscription engine to route the matching packets to their destinations.
Server and Client establish a connection. By doing so, they each spawn a distinct session process for each connection. Create flow diagrams of the steps and messages exchanged by processes to act on Control Packets being sent and received. Include as many atomic steps, such as validation and handling of packets. This should help developers maintain as much reciprocity as possible in the actor model between server and client, and also keep track of where the messages flow. Knowledge of the flow of messages will help identify where to add or modify a feature of the broker/client.