[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-260) Add a CONNACK code of 'Try Another Server'
[ https://issues.oasis-open.org/browse/MQTT-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63689#comment-63689 ]
Raphael Cohn commented on MQTT-260:
-----------------------------------
"Try Another Server"
I've been thinking about this on and off over the last few days, and the consensus view from the F2F is that we'd like to return additional information via MQTT without requiring a client to need out-of-band knowledge, or to use a REST service, DNS, etc, if possible. John was also quite keen that a low level client library should be able to take advantage of this information, so it can manager reconnects, redirects and the like. I was worried about what we screwed up with AMQP. And there is also uncertainty about whether a client can expect state to exist on another server. Ken was keen for a server to be able to return a list. Ed suggested an optional value.
I've gone through some thought experiments, and played with some scenarios, and I think we might be able to reach consensus on a large number of useful scenarios with something akin to a URI. It looks to me something a bit like a hybrid between a URI and a textual DNS record might work well.
So here goes. The syntax I then describe below is not meant to be what we might use, but just to express what we need. I'm going to address a bunch of scenarios, and give some suggested needs. These are in no way exhaustive.
A. Manfacturer supplied hardware, shrink-wrapped and new
(Because we like option A and B language (;-) )
- No way for an installer to change anything on it (no serial port, no USB initialisation, etc)
- Has been coded to connect to an initial server;
- Can't be sure DNS or DHCP exists or is reliable;
- Presents the server with what we've been calling client-id (probably a UUID or similar)
- client id is on a sticker on the device
- Needs to be permanently redirected; installer probably registers the device's client id on a web form provided by the manufacturer and starts it up
- Options
- (1) If not registered yet, gets told to disconnect
- Needs to be told how long to wait until reconnection, to stop thrashing of a server
- Could be hardcoded, or a could be a timer supplied on CONNACK
- (2) If registered, receives our 'redirect' data; needs to know this is permanent
- (3) Needs a firmware update, then needs to be redirected to the permanent server
- Initial connection, does PUB / SUB
- Then receives a server DISCONNECT. Permanent redirect.
B. Decommissioning for Recommissioning
- A sort-of reverse of A. The device needs to be redirected to the manufacturer's provisioning server, permanently, and lose all state.
C. Manufacturer out-of-business but third party support exists
- Effectively recommissioning, but needs to be redirected permanently to a third party or enthusasists server. The redirection details are for a different server than the one it originally provisioned against. So they can't be hardcoded or burned into the device (This is similar to a real world problem we had in 2010).
D. Server down for maintenance
- Needs to temporarily use another in the group. CONNACK codes needs to be on both DISCONNECT and CONNACK. If there are no other servers, the client would benefit from a timer so that it can sleep or power sip; useful for low power devices to (a) save power and (b) preserve expensive bandwidth, multiple TLS setups, etc.
E. Disaster Recovery, Back Up site has state
F. Disaster Recovery, Back Up site doesn't have state
G. Anycast / Legal Entity scenarios
- eg devices in Germany must connect within Germany but others could connect to German servers if their local ones are kaput (eg in a partial overload scenario, migration of a data centre, etc). So client id differentiation needed.
H. Server split due to load (John's case)
Per client-id split. Effectively a permanent redirect. State may or may not be present; state might take a while to get to the new server, so the client could benefit from a timer to prevent reconnection until migration is likely complete.
I. DDoS scenarios
Providing a timer, which a persistent offender ignores, allows a broker to make a more informed decision that a connecting client is trying to DDoS? Not 100% sure about this.
J. Selling off some electric trucks (Raph's scenario)
Permanent redirect of some, but clients need to keep state but flush their configuration.
So, with all those scenarios explored, here's a suggested configuration string / blob by example (syntax not necessarily what we want):-
1. 10:NONE:
5. :IPv4:8.8.8.8
6. 0:IPv6:8.8.8.8,10.11.12.13:1234
2. :SRV:_mqtts._tcp.mqtt.com [could be shortened potentially to mqtt.com]
3. :NAME:broker2.mqtt.com
4. 100:DNS:name:brokers.mqtt.com:1234
* The first part is a timer (optional)
* If the timer is 0, this is a permanent redirect.
* Otherwise it is seconds / power of 2 seconds (more useful, more controversial I suppose) in which the client shouldn't attempt reconnection to this or any other server
* The second part is the kind of configuration (NONE, DNS, IPv4, IPv6)
* NONE means there is no configuration data supplied; do your own thing. This could just be omitted (eg the minimum record is then just ':')
* IPv4 means use IPv4. A list of one or more ip addresses follows. Ports are optional. IP addresses can be repeated, but only if ports differ. It is an error to have a specified port for an IP address X be the same as the IANA default for another entry for address X (clumsily written).
* IPv6 means use IPv6. A list of one or more ip addresses follows. Ports are optional. IPv6 addresses should not use [] and should ideally be in a canonical form, but we probably can't mandate that. IPv6 address parsing is a royal pain in the neck... Points as above for IPv4.
* There is an argument for combining IPv4 and IPv6 into one list, but a broker will know if a client has connected over IPv4 or IPv6 and can offer what's appropriate.
* SRV means a SRV name to look up. There's no point in a list for this. We could omit the '_mqtts._tcp' stuff
* NAME means either a CNAME, A or AAAA record type. I'm not sure being more specific is very helpful. The name to look up can optionally be followed by a port identifier. There's less value in a list, as a A / AAAA record can return a list. Of course, we could have a list, and then what does a client do when presented with several sets of IP addresses? F88k8d if I know. And that was exactly the problem we had with AMQP.
* Both SRV and NAME's data is case insensitive and follows RFC rules for valid DNS names
* We probably should omit the final '.' from the DNS name (we need to be specific about this)
* We should permit punycode / IDNA cruft, although since the data is effectively pass-through, this is unlikekly to be a burden
Notes:-
* This configuration string should be possible on both CONNACK and DISCONNECT.
* "Try Another Server" CONNACK code should be possible on CONNACK and DISCONNECT.
* This syntax doesn't provide a way to assign a new client id on DISCONNECT or CONNACK. That seems an interesting thing to do if 'moving' a client's state, or recommisioning, but not essential and potentially confusing.
* We also need to offer advice on what to do if the list of servers, once turned into IP addresses, contains the server currently connected to. This goes for both NAME and SRV (as a SRV record can resolve to multiple A records with multiple IP addresses).
* This configuration string is entirely optional, as per Ed's suggestion.
* This configuration string says nothing about what a client should do if using TLS SNI. One scenario, one I'm not very keen on, is connecting to a generic TLS server (eg tls.mqtt.com) and setting the SNI to be, say, the value in a NAME above. TLS SNI is insecure in any event.
* The configuration string does not suggest a protocol version. If this is wanted then it can be negotiated via ALPN in TLS. If a client only supports one protocol, then providing alternatives isn't very useful to him.
* This configuration string has the potential to be problematic for WebSockets clients, who would not necessarily be able to handle them
* This configuration string effectively ties us to TCP / requires the client to continue to use the network socket protocol they connect on. In practice, I think it's unlikely to be much an issue. I can just about see a TLS over TCP upgrade t QUIC over UDP, but that's going to require a major client change in any event with new firmware and the like. This is similar to the MQTT / MQTTS point above.
* In this syntax I have omitted state: this is because it may be best to just offer the advice that clients should anticipate they might not have state on the redirected broker(s).
* I have also omitted stating use of MQTT or MQTTS. I feel this is a client decision. If a client has connected over TLS to a broker, and been redirected, why should he then want to use non-TLS? The broker also knows (except in some specialised load-balancer terminated scenarios that frankly, are a bad idea in this day and age if one cares about confidentiality) that the client is using TLS or not. And returning this configuration string to a non-TLS secured connection is as bad as my suggestion for an 'Upgrade to TLS' code - it's fundamentally insecure. Either a client uses TLS or he doesn't. And most will. Especially post-SHODAN...
* I'd also like to explore embedding an equivalent of DNS SRV in this syntax, and a DHCP configuration type name (meaning get it from DHCP; mechanism not yet defined). However these are much less important to me, and might be done at a much latter stage as small committee notes or some such. My rationale for the former is that it completely eliminates the need for DNS. Note that I have avoided adding weighting or preference information. This is very much a client decision. Some DNS resolvers (eg Windows if I remember) also can calculate shortest routes and so avoid round-robinness (nice). (See point 2 below)
* I'm also open to additional configuration types, that specify, say, a LDAP record, JSON, or a URL to a REST service to retrieve configuration details. To my mind these are quite specialised and I think should probably be prefixed X- or some such. (eg X-LDAP). If we allow client metadata on CONNECT, then they are potentially useful. (see point below)
* However, all the current suggestions (NONE, IPv4, IPv6, SRV, NAME) can be implemented straightforwardly by most clients, in most cases, just by delegating to a third-party DNS resolver and IP address parsing code. The DHCP, LDAP, HTTP, etc suggestions are much more complex and difficult to support, and, in many ways, don't need protocol support; if a client gets a redirect, with data they don't want to use, and is configured via LDAP, say, it's free to ignore it.
Overall, I'd like to talk about this on this week's call. I'm happy to move forward with people to draft something (Nick, John, Ed or Ken)?
> 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]