Slashdot Mirror
Gnutella2 Specs - Part 1
Mr Fodder writes "The first part of the Gnutella2 specs are finally up." Our previous Gnutella2 story has a little more information.
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Shareaza is the only gnutella client that even uses this '2.0' protocol so im more inclined to say that its not really a new gnutella protocol but more or less an extension of the current gnutella client (apparently they didnt like the rate @ which gnutella was progressing)..
I used LimeWire to try downloading a RedHat 8.0 ISO once, but even with a swarm download from several people, it was slower than a single FTP download.
> Is this official, by the original Gnutella developers? (who were winamp related, right?)
Yes, the original Gnutella developers worked for Nullsoft, then a division of netscape, a division of AOL, now a division of AOL/tw.
No, it's not official in that sense. It's not even official in the sense that other gnutella-client (such as limewire, bearshare, gtk-gnutella, qtella, gnucleus, etc..) developers have adopted, or agreed anything of shareaza's new protocol.
Of course, I hope this new protocol works good, but it's wrong to attach the gnutella name to it. It doesn't have much to do with it at all. Next thing that'll happen is someone else will come up with a totally different protocol and call it "gnutellav3" or something. Bad precident.
They are, however, free to distribute as long as the GPL license is included. It's perfectly legal and moral to download Linux distros over a P2P program.
Granted, this is off of the FastTrack network, but the information is still valid.
1. Dungeon Siege Demo
2. Day of Defeat Patch (Halflife Mod)
3. Alias Season 2 episode 1
Note that two of these are definitely freely distributable. The third one is not available anywhere else - and I have yet to hear of a big* hubbub concerning TV shows.
*there is a small hubbub, but nobody REALLY seems to care - I'll let you speculate as to why that is
It's really closer to the jump between HTML and XML. The new specification is more extensible, and has more optimizations than Gnutella. It's essentially the trends in Gnutella today taken to somewhat of a logical conclusion. Plus, instead of just lumping in Gnutella developments like hashing files, it uses it in the base design of the network. And at the same time G2 hubs and leafs can play nicely with G1 peers.
So, to answer your question, for the moment it's more of a complement to Gnutella than a replacement. However, as time goes on and more clients adopt the new protocol, it may eventually replace it. Your original question was a bit to inherently harsh.
Well, here's the story.
Micheal Stokes (Shareaza developer>) thought that the GDF (Gnutella Developers Forum) was a too slow at fixing Gnutella's problems (unscalable, too much unused bandwidth, unorgnaized for future additions) so he went ahead himself (by himself) and wrote Gnutella2. He has done this before, when he wrote the spec for "Remote Queueing" (kind of like IRC). He wrote his spec first, developed it in his client, released it then proposed the idea to the GDF. The GDF likes it and now Limewire, Bearshare and Gnucleus all support it.
The GDF is pissed that Mike went ahead and "updated Gnutella" without asking them first. Granted, they have a right to. The GDF is meant to be a consensus, a forum for all developers. And a "assumed" condition of that is to let the other developers know *ahead of time* before going ahead and doing something this massive. And the entire idea that he called it "Gnutella2" (using the Gnutella brand) and advertised it as the "next revolution in P2P" (which it actually, IMO, is) pisses them off even more.
However, if you notice, it seems only the developers with corperate ties are pissed. Other clients such as GTK (Linux), Gnucleus, etc. all seem interested in the protocol, I believe GTK already said they'd implament it. Limewire and BearShare still seem upset. (It's like owning a oil company, then someone comes out with electricty - sucks).
Anyways, Mike likes the Gnutella ideals - that it is open and free. So he called it "Gnutella2". Partly to "refresh" Gnutella and revive Gnutella's bad image it has with the general user (which it has achieved IMO) and to show users it's the "second generation" of Gnutella.
The Protocol is being released now. This is part one, the next one will go over the new packet encapsulation and what not.
There are several steps in the right direction, but the new design still doesn't do enough to address impact on the network. I work at a public sector ISP and we try like heck not to "censor" traffic based on port numbers, but lately we have had to kill off several PtP applications because they were hosing links and firewalls. Since much of the next-to-last-mile is using flow-based methods to make the Internet fair, not to mention asymetrical NAT, any PtP structure needs to put a higher priority on limiting the number of "flows" or "conversations" (hostA:portA hostB:portB).
This *does* include UDP as many routers/firewalls/packet shapers do perform flow-based rules on UDP conversations as well.
We've seen a relatively small link full of Bubster traffic bring a medium-end firewall to it's knees
by causing far too many conversation setup/teardowns. GnuTella should try to construct a network of long-lived inter-hub connections such that a query is never sent over a *new* connection more than a a few hundred times. Fortunately the new design is at least progress.
I've been playing around with the limewire source for ahwile, it is well documented and there is no spyware in the open source version. I love how people complain about Limewire and spyware, when it is open source. Anyone can take the gpled limewire source and package it without spyware without having to reverse engineer it like closed source KaZaa.
I know I spent a lot of time looking for mirrors of RH8, all of the published ones were overloaded. You could actually look at the mirroring network for free software distros as an inefficient P2P network.
P2P networks like Edonkey and Freenet have the property that it becomes easier to download a piece of information and its more likely to be closer to you the more it is downloaded, rather than the reverse with a centralized server.
Paying for bandwidth to host large digital content is not always feasible for some information distributors. A group that I work with that produces freely redistrutable media is considering how to make full resolution video available. Sometimes even for the low res video we now make available we have peaks over 40mbps when a piece of info is popular. If we can't find a donor for a substantial amount of bandwidth then we'll probably use a P2P network.
It would be more efficient bandwdith-wise if ISPs implemented P2P nodes for their customers, rather than the customers doing it themselves. They recognized that this was the case a long time ago with newsgroups and more recently with Akamai. Maybe when there's more freely redistributable content available they will do so.
Digital signatures take care of the security concerns you raised. You can download them from authoritative website and check the file after you've downloaded it. Freenet and Edonkey use digital signatures natively.
Pr0n priority levels have been a concern of many P2P network users for some time. While the collection of protocol updates in gnutella2 has many general performance enhancements, it does (rather glaringly) lack any improvements specifically addressing the pr0n issue. A good deal of user upset has been produced by this -- however, fortunately much of the furor is undeserved.
Improvements to improve your pr0n viewing experience are well underway in many *clients*, rather than in the protocol itself -- protocol changes would produce compatibility issues. A number of proposed improvements include changes to the routing system to use dictionary-based priority changing. Query and result packets containing entries with phrases such as "tits", "ass", or "CowboyNeal nude" will be given an elevated priority in sending, improving latency for those users who really need pr0n. There has been some debate over whether this is entirely appropriate -- it reduces fairness -- but when it comes right now to it, pr0n-obtaining is a task with hard realtime constraints. The Gnutella developers and GDF members recognize that the goal of P2P software should be to best serve the community as a whole -- and so some unfairness will be allowed.
Preliminary dictionaries for the new routing prioritization may be downloaded from various of the GDF developers -- links have been posted in relevant discussion on the GDF board. The proposed dictionary format allows granting of variable priority -- "tits" matching a packet might increase the routing class by 1, but "teen lesbian slut" would increase it by 3, giving it priority over merely "tits" packets.
There is some concern over abuse -- that users hungry for low latency may simply include terms like these in their filenames. Indeed, a few users have already begun doing so. A second solution, perhaps blacklisting, may have to be used later on if this becomes a severe issue.
Because of the real-time nature of Gnutella, there are limits that can be placed on how much latency alteration that can be made. Queues are never massive at a single node, since most clients allow only relatively small send buffers. Early tests show 10% to 40% improvement on high-priority pr0n-containing packets. This is somewhat variable depending upon the network traffic -- if background traffic is composed mostly of smaller "ping" packets (instead of result packets), latency improvements tend toward the latter number.
There are a few other improvements on the table. Those of you that follow my work know that I'm interested in distributed trust used to rank the users. This trust network can be adapted to rank users based on the quality of the pr0n they serve, and give higher priority to users that give really top-notch pr0n -- unfortunately, this requires a client UI (and effort on the part of the user) to do manual ranking.
One more controversial proposal includes a Freenet-like network-wide caching system. Pr0n that is being frequently downloaded will be mirrored to as many systems as possible. This will improve download speed (and end-user experience, as people will be able to view locally-cached pr0n, and thus be introduced to new and interesting forms of pr0n). The p-cache (as it's already being called) even goes Freenet one better -- it is being designed to support speculative caching based on past searches. If your client catches even a hint, based on the searches that you've done, that you might be remotely interested in "cuties in French maid outfits on the beach", say, it will search and download all the related files it can find on the Gnutellanet. Aside from the massive cache of pr0n that builds up (if the user chooses to browse it), this is mostly user-transparent, yielding only low latency, high-availability pr0n searches tailored to your tastes.
Also notable is the support (for pr0n only, I'm afraid -- scarce network resources must be conserved) for multicast, introduced with the new UDP support. When you request a download of a large file, a remote server can give you a time offset until the file will be sent -- usually, an hour or two -- and will establish you as a "subscriber" of this file. When the time expires, the server will multicast-stream the pr0n file to all people that have subscribed to the broadcast. Now, an "hour or two" may seem like a long time, but it's far better than simply waiting in a unicast queue, possibly for days. You will need to be on the MBONE for this -- some college users or business users with videoconferencing may already have this handled, but the rest will need to request "MBONE support" from their ISP.
May we never see th
Check out http://www.furthurnet.org.
Legitimate P2P sharing of live music.
So if you have 6 hubs, all neighbours to each other, and the first gets a request it sends it to its neightbours. Then they all send the request to their neighbours??
/
How do they stop circular requests? Don't send to the request to the one that requested it is simple enough, but what about "multiple inheritence"?
Hub A knows hub B and hub C, but not D. Both B and C know D. D gets the same request twice?
A
/ \
B C
\
D
Can't A tell B and C to talk to each other once in a while and temporarilly remove D from either B or C's neighbour list to prevent wasting bandwidth? As soon as B or C goes down D can then automatically be re-added to D the neighbour list of the hub that is still up.