I've thought of a method to let nodes know how many files/Megabytes they can reach through their connection without the need of sending broadcast messages:

Therefor, every node keeps a list for every of its connections with two 32 bit values for every TTL from 1 to 9 indicating how many files/Megabytes it can reach through that connection at that TTL.
This, of course raises the question how the nodes get these lists. Well, they ask their neighbours.
These neighbours, upon being asked, will now do the following:
-create an empty list (like the one described above)
-Enter into every row of this list the values for their locally shared files/MBs
-Add to the row for a TTL of 2 of this list the values from the row for a TTL of 1 from their lists for every of their connections, except for the one the query came from.
-Continue with the last step until the list is finished (You've got the idea...)
-Send the list back to the querying host, which will store it.

Unfortunately, this method has (at least) two disadvantages:
-The possibility of loopings
-Two new message types have to be added to the protocol

Guido

hm brainstorming.

Okay, you want to measure size of horizon and file number. I agree, let's forget the idea of a exact measure... a rough estimated size must be enough for the advantage of nearly no extra traffic. How about this.

A descriptor "XPING" which is normally used with a TTL=1 only (goes only to direct connected hosts, no bigger broadcast). Those hosts answer with an "XPONG":
* IP, speed and files info (number and size sharing)
* unique IPs from direct connected clients TTL1 level and for each IP the summarized files (summarized number and summarized size)
* summarized files info from TTL1+TTL2 level (for example TTL2 is available for every TTL1 queried host by his own XPING/XPONG)
* summarized number of peers in TTL1+TTL2 level
* how many unique superpeers are in horizon the last hour
* list of topten superpeers in horizon (with free connect slots)

A descriptor "SUPERPONG" is automatically send with high TTL from every superpeer in hourly distance. This message contains:
* IP, speed and files info (number and size sharing)
* summarized files info from connected clients in TTL1+TTL2 level (summarized number and summarized size), see above.
* summarized number of peers in TTL1+TTL2 level, see above.
* number of direct connected servants, direct connected superpeers, free connect slots.
There is no answer to this descriptor, it is used for the XPONG statistics above.

Remarks: With the normal XPONG answers a client can estimate a horizon size when interpolating the TTL1/TTL2 values, then adding some extra % for every superpeer found. Not precise but a quick and dirty guess? XPINGS with an TTL higher 1 for statistic tools only, e.g. network analyzing tools. With the superpong answers every client can also try to connect the best superpeers automatically and so improve network topology.

hm more brainstorming.

How about using passive statistics in XPONGS/UPERPONG too? You heared about passive searching, it means sniffing Queryhits on existing gnutella traffic and use the results for own downloads. Passive searching does avoid extra traffic (and provide more hits for automatic research).
So why not using a passive technique to estimate peers in horizon? Every client can collect unique client IDs while sniffing gnutella traffic. On a XPONG it will give the
estimated peers number - together with the summarized files info from TTL1+TTL2 level (files info can not be passively scanned, only the peer IDs).

Collecting unique IDs can be implemented using a binary tree, which stores ID and a time tag from every sniffed descriptor. Every hour the tree should be maintained and reconstructed to delete old IDs (which maybe allready gone offline).

hm and more barinstorming.

How about adding also country or toplevel-domain to the "SUPERPONG" descriptor (e.g. 'us', 'au', 'fr' ... or 'aol.com', 'swipnet.se')? It could be a good idea to connect to a superpeer located in the same country or at the same ISP. Gnutella causes a very high traffic for an ISP, using a local superpeer can reduce traffic for our ISPs... and so reducing costs... and so make high bandwith internet cheaper for us consuments.

About SUPERPONG... every client can collect those messages and then:

a) calculate an estimated horizon, perhaps
b) hop within the horizon (horizon travelling for specialized horizons)
c) avoid to be double connected within the same local horizon (it must not happen that you connect two/multiple big super peers within a local horizon and create identical traffic)
d) find new super peers very fast when one drops! (important for modem users)

Well as far as I know you aren't supposed to be connected to more than one supernode, especially if you are a modem-user. And for finding supernodes I'd suggest using some kid of hostscache.

By the why - I thought the whole idea of using supernodes was having only one big horizon.

Hi John!

Looking into future it could be a good idea for high bandwith users to connect multiple superpeers (or to be a superpeer itself and connect different other superpeers, see images here).

Question: How do you find a super peer with a host cache? By getting a lot of IPs from pongs, test them all until you finally find a new superpeer? This try'n'error would take a lot of time (typically up to two minutes, similar to the Gnutella startup from old clients). The SUPERPONG will help to switch over to another/more superpeers immediately.

> I thought the whole idea of using supernodes was having only one big horizon.
I didn't get that in the context here, could you explain plz?