eclipse-paho / paho.mqtt.golang

Other
2.77k stars 534 forks source link

custom connection type #567

Closed carr123 closed 2 years ago

carr123 commented 2 years ago

hi, i want to add my own connection type, currently i need to modify your code at github.com\eclipse\paho.mqtt.golang\netconn.go in openConnection function, add a new case branch.

case "haha":
       conn, err := HahaConnect(uri.Host, timeout)
       return conn, err

is there a better way to do that, without modifying your code ? thanks.

MattBrittan commented 2 years ago

Unfortunately there is currently no way of achieving this without modifying the library itself. If your broker supports MQTT v5 I'd suggest taking a look at the v5 client because it's design does allow this kind of thing.

carr123 commented 2 years ago

my broker doesn't supports MQTTv5. do you hava any plan to support this feature in this library ?

MattBrittan commented 2 years ago

It's not something I plan to add (you are the first person I've heard from who has a need for this). If you feel that you can add this in a way that does not impact other functionality or add too much complexity then please feel free to submit a pull request.

carr123 commented 2 years ago

hi, i hava added this feature and submit a PR.

GilAddaCyberark commented 2 years ago

Hello, we are interested in such a feature as well, as we look to use OpenSSL TLS library instead of golang default one. @carr123 is it possible to contribute to that PR? thanks Gil

MattBrittan commented 2 years ago

@GilAddaCyberark see PR #569 - @carr123 submitted that PR but I've suggested an alternative implementation. Would be interested in your thoughts on this (had seen it as a very niche request so was keen for a very generic solution).

GilAddaCyberark commented 2 years ago

Hi @MattBrittan thanks for sharing and referring to the need. I looked at PR #569 and is seems fine to our use case. I assume that we can convert tls.config params to openssl context parameters (well, tls is tls). however have a concern that there will be a need other parameters for future transport types. May I suggest a slight modification to it (hope that i'm getting things right):

// connectionArgs is an array of future transport parameters type openConnectionFunc func(uri *url.URL, ... , connectionArgs ...interface{}) (net.Conn, error)

or maybe do it the ClientOptions way: type openConnectionFunc func(uri url.URL, options ClientOptions , connectionArgs ...interface{}) (net.Conn, error)

MattBrittan commented 2 years ago

Thanks @GilAddaCyberark - unfortunately that doesn't work because there is no mechanism to pass the connectionArgs into the library (we don't want to break existing usages so are not changing the API). Having said that you can still accomplish this by passing in a member function (e.g. Setup type foo struct { connectionArg interface{} } func (f *foo) Connect (net.Conn, Error) Connect { // connetc using the args} then pass f.Connect into SetOpenConnectionFunc.

carrish commented 2 years ago

@GilAddaCyberark hi, i(carr123) encounter some problem to summit a PR.
you can summit your PR. refer to #571 good luck.

MattBrittan commented 2 years ago

I have accepted PR #574 which I believe should resolve this request.

carr123 commented 2 years ago

@MattBrittan very good ! thanks.