Gnutella is a decentralized network and has no central server used for coordination. Once a Gnutella host is connected to a Gnutella network they act as a coordination node that is free to exchange files with other hosts.


Gnutella originally worked, imagine a large circle of users, called NODES, who each have Gnutella client software. On initial startup, the client software must bootstrap and find at least one other node. Once connected, the client requests a list of working addresses. The client tries to connect to the nodes it was shipped, as well as nodes it receives from other clients, until it reaches a certain quota.


A Gnutella host first joins a Gnutella network by connecting to at least one other host on the network. To obtain files a client must query the network to find out where files are located. One of the computers sends a search message to all of its connected computers. This message is propagated to other connected computers. A time to live (TTL) field in a query message will ensure that a message does not last forever. The furthest node possible where the query message dies is termed as the search horizon. When a computer contains files that match the search message it sends a search results message back along the path the request came. Once the search results are returned, the client can directly connect and download from a peer carrying a desired file. We can plot an example as if the computer which needs the file guts the message back from the 4th computer in the network it will download the file from there and will ignore all other computers in the network.

  • Message Types

There are five messages defined for coordination and discovery of files between Gnutella Peers: ping, ping response, client ping request, search, and search results.

  • Protocol Type

All connections between Gnutella peers use the TCP/IP protocol. A small subset of HTTP constructs will be used for the initialization of peer connections. These include the messages CONNECT, OK, GET, and GIVE. In discussion of the protocol all messages are shown in bold and italic.

  • Download Instance

Download Instance is given in Figure 19. It has five states: connect to peer, wait for file, download file, download finished, and terminate. Initially the Download Instance starts in the connect to peer state. To start the download the peer sends a GET message containing the desired filename to download. It then changes state to the wait for file state. A connection error to the remote peer will cause a state change from the wait for file state to the download finished state. Otherwise the peer will receive an HTTP file header and the first byte of the file. This will cause a state change to the download file state. The Download Instance will remain in the download file state as long as it continues to receive bytes of the file. Once the file has been successfully received it will come in download finished state.

  • Upload Instance

Initially the Upload Instance starts in the send HTTP header state. In response to the GET request of the remote peer an HTTP content header, and the first byte of the file will be sent to cause a state change to uploading file. Bytes will be sent to the remote peer until the file has successfully uploaded or there is a connection error. At this point the state will change to the upload finished state. The connection will be closed and the Upload Instance terminated. And if no error occurs and the download is uploaded successfully again the message appears upload finished.


Gnutella removes centralization and extends the model further by requiring the peers to contribute to the coordination and discovery efforts. Gnutella is resilient since there are no centralized components, but it is not scalable since the structure of Gnutella produces an exponential number of messages.