Re: Transport requirements for DNS-like protocols

[Patrik Fältström <[e-mail]>]

--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