vertx-mqtt
vertx-mqtt copied to clipboard
vert-x3
Mqtt Client doesn't close connection when there is no reply to CONNECT
Assuming the following happens:
- TCP connect is OK
- Client sends CONNECT
- Waits for CONACK
If the CONACK never is received by the client, but still the TCP connection remains open, then MQTT Client never reports back.
No. As by default a TCP keepalive timeout still is somewhat around two days IIRC.
@ctron, do you think we should have something like "timeout of CONNACK" right?
I guess so. Maybe there already is a communication idle timeout on which the client disconnects which could be re-used.
I think that's a more general question about dead connection detection : does MQTT have PING message ?
@ctron there is not such timeout because it's protocol dependant (like PING frames for websocket, HTTP/2, etc...)
@ctron as @vietj said maybe it's something related to the PINGREQ/PINGRESP at MQTT level. If the CONNACK packet is "lost", the MQTT server should then closes the connection if it doesn't receive the PINGREQ in the timeout specified in the CONNECT packet. What's the broker you are using with the MQTT client. It's also true that the keepalive mechanism can be disabled (if timeout is set to 0 in the CONNECT packet) so closing connection from server side can't happen.
@ctron but it's also true that MQTT 3.1.1 says the following :
If the Client does not receive a CONNACK Packet from the Server within a reasonable amount of time, the Client SHOULD close the Network Connection. A "reasonable" amount of time depends on the type of application and the communications infrastructure.
so it's something that we don't have in the current MQTT client :-(
we should use PINGREQ/PINGRESP with a timeout to create an hearbeat to handle this case
@vietj I don't think that using the PING mechanism is the right solution just because as I said it can be disabled (keep alive = 0 in the CONNECT packet) so it means that client and server DON'T HAVE TO exchanged PINGREQ/PINGRESP.
The client should simply have an option to configure the maximum amount of time it will wait for a CONNACK from the server before it closes the connection. BTW the client has the same problem when sending a PUBLISH for a message using QoS 1 and/or 2. It will not time out while waiting for a PUBACK. Thus, if the server does not send a PUBACK (or it gets lost somehow), the message will remain in the client's outbound queue forever, eventually preventing the client to send additional messages because the max messages in flight limit is exceeded. FMPOV the same time out could be used for both the CONNACK as well as the PUBACK as it should in both cases be (mostly) dependent on the characteristics of the underlying networking infrastructure.
@ctron @ppatierno @vietj WDYT?
