Modelos e Arquitecturas 2013

Transcrição

Modelos e Arquitecturas 2013
Departamento de Engenharia Informática
Sistemas Distribuídos
Revisão de redes
Modelos e arquitecturas
12/13
Sistemas Distribuídos
1
Departamento de Engenharia Informática
Objectivo das aulas desta semana
• Rever o modelo de arquitectura das redes
• Rever a forma de programação distribuída
baseada em mensagens (aulas práticas)
• Compreender o modelo cliente-servidor e suas
evoluções
• Perceber as limitações do modelo de
programação baseado em mensagens e a
evolução para o RPC
Ca
Revisão baseada nos Capitulos do livro 2, 3 e 4
12/13
Sistemas Distribuídos
2
Departamento de Engenharia Informática
Aplicações
Middleware
Bibliotecas (DLL)
Protocolos
Servidores
Sistema
Operativo
Plataformas
de
Middleware
Nova camadas de software
Middleware
Plataformas
Hardware
Os Sistemas Distribuídos são suportados por diversas componentes
frequentemente designadas por plataformas de Middleware
12/13
Sistemas Distribuídos
3
Departamento de Engenharia Informática
A rede que interliga o
sistema distribuído
Revisão
12/13
Sistemas Distribuídos
4
Departamento de Engenharia Informática
Programação da comunicação: modelo
porto
porto
Canal de comunicação
modo utilizador
lógico
rede
rede
transporte
API da
comunicação
Processo
físico
Processo
modo sistema
12/13
Sistemas Distribuídos
5
Departamento de Engenharia Informática
Redes de Dados
• Fornecer uma base mínima de compreensão
das redes de dados
– Arquitectura
– Organização
– Protocolos
Revisão
• Identificar os aspectos relevantes das redes de
dados na concepção de sistemas distribuídos
12/13
Sistemas Distribuídos
6
Departamento de Engenharia Informática
Características habituais das Arquitecturas
Físicas
•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
12/13
•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
Sistemas Distribuídos
8
Departamento de Engenharia Informática
Modelo OSI
12/13
Sistemas Distribuídos
10
Departamento de Engenharia Informática
Modelo OSI
Do nível físico ao nível transporte
Processo Utilizador
Rede IP
Rede TCP
Frame
Relay
Anel (ring)
ATM
GPRS
Ethernet
Malha (mesh)
UMTS
Bus
Processo Utilizador
12/13
Sistemas Distribuídos
11
Departamento de Engenharia Informática
OSI - Nível Físico
• 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.
Anel (ring)
• 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 conectores
12/13
Sistemas Distribuídos
Malha (mesh)
Bus
12
Departamento de Engenharia Informática
OSI - Nível Lógico ou
Ligação de Dados
• 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
12/13
Frame
Relay
ATM
GPRS
Ethernet
UMTS
Sistemas Distribuídos
13
Departamento de Engenharia Informática
OSI - Nível Rede
Rede IP
• 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
12/13
Sistemas Distribuídos
14
Departamento de Engenharia Informática
Processo Utilizador
Nível Transporte
Rede TCP
• 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
12/13
Processo Utilizador
Sistemas Distribuídos
15
Departamento de Engenharia Informática
A Internet como um Relógio de Areia
Mail
Web
Audio
Passível de
alterações
Maior inovação
Ethernet
12/13
VoIP
Video
IM
TCP / UDP
Web Services
Difícil de alterar
IP
GPRS
802.11
Satélite
Sistemas Distribuídos
Bluetooth
16
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)
Exemplos
Problemas?
• telnet, rlogin, Winrdpaplicações de terminal
remoto
• ftp, samba – Transferência
de ficheiros
• SMTP – Correio electrónico
12/13
• Cada aplicação possui um
protocolo próprio
• Dificulta a utilização do
protocolo por terceiros
• Desempenho porque é
executado em modo utilizador
Sistemas Distribuídos
17
Departamento de Engenharia Informática
Interfaces de Comunicação
Máquina A
aplicação
Sockets, TLI
OS kernel
12/13
Máquina B
Níveis
7a5
Nível 4
Transporte
Níveis
3a1
Níveis
7a5
Nível 4
Transporte
Níveis
3a1
Sistemas Distribuídos
aplicação
Sockets, TLI
OS kernel
18
Departamento de Engenharia Informática
Caracterização do canal de Comunicação
Tipos de canais
• 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
12/13
Sistemas Distribuídos
19
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
12/13
Sistemas Distribuídos
20
Departamento de Engenharia Informática
Aula Prática – 1º Semana
12/13
Sistemas Distribuídos
22
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)
Departamento de Engenharia Informática
Sockets sem Ligação
Servidor
Cliente
socket
socket
bind
bind
sendto
recvfrom
sendto
recvfrom
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[]){
Constrói um socket datagram
// args give message contents and server hostname
DatagramSocket aSocket = null;
(associado a qualquer porto
try {
disponível)
aSocket = new DatagramSocket();
byte [] m = args [0].getBytes();
InetAddress aHost = InetAddress.getByName(args[1]);
Conversão do nome
Int serverPort = 6789;
DNS para endereço IP
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);
Cada mensagem
aSocket.receive(reply);
System.out.println(“Reply:” + new
enviada tem que
String(reply.getData()));
levar junto
} catch (SocketException e){System.out.println(“Socket:” +
e.getMessage());
identificador do
} catch (IOException e){System.out.println(“IO:” +
e.getMessage());
processo destino:
} finally { if(aSocket ! = null) aSocket.close();}
IP e porto
}
}
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;
Constrói um socket datagram
try{
(associado ao porto 6789)
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(),
Recebe mensagem
request.getPort());
aSocket.send(reply);
}
Extrai da
} catch (SocketException e){System.outprintln(“Socket:”+
mensagem o
e.getMessage());
IP e porto do
} catch (IOException e){System.out.println(“IO:” +
e.getMessage());
processo
} finally {if(aSocket ! = null) aSocket.close();}
origem para
}
responder
}
Departamento de Engenharia Informática
Sockets com Ligação
Servidor
Cliente
socket
Servidor
bind
Socket
Escuta
listen
socket
accept
connect
read
write
write
read
Socket
Ligação
Cliente
bytes
bytes
Socket
Cliente
Departamento de Engenharia Informática
Sockets Stream em Java (Cliente)
•
•
•
•
•
•
•
•
•
•
WriteUTF /
•
readUTF – •
para
•
Universal •
transfer
•
•
format / para
•
as cadeias de
•
caracteres
•
•
•
import java.net*;
import java.io*;
public class TCPClient{
public static void main(String args[]){
• classe Socket – suporta o socket
// args: message and destin. hostname
Socket s = null;
cliente. Argumentos: nome DNS
try{
do servidor e o porto.
int server Port = 7896;
• Construtor
não só cria o socket
s = new Socket (args[1],
serverPort);
DataInputStream = new
como efectua a ligação TCP
DataInputStream(s.getInputStream());
DataOutputStream out =
newDataOutputStream (s.getOutputStream());
out.writeUTF(args[0]);
String data = in.readUTF();
Métodos getInputStream /
System.out.prtintln(“Received: ” + data);
getOutputStream – permitem
}catch (UnknownHostException e){
aos dois streams
System.out.println(“Sock:”aceder
+ e.getMessage());
}catch (EOFException
definidos pelo socket
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}
}
Departamento de Engenharia Informática
Sockets Stream em Java (Servidor)
•
•
•
•
•
•
•
•
•
import java.net*;
import java.io*;
Cria socket servidor que fica à
public class TCPServer{
escuta
no porto “serverPort”
public static void main(String
args[]){
try{
Bloqueia até cliente
int server Port = 7896;
estabelecer ligação.
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());}
Cria novo socket servidor com quem é
}
estabelecida ligação com o cliente e
}
onde os dados são recebidos
Departamento de Engenharia Informática
Aula prática
• SocketClient.java
• SocketServer.java
12/13
Sistemas Distribuídos
32
Departamento de Engenharia Informática
Integração da Comunicação no Sistema
Operativo
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
Departamento de Engenharia Informática
Winsock Implementation
Application
Mswsock.dll
SPI
Msafd.dll
Wshtcpip.dll
Service Providers
Ntdll.dll
NtReadFile, NtWriteFile,
NtCreateFile,
NTDeviceloControlFile User mode
Kernel mode
\Device\AFD
TDI IRPs
Protocol drivers
IPX/SPX
AFD FSD
TDI
NetBEUI
TCP/IP
Departamento de Engenharia Informática
Três gerações de sistemas distribuídos
• Sistemas distribuídos iniciais
– Final da década de 70, início da década de 80
– 10-100 nós ligados por uma rede local, ligação limitada à internet
– Poucos serviços oferecidos (partilha de ficheiros, impressoras, email)
• Sistemas à escala da Internet
–
–
–
–
Década de 90
Sistema global de larga escala, composto por redes de redes
Altamente heterogéneo
Nós são essencialmente servidores e desktops
• Sistemas contemporâneos
– Inclui nós móveis (laptops, smart phones, etc)
– Inclui nós embebidos em “coisas” (e.g. máquinas de lavar, smart
homes)
– Nós autónomos substituídos por grupos de nós que oferecem serviços
na Cloud
12/13
Sistemas Distribuídos
43
Departamento de Engenharia Informática
Três gerações de sistemas distribuídos
12/13
Sistemas Distribuídos
44
Departamento de Engenharia Informática
Modelos arquitecturais
12/13
Sistemas Distribuídos
45
Departamento de Engenharia Informática
Quem são as entidades que comunicam
através da rede num sistema distribuído?
Por omissão, assumiremos
sistema distribuído de processos
• 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)
12/13
Sistemas Distribuídos
46
Departamento de Engenharia Informática
Como comunicam estas entidades?
12/13
Sistemas Distribuídos
47
Departamento de Engenharia Informática
Comunicação directa
• Interface de comunicação entre-processos
• Invocação remota
– Protocolos de pedido-resposta
• Exemplo: HTTP
Estudaremos
ambos em breve
– 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
12/13
Sistemas Distribuídos
48
Departamento de Engenharia Informática
Comunicação directa
Exemplo: chamada remota de procedimentos
CLIENTE
SERVIDOR
Chamada ao procedimento remoto:
envio dos parâmetros
Bloqueia-se
Execução do
procedimento
pedido
Cliente bloqueado
Retoma a execução
Retorno do procedimento remoto:
devolução dos resultados
Sistemas Distribuídos 2009/10
12/13
Sistemas Distribuídos
49
Departamento de Engenharia Informática
Comunicação directa
Exemplo: invocação remota de métodos
• As potencialidades da noção de objecto tornaram-na
atractiva para descrever diversos conceitos em Eng.
Informática
– dando origem a uma tendência de evolução que se designa por
OO de Object Oriented
• Diferenças entre a aproximação baseada em objectos e
uma arquitectura cliente-servidor:
– No RPC invocam-se funções, os dados são entidades separadas
– Num sistema de objectos invoca-se uma função num
determinado objecto que, como contém o seu próprio estado,
torna indissociável a invocação da operação dos dados a que
se aplica
12/13
Sistemas Distribuídos
50
Departamento de Engenharia Informática
Comunicação directa
Exemplo: invocação remota de métodos
Objecto remoto
Interface
Remota
Dados
m1
m2
m3
•
Código
dos
métodos
m4
m5
m6
Exemplos de Plataformas
– RMI do Java
– DCOM – Distributed Component Object Model - Microsoft
– Common Object Request Broker Architecture (CORBA) - Object Management
Group (OMG)
12/13
Sistemas Distribuídos
51
Departamento de Engenharia Informática
Comunicação indirecta
• Em comunicação directa, em geral:
– Emissor tem de conhecer receptor
– Emissor e receptor têm de existir simultaneamente
• Paradigmas de comunicação indirecta
introduzem terceira entidade para permitir:
– Desacoplamento espacial
• Emissor de mensagem não precisa conhecer receptor(es)
– Desacoplamento temporal
• Emissor e receptor não têm de existir simultaneamente
12/13
Sistemas Distribuídos
52
Departamento de Engenharia Informática
Comunicação indirecta: paradigmas
• Comunicação em grupo
– Suporte a comunicação um-para-muitos
– Emissor envia mensagem a um identificador de grupo
• Não precisa saber quem são os membros do grupo
• Sistemas publicador/subscritor (publish-subscribe)
– Publicadores emitem mensagens (chamadas eventos)
– Subscritores registam-se e expressam interesse em
determinados eventos
– Cada mensagem publicada é disseminada aos subscritores
interessados
12/13
Sistemas Distribuídos
53
Departamento de Engenharia Informática
Comunicação indirecta: paradigmas
• Filas de mensagens
– Troca de mensagens ponto-a-ponto em que há desacoplamento
espacial/temporal
– Emissor coloca mensagem em fila (mantida por um servidor central broker), receptor retira mensagem de uma fila
– As mensagens recebidas pelo broker podem ser reformatadas,
combinadas ou modificas por forma a serem entendidas pelo sistema
de destino
– Normalmente não é necessário modificar os sistemas envolvidos. Os
Message Brokers fornecem adaptadores para as aplicações mais
comuns (SAP, Baan, PeopleSoft, etc.).
12/13
Sistemas Distribuídos
54
Departamento de Engenharia Informática
Comunicação indirecta: paradigmas
• Partilha de memória distribuída
– Permitem que processos que não partilham
memória física escrevam e leiam estruturas de
dados em memória distribuída
– Sistema mantém cópias locais da memória
partilhada e sincroniza alterações através de troca
de mensagens
• Tudo transparentemente à aplicação
– Variante recente deste paradigma: espaços de
tuplos
12/13
Sistemas Distribuídos
55
Departamento de Engenharia Informática
Papéis e responsabilidades
12/13
Sistemas Distribuídos
57
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
Client
invocation
Server
invocation
result
result
Server
Client
Key:
Process:
12/13
Computer:
Sistemas Distribuídos
58
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
Sharable
• Mais ampla distribuição objects
de carga (computação e
rede)
Peer 2
Peer 1
Application
Application
Peer 3
Application
– Maior escalabilidade
– Sistema expande-se
acrescentando mais
pares
Peer 4
Application
Peers 5 .... N
• Coordenação mais
complicada que clienteservidor
12/13
Sistemas Distribuídos
59
Departamento de Engenharia Informática
Entre-Pares (Peer-to-Peer)
12/13
Sistemas Distribuídos
60
Departamento de Engenharia Informática
Como mapear objectos e serviços no
modelo físico?
12/13
Sistemas Distribuídos
61
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
12/13
Service
Server
Client
Server
Client
Server
Sistemas Distribuídos
62
Departamento de Engenharia Informática
Serviço Oferecido por Múltiplos Servidores
12/13
Sistemas Distribuídos
63
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
Web
server
Client
Proxy
server
Web
server
Client
12/13
Sistemas Distribuídos
64
Departamento de Engenharia Informática
Servidores Proxy e Caches
12/13
Sistemas Distribuídos
65
Departamento de Engenharia Informática
Código Móvel (Applets)
a) client request results in the downloading of applet code
Client
Applet code
Web
server
b) client interacts with the applet
Client
Applet
Web
server
• 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
12/13
Sistemas Distribuídos
66
Departamento de Engenharia Informática
Código Móvel (Applets)
12/13
Sistemas Distribuídos
67
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
12/13
Sistemas Distribuídos
68
Departamento de Engenharia Informática
Modelos fundamentais
12/13
Sistemas Distribuídos
69
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
12/13
Sistemas Distribuídos
70
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
12/13
Sistemas Distribuídos
71
Departamento de Engenharia Informática
Modelo de Interacção
Mais à frente no semestre,
analisaremos modelos de
interacção em maior detalhe
• 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
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
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