Reputation: 150882
Supposed I have a P2P network with lots of nodes. If I want to update the P2P client there is one thing I do not want to do: Update each single node.
Now I could imagine updating one node, and from time to time, each node checks whether the node it currently interacts with is a newer version - and if so, gets the update from that node.
This way, updates would find their way through the P2P network and all you had to do was update one node. Moreover, you'd not be dependent from a central server.
Is there (somewhere out there ;-)) a concept for such an update scenario?
What might be the pros / cons of this approach?
Upvotes: 0
Views: 367
Reputation: 104579
Pros: If for any other reason, it would be really cool to discuss and talk about.
Cons:
Could be a security hole. If I can put a rogue peer on the P2P network, my code could advertise an update that is actually a virus. You should at least make sure updates including some sort of code signing and authentication piece.
If there's any sort of bug in the P2P protocol or in the update code, then you could get into a state where you are only able to upgrade a subset of all nodes.
A better approach might be to just let the clients get their updates from a centralized location. A hybrid approach would be to notify peers of an update via a central server that advertises a URL and a file hash. If the nodes can get the update from a peer (and validate the hash and code signing), then great. But always have "download from central server" as a fallback.
You might also want to consider how to incorporate a "staged rollout" so that only a limited number of peers receive an update. So you can validate the update works ok on a small set before pushing it out to all the other peers.
Upvotes: 1