After a connection establishment between an MQTT client and Broker, the first packet must be a CONNECT packet. The CONNECT packet must be sent only once over a network connection. The second CONNECT Packet sent from an MQTT Client will be ignored and disconnected.
|byte1||MQTT control packet type (1)||Reserved|
The variable header has to contain four parts
- Protocol name bytes
- Protocol level
- Connect flags
Protocol name bytes
|Byte 1||Length MSB (0)||0||0||0||0||0||0||0||0|
|Byte2||Length LSB (4)||0||0||0||0||0||1||0||0|
A incorrect protocol name will be disconnected by MQTTRoute
The protocol level for the MQTTRoute is 4, other values will lead to disconnection
|User name flag||Password flag||Will retain||Will qos||Will flag||cleansession||reserved|
This field has to mention the presence or absence of data in a payload.
|Byte 9||Keep Alive MSB|
|Byte 10||Keep Alive LSB|
The MQTT client must send the control packets not exceeding the value of defined keepalive. The keep-alive value will depend on the client’s control packet duration of one transmission.
The payload contains the MQTT Client identifiers for the client eg: username, password. The client id must be unique to each client the Broker will respond to the unique client id for each client. Sending client id with an empty field leads to rejection of the client. The following fields must be taken in the following order only Client Identifier, Will Topic, Will Message, User Name, Password. The above fields must be in string format. The packet which does not send CONNECT packet after a reasonable time will be rejected by the Broker. After the above validation success, the Broker will respond in 2 format
- Check whether the client is already present if present the Broker will respond with a disconnection.
- The Broker will send a CONNACK packet with zero value.
After a successful CONNACK, the Broker will do a keepalive monitoring.