On Wed, Mar 12, 2014 at 1:27 AM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > On 02/14/2014 04:38 AM, Nikolai Gorchilov wrote: >> On Fri, Feb 14, 2014 at 7:22 AM, Alex Rousskov wrote: <snip> >>> Would using ICP reqnum field as a cache key or adding StoreID to >>> ICP/HTCP requests work for your use cases? I have not fully checked >>> whether the former is possible, but I think it is. The latter is >>> possible, but is more difficult to implement (and will bump into UDP >>> packet size limits more often?). > >> Yep. Both will do. I personally prefer the second option - StoreID URL >> normalization on incoming ICP/HTCP request, in order to avoid packet >> size bumps as much as possible. > > 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? > 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. Best, Niki
