[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=62859#comment-62859 ] 

Jonathan Levell commented on MQTT-260:
--------------------------------------

"I'm not sure how you can argue it is more complicated for a client to have a list of server addresses to try?"

Imagine a system with 50 servers and the server side state is available on one of those. The client knows where it was connected last but if that server is not available it doesn't know where the state for *that* client is now - without a hint it could be on any of the other 50 and it can't tell so it is likely to lose its buffered messages by connecting to the "wrong" one of the 49 available (and then maybe collect them weeks later when they are old and stale). A system like that doesn't work so would require a MQTT aware load balancer to direct clients to the right server.


> 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)