QoS 0: when we prefer that the message will arrive at most once; the message will be received or it won't, there isn't a chance of a duplicate; at most once; fire and forget;

QoS 1: when we want the message to arrive at least once but don’t care if it arrives twice (or more); at least once;

QoS 2: when we want the message to arrive exactly once. A higher QOS value means a slower transfer; exactly once.

If a message is published with QoS 2 and the client is subscribed to a topic with QoS 0, then the message will be delivered to that client with QoS 0;

Next, if another customer is subscribed to the same topic, but with QoS 2, he will receive the message with QoS 2;

Now, lastly, if a subscriber is registered with QoS 2 and the message is published with QoS 0, the message will be delivered with QoS 0.

mosquito - c  mosquitto.conf -v

mosquitto_sub -h localhost -p 1883 -u user1 - P 321 -t temperature -q 2

mosquitto_pub -h localhost -p 1883 -u user1 - P 321 -t temperature -m 45 -q 2

The notion of physical devices connected to the Internet and passing data to and receiving data from it is the spine of a realistic implementation of an IoT solution.

The IoT revolution holds a lot of promise, the implications of which are only viable if there is effective machine-to-machine (M2M) communication, and to aim for real-time M2M communication over the Internet.

A communication protocol can be thought of as a language that is used by two or more machines to talk to each other. It is a set of rules that are followed by the two devices in order to make sense out of the messages that they pass to each other. 

Communication Protocols are extremely essential in distributed systems, where different parts of the same process are carried out at more than one location, significantly distant from each other.

That's pretty much how MQTT functions:

MQTT consists of two broad categories of participating devices. They are called brokers and clients. The clients are those devices which can access or modify data, and brokers are those which host and relay data.

MQTT works on a paradigm called the publish/subscribe method. A client can publish data regarding a certain parameter to the broker under a topic. Another client interested in this toopic can subscribe to this topic and receive regular updates on messages under the topic.

MQTT offers a quality of service, which from an IoT standpoint is essentially the priority attached to the message. An important message should reach the destination in any case, so it's given a better QoS, so that transmission may be slow, but delivery is guaranteed. A dynamic data source that prioritizes speed over efficiency, though, is assigned a lower QoS, so that it's more of a fire-and-forget affair, like UDP.

MQTT can retain the last good message received under a topic, which it sends to subscribers who subscribe after the chain has been set in motion. This allows asynchronous connection of subscribers within an existing network of clients and brokers. This also provides a facility to check for redundancy and data loss.

An MQTT client has a property called the Last will and testament. This property enables a client which has disconnected abruptly to send a message to the broker. An SOS call of sorts, which can be used for autonomous regeneration of a wireless sensor network, detection and debugging of stray nodes and outliers as well as a routine to ensure a faultless cycle in data flow of a wireless sensor network.

mosquito - c  mosquitto.conf -v

mosquitto_sub -h localhost -p 1883 -u user1 - P 321 -t temperature -m 45 -q 2

mosquitto_pub -h localhost -p 1883 -u user1 - P 321 -t temperature -m 45 -q 2

mosquitto_sub -h localhost -p 1883 -u user1 - P 321 -t temperature -m 45 -q 1

mosquitto_pub -h localhost -p 1883 -u user1 - P 321 -t temperature -m 45 -q 1

mosquitto_sub -h localhost -p 1883 -u user1 - P 321 -t temperature -m 45 -q 0

mosquitto_pub -h localhost -p 1883 -u user1 - P 321 -t temperature -m 45 -q 0