insert_drive_file Comunicação

Propaganda

Sistemas Distribuı́dos
Comunicação II
Prof. Emerson Ribeiro de Mello
Instituto Federal de Santa Catarina – IFSC
campus São José
[email protected]
http://docente.ifsc.edu.br/mello
27 de março de 2017
1/30
Revisão das aulas anteriores
2/30
Alguns pontos na comunicação cliente/servidor
Protocolo de comunicação
Podem ser definidos como acordos/regras para comunicação
Podem ser orientados a conexão ou não (Ex: TCP x UDP)
Modelo de comunicação cliente/servidor
Servidores oferecem serviços aos clientes
Paradigma pedido e resposta
Implementação: Socket, RPC e RMI
2/30
Alguns pontos na comunicação cliente/servidor
Endereçamento
Como localizar o servidor?
Conhecimento prévio, broadcast ou serviço de nomes
Bloqueante x não bloqueante
Sı́ncrono – emissor/receptor fica bloqueado até enviar/receber mensagem
Assı́ncrono – emissor não fica bloqueado e o retorno também não bloqueia
Área de armazenamento temporário (buffer) - com x sem
Servidor precisa ficar esperando uma mensagem antes que o cliente possa
enviá-la (consumo imediato)
Cliente envia para uma área de armazenamento temporário e o servidor
depois consulta esta área
3/30
Alguns pontos na comunicação cliente/servidor
Confiável x não confiável
Canal não confiável: exige confirmação de todas mensagens (pedido e
resposta) – aplicação fica responsável
Canal confiável: a resposta pode atuar como uma confirmação do pedido
Comunicação confiável pode delegar para os mecanismos de transporte
lidarem com mensagens perdidas
Servidor concorrente x sequencial
Sequencial: servidor atende um pedido por vez
Concorrente: servidor dispara uma thread ou processo filho para lidar com
cada pedido que chega
4/30
Receber (pull) ou enviar (push)
Cliente: modelo pull (receber)
Cliente responsável por obter dados do servidor (envia pedido)
Ex: HTTP
Vantagem: servidor não precisa manter estado
Dificuldade: escalabilidade limitada
Servidor: modelo push (enviar)
Servidor envia dados para o cliente
Ex: Streaming de vı́deo
Vantagem: mais escalável
Dificuldade: servidor precisa manter estado
5/30
Comunicação em grupo: um para muitos
Algumas caracterı́sticas
Caracterı́sticas de um grupo
estáticos ou dinâmicos
abertos ou fechados
Endereçamento de um grupo
Multicast, broadcast
Multicast na camada da aplicação (unicast)
Atomicidade, ordenação de mensagens e escalabilidade
6/30
Objetos distribuı́dos e invocação de métodos
remotos
7/30
Objetos distribuı́dos e invocação de métodos remotos
Chamada Remota de Procedimento – RPC
Permite que processos locais realizem chamadas de procedimentos que
estão localizados em outras máquinas
7/30
Objetos distribuı́dos e invocação de métodos remotos
Chamada Remota de Procedimento – RPC
Permite que processos locais realizem chamadas de procedimentos que
estão localizados em outras máquinas
Invocação de Métodos Remotos – RMI
Semelhante ao RPC, porém voltado para objetos distribuı́dos
Usufrui do paradigma da programação orientada a objetos
Estende o conceito de referência de objetos para um ambiente global
distribuı́do
Objeto residente em um processo pode invocar métodos de um objeto
residente em um outro processo
7/30
RPC vs RMI
Semelhanças entre RPC e RMI
Diferenças entre RCP e RMI
8/30
RPC vs RMI
Semelhanças entre RPC e RMI
Fazem uso de linguagem de descrição de interfaces (IDL)
São construı́dos sobre protocolos pedido e resposta
Oferecem o mesmo nı́vel de transparência ao desenvolvedor
Diferenças entre RCP e RMI
8/30
RPC vs RMI
Semelhanças entre RPC e RMI
Fazem uso de linguagem de descrição de interfaces (IDL)
São construı́dos sobre protocolos pedido e resposta
Oferecem o mesmo nı́vel de transparência ao desenvolvedor
Diferenças entre RCP e RMI
Com o RMI o desenvolvedor poderá usufruir das facilidades da POO
objetos, classes, herança, . . .
Objetos possuem uma referência única em todo o sistema
Oferece maior riqueza na semântica quando passados como parâmetros
Objetos podem ser passados nos parâmetros por referência (e não somente
por valor)
8/30
RMI
Modelo orientado a objeto
Atributos de objetos são acessados através de seus métodos
Interfaces
Provê a definição de um conjunto de métodos, sem no entanto prover
implementação para os mesmos
Arquiteturas de sistemas de objetos distribuı́dos
Cliente e servidor
um objeto ao invocar um método de um objeto distribuı́do resulta em
enviar uma mensagem pela rede e aguardar por uma resposta
Replicação
Um mesmo objeto pode ser replicado em todas as máquinas do SD,
trazendo benefı́cios de desempenho e propiciando uma tolerância a faltas
9/30
Modelo de objetos distribuı́dos
Cada processo possui uma coleção de objetos, os quais estão aptos a
receber invocações locais ou remotas
Referência de objeto remoto
um objeto só poderá invocar métodos de outros objetos que este possuir a
referência
Interface remota
cada objeto remoto possui uma interface que especifica quais de seus
métodos poderão ser invocados remotamente
208
CHAPTER 5 REMOTE INVOCATION
objetos
dentro de um mesmo processo poderão invocar os métodos
remotos
e também os locais
Figure 5.13 A remote object and its remote interface
remoteobject
remote
interface
Data
{
m1
m2
m3
implementation
of methods
m4
m5
m6
Remote interfaces: The class of a remote object implements the methods of its remote
interface, for example as public instance methods in Java. Objects in other processes can
10/30
Modelo de objetos distribuı́dos
Coletor automático de lixo
Se a linguagem permitir (p.e. Java), a coleta de lixo distribuı́da é possı́vel
através da interação entre os coletores locais
Se a linguagem não permitir (p.e. C++), então cabe ao desenvolver se
preocupar em liberar a memória de objetos remotos que não são mais
usados
Exceções
Qualquer invocação remota poderá falhar e assim deverá disparar exceções
servidor onde está objeto distribuı́do fica indisponı́vel
servidor está muito ocupado para responder
resposta pode ser perdida
11/30
Implementação RMI
Módulo de comunicação (no cliente e servidor)
Responsável pela comunicação entre cliente e servidor
Módulo de referência de objetos remotos (no cliente e servidor)
Responsável por traduzir as referências entre objetos remotos e locais
Proxy (no cliente)
Faz com que as invocações remotas sejam transparentes para o cliente
Ao receber uma inovação local, este encaminha uma mensagem para o
objeto remoto
Servants (no servidor)
Instância da classe que provê o objeto remoto
Responsável por receber as invocações remotas
12/30
Implementação RMI
Skeleton (no servidor)
Associado a uma classe de um objeto remoto – é onde estão as
implementações dos métodos da interface remota
Atividades de empacotamento e desempacotamento acontecem aqui
Dispatcher (no servidor)
Um servidor possui um skeleton e um dispatcher para cada classe de
10
CHAPTER
REMOTE INVOCATION
objeto5 remoto
que prover.
igure 5.15
The
role of proxy
and skeleton
in remote method invocation
invocar
o método
no skeleton
Responsável por: receber um pedido do módulo de comunicação; e
server
client
object A proxy for B
Request
skeleton
& dispatcher
for B’s class
remote
object B
Reply
Communication
Remote
reference module
module
Communication
module
Remote reference
module
servant
13/30
all the marshalling and unmarshalling are the concern of the RMI software, discussed
Implementações de modelos de objetos distribuı́dos
CORBA
Linguagem de Descrição de Interface: CORBA IDL
Compilador IDL para diferentes linguagens de programação: Python,
C++, Java
Implementações: JacORB, R2CORBA, TAO, VBOrb, omniORB
Java RMI
Linguagem de Descrição de Interface: Interfaces Java
Objetos remotos e programas clientes devem ser escritos em Java
14/30
Java RMI
Serviço de registro pode ser iniciado na linha de comando:
rmiregistry &
ou dentro do código Java:
1
Registry registro = LocateRegistry.createRegistry(PORTA);
15/30
Exemplo RMI: Contador distribuı́do
Interface Java que deve ser compartilhada pelo cliente e servidor
2
3
4
5
6
package std;
public interface ContadorDistribuido extends Remote{
public void incrementa() throws RemoteException;
public int obtemValor() throws RemoteException;
}
Implementação da Interface pelo Servidor
7
8
9
package std;
public class Contador implements ContadorDistribuido{
public int valor = 0;
10
public void incrementa() throws RemoteException {
this.valor++;
}
public int obtemValor() throws RemoteException {
return this.valor;
}
11
12
13
14
15
16
17
}
16/30
Exemplo RMI: Contador distribuı́do – Servidor
18
19
20
21
22
package std;
public class Servidor{
public static void main(String[] args){
try {
Contador c = new Contador();
23
System.setProperty("java.rmi.server.hostname","IP-do-servidor");
ContadorDistribuido stub = (ContadorDistribuido)
UnicastRemoteObject.exportObject(c, 0);
24
25
26
Registry registro = LocateRegistry.createRegistry(1234);
registro.bind("MeuContador", stub);
27
28
29
System.out.println("Servidor pronto!");
30
31
} catch (Exception e) {
System.err.println("erro: " + e.toString());
}
32
33
34
35
36
}
}
17/30
Exemplo RMI: Contador distribuı́do – Cliente
37
38
39
40
41
42
package std;
public class Cliente{
public static void main(String[] args){
try {
Registry registro = LocateRegistry.getRegistry("IP-servidor",
1234);
ContadorDistribuido stub = (ContadorDistribuido) registro.
lookup("MeuContador");
43
System.out.println("valor: " + stub.obtemValor());
stub.incrementa();
System.out.println("valor: " + stub.obtemValor());
44
45
46
47
} catch (Exception e) {
System.err.println("erro: " + e.toString());
}
48
49
50
}
51
52
}
18/30
Comunicação por mensagens
19/30
Comunicação transitória por mensagens
Embora RPC e RMI contribuam para esconder a comunicação no
sistema distribuı́dos (transparência), estes assumem que ambas as
partes estarão ativas no mesmo instante para permitir a
comunicação
19/30
Comunicação transitória por mensagens
Embora RPC e RMI contribuam para esconder a comunicação no
sistema distribuı́dos (transparência), estes assumem que ambas as
partes estarão ativas no mesmo instante para permitir a
comunicação
Server
socket
bind
listen
accept
Synchronization point
socket
read
write
close
Communication
connect
write
read
close
Client
19/30
Comunicação persistente por mensagens
Middleware orientado a mensagem (MOM) – sistema de fila de
mensagens
Provê suporte a comunicação assı́ncrona e persistente
Cliente e servidor não precisam estar ativos no mesmo instante para
permitir a troca de mensagens
Comunicação entre aplicações é feita por meio de filas de
mensagens
Mensagens podem ser roteadas por diversos servidores intermediários
e eventualmente ser entregue ao destino
20/30
Comunicação persistente por mensagens
Middleware orientado a mensagem (MOM) – sistema de fila de
mensagens
Provê suporte a comunicação assı́ncrona e persistente
Cliente e servidor não precisam estar ativos no mesmo instante para
permitir a troca de mensagens
Comunicação entre aplicações é feita por meio de filas de
mensagens
Mensagens podem ser roteadas por diversos servidores intermediários
e eventualmente ser entregue ao destino
20/30
Modelo de fila de mensagens
Comunicação persistente e assı́ncrona – desacoplamento temporal
Mensagens ficam armazenadas até que o receptor possa consumi-las
Emissor só tem garantia que a mensagem será eventualmente inserida na
fila do receptor
Quando a mensagem será consumida ou se será consumida, isto depende
do comportamento do receptor
Sender
running
Sender
running
Sender
passive
Sender
passive
Receiver
running
Receiver
passive
Receiver
running
Receiver
passive
(a)
(b)
(c)
(d)
21/30
Interface básica para sistemas de filas de mensagens
PUT
Colocar uma mensagem em uma fila
GET
Se a fila estiver vazia ficará bloqueada até chegar mensagem. Remove a
primeira mensagem que estiver na fila
POLL
Verificar se existe mensagem em uma fila especı́fica e remover a primeira.
Neste caso, não fica bloqueado
NOTIFY
Definir uma função que será invocada sempre que uma mensagem for
inserida na fila
22/30
Arquitetura básica de um sistema de filas de mensagens
Cada fila possui um identificador único em todo o sistema distribuı́do
e as mensagens são destinadas para uma fila
Filas são distribuı́das por diversas máquinas
Identificar cada fila implica em fazer um mapeamento para endereços de
rede e portas
Cada máquina oferece uma interface para o envio e recepção de
mensagens
Máquinas clientes podem estar ligadas a uma ou mais máquinas
servidoras responsáveis pelo encaminhamentos de mensagens
(roteamento)
23/30
Organização de um sistema de filas de mensagens com
roteadores
Sender A
Application
Application
Receive
queue
R2
Message
Send queue
Application
R1
Receiver B
Application
Router
24/30
Java Message Service – JMS
API que permite a criação, envio, recebimento e leitura de mensagens de
forma confiável, assı́ncrona e com baixo acoplamento temporal
Uma aplicação JMS é composta por
Clientes – enviam e recebem mensagens
Mensagens – informações a serem trocadas
Objetos administrados – objetos para serem usados pelos clientes
Provedor – é o sistema de mensagens com funções de administração e
controle da aplicação
Modos de operação
ponto a ponto
publish/subscribe
25/30
Modo Ponto a Ponto
Mensagens são mantidas nas filas até que alguém as consuma ou até
que expirem
Cada mensagem possui um único consumidor
26/30
Modo publish/subscribe
Produtores e consumidores podem publicar e assinar tópicos
Quando uma mensagem é publicada em um determinado tópico, o JMS
distribui esta mensagem para todos os assinantes
A mensagens ficam retidas nos tópicos até serem entregues a todos os
assinantes
27/30
Outras implementações de comunicações por mensagens
Advanced Message Queuing Protocol – AMQP
Padrão aberto para middleware orientado à mensagens – enfileiramento,
roteamento ponto-a-ponto ou pub-sub, confiabilidade e segurança
Apache ActiveMQ
Apache Qpid
RabbitMQ
ZeroMQ
Message Queue Telemetry Transport – MQTT
Padrão ISO baseado em uma versão leve do publish-subscribe para ser usado
sobre TCP/IP – ambientes que exigem código pequeno & taxa de
transmissão baixa
Mosquitto
28/30
Exercı́cio: Sistema de e-mails
DNS
1
0
0
1
0
1
0
1
REMETENTE
Servidor
Local
Servidor
Remoto
caixa postal
dos usuários
1
0
0
1
0
1
0
1
DESTINATÁRIO
29/30
Exercı́cio: Sistema de e-mails
DNS
TP
M
1. S
1
0
0
1
0
1
0
1
REMETENTE
Servidor
Local
Servidor
Remoto
caixa postal
dos usuários
1
0
0
1
0
1
0
1
DESTINATÁRIO
29/30
Exercı́cio: Sistema de e-mails
a
ult
ns
co ome
2. n
DNS
TP
M
1. S
1
0
0
1
0
1
0
1
REMETENTE
Servidor
Local
Servidor
Remoto
caixa postal
dos usuários
1
0
0
1
0
1
0
1
DESTINATÁRIO
29/30
Exercı́cio: Sistema de e-mails
a
ult
ns
co ome
2. n
3.
DNS
SMTP
P
MT
1. S
1
0
0
1
0
1
0
1
REMETENTE
Servidor
Local
Servidor
Remoto
caixa postal
dos usuários
1
0
0
1
0
1
0
1
DESTINATÁRIO
29/30
Exercı́cio: Sistema de e-mails
a
ult
ns
co ome
2. n
3.
P
MT
1. S
1
0
0
1
0
1
0
1
REMETENTE
DNS
SMTP
4.
armazena
Servidor
Local
Servidor
Remoto
caixa postal
dos usuários
1
0
0
1
0
1
0
1
DESTINATÁRIO
29/30
Exercı́cio: Sistema de e-mails
a
ult
ns
co ome
2. n
3.
DNS
SMTP
5.
PO
P
MT
P
1. S
1
0
0
1
0
1
0
1
REMETENTE
Servidor
Local
Servidor
Remoto
caixa postal
dos usuários
1
0
0
1
0
1
0
1
DESTINATÁRIO
29/30
Exercı́cio: Sistema de e-mails
a
ult
ns
co ome
2. n
3.
DNS
SMTP
5.
PO
P
MT
P
1. S
1
0
0
1
0
1
0
1
REMETENTE
6.
Servidor
Local
obtém
Servidor
Remoto
caixa postal
dos usuários
1
0
0
1
0
1
0
1
DESTINATÁRIO
29/30
Exercı́cio: Sistema de e-mails
Endereçamento: Como localizar os servidores de e-mail?
Bloqueante ou não bloqueante?
Com área de armazenamento temporário?
Confiável ou não confiável?
Servidor concorrente ou sequencial?
Modelo pull ou push?
Modelo de comunicação em grupo?
30/30