Inswitch Solutions - Erlang Evaluation
Wed May 19 14:03:37 CEST 2004
I have used "pg2" module, I think it has the same concepts as "group"
In my case I have node1 (source) and node2,node3... nodeN (destinations).
- node2, node3 and nodeN with FSM apps.. Each app. when started executes
pg2:create(myGroup) and pg2:join(myGroup, self()).
- node1 knows about the available destinations by pg2:get_members(myGroup).
- I can add/remove destinations dinamically (load balancing)
- I don't need configuration info for destinations nodes in source nodes and
viceversa (no dependence)
- Monitorying for available destinations is already implemented. Mainly for
destinations nodes in different machines.
- Easy to use
- Don't know yet.
Please, correct me if I'm wrong.
----- Original Message -----
From: "Ulf Wiger (AL/EAB)" <>
Sent: Wednesday, May 19, 2004 7:27 AM
Subject: RE: Erlang distribution
> Regarding avoidance of global operations,
> you should take a look at global_group.
> "The global group function makes it possible to group the nodes in a
system into partitions, each partition having its own global name space,
refer to global(3). These partitions are called global groups.
> The main advantage of dividing systems to global groups is that the
background load decreases while the number of nodes to be updated is reduced
when manipulating globally registered names."
> Not sure if anyone has ever used it. I'd be interested
> in hearing feedback on it, if there is such.
> > -----Original Message-----
> > From:
> > [mailto:]On Behalf Of Joe Armstrong
> > Sent: den 19 maj 2004 11:30
> > To:
> > Subject: Erlang distribution
> > Hi,
> > I'm trying to change how distributed Erlang works.
> > Currently, all nodes in a distributed Erlang system know about all
> > other nodes. So for example, if node A knows about B and A knows
> > about C then B implicitly knows about C. This does not scale to
> > systems of millions of nodes
> > What I'd like is the following:
> > A should be able to do things on B (spawn processes, etc. )
> > and A should be able to do things on C
> > I don't want any knowldege of B to leak out to C. I'd also like to
> > handle multiple cookies etc. ie the coookies needed to authenticate A
> > against B whould be different from the cookies neede to authenticate A
> > against C.
> > I also don't want any form of global operations on all nodes in
> > cluster.
> > - has anybody done any work in this direction?
> > - is what I want possible without perfoming major
> > surgery to
> > net_kernel.erl?
> > Cheers
> > /Joe
More information about the erlang-questions