Sistemas Operacionais II

Transcrição

1 Introdução Instituto de Informátic ca - UFRGS Sistemas Operacionais II Comunicação e sincronização por troca de mensagens Aula 0 Em ambientes de memória distribuída a comunicação e a sincronização entre processos é feita por troca de mensagem Troca de mensagem Associado a bibliotecas de comunicação Capacidades de comunicação e/ou sincronização dependem das primitivas fornecidas pela biblioteca Pode ser empregada em ambientes de memória compartilhada Comunicação pode ser: Ponto a ponto Grupo Sistemas Operacionais II Características desejáveis para primitivas de mensagens Características desejáveis (cont.) Simplicidade e clareza de uso Semântica uniforme Processos locais e remotos usam a mesma interface de comunicação Eficiência: Baixo sobrecusto de processamento Uso otimizado de recursos do sistema Confiabilidade: Garantir a entrega das mensagens em presença de falhas Eliminar (tratar) replicação de mensagens Entrega ordenada Correção (associado a comunicação em grupo) Atomicidade: todos ou nenhum recebem Entrega ordenada: mensagens chegam na mesma ordem a todos processos Garantia de entrega Flexibilidade Nem todas as aplicações tem as mesmas necessidades Segurança Autenticação dos pares Codificação das mensagens Portabilidade Aplicações e da própria biblioteca (implica em heterogeneidade) Sistemas Operacionais II 3 Sistemas Operacionais II 4

2 Modelo de comunicação Mensagem Duas primitivas básicas: send e receive Pode implicar na sincronização de processos/threads Modelo Origem (emissor, remetente) e Destino (receptor, destinatário) Mensagem Fila associada a cada destino de mensagem! send: faz com que mensagens sejam adicionadas na fila! receive: remove mensagens da fila Noção de canal P send(m) canal P receive(m) Fila Conjunto de n bytes Tamanho fixo Implementação das primitivas (e suporte) é mais fácil Programação simples Tamanho variável, mas com um limite superior fixo Implementação das primitivas iti (e suporte) fácil Programação mais complexa quando a mensagem tem, efetivamente, um tamanho variável, menor que o fixo Tamanho variável Implementação das primitivas (e suporte) mais complexo Facilidade da programação depende da abstração dada ao usuário Sistemas Operacionais II 5 Sistemas Operacionais II 6 Canal de comunicação Semânticas das primitivas send e receive Suporte abstrato (lógico ou virtual) pelo qual as mensagens são transferidas de um processo a outro Características: Canal pode ser unidirecional ou bidirecional Ser vinculado a dois processos ou a vários processos Ser ou não confiável (garantia de entrega, ordem e livre de erros)! Depende da forma como é criado (orientado a conexão* ou não) Depende da implementação/abstração: nem sempre conexão é sinônimo de confiabilidade Semântica depende se na primitiva send, o remetente fica bloqueado até a mensagem ser aceita pelo destinatário? receive, o receptor fica bloqueado se não houver mensagem a ser recebida? send, deve ser indicado um destinatário específico ou a mensagem pode ser entregue a qualquer processo? receive, deve ser indicado um remetente específico ou se a mensagem pode ser proveniente de qualquer processo? Remete a questões de sincronismo e nomeação Sistemas Operacionais II 7 Sistemas Operacionais II 8

3 Nomeação Sincronismo e assincronismo Modo de indicar (nomear) o processo com o qual se deseja interagir Nomeação explícita (direta) Determinação de processo destino/remetente específicos Nomeação implícita (indireta) Envio da mensagem para qualquer processo de um grupo! Também denominado de difusão (broadcast) Recepção de uma mensagem de qualquer origem Normalmente construída sobre o conceito de caixas postais! Caixas postais podem ser vinculadas a processos ao ou sistema Relacionado com o fato do emissor e do receptor ficarem ou não bloqueados na execução das primitivas send/receive Comunicação síncrona: send e receive são bloqueantes Comunicação assíncrona: send é não bloqueante receive pode ser! Bloqueante! Não bloqueante Com send e receive não bloqueantes se tem apenas um mecanismo de comunicação, não de sincronização Sistemas Operacionais II 9 Sistemas Operacionais II 0 Implementação comunicação síncrona Implementação da comunicação assíncrona As primitiva send e receive são bloqueantes Dispensa o uso de fila e buffers Procedimento: send: processo/thread fica bloqueado até que a recepção seja efetivada receive: processo/thread fica bloqueado até que o envio seja feito e a mensagem seja recebida ii receive(p, m); msg iii m send(p, msg); i 4 3 Envolve a utilização de buffers Podem provocar bloqueio do emissor/receptor devido ao buffer limitado Tipicamente, o receive é implementado de forma bloqueante msg send(p, msg); buffer 3 send não bloqueante 4* receive(p, m); test( ); 3 receive não bloqueante * Momento de tempo não preciso! 4* m 3 receive(p, m); buffer * receive bloqueante Sistemas Operacionais II Sistemas Operacionais II

4 Outra forma de enxergar... Comparação: comunicação síncrona versus assíncrona Comunicação: síncrona: null buffer assíncrona: buffer com capacidade ilimitada Na prática existe single message e buffer de capacidade limitada P P null buffer single message (síncrona) Unbounded dbuffer (assíncrona) P P P buffer P 3... buffer overflow: erro ou controle de fluxo i ii Comunicação: Sincrona: processos usam versão bloqueante das primitivas Assíncrona: processos usam versão não bloqueante de pelo menos uma das primitivas Desvantagens da comunicação síncrona Limitação da concorrência Possibilidade de deadlocks Vantagens da comunicação síncrona Programação simples Vantagens e desvantagens da assíncrona são dual da sincrona Sistemas Operacionais II 3 Sistemas Operacionais II 4 Representação externa de dados Marshalling e unmarshalling Informação (dados) é representada em uma estrutura de dados Na comunicação informação é igual a uma seqüência de bytes! Necessidade de conversão estrutura de dados seqüência de bytes Problema: diferentes sistemas = diferentes estruturas de dados! Ex: código ASC versus Unicode, big endian versus little endian, formatos ponto flutuante, etc Solução: Conversão para um formato de dados acordado (external data representation) Enviar no formato do emissor e incluir informação sobre o formato empregado Conversão de dados em um formato próprio para transmissão Auxilia a tratar a heterogeneidade de representação de dados entre os processos comunicantes dd dados Conversão Desconversão dados Formato X formato X Marshalling Unmarshalling Ideal é que seja feito sem envolvimento explícito da aplicação Responsabilidade da biblioteca ou middleware Duas técnicas básicas: Conversão dos dados para um formato binário ou texto (ASCII)! Exemplos:XDR, Corba, serialização Java e XML Sistemas Operacionais II 5 Sistemas Operacionais II 6

5 Modelo de falhas Modelo de falhas (cont.) Define como uma falha pode se manifestar de forma a proporcionar um entendimento sobre seus efeitos e conseqüências Processos ou comunicação podem falhar Tipos de falhas: Omissão: processo e/ou comunicação não executam sua função! Ex: mensagem não chega ao destino Arbitrária (bizantina): processo e/ou comunicação executam com erros! Ex: mensagem chega no destino com erro, duplicada e/ou fora de ordem Temporização: quando limites superiores de tempo não são respeitados Mascaramento de falhas Quando um serviço esconde que houve uma falha ou a transforma em um modelo menos grave! Ex: CRC corrompido, mensagem descartada (bizantina omissão) Outras técnicas: retransmissão de mensagens, replicação dados/serviços, etc Confiabilidade na comunicação Definido em termos de:! Validade: mensagem é entregue (garantia)! Integridade: o que é recebido e exatamente o que foi enviado! Tratar problemas de duplicação, mensagens espúrias, mensagens modificadas Sistemas Operacionais II 7 Sistemas Operacionais II 8 Estudo de caso: Sockets Características básicas Mecanismo de comunicação entre processos por troca de mensagens Baseado nos protocolos de transporte da Internet (UDP e TCP) Abstração de ponto de comunicação (socket ou endpoint) Composto pelo par {endereço IP, porta} Canal de comunicação é definido pela associação (5-tupla)! [IP_destino, Porta_destino, IP_fonte, Porta_fonte, Protocolo]! Envolve um par de sockets (endpoint local e endpoint remoto) Permite desenvolvimento de aplicativos através de uma API Primitivas para criar,inicializar, enviar e receber dados Modelo cliente-servidor Permite comunicação bidirecional Confiabilidade da comunicação depende Orientado a conexão (TCP) Não orientado a conexão (UDP) Processos são associados a portas Um processo pode estar associado a mais de uma porta. Numa mesma máquina (IP), uma porta não pode ser compartilhada por vários processos (exceção: multicast IP) Atribuição de número de porta deve respeitar padrão IANA -03: reservadas para serviços Internet (well-know address) : registradas (serviços não padronizados) : portas dinâmicas ou efêmeras (processos clientes) Sistemas Operacionais II 9 Sistemas Operacionais II 0

6 Aspectos na comunicação UDP Modelo de falhas UDP Tamanho da mensagem Necessidade de especificar o tamanho da área de recepção! Se menor que o necessário mensagem truncada Bloqueio Normalmente: send é não bloqueante e receive é bloqueante Timeout Limitar tempo de espera do receive problema: dimensionar o timeout Recepção anônima Correspondência entre itens de dados Processos devem concordar quando ao conteúdo dos dados transmitidos! Se um envia n bytes como sendo um inteiro, o outro deve ler como tal Lembre: comunicação confiável implica duas propriedades: Validade: qualquer mensagem é entregue a seu destino Integridade: mensagens não podem ser corrompidas, nem duplicadas Datagramas UDP falham por: Falhas por omissão: mensagens podem ser perdidas e/ou descartadas Ordenamento: mensagens podem ser entregues fora de ordem Responsabilidade dos aplicativos tratarem com as falhas Sistemas Operacionais II Sistemas Operacionais II Comunicação por fluxo TCP Aspectos na comunicação TCP Define a abstração de fluxo (stream) Dados podem ser lidos (receive) e escritos (send) na base de uma relação produtor-consumidor Características de um fluxo TCP Não define limites de tamanho para as mensagens (tamanho variável) Efetua controle de erro (evita perdas por erro) Faz controle de fluxo (regula a taxa de leitura e escrita em fluxo para evitar perdas por overflow) Garante entrega ordenada e a não-duplicação dos dados Define a abstração de conexão como identificadores de processos e máquinas origem e destino Correspondência entre itens de dados Processos devem concordar quando ao conteúdo dos dados transmitidos! Se um envia n bytes como sendo um inteiro, o outro deve ler como tal Bloqueio Dados escritos em um fluxo são mantidos até serem lidos! Processo destino é bloqueado se tenta ler dados não disponíveis! Processo remetente é bloqueado pelo controle de fluxo do TCP, se não houver espaço disponível no destinatário para recepção Threads! Recomendável para simplificar a programação (bloqueante), senão é preciso empregar primitivas do tipo select. Sistemas Operacionais II 3 Sistemas Operacionais II 4

7 Modelo de falhas Leituras adicionais Funcionamento do TCP quanto à confiabilidade: Validade: usa timeouts e retransmissões para tratar perda de mensagens Integridade: uso de checksum e de número de sequências para garantir que mensagens não corrompidas, nem duplicadas Porém não é uma comunicação confiável (modelo definido), pois as conexões TCP podem ser desfeitas (rompidas), implicando: Processos não distinguem entre falha de rede e falha de processo Processos não sabem identificar se mensagens enviadas recentemente foram recebidas ou não Couloris, G; Dollimore, J; Kindberg, T. Distributed Systems: Concepts and Design (4 th edition), Addison Wesley, 005 Capítulos (seção.3), 4 (seções 4., 4. e 4.3) S. Toscani; R. Oliveira; A. Carissimi; Sistemas Operacionais e programação concorrente Editora Sagra-Luzzato, 003. Capítulo Sistemas Operacionais II 5 Sistemas Operacionais II 6