Supported Protocols

FlowMQ natively supports MQTT, Kafka, and AMQP protocols within a single, unified routing engine. This simplifies your messaging infrastructure and enables seamless interoperability. FlowMQ's architecture also allows to be extended to support cloud service APIs, AWS SNS(Simple Notification Service) and SQS(Simple Queue Service).

This chapter will detail FlowMQ's support for each protocol and how messages flow between them.

MQTT (Message Queuing Telemetry Transport)

FlowMQ can act as an fully compliant MQTT v5.0 and v3.1.1 broker, connecting millions of devices concurrently, ideal for IoT and mobile messaging. It maps MQTT publish/subscribe to its unified routing model.

Getting Started with MQTT:

You can easily connect, publish, and subscribe to FlowMQ using any standard MQTT client library or tool. For command-line interface, the MQTTX CLI is a popular choice.

Example (using MQTTX CLI):

# Subscribe
mqttx sub -h <flowmq_host> -p 1883 -t "sensor/+/data" -q 1
# Publish
mqttx pub -h <flowmq_host> -p 1883 -t "sensor/thermostat/data" -m '{"temperature": 22.5}' -q 1

Kafka (Apache Kafka Protocol)

FlowMQ operates as a stateless Kafka broker, allowing standard Kafka clients to connect without code changes. It maps Kafka topics to its unified routing model, using its stream capabilities.

Getting Started with Kafka Protocol:

You can use the standard Kafka client command-line tools (kafka-topics.sh, kafka-console-producer.sh, kafka-console-consumer.sh) or any Kafka client library in your preferred programming language to interact with FlowMQ.

Example (using Kafka CLI tools):

# Create a topic (if not auto-created)
kafka-topics.sh --bootstrap-server <flowmq_host>:9092 --create --topic my-k-topic --partitions 1 --replication-factor 1

# Produce messages
kafka-console-producer.sh --bootstrap-server <flowmq_host>:9092 --topic my-k-topic

# Consume messages
kafka-console-consumer.sh --bootstrap-server <flowmq_host>:9092 --topic my-k-topic --from-beginning

AMQP (Advanced Message Queuing Protocol)

FlowMQ can function as an AMQP 0-9-1 broker, suitable for enterprise messaging and task queuing. It maps AMQP exchanges, queues, and bindings to its unified routing model.

Getting Started with AMQP:

You can use any standard AMQP 0-9-1 client SDK (e.g., RabbitMQ client libraries for various languages like Java, Python, Node.js) to interact with FlowMQ.

Example (using the Pika Python client):

# import pika
# connection_params = pika.ConnectionParameters(host='<flowmq_host>', port=5672)
# connection = pika.BlockingConnection(connection_params)
# channel = connection.channel()
# channel.queue_declare(queue='my_amqp_q', durable=True)
# channel.basic_publish(exchange='my_direct_ex', routing_key='task_key', body='Msg')
# channel.basic_consume(queue='my_amqp_q', on_message_callback=callback_func)

Interoperability Between Protocols

One of the most powerful features of FlowMQ is its ability to enable seamless interoperability between different messaging protocols, all thanks to its unified routing model. This means a message produced using one protocol can be consumed by an application using an entirely different protocol, without either application needing to be aware of the other's protocol choice.

MQTT → Kafka

FlowMQ can route MQTT messages published on an topic (or matching an topic filter) to a FlowMQ stream. Kafka consumers can then subscribe to this stream as if it were a standard Kafka topic.

How it works: You declare a FlowMQ stream and configure it to subscribe to a specific MQTT topic filter (e.g., sensors/+/temperature). When an MQTT client publishes a message to sensors/device1/temperature, FlowMQ routes this message to the designated stream. Kafka consumers listening to that stream will then receive the message.

Kafka → MQTT

When Kafka producers send messages to a Kafka topic within FlowMQ that uses a hierarchical naming convention (e.g., data.telemetry.device1), FlowMQ can automatically interpret this as an MQTT-compatible topic (e.g., data/telemetry/device1).

How it works: FlowMQ's routing engine can be configured to recognize these Kafka topic naming patterns. Messages sent to such Kafka topics are then made available to MQTT clients subscribed to the corresponding MQTT topic hierarchy. This allows, for example, data ingested via Kafka to be fanned out to numerous MQTT-based dashboards or devices.

MQTT → AMQP

FlowMQ facilitates routing messages from MQTT clients to AMQP consumers by leveraging AMQP's exchange and binding mechanisms and mapping them to MQTT topic subscriptions.

How it works: When an AMQP client declares a queue (e.g. q_analytics) and binds it to an exchange (e.g., amq.direct with routing key q_analytics), FlowMQ can automatically translate this binding into an internal MQTT subscription. In this example, FlowMQ would effectively subscribe the AMQP queue q_analytics to the MQTT topic amq.direct/q_analytics. Messages published by MQTT clients to this topic are then routed to the AMQP queue.

Exchange Name in Topic: For amq.direct and amq.topic exchanges, FlowMQ can be configured to either include or omit the exchange name as a prefix in the derived MQTT topic, offering flexibility in topic naming conventions.

Default Bindings: AMQP queues auto-bind to default amq.direct (key=queue name). amq.fanout/amq.topic exchanges auto-bind to wildcard MQTT topic (e.g., amq.fanout to amq.fanout/#).

AMQP → MQTT

To route messages from an AMQP producer to MQTT subscribers, FlowMQ constructs an MQTT topic by combining the AMQP exchange name and the routing key used when the message was published.

How it works: If an AMQP producer sends a message to the amq.direct exchange with a routing key of sensor.temperature, FlowMQ will treat the effective MQTT topic for this message as amq.direct/sensor/temperature. MQTT clients subscribed to this topic (or a matching wildcard) will then receive the message.

AMQP → Kafka

Interoperability from AMQP to Kafka is achieved by chaining the existing routing paths within FlowMQ.

How it works: An AMQP message is first routed to an MQTT topic as described in section 4.4 (AMQP → MQTT). This MQTT topic, now carrying the AMQP message, can then be subscribed to by a FlowMQ stream, making the messages available to Kafka consumers as described in section 4.1 (MQTT → Kafka).

Path: AMQP Producer → FlowMQ (AMQP to MQTT Topic) → FlowMQ (MQTT Topic to Stream) → Kafka Consumer

Kafka → AMQP

Similarly, routing messages from Kafka producers to AMQP consumers involves a two-step process within FlowMQ's unified model.

How it works: A message produced to a Kafka topic is first treated as an MQTT topic as described in section 4.2 (Kafka → MQTT). AMQP queues can then receive these messages if their bindings (translated to MQTT subscriptions by FlowMQ) match this MQTT topic, as detailed in section 4.3 (MQTT → AMQP).

Path: Kafka Producer → FlowMQ (Kafka Topic to MQTT Topic) → FlowMQ (MQTT Topic to AMQP Binding/Queue) → AMQP Consumer

Protocol Ports

Default ports for each protocol:

• MQTT: 1883 (TCP), 8883 (SSL/TLS)
• AMQP: 5672 (TCP), 5671 (SSL/TLS)
• Kafka: 9092 (TCP, SSL/TLS typically on same/different port)

Next Steps

• Learn more about the Architecture
• Check Troubleshooting for protocol-specific issues