![Page 1: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/1.jpg)
1
Departamento de Engenharia Informática
Sistemas Distribuídos
Revisão de redes
Modelos e arquitecturas
13/14 Sistemas Distribuídos 1
Departamento de Engenharia Informática
A rede que interliga o
sistema distribuído
Revisão
13/14 Sistemas Distribuídos 2
![Page 2: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/2.jpg)
2
Departamento de Engenharia Informática
Programação da comunicação: modelo
Processo Canal de comunicação
portoProcesso
API da
comunicação
modo utilizador modo sistema
rede
porto
transport
e
rede
lógic
o
físic
o
13/14 Sistemas Distribuídos 3
Departamento de Engenharia Informática
Redes de Dados
• Fornecer uma base mínima de compreensão das redes de dados
– Arquitectura
– Organização
– Protocolos
• Identificar os aspectos relevantes das redes de dados na concepção de sistemas distribuídos
Revisão
13/14 Sistemas Distribuídos 4
![Page 3: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/3.jpg)
3
Departamento de Engenharia Informática
Arquitectura Lógica
• Porquê uma arquitectura Lógica nas redes?
• A arquitectura lógica define as propriedades da rede, adequadas ao seu campo de aplicações
– Tipo de endereçamento
– Desempenho
– Garantia de entrega de mensagens
– Ordenação das mensagens
– Tolerância a faltas
– Endereçamento em difusão
– …
• A mesma arquitectura lógica pode ser realizada (com maior ou menor facilidade) sobre várias arquitecturas físicas
13/14 Sistemas Distribuídos 5
Departamento de Engenharia Informática
Características habituais das Arquitecturas Físicas
•Redes de Larga Escala–Transmissão ponto a ponto
–Banda passante com limitações mas tecnologias tradicionais
–Topologia malhada com redundância
–Necessidade de encaminhamento
–Grande escalabilidade
–Menor tolerância a faltas
•Redes Locais–Transmissão em difusão–Largura de Banda muito grande–Topologias de bus ou anel–Encaminhamento trivial–Menor escalabilidade–Maior tolerância a faltas
13/14 Sistemas Distribuídos 6
![Page 4: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/4.jpg)
4
Departamento de Engenharia Informática
Modelo de Referência
• Um Modelo de Referência, ou Família de Protocolos, define as características lógicas e físicas das redes• Normalmente divididos em níveis
• Os níveis são independentes mas estão relacionados
• Permitem várias realizações compatíveis
• cada nível corresponde a um nível de abstração necessário no modelo
• cada nível possui funções próprias e bem definidas• as funções de cada nível foram escolhidas segundo a definição dos protocolos
normalizados internacionalmente
• as fronteiras entre níveis devem ser definidas de modo a minimizar o fluxo de informação nas interfaces
• o número de níveis deve ser suficientemente grande para que funções distintas não precisem ser colocadas na mesma nível • e, ao mesmo tempo, suficientemente pequeno que não torne a arquitectura
difícil de controlar.
13/14 Sistemas Distribuídos 7
Departamento de Engenharia Informática
• Funções: conseguir transmitir 1 bit de informação sobre meio físico de interligação
– Velocidade de propagação, atenuação, imunidade ao ruído, etc.
• Nível Físico define:– Níveis eléctricos do sinal, características
temporais
– Protocolos de codificação, baseados no funcionamento da rede (taxa de erros, recuperação de relógio, …)
– Placas de interface (network cards)• Interface eléctrica
• Aspectos mecânicos dos conectoresBus
Anel (ring)
Malha (mesh)
OSI - Nível Físico
13/14 Sistemas Distribuídos 8
![Page 5: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/5.jpg)
5
Departamento de Engenharia Informática
• Funções: transmissão de pacotes, ou tramas, entre máquinas ligadas à mesma rede física
• Nível Lógico define:– Delimitadores de trama
– Endereço físico do destinatário
– Multiplexagem do meio de transmissão (emissor)
– Detecção do endereço do destinatário (receptor)
– Definição da unidade básica de informação (bit, octeto)
– Recuperação de erros de transmissão
– Controlo de fluxo
Ethernet
ATMFrame
Relay
GPRS
UMTS
OSI - Nível Lógico ou
Ligação de Dados
13/14 Sistemas Distribuídos 9
Departamento de Engenharia Informática
OSI - Nível Rede
• Funções: interligar máquinas independentemente da rede física a que estão ligadas
• Uma rede lógica passa a ser composta pela interligação de várias redes físicas
• Nível Rede define:– Formato dos pacotes de dados
– Mecanismos de encaminhamento entre redes• Fundamental para redes malhadas
• Normalmente baseados em tabelas de encaminhamento
– Protocolo de rede OSI: X.25• Com ligação, sequencialidade, controlo de fluxo
– Protocolo de rede Internet: IP• Sem ligação nem garantias de qualidade
Rede IP
13/14 Sistemas Distribuídos 10
![Page 6: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/6.jpg)
6
Departamento de Engenharia Informática
• Funções: oferecer um serviço de transmissão de informação que permita a comunicação entre utilizadores finais
• Características– Com ou sem ligação
– Comunicação fiável• Garantia de entrega
• Garantia de ordem
– Segmentação
– Controlo de fluxo
– Notificação de excepções na comunicação
Nível TransporteRede TCP
Processo Utilizador
Processo Utilizador
13/14 Sistemas Distribuídos 11
Departamento de Engenharia Informática
A Internet como um Relógio de Areia
IP
TCP / UDP
Ethernet GPRS 802.11 BluetoothSatélite
Web Audio VoIP Web ServicesMail Video IM
Difícil de alterarPassível de alterações
Maior inovação
13/14 Sistemas Distribuídos 12
![Page 7: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/7.jpg)
7
Departamento de Engenharia Informática
Interfaces de Comunicação
• Interacção baseada na troca de mensagens • Facilidade de transporte para múltiplos sistemas
• Exploração das APIs normais de comunicação• Tipicamente da API de transporte (sockets)
• Cada aplicação possui um protocolo próprio
• Dificulta a utilização do protocolo por terceiros
• Desempenho porque é executado em modo utilizador
• telnet, rlogin, Winrdp-aplicações de terminal remoto
• ftp, samba – Transferência de ficheiros
• SMTP – Correio electrónico
Exemplos Problemas?
13/14 Sistemas Distribuídos 13
Departamento de Engenharia Informática
Interfaces de Comunicação
Máquina A
OS kernel
Níveis7 a 5
Sockets, TLI
Níveis3 a 1Níveis3 a 1
Máquina B
OS kernel
Níveis7 a 5
aplicação
Sockets, TLI
Níveis3 a 1
Níveis3 a 1
aplicação
Nível 4TransporteNível 4Transporte
Nível 4TransporteNível 4Transporte
13/14 Sistemas Distribuídos 14
![Page 8: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/8.jpg)
8
Departamento de Engenharia Informática
Caracterização do canal de Comunicação
• Com ligação
– Normalmente serve 2 interlocutores
– Normalmente fiável, bidireccional e garante sequencialidade
• Sem ligação
– Normalmente serve mais de 2 interlocutores
– Normalmente não fiável: perdas, duplicação, reordenação
• Canal com capacidade de armazenamento em fila de Mensagens
– Normalmente com entrega fiável das mensagens
Tipos de canais
13/14 Sistemas Distribuídos 15
Departamento de Engenharia Informática
Portos – Extermidades do Canal de
Comunicação
• Portos– São extremidades de canais de comunicação
• Em cada máquina são representados por objectos do modelo computacional local
– Possuem 2 tipos de identificadores:• O do objecto do modelo computacional
– Para ser usado na API pelos processos locais
– Ex.: File descriptors, handles
• O do protocolo de transporte– Para identificar a extremidade entre processos (ou
máquinas) diferentes
– Ex.: Endereços TCP/IP, URL
13/14 Sistemas Distribuídos 16
![Page 9: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/9.jpg)
9
Departamento de Engenharia Informática
Interface sockets
• Domínio do socket: define a família de protocolos associada a um socket– INET: família de protocolos Internet
– Unix: comunicação entre processos da mesma máquina
– Outros…
• Tipo do socket: define as características do canal de comunicação– Stream: canal com ligação, bidireccional, fiável, interface tipo
sequência de octetos
– Datagram: canal sem ligação, bidireccional, não fiável, interface tipo mensagem
– Raw: permite o acesso directo aos níveis inferiores dos protocolos (ex: IP na família Internet)
13/14 Sistemas Distribuídos 18
Departamento de Engenharia Informática
Sockets sem Ligação
socket
bind
recvfrom
sendto
socket
bind
sendto
recvfrom
ClienteServidor
13/14 Sistemas Distribuídos 21
![Page 10: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/10.jpg)
10
Departamento de Engenharia Informática
Sockets UDP em Java (Cliente)• import java.net*;
• import java.io*;
• public class UDPClient{
• public static void main(String args[]){
• // args give message contents and server hostname
• DatagramSocket aSocket = null;
• try {
• aSocket = new DatagramSocket();
• byte [] m = args [0].getBytes();
• InetAddress aHost = InetAddress.getByName(args[1]);
• Int serverPort = 6789;
• DatagramPacket request =
• new DatagramPacket(m, args[0].length(), aHost, serverPort);
• aSocket.send(request);
• byte[]buffer = new byte[1000];
• DatagramPacket reply = new DatagramPacket(buffer, buffer.length);
• aSocket.receive(reply);
• System.out.println(“Reply:” + new String(reply.getData()));
• } catch (SocketException e){System.out.println(“Socket:” + e.getMessage());
• } catch (IOException e){System.out.println(“IO:” + e.getMessage());
• } finally { if(aSocket ! = null) aSocket.close();}
• }
• }
Conversão do nome DNS para endereço IP
Constrói um socket datagram (associado a qualquer porto
disponível)
Cada mensagem enviada tem que
levar junto identificador do
processo destino: IP e porto
13/14 Sistemas Distribuídos 22
Departamento de Engenharia Informática
Sockets UDP em Java (Servidor)• import java.net*;
• import java.io*;
• public class UDPServer{
• public static void main(String args[]){
• DatagramSocket aSocket = null;
• try{
• aSocket = new DatagramSocket(6789);
• byte[] buffer = new byte [1000];
• while(true){
• DatagramPacket request = new DatagramPacket(buffer, buffer.legth);
• aSocket.receive(request);
• DatagramPacket reply = new DatagramPacket(request.getData(),
• request.getLength(); request.getAddress(), request.getPort());
• aSocket.send(reply);
• }
• } catch (SocketException e){System.outprintln(“Socket:”+ e.getMessage());
• } catch (IOException e){System.out.println(“IO:” + e.getMessage());
• } finally {if(aSocket ! = null) aSocket.close();}
• }
• }
Constrói um socket datagram (associado ao porto 6789)
Recebe mensagem
Extrai da mensagem o IP e porto do
processo origem para responder
13/14 Sistemas Distribuídos 23
![Page 11: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/11.jpg)
11
Departamento de Engenharia Informática
Sockets com Ligação
socket
bind
listen socket
connectaccept
read
write read
write
ClienteServidor
ClienteServidor
Socket
Cliente
Socket
Escuta
Socket
Ligação
bytes
bytes
13/14 Sistemas Distribuídos 24
Departamento de Engenharia Informática
• import java.net*;
• import java.io*;
• public class TCPClient{
• public static void main(String args[]){
• // args: message and destin. hostname
• Socket s = null;
• try{
• int server Port = 7896;
• s = new Socket (args[1], serverPort);
• DataInputStream = new DataInputStream(s.getInputStream());
• DataOutputStream out =
• newDataOutputStream (s.getOutputStream());
• out.writeUTF(args[0]);
• String data = in.readUTF();
• System.out.prtintln(“Received: ” + data);
• }catch (UnknownHostException e){
• System.out.println(“Sock:” + e.getMessage());
• }catch (EOFException e){System.out.println(“EOF:”e.getMessage());
• }catch (IOException e){System.out.println(“IO:”e.getMessage());
• }finally {if(s!=null) try{s.close();}catch (IOException e}
• }
• classe Socket – suporta o socket cliente. Argumentos: nome DNS do servidor e o porto.• Construtor não só cria o socket como efectua a ligação TCP
Métodos getInputStream / getOutputStream – permitem aceder aos dois streams definidos pelo socket
WriteUTF / readUTF –para Universal transfer format / para as cadeias de caracteres
Sockets Stream em Java (Cliente)
13/14 Sistemas Distribuídos 25
![Page 12: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/12.jpg)
12
Departamento de Engenharia Informática
• import java.net*;
• import java.io*;
• public class TCPServer{
• public static void main(String args[]){
• try{
• int server Port = 7896;
• ServerSocket listenSocket = new ServerSocket(serverPort);
• while(true){
• Socket connectionSocket = listenSocket.accept();
• myConnection c = new myConnection(connectionSocket);
• }
• }catch (IOException e){System.out.println(“Listen:”
• +e.getMessage());}
• }
• }
Bloqueia até cliente estabelecer ligação.
Cria socket servidor que fica à escuta no porto “serverPort”
Sockets Stream em Java (Servidor)
Cria novo socket servidor com quem é estabelecida ligação com o cliente e
onde os dados são recebidos
13/14 Sistemas Distribuídos 26
Departamento de Engenharia Informática
Aula prática – 1ª semana
• SocketClient.java
• SocketServer.java
13/14 Sistemas Distribuídos 27
![Page 13: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/13.jpg)
13
Departamento de Engenharia Informática
Integração da Comunicação no Sistema
Operativo
13/14 Sistemas Distribuídos 33
Departamento de Engenharia Informática
Integração da Comunicação no Sistema
Operativo
• As aplicações invocam uma API que lhes permite aceder ao mecanismos de transporte
• A API deve ser conceptualmente independente de uma determinada pilha de protocolos de transporte
• Alternativas de implementação– Funções de ES genéricas
• Ex: sockets – parcialmente
– Funções de comunicação específicas• Ex: Algumas funções dos sockets
• Ex: TLI
– Mecanismo básico de comunicação entre processos do sistema operativo
• Ex: IPC dos micro-núcleos
13/14 Sistemas Distribuídos 34
![Page 14: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/14.jpg)
14
Departamento de Engenharia Informática
Winsock Implementation
Application Mswsock.dll
SPI
Service Providers
NtReadFile, NtWriteFile,NtCreateFile,NTDeviceloControlFile
Kernel mode
User mode
\Device\AFD
AFD FSD
TCP/IPIPX/SPX
TDI IRPs
NetBEUI
TDI
Protocol drivers
Wshtcpip.dll
Ntdll.dll
Msafd.dll
13/14 Sistemas Distribuídos 36
Departamento de Engenharia Informática
Modelos arquitecturais
13/14 Sistemas Distribuídos 38
![Page 15: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/15.jpg)
15
Departamento de Engenharia Informática
Aplicações
Middleware
Sistema Operativo
Bibliotecas (DLL)ProtocolosServidores
Hardware
Plataformas
Os Sistemas Distribuídos são suportados por diversas componentes frequentemente designadas por plataformas de Middleware
Pla
tafo
rm
a
s d
e
Mid
dle
ware
Camadas de Software: o Middleware
13/14 Sistemas Distribuídos 39
Departamento de Engenharia Informática
Quem são as entidades que comunicam
através da rede num sistema distribuído?
• Processos ou tarefas
• Nós
– Em alguns sistemas primitivos não existe a abstracção de
processo ou tarefa
– Exemplo: redes de sensores
• Objectos
– Exemplo: objecto Java invoca método de outro objecto remoto
– Veremos mais adiante na cadeira
• Web Services
– Veremos mais adiante na cadeira
• Componentes
– (Fora do âmbito da cadeira)
13/14 Sistemas Distribuídos 40
Por omissão, assumiremos
sistema distribuído de processos
![Page 16: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/16.jpg)
16
Departamento de Engenharia Informática
Como comunicam estas entidades?
13/14 Sistemas Distribuídos 41
Departamento de Engenharia Informática
Est
ud
arem
os
amb
os
em b
rev
e
Comunicação directa
• Interface de comunicação entre-processos
• Invocação remota
– Protocolos de pedido-resposta
• Exemplo: HTTP
– Chamada remota de procedimentos
• Programador define conjunto de procedimentos que servidor
oferece
• Cliente pode invocar esses procedimentos como se tratassem de
chamadas locais
– Invocação remota de métodos
• Semelhante a chamada remota de procedimentos, mas no
mundo OO
13/14 Sistemas Distribuídos 42
![Page 17: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/17.jpg)
17
Departamento de Engenharia Informática
Papéis e responsabilidades
13/14 Sistemas Distribuídos 51
Departamento de Engenharia Informática
Modelo Cliente-Servidor
• Servidores mantêm recursos e servem pedidos de operações sobre esses recursos
• Servidores podem ser clientes de outros servidores
• Simples e permite distribuir sistemas centralizados muito directamente
• Mas pouco escalável: limitado pela capacidade do servidor e pela rede que o liga aos clientes
Server
Client
Client
invocation
result
Serverinvocation
result
Process:Key:
Computer:
13/14 Sistemas Distribuídos 52
![Page 18: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/18.jpg)
18
Departamento de Engenharia Informática
Modelo Entre-Pares (Peer-to-Peer)
• Todos os processos têm papéis semelhantes, sem distinção entre clientes e servidores
• Mais ampla distribuição de carga (computação e rede)
– Maior escalabilidade
– Sistema expande-se acrescentando mais pares
• Coordenação mais complicada que cliente-servidor
Application
Application
Application
Peer 1
Peer 2
Peer 3
Peers 5 .... N
Sharableobjects
Application
Peer 4
13/14 Sistemas Distribuídos 53
Departamento de Engenharia Informática
Entre-Pares (Peer-to-Peer)
13/14 Sistemas Distribuídos 54
![Page 19: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/19.jpg)
19
Departamento de Engenharia Informática
Como mapear objectos e serviços no
modelo físico?
13/14 Sistemas Distribuídos 55
Departamento de Engenharia Informática
Serviço Oferecido por Múltiplos Servidores
• Distribui carga do servidor por múltiplos servidores
• Duas opções:
– Particionamento: cada servidor mantém uma partição do conjunto de objectos
– Replicação: todos os servidores mantêm réplicas do mesmo conjunto de objectos
Server
Server
Server
Service
Client
Client
13/14 Sistemas Distribuídos 56
![Page 20: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/20.jpg)
20
Departamento de Engenharia Informática
Serviço Oferecido por Múltiplos Servidores
13/14 Sistemas Distribuídos 57
Departamento de Engenharia Informática
Servidores Proxy e Caches
• Mantêm cópias de sub-conjunto dos objectos num computador mais próximo dos clientes
• Melhor desempenho e disponibilidade
• Outros objectivos: por exemplo, acesso ao exterior através de firewall
Client
Proxy
Web
server
Web
server
serverClient
13/14 Sistemas Distribuídos 58
![Page 21: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/21.jpg)
21
Departamento de Engenharia Informática
Servidores Proxy e Caches
13/14 Sistemas Distribuídos 59
Departamento de Engenharia Informática
Código Móvel (Applets)
• Parte do código do servidor é transferido para o cliente e executado localmente
• Execução não sofre com atrasos de rede e variações de largura de banda
• Bom desempenho de aplicações interactivas
a) client request results in the downloading of applet code
Web
server
ClientWeb
serverApplet
Applet code
Client
b) client interacts with the applet
13/14 Sistemas Distribuídos 60
![Page 22: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/22.jpg)
22
Departamento de Engenharia Informática
Código Móvel (Applets)
13/14 Sistemas Distribuídos 61
Departamento de Engenharia Informática
Agentes móveis
• Programa em execução (código+dados) que viaja de um
computador para outro na rede
• Executa alguma tarefa em nome de alguém
• Em cada computador, invoca serviços locais (e.g. acesso
a BD local para consultar informação local)
• Comparado com a solução de ter um cliente remoto a
invocar os mesmos serviços remotamente:
– Menor custo e tempo de comunicação
13/14 Sistemas Distribuídos 62
![Page 23: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/23.jpg)
23
Departamento de Engenharia Informática
Modelos fundamentais
13/14 Sistemas Distribuídos 63
Departamento de Engenharia Informática
Modelos fundamentais
• Explicitam quais são as entidades e características
essenciais de um sistema
• Permitem-nos:
– Generalizar o o que é possível e impossível resolver nesse
modelo (por provas matemáticas
– Desenhar soluções mais facilmente, pois não pensamos nos
detalhes de hardware, etc
– Provar matematicamente propriedades das nossas soluções
• fiabilidade, desempenho, escalabilidade, segurança
– Determinar facilmente se determinada solução funciona num
sistema em particular
• basta verificar se os pressupostos do modelo usado para a
solução se verificam no sistema em particular
13/14 Sistemas Distribuídos 64
![Page 24: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/24.jpg)
24
Departamento de Engenharia Informática
Modelos fundamentais
• Logo, antes de desenhar qualquer solução, é
muito boa prática definir os modelos
fundamentais!
• Três modelos fundamentais:
– Modelo de interacção
– Modelo de faltas
– Modelo de segurança
13/14 Sistemas Distribuídos 65
Departamento de Engenharia Informática
Modelo de Interacção
• Pressupostos sobre o canal de comunicação?
– Latência, que inclui:
• Tempo de espera até ter acesso à rede +
• Tempo de transmissão da mensagem pela rede +
• Tempo de processamento gasto em processamento local para enviar e
receber a mensagem
– Largura de banda
• Quantidade de informação que pode ser transmitida simultaneamente
pela rede
– Jitter
• Que variação no tempo de entrega de uma mensagem é possível?
– Canal assegura ordem de mensagens?
– Mensagem pode chegar repetida?
• E sobre os relógios locais?
– Taxa com que cada relógio local se
desvia do tempo absoluto
Mais à frente no semestre, analisaremos modelos de
interacção em maior detalhe
13/14 Sistemas Distribuídos 66
![Page 25: 2 - Modelos e Arquitecturas -2014 - tagus [Modo de …disciplinas.ist.utl.pt/~leic-sod.daemon/2013-2014... · 2014-02-26 · menor facilidade) sobre várias arquitecturas físicas](https://reader033.vdocuments.pub/reader033/viewer/2022052919/5be43ca609d3f2f9648c362e/html5/thumbnails/25.jpg)
25
Departamento de Engenharia Informática
Modelo de Falhas
• Que componentes podem falhar?
• De que forma podem falhar?
• Por enquanto, assumiremos modelo simples:
– Processos podem falhar silenciosamente
– Mensagens podem perder-se na rede
Mais à frente no semestre, analisaremos outros modelos de falhas em maior detalhe
13/14 Sistemas Distribuídos 67
Departamento de Engenharia Informática
Modelo de Segurança
• Que ameaças existem sobre o sistema?
• Que ataques são possíveis?
• Por enquanto, assumiremos que não existem
quaisquer ameaças sobre o sistema
Mais à frente no semestre, analisaremos modelos de segurança mais realistas
13/14 Sistemas Distribuídos 68