On Tuesday, December 13, 2005 Michael Rogers wrote:

I believe eMule allows the uploader to assign different priorities to different files - I'd like to be able to do this in Gnutella, to make the rarer (or better) content on my node easier to find...

Tha is more like "easier to download", but I see what you're saying. Yes, at some point I used to place hight hopes on this method, basically thinking that the transfer rates for the rare content can be improved at the expense of the popular one. Popular content can be found at lots of places anyway, so penalizing it should not hurt all that much; for me the goal was to equalize the download rates for all content regardless of its popularity. So if improving the rare content download speed would make the widely distributed content transfers a bit slower (because the systemwide cumulative uplink bandwidth is a scarce resource, after all), so be it. Unfortunately the statistical research of the P2P systems (the one that I've already quoted in this thread) shows that from the uploader standpoint the prioritization of rare vs popular content does not cover a very significant percentage of all upload situations. The typical upload scenario is not only "some popular, some rare, so give the rare more bandwidth". Just as widespread is "many rare uploads from one node", in which case changing their relative priorities is pointless, and also "rare upload from a single node", in which case no matter what this node does, the speed is going to be substandard. And let me reemphasize this again - these scenarios seem to be very common. Essentially the download speed for the rare content is limited by the uplink rates of the nodes with rare content, even if all the nodes are always on and spend just a small percantage of their online time downloading. For popular content, you can have very fast downloads in such a case; you can even saturate your downlink if you wish. But for rare content, you're still stuck with whatever is the uplink rate of a single node that has this file. As the nodes start spending more time on line, this disparity becomes more and more pronounced no matter how you prioritize the uploads. And seeing this causes the user frustration on a significant percentage of all downloads (on everything that is in the long tail). Best wishes - S.Osokine. 13 Dec 2005. -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On Behalf Of Michael Rogers Sent: Tuesday, December 13, 2005 3:25 AM To: Peer-to-peer development. Subject: Re: [p2p-hackers] p2p in some place or other Serguei Osokine wrote:

And the reason for this is quite understandable - if most of the content exists in just one or two copies, what good are the swarm downloaders and other marvelous instruments of progress? This single copy that you need might be on a single host behind the modem in Albania, the host might go off-line at any moment, and to make it more fun, it might be trying to upload five other files (different files, mind you) to five other people at the same time.

I believe eMule allows the uploader to assign different priorities to different files - I'd like to be able to do this in Gnutella, to make the rarer (or better) content on my node easier to find, almost like a recommendation system. Cheers, Michael _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]