1 SD Cap. 1-4 Coulouris (ed. 2): Compartilhamento de recursos; Abertura; Concorrncia; Independncia de escala; Tolerncia a falhas; Transparncia.

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

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.

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 1os 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:

2 SD Cap. 1-4 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 clienteservidor 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.

2 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.

3 SD Cap. 1-4

3 SD Cap. 1-4

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; 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

4 SD Cap. 1-4 ser renovado em perodos fixos). Isso obriga o usurio a fazer refresh de uma pgina se quiser ver se ela foi atualizada; 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.

4 SD Cap. 1-4 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. 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.

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.

5 SD Cap. 1-4 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 12/1979 07/1989 07/1999 Computadores 188 130.000 56.218.000 Servidores WWW 0 0 5.560.866

5 SD Cap. 1-4

Ex.: nmero de computadores e servidores WWW na histria da Web (1993 a 1999) Data 07/1993 07/1995 07/1997 07/1999 Computadores 1.776.000 6.642.000 19.540.000 56.218.000 Servidores WWW 130 23.500 1.203.096 6.598.697 % 0,008 0,4 6 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

6 SD Cap. 1-4 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.

6 SD Cap. 1-4 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.

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 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

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;

7 SD Cap. 1-4 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. Negao de servio.

7 SD Cap. 1-4

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.

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;

2.2.1 Camadas de software

Aplicaes, servios Middleware Sistema operacional Plataforma Hardware e rede Middleware: Camada de software que mascara a heterogeneidade de um sistema; Fornece um modelo para os programadores;

8 SD Cap. 1-4 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. Modelo cliente-servidor

8 SD Cap. 1-4

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.

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); Servios com mltiplos servidores Serv Clien t

2.2.2 Arquiteturas de sistemas

Serv 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. Cliente Server Clien t Serv

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

Cliente

Server

9 SD Cap. 1-4

9 SD Cap. 1-4

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. Cliente Proxy Cliente Aplicao Processos pares (peer) Cdigo de Cdigo de Processos que so similares e desempenham os mesmos papis. Interagem coordenao coordenao de forma cooperativa para realizar atividades distribudas, sem distino entre clientes e servidores. Web Serv

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.

Web AplicaoServ

Cdigo mvel Ex.: a)

Cliente

Applet

Web Server

Aplicao b) Cdigo de coordenao

10 SD Cap. 1-4 Cliente Web Server Applet 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.

10 SD Cap. 1-4 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.

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:

11 SD Cap. 1-4 Implementaes: X11 (sistema de janelas), WinFrame da Citrix, VNC da AT&T.

11 SD Cap. 1-4 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.

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:

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. 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;

12 SD Cap. 1-4 Ex.: usurio em um hotel com figuras numa cmera digital que deseja ver como elas saram.

12 SD Cap. 1-4 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. 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.

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;

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:

13 SD Cap. 1-4 Adaptabilidade: para se adequar a mudanas; Disponibilidade de recursos.

13 SD Cap. 1-4 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).

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. 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.

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.

14 SD Cap. 1-4 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. Assim, no possvel fazer um sistema que carregue fichas de pacientes em notebooks porque eles so inseguros por natureza.

14 SD Cap. 1-4 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. 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.

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;

15 SD Cap. 1-4

15 SD Cap. 1-4 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. 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.

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;

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.

16 SD Cap. 1-4

16 SD Cap. 1-4 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 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: Send m Receive

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.

Buffer de transmisso

Buffer de recepo

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.

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).

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.

17 SD Cap. 1-4

17 SD Cap. 1-4

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.

18 SD Cap. 1-4

18 SD Cap. 1-4 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.
Object

2.3.3 Modelo de segurana

Proteo de objetos
Access rights invocation Client result

O inimigo
Copy of m
Server

The enemy
Network Principal (server)

m Proces

Principal (user)

Process p

m Communication channel

sq

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

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. 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

19 SD Cap. 1-4 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.

19 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

20 SD Cap. 1-4

20 SD Cap. 1-4 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.

Camada
Aplicao Sesso Transporte Internet Caractersticas:

Protocolo Internet
FTP, Telnet, SMTP TCP, UDP IP

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

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. 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.

21 SD Cap. 1-4

21 SD Cap. 1-4 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 1o.; 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; 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.

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);

22 SD Cap. 1-4 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.

22 SD Cap. 1-4 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 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.

23 SD Cap. 1-4 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; 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.

23 SD Cap. 1-4 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);

24 SD Cap. 1-4 Interface para o objeto remoto.

24 SD Cap. 1-4 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.

4.4 Comunicao cliente-servidor Protocolos request-reply: Cliente Servidor DoOperation GetRequest wait continua processa SendReply

DoOperation(Porta, Msg, Resposta); 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 requestId objectReference methodId argumentos int (0 = request, 1 = reply) Int identifica msg RemoteObjectRef int ou mtodo 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.

25 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.

25 SD Cap. 1-4 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.

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.

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.

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.

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.

26 SD Cap. 1-4 Sem um mecanismo de garantia da ordenao, as mensagens podem chegar em ordem diferente dependendo do servidor. P. ex.: h extravios e retransmisses. P1 A A B Tempo P2 P3 B P4

26 SD Cap. 1-4 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. Um sistema multicast de fato deve enviar mensagens para todos os processos de um grupo, independente de sua localizao.

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.

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;

Eficincia Pode-se aumentar muito a eficincia de um multicast;

27 SD Cap. 1-4 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.

27 SD Cap. 1-4 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.

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. 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;

28 SD Cap. 1-4

28 SD Cap. 1-4