Background
We are evaluating Redpanda Connect for use in our data pipelines, but this use case requires MQTT v5 support, which currently does not exist for Redpanda Connect. Currently only MQTT v3.1.1 is supported via the mqtt input and output using the paho.mqtt.golang library.
Prior Work
There were two prior attempts to contribute MQTT v5 support to Redpanda Connect:
Kafka Connect Equivalent
There is no Kafka Connect equivalent since the Kafka Connect MQTT source connector is also based on an MQTT v3.1.1 paho library.
Proposal
We would like to contribute a new mqtt5 input and output component. Per §3.1.1 of the CONTRIBUTING.md, code written by non-Redpanda engineers needs to be reviewed and scoped by Redpanda. We are opening this issue to ask for comments on two points:
- Is an MQTT v5 input and output component still desired/wanted by Redpanda?
- Is the following scope properly sized for a MQTT v5 input and output component?
Intended Scope
- A new, separate
mqtt5 input and output component.
- Written in Go and based on paho.golang. This library is written by the same authors as the mqtt.paho.golang library that is already in use with the
mqtt connector.
- Code structure will mirror the existing
mqtt connector where it makes sense.
- All configuration fields shared with the existing
mqtt connector are carried over unchanged
- New
mqtt5 input config options:
| Field |
Notes |
session_expiry_interval |
How long the broker retains session state after disconnect. |
receive_maximum |
Maximum in-flight QoS 1/2 messages the broker may send to this client simultaneously. |
maximum_packet_size |
Maximum packet size this client will accept from the broker. |
no_local |
Subscription option: do not receive messages published by this client. |
retain_as_published |
Subscription option: preserve the retain flag from the original publisher. |
retain_handling |
Subscription option: controls whether retained messages are sent on subscribe. |
topic_alias_maximum |
Maximum number of topic aliases this client will accept from the broker. 0 disables topic aliases. |
subscription_identifiers |
Enables the use of subscription identifiers by the client. |
will_* |
Full v5 will message config. |
- Metadata set by the
mqtt5 input:
| Metadata key |
Source |
mqtt5_user_properties_<key> |
User Properties from the PUBLISH packet. If a key appears only once, it is stored as-is. |
mqtt5_user_properties_<key>_<idx> |
User Properties from the PUBLISH packet can have the same key multiple times. If this happens they receive a zero-based index as a suffix |
mqtt5_content_type |
Content Type |
mqtt5_payload_format_indicator |
Payload Format Indicator |
mqtt5_response_topic |
Response Topic |
mqtt5_correlation_data |
Correlation Data |
mqtt5_subscription_identifier |
Subscription identifier sent by the broker |
- New
mqtt5 output config options:
| Field |
Notes |
session_expiry_interval |
How long the broker retains session state after disconnect. |
message_expiry_interval |
Per-message TTL. Broker drops the message if undelivered before expiry. |
topic_alias_maximum |
Maximum number of topic aliases this client will use when publishing. 0 disables topic aliases. |
will_* |
Full v5 will message config. |
- Metadata read by the
mqtt5 output:
| Metadata key |
Written to |
mqtt5_user_properties_<key> |
User Properties on the PUBLISH packet. Plain keys (mqtt5_user_properties_<key>) are written as single entries. Indexed keys (mqtt5_user_properties_<key>_0, _1, etc.) are reassembled into multiple User Properties with the same key, preserving order. |
mqtt5_content_type |
Content Type |
mqtt5_payload_format_indicator |
Payload Format Indicator |
mqtt5_response_topic |
Response Topic |
mqtt5_correlation_data |
Correlation Data |
- Other MQTT v5 Behavior:
- Shared Subscriptions are supported by the underlying library.
- Reason codes will be surfaced in error messages.
- Server-initiated DISCONNECT is handled by the underlying library.
Background
We are evaluating Redpanda Connect for use in our data pipelines, but this use case requires MQTT v5 support, which currently does not exist for Redpanda Connect. Currently only MQTT v3.1.1 is supported via the
mqttinput and output using the paho.mqtt.golang library.Prior Work
There were two prior attempts to contribute MQTT v5 support to Redpanda Connect:
Kafka Connect Equivalent
There is no Kafka Connect equivalent since the Kafka Connect MQTT source connector is also based on an MQTT v3.1.1 paho library.
Proposal
We would like to contribute a new
mqtt5input and output component. Per §3.1.1 of the CONTRIBUTING.md, code written by non-Redpanda engineers needs to be reviewed and scoped by Redpanda. We are opening this issue to ask for comments on two points:Intended Scope
mqtt5input and output component.mqttconnector.mqttconnector where it makes sense.mqttconnector are carried over unchangedmqtt5input config options:session_expiry_intervalreceive_maximummaximum_packet_sizeno_localretain_as_publishedretain_handlingtopic_alias_maximumsubscription_identifierswill_*mqtt5input:mqtt5_user_properties_<key>mqtt5_user_properties_<key>_<idx>mqtt5_content_typemqtt5_payload_format_indicatormqtt5_response_topicmqtt5_correlation_datamqtt5_subscription_identifiermqtt5output config options:session_expiry_intervalmessage_expiry_intervaltopic_alias_maximumwill_*mqtt5output:mqtt5_user_properties_<key>mqtt5_user_properties_<key>) are written as single entries. Indexed keys (mqtt5_user_properties_<key>_0,_1, etc.) are reassembled into multiple User Properties with the same key, preserving order.mqtt5_content_typemqtt5_payload_format_indicatormqtt5_response_topicmqtt5_correlation_data