To further reduce this possibility, the acknowledgement includes the hash of the requested blob. Other servers only suppress their responses when they see a correct hash for that blob. Attackers can only pro duce acknowledgements for blobs whose content they know All three methods are bandwidth inefficient, but the alternative is that all the storage servers need to communicate with each other to decide who is to send back the blob. This adds protocol complexity, but more importantly requires the setting up and management of trust relationships between servers. This would require either some central authority that would then become a very valuable target, or a huge amount of work by each server administrator.
Clients also act as servers.
They cache any blobs they retrieve for a short length of time, and during that period will act as a server to any other client that requests the blob. To unpublish a blob, an attacker must therefore remove it from the cache of every client that has accessed it recently as well as all the servers that hold it. To encourage a better distribution of different blobs throughout all client caches, clients monitor the blobs supplied by other servers, and add those blobs to a deletion list. If a blob is already on the deletion list, it is moved up one position on t he list. When a client needs to reduce the size of its cache, it removes a random selection of files on the list before deleting other least recently used blobs in the cache.