Sistemas Distribuídos

Comunicação
Porf Lahoz
Apoio: Prof. André Y. Kusumoto
 Comunicação nos SD
Elementos básicos de comunicação em SDs

•  Transmissão de dados
•  Endereçamento
•  Sincronismo
•  Enfileiramento (Bufferização)
•  Confiabilidade
•  Modelo Cliente-Servidor
 Transmissão de dados
Dados em programas são estruturados enquanto que mensagens
carregam informação sequencial:
» Linearização/Restauração de dados

Heterogeneidade na representação de dados em computadores:

» Uso de um formato externo comum
» Inclusão de uma identificação de arquitetura na mensagem
 Transmissão de dados
Como lidar com representação de dados diferentes?
Como organizar os bytes de uma palavra (32 bits) na memória do
computador? Ex: little-endian x big-endian

Chegaram 32 bits da rede, como organizar na memória?

little endian ou big endian? depende de quem mandou!
 Transmissão de dados
Ideia: Converter dados para representação que não dependa da máquina
•  de comum acordo entre os dois lados; cada lado faz sua parte
•  encapsulado “fora” do programa
Usar também para strings, floats, tipos mais complicados (structs), etc.

Stubs: em SD é um trecho de código que converte parâmetros

transmitidos entre cliente e servidor durante uma chamada de
procedimento remoto (RPC).
É o código responsável por marshalling e unmarshalling dos parâmetros
•  oferecido pela biblioteca, de uso obrigatório, mas transparente
(programador não sabe)
•  descrevem os parâmetros da função através de algum padrão, como
XML
 Transmissão de dados
Marshalling (arranjo):
•  Linearização de uma coleção de itens de dados estruturados
•  Tradução dos dados em formato externo

Unmarshalling (desarranjo):
•  Tradução do formato externo para o local
•  Restauração dos itens de dados de acordo com sua estrutura
 Transmissão de dados
Passos (retorno assimétrico)
 Transmissão de dados
Função dos Stubs

Client stub: intercepta a chamada, empacota os parâmetros

(marshalling), envia mensagem de request ao servidor (através do
núcleo).

Server stub: recebe a mensagem de request (através do núcleo),

desempacota os parâmetros (unmarshalling), chama o procedimento,
passando os parâmetros, empacota o resultado, envia mensagem de
reply ao cliente (através do núcleo).

Client stub: recebe a mensagem de reply (através do núcleo),

desempacota o resultado, passa o resultado para o cliente
 Endereçamento
Esquemas:

Endereçamento máquina.processo
Endereçamento máquina.id-local
Descoberta de endereço via broadcasting (difusão)
Descoberta de endereço via um servidor de nomes

Problemas potenciais: transparência de localização, sobrecarga,

escalabilidade
 Endereçamento
Para que um processo possa enviar mensagens a um processo remoto,
ele precisa conhecer o endereço desse processo.

•  endereço, end, de um processo deve identificar numa primeira

instância a máquina na qual ele está executando e depois, quem é ele
entre os vários processos executando naquela máquina.

•  De posse desse endereço, qualquer processo pode invocar a primitiva

send( end, &msg ) do sistema para enviar mensagens ao outro
processo ou então a primitiva receive( end, &msg) quando desejar
receber mensagens desse processo
 Endereçamento
Vários esquemas de endereçamento podem ser utilizados, cada um
apresenta vantagens e desvantagens:
a) Endereçamento máquina.processo: neste esquema o endereço de
um processo é formado por duas partes, a primeira parte é o endereço
da máquina onde o processo está executando e a segunda parte é o
endereço do processo dentro da máquina.
Supondo a existência de uma máquina cujo endereço IP seja
200.131.209.193 e a existência de um número que identifica um
processo dentro daquela máquina como o processo 5291, o endereço
do processo poderia ser expresso como 200.131.209.193.5291.
 Endereçamento
Vários esquemas de endereçamento podem ser utilizados, cada um
apresenta vantagens e desvantagens:
a)  Endereçamento máquina.processo:
Este esquema apresenta dois problemas. O primeiro diz respeito à
transparência à migração que todo sistemas distribuído deve prover. O
fato de usarmos o endereço da máquina como parte do endereço
quebra tal transparência uma vez que o processo 5291 não poderia
migrar para outra máquina sem causar problema, pois os processos
que precisam comunicar-se com ele não o encontrariam mais.
Além disso, para garantir a transparência á migração deveríamos garantir
que nenhum outro processo em todo o sistema fosse identificado pelo
número 5291, ou seja, que o identificador 5291 tivesse um escopo
global, pois só dessa forma o processo 5291 poderá ser encontrado
caso migrasse para uma outra máquina do sistema.
 Endereçamento
Vários esquemas de endereçamento podem ser utilizados, cada um
apresenta vantagens e desvantagens:
a)  Endereçamento máquina.processo:
Neste momento é que surge o segundo problema. Que método seria
utilizado para gerar identificadores universais para todos os processos
do sistema? Este método iria interferir na confiabilidade ou
desempenho do sistema distribuído?
Por exemplo, centralizar a reponsabilidade de gerar esses identificadores
em um único processo do sistema, com certeza, iria criar um novo
gargalo no sistema além de fazer com que todo o sistema dependa do
bom funcionamento de um único processo.
 Endereçamento
Vários esquemas de endereçamento podem ser utilizados, cada um
apresenta vantagens e desvantagens:
b) Endereçamento máquina.id-local:
Grande parte do esquema de comunicação do UNIX de Berkley utiliza um
esquema um pouco diferente desse: endereçamento máquina.local-
ident. O campo máquina é o endereço IP de 32 bits da máquina e o
campo local-ident é um número de 16 bits escolhido randômicamente
pelo próprio processo.
Um processo começa sua execução com uma chamada ao núcleo do
sistema para informá-lo que seu identificador é local-ident. A
probabilidade de um processo escolher um ident-local que esteja
sendo utilizado é remota, mas caso isso aconteça o processo deverá
escolher outro identificador.
 Endereçamento
Vários esquemas de endereçamento podem ser utilizados, cada um
apresenta vantagens e desvantagens:
c) Endereçamento de processo em broadcast: neste método um
processo possui um endereço que não depende do endereço da
máquina onde está rodando.
Quando um processo A precisa comunicar-se com um processo B, o
processo precisa antes de qualquer coisa enviar uma mensagem
broadcast na rede perguntado "Que máquina está executando o
processo B?".
Todas as máquinas receberão esta mensagem, mas somente a máquina
que estiver o processo B responderá enviando o seu endereço para o
processo.
 Endereçamento
Vários esquemas de endereçamento podem ser utilizados, cada um
apresenta vantagens e desvantagens:
c) Endereçamento de processo em broadcast: problema com este
esquema é que ele pode causar muita sobrecarga na rede, pois todo
processo para comunicar-se com outro precisará executar um
broadcast.
Além disso, um processo terá sempre que esperar pelo endereço da
máquina que executa o processo com quem deseja se comunicar, esta
fato torna-se ainda mais grave a penalização que a comunicação entre
processos impõe ao desempenho dos sistemas distribuídos.
 Endereçamento
Vários esquemas de endereçamento podem ser utilizados, cada um
apresenta vantagens e desvantagens:
d) Endereçamento de através de servidores de nome: no esquema de
endereçamento através de servidores de nome um processo extra é
utilizado para mapear o nome de serviços escritos em alto nível
(ASCII), para endereços de máquina.
Este processo é chamado servidor de nome.
 Endereçamento
Vários esquemas de endereçamento podem ser utilizados, cada um
apresenta vantagens e desvantagens:
d) Endereçamento de através de servidores de nome:
Serviços são facilidades que processos servidores oferecem a outros
processos do sistema. Um serviço está sempre associado a um porto
padronizado por convenção, por exemplo, o serviço de ftp é associado
ao porto 21 e o serviço de e-mail é associado ao porto 25.
Desta forma, quando o processo deseja solicitar um serviço, ele primeiro
deve consultar o servidor de nome para saber o endereço da máquina
que executa o processo que fornece o serviço e depois ele deve
conectar-se a esta máquina informando o porto que corresponde ao
serviço que ele deseja.
 Comunicação síncrona e assíncrona
A comunicação entre processos pode ocorrer de duas maneiras
diferentes: síncrona e assíncrona.

Na comunicação síncrona quando um processo invoca a primitiva

send(addr, &buffer) para enviar uma mensagem a outro processo, a
sua execução fica suspensa até que a mensagem realmente chegue
ao processo destinatário. Quando um processo invoca a primitiva
receive( addr, &buffer), a execução desse processo fica suspensa até
que uma mensagem vinda do processo addr chegue.
A comunicação síncrona também é conhecida como comunicação com
bloqueio ou bloqueante.
 Comunicação síncrona e assíncrona
Na comunicação síncrona:

Um aspecto importante da comunicação síncrona é a necessidade do uso

de temporizadores. Este temporizadores deverão ser utilizados para
evitar que processos fiquem eternamente esperando pela confirmação
do envio de uma mensagem ou pela chegada de uma mensagem
gerada por outro processo.
 Comunicação síncrona e assíncrona
Na comunicação síncrona:

Primitiva send é bloqueante: processo cliente aguarda enquanto o núcleo

envia a mensagem para o processo servidor.

Primitiva receive é bloqueante: processo servidor aguarda até que o

núcleo receba uma mensagem endereçada para aquele processo.
 Comunicação síncrona e assíncrona
Primitivas para Troca de mensagens:
Primitivas bloqueadas
•  Também chamadas de primitivas síncronas.
•  Quando um processo chama send, ele especifica um destino e um buffer,
cujo conteúdo deve ser enviado a este destino.
•  Enquanto a mensagem estiver sendo enviada, o processo que está
enviando fica bloqueado (ou seja, suspenso).
•  A instrução seguinte à chamada send , não será executada até que a
mensagem tenha sido completamente enviada.
•  De forma similar, uma chamada para receive não retorna o controle até
que a mensagem tenha sido realmente recebida.
•  O processo permanece suspenso em receive, até que a mensagem
chegue, mesmo que isto demore algumas horas.
 Comunicação síncrona e assíncrona
Na comunicação assíncrona: a execução de um processo não é
bloqueda quando o processo invoca a primitiva send ou receive.

A comunicação assíncrona é a que apresenta um menor custo em

termos de desempenho, pois permite ao sistema distribuído explorar
ao máximo o paralelismo de processamento e comunicação.
Entretanto, é a forma de comunicação que apresenta maiores
dificuldades de implementação, além de criar novos problemas para o
programador. Por exemplo, suponha que um processo tenha invocado
de forma assíncrona a primitiva send(addr, &buffer) e que portanto,
sua execução tenha continuado a ser realizada.
 Comunicação síncrona e assíncrona
Quando este processo, enviado de forma assíncrona, terá certeza que
pode alterar o conteúdo da variável buffer sem alterar a informação a
ser trocada durante a comunicação? A resposta é simples, não há
como. Duas soluções podem ser dadas para este problema:

1) antes de ser enviada toda mensagem deve ser copiada para uma área
de armazenamento temporário interna ao núcleo do sistema. Assim,
qualquer alteração no conteúdo da variável buffer não influenciará a
comunicação em andamento. Fatores críticos para esta estratégia é a
determinação do tamanho dessa área de armazenamento temporário
e o número máximo permitido de mensagens assíncronas sendo
enviadas.
 Comunicação síncrona e assíncrona

2) sempre que uma mensagem terminar de ser entregue ao seu destino,

o processo que a gerou deverá ser interrompido e informado do fato,
ou seja, uma interrupção será gerada na máquina do processo que
originou a mensagem. Porém, o uso de interrupções torna o
programação dos processos comunicantes mais difícil, além de quase
impossibilitar a depuração dos mesmos.
 Comunicação síncrona e assíncrona

Comunicação assíncrona:

Primitiva send não é bloqueante: o processo cliente aguarda somente

enquanto a mensagem é copiada para o buffer do núcleo.

Primitiva receive pode ser:

bloqueante: o processo servidor aguarda por uma mensagem.
não bloqueante: o processo servidor simplesmente comunica o núcleo
que espera receber uma mensagem.
 Comunicação síncrona e assíncrona
Primitivas para Troca de mensagens
Primitivas Não-bloqueadas
•  Algumas vezes chamadas de primitivas assíncronas.
•  Se send não é bloqueada, ele devolve o controle ao processo que chamou
imediatamente, antes do envio da mensagem.
•  A vantagem deste esquema é que o processo que envia a mensagem
pode continuar processando em paralelo com a transmissão da
mensagem, em vez do seu processador permanecer ocioso durante este
tempo.
•  A escolha entre primitivas bloqueadas e não-bloqueadas é normalmente
feita pelo projetista do sistema, apesar de em alguns sistemas ambas
estarem disponíveis.
 Enfileiramento (bufferização)
Situações:

send ocorre antes de receive

Um cliente faz um send enquanto o servidor ainda atende a outro cliente

Solução trivial: clientes devem insistir ...

Solução pragmática: mailbox (uma fila de mensagens controlada pelo
núcleo):
mailbox criado a pedido do servidor
mensagens endereçadas ao mailbox
 Enfileiramento (bufferização)

Suponha que um processo A envie uma mensagem M para um processo

B, mas que o processo B ainda não tenha executado a primitiva
receive(addrA, &buffer), ou seja, que o processo B ainda não esteja
esperando por uma mensagem.

Quando a mensagem chegar à máquina onde o processo B está

executando o sistema operacional deverá descartar a mensagem ou
esperar que o processo B a solicite?

O que acontecerá se o processo B nunca requisitar a mensagem M?

 Enfileiramento (bufferização)
Duas soluções podem ser adotadas para resolver este problema.

A primeira solução, e a menos desejada, é simplesmente proibir que um

processo invoque a primitiva send se não houver um lugar para
armazená-la na máquina destino. Isto é, o processo transmissor ficará
bloqueado até o processo destino invoque a primitiva receive.

A segunda solução faz uso de um buffer interno ao núcleo do sistema

operacional chamado mailbox e de temporizadores. A medida que as
mensagens são recebidas elas vão sendo inseridas no mailbox que
funciona como uma fila de mensagens e para cada mensagem um
novo temporizador é iniciado com o objetivo de medir o tempo de
permanência da mensagem no mailbox.
 Enfileiramento (bufferização)
Duas soluções podem ser adotadas para resolver este problema.

Conforme os processos forem requisitando as mensagens, estas vão

sendo retiradas do mailbox.

Se nenhum processo requisitar uma determinada mensagem e seu

temporizador atingir um valor máximo permitido, a mensagem é
descartada. O problema com a segunda solução é a sobrecarga
gerada pela manutenção dos mailboxes.
 Enfileiramento (bufferização)
Duas soluções podem ser adotadas para resolver este problema.

Conforme os processos forem requisitando as mensagens, estas vão

sendo retiradas do mailbox.

Se nenhum processo requisitar uma determinada mensagem e seu

temporizador atingir um valor máximo permitido, a mensagem é
descartada. O problema com a segunda solução é a sobrecarga
gerada pela manutenção dos mailboxes.
 Confiabilidade
Principais problemas:
-  mensagens se perdem, atrasam, duplicam.
-  send tem semântica não confiável: as aplicações devem garantir
entrega de mensagens (ex: timeout)

Solução:
Mensagem de acknowledgement enviada pelo servidor (no nível núcleo)
Mensagem de acknowledgement implícita na resposta do servidor
 Confiabilidade
Muitas vezes o envio de uma mensagem deve ser confiável, isto é, o
processo que enviou a mensagem deve receber uma confirmação do
processo destino informando o perfeito recebimento da mensagem.

Este mecanismo evitaria que uma mensagem perdida ou corrompida

atrapalhe o funcionamento do sistema.

Num arquitetura cliente-servidor a confirmação pode ser necessária tanto

para garantir que um servidor recebeu a solicitação de um cliente
como para garantir que um cliente recebeu a resposta de um servidor.
 Confiabilidade
Como tanto a solicitação do cliente como a resposta do servidor são
recebidas pelo núcleo do sistema operacional na forma mensagens a
serem entregues aos processos servidor e cliente, respectivamente, o
próprio núcleo do sistema poderia confirmar o recebimento dessas
mensagens evitando-se que esses processos tivessem que fazê-lo,
resultando num melhor desempenho do sistema.
 Confiabilidade
Para melhorar ainda mais o desempenho do sistema, quando o
processamento solicitado por um cliente for muito pequeno, em termos
computacionais, a própria resposta a esta solicitação poderia ser
utilizada como confirmação.

Desta forma, não será necessário o envio de duas mensagens para o

mesmo processo onde um intervalo de tempo muito pequeno
separaria uma mensagem da outra, evitando-se sobrecargas na rede
de comunicação do sistema distribuído.
 Modelo C-S
Modelo Cliente-Servidor
•  O modelo cliente-servidor é baseado em um protocolo muito simples, sem
conexão do tipo solicitação/resposta.
•  O cliente envia uma mensagem ao servidor solicitando algum tipo de
serviço, como por exemplo, a leitura de um determinado arquivo. O
servidor faz o trabalho e envia para o cliente os dados solicitados, ou um
código de erro indicando a razão do trabalho não ter sido realizado.

Request para 243

Replay para 199

 Modelo C-S
Modelo Cliente-Servidor
•  A primeira vantagem desse modelo é a simplicidade.
•  E como consequência disso, a eficiência, a pilha de protocolos desse
modelo é bem menor.

•  Os protocolos do nível físico e do enlace de dados

tratam da obtenção dos pacotes.
•  Como não há necessidade de roteamento nem de
estabelecimento de conexão, os níveis 3 e 4 não
são necessários.
•  O nível 5 é o do protocolo de solicitação/resposta, que define um conjunto de solicitações
legais e de respostas aceitas como apropriadas para tais solicitações.
•  Nenhum dos outros níveis superiores é necessário.
 Modelo C-S
Pacotes em protocolo Cliente-Servidor (C-S)

Código Tipo De Para Descrição

REQ Request C S O cliente deseja um

serviço
REP Reply S C Resposta do servidor para
o cliente
ACK Ackowledgment x y O pacote anterior chegou

AYA Are you alive? C S Investiga de o servidor

não parou
IAA I am alive S C O servidor não parou

TA Try again S C O servidor está lotado

AU Address unknown S C Nenhum processo está

usando aquele endereço
 Comunicação Grupal
•  Um grupo é um conjunto de processos que agem juntos.
•  A propriedade fundamental de um grupo é que quando uma mensagem
é enviada para o grupo, todos os membros desse grupo devem recebê-la.
•  Esta é uma forma de comunicação de um-para-muitos (um transmissor,
muitos receptores), que contrasta com a comunicação ponto-a-ponto.
 Comunicação Grupal
•  Um grupo é um conjunto de processos que agem juntos.
•  A propriedade fundamental de um grupo é que quando uma mensagem
é enviada para o grupo, todos os membros desse grupo devem recebê-la.
•  Esta é uma forma de comunicação de um-para-muitos (um transmissor,
muitos receptores), que contrasta com a comunicação ponto-a-ponto.
 Comunicação Grupal
Objetivos:

• Tolerância a falhas baseada na replicação de serviços

• Localização de objetos em serviços distribuídos
• Melhor desempenho via replicação de dados
• Múltipla atualização
 Comunicação Grupal
Tipos de grupos:

Visibilidade:
• Aberto: um processo fora do grupo consegue enviar mensagens para o
grupo todo
• Fechado: somente processos do grupo enviam mensagens para o grupo
todo

Organização:
• Peer: todos os processos tomam decisão
• Hierárquico: decisão é centralizada
 Comunicação Grupal

Endereçamento de grupo (implementar a comunicação grupal):

•  Multicast - um processo envia uma mensagem simultânea e somente
para os membros do grupo. (envio de pacotes para um conjunto de
máquinas).
•  Broadcast - um processo envia uma mensagem para todas as
máquinas e somente as que contêm um membro do grupo a assimila
(envio de pacotes para todas as máquinas).
•  Unicast – envio de uma mensagem de um único transmissor para um
único receptor (envia uma mensagem para todos os membros do
grupo em série). Apesar de ser menos eficiente, este esquema
funciona relativamente bem, sobretudo se o número de membros dos
grupos for pequeno um processo.
 Comunicação Grupal

Modificações no grupo:

Controle centralizado: servidor de grupo

Controle descentralizado: acordo entre os membros

Operações:
Entrada de um membro: atualizar estado
Saída de um membro: se involuntária (ex: parada), todos os membros
restantes devem notar sua saída.
 Comunicação Grupal

Primitivas de comunicação:

GroupSend: envia mensagem para todos os membros do grupo

GroupReceive: aguarda mensagem enviada a todo o grupo

GetReply: aguarda resposta de todos os membros do grupo após um

GroupSend
 Comunicação Grupal

Ordenação das mensagens

Todas as mensagens enviadas a um grupo devem chegar a todos os

processos na mesma ordem.

Abordagens:
• Ordenação por tempo global
• Ordenação por tempo consistente: somente uma mensagem por vez é
difundida
 Protocolos em Camadas
•  Em sistemas distribuídos, toda comunicação entre os nós é baseada em
troca de mensagens. Quando uma máquina A quer se comunicar com a
máquina B, ela monta uma mensagem e a envia através da rede.

•  Essa comunicação deve conter regras e convenções pré-definidas.

•  Para reduzir a complexidade de projeto, a maioria das redes foi
organizada como uma série de camadas ou níveis.

•  Cada camada foi colocada em cima da outra com funcionalidades, nomes

e conteúdos específicos, implementada com o objetivo de oferecer
serviços para as camadas superiores.
 Protocolos em Camadas
Conceito de Interface e Protocolo
Temos dois tipos de protocolos definidos no modelo OSI:
Protocolos orientados à conexão. Ex. TCP
Protocolos sem conexão. Ex. UDP
 Protocolos em Camadas
Protocolos orientados à conexão. Ex. TCP
•  Antes de trocar dados, o remetente e o receptor primeiro estabelecem
explicitamente uma conexão e possivelmente negociam o protocolo
que usarão. Após concluírem, devem liberar a conexão. O telefone é
um exemplo de protocolo orientado a conexão.

Protocolos sem conexão. Ex. UDP

•  Não é preciso estabelecer uma conexão antecipadamente. O
remetente apenas transmite a primeira mensagem quando estiver
pronta. Um exemplo de comunicação sem conexão é colocar uma
carta em uma caixa de correio
 RPC
Chamada Remota a Procedimento – Remote Procedure Call

Comunicação baseada em operações de entrada/saída: abstração fraca,

sujeito a erros.

Ideal: programar um sistema distribuído como se fosse centralizado.

RPC objetiva permitir chamada de procedimento remoto como se fosse

local, ocultando entrada/saída de mensagens.
 RPC
Remote Procedure Call:

• Consiste na permissão de execução de procedimentos localizados em

outras máquinas por programas locais, fazendo com que a chamada remota
se pareça tanto quanto possível com uma chamada local, isto é, deve ser
transparente.

• O procedimento que chama não deve se preocupar com o fato do

procedimento chamado estar ou não rodando em uma máquina diferente, ou
vice-versa.
 RPC
Remote Procedure Call:

•  Desviando o fluxo de execução para uma máquina remota, passando

argumentos e recebendo valores de resposta.
•  Permite a um processo executar uma “subrotina” em um outro processo,
possivelmente remoto
• Por exemplo, processo P executa função pow() que faz parte do Processo Q
 RPC
Remote Procedure Call:

Processo P executa função pow() que faz parte do Processo Q

 RPC
Remote Procedure Call:

Justificativa para criação de RPC foi que “passagem de mensagens” era um

mecanismo complexo e dificultava desenvolvimento de aplicações
distribuídas

RPC “esconde” troca de mensagens em chamadas de procedimentos sintaxe

próxima a chamadas em linguagens tradicionais facilitou conversão de
aplicações legadas em distribuídas
 RPC
Remote Procedure Call:
Outro exemplo:

• Um processo A chama um procedimento p de um processo B, entrando em

estado de espera

• O processo B passa a executar o procedimento p, e ao seu término faz um

reply para o processo A

• O processo A volta à sua execução normal após ter recebido o reply
 RPC
Chamadas em RPC:

• O procedimento chamador, que já tem suas variáveis locais empilhadas,

empilha os parâmetros da chamada e o endereço de retorno.

• O procedimento chamado aloca suas variáveis locais.

• No retorno do procedimento chamado, os parâmetros e o endereço de

retorno são desempilhados.
 RPC
Chamadas em RPC:
Lado cliente:
• aplicativo, lado cliente, que solicita serviço
• “stub cliente”, gerado automaticamente
• “RPC runtime” do lado do cliente

Lado servidor:
• aplicativo, lado servidor, que recebe solicitação e processa
• “stub servidor”, gerado automaticamente
• “RPC runtime” do lado do servidor

• Código do stub cliente e servidor são compilados

 RPC
Operação Básica da Chamada Remota a Procedimento
•  Para entender com funciona a chamada remota a procedimento, é
importante entender como a chamada a procedimento funciona em uma
máquina convencional.

Parâmetros de uma chamada remota:

Valor: procedimento chamado recebe uma cópia de uma variável conhecida
do procedimento chamador.
Referência: procedimento chamado recebe o endereço de uma variável
conhecida do procedimento chamador.
Cópia/Reescrita: procedimento chamador recebe uma cópia de uma variável
conhecida do procedimento chamador e o valor desta cópia é reescrito na
variável.
 RPC
Chamadas e mensagens em Procedimento Remoto
Máquina do Cliente Máquina do Servidor

2 4
1 empacota desempacota 5
0 parâmetros 6
cliente parâmetros servidor
desempacota empacota
11 resultados resultados 7
10 8

Kernel Kernel

3
transporte de mensagens
9 via rede
 RPC
Operação Básica da Chamada Remota a Procedimento
•  Primeiro, em C os parâmetros podem ser chamados por valor ou por
referência.
•  Um parâmetro chamado por valor é pura e simplesmente copiado da
pilha.
•  Um parâmetro passado por referência é um ponteiro para uma
variável, ou seja, o endereço da variável, em vez do valor da própria
variável.
•  Segundo, denominado de chamada copiar/restaurar.
•  Consiste em fazer uma chamador copiar a variável para a pilha, como
em chamada por valor, e então copiá-la de volta após a chamada.
Sobrescreve o valor original do chamador.
 RPC
Semântica da Chamada Remota a Procedimento em Presença de Falhas
•  Enquanto tanto o cliente quanto o servidor estiverem funcionando
perfeitamente, a chamada remota a procedimento faz seu trabalho de
forma admirável.
•  Os problemas começam com a ocorrência eventual de erros. É aí que não
vai ser fácil mascarar as diferenças entre chamadas locais e remotas.
 RPC
Problemas e Limitações
Obter com RPC mesma semântica de chamada local é difícil, por diversas
razões:

Necessário fase de binding (amarração):

• stub precisa primeiro localizar função (máquina e porta associadas)
• uma solução é uma base de dados com localização das subrotinas, base de
dados possui endereço fixo e conhecido
 RPC
Problemas e Limitações
Obter com RPC mesma semântica de chamada local é difícil, por diversas
razões:

Implementação de passagem de parâmetros por referência:

• na ausência de memória compartilhada, apontadores não tem significado no
processador remoto

Deve tratar exceções (deve estar indicado no código):

• problemas na rede, morte processo servidor, morte do cliente durante a
execução de chamada remota...
 RPC
Problemas e Limitações
Obter com RPC mesma semântica de chamada local é difícil, por diversas
razões:

Semântica das chamadas:

• em chamada local, função é executada uma única vez na rede, há perdas
de mensagens e retransmissões, e falhas de hosts

Há três semânticas diferentes para chamadas remotas: exatamente-uma-vez

(exactly-once), no-máximo-uma (at-most-once) , no-mínimo-uma (at-least-
once)
 RPC
Problemas e Limitações
Obter com RPC mesma semântica de chamada local é difícil, por diversas
razões:

Heterogeneidade e representação de dados:

Arquiteturas possivelmente incompatíveis

• conversão de dados entre diferentes representações
• exemplos de incompatibilidades: ordem, precisão, código de caracteres
 RPC
Problemas e Limitações
Obter com RPC mesma semântica de chamada local é difícil, por diversas
razões:

Desempenho:
overhead é substancial e diminui desempenho por fator de 10+ em relação a
mensagens

Segurança:
permitir execução de procedimentos localmente pode criar “furos” da
segurança
 Classes de Falhas em RPC
Cinco classes diferentes de falhas possíveis de ocorrer nos sistemas
baseados em chamadas remotas a procedimento.

1. O cliente não é capaz de localizar o servidor

2. A mensagem de request do cliente para o servidor é perdida
3. A mensagem de reply do servidor para o cliente é perdida
4. O servidor para após ter recebido a mensagem de request
5. O cliente para após ter enviado a mensagem de request
 Classes de Falhas em RPC
Cinco classes diferentes de falhas possíveis de ocorrer nos sistemas
baseados em chamadas remotas a procedimento.

1. O cliente não é capaz de localizar o servidor

•  O servidor pode estar fora do ar.
•  Em qualquer caso, pode-se optar por utilizar tratamento de erros criando
uma exceção quando não for possível localizar o servidor.
•  Porém, mesmo com esse tipo de mecanismo, o sistema ainda deve
permanecer transparente para o usuário. Mensagens que trazem
informações que possam demonstrar a utilização de sistemas distribuídos
devem ser evitadas.
 Classes de Falhas em RPC
Cinco classes diferentes de falhas possíveis de ocorrer nos RPCs

2. Perda de mensagens solicitando serviços

•  Esse aspecto é o mais fácil de tratar, para isso, um temporizador pode
ser iniciado quando uma mensagem de solicitação for enviada.
•  Se o temporizador expirar antes da chegada de uma resposta, a
mensagem deve ser retransmitida. Se ela tiver realmente se perdido na
rede, o servidor não será capaz de distinguir entre a mensagem
retransmitida e a mensagem original, e tudo vai funcionar muito bem.
•  Observe que pode ocorrer o caso de perda de uma série de mensagens,
fazendo com que seja concluído que o servidor possa ter saído do ar.
 Classes de Falhas em RPC
Cinco classes diferentes de falhas possíveis de ocorrer nos RPCs

3. Perda de mensagens com resposta

•  Também pode ser utilizado o temporizador como alternativa, porém, a
perda de mensagens com resposta pode trazer consequências maiores e
alguns cuidados devem ser tomados.
•  O problema com esta solução é que o kernel do cliente não está seguro a
respeito do motivo pelo qual a resposta não chegou. Será que a
solicitação perdeu-se pela rede? Ou será que quem se perdeu foi a
resposta? Ou será que o servidor é muito lento?
 Classes de Falhas em RPC
Cinco classes diferentes de falhas possíveis de ocorrer nos RPCs

3. Perda de mensagens com resposta (cont)

•  Imagine uma transação bancária de transferência de valores de um
milhão de dólares de uma conta para outra. Se a solicitação for
executada, mas a resposta se perder, pode acontecer do cliente
retransmitir a solicitação. O servidor bancário vai interpretar a requisição
de retransmissão como uma nova requisição e vai executá-la novamente.
Dois milhões de dólares vão ser efetivamente transferidos.
•  Um método para resolver esse problema é fazer com que cada kernel
do cliente atribua a cada requisição um número sequencial. Uma
salvaguarda adicional é inserir um bit no cabeçalho distinguindo a
mensagem original de uma mensagem retransmitida.
 Classes de Falhas em RPC
Cinco classes diferentes de falhas possíveis de ocorrer nos RPCs

4. Quedas do Servidor
•  Em primeiro lugar, chega uma requisição; a seguir, ela é executada, e
finalmente uma resposta é enviada de volta.
•  Agora considere o caso onde a requisição é executada, exatamente
como no caso anterior, mas, depois disto, o servidor sai do ar antes de
enviar a resposta.
•  Por fim, considere o caso aonde novamente chega uma requisição, mas
agora, o servidor para de funcionar antes de processá-la.
 Classes de Falhas em RPC
Cinco classes diferentes de falhas possíveis de ocorrer nos RPCs

4. Quedas do Servidor (cont)

Passos normais: (1) recebe mensagem de request; (2) executa
procedimento; (3) envia mensagem de reply

Falha pode ocorrer: (1) após a execução; (2) antes da execução

Semânticas de chamada: (1) pelo menos um; (2) no máximo um; (3)
exatamente um
 Classes de Falhas em RPC
Cinco classes diferentes de falhas possíveis de ocorrer nos RPCs

5. Queda do Cliente
•  O que acontece quando um cliente manda uma mensagem para um
servidor solicitando algum trabalho e sai do ar antes que o servidor tenha
podido responder?
•  Neste caso, está sendo realizado um processamento sem que nenhum
cliente esteja esperando por ele. Tal processamento é denominado
processamento órfão, e deve ser evitado a todo custo, pois podem
ocasionar inúmeros problemas.
•  No mínimo, os processamentos órfãos gastam o precioso tempo do
processador. Eles também podem bloquear arquivos, ou ocupar recursos
escassos, e portanto valiosos.
 Classes de Falhas em RPC
Cinco classes diferentes de falhas possíveis de ocorrer nos RPCs

5. Queda do Cliente (cont)

O servidor torna-se um “órfão”
Soluções:
•  exterminação do servidor pela máquina do cliente
•  reencarnação do cliente: toda computação remota é destruída
•  "reencarnação" suave do cliente: somente as computações remotas
referentes a aquele cliente são destruídas
•  expiração: servidor estabelece um timeout para confirmação