How to fast determine abnormal disconnect and fast restore connection?

[neardreams]

I have two questions:

1. If I shutdown my MQTT broker normally, the client will change it's connection state immediately, but if the MQTT broker (actually it's a Raspberry PI) shutdown by power failure, or network failure, it will take very long time (maybe few minutes or longer) to determine the connection state changed. How to make it faster?

2. If the client is trying connect before MQTT broker is ready or before network is ready , it will blocking a lot of time till it failed then retry next time, how to make it faster?

Thanks for help :)

Nice tool by the way.

[shamblett]

The client is event driven, in scenario 1 it won't know its disconnected until it receives a network event to tell it this so you can't make this faster unless you can somehow make the notification event faster.

In scenario 2 you can't make it faster, the client attempts to connect synchronously when connect() is called, it will keep trying till it succeeds or you call disconnect().

There nothing to stop you monitoring your broker state using some external means, i.e. implement a mechanism that knows if your Raspberry Pi is up or down. I f it goes down the mechanism could just call disconnect() and similarly you could call connect() only when you know your broker is ready.

[neardreams]

The client is event driven, in scenario 1 it won't know its disconnected until it receives a network event to tell it this so you can't make this faster unless you can somehow make the notification event faster.

In scenario 1, I use other client tool , it only take few seconds to change the connection states, but currently my app takes 1 to 10 minutes to change connection state and trigger onDisconnected callback (Running in Android Tablet), I don't need it immediately, but it takes too long.

In scenario 2 you can't make it faster, the client attempts to connect synchronously when connect() is called, it will keep trying till it succeeds or you call disconnect().

I also tried other client tool, it also takes few seconds to connect back when my MQTT broker service goes back. Can I make the synchronously connect timeout shorter? So that It will retry faster? By the way, even I call disconnect manually, that last connect() is still blocking.

There nothing to stop you monitoring your broker state using some external means, i.e. implement a mechanism that knows if your Raspberry Pi is up or down. I f it goes down the mechanism could just call disconnect() and similarly you could call connect() only when you know your broker is ready.

I want the mechanism to be more accuracy to the specific MQTT service so that I can make whole system more reliable

Thanks for your reply.

[shamblett]

What do you mean by 'other client tool'? If mean any other MQTT client then you can't compare it to this one, this client sits atop the the Dart/flutter runtime, its this runtime that generates network events, not android or anything else directly.

When your broker is back it should take the client seconds to connect also, I thought you were saying it takes too long when your broker is down.

You can change the maxConnectionAttempts, this is currently 3.

The connect will block until it succeeds unfortunately, this is why you shouldn't call it if you know your broker is down or alternatively wait for connection.

You could use keepalive, i.e. set a keepalive period of say 2 seconds and monitor the pongCallback, if this is not called your broker has stopped responding to keepalive pings, you can then disconnect which should work as you are now connected.

[neardreams]

What do you mean by 'other client tool'? If mean any other MQTT client then you can't compare it to this one, this client sits atop the the Dart/flutter runtime, its this runtime that generates network events, not android or anything else directly.

When your broker is back it should take the client seconds to connect also, I thought you were saying it takes too long when your broker is down.

You can change the maxConnectionAttempts, this is currently 3.

The connect will block until it succeeds unfortunately, this is why you shouldn't call it if you know your broker is down or alternatively wait for connection.

You could use keepalive, i.e. set a keepalive period of say 2 seconds and monitor the pongCallback, if this is not called your broker has stopped responding to keepalive pings, you can then disconnect which should work as you are now connected.

Thanks about pongCallback, I will try this method :)