Re: [Vrs-development] Cluster Management Message (was CVS)

[Chris Smith]

On Monday 18 February 2002 16:15, Bill Lance wrote:
> --- Chris Smith <address@hidden> wrote:
> > I quite like this idea - though I'm not sure how
> > well it really does fit into
> > the architecture... I'll do some more work on this.
>
> I'm not clear about the nature of the doman problem,
> no doubt due to ignorance of Goldwater. In a VRS
> Cluster, I had thought it was simply a matter of
> maitaining a list of active node IP's in the Cluster
> Image.  What am I missing?

Nothing.  Goldwater apps are a set of inter calling services.
However, these services do not have to exist within the local Goldwater 
application, they can be in other 'Domains'.  
So my thinking went along the lines of:
Applications built on Goldwater may communicate with each other natively 
using Domains.  The VRS will be built on top of Goldwater, and therefore 
'could' use Goldwater Domains for inter-LDS communication.

The layering between Goldwater Domain support and LDS->LDS support may blur 
too much for this to work.  If the abstraction is clean and eligent, then we 
might as well use what Goldwater offers (even if I'm practically writing it 
from scratch again....)

> > This does mean resurrecting Phoenix (no pun
> > intended!) for the network comms
> > (far more efficient than something like Apache) -
> > but we did say that we'd
> > like to use a tight binary format, which precludes
> > using port 80 anyway.
>
> I presume you are talking about cluster management
> traffic, and not net services traffic.  Perhaps
> Phoenix is the core of the Network Port Manager.

Yep cluster traffic.
If we're not sending 'cluster' traffic over HTTP, then we need some sort of 
network server.  Phoenix is a very stable, efficient, bolt on functionality 
server that already integrates into Goldwater apps (even though I've spent 
the last few weeks trying to seperate them!)

Basically you write a module containing a read_handler and event_handler that 
performs the network server functionality you require, assign a port number 
to it and get phoenix to load it on start up.  There are some rules to comply 
with when writing such a module as Phoenix is an internally multiplexed, 
thread free, fork'less server.  The configuration of it is very different to 
that employed in Goldwater - so I'd like to fix that in phoenix before 
releasing it as the (optional) network server component of Goldwater.

Domains may help a lot though - as it handles service request timeouts and 
(should) do load balancing - but I don't think we need this.......

Chris
-- 
Chris Smith
  Technical Architect - netFluid Technology Limited.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk