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

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

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 ?

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.

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

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