12.4 Cartruio 12m Coonoenacho eAcon0 421 eleicao na c Co: ce x ——a ———h % Tepe leiggo ‘eleica0 alegao RRS eso: Py 2», Py tempo limite Estégio 3 K x » p », P Finalmente coordenador —s Estigio 4 x >< ey yy Ps Figura 12.8 0 algoritmo valentao. ‘elecdo do coordenador p, asa fala de p, €, depos, dep, Pegando o exemplo que acabamos de dar, suponha que p, ndo tivesse falhado, mas estava exe- cutando de forma extraordinariamente lenta (isto é, a suposigd0 de que o sistema é sincrono esta incorreta), ou que p;tivesse falhado, mas entdo foi substituido. Assim como p, envia sua mensagem de coondenador, p, (ou seu substituto) faz.0 mesmo. p, recebe a mensagem de coondenador de p, aps ter enviado a sua propria e, portanto, configura elected, = p,, Devido aos atrasos de transmissio de mensagem varidveis, p, recebe a mensagem de coordenador de p, aps a de p, e, assim, finalmente configura elected, = pA condigo El foi violada, ‘Com relagio ao desempenho do algoritmo, no melhor caso, 0 processo com o segundo identifi- cador mais alto nota a falha do coordenador. Entio, ele pode se eleger imediatamente e enviar N 2 ‘mensagens de coordenador. O tempo do ciclo de rotagio é 0 de uma mensagem. O algoritmo valent30 exige O(N") mensagens, no pior caso - isto é, quando o processo com © menor identificador detecta primeiro a falha do coordenador. Nesse caso, N — | processos em conjunto iniciam eleigdes, cada um enviando mensagens para os processos com identificadores mais altos. Comunicacao multicast A Segao 4.5.1 descreveu 0 multicast IP, que ¢ uma implementagdo de comunicagio em grupo. A co- io em grupo, ou por multicast, exige coordenagio e acordo. O objetivo € que cada processo ‘de um grupo de processos receba copias das mensagens enviadas para o grupo, freqiientemente com garantias de distribuigao. As garantias incluem o acordo sobre 0 conjunto de mensagens que cada processo do grupo deve receber e a ordem de entrega pelos membros do grupo. ‘Os sistemas de comunicagio em grupo so extremamente sofisticados. Mesmo o multicast IP, que fornece garantias de distribuigio mfnimas, exige um trabalho de engenharia importante. O tempo e a cficiéncia da largura de banda sio preocupagdes sérias € desafiadoras, mesmo para grupos de proces422 Sisreaas Disrsguloos, Conceros € PRoIETO ‘sos estaticos. Os problemas so multiplicados quando os processos podem entrar € sair dos grupos em momentos arbitrdrios. Estudaremos aqui a comunicagio multicast para grupos de processos cuja participagio cong membro € conhecida, © Capitulo 15 expandiré nosso estudo para a comunicagio de grupo completa incluindo o gerenciamento de grupos que variam dinamicamente. ‘A comunicagio multicus! tem sido 0 assunto de muitos projetos. incluindo o V-system (Chenion € Zwaenepoel 1985], Chorus [Rozier ¢/ al. 1988], Amoeba [Kaashoek ¢/ al. 1989, Kaashoek e Tanen- baum 1991 j, Trans/Total [Melliar-Smith e/ al. 1990], Delta-4 [Powell 1991}, Isis [Birman 1993}, Ho- rus [van Renesse ¢/ al. 1996), Totem (Moser et al. 1996) ¢ Transis [Dolev ¢ Malki 1996] ~¢ citaremos ‘outros trabalhos notavers no decorrer desta seco. A caracteristica basica da comunicagao multicast € que um proceso executa apenas uma ope ragio multicast para enviar uma mensagem para cada processo de um grupo de processos (em Java, essa operacao € aSocker.send(aMessage)), em vez. de execular Varias operag®es sertd para processor individuais. A comunicagio com todos os processos do sistema, em oposigdo a um subgrupo deles. € conhecida como broadcast O uso de uma dnica operacdo mudricast, em ver de virias operagdes send, significa muito mats do {que uma conveniéneia para 0 programador. Ela permite que a implementagao seya eficiente € possibi lita fomecer garantias de enirega mais fortes do que seriam possiveis de outra forma Eficiéncia’ a informagao de que a mesma mensagem vai ser enviada para todos os processos de ‘um grupo permite que a implementagao seja eficiente em sua utilizagao da largura de banda. Po- dei ser tomadas medidas para enviar a mensagem nao mais do que uma vez por qualquer enlace de comunicacao. por meio do seu envio para uma dirvore de distribuiga0; € pode-se usar suporte de hardware de rede para multicast, onde isso estiver disponivel. A implementagao também pode minimizar o tempo total gasto para enviar a mensagem para todos os destinos, em ver de transi tila separadamente, ¢ em série Para ver essas vantagens, compare a utilizagao da largura de banda ¢ o tempo de transmisso (otal gasto ao enviar a mesma mensagem de um computador em Londres para dois computsde- res na mesma rede Ethernet, em Palo Alto, (a) por meio de dois envios de UDP separados ¢ (b} por meio de uma tinica operagdo de multicast IP. No primeiro caso, duas cOpias das mensagens siio enviadas independentemente, ¢ a segunda ¢ retardada pela primeira. No segundo caso, um conjunto de roteadores com capacidade multicast encaminha uma tinica cépia da mensagem de Londres para um roteador na rede local de destino. Entdo. o roteador final usa um mulficast €m hardware (fornecida pela rede Ethernet) para enviar a mensagem para os destinos. em ver de envid-la duas vezes Garantias de entrega: se um processo exccuta vérias operagées send independentes para proces sos individuats, cntdo ndo hd como a implementagao dar garantias de entrega que afelem 0 grupo de processos como umm todo. Se o remetente falhar na metade do proceso de envio, alguns mem bros do grupo poderdo receber a mensagem, enquanto outros nao. E a ordem relativa das das mensagens enviadas para quaisquer dois membros do grupo € indefinida. Na verdade. no cas particular de multicast IP nenhuma garantis de ordem, ou confiabilidade, ¢ oferecida, Mas podem ser dadas garantias de multicast mais fortes, € em breve definiremos alguias Modelo de sistema 9 0 sistema contém um conjunto de processes, os guais podem se comunicar com confiabilidade por meio de canais um para um. Como antes, os processas podem fathor apenas por colapso. Os processus sio membros de grupos, os quals so 0s destinos das mensagens enviadas com # ‘operagao de multicast. Geralmente € dtil permitir que os processos sejam membros de varios grupos simaltaneamente ~ por exemplo, para permitir que processos recebam informagées de varias Fontes ‘entrando em varios grupos. Mas para simplificar nossa discussao sobre as propriedades de ordenayse- as vezes resiringitemos os processos de modo a serem membros de no maXitno um erupe por YE? A operacio multicast, m) envia & mensagem nr para todos os meinbros do grupo x (processes) Correspondentemente. exisie uma operasao detiverton) que distribui (entrega) uma mensagem rece ‘bida por multicast para 0 processo que a exccuta. Usamas 0 termo distribuir ov entregar, em ver de receber, para vornar claro que uma mensagem mulricass nem sempre é entregue para a camadaCastro 12m Coonoenacho EAcoRD0 423 aplicativo dentro do processo, assim que € recebida no né do processo. Isso serd explicado quando discutirmos a semaintica da distribuigde por multicast, em breve. ‘Toda mensagem m transporta 0 identificador exclusivo do processo sender(m) que a enviou € 0 identiticador de grupo de destino exclusive group(m). Supomos que os processos ndo mentem sobre a origem ou destinos das mensagens. Diz-se que um grupo ¢ fechado se apenas os membros do grupo podem fazer multicast para ele (Figura 12.9). Um processo em um grupo fechado envia para si mesmo toda mensagem que difunde seletivamente (multicast) para 0 grupo. Um grupo € aberto se processos de fora podem enviar men- sagens para cle. (As categorias “aberto” e “fechado” também se aplicam as listas de distribuigio de e-mail, com significados andlogos.) Os grupos fechados de processos sio dieis, por exemplo. para servidores em cooperacio para enviar uns aos outros mensagens que apenas eles devem receber. Os grupos abertos so utes. por exemplo, para enviar eventos para grupos de processos interessados, Alguns algoritmos presumem que os grupos sio fechados. O mesmo efeito de abertura pode ser obtido com um grupo fechado, escolhendo-se um membro do grupo e enviando-se a cle uma men- sagem (um para um) para difundir setetivamente para seu grupo. Rodrigues er al. [1998] discutem 0 ‘multicast para grupos abertes. 12.4.1 Multicast basico E imteressante termos & nossa disposigdo uma primitiva de multicast bésico que garanta, a0 contririo do multicast IP, que um processo correto finalmente distribuir a mensagem. desde que 0 difusor no falhe. Chamamos a primitiva de B-multicast ¢ sua primitiva de distribuiggo bésica correspondente de Bedeliver. Permitimos que 0s processos pertengam a varios grupos e cada mensagem € destinada a algum grupo em particular. Uma maneira simples de implementar B-multicasr & usando uma operagio send de um para um confidvel, como segue: Para B-multicast(g, m): para cada processo p € g. send{(p, m): Em receive(m) em p: B-delivertm) em p. A implementagio pode usar threads para executar as operagdes send concorrentemente, em uma, tentativa de reduzir o tempo total gasto para distribuir a mensagem. Infelizmente, tal implementacao € propensa a sofrer a conhecida explosito de confirmacdes, caso 0 niimero de processos seja grande. s sinais de confirmagao, enviados como parte da operago send confidvel, esto sujeitos a chegar de "muitos processos quase ao mesmo tempo. Os buffers dos processos sero consumides rapidamente © 50 Grupo fechado N/ Grupe aberto x 4 3 ° Figura 12.9 Grupos abertos e fechados.424 ssreus Dstaminos, Concenns € POI ‘os sinais de confimagio podem ser perdidos. Portanto ele retransmitiré 2 mensagem, acarretandy ain. dda mais sinas de canfirmagies ¢ mais desperdicio de largura de banda de rede. Um servigo multicast bbésico mais pritnco pode ser constnuido, usando-se maulrcast IP, ¢ convidamos 0 leitor a mostrar i99, 12.4.2 Multicast confiavel [A Sogo 2.3.2 definiu os canais de comunicagdo um para um confidveis entre pares de processos. A propniedade de seguranca exiguia ¢ chamada de integridade ~ a de que qualquer mensagem entregue € idéemica aquela que foi enviada € que nenhama mensagem ¢ entregue duas vezes. A propriedade de subsisténcia exipida € chamada de validade ~a de que qualquer mensagem ¢ finalmente entregue para destino, seestiver correta. ‘Seeuindo Hadzilacos Toveg [1994] ¢ Chandra ¢ Toueg |1996}. definiremos agora o multicast conpidvel, com as operacies correspondents R-multicast € R-deliver (R de Reliable). Claramente, ‘propnedades andlogas a ntegndade ¢ & validade sio altamente desejaveis na distribuigdo por mad- ricast confiivel. Mas acrescentamos outra: 0 requisito de que todos os processos corretos do grupo . Uma confirmagio informa, para um remetente mimero de sequéncia da mensagem mais recente de q, destinada a g, que p entregou desde que difun- diu um multicast. Entao, 0 emissor p envia a mensagem por multicast IP para g, com seus valores “de ccarona’ ¢ incrementa S° por um. (0s valores “de carona” em uma mensagem multicast permitem que os destinatirios saibam sobre as mensagens que nio receberam. Um processo entrega uma mensagem com R-deliver, destinada a g, contendo o ntimero de seqiiéncia $ de p, se € somente se $= R! + 1, incrementa RY por um, imedia- tamente apés a distribuigdo. Se uma mensagem recebida tem S 5 1, entio renviou a mensagem antes ea descarta, Se $ > Ri + 1 ou se R> Ri com uma confirmagio incluida , entio existe uma ou ‘mais mensagens ainda no recebidas (e que provavelmente foram eliminadas, no primeiro caso). Ele ‘mantém toda mensagem para a qual $> Rj + 1,em uma fila de espera (Figura 12.11) ~ tai filas sio fre- Gilentemente usadas para satisfazer garantias de distribuigdo de mensagem. Ele solicita as mensagens ausentes enviando confirmagdes negativas para 0 remetente original, ou para um processo q a partir do qual recebeu uma confirmagio , com Rt niio menor do que o ntimero de sequéncia exigido.426 _ Sistewas Disrmwuioos, Concertos € PROIETO Fila de espera Quando as garantias de entrega Mensagens so satistetas recebidas Figura 12.11 A fila de espera para mensagens multicast recebidas. AA fila de espera ndo € rigorosamente necesséria para a confiabilidade, mas simplifica o protocoto. nos permitindo usar nmeros de seqiiéncia para representar conjuntos de mensagens enviadas. Ela também nos fornece uma garantia da ordem de envio (veja a Secdo 11.4.3). ‘A propriedade da integridade resulta da detecc3o de duplicatas e das propriedades subjacentes do multicast IP (que usa somas de verificagao para eliminar mensagens corrompidas). A propriedade da validade vale porque 0 multicast IP tem essa propriedade. Para o acordo, exigimos primeiro que ‘um processo sempre possa detectar mensagens ausentes. Isso, por sua vez, significa que ele sempre receberd mais uma mensagem que permita detectar a omissio. Conforme o protocolo simplificado, garantimos a detecedo de mensagens ausentes apenas no caso em que processos corretos enviam ‘mensagens por multicast, indefinidamente, Segundo, a propriedade do acordo exige que sempre haja ‘uma c6pia dispontvel de toda mensagem necessdria para um processo que niio a recebeu. Portanto, presumimos que os processos mantém indefinidamente as c6pias das mensagens que enviaram ~nesse protocolo simplificado. Nenhuma das suposigdes que fizemos para garantit 0 acordo € pritica (veja o Exercicio 11.14). Entretanto, 0 acordo € tratado praticamente em todos os protocolos dos quais © nosso é derivado: 0 protocolo Psync [Peterson et al. 1989], 0 protocolo Trans [Melliar-Smith et al. 1990] ¢ 0 protocolo de multicast confidvel escalivel [Floyd et al. 1997]. Os protocolos Psyne ¢ Trans também fornecem garantias de ordenacio de entrega a mais. Propriedades uniformes 0 A detinigio de acordo dada anteriormente se refere apenas a0 c0inyor tamento de processos corretos ~ processos que nunca falham. Considere o que aconteceria i sig0- ritmo da Figura 12.10 se um processo nio fosse correto ¢ falhasse apds ter entregue uma mensagem com R-deliver. Como todo processo que entrega mensagem com R-deliver deve primeiro envis-la com B-multicast, segue-se que todos os processos corretos terminario por entregar a mensagem. ‘Toda propriedade que vale, sejam os processos corretos ou nao, é chamada de propriedade wnifor ‘me. Definimos 0 acordo uniforme como segue: Acordo uniforme: se um proceso, correto ou falho, entrega uma mensagem m, entdo todos os processos corretos em group(m) terminarao por entregar m. 0 acordo uniforme permite que um processo falhe apés ter enviado uma mensagem, enquanto ainda garante que todos 0s processos corretos entregario a mensagem. Argumentamos que 0 alg0- ritmo da Figura 12.10 satisfaz essa propriedade. que & mais forte do que a propriedade do acordo nio- uuniforme, definida anteriormente. © acordo uniforme € itil em apticagdes onde um proceso pode executar uma ago que produz uma inconsisténcia observvel antes de falhar. Por exemplo, considere que 0s processos sio servidores gerenciando c6pias de uma conta bancéria, e que as atualizagées na conta so enviadas para 0 grupo de servidores usando multicast confidvel. Se 0 multicast nao satisfizer 0 acordo uniforme. entio umCariuio 12 @ Cooroenacko eAcoroo 427 cliente que acesse um servidor imediatamente antes dele falhar poderd observar uma atualizagao que renhum outro servidor processard leressante notar que, se invertermios as linhas “Redeliver m” e “if (q # p) then Bemulticastts, ‘m); end if” na Figura 12.10, 0 algoritmo resultante nao satisfari o acordo uniforme. Assim como existe uma versio uniforme do acordo, também existem versdes uniformes de qual {quer propriedade de multicast, incluindo validade ¢ integridade ¢ as propriedades de order estamos para definir. 12.4.3 Multicast ordenado Oalgoritmo multicast basico da Segao 12.4.1 entrega mensagens para processos em uma ondem arbitr devido aos atrasos arbitrérios nas operagdes de envio de um para um subjacentes. Essa falta de garantia de lordem nao ¢ satisfatéria para muitas aplicagdes. Por exemplo, em uma usina nuclear pode ser importante que os eventos que signifiquem ameagas as condigées de seguranga e os eventos que signifiquem agdes de unidades de controle sejam observados na mesma ordem por todos os processos do sister, Os requisitos de ordenagao comuns so: ordem total, ordem causal, ordem FIFO ¢ as misturas total-causal ¢ total-FIFO. Para simplificarmos nossa discussio. definiremos essas ordenagbes sob a suposigio de que todo proceso pertence no maximo a um grupo. Posteriormente, discutiremos as implicagdes resultantes de permitir que os grupos se sobreponham, Ordem FIFO: se um proceso correto executa multicast(g. m) € depois multicasi(g, m’), entao todo proceso correto que entregar m’ entregard m antes dem Ordem causal: se multicast(g, m) — multicast(g. m’), onde + € a relagio antes do acontecido induzida apenas pelas mensagens enviadas entre os membros de g, entio todo proceso correto «que entregar m' entregard m antes dem’ Ordem total: se um processo correto entregar a mensagem m antes de entregar m', ‘outro proceso correto que entregue m’ entregarim antes de mr. nto qualquer A ordem causal implica na ordem FIFO, pois quaisquer dois multicasts feitos pelo mesmo pro- cesso esto sujeitos a relagio antes do acontecido. Note que a ordem FIFO ¢ a ordem causal so ‘ordenagdes apenas parciais: em geral, nem todas as mensagens sio enviadas pelo mesmo proceso analogamente, alguns multicasts so concorrentes (ndo ordenados pela relagdo antes do acontecido), A Figura 12.12 ilustra as ordenagdes para o caso de trés processos. Uma inypecdo detalhada dla figura mostra que as mensagens totalmente ordenadas sdo enviadas na ordem oposta ao tempo fisico ‘em que foram enviadas. Na verdade, a definigdo de ordenagio total permite que a distribuigdo de mensagens seja ordenada arbitrariamente, desde que a ordem seja a mesma ein diferentes processos, Como a ordcnagdio total nao é necessariamente também uma ordenagio FIFO, ou causal, detinimos a mistura da ordenagao FIFO-total como aquela para a qual a distribuigdo de mensagens obedece a or- dem FIFO e a total; analogamente, sob a ordenagao causal-tota. distribuigio de mensagens obedece a ordenacao causal e a to ‘As definiges de multicast ordenado no presumem nem implicam em confiabitidade, Por exem- plo, o leitor deve verificar que, na ordenagio total, se 0 processo correto p entre} gem me ‘depois m', entdo um processo correto q poderd entregar m sem também entregar mou qualquer outra ‘mensagem ordenada aps m. Também podemos formar misturas dos protocolos ordenados ¢ confidveis. O multicast totalmente confidvel é freqiicntemente referido na literatura como multicast atdmico. Analogamente, podemos formar um multicast FIFO confiavel, um multicast causal confidvel e versdes confidveis de multicasis ‘ordenados mistos Ordenar a entrega de mensagens multicast, conforme veremos, pode ser dispendioso em termos de Jaténcia da distribuigdo de consumo de largura de banda. A semantica da ordenagio que descrevemos pode atrasar desnecessariamente a distribuigdo das mensagens. Isto €, no nivel aplicativo, uma mensagem pode ser retardada por outra mensagem da qual, na verdade, nao depende. Por isso, alguns t6n» proposto sistemas multicast que utilizam apenas a semintica de mensagem especttica & propria aplicagdo para determinar a ordem de distribuigdo de mensagens [Cheriton ¢ Skeen 1993, Pedone © Schiper 1999},