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

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

I've got two possible answers on your questions. On one hand, making this normative gives the most utility to client library implementations to 'do what's right', thereby satisfying John's observations, I think. However, that potentially comes at some cost for some implementations. The opposite view is the one I espoused last week, but that's not necessarily useful, either. I'm beginning to think we make all of this a MAY (as was your original suggestion) but I'm no way nailed on it. It'd be really helpful to try to understand your use cases too. I'm open to not including the timer processing as part of this. Indeed, we could make it non-normative, or not even include it. I do feel, though, that it is needed for quite a number of real-world cases. It could be a separate item of metadata as Ken suggests.

Whatever we do, I'd like to make sure it's clean, consistent and easy to understand. Having implemented the mess of AMQP's approach in the past, I can categorically say there are a lot of edge cases, and we do need to offer some advice at the very least. Hence my observations about duplicates, default port numbers, what to do with lists of lists of IP addresses, etc. Whatever we advise I want it to be helpful to implementors.

From a syntax point of view, I'm in favour of whatever is easy to 'parse' into tokens using, say, String::split(":"); most programmers aren't great with true parsers, and forcing some horrible mini-one seems unpleasant for them... a simple syntax should  also allow tiny clients to avoid memory allocation whatsoever - eg they can just use offsets into the receive buffer... (so a split-friendly syntax is a good choice; and what's sauce for the goose is also sauce for the gander, ie what's good for tiny embedded stuff is often good for giant overloaded internet servers).

Commenting specifically on URIs, the world of tools and the like is a minefield. For instance, Java itself has had a number of implementations over the years, official and semi-official (eg Google's), all of which enjoyed subtle brokenness. In the dynamic language space, I've had the joy of working with the '+' vs %20 mess. URIs also really don't work well for SRV records and other possible stuff people might want to do. Lists for instance. There's more, but I'd really like to avoid a back and forth on this Jira with tomorrow's call coming up.

Forcing quarts into pint pots is what I'd like to avoid.

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