Re: Neighboring woes

Andreas Strotmann wrote:
>
[Old junk from neighbors (and parents?!)]
>
>As a maintainer of a local cache, I need *total* control over the age of
>objects delivered to my users. Otherwise I will loose those users, to the
>detriment of the whole cooperative system, and (what bugs me most;-)
>through no fault of mine.
>
Yup, that's the reason the local caches haven't joined up in the de-cache
hierachy yet. ^_^ And thanks for writing this all, saved me from writing
another long email. ^_^

>Conclusions:
>
> - Neighbor caches *MUST* send last-checked information along with any
> peered objects. ICP *MUST* support this, if it doesn't do so already.
> That's the only way to guarantee locality of age-control.
>
Exactly my thoughts! We need to know how fresh this data is...

> - Objects sent by neighbors *MUST* be checked against local ttl_patterns
> to determine whether to send them on to the user or to retrieve them
> directly (neighbor) or force a refresh/IMS (parent).
>
...and if we can trust it thus. How do parents differ from neighbors in
terms of aged data?

> - Neighbors should be notified when objects received from them turn out
> to be out-of-date by checking the source (wasn't that supposed to be
> done using Mbone?). They should also be notified, if possible, if
> an object they delivered is known to have changed through a user
> reload (this is a lot harder to implement properly, I suspect).
>
Yup, the first part is a must, too.

Mata ne,

<CB>

-- 
  // <CB> aka Christian Balzer, Tannenstr. 23c, D-64342 Seeheim, Germany
\X/  CB@brewhq.swb.de | Voice: +49 6257 83036, Fax/Data: +49 6257 83037
SWB  - The Software Brewery - | Team H, Germany HQ | Anime no Otaku