SI - Comunicação

Sistemas Distribuídos
Comunicação
Frederico Madeira
LPIC-1, LPIC-2, CCNA
fred@madeira.eng.br
www.madeira.eng.br

Referências
- Tanenbaum, A.; Steen, M.; Sistemas Distribuídos, princípios
e paradigmas. Capítulo 4.
- Coulouris, G.;Dollimore, J.; Kindberg, T.;
SISTEMAS DISTRIBUIDOS CONCEITOS E PROJETO. Capítulo 4.

✔
Introdução
✔
Fundamentos
✔
Modelo em Camadas
✔
OSI
✔
TCP
✔
Modelos de Comunicação
✔
RPC
✔
MOM
✔
Fluxo
Sumário

Introdução
• A comunicação entre processos está no coração de
todo Sistema Distribuído;
• A comunicação é sempre baseada em troca de
mensagens pela rede;
• Protocolo são regras as quais os processos
comunicantes têm de obedecer;
• Expressar comunicação por meio de troca de
mensagens é mais difícil do que usar primitivas
baseadas em memória compartilhada;
• A comunicação via rede não é confiável, como por
exemplo na Internet;

Protocolos em Camadas
• Dada ausência de memória compartilhada, toda
comunicação é feita via troca de mensagens de
baixo nível
• Em resumo:
– Quando A quer se comunicar com B;
– A cria uma mensagem;
– Envia a mensagem para B;
– Vários acordos são necessários para que essa
comunicação seja bem sucedida;

SIMPLES ESSE PROCESSO ???

• Como o receptor sabe o último bit da mensagem ?
• As partes da mensagem chegaram em ordem ?
• Alguma parte da mensagem foi perdida e precisa
ser retransmitida ?
• A mensagem que foi enviada foi recebida integra ?
Ocorreu algum erro de transmissão ?
• Para onde devo enviar a mensagem ?
• A latência está alta, como compensar ?
• O Servidor está atrás de um firewall e agora ?
• Essa porta é reservada, qual devo usar ?
• Como priorizar meus pacotes no meio de tantos
outros ?

Modelo OSI
• Para resolver esse problema de comunicação, a
ISO desenvolveu um modelo de referência;
• Este modelo é chamado de Open Systems
Interconnection Reference Model (OSI);
• Ele foi projetado para que sistemas abertos se
comuniquem;
• Sistema aberto é um sistema que está preparado
para se comunicar com outro usando regras
padronizadas, que seguem: o formato, o
conteúdo e o significado de cada mensagem;
• Essas regras estão formalizadas no que
denominamos como protocolos;

Modelo OSI
• Modelo baseado em camadas
• Onde cada camada tem sua função e serviços
oferecidos
• A camada inferior oferece (para a camada
superior) uma interface de interação;
• Facilita a identificação e tratamento de falhas
• Exemplo:
– se um grupo de computadores quiser se
comunicar, eles devem concorda quais
protocolos irão utilizar;
• Existem dois tipos de protocolos:
– Orientado a conexão
– Não orientado a conexão (sem conexão)

Modelo OSI
• Orientado a conexão
– antes de haver a comunicação,os
computadores estabelecem uma conexão para
negociarem o protocolo;
Ex. telefone
• Sem conexão
– não é preciso haver essa negociação. O
remetente envia uma mensagem assim que ela
estiver pronta;
Ex. correio
• Ambos os tipos de comunicação são comuns;

Modelo OSI
IP Layer
Link Layer
Application Layer
TCP Layer
Dados
Cabecalho de
Aplicação
Dados
TCP
Header
Application Data
TCP
Header
Application DataIP
Header
Application DataTCP
Header
IP
Header
Ethernet
Header
Ethernet
Trailer
TCP Segment
IP Datagram
Ethernet Frame
46 to 1500 bytes
Ethernet
Encapsulamento

Modelo OSI - Camadas
- Transmissão dos bits por um canal de
comunicação
- Ponta A enviar 1 a Ponta B deve receber 1
(definição da voltagem para representar 0 ou
1);
- Duração do bit (nanossegundos)
- Definição do modo de operação (Simplex,
Half ou full duplex)
- Como Inicializar e terminar uma conexão;
- Pinagem do conector e finalidade de cada
pino
Em linhas gerais:
- Interfaces Mecânicas
- Interfaces Elétricas
- Sincronização
- Meio físico de transmissão

- Transformar um canal de transmissão bruto
em uma linha livre de erros não detectados
para a camada de rede;
- Divide os dados de entrada em QUADROS de
dados e transmite sequencialmente
- Se serviço for confiável, receptor enviará
quadro de confirmação;
- Controle de Fluxo (Buffer interfaces);
- Controle de Erro;
- Controle de Acesso ao canal compartilhado
feito pela sub-camada MAC (Media acces contro
- controle de acesso ao meio).

Quadro Ethernert

- Controlar a sub-rede, definindo como os
PACOTES são roteados da origem até o destino;
- Rotas baseadas em tabelas estáticas ou podem
ser dinâmicas (especificada para cada pacote)
- Controle de congestionamento;
- Qualidade de Serviço (retardo, instabilidade,
etc)
- Endereçamento de redes
- Tamanho do pacote (fragmentação)
- Interconectar redes Heterogêneas

- Aceitar dados das camadas acima, dividi-los em
unidades menores (se necessário), repassá-los a
camada de rede e assegurar que os fragmentos
chegarão corretamente a oura extremidade.
- Deve ser feito de forma transparente para as
camadas superiores, independente da tecnologia
utilizada abaixo dela.
- Comunicação fim-a-fim
- O tipo de transporte mais popular é o ponto-a-
ponto, livre de erros, com garantia, no entanto
também é possível utilizar sem garantia.

• Os protocolos nesta camada podem utilizar
outros protocolos na camada de rede que seja
orientados, ou não, a conexão;
• Orientado a conexão:
•garantir que os fragmentos chegaram na
ordem correta;
• Sem conexão:
•não tem a mesma garantia, fragmentos
podem chegar desordenados;
• Esta camada deve tratar essa diferença, ela
deve reorganizar, antes de repassar a mensagem
para acamada de cima

•Dois protocolos se destacam nessa
camada: o TCP e o UDP
• O TCP (Transmission Control Protocol)
garante que todas os fragmentos serão
recebidos (conexão confiável, por
consequência, orientado a conexão)
• O UDP (Universal Datagram Protocol)
não garante que todas os fragmentos
serão recebidos (conexão não confiável,
por consequência, sem conexão)
• Implementa portas de comunicação

Sessão
• Responsável por sincronizar, manter e gerenciar
a conexão com outro computador
• Porventura a rede falhe, esta camada pode
continuar a comunicação de onde parou;
Apresentação
• Se preocupa com os significados dos bits;
• Também pode comprimir ou criptografar para
tornar a comunicação mais rápida e segura;
Aplicação
• De fato, são as aplicações sendo executadas;
• Esta camada também disponibiliza os recursos
(protocolo) para que tal comunicação aconteça

• Na prática, somente a camada de aplicação é
usada;
• A aplicação fica responsável por implementar as
funcionalidades das camadas Apresentação e
Sessão;
• Ex. HTTP e FTP

Modelo OSI – Camada de Middleware
•Mesmo com essa pilha de protocolo bem
definida, a aplicação ainda fica encarregada de
implementar diversas funcionalidades (criar
protocolo, segurança e etc);
•Muitas vezes, essas funcionalidades não está
ligadas diretamente ao negócio da aplicação;
•A alternativa é utilizar um middleware, que
ofereça essas funcionalidades já implementadas;
•O Middleware fica entre as camadas de baixo
nível e a aplicação;

Modelos de Comunicação
• Existem dois modos implementar um sistema
distribuído:
– Podemos implementar “do zero”, utilizando
os protocolos oferecidos pela camada de
transporte;
• Utilizando Socket ou Datagram (ambos
fornecidos pela linguagem Java);
– Podemos usar uma middleware;
• Devemos escolher qual tipo de middleware;
• Ex. RPC, MOM

Socket
• Ele é o ponto de comunicação entre full-duplex
(possibilita enviar e receber mensagens) entre
dois processos
• Não existe a transparência de distribuição: toda a
comunicação está explícita, através de
procedimentos:
– Send: enviar os dados (array de bytes)
– Receive: recebe os dados (array de bytes)
• Bem, o que esses Arrays significam? Sua aplicação
que dirá.
• É a forma mais primitiva de criar um sistema
distribuído;

Socket
• Além do mais, o desenvolvedor terá que
implementar (caso seja necessário):
– Balanceamento de carga
– Segurança
– Transparência de tecnologia
– E etc.

Socket
http://meusite.mackenzie.com.br/mariofci/COM_Socket.pdf

Socket
• Socket: uma porta entre o processo de aplicação
e o protocolo de transporte fim-a-fim (UCP or TCP)
• Serviço TCP: transferência confiável de bytes de
um processo para outro
http://meusite.mackenzie.com.br/mariofci/COM_Socket.pdf

Modelos de Comunicação -
Middleware
• A maneira mais fácil e rápida de desenvolver um
Sistema Distribuído é utilizando middleware;
• O desenvolvedor deve escolher um middleware
que atenda as necessidades da aplicação;
• Existem vários tipos, tais como:
– Chamada a Processo Remoto (RPC)
– Middleware Orientado a Mensagem (MOM)
– Fluxo de dados
• Mas antes de entender esses tipos, precisamos
entender sobre a:
– persistência, sincronização, granularidade
e ordenação dos bytes

Tipos de Comunicação
Persistência
• Comunicação Persistente
– Uma mensagem que foi apresentada para
transmissão é armazenada pelo middleware de
comunicação durante o tempo que for
necessária entregá-la
• Comunicação Transiente
– Uma mensagem é armazenada pelo sistema de
comunicação somente durante o tempo em que
a aplicação remetente e a aplicação receptora
estiverem executando.
• Normalmente, todos os serviços de comunicação a
nível de transporte oferecem somente
comunicação transiente.

Sincronização
• Comunicação Assíncrona (Primitiva não –
Bloqueante)
– Remetente continua sua execução
imediatamente após ter apresentado sua
mensagem para transmissão.
• Comunicação Síncrona (Primitiva
Bloqueante)
– O remetente é bloqueado até saber que a
requisição foi aceita

Sincronização

Granularidade
• Discreta
– Partes se comunicam por mensagens e cada
mensagem forma uma unidade de informação
completa
– Ex: Uma requisição
• Fluxo
– Várias mensagens,sendo que as mensagens
estão relacionadas uma com as outras pela
ordem ou pela relação temporal
– Ex. sistemas multimídia (vídeo ou áudio)

RPC - Remote Procedure Call
• Tecnologia de comunicação entre processos que
permite a um programa chamar um procedimento
em outro computador, conectado por uma rede
• O programador não se preocupa com detalhes de
implementação dessa interação remota
– do ponto de vista do código, a chamada se
assemelha a chamadas de procedimentos
locais.
– Viabiliza a transparência de acesso
• Tecnologia popular para a implementação do
modelo cliente-servidor de computação distribuída
• A idéia de RPC data de 1976, quando foi descrito
no RFC 707
Fonte: Wikipedia

Fonte: Wikipedia

• Arquiteturas de duas máquinas podem ser
diferentes
• É preciso passar parâmetros e resultados;
– De tipos primitivos (ex. int, bool) até os
compostos (classe, struct);
• Como tudo vai se tornar array de bytes, como
será a organização dos dados antes de enviar?

• A transparência é conseguida através dos
apêndices;
• Existem dois tipos de apêndices: o Stub (Cliente)
e o Skeleton (Servidor);
– Stub: responsável por empacotar os
parâmetros em uma mensagem, envia para o
servidor, e tratar a resposta.
– Skeleton: responsável por interpreta as
requisições, processar e retorna a resposta;

• Os Stubs e Skeletons ele não são genéricos;
• São utilizados para facilitar a comunicação com
um determinado servidor;
• Caso haja outro servidor, oferecendo outro tipo de
procedimento, irá existir outro Stub (para o
cliente) e o outro Skeleton (para o servidor);

• Mas, como são construído esses apêndices?
• Através de uma IDL (Linguagem de Definição de
Interface), é possível descrever a interface do
procedimento remoto
– A descrição provida pela IDL é independente de
qualquer linguagem de programação
• Assim, é possível criar Stub e Skeleton da
mesma IDL;
• E possibilitar a comunicação entre o cliente e o
servidor de forma transparente;

• Uma chamada remota de procedimento difere das
chamadas locais em alguns pontos:
– Tratamento de erros: falhas do servidor ou
da rede devem ser tratadas.
– Variáveis globais e efeitos colaterais: Uma
vez que o servidor não possui acesso ao espaço
de endereços do cliente, argumentos
protegidos não podem ser passados como
variáveis globais ou retornados.
– Desempenho: chamadas remotas geralmente
operam a velocidades inferiores em uma ou
mais ordens de grandeza em relação às
chamadas locais.

– Autenticação: uma vez que chamadas
remotas de procedimento podem ser
transportadas em redes sem segurança,
autenticação pode ser necessário.
• Dessa forma, mesmo havendo diversas
ferramentas que geram automaticamente o cliente
e o servidor, os protocolos precisam ser
desenvolvidos cuidadosamente.

RPC - Implementações
• CORBA — padrão RPC independente de
plataforma
• Sun RPC — RPC para as plataformas Unix e Linux
• DCOM — RPC para Windows
• RMI — RPC para Java
• SOAP — padrão RPC para web service
• JRES - Java Remote Execution Service é um
protocolo RPC que usa um mecanismo de
codificação estilo SSL para codificar suas
chamadas e HTTP puro como mecanismo de
transporte.

Comunicação Orientada Mensagem
(Transiente)
• Dada a natureza Síncrona do modelo RPC
– Bloqueia o cliente até que sua requisição
tenha sido atendida
• Quando não podemos garantir que o receptor
estará executando no momento em que uma
requisição é emitida
• É necessário o uso de serviços alternativos de
comunicação
• Neste, caso é o uso de troca de mensagens:
– Ex: Interface Berkley (sockets)
– Interface de troca de mensagens (MPI)

Comunicação Orientada Mensagem
(Persistente)
• Oferecem suporte extensivo para comunicação
assíncrona
• Capacidade de armazenamento de médio prazo
para mensagens,
– remetente ou receptor não precisam estar
ativos durante a transmissão da
mensagem
• A diferença do modelo anterior (sockets/MPI) as
mensagens podem durar minutos ao invés de
seg/ms)
• Exemplos:
– Sistemas de Enfileiramento de
mensagens
– Middleware orientado a mensagem (MOM)

Sistemas de Enfileiramento de Mensagens
• Aplicações se comunicam inserindo mensagens
nas filas especificas.
• As mensagens são repassadas para uma série de
servidores de comunicação
• Em certa altura, elas são entregues aos
destinatários.
• A transmissão da mensagem pode ocorrer mesmo
que o receptor não esteja em funcionamento no
mesmo momento.
• Única garantia: Que a mensagem será inserida na
fila

Sistemas de Enfileiramento de Mensagens

Comunicação orientada a Fluxo
• Os modelos anteriores focam a troca de unidades
de informação completas/independentes
• A temporização do envio/recebimento da
mensagem não é tão relevante
• Neste modelo, a temporização representa uma
questão crucial
• Imagine uma transmissão de áudio com qualidade
de CD, ou seja amostrada a 44.1 khz.
– Para reprodução, as amostras no fluxo de
áudio precisam se tocadas em intervalos
de 1/44100s.
– A reprodução a uma taxa diferente vai
resultar um áudio diferente do original
• Neste modelo a distribuição de dados é altamente
dependente do tempo, como áudio e vídeo.

• Modo de Transmissão Assíncrono
– Não existe restrição de temporização sobre quando a
transmissão dos itens deve ocorrer.
– É irrelevante o momento exato em que a
transferência de cada item é concluída
• Modo de Transmissão Síncrono
– Existe um atraso fim-a-fim máximo definido para
cada unidade em um fluxo de dados
– Se forem transmitidas muito mais rápida do que o
atraso mínimo tolerado, não importa
• Modo de Transmissão Isócrono
– As unidades precisam ser transmitidas no temo
certo.
– O atraso fim-a-fim tem um valor máximo e um valor
mínimo. (Variação de atraso delimitado)

Fluxos e Qualidade de Serviço
• Para que as relações temporais em um fluxo possa
ser preservadas, os requisitos costumam ser
expressos em politicas de QOS (Quality of
Service)
• QOS se resume na definição de algumas
propriedades:
– Taxa de bits requerida
– Máximo de atraso até o estabelecimento
de uma sessão
– Máximo atraso fim-a-fim
– Máxima variância de atraso
– Máximo atraso de ida e volta
• Se a comunicação utilizar a pilha de protocolos da
internet, esta é formada por serviço de datagrama
de melhor esforço, extremamento simples, o IP.
– Lá se vai a especificação de QOS !!!

• Dada a classe best-effort da internet, o sistema
distribuído pode ocultar essa falta de qualidade
• A internet suporta diffserv ou serviços
diferenciados
• O método DiffServ opera sobre grandes volumes
de dados em oposição a fluxos ou reservas
individuais
– Isto implica em uma negociação para todos os
pacotes de, por exemplo, um ISP ou uma
universidade
– Os acordos resultantes destas negociações são
designados de "acordos de nível de serviço"
(Service Level Agreements), e envolvem
geralmente um valor por parte das operadoras
de telecomunicações.
Fonte: https://pt.wikipedia.org/wiki/DiffServ

• Outra alternativa é trabalhar com buffers
– Muito útil para reduzir a variância de atraso.
– O receptor armazena os dados recebidos em
um buffer pelo tempo máximo.
– Isso permite que o receptor passe pacotes para
a aplicação a uma taxa regular
– Sempre haverá pacotes suficientes entrando no
buffer que garantirá a reprodução posterior

Solução é aumentar o
tamanho do buffer

Fonte: https://googlesystem.blogspot.com.br/2016/04/background-buffer-in-youtubes-
android.html#gsc.tab=0

Comunicação Multicast
• “multicast communication” - permite que um
processo envie a mesma mensagem para um
grupo de processos;
• Por muitos anos este tópico pertenceu ao domínio
dos protoco-los de rede, onde soluções na camada
de rede e de transporte foram propostas e
implementadas;
– Dependia de muito esforço de gerenciamento
– Em muitos casos intervenção humana
• No entanto, este tópico vem tomando espaço
como tópico em comunicação em sistemas
distribuídos.

Multicasting de nível de aplicação
• “idéia” - nós são organizados em uma rede de
sobreposição utilizada para disseminar a informação
para os membros;
• Roteadores da rede não estão envolvidos nesta rede,
assim o roteamento de mensagens na rede não é ótimo
em comparação com o roteamento na camada de rede.
• Assim, o aspecto de projeto é essencial no suporte a
multicast na aplicação é a construção da rede de
sobreposição:
– nós se organizam em uma árvore de modo que
tenhamos um único caminho entre cada par de nós;
– nós se organizam de modo que tenham múltiplos
vizinhos - “mesh network” assim, em geral existem
múltiplos caminhos entre cada par de nós.

Multicasting de nível de aplicação

SI - Comunicação

Mais conteúdo relacionado

Mais procurados

Semelhante a SI - Comunicação

Mais de Frederico Madeira

SI - Comunicação