OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

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

Ken Borgendale commented on MQTT-260:
-------------------------------------

I am glad we are moving toward consensus.  Raph, thanks for the analysis of the requirement.  Personally I do not see how you could convey everything you need to provision a client to an arbitrary server with just this information, but there are some good use cases which work with a limited set of information  I would like to comment on the syntax of the return string.

It is not clear why we would invent our own syntax rather than using a URI.  There are of course many flaws in the design of URI especially in the area of globalization, but it is heavily used and there are quite a number of tools to support it. If what we are trying to convey here is primarily the authority portion of a URI, we might just restrict to that, or indeed to just host and port but encoded URI style.

I presume that the only two schemes we are really interested here are mqtt and mqtts so we could easily say that we have a relative URI which uses the scheme of the original connection.  I do not think we want to try to convey the TLS options necessary to connect.

It is not clear why we need to specify the type of the authority; we again have standards for how this is represented.  The canonical IPv4 IP address is not valid as a DNS name, and either the hostname or service can be name resolved.  The only issue is the IPv6 IP address which optionally contains a colon and therefore has an issue with URI parsing which is resolved by the use of brackets.

The convention of not specifying the port in an authority is to use the one you get from name resolution, and otherwise use the default port for the scheme.  I do not understand the point about the specified port and IANA registry.  I assume you are saying that we should not be getting two equal authorities in a list after name resolution.  While there is very little point of this, I do not see why it needs to be an error.  Detecting this error is not simple and requires that you do name resolution of all entries in the list even if the first one works which is not common practice. In the case of DNS resolution it is common to get back a list for each name.   

I would prefer to use multiple return codes to indicate the difference between a permanent and temporary redirect (as is done in HTTP).  It is not clear to me that we need various settings of temporary but if this is really found to be required we could just pass back another value.  Alternatively you could use the URI query section for this.


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