Unhandled SocketException in ServerClient mode (errno 121)

[LucaBoss74]

Hi, I think there's a bug in handling reconnection on Client (not websocket) mode. The problem is easy reproducible by launching an MQTT client in secure mode, establish a connection, detach network cable (or power-off wifi) and wait until autoreconnect is triggered.

The Dart VM throws an Unhandled Exception claiming there's an untrapped SocketException with OS Error errno 121.

If we use the WebSocket mode, the autoReconnect works correctly.

[luohao123]

SocketException: Connection reset by peer (OS Error: Connection reset by peer, errno = 104)

how to use WebSocket mode

[shamblett]

Socket exceptions are raised by the Dart runtime not the client. What happens on ypur platform when the network cable is pulled has nothing to do with the client code. The client just picks up the exception and propagates it

May well work in the browser, this is a different runtimr again and websockets are not server side sockets

[luohao123]

Got this error just after server report duplicated id login error.

[shamblett]

Ok sounds like the broker has closed the connection which should be signalled to the client as an onDone event, it seems this is not happening. Ill need a client log to go any further.

Note that Ive never heard of an MQTT broker refusing a connection because the client id is one that has been used before it may do this if you already have a connection active with the same client id.

[luohao123]

@shamblett thank u sir, this the golang broker I use: https://github.com/DrmagicE/gmqtt/issues/203

here is the thing i found for now:

Seems the server got duplicated client_id when I connected, and then, the server will close the old client_id, but somehow, it takes the old client_id as current, so once I just connected, the server just disconnected due to treat this client_id as old one.

Is this could happen? (the link I attached is Chinese, using translate could possibly knows what it means)

[shamblett]

This seems wrong, if when you connected the broker still had an active connection with the same client id, you should disconnect this before trying to connect again. If you have done this then the broker should have closed the connection to that client so when you connect again there is only 1 connection. If the broker at anytime wants to disconnect you or the network fails when you connect again there should be no old client connections with the same id hanging around. If your broker is doing this then its wrong.

[luohao123]

Am not sure whether is broker issue or not, but I changed another broker, same situation found.

Once the client connected, then disconnected imediately. Do u know how could this happen?

[shamblett]

There are many reasons, the only way to tell is to look at your broker logs, the client can't help you anymore.

[luohao123]

Hi, I using test.mosquitto.org, same error got.

[shamblett]

You still ned to look at your broker logs no matter what broker you are using.

[luohao123]

I don't think test.mosquittto.org provides such a log. Is there anything could be possible reason on client?

I look into the mqttclient example code, none of them really work on a real flutter app.

Although it could be same, but in flutter it has more complicated lifecycle, a good mqtt workable example would be very good for users to start with.

[shamblett]

It doesnt, it is just a test to see if the behaviour remains the same. Either way whichever brolker you use only its logs can tell you whats happening.