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

Dominik Obermaier commented on MQTT-260:
----------------------------------------

Jonathan,

I think this is a valid argument for broker implementations that are not able to transfer session state between the servers. From my point of view this is a design decision on the broker that is not optimal, because if clients reconnect to the "wrong" server, state for the client is in best case lost, or worse, there's conflictive state on the broker on different servers. The discussion right now drifts in the direction of large scale systems and one thing I learned the hard way (several times) is that making assumptions on other servers states in a distributed system makes things extremely complicated. Imagine if you send the client the URI with the "correct" server but the correct server is not available? We would need to clearly give recommendations on client implementations what to do in such edge cases. The worst thing that can happen is to have a scalable backend but clients can't connect (potentially infinite) due to some error conditions on the distributed broker.

I understand that with current implementations for MQTT brokers that chose to have such a distributed design, the URI feature could help solve a design problem on the backends. I'm not convinced that adding complexity to the protocol is a viable way to circumvent such issues on the backend side. MQTT on the broker side is surprisingly hard, I know that from my own experience. One of the main reasons for the popularity of MQTT (at least from the feedback I get from my daily work with customers that are using MQTT) is the extreme simplicity on the client side. It's trivial to implement a basic MQTT client. So please let's keep MQTT simple on the client side and please don't leak complexity from the broker side to the clients.

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]