View Full Version : What does everyone think of gnutella2 now?
View Full Version : What does everyone think of gnutella2 now?
Deep Thought
June 17th, 2003, 12:00 AM
Just wondering what everyone's opinion of Gnutella2 or MP now that all of the controversy has subsided.
Theinfamousone
June 17th, 2003, 12:08 AM
I don't really know that much about it, but I know that hashing is kind of annoying. It's better than the Winmx protocol and G1 from what I can see, and a few others, but I don't know if it could handle 5 million users like the FT protocol could. I guess he'll have to cross that bridge if he ever comes to it (I doubt it will get that big). Gnutella has huge problems with keeping the entire network united, also, G2 doensn't have that many users, so it's kind of hard to tell if the problems are with the protocol or the small user base.
cpugeniusmv
June 17th, 2003, 12:50 AM
it's hard to tell, i rarely use shareaza without connecting to the other networks....i'm sure it's an efficient protocol, yet it lacks the users to really judge the integrity of it.
Psilaxs
June 17th, 2003, 01:41 AM
Bleh, seems the same to me. no improvement.
GPA
June 17th, 2003, 03:11 AM
I wish that when KaZaA dies (in terms of 'no working' OR 'pay 4 nothing subscription') I wish so much that everyone would go to G2/MP. Or just Shareza, I'd love to see how much it can handle before it falls apart. I know G1 and G as a whole has always had problems with keeping it together, I'd like to see how far it's come from back in the days when Scour Exchange was around.
Talking of Scour, damn how I miss that little proggie, I know it sucked compaired to these 'new day' proggies, but it had a big impact on me. I think i'd be great if Scour came back as a G2 network client, but I bet the name is still tm-ed.
Anyway, I'd love for G2 to be put to the test, I aint saying it's great, but I'd like to test it full the full 4 million KaZaA users.
-BoY
isus
June 17th, 2003, 04:52 AM
g2 is one of the better protocol's i have ever seen... the only problem i have with g2 is unreliable download speeds... going full speed one second, 0kB/s the next...
method77
June 17th, 2003, 05:18 AM
why would anybody vote "I love it! It's the best ever!"?
GPA
June 17th, 2003, 05:24 AM
Originally posted by method77
why would anybody vote "I love it! It's the best ever!"?
I would if the theory behind how it works actually came out in the actual. If mike did his coding right and it can do what he hypes it up to be able to do, then sure, it deserves that vote, which is why I really wanna test it out.
Just like many of you may want a fast car, just to see how fast it goes, it doesn't matter really how fast it goes, but you still wanna see it, I wanna load Shareza up, and watch it crumble under the load, or watch it stun everyone from here to the outer reachs of deep space.
-BoY
DIMA2001
June 17th, 2003, 07:41 AM
but I don't know if it could handle 5 million users like the FT protocol could
FastTrack can't handle its 5 millions...it can handle 10000-30000 users. Everything else is out of your sight.
Some numbers: (horizon[accessable number of peers]/network size)
KaZaA: 10,000-30,000/4,500,000
Edonkey (+ Overnet): 600,000-800,000/1,200,000
WinMX: dunno/1,000,000+
DirectConnect: 800/600,000 (while with 400 users you get more than with 5,000,000 on FastTrack)
Ares: 10,000/12,000
Gnutella one: 10,000-40,000/120,000
Gnutella two: several Millions possible/20,000 or more (didnt check latest numbers now)
OpenNap: 10,000 (a million+ possible)/300,000 (while with 400 you can get more than on FastTrack with its 5,000,000)
IRC: 50(per channel) - 10,000 XDCC servers on EFNet/1,000,000+
FTP: 1/no stats (you get more from 1 FTP than from FT with its 500,000 if you know where to search and have some connections)
FreeNet: Several 10,000 possible/ 500
HTTP: See FTP
XS: 800/50 (while with 400 users you get more than with 5,000,000 on FastTrack)
FileShare: see XS
etc.
etc.
As you can see, FastTrack is only modified Gnutella with encrypted HTTP headers while accessing other peers. The stats should be also similar to G1.
On DirectConnect/XS/FileShare you get more useful content than on the whole FastTrack (binary and video content) because there is a minimum share amount for different Hubs (1Gig to 100 Gigs min)
Have fun with the numbers.
You must notice that with Shareaza you gain access to:
600,000-800,000 ed2k users
20,000 G2 users
10,000-40,000 G1 users
and also several files on BT (on BT the number of users doesnt mean much because the most seeds are very fast and you can get from 1 seed with the same speed as with 100 peers).
DIMA2001
June 17th, 2003, 07:56 AM
I don't really know that much about it, but I know that hashing is kind of annoying
On KaZaA you have no real hashing, it takes several bytes and then makes a number.
Because Shareaza uses both ed2k and gnutella(2), it HAS to hash the MD4 hash (ed2k), SHA1 (G1/G2), TTH (G2).
MD4 and SHA1 are very strict hash algorythmuses, they require your computer to go through every byte of the file and then compute the hash code on the base of the byte catalogue.
TTH is even more strict than SHA1 (it is based on SHA1):
it goes through 512k small chunks, hashes every chunk separately, saves the hashes into the tth catalogue and then hashes the whole file again (or does it only hash then the TTH catalogue?).
Because of 3 hashtypes, the times for hashing are 2xlonger than on emule - that's all. AND TTH is computed on-the-fly, while downloading the file, so, it doesn't take any time after the download is 100%.
So, actually, you hash only SHA1 and MD4. For an 700MB file my computer needs ca. 2-3 minutes (with moving the file). Sometimes less, but not more.
Have fun with the numbers again :)
You should see that the hasing algorythmus is not annoing, it is just 2x longer than on emule and emule hashes very fast. And he most time your computer needs for moving the files from the incomplete directory to the complete directory. It takes the same time on emule and shareaza, so the 'hash times' are nearly the same on the both clients.
And now again: have fun with the numbers :devil
aqlo
June 17th, 2003, 07:56 AM
I used g2-only for weeks back when and have done so again a couple of times lately, I like it a lot because there is a very eclectic selection similar to the way gnutella has been but much faster.
Keep in mind that I prefer Old Time Radio and celebrity fakes over anything from the contemporary music scene though, if you are expecting 'britney.mpg' to be a song by that performer perhaps g2 isn't for you yet.
nasrules
June 17th, 2003, 08:16 AM
I have to say that it's by far my favourite P2P, after BitTorrent. True, the download speeds aren't completely reliable, but if you get something with loads of sources (see PeerWeb.org (http://www.peerweb.org)) then you're fine. Shareaza is the best P2P app out there in a lot of ways, I can't see why anyone would use ML-Donkey for G2!
method77
June 17th, 2003, 08:56 AM
I agree with the numbers DIMA2001 posted about all the networks. That's why I always thought that centralised clients where the best to use. I only use opennap and soulseek. Althought soulseek is trying a more decentralised way of sharing now but you can still search the whole network.
DIMA2001
June 17th, 2003, 09:55 AM
actually, you can use nearly every decentralized network as a centralized one:
just setup a shareaza hub (let it become promoted to a hub) and tell everyone its IP - the users can use it as a central server and the server communicates with other servers and so builds up a network, it is so also on OpenNap, DC (DCG for some time, now it has been discontinued) or IRC (EfNET).
It is also possible to use ed2k centralized - just let all people know that you have a server. They will use it as a gateway.
On ed2k Adanet and Razorback are used by many users as _the_ central server. Russian ed2k users se the NNov Donkey Server as a gateway. So, ed2k _is_ relatively centralized.
So, actually, also Napster was a decentralized network - they had 7 servers. If the open nap developer would reverse ingeneer the protocol earlier, it could be possible to maintain more servers and Napster would be unstopable.
The Napster developers should think about this earlier and release the server software the same way as Jed (ed2k developer) did it - free.
Just a tipp for new p2p-generations with servers ;)
DainBramaged
June 17th, 2003, 10:32 AM
Most people say G2 sucks because the speeds and # of files can't compare with Kazaa, or because it can't compare with the types/rarity of files on ed2k or BT. Well, gee guys, not everything is going to be the best of everything.
I think G2 is good on its merits though. I'm just not a user who particularily needs it. The speeds have always been great, often maxing out my connection within a few seconds, just like Kazaa. I've used the 1.9 beta a little, but the legacy clients still do a better job. The peeps are the Raza forums really want to do a good job though, given whatever limitations they have.
zaphodiv
June 17th, 2003, 10:34 AM
G2 is average. It's a reasonably resiliant network that works but
the search traffic is too high for my liking, thats what you get
with a leaf/hub linked supernode architecture.
@DIMA2001, Interesting numbers, is that your estimate or did you
find that somewhere? Is that measured or estimated?
Overnet (distributed hash table system) is supposed to have
global search, it's a pity metamachine can't fix the bugs in
their software.
40K horizon for G1 seems high to me, last used it long ago though
Waste: 120/120 per mesh(expect improved versions)
winmx: horizon is certainly a fraction of the number of users.
IRC: only a small fraction of IRC users get files from it.
>TTH is even more strict than SHA1
TTH allows corrupt parts of a file to be detected more closly.
The ed2k/emule system just detects that a paticular 9.5MB chunk
is bad.
>it is just 2x longer than on emule
Depends if the computer is IO bound or CPU bound, if it hashing
is done in parallel properly it should only be necessary to
fetch parts of the file from the disk/network once.
thongsai
June 17th, 2003, 10:44 AM
me i like shareaza alot and i try to get people to join.. but yea u guys r right to be skeptical if it can really handle alot of users.. we will have to wait and see i guess
Sephiroth
June 17th, 2003, 11:04 AM
I think that it was way overhyped..
The only new things is query keys and UDP searches the rest is just the gnutella protocol that was rewritten which really didnt need to be done.
TipYourBartender
June 17th, 2003, 12:10 PM
If I could, I'd pick the option that "It's nice...and it's creator should be hunted down and shot."
Seriously, for all the shit that went down, G2 is pretty good. Not orgasmic, but good.
DIMA2001
June 17th, 2003, 12:11 PM
Interesting numbers, is that your estimate or did you
Gnutella should have ca. 20,000-30,000 users in your horizon while having 5 good connections in the leaf mode.
If every ultrapeer has 3 connections to ultrapeers, you will have in the best situation 243 ultrapeers in your horizon (TTL=5)
Then, every UP has max 400 leafs (it is standard) ->
243*400 = 97,000
But the most peers have often only 20-30% of their capacity filled. With 20% we come on 19,440 Peers in your horizon.
This is my calculation. I also read on some reliable sources (i think, one of them was napjunk) which said nearly the same numbers.
The ed2k numbers i have from the slyck interview with the emule developers.
DC numbers are on the base of the most BBB and Dˆ-hubs (Dˆ Hubs have 400 users max ... by default, BBB hubs have often over 600)
IRC: I read also these stats on different pages. I also have stats for IRC made with IRC-Ork. It crawled over 40,000 files in 10 minutes. I dont know any reliable XDCC server which have over 20 files since no one is able to get them since everyone is in the queue.
Of course, not many users use it ... but there are thousands of them. There are also private very big servers which you dont know. I have for example a server which has 500,000 users permanently.
The KaZaA stats are based on many internet sources, zeropaid comments and posts on different forums. You can increase your horizon (actually, change the field) by changing the supernode and hammering the network with astronomic TTL numbers (both makes K++), but that kills the network and is unethical. I dont look on these functions since they dont follow the network rules.
SHA1: it is a hashing algorythmus, i said hwo it works. Now, the programm decides what it will do with a chunk if it returns a wrong hash.
Hashing times. Of course, it depends on computers' IO. But if hashing of a file with one hashing algorythmus took x minutes, wouldnt it take x*2 while hashing it two times?
I dont know how both hashes work, but i know that SHA1 is more strict than MD4 and that's why it takes a little more time than for MD4 hashing. But these are very small differences.
Evil_Dweller_01
June 17th, 2003, 12:49 PM
I voted for "It's Nice"" because the only difference I see is faster search results..
The downloads SUCK
They jump from 100k to 5k within a span of 5 seconds
Everything else is good though, the network is actually very good
John W. Lindh
June 17th, 2003, 12:50 PM
Originally posted by DIMA2001
[B]FastTrack can't handle its 5 millions...it can handle 10000-30000 users. Everything else is out of your sight.
How do you know how KaZaA's supernodes handle queries? I mean it's a closed protocol after all and it would be entirely possible for the network to query 100,000 hosts if you are looking for very rare content and just 1,000 hosts if you are getting many results for your query.
Edonkey (+ Overnet): 600,000-800,000/1,200,000
The problem is that many of the results you get for searches on eDonkey / Overnet aren't available anymore, - especially if you are looking for rare content.
As you can see, FastTrack is only modified Gnutella with encrypted HTTP headers while accessing other peers. The stats should be also similar to G1.
It started as a modified Gnutella client but the Fasttrack protocol doesn't have much in common with Gnutella anymore.
The whole thing depends on how many leaf- and supernode-connection an average supernode on fasttrack keeps.
If every supernode has 1,000 leafs and 100 supernode connections you can search 100,000 leafs with a query-TTL of 1 and 10,000,000 leafs with a query-TTL of 2.
DIMA2001
June 17th, 2003, 01:03 PM
A little question @ fans of any p2p network:
- do you know from whom you are downloading?
The 'servers' are not some T3 or better servers, they are the same as you ... sometimes better, sometimes worse.
There is a good mathematical 'sentence' which works for every P2P (and also other types of serving):
whole amount of bandwidth (in your horizon) / number of users (in your horizon) = your average download
That means on ed2k network that your average speed should be between 10 and 12 since 60% of the users are on T-DSL (germany) which allows only 16 KBps up and is assymetric and thats why the most users set it to 10 or 12.
If you get more, others get less. If you get less, others get more.
And it doesnt matter if you have also a T3 or an ISDN cable.
On a P2P Network your average download speed is bandwidth amount/user count.
It doesn't matter if you are on KaZaA, FTP, HTTP, UseNet, Shareaza or ed2k.
Example for FTP?
We have an FTP with total amount of speed=90KBps. 3 Users connect - you get only 30 KB max. If you get more, others get less.
A better example with FTP is such one:
the FTP server allows maximum amount of traffic = 1 Gigabyte.
You connected at 12:00 and an another user connected at 13:00 and you both download with 10 MBytesPerHour. Now, unfortunately, you 'stole' his 5 MB, if you will stay on the server until the traffic exceeds.
-------
Moral: you can't blame a client for download speeds really. You can blame it for its inefficient protocol ... and G2 is not a bad one. You just lack on luck because i always get small queues and fast downloads.
I hope that my description will show the users which blame the speeds on other clients. The best thing you gain with G2/Shareaza are: global search and global source exchange of ed2k sources even if they are out of your horizon - G2 makes it possible.
John W. Lindh
June 17th, 2003, 01:05 PM
Originally posted by DIMA2001
Gnutella should have ca. 20,000-30,000 users in your horizon while having 5 good connections in the leaf mode.
If every ultrapeer has 3 connections to ultrapeers, you will have in the best situation 243 ultrapeers in your horizon (TTL=5)
Then, every UP has max 400 leafs (it is standard) ->
243*400 = 97,000
But the most peers have often only 20-30% of their capacity filled. With 20% we come on 19,440 Peers in your horizon.
This is my calculation. I also read on some reliable sources (i think, one of them was napjunk) which said nearly the same numbers.
The result may be realistic, your calculation however is not.
Take BearShare for example, the most popular gnutella client (since it obviously has the most users). Each BearShare ultrapeer has up to 75 leafs (most ultrapeers have 50+ leafs) and 6-10 ultrapeer connections. In addition they use a TTL of 6, - result:
2++ million hosts in your horizon (when searching with BearShare you can really a good part of the gnutella network, - something like 40-50% but according to your calculation it would have to reach the whole network).
Another example is LimeWire ultapeers, - they are keeping 32 ultrapeer connections, 30 leafs (and almost all ultrapeers have 30 leafs) and they are using a TTL of 3. The result - according to your calculation would be ~ 1 million hosts, effectively they are reaching about the same amount of hosts as BearShare.
Sephiroth
June 17th, 2003, 01:19 PM
You cant judge a network by the horizon which IMHO is just window dressing and is really for entertainment use only and are not very accurate no matter what network it is.
Who cares if one program horizon is larger than another using the horizon guesses in this thread it doesnt seem to be that big of an effect. So your only searching a small number of the fasttrack network and yet its still efficient, and people can still download better.
Just because you can find the most files doesnt mean that it will download the faster is just a myth..
Why because things like searching and queues dont do anything to improve the transfers themselves. What good is more sources if they are all busy and you get stuck so far back in some queue there is no way that it will start in a reasonable amount of time.
DIMA2001
June 17th, 2003, 01:30 PM
the host is very important since the percentage of getting more or less sources depends on the size of your horizon.
Because of the small horizon on KaZaA and Gnutella, the chance of getting an upload from you is smaller than on a network where the horizon is very big or unlimited (ed2k, G2)
Since everyone knows everyone else, everyone queries everyone and because everyone doesnt have unlimited number of sources, you have to queue.
What is more ethical?
Hammering a host with your requests
or
Waiting for a queue update from the host?
I think that waiting for a queue update sent by the host is better than hammering it with requests. Your requests would make a DDoS attack on a host since you wouldnt be the only one.
For a SR release, no host would be able to stay alive because it would be hammered by 100s if not even 1000 hosts.
That's why the horizon is so important and that's why you stay so long in the queue on networks with bigger horizon.
DIMA2001
June 17th, 2003, 01:33 PM
Another example is LimeWire ultapeers, - they are keeping 32 ultrapeer connections, 30 leafs (and almost all ultrapeers have 30 leafs) and they are using a TTL of 3. The result - according to your calculation would be ~ 1 million hosts, effectively they are reaching about the same amount of hosts as BearShare.
My fault, i wasnt on BS or LimeWire for a very long time. Only on gnucleus etc. when i used Gnutella, Shareaza and Gnucleus used 400 hosts by default, if i remember it the right way.
Now, since LimeWire supports GUESS, not so many ultrapeers are needed and many GUESS ultrapeers can be accessed indeed, even if the leaf numbers are very low and ultrapeer numbers are very high.
My fault again.
DIMA2001
June 17th, 2003, 01:44 PM
If every supernode has 1,000 leafs and 100 supernode connections you can search 100,000 leafs with a query-TTL of 1 and 10,000,000 leafs with a query-TTL of 2.
But think of the traffic !
An edonkey server becomes bad, if it is on 16kbps out and has only 300-500 users on it.
And the edonkey servers dont have a TCP or UDP connection between each other. The Server-own-clients communicate with the server over TCP and the outter clients (if you extend the search) send a direct request per UDP and the server responds with UDP. AFAIK, the actual server software can even queue the UDP traffic, but i dont know if it is true. If yes, then it is good.
With 1000 direct communication traffic and 100 routed traffic, where the traffic comes again from 1000*100 peers, dont you think that there would be a very big traffic amount?
And just make a small test: ask your friend to write a text file with a random symbols and let him share it. Search for it. Will you find it? I doubt that you will find it on KaZaA ;) There is no real possibility to manage such traffic by using Gnutella-similar technology, even if you increase the amount of connections. At least it is not possible without making clustering.
I currently mean under clustering that several supernodes/ultrappers/hubs/server or whatever find eachother and create a big server. And if one server gets a request, the other can return the results for him. It is currently made on G2 and that's why it is so effective.
ROMANTICGUY50
June 17th, 2003, 02:36 PM
I use Shareaza alot. I like the G2 and the fact that they added
edonkey to I have not had much trouble with it so far. I use Windows XP. I do think that it is a good P2P. I can't wait til the final version is out
:gj :gj
Sephiroth
June 17th, 2003, 03:24 PM
Originally posted by DIMA2001
the host is very important since the percentage of getting more or less sources depends on the size of your horizon.
Because of the small horizon on KaZaA and Gnutella, the chance of getting an upload from you is smaller than on a network where the horizon is very big or unlimited (ed2k, G2)
Since everyone knows everyone else, everyone queries everyone and because everyone doesnt have unlimited number of sources, you have to queue.
What is more ethical?
Hammering a host with your requests
or
Waiting for a queue update from the host?
I think that waiting for a queue update sent by the host is better than hammering it with requests. Your requests would make a DDoS attack on a host since you wouldnt be the only one.
For a SR release, no host would be able to stay alive because it would be hammered by 100s if not even 1000 hosts.
That's why the horizon is so important and that's why you stay so long in the queue on networks with bigger horizon.
Horizons are at best an guess at the number of people on the network. They arent accurate and really just window dressing. I think of it as entertainment use only.
As you admitted in a post following this one you did not use a gnutella program that long because of the Alt-Loc system in gnutella and which shareaza uses the same system because you use shareaza alot alt loc to your system are more propogated through the system than on gnutella because you were not connected that long. It is not all about the horizon as you say the long you use a program the more uploads your going to get because the more propogated you get in the network. And as with the alt-loc system you dont have to constantly requery as the only method to find sources.
If the queue is large enough then i dont think it really matters. By updating the queue you still using bandwidth and queues do not save a tremendous amount of bandwidth and does nothing to improve file transfers.
Telling a user that they will have to wait more than a few hours is no different then saying busy because in the end it still means that they have no chance at getting the file. Queues are not a guarentee that you will be able to get and complete the file from that user.
Malicious hosts will requery and use other malicious ways to give them an unfair advantage no matter if there are queues or not would not have any effect.
Psilaxs
June 17th, 2003, 04:33 PM
And when that theoretical horizon is reached, i can always jump supernodes in kazaa.
I have been through this countless times,and really do not feel like writing a mini thesis on the attributes of the fasttrack protocol, but i suggest DIMA, that you download the newest build of kazaa with the zupernode manager.
And play around with it, you can select supernodes right down to your neighborhood (no lie, I connected myself to ONLY 1 node which was located in my city) I think you will be surprised how big some of the network segments are. And also, how limited search results can be when only on a very small node.
I mention the few search results because there is no way in hell i could find a lot of the content i do if the horizon was only 20,000 or less.
(if this is incoherent BAH, i have been up for a day a and a half)
John W. Lindh
June 20th, 2003, 01:12 AM
Originally posted by DIMA2001
Now, since LimeWire supports GUESS, not so many ultrapeers are needed and many GUESS ultrapeers can be accessed indeed, even if the leaf numbers are very low and ultrapeer numbers are very high.
My fault again.
LimeWire does not use GUESS. (LimeWire will answer UDP queries but it does not send them).
John W. Lindh
June 20th, 2003, 01:23 AM
Originally posted by DIMA2001
With 1000 direct communication traffic and 100 routed traffic, where the traffic comes again from 1000*100 peers, dont you think that there would be a very big traffic amount?
Not at all. Because not every query has to be sent to all the 100,000 peers in your horizon but only to up to 100 supernodes. On fasttrack queries are never sent to the shielded clients.
And just make a small test: ask your friend to write a text file with a random symbols and let him share it. Search for it. Will you find it? I doubt that you will find it on KaZaA ;) There is no real possibility to manage such traffic by using Gnutella-similar technology, even if you increase the amount of connections.
Kazaa is not so similar to gnutella. And it's not a problem to manage the traffic if you have control over how many results a search returns.
At least it is not possible without making clustering.
What you call clustering is not really an improvement.
triniti
June 29th, 2003, 12:29 AM
One Word: "CRAP"
isus
July 1st, 2003, 05:46 PM
Originally posted by triniti
One Word: "CRAP"
triniti: user of kmd v2.5
it's always good to say "one word: crap". bc then you have said 3 words to accomplish a one word post. thanks for, uh, nothing.
thongsai
July 1st, 2003, 10:51 PM
lol about 90% of people who hate shareaza likes kazaa.. we just cant convert them.. i cant wait for when or if all the kazaa users head over to shareaza and say, " wow this is good!" but too bad that wont happen any time soon
MoonMan
July 4th, 2003, 12:18 PM
Originally posted by thongsai
lol about 90% of people who hate shareaza likes kazaa.. we just cant convert them.. i cant wait for when or if all the kazaa users head over to shareaza and say, " wow this is good!" but too bad that wont happen any time soon
No you just assume that. I personally cannot stand EITHER app.
For the past two days I have been on DSL and I have to tell you, I've been RAPING the bandwidth away from others using apps like DC++, Bittorrent, and mIRC. I even gave Shareaza another chance and it did a LITTLE better than when I was on dialup but still crap compared to other file sharing applications I have tried. KL++ didn't do much better except that he search results were massive.
Conclusion:
App | Max speed | Personal grade
Bittorrent | 120KB/s | A
DC | 112KB/s | A
KL++ | 59KB/s | C
Shareaza | 45KB/s | D
(Side note, I was using Shareaza mainly on G2. I couldn't even start a download with it in eDonkey or Gnutella.)
isus
July 4th, 2003, 12:30 PM
just a question moonman:
can you go try winmx and tell us what your max speed is, along with your grade?
i'm just curious to see how it does...