3.3 released - PUBLISH news release
PUBLISH control packet sent from the client to the server or from the server to the client application messages for transmission.
Fixed 3.3.1 Fixed header title
FIG 3.10 - PUBLISH fixed packet headers fixed header format described:
FIG 3.10 - PUBLISH fixed packet header
| Place |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
| Byte 1 |
MQTT control packet type (3) |
DUP flag |
QoS level |
Retention |
||||
|
|
0 |
0 |
1 |
1 |
X |
X |
X |
X |
| Byte 2 |
The remaining length |
|||||||
Location: Byte 1, bit 3.
If the DUP flag is set to 0, it means that this is the first time the client or server tries to send this MQTT PUBLISH packet. If the DUP flag is set to 1, then this may be the previous attempt redelivery to send data packets.
When the client or the server tries to resend the packet PUBLISH [MQTT-3.3.1.-1] when, DUP flag must be set to 1. For all the QoS 0 messages [the MQTT-3.3.1-2] , the DUP flag must be set to 0.
When PUBLISH packet sent by the server to a subscriber, it does not spread values from the incoming data packet PUBLISH flag DUP. DUP PUBLISH flag output data packet independent of the input data packet PUBLISH set, its value must be output only by whether the data packet is retransmitted PUBLISH [MQTT-3.3.1-3] determined .
Non-normative Comments
Comprising DUP flag is set to control packet receiver 1 can not assume that it has seen the early copy of the data packet.
Non-normative Comments
Be sure to note, DUP sign refers to the control packet itself, not the application message it contains. When the QoS 1, the client may receive DUP PUBLISH packet flag is set to 0, the data comprising a previously received application message is repeated but with different packet identifiers. Section 2.3.1 provides more information on packet identifier.
Location: byte 1, bits 2-1.
This field indicates the level of guaranteed delivery of application messages. QoS level listed in 3.2 table - QoS definitions in.
| QoS value |
The first two |
No. 1 |
description |
| 0 |
0 |
0 |
At most once delivered |
| 1 |
0 |
1 |
At least one delivery |
| 2 |
1 |
0 |
Complete primary issue |
| - |
1 |
1 |
Reserved - do not use |
Publish QoS packet can not be two bits are set to 1. If the server or the client receives two bits are set to PUBLISH QoS packet 1, network connections must close it [the MQTT-3.3.1-4] .
Location: Byte 1, bit 0.
Sent to the server in a client PUBLISH packet, if the RETAIN flag is set to 1, the server must store application messages and QoS, in order to pay their subscription to match the name of its theme of future subscribers [MQTT- 3.3.1- 5] . When creating a new subscription must be reserved for each match last message subject name (if any) is sent to subscribers [the MQTT-3.3.1-6] . If the server receives the message and QoS 0 RETAIN flag is set to 1, it must discard any messages previously reserved for the theme. It should be a new QoS 0 message store for the theme of the new reservation message, but you can choose to drop it at any time - if this happens, the topic will not be retained messages [the MQTT-3.3.1-7] . For more information about the status of storage, see Section 4.1.
When sending a packet to the client PUBLISH, since if the client [MQTT-3.3.1-8] transmits new subscription message sent, the server must be RETAIN flag is set to 1 . When PUBLISH packets sent to the client, it must RETAIN flag is set to 0, because it matches the subscription established, regardless of the setting of the flag in the received message [the MQTT-3.3.1-9] .
The flag is set to RETAIN PUBLISH packet and payload contains zero bytes of the normal processing by the server 1, and sent to the client has a subject name that matches the reservation. In addition, you must remove any existing reservation message with the same subject name and the subject of any future subscribers will not receive a reservation message [3.3.1-10-the MQTT] . "Normal" indicates that no current is provided RETAIN flag in the message received by the client. Zero-byte message can not be reserved as a reservation message is stored in the server [MQTT-3.3.1-11] on .
If RETAIN flag is 0, then the client sends the PUBLISH packet server, the server can not store the message, and can not remove or replace any existing reservation message [3.3.1-12 the MQTT-] .
Non-normative Comments
If the publisher occasionally send status messages, leave messages useful. New subscribers will receive up to date.
The remaining length field
This is a variable length header plus the payload.
3.3.2 Variable header The variable header
Variable sequence header contains the following fields: topic name, a packet identifier.
Theme name identifies valid data released information channel.
Subject name must appear as PUBLISH Packet Variable header in the first field. It must be UTF-8 encoded string defined in Section 1.5.3 of [the MQTT-3.3.2-1] .
PUBLISH packet subject name must not contain wildcards [the MQTT-3.3.2-2] .
The server sends to the client the subscription PUBLISH packet must be based on the name relating to section 4.7 [the MQTT-3.3.2-3] matching subscription matching process subject matter defined in the filter . However, by allowing the server to cover the topic name, so it may differ from the original packet PUBLISH subject name.
3.3.2.2 Packet Identifier Packet Identifier
A packet identifier field is present only in the PUBLISH packet QoS level of 1 or 2. Section 2.3.1 provides more information on packet identifier.
3.3.2.3 Variable header non normative example exemplary variable head nonstandard
Figure 3.11 - distribution data packet header variables nonstandard example illustrates Table 3.3 Example PUBLISH variable header packet described briefly - the non-canonical example of distribution data packet .
Table 3.3 - released packet exemplary non-canonical
| field |
value |
| Theme Name |
A / B |
| Packet identifier |
10 |
Figure 3.11 - first exemplary non-canonical variable packet publish
|
|
description |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
| Theme Name |
|||||||||
| Byte 1 |
Length MSB (0) |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
| Byte 2 |
The length of the LSB (3) |
0 |
0 |
0 |
0 |
0 |
0 |
1 |
1 |
| Byte 3 |
'a'（0x61） |
0 |
1 |
1 |
0 |
0 |
0 |
0 |
1 |
| Byte 4 |
'/'（0x2F） |
0 |
0 |
1 |
0 |
1 |
1 |
1 |
1 |
| Byte 5 |
'b'（0x62） |
0 |
1 |
1 |
0 |
0 |
0 |
1 |
0 |
| Packet identifier |
|||||||||
| Byte 6 |
Packet identifier MSB (0) |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
| Byte 7 |
Packet identifier LSB (10) |
0 |
0 |
0 |
0 |
1 |
0 |
1 |
0 |
3.3.3 Payload Payload
Payload contains application messages being posted. The content and format of the data is specific to the application. May be calculated by subtracting the length of the payload header from a fixed variable header length field of the remaining length. PUBLISH packet contains zero payload length is effective.
3.3.4 Response response
PUBLISH packet recipient must be based on table 3.4 packet data by the PUBLISH [MQTT-3.3.4-1] in the determined QoS expected release response packet responds .
Table 3.4 - Expected release response packet
| QoS level |
Unexpected response |
| QoS 0 |
No |
| QoS 1 |
PUBACK packet |
| QoS 2 |
PUBREC packet |
3.3.5 Actions Action
The client data packet using the PUBLISH message to the application server, for distribution to the client with a matching subscription.
The server uses the application PUBLISH message packets sent to each customer terminal having a matching subscription.
When the subject filter contains wildcards client uses a subscription, the subscription client may overlap to a published message may match multiple filters. In this case, the server must pass the message to the client, respect for all match subscribed maximum QoS [the MQTT-3.3.5-1] . In addition, the server can provide additional copies of the message, each additional match a subscription, subscription and comply with QoS in each case.
When the recipient receives the operation PUBLISH packet QoS level depending described in Section 4.3.
If the server is not authorized to implement client performs PUBLISH; it has no way to notify customers. It must make a positive acknowledgment, the network connection on or off according to the normal rules of QoS [the MQTT-3.3.5-2] .