[OASIS Issue Tracker] Commented: (MQTT-4) Flowing MQTT messages before CONNACK is received in the client.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/MQTT-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33323#action_33323 ] 

Nick O'Leary commented on MQTT-4:
---------------------------------

I believe we are only talking about the CLIENT sending packets before it receives the CONNACK. We are not talking about the SERVER starting to send packets in response to the CONNECT ahead of sending the CONNACK (which is not allowed).

As such, no existing clients would be broken by this as it is the server that has to tolerate the packets arriving earlier than they would otherwise. Most servers I am aware of are single-threaded at the point of handling an individual client's connection - ie, even if the server is multi-threaded, it won't have multiple threads service the same client connection in parallel.

In the scenario that the client's connection request is refused - authentication failure for example - the client may start streaming up QoS 0 messages which will get instantly dropped by the server as it has not permitted the connection. The application will get no indication that the messages were dropped. Of course QoS 0 is fire-and-forget, but I would be concerned about introducing a scenario that allows them to be so readily thrown away.

If we were to permit this, the language in the spec needs to make this risk clear.

As for client implementations, I'm not convinced there is much simplification to be had here. You have to police the connection state to handle asynchronous disconnect events anyway. (Of course this point of view may be skewed by having done it so often...).







> Flowing MQTT messages before CONNACK is received in the client.
> ---------------------------------------------------------------
>
>                 Key: MQTT-4
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-4
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>         Environment: MQTT Client
>            Reporter: Andrew Banks
>
> The MQTT Client sends CONNECT and receives  CONNACK in response. Should the client have to wait for the CONNACK or is it free to send other commands before it receives the CONNACK?
>  The advantages of allowing the client to proceed before receiving the CONNACK are:
> 1) Simpler client implementation, because the API does not have to police the connected state.
> 2) Lower latency because the client application does not have to wait for the CONNACK.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira