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

Jonathan Levell commented on MQTT-260:

I think there are valid use cases for temporary redirects (e.g. a directory server that clients connect to first to discover their real home) and a permanent redirect (state for some clients has been migrated to a different server as the previous server has been scaled up and split into two servers which do not share storage).

As for whether to use the same client state or different - each time a client connects to a server the server can have lost state so I propose the client can choose to:
         a) use the same state (and be prepared to clear state if session_present is not returned in the connack
         b) clean start on connection to the new server.
Alternatively we could encode whether to treat the new server as the same cleanstart by splitting each of temporary and permanent redirect into two codes (temporary redirect, same state) (temporary redirect, clean start).

I think an alternative service tag (like RFC 7838) is overkill - at the moment we stick to a URI (have a optional REDIRECT_URI field), if later we decide to provide more details for the service we can add a new REDIRECT_DETAILS field and specify the format then.

So I suggest that the TC consider a number of options in the Face2Face meeting today and if any of the options are preferred in  spirit, more details (and spec language can be generated)

Option 0: We keep the connack 'Try another server' error code that has already been added and do nothing further
Option 1: We add two errors codes: Temporary_Redirect and Permanent_Redirect which take a MQTT URI (and the client can assume same state or decide to  cleanstart via unspecified means)
Option 2: We add 4 error code:
    Temporary_Redirect, same state
    Temporary_Redirect, new state
    Permanent_Redirect, clean state
    Permanent_Redirect new state

In options 1 &2 we can add an  RFC 7838 style REDIRECT_DETAILS at a later point.

My personal preference is for option 1 at this point (but will keep an open mind).

> 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

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