Gnutella2 Standard

What is the Gnutella2 Standard?

The Gnutella2 Standard is a set of requirements for building applications which operate with the Gnutella2 Network in different capacities. For example, the Gnutella2 Standard for File Sharing specifies a set of features and behaviours which must be available in any Gnutella2-connected file-sharing product offered to the public.

Why is a Standard Needed?

As an open, general purpose platform, Gnutella2 networks must be able to operate with a diverse family of different implementing applications. Every effort has been made to limit the ill-effects a non-compliant application can cause (deliberately or accidentally), however, when it comes to critical features such as common URN schemes and character encodings, minimum standards help to ensure a favourable baseline user experience.

How are Standards Enforced?

The open and transparent nature of the Gnutella2 architecture makes technical enforcement difficult, so a more viable (and hopefully, more productive) social scheme has instead been adopted. Only applications meeting the appropriate Gnutella2 Standard may be marked as "Gnutella2-compliant". Websites containing information about Gnutella2 (such as gnutella2.com) are encouraged to list only compliant applications, and application developers are encouraged to deny communications with known non-compliant applications. Applications which do not comply with the standard, or are still in the development process, should never be made available to the public, however, private testing is always encouraged.

How are Applications Tested?

Ultimately, it is the responsibility of the developer to ensure their own application complies with the relevant standards, both with respect to Gnutella2 and any other functionality they may be including. However, as an inter-dependent community, developers of Gnutella2-compliant applications are encouraged to take an interest in other Gnutella2 applications, and where possible, examine them for compliance. Similarly, new developers are strongly encouraged to seek assistance from other developers in verifying their work. This need not compromise competitive advantage - if the application is sensitive, the important compliance testing phase can be performed in the days prior to release.

What Standards are Available?

At the current time, only one Gnutella2 standard has been published: the Gnutella2 standard for File Sharing Applications. Additional standards for other application classes will be published in the future as required.

Developers of new application classes are operating in somewhat untried territory, and should review the existing published standards for best practices which can be borrowed. In particular, the basic components of the Gnutella2 network architecture should always be implemented in full.

Common Gnutella2 Standard (All Applications)

All applications making use of Gnutella2 technology for any application class MUST IMPLEMENT the following core features:

• Bidirectional TCP stream connections (stream compression OPTIONAL)
• Bidirectional reliable UDP protocol (Gnutella2 reliability layer and stateless compression REQUIRED)
• HTTP-style link negotiation, exchanging at least the required headers
• Gnutella2 protocol support, graceful handling of unknown trees
• Localised, UTF-8 and UNICODE decode REQUIRED, encoding to each optional
• Operation in LEAF mode, additional node states OPTIONAL
• Basic link handshaking and maintenance functionality (PI/PO/LNI/KHL)
• Global node addressing scheme and routing maintenance, addressing children (TO)
• Reverse (PUSH) connection response (connecting out)
• HTTP/1.1 client and server for peer to peer transactions

Gnutella2 Standard for File Sharing

Applications making use of Gnutella2 technology for file sharing MUST IMPLEMENT the following features:

• All of the COMMON features listed in the previous section
• Operation in LEAF mode, additional node states OPTIONAL
• Some form of bandwidth management scheme, to keep network and transfer bandwidth below 95% of the user's link capacity - be it manually configured or some automatic scheme (very important to avoid flooding local connection)
• SHA1 and TIGER ROOT URNs for all shared objects
• XML metadata, using existing schemas where appropriate (manual entry and peer acquired at minimum, automatic local collection highly recommended, service lookup optional)
• Universal 1-bit query hash filter, at least 2^20 length, intelligent density management scheme (superset combination required if supporting hub mode)
• Gnutella2 object search mechanism, all client responsibilities and if supporting hub mode, server responsibilities too
• Local search processing, including simple query language (Boolean operations, quoted search terms, numeric range searches, interest flagging (I), local rulebased metadata searching)
• Extensible hit format (URN/DN/MD/URL are REQUIRED, all other extensions OPTIONAL)
• HTTP/1.1 based upload system, URN based requesting, partial content requests, active queuing, partial file uploading, timestamp protected alternate source cache and exchange
• TigerTree volume calculation on shared files, caching on downloads, exchange via DIME. Local corruption detection OPTIONAL but recommended.