search

eclipse-paho / paho.mqtt.golang

Other
2.77k stars 534 forks source link

When to support quic protocol? #608

Closed Gypsying closed 2 years ago

Gypsying commented 2 years ago

With the quic is developed，mqtt over quic is needed. Will appreciated to got the release which support quic transport protocol.

MattBrittan commented 2 years ago

There are no plans to implement QUIC support (but pull requests would be considered).

This is probably something that could be done separately as a CustomOpenConnectionFn if you are just using QUIC to establish a pipe. However QUIC has some overlap with MQTT (e.g. at-most-once message delivery guarantees) so implementation may be more involved. Until the major brokers support this (EMQX has an experimental QUIC transport) I'm not even sure what QUIC support would look like.

Gypsying commented 2 years ago

There are no plans to implement QUIC support (but pull requests would be considered).

This is probably something that could be done separately as a CustomOpenConnectionFn if you are just using QUIC to establish a pipe. However QUIC has some overlap with MQTT (e.g. at-most-once message delivery guarantees) so implementation may be more involved. Until the major brokers support this (EMQX has an experimental QUIC transport) I'm not even sure what QUIC support would look like.

Thanks for your reply!

Maybe can integrate with the quic-go? There has a implementation: Evaluation of QUIC in Industrial IoT Scenarios which used the quic-go to implement the quic protocol; Open and close connections, or send and receive packets, are managed by paho.mqtt.golang's net.go interface.

paho.mqtt.golang just need to involve minor changes to support quic connection.

MattBrittan commented 2 years ago

Anyone is most welcome to add support via SetCustomOpenConnectionFn. I feel that cost of accepting this into the main library (complexity, impact on executable sizes, increase in dependencies etc) currently outweighs the benefits (note that the report authors fork does exactly that and should be relatively simple to adapt). This may change if QUIC becomes something supported by a range of brokers and the benefits become more apparent (currently this is probably of most interest to those pushing a high volume of messages over poor quality links).

Note that I would be happy to create a folder off the main project to contain new custom open connection functions so that these are available to all users (I feel this provides 95% of the benefits of implementing these within the library without any of the disadvantages of doing so).

Gypsying commented 2 years ago

Yes, you are right, Support custom connection would be a more appropriate method. I will have a look SetCustomOpenConnectionFn, thanks!