The ICP client side filter add support for the Internet Cache Protocol to the Jigsaw HTTP client side implementation. This support can be used both by browsers (such as HotJava, check the FAQ), or by proxies (the typical case).
In brief, ICP allows several proxies to cooperate by exchanging informations about what they currently have in their local cache. Jigsaw's ICP implementation should be compatible with other ICP capable proxies (such as Squid), even though it doesn't make use of all the features of the underlying protocol (in fact, it implements what can be implemented while still remaining compliant with the HTTP/1.1 protocol specification).
Warning: Jigsaw doesn't come with the appropriate support for editing the ICP filter properties from the /Admin/Properties resource; this means that you will have to manually edit your Jigsaw configuration file in order to set the properties relevant to that filter. This file is usually named config/http-server.props if not, you probably know already what we are talking about.
This filter uses a configuration file, to know about the proxies it cooperates with. The syntax for this rule file is defined by the following BNF:
rule-file := *(rules) rules := (comment|host-description) comment := '#' <chars up EOL> host-description := host SPACES port spaces url EOL host := <valid Internet host name> port := <valid UDP port number> url := <URL locating the proxy to use for that host/port> SPACES := *(' '|'\t') EOL := '\r' | '\r\n' | '\n'
A sample ICP configuration file looks like:
# Sample ICP configuration file # ----------------------------- # First neighbour: icp.host1.com 10345 http://icp.host1.com:8080/ # Second neighbour: icp.host2.com 10345 http://icp.host2.com:8080/
After parsing such a configuration file, the ICP filter, will register both hosts as neighbours. When a request comes in for some document, the filter sends a UDP packet to both hosts (it knows about their namee, and the port they are listening on through the first two fields of the configuration file). It then waits for some positive answer, if such an answer arrives, it finally looks it up (matching the UDP sender address with one of the above declared hosts), and use the appropriate URL as a proxy address.
To setup a nice cache hierarchy, one can use a conjunction of the ProxyDispatcher filter, the CacheFilter and the ICP filter. The starting point for setting up such a config, is to set the HttpManager filters property to:
org.w3c.www.protocol.http.filters=org.w3c.www.protocol.http.proxy.ProxyDispatcher \ |org.w3c.www.protocol.http.cache.CacheFilter \ |org.w3c.www.protocol.http.icp.ICPFilter
(the \ character indicates that the line is splitted for best reading, they should not appear in the property value - which should be written as a single line). Note that in this setting the order in which you declare the filters is indeed important.
The ICPFilter defines the following properties:
org.w3c.www.protocol.http.icp.debug
org.w3c.www.protocol.http.icp.config
org.w3c.www.protocol.http.icp.port
org.w3c.www.protocol.http.icp.timeout
org.w3c.www.protocol.http.icp.disable-cache
Jigsaw Team
$Id: org.w3c.www.protocol.http.icp.ICPFilter.html,v 1.7 2000/03/15 12:49:15 bmahe Exp $