I have recently read an article about why IoT should switch from the now dominant centralized (server - client) model to a decentralized peer-to-peer solution.

Reasons against centralization:

Connection between devices will have to exclusively go through the internet, even if they happen to be a few feet apart.


it will not be able to respond to the growing needs of the huge IoT ecosystems of tomorrow


Existing IoT solutions are expensive because of the high infrastructure and maintenance cost associated with centralized clouds, large server farms and networking equipment. The sheer amount of communications that will have to be handled when IoT devices grow to the tens of billions will increase those costs substantially.


Even if the unprecedented economical and engineering challenges are overcome, cloud servers will remain a bottleneck and point of failure that can disrupt the entire network. This is especially important as more critical tasks such as human health and life will become dependent on IoT.

Instead the article suggests a decentralized approach to IoT networking using peer-to-peer communication. But:

However, establishing peer-to-peer communications will present its own set of challenges, chief among them the issue of security.

Other source, like How Is P2P Becoming the IoT Nightmare? also mentions security as a problem.

It seems that the P2P (peer-to-peer) communication capabilities embedded into some Internet of Things devices turns into a security headache for users.

So security is clearly an issue to be solved, but what else should I care about when choosing to use a decentralized P2P network?

I am interested in general limitations, risks, and issues that can be used as points of comparison when I want to decide between centralized and decentralized network.

  • What kind of IoT application are we talking about?
    – Helmar
    Dec 22 '16 at 11:02
  • @Helmar I have updated the question. I am interested in a wider aspect if that is acceptable. I know it is broader this way, but I basically need the disadvantages of which I can decide one by one if it is relevant in a certain application. Dec 22 '16 at 11:46
  • As it is, your question is overly broad, because "decentralized" doesn't state what things will be decentralized and talking P2P. Will you have a single site-based hub to serve as a controller? Will you have pure P2P, with no controller? Will you have multiple hubs, one per home network such as Insteon, Z-Wave, Zigbee, AssureLink, Crestron, WiFi, etc., with each hub somehow interconnected? It would help if you described a more detailed architecture, then address the disadvantages of the specific implementation. Dec 22 '16 at 12:23
  • @JohnDeters I see, unfortunately the concept is not my idea but I will try to find some examples with more details to answer your questions. As I see it is still in development phase. I will try to make an update as soon as possible. Dec 22 '16 at 12:37
  • 3
    One thing the article fails to consider is that money is the driving force behind centralized servers. Central servers may seem expensive to maintain, but once a user base is locked into their proprietary ecosystem, each with a sizeable investment in expensive hardware, the company has leverage they can use to raise subscription prices. That ongoing revenue stream offers the tantalizing promise of never-ending profit, which means centralized services will always be what companies are incentivized to create. There's little incentive for them to create a not-profitable blockchain mechanism. Dec 22 '16 at 13:24

Although decentralised networks often look appealing as a solution, there are a few compelling advantages of centralised networks which make them far more popular at the minute.

Design Overhead

Understanding, programming and setting up a decentralised network is often much more challenging than a traditional centralised (client-server) model in the majority of cases. Take, for example, a mesh network (the topology used by ZigBee, Z-Wave and Thread), which tends to be structured like so:

Mesh network

(image from Wikipedia, in the public domain)

Nodes in the network must be capable of sending messages for themselves, but they must also be able to route messages across the network, which is more more complex, since each node must be able to calculate a route to the destination. The IETF has a rather interesting presentation on the routing protocols used in 6LoWPAN, a mesh network protocol that uses IPv6. As you can see, the design is far more involved than a traditional star network connected to a Wi-Fi router, and of course each node will need more computational power to handle the additional processing steps needed to participate in the mesh network.

The main problem of all of this is that each node will require more processing power, and hence cost more. A TechTarget article addresses this more generally:

Centralization is an attempt to improve efficiency by taking advantage of potential economies of scale: improving the average; it may also improve reliability by minimizing opportunities for error. Decentralization is an attempt to improve speed and flexibility by reorganizing to increase local control and execution of a service: improving the best case.

The other side effect will be that the increased computation will lead to a higher power consumption (although this tradeoff may not be that significant compared to long-range transmissions which would otherwise be necessary).


Unless security is built-in to the design of the decentralised protocol, it can easily pose a big problem. Since nodes will be passing data between each other, it's difficult to guarantee the integrity of each packet, since one router node could easily replace one packet with another, and the receiver would never be able to tell the difference. A Chron article describes this issue well:

If a computer becomes infected or malicious computer enters a mesh network, it can pretend to be a trusted member of that network and then modify sent data and disrupt how the network passes information. In a black hole attack, information passing through the infected computer will not continue through the network, blocking the flow of data. In gray hole attacks, some data may be blocked, while other data is allowed, making it seem like the computer is still a working part of the network. Wormhole attacks are harder to detect: They tunnel into a network computer from the outside and pretend to be other nodes in the network, essentially becoming invisible nodes. They can then monitor network traffic as it passes from one node to the next.

Economies of Scale

Large cloud platforms such as AWS or Azure allow you to set up a centralised server for a price that is dirt cheap - Amazon and Microsoft have the benefit of running truly immense server farms which allows them to provide server space for a very low price. Have a play with the Azure pricing calculator to see what I mean - you can run a function 1 million times in a month, using 128MB of RAM and taking 5 seconds per execution for £2.20/month, and scaling up the capacity is trivially easy.

On the other hand, scaling up a decentralised network requires adding more and more nodes, and I expect that you would start to see diseconomies of scale, since the nodes would need to spend more and more time routing data rather than performing useful computation.

In summary, although decentralised networks looks like a perfect solution, they do have significant disadvantages, which is why many IoT developers still favour centralised solutions.

  • 1
    While I agree that mesh networks are much more complex, this does not automatically lead to a higher power consumption due to computation. Small processors are very energy efficient and executing the 6LoWPAN stack does not require that many instructions. In fact, WiFi devices consume MUCH more energy and that is not due to a higher transmission power!
    – koalo
    Feb 23 '17 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.