We have patches available for squid-1.2b23 and squid-2.0P2, they can be
found at
SMART NEIGHBOUR
---------------
The 'Smart Neighbour' (or 'Central Squid Server' - CSS) is a cut-down
version of Squid without HTTP or object caching functionality. The
CSS deals only with ICP messages. Instead of caching objects, the CSS
records the availability of objects in each of its neighbour caches.
Caches that have smart neighbours update each smart neighbour with the
status of their cache by sending ICP_STORE_NOTIFY/ICP_RELEASE_NOTIFY
messages upon storing/releasing an object from their cache. The CSS
maintains an up to date 'object map' recording the availability of
objects in its neighbouring caches.
A cache that peers with smart neighbours must be prepared to allow
world access to its cache for queries forwarded from its smart
neighbours. The CSS does not currently know about access control
lists. It expects each of its neighbours to cooperate with each
other.
An example of how a smart neighbour works. In this example, Cache A
and Cache B are two non peering squids. The process of sending an ICP
query through a smart neighbour proceeds as follows:
When an ICP_QUERY is received by the CSS from a neighbouring cache
(Cache A), the CSS looks up the requested object in its object map.
If there are no known instances of this object in neighbouring caches,
the CSS will respond with an ICP_MISS. Assuming however, that an
ICP_STORE_NOTIFY was previously received by the CSS from Cache B, the
request is forwarded to Cache B which has cached the object. The SHID
field of the ICP query should contain the address of Cache A.
Cache B receives the forwarded query and extracts the original
querying cache from the SHID field. If Cache B has cached the object,
it then sends an ICP_HIT message to the original querying cache (Cache
A). If Cache B does not have the object, it responds with an ICP_MISS
to the smart neighbour, and the smart neighbour will relay the
ICP_MISS to the originator of the query (found in the SHID field).
If Cache B responded with a ICP_HIT, it then adds to its access list
an element which will allow Cache A to retrieve the requested object.
ie Cache B will treat Cache A as a 'temporary peer'. Cache A will be
allowed access to this object for a specified period (currently 2
seconds) after the ICP_HIT message is sent.
MORE INFO CAN BE FOUND IN THE ABOUT FILES AT
------------------------------------------------------------------
Stephen Baxter SE Network Access/Big Networks Australia
phone : +61 8 8221 5221 222 Grote Street
fax : +61 8 8221 5220 Adelaide 5000, Australia
Received on Mon Nov 02 1998 - 14:36:31 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:42:56 MST