So I was reading about P2P stuff and I have this cool idea, only problem is its one of those things where everyone needs to agree to change at once. I'll just describe it here and let the proffessionals deal with the details.

OK, you're all aware of how the Time To Live (TTL) field works when broadcasting messages over a network of nodes such as Gnutella; it counts down everytime the message gets forwarded. (At the same time the number of Hops is counted up)

If you were to search for *.mp3 then you would get several thousand responses before the request gets forwarded even once, that's more than enough. But if you were to search for something really rare like, Orange Penguins Cheat At Risk, then you would need to search further, but you're not allowed to increase the TTL by too much otherwise your request gets cancelled.

I propose that queries include a Hits To Return (HTR) field. Allow me to illustrate:
Say you were to search for Orange Penguins Cheat At Risk with a HTR of 40 and you are connected to 4 hosts. You (or your gnutella client/servent) divides the search between them, each receiving a query with an HTR of 10. Say one of them has 2 matching files (!!) and also has 4 other hosts connected. It would return the 2 query hits, decrement the HTR of that query by those 2 and share the query among it's hosts so they get a copy of the original query but with an HTR of just 2.
If that host had more than 2 cheating orange penguins then it would only return the 2 most likely/best fit hits.

This way a common search would end after a hop or two instead of bogging the network with thousands of near identical messages, also the original searcher, you, would not receive too many hits to make sense of. Your search would be limited to a maximum number of hits and if you hit the maximum then you would be forced to refine your search properly which is just good practice.
A complex, rare search may travel for several hops before running out. You would only bother people (and in doing so, use their bandwidth) with your search if it really matters.
An impossible search would eventually run out because the HTR would be divided to a value less than 1. The TTL field would still be used as a definite limit but the message and network could survive without it.

That's my two cents, hopefully someone will take it on. Thanks for reading such a long suggestion.

Did.

Not to long ago I mentioned something similar, so I like your idea

It could work with the current system, by attaching a GGEP extension to the Query, indicating how many hits you need (and are remaining). This way, older clients still work by the TTL/HOPs, but newer clients could go by that GGEP packet if present. During the initial stages, where clients that do not support such GGEP extension, you won't notice much of a difference. But over time, it would.

The only drawbacks I see are these:

1) Like you noted: What if someone enters keywords that doesn't match ANYTHING. It could cause the Query to remain on the network for a very long time - so one would have to add a timestamp to the message as well (ie., kill the query at 10:31 AM GMT on 01/02/03)

2) Abuse or malfunction. Clients that purposedly or accidentally do not lower the value (or change the above timestamp), in order to overflow the network with useless messages. Although, this is the same for clients that rely on TTL/HOPs at the moment - one could simply reset that number back, and the message lives on longer than usual...

Otherwise, it could be a benefit for not only those looking for rare files, but common files. Perhaps someone wants a maximum of 1000 hits - sometimes you can get well over that amount of hits on Gnutella, especially if the keyword is too generic. It could thus reduce the number of messages on the network, provided all clients behave properly.

I tried to find your previous suggestion but you've posted so many replies I didn't waste the time.

1) Terminating queries is what the TTL is for. But also I pointed out that the HTR (if that is what it would be called) would eventually be rounded down to zero after so many divisions.

2) I'm not sure exactly what to do about abuse, the purpose of putting the idea on a forum is for other people to do the hard thinking work for me

3) Reading your post has given me another thought. Older clients that ignore this new field would not change it (or maybe even lose it), thereby extending the life of the query. I think it would be smart to leave in the TTL not just for compatability reasons.

Now I just need someone to convince the 'THE' people to make appropriate changes to the whole of gnutella. Should be easy enough.