Client triggering disconnected signal only after recovering connection

[SirHeisenberg]

Hello!

I'd like to report what I think it's a bug. Maybe it's because I'm missing something though.

When my client loses connection itself (client loses connection within the network) it doesn't trigger the disconnected() signal until it recovers connection again.

If it's the broker the one who loses connection the client triggers the disconnected() signal instantly, but as I mentioned before, if the client is the one who loses connection the signal isn't triggered until it recovers connection.

I don't know if there is another option to know if the client has connection apart of pingresp, which only lets me know when I have connection but not when I lose it.

Thanks.

[mwallnoefer]

From my point of view disconnected() should only be triggered when a disconnect operation has been requested explicitly (disconnectFromHost()). Otherwise you have the possibility to handle this in the onSocketError()?

[SirHeisenberg]

From my point of view disconnected() should only be triggered when a disconnect operation has been requested explicitly (disconnectFromHost()). Otherwise you have the possibility to handle this in the onSocketError()?

What class does onSocketError() belong to and which signal would trigger it?

[mwallnoefer]

The socket errors are forwarded to the error signal of the class Client. Look at the ClientError enum for a complete enumeration of all values: https://github.com/emqx/qmqtt/blob/master/src/mqtt/qmqtt_client.h.

[SirHeisenberg]

I have the same problem, the error signal doesn't get triggered until I recover connection.

So when the client recovers connection it trigger both signals: error and disconnected.

[mwallnoefer]

Okay, so let us ask someone else: @ejvr, @KonstantinRitt any idea what the reason could be?

@SirHeisenberg Have you tried also with a different client OS? Not that this issue is pertinent to the underlying socket API?

[SirHeisenberg]

@mwallnoefer I tried it in a Raspberry Pi and in a machine with Ubuntu, both have the same issue

[mwallnoefer]

Yes, but these are both Linux and hence will behave similarly. Here it would be interesting to reproduce on an alternative system like MacOSX, iOS, Android or also Windows since this could perfectly be a bug in Qt (= a misinterpretation of the OS' socket API semantics).

[ejvr]

It seems to be a Linux specific thing. To test this I modified the example application to log disconnect and error signals, and enabled the auto reconnect.

On windows 10 you see an error and a disconnect message in less than one second after disconnect (I pulled out my network cable from the client system to force disconnection).

Trying the same thing on my Linux system (a beaglebone block running debian v9) gives the same result @SirHeisenberg reports: there is no error message and no disconnect. However, when I plugged the network cable in again, the example program simply continued receiving data on its subscriptions. So it seems the socket has never been closed at all.

I also noticed that my SSH session to the beaglebone was not closed either, and I could use it again after plugging in the cable.

So, to me this seems to be some kind of Linux oddity. I'm not sure if we have to fix this (can we fix this?) in QMQTT.

[mwallnoefer]

Thanks for the reproduction, @ejvr.

So yes this seems to be a Qt - GNU/Linux-specific issue, look at: https://bugreports.qt.io/browse/QTBUG-16688

Also interesting (more to Windows): https://bugreports.qt.io/browse/QTBUG-24451 https://bugreports.qt.io/browse/QTBUG-39518

Maybe Qt 6 will handle this better? https://bugreports.qt.io/browse/QTBUG-75638

[ejvr]

Hmm, the fact that my SSH session was not disconnected either when the network cable is unplugged suggests that this is not a QT issue, but a Linux 'feature'.

We could check what happens if the network connection is closed in software (eg. using ifdown). I guess that the operating system will immediately close any related sockets.