In an rather old article, it is suggested that 70% of the servants are not sharing:
http://www.firstmonday.dk/issues/iss...dar/index.html

Think of it - if the 70% figure is right, then 91% of the bandwith consumed by serchrequests today is wasted. Why? Because 91% (1 - 0.3*0.3) of the requests goes either from freeloader to freeloader, from freeloader to sharer or from sharer to freeloader. All of these should be shaved away.

In my opinion - this is the area where Gnutella clients could develop the most. I am not a developer of Gnutella clients, I just have some ideas:

Don't send serchrequests to Freeloaders. That is, you should not drop the freeloaders from your list of connected hosts. Doing that would damage the network. But, you should test and rate the hosts with some methods; Brainstorming - Send a search that is build up using frequent words in the users shared directory and/or earlier searchs, set the TTL to 1 and register the number of files returned. Using this number as a rating, the hostlist should become better and better for the user.

So, what happens with the freeloaders (the "glue" of our community)?
They would be given a rating of 0, using the above mentioned method. That would put them in the same group as those who share files that I am not interested in.
You should allow them to connect to your servant. You should answer and forward their serches. But you should never send the users searches to them.

So, what would happen if all the clients used this strategy?
I think the searches would become much more efficient and everyone would live happily ever after.

Stig Eide

You will partly stop routing search queries and eighther make the network inoperable or less operable. If a freeloader is between you and a sharer of a file you want, you never get it with your routing rules.

Superpeers and query caches can help to reduce traffic, while freeloader are usually modem users they can be shielded behind a super peer. See also my list of Anti-freeloading features for alternative ideas against freeloading A better way to promote sharing

Greets, Moak

Why would the network be less operable by not routing searches to freeloaders? They will not respond anyway. Of course, they might route the request to the One, but the probability that they just routes it to another freeloader is 70%.
If everybody sendes the requests to those who are on their "buddy-list" (those who share files you like), then the number of hits will be much higher.
I am sure this can be proven both mathematically and by simulation, but today being the first day of the rest of my life, I could not bother

Stig

Hmm without new statistics/simulation I doubt it. I think your idea will decrease horizon and availability, while super nodes together with caches will increase horizon.

What is a supernode? Isn't that just a centralized server in disguise?

The forum search will e.g. give you this thread: "Improving Gnutella performance"
improving Gnutella performance

A very short summary about super peers and other ideas arround (if you're interested):

1. A superpeer concept for dynamic traffic routing = reducing backbone traffic + improves network toplogy + increases horizon (more available files)
2. Search-caches for reducing double/multiple routed traffic = reducing high amout of search backbone traffic
3. Swarming technology = make use of the high amout of wasted bandwith + will spread often requested files + balance load + less "busy" servants (more available files)
4. Add more ideas here.... brainstorming is allways fine

A freeloader may provide a path to non-freeloaders. Even though it may also prove a path to freeloaders, cutting the path in its entire will cut off all of these non-freeloaders, decreasing the available files even more. Also remember that a freeloader may be connected to more than one other node, increasing this possibility even more.

__________________
Okay, so I've been gone a while - but hey, meanwhile online translators have gotten better:

Ce n'est pas ma faute. Blâmer vous-même.

----

Ne me blâmez pas. Blâment votre individu.

I do not have anything against freeloaders. But I can not see why my suggestion would hurt them? I didn't propose to cut them off the network. I say that you should manage their searches as usual, but you should not send searches to them. How can they be hurt by that?

If you don't send a search request to a freeloader, everyone else connected to that freeloader, whether non-freeloader or not, will never see that request, thus reducing the amount of responses you will get even more. That's why it will hurt.

__________________
Okay, so I've been gone a while - but hey, meanwhile online translators have gotten better:

Ce n'est pas ma faute. Blâmer vous-même.

----

Ne me blâmez pas. Blâment votre individu.

It is true that those who is connected to freeloaders won't see the query.
But thats not an error its a feature!

OK, time for some mathematics. Say you send out a query with TTL (time to live) 4. Lets say everyone is connected to 3 hosts.

The old, inefficient and stupid way:
Your query will reach 3**4 + 3**3 + 3**2 + 3**1 = 81 + 27 + 9 + 3 = 120. But since only 30% of these are sharing, the sharing hosts you reach is 36.
The network is fed with 120 queries, and you reach 36 hosts that have more than one file to share.

The new, efficient and Smart way:
Since only one of the three hosts is sharing, you only send the query to that host. He again, sends it only to the sharing hosts in his list as well. This means that you can send a query with a TTL of 120 and still cause as much network traffic as the old way. Since this will reach 120 sharing hosts, you will reach 3.33 times as many files as the old method.

This is obvious!
Stig

In practice, the best way to manage this is to have two hostlists. One that you receive queries from (as today) and one that you send searchs to.
This new list should always become better as you drop those that do not respond to your searches and/or som automatic test-searches performed by the client, based on your shared directory.

As for the freeloaders, noone would want to use them on the list over hosts to send searches to. But that is good for them, less traffic over their modems.

Yep, it's obvious that you will segment the network and get cut off from the files you want (you do not get more files, propably you get none). If you destroy members of a chain the whole chain will be destroyed.
IMHO you are treating the symptoms, perhaps it is better to encourage sharing as suggest in other threads.

Keeping to your example (TTL of 4, 3 connected hosts at each node), you gave us this:

And that's is absolutely correct. You're also correct that if 70% out of 120 were freeloaders, you'd only have a mere 36 nodes that could give you a possible response.

BUT, that is only in the current scenario, where you send a query to each connected node, regardless it is a freeloader or not. Under the scenario you are proposing, to refrain sending a query to a node known as a freeloader, you will end up with a different number.

If 70% of the 3 connected nodes would be a freeloader (2.1 ~ 2), then you'll end up with 1 (0.9) non-freeloader per 3 nodes. So:

1^4 + 1^3 + 1^2 + 1^1 = 10.

10 possible nodes, in comparision to 36 possible nodes is a drastic reduction in my opinion. In both your and my case, we're also assuming an even spread of freeloaders, which is obviously never the case. What if 3 out of 3 connected nodes turn out to be freeloaders - you'd not be sending out *any* queries to anyone.

However, I can agree that you could have a preference for nodes that seem to return more results on average, although you should never refrain from sending a Query message.

-- Mike

-- Mike

__________________
Okay, so I've been gone a while - but hey, meanwhile online translators have gotten better:

Ce n'est pas ma faute. Blâmer vous-même.

----

Ne me blâmez pas. Blâment votre individu.

Anyways, thanks for your input.

Stig Eide

Every Input is welcome!

__________________
I have seen the future and it doesn't work!