perfsonar development work

[ulisses <>]

Hi Vedrin

On 2006-09-07 21:02:52, Vedrin Jeliazkov wrote:
[...]
> Well, this looks like a better formulated superset of what I've proposed and
> I'm happy with it. You're augmenting the TTL-related functionalities with 
> TTL
> negotiation capability (between services). While such capability would be
> handy to have, we should also keep in mind that it's even more complicated
> (and perhaps expensive in terms of developer's time needed for
> implementation), than what I proposed initially.
> 
> I'm not opposing the idea, but rather wondering why would we need such TTL
> negotiation, while considering that the DNS world does fine without it. 
> What's
> the difference making such capability desirable in our case? Is it the 
> absence
> of hierarchy or something else?

I don't think it's that difficult it's only two values inserted in two 
messages

The client/service that is registering will have to obey what the LS said.
The client/service only suggests a value.

In any case please take into account that is the way I propose to implement 
for
the notifications in the toplogy service, and I don't want to mean that is the
proper way to do it for the Lookup service. 

At the begining I asked if there was such capability in the Lookup service, 
just
in case I should follow you as example to follow.

> > This does have some ramifications on multi-LS so I'm curious what Jason 
> > and 
> > Martin think about it.
> 
> TTL negotiation + multi-LS could require a very talkative protocol, which
> might also experience synchronisation/convergence problems. Again, I might 
> be
> missing something. 

yes, multi-LS is totally different is a very different issue to my problem:

        - multi-LS seems a distributed architecture.
        - client ntification of modifications on a single tops server is a 
          client-server architecture.

        Ulisses