Sistemas Operacionais Distribuídos e de Redes

Transcrição

1 Sistemas Operacionais Distribuídos e de Redes Notas de Aula /2 Profa. Patrícia Kayser Vargas 3 Comunicação em Sistemas Distribuídos 3.1 Troca de Mensagens Assunto que já foi abordado em Sistemas Operacionais II. Mensagem pode ser entendida como um objeto de dados cuja estrutura e aplicação são definidas pelas aplicações. A troca de mensagens é feita através de primitivas explícitas de comunicação: send(destino, msg) envio da mensagem msg para destino receive(origem, msg) recebimento da mensagem msg enviada por origem Essas primitivas podem ser classificadas do seguinte modo: Tabela 3.1 Classificações das primitivas de comunicação. Forma de comunicação Direta send: há indicação do processo receptor send(processo, msg) receive: há indicação do emissor receive(processo, msg) Forma de sincronização Síncrona ou bloqueante send: espera até que a mensagem seja recebida pelo receptor receive: aguarda até a mensagem estar disponível Indireta send: envio para uma porta ou mailbox sem conhecimento de qual será o receptor send(mailbox, msg) receive: obtenção da mensagem guardada no mailbox, possivelmente desconhecendo a identidade do processo emissor receive(mailbox, msg) Assíncrona ou não bloqueante send: envia mensagem, mas não espera até que seja recebido pelo receptor receive: se a mensagem estiver disponível, recebe a mensagem, caso contrário continua a processamento retornando uma indicação de que a mensagem não estava disponível Um sistema pode possuir diferentes combinações desses tipos de primitivas. Um sistema de comunicação é dito síncrono se ambas as primitivas, isto é, tanto send quanto receive, forem do tipo bloqueante. Por outro lado, um sistema de comunicação é dito assíncrono se pelo menos uma das primitivas for assíncrona. A principal desvantagem dessa abordagem é o baixo nível de abstração que permite apenas a modelagem de troca direta de informação entre processos.

2 3.2 Modelo Cliente/Servidor É um paradigma de programação que representa as interações entre os processos e as estruturas do sistema. Nesse tipo de paradigma existem dois tipos de processos: clientes: processos que requisitam serviços; es: processos que recebem requisições, realizam uma operação e retornam serviços Em um modelo cliente/, o processo cliente necessitando de um serviço (por exemplo ler dados de um arquivo) envia uma mensagem para o e espera pela mensagem de resposta. O processo, após realizar a tarefa requisitada, envia o resultado na forma de uma mensagem de resposta ao processo cliente. Note que os es apenas respondem as requisições dos clientes, e, tipicamente, não iniciam conversação com os clientes. A principal vantagem dessa abordagem é a simplicidade mas a implementação em princípio é menos eficiente do que na troca de mensagens pura. A figura (A) abaixo mostra como é a comunicação lógica: envio de requisição (mensagem request) e recebimento do resultado (mensagem reply). De fato, a implementação ocorre como na figura (B) onde a troca de mensagem é feita via do sistema operacional request request cliente cliente reply reply (A) Rede Rede Figura 3.1 (a) Visão lógica da comunicação cliente/; (b) Troca de mensagens que possibilita a comunicação cliente/. (B) cliente 1 request cliente 2... cliente n recurso Figura 3.2 Possibilidade de vários clientes acessarem um recurso de forma consistente e transparente através do uso de um. Também é possível termos um ambiente com múltiplos es. Esses es podem ser ditos replicados quando são várias instâncias do mesmo, e podem ser replicados por questões de desempenho, distribuição natural dos recursos ou por tolerância a falhas. Também é possível termos es hierárquicos, isto é, um que usa serviços de outros es. Nesse tipo de ambiente, as localizações e conversações entre es deveriam ser transparentes aos clientes Endereçamento No nível de usuário, tem-se a noção de um envio de requisição a um específico, mas para que um cliente envie mensagens para um ele deve conhecer o seu endereço. Deste modo, é preciso estabelecer um esquema de identificação única do processo :

3 Opção 1 um identificador único de processo quando na mesma máquina: com um único processo por máquina basta indicar o endereço da máquina pois o consegue determinar qual é o processo único. Isso não é uma abordagem viável, pois dificilmente teremos um único processo em uma máquina. Opção 2 endereçamento indicando o processo e a máquina: quando se permite mais de um processo por máquina, deve-se endereçar a mensagem a esse específico. Um esquema comum é o uso de um nome composto por duas partes. Por exemplo, ou 4@243 indicaria o processo 4 na máquina 243. Assim, o da máquina cliente usa o número 243 para enviar a máquina correspondente e com o número 4 o remoto determina para qual a mensagem é endereçada. Nessa abordagem a identificação é incluída no código do cliente. Com isso evita-se o custo de coordenação global e evita-se ambigüidades entre processos com identificador idênticos mas em máquinas distintas. Entretanto, perde-se em transparência pois é preciso que o cliente conheça a localização física do. Isso pode causar problemas, como por exemplo, se um de banco de dados normalmente executa na máquina 243, no dia que ela for desligada para realizar manutenção, pode-se disponibilizar o serviço na máquina 177. Se um cliente estiver usando esse esquema fixo, apesar do serviço estar disponível, o cliente não poderá acessar o. Opção 3 processos escolhem endereços que são detectados por broadcast: Cada processo deve receber um endereço único que não envolva o número da sua máquina. Esse endereço pode ser atribuído de duas formas:! através de um alocador de endereços de processo centralizado, que mantém um contador e ao receber uma requisição incrementa esse contador e envia o valor. A principal desvantagem é a utilização de um componente centralizado que compromete a tolerância a falhas e a escalabilidade;! cada processo escolhe um valor aleatoriamente a partir de um espaço de endereçamento grande (por exemplo 64 bits) e portanto com pouca probabilidade de colisão. O emissor de uma requisição pode localizar para qual máquina enviar através do seguinte procedimento: (1) o emissor envia uma mensagem para todas as máquinas (broadcast) com um pacote especial de localização contendo o endereço do processo destino; (2) em cada máquina da rede o verifica se o processo está na sua máquina. Quem localizar envia mensagem indicando seu endereço na rede; (3) o emissor guarda essas informações para requisições futuras. Essa abordagem tem como vantagem ser transparente mas tem um custo da mensagem broadcast. Opção 4 uso de de nomes: nesse esquema os es são indicados por um identificador de alto nível (nome ASCII) que não inclui nem identificação da máquina nem do processo. Quando um cliente executa uma requisição a um pela primeira vez, uma mensagem especial é enviada para um de mapeamento ou de nomes solicitando o número da máquina onde o

4 cliente 1 2 cliente (A) 1 request to reply to (B) 1 broadcast 2 here I am 3 request 4 reply 3 4 cliente 1 2 Name server (C) 1 NS lookup 2 NS reply 3 request 4 reply Figura 3.3 Formas de endereçar o : (a) endereçamento indicando o processo e a máquina; (b) endereços detectados por broadcast; (c) uso de de nomes Primitivas confiáveis e não confiáveis Se as mensagens envolvidas na comunicação cliente/ forem assumidas como não confiável, recairá ao usuário a tarefa de controlar possíveis perdas de mensagem. Isso não é desejável uma vez que o objetivo é tornar o mais transparente possível para o usuário. É, portanto, desejável que o do SO se preocupe em verificar se as mensagens foram corretamente recebidas garantindo dessa forma uma comunicação confiável. A figura abaixo ilustra dois protocolos para garantir a confiabilidade através do uso de mensagens especiais do tipo acknowledgment. cliente request(1) reply (3) cliente request(1) reply (2) ack (2) ack (4) ack (3) (A) Figura 3.4 Uso de mensagens de acknowledgment para garantir comunicação confiável. Normalmente tem-se uma implementação mista, do seguinte modo:! quando a requisição chega no do, um temporizador é inicializado.! se o enviar a mensagem rápido o suficiente, a resposta funcionará como uma confirmação (ACK), senão, um ACK separado é enviado antes do envio da resposta. Nesse caso, a maior parte das requisições é completada com apenas duas mensagens, mas quando uma requisição complexa for requisitada, serão necessárias três mensagens. (B)

5 3.3 Chamada Remota de Procedimento (RPC) Chamada Remota de Procedimento (Remote Procedure Call RPC) permite que programas invoquem procedimentos ou funções localizados em outras máquinas como se ele estivesse localmente definido. No nível do programa, as informações são passadas do chamador para o procedimento chamado através de parâmetros e resultados são retornados através do resultado do procedimento. Deste modo, nenhuma mensagem ou entrada/saída é visível ao programador. Apesar de simples e elegante esse paradigma tem como problemas potenciais os seguintes pontos:! chamador e chamado executam em espaços de endereçamento distintos;! como fazer a passagem de parâmetros e resultados quando máquinas com arquiteturas distintas;! possibilidades de falhas Operação RPC Básica Inicialmente vamos revisar como é realizada uma chamada de procedimento convencional, isto é, em uma linguagem e máquina seqüenciais. Vamos supor a chamada em linguagem C count = read(fd, buffer, nbytes), sendo o primeiro argumento um descritor de arquivo, o segundo um array de caracteres e o último um inteiro. Teríamos nesse caso na pilha de ativação a seguinte seqüência de valores: Variáveis locais da função main SP Variáveis locais da função main Variáveis locais da função main SP nbytes buffer fd end retorno variáveis locais de read SP (a) antes chamada da função read (b) durante execução da função read (c) após chamada da função read Note que os parâmetros são empilhados de modo a que o primeiro argumento esteja no topo da pilha facilitando o acesso aos dados. A forma como esses parâmetros serão empilhados (tratados) define três tipos de passagens de parâmetros:! Chamada por valor (call-by-value): o valor do parâmetro é copiado para a pilha; o procedimento pode alterar o valor da forma que desejar que tal mudança não será refletida na variável original após o retorno da função;! Chamada por referência (call-by-reference): o endereço do parâmetro é copiado para a pilha; quando o procedimento alterar uma variável, esse valor será mantido no retorno da chamada uma vez que a alteração é feita diretamente na variável original;! Chamada por cópia e restauração (call-by-copy/restore): a variável é copiada para a pilha (como se fosse em uma chamada por valor) e no retorno da chamada o valor alterado sobrescreve o valor original (como se fosse uma chamada por referência)

6 Note que a chamada por cópia e restauração normalmente atinge o mesmo efeito da chamada por referência. Porém, em algumas situações a semântica não é a mesma, como, por exemplo, quando uma mesma variável for passada como mais de um parâmetro. No caso das implementações RPC, via de regra usa-se chamada por valor ou por cópia e restauração. Como um dos princípios do RPC é tornar a chamada de um procedimento remoto parecer o máximo possível com uma chamada local. Por isso, utiliza-se a estrutura de clientes e es stubs. Máquina Cliente Máquina Servidora call Cliente 1 unpack pack 5 parameter call parameters Stub Stub Servidor Cliente 2 4 Servidor KERNEL 3 KERNEL Máquina Cliente Máquina Servidora call Cliente return 1 unpack pack 5 parameter call parameters Stub Stub Servidor Cliente 2 4 Servidor 10 unpack pack 6 return results results KERNEL KERNEL Figura 3.5 Passos realizados para executar uma chamada remota. Conforme ilustrado na figura acima, uma chamada remota de procedimentos segue os seguintes passos: 1. O procedimento remoto chama o stub cliente da forma normal, isto é, como se fosse um procedimento local qualquer; 2. O stub cliente constrói a mensagem e passa ao ; 3. O envia a mensagem ao remoto; 4. O remoto entrega a mensagem ao stub ; 5. O stub desempacota os parâmetros e chama o ; 6. O realiza o trabalho solicitado e envia o resultado ao stub ; 7. O stub empacota o resultado em uma mensagem e passa para o ; 8. O remoto envia mensagem ao cliente; 9. O do cliente entrega a mensagem ao stub cliente; 10. O stub desempacota o resultado e retorna ao cliente.

7 O efeito da execução de todos esses passos é a conversão da chamada local de um cliente a um stub cliente em uma chamada ao procedimento sem que o cliente ou o percebam os passos intermediários. Via de regra os stubs são gerados automaticamente por um compilador. Essa operação básica do RPC indica alguns aspectos e problemas interessantes que serão tratados nas próximas seções. (a) Passagem de Parâmetros É preciso tratar a passagem de parâmetros e a conversão de dados. Isso é feito pela operação de empacotamento de parâmetros (parameter marshalling). Essa operação trata problemas de representação distinta de dados (números/caracteres) para máquinas heterogêneas;. Tanto o cliente quanto o sabem os tipos de parâmetros passados (identificador do procedimento + parâmetros) e devem conseguir obter a representação correta dos dados. Alternativa 1: uso de um padrão de representação de dados, como por exemplo o XDR do RPC Unix. Essa alternativa é muito interessante por permitir a comunicação entre máquinas heterogêneas. A desvantagem é que entre máquinas homogêneas não haveria a necessidade de incluir um custo adicional de conversão da representação da máquina para a representação do padrão. Alternativa 2: a mensagem é enviada no formato nativo com indicação de qual o formato utilizado. O receptor deve fazer a conversão quando for o caso. Essa alternativa evita custos de conversão em ambientes homogêneos, entretanto exige que clientes e es saibam converter qualquer formato para a sua representação nativa. (b) Passagem de Ponteiros Um ponteiro representa um endereço de memória que não tem nenhum significado na máquina remota. Alternativa 1: proibir a passagem de ponteiros. Essa obviamente não é uma alternativa desejável pelo programador; Alternativa 2: Copiar o valor apontado pela variável ponteiro. As alterações são feitas remotamente e no retorno as alterações são atualizadas no chamador (semântica cópia/restauração). Uma otimização possível consiste em, sabendo que um determinado parâmetro é apenas de entrada, evitar o retorno do conteúdo do ponteiro. De forma análoga, se ele for apenas de saída, ele não precisa ser copiado no envio. Esse tipo de informação pode ser fornecido pelo programador ou extraído a partir da análise do código fonte (análise estática). (c) Semântica RPC na Presença de Falhas Na execução de uma chamada remota de procedimento, existem cinco classes diferentes de falhas possíveis. 1. O cliente não consegue localizar o Tal situação pode ocorrer devido a dois motivos: ou o caiu ou o cliente e o estão executando versões incompatíveis de protocolo impedindo a sua comunicação. A melhor forma de tratar tal erro é através do uso no programa de tratamento de exceções. Uma exceção é um procedimento especial que é invocado pelo sistema no caso de uma falha (exceção) ser detectada. Esse tipo de solução torna o código mais claro e fácil de dar manutenção do que o uso de um código de retorno de função. O principal problema é que nem todas as linguagens prevêem o tratamento de exceção. Além disso, a inclusão de tratamento de exceção acaba com a ilusão de que procedimentos remotos não diferem dos locais.

8 2. Mensagem de requisição perdida: A mensagem de requisição do cliente para o pode ser perdida. O do Sistema Operacional deve controlar, através de timeout e ao detectar a perda, reenviar a mensagem. 3. A mensagem de resposta perdida: A mensagem de resposta do para o cliente pode ser perdida e nesse caso é um pouco mais difícil de tratar. Com o uso de timeout o do cliente não pode determinar o porquê da ausência de resposta: a mensagem de resposta pode ter sido perdida, ou a mensagem de requisição foi perdida ou então se tem apenas um muito lento. O reenvio de requisição pode causar erros caso o procedimento remoto não seja idempotente. Um procedimento idempotente (idempotent) é aquele cuja execução não causa efeito colateral. Por exemplo, ler um determinado bloco de um arquivo. Para resolver esse impasse, pode-se numerar as requisições o que permite que o identifique e possivelmente ignore uma retransmissão. 4. O cai após receber uma requisição: Esse tipo de falha também está relacionado a semântica idempotente ou não idempotente de um procedimento. requisição Servidor requisição Servidor requisição Servidor receive execute reply receive execute crash receive crash resposta não há resposta não há resposta (a) (b) (c) Figura 3.6 (a) execução normal no ; (b) falha no após a requisição ter sido realizada; (c) falha no após receber requisição, mas antes de iniciar execução. Note que na figura acima temos dois pontos onde pode ocorrer falha no após a requisição ter sido recebida. No caso (b) houve a execução da requisição, mas o resultado não será enviado ao cliente, enquanto no caso (c) a requisição não chegou a ser processada. Logo, no caso (b) a requisição somente poderá ser reexecutada se o procedimento for idempotente, enquanto no caso (c) a reexecução seria permitida sem restrições. As implementações de RPC tratam a possibilidade de falha do através da definição de uma das três possíveis semânticas de execução de procedimento remoto:! pelo menos uma vez (at least once semantics): o procedimento vai ser executado pelo menos uma vez, mas possivelmente mais de uma vez (o cliente espera que o volte a funcionar enviando nova requisição);! no máximo uma vez (at most once semantics): o procedimento será executado uma única vez ou nenhuma (no caso de erro, o cliente desiste e reporta erro)! exatamente uma vez (exactly once semantics): garante a execução do procedimento uma única vez. Teoricamente seria a melhor semântica, porém difícil de implementar. 5. O cliente falha após enviar uma requisição (falha do cliente):

9 No caso de falha do cliente, a computação estará ativa no não existirá nenhum processo aguardando o resultado, resultando em um processo ou computação órfã. Esse tipo de computação causa basicamente dois tipos de problemas: - desperdício de CPU, e - processo cliente ao retornar pode receber uma mensagem não esperada do processo órfão. [TAN 95] apresenta as seguintes soluções possíveis: solução 1 exterminação (extermination): o cliente mantém log das requisições. Quando falhar, ao reiniciar, elimina todos os processos órfãos. Como desvantagens tem-se o gasto para escrita em disco e o fato de não funcionar quando houver partição na rede. solução 2 reencarnação (reincarnation): quando o cliente reiniciar, envia mensagem broadcast declarando o início de uma nova época. Com isso computações remotas serão finalizadas. solução 3 reencarnação gentil (gentle reincarnation): idem solução 2, porém somente mata as requisições remotas quando o não estiver ativo. solução 4 expiração (expiration): O tem um tempo T para executar, se precisar de mais tempo tem que enviar requisição Questões de Implementação As questões de implementação a serem analisadas nessa seção estão intimamente direcionadas ao ganho de desempenho. (a) Protocolo Em princípio qualquer mecanismo de troca de mensagens poderia dar suporte a implementação de RPC. Uma das questões a serem decididas na implementação é se o protocolo será orienta a conexão ou sem conexão. No primeiro caso, evita-se o problema de mensagens perdidas pois isso é tratado em baixo nível, porém, o desempenho é menor. No segundo caso, o desempenho é melhor, sendo indicado para implementações em LANs que são mais confiáveis do que WAMs. (b) Confirmação (Acknowledgements) O uso de mensagens de confirmação é usado para detecção de falhas. No momento de implementar, é preciso decidir se os pacotes serão confirmados individualmente ou não. Assim temos dois tipos de protocolos: stop-and-wait (no momento em que um pacote for danificado ou perdido, o cliente não recebendo o ACK providencia o reenvio), e blast (o envia mensagem ACK apenas ao final). stop-and-wait ACK 0 ACK 1 ACK 2 ACK 3 blast protocol ACK 0-3 Figura 3.7 Protocolos stop-and-wait e blast. No caso do blast protocol, existe duas formas de tratar o fato de apenas alguns pacotes terem sido entregues e outros não. Uma hipótese é ignorar todos os pacotes e solicitar a retransmissão de todos os pacotes. Outra possibilidade é realizar uma repetição seletiva, onde os pacotes recebidos são armazenados em um buffer, e solicitar ao cliente o reenvio específico dos pacotes. A segunda alternativa requer maior administração porém gasta menos banda no canal da rede de comunicação

10 Como a perda de pacotes em LANs é muito rara, a repetição seletiva (selective repeat) não compensa devido ao custo de controle envolvido. Outro problema refere-se ao fato dos buffers de recepção serem limitados. O envio de várias mensagens consecutivas pode causar um overrun error. O overrun error caracteriza-se pela incapacidade do receptor receber um pacote que chega corretamente causando dessa forma uma perda de mensagem. Na prática esse é um erro mais sério do que a perda por ruído ou outros problemas físicos na rede. Com o uso de stop-and-wait em princípio esse erro não ocorre pois uma mensagem é enviada de cada vez. No entanto ele poderia ocorrer caso diferentes emissores enviarem várias mensagens ao mesmo tempo.

11 3.4 Comunicação de grupo [TAN 95][TAN 92] Existem várias aplicações para as quais tem-se comunicação com múltiplos processos (comunicação em grupo ou multicast). Por exemplo, grupo de es de arquivos que fornecem serviço de arquivos tolerante a falhas. Um processo pode enviar mensagem para um grupo de es sem saber quantos eles são ou onde se localizam, sendo que tais parâmetros que podem mudar na próxima chamada. Um grupo é uma coleção de processos que agem juntos. Quando uma mensagem é enviada ao grupo, todos os membros recebem a mesma mensagem. Grupos são dinâmicos (analogia a grupos sociais): podem ser criados e destruídos; processos podem entrar ou abandonar o grupo; e um mesmo processo pode pertencer a mais de um grupo Questões de Projeto! grupos fechados (closed) x grupos abertos (open) essa diferenciação é definida em função de quem pode ou não se comunicar com os elementos do grupo. Grupo fechado: Apenas os membros do grupo podem mandar mensagem para o grupo; processos fora do grupo não podem enviar mensagens ao grupo como um todo, apenas aos membros individualmente. Tipicamente essa abordagem é usada em processamento paralelo. Grupo aberto: Qualquer processo no sistema pode enviar mensagem para o grupo. Tipicamente usado para elementos replicados como por exemplo um grupo de es.! grupos igualitários (peer) e hierárquicos essa classificação indica a estrutura interna do grupo. Grupo igualitário: Todos os processos são iguais e as decisões são tomadas coletivamente. Como vantagens temos um grupo simétrico e uma ausência de ponto único de falhas. Por outro lado, a tomada de decisão é bem mais complexa. Grupo hierárquico: Existe algum tipo de hierarquia entre os membros; a organização mais simples consiste em um processo coordenador e outros processos denominados trabalhadores; quando uma requisição (externa ou interna) é feita, o coordenador decide qual trabalhador é o mais apropriado para realizar a tarefa, ou define que todos devem realizar a requisição. Quando a hierarquia for do tipo coordenador-trabalhadores temos no coordenador ao mesmo tempo um ponto de falha e uma simplificação da tomada de decisão.! Controle dos Membros do Grupo (group membership) Como grupos são dinâmicos, é preciso realizar de alguma forma o controle de quais são os membros do grupo, bem como permitir a inclusão e exclusão de membros. As duas principais formas de fazer essa gerência é através de um (implementação centralizada) ou de uma forma distribuída. Servidor de Grupo (group server): com a presença de um de grupo, todas as requisições devem ser feitas a ele. O deve manter uma base de dados completa de todos os grupos e seu conjunto exato de membros. Vantagens: eficiente; direto; fácil de implementar. Desvantagem: ponto único de falha. Controle de forma distribuída: cada novo membro deve enviar mensagem a todos os membros atuais anunciando a sua presença. Da mesma forma temos que ao sair um membro deve avisar a todos os membros para que as mensagens do grupo não sejam mais direcionadas a ele. Esse tipo

12 de gerência facilita uma implementação tolerante a falhas. Além disso, note que a entrada e a saída do grupo deve ser sincronizada com a troca de mensagens para que ao entrar um membro receba todas as mensagens. Controle de falhas: a falha de um membro isolado equivale a esse membro sair do grupo. A diferença é que nesse caso não há "anúncio" dessa saída. Os demais membros do grupo devem perceber que um membro não está mais respondendo e por isso não faz mais parte do grupo. No caso de uma organização hierárquica, pode ser necessário reestruturar a organização do grupo. Além disso, caso haja muitos membros falhando (máquinas e/ou processos) o grupo pode ser inviabilizado pelo pouco número de elementos, forçando a execução de um algoritmo de reconstrução de grupo.! Endereçamento do Grupo Para realizar efetivamente a comunicação em grupo é preciso ter uma forma de indicar qual o grupo com o qual deseja-se enviar a mensagem. Esse endereçamento deve ser análogo ao endereçamento de processos devendo ser um identificador único no nível do usuário. Para implementar a comunicação em grupo existem basicamente três formas de implementação, que são dependentes de suporte de hardware: multicast, broadcast e unicast (ponto a ponto). Considere por exemplo a figura abaixo onde o processo 0 deseja enviar a mensagem ao grupo formado pelos processos 1, 3 e 4. Note que multicast é baseado na possibilidade de criar endereços especiais para os quais um conjunto de máquinas selecionadas podem receber. Já o broadcast envia a mensagem a todas as máquinas e fica a cargo do descartar as mensagens que não são endereçadas a uma determinada máquina (no exemplo, a máquina 2 descarta a mensagem). Finalmente, caso não haja suporte para comunicação em grupo ou broadcast, o sistema deve enviar as mensagens usando um pacote separado para cada membro do grupo (mensagens ponto a ponto) (a) multicast * * descarta a msg (b) broadcast (c) unicast Ainda com relação a endereçamento, existe a possibilidade de endereça o grupo usando predicados (expressão booleana). Esse endereçamento, denominado predicate addressing, permite que somente quando o predicado for avaliado com verdadeiro o membro irá receber e avaliar a mensagem.

13 ! Primitivas de comunicação com o grupo O envio de mensagens para grupos não pode ser modelado como uma chamada remota de procedimento (RPC) ou pelo menos fica bem mais difícil em termos semânticos. Normalmente a comunicação é modelada como primitivas send e receive. Assim como na troca de mensagens normais, pode-se ter os seguintes tipos de "configuração" para o send: bloqueante x não bloqueante com buffer x sem buffer confiável x não confiável Essas características costumam ser definidas pelo projetista do sistema e o usuário não tem como interferir. Para implementar em essas rotinas, pode-se usar send/receive utilizando ao invés de um identificador de processo a identificação do grupo ou usar primitivas distintas como send_group/receive_group que explicitam a existência de comunicação em grupo.! Atomicidade A atomicidade ou broadcast atômico garante a propriedade de tudo ou nada na entrega da mensagem ao grupo simplificando a programação distribuída de certas classes de aplicações, como por exemplo, bancos de dados distribuídos. De fato existem dois cenários de aplicações com comunicação em grupo: o cliente solicita um serviço o qual qualquer um dos es pode realizar ou o cliente solicita um serviço para todos os membros. No primeiro caso, o sistema deve garantir a entrega a todos os membros do grupo que não falharam caracterizando uma comunicação do tipo melhor esforço (best-effort multicast). No segundo caso, a mensagem deve ser entregue a todos os membros do grupo ou a nenhum caracterizando uma comunicação confiável (reliable multicast). Além dessa classificação, pode-se estabelecer três semânticas de ordenação: - ordem de chegada (FIFO order): mensagens enviadas ao grupo a partir de uma fonte são entregues na ordem em que foram enviadas por essa fonte; - ordem causal (causal order): mensagens com relacionamento causa-efeito das diversas fontes são entregues na ordem causal; - ordem total (total order): todas as mensagens são entregues para todos os membros do grupo na mesma ordem. Segundo alguns autores, uma comunicação atômica (atomic multicast) pode ser descrita por uma comunicação confiável que garante a semântica de ordenação total [CHO 97]. Ordenamento de mensagens Quando dois processos estão disputando o acesso à rede local, a ordem na qual as mensagens serão enviadas é não determinística. Por isso, pode-se utilizar algoritmos que garantam a ordenação com tempo global, com a entrega de todas as mensagens na ordem exata em que foram enviadas, o que é muito difícil de ser implementado, ou uma ordenação com tempo consistente, onde a mensagem chega a todos os membros do grupo na mesma ordem que pode ou não ser a ordem real de envio. Considere a figura abaixo:

14 Note que o processo 0 envia as mensagens, respectivamente para os processos 1, 3 e 4 enquanto o processo 4 envia, respectivamente, para os processos 0,1 e 3. Note que teremos uma inconsistência no recebimento das mensagens uma vez que o processo 1 receberá primeiro a mensagem do processo 0 e depois do 4 enquanto o processo 3 receberá primeiro do 4 e depois do 0. Isso pode ser um problema em certos tipos de aplicações como por exemplo banco de dados replicados. Uma possibilidade de resolver isso é através do uso de um algoritmo de ordenamento causal como o apresentado abaixo: S = (S1, S2,..., Sn) // vetor local onde // Sk é o número da última mensagem recebida de k T = (T1, T2,..., Tn) // vetor de seqüência incluído na mensagem Quando é recebida uma mensagem m de i para j Se (Ti = Si+1) e (Tk Sk para todo k i) j aceita a mensagem m Se (Ti > Si+1) ou ( k i tal que Tk>Sk) j aguarda para processar m Se (Ti Sj) j rejeita a mensagem m A primeira verificação inclui duas condições para que a mensagem seja aceita: j está esperando a mensagem de i (Ti = Si+1) e j lá recebeu todas as mensagens que precedem m (ordem casual). Caso alguma mensagem de i ainda não tenha sido recebida (Ti > Si+1) ou i recebeu mais mensagens multicast do que j ( k i tal que Tk>Sk), irá precisar aguardar até processar a mensagem. Finalmente, mensagens duplicadas (Ti Sj) são descartadas. Note que esse algoritmo irá funcionar apenas para grupos fechados. 4 Referências Bibliográficas [CHO 97] CHOW, R.; JOHNSON, T. Distributed Operating Systems & Algorithms. Addison-Wesley, [SIL 99] SILBERSCHATZ et al. Operating System Concepts. John Willey, [TAN 92] TANENBAUM, A. S. Modern Operating Systems. Prentice Hall, [TAN 95] TANENBAUM, A. S. Distributed Operating Systems. Prentice Hall, [DSM] DSM Tutorial.

15