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
|