Algoritmos de Eleição

Algoritmos de Eleição
Roteiro:
•  Motivação e Principais Requisitos
•  Algoritmos em Anel
•  Algoritmo Bullying
•  Algoritmo do Convite
Referências:
•  Livro do Chow/Johnson: seção 10.2
•  Livro do Colouris/Dollimore/Kindberg: seção 11.3
•  Livro do Michel Raynal: Distributed Algorithms and Protocols,
Wiley & Sons, 1988 (seção 2.5)
•  S. Sight & A. Kurose: Electing “good” leaders, Journal of Parallel
and Distributed Computing Systems, 21: 194-201, 1994.
© Markus Endler
1
Eleição
Objetivo:
•  obter um consenso em um grupo de processos sobre a
escolha de um único processo
Aplicações:
•  Em muitos serviços (ou aplicações) distribuídos um
processo (arbitrário) exerce um papel diferenciado
(coordenador)
•  Quando este falha, o grupo precisa re-eleger um novo
coordenador
Exemplos:
•  Servidores replicados com com replicação passiva
(primary-backup)
•  Um processo sequenciador para comunicação multicast
com ordenação total (exemplo: sistema Amoeba)
© Markus Endler
2
Eleição vs. Exclusão Mútua vs. Consenso
Diferenças entre Exclusão Mútua e Eleição:
•  Na Eleição, todos os participantes precisam saber quem foi escolhido
•  A maioria dos Algoritmos de Eleição não faz suposições sobre o número
total de processos
•  Geralmente, Eleição é iniciada como reação a uma detecção de falha (p.ex.
do antigo coordenador)
•  Algoritmos de eleição precisam lidar com a possibilidade de falha durante a
escolha do novo coordenador.
•  Para o problema da eleição assume-se uma ordem total do conjunto de IDs
dos processos, e o conhecimento de um limite máximo deste conjunto
Similaridades:
•  Qualquer processo pode iniciar uma eleição (porém, não mais do que uma
eleição a cada vez), ou seja, pode haver várias execuções simultâneas do
algoritmo de eleição
•  Todos os processos precisam estar de acordo com a decisão tomada (o
novo coordenador, ou o próximo a entrar na SC)
Eleição é um problema de consenso específico (onde o valor proposto por cada
processo, vi é próprio PID)
© Markus Endler
3
Principais Requisitos
Definição:
• 
Durante uma eleição, cada processo pode estar engajado em uma
eleição (participante) ou não (não participante)
Os principais requisitos de qualquer Algoritmo de Eleição são:
• 
Safety/Segurança: deve-se garantir a unicidade do elemento
escolhido (o coordenador/lider)
• 
Liveness/Progresso: em algum momento, define-se qual será o líder/
coordenador
• 
Acurácia/Estabilidade: só fazer a releição se for realmente
necessária
© Markus Endler
4
Principais Requisitos
Considere N processos P1,..,PN, cada um com uma variável Coord,
incialmente indefinida (Coord = undef)
As condições acima são formuladas como:
Segurança: Um processo participante Pi tem Coord = undef ou Coord =
P, onde P é um processo correto (não faltoso) ao término do
algoritmo.
Liveness: Todos os processos Pi participam da eleição e em algum
momento ou tem Coord ≠ undef, ou terão falhado.
Acurácia/Estabilidade: são definidos em termos da qualidade da
detecção de falha.
Geralmente, o problema é reduzido ao de encontrar o maior/menor ID no
grupo.
© Markus Endler
5
Eleição em uma toplogia de Anel
• 
Assuma que cada processo tem um PID ∈ [1, MAX]
• 
E mensagens só circulam em um sentido
Objetivo: Achar o maior/menor PID.
Qual seria a idéia?
p8
p3
p9
•  Como detectar o término do
algoritmo (ter encontrado o
manor/maior PID) ?
•  Quantas rodadas são
necessárias?
© Markus Endler
p4
p1
6
Algoritmos baseados em Anel
Chang & Roberts (1979) propuseram um algoritmo simples para processos
interligados em uma estrutura lógica de anel (onde as mensagens só
circulam em um sentido)
O algoritmo funciona em 2 rodadas, para um número arbitrário de processos.
Ideia Central:
• 
Processo Pi inicia o algoritmo enviando uma mensagem (election, Pi.PID)
para o próximo processo P (i+1)mod N.
• 
Ao receber uma mensagem (election,ID), o processo Pj calcula max(ID,
PIDj) e manda este valor para o próximo
• 
O processo que receber o seu próprio PID é o novo coordenador.
• 
O coodenador coloca em circulação uma mensagem (elected,
coord.PID), para que todos fiquem sabendo quem é o novo coordenador
e o algoritmo termina quando esta msg retorna a ele.
O modelo de sistema:
• 
Processos não falham
• 
Comunicação é confiável e segura
• 
Sistema é assíncrono
• 
Todos os processos possuem PIDs distintos!
© Markus Endler
7
Algoritmos baseados em Anel
O algoritmo de Chang & Roberts garante a unicidade do coordenador (propr.
de segurança) porque:
• 
A mensagem election passa por todos os processos (todos são
participantes)
• 
Como todos tem PID distintos, existe um único processo com PIDmax
• 
Como a mensagem elected passa por todos os processos, todos setam o
mesmo valor para a variável Coord.
Liveness é garantida por:
• 
A função max é uma aproximação sucessiva deste PIDmax
• 
Por se tratar de um anel, e não haver perdas de mensagem, o processo
com PIDmax em algum momento receberá a mensagem com seu próprio
PID (PIDmax)
Características do Algorítmo:
• 
Simetria de papéis
• 
Vários processos podem iniciar simultaneamente o algoritmo
• 
Complexidade de mensagens por requisição 2 N.
• 
No pior caso (todos começando simultaneamente) é O(N2)
© Markus Endler
8
Algoritmos baseados em Anel
Hirschberg & Sinclair [HS80] propuseram um algoritmo com custo de
comunicação O(N log N), que:
• 
funciona em rodadas e
• 
assume um anel de tamanho N com links bi-direcionais confiáveis
Ideia Central:
• 
Iniciado a partir de um processo candidato, que a cada rodada
difunde (e compara ) o seu PID com vizinhos cada vez mais
afastados (mensagem Cand);
• 
caso um dos vizinhos perceba que possui PID maior do que o do
candidato, este inicia uma nova eleição (difundindo o seu próprio
PID)
• 
Processos com PID menores respondem ao candidato,
concordando com sua candidatura
• 
Processos intermediários:
– 
repassam mensagens, ou iniciam nova eleição (caso seu PID >
PIDCand)
[HS90] Hirschberg & Sinclair: Decentralized Extrema Finding in Circular
Configurations of Processes. Communications of the ACM, 23 (11), Nov. 1980.
© Markus Endler
9
Algoritmo de Hirschberg & Sinclair
Um pouco mais de detalhes:
Na rodada j o Pi envia a msg (Cand,Pi.ID) para os elementos distantes
2j hops dele no anel:
P(i-2j) mod N e P(i+2j) mod N
Ao receber a mensagem (Cand,ID), processo Pk compara ID com o
seu próprio identificador Pk.PID:
Se (ID > Pk.PID) então retorna ao remetente TRUE
senão retorna FALSE e passa a ser o novo candidato
Se o iniciador da difusão receber duas respostas TRUE, continua
candidato e passa à próxima rodada è incrementa j (= o alcance
da consulta)
Quando o iniciador recebe a msg Cand com o próprio PID, sabe que foi
eleito o novo coordenador e
Difunde uma mensagem Elected com o seu ID no anel.
© Markus Endler
10
O Algoritmo de Hirschberg & Sinclair
Exemplo para 7 processos: Algoritmo iniciado pelo P5
P4
P1
P3
P7
P5
P2
P0
P4
False
Os 3 tipos de mensagem:
Cand (PID, d, dmax), onde:
• 
dmax: distância máxima (# hops) a serem percorridos
• 
d: distânca (#hops) já percorridos pela mensagem
Resp (bool, P), onde:
• 
Bool = TRUE indica que P permanece candidato
• 
P indica o processo ao qual a resposta é destinada (o candidato)
Elected(sender)
© Markus Endler
11
O Algoritmo de Hirschberg & Sinclair
Cada processo pode estar em um de quatro estados:
•  not_involved = não foi consultado ainda
•  candidate = é o atual responsável pelas pesquisas (enquanto for o de
maior PID)
•  lost = recebeu msg com PID maior
•  elected = quando P descobre que ele é o de maior PID
Variáveis em cada processo:
Enum state: initialy not_involved;
// State = {candidate, not_involved, lost, elected}
Int maxhops, hops;
Int Nr_replies;
// pode ser 0,1 ou 2
Bool remain;
// TRUE = continua candidato na próxima rodada
Int winner;
// ID do processo eleito
Bool end_phase // sinal que indica que uma rodada terminou
O algoritmo é composto de um procedimento para iniciar a eleição
(Election) e uma tread (Monitor) que trata as mensagens recebidas, e
que compartilham variáveis state e end_phase
© Markus Endler
12
Procedimento de invocação da Eleição
Election() {
state = candidate;
dmax = 1;
while (state == candidate) {
Nr_replies = 0;
remain = TRUE;
send(left, Cand (self.ID, 0, dmax) );
send(right, Cand (self.ID, 0, dmax) );
wait(end_phase) => {
// espera sinal do Monitor
if (remain==FALSE) state = lost;
else dmax = dmax * 2;
// dobra a distânca
}
}
}
Obs: Assumimos que next[k] relaciona os vizinhos da
esq/direita:
•  next[left] = right
•  next[right] = left
© Markus Endler
Left=0
Right=1
Next[0] = 1
Next[1] = 0
13
A thread Monitor (1)
Loop {
received(k, Resp(bool,dest) ) =>
if (dest == self) {
Nr_replies++;
remain = remain ∧ bool;
if (Nr_replies==2) signal (end_phase);
} else send(next(k), Resp(bool,dest) )
// forward Resp
}
received(k, Cand(ID,d,dmax) )=> {
if (ID < self.ID) {
send(k, Resp(FALSE,ID) );
if (state == not_involved) Election();
// start election
} elseif (ID > self.ID) {
state = lost;
d++;
if (d < dmax) send(next(k), Cand(ID,d,dmax) ); // forward
else send(k, Resp(TRUE, ID);
// reply to candidate
} elseif (state ≠ elected) {
// ID == self.ID
state = elected;
// isto termina o while de Election()
winner = self.ID;
send(next(k), Elected(winner)); // announces in one direction
}
}
continua ...
© Markus Endler
14
A thread Monitor (2)
}
... continua
received(k, Elected(new) => {
if (winner ≠ new) {
send(next(k), Elected(new));
winner = new;
state = not_involved;
}
}
A corretude do algoritmo deriva dos seguintes fatos:
•  apenas o processo de maior ID (e.g. P.max) é capaz de receber a sua
própria msg Cand. Qualquer outro processo com ID < max terá a sua msg
Cand respondida negativamente por P.max.
•  todos os processos ao longo dos caminhos (i-2j, i+2j) irão interferir na
eleição (responder negativamente), caso tenham ID maior do que o do
candidato
© Markus Endler
15
Eleição para Grafos Completos
•  A topologia em anel é meio artificial, pois todos os processos
precisam estar ativos para repassar as mensagens...
•  Suponhamos agora que:
–  PID ∈ [1, MAX]
–  Processos podem estar ativos ou faltosos (não responder às
requisições)
–  Durante a eleição processos podem falhar, ou voltar a ficarem
ativos (mas com o mesmo PID)
Objetivo: encontrar o maior PID dentre os processos ativos
Sugestões...?
p8
p1
p9
p3
p4
© Markus Endler
p2
16
Eleição de Líder em MANETs
Leader Election Algorithms for Mobile Ad Hoc Networks
Navneet Malpani, J. Welch, N. Vaidya
We present two new leader election algorithms for mobile ad hoc networks.
The algorithms ensure that eventually each connected component of the
topology graph has exactly one leader. The algorithms are based on a routing
algorithm called TORA [5], which in turn is based on an algorithm by Gafni and
Bertsekas [3]. The algorithms require nodes to communicate with only their
current neighbors, making it well suited to the ad hoc environment. The first
algorithm is for a single topology change and is provided with a proof of
correctness. The second algorithm tolerates multiple concurrent topology
changes.
Publicado em ACM DIAL M worskhop, 2000
© Markus Endler
17
Eleição de Líder Estável
A Robust and Lightweight Stable Leader Election Service for Dynamic Systems
Nicolas Schiper, Sam Toueg
We describe the implementation and experimental evaluation of a fault-tolerant leader
election service for dynamic systems. Intuitively, distributed applications can use this
service to elect and maintain an operational leader for any group of processes which may
dynamically change. If the leader of a group crashes, is temporarily disconnected, or
voluntarily leaves the group, the service automatically re- elects a new group leader. The
current version of the service implements two recent leader election algorithms, and
users can select the one that fits their system better. Both algorithms ensure leader
stability, a desirable feature that lacks in some other algorithms, but one is more robust in
the face of extreme network disruptions, while the other is more scalable.
The leader election service is flexible and easy to use. By using a stochastic failure
detector [5] and a link quality estimator, it provides some degree of QoS control and it
adapts to changing network conditions. Our experimental evaluation indicates that it is
also highly robust and inexpensive to run in practice.
© Markus Endler
18
O Algoritmo “Bully”
Garcia-Molina[GM82] propôs um algoritmo para um sistema síncrono com
falhas tipo fail-stop, baseado na difusão de mensagens (conectividade total).
O algoritmo faz as seguintes suposições adicionais:
•  Toda mensagem é entregue em Tm unidades de tempo após o seu envio;
•  Todos os processos não falhos respondem a todas as mensagens
recebidas em Tp unidades de tempo;
•  Todos os processos têm acesso a uma memória não volátil (p.exemplo:
disco local) para persistir algumas informações.
Com as duas primeiras suposições, é possível definir um detector de falhas
confiável: se um processo não responde em 2Tm+Tp unidades de tempo,
então tem-se certeza de que o mesmo falhou.
A terceira suposição é necessária para manter o registro de versões (instâncias
da eleição) em ordem estritamente crescente.
© Markus Endler
[GM82] Garcia-Molina. Elections in a Distributed Computing System,
IEEE Trans. On Computers, C-31(2),48-59, 1982.
19
Algoritmo Bully: Princípio de Funcionamento
•  Periodicamente, o atual coordenador verifica se a configuração do
grupo mudou (um processo falhou ou se recuperou de falha) è se isso
ocorreu, inicia eleição
•  Se algum participante desconfiar da falha do Coordenador è inicia
eleição
• Dentre os processos ativos em determinado momento, aquele com o
maior PID deve ser eleito o coordenador. Este tenta convencer os
demais intimidando-os (“bullying”).
•  Antes de começar a eleição, o processo iniciador da eleição faz uma
consulta para verificar se existe algum processo com maior PID. (è A
possibilidade da detecção confiável de falhas garante que somente o
processo de maior prioridade vai tentar ser o coordenador)
© Markus Endler
20
Algoritmo Bully: Princípio de Funcionamento
A eleição funciona em 3 fases: ao final de cada fase, garante-se que
todos os processos não falhos estão sincronizados com o mesmo estado
(global) da eleição:
Normal >F1> Election >F2 > Reorganizing >F3> Normal
Significado dos estados:
•  Down = processo voltando de um período de falha
•  Election = um (ou mais candidatos) tentando se estabelecer como
Coordenador
•  Reorganizing = o estado da aplicação está sendo difundido para todos
os membros do grupo (p.exemplo a nova lista de membros ativos)
•  Normal = processamento normal (até início da próxima eleição)
© Markus Endler
21
Algoritmo Bully: Princípio de Funcionamento
Estados percorridos por todos os
processos
Down
Normal
Election
Reorganiz
...
Obs: durante os estados Election e
Reorganiz. o processamento da
aplicação fica suspenso.
Principais Variáveis em cada Processo P:
State: um valor em {Down,Election,Reorganizing,Normal}
Coord: o ID do candidato a Coordenador, segundo a visão de P
Definition: o estado relevante da aplicação
Up:
conjunto de PIDs de processos ativos no grupo
halted: ID do processo que notificou P da eleição (iniciador)
© Markus Endler
22
Segurança e Liveness
As propriedades de segurança (safety) e progresso (liveness) do algoritmo
são as seguintes:
Safety:
Seja G um estado global consistente(*). Então para quaisquer dois pares
de processos Pi e Pj as seguintes condições são satisfeitas em G:
•  Se Pi e Pj estão nos estados {Normal,Reorganizing}, então Pi.Coord =
Pj.Coord
•  Se Pi e Pj estão no estado Normal, então Pi.Definition = Pj.Definition
(estados sincronizados)
Liveness:
Seja G um estado consistente (*). Então as duas seguintes propriedades
estarão satisfeitas em algum estado global de qualquer processamento
a partir de G:
•  Existe um Pi tal que Pi.State = Normal && Pi.Coord = Pi
•  Para qualquer processo Pj não-falho, vale Pj.State = Normal &&
Pj.Coord = Pi
(*) Uma coleção de estados locais dos processos e canais de comunicação,
que de fato, poderia ter ocorrido em uma execução do sistema.
© Markus Endler
23
Detecção de Mudança no Grupo
Periodicamente:
•  Coord. verifica a existência de um processo ativo (com PID maior
ou menor do que PIDCoord )
•  Coord. verifica se todos os participante estão ativos (respondem à
mensagen AYNormal)
•  Participante verifica se seu Coord. está ativo (mensagem AYUp)
Se alguém tiver detectado qq mudança inicia-se uma nova eleição...
•  Quando um processo se recupera de uma falha, também inicia
nova eleição.
Obs: AY.. significa AreYou... e para cada tipo de mensagem existe uma
mensagem de resposta (AYNormal è AYN_answer, etc.)
A eleição consiste de 3 mensagens difundidas pelo Processo com
maior PID:
•  EnterElection (EE) // se propõe como coordenador e verifica quais
processos estão ativos
•  SetCoordinator (SC)
•  NewState
© Markus Endler
24
Monitoramento do Grupo e Situações de chamada de Election
Coord
Part A
Part B
AYNormal
ok
AYN_answer
AYUp
AYU_answer
ok
crash
Election()
AYNormal
Election()
AYN_answer
Election()
AYUp
crash
Election()
Timer T
© Markus Endler
25
Estados Globais na Execução da Eleição
P4
AYUp
P3
P2
!∃ P tq. P.ID > P3
& P.State=Normal
C1
EnterElection
SetCoord
C3
NewState
© Markus Endler
P3
∀ P tq. (P.ID < P3) :
P.Coord ≠ P
∀P P.State≠Normal
C2
C4
P1
∀P ∈ UP:
P.State=Reorg. ∧
P.Coord=P3
∀P ∈UP:
P.State=Normal ∧
P.Coord=P3
26
Procedimentos que iniciam uma Eleição
•  Qualquer processo que deixa de receber msg do coordenador
por um certo período è suspeita de sua falha
Check_Coordinator () {
if (State==Normal || State == Reorganizing) {
send (coord,AYUp);
set timer T;
}
received(coord, AYU_answer) => set timer for next check;
timeout T => Election();
}
•  Qualquer processo que esteja voltando de um
período de falha
Recovery () {
State = Down;
Election();
}
© Markus Endler
27
Coordenador verifica o estado dos demais processos
Check_members() {
if (State==Normal && Coord == self) {
forall Pj: send (j,AYNormal);
set timer T;
replied = ∅;
}
loop {
received(k, AYN_answer, status) => {
replied = replied ∪ {k};
if (k ∈ Up && status ≠ Normal) || k ∉Up) {
Election();
// detected new or candidate process
exit;
}
timeout T => { if ∃ k ( k ∈ Up && k ∉ replied ) { // some process did not reply
Election();
} exit;
}
} // endloop
}
Obs: para cada tipo de mensagem existe uma mensagem de resposta
(AYNormal - AYN_answer, etc.)
© Markus Endler
28
Procedimento Election (1)
Election() {
highest = True;
forall P with P.ID > self.ID send(P, AYUp); // look for higher-priority processes
set timer T;
received(sender, AYU_answer) => {
highest = False; return;} // abandon own candidacy
timeout T => ;
// wait only for certain amount of time
State = Election;
halted = self;
// I am the initiator and candidate
Up = ∅;
forall P s.th (P.ID < self.ID) send(P, EnterElection(halted)); // “invite” other
participants
set timer T;
loop {
received(k, EE_answer) => Up = Up ∪ {k}
timeout T => exit;
}
Coord = self;
Obs: participant= process with a lower PID
State = Reorganizing;
...
© Markus Endler
29
Procedimento Election (2)
...
num_answers = 0;
forall P ∈ Up send(P,Set_Coord, self);
// try to establish myself as Coord
Set timer T;
loop {
received(k, SC_answer) => num_answers++;
timeout T =>
if (num_answers = | Up |) exit loop;
else { Election(), return; }
// set of participants has changed
}
num_answers = 0;
forall P ∈ Up send(P,New_State, Definition) // sends appl state to other in Up
loop {
received(k, NS_answer) => num_answers++;
timeout T =>
if num_answers = | Up | exit loop;
else { Election(), return; }
// set of participants has changed
}
State = Normal
}
© Markus Endler
30
Thread Monitor
Loop {
received(k, M) => {
switch (M ) {
AYUp: send(k,AYU_answer);
AYNormal: send(k, state);
EnterElection(k): {
State = Election;
suspend_normal_application processing
if (k > self)
// defines, in which Election will participate
if election_procedure was started, stop it
halted = k;
send(k, EE_answer);
}
Set_Coord(newCoord): {
if (State==Election && halted==newCoord) {
Coord = newCoord;
State = Reorganizing;
}
send(k, SC_answer); }
NewState (NewDefinition) :
if (Coord == k && State = Reorganizing) {
Definition = newDefinition;
// updates state
State = Normal;
}
} // end switch
} // endloop
© Markus Endler
31
Algoritmo do Convite (Invitation Algorithm)
De Garcia-Molina[GM82] é também o Algoritmo do Convite, que:
•  é uma variante do Algoritmo Bully para sistemas assíncronos e
•  que trata a possibilidade de ocorrem partições na rede.
Sistemas Assíncronos:
•  Sem a suposição sobre tempos máximos de processamento e
comunicação, não é possível saber com certeza se um
processo falhou. Sabe-se apenas que a comunicação (em certo
período) não está sendo possível.
Partições:
•  Impossibilidade temporária da comunicação entre grupos de
processos
© Markus Endler
32
Algoritmo do Convite
Suposições do Modelo:
•  Comunicação é segura
•  Falhas são do tipo fail-stop
•  Nós guardam o estado em memória persistente (após se recuperar
de uma falha, conseguem recuperar o estado anterior)
•  Grupos de processos podem ficar temporariamente isolados uns
dos outros (partições na rede)
•  As mudanças de conectividade da rede ocorrem com baixa
frequencia
Características:
•  Permite que existam mais de um grupo (com seu coordenador)
isolados
•  Mas se houver alguma possibilidade de comunicação entre estes
grupos, eles irão se fundir
© Markus Endler
33
Algoritmo do Convite (Invitation Algorithm)
Ideia Central:
•  em vez de se tentar eleger um coordenador para todos os
processos, elege-se somente o coordenador para cada um dos
sub-grupos de processos cujos membros estão conseguindo
interagir
Obs: permite-se grupos unitários consistindo apenas do
candidato a coordenador!
•  Periodicamente, coordenadores de sub-grupos verificam se
existem outros coordenadores, e tentam convidar todos os
membros do sub-grupo correspondente a se juntar ao seu
grupo.
•  Para evitar que dois coordenadores fiquem se “roubando
mutuamente” membros do outro grupo, após a descoberta do
outro coordenador, este espera um tempo inversamente
proporcional à sua prioridade (valor do PID) até começar a
enviar os convites.
è Para isto, é necessário usar a noção de grupo, com um
identificador único (groupID)
© Markus Endler
34
Algoritmo do Convite
Adaptando as propriedades de segurança e progresso para o algoritmo do
convite:
Propriedade Safety:
Seja G um estado consistente. Então para quaisquer dois pares de
processos Pi e Pj as seguintes condições são satisfeitas em G:
•  Se Pi e Pj estão nos estados {Normal,Reorganizing} e Pi.Group =
Pj.Group, então Pi.Coord = Pj.Coord
•  Se Pi e Pj estão no estado Normal, e Pi.Group = Pj.Group então
Pi.Definition = Pj.Definition
A propriedade de segurança é facil de ser satisfeita, pois depende de
como é escolhido o grupo (= pode ser qualquer conjunto de processos
que concorde em adotar um mesmo coordenador).
© Markus Endler
35
Algoritmo do Convite
Propriedade Liveness:
Seja R o conjunto máximo de processos mutuamente comunicáveis em
um estado consistente G.
Então as duas seguintes propriedades serão em algum momento
satisfeitas (para qualquer processamento a partir de G), dado que o
conjunto máximo de processos mutuamente comunicáveis R
permaneça igual e não ocorram outras falhas:
•  Existe um Pi ∈ R tal que Pi.State = Normal && Pi.Coord = Pi
•  Para todos os processos Pj ∈ R não-falhos, vale Pj.State = Normal &&
Pj.Coord = Pi
© Markus Endler
36
Algoritmo do Convite (Invitation Algorithm)
Para satisfazer a propriedade de liveness, precisa-se garantir que:
•  Se membros de grupos distintos conseguem se comunicar,
então em algum momento futuro, terá sido formado um novo
grupo (com coordenador único) contendo todos os processos
mutuamente comunicáveis (ou seja, o conjunto R).
Para tal, é necessário que os coordenadores dos grupos
correspondentes concordem sobre a formação de um novo
grupo contendo todos os membros dos grupos originais e um
único coordenador.
•  Sucessivamente, grupos menores vão se aglutinando, até
formar um grupo contendo todo R.
•  Cada coordenador, periodicamente tenta descobrir outros
coordenadores e executar um Merge() nos grupos tendo como
parâmetro a lista de outros coordenadores encontrados
(Others).
© Markus Endler
37
Funcionamento Básico
•  Periodicamente, um coordenador difunde um AYCoord? tentando
contactar outros coordenadores, armazena o ID destes na variável
Other e tenta juntar os grupos (procedimento Merge(Other))
através de mensagens Invitation.
•  Ao receber uma Invitation de outro coordenador (digamos, NC),
um coordenador C repassa esta mesagem para os participantes
de seu grupo, que respondem diretamente ao NC usando msg
Accept. O próprio C também envia Accept para NC.
•  O NC por sua vez confirma o seu papel de novo coordenador
através de Accept_answer. Se esta mensagem não chegar a
tempo, qualquer processo pode executar recovery();
•  A seguir, NC envia a mensagem Ready com seu estado Definition
para todos os processos da união dos grupos originais.
Principais variáveis em cada processo:
State
UpSet
Up
Group
Others
© Markus Endler
// {Normal, Election, Reorganizing}
// conjunto dos membros do próprio grupo
// conjunto dos membros da união dos grupos
// identificação do grupo, através do par (CoordID, count])
// conjunto de outros coordenadores descobertos
38
Execução da Eleição
Merge(P2)
P4
Invitation P4
P3
P2
Accept
Accept_answer
P1
Invitation P4
Accept
Accept_answer
Up
Ready
Ready_answer
Grupo A
© Markus Endler
Grupo B
39
Coordenador procura por outros coordenadores
Periodicamente, cada coordenador verifica se consegue se comunicar com
outro coordenador (e coleta na variável Others os PIDs correspondentes)
Check_members() {
if (State==Normal && Coord == self) {
Others = ∅;
forall Pj send (j,AYCoord);
set timer T;
}
loop {
received(k, AYC_answer, is_Coord) => {
if( is_Coord == TRUE) Others = Others ∪ {k};
}
timeout T => if Others == ∅ return;
// no group to merge
else exit;
}
} // endloop
set timer 1/self.Priority;
// higher-priority coordinator merges first
timeout => Merge(Others);
}
Obs: Se um participante de outro grupo receber msg AYCoord, informa a
identidade de seu atual coordenador (em AYC_answer).
© Markus Endler
40
Tipos de Mensagem
origem è destino
AY_Coordinator
AYC_answer (bool)
AY_There (groupID)
AYT_answer (bool)
Coord è any
Coord è Coord
Mem è Coord
Coord è Mem
Invitation(newCoord, newGroup)
Accept (newGroup)
Accept_answer (bool)
Ready (newGroup, newDefinition)
Ready_answer (bool)
C è C, C è Mem
any è Coord
Coord è all that accepted
Coord è all in Up
all in Up è Coord
Identificação do Grupo agora é composta do par:
(PID do Coord, número de sequência)
© Markus Endler
41
Quando um Membro suspeita de falha do Coordenador
è membro simplesmente cria um novo grupo contendo somente ele
próprio.
Check_Coord() {
// periodically called
if (Coord == self) return;
send(Coord, AYThere,Group);
set timer T;
is_Coord=FALSE;
received(k, AYT_answer, is_Coord) => { // coordenator is alive
if( is_Coord == TRUE) return;
timeout T => Recovery();
// coordenator has crashed
}
Recovery() {
State= Election;
stop_processing();
Counter++;
Group = (self ⎜Counter);
Coord = self;
Up = ∅;
State = Reorganizing;
Definition = my_appl_state;
State = Normal;
}
© Markus Endler
// creates a new group of its own
42
O procedimento Merge
Merge(CoordSet) {
if (Coord == self) && (State = Normal) {
State = Election;
suspend_processing_application;
Counter++;
GroupID = (self ⎜Counter);
// creates a new group
UpSet = Up;
// UpSet: members of previous group
Up =
∅;
set timer T1;
foreach p ∈ (CoordSet ∪ UpSet) send(p, Invitation(self,GroupID));
// replies “Accept” collected in UP by monitor thread
when timeout T1=> {
// waits T1 for accept replies
State= Reorganizing;
Nr_answers=0;
set timer T2;
foreach p ∈ Up send(p, Ready(GroupID, Definition));
loop {
when revd(Ready_answer(sender, inGroup, newGroupID) => {
if (inGroup==TRUE ∧ newGroupID==GroupID) Nr_answers++;
when timeout T2 => {
// waits T2 for Ready_answers
if (Nr_answers < | Up |) Recovery();
else state = Normal;
} // endloop
}
}
© Markus Endler
43
Thread para tratar um Convite
Cada processo (participante|coordenador) precisa executar uma thread para
tratar mensagens Invitation.
loop {
when State == Normal ∧ recv(p, Invitation(newCoord, newGroupID) => {
suspend_processing_application;
oldCoord = Coord;
UpSet = Up;
// UpSet: the members of its own group
State = Election;
Coord = newCoord;
GroupID = newGroupID;
if (oldCoord == self)
// if coordenador, forward to members
foreach p ∈ UpSet send(p, Invitation(Coord,GroupID)) ;
send(Coord, Accept(GroupID));
set timer T;
when recv (Coord, Accept_answer(accepted)) => { }
when timeout T => { accepted = FALSE}
if (accepted == FALSE) Recovery();
State = Reorganizing;
}
}
© Markus Endler
44
Thread Monitor para responder às mensagens
Loop {
received(k, M) => {
// receiving a message from process k
case M == Ready(newGroup,newDefinition):
if (Group==newGroup) ∧ State == Reorganizing {
Definition = newDefinition; // only if in Reorganizing
State = Normal;
send(Coord, Ready_answer(True, Group));
} else
send(k, Ready_answer(False));
case M == AYCoordinator:
if (State==Normal ∧ Coord==self)
send(k, AYC_answer(TRUE));
else
send(k, AYC_answer(FALSE));
case M == AYThere(oldGroup):
if (Group==oldGroup ∧ Coord==self ∧ k ∈ Up)
send(k, AYT_answer(TRUE);
else
send(k, AYT_answer(FALSE);
case M == Accept(newGroup):
if State==Election ∧ Coord==self
∧ Group==newGroup { // only if in Election and for new Group
Up = Up ∪ {k}
// Up is used by Merge()
send(k, Accept_answer(TRUE));
} else
send(k, Accept_answer(FALSE));
}
} // endloop
© Markus Endler
45
O Modelo de Sistema
Suposições sobre:
•  Sincronismo ?
•  Comunicação ?
•  Tipos de Falhas ?
•  Estabilidade do sistema ?
© Markus Endler
46
Conclusões sobre o Algoritmo do Convite
Por não fazer qualquer suposição sobre o sincronismo do
sistema, este algoritmo é de utilidade prática e até é
mais simples do que o Algoritmo Bullying.
A corretude do mesmo se baseia na idéia de consistência
relativa, que é muito usada em sistemas assíncronos:
•  aplica-se a exigência de consistência (igualdade da
variável Coord e da lista de membros) somente para os
atuais membros do grupo
•  Não há qualquer exigência sobre consistência do
estado em todos os processos. O estado global é
tornado consistente “a medida do possível” (p.ex.
inclusão esponanea de novos membros, unificação de
grupos quando há descoberta mútua, etc)
•  Por exemplo: se existirem dois grupos a serem
juntados, então somente se não houver outras falhas
durante o Merge (incluindo as falhas de comunicação),
em algum momento futuro os grupos serão unificados;
© Markus Endler
47
Conclusões sobre o Algoritmo do Convite
Com relação à convergência:
•  O alg. é muito sensível à frequência de perdas de mensagem (entre
quaisquer dois processos)
•  Mas se houver subgrupos de processos em que frequência de
perda é praticamente inexistente (partições de rede), então estes
conseguirão formar grupos locais e eleger um coordenador.
•  O quanto menor for N, menor será a chance de alguma mensagem
se perder, e mais estável os grupos estarão.
© Markus Endler
48