perfsonar development work

["Jeff W. Boote" <>]

ulisses wrote:
> Hi Vedrin!
>
> On 2006-09-07 01:58:55, Vedrin Jeliazkov wrote:
> [...]
>
> > Ulisses, I guess that by "client that registers the data" you actually mean a
> > service which registers its capabilities in LS, right? In my further comments
> > below I'm assuming this.
>
>
> yes, that's it.
>
>
> > > Hi!
> > >
> > > Yes, that's right. We haven't thought about it yet.
> > >
> > > [ I CC-ed the e-mail to Vedrin. ]
> > >
> > > Vedrin, what do you think: what would be the best way (from client point 
> > > of view) for determining such LS parameters as TTL:
> >
> > Maciej, if your question refers only to visualization clients (which would
> > access the LS in a read-only mode), than I see two options:
> >
> > 1) the client doesn't receive/process resource TTLs at all; instead, it
> > assumes that if the LS has returned a pointer to a certain resource, then it's
> > reasonable to consider the resource as being available (alive);
> >
> > 2) the LS provides a TTL attribute for each returned resource (or set of
> > resources) and the client is free to make its own decisions based on this info
> > (e.g. cache the resource pointer while the returned TTL has not expired,
> > consider some resource as unstable if its remaining TTL is too short, ignore
> > the TTL attribute, etc...).
>
>
> [...]
>
> to summarize:
>
> - returning the TTL from the LS means the LS can stablish the policy. eg: 
> informing
>   that the requested TTL is too large or customizing the TTL depending on the 
>   size of the storage.
>
> - specifying the TTL as a parameter to the LS will be interesting because each
>   service knows it's needs, more than the LS.
>
> I think that the simple, the best:
>
>   the registrator sets the desired value for the TTL.
>   the LS returns the effective TTL.
>
> in think I will define this way for the TOPS notifications

I agree. The service should be able to specify the TTL it wants and the LS 
should be able to impose policy on that TTL (A max relative to storage issues - 
and a min relative to how often it is willing to let services re-register). And, 
the effective TTL should be returned to the registering service somehow so it 
knows how often it should re-register.

This does have some ramifications on multi-LS so I'm curious what Jason and 
Martin think about it.

jeff