[IOT] Feedback on pubsub for IoT

Cramer, E.R. (Eelco) Eelco.Cramer at tno.nl
Wed Apr 29 14:09:35 UTC 2015

Hi Peter,

Thanks a lot for your comprehensive answer!

I agree with your view on MQTT but from discussion I’m having not a lot of organisations see federation as something that adds value and go for a short term win. You provide me with some good arguments against that :-)

> > 2. There is currently no best practises in using pubsub or PEP for IoT.
> Perhaps it’s time to retake the XEP-writing effort and write down some guidelines for IoT on XMPP using pubsub…

Perhaps it is. I would not mind participating.

> > 3. Management of pubsub nodes (manage subscribers and publishers) is cumbersome and not all functions (authorization schemes) are supported by all XMPP servers.
> Some kind of minimum supported server pubsub functionality might be necessary, together with a validation procedure. I know similar work is being done by UPnP to make sure XMPP servers support a minimum set of functionality required. Much of the administration might be taken care of if the server supports model “authorize” which allows node owners to approve or deny subscriptions. The owner can tie this into provisioning (XEP-0324) (canRead), for automated decisionmaking and a single interface for both momentary readouts and publish/subscribe.

That is sort of the approach I wanted to take for pubsub but did not link it to XEP-0324 yet. Thanks.

> > 4. I proposed an alternative pubsub like service, that I called ‘dealer’, which acts as a IoT concentrator towards the subscribers and that would subscribe to all Things the clients would want to receive events from.
> Ok, not sure I understand. Please tell me more. Would it be an entity that subscribes to data from multiple nodes, and then makes it accessible using XEP-326 to other interested parties?

Something like that except I would use IoT events (https://xmpp.org/extensions/inbox/iot-events.html <https://xmpp.org/extensions/inbox/iot-events.html>) and let the ‘dealer’ optimise the subscriptions towards the ‘Things’.

In the dealer pattern the client applications, that want to subscribe to sensor data from the Things, instead subscribe to the dealer service. Once subscribed the clients receive the measurements from all the Things via the dealer.
The dealer is responsible to subscribe to all the individual Things and when it receives new measurements it will instantly publish these measurement to clients that subscribed to the dealer.

Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/iot/attachments/20150429/a4383377/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.jabber.org/pipermail/iot/attachments/20150429/a4383377/attachment-0001.sig>
-------------- next part --------------
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

More information about the IOT mailing list