Searching the Smart way
 

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

bad idea
 

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 http://www.gnutellaforums.com/showth...9&pagenumber=3

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?

Supernodes, Superpeers, Ultrapeers (different names, all the same)
 

The forum search will e.g. give you this thread: "Improving Gnutella performance"
http://www.gnutellaforums.com/showth...&threadid=5254

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.

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.

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