Path: utzoo!attcan!uunet!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!eden!mao
From: mao@eden (Mike Olson)
Newsgroups: comp.databases
Subject: Re: data base client/server communications
Message-ID: <21906@pasteur.Berkeley.EDU>
Date: 8 Feb 90 20:18:51 GMT
References: <2097@lamont.ldgo.columbia.edu>
Sender: news@pasteur.Berkeley.EDU
Reply-To: mao@postgres.Berkeley.EDU (Mike Olson)
Distribution: na
Organization: University of California, Berkeley
Lines: 44

In message <2097@lamont.ldgo.columbia.edu>,
Paul Friberg (paulf@lamont.ldgo.columbia.edu) writes

> One issue that still bothers me is the creation of intermediary
> communications servers:
>
> Jon Krueger (jkrueger@dtic.dla.mil writes:
>> Need to?  If one has separation mechanisms one is wise to use them.
>> We don't need to run software at all, or have online databases.  If
>> we choose to, and also aim at reliable systems and correct data, why
>> refuse to use available mechanisms?  Plus, anyone who is serious about
>> security needs to prevent direct access to data of any sort.
>
> why use a separtion mechanism if you are going to give up performance?
> Why not use a library for the network code? What does security have to
> do with a separation mechansim any way?

i expect you could argue that separate processes get some security benefits
from the kernel in that they don't share an address space.  as a practical
matter, i don't personally know of any vendors who implement comm protocol
servers for security reasons.

one reason that it does happen is for sharing.  arbitrarily many client
processes can open up connections to a single comm server process; they
don't all need to link identical versions of the library.  the comm server
talks over the net to its counterpart, which talks directly to the database
server.

with shared libraries, this is becoming a less compelling reason for the
design, but there are still lots of systems that don't support shared libs.

performance is sort of a funny metric; it's not always the case that a
design that appears slow really will be.  using a comm server is going to
involve at least one extra copy of data coming back from the database server,
but then, a library might, as well.  if you can shovel data over sockets (or
whatever they're called on other systems) fast enough, the server may not be
all that expensive.  in any case, the bottleneck almost always appears on the
wire, and not in the machine at either end of it.  in that respect, delays
imposed by using a separate process for communications are going to get lost
in the noise.
					mike olson
					postgres research group
					uc berkeley
					mao@postgres.Berkeley.EDU