Some Conclusions After Some Experiments...

Quote:

G1 (Gnutella 1) is in fact growing, although at a slower rate than more popular networks. It has a reputation of slowness and 'as a last resort' network when your connection is so firewalled that no other network/s will work.

So G2 is NOT the successor of G1? By simple logic (2 comes after 1 ;) ), I thought that the arrival of G2 meant the gradual phase out of G1. Are they being developed in parallel, instead?

Quote:

Shareaza works a lot better if you just don't connect to edonkey, try it...

Maybe it does, but given the fact that in my searches the vast amount of results comes from ed2k, disconnecting from it will kill one of Raza's competitive edges: Its great file availability... :( It seems like a Catch-22 situation here: Connect to ed2k, you get results but slow d/ls-disconnect, and you get no results and fast d/ls...

Quote:

Originally posted by jackc@4 February 2004 - 05:17

Quote:

G1 (Gnutella 1) is in fact growing, although at a slower rate than more popular networks. It has a reputation of slowness and 'as a last resort' network when your connection is so firewalled that no other network/s will work.

So G2 is NOT the successor of G1? By simple logic (2 comes after 1 ;) ), I thought that the arrival of G2 meant the gradual phase out of G1. Are they being developed in parallel, instead?

Yes, G2 is NOT the successor of G1!

The "Gnutella 2" protocol was developed only by the programmer of Shareaza (A.K.A. Mike), who felt dissatisfied with the rate of change in the Gnutella developers forum ( http://groups.yahoo.com/group/the_gdf/ ) and with all the 'legacy' protocol extensions that had to be maintained/supported to be considered a 'true' Gnutella client.

He decided to write a NEW file-sharing protocol from the ground up, trying not to make all the 'mistakes' (in quotes because many of these questionable things were done for good reasons) that Gnutella had, and called it Gnutella 2 without any consideration towards other Gnutella developers. It was strongly felt by them that he was seeking to hijack the name and use it for his own fame/gain/etc. Inside the Gnutella developers forum, the Gnutella 2 protocol is often reffered to as "Mike's Protocol".

Having said all that, Shareaza's Gnutella 2 protocol does have minor advantages over the latest Gnutella v0.6 protocol (as implimented in BearShare and Limewire.) It CAN allow users to search the entire Gnutella 2 network so long as that network remains small (<100,000 users) and the file/s searched for are rare -- for this to be sustained beyond those limitations requires ever-increasing amounts of bandwidth at the supernode/ultrapeer level.

Not only do Gnutella 1 and 2 continue to be developed in parallel, Mike (the maker of Shareaza) has continued to support Gnutella 1's protocol in Shareaza... so well in fact that his program has as good or better connectivity into the Gnutella 1 network as BearShare OR Limewire. I ought to know, on BearShare many of my downloads COME from Shareaza users!

The reason why Shareaza (when connected to just the Gnutella 2 network) doesn't vastly outperform things like Kazaa Lite is because even though the network protocol is FAR more efficient (meaning less overheads are wasted to get downloads completed) there are simply fewer users (to download from.) Even Gnutella 1's protocol is considerably more efficient than Kazaa's -- and it is still improving. (Alt Locs, a quick way to gather additional sources for downloads have been reduced from about 1 KB in size to less than 30 bytes per ip source past the first!) Much of the legacy stuff in Gnutella has been dropped with Gnutella v0.6 -- which not only makes it faster, but encourages (the painful way!) users to upgrade to a version made in the last year.

However, there are still some very thorny and painful issues in Gnutella 1 (and 2 as a couple clients have come to TRY to support it) with automatic source searches and download retry rates. A client that retries downloads very quickly has a better-than-average chance of starting a download than others, but does so at the BANDWIDTH expense of everyone. The same is true with a client which automatically seeks new sources for downloads at a rapid rate. At it's worst, it's cheating -- needlessly using lots of people's connection's bandwidth and slowing everyone's downloads and uploads down. But where do you draw the line? A client that retries ALL its searches and ALL its downloads (for more sources) once every 10 seconds quickly overloads the network backbone it's connected to. Believe it or not, even a single search for ".MP3" files might consume 100+ MEGABYTES of bandwidth across the network! Even a very rare search might consume 1 MB or more of bandwidth if added up across every connection that had to receive the search and forward it on. (If a search takes 1 KB to send to 1 connection and it's sent to 1,000 connections, that's 1,000 KB or roughly 1 MB. But searches are now easily reaching >1,000 UltraPeers with 10-200 leaves each!)

Gnutella Leaves are equal to nodes on Kazaa and UltraPeers are equal to Supernodes. Peers was all that existed in earlier Gnutella versions and was mainly why Gnutella ORIGINALLY sucked. Now, UltraPeers have no more message/network traffic (measured in bandwidth used) across them than Peers originally did but they support 10-200 TIMES as many connections!

BearShare's detailed network statistics for its updated v0.6 versions only ( http://www.bearshare.com/stats/ ) shows that the average upload speed for leaves which make up the majority of the network is hovering around 2 KB/sec. It's been pointed out that about 80% of the network is made up of 56k modems, so only 2 KB/sec uploads makes sense... but is a painful fact. Even the UltraPeers which HAVE to be much faster than Leaves to BE UltraPeers are only uploading at 4-6 KB/sec on average! This doesn't mean VERY FAST downloads can't come from Leaves or UltraPeers, just that most don't -- and MANY don't share anything at all or seldom have an active upload even though they ARE sharing.

Because of this, ANYTHING that eats bandwidth without giving faster download speeds to almost everyone really isn't something file-sharing networks can support.

Kazaa is little different in that regard, it just may seem so due to local conditions. Auto-continuing searches in KL++ and jumping supernodes just allows us to see more of the network, so even if the average download rate PER node is low it doesn't matter so long as FEW are taking advantage of searching more of the network.

A really horrible surprise learned just recently by all the Gnutella developers (BearShare's stats-gathering caused this) is how MUCH of the network is FIREWALLED! Roughly 2/3s of BearShare is, and probably equal or higher amounts of Gnutella 1 and 2 is. But from what I can tell about Kazaa/KL++'s (FastTrack) protocol, it's even WORSE on Kazaa/KL++! On Gnutella 1 or 2, you can use a router and not be firewalled just by port-forwarding whatever ip port Gnutella 1 or 2 users. But on Kazaa/KL++, you have to port forward Kazaa/KL++'s ip port (on both TCP AND UDP!) AND run KaNAT -- and even still there are brief moments where the connection will appear firewalled and/or giving out your local LAN ip! A side-effect of this is if you are firewalled on Kazaa/KL++, then your download options are FAR WORSE than if you're not. Someone who's not firewalled may have 100+ KB/sec download speeds, but someone who is firewalled may be lucky to find anything at all to download.

This shows Gnutella 1's approximate size (actually a low estimate):
http://www.limewire.com/english/content/netsize.shtml

BitTorrent *IS* different because usually multiple files aren't competing for upload-time. People usually run only 1 or 2 torrents at a time and often allow them to continue uploading (or just forgot they were uploading) after the download finishes. There is no search ability in the BitTorrent program (or BT clones), so the TIME it takes just to find more to download using BT is considerably greater than on Kazaa/Gnutella 1 or 2/Emule/etc. Also, BitTorrent has forced sharing by EVERYONE -- often without upload limits, unless explicitly specified. The BitTorrent clone programs on the other hand DO have upload limits which can be made the default settings, so that's the speed they start at with each NEW torrent.

That was a useful piece of info, Switeck! Thx... B)