“Our network knows within 20 milliseconds if the status of a
piece of data or a node has changed. It has to happen that
fast because if you turn your computer off the network has to
recreate that chunk on another node on the network to maintain
four copies at all time.”
What do they mean by that 20ms figure? That can't be the entire network, since trans-pacific latency is something on the order of 100ms
Perhaps the copies of data are geographically placed to minimize distance to within 20ms. Just a thought - I have no actual data to support that assumption.
Sounds pretty made up. It's over 200ms for me to see a reply from most servers just due to the latency coming in and out of the deep sea cables. I wager most nodes in a p2p system would have peers far above that. You can't get around limitation that no matter how fancy your code.
It's possible with central tracking servers if you de-hype-ify that number to say <500ms. With a decentralized network it's not possible. Even trying to achieve this would result in completely insane exponential bandwidth overhead and consummate issues around vulnerability to amplification DOS attacks.
This is why we have no huge-scale meshnet. As the network's size increases the bandwidth required to maintain the network's routing tables increases exponentially, not linearly, until no bandwidth remains for actual traffic.
If this is solvable it will either require a creative redefinition of the problem or a fundamental innovation in mathematics, probably in the realm of graph theory.
I think the lack of wider scale meshnets is just that the people willing to set one up or join one are either geographically isolated or aren't aware of others in a similar position. You need a high density of willing participants for something like it to work. Yes there's issues with authentication and flood control, but I'm not sure meshnets have ever become a big or important enough thing for that to be an issue (I'd love to be corrected on that).
Comments
Perhaps the copies of data are geographically placed to minimize distance to within 20ms. Just a thought - I have no actual data to support that assumption.
Sounds pretty made up. It's over 200ms for me to see a reply from most servers just due to the latency coming in and out of the deep sea cables. I wager most nodes in a p2p system would have peers far above that. You can't get around limitation that no matter how fancy your code.
It's possible with central tracking servers if you de-hype-ify that number to say <500ms. With a decentralized network it's not possible. Even trying to achieve this would result in completely insane exponential bandwidth overhead and consummate issues around vulnerability to amplification DOS attacks.
This is why we have no huge-scale meshnet. As the network's size increases the bandwidth required to maintain the network's routing tables increases exponentially, not linearly, until no bandwidth remains for actual traffic.
If this is solvable it will either require a creative redefinition of the problem or a fundamental innovation in mathematics, probably in the realm of graph theory.
I think the lack of wider scale meshnets is just that the people willing to set one up or join one are either geographically isolated or aren't aware of others in a similar position. You need a high density of willing participants for something like it to work. Yes there's issues with authentication and flood control, but I'm not sure meshnets have ever become a big or important enough thing for that to be an issue (I'd love to be corrected on that).