Learn RabbitMQ - Multi-Protocol Support (MQTT, STOMP, WebSockets)

#Introduction

Everything we've done so far runs over the AMQP protocol. But not every client can (or wants to) speak AMQP. IoT sensors only understand MQTT — a lightweight protocol for constrained devices. Web applications often use STOMP or WebSockets for real-time push. Forcing everything onto AMQP is unnecessary extra work.

RabbitMQ's answer is multi-protocol plugins: the same broker, one AMQP core, but different entry doors. MQTT, STOMP, and WebSockets are all translated into the internal AMQP model — the same topics, queues, and exchanges can be reached from any protocol.

This episode enables and configures all three protocols, understands the cross-protocol mapping, and looks at real usage patterns: from IoT dashboards to real-time chat in the browser.

#The MQTT Plugin

#Enabling MQTT

The MQTT plugin provides a listener on port 1883 (and 8883 for TLS):

rabbitmq-plugins enable rabbitmq_mqtt

Once active, any MQTT client (for example mosquitto_pub) connects directly:

mosquitto_pub -h localhost -t 'sensor/suhu' -m '{"suhu":29.5}'

The mosquitto_pub command publishes a message to the MQTT topic sensor/suhu.

#MQTT to AMQP Translation

Every MQTT topic is mapped to an internal AMQP exchange: the sensor/suhu topic becomes the routing key sensor.suhu on the amq.topic exchange. That way, AMQP consumers can receive MQTT messages and vice versa — they meet at the amq.topic exchange.

#QoS Level Mapping

MQTT QoS is mapped to AMQP mechanisms:

• QoS 0 — best effort; mapped to transient delivery without confirms.
• QoS 1 — at-least-once; mapped to manual ack with retry.
• QoS 2 — exactly-once; RabbitMQ maps it with special synchronization.

This mapping matters when designing devices: QoS 2 consumes the most round-trip cost, so for battery-constrained devices you should use QoS 0 or 1 depending on application needs. The higher the QoS, the greater the per-message communication overhead.

MQTT's biggest use case is IoT: constrained sensors sending telemetry with small bandwidth. Thanks to two-way translation, sensor data can be consumed directly by AMQP pipelines on the backend.

#MQTT over WebSockets

For browsers that need to receive MQTT topics, the plugin also provides MQTT over WebSockets on port 15675 (/ws). This lets web dashboards use the MQTT.js library without protocol changes.

#Configuring the Default User and Vhost

Each protocol plugin has a default user and vhost. For MQTT, the default is guest and the / vhost — vulnerable if the node is publicly accessible. Replace them with dedicated users and vhosts:

mqtt.default_user = mqtt_svc
mqtt.default_pass = changeme
mqtt.default_vhost = /iot

The mqtt.default_vhost configuration directs all MQTT clients that don't specify a vhost to /iot. The same pattern is available for STOMP (stomp.default_user, stomp.default_vhost) and Web-STOMP (web_stomp.default_user). This way you can separate each protocol's traffic into different vhosts.

#The STOMP Plugin

#Enabling STOMP

STOMP is a simple textual protocol popular for web messaging:

rabbitmq-plugins enable rabbitmq_stomp

STOMP listens on port 61613. Clients send SEND and SUBSCRIBE frames that map to AMQP exchanges and queues: the /topic/berita destination becomes a routing key on the amq.topic exchange, and /queue/tugas becomes a queue named tugas.

#Web Messaging and Browsers

STOMP is very popular for web applications because of its simple, textual format. For browsers, use STOMP.js with WebSockets so real-time messages can be received directly on a web page.

#WebSockets and Web-STOMP

#The Web-STOMP Plugin

The rabbitmq_web_stomp plugin bridges browsers and RabbitMQ: the browser opens a WebSocket, then speaks STOMP inside it:

rabbitmq-plugins enable rabbitmq_web_stomp

Web-STOMP listens on port 15674 (/ws). Browsers use STOMP.js to subscribe to AMQP destinations — ideal for real-time notifications like order status or live scores.

#SockJS Integration

For environments with proxies that don't fully support WebSockets, use SockJS: the rabbitmq_web_stomp plugin supports the SockJS fallback so connections keep working through HTTP long-polling when WebSockets are blocked. Consumers just pick whichever transport is available automatically.

#Choosing a Protocol for the Browser

For web applications, the protocol choice depends on the needs: Web-STOMP is the most common because STOMP is simple and maps directly to the AMQP model; MQTT over WebSockets fits if you already have an MQTT pipeline and want the dashboard to receive the same topics; raw WebSocket with AMQP isn't practical because AMQP is a binary protocol that's awkward for browsers to handle. Start with Web-STOMP, then adjust if the architecture demands another protocol.

#End-to-End Scenario: An IoT Dashboard

All the protocols can combine in one real flow: sensors publish telemetry via MQTT, and the browser dashboard receives it via Web-STOMP:

Sensor (MQTT, port 1883) ──► RabbitMQ (exchange amq.topic)
                                   │
                                   ▼
Dashboard browser (Web-STOMP, port 15674) ◄── subscribe /topic/telemetri

Sensors publish to the telemetri topic, which is translated into a routing key on the amq.topic exchange. The browser dashboard subscribes to the /topic/telemetri destination via Web-STOMP, so it receives the same data without writing a single line of the AMQP protocol. One broker, two entry doors, one data flow.

#Conclusion

In episode 27 you enabled the MQTT plugin for IoT, STOMP for web applications, and WebSockets via Web-STOMP and SockJS, understood protocol translation into the AMQP model, and MQTT QoS level mapping.

Key takeaways:

• MQTT on port 1883; topics map to the amq.topic exchange.
• MQTT QoS maps to AMQP ack mechanisms.
• MQTT over WebSockets serves IoT dashboards in the browser.
• STOMP on port 61613 uses the textual SEND and SUBSCRIBE frames.
• Web-STOMP on port 15674 connects browsers via WebSocket.
• SockJS provides a fallback when WebSockets aren't available.
• One dotted topic can be reached from AMQP, MQTT, and STOMP at once.

In the next episode we will discuss client SDK best practices — connection recovery and topology recovery patterns, consumer cancellation notifications, handling blocked connections, client-side load balancing, and error handling strategies with retry logic and circuit breakers for the Java, Python, Node.js, and Go clients. This is what makes client applications resilient!