Anenga2
November 12th, 2002, 05:03 AM
Here is some FAQ for you.
Why did Mike choose to release G2 as he did?
First of all, Mike has replied in the GDF on why he choose to release Shareaza with G2 as he did. He has good, legitimate, valid points. You can view his post here: http://groups.yahoo.com/group/the_gdf/message/11571
Where are the specs for G2?
Mike plans on releasing the G2 Protocol Spec to the GDF after v1.7 of Shareaza is complete (goes out of beta). I'm positive Mike will get the spec out in time.
The spec will be a proposed standard for Gnutella. G2, defined, is a new set of open standards. Yes, it is not open at the moment (because the specs haven't been released yet) but it will be soon. ETA for the specs is in around 1 week.
The reason Mike did not release the spec yet is becuase he wanted to test his G2 network in the wild with a large beta group. He's tested it, and everything looks solid.
Will other Gnutella clients adopt G2?
Regarding other clients, well... it's their decision if they want to use G2 or not.
If you want to know if your favorite Gnutella client will be supporting G2 or not, ask them. They probably won't have an answer for you until the specs are released. Even then, they might have issues with it. I'm positive the specs will hold up to the GDF's expectations. Of course, expect some changes to occur to G2 in the future.
Many developers have said they'll support it if is stable. Vinnie of BearShare said he'll support it if Limewire does, Limewire says it will support it if it holds up to their expectations, Gnucleus says they are eager to see the spec and to discuss it with the GDF. GTK's (the open source Linux client) developer has been active in the Shareaza IRC channel. So it seems like he will be interested in the spec when it is released as well.
Sure it works well now, but how about when you add 100,000 more nodes to it? Surely it can't hold up!
Seems like Mike is confident that it will scale even with that many nodes. Here is what he said in the Shareaza Forum in reply to one skeptical developer:
This is an interesting example. Lets say that there are 500,000 nodes on the network, sensibly organised into hubs and leaves. Shareaza hubs aim for 100-200 leaves, but for the sake of making it harder, lets say they have about 100 each. Thats about 4,950 hubs and the rest (495,050) leaves.
To begin with, every node on the network does a search an hour, which is pretty conservative, but its a start. Gnutella2 queries vary in length substantially, but 64 bytes is not a bad size I guess. 500,000 queries per hour is about 140 queries per second. At 64 bytes each thats very approximately ~8888 bytes. If every hub has to receive every query, every hub must have at least 70 kilobit per second inbound bandwidth. That is not a lot of bandwidth for a hub to have, in fact you have to have 144 kbit/s minimum before you can even become a hub.
And it actually gets better, because every hub does not have to receive every query to do a global search. And where a hub does process a query, the leaf filtering process is good enough that very few of the attached leaves will actually see it. Thus the passive bandwidth burden on leaves is much smaller than that experienced in Gnutella1. Active leaf bandwidth requirements (when searching) scale perfectly to however much bandwidth the leaf has available to it -- if you have less, it simply takes longer.
In conclusion, Gnutella2 easily supports true global searching on a 500,000 node network assuming one query per hour. As stated above, one per hour is very conservative. All optimisations aside, 2 per hour would require 140 kbit/s hubs. 4 per hour would require 280 kbit/s hubs, etc. At first that doesn't sound good, but there is good news. Not every hub has to receive every query, and hub by hub control means that it is possible to throttle per hub query traffic on the client side (eg: actively restricting per client per hub query traffic based on the capacity of the hub).
LimeWire's network size meter suggests there are currently about 100,000 nodes on Gnutella1. I don't know how accurate that count is, but assuming its not way off, the entire Gnutella1 network could move to Gnutella2 right now and be able to find any file anywhere.
How does G2 work with G1 in Shareaza?
G2 nodes cluster in Shareaza with a default value of 70%. That means 30% is G1 (Old Gnutella). If your a leaf, your connected to 1-3 G2 Hubs 3+ G1 Ultrapeers. So in actuality, your searching both Gnutella1 and Gnutella2. So you'll have the same results as you get in Limewire, Gnucleus etc. plus Gnutella2 (which is currently all of Shareaza).
So basically, all nodes on Shareaza support G1 and G2. Leafs search G1 and G2, Hubs have leafs which are G1 and G2 and have peers which are G1 and G2. Shareaza is not ditching G1.
If you have anymore questions, e-mail me at
[email protected] or post something up in the Shareaza forums (www.shareaza.com/forums)