I'm going to start off by admitting that I don't know exactly how the mirror system works, from my understanding it literally relies on a user changing their sources.list file to point to a different download site?

Here's an idea that I've just whipped up as a hybrid of the mirror system and true p2p systems, taking into consideration points mentioned in this thread.

Rather than have each user become a peer on the download network, have it a subscription based thing, very similar to a mirror system. A user would sign up saying that they were willing to share their .deb files, and this would be registered with a central tracker. Other users would then point their sources.list to the tracker, and when requesting a .deb the tracker would provide them with a link to one of the subscribed sharing users.

Given that (correct me if I'm wrong) the size of .deb files is relatively small, I don't think it would make much sense to split them into different chunks and farm them out to different servers. Rather the tracker would just choose a server to point the user at, based either on historical traffic or a quick query of the server's speed. This would be the "difficult" part of the system to develop, and while I have some ideas I suspect someone with a network background would be better (mine is AI ;-) )

This would make it somewhat more user-friendly (as they would just have to add a single line to their sources.list; the address of the "tracker" for a set of packages, rather than choosing from a mirror), and it would have the benefits of distributed network use that you get from a p2p network.

Security would be dealt with easily, MD5 sums or some such solution, but there would potentially be some latency, waiting for the tracker to provide a download location.

I don't personally have any problems with the existing system, and any change would presumably be prompted by problems with the hosts of mirrors if bandwidth usage gets too great for them. I reckon it would be relatively easy to implement, and depending on whether current mirrors are feeling at all pressed for bandwidth, it might not be a bad idea for someone to at least prototype it.

Then again, this is probably completely the wrong list for discussing this, given its an AMD64 place... I'm not subscribed to anywhere else though, and its always fun to chat ;)

Max



Nat Tuck wrote:
The security issues in this plan are solved pretty well. If you used the actual bittorrent protocol then it would be as secure as the mirrors are now - if not slightly more secure.

The biggest issues here are
A.) unexpected bandwidth usage.
B.) horrible latency

The first issue is mostly a real issue from a bad press perspective. People
will see not using upstream bandwidth as a feature and try to avoid/cheat
the system. I actually wish bittorrent-style update mechanisms were more
common - people might stop paying for connections with horrible upload
speeds.

The second issue is most likely an engineering problem. The existing bittorrent protocol has a bit of a delay finding peers and convincing them
to share - until you have a chunk or two of the file, you'll be stuck at a super-low download rate (typically 1kb/sec). Since a bittorrent "chunk" is a good percentage of the size of the average Debian package, some sort of
custom bittorrent-like protocol would need to be developed.


I guess the real question is as follows:
- Is there a big enough shortage in donated mirror bandwidth to put the effort into developing a peer to peer package distribution system and convincing a large percentage of users to share their bandwidth?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Reply via email to