Definició del protocol
Message headers and its components
MQTT message := Fixed_Header { + Variable_Header } { + Payload } ;
2.1 - Fixed_Header
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | |
byte 1 | Message type | DUP | QoS level | RET |
| | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | Remaining length |
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Message type :
0 = reserved
1 = CONNECT x10
2 = CONNACK x20
3 = PUBLISH x3n
4 = PUBACK x40
5 = PUBREC x50
6 = PUBREL x62
7 = PUBCOMP x70
8 = SUBSCRIBE x82
9 = SUBACK x90
10 = UNSUBSCRIBE xA2
11 = UNSUBACK xB0
12 = PINGREQ xC0
13 = PINGRESP xD0
14 = DISCONNECT xE0
15 = reserved
DUP flag : set when an attempt to redeliver PUBLISH, PUREL, SUBSCRIBE or UNSUBSCRIBE message.
Applies to messages where QoS is greater than zero and an acknowledgement is required.
QoS level : indicates the level of assurance for delivery of a PUBLISH message.
Retain : used on PUBLISH messages, indicates the server should hold on the message after it has been delivered to the subscribers.
Remaining length : number of bytes remaining within the current message.
2.2 - Variable header
- Protocol name
- Protocol version
- Connect flags
- Clean session flag
- Will flag
- Will QoS
- Will Retain flag
- User name and password flags
- Keep Alive timer
- Connect return code
- Topic name
7 6 5 4 3 2 1 0
+---------+---------+---------+---------+---------+---------+---------+---------+
| user | pwd | will | will | will | clean | |
byte 1 | name | flag | retain | QoS | flag | session| n.u. |
| flag | | | | | flag | |
+---------+---------+---------+---------+---------+---------+---------+---------+
Clean Session Flag - bit 1 of the Connect Flags byte.
If not set (0), then the server must store the subscriptions of the client after it disconnects.
If set (1), then the server must discard any previously maintained information about the client
and treat the connection as "clean".
The server must also discard any state when the client disconnects.
Clean sessions
url
Wills
When a client connects to a broker, it may inform the broker that it has a will.
This is a message that it wishes the broker to send when the client disconnects unexpectedly.
The will message has a topic, QoS and retain status just the same as any other message.
url
2.2.9 - Keep Alive timer
The Keep Alive timer, measured in seconds, defines the maximum time interval between messages received from a client.
It enables the server to detect that the network connection to a client has dropped, without having to wait for the long TCP/IP timeout.
The client has a responsibility to send a message within each Keep Alive time period.
In the absence of a data-related message during the time period, the client sends a PINGREQ message, which the server acknowledges with a PINGRESP message.
If the server does not receive a message from the client within one and a half times the Keep Alive time period
(the client is allowed "grace" of half a time period),
it disconnects the client as if the client had sent a DISCONNECT message.
This action does not impact any of the client's subscriptions.
If a client does not receive a PINGRESP message within a Keep Alive time period after sending a PINGREQ,
it should close the TCP/IP socket connection.
The Keep Alive timer is a 16-bit value that represents the number of seconds for the time period.
The actual value is application-specific, but a typical value is a few minutes.
The maximum value is approximately 18 hours.
A value of zero (0) means the client is not disconnected.
2.2.11 - Topic name
The topic name is the key that identifies the information channel to which payload data is published.
Subscribers use the key to identify the information channels on which they want to receive published information.
The topic name is a UTF-encoded string.
2.3 - Payload
- CONNECT : one or more UTF-8 strings
- unique identifier
- will topic
- user name and password
- SUBSCRIBE : a list of topic names to which the client can subscribe
- SUBACK : list of granted QoS levels.
2.4 - Message Identifier
Present in PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK.
Present only in messages where QoS is 1 or 2.
16-bit integer that must be unique amongst the set of "in flight" messages
Do not use Message ID 0 - it is reserved as an invalid Message ID.
2.5 - UTF-8
In MQTT, strings are prefixed with 2 bytes to denote the length, indicating the number of bytes,
not the number of characters.
3 - Command messages
3.1 - CONNECT - client requests a connection to a server
When a TCP/IP socket connection is established from a client to a server,
a protocol level session must be created using a CONNECT flow.
Fixed Header :
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | |
byte 1 | 0 0 0 1 | 0 | 0 0 | 0 | MsgType (1)
| | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | Remaining length | 12 + payload length
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
The DUP, QoS, and RETAIN flags are not used in the CONNECT message.
Variable header = protocol name + protocol version + connect flags + keep alive timer ;
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 1 | 0 0 0 0 0 0 0 0 | Length MSB (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 1 1 0 | Length LSB (6)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 3 | 0 1 0 0 1 1 0 1 | "M"
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 4 | 0 1 0 1 0 0 0 1 | "Q"
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 5 | 0 1 0 0 1 0 0 1 | "I"
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 6 | 0 1 1 1 0 0 1 1 | "s"
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 7 | 0 1 1 0 0 1 0 0 | "d"
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 8 | 0 1 1 1 0 0 0 0 | "p"
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 9 | 0 1 0 0 0 0 1 1 | Protocol version (3)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 10 | 1 1 0 0 1 1 1 0 | Connect flags
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 11 | 0 0 0 0 0 0 0 0 | Keep Alive timer MSB (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 12 | 0 0 0 0 1 0 1 0 | Keep Alive timer LSB (10)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Payload - The payload of the CONNECT message contains one or more UTF-8 encoded strings, based on the flags in the variable header.
3.2 - CONNACK - Acknowledge connection request
The CONNACK message is the message sent by the server in response to a CONNECT request from a client.
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Fixed header
| | |
byte 1 | 0 0 1 0 | 0 0 0 0 | Message type (2)
| | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 1 0 | Remaining length (2)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+ Variable header
| |
byte 3 | 0 0 0 0 0 0 0 0 | Not used (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 4 | n n n n n n n n | Return code
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
The DUP, QoS and RETAIN flags are not used in the CONNACK message.
Values for Connect return code :
- x'00 - connection accepted
- x'01 - connection refused : unacceptabe protocol version
- x'02 - connection refused : identifier rejected
- x'03 - connection refused : server unavailable
- x'04 - connection refused : bad user name or password
- x'05 - connection refused : not authorized
- 6-255 - reserved for future use
3.3 - PUBLISH - Publish message
A PUBLISH message is sent by a client to a server for distribution to interested subscribers.
Each PUBLISH message is associated with a topic name (also known as the Subject or Channel).
This is a hierarchical name space that defines a taxonomy of information sources
for which subscribers can register an interest.
A message that is published to a specific topic name is delivered to connected subscribers for that topic.
Fixed Header :
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | |
byte 1 | 0 0 1 1 | 0 | 0 1 | 0 | MsgType (3), DUP (0), QoS (1), RET (0)
| | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | Remaining length | variable header length + payload length
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Variable header = topic name ("a/b") + Message ID (10) ;
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Topic Name
| |
byte 1 | 0 0 0 0 0 0 0 0 | Length MSB (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 1 1 | Length LSB (3)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 3 | 0 1 1 0 0 0 0 1 | "a", x'61
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 4 | 0 0 1 0 1 1 1 1 | "/", x'2F
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 5 | 0 1 1 0 0 0 1 0 | "b", x'62
| |
+-----+-----+-----+-----+-----+-----+-----+-----+ Message Identifier
| |
byte 6 | 0 0 0 0 0 0 0 0 | MSB (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 7 | 0 0 0 0 1 0 1 0 | MSB (10)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Payload - Contains the data for publishing.
The content and format of the data is application specific.
The Remaining Length field in the fixed header includes both the variable header length and the payload length.
As such, it is valid for a PUBLISH to contain a 0-length payload.
Response
PUBLISH messages can be sent either from a publisher to the server, or from the server to a subscriber.
The action of the recipient when it receives a message depends on the QoS level of the message:
- QoS = 0 -> Expected response = none ;
- QoS = 1 -> Expected response = PUBACK ;
- QoS = 2 -> Expected response = PUBREC ;
3.4 - PUBACK - Publish acknowledgment
A PUBACK message is the response to a PUBLISH message with QoS level 1.
A PUBACK message is sent by a server in response to a PUBLISH message from a publishing client,
and by a subscriber in response to a PUBLISH message from the server.
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Fixed header
| | |
byte 1 | 0 1 0 0 | 0 0 0 0 | Message type (4)
| | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 1 0 | Remaining length (2)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+ Variable header
| |
byte 3 | n n n n n n n n | Message ID MSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 4 | n n n n n n n n | Message ID LSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
The DUP, QoS and RETAIN flags are not used in the PUBACK message.
3.5 - PUBREC - Assured publish received (part 1)
A PUBREC message is the response to a PUBLISH message with QoS level 2.
It is the second message of the QoS level 2 protocol flow.
A PUBREC message is sent by the server in response to a PUBLISH message from a publishing client,
or by a subscriber in response to a PUBLISH message from the server.
When a PUBREC message is received, the recipient sends a PUBREL message to the sender with the same Message ID as the PUBREC message.
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Fixed header
| | |
byte 1 | 0 1 0 1 | 0 0 0 0 | Message type (5)
| | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 1 0 | Remaining length (2)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+ Variable header
| |
byte 3 | n n n n n n n n | Message ID MSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 4 | n n n n n n n n | Message ID LSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
The DUP, QoS and RETAIN flags are not used in the PUBACK message.
3.6 - PUBREL - Assured Publish Release (part 2)
A PUBREL message is the response either from a publisher to a PUBREC message from the server,
or from the server to a PUBREC message from a subscriber.
It is the third message in the QoS 2 protocol flow.
When the server receives a PUBREL message from a publisher,
the server makes the original message available to interested subscribers,
and sends a PUBCOMP message with the same Message ID to the publisher.
When a subscriber receives a PUBREL message from the server,
the subscriber makes the message available to the subscribing application
and sends a PUBCOMP message to the server.
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Fixed header
| | |
byte 1 | 0 1 1 0 | 0 0 1 0 | Message type (6)
| | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 1 0 | Remaining length (2)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+ Variable header
| |
byte 3 | n n n n n n n n | Message ID MSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 4 | n n n n n n n n | Message ID LSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
PUBREL messages use QoS level 1 as an acknowledgement is expected in the form of a PUBCOMP.
DUP flag set to zer meaning message is being sent for the first time
RETAIN not used.
3.7 - PUBCOMP - Assured publish complete (part 3)
This message is either the response from the server to a PUBREL message from a publisher,
or the response from a subscriber to a PUBREL message from the server.
It is the fourth and last message in the QoS 2 protocol flow.
When the client receives a PUBCOMP message, it discards the original message
because it has been delivered, exactly once, to the server.
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Fixed header
| | |
byte 1 | 0 1 1 1 | 0 0 0 0 | Message type (7)
| | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 1 0 | Remaining length (2)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+ Variable header
| |
byte 3 | n n n n n n n n | Message ID MSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 4 | n n n n n n n n | Message ID LSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
The DUP, QoS and RETAIN flags are not used in the PUBCOMP message.
3.8 - SUBSCRIBE - Subscribe to named topics
The SUBSCRIBE message allows a client to register an interest in one or more topic names with the server.
Messages published to these topics are delivered from the server to the client as PUBLISH messages.
The SUBSCRIBE message also specifies the QoS level at which the subscriber wants to receive published messages.
Note that if a server implementation does not authorize a SUBSCRIBE request to be made by a client,
it has no way of informing that client.
It must therefore make a positive acknowledgement with a SUBACK,
and the client will not be informed that it was not authorized to subscribe.
Fixed Header :
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | | |
byte 1 | 1 0 0 0 | 0 | n n | 0 | MsgType (8), QoS (N)
| | | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | Remaining length | variable header length + payload length
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
SUBSCRIBE messages use QoS level 1 to acknowledge multiple subscription requests.
The corresponding SUBACK message is identified by matching the Message ID.
DUP flag set to zer meaning message is being sent for the first time
RETAIN not used.
Variable header = message ID (if QoS > 0)
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 3 | n n n n n n n n | Message ID MSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 4 | n n n n n n n n | Message ID LSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Payload - Contains the data for publishing.
The payload of a SUBSCRIBE message contains a list of topic names to which the client wants to subscribe,
and the QoS level at which the client wants to receive the messages.
The strings are UTF-encoded, and the QoS level occupies 2 bits of a single byte.
Sample for topic "a/b", QoS=1 and topic "c/d", QoS=2 :
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Topic Name
| |
byte 1 | 0 0 0 0 0 0 0 0 | Length MSB (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 1 1 | Length LSB (3)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 3 | 0 1 1 0 0 0 0 1 | "a", x'61
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 4 | 0 0 1 0 1 1 1 1 | "/", x'2F
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 5 | 0 1 1 0 0 0 1 0 | "b", x'62
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 6 | 0 0 0 0 0 0 0 1 | QoS (1)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 7 | 0 0 0 0 0 0 0 0 | Length MSB (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 8 | 0 0 0 0 0 0 1 1 | Length LSB (3)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 9 | 0 1 1 0 0 0 1 1 | "c", x'63
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 10 | 0 0 1 0 1 1 1 1 | "/", x'2F
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 11 | 0 1 1 0 0 1 0 0 | "d", x'64
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 12 | 0 0 0 0 0 0 1 0 | QoS (2)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.9 - SUBACK - Subscription acknowledgement
A SUBACK message is sent by the server to the client to confirm receipt of a SUBSCRIBE message.
A SUBACK message contains a list of granted QoS levels.
The order of granted QoS levels in the SUBACK message matches the order of the topic names in the corresponding SUBSCRIBE message.
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Fixed header
| | |
byte 1 | 1 0 0 1 | 0 0 0 0 | Message type (9)
| | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | n n n n n n n n | Remaining length (n)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
The DUP, QoS and RETAIN flags are not used in the SUBACK message.
Variable header = message ID
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 1 | n n n n n n n n | Message ID MSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | n n n n n n n n | Message ID LSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Payload = granted QoS's
In our sample :
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 1 | 0 0 0 0 0 0 0 0 | QoS (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 1 0 | QoS (2)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.10 - UNSUBSCRIBE - Unsubscribe from named topics
An UNSUBSCRIBE message is sent by the client to the server to unsubscribe from named topics.
UNSUBSCRIBE messages use QoS level 1 to acknowledge multiple unsubscribe requests.
The corresponding UNSUBACK message is identified by the Message ID.
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Fixed header
| | |
byte 1 | 1 0 1 0 | 0 0 1 0 | Message type (10), QoS (1)
| | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | n n n n n n n n | Remaining length (n)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
UNSUBSCRIBE messages use QoS level 1 to acknowledge multiple unsubscribe requests.
The corresponding UNSUBACK message is identified by the Message ID.
DUP flag set to zer meaning message is being sent for the first time
RETAIN not used.
Variable header = message ID
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 1 | n n n n n n n n | Message ID MSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | n n n n n n n n | Message ID LSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
Payload
The client unsubscribes from the list of topics named in the payload.
The strings are UTF-encoded and are packed contiguously.
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Topic Name(s)
| |
byte 1 | 0 0 0 0 0 0 0 0 | Length MSB (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 1 1 | Length LSB (3)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 3 | 0 1 1 0 0 0 0 1 | "a", x'61
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 4 | 0 0 1 0 1 1 1 1 | "/", x'2F
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 5 | 0 1 1 0 0 0 1 0 | "b", x'62
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 6 | 0 0 0 0 0 0 0 0 | Length MSB (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 7 | 0 0 0 0 0 0 1 1 | Length LSB (3)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 8 | 0 1 1 0 0 0 1 1 | "c", x'63
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 9 | 0 0 1 0 1 1 1 1 | "/", x'2F
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 10 | 0 1 1 0 0 1 0 0 | "d", x'64
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
3.11 - UNSUBACK - Unsubscribe acknowledgment
The UNSUBACK message is sent by the server to the client to confirm receipt of an UNSUBSCRIBE message.
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Fixed header
| | |
byte 1 | 1 0 1 1 | 0 0 0 0 | Message type (11)
| | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 1 0 | Remaining length (2)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+ Variable header
| |
byte 3 | n n n n n n n n | Message ID MSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 4 | n n n n n n n n | Message ID LSB
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
The DUP, QoS and RETAIN flags are not used in the UNSUBACK message.
3.12 - PINGREQ - PING request
The PINGREQ message is an "are you alive?" message that is sent from a connected client to the server.
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Fixed header
| | |
byte 1 | 1 1 0 0 | 0 0 0 0 | Message type (12)
| | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 0 0 | Remaining length (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
The DUP, QoS and RETAIN flags are not used in the PINGREQ message.
3.13 - PINGRESP - PING response
A PINGRESP message is the response sent by a server to a PINGREQ message and means "yes I am alive".
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Fixed header
| | |
byte 1 | 1 1 0 1 | 0 0 0 0 | Message type (13)
| | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 0 0 | Remaining length (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
The DUP, QoS and RETAIN flags are not used in the PINGRESP message.
3.14 - DISCONNECT - Disconnect notification
The DISCONNECT message is sent from the client to the server to indicate that it is about to close its TCP/IP connection.
This allows for a clean disconnection, rather than just dropping the line.
If the client had connected with the clean session flag set,
then all previously maintained information about the client will be discarded.
A server should not rely on the client to close the TCP/IP connection after receiving a DISCONNECT.
7 6 5 4 3 2 1 0
+-----+-----+-----+-----+-----+-----+-----+-----+ Fixed header
| | |
byte 1 | 1 1 1 0 | 0 0 0 0 | Message type (14)
| | |
+-----+-----+-----+-----+-----+-----+-----+-----+
| |
byte 2 | 0 0 0 0 0 0 0 0 | Remaining length (0)
| |
+-----+-----+-----+-----+-----+-----+-----+-----+
The DUP, QoS and RETAIN flags are not used in the DISCONNECT message.
mosquitto bites
http://mosquitto.org - open source message broker that implements the MQ Telemetry Transport protocol version 3.1.
docu :
Mosquitto is an Open Source MQTT v3.1 message broker written by Roger Light.
It aims to provide the same features (and more) as IBM's Really Small Message Broker but as fully Open Source software.
. . .
Included with Mosquitto are two basic command line clients: mosquitto_pub and mosquitto_sub.
Download
If we use win32 install, then mosquitto.exe requires "WSAPoll() entry in WS2_32.DLL" => use CYGWIN for server.
Fixed on version 1.1.11 : use win32 !
Pel servidor ens cal instalar
cygwim
o tenim
c:\Program Files\mosquitto> mosquitto.exe
"tty" option detected in CYGWIN environment variable.
CYGWIN=tty is no longer supported.
Please remove it from your CYGWIN environment variable and use a terminal emulator like mintty, xterm, or rxvt.
Mosquitto project information is available at the following locations:
Support
Under Windows 7 Enterprise SP1 (64-bit) we get:
The application was unable to start Correctly (0xc0150002)
I send a question to
support [u/k] : "VC90.CRT problem"
install "Microsoft Visual C++ 2008 SP1 Redistributable Package (x86)" under
w7
mosquitto_sub
mosquitto_sub is a simple mqtt client that will subscribe to a single topic and print all messages it receives.
Usage: mosquitto_sub [-c] [-h host] [-k keepalive] [-p port] [-q qos] [-v] -t topic ...
[-i id] [-I id_prefix]
[-d] [--quiet]
[-u username [-P password]]
[--will-topic [--will-payload payload] [--will-qos qos] [--will-retain]]
[{--cafile file | --capath dir} [--cert file] [--key file]]
[--psk hex-key --psk-identity identity]
mosquitto_sub --help
-c : disable 'clean session' (store subscription and pending messages when client disconnects).
-d : enable debug messages.
-h : mqtt host to connect to. Defaults to localhost.
-i : id to use for this client. Defaults to mosquitto_sub_ appended with the process id.
-I : define the client id as id_prefix appended with the process id.
Useful for when the broker is using the clientid_prefixes option.
-k : keep alive in seconds for this client. Defaults to 60.
-p : network port to connect to. Defaults to 1883.
-q : quality of service level to use for the subscription. Defaults to 0.
-t : mqtt topic to subscribe to. May be repeated multiple times.
-u : provide a username (requires MQTT 3.1 broker)
-v : print published messages verbosely.
-P : provide a password (requires MQTT 3.1 broker)
--help : display this message.
--quiet : don't print error messages.
--will-payload : payload for the client Will, which is sent by the broker in case of unexpected disconnection.
If not given and will-topic is set, a zero length message will be sent.
--will-qos : QoS level for the client Will.
--will-retain : if given, make the client Will retained.
--will-topic : the topic on which to publish the client Will.
--cafile : path to a file containing trusted CA certificates to enable encrypted certificate based communication.
--capath : path to a directory containing trusted CA certificates to enable encrypted communication.
--cert : client certificate for authentication, if required by server.
--key : client private key for authentication, if required by server.
--psk : pre-shared-key in hexadecimal (no leading 0x) to enable TLS-PSK mode.
--psk-identity : client identity string for TLS-PSK mode.
mosquitto_pub
mosquitto_pub is a simple mqtt client that will publish a message on a single topic and exit.
Minimal required files (2,3 MB) :
- libeay32.dll
- mosquitto.dll
- mosquitto_pub.exe
- msvcr100.dll
- pthreadVC2.dll
- ssleay32.dll
Usage: mosquitto_pub [-h host] [-p port] [-q qos] [-r] {-f file | -l | -n | -m message} -t topic
[-i id] [-I id_prefix]
[-d] [--quiet]
[-u username [-P password]]
[--will-topic [--will-payload payload] [--will-qos qos] [--will-retain]]
[{--cafile file | --capath dir} [--cert file] [--key file]]
[--psk hex-key --psk-identity identity]
mosquitto_pub --help
-d : enable debug messages
-f : send the contents of a file as the message
-h : mqtt host to connect to. Defaults to localhost
-i : id to use for this client. Defaults to mosquitto_pub_ appended with the process id
-I : define the client id as id_prefix appended with the process id. Useful for when the broker is using the clientid_prefixes option
-l : read messages from stdin, sending a separate message for each line
-m : message payload to send
-n : send a null (zero length) message
-p : network port to connect to - defaults to 1883
-q : quality of service level to use for all messages - defaults to 0
-r : message should be retained
-s : read message from stdin, sending the entire input as a message
-t : mqtt topic to publish to
-u : provide a username (requires MQTT 3.1 broker)
-P : provide a password (requires MQTT 3.1 broker)
--help : display this message
--quiet : don't print error messages
--will-payload : payload for the client Will, which is sent by the broker in case of unexpected disconnection
If not given and will-topic is set, a zero length message will be sent
--will-qos : QoS level for the client Will
--will-retain : if given, make the client Will retained
--will-topic : the topic on which to publish the client Will
--cafile : path to a file containing trusted CA certificates to enable encrypted communication
--capath : path to a directory containing trusted CA certificates to enable encrypted communication
--cert : client certificate for authentication, if required by server
--key : client private key for authentication, if required by server
--psk : pre-shared-key in hexadecimal (no leading 0x) to enable TLS-PSK mode
--psk-identity : client identity string for TLS-PSK mode
task pub @ win
On win we shall use
c:\TT2> type task_pub.cmd
@echo off
SET MSGID=visc.TT2.mpc.v1a
SET MYHOST=99.137.164.25
SET MYQOS=0
SET MYTOPIC=visc/monit/pcs
SET MYID=mosquitto_pubTASK_client
set mydate=Y%date:~6,4%/M%date:~3,2%/D%date:~0,2%
set mytime=H%time:~0,2%:M%time:~3,2%
set MYHN=%COMPUTERNAME%
for /f "tokens=1 delims=:" %%j in ('ping %computername% -4 -n 1 ^| findstr Reply') do (
set localip=%%j
)
set myip=%localip:~11%
SET MYMSG="%MSGID% %MYHN% %myip% %mydate% %mytime%"
c:\mqtt\mosquitto_pub.exe -h %MYHOST% -q %MYQOS% -t %MYTOPIC% -i %MYID% -m %MYMSG%
And we get
visc.TT2.mpc.v1a RACRIM12 99.137.164.25 Y2012/M11/D29 H11:M45
mosquitto_pub @ RH-64b
For
RH
we have:
The available packages are: mosquitto, mosquitto-pub, mosquitto-sub, libmosquitto0, libmosquitto-devel, libmosquittopp0, libmosquittopp-devel, python-mosquitto.
So, we go
[root@rhv6-64b yum.repos.d]# yum install --enablerepo=home_oojah_mqtt mosquitto
Loaded plugins: product-id, refresh-packagekit, subscription-manager
Updating Red Hat repositories.
home_oojah_mqtt | 1.3 kB 00:00
home_oojah_mqtt/primary | 3.0 kB 00:00
home_oojah_mqtt 17/17
rhel-source-beta | 1.3 kB 00:00
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package mosquitto.x86_64 0:1.0.5-2.1 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
==============================================================================================================================
Package Arch Version Repository Size
==============================================================================================================================
Installing:
mosquitto x86_64 1.0.5-2.1 home_oojah_mqtt 84 k
Transaction Summary
==============================================================================================================================
Install 1 Package(s)
Total download size: 84 k
Installed size: 182 k
Is this ok [y/N]: y
Downloading Packages:
mosquitto-1.0.5-2.1.x86_64.rpm | 84 kB 00:00
warning: rpmts_HdrFromFdno: Header V3 DSA/SHA1 Signature, key ID 49e1d0b1: NOKEY
Retrieving key from http://download.opensuse.org/repositories/home:/oojah:/mqtt/RedHat_RHEL-6/repodata/repomd.xml.key
Importing GPG key 0x49E1D0B1:
Userid: "home:oojah OBS Project "
From : http://download.opensuse.org/repositories/home:/oojah:/mqtt/RedHat_RHEL-6/repodata/repomd.xml.key
Is this ok [y/N]: y
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Warning: RPMDB altered outside of yum.
Installing : mosquitto-1.0.5-2.1.x86_64 1/1
duration: 585(ms)
Installed products updated.
Installed:
mosquitto.x86_64 0:1.0.5-2.1
Complete!
Malauradament ...
[root@rhv6-64b yum.repos.d]# yum install --enablerepo=home_oojah_mqtt mosquitto-pub
Loaded plugins: product-id, refresh-packagekit, subscription-manager
Updating Red Hat repositories.
Setting up Install Process
No package mosquitto-pub available.
Error: Nothing to do
En canvi, va be
[root@rhv6-64b mqtt]# yum install --enablerepo=home_oojah_mqtt python-mosquitto
Solució, by Roger Light :
[root@rhv6-64b mqtt]# yum install --enablerepo=home_oojah_mqtt mosquitto-clients
. . .
Installed:
mosquitto-clients.x86_64 0:1.0.5-2.1
Dependency Installed:
libmosquitto1.x86_64 0:1.0.5-2.1
Complete!
Ara tenim els clients :
[root@rhv6-64b ~]# find / mosquitto -print | grep mosquitto_pub
/usr/bin/mosquitto_pub
I tambe el servidor :
[root@rhv6-64b /usr/sbin]# ls -al mos*
-rwxr-xr-x. 1 root root 118480 Nov 3 13:30 mosquitto
task pub @ RH-64b
Alguna idea de
aqui
[sebas@rhv6-64b /home/sebas/cmds/mqtt]$ cat do_pub.sh
#!/bin/bash -x
myhost="99.137.164.25"
myqos="0"
mytopic="visc/monit/pcs"
myid="mosquitto_pubTASK_client"
mymsgid="visc.TT2.mpc.v1a"
myhn=$HOSTNAME
myip="$(/sbin/ifconfig eth0 | grep 'inet addr:9' | cut -d: -f2 | awk '{ print $1}')"
mydate=`date +"%y/%m/%d"`
mytime=`date +"%H:%M"`
mymsg="$mymsgid $myhn $myip $mydate $mytime"
echo "MyMsg={" $mymsg "}."
mosquitto_pub -h $myhost -q $myqos -t $mytopic -i $myid -m "$mymsg"
Ho programem per fer-se cada 15 minuts :
[sebas@rhv6-64b mqtt]$ cat cron_task
#############################################################
# minute (0-59), #
# | hora (0-23), #
# | | dia del mes (1-31), #
# | | | mes (1-12), #
# | | | | dia de la semana (0-6 donde 0=Domingo) #
# | | | | | comandos #
#############################################################
*/15 9-17 * * 1-5 /home/sebas/cmds/mqtt/do_pub.sh >> /home/sebas/cmds/mqtt/cron_task.out
I ho engeguem :
[root@rhv6-64b ~]# crontab -u sebas cron_task
[root@rhv6-64b ~]# service crond restart
Stopping crond: [ OK ]
Starting crond: [ OK ]
Conclusió : tenim mosquitto server i client al RH-64b v6.1
mosquitto_pub @ RHEL v4
[sebas@labss2 /home/sebas/soft/mosquitto/mosquitto-1.0.5]$ make
cc mosquitto.o bridge.o conf.o context.o database.o logging.o loop.o memory_mosq.o persist.o net.o
net_mosq.o read_handle.o read_handle_client.o read_handle_server.o read_handle_shared.o
security.o security_default.o send_client_mosq.o send_mosq.o send_server.o service.o subs.o
util_mosq.o will_mosq.o -o mosquitto -ldl -lssl -lcrypto
net.o(.text+0x7ad): In function `mqtt3_socket_listen':
/home/sebas/soft/mosquitto/mosquitto-1.0.5/src/net.c:433: undefined reference to `SSL_CTX_set_psk_server_callback'
net.o(.text+0x801):/home/sebas/soft/mosquitto/mosquitto-1.0.5/src/net.c:435: undefined reference to `SSL_CTX_use_psk_identity_hint'
net_mosq.o(.text+0x4a3): In function `_mosquitto_socket_connect':
../lib/net_mosq.c:388: undefined reference to `SSL_CTX_set_psk_client_callback'
collect2: ld returned 1 exit status
make[1]: *** [mosquitto] Error 1
make[1]: Leaving directory `/home/sebas/soft/mosquitto/mosquitto-1.0.5/src'
make: *** [mosquitto] Error 2
Solucio : "make WITH_TLS_PSK=no"
Sorry, same error.
mosquitto_pub @ SLES 10 @ rug
Verify server status :
p7029-6E3:~ # rczmd status
Checking for ZENworks Management Daemon: running
p7029-6E3:~ # rug sa --type=yum http://download.opensuse.org/repositories/home:/oojah:/mqtt/SLE_10_SDK/ mosquitto
Adding YUM service http://download.opensuse.org/repositories/home:/oojah:/mqtt/SLE_10_SDK/...
100%, 169.0 byte/s
Successfully added service 'http://download.opensuse.org/repositories/home:/oojah:/mqtt/SLE_10_SDK/'
p7029-6E3:~ #
p7029-6E3:~ # rug subscribe mosquitto
Subscribed to 'mosquitto'
p7029-6E3:~ #
p7029-6E3:~ # rug in mosquitto-pub
ERROR: 'mosquitto-pub' is not available, or is fully up-to-date.
p7029-6E3:~ #
p7029-6E3:~ # rug catalogs
Sub'd? | Name | Service
-------+-------------------------------------------------------+------------------------------------------------------
Yes | SUSE-Linux-Enterprise-Server-ppc-10-0-20100827-072721 | SUSE-Linux-Enterprise-Server-ppc-10-0-20100827-072721
Yes | 19710129-062141 | 19710129-062141
Yes | mosquitto | mosquitto
p7029-6E3:~ # rug pa mosquitto
S | Catalog | Bundle | Name | Version | Arch
--+-----------+--------+------+---------+-------
| mosquitto | | | - | noarch
url
Un altre intent :
p7029-6E3:/home/sebas/soft/mosquitto # rpm -ivh ./mosquitto-0.15-4.1.src.rpm
warning: ./mosquitto-0.15-4.1.src.rpm: Header V3 DSA signature: NOKEY, key ID 49e1d0b1
1:mosquitto ########################################### [100%]
p7029-6E3:/home/sebas/soft/mosquitto # rpm -qpl ./mosquitto-0.15-4.1.src.rpm
warning: ./mosquitto-0.15-4.1.src.rpm: Header V3 DSA signature: NOKEY, key ID 49e1d0b1
disable-python.patch
mosquitto-0.15.tar.gz
mosquitto.apparmor
mosquitto.conf.patch
mosquitto.fw
mosquitto.init.d.suse
mosquitto.spec
p7029-6E3:/usr/src/packages/SOURCES/mosquitto-0.15 # tar -xvzf mosquitto-0.15.tar.gz
p7029-6E3:/usr/src/packages/SOURCES/mosquitto-0.15 # make
. . .
gcc mosquitto.o bridge.o conf.o context.o database.o logging.o loop.o memory_mosq.o persist.o net.o net_mosq.o \\
read_handle.o read_handle_client.o read_handle_server.o read_handle_shared.o security.o security_external.o \\
send_client_mosq.o send_mosq.o send_server.o service.o subs.o util_mosq.o will_mosq.o -o mosquitto
make[1]: Leaving directory `/usr/src/packages/SOURCES/mosquitto-0.15/src'
make[1]: Entering directory `/usr/src/packages/SOURCES/mosquitto-0.15/man'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/src/packages/SOURCES/mosquitto-0.15/man'
p7029-6E3:/usr/src/packages/SOURCES/mosquitto-0.15/src # ./mosquitto /?
Error: Unknown option '/?'.
mosquitto is an MQTT v3.1 broker.
Usage: mosquitto [-c config_file] [-d] [-h] [-p port]
-c : specify the broker config file.
-d : put the broker into the background after starting.
-h : display this help.
-p : start the broker listening on the specified port.
Not recommended in conjunction with the -c option.
See http://mosquitto.org/ for more information.
p7029-6E3:/usr/src/packages/SOURCES/mosquitto-0.15/src # ./mosquitto
1354208268: Warning: Mosquitto should not be run as root/administrator.
1354208268: mosquitto version 0.15 (build date 2012-11-29 17:41:06+0100) starting
1354208268: Opening ipv6 listen socket on port 1883.
1354208268: Opening ipv4 listen socket on port 1883.
Conclusió : tenim mosquitto server al SLES 10 (p7029)
