[OASIS Issue Tracker] (MQTT-260) Add a CONNACK code of 'Try Another Server'

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

    [ https://issues.oasis-open.org/browse/MQTT-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62849#comment-62849 ] 

Ed Briggs commented on MQTT-260:
--------------------------------

I am not in favor of returning an alternate URI either.   My reasons are along the lines of what Raphael states above, but slightly different.

1. Before sending the redirect, the SSL handshake (if used) and the client authorization would have to be performed so as to avoid sending the URL to a malicious or unauthorized recipient. Hence the major cost has already been incurred (ssl and auth) at which point simply sending a retain message or a just a regular topic messages with the new URL would be easy to do, and could take advantage of QoS > 0.

2, The redirect (or a subsequent redirect) may land the client on a server which may have stale QoS 1 send state, QoS 2 receive state, or different subscriptions. This could  cause loss, duplication, re-ordering etc. So adding the redirect without also solving the other problems (which are are not going to solve) creates a half-solution.

3. A similar problem is created if this mechanism is used for cross-datacenter disaster recovery, or moving a device (say a car) to a different geographical region.  Supplying the new URL solves the easy part; making the other 'context' move (security, data etc) in a which which is always consistent with the transmission of the new URL is hard.  

4. Ken is correct that the client can simply ignore the message, however for small embedded systems, every variable length string is an invitation to memory exhaustion and fragmentation that is avoided by simply returning a numeric code ( say 42 =  busy).  I think I'd opt for using DNS as I think Raph is suggesting.

5. There is a 'nightmare' scenario for embedded systems in which the wrong URL is sent, and the clients become unreachable forever after.



> Add a CONNACK code of 'Try Another Server'
> ------------------------------------------
>
>                 Key: MQTT-260
>                 URL: https://issues.oasis-open.org/browse/MQTT-260
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: futures
>    Affects Versions: 5
>            Reporter: Raphael Cohn
>            Assignee: Raphael Cohn
>            Priority: Critical
>
> If we add a CONNACK return code of 'Try Another Server', this makes it easier for over-loaded servers to tell clients to redirect. This works in conjunction with MQTT-259, which advocates the use of DNS SRV records.
> Indeed, if we also added server-originated DISCONNECT packets with this return code, we could get clients to cleanly migrate to another server when a server is shutdown for maintenance.
> Please note, I do not favour the server also reporting which new server to connect to. There in lies the route to madness, as it means the current server has to know the state of all the others. That's intimate knowledge.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)