1 SD Cap. 1-4 1 SD Cap.

1-4
Cap. 1 Caracterizao

Definies:
Tanenbaum: Ns usamos o termo Sistema Distribudo com
o sentido de um Sistema Operacional Distribudo;
Mullender: Um SD um sistema com vrios EPs e vrios
dispositivos de armazenamento, conectados entre si por uma
rede;
Lamport: Um SD aquele que no permite que voc
produza qualquer tipo de trabalho quando ocorre uma pane
numa mquina que voc nem sabia que existia;
Coulouris: Um SD consiste de um conjunto de
computadores autnomos conectados por uma rede, cada um
deles equipado com um Software de SD.

Definies mais recentes:
Tanenbaum: Um SOD aquele que, para seus usurios,
parece um SO centralizado, mas executa sobre mltiplas
CPUs independentes. O conceito chave aqui
transparncia, ou seja, os mltiplos processadores utilizados
devem ser invisveis (transparentes) para o usurio. Outra
forma de expressar a mesma idia dizer que o usurio
enxerga o sistema como um processador virtual nico, e
no como um conjunto de mquinas distintas;

Mullender:
Definir exatamente um SD perigoso;
Uma caracterstica importante (ou que pode ser importante
no futuro) pode ser esquecida.

Schroeder:
Avaliao de um candidato a SD atravs de sintomas:
o Vrios EPs;
o Hardware de interconexo;
o Os EPs falham independentemente;
o Estado do sistema compartilhado.

Coulouris (ed. 2):
Compartilhamento de recursos;
Abertura;
Concorrncia;
Independncia de escala;
Tolerncia a falhas;
Transparncia.

Coulouris (ed. 3):
Heterogeneidade;
Abertura;
Segurana;
Independncia de escala;
Tratamento de falhas;
Concorrncia;
Transparncia.

2 SD Cap. 1-4 2 SD Cap. 1-4
Tanenbaum disse que vrios sistemas apresentados como
distribudos na verdade no eram. Regra geral: se possvel dizer
qual mquina responsvel por uma tarefa, ento no um SD.

Exemplos de SDs:

1 Unix Distribudo.
O Unix talvez seja o sistema operacional multiusurio mais
conhecido. Quando os SDs comearam 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 estao isolada.
A verso 4BSD do Unix foi extendida para suportar IPC. Este
recurso foi extendido e explorado na construo dos 1
os
SDs.

O Unix introduziu o conceito de sistemas tipo cliente-servidor ao
possibilitar a construo de servidores acessveis atravs de IPC.
Foi usado como modelo na implementao de vrios sistemas:
A Sun usou-o no desenvolvimento do NFS (Network File
System);
Tambm serviu de modelo na implementao do RPC
(Remote Procedure Call);
NIS (Network Information System);
Amoeba (DOS);
Mach (DOS);
Chorus (DOS);
Andrew (FS);
Kerberos (Segurana).
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 requisies, que so
mensagens enviadas pelo cliente contendo pedidos de aes a serem
feitas pelo servidor.
Ao enviar uma requisio, dizemos que o cliente invoca o servidor.
A operao completa, desde o envio da requisio at o recebimento
da resposta, chamada de invocao remota.
Um servidor pode ser cliente de outro servidor. Assim, o modelo
cliente-servidor s vlido para uma nica requisio.
Clientes so entidades ativas, enquanto servidores so passivos.
Servidores permanecem rodando, esperando pela chegada de
requisies. Clientes s executam no perodo em que sua aplicao
necessria.
Os recursos de uma rede podem ser encapsulados em objetos. Nesse
caso, clientes e servidores podem ser objetos escritos em uma
linguagem OO. A invocao remota substituda pela chamada
remota de um mtodo do objeto servidor.

2 Internet.
A Internet um grande sistema distribudo, fornecendo servios para
seus usurios como: WWW, email, FTP, etc.
Esses servios so fornecidos da mesma maneira em qualquer lugar.
O usurio pode fazer uso deles onde quiser, com a mquina que
quiser e quando quiser.
Provedores fornecem o acesso para usurios caseiros. Empresas
podem contratar linhas de maior capacidade. Todos eles so
conectados atravs de redes de alta capacidade, os backbones, qure
so fornecidas por provedores de atacado.
3 SD Cap. 1-4 3 SD Cap. 1-4
A Internet manipula diferentes tipos de dados, incluindo multimdia.
Os usurios podem ouvir rdios, ver TV, filmes, participar de
reunies e at fazer ligaes telefnicas.
Um aspecto interessante da Internet que ela possui transparncia de
escala, permitindo que seu tamanho e aplicaes cresam por vrias
ordens de magnitude.
Apesar das linhas apresentarem restries de capacidade, elas
suportam vrias aplicaes distribudas. A mais conhecida o email.
O principal problema do email encontrar o destinatrio atravs de
um endereo como president@whitehouse.gov ou abc@din.uem.br.
Esse tipo de endereo no d informaes de como encontrar o
destinatrio (roteamento). Na rede destino no diz em que mquina
est o destinatrio.

3 Intranets.

Intranets so pedaos da Internet administrados em separado e que
possuem controle de segurana prprio. Podem estar ou no ligados
grande rede.

3 Computao mvel e ubiquitous.

Integrao de pequenos diispositivos mveis com a Internet e
acrscimo de poder de processamento em mquinas e equipamentos:
Laptops e notebooks;
Handtops, celulares, etc.;
Dispositivos sem fio;
Dispositivos embutidos em mquinas de lavar, aparelhos de
som, microondas, carros, geladeiras, etc.
A computao mvel tambm chamada de nmade. Nesse modelo,
o usurio acessa a rede fora de seu ambiente normal (casa ou
escritrio) atravs de dispositivos que ele carrega consigo.
Computao ubiquitous realizada por vrios dispositivos
pequenos e baratos que esto presentes em nosso ambiente (casa,
escritrio, ou qualquer outro lugar). O termo sugere uma situao em
que seu uso ser to grande que sua presena ser ignorada. Quer
dizer, seu comportamento ser transparente.

4 WWW.

A Web um sistema em constante evoluo que se baseia em
documentos hipertextos. Os usurios organizam seu conhecimento
por meio de links. Esse sitema foi concebido em 1945 por Bush. Sua
implementao s foi possvel com o surgimento da Internet.
A Web um sistema aberto. Pode ser extendido e implementado de
vrias formas sem alterar o funcionamento da base j instalada. Sua
operao baseada em comunicao e documentao padres
distribudos livremente.
P. ex.:
H vrios navegadores;
So implementados em plataformas diferentes;
H vrias implementaes de servidores.
Qualquer navegador pode recuperar pginas de qualquer servidor.

Tambm aberta em relao ao tipo de mdia publicado:
Pginas (texto);
Programas;
Imagens;
Msica;
4 SD Cap. 1-4 4 SD Cap. 1-4
Vdeo;
Documentos (Word, PS, PDF, etc.).
Se algum inventar um novo tipo de mdia, objetos desse tipo podem
ser publicados na Web imediatamente. Basta criar um driver para
tratar esta nova mdia. Os navegadores so construdos para
aceitarem novas funcionalidades por meio de plug-ins.
As pginas receberam funcionalidade para aceitar dados, e no
apenas mostr-los.

A Web evolui de um sistema de visualizao para um sistema de
prestao de servios, como compra de bens, transaes bancrias,
etc. Para realizar esses servios, no houve modificaes estruturais.

A Web apresenta 3 principais componentes tecnolgicos padres:
HTML: linguagem para especificar contedo e layout das
pginas;
URL: identificadores de documentos e outros recursos;
HTTP: protocolo que define a arquitetura cliente-servidor da
Web.

Mais recentemente, a Web recebeu acrscimos como pginas
dinmicas.e formulrios. P. ex.:
Ao preencher um formulrio e apertar o boto que executa a
transao, o navegador faz uma requisio ao servidor;
http://www.google.com/search?q=Bin Laden
O navegador envia uma requisio de pesquisa (q) por Bin
Laden;
Quem pode pesquisar um programa (o navegador no est
pedindo um arquivo). Ele search.
A URL do servidor www.google.com;
O tipo de servio WWW (http);
O resultado dessa pesquisa uma pgina mostrada ao
usurio. Essa pgina no existe (dinmica). Aps seu envio
para o navegador, ela no ser mantida.

No comeo, esses programas eram escritos em CGI, mas hoje h
vrias opes: PERL, Python, Java, etc.

Problemas da Web:
Recursos removidos podem continuar apontados por outras
pginas;
O contedo no necessariamente confivel;
Sistemas de pesquisa (ex. google, altavista, etc.) so imperfeitos
e podem no localizar coisas com preciso;
Est em andamento um sistema de padronizao de metadados
para registrar melhor o contedo das pginas - sistemas de
pesquisa poderiam melhorar seu desempenho baseado nisso;
A diversidade de tipos de dados na Web um problema para
uma linguagem esttica como o HTML (todos os tipos de dados
so tratados da mesma forma - a diferena implementada pelos
plug-ins). Isso levou ao desenvolvimento do XML (Extensible
Markup Language). XML uma linguagem de descrio de
dados, que torna-os portveis entre as aplicaes.
Sites muito acessados tm problemas de escala - o acesso pode
ficar lento. Os navegadores (e proxys) implementam caches, mas
no h mecanismo para indicar que um site foi atualizado (um
contedo s pode ser renovado em perodos fixos). Isso obriga o
usurio a fazer refresh de uma pgina se quiser ver se ela foi
atualizada;
5 SD Cap. 1-4 5 SD Cap. 1-4
Sites com anncios obrigam os navegadores a buscar sempre a
ltima verso em vez de usar o cache;
Pginas no so um meio apropriado para representar todas as
informaes. Isso levou ao uso de applets e muitas imagens para
tornar a interface mais aceitvel. Tambm gasta mais tempo para
fazer um download completo.

Caractersticas principais

1 - Heterogeneidade

Aplica-se a redes, computadores, sistemas operacionais, linguagens
de programao e implementaes de diferentes desenvolvedores.
A Internet composta de vrios tipos de redes diferentes, mas
todas implementam o Protocolo IP;
Plataformas diferentes podem ter representaes diferentes de
inteiros, reais, etc.
Apesar da necessidade de toda mquina ligada Internet ter uma
implementao do IP, os SOs no 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 no se
comunicam, a menos que usem padres comuns (comunicao,
dados, estruturas, passagem de parmetros, etc.).

Middleware

Camadas de software que fornecem abstraes de programao e
mascaram a heterogeneidade dos elementos abaixo.
Ex.: CORBA.
Alguns middlewares suportam apenas uma linguagem (ex. Java
RMI).
Todos so implementados sobre o IP - mascaram diferenas entre as
redes.
Todos precisam tratar diferenas de SOs e hardware.
Para resolver os problemas de heterogeneidade, os middlewares
fornecem modelos computacionais uniformes para os
programadores.
Possveis modelos incluem:
Invocao remota de objetos;
Notificao remota de eventos;
Acesso remoto com SQL;
Transaes distribudas.

Heterogeneidade e cdigo mvel

Cdigo mvel: cdigo que pode ser enviado de um computador para
outro e rodar no destino. Ex.: applets Java.
O cdigo depende do tipo de arquitetura de origem.
A abordagem com mquinas virtuais permite fazer cdigo
executvel em qualquer plataforma. Ex.: um compilador Java produz
cdigo para a JVM, que pode rodar em qualquer plataforma com
JVM implementada.
Esta soluo no aplicvel a todas as linguagens. Ex.: no existe
uma VM para C.


6 SD Cap. 1-4 6 SD Cap. 1-4
2 - Abertura

Determina se um sistema pode ser estendido e implementado de
vrias formas. Grau com que novos servios de recursos
compartilhados podem ser inseridos.
No pode ser alcanada sem tornar pblicas as documentaes das
interfaces dos principais softwares do sistema.
Palavra chave = publicao!
Grande desafio para os projetistas de um sistema (distribudo) =
juntar componentes desenvolvidos por diferentes pessoas.
Ex. sistema de publicao da Internet = RFCs (Request for
Comments).
Inclui discusses e padronizao de protocolos.
Ex.: CORBA.
Srie de documentos tcnicos separados por rea, incluindo
especificaes completas das interfaces dos servios.

Abertura em relao ao hardware: permite a adio de computadores
na rede.
Ao software: permite a introduo de novos servios e a
reimplementao dos velhos.
Em qualquer caso, permite a independncia em relao aos
vendedores.

3 - Segurana

O tipo de servio prestado por um sistema distribudo provavelmente
alto valor intrnsico. Sua segurana de grande importncia.
A segurana de recursos de informao tem 3 componentes:
Confidencialidade: proteo contra acesso no autorizado;
Integridade: proteo contra estragos;
Disponibilidade: proteo contra interferncias no seu
funcionamento.

Toda a comunicao em um SD ocorre sobre redes. O desafio
enviar informao sensvel em mensagens de forma segura.
Outro problema garantir a identidade de quem recebe e de quem
envia alguma coisa.
Problemas atualmente no completamente resolvidos:
Ataques de negao de servio: atualmente a ao possvel
procurar os responsveis depois que um ataque ocorre.
Segurana de cdigo mvel: garantias para quem recebe e para
quem envia.

4 - Independncia de Escala

Um SD deve operar de forma eficiente independente da escala,
desde uma pequena intranet at a Internet.
Um sistema escalvel se continuar efetivo aps um incremento
significativo de recursos e usurios.
Ex.: Internet de 1979 a 1999

Data Computadores Servidores WWW
12/1979 188 0
07/1989 130.000 0
07/1999 56.218.000 5.560.866

Ex.: nmero de computadores e servidores WWW na histria da
Web (1993 a 1999)

7 SD Cap. 1-4 7 SD Cap. 1-4
Data Computadores Servidores
WWW
%
07/1993 1.776.000 130 0,008
07/1995 6.642.000 23.500 0,4
07/1997 19.540.000 1.203.096 6
07/1999 56.218.000 6.598.697 12

Um SD escalvel apresenta os seguintes desafios:

Controlar o custo de recursos fsicos: medida que a
demanda por recursos cresce, necessrio estender o sistema
para atend-la. Ex.: um certo nmero de usurios podem ser
atendidos por um FS. Se os usurios aumentam, necessrio
introduzir novos FS para evitar um gargalo.
Em geral, para um sistema com N usurios ser escalvel, a
quantidade de recursos fsicos deve ser O(N) proporcional
a N. Ex.: um FS para 20 usurios. Se N passa para 40,
necessrio ter 2 FSs.

Controlar a perda de desempenho: considere um conjunto
de dados proporcional ao nmero de usurios. Ex.: tabela de
converso de nomes do DNS. Algoritmos que usam
estruturas hierrquicas (ex. rvore B) escalam melhor que
aqueles que usam estruturas lineares (ex. Listas).
Mesmo com estruturas hierrquicas, o aumento do nmero
de usurios causa perdas de desempenho, que no devem ser
superiores a O(log n).

Prevenindo o esgotamento de recursos: ex.: nmeros
usados como endereos Internet (32 bits - 1970). Os
endereos se esgotaram por volta do ano 2000. O IPv6 adota
128 bits de endereos. Infelizmente, no h soluo correta
para o problema. No h garantias de que 128 bits no se
esgotaro tambm. Nmeros maiores ocupam mais espao
nas mensagens.

Evitando gargalos de desempenho: algoritmos devem ser
descentralizados. Ex.: antecessor do DNS era um arquivo
central que devia ser baixado pelos servidores que
precisavam dele. O DNS substituiu esse sistema por uma
organizao descentralizada.

Alguns recursos podem ser acessados muito frequentemente. Ex.:
uma pgina de Internet. Nesse caso, pode-se usar cache e replicao.
Idealmente, o sistema e o software de aplicao no devem ser
modificados conforme a escala. Difcil de alcanar! Solues: dados
replicados, cache, mltiplos servidores.

5 - Tratamento de falhas

Computadores falham!
No uma questo de SE eles vo falhar, mas de QUANDO!
Numa falha, um computador pode devolver um resultado errado,
mas, em geral, eles param antes de dar a resposta.
Num SD, falhas so parciais: outros componentes continuam
funcionando.
O tratamento de falhas bastante difcil.
Tcnicas possveis de tratamento:
Deteco de falhas: p. ex.: checksums podem ser usados para
detectar alteraes de pacotes de rede. No cap. 2, veremos que
8 SD Cap. 1-4 8 SD Cap. 1-4
difcil (ou mesmo impossvel) detectar falhas como crash de
servidores. O desafio gerenciar falhas que no 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 tcnicas podem no funcionar. P. ex. o 2o. disco
pode estar corrompido tambm.
Tolerar falhas: a maioria dos servios na Internet apresentam
falhas. No seria prtico tratar todas elas e escond-las dos
usurios. P. ex. um servidor pode no estar no ar. O navegador
no pode ficar indefinidamente a espera de que ele volte. Nesse
caso, um erro apresentado ao usurio.
Recuperao de falhas: envolve o projeto de software. P. ex.
roll-back numa falha de servidor.
Redundncia: Ex.:
2 rotas para acessar um servidor importante;
No DNS, as tabelas so replicadas em pelo menos 2
servidores diferentes;
Um BD pode ser replicado em vrios servidores;
Servidores projetados para detectar falhas em seus pares;
Clientes so redirecionados a um backup quando um servidor
falha.

6 - Concorrncia

H possibilidade de um recurso ser acessado por vrios clientes ao
mesmo tempo.
O servidor de um recurso pode atender um cliente de cada vez. Isso
limita o throughput.
P. ex. cada recurso encapsulado em um objeto.
Invocaes so executadas em threads concorrentes
possvel que sua operao possa ser conflitante,
produzindo inconsistncias
Resultado: qualquer objeto que gerencie um recurso compartilhado
deve garantir que ele opere com correo num ambiente concorrente.
Seus dados devem se manter consistentes.

7 - Transparncia

ANSA (Advanced Networks Systems Architecture) e ISO
(International Standards Organization) definem 8 formas de
transparncia:
Acesso: recursos remotos e locais so acessados com as mesmas
operaes;
Localizao: acesso aos recursos sem saber sua localizao;
Concorrncia: vrios processos acessam os mesmos recursos
compartilhados sem interferncia;
Replicao: mltiplas instncias de recursos so usadas sem
conhecimento sobre rplicas;
Falhas: permite aos usurios completarem suas tarefas
independente de falhas em software ou hardware;
Mobilidade: permite a movimentao de recursos e clientes sem
afetar a operao dos usurios;
Desempenho: permite ao sistema ser reconfigurado para
melhorar o desempenho;
Escala: permite mudanas de escala sem alterar aplicaes ou
algoritmos.
9 SD Cap. 1-4 9 SD Cap. 1-4
Cap. 2 - Modelos de Sistemas

Um modelo de arquitetura define a forma como os componentes se
relacionam entre si. Tambm define a forma como so mapeados
numa rede de computadores.

Dificuldades e ameaas aos SDs:
Grande variao nas formas de utilizao: p. ex.:
Variao de carga - algumas pginas so pouco acessadas
enquanto outras recebem milhes de acessos por dia;
Partes de um sistema podem estar desconectadas;
Algumas aplicaes precisam de grande largura de banda.
Grande variao de ambientes:
H heterogeneidade de hardware, SO e redes;
Redes sem fio operam a uma frao das LANs;
H diferenas de escala: sistemas com dezenas de
computadores at milhes.
Problemas internos:
Relgios no sincronizados;
Atualizaes conflitantes;
Muitas formas de falhas de hardware e software envolvendo
componentes do sistema.
Ameaas externas:
Ataques integridade de dados e ao sigilo;
Negao de servio.

2.2 Modelos arquiteturais

Arquitetura de um sistema: sua estrutura em termos de especificao
de componentes separados.
Objetivo geral: garantir que a estrutura vai atender necessidades
atuais e futuras
Principais objetivos: fazer o sistema confivel, manusevel,
adaptvel e custo-efetivo.
Simplificao inicial: classificao dos processos em clientes,
servidores e pares.

Variaes do modelo cliente-servidor:
Mobilidade de cdigo de um processo p/ outro permite a
delegao de tarefas. P. ex. clientes podem fazer download de
cdigo dos servidores para execut-los localmente;
Cdigos e objetos podem ser movidos para reduzir o trfego;
SDs podem ser projetados para permitir a adio e remoo de
computadores e outros dispositivos mveis - podem descobrir os
servios disponveis e oferecer servios para outros.

2.2.1 Camadas de software

Aplicaes,
servios
Middleware

Sistema
operacional
Hardware e rede

Plataforma
10 SD Cap. 1-4 10 SD Cap. 1-4
Middleware:
Camada de software que mascara a heterogeneidade de um
sistema;
Fornece um modelo para os programadores;
Fornece blocos de construo de componentes de software que
trabalham uns com os outros;
Ultrapassa o nvel de comunicao e permite abstraes como
Invocao Remota, comunicao de grupos, notificao de
eventos, replicao de dados, transmisso de multimdia em
tempo real.

Limitaes do middleware

Ex.: transferncia de grande nmero de emails do servidor para o
cliente.
Aplicao TCP;
Considere uma rede no confivel;
TCP possui alguma deteco de erros e correo;
Mas no h recuperao possvel de erros graves ou
interrupes;
Nesse sentido, o servio de email pode acrescentar tolerncia a
falhas atravs de um registro do trabalho j feito.

O correto comportamento de um SD depende de verificaes,
correo de erros, medidas de segurana em vrios nveis.
preciso acessar dados dentro do espao de endereamento das
aplicaes.
Tentativas de realizar as verificaes atravs dos sistemas de
comunicao padres garante apenas parte das necessidades de
correo.
2.2.2 Arquiteturas de sistemas

Projeto de SD - aspectos + evidentes:
Diviso de responsabilidades entre componentes (aplicaes,
servidores, etc.);
Colocao de componentes em computadores da rede.
Esses itens tm grandes implicaes no desempenho, confiabilidade
e segurana.












Modelo cliente-servidor

Historicamente o modelo mais conhecido e mais usado.
Servidores podem ser clientes:
Servidores WWW podem ser clientes do FS local;
Tambm podem ser clientes do DNS;
Um engenho de pesquisa um cliente (dos sites que visita) e um
servidor (dos usurios que pedem pesquisas);


Cliente
Cliente
Server
Server
11 SD Cap. 1-4 11 SD Cap. 1-4
Servios com mltiplos servidores
















Os servidores podem dividir o conjunto de dados.
Tambm podem manter cpias replicadas.
Replicao aumenta o desempenho, a disponibilidade e a tolerncia
a falhas.

Servidores proxy e cache

Um cache um armazm de objetos mais usados mais perto que os
objetos originais.
Ao receber um objeto, ele adicionado ao cache, eventualmente
substituindo um mais velho.
Ao precisar de um objeto, o cache consultado primeiro. Se houver
uma verso atualizada, ela usada. Se no, feita uma solicitao
do objeto ao seu servidor.
Caches podem ser residentes em cada cliente ou residir em um
proxy, sendo compartilhados por todos.
Caches so bastante utilizados:
Navegadores possuem caches das pginas recentemente visitadas
uma funo especial do protocolo HTTP permite verificar se as
pginas esto atualizadas;
Servidores proxy fornecem pginas j acessadas aos clientes de
uma rede finalidade aumentar o desempenho podem ser
usados para outras finalidades. Ex.: acessar sites atravs de um
firewall.









Processos pares (peer)

Processos que so similares e desempenham os mesmos papis.
Interagem de forma cooperativa para realizar atividades distribudas,
sem distino entre clientes e servidores.



Client
Client
Serv
Serv
Serv
Cliente
Cliente
Proxy
Web Serv
Web Serv
12 SD Cap. 1-4 12 SD Cap. 1-4
















A no existncia de um servidor torna a comunicao mais
demorada, j que h atrasos considerveis caso se precise procurar
algo por todos os processos.

2.2.3 Variaes no modelo cliente-servidor

Novas situaes:
Uso de cdigo mvel e agentes mveis;
Necessidade de computadores de baixo custo;
Necessidade de adicionar e remover dispositivos mveis.



Cdigo mvel

Ex.:
a)




b)





Vantagem: No h atrasos na rede, no gasta banda.

Apesar da padronizao, algumas aplicaes apresentam
funcionamento incomum. P. ex.: um broker:
O cliente faz download de um cdigo para acompanhar o valor
das aes;
O servidor mantm os valores e informa periodicamente o
cdigo das mudanas - push - no o cliente que pede, mas o
servidor que comunica os dados.

Um cdigo mvel uma ameaa potencial segurana dos recursos
locais de um sistema. Por isso, navegadores do acesso limitado aos
applets baixados da Internet.



Aplicao


Cdigo de
coordenao
Aplicao


Cdigo de
coordenao
Aplicao


Cdigo de
coordenao

Cliente

Web Server
Applet
Cliente

Applet

Web Server
13 SD Cap. 1-4 13 SD Cap. 1-4
Agentes mveis

Processo (cdigo + dados) que viaja de mquina para mquina numa
rede para executar uma tarefa para algum.
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 mveis so uma ameaa potencial aos recursos das
mquinas que visitam.
O ambiente local deve decidir:
A identidade do emissor do agente;
Que privilgios dar ao agente que chega;
Que recursos ele pode acessar.
Os prprios agentes so vulnerveis:
Podem ser atacados nos hosts em que chegam;
Talvez no possam realizar sua tarefa se no puderem acessar os
recursos de que precisam.
A tarefa de um agente mvel pode ser realizada por outros meios:
Ex.: invocao remota.
Assim, sua aplicao ainda restrita.

Network Computers

Um computador tpico possui:
Sistema operacional;
Aplicaes instaladas conforme a necessidade do usurio;
Pertence a uma plataforma determinada.

A proposta de um NC possui os seguintes objetivos:
Sistema operacional e aplicaes so baixados de um servidor
remoto;
Aplicaes executam localmente, mas os arquivos so acessados
remotamente;
Como todos os arquivos so acessados em um servidor, os
usurios podem mudar de computador sem problemas;
Processador e memria podem ser limitados para reduzir custos;
Se o NC tem um disco, ele usado para manter um mnimo de
software;
A maior parte dele usada como cache para os arquivos mais
recentes;
Os objetos mantidos no cache so invalidados quando
atualizados no servidor principal.

Thin Clients

Camada de software que suporta uma interface para o usurio local
enquanto executa aplicaes em computadores remotos.
As aplicaes rodam em computadores de grande capacidade,
multiprocessadores ou clusters, com um SO como Unix ou Windows
NT/2000/XP.
Problema: aplicaes grficas interativas (ex. Autocad), cujo envio
de telas pela rede pode causar grandes atrasos.

Implementaes: X11 (sistema de janelas), WinFrame da Citrix,
VNC da AT&T.



14 SD Cap. 1-4 14 SD Cap. 1-4
Dispositivos mveis e comunicao espontnea

Dispositivos mveis esto se tornando populares:
Notebooks;
Laptops;
PDAs;
Celulares;
Cameras digitais;
Computadores vestveis relgios, etc.
Dispositivos embutidos (mquinas de lavar, geladeiras, micro-
ondas, etc.).

Esses dispositivos podem realizar comunicao sem fio:
Grandes distncias: GSM (centenas de Kbps), CDPD;
Centenas de metros: WAVELAN;
Poucos metros: BlueTooth, infravermelho, HomeFR 10 Mbps.

GSM: Global System Mobile Communication
CDPD: tambm conhecido como Mobile IP
WAVELAN: LAN sem fio
BlueTooth: padro de comunicao por rdio
HomeRF: Home Radio Frequency: sistema de comunicao por
rdio

Comunicao espontnea o termo que indica que os dispositivos
mveis se comunicam com as redes para estabelecer seu
funcionamento.
Principais recursos da comunicao espontnea:
Fcil conexo com redes locais no h necessidade de cabos,
plugs, etc.;
Fcil integrao com os servios locais os dispositivos
descobrem os recursos disponveis e podem utiliz-los quando
necessrio.
Desafio de conseguir conexo e integrao fceis:
Ex.: endereos IP assumem que as mquinas pertencem a uma
determinada subrede se o computador movido para outra
rede, ele no pode ser acessado com o mesmo endereo.

Os usurios podem ter problemas de conexo medida que viajam
A natureza espontnea de sua conexo pode levar a problemas de
segurana.

Conectividade limitada: p. ex. O usurio pode sofrer
desconexes intermitentes se viajar num trem que passa por
tneis
O usurio pode ser desconectado quando estiver numa regio
sem acesso como suportar o usurio para que ele possa
trabalhar mesmo desconectado?

Segurana e privacidade: p. ex. Usurios ou funcionrios de
uma instalao podem tentar se conectar num modo no
supervisionado;
Usurios podem ser espionados a medida que se movem por
vrias redes;
Usurios podem acessar suas redes caseiras, o que pode tornar
esses ambientes suscetveis a ataques dados mantidos por um
firewall podem ser interceptados quando o usurio acessa-os.

15 SD Cap. 1-4 15 SD Cap. 1-4
Descobrir servios: ao se conectar com uma rede, o dispositivo
mvel deve identificar os recursos disponveis (ex.: impressoras,
fax, TVs, etc.)
No se pode esperar que os protocolos de todos os recursos
sejam compatveis;
Deve haver meios de descobrir os recursos disponveis e obter
dados sobre eles;
Quando so usurios quiserem, podero fazer requisies sobre
esses recursos;

Um servio de descoberta tem 2 interfaces:
Servio de registro: aceita registros dos servidores e mantm
bancos de dados sobre os recursos disponveis;
Servio de lookup (pesquisa): aceita requisies dos usurios e
o BD por servios que possam atend-las;

Ex.: usurio em um hotel com figuras numa cmera digital que
deseja ver como elas saram.

2.2.4 Interfaces e Objetos

Definies de interface: conjunto de funes disponveis para
invocao em um processo (servidor, peer, etc.). Ex.: C++, Java, etc.
Linguagens orientadas a objetos podem encapsular objetos com uma
interface definida. Os mtodos desses objetos podem ser invocados
remotamente. Ex.: CORBA, RMI, etc.



2.2.5 Requisitos de projeto para arquiteturas
distribudas

Compartilhamento de recursos foi lanado nos anos 60, com o
sistemas timesharing. Ex. Sistemas operacionais multiusurios
(Unix) ou sistemas de banco de dados multiusurios (Oracle).
O surgimento de processadores baratos e de alto desempenho tirou o
controle dos recursos de mquinas de grande capacidade passou-os
para qualquer mquina da rede.
A necessidade de compartilhamento de recursos fsicos
(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 atualizao.

Questes de desempenho

Derivado do uso de mquinas e linhas de comunicao limitadas,
aparecem 3 principais elementos:

Tempo de resposta: o acesso a recursos remotos leva a atrasos
considerveis nas respostas a requisies do usurio;
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 pginas acessadas do cache so rpidas; pginas
s de texto mesmo remotas so rpidas; pginas com dados grandes
acessadas remotamente so lentas.
16 SD Cap. 1-4 16 SD Cap. 1-4
Throughput: taxa de realizao de trabalho computacional.
Num SD a habilidade de realizar trabalho para todos os seus
usurios. Valor afetado pela velocidade de clientes e servidores e
pelas taxas de transferncia.
Considere dados localizados num servidor remoto:
o Os dados precisam passar do processo servidor para o
processo cliente;
o Nesse processo, eles atravessam vrias 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 aplicaes e outros processos processem
concorrentemente sem competio por recursos.
P. ex.: rodar applets nos clientes permite ao servidor prestar um
servio melhor;
Ex.: vrios computadores para manter um s servio. O DNS
tem um recurso de lookup que devolve s um deles na pesquisa
de um domnio;
Algumas vezes, preciso mover um servio parcialmente feito
para ajustar a carga de um sistema.

Qualidade de servio

Uma vez que um SD tenha o servio que o usurio precisa, preciso
verificar sua qualidade.
Propriedades que afetam a qualidade:
Confiabilidade, segurana e desempenho.

Recursos reconhecidos a pouco tempo como muito importantes para
a qualidade:
Adaptabilidade: para se adequar a mudanas;
Disponibilidade de recursos.

Aspectos de desempenho em QoS at pouco tempo eram tratados
como tempo de resposta e throughput.
Recentemente se considera que so as garantias de se respeitar
limites de tempo.
Algumas aplicaes trabalham com dados de tempo crtico - cadeias
que precisam ser processadas entre processos a uma taxa fixa. Ex.:
vdeo.
QoS considerado hoje como a capacidade de atender deadlines.
Alcanar 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 satisfatrias 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 crticos devem ser reservados
para as aplicaes que precisam de QoS. Gerentes de recursos
devem dar garantias. Requisies de reserva que n\o podem ser
atendidas so descartadas.

Uso de cache e replicao

As questes de desempenho citadas podem parecer obstculos para a
construo de SDs.
17 SD Cap. 1-4 17 SD Cap. 1-4
Na prtica, h tcnicas bastante pesquisadas como replicao de
dados e cache.
Vimos antes caches e proxies, sem discutir como as cpias de
recursos so atualizadas quando o original atualizado em um
servidor.
Diferentes aplicaes podem usar diferentes protocolos de cache.

Protocolo Web-caching (HTTP): proxies e web servers
respondem da mesma forma a requisies dos clientes. O
protocolo de consistncia do cache procura garantir que os dados
entregues ao cliente sero "frescos". Mas para garantir
desempenho, disponibilidade e operao offline essa condio
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 no avisa navegadores
e proxies - para isso, seria necessrio manter uma relao 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 mdia de atualizaes registradas).
Esse recurso pode ser enganoso (dados na Web podem ser
atualizados a qualquer momento).

Os servidores anexam s pginas fornecidas um timestamp de
validade e a hora no servidor.
Navegadores podem saber quando um objeto do cache est para se
tornar invlido quando sua idade (soma do momento em que o
objeto foi colocado no cahe + tempo no servidor) se aproximar do
momento em que a entrada vai expirar.
Esse clculo no depende que os relgios do servidor, do cliente e
do proxy concordem entre si.

Dependncia

Dependncia um alto grau de necessidade dos usurios em relao
a um servio.
Dependncia relacionado com correo, segurana e tolerncia a
falhas.
O desenvolvimento de tcnicas para garantir a correo de
programas distribudos alvo de vrias pesquisas recentes. H
alguns resultados promissores, mas nenhum maduro o suficiente.

Tolerncia a falhas: aplicaes que geram dependncia devem
continuar funcionando mesmo na presena de falhas.
Confiabilidade alcanada atravs de redundncia. Isso caro e
h limites para o grau de redundncia possvel. Portanto, h
limites para o grau de tolerncia a falhas de um sistema.
Uma aplicao crtica (ex. Controle de trfego areo) necessita
de alto grau de tolerncia a falhas, que leva a um alto custo para
manter rplicas de dados atualizadas.

Segurana: dados e servios crticos s devem residir em
computadores a prova de ataques.
Ex.: o BD de um hospital contm dados que s devem ser vistos
por poucos mdicos. Outros dados podem ser vistos por grupos
maiores.
18 SD Cap. 1-4 18 SD Cap. 1-4
Assim, no possvel fazer um sistema que carregue fichas de
pacientes em notebooks porque eles so inseguros por natureza.

2.3 Modelos Fundamentais

Um modelo contm os elementos mnimos para entender e
raciocinar sobre os elementos essenciais de um sistema. Questes
principais:
Quais so as principais entidades do sistema?
Como elas interagem?
Que caractersiticas afetam seu comportamento individual e
coletivo?

Finalidade de um modelo:
Tornar explcitas todas as suposies relevantes do sistema
modelado.
Generalizar o que possvel ou no em geral, tomam a forma de
algoritmos de finalidade geral ou regras (propriedades
desejveis) garantidos. As garantias so dadas por anlise lgica
ou prova matemtica.

Aspectos de SDs dos modelos fundamentais:
Interao: processos interagem por mensagens e coordenao; o
modelo de interao deve tratar dos atrasos inerentes
comunicao; tambm deve considerar a preciso com que um
grupo de processos pode se sincronizar depende dos atrasos e
da manuteno de noo de tempo entre todos os computadores;
Falhas: definio dos tipos e classificao das falhas fornece
uma base para a anlise das falhas e o projeto do tratamento de
cada tipo;
Segurana: a natureza modular e abertura dos SDs expem-os a
ataques externos e internos. O modelo de segurana define e
classifica as formas de ataque, permite anlise de ameaas e o
projeto de mtodos de resistncia.

2.3.1 Modelo de Interao

Um programa simples controlado por um algoritmo sequencial,
cujos passos so realizados numa cadncia conhecida. O algoritmo
no interfere nem sofre interferncias externas. Ele tambm define
os contedos das variveis e os estados dos programas em um dado
momento.
SDs so constitudos de mltiplos processos. Seu comportamento
pode ser descrito por um algoritmo distribudo: uma definio de
passos + transmisso de mensagens entre os processos.
As mensagens so usadas para transferir informaes e para
coordenar as atividades.
Elementos difceis 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 interao de processos num
SD.

19 SD Cap. 1-4 19 SD Cap. 1-4
Desempenho dos canais de comunicao

Latncia: o atraso entre a transmisso e recepo 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 servios de comunicao dos SOs origem e
destino.
Banda: capacidade de transmisso total em um certo momento;
Jitter: variao de tempo para entregar uma srie de mensagens
- importante em multimdia, onde a diferena nos tempos de
entrega pode causar distores.

Relgios e medio de tempo

Cada computador possui seu relgio. Os processos locais usam-no
para medir o tempo dos eventos locais.
Relgios possuem diferenas em relao ao tempo real.
A taxa de diferena mede a relao entre o relgio local e um
relgio perfeito.
Acertando todos os relgios de um SD ao mesmo tempo, aps um
certo perodo pode-se ter variaes significativas.

Duas variantes do modelo de interao

difcil impor limites de tempo para:
Execuo de um processo;
Trnsito de uma msg;
Taxa de variao de um relgio.
Duas abordagens diferentes em relao ao tempo:
Forte suposio;
Nenhuma suposio.

SDs sncronos definem os seguintes limites (inferiores e superiores):
Tempo para realizar um passo;
Tempo para transmitir uma msg;
Taxa de variao do relgio local.

possvel sugerir valores, mas difcil dar garantias sobre eles. Um
SD sncrono tem a vantagem de permitir modelagem, que pode ser
til para verificar seu funcionamento. Pode-se usar timeouts, p. ex.,
para determinar falhas em servios.

SDs assncronos so aqueles que no podem ser qualificados como
sncronos (ex. Internet).
No possui limites:
Processos podem demorar longos tempos arbitrrios;
Mensagens podem ser recebidas aps longos tempos arbitrrios;
A taxa de variao dos relgios tambm arbitrria.
Na Internet, um email pode levar dias ou segundos. A transferncia
de um arq. por FTP pode ser rpida, demorada ou invivel.
O problema dos exrcitos azul e vermelho assume mais um grau de
dificuldade, caso o sistema seja assncrono.
Alguns problemas de projeto podem ser resolvidos mesmo nesse
caso. Ex. a Web no possui limites para tempos de resposta, mas os
navegadores podem permitir ao usurio outras atividades enquanto
espera.
Solues vlidas para SDs assncronos tambm so vlidas para SDs
sncronos.
20 SD Cap. 1-4 20 SD Cap. 1-4
Ordenao de eventos

H interesses em saber se um evento ocorre antes, depois ou
concorrentemente em relao a outro evento em outro processo.
P. ex.: considere a seguinte situao
Em um newsgroup, X envia uma mensagem Matter;
Y l a msg de X e responde com Re: Matter;
Z l as 2 msgs e responde com Re: Matter.
O resultado pode ser:
Item Origem Assunto
23 Z Re: Matter
24 X Matter
25 Y Re: Matter

Para resolver o problema, preciso 3 coisas:
Sincronizar todos os relgios envolvidos;
Enviar o timestamp junto com a msg;
Classificar as msgs pelo timestamp.

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.

Falhas por Omisso

Processos ou canais falham por no realizar o que se esperava que
fizessem.

Processos: principal ocorrncia o crash. Nesse caso, o processo
pra e no realiza mais sua tarefa. O projeto de um servio
tolerante a falhas simplificado se os servios de que ele
depende falham de forma limpa (ou funciona ou pra).
Um processo falha em crash se outros processos podem
determinar que isso aconteceu.

Comunicao:






Buffer de transmisso Buffer de recepo

O canal de comunicao produz uma falha por omisso se:
No ocorre o transporte entre os buffers de transmisso e
recepo (ex. falta de espao em buffer);
Erro de transmisso (detectado por checksums).

As falhas podem ser classificadas por sua severidade. Todos os tipos
de falhas apontadas aqui so falhas benignas (no causam
interrupes srias no sistema).

Send m Receive
21 SD Cap. 1-4 21 SD Cap. 1-4
Falhas arbitrrias

O termo arbitrrio (ou Bizantino) descreve o pior tipo de falha
possvel, onde um processo no pra (no h crash) mas pode alterar
seus dados com valores errados, ou dar respostas erradas.
Nesse caso, o processamento de uma requisio ocorre com uma
sequncia de passos equivocada.
Canais de comunicao so especialmente sujeitos a esse tipo de
falha:
O contedo de uma mensagem pode ser corrompido;
Mensagens no 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, nmeros de sequncia, etc.).

Falhas de tempo

Ocorrem em SDs sncronos (tempo de execuo de processos,
entrega de msgs, diferena entre relgios).
Num SD assncrono, um servidor pode responder muito lentamente,
mas no se pode falar em falhas de tempo j que no h garantias.

Mascarando falhas

Componentes de SDs so construdos a partir de conjuntos de outros
componentes.
possvel construir servios confiveis a partir de elementos que
apresentam falhas.
As caractersticas das falhas permitem desenhar servios que
mascaram falhas em componentes dos quais o servio depende.
Formas de mascarar falhas:
O servio esconde sua ocorrncia;
A falha convertida em um tipo + aceitvel.
Ex. Checksums mascaram msgs corrompidas uma falha arbitrria
convertida em falha por omisso.
Crashes de processos podem ser mascarados o processo
substitudo e seu estado restaurado a partir de dados armazenados
pelos predecessores.

Confiabilidade da comunicao 1-para-1

Canais apresentam falhas por omisso, mas podem ser usados para
construir servios que mascaram essas falhas.
Uma comunicao confivel se ela apresentar:
Validade: uma msg colocada no buffer de transmisso sempre
entregue no buffer de recepo;
Integridade: a msg recebida idntica enviada; msgs no so
enviadas + de 1 vez; msgs no enviadas no so entregues.

22 SD Cap. 1-4 22 SD Cap. 1-4
2.3.3 Modelo de segurana

Proteo de objetos









Na figura, um servidor manipula um conjunto de objetos.
Os usurios executam programas clientes para acessar esses objetos.
Os servidores recebem invocaes e devolvem respostas.
Para cada usurio, o servidor verifica os direitos de acesso antes de
dar acesso aos objetos.
Usurios diferentes podem usar os objetos de formas diferentes.
Ex.: um objeto que contm uma caixa postal
So dados privados pertencentes a algum;
S o dono pode ver e/ou alterar esse objeto.

Ex.: pginas Web
Alguns usurios s podem ler essas pginas;
O dono pode alterar seu contedo.

Os principais devem ser identificados e associados com um conjunto
de direitos de acesso.
O servidor deve identificar o principal que acessa seus objetos e
conceder direitos de acesso. As operaes devem ser verificadas. Se
estiverem fora dos direitos concedidos, devem ser negadas.
O cliente deve identificar o servidor para garantir que as respostas
vm de um principal autntico.

Protegendo processos e suas interaes

Processos interagem pelo envio de mensagens.
Mensagens ficam expostas a ataques enquanto trafegam pela rede.
Os servios em que so baseadas so abertos e suas interfaces
publicadas.
Assim, algum pode enviar mensagens a um principal tentando se
passar por outro.

O inimigo







Para modelar os ataques possveis, identifica-se um inimigo. Ele
pode enviar qualquer mensagem para qualquer processo, pode ler
e/ou copiar mensagens trocadas entre os processos.
Os ataques podem vir de um computador conectado rede, que roda
um programa que l msgs endereadas a outros processos, ou um
programa que gera msgs fazendo falsas requisies como se fosse
um usurio autorizado.
Network
invocation
result
Client
Server
Principal (user) Principal (server)
Object
Access rights
Communication channel
Copy
of
m
Process p
Process
q m
The
enemy
m
23 SD Cap. 1-4 23 SD Cap. 1-4
Ameaa aos processos: processos podem receber msgs da rede e
talvez no consigam identificar o emissor.
o Servidores: da mesma forma, processo podem enviar
msgs a um servidor, que pode no identificar o emissor.
Pode-se exigir que o emissor acrescente uma identidade
requisio, mas ela tambm pode ser falsificada.
o Clientes: um servidor que um cliente acessa pode ser
falso. Assim difcil determinar se a resposta vem de um
servidor legal ou de um que se faz passar por outro.
Ameaa aos canais de comunicao: o inimigo pode copiar,
alterar ou injetar msgs numa rede. Um ataque + sofisticado
copiar msgs e fazer replay delas + tarde.

Combatendo ameaas segurana

Criptografia e segredos compartilhados: considere que 2
processos compartilham um segredo (s os 2 sabem). Se numa
troca de mensagens esse segredo anexado, ento o outro lado
sabe que o processo que mandou a msg quem diz ser. Para
garantir que o segredo no se torne pblico, as msgs so trocadas
criptografadas;
Autenticao: o uso de segredos compartilhados e criptografia
a base para a autenticao, sistema de garantia de identidade de
um principal;
Canais seguros: criptografia e autenticao permitem construir
canais seguros no topo de um sistema de comunicao.
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
Cap. 3 FLIP (Fast Local Internet
Protocol)

H necessidades no atendidas por alguns protocolos (ex.: TCP/IP)
que precisam ser consideradas num SD. P. ex.:

Transparncia: as mensagens devem ser transmitidas para
processos (ou portas) em vez de nmeros IP.
Transparncia completa: a comunicao mantida mesmo
quando os processos (ou portas) migram entre os
computadores.
Segurana: numa rede, alguns componentes podem ser seguros
e outros no:
No seguros: criptografia.
Criptografia consome recursos no fazer nos componentes
seguros.
Gerncia de rede simplificada:
Redes grandes: computadores adicionados ou removidos
com freqncia.
Alocao automtica de novos endereos.

Esses elementos so difceis de alcanar em redes dispersas:
limitaes de desempenho;
mltiplos domnios administrativos.

FLIP: Tanenbaum:
protocolo para redes Ethernet interconectadas;
computadores com Amoeba.
Internet x FLIP

Camada

Aplicao
Sesso
Transporte
Internet
Protocolo
Internet
FTP, Telnet, SMTP
-
TCP, UDP
IP
FLIP

Definido pelo usurio
RPC, grupos
FLIP (tipo UDP)
FLIP

Caractersticas:

Servio no confivel de datagrama;
Base para protocolo RPC e multicast de grupo;
Fonte e destino = processos Amoeba;
Mensagens de 0 a 4GB (no precisa de transporte);
Nmero de porta nico em toda a rede.
Nmero no se altera com migrao.
Enderea grupos de portas.

Cada computador em uma rede FLIP conectado rede fsica por
meio de um FLIP Box:
Packet switch: transfere pacotes entre hosts e redes e de uma
rede para outra;
Usa tabelas de roteamento;
Essas tabelas variam dinamicamente medida que os
processos se movem entre os hosts;
A localizao de um identificador FLIP pode ser feita via
broadcast.
25 SD Cap. 1-4 25 SD Cap. 1-4
Interface com os hosts: para o envio e recepo de mensagens
unicast, multicast e broadcast;
Permite que processos se registrem (p. ex.: servidores) para a
recepo de mensagens;
Esse registro pode ser seguro, se necessrio funes de
criptografia one-way.
Interfaces de Rede: um host tem uma s; um roteador tem
vrias interfaces com redes diferentes.

Principais diferenas entre FLIP e protocolos Internet:
FLIP tem transparncia de localizao destinos independentes
de localizao;
Identificadores de portas gerados e alocados automaticamente
reduz a administrao;
Suporte comunicao de grupo;
Suporta comunicao segura apenas onde necessrio;
Objetivo: uso em grupos pequenos e confiveis de WANs e
LANs.


26 SD Cap. 1-4 26 SD Cap. 1-4
Cap. 4 IPC
4.3 Representao externa de dados e
marshalling

Mensagens:
Estruturas de dados mapeados em seqncia;
Integrao de diferentes tipos de dados;
Plataformas com representao interna diferente;
Converso para representao comum.
Computadores iguais podem omitir esse passo.

XDR (External Data Representation SUN)
RFC 1832
www.cdk3.net/ipc
Ex.: Smith, London, 1934

4 bytes
5
Smit
h---
6
Lond
on--
1934

Marshalling: operao de empacotar dados numa mensagem para
transmisso.

Ex.:
char * nome = Smith, * lugar = London;
int ano = 1934;

sprintf(msg, %d%s%d%s%d, strlen(nome), nome,
strlen(lugar), lugar, ano);
Para ser transmitida, uma estrutura precisa ser convertida em bytes
(serializada). Isso leva a problemas dependendo do tipo de dado.
P. ex.:
Reais: cada arquitetura tem uma forma de representao;
Cdigos de representao:
o Unix, IBM, Intel: ASCII;
o Unisys: EBCDIC;
o Macintosh: ASCII mixto;
o Windows 98/ME/2000/XP, Java: Unicode.
Inteiros:
o Big Endian: o bit + significativo vem 1
o
.;
o Little Endian: o bit + significativo vem por ltimo.

CORBA CDR

Representao externa definida no Corba 2.0.
Representa todos os tipos de dados que podem ser argumentos em
chamadas de funes.

15 tipos primitivos. Ex.:
short (16 bits), long (32 bits), unsigned short, unsigned long,
float (32 bits), double (64 bits), char, boolean (TRUE, FALSE),
octet (8 bits), any!
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
caracteres longos);
array: elementos em ordem (no possui tamanho);
struct: na ordem dos componentes;
enumerated: unsigned long;
union: tipo + membro.
O exemplo Smith, London, 1934 em XDR idntico em Corba
CDR.

Marshaling no Corba

Considere o exemplo Smith, London, 1934.
As operaes de marshalling so feitas automaticamente a partir da
definio IDL:

struct Person {
string name;
string place;
long year;
};

O compilador de interface do Corba gera as operaes de
marshalling e unmarshalling para os parmetros e resultados.

Serializao de objetos em Java

No Java RMI, objetos e dados primitivos podem ser passados como
argumentos e resultados de operaes.
Ex. Implementao do exemplo do IDL acima:


public class Person implements Serializable {
private String name;
private String place;
private int year;

public Person(String aName, String aPlace,
int aYear) {
name = aName;
place = aPlace;
year = aYear;
}
// outros metodos
}

A interface Serializable no possui mtodos, mas permite que
objetos instncias das classes que implementam-na sejam
serializados.
Isso significa transformar um objeto numa sequncia de bytes que
podem ser armazenados em disco ou enviados numa mensagem.
A operao de deserializao consiste em transformar uma
sequncia de bytes no objeto original.
O processo que recupera um objeto no tem informaes sobre ele.
Elas fazem parte da forma sequencial.

A serializao inclui todos os objetos referenciados. Isso permite
reconstruir o objeto orginal com todos os objetos que ele
referenciava.
Referncias a variveis que no devem ser serializadas devem ser
declaradas como transient (ex.: arquivos, sockets, etc.)

Reflection: informa o compilador que a classe de uma instncia no
conhecida. Ela ser conhecida durante a execuo. Isso permite a
28 SD Cap. 1-4 28 SD Cap. 1-4
serializao de uma forma totalmente genrica, sem conhecimento
prvio da classe usada.

Operaes Send e Receive

Send(destino, msg);
Receive(fonte, msg);

Para o receive, fonte pode ser ANY.

Comunicao sncrona e assncrona

A comunicao sncrona envolve o bloqueio do transmissor (send) e
do receptor (receive).
O bloqueio permanece at que o processo par realize a operao par
do processo bloqueado.
A comunicao assncrona bloqueia o processo apenas at que a msg
seja entregue biblioteca de comunicao (send). Mesmo nesse
caso, pode-se escolher entre receive bloqueante e no bloqueante.
Na forma no bloqueante, o processo continua sua execuo e h
alguma funo que indica se o buffer recebeu uma mnsg vlida.
Obs.: no Java (multithread) o bloqueio no tem importncia, pois
possvel fazer uma thread bloquear enquanto o restante da aplicao
continua.
A comunicao no bloqueante parece ser + vantajosa, mas a +
difcil de implementar, pois preciso carregar a msg no buffer do
processo sem que ele solicite. Por isso, alguns sistemas no
oferecem essa possibilidade.


Identificadores de destino independentes de localizao.
Na Internet:
Porta, nmero IP.

FLIP:
Destino mapeado para um endereo fsico pelos roteadores.

Comunicao confivel.

Problemas que podem ocorrer com mensagens:
Extravio;
Duplicao;
Entrega fora de ordem;
Atraso.

Um servio confivel pode ser construdo sobre um outro no
confivel pelo uso de acks de confirmao.
Cliente-servidor: ack positivo;
Grupos: ack negativo.

Overhead de um servio confivel:
1. Armazenamento de informao de estado em fonte e destino.
2. Retransmisso.
3. Latncia entre fonte e destino.

Identificadores de mensagens:
1. Request ID: nmero seqencial nico (ex.: 2**32).
2. Identificao 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
nmeros.

Destino de mensagens

Na Internet, msgs so enviadas para <Endereo IP, porta>. Uma
porta um processo destino num computador.
Uma porta tem no mximo um receptor. Mas pode ter vrios
transmissores.
Qualquer processo que saiba o nmero de uma porta pode enviar
msgs para ela.
Em geral, servidores publicam suas portas para os clientes.

Se um cliente usa um end. Internet para um servio, esse servio
deve rodar sempre no mesmo endereo (no permite mobilidade, no
transparente, etc.).

Para evitar isso:
Clientes se referem a servios pelo nome, e um servio de nomes
ou binder faz a traduo;
o Permite relocao, mas no migrao.
possvel ao SO usar endereos independentes de localizao,
fazendo seu mapeamento para endereos de baixo nvel;
o Permite relocao e migrao.

Alternativa: enderear msgs para processos em vez de portas (ex. V
System 1984).
Cada processo recebe um nmero nico para o sistema inteiro;
Portas permitem que um processo tenha vrios endereos para
receber msgs;
Portas permitem que 1 msg seja entregue a vrios processos em
mquinas diferentes;
Alguns sistemas permitem usar endereos de grupos de
processos.

Referncias a objetos remotos

Feito atravs de mensagens de invocao.
Especifica que objeto deve ter um de seus mtodos invocados.
Vlido dentro de um SD determinado.
Ex.:
Endereo IP (32 bits);
Porta (32 bits);
Hora (32 bits);
Nmero de objeto (32 bits);
Interface para o objeto remoto.

4.4 Comunicao cliente-servidor

Protocolos request-reply:
Cliente Servidor
DoOperation GetRequest

wait

processa

continua SendReply

DoOperation(Porta, Msg, Resposta);
30 SD Cap. 1-4 30 SD Cap. 1-4
Implementao:
Send(Porta, Msg);
Receive(Fonte, Resposta).
Timeout para falhas e retransmisso.

GetRequest(Porta, Msg);
SendReply(Porta_Cliente, Resposta);

Mensagem de um protocolo request-reply:

messageType int (0 = request, 1 = reply)
requestId Int identifica msg
objectReference RemoteObjectRef
methodId int ou mtodo
argumentos Array de bytes

Timeouts:
Indica que uma operao DoOperation falhou;
Pode ocorrer porque um reply ou request se perdeu;
o Em caso de reply, a operao foi feita;
Leva retransmisso at que chegue uma resposta ou que se
assuma que o servidor no vai responder.

Descartando mensagens duplicadas:
Com retransmisso, um servidor pode receber uma mensagem
mais de uma vez.
O servidor pode executar uma requisio num tempo maior do
que o timeout do cliente.
Controle de Identificao da mensagem.

Perda de respostas:
Operao reexecutada aps a repetio de uma requisio;
No h problemas caso a operao seja idempotente;

Histrico:
Para servidores no idempotentes;
Registro das respostas enviadas para cada requisio;
Custo de memria para manter as informaes;
Servidor deve saber quando descartar um registro;
Sistemas interativos: uma resposta a cada requisio se o
cliente retransmite, basta guardar a ltima resposta.

Protocolos RPC:
Request (R): no h resposta;
Request-Reply (RR): resposta = ACK;
Request-Reply-Acknowledge (RRA):
O cliente confirma que recebeu a resposta;
Um ACK confirma todos os anteriores.

Exemplo: protocolo HTTP
Clientes especificam uma URL (host + porta {opcional});
HTTP especifica as mensagens, mtodos, argumentos e
resultados;
H um conjunto fixo de mtodos (GET, PUT, POST, etc.).

Especificao de contedo: os clientes podem dizer ao servidor
que tipo de dados eles podem representar.
Autenticao: o servidor pode dar um reply solicitando user +
password, caso o cliente tente acessar uma rea protegida.
31 SD Cap. 1-4 31 SD Cap. 1-4
Navegadores podem usar conexes persistentes, j que o
estabelecimento de conexes a cada pedido muito custoso. Essas
conexes permanecem ativas mesmo entre vrias requisies.

4.5 Comunicao de Grupo

Mensagens multicast so teis para construir Sistemas Distribudos:
Tolerncia a falhas baseadas em servios replicados;
Descobrir servios em comunicao espontnea;
Melhor desempenho atravs de dados replicados;
Localizao de objetos controlados individualmente;
Desempenho: aps alterao, dados enviados para todos os
interessados;
Atualizao mltipla: ex.: usurios de uma lista;
Propagao de notificaes de eventos.

4.5.1 IP multicast uma implementao de
comunicao de grupos

Grupos multicast so especificados por endereos classe D (1os. 4
bits = 1110).
Membros de um grupo recebem pacotes IP endereados ao grupo.

A participao como membro dinmica.
S disponvel via protocolo UDP.


Detalhes especficos 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 distncia entre membros de um grupo.
Alocao de endereos: endereos multicast podem ser
permanentes ou temporrios. Grupos permanentes existem
mesmo sem nenhum membro. Esses endereos so da faixa
224.0.0.1 at 224.0.0.255.

Modelo de falhas para datagramas multicast

Datagramas de IP multicast tm os mesmos problemas de
datagramas UDP sofrem falhas por omisso.
No h garantias que um membro de um grupo receber uma
mensagem multicast no confivel.

4.5.2 Confiabilidade e ordenao de multicast

Um datagrama pode ser extraviado porque o buffer do destino
est cheio;
O extravio de um datagrama por um roteador evita a recepo da
msg por todas as mquinas depois dele;
Pacotes IP enviados por um internetwork no chegam
necessariamente na ordem em que foram enviados.



32 SD Cap. 1-4 32 SD Cap. 1-4
Atomicidade:
Caso 1: todos os servidores precisam receber:
Multicast atmico: todos recebem ou nenhum.
Multicast confivel: h um esforo para garantir a entrega,
mas no h garantias.

Ordenao
Operaes multicast atmicas e confiveis fornecem ordenao
FIFO. Neste tipo de ordenao, as mensagens entre3 clientes e
servidores so entregues na ordem de envio (possvel pelo uso de
nmeros de seqncia dentro das mensagens).
No caso 1, todos os servidores devem executar todas as requisies
na mesma ordem.
Sem um mecanismo de garantia da ordenao, as mensagens podem
chegar em ordem diferente dependendo do servidor. P. ex.: h
extravios e retransmisses.

P1 P2 P3 P4


A B
A
B
Tempo





Forma mais forte de ordenao: multicast totalmente ordenado.
Mensagens enviadas para um grupo via multicast totalmente
ordenado

Implementao de comunicao de grupos
Forma mais simples: multicast no confivel;
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 no confivel usa o Send
bsico;
Essa funo implica na existncia de um servio de controle de
grupos, do qual se obteve os nmeros de porta dos participantes.


Eficincia
Pode-se aumentar muito a eficincia de um multicast;
Ex.: em redes Ethernet, h formas de fazer broadcast para todos
os computadores de uma rede local;
Ethernet tambm admite enviar uma mensagem para vrios
computadores da rede (multicast);
Isso no resolve todos os problemas:
Pode haver mais de um processo em um n da rede;
Pode haver processos em redes locais diferentes, conectadas
entre si.
33 SD Cap. 1-4 33 SD Cap. 1-4
Um sistema multicast de fato deve enviar mensagens para todos
os processos de um grupo, independente de sua localizao.

Confiabilidade
Razes para que uma mensagem no alcance todos os membros
de um grupo:
Extravio, caso as mensagens sejam enviadas uma a uma;
Quem envia pode falhar aps enviar para alguns dos
participantes.

Nenhum desses motivos aceitvel para aplicaes com
multicast atmico ou totalmente ordenado.

Monitoramento
Faz parte do servio 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 no
responda;
Aps um certo nmero de tentativas, o processo que no
responde descartado do grupo;
Mensagens de processos removidos so descartadas;
Essencial para protocolos de multicast atmico.

Multicast atmico e confivel
Forma de implementar um multicast confivel:
O transmissor envia mesma mensagem para todos os
componentes do grupo;
Aguarda um ack de todos os processos;
Quando todos os acks chegarem, o transmissor tem certeza
de que todos os processos receberam.
Se um ack no recebido at um timeout, a mensagem
retransmitida;
Aps um nmero de retransmisses, assume-se que o membro do
grupo falhou ele removido.

Pode ser que o transmissor falhe aps 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 requisio confirma que a anterior
foi bem sucedida.

Este protocolo tem um desempenho ruim, mesmo num meio que no
apresente falhas.
H duas formas de se aumentar o desempenho desse tipo de
comunicao.

Hold-back

O elemento que controla a comunicao retm a ltima
mensagem at garantir que os requisitos de atomicidade e
ordenao foram satisfeitos.
34 SD Cap. 1-4 34 SD Cap. 1-4
Ack negativo

Reduz o nmero de mensagens trocadas entre os pares;
Cada transmissor mantm um contador do nmero de mensagens
enviadas;
Esse contador acrescentado a todas as mensagens;
Os receptores controlam se receberam todas as mensagens
enviadas;
Se alguma delas no foi recebida, o receptor envia um ack
negativo comunicando este fato ao transmissor;

Neste caso, no h acks de confirmao;
Obriga o transmissor a manter um histrico das mensagens
transmitidas;
Se o transmissor falha e outro processo o substitui, esse histrico
deve estar disponvel;
Deve haver um mtodo que evite o histrico de ficar muito
grande;
Uma forma usar eventuais acks de confirmao piggybacked
em outras mensagens at aquele nmero, o transmissor pode
descartar o histrico.

Alguns exemplos dos efeitos da confiabilidade e ordenao

1 Tolerncia a falhas baseado em servios replicados:
Um servio replicado deve iniciar com todos os membros no
mesmo estado.
Todas as operaes devem ser feitas por todos os membros, na
mesma ordem.

2 Encontrando os servios em computao espontnea:
Processos que querem descobrir servios disponveis fazem
multicast de requisies periodicamente. O extravio de uma
dessas msgs no aceitvel.

3 Melhor desempenho com dados replicados:
No caso de servios em que os dados so mantidos por msgs
multicast.
A perda de msgs pode levar quebra de ordenao.
O tipo de servio usado para multicast depende da necessidade
de exatido em todas as rplicas.

4 Propagao de notificao de eventos:
Ex.: novos servios podem ser informados por msgs multicast
peridicas.