MQTT standard supports bi-directional messaging to uniformly handle both signals and commands, deterministic message delivery, basic QoS levels, always/sometimes-connected scenarios, loose coupling, and scalability to support large numbers of devices. The MQTT clients and the broker communicate with each other in the form of control packets defined as per specification.
Fiorano initially proposes to productize MQTT package separately and also embed into FioranoMQ Server. Therefore, an MQTT-RTL from Fiorano would also support MQTT broker functionalities as well as client specifications.
When MQTT is embeded inside FioranoMQ server, it is decided that MQTT clients are accepted on separate port other than the JMS connections port. Therefore, the existing FioranoMQ's Connection manager is extended to accept MQTT client connections on a different port.
MQTT Packet Structure
The MQTT protocol works by exchanging a series of Control Packets in a defined way. There are fourteen types of Packets as specified by OASIS standard. Application messages are carried through the 'Publish' packet. Structure of an MQTT packet comprises of Fixed Header, Variable Header, and Payload:
Fixed Header
The fixed header can contain at-most five bytes, the , 4 to 7 bits in the first byte denote the Control Packet Type and 3 to 0 are reserved for other flags (such as DUP, Qos, Retain). The length of the encoded data starts from byte 2 and up to byte 5, which denotes length of Variable Header and the Payload data.Variable Header
The variable header component of many Control packet types include a 2 byte Packet Identifier field, such as PUBLISH (Qos > 0), PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, mostly the message carrying packets.PayLoad
The final part of a Control packet is the payload and is required only in few types of control packets such as PUBLISH, where application message is the payload.
CONNECT Packet
- Client requests a connection with the Server using Connect Packet.
- Each Connect packet must provide a unique Client Identifier.
- Variable Header of 10 bytes, Protocol Name, Protocol Level, Connect Flags, and Keep Alive.
- Each Connection is associated with a Session and the Session state is stored in the Client and the Server. Session State consists of:
- Client: QOS1 and QOS2 messages
- Server: the session, client subscriptions, and QOS1, QOS2 messages etc.