Reusing the websocket connection

[meehol]

Hey folks,

Been trying to figure this one out for a while:
Is it possible to reuse the websocket connection and attempt to connect using few different clientIds?
Scenario would be multiple widgets that each have a separate MQTTClient yet they all use the same WebSocket connection.

That would neatly scope the subscription event handlers and ability for two widgets (two clients) to subscribe/unsub to the same topic (if UI user wanted to) without affecting the other widget (client).

Not sure if this is even possible at all :)

[robertsLando]

yes you can, you should firstly create the websocket using browserStreamBuilder: https://github.com/mqttjs/MQTT.js/blob/main/src/lib/connect/ws.ts#L161, then you can create your own client new MqttClient(streamBuilder, opts) passing a streambuilder that always returns the previous socket

A bit tricky but should work, streamBuilder also requires an mqttclient in first argument but it's only needed in case you have transformWsUrl option set, otherwise it's not used at all

Your own streamBuilder so could so something like this:

const wsSocket = null /// the socket instance

const myStreamBuilder = (client, opts) => {
	wsSocket = wsSocket || browserStreamBuilder(client, opts)

	return wsSocket
}

const client = new MqttClient(myStreamBuilder, opts)

I didn't tested above code and also I'm not sure about any unexpected issues related to this

[meehol]

Ah darn it, just got your reply with a bit of a delay

[robertsLando]

Try it and let me know, I may be wrong :)

[meehol]

Aye! will update here

[meehol]

Hey @robertsLando, you mentioned i should pass a MqttClient to browserStreamBuilder not sure how to go around, isnt that a circular loop? i need a stream to create a MqttClient, chicken egg problem? :D

[robertsLando]

@meehol nope because the buildStream function is passed down to the constructor of MqttClient and it's him that call the function by passing itself:

MQTT.js/src/lib/client.ts

Line 760 in 72c008d

this.stream = this.streamBuilder(this)

[meehol]

Darn it, your suspicion was correct, the broker (FlashMQ) does not like that idea.
Removing client (...) Reason(s): Client already sent a CONNECT.
Trying to out to the broker authors to see if anything can be done. Will post a final update once i hear back

[meehol]

Alright, the other guys confirmed what i suspected as well:

(...) Websockets don't have 'streams' as HTTP2 does, so this would fundamentally be problematic,
because it would not be clear which client receives which bytes.

@robertsLando
To solve my problem what is your opinion, out of the two:

• Option 1: would you go down the path having multiple websocket clients, each per widget to isolate subscribes and simplify onMessage handlers?
• OR Option 2 would you try to create on client and some sort of smart Store to keep track of value on a given topic and which components subscribed to that topic - that way you always have the value handy if another component tries to subscribe to the same topic and also you wont call .unsubscribe on destroying the component (like a modal) if there are other components that listen on that topic, to avoid disconnecting the subscription

[meehol]

Some information for Option 1: (simplicity, but separate ws connection overhead) – modern browsers allow up to 256 Websocket connections, that’s plenty, I’d limit each dashboard to ~50 widgets/components per page, plenty of overhead left.

Option 2 needs solid engineering but done properly could work really well too!

Thank you for all the help @robertsLando! ✌🏼 happy coding!

[robertsLando]

@meehol I'm already using option 2 in a dashboard project that's using widgets and it's what I suggest to you. I had to recreate kind of a WidgetsBroker that handles all widgets subscriptions and forwards the packets to the correct widget based on their subscriptions. Not so hard :)