5 ms·
Centralization will always be more efficient, generally speaking. Access to a centralized channel for distribution can be prohibitive for many reasons - cost an
by flatline 8y ago
Centralization will always be more efficient, generally speaking. Access to a centralized channel for distribution can be prohibitive for many reasons - cost and censorship being the foremost in my mind.
- StudentStuff 8y agoI'm doubtful of this premise, especially in the context of peering disputes. Here in the states, Netflix had/has serious issues with Comcast/Verizon/Centurylink not peering with their upstream providers sufficently to handle the number of video streams that needed to be carried. This was not an issue with the last mile connection itself, but a middle mile peering problem. From the testing I have done, on certain carriers that play games like this (Deutsch Telekom in Germany, Centurylink, Verizon & others in the US, and most Asian/South American ISPs) torrenting updates to users is significantly faster than an HTTPS download from Amazon, Google Cloud & the like. Once you get a handful of seeders internal to the network, the other downloaders in that network start to get the torrent significantly faster than they would over traditional HTTPS. If the content isn't extremely time sensitive (eg: live sports games, video calls) and is of a noteworthy size, using P2P tech to speed up downloads is not a bad idea.
- kalleboo 8y agoTheoretically BitTorrent should be more efficient, since peers nearby can send data directly (e.g. within an ISP or regional node), whereas a central server will always have to transfer a longer distance and involve more infrastructure. E.g. with my ISP, the bottleneck isn't in the last mile (that's all GPON fiber) but rather in the national network and their transit to the internet. If more transfer was made to local-to-local, it would reduce the amount of traffic that needs to go cross-country or out on the internet.
- bb88 8y agoI don't think that's true. Unless bittorrent understands the topology of a network, it will never be more efficient than a structure that takes advantage of the topology. E.g. Netflix makes servers that can be distributed to the ISP's and can serve content to those consumers directly from the ISP itself, and not over the ISP's outgoing link. E.g.#2 Multicast clients register to receive multicast streams and the routers know how to propagate multicast.
- jstanley 8y agoIt doesn't have to understand the topology, it can just understand which peers can serve bytes fastest. (I don't know if it does this, but it's been around long enough that I'd be surprised if it doesn't).
- bb88 8y agoThat doesn't make it more efficient. It might make it faster at the expense of using your ISP's outgoing bandwidth multiple times over. The most efficient network distribution is one where the data only travels each network link once for all destinations. This is the way multicast works, e.g.
- T-Winsnes 8y agoI think it can be done simpler than that. When the client/server has a choice of multiple peers to connect to, it can pick the one with the lower latency. That way you end up picking peers that are closer and will help lessen the load on the overall network. Not perfect, but a pretty good 90% solution
- bb88 8y agoLatency is different than bandwidth. I can make a very low latency connection but only delivers at most 1 packet every 10 seconds. It responds in 5 milliseconds say, but it won't let you have another packet for 10 seconds. Or I can have a high latency connection that delivers a huge amount of bandwidth. It might take 10 seconds to start the firehose, but once it starts, it's a firehose. This is ironically the problem that the internet has with "Bufferbloat", and high bandwidth radio connections in space. A topological solution would be counting the number of hops. There are internet protocols that do this, it's just that I don't think that BT takes advantage of it.
- zzzcpan 8y agoWhen bandwidth was a big concern bittorrent trackers prioritized peers geographically and ISPs were using retrackers to force peers within the same ISP to save bandwidth. It was very efficient, each torrent was downloaded pretty much just once for an entire ISP from the fastest sources. Good times. But none of this is necessary, fast clients simply send more data and dominate download bandwidth. Doesn't matter why they are fast, whether they are simply very close or just on a path with more capacity. Everything is naturally efficient.