Leech Contol: Managing "sharing" on a decentralised p2p network how would you do it? - P2P-Zone

kento · 07-09-02, 11:11 AM

Quote:

originally posted by TankGirl

paraphrased

I think there are very few people who would like to have anything like ratio FTP recreated in p2p. Leech control is a good and much needed functionality but there are way more intelligent ways to implement it than ratio FTP's mechanical requirement to upload a certain amount of stuff to be able to download a certain amount of stuff. First, it deals only with 1-to-1 relations, missing the inherent power of p2p to match the needs and offerings of multiple people. Second, it does not take into account the quality and desirability of the content at all.

could you please elaborate a little more on:

>>but there are way more intelligent ways to implement it than ratio FTP's mechanical requirement to upload a certain amount of stuff to be able to download a certain amount of stuff

thanks, kento

zombywoof · 07-09-02, 11:41 AM

If its managing leech control, perhaps something like being able to download up to the capacity you share. Have networks detect your share size. If you show you are sharing say 2gb worth of files, you can be able to download up to 2gb of files. As you increase your share, so goes up your downloading capacity. To me it sounds like a nice balance between not having to put up ratios or minimum number of shares etc or minimum share sizes to get connected to a specific server or network.

ReD · 07-09-02, 01:32 PM

These are some of my ideas to help prevent against leech control, These are methods i will be implementing in Sphere and dp2pftp.

1) If user isnt sharing, disable downloads, you can set a minimun, user must share a set amount of files so they can download.

2) Control number of active downloads based on how many slots users has for uploads. If user allows 1 upload, only allow to download one file at a time, If users has 2 upload slots then allow them to download 3 files at once, 3 upload slots 6 download slots etc.

3) Bandwidth limits for downloads and uploads, But have a minimum, say 1kb for modem users and 10kb for DSL or higer or whatever. But if user limits upload speed then limit their download speed.

4) Users cannot cancel uploads unless they need the bandwidth to do something else or if they are acting as a supernode/ultrapeer or only allow cancelling of uploads if the percentage of completion is less than 90% This will be a good feature I hate my downloads being cancelled at 99%

these are just a few of my ideas

alphabeater · 07-09-02, 04:07 PM

so-called leech control in decentralized p2p is, in my opinion, not properly and reliably implementable.

in a centralized, client-server environment, you can easily add things like the dreaded ratio and other leech-control measures. once you're in a decentralized environment, though, how do you know that anyone is doing what they say they are? the only way i can see to achieve this is a closed protocol, which isn't good for p2p in general and would have to feature strong encryption and protection to stop people from figuring it out and spoofing it. even then, what's to stop me from using a program to generate lots of random files that look like proper files but aren't (this is what ends up happening on direct connect hubs).

leech control can only be included in the official client. with an open protocol, as many p2p programs use now, there's nothing to stop someone else building their own version of the p2p app, but without the limits on connecting and downloading if you're not sharing, perhaps by lying to the rest of the network and saying that the user of this 'unfriendly' p2p program is actually sharing lots. this simply puts the official client at a disadvantage - unlimited downloads without silly limits is a desirable feature, and most people won't think twice about switching to an unofficial client if it allows unlimited downloading and the official one doesn't.

even with a trust system in place, how do you differentiate between a new user with 1,000 files to share, and a leech who just re-joined the network with a new identity and a changed dynamic ip who says they're sharing the same 1,000 files, but isn't? the ip change wouldn't even be needed, if the user reconnected to a different part of the network that wouldn't recognise their ip using a new identity. on an open, officially leech-controlled network with lots of good content, you can almost bet on someone coming up with a client to do this automatically, and that more people will use it, hurting the network more than the original non-sharers.

so do you make it so that new users can't download anything until they've uploaded something? what if they have nothing to share (unlikely, but possible)? what if they have nothing anyone else is uploading? how annoyed would you be if you decided to try out that new p2p for your next download, only to find that you can't download anything until you've waited for it to upload x files, or done whatever else is required of you?

i, for one, would do what i do with ratio ftp sites - stay away from it.

the network could attempt to rate content, but what if they're new files? or versions of existing files on the network, that i ripped myself? besides that, what gets rated higher.. high quality content, popular and known good content, or rare content? who decides?

if i can think of one thing that'd annoy me more than having to wait for someone to upload before i could download, then it'd be not be permitted to do any more downloads because my files weren't rated highly enough by the network. i'd click uninstall right away, and go get the convenient network-unfriendly client with a list of the best-rated files, and pretend to be sharing them.

leech controls are simply annoying. clients that implement them have an inflated sense of their own self-worth (see mojo-nation, if you've ever heard of it)... there are plenty more networks out there, you know.

give your user value in the official client, give them a community and make them feel good about sharing and more will. the reason there are so many leeches on gnutella and fasttrack is that uploaders are just a number or username that you'll probably never be able to find again. this is, i feel, a large advantage of having a community-oriented p2p.. but why does any leech control need to be done by the network itself? it won't work properly - it'll either frustrate new users or simply not have any effect on determined leeches - and in the long run will cause more headaches for both the developers and the users than it will solve.

life isn't fair, and nor by extension are the internet and p2p. have confidence in your users, involve them in a community, and they will share - most people are nice, really. maybe some won't, but with a good reason. maybe others won't at first, but will later. in a good network, no artificial controls are needed, as enough people will share to make the network worthwhile.

SA_Dave · 07-09-02, 06:21 PM

I basically agree with alphabeater on this issue. At the moment, these leech control mechanisms are flawed and short-sighted. There are however some features of two p2p clients which I believe are reasonable :[list=1][*]Xolox - the method used to discourage "leeches" is somewhat ingenious IMO! If you are a cable user, and report yourself as a dial-up peer (thereby throttling upload capacity to relatively low levels), your download capability is also hindered. If "leeches" can only get it after 2 weeks instead of several hours, this is a suitable deterrant! I'm not sure of how this system accomodates asynchronous connections, as I've only read about this feature & I have a modem.[*]eDonkey2000 & Overnet - the forced sharing of partial downloads is not too much to ask, even from a person with limited hdd space. The bandwidth limiters in the donkey are also scalable & relative to a node's limitations. It doesn't go far enough though as sharing at 10kbps gives you all the benefits of sharing at 50. This is one of the factors which makes the network "slower" than the competition's.[/list=1]
If these features could be combined into a client with TankGirl's proposed Peer-rating system, as well as allowing for prioritised uploading to trusted peers, it would be an excellent development! This would be a useful distribution mechanism, particularly if you could prioritise selected content (rare & 'new' files for the most part) to be uploaded before anything else (as long as it's requested of course), to peers that have proved themselves to be worthy contributors to the network through their own interactions with you. This would have a beneficial ripple effect. I believe the advantages of prioritisation would far outweigh the perceived disadvantages. It's my experience that many users are micro-managing control-freaks, monitoring uploads & downloads and cancelling or otherwise manipulating any that don't meet their own divergent & often ridiculous requirements! In this sense, priorities already exist on a per-user basis & I believe that automated prioritisation would practically eliminate queues if the "rules" were implemented in a rational and generally fair manner. Think of this as a decentralised version of AudioGalaxy's groups, without the spam of course!

This is mainly what TankGirl's vision incorporates, with a few of my own ideas thrown in for good measure!

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

07-09-02, 11:41 AM	#2
zombywoof Join Date: Mar 2000 Posts: 2,160	If its managing leech control, perhaps something like being able to download up to the capacity you share. Have networks detect your share size. If you show you are sharing say 2gb worth of files, you can be able to download up to 2gb of files. As you increase your share, so goes up your downloading capacity. To me it sounds like a nice balance between not having to put up ratios or minimum number of shares etc or minimum share sizes to get connected to a specific server or network.

07-09-02, 01:32 PM	#3
ReD Registered User Join Date: Aug 2002 Location: United Kingdom Posts: 14	These are some of my ideas to help prevent against leech control, These are methods i will be implementing in Sphere and dp2pftp. 1) If user isnt sharing, disable downloads, you can set a minimun, user must share a set amount of files so they can download. 2) Control number of active downloads based on how many slots users has for uploads. If user allows 1 upload, only allow to download one file at a time, If users has 2 upload slots then allow them to download 3 files at once, 3 upload slots 6 download slots etc. 3) Bandwidth limits for downloads and uploads, But have a minimum, say 1kb for modem users and 10kb for DSL or higer or whatever. But if user limits upload speed then limit their download speed. 4) Users cannot cancel uploads unless they need the bandwidth to do something else or if they are acting as a supernode/ultrapeer or only allow cancelling of uploads if the percentage of completion is less than 90% This will be a good feature I hate my downloads being cancelled at 99% these are just a few of my ideas

07-09-02, 04:07 PM	#4
alphabeater Registered User Join Date: Jul 2002 Location: uk Posts: 97	so-called leech control in decentralized p2p is, in my opinion, not properly and reliably implementable. in a centralized, client-server environment, you can easily add things like the dreaded ratio and other leech-control measures. once you're in a decentralized environment, though, how do you know that anyone is doing what they say they are? the only way i can see to achieve this is a closed protocol, which isn't good for p2p in general and would have to feature strong encryption and protection to stop people from figuring it out and spoofing it. even then, what's to stop me from using a program to generate lots of random files that look like proper files but aren't (this is what ends up happening on direct connect hubs). leech control can only be included in the official client. with an open protocol, as many p2p programs use now, there's nothing to stop someone else building their own version of the p2p app, but without the limits on connecting and downloading if you're not sharing, perhaps by lying to the rest of the network and saying that the user of this 'unfriendly' p2p program is actually sharing lots. this simply puts the official client at a disadvantage - unlimited downloads without silly limits is a desirable feature, and most people won't think twice about switching to an unofficial client if it allows unlimited downloading and the official one doesn't. even with a trust system in place, how do you differentiate between a new user with 1,000 files to share, and a leech who just re-joined the network with a new identity and a changed dynamic ip who says they're sharing the same 1,000 files, but isn't? the ip change wouldn't even be needed, if the user reconnected to a different part of the network that wouldn't recognise their ip using a new identity. on an open, officially leech-controlled network with lots of good content, you can almost bet on someone coming up with a client to do this automatically, and that more people will use it, hurting the network more than the original non-sharers. so do you make it so that new users can't download anything until they've uploaded something? what if they have nothing to share (unlikely, but possible)? what if they have nothing anyone else is uploading? how annoyed would you be if you decided to try out that new p2p for your next download, only to find that you can't download anything until you've waited for it to upload x files, or done whatever else is required of you? i, for one, would do what i do with ratio ftp sites - stay away from it. the network could attempt to rate content, but what if they're new files? or versions of existing files on the network, that i ripped myself? besides that, what gets rated higher.. high quality content, popular and known good content, or rare content? who decides? if i can think of one thing that'd annoy me more than having to wait for someone to upload before i could download, then it'd be not be permitted to do any more downloads because my files weren't rated highly enough by the network. i'd click uninstall right away, and go get the convenient network-unfriendly client with a list of the best-rated files, and pretend to be sharing them. leech controls are simply annoying. clients that implement them have an inflated sense of their own self-worth (see mojo-nation, if you've ever heard of it)... there are plenty more networks out there, you know. give your user value in the official client, give them a community and make them feel good about sharing and more will. the reason there are so many leeches on gnutella and fasttrack is that uploaders are just a number or username that you'll probably never be able to find again. this is, i feel, a large advantage of having a community-oriented p2p.. but why does any leech control need to be done by the network itself? it won't work properly - it'll either frustrate new users or simply not have any effect on determined leeches - and in the long run will cause more headaches for both the developers and the users than it will solve. life isn't fair, and nor by extension are the internet and p2p. have confidence in your users, involve them in a community, and they will share - most people are nice, really. maybe some won't, but with a good reason. maybe others won't at first, but will later. in a good network, no artificial controls are needed, as enough people will share to make the network worthwhile.

07-09-02, 06:21 PM	#5
SA_Dave Guardian of the Maturation Chamber Join Date: May 2002 Location: Unimatrix Zero, Area 25 Posts: 462	I basically agree with alphabeater on this issue. At the moment, these leech control mechanisms are flawed and short-sighted. There are however some features of two p2p clients which I believe are reasonable :[list=1][]Xolox* - the method used to discourage "leeches" is somewhat ingenious IMO! If you are a cable user, and report yourself as a dial-up peer (thereby throttling upload capacity to relatively low levels), your download capability is also hindered. If "leeches" can only get it after 2 weeks instead of several hours, this is a suitable deterrant! I'm not sure of how this system accomodates asynchronous connections, as I've only read about this feature & I have a modem.[]eDonkey2000 & Overnet* - the forced sharing of partial downloads is not too much to ask, even from a person with limited hdd space. The bandwidth limiters in the donkey are also scalable & relative to a node's limitations. It doesn't go far enough though as sharing at 10kbps gives you all the benefits of sharing at 50. This is one of the factors which makes the network "slower" than the competition's.[/list=1] If these features could be combined into a client with TankGirl's proposed Peer-rating system, as well as allowing for prioritised uploading to trusted peers, it would be an excellent development! This would be a useful distribution mechanism, particularly if you could prioritise selected content (rare & 'new' files for the most part) to be uploaded before anything else (as long as it's requested of course), to peers that have proved themselves to be worthy contributors to the network through their own interactions with you. This would have a beneficial ripple effect. I believe the advantages of prioritisation would far outweigh the perceived disadvantages. It's my experience that many users are micro-managing control-freaks, monitoring uploads & downloads and cancelling or otherwise manipulating any that don't meet their own divergent & often ridiculous requirements! In this sense, priorities already exist on a per-user basis & I believe that automated prioritisation would practically eliminate queues if the "rules" were implemented in a rational and generally fair manner. Think of this as a decentralised version of AudioGalaxy's groups, without the spam of course! This is mainly what TankGirl's vision incorporates, with a few of my own ideas thrown in for good measure!