c
a
-U
FRGS
Sistemas Operacionais II
Comunicação e sincronização
por troca de mensagens
Instituto de
Informáti
c
por troca de mensagens
Aula 10
Introdução
•
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 dependemIn sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 2 A. Car is s im i -25-abr -1 1
das primitivas fornecidas pela biblioteca
•
Pode ser empregada em ambientes de memória compartilhada•
Comunicação pode ser:•
Ponto a ponto•
GrupoCaracterísticas desejáveis para primitivas de mensagens
•
Simplicidade e clareza de uso•
Semântica uniforme•
Processos locais e remotos usam a mesma interface de comunicação•
Eficiência: In sti tuto de In for m áti ca -U FRGS A. Car is s im i -25-abr -1 1•
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 ordenadaCaracterísticas desejáveis (cont.)
•
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 In sti tuto de In for m áti ca -U FRGS A. Car is s im i -25-abr -1 1•
Flexibilidade•
Nem todas as aplicações tem as mesmas necessidades•
Segurança•
Autenticação dos pares•
Codificação das mensagens•
PortabilidadeModelo de comunicação
•
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 In sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 5 A. Car is s im i -25-abr -1 1 g•
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 P2 P1 send(m) receive(m) canal FilaMensagem
•
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 I l t ã d i iti ( t ) fá il In sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 6 A. Car is s im i -25-abr -1 1•
Implementação das primitivas (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árioCanal de comunicação
•
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 processosIn sti tuto de In for m áti ca -U FRGS A. Car is s im i -25-abr -1 1
•
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ânticas das primitivas send e receive
•
Semântica depende se na primitiva•
send, o remetente fica bloqueado até a mensagem ser aceitapelo destinatário ?
•
receive, o receptor fica bloqueado se não houver mensagem aser recebida? In sti tuto de In for m áti ca -U FRGS A. Car is s im i -25-abr -1 1
•
send, deve ser indicado um destinatário específico ou amensagem pode ser entregue a qualquer processo?
•
receive, deve ser indicado um remetente específico ou se amensagem pode ser proveniente de qualquer processo?
Nomeação
•
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)In sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 9 A. Car is s im i -25-abr -1 1
•
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
Sincronismo e assincronismo
•
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 bloqueanteIn sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 10 A. Car is s im i -25-abr -1 1
•
send é não bloqueante•
receive pode ser! Bloqueante ! Não bloqueante
•
Com send e receive não bloqueantes se tem apenas ummecanismo de comunicação, não de sincronização
Implementação comunicação sí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 sejaefetivada In sti tuto de In for m áti ca -U FRGS A. Car is s im i -25-abr -1 1
•
receive: processo/thread fica bloqueado até que o envio sejafeito e a mensagem seja recebida
msg send(p2, msg); receive(p1, m); m 1 2 3 4 i ii iii
Implementação da comunicação assíncrona
•
Envolve a utilização de buffers•
Podem provocar bloqueio do emissor/receptor devido ao “buffer limitado”•
Tipicamente, o receive é implementado de forma bloqueantem 2 In sti tuto de In for m áti ca -U FRGS A. Car is s im i -25-abr -1 1 receive(p1, m); test( ); msg send(p2, msg); buffer
send não bloqueante receive não bloqueante
m receive(p2, m); buffer receive bloqueante 1 2 3 4* 1 2 3 4* * 1 3 2
Outra forma de enxergar...
•
Comunicação:•
síncrona: null buffer•
assíncrona: buffer com capacidade ilimitada•
Na prática existe single message e buffer de capacidade limitadai l ( í ) U b d d b ff ( í ) ll b ff In sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 13 A. Car is s im i -25-abr -1 1 P1 P2
single message (síncrona)
P1 P2
Unbounded buffer (assíncrona)
buffer
P1
P2
null buffer
...
buffer overflow: erro ou
controle de fluxo 2 1 2 1 3 2 1 i ii
Comparação: comunicação síncrona versus assíncrona
•
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íncronaIn sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 14 A. Car is s im i -25-abr -1 1
•
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 sincronaRepresentação externa de dados
•
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 dadosIn sti tuto de In for m áti ca -U FRGS A. Car is s im i -25-abr -1 1
! 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 empregadoMarshalling e unmarshalling
•
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 comunicantesd d Conversão Desconversão dados
In sti tuto de In for m áti ca -U FRGS A. Car is s im i -25-abr -1 1
•
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
dados Formato X formato X
Marshalling Unmarshalling
Modelo de falhas
•
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 suaIn sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 17 A. Car is s im i -25-abr -1 1 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 respeitadosModelo de falhas (cont.)
•
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çãoIn sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 18 A. Car is s im i -25-abr -1 1 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
Estudo de caso: Sockets
•
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)In sti tuto de In for m áti ca -U FRGS A. Car is s im i -25-abr -1 1
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-servidorCaracterísticas básicas
•
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 portasIn sti tuto de In for m áti ca -U FRGS A. Car is s im i -25-abr -1 1 p
•
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•
1-1023: reservadas para serviços Internet (well-know address)•
1024-49151: registradas (serviços não padronizados)Aspectos na comunicação 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•
Ti t In sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 21 A. Car is s im i -25-abr -1 1•
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
Modelo de falhas UDP
•
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:In sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 22 A. Car is s im i -25-abr -1 1
•
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 falhasComunicação por fluxo 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 (tamanhoIn sti tuto de In for m áti ca -U FRGS A. Car is s im i -25-abr -1 1 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 destinoAspectos na comunicação TCP
•
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 lidosIn sti tuto de In for m áti ca -U FRGS A. Car is s im i -25-abr -1 1
•
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 é
Modelo de falhas
•
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 duplicadasIn sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 25 A. Car is s im i -25-abr -1 1
•
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ãoLeituras adicionais
•
Couloris, G; Dollimore, J; Kindberg, T. Distributed Systems:Concepts and Design (4thedition), Addison Wesley, 2005
•
Capítulos 2 (seção 2.3), 4 (seções 4.1, 4.2 e 4.3)•
S. Toscani; R. Oliveira; A. Carissimi; Sistemas Operacionais eprogramação concorrente Editora Sagra-Luzzato, 2003.
In sti tuto de In for m áti ca -U FRGS Sistemas Operacionais II 26 A. Car is s im i -25-abr -1 1
