SISTEMAS DISTRIBUÍDOS

CAPÍTULO 4 – COMUNICAÇÃO
Slides cedidos pela professora Aline
Nascimento e do livro texto
COMUNICAÇÃO ENTRE PROCESSOS

 Fundamentos

 Chamada de Procedimento Remoto

 Comunicação Orientada a mensagem

 Comunicação Multicast
COMUNICAÇÃO ENTRE PROCESSOS

 A comunicação entre processos está no coração de

qualquer Sistema Distribuído

 Como processos em diferentes máquinas são capazes de

trocar informações?
 A comunicação em SD é sempre baseada em troca de
mensagens

 Troca de mensagens é mais difícil do que usar primitivas

baseadas em memória compartilhada

 Desejável obter modelos onde a complexidade da

comunicação seja transparente para o desenvolvedor
COMUNICAÇÃO

 Os processos que se comunicam tem que obedecer regras

estabelecidas  Protocolos

 Como processos em diferentes máquinas trocam

informações?

 Processo A monta uma MSG em seu próprio espaço de

endereçamento

 Executa uma chamada de sistema, SO envia a MSG pela rede

até B

 A e B precisam concordar com significado de bits

COMUNICAÇÃO

 Vários acordos diferentes são necessários:

 Quantos volts são necessários para sinalizar um bit 0 ou 1?

 Como o receptor sabe qual é o último bit da mensagem?

 Como o receptor pode detectar se uma mensagem foi

danificada ou perdida?

 Qual o comprimento de cadeias e como elas são

representadas?

 Os acordos são estabelecido em diferentes níveis

COMUNICAÇÃO

 Para ficar mais fácil lidar com os vários níveis e questões

envolvidas na comunicação:

 International Organization for Standardization (ISO)

desenvolveu um modelo de referência que identifica os vários
níveis envolvidos  Modelo OSI

 Modelo OSI (Open Systems Interconnection Reference Model)

 Cada camada lida com um aspecto específico da comunicação

 Problema quebrado em pedaços gerenciados

independentemente
MODELO OSI
MODELO OSI

 A comunicação é dividida em até sete níveis/camadas

 Cada camada oferece uma interface para a camada que

está acima dela

 A interface é um conjunto de operações que definem um

serviço

 Modelo de referência ≠ Protocolos

 Protocolos OSI nunca foram populares

 Os protocolos desenvolvidos para internet são os mais usados

CAMADA FÍSICA

 Responsável pelo envio de bits

 Define algumas questões como:

 Quantos volts usar para 0 e para 1?

 Quantos bits por segundo podem ser enviados?

 A comunicação pode ocorrer em ambas as direções

simultaneamente?

 O protocolo da camada física trata da padronização das

interfaces elétrica, mecânica e de sinalização
CAMADA DE ENLACE

 Agrupa bits em unidades (quadros)

 Responsável para que cada quadro seja corretamente

recebido

 Coloca padrão especial de bits no início e no final de cada

quadro

 Soma de verificação

 Os quadros recebem números no cabeçalho para identificar a

sequência

 Cada protocolo pode implementar serviços diferentes

CAMADA DE REDE

 Em uma LAN, em geral não há necessidade de o remetente

localizar o receptor
 Remetente coloca quadro na rede e o receptor o retira

 Porém, redes de longa distância são constituídas de muitos

nós com diferente caminhos entre eles
 Como definir um melhor caminho entre um par origem-destino?

 O ROTEAMENTO é a principal tarefa da camada de rede

 O protocolo de rede mais famoso  Internet Protocol (IP)

 Protocolo sem conexão  não há uma preparação antecipada
 Cada pacote IP é roteado ao seu destino de forma independente
CAMADA DE TRANSPORTE

 Responsável pela comunicação lógica entre diferentes

processos sendo executados em diferentes hosts

 Ao receber uma mensagem da camada de aplicações, a

camada de transporte

 Quebra a mensagem em porções pequenas o suficiente para

transmissão, numera cada uma e envia

 Pode fornecer os seguintes serviços:

 Transmissão confiável

 Garantia de recebimento na sequência correta

PROTOCOLOS DE TRANSPORTE NA
INTERNET

 Transmission Control Protocol (TCP)

 Orientado a Conexão

 Confiável, porém “lento”

 Universal Datagram Protocol (UDP)

 Sem conexão

 “Rápido”, porém não confiável

 Escolha esta ligada as características da aplicação!

CAMADA DE APLICAÇÃO

 A Internet agrupou camadas superiores em uma única

camada  apresentação + sessão + aplicação

 Na prática somente a camada de aplicação é usada

 A intenção original da camada de Aplicação OSI era conter

um conjunto de aplicações padronizadas de rede como
correio eletrônico e transferência de arquivos

 Atualmente é um repositório de todas as aplicações que não

se ajustam as camadas subjacentes
CAMADA DE APLICAÇÃO

 É necessário fazer uma distinção entre aplicação para redes

e protocolos da camada de aplicação

 FTP (File Transfer Protocol) define um protocolo para transferir

arquivos entre um cliente e um servidor

 Programa ftp  aplicação de usuário para transferir arquivos que

implementa o FTP

 HTTP (HyperText Transfer Protocol) é projetado para gerenciar

e manipular remotamente a transferência de páginas Web

 O protocolo é implementado por aplicações como browsers Web

 Protocolos definem: tipos de mensagens trocadas, sintaxe

CAMADA DE MIDDLEWARE

 O objetivo do Middleware é prover serviços e protocolos comuns

que podem ser usados por diversas aplicações

 Consiste de um conjunto rico de protocolos

 (Un)marshaling de dados, necessário para sistemas integrados

 Protocolos de nomeação, para permitir compartilhamento fácil de

recursos

 Protocolos de segurança para comunicação segura

 Mecanismos de dimensionamento, para replicação e caching

PROTOCOLOS DE MIDDLEWARE

 Domain Name System (DNS): procura um endereço de rede

associado a um nome

 No modelo OSI estaria no nível de aplicação, mas este

serviço independe da aplicação

 Protocolos de autorização para garantir que usuários e

processos só tenham acesso a recursos autorizados

 Protocolo para acessar acesso compartilhado

MODELO DE REFERÊNCIA ADAPTADO

•As camadas de apresentação e sessão foram substituídas pela camada de

middleware que contém protocolos independentes da aplicação
•As camadas de transporte e rede foram agrupadas em serviços de comunicação
oferecidos pelo sistema operacional
•Sistema operacional gerencia hardware
TIPO DE COMUNICAÇÃO

•Núcleo do sistema de entrega de correio é um serviço de comunicação do

middleware
•Cada host executa um agente de usuário que possibilita que usuários
componham, enviem e recebam e-mail
•Um agente de envio passa o e-mail para o sistema de entrega de correio
•O agente do usuário no lado do receptor se conecta ao sistema de entrega
de correio para verificar se existe e-mail
TIPO DE COMUNICAÇÃO - PERSISTÊNCIA

 Comunicação Persistente

 Uma mensagem é armazenada pelo middleware de

comunicação durante o tempo que for necessário para
entregá-la ao receptor

 Não é necessário que a aplicação remetente continue em

execução após submeter a mensagem

 A aplicação receptora não precisa estar em execução no

momento da submissão da mensagem
TIPO DE COMUNICAÇÃO - PERSISTÊNCIA

 Comunicação Transiente

 Uma mensagem é armazenada pelo middleware de

comunicação somente durante o tempo em que a aplicação
remetente e a aplicação receptora estiverem executando

 Caso o middleware não possa entregar a mensagem, ela será

descartada

 Normalmente os serviços de comunicação do nível de

transporte oferecem comunicação transiente
TIPOS DE COMUNICAÇÃO -
SINCRONIZAÇÃO
 Comunicação Assíncrona

 Remetente continua sua execução imediatamente após ter

submetido sua mensagem para transmissão

 Middleware armazena temporariamente a mensagem

 Comunicação Síncrona

 Remetente é bloqueado até saber que sua requisição foi aceita:

1. Até que o middleware avise que se encarregará da transmissão

2. Até que sua requisição seja entregue ao receptor

3. Até que sua requisição tenha sido totalmente processada, isto é

quando o receptor retornar uma resposta
TIPOS DE COMUNICAÇÃO - Exemplo
 Computação cliente/servidor é geralmente baseada no modelo de
comunicação transiente síncrona

 Cliente e servidor devem estar ativos no momento da comunicação

 Cliente submete um pedido e bloqueia até que receba uma resposta

 Servidor essencialmente fica esperando requisições dos clientes, e as processa

subsequentemente

 Desvantagens

 Cliente não pode fazer outra coisa enquanto espera resposta

 Falhas devem ser tratadas imediatamente porque o cliente está esperando

 Para algumas aplicações não é apropriado (correio, news)

TIPOS DE COMUNICAÇÃO - Exemplo
 Middleware orientado a mensagem com comunicação persistente
assíncrona

 Processos enviam mensagens uns aos outros que são enfileiradas

 Remetente envia uma mensagem e não precisa receber uma resposta

imediatamente

 Middleware deve oferecer tolerância a falhas

CHAMADA DE PROCEDIMENTO REMOTO

“Permite a processos chamar procedimentos

localizados em outras máquinas”

(Birrell and Nelson - 1984)

 Surge da necessidade de obter transparência de acesso em

sistemas distribuídos  o que não ocorre com o uso dos
procedimentos send e receive
CHAMADA DE PROCEDIMENTO REMOTO

 RPC (Chamada de Procedimento Remoto)

 Um processo da máquina A chama um procedimento da

máquina B

 O processo A é suspenso e o procedimento é executado em B

 Informações podem ser transportadas nos parâmetros e no

resultado do procedimento

 Nenhum aspecto da troca de mensagens é visível para o

programador!
CHAMADA DE PROCEDIMENTO REMOTO

 Principais dificuldades:

 Chamador e procedimento executam em máquinas diferentes,

executando em espaços de endereço diferentes

 Necessário passar parâmetros e resultados  pode ser

complicado quando se trata de máquinas diferentes

 Qualquer uma das duas máquinas pode falhar e cada uma das
possíveis falhas causa problemas diferentes

 Ainda assim, RPC é uma técnica de ampla utilização em SD

CHAMADA DE PROCEDIMENTO
CONVENCIONAL

 Considere uma chamada em C

count = read(fd,buf,nbytes)

 Onde:

 fd é um inteiro
para um arquivo

 buf é um vetor
de caracteres

 nbytes um inteiro
que informa quantos
bytes devem ser lidos
CHAMADA DE PROCEDIMENTO
CONVENCIONAL

 Em C, a passagem de parâmetros pode ser por valor ou por

referência

 Por Valor

 O parâmetro de valor como fd ou nbytes, simplesmente é

copiado para a pilha

 O procedimento chamado pode modificar o valor, mais tais

alterações não afetam o valor original no lado chamador
CHAMADA DE PROCEDIMENTO
CONVENCIONAL

 Por Referência

 O parâmetro é um ponteiro para a variável  o endereço da

variável

 Se o procedimento chamado usa esse parâmetro para

armazenar algo, ele realmente modifica o seu valor no
processo chamador

 No exemplo, buf é passado por referência  vetores sempre

são passados por referência em C
CHAMADA DE PROCEDIMENTO
CONVENCIONAL

 Passagem de parâmetro Copiar/Restaurar

 Este mecanismo não é empregado na linguagem C

 O chamador copia a variável para a pilha, como em uma

chamada por valor

 Após a execução, o valor (modificado ou não) é então copiado

de volta  sobrescrevendo o valor original do chamador

 Na maioria dos casos, possui o mesmo efeito que uma

chamada por referência

 Porém, quando o mesmo parâmetro está presente na lista mais de

uma vez, o efeito é diferente
CHAMADA DE PROCEDIMENTO REMOTO

A ideia fundamental é fazer com que uma chamada

de procedimento remoto pareça com uma
chamada local  Transparência

 A Transparência é alcançada com o uso de stubs  apêndices

 Stub do cliente

 Stub do servidor
CHAMADA DE PROCEDIMENTO REMOTO

 Stub do cliente

 Responsável por empacotar os parâmetros em uma mensagem

e enviá-la para a máquina do servidor

 Quando a resposta chega, o resultado é copiado para o cliente,

e o controle volta a ele

 Stub do servidor

 Responsável por desempacotar os parâmetros

 Chama o procedimento do servidor e retorna a resposta para

máquina do cliente
CHAMADA DE PROCEDIMENTO REMOTO

STUB DO CLIENTE

 Em um sistema tradicional, read é um procedimento que faz

uma chamada de sistema ao SO

 Com RPC uma versão diferente do read é colocada na

biblioteca  stub/apêndice do cliente

 Ela empacota os parâmetros em uma mensagem e pede que

esta mensagem seja enviada para o servidor

 O apêndice de cliente efetua o send e o receive, bloqueando a

si mesmo até que a resposta volte
CHAMADA DE PROCEDIMENTO REMOTO
CHAMADA DE PROCEDIMENTO REMOTO

STUB DO SERVIDOR

 Quando a mensagem chega ao servidor, o SO do servidor a

repassa para um stub de servidor

 Equivalente ao stub de cliente  transforma requisições que

vêm pela rede em chamadas de procedimento locais

 Desempacota os parâmetros da mensagem vinda do cliente e

executa o procedimento do servidor

 O resultado é armazenado em um buffer e devolvido ao stub do

servidor, que empacota os dados e o envia ao stub do cliente
ETAPAS DE PROCEDIMENTO REMOTO
1. Procedimento de cliente chama o stub de cliente do modo normal

2. O stub de cliente constrói uma mensagem e chama o SO local

3. O SO do cliente envia a mensagem para o SO remoto

4. O SO remoto dá a mensagem ao stub de servidor

5. O stub de servidor desempacota os parâmetros e chama o serviço

6. O servidor faz o serviço e retorna o resultado para o stub

7. O stub de servidor empacota o resultado em uma mensagem e

chama o SO Local

8. O SO do servidor envia a mensagem ao SO do cliente

9. O SO do cliente dá a mensagem ao stub de cliente

10. O stub desempacota o resultado e retorna ao cliente

RPC – PASSAGEM DE PARÂMETROS
(ADD)

 Considerando um procedimento remoto add(i,j), que pega 2

elementos inteiros, i e j, e retorna sua soma aritmética como
resultado (passagem por valor):
RPC – PASSAGEM DE PARÂMETROS
import channel, pickle

class DBList:
def append(self, data):
self.value = self.value + [data]
return self

class Client:
def append(self, data, dbList):
msglst = (APPEND, data, dbList) # message payload
self.chan.sendTo(self.server, msglst) # send msg to server
msgrcv = self.chan.recvFrom(self.server) # wait for response
return msgrcv[1] # pass it to caller

class Server:
def append(self, data, dbList):
return dbList.append(data)

def run(self):
while True:
msgreq = self.chan.recvFromAny() # wait for any request
client = msgreq[0] # see who is the caller
msgrpc = msgreq[1] # fetch call & parameters
if APPEND == msgrpc[0]: # check what is being requested
result = self.append(msgrpc[1], msgrpc[2]) # do local call
self.chan.sendTo([client],result) # return response
RPC – PASSAGEM DE PARÂMETROS
import channel, pickle

class Client:
def append(self, data, dbList):
msglst = (APPEND, data, dbList) # message payload
msgsnd = pickle.dumps(msglst) # wrap call
self.chan.sendTo(self.server, msgsnd) # send request to server
msgrcv = self.chan.recvFrom(self.server) # wait for response
retval = pickle.loads(msgrcv[1]) # unwrap return value
return retval # pass it to caller

class Server:
def run(self):
while True:
msgreq = self.chan.recvFromAny() # wait for any request
client = msgreq[0] # see who is the caller
msgrpc = pickle.loads(msgreq[1]) # unwrap the call
if APPEND == msgrpc[0]: # check what is being requested
result = self.append(msgrpc[1], msgrpc[2]) # do local call
msgres = pickle.dumps(result) # wrap the result
self.chan.sendTo([client],msgres) # send response
RPC – PASSAGEM DE PARÂMETROS -
VALOR

 Problemas:

 A chamada do procedimento remoto add somente funcionará

se as máquinas do cliente e do servidor forem idênticas

 Em sistemas com vários tipos de máquinas, cada uma pode ter

sua própria representação de números, caracteres e outros
tipos de dados

 Representação diferentes para caracteres (ASCII x EBCDIC);

 Ordenação de bytes
RPC – PASSAGEM DE PARÂMETROS -
REFERÊNCIA

 Um ponteiro só é significativo dentro do espaço de endereço

do processo no qual está sendo usado

 Memória distribuída  diferente espaços de endereçamento

 Passagem de parâmetros por referência  Muito difícil

 Considerando o exemplo da função read:

 Passar o endereço do parâmetro buf não faz sentido!

 Solução: copiar o vetor para a mensagem e enviá-la ao servidor

 Similar à passagem de parâmetros copiar/restaurar  mesmo efeito

da chamada por referência, modificando o valor ao fim da chamada
RPC – PASSAGEM DE PARÂMETROS -
REFERÊNCIA

 No caso do read, suponha que o stub do cliente saiba que

 O parâmetro buf aponta para um conjunto de caracteres e o
tamanho do vetor buf

 Solução:
 Copiar o vetor para a mensagem e enviar ao servidor
 O stub do servidor pode chamar o servidor com um ponteiro para
este vetor
 Modificação feita pelo servidor é armazenada diretamente no vetor
que está no stub
 Ao enviar o vetor de volta ao stub do cliente, o vetor é copiado de
volta ao cliente
 Se os stubs souberem se o buffer é um parâmetro de entrada ou
um parâmetro de saída, uma das cópias pode ser eliminada
CHAMADA DE PROCEDIMENTO REMOTO

Especificação de parâmetros e geração de stubs

 É necessário definir o formato da mensagem, de modo que o

chamador e o chamado sigam as mesmas etapas

 Ambos necessitam concordar com as definições de tipo (ex.:

char: unicode 16 bits, int: complemento de dois, float: IEEE
#754, little endian);

 Definição de protocolo de comunicação a ser usado

 Após definir o protocolo para RPC é preciso implementar os

stubs de cliente e servidor
CHAMADA DE PROCEDIMENTO REMOTO

Especificação de parâmetros e geração de stubs

 Definir a interface a ser chamada pelo cliente e implementada

no servidor

 Para simplificar, interfaces costumam ser especificadas por

uma IDL – Interface Definition Language

 Uma interface definida por IDL é compilada para gerar um stub de

cliente e um stub de servidor

 IDL simplifica aplicações cliente-servidor baseadas em RPCs

 Sistemas de middleware baseados em RPC oferecem uma IDL para

suportar desenvolvimento de aplicação
CHAMADA DE PROCEDIMENTO REMOTO

 Resumindo:

 Permite a um cliente o acesso a um serviço remoto por meio

de uma simples chamada a um procedimento local

 Possibilita que programas clientes sejam escritos de modo

simples

 Pode localizar automaticamente o servidor correto

 Estabelece a comunicação entre software cliente e software

servidor
RPC ASSÍNCRONA

 Fornecem facilidades de modo a não bloquear o cliente

quando não há nenhum resultado a esperar
RPC ASSÍNCRONA

 Também podem ser úteis quando uma resposta será

retornada mas o cliente não está preparado para esperar
por ela
 Enquanto espera, o cliente pode realizar outras tarefas

 São combinadas duas RPCs assíncronas  denominada

RPC assíncrona deferida

 O cliente pode, também, não esperar aceite do servidor e

continuar sua execução  RPC de uma via
 Quando a confiabilidade não é garantida, o cliente não
saberá se a requisição será ou não processada
RPC ASSÍNCRONA DEFERIDA