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

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

Raph: I do not understand the distinction you make between brokers and servers.  The MQTT spec only talks about servers and does not deal with issues of the internal organization of the server or how it stores session state.  I have always treated people using the term broker as just a synonym for server, similar to the use of device as a synonym for client.  The MQTT spec also does not talk about the internal organization of the client, even though we commonly talk of a separation between a client library and a client application in our discussions. 

There is some concern raised that returning a string value as well as a return integer value complicates the client.  I do not understand this  One of the originally stated goals of optional fields (nee metadata) is that the receiver can ignore them other than to skip over them.  The cost to a client not using this function might well be zero.

There is some concern raised that returning a reference to another server poses security concerns.  If exposing the location of a server is considered a problem, then the server can fully authenticate and authorize this client before sending this return string,  In HTTP it is suggested but not required that authorization be done before redirection.

The reality is that in HTTP redirection is very commonly used even though similar functionality can be achieved using DNS or other out of band methods.  There is of course a significant difference in that for HTTP the request includes the path and in MQTT you only have the ClientID.  MQTT is already used for a number of use cases ranging from very small devices to complex mobile devices such as automobiles.  For many of these use cases returning a redirect is not the best design.  For some of them it is a good way of implementing a requirement.  

We raised this item in part because functionality of this sort was requested by one of our customers.  We did of course tell them of the alternate solutions to solve this problem and since the current MQTT does not support this they will use one or more of these alternatives.  As the MQTT TC has almost no representation from end users of MQTT, those of us producing MQTT based products need to represent our customers.

I do not think this is the most important thing we are dealing with for MQTTv5, and I agree there are alternate solutions which might or might not be better for particular use cases.  I am concerned about the doom and gloom response and concerns over client complexity.  I think this is a nice side functionality which has near zero cost to any client which does not use it.  There is certainly a zero cost to servers which do not use this function.


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