MQTT (Message Queue Telemetry Transport) is a messaging protocol introduced by
IBM in 1999, designed for IoT applications.
It's ideal for small, cheap, low-memory, and low-power devices commonly found in IoT.
MQTT uses a publish/subscribe architecture, involving publishers, subscribers, and a
broker.
Publishers are lightweight sensor devices that send data to a broker and go to sleep
when not in use.
Subscribers are applications interested in specific topics or sensory data, connected to
brokers to receive updates.
The broker filters and sends sensory data to subscribers based on their topic interests.
SMQTT (Secure Message Queue Telemetry Transport) is an extension of
MQTT protocol that adds encryption using lightweight attribute encryption.
It has a broadcast encryption feature, allowing one message to be encrypted
and delivered to multiple nodes.
The process involves four main stages:
1. Setup: Publishers and subscribers register with the broker and receive a
secret master key.
2. Encryption: The broker encrypts the published data.
3. Publish: Encrypted messages are published to subscribers.
4. Decryption: Subscribers decrypt received messages using the same
master key.
SMQTT is designed to enhance the security features of MQTT.
Constrained Application Protocol (CoAP) is a session layer
protocol designed by the IETF Constrained RESTful
Environment (CoRE) working group.
It provides a lightweight RESTful (HTTP) interface, which is a
standard way for communication between HTTP clients and
servers.
CoAP is specifically designed for IoT applications to minimize
overhead and power consumption.
Unlike HTTP, which uses TCP, CoAP is built over UDP,
making it lighter.
CoAP architecture has two main sublayers: messaging and
request/response. The messaging sublayer handles reliability
and duplication, while the request/response sublayer manages
communication.
CoAP has four messaging modes: confirmable (reliable), non-
confirmable (unreliable), piggyback, and separate.
It uses GET, PUT, POST, and DELETE messages similar to
HTTP for retrieving, creating, updating, and deleting data,
respectively.
- Confirmable mode: Ensures reliable transmission, where the sender waits for an
acknowledgment from the receiver.
- Non-confirmable mode: Unreliable transmission, where no acknowledgment is
expected.
- Piggyback mode: Allows the server to include its response within the
acknowledgment message, facilitating direct communication.
- Separate mode: The server response is sent separately from the acknowledgment,
potentially taking more time.
Here's a simplified explanation of XMPP:
- Extensible Messaging and Presence Protocol (XMPP) is a messaging protocol
originally designed for chat and message exchange applications.
- It's been standardized by the IETF and has been used effectively over the internet
for over a decade.
- XMPP has been adapted for IoT applications and software-defined networking
(SDN) due to its extensibility with XML.
- It supports both publish/subscribe and request/response architectures, providing
flexibility for developers.
- Designed for near real-time applications, XMPP efficiently handles low-latency
small messages.
- However, it lacks quality of service guarantees, making it less suitable for
machine-to-machine (M2M) communications.
- XML format used in XMPP messages can create overhead with many headers
and tags, potentially increasing power consumption, which is a concern for IoT
applications.
- While not widely used in IoT, there's some interest in enhancing XMPP's
architecture to better support IoT applications.
Here's a simplified explanation of AMQP:
- AMQP (Advanced Message Queuing Protocol) is a messaging protocol originally
designed for the financial industry.
- It runs over TCP and uses a publish/subscribe architecture, similar to MQTT.
- In AMQP, the broker is divided into two main components: exchanges and
queues.
- The exchange receives messages from publishers and distributes them to queues
based on predefined rules and conditions.
- Queues represent topics and are subscribed to by subscribers who receive sensory
data whenever it's available in the queue.
Exchange: Receives messages from publisher primarily based programs and routes them To ‘message
queues’.
Message Queue: Stores messages until they may thoroughly process via the eating client software.
Binding: States the connection between the message queue and the change.
