mcta025-13 - sistemas distribuídos -...

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

https://www.distributed-systems.net

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


Client

Server




Request

Reply

Storage facility


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


Client

Server




Request

Reply

Storage facility


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

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)



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


Returnfrom call

Request Accept request

Wait for acceptance

Call local procedureand return results


Returnfrom call

Client Client

Request Reply

Server ServerTime Time

Wait for result

(a) (b)

15/29

rpc síncrono diferido

Call local procedure


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

mcta025-13 - sistemas distribuídos -...

Documents