[p2p-hackers] p2p in some place or other

[Serguei Osokine]

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 at zgp.org [mailto:p2p-hackers-bounces at 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 at 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 at 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]