Closed Gnutella System to Prevent Bandwidth Hogs

prostoalex writes: "Salon.com is running a story on Gnutella developers contemplating the creation of a closed or authorization-only system to prevent bandwidth hogging. Turns out, numerous applications, including Xolox and QTraxMax employ quering algorithms that are capable of bringing the network traffic to a halt. While it gets better download speeds for the users of the aforementioned applications, the damage to network traffic as a whole is substantial."

Comments

A few thoughts on P2P

[jukal]

Here's a clip from an email I sent sometime ago to someone, it might or might not have something in it, judge yourself.

- the system must reorganise itself automatically based on current
analysis of the nodes available on the network. - the system must have a dynamic trust model, based on "paranoia".
- the trust model must be utilized in combination of other characteristics of each peer(node) to select best population of the nodes as more important servants. Untrusted/neutral nodes are not to be given any crucial tasks. No-one can do anything crucial alone, confirmation for the action must be confirmed from other trusted ones. - All functionality of the network mut be replicable automaticly. Tasks done by any node must be transferrable transparently.
- Weak nodes will not be given any "community work"
- Every node must pass constant quality criteria to be able to perform any actions on the actual network.

Just to mention a few points. In short, anarchy does not work - even in P2P networks. We need a government, but one which is always on move, but still governs population using strict - but adaptive - rules. :)

The solution is to block abusive servents

[Anonymous Coward]

IIRC, the big players on the Gnutella network at this point (Limewire, Bearshare, etc) are able to exchange version information, and to confirm that version information. If this is true, and it's not possible for a rogue application to masquerade as another servent, I believe it's time to lock abusive servents out of the network. If they aren't playing fair, don't let them play at all. Period.

This means you, XoloX. As well as all the other servents which send requeries at ridiculously short intervals, send download requests tens of times per minute trying to force their way into a download slot, support downloading but not sharing, encourage or emphasize web downloading as opposed to participating in the Gnutella network, etc. Freeloaders are as much a problem as they ever were, but (IMO) only because they're being allowed to be such a problem.

The time has come when abusive servents need to be shown the door. I don't mind sharing most of the time. But when the same asshole is hammering me 100 times per minute trying to get a download slot, or sending the same query every 5 seconds trying to find more sources, my desire to share files goes down the toilet. Something needs to be done.

Re:The solution is to block abusive servents

[DNS-and-BIND]

The Gnutella developers see their mission as bringing a new, revolutionary network protocol to the masses. Something on the level of a new HTTP.

The Asia-based Qtraxmax developers see their mission as getting as many software(spyware?) installs as possible, through promising a superior user experience, and they would cheerfully destroy the network to do so.

Obviously, the solution is a new Gnutella option, defaulting to "on", that says "deny resources to abusive clients".

Those who do not learn from history...

[Todd Knarr]

It's not like this hasn't happened before.

Sun did it with Ethernet. They set their NICs to use the minimum retry interval instead of minimum + random time like the spec says they must. This got better performance for Sun equipment. Right up to the time where someone put a dozen Suns on a single Ethernet segment and the competition between all of them hammered the network down to 10% of the expected bandwidth.

Various TCP/IP "accelerators" tried this too, by ignoring the exponential-backoff and slow-start parts of the TCP spec. They too improved speeds for the people who used them. Right up to the point where lots of people started to use them, when the competition between them hammered their transfer rates down to a fraction of what's expected.

We've seen it on UDP-based streaming protocols, where lack of flow-control mechanisms causes massive congestion problems and slower transfer rates than when flow-control is applied.

So why didn't anyone expect/predict this when they were designing the Gnutella network and protocols?

Gnutella is the future of the Internet

[Anenga]

Stop the FUD.

People need to realize that Gnutella is now fastly becoming a big player in the function and value of the Internet.

Gnutella, in my view (and many others), is not a mecca for porn, warez, and MP3's - but a pool where anyone can share any type of file.

A bigger trend now showing up is linking to files on the Gnutella network instead of the common http://site.com/file.zip. How does this benfit you? You get faster downloads by utilizing partial file sharing, swarm downloads, etc. It also benfits servers greatly. They now aren't the only source for the download, because once the file gets onto a Gnutella client, it searches for more peers, and shares the load with them. This can save TREMENDOUS bandwidth.

For example, Linux can link to Linux links as such: magnet:?xt=urn:sha1:(InsertSHA1)&dn=Linux&xs=http: //www.linux.org/linux.iso

(not an actual correct MAGNET link, but you get the idea)

When someone clicks that, it opens it up in a Gnutella client. It begins downloading from that source, and searching for the same file on the Gnutella network. Through the entire life of the download, it will continue to add sources. You could then be downloading from over 30 people at once, gaining speeds of up to 10MBPS+.

Oh, the power of Gnutella. Can KazAa (FastTrack) do that?! (Well, it can, kind of :P)

Oh, how do you know if that's the correct file? Hashing. Gnutella servents are implamenting hashing now, where each file has it's own hash. So when searching for files, they can swarm you downloads. You are GUARANTEED that all the sources your downloading from are in fact the same file, because they have the same hash (SHa1). That's whats getting the RIAA so scared :P No longer can they infect files and make them the same file size/file name.

Also new on the scene (well, new as in new popularity) is Bitzi. Bitzi catologs hashs (bitprints). You can search through their database, and find files with hashes. Click the hashes, and you can download a file. Each file on bitzi has a "Bitzi Ticket" where you can rate the file. You can mark it "Invalid/Misleading" which means it is not the file you want. You can mark them if they contain virus's too. I can almost hear the sweat dripping from the RIAA Lawyers foreheads.

Want to see the future of Gnutella? Check out Shareaza (WINE Compatable).

Supports all of what I discussed in this post.

[Slightly OT] Peer-to-peer and web of trust

[RavenDuck]

I'm not a coder myself, and am probably not very up to date on the whole p2p scene (other than knowning that Limewire doesn't seem to work real well on my box at work), but one of the real problems on the p2p networks seems to be trust. With the recent news about entertainment industry bodies seeking legislation to DoS the networks, and the common user experience of crap files on the network (incomplete, or incorrectly labled files), I wonder whether someone could make a system based on the same sort of web of trust model than PGP/GnuPG uses.

The Keyserver infrastructure is already there, and the apps (like GnuPG) are readily available cross-platform. So why can't p2p clients allow content to be signed, so that you can establish a web of trust as to whose content can and cannot be trusted. Downloading a signature of a file to check it's validity would certainly help reduce the chance of downloading dodgy content. This should be especially useful as you tend to get groups of people who are all interested in the same sorts of files (anime, divx, certain bands, etc), so you could imagine a good web forming fairly rapidly.

Making a valid OpenPGP key is a computationally intensive task, suggesting that few people would make thousands of them on the possibility they would be blacklisted. They also don't require any form of real identification, making them effectively anonymous. Also gaining a good trust metric would be an incentive to keep the same key, especially if downloading was restricted based on your trustability.

I can't think of any good reason that this couldn't be worked into an existing p2p network. Whether it would work in practice I have no idea. Anyone who knows more about this than me care to comment? Anyone done it already?

Re:An idea: UL/DL ratios

[af_robot]

Well, my idea is slightly different..
You don't have to upload files manually - all you have to do is to share specified amount of traffic before you can download more from other users.

Example: you want to download 600Mb file from other users. Admin server will check your account and verify amount of traffic you allowed to download If you don't have enough traffic stats you have to wait until somebody will download something from you. .

Good example is Edonkey protocol: then downloading big file you HAVE to share parts of it in order to finish download.

Re:Inhernetly N-P Incomplete Problem

[WolfWithoutAClause]

The peer-to-peer system pretends to be a virtual network over a real network using point-to-point links to establish proximity relationships between sets of peers, mostly ignoring physical proximity and bandwidth constraints.

Actually, you mostly don't want to ignore these constraints. The P2P should make use of closer servers (mostly, but not exclusively).

In order to get better performance for themselves, people play "the prisoners dilemma", and rat everyone else out with clients that gang up on requests to ensure disproportionately favorable service.

I don't see that this is necessarily a real issue. After all the server that has the file you want can keep a queue of requestors, and serve it in strict first come, first served order. 'Take a ticket and sit down over there.' It works. Asking more than once doesn't get you anywhere; and may even get you lower down the list.

The only real way to deal with this is to define a new protocol that is not virtual point-to-point linked.

Unclear. Very unclear.

Now take active attacks. "Automatic Karma" can deal with dummy files -- "poisoning"... at least until they start intermixing bad with good.

Yes, but users can usually play files before they've finished and cryptographic hashing of file contents can preclude people spoofing files, even when downloaded from multiple servers simultaneously.