BranchCache and Content Updates

One of the issues in any caching scheme involves data volatility. When data can change, there is a risk of caches becoming outdated. We’ve seen the potential ramifications of this in technologies from browser caching to DNS caching. BranchCache, the branch-office capability whereby data from central servers is cached on branch-office machines, avoids the problem of clients receiving stale data from cache by enforcing a check with the original content server. That original server (say, a Server 2008 R2 box running at corporate headquarters) creates cryptographic hashes of 64KB content chunks. Those hashes are returned to the requesting client at the branch office. Now, the requesting client – assuming it’s running Windows 7, and assuming that one or more BranchCache hosts has been set up at the branch office – will next query the local branch (e.g. a Server 2008 R2 box running BranchCache) to see if it has a copy of the desired content. If it does, great, but the client doesn’t just accept that because the first content chunk matches the stored hash, the entire file is current. Each retrieved chunk of content must match the stored hashes received from the original content server. If any one of them fails to match up, then the client looks for another caching server. If that also fails, then the client gets the content from the origin server at corporate headquarters, and subsequently advertises the content to the local branch server, which then caches the new content. With this scheme, retrieving a stale file in BranchCache should be pretty close to impossible, and clients can be confident they aren’t getting any outdated information. Makes sense to me!