add reconnect?

[etimes2008]

add client.reconnect = true? auto reconnect

[shamblett]

This facility will be added in a future release but not on the client itself, there will be a managed client class with auto-reconnect/monitoring/fallback options etc.

[uwejan]

is auto reconnect implemented?

[shamblett]

Not yet, still WIP

[uwejan]

Kindly, Any update on this?

[dxGuan]

Any update on this? Looking forward to this feature.

[uwejan]

This is becoming really important on flutter especially, and some server too, any progress happening ?

[shamblett]

I'm currently working on issue 144, the browser client although its nearing completion, I'll look at this again after this work is completed.

[uwejan]

Any update on this?

[marwfair]

@shamblett Do you have a timeline on about when this would be ready?

[shamblett]

Not at the moment, I'll update this when I have

[zxl777]

As the connection situation of the mobile network changes, mqtt often disconnects. We hope to have a fastest way to reconnect, such as detecting a network change, and checking the following mqtt connection when the phone is on standby or activated, and reconnect if necessary.

We hope to have a perfect solution, thank you.

[shamblett]

Ok but we have to be a bit careful with scope here, the mqqt client is just that, an mqtt client.

The update I envisage will put an auto reconnect api on the client such that you can set auto reconnect on creation and when the client disconnects through its own inernal processing it will attempt to auto reconnect, also a method will be provided to force this externally, i.e if the external environment decides the client needs to auto reconnect(out of standby etc.) it will call this method, the client will not do this automatically be itself if it doesn't trigger its disconnect code.

[shamblett]

Ok, started looking at this now

[zxl777]

Thank you and look forward to your new progress.

[shamblett]

Question for you guys, do you want auto reconnect to work only after an initial successful connection or auto reconnect will always be invoked if set, whether initially connected or not? Codes in BTW, just testing it now.

[zxl777]

auto reconnect to work only after an initial successful connection

[marwfair]

I can see advantages and disadvantages for both ways. If it fails on the first try, like if the device doesn't have a data connection, would we have to manually retry later?

[shamblett]

My original thought was that the auto reconnect mechanism would only kick in if selected after an initial good connection, I think I'll stick to this for now. I'll document the API so it clearly states this.

[liuhong1happy]

When I call "connect" again, why server has two socket connection.how can I reconnect?

[shamblett]

There is no reconnect in the current client, this is what this issue is addressing.

[liuhong1happy]

There is no reconnect in the current client, this is what this issue is addressing.

How can i cache the "socket connection"?

[liuhong1happy]

https://github.com/shamblett/mqtt_client/blob/70e1091a288225439ef3f1ed55b2851b97c5c15f/lib/src/mqtt_client.dart#L299 Only this row code can clear "socket connection", why "unsolicited == false" can do. when call "connect" again, server will has two socket connection.

[shamblett]

OK, I'm not sure what you are trying to do here however the autoreconnect code is now ready for development testing.

Please test against the autoreconnect branch, read the API docs, see if it makes sense. I'll leave this open for a little while before re-publishing for further comments.

[liuhong1happy]

https://github.com/shamblett/mqtt_client/blob/9f787c9d2e7f8436b4c4cd0ab132e40a93b6908f/lib/src/connectionhandling/server/mqtt_client_mqtt_server_connection.dart#L118

this line, dart sdk comment:

Destroy the socket in both directions. Calling [destroy] will make the send a close event on the stream and will no longer react on data being piped to it.

Call [close](inherited from [IOSink]) to only close the [Socket] for sending data.

So, you should call 'destroy' but no 'close'

[shamblett]

Yep OK, updated this thanks.

[shamblett]

The number of tries on the re-connect sequence is currently unlimited, once we go into reconnect we try forever until we reconnect. Do you want a different behaviour?

[uwejan]

@shamblett no, unlimited sounds right. i should come back with better question, am testing.

[uwejan]

am trying to debug the behavior, is it suppose to reconnect and sub to all topics that it was subscribed to once initial connection made, or that has to be re done (re subscribe again).

[shamblett]

There's no automatic re subscription, we don't keep a track of active subscriptions so the client can't do this. To do this you must use a persistent session as per the MQTT spec, then the broker will not expect you to resubscribe. The original connect message you use to initially connect is used on auto reconnect so this will be persisted on auto reconnect. If you do not use a persistent session you have to manually re subscribe again as per the MQTT spec.

[shamblett]

Last call for any testers. I aim to re-publish the package this in the next few days.

[shamblett]

Package re-published at 6.2.0, closing this now, any problems found with auto reconnect should be raised as separate issue.