[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=33646#action_33646 ] 

Raphael Cohen commented on MQTT-4:
----------------------------------

Thinking things through, I'd tend to agree, although leaving it as an option for clients + a clear caveat in the spec (eg a client MAY if it desires, but should be aware...)

In other mq-like protocols, support for this sort of thing does exist, and does get used. However, it's not a particularly common need, and it's not something I've ever put into a client solution.

Two use cases, though, where this would have some advantages:-

- WebSocket connections, where the handshaking, TLS, etc has effectively already been done, so Nick's third point is mitigated somewhat - useful for sending immediate 'I'm here' presence messages, and if one wanted to use MQTT as an efficient pipelined CDN... by sending CONN, then a subscribe immediately...
- Sensor 'bursts' - connect, send a burst of data, disconnect; if the events don't get through, not a problem for these events. Suitable as a mode of operation only for very constrained devices with completely throw-away data, particularly where they operate on a link with deeply asymmetric send-receive bandwidth that's potentially quite expensive (eg satellite broadband paid by the second of connectivity)

In the latter use case, client side processes would use heuristics to identify sensors not 'observed' for some time.

So, in summary, it does little harm to make it clear that it's possible - it's never going to change broker design one jot - but strongly suggest not using it.


> 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
>          Components: core
>         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