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
Tanenbaum disse que vários sistemas apresentados como
distribuídos na verdade não eram. Regra geral: se é possível dizer
qual máquina é responsável por uma tarefa, então não é um SD.
Exemplos de SDs:
1 – Unix Distribuído.
O Unix talvez seja o sistema operacional multiusuário mais
conhecido. Quando os SDs começaram a ser pesquisados, o Unix era
largamente utilizado. Muitos pesquisadores adotaram o modelo Unix
como meta:
• Um modelo Unix que pudesse explorar os recursos de muitos
computadores;
• Desempenho superior ao de uma estação isolada.
A versão 4BSD do Unix foi extendida para suportar IPC. Este
recurso foi extendido e explorado na construção dos 1os SDs.
O Unix introduziu o conceito de sistemas tipo cliente-servidor ao
possibilitar a construção de servidores acessíveis através de IPC.
Foi usado como modelo na implementação de vários sistemas:
• A Sun usou-o no desenvolvimento do NFS (Network File
System);
• Também serviu de modelo na implementação do RPC
(Remote Procedure Call);
• NIS (Network Information System);
• Amoeba (DOS);
• Mach (DOS);
• Chorus (DOS);
• Andrew (FS);
• Kerberos (Segurança).
2 SD Cap. 1-4
O modelo cliente-servidor implementa o compartilhamento de
recursos, um dos principais objetivos que motivaram o
desenvolvimento das redes locais.
O acesso aos servidores é feito por meio de requisições, que são
mensagens enviadas pelo cliente contendo pedidos de ações a serem
feitas pelo servidor.
Ao enviar uma requisição, dizemos que o cliente invoca o servidor.
A operação completa, desde o envio da requisição até o recebimento
da resposta, é chamada de invocação remota.
Um servidor pode ser cliente de outro servidor. Assim, o modelo
cliente-servidor só é válido para uma única requisição.
Clientes são entidades ativas, enquanto servidores são passivos.
Servidores permanecem rodando, esperando pela chegada de
requisições. Clientes só executam no período em que sua aplicação é
necessária.
Os recursos de uma rede podem ser encapsulados em objetos. Nesse
caso, clientes e servidores podem ser objetos escritos em uma
linguagem OO. A invocação remota é substituída pela chamada
remota de um método do objeto servidor.
2 – Internet.
A Internet é um grande sistema distribuído, fornecendo serviços para
seus usuários como: WWW, email, FTP, etc.
Esses serviços são fornecidos da mesma maneira em qualquer lugar.
O usuário pode fazer uso deles onde quiser, com a máquina que
quiser e quando quiser.
Provedores fornecem o acesso para usuários caseiros. Empresas
podem contratar linhas de maior capacidade. Todos eles são
conectados através de redes de alta capacidade, os backbones, qure
são fornecidas por provedores de “atacado”.
3 SD Cap. 1-4
A Internet manipula diferentes tipos de dados, incluindo multimídia.
Os usuários podem ouvir rádios, ver TV, filmes, participar de
reuniões e até fazer ligações telefônicas.
Um aspecto interessante da Internet é que ela possui transparência de
escala, permitindo que seu tamanho e aplicações cresçam por várias
ordens de magnitude.
Apesar das linhas apresentarem restrições de capacidade, elas
suportam várias aplicações distribuídas. A mais conhecida é o email.
O principal problema do email é encontrar o destinatário através de
um endereço como president@whitehouse.gov ou abc@din.uem.br.
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
está o destinatário.
3 – Intranets.
Intranets são pedaços da Internet administrados em separado e que
possuem controle de segurança próprio. Podem estar ou não ligados
à grande rede.
3 – Computação móvel e “ubiquitous”.
Integração de pequenos diispositivos móveis com a Internet e
acréscimo de poder de processamento em máquinas e equipamentos:
• Laptops e notebooks;
• Handtops, celulares, etc.;
• Dispositivos sem fio;
• Dispositivos embutidos em máquinas de lavar, aparelhos de
som, microondas, carros, geladeiras, etc.
3 SD Cap. 1-4
A computação móvel também é chamada de nômade. Nesse modelo,
o usuário acessa a rede fora de seu ambiente normal (casa ou
escritório) através de dispositivos que ele carrega consigo.
Computação “ubiquitous” é realizada por vários dispositivos
pequenos e baratos que estão presentes em nosso ambiente (casa,
escritório, ou qualquer outro lugar). O termo sugere uma situação em
que seu uso será tão grande que sua presença será ignorada. Quer
dizer, seu comportamento será transparente.
4 – WWW.
A Web é um sistema em constante evolução que se baseia em
documentos hipertextos. Os usuários organizam seu conhecimento
por meio de links. Esse sitema foi concebido em 1945 por Bush. Sua
implementação só foi possível com o surgimento da Internet.
A Web é um sistema aberto. Pode ser extendido e implementado de
várias formas sem alterar o funcionamento da base já instalada. Sua
operação é baseada em comunicação e documentação padrões
distribuídos livremente.
P. ex.:
• Há vários navegadores;
• São implementados em plataformas diferentes;
• Há várias implementações de servidores.
Qualquer navegador pode recuperar páginas de qualquer servidor.
Também é aberta em relação ao tipo de mídia publicado:
• Páginas (texto);
• Programas;
• Imagens;
• Música;
4 SD Cap. 1-4
• Vídeo;
• Documentos (Word, PS, PDF, etc.).
Se alguém inventar um novo tipo de mídia, objetos desse tipo podem
ser publicados na Web imediatamente. Basta criar um “driver” para
tratar esta nova mídia. Os navegadores são construídos para
aceitarem novas funcionalidades por meio de plug-ins.
As páginas receberam funcionalidade para aceitar dados, e não
apenas mostrá-los.
A Web evolui de um sistema de visualização para um sistema de
prestação de serviços, como compra de bens, transações bancárias,
etc. Para realizar esses serviços, não houve modificações estruturais.
A Web apresenta 3 principais componentes tecnológicos padrões:
• HTML: linguagem para especificar conteúdo e layout das
páginas;
• URL: identificadores de documentos e outros recursos;
• HTTP: protocolo que define a arquitetura cliente-servidor da
Web.
Mais recentemente, a Web recebeu acréscimos como páginas
dinâmicas.e formulários. P. ex.:
• Ao preencher um formulário e apertar o botão que executa a
transação, o navegador faz uma requisição ao servidor;
• http://www.google.com/search?q=“Bin Laden”
• O navegador envia uma requisição de pesquisa (q) por “Bin
Laden”;
• Quem pode pesquisar é um programa (o navegador não está
pedindo um arquivo). Ele é search.
• A URL do servidor é www.google.com;
4 SD Cap. 1-4
• O tipo de serviço é WWW (http);
• O resultado dessa pesquisa é uma página mostrada ao
usuário. Essa página não existe (dinâmica). Após seu envio
para o navegador, ela não será mantida.
No começo, esses programas eram escritos em CGI, mas hoje há
várias opções: PERL, Python, Java, etc.
Problemas da Web:
• Recursos removidos podem continuar apontados por outras
páginas;
• O conteúdo não necessariamente é confiável;
• Sistemas de pesquisa (ex. google, altavista, etc.) são imperfeitos
e podem não localizar coisas com precisão;
• Está em andamento um sistema de padronização de metadados
para registrar melhor o conteúdo das páginas - sistemas de
pesquisa poderiam melhorar seu desempenho baseado nisso;
• A diversidade de tipos de dados na Web é um problema para
uma linguagem estática como o HTML (todos os tipos de dados
são tratados da mesma forma - a diferença é implementada pelos
plug-ins). Isso levou ao desenvolvimento do XML (Extensible
Markup Language). XML é uma linguagem de descrição de
dados, que torna-os portáveis entre as aplicações.
• Sites muito acessados têm problemas de escala - o acesso pode
ficar lento. Os navegadores (e proxys) implementam caches, mas
não há mecanismo para indicar que um site foi atualizado (um
conteúdo só pode ser renovado em períodos fixos). Isso obriga o
usuário a fazer refresh de uma página se quiser ver se ela foi
atualizada;
5 SD Cap. 1-4
• Sites com anúncios obrigam os navegadores a buscar sempre a
última versão em vez de usar o cache;
• Páginas não são um meio apropriado para representar todas as
informações. Isso levou ao uso de applets e muitas imagens para
tornar a interface mais aceitável. Também gasta mais tempo para
fazer um download completo.
Características principais
1 - Heterogeneidade
Aplica-se a redes, computadores, sistemas operacionais, linguagens
de programação e implementações de diferentes desenvolvedores.
• A Internet é composta de vários tipos de redes diferentes, mas
todas implementam o Protocolo IP;
• Plataformas diferentes podem ter representações diferentes de
inteiros, reais, etc.
• Apesar da necessidade de toda máquina ligada à Internet ter uma
implementação do IP, os SOs não possuem a mesma interface
(chamadas).
• Linguagens diferentes possuem diferentes formas de representar
dados. Isso deve ser considerado se elas devem se comunicar
umas com as outras;
• Programas escritos por desenvolvedores diferentes não se
comunicam, a menos que usem padrões comuns (comunicação,
dados, estruturas, passagem de parâmetros, etc.).
Middleware
5 SD Cap. 1-4
Camadas de software que fornecem abstrações de programação e
mascaram a heterogeneidade dos elementos abaixo.
Ex.: CORBA.
Alguns middlewares suportam apenas uma linguagem (ex. Java
RMI).
Todos são implementados sobre o IP - mascaram diferenças entre as
redes.
Todos precisam tratar diferenças de SOs e hardware.
Para resolver os problemas de heterogeneidade, os middlewares
fornecem modelos computacionais uniformes para os
programadores.
Possíveis modelos incluem:
• Invocação remota de objetos;
• Notificação remota de eventos;
• Acesso remoto com SQL;
• Transações distribuídas.
Heterogeneidade e código móvel
Código móvel: código que pode ser enviado de um computador para
outro e rodar no destino. Ex.: applets Java.
O código depende do tipo de arquitetura de origem.
A abordagem com máquinas virtuais permite fazer código
executável em qualquer plataforma. Ex.: um compilador Java produz
código para a JVM, que pode rodar em qualquer plataforma com
JVM implementada.
Esta solução não é aplicável a todas as linguagens. Ex.: não existe
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
difícil (ou mesmo impossível) detectar falhas como crash de
servidores. O desafio é gerenciar falhas que não podem ser
detectadas, mas podem ser presumidas.
• Mascaramento de falhas: as falhas detectadas podem ser
escondidas ou tornadas menos severas:
• Mensagens podem ser retransmitidas;
• Dados podem ser armazenados em + de um disco - se um
falha, o outro pode continuar em uso.
No pior caso, essas técnicas podem não funcionar. P. ex. o 2o. disco
pode estar corrompido também.
• Tolerar falhas: a maioria dos serviços na Internet apresentam
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
não pode ficar indefinidamente a espera de que ele volte. Nesse
caso, um erro é apresentado ao usuário.
• Recuperação de falhas: envolve o projeto de software. P. ex.
roll-back numa falha de servidor.
• Redundância: Ex.:
• 2 rotas para acessar um servidor importante;
• No DNS, as tabelas são replicadas em pelo menos 2
servidores diferentes;
• Um BD pode ser replicado em vários servidores;
• Servidores projetados para detectar falhas em seus pares;
• Clientes são redirecionados a um backup quando um servidor
falha.
6 - Concorrência
Há possibilidade de um recurso ser acessado por vários clientes ao
mesmo tempo.
8 SD Cap. 1-4
O servidor de um recurso pode atender um cliente de cada vez. Isso
limita o throughput.
P. ex. cada recurso é encapsulado em um objeto.
Invocações são executadas em threads concorrentes
É possível que sua operação possa ser conflitante,
produzindo inconsistências
Resultado: qualquer objeto que gerencie um recurso compartilhado
deve garantir que ele opere com correção num ambiente concorrente.
Seus dados devem se manter consistentes.
7 - Transparência
ANSA (Advanced Networks Systems Architecture) e ISO
(International Standards Organization) definem 8 formas de
transparência:
• Acesso: recursos remotos e locais são acessados com as mesmas
operações;
• Localização: acesso aos recursos sem saber sua localização;
• Concorrência: vários processos acessam os mesmos recursos
compartilhados sem interferência;
• Replicação: múltiplas instâncias de recursos são usadas sem
conhecimento sobre réplicas;
• Falhas: permite aos usuários completarem suas tarefas
independente de falhas em software ou hardware;
• Mobilidade: permite a movimentação de recursos e clientes sem
afetar a operação dos usuários;
• Desempenho: permite ao sistema ser reconfigurado para
melhorar o desempenho;
• Escala: permite mudanças de escala sem alterar aplicações ou
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
relacionam entre si. Também define a forma como são mapeados
numa rede de computadores.
Dificuldades e ameaças aos SDs:
• Grande variação nas formas de utilização: p. ex.:
• Variação de carga - algumas páginas são pouco acessadas
enquanto outras recebem milhões de acessos por dia;
• Partes de um sistema podem estar desconectadas;
• Algumas aplicações precisam de grande largura de banda.
• Grande variação de ambientes:
• Há heterogeneidade de hardware, SO e redes;
• Redes sem fio operam a uma fração das LANs;
• Há diferenças de escala: sistemas com dezenas de
computadores até milhões.
• Problemas internos:
• Relógios não sincronizados;
• Atualizações conflitantes;
• Muitas formas de falhas de hardware e software envolvendo
componentes do sistema.
• Ameaças externas:
• Ataques à integridade de dados e ao sigilo;
• Negação de serviço.
Arquitetura de um sistema: sua estrutura em termos de especificação
de componentes separados.
Objetivo geral: garantir que a estrutura vai atender necessidades
atuais e futuras
Principais objetivos: fazer o sistema confiável, manuseável,
adaptável e custo-efetivo.
Simplificação inicial: classificação dos processos em clientes,
servidores e pares.
Variações do modelo cliente-servidor:
• Mobilidade de código de um processo p/ outro permite a
delegação de tarefas. P. ex. clientes podem fazer download de
código dos servidores para executá-los localmente;
• Códigos e objetos podem ser movidos para reduzir o tráfego;
• SDs podem ser projetados para permitir a adição e remoção de
computadores e outros dispositivos móveis - podem descobrir os
serviços disponíveis e oferecer serviços para outros.
2.2.1 Camadas de software
Aplicações,
serviços
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
demorada, já que há atrasos consideráveis caso se precise procurar
algo por todos os processos.
2.2.3 Variações no modelo cliente-servidor
Novas situações:
• Uso de código móvel e agentes móveis;
• Necessidade de computadores de baixo custo;
• Necessidade de adicionar e remover dispositivos móveis.
Apesar da padronização, algumas aplicações apresentam
funcionamento incomum. P. ex.: um broker:
• 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
código das mudanças - push - não é o cliente que pede, mas o
servidor que comunica os dados.
Um código móvel é uma ameaça potencial à segurança dos recursos
locais de um sistema. Por isso, navegadores dão acesso limitado aos
applets baixados da Internet.
13 SD Cap. 1-4
Agentes móveis
Processo (código + dados) que viaja de máquina para máquina numa
rede para executar uma tarefa para alguém.
Ex.: coletar dados, retornando com o resultado.
Podem invocar recursos locais (ex. Bancos de dados), eventualmente
acessando grandes conjuntos de dados.
• Com isso, economizam banda de rede porque o acesso é local,
com melhor tempo de resposta.
Agentes móveis são uma ameaça potencial aos recursos das
máquinas que visitam.
O ambiente local deve decidir:
• A identidade do emissor do agente;
• Que privilégios dar ao agente que chega;
• Que recursos ele pode acessar.
Os próprios agentes são vulneráveis:
• Podem ser atacados nos hosts em que chegam;
• Talvez não possam realizar sua tarefa se não puderem acessar os
recursos de que precisam.
A tarefa de um agente móvel pode ser realizada por outros meios:
• Ex.: invocação remota.
Assim, sua aplicação ainda é restrita.
Network Computers
Um computador típico possui:
• Sistema operacional;
• Aplicações instaladas conforme a necessidade do usuário;
• Pertence a uma plataforma determinada.
13 SD Cap. 1-4
A proposta de um NC possui os seguintes objetivos:
• Sistema operacional e aplicações são baixados de um servidor
remoto;
• Aplicações executam localmente, mas os arquivos são acessados
remotamente;
• Como todos os arquivos são acessados em um servidor, os
usuários podem mudar de computador sem problemas;
• Processador e memória podem ser limitados para reduzir custos;
• Se o NC tem um disco, ele é usado para manter um mínimo de
software;
• A maior parte dele é usada como cache para os arquivos mais
recentes;
• Os objetos mantidos no cache são invalidados quando
atualizados no servidor principal.
Thin Clients
Camada de software que suporta uma interface para o usuário local
enquanto executa aplicações em computadores remotos.
As aplicações rodam em computadores de grande capacidade,
multiprocessadores ou clusters, com um SO como Unix ou Windows
NT/2000/XP.
Problema: aplicações gráficas interativas (ex. Autocad), cujo envio
de telas pela rede pode causar grandes atrasos.
Implementações: X11 (sistema de janelas), WinFrame da Citrix,
VNC da AT&T.
14 SD Cap. 1-4
Dispositivos móveis e comunicação espontânea
Dispositivos móveis estão se tornando populares:
• Notebooks;
• Laptops;
• PDAs;
• Celulares;
• Cameras digitais;
• Computadores “vestíveis” – relógios, etc.
• Dispositivos embutidos (máquinas de lavar, geladeiras, micro-
ondas, etc.).
Esses dispositivos podem realizar comunicação sem fio:
• Grandes distâncias: GSM (centenas de Kbps), CDPD;
• Centenas de metros: WAVELAN;
• Poucos metros: BlueTooth, infravermelho, HomeFR – 10 Mbps.
GSM: Global System Mobile Communication
CDPD: também conhecido como Mobile IP
WAVELAN: LAN sem fio
BlueTooth: padrão de comunicação por rádio
HomeRF: Home Radio Frequency: sistema de comunicação por
rádio
Comunicação espontânea é o termo que indica que os dispositivos
móveis se comunicam com as redes para estabelecer seu
funcionamento.
Principais recursos da comunicação espontânea:
• Fácil conexão com redes locais – não há necessidade de cabos,
plugs, etc.;
14 SD Cap. 1-4
• Fácil integração com os serviços locais – os dispositivos
descobrem os recursos disponíveis e podem utilizá-los quando
necessário.
Desafio de conseguir conexão e integração fáceis:
• Ex.: endereços IP assumem que as máquinas pertencem a uma
determinada subrede – se o computador é movido para outra
rede, ele não pode ser acessado com o mesmo endereço.
Os usuários podem ter problemas de conexão à medida que viajam
A natureza espontânea de sua conexão pode levar a problemas de
segurança.
• Conectividade limitada: p. ex. O usuário pode sofrer
desconexões intermitentes se viajar num trem que passa por
túneis
• O usuário pode ser desconectado quando estiver numa região
sem acesso – como suportar o usuário para que ele possa
trabalhar mesmo desconectado?
• Segurança e privacidade: p. ex. Usuários ou funcionários de
uma instalação podem tentar se conectar num modo não
supervisionado;
• Usuários podem ser espionados a medida que se movem por
várias redes;
• Usuários podem acessar suas redes caseiras, o que pode tornar
esses ambientes suscetíveis a ataques – dados mantidos por um
firewall podem ser interceptados quando o usuário acessa-os.
15 SD Cap. 1-4
• Descobrir serviços: ao se conectar com uma rede, o dispositivo
móvel deve identificar os recursos disponíveis (ex.: impressoras,
fax, TVs, etc.)
• Não se pode esperar que os protocolos de todos os recursos
sejam compatíveis;
• Deve haver meios de descobrir os recursos disponíveis e obter
dados sobre eles;
• Quando so usuários quiserem, poderão fazer requisições sobre
esses recursos;
Um serviço de descoberta tem 2 interfaces:
• Serviço de registro: aceita registros dos servidores e mantém
bancos de dados sobre os recursos disponíveis;
• Serviço de lookup (pesquisa): aceita requisições dos usuários e
o BD por serviços que possam atendê-las;
Ex.: usuário em um hotel com figuras numa câmera digital que
deseja ver como elas saíram.
2.2.4 Interfaces e Objetos
Definições de interface: conjunto de funções disponíveis para
invocação em um processo (servidor, peer, etc.). Ex.: C++, Java, etc.
Linguagens orientadas a objetos podem encapsular objetos com uma
interface definida. Os métodos desses objetos podem ser invocados
remotamente. Ex.: CORBA, RMI, etc.
15 SD Cap. 1-4
2.2.5 Requisitos de projeto para arquiteturas
distribuídas
Compartilhamento de recursos foi lançado nos anos 60, com o
sistemas timesharing. Ex. Sistemas operacionais multiusuários
(Unix) ou sistemas de banco de dados multiusuários (Oracle).
O surgimento de processadores baratos e de alto desempenho tirou o
controle dos recursos de máquinas de grande capacidade passou-os
para qualquer máquina da rede.
A necessidade de compartilhamento de recursos físicos
(impressoras, discos, etc.) levou aos SDs dos anos 70 e 80.
Hoje, o compartilhamento atinge principalmente os dados.
O principal desafio é controlar o acesso concorrente aos dados e
evitar os conflitos de atualização.
Questões de desempenho
Derivado do uso de máquinas e linhas de comunicação limitadas,
aparecem 3 principais elementos:
• Tempo de resposta: o acesso a recursos remotos leva a atrasos
consideráveis nas respostas a requisições do usuário;
• Para melhorar os tempos de resposta, o software deve ser
composto de poucas camadas;
• A quantidade de dados trocadas entre os processos deve ser
pequena.
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
• Throughput: taxa de realização de trabalho computacional.
Num SD é a habilidade de realizar trabalho para todos os seus
usuários. Valor afetado pela velocidade de clientes e servidores e
pelas taxas de transferência.
• Considere dados localizados num servidor remoto:
o Os dados precisam passar do processo servidor para o
processo cliente;
o Nesse processo, eles atravessam várias camadas de
software nos 2 lados;
o O throughput de cada camada é importante, assim como
o da rede.
• Balanceamento de carga: uma das finalidades de um SD:
permitir que aplicações e outros processos processem
concorrentemente sem competição por recursos.
• P. ex.: rodar applets nos clientes permite ao servidor prestar um
serviço melhor;
• Ex.: vários computadores para manter um só serviço. O DNS
tem um recurso de lookup que devolve só um deles na pesquisa
de um domínio;
• Algumas vezes, é preciso mover um serviço parcialmente feito
para ajustar a carga de um sistema.
Qualidade de serviço
Uma vez que um SD tenha o serviço que o usuário precisa, é preciso
verificar sua qualidade.
Propriedades que afetam a qualidade:
• Confiabilidade, segurança e desempenho.
16 SD Cap. 1-4
Recursos reconhecidos a pouco tempo como muito importantes para
a qualidade:
• Adaptabilidade: para se adequar a mudanças;
• Disponibilidade de recursos.
Aspectos de desempenho em QoS até pouco tempo eram tratados
como tempo de resposta e throughput.
Recentemente se considera que são as garantias de se respeitar
limites de tempo.
Algumas aplicações trabalham com dados de tempo crítico - cadeias
que precisam ser processadas entre processos a uma taxa fixa. Ex.:
vídeo.
QoS é considerado hoje como a capacidade de atender deadlines.
Alcançar isso depende de existir suficiente recurso de processamento
e redes no momento certo.
Quem deve garantir esses recursos é o sistema.
Ex.: as redes que se conectam com a Internet hoje conseguem
transferir dados a taxas satisfatórias até que elas se sobrecarreguem.
Nesse caso, o desempenho se deteriora rapidamente.
De forma nenhuma, isso pode ser considerado QoS.
QoS é garantido pelo SO. Recursos críticos devem ser reservados
para as aplicações que precisam de QoS. Gerentes de recursos
devem dar garantias. Requisições de reserva que n\ão podem ser
atendidas são descartadas.
Uso de cache e replicação
As questões de desempenho citadas podem parecer obstáculos para a
construção de SDs.
17 SD Cap. 1-4
Na prática, há técnicas bastante pesquisadas como replicação de
dados e cache.
Vimos antes caches e proxies, sem discutir como as cópias de
recursos são atualizadas quando o original é atualizado em um
servidor.
Diferentes aplicações podem usar diferentes protocolos de cache.
• Protocolo Web-caching (HTTP): proxies e web servers
respondem da mesma forma a requisições dos clientes. O
protocolo de consistência do cache procura garantir que os dados
entregues ao cliente serão "frescos". Mas para garantir
desempenho, disponibilidade e operação offline essa condição
precisa ser relaxada.
• Navegadores ou proxies podem validar uma resposta do cache
verificando o servidor original. Se falhar, o servidor envia os
dados atualizados.
• Quando um dado é atualizado, o servidor não avisa navegadores
e proxies - para isso, seria necessário manter uma relação dos
atuais interessados em cada um dos seus recursos.
• Para permitir aos clientes identificar quando um recurso pode
estar atualizado, o servidor fornece data e hora para expirar
(determinado a partir da média de atualizações registradas).
• Esse recurso pode ser enganoso (dados na Web podem ser
atualizados a qualquer momento).
Os servidores anexam às páginas fornecidas um timestamp de
validade e a hora no servidor.
Navegadores podem saber quando um objeto do cache está para se
tornar inválido quando sua “idade” (soma do momento em que o
17 SD Cap. 1-4
objeto foi colocado no cahe + tempo no servidor) se aproximar do
momento em que a entrada vai expirar.
Esse cálculo não depende que os relógios do servidor, do cliente e
do proxy concordem entre si.
Dependência
Dependência é um alto grau de necessidade dos usuários em relação
a um serviço.
Dependência é relacionado com correção, segurança e tolerância a
falhas.
O desenvolvimento de técnicas para garantir a correção de
programas distribuídos é alvo de várias pesquisas recentes. Há
alguns resultados promissores, mas nenhum maduro o suficiente.
• Tolerância a falhas: aplicações que geram dependência devem
continuar funcionando mesmo na presença de falhas.
Confiabilidade é alcançada através de redundância. Isso é caro e
há limites para o grau de redundância possível. Portanto, há
limites para o grau de tolerância a falhas de um sistema.
• Uma aplicação crítica (ex. Controle de tráfego aéreo) necessita
de alto grau de tolerância a falhas, que leva a um alto custo para
manter réplicas de dados atualizadas.
• Segurança: dados e serviços críticos só devem residir em
computadores a prova de ataques.
• Ex.: o BD de um hospital contém dados que só devem ser vistos
por poucos médicos. Outros dados podem ser vistos por grupos
maiores.
18 SD Cap. 1-4
• Assim, não é possível fazer um sistema que carregue fichas de
pacientes em notebooks porque eles são inseguros por natureza.
2.3 Modelos Fundamentais
Um modelo contém os elementos mínimos para entender e
raciocinar sobre os elementos essenciais de um sistema. Questões
principais:
• Quais são as principais entidades do sistema?
• Como elas interagem?
• Que caracterísiticas afetam seu comportamento individual e
coletivo?
Finalidade de um modelo:
• Tornar explícitas todas as suposições relevantes do sistema
modelado.
• Generalizar o que é possível ou não em geral, tomam a forma de
algoritmos de finalidade geral ou regras (propriedades
desejáveis) garantidos. As garantias são dadas por análise lógica
ou prova matemática.
Aspectos de SDs dos modelos fundamentais:
• Interação: processos interagem por mensagens e coordenação; o
modelo de interação deve tratar dos atrasos inerentes à
comunicação; também deve considerar a precisão com que um
grupo de processos pode se sincronizar – depende dos atrasos e
da manutenção de noção de tempo entre todos os computadores;
18 SD Cap. 1-4
• Falhas: definição dos tipos e classificação das falhas – fornece
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
ataques externos e internos. O modelo de segurança define e
classifica as formas de ataque, permite análise de ameaças e o
projeto de métodos de resistência.
2.3.1 Modelo de Interação
Um programa simples é controlado por um algoritmo sequencial,
cujos passos são realizados numa cadência conhecida. O algoritmo
não interfere nem sofre interferências externas. Ele também define
os conteúdos das variáveis e os estados dos programas em um dado
momento.
SDs são constituídos de múltiplos processos. Seu comportamento
pode ser descrito por um algoritmo distribuído: uma definição de
passos + transmissão de mensagens entre os processos.
As mensagens são usadas para transferir informações e para
coordenar as atividades.
Elementos difíceis de determinar:
• Taxa de andamento de cada processo;
• Momento em que uma mensagem é enviada;
• Estados do algoritmo - é preciso considerar as falhas em 1 ou +
processos, extravio de mensagens, etc.
A seguir, vemos 2 fatores que afetam a interação de processos num
SD.
19 SD Cap. 1-4
Desempenho dos canais de comunicação
• Latência: o atraso entre a transmissão e recepção de uma
mensagem. Inclui:
• Tempo para o 1o. bit sair do transmissor e atingir seu
destino;
• Atraso para acessar a rede - maior em redes carregadas;
• Atraso dos serviços de comunicação dos SOs origem e
destino.
• Banda: capacidade de transmissão total em um certo momento;
• Jitter: variação de tempo para entregar uma série de mensagens
- importante em multimídia, onde a diferença nos tempos de
entrega pode causar distorções.
Relógios e medição de tempo
Cada computador possui seu relógio. Os processos locais usam-no
para medir o tempo dos eventos locais.
Relógios possuem diferenças em relação ao tempo real.
A taxa de diferença mede a relação entre o relógio local e um
relógio perfeito.
Acertando todos os relógios de um SD ao mesmo tempo, após um
certo período pode-se ter variações significativas.
Duas variantes do modelo de interação
É difícil impor limites de tempo para:
• Execução de um processo;
• Trânsito de uma msg;
• Taxa de variação de um relógio.
19 SD Cap. 1-4
Duas abordagens diferentes em relação ao tempo:
• Forte suposição;
• Nenhuma suposição.
SDs síncronos definem os seguintes limites (inferiores e superiores):
• Tempo para realizar um passo;
• Tempo para transmitir uma msg;
• Taxa de variação do relógio local.
É possível sugerir valores, mas é difícil dar garantias sobre eles. Um
SD síncrono tem a vantagem de permitir modelagem, que pode ser
útil para verificar seu funcionamento. Pode-se usar timeouts, p. ex.,
para determinar falhas em serviços.
SDs assíncronos são aqueles que não podem ser qualificados como
síncronos (ex. Internet).
Não possui limites:
• Processos podem demorar longos tempos arbitrários;
• Mensagens podem ser recebidas após longos tempos arbitrários;
• A taxa de variação dos relógios também é arbitrária.
Na Internet, um email pode levar dias ou segundos. A transferência
de um arq. por FTP pode ser rápida, demorada ou inviável.
O problema dos exércitos azul e vermelho assume mais um grau de
dificuldade, caso o sistema seja assíncrono.
Alguns problemas de projeto podem ser resolvidos mesmo nesse
caso. Ex. a Web não possui limites para tempos de resposta, mas os
navegadores podem permitir ao usuário outras atividades enquanto
espera.
Soluções válidas para SDs assíncronos também são válidas para SDs
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
Uma falha é um desvio daquilo que é considerado correto.
O modelo falha determina como as falhas ocorrem para verificar
seus efeitos.
• 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).
As falhas podem ser classificadas por sua severidade. Todos os tipos
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
Falhas arbitrárias
O termo arbitrário (ou Bizantino) descreve o pior tipo de falha
possível, onde um processo não pára (não há crash) mas pode alterar
seus dados com valores errados, ou dar respostas erradas.
Nesse caso, o processamento de uma requisição ocorre com uma
sequência de passos equivocada.
Canais de comunicação são especialmente sujeitos a esse tipo de
falha:
• O conteúdo de uma mensagem pode ser corrompido;
• Mensagens não existentes podem ser entregues;
• 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.).
Falhas de tempo
Ocorrem em SDs síncronos (tempo de execução de processos,
entrega de msgs, diferença entre relógios).
Num SD assíncrono, um servidor pode responder muito lentamente,
mas não se pode falar em falhas de tempo já que não há garantias.
Mascarando falhas
Componentes de SDs são construídos a partir de conjuntos de outros
componentes.
21 SD Cap. 1-4
É possível construir serviços confiáveis a partir de elementos que
apresentam falhas.
As características das falhas permitem desenhar serviços que
mascaram falhas em componentes dos quais o serviço depende.
Formas de mascarar falhas:
• O serviço esconde sua ocorrência;
• A falha é convertida em um tipo + aceitável.
Ex. Checksums mascaram msgs corrompidas – uma falha arbitrária é
convertida em falha por omissão.
Crashes de processos podem ser mascarados – o processo é
substituído e seu estado é restaurado a partir de dados armazenados
pelos predecessores.
Confiabilidade da comunicação 1-para-1
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:
• Validade: uma msg colocada no buffer de transmissão é sempre
entregue no buffer de recepção;
• Integridade: a msg recebida é idêntica à enviada; msgs não são
enviadas + de 1 vez; msgs não enviadas não são entregues.
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
Navegadores podem usar conexões persistentes, já que o
estabelecimento de conexões a cada pedido é muito custoso. Essas
conexões permanecem ativas mesmo entre várias requisições.
4.5 Comunicação de Grupo
Mensagens multicast são úteis para construir Sistemas Distribuídos:
• Tolerância a falhas baseadas em serviços replicados;
• Descobrir serviços em comunicação espontânea;
• Melhor desempenho através de dados replicados;
• Localização de objetos controlados individualmente;
• Desempenho: após alteração, dados enviados para todos os
interessados;
• Atualização múltipla: ex.: usuários de uma lista;
• Propagação de notificações de eventos.
4.5.1 IP multicast – uma implementação de
comunicação de grupos
Grupos multicast são especificados por endereços classe D (1os. 4
bits = 1110).
Membros de um grupo recebem pacotes IP endereçados ao grupo.
A participação como membro é dinâmica.
Só disponível via protocolo UDP.
31 SD Cap. 1-4
Detalhes específicos do Ipv4:
• Roteadores multicast: pacotes IP podem ser enviados por
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
a distância entre membros de um grupo.
• Alocação de endereços: endereços multicast podem ser
permanentes ou temporários. Grupos permanentes existem
mesmo sem nenhum membro. Esses endereços são da faixa
224.0.0.1 até 224.0.0.255.
Modelo de falhas para datagramas multicast
Datagramas de IP multicast têm os mesmos problemas de
datagramas UDP – sofrem falhas por omissão.
• Não há garantias que um membro de um grupo receberá uma
mensagem – multicast não confiável.
4.5.2 Confiabilidade e ordenação de multicast
• Um datagrama pode ser extraviado porque o buffer do destino
está cheio;
• O extravio de um datagrama por um roteador evita a recepção da
msg por todas as máquinas depois dele;
• Pacotes IP enviados por um internetwork não chegam
necessariamente na ordem em que foram enviados.
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:
• Multicast atômico: todos recebem ou nenhum.
• Multicast confiável: há um esforço para garantir a entrega,
mas não há garantias.
Ordenação
Operações multicast atômicas e confiáveis fornecem ordenação
FIFO. Neste tipo de ordenação, as mensagens entre3 clientes e
servidores são entregues na ordem de envio (possível pelo uso de
números de seqüência dentro das mensagens).
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
chegar em ordem diferente dependendo do servidor. P. ex.: há
extravios e retransmissões.
P1 P2 P3 P4
ordenado
Implementação de comunicação de grupos
• Forma mais simples: multicast não confiável;
• Mensagem única é enviada para cada destino:
void multicast(PortId porta[], Message m) {
int i;
for (i = 0; i < sizeof(porta); i++)
Send(porta(i), m);
}
• Este procedimento potencialmente é não confiável – usa o Send
básico;
• 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.

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

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

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.