Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for mqtt 5.0 #138

Open
l0rb opened this issue Jan 10, 2023 · 1 comment
Open

Support for mqtt 5.0 #138

l0rb opened this issue Jan 10, 2023 · 1 comment
Labels
design Requirements engineering / design decions enhancement New feature or request

Comments

@l0rb
Copy link

l0rb commented Jan 10, 2023

Is support for mqtt 5.0 planned? What are the main obstacles to overcome for this?

@Namoshek
Copy link
Collaborator

Namoshek commented Jan 10, 2023

Depends on how you define planned. I would like to implement MQTT 5 eventually and I'm totally open to thorough and solid contributions, but I have no concrete plans to work on this feature right now. MQTT 5 has quite a lot of new features and also some breaking changes, so the implementation is not as straight forward as one might think. The following is a list of things I know need attention, but it might not be complete yet.

New features which need to be designed and implemented:

  • TTL for published messages (could be a simple addition to publish(), but with retransmission at higher QoS there are edge cases)
  • Additional key-value pairs as header of published messages
  • Return codes for features not supported by the broker (in CONNACK) and client-side deactivation of affected features
  • New additional AUTH message for complex authentication flows (bi-directional)
  • Improved UTF-8 support and new UTF-8 data type
  • Bi-directional DISCONNECT support (to allow brokers to gracefully close connections)
  • Support for topic aliases in subscriptions to reduce the traffic between broker and client
  • Maximum packet size can be configured and communicated by both, client and broker
  • Flow control (allows to limit the send and receive rate)
  • Last Will publish delay
  • Server-side assigned client ids
  • Client redirection (if a broker wants a client to connect to a different broker)

Breaking changes to consider:

  • Reason codes in acknowledgements for improved error handling
  • Replacement of the clean session with clean start and session expiry interval
  • Retransmission of unacknowledged messages is forbidden and only allowed after reconnecting to the broker (new TCP connection)
  • Usage of passwords without username is permitted (probably only validation)

If you are interested to work on MQTT 5, I'm willing to support you. A good start would be some design ideas regarding changes to interfaces and classes, as well as a solid test suite to simplify development.

@Namoshek Namoshek added enhancement New feature or request design Requirements engineering / design decions labels Nov 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Requirements engineering / design decions enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants