QoS 0: In "At most once" delivery, the message is delivered according to the best efforts of the underlying TCP/IP network. No response is expected. No retry semantics are defined in the protocol. Consequently, the message will arrive at the destination broker either not at all or once.
Care should be taken to understand the context of reliable delivery, i.e. QoS 1 and QoS 2: certain classes of failure can still cause the non-delivery of a message. Each message with QoS 1 or QoS 2 is accompanied by a Message Identifier in the Variable Header.
QoS 1: In "At least once" delivery, the arrival of the message at the broker, including its successful placement onto an MQ Series queue, if applicable, is acknowledged by a PUBACK message. In the event of identifiable failure of the communications link, or of the sending device, or after some period of time of non-receipt of the acknowledgement message, the sender will resend the message with the DUP bit set. Consequently, the message is "certain" to arrive, but could arrive more than once.
QoS 2: In "Exactly once" delivery, additional protocol flows
are employed above QoS 1 to ensure that duplicate messages are not delivered
to the receiving application. This is the highest level of delivery service,
and is used when duplicate messages are undesirable. Of course, there is
a price to be paid in terms of network traffic, but often this is acceptable
because of the importance of the message content.
It is assumed that both client and broker are generally reliable, and
that it is the communications channel which is most likely to be unreliable.
Moreover it is usually the case that if the client device fails, then it
is a catastrophic failure, rather than a transient failure, so the chances
of recovering data from the device are low.
Some devices may have non-volatile storage, such as flash ROM, which
would allow the most critical data to be stored more persistently on the
client device to allow it to survive some failure modes.
Beyond simple communications link failure, the failure mode matrix becomes extremely complex, and there are just too many scenarios to cater for in a specification such as this.
That is the level of assumption that is being made in this protocol
specification, and this should be borne in mind when writing applications
using this protocol.
The Message Identifer is a 16 bit unsigned integer, which will typically increase, but is not required to increase by exactly one from one message to the next. This assumes that there will never be more than 65,535 messages "in flight" between one particular client-broker pair at any time. For more details, see the Variable Header section.
Note that Message ID 0 (i.e. 0x0000) is reserved as an invalid Message
ID. This is to avoid erroneous actions if a Message ID is accidentally
omitted.
BACK to index