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

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

I note that the reporter does not favour reporting a new server, but I'd like to propose an _optional_ uri of a new server. In a couple of use cases it would be useful:

(1) State (buffered messages etc) for some (cleansession=false in 3.1.1 terminology) clients may be migrated from one server to another whilst the client is disconnected. In this case, the source server could remember where state was moved to.

(2) A large distributed system of MQTT servers. In such a system, state for a client may be available on a single server; if the optional URI was available then clients could connect to an initial "routing" server that tells them where their state is (buffered msgs etc). The initial server  acts as directory and would know the state of other servers in the system.

I understand this that there are drawbacks to this suggestion:
 (1) extra complexity and need to consider infinite redirects etc.
 (2) Makes this issue dependent on others: MQTT URI ( https://issues.oasis-open.org/browse/MQTT-203) and optional metadata on non-Publish packets (Connack/Disconnect) (currently I can only find the issue for publish packets (https://issues.oasis-open.org/browse/MQTT-256) though that says metadata on other packets will follow.

I think that the extra flexibility outweighs the drawbacks. If this is not implemented, large distributed systems that allow clients to have server side state (cleansession=false in 3.1.1 terms) have have a solution like:
   (i) All MQTT servers in the system have to be able to retrieve state for any client
   (ii) An intermediate MQTT aware  proxy/load-balancer needs to sit between client & server and direct client connections to server(s) available to access the state for that client.
   (iii) maintain DNS SRV records  specific to particular clientids which does not scale to large numbers of clients  

Thoughts?

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