Re: [PATCH] xenctld - a control channel multiplexing daemon

["B.G. Bruce" <bgb@nt-nv.com>]

As I see it, we have two (or more) camps/uses for xen.  One (micro) that
is dealing primarily with a relatively small number of machines -
typically one and is concerned with speed and security of the local
machine.  The other (macro) is HPC or large enterprise/server farm type
setups that requires out of the physical box remote connectivity.  The
third camp just wants something reliable and easy to use (probably -
though they have been quiet up to this point so I'm just guessing
here).  The real question is can one tool be made to fit all, or is the
gap so large that two different tools are required.

B.



On Mon, 2005-01-24 at 15:07, Anthony Liguori wrote:
> On Mon, 2005-01-24 at 10:55, Jared Rhine wrote:
> > > > Again, this is not an issue of esthetics, it's an issue of measured 
> > > > performance. 
> > > 
> > > Where's the performance issue?
> > 
> > I think Ron was suggesting that the dual handoff of the data between the
> > UDP listener and the TCP listener would be foolish and avoidable and
> > inarguably is a measurable throughput degredation over a direct TCP
> > processing loop.
> 
> You're not going to have a direct listener though on TCP.  I think you
> mean unix domain sockets too instead of UDP.  The current message
> passing architecture assumes the messages are originating from the
> native architecture.
> 
> They do not take into account things like endianness into
> consideration.  They certainly don't security into account at all.  To
> export a proper TCP interface requires a higher level protocol.  The TCP
> interface will have to do a certain amount of work to take these things
> into account.
> 
> I think we all agree that we need a TCP interface.
> 
> The only real question is whether you export a lower level protocol
> interface via something like domain sockets.  Domain sockets are
> extremely fast on most platforms (usually reducing to something like a
> memcpy).  Considering the message size here I do not think you can make
> a performance argument for having a TCP daemon go through a domain
> socket.
> 
> If we agree that we need a higher level protocol for TCP, then it
> becomes pretty apparently that there's going to be desire for multiple
> protocols.  Maybe a less security conscious protocol for isolated
> clusters (like xcs implements right now) verses a more hardened protocol
> for enterprise usage.
> 
> Using multiple daemons here becomes a no-brainer.  You just start the
> appropriate daemon for whatever protocol you wish to export.  Properly
> architected, multi daemons could even be run simultaneously to support
> multiple sets of control tools.
> 
> > Ron, is your performance concern because large clusters need to pass a
> > very high volume of control messages?  For any low-volume situation,
> > this unix domain/TCP argument is a non-issue, mostly?
> 
> I have a feeling that the concern is that there's a general fear that
> more daemons == more resource usage == more administrative overhead.  I
> don't think this is true though.  I think it simply depends on how
> things are architected.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl