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

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

Ken, Jonathan,

A request URI is exactly what we added to AMQP 1.0. And you know what? It was unusable. In real-world use, it caused all sorts of problems and misunderstandings. It played merry hell with WebSockets tunnels, as it had no easily understood meaning. It didn't differentiate permanent from temporary redirects. Add in TLS, and life got harder still. What about topic redirects? Oh, the joys. Please, I beg of you, don't do this. We'd better off with no code at all than a URI. Please, please let us learn from the mistakes of the past. Those that ignore history are doomed to repeat its mistakes.

Dominic's point about security is completely valid. It could be partly mitigated by incorporating one of my other proposals, a CONNACK code 'upgrade to TLS', but I withdrew that as I believe this could be maliciously used. Additionally, it is likely that TLS will not be the transit of choice for deployments a few years from now. I'm already experimenting with MQTT over other TLS replacements. Likewise his point about conflicts between the client list and the server list - exactly the like of which occurred in AMQP...

The point of my suggestion was very simple - it simply means try another server - I am unavailable. The idea that a client is MORE complex with this coding should be seen as absurd. If it isn't, then my proposal is probably misunderstood. And, frankly, what is so hard about DNS SRV records? Indeed, the point of my proposal is that you don't have to use these. One could use LOC records, or apply that RFC about ordering to round-robin A / AAAA records (indeed, I vaguely recall the Windows resolver doing exactly that - I may be wrong, of course). Or use a hardcoded list. Or assume the list of HTTP servers it has configured for its REST services are the same as used for MQTT over Websockets. Or whatever. In other words, the necessary information is out-of-band, its source can be changed without changing the protocol and simpler set ups or ones we haven't yet envisaged aren't handicapped. Lastly, if the redirect URI is just an authority section, then it is no better than a A record, and is as handicapped...

If necessary, we could use more than CONNACK code to make error reporting more useful. However, in practice, a client needs to know for any error code:-
- Is this a permanent failure, full stop, give up (eg you're not authorised)
- A temporary failure, try this connection again
- A more permanent failure, try another connection
- Permanently redirected

In practice, the last scenario is nearly always handled by either a firmware update, or a client configuration update, or by publishing information to DNS. The only variant of this scenario that is hard to do with my proposal is a 'split' - where one sells 50% of a truck fleet to DHL, and keeps the rest. However, if using DNS SRV, a temporary proxy server could return this CONNACK based on the client's id. In this scenario, the client needs to know whether its configuration data is stale. However, it is not normally practicable for a broker to know that...

I'll reiterate. Please let us not add a redirect URI. MQTT is currently very simple. Let's not make it complex.

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