2. Introdução
• A maior diferença entre um sistema monoprocessado e um
sistema distribuído é a comunicação entre processos
– Em um sistema monoprocessado:
• Assume-se a existência de memória compartilhada, que é
fundamental para o funcionamento de soluções para:
– Comunicação entre processos
– Exclusão mútua e regiões críticas
– Semáforos, variáveis compartilhadas, etc
– Em sistemas distribuídos:
• A ausência de memória compartilhada (ou a impossibilidade de
garantir a disponibilidade deste recurso) obriga os componentes
dos sistemas distribuídos a buscar outra solução para interagir
– Troca de mensagens
– Implica em adotar protocolos de comunicação para permitir que
ambientes heterogêneos troquem mensagens
3. Protocolos de Comunicação
– Protocolos são regras pré-estabelecidas para
comunicação entre duas ou mais partes
• O uso de camadas facilita sua implementação e
entendimento, já que cada camada possui responsabilidades
específicas
• Em 1983, a International Standards Organization (ISO)
desenvolveu um modelo de referência que identifica
claramente os vários níveis envolvidos e suas atribuições: o
“Modelo OSI” (Open Systems Interconnection Reference
Model)
– Voltado para comunicação entre sistemas abertos
– Um sistema aberto é preparado para se comunicar com qualquer outro sistema
aberto através de regras que ditam o formato, conteúdo e significado das
mensagens enviadas e recebidas.
4. Modelos de Protocolos
• Protocolos orientados à conexão
– Neste modelo, o emissor e o receptor de uma
determinada mensagem devem estabelecer uma conexão
antes que ocorra a troca de dados propriamente dita
• Existe possibilidade inclusive de negociação de aspectos do
protocolo
• Protocolos sem conexão
– Conforme o nome já indica, não há necessidade de que o
emissor e o receptor de uma determinada mensagem
estejam conectados para a comunicação acontecer
5. O Modelo OSI
• Características:
– Dividido em sete
camadas de
funcionalidade
• Cada camada trata de
um aspecto da
comunicação e provê
uma interface
(operações que definem
os serviços da camada)
às camadas adjacentes
– Cabeçalhos e
finalizadores podem ser
acrescentados e
retirados às mensagens
6. Características Importantes na
Comunicação SD
• Dependabilidade (qualidade do serviço oferecido
por um dado sistema)
– Em geral, sistema é considerado confiável se há
garantia de entrega de mensagens apesar da perda de
um número “razoável” de pacotes
– Reconhecimento de mensagens
• Reconhecimento positivo (esta é a mensagem esperada)
• Reconhecimento negativo (esta não pode ser a mensagem)
• Ordenação
– Alguns sistemas dependem da ordem das mensagens
– Fácil implementar para cliente-servidor ou p2p,
porém complexo em comunicação multicast
7. APIs de Comunicação
• APIs de comunicação permitem que as aplicações enviem e
recebam dados
– Fornecem primitivas de comunicação que podem ser chamadas
a partir do código
– Oferecem acesso aos serviços de comunicação, que podem
assim ser usados pelas aplicações
– Exemplos de APIs de comunicação:
• Sockets:
– Portas de comunicação locais ou de rede (Ex: SSL)
• Suportes de RPC (Remote Procedure Call):
– Permitem chamar procedimentos/métodos remotamente (ex.: Java RMI, Sun
RPC, ...)
• Canais de eventos:
– Permitem notificar threads e processos dos eventos ocorridos no sistema (Ex.:
JMS, CORBA Notification Service, …)
8. API Socket
• São abstrações que representam uma porta de
comunicação associada a uma aplicação
– Origem: UNIX - depois portado para outros Sos
– Identificados por um inteiro de 16 bits:
• Valores de 0 a 1024: serviços padronizados pela rede
• Valores acima de 1024: livres para uso (desenvolvedores)
– Tipos de Socket
• Sockets Datagrama:
– serviço sem conexão que usa protocolo UDP em mensagens 1 para 1
• Sockets Multicast:
– envio para um grupo sem estabelecimento de conexão via UDP
• Sockets Stream:
– serviço com conexão, baseado no paradigma cliente-servidor
9. Comunicação Cliente/Servidor
• Conceitos básicos:
– Servidor: oferece serviços
– Cliente: consome serviços oferecidos
– Em termos lógicos, para que dois processos se
comuniquem é preciso apenas a existência de duas
operações primitivas:
– SEND (enviar) – acionada pelo rementente da mensagem
– RECEIVE (receber) – acionada pelo destinatário
– 3 questões importantes:
• Como o cliente localiza o serviço?
• Como se processa o envio/entrega das mensagens?
• Como lidar com o conceito de “garantia de entrega”?
10. Comunicação Cliente/Servidor (cont.)
• Como o cliente localiza o servidor para solicitar um
serviço?
– Opção 1: O pedido é enviado para o endereço do servidor
acompanhado pelo endereço do processo/serviço
• Desvantagem: endereço estático no código do cliente
Cliente Servidor
SO SO
Rede Rede
Pedido para 123.1
Resposta para 123.2
11. Comunicação Cliente/Servidor (cont.)
• Como o cliente localiza o servidor para solicitar um
serviço?
– Opção 2: O pedido é enviado para todos
• Desvantagem: sobrecarga da rede
• Variação da opção 2: Antes do pedido ser enviado, é
feito um broadcast para localizar o servidor (reduz
sobrecarga)
Cliente Servidor
SO SO
Rede Rede
Resposta para 0.0 (broadcast)
Pedido para 0.0 (broadcast)
12. Comunicação Cliente/Servidor (cont.)
• Como o cliente localiza o servidor para solicitar um
serviço?
– Opção 3: O cliente consulta um serviço de resolução de
nomes para localizar o servidor desejado
• Desvantagem: exige um serviço adicional centralizado
Cliente
SO
Rede
Servidor
SO
Rede
Pedido de resolução de nomes
Resposta do endereço real
Servidor NS
SO
Rede
13. Comunicação Cliente/Servidor (cont.)
• Comportamento das primitivas SEND e RECEIVE:
– Na Comunicação Síncrona
– É a solução mais comum
– Exige que a origem e o destino da mensagem estejam
sincronizadas a cada troca de mensagem, ou seja, as
operações de SEND e RECEIVE causam bloqueios em
suas respectivas execuções
– Ao ser emitido um SEND, o emissor é bloqueado até que
um RECEIVE correspondente seja realizado
– Ao ser executado um RECEIVE, o processo receptor é
bloqueado até a mensagem chegar
14. Comunicação Cliente/Servidor (cont.)
• Comportamento das primitivas SEND e
RECEIVE:
– Na Comunicação Assíncrona
– A operação SEND é “não bloqueante”, permitindo
que o processo remetente prossiga em sua
execução assim que a mensagem emitida seja
armazenada em algum dispositivo (um buffer local,
por exemplo) para envio
– Oferece a vantagem de permitir que o processo
continue executando paralelamente ao envio real
da mensagem
15. Comunicação Cliente/Servidor (cont.)
• Comunicação Assíncrona (cont.)
– A operação RECEIVE pode ser implementada de duas formas:
– RECEIVE não bloqueante
– A operação RECEIVE consiste em fornecer um
buffer para armazenar a mensagem que será
recebida em background. Com isso, o processo
receptor pode prosseguir sua execução e deve
receber uma notificação posterior informando que
há dados a serem processados no buffer
– Isso pode ser implementado usando técnicas de
polling ou interrupção
– RECEIVE bloqueante
– Se comporta igual ao RECEIVE da comunicação
síncrona
16. Comunicação Cliente/Servidor (cont.)
• Comunicação Assíncrona (cont.)
• A grande maioria dos sistemas não adota a comunicação
assíncrona em virtude de sua complexidade no tratamento
de informações que podem ser recebidas fora do fluxo
normal de execução
– Quando a comunicação termina?
– Houve alguma falha ou necessidade de
intervenção?
17. Processamento do Pedido/Resposta
• Um mecanismo de controle comum tanto para
primitivas bloqueantes quanto para primitivas não
bloqueantes, é o uso de timeouts
– O estabelecimento de um limite de tempo facilita o
tratamento de situações de espera muito longa
– Em primitivas bloqueantes:
• Se o tempo de espera de um send ou receive for muito alto, além
de um determinado valor, pode-se notificar um erro.
– Em primitivas não bloqueantes:
• O número de tentativas de enviar/receber pode ser limitado.
18. Garantia de Entrega
– Até o momento assumimos que sempre que um
cliente envia uma mensagem para o servidor, esta é
entregue ou falha.
• Na realidade, as mensagens podem se atrasar na
entrega, ou falhar na entrega.
– Cada vez que um SEND é executado, imagina-se que a
mensagem tenha sido recebida
– No entanto, não existem garantias de que isso realmente
aconteceu
Conceitos Básicos
19. Garantia de Entrega
• Proposta 1: assumir que o envio é falho e não
confiável
– Exemplo: Correios
• Quando se deixa uma carta no correio usando postagem
normal, sabe-se que ainda falta um caminho a ser
percorrido pela carta até seu destino
• O correio faz o seu melhor para entregar a mensagem, mas
não há garantias rígidas de entrega ou prazo
• Algumas vezes, caso os Correios saibam que a mensagem
não pode ser entregue, é possívem efetuar a devolução da
mensagem e até mesmo a recusa da mesma
• Mas o remetente já se imaginava livre dessa tarefa e sua
agenda de atividades não prevê tratar este problema
Conceitos Básicos
20. Garantia de Entrega
• Proposta 2: solicitar a confirmação do
recebimento da mensagem
– ACK (ACKNOWLEDGE)
– Um simples pedido/resposta agora tem 4
mensagens
Cliente Servidor
SO SO
Rede Rede
Pedido
Resposta
ACK
ACK
21. Garantia de Entrega
• Proposta 3: solicitar a confirmação do
recebimento da Resposta da Mensagem
– Possível devido a característica do modelo Cliente-
Servidor
– Um pedido/resposta agora tem 3 mensagens
Conceitos Básicos
Cliente Servidor
SO SO
Rede Rede
Pedido
Resposta
ACK
22. Implementando o Modelo
Cliente/Servidor
Localização Processamento de
Envio/Recepção de
mensagens
Garantia
Endereços
predefinidos e escritos
nos clientes
Boloquear enquanto
envia/recebe
Não confiar
Broadcast Não Bloquear Solicitar confirmação
para cada mensagem
Serviço de Resolução
de Nomes
Notificar quando a
mensagem estiver
pronta
Solicitar confirmação
para cada resposta
Conceitos Básicos
23. Estudo de Caso: RPC
• RPC (Remote Procedure Call)
– É um meio de empacotar e trocar mensagens entre
processos de forma a tornar isso mais fácil e mais
parecido com a programação convencional.
– É um método de transferência de controle
• Quem aciona o procedimento remoto suspende
sua execução e fica aguardando o retorno do
mesmo (ou seja, passa o controle da execução
adiante)
• O procedimento remoto assume o controle,
executa suas funções e devolve o controle para
quem o acionou
• O acionador retoma sua execução do ponto em
que parou
24. Estudo de Caso: RPC
• RPC (Remote Procedure Call)
– A troca de mensagens entre processos ou o I/O
envolvido não são percebidos pelo programador
da aplicação
• O ambiente que suporta RPC provê toda a
infraestrutura necessária para que a
comunicação aconteça sem que o
programador precise codificar isso de forma
explícita
25. Estudo de Caso: RPC (cont.)
• O que motivou a criação do RPC:
– Programar usando primitivas de comunicação não
é uma solução transparente, pois exige
conhecimento do ambiente físico ao redor
– Primitivas orientadas a Entrada/Saída (E/S) não
conseguem reproduzir nos sistemas distribuídos o
mesmo efeito obtido em sistemas centralizados
• Objetivo do RPC:
– Tornar mais fácil e transparente a implementação
de aplicações distribuídas
26. Estudo de Caso: RPC (cont.)
• STUB
– “Um stub ou method stub em desenvolvimento
de software, é um pedaço de código usado para
substituir algumas funcionalidades de
programação.” (Wikipédia)
– O código referente a chamadas à rede é
“escondido” (encapsulado) em procedimentos
chamados STUBs
• Os STUBs permitem ao RPC proteger os programas de
aplicação em relação a preocupações com detalhes
(exemplo: SOCKETS)
• A conversão dos tipos de dados acontece nos STUBS
durante a passagem de parâmetros
– Reduz a chance de erros, pois torna o sistema
transparente em relação a diferentes
representações de dados
27. Estudo de Caso: RPC (cont.)
• STUB
– Como obter os STUBs?
• Os STUBs são gerados pelo compilador e
“linkados” ao programa
– Em vários sistemas baseados em RPC os STUBs são
gerados automaticamente, mas existem algumas
implementações que oferecem a opção de gerá-los
de forma manual
28. Estudo de Caso: RPC (cont.)
• BINDER
– Cliente precisa localizar o servidor que vai executar o
procedimento remoto, mas isso deve acontecer de
forma transparente
• O responsável pelo processo de localização é um programa
chamado “Binder”, que fica disponível na rede em uma ou
mais máquinas
• STUBs possuem uma chamada o programa BINDER para
obter estas informações
– O programa Binder possui uma tabela com:
• Nomes e endereços dos serviços ativos e corretamente
exportados
• Um Checksum que identifica a versão de cada interface
exportada
29. Estudo de Caso: RPC (cont.)
• Funcionamento do BINDER
– Para cada instância de um serviço que está no ar:
• A interface é exportada no início da execução do serviço
para o Binder
• Cada serviço ativo é incluído na tabela do binder
• Um checksum é calculado a partir da interface exportada
• O cliente, ao iniciar, precisa se ligar (bind) ao serviço remoto
desejado
– Este processo é chamado de Dynamic Binding
• Os tipos de dados no cliente e no servidor devem ser
compatíveis (mas não necessariamente idênticos)
• Cliente e servidor são compilados separadamente mas
precisam ter a mesma interface
30. Estudo de Caso: RPC (cont.)
CLIENTE
Aplicação CLIENTE
CALL ‘rotina’ parm1
Serviço executando
EMPACOTA
PARÂMETROS
DESEMPACOTA
RESULTADOS
DESEMPACOTA
PARÂMETROS
EMPACOTA
RESULTADOS
KERNEL do CLIENTE KERNEL do SERVIDOR
TRANSPORTE
DE MENSAGENS
VIA REDE
STUB
CLIENTE
STUB
SERVIDOR
SERVIDOR
31. Comunicação em Grupo
• Um grupo é uma coleção de processos que atuam
juntos em um sistema
– Para que o grupo funcione bem, é desejável garantir que
qualquer mensagem enviada ao grupo seja conhecida por
todos os seus membros
– Grupos são dinâmicos:
• Novos grupos podem ser criados e outros podem ser apagados
• Um processo pode se unir a um grupo ou deixar-lo
• Um processo pode pertencer a mais de um grupo
32. Comunicação em Grupo
• Outras características de grupos
– É preciso haver algum tipo de estratégia de gestão de
grupos
– A existência de um grupo precisa ser transparente
• Quando um processo envia uma mensagem para o
grupo, ele não precisa saber o tamanho do grupo e
nem a localização dos membros
33. Comunicação em Grupo:
Estratégia de Comunicação
• A comunicação em pares (um-para-um) não é o melhor
modelo para comunicação de um processo com um
grupo
– Para estes casos, o emprego da difusão seletiva (multicast) é a
solução mais indicada
– A adoção de multicast permite a implementação de sistemas
distribuídos que suportam as seguintes características:
• Tolerância a falhas baseado em serviços replicados
• Localização de serviços de descoberta na interligação de
redes
• Melhor desempenho através da replicação de dados
• Propagação de notificações de eventos
34. Comunicação em Grupo:
Técnicas de implementação
• Comunicação do grupo com outros processos:
– Grupos abertos
• Neste tipo de grupo, qualquer processo externo pode enviar
mensagem para o grupo todo
• É uma abordagem usada tipicamente em casos de
replicação de serviços
– Grupos fechados
• Neste tipo de grupo, apenas os membros do grupo podem
mandar mensagem para o grupo todo
• E como alguém de fora fala com o grupo?
– A mensagem é mandada para um único integrante do
grupo, que se encarrega de repassar aos demais
• É uma abordagem usada tipicamente em processamento
paralelo
36. Comunicação em Grupo:
Técnicas de implementação
• Estrutura interna do grupo:
– Grupos igualitários (ou peers)
• Todos os processos são iguais e as decisões são tomadas coletivamente
• É um grupo simétrico, e isso evita a existência de um ponto único de
falha, já que todos os processos são iguais e podem desempenhar as
mesmas funções
• A tomada de decisão bem mais complexa
– Grupos hierárquicos
• Existe algum tipo de hierarquia entre os membros
• A organização mais simples (mas não a única possível) deste tipo de
grupo consiste em um processo coordenador e outros processos
denominados trabalhadores
– Quando uma requisição é feita, o coordenador decide qual
trabalhador é o mais apropriado para realizar a tarefa, ou define que
todos devem realizar a tarefa
• Possui um ponto único de falha (geralmente, o coordenador)
• A tomada de decisão neste tipo de grupo é mais simples
37. Comunicação em Grupo:
Controle de Membros
• É 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 são:
– Usando um servidor de grupo
• Todas as requisições devem ser feitas ao servidor
• O servidor deve manter uma base de dados completa de todos os grupos
e seu conjunto exato de membros
• É eficiente, direto e fácil de implementar, mas o servidor torna-se uma
vulnerabilidade da solução
– Adotando um controle distribuído
• Cada novo membro deve enviar mensagem a todos os membros atuais
anunciando a sua presença e, ao sair, deve avisar a todos os outros
membros
• É uma solução mais tolerante a falhas
• Quando um membro falha ele deixa de pertencer ao grupo e não há
mensagens de aviso
• A entrada e a saída do grupo devem ser sincronizadas com a troca de
mensagens
38. Comunicação em Grupo:
Atomicidade
• Quando uma mensagem é enviada para o grupo, ela deverá
chegar corretamente para todos os membros ou para
nenhum deles
– Não são permitidas situações onde alguns membros recebem a
mensagem e outros não (entrega parcial da mensagem)
– Isso torna a programação de aplicações mais fácil, pois quando um
processo envia uma mensagem para o grupo não precisa se preocupar
com o fato de alguém não ter recebido a mensagem
• Falhas na entrega são reportadas ao emissor da mensagem
– Sabendo-se que a mensagem falhou, é possível realizar as ações
necessárias para recuperação da consistência do processamento
39. Comunicação em Grupo:
Atomicidade
• A implementação da atomicidade não é simples
– A única forma de garantir a entrega da mensagem para todos os
destinos é através do envio de mensagens de reconhecimento
• Tolerância a falhas
– É essencial que a atomicidade seja mantida mesmo na presença
de falhas
– Exemplo de falha:
• O emissor envia uma mensagem para todos os membros do
grupo e falha em seguida
• Um processo do grupo não recebe a mensagem
• Não há mais um emissor para ser avisado, logo, não existe
possibilidade de retransmissão da mensagem
• Qual a ação do grupo?
– Resposta: ignorar a mensagem
40. Comunicação em Grupo:
Ordenação
• Um mecanismo de comunicação em grupo precisa ter uma
semântica bem definida com relação à ordem em que as
mensagens serão entregues.
• A melhor garantia para isto é fazer com que as mensagens
sejam entregues na mesma ordem em que foram enviadas
• Como nem sempre é possível imitar a ordem de envio,
existem quatro tipos diferentes de ordenação que
normalmente estão implementadas nos mecanismos de
comunicação de grupo:
– Sem Ordem
– Ordenamento FIFO
– Ordenamento Causal
– Ordenamento Total
41. Comunicação em Grupo:
Ordenação
• Tipos de ordenação:
– Sem Ordem
• As mensagens são enviadas ao grupo sem a preocupação de ordenamento
• Tem o menor overhead pois não necessita controle algum de sequência
• Nem sempre é adequado para certas aplicações.
– Ordenamento FIFO
• Garante que todas as mensagens de um membro sejam entregues aos demais na
ordem que o mesmo enviou
• Não garante que todas as mensagens serão ordenadas, apenas ordena por membro
– Ordenamento CAUSAL
• Adota o conceito de mensagem dependente de outra
• Se uma mensagem “A” é dependente de outra mensagem “B”, então “A” deve
sempre ser recebida depois de “B”
• Exemplo: respostas de mensagens em listas de discussão
– Ordenamento TOTAL
• Cada membro do grupo recebe TODAS as mensagens na mesma ordem
