On Thu, Jul 19, 2001 at 03:49:52PM -0700, Todd Caine wrote:
> Thanks for the quick replies. I'm working on a creating a
> POE::Component which implements a distributed election
> algorithm, aka the "bully algorithm". The idea is to have
> multiple poe processes running the Component and all talking
> to each other. Each POE process will contain a unique
> priority level. The POE process that is running with the
> highest priority will be elected, whereas the other
> processes will just sit in an event loop always trying to
> get elected. The only way for a process to be elected is if
> all other processes with a higher priority can't respond.
> If the processes with a higher priority come back they will
> re-elect themselves and the backup will restart the election
> process. I think the interface will look something like
> this:
>
> POE::Component::Election::Bully->spawn
> ( Alias => 'bully',
> Port => 5121,
> Priority => 100,
> ElectedState => 'do_something',
> ImpeachedState => 'stop_doing_something'
maybe this should be *Event ...
> );
>
> POE::Session->create
> ( inline_states =>
> { _start => sub { $_[KERNEL]->post('bully',
> 'start_election', 'do_something') },
> _stop => sub { $_[KERNEL]->post('bully',
> 'stop_election') },
> }
> );
>
> $poe_kernel->run();
> exit 0;
>
> sub do_something {}
> sub stop_doing_something {}
>
> If anyone has any comments or suggestions for the interface
> or design, please let me know. I need to have at least a
> basic version of this module implemented here very shortly
> for a pair of data collectors that I'm working on.
if i see this right your implementing the component that elects processes.
well just let them register. an postback as argument, under which they can
be reached later (as there is a port, an open network connection would work
as well, don't know much about postback functionality and workarounds on
IKC though).
then either choose a periodic heartbeat that clients have to send or ask
for a new election on demand. just use the postback to talk to the clients.
they can even send their current priority when asked so it gets dynamic.
they should send an unregister event that will cause the postback to be
deleted. so an id might be useful as well (that is given to the clients by
the component, as you cannot really identify the postback without keeping
extra copies of session references i guess).
Torvald
