Re: Transport requirements for DNS-like protocols

[John C Klensin <[e-mail]>]

Exactly.
    john


--On Friday, 28 June, 2002 16:30 +0200 Patrik Fältström
<[e-mail]> wrote:

> --On 2002-06-28 09.29 -0400 John C Klensin <[e-mail]>
> wrote:
> 
>> If one can keep the operations sufficiently simple
>> (e.g., no profiles and few or none of the constraints you are
>> concerned about), there are very significant advantages to
>> server-side operations, particularly to interoperability,
>> getting things right, and being able to do upgrades/ changes
>> in a rational way.
> 
> Agreed. And, another reason why one want to do more
> calculations on the server side is because differentiation
> between services. I.e. if we look at systems which does not
> work like the DNS (where koherence is extremely important, and
> together with caching create a very very special constrain),
> we can allow different servers to do different things. Some
> servers should be able to be "better" for chemistry than
> others.
> 
> So, I would like to see something where both server and client
> side can do good things, because at the end the user using the
> client want to have "correct" results back.
> 
> My point with saving CPU in the server is just because too
> many don't think about the fact that a server can not spend
> more time on a query than the time between queries. Yes, via
> parallell threads in the server this is possible, but only to
> a certain degree. The server need to at least get rid of
> responses in the same speed new queries are coming in.
> 
> Now, this create problem if we mix "large data sets" with
> "many queries".
> 
> We make the problem easier to solve if we have the ability to
> inside the protocol do things which DNS can not handle:
> 
>  - Split one dataset on more than one server, so the dataset
> can    always be arbitrary small (a zone in DNS is a zone...is
> a zone)
> 
>  - Split the query load on more than one server, so the query
>    load can be shared (which imply that the server should not
>    keep state -- if at all possible)
> 
> With simple things like this, we will get much easier
> operations than what we have today in many protocols (DHCP,
> DNS etc).
> 
>    paf
> 
> 
>