Post on 07-Jun-2020
mcta025-13 - sistemas distribuídoscomunicação
Emilio Francesquini02 de julho de 2018
Centro de Matemática, Computação e CogniçãoUniversidade Federal do ABC
disclaimer
• Estes slides foram preparados para o curso de SistemasDistribuídos na UFABC.
• Este material pode ser usado livremente desde que sejammantidos, além deste aviso, os créditos aos autores einstituições.
• Estes slides foram adaptados daqueles originalmentepreparados (e gentilmente cedidos) pelo professor DanielCordeiro, da EACH-USP que por sua vez foram baseadosnaqueles disponibilizados online pelos autores do livro“Distributed Systems”, 3ª Edição em:https://www.distributed-systems.net.
1/29
protocolos em camadas
• Camadas de baixo nível• Camada de transporte• Camada de aplicação• Camada do middleware
2/29
modelo de comunicação básico
Physical
Data link
Network
Transport
Session
Application
Presentation
Application protocol
Presentation protocol
Session protocol
Transport protocol
Network protocol
Data link protocol
Physical protocol
Network
1
2
3
4
5
7
6
Desvantagens:
• Funciona apenas com passagem de mensagens• Frequentemente possuem funcionalidades desnecessárias• Viola a transparência de acesso
3/29
camadas de baixo nível
Camada física: contém a especificação e implementação dos bitsem um quadro, e como são transmitidos entre oremetente e destinatário
Camada de enlace: determina o envio de séries de bits em umquadro, permite detecção de erro e controle de fluxo
Camada de rede: determina como pacotes são roteados em umarede de computadores
Observação:Em muitos sistemas distribuídos, a interface de mais baixo nível é ainterface de rede.
4/29
camada de transporte
Importante:A camada de transporte fornece as ferramentas de comunicaçãoefetivamente utilizadas pela maioria dos sistemas distribuídos.
Protocolos padrões da Internet
TCP: orientada a conexão, confiável, comunicação orientadaa fluxo de dados
UDP: comunicação de datagramas não confiável (best-effort)
Nota:IP multicasting é normalmente considerado um serviço padrão (masessa é uma hipótese perigosa)
5/29
camada de middleware
Middleware foi inventado para prover serviços e protocolosfrequentemente usados que podem ser utilizados por váriasaplicações diferentes.
• Um conjunto rico de protocolos de comunicação• (Des)empacotamento [(un)marshaling] de dados, necessáriospara a integração de sistemas
• Protocolos de gerenciamento de nomes, para auxiliar ocompartilhamento de recursos
• Protocolos de segurança para comunicações seguras• Mecanismos de escalabilidade, tais como replicação e caching
Observação:O que realmente sobra são protocolos específicos de aplicação.
6/29
tipos de comunicação
Client
Server
Synchronize after processing by server
Synchronize at request delivery
Synchronize at request submission
Request
Reply
Storage facility
Transmission interrupt
Time
• Comunicação transiente vs. persistente• Comunicação assíncrona vs. síncrona
7/29
tipos de comunicação
Client
Server
Synchronize after processing by server
Synchronize at request delivery
Synchronize at request submission
Request
Reply
Storage facility
Transmission interrupt
Time
Transiente vs. persistente
Comunicação transiente: remetente descarta a mensagem se elanão puder ser encaminhada para o destinatário
Comunicação persistente: uma mensagem é guardada no remetentepelo tempo que for necessário, até ser entregue nodestinatário
7/29
tipos de comunicação
Client
Server
Synchronize after processing by server
Synchronize at request delivery
Synchronize at request submission
Request
Reply
Storage facility
Transmission interrupt
Time
Pontos de sincronização
• No envio da requisição• Na entrega da requisição• Após o processamento da requisição
7/29
cliente/servidor
Computação Cliente/Servidor geralmente é baseada em um modelode comunicação transiente síncrona:
• Cliente e servidor devem estar ativos no momento dacomunicação
• Cliente envia uma requisição e bloqueia até que receba suaresposta
• Servidor essencialmente espera por requisições e as processa
Desvantagens de comunicação síncrona:
• o cliente não pode fazer nenhum trabalho enquanto estiveresperando por uma resposta
• falhas precisam ser tratadas imediatamente (afinal, o clienteestá esperando)
• o modelo pode não ser o mais apropriado (mail, news)
8/29
cliente/servidor
Computação Cliente/Servidor geralmente é baseada em um modelode comunicação transiente síncrona:
• Cliente e servidor devem estar ativos no momento dacomunicação
• Cliente envia uma requisição e bloqueia até que receba suaresposta
• Servidor essencialmente espera por requisições e as processa
Desvantagens de comunicação síncrona:
• o cliente não pode fazer nenhum trabalho enquanto estiveresperando por uma resposta
• falhas precisam ser tratadas imediatamente (afinal, o clienteestá esperando)
• o modelo pode não ser o mais apropriado (mail, news)
8/29
trocas de mensagem
Middleware orientado a mensagenstem como objetivo prover comunicação persistente assíncrona:
• Processos trocam mensagens entre si, as quais sãoarmazenadas em uma fila
• O remetente não precisa esperar por uma resposta imediata,pode fazer outras coisas enquanto espera
• Middleware normalmente assegura tolerância a falhas
9/29
rpc — chamadas a procedimentosremotos
chamadas a procedimentos remotos (rpc)
• Funcionamento básico de RPCs• Passagem de parâmetros• Variações
10/29
funcionamento básico de rpc
• Desenvolvedores estão familiarizados com o modelo deprocedimentos
• Procedimentos bem projetados operam isoladamente (blackbox)
• Então não há razão para não executar esses procedimentos emmáquinas separadas
ConclusãoComunicação entre o chamador &chamado podem ser escondidacom o uso de mecanismos dechamada a procedimentos. Call local procedure
and return results
Call remoteprocedure
Returnfrom call
Client
Request Reply
ServerTime
Wait for result
11/29
funcionamento básico de rpc
Implementationof add
Client OS Server OS
Client machine Server machine
Client stub
Client process Server process1. Client call to
procedure
2. Stub buildsmessage
5. Stub unpacksmessage
6. Stub makeslocal call to "add"
3. Message is sentacross the network
4. Server OShands messageto server stub
Server stubk = add(i,j) k = add(i,j)
proc: "add"int: val(i)int: val(j)
proc: "add"int: val(i)int: val(j)
proc: "add"int: val(i)int: val(j)
1. Procedimento no cliente chama ostub do cliente
2. Stub constrói mensagem; chama o SOlocal
3. SO envia msg. para o SO remoto4. SO remoto repassa mensagem para o
stub5. Stub desempacota parâmetros e
chama o servidor
6. Servidor realiza chamada local edevolve resultado para o stub
7. Stub constrói mensagem; chama SO8. SO envia mensagem para o SO do
cliente9. SO do cliente repassa msg. para o
stub10. Stub do cliente desempacota
resultado e devolve para o cliente 12/29
rpc: passagem de parâmetros
Empacotamento de parâmetroshá mais do que apenas colocá-los nas mensagens:
• As máquinas cliente e servidor podem ter representação dedados diferentes (ex: ordem dos bytes)
• Empacotar um parâmetro significa transformar um valor emuma sequência de bytes
• Cliente e servidor precisam concordar com a mesma regra decodificação (encoding):
• Como os valores dos dados básicos (inteiros, números em pontoflutuante, caracteres) são representados?
• Como os valores de dados complexos (vetores, unions) sãorepresentados?
• Cliente e servidor precisam interpretar corretamente asmensagens, transformando seus valores usando representaçõesdependentes da máquina
13/29
rpc: passagem de parâmetros
Algumas suposições:
• semântica de copy in/copy out: enquanto um procedimento éexecutado, nada pode ser assumido sobre os valores dosparâmetros
• Todos os dados são passado apenas por parâmetro. Excluipassagem de referências para dados (globais).
ConclusãoNão é possível assumir transparência total de acesso.
14/29
rpc: passagem de parâmetros
Algumas suposições:
• semântica de copy in/copy out: enquanto um procedimento éexecutado, nada pode ser assumido sobre os valores dosparâmetros
• Todos os dados são passado apenas por parâmetro. Excluipassagem de referências para dados (globais).
ConclusãoNão é possível assumir transparência total de acesso.
14/29
rpc assíncrono
Ideia geralTentar se livrar do comportamento estrito de requisição–resposta,mas permitir que o cliente continue sem esperar por uma respostado servidor.
Call local procedure
Call remoteprocedure
Returnfrom call
Request Accept request
Wait for acceptance
Call local procedureand return results
Call remoteprocedure
Returnfrom call
Client Client
Request Reply
Server ServerTime Time
Wait for result
(a) (b)
15/29
rpc síncrono diferido
Call local procedure
Call remoteprocedure
Returnfrom call
Client
RequestAcceptrequest
ServerTime
Wait foracceptance
Interrupt client
Returnresults Acknowledge
Call client withone-way RPC
VariaçãoCliente pode também realizar uma consulta (poll) (bloqueante ounão) para verificar se os resultados estão prontos.
16/29
rpc na prática
C compiler
Uuidgen
IDL compiler
C compiler C compiler
Linker Linker
C compiler
Server stubobject file
Serverobject file
Runtimelibrary
Serverbinary
Clientbinary
Runtimelibrary
Client stubobject file
Clientobject file
Client stubClient code Header Server stub
Interfacedefinition file
Server code
#include#include
17/29
vinculação cliente–servidor (dce)
Problemas(1) Cliente precisa localizar a máquina com o servidor e,(2) precisa localizar o servidor.
Endpointtable
Server
DCEdaemon
Client1. Register endpoint
2. Register service3. Look up server
4. Ask for endpoint
5. Do RPC
Directoryserver
Server machineClient machine
Directory machine
18/29
comunicação orientada amensagens
comunicação orientada a mensagens
• Mensagens transientes• Sistema de enfileiramento de mensagens• Message brokers• Exemplo: IBM Websphere
19/29
mensagens transientes: sockets
Berkeley socket interface
SOCKET Cria um novo ponto de comunicaçãoBIND Especifica um endereço local ao socketLISTEN Anuncia a vontade de receber N conexõesACCEPT Bloqueia até receber um pedido de estabelecimento de conexãoCONNECT Tenta estabelecer uma conexãoSEND Envia dados por uma conexãoRECEIVE Recebe dados por uma conexãoCLOSE Libera a conexão
20/29
mensagens transientes: sockets
connect
socket
socket
bind listen read
read
write
write
accept close
close
Server
Client
Synchronization point Communication
21/29
sockets: código em python
import socketHOST = socket.gethostname() # e.g. 'localhost'PORT = SERVERPORT # e.g. 80s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)s.bind((HOST, PORT))s.listen(N) # listen to max N queued connectionconn, addr = s.accept() # new socket + addr clientwhile 1: # foreverdata = conn.recv(1024)if not data: breakconn.send(data)
conn.close()
22/29
middleware orientado a mensagens
Ideia geralComunicação assíncrona e persistente graças ao uso de filas pelomiddleware. Filas correspondem a buffers em servidores decomunicação.
PUT Adiciona uma mensagem à fila especificadaGET Bloqueia até que a fila especificada tenha alguma
mensagem e remove a primeira mensagemPOLL Verifica se a fila especificada tem alguma mensagem e
remove a primeira. Nunca bloqueiaNOTIFY Instala um tratador para ser chamado sempre que uma
mensagem for inserida em uma dada fila
23/29
message broker
Observação:Sistemas de filas de mensagens assumem um protocolo comum detroca de mensagens: todas as aplicações usam o mesmo formato demensagem (i.e., estrutura e representação de dados)
Message brokerComponente centralizado que lida com a heterogeneidade dasaplicações:
• transforma as mensagens recebidas para o formato apropriado• frequentemente funciona como um application gateway• podem rotear com base no conteúdo ⇒ Enterprise ApplicationIntegration
24/29
message broker
Queuinglayer
Brokerprogram
Repository with conversion rules and programsSource client Destination client
OS OSOS
Message broker
Network
25/29
ibm websphere message queue (mq)
• Mensagens específicas da aplicação são colocadas e removidasde filas
• As filas são controladas por um gerenciador de filas• Processos podem colocar mensagens apenas em filas locais, ouusando um mecanismo de RPC
26/29
ibm websphere mq
Transferência de mensagens
• Mensagens são transferidas entre filas• Mensagens transferidas entre filas em diferentes processosrequerem um canal
• Em cada ponta do canal existe um agente de canal, responsávelpor:
• configurar canais usando ferramentas de rede de baixo nível (ex:TCP/IP)
• (Des)empacotar mensagens de/para pacotes da camada detransporte
• Enviar/receber pacotes
27/29
ibm websphere mq
MCA MCAMCA MCA
MQ Interface
Stub StubServerstub
Serverstub
Send queue
Program ProgramQueuemanager
Queuemanager
Routing table
Enterprise networkRPC(synchronous)
Local network
Message passing(asynchronous)
To other remotequeue managers
Client's receivequeueSending client Receiving client
• Canais são unidirecionais• Agentes de canais são automaticamente iniciados quando umamensagem chega
• Pode-se criar redes de gerenciadores de filas• Rotas são configuradas manualmente (pelo admin do sistema) 28/29
ibm websphere mq
RoteamentoO uso de nomes lógicos, combinados com resolução de nomes parafilas locais, permitem que uma mensagem seja colocada em uma filaremota.
SQ1SQ2
SQ1
SQ1SQ1SQ2
QMBQMCQMD
SQ1
SQ1SQ1
SQ1
SQ2SQ1
SQ1
SQ1SQ1
QMA
QMA QMA
QMC
QMCQMB
QMD
QMBQMD
Routing tableRouting table
Routing table Routing table
QMB
QMC
QMA
LA1LA1
LA1
LA2LA2
LA2
QMCQMA
QMA
QMDQMD
QMC
Alias tableAlias table
Alias table
QMD
SQ1
SQ2
SQ1
29/29