Algoritmos de Eleio

Roteiro: Motivao e Principais Requisitos Algoritmos em Anel Algoritmo Bully Algoritmo do Convite Referncias: Livro do Chow/Johnson: seo 10.2 Livro do Colouris/Dollimore/Kindberg: seo 11.3 Livro do Michel Raynal: Distributed Algorithms and Protocols, Wiley & Sons, 1988 (seo 2.5) S. Sight & A. Kurose: Electing good leaders, Journal of Parallel and Distributed Computing Systems, 21: 194-201, 1994.

Markus Endler

Eleio Objetivo: obter um consenso em um grupo de processos sobre a escolha de um nico processo Aplicaes: Em muitos servios (ou aplicaes) distribudos um processo (arbitrrio) exerce um papel diferenciado (coordenador) Quando este falha, o grupo precisa re-eleger um novo coordenador Exemplos: Servidores replicados com com replicao passiva (primary-backup) Um processo sequenciador para comunicao multicast com ordenao total (exemplo: sistema Amoeba)
Markus Endler 2

Eleio vs. Excluso Mtua vs. Consenso

Diferenas entre Excluso Mtua e Eleio: Na Eleio, todos os participantes precisam saber quem foi escolhido A maioria dos Algoritmos de Eleio no faz suposies sobre o nmero total de processos Geralmente, Eleio iniciada como reao a uma deteco de falha (p.ex. do antigo coordenador) Algoritmos de eleio precisam lidar com a possibilidade de falha durante a escolha do novo coordenador. Para o problema da eleio assume-se uma ordem total do conjunto de IDs dos processos, e o conhecimento de um limite mximo deste conjunto Similaridades: Qualquer processo pode iniciar uma eleio (porm, no mais do que uma eleio a cada vez), ou seja, pode haver vrias execues simultneas do algoritmo de eleio Todos os processos precisam estar de acordo com a deciso tomada (o novo coordenador, ou o prximo a entrar na SC) Eleio um problema de consenso especfico (onde o valor proposto por cada processo, vi prprio PID)
Markus Endler 3

Principais Requisitos
Definio: Durante uma eleio, cada processo pode estar engajado em uma eleio (participante) ou no (no participante) Safety/Segurana: deve-se garantir a unicidade do elemento escolhido Liveness/Progresso: em algum momento, define-se um coordenador

Os principais requisitos de qualquer Algoritmo de Eleio so:

Considere N processos P1,..,PN, cada um com uma varivel Coord, incialmente indefinida (Coord = undef) As condies acima so formuladas como: Segurana: Um processo participante Pi tem Coord = undef ou Coord = P, onde P um processo correto (no faltoso) ao trmino do algoritmo. Liveness: Todos os processos Pi participam da eleio e em algum momento ou tem Coord undef, ou tero falhado. Geralmente, o problema reduzido ao de encontrar o maior/menor ID no grupo.

Markus Endler

Eleio 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 idia?

p8 p9 p3

Como detectar o trmino do algoritmo (ter encontrado o manor/maior PID) ? Quantas rodadas so necessrias?
Markus Endler

p4

p1

Algoritmos baseados em Anel

Chang & Roberts (1979) propuseram um algoritmo simples para processos interligados em uma estrutura lgica de anel (onde as mensagens s circulam em um sentido) O algoritmo funciona em 2 rodadas, para um nmero arbitrrio de processos. Ideia Central: Processo Pi inicia o algoritmo enviando uma mensagem (election, Pi.PID) para o prximo 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 prximo O processo que receber o seu prprio PID o novo coordenador. O coodenador coloca em circulao 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:
Markus Endler

Processos no falham Comunicao confivel e segura Sistema assncrono Todos os processos possuem PIDs distintos!
6

Algoritmos baseados em Anel

O algoritmo de Chang & Roberts garante a unicidade do coordenador (segurana) porque: A mensagem election passa por todos os processos (todos so 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 varivel Coord. Liveness garantida por: A funo max uma aproximao sucessiva deste PIDmax Por se tratar de um anel, e no haver perdas de mensagem, o processo com PIDmax em algum momento receber a mensagem com seu prprio PID (PIDmax) Caractersticas do Algortmo: Simetria de papis Vrios processos podem iniciar simultaneamente o algoritmo
Markus Endler

Complexidade de mensagens por requisio 2 N. No pior caso (todos comeando simultaneamente) O(N2)
7

Algoritmos baseados em Anel

Hirschberg & Sinclair [HS80] propuseram um algoritmo com custo de comunicao O(N log N), que: funciona em rodadas e assume um anel de tamanho N com links bi-direcionais confiveis 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 eleio (difundindo o seu prprio PID) Processos com PID menores respondem ao candidato, concordando com sua candidatura Processos intermedirios:

[HS90] Hirschberg & Sinclair: Decentralized Extrema Finding in Circular Configurations of Processes. Communications of the ACM, 23 (11), Nov. 1980.
Markus Endler

repassam mensagens, ou iniciam nova eleio (caso seu PID > PIDCand)

Algoritmo de Hirschberg & Sinclair

Um pouco mais de detalhes: Na rodada j o Pi envia a msg (Cand,Pi.ID) para os elementos: P(i-2j) mod N e P(i+2j) mod N Ao receber a mensagem (Cand,ID), processo Pk compara ID com o seu prprio identificador Pk.PID: Se (ID > Pk.PID) ento retorna ao remetente TRUE seno retorna FALSE e passa a ser o candidato Se o iniciador receber duas respostas TRUE, continua candidato e passa proxima rodada incrementa j Quando o iniciador recebe a msg Cand com o prprio PID, sabe que foi eleito o novo coordenador e Difunde uma mensagem Elected com o seu ID no anel.

Markus Endler

O Algoritmo de Hirschberg & Sinclair Exemplo para 7 processos: Algoritmo iniciado pelo P5
P4 P1 P3 P7
False

P5

P2

P0

P4

Os 3 tipos de mensagem: Cand (PID, d, dmax), onde: dmax: distncia mxima (# hops) a serem percorridos d: distnca (#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)
10

Markus Endler

Elected(sender)

O Algoritmo de Hirschberg & Sinclair

Cada processo pode estar em um de 4 estados: not_involved = no foi consultado ainda candidate = o atual responsvel pelas pesquisas (enquanto for o de maior PID) lost = recebeu msg com PID maior elected = quando P descobre que ele o de maior PID Variveis 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 proxima rodada Int winner // ID do processo eleito O algoritmo composto de um procedimento para iniciar a eleio (Election) e uma tread (Monitor) que trata as mensagens recebidas, e que compartilham variveis state e end_phase
Markus Endler 11

Procedimento de invocao da Eleio

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 distnca } } }
Obs: Assumimos que next[k] relaciona os vizinhos da esq/direita: next[left] = right next[right] = left
Markus Endler

Left=0
Next[2]={1,0}

Right=1

12

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 } } Markus continua ... Endler

13

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 prpria 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) iro interferir na eleio (responder negativamente), caso tenham ID maior do que o do candidato
Markus Endler 14

Eleio 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 (no responder s requisies) Durante a eleio processos podem falhar, ou voltar a ficarem ativos (mas com o mesmo PID) Objetivo: encontrar o maior PID dentre os processos ativos

Sugestes...?
p9

p8

p1 p3

p4
Markus Endler

p2
15

O Algoritmo Bully
Garcia-Molina[GM82] props um algoritmo para um sistema sncrono com falhas tipo fail-stop, baseado na difuso de mensagens (conectividade total). O algoritmo faz as seguintes suposies adicionais: Toda mensagem entregue em Tm unidades de tempo aps o seu envio; Todos os processos no falhos respondem a todas as mensagens recebidas em Tp unidades de tempo; Todos os processos tm acesso a uma memria no voltil (p.exemplo: disco local ou Sist. de Arquivos Distribudo NFS) Com as duas primeiras suposies, possvel definir um detector de falhas confivel: se um processo no responde em 2Tm+Tp unidades de tempo, ento tem-se certeza de que o mesmo falhou. A terceira suposio necessria para manter o registro de verses (instncias da eleio) 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.

16

Algoritmo Bully: Princpio de Funcionamento Periodicamente, o atual coordenador verifica se a configurao do

grupo mudou (um processo falhou ou se recuperou de falha) inicia eleio Se algum participante desconfiar da falha do Coordenador inicia eleio entre os processos ativos em determinado momento, aquele com o D maior PID deve ser eleito o coordenador. Este tenta convencer os demais intimidando-os (bullying). Antes de iniciar a1a fase, o processo iniciador da eleio faz uma consulta para ver se existe algum processo com maior PID. ( A possibilidade da deteco confivel de falhas garante que somente o processo de maior prioridade vai tentar ser o coordenador) A eleio funciona em 3 fases: ao final de cada fase, garante-se que todos os processos no falhos esto sincronizados com o mesmo estado (global) da eleio:
Markus Endler

Normal >F1> Election >F2 > Reorganizing >F3> Normal

17

Algoritmo Bully: Princpio de Funcionamento

Principais Variveis em cada Processo P: State: um valor em {Down,Election,Reorganizing,Normal} Coord: o ID do candidato a Coordenador, segundo a viso de P Definition: o estado relevante da aplicao Up: conjunto de IDs de processos supostamente ativos no halted: ID do processo que notificou P da eleio (iniciador) Significado dos estados: Down = processo voltando de um perodo de falha Election = um (ou mais candidatos) tentando se estabelecer como Coordenador Reorganizing = o estado da aplicao est sendo difundido para todos os membros do grupo (p.exemplo a nova lista de membros ativos) Normal = processamento normal (at incio da prxima eleio)

grupo

Markus Endler

18

Segurana e Liveness
As propriedades de segurana (safety) e progresso (liveness) do algoritmo so as seguintes: Safety: Seja G um estado global consistente(*). Ento para quaisquer dois pares de processos Pi e Pj as seguintes condies so satisfeitas em G: Se Pi e Pj esto nos estados {Normal,Reorganizing}, ento Pi.Coord = Pj.Coord Se Pi e Pj esto no estado Normal, ento Pi.Definition = Pj.Definition (estados sincronizados) Liveness: Seja G um estado consistente(*). Ento as duas seguintes propriedades estaro 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 no-falho, vale Pj.State = Normal && Pj.Coord = Pi
Markus Endler

(*) Uma coleo de estados locais dos processos e canais de comunicao, que de fato, poderia ter ocorrido em uma execuo do sistema.

19

Deteco de Mudana no Grupo

Periodicamente: Coord verifica a existncia de um processo ativo (com PID maior ou menor do que PIDCoord ) Coord verifica se todos os participante esto ativos (respondem mensagen AYNormal) Participante verifica se seu Coord. est ativo (mensagem AYUp) Se algum tiver detectado qq mudana inicia-se uma nova eleio... Quando um processo se recupera de uma falha, tambm inicia nova eleio. Obs: AY.. = AreYou...

Markus Endler

20

Deteco de Mudana no Grupo

Coord
AYNormal

Part A

Part B

AYN_answer AYUp AYU_answer

crash
Election()
AYNormal AYN_answer

Election()

Election()

AYUp

crash
Timer T
Markus Endler

Election()

21

Estados Globais na Execuo da Eleio

P4
AYUp

P3

P2

P1
! P tq. P.ID > P3

C1 EnterElection

& P.State=Normal P tq. (P.ID < P3) : P.Coord P P P.StateNormal P UP: P.State=Reorg. P.Coord=P3 NewState

C2 SetCoord

C3

C4

P UP: P.State=Normal P.Coord=P3

Markus Endler

22

Procedimentos que iniciam uma Eleio Qualquer processo que deixa de receber msg do coordenador por um certo perodo suspeita de sua falha
Check_Coordinator () { if (State==Normal || State == Reorganizing) { send (coord,AYUp); set timer T; } received(coord, AYU_answer) => set timer T; timeout T => Election(); }

Qualquer processo que esteja voltando de um perodo de falha

Recovery () { State = Down; Election(); }
Markus Endler 23

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 ) { Election(); } exit; } } // endloop } Obs: para cada tipo de mensagem existe uma mensagem de resposta (AYNormal - AYN_answer, etc.) Markus Endler

24

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

Procedimento Election (2)

... num_answers = 0; forall P Up send(P,Set_Coord, self); // try to establish (him)self 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 state for synchronization 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

26

Thread Monitor
Loop { received(k, M) => { case M == AYUp: send(k,AYU_answer); case M == AYNormal: send(k,state); case M == EnterElection(k): { State = Election; suspend_normal_application processing if (k > self) // defines, in which Election will participate stop_election_procedure (if executing) halted = k; send(k,EE_answer); } case M == Set_Coord(newCoord): { if (State==Election && halted==newCoord) { Coord = newCoord; State = Reorganizing; } send(k, SC_answer); } case M == NewState (NewDefinition) : if (Coord == k && State = Reorganizing) { Definition = newDefinition; // updates state State = Normal; } } // endloop Markus Endler

27

Algoritmo do Convite (Invitation Algorithm)

De Garcia-Molina[GM82] tambm o Algoritmo do Convite, que: uma variante do Algoritmo Bully para sistemas assncronos e que trata a possibilidade de ocorrem parties na rede. Sistemas Assncronos: Sem a suposio sobre tempos mximos de processamento e comunicao, no possvel saber com certeza se um processo falhou. Sabe-se apenas que a comunicao (em certo perodo) no est sendo possvel. Parties: Impossibilidade temporria da comunicao entre grupos de processos

Markus Endler

28

Algoritmo do Convite
Suposies do Modelo: Comunicao segura Falhas do tipo fail-stop Ns guardam o estado em memria persistente (aps se recuperar de uma falha, conseguem recuperar o estado anterior) Processos podem ficar temporariamente isolados uns dos outros (parties na rede) As mudanas de conectividade da rede ocorrem com baixa freqncia Caractersticas: Permite que existam mais de um grupo (com seu coordenador) isolados Mas se houver alguma possibilidade de comunicao entre estes grupos, eles iro se fundir
Markus Endler 29

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 grupos de processos cujos membros esto conseguindo interagir Obs: permite-se grupos unitrios consistindo apenas do candidato a coordenador! Periodicamente, cada coordenador verifica se existem outros coordenadores, e tenta convidar todos os membros do grupo correspondente a se juntar ao seu grupo. Para evitar que dois coordenadores fiquem se roubando mutuamente membros do outro grupo, aps a descoberta do outro coordenador, este espera um tempo inversamente proporcional sua prioridade (valor do PID) at comear a enviar os convites.

Para isto, necessrio usar a noo de grupo, com um

identificador nico (groupID)
Markus Endler 30

Algoritmo do Convite
Adaptando as propriedades de segurana e progresso para o algoritmo do convite: Safety: Seja G um estado consistente. Ento para quaisquer dois pares de processos Pi e Pj as seguintes condies so satisfeitas em G: Se Pi e Pj esto nos estados {Normal,Reorganizing} e Pi.Group = Pj.Group, ento Pi.Coord = Pj.Coord Se Pi e Pj esto no estado Normal, e Pi.Group = Pj.Group ento Pi.Definition = Pj.Definition Liveness: Seja R o conjunto mximo de processos mutuamente comunicveis em um estado consistente G. Ento as duas seguintes propriedades sero em algum momento satisfeitas (para qualquer processamento a partir de G), contanto que o conjunto mximo de processos mutuamente comunicveis R permanea igual e no ocorram outras falhas: Existe um Pi R tal que Pi.State = Normal && Pi.Coord = Pi Para todos os processos Pj R no-falhos, vale Pj.State = Normal && Pj.Coord = Pi
Markus Endler 31

Algoritmo do Convite (Invitation Algorithm)

A propriedade de segurana facil de ser satisfeita, pois depende de como escolhido o grupo (= pode ser qualquer conjunto de processos que concorde em adotar o mesmo coordenador). Para satisfazer a propriedade de progresso, precisa-se garantir que: Se membros de grupos distintos conseguem se comunicar, ento em algum momento futuro, ter sido formado um novo grupo (com coordenador nico) contendo todos os processos mutuamente comunicveis (ou seja, o conjunto R). Para tal, necessrio que os coordenadores dos grupos correspondentes concordem sobre a formao de um novo grupo contendo todos os membros dos grupos originais e um nico coordenador. Sucessivamente, grupos menores vo se aglutinando, at formar um grupo contendo todo R. Cada coordenador, periodicamente tenta descobrir outros coordenadores e executar um Merge() nos grupos tendo como parmetro a lista de outros coordenadores encontrados (Others). Markus Endler

32

Funcionamento Bsico
Periodicamente, um coordenador difunde um AYCoord? tentando contactar outros coordenadores, armazena o ID destes na varivel Other e tenta juntar os grupos (procedimento Merge(Other)) atravs de mensagens Invitation. Ao receber uma Invitation de outro coordenador, NC, um coordenador C repassa esta mesagem para os participantes de seu grupo, que respondem diretamente a NC usando msg Accept. O prprio C tambm envia Accept para NC. O NC por sua vez confirma o seu papel de novo coordenador atravs de Accept_answer. Se esta mensagem no chegar a tempo, qualquer processo pode executar recovery(); A seguir, NC envia a mensagem Ready com seu estado Definition para todos os processos da unio dos grupos originais. Principais variveis em cada processo: State // {Normal, Election, Reorganizing} UpSet // conjunto dos membros do prprio grupo Up // conjunto dos membros da unio dos grupos Group // identificao do grupo (par [CoordID,count]) Others // conjunto de outros coordenadores descobertos Markus Endler

33

Execuo da Eleio
Merge(P2)

P4

Invitation P4 Accept Accept_answer

P3

P2
Invitation P4 Accept

P1

Accept_answer

Up

Ready

Ready_answer

Grupo A
Markus Endler

Grupo B
34

Coordenador procura por outros coordenadores

Periodicamente, cada coordenador verifica se consegue se comunicar com outro coordenador (e coleta na varivel Others as Ids 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; 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

35

Tipos de Mensagem
origem destino AY_Coordinator AYC_answer (bool) AY_There (groupID) AYT_answer (bool) Invitation(newCoord, newGroup) Accept (newGroup) Accept_answer (bool) Ready (newGroup, newDefinition) Coord any Coord Coord Mem Coord Coord Mem C C, C Mem any Coord Coord any Coord any

Identificao do Grupo agora composta de: (ID do Coord, nmero de sequncia)

Markus Endler

36

Quando um Membro suspeita de falha do Coordenador

embro simplesmente cria um novo grupo contendo somente ele m prprio.
Check_Coord() { if (Coord == self) return; send(Coord, AYThere,Group); set timer T; is_Coord=FALSE; received(k, AYT_answer, is_Coord) => { if( is_Coord == TRUE) return; timeout T => Recovery(); } Recovery() { State= Election; stop_processing(); Counter++; Group = (self Counter); Coord = self; Up = ; State = Reorganizing; Definition = my_appl_state; State = Normal; } // periodically called

// coordenator is alive // coordenator has crashed

// creates a new group

Markus Endler

37

O procedimento Merge
Merge(CoordSet) { if (Coord == self) && (State = Normal) { State = Election; suspend_processing_application; Counter++; Group = (self Counter); // creates a new group UpSet = Up; Up = ; set timer T1; foreach p (CoordSet UpSet) send(p, Invitation(self,Group)); // 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(Group,Definition)); loop { when revd(Ready_answer(sender,inGroup, newGroup) => { if (inGroup==TRUE newGroup==Group) Nr_answers++; when timeout T2 => { // waits T2 for Ready_answers if (Nr_answers < | Up |) Recovery(); else state = Normal; } // endloop } Markus Endler }

38

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, newGroup) => { suspend_processing_application; oldCoord = Coord; UpSet = Up; // UpSet: the members of its own group State = Election; Coord = newCoord; Group = newGroup; if (oldCoord == self) // if coordenador, forward to members foreach p UpSet send(p, Invitation(Coord,Group)) ; send(Coord, Accept(Group)); set timer T; when recv (Coord, Accept_answer(accepted)) => { } when timeout T => { accepted = FALSE} if (accepted == FALSE) Recovery(); State = Reorganizing; } } Markus Endler

39

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

Markus Endler

} } // endloop

O Modelo de Sistema

Sincronismo Comunicao Tipos de Falhas Estabilidade do sistema

Markus Endler

41

Concluses sobre o Algoritmo do Convite Por no fazer qualquer suposio sobre o sincronismo do sistema, este algoritmo de utilidade prtica e at mais simples do que o Algoritmo Bully. A corretude do mesmo se baseia na idia de consistncia relativa, que muito usada em sistemas assncronos: aplica-se a exigncia de consistncia (concordncia sobre o Coord e lista de membros) somente para os atuais membros do grupo No h qualquer requisito sobre corretude/consistncia da viso do grupo total. Esta atualizada pela lei do melhor esforo (p.ex. incluso esponnea de novos membros, unificao de grupos quando h descoberta mtua, etc) Por exemplo: se existirem dois grupos a serem juntados, ento somente se no houver outras falhas durante o Merge (incluindo as falhas de comunicao), Markus Endler em algum momento futuro os grupos sero unificados;

42