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

-- 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.

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 ...

__________________
Cheers

Felix

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

But think of the underlying issue though: bandwidth. At least, I think that is your concern here. The ones who carry the biggest burden with Queries, is those who cannot responde to them but merely broadcast them. So, that would always be the freeloader. In my opinion, that is not such a bad thing at all.

A much better solution to this issue would be to deny sending a result to a freeloader. Queryhits are usually bigger, even when the broadcasted Queries are summed up. By refraining from sending a Queryhit to someone known as a freeloader, you will:

1) reduce bandwidth
2) give the freeloader incentive to contribute

I've followed some discussions here about that as well. The best one I've seen, and also something I'm looking to implement in my client, is a "rating". When the user runs his Gnutella client for the first time, his rating is 50/50. But the more he dowloads without uploading, his ratio drops. Below a certain ratio, he/she is assumed a "freeloader". This data can easily be sent with a Query.

Obviously, there are a few drawbacks to that method. The first would be those who figure out what to edit to increase their ratio. The second would be where the user shares stuff that, in general, is not popular. There's a third one too, where the user could rename junk/text files to popular files in order to increase his ratio. However, with the introduction of what is known as HUGE (a hashing system), this will most likely not survive for long.

-- 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.

Isn't this still the same? If you stop routing Query or Queryhits, whatever, you will cut off any user behind this freeloader and so harm the network.

I have listed this under the terms of 'Mojos' (see my anti-freeloading list, section D). I think local Mojos (even hash based) could be allways faked by patching your client, by changing stored client statistics or simply by using a client that doesn take part at your Mojo system. Guess how long it would take until the first Mojo-Freeloading tool hits the network? Only remote or central hosted Mojos (e.g. similar to FTP-Server or IRC-based Fileserver) with a IP/user based ratio and authetification prevents cheating.
I personally do not believe in Mojos: IMHO Gnutella should be designed to stand against bad clients/abuse, be free as possible (think about the web, free and easy information access was the success) and we still have many other unused possibilites left to prevent freeloading.

Greets, Moak

A Query is a broadcast message. A Query hit is a routed message, taking only the path it came from and destined to only the user that requested it.

It would only be "harmful" if other clients relied on Query Hits for passive searching.

True. And that's also one of the drawbacks I had listed. There will always be someone who'll try to circumvent this. But there are a few things the cracker should keep in mind when doing so, and the most important one: is it really in his benefit? I mean, would it help him (her) by allowing freeloaders on the network, so eventually he won't find anything he wants anymore?

-- 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.

I agree with Mike pretty much , though I also doubt that there is a bulet-proof way for rating that can not be faked.

Since I am following the discussion here, I think somehow that we talk about 2 things: One is bandwidth the other is how to "do something against freeloaders" ... and I don't get the point what the two things have to do with each other ... at least freeloaders do not cause are "needed" to keep the network together (though they might lower your effective horizon cause of "unnecessary" hops = freeloaders in your network path).

I think the bandwidth problem is a Gnutella Protocol issue not a freeloader issue ...

So if I get you here you wanna send the queries (incomming/outgoing) to the first list. Do you want to connect to these hosts as well? I mean then you might eliminate some freeloader paths" in your horizon. I mean then one could close the connection to a potential freeloader and ( I am brainstorming ) that could leed to a new network structure where freeloaders are cut out by time if all clients act like this. On the other hand how do you want to rate a client whether he is a freeloader or not? I mean someone might provide files that you are not interested in at all though others might be?
Another thing: cutting out those who do not respond to your queries may lead to a "smaller network"/ smaller horizon for your client but this smaller horizon may have more clients with files you look for ... or am I fascinating totaly now ?

__________________
Cheers

Felix

Hm ... should we really be afraid of some geeks? Or do you really think that there would be clinents out after a short time compromising the whole thing? Just asking ... you might be right.

__________________
Cheers

Felix

Just take the source code of an existing client, change 1-2 lines in the source code, and you have your freeloading tool again. It's that easy! Or even more easy... just take an old/existing client with has no mojos.

Hi Mike!

It is still the same. For example: If a freeloader is between you and me, I would never get your search results, because you regret to send it via the freeloader route, I will be cut off.

Moaky Moak

PS: I know I repeat myself, I believe superpeers and swarming will be a better solution to decrease bandwith and handle with "useless" nodes. I personally follow a way of encouraging people to share instead of tolerating freeloading. I see freeloading as a selfish symptom, ppl do it because they can't see the bigger context, that they hurt themselfs.

I wouldn't say that 'afraid' is the correct word for this. But apparently, preventing widespread freeloading is a benefit to all Gnutella users, including those who would normally be freeloaders. If someone decides to take that benefit away, the cycle starts over, and the network will be diluted with 'empty' nodes again.

But cracking in general: whatever tickles your fancy

-- 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.

Okay, I see your point, and you're correct. But I think you misunderstood me.

Assuming that there's a freeloader between you and me:

-- If you send a search request, I will still send a search result - because the destination is not the freeloader.

-- If the freeloader sends out a search request, neither you nor me will send a search result, because the destination is the freeloader.

I only refrain from sending the search hit if the *destination* is the freeloader. Anyone before or after this freeloader will still receive his search hits.

-- 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.

Hi Mike,
ah I understand. Just to make sure, does this mean you want to block freeloaders from receiving any search result?