default Squid and Harvest use a two-second timeout.  If object
   retrieval has not commenced when the timeout occurs, a source is
   selected as described in section 5.3.9 below.




 
RFC 2187                          ICP                     September 1997


5.2.  Receiving ICP Queries and Sending Replies

   When an ICP_OP_QUERY message is received, the cache examines it and
   decides which reply message is to be sent.  It will send one of the
   following reply opcodes, tested for use in the order listed:

5.2.1.  ICP_OP_ERR

   The URL is extracted from the payload and parsed.  If parsing fails,
   an ICP_OP_ERR message is returned.

5.2.2.  ICP_OP_DENIED

   The access controls are checked.  If the peer is not allowed to make
   this request, ICP_OP_DENIED is returned.  Squid counts the number of
   ICP_OP_DENIED messages sent to each peer.  If more than 95% of more
   than 100 replies have been denied, then no reply is sent at all.
   This prevents misconfigured caches from endlessly sending unnecessary
   ICP messages back and forth.

5.2.3.  ICP_OP_HIT

   If the cache reaches this point without already matching one of the
   previous  opcodes, it means the request is allowed and we must
   determine if it will be HIT or MISS, so we check if the URL exists in
   the local cache.  If so, and if the cached entry is fresh for at
   least the next 30 seconds, we can return an ICP_OP_HIT message.  The
   stale/fresh determination uses the local refresh (or TTL) rules.

   Note that a race condition exists for ICP_OP_HIT replies to sibling
   peers.  The ICP_OP_HIT means that a subsequent HTTP request for the
   named URL would result in a cache hit.  We assume that the HTTP
   request will come very quickly after the ICP_OP_HIT.  However, there
   is a slight chance that the object might be purged from this cache
   before the HTTP request is received.  If this happens, and the
   replying peer has applied Squid's `miss_access' configuration then
   the user will receive a very confusing access denied message.

5.2.3.1.  ICP_OP_HIT_OBJ

   Before returning the ICP_OP_HIT message, we see if we can send an
   ICP_OP_HIT_OBJ message instead.  We can use ICP_OP_HIT_OBJ if:

   o    The ICP_OP_QUERY message had the ICP_FLAG_HIT_OBJ flag set.








 
RFC 2187                          ICP                     September 1997


   o    The entire object (plus URL) will fit in an ICP message.  The
        maximum ICP message size is 16 Kbytes, but an application may
        choose to set a smaller maximum value for ICP_OP_HIT_OBJ
        replies.

   Normally ICP replies are sent immediately after the query is
   received, but the ICP_OP_HIT_OBJ message cannot be sent until the
   object data is available to copy into the reply message.  For Squid
   and Harvest this means the object must be "swapped in" from disk if
   it is not already in memory.  Therefore, on average, an
   ICP_OP_HIT_OBJ reply will have higher latency than ICP_OP_HIT.

5.2.4.  ICP_OP_MISS_NOFETCH

   At this point we have a cache miss.  ICP has two types of miss
   replies.  If the cache does not want the peer to request the object
   from it, it sends an ICP_OP_MISS_NOFETCH message.

5.2.5.  ICP_OP_MISS

   Finally, an ICP_OP_MISS reply is returned as the default.  If the
   replying cache is a parent of the querying cache, the ICP_OP_MISS
   indicates an invitation to fetch the URL through the replying cache.

5.3.  Receiving ICP Replies

   Some ICP replies will be ignored; specifically, when any of the
   following are true:

   o    The reply message originated from an unknown peer.

   o    The object named by the URL does not exist.