sistemas distribuÍdos - uffsimone/sd/contaulas/aula7.pdfsistemas distribuídos o que não ocorre...

SISTEMAS DISTRIBUÍDOSCAPÍ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 domiddleware

•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 entregade 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


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!


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


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


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


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


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


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


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


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ÂMETROSimport 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:


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ÂMETROSimport channel, pickle

class Client:


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


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


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


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

sistemas distribuÍdos - uffsimone/sd/contaulas/aula7.pdfsistemas distribuídos o que não ocorre...

Documents