© Markus Endler1 Algoritmos de Eleição Roteiro: Motivação e Principais Requisitos Algoritmos em...
Transcript of © Markus Endler1 Algoritmos de Eleição Roteiro: Motivação e Principais Requisitos Algoritmos em...
© Markus Endler 1
Algoritmos de Eleição
Roteiro:• Motivação e Principais Requisitos• Algoritmos em Anel• Algoritmo Bully• 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 2
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 3
Eleição vs. Exclusão Mútua
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)
© Markus Endler 4
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
• Liveness/Progresso: em algum momento, define-se um coordenador
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.
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
p1p4
p3p9
• Como detectar o término do algoritmo (ter encontrado o manor/maior PID) ?• Quantas rodadas são necessárias?
© Markus Endler 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 (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 textual• Vários processos podem inciar 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 CircularConfigurations 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:
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 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 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
P7 P0P2P5 P4P3P1P4
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 4 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 2Bool remain // TRUE = continua candidato na proxima rodada Int winner // ID do processo eleito
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 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) ); // forwardelse 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)
... continuareceived(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
p2p4
p3p9
p1
© Markus Endler 16
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 ou Sist. de Arquivos Distribuído – NFS)
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 17
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) 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 iniciar a1a. fase, o processo iniciador da eleição faz uma consulta para ver 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)
• 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
© Markus Endler 18
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 PDefinition: o estado relevante da aplicaçãoUp: conjunto de IDs de processos supostamente ativos no
grupohalted: ID do processo que notificou P da eleição (iniciador)
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 19
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 ponto 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 20
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.. = AreYou...
© Markus Endler 21
Detecção de Mudança no Grupo
Timer T
Coord Part A Part B
crash
AYNormal
AYN_answer
AYUp
AYU_answer
crash
Election()
AYUp
Election()
Election()
AYN_answer
AYNormal Election()
© Markus Endler 22
Execução da Eleição
P3P4 P2 P1AYUp
P tq. P.ID > P3
& P.State=Normal C1
NewStateP UP:P.State=Normal P.Coord=P3C4
SetCoord P UP:
P.State=Reorg. P.Coord=P3
C3
EnterElection P tq. (P.ID < P3) :P.Coord P
P P.StateNormal C2
© Markus Endler 23
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 T;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 24
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 processexit;
}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 25
Procedimento Election (1)
Election() {highest = True;forall P with P.ID > self.ID send(P, AYUp); // look for higher-priority processesset timer T;received(sender, AYU_answer) => {
highest = False; return;}timeout T => ; // wait only for certain amount of timeState = 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;State = Reorganizing;...
Obs: participant= process with a lower PID
© Markus Endler 26
Procedimento Election (2)
...num_answers = 0;forall P Up send(P,Set_Coord, self); // try to establish (him)self as CoordSet 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 27
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 processingif (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 28
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 29
Algoritmo do Convite
Suposições do Modelo:
• Comunicação é segura• Falhas 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)• Processos podem ficar temporariamente isolados uns dos outros
(partições na rede)• As mudanças de conectividade da rede ocorrem com baixa
freqüência
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 30
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 estão conseguindo interagirObs: permite-se grupos unitários 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, 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 31
Algoritmo do Convite
Adaptando as propriedades de segurança e progresso para o algoritmo do convite:
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.DefinitionLiveness: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), contanto 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 32
Algoritmo do Convite (Invitation Algorithm)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 o mesmo coordenador).
Para satisfazer a propriedade de progresso, 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 33
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, NC, um coordenador C repassa esta mesagem para os participantes de seu grupo, que respondem diretamente a 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 grupoUp // conjunto dos membros da união dos gruposGroup // identificação do grupo (par [CoordID,count])Others // conjunto de outros coordenadores descobertos
© Markus Endler 34
Execução da Eleição
P3P4 P2 P1Invitation P4
Invitation P4
Accept_answer
AcceptAccept_answer
Accept
UpReady
Ready_answer
Merge(P2)
Grupo A Grupo B
© Markus Endler 35
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; 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 as Ids correspondentes)
Obs: Se um participante de outro grupo receber msg AYCoord, informa a identidade de seu atual coordenador (em AYC_answer).
© Markus Endler 36
Tipos de Mensagem
AY_Coordinator Coord anyAYC_answer (bool) Coord CoordAY_There (groupID) Mem CoordAYT_answer (bool) Coord MemInvitation(newCoord, newGroup) C C, C MemAccept (newGroup) any CoordAccept_answer (bool) Coord any Ready (newGroup, newDefinition) Coord any
origem destino
Identificação do Grupo agora é composta de:(ID do Coord, número de sequência)
© Markus Endler 37
Quando um Membro suspeita de falha do Coordenador
Check_Coord() { // periodically calledif (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 groupCoord = self;Up = ;State = Reorganizing;Definition = my_appl_state;State = Normal;
}
membro simplesmente cria um novo grupo contendo somente ele próprio.
© Markus Endler 38
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 threadwhen 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 39
Thread para tratar um Convite
loop {when State == Normal recv(p, Invitation(newCoord, newGroup) => {
suspend_processing_application;oldCoord = Coord; UpSet = Up; // UpSet: the members of its own groupState = 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;
}}
Cada processo (participante|coordenador) precisa executar uma thread para tratar mensagens Invitation.
© Markus Endler 40
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 ReorganizingState = 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
GroupUp = Up {k} // Up is used by Merge()send(k, Accept_answer(TRUE));
} else send(k, Accept_answer(FALSE));}
} // endloop
© Markus Endler 41
O Modelo de Sistema
• Sincronismo• Comunicação• Tipos de Falhas• Estabilidade do sistema
© Markus Endler 42
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 Bully.
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 (concordância sobre o Coord e lista de membros) somente para os atuais membros do grupo
• Não há qualquer requisito sobre corretude/consistência da visão do grupo total. Esta é atualizada pela lei do “melhor esforço” (p.ex. inclusão esponânea 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;