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-279) Make SUBSCRIBE symmetric


Paul Fremantle created MQTT-279:
-----------------------------------

             Summary: Make SUBSCRIBE symmetric
                 Key: MQTT-279
                 URL: https://issues.oasis-open.org/browse/MQTT-279
             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
          Issue Type: Improvement
            Reporter: Paul Fremantle


This is a proposal that may sound a bit strange at first, so I'd ask you all to have a think about it before making up your minds!

There are a number of use cases where it would be useful to specify to a client what data it should publish. For example, there is no point a lightweight client publishing data over GPRS or another pay-per-use network when there are no subscribers at the broker. 

To solve this, I suggest making the SUBSCRIBE message "symmetric". E.g the server can send a SUBSCRIBE packet to the client as well as the current client  --> server packet. PUBLISH messages are already "symmetric".

The client should also support UNSUBSCRIBE.

If a client implementor does not want to implement this, they can simply return a 0x80 failure every time, making this trivially easy to implement in existing or very small clients. 

I see a number of use cases, but these need fleshing out a bit more.

The simplest case would be that a client connects to the broker with a clientid (e.g. dev1032). The broker has some stored information that indicates that this clientid can be a source of messages for /device/dev1032. There are currently no subscribers to that topic, so the client just remains connected. When another client connects to the broker and subscribes, the broker could send a SUBSCRIBE to the client. This would save a lot of processing and bandwidth on the original clients part. 



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