Lime Group Lime Group aboutdownloadsupportresourcespresscontact
Limewire
Baseline Healthy Client Requirements

Improving the Gnutella Network

We wrote up some of our thoughts on what makes for healthy behaviour of a Gnutella servent. It is more focused on medium term changes but perhaps worth a read. http://www.limewire.com/health.htm

Let me go through what we think the baseline for a healthy client NOW should be.

If we were to remove Gnutella 0.56 clients and get other clients to update themselves, what should they do to promote health on the network?

I'll go into more details but the brief answer would be:
   1) Have an incomplete directory and automatically share downloads.
   2) Block browser uploads.
   3) Avoid network broadcasts.
   4) Implement some form of network rebalancing.

The other way to say this is:
  1) Encourage sharing of content.
  2) Reduce freeloaders.
  3) Reduce unnecessary network traffic.
  4) Encourage a healthy network structure.

t o p

1.0
Point one is fairly obvious and we have been discussing that in the forum a little. Note that you should have an incomplete download directory to prevent the sharing of partial files but then the completed downloads should be shared by default.

t o p

2.0
Now blocking browsers is regrettable and not necessarily what we want to do in the long term. However, for the short term, they are flooding the Gnutella network with upload requests and giving the active client users a bad experience. They take up most of the upload slots on the network without sharing. You can detect the majority of browser uploads by looking for "Mozilla" in the User-Agent header string. I can give a list of download accelorators that we block as well if interested. In fact, LimeWire and BearShare send back an HTML page (or redirect) encouraging users to join the network and share.

t o p

3.0
Our paper outlines some future idea of avoiding network broadcasts. The most important right now is to not broadcast pushes. We have also been discussing that in the forum. Broadcasting in general should be kept to a minimum - i.e. don't actively ping the network.

t o p

4.0
So, I think the network rebalancing needs some mention. We currently have a much healthier network than a few months ago but as the network grows, this could become more of an issue again. The basic idea is that if all servents behave in a particular fashion, the network can heal itself and remove some of the congestion due to the modem bandwidth barrier. The simple answer here is to drop a connection if it gets clogged. What we hope that this will cause is for the slower modem users to move out from the center or fast areas of the network. Obviously, encouraging the use of reflector is good - if there are publicly accessible reflectors. Here are our rules for dropping a connection.

Drop clients if:
  +They have been unable to receive our data for ~10 seconds.
  +They have sent us no data for ~10 seconds AND do not respond to a ping with TTL=1 AND are not a Clip2 reflector.

One other thing that we would recommend is message prioritization on sending. If you have a certain I/O limitation, you might need to drop some messages in a smart fashion. Obviously, you prioritize your own query messages first but those are a tiny part of your traffic.

The best order for prioritization is this:
  Pushes
  Query Replies (Hits)
  Queries
  Pongs
  Pings

If you need to drop packets, drop from pings and pongs on up. This will help pushes work and allow the network to function reasonably under stress. Note though, if there is an overly slow or clogged connection, it needs to be dropped. Perhaps this qualifies as brute force flow control. The basic goal here is that one slow connection should not prevent others from making progress.

There are likely other improvements that we can all think of. (multi-direction push routing?) However, I believe that this set would create a much better network.

t o p

home | about | download | support | resources | press | contact | legal | sitemap