adam/ipfs-blog
1
0
Fork 0
mirror of https://github.com/ipfs/ipfs-blog.git synced 2026-08-08 18:03:04 +02:00
Code Issues Packages Projects Releases Wiki Activity

excluding header image from body

Browse Source
This commit is contained in:
Yiannis Psaras
2023-05-05 20:42:26 +03:00
parent 727e1b5aa9
commit ebd492b8dd
1 changed files with 0 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/_blog/unresponsive-nodes-incident-202305.md
-2
View File
@@ -11,8 +11,6 @@ tags:
- 'resource manager'
---
![ipfs-disruption.jpeg](unresponsive-nodes-incident-202305/ipfs-disruption.jpeg)
It depends on what type of system/network you’re running. In 90% of networks, or networked systems, this is a grand-scale disaster. Alerts are popping up everywhere, engineers go far beyond “day-time work” to get things back to normal, customers are panicking and potentially leaving the platform and the customer care lines are on fire. Half of the network is a large fraction, but I would bet that the same would happen even when 10% or 20% of the network experiences outage, or malfunction.
It’s not like that when you run your services on a decentralized, distributed P2P network, such as IPFS! At the beginning of 2023 a central component of the IPFS network, namely the public IPFS DHT experienced a large-scale incident. *During this incident, [60% of the IPFS DHT Server nodes became unresponsive](https://github.com/protocol/network-measurements/blob/master/reports/2023/calendar-week-04/ipfs/plots/crawl-unresponsive.png).* Interestingly, no content became unreachable and almost nothing in the network looked like the majority of the network was basically down. We did observe a significant increase in the content routing/resolution latency, in the order of 25% initially, but this definitely didn’t reflect the scale of the event.