Known Hub Cache and Hub Cluster Cache: Difference between revisions
No edit summary |
mNo edit summary |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
[[Basic Network Maintenance|<< Basic Network Maintenance]] | [[Node Route Cache and Addressed Packet Forwarding|Node Route Cache and Addressed Packet Forwarding >>]] | [[Main_Page|Main Page]] | |||
== Introduction == | == Introduction == | ||
| Line 32: | Line 34: | ||
== The Hub Cluster Cache == | == The Hub Cluster Cache == | ||
The hub cluster cache is used to maintain an up to date list of neighbouring hubs, | 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 | 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 | 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 | 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. | 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 | The hub cluster cache is used by a hub when responding to a keyed remote query | ||
Latest revision as of 18:35, 5 April 2005
<< Basic Network Maintenance | Node Route Cache and Addressed Packet Forwarding >> | Main Page
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.