INSTITUTO DE COMPUTAÇÃO UNIVERSIDADE ESTADUAL DE CAMPINAS

Transcrição

1 INSTITUTO DE COMPUTAÇÃO UNIVERSIDADE ESTADUAL DE CAMPINAS Sub-Projeto 1: Multicast e Revisão Bibliográca E. B. Prata G. S. de Paula P. R. Costa R. Dominiquini Technical Report - IC Relatório Técnico March Março The contents of this report are the sole responsibility of the authors. O conteúdo do presente relatório é de única responsabilidade dos autores.

2 Sub-Projeto 1: Multicast e Revisão Bibliográfica Eduardo Jacob Prata Gustavo de Paula Paulo de Almeida Costa Rafael Baboni Dominiquini Resumo Neste artigo descrevemos diversos aspectos relativos ao multicast e broadcast, justificando o seu uso em sistemas distribuidos para evitar o uso de sistemas de nomes e redução de tráfego na rede. Além disso, descrevemos três artigos fundamentais na área de sistemas distribuídos que fazem uso de diretivas de multicast e que serão a base do desenvolvimento dos projetos desta disciplina. 1 Introdução Um método simples e mais eficiente para implementação de sistemas distribuídos em uma rede ethernet deve utilizar diretivas de multicast ou broadcast. Através do uso destas diretivas é possível alcançar todos os computadores ligados na rede local utilizando o envio de apenas uma mensagem ao invés de N mensagens na comunicação unicast. Além disso, o uso de broadcast facilita o problema da nomeação e localização de recursos no sistema, já que as entidades do sistema podem receber uma mensagem broadcast e então responder indicando sua presença e seus dados. Este artigo contém uma explicação concisa sobre multicast e broadcast, elucidando o seu funcionamento e o seu uso na Internet. Além disso, incluímos um resumo de três artigos fundamentais na área de sistemas distribuídos sobre os quais basearemos o desenvolvimento dos projetos da disciplina. 2 Multicast Nesta seção respondemos algumas questões relativas ao multicast e broadcast visando elucidar o que é como funciona este tipo de comunicação. E, por fim, fornecemos uma descrição sucinta sobre o estágio atual do multicast e broadcast no ambiente de internet. 2.1 Classes de endereços IP Os endereços IP foram originalmente repartidos em classes, de acordo com o número de bytes que identificam a rede e o número de bytes que identificam a máquina na rede. Nas próximas seções definimos cada uma das classes e mostramos ainda uma série de endereço Instituto de Computação, Universidade Estadual de Campinas, Campinas, SP. 1

3 2 Prata, De Paula, Costa e Dominiquini especiais. São ao todo 5 classes, porém, a classe E não é mostrada porque corresponde a uma faixa reservada a testes pela IETF (Internet Engineering Task Force) Classe A Num endereço IP de classe A, o primeiro byte representa a rede. O bit de sinal (o primeiro bit, da esquerda) tem valor zero, o que significa que há 27 ( à ) possibilidades de redes, quer dizer 128 possibilidades. Contudo, a rede 0 (bits que valem ) não existe e o número 127 é reservado para designar a sua máquina. Dentro da classe A, o intervalo é reservado para uso em redes locais, e pacotes com IPs neste intervalo não são roteados para a internet Classe B Num endereço IP de classe B, os dois primeiros bytes representam a rede. Os dois primeiros bits são 10, o que significa que há redes possíveis ( ao ). As redes disponíveis em classe B são por conseguinte as redes que vão de a Dentro da classe B, o intervalo é reservado para uso em redes locais, e pacotes com IPs neste intervalo não são roteados para a internet Classe C Num endereço IP de classe C, os três primeiros bytes representam a rede. Os três primeiros bits são 110, que significa que há redes possíveis. As redes disponíveis em classe C são por conseguinte as redes que vão de a Dentro da classe C, o intervalo é reservado para uso em redes locais, e pacotes com IPs neste intervalo não são roteados para a internet. Classe Início Fim Redes possíveis Máximo de computadores A B C Classe D Endereço IP de classe D são identificados pelos quatro primeiros bits, com valor Neste caso especial, o endereço IP não identifica uma rede/máquina, mas sim um grupo de multicast. Basta enviar um pacote para o IP escolhido, e todas as máquina do grupo receberão uma cópia do pacote (exceto por eventuais perdas de pacote), sendo que a transmissão destes é feita de forma eficiente através da coordenação semi-automática dos roteadores intermediários. A única diferença em relação a uma transmissão normal é que as máquinas destinatárias devem se juntar ao grupo desejado explicitamente, a fim de configurar os roteadores para retransmitir o pacote para todos membros do grupo. Essa configuração é feita através do

4 Multicast 3 protocolo IGMP, responsável por associar um endereço ao grupo desejado (join). Também é necessário renovar a associação periodicamente, caso contrário as configurações de roteamento são desfeitas Classes Especiais Além destas classes, existem outras faixas de endereço reservadas para classes especiais: Máscara de rede /8 Rede corrente /8 Rede Privada /8 Rede Pública /8 Reservado /8 Localhost /16 Reservado (IANA) /16 Zeroconf /12 Rede Privada /16 Reservado (IANA) /24 Documentação /24 IPv6 para IPv /16 Rede Privada /15 Teste de benchmark de redes /24 Reservado /4 Multicasts (antiga rede Classe D) /4 Reservado (antiga rede Classe E) Broadcast Atualmente, a separação entre rede e máquina não é feita apenas através das classes A, B e C, além do IP, usa-se uma máscara de rede escrita no mesmo formato do endereço IP. Ela possui 1 nos bits que identificam a rede e 0 nos bits que identificam a máquina. Alternativamente, a máscara também pode ser especificada apenas pelo número de bits que identificam a rede. Por exemplo, se temos o endereço , com máscara , os primeiros 24 bits do endereço identificam a rede ( ) e os 8 demais identificam a máquina. Também se escreve como / A relação entre o broadcast e o tráfego na Ethernet Ao se utilizar broadcast sobre Ethernet, apenas uma mensagem precisa ser enviada para que todas as máquinas que compartilham o meio possam recebê-la. Desta forma, uma mensagem endereçada apenas a uma máquina, causa o mesmo tráfego de rede que uma mensagem em broadcast. Caso a mensagem seja endereçada a mais máquinas, o trafego em unicast cresce linearmente, enquanto o tráfego em broadcast permanece constante. Portanto o uso de mensagens de broadcast não causa aumento do tráfego de rede como um todo. Na verdade, o trafego permanece constante ou diminui.

5 4 Prata, De Paula, Costa e Dominiquini Porém, devemos considerar o caso das redes ethernet comutadas, isto é, com meio físico não compartilhado, que é o caso mais comum atualmente. Nestas, uma mensagem em unicast congestiona apenas os segmentos de rede necessários para transportar o pacote ao seu destino. Já uma mensagem em broadcast irá congestionar todos os segmentos de rede. Para as máquinas de origem e destino do pacote, esse tráfego extra não faz diferença em relação a uma rede de meio compartilhado, pois os pacotes precisam trafegar o segmento de rede correspondente de qualquer maneira. Mas para as máquinas que não estão interessadas naqueles dados, o uso de broadcast congestiona desnecessáriamente os seus segmentos de rede. Portanto, em uma rede ethernet comutada, o uso de multicast irá diminuir o congestionamento para os computadores interessados na transmissão, mas irá congestionar os desnecessáriamente os computadores que não precisariam recebê-la. 2.3 Comunicação ponto-a-ponto na Ethernet PPPoE (Point-to-Point Protocol over Ethernet) é um protocolo de rede usado para encapsular quadros PPP (Point-to-Point Protocol) dentro de quadros Ethernet. Seu uso típico é nas conexões de um ou múltiplos usuários em uma rede LAN à Internet. Seu principal uso está relacionado à utilização de linhas DSL, onde o PPPoE encapsula os dados de um computador até a central telefônica. Derivado do PPP, permite acesso autenticado e transmissão de pacotes de diversos protocolos. Para a Internet, o PPP encapsula o protocolo TCP/IP. 2.4 Obtenção de endereço broadcast em UNIX O comando ifconfig deve ser utilizado para obter informações de rede. Entre outras informações, podemos ver se a interface de rede suporta envio de pacotes em broadcast pela presença da flag BROADCAST, e o endereço de broadcast da rede local pelo campo Bcast: $ ifconfig eth1 Link encap:ethernet HWaddr 00:1C:C0:1C:B1:F6 inet addr: Bcast: Mask: inet6 addr: fe80::21c:c0ff:fe1c:b1f6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets: errors:0 dropped:2 overruns:0 frame:0 TX packets: errors:66873 dropped:0 overruns:0 carrier:66873 collisions:78219 txqueuelen:100 RX bytes: (126.1 MiB) TX bytes: (182.4 MiB) Memory:e e lo Link encap:local Loopback inet addr: Mask: inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1511 errors:0 dropped:0 overruns:0 frame:0 TX packets:1511 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0

6 Multicast 5 RX bytes: (193.2 KiB) TX bytes: (193.2 KiB) Alternativamente, pode-se utilizar o endereço , que é um endereço especial para enviar broadcasts na rede local. 2.5 Broadcast nos laboratórios do IC Cada um dos laboratórios possui um endereço de rede distinto, e, consequentemente, um endereço de broadcast distinto. A sala 303 possui endereço /26, broadcast , a sala 304 possui endereço /26, broadcast e a rede onde está a máquina Xaveco possui endereço de rede /26, broadcast Para fazer os testes desenvolvemos uma classe java para o envio e recebimento das diretivas de Broadcast e Multicast, esta classe pode ser consultada no diretório do projeto. Como as redes e os endereços de broadcast são distintos, não foi possível enviar um pacote que fosse entregue em todas as salas. Mas foi possível enviar um pacote de broadcast de uma sala para outra, isto é, enviado da sala 303 para o endereço de broadcast da sala 304, e recebido com sucesso na outra sala. Dessa forma, se for necessário enviar um pacote para todas as máquinas de algumas salas, só será necessário enviar um pacote por sala utilizando broadcast, ao invés de um pacote por máquina, como seria necessário com Unicast. Tentamos contornar essa restrição utilizando endereços de multicast, mas estes não parecem funcionar dentro da rede do IC, os pacotes enviados são recebidos apenas pela máquina que os enviou. O mesmo código funciona em outras redes, portanto acreditamos que seja uma restrição de segurança do IC. Também tentamos enviar pacotes de broadcast a partir de computadores remotos, mas a configuração das redes do IC impediu o recebimento dos pacotes. 2.6 Multicast e Broadcast na Internet Abcdefghijklmnopqrstuvxwyz. 3 Revisão Bibliográfica 3.1 Time, clocks and the ordering of events in a distributed system. Leslie Lamport, 1978 Em seu artigo seminal, Lamport [3] define o conceito de relógios lógicos utilizados para sincronização de sistemas distribuídos. Neste artigo é mostrado um algoritmo distribuído para sincronizar um sistema de relógios lógicos que pode ser utilizado para gerar uma ordenação total de eventos. O uso da ordenação total é ilustrado com um método para resolver problemas de sincronização. O algoritmo é então especializado para sincronizar relógios físicos e se chega um limite da máxima assíncronia entre os relógios. A ordenação de eventos em sistemas distribuídos é um problema complicado, isto ocorre porque os computadores que formam o sistema não compartilham o mesmo relógio físico,

7 6 Prata, De Paula, Costa e Dominiquini às vezes se torna impossível dizer qual evento ocorreu antes do outro. A relação aconteceu antes é apenas uma ordenação parcial dos eventos. Esta relação pode ser definida sem o uso de relógios físicos. Os eventos dentro de um mesmo processo são totalmente ordenados a priori. A relação aconteceu antes ( ) pode ser definida pelas 3 regras a seguir: 1. Se (a) e (b) ocorrem no mesmo processo, e (a) ocorre antes de (b), então a b. 2. Se (a) é o envio de uma mensagem e (b) é seu recebimento, então a b. 3. Se a b e b c então a c. Dois eventos são ditos concorrentes se a b e b a são ambos falsos. A relação a b demonstra que a pode afetar b de maneira causal. Dois eventos são concorrentes se nenhum dos dois pode se afetar causalmente. Esta relação e suas definições permitem ordenar parcialmente os eventos de um sistema distribuído. Relógios lógicos são introduzidos para que se possa gerar uma ordenação total dos eventos. Um relógio lógico é definido como uma função monotonicamente crescente que atribui um valor numérico para cada evento no processo. O valor da função do relógio lógico é o tempo lógico concatenado com o número do processo. Podem ser implementados de maneira simples com contadores, porque tem um significado lógico e não físico. Para um sistema de relógios estar correto a seguinte relação deve valer: Relação de Relógio: Para quaisquer eventos a e b: Se a b então C(a) < C(b). Partindo da relação vemos que as duas condições devem valer: C1: Se a e b são processos em P i e a vem antes de b então C(a) < C(b). C2: Se a é o envio de uma mensagem por P i e b é o recebimento desta mensagem por P j então C(a) < C(b). Para garantir que a condição vale temos apenas que utilizar duas regras: 1. O processo P incrementa seu relógio a cada evento. Satisfaz C1. 2. A cada recebimento de uma mensagem de P i por P j contendo timestamp C i < a >, P j coloca seu relógio como sendo o máximo entre seu relógio atual e C i < a > e incrementa seu relógio. Satisfaz C2. Uma relação total dos eventos é obtida apenas utilizando a ordem com que eles ocorrem. A ordenação parcial é acrescida do poder dos relógios lógicos e das regras R1 e R2 além de utilizar o número do processo para desempate, de forma que nunca temos dois eventos simultâneos. Esta ordenação total não necessita ter uma relação direta com a ordem física de ocorrência dos eventos e pode mudar se o sistema de relógios for alterado, mas permanece consistente. O uso de sistemas de relógios lógicos para resolver problemas de sincronização em sistemas distribuídos é muito importante e é demonstrada por Lamport em seu artigo ao resolver o problema da exclusão mútua distribuída. O algoritmo trabalha com três condições:

8 Multicast 7 1. Um processo ao qual foi dado um recurso deve liberá-lo antes que o recurso possa ser dado a outro processo. 2. Diferentes pedidos de recurso devem ser dados na ordem em que foram pedidos. 3. Se cada processo ao qual é dado um recurso o libera, então cada pedido é eventualmente tratado. Estas condições caso respeitadas garantem safety e liveness para o algoritmo, ou seja, ele é seguro e, eventualmente, progride. Não é trivial resolver este problema de maneira distribuída, sem um gestor de recursos centralizado. Utilizando as regras R1 e R2 podemos estabelecer uma ordenação total entre os pedidos de recurso e o problema fica simples, basta fazer com que os processor fiquem sabendo sobre os pedidos uns dos outros. Assumimos que os canais de comunicação são FIFO e também que cada mensagem é recebida algum dia. Também assumimos que cada processo pode enviar mensagens diretamente para todos os outros processos, ou seja, o grafo de comunicação é completo. Cada processo mantém sua fila de requisições que não é vista pelos outros processos e que a fila contém inicialmente a mensagem T 0 : P 0 requests resource, onde P0 é o processo que ganhou o recurso inicialmente e T 0 é menor que o valor inicial de qualquer relógio. O algoritmo é definido por 5 regras básicas descritas em pseudo-código abaixo: /* Algoritmo de Exclusao Mutua de Lamport. * O codigo e exatamente o mesmo para todos os processos. /* Implementa as diretivas de broadcast para envio de mensagens e as diretivas * de unicast para envio do ack. * Funcoes: sendmessage e sendackunicast. import BcastService; /* Implementa a fila de mensagens, ordena do mais antigo para o mais recente, * assim os pedidos sao respondidos na ordem com que chegaram. * Funcoes: put e removeall. import MessageQueue; /* Implementa o relogio logico de Lamport e todas as funcoes de atualizacao * e incremento. * Funcoes: tickclock e updateclock. import Clock; class LamportMutex { ProcessNumber pid; MessageQueue queue; BcastService bcast; Clock clock;

9 8 Prata, De Paula, Costa e Dominiquini LamportMutex(ProcessNumber pid) { bcast = new BcastService(); queue = new MessageQueue(); clock = new Clock(); this.pid = pid; workflow(); void workflow() { /* Enquanto o processo estiver em execucao ouve por novos * pedidos de acesso e mensagens enviadas por outros processos. * Chama as demais funcoes para tratar o recebimento e envio de mensagens. Message createmessage(type t) { /* Cria mensagem com tipo pedido, numero do processo * e anexa timestamp Tm:Pi /* REGRA 1 void requestresource() { /* Avanca o relogio, cria uma mensagem de pedido com timestamp igual ao relogio atual * e entao a envia por broadcast para todos os outros processos e apenas no fim * insere na fila de mensagens. tickclock(); Message msg = createmessage(request); bcast.sendmessage(msg); queue.put(msg); /* REGRA 2 void receiverequestmsg(message msg) { /* Atualiza seu relogio, coloca a mensagem em sua fila de mensagens e envia * um ack para o processo que enviou o pedido. Ao fim verifica se pode entrar updateclock(msg.timestamp); queue.put(msg); bcast.sendackunicast(msg.process, msg); /* REGRA 3 void releaseresource() { /* Saida da regiao critica, atualiza seu relogio, remove todos os pedidos com seu pid

10 Multicast 9 * que estejam na fila e envia uma mensagem de release para os outros processos. tickclock(); queue.removeall(pid); msg = createmessage(release); bcast.sendmessage(msg); /* REGRA 4 void receivereleasemsg(message msg) { /* Atualiza o relogio e entao remove as mensagens de pedido de recurso do processo * que enviou o release. updateclock(msg.timestamp); queue.removeall(msg.process); /* REGRA 5 boolean checkresource() { /* Verifica se o seu pedido e o mais antigo e verifica se recebeu * pelo menos uma mensagem de cada outro processo com timestamp mais recente * que o seu. boolean canaccess = true; if (queue.head.process == pid) { for each (Process p) { if (! queue.containsmsg(p)) canaccess = false; else { canaccess = false; É fácil demonstrar que o algoritmo satisfaz as condições I-III descritas acima. A condição de que o processo deve ter visto mensagens mais recentes de todos os outros processos, em conjunto com a suposição que as mensagens são recebidas em ordem, garante que o processo Pi conhece todos os outros pedidos que precedem o seu. Como as regras 3 e 4 são as únicas que apagam pedidos da fila é fácil ver que a condição I é satisfeita, ou seja, o processo deve liberar o recurso antes que outro possa utilizá-lo. A condição II é satisfeita vendo que as mensagens do sistema estão totalmente ordenadas, ou seja, todos os processos do sistema enxergam a mesma ordenação dos pedidos. A regra 2 (recebimento de pedido) e a regra 4 (recebimento de release) garantem que o processo irá receber pelo menos uma mensagem mais recente dos outros processos e que todos os pedidos anteriores ao seu eventualmente

11 10 Prata, De Paula, Costa e Dominiquini serão liberados, então chegará um momento em que seu pedido será o mais antigo e será dado acesso, provando a condição III. Lamport segue demonstrando que o funcionamento deste algoritmo distribuído em que cada processo funciona de maneira independente pode ser representado por uma máquina de estados, formada por um conjunto de comandos e estados. A sincronização da máquina de estados é obtida porque pela ordenação total cada processo ordena sua fila pelos timestamps das mensagens e, portanto, executa a mesma sequência de comandos. Utilizando esta idéia de máquina de estados e o funcionamento básico do algoritmo de sincronização, é possível implementar qualquer forma de sincronização de múltiplos processos em um sistema distribuído. O algoritmo proposto por Herman e Verjus [2] descrito em outra seção segue esta mesma idéia. No restante do artigo Lamport deriva o uso de relógios lógicos para sincronizar relógios físicos e, através do desenvolvimento de diversas equações, chega em um limite para o atraso máximo entre os relógios ao se utilizar este método de sincronização. 3.2 An algorithm for maintaining the consistency of multiple copies. D. Herman e J. P. Verjus, 1979 Herman e Verjus [2] descrevem em seu artigo um algoritmo que, basicamente, estende a idéia de Lamport para implementar consistência entre cópias de dados distribuídos em diversos processos. Os pressupostos para o algoritmo são os mesmos dos fornecidos por Lamport e seu funcionamento é uma estensão ao algoritmo de exclusão mútua dado por Lamport. O sistema é formado por um conjunto de processos em que cada um deles possui uma cópia do banco de dados, com o objetivo de reduzir o turn-around de cada site e melhorar a disponibilidade do sistema. Com isso os usuários podem requisitar os dados de qualquer um dos bancos e obter o mesmo resultado, sem ter de saber que estão acessando dados de outros servidores, para os usuários a imagem é que os dados estão em apenas um servidor. Este é o mesmo príncipio da replicação para aumento de desempenho em sistemas distribuídos. Muitos algoritmos foram propostos para garantir consistência mútua de cópias redundantes mas o algoritmo proposto maximiza o paralelismo evitando o uso de locks globais. O sistema trabalha com filas de requisições, levando isso em conta são previstas as seguintes transações: Estimativa: retorna o valor atual do dado no site em questão, não é necessário que seja um valor consistente com os demais sites, é apenas uma estimativa. Pode também ser chamado de leitura rasa. Leitura: o valor só pode ser retornado quando chega ao topo da fila de requisições, isto garante que todas as operações relativas ao item já foram efetuadas. Escrita: a escrita é efetuada quando chega ao topo da fila, é semelhante à leitura. Atualização: uma transação é inserida na fila, e quando ela chega ao topo a fila é travada e é aplicada uma sequência de operações de leitura e escrita, o processo termina quando a mensagem de fim de transação é encontrada.

12 Multicast 11 As transações são ordenadas globalmente pelas condições de relógio dadas por Lamport [3], utilizando relógios lógicos em cada processo e aplicando-se timestamps às requisições. A ordem de tempo físico não precisa ser obedecida, mas todas as requisições devem ser aplicadas na mesma ordem em todos os sites, de acordo com a ordenação total provida pelos timestamps das requisições. Consistência neste caso é dada nos termos em que os dados podem diferir ao longo do tempo, mas eventualmente, quando toda atividade cessar, o sistema deve convergir para um estado consistente em que todas as cópias são idênticas. Isto ocorre porque ao fim das atividades as mensagens em trânsito em todo o sistema irão chegar e serão processadas, portanto, em um momento não haverá mais mensagens em trânsito e o sistema terá convergido. A explicação sobre ordenação de requisições é a mesma fornecida por Lamport, seguindo as condições de relógio e regras fornecidas para ordenação total. A base do algoritmo é um programa em cada site chamado REGISTRAR que obedece um conjunto de regras bem definidas. Ele responde imediatamente a pedidos de estimativa e aplica as regras para os outros tipos de pedidos. O formato das mensagens trocadas entre os processos é a seguinte <tipo da mensagem, parâmetros, timestamp>. O tipo da mensagem pode também ser uma transação. O algoritmo é descrito em pseudo-código a seguir: /* Algoritmo de Replicacao consistente de Herman e Verjus, * O codigo e exatamente o mesmo para todos os processos. /* Implementa as diretivas de broadcast para envio de mensagens e as diretivas * de unicast para envio do ack e enquiry. * Funcoes: sendmessage, sendackunicast e sendenquiry. import BcastService; /* Implementa a fila de mensagens, ordena do mais antigo para o mais recente, * assim os pedidos sao respondidos na ordem com que chegaram. * Funcoes: put e removeall. import MessageQueue; /* Implementa o relogio logico de Lamport e todas as funcoes de atualizacao * e incremento. * Funcoes: tickclock e updateclock. import Clock; class Registrar { ProcessNumber pid; MessageQueue queue[]; BcastService bcast; Clock clock; /* Principal diferenca com relacao a Lamport, dado Data item;

13 12 Prata, De Paula, Costa e Dominiquini /* Marca se esta dentro de uma transacao boolean trans = false; Registrar(ProcessNumber pid) { bcast = new BcastService(); queue = new MessageQueue[numberProcesses]; for (int i = 0; i < numberprocesses; i++) queue[i] = new MessageQueue(); clock = new Clock(); this.pid = pid; workflow(); void workflow() { /* Enquanto o processo estiver em execucao ouve por novas operacoes * e mensagens enviadas por outros processos. * Chama as demais funcoes para tratar o recebimento e envio de mensagens. * Chama "checkqueues" ao fim de cada iteracao. Message getoldest(queue[] queue) { /* Retorna a mensagem mais antiga de todas as filas e faz * um pop da mensagem. * Se "trans" for true, retorna da mais antiga a mensagem com * numero de transacao menor, para respeitar ordem da transacao. void checkqueues() { /* Verifica por filas vazias e envia enquiries se preciso boolean vazia = false; for (Queue q : queue) { if (q.empty()) { requestenquiry(q.process); vazia = true; /* Encontra fila cujo topo tem a mensagem mais antiga if (vazia == false) { Message maisantiga = getoldest(queue); switch (maisantiga.type) { case write: item = maisantiga.value; break; case read: maisantiga.thread.sendvalue(item); break;

14 Multicast 13 case beginupdate: /* Apenas trata restante das mensagens de transacao trans = true; break; case finishupdate: /* Marca fim da transacao, elimina estruturas criadas para transacao trans = false; break; Message createmessage(type t) { /* Cria mensagem com tipo pedido, numero do processo, * e anexa timestamp Tm:Pi Message createmessage(type t, int value) { /* Cria mensagem com tipo pedido, numero do processo, * valor e anexa timestamp Tm:Pi void requestwrite(int value) { /* Enfileira o pedido de escrita e envia por broadcast * para que todos os outros processos possam realizar a * escrita. tickclock(); Message msg = createmessage(write, value); bcast.sendmessage(msg); queue[pid].put(msg); void receivewrite(message msg) { /* Atualiza seu relogio com o timestamp da mensagem e coloca * a mensagem em sua fila local. updateclock(msg.timestamp); queue[pid].put(msg); void requestenquiry(int process) { /* Caso a fila do processo J esteja vazia precisa enviar um * pedido para o processo para preencher sua fila com um ack. tickclock();

15 14 Prata, De Paula, Costa e Dominiquini Message msg = createmessage(enquiry); bcast.sendenquiry(msg.process, msg); void receiveenquiry(message msg) { /* Responde a um enquiry enviando um ack para o processo * requisitante. updateclock(msg.timestamp); queue[msg.process].put(msg); bcast.sendackunicast(msg.process, msg); void receiveack(message msg) { /* Enfileira o ack do processo updateclock(msg.timestamp); queue[msg.process].put(msg); void requestread() { /* Avanca o relogio, cria a mensagem de leitura e a enfileira * em sua fila, nao precisa enviar para os outros porque nao * altera os dados. tickclock(); Message msg = createmessage(read); queue[pid].put(msg); void requestupdate(list<message> operations) { /* Avanca o relogio, enfileira mensagem de inicio de atualizacao, * operacoes e mensagem de fim de atualizacao. Todas as mensagens da * transacao tem o mesmo timestamp, diferindo apenas seu numero, com isso * se consegue que elas sejam executadas em conjunto sem nenhuma outra operacao * entre elas. A lista operacoes contem todas as operacoes da transacao. tickclock(); /* Envia mensagem de inicio da atualizacao. Tipo beginupdate bcast.sendmessage(operations.head); queue[pid].put(operations.head); for (Message msg : operations) { /* So precisa enviar mensagens de write if (msg.type == write) bcast.sendmessage(msg); queue[pid].put(msg); /* Envia a mensagem de fim da atualizacao. Tipo finishupdate bcast.sendmessage(operations.tail);

16 Multicast 15 queue[pid].put(operations.tail); Pela ordenação total das mensagens no sistema e pelo fato de que as mensagens enviadas por um mesmo processo são entregues na ordem com que foram enviadas, a prova de consistência é a mesma dada por Lamport [3]. Dada a característica FIFO dos canais basta que o site conheça pelo menos uma mensagem de cada um dos outros sites para poder decidir se pode ou não processar alguma requisição, para isto entram em ação as mensagens de enquiry e acknowledge. 3.3 Chandy e Lamport Abcdefghijklmnopqrstuvwxyz. [1] Referências [1] M. Chandy and L. Lamport. Distributed snapshots: determining global states of distributed systems. Transactions on Computer Systems, 3(1):63 75, [2] D. Herman and J. P. Verius. An algorithm for maintaining the consistency of multiple copies. In Proceedings of the 1st International Conference on Distributed Computing Systems, pages , Washington, DC, IEEE Computer Society. [3] L. Lamport. Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, 21(7): , July 1978.