Based on a topic in the Development Forum, I though I should write a rough outline to get you started building your own Gnutella client.
First of all, and the most obvious, you need a programming language to start with. This can be any language that has a basic TCP/IP interface. Visual Basic, C, Delphi/Pascal, Java, Python, whichever your choice.
Next you need to understand what is being sent on the Gnutella network, and how you should respond. The most comprehensive document to date can be found at this URL:
Gnutella Protocol 0.4, revision 1.2 (PDF)
The document explains in layman’s terms what type of messages exist on the version 0.4 Gnutella network, and what you need to do with each such message.
The referenced document is located at "The GDF", short for the Gnutella Developers Forum (see http://groups.yahoo.com/group/the_gdf/). The GDF is a collection of Gnutella developers, users and lurkers that (usually) come to a mutual agreement about additions or changes to the Gnutella protocol and discuss their ideas or other interests. It might be beneficial if you subscribe to this group - there are no obligations.
One of the most recent changes made through the GDF is the way Gnutella clients start talking to each other - the handshake. The above mentioned document explains about one possible method, which is still accepted. However, the new handshake, version 0.6, is expected to gradually replace the other handshake. The following URL will document this new handshake in full:
When reading through the documents, you will notice the mention of "Vendor Codes". These vendor codes help other vendors identify how to address certain chunks of data in messages, as they may vary per vendor. Don't worry too much about it at this moment - this vendor-specific data does not affect how Gnutella works. But if you'd like to use your own vendor code, visit the GDF at the URL given above and enter your vendor code into the database. You'll can also see other vendor codes in this database, so chances for duplicate vendor codes will be reduced.
Once you have read through these documents, make sure you really understand it all before you begin. If not, visit the Gnutella.com Community or the GDF and ask. Don't worry if your question may seem "stupid" or "newbie"-like. No one is going to bite. And I am sure you will have a few questions because even though the first mentioned document is considered the most comprehensive, it still has many voids. A number of people are trying to fix that issue with a new document - expect that somewhere in early or mid 2002.
I highly recommend thinking what your intentions are. Are you going to build a Gnutella client for your personal use, or will it be for anyone? Is it going to be a single threaded application or multi-threaded? Will it be for Windows, *nix, Mac or all of them? The reason is that once you're in the progress of writing, you'll find it rather difficult to make certain changes because of how Gnutella works internally.
While you're writing your client, you need some means to test your code. Don't spread a pre-alpha product to thousands of people and ask, "does it work?” If there's a serious bug within your client, it may throw off a lot more other clients/users, not just your own. So download a few clients for your platform from Gnutulla.com's Connect section. Use these clients as if they are were located directly on the Gnutella network, and connect to them using your own client. You don't need a local network for this purpose, although it may prove helpful.
More experienced developers may also want to use a packet sniffer. It will allow you to see what your client is receiving and sending. Sometimes, you can find those mysterious problems this way. As little as one missing byte can throw some Gnutella clients off, usually referred to as "Out of Sync".
In reference to "Out of Sync", another thing I’d like to point out is that you should rely on the message's size. The document mentioned first in this article refers to that as "Payload Length". It is very important that you send out as many bytes as you've received when routing or broadcasting. Occasionally, vendors may send a little more data than officially documented -- don't truncate it, but include it when passing the message on! This allows the Gnutella network to be extended with a bit more ease, without having certain clients come to a crashing halt.
Most importantly is the use of Gnutella etiquette (good conduct). Gnutella is not a finished protocol, but a work in progress. There is still a number of issues that are fragile. For instance, be careful with automated re-search queries. While such feature can't take down the network, it may interfere with the end user experience (slow responses, etc). You should always try to be "the best of the class" when it comes to "Gnutella client behavior".
Last but not least, stop by at Gnutella.com often. It will help you stay up to date with your development!