Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!apple!well!rbp
From: rbp@well.sf.ca.us (Bob Pasker)
Newsgroups: comp.databases
Subject: Re: data base client/server communications
Message-ID: <16089@well.sf.ca.us>
Date: 10 Feb 90 23:15:16 GMT
References: <2097@lamont.ldgo.columbia.edu>
Distribution: na
Organization: Bob Pasker, Software & Communications Consultant
Lines: 47

paulf@lamont.ldgo.columbia.edu (paul friberg) writes:

>One issue that still bothers me is the creation of intermediary
>communications servers:
> 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? Can't that be implemented straight up through a library just 
>the same?  I personally feel that efficiency should rule on the 
>side of performance.

The other reason to use a separarte process is so that many users can
share the same com server-type process. the com server type process
can perform many efficiencies that would be difficult to do if it existed
in each db process.

	- session sharing (multiplexing) - many fe/be connections
	(associations) from node A to node B can use a single virtual
	circuit. This, in turn, allows concatenation of messages
	across connections for larger transfers when appropriate.

	- single point of analysis - if you wanted some kind of dynamic
	instrumentation of all the sessions, you would have to interrogate
	each of the db processes, with a single comserver server you just
	interrogate a single process.  E.G. If you wanted a list of all
	the associations, you'd have to interrogate each process, compile
	a list and then print them out.

	- single point of control - same idea as previous example, but for
	starting/shutting, enabling/disabling & changing other parameters.

	- communications prioritization -a single com server can manipulate
	the priorities/resources used by each connection independent of
	the db process.

	- information sharing - a single process would have information
	about things like address mapping, condition of the lines, etc.
	and would be able to change these things without less worry about
	multi-process synchronization & locking.

More will come to mind...

-- 
- bob
;-----------------------------------------------------------------
; Bob Pasker, San Francisco, CA	 	| rbp@well.sf.ca.us
; +1 415-695-8741			| {apple|pacbell}!well!rbp