On Thu, Mar 13, 2014 at 5:44 PM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > 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). I can't think of a reliable checksum algorithm that can fit in 31 bits :) This means some form of db-based storeid-to-url mapping, that has to be shared between cache peers. It adds too much complexity and reduced reliability in the helpers... Using MD5 as StoreID can do the job, but this is option 2. >>> 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. To sum it ip, the above list ordered by preference: Option 3 with StoreID helper and StoreID caching Option 2 (using MD5 to minimize the packet size) Option 3 with StoreID helper, but without StoreID caching Option 1
