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

Raphael Cohn commented on MQTT-260:
-----------------------------------

My reply to Stefan's point seems to have been lost:-

"My intention here is to have a very simple mechanism that can be used many ways - and not just traditional it adimn. Eg When migrating a cluster, eg because a fleet of trucks was sold to a new operator. (Something that actually happened to me in a previous life). One way to use this is a shutting down a server removes itself from a DNS srv record; a starting server adds itself. This allows elastic scale up and down. No Uri req'd. During migration the srv record is a mixed m and p. No server needs know about any other. Booting from AWS images etc is simple. A server could even algorithmically turn its ram etc sizes into a weighting in srv."

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