4 ms·

For IoT XMPP is utterly wrong. Yes, some planes use it for a message bus. But that was silly then as it is now. most IoT application have to worry about both p

For IoT XMPP is utterly wrong. Yes, some planes use it for a message bus. But that was silly then as it is now. most IoT application have to worry about both power and network efficiency. XMPP is neither light nor concise. For example, I'm building a sensor network that needs to report a range of sensors every n seconds. I could use XMPP, but first I'd have to figure out how to make a decent XML parser in < 2kb or ram. Let alone a full IP stack. The cheap radio I have has an MTU of 60 bytes. None of this is going to fly, for what is effectively: Node Address: 1: 56.456 2: -6704 3: 80 If we ignore the <node><sensor><value> boiler plate that will instantly blow our packet budget, lets look at how the values are represented as: ascii. so sensor 1 which was a 4byte float is now a 6 byte varchar. We are of course ignoring the address which is going to be at least 16 bytes. We haven't even touched on the server requirements either. Can you name a decent XMPP server? I can't they are all finicky and nasty. So, no XMPP is not the swiss army knife of IoT, because its too large, too power hungry and just a massive pain in the arse. Anything that uses ascii representations of numbers is probably a bad fit for IoT

ge0rg 10y ago
Your argument only shows how wide the field of "IoT" is. For embedded sensor networks, your arguments apply without restriction. However, for things like "smart lightbulbs" or other devices connected to the cloud (not that I would endorse such things), where you need a scalable infrastructure for secure bidirectional communication between nodes deployed somewhere and your frontend application, XMPP provides a solid base. Besides, embedded nodes are getting more and more powerful (consider the ESP8266, which runs IPv4 and TLS and could easily handle XMPP), and it provides huge benefits to have a common end-to-end protocol that is not based on periodic polling like HTTP.
- KaiserPro 10y ago
  The ESP* sucks power, which means bigger PSU, or in the case of lightbulbs, no config support when the light switch is off. Making a PSU that is both small and efficient for both low current draw and high is rather hard. Protocol design is trivial for something like a light bulb, compared to the cost of designing the device, and making the scalable backend (and no XMPP is no shortcut for that. I know how wide the IoT field is. I also know the sheer volume of shite that is being produced. Most of the Wifi products will die a horrid death. replaced by something better and more suitable to low power usage. Failing that something more secure, after a rash of home fires caused by a terribly insecure system that was able to be turned off and on again repeatedly until it caught fire.
  - 0xdeadbeefbabe 10y ago
    Would you suppose it will be something like bluetooth keyboards getting replaced by a usb dongle that talks to your keyboard using some other radio protocol that isn't bluetooth?
    - KaiserPro 10y ago
      There is nothing inherently wrong with bluetooth. So long as you are prepared to put work in over the top to handle security. Bluetooth LE has a reasonable power profile, and the advantage of being about to interop with lots of other things.
  - nitrogen 10y ago
    As someone who started a company around IoT before people were really calling it that, I agree with you that the IoT market is being polluted with crap. But I think there is room for multiple service tiers for IoT devices. For example, some systems and devices need frequent, low-latency updates (such as lights that quickly and smoothly change colors in response to events), others need low latency but only a few packets per second (a light that only switches on and off), etc. So unless there is a low-power protocol that meets all those needs, I don't think we'll eliminate all of them but one.
- jeremiep 10y ago
  I wouldn't touch XMPP with a 10' pole even on desktop PCs. That's considering the fact that parsing XML is at least two orders of magnitude faster on PC than anything else, simply because of larger CPU caches. XML has to be the heaviest data format I know of to parse for CPUs, and the most cumbersome to read for humans. Its the worst of both worlds. Its not because we bloated our desktop PCs and our mobile phones' software that we need to do the same for IoT devices.
  - ashark 10y ago
    Glad mine wasn't the only "oh hell no!" reaction. Anyone who's ever dug into XMPP ought to know it doesn't belong anywhere near low-power, possibly battery-dependent devices.
    - azinman2 10y ago
      It's a terrible protocol in general. Has all the hallmarks of old thinking, a million people on the panel with a million needs, no consolidation, and no clean minimal implementation that gets you 99% of what you want.
iuguy 10y ago
Thanks for saving me the trouble of having to write this. The problem XMPP addresses has been solved far more efficiently for IoT by MQTT.
- imglorp 10y ago
  Sort of - if the devices are push only: ie, device decides when to push to server. MQTT might not be what you want if the server would like to converse with a device instantly. Examples include a server commanding a garage door to open, or a server querying a device state.
  - azdle 10y ago
    I'm curious why you say that. I'm unashamedly a fan of CoAP and have bashed on MQTT in the past. But isn't that the one thing that MQTT is good at? It is a pubsub protocol after all.
  - iuguy 10y ago
    I'm not so sure, I use MQTT to control lighting and various other things via NodeMCU and Arduino. It's not as quick as a direct link to the devices, but it's perfectly fine. Far more robust than something like IRC for example.
erikb 10y ago
More and more IoT moves from these very very micro machines to something like raspberry pis. And in that range you probably already have your IP stack and your xml parser since you are using Linux anyways.
- azdle 10y ago
  And what a disaster for security that is. 95% of the IoT crap that's being made today will never get an update. When you have something as complicated as a linux box the only thing that can mean is in ~5 years we'll have botnets that are an order of magnitude larger.
  - erikb 10y ago
    Yeah probably. But as a species we probably need to make that experience to learn to set up the corresponding systems. Think about how long it took to get some decent server security into the world. And even today there are more than enough computers hooked up to the net that shouldn't be.
zedpm 10y ago
Are you using CoAP or MQTT for your sensor network? CoAP fits the bill in terms of message overhead.
- KaiserPro 10y ago
  I only have 2k of RAM so sadly I don't have the ability to run MQTT (no IP) and not enough ram for CoAP
  - zedpm 10y ago
    We do CoAP in 2K on a custom embedded device I work on. What makes you think it's not enough? CoAP is dead simple (though DTLS complicates things if you want to run that).
    - KaiserPro 10y ago
      In that case, I'll have a proper look.... :)
daenney 10y ago
> Can you name a decent XMPP server? I can't they are all finicky and nasty. I've run a couple of different ones but Prosody has always been a pleasure to run. It's easy, simple to configure and very easily extensible. Not to say that makes XMPP a good fit for IoT, but it's a very pleasant and capable XMPP server and has a friendly set of developers behind it.

ge0rg 10y ago

Your argument only shows how wide the field of "IoT" is. For embedded sensor networks, your arguments apply without restriction. However, for things like "smart lightbulbs" or other devices connected to the cloud (not that I would endorse such things), where you need a scalable infrastructure for secure bidirectional communication between nodes deployed somewhere and your frontend application, XMPP provides a solid base. Besides, embedded nodes are getting more and more powerful (consider the ESP8266, which runs IPv4 and TLS and could easily handle XMPP), and it provides huge benefits to have a common end-to-end protocol that is not based on periodic polling like HTTP.

KaiserPro 10y ago
The ESP* sucks power, which means bigger PSU, or in the case of lightbulbs, no config support when the light switch is off. Making a PSU that is both small and efficient for both low current draw and high is rather hard. Protocol design is trivial for something like a light bulb, compared to the cost of designing the device, and making the scalable backend (and no XMPP is no shortcut for that. I know how wide the IoT field is. I also know the sheer volume of shite that is being produced. Most of the Wifi products will die a horrid death. replaced by something better and more suitable to low power usage. Failing that something more secure, after a rash of home fires caused by a terribly insecure system that was able to be turned off and on again repeatedly until it caught fire.
- 0xdeadbeefbabe 10y ago
  Would you suppose it will be something like bluetooth keyboards getting replaced by a usb dongle that talks to your keyboard using some other radio protocol that isn't bluetooth?
  - KaiserPro 10y ago
    There is nothing inherently wrong with bluetooth. So long as you are prepared to put work in over the top to handle security. Bluetooth LE has a reasonable power profile, and the advantage of being about to interop with lots of other things.
- nitrogen 10y ago
  As someone who started a company around IoT before people were really calling it that, I agree with you that the IoT market is being polluted with crap. But I think there is room for multiple service tiers for IoT devices. For example, some systems and devices need frequent, low-latency updates (such as lights that quickly and smoothly change colors in response to events), others need low latency but only a few packets per second (a light that only switches on and off), etc. So unless there is a low-power protocol that meets all those needs, I don't think we'll eliminate all of them but one.
jeremiep 10y ago
I wouldn't touch XMPP with a 10' pole even on desktop PCs. That's considering the fact that parsing XML is at least two orders of magnitude faster on PC than anything else, simply because of larger CPU caches. XML has to be the heaviest data format I know of to parse for CPUs, and the most cumbersome to read for humans. Its the worst of both worlds. Its not because we bloated our desktop PCs and our mobile phones' software that we need to do the same for IoT devices.
- ashark 10y ago
  Glad mine wasn't the only "oh hell no!" reaction. Anyone who's ever dug into XMPP ought to know it doesn't belong anywhere near low-power, possibly battery-dependent devices.
  - azinman2 10y ago
    It's a terrible protocol in general. Has all the hallmarks of old thinking, a million people on the panel with a million needs, no consolidation, and no clean minimal implementation that gets you 99% of what you want.

iuguy 10y ago

Thanks for saving me the trouble of having to write this. The problem XMPP addresses has been solved far more efficiently for IoT by MQTT.

imglorp 10y ago
Sort of - if the devices are push only: ie, device decides when to push to server. MQTT might not be what you want if the server would like to converse with a device instantly. Examples include a server commanding a garage door to open, or a server querying a device state.
- azdle 10y ago
  I'm curious why you say that. I'm unashamedly a fan of CoAP and have bashed on MQTT in the past. But isn't that the one thing that MQTT is good at? It is a pubsub protocol after all.
- iuguy 10y ago
  I'm not so sure, I use MQTT to control lighting and various other things via NodeMCU and Arduino. It's not as quick as a direct link to the devices, but it's perfectly fine. Far more robust than something like IRC for example.

erikb 10y ago

More and more IoT moves from these very very micro machines to something like raspberry pis. And in that range you probably already have your IP stack and your xml parser since you are using Linux anyways.

azdle 10y ago
And what a disaster for security that is. 95% of the IoT crap that's being made today will never get an update. When you have something as complicated as a linux box the only thing that can mean is in ~5 years we'll have botnets that are an order of magnitude larger.
- erikb 10y ago
  Yeah probably. But as a species we probably need to make that experience to learn to set up the corresponding systems. Think about how long it took to get some decent server security into the world. And even today there are more than enough computers hooked up to the net that shouldn't be.

zedpm 10y ago

Are you using CoAP or MQTT for your sensor network? CoAP fits the bill in terms of message overhead.

KaiserPro 10y ago
I only have 2k of RAM so sadly I don't have the ability to run MQTT (no IP) and not enough ram for CoAP
- zedpm 10y ago
  We do CoAP in 2K on a custom embedded device I work on. What makes you think it's not enough? CoAP is dead simple (though DTLS complicates things if you want to run that).
  - KaiserPro 10y ago
    In that case, I'll have a proper look.... :)

daenney 10y ago

> Can you name a decent XMPP server? I can't they are all finicky and nasty. I've run a couple of different ones but Prosody has always been a pleasure to run. It's easy, simple to configure and very easily extensible. Not to say that makes XMPP a good fit for IoT, but it's a very pleasant and capable XMPP server and has a friendly set of developers behind it.