SD Slides

Sistema distribudo?
Um sistema distribudo um conjunto de componentes

hardware e software interligados atravs de uma infra-estrutura de
Sistemas Distribudos comunicao, que cooperam e se coordenam entre na execuo
de aplicaes
LEI (1 ciclo) 2010/2011
http://asc.di.fct.unl.pt/sd1
No mbito desta cadeira, vamos esquecer os sistemas que
cooperam e se coordenam pela partilha de memria fsica comum
Vitor Duarte (T, P1, P2)

David Navalho (P3)
slides baseados nos de SD 2009/2010 por Nuno Preguia
Hoje em dia, os sistemas Informticos so normalmente
distribudos !
Material de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 1 Material de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 2
Motivaes dos Sistemas Distribudos Principais objectivos da cadeira
Acesso generalizado sem restries de localizao Caractersticas essenciais dos sistemas distribudos
utilizadores fixos ou mveis modelos, metodologias e tcnicas de concepo e
desenvolvimento.
Partilha dos recursos distribudos
factores que influenciam a funcionalidade, simplicidade,
impressores, ficheiros, ...
desempenho, fiabilidade, segurana e resistncia a falhas.
Distribuio da carga
melhoria do desempenho Implementar um sistema distribudo funcional no
trivial, com recurso a tecnologias standard de
Lidar com falhas
comunicao: invocao remota usando RMI, SOAP,
melhoria da disponibilidade
REST.
Flexibilidade e adaptabilidade
Decomposio de um sistema complexo num conjunto de sistemas mais
simples
Programa das aulas tericas Bibliografia
Introduo aos sistemas distribudos Principal:

Modelos de sistemas distribudos G. Coulouris, J. Dollimore and T. Kindberg,
Distributed Systems - Concepts and Design,
Comunicao em sistemas distribudos (parte 1: comunicao ponto-a-
Addison-Wesley, 4th Edition, 2005
ponto)
Invocao de mtodos/procedimentos remotos

Complementar:
Web services e modelos alternativos de interaco cliente/servidor na
internet Tericas
A. Tanenbaum, M. van Steen,
Segurana em sistemas distribudos Distributed Systems: Principles and Paradigms,
Prentice Hall, 2007
Comunicao em sistemas distribudos (parte 2: comunicao multi-ponto)
Prticas
Servios de designao e descoberta Elliote Rusty Harold ,
Java Network Programming,
Gesto de ficheiros distribudos e introduo s tcnicas de replicao O'Reilly & Associates, 2004
1
Sistemas Distribudos na Engenharia Informtica Aulas prticas
Sistemas Distribudos 1 ciclo Pressuposto: alunos conhecem primitivas de comunicao TCP/IP

Introduo, Modelos, Comunicao, Invocao remota, (java.net)
Segurana, Naming, Web services SOAP e REST, Sistemas
de ficheiros distribudos 1 ciclo
E.g.: Distributed Systems, Coulouris et. al., 4th edition:
Cap. 1, 2, 4, 5, 7, 8, 9, 19 Sistema Java RMI
Web services SOAP e REST
Sistemas Distribudos 2 ciclo

Modelos, Tempo, Alg. Coordenao, Transaces
2 ciclo Segurana em sistemas de invocao remota
Nomeao e Sist. Ficheiros distribudos

distribudas, Replicao e tolerncia a falhas, Sistemas
peer-to-peer
E.g.: Distributed Systems, Coulouris et. al., 4th edition:
Cap. 2, 10, 11, 12, 13, 14, 15
Trabalho prtico ao longo do semestre
Engenheiro Informtico
Material didctico Avaliao (1)
Hardware: Componentes da avaliao: exame final (70%) e frequncia (30%)

Laboratrio com um conjunto de computadores ligados atravs de uma rede Nota: todas as notas intermdias so aproximadas s dcimas.
local. Sistemas de operao Linux e Windows.
Software: Exame final. O exame final sem consulta e pode incluir questes
Sistema Java 6.0 para Linux e Windows. sobre os trabalhos (mas no sobre programao).
...
Documentao:
Cpia dos transparentes de apoio s aulas tericas Frequncia. Teste prtico e trabalho prtico.
Cpia dos transparentes de apoio s aulas prticas O teste prtico sem consulta e incide sobre a matria das aulas prticas e do
Cdigo de exemplos e exerccios trabalho prtico.
O trabalho prtico ter duas partes, havendo pelo menos uma opo em cada
Informaes e bibliografia on-line: uma.
http://clip.unl.pt/ Nota de frequncia = 50% * teste + 50% * trabalho
http://asc.di.fct.unl.pt/sd1
Avaliao (2) Avaliao (3)
Trabalho prtico Melhorias de nota ou alunos com frequncia positiva.

A nota de frequncia obtida vlida e ser usada no clculo da nota final, se no
Para o trabalho prtico, sero definidas:
voltarem a fazer a prtica!
As funcionalidades mnimas que o trabalho deve implementar. Os alunos cujos
trabalhos no implementem essas funcionalidades mnimas no tm
frequncia. Condies de aprovao na cadeira:
As funcionalidades opcionais e a sua valorizao na nota do trabalho. entrega da soluo dos trabalhos a realizar em grupo que implemente as
Os prazos intermdios e final de entrega. funcionalidades mnimas indicadas no enunciado, e
A avaliao ser obtida pela avaliao do trabalho efectuado, relatrio e pode incluir
a nota do teste prtico maior ou igual a 8,0 valores, e
uma discusso sobre o mesmo com todos os elementos do grupo.
a nota final da frequncia tem que ser maior ou igual a 9,0 valores, e
A seleco de quais os grupos que estaro sujeitos a discusso dos trabalhos prticos a nota do exame final terico tem que ser maior ou igual a 9,0 valores, e
ter em considerao, entre outros, os seguintes critrios: a nota final tem que ser maior ou igual a 9,5 valores.
discrepncia entre a nota do teste prtico e a nota do trabalho prtico;
discrepncia entre as notas dos vrios elementos do grupo;
nota elevada na avaliao do trabalho prtico. NOTA: qualquer problema com prazos (ou outros) deve ser
colocado ao docente ATEMPADAMENTE!
Os alunos que, sem justificao, falhem prazos, tm uma penalizao de 1 valor por
dia de atraso. Se, sem justificao, no comparecerem ao teste ou discusso, no
tm frequncia.
2
Planeamento (tentativo) Resumo (datas sujeitas a confirmao)
T (Qua) T (Sex) P (Sex)
13 Set Apresentao Introduo -- Trabalho semanal:
20 Set Modelos Modelos Reviso (java.net) 3 h aulas tericas
27 Set Comunicao Comunicao Passar dados 2 h aulas prticas
4 Out RMI/RPC RMI RMI 2-4 h estudo
11 Out RMI RMI RMI TRAB 3-5 h trabalho prtico
18 Out WS WS WS TRAB 22 Out - fase 0
Aulas prticas a partir da prxima semana
25 Out RESt Segurana RESt TRAB
1 No Segurana Segurana Cripto TRAB Trabalho prtico: enunciado na semana de 11 de Outubro

Grupos de 2 alunos
8 No Segurana Comunicao Mult Cripto TRAB 8 Nov - fase 1
Entrega final a 8 Dezembro
15 No Nomes Nomes Nomes TRAB
22 No Nomes Ficheiros Ficheiros TRAB 25 Nov - fase 2 27Nov - teste Teste prtico a 27 de Novembro
29 No F -- 1 dez Ficheiros duvidas TRAB Horrio preferencial de atendimento:
6 Dez F -- 8 dez Ficheiros -- 8 Dez - final Quintas 10h-11h
avaliao
13 Dez Ficheiros revises avaliao trabalhos
3
Nota prvia
A estrutura da apresentao semelhante e utiliza algumas das

figuras do livro de base do curso
Sistemas Distribudos G. Coulouris, J. Dollimore and T. Kindberg,

LEI (1 ciclo) 2010/2011 Addison-Wesley, 4th Edition, 2005
(cap. 1)
Captulo 1
Introduo
Organizao do captulo Definio de sistema distribudo
Definio, exemplos de sistemas distribudos Um sistema distribudo um conjunto de componentes

hardware (ns, hosts, mquinas ou computadores) e software
Caractersticas essenciais dos sistemas distribudos interligados atravs de uma infra-estrutura de comunicaes
Desafios: heterogeneidade, abertura, segurana, escala, falhas, (geralmente uma rede de computadores ou um bus especial, ),
concorrncia, transparncia que cooperam e se coordenam entre si apenas pela troca de
mensagens, para execuo de aplicaes distribudas (pelos
diferentes computadores)
No mbito desta cadeira, vamos esquecer os sistemas que

cooperam e se coordenam pela partilha de memria fsica comum
Exemplo: servios na Internet Exemplo: servios em intranets

Intranets: redes isoladas fisicamente, redes isoladas logicamente (private virtual network), ligao
Internet atravs de firewalls, etc.
email server Desktop

computers
intranet

print and other servers

ISP

Local area
Web server network
backbone

email server
File server print

satellite link

desktop computer:
other servers
server:
the rest of
network link:
Web (HTTP), E-mail (SMTP); the Internet
instant-messaging (e.g.Icq); router/firewall
VoIP (e.g.Skype); etc.
Servios da Internet +
Material de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 5 impresso; sistemas de ficheiros; etc. Material de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 6
1
Exemplo: servios em ambientes de computao Exemplo: computao ubqua
mvel
Exploso no nmero de dispositivos existentes
Dispositivos associados a utilizadores
Computadores, telemveis, etc. RF-ids ??
Dispositivos associados a objectos, animais
Dispositivos embebidos
RF-ids
Ns de redes de sensores
Internet/Intranet + Abre a possibilidade de criar novas aplicaes distribudas

descoberta automtica; Numa casa: controlo de luzes, frigorfico, TV, etc.
localizao; adaptao dos No supermercado: controlo de compras com RF-ids, etiquetas electrnicas
dados; execuo remota; etc. No ambiente: monitorao de condies atmosfricas em vinhas, florestas,
etc.; localizao em hospitais; criao de cercas virtuais; etc.
Computao mvel: execuo de tarefas em dispositivos portteis durante Etc.
o movimento do utilizador ou em locais diferentes do habitual ambiente de
trabalho
Mltiplos dispositivos portteis Abordado na discipliana de Sistemas de Computao Mvel e Ubqua (2
Diversas redes sem fios: GSM, UMTS, Wi-Max, Wi-Fi, Bluetooth ciclo)
Outros exemplos Motivaes dos Sistemas Distribudos
Sistemas de controlo de processos industriais em fbricas (linhas Acesso generalizado sem restries de localizao
de montagem, gesto de stocks, facturao, ...) Acessibilidade ubqua (suporte para utilizadores fixos, mveis)
Dispositivos ou mquinas especiais controlados atravs de Partilha dos recursos distribudos pelos diferentes utilizadores
conjuntos de computadores embutidos (por exemplo: um avio Exemplos: impressores, ficheiros
ou um carro, equipamento duma fbrica)
Clusters de computadores interligados atravs de redes de alta

velocidade para clculo paralelo ou grandes servidores Distribuio da carga melhoria do desempenho
Tolerncia a falhas
Flexibilidade e adaptabilidade
Decomposio de um sistema complexo num conjunto de sistemas mais
simples
Vantagens potenciais para as aplicaes/servios Desenvolvimento de SD
Ubiquidade e mobilidade Como desenvolver os componentes software em SD (ou pr a

pode ser utilizado independentemente da localizao cooperar os j existentes)?
Custo inferior, ou pelo menos mais racional Que problemas novos temos de ter em conta?
vrias pequenas mquinas em vez de uma s gigantesca
Melhor desempenho
paralelismo real
Maior disponibilidade
se uma mquina falha, as outras podem continuar
Extensibilidade
crescimento incremental
Simplicidade associada modularidade fsica

pode ter processadores dedicados a funes
pode ser distribudo de acordo com a organizao utilizadora
2
Caractersticas fundamentais dos SD Implicaes
Componentes do sistema executam de forma concorrente Nenhum componente tem uma viso exacta instantnea do estado
paralelismo real global de todo o sistema
Necessidade de coordenao entre os vrios componentes
Os componentes tm uma viso parcial do estado global do sistema
Falhas independentes dos componentes e das comunicaes Os componentes do sistemas esto distribudos e s podem cooperar
Impossvel determinar se existe uma falha dum componente ou do atravs da troca de mensagens, as quais levam um tempo no nulo a
sistema de comunicaes propagarem-se
Necessidade de lidar com as falhas
Na presena de falhas, o estado global pode tornar-se incoerente,
Ausncia de relgio global existem limites para a preciso da i.e., as vises parciais do estado global podem tornar-se
sincronizao dos relgios locais incoerentes
Impossvel usar relgios locais para ordenar globalmente todos os Por exemplo, rplicas de um objecto podem ficar incoerentes
eventos (os mesmos eventos podem ser vistos por ordens diferentes
por diferentes componentes)
Principais Desafios Heterogeneidade
Heterogeneidade Do hardware: telemveis, PDAs, portteis (laptops), workstations

(desktops), servidores, multiprocessadores, clusters (agregados), grids,...
Abertura Diferentes caractersticas dos processadores, da memria, da representao
dos dados, dos cdigos de caracteres,...
Transparncia
Das redes de interligao e dos protocolos de transporte: Redes mveis
Concorrncia (GSM, UMTS, CDMA), Wi-Max, WLANs, wired LANs, WANs, ..., TCP/IP, ....
Segurana Do sistema de operao: MSWindows, Unix/Linux/Mac, Simbian, ...

Diferentes interfaces para as mesmas funcionalidades
Escala
Das linguagens de programao....
Falhas
Construir um sistema nico, integrado, coerente, etc. geralmente um

desafio gigantesco
Middleware Mquina virtual
N computadores interligados Objectivo: permitir executar os mesmos programas em mquinas

com diferentes caractersticas
Aplicao distribuda Fornece um ambiente de execuo local uniforme,
independentemente do hardware e sistema de operao
Sistema middleware Programas escritos numa nica linguagem (JavaVM) ou em mltiplas
linguagens (Microsoft CLR)
Sistema de operao Sistema de operao Sistema de operao
Sistema de Sistema de Sistema de Num sistema distribudo permite simplificar o deployment de uma
comunicaes comunicaes comunicaes
aplicao e a utilizao de cdigo mvel (applets, agentes)
Sistema middleware
Sistemas operativos
Interface homognea
Interfaces heterognea Servios mais complexos (invocao
Servios bsicos remota: RMI, Web-services, Corba;
comunicao em grupo: Horus, etc)
Verdadeira interoperabilidade requer
idnticos interface e protocolos
3
Abertura Transparncia
A abertura de um sistema determina o modo como pode ser A transparncia (da distribuio) a propriedade relativa a esconder
acedido, estendido e re-implementado ao utilizador e ao programador das aplicaes a separao fsica dos
elementos que compem um sistema distribudo
Sistemas abertos
Interfaces e modelo conhecidos (incluindo protocolos de Simplicidade e flexibilidade so objectivos
comunicao)
Em certas circunstncias, a transparncia indesejvel
Evoluo controlada por organismos de normalizao independentes
ou consrcios industriais Implementao complexa e desempenho baixo
Permite a interoperao de componentes com diferentes Pode levar a inflexibilidade
implementaes
A transparncia pode manifestar-se em diversos nveis e de vrias
Sistemas proprietrios formas
Podem ser modificados pelo seu dono Vantagens e desvantagens de
cada aproximao?
Outras questes
Middleware suportando vrias linguagens vs. Middleware integrado
com uma s linguagem de programao
Alguns tipos de transparncia Concorrncia
O acesso simultneo a um recurso por vrios clientes

Acesso Esconde as diferenas no modo de acesso a um recurso
pode causar problemas
Localizao Esconde a localizao de um recurso
Necessrio sincronizar as operaes para que os dados
Mobilidade Esconde a mudana de localizao dos recursos e clientes
permaneam consistentes
Num nico computador, solues possveis so e.g. o uso de
Replicao Esconde que o recurso tem vrias cpias semforos, monitores, transaces
Num SD, necessrio implementar tcnicas de sincronizao
Concorrncia Esconde que o recurso pode ser usado por vrios clientes
em concorrncia
Falhas Esconde as falhas e o processo de recuperao
Desempenho/ Esconde a reconfigurao para melhorar o desempenho/

Escalabilidade aumento de recursos ou componentes
Segurana Escala
Necessidade de proteger os recursos e informao gerida num A escala de um sistema distribudo o mbito que o mesmo
sistema distribudo abrange assim como o nmero de componentes.
Recursos tm valor para os seus utilizadores
A escala de um sistema tem vrias facetas:
Segurana tem trs componentes:
recursos usados e utilizadores servidos
Confidencialidade: indivduos no autorizados no podem obter
mbito geogrfico (rede local, pas, mundo, ...)
informao (aceder ao recurso)
Integridade: dados no podem ser alterados ou corrompidos mbito administrativo (uma organizao, inter-organizaes)
Disponibilidade: acesso aos dados deve manter-se disponvel Um sistema de pequena escala um sistema confinado a uma
Aspectos envolvidos: organizao pequena / mdia, com poucos utilizadores e poucos
Autenticao dos utilizadores componentes.
Autenticao das plataformas de hardware/software
Comunicao segura Um sistema de grande escala um sistema com muitos recursos ou
Preveno de falhas/ataques de negao de servio (denial of utilizadores, ou cobrindo uma rea geogrfica significativa, ou
service attacks) envolvendo muitas organizaes.
Segurana na presena de cdigo mvel
4
Exemplo da prpria internet Sistema escalvel
Os protocolos e servios bsicos da internet tm respondido ao seu Um sistema capaz de escalar (escalvel) um sistema que
crescimento continua eficaz quando h um aumento significativo do nmero
de recursos ou utilizadores
i.e., em que no necessrio alterar a implementao dos
componentes e da forma de interaco dos mesmos
Data Computadores Servidores Web Num sistema escalvel, as seguintes propriedades devem ser
verdadeiras:
Dez. 1979 188 0
Os recursos envolvidos devem aumentar linearmente com a dimenso
Jul. 1989 130.000 0 do sistema
Jul. 1999 56.218.000 5.560.866 O aumento na dimenso dos dados, dos recursos ou utilizadores no
deve levar a uma diminuio significativa do desempenho a reduo
Jul. 2006 439.286.364 88.166.395
no deve ser superior a O(log n)
Dez. 2009 ~690.000.000 ~234.000.000 Possvel aproximao: recurso a estruturas hierrquicas (ex.: DNS)
fonte: http://www.zakon.org/
robert/internet/timeline
Como lidar com a escala ? Falhas (avarias, erros )
Para reduzir o nmero de pedidos tratados por cada componente Os componentes de um sistema podem falhar, i.e., comportar-se
Diviso de um componente em partes e sua distribuio de forma no prevista e no de acordo com a especificao devido
Replicao e caching (problema da consistncia entre rplicas e a erros (por exemplo a presena de rudo num canal de
caches) comunicao ou um erro de software) ou avarias (mecanismo que
que entra em mau funcionamento)
Para reduzir dependncias entre componentes
Meios de comunicao assncronos
Para simplificar o sistema Num sistema distribudo, as falhas so geralmente parciais (num
Uniformidade de acesso aos recursos e dos mecanismos de componente do sistema) e independentes
cooperao, sincronizao, etc. Um componente em falha pode induzir uma mudana de estado
Meios de designao universais (independentes da localizao e dos incorrecta noutro componente, levando eventualmente o sistema a
recursos) falhas, i.e., a ter um comportamento no de acordo com a sua
especificao.
Como lidar com as falhas Como lidar com as falhas
Detectar falhas Tolerar falhas

Possvel: e.g.: mensagens corrompidas atravs de checksums Definio do comportamento na presena de falhas
Pode ser impossvel: Falha (crash) num computador remoto Continuar a funcionar de acordo com a especificao recorrendo a
Desafio: Funcionar atravs da suspeio das falhas componentes redundantes
Parar o sistema at falhas serem resolvidas
Mascarar falhas (aps a sua deteco)
Exemplos: retransmisso de mensagens, redundncia, Recuperao de falhas
Mesmo num sistema que tolere falhas necessrio recuperar
os componentes falhados. Porqu?
Problema: recuperar estado do servio, considerando que
algumas operaes podem ter sido parcialmente executadas
5
Para saber mais
G. Coulouris, J. Dollimore and T. Kindberg,

Distributed Systems Concepts and Design,
Captulo 1.
Material de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 31
6
Nota prvia
A estrutura da apresentao semelhante e utiliza algumas das

figuras do livro de base do curso
Sistemas Distribudos G. Coulouris, J. Dollimore and T. Kindberg,

LEI (1 ciclo) 2010/2011 Addison-Wesley, 4th Edition, 2005
(cap. 2)
Captulo 2
Arquitecturas e Modelos de Sistemas Distribudos
Terminologia Organizao do captulo
Processo: programa a executar num computador Modelos arquitecturais usados para descrever os sistemas em
Objecto: quaisquer dados manipulados por um processo (ex.: termos de componentes e suas relaes
ficheiro, base de dados, objecto) Camadas de software
Cliente-servidor, peer-to-peer, variantes
Servio: conjunto de operaes disponibilizadas a Modelos fundamentais usados para descrever propriedades
processos remotos parciais, comuns a todas as arquitecturas
Necessrio definir o interface e o protocolo de acesso ao Modelo de interaco
servio Modelo de falhas
Um servio pode ser fornecido por qualquer arquitectura Modelo de segurana
discutida neste captulo
Camadas de software
N computadores interligados
Alguns dos problemas no desenvolvimento de sistemas distribudos:
Utilizao diversificada
Diversidade de ambientes Aplicao distribuda
Sistema middleware
Sistema de operao
Plataforma
Sistema de operao Sistema de operao

Sistema de Sistema de Sistema de
comunicaes comunicaes comunicaes
O middleware fornece uma interface homognea (esconde a

heterogenidade) de mais alto nvel (facilita a programao) que a
disponibilizada pela plataforma
Limitaes: algumas funcionalidades apenas podem ser implementadas de

forma eficaz com o conhecimento da semntica da aplicao, pelo que
fornecer essa funcionalidade no sistema de middleware seria
contraproducente (correco de erros, segurana, etc.)
1
Arquitectura do sistema Cliente/Servidor
Arquitectura do sistema Cliente Servidor

Define os componentes do sistema distribudo, identificando as suas
funes de forma simples e abstracta
Identifica a localizao dos componentes numa rede Pedido / resposta
Identifica as inter-relaes entre os componentes (incluindo os
padres de comunicao) Cliente
Cliente
A arquitectura tem implicaes no desempenho, fiabilidade e
segurana do sistema
Sistema em que os processos podem ser divididos em dois tipos, de

acordo com o seu modo de operao:
Servidor: programa que implementa um servio executando
operaes solicitadas pelos clientes e enviando o respectivo resultado
Cliente: programa que usa o servio efectuando pedidos a um
processo servidor
Cliente/Servidor: propriedades Modelo peer-to-peer
Modelo simples (o mais comum e usado na prtica)
Interaces simples (pedido/resposta)
Servidor um ponto de falha nico
No escala para alm dum dado limite (servidor pode tornar-se um

bottleneck)
Segurana apenas tem de se concentrar no servidor
Todos os processos tm funcionalidades semelhantes

Durante a sua operao podem assumir o papel de clientes e
Variantes podem eliminar/diminuir problemas
servidores do mesmo servio em diferentes momentos
Exemplos: partilha de ficheiros, VoIP, edio colaborativa
Modelo peer-to-peer: propriedades Variantes do modelo cliente/servidor: servidor
Interaco mais complexa (do que num sistema cliente/servidor) Cliente/servidor replicado
leva a implementaes mais complexas Existem vrios servidores idnticos (i.e. capazes de responder aos
Operaes de pesquisa so complexas mesmo pedidos)
Vantagens
No existe ponto nico de falha Permite distribuir a carga, melhorando o desempenho (potencialmente)
No existe um ponto de falha nico
Melhor potencial de escalabilidade Problemas
Manter estado do servidor coerente em todas as rplicas
Maior nmero de computadores envolvidos pode colocar questes
Recuperar da falha parcial de um servidor
relativas a Service
Heterogeneidade
Segurana Server
Client
Server
Apropriado para ambientes em que todos os participantes querem

cooperar para fornecer uma dado servio Client
Server
Capacidade agregada >> capacidade individual
2
Variantes do modelo cliente/servidor: servidor Variantes do modelo cliente/servidor: cliente
Cliente/servidor particionado Cliente leve (thin client)/servidor

Existem vrios servidores com a mesma interface, cada um capaz de O cliente apenas inclui um interface (p.e. grfico) para executar
responder a uma parte dos pedidos (ex. DNS) operaes no servidor (ex: web-browser)
Servidor redirige cliente para outro servidor (iterativo) Vantagens:
Servidor invoca pedido noutro servidor (recursivo) Cliente pode ser muito simples
Vantagens Desvantagens
Permite distribuir a carga, melhorando o desempenho (potencialmente) Maior carga no servidor
No existe um ponto de falha nico Interaco mais lenta
Problemas
Falha de um servidor impede acesso aos dados presentes nesse servidor
Compute server
Network computer or PC
Thin network Application

Client Process
Variantes do modelo cliente/servidor: cliente Noo de proxy de um servio
Cliente completo (estendido)/servidor Web

Client
O cliente executa localmente algumas operaes (ou partes destas) server
Proxy
Vantagens: server
Permite funcionar quando no possvel contactar o servidor (recorrendo
a caching) Web
Client
Permite diminuir a carga do servidor e melhorar o desempenho server
Desvantagens:
Implementao do cliente mais complexa Proxy de um servio
Processo que fornece um servio recorrendo a um servidor (desse servio)
Necessrio tratar da coerncia dos dados entre o cliente e o servidor
para executar o servio
Utilizaes possveis
Intermedirio simples
E.g.: alguns sistemas aplicam o princpio Web: Google Gears
Intermedirio complexo (gateway)
Transformao dos pedidos
Servio adicional atravs do caching das respostas
Diminuio do tempo de resposta (latncia inferior para o proxy)
Diminuio da carga do servidor
Mascarar falhas do servidor / desconexo
Edge-server Arquitectura de software: modelo three-tier
Sistemas edge-server Em aplicaes de acesso a

Existem servidores colocados nos ISP para responder a pedidos sistemas de informao
E.g. akamai (pginas web), content-distribution networks
Arquitectura de trs nveis (3-tier)
Propriedades
Menor latncia, filtragem, distribuio de carga, etc. Apresentao
Aplicao
Dados
Arquitectura tpica: cliente/

zone A
Client server servidor
original
server
Client zone B
server
3
Variantes do modelo peer-to-peer Variantes do modelo peer-to-peer
Sistemas peer-to-peer estruturados

Os membros do sistema comunicam
xpto.mp3?
de acordo com uma organizao
N113"
definida de forma determinista
E.g. DHT permitem pesquisar valores Cada elemento apenas
xpto.mp3? conhecidos N102" conhece log(n)
xpto.mp3? N responsvel por uma dada chave elementos do sistema
depende do identificador do n
xpto.mp3 Vantagens N32"

Boa latncia/escalabilidade- O(log n) N85"
Sistema peer-to-peer no estruturado lookup( 80)
As ligaes entre os membros so formadas de forma no- Desvantagens N80" N40"
determinista Maior complexidade
E.g. quando se junta rede, um membro escolhe um conjunto de N79"
contactos (os contactos podem variar durante a execuo do sistema)
N52"
N70" N60"
Vantagens:
Simplicidade
Problemas:
Pesquisa pesada (geralmente por inundao)
Latncia/escalabilidade depende da rvore formada
DHTs: caractersticas interessantes Combinao dos modelos c/s e p2p
Identificar informao usando hash seguro hash(info) Cliente + peer-to-peer

Quais as implicaes? Num sistema peer-to-peer, podem existir elementos que
disponibilizam o servio a outros processos (clientes) que no
pertencem ao sistema peer-to-peer
Cada n fica responsvel por tratar um conjunto de identificadores
(de forma determinista) Propriedades:
E.g. cada n tem associado identificador nico gerado aleatoriamente, Permite a um host aceder a um servio disponibilizado por um sistema
ficando responsvel por manter informao cujo identificador mais peer-to-peer
prximo do seu identificador Permite limitar o nmero de processos que fazem parte do sistema
Implicaes: Pesquisa? Distribuio da informao? Replicao da peer-to-peer
informao? Escalabilidade? Falhas?
Usar identificadores para criar um sistema de encaminhamento

overlay, em que qualquer percurso tem, no mximo, log(n) ns
Combinao dos modelos c/s e p2p Exemplo: BitTorrent (resumido e simplificado)
.torrent: contm informao sobre ficheiro a ser partilhado,

Cliente/servidor + peer-to-peer
incluindo: url do tracker, hash seguro de cada bloco do ficheiro
O servio disponibilizado por um sistema pode ser dividido em vrias
(SHA-1)
funcionalidades, sendo umas fornecidas por um sistema cliente/
servidor e outras por um sistema peer-to-peer. Arquitectura:
Neste caso comum o sistema cliente/servidor servir como servio de
Cliente/servidor
directrio.
Tracker: servidor centralizado mantm informao sobre quais os peers
E.g. BitTorrent
que esto a partilhar/descarregar o ficheiro
Propriedades: Peers: acedem ao tracker para obter lista de outros peers a descarregar o
ficheiro
Permite combinar as vantagens de ambos os sistemas
Peer-to-peer
Peers comunicam entre si para trocar blocos do ficheiro
Toma-l d-c (tit-for-tat): peer s envia bloco em troca de outro
bloco
Peer envia alguns blocos a outros peers (sem contrapartida -
aleatoriamente)
Peer descarrega blocos aleatoriamente
Para que serve cada uma destas propriedades?

4
BitTorrent BitTorrent
client client
tracker tracker
client
client
seeder seeder
client client
BitTorrent BitTorrent + DHT
client BitTorrent tem a possibilidade de funcionar sem tracker

Ou seja: com trackers nos peers
Neste caso, os peers formam uma DHT

tracker Cada n gera um identificador nico
client
Cada torrent tem um identificador nico
Informao sobre quais os ns que esto a partilhar/descarregar um

ficheiro armazenada nos ns com identificadores mais prximos
client
seeder Nota: baseado no sistema Kademlia (2002)

client
Ainda outros exemplos Exemplo: KaZaA
Sistemas peer-to-peer hierrquicos Arquitectura:

Subconjunto de super-ns que se agrupam como num sistema peer- Super-ns (SN): ns com maior capacidade
to-peer tornam-se super-ns
Outros ns ligam-se a um super-n Cada SN tem 60-150 ns ligados
Cada SN liga-se a outros 30-50 SN
Peers (ordinary node ON)
ON liga-se a um dos SNs que conhece (aps
... se ter ligado, actualiza lista de SNs)
Pesquisa:
ON contacta o seu SN
SNs propagam pedidos entre si
Transferncia de ficheiros:
Directamente entre ONs
Nota: Skype tem aproximao semelhante
5
Modelo de interaco Modelo de interaco (1)
Tipo da interaco Tipo da interaco

Activa
Contedo da interaco Processo solicita execuo de operao noutro processo
Exemplo: protocolos tipo pedido/resposta
Coordenao entre interlocutores Reactiva
Sncrona Evento no sistema desencadeia aco num processo
Assncrona Exemplo: modelo publicar/subscrever
Indirecta
Processos comunicam atravs de um espao partilhado
Exemplo: espaos partilhados
Modelo reactivo Modelo de interaco indirecta (ex.: memria

(publish/subscribe event-based system) partilhada distribuda)
Message bus
Objectos partilhados
Processos comunicam e coordenam-se atravs dum espao de

No modelo publish/subscribe, um processo (subscritor/consumidor)
subscreve o interesse num conjunto de eventos junto de outro processo memria partilhada distribuda
(publisher/produtor) que os fornece Processos escrevem e lem dados no espao de memria partilhada
Exemplos:
O publisher envia os eventos de um dado tipo para todos os processos que
Sem suporte de hardware, memria partilhada implementada como
o subscreveram
servio distribudo
Um exemplo particular: invocation return calback Espao de tuplos operaes de sincronizao (leitura/escrita
bloqueantes) e.g. JavaSpaces
Base de dados
Modelo de interaco (2) Contedo da interaco: dados
Contedo da interaco Processos trocam dados

Informao/dados Pedido (operao a invocar + parmetros + inf. utilizador + ...)
Resposta (resultado de operao + ...)
Cdigo
Evento (num sistema de eventos)
Propriedades
Parceiros devem conhecer formato das mensagens (dados)
Parceiros devem saber processar mensagens (operaes)
6
Contedo da interaco: cdigo mvel Coordenao
a) client request results in the downloading of applet code
Sistemas sncronos
Baseiam-se em limites definidos quanto s latncias:
Client Web
server Tempo de execuo de cada aco
Applet code
Tempo para transferncia das mensagens
b) client interacts with the applet Podem assumir nas interaces que os interlocutores se encontram no
tempo
Web
Client Applet server Sistemas assncronos
No assumem limites de tempo para as aces ou para a
A execuo do cdigo no cliente pode: comunicao
Melhorar o desempenho Nas interaces podemos querer que o sistema continue em
Ser usado para implementar funcionalidade adicional funcionamento at que a comunicao se conclua
Transparncia na interaco com o webserver
Necessrio acordar como transferir e executar

Os SD no realmente assncronos, mas podemos desenhar solues
Segurana
Necessrio proteger o cliente do cdigo executado
assumindo que so sncronos
Modelo de falhas Tipos de falhas
Num sistema distribudo, tanto os processos (e computadores) Uma falha por omisso d-se quando um processo ou um canal de
como os canais de comunicao podem falhar comunicao falha a execuo de uma aco que devia executar
Exemplo: uma mensagem que devia chegar no chegou, processo falha
No possvel conceber componentes sem falhas, apenas se pode
(crash)
diminuir a probabilidade de as mesmas ocorrerem
Uma falha temporal d-se quando um evento que se devia produzir num
O modelo de falhas consiste na definio rigorosa de quais determinado perodo de tempo ocorreu mais tarde
os erros ou avarias, assim como das falhas que podem ter
lugar nas diferentes componentes. O modelo de falhas abrange Uma falha arbitrria ou bizantina d-se quando se produziu algo no
ainda a indicao rigorosa do comportamento global do previsto
Exemplo: chegou uma mensagem corrompida, um atacante produziu uma
sistema na presena dos diferentes tipos de falhas.
mensagem no esperada.
Para lidar com estas falhas necessrio garantir que elas no levam a que
outros componentes passem a estados incorrectos
Durao das falhas Algumas definies
Permanentes: mantm-se enquanto no forem reparadas (ex: Availability disponibilidade. Mede a fraco de tempo em que um
computador avaria) servio est a operar correctamente, isto , de acordo com a sua
Mais fceis de detectar especificao.
Mais difceis de reparar Para um sistema ser altamente disponvel (highly available) deve
combinar um reduzido nmero de falhas com um curto perodo de
Temporrias: ocorrem durante um intervalo de tempo limitado, recuperao das falhas (durante o qual no est disponvel).
geralmente por influncia externa
Mais difceis de reproduzir, detectar Reliability - fiabilidade. Mede o tempo desde um instante inicial at
Mais fceis de reparar primeira falha, i.e., o tempo que um sistema funciona
correctamente sem falhas.
Erros transientes: ocorrem instantaneamente, ficam reparados Um sistema que falha com grande frequncia e recupere rapidamente
imediatamente aps terem ocorrido (ex.: perda de mensagem) tem baixa fiabilidade, mas alta disponibilidade.
7
Classificao dos sistemas quanto disponibilidade Mais definies
Classe Disponibilidade Indisponibilidade Exemplos Timeliness - adequao temporal ou pontualidade. Em sistemas de

(por ano mximo) tempo real a garantia de que o sistema capaz de obedecer a
1 90,0% 36d 12h Personal clients, experimental constrangimentos temporais, isto , a capacidade que o sistema
systems tem de garantir limites para o tempo que as diferentes aces
2 99,0% 87h 36min entry-level business systems
levam a executar.
3 99,9% 8h 46min top Internet Service Providers,

mainstream business systems
4 99,99% 52min 33s high-end business systems,
data centers
5 99,999% 5min 15s carrier-grade telephony; health
(alta disponibilidade) systems; banking
6 99,9999% 31,5 seg military defense systems
Falhas temporais Algumas definies
As falhas temporais so difceis ou impossveis de mascarar. Fault tolerance - tolerncia a falhas. Propriedade de um sistema
Normalmente apenas os sistemas de tempo real se preocupam com distribudo que lhe permite recuperar da existncia de falhas sem
este tipo de falha. introduzir comportamentos incorrectos.
Um sistema deste tipo pode mascarar as falhas e continuar a operar,
Mas o desempenho do sistema pode ser inadequado ou parar e voltar a operar mais tarde, de forma coerente, aps
reparao da falha.
Classe de falhas Afecta Descrio
Relgio Processo O relgio do processo tem um desvio superior ao

permitido em relao ao tempo real
Desempenho Processo O processo leva mais tempo do que o estipulado a
executar uma operao
Desempenho Canal A mensagem levou mais tempo do que o previsto
Mascarar falhas de componentes Modelo de segurana
Para compensar os problemas levantados pelas falhas usam-se tcnicas A informao gerida por um sistema distribudo tem valor para os
para as mascarar. Desta forma possvel confinar os seus efeitos sobre o utilizadores
sistema.
Muitas vezes recorrendo a redundancia O modelo de segurana consiste em definir quais as ameaas das
quais um sistema se consegue defender
As falhas de omisso podem ser mascaradas por replicao ou repetio
Exemplo: se uma mensagem no chegou dentro de um certo perodo o que
se detecta por um timeout ento pode-se emiti-la novamente. Outra hiptese
duplicar o canal, enviar mais do que uma cpia em paralelo e filtrar as
A segurana de um sistema distribudo pode ser obtida:
mensagens duplicadas.
Protegendo os processos e os canais usados para a interaco entre
As falhas arbitrrias podem ser difceis de mascarar. Pode-se tentar processos;
transform-las em falhas por omisso Protegendo os objectos (dados) geridos pelos processos contra
Exemplo: um CRC numa mensagem permite transformar uma falha bizantina acessos no autorizados.
do canal numa falha por omisso
O mesmo tipo de tcnicas usam-se muitas vezes nos componentes

hardware do tipo: discos, memrias, etc... mesmo nos sistemas
centralizados.
8
Definio Principais, objectos, controlo de acesso e
canais
Access rights
Num sistema existem entidades que do ponto de vista da Object
segurana tm identidade prpria, direitos e deveres essas invocation
entidades podem ser utilizadores, processos, etc. Utiliza-se o termo
principal para as designar. Client
result Server
Em Ingls, no contexto legal, um principal algum que est a ser
julgado pelos seus actos.
Principal (user) Network Principal (server)
A segurana num sistema distribudo passa por:

Autenticar os principais
Verificar direitos de acesso aos recursos controlo de acessos
Utilizar canais seguros
Existem tcnicas criptogrficas (com

Ameaas bsicas aos canais de comunicao (e Canais seguros partilha de segredos) que podem ser
consequentemente aos processos) usadas na autenticao de parceiros e
cifra de informao:
Permitem implementar um canal
Copy ofm
PrincipalA seguro PrincipalB
The enemy
m
Processo P Secure channel Processo Q
Processp m Processq
Communication channel
Num canal seguro os interlocutores (A e B) esto autenticados

Para modelar ameaas de segurana, assume-se que o inimigo tem
grande capacidade e pode: O inimigo no pode copiar, alterar ou introduzir mensagens
Enviar mensagens para qualquer processo O inimigo no pode fazer replaying de mensagens
Forjar endereo das mensagens, fazendo-se passar por outro processo
Ler, copiar, remover e reenviar mensagens que passam no canal O inimigo no pode reordenar as mensagens
Impedir interaco, repetir interaco, etc.
Outras ameaas Para saber mais

Distributed Systems Concepts and Design,
Cdigo mvel: problemas de segurana para os processos que Addison-Wesley, 4th Edition, 2005
recebem e devem executar cdigo mvel
Captulo 2. (peer-to-peer no cap. 10)
Denial of service: ataque em que o inimigo interfere (impede)
actividade dos utilizadores autorizados
Outras . . .
9
Nota prvia
A estrutura da apresentao semelhante e utiliza algumas das figuras

do livro de base do curso
Sistemas Distribudos I Captulo 4 (recomenda-se cap. 3 como reviso de RC)
Captulo 3 - Comunicao em
Sistemas Distribudos Parte 1
Comunicao Ponto a Ponto
Organizao do captulo Comunicao num sistema distribudos
Nveis dos sistemas de comunicao
Heterogeneidade e representao dos dados
Formas de comunicao ao nvel do middleware e sua caracterizao Applications, services
Sistemas de Middleware
comunicao
middleware Protocols
Data representation
Sistemas de Operating system

Platform
comunicao de base
Computer and network hardware
Comunicao no nvel middleware Sistemas de comunicao simples
Modelos de comunicao simples: Os sistemas de operao suportam a comunicao de dados entre os diferentes
Comunicao por streams (fluxos) computadores envolvidos num sistema distribudo
1 ou N destinatrios; Interfaces geralmente de baixo nvel
Uni-direccional ou bi-direccional. Exemplo: Protocolo mais popular - TPC/IP
Oferece os seguintes protocolos de comunicao base:
Comunicao por mensagens.
TCP streams
1 ou N destinatrios; Dados transmitidos como fluxo contnuo.
Fiabilidade no envio de mensagens ou no; Dados chegam de forma fivel a menos que o stream seja quebrado.
Diferentes garantias de ordenao na propagao das mensagens. UDP datagrama
Comunicao por mensagens.
Mensagens podem-se perder, duplicar e chegar fora de ordem.
Modelo de comunicao baseada no paradigma pedido / resposta. IP multicast

Comunicao por mensagens com mltiplos receptores.
Invocao de mtodos/procedimentos remotos (RMI / RPC) Semntica semelhante ao UDP.
Modelo de comunicao baseada no paradigma do cdigo mvel
1
Exemplo: protocolos tipo pedido/resposta Heterogeneidade na representao dos dados
Diferentes arquitecturas (processadores), sistemas e linguagens podem

ter:
Client Server
diferentes representaes de nmeros reais
diferente ordem na representao de inteiros (big-endian, little-endian)
Request diferentes representaes de caracteres (ASCII, Unicode, EBCDIC)
doOperation
message getRequest diferentes definies do que um inteiro (2, 4, 8 bytes?), real
(wait) execute
Reply Problema: num sistema distribudo, como garantir que dois processos a
message sendReply funcionar em diferentes arquitecturas, sistemas ou linguagens
(continuation)
conseguem trocar dados?
Representaes dos dados tipos primitivos Aproximaes codificao dos dados
Diferentes sistemas representam os tipos primitivos de formas diferentes Utilizao de formato intermdio independente (network standard representation)
Inteiros armazenados por ordem diferente em memria Emissor converte da representao nativa para a representao da rede
Diferentes representaes para nmeros reais O receptor converte da representao da rede para a representao standard
Caracteres com diferentes codificaes Utilizao do formato do emissor (receiver makes it right)
Simples transmisso dos valores armazenados pode levar a resultados Emissor envia usando a sua representao interna e indicando qual ela
Receptor, ao receber, faz a converso para a sua representao
errados
Utilizao do formato do receptor (sender makes it right)
MSB LSB
contedo da palavra
big-endian .. 0 0 0 1 .. =1
Propriedades:
n n+1 n+2 n+3
Desempenho ?
rep. intermdia tem pior desempenho - exige duas transformaes
LSB MSB
contedo da palavra Complexidade (nmero de transformaes a definir) ?
little-endian = 1 x 256 x 256 x 256=16777216 rep. intermdia exige apenas que em cada plataforma se saiba converter de/para formato
.. 0 0 0 1 ..
intermdio
n n+1 n+2 n+3
Representaes dos dados tipos complexos Representao de dados e marshalling
Aplicaes manipulam estruturas de dados complexas Muitos dos protocolos de rede usam a codificao dos dados atravs de
Ex.: representadas por grafos de objectos cdigos ASCII (SMTP, FTP, ). Esta tambm a opo quando se usa
XML.
Mensagens so sequncias de bytes
Alguns sistemas fornecem suporte para codificar tipos complexos e
O que necessrio fazer para propagar estrutura de dados complexa? (hierarquias de) objectos de forma automtica. Exemplos: RPC, Corba,
necessrio convert-la numa sequncia de bytes RMI.
Por exemplo, para um objecto necessrio: Estas alternativas sero estudadas em detalhe no prximo captulo
Converter as variveis internas, incluindo outros objectos
Necessrio lidar com ciclos nas referncias
Marshalling processo de codificar do formato interno para o formato rede Marshalling = arrange in proper order
Unmarshalling processo de descodificar do formato rede para o formato interno
2
Exemplo: CDR - CORBA Common Data Representation Exemplo: CDR - CORBA Common Data Representation
CDR primitive or simple data types CDR constructed data types
Tipo Wire size (bytes) Descrio Tipo de dados Representao
short 2 16 bits signed binary integer

sequence length (unsigned long) followed by elements in order
unsigned short 2 16 bits unsigned binary integer
long 4 32 bits signed binary integer string length (unsigned long) followed by characters in order
unsigned long 4 32 bits unsignedbinary integer
float 4 single precision floating point number array array elements in order (no length specified because it is fixed)
double 8 double precision floating point number
Boolean 1 boolean value (0 or 1) struct in order of declaration of components
char 1 ASCII char enumerated unsigned long
octet 1 any 8 bits
any any type union type tag followed by the selected number
Inteiros so big-endian ou little-endian de acordo com a ordem do emissor (enviada em

cada mensagem).
Floats so IEEE, tambm big-endian ou little-endian
Facetas da comunicao ponto-a-ponto Comunicao por mensagens
Forma da interaco Emissor e receptor comunicam trocando mensagens

Streams Cada mensagem tem um limite (e dimenso) bem-definida.
Mensagens
Ordenao das mensagens

Sem garantias de ordem
Nmero de destinatrios Sistema no garante que as mensagens so entregues pela ordem que
Ponto-a-ponto foram enviadas. Exemplo: UDP
Multi-ponto (estudado mais tarde)
Direco de interaco Entrega pela mesma ordem da emisso FIFO (first in first out)
Uni-direccional Sistema garante que as mensagens dum emissor so entregues pela mesma
Bi-direccional ordem que foram enviadas. (Como implementar em TCP/UDP?)
Tipo de sincronizao
Comunicao sncrona P Q
Comunicao assncrona
send m receive
Persistncia
Comunicao persistente
Comunicao voltil
Fiabilidade (modelo de falhas)

Outgoing message buffer Incoming message buffer
Streams Nmero de destinatrios
Emissor e receptor estabelecem um fluxo contnuo de dados Comunicao ponto-a-ponto

Ordem dos dados enviados mantida;
Comunicao entre um emissor e um receptor
Dimenso (fronteira) dos dados no mantida.
Comunicao multi-ponto
Algumas variantes
Um stream pode ser composto por vrios substreams (e.g. vdeo+audio) Comunicao entre um emissor e um conjunto de receptores (multicast)
Problemas de sincronizao dos substreams (detalhado na segunda parte deste captulo)
Qualidade de servio
Condies temporais para propagao entre extremos (sncrono)
Reserva de largura de banda (ex: RSVP)
P Q
write m read
Outgoing message buffer Incoming message buffer
3
Direco de interaco Sincronizao
Comunicao uni-direccional: Comunicao assncrona:

Comunicao apenas num sentido: emissor->receptor o emissor s fica bloqueado at o seu pedido de envio ser tomado pelo
sistema de comunicao
Comunicao bi-direccional: o receptor fica bloqueado at ser possvel receber dados
Comunicao nos dois sentidos Em geral, o sistema de comunicao do receptor armazena (algumas) mensagens
caso no exista nenhum receptor bloqueado no momento da sua recepo.
Assim, funciona como um buffer entre o emissor e o receptor
Possvel variante: o receptor no fica bloqueado e devolve erro ou a recepo
efectuada em background
Comunicao sncrona:
o emissor fica bloqueado at:
o receptor receber os dados comunicao sncrona unidireccional
receber a resposta do receptor comunicao pedido / resposta ou cliente /
servidor
o receptor fica bloqueado at ser possvel consumir dados
Persistncia Fiabilidade
Comunicao voltil: mensagens apenas so encaminhadas se o receptor Comunicao fivel: o sistema garante a entrega das mensagens em
existir e estiver a executar, caso contrrio so destrudas. caso de falha temporria. Como implementar?
Exemplo: ???
Comunicao no-fivel: em caso de falha, as mensagens podem-se
perder
No se aplica a sistemas de comunicao baseados em streams
Comunicao persistente: mensagens so guardadas pelo sistema de
comunicao at serem consumidas pelos destinatrios, que podem no
estar a executar. Mensagens so guardadas num receptculo
independente do receptor mailbox, canal, porta persistente, etc.
Exemplo: ???
Sistemas de comunicao middleware Sistemas de comunicao
Podem oferecer diferentes modelos paradigmas Alguns exemplos

Simples por mensagens Streams assncronos (TCP)
Simples por streams
Pedido/resposta Comunicao assncrona por mensagens (UDP)
Baseado no paradigma de cdigo mvel Comunicao sncrona unidireccional
Comunicao sncrona pedido / resposta
Podem fornecer diferentes propriedades relativas s facetas abordadas
Forma da interaco
Comunicao persistente sncrona
Nmero de destinatrios Comunicao persistente assncrona
Direco de interaco Message-Oriented Middleware (MOM)
Tipo de sincronizao
Persistncia
Fiabilidade (modelo de falhas)
4
Comunicao sncrona unidireccional Comunicao sncrona unidireccional
Concorrncia:
Limita a concorrncia, porque o emissor se bloqueia at o receptor receber a
emissor receptor mensagem enviada.
send ( ) Sincronizao:
Aps o envio o emissor sabe que o receptor acabou de receber a mensagem;
Aps a recepo, o receptor sabe que o emissor esteve bloqueado at esse momento.
receive ( )
tempo
Ordenao:
processo bloqueado Em geral, garante a ordem das mensagens do mesmo emissor.
processo a executar Modelo de falhas:

Em caso de sucesso o emissor sabe que o receptor recebeu a mensagem.
Em caso de insucesso no se sabe exactamente o que se passou (problemas de rede
ou do receptor ?).
O emissor fica bloqueado espera de o receptor estar disposto a receber a
mensagem
Variaes: possvel o emissor s ficar bloqueado at a mensagem chegar ao
Implementao exige envio de mensagem com informao de recepo para o site do receptor mesmo que este no a consuma logo.
emissor
Comunicao sncrona pedido / resposta Comunicao sncrona pedido / resposta
emissor receptor o modo de comunicao caracterstico das arquitecturas cliente / servidor.

receive ( ) bloqueado Concorrncia:
Limita a concorrncia porque o emissor bloqueia-se espera da resposta do receptor.
a executar
send ( )
tempo Sincronizao:
O emissor sabe que a mensagem foi emitida, recebida e tratada.
process request ( )
O receptor sabe que o emissor esperou por ele at receber a resposta.
send ( )
Ordenao:
Se no houver falhas, garante a ordem das mensagens do mesmo emissor.
Modelo de falhas:
Em caso de sucesso o emissor sabe que o receptor recebeu a mensagem, tratou-a e
O emissor fica bloqueado espera da resposta do receptor
respondeu. Em caso de insucesso no sabe exactamente o que se passou:
Problema de rede ou do receptor?
Problema antes ou depois de processar o pedido?
Comunicao persistente assncrona Comunicao persistente assncrona
Concorrncia:
Emissor nunca se bloqueia. Receptor pode bloquear-se na recepo de
emissor receptor
mensagens.
O sistema de comunicao guarda a Sincronizao:

send ( ) mensagem (pode ser, por exemplo,
uma mailbox) No existe sincronizao entre emissor e receptor.
tempo Ordenao:
Geralmente garante a ordem das mensagens do mesmo emissor.
bloqueado
receive ( ) Modelo de falhas:
a executar Emissor no tem garantia que mensagem foi armazenada. Se for
armazenada, em geral, o sistema garante que a mensagem guardada at o
receptor a consumir.
No existem garantias que algum receptor a consuma.
5
Message-Oriented Middleware (MOM) ou Message- Interaco emissor / receptor
Queuing systems
Os processos comunicam pela troca de mensagens usando um Primitivas:
emissor
subsistema intermdio que assegura a persistncia atravs de filas de a executar Put adiciona uma mensagem a uma
mensagens (queues) queue
Comunicao assncrona Get bloqueia at que a queue no
Suporta transferncia de mensagens que duram vrios minutos esteja vazia e remove a primeira
mensagem
Poll verificar se existem mensagens
na queue
Uma mensagem sempre endereada por um processo para uma queue Notify Instalar um handler para ser
e s pode ser consumida da queue por um outro processo / aplicao notificado se uma mensagem chegar
(uma queue pode, no entanto, ser partilhada por vrios processos /
aplicaes)
O emissor apenas tem garantias que a mensagem foi entregue na queue
receptor
a executar
Estrutura geral de um MOM
process
process
Application host
Application host Message router
Message
process
Queue Message router

Message router
Message router Application host

Receive / send queues
Mensagens podem ser propagadas para o destino atravs de filas intermdias

Algumas mquinas podem ter filas e actuar apenas como routers
Permite implementar funcionalidade adicional ex.: log para segurana ou tolerncia a falhas,
converso de formato de mensagens/gateway (message brokers)
Aplicaes: e-mail, workflow, processamento em batch, . . .
6
Nota prvia
A estrutura da apresentao semelhante e utiliza algumas das figuras

do livro de base do curso
Sistemas Distribudos Addison-Wesley, 4th Edition, 2005
LEI (1 ciclo) 2010/2011

Para saber mais:
Captulo 3 - Comunicao em Sistemas Distribudos seco 12.4 apenas parte relativa aos tipos de multicast (no entrar na
parte de implementao)
Parte 2 - Comunicao Multiponto SD 2 ciclo
Baseado nos slides de Nuno Preguia, SD 09/10
Comunicao em grupo Algumas definies
Um grupo um conjunto dinmico de communication end-points (portas, Comunicao ponto a ponto (ou unicast) [1x1] envio de uma
processos, servidores, etc.) que tratado pelo sistema como uma entidade nica mensagem de um nico emissor para um nico receptor
do ponto vista da comunicao
Operao multicast: envio de uma mensagem para todos os elementos do grupo,
usualmente de forma que a filiao (membership) do grupo transparente para o
emissor Formas de comunicao multi-ponto
Comunicao multicast ou em grupo [1xN] envio de uma mensagem de
um emissor para um grupo de receptores
Pode exigir que o emissor pertena ao grupo ou no
Forma de identificar o grupo
m
m
g1 g2
Comunicao broadcast ou por difuso [1xAll] envio de uma mensagem de
m
m
um emissor para todos as mquinas do sistema
p
Comunicao funcional ou anycasting [1x1 among N] envio de uma
m g4 mensagem de um emissor para um de um grupo de receptores
g3
A noo de grupo aparece a vrios nveis Caractersticas do multicast
Nvel fsico Multicasting pressupe:

Ex.: ethernet broadcasting e multicasting endereo / identificador nico do grupo
composio dinmica no necessariamente visvel
Nvel datalink e nvel rede a modificao da composio feita de forma independente dos emissores
Ex.: IP multicasting gesto, localizao, comunicao, etc. com ou dos membros do grupo
assegurada pelo suporte de materializao da comunicao multi-ponto
Sistema de operao [distribudos]
Ex.: grupos de processos, grupos de portas Interfaces
createGroup, destroyGroup, joinGroup, leaveGroup, send, receive
Plataformas midleware:
(disseminao de eventos) open, destroy, subscribe, unsubscribe, publish,
Ex.: Isis, Horus e Ensemble (Univ. Cornell), Consul (Univ. Arizona), Totem
receive (call-back)
(Univ. California at Santa Barbara), JGroups, Appia (FCUL)
Plataformas middleware publish / subscribe e de disseminao de

eventos
Ex. Java Message Service (JMS), iBUS, BEA MessageQ
1
Entrega das mensagens Caracterizao do multicast: fiabilidade
Diz-se que sistema de comunicao entrega Multicast no fivel (unreliable multicast) em caso de falha, no
uma mensagem quando a mensagem existem garantias sobre a entrega das mensagem aos vrios elementos
entregue aplicao do grupo
Aplicao e.g. IP multicast
O middleware pode reordenar as mensagens

recebidas localmente atrasando a entrega das Middleware
que j recebeu para garantir as propriedades
desejadas
OS
Para esse efeito mantm uma fila local de
mensagens recebidas e ainda no entregues
Network
Caracterizao do multicast: fiabilidade Caracterizao do multicast: fiabilidade
Multicast fivel (reliable multicast) - uma mensagem para o grupo Multicast fivel (reliable multicast) - uma mensagem para o grupo
enviada por um processo correcto (que no falhe) dever ser entregue enviada por um processo correcto (que no falhe) dever ser entregue
Agreement: Se um membro correcto entrega uma mensagem todos os Agreement: Se um membro correcto entrega uma mensagem todos os
membros correctos tambm a entregam membros correctos tambm a entregam
Ou ento ningum entrega Ou ento ningum entrega
Membros que falham podem ter entregue a mensagem ou no Membros que falham podem ter entregue a mensagem ou no
Implementao simples (e errada): o emissor emite para cada um dos Implementao simples (e errada): o emissor emite para cada um dos
elementos do grupo com base em acks+retransmisses elementos do grupo com base em acks+retransmisses
Porqu errada? Exemplo: Em caso de falha do emissor, necessrio que os elementos do grupo
propaguem as mensagens recebidas para os elementos que ainda no as
receberam
Uniform agreement: se algum processo que falha entrega a mensagem,

todos os processos correctos devem entregar a mensagem
Caracterizao do multicast: ordem Caracterizao do multicast: ordem
Sem ordem as mensagens podem ser entregues por diferentes ordens Ordem causal se m1 pode causar m2, m1 deve ser entregue sempre
em diferentes processos antes de m2
Se duas mensagens forem emitidas pelo mesmo processo, considera-se que
Ordem FIFO as mensagens de um processo so entregues pela ordem o envio da primeira mensagem pode causar o envio da segunda
de emisso em todos os processos Neste caso, a recepo da primeira deve acontecer antes da recepo da segunda
Se duas mensagens forem emitidas em processos diferentes, a primeira
Ordem total as mensagens m1, m2 so entregues por ordem total, se mensagem pode causar a segunda se for recebida antes do envio da
forem entregues pela mesma ordem em todos os processos segunda (ou transitivamente incluindo outras mensagens)
pi, receive(m1,pi) < receive(m2,pi) ou Se uma mensagem no pode causar a outra, qualquer ordem de entrega respeita
pi, receive(m1,pi) > receive(m2,pi) a ordem causal
NOTA: a ordem de entrega das mensagens de um mesmo emissor pode ser
diferente da ordem de emisso
Um sistema de multicast fivel no qual as mensagens so entregues por
ordem total chama-se sistema de multicast atmico NOTA: a noo de causalidade estende-se a qualquer tipo de comunicao
2
Ordens: exemplo Ordens: exemplo
p3 p1 p2 p4 p3 p1 p2 p4
m3
m1 m1
m2 m4
m2
m5
m1,m2: total, causal

m1,m3: sem ordem,
causal
m2,m3: sem ordem,
causal
grupo(p1,p2) m3,m4: sem ordem, no
causal grupo(p1,p2,p4)
m2,m5: total, no causal,
no FIFO
Caracterizao do multicast: vistas Facetas da comunicao multicast: resumo
Def: uma vista (view) o conjunto de elementos de um grupo num dado Fiabilidade
momento. Multicast fivel
Nos sistemas de comunicao em grupo fiveis, a mudana de vista Multicast no-fivel
efectuada atravs do envio de uma mensagem multicast
Ordenao das mensagen
Sincronia virtual (virtual synchrony) um sistema de multicast fivel Sem ordem
implementa sincronia virtual se: Ordem FIFO
as mudanas de vista so entregues em todos os processos pela mesma Ordem total
ordem Ordem casual
o conjunto de mensagens entregues entre a entrega de cada duas vistas
consecutivas idntico para todos os processos que observam as duas vistas Relativamente s vistas
Sincronia virtual
Para saber mais
G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems

Concepts and Design, Addison-Wesley, 4th Edition, 2005
captulo 4 : partes sobre heterogeneidade e protocolos de invocao remota
sero abordados no prximo captulo
seco 12.4 apenas parte relativa aos tipos de multicast (no entrar na
parte de implementao)
3
Nota prvia
A estrutura da apresentao semelhante e utiliza algumas das figuras do livro

de base do curso
LEI (1 ciclo) 2010/2011 Para saber mais:

RMI/RPCs - captulo 5.
Representao de dados e protocolos - captulo 4.
Captulo 4 Web services captulo 19.1-19.4
Corba captulo 20 (interessante para quem queira saber mais).
Invocao de procedimentos/mtodos remotos
Organizao do captulo Invocao de procedimentos remotos: motivao
Invocao remota de procedimentos/objectos possvel estruturar uma aplicao distribuda usando como base as
Modelo interaces atravs da troca de mensagens entre processos. Os
Definio de interfaces problemas so:
Mtodos de passagem de parmetros (representao de dados) complicado e cheio de detalhes no relevantes
Mecanismos de ligao (binding) os programas ficam estruturados em funo dos protocolos (trocas de
Semntica na presena de falhas mensagens)
os servidores ficam estruturados em funo da lista de mensagens que
Concorrncia no servidor
sabem processar
Exemplos
Muitas linhas de cdigo so repetitivas, no contm nenhum significado
aplicacional especfico e referem-se ao processamento das comunicaes:
criao de communication end points e sua associao aos processos
criao, preenchimento e interpretao das mensagens
seleco do cdigo a executar consoante o tipo da mensagem recebida
gesto de temporizadores/tratamento das falhas
Segurana?
No se podero automatizar as interaces cliente/servidor?

Invocao remota de procedimentos Invocao de procedimentos (locais)
Num programa definido numa linguagem imperativa, definem-se Procedimento que invoca
Procedimento invocado
funes/procedimentos para executar uma dada operao
Uma extenso natural num ambiente distribudo consiste em permitir a

Empilhar parmetros;
execuo de procedimentos noutra mquina: Chamada ou invocao Call subroutine
res = func( params)
remota de procedimentos Desempilhar parmetros
Baseada no modelo de interao pedido/resposta tempo

Ex. ONC/RPC, DCE Executar o procedimento
Web services: permitem efectuar invocao remota de procedimentos
usando mensagens (geralmente) representadas em XML e enviadas usando
Empilhar resultados;
HTTP Desempilhar
Return from subroutine
resultados
Web services permitem interaces mais complexas que simples pedido/resposta
res = func( params)
Se as funes/procedimentos estiverem definidos no mbito de um
objecto, chama-se invocao remota de mtodos
Ex.: Java RMI, CORBA e .NET Remoting a executar
1
Invocao de procedimentos remotos (RPCs) Invocao de procedimentos remotos (cont.)
cliente Servidor
Propriedades
Chamada de procedimento
Extenso natural do paradigma imperativo/procedimental a um ambiente
remoto: envio de distribudo
parmetros
res = serverFunc( p1) Chamada sncrona de funes modelo de comunicao ?
tempo res_type serverFunc( p1)

Esconde detalhes de comunicao (e tarefas repetitivas)
{
cliente bloqueado ... Construo, envio, recepo e tratamento das mensagens
... Tratamento bsico de erros (devem ser tratados ao nvel da aplicao)
return result
Heterogeneidade da representao dos dados
}
res = serverFunc( p1)
Retorno do procedimento
remoto: envio dos Simplifica disponibilizao de servios
a executar resultados Interface bem definida, facilmente documentvel e independente dos protocolos
de transporte
Necessita de um sistema de registo e procura de servios
Modelo
Servidor exporta interface com operaes que sabe executar
Cliente invoca operaes que so executadas remotamente e (normalmente) aguarda
pelo resultado
RPCs: como implementar? Como esconder os detalhes? RPCs: como implementar
Cliente Servidor
cliente Servidor
a executar
res = serverFunc( p1 ) resType serverFunc( T1 p1 ) {
...
return result
}
tempo
res_type serverFunc( p1)
{
cliente bloqueado ...
(1) Invocao:
...
return result
no cliente,
}
deve existir uma funo,
com o mesmo nome, responsvel por
enviar o pedido ao servidor, codificando
a operao numa mensagem enviada
atravs dum protocolo de comunicao
de base (ex.: TCP)
RPCs: como implementar? Como esconder os detalhes?

(1) Invocao: RPCs: como implementar
no cliente, deve existir uma funo,
com o mesmo nome, responsvel por
Cliente enviar o pedido ao Servidor
servidor, codificando
cliente Servidor
a operao numa mensagem enviada a executar
res = serverFunc( p1) res_type serverFunc( T1 p1) {
atravs dum protocolo
... de comunicao
de base (ex.: TCP)
return result
}
tempo
res_type serverFunc( T1 p1) res_type serverFunc( p1)
{
s = new Socket( host, port) cliente bloqueado ...
s.send( msg( serverFunc,[p1])) (2) Recepo do pedido: ...
return result
no servidor, deve existir um processo }
que aguarda a recepo de pedidos.
Para cada mensagem recebida, deve
descodificar o pedido e invocar a
operao respectiva
2
(2) Recepo do pedido:

Cliente Servidor
no servidor, deve existir um processo (3) Envio da resposta: cliente Servidor
a executar
res
que=aguarda
serverFunc( p1)
a recepo de pedidos. res_type serverFunc( T1 p1) {
...
no servidor, quando a execuo do
Para cada mensagem recebida, deve procedimento termina, os resultados
return result
descodificar o pedido e invocar a (ou apenas a informao de fim) devem
}
operao respectiva res = serverFunc( p1)
ser codificado e enviado para o cliente
tempo
res_type serverFunc( T1 p1) s = new ServerSocket res_type serverFunc( p1)
{
s = new Socket( host, port) forever cliente bloqueado ...
s.send( msg( serverFunc,[p1])) Socket c = s.accept(); ...
c.receive( msg( op, params)) return result
}
if( op = serverFunc)
res = serverFunc( params[0]);
else if( op = ...)
...

(3) Envio da resposta:
no servidor, quando
Cliente a execuo do Servidor
procedimento termina, os resultados cliente (4)Servidor
Recepo do pedido:
a executar
res = serverFunc( p1) res_type serverFunc( T1 p1) { no cliente, a mensagem de resposta do
(ou apenas a informao de fim) devem
... servidor deve ser descodificada e o
ser codificado e enviado para o cliente return result
programa do utilizador deve voltar a
}
res = serverFunc( p1) executar com o resultado da operao
tempo
res_type serverFunc( T1 p1) s = new ServerSocket res_type serverFunc( p1)
{
s = new Socket( host, port) forever cliente bloqueado ...
s.send( msg( serverFunc,[p1])) Socket c = s.accept(); ...
c.receive( msg( op, params)) return result
}
if( op = serverFunc) res = serverFunc( p1)
res = serverFunc( params[0]);
else if( op = ...)
...
c.send( msg(res))
c.close
RPCs: como implementar? Como esconder os detalhes? RPCs: como implementar? Como
Stub esconder
do clienteos
oudetalhes?
proxy do
(4) Recepo do pedido:
servidor
Cliente Servidor
no cliente, a mensagem de resposta do Cliente Servidor
res = serverFunc( p1) servidor deve ser
res_type descodificada
serverFunc( e o{
T1 p1) res = serverFunc( p1) (1) Invocao:
res_type serverFunc( T1 p1) {
programa do utilizador
... deve voltar a no cliente, deve ... existir uma funo,
executar com oreturn resultda operao
resultado com o mesmo return
nome, result
responsvel por
} enviar }o pedido ao servidor, codificando
a operao numa mensagem enviada
res_type serverFunc( T1 p1) s = new ServerSocket res_type serverFunc( T1 p1) atravss =
dumnewprotocolo de comunicao
ServerSocket
s = new Socket( host, port) forever s = new Socket( host, port) de base (ex.: TCP)
forever
s.send( msg( serverFunc,[p1])) Socket c = s.accept(); s.send( msg( serverFunc,[p1])) Socket c = s.accept();
s.receive( msg( result)) c.receive( msg( op, params)) s.receive( msg( result)) c.receive( msg( op, params))
s.close if( op = serverFunc) s.close (4) Recepo
if( op =do pedido:
serverFunc)
return result res = serverFunc( params[0]); return result no cliente, res
a mensagem
= serverFunc(de params[0]);
resposta do
else if( op = ...) servidor deve
else if(seropdescodificada
= ...) eo
... programa do ... utilizador deve voltar a
c.send( msg(res)) executar c.send( msg(res)) da operao
com o resultado
c.close Na prtica, sucessivas c.close
invocaes podem partilhar
o mesmo socket
3
RPCs: como implementar? Como esconder os detalhes? Automatizao do processo Stub/skeleton compilers
Stub ou skeleton do servidor
Cliente Servidor Nos sistemas de RPC/RMI pode existir uma ferramenta (stub compiler)
(2)=Recepo
res dop1)
serverFunc( pedido: res_type serverFunc( T1 p1) {
que gera automaticamente o cdigo que trata da parte de comunicao
no servidor, deve existir um processo ... Este cdigo gerado com base na interface do servidor
que aguarda a recepo de pedidos. return result
Para cada mensagem recebida, deve } Stub do cliente inclui funes do cliente com o mesmo nome que efectuam a
descodificar o pedido e invocar a comunicao com o servidor para efectuar a invocao remota
res_type
operaoserverFunc(
respectivaT1 p1) s = new ServerSocket Skeleton do servidor inclui cdigo de comunicao para esperar invocaes e
s = new Socket( host, port) forever execut-las, devolvendo o resultado
s.send( msg( serverFunc,[p1])) Socket c = s.accept();
(3)s.receive(
Envio da resposta:
msg( result)) c.receive( msg( op, params)) Stubs/skeletons incluem cdigo para codificar os parmetros e resultado
no servidor,
s.close quando a execuo do if( op = serverFunc)
return result
procedimento termina, o resultado (ou res = serverFunc( params[0]);
Nos sistemas mais modernos, por vezes, existem stubs genricos que podem
apenas a informao de fim) deve ser else if( op = ...)
... ser usados com todos os tipos (e.g. Java)
codificado e enviado para o cliente Algumas linguagens/sistemas incluem suporte para invocao remota, pelo
c.send( msg(res))
c.close que as comunicaes so tratadas pelo runtime de suporte (e.g. .NET
remoting)
Aspectos a considerar num sistema de RPC/RMI RPC/RMI Interface Definition Languages (IDL)
Linguagem de definio de interfaces (IDL - [Network] Interface IDLs so linguagens que permitem definir interfaces de servidores/objectos
Definition Language) remotos, especificando:
Tipos e constantes
Modelo de passagem de parmetros, resultados e excepes Interface do servio - assinatura das funes/procedimentos
Formato de transmisso dos dados
Forma de localizao do servidor/objecto remoto (binding) Os IDLs so usados apenas para definir as interfaces, no o cdigo das operaes
Por vezes, esta distino difcil de fazer porque os IDLs esto integrados
Modelos de falhas e protocolos de interaco entre o cliente e o servidor com a linguagem
Em certos sistemas (e.g. .NET remoting), a interface pode no ser definida
Arquitectura do cliente e do servidor (multiprogramao) e outros autonomamente
aspectos de desempenho
Segurana (autenticao, controlo de acessos, )
IDLs aproximaes possveis Exemplo: DCE - Distributed Computing Environment

(tambm adoptado pela Microsoft no DCOM)
Usar sub-conjunto de uma linguagem j existente [ uuid(b20a1705-3c26-12d8-8ea3-04163a0dcefz) version (1.0)]

Ex.: Java RMI interface readwritefs { uuid permite identificar
const long FILE_NAME_SIZE = 16; univocamente o servidor
Definir linguagem especfica para especificar interfaces dos servidores/ const long BUFFER_SIZE = 1024;
objectos remotos typedef char FileName [ FILE_NAME_SIZE ];
typedef char Buffer [ BUFFER_SIZE ];
Ex.: DCE RPCs, WSDL, CORBA podem-se definir constantes e
Geralmente baseado numa linguagem existente void read ( [in] FileName filename,
tipos auxiliares
[in] long position,
Adio de tipos especiais (exemplo: SUN-RPC string, opaque) [in, out] long nbytes,
[out] Buffer buffer );
Necessidade de mapear o IDL e as linguagens de desenvolvimento dos
void write ( [in] FileName filename,
clientes/servidores [in] long position, parmetros podem ser de
[in, out] long nbytes, entrada, sada ou ambos
[in] Buffer buffer );
}
4
Interfaces definidas em Java
Exemplo de uma interface remota em CORBA IDL Interface remota em Java RMI standard
import java.rmi.*;
Interfaces remotas
public interface IContaBancaria
Podem-se definir tipos extends Remote { estendem Remote
auxiliares
public void depositar ( float quantia )
throws RemoteException;
Podem-se definir tipos
public void levantar ( float quantia)
para erros throws SaldoDescoberto, RemoteException;
Para cada atributo so definidas public float saldoActual ( )

operaes para aceder e mudar o valor throws RemoteException;
}
Mtodos devem lanar
public class ContaBancariaImp
extends UnicastRemoteObject RemoteException para tratar
implements IContaBancaria erros de comunicao
{
oneway: cliente no se bloqueia // Implementao
}
Servidor Cliente
public class ContaBancaria

extends UnicastRemoteObject IContaBancaria
implements IContaBancaria remAcc = (IContaBancaria)
{
Naming.lookup("//hostname/ContaBancaria");
protected ContaBancaria() throws RemoteException {
super();
}
remAcc.depositar( 10000000.00 );
public void depositar ( float quantia ) throws RemoteException {
. . . Etc . . . ...
}
...
ContaBancaria myAcc = new ContaBancaria();
Naming.rebind("/ContaBancaria", myAcc );
Interface definida em C# para .NET Remoting Interface definida em C# para .NET Remoting
Interface definida em C#
using System; comum using System;
namespace IRemoting namespace IRemoting public class ContaBancaria:
{ { System.MarshalByRefObject,
public interface IContaBancaria public interface IContaBancaria IContaBancaria
{ { {
double SaldoActual { get; } Permite definir atributos acessveis double SaldoActual { get; } // implementao . . .
por operaes associadas (get/set) }
void Depositar( float quantia ); void Depositar( float quantia );
void Levantar( float quantia ); void Levantar( float quantia ); Um objecto remotamente acessvel
} } deve estender MarshalByRefObject
} }
No .NET Remoting no
necessrio definir a interface
como remota esta pode ser
inferida a partir da definio do
servidor
5
WSDL IDL para web services WSDL - exemplo
Definio da interface em XML <?xml version="1.0" encoding="UTF-8"?>

<definitions name="HelloService"
WSDL permite definir a interface do servio, indicando quais as mensagens targetNamespace="http://www.ecerami.com/wsdl/HelloService.wsdl"
trocadas na interaco xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
WSDL permite tambm definir a forma de representao dos dados e a xmlns:tns="http://www.ecerami.com/wsdl/HelloService.wsdl"
forma de aceder ao servio xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<message name="SayHelloRequest">
Especificao WSDL bastante verbosa normalmente criada a partir de <part name="firstName" type="xsd:string"/>
</message>
interface ou cdigo do servidor <message name="SayHelloResponse">
Ex. JAX-WS tem ferramentas para criar especificao a partir de interfaces Java <part name="greeting" type="xsd:string"/>
</message>
definitions <portType name="Hello_PortType">

<operation name="sayHello">
types message interface bindings services <input message="tns:SayHelloRequest"/>
<output message="tns:SayHelloResponse"/>
</operation>
</portType>
target namespace document style request-reply style how where

(exemplo do livro Web Services Essentials, OReilly, 2002.)
abstract concrete
WSDL - exemplo WSDL - exemplo
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>

<definitions name="HelloService" <definitions name="HelloService"
targetNamespace="http://www.ecerami.com/wsdl/HelloService.wsdl" targetNamespace="http://www.ecerami.com/wsdl/HelloService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.ecerami.com/wsdl/HelloService.wsdl" xmlns:tns="http://www.ecerami.com/wsdl/HelloService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<message name="SayHelloRequest"> <message name="SayHelloRequest">

<part name="firstName" type="xsd:string"/> <part name="firstName" type="xsd:string"/>
</message> </message>
<message name="SayHelloResponse"> <message name="SayHelloResponse">
<part name="greeting" type="xsd:string"/> <part name="greeting" type="xsd:string"/>
</message> </message>
<portType name="Hello_PortType"> <portType name="Hello_PortType">

<operation name="sayHello"> <operation name="sayHello">
<input message="tns:SayHelloRequest"/> <input message="tns:SayHelloRequest"/>
<output message="tns:SayHelloResponse"/> <output message="tns:SayHelloResponse"/>
</operation> </operation>
</portType> </portType>
WSDL - exemplo WSDL - exemplo

<binding name="Hello_Binding" type="tns:Hello_PortType"> <binding name="Hello_Binding" type="tns:Hello_PortType">
<soap:binding style="rpc" <soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/> transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="sayHello"> <operation name="sayHello">
<soap:operation soapAction="sayHello"/> <soap:operation soapAction="sayHello"/>
<input> <input>
<soap:body <soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:helloservice" namespace="urn:examples:helloservice"
use="encoded"/> use="encoded"/>
</input> </input>
<output> <output>
<soap:body <soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:helloservice" namespace="urn:examples:helloservice"
use="encoded"/> use="encoded"/>
</output> </output>
</operation> </operation>
</binding> </binding>
<service name="Hello_Service"> <service name="Hello_Service">

<documentation>WSDL File for HelloService</documentation> <documentation>WSDL File for HelloService</documentation>
<port binding="tns:Hello_Binding" name="Hello_Port"> <port binding="tns:Hello_Binding" name="Hello_Port">
<soap:address <soap:address
location="http://localhost:8080/soap/servlet/rpcrouter"/> location="http://localhost:8080/soap/servlet/rpcrouter"/>
</port> </port>
</service> </service>
</definitions> </definitions>
6
Mtodos de passagem de parmetros Mtodos de passagem de parmetros (cont.)
Independentemente dos tipos dos parmetros, os mesmos podem ser: Aproximao comum nos sistemas de RPC/RMI:
parmetros de entrada ( in ) : cpia no pedido Passagem por valor para tipos bsicos, arrays, estruturas e objectos no
parmetros de sada/resultado ( out ): cpia na resposta remotos
parmetros de entrada/sada ( in/out ): cpia no pedido e na resposta Apontadores/referncias para arrays, objectos, etc. so seguidas
Estado dos objectos copiado (ex: Java RMI)
Porque no passar tipos bsicos por referncia?
Passagem por referncia para objectos remotos

quando o tipo de um parmetro um objecto remoto, uma referncia para o
objecto transferida
Porque no passar objectos remotos por valor?
Mtodos de passagem de parmetros: exemplo Mtodos de passagem de parmetros: exemplo
SD1 RemObj SD1 RemObj

LocalObj LocalObj
str l r str l r
LocalObj l = ... LocalObj l = ...

char[] str = SD1; char[] str = SD1;
RemObj r = ... RemObj r = ... SD1 LocalObj
Server Server
LocalObj f( in LocalObj l, LocalObj f( in LocalObj l,
l = server.f( l, str,r); in char[] str,in RemObj r){ l = server.f( l, str,r); in char[] str,in RemObj r){
... str l r ...
} }
Mtodos de passagem de parmetros: exemplo Mtodos de passagem de parmetros: exemplo
LocalObj
SD1 RemObj SD1 RemObj
LocalObj LocalObj
str l r str l r
LocalObj l = ... LocalObj l = ...

char[] str = SD1; char[] str = SD1;
RemObj r = ... SD1 LocalObj RemObj r = ... SD1\0
SD1 LocalObj
LocalObj l
Server Server
LocalObj f( in LocalObj l, LocalObj f( in LocalObj l,
l = server.f( l, str,r); in char[] str,in RemObj r){ l = server.f( l, str,r); in char[] str,in RemObj r){
str l r ... str l r ...
} }
7
Aproximaes codificao dos dados Extensible markup language (XML)
Utilizao de formato intermdio independente (network standard representation) XML permite descrever estruturas de Possivel aproximao usando xml para Person:
Emissor converte da representao nativa para a representao da rede dados complexas
Tags usadas para descrever a estrutura <person id="123456789">
O receptor converte da representao da rede para a representao standard
dos dados
<name>Smith</name>
Utilizao do formato do emissor (receiver makes it right) Permite associar pares atributo/valor com

a estrutura lgica
<place>London</place>
Emissor envia usando a sua representao interna e indicando qual ela <year>1934</year>
Receptor, ao receber, faz a converso para a sua representao XML extensvel </person >
Novas tags definidas quando necessrio
Utilizao do formato do receptor (sender makes it right)
Num documento XML toda a informao
Possivel aproximao usando xml para invocar
textual um metodo:
Podem-se codificar valores binrios, por
<methodCall>
Propriedades: exemplo, em base64
<methodName>inc</methodName>
Desempenho ? No contexto dos sistemas de RPC/RMI, o <params>
rep. intermdia tem pior desempenho - exige duas transformaes XML pode ser usado para: <param>
Complexidade (nmero de transformaes a definir) ? Codificar parmetros em sistemas de RPC <value><i4>41</i4></value>
rep. intermdia exige apenas que em cada plataforma se saiba converter de/para formato Codificar invocaes (SOAP)
</param>
intermdio Etc.

</params>
</methodCall>
Exemplo anterior: Pedido soap/http (aprox.) Resposta (aprox.)
POST /HelloPort HTTP/1.1 HTTP/1.1 200 OK

Content-type: text/xml;charset="utf-8 Transfer-encoding: chunked
Soapaction: sayHello Content-type: text/xml;charset="utf-8
Accept: text/xml, multipart/related, text/html
User-Agent: JAX-WS RI 2.1.6 in JDK 6 <?xml version="1.0" ?><soap:Envelope xmlns:S="http://
Host: localhost:8080 schemas.xmlsoap.org/soap/envelope/">
Connection: keep-alive <soap:Body><ns2:sayHelloResponse xmlns:ns2=helloservice">
Content-Length: 187 <greeting>Hello World!</greeting></ns2:sayHelloResponse>
</soap:Body></soap:Envelope>
<?xml version="1.0" ?><soap:Envelope xmlns:S="http://
schemas.xmlsoap.org/soap/envelope/">
<soap:Body><ns2:sayHello xmlns:ns2=helloservice">
<firstName>World!</firstName></ns2:sayHello>
</soap:Body></soap:Envelope>
CDR - CORBA Common Data Representation CDR - CORBA Common Data Representation
CDR primitive or simple data types CDR constructed data types
Tipo Wire size (bytes) Descrio Tipo de dados Representao
short 2 16 bits signed binary integer

sequence length (unsigned long) followed by elements in order
unsigned short 2 16 bits unsigned binary integer
long 4 32 bits signed binary integer string length (unsigned long) followed by characters in order
unsigned long 4 32 bits unsignedbinary integer
float 4 single precision floating point number array array elements in order (no length specified because it is fixed)
double 8 double precision floating point number
Boolean 4 boolean value (0 or 1) struct in order of declaration of components
char 1 ASCII char enumerated unsigned long
octet 1 any 8 bits
any any type union type tag followed by the selected number
Inteiros so big-endian ou little-endian de acordo com a ordem do emissor (enviada em

cada mensagem).
Floats so IEEE, tambm big-endian ou little-endian
8
CORBA CDR wire message Java serialization (simplificado)
index in notes
on representation Serialized values Explanation
sequence of bytes 4 bytes struct Person {
5 length of string Person 8-byte version number class name, version number
03 string name;
47 "Smit" Smith string place; int year
java.lang.String java.lang.String number, type and name of
3 name
811 "h___" long year; place instance variables
1215 6 length of string }; 1934 5 Smith 6 London values of instance variables
1619 "Lond" London
20-23 "on__" {Smith, London,
1934 1934}
2427 unsigned long public class Person Assume-se que o processo de deserialization no tem
implements Serializable informao sobre os objectos serializados
{ Forma serializada inclui informao dos tipos
Dados com dimenso varivel so alinhados preenchendo com 0s posies no private String name;
usadas Serializao grava estado de um grafo de objectos
private String place; A cada objecto atribudo um handle. Permite escrever
No enviada informao sobre os tipos. Como funciona? private int year; apenas uma vez cada objecto, mesmo quando existem vrias
Assume-se que o emissor e o receptor sabem os tipos que esperam ... referncia para o mesmo no grafo de objectos.
So geradas funes para fazer o marshalling e o unmarshalling

}
Serializao de objectos Representaes dos dados: classificao
Permite codificar/descodificar grafos de objectos Contedo da representao

Detecta e preserva ciclos pois incorpora a identidade dos objectos no grafo Formato binrio Corba, Java
Adaptvel em cada classe (os mtodos responsveis podem ser redefinidos) Formato de texto XML, etc
Os objectos devem ser serializveis Integrao com linguagem

por omisso no so porqu? Independente Corba, XML
poderia abrir problemas de segurana. Exemplo? Integrado Java
Permitia acesso a campos private, por exemplo.
Informao de tipos
Os campos static e transient no so serializados
Includa Java, XML
Usa reflection permite obter informao sobre os tipos em runtime No includa Corba
Assim, no necessita de funes especiais de marshalling e unmarshalling
Referncias para objectos remotos Referncias para objectos remotos
Nos sistemas de RMI , em geral, possvel passar (referncias para) objectos remotos Nos sistemas de RMI , em geral, possvel passar (referncias para) objectos remotos
em parmetro (ou como resultado de uma operao) em parmetro (ou como resultado de uma operao)
Porqu time+object unique id?
Em Java RMI pode-se enviar uma referncia para um objecto remoto: Em Java RMI pode-se enviar uma referncia para representao
Com esta um objecto remoto:
seria fcil
Referncias nicas no tempo e no
Passando como parmetro/resultado uma referncia remota neste caso, uma cpia da Passando comoque
parmetro/resultado mudar
uma a localizao
referncia remota do objecto?
neste caso, uma cpia da
espao,
para garantir o acesso a
referncia remota enviada referncia remota enviada
um objecto que foi apagado d um No. Para tal, a referncia remota
Passando como parmetro/resultado o objecto remoto neste caso, uma referncia para o Passando como parmetro/resultado o no deve
objecto incluir
remoto directamente
neste caso, umaareferncia para o
erro e no resulta no acesso a outro

objecto remoto enviada (e no o prprio objecto) passagem por referncia localizao do objecto.
objecto objecto remoto enviada (e no o prprio objecto) passagem por referncia
Em CORBA e outros sistemas semelhantes, os objectos remotos so referenciados Em CORBA e outros sistemas semelhantes, os objectos remotos so referenciados
atravs de referncias para objectos (nicas no tempo e no espao) como por atravs de referncias para objectos (nicas no tempo e no espao) como por
exemplo a seguinte (no CORBA): exemplo a seguinte (no CORBA):
32 bits 32 bits 32 bits 32 bits 32 bits 32 bits 32 bits 32 bits
interface of interface of
Internet address port number time object unique id Internet address port number time object unique id
remote object remote object
9
Ligao do cliente ao servidor (binding) Como obter referncia para o servidor?
request Por configurao directa (p.e. URL)

Ex.: Web services, .NET remoting
client server
Servidor de nomes regista associao entre nome e referncia remota
Ex.: Java RMI, Corba, *RPC
reply
Servidor de nomes e directrio regista informao sobre servidores
Para poder invocar o servidor, o cliente tem de obter uma referncia para o
Ex. Universal Directory and Discovery Service UDDI (web services)
servidor
Alm de permitir obter servidor dado o nome, permite procurar servidor
Nos sistemas de RPC, referncia corresponde ao communication end-point do servidor
pelos seus atributos
endereo IP + porta + ... (nmero nico da interface)
Nos sistemas de RMI, referncia remota corresponde geralmente a um proxy com o
mesmo interface do servidor (que internamente inclui informao de localizao do
servidor) Cliente procura servidor usando multicast/broadcast
Como obter essa 1 referncia? Alguns sistemas de objectos distribudos usavam esta aproximao
10
Como obter referncia para o servidor? Por configurao directa
Por configurao directa (p.e. URL) No cdigo do cliente, para obter uma referncia para o servidor indica-se
Ex.: Web services, .NET remoting explicitamente a sua localizao
.NET remoting
Servidor de nomes regista associao entre nome e referncia remota ChannelServices.RegisterChannel(new TcpChannel());
HelloServer obj = (HelloServer)Activator.GetObject(
Ex.: Java RMI, Corba, *RPC
typeof(Examples.HelloServer),
"tcp://localhost:8085/SayHello");
Web services
Servidor de nomes e directrio regista informao sobre servidores
Ex. Universal Directory and Discovery Service UDDI (web services) NetServerImplWSService service = new NetServerImplWSService(
Alm de permitir obter servidor dado o nome, permite procurar servidor new java.net.URL(http://host/xpto));
pelos seus atributos Ao criar o cdigo da referncia remota a partir da descrio do servio, a
mesma pode incluir a localizao do servio (<service>)
Cliente procura servidor usando multicast/broadcast Web services

Alguns sistemas de objectos distribudos usavam esta aproximao
NetServerImplWSService service = new NetServerImplWSService();
Usar um servio (Binding, Naming or Trading) A interface da Registry Java RMI
void rebind (String name, Remote obj)

request (3) This method is used by a server to register the identifier of a remote object by name.
client server void bind (String name, Remote obj)
reply This method can alternatively be used by a server to register a remote object by
name, but if the name is already bound to a remote object reference an exception is
thrown.
lookup register void unbind (String name, Remote obj)

(2) (1)
This method removes a binding.
Remote lookup(String name)

name This method is used by clients to look up a remote object by name. A remote object
server reference is returned. The code (stub/proxy) of the remote reference may be
downloaded, if necessary. It encodes the protocol to be used.
Name reference String [] list()

This method returns an array of Strings containing the names bound in the registry.
Problemas quando se usa um servidor de nomes? Soluo pragmtica dos RPC e Java RMI
Como encontrar o name server ? Em cada mquina existe um RMI

Nome do objecto indica mquina em que est o name server server machine registry. O cliente tem de saber em
client machine
Name server descoberto por multicast/broadcast que mquina est o servio/objecto
remoto em que est interessado.
portmapper/rmiregistry
Em cada mquina, s pode estar
associado uma instncia de uma
O name server pode ser nico ? interface/classe a cada nome
Pode existir mais do que uma
O sistema CORBA define um servio de nomes em que o espao de nomes
instncia da mesma interface/classe
nico e global. A implementao depende do sistema. 2 associados a nomes diferentes
1
Problemas de segurana como evitar que haja servios / objectos client 3

Porque que esta soluo diminui
impostores ou que atacantes impeam o acesso ao servio? server os problemas de segurana?
1
Modelo de falhas e semntica da invocao remota (RPC/RMI
ou qualquer interaco do tipo pedido/resposta)
cliente
Servido
temp r
o Chamada de
procedimento
remoto: envio de
parmetros
res_type serverFunc
cliente ( p1)
a bloqueado {
executar ...
...
res = serverFunc( p1) return result
Retorno do
procedimento
}
remoto: envio dos
resultados
Admitindo que o canal no introduz falhas arbitrrias, podemos ter:

Canal: falhas de omisso e temporizao
Cliente e servidor: crash-failures e falhas de temporizao
Anomalias possveis durante uma invocao remota Transporte connection-less vs. connection-oriented
Anomalias a considerar: Motivaes para o uso do UDP:

a mensagem com o pedido pode perder-se Estabelecer uma conexo tem um peso que se pode revelar demasiado
a mensagem com a resposta pode perder-se pesado (para pedidos pontuais e de pequenas dimenses)
o servidor est muito lento e aparentemente no responde Resposta invocao remota funciona como ACK (no necessrio suportar
o servidor falha e no responde peso dos mecanismos de fiabilidade includos no TCP)
o servidor falha e recupera mais tarde (quando ?)
o cliente falha e recupera
Motivaes para o uso de TCP (ou HTTP):
...
Efectuam-se vrios pedidos ao mesmo servidor
No caso de usar UDP ser necessrio enviar um pedido/resposta em mais do
que uma mensagem
Algumas destas situaes podem ser facilmente detectveis, outras no. Dimenso dos parmetros/resultados significativa
Beneficia da fiabilidade e controlo de fluxo
Depende do tipo de transporte usado
Protocolo Connection-oriented Protocolo connection-less no fivel (e.g. UDP)
Hiptese: o cliente usa o protocolo TCP para contactar o servidor e Hiptese: o cliente usa o protocolo UDP para contactar o servidor e
enquanto no receber resposta a um pedido, ou no decidir abandonar enquanto no receber resposta a um pedido, ou no decidir abandonar
um pedido, no avana com outro pedido um pedido, no avana com outro pedido
Situao semelhante quando se usa protocolo HTTP
1) O cliente enviou uma s vez o pedido e recebeu a resposta

1) O cliente fez um pedido e recebeu a resposta: O cliente tem a certeza que o procedimento executou uma e uma s vez
O cliente tem a certeza que o procedimento executou (uma e uma s vez) (assumindo que no existe duplicao de pacotes)
2) O cliente fez o pedido e no recebeu resposta nenhuma at um certo 2) O cliente fez o pedido e no recebeu resposta nenhuma at um certo
timeout, ou recebeu uma notificao de que a conexo foi quebrada timeout
Que se passou ? No se sabe se a operao foi executada ou no. Que se passou ? No se sabe se a operao foi executada ou no.
Motivo? Falha na ligao (pedido ou resposta) ou crash no servidor? Motivo? Falha do pedido, da resposta ou crash no servidor?
2
Introduo de retransmisso Em caso de anomalia, aps retransmisso, o que se
passou?
Nas situaes em que o cliente no recebe resposta poder-se-ia Caso o cliente no receba resposta ao seu pedido aps uma ou mais
introduzir um mecanismo de retransmisso do pedido: retransmisses, e deseje abandonar, pode ter acontecido que:
A anomalia ocorreu antes de executar a operao em todas as retransmisses
No caso connection-oriented, se a conexo se quebrou, criando uma nova
conexo A anomalia ocorreu aps a execuo da operao em uma ou mais retransmisses
No caso connection-less, reenviando a mensagem Sabe-se que: a operao foi executada zero, uma ou mais vezes.
Caso o cliente receba resposta ao seu pedido aps uma ou mais retransmisses,
pode ter acontecido que:
Quantas vezes se retransmite? Na tentativa anterior, a anomalia ocorreu antes de executar a operao
Na tentativa anterior, a anomalia ocorreu aps a execuo da operao
Consequncias da retransmisso?
Sabe-se que: a operao foi executada uma vez ou mais vezes.
Filtragem de duplicados (no re-executar pedidos) Filtragem de duplicados (cont.)
Problema: como evitar que o mesmo pedido seja executado mais do que Problema: quando que o servidor pode remover a informao sobre
uma vez no servidor? resultados de pedidos antigos?
O cliente numera com um nmero de sequncia nico cada pedido que O servidor pode remover informao quando souber que j no vai ser
faz. Retransmite enquanto no receber resposta at um nmero limite de necessria:
vezes. Cliente pode informar o servidor que recebeu o resultado (ack)
Cliente pode iniciar um novo pedido (equivalente a j ter recebido resultado
O servidor quando recebe um pedido novo, executa a operao e guarda do anterior)
a resposta (cache).
Caso no inicie um novo pedido e o ack da resposta se perder, o servidor
Caso receba uma retransmisso devolve o resultado previamente pode anular a informao ao fim de um tempo alargado.
calculado (cached) pois a resposta deve ter-se perdido.
Para tolerar crashs e recuperaes do servidor, a cache com resultados

deve ser mantida em memria estvel
Problemas?
Nmeros nicos e de sequncia Semntica da invocao remota
Os sistemas de RPC / RMI necessitam de utilizar nmeros nicos no May be (talvez): mtodo pode ter sido executado uma vez ou nenhuma
reutilizveis ou nmeros de sequncia (inconfundveis num certo perodo) vez
para diversos efeitos usa-se quando no se esperam resultados; no tem garantias. O interesse
Nmeros nicos de servio / interfaces (verses) muito limitado.
Nmeros nicos de objectos (identificadores)
Nmeros nicos de invocaes
Nmeros nicos de incarnao dos clientes e servidores se necessrio Protocolo?
Implementado por protocolo de envio simples de mensagem (sem resposta
nem retransmisses)
Ideias para a gerao de nmeros nicos:
Concatenar identificador nico num dado contexto com um contador
Exemplo: Identificador nico num contexto de uma mquina:
pid + tempo
Exemplo: Identificador nico num contexto de um sistema distribudo:
IP (+tempo --- quando IP pode variar ou se quer garantir unicidade aps
recuperao de falha da mquina)
3
Semntica da invocao remota (cont.) Semntica da invocao remota (cont.)
At least once (uma ou mais vezes ou pelo menos uma vez): At most once (zero ou uma vez ou no mximo uma vez):
1. se cliente recebeu a resposta, o procedimento foi executado uma ou 1. Se cliente recebeu a resposta, o procedimento foi executado uma s vez
mais vezes 2. Se o cliente no recebeu a resposta, o procedimento foi executado zero
2. se o cliente no recebeu a resposta, o procedimento foi executado zero ou ou uma vez
mais vezes
Protocolo ?
Protocolo ? Protocolo sem re-emisses ou protocolo com re-emisses e filtragem de
Implementado por protocolo com re-emisses e sem filtragem de duplicados duplicados memorizando o pedido assim que o 1 recebido
ou com filtragem memorizando o pedido s aps a sua execuo
Semntica da invocao remota (cont.) Protocolos de invocao remota (resumo)
Exactly once (exactamente uma vez): Com transporte connection-oriented (TCP)

Request / Reply protocol ( RR ): semntica?
(Semntica das invocaes locais) Implementa facilmente a poltica no mximo uma vez. Como?
necessrio registar em memria estvel o estado do cliente e servidor
para:
Quando o cliente recupera de uma falha, deve retomar a execuo da invocao
Quando o servidor recupera de uma falha, deve recuperar o seu estado (incluindo Com transporte connectionless (UDP)
informao sobre as operaes executadas) Request protocol ( R ): semntica?
Implementa a semntica maybe
Nota: a indisponibilidade do servio durante a falha no mascarada Request / Reply protocol ( RR ): semntica?
Implementa facilmente semntica pelo menos uma vez. Como?
Protocolo ? Request / Reply / Acknowledge protocol ( RRA ): semntica?
Protocolo com retransmisso, filtragem de duplicados e manuteno do usado para melhorar RR no caso de de se estar a implementar a semntica no
mximo uma vez. Porqu?
estado em memria estvel
Nota: Podem existir operaes que deixem o servidor

Operaes idempotentes Operaes idempotentesno mesmo estado e no sejam idempotentes.
Exemplo ???
Exemplo: uma operao de criao de um ficheiro que
Em geral, a execuo repetida devido s retransmisses conduz a um estado Em geral, a execuo repetida devido
devolvascomo
retransmisses conduz
resultado um a umque
booleano estado
indique se o
errado do servidor. Nestes casos a semntica pelo menos uma vez errado do servidor. Nestes casos a semntica
ficheiro pelo
foi criado ou menos umajvez
no (caso
existisse).
inadequada. inadequada.
Uma operao idempotente se a sua execuo repetida no altera o efeito Uma operao idempotente se a sua execuo repetida no altera o efeito
produzido (deixando o servidor no mesmo estado ou num estado produzido (deixando o servidor no mesmo estado ou num estado
aplicacionalmente aceitvel como equivalente e produzindo o mesmo resultado). aplicacionalmente aceitvel como equivalente e produzindo o mesmo resultado).
Exemplos de operaes idempotentes: Exemplos de operaes idempotentes:

em geral todas as operaes que no mudam o estado (leitura) em geral todas as operaes que no mudam o estado (leitura)
reescrever os primeiros 512 bytes de um ficheiro se se ignorar o problema da reescrever os primeiros 512 bytes de um ficheiro se se ignorar o problema da
concorrncia de acessos ao ficheiro concorrncia de acessos ao ficheiro
Exemplos de operaes no idempotentes: Exemplos de operaes no idempotentes:

acrescentar 512 bytes a um ficheiro acrescentar 512 bytes a um ficheiro
transferir dinheiro entre contas transferir dinheiro entre contas
As operaes idempotentes podem ser usadas com base na semntica at least As operaes idempotentes podem ser invocadas usando uma semntica at least
once once sem consequncias
4
Que protocolos se usam? Semnticas geralmente adoptadas
Protocolos connection-oriented Java RMI

Levam a stubs com implementao mais simples At most once sobre TCP
Apropriados quando: Corba
Erros nas comunicaes podem ser elevados (ex.: redes de longa distncia) At most once geralmente sobre TCP, maybe
Cliente inter-actuando continuamente com um dado servidor
Parmetros de grande dimenso .NET Remoting
Tendncia geral para utilizao deste tipo de protocolo At most once sobre TCP, HTTP, pipes
Java RMI: TCP
Web Services
.NET Remoting: TCP e HTTP
At most once sobre HTTP (SMTP, etc.)
Web-services: HTTP
WS-Reliability: suporte para at least once, exactly-once
Protocolos connection-less
Usados quando se pretende optimizar as comunicaes num ambiente com poucos
erros nas comunicaes e mensagens de dimenso reduzida Outros Sistemas antigos
Usado em: DCE RPC permite utilizar as semnticas at-most once e at-least once a partir de directivas
ONC/RPC (exemplo de sistema que usa RPC: NFS) introduzidas na definio da interface. Esto disponveis implementaes sobre UDP e sobre TCP.
Sistemas de operao distribudos com suporte nativo (no ncleo) de protocolos de RPC ONC/RPC permite utilizar as semnticas maybe, at-most once e at least once quer sobre UDP
(Amoeba, Chorus, V-Kernel, ....) quer sobre TCP. O programador pode tambm manipular os valores dos timeouts e o nmero de
repeties.
Organizao dos servidores
Activao dos servidores

Servidor a executar continuamente
Servidor activado quando necessrio
Organizao interna
Sequencial vs. concorrente
Activao de objectos remotos Organizao dos servidores: activao
Motivao: num sistema pode haver um nmero muito elevado de objectos Quando necessrio activar um servidor (objecto remoto), pode-se criar:
remotos cujo estado se quer que persista durante tempo ilimitado, mas que no Um servidor para atender todos os clientes
esto em uso durante grande parte do tempo Aproximao mais comum
Soluo: activam-se os objectos remotos apenas quando necessrio

Um servidor para atender cada cliente
Quando um mtodo invocado ou quando uma referncia remota obtida
E.g. .NET remoting: servidor SingleCall
Activator: servidor responsvel por:
Manter informao sobre os objectos activveis
Activar os objectos remotos quando solicitado por um cliente
Manter informao sobre localizao dos objectos activados
Objecto remoto passivo (quando no activado)

Cdigo
Estado do objecto marshalled
Referncia remota mantm informao necessria para solicitar a activao do

objecto
5
Organizao dos servidores: threads Utilizao de threads num servidor
Client makes
Servidor sequencial: o servidor executa os pedidos de forma sequencial, requests to server
um de cada vez
Modelo simples e claro
Receipt & Input-output
Para alguns tipos de servios, esta aproximao pode ter um queuing
desempenho inadequado
Exemplos: servidores de bases de dados, de ficheiros, etc. Porqu? T1
Exemplo: servios que chamam outros servios em ambos os sentidos (AB Requests
e B A). Porqu? N threads
Client
Server
A ter em ateno:
Em geral, quando a execuo de uma operao remota pode ser longa Possveis problemas de concorrncia: necessidade de sincronizar execuo
interessante introduzir concorrncia no servidor. Porqu? dos vrios threads.
Distributed deadlock: quando um servidor A chama outro servidor B e o servidor B chama
o servidor A
Como que os threads se organizam e se relacionam com os pedidos?
Hipteses de relao invocaes / threads Hipteses de relao invocaes / threads
workers workers
I/O I/O remote I/O I/O remote

remote remote remote remote
objects objects
objects objects objects objects
a. Thread-per-request b. Thread-per-connection c. Thread-per-object a. Thread-per-request b. Thread-per-connection c. Thread-per-object
Thread-per-request: cada invocao executada por um thread Thread-per-request: cada invocao executada
Quais os problemas depor um threadentre os threads
concorrncia
nos vrios modelos?
Thread-per-connection: as invocaes de uma conexo so executadas todas Thread-per-connection: as invocaes de uma conexo so executadas todas
pelo mesmo thread pelo mesmo thread Nos modelos thread-per-request e thread-per-
connection podem existir vrios threads a aceder aos
Thread-per-object: as invocaes para um objecto so executadas todas pelo Thread-per-object: as invocaes
mesmos para um objecto so executadas todas pelo
dados.
mesmo thread mesmo thread
No modelo thread-per-object pode existir um
problema de deadlock distribudo se a execuo de
um mtodo puder levar invocao local de um
mtodo noutroMaterial
objectode suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 34
Gesto dos threads Exemplos
Nos sistemas que usam mltiplos threads comum: Tipo de invocao em RMI
Existir um thread responsvel por distribuir as invocaes e existir um Invocao esttica operao a invocar definida em tempo de compilao
conjunto de threads responsveis por executar as invocaes, sendo Ex: server.someOp( param1, param2 )
reutilizados em sucessivas invocaes Invocao dinmica operao a invocar pode ser definida em tempo de
Pools de threads execuo
Em cada momento, o sistema mantm informao sobre os threads que no Ex. server.invoke( objId, someOpId, params )
esto a processar nenhuma operao, os quais se encontram a dormir
Quando uma nova invocao recebida, a informao sobre a mesma passada
para um thread da pool, o qual fica responsvel por processar o pedido Outros modelos de RPC/RMI
No fim de processar o pedido, o thread volta pool RPCs/RMI assncronos neste caso, o servidor envia um ACK quando recebe
o pedido; o cliente prossegue assim que recebe o ACK. O Cliente pode, mais
tarde, aceder ao resultado (assincronamente)
E.g. Java Future: Future<ResultType> res = server.execOpAsync( someParams);
if( res.isDone() ) result = res.get();
RPCs/RMIs one-way neste caso, o cliente prossegue imediatamente a
seguir a enviar o pedido, no esperando por resposta
6
! Apresentao de Java RMI
A estrutura da apresentao semelhante e utiliza algumas figuras e

exemplos de um tutorial sobre Java RMI proferido por Jim Waldo no
USENIX COOTS98 The Fourth Conference on Object-Oriented

Technologies and Systems (COOTS98)", Santa F, New Mexico, USA, April
1998
Java RMI Relevncia da linguagem Java para o RMI
Ao assumir-se uma nica linguagem, portvel entre diferentes plataformas, Caractersticas particularmente relevantes do Java no contexto da
possvel explorar algumas vantagens impossveis noutros contextos, invocao remota:
nomeadamente:
Heterogeneidade:
Uma plataforma de distribuio homognea mesmo quando as mquinas e sistemas
Neutralidade em relao a diferentes arquitecturas hardware: o cdigo
so heterogneos
interpretado (byte Codes), atravs de JVMs (Java Virtual Machines). Todos
Um modelo de objectos nico e global
Um nico sistema de tipos (locais e remotos)
os tipos de dados so definidos rigorosamente.
Objectos em parmetro, passados de forma polimrfica
Acesso a servidores (eventualmente desconhecidos):
Carrega dinamicamente cdigo se necessrio Ligao dinmica do cdigo das classes: o cdigo s carregado
Baseia-se na segurana do sistema Java quando necessrio e tal operao realizada dinamicamente. A JVM que
carrega dinamicamente as classes, conhece a noo de interface e realiza
controlo de tipos em tempo de carregamento. O carregamento de cdigo
pode fazer-se remotamente atravs de URLs.
Carregamento de cdigo e segurana Os objectos remotos so objectos Java
No h apontadores e no possvel escrever cdigo que viole as interfaces das

classes. Se um programa (uma JVM) importar o cdigo de uma classe, o processo
de compilao e ligao dinmica de cdigo impede que um objecto aceda ao
cdigo de uma classe ou aos dados dos outros objectos.
O cdigo das classes a carregar dinamicamente pode ser assinado para

autenticao e possvel especificar os seus direitos de acesso (pode criar
sockets? Aceder a ficheiros? etc.. .)
Desta forma, possvel carregar dinamicamente cdigo com segurana. Por

exemplo, um cliente pode carregar dinamicamente um stub, ou um objecto pode
ser passado por valor, sendo copiado de uma JVM para outra. Se necessrio, o
cdigo da sua classe carregado dinamicamente pela JVM receptora do objecto.
7
Tipos dos argumentos e do valor de retorno Carregamento de classes
Os argumentos e o valor de retorno podem ser de qualquer tipo desde que seja RMI carrega o cdigo das classes se o mesmo no estiver disponvel
derivado de Serializable ou Externalizable (or RemoteObject, como o
UnicastRemoteObject) Isto aplica-se s classes do objecto remoto, do stub, do esqueleto, dos
parmetros e do valor de retorno dos mtodos
Os objectos do tipo Serializable e Externalizable so copiados atravs da
serializao de objectos O carregamento faz-se remotamente se necessrio
os stubs (referncias remotas) so serializveis Os URLs das classes ficam anotados nas referncias remotas para se poderem
d o efeito da passagem de um objecto por valor (duplicao do objecto) localizar as mesmas
Os objectos do tipo RemoteObject passados em parmetro so substitudos por As classes a carregar so sujeitas ao controlo do gestor de segurana instalado
stubs
o stub tem embebida a referncia remota (a serializao especial)
d o efeito da passagem por referncia
O cdigo das classes carregado a pedido
Java RMI interfaces e classes Exemplo1: polimorfismo no servidor
Objectivo: criar um servidor que possa executar clculos arbitrrios

Interfaces Classes
Como fazer?
O cliente envia o objecto capaz de realizar o clculo para o servidor

Remote RemoteObject
Podamos chamar a este objecto um agente (simples)
O servidor executa o clculo e retorna o objecto resultado, por cpia ou por

referncia
RemoteServer O sistema carrega dinamicamente no servidor o cdigo do objecto clculo
Activatable UnicastRemoteObject
Implements <servant class>

Extends
Interfaces O servidor de computao
import java.rmi.*
Task - define uma task arbitrria para ser executada remotamente
import java.rmi.server.*
public interface Task extends Serializable { public class ComputeServer extends UnicastRemoteObject implements Compute {
Object run () ; public ComputeServer () throws RemoteException { /* initializations*/ }
}
public Object runTask (Task t) throws RemoteException {
return t.run () ;
Compute - define o servio do servidor de computao }
public static void main (String [] args) {
// SecurityManager installation
import java.rmi.*; try {
ComputeServer cs = new ComputeServer () ;
public interface Compute extends Remote {
Naming.rebind ( ComputeServer, cs );
Object runTask ( Task t ) throws RemoteException;
} catch (Exception e) {
} System.out.println (Cant compute + e.getMessage() );
e.printStackTrace ();
}
}
}
8
Notas sobre a interface Compute O que o cliente tem que fazer
Cria a task a ser executada remotamente
Obtm uma referncia para o servio de computao remoto
Envia a task a calcular para o servidor de clculo
Obtm o objecto resultado
Imprime o resultado
Task que calcula Pi Task que calcula uma funo
public class Pi implements Task {

private int places; public class F implements Task {
private F args ....;
public Pi ( int places ) {
this.places = places; public F ( args .... ) {
} // initializes args
}
public Object run ( ) {
// compute Pi public Object run () {
return result ; // compute F
} return result ;
} }
}
O cliente Garbage-collection distribudo
Compute comp = (Compute ) Naming.Lookup

(//SuperProcessorHost/ComputeServer );
// create the tasks to be evaluated remotely

Pi pi = new Pi ( 100 );
F f = new F ( args... );
// make the remote caclculations
Object piResult = comp.runTask ( pi );

Object fResults = comp.runTask ( f );
// print results
9
Segurana do carregamento do cdigo Carregamento de cdigo no cliente
O RMI usa os mecanismos de segurana da linguagem Java
Qualquer cdigo a carregar tem de o ser atravs de um carregador de classes

(class loader)
Um gestor de segurana (security manager) tem de estar presente para que o

carregamento de cdigo seja possvel
As aplicaes podem fornecer o seu prprio gestor de segurana
A omisso de um gestor de segurana no abre buracos de proteco
Os objectos anotam o seu codebase, o que permite obter o cdigo das classes
remotamente sem configurao adicional.
Carregamento de cdigo no servidor Exemplo 2: polimorfismo no cliente
O servidor conter um objecto poltica de notas de despesa aceitveis

actualizado
O cliente tem uma interface atravs da qual so preenchidas as notas de despesa
Como permitir actualizao das polticas sem ter de criar um novo cliente e no
sobrecarrgando o servidor?
A poltica de aceitabilidade das mesmas ser carregada dinamicamente no cliente

para verificar se a nota de despesa aceitvel
Os clientes so actualizados dinamicamente conforme necessrio se a poltica de

notas de despesa mudar
O teste de aceitabilidade pode executar no cliente e o servidor no

sobrecarregado o que prefervel tambm para o utilizador
O servidor de notas de despesa A interface Policy
import java.rmi.* import java.io.Serializable ;
public interface ExpenseServer extends Remote public interface ExpPolicy extends Serializable
{
ExpPolicy getExpPolicy ( ) throws RemoteException;
{
void checkEntry ( ExpenseEntry entry )
void submit ( ExpenseList report ) throws InvalidExpenseException ;
throws RemoteException, InvalidReportException ; }
}
10
Notas sobre a soluo ExpPolicy e ExpenseReport
ExpenseEntry entry;
// start new expense report and show GUI to user

ExpPolicy currentPolicy = server.getPolicy();
ExpenseList report = new ExpenseList();
while ( notDone ) {
entry = GUI.getEntry () ;
try {
currentPolicy.checkEntry ( entry );
report.addEntry ( entry );
} catch (InvalidEntryException e) {
GUI.errorDisplay ( e.getReason() );
}
}
server.submit ( report );
Para saber mais
G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems -

RMI/RPCs - captulo 5.
Representao de dados e protocolos - captulo 4.
Web services captulo 19.1-19.4
Corba captulo 20 (interessante para quem queira saber mais).
11
Nota prvia
A apresentao utiliza algumas das figuras do livro de base do curso

Sistemas Distribudos
Para saber mais:
LEI (1 ciclo) 2010/2011 Web services captulo 19.1-19.4
REST: http://en.wikipedia.org/wiki/Representational_State_Transfer
GWT: http://code.google.com/webtoolkit/
Captulo 5
Web services e modelos alternativos de interaco
cliente/servidor na internet
Organizao do captulo Web Services
Web services SOAP Definio W3C:
Web services REST A Web service is a software system designed to support interoperable
machine-to-machine interaction over a network. It has an interface
Invocao remotas assncronas
described in a machine-processable format (specifically WSDL). Other
Ajax systems interact with the Web service in a manner prescribed by its
GWT description using SOAP messages, typically conveyed using HTTP with an
XML serialization in conjunction with other Web-related standards.
Web services: motivao Componentes dos web services
Garantir inter-operabilidade
Usar protocolos web (HTTP e HTTPS) para transporte
Tambm se pode usar SMTP !!! Applications

Usar URLs e URIs como referncias para servios remotos
Directory service
Security
Choreography

Tratar problemas de heterogeneidade dos dados usando XML para
representar os dados
Web Services
Service descriptions (in WSDL)

SOAP

URIs (URLs or URNs)

XML
HTTP, SMTP or other transport

1
Componentes bsicos UDDI
SOAP: protocolo de invocao Protocolo de ligao ou binding entre o cliente e o servidor

remota
Os fornecedores dos servios publicam a respectiva interface
O protocolo de inspeco permite verificar se uma dado servio existe

WSDL: linguagem de baseado na sua identificao
especificao de servios
O UDDI responde s questes
Onde que o Web service est localizado?
O UDDI permite encontrar o servio baseado na sua definio capability
UDDI: servio de registo lookup
Funciona como pginas brancas e pginas amarelas
Estruturas de dados UDDI SOAP
Protocolo para trocar mensagens XML

businessEntity

Inclui definio do formato das mensagens a trocar
businessServices

human readable
Inclui um mecanismo de ligao das mensagens SOAP com o protocolo de
businessServices

transporte usado: HTTP ou HTTPS (ou SMTP, )
information

businessServices
bindingTemplate
Inclui mecanismo para tratar falhas
about the publisher

human readable

bindingTemplate

information
URL

about a
bindingTemplate
tModel

family of services
information
tModel

about the

URL

interfaces

serviceinterfaces
service
tModel

key
URL

key
service descriptions

key

SOAP: mensagens SOAP: mensagens

<?xml version='1.0' encoding='UTF-8'?>
<soap:Envelope xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns:soap='http://
No SOAP toda a informao est includa no envelope da mensagem No SOAP toda a informao est includa no envelope da mensagem
schemas.xmlsoap.org/soap/envelope/' xmlns:soapenc='http://
O envelope inclui elementos de cabealho e de corpo schemas.xmlsoap.org/soap/encoding/' soap:encodingStyle='http://
O envelope inclui elementos de cabealho e de corpo
schemas.xmlsoap.org/soap/encoding/'>
<soap:Body>
<n:sayHello xmlns:n='urn:examples:helloservice'>
<firstName xsi:type='xsd:string'>World</firstName>
</n:sayHello>
</soap:Body>
</soap:Envelope>
envelope
envelope

header
header

header element
header element
header element
header element

body
body

body element
body element
body element
body element

2
SOAP: interaces WSDL IDL para web services
Oneway: mensagem undireccional do cliente para o servidor Definio da interface em XML

WSDL permite definir a interface do servio, indicando quais as operaes
Pedido-resposta: interaco cliente-servidor-cliente disponveis
WSDL define as mensagens trocadas na interaco (e.g. na invocao duma
Notificao: interaco unidireccional servidor-cliente
operao, quais as mensagens trocadas)
E.g. callback, notificao
WSDL permite tambm definir a forma de representao dos dados e a
Notificao-resposta: interaco servidor-cliente-servidor forma de aceder ao servio
Especificao WSDL bastante verbosa normalmente criada a partir de

interface ou cdigo do servidor
Em Java e .NET existem ferramentas para criar especificao a partir de
interfaces dessas linguagens
Alguns ambientes de desenvolvimento (IDE) possuem wizards que simplificam
tarefa
WSDL: elementos WSDL a partir do Java JAX-WS

import javax.jws.*;
No seu conjunto, um documento WSDL comporta os seguintes import java.util.*;
elementos:
Types - definies de tipos de dados, num dado sistema (e.g., XSD) public class SimpleWSServer {
Messages - definio abstracta dos dados trocados nas operaes private Map<String, MyInfo> infos;
Operation - definio abstracta das aces suportadas pelo servio public SimpleWSServer() {
Port Type - conjunto abstracto das operaes suportadas por um ou mais }
infos = new HashMap<String, MyInfo>();
endpoints
Binding - uma especificao concreta do protocolo e formato de dados public void addInfo( String name, int age) {
infos.put( name, new MyInfo( name, age));
usados por um port type. }
Port - um endpoint concreto que combina um endereo e um binding
public MyInfo getInfo( String name) throws InfoNotFoundException {
particulares.
if( infos.containsKey( name))
Servio - um conjunto de endpoints/ports relacionados. return infos.get( name);
else
throw new InfoNotFoundException();
}
}
WSDL a partir do Java JAX-WS

Anota-se uma classe usando: WebService e Cdigo gerado: SimpleWSServer.wsdl
WebMethod
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
import javax.jws.*;
<definitions targetNamespace="http://aulaWS/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://
import java.util.*; aulaWS/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<types>
@WebService() <xsd:schema>
public class SimpleWSServer { <xsd:import namespace="http://aulaWS/" schemaLocation="SimpleWSServer_schema1.xsd"/>
private Map<String, MyInfo> infos; </xsd:schema>
</types>
<message name="getInfo">
public SimpleWSServer() {
<part name="parameters" element="tns:getInfo"/>
infos = new HashMap<String, MyInfo>(); </message>
} <message name="getInfoResponse">
@WebMethod() <part name="parameters" element="tns:getInfoResponse"/>
public void addInfo( String name, int age) { </message>
infos.put( name, new MyInfo( name, age)); <message name="InfoNotFoundException">
} <part name="fault" element="tns:InfoNotFoundException"/>
</message>
@WebMethod()
...
public MyInfo getInfo( String name) throws InfoNotFoundException { <portType name="SimpleWSServer">
if( infos.containsKey( name)) <operation name="getInfo">
return infos.get( name); <input message="tns:getInfo"/>
else <output message="tns:getInfoResponse"/>
throw new InfoNotFoundException(); <fault name="InfoNotFoundException" message="tns:InfoNotFoundException"/>
} </operation>
...
} Para gerar WSDL e skeleton: </portType>
wsgen -cp . aulaWS.SimpleWSServer -wsdl -servicename MyServer
</definitions>
3
Cdigo gerado: SimpleWSServer.wsdl Cdigo gerado: MyServer.wsdl
<definitions targetNamespace="http://aulaWS/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http:// tipos xmlns:tns="http://aulaWS/"
<xs:schema version="1.0" targetNamespace="http://aulaWS/"
aulaWS/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> xmlns:xs="http://www.w3.org/2001/XMLSchema">
<types> Tipos usados nas mensagens so
<xs:element name="InfoNotFoundException" type="tns:InfoNotFoundException"/>
<xsd:schema> ... definidos em XML Schema
<xsd:import namespace="http://aulaWS/" schemaLocation="SimpleWSServer_schema1.xsd"/> <xs:element name="getInfo" type="tns:getInfo"/>
</xsd:schema> <xs:element name="getInfoResponse" type="tns:getInfoResponse"/>
</types> portType
<xs:complexType name="getInfo">
<part name="parameters" element="tns:getInfo"/> Define os servios do Web Service <xs:sequence>
</message> <xs:element name="arg0" type="xs:string" minOccurs="0"/>
<message name="getInfoResponse">
Mensagens permitem assinatura dos </xs:sequence>
servios
<part name="parameters" element="tns:getInfoResponse"/> </xs:complexType>
</message> <xs:complexType name="getInfoResponse">
<message name="InfoNotFoundException"> <xs:sequence>
<part name="fault" element="tns:InfoNotFoundException"/>
<xs:element name="return" type="tns:myInfo" minOccurs="0"/>
</message>
...
</xs:sequence>
<portType name="SimpleWSServer"> </xs:complexType>
<operation name="getInfo"> <xs:complexType name="myInfo"/>
<input message="tns:getInfo"/> <xs:complexType name="InfoNotFoundException">
<output message="tns:getInfoResponse"/> <xs:sequence>
<fault name="InfoNotFoundException" message="tns:InfoNotFoundException"/> <xs:element name="message" type="xs:string" minOccurs="0"/>
</operation>
</xs:sequence>
...
</portType>
</xs:complexType>
</definitions> </xs:schema>
Cdigo gerado: SimpleWSServer.wsdl Cdigo gerado: MyServer.wsdl

<definitions targetNamespace="http://aulaWS/" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http:// <definitions targetNamespace="http://localhost/WS/" name="MyServer" ... xmlns:tns="http://localhost/WS/" ... >
aulaWS/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <import namespace="http://aulaWS/" location="SimpleWSServer.wsdl"/>
<types> <binding name="SimpleWSServerPortBinding" type="ns1:SimpleWSServer" xmlns:ns1="http://aulaWS/">
<xsd:schema> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<xsd:import namespace="http://aulaWS/" schemaLocation="SimpleWSServer_schema1.xsd"/> <operation name="getInfo">
</xsd:schema> <soap:operation soapAction=""/>
</types> message binding
<input>
<message name="getInfo"> <soap:body use="literal"/>
<part name="parameters" element="tns:getInfo"/> As mensagens podem ser de input, Concretiza o servio definindo como
</input>
</message> output ou assinalar erros <output>
se processam as interaces
<message name="getInfoResponse"> <soap:body use="literal"/>
<part name="parameters" element="tns:getInfoResponse"/> </output>
</message> <fault name="InfoNotFoundException">
<message name="InfoNotFoundException"> <soap:fault name="InfoNotFoundException" use="literal"/>
<part name="fault" element="tns:InfoNotFoundException"/> </fault>
</message> </operation>
... ...
<portType name="SimpleWSServer"> </binding>
<operation name="getInfo"> <service name="MyServer">
<input message="tns:getInfo"/> <port name="SimpleWSServerPort" binding="tns:SimpleWSServerPortBinding">
<output message="tns:getInfoResponse"/> <soap:address location=http://webserver/WS/MyServer"/>
<fault name="InfoNotFoundException" message="tns:InfoNotFoundException"/> </port>
</operation> </service>
... </definitions>
</portType>
</definitions>
Cdigo gerado: MyServer.wsdl Web Services: tipos

<definitions targetNamespace="http://localhost/WS/" name="MyServer" ... xmlns:tns="http://localhost/WS/" ... >
<import namespace="http://aulaWS/" location="SimpleWSServer.wsdl"/>
Noo de tipos simples e tipos complexos.
<binding name="SimpleWSServerPortBinding" type="ns1:SimpleWSServer" xmlns:ns1="http://aulaWS/">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
Os tipos simples (built-in) XSD so os usuais, mas inclui diversos outros
<operation name="getInfo"> derivados: decimal, integer, positiveinteger, normalizedstring, token, etc.
<soap:operation soapAction=""/>
<input>
port Os tipos complexos correspondem a novos tipos derivados a partir de outros
<soap:body use="literal"/> Define o endereo de rede onde o tipos j definidos.
</input>
<output>
web service disponibilizado A diferena principal entre tipos simples e complexos que os tipos
<soap:body use="literal"/> simples no podem ter sub-elementos ou atributos.
</output>
<fault name="InfoNotFoundException">
<soap:fault name="InfoNotFoundException" use="literal"/> Suporta a noo de hierarquia de tipos por derivao a partir de um tipo
</fault>
</operation>
base (any)
...
</binding>
H 4 regras de derivao:
<service name="MyServer"> restriction (limita o intervalo de valores permitido no tipo base)
<port name="SimpleWSServerPort" binding="tns:SimpleWSServerPortBinding">
<soap:address location=http://webserver/WS/MyServer"/>
extension (aumenta a gama de valores permitido no tipo base)
</port> list (define uma coleco de valores de um dado tipo)
</service> union (define tipos anlogos aos registos com variante de Pascal)
</definitions>
4
Tipos XML Schema Clientes
O cliente pode ter um static proxy criado antes da execuo (static

stub) que compilado a partir do WSDL
Exemplos: wsimport p client.ws MyServer.wsdl
Ou: wsimport p client.ws http://localhost:8080/MyServer?wsdl
O cliente pode tambm usar um dynamic proxy uma classe que

criada durante a execuo a partir do WSDL
Cliente em Java JAX-WS Cliente em Java JAX-WS
package client; import javax.xml.ws.WebServiceRef;
import client.ws.*; public class SimpleClient {

@WebServiceRef(wsdlLocation="http://localhost:8080/MyServer?wsdl")
static SimpleWSServerService service;
public class Client {
public void doTest(String name) {
public static void main( String[] args) throws Exception { try {
SimpleWSServer port = service.getSimpleWSServerPort();
SimpleWSServerService service = new SimpleWSServerService();
MyInfo response = port.getInfo(name);
SimpleWSServer port = service.getSimpleWSServerPort(); } catch(Exception e) {
e.printStackTrace();
System.out.println(port.getInfo(Z Maria") ); }
}
}
} public static void main(String[] args) {
new SimpleClient().doTest(args[0]);
}
}
Criar servidor/cliente usando Java WS-*
Uma soluo consiste em utilizar os wizards disponveis nos ambientes de WS-Reliability: especificao que permite introduzir fiabilidade nas
desenvolvimento de software invocaes remotas (com as diferentes semnticas)
WS-ReliableMessaging
WS-Security: define como efectuar invocaes seguras

No Eclipse existem tutoriais que mostram como criar um servidor ou um
cliente usando os wizards disponibilizados
http://www.eclipse.org/webtools/community/communityresources.html#tutorials WS-Coordination: fornece enquadramento para coordenar as aces de
aplicaes distribudas (coreografia de web services)
WS-AtomicTransaction: fornece coordenao transaccional (distribuda) entre
mltiplos web services
E.g.: BPEL4WS, WSBPEL linguagem de orquestrao
5
WS-Coordination Web Services: resumo
flight booking
a

flight booking
b

Tem ganho popularidade na indstria porque apresenta uma soluo
Travel Agent

Client

Service

para integrar diferentes aplicaes
hire car booking
a

RMI apenas Java
Corba/IIOP suporte mais complexo
hire car booking
b

hotel booking
a
hotel booking
b

Permite:
Utilizao de standards
HTTP, XML
Reutilizao de servios (arquitecturas orientadas para os servios)
WS-Coordination
Modificao parcial/evoluo independente dos servios
WSDL
Disponibilidade, assincronismo
WS-Eventing
Web services: utilizaes possveis Web services: entre organizaes
Inter-operao entre instituies

Utilizao tende a ser limitada
Promessas de todos os servios disponveis para todos acabaram por no se
concretizar
Inter-operao entre sistemas duma mesma instituio

Utilizao com forte implantao
Web services: dentro de uma organizao Web services: problemas
Desempenho:
Complexidade do XML
Difcil fazer caching: noo de operao + estado
Necessrio cuidado para fazer evoluir o servidor
Complexidade
Necessrio utilizao de ferramentas de suporte
6
REST: Representational State Transfer
Aproximao: v uma aplicao como uma coleco de recursos

Um recuso identificado por um URI/URL
Um URL devolve um documento com a representao do recurso
Podem-se fazer referncias a outros recursos usando ligaes (links)
Estilo arquitectural, no um sistema de desenvolvimento
Aproximao proposta por Roy Fielding na sua tese de doutoramento

No como uma alternativa aos web services, mas como uma forma de
aceder a informao
REST: princpios de desenho Mais detalhes e exemplo
Protocolo cliente/servidor stateless: cada pedido contm toda a Usa HTTP GET, POST, etc., mas
informao necessria para ser processado objectivo: tornar o sistema Usa dados bem-tipados (usando schemas XML)
simples.
Um exemplo (de Roger L. Costello)
Recursos no sistema tudo so recursos, identificados por um URI/URL. Uma empresa pretende disponibilizar web services REST para permitir aos
Recursos tipicamente armazenados num formato estruturado que suporta seus clientes:
hiper-ligaes (e.g. XML) Obter uma lista de peas
Obter informao detalhada sobre uma pea
Interface uniforme: todos os recursos so acedidos por um conjunto de Submeter uma ordem de compra
operaes bem-definidas. Em HTTP: POST, GET, PUT, DELETE (equiv.
criar, ler, actualizar, remover).
Cache: para melhorar desempenho, respostas podem ser etiquetadas

como permitindo ou no caching.
Exemplo Exemplo (cont.)
Tornar uma lista de peas disponvel como um recurso Tornar uma lista de peas disponvel como um recurso
http://www.parts-depot.com/parts http://www.parts-depot.com/parts?query=hammer
Ou http://www.parts-depot.com/parts Ou http://www.parts-depot.com/parts/hammer
Enviar um pedido HTTP GET para o recurso devolve Enviar um pedido HTTP GET para o recurso devolve
<?xml version="1.0"?> <?xml version="1.0"?>

<p:Parts xmlns:p="http://www.parts-depot.com" <p:Parts xmlns:p="http://www.parts-depot.com"
xmlns:xlink="http://www.w3.org/1999/xlink"> xmlns:xlink="http://www.w3.org/1999/xlink">
<Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/> <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>
<Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/> </p:Parts>
<Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>
</p:Parts>
7
Exemplo (cont.) Exemplo (cont.)
Obter detalhes sobre uma pea Submeter uma ordem de compra

http://www.parts-depot.com/parts/00345?flavor=xml Cliente deve saber ou obter informao de como representar o pedido num documento
Enviar um pedido HTTP GET para o recurso devolve A seguir efectua um HTTP POST http://www.parts-depot.com/order
<?xml version="1.0"?> <?xml version="1.0"?>

<p:Part xmlns:p="http://www.parts-depot.com" <p:Order xmlns:p="http://www.parts-depot.com"
xmlns:xlink="http://www.w3.org/1999/xlink"> xmlns:xlink="http://www.w3.org/1999/xlink">
<Part-ID>00345</Part-ID> <Part-ID>00345</Part-ID>
<Name>Widget-A</Name> <UnitCost currency="USD">0.10</UnitCost>
<Description>This part is used within the frap assembly</Description> <Quantity>10</Quantity>
<Specification xlink:href="http://www.parts-depot.com/parts/00345/ </p:Part>
specification"/>
<UnitCost currency="USD">0.10</UnitCost>
<Quantity>10</Quantity>
</p:Part>
REST vs. RPCs Outro exemplo: sistema sobre utilizadores
Nos sistemas de RPCs a nfase nas operaes que podem ser (baseado em documento REST na wikipedia)
invocadas Ideia: sistema que mantm

Nos sistemas REST, o nfase nos recusos, na sua representao e em informao sobre utilizadores
como estes so afectados por um conjunto de mtodos standard RPCs: REST:
getUser() http://example.com/users/{user}
addUser() (GET, POST, DELTETE, PUT)
removeUser()
updateUser()
listUsers() http://example.com/users/
findUser() http://example.com/findUserForm
REST: notas soltas REST: suporte Java
Tem ganho popularidade Definido em JAX-RS (JSR 311) aprovado em Outubro de 2008
Muitos servios web disponibilizados segundo este modelo (Ou usar JAX-WS)
Grandes vantagens: simplicidade e desempenho
Suporte lingustico baseado na utilizao de anotaes
Permite definir que um dado URL leva execuo dum dado mtodo
Permite definir o modo de codificao da resposta (xml ou json)
Servios disponibilizados num modelo REST nem sempre aderem XML usando mecanismo standard de codificao de cobjectos java em XML
fornecido pelo JAXB
completamente aos princpios REST JSON mecanismo leve de codificao de tipos (RFC 4627)
Difcil disponibilizar nmero elevado de mtodos {
"firstName": "John",
Exemplo: "lastName": "Smith",
http://api.flickr.com/services/rest/?method=flickr.photos.search&. . . . "address": {
"streetAddress": "21 2nd Street",
"postalCode": 10021
},
"phoneNumbers": [
"212 555-1234",
"646 555-4567"
]
}
8
REST: suporte Java (exemplo) Web services e REST: arquitectura de suporte
@Path("/customerservice/")
@ProduceMime("application/xml")
public class CustomerService {
@GET
public Customers getCustomers() { ...... }
@GET
@Path("/customers/{id}")
@Produces("application/json")
public Customer getCustomer(@PathParam("id") String id) {...... }
@PUT
@Consumes("application/xml")
public Response updateCustomer(@PathParam("id") Long id, Customer customer) { ...... }
@POST
@Path("/customers")
public Response addCustomer(Customer customer) { ...... }
@DELETE
@Path("/customers/{id}/")
public Response deleteCustomer(@PathParam("id") String id) { ...... }
@Path("/orders/{orderId}/")
public Order getOrder(@PathParam("orderId") String orderId) { ...... }
}
Web services ou REST?
REST:
Mais simples
Mais eficiente
Complicado implementar servios complexos
Web services
Mais complexo
Grande suporte da indstria
Pode ser mais fcil para servios mais complexos
E.g.:
http://www.oreillynet.com/pub/wlg/3005
AJAX: Asynchronous JavaScript with XML Ajax vs. web clssico
Ideias chave: Web:

Apresentao baseada em standards: XHTML e CSS; Utilizador clica em links ou preenche formulrios (forms)
Apresentao e interao dinmica usando o Document Object Model; Servidor obtm dados dum form e computa nova pgina
Troca e manipulao de dados usando XML e XSLT; Browser apresenta nova pgina completa
Obteno assncrona de dados usando XMLHttpRequest;
Utilizao de JavaScript na implementao destes princpios.
Ajax:
Aco do utilizador desencadeia modificao de partes da pgina
Objectivo: permitir ao cliente duma aplicao, a executar num browser, apresentada
apresentar uma interface rica e interactiva E.g. Gmail, Google Maps, etc.
Riqueza: Muitos widgets disponveis
Interactividade
Possibilidade de modificar a pgina actual: modificando a rvore DOM
Possibilidade de enviar/receber pedidos sem se bloquear: operaes
XMLHttpRequest no bloqueante
9
Ajax (cont.) GWT: Google Web Toolkit
Baseado em Javascript Permite desenvolver aplicaes Ajax de forma simples

Javascript uma linguagem de scripting suportada pela generalidade dos
browsers Desenvolvimento em Java
Algumas caractersticas: O compilador do toolkit transforma o cliente Java em Javascript
No Java !!!
E.g. Gmail, Google Maps, etc.
No tipada
Sem threads
Suporte para eventos. Porqu?
XMLHttpRequest permite efectuar pedido HTTP, de forma assncrona Suporte para invocao remota de procedimentos (semelhante ao RMI),
Desenvolvimento mas suportando RPCs assncronos
Usando frameworks Ajax Mecanismo de serializao prpria, permite serializar grafos de objectos
E.g. Prototype, Dojo, Script.aculo.us, GoogleWeb Toolkit (GWT)
Exemplo: Java com mtodo assncrono (callback) Exemplo: Java com mtodo assncrono (callback)
public interface MyService extends RemoteService { Chamada assincrona (getShapes retorna logo; mais tarde a resposta entregue chamando
Shape[] getShapes(String databaseName) throws ShapeException . . . ; // bloqueante onSuccess() ou onFailure() ) :
}
public interface MyServiceAsync { service.getShapes(dbName, new AsyncCallback() {
void getShapes(String databaseName, AsyncCallback callback) . . . ; // no bloqueante public void onSuccess(Object result) {
} Shape[] shapes = (Shape[]) result;
controller.processShapes(shapes);
}
public class MyServiceImpl extends RemoteServiceServlet implements MyService {
Shape[] getShapes(String databaseName) throws ShapeException . . . { public void onFailure(Throwable caught) {
try {
} throw caught;
} } catch (IncompatibleRemoteServiceException e) {
public class MyServiceAsyncImpl extends RemoteServiceServlet implements MyServiceAsync { // this client is not compatible with the server; cleanup and refresh the browser
} catch (InvocationException e) {
Shape[] getShapes(String databaseName, AsyncCallback callback) . . . {
// the call didn't complete cleanly
} catch (ShapeException e) {
} // one of the 'throws' from the original method
} } catch (Throwable e) {
// last resort -- a very unexpected exception
}
}
} );
Para saber mais

10
LEI (1 ciclo) 2010/2011
Captulo 5
Web services e modelos alternativos de interaco
cliente/servidor na internet
Nota prvia
A apresentao utiliza algumas das figuras do livro de base do curso

Para saber mais:

1
Organizao do captulo
Web services SOAP
Web services REST
Invocao remotas assncronas

Ajax
GWT
Web Services
Definio W3C:
A Web service is a software system designed to support interoperable

machine-to-machine interaction over a network. It has an interface
described in a machine-processable format (specifically WSDL). Other
systems interact with the Web service in a manner prescribed by its
description using SOAP messages, typically conveyed using HTTP with an
XML serialization in conjunction with other Web-related standards.
2
Web services: motivao
Garantir inter-operabilidade
Usar protocolos web (HTTP e HTTPS) para transporte
Tambm se pode usar SMTP !!!
Usar URLs e URIs como referncias para servios remotos
Tratar problemas de heterogeneidade dos dados usando XML para
representar os dados
Componentes dos web services
Applications

Directory service
Security
Choreography

Web Services
Service descriptions (in WSDL)

SOAP

URIs (URLs or URNs)

XML
HTTP, SMTP or other transport

3
Componentes bsicos
SOAP: protocolo de invocao

remota
WSDL: linguagem de
especificao de servios
UDDI: servio de registo
UDDI
Protocolo de ligao ou binding entre o cliente e o servidor
Os fornecedores dos servios publicam a respectiva interface
O protocolo de inspeco permite verificar se uma dado servio existe

baseado na sua identificao
O UDDI responde s questes

Onde que o Web service est localizado?
O UDDI permite encontrar o servio baseado na sua definio capability
lookup
Funciona como pginas brancas e pginas amarelas
4
Estruturas de dados UDDI
businessEntity
businessServices

human readable
businessServices

information

businessServices
bindingTemplate

about the publisher

human readable

bindingTemplate

information
URL

about a
bindingTemplate
tModel

family of services
information
tModel

about the

URL

interfaces

serviceinterfaces
service
tModel

key
URL

key
service descriptions

key

SOAP
Protocolo para trocar mensagens XML

Inclui definio do formato das mensagens a trocar
Inclui um mecanismo de ligao das mensagens SOAP com o protocolo de
transporte usado: HTTP ou HTTPS (ou SMTP, )
Inclui mecanismo para tratar falhas
5
SOAP: mensagens
No SOAP toda a informao est includa no envelope da mensagem
envelope

header

header element
header element

body

body element
body element

SOAP: mensagens
<?xml version='1.0' encoding='UTF-8'?>
<soap:Envelope xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns:soap='http://
No SOAP toda a informao est includa no envelope da mensagem
schemas.xmlsoap.org/soap/envelope/' xmlns:soapenc='http://
schemas.xmlsoap.org/soap/encoding/' soap:encodingStyle='http://
schemas.xmlsoap.org/soap/encoding/'>
<soap:Body>
<n:sayHello xmlns:n='urn:examples:helloservice'>
<firstName xsi:type='xsd:string'>World</firstName>
</n:sayHello>
</soap:Body>
</soap:Envelope>
envelope

header

header element
header element

body

body element
body element

6
SOAP: interaces
Oneway: mensagem undireccional do cliente para o servidor
Pedido-resposta: interaco cliente-servidor-cliente
Notificao: interaco unidireccional servidor-cliente

E.g. callback, notificao
Notificao-resposta: interaco servidor-cliente-servidor
WSDL IDL para web services
Definio da interface em XML

WSDL permite definir a interface do servio, indicando quais as operaes
disponveis
WSDL define as mensagens trocadas na interaco (e.g. na invocao duma
operao, quais as mensagens trocadas)
WSDL permite tambm definir a forma de representao dos dados e a
forma de aceder ao servio
Especificao WSDL bastante verbosa normalmente criada a partir de

interface ou cdigo do servidor
Em Java e .NET existem ferramentas para criar especificao a partir de
interfaces dessas linguagens
Alguns ambientes de desenvolvimento (IDE) possuem wizards que simplificam
tarefa
7
WSDL: elementos
No seu conjunto, um documento WSDL comporta os seguintes

elementos:
Types - definies de tipos de dados, num dado sistema (e.g., XSD)
Messages - definio abstracta dos dados trocados nas operaes
Operation - definio abstracta das aces suportadas pelo servio
Port Type - conjunto abstracto das operaes suportadas por um ou mais
endpoints
Binding - uma especificao concreta do protocolo e formato de dados
usados por um port type.
Port - um endpoint concreto que combina um endereo e um binding
particulares.
Servio - um conjunto de endpoints/ports relacionados.

import javax.jws.*;
import java.util.*;
public class SimpleWSServer {

private Map<String, MyInfo> infos;
}
public void addInfo( String name, int age) {

}

return infos.get( name);
else
}
}
8
Anota-se uma classe usando: WebService e
WebMethod
import javax.jws.*;
import java.util.*;
@WebService()
public class SimpleWSServer {
private Map<String, MyInfo> infos;
}
@WebMethod()
public void addInfo( String name, int age) {
}
@WebMethod()
return infos.get( name);
else
}
} Para gerar WSDL e skeleton:
wsgen -cp . aulaWS.SimpleWSServer -wsdl -servicename MyServer
Cdigo gerado: SimpleWSServer.wsdl

aulaWS/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<types>
<xsd:schema>
<xsd:import namespace="http://aulaWS/" schemaLocation="SimpleWSServer_schema1.xsd"/>
</xsd:schema>
</types>
<part name="parameters" element="tns:getInfo"/>
</message>
<part name="parameters" element="tns:getInfoResponse"/>
</message>
<message name="InfoNotFoundException">
</message>
...
<portType name="SimpleWSServer">
<operation name="getInfo">
<input message="tns:getInfo"/>
<output message="tns:getInfoResponse"/>
<fault name="InfoNotFoundException" message="tns:InfoNotFoundException"/>
</operation>
...
</portType>
</definitions>
9
<types>
<xsd:schema>
</xsd:schema>
</types> portType
<part name="parameters" element="tns:getInfo"/> Define os servios do Web Service
</message>
Mensagens permitem assinatura dos
servios
</message>
</message>
...
</operation>
...
</portType>
</definitions>
Cdigo gerado: MyServer.wsdl

tipos xmlns:tns="http://aulaWS/"
<xs:schema version="1.0" targetNamespace="http://aulaWS/"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
Tipos usados nas mensagens so
<xs:element name="InfoNotFoundException" type="tns:InfoNotFoundException"/>
... definidos em XML Schema
<xs:element name="getInfo" type="tns:getInfo"/>
<xs:element name="getInfoResponse" type="tns:getInfoResponse"/>
<xs:complexType name="getInfo">
<xs:sequence>
<xs:element name="arg0" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="getInfoResponse">
<xs:sequence>
<xs:element name="return" type="tns:myInfo" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="myInfo"/>
<xs:complexType name="InfoNotFoundException">
<xs:sequence>
<xs:element name="message" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
10
<types>
<xsd:schema>
</xsd:schema>
</types> message
<part name="parameters" element="tns:getInfo"/> As mensagens podem ser de input,
</message> output ou assinalar erros
</message>
</message>
...
</operation>
...
</portType>
</definitions>

<soap:operation soapAction=""/> binding
<input>
<soap:body use="literal"/> Concretiza o servio definindo como
</input>
<output>
se processam as interaces
<soap:body use="literal"/>
</output>
<soap:fault name="InfoNotFoundException" use="literal"/>
</fault>
</operation>
...
</binding>
<service name="MyServer">
</port>
</service>
</definitions>
11
<soap:operation soapAction=""/> port
<input>
<soap:body use="literal"/> Define o endereo de rede onde o
</input>
<output>
web service disponibilizado
<soap:body use="literal"/>
</output>
<soap:fault name="InfoNotFoundException" use="literal"/>
</fault>
</operation>
...
</binding>
<service name="MyServer">
</port>
</service>
</definitions>
Web Services: tipos
Noo de tipos simples e tipos complexos.

Os tipos simples (built-in) XSD so os usuais, mas inclui diversos outros
derivados: decimal, integer, positiveinteger, normalizedstring, token, etc.
Os tipos complexos correspondem a novos tipos derivados a partir de outros
tipos j definidos.
A diferena principal entre tipos simples e complexos que os tipos
simples no podem ter sub-elementos ou atributos.
Suporta a noo de hierarquia de tipos por derivao a partir de um tipo

base (any)
H 4 regras de derivao:
restriction (limita o intervalo de valores permitido no tipo base)
extension (aumenta a gama de valores permitido no tipo base)
list (define uma coleco de valores de um dado tipo)
union (define tipos anlogos aos registos com variante de Pascal)
12
Tipos XML Schema
Clientes
O cliente pode ter um static proxy criado antes da execuo (static

stub) que compilado a partir do WSDL
Exemplos: wsimport p client.ws MyServer.wsdl
Ou: wsimport p client.ws http://localhost:8080/MyServer?wsdl
O cliente pode tambm usar um dynamic proxy uma classe que

criada durante a execuo a partir do WSDL
13
Cliente em Java JAX-WS
package client;
import client.ws.*;
public class Client {
public static void main( String[] args) throws Exception {
SimpleWSServerService service = new SimpleWSServerService();
System.out.println(port.getInfo(Z Maria") );
}
}
Cliente em Java JAX-WS
import javax.xml.ws.WebServiceRef;
public class SimpleClient {

@WebServiceRef(wsdlLocation="http://localhost:8080/MyServer?wsdl")
static SimpleWSServerService service;
public void doTest(String name) {

try {
MyInfo response = port.getInfo(name);

} catch(Exception e) {
e.printStackTrace();
}
}
public static void main(String[] args) {

new SimpleClient().doTest(args[0]);
}
}
14
Criar servidor/cliente usando Java
Uma soluo consiste em utilizar os wizards disponveis nos ambientes de

desenvolvimento de software
No Eclipse existem tutoriais que mostram como criar um servidor ou um

cliente usando os wizards disponibilizados
http://www.eclipse.org/webtools/community/communityresources.html#tutorials
WS-*
WS-Reliability: especificao que permite introduzir fiabilidade nas

invocaes remotas (com as diferentes semnticas)
WS-ReliableMessaging
WS-Security: define como efectuar invocaes seguras
WS-Coordination: fornece enquadramento para coordenar as aces de

aplicaes distribudas (coreografia de web services)
WS-AtomicTransaction: fornece coordenao transaccional (distribuda) entre
mltiplos web services
E.g.: BPEL4WS, WSBPEL linguagem de orquestrao
15
WS-Coordination

flight booking a

flight booking b
Travel Agent

Client
Service

hire car booking a

hire car booking b
hotel booking a

hotel booking b

Web Services: resumo
Tem ganho popularidade na indstria porque apresenta uma soluo

para integrar diferentes aplicaes
RMI apenas Java
Corba/IIOP suporte mais complexo
Permite:
Utilizao de standards
HTTP, XML
Reutilizao de servios (arquitecturas orientadas para os servios)
WS-Coordination
Modificao parcial/evoluo independente dos servios
WSDL
Disponibilidade, assincronismo
WS-Eventing
16
Web services: utilizaes possveis
Inter-operao entre instituies

Utilizao tende a ser limitada
Promessas de todos os servios disponveis para todos acabaram por no se
concretizar
Inter-operao entre sistemas duma mesma instituio

Utilizao com forte implantao
Web services: entre organizaes
17
Web services: dentro de uma organizao
Web services: problemas
Desempenho:
Complexidade do XML
Difcil fazer caching: noo de operao + estado
Necessrio cuidado para fazer evoluir o servidor
Complexidade
Necessrio utilizao de ferramentas de suporte
18
REST: Representational State Transfer
Aproximao: v uma aplicao como uma coleco de recursos

Um recuso identificado por um URI/URL
Um URL devolve um documento com a representao do recurso
Podem-se fazer referncias a outros recursos usando ligaes (links)
Estilo arquitectural, no um sistema de desenvolvimento
Aproximao proposta por Roy Fielding na sua tese de doutoramento

No como uma alternativa aos web services, mas como uma forma de
aceder a informao
19
REST: princpios de desenho
Protocolo cliente/servidor stateless: cada pedido contm toda a

informao necessria para ser processado objectivo: tornar o sistema
simples.
Recursos no sistema tudo so recursos, identificados por um URI/URL.

Recursos tipicamente armazenados num formato estruturado que suporta
hiper-ligaes (e.g. XML)
Interface uniforme: todos os recursos so acedidos por um conjunto de

operaes bem-definidas. Em HTTP: POST, GET, PUT, DELETE (equiv.
criar, ler, actualizar, remover).
Cache: para melhorar desempenho, respostas podem ser etiquetadas

como permitindo ou no caching.
Mais detalhes e exemplo
Usa HTTP GET, POST, etc., mas

Usa dados bem-tipados (usando schemas XML)
Um exemplo (de Roger L. Costello)

Uma empresa pretende disponibilizar web services REST para permitir aos
seus clientes:
Obter uma lista de peas
Obter informao detalhada sobre uma pea
Submeter uma ordem de compra
20
Exemplo
Tornar uma lista de peas disponvel como um recurso

http://www.parts-depot.com/parts
Ou http://www.parts-depot.com/parts
Enviar um pedido HTTP GET para o recurso devolve
<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.parts-depot.com"
xmlns:xlink="http://www.w3.org/1999/xlink">
</p:Parts>
Exemplo (cont.)
Tornar uma lista de peas disponvel como um recurso

http://www.parts-depot.com/parts?query=hammer
Ou http://www.parts-depot.com/parts/hammer
<p:Parts xmlns:p="http://www.parts-depot.com"
</p:Parts>
21
Exemplo (cont.)
Obter detalhes sobre uma pea

http://www.parts-depot.com/parts/00345?flavor=xml
<p:Part xmlns:p="http://www.parts-depot.com"
<Part-ID>00345</Part-ID>
<Name>Widget-A</Name>
<Description>This part is used within the frap assembly</Description>
<Specification xlink:href="http://www.parts-depot.com/parts/00345/
specification"/>
</p:Part>
Exemplo (cont.)
Submeter uma ordem de compra

Cliente deve saber ou obter informao de como representar o pedido num documento
A seguir efectua um HTTP POST http://www.parts-depot.com/order
<p:Order xmlns:p="http://www.parts-depot.com"
<Part-ID>00345</Part-ID>
</p:Part>
22
REST vs. RPCs
Nos sistemas de RPCs a nfase nas operaes que podem ser

invocadas
Nos sistemas REST, o nfase nos recusos, na sua representao e em

como estes so afectados por um conjunto de mtodos standard
Outro exemplo: sistema sobre utilizadores
(baseado em documento REST na wikipedia)
Ideia: sistema que mantm

informao sobre utilizadores
RPCs: REST:
getUser() http://example.com/users/{user}
addUser() (GET, POST, DELTETE, PUT)
removeUser()
updateUser()
listUsers() http://example.com/users/
findUser() http://example.com/findUserForm
23
REST: notas soltas
Tem ganho popularidade

Muitos servios web disponibilizados segundo este modelo
Grandes vantagens: simplicidade e desempenho
Servios disponibilizados num modelo REST nem sempre aderem

completamente aos princpios REST
Difcil disponibilizar nmero elevado de mtodos
Exemplo:
http://api.flickr.com/services/rest/?method=flickr.photos.search&. . . .
REST: suporte Java
Definido em JAX-RS (JSR 311) aprovado em Outubro de 2008

(Ou usar JAX-WS)
Suporte lingustico baseado na utilizao de anotaes

Permite definir que um dado URL leva execuo dum dado mtodo
Permite definir o modo de codificao da resposta (xml ou json)
XML usando mecanismo standard de codificao de cobjectos java em XML
fornecido pelo JAXB
JSON mecanismo leve de codificao de tipos (RFC 4627)
{
"firstName": "John",
"lastName": "Smith",
"address": {
"streetAddress": "21 2nd Street",
"postalCode": 10021
},
"phoneNumbers": [
"212 555-1234",
"646 555-4567"
]
}
24
REST: suporte Java (exemplo)
@Path("/customerservice/")
@ProduceMime("application/xml")
public class CustomerService {
@GET
public Customers getCustomers() { ...... }
@GET
@Produces("application/json")
public Customer getCustomer(@PathParam("id") String id) {...... }
@PUT
@Consumes("application/xml")
public Response updateCustomer(@PathParam("id") Long id, Customer customer) { ...... }
@POST
@Path("/customers")
public Response addCustomer(Customer customer) { ...... }
@DELETE
@Path("/customers/{id}/")
public Response deleteCustomer(@PathParam("id") String id) { ...... }
@Path("/orders/{orderId}/")
public Order getOrder(@PathParam("orderId") String orderId) { ...... }
}
Web services e REST: arquitectura de suporte
25
Web services ou REST?
REST:
Mais simples
Mais eficiente
Complicado implementar servios complexos
Web services
Mais complexo
Grande suporte da indstria
Pode ser mais fcil para servios mais complexos
E.g.:
http://www.oreillynet.com/pub/wlg/3005
26
AJAX: Asynchronous JavaScript with XML
Ideias chave:
Apresentao baseada em standards: XHTML e CSS;
Apresentao e interao dinmica usando o Document Object Model;
Troca e manipulao de dados usando XML e XSLT;
Obteno assncrona de dados usando XMLHttpRequest;
Utilizao de JavaScript na implementao destes princpios.
Objectivo: permitir ao cliente duma aplicao, a executar num browser,

apresentar uma interface rica e interactiva
Riqueza: Muitos widgets disponveis
Interactividade
Possibilidade de modificar a pgina actual: modificando a rvore DOM
Possibilidade de enviar/receber pedidos sem se bloquear: operaes
XMLHttpRequest no bloqueante
Ajax vs. web clssico
Web:
Utilizador clica em links ou preenche formulrios (forms)
Servidor obtm dados dum form e computa nova pgina
Browser apresenta nova pgina completa
Ajax:
Aco do utilizador desencadeia modificao de partes da pgina
apresentada
27
Ajax (cont.)
Baseado em Javascript
Javascript uma linguagem de scripting suportada pela generalidade dos
browsers
Algumas caractersticas:
No Java !!!
No tipada
Sem threads
Suporte para eventos. Porqu?
XMLHttpRequest permite efectuar pedido HTTP, de forma assncrona
Desenvolvimento
Usando frameworks Ajax
E.g. Prototype, Dojo, Script.aculo.us, GoogleWeb Toolkit (GWT)
GWT: Google Web Toolkit
Permite desenvolver aplicaes Ajax de forma simples
Desenvolvimento em Java
O compilador do toolkit transforma o cliente Java em Javascript
Suporte para invocao remota de procedimentos (semelhante ao RMI),

mas suportando RPCs assncronos
Mecanismo de serializao prpria, permite serializar grafos de objectos
28
Exemplo: Java com mtodo assncrono (callback)
public interface MyService extends RemoteService {

Shape[] getShapes(String databaseName) throws ShapeException . . . ; // bloqueante
}
public interface MyServiceAsync {
void getShapes(String databaseName, AsyncCallback callback) . . . ; // no bloqueante
}
public class MyServiceImpl extends RemoteServiceServlet implements MyService {

Shape[] getShapes(String databaseName) throws ShapeException . . . {

}
}
public class MyServiceAsyncImpl extends RemoteServiceServlet implements MyServiceAsync {
Shape[] getShapes(String databaseName, AsyncCallback callback) . . . {

}
}
Exemplo: Java com mtodo assncrono (callback)
Chamada assincrona (getShapes retorna logo; mais tarde a resposta entregue chamando
onSuccess() ou onFailure() ) :
service.getShapes(dbName, new AsyncCallback() {

public void onSuccess(Object result) {
Shape[] shapes = (Shape[]) result;
controller.processShapes(shapes);
}
public void onFailure(Throwable caught) {

try {
throw caught;
} catch (IncompatibleRemoteServiceException e) {
// this client is not compatible with the server; cleanup and refresh the browser
} catch (InvocationException e) {
// the call didn't complete cleanly
} catch (ShapeException e) {
// one of the 'throws' from the original method
} catch (Throwable e) {
// last resort -- a very unexpected exception
}
}
} );
29
Para saber mais

30
Nota prvia
A estrutura da apresentao semelhante e utiliza algumas das figuras livro de

base do curso
Captulo 7
LEI (1 ciclo) 2010/2011

e tambm do captulo de segurana do livro
Captulo 6 James F. Kurose and Keith W. Ross, "Computer Networking - A Top-Down Approach
Featuring the Internet, Addison Wesley Longman, Inc.
Segurana em sistemas distribudos
Organizao do captulo Da necessidade da segurana
Apresentao do problema A partir do momento que os computadores so partilhados e contm

Diferenas essenciais entre os sistemas centralizados e os sistemas distribudos dados ou permitem executar operaes com valor, necessrio definir
Canais seguros e seus requisitos polticas de segurana que: evitem acesso indevido a dados, protejam
Criptografia simtrica operaes com alguma espcie de valor, e impeam aces de
Utilizao da criptografia simtrica na comunicao e autenticao vandalismo
Criptografia assimtrica Naturalmente, os sistemas distribudos aumentam a necessidade de se
Utilizao da criptografia assimtrica na comunicao e autenticao disporem de mais politicas de segurana pois os sistemas tornam-se mais
acessveis (so mesmo abertos ao exterior)
Assinaturas digitais
Aplicaes seguras mais comuns: SSL, PGP, ... Por outro lado, as caractersticas distribudas destes sistemas requerem
mecanismos de segurana mais sofisticados.
Os sistemas devem pois providenciar um conjunto de mecanismos que
possam ser usados para, em cada caso, materializar as polticas de
segurana mais adequadas. Isto , as polticas de segurana so
materializadas com o auxlio dos mecanismos de segurana mas so
distintas destes
Exemplo Modelo de segurana
Mecanismo: uma porta com fechadura e chave para proteger uma casa Num sistema existem entidades que do ponto de vista da segurana tm
identidade prpria, direitos e deveres - essas entidades podem ser
A casa fica protegida com este mecanismo? utilizadores, processos, etc. e designam-se pelo termo principal
Poltica: a porta deve estar sempre fechada com a chave A segurana do sistema distribudo passa por:
autenticar os principais (autenticao)
Como garantir/verificar que a poltica cumprida? verificar os seus direitos de acesso aos objectos (controlo de acessos)
utilizar canais seguros para impedir o acesso, alterao ou destruio
A casa j fica protegida com esta poltica? indevida de informao, ou seja, proteger a privacidade
Quantas chaves existem? Quem tem acesso s chaves?
E as janelas?
1
Elementos do modelo de segurana Um sistema centralizado clssico
Processo utilizador utilizador

Autenticao (login)
O ncleo do sistema de operao

realiza controlo de acessos
Trusted Computer Base

Mecanismos (software/hardware)
nos quais se confia para
implementar a poltica de
segurana
Num sistema distribudo Principais, objectos, direitos de acesso e canais
Access rights Object

Processo
do SD invocation The image
? The cannot be
image displayed.
Client
cannot Your
be result Server
computer
may not have

realiza controlo de acessos,
mas qual a identidade e direitos Principal (user) Network Principal (server)
da entidade externa?
Onde est a Trusted Computing Base ?
Assumir o pior End-to-end arguments em segurana
Os componentes so acessveis pelos atacantes A segurana deve depender de um conjunto de mecanismos

As redes so inseguras de segurana e de uma Trusted Computing Base mnima,
porque assim:
Os segredos tendem a deixar de o ser (p.e. Chaves)
mais fcil compreender os mecanismos de segurana,
Os algoritmos (cdigo?) do sistema pode ser conhecido dos atacantes mais fcil verificar a sua correco,
mais fcil de implementar,
Os atacantes podem ter imensos recursos (CPU, memria, dinheiro,...) o nmero de intervenientes menor,
s se paga o que se consome
2
Problemas do cdigo mvel Java Security Manager
O cdigo obtido remotamente pode conter operaes que comprometam As operaes criticas na biblioteca Java verificam permisses:
a segurana de um sistema SecurityManager security = System.getSecurityManager();
if (security != null) { security.checkXXX(argument, . . . ); }
Como se pode minimizar o risco (exemplo Java VM):
Verificar que o cdigo apenas contm operaes legtimas A politica de segurana pode ser configurada ao gosto:
Manter o cdigo obtido remotamente separado do cdigo local System.getProperties().put( "java.security.policy", my.policy");
System.setSecurityManager( new SecurityManager() );
Associar permisses ao cdigo obtido remotamente. As permisses dadas
podem depender da origem do cdigo, o que pode ser verificado atravs da
assinatura do mesmo Ficheiro my.policy tem algo como:
Quando se executa uma operao que acede a um recurso do sistema (exemplo: grant codeBase "file:/home/user2/" { !
sockets, ficheiros, etc.), so verificadas as permisses (de todas as classes do permission java.io.FilePermission "/tmp/abc", "read"; };!
stack)
Possvel porque todas estas operaes so implementadas pelo biblioteca do
sistema
Mtodos de ataque
Violar os mecanismos de autenticao

Explorar inadequaes na especificao ou implementao da Trusted
Computing Base e adquirir direitos ou identidades indevidas
Tentar modificar a Trusted Computing Base
Obter segredos indevidos
Como os ataques exploram bugs e fraquezas das implementaes ou

simples fraquezas de planeamento ou humanas, geralmente impossvel
de enunciar todas as formas de ataque e quase sempre esto-se a
descobrir novas.
Comunicao num sistema sem segurana Ataques em sistemas distribudos atravs da

comunicao
Canais no seguros:
Indiscrio obteno de mensagens sem autorizao (Eavesdropping)
Mascarar-se ou pretender ser outro (Masquerading)
Reemisso de antigas mensagens (Message replaying)
Alterao indevida do contedo das mensagens (Message tampering)
Supresso de mensagens (Message supression)
Repudiar (negar) as mensagens enviadas pelo prprio
Ataques de impedimento de prestao de servio (Denial of service

Canal est acessvel ao atacante
attacks)
Nomes usados na descrio dos protocolos de segurana: Anlise de trfego (Traffic analysis)
Alice, Bob, Carol, Dave participantes que querem comunicar
Mallory/Trudy atacante que pode ler, interceptar, modificar suprimir ou re-introduzir
mensagens nos canais ou tentar passar por um dos participantes (Eve usado com
frequncia para um atacante que l mensagens eavesdropper)
3
Eavesdropping (exemplo): cpia dos pacotes que Masquerading (exemplo): mascarar o emissor
transitam na rede
Packet sniffing: IP Spoofing:
broadcast media Permite a gerao de pacotes directamente da aplicao mas em que o
modo promiscuous da placa ethernet (NIC) permite copiar todos os pacotes endereo origem falso (est spoofed)
permite a leitura de todos os dados no cifrados (exemplo: passwords) o receptor no pode detectar que o pacote est spoofed
exemplo: Trudy sniffs Bobs packets e.g.: Trudy mascara-se como Bob
Alice Trudy Alice Trudy
src:B dest:A payload src:B dest:A payload

Bob
Bob
Impedimento de prestao de servio (exemplo) Mecanismos de segurana mais comuns
Denial of service (DoS): Baseados na utilizao de tcnicas criptogrficas

um conjunto de pacotes inundam o receptor impedindo-o de fazer qualquer Autenticar clientes e servidores
trabalho til (DoS- Denial Of Service attack) Construir canais seguros: imunes a modificaes e garantindo a privacidade
Distributed DoS (DDoS): ataque distribudo e coordenado de impedimento da Assinaturas digitais
prestao de servio
exemplo, C e um host remoto realizam um SYN-attack a A
Introduzir padres de comunicao falsos

A C
SYN
SYN
SYN SYN SYN
B
SYN
SYN
Nota: cifrar e no encriptar
4
LEI (1 ciclo) 2010/2011
Captulo 6
Segurana em sistemas distribudos
Nota prvia
A estrutura da apresentao semelhante e utiliza algumas das figuras livro de

base do curso
Captulo 7
e tambm do captulo de segurana do livro

James F. Kurose and Keith W. Ross, "Computer Networking - A Top-Down Approach
Featuring the Internet, Addison Wesley Longman, Inc.
1
Apresentao do problema
Diferenas essenciais entre os sistemas centralizados e os sistemas distribudos
Canais seguros e seus requisitos
Criptografia simtrica
Utilizao da criptografia simtrica na comunicao e autenticao
Criptografia assimtrica
Utilizao da criptografia assimtrica na comunicao e autenticao
Aplicaes seguras mais comuns: SSL, PGP, ...
Da necessidade da segurana
A partir do momento que os computadores so partilhados e contm

dados ou permitem executar operaes com valor, necessrio definir
polticas de segurana que: evitem acesso indevido a dados, protejam
operaes com alguma espcie de valor, e impeam aces de
vandalismo
Naturalmente, os sistemas distribudos aumentam a necessidade de se
disporem de mais politicas de segurana pois os sistemas tornam-se mais
acessveis (so mesmo abertos ao exterior)
Por outro lado, as caractersticas distribudas destes sistemas requerem
mecanismos de segurana mais sofisticados.
Os sistemas devem pois providenciar um conjunto de mecanismos que
possam ser usados para, em cada caso, materializar as polticas de
segurana mais adequadas. Isto , as polticas de segurana so
materializadas com o auxlio dos mecanismos de segurana mas so
distintas destes
2
Exemplo
Mecanismo: uma porta com fechadura e chave para proteger uma casa
A casa fica protegida com este mecanismo?
Poltica: a porta deve estar sempre fechada com a chave
Como garantir/verificar que a poltica cumprida?
A casa j fica protegida com esta poltica?
Quantas chaves existem? Quem tem acesso s chaves?
E as janelas?
Modelo de segurana
Num sistema existem entidades que do ponto de vista da segurana tm

identidade prpria, direitos e deveres - essas entidades podem ser
utilizadores, processos, etc. e designam-se pelo termo principal
A segurana do sistema distribudo passa por:

autenticar os principais (autenticao)
verificar os seus direitos de acesso aos objectos (controlo de acessos)
utilizar canais seguros para impedir o acesso, alterao ou destruio
indevida de informao, ou seja, proteger a privacidade
3
Elementos do modelo de segurana
Um sistema centralizado clssico
Processo utilizador utilizador

Autenticao (login)

realiza controlo de acessos
Trusted Computer Base

Mecanismos (software/hardware)
nos quais se confia para
implementar a poltica de
segurana
4
Num sistema distribudo
Processo
do SD
?

realiza controlo de acessos,
mas qual a identidade e direitos
da entidade externa?
Principais, objectos, direitos de acesso e canais
Access rights Object

invocation The image cannot be displayed.
Your computer may not have
The image cannot be enough memory to open the
displayed. Your image, or the image may have
computer may not have been corrupted. Restart your
enough memory to open computer, and then open the file
Client
the image, or the image
may have been
again. If the red x still appears,
you may have to delete the image
corrupted. Restart your
computer, and then result Server
and then insert it again.
Principal (user) Network Principal (server)
Onde est a Trusted Computing Base ?
5
Assumir o pior
Os componentes so acessveis pelos atacantes
As redes so inseguras
Os segredos tendem a deixar de o ser (p.e. Chaves)
Os algoritmos (cdigo?) do sistema pode ser conhecido dos atacantes
Os atacantes podem ter imensos recursos (CPU, memria, dinheiro,...)
End-to-end arguments em segurana
A segurana deve depender de um conjunto de mecanismos

de segurana e de uma Trusted Computing Base mnima,
porque assim:
mais fcil compreender os mecanismos de segurana,
mais fcil verificar a sua correco,
mais fcil de implementar,
o nmero de intervenientes menor,
s se paga o que se consome
6
Problemas do cdigo mvel
O cdigo obtido remotamente pode conter operaes que comprometam

a segurana de um sistema
Como se pode minimizar o risco (exemplo Java VM):

Verificar que o cdigo apenas contm operaes legtimas
Manter o cdigo obtido remotamente separado do cdigo local
Associar permisses ao cdigo obtido remotamente. As permisses dadas

podem depender da origem do cdigo, o que pode ser verificado atravs da
assinatura do mesmo
Quando se executa uma operao que acede a um recurso do sistema (exemplo:
sockets, ficheiros, etc.), so verificadas as permisses (de todas as classes do
stack)
Possvel porque todas estas operaes so implementadas pelo biblioteca do
sistema
Java Security Manager
As operaes criticas na biblioteca Java verificam permisses:

SecurityManager security = System.getSecurityManager();
if (security != null) { security.checkXXX(argument, . . . ); }
A politica de segurana pode ser configurada ao gosto:

System.getProperties().put( "java.security.policy", my.policy");
System.setSecurityManager( new SecurityManager() );
Ficheiro my.policy tem algo como:

grant codeBase "file:/home/user2/" { !
permission java.io.FilePermission "/tmp/abc", "read"; };!
7
Mtodos de ataque
Violar os mecanismos de autenticao

Explorar inadequaes na especificao ou implementao da Trusted
Computing Base e adquirir direitos ou identidades indevidas
Tentar modificar a Trusted Computing Base
Obter segredos indevidos
Como os ataques exploram bugs e fraquezas das implementaes ou

simples fraquezas de planeamento ou humanas, geralmente impossvel
de enunciar todas as formas de ataque e quase sempre esto-se a
descobrir novas.
8
Comunicao num sistema sem segurana
Canal est acessvel ao atacante
Nomes usados na descrio dos protocolos de segurana:

Alice, Bob, Carol, Dave participantes que querem comunicar
Mallory/Trudy atacante que pode ler, interceptar, modificar suprimir ou re-introduzir
mensagens nos canais ou tentar passar por um dos participantes (Eve usado com
frequncia para um atacante que l mensagens eavesdropper)
Ataques em sistemas distribudos atravs da

comunicao
Canais no seguros:
Indiscrio obteno de mensagens sem autorizao (Eavesdropping)
Mascarar-se ou pretender ser outro (Masquerading)
Reemisso de antigas mensagens (Message replaying)
Alterao indevida do contedo das mensagens (Message tampering)
Supresso de mensagens (Message supression)
Repudiar (negar) as mensagens enviadas pelo prprio
Ataques de impedimento de prestao de servio (Denial of service

attacks)
Anlise de trfego (Traffic analysis)
9
Eavesdropping (exemplo): cpia dos pacotes que
transitam na rede
Packet sniffing:
broadcast media
modo promiscuous da placa ethernet (NIC) permite copiar todos os pacotes
permite a leitura de todos os dados no cifrados (exemplo: passwords)
exemplo: Trudy sniffs Bobs packets
Alice Trudy
src:B dest:A payload

Bob
Masquerading (exemplo): mascarar o emissor
IP Spoofing:
Permite a gerao de pacotes directamente da aplicao mas em que o
endereo origem falso (est spoofed)
o receptor no pode detectar que o pacote est spoofed
e.g.: Trudy mascara-se como Bob
Alice Trudy
src:B dest:A payload
Bob
10
Impedimento de prestao de servio (exemplo)
Denial of service (DoS):

um conjunto de pacotes inundam o receptor impedindo-o de fazer qualquer
trabalho til (DoS- Denial Of Service attack)
Distributed DoS (DDoS): ataque distribudo e coordenado de impedimento da
prestao de servio
exemplo, C e um host remoto realizam um SYN-attack a A
A C
SYN
SYN
SYN SYN SYN
B
SYN
SYN
Mecanismos de segurana mais comuns
Baseados na utilizao de tcnicas criptogrficas

Autenticar clientes e servidores
Construir canais seguros: imunes a modificaes e garantindo a privacidade
Introduzir padres de comunicao falsos
Nota: cifrar e no encriptar
11
Canais seguros Criptografia
Criptografia a disciplina que inclui os princpios, meios e mtodos de

Principal A Principal B transformao dos dados com a finalidade de:
esconder o seu contedo semntico
The image The image estabelecer a sua autenticidade
cannot be cannot be
Process p
displayed. Secure channel Process q
displayed. impedir que a sua alterao passe despercebida
Your Your
computer computer impedir a sua utilizao no autorizada.
evitar o seu repdio
Objectivo: trocar dados com confidencialidade, integridade e autenticidade

(e no repdio se necessrio) Chave criptogrfica um parmetro utilizado com um algoritmo
Num canal seguro os interlocutores (A e B) esto autenticados (mutuamente?)
criptogrfico para transformar, validar, autenticar, cifrar ou decifrar
O inimigo no pode copiar, alterar ou introduzir mensagens
O inimigo no pode reordenar as mensagens
dados.
O inimigo no pode fazer replaying de mensagens (replaying = reenvio)
(o emissor no pode negar o envio de determinada mensagem)
O canal pode basear-se em qualquer meio de comunicao: mensagens ou

conexes por rede, mensagens email, ficheiros, etc...
Cifrar/decifrar A linguagem criptogrfica (exemplo de canal cifrado)
Cifrar com funo/algoritmo E() e chave/parmetro k:

Criptograma
Mensagem em claro
E(k,M) = X tambm representvel por {M}k
K (ciphertext) K Mensagem em claro
(plaintext)
Decifrar funo/algoritmo D() e chave/parmetro j: {M}K {{M}K}K= M
M
D(j,X) = M (ou seja, verifica-se { {M}k }j = M)
Figure 7.3 goes here
No deve ser possvel, sabendo X, obter M (mesmo que se
conhea E e D)
Pode acontecer que E()=D() ou estejam relacionadas
Pode acontecer que k=j ou que estejam relacionadas Trudy no consegue passar por Alice ou Bob
No consegue obter M (mesmo em parte)
Qualquer alterao no passa despercebida
Criptografia clssica ex.: cdigo de Csar Eficcia da criptografia
Normalmente baseiam-se em cifras de substituio O algoritmo criptogrfico ser tanto melhor quanto mais difcil for obter o
Uma cifra de substituio substitui um smbolo por outro texto original a partir do texto cifrado, sem se conhecer a chave. A
eficcia de um ataque depende de dois factores:
Cdigo de Csar uma cifra de substituio para texto, considerando
Algoritmo de cifra
A=0,B=1,etc.
Cardinalidade do domnio da chave, isto , nmero de bits da chave
E(n,x) = (x+n) mod 26
D(n,x) = (x-n) mod 26 Mtodos de ataque:
Ex.: para n = 3, tm-se as seguintes substituies Fora bruta - baseia-se na explorao sistemtica de todas as
ABCDEFGHIJKLMNOPQRSTUVWXYZ
chaves possveis
DEFGHIJKLMNOPQRSTUVWXYZABC
E(3,SISTEMAS DISTRIBUIDOS)=VLVWHPDV GLVWULEXLGRV Criptoanlise - baseia-se em explorar os mtodos matemticos
utilizados em criptografia para descobrir como decifrar os dados (ou
Usado por Jlio Csar para cifrar mensagens militares diminuir o nmero de possibilidades)
Como quebrar esta cifra?
1
Fora bruta exemplo Criptoanlise exemplo
Tentar todas as chaves no Anlise dedefrequncia:

Anlise ideia
frequncia: ideia aplicada
ao cdigo
aplicada de Csar:de Csar:
ao cdigo
caso do cdigo de Csar:
sabe-se
sabe-se que X substitudo sempre
X substitudo sempre
por que
Y
sabe-se que X VLVWHPDV GLVWULEXLGRV por Ysabe-se a frequncia do
substitudo sempre por Y sabe-seaparecimento dos diferentes
a frequncia do
smbolos no texto
com deslocamento k 1 UKUVGOCU FKUVTKDWKFQU aparecimento dos diferentes
smbolos no texto
Verifica-se a Como fazer?
O smbolo mais frequente no texto
descodificao obtida 2 TJTUFNBT EJTUSJCVJEPT cifrado deve corresponder a um dos
tentando k de 1 at 25 smbolos mais frequentes no texto
3 SISTEMAS DISTRIBUIDOS original
Se se souber algum texto da

mensagem, pode-se usar essa
informao para inferir parte da
chave
Ataque Enigma (WWII)
Eficcia da criptografia Ataques fora bruta

Supondo que possvel arranjar mil milhes (10^3 x 10^6) de computadores,
Nenhum algoritmo criptogrfico inteiramente seguro se capazes de testarem mil milhes de chaves por segundo cada um, ento
o nmero de bits da chave tornar um ataque fora bruta realista no possvel testar 10^18 chaves por segundo.
quadro de dois factores: Uma chave de 128 bits tem cerca de 3,4 x 10^38 combinaes (10 levantado a
O valor da informao 38). Com o poder computacional indicado, seriam necessrios 10^13 anos para
A capacidade computacional do atacante completar o ataque
Se a anlise dos dados cifrados permite detectar informao Curiosidade: estima-se que a idade do universo de cerca de 10^10 anos.
(estatistica, padres, ...) que relaciona esses dados com a
Uma chave de 54 bits tem cerca de 6 x 10^16 combinaes. Com o poder
informao original computacional indicado, seria necessrio menos de um segundo para descobrir a
chave.
Concluso: chaves geradas de forma totalmente aleatria e com um nmero de

bits suficiente so relativamente seguras quando sujeitas a ataques do tipo fora
bruta
A teoria e a prtica Confiana nos algoritmos criptogrficos
A anlise anterior pressupe que h uma distribuio perfeita da O algoritmo criptogrfico usado deve produzir contedo com grande
probabilidade de se ter seleccionado uma dada chave em todo o universo entropia e sem qualquer relao com a mensagem original
possvel. Na prtica tais geradores perfeitos de chaves no existem e o
atacante pode, conhecendo alguma das fraquezas do gerador de chaves, ir No possvel provar matematicamente que um algoritmo criptogrfico
analisar um espao de pesquisa muito mais reduzido. no tem falhas capazes de o tornar frgil perante ataques
criptoanalticos.
espectvel que a chave seja descoberta antes da ltima tentativa (pode S se consegue provar exactamente o contrrio, atravs de exemplos.
ser na 1). Em mdia ser a meio das tentativas.
A segurana de um mtodo pois baseada em o mesmo ser pblico e
Por outro lado, certas chaves so inadequadas e so facilmente quebradas ser sujeito critica e anlise por muitos especialistas.
conhecendo o algoritmo usado por isso no podem ser usadas. A segurana deve ser resultado do segredo das chaves e no do segredo do
algoritmo criptogrfico
Ou seja, na prtica, a gerao de chaves adequadas um problema muito

delicado e os ataques de fora bruta quase nunca so realizados de forma A cincia criptogrfica uma disciplina especializada.
cega a todo o universo de chaves possveis.
2
A linguagem criptogrfica (exemplo: canal cifrado)
Criptograma
Mensagem em claro
(plaintext)
{M}K {{M}K}K= M
M
Criptografia de chave simtrica : as chaves de cifra e de decifra so idnticas
Criptografia de chaves assimtrica ou de chave pblica : cifra-se com a chave

pblica, decifra-se com a chave privada do receptor, ou vice-versa
Criptografia simtrica Algoritmos de criptografia simtrica mais comuns
Parceiros devem partilhar chave secreta DES - Data Encryption Standard - chaves com 56 bits. Histria atribulada. Est a
cair em desuso pois a chave demasiado pequena para a potncia de clculo
Mensagem cifrada e decifrada com a mesma chave actual.
E(k,M) = X
D(k,X) = M
Triple DES (ou TDEA) - DES reforado - chave com 112 ou 168 bits (3x56).
Que garantias d? (confidencialidade, autenticao?) Aplica trs vezes o algoritmo DES
Garante confidencialidade das mensagens

Dado X, deve ser computacionalmente impossvel obter M sem saber K, mesmo
IDEA - International Data Encryption Algorithm - chave com 128 bits. Mtodo
conhecendo E e D
desenvolvido na Europa. Aps vrios anos de utilizao e divulgao pblica no
se conhecem ataques com xito.
Baseado em lgebra de grupos: XOR, adies e multiplicaes
Sistemas Kjh34r#36S Sistemas AES - Advanced Encryption Standard - Nova norma U.S.A. Definida por concurso
E(k,M) D(k,M)
distribudos dlm0u2dlo1 distribudos pblico, ganho por uma equipa belga. Admite chaves de 128, 192 ou 256 bits.
chave: k chave: k
DES - Data Encryption Standard Funcionamento do DES
Chave simtrica de 56 bits, blocos em claro e cifrados de 64 bits
Qual o grau de seguranga do DES ?

DES Challenge: uma frase cifrada com uma chave de 56 bits (Strong cryptography
makes the world a safer place) foi decifrada (por fora bruta) em 4 meses
Operao do DES
(cooperao internacional - 1997), e em 22 horas (1999)
Permutao inicial
http://en.wikipedia.org/wiki/DES_Challenges
no existem backdoors conhecidos 16 rounds idnticos de
Pode ser tornada mais segura aplicao de uma funo,
aplicando vrias chaves sequencialmente em cada bloco (3-DES) cada um dos quais usa 48
usando cipher-block chaining (ver mais frente) bits diferentes da chave
Permutao final
3
Criptografia assimtrica Criptografia assimtrica
Cada entidade tem duas chaves Cada entidade tem duas chaves
Chave privada (Kpriv) conhecida apenas pelo seu dono Chave privada (Kpriv) conhecida apenas pelo seu dono
Chave pblica (Kpub) pode ser conhecida por todos Chave pblica (Kpub) pode ser conhecida por todos
A partir de Kpub impossvel derivar Kpriv A partir de Kpub impossvel derivar Kpriv
Mensagem cifrada com uma chave e decifrada com a outra: Mensagem cifrada com uma chave e decifrada com a outra
E(Kpub,M) = X; D(Kpriv,X) = M E(Kpub,M) = X; D(Kpriv,X) = M

Garante o qu? (confidencialidade, autenticao?) Garante confidencialidade
Conhecendo Kpub e X deve ser computacionalmente impossvel obter M sem
E(Kpriv,M) = X; D(Kpub,X) = M saber Kpriv. S receptor conhece Kpriv.
Garante o qu? (confidencialidade, autenticao?)
E(Kpriv,M) = X; D(Kpub,X) = M
Garante autenticao do emissor
Sistemas E(k1,M) Kjh34r#36S D(k2,M) Sistemas
A partir de Kpub deve ser computacionalmente impossvel obter Kpriv. S quem
distribudos dlm0u2dlo1 distribudos possui Kpriv pode gerar X.
chave: k1 chave: k2
Algoritmo RSA (Rivest, Shamir e Adelman) Algoritmos de criptografia assimtrica mais comuns
RSA Challenge (640 bits quebrado)
http://www.rsa.com/rsalabs/node.asp?id=2093
Para gerar as chaves Exemplo simples: RSA algoritmo mais usado. Chave recomendada: 1024bits (ou mais).
Escolhem-se dois nmeros primos grandes , P=5 Baseado em nmeros primos
P e Q (P e Q > 10100) Q=11 Patente RSA expirou em 2000
N = P*Q, Z=(P-1) *(Q-1) N=55
Escolhe-se d, que pode ser qualquer nmero Z=40
menor que N que seja primo em relao a Z
Calcula-se e, que um nmero tal que e.d-1 d=3
divisvel por Z Algoritmos de curva elptica mtodo para gerar pares de chaves
e=7
A chave privada p.e. (N,e); a chave pblica pblica/privada baseado nas propriedades das curvas elpticas
(N,d) Y2 = X3 + aX + b
E(2)= 27 mod 55
Pode-se usar chaves de dimenso menor (~90bits).
A funo de cifra = 18
No est dependente da factorizao de nmeros
E((e,N), M) = Me mod N = c D(18)=183 mod 55
=2
A funo de decifra
D((d,N), c) = cd mod N = M
NOTA: Segurana do mtodo depende
da dificuldade de factorizar N em P e Q
Cifra bloco a bloco Cifra por blocos encadeados
Um algoritmo de cifra aplicado bloco a bloco pode revelar-se frgil j que Uma tcnica possvel para melhorar o mtodo usar cifra por blocos
cada bloco cifrado de forma independente pode revelar padres repetidos encadeados (CBC - cipher block chaining)
que facilitem o ataque por mtodos cripto-analticos. Durante o processo de cifra, antes de cifrar um bloco, faz-se XOR com o
Exemplo com uma imagem no comprimida: resultado da cifra anterior
Ao decifrar, aps decifrar um bloco faz-se XOR com o bloco anterior cifrado
No incio usa-se um vector de inicializao (por exemplo uma timestamp da
dimenso de um bloco) para iniciar o processo. Desta forma, o mesmo texto,
cifrado com a mesma chave, mas com vectores iniciais distintos, conduz a
resultados distintos.
Esta tcnica s se pode aplicar em canais fiveis pois a perca de uma

mensagem impede o processo de decifra.
Ou, alteraes nas mensagens so detectadas
4
Cifra por blocos encadeados Cifra de streams
plaintext plaintext plaintext Um algoritmo de cifra por blocos apenas pode cifrar bloco a bloco
vector de Quando se pretende cifrar dados de dimenso inferior a um bloco necessrio
incializao preparar um bloco que contenha os dados a enviar (padding) e cifr-lo
Alternativamente pode-se obfuscar a mensagem a transmitir (mesmo bit a bit)
usando um stream (keystream) criado a partir de um gerador de nmeros
E(K,M1) E(K,M2) E(K,M3) aleatrios (fazendo XOR)
Como decifrar a mensagem?

cyphertext cyphertext cyphertext
keystream

number
E(K, M)
buffer

generator
n+3
n+2
n+1

D(K,X1) D(K,X2) D(K,X3) XOR

ciphertext

plaintext

vector de stream

stream

incializao
plaintext plaintext plaintext

Como evitar que o receptor fique baralhado
A cifra/decifra de uma mensagem com uma chave errada, pode, apesar disso,
conduzir a um padro de bits que pode ter significado (errado) para o receptor
Problema?
Este facto pode ser usado para levar o receptor a executar disparates o que
pode ser uma fonte de insegurana
Pode ser usado para ataques de impedimento de prestao de servio tentando
saturar o receptor a processar dados aleatrios.
Soluo?
Por este motivo, necessrio introduzir bits redundantes antes de cifrar as

mensagens que impeam o receptor de ficar baralhado. As solues mais
simples so:
colocar um valor fixo pr-estabelecido, (usar formatos acordados, etc.)
colocar um nmero de ordem
colocar um CRC
Exemplo Funes de sntese seguras
Objectivo: uma funo de sntese segura H (Message Digest ou Secure Hash)

deve produzir um sequncia pequena de bits (128,160,512,...) que permita
Mensagem M: identificar uma mensagem de qualquer dimenso
Propriedades:
M = n f 1. Calcular H(M) fcil (computacionalmente)
2. Dado H(M) computacionalmente impossvel calcular M
f = F ( n, M ) ; Funo especial F como um CRC por exemplo 3. Dado M computacionalmente impossvel descobrir M2 tal que H(M) = H(M2)
Nmero de sequncia:
As funes de sntese com estas propriedades dizem-se Secure one-way hash
functions ou funes de disperso unidireccionais seguras.
M a mensagem que cifrada e transmitida. O receptor recebe M cifrada e Porqu unidireccional e seguro?
decifra o primeiro bloco. Comea logo por controlar se o mesmo contem um
nmero de sequncia vlido. Se no contiver, ignora o resto da mensagem; Para que que serve?
seno considera-a mas volta a controlar o valor de f no fim. Usado para garantir integridade dos dados
...
(os CRC no foram pensados em proteger contra ataques)
5
Funes seguras de sntese Controlo de integridade e autenticidade
com funes de sntese seguras
Funo segura de sntese MD5 possvel usar as funes de sntese para controlar a integridade num
Calcula snteses de 128 bits num processo em 4 fases canal de dados no seguro (sem cifrar). O mtodo consiste em usar
Uma das funes seguras de sntese computacionalmente mais eficientes MACs (Message Authentication Codes) que so como assinaturas,
Conhecidos ataques que permitem gerar colises. computacionalmente fceis de calcular, baseadas em chaves secretas.
O mtodo funciona assim (exemplo):
A funo SHA-1 tambm muito usada. 1. A e B estabelecem uma chave secreta K s conhecida por ambos. K pode
Norma USA. Conhecida publicamente
ser trocada aquando da autenticao, por exemplo.
Conhecidos ataques que permitem diminuir o espao de pesquisa para uma 2. Para A enviar a mensagem M a B:
coliso para O(263 ) (em vez de (280 ) ) Calcula h = H(M+K)
Est-se a migrar para SHA-2 Envia M,h
Produz uma sntese de 160 bits 3. Ao receber M,h, B calcula h=H(M+K) e verifica integridade da mensagem
se h=h
Porque que garante autenticao e integridade?
S A conhece K, logo s A consegue gerar H(M+K) autentica emissor de M e
garante que a mensagem no foi modificada
NOTA: No se est a garantir confidencialidade. K tem de ser mantida

secreta e necessrio confiana entre A e B.
Assinaturas digitais O desempenho dos diferentes mtodos
Pretende-se garantir:
Autenticidade, integridade, no repudio
Key size/hash size Extrapolated PRB optimized
1 - envia M,A,{M}KA (bits) speed (kbytes/s)
(kbytes/sec.)
Problemas: ter de conhecer KA para verificar as garantias; A e B tm de
confiar um no outro TEA 128 700 -
DES 56 350 7746
2 - envia M,A,{M}KApriv
Qualquer um verifica com KApub. Grande overhead Triple-DES 112 120 2842
IDEA 128 700 4469
3 - envia M,A,{H(M)} KApriv
Qualquer um verifica sem grande overhead RSA 512 7 -
RSA 2048 1 -
MD5 128 1740 62425
SHA 160 750 25162
Ano: 1999
Utilizao conjunta dos mtodos Exposio das chaves privadas assimtricas
Os algoritmos utilizados pelos mtodos baseados em criptografia assimtrica so Se as chaves pblicas e privadas apenas forem usadas para a autenticao e
100 a 1000 vezes mais pesados que os baseados em criptografia simtrica. Por troca de uma chave simtrica de sesso com o outro parceiro, ento:
esta razo, os dois mtodos so utilizados em conjunto. Como? 1) as chaves pblicas esto sempre expostas, mas
2) as chaves privadas s so usadas para decifrar as mensagens iniciais devendo ser
As chaves pblicas so utilizadas para autenticao e para passar uma chave de apagadas da memria imediatamente a seguir
sesso para utilizao posterior de criptografia simtrica entre os dois principais. 3) a chave de sesso tem a validade dessa sesso e nunca mais reutilizada
Exemplo:
As chaves assimtricas so geralmente de grande dimenso pelo que no

prtico memoriz-las; devem ser guardadas em suportes estveis onde, a privada
est cifrada por sua vez atravs de uma palavra chave (usando cifra simtrica de
chave secreta).
Em alternativa a chave privada pode estar gravada num carto inteligente

{Ks}KBpub, {M}Ks (smartcard) que cifra / decifra sem expor a chave secreta.
A B
6
Autenticao Autenticao
Objectivo: Bob quer que a Alice lhe demonstre a sua identidade Objectivo: Bob quer que a Alice lhe demonstre a sua identidade
Protocolo 1: Alice diz simplesmente I am Alice Protocolo 1: Alice diz simplesmente I am Alice
Segunda tentativa Segunda tentativa
Protocolo 2: Alice diz I am Alice e envia o seu endereo IP Protocolo 2: Alice diz I am Alice e envia o seu endereo IP
para o provar. para o provar.
Trudy faz IP Trudy faz IP

spoofing spoofing
Terceira tentativa Terceira tentativa
Protocolo 3: Alice diz I am Alice e envia tambm uma Protocolo 3: Alice diz I am Alice e envia tambm uma
password conhecida de Bob password conhecida de Bob
Trudy faz Trudy faz

replaying replaying
7
Variante da terceira tentativa Variante da terceira tentativa
Protocolo 3: Alice diz I am Alice e envia tambm a sua Protocolo 3: Alice diz I am Alice e envia tambm a sua
password cifrada com uma chave comum a ambos password cifrada com uma chave comum a ambos
I am Alice I am Alice
(password (password
cifrada) cifrada)
Trudy faz Trudy faz

replaying replaying
Mtodo desafio / resposta
Objectivo: evitar o ataque por replaying
Nonce: nmero usado uma nica vez
Protocolo 4: para garantir a frescura da transaco, Bob envia Alice o

nonce, R. Alice deve devolver R cifrado com a chave secreta que ambos
partilham.
8
Canais seguros
Principal A Principal B
The image cannot be The image cannot be
displayed. Your computer displayed. Your computer
may not have enough may not have enough
memory to open the image, memory to open the image,
Process p
or the image may have been
corrupted. Restart your Secure channel Process q
or the image may have
been corrupted. Restart
computer, and then open your computer, and then
the file again. If the red x open the file again. If the
still appears, you may have red x still appears, you may
have to delete the image
Objectivo: trocar dados com confidencialidade, integridade e autenticidade

(e no repdio se necessrio)
Num canal seguro os interlocutores (A e B) esto autenticados (mutuamente?)
O inimigo no pode copiar, alterar ou introduzir mensagens
O inimigo no pode reordenar as mensagens
O inimigo no pode fazer replaying de mensagens (replaying = reenvio)
(o emissor no pode negar o envio de determinada mensagem)
O canal pode basear-se em qualquer meio de comunicao: mensagens ou

conexes por rede, mensagens email, ficheiros, etc...
Criptografia
Criptografia a disciplina que inclui os princpios, meios e mtodos de

transformao dos dados com a finalidade de:
esconder o seu contedo semntico
estabelecer a sua autenticidade
impedir que a sua alterao passe despercebida
impedir a sua utilizao no autorizada.
evitar o seu repdio
Chave criptogrfica um parmetro utilizado com um algoritmo

criptogrfico para transformar, validar, autenticar, cifrar ou decifrar
dados.
1
Cifrar/decifrar
Cifrar com funo/algoritmo E() e chave/parmetro k:

E(k,M) = X tambm representvel por {M}k
Decifrar funo/algoritmo D() e chave/parmetro j:

D(j,X) = M (ou seja, verifica-se { {M}k }j = M)
No deve ser possvel, sabendo X, obter M (mesmo que se

conhea E e D)
Pode acontecer que E()=D() ou estejam relacionadas
Pode acontecer que k=j ou que estejam relacionadas
A linguagem criptogrfica (exemplo de canal cifrado)
Criptograma
Mensagem em claro
(plaintext)
{M}K {{M}K}K= M
M
Trudy no consegue passar por Alice ou Bob

No consegue obter M (mesmo em parte)
Qualquer alterao no passa despercebida
2
Criptografia clssica ex.: cdigo de Csar
Normalmente baseiam-se em cifras de substituio

Uma cifra de substituio substitui um smbolo por outro
Cdigo de Csar uma cifra de substituio para texto, considerando

A=0,B=1,etc.
E(n,x) = (x+n) mod 26
D(n,x) = (x-n) mod 26
Ex.: para n = 3, tm-se as seguintes substituies
ABCDEFGHIJKLMNOPQRSTUVWXYZ
DEFGHIJKLMNOPQRSTUVWXYZABC
E(3,SISTEMAS DISTRIBUIDOS)=VLVWHPDV GLVWULEXLGRV
Usado por Jlio Csar para cifrar mensagens militares
Como quebrar esta cifra?
Eficcia da criptografia
O algoritmo criptogrfico ser tanto melhor quanto mais difcil for obter o
texto original a partir do texto cifrado, sem se conhecer a chave. A
eficcia de um ataque depende de dois factores:
Algoritmo de cifra
Cardinalidade do domnio da chave, isto , nmero de bits da chave
Mtodos de ataque:
Fora bruta - baseia-se na explorao sistemtica de todas as
chaves possveis
Criptoanlise - baseia-se em explorar os mtodos matemticos
utilizados em criptografia para descobrir como decifrar os dados (ou
diminuir o nmero de possibilidades)
3
Fora bruta exemplo
Tentar todas as chaves no

caso do cdigo de Csar:
sabe-se que X VLVWHPDV GLVWULEXLGRV
substitudo sempre por Y
com deslocamento k 1 UKUVGOCU FKUVTKDWKFQU
Verifica-se a
descodificao obtida 2 TJTUFNBT EJTUSJCVJEPT
tentando k de 1 at 25
3 SISTEMAS DISTRIBUIDOS
Criptoanlise exemplo
Anlise dedefrequncia:
Anlise ideia
frequncia: ideia aplicada
ao cdigo de Csar:
aplicada ao cdigo de Csar:
sabe-se que X substitudo sempre
sabe-sepor que
Y X substitudo sempre
por Ysabe-se a frequncia do
sabe-seaparecimento dos diferentes
a frequncia do
smbolos no texto
aparecimento dos diferentes
smbolos no texto
Como fazer?
O smbolo mais frequente no texto
cifrado deve corresponder a um dos
smbolos mais frequentes no texto
original
Se se souber algum texto da

mensagem, pode-se usar essa
informao para inferir parte da
chave
Ataque Enigma (WWII)
4
Eficcia da criptografia
Nenhum algoritmo criptogrfico inteiramente seguro se

o nmero de bits da chave tornar um ataque fora bruta realista no
quadro de dois factores:
O valor da informao
A capacidade computacional do atacante
Se a anlise dos dados cifrados permite detectar informao
(estatistica, padres, ...) que relaciona esses dados com a
informao original
Ataques fora bruta

Supondo que possvel arranjar mil milhes (10^3 x 10^6) de computadores,
capazes de testarem mil milhes de chaves por segundo cada um, ento
possvel testar 10^18 chaves por segundo.
Uma chave de 128 bits tem cerca de 3,4 x 10^38 combinaes (10 levantado a
38). Com o poder computacional indicado, seriam necessrios 10^13 anos para
completar o ataque
Curiosidade: estima-se que a idade do universo de cerca de 10^10 anos.
Uma chave de 54 bits tem cerca de 6 x 10^16 combinaes. Com o poder

computacional indicado, seria necessrio menos de um segundo para descobrir a
chave.
Concluso: chaves geradas de forma totalmente aleatria e com um nmero de

bits suficiente so relativamente seguras quando sujeitas a ataques do tipo fora
bruta
5
A teoria e a prtica
A anlise anterior pressupe que h uma distribuio perfeita da

probabilidade de se ter seleccionado uma dada chave em todo o universo
possvel. Na prtica tais geradores perfeitos de chaves no existem e o
atacante pode, conhecendo alguma das fraquezas do gerador de chaves, ir
analisar um espao de pesquisa muito mais reduzido.
espectvel que a chave seja descoberta antes da ltima tentativa (pode

ser na 1). Em mdia ser a meio das tentativas.
Por outro lado, certas chaves so inadequadas e so facilmente quebradas

conhecendo o algoritmo usado por isso no podem ser usadas.
Ou seja, na prtica, a gerao de chaves adequadas um problema muito

delicado e os ataques de fora bruta quase nunca so realizados de forma
cega a todo o universo de chaves possveis.
Confiana nos algoritmos criptogrficos
O algoritmo criptogrfico usado deve produzir contedo com grande

entropia e sem qualquer relao com a mensagem original
No possvel provar matematicamente que um algoritmo criptogrfico

no tem falhas capazes de o tornar frgil perante ataques
criptoanalticos.
S se consegue provar exactamente o contrrio, atravs de exemplos.
A segurana de um mtodo pois baseada em o mesmo ser pblico e

ser sujeito critica e anlise por muitos especialistas.
A segurana deve ser resultado do segredo das chaves e no do segredo do
algoritmo criptogrfico
A cincia criptogrfica uma disciplina especializada.
6
A linguagem criptogrfica (exemplo: canal cifrado)

Criptograma
Mensagem em claro
(plaintext)
{M}K {{M}K}K= M
M
Criptografia de chave simtrica : as chaves de cifra e de decifra so idnticas
Criptografia de chaves assimtrica ou de chave pblica : cifra-se com a chave

pblica, decifra-se com a chave privada do receptor, ou vice-versa
7
Parceiros devem partilhar chave secreta
Mensagem cifrada e decifrada com a mesma chave

E(k,M) = X
D(k,X) = M
Que garantias d? (confidencialidade, autenticao?)
Garante confidencialidade das mensagens

Dado X, deve ser computacionalmente impossvel obter M sem saber K, mesmo
conhecendo E e D
Sistemas Kjh34r#36S Sistemas

E(k,M) D(k,M)
distribudos dlm0u2dlo1 distribudos
chave: k chave: k
Algoritmos de criptografia simtrica mais comuns
DES - Data Encryption Standard - chaves com 56 bits. Histria atribulada. Est a
cair em desuso pois a chave demasiado pequena para a potncia de clculo
actual.
Triple DES (ou TDEA) - DES reforado - chave com 112 ou 168 bits (3x56).
Aplica trs vezes o algoritmo DES
IDEA - International Data Encryption Algorithm - chave com 128 bits. Mtodo
desenvolvido na Europa. Aps vrios anos de utilizao e divulgao pblica no
se conhecem ataques com xito.
Baseado em lgebra de grupos: XOR, adies e multiplicaes
AES - Advanced Encryption Standard - Nova norma U.S.A. Definida por concurso
pblico, ganho por uma equipa belga. Admite chaves de 128, 192 ou 256 bits.
8
DES - Data Encryption Standard
Chave simtrica de 56 bits, blocos em claro e cifrados de 64 bits
Qual o grau de seguranga do DES ?

DES Challenge: uma frase cifrada com uma chave de 56 bits (Strong cryptography
makes the world a safer place) foi decifrada (por fora bruta) em 4 meses
(cooperao internacional - 1997), e em 22 horas (1999)
http://en.wikipedia.org/wiki/DES_Challenges
no existem backdoors conhecidos
Pode ser tornada mais segura

aplicando vrias chaves sequencialmente em cada bloco (3-DES)
usando cipher-block chaining (ver mais frente)
Funcionamento do DES
Operao do DES
Permutao inicial
16 rounds idnticos de
aplicao de uma funo,
cada um dos quais usa 48
bits diferentes da chave
Permutao final
9
Cada entidade tem duas chaves

Chave privada (Kpriv) conhecida apenas pelo seu dono
Chave pblica (Kpub) pode ser conhecida por todos
A partir de Kpub impossvel derivar Kpriv
Mensagem cifrada com uma chave e decifrada com a outra:
E(Kpub,M) = X; D(Kpriv,X) = M
Sistemas E(k1,M) Kjh34r#36S D(k2,M) Sistemas

distribudos dlm0u2dlo1 distribudos
chave: k1 chave: k2
Cada entidade tem duas chaves

Chave privada (Kpriv) conhecida apenas pelo seu dono
Chave pblica (Kpub) pode ser conhecida por todos
A partir de Kpub impossvel derivar Kpriv
Mensagem cifrada com uma chave e decifrada com a outra
E(Kpub,M) = X; D(Kpriv,X) = M
Garante confidencialidade
Conhecendo Kpub e X deve ser computacionalmente impossvel obter M sem
saber Kpriv. S receptor conhece Kpriv.
Garante autenticao do emissor
A partir de Kpub deve ser computacionalmente impossvel obter Kpriv. S quem
possui Kpriv pode gerar X.
10
Algoritmo RSA (Rivest, Shamir e Adelman)
RSA Challenge (640 bits quebrado)
http://www.rsa.com/rsalabs/node.asp?id=2093
Para gerar as chaves Exemplo simples:
Escolhem-se dois nmeros primos grandes , P=5
P e Q (P e Q > 10100) Q=11
N = P*Q, Z=(P-1) *(Q-1) N=55
Escolhe-se d, que pode ser qualquer nmero Z=40
menor que N que seja primo em relao a Z
Calcula-se e, que um nmero tal que e.d-1 d=3
divisvel por Z e=7
A chave privada p.e. (N,e); a chave pblica
(N,d)
E(2)= 27 mod 55
A funo de cifra = 18
E((e,N), M) = Me mod N = c D(18)=183 mod 55
=2
A funo de decifra
D((d,N), c) = cd mod N = M
NOTA: Segurana do mtodo depende
da dificuldade de factorizar N em P e Q
Algoritmos de criptografia assimtrica mais comuns
RSA algoritmo mais usado. Chave recomendada: 1024bits (ou mais).

Baseado em nmeros primos
Patente RSA expirou em 2000
Algoritmos de curva elptica mtodo para gerar pares de chaves

pblica/privada baseado nas propriedades das curvas elpticas
Y2 = X3 + aX + b
Pode-se usar chaves de dimenso menor (~90bits).
No est dependente da factorizao de nmeros
11
Cifra bloco a bloco
Um algoritmo de cifra aplicado bloco a bloco pode revelar-se frgil j que

cada bloco cifrado de forma independente pode revelar padres repetidos
que facilitem o ataque por mtodos cripto-analticos.
Exemplo com uma imagem no comprimida:
Cifra por blocos encadeados
Uma tcnica possvel para melhorar o mtodo usar cifra por blocos
encadeados (CBC - cipher block chaining)
Durante o processo de cifra, antes de cifrar um bloco, faz-se XOR com o
resultado da cifra anterior
Ao decifrar, aps decifrar um bloco faz-se XOR com o bloco anterior cifrado
No incio usa-se um vector de inicializao (por exemplo uma timestamp da
dimenso de um bloco) para iniciar o processo. Desta forma, o mesmo texto,
cifrado com a mesma chave, mas com vectores iniciais distintos, conduz a
resultados distintos.
Esta tcnica s se pode aplicar em canais fiveis pois a perca de uma

mensagem impede o processo de decifra.
Ou, alteraes nas mensagens so detectadas
12
Cifra por blocos encadeados
vector de
incializao
E(K,M1) E(K,M2) E(K,M3)
cyphertext cyphertext cyphertext
D(K,X1) D(K,X2) D(K,X3)
vector de
incializao

Cifra de streams
Um algoritmo de cifra por blocos apenas pode cifrar bloco a bloco

Quando se pretende cifrar dados de dimenso inferior a um bloco necessrio
preparar um bloco que contenha os dados a enviar (padding) e cifr-lo
Alternativamente pode-se obfuscar a mensagem a transmitir (mesmo bit a bit)
usando um stream (keystream) criado a partir de um gerador de nmeros
aleatrios (fazendo XOR)
Como decifrar a mensagem?
keystream

number
E(K, M)
buffer

generator
n+3
n+2
n+1

XOR

ciphertext

plaintext

stream

stream

13
Como evitar que o receptor fique baralhado
A cifra/decifra de uma mensagem com uma chave errada, pode, apesar disso,
conduzir a um padro de bits que pode ter significado (errado) para o receptor
Problema?
Este facto pode ser usado para levar o receptor a executar disparates o que
pode ser uma fonte de insegurana
Pode ser usado para ataques de impedimento de prestao de servio tentando
saturar o receptor a processar dados aleatrios.
Soluo?
Por este motivo, necessrio introduzir bits redundantes antes de cifrar as

mensagens que impeam o receptor de ficar baralhado. As solues mais
simples so:
colocar um valor fixo pr-estabelecido, (usar formatos acordados, etc.)
colocar um nmero de ordem
colocar um CRC
14
Exemplo
Mensagem M:
M = n f
Nmero de sequncia: f = F ( n, M ) ; Funo especial F como um CRC por exemplo
M a mensagem que cifrada e transmitida. O receptor recebe M cifrada e

decifra o primeiro bloco. Comea logo por controlar se o mesmo contem um
nmero de sequncia vlido. Se no contiver, ignora o resto da mensagem;
seno considera-a mas volta a controlar o valor de f no fim.
(os CRC no foram pensados em proteger contra ataques)
Funes de sntese seguras
Objectivo: uma funo de sntese segura H (Message Digest ou Secure Hash)

deve produzir um sequncia pequena de bits (128,160,512,...) que permita
identificar uma mensagem de qualquer dimenso
Propriedades:
1. Calcular H(M) fcil (computacionalmente)
2. Dado H(M) computacionalmente impossvel calcular M
3. Dado M computacionalmente impossvel descobrir M2 tal que H(M) = H(M2)
As funes de sntese com estas propriedades dizem-se Secure one-way hash

functions ou funes de disperso unidireccionais seguras.
Porqu unidireccional e seguro?
Para que que serve?

Usado para garantir integridade dos dados
...
15
Funes seguras de sntese
Funo segura de sntese MD5

Calcula snteses de 128 bits num processo em 4 fases
Uma das funes seguras de sntese computacionalmente mais eficientes
Conhecidos ataques que permitem gerar colises.
A funo SHA-1 tambm muito usada.

Norma USA. Conhecida publicamente
Conhecidos ataques que permitem diminuir o espao de pesquisa para uma
coliso para O(263 ) (em vez de (280 ) )
Est-se a migrar para SHA-2
Produz uma sntese de 160 bits
Controlo de integridade e autenticidade

com funes de sntese seguras
possvel usar as funes de sntese para controlar a integridade num
canal de dados no seguro (sem cifrar). O mtodo consiste em usar
MACs (Message Authentication Codes) que so como assinaturas,
computacionalmente fceis de calcular, baseadas em chaves secretas.
O mtodo funciona assim (exemplo):
1. A e B estabelecem uma chave secreta K s conhecida por ambos. K pode
ser trocada aquando da autenticao, por exemplo.
2. Para A enviar a mensagem M a B:
Calcula h = H(M+K)
Envia M,h
3. Ao receber M,h, B calcula h=H(M+K) e verifica integridade da mensagem
se h=h
Porque que garante autenticao e integridade?
S A conhece K, logo s A consegue gerar H(M+K) autentica emissor de M e
garante que a mensagem no foi modificada
NOTA: No se est a garantir confidencialidade. K tem de ser mantida

secreta e necessrio confiana entre A e B.
16
Pretende-se garantir:
Autenticidade, integridade, no repudio
1 - envia M,A,{M}KA
Problemas: ter de conhecer KA para verificar as garantias; A e B tm de
confiar um no outro
2 - envia M,A,{M}KApriv
Qualquer um verifica com KApub. Grande overhead
3 - envia M,A,{H(M)} KApriv

Qualquer um verifica sem grande overhead
O desempenho dos diferentes mtodos
Key size/hash size Extrapolated PRB optimized

(bits) speed (kbytes/s)
(kbytes/sec.)
TEA 128 700 -
DES 56 350 7746
Triple-DES 112 120 2842
IDEA 128 700 4469
RSA 512 7 -
RSA 2048 1 -
MD5 128 1740 62425
SHA 160 750 25162
Ano: 1999
17
Utilizao conjunta dos mtodos
Os algoritmos utilizados pelos mtodos baseados em criptografia assimtrica so

100 a 1000 vezes mais pesados que os baseados em criptografia simtrica. Por
esta razo, os dois mtodos so utilizados em conjunto. Como?
As chaves pblicas so utilizadas para autenticao e para passar uma chave de

sesso para utilizao posterior de criptografia simtrica entre os dois principais.
Exemplo:
{Ks}KBpub, {M}Ks
A B
Exposio das chaves privadas assimtricas
Se as chaves pblicas e privadas apenas forem usadas para a autenticao e

troca de uma chave simtrica de sesso com o outro parceiro, ento:
1) as chaves pblicas esto sempre expostas, mas
2) as chaves privadas s so usadas para decifrar as mensagens iniciais devendo ser
apagadas da memria imediatamente a seguir
3) a chave de sesso tem a validade dessa sesso e nunca mais reutilizada
As chaves assimtricas so geralmente de grande dimenso pelo que no

prtico memoriz-las; devem ser guardadas em suportes estveis onde, a privada
est cifrada por sua vez atravs de uma palavra chave (usando cifra simtrica de
chave secreta).
Em alternativa a chave privada pode estar gravada num carto inteligente

(smartcard) que cifra / decifra sem expor a chave secreta.
18
Autenticao
Objectivo: Bob quer que a Alice lhe demonstre a sua identidade
Protocolo 1: Alice diz simplesmente I am Alice
Autenticao
Objectivo: Bob quer que a Alice lhe demonstre a sua identidade
Protocolo 1: Alice diz simplesmente I am Alice
19
Segunda tentativa
Protocolo 2: Alice diz I am Alice e envia o seu endereo IP

para o provar.
Trudy faz IP
spoofing
Segunda tentativa
Protocolo 2: Alice diz I am Alice e envia o seu endereo IP

para o provar.
Trudy faz IP
spoofing
20
Terceira tentativa
Protocolo 3: Alice diz I am Alice e envia tambm uma

password conhecida de Bob
Trudy faz
replaying
Terceira tentativa
Protocolo 3: Alice diz I am Alice e envia tambm uma

password conhecida de Bob
Trudy faz
replaying
21
Variante da terceira tentativa
Protocolo 3: Alice diz I am Alice e envia tambm a sua

password cifrada com uma chave comum a ambos
I am Alice
(password
cifrada)
Trudy faz
replaying

I am Alice
(password
cifrada)
Trudy faz
replaying
22

partilham.
23
Variante da terceira tentativa Mtodo desafio / resposta

password cifrada com uma chave comum a ambos Nonce: nmero usado uma nica vez

I am Alice
(password partilham.
cifrada)
Trudy faz
replaying
Problemas e possveis solues Distribuio de chaves de sesso atravs de um

Key Distribution Center primeira tentativa
Apesar de a chave secreta no necessitar de passar na rede durante a

autenticao, Alice e Bob tm de arranjar alguma forma de se porem
previamente de acordo sobre a chave secreta a usar (sem a trocar em Problema:
Problemas?
claro pela rede): KDC Como que o Bob
1. Acordando a chave previamente (p.e. trocando-a em mo) pode ter a certeza
2. Usando uma terceira pessoa/entidade para trocarem a chave
que est a falar com
Se isso se revelar um mtodo complexo, vo ter tendncia a manter a 1) Eu sou a Alice e quero
mesma chave durante muito tempo, o que perigoso. falar com o Bob a Alice?
2) {Ks}Ka, {Ks}Kb
Uma Soluo:
usar uma chave diferente em cada sesso
usar um centro de distribuio dessas chaves no qual Alice e Bob confiam e
com o qual j partilham chaves
Alice Bob
3) {M}Ks {Ks}Kb
Distribuio de chaves de sesso atravs de um KDC Distribuio de chaves de sesso atravs de um KDC
segunda tentativa segunda tentativa
Problema: Problema:
KDC
Como que Bob Bob KDC
Pode Trudy obter o
1) Eu sou a Alice e quero pode ter a certeza 1) Eu sou a Alice e quero contedo da
falar com o Bob que est a falar com falar com o Bob mensagem?
Alice? No, porque apenas
Por Alice ter sido Bob conhece Kb. Mas
2) { {A, Ks}Kb, Ks }Ka capaz de obter 2) { {A, Ks}Kb, Ks }Ka Trudy pode gravar a
{A,Ks}Kb. S Alice mensagem e mais
conhece Ka tarde tentar
incomodar Bob.
Alice Bob Alice Bob
3) {M}Ks, {A, Ks}Kb 3) {M}Ks, {A, Ks}Kb
1
Protocolo de Needham-Schroeder O protocolo NS com chaves simtricas
(terceira tentativa)
Este protocolo permite a dois principais A e B (Alice e Bob) estabelecerem um 1) A -> KDC: A, B, Na
canal seguro entre si e autenticarem-se mutuamente. A solicita uma chave para comunicar com B, sendo Na um nmero aleatrio gerado
por A para garantir a unicidade da transaco (Na deve ser nico. Porqu?).
2) KDC -> A: { Na, B, Ks, { Ks, A }Kb }Ka

Baseia-se na presena de um KDC (Key Distribution Center) que conhece as O KDC devolve Na, a chave e um ticket ({ Ks, A }Kb), tudo cifrado com a chave de A.
chaves secretas de A e B (Ka e Kb) e que capaz de gerar chaves de sesso (Ks)
que vo ser usadas por A e B para comunicarem de forma segura. 3) A -> B: {Ks, A}Kb, {Na}Ks
Passa a fazer parte da trusted computing base A solicita comunicar com B, enviando-lhe o ticket
4) B -> A: {Na-1}Ks
O protocolo resiste aos ataques eavesdropping, masquerading, message

tampering e replaying.
(base do protocolo do Kerberos)
O protocolo NS com chaves simtricas O protocolo NS com chaves simtricas
1) A -> KDC: A, B, Na 1) A -> KDC: A, B, Na

A solicita uma chave para comunicar com B, sendo Na um nmero aleatrio gerado A solicita uma chave para comunicar com B, sendo Na um nmero aleatrio gerado
por A para garantir a unicidade da transaco (Na deve ser nico). por A para garantir a unicidade da transaco (Na deve ser nico).
2) KDC -> A: { Na, B, Ks, { Ks, A }Kb }Ka 2) KDC -> A: { Na, B, Ks, { Ks, A }Kb }Ka
O KDC devolve Na, a chave e um ticket ({ Ks, A }Kb), tudo cifrado com a chave de A.
A recepo do Na nico cifrado com Ka garante que A comunicou com o KDC s o
O que garante a A ter falado com o KDC ? KDC conhece Ka, logo s KDC pode gerar a mensagem indicada.
3) A -> B: {Ks, A}Kb, {Na}Ks 3) A -> B: {Ks, A}Kb, {Na}Ks
A solicita comunicar com B, enviando-lhe o ticket A solicita comunicar com B, enviando-lhe o ticket
O que garante a B estar a falar com A ?
4) B -> A: {Na-1}Ks
4) B -> A: {Na-1}Ks
O protocolo NS com chaves simtricas O protocolo NS com chaves simtricas
1) A -> KDC: A, B, Na 1) A -> KDC: A, B, Na

A solicita uma chave para comunicar com B, sendo Na um nmero aleatrio gerado A solicita uma chave para comunicar com B, sendo Na um nmero aleatrio gerado
por A para garantir a unicidade da transaco (Na deve ser nico). por A para garantir a unicidade da transaco (Na deve ser nico).
2) KDC -> A: { Na, B, Ks, { Ks, A }Kb }Ka 2) KDC -> A: { Na, B, Ks, { Ks, A }Kb }Ka
O KDC devolve Na, a chave e um ticket ({ Ks, A }Kb), tudo cifrado com a chave de A. O KDC devolve Na, a chave e um ticket ({ Ks, A }Kb), tudo cifrado com a chave de A.
A recepo do Na nico cifrado com Ka garante que A comunicou com o KDC s o A recepo do Na nico cifrado com Ka garante que A comunicou com o KDC s o
KDC conhece Ka, logo s KDC pode gerar a mensagem indicada. KDC conhece Ka, logo s KDC pode gerar a mensagem indicada.
3) A -> B: {Ks, A}Kb, {Na}Ks 3) A -> B: {Ks, A}Kb, {Na}Ks

A solicita comunicar com B, enviando-lhe o ticket A solicita comunicar com B, enviando-lhe o ticket
B sabe que est a falar com A, porque apenas A pode obter Ks associada a um ticket B sabe que est a falar com A, porque apenas A pode obter Ks associada a um ticket
indicando A (porque Ks passa cifrado com Ka em 2)). Alm disso, impossvel forjar indicando A (porque Ks passa cifrado com Ka em 2)). Alm disso, impossvel forjar
um ticket, porque s B e KDC conhecem Kb um ticket, porque s B e KDC conhecem Kb
4) B -> A: {Na-1}Ks 4) B -> A: {Na-1}Ks

O que garante a A estar a falar com B ? B prova ser B por ser capaz de decifrar {Na}Ks, o que pressupe ter sido capaz de
decifrar {Ks, A}Kb
Porque no pode B enviar {Na}Ks ?
2
Um possvel ataque e respectiva soluo Autenticao via chave pblica
A mensagem 3) pode ser replayed mais tarde. Isso, em princpio, no tem Problema: como que a Alice se autentica utilizando chaves assimtricas?
problema mas se por acaso Ks for um dia comprometida, ento Trudy pode
conseguir autenticar-se perante Bob como se fosse Alice. A soluo consiste em soluo: usa desafio/resposta, e criptografia assimtrica
acrescentar uma timestamp ao ticket que deve ser testada por Bob aps ter
recebido a mensagem 3). Tal exige que os relgios de A, B e do KDC estejam 1 tentativa:
sincronizados a menos de um valor considerado suficiente para tornar impossvel
a quebra da chave Ks em tempo til.
O protocolo fica:
1) A -> KDC: A, B, Na
2) KDC -> A: { Na, B, Ks, { Ks, A, t }Kb }Ka
3) A -> B: {Ks, A, t}Kb, {Na}Ks KApriv(R)
4) B -> A: {Na-1}Ks KApub( KApriv(R) ) == R
Protocolo de Needham-Schroeder com chaves Protocolo de Needham-Schroeder com chaves

pblicas pblicas
Pressupondo que A e B conhecem as chaves pblicas um do outro, podem Se A apenas quiser criar um canal cifrado e ter a certeza de que est a falar com
estabelecer um canal seguro e autenticarem-se mutuamente atravs de: B basta:
1. A -> B: { A, Na }KBpub A -> B: { A, Na, Ks }KBpub
2. B -> A: { Na, Nb, Ks } KApub B -> A: { Na } Ks
3. A -> B: { Nb } Ks
O que garante a A estar a falar com B?
Receber Na em 2 apenas B consegue obter Na, porque apenas B tem KBpriv
O que garante a B estar a falar com A?
Receber Nb em 3 apenas A consegue obter Nb, porque apenas A tem KApriv
Criptografia assimtrica lenta. Como solucionar o problema durante a comunicao?
Negoceia chave simtrica (Ks) para usar durante a comunicao
O que garante que Ks seguro?
Ks apenas passa na rede em 2 apenas A consegue obter Ks, porque apenas A tem KApriv
(B conhece Ks porque gerou Ks)
Como distribuir as chaves pblicas? Ataques por interposio
So necessrias chaves pblicas

certificadas
3
Centro de distribuio de chaves pblicas Vantagens face criptografia simtrica
PKC = Public Key Center So possveis ataques O Public Key Center (PKC) apenas conhece aquilo que pblico, isto , as
por interposio? chaves pblicas dos principais. Tal um progresso notvel pois o papel da
trusted computing base foi drasticamente reduzido.
PKC
Qual a chave pblica
de B ?
Qual a chave pblica Para que tudo funcione bem apenas necessrio assegurar que o PKC tem as
de A ? chaves pblicas verdadeiras e que os principais tm a certeza que esto a falar
com o verdadeiro PKC e no com um impostor.
KBpub KApub
necessrio ter absoluta segurana de que se est a dialogar com uma fonte
A -> B: { A, Na }KBpub fidedigna que nos est a entregar a verdadeira chave pblica que pretendemos
A B Se se conhece a chave pblica dessa fonte fidedigna, uma forma de obter esta
confiana essa fonte cifrar a sua resposta com a sua chave secreta
B -> A: { Na, Nb, Ks } KApub
A -> B: { Nb } Ks
Distribuio das chaves pblicas Assinaturas digitais
Nos protocolos anteriores, um intruso que se consiga fazer passar pelo PKC, Objectivo: desenvolver um mecanismo digital que substitua as assinaturas
consegue levar A e B a usarem chaves conhecidas efectuadas num documento em papel
So necessrias chaves pblicascertificadas (ou assinadas) Quais as propriedades?
Mtodos de distribuio de chaves: Um sistema de assinaturas digitais deve ter as seguintes propriedades:
Certificate Granting Authority entidades cujas chaves pblicas so bem Autenticao: o receptor deve poder verificar que a assinatura autentica
conhecidas e que assinam as chaves / certificados que entregam. Este mtodo est Integridade: a assinatura deve garantir que a mensagem assinada no foi alterada,
hoje em dia normalizado de forma oficial. nem durante o trajecto, nem pelo receptor, mesmo que tenha passado em claro
Web of trust - mtodo informal por transitividade da relao de confiana, tambm No repudiamento: o emissor no poder negar que de facto enviou a mensagem
suportado na assinatura das informaes trocadas entre principais. Este mtodo assinada
tem sido vulgarizado pelo programa PGP para troca de correio electrnico.
NOTA: O objectivo das assinaturas no esconder o contedo
Assinaturas digitais com chaves simtricas (MACs)
Sendo H() uma funo de sntese segura e K uma chave pr-acordada

M signed doc
H(M+K) h
Bob envia uma mensagem com
Assinatura
uma assinatura digital:
M M, H(M+K)
K
Alice verifica a autenticidade M

e integridade da mensagem: h
H(M+K) recebido =
Verificao
H(M+K) computado ? h = h'?
H(M+K) h'
K
4
Assinatura digital soluo com chaves simtricas Assinatura digital com chaves assimtricas:
(MACs) primeira tentativa
Assinatura digital da mensagem M efectuada por Bob: h=H(M+K) Assinatura digital da mensagem M efectuada por Bob: {M}KBpriv
Mensagem a enviar: M,h
H(M): funo de sntese segura
Propriedades:
Verificao ao receber M, h, calcula H(M+K) = h
Autenticao, integridade garantidos porque apenas B consegue criar H(M+K) e
ningum consegue alterar M para M de forma que H(M+K)=H(M+K)
O no repdio limitado pois a verificao exige conhecer K, e conhecendo K pode-se
falsificar a assinatura Propriedades:
Autenticao verificada decifrando M = {{M}KBpriv}KBpub
Integridade e no repudiamento garantidos porque ningum consegue alterar/criar
{M}KBpriv sem conhecer KBpriv
Dimenso da assinatura idntica do documento Soluo?

Necessidade de cifrar todo o documento com chaves assimtricas
Utilizao de assinaturas digitais com chaves pblicas Assinatura digital: soluo com chaves pblicas
M signed doc Bob envia uma mensagem Assinatura digital da mensagem M efectuada por Bob: {H(M)}KBpriv
com uma assinatura digital: Mensagem a enviar: M,{H(M)}KBpriv
H(M) h E(Kpri , h) {h}Kpri
Assinatura H(M): funo de sntese segura
M,{H(M)}KBpriv
128 bits M
Propriedades:
Verificao ao receber M,{H(M)}KBpriv : H(M) = {{H(M)}KBpriv}KBpub
Autenticao, integridade e no repudiamento garantidos porque apenas B consegue
criar {H(M)}KBpriv e ningum consegue alterar M para M de forma que H(M)=H(M)
{h}Kpri
Dimenso da assinatura pequena e constante
D(Kpub ,{h}) h' Apenas assinatura cifrada mensagem at pode passar em claro
Qualquer um pode verificar a assinatura
Verificao M
h = h'?
Alice verifica a autenticidade e
h
a integridade da mensagem: H(doc)
H(M) = {H(M)}KBpriv}KBpub ?
Certificados de chaves pblicas Exemplo
A segurana baseada em chaves pblicas depende da validade das chaves

pblicas.
Objectivo: estabelecer a autenticidade e integridade de uma chave pblica (p.e.

por declarao de uma entidade fidedigna) chave pblica certificada
Um certificado contm informao assinada/certificada de pelo menos o nome e

chave pblica duma entidade. Exemplo:
1. Certificate type
: Public key
2. Name Bobs Bank
3. Public key
: KBpub
4. Certifying authority
: Fred The Bankers Federation
5. Signature
: {Digest(field 2 + field 3)}KFpriv
5
Exemplo Autoridades de certificao
Uma certification authority (CA)

associa chaves pblicas a principais
Em geral, os chaves pblicas
(certificados) das CAs so bem-
conhecidos
Quando a Alice quer verificar qual a

chave do Bob:
1) obtm um certificado dessa chave
(at Bob o pode enviar!).
2) verifica autenticidade do certificado
verificando a assinatura efectuada
pela CA (usando chave pblica da
CA)
Certificados X.509 Repudiamento e validade de uma chave
Quando uma chave privada comprometida necessrio revogar a

chave pblica que lhe estava associada. Quando se utilizam certificados,
necessrio que as entidades de certificao memorizem os certificados
vlidos e os revogados.
Entidade Nome identificativo, chave pblica Quando se utiliza um certificado devia-se verificar se o mesmo continua
vlido ou se foi revogado.
Emissor Nome identificativo, assinatura
Perodo de validade Data de incio, data de fim Quando uma chave privada comprometida impossvel garantir a
autenticidade de qualquer mensagem
Informao administrativa Verso, nmero de srie Mesmo as anteriormente emitidas (pode ou no ser um problema)
Informao adicional
Assim, a utilizao de certificados por si s no uma panaceia universal.
Algoritmo de Diffie-Hellman Segurana futura perfeita
Alice e Bob pretendem trocar entre si um senha ou chave de sesso (Ks) sem que Um protocolo de distribuio de chaves de sesso diz-se que garante segurana
esta passe na rede (nota: autenticao no objectivo) futura perfeita se no envolve segredos de longa durao que, uma vez
Se as chaves privadas forem comprometidas no futuro, os dados desta sesso comprometidos no futuro, permitiriam conhecer uma sesso do passado.
continuam seguros
Nos algoritmos NS (e similares), se uma chave secreta/privada for comprometida
Sejam dois nmeros aleatrios (grandes) m e n que so parmetros pblicos do possvel obter as chaves secretas negociadas com base nessa chave para uso
algoritmo ( melhor n ser primo e m ser tal que (m-1)/2 primo): nas comunicaes
1) A gera um nmero secreto Xa e calcula: Ya = m^Xa mod n Trudy pode ficar a conhecer o contedo das mensagens trocadas para todas as
2) B gera um nmero secreto Xb e calcula: Yb = m^Xb mod n sesses que tenha gravado
3) A e B trocam entre si Ya e Yb (valores pblicos passados em claro) Os segredos so de longa durao
4) A calcula Ka = Yb^Xa mod n
5) B calcula Kb = Ya^Xb mod n No algoritmo Diffie-Hellman, se a Alice e o Bob usarem valores aleatrios de Xa e
Xb, que no voltem a ser usados, a chave nica e foi obtida sem recurso a
segredos de longa durao
Comprova-se que Ks = Ka = Kb e que computacionalmente impossvel calcular Sabendo m, n, Ya e Yb no possvel obter Ks
Xa ou Xb a partir de Ya ou Yb, isto , est-se a usar uma funo sem inverso Xa, Xb, e logo Ks, so segredos apenas enquanto dura a sesso: depois podem
(one-way function). (devem) ser descartados
E.g. m = 5; n = 23;
Xa = 3; Ya= 10; Xb =4; Yb = 4
Ka = 4^3 mod 23 = 18 Kb = 10^4 mod 23 = 18
6
Casos de estudo
Kerberos
SSL
PGP
O sistema Kerberos O sistema Kerberos
Sistema desenvolvido no MIT para fornecer servios de autenticao e

Kerberos Key Distribution Centre
segurana numa organizao
Usa uma variante do protocolo Needham-Schroeder com criptografia Authentication
Step A database
simtrica Authen- Ticket-
tication granting
1. Request for
service A service T
Servidor Kerberos TGS ticket
Servio de autenticao 2. TGS

ticket
Permite autenticar um cliente no sistema
Step B
Servio de autenticao conhece chave secreta (simtrica) de todos os 3. Request for
utilizadores e do TGS server ticket
Login Step C
Servio de tickets para servidores (TGS ticket granting service) session setup
4. Server ticket
5. Service
Permite obter um ticket para aceder a um servio request
Server
Servio de tickets conhece chaves secretas (simtricas) de todos os servidores Client session setup Service Server
C Request encrypted with session key function
S
DoOperation
Reply encrypted with session key
O protocolo Kerberos verso 5.0 O protocolo Kerberos verso 5.0
Autenticao no sistema Autenticao no sistema

A -> AS: A, TGS, n1 A -> AS: A, TGS, n1
Cliente (A) pede para fazer login no sistema Cliente (A) pede para fazer login no sistema
AS -> A: { Ks, n1}Ka, {A,TGS, t1, t2, Ks}Ktgs AS -> A: { Ks, n1}Ka, {A,TGS, t1, t2, Ks}Ktgs
Servio de autenticao devolve ticket, vlido de t1 at t2, e chave que permite Servio de autenticao devolve ticket, vlido de t1 at t2, e chave que permite
falar com TGS falar com TGS
O que garante a A estar a falar com AS? O que garante a A estar a falar com AS?
A recepo de {n1...}Ka garante a A que est a falar com AS (pois s AS conhece
O que garante ao AS estar a falar com A? tambm Ka) e que no existe replaying (n1 um nonce)
O que garante ao AS estar a falar com A?
Nada, mas apenas A pode usar informao recebida para as fases seguintes do
protocolo por ser o nico a conhecer Ka
7
O protocolo Kerberos verso 5.0 (cont.) O protocolo Kerberos verso 5.0 (cont.)
Obteno de ticket para aceder a servio Obteno de ticket para aceder a servio
A -> TGS: {A, TGS, t1, t2, Ks}Ktgs, {A, t3}Ks, B, n2 A -> TGS: {A, TGS, t1, t2, Ks}Ktgs, {A, t3}Ks, B, n2
Cliente pede a TGS ticket para aceder ao servidor B Cliente pede a TGS ticket para aceder ao servidor B
TGS -> A: {B, n2, Kab}Ks, {A, B, t1, t2, Kab}Kb TGS -> A: {B, n2, Kab}Ks, {A, B, t1, t2, Kab}Kb
TGS devolve chave (Kab) e um ticket para A aceder ao servio B TGS devolve chave (Kab) e um ticket para A aceder ao servio B
O que garante a A estar a falar com TGS? O que garante a A estar a falar com TGS?
A recepo de {n2...}Ks garante a A que est a falar com TGS (pois s TGS
O que garante a TGS estar a falar com A? consegue obter Ks) e que no existe replaying (n2 um nonce)
O que garante a TGS estar a falar com A?
Autenticador {A, t3}Ks autentica A perante TGS por demonstrar que A conhece
Ks. Time-stamp (t3) impede replaying desta mensagem.
NOTA: Ka apenas usada na autenticao. A partir desse momento, o ticket
enviado pelo AS permite ao cliente comunicar de forma segura e autenticar-se no
TGS
O protocolo Kerberos verso 5.0 (cont.) O protocolo Kerberos verso 5.0 (cont.)
Acesso ao servio Acesso ao servio

A -> B: {A, t3}Kab, {A, B, t1, t2, Kab}Kb, n3 A -> B: {A, t3}Kab, {A, B, t1, t2, Kab}Kb, n3
Cliente pede para se autenticar com o servidor Cliente pede para se autenticar com o servidor
B -> A: {n3}Kab B -> A: {n3}Kab
Cliente verifica autenticidade do servidor. A partir deste momento, cliente e Cliente verifica autenticidade do servidor. A partir deste momento, cliente e
servidor podem usar Kab para comunicarem de forma segura. servidor podem usar Kab para comunicarem de forma segura.
O que garante a A estar a falar com B? Como se evita o replaying? O que garante a A estar a falar com B? Como se evita o replaying?
Apenas B pode produzir {n3}Kab, porque apenas B consegue obter Kab a partir
O que garante a B estar a falar com A? Como se evita o replaying? do ticket. Replaying evitado por n3 ser um nonce.
O que garante a B estar a falar com A? Como se evita o replaying?
Apenas A conhece Kab, logo s A pode produzir {A,t3}Kab. t3 um timestamp
usado para evitar replaying.
Notas sobre o protocolo Kerberos v. 5.0 Vantagens da variante Kerberos sobre o protocolo
Needham-Schroeder simples
Os valores de t1, t1, t2, t2, t3, t3 so estampilhas temporais geradas a partir do O AS conhece as senhas / chaves / passwords de todos os clientes mas estas s
relgio (que se pressupem estar fracamente sincronizados) so usadas para autenticar inicialmente os clientes
Permite aplicar tempo limite a tickets, revogando autorizaes dadas A senha / chave / password do cliente (que usa workstations avulso) s est na
Permite proteco contra replaying de mensagens antigas (ou utilizao indevida de memria das mesmas durante alguns milisegundos
tickets encontrados em memria)
Os tickets tm uma durao limitada (tanto com o TGS como com os servidores)
Validade dos tickets geralmente de algumas horas
Clientes devem obter novos tickets quando termina a validade dos tickets obtidos. Permite interromper o servio a clientes a quem tenha sido cancelado o registo
O TGS apenas tem de conhecer os servidores e emitir chaves de sesso (repare-
Clientes devem obter um ticket para cada servidor que queiram contactar. se que os clientes so muito mais numerosos que os servidores)
Quando se usa um sistema tipo Kerberos, quais as diferentes formas de controlo

de acessos executadas?
8
SSL - Secure Socket Layer O protocolo SSL
Trata-se de um protocolo proposto e desenvolvido pela Netscape, do tipo sesso, O protocolo SSL funciona por cima do Autenticao do servidor:
isto sobre o nvel transporte, que permite estabelecer canais seguros e nvel de transporte e permite fornecer O cliente (browser) inclui as chaves
autenticar clientes e servidores. Hoje em dia trata-se de uma norma IETF. segurana a qualquer aplicao pblicas de vrias CAs
baseada em TCP O cliente solicita ao servidor um
certificado do servidor emitido por uma
usado entre browsers e servidores CA em que ele confie.
WWW (https). O cliente verifica o certificado do
Canal seguro servidor com a chave pblica da CA
Conexo TCP Funcionalidades de segurana:
autenticao do servidor Autenticao do cliente:
cifra e integridade dos dados Processa-se de forma semelhante
autenticao do cliente (opcional)
Veja no seu browser na seco de

segurana.
Cliente Servidor
Certificado CLIP
Certificado CLIP Certificado Moodle@FCT
Assinado pela Multicert Certificado emitido localmente

Empresa de certificao nacional:
SIBS,CTT,INCM,PTPrime Que garantias fornece?
9
Protocolos SSL
SSL

Handshake
SSL Change
SSL Alert
HTTP
Telnet

protocol
Cipher Spec
Protocol

SSL Record Protocol

Transport layer (usually TCP)

Network layer (usually IP)

SSL protocols:
Other protocols:

SSL Record Protocol: implementa canal seguro, cifrando e autenticando as

mensagens
SSL Handshake protocol + SSL CCS + SSL AP: estabelecem e mantm um canal
seguro entre um cliente e um servidor
SSL handshake protocol SSL handshake configuration options

Transport handshake
Establish protocol version, session ID, Component Description Example

ClientHello
cipher suite, compression method,
ServerHello exchange random start values Key exchange the method to be used for RSA with public-key
method exchange of a session key certificates
Certificate
Optionally send server certificate and
Cipher for data the block or stream cipher to be IDEA
Certificate Request
request client certificate transfer used for data
ServerHelloDone
Message digest for creating message SHA
Client Certificate Server
function authentication codes (MACs)
Send client certificate response if
A Certificate Verify B requested
SSL permite usar diferentes Cipher Suites. Durante o handshake o cliente indica quais tem
disponveis e o servidor selecciona um.
Change Cipher Spec
Change cipher suite and finish Autenticao do servidor: servidor envia certificado e cliente envia premaster secret cifrado
Finished com a chave pblica do servidor
handshake
Premaster secret usado para gerar as chaves de cifra (uma para cada sentido) e a chave a usar
Change Cipher Spec
no MAC
Finished
Autenticao do cliente: cliente envia certificado e cliente envia assinatura de parte das
mensagens trocadas
DATA Application data
Material de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 57 * Material de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 58
SSL record protocol Pretty good privacy (PGP)
Esquema de cifra e assinatura de e- Exemplo de uma mensagem assinada com PGP:

mail.
Application data abcdefghi
Trata-se de uma norma de facto. ---BEGIN PGP SIGNED MESSAGE--
Hash: SHA1
Fragment/combine
Utiliza criptografia simtrica,
Record protocol units abc def ghi criptografia assimtrica, funes de Bob,
hash seguras e assinaturas digitais. My husband is out of town tonight.
Passionately yours,
Compress
Fornece autenticao, secretismo, Alice
Compressed units integridade e no repudiamento.
---BEGIN PGP SIGNATURE---
Version: PGP 5.0
Hash
MAC O inventor, Phil Zimmerman, foi alvo de yhHJRHhGJGhgg/12EpJ
um processo legal nos EUA durante 3 +lo8gE4vB3mqJhFEvZP9t6n7G6m5Gw2
Encrypt anos. ---END PGP SIGNATURE---
Encrypted
Transmit
TCP packet
10
Funcionamento do PGP (exemplo com SHA1 e IDEA) Funcionamento do PGP O que garante que s o
receptor (B) pode ler a
Envio da mensagem M de A para B assinada e cifrada: mensagem?
1.Produz assinatura A mensagem cifrada com Ks,
digital de M, com chave Ks 4. Cifra Ks com chave Ks
RSA RSA
privada do emissor: pblica do receptor: logo s quem conhea Ks pode
{SHA1(M)}KApriv {Ks}KBpub decifrar a mensagem.
SHA1 RSA SHA1 RSA
Compresso Compresso Ks cifrada com KBpub, logo
s B pode obter Ks, porque s
5. Resultado de 3+4 so B conhece KBpriv
M
(a) (b) (c) concatenados e codificados M
(a) (b) (c)
em ASCII 7 bits usando o O que garante ao receptor (B)
IDEA Base 64 mtodo base64. O resultado IDEA Base 64
que foi o emissor (A) que
enviado atravs de correio
2. Comprime M+{SHA1(M)}KApriv 3. Gera Ks e cifra electrnico. enviou a mensagem?
resultado de 2 com Ks
( a ) M, { SHA1(M) } KApriv
(algoritmo IDEA)
( a ) M, { SHA1(M) } KApriv Apenas o emissor pode
( b ) { M, { SHA1(M) } KApriv } Ks ( b ) { M, { SHA1(M) } KApriv } Ks produzir a assinatura digital da
mensagem, porque apenas A
( c ) { M, { SHA1(M) } KApriv } Ks , { Ks } KBpub ( c ) { M, { SHA1(M) } KApriv } Ks , { Ks } KBpub
conhece KApriv
Funcionamento do PGP Distribuio de chaves em PGP
1. Produz assinatura da mensagem M. Seja M a mensagem a enviar, H a funo O programa PGP vulgarizou um mtodo de distribuio de chaves dito Web of
de hash seguro, e KApriv a chave privada de A, a assinatura gerada {H(M)} Trust que consiste em cada pessoa adquirir as chaves pblicos dos interlocutores
KApriv. atravs de outras pessoas em quem tem confiana, ou atravs de servidores
pblicos.
2. A concatenao da mensagem M com a assinatura comprimida PGP fornece um mtodo de assinatura de chaves para que cada principal possa
assinar as chaves que envia a quem confia nele (que j conhece a sua chave ou
3. Uma chave secreta Ks ento gerada e o resultado de 2) cifrado com a chave chaves pblicas).
Ks. Para fazer bootstrap da Web of trust utilizam-se mtodos administrativos que
ultrapassam o mbito da problemtica criptogrfica, nomeadamente relacionados com
4. Ks cifrada com a chave pblica do receptor, KBpub. a forma como as chaves so depositadas no servidor de chaves pblicas.
Cada utilizador pode ter vrias chaves privadas (private key ring) e dispe de um
5. O resultado de 4) e 5) so concatenados e codificados em ASCII 7 bits pelo
directrio de chaves pblicas de terceiros (public key ring) classificadas por grau
mtodo base 64. de confiana da fonte que forneceu a chave.
6. O resultado de 5) pode ser enviado atravs de correio electrnico. As chaves podem ter 512 (utilizao casual), 1024 (utilizao comercial) ou 2048 bits
(utilizao segura).
Resumo Ideia base
Estabelecimento de canal cifrado

Criptografia simtrica Algoritmo Needham-
Parceiros devem partilhar segredo
KDC Schroeder
Parceiros devem partilhar segredo com terceira entidade (KDC) (mas no
1) Eu sou a Alice e quero
necessariamente entre si) falar com o Bob
Criptografia assimtrica A, B, Na
Parceiros necessitam de conhecer chave pblica do parceiro
Parceiros podem conhecer chave pblica de terceira entidade (PKC) que assina
chave pblica das entidades
Usada geralmente para negociar chave de sesso simtrica, com a qual os
2) { {A, Ks}Kb, Ks, B, Na }Ka
dados so transmitidos
Alice 3) {Nb}Ks, {A, Ks}Kb Bob

{Nb-1}Ks
4) {M}Ks
11
Ideia base Ideia base
PKC = Public Key Center

PKC
Qual a chave pblica
de B ?
CertB
A B
{Ks}KBpub, {M}Ks
CertB
Verifica validade de CertB,

com base nos certificados
{Ks}KBpub, {M}Ks das CA que conhece
A B

com base na chave publica S est a autenticar B S est a autenticar B
de PKC que conhece
Resumo Resumo
Estabelecimento de canal cifrado Autenticao dos parceiros (ideia base: desafio)

Criptografia simtrica Criptografia simtrica
Parceiros devem partilhar segredo Capacidade de decifrar mensagem cifrada com chave secreta
Parceiros devem partilhar segredo com terceira entidade (KDC) (mas no Criptografia assimtrica
necessariamente entre si) Capacidade de cifrar mensagem com chave privada
Criptografia assimtrica Capacidade de decifrar mensagem cifrada com chave pbica
Diffie-Hellman
Permite estabelecer canal cifrado entre dois parceiros sem trocar uma chave
sesso (mas no os autentica)
Resumo Para saber mais
Garantia de integridade e autenticidade das mensagens Bibliografia base

Assinaturas digitais baseadas em chaves assimtricas G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems - Concepts
MACs and Design, Addison-Wesley, 4th Edition, 2005
Captulo 7
Bibliografia adicional:
James F. Kurose and Keith W. Ross, "Computer Networking - A Top-Down Approach Featuring the
Internet, Addison Wesley Longman, Inc., Second Edition, 2003 captulo 7.
Tanenbaum and Maarten van Steen Distributed Systems Principles and Paradigms, Prentice-
Hall, 2002 captulo 8.
W. Stallings, Cryptography and Network Security Principles and Practice, Second Edition 1999
Este livro integralmente dedicado a este tpico.
Codificao da Informao (1 ciclo)
Segurana em Sistemas e Redes de Computadores (2 ciclo)
12

I am Alice
(password
cifrada)
Trudy faz
replaying

partilham.
1
Problemas e possveis solues
Apesar de a chave secreta no necessitar de passar na rede durante a

autenticao, Alice e Bob tm de arranjar alguma forma de se porem
previamente de acordo sobre a chave secreta a usar (sem a trocar em
claro pela rede):
1. Acordando a chave previamente (p.e. trocando-a em mo)
2. Usando uma terceira pessoa/entidade para trocarem a chave
Se isso se revelar um mtodo complexo, vo ter tendncia a manter a
mesma chave durante muito tempo, o que perigoso.
Uma Soluo:
usar uma chave diferente em cada sesso
usar um centro de distribuio dessas chaves no qual Alice e Bob confiam e
com o qual j partilham chaves
Distribuio de chaves de sesso atravs de um

Key Distribution Center primeira tentativa
Problema:
Problemas?
KDC Como que o Bob
pode ter a certeza
que est a falar com
falar com o Bob a Alice?
2) {Ks}Ka, {Ks}Kb
Alice Bob
3) {M}Ks {Ks}Kb
2
Distribuio de chaves de sesso atravs de um KDC
segunda tentativa
Problema:
KDC
Como que Bob Bob
1) Eu sou a Alice e quero pode ter a certeza
falar com o Bob que est a falar com
Alice?
Por Alice ter sido
2) { {A, Ks}Kb, Ks }Ka capaz de obter
{A,Ks}Kb. S Alice
conhece Ka
Alice Bob
3) {M}Ks, {A, Ks}Kb
Distribuio de chaves de sesso atravs de um KDC

segunda tentativa
Problema:
KDC
Pode Trudy obter o
1) Eu sou a Alice e quero contedo da
falar com o Bob mensagem?
No, porque apenas
Bob conhece Kb. Mas
2) { {A, Ks}Kb, Ks }Ka Trudy pode gravar a
mensagem e mais
tarde tentar
incomodar Bob.
Alice Bob
3) {M}Ks, {A, Ks}Kb
3
Protocolo de Needham-Schroeder
Este protocolo permite a dois principais A e B (Alice e Bob) estabelecerem um

canal seguro entre si e autenticarem-se mutuamente.
Baseia-se na presena de um KDC (Key Distribution Center) que conhece as

chaves secretas de A e B (Ka e Kb) e que capaz de gerar chaves de sesso (Ks)
que vo ser usadas por A e B para comunicarem de forma segura.
Passa a fazer parte da trusted computing base
O protocolo resiste aos ataques eavesdropping, masquerading, message

tampering e replaying.
(base do protocolo do Kerberos)
O protocolo NS com chaves simtricas

(terceira tentativa)
1) A -> KDC: A, B, Na
A solicita uma chave para comunicar com B, sendo Na um nmero aleatrio gerado
por A para garantir a unicidade da transaco (Na deve ser nico. Porqu?).

3) A -> B: {Ks, A}Kb, {Na}Ks

A solicita comunicar com B, enviando-lhe o ticket
4) B -> A: {Na-1}Ks
4
1) A -> KDC: A, B, Na
por A para garantir a unicidade da transaco (Na deve ser nico).

O que garante a A ter falado com o KDC ?
3) A -> B: {Ks, A}Kb, {Na}Ks

4) B -> A: {Na-1}Ks
1) A -> KDC: A, B, Na

KDC conhece Ka, logo s KDC pode gerar a mensagem indicada.
3) A -> B: {Ks, A}Kb, {Na}Ks

O que garante a B estar a falar com A ?
4) B -> A: {Na-1}Ks
5
1) A -> KDC: A, B, Na

3) A -> B: {Ks, A}Kb, {Na}Ks

B sabe que est a falar com A, porque apenas A pode obter Ks associada a um ticket
indicando A (porque Ks passa cifrado com Ka em 2)). Alm disso, impossvel forjar
um ticket, porque s B e KDC conhecem Kb
4) B -> A: {Na-1}Ks
O que garante a A estar a falar com B ?
1) A -> KDC: A, B, Na

3) A -> B: {Ks, A}Kb, {Na}Ks

B sabe que est a falar com A, porque apenas A pode obter Ks associada a um ticket
indicando A (porque Ks passa cifrado com Ka em 2)). Alm disso, impossvel forjar
um ticket, porque s B e KDC conhecem Kb
4) B -> A: {Na-1}Ks
B prova ser B por ser capaz de decifrar {Na}Ks, o que pressupe ter sido capaz de
decifrar {Ks, A}Kb
Porque no pode B enviar {Na}Ks ?
6
Um possvel ataque e respectiva soluo
A mensagem 3) pode ser replayed mais tarde. Isso, em princpio, no tem

problema mas se por acaso Ks for um dia comprometida, ento Trudy pode
conseguir autenticar-se perante Bob como se fosse Alice. A soluo consiste em
acrescentar uma timestamp ao ticket que deve ser testada por Bob aps ter
recebido a mensagem 3). Tal exige que os relgios de A, B e do KDC estejam
sincronizados a menos de um valor considerado suficiente para tornar impossvel
a quebra da chave Ks em tempo til.
O protocolo fica:
1) A -> KDC: A, B, Na
2) KDC -> A: { Na, B, Ks, { Ks, A, t }Kb }Ka
3) A -> B: {Ks, A, t}Kb, {Na}Ks
4) B -> A: {Na-1}Ks
Autenticao via chave pblica
Problema: como que a Alice se autentica utilizando chaves assimtricas?
soluo: usa desafio/resposta, e criptografia assimtrica
1 tentativa:
KApriv(R)
KApub( KApriv(R) ) == R
7
Protocolo de Needham-Schroeder com chaves
pblicas
Pressupondo que A e B conhecem as chaves pblicas um do outro, podem
estabelecer um canal seguro e autenticarem-se mutuamente atravs de:
1. A -> B: { A, Na }KBpub
2. B -> A: { Na, Nb, Ks } KApub
3. A -> B: { Nb } Ks

Receber Na em 2 apenas B consegue obter Na, porque apenas B tem KBpriv
O que garante a B estar a falar com A?
Receber Nb em 3 apenas A consegue obter Nb, porque apenas A tem KApriv
Criptografia assimtrica lenta. Como solucionar o problema durante a comunicao?
Negoceia chave simtrica (Ks) para usar durante a comunicao
O que garante que Ks seguro?
Ks apenas passa na rede em 2 apenas A consegue obter Ks, porque apenas A tem KApriv
(B conhece Ks porque gerou Ks)
Protocolo de Needham-Schroeder com chaves

pblicas
Se A apenas quiser criar um canal cifrado e ter a certeza de que est a falar com
B basta:
A -> B: { A, Na, Ks }KBpub
B -> A: { Na } Ks
8
Como distribuir as chaves pblicas?
Ataques por interposio
So necessrias chaves pblicas

certificadas
9
Centro de distribuio de chaves pblicas
PKC = Public Key Center So possveis ataques

por interposio?
PKC
Qual a chave pblica
de B ?
Qual a chave pblica
de A ?
KBpub KApub
A -> B: { A, Na }KBpub
A B
B -> A: { Na, Nb, Ks } KApub

A -> B: { Nb } Ks
Vantagens face criptografia simtrica
O Public Key Center (PKC) apenas conhece aquilo que pblico, isto , as
chaves pblicas dos principais. Tal um progresso notvel pois o papel da
trusted computing base foi drasticamente reduzido.
Para que tudo funcione bem apenas necessrio assegurar que o PKC tem as
chaves pblicas verdadeiras e que os principais tm a certeza que esto a falar
com o verdadeiro PKC e no com um impostor.
necessrio ter absoluta segurana de que se est a dialogar com uma fonte
fidedigna que nos est a entregar a verdadeira chave pblica que pretendemos
Se se conhece a chave pblica dessa fonte fidedigna, uma forma de obter esta
confiana essa fonte cifrar a sua resposta com a sua chave secreta
10
Distribuio das chaves pblicas
Nos protocolos anteriores, um intruso que se consiga fazer passar pelo PKC,
consegue levar A e B a usarem chaves conhecidas
So necessrias chaves pblicascertificadas (ou assinadas)
Mtodos de distribuio de chaves:

Certificate Granting Authority entidades cujas chaves pblicas so bem
conhecidas e que assinam as chaves / certificados que entregam. Este mtodo est
hoje em dia normalizado de forma oficial.
Web of trust - mtodo informal por transitividade da relao de confiana, tambm
suportado na assinatura das informaes trocadas entre principais. Este mtodo
tem sido vulgarizado pelo programa PGP para troca de correio electrnico.
Objectivo: desenvolver um mecanismo digital que substitua as assinaturas

efectuadas num documento em papel
Quais as propriedades?
Um sistema de assinaturas digitais deve ter as seguintes propriedades:

Autenticao: o receptor deve poder verificar que a assinatura autentica
Integridade: a assinatura deve garantir que a mensagem assinada no foi alterada,
nem durante o trajecto, nem pelo receptor, mesmo que tenha passado em claro
No repudiamento: o emissor no poder negar que de facto enviou a mensagem
assinada
NOTA: O objectivo das assinaturas no esconder o contedo
11
Assinaturas digitais com chaves simtricas (MACs)
Sendo H() uma funo de sntese segura e K uma chave pr-acordada

M signed doc
H(M+K) h
Bob envia uma mensagem com
Assinatura
uma assinatura digital:
M M, H(M+K)
K
Alice verifica a autenticidade M

e integridade da mensagem: h
H(M+K) recebido =
Verificao
H(M+K) computado ? h = h'?
H(M+K) h'
K
12
Assinatura digital soluo com chaves simtricas
(MACs)
Assinatura digital da mensagem M efectuada por Bob: h=H(M+K)
Mensagem a enviar: M,h
Propriedades:
Verificao ao receber M, h, calcula H(M+K) = h
Autenticao, integridade garantidos porque apenas B consegue criar H(M+K) e
ningum consegue alterar M para M de forma que H(M+K)=H(M+K)
O no repdio limitado pois a verificao exige conhecer K, e conhecendo K pode-se
falsificar a assinatura
Assinatura digital com chaves assimtricas:

primeira tentativa
Assinatura digital da mensagem M efectuada por Bob: {M}KBpriv
Propriedades:
Autenticao verificada decifrando M = {{M}KBpriv}KBpub
Integridade e no repudiamento garantidos porque ningum consegue alterar/criar
{M}KBpriv sem conhecer KBpriv
Dimenso da assinatura idntica do documento Soluo?

Necessidade de cifrar todo o documento com chaves assimtricas
13
Utilizao de assinaturas digitais com chaves pblicas
M signed doc Bob envia uma mensagem

H(M) h E(Kpri , h) {h}Kpri com uma assinatura digital:
Assinatura
M,{H(M)}KBpriv
128 bits M
{h}Kpri h'
D(Kpub ,{h})
Verificao M
h = h'?
Alice verifica a autenticidade e
h
a integridade da mensagem: H(doc)
H(M) = {H(M)}KBpriv}KBpub ?
Assinatura digital: soluo com chaves pblicas
Assinatura digital da mensagem M efectuada por Bob: {H(M)}KBpriv

Mensagem a enviar: M,{H(M)}KBpriv
Propriedades:
Verificao ao receber M,{H(M)}KBpriv : H(M) = {{H(M)}KBpriv}KBpub
Autenticao, integridade e no repudiamento garantidos porque apenas B consegue
criar {H(M)}KBpriv e ningum consegue alterar M para M de forma que H(M)=H(M)
Dimenso da assinatura pequena e constante

Apenas assinatura cifrada mensagem at pode passar em claro
Qualquer um pode verificar a assinatura
14
Certificados de chaves pblicas
A segurana baseada em chaves pblicas depende da validade das chaves

pblicas.
Objectivo: estabelecer a autenticidade e integridade de uma chave pblica (p.e.

por declarao de uma entidade fidedigna) chave pblica certificada
Um certificado contm informao assinada/certificada de pelo menos o nome e

chave pblica duma entidade. Exemplo:
1. Certificate type
: Public key
2. Name Bobs Bank
3. Public key: KBpub
4. Certifying authority
: Fred The Bankers Federation
5. Signature
: {Digest(field 2 + field 3)}KFpriv
Exemplo
15
Exemplo
Autoridades de certificao
Uma certification authority (CA)

associa chaves pblicas a principais
Em geral, os chaves pblicas
(certificados) das CAs so bem-
conhecidos
Quando a Alice quer verificar qual a

chave do Bob:
1) obtm um certificado dessa chave
(at Bob o pode enviar!).
2) verifica autenticidade do certificado
verificando a assinatura efectuada
pela CA (usando chave pblica da
CA)
16
Certificados X.509
Entidade Nome identificativo, chave pblica

Emissor Nome identificativo, assinatura
Perodo de validade Data de incio, data de fim
Informao administrativa Verso, nmero de srie
Informao adicional
Repudiamento e validade de uma chave
Quando uma chave privada comprometida necessrio revogar a

chave pblica que lhe estava associada. Quando se utilizam certificados,
necessrio que as entidades de certificao memorizem os certificados
vlidos e os revogados.
Quando se utiliza um certificado devia-se verificar se o mesmo continua
vlido ou se foi revogado.
Quando uma chave privada comprometida impossvel garantir a

autenticidade de qualquer mensagem
Mesmo as anteriormente emitidas (pode ou no ser um problema)
Assim, a utilizao de certificados por si s no uma panaceia universal.
17
Algoritmo de Diffie-Hellman
Alice e Bob pretendem trocar entre si um senha ou chave de sesso (Ks) sem que
esta passe na rede (nota: autenticao no objectivo)
Se as chaves privadas forem comprometidas no futuro, os dados desta sesso
continuam seguros
Sejam dois nmeros aleatrios (grandes) m e n que so parmetros pblicos do

algoritmo ( melhor n ser primo e m ser tal que (m-1)/2 primo):
1) A gera um nmero secreto Xa e calcula: Ya = m^Xa mod n
2) B gera um nmero secreto Xb e calcula: Yb = m^Xb mod n
3) A e B trocam entre si Ya e Yb (valores pblicos passados em claro)
4) A calcula Ka = Yb^Xa mod n
5) B calcula Kb = Ya^Xb mod n
Comprova-se que Ks = Ka = Kb e que computacionalmente impossvel calcular

Xa ou Xb a partir de Ya ou Yb, isto , est-se a usar uma funo sem inverso
(one-way function).
E.g. m = 5; n = 23;
Xa = 3; Ya= 10; Xb =4; Yb = 4
Ka = 4^3 mod 23 = 18 Kb = 10^4 mod 23 = 18
Segurana futura perfeita
Um protocolo de distribuio de chaves de sesso diz-se que garante segurana

futura perfeita se no envolve segredos de longa durao que, uma vez
comprometidos no futuro, permitiriam conhecer uma sesso do passado.
Nos algoritmos NS (e similares), se uma chave secreta/privada for comprometida
possvel obter as chaves secretas negociadas com base nessa chave para uso
nas comunicaes
Trudy pode ficar a conhecer o contedo das mensagens trocadas para todas as
sesses que tenha gravado
Os segredos so de longa durao
No algoritmo Diffie-Hellman, se a Alice e o Bob usarem valores aleatrios de Xa e

Xb, que no voltem a ser usados, a chave nica e foi obtida sem recurso a
segredos de longa durao
Sabendo m, n, Ya e Yb no possvel obter Ks
Xa, Xb, e logo Ks, so segredos apenas enquanto dura a sesso: depois podem
(devem) ser descartados
18
Casos de estudo
Kerberos
SSL
PGP
19
O sistema Kerberos
Sistema desenvolvido no MIT para fornecer servios de autenticao e

segurana numa organizao
Usa uma variante do protocolo Needham-Schroeder com criptografia
simtrica
Servidor Kerberos
Servio de autenticao
Permite autenticar um cliente no sistema
Servio de autenticao conhece chave secreta (simtrica) de todos os
utilizadores e do TGS
Servio de tickets para servidores (TGS ticket granting service)
Permite obter um ticket para aceder a um servio
Servio de tickets conhece chaves secretas (simtricas) de todos os servidores
O sistema Kerberos
Kerberos Key Distribution Centre
Authentication
Step A database Ticket-
Authen- granting
1. Request for tication
service A service T
TGS ticket
2. TGS
ticket
Step B
3. Request for
server ticket
Login 4. Server ticket Step C
session setup 5. Service
Server request
Client session setup Service Server
C Request encrypted with session key function
S
DoOperation
Reply encrypted with session key
20
O protocolo Kerberos verso 5.0
Autenticao no sistema
A -> AS: A, TGS, n1
Cliente (A) pede para fazer login no sistema
AS -> A: { Ks, n1}Ka, {A,TGS, t1, t2, Ks}Ktgs
Servio de autenticao devolve ticket, vlido de t1 at t2, e chave que permite
falar com TGS
O que garante a A estar a falar com AS?
O protocolo Kerberos verso 5.0
Autenticao no sistema
A -> AS: A, TGS, n1
Cliente (A) pede para fazer login no sistema
AS -> A: { Ks, n1}Ka, {A,TGS, t1, t2, Ks}Ktgs
Servio de autenticao devolve ticket, vlido de t1 at t2, e chave que permite
falar com TGS
O que garante a A estar a falar com AS?

A recepo de {n1...}Ka garante a A que est a falar com AS (pois s AS conhece
tambm Ka) e que no existe replaying (n1 um nonce)
Nada, mas apenas A pode usar informao recebida para as fases seguintes do
protocolo por ser o nico a conhecer Ka
21
O protocolo Kerberos verso 5.0 (cont.)
Obteno de ticket para aceder a servio

A -> TGS: {A, TGS, t1, t2, Ks}Ktgs, {A, t3}Ks, B, n2
Cliente pede a TGS ticket para aceder ao servidor B
TGS -> A: {B, n2, Kab}Ks, {A, B, t1, t2, Kab}Kb
TGS devolve chave (Kab) e um ticket para A aceder ao servio B
O que garante a A estar a falar com TGS?
Obteno de ticket para aceder a servio

A -> TGS: {A, TGS, t1, t2, Ks}Ktgs, {A, t3}Ks, B, n2
Cliente pede a TGS ticket para aceder ao servidor B
TGS -> A: {B, n2, Kab}Ks, {A, B, t1, t2, Kab}Kb
TGS devolve chave (Kab) e um ticket para A aceder ao servio B
O que garante a A estar a falar com TGS?

A recepo de {n2...}Ks garante a A que est a falar com TGS (pois s TGS
consegue obter Ks) e que no existe replaying (n2 um nonce)
Autenticador {A, t3}Ks autentica A perante TGS por demonstrar que A conhece
Ks. Time-stamp (t3) impede replaying desta mensagem.
NOTA: Ka apenas usada na autenticao. A partir desse momento, o ticket
enviado pelo AS permite ao cliente comunicar de forma segura e autenticar-se no
TGS
22
Acesso ao servio
A -> B: {A, t3}Kab, {A, B, t1, t2, Kab}Kb, n3
Cliente pede para se autenticar com o servidor
B -> A: {n3}Kab
Cliente verifica autenticidade do servidor. A partir deste momento, cliente e
servidor podem usar Kab para comunicarem de forma segura.
O que garante a A estar a falar com B? Como se evita o replaying?
Acesso ao servio
A -> B: {A, t3}Kab, {A, B, t1, t2, Kab}Kb, n3
Cliente pede para se autenticar com o servidor
B -> A: {n3}Kab
Cliente verifica autenticidade do servidor. A partir deste momento, cliente e
servidor podem usar Kab para comunicarem de forma segura.
O que garante a A estar a falar com B? Como se evita o replaying?

Apenas B pode produzir {n3}Kab, porque apenas B consegue obter Kab a partir
do ticket. Replaying evitado por n3 ser um nonce.
Apenas A conhece Kab, logo s A pode produzir {A,t3}Kab. t3 um timestamp
usado para evitar replaying.
23
Notas sobre o protocolo Kerberos v. 5.0
Os valores de t1, t1, t2, t2, t3, t3 so estampilhas temporais geradas a partir do
relgio (que se pressupem estar fracamente sincronizados)
Permite aplicar tempo limite a tickets, revogando autorizaes dadas
Permite proteco contra replaying de mensagens antigas (ou utilizao indevida de
tickets encontrados em memria)
Clientes devem obter novos tickets quando termina a validade dos tickets obtidos.
Clientes devem obter um ticket para cada servidor que queiram contactar.
Vantagens da variante Kerberos sobre o protocolo

Needham-Schroeder simples
O AS conhece as senhas / chaves / passwords de todos os clientes mas estas s
so usadas para autenticar inicialmente os clientes
A senha / chave / password do cliente (que usa workstations avulso) s est na
memria das mesmas durante alguns milisegundos
Os tickets tm uma durao limitada (tanto com o TGS como com os servidores)
Validade dos tickets geralmente de algumas horas
Permite interromper o servio a clientes a quem tenha sido cancelado o registo
O TGS apenas tem de conhecer os servidores e emitir chaves de sesso (repare-
se que os clientes so muito mais numerosos que os servidores)
Quando se usa um sistema tipo Kerberos, quais as diferentes formas de controlo

de acessos executadas?
24
SSL - Secure Socket Layer
Trata-se de um protocolo proposto e desenvolvido pela Netscape, do tipo sesso,

isto sobre o nvel transporte, que permite estabelecer canais seguros e
autenticar clientes e servidores. Hoje em dia trata-se de uma norma IETF.
Canal seguro
Conexo TCP
Cliente Servidor
O protocolo SSL
O protocolo SSL funciona por cima do Autenticao do servidor:

nvel de transporte e permite fornecer O cliente (browser) inclui as chaves
segurana a qualquer aplicao pblicas de vrias CAs
baseada em TCP O cliente solicita ao servidor um
certificado do servidor emitido por uma
usado entre browsers e servidores CA em que ele confie.
WWW (https). O cliente verifica o certificado do
servidor com a chave pblica da CA
Funcionalidades de segurana:
autenticao do servidor Autenticao do cliente:
cifra e integridade dos dados Processa-se de forma semelhante
autenticao do cliente (opcional)
Veja no seu browser na seco de

segurana.
25
Certificado CLIP
26
Certificado CLIP
Assinado pela Multicert

Empresa de certificao nacional:
SIBS,CTT,INCM,PTPrime
Certificado Moodle@FCT
Certificado emitido localmente
Que garantias fornece?
27
Protocolos SSL
SSL

Handshake
SSL Change
SSL Alert
HTTP
Telnet

protocol
Cipher Spec
Protocol

SSL Record Protocol

Transport layer (usually TCP)

Network layer (usually IP)

SSL protocols:
Other protocols:

SSL Record Protocol: implementa canal seguro, cifrando e autenticando as

mensagens
SSL Handshake protocol + SSL CCS + SSL AP: estabelecem e mantm um canal
seguro entre um cliente e um servidor
28
SSL handshake protocol
Transport handshake
ClientHello Establish protocol version, session ID,

cipher suite, compression method,
ServerHello exchange random start values
Certificate
Certificate Request Optionally send server certificate and
request client certificate
ServerHelloDone
Client Certificate Server Send client certificate response if

A Certificate Verify B requested
Change Cipher Spec

Change cipher suite and finish
Finished
handshake
Change Cipher Spec
Finished
DATA Application data
Material de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 57 *
SSL handshake configuration options
Component Description Example

Key exchange the method to be used for RSA with public-key
method exchange of a session key certificates
Cipher for data the block or stream cipher to be IDEA
transfer used for data
Message digest for creating message SHA
function authentication codes (MACs)
SSL permite usar diferentes Cipher Suites. Durante o handshake o cliente indica quais tem
disponveis e o servidor selecciona um.
Autenticao do servidor: servidor envia certificado e cliente envia premaster secret cifrado
com a chave pblica do servidor
Premaster secret usado para gerar as chaves de cifra (uma para cada sentido) e a chave a usar
no MAC
Autenticao do cliente: cliente envia certificado e cliente envia assinatura de parte das
mensagens trocadas
29
SSL record protocol
Application data abcdefghi
Fragment/combine
Record protocol units abc def ghi
Compress
Compressed units
Hash
MAC
Encrypt
Encrypted
Transmit
TCP packet
Pretty good privacy (PGP)
Esquema de cifra e assinatura de e- Exemplo de uma mensagem assinada com PGP:

mail.
Trata-se de uma norma de facto. ---BEGIN PGP SIGNED MESSAGE--
Hash: SHA1
Utiliza criptografia simtrica,
criptografia assimtrica, funes de Bob,
hash seguras e assinaturas digitais. My husband is out of town tonight.
Passionately yours,
Fornece autenticao, secretismo, Alice
integridade e no repudiamento.
---BEGIN PGP SIGNATURE---
Version: PGP 5.0
O inventor, Phil Zimmerman, foi alvo de yhHJRHhGJGhgg/12EpJ

um processo legal nos EUA durante 3 +lo8gE4vB3mqJhFEvZP9t6n7G6m5Gw2
anos. ---END PGP SIGNATURE---
30
Funcionamento do PGP (exemplo com SHA1 e IDEA)
Envio da mensagem M de A para B assinada e cifrada:

1.Produz assinatura
digital de M, com chave Ks 4. Cifra Ks com chave
RSA
privada do emissor: pblica do receptor:
{SHA1(M)}KApriv {Ks}KBpub
SHA1 RSA Compresso
5. Resultado de 3+4 so
M
(a) (b) (c) concatenados e codificados
em ASCII 7 bits usando o
IDEA Base 64 mtodo base64. O resultado
enviado atravs de correio
2. Comprime M+{SHA1(M)}KApriv 3. Gera Ks e cifra electrnico.
resultado de 2 com Ks
( a ) M, { SHA1(M) } KApriv
(algoritmo IDEA)
( b ) { M, { SHA1(M) } KApriv } Ks
( c ) { M, { SHA1(M) } KApriv } Ks , { Ks } KBpub
Funcionamento do PGP O que garante que s o

receptor (B) pode ler a
mensagem?
A mensagem cifrada com Ks,
Ks RSA
logo s quem conhea Ks pode
decifrar a mensagem.
SHA1 RSA Compresso Ks cifrada com KBpub, logo
s B pode obter Ks, porque s
B conhece KBpriv
(a) (b) (c)
M
O que garante ao receptor (B)
IDEA Base 64
que foi o emissor (A) que
enviou a mensagem?
( a ) M, { SHA1(M) } KApriv Apenas o emissor pode
( b ) { M, { SHA1(M) } KApriv } Ks produzir a assinatura digital da
mensagem, porque apenas A
( c ) { M, { SHA1(M) } KApriv } Ks , { Ks } KBpub
conhece KApriv
31
Funcionamento do PGP
1. Produz assinatura da mensagem M. Seja M a mensagem a enviar, H a funo

de hash seguro, e KApriv a chave privada de A, a assinatura gerada {H(M)}
KApriv.
2. A concatenao da mensagem M com a assinatura comprimida
3. Uma chave secreta Ks ento gerada e o resultado de 2) cifrado com a chave

Ks.
4. Ks cifrada com a chave pblica do receptor, KBpub.
5. O resultado de 4) e 5) so concatenados e codificados em ASCII 7 bits pelo

mtodo base 64.
6. O resultado de 5) pode ser enviado atravs de correio electrnico.
Distribuio de chaves em PGP
O programa PGP vulgarizou um mtodo de distribuio de chaves dito Web of

Trust que consiste em cada pessoa adquirir as chaves pblicos dos interlocutores
atravs de outras pessoas em quem tem confiana, ou atravs de servidores
pblicos.
PGP fornece um mtodo de assinatura de chaves para que cada principal possa
assinar as chaves que envia a quem confia nele (que j conhece a sua chave ou
chaves pblicas).
Para fazer bootstrap da Web of trust utilizam-se mtodos administrativos que
ultrapassam o mbito da problemtica criptogrfica, nomeadamente relacionados com
a forma como as chaves so depositadas no servidor de chaves pblicas.
Cada utilizador pode ter vrias chaves privadas (private key ring) e dispe de um
directrio de chaves pblicas de terceiros (public key ring) classificadas por grau
de confiana da fonte que forneceu a chave.
As chaves podem ter 512 (utilizao casual), 1024 (utilizao comercial) ou 2048 bits
(utilizao segura).
32
Resumo

necessariamente entre si)
Ideia base
Algoritmo Needham-
KDC Schroeder
falar com o Bob
A, B, Na
2) { {A, Ks}Kb, Ks, B, Na }Ka
Alice 3) {Nb}Ks, {A, Ks}Kb Bob

{Nb-1}Ks
4) {M}Ks
33
Ideia base
PKC = Public Key Center

PKC
Qual a chave pblica
de B ?
CertB
{Ks}KBpub, {M}Ks
A B

com base na chave publica S est a autenticar B
de PKC que conhece
Ideia base
CertB
A B
{Ks}KBpub, {M}Ks

com base nos certificados
das CA que conhece
S est a autenticar B
34
Resumo

necessariamente entre si)
Diffie-Hellman
Permite estabelecer canal cifrado entre dois parceiros sem trocar uma chave
sesso (mas no os autentica)
Resumo
Autenticao dos parceiros (ideia base: desafio)

Capacidade de decifrar mensagem cifrada com chave secreta
Capacidade de cifrar mensagem com chave privada
Capacidade de decifrar mensagem cifrada com chave pbica
35
Resumo
Garantia de integridade e autenticidade das mensagens

Assinaturas digitais baseadas em chaves assimtricas
MACs
Para saber mais
Bibliografia base
G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems - Concepts
and Design, Addison-Wesley, 4th Edition, 2005
Captulo 7
Bibliografia adicional:
James F. Kurose and Keith W. Ross, "Computer Networking - A Top-Down Approach Featuring the
Internet, Addison Wesley Longman, Inc., Second Edition, 2003 captulo 7.
Tanenbaum and Maarten van Steen Distributed Systems Principles and Paradigms, Prentice-
Hall, 2002 captulo 8.
W. Stallings, Cryptography and Network Security Principles and Practice, Second Edition 1999
Este livro integralmente dedicado a este tpico.
Codificao da Informao (1 ciclo)
Segurana em Sistemas e Redes de Computadores (2 ciclo)
36
Nota prvia
A apresentao utiliza algumas das figuras livro de base do curso

LEI (1 ciclo) 2010/2011
Captulo 7
Introduo aos sistemas de designao,
de descoberta e de localizao de servios
Organizao do captulo Da necessidade dos nomes
Introduo problemtica da designao de objectos distribudos Num sistema distribudo os nomes so imprescindveis para designar computadores,
servios, utilizadores, objectos remotos, ficheiros e recursos em geral, Os diferentes
Nomes e estruturao do espao de nomes
componentes do sistema, assim como os utilizadores, s podem partilhar recursos se os
Servidores de designao poderem designar.
Servios de descoberta Os nomes permitem designar e identificar entidades ou objectos.
Por vezes, os nomes incluem informao relativa a propriedades/atributos dos objecto:

Exemplos?
xpto@foo.com, http://asc.di.fct.unl.pt/sd1
Um servio de nomes permite obter dados (atributos) sobre um entidade dado o seu nome.
Exemplo: nome dos ficheiros nos sistemas de ficheiros
Um servio de directrio ou descoberta permite obter dados sobre as entidades que

satisfazem um dada descrio.
Exemplo: directorias nos sistemas de ficheiros
O que so nomes ? Nomes e identificadores
Nomes so sequncias de smbolos (geralmente codificados como sequncias de Designar - aco de apontar, indicar, mostrar, escolher
bytes, bits) que designam entidades. Identificar - tornar idntico, o que faz com que uma coisa seja idntica a outra, o que
permite saber se duas coisas so distintas ou no
Um nome tem de ser interpretado para se chegar (aos dados da) entidade. Este
processo de interpretao diz-se resolver ou interpretar o nome (to resolve). Um nome permite designar uma entidade
Num dado contexto, uma entidade pode ser designada por mais do que um nome.
A associao entre um nome e uma entidade designa-se por ligao (binding).
Em geral, os nomes esto ligados a atributos da entidade e no directamente Um identificador permite identificar uma entidade
entidade (ex: ????). Num dado contexto, uma entidade tem um e um s identificador.
Dois identificadores distintos identificam duas entidades diferentes. Se duas entidades
tiverem o mesmo identificador, ento so a mesma entidade.
A interpretao de um nome deve ser feita num contexto pois o mesmo nome em
contextos diferentes pode designar objectos diferentes (exemplo?). Um identificador nico permite identificar uma entidade de forma permanente
Se UID1=UID2, ento Ent1=Ent2 para todo o sempre
Os nomes tomam vrias formas conforme o nvel do sistema em que so Se UID1UID2, ento Ent1 Ent2 para todo o sempre
interpretados.
1
Nomes, identificadores e endereos na prtica Hierarquias de designao
Utiliza-se o termo nome simblico, textual, orientado aos utilizadores, ou externo

para designar ou identificar entidades atravs de nomes mnemnicos e legveis Nomes simblicos ou externos
para os utilizadores. Exemplos? (exemplos: http://asc.di.fct.unl.pt/sd1,
www.di.fct.unl.pt, /home/nmp/myfile
/home/jose )
Utiliza-se o termo identificador nico sistema (UID) para designar sequncias de Nomes internos ou identificadores do sistema
smbolos, geralmente sem significado mnemnico, que permitem identificar (exemplos: UIDs, File handles, ...)
entidades de forma (quase) permanente, ao nvel interno do sistema distribudo.
Exemplos?
AF.65.8F.89.1B.23.FF.45.A5.89.8B (uid de um objecto remoto) Endereos
Utiliza-se o termo endereo para designar formas especiais de designao
(exemplo: 193.136.122.23)
transitria, voltil ou temporria das entidades, geralmente associadas
localizao das mesmas. Exemplo?
10.0.0.12 Para se manipularem os objectos assim designados, os nomes so traduzidos de
Um endereo um nome que d acesso imediato a uma entidade. um espao de designao noutro. Exemplos?
abertura de um ficheiro em tempo de execuo, determinao do
endereo IP associado a um nome DNS, acesso a um objecto remoto, etc.
URLs, URNs, URIs Vantagens dos URNs? Gerao de UIDs

Vantagens dos URLs?
Um URL (Uniform Resouce Locator) um nome que indica a localizao de um De forma geral os UIDs asseguram coerncia referencial e propriedades dos
objecto identificadores devido a no serem reutilizados. Esta propriedade torna a sua
scheme:scheme-specific-location gerao mais difcil.
Ex: http://asc.di.fct.unl.pt/sd1 A forma mais fcil de se gerarem UIDs consiste em utilizar geradores de nmeros
Um URL basicamente um endereo aleatrios e/ou estampilhas horrias.
Tais identificadores so potencialmente puros, no sentido em que no codificam
Um URN (Uniform Resource Name) um nome que permite identificar um propriedades das entidades que identificam, pelo que a sua utilizao se pode revelar
objecto independentemente da sua localizao muito difcil. Porqu?
urn:nameSpace:nameSpace-specificName
Ex: urn:ISBN:0-201-64233-8 Os UIDs no so geralmente visveis aos utilizadores ou so complementados
com sugestes (hints). Alternativamente usam-se nomes no puros,
Para aceder a um objecto ser geralmente necessrio existir um servio de nomes que
converta um URN num URL
prefixando-os com endereos de sites, por exemplo.
URLs e URNs so URIs (Uniform Resource Identifiers)
Nomes globais versus nomes contextuais Exemplos
Todos os nomes so contextuais pelo que duas entidades computacionais s Nomes globais:
podem partilhar um nome se partilharem directa ou indirectamente um contexto
nfs://phoenix.students.di.fct.unl.pt/home/joe
comum de interpretao de nomes. Caso contrrio no se entenderiam.
http://www.google.com/
Um sistema distribudo necessita de um contexto comum a todas as entidades smb://fatdata.berkley.edu/students/johnDeere
computacionais, para que essas entidades possam interagir. Os nomes relativos a rmi://bigserver.di.fct.unl.pt/computeService
esse contexto global dizem-se nomes globais, por oposio a nomes relativos a
193.136.122.1
outros contextos mais limitados que se dizem nomes contextuais.
Os nomes globais so independentes do contexto e podem passar-se livremente Nomes contextuais:
entre as diferentes entidades computacionais. 10.200.0.2
/home/joe
C:\database\students
2
Organizao do espao de nomes Generalizao a vrios espaos
Um domnio de nomeao um espao de nomes para o qual existe uma nica

//asc.di.fct.unl.pt/sd1/aulas-teoricas/cap6.pdf
autoridade administrativa para atribuir nomes.
asc.di.fct.unl.pt:
Em geral, num sistema coexistem vrios contextos ou domnios de designao e a
traduo dos nomes envolve interpretaes parciais em domnios do mesmo nvel
ou de nveis diferentes.
Assim, estabelecem-se ligaes entre os diferentes domnios e procedem-se a

vrias tradues de nomes at se chegar ao objecto.
Exemplo: http://asc.di.fct.unl.pt/sd1/aulas-teoricas/cap6.pdf
Quais os vrios domnios ?
Geralmente, os contextos iniciais so globais e so materializados por um servio

de nomes. Os outros contextos podem ser materializados por outros servidores
de nomes ou directamente pelos servidores que gerem os objectos.
/sd1/aulas-teoricas/cap6.pdf
Conceitos importantes Servio de designao ou de nomes
Contexto ou directrio lista de Um servio de designao ou servio de nomes um servio que permite obter
nomes e ligaes a folhas ou a outros um conjunto de atributos de uma entidade dado o seu nome. A resoluo do
directrios nome realizada a partir de um contexto de interpretao do nome.
Folhas atributos da entidade Cada um desses nomes pode designar utilizadores, servidores, servios, objectos
designada pelo nome ou a sua remotos, ficheiros, etc.
representao directa
Um servio de nomes geralmente implementa uma base de dados (distribuda)
Mounts ligaes entre espaos que associa nomes aos atributos das entidades que estes designam.
distintos
Existem duas operaes importantes:
Links simblicos, redireces ou Lookup: dado um nome devolve os atributos associados ao mesmo
aliases uma folha que contm um Bind: que associa um nome a um conjunto de atributos
nome (a ser resolvido)
No concreto Na prtica
O servio de nomes pode ser um servio isolado e especfico ou estar integrado Existe um ou mais servios de nomes puros, ao mais alto nvel: as
noutro servio. Exemplos? entidades nomeadas tm uma taxa de criao, supresso e de mudana
O DNS um servio de nomes puro pois no desempenha nenhum outro papel. de atributos relativamente lenta. Exemplo?
Os servidores de ficheiros integram igualmente um servio de nomes dos ficheiros.
Servios de nomes para domnios, utilizadores, servios, mquinas, etc.
Num servio de nomes puro, as entidades existem independentemente do servio No que toca s entidades cujas taxas de criao, supresso ou de
de nomes. O servio de nomes permite obter atributos que permitem depois mudana de estado so mais elevadas, opta-se geralmente por integrar o
aceder ao objecto. servio de designao dessas entidades com o prprio servio de gesto
Nos servios de nomes integrados, a designao e a gesto das entidades esto das mesmas. Exemplo?
intimamente integradas. Geralmente, o servio de nomes usado internamente Servio de gesto de ficheiros integra a gesto dos nomes dos mesmos.
para aceder s entidades geridas pelo servio.
Porqu esta diferena?

Com baixas taxas de alterao mais fcil criar um servio independente
que seja fivel e global.
3
Resoluo iterativa do nome pelo cliente Resoluo recursiva do nome pelos servidores
Caractersticas? NS2 NS2

NS2 Servidor processa cada pedido
2 2
rapidamente.
2 4 3
Resoluo comea em servidores 1 1
Name NS1 NS1
1 NS1 servers diferente. client client
Client 3 5
4
3 NS3 NS3
NS3
Non-recursive Recursive
server-controlled server-controlled
Cliente apresenta nome ao servidor local de nomes Cliente apresenta nome ao servidor local de nomes
Se servidor conhece o nome, devolve atributos Se servidor conhece o nome, devolve atributos
Se servidor no conhece o nome, indica outro servidor onde tentar resolver o nome Se servidor no conhece o nome, o prprio servidor resolve o nome iterativamente ou
recursivamente
Resoluo recursiva do nome pelos servidores Resoluo por multicasting
NS2 NS2 NS2

1 1 NS5
2 2
4 3
1 1 1
NS1 NS1 client NS3
client client
4 3 5 NS1
NS3 1
NS3 1
NS6
2 NS4
server-controlled Caractersticas? server-controlled
Cliente apresenta nome ao servidorCada local pedido

de nomes
fica pendente at estar resolvido Cliente envia mensagem multicast aos servidores de nomes
(ocupando
Se servidor conhece o nome, devolve atributosrecursos). O servidor de nomes que conhece o nome, devolve os atributos
Pode
Se servidor no conhece o nome, o permitir
prprio contornar
servidor resolve oproblemas de
nome iterativamente ou
recursivamente permisses.
Resoluo comea em servidores diferente.
Resoluo por multicasting Mascaramento das falhas e caching
Servio de nomes muitas vezes fundamental no acesso ao sistema.

NS2
1 1 NS5 Para mascarar falhas e fornecer elevada disponibilidade pode recorrer-se
replicao e caching de contextos.
Ao colocar cpias da informao (rplicas) em servidores distintos possvel tolerar
1
client NS3 falhas dos servidores e da rede.
NS1 Como que os clientes sabem quais so os servidores?
1 Problema idntico a saber um servidor - por exemplo, os atributos de um contexto
1 contm a lista das rplicas.
NS6
2 NS4 O caching e replicao tambm permitem melhorar a escalabilidade (e responder
a um elevado nmero de pedidos).
Caractersticas?
Cliente envia mensagem multicast aos servidores
Apenas deem
possvel nomes
ambientes que suportam
O servidor de nomes que conhece multicast
o nome, devolve
. os atributos Problema?
Todos os servidores de nomes vem todos os Manter coerncia entre as rplicas e a informao oficial.
pedidos.
4
DNS:
Coerncia entre rplicas e das caches Exemplo do DNS Sistema que mantm base de dados
distribuda com informao de
mquinas na internet.
Muitos servios de nomes no asseguram coerncia total, isto , permitem que os Protocolo de acesso ao sistema.
clientes observem incoerncias momentneas. O sistema s assegura que as Note: Name server names are a.root-servers.net
in italics, and the corresponding (root)
incoerncias no se vo manter e que todas as rplicas tendem para um estado domains are in parentheses.
coerente. Arrows denote name server entries uk
ns1.nic.uk purdue.edu
(uk)
Propriedades geralmente assumidas: yahoo.com
ns.purdue.edu
os clientes suportam algum grau de incoerncia. (purdue.edu)
co.uk
os valores registados no servio evoluem lentamente. ac.uk ns0.ja.net
(ac.uk)
* .purdue.edu
So frequentes as seguintes solues:
Replicao do tipo primrio/secundrios com propagao assncrona das actualizaes ic.ac.uk
do primrio para o secundrio; qmw.ac.uk
Mecanismos de caching em que os valores so retirados da cache por um mecanismo

de envelhecimento ou TTL, controlado pelos administradores dos contextos de
designao. Trata-se de um mecanismo optimista.
dcs.qmw.ac.uk *.dcs.qmw.ac.uk *.ic.ac.uk
*.qmw.ac.uk
alpha.qmw.ac.uk dns0.dcs.qmw.ac.uk dns0-doc.ic.ac.uk

(qmw.ac.uk) (dcs.qmw.ac.uk) (ic.ac.uk)
Os atributos no DNS - resource records do DNS Registos DNS (DNS Resource Records)
DNS: db distribuda com registos (RR)

Record type Meaning Main contents
A A computer address IP number Formato de um RR: (name, type, value, ttl)
NS An authoritative name server Domain name for server
CNAME The canonical name for an alias Domain name for alias
SOA Marks the start of data for a zone Parameters governing the zone Type=A Type=CNAME
WKS A well-known service description List of service names and protocols O nome um hostname O nome um alias para o
PTR Domain name pointer (reverse Domain name O valor um endereo nome cannico (o nome real)
lookups)
IP do host O valor o nome
HINFO Host information Machine architecture and operating
cannico
system
MX Mail exchange List of < preference, host > pairs Type=NS
O nome um domnio (e.g. Type=MX
TXT Text string Arbitrary text
foo.com) O valor o nome de um
O valor o hostname de mail server do domnio e
um servidor do domnio a respectiva prioridade
Arquitectura DNS Domnios de topo
Base de dados particionada por mltiplos servidores Domnios genricos: com, edu, org, mil, etc.
Organizao hierrquica dos servidores
Conjunto de servidores replicam informao da raiz da rvore Domnios nacionais: pt, uk, etc.
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also Los Angeles)
d U Maryland College Park, MD
g US DoD Vienna, VA k RIPE London (also Amsterdam, Frankfurt)
h ARL Aberdeen, MD i Autonomica, Stockholm (plus 3 other
j Verisign, ( 11 locations)
locations)
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto, CA
(and 17 other locations)
b USC-ISI Marina del Rey, CA

l ICANN Los Angeles, CA
5
Arquitectura DNS DNS: que futuro ?
Base de dados particionada por mltiplos servidores

Conjunto de servidores replicam informao da raiz da rvore
Informao sobre cada zona mantida em pelo menos dois servidores (de forma
authoritative em princpio actual)
Replicao primary/backup: backup l informao periodicamente do primrio
Frequnca da verificao parmetro da configurao
Qualquer servidor pode fazer cache de informao de outros servidores
Entradas tm time-to-live
Clientes contactam servidores (pode ser dada lista de servidores)

Protocolo tipicamente em UDP
Cliente pode solicitar navegao recursiva ou iterativa. Servidor livre de respeitar
pedido.
Clientes podem fazer caching dos resultados
Esta arquitectura garante coerncia da

informao?
Porque Material
funciona bem?
de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 31 Material de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 32
Directrios e servios de descoberta
Um servio de directrio ou descoberta um servio que permite obter os

atributos de uma entidade que satisfaz uma dada descrio (dada como um sub-
conjunto de atributos).
Nestes sistemas, o nome apenas um dos atributos.
Exemplo: qual o endereo IP da impressora a cores do edifcio II ?
Designao atravs de atributos Servios de nomes vs. servios de directrio
Um conjunto de atributos pode funcionar como apontador de uma entidade de Servios de nomes
uma forma mais potente que os nomes clssicos Nomes mais simples
Por exemplo, uma pessoa quando se dirige a uma agncia de um banco pode dizer
que deseja falar com o responsvel pela agncia, ou com o caixa. Servios de directrio
Estes apontadores so abreviaturas de a pessoa cujo atributo funo tem o valor Atributos mais poderosos
gerente ou caixa .
Necessrio definir atributos
Um mecanismo de designao baseado em atributos pode facilmente ser usado Mais simples obter servios redundantes
para designar conjuntos de entidades. Mais simples para integrao de um computador num ambiente novo
6
Servios de descoberta e mobilidade Descoberta de servios em Jini Diversos servios de
Acede ao servio usando lookup disponveis, com
Procura servio de vrios scopes
objecto recebido do servio descoberta enviando
Num ambiente com mobilidade ou em que a associao entre objectos se faz de
de descoberta (encapsula multicast
forma espontnea, os utilizadores tendem a no conhecerem previamente o admin
protocolo de comunicao). Printing
nome dos recursos.
1. finance service
Client lookup service?
Um servio de descoberta um servio de directrio que regista servios
disponveis numa rede.
admin
Exemplos? Lookup Client
service
Um servio de descoberta pode ser usado: Network 2. Here I am: .....
por um porttil para encontrar uma impressora, ou um projector de slides. 4. Use printing
service admin, finance
por um frigorifico para encontrar o sistema de alarme para comunicar que est sem
corrente h mais de 10 minutos.
finance 3. Request Lookup
Nos servios de descoberta uma pesquisa est geralmente sujeita a um contexto Corporate Printing service
printing
ou mbito, por exemplo, uma rede local, uma dada sala, uma localizao infoservice service
geogrfica, ...
Procura servio enviando RMI
Servios registam-se para servio de descoberta.
com um ou mais
servios de lookup Material de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 38
Servios de descoberta: arquitecturas possveis Servios de descoberta
Com servidor de directrio. Como descobrir servidor? Os servios registados nos servidores de descoberta tendem a ser
Utilizao de multicast volteis. Como lidar com esta volatilidade?
E.g. no comum: Bluetooth: well-known frequency-hopping sequence:
dispositivos e clientes percorrem as frequncias disponveis com diferentes Arquitectura com servidor:
velocidade Utilizao de leases: servidores devem renovar o seu registo periodicamente.
Sem servidor de directrio Arquitectura sem servidor:
Alternativa 1: Cliente envia multicast com pergunta. Servidores respondem Sem anncios peridicos, no necessrio fazer nada
directamente caso correspondam descrio. Com anncios peridicos, aps um dado perodo, considera-se que um
Alternativa 2: Servidores enviam multicast peridico com a sua descrio. servio que no se anunciou deixou de estar disponvel
Clientes guardam informao para responder s perguntas locais.
X.500 Directory Service
X.500 um servio de directrio X.500 Service (root)

desenhado para guardar
informao sobre recursos e
utilizadores ... France (country) Great Britain (country)
Greece (country)
...
A informao est organizada

hierarquicamente
... BT Plc (organization)University of Gormenghast (organization)
...
rvore de nomes chama-se
Directory Information Tree
... Computing Service (organizationalUnit)
estrutura directrio completa, Department of Computer Science (organizationalUnit)
Engineering Department (organizationalUnit)
incluindo os dados associados ...
com os vrios ns, chama-se

Directory Information Base (DIB)... Departmental Staff (organizationalUnit)
ely (applicationProcess)
Research Students (organizationalUnit)
...
... Alice Flintstone (person)... Pat King (person)James Healey (person)Janet Papworth (person) ...
7
X.500 Directory Service Exemplo de uma DIB Entry
A DIB (Directory Information Base) X.500 Service (root)

uma coleco de entries. Uma entry
info
contm informao sobre objectos, isto
Alice Flintstone, Departmental Staff, Department of Computer Science,
, uma entry uma coleco de ... France (country) Great Britain (country)
Greece (country)
... University of Gormenghast, GB
atributos de um objecto do mundo real.
DIB: entry 1, , entry N commonName uid
Entry: atribute 1, , atribute N Alice.L.Flintstone
... alf
Atribute: type, value Alice.Flintstone
Value: distinguished value, value Alice Flintstone mail
A. Flintstone
... Computing Service (organizationalUnit) alf@dcs.gormenghast.ac.uk
Department of Computer Science (organizationalUnit)
surname Alice.Flintstone@dcs.gormenghast.ac.uk
...
Um dos atributos essenciais de uma Flintstone roomNumber
entry o atributo objectClass que Departmental
um Z42
... Staff (organizationalUnit) telephoneNumber
atributo obrigatrio que define o tipo da ely (applicationProcess) +44 986 33 4604 userClass
entry. Research Students (organizationalUnit)
...
Research Fellow
... Alice Flintstone (person)... Pat King (person)James Healey (person)Janet Papworth (person)...
Tipos dos atributos Alguns exemplos de atributos
Existe um sistema de tipos de entries que utiliza herana e extensvel. O tipo de Nome do atributo Abreviatura Sintaxe do valor
uma entry define, atravs de ASN.1, os seus atributos obrigatrios e opcionais. O
commonName cn string
conjunto dos tipos da DIB constitui o esquema da DIB.
countryName c ISO3166 code
A DIB est organizada hierarquicamente. Cada entry identificada por um
Distinguished Name (DN) que um identificador global. Um DN um conjunto de localityName l string
atributos que permite identificar a entry, localizando-a na rvore.
organizationName o string
Cada entry pode tambm ser designada por um RDN, isto , Relative
organizationalUnitName ou string
Distinguished Name, isto , um conjunto de atributos que permite distinguir a
entry das suas irms na rvore. postalAddress special
postalCode string
userPassword string
telephoneNumber special
surname sn string
Exemplo Modelos de segurana
Permite vrios esquema de controlo de acessos

root Nenhuma
C=US C=PT Simples (password)
Strong (Public Key Encryption) - baseada nos certificados X.509
Suporta tambm ACLs para controlo dos acessos e modificaes

O=PSI O=COMPAQ O=RCCN
O=IBM
Ou=Operations Ou=Marketing
Cn=John Deere
Cn=Manager
DN = /C=US/o=COMPAQ/Ou=Marketing/Cn=John Deere
(DN = Distinguished Name )

8
Modelo organizacional Arquitectura
Existem domnios de gesto da informao so os Directory Management Conjunto de servidores (DSA) acessveis
Domains ( DMDs ) pelos User Agents (UA)
Est prevista a resoluo iterativa,

recursiva, transitiva server based e por
Um DMD materializados por um conjunto de DSAs ( Directory System Agents ), broadcasting dos nomes DUA DSA DSA
que gerem uma sub-rvore da rvore de informao (DIT)
A DIT est particionada em naming
DUA DSA
contexts.
DSA
Os DSAs definem o esquema e organizao dessa sub-rvore e a forma como a Um DSA gere uma information tree com DSA
mesma vista do exterior um ou mais naming contexts. Cada DSA DUA
conhece os DNs da raz dos seus naming
DSA
contexts e os RDNs da suas entries, logo
conhece os DNs das suas entries.
Operadores, utilizaes e estado Light-weighted Directory Access Protocol
Read, Compare (verifica o valor de um atributo de uma entry), List, Search, Add, A nica implementao disponvel de forma alargada e com uma utilizao
Remove, Modify (atributes), Modify RDN (como move), generalizada da norma X.500 como directrio interno das organizaes.
Utilizaes tpicas: O protocolo de acesso uma verso simplificada do protocolo de acesso entre o
pginas brancas das instituies DUA e o DSA chamado LDAP ou Light-weighted Directory Access Protocol.
DNS para hosts e e-mail
servidores de chaves pblicas O LDAP apenas usa uma representao textual dos atributos e dos valores e no
bases de dados bibliogrficas ASN.1 nem as regras de codificao associadas como est previsto nas normas X.
listas de servios, etc. 500 completas.
Alguns problemas: Vrias implementaes do protocolo LDAP e de servios de directoria a ele

definio de um conceito de nome legvel (e usvel) associados so disponibilizadas em open source (Open LDAP) e por fabricantes
estrutura mundial da DIT e uniformizao dos tipos usados como a Novell e Microsoft (Active Directory).
algoritmos de pesquisa e navegao genricos
A sua generalidade e complexidade tem impedido a sua divulgao a nvel

mundial para substituir o DNS como era a inteno inicial.
Para saber mais
G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems - Concepts and Design,

Captulo 9.
Captulo 16 seco 16.2.1
9
LEI (1 ciclo) 2010/2011
Captulo 7
Introduo aos sistemas de designao,
de descoberta e de localizao de servios
Nota prvia

1
Introduo problemtica da designao de objectos distribudos
Nomes e estruturao do espao de nomes
Servidores de designao
Servios de descoberta
Da necessidade dos nomes
Num sistema distribudo os nomes so imprescindveis para designar computadores,

servios, utilizadores, objectos remotos, ficheiros e recursos em geral, Os diferentes
componentes do sistema, assim como os utilizadores, s podem partilhar recursos se os
poderem designar.
Os nomes permitem designar e identificar entidades ou objectos.
Por vezes, os nomes incluem informao relativa a propriedades/atributos dos objecto:

Exemplos?
xpto@foo.com, http://asc.di.fct.unl.pt/sd1
Um servio de nomes permite obter dados (atributos) sobre um entidade dado o seu nome.
Exemplo: nome dos ficheiros nos sistemas de ficheiros
Um servio de directrio ou descoberta permite obter dados sobre as entidades que

satisfazem um dada descrio.
Exemplo: directorias nos sistemas de ficheiros
2
O que so nomes ?
Nomes so sequncias de smbolos (geralmente codificados como sequncias de

bytes, bits) que designam entidades.
Um nome tem de ser interpretado para se chegar (aos dados da) entidade. Este
processo de interpretao diz-se resolver ou interpretar o nome (to resolve).
A associao entre um nome e uma entidade designa-se por ligao (binding).

Em geral, os nomes esto ligados a atributos da entidade e no directamente
entidade (ex: ????).
A interpretao de um nome deve ser feita num contexto pois o mesmo nome em
contextos diferentes pode designar objectos diferentes (exemplo?).
Os nomes tomam vrias formas conforme o nvel do sistema em que so

interpretados.
Nomes e identificadores
Designar - aco de apontar, indicar, mostrar, escolher

Identificar - tornar idntico, o que faz com que uma coisa seja idntica a outra, o que
permite saber se duas coisas so distintas ou no
Um nome permite designar uma entidade

Num dado contexto, uma entidade pode ser designada por mais do que um nome.
Um identificador permite identificar uma entidade

Num dado contexto, uma entidade tem um e um s identificador.
Dois identificadores distintos identificam duas entidades diferentes. Se duas entidades
tiverem o mesmo identificador, ento so a mesma entidade.
Um identificador nico permite identificar uma entidade de forma permanente
Se UID1=UID2, ento Ent1=Ent2 para todo o sempre
Se UID1UID2, ento Ent1 Ent2 para todo o sempre
3
Nomes, identificadores e endereos na prtica
Utiliza-se o termo nome simblico, textual, orientado aos utilizadores, ou externo

para designar ou identificar entidades atravs de nomes mnemnicos e legveis
para os utilizadores. Exemplos?
www.di.fct.unl.pt, /home/nmp/myfile
Utiliza-se o termo identificador nico sistema (UID) para designar sequncias de

smbolos, geralmente sem significado mnemnico, que permitem identificar
entidades de forma (quase) permanente, ao nvel interno do sistema distribudo.
Exemplos?
AF.65.8F.89.1B.23.FF.45.A5.89.8B (uid de um objecto remoto)
Utiliza-se o termo endereo para designar formas especiais de designao

transitria, voltil ou temporria das entidades, geralmente associadas
localizao das mesmas. Exemplo?
10.0.0.12
Um endereo um nome que d acesso imediato a uma entidade.
Hierarquias de designao
Nomes simblicos ou externos

(exemplos: http://asc.di.fct.unl.pt/sd1,
/home/jose )
Nomes internos ou identificadores do sistema

(exemplos: UIDs, File handles, ...)
Endereos
(exemplo: 193.136.122.23)
Para se manipularem os objectos assim designados, os nomes so traduzidos de

um espao de designao noutro. Exemplos?
abertura de um ficheiro em tempo de execuo, determinao do
endereo IP associado a um nome DNS, acesso a um objecto remoto, etc.
4
URLs, URNs, URIs Vantagens dos URNs?
Vantagens dos URLs?
Um URL (Uniform Resouce Locator) um nome que indica a localizao de um
objecto
scheme:scheme-specific-location
Ex: http://asc.di.fct.unl.pt/sd1
Um URL basicamente um endereo
Um URN (Uniform Resource Name) um nome que permite identificar um

objecto independentemente da sua localizao
urn:nameSpace:nameSpace-specificName
Ex: urn:ISBN:0-201-64233-8
Para aceder a um objecto ser geralmente necessrio existir um servio de nomes que
converta um URN num URL
URLs e URNs so URIs (Uniform Resource Identifiers)
Gerao de UIDs
De forma geral os UIDs asseguram coerncia referencial e propriedades dos

identificadores devido a no serem reutilizados. Esta propriedade torna a sua
gerao mais difcil.
A forma mais fcil de se gerarem UIDs consiste em utilizar geradores de nmeros
aleatrios e/ou estampilhas horrias.
Tais identificadores so potencialmente puros, no sentido em que no codificam
propriedades das entidades que identificam, pelo que a sua utilizao se pode revelar
muito difcil. Porqu?
Os UIDs no so geralmente visveis aos utilizadores ou so complementados

com sugestes (hints). Alternativamente usam-se nomes no puros,
prefixando-os com endereos de sites, por exemplo.
5
Nomes globais versus nomes contextuais
Todos os nomes so contextuais pelo que duas entidades computacionais s

podem partilhar um nome se partilharem directa ou indirectamente um contexto
comum de interpretao de nomes. Caso contrrio no se entenderiam.
Um sistema distribudo necessita de um contexto comum a todas as entidades
computacionais, para que essas entidades possam interagir. Os nomes relativos a
esse contexto global dizem-se nomes globais, por oposio a nomes relativos a
outros contextos mais limitados que se dizem nomes contextuais.
Os nomes globais so independentes do contexto e podem passar-se livremente
entre as diferentes entidades computacionais.
Exemplos
Nomes globais:
nfs://phoenix.students.di.fct.unl.pt/home/joe
http://www.google.com/
smb://fatdata.berkley.edu/students/johnDeere
rmi://bigserver.di.fct.unl.pt/computeService
193.136.122.1
Nomes contextuais:
10.200.0.2
/home/joe
C:\database\students
6
Organizao do espao de nomes
Um domnio de nomeao um espao de nomes para o qual existe uma nica

autoridade administrativa para atribuir nomes.
Em geral, num sistema coexistem vrios contextos ou domnios de designao e a

traduo dos nomes envolve interpretaes parciais em domnios do mesmo nvel
ou de nveis diferentes.
Assim, estabelecem-se ligaes entre os diferentes domnios e procedem-se a

vrias tradues de nomes at se chegar ao objecto.
Exemplo: http://asc.di.fct.unl.pt/sd1/aulas-teoricas/cap6.pdf
Quais os vrios domnios ?
Geralmente, os contextos iniciais so globais e so materializados por um servio

de nomes. Os outros contextos podem ser materializados por outros servidores
de nomes ou directamente pelos servidores que gerem os objectos.
Generalizao a vrios espaos

//asc.di.fct.unl.pt/sd1/aulas-teoricas/cap6.pdf
asc.di.fct.unl.pt:
/sd1/aulas-teoricas/cap6.pdf
7
Conceitos importantes
Contexto ou directrio lista de

nomes e ligaes a folhas ou a outros
directrios
Folhas atributos da entidade

designada pelo nome ou a sua
representao directa
Mounts ligaes entre espaos

distintos
Links simblicos, redireces ou

aliases uma folha que contm um
nome (a ser resolvido)
Servio de designao ou de nomes
Um servio de designao ou servio de nomes um servio que permite obter

um conjunto de atributos de uma entidade dado o seu nome. A resoluo do
nome realizada a partir de um contexto de interpretao do nome.
Cada um desses nomes pode designar utilizadores, servidores, servios, objectos

remotos, ficheiros, etc.
Um servio de nomes geralmente implementa uma base de dados (distribuda)

que associa nomes aos atributos das entidades que estes designam.
Existem duas operaes importantes:

Lookup: dado um nome devolve os atributos associados ao mesmo
Bind: que associa um nome a um conjunto de atributos
8
No concreto
O servio de nomes pode ser um servio isolado e especfico ou estar integrado

noutro servio. Exemplos?
O DNS um servio de nomes puro pois no desempenha nenhum outro papel.
Os servidores de ficheiros integram igualmente um servio de nomes dos ficheiros.
Num servio de nomes puro, as entidades existem independentemente do servio

de nomes. O servio de nomes permite obter atributos que permitem depois
aceder ao objecto.
Nos servios de nomes integrados, a designao e a gesto das entidades esto

intimamente integradas. Geralmente, o servio de nomes usado internamente
para aceder s entidades geridas pelo servio.
Na prtica
Existe um ou mais servios de nomes puros, ao mais alto nvel: as

entidades nomeadas tm uma taxa de criao, supresso e de mudana
de atributos relativamente lenta. Exemplo?
Servios de nomes para domnios, utilizadores, servios, mquinas, etc.
No que toca s entidades cujas taxas de criao, supresso ou de

mudana de estado so mais elevadas, opta-se geralmente por integrar o
servio de designao dessas entidades com o prprio servio de gesto
das mesmas. Exemplo?
Servio de gesto de ficheiros integra a gesto dos nomes dos mesmos.
Porqu esta diferena?

Com baixas taxas de alterao mais fcil criar um servio independente
que seja fivel e global.
9
Resoluo iterativa do nome pelo cliente
Caractersticas?
NS2 Servidor processa cada pedido
rapidamente.
2 Resoluo comea em servidores
Name
1 NS1 servers diferente.
Client
3
NS3
Cliente apresenta nome ao servidor local de nomes

Se servidor conhece o nome, devolve atributos
Se servidor no conhece o nome, indica outro servidor onde tentar resolver o nome
Resoluo recursiva do nome pelos servidores
NS2 NS2
2 2
4 3
1 1
NS1 NS1
client client
4 3 5
NS3 NS3
server-controlled server-controlled
Cliente apresenta nome ao servidor local de nomes

Se servidor conhece o nome, devolve atributos
Se servidor no conhece o nome, o prprio servidor resolve o nome iterativamente ou
recursivamente
10
Resoluo recursiva do nome pelos servidores
NS2 NS2
2 2
4 3
1 1
NS1 NS1
client client
4 3 5
NS3 NS3
server-controlled Caractersticas? server-controlled
Cliente apresenta nome ao servidorCada local pedido

de nomes
fica pendente at estar resolvido
(ocupando
Se servidor conhece o nome, devolve atributosrecursos).
Pode
Se servidor no conhece o nome, o permitir
prprio contornar
servidor resolve oproblemas de
nome iterativamente ou
recursivamente permisses.
Resoluo comea em servidores diferente.
Resoluo por multicasting
NS2
1 1 NS5
1
client NS3
NS1
1
1
NS6
2 NS4
Cliente envia mensagem multicast aos servidores de nomes

O servidor de nomes que conhece o nome, devolve os atributos
11
Resoluo por multicasting
NS2
1 1 NS5
1
client NS3
NS1
1
1
NS6
2 NS4
Caractersticas?
Cliente envia mensagem multicast aos servidores
Apenas deem
possvel nomes
ambientes que suportam
O servidor de nomes que conhece multicast
o nome, devolve
. os atributos
Todos os servidores de nomes vem todos os
pedidos.
Mascaramento das falhas e caching
Servio de nomes muitas vezes fundamental no acesso ao sistema.
Para mascarar falhas e fornecer elevada disponibilidade pode recorrer-se

replicao e caching de contextos.
Ao colocar cpias da informao (rplicas) em servidores distintos possvel tolerar
falhas dos servidores e da rede.
Como que os clientes sabem quais so os servidores?
Problema idntico a saber um servidor - por exemplo, os atributos de um contexto
contm a lista das rplicas.
O caching e replicao tambm permitem melhorar a escalabilidade (e responder

a um elevado nmero de pedidos).
Problema?
Manter coerncia entre as rplicas e a informao oficial.
12
Coerncia entre rplicas e das caches
Muitos servios de nomes no asseguram coerncia total, isto , permitem que os

clientes observem incoerncias momentneas. O sistema s assegura que as
incoerncias no se vo manter e que todas as rplicas tendem para um estado
coerente.
Propriedades geralmente assumidas:

os clientes suportam algum grau de incoerncia.
os valores registados no servio evoluem lentamente.
So frequentes as seguintes solues:

Replicao do tipo primrio/secundrios com propagao assncrona das actualizaes
do primrio para o secundrio;
Mecanismos de caching em que os valores so retirados da cache por um mecanismo
de envelhecimento ou TTL, controlado pelos administradores dos contextos de
designao. Trata-se de um mecanismo optimista.
DNS:
Exemplo do DNS Sistema que mantm base de dados
distribuda com informao de
mquinas na internet.
Protocolo de acesso ao sistema.
Note: Name server names are a.root-servers.net
in italics, and the corresponding (root)
domains are in parentheses.
Arrows denote name server entries uk
ns1.nic.uk purdue.edu
(uk) yahoo.com
ns.purdue.edu
(purdue.edu)
co.uk
ac.uk ns0.ja.net
(ac.uk)
* .purdue.edu
ic.ac.uk
qmw.ac.uk
dcs.qmw.ac.uk *.dcs.qmw.ac.uk *.ic.ac.uk

*.qmw.ac.uk
alpha.qmw.ac.uk dns0.dcs.qmw.ac.uk dns0-doc.ic.ac.uk

(qmw.ac.uk) (dcs.qmw.ac.uk) (ic.ac.uk)
13
Os atributos no DNS - resource records do DNS
Record type Meaning Main contents

A A computer address IP number
NS An authoritative name server Domain name for server
CNAME The canonical name for an alias Domain name for alias
SOA Marks the start of data for a zone Parameters governing the zone
WKS A well-known service description List of service names and protocols
PTR Domain name pointer (reverse Domain name
lookups)
HINFO Host information Machine architecture and operating
system
MX Mail exchange List of < preference, host > pairs
TXT Text string Arbitrary text
Registos DNS (DNS Resource Records)
DNS: db distribuda com registos (RR)

Formato de um RR: (name, type, value, ttl)
Type=A Type=CNAME
O nome um hostname O nome um alias para o
O valor um endereo nome cannico (o nome real)
IP do host O valor o nome
cannico
Type=NS
O nome um domnio (e.g. Type=MX
foo.com) O valor o nome de um
O valor o hostname de mail server do domnio e
um servidor do domnio a respectiva prioridade
14
Arquitectura DNS

Domnios de topo
Domnios genricos: com, edu, org, mil, etc.
Domnios nacionais: pt, uk, etc.
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also Los Angeles)
d U Maryland College Park, MD
g US DoD Vienna, VA k RIPE London (also Amsterdam, Frankfurt)
h ARL Aberdeen, MD i Autonomica, Stockholm (plus 3 other
j Verisign, ( 11 locations)
locations)
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto, CA
(and 17 other locations)
b USC-ISI Marina del Rey, CA

l ICANN Los Angeles, CA
15
Arquitectura DNS

Informao sobre cada zona mantida em pelo menos dois servidores (de forma
authoritative em princpio actual)
Replicao primary/backup: backup l informao periodicamente do primrio
Frequnca da verificao parmetro da configurao
Qualquer servidor pode fazer cache de informao de outros servidores
Entradas tm time-to-live
Clientes contactam servidores (pode ser dada lista de servidores)

Protocolo tipicamente em UDP
Cliente pode solicitar navegao recursiva ou iterativa. Servidor livre de respeitar
pedido.
Clientes podem fazer caching dos resultados
Esta arquitectura garante coerncia da

informao?
Porque Material
funciona bem?
de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 31
DNS: que futuro ?
16
Directrios e servios de descoberta
Um servio de directrio ou descoberta um servio que permite obter os

atributos de uma entidade que satisfaz uma dada descrio (dada como um sub-
conjunto de atributos).
Nestes sistemas, o nome apenas um dos atributos.
Exemplo: qual o endereo IP da impressora a cores do edifcio II ?
17
Designao atravs de atributos
Um conjunto de atributos pode funcionar como apontador de uma entidade de

uma forma mais potente que os nomes clssicos
Por exemplo, uma pessoa quando se dirige a uma agncia de um banco pode dizer
que deseja falar com o responsvel pela agncia, ou com o caixa.
Estes apontadores so abreviaturas de a pessoa cujo atributo funo tem o valor
gerente ou caixa .
Um mecanismo de designao baseado em atributos pode facilmente ser usado

para designar conjuntos de entidades.
Servios de nomes vs. servios de directrio
Servios de nomes
Nomes mais simples
Servios de directrio
Atributos mais poderosos
Necessrio definir atributos
Mais simples obter servios redundantes
Mais simples para integrao de um computador num ambiente novo
18
Servios de descoberta e mobilidade
Num ambiente com mobilidade ou em que a associao entre objectos se faz de

forma espontnea, os utilizadores tendem a no conhecerem previamente o
nome dos recursos.
Um servio de descoberta um servio de directrio que regista servios

disponveis numa rede.
Exemplos?
Um servio de descoberta pode ser usado:

por um porttil para encontrar uma impressora, ou um projector de slides.
por um frigorifico para encontrar o sistema de alarme para comunicar que est sem
corrente h mais de 10 minutos.
Nos servios de descoberta uma pesquisa est geralmente sujeita a um contexto

ou mbito, por exemplo, uma rede local, uma dada sala, uma localizao
geogrfica, ...
Descoberta de servios em Jini Diversos servios de

Acede ao servio usando lookup disponveis, com
Procura servio de vrios scopes
objecto recebido do servio descoberta enviando
de descoberta (encapsula multicast admin
protocolo de comunicao). Printing
1. finance service
Client lookup service?
admin
Lookup Client
service
Network 2. Here I am: .....
4. Use printing
service admin, finance
finance 3. Request Lookup

Corporate Printing printing service
infoservice service
Procura servio enviando RMI

Servios registam-se para servio de descoberta.
com um ou mais
servios de lookup Material de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 38
19
Servios de descoberta: arquitecturas possveis
Com servidor de directrio. Como descobrir servidor?

Utilizao de multicast
E.g. no comum: Bluetooth: well-known frequency-hopping sequence:
dispositivos e clientes percorrem as frequncias disponveis com diferentes
velocidade
Sem servidor de directrio

Alternativa 1: Cliente envia multicast com pergunta. Servidores respondem
directamente caso correspondam descrio.
Alternativa 2: Servidores enviam multicast peridico com a sua descrio.
Clientes guardam informao para responder s perguntas locais.
Servios de descoberta
Os servios registados nos servidores de descoberta tendem a ser

volteis. Como lidar com esta volatilidade?
Arquitectura com servidor:

Utilizao de leases: servidores devem renovar o seu registo periodicamente.
Arquitectura sem servidor:

Sem anncios peridicos, no necessrio fazer nada
Com anncios peridicos, aps um dado perodo, considera-se que um
servio que no se anunciou deixou de estar disponvel
20
X.500 um servio de directrio X.500 Service (root)

desenhado para guardar
informao sobre recursos e
utilizadores ... France (country) Great Britain (country)
Greece (country)
...
A informao est organizada

hierarquicamente
...
rvore de nomes chama-se
Directory Information Tree
estrutura directrio completa, Department of Computer Science (organizationalUnit)
incluindo os dados associados ...
com os vrios ns, chama-se

Directory Information Base (DIB)... Departmental Staff (organizationalUnit)
ely (applicationProcess)
Research Students (organizationalUnit)
...
... Alice Flintstone (person)... Pat King (person)James Healey (person)Janet Papworth (person) ...
21
A DIB (Directory Information Base) X.500 Service (root)

uma coleco de entries. Uma entry
contm informao sobre objectos, isto
, uma entry uma coleco de ... France (country) Great Britain (country)
Greece (country)
...
atributos de um objecto do mundo real.
DIB: entry 1, , entry N
Entry: atribute 1, , atribute N
...
Atribute: type, value
Value: distinguished value, value
Department of Computer Science (organizationalUnit)
...
Um dos atributos essenciais de uma
entry o atributo objectClass que Departmental
um Staff (organizationalUnit)
...
atributo obrigatrio que define o tipo da ely (applicationProcess)
entry. Research Students (organizationalUnit)
...
... Alice Flintstone (person)... Pat King (person)James Healey (person)Janet Papworth (person)...
Exemplo de uma DIB Entry
info
Alice Flintstone, Departmental Staff, Department of Computer Science,
University of Gormenghast, GB
commonName uid
Alice.L.Flintstone alf
Alice.Flintstone
Alice Flintstone mail
A. Flintstone
alf@dcs.gormenghast.ac.uk
surname Alice.Flintstone@dcs.gormenghast.ac.uk
Flintstone roomNumber
telephoneNumber Z42
+44 986 33 4604 userClass
Research Fellow
22
Tipos dos atributos
Existe um sistema de tipos de entries que utiliza herana e extensvel. O tipo de

uma entry define, atravs de ASN.1, os seus atributos obrigatrios e opcionais. O
conjunto dos tipos da DIB constitui o esquema da DIB.
A DIB est organizada hierarquicamente. Cada entry identificada por um

Distinguished Name (DN) que um identificador global. Um DN um conjunto de
atributos que permite identificar a entry, localizando-a na rvore.
Cada entry pode tambm ser designada por um RDN, isto , Relative
Distinguished Name, isto , um conjunto de atributos que permite distinguir a
entry das suas irms na rvore.
Alguns exemplos de atributos
Nome do atributo Abreviatura Sintaxe do valor

commonName cn string
countryName c ISO3166 code

localityName l string
organizationName o string
organizationalUnitName ou string
postalAddress special
postalCode string
userPassword string
telephoneNumber special
surname sn string
23
Exemplo
root
C=US C=PT
O=PSI O=COMPAQ O=RCCN

O=IBM
Ou=Operations Ou=Marketing
Cn=John Deere
Cn=Manager
DN = /C=US/o=COMPAQ/Ou=Marketing/Cn=John Deere
(DN = Distinguished Name )

Modelos de segurana
Permite vrios esquema de controlo de acessos

Nenhuma
Simples (password)
Strong (Public Key Encryption) - baseada nos certificados X.509
Suporta tambm ACLs para controlo dos acessos e modificaes
24
Modelo organizacional
Existem domnios de gesto da informao so os Directory Management

Domains ( DMDs )
Um DMD materializados por um conjunto de DSAs ( Directory System Agents ),

que gerem uma sub-rvore da rvore de informao (DIT)
Os DSAs definem o esquema e organizao dessa sub-rvore e a forma como a

mesma vista do exterior
Arquitectura
Conjunto de servidores (DSA) acessveis

pelos User Agents (UA)
Est prevista a resoluo iterativa,

recursiva, transitiva server based e por
broadcasting dos nomes DUA DSA DSA
A DIT est particionada em naming

DUA DSA
contexts.
DSA
Um DSA gere uma information tree com DSA
um ou mais naming contexts. Cada DSA DUA
conhece os DNs da raz dos seus naming
DSA
contexts e os RDNs da suas entries, logo
conhece os DNs das suas entries.
25
Operadores, utilizaes e estado
Read, Compare (verifica o valor de um atributo de uma entry), List, Search, Add,
Remove, Modify (atributes), Modify RDN (como move),
Utilizaes tpicas:
pginas brancas das instituies
DNS para hosts e e-mail
servidores de chaves pblicas
bases de dados bibliogrficas
listas de servios, etc.
Alguns problemas:
definio de um conceito de nome legvel (e usvel)
estrutura mundial da DIT e uniformizao dos tipos usados
algoritmos de pesquisa e navegao genricos
A sua generalidade e complexidade tem impedido a sua divulgao a nvel

mundial para substituir o DNS como era a inteno inicial.
Light-weighted Directory Access Protocol
A nica implementao disponvel de forma alargada e com uma utilizao

generalizada da norma X.500 como directrio interno das organizaes.
O protocolo de acesso uma verso simplificada do protocolo de acesso entre o

DUA e o DSA chamado LDAP ou Light-weighted Directory Access Protocol.
O LDAP apenas usa uma representao textual dos atributos e dos valores e no
ASN.1 nem as regras de codificao associadas como est previsto nas normas X.
500 completas.
Vrias implementaes do protocolo LDAP e de servios de directoria a ele

associados so disponibilizadas em open source (Open LDAP) e por fabricantes
como a Novell e Microsoft (Active Directory).
26
Para saber mais
G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems - Concepts and Design,

Captulo 9.
Captulo 16 seco 16.2.1
27
Nota prvia

LEI (1 ciclo) 2010/2011
Captulo 8
Introduo aos sistemas distribudos de gesto de ficheiros
Sistemas de ficheiros distribudos Algumas questes envolvidas na distribuio
Um sistema de gesto de ficheiros distribudos fornece um servio de Integrao: como integrar no sistema de ficheiro local?
acesso a ficheiros semelhante ao de um sistema de ficheiros normal, mas
estendido a um conjunto de mquinas ligadas em rede. Normalmente Designao: como designar os ficheiros remotos?
permite: Externamente: ao nvel das aplicaes
Internamente: no sistema
Partilha de ficheiros por vrios utilizadores
Modelo de acesso: dois extremos: acesso completamente remoto ou
acesso completamente local (usando cache).
Melhor qualidade de servio do que a disponvel localmente
Maior dimenso do espao disponvel
Partilha de ficheiros: problemas relacionados com o controlo da concorrncia
Melhor tolerncia a falhas
e modelo de consistncia fornecido
Desempenho semelhante ou superior
Integrao no sistema local Exemplo: mount remoto e designao no NFS
Server 1 Client Server 2

Os ficheiros dum sistema distribudo de ficheiros devem ser acedidos
(root) (root) (root)
localmente numa mquina
Problema: Qual a granularidade da partilha?
Soluo tpica: sub-rvore do sistema de ficheiros export ... vmunix usr nfs
Remote Remote
Problema: Como providenciar acesso aos ficheiros? people
mount
students x staff
mount
users
Soluo: integrar a sub-rvore na hierarquia local

big jon bob ... jim ann jane joe
Windows: definindo uma nova drive
Unix-like: atravs do mecanismo de mount Cada servidor exporta um conjunto de directorias.
O cliente pode montar uma directoria remota (caso tenha permisses) numa
directoria local (ex.: /usr/students no cliente monta a rvore /export/people no
Server 1)
1
Integrao no sistema local (cont.) Arquitectura
Como fazer a integrao ?

Client computer Server computer
Soluo: os sistemas de operao normalmente suportam mecanismos
para definir novos sistemas de ficheiros
Unix-like: VFS Application Application
program program
Windows: IFS UNIX
system calls
UNIX kernel
UNIX kernel Virtual file system Virtual file system
Local Remote
file system
UNIX NFS NFS UNIX
file file
Other
client server
system system
NFS
protocol
Designao dos ficheiros Tipos dos nomes simblicos
Tipos dos nomes dos ficheiros: Nomes globais. Podem ser passados entre mquinas mas implicam a introduo
de uma super-raiz do file system.
Nomes simblicos Uma forma popular : //servername/ficheiro
(exemplo: /x/y/p/q ) Exemplo: //asc.di.fct.unl.pt/home/foobar
Nomes contextuais. Todos os nomes so interpretados a partir de um file system

local.
Nomes internos ao sistema Fceis de implementar mas difcil passar um nome entre duas mquinas
(exemplos: FileId, File-handles, UFIDs)
Ligaes (mounts)
Um mesmo nome em duas mquinas pode referir o mesmo ou diferentes ficheiros
Nomes diferentes em duas mquinas podem referir o mesmo ficheiro
Endereos internos ao servidor:
(exemplo: n device, n i-node, endereo de bloco, )
Caractersticas dos nomes internos Capacidades e UFIDS
Para que os clientes e os servidores possam memorizar UFIDs (ou file possvel definir identificadores de baixo nvel cuja posse garante o direito de
handles) sem que os mesmos possam dar origem a ambiguidades, estes realizar operaes sobre um objecto. Tratam-se de identificadores que podem ser
copiados, mas que no podem ser forjados. Este tipo de identificadores tm as
devem ser: vantagens de uma capacidade (e os defeitos tambm).
nicos no tempo
nicos no espao Exemplo:
64 bits 64 bits 64 bits
Communication end point file handle - random operations
UFID - Unique File Identifier
Que propriedades tem um NFS file handle ? Os dois campos direita tm de ser cifrados ou assinados para no serem
[ file system number, file i-node, i-node generation number ], alterveis.
endereo IP do servidor, porta do servidor
2
Caractersticas do mtodo Servidores stateless vs. Servidores stateful
Vantagens Um sistemas de ficheiros distribudos pode ser desenhado recorrendo a servidores

stateless ou stateful.
Favorece a modularidade e a independncia das componentes
Um servidor que no mantm informao sobre os clientes chama-se stateless.
Favorece solues stateless, mas
Um servidor que mantm informao sobre os clientes chama-se stateful.
Desvantagens
A revogao ou simples modificao dos direitos impossvel ou simplesmente

difcil
Exige cuidados especiais para impedir a cpia das capacidades ou o acesso

indevido s mesmas
Geralmente usam-se como complemento de um sistema baseado em ACLs,

atravs de short-lived ou session capabilities.
Servidores stateless Exemplo: operaes NFS

Nomes so resolvidos atravs de uma
sequncia de operaes de lookup, uma para
Considere um sistema de ficheiros local. Neste, o sistema mantm informao cada elemento do caminho. Porqu?
sobre o estado do cliente, ficheiros abertos, posio de leitura/escrita nos lookup(dirfh, name) -> fh, attr Returns file handle and attributes for the file name in the directory
ficheiros, etc. Como desenhar um sistema distribudo stateless, em que o servidor dirfh.
no mantm nenhuma desta informao? create(dirfh, name, attr) -> Creates a new file name in directory dirfh with attributes attr and
newfh, attr returns the new file handle and attributes.
Criar as operaes de modo a que incluam toda a informao necessria sua
remove(dirfh, name) status Removes file name from directory dirfh.
execuo
getattr(fh) -> attr Returns file attributes of file fh. (Similar to the UNIX stat system
call.)
setattr(fh, attr) -> attr Sets the attributes (mode, user id, group id, size, access time and
modify time of a file). Setting the size to 0 truncates the file.
read(fh, offset, count) -> attr, data Returns up to count bytes of data from a file starting at offset.
Also returns the latest attributes of the file.
write(fh, offset, count, data) -> attr Writes count bytes of data to a file starting at offset. Returns the
attributes of the file after the write has taken place.
fh, newfh so identificadores de ficheiros
opacos
Continua ...
Exemplo: operaes NFS Servidores stateful
Nesta aproximao, o servidor mantm informao sobre quais so os

lookup(dirfh, name) -> fh, attr Returns file handle and attributes for the file name in the directory clientes e o seu estado (e.g. ficheiros abertos, posio de leitura/escrita,
dirfh. etc.)
create(dirfh, name, attr) -> Creates a new file name in directory dirfh with attributes attr and Exemplo: protocolo CIFS/SMB
call.)
Operaes read e write so idempotentes. Como?

Atravs da adio da posio a ler/escrever Continua ...
3
Servidores stateless vs. Servidores stateful Operaes idempotentes
Propriedades stateless possvel desenhar um interface com (quase todas as) operaes idempotentes
Mascara mais facilmente as falhas dos servidores e de comunicaes. e.g. NFS
Para algumas operaes fcil: ex.: read, write, etc. Como?
Porqu?
Para outras operaes no possvel (ex.: rename, mkdir, rmdir). Porqu?
No h limite terico para o nmero de utilizadores simultneos. Porqu? Para estas operaes, comum o servidor manter uma pequena cache das ltimas
No existe necessidade de propagar operaes OPEN / CLOSE. Porqu? operaes deste tipo, implementando uma semntica at-most-once simplificada.
Propriedades stateful
Operaes podem ser mais simples e mais simples ter semntica
A utilizao de operaes idempotentes simplifica o protocolo e a implementao
equivalente dos sistemas centralizados. Porqu?
do servidor. Porqu?
Permitem implementar locks mais facilmente. Porqu? Estado mantido pelo servidor nulo (ou mnimo)
Protocolo RPC pode implementar semntica at-least-once. Porque que mais
simples?
Tendem a permitir uma poltica de caching tambm mais eficaz (como
veremos a seguir)
Se tudo estiver a funcionar bem, um crash do servidor seguido da sua
recuperao, uma interrupo momentnea da rede, ou a perca de alguns
pacotes, so falhas que so mascaradas facilmente pelo conjunto do sistema
Como?
Falhas: no to simples como parece... Modelos de Caching : informao replicada
Cache no (SO do) servidor levanta alguns problemas na presena de falhas. Quase todos os sistemas de ficheiros distribudos mantm um cache que pode ter
Quais? diferentes caractersticas
Modelo caching por blocos. Guarda blocos de ficheiros (geralmentes da dimenso

Solues possveis? do bloco dos discos e com dimenso idntica usada na transferncia entre o
Exemplo NFS: cliente e o servidor).
Verso 2: o write apenas retornava aps a escrita ser efectuada em disco (cache
write-through). Porqu? Quais os problemas? Modelo Caching de Ficheiros inteiros. Guarda ficheiros completos na cache
Verso 3: o write escreve na cache do file-system (como qualquer write local). A sempre que necessrio aceder a um ficheiro, este transferido para a mquina do
operao commit permite garantir que as escritas efectuadas foram escritas em disco cliente. Nota: caching efectuado normalmente em disco.
(normalmente executado aquando do close).
Modelo Servio Remoto ou sem Cache. Cada vez que necessrio aceder a um
ficheiro, o cliente invoca o servidor.
Eficincia?
Depende da fraco de operaes que podem ser servidas
pelos valores guardados na cache.
Caching fich. inteiros > caching blocos > sem caching
Modelos de Caching : informao replicada Acessos concorrentes em sistemas tradicionais
Quase todos os sistemas de ficheiros distribudos mantm um cache que pode ter Nos sistemas de ficheiros centralizados, a semntica dos acessos concorrentes
diferentes caractersticas definida por:
Uma poltica por omisso
Modelo caching por blocos. Guarda blocos de ficheiros (geralmentes da dimenso E um mecanismo de locks
do bloco dos discos e com dimenso idntica usada na transferncia entre o
No sistema Unix (e Linux ), a poltica por omisso do tipo serializao das
cliente e o servidor).
operaes sobre cada ficheiro: uma leitura l sempre o resultado da ltima
Modelo Caching de Ficheiros inteiros. Guarda ficheiros completos na cache escrita.
sempre que necessrio aceder a um ficheiro, este transferido para a mquina do Existe ainda um sistema de locks que permite garantir acessos sem conflitos
cliente. Nota: caching efectuado normalmente em disco. (write / write ou read / write ) por dois processos distintos.
Exemplo de system call para manipular locks no sistema Unix:
Modelo Servio Remoto ou sem Cache. Cada vez que necessrio aceder a um result = flock(filedes, offset, range, locktype)
Nos sistemas centralizados estas polticas so relativamente fceis de

Coerncia? implementar pois s existe um sistema de gesto de ficheiros e uma cache
Depende do modo como verificada a validade da cache
Sem caching > caching blocos > caching fich. inteiros
4
Acessos concorrentes distribudos Controlo de concorrncia pessimista com servidores
stateless
Quando o sistema de gesto de ficheiros distribudo o problema do acesso A semntica tradicional centralizada consiste em uma leitura ver sempre o
partilhado e do controlo da concorrncia mais difcil de resolver. Porqu? resultado da ltima escrita (serializao dos acessos).
Os mtodos usados para lidar com este aspecto podem agrupar-se em mtodos A semntica dum esquema de gesto das caches depende do que se faz nas
pessimistas ou mtodos optimistas. operaes de leitura e escrita:
Associado s escritas est a propagao das modificaes para o servidor (e sua
Os mtodos pessimistas tentam esconder que existem vrias cpias e procuram visualizao por outros clientes).
emular o melhor possvel a semntica do sistema centralizado a distribuio Associada s leituras est a verificao da coerncia da cache em relao ao servidor.
mais transparente.
Estes sistemas poderiam descrever-se como sistemas com equivalncia a uma s
cpia (one copy serializability).
Os mtodos optimistas tentam no esconder totalmente a replicao e o

caching em troca de um maior desempenho, adaptao escala e flexibilidade.
No limite so os nicos aplicveis em sistemas mveis quando se pretende admitir
acesso em escrita com desconexo.
Modelo da cache do NFS Modelo da cache do NFS (2)
Os sistemas Unix usam sempre caching de ficheiros locais, em memria central. A O valor de t calculado de forma dinmica e varia entre 3 e 30 segundos para
poltica convencional satisfazer os pedidos de leitura da cache se possvel e usar ficheiros (o valor menor quanto mais frequentemente o ficheiro escrito) e
read-ahead e delayed-write (30 segundos no mximo) dos ficheiros locais. entre 30 e 60 segundos para directrios (estratgia idntica).
O mdulo cliente do NFS coloca tambm na cache local os blocos que l do Se T - Tc < t, o segundo teste no realizado, caso contrrio executado um
servidor e utiliza um sistema de timestamps para controlar a respectiva validade.
getattr request ao servidor e os valores de Tc e Tw so actualizados.
H duas timestamps associadas a cada bloco na cache:
Se Tw-server Tw-client todos os blocos do ficheiro so retirados da cache pois o
Tc - ltima hora a que esta entrada na cache foi validada (hora local)
ficheiro foi modificado.
Tw-client - estampilha horria da ltima vez que o ficheiro foi escrito (hora do servidor
tal como est registada actualmente no cliente) Para optimizar, os valores de Tw so aplicados a todos os blocos do mesmo ficheiro e
os atributos do ficheiro so piggybacked sempre que possvel com todas as respostas
No momento T, considera-se vlida uma entrada na cache sse: T-Tc< t Caso do servidor (ver a definio das operaes NFS)
contrrio, necessrio verificar se o ficheiro no foi alterado no servidor, i.e., se Qual o problema de manter apenas um Tw para cada ficheiro?
Tw-server = Tw-client
Se t grande pode resultar incoerncia, se t pequeno pode resultar ineficincia. Os blocos modificados por uma escrita no cliente so marcados como dirty e
enviados assincronamente para o servidor ou logo que um sync ocorre no cliente.
Porque que (quase) todas as operaes NFS Como se comporta esta aproximao
retornam atributos do ficheiro? com um sistema de bases de dados?
Gesto da cache com servidores stateless NFS: Gesto da cache com servidores stateless
Leituras. Para garantir a frescura da informao cached, os clientes de NFS

servidores stateless tm de testar a validade da mesma: Escrita: delayed-write, read-ahead
teste antes de cada acesso - aumenta a coerncia mas diminui a performance Leitura: testa periodicamente
teste peridico - semntica sem garantias totais
Escrita. A propagao de escritas pode ser efectuada em vrios momentos.

Escrita Write-through. A cada escrita no cliente corresponde uma (ou mais) escritas Para que tipo de ambiente apropriado?
no servidor. Propriedades?
Favorece a fiabilidade e a semelhana com a semntica tradicional tipo sistema Acesso aos ficheiros num ambiente de desenvolvimento de software ou
equivalente a uma s cpia custa do sacrifcio do desempenho.
de partilha no simultnea dos ficheiros. O resultado um sistema com
Escrita Delayed-Write. As escritas so inicialmente efectuadas na cache local e, uma semntica de carcter probabilstico, mas com muito sucesso no
posteriormente, enviadas para o servidor. Propriedades? ambiente alvo e que afinal mais optimista que pessimista.
Este esquema diminuem o trfego de rede mas diminui a fiabilidade e consistncia.
Quando o servidor stateless e ignora os clientes, no possvel implementar a
semntica equivalncia a uma s cpia.
5
Gesto da cache com servidores stateful Gesto de cache no sistema CIFS: Opportunistic locks
Aproximao controlada pelo servidor: o servidor (stateful) anota cada cliente de Neste esquema, introduzido no sistema CIFS (sucessor do SMB), existem vrios
um ficheiro e o modo de acesso e gere um sistema de notificaes de alteraes, tipos de locks:
assim como mecanismos baseados em tokens e locks para ajudar os clientes a Opportunistic locks (oplocks) exclusivos que permitem ao cliente ter acesso exclusivo
melhorarem o seu desempenho. ao ficheiro e fazer caching arbitrrio do mesmo. Um oplock pode ser retirado ao
cliente pelo servidor.
Oplocks partilhados que permitem aos clientes ter acesso ao ficheiro em leitura e fazer
Quando existe um sistema de locks distribudos, o cliente que possui um lock caching arbitrrio do mesmo. Um oplock pode ser retirado ao cliente pelo servidor.
sobre um ficheiro pode usar esse conhecimento para melhorar a gesto da sua Mandatory locks que permitem acessos exclusivos e caching e que no podem ser
cache. retirados pelo servidor
Se o cliente possui um lock de leitura partilhada, ????
Se o cliente possui um lock de leitura partilhada, o ficheiro no pode ser escrito por
outros e portanto enquanto o lock for vlido no ser modificado os testes de
validade do ficheiro cached so inteis. Os clientes fazem ou no caching dos ficheiros conforme o tipo de lock que tm.
Se no tm nenhum podem sempre aceder ao ficheiro mas sem fazer caching do
Se o cliente possui um lock de escrita exclusiva, ???? mesmo.
Se o cliente possui um lock de escrita exclusiva, o ficheiro no pode ser escrito por
outros e basta fazer escritas peridicas para minorar problemas em caso de crash.
Ilustrao Gesto dos oplocks
1. O primeiro cliente obtm:

Neste exemplo ilustra-se a utilizao de oplocks para acesso ao ficheiro 1. Oplock exclusivo caso pretenda escrever o ficheiro
F1 por dois clientes A e B. 2. Oplock partilhado caso pretenda apenas ler o ficheiro
2. Quando surgem novos clientes de leitura:

1. Existe um cliente com oplock exclusivo
Cliente perde lock e deve enviar as modificaes efectuadas
client A server client B Ambos os clientes ficam sem oplocks (e portanto sem poder fazer cache)
2. Existe um cliente com oplock partilhado
Ambos os clientes ficam com oplock partilhado
(1) access F1
3. Quando surge um novo cliente de escrita
(2) Oplock and data for F1 Cliente perde lock e deve enviar as modificaes efectuadas
client A server client B
Ambos os clientes ficam sem oplocks (e portanto sem poder fazer cache)
2. Existe um (ou mais) clientes com oplock partilhado
(3) access F1
(4) revoke lock from F1 Clientes perdem o oplock
Todos os clientes ficam sem oplocks (e portanto sem poder fazer cache)
(5) oplock and updated (6) updated data for F1

client A data for F1 (if any) but no oplock client B
server
Gesto dos oplocks (cont.) Callback promise
Optimizao: Quando um ficheiro aberto para leitura/escrita tenta-se prolongar Introduzido no AFS e usado tambm no Coda.
a concorrncia, assumindo que o cliente de leitura at primeira escrita
nessa altura troca-se de oplock. Neste sistema os clientes fazem caching de ficheiros inteiros (replica),
sendo o ficheiro a unidade de transferncia entre o cliente e o servidor.
Se um cliente perde um oplock, deixa de fazer caching desse ficheiro. Quando um cliente obtm um cpia do ficheiro, o servidor promete
informar o cliente de qualquer modificao efectuada ao ficheiro a esta
promessa chama-se uma callback promise.
Desde que o cliente tenha uma callback promise vlida, assume que a
sua cpia do ficheiro est actualizada. Neste caso, um ficheiro aberto
no cliente sem nenhuma comunicao com o servidor.
Quando um programa no cliente fecha um ficheiro que acabou de
modificar, o cliente AFS/Coda envia as modificaes para o servidor.
Nessa altura, o servidor notifica todos os clientes com callback promises
vlidas.
Um cliente, ao receber a notificao, anula a sua callback promise e, se
o ficheiro estiver aberto, obtm uma nova cpia do ficheiro.
6
Funcionamento usando callback promise Soluo Callback promise
User process UNIX kernel Venus Net Vice
open(FileName,
mode)
If FileName refers to a
file in shared file space, Com este esquema todos as escritas feitas no cliente so temporrias at ao
Check list of files in
pass the request to
Venus.
local cache. If not fecho do ficheiro. Desta forma, a nica semntica que pode ser implementada
present or there is no
valid callback promise, uma semntica dita semntica de sesso. Com esta semntica, uma leitura l o
send a request for the
file to the Vice server resultado das escritas feitas depois do ltimo close do ficheiro.
that is custodian of the
Transfer a copy of the
Quando um cliente inicializado, ele tem de revalidar as calback promises que
volume containing the
file. file and a callback
promise to the
workstation. Log the tem. Porqu?
Place the copy of the callback promise.
file in the local file Pode ter perdido os calbacks feitas pelo servidor enquanto o cliente esteve
Open the local file and system, enter its local
return the file name in the local cache desligado.
descriptor to the list and return the local
application. name to UNIX.
read(FileDescriptor, Perform a normal
Buffer, length) UNIX read operation
on the local copy.
write(FileDescriptor, Perform a normal
Buffer, length) UNIX write operation
on the local copy.
close(FileDescriptor) Close the local copy
and notify Venus that
the file has been closed. If the local copy has
been changed, send a
copy to the Vice server Replace the file
that is the custodian of contents and send a
the file. callback to all other
clients holding callback
promises on the file.
Coda Estrutura do sistema Coda
Sistema de ficheiros distribudo, descendente do AFS

Workstations Servers
Servidores replicam volumes (hierarquia de directrios): rplicas principais
User Venus
program
Clientes replicam subconjunto de ficheiros: rplica secundria (ou cache) Vice
Ficheiros so replicados completamente UNIX kernel
Utiliza aproximao callback promise UNIX kernel

Modificaes no servidor notificadas aos clientes que replicam ficheiros
User Venus Network
program
UNIX kernel
Vice
Venus
User
program UNIX kernel
UNIX kernel
Funcionamento dos system calls Replicao no sistema Coda
Aproximao optimista
Workstation Permite a operao mesmo com particionamento da rede e durante perodos de
desconexo
Cada cliente mantm dois conjuntos relativamente a cada volume :

VSG conjunto de servidores que replicam o volume
User
Venus AVSG sub-conjunto dos servidores VSG activos
program
UNIX file Non-local file Cada ficheiro tem associado um vector-verso (semelhante a um relgio
system calls operations vectorial), que identifica a sua verso
No vector-verso existe uma entrada para cada servidor do VSG
UNIX kernel
UNIX file system
Local
disk
7
Replicao no sistema Coda: leitura Replicao no sistema Coda: leitura
Um cliente obtm uma cpia de um [1,1,1] [1,1,1] [1,1,1] Um cliente obtm uma cpia de um [1,1,1] [1,1,1] [1,1,1]
ficheiro a partir de um elemento do ficheiro a partir de um elemento do
AVSG, verificando com todos qual o AVSG, verificando com todos qual o
que tem a verso mais actual que tem a verso mais actual
O cliente obtm a cpia do ficheiro

[1,1,1] [1,1,1] de um dos servidores com a verso
[1,1,1]
mais actual. Fica com uma callback
promise nesse servidor (e s
nesse).
Se existirem diferentes verses, os

servidores so informados para se
sincronizarem
Replicao no sistema Coda: escrita Replicao no sistema Coda: escrita
Quando o ficheiro fechado, o [1,1,1] [1,1,1] [1,1,1] Quando o ficheiro fechado, o [2,1,1] [1,2,1] [1,1,1]
cliente escreve a nova verso em cliente escreve a nova verso em
todos os servidores do AVSG todos os servidores do AVSG
Os servidores actualizam o seu

[1,1,1] vector-verso e enviam-no ao cliente [1,2,1]
[2,1,1]
[1,1,1]
Replicao no sistema Coda: escrita Deteco da inconsistncia: leitura
Quando o ficheiro fechado, o [2,2,1] [2,2,1] [1,1,1] Seoovector-verso

Se vector-versodos
dosvrios
vrios [2,2,1] [2,2,1] [1,1,1]
cliente escreve a nova verso em servidoresdiferente
servidores diferente
todos os servidores do AVSG
Dadosdois
Dados doisvectores-verso,
vectores-verso,v1
v1eev2:
v2:
Os servidores actualizam o seu Se v2 > v1, ?v2 uma verso mais actual
vector-verso e enviam-no ao cliente [2,2,1] Se v2 || v1, ?existiram escritas
[2,2,1] [2,2,1] [1,1,1]

concorrentes
O cliente combina os vectores verso
e envia-os aos servidores, que [2,2,1]
actualizam o ser vector-verso
Como poderia surgir uma escrita

Os servidores notificam os [2,2,1] concorrente?
clientes com callback promises
das alteraes nos ficheiros
8
Deteco da inconsistncia: escrita Tratamento de conflitos
Se quando se envia uma escrita, o [2,2,1] [2,2,1] [1,1,1] Resoluo manual (inicial)
vector-verso da verso modificado Quando existem modificaes concorrentes a um ficheiro, os ficheiros so marcados
for inferior ao da rplica actual como em conflito e o acesso impedido at o conflito ser resolvido por um utilizador
porque existiu uma modificao
Resoluo automtica
concorrente (conflito)
[1,1,1] Podem-se definir programas que, em caso de conflito, so executados para gerar o
estado final do ficheiro a partir das diferentes verses
Modificaes concorrentes em directorias so resolvidas automaticamente
[1,1,1]
Coerncia da cache Suporte desconexo
A coerncia da cache mantida pelo mecanismo de callback promise Clientes replicam subconjunto de ficheiros completos: rplica secundria (ou
cache) mantida por replicao antecipada (pre-fetching)
Um cliente invalida uma callback promise se o conjunto AVSG aumenta (i.e., se Utilizadores especificam ficheiros crticos para replicao
um servidor passa a estar acessvel). Porqu? ltimos ficheiros utilizados tambm ficam na cache (caching tradicional)
Porque que para suportar desconexo replicar o ficheiro completo uma boa
Cada servidor mantm, alm do vector verso para cada ficheiro, um vector
soluo?
verso para um volume. Um cliente invalida uma callback promise se, ao
contactar os servidores, verifica que eles tm diferentes vectores verso de Durante a desconexo
volume. Porqu? Registo das operaes efectuadas
Qual o interesse deste vector-verso?
Na reconexo
Reintegrao das modificaes efectuadas, re-executando lista de operaes
executadas e detectando/resolvendo eventuais conflitos
Para saber mais
G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems - Concepts and

Design, Addison-Wesley, 4th Edition, 2005
Captulo 8. Corresponde matria aqui apresentada mas no cobre o sistema SMB/
CIFS nem os esquemas de controlo de concorrncia baseados em oplocks e tokens.
9
LEI (1 ciclo) 2010/2011
Captulo 8
Introduo aos sistemas distribudos de gesto de ficheiros
Nota prvia

1
Sistemas de ficheiros distribudos
Um sistema de gesto de ficheiros distribudos fornece um servio de

acesso a ficheiros semelhante ao de um sistema de ficheiros normal, mas
estendido a um conjunto de mquinas ligadas em rede. Normalmente
permite:
Partilha de ficheiros por vrios utilizadores
Melhor qualidade de servio do que a disponvel localmente

Maior dimenso do espao disponvel
Melhor tolerncia a falhas
Desempenho semelhante ou superior
Algumas questes envolvidas na distribuio
Integrao: como integrar no sistema de ficheiro local?
Designao: como designar os ficheiros remotos?

Externamente: ao nvel das aplicaes
Internamente: no sistema
Modelo de acesso: dois extremos: acesso completamente remoto ou

acesso completamente local (usando cache).
Partilha de ficheiros: problemas relacionados com o controlo da concorrncia
e modelo de consistncia fornecido
2
Integrao no sistema local
Os ficheiros dum sistema distribudo de ficheiros devem ser acedidos

localmente numa mquina
Problema: Qual a granularidade da partilha?
Soluo tpica: sub-rvore do sistema de ficheiros
Problema: Como providenciar acesso aos ficheiros?
Soluo: integrar a sub-rvore na hierarquia local

Windows: definindo uma nova drive
Unix-like: atravs do mecanismo de mount
Exemplo: mount remoto e designao no NFS
Server 1 Client Server 2

(root) (root) (root)
export ... vmunix usr nfs
Remote Remote
people students x staff users
mount mount
big jon bob ... jim ann jane joe
Cada servidor exporta um conjunto de directorias.
O cliente pode montar uma directoria remota (caso tenha permisses) numa
directoria local (ex.: /usr/students no cliente monta a rvore /export/people no
Server 1)
3
Integrao no sistema local (cont.)
Como fazer a integrao ?
Soluo: os sistemas de operao normalmente suportam mecanismos

para definir novos sistemas de ficheiros
Unix-like: VFS
Windows: IFS
Arquitectura
Client computer Server computer
Application Application
program program
UNIX
system calls
UNIX kernel
UNIX kernel Virtual file system Virtual file system
Local Remote
file system
UNIX NFS NFS UNIX

file file
Other
client server
system system
NFS
protocol
4
Designao dos ficheiros
Tipos dos nomes dos ficheiros:
Nomes simblicos
(exemplo: /x/y/p/q )
Nomes internos ao sistema

(exemplos: FileId, File-handles, UFIDs)
Endereos internos ao servidor:

(exemplo: n device, n i-node, endereo de bloco, )
Tipos dos nomes simblicos
Nomes globais. Podem ser passados entre mquinas mas implicam a introduo
de uma super-raiz do file system.
Uma forma popular : //servername/ficheiro
Exemplo: //asc.di.fct.unl.pt/home/foobar
Nomes contextuais. Todos os nomes so interpretados a partir de um file system

local.
Fceis de implementar mas difcil passar um nome entre duas mquinas
Ligaes (mounts)
Um mesmo nome em duas mquinas pode referir o mesmo ou diferentes ficheiros
Nomes diferentes em duas mquinas podem referir o mesmo ficheiro
5
Caractersticas dos nomes internos
Para que os clientes e os servidores possam memorizar UFIDs (ou file

handles) sem que os mesmos possam dar origem a ambiguidades, estes
devem ser:
nicos no tempo
nicos no espao
Que propriedades tem um NFS file handle ?

[ file system number, file i-node, i-node generation number ],
endereo IP do servidor, porta do servidor
Capacidades e UFIDS
possvel definir identificadores de baixo nvel cuja posse garante o direito de

realizar operaes sobre um objecto. Tratam-se de identificadores que podem ser
copiados, mas que no podem ser forjados. Este tipo de identificadores tm as
vantagens de uma capacidade (e os defeitos tambm).
Exemplo:
64 bits 64 bits 64 bits
Communication end point file handle - random operations
UFID - Unique File Identifier
Os dois campos direita tm de ser cifrados ou assinados para no serem

alterveis.
6
Caractersticas do mtodo
Vantagens
Favorece a modularidade e a independncia das componentes
Favorece solues stateless, mas
Desvantagens
A revogao ou simples modificao dos direitos impossvel ou simplesmente

difcil
Exige cuidados especiais para impedir a cpia das capacidades ou o acesso

indevido s mesmas
Geralmente usam-se como complemento de um sistema baseado em ACLs,

atravs de short-lived ou session capabilities.
Servidores stateless vs. Servidores stateful
Um sistemas de ficheiros distribudos pode ser desenhado recorrendo a servidores

stateless ou stateful.
Um servidor que no mantm informao sobre os clientes chama-se stateless.
Um servidor que mantm informao sobre os clientes chama-se stateful.
7
Servidores stateless
Considere um sistema de ficheiros local. Neste, o sistema mantm informao

sobre o estado do cliente, ficheiros abertos, posio de leitura/escrita nos
ficheiros, etc. Como desenhar um sistema distribudo stateless, em que o servidor
no mantm nenhuma desta informao?
Criar as operaes de modo a que incluam toda a informao necessria sua

execuo
Exemplo: operaes NFS

Nomes so resolvidos atravs de uma
sequncia de operaes de lookup, uma para
cada elemento do caminho. Porqu?
lookup(dirfh, name) -> fh, attr Returns file handle and attributes for the file name in the directory
dirfh.
create(dirfh, name, attr) -> Creates a new file name in directory dirfh with attributes attr and
call.)
fh, newfh so identificadores de ficheiros
opacos
Continua ...
8
Exemplo: operaes NFS
lookup(dirfh, name) -> fh, attr Returns file handle and attributes for the file name in the directory
dirfh.
create(dirfh, name, attr) -> Creates a new file name in directory dirfh with attributes attr and
call.)
Operaes read e write so idempotentes. Como?

Atravs da adio da posio a ler/escrever Continua ...
Servidores stateful
Nesta aproximao, o servidor mantm informao sobre quais so os

clientes e o seu estado (e.g. ficheiros abertos, posio de leitura/escrita,
etc.)
Exemplo: protocolo CIFS/SMB
9
Servidores stateless vs. Servidores stateful
Propriedades stateless
Mascara mais facilmente as falhas dos servidores e de comunicaes.
Porqu?
No h limite terico para o nmero de utilizadores simultneos. Porqu?
No existe necessidade de propagar operaes OPEN / CLOSE. Porqu?
Propriedades stateful
Operaes podem ser mais simples e mais simples ter semntica
equivalente dos sistemas centralizados. Porqu?
Permitem implementar locks mais facilmente. Porqu?
Tendem a permitir uma poltica de caching tambm mais eficaz (como

veremos a seguir)
Operaes idempotentes
possvel desenhar um interface com (quase todas as) operaes idempotentes

e.g. NFS
Para algumas operaes fcil: ex.: read, write, etc. Como?
Para outras operaes no possvel (ex.: rename, mkdir, rmdir). Porqu?
Para estas operaes, comum o servidor manter uma pequena cache das ltimas
operaes deste tipo, implementando uma semntica at-most-once simplificada.
A utilizao de operaes idempotentes simplifica o protocolo e a implementao

do servidor. Porqu?
Estado mantido pelo servidor nulo (ou mnimo)
Protocolo RPC pode implementar semntica at-least-once. Porque que mais
simples?
Se tudo estiver a funcionar bem, um crash do servidor seguido da sua

recuperao, uma interrupo momentnea da rede, ou a perca de alguns
pacotes, so falhas que so mascaradas facilmente pelo conjunto do sistema
Como?
10
Falhas: no to simples como parece...
Cache no (SO do) servidor levanta alguns problemas na presena de falhas.

Quais?
Solues possveis?
Exemplo NFS:
Verso 2: o write apenas retornava aps a escrita ser efectuada em disco (cache
write-through). Porqu? Quais os problemas?
Verso 3: o write escreve na cache do file-system (como qualquer write local). A
operao commit permite garantir que as escritas efectuadas foram escritas em disco
(normalmente executado aquando do close).
Modelos de Caching : informao replicada
Quase todos os sistemas de ficheiros distribudos mantm um cache que pode ter
diferentes caractersticas

Modelo Caching de Ficheiros inteiros. Guarda ficheiros completos na cache

sempre que necessrio aceder a um ficheiro, este transferido para a mquina do
cliente. Nota: caching efectuado normalmente em disco.
Eficincia?
Depende da fraco de operaes que podem ser servidas
pelos valores guardados na cache.
Caching fich. inteiros > caching blocos > sem caching
11
Modelos de Caching : informao replicada
Quase todos os sistemas de ficheiros distribudos mantm um cache que pode ter
diferentes caractersticas

Modelo Caching de Ficheiros inteiros. Guarda ficheiros completos na cache

sempre que necessrio aceder a um ficheiro, este transferido para a mquina do
cliente. Nota: caching efectuado normalmente em disco.
Coerncia?
Depende do modo como verificada a validade da cache
Sem caching > caching blocos > caching fich. inteiros
Acessos concorrentes em sistemas tradicionais
Nos sistemas de ficheiros centralizados, a semntica dos acessos concorrentes

definida por:
Uma poltica por omisso
E um mecanismo de locks
No sistema Unix (e Linux ), a poltica por omisso do tipo serializao das

operaes sobre cada ficheiro: uma leitura l sempre o resultado da ltima
escrita.
Existe ainda um sistema de locks que permite garantir acessos sem conflitos
(write / write ou read / write ) por dois processos distintos.
Exemplo de system call para manipular locks no sistema Unix:
result = flock(filedes, offset, range, locktype)
Nos sistemas centralizados estas polticas so relativamente fceis de

implementar pois s existe um sistema de gesto de ficheiros e uma cache
12
Acessos concorrentes distribudos
Quando o sistema de gesto de ficheiros distribudo o problema do acesso

partilhado e do controlo da concorrncia mais difcil de resolver. Porqu?
Os mtodos usados para lidar com este aspecto podem agrupar-se em mtodos
pessimistas ou mtodos optimistas.
Os mtodos pessimistas tentam esconder que existem vrias cpias e procuram

emular o melhor possvel a semntica do sistema centralizado a distribuio
mais transparente.
Estes sistemas poderiam descrever-se como sistemas com equivalncia a uma s
cpia (one copy serializability).
Os mtodos optimistas tentam no esconder totalmente a replicao e o

caching em troca de um maior desempenho, adaptao escala e flexibilidade.
No limite so os nicos aplicveis em sistemas mveis quando se pretende admitir
acesso em escrita com desconexo.
Controlo de concorrncia pessimista com servidores

stateless
A semntica tradicional centralizada consiste em uma leitura ver sempre o
resultado da ltima escrita (serializao dos acessos).
A semntica dum esquema de gesto das caches depende do que se faz nas
operaes de leitura e escrita:
Associado s escritas est a propagao das modificaes para o servidor (e sua
visualizao por outros clientes).
Associada s leituras est a verificao da coerncia da cache em relao ao servidor.
13
Modelo da cache do NFS
Os sistemas Unix usam sempre caching de ficheiros locais, em memria central. A

poltica convencional satisfazer os pedidos de leitura da cache se possvel e usar
read-ahead e delayed-write (30 segundos no mximo) dos ficheiros locais.
O mdulo cliente do NFS coloca tambm na cache local os blocos que l do
servidor e utiliza um sistema de timestamps para controlar a respectiva validade.
H duas timestamps associadas a cada bloco na cache:
Tc - ltima hora a que esta entrada na cache foi validada (hora local)
Tw-client - estampilha horria da ltima vez que o ficheiro foi escrito (hora do servidor
tal como est registada actualmente no cliente)
No momento T, considera-se vlida uma entrada na cache sse: T-Tc< t Caso

contrrio, necessrio verificar se o ficheiro no foi alterado no servidor, i.e., se
Tw-server = Tw-client
Se t grande pode resultar incoerncia, se t pequeno pode resultar ineficincia.
Porque que (quase) todas as operaes NFS

retornam atributos do ficheiro?
Modelo da cache do NFS (2)
O valor de t calculado de forma dinmica e varia entre 3 e 30 segundos para

ficheiros (o valor menor quanto mais frequentemente o ficheiro escrito) e
entre 30 e 60 segundos para directrios (estratgia idntica).
Se T - Tc < t, o segundo teste no realizado, caso contrrio executado um

getattr request ao servidor e os valores de Tc e Tw so actualizados.
Se Tw-server Tw-client todos os blocos do ficheiro so retirados da cache pois o
ficheiro foi modificado.
Para optimizar, os valores de Tw so aplicados a todos os blocos do mesmo ficheiro e
os atributos do ficheiro so piggybacked sempre que possvel com todas as respostas
do servidor (ver a definio das operaes NFS)
Qual o problema de manter apenas um Tw para cada ficheiro?
Os blocos modificados por uma escrita no cliente so marcados como dirty e

enviados assincronamente para o servidor ou logo que um sync ocorre no cliente.
Como se comporta esta aproximao

com um sistema de bases de dados?
14
Gesto da cache com servidores stateless
Leituras. Para garantir a frescura da informao cached, os clientes de

servidores stateless tm de testar a validade da mesma:
teste antes de cada acesso - aumenta a coerncia mas diminui a performance
teste peridico - semntica sem garantias totais
Escrita. A propagao de escritas pode ser efectuada em vrios momentos.

Escrita Write-through. A cada escrita no cliente corresponde uma (ou mais) escritas
no servidor. Propriedades?
Favorece a fiabilidade e a semelhana com a semntica tradicional tipo sistema
equivalente a uma s cpia custa do sacrifcio do desempenho.
Escrita Delayed-Write. As escritas so inicialmente efectuadas na cache local e,

posteriormente, enviadas para o servidor. Propriedades?
Este esquema diminuem o trfego de rede mas diminui a fiabilidade e consistncia.
Quando o servidor stateless e ignora os clientes, no possvel implementar a
semntica equivalncia a uma s cpia.
NFS: Gesto da cache com servidores stateless
NFS
Escrita: delayed-write, read-ahead
Leitura: testa periodicamente
Para que tipo de ambiente apropriado?
Acesso aos ficheiros num ambiente de desenvolvimento de software ou

de partilha no simultnea dos ficheiros. O resultado um sistema com
uma semntica de carcter probabilstico, mas com muito sucesso no
ambiente alvo e que afinal mais optimista que pessimista.
15
Gesto da cache com servidores stateful
Aproximao controlada pelo servidor: o servidor (stateful) anota cada cliente de

um ficheiro e o modo de acesso e gere um sistema de notificaes de alteraes,
assim como mecanismos baseados em tokens e locks para ajudar os clientes a
melhorarem o seu desempenho.
Quando existe um sistema de locks distribudos, o cliente que possui um lock

sobre um ficheiro pode usar esse conhecimento para melhorar a gesto da sua
cache.
Se o cliente possui um lock de leitura partilhada, ????
Se o cliente possui um lock de leitura partilhada, o ficheiro no pode ser escrito por
outros e portanto enquanto o lock for vlido no ser modificado os testes de
validade do ficheiro cached so inteis.
Se o cliente possui um lock de escrita exclusiva, ????

Se o cliente possui um lock de escrita exclusiva, o ficheiro no pode ser escrito por
outros e basta fazer escritas peridicas para minorar problemas em caso de crash.
Gesto de cache no sistema CIFS: Opportunistic locks
Neste esquema, introduzido no sistema CIFS (sucessor do SMB), existem vrios

tipos de locks:
Opportunistic locks (oplocks) exclusivos que permitem ao cliente ter acesso exclusivo
ao ficheiro e fazer caching arbitrrio do mesmo. Um oplock pode ser retirado ao
cliente pelo servidor.
Oplocks partilhados que permitem aos clientes ter acesso ao ficheiro em leitura e fazer
caching arbitrrio do mesmo. Um oplock pode ser retirado ao cliente pelo servidor.
Mandatory locks que permitem acessos exclusivos e caching e que no podem ser
retirados pelo servidor
Os clientes fazem ou no caching dos ficheiros conforme o tipo de lock que tm.
Se no tm nenhum podem sempre aceder ao ficheiro mas sem fazer caching do
mesmo.
16
Ilustrao
Neste exemplo ilustra-se a utilizao de oplocks para acesso ao ficheiro

F1 por dois clientes A e B.
(1) access F1
(2) Oplock and data for F1

(3) access F1
(4) revoke lock from F1
(5) oplock and updated (6) updated data for F1

client A data for F1 (if any) client B
server but no oplock
Gesto dos oplocks
1. O primeiro cliente obtm:

1. Oplock exclusivo caso pretenda escrever o ficheiro
2. Oplock partilhado caso pretenda apenas ler o ficheiro
2. Quando surgem novos clientes de leitura:

2. Existe um cliente com oplock partilhado
Ambos os clientes ficam com oplock partilhado
3. Quando surge um novo cliente de escrita

2. Existe um (ou mais) clientes com oplock partilhado
Clientes perdem o oplock
Todos os clientes ficam sem oplocks (e portanto sem poder fazer cache)
17
Gesto dos oplocks (cont.)
Optimizao: Quando um ficheiro aberto para leitura/escrita tenta-se prolongar

a concorrncia, assumindo que o cliente de leitura at primeira escrita
nessa altura troca-se de oplock.
Se um cliente perde um oplock, deixa de fazer caching desse ficheiro.
Callback promise
Introduzido no AFS e usado tambm no Coda.

Neste sistema os clientes fazem caching de ficheiros inteiros (replica),
sendo o ficheiro a unidade de transferncia entre o cliente e o servidor.
Quando um cliente obtm um cpia do ficheiro, o servidor promete
informar o cliente de qualquer modificao efectuada ao ficheiro a esta
promessa chama-se uma callback promise.
Desde que o cliente tenha uma callback promise vlida, assume que a
sua cpia do ficheiro est actualizada. Neste caso, um ficheiro aberto
no cliente sem nenhuma comunicao com o servidor.
Quando um programa no cliente fecha um ficheiro que acabou de
modificar, o cliente AFS/Coda envia as modificaes para o servidor.
Nessa altura, o servidor notifica todos os clientes com callback promises
vlidas.
Um cliente, ao receber a notificao, anula a sua callback promise e, se
o ficheiro estiver aberto, obtm uma nova cpia do ficheiro.
18
Funcionamento usando callback promise
User process UNIX kernel Venus Net Vice
open(FileName, If FileName refers to a
mode) file in shared file space,
pass the request to Check list of files in
local cache. If not
Venus. present or there is no
valid callback promise,
send a request for the
file to the Vice server
that is custodian of the
volume containing the Transfer a copy of the
file. file and a callback
promise to the
workstation. Log the
Place the copy of the callback promise.
file in the local file
Open the local file and system, enter its local
return the file name in the local cache
descriptor to the list and return the local
application. name to UNIX.
read(FileDescriptor, Perform a normal
Buffer, length) UNIX read operation
on the local copy.
write(FileDescriptor, Perform a normal
Buffer, length) UNIX write operation
on the local copy.
close(FileDescriptor) Close the local copy
and notify Venus that
the file has been closed. If the local copy has
been changed, send a
copy to the Vice server Replace the file
that is the custodian of contents and send a
the file. callback to all other
clients holding callback
promises on the file.
Soluo Callback promise
Com este esquema todos as escritas feitas no cliente so temporrias at ao

fecho do ficheiro. Desta forma, a nica semntica que pode ser implementada
uma semntica dita semntica de sesso. Com esta semntica, uma leitura l o
resultado das escritas feitas depois do ltimo close do ficheiro.
Quando um cliente inicializado, ele tem de revalidar as calback promises que

tem. Porqu?
Pode ter perdido os calbacks feitas pelo servidor enquanto o cliente esteve
desligado.
19
Coda
Sistema de ficheiros distribudo, descendente do AFS
Servidores replicam volumes (hierarquia de directrios): rplicas principais
Clientes replicam subconjunto de ficheiros: rplica secundria (ou cache)

Ficheiros so replicados completamente
Utiliza aproximao callback promise

Modificaes no servidor notificadas aos clientes que replicam ficheiros
Estrutura do sistema Coda
Workstations Servers
User Venus
program
Vice
UNIX kernel
UNIX kernel
User Venus Network

program
UNIX kernel
Vice
Venus
User
program UNIX kernel
UNIX kernel
20
Funcionamento dos system calls
Workstation
User
Venus
program
UNIX file Non-local file
system calls operations
UNIX kernel
UNIX file system
Local
disk
Replicao no sistema Coda
Aproximao optimista
Permite a operao mesmo com particionamento da rede e durante perodos de
desconexo
Cada cliente mantm dois conjuntos relativamente a cada volume :

VSG conjunto de servidores que replicam o volume
AVSG sub-conjunto dos servidores VSG activos
Cada ficheiro tem associado um vector-verso (semelhante a um relgio

vectorial), que identifica a sua verso
No vector-verso existe uma entrada para cada servidor do VSG
21
Replicao no sistema Coda: leitura
Um cliente obtm uma cpia de um [1,1,1] [1,1,1] [1,1,1]

ficheiro a partir de um elemento do
AVSG, verificando com todos qual o
que tem a verso mais actual
[1,1,1] [1,1,1]
Replicao no sistema Coda: leitura
Um cliente obtm uma cpia de um [1,1,1] [1,1,1] [1,1,1]

ficheiro a partir de um elemento do
AVSG, verificando com todos qual o
que tem a verso mais actual
O cliente obtm a cpia do ficheiro

[1,1,1]
de um dos servidores com a verso
mais actual. Fica com uma callback
promise nesse servidor (e s
nesse).
Se existirem diferentes verses, os

servidores so informados para se
sincronizarem
22
Replicao no sistema Coda: escrita
Quando o ficheiro fechado, o [1,1,1] [1,1,1] [1,1,1]

cliente escreve a nova verso em
[1,1,1]
[1,1,1]


vector-verso e enviam-no ao cliente [1,2,1]
[2,1,1]
23


vector-verso e enviam-no ao cliente [2,2,1]
O cliente combina os vectores verso
e envia-os aos servidores, que [2,2,1]
actualizam o ser vector-verso
Os servidores notificam os [2,2,1]

clientes com callback promises
das alteraes nos ficheiros
Deteco da inconsistncia: leitura
Seoovector-verso
Se vector-versodos
dosvrios
vrios [2,2,1] [2,2,1] [1,1,1]
servidoresdiferente
servidores diferente
Dadosdois
Dados doisvectores-verso,
vectores-verso,v1
v1eev2:
v2:
Se v2 > v1, ?v2 uma verso mais actual
Se v2 || v1, ?existiram escritas
[2,2,1] [2,2,1] [1,1,1]

concorrentes
Como poderia surgir uma escrita

concorrente?
24
Deteco da inconsistncia: escrita
Se quando se envia uma escrita, o [2,2,1] [2,2,1] [1,1,1]

vector-verso da verso modificado
for inferior ao da rplica actual
porque existiu uma modificao
concorrente (conflito)
[1,1,1]
[1,1,1]
Tratamento de conflitos
Resoluo manual (inicial)

Quando existem modificaes concorrentes a um ficheiro, os ficheiros so marcados
como em conflito e o acesso impedido at o conflito ser resolvido por um utilizador
Resoluo automtica
Podem-se definir programas que, em caso de conflito, so executados para gerar o
estado final do ficheiro a partir das diferentes verses
Modificaes concorrentes em directorias so resolvidas automaticamente
25
Coerncia da cache
A coerncia da cache mantida pelo mecanismo de callback promise
Um cliente invalida uma callback promise se o conjunto AVSG aumenta (i.e., se

um servidor passa a estar acessvel). Porqu?
Cada servidor mantm, alm do vector verso para cada ficheiro, um vector
verso para um volume. Um cliente invalida uma callback promise se, ao
contactar os servidores, verifica que eles tm diferentes vectores verso de
volume. Porqu?
Qual o interesse deste vector-verso?
Suporte desconexo
Clientes replicam subconjunto de ficheiros completos: rplica secundria (ou

cache) mantida por replicao antecipada (pre-fetching)
Utilizadores especificam ficheiros crticos para replicao
ltimos ficheiros utilizados tambm ficam na cache (caching tradicional)
Porque que para suportar desconexo replicar o ficheiro completo uma boa
soluo?
Durante a desconexo
Registo das operaes efectuadas
Na reconexo
Reintegrao das modificaes efectuadas, re-executando lista de operaes
executadas e detectando/resolvendo eventuais conflitos
26
Para saber mais
G. Coulouris, J. Dollimore and T. Kindberg, Distributed Systems - Concepts and

Design, Addison-Wesley, 4th Edition, 2005
Captulo 8. Corresponde matria aqui apresentada mas no cobre o sistema SMB/
CIFS nem os esquemas de controlo de concorrncia baseados em oplocks e tokens.
27

SD Slides

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SD Slides

Enviado por

Direitos autorais:

Formatos disponíveis

Sistema distribudo?

Um sistema distribudo um conjunto de componentes

Vitor Duarte (T, P1, P2)

Motivaes dos Sistemas Distribudos Principais objectivos da cadeira

Programa das aulas tericas Bibliografia

Introduo aos sistemas distribudos Principal:

Invocao de mtodos/procedimentos remotos

Sistemas Distribudos 1 ciclo Pressuposto: alunos conhecem primitivas de comunicao TCP/IP

Web services SOAP e REST

Sistemas Distribudos 2 ciclo

Nomeao e Sist. Ficheiros distribudos

Material didctico Avaliao (1)

Hardware: Componentes da avaliao: exame final (70%) e frequncia (30%)

http://clip.unl.pt/ Nota de frequncia = 50% * teste + 50% * trabalho

Avaliao (2) Avaliao (3)

Trabalho prtico Melhorias de nota ou alunos com frequncia positiva.

1 No Segurana Segurana Cripto TRAB Trabalho prtico: enunciado na semana de 11 de Outubro

A estrutura da apresentao semelhante e utiliza algumas das

Sistemas Distribudos G. Coulouris, J. Dollimore and T. Kindberg,

Organizao do captulo Definio de sistema distribudo

Definio, exemplos de sistemas distribudos Um sistema distribudo um conjunto de componentes

No mbito desta cadeira, vamos esquecer os sistemas que

Exemplo: servios na Internet Exemplo: servios em intranets

email server Desktop

File server print

Internet/Intranet + Abre a possibilidade de criar novas aplicaes distribudas

Outros exemplos Motivaes dos Sistemas Distribudos

Clusters de computadores interligados atravs de redes de alta

Vantagens potenciais para as aplicaes/servios Desenvolvimento de SD

Ubiquidade e mobilidade Como desenvolver os componentes software em SD (ou pr a

Simplicidade associada modularidade fsica

Principais Desafios Heterogeneidade

Heterogeneidade Do hardware: telemveis, PDAs, portteis (laptops), workstations

Segurana Do sistema de operao: MSWindows, Unix/Linux/Mac, Simbian, ...

Construir um sistema nico, integrado, coerente, etc. geralmente um

Middleware Mquina virtual

N computadores interligados Objectivo: permitir executar os mesmos programas em mquinas

Alguns tipos de transparncia Concorrncia

O acesso simultneo a um recurso por vrios clientes

Desempenho/ Esconde a reconfigurao para melhorar o desempenho/

Como lidar com a escala ? Falhas (avarias, erros )

Como lidar com as falhas Como lidar com as falhas

Detectar falhas Tolerar falhas

G. Coulouris, J. Dollimore and T. Kindberg,

Material de suporte s aulas de SD/LEI (1 ciclo) Copyright DI FCT/ UNL - 31

A estrutura da apresentao semelhante e utiliza algumas das

Sistemas Distribudos G. Coulouris, J. Dollimore and T. Kindberg,

Arquitecturas e Modelos de Sistemas Distribudos

Terminologia Organizao do captulo

Sistema de operao Sistema de operao

O middleware fornece uma interface homognea (esconde a

Limitaes: algumas funcionalidades apenas podem ser implementadas de

Arquitectura do sistema Cliente Servidor

Sistema em que os processos podem ser divididos em dois tipos, de

Cliente/Servidor: propriedades Modelo peer-to-peer

Modelo simples (o mais comum e usado na prtica)

Interaces simples (pedido/resposta)

Servidor um ponto de falha nico

No escala para alm dum dado limite (servidor pode tornar-se um

Segurana apenas tem de se concentrar no servidor

Todos os processos tm funcionalidades semelhantes

Exemplos: partilha de ficheiros, VoIP, edio colaborativa

Modelo peer-to-peer: propriedades Variantes do modelo cliente/servidor: servidor