MQTT by name is a misnomer. There are no message queues inherent in the protocol. While it is possible to queue messages, it's not necessary and often not done. MQTT is TCP based, and therefore includes some guarantee that a packet is transferred reliably.  

MQTT is also an asymmetric protocol, whereas HTTP is a nonsymmetric protocol. Say node A needs to communicate with node B. An asymmetric protocol between A and B would only require one side (A) to use the protocol, however, all information needed for the reassembly of packets must be contained in the fragmentation header sent by A. Asymmetric systems have one master and one slave (FTP being a classic example). In a symmetric protocol, both A and B would have the protocol installed. A or B can assume the role of master or slave (telnet being a primary example). MQTT has distinct roles which makes sense in sensor/cloud topology.

MQTT can retain a message on a broker indefinitely. This mode of operation is controlled by a flag on a normal message transmission. A retained message on a broker is sent to any client that subscribes to that MQTT topic branch. The message is transmitted immediately to that new client. This allows a new client to receive a status or signal from a newly subscribed topic without waiting. Typically, a client subscribing to a topic may need to wait hours, or even days, before a client publishes new data.  

MQTT defines an optional facility called Last Will and Testament (LWT). An LWT is a message a client specifies during the connect phase. The LWT contains the Last Will topic, QoS, and the actual message. If a client disconnects from a broker connection ungracefully (for example, keep-alive timeout, I/O error, or the client closing the session without a disconnect), the broker is then obligated to broadcast the LWT message to all other subscribed clients to that topic. 

Even though MQTT is based on TCP, connections can still be lost, especially in a wireless sensor environment. A device may lose power, lose signal strength, or simply crash in the field, and a session will enter a half-open state. Here, the server will believe the connection is still reliable and expect data. To remedy this half-open state, MQTT uses a keep-alive system. Using this system, both the MQTT broker and client have assurance that the connection is still valid even if there hasn't been a transmission for some time. The client sends a PINGREQ packet to the broker, which in turn acknowledges the message with a PINGRESP. A timer is preset on the client and broker side. If a message has not been transmitted from either within a predetermined time limit, a keep-alive packet should be sent. Both a PINGREQ or a message will reset the keep-alive timer.

In the event that a keep-alive is not received and the timer expires, the broker will close the connection and send out the LWT packet to all clients. The client may at some point later attempt to reconnect. In that case, a half-open connection will be closed by the broker and open up a new connection to the client.

While keep-alive assists with broken connections, re-establishing all of a client's subscriptions and QoS parameters can result in unnecessary overhead on a data-capped connection. To alleviate this extra data, MQTT allows for persistent connections. A persistent connection will save the following on the broker side:

• All client's subscriptions
• All QoS messages that were not confirmed by the client
• All new QoS messages missed by the client

This information is referenced by the client_id parameter to identify unique clients. A client can request a persistent connection, however, the broker can deny the request and force a clean session to restart. Upon connection, the cleanSession flag is used by the broker to allow or deny persistent connections. The client can determine if a persistent connection was stored using the CONNACK message. 

There are three levels of quality of service in MQTT:

• QoS-0 (non-assured transmission): This is the minimal QoS level. This is analogous to a fire-and-forget model detailed in some of the wireless protocols. It is a best-effort delivery process without the receiver acknowledging a message or the sender reattempting transmission.
• Qos-1 (assured transmission): This mode will guarantee delivery of the message at least once to the receiver. It may be delivered more than once, and the receiver will send an acknowledgment back with a PUBACK response.
• QoS-2 (assured service on applications): This is the highest level of QoS that ensures and informs both the sender and receiver that a message has been transmitted correctly. This mode generates more traffic with a multi-step handshake between the sender and receiver. If a receiver gets a message set to QoS-2, it will respond with a PUBREC message to the sender. This acknowledges the message and the sender will respond with a PUBREL message. PUBREL allows the receiver to safely discard any re-transmissions of the message. The PUBREL is then acknowledged by the receiver with a PUBCOMP. Until the PUBCOMP message is sent, the receiver will cache the original message for safety.

QoS in MQTT is defined and controlled by the sender and each sender can have a different policy.