Unit 5: Messaging Queues and Publish/Subscribe Communications - Subjective Questions

MQTT is a lightweight messaging protocol designed for devices operating over low-bandwidth, high-latency, or unreliable networks. It uses the publish/subscribe communication model and normally operates over TCP/IP.

Its main architectural components are:

• Publisher: Produces data and publishes messages to a named topic.
• Subscriber: Expresses interest in one or more topics and receives matching messages.
• Broker: Receives messages from publishers, filters them according to topics, and forwards them to subscribers.
• Topic: A hierarchical name used to classify messages, such as factory/machine1/temperature.
• MQTT client: Any device or application acting as a publisher, subscriber, or both.

MQTT is suitable for IoT because it has a small packet header, supports asynchronous communication, and provides configurable delivery reliability.

An MQTT communication session generally follows these steps:

1. Transport connection: The client establishes a TCP connection with the MQTT broker. A secure connection may use TLS.
2. CONNECT packet: The client sends a CONNECT control packet containing its client identifier, session options, authentication information, keep-alive value, and optional Will information.
3. CONNACK packet: The broker accepts or rejects the request using a CONNACK packet.
4. Subscription: A subscriber sends SUBSCRIBE with one or more topic filters. The broker responds with SUBACK.
5. Publication: A publisher sends a PUBLISH packet containing a topic, payload, QoS level, and other flags.
6. Message delivery: The broker forwards the message to all matching subscribers.
7. Connection maintenance: PINGREQ and PINGRESP packets can confirm that the connection remains active.
8. Termination: A client normally sends DISCONNECT before closing the transport connection.

MQTT provides three Quality of Service (QoS) levels:

• QoS 0 — At most once: The message is sent once without acknowledgment. Delivery is not guaranteed. It has the lowest overhead and is suitable for frequent sensor readings where occasional loss is acceptable.
• QoS 1 — At least once: The sender retransmits the message until it receives an acknowledgment. The message is guaranteed to arrive, but duplicates may occur. It is suitable for alarms, status updates, and control information when applications can detect duplicates.
• QoS 2 — Exactly once: A multi-step acknowledgment exchange ensures that the message is processed once. It provides the highest reliability but also has the greatest delay and overhead. It is suitable for billing, financial transactions, or critical commands.

The QoS level should be selected by balancing reliability, bandwidth, latency, energy consumption, and processing cost.

These MQTT features improve availability and reliability:

• Retained message: A publisher marks a message as retained, causing the broker to store the most recent retained message for that topic. A new subscriber immediately receives it instead of waiting for the next publication.
• Persistent session: The broker retains session-related information after a client disconnects. Depending on the MQTT version and configuration, this can include subscriptions and queued QoS messages.
• Last Will and Testament: A client provides a Will topic and Will message during connection establishment. If the client disconnects unexpectedly, the broker publishes the Will message to inform interested subscribers.

For example, an industrial sensor can publish an online status when it connects and configure an offline status as its Will message. Monitoring systems can then detect an unexpected sensor failure.

MQTT and AMQP are both messaging protocols, but they target different requirements.

Conclusion: MQTT is usually preferred when low power, low bandwidth, and simplicity are important. AMQP is preferred when applications require sophisticated routing, durable queues, transactions, and enterprise-level messaging guarantees.

In the publish/subscribe model, publishers send messages to logical topics or channels rather than directly addressing receivers. Subscribers register their interest in selected topics, and a broker distributes matching messages.

Its important characteristics are:

• Space decoupling: Publishers do not need the addresses of subscribers.
• Time decoupling: Publishers and subscribers may not need to be active simultaneously if the broker supports message storage.
• Synchronization decoupling: Publishers can continue their work without waiting for subscribers to process messages.
• One-to-many delivery: One publication may be delivered to several subscribers.

In request/response communication, a client sends a request directly to a known server and normally waits for a response. It is appropriate for immediate queries and commands. Publish/subscribe is more suitable for asynchronous event distribution, telemetry, and situations in which producers and consumers change dynamically.

The publish/subscribe model provides the following IoT advantages:

• Loose coupling: Sensors and applications do not need direct knowledge of one another.
• Scalability: New publishers and subscribers can be added without changing existing devices.
• Efficient one-to-many communication: A single sensor update can be distributed to many applications.
• Asynchronous operation: Devices can publish without waiting for receivers to respond.
• Simplified integration: Multiple applications can consume the same telemetry through common topics.
• Support for intermittent devices: Brokers can retain or queue selected messages for temporarily disconnected clients.
• Flexible filtering: Subscribers receive only messages matching their topic filters.
• Reduced device complexity: The broker performs message routing and distribution.

These properties are useful in smart cities, industrial monitoring, connected vehicles, agriculture, and home automation.

The publish/subscribe model has several limitations:

• Broker dependency: A centralized broker can become a failure point. This can be mitigated through clustering, replication, and failover brokers.
• Delivery uncertainty: Messages may be lost on unreliable networks. QoS levels, acknowledgments, persistence, and retransmission can improve reliability.
• Duplicate or out-of-order messages: Applications can use message identifiers, timestamps, sequence numbers, and idempotent processing.
• Security complexity: Unauthorized clients may publish or subscribe to sensitive topics. TLS, authentication, access-control lists, and topic-level authorization should be applied.
• Debugging difficulty: Indirect communication makes message tracing harder. Distributed logging, correlation identifiers, and broker monitoring are useful.
• Potential broker overload: High publication rates can exhaust broker resources. Rate limiting, load balancing, topic partitioning, and edge aggregation can reduce load.
• Stale retained data: Retained messages may no longer be valid. Expiry intervals and clear retention policies should be used.

Thus, publish/subscribe improves flexibility but requires careful reliability, security, and broker-capacity planning.

Session initiation is the procedure through which two or more IoT endpoints establish the context needed for communication before application data is exchanged.

The initiation process may negotiate or establish:

• Endpoint identities and addresses
• Application or service being requested
• Media or data format, such as a sensor-data representation or audio codec
• Transport protocol and port numbers
• Security parameters, including authentication and encryption choices
• Quality requirements, such as delay, reliability, or bandwidth
• Session lifetime and refresh rules
• Device capabilities and resource limitations

The process normally includes a session request, an acceptance or rejection response, and an acknowledgment or confirmation. In IoT, session initiation must minimize message size, processing cost, delay, and radio use.

A lightweight session maintains only the essential communication state needed by constrained IoT devices. It avoids the large messages, repeated negotiations, and complex state machines commonly used in traditional multimedia or enterprise systems.

A lightweight session mechanism should provide:

• Small message size to reduce bandwidth and fragmentation
• Few signaling exchanges to reduce latency and radio energy consumption
• Compact state information to fit limited memory
• Simple parsing for low-power processors
• Support for sleeping and intermittently connected devices
• Reliable retransmission when an unreliable transport is used
• Capability discovery and minimal parameter negotiation
• Authentication and replay protection with acceptable overhead
• Simple session refresh, modification, and termination

Such sessions are useful for constrained sensors, actuators, wearable devices, and low-power wireless nodes.

A constrained session initiation protocol, often represented by lightweight or constrained adaptations of SIP such as CoSIP, provides session establishment functions while reducing the overhead of conventional SIP.

It can reduce overhead through:

• Compact message encoding instead of lengthy textual headers
• Short method names or numeric option identifiers
• Removal of headers not required by constrained applications
• Reduced number of request-response exchanges
• Reuse of existing security and transport contexts
• Caching of endpoint capabilities and session parameters
• Operation through a gateway or proxy that translates between constrained signaling and standard Internet protocols
• Support for lightweight transports and retransmission timers

The protocol should still provide endpoint discovery, capability negotiation, session creation, modification, and termination. A gateway-based design is especially useful because constrained devices perform simple signaling while the gateway handles complex routing, translation, and interoperability.

A typical session initiation sequence is as follows:

1. Discovery: The client discovers the service directly, through a resource directory, or through a gateway.
2. Initial request: The client sends an initiation request containing its identity, desired service, supported formats, transport details, and proposed session parameters.
3. Authentication: The service verifies credentials or performs a security handshake when required.
4. Capability negotiation: The service checks whether it supports the requested data format, transport, reliability, and security options.
5. Provisional response: An intermediate response may indicate that the request is being processed.
6. Final response: The service accepts the proposal, returns modified parameters, or rejects it with a reason.
7. Acknowledgment: The client confirms acceptance of the negotiated parameters when the protocol requires it.
8. Resource allocation: Both endpoints create session state, timers, buffers, and security contexts.
9. Data exchange: Sensor data, commands, or media are transferred according to the agreed parameters.

A constrained design may combine or omit some steps to reduce packet count. Each message should include a transaction or session identifier so that retransmissions are not mistaken for new sessions.

Session tear-down releases the state and resources associated with an active session.

In a graceful termination:

1. One endpoint sends a termination request containing the session identifier.
2. The peer stops or completes ongoing data transfer.
3. The peer returns a confirmation response.
4. Both endpoints release buffers, timers, ports, and temporary security state.
5. Logs or final delivery records may be stored.

In an abnormal termination, a device may lose power, move out of coverage, or experience a network failure without sending a termination request. The other endpoint detects the failure through keep-alive expiry, inactivity timers, retransmission limits, transport closure, or a broker Will message.

Graceful tear-down avoids stale state and confirms completion. Abnormal tear-down depends on timers and failure detection, so resources may remain allocated until a timeout occurs.

Session modification changes one or more parameters of an already established session without creating an entirely new session.

Parameters that may be modified include:

• Data format or encoding
• Sampling or publication rate
• Destination address or port
• Reliability or QoS level
• Security algorithm or key context
• Device role or stream direction
• Session expiry time

A safe modification procedure is:

1. The requester sends a modification message containing the current session identifier and proposed changes.
2. The receiver validates the request and checks resource availability.
3. The receiver accepts, rejects, or provides alternative parameters.
4. Both sides agree on when the new parameters become active.
5. The requester acknowledges the result if required.
6. Both endpoints update their session state consistently.

Version numbers, transaction identifiers, acknowledgments, and rollback rules prevent inconsistent state when messages are lost or duplicated.

Both approaches can support session creation, modification, and termination. However, a constrained approach simplifies encoding, state management, retransmission, discovery, and negotiation to suit limited bandwidth, energy, processing capacity, and memory.

A topic is a logical classification or routing name. Publishers send messages under a topic, and any subscriber with a matching filter can receive them. The same publication may therefore be delivered to many subscribers.

A message queue stores messages until they are consumed. In a competing-consumer arrangement, each queued message is normally processed by one consumer, which supports workload distribution.

• MQTT: Primarily uses hierarchical topics. The broker matches publications against subscriptions. Persistent sessions and queued QoS messages can provide queue-like behavior for offline clients.
• AMQP: Explicitly separates producers, exchanges, bindings, and queues. An exchange routes a message to one or more queues according to routing rules, and consumers retrieve messages from those queues.

Topics are ideal for event distribution, while queues are ideal for durable work processing and load sharing. AMQP exposes queue and routing structures directly, whereas MQTT offers a simpler topic-centered abstraction.

A suitable design includes the following elements:

• Publishers: Temperature, smoke, and fire sensors installed in rooms.
• Broker: A local building broker with an optional connection to a cloud platform.
• Subscribers: Dashboards, alarm controllers, maintenance applications, and emergency services.
• Topic hierarchy: Examples include building/floor1/room101/temperature and building/floor1/room101/fire.
• Temperature QoS: Routine temperature values can use QoS 0 because newer readings replace older ones.
• Fire-alert QoS: Fire events should use QoS 1 or QoS 2 according to the required reliability and acceptable overhead.
• Retained state: The latest room status can be retained so that a newly connected dashboard receives it immediately.
• Last Will: Each gateway can configure an offline-status Will message.
• Security: TLS, unique client credentials, topic-level authorization, and certificate rotation should be used.
• Availability: A clustered or backup broker can reduce the risk of a single point of failure.

The design separates data producers from consumers, allows several applications to receive the same alarm, and supports future expansion without changing sensor addressing.

Reliability requirements include:

• Transaction and session identifiers to match requests with responses
• Retransmission timers for lost signaling messages
• Duplicate detection and idempotent request processing
• Keep-alive or inactivity timers to detect failed peers
• Consistent cleanup after normal or abnormal termination
• Recovery or resumption after temporary disconnection

Security requirements include:

• Mutual or server-side authentication
• Authorization for requested services and session changes
• Confidentiality through TLS, DTLS, or another suitable secure channel
• Integrity protection to prevent message modification
• Nonces, timestamps, or sequence numbers to prevent replay attacks
• Secure key establishment and renewal
• Protection against resource-exhaustion and denial-of-service attacks

Security must be applied throughout the session lifecycle. An authenticated initiation is insufficient if later modification or termination messages can be forged. Constrained devices may use gateways, compact credentials, or pre-established security contexts to reduce overhead.

MQTT session persistence allows a client to disconnect temporarily without losing all broker-side session information.

• In MQTT 3.1.1, the client uses the Clean Session flag to request a new temporary session or resume a stored session.
• In MQTT 5, Clean Start and Session Expiry Interval provide more precise control over session creation and lifetime.
• A persistent session may retain subscriptions and queued QoS messages, depending on protocol rules and broker configuration.
• When the client reconnects using the same client identifier, the broker can restore the session and deliver pending messages.

This is useful for battery-powered devices that sleep to conserve energy or devices that frequently lose wireless connectivity. However, long-lived sessions consume broker memory and storage. Therefore, administrators should select reasonable expiry intervals, queue limits, message-expiry values, and policies for inactive clients.

A lightweight IoT session can be represented by the following conceptual states:

1. Idle: No session state exists. A discovery result or application event triggers initiation.
2. Initiating: A session request has been sent. The endpoint waits for acceptance, rejection, or timeout.
3. Negotiating: Endpoints select compatible transport, format, security, and reliability parameters.
4. Established: Negotiation has succeeded, resources are allocated, and application data can be exchanged.
5. Modifying: One endpoint requests a parameter change. The existing configuration remains active until the modification is accepted, unless the protocol defines otherwise.
6. Suspended or reconnecting: Connectivity is temporarily lost, but resumable session state is retained for a limited time.
7. Terminating: A tear-down request or local shutdown begins resource release.
8. Closed: Session state has been removed and allocated resources have been released.
9. Failed: Initiation, modification, or maintenance has failed. Cleanup is performed before returning to the idle or closed state.

Important transitions include:

• Idle to Initiating after a session request
• Initiating to Established after successful negotiation
• Established to Modifying after a change request
• Modifying to Established after acceptance or rollback
• Established to Suspended or reconnecting after temporary network loss
• Established to Terminating after a termination request
• Any active state to Failed after timeout, authentication failure, or unrecoverable error

Timers, transaction identifiers, acknowledgments, and duplicate detection are essential for deterministic transitions. The model prevents stale resources and inconsistent endpoint state while keeping signaling suitable for constrained devices.