I am preparing for one of my hobby projects which will need to connect to all my gadgets (phone, system etc). I stumbled on mqtt which looks like it will solve my impending problems.

Since am still new to this, I had to bring it here to engage like-minds for help and to help others.

MQTT was invented by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Cirrus Link) back in 1999, when their use case was to create a protocol for minimal battery loss and minimal bandwidth connecting oil pipelines over satellite connection. They specified the following goals, which the future protocol should have:

Simple to implement
Provide a Quality of Service Data Delivery
Lightweight and Bandwidth Efficient
Data Agnostic
Continuous Session Awareness


These goals are still the core of MQTT, while the focus has changed from proprietary embedded systems to open Internet of Things use cases. Another thing that is often confused about MQTT is the appropriate meaning of the abbreviation MQTT. It’s a long story, the short answer is that MQTT officially does not have an acronym anymore, it’s just MQTT.


http://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt

MQTT is a machine to machine (m2m)/"internet of things" connectivity protocol. it was designed as an extremely lightweight publish/subscribe message transport. it is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is premium.

[center]STUCTURE OF MQTT PROTOCOL[/center]


- MQTT publish/subscribe

- space decoupling; publisher and subscriber do not need to know each other.
- Time decoupling; publisher and subscriber do not need to run at the same time.
- Synchronization decoupling; operations on both components are not halted during publish or recieving.
- MQTT uses message filtering in the broker to send messages to clients based on the topic they subcribed to.

CLIENT: A mqtt client is any device from a micro controller up to a full flegded server, that has a MQTT library running and is connecting to an MQTT broker over any kind of network. A client can subscribe and also publish.

BROKER: A mqtt broker is the heart of any publish/subscribe protocol. it is primarily responsible for receving all messages, filtering them, decide who is interested in it and then sending the message to all subscribed clients. it is the central hub, which every message needs to pass.

MQTT Connection:

the Mqtt protocol is based on top of TCP/IP and both client and broker need to have a TCP/IP stack. The connection itself is always between one client and the broker, no client is connected to another directly. the connection is initiated through a client sending a CONNECT message to the broker. The broker respond with a CONNACK and a status code.
Once initaited, MQTT will keep it open as long as the client doesn't send a disconnect command or it looses the connection.

MQTT CONNECT command:
sent from a client to the broker. A good natural client will send a connect with the following content among other things:
example
clientId "android-client"
cleansession true
username (optional)
password (optional)
lastwill topic "room1/temp"
lastwill QoS 2
lastwill message "unexcepted exit"
keepAlive 60

if the CONNECT message is malformed (according to the MQTT specification) or it takes too long from opening a network socket to sending it, the broker will close the connection.

clientId:

the clean session flag indicates to the broker, whether the client wants to establish a persisent sesion or not. A persistent session (clean session is false) means that the broker will store all subscriptions for the client and also all missed messages; when subscribing with quality of service (QoS) 1 or 2. if the clean session is set to true, the broker won't store anything for the client.

Username/Password:
MQTT allows to send a username and password for authenticating the client and also authorization. it is optional.

Will message:
this is the part of the last will and testament feature of MQTT. It allows to notify other clients, when a client disconnects ungracefully. A connecting client will provide his will in form of an MQTT message and topic in the CONNECT message. The broker sends this message on behalf of the client if the client gets disconnected ungracefully.

Keep Alive:
This is a time interval the client commits to by sending regular PING request messages to the broker. The broker respond with PING response and this mechanism will allow both sides to determine. If the other one is still aliveand reachable.

CONNACK
When a broker obtains a CONNECT message. It is obligated to respond with a CONNACK message. The CONNACK message contains only two data entries: session present flag, connect return code.

Session present true
Return code 0


Return code return code response
0 connection accepted
1 connection refused, unacceptable protocol version
2 connection refused, identifier rejected
3 connection refused, server unavailable
4 connection refused, bad username or password
5 connection refused, not authorised