Re: [IOT] Feedback on pubsub for IoT

Hello Eelco Thanks for the input. Following are some of my comments: This is correct. It’s not the publish/subscribe pattern. It allows for tailored information to be sent to each subscriber. It also provides a means for the publisher to limit content to different subscribers based on rights (for instance, in accordance with the provisioning extension XEP-0324). Perhaps it’s time to retake the XEP-writing effort and write down some guidelines for IoT on XMPP using pubsub… 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. 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? MQTT is by some a popular approach, because it’s easy to solve the transport layer. But since MQTT does not provide any information about who subscribes, or even who publishes information, the only way to make such a solution in any way secure is to build proprietary security-measures on-top, closing it off to everybody, which practically evaporates any hopes of having some kind of interoperability. Furthermore, all configuration is made out-of-band. And since it does not have a federation-mechanism built into it, scalability is also an issue. I would only recommend MQTT as a back-end solution in closed M2M applications, not as a protocol for IoT. If you have any interest in creating a solution that is both secure and interoperable, you cannot choose MQTT. There, you must select either or. In M2M this is not necessarily a problem, since solutions only need to be secure, not interoperable. XMPP provides a mechanism however, to build both a secure and interoperable architecture, using the XEPs 323-326. That’s why it’s better for IoT. And with XEP-347 & 348, you can create a zero-configration IoT architecture, that is both secure and interoperable. Best regards, Pete Waher Från: Cramer, E.R. (Eelco) [mailto:Eelco.Cramer@tno.nl] Skickat: den 29 april 2015 06:03 Till: XMPP in the Internet of Things Ämne: [IOT] Feedback on pubsub for IoT For a project that I’m doing with several partners I’m proposed to use the XMPP IoT experimental extensions (including the not yet submitted eventing extension). One requirement for the project is that the ‘Things’ should use as little data as possible and for this we wanted to optimise the data the Things are sending to subscribers. Another requirements was that we would like to be able to have fine grained control on which subscribers would be allowed to subscribe and receive the data. We want to accommodate multiple listeners to the same events, this is quite pub/sub like, and discussed to use either MQTT or XMPP. A few things I noticed during our discussion: 1. The partners did not see the eventing extension as pubsub but rather as p2p because clients need to subscribe to all the different things instead of to only a single topic. 2. There is currently no best practises in using pubsub or PEP for IoT. 3. Management of pubsub nodes (manage subscribers and publishers) is cumbersome and not all functions (authorization schemes) are supported by all XMPP servers. 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. Currently the project is leaning towards MQTT, mostly because partners like that concept of pubsub over the XMPP alternatives (verbosity of XMPP is not considered an issue). I would like to share this feedback as it might be useful in progressing the IoT extensions further. Cheers, Eelco 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.