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] Commented: (MQTT-42) Clean session and random client ids

    [ http://tools.oasis-open.org/issues/browse/MQTT-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34123#action_34123 ] 

Raphael Cohen commented on MQTT-42:

Hmmm.. I understand the rationales and argument but I remain to be convinced.

Of course, brokers are very capable of generating good ids, as they (a) are written by very capable people in the main and (b) have full knowledge of the topic space and clients, etc. But it's of very little use, as the client doesn't know it unless we change the protocol... I also have concerns about re-interpreting 'empty' as a special sentinel value.

I think some of the impact of this behaviour is mitigated in situations where:-

- A client has to use credentials to authenticate, and so a broker implementation can have a manual delete (obviously not completely ideal)
- Client libraries that do generate random ids do so before connection, and pass them via the API to the connecting code to manage.
- I do like Roger's original suggestion on the MQTT wiki.

Having long-lived client ids is extremely powerful (eg tracking, logging, audit, etc), even if it is awkward for clients (eg "What is unique?" "What should I use?" "Where do I store it?") With our extended identifier size, clients are free to use MAC addresses, one-off GUIDs, hostnames, ipV6 addresses (which when link-local and without privacy extensions are effectively MACs), hostname + processname + process instance, etc. It also maps very nicely to AMQP 1-0's container-id (or link-name) concepts for implementers that might want to bridge protocols.
There are also places where a client should know its own id, anyway, even if random and for dynamic purposes, eg dynamic topics with reply-to, etc.

So, in summary, I'd support adding a non-normative comment to the spec along the lines Roger proposes.

> Clean session and random client ids
> -----------------------------------
>                 Key: MQTT-42
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-42
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 3.1.1
>         Environment: N/A
>            Reporter: Raphael Cohen
>            Priority: Minor
>             Fix For: 3.1.1
> Opened on behalf of Roger Light:-
> Hi,
> A lot of MQTT client libraries offer the feature of generating random
> client ids rather than having to supply one. This is good.
> I recently had over 10,000 client connections made to
> test.mosquitto.org using a random client id, but also having set clean
> session to false, which meant that when they disconnected their
> information was stored on the server but there was basically no chance
> they could reconnect.
> It would be nice to have a comment in the spec suggesting that
> implementations may offer to generate random client ids but that they
> must refuse to do so if clean session is set to false.
> Cheers,
> Roger

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


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