As far as I do understand gnutella, that would not be exactly a good idea, for it causes a lot of unwanted traffic giving you probably about 90% of the time the same results. It'd be also taking away incoming connections slots which the network is currently short of.

Hi, can you describe you conclusion more detailed please? Sorry, I currently do not see the connection between horizon travelling and increased traffic?

As I see it, the problem is you don't know how those far hosts which are maybe 7 hops away from you, are connected to the rest of the network. They might not know other hosts than you do and they will forward your request to the hosts within their reach.

If you wanted to be sure to reach any new hosts, you would have to try more than one host and your horizon and it could as well be that your search-request reaches the same part of the network multiple times, causing additional traffic each time. If this was common place, the amount of search-requests could easily multiply, without necessarily improving the result of the searches to the same extend. This could be very ineffective.

I think supernodes are currently the best solution to increase your network horizon. But I'm no expert. Maybe one of the developers knows it better than me.

hehe, what you describe is multi-horizon-flooding.

Let's brainstorm: I don't think horizon travelling _must_ be unhealthy, it could be. See it like a sheep: once every grass stem on the meadow is eaten, it does walk to the next meadow nearby. A sheep does not constantly hop and run around like a crazy sheep and eat every stem it could get on the whole wide world. *grin-imaginating-a-crazy-sheep*

Modern gnutella client do allready generate automatic researchs (for resuming files e.g.), together with a highly recommended query cache this is nothing unhealthy. Going into far future (assuming query caches are present in every servant/superpeer - important!):

Horizon traveller could use hostcaches to find a brand new horizon (best thing) - or just creep along horizons by quering neighbour IPs with an TTL=1 IP time by time (not that good idea maybe, I guess horizon border hops are better, but how to achieve that?)... until they find new "rich medows". If automatic search queries are within limits, there is no significant higher traffic IMHO.
As a counterthesis: By dynamic restructuring of horizons with more specialized content, there will be a more efficient traffic, because searchqueries does only reach interested hosts not various hosts (seeing gnutella network at whole = multiple horizons).
So far my theory, maybe I'm wrong, that's what I ment with "sounds interesting". Propably the idea of 'specialized gnutella horizons' (described on top of this thread) looks like a more promising approach for horizon travelling. It does include a automatic horizon travelling, because connected hosts drop time by time and must be refreshed. However a seldom horizon travelling or parallel travelling on purpose must not be unhealthy: gimme music in one specialized horizon and this outer space cookie recipes in another specialized horizon.

Greets, Moak

PS: A possible attempt to enable inside 'horizon border travelling' (far future) could be to add another Descriptor 'SuperpeerInfo': A super peer sends this message e.g. once an hour to all hosts in the horizon (high TTL) and tells that he is available and how big he is (how many servants connected). Every client can collect those messages and then:

a) hop within the horizon
b) avoid to be double connected within the same local horizon (it must not happen that you connect two big super peers within a local horizon and create identical traffic)
c) find new super peers very fast when one drops! (important for modem users)

Hmm, completely nuts what I'm saying?

What I was thinking of wouldn't stress the network at all. All you need do is keep track of the following.

1) which connection search results come from
2) which peers you know about from this same connection

It wouldn't make any new activity, just watch what normally goes on, and when it comes time to make a new connection try IPs from the connection that returned the most search results first (instead of picking a random IP from the host cache as it does now).

Superpeers are find once everything supports them, but until then the horizon will always be limited. Even with them it's possible all SP's won't be able to see each-other or SP clients won't have enough memory to hold all the search results (which could get *really* big).

It would be much better if people looking for similar files tended to drift towards one another. Common files are easy to find, but it's getting nearly impossible to find anything only a few peers are sharing.

P.S. Actually, after thinking about it, even better and simpler approach would be to keep and try connecting first to IPs from the search results themselves (if non firewalled). All you'd need do is stick search result IP in the host cache. Also hosts downloading from you might be good too (under the theroy that if they're interested in what you've got perhaps you'll find what they've got interesting).

Specialized horizon may be a good extension to Gnutella protocoll v0.6 handshaking and so increase the community idea? And it helps to decrease overall backbone bandwith, by grouping similar content and similar search traffic together.