On Wednesday 07 October 2015 15:02:55 Drasko DRASKOVIC wrote: > > Others can chime in, but I believe the rationale goes like this: > > - HTTP: not bi-directional, so technically unsuitable for the task > > - XMPP: known quantity > > - CoAP, MQTT: unknown quantities in firewalls > > Maybe I misunderstood something... But big majority of already > existing IoT clouds are using either MQTT or CoAP (they are using > often HTTP or WebSocket, but this is more for user apps then for > devices themselves). These (especialy coap) have suitable client > libraries for constrained devices, Moreover, OMA-LWM2M i a > standardized way for devices to reach coud over CoAP.
Hello Drako What you need to understand is how those protocols are considered by routers usually found on end users' homes. We're not talking about intra-cloud communication here nor about local-network communication of devices in a smart home. We're talking about gaining access to a network and transporting OIC message payloads (which use CoAP) over existing, consumer-grade wireless access points and routers. We had to choose an existing and well-known protocol that allowed for bi- directional exchange of messages of arbitrary format. Those qualifications exclude MQTT and CoAP, since those aren't known to most consumer routers. > What does mean "known quantity" for XMPP? See above. It's about the router know about XMPP and knows to route replies properly back to the originating gateway. > Would you say that CoAP or MQTT would not be well suited for this task > because of intermediate firewalls? Yes. > I do not see the problems with > firewalls, as device behind firewall opens the connection to the > cloud, and not the other way (cloud->device, although even this is > realtively easy achiveable: > https://lists.w3.org/Archives/Public/public-wot-ig/2015Sep/0023.html). That is where our opinions differ. Where you say "easy achievable" (sic), we say "almost impossible". We have OIC members who have been doing this kind of remote access as a business for years and we've trusted their experience on the subject, choosing a protocol that has the least amount of issues. You can, if you want, argue with them, over technical merits. If you do, I will be glad to introduce you to them. But until the opinion of experts in the OIC and in IoTivity changes, we'll continue to follow their recommendations. > I must be missing something, as XMPP choice comes as a surprise to me, > so can you please point me to the discussions about making this coice > in Iotiviry (if there are public ones). Those discussions happened inside OIC, so they are not public. IoTivity itself has no opinion on the matter, as such discussion has not happened (before today, anyway). We can have it now, but you're arguing against experts in the market. You'll need really convincing arguments why we shouldn't use XMPP. So far, I've heard arguments why could've used other protocols, but not why XMPP wouldn't be suitable. So, at worst, we didn't choose the most efficient protocol, but we still chose one that works... > > That pretty much settled the discussion. > > > >> Can anybody tell me the state of this GW and what other protocols are > >> planned? > > > > None others are planned. What did you expect to see in our plans? What > > would we gain from having other transports? > > Let people connect IoTivity networks to different cloud providers - > for example ones that do not support XMPP (which is about 90%). I > mentioned two very popular - Xively and IBM Bluemix. I've never heard of either. When I think of cloud, I think of Google and Amazon, and if I constrain myself to open source cloud implementations, I think of OpenStack and ownCloud. Maybe those two are using one of those open source implementation, in which case my argument here makes no sense, except that it goes to show that cloud solution selection is evident a solution as you may expect it to be. [I'm not surprised IBM is in this game and that their product has "blue" in its name, but I had not ever heard of it] > There must be a > tons of them, as the vast majority of IoT clouds do not support XMPP, > this is definitly not the choice of protocol for these clods today. We > can see HTTP REST, WebSockets, MQTT and CoAP proliferate, but not > XMPP. That's why I was surprised with your choice on XMPP. As I said, plain HTTP is out of the question. WebSockets implement bi- directional communication over HTTP, so it's a solution for that problem, but I have not heard any arguments why it would be superior to XMPP. XMPP and CoAP are important and relevant to us in the local network (heck, our entire protocol is based on CoAP!), but the fact is that routers may block them in unpredictable ways. XMPP, for bad or worse, is a known quantity. We know how it behaves over routers, in the majority of scenarios. > The only reason for XMPP that comes to my mind is TR-069 Amendment 5 > (https://www.broadband-forum.org/cwmp.php), as a standardized way to > manage WAN gatewaysm but this still do not justify the way you would > export Iotivity services form the local network to the IoT cloud... I still have to ask, "why not?" -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
