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

custom connection type #567

Closed
carr123 opened this issue Dec 13, 2021 · 11 comments
Closed

custom connection type #567

carr123 opened this issue Dec 13, 2021 · 11 comments

Comments

@carr123
Copy link

carr123 commented Dec 13, 2021

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
Copy link
Contributor

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
Copy link
Author

carr123 commented Dec 15, 2021

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

@MattBrittan
Copy link
Contributor

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
Copy link
Author

carr123 commented Dec 16, 2021

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

@hub-adda
Copy link
Contributor

hub-adda commented Dec 20, 2021

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
Copy link
Contributor

@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).

@hub-adda
Copy link
Contributor

hub-adda commented Dec 21, 2021

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
Copy link
Contributor

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
Copy link

carrish commented Dec 22, 2021

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

@MattBrittan
Copy link
Contributor

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

@carr123
Copy link
Author

carr123 commented Dec 23, 2021

@MattBrittan very good ! thanks.

@carr123 carr123 closed this as completed Dec 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants