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

Stefan Hagen commented on MQTT-260:
-----------------------------------

My thoughts on this are, being a) positive about the **optional** "redirect" URI info and b) suggesting two overlapping use case (I consider valid and reasonable, but may be wrong there):

I suggest the "intimate knowledge" to be considered a (hopefully) "adequate knowledge" in the use case mentioned in the description of "when a server is shutdown for maintenance". Imaginable, that the admin shutting down one server, is able to offer either an unspecific "N-1" alternative or a specific "1" alternative.

I further imagine that using this optional "hint", this could be viable migration scenario component, where a soon decommissioned M-Cluster of servers constructs a M to P load distribution equivalent map to a new P-Cluster (which shall take over). I imagine an example, where the machinery and number of a M=3 cluster on machines of low resources, is dynamically migrated to a P=5 cluster with say machines with two times the core number and quadrupled RAM or the like.

Hope this makes sense, feedback appreciated.

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