1 SD Cap. 1-4
1 SD Cap. 1-4
•
Cap. 1 – Caracterização Definições: •
•
•
•
Tanenbaum: “Nós usamos o termo Sistema Distribuído com
o sentido de um Sistema Operacional Distribuído”; Mullender : “Um SD é um sistema com vários EPs e vários dispositivos de armazenamento, conectados entre si por uma rede”; Lamport : “Um SD é aquele que não permite que você produza qualquer qualquer tipo de trabalho quando quando ocorre uma pane numa máquina que você nem sabia que existia”; Coulouris: “Um SD consiste de um conjunto de computadores autônomos conectados conectados por uma rede, cada um deles equipado com um Software de SD.
Uma característica importante (ou que pode ser importante no futuro) pode ser esquecida.
Schroeder: Avaliação de um candidato a SD através de sintomas: o Vários EPs; o Hardware de interconexão; o Os EPs falham independentemente; independentemente; o Estado do sistema compartilhado. •
Coulouris (ed. 2): Compartilhamento de recursos; Abertura; Concorrência; Independência de escala; Tolerância a falhas; Transparência. • • • • •
Definições mais recentes: Tanenbaum: “Um SOD é aquele que, para seus usuários, parece um SO centralizado, mas executa sobre múltiplas CPUs independentes. O conceito chave aqui é transparência , ou seja, os múltiplos processadores utilizados devem ser invisíveis (transparentes) para o usuário. Outra forma de expressar a mesma idéia é dizer que o usuário enxerga o sistema como um ‘processador ‘ processador virtual único’, e não como um conjunto de máquinas distintas”; •
Mullender: Definir exatamente um SD é perigoso; •
•
Coulouris (ed. 3): Heterogeneidade; Abertura; Segurança; Independência de escala; Tratamento de falhas; Concorrência; Transparência. • • • • • • •
5 SD Cap. 1-4
•
•
Sites com anúncios obrigam os navegadores a buscar sempre a última versão em vez de usar o cache; Páginas não são um meio apropriado para representar todas as informações. Isso levou ao uso de applets e muitas imagens para tornar a interface mais aceitável. Também gasta mais tempo para fazer um download completo.
Características principais
1 - Heterogeneidade Aplica-se a redes, computadores, sistemas operacionais, linguagens de programação e implementações de diferentes desenvolvedores. A Internet é composta de vários tipos de redes diferentes, mas todas implementam o Protocolo IP; Plataformas diferentes podem ter representações diferentes de inteiros, reais, etc. Apesar da necessidade de toda máquina ligada à Internet ter uma implementação do IP, os SOs não possuem a mesma interface (chamadas). Linguagens diferentes possuem diferentes formas de representar dados. Isso deve ser considerado se elas devem se comunicar umas com as outras; Programas escritos por desenvolvedores diferentes não se comunicam, a menos que usem padrões comuns (comunicação, dados, estruturas, passagem de parâmetros, etc.). •
•
•
•
•
Middleware
5 SD Cap. 1-4
Camadas de software que fornecem abstrações de programação e mascaram a heterogeneidade dos elementos abaixo. Ex.: CORBA. Alguns middlewares suportam apenas uma linguagem (ex. Java RMI). Todos são implementados sobre o IP - mascaram diferenças entre as redes. Todos precisam tratar diferenças de SOs e hardware. Para resolver os problemas de heterogeneidade, os middlewares fornecem modelos computacionais uniformes para os programadores. Possíveis modelos incluem: Invocação remota de objetos; Notificação remota de eventos; Acesso remoto com SQL; Transações distribuídas. • • • •
Heterogeneidade e código móvel
Código móvel: código que pode ser enviado de um computador para outro e rodar no destino. Ex.: applets Java. O código depende do tipo de arquitetura de origem. A abordagem com máquinas virtuais permite fazer código executável em qualquer plataforma. Ex.: um compilador Java produz código para a JVM, que pode rodar em qualquer plataforma com JVM implementada. Esta solução não é aplicável a todas as linguagens. Ex.: não existe uma VM para C.
6 SD Cap. 1-4
2 - Abertura Determina se um sistema pode ser estendido e implementado de várias formas. Grau com que novos serviços de recursos compartilhados podem ser inseridos. Não pode ser alcançada sem tornar públicas as documentações das interfaces dos principais softwares do sistema. Palavra chave = publicação! Grande desafio para os projetistas de um sistema (distribuído) = juntar componentes desenvolvidos por diferentes pessoas. Ex. sistema de publicação da Internet = RFCs (Request for Comments). Inclui discussões e padronização de protocolos. Ex.: CORBA. Série de documentos técnicos separados por área, incluindo especificações completas das interfaces dos serviços. Abertura em relação ao hardware: permite a adição de computadores na rede. Ao software: permite a introdução de novos serviços e a reimplementação dos velhos. Em qualquer caso, permite a independência em relação aos vendedores. 3 - Segurança O tipo de serviço prestado por um sistema distribuído provavelmente é alto valor intrínsico. Sua segurança é de grande importância. A segurança de recursos de informação tem 3 componentes: Confidencialidade: proteção contra acesso não autorizado; •
6 SD Cap. 1-4
• •
Integridade : proteção contra estragos; Disponibilidade : proteção contra interferências no seu
funcionamento. Toda a comunicação em um SD ocorre sobre redes. O desafio é enviar informação sensível em mensagens de forma segura. Outro problema é garantir a identidade de quem recebe e de quem envia alguma coisa. Problemas atualmente não completamente resolvidos: Ataques de negação de serviço : atualmente a ação possível é procurar os responsáveis depois que um ataque ocorre. Segurança de código móvel : garantias para quem recebe e para quem envia. •
•
4 - Independência de Escala Um SD deve operar de forma eficiente independente da escala, desde uma pequena intranet até a Internet. Um sistema é escalável se continuar efetivo após um incremento significativo de recursos e usuários. Ex.: Internet de 1979 a 1999 Data
Computadores
Servidores WWW
12/1979 07/1989 07/1999
188 130.000 56.218.000
0 0 5.560.866
Ex.: número de computadores e servidores WWW na história da Web (1993 a 1999)
9 SD Cap. 1-4
9 SD Cap. 1-4
Cap. 2 - Modelos de Sistemas
2.2 Modelos arquiteturais
Um modelo de arquitetura define a forma como os componentes se relacionam entre si. Também define a forma como são mapeados numa rede de computadores.
Arquitetura de um sistema: sua estrutura em termos de especificação de componentes separados. Objetivo geral : garantir que a estrutura vai atender necessidades atuais e futuras Principais objetivos : fazer o sistema confiável, manuseável, adaptável e custo-efetivo. Simplificação inicial : classificação dos processos em clientes, servidores e pares.
Dificuldades e ameaças aos SDs : Grande variação nas formas de utilização : p. ex.: •
Variação de carga - algumas páginas são pouco acessadas enquanto outras recebem milhões de acessos por dia; Partes de um sistema podem estar desconectadas; Algumas aplicações precisam de grande largura de banda. Grande variação de ambientes : Há heterogeneidade de hardware, SO e redes; Redes sem fio operam a uma fração das LANs; Há diferenças de escala: sistemas com dezenas de computadores até milhões. •
• • •
• • •
•
Problemas internos: • • •
•
Relógios não sincronizados; Atualizações conflitantes; Muitas formas de falhas de hardware e software envolvendo componentes do sistema.
Ameaças externas: • •
Ataques à integridade de dados e ao sigilo; Negação de serviço.
Variações do modelo cliente-servidor: Mobilidade de código de um processo p/ outro permite a delegação de tarefas. P. ex. clientes podem fazer download de código dos servidores para executá-los localmente; Códigos e objetos podem ser movidos para reduzir o tráfego; SDs podem ser projetados para permitir a adição e remoção de computadores e outros dispositivos móveis - podem descobrir os serviços disponíveis e oferecer serviços para outros. •
• •
2.2.1 Camadas de software Aplicações, serviços Middleware Sistema operacional Hardware e rede
Plataforma
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 construção de componentes de software que trabalham uns com os outros; Ultrapassa o nível de comunicação e permite abstrações como Invocação Remota, comunicação de grupos, notificação de eventos, replicação de dados, transmissão de multimídia em tempo real.
10 SD Cap. 1-4
2.2.2 Arquiteturas de sistemas Projeto de SD - aspectos + evidentes: Divisão de responsabilidades entre componentes (aplicações, servidores, etc.); Colocação de componentes em computadores da rede. Esses itens têm grandes implicações no desempenho, confiabilidade e segurança. •
•
Cliente
Limitações do middleware
Ex.: transferência de grande número de emails do servidor para o cliente. Aplicação TCP; Considere uma rede não confiável; TCP possui alguma detecção de erros e correção; Mas não há recuperação possível de erros graves ou interrupções; Nesse sentido, o serviço de email pode acrescentar tolerância a falhas através de um registro do trabalho já feito. •
Cliente
•
Server
Server
• •
•
O correto comportamento de um SD depende de verificações, correção de erros, medidas de segurança em vários níveis. É preciso acessar dados dentro do espaço de endereçamento das aplicações. Tentativas de realizar as verificações através dos sistemas de comunicação padrões garante apenas parte das necessidades de correção.
Modelo cliente-servidor
Historicamente o modelo mais conhecido e mais usado. Servidores podem ser clientes: Servidores WWW podem ser clientes do FS local; Também podem ser clientes do DNS; Um engenho de pesquisa é um cliente (dos sites que visita) e um servidor (dos usuários que pedem pesquisas); • • •
11 SD Cap. 1-4
11 SD Cap. 1-4
Serviços com múltiplos servidores
Serv Client
Ao precisar de um objeto, o cache é consultado primeiro. Se houver uma versão atualizada, ela é usada. Se não, é feita uma solicitação do objeto ao seu servidor. Caches podem ser residentes em cada cliente ou residir em um proxy, sendo compartilhados por todos. Caches são bastante utilizados: Navegadores possuem caches das páginas recentemente visitadas – uma função especial do protocolo HTTP permite verificar se as páginas estão atualizadas; Servidores proxy fornecem páginas já acessadas aos clientes de uma rede – finalidade é aumentar o desempenho – podem ser usados para outras finalidades. Ex.: acessar sites através de um firewall. •
Serv Client
•
Serv
Cliente Os servidores podem dividir o conjunto de dados. Também podem manter cópias replicadas. Replicação aumenta o desempenho, a disponibilidade e a tolerância a falhas.
Servidores proxy e cache Um cache é um armazém de objetos mais usados mais perto que os objetos originais. Ao receber um objeto, ele é adicionado ao cache, eventualmente substituindo um mais velho.
Web Serv Proxy
Cliente
Web Serv
Processos pares (peer)
Processos que são similares e desempenham os mesmos papéis. Interagem de forma cooperativa para realizar atividades distribuídas, sem distinção entre clientes e servidores.
12 SD Cap. 1-4
12 SD Cap. 1-4
Aplicação
Aplicação
Código de coordenação
Código de coordenação
Código móvel
Ex.: a)
Cliente
Applet
Web Server
b) Cliente
Aplicação
Web Server Applet
Código de coordenação A não existência de um servidor torna a comunicação mais demorada, já que há atrasos consideráveis caso se precise procurar algo por todos os processos.
Vantagem: Não há atrasos na rede, não gasta banda. Apesar da padronização, algumas aplicações apresentam funcionamento incomum. P. ex.: um broker: O cliente faz download de um código para acompanhar o valor das ações; O servidor mantém os valores e informa periodicamente o código das mudanças - push - não é o cliente que pede, mas o servidor que comunica os dados. •
•
2.2.3 Variações no modelo cliente-servidor Novas situações: Uso de código móvel e agentes móveis; Necessidade de computadores de baixo custo; Necessidade de adicionar e remover dispositivos móveis. • • •
Um código móvel é uma ameaça potencial à segurança dos recursos locais de um sistema. Por isso, navegadores dão acesso limitado aos applets baixados da Internet.
13 SD Cap. 1-4
Agentes móveis
13 SD Cap. 1-4
A proposta de um NC possui os seguintes objetivos: Sistema operacional e aplicações são baixados de um servidor remoto; Aplicações executam localmente, mas os arquivos são acessados remotamente; Como todos os arquivos são acessados em um servidor, os usuários podem mudar de computador sem problemas; Processador e memória podem ser limitados para reduzir custos; Se o NC tem um disco, ele é usado para manter um mínimo de software; A maior parte dele é usada como cache para os arquivos mais recentes; Os objetos mantidos no cache são invalidados quando atualizados no servidor principal. •
Processo (código + dados) que viaja de máquina para máquina numa rede para executar uma tarefa para alguém. Ex.: coletar dados, retornando com o resultado. Podem invocar recursos locais (ex. Bancos de dados), eventualmente acessando grandes conjuntos de dados. Com isso, economizam banda de rede porque o acesso é local, com melhor tempo de resposta. Agentes móveis são uma ameaça potencial aos recursos das máquinas que visitam. O ambiente local deve decidir: A identidade do emissor do agente; Que privilégios dar ao agente que chega; Que recursos ele pode acessar. Os próprios agentes são vulneráveis: Podem ser atacados nos hosts em que chegam; Talvez não possam realizar sua tarefa se não puderem acessar os recursos de que precisam. A tarefa de um agente móvel pode ser realizada por outros meios: Ex.: invocação remota. Assim, sua aplicação ainda é restrita. •
• •
•
•
• •
•
•
•
Thin Clients
• •
•
Network Computers
Um computador típico possui: Sistema operacional; Aplicações instaladas conforme a necessidade do usuário; Pertence a uma plataforma determinada. • • •
Camada de software que suporta uma interface para o usuário local enquanto executa aplicações em computadores remotos. As aplicações rodam em computadores de grande capacidade, multiprocessadores ou clusters, com um SO como Unix ou Windows NT/2000/XP. Problema: aplicações gráficas interativas (ex. Autocad), cujo envio de telas pela rede pode causar grandes atrasos. Implementações: X11 (sistema de janelas), WinFrame da Citrix, VNC da AT&T.
14 SD Cap. 1-4
Dispositivos móveis e comunicação espontânea
Dispositivos móveis estão se tornando populares: Notebooks; Laptops; PDAs; Celulares; Cameras digitais; Computadores “vestíveis” – relógios, etc. Dispositivos embutidos (máquinas de lavar, geladeiras, microondas, etc.). • • • • • • •
Esses dispositivos podem realizar comunicação sem fio: Grandes distâncias: GSM (centenas de Kbps), CDPD; Centenas de metros: WAVELAN; Poucos metros: BlueTooth, infravermelho, HomeFR – 10 Mbps.
14 SD Cap. 1-4
Fácil integração com os serviços locais – os dispositivos descobrem os recursos disponíveis e podem utilizá-los quando necessário. Desafio de conseguir conexão e integração fáceis: Ex.: endereços IP assumem que as máquinas pertencem a uma determinada subrede – se o computador é movido para outra rede, ele não pode ser acessado com o mesmo endereço. •
•
Os usuários podem ter problemas de conexão à medida que viajam A natureza espontânea de sua conexão pode levar a problemas de segurança. •
• • •
GSM: Global System Mobile Communication CDPD: também conhecido como Mobile IP WAVELAN: LAN sem fio BlueTooth: padrão de comunicação por rádio HomeRF: Home Radio Frequency: sistema de comunicação por rádio Comunicação espontânea é o termo que indica que os dispositivos
móveis se comunicam com as redes para estabelecer seu funcionamento. Principais recursos da comunicação espontânea: Fácil conexão com redes locais – não há necessidade de cabos, plugs, etc.; •
•
•
•
•
Conectividade limitada : p. ex. O usuário pode sofrer
desconexões intermitentes se viajar num trem que passa por túneis O usuário pode ser desconectado quando estiver numa região sem acesso – como suportar o usuário para que ele possa trabalhar mesmo desconectado? Segurança e privacidade: p. ex. Usuários ou funcionários de
uma instalação podem tentar se conectar num modo não supervisionado; Usuários podem ser espionados a medida que se movem por várias redes; Usuários podem acessar suas redes caseiras, o que pode tornar esses ambientes suscetíveis a ataques – dados mantidos por um firewall podem ser interceptados quando o usuário acessa-os.
15 SD Cap. 1-4
•
•
•
•
Descobrir serviços: ao se conectar com uma rede, o dispositivo
móvel deve identificar os recursos disponíveis (ex.: impressoras, fax, TVs, etc.) Não se pode esperar que os protocolos de todos os recursos sejam compatíveis; Deve haver meios de descobrir os recursos disponíveis e obter dados sobre eles; Quando so usuários quiserem, poderão fazer requisições sobre esses recursos;
Um serviço de descoberta tem 2 interfaces: Serviço de registro : aceita registros dos servidores e mantém bancos de dados sobre os recursos disponíveis; Serviço de lookup (pesquisa) : aceita requisições dos usuários e o BD por serviços que possam atendê-las; •
•
Ex.: usuário em um hotel com figuras numa câmera digital que deseja ver como elas saíram.
2.2.4 Interfaces e Objetos Definições de interface: conjunto de funções disponíveis para invocação em um processo (servidor, peer, etc.). Ex.: C++, Java, etc. Linguagens orientadas a objetos podem encapsular objetos com uma interface definida. Os métodos desses objetos podem ser invocados remotamente. Ex.: CORBA, RMI, etc.
15 SD Cap. 1-4
2.2.5 Requisitos de projeto para arquiteturas distribuídas Compartilhamento de recursos foi lançado nos anos 60, com o sistemas timesharing. Ex. Sistemas operacionais multiusuários (Unix) ou sistemas de banco de dados multiusuários (Oracle). O surgimento de processadores baratos e de alto desempenho tirou o controle dos recursos de máquinas de grande capacidade passou-os para qualquer máquina da rede. A necessidade de compartilhamento de recursos físicos (impressoras, discos, etc.) levou aos SDs dos anos 70 e 80. Hoje, o compartilhamento atinge principalmente os dados. O principal desafio é controlar o acesso concorrente aos dados e evitar os conflitos de atualização. Questões de desempenho
Derivado do uso de máquinas e linhas de comunicação limitadas, aparecem 3 principais elementos: •
Tempo de resposta : o acesso a recursos remotos leva a atrasos
consideráveis nas respostas a requisições do usuário; Para melhorar os tempos de resposta, o software deve ser composto de poucas camadas; A quantidade de dados trocadas entre os processos deve ser pequena. Ex.: navegadores – páginas acessadas do cache são rápidas; páginas só de texto mesmo remotas são rápidas; páginas com dados grandes acessadas remotamente são lentas. •
•
16 SD Cap. 1-4
•
•
•
•
•
•
Throughput: taxa de realização de trabalho computacional.
Num SD é a habilidade de realizar trabalho para todos os seus usuários. Valor afetado pela velocidade de clientes e servidores e pelas taxas de transferência. Considere dados localizados num servidor remoto: o Os dados precisam passar do processo servidor para o processo cliente; o Nesse processo, eles atravessam várias camadas de software nos 2 lados; o O throughput de cada camada é importante, assim como o da rede. Balanceamento de carga: uma das finalidades de um SD: permitir que aplicações e outros processos processem concorrentemente sem competição por recursos. P. ex.: rodar applets nos clientes permite ao servidor prestar um serviço melhor; Ex.: vários computadores para manter um só serviço. O DNS tem um recurso de lookup que devolve só um deles na pesquisa de um domínio; Algumas vezes, é preciso mover um serviço parcialmente feito para ajustar a carga de um sistema.
Qualidade de serviço
Uma vez que um SD tenha o serviço que o usuário precisa, é preciso verificar sua qualidade. Propriedades que afetam a qualidade: Confiabilidade, segurança e desempenho. •
16 SD Cap. 1-4
Recursos reconhecidos a pouco tempo como muito importantes para a qualidade: Adaptabilidade: para se adequar a mudanças; Disponibilidade de recursos. • •
Aspectos de desempenho em QoS até pouco tempo eram tratados como tempo de resposta e throughput. Recentemente se considera que são as garantias de se respeitar limites de tempo. Algumas aplicações trabalham com dados de tempo crítico - cadeias que precisam ser processadas entre processos a uma taxa fixa. Ex.: vídeo. QoS é considerado hoje como a capacidade de atender deadlines. Alcançar isso depende de existir suficiente recurso de processamento e redes no momento certo. Quem deve garantir esses recursos é o sistema. Ex.: as redes que se conectam com a Internet hoje conseguem transferir dados a taxas satisfatórias até que elas se sobrecarreguem. Nesse caso, o desempenho se deteriora rapidamente. De forma nenhuma, isso pode ser considerado QoS. QoS é garantido pelo SO. Recursos críticos devem ser reservados para as aplicações que precisam de QoS. Gerentes de recursos devem dar garantias. Requisições de reserva que n\ão podem ser atendidas são descartadas. Uso de cache e replicação
As questões de desempenho citadas podem parecer obstáculos para a construção de SDs.
18 SD Cap. 1-4
•
Assim, não é possível fazer um sistema que carregue fichas de pacientes em notebooks porque eles são inseguros por natureza.
18 SD Cap. 1-4
•
•
2.3 Modelos Fundamentais Um modelo contém os elementos mínimos para entender e raciocinar sobre os elementos essenciais de um sistema. Questões principais: Quais são as principais entidades do sistema? Como elas interagem? Que caracterísiticas afetam seu comportamento individual e coletivo? • • •
Finalidade de um modelo: Tornar explícitas todas as suposições relevantes do sistema modelado. Generalizar o que é possível ou não em geral, tomam a forma de algoritmos de finalidade geral ou regras (propriedades desejáveis) garantidos. As garantias são dadas por análise lógica ou prova matemática. •
•
Aspectos de SDs dos modelos fundamentais: Interação: processos interagem por mensagens e coordenação; o modelo de interação deve tratar dos atrasos inerentes à comunicação; também deve considerar a precisão com que um grupo de processos pode se sincronizar – depende dos atrasos e da manutenção de noção de tempo entre todos os computadores; •
Falhas: definição dos tipos e classificação das falhas – fornece
uma base para a análise das falhas e o projeto do tratamento de cada tipo; Segurança : a natureza modular e abertura dos SDs expõem-os a ataques externos e internos. O modelo de segurança define e classifica as formas de ataque, permite análise de ameaças e o projeto de métodos de resistência.
2.3.1 Modelo de Interação Um programa simples é controlado por um algoritmo sequencial, cujos passos são realizados numa cadência conhecida. O algoritmo não interfere nem sofre interferências externas. Ele também define os conteúdos das variáveis e os estados dos programas em um dado momento. SDs são constituídos de múltiplos processos. Seu comportamento pode ser descrito por um algoritmo distribuído : uma definição de passos + transmissão de mensagens entre os processos. As mensagens são usadas para transferir informações e para coordenar as atividades. Elementos difíceis de determinar: Taxa de andamento de cada processo; Momento em que uma mensagem é enviada; Estados do algoritmo - é preciso considerar as falhas em 1 ou + processos, extravio de mensagens, etc. • • •
A seguir, vemos 2 fatores que afetam a interação de processos num SD.
19 SD Cap. 1-4
Desempenho dos canais de comunicação
19 SD Cap. 1-4
Duas abordagens diferentes em relação ao tempo: Forte suposição; Nenhuma suposição. •
•
Latência: o atraso entre a transmissão e recepção de uma
mensagem. Inclui: Tempo para o 1o. bit sair do transmissor e atingir seu destino; Atraso para acessar a rede - maior em redes carregadas; Atraso dos serviços de comunicação dos SOs origem e destino. Banda: capacidade de transmissão total em um certo momento; Jitter : variação de tempo para entregar uma série de mensagens - importante em multimídia, onde a diferença nos tempos de entrega pode causar distorções. •
• •
• •
Duas variantes do modelo de interação
É difícil impor limites de tempo para: Execução de um processo; Trânsito de uma msg; Taxa de variação de um relógio. •
•
•
Cada computador possui seu relógio. Os processos locais usam-no para medir o tempo dos eventos locais. Relógios possuem diferenças em relação ao tempo real. A taxa de diferença mede a relação entre o relógio local e um relógio perfeito. Acertando todos os relógios de um SD ao mesmo tempo, após um certo período pode-se ter variações significativas.
•
SDs síncronos definem os seguintes limites (inferiores e superiores):
•
Relógios e medição de tempo
•
•
Tempo para realizar um passo; Tempo para transmitir uma msg; Taxa de variação do relógio local.
É possível sugerir valores, mas é difícil dar garantias sobre eles. Um SD síncrono tem a vantagem de permitir modelagem, que pode ser útil para verificar seu funcionamento. Pode-se usar timeouts, p. ex., para determinar falhas em serviços. SDs assíncronos são aqueles que não podem ser qualificados como
síncronos (ex. Internet). Não possui limites: Processos podem demorar longos tempos arbitrários; Mensagens podem ser recebidas após longos tempos arbitrários; A taxa de variação dos relógios também é arbitrária. Na Internet, um email pode levar dias ou segundos. A transferência de um arq. por FTP pode ser rápida, demorada ou inviável. O problema dos exércitos azul e vermelho assume mais um grau de dificuldade, caso o sistema seja assíncrono. Alguns problemas de projeto podem ser resolvidos mesmo nesse caso. Ex. a Web não possui limites para tempos de resposta, mas os navegadores podem permitir ao usuário outras atividades enquanto espera. Soluções válidas para SDs assíncronos também são válidas para SDs síncronos. • • •
20 SD Cap. 1-4
20 SD Cap. 1-4
Processos ou canais falham por não realizar o que se esperava que fizessem.
Ordenação de eventos
Há interesses em saber se um evento ocorre antes, depois ou concorrentemente em relação a outro evento em outro processo. P. ex.: considere a seguinte situação 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 24 25
Z X Y
Re: Matter Matter Re: Matter
Para resolver o problema, é preciso 3 coisas: Sincronizar todos os relógios envolvidos; Enviar o timestamp junto com a msg; Classificar as msgs pelo timestamp.
Processos : principal ocorrência é o crash. Nesse caso, o processo pára e não realiza mais sua tarefa. O projeto de um serviço tolerante a falhas é simplificado se os serviços de que ele depende falham de forma limpa (ou funciona ou pára). Um processo falha em crash se outros processos podem determinar que isso aconteceu.
•
Comunicação :
Send m
Receive
• • •
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 Omissão
Buffer de transmissão
Buffer de recepção
O canal de comunicação produz uma falha por omissão se: Não ocorre o transporte entre os buffers de transmissão e recepção (ex. falta de espaço em buffer); Erro de transmissão (detectado por checksums). •
•
As falhas podem ser classificadas por sua severidade. Todos os tipos de falhas apontadas aqui são falhas benignas (não causam interrupções sérias no sistema).
21 SD Cap. 1-4
Falhas arbitrárias O termo arbitrário (ou Bizantino) descreve o pior tipo de falha possível, onde um processo não pára (não há crash) mas pode alterar seus dados com valores errados, ou dar respostas erradas. Nesse caso, o processamento de uma requisição ocorre com uma sequência de passos equivocada. Canais de comunicação são especialmente sujeitos a esse tipo de falha: O conteúdo de uma mensagem pode ser corrompido; Mensagens não existentes podem ser entregues; Mensagens reais podem ser entregues + de uma vez. Em geral, o software de rede identifica todos esses casos com facilidade (ex. Checksums, números de sequência, etc.). • •
21 SD Cap. 1-4
É possível construir serviços confiáveis a partir de elementos que apresentam falhas. As características das falhas permitem desenhar serviços que mascaram falhas em componentes dos quais o serviço depende. Formas de mascarar falhas: O serviço esconde sua ocorrência; A falha é convertida em um tipo + aceitável. Ex. Checksums mascaram msgs corrompidas – uma falha arbitrária é convertida em falha por omissão. Crashes de processos podem ser mascarados – o processo é substituído e seu estado é restaurado a partir de dados armazenados pelos predecessores. • •
•
Falhas de tempo Ocorrem em SDs síncronos (tempo de execução de processos, entrega de msgs, diferença entre relógios). Num SD assíncrono, um servidor pode responder muito lentamente, mas não se pode falar em falhas de tempo já que não há garantias.
Mascarando falhas Componentes de SDs são construídos a partir de conjuntos de outros componentes.
Confiabilidade da comunicação 1-para-1 Canais apresentam falhas por omissão, mas podem ser usados para construir serviços que mascaram essas falhas. Uma comunicação é confiável se ela apresentar: Validade : uma msg colocada no buffer de transmissão é sempre entregue no buffer de recepção; Integridade : a msg recebida é idêntica à enviada; msgs não são enviadas + de 1 vez; msgs não enviadas não são entregues. •
•
22 SD Cap. 1-4
22 SD Cap. 1-4
O servidor deve identificar o principal que acessa seus objetos e conceder direitos de acesso. As operações devem ser verificadas. Se estiverem fora dos direitos concedidos, devem ser negadas. O cliente deve identificar o servidor para garantir que as respostas vêm de um principal autêntico.
2.3.3 Modelo de segurança Proteção de objetos Access rights
Object
invocation
Protegendo processos e suas interações
Client Server
result
Principal (user)
Network
Principal (server)
Na figura, um servidor manipula um conjunto de objetos. Os usuários executam programas clientes para acessar esses objetos. Os servidores recebem invocações e devolvem respostas. Para cada usuário, o servidor verifica os direitos de acesso antes de dar acesso aos objetos. Usuários diferentes podem usar os objetos de formas diferentes. Ex.: um objeto que contém uma caixa postal São dados privados pertencentes a alguém; Só o dono pode ver e/ou alterar esse objeto. •
Processos interagem pelo envio de mensagens. Mensagens ficam expostas a ataques enquanto trafegam pela rede. Os serviços em que são baseadas são abertos e suas interfaces publicadas. Assim, alguém pode enviar mensagens a um principal tentando se passar por outro. O inimigo Copy of
m The enemy
Process p
m’
m
Communication channel
Proces
q
s
•
Ex.: páginas Web Alguns usuários só podem ler essas páginas; O dono pode alterar seu conteúdo. • •
Os principais devem ser identificados e associados com um conjunto de direitos de acesso.
Para modelar os ataques possíveis, 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 endereçadas a outros processos, ou um programa que gera msgs fazendo falsas requisições como se fosse um usuário autorizado.
23 SD Cap. 1-4
•
•
Ameaça aos processos: processos podem receber msgs da rede e
talvez não consigam identificar o emissor. o Servidores: da mesma forma, processo podem enviar msgs a um servidor, que pode não identificar o emissor. Pode-se exigir que o emissor acrescente uma identidade à requisição, mas ela também pode ser falsificada. o Clientes: um servidor que um cliente acessa pode ser falso. Assim é difícil determinar se a resposta vem de um servidor legal ou de um que se faz passar por outro. Ameaça aos canais de comunicação: o inimigo pode copiar, alterar ou injetar msgs numa rede. Um ataque + sofisticado é copiar msgs e fazer replay delas + tarde.
Combatendo ameaças à segurança •
•
•
Criptografia e segredos compartilhados : considere que 2 processos compartilham um segredo (só os 2 sabem). Se numa troca de mensagens esse segredo é anexado, então o outro lado sabe que o processo que mandou a msg é quem diz ser. Para garantir que o segredo não se torne público, as msgs são trocadas criptografadas; Autenticação : o uso de segredos compartilhados e criptografia é a base para a autenticação, sistema de garantia de identidade de um principal; Canais seguros: criptografia e autenticação permitem construir canais seguros no topo de um sistema de comunicação. Propriedades: o Cada principal sabe a identifdade de seu par; o Garantia de privacidade e integridade; o Timestamps podem evitar replay ou troca de ordem.
23 SD Cap. 1-4
24 SD Cap. 1-4
24 SD Cap. 1-4
Internet x FLIP
Cap. 3 – FLIP (Fast Local Internet Protocol) Há necessidades não atendidas por alguns protocolos (ex.: TCP/IP) que precisam ser consideradas num SD. P. ex.: •
Transparência: as mensagens devem ser transmitidas para processos (ou portas) em vez de números IP. Transparência completa: a comunicação é mantida mesmo quando os processos (ou portas) migram entre os computadores. Segurança: numa rede, alguns componentes podem ser seguros e outros não: Não seguros: criptografia . Criptografia consome recursos – não fazer nos componentes seguros. Gerência de rede simplificada : Redes grandes: computadores adicionados ou removidos com freqüência. Alocação automática de novos endereços. •
•
• •
•
•
•
Esses elementos são difíceis de alcançar em redes dispersas: limitações de desempenho; múltiplos domínios administrativos. • •
Camada Aplicação Sessão Transporte Internet
• •
FTP, Telnet, SMTP TCP, UDP IP
FLIP Definido pelo usuário RPC, grupos FLIP (tipo UDP) FLIP
Características: • • • • •
Serviço não confiável de datagrama; Base para protocolo RPC e multicast de grupo; Fonte e destino = processos Amoeba; Mensagens de 0 a 4GB (não precisa de transporte); Número de porta único em toda a rede. Número não se altera com migração. Endereça grupos de portas. •
•
Cada computador em uma rede FLIP é conectado à rede física 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 localização de um identificador FLIP pode ser feita via broadcast. •
• •
FLIP: Tanenbaum: protocolo para redes Ethernet interconectadas; computadores com Amoeba.
Protocolo Internet
•
25 SD Cap. 1-4
•
Interface com os hosts : para o envio e recepção de mensagens
unicast, multicast e broadcast; Permite que processos se registrem (p. ex.: servidores) para a recepção de mensagens; Esse registro pode ser seguro, se necessário – funções de criptografia one-way. Interfaces de Rede: um host tem uma só; um roteador tem várias interfaces com redes diferentes. •
•
•
Principais diferenças entre FLIP e protocolos Internet: •
•
• • •
FLIP tem transparência de localização – destinos independentes de localização; Identificadores de portas gerados e alocados automaticamente – reduz a administração; Suporte à comunicação de grupo; Suporta comunicação segura apenas onde é necessário; Objetivo: uso em grupos pequenos e confiáveis de WANs e LANs.
25 SD Cap. 1-4
26 SD Cap. 1-4
26 SD Cap. 1-4
Ex.:
Cap. 4 – IPC
char * nome = “Smith, * lugar = “London”; int ano = 1934;
4.3 Representação externa de dados e marshalling
sprintf(msg, “%d%s%d%s%d”, strlen(nome), nome, strlen(lugar), lugar, ano);
Mensagens : • • •
Estruturas de dados mapeados em seqüência; Integração de diferentes tipos de dados; Plataformas com representação interna diferente; Conversão para representação 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 : operação de empacotar dados numa mensagem para
transmissão.
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 representação; Códigos de representação: 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
Representação externa definida no Corba 2.0. Representa todos os tipos de dados que podem ser argumentos em chamadas de funções. 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
string: tamanho (unsigned long) + caracteres em ordem (pode ser caracteres longos); array: elementos em ordem (não possui tamanho); struct: na ordem dos componentes; enumerated: unsigned long; union: tipo + membro. O exemplo Smith, London, 1934 em XDR é idêntico em Corba CDR. •
•
27 SD Cap. 1-4
public class Person implements Serializable { private String name; private String place; private int year;
• • •
Marshaling no Corba
Considere o exemplo Smith, London, 1934. As operações de marshalling são feitas automaticamente a partir da definição IDL: struct Person { string name; string place; long year; };
O compilador de interface do Corba gera as operações de marshalling e unmarshalling para os parâmetros e resultados. Serialização de objetos em Java
No Java RMI, objetos e dados primitivos podem ser passados como argumentos e resultados de operações. Ex. Implementação do exemplo do IDL acima:
public Person(String aName, String aPlace, int aYear) { name = aName; place = aPlace; year = aYear; } // outros metodos }
A interface Serializable não possui métodos, mas permite que objetos instâncias das classes que implementam-na sejam serializados. Isso significa transformar um objeto numa sequência de bytes que podem ser armazenados em disco ou enviados numa mensagem. A operação de deserialização consiste em transformar uma sequência de bytes no objeto original. O processo que recupera um objeto não tem informações sobre ele. Elas fazem parte da forma sequencial. A serialização inclui todos os objetos referenciados. Isso permite reconstruir o objeto orginal com todos os objetos que ele referenciava. Referências a variáveis que não devem ser serializadas devem ser declaradas como transient (ex.: arquivos, sockets, etc.) Reflection: informa o compilador que a classe de uma instância não é conhecida. Ela será conhecida durante a execução. Isso permite a
28 SD Cap. 1-4
serialização de uma forma totalmente genérica, sem conhecimento prévio da classe usada.
28 SD Cap. 1-4
Identificadores de destino independentes de localização.
Na Internet: Porta, número IP. •
Operações Send e Receive
Send(destino, msg); Receive(fonte, msg); Para o receive, fonte pode ser ANY.
FLIP: •
Destino mapeado para um endereço físico pelos roteadores.
Comunicação confiável. Problemas que podem ocorrer com mensagens:
Comunicação síncrona e assíncrona
A comunicação síncrona envolve o bloqueio do transmissor (send) e do receptor (receive). O bloqueio permanece até que o processo par realize a operação par do processo bloqueado. A comunicação assíncrona bloqueia o processo apenas até que a msg seja entregue à biblioteca de comunicação (send). Mesmo nesse caso, pode-se escolher entre receive bloqueante e não bloqueante. Na forma não bloqueante, o processo continua sua execução e há alguma função que indica se o buffer recebeu uma mnsg válida. Obs.: no Java (multithread) o bloqueio não tem importância, pois é possível fazer uma thread bloquear enquanto o restante da aplicação continua. A comunicação não bloqueante parece ser + vantajosa, mas é a + difícil de implementar, pois é preciso carregar a msg no buffer do processo sem que ele solicite. Por isso, alguns sistemas não oferecem essa possibilidade.
• • • •
Extravio; Duplicação; Entrega fora de ordem; Atraso.
Um serviço confiável pode ser construído sobre um outro não confiável pelo uso de acks de confirmação. Cliente-servidor: ack positivo; Grupos: ack negativo. • •
Overhead de um serviço confiável:
1. Armazenamento de informação de estado em fonte e destino. 2. Retransmissão. 3. Latência entre fonte e destino. Identificadores de mensagens :
1. Request ID: número seqüencial único (ex.: 2**32). 2. Identificação do processo send (porta) para receber resposta: Request ID volta para zero; •
29 SD Cap. 1-4
•
Tempo de vida de uma msg. << tempo para esgotar os números.
29 SD Cap. 1-4
•
•
Destino de mensagens
Na Internet, msgs são enviadas para . Uma porta é um processo destino num computador. Uma porta tem no máximo um receptor. Mas pode ter vários transmissores. Qualquer processo que saiba o número 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 serviço, esse serviço deve rodar sempre no mesmo endereço (não permite mobilidade, não é transparente, etc.).
Portas permitem que 1 msg seja entregue a vários processos em máquinas diferentes; Alguns sistemas permitem usar endereços de grupos de processos.
Referências a objetos remotos Feito através de mensagens de invocação. Especifica que objeto deve ter um de seus métodos invocados. Válido dentro de um SD determinado. Ex.: Endereço IP (32 bits); Porta (32 bits); Hora (32 bits); Número de objeto (32 bits); Interface para o objeto remoto. • • • •
Para evitar isso: Clientes se referem a serviços pelo nome, e um serviço de nomes ou binder faz a tradução; o Permite relocação, mas não migração. É possível ao SO usar endereços independentes de localização, fazendo seu mapeamento para endereços de baixo nível; o Permite relocação e migração. •
•
Alternativa: endereçar msgs para processos em vez de portas (ex. V System – 1984). Cada processo recebe um número único para o sistema inteiro; Portas permitem que um processo tenha vários endereços para receber msgs; • •
•
4.4 Comunicação 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
Implementação: Send(Porta, Msg); Receive(Fonte, Resposta). Timeout para falhas e retransmissão.
Perda de respostas:
•
•
•
•
Operação reexecutada após a repetição de uma requisição; Não há problemas caso a operação seja idempotente ;
•
Histórico:
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 método Array de bytes
• • • • •
Protocolos RPC: • • •
Timeouts: • •
•
Indica que uma operação DoOperation falhou; Pode ocorrer porque um reply ou request se perdeu; o Em caso de reply, a operação foi feita; Leva à retransmissão até que chegue uma resposta ou que se assuma que o servidor não vai responder.
Descartando mensagens duplicadas: •
•
•
Com retransmissão, um servidor pode receber uma mensagem mais de uma vez. O servidor pode executar uma requisição num tempo maior do que o timeout do cliente. Controle de Identificação da mensagem.
Para servidores não idempotentes; Registro das respostas enviadas para cada requisição; Custo de memória para manter as informações; Servidor deve saber quando descartar um registro; Sistemas interativos: uma resposta a cada requisição – se o cliente retransmite, basta guardar a última resposta. Request (R): não 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, métodos, argumentos e resultados; Há um conjunto fixo de métodos (GET, PUT, POST, etc.). • •
•
•
•
Especificação de conteúdo: os clientes podem dizer ao servidor que tipo de dados eles podem representar. Autenticação: o servidor pode dar um reply solicitando user + password, caso o cliente tente acessar uma área protegida.
31 SD Cap. 1-4
Navegadores podem usar conexões persistentes, já que o estabelecimento de conexões a cada pedido é muito custoso. Essas conexões permanecem ativas mesmo entre várias requisições.
4.5 Comunicação de Grupo
31 SD Cap. 1-4
Detalhes específicos do Ipv4: Roteadores multicast : pacotes IP podem ser enviados por multicast para redes locais (ex.: multicast Ethernet) ou na Internet. Roteadores multicast sabem utros roteadores debem receber um pacote (suas redes possuem membros). O TTL limita a distância entre membros de um grupo. Alocação de endereços: endereços multicast podem ser permanentes ou temporários. Grupos permanentes existem mesmo sem nenhum membro. Esses endereços são da faixa 224.0.0.1 até 224.0.0.255. •
•
Mensagens multicast são úteis para construir Sistemas Distribuídos: Tolerância a falhas baseadas em serviços replicados; Descobrir serviços em comunicação espontânea; Melhor desempenho através de dados replicados; Localização de objetos controlados individualmente; Desempenho: após alteração, dados enviados para todos os interessados; Atualização múltipla: ex.: usuários de uma lista; Propagação de notificações de eventos. • • • • •
• •
4.5.1 IP multicast – uma implementação de comunicação de grupos Grupos multicast são especificados por endereços classe D (1os. 4 bits = 1110). Membros de um grupo recebem pacotes IP endereçados ao grupo. A participação como membro é dinâmica. Só disponível via protocolo UDP.
Modelo de falhas para datagramas multicast
Datagramas de IP multicast têm os mesmos problemas de datagramas UDP – sofrem falhas por omissão. Não há garantias que um membro de um grupo receberá uma mensagem – multicast não confiável. •
4.5.2 Confiabilidade e ordenação de multicast •
•
•
Um datagrama pode ser extraviado porque o buffer do destino está cheio; O extravio de um datagrama por um roteador evita a recepção da msg por todas as máquinas depois dele; Pacotes IP enviados por um internetwork não chegam necessariamente na ordem em que foram enviados.
32 SD Cap. 1-4
32 SD Cap. 1-4
Atomicidade: •
•
Caso 1: todos os servidores precisam receber: Multicast atômico : todos recebem ou nenhum. Multicast confiável : há um esforço para garantir a entrega, mas não há garantias.
Mensagens enviadas para um grupo via multicast totalmente ordenado
• •
Implementação de comunicação de grupos • •
Forma mais simples: multicast não confiável; Mensagem única é enviada para cada destino:
Ordenação
Operações multicast atômicas e confiáveis fornecem ordenação FIFO. Neste tipo de ordenação, as mensagens entre3 clientes e servidores são entregues na ordem de envio (possível pelo uso de números de seqüência dentro das mensagens). No caso 1, todos os servidores devem executar todas as requisições na mesma ordem. Sem um mecanismo de garantia da ordenação, as mensagens podem chegar em ordem diferente dependendo do servidor. P. ex.: há extravios e retransmissões. P1
P2 A
P3
void multicast(PortId porta[], Message m) { int i; for (i = 0; i < sizeof(porta); i++) Send(porta(i), m); } •
•
P4
Este procedimento potencialmente é não confiável – usa o Send básico; Essa função implica na existência de um serviço de controle de grupos, do qual se obteve os números de porta dos participantes.
Eficiência
B
•
A
•
B Tempo
•
•
Pode-se aumentar muito a eficiência de um multicast; Ex.: em redes Ethernet, há formas de fazer broadcast para todos os computadores de uma rede local; Ethernet também admite enviar uma mensagem para vários computadores da rede (multicast); Isso não resolve todos os problemas: Pode haver mais de um processo em um nó da rede; Pode haver processos em redes locais diferentes, conectadas entre si. • •
Forma mais forte de ordenação: multicast totalmente ordenado .
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 localização. •
Confiabilidade •
Razões para que uma mensagem não alcance todos os membros de um grupo: Extravio, caso as mensagens sejam enviadas uma a uma; Quem envia pode falhar após enviar para alguns dos participantes.
Quando todos os acks chegarem, o transmissor tem certeza de que todos os processos receberam. Se um ack não é recebido até um timeout, a mensagem é retransmitida; Após um número de retransmissões, assume-se que o membro do grupo falhou – ele é removido. •
•
• •
•
• •
Nenhum desses motivos é aceitável para aplicações com multicast atômico ou totalmente ordenado.
•
Pode ser que o transmissor falhe após enviar algumas mensagens; Os membros do grupo podem enviar seus acks e monitorar o transmissor para ver se ele recebeu todos os acks ou falhou; Em caso de falha, há duas possibilidades: Um processo substitui o transmissor (cliente) e completa o multicast; Ou ele falha e um ou mais membros do grupo detectam sua falha – neste caso, a mensagem é descartada por todos os que receberam. Para reduzir custos, uma nova requisição confirma que a anterior foi bem sucedida. •
Monitoramento • •
•
•
• •
Faz parte do serviço de grupos; Quando um processo envia uma mensagem para um grupo, ele monitora se todos receberam; Isso é feito com o reenvio caso um dos processo do grupo não responda; Após um certo número de tentativas, o processo que não responde é descartado do grupo; Mensagens de processos removidos são descartadas; Essencial para protocolos de multicast atômico.
•
•
Este protocolo tem um desempenho ruim, mesmo num meio que não apresente falhas. Há duas formas de se aumentar o desempenho desse tipo de comunicação.
Multicast atômico e confiável •
Forma de implementar um multicast confiável: O transmissor envia mesma mensagem para todos os componentes do grupo; Aguarda um ack de todos os processos;
Hold-back
•
•
•
O elemento que controla a comunicação retém a última mensagem até garantir que os requisitos de atomicidade e ordenação foram satisfeitos.
