On 03/13/2014 07:24 AM, Nikolai Gorchilov wrote: > On Wed, Mar 12, 2014 at 1:27 AM, Alex Rousskov wrote: >> Just to make sure we are on the same page, here is a list of options I >> recall being discussed: >> >> 1. Using ICP reqnum field as a cache key. > I don't understand how this option is going to work. AFAIK regnum > is just 4 octets long - how is it supposed to accommodate the StoreID? By using StoreIDs that are 31 bits long. Recall that you control the StoreID map and, in most cases, there are fewer than 2^31 mapped/altered URLs in the cache, so one could use "positive reqnums" as regular reqnums and "negative reqnums" as "this is my special StoreID" reqnums. There are other caveats or optimizations that may make sense with this scheme. And, as I said earlier, this is a hack (that may work well in some environments). >> 2. Adding StoreID to ICP/HTCP requests as an optional field. >> 3. Computing StoreID upon receiving a regular ICP/HTCP request. >> >> Out of those three, do you prefer #3? Note that #1 is a little hackish, >> but may be a easier to implement (and is a lot cheaper CPU-wise) than >> #3. Neither #1 nor #3 make the ICP packets bigger, unlike #2. > > Option 3 is the only universal solution that works in all scenarios. > Sharing the a StoreID string or a derivative of it > (checksum/hash/digest/whatever) will do only for peers using same > StoreID rewriting logic. Yes, of course. And with a StoreID cache or, in the worst case, a loaded module computing Store IDs, it will be fast enough too. Cheers, Alex.
