Known Hub Cache and Hub Cluster Cache

Introduction

Each Gnutella2 node must maintain a non-exhaustive cache of known hubs at the global level, and an exhaustive cache of hubs within the neighbouring hub cluster(s).

The Known Hub Cache

The known hub list is used to provide connection hints to the local connection manager, and other nodes which connect permanently or transiently. The most recent portion of it is exchanged with neighbours regularly.

It is also used when executing a query on the network, which involves iteratively contacting hubs representing each hub cluster and simultaneously recording the hubs which have been accounted for and adding those newly discovered.

The known hub cache should be highly efficient, addressable by node address and timestamp, and sorted by the last seen timestamp of each hub record. Adding fresh hubs should push the oldest hubs from the bottom of the cache.

It is suggested that each cached hub entry store:

• Node address
• Last seen time
• Query key, if available
• GUID, if available
• Vendor information, if desired and available
• Throttling timing for last query key request, last query, etc

Hubs whose last seen timestamp is too old should be removed from the cache, and should certainly never be sent to other nodes.

The Hub Cluster Cache

The hub cluster cache is used to maintain an up to date list of neighbouring hubs, and the neighbouring hubs of neighbouring hubs. Thinking in terms of hops, it is an exhaustive list of every hub which is 1 or 2 hops away from the local node (be the local node a hub or a leaf). The cluster cache is really only important when operating in hub mode, however it can be maintained in leaf mode for informational purposes.

The hub cluster cache is used by a hub when responding to a keyed remote query request, in the generation of a query acknowledgement packet (/QA). The /QA packet contains a list of neighbouring hubs and a selection of second degree neighbours.

The cluster cache is updated using information from /LNI and /KHL packets.