Each iteration of the wg-Humming- bird loop parses the next sequential event from the log and attempts to read the URL from Hummingbird. If successful, it explicitly releases the file buffer. If the read attempt fails, it attempts to write the URL into the file system; this would have occurred after the proxy fetched the URL from the server.
The wg-Hummingbird maintains a hash table keyed by client IP address to store information for generating the collocate hints. The values in the hash table are the URLs of the most recent HTML file request seen from a particular client. The hash table only stores the URLs of static HTML files. As requests for non-HTML documents are processed, wg-Hummingbird generates collocate_files() calls for the non-HTML paired with its client's current HTML file, as stored in the hash table.
Note that Squid (and wg-Squid) do not provide explicit locality hints to the underlying operating system; they only place files in the directory hierarchy. This is in contrast with wg- Hummingbird, which provides explicit locality hints via the colocate_files() call. There are other ways which a proxy could use UFS to obtain file locality; we did not test against these other approaches. Thus, our comparisons are restricted to the Squid approach for file locality.