Freeloader-Friendly Anti-Freeloading Approaches <p align="right"> 12-11-2001 </p>
<font size="4"><b><center>Freeloader-Friendly Anti-Freeloading Approaches</center></b></font>
Is this an oxymoron? Perhaps not...
<b>What's a freeloader?</b>
A freeloader is someone who downloads files constantly, or leeches, and doesn't share anything with the rest of the community.
<b>Why are freeloaders a problem?</b>
They take up a large portion of upload slots available, leaving few available resources. Sharing involves two entities and is a two way process. In Gnutella's case, each does should give something to the other. However, this is not so. Most people are in the mind-set of 'download and go'. The fact is you can't have one person taking everything and not giving anything back. That's not sharing. It's taking. It's greed. It simply doesn't work. Due to the current standing of the network, Gnutella should be called the 'File-Giving Network'.
I believe LimeWire took a very wise approach to free-loading (I reference LimeWire in several places throughout this post - I AM NOT A LIMEWIRE ADVOCATE). LimeWire will not let freeloaders download from the host's computer at the users's discretion. This is predetermined by the number of files a user must be sharing in order to qualify to download. Granted, most people don't bother turning it on, but the people that do are doing themselves, and everyone else, a big favor. Not everyone is forced to used the features. As a result, they did not ruffle too many feathers when they implemented this idea.
<b>Current dilemnas:</b>
<b>1)</b> Freeloaders must still be included. They are not evil. Gnutella was founded as an open standard, and the idea of censorship has been against its philosophy from the beginning.
<b>2)</b> Gnutella is not an efficient networking protocol when compared to others. In the beginning, the idea was to create a completely decentralized network, but now we are seeing a migration back to a more organized network topology. Several measures have been slowly introduced, but it is high time for something a bit more drastic. This was something we wanted to avoid in the beginning, but now that the network has grown, but we once again see a centralized network's usefulness. So, all I'm saying is that there is always room for improvement until Gnutella gets better/more efficient than current client/server models there's room for improvement. We go from there, but we worry about it later...
Currently, modem users comsume lots of their bandwidth with Gnutella traffic and do not have much bandwidth left for uploads and downloads. As a result, most modem users are forced to become freeloaders if they want to download anything. This needs to be changed, or people will use other file-sharing networks.
The network's size is limited by modem users. If the network could span a majority of Gnutella users, more files could accessible to everyone. A network composed completely of DSL users would be fast, but this would lead to segregation and smaller search horizons. Dial-up users might as well give up altogether. Modem speeds are the primary bottleneck when it comes to scaling the network to a larger size.
<b>3)</b> Most people that freeload to do not realize that they are freeloading. The classic Internet (ok, so the Internet isn't <i>that</i> old - how about common?).... The common Internet model is that you download from from a server. That's it. The server does not download from you. Therefore, most people don't understand the concept of peer to peer networking. It is a new thing to them, and they currently have no initiative to share files with the Gnutella community.
<b>Possible solutions:</b>
<b>1)</b> Include freeloaders anyways. The spirit of Gnutella is freedom and uncensored file sharing. If you really wanted to, you could abandon Gnutella altogether and create a new proprietary, censored network.
<b>2)</b> LimePeer has already begun working on the problem of network size. They refer to it as UltraPeer/Client. This allows fast users to form a solid backbone, and the other, slower users to become highly organized branches. Many more hosts than currently possible can be connected at once in this way. File lists are cached on the Ultrapeers, which reduces query traffic, while the branch nodes communicate with the network trough its respective Ultrapeer node. It is still in beta phase, however. Hopefully, others will adopt this once LimePeer standardizes its method. Once successfully integrated into Gnutella, modem users will be able to participate without hacing to sacrifice great amounts of bandwidth.
Distributed downloads need to be implemented more widely and effectively. Some clients are burdened with especially large files that could be easliy uploaded in segments by multiple people at a much greater speed. Currently, swarmed downloads seem to be a good way to allow everyone to contribute proportionally and allow downloads to proceed at an accelerated rate. If more clients can adopt this standard, more download attempts will be successful, and many busy servers will be free to upload file segments to everyone. Obviously, a large percent of Gnutella users would need to implement this in order for it to be successful. Here's the main emphasis: Modem users can contribute small portions of a file transfer in a situation where contribution would be other wise impossible. Ideally, the amount of file segments/portions uploaded should be proportional to the amount of available bandwidth. In other words, file upload responsibility is equally distributed.
<b>3)</b> Consider the possibility of educating the file-sharing public. But right here is where we hit a snag: How do you edicate them? Does anyone actually like those screen tips that pop up when the program starts (like Xolox)? Maybe I'm alone on this, but it sure annoys me to death. Perhaps a better idea can be presented on this forum.
I invite everyone* to participate in this discussion. Perhaps together we can invent some ways to solve some of the problems the Gnutella network faces.
<font size=1>*Does not apply to trolls, flamers, or other annoyances. Terms subject to change without notice.
;-)</font>
Last edited by TruStarwarrior; December 12th, 2001 at 12:55 AM.
|