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

Dominik Obermaier commented on MQTT-260:
----------------------------------------

A few thoughts on adding the optional redirect URI:

1. Load Balancers: This probably won't work for deployments where a load balancer / proxy is used before the MQTT broker(s), since the IP would be the same for all MQTT brokers from the clients perspective. 

2. Simplicity: MQTT is designed with simplicity for client implementations. The redirect feature adds complexity, especially if there are multiple return values that represent multiple online brokers. Clients must then either prefer their own broker list (that was configured on the client side) or trust the list received from the broker. Some clients in the wild are offering APIs with a list of brokers to try if one of the brokers is offline, so we need at least a non-normative implementation note.

3. Security: Using redirects needs TLS enabled. Otherwise a MITM attack could redirect the client to a malicious broker. We should at least give a non-normative note that using redirects without TLS is a potential security problem.

4. Large Scale Systems: My view is that MQTT clients should make no assumptions about large scale backend systems and if they communicate to a single broker or a broker landscape. For resilient, large deployments, brokers could take the burden of client session transfer/management (in case of cleanSession=false) instead of making client implementations more complex by dictating clients where to (re-)connect, especially in dynamic environments with a varying number of brokers over time. If load balancers are in the mix (my personal experience is that for most large deployments there is at least one load balancer in the deployment), only the load balancers IP would be exposed to the outside (see 1. ) and this feature (even if optional) would cause more confusion than it would help.

So I agree with the reporter that exposing such intimate knowledge as other server addresses would open a can of worms that would help in some use cases but would be troublesome in many other use cases.



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