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

Anyways, thanks for your input.

Stig Eide

Every Input is welcome! :)

Just one more thing though. A TTL of 120 will not survive long, as most clients will drop messages after 7~10 hops.

-- Mike

Also, say you are connected to three other nodes, and they are all freeloaders. Where does the search go now?

My measurements have shown that even if you use a TTL greater than 7 you won't get back packages with a TTL > 7 with very high probability ( I talk about 99.9% I haven't calculated that number exactly yet). So you horizon today is "aways" 7 hops in the gntella network.

So cutting out the freeloaders from your searches will give you less hits. Raising the TTL won't help. But as you might know there are other ways how to to priorotize a search/hit ... like eDonkey does.


@blb: Searches contain a TTL time, which is a number of how often the search is forwarded in the network. So the freeloaders will forward the Search if TTL > 1 ...

First, I know that a request with TTL=120 will (thank God) not survive - it was just to make a comparison between the old, inefficient method and my Smart method. It is easier to compare the efficiency of two methods if they consumes the same amount of bandwidth.

Anyways, you have to admit that the current method of sending searches blindly is inefficient?

My (Smart ;) ) method would use two lists of hosts for each client:
One list to send and forward queries to.
This list should be cultiv8ted by hosts that responds to your searches. This way you have the great benefit of being close to hosts that hosts files that you want.
One list to receive queries from
This list, you should not care who is on. But you know that these hosts prefer your files, if they are using the Smart method.

My claim is, that this method will make the searches much more efficient because:
Searches is only send to those who actually have files.
The probability that the hosts that see your search will return a hit is bigger, because they are closer to you in "taste".

You can think of it as insiders and outsiders. The outsiders are freeloaders and sends the requests to the insiders. The insiders sends the requests to other insiders.
A cute picture:
http://www.geocities.com/stigeide/s.html

Peace!
Stig Eide

Looks like superpeer concept :)