Waterstream MQTT v5 Support

Starting from version 1.3.0 Waterstream supports version 5 of MQTT protocol. And from version 1.3.3 all relevant features are supported.

Supported features

Waterstream version 1.3.5 supports all relevant MQTT v5 features:

  • Session expiry according to “Session Expiry Interval” property of the CONNACK packet

  • Message expiry according to “Message Expiry Interval” property of the PUBLISH packet.

  • Reason codes on all ACKs messages - easier debug of issues with CONNACK, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT packets

  • Server DISCONNECT in case of some issues rather than just dropping the TCP connection

  • PUBLISH packet metadata properties - payload format, content type, response topic, correlation data, user properties. If the publishing client provides them, such properties are passed to the consuming client.

  • Flow control - client may specify how many in-flight messages it can take. Also the server reports to the client how many it can take. Server puts sending messages on hold if this limit is reached. Clients that send messages beyond this limit are disconnected.

  • Maximum packet size - server reports to the client maximal packet size it supports. Client can also specify maximal packet size it can take. Messages that are bigger than this limit are skipped.

  • Server feature availability - server reports to the clients in CONNACK properties which features does it support

  • Subscription options - more fine-grained subscription tuning, such as NoLocal (don’t send back to the client the messages it send to the server), skip retained messages etc.

  • Assigned ClientId - if client didn’t specify ClientID, server reports back to the client ID it’s using for this connection.

  • Last Will delay - client may specify a delay between the end of connection and sending the will message. Thus, brief interruptions will not trigger Last Will sending.

  • Topic aliases - ability to decrease the size of PUBLISH messages by replacing long frequently used topic names with the numeric values.

  • Subscription ID - clients may assign identifiers to subscriptions and have them returned back in the messages, in order to track which subsystem requested the message.

  • Shared subscriptions - somewhat like Kafka consumer groups: multiple clients may share the subscription with each message ending up in one and only one of those clients.