© Markus Endler 1

Algoritmos de Eleição

difere da eleição convencional eleição de um processo coordenador – instância do problema de acordo (todos os processos precisam concordar sobre mesmo coordenador)

© Markus Endler 2

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 3

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 4

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 (processos podem falhar) •  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 requisições concorrentes (pedidos 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 5

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 6

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 ( se a falha realmente ocorreu e é estável)

Essencialmente, o problema pode ser reduzido ao de encontrar o maior/

menor ID no grupo de processos ativos.

© Markus Endler 7

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

p1 p4

p3 p9

•  Como detectar o término do algoritmo (ter encontrado o manor/maior PID) ? •  Quantas rodadas são necessárias?

© Markus Endler 8

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 9

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 10

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 11

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 12

O Algoritmo de Hirschberg & Sinclair

Exemplo para 7 processos: Algoritmo iniciado pelo P5

P7 P0 P2 P5 P4 P3 P1 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 13

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 14

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 Next[0] = 1

Next[1] = 0

Left=0 Right=1

© Markus Endler 15

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 16

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 17

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

p2 p4

p3 p9

p1

© Markus Endler 18

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 19

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 20

Eleição em Zookeeper

•  Zookeeper é um sistema que mantém a configuração consistente para nós de clusters

•  Utiliza um algoritmo de monitoramento hierarquico:

The process of leader election (for N nodes in a cluster) is as follows: •  All the nodes create a sequential, ephemeral znode with the same path, /app/leader_election/

guid_. •  ZooKeeper ensemble will append the 10-digit sequence number to the path and the znode

created will be /app/leader_election/guid_0000000001, /app/leader_election/guid_0000000002, etc.

•  For a given instance, the node which creates the smallest number in the znode becomes the leader and all the other nodes are followers.

•  Each follower node watches the znode having the next smallest number. For example, the node which creates znode /app/leader_election/guid_0000000008 will watch the znode /app/leader_election/guid_0000000007 and the node which creates the znode /app/leader_election/guid_0000000007 will watch the znode /app/leader_election/guid_0000000006.

•  If the leader goes down, then its corresponding znode /app/leader_electionN gets deleted.

© Markus Endler 21

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 (sistema síncrono): •  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.

[GM82] Garcia-Molina. Elections in a Distributed Computing System, IEEE Trans. On Computers, C-31(2),48-59, 1982.

© Markus Endler 22

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 23

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 24

Algoritmo Bully: Princípio de Funcionamento

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)

Election

Reorganiz...

Normal Down

Estados percorridos por todos os processos

Obs: durante os estados Election e Reorganiz. o processamento da aplicação fica suspenso.

© Markus Endler 25

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 26

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) •  Cada Participante periodicamente 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 27

Monitoramento do Grupo e Situações de chamada de Election

Timer T

Coord Part A Part B

crash

AYNormal

AYN_answer AYUp

AYU_answer

crash

Election()

AYUp

Election()

Election()

AYN_answer

AYNormal Election()

ok

ok

© Markus Endler 28

Estados Globais na Execução da Eleição

P3 P4 P2 P1 AYUp

!∃ P tq. P.ID > P3 & P.State=Normal C1

NewState ∀P ∈UP: P.State=Normal ∧ P.Coord=P3 C4

SetCoord ∀P ∈ UP: P.State=Reorg. ∧ P.Coord=P3

C3

EnterElection ∀ P tq. (P.ID < P3) : P.Coord ≠ P ∀P P.State≠Normal C2

P3

© Markus Endler 29

Procedimentos que iniciam uma Eleição

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 deixa de receber msg do coordenador por um certo período è suspeita de sua falha

•  Qualquer processo que esteja voltando de um período de falha

Recovery () { State = Down; Election();

}

© Markus Endler 30

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 31

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; State = Reorganizing; ...

Obs: participant= process with a lower PID

© Markus Endler 32

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 33

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 34

Algoritmo do Convite (Invitation Algorithm)

É também de Garcia-Molina[GM82] 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 na rede: •  Impossibilidade temporária da comunicação entre grupos de

processos

© Markus Endler 35

Algoritmo do Convite Suposições (Modelo de Sistema): •  Comunicação é segura •  Falhas são no máximo do tipo crash •  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

frequência

Características: •  Permite que existam mais de um grupo isolados (cada um com seu

coordenador) •  Mas se houver alguma possibilidade de comunicação entre estes

grupos, estes irão se fundir e terão apenas um coordenador

© Markus Endler 36

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 que existam 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 37

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 38

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 39

Algoritmo do Convite (Invitation Algorithm)

Para satisfazer a propriedade de liveness, precisa-se garantir que: •  Se membros de grupos distintos conseguem se comunicar, (e

isso permanece assim durante um período suficientemente longo) então em algum estado futuro, terá sido formado um novo grupo - com coordenador único e 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 40

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 // {Normal, Election, Reorganizing} UpSet // conjunto dos membros do próprio grupo Up // conjunto dos membros da união dos grupos Group // identificação do grupo, através do par (CoordID, count]) Others // conjunto de outros coordenadores descobertos

© Markus Endler 41

Execução da Eleição

P3 P4 P2 P1 Invitation P4

Invitation P4

Accept_answer

Accept Accept_answer

Accept

Up Ready

Ready_answer

Merge(P2)

Grupo A Grupo B

© Markus Endler 42

Coordenador procura por outros coordenadores

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); }

Periodicamente, cada coordenador verifica se consegue se comunicar com outro coordenador (e coleta na variável Others os PIDs correspondentes)

Obs: Se um participante de outro grupo receber msg AYCoord, informa a identidade de seu atual coordenador (em AYC_answer).

© Markus Endler 43

Tipos de Mensagem

AY_Coordinator Coord è any AYC_answer (bool) Coord è Coord AY_There (groupID) Mem è Coord AYT_answer (bool) Coord è Mem Invitation(newCoord, newGroup) C è C, C è Mem Accept (newGroup) any è Coord Accept_answer (bool) Coord è all that accepted Ready (newGroup, newDefinition) Coord è all in Up Ready_answer (bool) all in Up è Coord

origem è destino

Identificação do Grupo agora é composta do par: (PID do Coord, número de sequência)

© Markus Endler 44

Quando um Membro suspeita de falha do Coordenador

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); // creates a new group of its own Coord = self; Up = ∅; State = Reorganizing; Definition = my_appl_state; State = Normal;

}

è membro simplesmente cria um novo grupo contendo somente ele próprio.

© Markus Endler 45

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 46

Thread para tratar um Convite

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; }

}

Cada processo (participante|coordenador) precisa executar uma thread para tratar mensagens Invitation.

© Markus Endler 47

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 48

O Modelo de Sistema

Suposições sobre: •  Sincronismo ? •  Comunicação ? •  Tipos de Falhas ? •  Estabilidade do sistema ?

© Markus Endler 49

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 50

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 a perda de msgs é

praticamente inexistente (onde não há novas partições de rede), então, mais cedo ou mais tarde, 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 51

Trabalho Prático 1 •  Imlemente e teste no Sinalgo o Algoritmo do Convite para N nós

móveis em uma região 50 x 50 metros. A simulação precisará ser síncrona.

•  Os nós se movem segundo o modelo RandomWaypoint (i.e. escolhem randomicamente direção Φ e distância d =[5,25] se movem com velocidade constante, e chegando ao destino, esperam um certo período de tempo fixo T, antes de escolherem novamente outro destino)

•  Os radios sem fio tem um alcance de R metros (por exemplo de 15 metros) e permitem comunicação bidirecional.

•  Enquanto se movem, os nós também podem se comunicar. •  A cada instante, haverá grupos conexos de nós móveis. •  Os nós se comunicam através de inundação, onde cada hop

significa 1 rodada

•  Mostre como a frequência de Merge() e o tempo de convergência do algoritmo de eleição varia com N, T, R.