Origins
In late 2002, Shareaza’s author Michael Stokes introduced Gnutella2, a reworked version of the Gnutella protocol with fundamental changes, and added it to Shareaza. The name was controversial among Gnutella developers, but G2 became Shareaza’s native network and was later adopted by other clients.
How a G2 network is organised
Like later Gnutella, G2 uses a two-tier design:
- Hubs are well-connected, long-running nodes that route searches and keep an index of what their leaves share.
- Leaves are ordinary clients connected to a few hubs. They don’t route traffic for others.
Searches are sent to hubs, often over UDP, and hubs reply on behalf of their leaves. This cuts the flood traffic that made the original Gnutella hard to scale. G2 messages use an extensible packet format, so new fields can be added without breaking older clients.
Bootstrapping and Gnutella Web Caches (GWC)
A new client must find at least one live peer before it can join a decentralised network. One historical answer was the Gnutella Web Cache (GWC): a small script on a web server that clients queried over HTTP for lists of recently seen hosts and other caches.
This domain once ran such a cache at gwc.pantheraproject.net/gwc.php, and the old wiki had a page about GWCs. Both URLs are handled here.
Why we don’t run a web cache
We considered restoring the GWC and decided against it:
- No independent justification. We don’t operate a G2 client community and can’t keep host lists accurate.
- Abuse risk. An open host-list service can be fed bogus addresses and used to point many clients at a victim, a known traffic-amplification pattern for P2P bootstrap services.
- Trust. Clients would be trusting a domain whose ownership changed, which is the exact weakness that hurt Shareaza in 2007.
So gwc.pantheraproject.net doesn’t serve a cache. If DNS for it ever exists, requests receive 410 Gone.