Você está na página 1de 34

1 SD Cap. 1-4 1 SD Cap.

1-4

• Uma característica importante (ou que pode ser importante


Cap. 1 – Caracterização no futuro) pode ser esquecida.

Schroeder:
Definições:
• Avaliação de um candidato a SD através de sintomas:
• Tanenbaum: “Nós usamos o termo Sistema Distribuído com
o Vários EPs;
o sentido de um Sistema Operacional Distribuído”;
o Hardware de interconexão;
• Mullender: “Um SD é um sistema com vários EPs e vários
o Os EPs falham independentemente;
dispositivos de armazenamento, conectados entre si por uma
o Estado do sistema compartilhado.
rede”;
• Lamport: “Um SD é aquele que não permite que você Coulouris (ed. 2):
produza qualquer tipo de trabalho quando ocorre uma pane
• Compartilhamento de recursos;
numa máquina que você nem sabia que existia”;
• Abertura;
• Coulouris: “Um SD consiste de um conjunto de
• Concorrência;
computadores autônomos conectados por uma rede, cada um
deles equipado com um Software de SD. • Independência de escala;
• Tolerância a falhas;
Definições mais recentes: • Transparência.
• Tanenbaum: “Um SOD é aquele que, para seus usuários,
parece um SO centralizado, mas executa sobre múltiplas Coulouris (ed. 3):
CPUs independentes. O conceito chave aqui é • Heterogeneidade;
transparência, ou seja, os múltiplos processadores utilizados • Abertura;
devem ser invisíveis (transparentes) para o usuário. Outra • Segurança;
forma de expressar a mesma idéia é dizer que o usuário • Independência de escala;
enxerga o sistema como um ‘processador virtual único’, e • Tratamento de falhas;
não como um conjunto de máquinas distintas”; • Concorrência;
• Transparência.
Mullender:
• Definir exatamente um SD é perigoso;
2 SD Cap. 1-4 2 SD Cap. 1-4

Tanenbaum disse que vários sistemas apresentados como O modelo cliente-servidor implementa o compartilhamento de
distribuídos na verdade não eram. Regra geral: se é possível dizer recursos, um dos principais objetivos que motivaram o
qual máquina é responsável por uma tarefa, então não é um SD. desenvolvimento das redes locais.
O acesso aos servidores é feito por meio de requisições, que são
Exemplos de SDs: mensagens enviadas pelo cliente contendo pedidos de ações a serem
feitas pelo servidor.
1 – Unix Distribuído. Ao enviar uma requisição, dizemos que o cliente invoca o servidor.
O Unix talvez seja o sistema operacional multiusuário mais A operação completa, desde o envio da requisição até o recebimento
conhecido. Quando os SDs começaram a ser pesquisados, o Unix era da resposta, é chamada de invocação remota.
largamente utilizado. Muitos pesquisadores adotaram o modelo Unix Um servidor pode ser cliente de outro servidor. Assim, o modelo
como meta: cliente-servidor só é válido para uma única requisição.
• Um modelo Unix que pudesse explorar os recursos de muitos Clientes são entidades ativas, enquanto servidores são passivos.
computadores; Servidores permanecem rodando, esperando pela chegada de
• Desempenho superior ao de uma estação isolada. requisições. Clientes só executam no período em que sua aplicação é
A versão 4BSD do Unix foi extendida para suportar IPC. Este necessária.
recurso foi extendido e explorado na construção dos 1os SDs. Os recursos de uma rede podem ser encapsulados em objetos. Nesse
caso, clientes e servidores podem ser objetos escritos em uma
O Unix introduziu o conceito de sistemas tipo cliente-servidor ao linguagem OO. A invocação remota é substituída pela chamada
possibilitar a construção de servidores acessíveis através de IPC. remota de um método do objeto servidor.
Foi usado como modelo na implementação de vários sistemas:
• A Sun usou-o no desenvolvimento do NFS (Network File 2 – Internet.
System); A Internet é um grande sistema distribuído, fornecendo serviços para
• Também serviu de modelo na implementação do RPC seus usuários como: WWW, email, FTP, etc.
(Remote Procedure Call); Esses serviços são fornecidos da mesma maneira em qualquer lugar.
• NIS (Network Information System); O usuário pode fazer uso deles onde quiser, com a máquina que
• Amoeba (DOS); quiser e quando quiser.
Provedores fornecem o acesso para usuários caseiros. Empresas
• Mach (DOS);
podem contratar linhas de maior capacidade. Todos eles são
• Chorus (DOS);
conectados através de redes de alta capacidade, os backbones, qure
• Andrew (FS);
são fornecidas por provedores de “atacado”.
• Kerberos (Segurança).
3 SD Cap. 1-4 3 SD Cap. 1-4

A Internet manipula diferentes tipos de dados, incluindo multimídia. A computação móvel também é chamada de nômade. Nesse modelo,
Os usuários podem ouvir rádios, ver TV, filmes, participar de o usuário acessa a rede fora de seu ambiente normal (casa ou
reuniões e até fazer ligações telefônicas. escritório) através de dispositivos que ele carrega consigo.
Um aspecto interessante da Internet é que ela possui transparência de Computação “ubiquitous” é realizada por vários dispositivos
escala, permitindo que seu tamanho e aplicações cresçam por várias pequenos e baratos que estão presentes em nosso ambiente (casa,
ordens de magnitude. escritório, ou qualquer outro lugar). O termo sugere uma situação em
Apesar das linhas apresentarem restrições de capacidade, elas que seu uso será tão grande que sua presença será ignorada. Quer
suportam várias aplicações distribuídas. A mais conhecida é o email. dizer, seu comportamento será transparente.
O principal problema do email é encontrar o destinatário através de
um endereço como president@whitehouse.gov ou abc@din.uem.br. 4 – WWW.
Esse tipo de endereço não dá informações de como encontrar o
destinatário (roteamento). Na rede destino não diz em que máquina A Web é um sistema em constante evolução que se baseia em
está o destinatário. documentos hipertextos. Os usuários organizam seu conhecimento
por meio de links. Esse sitema foi concebido em 1945 por Bush. Sua
3 – Intranets. implementação só foi possível com o surgimento da Internet.
A Web é um sistema aberto. Pode ser extendido e implementado de
Intranets são pedaços da Internet administrados em separado e que várias formas sem alterar o funcionamento da base já instalada. Sua
possuem controle de segurança próprio. Podem estar ou não ligados operação é baseada em comunicação e documentação padrões
à grande rede. distribuídos livremente.
P. ex.:
3 – Computação móvel e “ubiquitous”. • Há vários navegadores;
• São implementados em plataformas diferentes;
Integração de pequenos diispositivos móveis com a Internet e • Há várias implementações de servidores.
acréscimo de poder de processamento em máquinas e equipamentos: Qualquer navegador pode recuperar páginas de qualquer servidor.
• Laptops e notebooks;
• Handtops, celulares, etc.; Também é aberta em relação ao tipo de mídia publicado:
• Dispositivos sem fio; • Páginas (texto);
• Dispositivos embutidos em máquinas de lavar, aparelhos de • Programas;
som, microondas, carros, geladeiras, etc. • Imagens;
• Música;
4 SD Cap. 1-4 4 SD Cap. 1-4

• Vídeo; • O tipo de serviço é WWW (http);


• Documentos (Word, PS, PDF, etc.). • O resultado dessa pesquisa é uma página mostrada ao
Se alguém inventar um novo tipo de mídia, objetos desse tipo podem usuário. Essa página não existe (dinâmica). Após seu envio
ser publicados na Web imediatamente. Basta criar um “driver” para para o navegador, ela não será mantida.
tratar esta nova mídia. Os navegadores são construídos para
aceitarem novas funcionalidades por meio de plug-ins. No começo, esses programas eram escritos em CGI, mas hoje há
As páginas receberam funcionalidade para aceitar dados, e não várias opções: PERL, Python, Java, etc.
apenas mostrá-los.
Problemas da Web:
A Web evolui de um sistema de visualização para um sistema de • Recursos removidos podem continuar apontados por outras
prestação de serviços, como compra de bens, transações bancárias, páginas;
etc. Para realizar esses serviços, não houve modificações estruturais. • O conteúdo não necessariamente é confiável;
• Sistemas de pesquisa (ex. google, altavista, etc.) são imperfeitos
A Web apresenta 3 principais componentes tecnológicos padrões: e podem não localizar coisas com precisão;
• HTML: linguagem para especificar conteúdo e layout das • Está em andamento um sistema de padronização de metadados
páginas; para registrar melhor o conteúdo das páginas - sistemas de
• URL: identificadores de documentos e outros recursos; pesquisa poderiam melhorar seu desempenho baseado nisso;
• HTTP: protocolo que define a arquitetura cliente-servidor da • A diversidade de tipos de dados na Web é um problema para
Web. uma linguagem estática como o HTML (todos os tipos de dados
são tratados da mesma forma - a diferença é implementada pelos
Mais recentemente, a Web recebeu acréscimos como páginas plug-ins). Isso levou ao desenvolvimento do XML (Extensible
dinâmicas.e formulários. P. ex.: Markup Language). XML é uma linguagem de descrição de
• Ao preencher um formulário e apertar o botão que executa a dados, que torna-os portáveis entre as aplicações.
transação, o navegador faz uma requisição ao servidor; • Sites muito acessados têm problemas de escala - o acesso pode
• http://www.google.com/search?q=“Bin Laden” ficar lento. Os navegadores (e proxys) implementam caches, mas
• O navegador envia uma requisição de pesquisa (q) por “Bin não há mecanismo para indicar que um site foi atualizado (um
Laden”; conteúdo só pode ser renovado em períodos fixos). Isso obriga o
• Quem pode pesquisar é um programa (o navegador não está usuário a fazer refresh de uma página se quiser ver se ela foi
pedindo um arquivo). Ele é search. atualizada;
• A URL do servidor é www.google.com;
5 SD Cap. 1-4 5 SD Cap. 1-4

• Sites com anúncios obrigam os navegadores a buscar sempre a Camadas de software que fornecem abstrações de programação e
última versão em vez de usar o cache; mascaram a heterogeneidade dos elementos abaixo.
• Páginas não são um meio apropriado para representar todas as Ex.: CORBA.
informações. Isso levou ao uso de applets e muitas imagens para Alguns middlewares suportam apenas uma linguagem (ex. Java
tornar a interface mais aceitável. Também gasta mais tempo para RMI).
fazer um download completo. Todos são implementados sobre o IP - mascaram diferenças entre as
redes.
Características principais Todos precisam tratar diferenças de SOs e hardware.
Para resolver os problemas de heterogeneidade, os middlewares
1 - Heterogeneidade fornecem modelos computacionais uniformes para os
programadores.
Aplica-se a redes, computadores, sistemas operacionais, linguagens Possíveis modelos incluem:
de programação e implementações de diferentes desenvolvedores. • Invocação remota de objetos;
• A Internet é composta de vários tipos de redes diferentes, mas • Notificação remota de eventos;
todas implementam o Protocolo IP; • Acesso remoto com SQL;
• Plataformas diferentes podem ter representações diferentes de • Transações distribuídas.
inteiros, reais, etc.
• Apesar da necessidade de toda máquina ligada à Internet ter uma Heterogeneidade e código móvel
implementação do IP, os SOs não possuem a mesma interface
(chamadas). Código móvel: código que pode ser enviado de um computador para
• Linguagens diferentes possuem diferentes formas de representar outro e rodar no destino. Ex.: applets Java.
dados. Isso deve ser considerado se elas devem se comunicar O código depende do tipo de arquitetura de origem.
umas com as outras; A abordagem com máquinas virtuais permite fazer código
• Programas escritos por desenvolvedores diferentes não se executável em qualquer plataforma. Ex.: um compilador Java produz
comunicam, a menos que usem padrões comuns (comunicação, código para a JVM, que pode rodar em qualquer plataforma com
dados, estruturas, passagem de parâmetros, etc.). JVM implementada.
Esta solução não é aplicável a todas as linguagens. Ex.: não existe
Middleware uma VM para C.
6 SD Cap. 1-4 6 SD Cap. 1-4

2 - Abertura • Integridade: proteção contra estragos;


• Disponibilidade: proteção contra interferências no seu
Determina se um sistema pode ser estendido e implementado de funcionamento.
várias formas. Grau com que novos serviços de recursos
compartilhados podem ser inseridos. Toda a comunicação em um SD ocorre sobre redes. O desafio é
Não pode ser alcançada sem tornar públicas as documentações das enviar informação sensível em mensagens de forma segura.
interfaces dos principais softwares do sistema. Outro problema é garantir a identidade de quem recebe e de quem
Palavra chave = publicação! envia alguma coisa.
Grande desafio para os projetistas de um sistema (distribuído) = Problemas atualmente não completamente resolvidos:
juntar componentes desenvolvidos por diferentes pessoas. • Ataques de negação de serviço: atualmente a ação possível é
Ex. sistema de publicação da Internet = RFCs (Request for procurar os responsáveis depois que um ataque ocorre.
Comments). • Segurança de código móvel: garantias para quem recebe e para
Inclui discussões e padronização de protocolos. quem envia.
Ex.: CORBA.
Série de documentos técnicos separados por área, incluindo 4 - Independência de Escala
especificações completas das interfaces dos serviços.
Um SD deve operar de forma eficiente independente da escala,
Abertura em relação ao hardware: permite a adição de computadores desde uma pequena intranet até a Internet.
na rede. Um sistema é escalável se continuar efetivo após um incremento
Ao software: permite a introdução de novos serviços e a significativo de recursos e usuários.
reimplementação dos velhos. Ex.: Internet de 1979 a 1999
Em qualquer caso, permite a independência em relação aos
vendedores. Data Computadores Servidores WWW
12/1979 188 0
3 - Segurança 07/1989 130.000 0
07/1999 56.218.000 5.560.866
O tipo de serviço prestado por um sistema distribuído provavelmente
é alto valor intrínsico. Sua segurança é de grande importância. Ex.: número de computadores e servidores WWW na história da
A segurança de recursos de informação tem 3 componentes: Web (1993 a 1999)
• Confidencialidade: proteção contra acesso não autorizado;
7 SD Cap. 1-4 7 SD Cap. 1-4

Data Computadores Servidores % endereços se esgotaram por volta do ano 2000. O IPv6 adota
WWW 128 bits de endereços. Infelizmente, não há solução correta
07/1993 1.776.000 130 0,008 para o problema. Não há garantias de que 128 bits não se
07/1995 6.642.000 23.500 0,4 esgotarão também. Números maiores ocupam mais espaço
07/1997 19.540.000 1.203.096 6 nas mensagens.
07/1999 56.218.000 6.598.697 12
• Evitando gargalos de desempenho: algoritmos devem ser
Um SD escalável apresenta os seguintes desafios: descentralizados. Ex.: antecessor do DNS era um arquivo
central que devia ser baixado pelos servidores que
• Controlar o custo de recursos físicos: à medida que a precisavam dele. O DNS substituiu esse sistema por uma
demanda por recursos cresce, é necessário estender o sistema organização descentralizada.
para atendê-la. Ex.: um certo número de usuários podem ser
atendidos por um FS. Se os usuários aumentam, é necessário Alguns recursos podem ser acessados muito frequentemente. Ex.:
introduzir novos FS para evitar um gargalo. uma página de Internet. Nesse caso, pode-se usar cache e replicação.
• Em geral, para um sistema com N usuários ser escalável, a Idealmente, o sistema e o software de aplicação não devem ser
quantidade de recursos físicos deve ser O(N) – proporcional modificados conforme a escala. Difícil de alcançar! Soluções: dados
a N. Ex.: um FS para 20 usuários. Se N passa para 40, é replicados, cache, múltiplos servidores.
necessário ter 2 FSs.
5 - Tratamento de falhas
• Controlar a perda de desempenho: considere um conjunto
de dados proporcional ao número de usuários. Ex.: tabela de Computadores falham!
conversão de nomes do DNS. Algoritmos que usam Não é uma questão de SE eles vão falhar, mas de QUANDO!
estruturas hierárquicas (ex. Árvore B) escalam melhor que Numa falha, um computador pode devolver um resultado errado,
aqueles que usam estruturas lineares (ex. Listas). mas, em geral, eles param antes de dar a resposta.
• Mesmo com estruturas hierárquicas, o aumento do número Num SD, falhas são parciais: outros componentes continuam
de usuários causa perdas de desempenho, que não devem ser funcionando.
superiores a O(log n). O tratamento de falhas é bastante difícil.
Técnicas possíveis de tratamento:
• Prevenindo o esgotamento de recursos: ex.: números • Detecção de falhas: p. ex.: checksums podem ser usados para
usados como endereços Internet (32 bits - 1970). Os detectar alterações de pacotes de rede. No cap. 2, veremos que é
8 SD Cap. 1-4 8 SD Cap. 1-4

difícil (ou mesmo impossível) detectar falhas como crash de O servidor de um recurso pode atender um cliente de cada vez. Isso
servidores. O desafio é gerenciar falhas que não podem ser limita o throughput.
detectadas, mas podem ser presumidas. P. ex. cada recurso é encapsulado em um objeto.
• Mascaramento de falhas: as falhas detectadas podem ser Invocações são executadas em threads concorrentes
escondidas ou tornadas menos severas: É possível que sua operação possa ser conflitante,
• Mensagens podem ser retransmitidas; produzindo inconsistências
• Dados podem ser armazenados em + de um disco - se um Resultado: qualquer objeto que gerencie um recurso compartilhado
falha, o outro pode continuar em uso. deve garantir que ele opere com correção num ambiente concorrente.
No pior caso, essas técnicas podem não funcionar. P. ex. o 2o. disco Seus dados devem se manter consistentes.
pode estar corrompido também.
• Tolerar falhas: a maioria dos serviços na Internet apresentam 7 - Transparência
falhas. Não seria prático tratar todas elas e escondê-las dos
usuários. P. ex. um servidor pode não estar no ar. O navegador ANSA (Advanced Networks Systems Architecture) e ISO
não pode ficar indefinidamente a espera de que ele volte. Nesse (International Standards Organization) definem 8 formas de
caso, um erro é apresentado ao usuário. transparência:
• Recuperação de falhas: envolve o projeto de software. P. ex. • Acesso: recursos remotos e locais são acessados com as mesmas
roll-back numa falha de servidor. operações;
• Redundância: Ex.: • Localização: acesso aos recursos sem saber sua localização;
• 2 rotas para acessar um servidor importante; • Concorrência: vários processos acessam os mesmos recursos
• No DNS, as tabelas são replicadas em pelo menos 2 compartilhados sem interferência;
servidores diferentes; • Replicação: múltiplas instâncias de recursos são usadas sem
• Um BD pode ser replicado em vários servidores; conhecimento sobre réplicas;
• Servidores projetados para detectar falhas em seus pares; • Falhas: permite aos usuários completarem suas tarefas
• Clientes são redirecionados a um backup quando um servidor independente de falhas em software ou hardware;
falha. • Mobilidade: permite a movimentação de recursos e clientes sem
afetar a operação dos usuários;
6 - Concorrência • Desempenho: permite ao sistema ser reconfigurado para
melhorar o desempenho;
Há possibilidade de um recurso ser acessado por vários clientes ao • Escala: permite mudanças de escala sem alterar aplicações ou
mesmo tempo. algoritmos.
9 SD Cap. 1-4 9 SD Cap. 1-4

Cap. 2 - Modelos de Sistemas 2.2 Modelos arquiteturais

Um modelo de arquitetura define a forma como os componentes se Arquitetura de um sistema: sua estrutura em termos de especificação
relacionam entre si. Também define a forma como são mapeados de componentes separados.
numa rede de computadores. Objetivo geral: garantir que a estrutura vai atender necessidades
atuais e futuras
Dificuldades e ameaças aos SDs: Principais objetivos: fazer o sistema confiável, manuseável,
• Grande variação nas formas de utilização: p. ex.: adaptável e custo-efetivo.
• Variação de carga - algumas páginas são pouco acessadas Simplificação inicial: classificação dos processos em clientes,
enquanto outras recebem milhões de acessos por dia; servidores e pares.
• Partes de um sistema podem estar desconectadas;
• Algumas aplicações precisam de grande largura de banda. Variações do modelo cliente-servidor:
• Grande variação de ambientes: • Mobilidade de código de um processo p/ outro permite a
• Há heterogeneidade de hardware, SO e redes; delegação de tarefas. P. ex. clientes podem fazer download de
código dos servidores para executá-los localmente;
• Redes sem fio operam a uma fração das LANs;
• Códigos e objetos podem ser movidos para reduzir o tráfego;
• Há diferenças de escala: sistemas com dezenas de
computadores até milhões. • SDs podem ser projetados para permitir a adição e remoção de
computadores e outros dispositivos móveis - podem descobrir os
• Problemas internos:
serviços disponíveis e oferecer serviços para outros.
• Relógios não sincronizados;
• Atualizações conflitantes;
• Muitas formas de falhas de hardware e software envolvendo 2.2.1 Camadas de software
componentes do sistema.
• Ameaças externas:
• Ataques à integridade de dados e ao sigilo; Aplicações,
serviços
• Negação de serviço.
Middleware
Sistema
operacional Plataforma
Hardware e rede
10 SD Cap. 1-4 10 SD Cap. 1-4

Middleware: 2.2.2 Arquiteturas de sistemas


• Camada de software que mascara a heterogeneidade de um
sistema; Projeto de SD - aspectos + evidentes:
• Fornece um modelo para os programadores; • Divisão de responsabilidades entre componentes (aplicações,
• Fornece blocos de construção de componentes de software que servidores, etc.);
trabalham uns com os outros; • Colocação de componentes em computadores da rede.
• Ultrapassa o nível de comunicação e permite abstrações como Esses itens têm grandes implicações no desempenho, confiabilidade
Invocação Remota, comunicação de grupos, notificação de e segurança.
eventos, replicação de dados, transmissão de multimídia em
tempo real.
Cliente Server
Limitações do middleware

Ex.: transferência de grande número de emails do servidor para o


cliente.
• Aplicação TCP;
Server
• Considere uma rede não confiável; Cliente
• TCP possui alguma detecção de erros e correção;
• Mas não há recuperação possível de erros graves ou
interrupções;
• Nesse sentido, o serviço de email pode acrescentar tolerância a Modelo cliente-servidor
falhas através de um registro do trabalho já feito.
Historicamente o modelo mais conhecido e mais usado.
O correto comportamento de um SD depende de verificações, Servidores podem ser clientes:
correção de erros, medidas de segurança em vários níveis. • Servidores WWW podem ser clientes do FS local;
É preciso acessar dados dentro do espaço de endereçamento das • Também podem ser clientes do DNS;
aplicações. • Um engenho de pesquisa é um cliente (dos sites que visita) e um
Tentativas de realizar as verificações através dos sistemas de servidor (dos usuários que pedem pesquisas);
comunicação padrões garante apenas parte das necessidades de
correção.
11 SD Cap. 1-4 11 SD Cap. 1-4

Serviços com múltiplos servidores Ao precisar de um objeto, o cache é consultado primeiro. Se houver
uma versão atualizada, ela é usada. Se não, é feita uma solicitação
Serv do objeto ao seu servidor.
Caches podem ser residentes em cada cliente ou residir em um
Client
proxy, sendo compartilhados por todos.
Caches são bastante utilizados:
• Navegadores possuem caches das páginas recentemente visitadas
– uma função especial do protocolo HTTP permite verificar se as
Serv páginas estão atualizadas;
Client • Servidores proxy fornecem páginas já acessadas aos clientes de
uma rede – finalidade é aumentar o desempenho – podem ser
usados para outras finalidades. Ex.: acessar sites através de um
firewall.
Serv

Cliente Web Serv

Os servidores podem dividir o conjunto de dados. Proxy


Também podem manter cópias replicadas.
Replicação aumenta o desempenho, a disponibilidade e a tolerância Cliente Web Serv
a falhas.

Processos pares (peer)


Servidores proxy e cache
Processos que são similares e desempenham os mesmos papéis.
Um cache é um armazém de objetos mais usados mais perto que os Interagem de forma cooperativa para realizar atividades distribuídas,
objetos originais. sem distinção entre clientes e servidores.
Ao receber um objeto, ele é adicionado ao cache, eventualmente
substituindo um mais velho.
12 SD Cap. 1-4 12 SD Cap. 1-4

Código móvel
Aplicação Aplicação
Ex.:
a)
Código de Código de Cliente Web Server
Applet
coordenação coordenação

b)
Cliente
Aplicação Web Server
Applet

Código de
coordenação Vantagem: Não há atrasos na rede, não gasta banda.

A não existência de um servidor torna a comunicação mais Apesar da padronização, algumas aplicações apresentam
demorada, já que há atrasos consideráveis caso se precise procurar funcionamento incomum. P. ex.: um broker:
algo por todos os processos. • O cliente faz download de um código para acompanhar o valor
das ações;
• O servidor mantém os valores e informa periodicamente o
2.2.3 Variações no modelo cliente-servidor código das mudanças - push - não é o cliente que pede, mas o
servidor que comunica os dados.
Novas situações:
• Uso de código móvel e agentes móveis; Um código móvel é uma ameaça potencial à segurança dos recursos
• Necessidade de computadores de baixo custo; locais de um sistema. Por isso, navegadores dão acesso limitado aos
• Necessidade de adicionar e remover dispositivos móveis. applets baixados da Internet.
13 SD Cap. 1-4 13 SD Cap. 1-4

Agentes móveis A proposta de um NC possui os seguintes objetivos:


• Sistema operacional e aplicações são baixados de um servidor
Processo (código + dados) que viaja de máquina para máquina numa remoto;
rede para executar uma tarefa para alguém. • Aplicações executam localmente, mas os arquivos são acessados
Ex.: coletar dados, retornando com o resultado. remotamente;
Podem invocar recursos locais (ex. Bancos de dados), eventualmente • Como todos os arquivos são acessados em um servidor, os
acessando grandes conjuntos de dados. usuários podem mudar de computador sem problemas;
• Com isso, economizam banda de rede porque o acesso é local, • Processador e memória podem ser limitados para reduzir custos;
com melhor tempo de resposta. • Se o NC tem um disco, ele é usado para manter um mínimo de
Agentes móveis são uma ameaça potencial aos recursos das software;
máquinas que visitam. • A maior parte dele é usada como cache para os arquivos mais
O ambiente local deve decidir: recentes;
• A identidade do emissor do agente; • Os objetos mantidos no cache são invalidados quando
• Que privilégios dar ao agente que chega; atualizados no servidor principal.
• Que recursos ele pode acessar.
Os próprios agentes são vulneráveis: Thin Clients
• Podem ser atacados nos hosts em que chegam;
• Talvez não possam realizar sua tarefa se não puderem acessar os Camada de software que suporta uma interface para o usuário local
recursos de que precisam. enquanto executa aplicações em computadores remotos.
A tarefa de um agente móvel pode ser realizada por outros meios: As aplicações rodam em computadores de grande capacidade,
• Ex.: invocação remota. multiprocessadores ou clusters, com um SO como Unix ou Windows
Assim, sua aplicação ainda é restrita. NT/2000/XP.
Problema: aplicações gráficas interativas (ex. Autocad), cujo envio
Network Computers de telas pela rede pode causar grandes atrasos.

Um computador típico possui: Implementações: X11 (sistema de janelas), WinFrame da Citrix,


• Sistema operacional; VNC da AT&T.
• Aplicações instaladas conforme a necessidade do usuário;
• Pertence a uma plataforma determinada.
14 SD Cap. 1-4 14 SD Cap. 1-4

Dispositivos móveis e comunicação espontânea • Fácil integração com os serviços locais – os dispositivos
descobrem os recursos disponíveis e podem utilizá-los quando
Dispositivos móveis estão se tornando populares: necessário.
• Notebooks; Desafio de conseguir conexão e integração fáceis:
• Laptops; • Ex.: endereços IP assumem que as máquinas pertencem a uma
• PDAs; determinada subrede – se o computador é movido para outra
• Celulares; rede, ele não pode ser acessado com o mesmo endereço.
• Cameras digitais;
• Computadores “vestíveis” – relógios, etc. Os usuários podem ter problemas de conexão à medida que viajam
• Dispositivos embutidos (máquinas de lavar, geladeiras, micro- A natureza espontânea de sua conexão pode levar a problemas de
ondas, etc.). segurança.

Esses dispositivos podem realizar comunicação sem fio: • Conectividade limitada: p. ex. O usuário pode sofrer
• Grandes distâncias: GSM (centenas de Kbps), CDPD; desconexões intermitentes se viajar num trem que passa por
• Centenas de metros: WAVELAN; túneis
• Poucos metros: BlueTooth, infravermelho, HomeFR – 10 Mbps. • O usuário pode ser desconectado quando estiver numa região
sem acesso – como suportar o usuário para que ele possa
GSM: Global System Mobile Communication trabalhar mesmo desconectado?
CDPD: também conhecido como Mobile IP
WAVELAN: LAN sem fio • Segurança e privacidade: p. ex. Usuários ou funcionários de
BlueTooth: padrão de comunicação por rádio uma instalação podem tentar se conectar num modo não
HomeRF: Home Radio Frequency: sistema de comunicação por supervisionado;
rádio • Usuários podem ser espionados a medida que se movem por
várias redes;
Comunicação espontânea é o termo que indica que os dispositivos • Usuários podem acessar suas redes caseiras, o que pode tornar
móveis se comunicam com as redes para estabelecer seu esses ambientes suscetíveis a ataques – dados mantidos por um
funcionamento. firewall podem ser interceptados quando o usuário acessa-os.
Principais recursos da comunicação espontânea:
• Fácil conexão com redes locais – não há necessidade de cabos,
plugs, etc.;
15 SD Cap. 1-4 15 SD Cap. 1-4

• Descobrir serviços: ao se conectar com uma rede, o dispositivo 2.2.5 Requisitos de projeto para arquiteturas
móvel deve identificar os recursos disponíveis (ex.: impressoras, distribuídas
fax, TVs, etc.)
• Não se pode esperar que os protocolos de todos os recursos
sejam compatíveis; Compartilhamento de recursos foi lançado nos anos 60, com o
sistemas timesharing. Ex. Sistemas operacionais multiusuários
• Deve haver meios de descobrir os recursos disponíveis e obter
(Unix) ou sistemas de banco de dados multiusuários (Oracle).
dados sobre eles;
O surgimento de processadores baratos e de alto desempenho tirou o
• Quando so usuários quiserem, poderão fazer requisições sobre
controle dos recursos de máquinas de grande capacidade passou-os
esses recursos;
para qualquer máquina da rede.
A necessidade de compartilhamento de recursos físicos
Um serviço de descoberta tem 2 interfaces:
(impressoras, discos, etc.) levou aos SDs dos anos 70 e 80.
• Serviço de registro: aceita registros dos servidores e mantém Hoje, o compartilhamento atinge principalmente os dados.
bancos de dados sobre os recursos disponíveis; O principal desafio é controlar o acesso concorrente aos dados e
• Serviço de lookup (pesquisa): aceita requisições dos usuários e evitar os conflitos de atualização.
o BD por serviços que possam atendê-las;
Questões de desempenho
Ex.: usuário em um hotel com figuras numa câmera digital que
deseja ver como elas saíram. Derivado do uso de máquinas e linhas de comunicação limitadas,
aparecem 3 principais elementos:

2.2.4 Interfaces e Objetos • Tempo de resposta: o acesso a recursos remotos leva a atrasos
consideráveis nas respostas a requisições do usuário;
Definições de interface: conjunto de funções disponíveis para • Para melhorar os tempos de resposta, o software deve ser
invocação em um processo (servidor, peer, etc.). Ex.: C++, Java, etc. composto de poucas camadas;
Linguagens orientadas a objetos podem encapsular objetos com uma • A quantidade de dados trocadas entre os processos deve ser
interface definida. Os métodos desses objetos podem ser invocados pequena.
remotamente. Ex.: CORBA, RMI, etc. Ex.: navegadores – páginas acessadas do cache são rápidas; páginas
só de texto mesmo remotas são rápidas; páginas com dados grandes
acessadas remotamente são lentas.
16 SD Cap. 1-4 16 SD Cap. 1-4

• Throughput: taxa de realização de trabalho computacional. Recursos reconhecidos a pouco tempo como muito importantes para
Num SD é a habilidade de realizar trabalho para todos os seus a qualidade:
usuários. Valor afetado pela velocidade de clientes e servidores e • Adaptabilidade: para se adequar a mudanças;
pelas taxas de transferência. • Disponibilidade de recursos.
• Considere dados localizados num servidor remoto:
o Os dados precisam passar do processo servidor para o Aspectos de desempenho em QoS até pouco tempo eram tratados
processo cliente; como tempo de resposta e throughput.
o Nesse processo, eles atravessam várias camadas de Recentemente se considera que são as garantias de se respeitar
software nos 2 lados; limites de tempo.
o O throughput de cada camada é importante, assim como Algumas aplicações trabalham com dados de tempo crítico - cadeias
o da rede. que precisam ser processadas entre processos a uma taxa fixa. Ex.:
vídeo.
• Balanceamento de carga: uma das finalidades de um SD: QoS é considerado hoje como a capacidade de atender deadlines.
permitir que aplicações e outros processos processem Alcançar isso depende de existir suficiente recurso de processamento
concorrentemente sem competição por recursos. e redes no momento certo.
• P. ex.: rodar applets nos clientes permite ao servidor prestar um Quem deve garantir esses recursos é o sistema.
serviço melhor; Ex.: as redes que se conectam com a Internet hoje conseguem
• Ex.: vários computadores para manter um só serviço. O DNS transferir dados a taxas satisfatórias até que elas se sobrecarreguem.
tem um recurso de lookup que devolve só um deles na pesquisa Nesse caso, o desempenho se deteriora rapidamente.
de um domínio; De forma nenhuma, isso pode ser considerado QoS.
• Algumas vezes, é preciso mover um serviço parcialmente feito
para ajustar a carga de um sistema. QoS é garantido pelo SO. Recursos críticos devem ser reservados
para as aplicações que precisam de QoS. Gerentes de recursos
Qualidade de serviço devem dar garantias. Requisições de reserva que n\ão podem ser
atendidas são descartadas.
Uma vez que um SD tenha o serviço que o usuário precisa, é preciso
verificar sua qualidade. Uso de cache e replicação
Propriedades que afetam a qualidade:
• Confiabilidade, segurança e desempenho. As questões de desempenho citadas podem parecer obstáculos para a
construção de SDs.
17 SD Cap. 1-4 17 SD Cap. 1-4

Na prática, há técnicas bastante pesquisadas como replicação de objeto foi colocado no cahe + tempo no servidor) se aproximar do
dados e cache. momento em que a entrada vai expirar.
Vimos antes caches e proxies, sem discutir como as cópias de Esse cálculo não depende que os relógios do servidor, do cliente e
recursos são atualizadas quando o original é atualizado em um do proxy concordem entre si.
servidor.
Diferentes aplicações podem usar diferentes protocolos de cache. Dependência

• Protocolo Web-caching (HTTP): proxies e web servers Dependência é um alto grau de necessidade dos usuários em relação
respondem da mesma forma a requisições dos clientes. O a um serviço.
protocolo de consistência do cache procura garantir que os dados Dependência é relacionado com correção, segurança e tolerância a
entregues ao cliente serão "frescos". Mas para garantir falhas.
desempenho, disponibilidade e operação offline essa condição O desenvolvimento de técnicas para garantir a correção de
precisa ser relaxada. programas distribuídos é alvo de várias pesquisas recentes. Há
• Navegadores ou proxies podem validar uma resposta do cache alguns resultados promissores, mas nenhum maduro o suficiente.
verificando o servidor original. Se falhar, o servidor envia os
dados atualizados. • Tolerância a falhas: aplicações que geram dependência devem
• Quando um dado é atualizado, o servidor não avisa navegadores continuar funcionando mesmo na presença de falhas.
e proxies - para isso, seria necessário manter uma relação dos Confiabilidade é alcançada através de redundância. Isso é caro e
atuais interessados em cada um dos seus recursos. há limites para o grau de redundância possível. Portanto, há
• Para permitir aos clientes identificar quando um recurso pode limites para o grau de tolerância a falhas de um sistema.
estar atualizado, o servidor fornece data e hora para expirar • Uma aplicação crítica (ex. Controle de tráfego aéreo) necessita
(determinado a partir da média de atualizações registradas). de alto grau de tolerância a falhas, que leva a um alto custo para
• Esse recurso pode ser enganoso (dados na Web podem ser manter réplicas de dados atualizadas.
atualizados a qualquer momento).
• Segurança: dados e serviços críticos só devem residir em
Os servidores anexam às páginas fornecidas um timestamp de computadores a prova de ataques.
validade e a hora no servidor. • Ex.: o BD de um hospital contém dados que só devem ser vistos
Navegadores podem saber quando um objeto do cache está para se por poucos médicos. Outros dados podem ser vistos por grupos
tornar inválido quando sua “idade” (soma do momento em que o maiores.
18 SD Cap. 1-4 18 SD Cap. 1-4

• Assim, não é possível fazer um sistema que carregue fichas de • Falhas: definição dos tipos e classificação das falhas – fornece
pacientes em notebooks porque eles são inseguros por natureza. uma base para a análise das falhas e o projeto do tratamento de
cada tipo;
• Segurança: a natureza modular e abertura dos SDs expõem-os a
2.3 Modelos Fundamentais ataques externos e internos. O modelo de segurança define e
classifica as formas de ataque, permite análise de ameaças e o
Um modelo contém os elementos mínimos para entender e projeto de métodos de resistência.
raciocinar sobre os elementos essenciais de um sistema. Questões
principais:
• Quais são as principais entidades do sistema? 2.3.1 Modelo de Interação
• Como elas interagem?
• Que caracterísiticas afetam seu comportamento individual e Um programa simples é controlado por um algoritmo sequencial,
coletivo? cujos passos são realizados numa cadência conhecida. O algoritmo
não interfere nem sofre interferências externas. Ele também define
Finalidade de um modelo: os conteúdos das variáveis e os estados dos programas em um dado
• Tornar explícitas todas as suposições relevantes do sistema momento.
modelado. SDs são constituídos de múltiplos processos. Seu comportamento
• Generalizar o que é possível ou não em geral, tomam a forma de pode ser descrito por um algoritmo distribuído: uma definição de
algoritmos de finalidade geral ou regras (propriedades passos + transmissão de mensagens entre os processos.
desejáveis) garantidos. As garantias são dadas por análise lógica As mensagens são usadas para transferir informações e para
ou prova matemática. coordenar as atividades.
Elementos difíceis de determinar:
Aspectos de SDs dos modelos fundamentais: • Taxa de andamento de cada processo;
• Interação: processos interagem por mensagens e coordenação; o • Momento em que uma mensagem é enviada;
modelo de interação deve tratar dos atrasos inerentes à • Estados do algoritmo - é preciso considerar as falhas em 1 ou +
comunicação; também deve considerar a precisão com que um processos, extravio de mensagens, etc.
grupo de processos pode se sincronizar – depende dos atrasos e
da manutenção de noção de tempo entre todos os computadores; A seguir, vemos 2 fatores que afetam a interação de processos num
SD.
19 SD Cap. 1-4 19 SD Cap. 1-4

Desempenho dos canais de comunicação Duas abordagens diferentes em relação ao tempo:


• Forte suposição;
• Latência: o atraso entre a transmissão e recepção de uma • Nenhuma suposição.
mensagem. Inclui:
• Tempo para o 1o. bit sair do transmissor e atingir seu SDs síncronos definem os seguintes limites (inferiores e superiores):
destino; • Tempo para realizar um passo;
• Atraso para acessar a rede - maior em redes carregadas; • Tempo para transmitir uma msg;
• Atraso dos serviços de comunicação dos SOs origem e • Taxa de variação do relógio local.
destino.
• Banda: capacidade de transmissão total em um certo momento; É possível sugerir valores, mas é difícil dar garantias sobre eles. Um
• Jitter: variação de tempo para entregar uma série de mensagens SD síncrono tem a vantagem de permitir modelagem, que pode ser
- importante em multimídia, onde a diferença nos tempos de útil para verificar seu funcionamento. Pode-se usar timeouts, p. ex.,
entrega pode causar distorções. para determinar falhas em serviços.

Relógios e medição de tempo SDs assíncronos são aqueles que não podem ser qualificados como
síncronos (ex. Internet).
Cada computador possui seu relógio. Os processos locais usam-no Não possui limites:
para medir o tempo dos eventos locais. • Processos podem demorar longos tempos arbitrários;
Relógios possuem diferenças em relação ao tempo real. • Mensagens podem ser recebidas após longos tempos arbitrários;
A taxa de diferença mede a relação entre o relógio local e um • A taxa de variação dos relógios também é arbitrária.
relógio perfeito. Na Internet, um email pode levar dias ou segundos. A transferência
Acertando todos os relógios de um SD ao mesmo tempo, após um de um arq. por FTP pode ser rápida, demorada ou inviável.
certo período pode-se ter variações significativas. O problema dos exércitos azul e vermelho assume mais um grau de
dificuldade, caso o sistema seja assíncrono.
Duas variantes do modelo de interação Alguns problemas de projeto podem ser resolvidos mesmo nesse
caso. Ex. a Web não possui limites para tempos de resposta, mas os
É difícil impor limites de tempo para: navegadores podem permitir ao usuário outras atividades enquanto
• Execução de um processo; espera.
• Trânsito de uma msg; Soluções válidas para SDs assíncronos também são válidas para SDs
• Taxa de variação de um relógio. síncronos.
20 SD Cap. 1-4 20 SD Cap. 1-4

Ordenação de eventos Processos ou canais falham por não realizar o que se esperava que
fizessem.
Há interesses em saber se um evento ocorre antes, depois ou
concorrentemente em relação a outro evento em outro processo. • Processos: principal ocorrência é o crash. Nesse caso, o processo
P. ex.: considere a seguinte situação pára e não realiza mais sua tarefa. O projeto de um serviço
• Em um newsgroup, X envia uma mensagem Matter; tolerante a falhas é simplificado se os serviços de que ele
• Y lê a msg de X e responde com Re: Matter; depende falham de forma limpa (ou funciona ou pára).
• Z lê as 2 msgs e responde com Re: Matter. • Um processo falha em crash se outros processos podem
O resultado pode ser: determinar que isso aconteceu.
Item Origem Assunto
23 Z Re: Matter • Comunicação:
24 X Matter
25 Y Re: Matter Send m Receive

Para resolver o problema, é preciso 3 coisas:


• Sincronizar todos os relógios envolvidos;
• Enviar o timestamp junto com a msg;
• Classificar as msgs pelo timestamp. Buffer de transmissão Buffer de recepção

O canal de comunicação produz uma falha por omissão se:


2.3.2 Modelo de falha • Não ocorre o transporte entre os buffers de transmissão e
recepção (ex. falta de espaço em buffer);
• Erro de transmissão (detectado por checksums).
Uma falha é um desvio daquilo que é considerado correto.
O modelo falha determina como as falhas ocorrem para verificar As falhas podem ser classificadas por sua severidade. Todos os tipos
seus efeitos. de falhas apontadas aqui são falhas benignas (não causam
interrupções sérias no sistema).

Falhas por Omissão


21 SD Cap. 1-4 21 SD Cap. 1-4

Falhas arbitrárias É possível construir serviços confiáveis a partir de elementos que


apresentam falhas.
As características das falhas permitem desenhar serviços que
O termo arbitrário (ou Bizantino) descreve o pior tipo de falha mascaram falhas em componentes dos quais o serviço depende.
possível, onde um processo não pára (não há crash) mas pode alterar Formas de mascarar falhas:
seus dados com valores errados, ou dar respostas erradas. • O serviço esconde sua ocorrência;
Nesse caso, o processamento de uma requisição ocorre com uma
• A falha é convertida em um tipo + aceitável.
sequência de passos equivocada.
Ex. Checksums mascaram msgs corrompidas – uma falha arbitrária é
Canais de comunicação são especialmente sujeitos a esse tipo de
convertida em falha por omissão.
falha:
Crashes de processos podem ser mascarados – o processo é
• O conteúdo de uma mensagem pode ser corrompido; substituído e seu estado é restaurado a partir de dados armazenados
• Mensagens não existentes podem ser entregues; pelos predecessores.
• Mensagens reais podem ser entregues + de uma vez.
Em geral, o software de rede identifica todos esses casos com
facilidade (ex. Checksums, números de sequência, etc.).
Confiabilidade da comunicação 1-para-1

Falhas de tempo Canais apresentam falhas por omissão, mas podem ser usados para
construir serviços que mascaram essas falhas.
Uma comunicação é confiável se ela apresentar:
Ocorrem em SDs síncronos (tempo de execução de processos, • Validade: uma msg colocada no buffer de transmissão é sempre
entrega de msgs, diferença entre relógios). entregue no buffer de recepção;
Num SD assíncrono, um servidor pode responder muito lentamente, • Integridade: a msg recebida é idêntica à enviada; msgs não são
mas não se pode falar em falhas de tempo já que não há garantias. enviadas + de 1 vez; msgs não enviadas não são entregues.

Mascarando falhas
Componentes de SDs são construídos a partir de conjuntos de outros
componentes.
22 SD Cap. 1-4 22 SD Cap. 1-4

O servidor deve identificar o principal que acessa seus objetos e


2.3.3 Modelo de segurança conceder direitos de acesso. As operações devem ser verificadas. Se
estiverem fora dos direitos concedidos, devem ser negadas.
Proteção de objetos O cliente deve identificar o servidor para garantir que as respostas
vêm de um principal autêntico.
Access rights Object
invocation Protegendo processos e suas interações
Client
result Server Processos interagem pelo envio de mensagens.
Mensagens ficam expostas a ataques enquanto trafegam pela rede.
Os serviços em que são baseadas são abertos e suas interfaces
Principal (user) Network Principal (server) publicadas.
Assim, alguém pode enviar mensagens a um principal tentando se
Na figura, um servidor manipula um conjunto de objetos. passar por outro.
Os usuários executam programas clientes para acessar esses objetos.
Os servidores recebem invocações e devolvem respostas. O inimigo
Copy m
Para cada usuário, o servidor verifica os direitos de acesso antes de
of
dar acesso aos objetos.
The
Usuários diferentes podem usar os objetos de formas diferentes. enemy m’
Ex.: um objeto que contém uma caixa postal Process p m
• São dados privados pertencentes a alguém; Communication channel Proces sq
• Só o dono pode ver e/ou alterar esse objeto.
Para modelar os ataques possíveis, identifica-se um inimigo. Ele
Ex.: páginas Web
pode enviar qualquer mensagem para qualquer processo, pode ler
• Alguns usuários só podem ler essas páginas;
e/ou copiar mensagens trocadas entre os processos.
• O dono pode alterar seu conteúdo. Os ataques podem vir de um computador conectado à rede, que roda
um programa que lê msgs endereçadas a outros processos, ou um
Os principais devem ser identificados e associados com um conjunto programa que gera msgs fazendo falsas requisições como se fosse
de direitos de acesso. um usuário autorizado.
23 SD Cap. 1-4 23 SD Cap. 1-4

• Ameaça aos processos: processos podem receber msgs da rede e


talvez não consigam identificar o emissor.
o Servidores: da mesma forma, processo podem enviar
msgs a um servidor, que pode não identificar o emissor.
Pode-se exigir que o emissor acrescente uma identidade à
requisição, mas ela também pode ser falsificada.
o Clientes: um servidor que um cliente acessa pode ser
falso. Assim é difícil determinar se a resposta vem de um
servidor legal ou de um que se faz passar por outro.
• Ameaça aos canais de comunicação: o inimigo pode copiar,
alterar ou injetar msgs numa rede. Um ataque + sofisticado é
copiar msgs e fazer replay delas + tarde.

Combatendo ameaças à segurança

• Criptografia e segredos compartilhados: considere que 2


processos compartilham um segredo (só os 2 sabem). Se numa
troca de mensagens esse segredo é anexado, então o outro lado
sabe que o processo que mandou a msg é quem diz ser. Para
garantir que o segredo não se torne público, as msgs são trocadas
criptografadas;
• Autenticação: o uso de segredos compartilhados e criptografia é
a base para a autenticação, sistema de garantia de identidade de
um principal;
• Canais seguros: criptografia e autenticação permitem construir
canais seguros no topo de um sistema de comunicação.
Propriedades:
o Cada principal sabe a identifdade de seu par;
o Garantia de privacidade e integridade;
o Timestamps podem evitar replay ou troca de ordem.
24 SD Cap. 1-4 24 SD Cap. 1-4

Internet x FLIP
Cap. 3 – FLIP (Fast Local Internet
Protocol) Camada Protocolo FLIP
Internet
Há necessidades não atendidas por alguns protocolos (ex.: TCP/IP)
Aplicação FTP, Telnet, SMTP Definido pelo usuário
que precisam ser consideradas num SD. P. ex.:
Sessão - RPC, grupos
Transporte TCP, UDP FLIP (tipo UDP)
• Transparência: as mensagens devem ser transmitidas para Internet FLIP
processos (ou portas) em vez de números IP. IP
• Transparência completa: a comunicação é mantida mesmo
quando os processos (ou portas) migram entre os Características:
computadores.
• Segurança: numa rede, alguns componentes podem ser seguros • Serviço não confiável de datagrama;
e outros não: • Base para protocolo RPC e multicast de grupo;
• Não seguros: criptografia. • Fonte e destino = processos Amoeba;
• Criptografia consome recursos – não fazer nos componentes • Mensagens de 0 a 4GB (não precisa de transporte);
seguros. • Número de porta único em toda a rede.
• Gerência de rede simplificada: • Número não se altera com migração.
• Redes grandes: computadores adicionados ou removidos • Endereça grupos de portas.
com freqüência.
• Alocação automática de novos endereços. Cada computador em uma rede FLIP é conectado à rede física por
meio de um FLIP Box:
Esses elementos são difíceis de alcançar em redes dispersas: • Packet switch: transfere pacotes entre hosts e redes e de uma
• limitações de desempenho; rede para outra;
• múltiplos domínios administrativos. • Usa tabelas de roteamento;
• Essas tabelas variam dinamicamente à medida que os
FLIP: Tanenbaum: processos se movem entre os hosts;
• protocolo para redes Ethernet interconectadas; • A localização de um identificador FLIP pode ser feita via
• computadores com Amoeba. broadcast.
25 SD Cap. 1-4 25 SD Cap. 1-4

• Interface com os hosts: para o envio e recepção de mensagens


unicast, multicast e broadcast;
• Permite que processos se registrem (p. ex.: servidores) para a
recepção de mensagens;
• Esse registro pode ser seguro, se necessário – funções de
criptografia one-way.
• Interfaces de Rede: um host tem uma só; um roteador tem
várias interfaces com redes diferentes.

Principais diferenças entre FLIP e protocolos Internet:


• FLIP tem transparência de localização – destinos independentes
de localização;
• Identificadores de portas gerados e alocados automaticamente –
reduz a administração;
• Suporte à comunicação de grupo;
• Suporta comunicação segura apenas onde é necessário;
• Objetivo: uso em grupos pequenos e confiáveis de WANs e
LANs.
26 SD Cap. 1-4 26 SD Cap. 1-4

Ex.:
Cap. 4 – IPC char * nome = “Smith, * lugar = “London”;
int ano = 1934;

4.3 Representação externa de dados e sprintf(msg, “%d%s%d%s%d”, strlen(nome), nome,


strlen(lugar), lugar, ano);
marshalling Para ser transmitida, uma estrutura precisa ser convertida em bytes
(serializada). Isso leva a problemas dependendo do tipo de dado.
Mensagens: P. ex.:
• Estruturas de dados mapeados em seqüência; • Reais: cada arquitetura tem uma forma de representação;
• Integração de diferentes tipos de dados; • Códigos de representação:
• Plataformas com representação interna diferente; o Unix, IBM, Intel: ASCII;
• Conversão para representação comum. o Unisys: EBCDIC;
• Computadores iguais podem omitir esse passo. o Macintosh: ASCII mixto;
o Windows 98/ME/2000/XP, Java: Unicode.
XDR (External Data Representation – SUN) • Inteiros:
RFC 1832 o Big Endian: o bit + significativo vem 1o.;
www.cdk3.net/ipc o Little Endian: o bit + significativo vem por último.
Ex.: Smith, London, 1934
CORBA CDR
4 bytes
5 Representação externa definida no Corba 2.0.
Smit Representa todos os tipos de dados que podem ser argumentos em
h--- chamadas de funções.
6
Lond
on-- 15 tipos primitivos. Ex.:
1934 • short (16 bits), long (32 bits), unsigned short, unsigned long,
float (32 bits), double (64 bits), char, boolean (TRUE, FALSE),
Marshalling: operação de empacotar dados numa mensagem para octet (8 bits), any!
transmissão. Tipos compostos:
• sequence: tamanho (unsigned long) + elementos em ordem;
27 SD Cap. 1-4 27 SD Cap. 1-4

• string: tamanho (unsigned long) + caracteres em ordem (pode ser public class Person implements Serializable {
caracteres longos); private String name;
private String place;
• array: elementos em ordem (não possui tamanho); private int year;
• struct: na ordem dos componentes;
• enumerated: unsigned long; public Person(String aName, String aPlace,
• union: tipo + membro. int aYear) {
O exemplo Smith, London, 1934 em XDR é idêntico em Corba name = aName;
place = aPlace;
CDR. year = aYear;
}
Marshaling no Corba // outros metodos
}
Considere o exemplo Smith, London, 1934.
As operações de marshalling são feitas automaticamente a partir da A interface Serializable não possui métodos, mas permite que
definição IDL: objetos instâncias das classes que implementam-na sejam
serializados.
struct Person { Isso significa transformar um objeto numa sequência de bytes que
string name; podem ser armazenados em disco ou enviados numa mensagem.
string place; A operação de deserialização consiste em transformar uma
long year;
}; sequência de bytes no objeto original.
O processo que recupera um objeto não tem informações sobre ele.
O compilador de interface do Corba gera as operações de Elas fazem parte da forma sequencial.
marshalling e unmarshalling para os parâmetros e resultados.
A serialização inclui todos os objetos referenciados. Isso permite
Serialização de objetos em Java reconstruir o objeto orginal com todos os objetos que ele
referenciava.
No Java RMI, objetos e dados primitivos podem ser passados como Referências a variáveis que não devem ser serializadas devem ser
argumentos e resultados de operações. declaradas como transient (ex.: arquivos, sockets, etc.)
Ex. Implementação do exemplo do IDL acima:
Reflection: informa o compilador que a classe de uma instância não
é conhecida. Ela será conhecida durante a execução. Isso permite a
28 SD Cap. 1-4 28 SD Cap. 1-4

serialização de uma forma totalmente genérica, sem conhecimento Identificadores de destino independentes de localização.
prévio da classe usada. Na Internet:
• Porta, número IP.
Operações Send e Receive
FLIP:
Send(destino, msg); • Destino mapeado para um endereço físico pelos roteadores.
Receive(fonte, msg);
Comunicação confiável.
Para o receive, fonte pode ser ANY.
Problemas que podem ocorrer com mensagens:
Comunicação síncrona e assíncrona • Extravio;
• Duplicação;
A comunicação síncrona envolve o bloqueio do transmissor (send) e • Entrega fora de ordem;
do receptor (receive). • Atraso.
O bloqueio permanece até que o processo par realize a operação par
do processo bloqueado. Um serviço confiável pode ser construído sobre um outro não
A comunicação assíncrona bloqueia o processo apenas até que a msg confiável pelo uso de acks de confirmação.
seja entregue à biblioteca de comunicação (send). Mesmo nesse
• Cliente-servidor: ack positivo;
caso, pode-se escolher entre receive bloqueante e não bloqueante.
• Grupos: ack negativo.
Na forma não bloqueante, o processo continua sua execução e há
alguma função que indica se o buffer recebeu uma mnsg válida.
Overhead de um serviço confiável:
Obs.: no Java (multithread) o bloqueio não tem importância, pois é
1. Armazenamento de informação de estado em fonte e destino.
possível fazer uma thread bloquear enquanto o restante da aplicação
2. Retransmissão.
continua.
3. Latência entre fonte e destino.
A comunicação não bloqueante parece ser + vantajosa, mas é a +
difícil de implementar, pois é preciso carregar a msg no buffer do
Identificadores de mensagens:
processo sem que ele solicite. Por isso, alguns sistemas não
1. Request ID: número seqüencial único (ex.: 2**32).
oferecem essa possibilidade.
2. Identificação do processo send (porta) para receber resposta:
• Request ID volta para zero;
29 SD Cap. 1-4 29 SD Cap. 1-4

• Tempo de vida de uma msg. << tempo para esgotar os • Portas permitem que 1 msg seja entregue a vários processos em
números. máquinas diferentes;
• Alguns sistemas permitem usar endereços de grupos de
Destino de mensagens processos.

Na Internet, msgs são enviadas para <Endereço IP, porta>. Uma


porta é um processo destino num computador. Referências a objetos remotos
Uma porta tem no máximo um receptor. Mas pode ter vários
transmissores. Feito através de mensagens de invocação.
Qualquer processo que saiba o número de uma porta pode enviar Especifica que objeto deve ter um de seus métodos invocados.
msgs para ela. Válido dentro de um SD determinado.
Em geral, servidores publicam suas portas para os clientes. Ex.:
• Endereço IP (32 bits);
Se um cliente usa um end. Internet para um serviço, esse serviço
• Porta (32 bits);
deve rodar sempre no mesmo endereço (não permite mobilidade, não
é transparente, etc.). • Hora (32 bits);
• Número de objeto (32 bits);
Para evitar isso: • Interface para o objeto remoto.
• Clientes se referem a serviços pelo nome, e um serviço de nomes
ou binder faz a tradução; 4.4 Comunicação cliente-servidor
o Permite relocação, mas não migração.
• É possível ao SO usar endereços independentes de localização, Protocolos request-reply:
fazendo seu mapeamento para endereços de baixo nível; Cliente Servidor
o Permite relocação e migração. DoOperation GetRequest

Alternativa: endereçar msgs para processos em vez de portas (ex. V wait processa
System – 1984).
• Cada processo recebe um número único para o sistema inteiro; continua SendReply
• Portas permitem que um processo tenha vários endereços para
receber msgs; DoOperation(Porta, Msg, Resposta);
30 SD Cap. 1-4 30 SD Cap. 1-4

Implementação: Perda de respostas:


• Send(Porta, Msg); • Operação reexecutada após a repetição de uma requisição;
• Receive(Fonte, Resposta). • Não há problemas caso a operação seja idempotente;
• Timeout para falhas e retransmissão.
Histórico:
GetRequest(Porta, Msg); • Para servidores não idempotentes;
SendReply(Porta_Cliente, Resposta); • Registro das respostas enviadas para cada requisição;
• Custo de memória para manter as informações;
Mensagem de um protocolo request-reply: • Servidor deve saber quando descartar um registro;
• Sistemas interativos: uma resposta a cada requisição – se o
messageType int (0 = request, 1 = reply) cliente retransmite, basta guardar a última resposta.
requestId Int – identifica msg
objectReference RemoteObjectRef Protocolos RPC:
methodId int ou método • Request (R): não há resposta;
argumentos Array de bytes • Request-Reply (RR): resposta = ACK;
• Request-Reply-Acknowledge (RRA):
Timeouts: • O cliente confirma que recebeu a resposta;
• Indica que uma operação DoOperation falhou; • Um ACK confirma todos os anteriores.
• Pode ocorrer porque um reply ou request se perdeu;
o Em caso de reply, a operação foi feita; Exemplo: protocolo HTTP
• Leva à retransmissão até que chegue uma resposta ou que se • Clientes especificam uma URL (host + porta {opcional});
assuma que o servidor não vai responder. • HTTP especifica as mensagens, métodos, argumentos e
resultados;
Descartando mensagens duplicadas: • Há um conjunto fixo de métodos (GET, PUT, POST, etc.).
• Com retransmissão, um servidor pode receber uma mensagem
mais de uma vez. • Especificação de conteúdo: os clientes podem dizer ao servidor
• O servidor pode executar uma requisição num tempo maior do que tipo de dados eles podem representar.
que o timeout do cliente. • Autenticação: o servidor pode dar um reply solicitando user +
• Controle de Identificação da mensagem. password, caso o cliente tente acessar uma área protegida.
31 SD Cap. 1-4 31 SD Cap. 1-4

Navegadores podem usar conexões persistentes, já que o Detalhes específicos do Ipv4:


estabelecimento de conexões a cada pedido é muito custoso. Essas • Roteadores multicast: pacotes IP podem ser enviados por
conexões permanecem ativas mesmo entre várias requisições. multicast para redes locais (ex.: multicast Ethernet) ou na
Internet. Roteadores multicast sabem utros roteadores debem
receber um pacote (suas redes possuem membros). O TTL limita
4.5 Comunicação de Grupo a distância entre membros de um grupo.
• Alocação de endereços: endereços multicast podem ser
Mensagens multicast são úteis para construir Sistemas Distribuídos: permanentes ou temporários. Grupos permanentes existem
• Tolerância a falhas baseadas em serviços replicados; mesmo sem nenhum membro. Esses endereços são da faixa
• Descobrir serviços em comunicação espontânea; 224.0.0.1 até 224.0.0.255.
• Melhor desempenho através de dados replicados;
Modelo de falhas para datagramas multicast
• Localização de objetos controlados individualmente;
• Desempenho: após alteração, dados enviados para todos os Datagramas de IP multicast têm os mesmos problemas de
interessados; datagramas UDP – sofrem falhas por omissão.
• Atualização múltipla: ex.: usuários de uma lista; • Não há garantias que um membro de um grupo receberá uma
• Propagação de notificações de eventos. mensagem – multicast não confiável.

4.5.1 IP multicast – uma implementação de 4.5.2 Confiabilidade e ordenação de multicast


comunicação de grupos
• Um datagrama pode ser extraviado porque o buffer do destino
Grupos multicast são especificados por endereços classe D (1os. 4 está cheio;
bits = 1110). • O extravio de um datagrama por um roteador evita a recepção da
Membros de um grupo recebem pacotes IP endereçados ao grupo. msg por todas as máquinas depois dele;
• Pacotes IP enviados por um internetwork não chegam
A participação como membro é dinâmica. necessariamente na ordem em que foram enviados.
Só disponível via protocolo UDP.
32 SD Cap. 1-4 32 SD Cap. 1-4

Atomicidade: • Mensagens enviadas para um grupo via multicast totalmente


• Caso 1: todos os servidores precisam receber: ordenado
• Multicast atômico: todos recebem ou nenhum.
• Multicast confiável: há um esforço para garantir a entrega, Implementação de comunicação de grupos
mas não há garantias. • Forma mais simples: multicast não confiável;
• Mensagem única é enviada para cada destino:
Ordenação
Operações multicast atômicas e confiáveis fornecem ordenação void multicast(PortId porta[], Message m) {
FIFO. Neste tipo de ordenação, as mensagens entre3 clientes e int i;
servidores são entregues na ordem de envio (possível pelo uso de
for (i = 0; i < sizeof(porta); i++)
números de seqüência dentro das mensagens). Send(porta(i), m);
No caso 1, todos os servidores devem executar todas as requisições }
na mesma ordem.
Sem um mecanismo de garantia da ordenação, as mensagens podem • Este procedimento potencialmente é não confiável – usa o Send
chegar em ordem diferente dependendo do servidor. P. ex.: há básico;
extravios e retransmissões. • Essa função implica na existência de um serviço de controle de
grupos, do qual se obteve os números de porta dos participantes.
P1 P2 P3 P4

Eficiência
A B • Pode-se aumentar muito a eficiência de um multicast;
A
• Ex.: em redes Ethernet, há formas de fazer broadcast para todos
B
os computadores de uma rede local;
Tempo
• Ethernet também admite enviar uma mensagem para vários
computadores da rede (multicast);
• Isso não resolve todos os problemas:
• Pode haver mais de um processo em um nó da rede;
• Pode haver processos em redes locais diferentes, conectadas
Forma mais forte de ordenação: multicast totalmente ordenado. entre si.
33 SD Cap. 1-4 33 SD Cap. 1-4

• Um sistema multicast de fato deve enviar mensagens para todos • Quando todos os acks chegarem, o transmissor tem certeza
os processos de um grupo, independente de sua localização. de que todos os processos receberam.
• Se um ack não é recebido até um timeout, a mensagem é
Confiabilidade retransmitida;
• Razões para que uma mensagem não alcance todos os membros • Após um número de retransmissões, assume-se que o membro do
de um grupo: grupo falhou – ele é removido.
• Extravio, caso as mensagens sejam enviadas uma a uma;
• Quem envia pode falhar após enviar para alguns dos • Pode ser que o transmissor falhe após enviar algumas
participantes. mensagens;
• Os membros do grupo podem enviar seus acks e monitorar o
• Nenhum desses motivos é aceitável para aplicações com transmissor para ver se ele recebeu todos os acks ou falhou;
multicast atômico ou totalmente ordenado. • Em caso de falha, há duas possibilidades:
• Um processo substitui o transmissor (cliente) e completa o
Monitoramento multicast;
• Faz parte do serviço de grupos; • Ou ele falha e um ou mais membros do grupo detectam sua
• Quando um processo envia uma mensagem para um grupo, ele falha – neste caso, a mensagem é descartada por todos os que
monitora se todos receberam; receberam.
• Isso é feito com o reenvio caso um dos processo do grupo não • Para reduzir custos, uma nova requisição confirma que a anterior
responda; foi bem sucedida.
• Após um certo número de tentativas, o processo que não
responde é descartado do grupo; Este protocolo tem um desempenho ruim, mesmo num meio que não
• Mensagens de processos removidos são descartadas; apresente falhas.
• Essencial para protocolos de multicast atômico. Há duas formas de se aumentar o desempenho desse tipo de
comunicação.
Multicast atômico e confiável
• Forma de implementar um multicast confiável: Hold-back
• O transmissor envia mesma mensagem para todos os
componentes do grupo; • O elemento que controla a comunicação retém a última
• Aguarda um ack de todos os processos; mensagem até garantir que os requisitos de atomicidade e
ordenação foram satisfeitos.
34 SD Cap. 1-4 34 SD Cap. 1-4

Ack negativo 2 – Encontrando os serviços em computação espontânea:


• Processos que querem descobrir serviços disponíveis fazem
• Reduz o número de mensagens trocadas entre os pares; multicast de requisições periodicamente. O extravio de uma
• Cada transmissor mantém um contador do número de mensagens dessas msgs não é aceitável.
enviadas;
• Esse contador é acrescentado a todas as mensagens; 3 – Melhor desempenho com dados replicados:
• Os receptores controlam se receberam todas as mensagens • No caso de serviços em que os dados são mantidos por msgs
enviadas; multicast.
• Se alguma delas não foi recebida, o receptor envia um ack • A perda de msgs pode levar à quebra de ordenação.
negativo comunicando este fato ao transmissor; • O tipo de serviço usado para multicast depende da necessidade
de exatidão em todas as réplicas.
• Neste caso, não há acks de confirmação;
• Obriga o transmissor a manter um histórico das mensagens 4 – Propagação de notificação de eventos:
transmitidas; • Ex.: novos serviços podem ser informados por msgs multicast
• Se o transmissor falha e outro processo o substitui, esse histórico periódicas.
deve estar disponível;
• Deve haver um método que evite o histórico de ficar muito
grande;
• Uma forma é usar eventuais acks de confirmação piggybacked
em outras mensagens – até aquele número, o transmissor pode
descartar o histórico.

Alguns exemplos dos efeitos da confiabilidade e ordenação

1 – Tolerância a falhas baseado em serviços replicados:


• Um serviço replicado deve iniciar com todos os membros no
mesmo estado.
• Todas as operações devem ser feitas por todos os membros, na
mesma ordem.

Você também pode gostar