CAP 1. – INTRODUÇÃO Neste livro procura-se analisar a evolução dos SO para responder aos desafios colocados pela distribuição e pela evolução da arquitectura dos computadores. Os desafios continuam essencialmente os mesmos: - Simplificar a interface com o sistema - Extrair o máximo rendimento da infra-estrutura de hardware SOs ficaram cada vez mais complicados, daí usar-se o termo mais abrangente de software de sistema que inclui, para além do núcleo, o conjunto de servidores, bibliotecas e protocolos que o complementam e permitem uma integração transparente em sistema distribuídos. 1.1. Condicionantes da Evolução 1.1.1. A Tecnológica Destacam-se 4 que mais profundamente modificaram o modo de conceber os sistemas computacionais: 1. As redes de computadores 2. Os computadores pessoais 3. Os sistemas abertos 4. As arquitecturas multiprocessador Redes de Computadores Os primeiros foram as companhias de aviação e sector bancário, que definiram assim os requisitos para os sistemas interactivos e transaccionais. Desenvolveram mecanismos comunicacionais; Operadores públicos ofereceram serviços de trx. de dados (ex. X.25); Internet teve um impacto enorme sobre os sistemas distribuídos na demonstração prática de problemas de segurança e de gestão que se colocam a esta escala. Operadores continuam com RDIS e ATM que permitirá ligar inúmeros equipamentos ao computador. Simultaneamente as LANs evoluiram. Computadores Pessoais Os gestores das empresas passaram a considerar a hipótese de descentralizarem o seu suporte informático, colocando máquinas de menor porte junto dos grupos que as utilizavam directamente. a distribuição tornou-se, assim, uma característica inevitável nos sistemas informáticos actuais. A evolução interessante deu-se quando foi possível inserir mecanismos que permitem interligar um grande número de computadores pessoais partilhando, coerentemente, informações e serviços. O culminar deste processo deu srcem a um novo paradigma no desenvolvimento das aplicações informáticas, o modelo cliente-servidor. Sistemas Abertos Durante muito tempo, caso se mudasse de fabricante tal implicava a substituição do SO e, consequentemente, do ambiente de desenvolvimento das aplicações. Utilizadores pressionaram para Sistemas Abertos, onde a ideia simples é uma separação clara entre o hardware e o SO e entre este a as aplicações. Isto levou ao conceito de plataforma, que procura virtualizar as características específicas de um dado equipamento ou programa, colocando a ênfase na definição de uma interface normalizada que permite a sua fácil integração em sistemas existentes ou a desenvolver. Arquitecturas Multiprocessador Os processos de microelectrónica vão-se aproximando do limite e o custo de desenvolvimento de um novo microprocessador são elevados, daí o interesse pelas arquitecturas multiprocessador, que permitem aumentar o desempenho, mantendo basicamente os ambientes de desenvolvimento de software. Interessa então por os processos num ambiente de concorrência real. Neste livro só estamos interessados em arquitecturas MIMD (Multiple Instruction, Multipl e Data), onde cada processador executa as suas instruções e trabalha sobre os seus dados. Podem ser classificadas em 2 categorias: de memória central partilhada (bus comum, os mais comuns) e de memória distribuída (através de rede local ou sistema dedicado de alto débito).
1.1.2. Os Requisitos dos Utilizadores É por actividade profissional: - Utilizadores finais dos sistemas computacionais - Os programadores - Os gestores de informática Requisitos dos utilizadores finais Funcionalidade dos sistemas: Isolamento dos detalhes – Transparência na utilização do sistema -> comandos, nomes e semânticas idênticas para todos os objectos sob controlo do SO. A vantagem da distribuição mais perceptível para o utilizador vulgar relacion a-se com a partilha de informação. Uma outra vertente da distribuição é a possibilidade de usar os computadores para suportar mais eficazmente a comunicação ente utilizadores humanos. É também importante a ergonomia das interfaces. Qualidade dos sistemas: Segurança; Fiabilidade; Disponibilidade. Requisitos do Programador Para além da funcionalidade do mecanismo de suporte, pretende que as interfaces com o software sistema se integrem harmoniosamente nos ambientes de programação. Um requisito, relacionado com os sistemas abertos, é a simplificação da portabilidade de aplicações através da definição de interfaces normalizadas ou API (Application Programming Interface). O programador também pretende um ambiente de programação que simplifique o desenvolvimento da aplicações, tornado idealmente o código independente da arquitectura das máquinas, da rede, dos protocolos, dos SO locais e mesmo do nº de máquinas ou utilizadores. Requisitos do Gestor Para rentabilizar: 1. Capacidade de evolução modular 2. Extensibilidade 3: Aumento da fiabilidade e disponibilidade 4. Capacidade de gestão global do sistema 1.2. Dificuldades e Vantagens Introduzidas pela Distribuição 1.2.1. Os Problemas Comunicação Exclusivamente por Mensagem Os multiprogramados têm mecanismos de comunicação por mensagem, mas internamente ao núcleo tudo é feito por espaço de endereçamento partilhado. Na distribuição não há partilha de memória física, o que dificulta as coisas. Há sempre perdas, duplicações e atrasos inseridos pelas várias entidades (gestores de periféricos, routers, armazenamento das mensagens, etc.) Para garantir a fiabilidade e sequenciamento das mensagens é necessário um nível suplementar de protocolos que assegurem estas propriedades. Modelo de Faltas Têm sempre um maior número de causas e maior probabilidade de ocorrência devido ao maior nº de componentes. Uma rede introduz um novo conjunto de componentes que pode falhar (controladores de rede, ligação ao sistema de cablagem, cabos, equipamentos de transmissão, etc.). Há também a correlação das falhas. A detecção também é mais complexa sendo difícil distinguir entre a falha de um servidor ou apenas um congestionamento do serviço. O modelo de tolerância a faltas tem de contar com tudo isso e introduz perdas no desempenho dos sistema. Distribuição do Sistema Operativo
O software sistema encontra-se repartido por diversas máquinas, dificultando a sincronização e o acesso à informação de gestão. Por exemplo a descodificação do caminho de acesso a um ficheiro dá-se no interior do núcleo numa única operação, nos centralizados. Outro exemplo: A sincronização nos sistemas centralizados baseia-se numa acção atómica a nível dos mecanismos elementa res que controlam o acesso à memória. Numa arquitectur a distribuída tal é impossível, havendo necessidade de existência de protocolos especializados na sincronização. A sincronização é um dos aspectos delicados. O tratamento do tempo também apresenta muito mais dificuldades no distribuído, havendo necessidade de um protocolo (complexo) de sincronização de relógios. Segurança A existência das redes introduz grande vulnerabilidade no sistema, porque, na maioria delas, não existem mecanismos de segurança física que impeçam a escuta das mensagens ou mesmo a sua substituição e falsificação. Por outro lado qualquer utilizador pode instalar software que não respeita as ”boas maneiras” A validação da identidade dos utilizadores que trocam informação nas redes e dos respectivos direitos passa a ser um problema complexo. Para além disso há os problemas de interligação de serviços públicos e privados com políticas de segurança diversas. Heterogeneidade Com múltiplas máquinas de fabricantes diversos, a representação dos dados é necessariamente heteogénea (ex. big endian ou little endian). Desempenho Introduz-se um acréscimo do tempo de trx. de mensagens que é pelo menos uma ordem de grandeza superior ao da comunicação local. Isto não só devido à trx. física mas também ao software usado para garantir comunicação fiável, segura e normalizada. 1.2.2. Vantagens Potenciais Adequação à Repartição Geográfica A centralização baseada em acesso por terminais remotos implica custos de comunicação significativos, porque não tira partido da possibilidade de trabalho local, em particular na interacção com o utilizador final das aplicações. Modularidade Os investimentos podem ser, portanto, programados da forma mais adequada ao crescimento da organização. Extensibilidade A capacidade de evolução de um sistema centralizado é limitada, devido essencialmente à estrutura do bus e do processador. Na distribuída a capacidade de processamento pode ser aumentada facilmente. Para além disso os SD pode expandir-se com máquinas de diferentes gerações tecnológicas, não existindo estruturas centrais (bus, controladores) que limitem à partida a capacidade física de evolução. Maior Disponibilidade Advém da existência de máquinas independentes que podem continuar a assegurar um serviço quando uma delas falha (replicação/redundância) Desempenho Optimizado Não é na eficiência de uma máquina isolada que os sistema poderá fornecer maior desempenho, mas na possibilidade de atribuir às máquinas mais adequadas as tarefas que elas podem optimizar.
Custo Argumento fundamental. baixa de custos nos PCs e servidores multiprocessador. É claro que os sistemas distribuídos implicam custos de comunicações, equipamento de rede e de supervisão, mas eliminam outros como os grandes centros de cálculo com ambiente controlado e elevados custos de exploração. 1.3. ARQUITECTURA DO SISTEMA A programação de aplicações executadas em sistemas computacionais independentes que não partilhem uma memória comum pode efectuar-se de diversas formas, desde a simples utilização dos gestores de periféricos da rede, directamente pelas aplicações, até o SO oferecer transparentemente suporte para as operações distribuídas. 1.3.1. Suporte à Comunicação Distribuída Nos primórdios as aplicações distribuíd as eram programadas utiliz ando directamente a interface do gestor de periférico e cabendo ao programador resolver os problemas de fiabilidade, heterogeneidade, gestão de recursos, etc. A evolução natural que facilitou a programação e a portabilidade foi a virtualização destas interfaces, oferecendo uma API estável suportada pelo SO. Do ponto de vista do programador , o suporte à comunicação materializa-se numa biblioteca de funções para envio e recepção de mensagens. Um dos exemplos mais conhecidos é o dos sockets do Unix (ex. telnet, ftp). Por ex. o ftp pode ser visto como a cooperação entre 2 aplicações, uma cliente outra servidor.... A programação é efectuada directamente, chamando as funções da biblioteca de sockets, tendo, portanto, uma relação directa com os detalhes dos protocolos. apesar desta solução ser expedita tem problemas: - Reutilização – cada aplicação reinventa os seus protocolos, gestão de nomes, etc. - Normalização – aplicação proprietária ou pública - Desempenho – A nível de núcleo é melhor - Segurança – Quando se implementa o suporte das aplicações no núcleo é mais fácil assegurar mecanismos de protecção. A implementação de aplicações distribuídas, usando apenas os mecanismos de comunicação, apresenta, no entanto, algumas vantagens complementares: - Programação Sistema Tradicional - Facilidade de Adaptação – portabilidade para sistemas heterogéneos. 1.3.2. Plataformas Cliente/Servidor Numa fase posterior a comunidade académica procurou encontrar métodos e tecnologias para suportar o desenvolvimento de aplicações distribuídas. Inicialmente, as redes foram utilizadas como mero mecanismo de acesso remoto a um computador, mantendo-se as aplicações no modelo habitual dos sistemas multiprogramados. Era tudo feito em sessão remota e as aplicações continuavam a executar-se na máquina onde estavam instaladas. Esta solução não explora eficientemente a distribuição, não utiliza a capacidade total de processamento e obriga a manter uma compatibilidade de interfaces com os multiprogramados, normalmente do tipo alfanumérica, o que é paradoxal face ao Windows. Problema semelhante tinha ocorrido no ambiente Unix onde se implementaram então aplicações cuja estrutura se baseava na separação entre um programa que implementava o essencial – o servidor – e outro que implementava a interface – o cliente -. A designação de arquitectura Cliente/Servidor estabelece a distinção entre 2 tipos de processos com comportamentos diferentes e, portanto, assimétricos: - Os servidores implementam um de funcionalidades de interesse geral para outros processo com comportamentos queconjunto remotamente lhes podem aceder. - Os clientes efectuam a interface com os utilizadores e podem executar parte das aplicações localmente e acedem remotamente aos servidores. Os servidores devem publicitar a existência dos seus serviços e quais os protocolos utilizados. A identificação dos serviços deve ser lógica permitindo a mudança de máquina servidora transparentemente.
Para diminuir a incidência de algumas limitações da utilização directa das bibliotecas das interfaces de comunicação, procurou-se criar um ambiente de suporte que facilite a programação, introduza normalização para as funções de base, dê mais garantia de segurança e tolerância a faltas e procure optimizar o desempenho. Esta evolução tem sido apresentada como o objectivo das plataformas cliente/servidor. Embora não exista definição clara e consensual destas plataformas, devem apresentar: 1. Comunicação entre clientes e servidores por chamada de procedimento remoto 2. Linguagem de descrição de interfaces e respectivo ambiente de desenvolvimento 3. Gestão de nomes 4. Mecanismos de segurança para autenticação e privacidade das comunicações 5. sistema de ficheiros distribuído 6. Sincronização de relógios A evolução das plataformas cliente-servidor deu-se na direcção dos sistemas distribuídos de objectos, de que podem ser consideradas como uma síntese de vários conceitos: o modelo cliente-servidor, a programação por objectos, as bases de dados orientadas aos objectos. 1.3.3. Sistema Operativo Distribuído A distinção que fazemos entre um SOD e um sistema cliente-servidor prende-se com o grau de integração dos diferentes componentes do sistema. Nos SOD a integração de todos os mecanismos é o objectivo primordial. A gestão de processos permite ilustrar as diferenças. Nas aproximações anteriores, os processos são locais a uma máquina e qualquer actividade remota passa pela interacção com um processo servidor. Se a gestão de processos for realizad a de forma integrada, os processos passam a ser entidades com capacidade de migrar entre máquinas existentes no sistema. esta facilidade permite não só políticas de equilíbrio da carga computacional (load balancing), como implementar facilidades de redirecção no caso de falhas de componentes do sistema. Uma extensão semelhante poderia ser considerada para a gestão de memória: faltas de páginas colmatadas por outra máquina, transparentemente. A homogeneidade destes SOD é um problema complexo. A modularização da sua estrutura interna também é uma das preocupações. A separação entre um núcleo de dimensão reduzi da, oferecendo os serviços bási cos (gestão de processos, gestão de memória e intercomunicação entre processos) e um conjunto de servidores que implementam a funcionalidade habitual do sistema, mas que podem ser geridos e mantidos de forma independente, é a linha técnica que tem vindo a ser seguida na maioria dos sistemas actuais como o Mach e Chorus. Eles usam como base um micro-núcleo com funcionalidade mínima que permite uma evolução do SO mais flexível, protegendo o investimento significativo que representa o software aplicacional para uma dada versãoseparação do SO. Osentre micro-núcleos têm de diversas vantagens: modularidad e, adaptação à distribuição, os mecanismos base e as políticas de sistema, dando ao programador a possibilidade de escolha de serviços adequados às características de uma aplicação que pode, ela própria, implementar as suas políticas, por exemplo, de segurança ou de tolerância a faltas. 1.4. ARQUITECTURAS MULTIPROCESSADOR 1.4.1. Multiprocessadores de Memória Partilhada Os vários processadores estão ligados à memória central através de bus partilhado. Os processadores têm cache privada. A coerência entre as caches dos diversos processadores é mantida pelo hardware de gestão de bus partilhado. Nestas máquinas existe apenas uma cópia do SO que se executa simultaneamente e em paralelo em todos os processadores. É conceptualmente a mais simples e normalmente suporta até 20 processadores. Os SO têm de ter mecanismos para execução simultânea em paralelo de vários processos, um em cada processador. comunicar pipes, sockets, etc, quer por memória partilhada e semáforos. estes Assimpodem se suportam um por maior nº de utilizadores ou executar mais trabalhos. Paralelização do Sistema Operativo Os multiprocessadores obrigaram à paralelização do código do SO para que este se execute correctamente e com bom desempenho nestas arquitecturas.
A paralelização do código do sistema operativo obriga à introdução de sincronização explícita em todos os seus pontos de entrada, em vez de se basear na ausência de preempção. Mas regiões críticas muito extensas diminui o paralelismo, pelo que esta deve ser efectuada num grão mais fino, dividindo a região crítica em várias zonas, cada uma delas protegida por uma variável de sincronização. Desta forma é possível ter vários processadores a criarem simultaneamente processos, pois cada um está normalmente a operar em dados diferentes. As regiões críticas globais (atribuição de pid) são de curta duração. Paralelismo a Nível Utilizador Uma forma de explorar o paralelismo intrínseco de certos algoritmos é permitir a execução em paralelo de várias tarefas que partilham o mesmo espaço de endereçamento, dentro do mesmo processo (ex ADA e Modula2). As tarefas são os elementos activos vistos pelo sistema operativo e usados pelo escalonador na atribuição dos processadores. 1.4.2. Multiprocessadores de Memória Distribuída Cada processador tem uma memória privada, interligados por uma rede de alto débito. A forma de comunicação é por mensagens. Podemos ir aqui até centenas ou milhares de processadores. Ao fim e ao cabo é um sistema distribuído com rede de interligação fiável permitindo protocolos mais simples; todos os processadores estão sob a mesma administração e correm o mesmo SO o que simplifica o problema de segurança e de tolerância a faltas. A visão oferecida ao utilizador e, em grande parte, ao programador é idêntica a um sistema centralizado. Devido ao seu elevado custo de aquisição e manutenção, estas máquinas têm de ser extremamente robustas e extensíveis. O sistema tem de conseguir tolerar a falha de parte dos processadores e reconfigurar-se para utilizar apenas os restantes; há que poder efectuar partições lógicas em que grupos de processadores se comportam como uma máquina autónoma e a contabilização dos custos de utilização tem de se feita de uma forma extremamente precisa. A utilização de micro-núcleos eficazes que asseguram a gestão básica dos processadores, complementados por servidores que oferecem as funcionalidades dos sistemas clássicos, apresenta-se como a solução mais promissora.
CAP. 2 – REDES DE DADOS 2.1. Introdução Fundamental neste contexto é a percepção do modelo conceptual das redes e dos níveis de protocolos com as respectivas interfaces funcionais e mecanismos de endereçamento. 2.1.1. A Complexidade das Redes de Dados A complexidade face a uma simples operação de E/S advém, sobretudo, dos problemas estruturais relacionado s com a escala e a heterogeneidade mas também de um mecanismo a que se exige cada vez mais desempenho e fiabilidade. Esta dimensão (ex. Internet) coloca problemas totalmente novos na interacção do software sistema com o ambiente exterior e que não tem paralelo nas E/S tradicionais. Por outro lado há muitos tipos de rede no que se refere a meios físicos de transmissão, partilha do meio, métodos de trx., etc. Isso tem a ver com sistemas proprietários mas também com a tecnologia (diferentes caracterí sticas de propagação, fiabilidade e imunidade ao ruído, gestão de multiplexagem. Isso tem implicações no binómio custo/desempenho (hardware, exploração, manutenção). 2.1.2. Redes Locais, Metropolitanas e de Grande Escala A razão da importância da escala como factor diferenciador da tecnologia das redes, deriva das limitações associadas à banda de trx. disponível e à distância. Diferentes meios de trx. como par entrançado, cabo coaxial, guias de ondas e fibra óptica têm velocidades de propagação, atenuação, taxas de erros e custo diferentes. Dependendo da área geográfica de implantação e dos requisitos de exploração, as várias propostas de arquitectura física das redes procuraram encontrar a relação custo/desempenho que optimizasse a estrutura da rede. Começou com as ofertas dos operadores de telecomunicações em redes implantadas para voz no srcinal, o que condicionou indirectamente os protocolos de níveis superiores. Depois, como o Unix, em 70s apareceu as redes locais com cabo coaxial e fibra. a seguir veio o RDIS e no futuro virá o ATM que esbaterá a diferença entre redes geograficamente diferentes. Para já há, em termos de escala: LAN – Redes Locais – extensão inferior a 10km MAN – Redes Metropolitanas – entre 10 e 100km WAN – Redes de Larga Escala – acima dos 100km A extensão condiciona também o usa-se meios próprios ou de operadores. Nas locais é tudo (meios de trx, gestão e equipamentos) da organização. Nas de longa distância para além de ser caro há monopólio, por vezes, dos operadores. é possível 2 abordagens: a utilização de uma rede públicadedetrx. dados; a implementação de uma rede privada, alugando aos operadores apenas os meios O custo é proporcional à largura de banda e distância. a realização de redes de grande escala, alugando os meios de trx. aos operadores, designa-se por rede privada, sendo normalmente a gestão da rede da organização e os meios físicos do operador. Os operadores diversificaram, propondo também redes públicas de dados (X.25, frame-relay, MAN/DQBD, Internet). Na rede privada o investimento inicial é elevado mas procura-se uma posterior utilização intensiva, pois os custos de aluguer são proporcionais ao tráfego, para além de um aluguer. 2.2. Arquitecturas das Redes de Dados Para os utilizadores a interface tipo telefone é a ideal. a pressão exercida pelos utilizadores no sentido dos Sistemas Abertos tem obrigado a indústria a assumir progressivamente uma atitude que privilegia a normalização e a definição de esquemas de interoperacionalidade dos diversos sistemas. 2.2.1. Arquitectura Física e Lógica As redes são complexas e obrigam à consideração de vários níveis de abstracção (desde as características dos sinais eléctricos ou ópticos até às interfaces de programação utilizáveis nas aplicações).
Seguindo a estratégia habitual nos sistemas computacionais de subdividir um problema complexo em vários níveis de abstracção, procurou-se criar nas redes um modelo que estabeleça os principais níveis de abstracção e o modo como estes se relacionam entre si. Uma divisão natural é considerar a existência de 2 níveis, correspondendo à arquitectura física e à arquitectura lógica. A física define os meios de transmissão, a topologia descrita pelos sistemas e as ligações entre os mesmos. A ligação entre os nós da rede depende em grande medida da forma como é controlada a transmissão. Uma diferença importante tem a ver com a utilização de um meio físico partilhado – difusão, ou de ligações ponto-a-ponto em que os sistemas se interligam aos pares. No primeiro tem de se estabelecer como controlar o direito de transmissão, no segundo a gestão da trx. é mais fácil mas o encaminhamento dos pacotes é mais complexo. Dependendo destas características, os nós podem interligar-se ao meio físico com diversas topologias. Nas redes de grande escala, a trx. é normalmente ponto-a-ponto e a topologia malhada, existindo diversos caminhos alternativos. Nas redes locais usam-se meios partilhados com uma trx. em difusão. As topologias mais comuns são tipo bus e anel. A topologia tem relação directa com a forma como é efectuado o controlo de partilha do meio. Por exemplo, num anel as ligações devem ser activas e actuar como repetidores, mantendo o sincronismo de funcionamento do anel, ao contrário, num bus as unidades de interligação são passivas e podem ser inseridas e retiradas com a rede a funcionar. A arquitectura lógica procura dotar a rede de um conjunto de propriedades adequadas ao seu campo de aplicações, como por ex. endereçamento transparente, desempenho, determinismo na entrega das mensagens, tolerância a faltas, endereçamento em difusão, garantia de ordenamento dos pacotes, etc. Um dos objectivos da divisão por níveis do modelo de comunicação das redes é flexibilizar a adopção da arquitectura lógica mais apropriada ao campo de aplicação, independentemente da arquitectura física subjacente. Ex. arquitecturas lógicas em anel sobre topologias físicas em bus. Estou enfim a virtualizar a rede física. assim, a arquitectura lógica de uma rede pode ser representada por uma malha de ligações entre redes que podem ter inclusivamente arquitecturas físicas diversas. O nível de separação entre AL e AF é diferente no sistema telefónico clássico e nas redes de computadores. 2.2.2. Os Modelos de Referência (p/ AL) Como existem muitas hipóteses, procurou-se definir modelos de referência que constituam um elemento agregador e sistematizante de toda a arquitectura de comunicação. Há os proprietários. actualmente o modelo mais usado é o OSI. Foi definido e normalizado no início da década de 80, reflecte parcialmente a envolvente tecnológica da época, por isso tem limitações. Mas como é genérico permite um fácil enquadramento de outras arquitecturas desenvolvidas independentemente e com maior implantação que a OSI. Com srcem na Arpanet desenvolveu-se uma arquitectura de rede que conduziu hoje à Internet. A família de protocolos Internet, mais conhecidos por protocolos TCP/IP, teve um grande desenvolvimento na 2ª metade da década de 80 e tomou em grande medida o lugar do OSI como tecnologia independente dos fabricantes e portanto como Sistema Aberto realmente utilizável. É menos formal mas é mais usado, pelo que o usaremos sobretudo ao longo do livro. O protocolo de transporte OSI também. 2.3. O Modelo OSI O objectivo era definir uma arquitectura de comunicação aberta. Ele estrutura a arquitectura de comunicações num conjunto de níveis ou camadas estanques com funções e interfaces bem definidas. Em cada nível existe uma interface de serviço que define a funcionalidade que esse nível disponibiliza à camada superior e um protocolo que define o formato e o significado das mensagens trocadas entre níveis correspondentes. Em cada sistema existe um fluxo de comunicação vertical através das interfaces. Entre níveis idênticos a comunicação é feita através de um protocolo. O protocolo associado a um dado nível define 2 aspectos: - O formato das mensagens – campos próprios ao protocolo + campo “opaco” que contém a informação recebida da camada superior.
- O significado e as acções a desencadear em função de cada mensagem trocada. A estanquidade e encapsulamento é obtida através de cabeçalhos. O PDU da camada N é igual ao SDU da camada N-1. Uma característica importante dos protocolos em qualquer nível tem a ver com o tipo de associação entre as entidades que comunicam: - Com ligação (connection oriented) - Sem ligação (connectionless) No 1º caso a comunicação decorre em 3 fases: estabelecimento da ligação, a conversação e a fase de corte da ligação (assemelha-se aos sistemas tradicionais de telecomunicações). No segundo caso os dados são enviados sem qualquer interacção prévia, existindo, conceptualmente, apenas a fase de conversação (correio). Vantagens e inconvenientes: Os com ligação podem aproveitar a fase de estabelecimento para negociar parâmetros relevantes para a fase de conversação, incluindo aspectos de segurança. Podem ainda implementar mecanismos de controlo de erros, que oferecem mais garantias às camadas superiores simplificando-as. Os sem ligação são mais simples e mais eficientes por eliminarem a latência da fase de estabelecimento. Tendem a consumir menos recursos de memória e processamento. No entanto obrigam ao endereçamento completo em cada mensagem consumindo largura de banda e é necessária decisão de encaminhamento em cada nó. caso as taxas de erros sejam baixas e as camadas superiores implemente controlo de recuperação de faltas, são mais eficientes para comunicações que não envolvem grandes volumes de dados. A difusão também é mais fácil. O modelo OSI define protocolos com ligação para os níveis de transporte e superiores, e nos de rede e de enlace também são comuns o que pode srcinar trocas de 18 conjuntos de dados antes da conversação. A interface de serviço é definida com base num conjunto de primitivas abstractas: Pedido, Indicação, Resposta e Confirmação. Estas funções abstractas cumprem o objectivo de independência do modelo OSI, definindo MC independente do SO e arquitectura de software de comunicações. A desvantagem é obrigar cada implementação a esforço adicional de adaptação ao modelo e condicionamento do desempenho devido à complexidade. Ao distinguir claramente entre serviço prestado e protocolo implementado pretendeu-se arquitectura modular e flexível. Este isolamento raramente se consegue em implementações reais. 2.3.1. Os Níveis Inferiores NívelaFísico Tem função de conseguir transmitir correctamente um bit sobre o meio físico de interligação. Preocupa-se com características de propagação do sinal como a velocidade, atenuação, imunidade ao ruído logo níveis eléctricos e temporais e protocolos de codificação que têm em conta os parâmetros de funcionamento da rede (taxa de erros, recuperação de relógio). Também interface eléctrica e mecânica. Nível Lógico ou de Ligação de Dados (data link) Utiliza os serviços do nível físico para o envio de pacotes de dados ou tramas (fra mes) entre 2 máquinas ligadas à mesma rede física. Encapsula numa trama que tem delimitadores, endereço do destinatário, informação de controlo e CRC. Uma função primordial deste nível é o contrlo da multiplexagem do meio de trx., de modo a poder enviar a trama. No modelocorrectamente OSI, este nível é serem também responsável garantir quefísico. os dados enviados são recebidos sem adulterados porpor faltas no meio Usa-se detecção de erros (CRC) e retrx. Nas redes de grande escala tradicionais este nível era também responsável pelo controlo de fluxo com mecanismos de janela deslizante.
Também se coloca aqui o problema da unidade básica de informação a trx. pois os dados dos níveis superiores podem estruturar-se em byte oriented (ASCII, EBCDIC) ou bit oriented. O SDLC da IBM é bit oriented com preâmbulo 01111110 e bit stuffing. Nível Rede Neste nível considera-se a rede como uma entidade lógica que interliga máquinas independentemente das redes físicas a que estão ligadas. É responsável pelo encaminhamento (routing) independentemente da rede física. Esta camada foi criada na óptica das redes malhadas de grande escala. A funcionalidade deste nível foi alvo de controvérsia. 2 filosofias: A defendida pelos operadores de telecomunicações pretende que o nível rede assegure uma ligação fiável que garanta a sequencialidade e o controlo de fluxo. Outra da Arpanet/Internet que considera que o nível de subrede é inerentemente pouco fiável pelo que a fiabilidade deve ficar a cargo do nível de transporte de extremo a extremo (ex.IP). Neste caso o nível deve só encaminhar. 2.3.2. Nível de Transporte Oferece um serviço de trx. de mensagens que permite a comunicação entre utilizadores finais. Dispõe de várias classes de qualidade de serviço. Noutra perspectiva, é o 1º nível em que os mecanismos de comunicação são virtualizados criando canais de comunicação entre processos. Existe normalmente a opção entre serviço com (criam uma abstracção de um canal de dados fiável e bidireccional) ou sem ligação (datagrama). Para garantir uma comunicação fiável, tem de detectar a existência de faltas (corrupção de dados, perda de mensagens, duplicação, recepção na ordem incorrecta do nível inferior) e assegurar a sua recuperação. Detecção é CRC, para além do de rede pois pode haver falhas na memória (tampões das máquinas finais ou encaminhadores). O receptor deve confirmar a mensagem. Deve também haver temporizador. A recuperação é feita por retrx. que, por sua vez pode srcinar duplicações e mensagens fora de ordem. As duplicações e alterações de ordem são detectadas enviando nºs de sequência. Mas a garantia de envio fiável da mensagem não é normalmente suficiente para uma aplicação. Aplicação pretende também assegurar outros requisitos como processo servidor está operacional e que recebeu correctamente o pedido. Para tal é preciso confirmação da aplicação; como ela confirma implicitamente a recepção adequada a nível de transporte, a sobrecarga suplementar de um mecanismo de transporte fiável pode ser evitada. Isolarmensagens o utilizadoredas físicas da rede implica que o transporte efectue a fragmentação das sualimitações numeração. Outro problema é que a capacidade do tampão do receptor é limitado, pelo que o emissor tem de ser bloqueado – controlo de fluxo. Nos protocolos com ligação é habitual considerar um mecanismo de janela que corresponde ao número máximo de pacotes que é possível enviar antes de receber confirmação do receptor. Uma outra facilidade importante para algumas aplicações é a garantia de sequencialidade. ex. SGBD. O assinalar de condições assíncronas depende do SO, por exemplo na interface de sockets do Unix, existe a possibilidade de notificar o utilizador da quebra do canal com ligação através de um signal. Sintetizando as propriedades habituais do serviço de transporte: - Com ligação/Sem Ligação - Garantia de entrega fiável da mensagem -- Controlo Fragmentação de fluxo - Mecanismo de janela - Garantia de ordem - Mecanismo de detecção e notificação de excepções que correspondem a quebra de serviço 2.3.3. Os Níveis Superiores
São locais a cada extremo da comunicação e transparentes à rede. Reflectem os problemas inerentes à compatibilização de sistemas heterogéneos, por forma a permitir a comunicação transparente para as aplicações e utilizadores. Nível de Sessão Tem por função a multiplexagem de várias instâncias de comunicação sobre a mesma ligação de transporte. Nível de Apresentação Controla a representação dos dados a trocar entre sistemas heterogéneos. Nível de Aplicação Engloba as funcionalidades relativas às aplicações propriamente ditas. No âmbito do OSI definiram-se aplicações para terminal virtual, transferência de ficheiros, correio electrónico, etc., pelo que num ambiente OSI há aqui uma série de subníveis que pretendem maximizar a reutilização de componentes comuns. 2.4. O Modelo Internet Resultado de projectos de investigação na área da comunicação de pacotes. Tem 4 níveis. Tem por base um modelo de concatenação de redes denominado (con)cate(nation) net ou catenet que assume que existe um grande nº de redes independentes, possivelmente utilizando tecnologias diferentes, interligadas entre si por portas (gateways) e cada utilizador pode falar com outro qualquer desde que saiba o seu endereço Internet.. - O nível de subrede – protocolos de ligação de dados associados aos meios físicos de trx. utilizados - Nível de Interligação de rede – assegura o encaminhamento dos pacotes - Nível de transporte – envia e recebe as mensagens das palicações que interactuam de extremo a extremo - Nível de Aplicação Há uma camada nuclear: o nível de interligação de redes. Baseia-se num único protocolo (IP) que define os aspectos mais relevantes para toda a arquitectura da Internet: - O endereçamento - A distinção entre nó (host) e rede As diferenças de fundo com OSI são: - O modelo Internet define comunicação entre redes. O foco é na interligação de redes em vez da interligação de sistemas - O modelo não pretende tratar a tecnologia da rede física Nível de Subrede A camada inferior do modelo Internet é específica a cada tecnologia física de transmissão, sendo suportada por RFC próprios que definem o modo como o encapsulamento do nível superior deve ser efectuado. Na Internet apenas se define o protocolo entre camadas correspondentes, ou seja, o formato das mensagens, o seu significado e as acções associadas, não existindo uma interface de serviço para cada camada. Embora tenha o inconveniente de não garantir a opacidade entre níveis, tem a vantagem de as normas de encapsulamento tirarem partido das características específicas da tecnologia de subrede para uma implementação eficiente, evitando lacunas de especificação, fonte de problemas de interoperacionalidade. Existem especificações para o encapsulamento dos pacotes do nível IP para todas as tecnologias (redes locais, ATM, Sonet, linhas série, etc.) Nível de Interligação de Redes O objectivo é disponibilizar às camadas superiores um serviço de encaminhamento dos pacotes através da rede. Rede formada por várias subredes independentes e de tecnologias diferentes.
O serviço oferecido pelo nível IP não dá qualquer garantia de fiabilidade. É “melhor esforço possível”. Se houver problemas de erro de trx. ou congestionamento, o nível superior não é avisado. Nível de Transporte Tem características semelhantes à camada OSI correspondente, nomeadamente esta camada apenas existe nos sistemas no extremo da conversação. Na família Internet definem-se 2 protocolos nesta camada: o TCP e o UDP. O TCP oferece um serviço semelhante ao de um canal de trx. fiável. O TCP oferece um serviço de transporte com ligação que garante a entrega de pacotes corrompidos, a eliminação de duplicações e a entrega sequencial. O TCP define um esquema de endereçamento, utilizando o conceito de porto, para identificar o utilizador final. O UDP oferece um serviço de transporte datagrama, não fiável, com base no melhor esforço, como o IP. Na prática baseia-se na utilização dos serviços do IP, adicionando checksum e endereçamento dos portos de acesso ao serviço de transporte UDP. Os portos UDP e TCP pertencem, portanto, a espaços de endereçamento distintos. Nível de Aplicação Inclui todos aqueles protocolos, serviços e aplicações implementados em cada nó da Internet que utilizam os serviços de transporte para fornecer funcionalidades adicionais. São transparentes à rede, ou seja, em toda a infra-estrutura de comunicação que interliga os nós não têm qualquer componente. Ex. SMTP, TELNET, FTP, DNS. A cada um desses serviços/aplicações é normalmente atribuído um porto específico de transporte (well known ports). 2.5. Redes Locais de Computadores São a tecnologia de comunicação mais relevante para a interligação de sistemas computacionais nas subredes. Foram um dos factores decisivos na evolução das arquitecturas centralizadas para distribuídas. A comissão 802 do IEEE liderou o processo e foi definido que apenas analisaria redes coma as seguintes características: - Com partilha efectiva do meio físico - Apenas os 2 primeiros níveis do modelo OSI - Com cobertura geográfica de 1 a 20km A comissão decidiu-se logo pela difusão em vez do ponto-a-ponto e pelas topologias em anel e bus em vez da estrela da comutação telefónica. 2.5.1. Controlo de problemas Acesso ao foi Meio de Comunicação Um dos primeiros a inadequação da subdivisão considerada no modelo OSI entre nível físico e de ligação de dados e a estrutura de controlo de trx. da maioria das redes de dados. O nível de ligação de dados é responsável pela partilha do meio físico, contudo é impossível definir uma máquina de estados eficiente para o nível de trama que fosse independente do modo como o envio de 1 bit se processava. Isto levou à criação de um subnível designado por Controlo de Acesso ao Meio – MAC. Multiplexagem na Frequência É a solução tradicional para multiplexar vários canais de comunicação num meio físico. São redes de banda larga. A desvantagem são o custo, complexidade do equipamento de modulação/desmodulação e a dificuldade da gestão dinâmica da atribuição das frequências num ambiente computacional, onde o estabelecimento de canais varia continuamente. Multiplexagem no Tempo Na TDM, o problema central a resolver é a forma como é controlada a partilha entre os vários emissores que querem trx. simultaneamente. Multiplexagem no Tempo: Síncrona
O tempo é dividido em intervalos de duração fixa, síncronos com um relógio central. Cada emissor dispõe de um intervalo de tempo prédefinido para colocar informação no meio. Ex. PCM – Pulse Code Modulation – sistema de trx. de voz digital. A sua utilização adapta-se bem à trx. de fluxos contínuos de informação, como voz ou vídeo. Multiplexagem no Tempo: Assíncrona Como os intervalos de tempo são assíncronos, é preciso um algoritmo que seleccione quem tem direito a trx.: - Aleatório - Passagem de testemunho - Controlo Centralizado O controlo aleatório baseia-se na reduzida probabilidade de dois emissores começarem, no mesmo instante, a trx. Na ausência de qualquer controlo determinista, a estação que pretende emitir fá-lo-á assim que detectar que o meio está livre. As outras detectam e aguardam. O problema surge quando 2 ou mais estações emitem antes de reconhecerem que há uma trx. em curso. Neste caso dá-se uma colisão e torna-se necessário implementar um mecanismo que a resolva. É a base da Ethernet. Para evitar a aleatoriedade existem métodos de controlo determinístico do direito de emitir, usando um testemunho lógico (token) que circula entre as várias estações de um anel lógico. As vantagens são que a rede pode ser mais facilmente modelizável e, portanto, os débitos podem ser assegurados através de uma gestão de prioridades adequada. As desvantagens são: alguma complexidade adicional para garantir o bom funcionamento do testemunho na inicialização e em caso de falhas; introdução de atrasos no acesso ao meio. Ex. token-ring da IBM e token-bus em automatização industrial. Finalmente, no controlo centralizado, há uma estação que se encarrega de inquirir (polling) às restantes se pretendem emi tir. Esta solução é simples mas do ponto de vista de fiabil idade e desempenho está fortemente dependente da estação central. A Ethernet é a mais utilizada, logo seguida da token-ring. Esta suporta melhor que a Ethernet a carga elevada, mas é mais cara. 802.3 802.4 802.5 802.6 Topologia Bus Bus Anel Bus duplo Método de Controlo Controlo Controlo Aleatório Acesso distribuído distribuído Distribuído Designação Ethernet Tokenbus TokenRing MAN/DQDB Comercial 2.5.2. Ethernet ServiuRede de base à norma IEEE 802.3. O seu sucesso ditou numerosas evoluções como a utilização de vários tipos de cabo coaxial, fibra óptica, aumento de vel. de trx., etc. Nível Físico A topologia de base é um bus e a vel. de trx. da norma srcinal de 10Mbps. também na srcem o suporte físico era o cabo coaxial limitado a 500m extensível a 1,5km através de repetidores. A evolução alargou ao par trançado e fibra óptica. Associada às arquitecturas de cablagem estruturada tem havido a tendência de usar cabos mais baratos (UTP e STP). Há especific ações para a qualidade dos cabos suportando a categoria 5 até 100MBps. É comum distinguir as tecnologias Ethernet por uma mnemónica B/Modo/D, com B-largura de banda (Mbps); Modo distingu e entre utilização em banda base ou modulação em frequência e Ddistância máxima de um segmento ou o tipo de cablagem, ficando a distância implícita. Ex. 10BaseT -> 10Mbps, banda base, 100m. A topologia em bus tem sido mantida do ponto de vista conceptual , mas a deinição dos sistemas de cablagem estruturada conduziu a soluções baseadas em concentradores (hyb) que agregam várias ligações Ethernet às máquinas. Neste caso o bus funciona conceptualmente dentro do concentrador – pseudo-estrela a partir do concentrador. Método de Controlo de Acesso ao Meio É por divisão no tempo assíncrono com controlo aleatório – CSMA/CD
Normalmente as funções de comunicação são implementadas por hardware: Após activação da recepção, o comunicador analisa o endereço de destino das tramas que passam no canal e recebe as que lhe são dirigidas ou as que têm o endereço de difusão. Para transmitir, o comunicador constrói a trama no tampão de trx., encapsulando os dados que lhe são fornecidos pelos níveis superiores. A partir deste momento, o comunicador escuta o tráfego no bus (carrier sense) e lança automaticamente a trx. quando detecta o canal livre. A colisão dá-se quando dois ou mais comunicadores interpretam o canal como estando livre. Isto deve-se ao tempo de propagação. O intervalo de tempo em que existe a possibili dade de colisão depende da distância e da velocidade de propagação do meio. As normas definem as características dos meios físicos assim como o comprimento máximo do bus, pelo que é possível tirar o intervalo de tempo para a situação mais desfavorável. Para detectar a colisão, a estação emissora escuta simultaneamente o bus para verificar se o sinal emitido não foi adulterado (colli sion detection). Se detecta colisão emite reforço de colisão; em seguida retira-se do canal e volta a tentar de novo passado um tempo. Para evitar situações ambíguas , em que algumas estações não detectam as colisões,os pacotes têm um comprimento mínimo de 64 bytes + preâmbulo, por forma a que a duração da sua trx. seja dupla do tempo máximo de propagação no cabo. Para evitar nova colisão na retrx., o comunicador espera um nº inteiro de slot-time, valor esse que é aleatório, de 0 a k. Se houver nova colisão k é duplicado e assim sucessivamente: Método Truncated Binary Exponential Backoff. Formato das Tramas 1- Preâmbulo de 64 bits (101010...1011) para sincronização dos relógios e delimitação física da trama 2- Endereços de 6 bytes cada 3- Campo tipo, na forma Ethernet, identifica o campo de dados aos níveis superiores, na 802.3 significa o tamanho do campo de dados 4- Dados – máximo de 1500 bytes - CRC (32 bits) 2.5.3. FDDI – Fiber Distributed Data Interface Foi concebida para ser usada como espinha dorsal (backbone) de grandes centros computacionais ou para interligação de redes locais. Nível Físico O meio de trx. é a fibra óptica multimodo. Há extensões para cabo coaxial, ou até mistura de pares trançados A norma prevê com anel fibra. duplo, permitindo a continuação da operação em caso de quebra de interligação entre 2 nós; no normal funcionamento operam em paralelo, com sentidos de circulação inversos. A distância entre estações pode ser de 2 km e a rede pode ter um perímetro de 200km. A configuração máxima prevê até 1000 estações -> redes metropolitanas. Método de Controlo de Acesso ao Meio É feito por um protocolo de testemunho temporizado, semelhante ao mecanismo de controle do token-ring da IBM e que também considera 4 níveis de prioridade. Para emitir, uma estação tem de estar na posse do testemunho. A mensagem circula no anel e é retirada quando retorna à estação emissora. Ao contrário do token-ring, o testemunho é libertado assim que a estação acaba de trx., devido Às dimensões. Os endereços são de 48 bits e o formato das tramas é semelhante ao do token-bus, enquadrando-se pois nas normas IEEE. 2.6. Interligação de Redes Nas redes de grande escala, o nível rede caracteriza o serviço oferecido, dado que é o nível que, do ponto de vista dos equipamentos de comunicação, define a funcionalidade do sistema de comunicação. Há 2 filosofias: Uma estabelece um circuito virtual, outra baseia-se numa aproximação sem ligação.
O nível de transporte pode negociar com o nível rede a qualidade de serviço pretendida, ficando assim, o nível de rede responsável pela criação dos mecanismos que assegurem a entrega fiável dos pacotes, garantam ordem de entrega e controlo de fluxo. Noutra aproximação (comunidade Internet), consider a-se que a diversidade de soluções para as subredes não permite uma solução eficiente que garanta a fiabilidade da rede, pelo que o controle dos erros, do fluxo e da sequencialidade devem ficar a cargo do nível de transporte, simplificando o nível de rede que ficará só responsável pelo encaminhamento. 2.6.1. Equipamento de Interligação Há conceitos ambíguos. A interligação das redes pode efectuar-se a diversos níveis do modelo. Se for só ao nível físico usam-se os repetidores que se limitam a copiar os sinais eléctricos de um segmento da rede para outro (ex. 2 segmentos de 1 rede Ethernet). Apenas podem ser usados entre redes físicas idênticas. A ponte (bridge) opera a nível lógico. Copia tramas de uma rede para outra. Como as tramas têm endereços pode fazer-se filtragem. Usam-se na hierarquização das redes locais (interligação de LANs). As razões para se interligar LANs são tráfego excessivo numa LAN que serve demasiadas estações de trabalho, por exemplo, quando se consideram SFD; distância demasiado grandes; gestão da empresa em departamentos; isolamento de faltas. Apesar da grande complexidade em interligar redes diferentes, a comissão propôs 2 coisas: A diferença essencial tema ver como é que a ponte conhece os endereços dos nós das redes que interliga. A proposta ponte transparente impõe memória interna na ponte, onde irá progressivamente registando os endereços dos nós e respectivas redes. No início difunde tudo. Outra proposta é as pontes com encaminhamento na srcem, em que o nó de srcem deve definir ele o encaminhamento da trama anexando à trama essa informação. Finalmente, a interligação no sentido mais abrangente efectua-se no nível de rede e é o encaminhador (router) ou gateways . gateway ou porta, é um termo genérico que se aplica quer a este tipo de interligação, quer ao software que compatibiliza protocolos de qualquer nível. 2.6.2. Rede X.25 Tem por base a filosofia do sistema telefónico. Visa a implementação de um serviço público para comunicação entre máquinas geograficamente distantes. as máquinas dos utilizadores interligamse à rede através de uma ligação ponto a ponto ao comutador da rede. Nível Físico O nível físico consiste na ligação ponto a ponto utilizando linhas analógicas ou linhas digitais. Nível nova Lógicoversão do HDLC, a LAPB (Link Acess Procedure) seria adoptada pela X.25. O Uma protocolo implementa controlo de fluxo, recuperação de erros e garante que o computador recebeu correctamente o pacote. mas não assegura que o comutador aceitou transmiti-lo, isso é a nível de rede. O formato é semelhante ao do SDLC, incluindo código detector de erros e um campo de controlo. As tramas são de 3tipos: informação, supervisão e não numeradas, a que correspondem funções diferentes do campo de controlo (nº seq. da trama e confirmação das já recebidas. Usa um protocolo de janela deslizante com 3 bits. Nível de Rede Esquema de funcionamento: Quando um DTE pretende comunicar, tem de estabelecer um circuito virtual – envio de pacote call-request. O destinatário se quiser estabelecer ligação envia callaccepted. Depois enviam pacotes de dados. Há regulação de fluxo e detecção de erros. Qualquer interlocutor podea terminar com de umserviço clear-request que deve ser confirmado. Para satisfazer necessidade datagrama, foi introduzido um mecanismos de fast select em que o pacote de call-request pode incluir 128 bytes de dados. O receptor pode recusar com um clear-request, estabelecendo-se assim a comunicação sem ligação. Endereços podem ter até 14 dígitos decimais. O X.25 ilustra a redundância funcional já referido no modelo OSI. Por exemplo o nível de rede e o de ligação implementam ambos o controle de fluxo.
As limitações de desempenho permitem prever que esta tecnologia será substituída pelo FrameRelay que dá um serviço mínimo que não oferece mecanismos de recuperação de erros e de controlo de fluxo, posicionando-se melhor para interligação de LANs, trx. pacotes até 1600 bytes sobre linhas com altas velocidades. 2.6.3. Rede IP A filosofia é bem diferente da X.25. Enquanto este pressupõe que a rede são os comutadores, aos quais se ligam os hosts, aquela pressupõe que os utilizadores possuem redes que pretendem interligar à rede global e que, para tal, dispõem de máquinas com capacidade de execução de protocolos. Os princípios básicos do IP são: - O serviço é sem ligação - O serviço é com base no melhor esforço - O endereço de um nó subdivide –se em 2 componentes: a identificação da subrede a que o nó se encontra ligado e a identificação do nó nessa subrede. - O encaminhamento é efectuado independentemente para cada pacote, pelo que todos devem ser endereçados. - A decisão de encaminhamento é feita com base no identificador da subrede de destino, com excepção dos nós com ligação directa a essa subrede que encaminham com base no endereço do nó. Endereços IP É constituído de forma hierárquica por um par
O nº de bits associado a cada elemento do par não é fixo, existindo 3 tipos de endereço – 3 classes: A, B e C. A razão prende-se com o nº de nós nas subredes. Qualquer organização com um endereço IP pode subdividi-lo para formar subredes internas. As subpartições efectuam-se sobre os bits menos significativos do endereço e dependem do tipo de endereço. Por ex. para um tipo B podem usar 16 bits (8 referenciam uma subrede e 8 o nó dentro da rede) Um endereço IP pode identificar uma máquina (netid=0) ou uma rede (hostid=0). Endereços de difusão têm todos os bits de hostid a 1. Como é hierárquico, uma máquina que tenha ligação a 2 redes tem 2 endereços. Um endereço IP não representa pois uma máquina mas sim um ponto de ligação. Problemas do endereços IP: - Se a máquina mudar de rede, torna-se necessário mudar o seu endereço e tabelas onde está - Se máquina tiver vários endereços usam a especificação de rede contida no endereço mesmo que outros caminhos fossemprotocolos mais eficientes. Os endereços IP têm 32 bits. Expls: 10.0.1.201 (classe A) 146.193.4.2 (classe B) 193.136.1.6 (classe C) 192.1.1.255 (classe C – endereço de difusão) Protocolo IP É de nível rede e é bastante simples. Implementa o encaminhamento através de tabelas fixas e um controlo de congestão com libertação de pacotes. a unidade é o pacote ou datagrama com cabeçalho, dados 8limitado a 64kbytes). IP pode fragmentar se subredes assim o exigirem. 0 8 16 31 Version
IHL Identification TTL
TOS
Flags
Protocol Source adress Destination Adress Options Internet Datagram Data
Total Lenght FragmentOffset HeaderChecksum Padding
3. INTERFACE DE COMUNICAÇÃO 3.1. Modelo da Comunicação Distribuída Os protocolos que vimos são fundamentais para comunicação eficiente e normalizada entre redes heterogéneas, mas é necessário incorporar a infra-estrutura de comunicação no modelo computacional, integrando as funções de comunicação no ambiente de desenvolvimento das aplicações. O MC tem de oferecer ao programador de aplicações uma visão coere nte dos objectos de comunicação e das funções que lhe estão associadas. A comunicação num AD é uma evolução da comunicação entre processos numa única máquina, correspondendo à troca de mensagens entre 2 processos. O MC é constituído por objectos de comunicação ou portos e por funções agrupadas numa biblioteca. É vulgar designar esta interface por API da comunicação. As interfaces permitem um pequeno grau de abstracção em relação aos protocolos de comunicação, mas continuam fortemente relacionadas com estes. Na maioria dos sistemas existe uma quase total correspondência entre os serviços oferecidos pelo protocolo de transporte e a interface. os protocolos de comunicação são, geralmente implementados no núcleo do SO. A interface de comunicação efectua as chamadas ao sistema necessárias para executar as operações do protocolo. A comunicação pode modelizar-se como a interacção entre um processo emissor e um processo receptor. a transferência é suportada por um canal, que não é mais que a abstracção dos mecanismos de transporte. a interacção efectua-se normalmente com o protocolo de transporte. O canal tem de ser representado por um objecto do MC. Para simplificar vamos designar estas extremidades por portos. Conceptualmente o canal pode ser considerado como a associação de dois portos. para que exista comunicação, esta associação tem de estabelecer-se, podendo ter uma forma duradoura no canal de ligação, ou apenas para uma interacção, no canal sem ligação. A informação trx. é a mensagem, devendo ser interpretada segundo um protocolo de elevado nível acordado entre produtor e consumidor. Idealmente, quando a qualidade de serviço do canal não pode ser mantida, deve usar-se o mecanismo de excepções que tem aqui uma maior importância face ao maior nº de falhas nos SD. É de notar que os SO podem ser diferentes. as interfaces utilizadas numa aplicação distribuída podem, portanto, ser diferentes consoante o SO. a garantia de capacidade de intercomunicação é dada pelo protocolo de transporte que implementa o canal. a portabilidade das aplicações é que fica prejudicada. 3.2. Caracterização da Interface 3.2.1. Canal Como ou Semé Ligação Na centralizada canal implementado por zonas de memória partilhada, normalmente no espaço de endereçamento do núcleo -> elevada fiabilidade. Num AD não é assim. O desempenho é também menor. Esta fiabilidade e desempenho devem ser explícitos para o programador para que este possa escolher a qualidade de serviço adequada à aplicação. a forma mais vulgar de traduzir o tipo de serviço de comunicação é a utilização de um canal com ou sem ligação: - Com Ligação – Antes da fase de ligação é estabelecido um canal entre os 2 processo interlocutores. O canal é normalmente fiável, bidireccional e com garantia de sequencialidade. - Sem Ligação ou Datagrama – O canal é conceptualmente estabelecido apenas para o envio de uma mensagem. Não oferece normalmente garantias de fiabilidade. O primeiro é preferível quando existe um fluxo contínuo de informação. A sua desvantagem é consumir recursos de forma permanente e de existir um tempo de latência significativo no estabelecimento do canal. O segundo adapta-se melhor à comunicação com múltiplos interlocutores, a mensagens de pequena dimensão (típicas dos sistemas cliente/servidor) e reduz o tempo inicial de latência. 3.2.2. Portos de Comunicação Para transferir informação os processo interactuam com um porto que representa a extremidade do canal de comunicação. Do ponto de vista do SO os portos são uma abstracção do mesmo tipo dos ficheiros e periféricos virtuais.
Os portos são objectos de interface entre o SO local e os protocolos de transporte, pelo que têm normalmente dois identificadores: um que o referencia localmente num dado SO e outro que o identifica na rede e que está associado ao protocolo de transporte. Os fabricantes e objectivos são diferentes daí a duplicação, mas há indirecção. O associado ao protocolo pode ser explícito na interface, obrigando a que o programador o conheça (ex: sockets) ou encapsulado por camadas que transparentemente efectuam a tradução (ex: Mach) Quando um porto é criado pode logo ser criada a associação entre o local e o de comunicação ou deixado par depois. Por ex. nos sockets a associaçã o é feita por uma função específic a (bind); a criação só devolve o local. Há os serviços de nomes que facilitam a vida aos programadores. Do elenco das operações associadas aos portos, fazem parte as funções de envio e recepção das mensagens e funções específicas para criar/eliminar um porto, associar um endereço de transporte e definir parametrização do canal. A funcionalidade depende do MC, do SO e do PT, sendo diferente consoante o canal é com ou sem ligação. No com ligação são necessárias funções para estabelecer a ligação, correspondendo a associar implicitamente os portos do emissor e receptor. Neste caso, como a ligação permanece estabelecida, os portos não são multiplexados; há que terminar uma ligação para se poder iniciar outra. No sem ligação, o porto receptor comporta-se como uma caixa de correio à qual se enviam mensagens e que, normalmente, tem capacidade para armazenar um determinado nº de bytes. O canal é neste caso estabelecido em cada mensagem. Como não existe ligação, o porto recebe mensagens de todos os processos que possuam o seu identificador. Naturalmente existem protecção com direitos de acesso. Na mensagem deve ser enviado o identificador do porto do emissor para que o destinatário possa estabelecer um canal de resposta. 3.2.3. Semântica da Função de Envio Conceptualmente transfere a mensagem do espaço de endereçamento do processo emissor até ao porto receptor. No tocante à sincronização, esta operação pode ter várias semânticas que se relacionam com a detecção de faltas na comunicação: - Assíncrona: a função copia a info para os tampões do protocolo de transporte e retorna depois de iniciar o envio. O processo emissor é desbloqueado assim que a função retorna do núcleo, mas não tem qualquer garantia que a mensagem chegou ao seu destino. - Síncrona: O processo emissor fica bloqueado até que o porto de destino confirme que recebeu a mensagem - Cliente/Servidor: O processo emissor fica bloqueado até areceber a mensagem A assíncrona é aparentemente mais eficiente. Contudo, hipótese de explorardeo resposta. paralelismo, criando múltiplos fluxos de actividade despoletado s por várias mensagens, conduz a numerosos problemas de sincronização. O tipo de programação é por eventos, diferent e dos paradigmas de programação a que estamos habituados e assim, é raro que o paralelismo seja convenientemente explorado. Se a comunicação remota for do tipo pergunta-resposta, a assíncrona não proporciona vantagem. Contudo se for essencialmente assíncrona ou unidireccional (FTP, Telnet) é interessante. O envio síncrono oferece garantia de que a info foi correctamente trx., mas não permite detectar qualquer falha na execução do serviço. a programação também é complexa para evitar interblocagens. A cliente/servidor é mais rica (procura garantir a execução da operação, assegurando que o processo só continua a sua execução quando recebe a mensagem de resposta do servidor (na ausência de faltas)) pelo que tem sido a base da programação do modelo cliente/servidor. Só que implica um conjunto de operações que naturalmente não existem no protocolo de transporte 3.2.4. Estrutura das Mensagens Pode ser estrutura individualizada ou apenas compostas por sequências de bytes de tamanho variável (byte stream).
Normalmente o sistema de suporte à comunicação não impõe uma formatação específica das mensagens. A imposição de formatos predefinidos na interface de comunicação é uma imposição do programador, sendo, em geral, evitada neste nível. Uma possível razão para impor uma estrut uração da mensagem no mecanismo básic o de comunicação prende-se com os mecanismos de suporte à heterogeneidade. 3.2.5. Semântica da Recepção É retirar a primeira mensagem existente no porto ou, caso nenhuma esteja presente, bloquear o processo. Se o servidor estabelecer simultaneamente canais com vários clientes, coloca-se o problema dos múltiplos pontos de sincronização (múltiplos portos, não pode bloquear num vazio). A existência de múltiplos canais relaciona-se com o modelo com ou sem ligação. Se sem ligação pode usar-se um porto para receber as mensagens de todos os processos. Mas neste caso não é possível estabelecer prioridades. Por esta razão é frequente os servidores criarem vários portos para as mensagens de tipo ou de interlocutores de classes diferentes. No com ligação, o porto fica associado ao canal, pelo que múltiplas ligações obrigam a múltiplos portos. A solução para ambos os caso é criar um mecanismo de recepção múltipla sobe um conjunto de portos. Um processo bloqueia-se até que um dos portos receba uma mensagem que lhe é destinada. Permite pois a um único processo ter vários portos. A função funciona como um comando com guardas lógicas que, quando uma delas se torna verdadeira, desbloqueia o processo. É frequente associar à primitiva de recepção uma temporização, associada com a comunicação remota, bidireccional, para o receptor não ficar indefinidamente bloqueado caso haja falha. A primitiva select dos sockets é um exemplo de uma função de recepção múltipla com uma temporização associada. A função de recepção também pode ser assíncrona (teste periódico ou associar a acontecimento assíncrono). 3.2.6. Paralelismo A sincronização das primitivas de envio e recepção de dados está fortemente relacion ada com o modelo de concorrência em termos de processos e tarefas. a necessidade de paralelismo colocase sobretudo na programação de processos servidores -< atender simultaneamente vários clientes. Uma forma de introduzir paralelismo no servidor é utilizar vários processos em paralelo. Isso obriga a partilha de estruturas de dados (memória partilhada e sincronização) o que obriga a programação delicada, porque reintroduz os problemas dos múltiplos pontos de sincronização. Um MC maisno adequado o modelopartilhadas. multitarefa com vários fios de execução concorrentecontinua que se sincronizam acesso aé variáveis Vantagens: O modelo de programação simples, pois o seu código é idêntico a um servidor sequencial, apenas com a introdução da sincronização no acesso a estruturas de dados partilhadas; permite explorar situações em que uma tarefa se bloqueia durante o serviço de um pedido; torna eficiente a partilha de dados e a sincronização entre as várias tarefas; tira partido de possíveis múltiplos processadores. 3.2.7. Faltas na Comunicação Podem ter numerosas origens. As mais frequentes são as devidas a quebra do canal de comunicação (rede física falhou, esgotamento de tampões para os dados). Nas interfaces de comunicação habituais não são introduzidos mecanismos suplementares de tolerância a faltas. essa evolução das interfaces é feita nos sistemas de Chamada de Procedimento Remoto (RPC) onde os mecanismos de suporte à comunicação asseguram a detecção e recuperação das faltas de comunicação. No ligação o protocolo de transporte é responsável por garantir o canal de estácom activo, podendo assinalar a sua quebra. No sem ligação é raroque o protocolo de comunicação transporte assegurar entrega fiável. Um segundo problema é a forma como as situações de excepção resultantes são trx. aos processos. a forma mais simples é através de um valor de retorno da execução da função que indique o estado da execução (utilizável em situações do tipo tentar enviar a um porto inexistente ou ocupado). Na trx. assíncrona isto não é possível, o que torna o problema mais complexo,
sendo necessário mecanismos intrínsecos do SO que permitem a execução de acções assíncronas. O Unix usa os signals, o VMS associa rotinas assíncronas ao envio das mensagens. isto é rudimentar. O Mach, por cada processo existe um porto para recepção de mensagens de excepção, reservando-se uma tarefa para o tratamento das excepções. 3.2.8. Difusão das Mensagens Simplifica a programação, por ex. no que toca a localização de uma entidade na rede, sincronização distribuída, replicação de dados, etc. Nas LANs é simples, nas de larga escala não devido ao grande nº de mensagens extra introduzidas. Devido ao interesse dos algoritmos baseados na difusão, foram propostos mecanismos de difusão mais restritos a grupos de portos. existe uma abstracção para representar o grupo de portos – têm nomes e podem ser criados dinamicamente. Generaliza-se no IPv6. Os protocolos com entrega fiável são designados de difusão atómica – são importantes nos sistemas de tolerância a faltas. Há também os de melhor esforço (IP, Chorus). 3.2.9. Alternativas de Implementação 3 formas de integração das funções de comunicação no modelo computacional de um SO multiprogramado: - Funções de E/S genéricas - Funções específicas dedicadas apenas à interface com os protocolos de transporte - Inclusão no mecanismo de intercomunicação entre processos do SO A primeira srcina problemas de normalização. O Unix ainda adoptou a interface dos sistemas de ficheiros, mas esta solução sofre de uma limitação importante, devido às operações disponíveis nas interfaces de E/S serem insuficientes face às necessidades dos protocolos de comunicação (ex. estabelecimento de ligação, parametrização ou recepção múltipla). A solução habitual é recorrer a uma forma de parametrização genérica (ex. ioctl do Unix) mas o estilo de programação fica pouco claro e susceptível de muitos erros. A alternativa biblioteca dedicada (solução simples) (ex. NetBios) que oferece interface coerente e esconde detalhes, não é genérica pois obriga a distinguir à partida comunicação local e remota, obrigando à reprogramação das aplicações. Os sockets do Unix são um exemplo da tentativa de compatibilização das funções de E/S, mas também houve que desenvolver funções específicas -> modelo híbrido. Uma outra visão considerava estender o IPC (Inter Process Communication) local para termos só uma interface. Mas há uma desvantagem importante: cada SO impõe uma estruturação própria das mensagens. Como nas redes se pretende ligar SO diferentes, a formatação imposta pelas mensagens do resultantes IPC torna complexo o transporte protocolos para outros Nos sistemas da evolução de SOCdos para SOD manteve-se a SO. distinção entre os mecanismos de IPC locais e interfaces de comunicação distribuída. No Unix V.4 há o IPC local e o TLI (Transport Layer Interface). O Mach e Amoeba são coerentes mas incompatíveis entre si, face ao que se referiu. Vamos estudar os sockets, o NetBios e o Mach. Os sockets são seguramente a interface mais divulgada e tendem a ser norma der facto nos sistemas abertos. O Netbios é representativo de uma biblioteca de interface desenvolvida para o ambiente DOS e que não procurou reutilizar a interface das E/S ou dos ficheiros. Finalmente o Mach IPC corresponde a uma abordagem integrada. 3.3. Interfaces de Sockets 3.3.1. Caracterização dos Sockets (Unix 4.3BSD) Os sockets propunham-se dar resposta a: -- Transparência Independência (remoto do protocolo (a interface) e local) - Compatibilidade (inserir-se na interface clássica de comunicação e E/S do Unix) Apresentam uma interface baseada nos descritores de ficheiros, permitindo a utilização por programas existentes como uma evolução dos pipes. Adicionaram-se funções específicas (criação de canais, ligação, gestão de nomes). a independência materializou-se na noção de domínio:
- Domínio Internet – Utiliza os protocolos TCP e UDP descritos no cap. anterior - Domínio Unix – Permite a comunicação entre processos numa única máquina, sendo semlhante aos pipes com nome - Domínio Xerox Na criação do socket, para além da definição do domínio, é especificado o tipo de serviço pretendido. Os tipos de sockets mais significativos são: - stream – canal com ligação, bidireccional, fiável e com garantia de ordem. a interface é do tipo sequência de bytes tal como nos pipes e ficheiros - datagram – canal sem ligaçãp, bidireccional, não sendo garantida sequencialidade, fiabilidade nem eleiminação de mensagens duplicadas. - sequenced packet – canal sem ligação, mas com envio síncrono que garante a entrega de mensagens - raw – acesso directo aos mecanismos de comunicação. No domínio Internet permite aceder ao nível IP Nem todas as combinações de domínio e tipo têm sentido. Os identificadores de transporte associados aos sockets são diferentes para cada domínio. No domínio Unix os nomes são caminhos de acesso, até 108 bytes; no domínio Internet, o identificador corresponde ao endereço de transporte dos protocolos UDP e TCP, descrito no cap. anterior. É composto pelo endereço IP da máquina (32 bits) e o nº de um porto de transporte codificado em 2 bytes. No domínio NS é 4 bytes para o NetId, 6 para o HostId e 2 para o porto. Os valores dos portos utilizáveis pelas aplicações encontram-se restringidos por razões de segurança e de eficácia. No Unix BSD: - Portos reservados: 1-1023 (para serv idores que normalmente existem em todos os sistem as – Ftp, Telnet) - Portos atribuídos dinamicamente pelo sistema: 1024-5000 (ex. clientes com canais com ligação) - Portos para servidores não privilegiados: > 5000 3.3.2. Criação de um Socket Os sockets, como os pipes são referenciados no SO por um descritor de ficheiro. int socket (int domínio, int tipo, int protocolo) Na criação de um socket não é indicado nenhum nome global, sendo devolvido pelo sistema um descritor de ficheiro aberto que, como sabemos, é local ao processo. Nesta fase, um socket é semelhante à extremidade de um pipe. para que o socket seja endereçável pelos restantes processos, é necessário associar-lhe um nome global. Esta associação é efectuada pela primitiva bind. int bind(int sockfd, struct sockaddr *nome, int dim) a função bind no domínio Internet, associa ao socket o endereço de transporte TCP ou UDP, ou seja, o endereço IP da máquina e o porto de transporte. O bind também pode ser utilizado pelos clientes para associarem ao seu socket um endereço Internet, por exemplo, para fixarem o porto remetente quando comunicarem em modo datagram. 3.3.3. Sockets com Ligação Antes de aceitar ligações, o servidor tem de indicar a sua disponibilidade para receber chamadas (primitiva listen) int listen (int sockfd, int maxpendentes) maxpendentes não limita o nº de ligações do servidor, mas apenas a fila de espera dos pedidos de ligação. A primitiva listen não é bloqueante, é a função accept que sincroniza o servidor com os pedidos de ligação, à chegada uma mensagem Quando aao ligação ébloqueando-o estabelecida,até o sistema cria de automaticamente umrequisitando outro socketuma queligação. ficará associado novo canal de comunicação, deixando livre o socket inicial para continuar a receber pedidos de ligação. O descritor de ficheiro correspondente ao novo socket é devolvido como parâmetro de saída da função accept. Esta primitiva tem uma semântica relativamente complexa, efectuando 3 operações: a sincronização na espera de ligação; a ligação com o socket do cliente; a criação automática de um novo socket que fica a ser a extremidade do canal no servidor.
int accept( int sockfd, struct sockaddr, *nome, int *dim); No lado do cliente é feito depois um connect e ambos fazem write e read vários. int connect (int sockfd, struct sockaddr *nome, int dim) A primitiva connect é idêntica à abertura de um ficheiro, tendo como parâmetro de entrada o nome do socket do servidor e devolvendo, em caso de sucesso, o descritor de ficheiro que ficou associado ao canal de comunicação. Nome especifica o endereço do socket do servidor e poderá ter sido codificado directamente. Há outras funções para o envio e recepção, que permitem parametrizações adicionais. Funções de Uso Geral Eliminam o problema da heterogeneidade nos valores inteiros e fazem a gestão de nomes. Comunicações Urgentes Há mecanismo especial (out of band). Utiliza-se um modificador no campo flag da primitiva send. Quando as info são enviadas por este canal é posicionado o signal SIGURG no processo servidor. a leitura tem de fazer-se utilizando recv com a flag MSG_OOB. Permite simulação da tecla delete remotamente. 3.3.4. Sockets Sem Ligação Na utilização dos sockets sem ligação ou datagrama, a interface é semelhante à das caixas de correio habituais nos sistemas de intercomunicação entre processos. Duas primitivas permitem enviar e receber mensagens: int sentto(int sockfd, char *mens, int dmens, int flag, struct sockaddr *destino, int *dim); int rcvfrom(int sockfd, char *mens, int dmens, int flag, struct *srcem, int *dim); Neste diagrama o cliente e servidor fazem socket e bind e depois vários recvfrom e sendto. ...
3.4. Interface de Programação NetBios 3.4.1. Estrutura de Base Na área dos computadores pessoa is, a comunicação foi particularmente relevante desde o início como forma de partilha dos ficheiros e de interligação dos sistemas a outros de maior complexidade. Existem diversos mecanismos de comunicação para redes de PC: - NetBios - Lan Manager - Netware - PC/NFS - Winsocket Apesar das significativas diferenças todas procuram oferecer uma interface de programação para aplicações distribuídas. O NetBios é interessante, porque corresponde a uma interface de comunicação amplamente divulgada. Considera que a rede local se baseia num meio partilhado que suporta difusão. Mas existem especificações para o adaptarem a diferentes protocolos de transporte como o TCP/IP. É realmente uma interface, não há um protocolo único existindo várias implementações para redes diferentes. Isto permite o transporte das aplicações. 3.4.2. Funcionalidade É habitual dividir a interface do NetBios em 3 tipos de comandos: - Serviço de nomes - Serviço de comunicação - Gestão Nomes Como em qualquer sistema de comunicação, o nível de transporte do NetBios usa endereços para identificar na rede os processos correspondentes. São compostos de 16 bytes, têm estrutura plana e são cadeias de caracteres. Há 2 tipos de nomes: nomes únicos (na rede local) e nomes de grupo (permitem difusão em grupo). São mantidos nas tabelas locais do NetBios e têm de ser explicitamente apagados. Comunicação com Ligação Designado como serviço de sessão, fornece transporte com as seguintes características: - Com ligação Preserva as fronteiras das mensagens -- Confirmação da recepção - Detecção de mensagens duplicadas - Garantia de ordem - Controlo de fluxo O modelo de programação baseia-se na execução pelo servidor de um Listen sobre um determinado nome. O cliente efectua um Call. Quando a ligação se estabelece, cada uma das aplicações interlocutoras recebe a notificação do estabelecimento de ligação e um identificador de sessão LSN (Local Session Number). É inteiro módulo 255. Como é habitual, este identificador é usado nas funções de Send e Receive para especificar uma dada sessão. A operação normal de Send é síncrona, implicando uma confirmação da máquina de destino. Há o Send-No-Ack que tem semântica assíncrona para as redes token-ring. Dados são limitados a 64Kbytes, havendo no entanto o Chain-Send para 128Kbytes. O Receive, como é habitual é síncrono. Para permitir recepção múltipla existe o Receive-Any sobre múltiplas sessões. Comunicação Sem Ligação Mensagens de tamanho limitado (512 bytes por omissão). Podem ser enviadas a nome único, grupo ou difusão. As primitivas são Send-Datagr am e Receive-Datagram e a semântica de envio
não é a habitual, dado que se o NetBios recebe uma mensagem para um dado nome em que não tenha sido feito um Receive, a mensagem é ignorada. O envio em difusão é Send-Broadcast-Datagram, havendo o Receive correspondente. 3.5. Interface de Comunicação no Mach 3.5.1. Conceito de Micro-Núcleo Nos micro-núcleos toda a comunicação se processa por transferência de mensagens entre processos, mesmo na invocação de funções do sistema operativo. O IPC é portanto muito genérico e com uma riqueza funcional que não existe noutras arquitecturas. Os micro-núcleos constituem um caso limite da utilização da comunicação entre processos como o elemento estruturador de toda a arquitectura do SO. Os SO, apesar de camadas são complexos e difíceis de evoluir e modificar. Então esta filosofia isola o núcleo que só faz: - Gestão de tarefas - Intercomunicação entre processos (IPC) - Interface com o hardware da máquina A funcionalidade habitual do SO é executada por processos em modo utilizador que comunicam entre si, usando os mecanismos de IPC do micro-núcleo. Como os processos são independentes (e concorrentes) podem ser reprogramados sem obrigar a recompilar o sistema. O mecanismo de chamada sistema é diferente nesta arquitectura, dado que é necessário que o processo utilizador e o servidor sistema troquem mensagens, não se tratando de uma simples mudança de contexto. As chamadas sistema são decomponíveis num envio de mensagem para o processo sistema que implementa a funcionalidade requerida e na recepção da mensagem de resposta. Para isto ser eficiente a intercomunicação tem de permitir a transferência de dados sem implicar numerosas cópias. Isto é similar a chamadas remotas de procedimento mas como são na mesma máquina são optimizadas. Também há que contemplar a segurança. 3.5.2. Mach Foi desenvolvido como variante do BSD que oferecia ao utilizador tarefas reais (threads). Na versão 3 a funcionalidade do BSD foi exportada para um processo servidor. A perspectiva básica do Mach é: - Um núcleo simples que suporte a comunicação - Objectos do sistema são identificados e associados a canais de comunicação - Um modelo de comunicação cliente/servidor usando IPC síncrono e assíncrono - Tarefas que se executam em modo utilizador e que implementam a maioria das operações do SO clássico elementos do de MCreserva relacionam-se com do estes conceitos: -Os Task – unidade de recursos sistema (espaços de endereçamento, portos). É como o processo - Thread tarefas reais que se assemelham a processos simplificados que se executam no interior de uma task - Memory Objects – unidade de gestão do espaço de endereçamento no Mach. Corresponde a um bloco contíguo de páginas (de memória virtual) com um identificador próprio (evolução dos segmentos do Unix) - Portos – objectos de comunicação - Mensagens Os conceitos relevantes no sistema do IPC são os portos e as mensagens. Um porto é um objecto do núcleo que representa uma extremidade de um canal de comunicação. São equivalentes a caixas de correio. Apenas uma tarefa pode ter num dado instante o direito de receber mensagens num determinado porto. O envio de um porto numa mensagem confere ao receptor da mensagem direito de envio para que este possa ao responder. Cada objecto conhecidoono sistema tem associado um porto, qual podem ser enviadas as mensagens respeitantes à sua utilização. Os portos são assim simultaneamente os objectos de comunicação, mas também o sistema de designação das entidades do núcleo. Os portos são um conceito inovador. O conhecimento de um porto permite comunicar com o objecto, independentemente da sua localização podendo ser trx. nas mensagens e mantido nas estruturas
de dados voláteis ou persistentes. Apesar da implementação diferente desempenham uma função conceptualmente semelhante aos URL da Web. As mensagens são estruturas tipificadas que descrevem para cada campo qual o tipo de dados que é trx.. São compostas por um cabeçalho e um nº variável de campos tipificados. O cabeçalho contém o porto de destino, o remetente para onde deve ser enviada a resposta e o tamanho da mensagem. Cada bloco de dados da mensagem pode ser constituído por dados tipificados, portos ou referências para objectos de memória. A tipificação resolve os problemas de heterogeneidade, mas é sobretudo útil para identificar as referências ou apontadores para objectos de memória e para a trx. de portos, permitindo que o núcleo controle a sua trx. entre tasks. A passagem de apontadores evita múltiplas cópias, até em redireccionamentos do núcleo. É necessário definir a semântica da utilização da informação transferida. No Mach é copy-onwrite, mas faz-se só mapeamento, sendo as páginas apenas duplicadas quando escritas. O envio e recepção de mensagens é efectuado por uma função única, o mach_msg que tem estrutura complexa com 7 parâmetros. A semântica de envio pode ser assíncrona ou cliente-servidor e há o prt set para permitir recepção múltipla. Uma tarefa que receba de um conjunto de portos bloqueia-se até que um dos portos receba uma mensagem. Em conjuntos de máquinas que tenham como sistema o Mach, o IPC permite a intercomunicação entre processos que se executam em máquinas diferentes. esta funcionalidade é proporcionada por um processo servidor, o NetMsgServer. Ele efectua a correspondência entre identificadores locais e remotos, duma forma transparente.
CAP. 4 – PROCEDIMENTOS REMOTOS 4.1. Introdução ao Modelo O modelo Cliente/Servidor pode ser implementado directamente sobre a interface de mensagens que vimos. Contudo, apesar de ser uma interface intuitiva, a sua ligação ao modelo de programação das linguagens procedimentais é delicada, devido à semântica totalmente diferente das interacções. As mensagens são normalmente enviadas assincronamente e pressupõem fluxos paralelos de actividade; as linguagens procedimentais consideram o simples fluxo de actividade que sincronamente chama funções. O modelo de mensagens é também pouco transparente para o programador habitual, expondo os mecanismos de transporte (endereçamento, formatação das mensagens, tratamento da heterogeneidade). Então associou-se ao modelo cliente/servidor uma metodologia de programação distribuída baseado na Chamada de Procedimento Remoto. O RPC consiste numa generalização deste mecanismo que visa permitir uma transferência de controlo e dados entre espaços de endereçamento disjuntos quer residentes na mesma máquina, quer em máquinas distintas. A interacção do tipo pergunta-resposta, implícita no RPC, permite simplificar alguns dos requisitos de fiabilidade dos níveis de comunicação inferiores, tornando possível a utilização de protocolos de transporte sem ligação. Antes de utilizar o servidor o cliente deve estabelecer uma ligação com ele. Este binding pode incluir várias operaç ões: localização do servidor, normalmente usando um serviço de nomes; estabelecimento de um canal de transporte; autenticação do cliente e/ou servidor. Depois o cliente invoca uma operação remota no servidor e envia-lhe a info. necessária. A mensagem contém a identificação do procedimento remoto e os respectivos parâmetros. Do lado do servidor é ao contrário... Os requisitos de desempenho são também diferentes. Um servidor deve poder processar simultaneamente várias invocações remotas, pelo que a sua estrutura interna deve basear-se num mecanismo de multiplexagem de fluxos de actividade, normalmente usando tarefas. Uma evolução possível deste modelo é a existência de múltiplos servidores idênticos. Numerosos projectos de I&D propuseram abordagens diferentes para arquitectura e implementação dos sistemas RPC (ex: Sun-RPC, Dce) e existem diversos esforços de normalização. A noção de RPC é uma abstracção lógica, dado que, quando o cliente invoca uma operação, chamando aparentemente a função definida no servidor, na realidade está a efectuar uma chamada a um procedimento local que se encarrega de iniciar a invocação remota. estes procedimentos, que designaremos por rotinas de adaptação (stub routines), têm um papel preponderante na arquitectura do sistema. No lado do cliente é responsável por converter e empacotar os parâmetros numa forma apropriada para a trx.; enviar a mensagem para o servidor usando um serviço de transporte; esperar pela resposta do servidor. Quando esta é recebida desempacota os resultados, convertendo-os para a representação local. Do lado do servidor, a rotina de adaptação tem a função simétrica. A ambição é a total transparência em relação ao modelo de programação habitual, podendo idealmente desenvolver-se uma aplicação de forma independente da rede ou máquinas que a irão suportar. assim, o RPC deve estar transparentemente integrado no ambiente de programação. A transparência total é difícil e podemos dividi-la nos aspectos: - Sintaxe da linguagem de programação - Passagem de parâmetros - Semântica de execução do procedimento - Desempenho O primeiro é relativamente fácil de obter. A forma de especificação dos procedimentos remotos baseia-se numa linguagem de descrição de interfaces ou IDL inspirada no C, Pascal e C++ a que são acrescentadas algumas palavras-chave. A passagem parâmetros vários problemas definição do RPC: heterogeneidade dos tipos de dadosdeem máquinas levanta diferentes; passagem por na valor ou referência. a primeira é um dos factores limitativos da transparência. O compilador terá de introduzir no código das rotinas de adaptação as chamadas às funções de conversão, de acordo com um protocolo de apresentação.
A passagem por valor é simples pois sabendo o servidor e cliente o tipo dos dados, basta reservar memória de acordo; ao contrário da passagem por referência pois os espaços de endereçamento são diferentes. A transparência na semântica de execução do procedimento é mais complexa, porque as diferenças introduzidas no modelo de faltas e pela intervenção de máquinas distintas não podem ser totalmente escondidas, vindo a reflectir-se na fiabilidade das aplicações. É necessário um protocolo. O desempenho é naturalmente muito diferente, e será sempre apesar da evolução. 4.2. Especificação da Interface dos Serviços As linguagens de especific ação de interfaces são uma versão simplificada de uma linguagem de programação, dado que apenas necessitam da parte declarativa das linguagens. A linguagem IDL possui palavras-chave para fornecer indicações na definição dos serviços: identificação do serviço; versões; semântica desejada, etc. Faz parte dos sistema RPC uma espécie de compilador com entrada a especificação da interface e gera as rotinas de adaptação para o cliente e servidor. a saída é em C ou Pascal que devem ser novamente compiladas e ligadas às aplicações. Na declaração dos parâmetros, é necessário eliminar as ambiguidades na definição do tipo de dados. IDL é enriquecido pois C é muito permissivo. A passagem por referência obriga a copiar a estrutura referenciada no cliente para a mensagem e no servidor a reserva dinâmica da memória para onde será copiada. Há problemas com a passagem de apontadores, vectores, strings e ainda mais listas e árvores. É denotar que na programação em linguagem C, os apontadores são um mecanismo a que os programadores associam grande eficiência, sendo o contrário no mecanismo de RPC (reserva dinâmica de memória, cópia dos dados, validação dos apontadores, etc.). Mais difícil ainda são os rings e listas circulares, que não têm o NULL. Situações deste tipo têm de ser resolvidas pelo programador e não pelo compilador RPC. ex. do banco... 4.3. Arquitectura do Sistema de RPC 4.3.1. Suporte de Execução do RPC As rotinas de adaptação estabelecem a interface entre o código das aplicações e os protocolos das redes, mas, como é natural, recorrem a uma biblioteca de funções para todas as operações de base do sistema de RPC. As funções de biblioteca suportam todos os mecanismos genéricos do funcionamento da chamada remota: inicialização do servidor e registo do nome dos serviços no servidor de nomes; protocolo de ligação entre o cliente e o servidor; conversão de dados, controlo da semântica chamada e a Também ligação aos mecanismos de envio e recepção das mensagens doda protocolo de remota transporte. incluem funções para tratamento de excepções e erros. a biblioteca de funções com as respectivas estrutura de dados globais constitui o ambiente de suporte (run-time) à execução do RPC que será carregado em memória com a aplicação distribuída. As principais funções do sistema de suporte são: Um servidor tem uma fase de inicialização em que estabelece o seu ambiente de comunicação: - Criar os portos de comunicação. Nesta fase definem-se os protocolos (família de protocolos, com e sem ligação, etc.) - Associar ao porto um procedimento de despacho/rotina de adaptação – agulha mensagens recebidas para a rotina do serviço com base num identificador de procedimento presente na mensagem - Registar o serviço no servidor de nomes – a identificação do serviço, o protocolo e os respectivo endereço do porto. - Invoca umaao rotina que otem bloqueia à espera da recepção de mensagens. A ligação do cliente servidor os seguintes passos, desencadeados pelo cliente: - Obter o endereço do porto do servidor através do serviço de nomes - Executar o protocolo de ligação (binding) que cria os canais de comunicação e poderá eventualmente tratar de aspectos de autenticação. A invocação remota de um serviço pode decompor-se em 3 protocolos: - Apresentação – trata da conversão de formato de dados internos para a trx.
- Controlo da invocação – trata das faltas de comunicação ou das máquinas - Transporte As rotinas na biblioteca de suporte do RPC suportam as diversas etapas dos protocolos que podemos resumir da seguinte forma: Cliente: - Conversão dos parâmetros de entrada e construção da mensagem - Envio da mensagem, bloqueando-se a aguardar resposta Servidor: - Recepção da mensagem - Invocação da rotina de despacho - Conversão dos campos da mensagem nos parâmetros da rotina invocada - Chamada ao procedimento interno do servidor - Conversão dos parâmetros de saída e construção da mensagem de resposta - Envio da mensagem de resposta Cliente: - Recepção da mensagem - Conversão dos campos da mensagem para os parâmetros de saída Esta descrição pressupões que não há faltas. Numa visão mais próxima do modelo OSI, dizemos que o protocolo de RPC engloba o nível de sessão – na abertura e fecho de ligações; de apresentação – no tratamento de heterogeneidade; aplicação – parte específica dos serviços. CódigodoCliente Rotinas de adaptação Biblioteca de suporte Transporte dos dados
Protocolo de Apresentação Protocolo de Controlo Protocolo de Transporte
Códigodoservidor Rotinas de adaptação Biblioteca de suporte Transporte de dados
4.3.2. Ligação Cliente – Servidor O cliente antes de efectuar uma chamada remota precisa de saber: - O protocolo de transporte - Endereço da máquina (nesse protocolo) onde se executa o servidor - O identificador do porto a que está associado o servidor Conceptualmente a ligação pode ser efectuada explicitamente, implicitamente ou de forma automática na RPC. Esta última apesar de mais simples para o programador raramente se usa pois aumenta a latência da chamada e não permite certas sofisticações em que um serviço se executa em múltiplos servidores. No Sun-RPC é explícita, no DEC há 2 alternativas. Genericamente podemos considerar os seguintes passos no protocolo de ligação: - Localização do servidor - Autenticação - Estabelecimento de uma sessão Localização Há várias formas. Uma solução imediata consiste em codificar directamente o porto do servidor no programa cliente, o que é um bocado inflexível, tornando-a pouco interessante. Uma alternativa é utilizar um ficheiro onde são registados os nomes e endereços dos servidores, mas a actualização dos ficheiros é trabalhosa e susceptível de se tornar inconsistente, pelo que apenas se utiliza para registar alguns serviços fundamentais (well-known) que devem estar presentes na inicialização do sistema. A aproximação mais geral é a utilização do Serviço de Nomes. O servidor de nomes tem um endereço bem conhecido que permite localizá-lo na inicialização. Como o servidor regista os seus serviços no Serviço de nomes. Na definição dos serviços, coloca-se o habitual problema da designação de um tipo de serviço de forma abstracta ou da sua instanciação num dado servidor. ex. serviço de impressão. Por vezes o cliente apenas está interessado em obter um serviço de um determinado tipo, noutras pretende seleccionar a instância. alguns sistemas de RPC efectuam a distinção permitindo escolher a forma de ligação. Outros, como o Sun-RPC, não dissociam a interface da sua instanciação obrigando o cliente a conhecer antecipadamente a máquina onde quer efectuar o
serviço. No DCE, as interfaces têm nomes universais (UUID) e, portanto, o nome é independente da localização. No caso de existirem vários servidores é devolvida uma lista para o cliente escolher. Há gestões de nomes que permitem ao utilizador escolher segundo critérios geográficos, por ex. Situação mais complexa é quando a interface é igual mas as instâncias de dados são diferentes (ex. serviço bancário com contas diferentes ou servidor de impressão com impressoras diferentes). Estes casos resolvem-se a nível da aplicação criando servidores que conhecem a localização dos objectos e indicam qual a máquina que o cliente deve ligar-se. No DCE este problema é resolvido pelo próprio mecanismo de ligação que permite especificar os objectos. Autenticação Quando se estabelece a ligação o cliente deve indicar a sua identidade para que o servidor valide os direitos de acesso. A autenticação levante enormes problemas devido às ameaças de segurança (escutas, modificações de mensagens). Isto é tratado por protocolos de autenticação que podem ser incluídos na maioria dos protocolos de RPC. Estabelecimento da sessão No final do protocolo de ligação, o cliente tem de registar a informação sobre o servidor que utilizará nas chamadas seguintes. o processo conduz ao preenchimento de uma estrutura de dados que funcionará como identificador da sessão (binding handle). Por exemplo criando um socket e registando a sua referência. Do lado do servidor, o estabelecimento da ligação poderá ou não dar srcem à criação de uma estrutura de dados que fique a referenciar o cliente. A estrutura alternativa é o servidor sem estado, que tem a vantagem de tornar o servidor independente dos clientes fazendo com que possa ser reinicializado sem precaução alguma, isto nos canais sem ligação. O identificador de sessão pode aparecer explicitamente como parâmetro das funções de adaptação ou ser escondido no suporte de execução e utilizado implicitamente. No Sun são sempre explícitas. No DCE pode optar-se por 3 hipóteses: - Explícita – obriga a estabelecer a ligação chamando as rotinas de biblioteca, de que resulta o preenchimento de um binding handle que deve ser passado como primeiro parâmetro para as rotinas de adaptação. - Automática – o cliente não efectua explicitamente a ligação, sendo esta transparentemente despoletada pela invocação de uma chamada remota. - Implícita – solução intermédia em que se efectua a ligação de forma explícita, mas a informação da estrutura de ligação é mantida em variáveis globais no suporte do RPC, evitando passá-la como parâmetro. Isto dá ao programador a possibilidade de escolha entre um mecanismos simples e um complexo mas que permite criar políticas de interacção mais sofisticadas (múltiplos servidores, segurança) 4.3.3. Semântica da Execução Modelo de Faltas Num ambiente local a percepção da falta é relativamente óbvia: o processo aborta, a máquina pára, etc. Num ambiente distribuído há mais causas: - Perda da mensagem inicial do cliente - Perda da mensagem no interior do servidor - O servidor falha - Perda da mensagem de resposta do servidor -AOforma cliente aborta como o protocolo RPC recupera das faltas define a semântica de execução da chamada remota. Idealmente devia ser igual a local mas isso não é atingível. Só interessa tratar as faltas que comprometem a oferta do serviço e que têm elevada probabilidade de ocorrer. As outras são erros ou catástrofes. O RPC só trata as primeiras. As faltas de comunicação são as mais prováveis.
As perdas de mensagem no nível de transporte podem ser eliminadas com um transporte com ligação, mas isto tem o tempo de latência. As faltas por paragem nas máquinas são mais complexas de tratar porque obrigam a manter o estado volátil. Não são normalmente tidas em conta no modelo do RPC, sendo tratadas nos sistemas de tolerância a faltas do tipo transaccional. Recuperação das Faltas Tem de se usar um temporizador, se não as faltas nunca mais eram detectadas, para libertar o processo cliente. Mas isto não recupera a falta, o que limita a transparência. esta semântica é do tipo talvez (may-be). talvez se tenha executado talvez não, e pode ser adequada a redes com diminutas taxas de erros ou que prefiram optimizar o desempenho em detrimento da fiabilidade. A solução habitual é reenviar a mensagem de invocação. Mas como o cliente não consegue discernir entre uma perda de trx. ou demora do servidor, é possível que o servidor receba a invocação em duplicado. É a semântica de pelo-menos-uma-vez (at-least-once). Isto não é o que se espera e em algumas aplicações pode ser perigoso (actualização de contas bancárias). Para garantir o funcionamento correcto com esta semântica o servidor deve apenas oferecer funções idempotentes. Uma semântica que se aproxima mais do habitual em modo local é a no-máximo-uma-vez (atmost-once). Aqui é necessário filtrar as mensagens duplicadas, pelo que estas têm de ter um identificador e o servidor tem de ter uma tabela com a identificação das operações em curso. O cliente e o servidor devem manter as mensagens, respectivamente de invocação e de resposta até que estas seja confirmadas. É a mais habitual em sistemas comerciais. O problema de garantir a semântica exactamente-uma-vez advém da impossibilidade de se o servidor falhar saber exactamente o seu estado. São necessários mecanismos do tipo transaccional que permitam manter o estado volátil da execução das invocações remotas. Protocolo de Controlo Um dos seus objectivos é garantir a semântica da execução e optimizar o desempenho, tendo em conta a relativamente conhecida natureza da interacção entre cliente e servidor. O protocolo de transporte com ligação mascara algumas faltas, como vimos, simplificando o protocolo de controlo. Mas para interacções esporádicas o tempo de latência sobrepõe-se ao de trx. Uma solução é a definição de protocolo de RPC que implemente todos os mecanismos de controlo necessários sobre um transporte mínimo sem ligação e sem fragmentação. Um dos mais conhecidos é da Xerox. Implementa a no-máximo-uma-vez e tenta minimizar o nº de mensagens trocadas, que no caso ideal podem ser apenas 2. para além do identificador de procedimento a invocar e dos argumentos, é enviado na mensagem de invocação um identificador de chamada, que permite cliente eassegurar-se do correcto emparelhamento entreO aidentificador mensagemdede invocação e deaoresposta ao servidor filtrar os pacotes resultantes de retrx. chamada tem 3 campos: - Endereço da máquina cliente - Identificador do processo cliente - Nº de sequência (CallID) O par dos 2 primeiros forma uma actividade. O servidor mantém tabela de actividades, rejeitando mensagens duplicadas. O servidor não pede confirmação imediata da resposta pois sabe que haverá interacção futura e, nessa altura (próxima mensagem) o cliente confirmará. Por outro lado como o protocolo de transporte não efectua a fragmentação, existe a possibilidade de os dados e enviar excederem a dimensão de um pacote. Como assumimos um protocolo de transporte datagrama, este é um dos problemas a ser resolvido pelo protocolo de controlo. Neste caso, os dados são enviados em pacotes sucessiv os, tendo o servidor que confirmar a recepção antes do envio do próximo. Desta forma garante-se a ordem correcta de recepção. 4.3.4. Protocolo de Apresentação de Dados Na conversão dos dados para um formato coerente no sistema distribuído, colocam-se 2 problemas: a descrição do tipo de dados para evitar ambiguidades na conversão e o protocolo que define o formato para a trx. No esforço de normalização OSI, a ASN1 é uma notação abstarcta, independente de uma linguagem; a norma 8825 define a transfer syntax.
Na maioria dos sistemas RPC evitou-se a estruturação em 2 níveis, usando a linguagem de definição das rotinas de interface como especificação dos tipos de dados. Para trx. é preciso protocolo. Há 2 soluções: - Explícita – para cada bloco de dados é colocado na mensagem um descritor (tag) que identifica o tipo - Implícita – Na mensagem vão só dados e existem convenções para cada tipo de máquina. O primeiro método é simples mas obriga a construções complexas das mensagens. No contexto OSI e no Mach foi adoptado o ASN para transfer syntax. O tratamento implícito tem 2 variantes. A mais vulgar é considerar que existe uma forma canónica de trx. que deve ser usada em todas as mensagens. É de fácil gestão mas pode obrigar a conversões duplas e desnecessárias se as máquinas comunicantes forem do mesmo tipo. O Sun usa esta solução. A alternativa é enviar os dados na forma como estão representados na máquina de srcem, incluindo na mensagem uma identificação do tipo de máquina. é óbvio que esta solução é de gestão mais difícil. 4.4. Implementação e Desempenho 4.4.1. Tarefas nos Servidores Um servidor tem normalmente de servir pedido s de vários clientes. O paralelismo vem da conjugação de múltiplos canais e utilização de tarefas. Como é natural, na programação das rotinas do servidor tem de se ter em conta o paralelismo introduzido pelas tarefas, utilizando mecanismos de sincronização para a definição de secções críticas, gestão de recursos ou algoritmos de cooperação entre tarefas independentes. No servidor é criado, na inicialização, um certo nº de tarefas que se bloqueiam à espera de pedidos. No entanto, este nº depende do paralelismo possível no servidor, não adiantando ter demasiadas tarefas, porque elas se bloqueariam à espera de recursos partilhados. Realizações mais sofisticadas criam dinamicamente tarefas. No cliente também pode haver paralelismo, dedicando uma tarefa para cada invocação remota. Uma tarefa para invocar outra para receber as respostas. Em termos de semântica levanta-se um problema com a ordem de recepção dos pedidos do lado do servidor, o que em certas aplicações pode ser grave e uma posterior pode ultrapassar outra que se bloqueou. A sincronização simples das tarefas não é suficiente, pois a sequência de operações receber o pedido, sincronizar para estabelecer a ordem não é atómica. Uma solução adoptada no Mach IPC é associar um nº de ordem a cada mensagem recebida. Se uma verificar que está fora de ordem bloqueia-se à espera da sua vez. 4.4.2. Chamada Há situações emem queRicochete o servidor, para processar um pedido, necessita de aceder a um segundo servidor que pode ser o cliente. Este caso denomina-se chamada em ricochete (callback). esta situação pode repetir-se e há, como na recursividade, uma profundidade dos ricochetes que é limitada. Do ponto de vista da biblioteca do RPC, esta situação requer que qualquer servidor possa ser cliente (fácil) e qualquer cliente possa ser servidor (difícil). O cliente tem de registar as chamadas em ricochete que quiser tratar, efectuando para isso um procedimento idêntico ao de um servidor quando regista um serviço no servidor de nomes. Nas bibliotecas que suportam múltiplas tarefas é simples bastando criar uma nova tarefa para processar o pedido. O Sun-RPC utiliza um select no cliente para esperar pela mensagem de resposta, o que lhe permite também receber pedidos de invocação enviados noutro canal. Note-se que a existência de chamadas em ricochete faz com que o código no cliente seja concorrente, pois, enquanto ele está bloqueado à espera de uma resposta, há um fluxo de execução quericochete vai processar ricochete, que jáa detido sincronização se torna complexa. Se a chamada em tentaroadquirir um pelo recurso pelo cliente há uma interblocagem (deadlock). 4.4.3. Desempenho O desempenho de um sistema RPC é crucial, o que originou muita pesquisa. Pode ser decomposto em 2 factores:
- Estabelecimento da ligação com o servidor - Latência de uma chamada simples O primeiro pode ter importância determinante se o cliente apenas efectua uma interacção com o servidor. Este é um dos argumentos na defesa da utilização de protocolos de transporte simples, sem ligação. A execução de um RPC simples tem as seguintes componentes temporais: - Tempo de conversão e empacotamento dos parâmetros de entrada e saída no cliente e no servidor (uns são mais flexíveis outros mais rápidos) - Tempo de execução do SO (Mach e Amoeba enviam pedido e esperam resposta logo evitando chamadas separadas e mudanças de contexto e interrupções) - Tempo de trx. das mensagens (normalmente não é determinante) RPC Local Um caso particular de optimização é o RPC local em que tanto o cliente como o servidor se executam na mesma máquina (Mach, Chorus, Windows NT). O desempenho local é determinante para o desempenho global do sistema. Existem várias técnicas de optimização. A passagem de parâmetros pode fazer-se por intermédio de uma região de memória partilhada entre o cliente e o servidor, evitando-se assim cópias adicionais dos dados. Há uma outra técnica (hand-off) que é extremamente eficiente porque o servidor executa a parte do código que necessita de privilégios especiais, mas é entendido como uma extensão do cliente; o cliente oferece o seu contexto ao servidor, havendo apenas transferência do espaço de endereçamento para o do servidor apenas alterando os registos que definem esse espaço de endereçamento. No retorno a mesma técnica é usada para devolver o controlo ao cliente, mantendo a prioridade e o quantum. Os sistemas comerciais (Sun-RPC e DCE) por terem se ser gerais e portáteis, privilegiam normalmente a flexibilidade e generalidade em detrimento do desempenho. Os sistemas experimentais, pelo contrário, usam técnicas mais agressivas de optimização.
CAP. 5 – GESTÃO DE NOMES 5.1. OBJECTIVOS DA GESTÃO DE NOMES O que é importante é a definição, propriedades, funcionalidade e respectiva arquitectura do serviço, que na maioria das vezes aparece agregado a outras componentes do sistema. Os nomes são fundamentais para identificar, localizar e partilhar os objectos. Nos SO são ainda indispensáveis para simplificar a interface com o utilizador e gerir os recursos informáticos. No âmbito dos SO têm um conteúdo semântico simples, representando uma associação (binding) entre um nome e um objecto sob controle do sistema (servidor, máquina, utilizador, ficheiro, impressora, etc.). A gestão dessas associações é o objectivo principal do serviço. Os nomes identificam as entidades ou objectos sob controlo do sistema, de forma a que seja possível discriminá-los – identificadores. A localização pode fazer interagir vários serviços de nomes nas camadas hierárquicas que constituem o sistema distribuído, até obter um identificador cuja resolução (em geral pelo hardware) permita o acesso físico ao objecto. Para que utilizadores e programadores partilhem recursos comuns os nomes devem ser uniformes e normalizados. Praticamente todos os mecanismos de comunicação pressupõem a existência de um serviço de nomes para estabelecer a ligação. Esta característica implica que os nomes possam ser transmitidos entre máquinas e SO heterogéneos. São também indispensáveis na criação de mecanismos de interface do sistema com os utilizadores. Mas têm de ser lógicos (inteligíveis e mnemónicos) e não físicos. Simplificam também a gestão do sistema por mecanismos de indirecção que permitem alterar transparentemente a correspondência entre os nomes e os objectos. A distribuição reforça a utilidade da gestão de nomes pelas numerosas entidades que é preciso designar e partilhar (endereços, nomes de máquinas, servidores, discos remotos, etc.) 5.2. CONCEITOS DE BASE Os nomes são definidos num espaço de nomes que caracteriza a sua estrutura. Este espaço pode ser visto como um conjunto de regras que define os nomes admissíveis. Um conjunto de associações pertencentes a um determinado espaço de nomes será designado por contexto correspondendo a uma visão parcial ou total das associações existentes. Esta noção de contexto pode materializar-se numa tabela, ou conjunto de tabelas, que suporta o registo das associações e que permite a resolução dos nomes – directório. A organização pode ser hierárquica pelo que pelo que os contextos podem ter referências para outros contextos. Como os sistemas são hierárquicos, a resolução pode necessitar de um conjunto de passos. Frequentemente, um objecto tem associado mais que um nome. Os nomes são simbólicos isto é, ée usado como referência ou eloo de ligação (link) para um outro nome no mesmo espaço de, nomes não referencia directamente objecto. 5.3. ESPAÇO DE NOMES As regras condicionantes reflectem as propriedades que se pretende que os nomes apresentem. 5.3.1. UNICIDADE REFERENCIAL É uma propriedade importante e traduz que num contexto, um nome não pode estar associado a dois objectos distintos. A operação de registo de um nome tem de ser autorizada por uma entidade que detém o controlo sobre um dado espaço de nomes ou sob um contexto, autoridade essa que tem a responsabilidade de gerir o recurso que suporta a implementação do objecto. 5.3.2. ÂMBITO DE UM NOME Classificação da organização da gestão de nomes: - Global (nome absoluto) – Um nome tem o mesmo significado em qualquer contexto do sistema onde o espaço de nomes é válido. - Local (nome relativo) –O contexto apenas engloba uma parte limitada do sistema (ex. máquina, processo), não sendo válidos fora do contexto onde são criados. A dificuldade de implementar um sistema de nomes globais advém da dimensão do sistema. Há várias soluções: - Centralizar numa única entidade a atribuição de nomes -> maior latência e ponto singular de falha
- Utilizar mecanismos de difusão -> limita escala a redes locais - Utilizar espaços de nomes de grande amplitude referencial As 2 primeiras soluções não são escaláveis para sistemas de dimensão média ou que tenham fortes requisitos de desempenho ou disponibilidade. O DCE utiliza a hora, data e nº telefone do instalador, com 128 bits mas não é prático, normalmente impor regras demasiado complicadas. Pelo contrário, garantir a unicidade nos nomes locais é fácil, porque cada contexto pode ser gerido separadamente por uma única autoridade, sem sacrifício do desempenho e da disponibilidade. A desvantagem é que não podem ser utilizados fora do contexto, obrigando a uma tradução. A forma mais simples de formar nomes globai s, mantendo as vantagens dos locais, é considerar que os nomes são formados por várias componentes numa estrutura hierárquica (sub-contextos a nível local). O nome é obtido por concatenação do nome do contexto com o nome do objecto. Esta técnica permite subdividir a complexidade da criação de nomes, obrigando contudo a nomes mais complexos. Ex. rede telefónica actual, endereços TCP (IP + porto). Estes nomes hierárquicos são os mais utilizados nos sistemas distribuídos. 5.3.3. PUREZA DE UM NOME Para além do problema da criação (propriedades anteriores) a pureza tem implicações a nível da resolução. Se o nome tiver informação sobre a localização do objecto, o algoritmo de resolução pode ser optimizado. Então teremos: - Nomes Puros: O algoritmo de resolução não utiliza qualquer informação presente no nome para inferir da localização do objecto ou da autoridade que o controla. ex. matrículas em Portugal, UUID do DCE. A sua vantagem é a independência da localização do objecto relativamente à informação do seu nome -> fácil aos objectos migrar do local onde foram criados, o que é cada vez mais importante nos sistemas distribu ídos. A desvantagem é a dificuldade dos algoritmos de resolução: não há indicação de onde iniciar a pesquisa. A solução simplista é aceder a um servidor centralizado mas isso reduz desempenho. Usam-se então técnicas de mecanismos de cache (mas tem de continuar a haver servidor central a quem recorrer), replicar a base de nomes, difusão (custos grandes fora do contexto de rede local), utilização de nomes com pistas (hints) caso não se consiga resolver na cache local. - Nomes Impuros : ex. portos TCP/UDP, nomes globais dos ficheiros Unix, rede telefónica fixa, URLs – o que impede a mobilidade das páginas ->URI. A designação de puro/impuro é ortogonal ao âmbito local/global: 5.3.4. ESTRUTURA SINTÁCTICA DOS NOMES A diferença entre nomes e identificadores reflecte-se, essencialmente, no tipo de estrutura de dados associada ao identificador. Nos sistemas distribuídos mais complexos pode haver a necessidade de interligar espaços de nomes de sistemas de múltiplos (ex. DCE). Um exemplo interessante de umfabricantes grande espaço de nomes heterogéneo é o definido na WWW para referenciar páginas de documentos (URLs), que pretendem ser nomes universais utilizáveis por todas as aplicações que manipulam documentos na Internet. Os URL baseiam-se numa estrutura hierárquica, em que o primeiro campo define qual o esquema de designação, ou seja, qual o espaço de nomes que se aplica e quais os protocolos que permitem o acesso ao objecto. : ex: http://hostport/[path][?search] 5.3.5. INFORMAÇÃO ASSOCIADA AOS NOMES A associação nome objecto pode conter, além do identificador, atributos que sejam importantes para caracterizar os objectos em diversas aplicações. Por ex., no Unix associam-se ao nome do utilizador o seu directório por omissão, o shell, as variáveis de ambiente. A função de resolução pode também ser complementada com facilidades para pesquisas mais complexas sobre vários atributos. Sistemas mais elaborados como a norma X.500 aproximam-se mais do esquema conceptual das bases de dados, mas comdos consistência relaxada funções de pesquisa limitadas ( serviços de , para distinguir serviços de nomes etradicionais). directório 5.4. FUNCIONALIDADE DO SERVIÇO DFE NOMES Gere as associações lógicas entre nomes e objectos. A função inicial corresponde ao registo da associação, isto é, à criação de um nome.
Esta operação verifica se a sintaxe está de acordo com as regras e a unicidade referencial. a criação tem de ser validada pela autoridade. Uma nova associação deve ser dada a conhecer a todos os contextos (distribuição das associações) onde é suposto ser válida, o que pode implicar actualização de directórios em várias máquinas, colocando os problemas habituais de consistência na presença de faltas. A actividade mais frequente da gestão de nomes é a resolução, que pode implicar vários contextos e espaços de nomes, sendo uma operação crítica em termos de desempenho. A gestão de nomes e a segurança são ortogonais. 5.5. ARQUITECTURA DO SISTEMA DE GESTÃO DE NOMES 5.5.1. MODELO Nos sistemas multiprogramados clássicos, a gestão de nomes não corresponde a uma componente autónoma e funcionalmente bem identificada dentro do sistema. Nos sistemas distribuídos, o maior volume de nomes , as necessidades de partilha e a heterogeneidade obrigam a uma arquitectura diferente, tornando o serviço de nomes uma componente autónoma. Tem, por isso, os problemas normais de uma arquitectura distribuída, reforçados por: - Disponibilidade – a gestão de nomes é quase sempre usada no estabelecimento de ligação entre processos -> tem de ter disponibilidade levada - Desempenho – das operações de resolução - Escala – escalabilidade sem comprometer os pontos anteriores. Uma solução trivial é replicar toda a informação relevante nas diversas máquinas. Os problemas de gestão, coerência e desperdício de espaço são evidentes. Inicialmente a gestão dos nomes dos sockets era assim, através dos ficheiros /etc/hosts e /etc/services que, em cada máquina, são o repositório dos nomes necessários para a comunicação distribuída, mas a gestão destes ficheiros por diferentes administradores leva a incongruências, não sendo portanto escalável, Uma outra solução é usar a difusão para traduzir um nome. O cliente envia o pedido parta a rede e o servidor que tivesse a associação no seu contexto respondia. Isto só é aplicável a redes locais, devido apreço e não é escalável (ex. NetBios e Windows). A gestão de nomes é uma aplicação intrinsecamente distribuída, pelo que uma arquitectura cliente-servidor permite criar uma solução que resolve os problemas referidos anteriormente. Podemos considerar os seguintes componentes: - Interface com os programas utilizadores – Agente do serviço de nomes - Estrutura do servidor de nomes - Mecanismos de armazenamento nos servidores. 5.5.2. O AGENTE DO SERVIÇO DE NOMES Coloca-se o problema da inicialização do agente. Para efectuar a primeira sobre o serviço de nomes, o agente tem de conhecer o endereço do servidor e não ooperação pode obter através do serviço de nomes. Existem várias soluções que diferem na flexibilidade de definição do endereço e no aumento de tráfego na rede que geram: - Considerar que o porto associado ao servidor é fixo (well-known) - Difusão periódica do endereço dos servidores - Pedido em difusão na inicialização do agente, do endereço do servidor de nomes Depois de obtido o endereço, o agente invoca uma operação, geralmente uma resolução. No caso da resolução não poder ser executada pelo servidor contactado, a sua finalização pode ser: - Iterativa – O servidor envia o pedido de volta ao cliente, indicando um outro servidor onde o nome poderá ser encontrado. É da responsabilidade do cliente continuar a busca - Recursiva – O servidor fica responsável, reenviando o pedido a outros servidores - Transitivo – O servidor transfere o pedido para o servidor seguinte. O servidor inicial não fica responsável. A iterativa é a mais simples para o servidor. Na Internet este protocolo é implementado porsolução todos os servidores. As soluções recursiva e iterativa simplificam a funcionalidade do agente pois o servidor actua como único responsável da resolução do nome. A recursiva é útil em diversos casos – agentes simples; diferenças de protocolo; servidor fica em contacto com a gente e refresca a sua cache.
5.5.3. O SERVIDOR DE NOMES Um servidor centralizado é impraticável, não só devido ao tamanho da base de dados como às condicionantes em termos de desempenho e disponibilidade. O que ajuda é que os nomes variam com pouca frequência e algumas inconsistên cias são toleráveis , redundando apenas num maior tempo de latência (ex. socket associado a um determinado servidor num RPC mudou, dá erro, mas cliente pode tentar traduzir novamente). As 2 características simplificam mecanismos de cache (aumento de desempenho) e replicação (aumento de disponibilidade). O algoritmo de resolução é simples: o servidor verifica se o nome pertence ao contexto que gere e, em caso afirmativo, procura informação local. Se for de outro contexto contacta o servidor responsável ou informa o cliente. Se o nome é impuro com uma estrutura hierárq uica, o servidor contacta um servidor do contexto hierarquicamente superior. Se puro, contacta servidor raiz. Para evitar o congestionamento do servidor da raiz, os outros servidores mantêm caches dos nomes traduzidos recentemente – Princípio da Localidade permite augurar boas perfomances. Mas como a cache pode não estar actualizada o cliente tem de ser informado que a resolução é da cache e não da raiz. Só no caso de o nome não se encontrar na cache, terá de ser contactado o servidor de um contexto presente no nome. DISPONIBILIDADE DO SERVIDOR Como em qualquer situação de replicação, existe implícito um compromisso entre a consistência dos dados e a sobrecarga nos nós gestores e na rede de comunicação. A organização mais simples é o servidor mestre se encarregar da gestão dos servidores replicados. Os problemas colocam-se em 2 situações: - Quando o mestre falha antes de propagar actualizações - Existência de falhas de comunicação ou nos escravos como há uma certa tolerância, as actualizações periódicas chegam para resolver o problema. ARMAZENAMENTO DA INFORMAÇÃO Nos servidores há informação volátil e persistente. Esta coloca os problemas clássicos da busca em bases de informação enormes (tempo). Uma boa solução são os programas para gestão de ficheiros sequenciais indexados como o dbm. Não é preciso SGBD comerciais. 5.6. EXEMPLOS DE SERVIÇOS DE NOMES Duas arquitecturas com objectivos parcialmente diferentes: - O DNS – para rede de grande escala (preocupações de redundância, optimização de desempenho e redução de tráfego) - O NIS – simplificar gestão de redes locais Unix
5.6.1. DOMAIN NAME SERVICE Gere os nomes das máquinas na Internet. O sistema de nomes inicial da Internet era global e puro, gerido de forma central com distribuição via ftp para actualização das caches, o que rapidamente se revelou insustentável. ESPAÇO DE NOMES É global, hierárquico e impuro. Os nomes são definidos numa estrutura em árvore como uma hierarquia de contextos. Cada contexto é designado de domínio e é identificado por uma cadeia de caracteres e tem associado uma autoridade. O nome global resulta de concatenação, com separação por ponto (.) A ordem da concatenação parte das folhas para a raiz, ao contrário dos ficheiros Unix. A raiz é representada por uma cadeia de caracteres vazia. ex. “ sina.inesc.pt. “ . Os domínios são lógicos. A autoridade pt é a FCCN. REGISTOS Os nomes DNS podem ser associ adosdesignados a diferentes de informação. encontra-se organizada em registos, normalmente RRtipos (resource register). Esta Os registos têm tamanho variável e são tipificados em termos de classe e tipo. A classe discrimina famílias de nomes associados a protocolos diferentes, ou seja, espaços de nomes diferentes que podem coexistir no mesmo serviço de nomes. A classe que nos interessa é a IN de Internet. Os tipos discriminam os diferentes atributos a que o nome pode estar associado: Tipo de registo Conteúdo
A MX CNAME NS SOA PTR TXT WKS
Endereço IP Máquina ou domínio do servidor preferencial de correio electrónico Nome simbólico para outro nome DNS Servidoresdeumazona Parâmetrosquedefinemazona Nome DNS para a resolução inversa de um endereço IP Textoarbitrário Descrição de um serviço com os respectivos nomes e protocolos
HINFO Arquitectura e sistema operativo do nó A operação mais relevante no DNS é a resolução do nome para obter a informação contida no registo respectivo. Estas operações são parametrizadas pela classe e tipo do registo pretendido ARQUITECTURA DO DNS Baseia-se no conceito de zona, que corresponde a uma subárvore que começa num domínio e se estende até às folhas ou até um domínio onde começam outras zonas. Cada zona é gerida por uma autoridade que tem a responsabilidade de instalar e gerir os servidores de nomes. O BIND é uma implementação do serviço de nomes DNS desenvolvida para a versão 4.3 do Unix BSD. É composto por 2 entidades: os servidores de nomes (named) e a biblioteca de interface (resolver). Uma zona tem pelo menos 2 servidores. Um primário gere os ficheiros com as tabelas de nomes e actualiza o secundário que é só réplica e só tem cache. A cada entrada é associado um TTL (time to live). Para optimizar a estrutura do serviço em redes locais , existem duas possibilidades de configuração que designaremos por cliente e de No servidor remoto reencaminhamento primeiro, o resolver actua como um remoto de um servidor que se executa(forwarding). numa máquina com acesso à Internet, pelo que a máquina local não tem servidor DNS. No segundo, o servidor local, perante um pedido não satisfeito, reenvia-o para uma lista de servidores que implementam a resolução recursiva dos nomes, que são os que se encarregam da interacção com os servidores externos. Isto é duplamente interessante pois evita que sejam logo contactados os servidores primários de outros domínios pelo servidor que não tem a informação em cache e o servidor mestre da rede pode progressivamente ter em cache um maior nº de nomes, reduzindo os acessos ao exterior. A informação de base para o servidor primário está descrita num conjunto de ficheiros DNS database files ou db. ex: inesc.pt (nome da zona) IN SOA inesc.pt.pt (nome do servidor primário) hostmaster.inesc.pt (endereço de e-mail do responsável pela gestão do domínio) (1995083015; serial (contador incrementado sempre que o ficheiro de base seja alterado e que permite sinaliz ar aos servidores secundários que a base de dados foi modificada) + refresh – frequência de actualização dos servidores, temporização para o refrescamento, período limite sem refrescamento e TTL) 5.6.2. NIS – NETWORK INFORMATION SERVICE Para a gestão de uma rede local de máquinas Unix, a SUN desenvolveu o serviço NIS. O sistema pretende simplificar, evitando que os nomes utilizados (pelo SO e utilitários) nas várias máquinas sejam mantidos de forma fragmentada. Usando o NIS o administrador da rede pode distribuir e actualizar a informação sobre nomes de um único ponto da rede, de forma automática e fiável. ESPAÇO DE NOMES Nomes são encontrados nos ficheiros da directoria /etc, por ex. passwd, group, hosts, networks, services, protocols, ethers, etc. A partir destes ficheiros o NIS constrói mapas. O contexto onde os nomes são válidos é o de uma rede local, locais a um domínio portanto. O NIS não resolve só os nomes mas gere tudo o que diz respeito a nomes. Utiliza a biblioteca C e a sua finalidade é facilitar o acesso pelo que a estrutura é a mesma dos ficheiros citados. ARQUITECTURA DO NIS Baseia-se na existência de um servidor mestre por domínio e vários escravos que devem gerir os mesmos mapas. O servidor designa-se por ypserv e podem existir vários processos ypserv escravos para substituir o mestre em caso de falha ou avaria. Quando um cliente pretende traduzir um nome, contacta o processo ypbind que se encarrega de estabelecer a ligação com o servidor ypserv. O processo ypbind apenas fornece ao cliente a informação de ligação e executa-se em todos os nós da rede. Quando um nó se inicializa, o
ypbind envia um pedido em difusão para a rede, o primeiro ypserv que responder fica a tratar do nó. Tem a vantagem de distribuir a carga pelos servidores. As etapas fundamentais do processo de instalação do NIS: - Definir um domínio NIS para um grupo de máquinas (atribuir nome ao domínio, definir máquina que tem servidor mestre, nº de servidores escravos necesasários, respectivos nós e os nós clientes) - Modificar os ficheiros do directório /etc nos clientes - Verificar no servidor mestre se os ficheiros no directório /etc estão actualizados e se são necessárias alterações no ficheiro password para incluir os servidores NIS - Converter os ficheiros nos mapas NIS, com comandos apropriados - Inicializar o servidor mestre no init colocando em execução o servidor do domínio (ypserv) - Inicializar nas máquinas cliente os servidores escravo através do comando init, mas especificando o nó onde se executa o mestre. A alteração de informação é sempre feita no servidor mestre e propagada aos escravos. 5.7. NORMALIZAÇÃO NA GESTÃO DE NOMES 5.7.1. A NORMA X.500 Pretende definir um serviço de nomes distribuído de grande dimensão – a grande lista telefóni ca mundial (directório) para os sistemas informáticos, não só relacionados com agestão de rede mas também com as aplicações distribuídas. A informação no directório chama-se DIB (Directory Information Base) ESPAÇO DE NOMES Tem uma estrutura hierárquica em árvore (DIT – Directory Information table). Cada objecto tem um nome local (RDN). O nome global (DN) é composto pela concatenação a partir da raiz de todos os nomes locais, ou seja, dos RDN. A aproximação é com base em classes de objectos. O directório oferece 3 tipos de serviço: Leitura, Pesquisa e Modificação. ARQUITECTURA Cada utilizador é representado por um DUA (Directory User Agent) que se considera como sendo uma aplicação que interage com um conjunto de Directory System Agents (DSA). Para o utilizador é transparente a que DSA se ligou. Usa também o método recursivo ou iterativo, para além da existência de um de difusão, em que um DSA envia o pedido a todos os DSA que conhece. 5.7.2. GESTÃO DE NOMES INTEGRADA NO DCE O espaço de nomes é global, hierárquico e heterogéneo... ler primeiro
CAP. 6 – SEGURANÇA NOS SISTEMAS DISTRIBUÍDOS 6.1. INTRODUÇÃO Proteger um bem de um conjunto de ameaças. No caso dos computadores, aceder ou modificar alguma informação. Na definição global de uma estratégia de segurança que se apoia em diversos mecanismos de protecção à informação, dever-se-à ter em conta o valor potencial dessa informação , as ameaças esperadas, as formas de ataque e os custos. Nos militares é a confidencialidade, nos comerciais a integridade. Com base nestes elementos estabelece-se uma política de segurança com determinados procedimentos e mecanismos. Quer no mundo real quer nos sistemas informáticos, a existência de partilha é a principal fonte de ameaças. Os mecanismos que implementam a segurança têm sempre um custo, a nível de hardware ou a nível de tempo. A complementaridade entre política e mecanismos de protecção é crucial para atingor o resultado final. 6.2. POLÍTICAS DE SEGURANÇA NOS SISTEMAS INFORMÁTICOS Historicamente o problema da segurança nos SO apareceu aquando das partilhas de recursos nos sistemas multiprogramados. Num sistema de informação genérico as ameaças são: - Acesso não autorizado à informação - Modificação não autorizada da informação - Execução de operações que conduzam ao uso não autorizado de recursos do sistema ou sob sua gestão - Perturbar o acesso legítimo de utilizadores a recursos do sistema - Acções de vandalismo Para descrever a segurança num SI usa-se no modelo o agente (utilizador ou alguém com responsabilidade na oferta de um serviço), que representa uma entidade que pretende executar uma operação sobre um objecto. O agente está representado no sistema através de um processo que é a entidade activa que executa as operações. Nos sistemas multiprogramados as políticas de segurança classificam-se em 3 tipos: - Isolamento dos Agentes – o agente está confinado à sua máquina virtual. Todas as interacções com o exterior são controladas pelo sistema. - Controlo dos Direitos de Acesso – extensão do anterior. Os agentes podem partilhar recursos (ler, escrever e executar). Com base na lista de operações que o recurso disponibiliza, direitos de cada agente. Controlado– por um componente sistema -estabelece-se Controlo do os Nível de Segurança da Informação Política dinâmica dedo controlo de acesso que tem em conta a função do agente e um nível de segurança do objecto, definido com base em regras o direito de acesso, num dado instante do agente ao objecto. A extensão para sistemas distribuídos é relativamente óbvia. 6.2.1. ISOLAMENTO DOS AGENTES Os objectos geridos pelo sistema pertencem a um único agente, o que estabelece uma relação de dono entre o objecto e o agente. Nos multiprogramados, como é óbvio, o isolamento é lógico, existindo vários utilizado res que partilham a mesma máquina. O gestor de máquinas virtuais, ou seja, o SO é responsável por garantir que todas as interacções são estritamente controladas, de acordo com o princípio do isolamento. A política de isolamento dos agentes obriga a que exista uma operação de base que valide a identidade do agente e que designaremos por autenticação – desafio (login). As hipótesesasde são: ataque ao isolamento - Descobrir palavras-chave de identificação - Assumir a identidade de outro utilizador no SO - Executar operações que indirectamente ultrapassam os mecanismos de protecção - Infiltrar código (cavalos de Tróia, vírus, vermes) em programas utilizador ou do sistema que permitem executar sub-repticiamente acções que ultrapassem os mecanismos de protecção do sistema
- Canis encobertos (covert channels) que permitem obter informação através da medida de outras grandezas Os ataques às palavras chave são feitos habitualmente construindo dicionários de palavras (actores,...) que depois são cifrados e comparados com as do ficheiro passwd. Um dos parâmetros que fragiliza a segurança das palavras-chave prende-se com o tempo de execução do algoritmo de cifra. A personificação pode se feitas depois de obter a palavra-chave de um utilizador, ou mais sofisticadamente capturar a informação de identificação nos pacotes que circulam na rede e reutilizá-la mais tarde. Os cavalos de Tróia surgem nos sistemas onde se permite a partilha de código, o que é comum por razões óbvias de diminuição do espaço de memória utilizada. Se a um programa com privilégios se adicionar um pedaço de código que execute outras funções (tipo acedam a informação confidencial como as passwords o que permite ao atacante ultrapassar os mecanismos de protecção). Os cavalos de Tróia dos PCs são vírus, nos sistemas distribuídos são vermes. A distinção depende dos autores mas todos significam adição de código a programas inofensivos, que aproveitam a execução do programa hospedeiro para detectar outros que podem infectar. No DOS é muito fácil devido à inexistência de protecção da memória e dos ficheiros. Os vermes têm um comportamento semelhante no sistema distribuído, detectando as máquinas acessíveis a partir de um nó e exportando-se associados a mensagens entre aplicações distribuídas como o sendmail ou o ftp. Uma ameaça potencial advém da existência de operações de E/S e de acções assíncronas de que é difícil verificar se mantêm o mesmo princípio de isolamento. O isolamento entre o núcleo do sistema e os processos pode ser também uma ameaça, por exemplo, subvertendo as funções sistema através de parâmetros indevidos, como endereços virtuais do espaço de endereçamento de outros agentes ou do núcleo. 6.2.2. CONTROLO DOS DIREITOS DE ACESSO Pode ser considerado como uma evolução da anterior, permitindo a partilha de objectos entre máquinas virtuais. O conceito de base nesta política é a matriz de direitos de acesso: Objectos Agentes 1 2 3 1 Ler Escrever 2 Ler/Escrever 3 Ler Cada objecto tem definido de acordo com a respectiva funcionalidade, as operações que sobre ele executar. A matriz especifica para cada par agente/objecto os direitos que o agente temse depodem executar operações nos objectos. A matriz é lógica e é materializada em estrutura de dados de 1 de 2 formas possíveis: - Lista de controlo de acesso (ACL) – associando todos os direitos de acesso ao objecto (por colunas). É o mais usual. - Capacidade – associando os direitos de acesso ao agente (por linhas). Ambas têm vantagens, dependendo do nº de agentes e de objectos do sistema, pelo que a comparação difere quando se consideram sistemas centralizados e distribuídos. Neste caso temos de ter 2 operações de base: - Autenticação – Operação de validação da identidade do agente - Autorização – Operação que valida os direitos do agente sobre o objecto A entidade que verifica a autorização é o monitor de controlo de referências , que é uma abstracção que representa o conjunto de mecanismos de controlo de acesso, normalmente residente no código de suporte ao servidor onde o objecto reside. Os direitos associados a cada objecto podem ser mudados pelo dono do objecto, que tem controlo discricionário sobre o objecto. Normalmente a revogação de direitos só entra em vigor na próxima utilização do objecto porque a revogação imediata é complexa. Os ataques são os que visam subverter o isolamento entre os agentes mais os que procuram alterar a matriz ou eliminar o controlo do monitor de controlo de referências. Os objectos só podem ser acedidos através do monitor, dai os processos utilizador não poderem fazer E/S directamente (ex. ficheiros).
Num sistema multiprogramado a informação relativa à matriz é mantida no núcleo. Nos distribuídos tem de haver comunicação entre elas, pelo que há o perigo de serem interceptadas. Em Unix agente identifica-se no login -> UID que fica registado no contexto núcleo do processo e, portanto, fica protegido pelo sistema. O UID identifica o agente perante o monitor nas operações de autorização. No sistema de ficheiros Unix, os direitos de acesso são armazena dos numa ACL mantida no descritor do ficheiro (inode). 6.2.3. MODIFICAÇÃO DINÂMICA DOS DIREITOS DE ACESSO A associação anterior é estática, que é mais simples mas torna inflexível o comportamento dos agentes em relação aos objectos durante a execução. O conceito anterior pode ser estendido, considerando um nível de indirecção que vamos designar por domínio de protecção . Podemos na matriz de direitos considerar que na coluna não identificamos directamente os agentes, mas domínios de protecção. Cada domínio define os respectivos direitos sobre os objectos. Um agente executa-se sempre num determinado domínio de protecção, contudo, durante a execução o domínio pode ser dinamicamente alterado. Para isso é preciso mais uma operação: de alteração do domínio associado a um agente, sempre de acordo com regras preestabelecidas. O Multics introduziu este conceito para gestão da protecção do espaço de endereçamento dos processos, que é conhecido por mecanismo de protecção em anéis, onde para mudar de anel, é invocada uma gate. Ainda hoje existe nos Intel. No Unix é através do set UID (SUID). Quando se executa um ficheiro através da função exec, há a possibilidade de o processo mudar a identificação do utilizador, se no ficheiro executável existir uma indicação especial que faz com que o processo assuma a identidade do dono do ficheiro durante a execução do programa. O processo tem 2 domínios associados: o do utilizador UID e o do grupo GID. A operação de alteração de domínio é conceptualmente muito crítica para a segurança, porque permite a personificação de qualquer outro agente. Precisamente o setUID revela-se um dos pontos fracos da segurança do Unix. 6.2.4.CONTRLO DO NÍVEL DE SEGURANÇA DA INFORMAÇÃO O poder discricionário do dono nos métodos de controlo de acesso que vimos anteriormente podem ser antes mandatórios sobre os objectos, obrigando ao cumprimento de regras de protecção que têm em conta o grau de segurança que se atribui ao agente e o tipo de utilização que pretende do objecto. É uma visão militar. Os objectos são classificados de acordo com o seu nível de confidencialidade, por ex. Muito Secreto, Secreto, Restrito, Não Classificado. Para além disso a informação é classificada de acordo com o assunto (Nato, Os aagentes têm aceder. autorizações (clearances) que definem os compartimentos e oComunicações). nível de segurança que podem 6.3. BASE COMPUTACIONAL DE CONFIANÇA Os mecanismos de protecção são hierárquicos e por isso, para ser tudo coerente, deve ser concebida uma plataforma, que se baseia em técnicas elementares e provadamente eficazes, que servem para edificar a arquitectura do sistema de segurança. No caso dos sistemas multiprogramados os utilizadores consideram o SO como o garante da segurança. Esse SO usa os mecanismos elementares: - Isolamento dos espaços de endereçamento (hardware de gestão de memória) - Restrição à execução em modo utilizador de instruções privilegiadas que possam ultrapassar o isolamento dos espaços de endereçamento (ex. interrupções, operações E/S) - Utilização do núcleo exclusivamente através de funções sistema - Algoritmos de criptografia Os protecção podem, contudo, nãoefeitos ser suficientes determinadas ameaças, quemecanismos por deficientedecobertura dos ataques quer por indirectos contra que permitam ultrapassá-los. Para explicitar a parte do SO responsável pela segurança, foi introduzido o conceito de Base Computacional de Confiança (TCB). Faz parte do TCB tudo o que no SO é necessário para garantir a política de segurança. O Departamento de Defesa dos EUA propôs uma taxonomia para caracterizar o nível de segurança – o Orange Book de que em Portugal é usada a versão SEGNAC-4. Nesse book são definidas 4 classes:
D – protecção mínima C – Política baseada no controlo de acessos, vulgar nos SO comerciais B – Políticas baseadas em controlo mandatório A – A classificação mais elevada que implica não só a existência dos mecanismos mas a sua verificação formal. 6.4. POLÍTICA DE SEGURANÇA NOS SISTEMAS DISTRIBUÍDOS 6.4.1. AMEAÇAS A TCB tem de ser reequacionada tendo em conta a escala que a torna propícia a diversos ataques. Ao nível da comunicação, podemos considerar os seguintes métodos de ataque: - Escuta de mensagens - Modificação, inserção ou remoção de mensagens para que o receptor aceite dados falsificados - Repetição de mensagens antigas A mais simples é a escuta (interpretação dos pacotes – captura e escrita em ficheiros de todas as mensagens). Há até programas de verificação Ethernet que, duma forma promíscua permitem isso. A solução é o recurso à criptografia – canais seguros com esquemas de cifra. A modificação já implica esquema que permita interpretar o protocolo de comunicação e capacidade de recepção e envio de mensagens. A solução é a combinação de prevenção, detecção e técnicas de recuperação, como por ex. o CRC embora este não elimine totalmente pois o pirata pode alterar e recalcular o CRC. Então técnicas baseadas em criptografi a permitem obter códigos que asseguram a integridade das mensagens (MIC) que não podem ser alterados sem que alguém conheça uma chave. Veremos esta técnica na assinatura digital de documentos. O 3º ataque é mais subtil porque se baseia em informação correcta gerada por agentes autênticos. Para detectar mensagens desactualizadas há que pôr nonces ou timestamps -> sincronização das máquinas. A visão genérica da TCB pode hierarquizar-se: - Rede e SO considerados seguros - Rede não segura e SO seguros - Rede e SO não seguros Não pressupor que uma rede é segura é a situação mais vulgar quando se consideram redes de alguma dimensão ou que ultrapassem os limites físicos de uma instituição. Basta pensar na Internet -> as dificuldades de garantir um sistema seguro são maiores. Na definição de uma política para este sistema dever-se-à suspeitar do interlocutor quer seja cliente ou servidor. O princípio da suspeita mútua obriga a uma validação cuidadosa de todas as interacções, apesar dos custos libertam manutenção por pessoal especiazado. 6.4.2. MODELO Nos sistemas distribuídos partimos do modelo inicial em que um agente que pretende executar uma dada operação sobre um objecto mantido num servidor. O canal de comunicação tem de ser seguro. No servidor terá de ser verificada a identidade do agente e validar se o agente tem direito a executar essa operação, o que é feito pelo monitor de controlo de referências. O canal seguro é implementado por mecanismos de criptografia. O mecanismo de autenticação para ser seguro não basta ser do tipo desafio, fazendo intervir as técnicas de base de constituição de canais de informação seguros e evitam a repetição da informação. O mecanismo de autorização é o de menor impacto nos SD pois é local ao servidor, mas o potencial grande nº de utilizadores pode tornar eficaz o uso de mecanismos baseados em capacidades, que recolocam o problema da trx. Para estender uma política de controlo de acessos aos SD, o TCB deve oferecer os seguintes mecanismos: -- Canais de comunicação seguros Autenticação dos agentes - Autorização no acesso aos objectos - Integridade e autenticidade da informação. 6.5. CANAIS DE COMUNICAÇÃO SEGUROS 6.5.1. CRIPTOGRAFIA
Baseia-se na aplicação de uma função que transforma a informação inteligível (claro) em cifrada. Para obter a informação srcinal é preciso conhecer a função inversa. As funções muito simples podem ser facilmente detectadas por análise de padrões. Para dificultar, as funções são parametrizadas por uma chave que pode mudar frequentemente ou ser exclusiva de conjuntos (tipicamente pares) de interlocutores. {M}K quer dizer mensagem cifrada com a chave K. A segurança de um mecanismos de cifra não se baseia no segredo do algoritmo da função de cifra mas na dificuldade de descobrir a chave em tempo útil. Difícil descobrir M sabendo {M}k, mesmo que o atacante tenha texto em claro e cifrado. Podem ser totalmente seguras mas usualmente basta serem praticamente seguras. 6.5.2. CANAIS SEGUROS Um sistema de criptografia permite também autenticar os agentes. Se a mensagem for lida pelo receptor com uma dada chave e nela estiver um valor pré-acordado, pode-se, com justificável certeza admitir que foi enviada por um agente que possuía a chave. Se a distribuição das chaves for segura, um canal criptográfico autentica os agentes que o usam. Uma solução óbvia é inserir o mecanismo no nível de ligação, mas isso implica que os ataques podem ser feitos a mensagens nos buffers dos routers, pelo que a introdução de segurança no canal end-to-end é mais seguro. Para ser independente do transporte usado faz-se normalmente no protocolo de RPC. As técnicas criptográficas para implementar o canal de extremo a extremo podem subdividir-se em 2 grupos: - Chave secreta ou criptografia simétrica – uma chave é partilhada exclusivamente pelos 2 agentes que interactuam sobre um canal - Chave Pública ou criptografia assimétrica – existem 2 chaves, uma conhecida publicamente que permite cifrar ou decifrar a informação e outra chave que deverá ser mantida secreta. 6.5.3. CHAVE SECRETA Baseiam-se na existência de uma função de cifra e uma chave que apenas deve ser do conhecimento do emissor e do receptor. Os algoritmos de cifra com chave pública baseiam-se em permutações (para difundir) e substituições (para confundir) seguindo um princípio explicitado por Shanon que considera que as 2 técnicas para esconder informação são: confusão para que a entrada não tenha a ver com a saída e difusão para espalhar o efeito das modificações por toda a informação. O problema inerente a este algoritmo é que se baseia na partilha de uma chave a toda a partilha induz uma fragilidade de segurança. A distribuição de chaves aos interlocutores, ou pelo menos um deles, éque umodos método.seguro A chave deve ser enviada de forma segura. Admitindo foi, problemas o canal de deste comunicação estabelece-se da seguinte forma: Emissor Receptor f(K,M) => {M}k Enviar({M}k) ---> Receber({M}k) f-1 (K,{M}k) => M Ou,emnotaçãosimplificada: E->R: {M}k O algoritmo DES (Data Encription Standard) é a base dos sistemas computorizados de criptografia simétrica. Na versão mais usual transforma um bloco de 64 (quanto maior melhor mas torna processamento muito compl exo, pelo que é o ideal) bits noutro cifrado, usando uma chave de 56 bits (quanto maior melhor, já é entendido como insuficiente face ao poder computacional estar sempre a aumentar) (tem 8 bits de paridade para cada um dos grupos de 7 bits). O algoritmo baseia-se na aplicação à palavra de 64 bits de permutações e substituições por funções não invertíveis. O algoritmoem temtermos 18 etapas e pode ser estudado na página + 265. em software mas adaptaÉ intensivo computacionais, sendo lento quando264 executado se bem em CIs. Há 2 formas de utilização de sistemas de cifra: stream e padding. Os stream são mais robustos e fáceis de construir mas apresentam o problema de um erro num bit poder tornar indecifrável todos os outros. O DES é padding de 64 bits. ECB – Electronic Code Book
Cifra blocos independentes de 64 bits. Pode fragilizar o sistema, porque a mesma informação produz o mesmo texto, permitindo análise de padrões. CBC – Chipter Block Chaining ... OFB – Output Feedback Mode ... 6.5.4. CHAVE PÚBLICA Evitam a transferência de uma chave secreta entre os dois interlocutores, ultrapassando assim o delicado problema da partilha da chave. Considera 2 chaves (Kp e Ks). A chave pública de um agente pode ser colocada num servidor de nomes e utilizada por todos os agentes que quiserem comunicar com ele de forma segura, garantindo-se que apenas este terá possibilidade de decifrar a informação trx., devido ao conhecimento da chave privada. O método baseia-se na dificuldade de factorizar nºs grandes, de cerca de uma centena de dígitos em nºs primos. A maioria dos algoritmos de chave pública baseia-se numa aritmética modular, que usa nºs inteiros inferiores a N. Os resultados das operações aritméticas são divididos por N e tomando-se apenas o resto (ex. multiplicação modular: X*Y mod N). No quadro da página 269 (X*Y) mod 10, pode ver-se que a multiplicação por 3, 5, 7 (primos) constitui uma cifra de substituição para valores numéricos, porque permite efectuar uma substituição biunívoca dos algarismos. Se escolhêssemos 3 para cifrar as mensagens numéricas, decifrar a informação implicaria multiplicar pelo inverso do nº. Mas numa aritmética modular, o valor inverso não é a fracção inversa do multiplic ador, mas o nº que respeita a seguinte equação X*X-1 mod N = 1 Ex. 7 seria o inverso multiplicativo de 3 mas é complexo determinar este inverso para nºs de 100 dígitos. Com a exponenciação existem resultados semelhantes, que são a base dos métodos de chave pública. O RSA é o mais usado e base da norma nos EUA. Genericamente, o algoritmo utiliza uma aritmética modular (módulo N9, cifrando com base na exponenciação modular com a chave pública Kp e decifrando ao efectuar a exponenciação modular com a chave privada que é o inverso exponencial da chave pública numa aritmética modular. A informação é subdividida em blocos de 2 k < N (usualmente 256 ou 512 bits): Emissor: {M}Kp = (M Kp) mod N Receptor: M = {M}Kp Ks mod N Para ilustrar o cálculo das chaves, ver pg. 270 e 271 Diffie-Hellman É anterior ao RSA. ... 6.5.5. DISTRIBUIÇÃO DAS CHAVES Em ambos os métodos coloca-se o problema da distribuição das chaves. No método da chave secreta, os 2 processos dialogantes têm de ter a certeza que possuem uma chave que não foi divulgada. A transmissão segura da chave assume, portanto, particular relevância. Não sendo rentável e eficiente o uso de vias separadas, pode-se utilizar uma 3ª entidade que se assume segura, um Servidor de Distribuição de Chaves (KDS ), que se encarrega de autenticar ios interlocutores e distribuir as chaves. No sistema de chave pública, o problema anterior não se põe, porque não há partilha de chaves, mas o atacante, porque se deve obter a chave pública de um servidor, fabricar um par e alterando o endereço fazer-se passar pelo servidor. A solução, tal como anteriormente, é ter uma autoridade segura de distribuição de chaves públicas, associando-se ainda uma assinatura digital, que consiste em cifrar a chave pública pretendida com a chave privada do servidor. Neste caso os servidores fornecem certificados aos seus utilizadores. Quando um agente contacta o servidor para a chave de contactar um outro eagente, é-lhe devolvido certificado composto pelo nomesaber do agente quepública pretende pela respectiva chave um pública. Esta informação é cifrada com a chave privada do servidor. Para que os agentes sejam capazes de usar esta chave, têm de possuir a chave pública do servidor. Como os certificados não são falsificáveis, podem ser colocados em servidores de nomes sem mecanis mos extra de segurança. É claro que o servidor de certificados (CA) torna-se o ponto crítico.
6.5.6. CONSIDERAÇÕES SOBRE OS MÉTODOS Para se comparar os 2 métodos temos de atender ao nível de segurança, desempenho e complexidade do sistema. Admitindo que a distribuição de chaves é igualmente segura, o nível de segurança ainda não foi objecto de ataques com sucesso em nenhum dos métodos mas o RSA é claramente mais robusto contra ataques sistemáticos. Os sistemas de chave secreta são muito mais rápidos (1000 vezes). A complexidade não pode ser avaliada de forma absoluta. O de chave secreta obriga à existência de um canal seguro, o que é complexo. O de chave pública é aparentemente mais simples, mas implica autenticação para evitar que impostores divulguem chaves públicas. Uma combinação interessante é utilizar um sistema de chave pública para a troca de chave secreta entre o agente e o servidor e, em seguida, utilizar um método criptográfico de chave secreta, com maior desempenho. 6.6. AUTENTICAÇÃO EM SISTEMAS DISTRIBUÍDOS Neste contexto referimo-nos à autenticação entre processos computacionais: o agente utilizador e o agente servidor. Muitas aplicações reutilizam o método da autenticação de pessoas perante o sistema, transmitindo a palavra-chave na rede, em claro, entre o agente e o servidor, o que é particularmente inseguro. Uma forma mais interessante é reutilizar o mecanismo de estabelecimento de um canal seguro: O cliente pede uma ligação ao serviço; este responde enviando um valor que o cliente deverá retornar, cifrando-o com a chave secreta associada ao canal cliente-servidor. Tem vários problemas: não é recíproco, só autentica o cliente; o valor de D tem de variar; é necessário estabelecer a chave secreta. O 1º problema resolve-se facilmente duplicando as duas últimas mensagens e obrigando o agente a apresentar um desafio ao servidor a que este deverá responder. O valor de D poderia ser um nonce ou carimbo temporal, o que impõe sincronização elevada entre relógios. O problema da chave secreta é mais complexo e impõe um KDS. O servidor de autenticação tem, para cada agente registado no seu serviço, uma chave secreta que foi introduzida na sua base de dados de forma segura e que o agente conhece. Baseados na conclusão que conhecer uma chave permite autenticar quem a possui, Needham e Schroeder definiram um serviço de autenticação, utilizando sistemas de chave privada e de chave pública.
6.6.1. CHAVE SECRETA O mecanismo baseia -se na existência de uma chave secreta para garantir a autenticação mútua entre clientetem e servidor. O protocolo as seguintes fases: 1: C->Saut C,S,Nc 2: Saut->C {Nc,S, Kcs, {Kcs, C} Ks} Kc 3: C ->S {Kcs, C}Ks 4: S->C {Ns}Kcs 5: C->S {Ns-1}Kcs
6.6.1. CHAVE PÚBLICA Baseia-se na assunção que o servidor de chaves públicas é seguro. 1: C->Saut C,S 2: Saut -> C {Kps, S} KsSaut 3: C->S {Nc,C}Kps 4: S->Saut C,S 5: 6: 7:
Saut S->C -> S C->S
6.6.3. KERBEROS
{Kpc,C} KsSaut {Nc, Ns}Kpc {Ns}Kps
O Kerberos foi concebido para implementar um serviço de autenticação do projecto Athena, um sistema distribuído de grande dimensão desenvolvido no MIT e que se destinava a suportar a comunidade de 5000 utilizadores daquela grande universidade. É semelhante ao protocolo de chave secreta, sendo a principal diferença funcional a existência de 2 servidores de autenticaç ão, um para a autenticação inicial dos agentes (Kerberos) e outro para obter as credenciais (TGS – Ticket Granting Service) que permitem o acesso aos servidores. A vantagem é poder optimizar. Tem vindo a ganhar reconhecimento sendo utilizado em vários sistemas de ficheiros distribuídos (NFS, AFS) e como componente de autenticação no DCE. Há 3 tipos de objectos de segurança: - Chaves de sessão - Credencial (tickets) - Autenticadores – contêm informação que um servidor pode comparar com a credencial para provar a autenticidade do agente. A lógica subjacente ao sistema é que o cliente efectua a sua autenticação perante o Kerberos, recebendo uma credencial para aceder ao serviço de distribuição de credenciais, o TGS. Quando o cliente pretender aceder a um serviço contacta o TGS que lhe fornecerá a respectiva credencial. As credenciais ou tickets têm a seguinte estrutura: ticket(c,s) – {c, s, t1, t2, Kcs} Ks a validade é de 8 horas. Os autenticadores utilizados para validar a informação contida nas credenciais são: aut(c) – {c, t} Kcs O autenticador, usado em conjunto com o ticket, permite garantir que este não está a ser usado indevidamente por alguém que se apossou da credencial e indica também a actualidade da mensagem. 1: C->Kerberos C,TGS,Tc 2: Kerberos -> C {Kc,tgs, Tc}Kc, {ticket(C,TGS)}Ktgs 3: C -> TGS {aut(C}Kc,tgs, {ticket(C,TGS)}Ktgs,S 4: TGS -> C {Kc,s}Kc,tgs, {ticket(C,S)}Ks 5: C -> S {aut(C)}Kc,s, {ticket(C,S)}Ks, Operação, Parâmetros 6: S ->C {Tc+1}Kc,s,Parâmetrosda resposta O Kerberos é implementado por um conjunto de servidores que se executam em máquinas seguras. O algoritmo de criptografia é, normalmente, o DES. Os agentes podem mudar as suas palavras-chave, sendo estas actualizações reflectidas na cópia do servidor mestre. 6.7. MECANISMOS DE AUTORIZAÇÃO 6.7.1. LISTAS DE CONTROLO DE ACESSO As listas de controlo de acesso são a forma mais vulgar de implementar os mecanismos de autorização nos sistemas multiprogramados. No Unix um processo tem associado dois domínios de protecção definidos pelo seu código de utilizador (UID) e código de grupo (GID). Estes códigos são atribuídos quando o utilizador se autentica e herdados pelos processos filho. Para garantir a sua inviolabilidade, são armazenados no contexto núcleo do processo, sendo usados nas funções sistema de acesso aos objectos para validar a possibilidade de execução de determinada operação. Conceptualmente, a matriz de controlo de acessos de um sistema Unix teria tantas linhas quantos os valores dos UID e GID definidos numa máquina e um nº de colunas igual ao somatório de objectos sob controlo do sistema: ficheiros, processo, semáforos, caixas de correio, zonas de memória partilhada, etc.. Cada coluna da matriz constitui uma lista de controlo de acesso que deveria ser armazenada junto do respectivo objecto. Todavia, por razões históricas ... a especificação informação segurança foi utili compactada, no sistema dea ficheiros, sendo restringida a 3 da categorias: dono,degrupo, restantes zadores (world). Ou seja, matriz define os direitos de acesso para 2 domínios, sendo todos os outros, por omissão, considerados na 3ª entrada. Num sistema distribuído, os grupos têm uma formulação diferente, dado que são realmente conjuntos dinâmicos constituídos por utilizadores ou outros grupos. Um grupo encontra-se sempre
associado a um utilizador que é o seu dono. Um grupo pode ser membro de outro grupo, herdando os seus privilégios. As listas de acesso efectuam a correspondência entre os utilizadores e grupos nos respectivos privilégios de acesso aos objectos. As listas são conceptualmente constituídas por 2 sublistas: uma de direitos positivos e outra de negativos, que são forma expedita de revogação de direitos. O algoritmo de verificação de direitos é relativamente simples. Para um dado utilizador ou grupo, podem-se calcular todos os grupos a que pertence pela transitividade da função “membro de”. Este conjunto é denominado CPS (Current Protection Subdomain) e representa todos os domínios de protecção a que um utilizador está ligado. Quando um utilizador se posiciona num directório, os grupos da respectiva lista de acesso e o CPS do utilizador são comparados sistematicamente. 6.7.2. CAPACIDADES ...
CAP. 7 – TOLERÂNCIA A FALTAS 7.1. AS FALTAS NOS SISTEMAS COMPUTACIONAIS O sistema falha quando se desvia da sua especificação de funcionamento, ou seja, quando num determinado estado se observa que o resultado produzido por uma dada entrada não corresponde ao resultado esperado. Conceptualmente vamos considerar que uma falta é um acontecimento que altera o padrão normal de funcionam ento de um dado componente do sistema, e que poderá obrigar o sistema a evoluir para um estado interno errado (não pertence ao conjunto de estados admissíveis na sua especificação), ou que poderá evoluir para um estado admissível mas através de uma sequência de estados incorrecta. Então deu-se um erro. Em resposta a determinadas entradas, um sistema num estado errado irá ser incapaz de oferecer o serviço especificado e teremos um falha. A falta pode ser latente enquanto não se produzir um erro. E um erro pode ser latente se não se produzir uma falha e não houver mecanismos de autodetecção desse erro. Quando o erro é detectado, se existirem mecanismos de tratamento que permitam recolocar o sistema num estado correcto, baril. O tratamento poderá obrigar o sistema a parar ou à necessidade de manutenção para o reparar. Interessa-nos primordialmente a possibilidade de, depois de detectado um erro, conseguir efectuar o respectivo tratamento, ou seja, tolerar a falta e continuando a oferecer o serviço. falta -> erro -> falha Um sistema é composto por vários componentes, de uma forma hierárquic a, sendo normalmente uma falha num subsistema, uma falta no nível hierarquicamente superior. A análise destas relações é fundamental para definir um modelo de faltas de um determinado nível do sistema. As faltas de hardware estão associadas à fiabilidade dos componentes, as de software aos problemas de desenvolvimento dos programas, sendo as mais difíceis de tratar aquelas que apenas se manifestam em situações particulares de carga do sistema ou de sincronização dos processos. Há ainda as resultantes de operação humana. Ao contrário do hardware, cuja fiabilidade tem aumentado, o software permanece com a maior fonte de problemas, apesar das técnicas modernas usadas. A regra empírica é que há 3 erros em cada mil linhas de código. As falhas são particularmente relevantes quando põem em causa a informação persistente, pelo que a tolerância a faltas apareceu muito associada aos sistemas de gestão de base de dados. Tipos de Faltas Laprie – Taxonomia baseada na causa, srcem e duração. A causa pode ser: Física (eléctrica, mecânica) ou Humana (concepção, operação, maliciosa) A srcem pode ser Interna ou Externa (temperatura, energia eléctrica) A duração pode são ser Permanente (+ fácil detectar) Temporária (elevação de temperatura) As temporárias características dos de sistemas deou comunicação, onde alterações do campo electromagnético conduzem a alteração da informação no meio de trx. -> a maioria é recuperada com repetição. Nas humanas há as acidentais e as intencionais (prendem-se com a segurança-cap.6). É sempre necessário subdividir entre expectáveis e altamente improváveis ou de custo não compensatório para tolerá-las. Como sempre é preciso ponderar a relação custo/confiança face ao domínio de aplicação do sistema. Os erros que permanecerem fora do conjunto que decidirmos tratar/tolerar são considerados catástrofes. A relação entre os erros que têm possibilidade de ser tratados e o conjunto global dos erros possíveis é a taxa de cobertura. Na definição do universo de faltas é necessária uma aproximaçã o estruturada que considere que determinadas componentes são encapsuladas dentro de um subsistema que deverá prestar um serviço, interessando apenas o comportamento nas suas interfaces para evitar explosão combinatória. Por ex. num sistema centralizado é vulgar considerar apenas 2 componentes susceptíveis de falhar: o sistema computacional propriamente dito (hardware + SO + aplicações) – máquina ou nó - -> perde-se memória volátil + cache, dando srcem a uma falha por paragem (system crash) e o armazenamento persistente (media failure) – estudo diz que 49% das falhas atribuíveis ao hardware são devidas aos discos (cabeças...)
O comportamento do subsistema quando detecta um erro interno é um aspecto relevante na definição dos mecanismos que suportam as políticas de tolerância a falatas referidas. Simplifica de forma considerável o tratamento dos erros o facto de um sistema autodetectar a situação de erro e tomar a iniciativa de desencadear uma excepção – falha silenciosa. Por ex. os discos têm controle de erros em cada sector, se não teríamos de usar 2 ou 3 discos com a mesma informação. Há também a falha rápida – um estado errado é detectado rapidamente e o SO irá parar a máquina. Nos sistemas distribuídos, é frequentemente considerado que a falha de paragem de uma máquina é uma falha rápida. Nas faltas não expectáveis há 2 tipos: Faltas Densas – resultam da acumulação de faltas Faltas Bizantinas ou arbitrárias – fogem ao padrão de comportamento esperado para o componente. Ex. nó que envia mensagens correctas a um interlocutor e incorrectas a outro. De difícil tratamento. Exigem mais redundância para ser tratadas mas se não o forem são as que aparecem mais. Faltas nos Sistemas Distribuídos A comunicação e independência das máquinas conduz a modelo de faltas mais complexo. As na comunicação advêm de perturbações electromagnéticas nas linhas de trx., falhas nos órgãos de conexão à rede, incapacidade de comutação ou recepção de pacotes, etc. Aqui é vulgar considerar que a falta é temporária e portanto recuperável com a repetição. Uma dificuldade intrínseca num sistema distribuído é distinguir a falha de um nó remoto da lentidão na resposta a uma mensagem. Uma solução são os temporizadores mas que só funcionarão adequadamente se se souber os valores máximos de comunicação e de execução do processador remoto (difícil). Isto pressupõe sistema síncrono (de relógios), que é difícil. Esta situação levou a que os protocolos de detecção de faltas que funcionem sem que exista alguma dependência em relação ao tempo tenham vindo a ser alvo de grande interesse, mas obviamente de complexidade acrescida. Outro problema é o da contaminação, que pode ser de difícil tratamento se não houver mecanismos que confinem o erro. Fiabilidade E Disponibilidade A fiabilidade (reliability) mede a probabilidade de num dado intervalo de tempo não existir nenhuma falta no sistema. É importante para sistemas que mexem com vida humana ou por dificuldades em reparar (satélites). A disponibilidade (availability) é definida como a probabilidade do sistema estar operacional num instante de tempo, admitindo que ocorreram falhas, mas que foram todas recuperadas através da manutenção adequada. São complementares para a qualidade. Ex. satélite exige boa fiabilidade; caixa multibanco é mais importante disponibilidade. É habitual caracterizar os sistemas reparáveis por grandezas como o MTBF (mean-time-betweenfailure) e o MTTR (mean-time-to-repair). Nos não reparáveis usa-se o MTTF (mean-time-tofailure). 7.2. Políticas de Tolerância a Faltas O objectivo é evitar que um erro num subsistema conduz a à impossibilidade de prestar o serviço e, portanto, à falha do sistema. O primeiro passo é a detecção e identificação. Levou à criação de códigos de detecção de erros (bit de paridade, CRC) – pressupõem um dado padrão de faltas. Qualquer política de tolerância a faltas basei a-se na existência de um mecanismo redundante que possibilite que a função da componente comprometida sejadiversas obtida de outraespacial, forma. Só dispondo de redundância, é possível tolerar faltas. Pode assumir formas: com duplicação de componentes; temporal, com repetição da mesma acção; conjugação de informação adicional com algoritmos que permitem calcular o estado correcto. Há 2 classes de políticas de tratamento de erros com objectivos diferentes e, consequentemente, implicando meios diferentes:
A política de recuperação do erro substitui um estado errado por um estado correcto, podendo tornar sem efeito algumas etapas do processamento já efectuado. A política de compensação do erro baseia-se na possibilidade de, mesmo na presença de um erro numa compon ente, ser possível calcular um estado correcto a partir de componentes redundantes. Esta abordagem procura limitar ou eliminar o período de recuperação, ou seja, maximizar a disponibilidade do sistema. Ex. sensores de avião. São de grande interesse mas aplicam-se normalmente a sistemas especializados onde se pretende uma elevada disponibilidade. Para ilustrar políticas vamos mostrar 2 arquitecturas representativas: 7.3. Replicação Passiva A forma mais simples de estruturar uma aplicação distribuída é ter um servidor que executa as operações e múltiplos clientes que interactuam com ele. Em vez de um só servidor com a sua disponibilidade podemos ter mais. No caso concreto da replicação de servidores, as duas políticas de tolerância a faltas e processamento do erro, traduzem-se respectivamente por: - Replicação Passiva – existe um servidor principal com que os clientes interactuam. O segundo servidor está de reserva (backup), de forma a que, quando detecta que o servidor primário falhou, torna-se o primário. - Replicação Activa – Todos os servidores recebem pela mesma ordem os pedidos dos clientes, efectuam a operação, determinam qual o resultado correcto por votação e respondem ao cliente. A replicação passiva implica uma menor redundância e menos processamento, sendo a técnica mais utilizada em sistemas comerciais. Nele verificam-se as seguintes propriedades: - Num dado instante apenas pode existir um servidor primário - Num dado instante um cliente apenas conhece a identidade de um servidor - Um servidor que não é primário quando recebe mensagens de um cliente, ignora-as Os 2 problemas maiores são: - Detectar a paragem do servidor primário - Garantir a coerência do estado dos servidores Vamos assumir que os processos servidores são de falha rápida, ou seja, toma a iniciativa de pararem quando detectam alguma situação anormal. Os protocolos baseiam-se na ausência de mensagens para detectar a falha de paragem do servidor principal. O servidor primário envia periodicamente mensagens de “prova de vida” (I´m alive). É necessário estar seguro de que se distingue a paragem do servidor de um simples atraso na resposta, o que coloca o problema do sistema ser síncrono, ou seja, que existam limites conhecidos para o tempo máximo de trx. de mensagens. A coerência de estados entre os servidores complexo, porque obrigacorrespondentes. a que o secundário receba todas as mensagens pela ordem correcta e éefectue as actualizações O primário tem, portanto, de enviar para o secundário as mensagens que recebe dos clientes, podendo justapor (piggyback) as mensagens de prova de vida. É crucial que o sistema de comunicação garanta que a ordem de recepção das mensagens no secundário é a mesma, para que não exista a possibilidade de que um estado mais antigo se sobrepor a um estado mais recente. O modelo pode considerar diversos tipos de faltas. Para além das faltas por paragem dos servidores é habitual considerar as faltas na comunicação. Nestas há ainda que distinguir as temporárias das permanentes. É frequente considerar 3 aspectos na avaliação dos protocolos de réplica passiva: o grau de replicação depende do modelo de faltas considerado (tipo e número de faltas); o tempo de latência máximo de resposta ao cliente depende do incremento de tempo introduzido pelo protocolo entre o primário e o secundário; o tempo de indisponibilidade do sistema em que o servidor secundário não detectou a falha no primário. Um exemplo de utilização desta arquitectura é o servidor HA-NFS que pretende implementar um servidor de NFS com capacidade de tolerar falhas de paragem e comunicação. 7.4. Transacções Atómicas Mais complexo é considerar situações em que múltiplos servido res mantêm estados diferentes e se pretende que um cliente tenha acesso e modifique a informação em vários deles, garantindo que a operação decorre de forma consistente, mesmo na presença de faltas.
Na tecnologia actual dos sistemas distribuídos, as técnicas de recuperação de erro do tipo transaccional podem ser incorporadas nas plataformas de desenvolvimento cliente-servidor, proporcionando-lhes uma robustez acrescida. 7.4.1. Objectivos Garantir que aplicações que manipulam estruturas de dados persistentes (normalmente bases de dados) têm possibilidade de recuperar de estados errados, garantindo que simultaneamente sincronizam as suas acções de forma consistente com outras transacções que utilizam os mesmos dados. Ex. mover dinheiro da conta A para B. O procedimento deveria ser atómico, garantindo que todas as operações se executam ou que, na presença de faltas, se considera nulo o efeito das operações já executadas e se repõe o estado inicial. O que se pretende é a consistência na base de dados. Obviamente durante a execução das operações, os estados parciais são inconsistentes, mas se não forem utilizados por outras operações concorrentes não é violada a consistência global do sistema. esta garantia de isolamento entre as transacções é importante, pois na maioria dos sistemas as estruturas de dados são partilhadas com outras aplicações. 7.4.2. Propriedades Para definir formalmente as transacções, considera-se um conjunto de propriedades (ACID): - Atomicidade (Atomic) – Para um observador externo, uma transacção ou se executa na totalidade ou não se executa. Sempre que existam faltas, é possível recuperar o sistema para o estado inicial da transacção. O desfazer das operações (rollback) implica manter o estado parcial da transacção numa forma que facilite a sua confirmação ou anulação; - Consistência (Consistent) – Cada transacção deve, a partir de um estado inicial válido e caso se execute completamente, atingir um novo estado válido; - Seriabilidade (Isolation) – Se diversas transacções se executarem em paralelo sobre os mesmos objectos, tudo se passa como se as transacções se executassem em série numa determinada ordem. - Persistência (Durability) – Os resultados de uma transacção que confirmou permanecem depois de esta acabar e são supostos sobreviver ao conjunto de faltas expectáveis dos mecanismos de armazenamento. Tipos de Transacções Apesar de todos os sistemas transaccionais terem o objectivo comum de manter a informação persistente e consistente mesmo quando há operações concorrentes e falhas no sistema, os sistemas não são todos idênticos. Classificação: -- Localização Duração - Estrutura a localização procura caracterizar se os dados sobre os quais a transacção se realiza estão todos no mesmo local físico ou repartidos por vários sistemas.. As distribuídas podem ser consideradas como um complemento do sistema de RPC permitindo uma arquitectura em que múltiplos clientes e servidores interactuam de forma fiável. A duração reflecte a diferença entre as transacções destinadas a actualizações interactivas (online) da base de dados e aquelas que irão ser executadas sobre grandes volumes de informação, normalmente de forma não interactiva (off-line) (duração longa). A estrutura caracteriza a possibilidade de uma transacção apenas poder corresponder a um único fio de execução ou existirem múltiplos fluxos de execução no interior de uma transacção. Na primeira é flat, na segunda é nested. 7.4.3. Tipologia - Aborto explícitodas da Faltas transacção - Falta de paragem do sistema - Falta nos sistemas de armazenamento persistente - Falta na comunicação
O aborto da transacção é a falta mais simples de tratar, dado que não necessita de detecção, porque é explicitamente desencadeada pelo programa (não é falta mas tratamento de excepções). É uma forma de resolver interblocagens. Na falta por paragem do sistema assume-se que, devido a faltas com múltipl as srcens (energia, hardware, SO, etc.) houve paragem do sistema e, consequentemente perdeu-se a memória volátil. A existência de uma falta nos discos (media failure) é das que acontecem mais e é necessário redundância da informação. As faltas de comunicação podem ter diversas srcens mas normalmente são temporárias e podem recuperar-se repetindo as mensagens. Uma situação mais complexa ocorre se existirem faltas permanentes que conduzem a uma partição da rede física. Poder-se-à continuara tentar oferecer o serviço se houver uma replicação das bases de dados. É importante ter a noção que não se considera o aparecimento simultâneo de 2 faltas. 7.4.4. Modelo de Sincronização A necessidade de sincronização das operações de leitura e escrita deriva da propriedade de isolamento (atomicidade). Não posso ler saldo antes de acabar transferência. Quando um conjunto de transacções se executa concorrentemente, as suas operações de leitura/escrita vão ser intercaladas pelo escalonamento normal dos SO multiprogramados. A sincronização do acesso a variáveis partilhadas é o problema clássico de sincronização dos leitores/escritores. Leitura Escrita Leitura Compatível Conflito Escrita Conflitodo isolamento Conflito implica que a execução das transacções seja serializável. O A propriedade objectivo é garantir que as histórias são serializáveis, mas que a sincronização só impede a progressão de uma transacção se for estritamente necessário, ou seja, quando existe um conflito nas operações – história equivalente a sequencial. A forma mais simples de garantir a serialização é sincronizar o acesso a uma variável partil hada com base em trincos de exclusão mútua, mas é restritivo pois leituras não conflituam. Então usam-se os trincos com o algoritmo dos escritores/leitores. Antes de utilizar qualquer objecto, a transacção requisita um trinco de leitura ou escrita consoante o acesso que pretende efectuar. Múltiplos acessos em leitura são permitidos, mas um acesso em escrita bloqueará todos os acessos subsequentes. se uma transacção detiver um trinco de leitura sobre um dado registo, não será permitida a outra obter um trinco de escrita. A transacção que o pretenda fazer ficará bloqueada até que todos os trincos de leitura sejam libertados. Um dos aspectos de base na programação concorrente é garantir que as variáveis partilhadas são protegidas mecanismos sincronização (exclusão mútua) que assegurem que a sua actualizaçãopor é consistente -> 2de coelhos... Sincronização em 2 fases A transacção numa primeira fase começa por adquirir sucessivamente os trincos que lhe permitem aceder aos objectos (fase de crescimento) e, em seguida, os liberta (fase de decrescimento). O problema nesta formulação é determinar o ponto em que mais nenhum trinco será necessári o. O mais habitual é a sincronização em 2 fases estrita (strict two-phase locking ), quando a fase de libertação dos trincos ocorre apenas quando a transacção termina. Isto pode obrigar uma transacção a esperar por transacções demoradas apenas porque se iniciaram antes. Para aumentar o paralelismo, há sistemas que permitem libertar alguns dos trincos antes de terminar a transacção. É solução complexa e pode srcinar abortos em cascata se algumas das transacções posteriores tiverem usado os resultados da inicial que vai abortar. A visão optimista consi dera que os conflitos são raros e que, portanto, as transacções se podem executar mais rapidamente sem sincronização e no fim confirmar-se e abortar a transacção se for caso disso. Não se usa nos comerciais e são maus em carga alta. Interblocagem Há sistemas que pretendem evitar e outros recuperar. Nas técnicas para evitar há um conjunto conhecido por prevenção -> regras: estabelecer uma ordem para as operações de sincronização sobre trincos. É conceptualmente simples mas difícil
quando se usam linguagens de alto nível, manter a relação entre as estruturas de dados e os trincos, de forma a garantir uma ordem de utilização. Outra é obrigar a efectuar requisição de todos os trincos no início da transacção e só a deixar prosseguir se os tiver obtido. Caso contrário liberta todos os trincos e bloqueia-se. É fortemente limitativa da concorrência e às vezes nem possível saber de início todos os trincos que vou precisar. Na recuperação, a forma mais simples de detecção de interblocagem é usar um temporizador que, quando expira, assinala que a transação está possivelmente bloqueada numa condição de interblocagem. É simples mas pouco precisa, mas é boa pois a interblocagem é rara. A forma mais simples de recuperação é abortar a transacção. Há mais sofisticados por grafo. 7.4.5. Subtransacções Encaixadas (Nested) ... 7.5. Arquitectura dos Sistemas Transaccionais 7.5.1. Sistema Transaccional numa Arquitectura Centralizada É necessária uma máquina virtual que garanta as propriedades das transacções (Sistema Transaccional). O sistema transaccional interactua com as aplicações, quer localmente, quer através de chamadas remotas de procedimento, disponibilizando às aplicações dois grupos de operações: controlo da transacção (iniciar, confirmar, abortar) e as que modificam ou lêem os dados (escrever, ler). Internamente o sistema transaccional é composto por diversas funções que asseguram as propriedades já descritas. As unidades funcionais são: - Gestor de Escalonamento (responsável pela sincronização de todos os acessos aos dados manipulados pelas transacções) - Gestor da Cache (Gere a relação entre os discos e a memória volátil) - Gestor do Diário ( O diário –log- é uma lista onde fica toda a informação que permite recuperar de falta, isto é, a reposição de um estado correcto) - Gestor da Recuperação (Tem a função de recuperar o sistema para um estado consistente sempre que uma falta for detectada) - Gestor da Memória Estável (deve garantir a persistência dos dados)
CAP.8 – SISTEMAS DE FICHEIROS DISTRIBUÍDOS 8.1. Introdução Um sistema de ficheiros distribuído (SFD) permite a um processo aceder a ficheiros situados noutras máquinas, de uma forma idêntica à que utiliza para o acesso a ficheiros locais. Complementar com o mecanismo cliente-servidor (CS). Em modelos de programação distribuída baseados em RPC, os dados são acedidos localmente e é a computação que se desloca entre o cliente e o servidor (function shipping); num SDF, a computação é sempre local e são os dados que se deslocam entre o servidor de ficheiros e a máquina local onde se executa a aplicação (data shipping). Perspectivas dos SDF, nas realizações mais comuns: - Um mecanismo que se adiciona ao SO local para permitir o acesso remoto aos SF já existentes na máquina (NFS, LAN Manager, Windows for Workgroups). Normalmente, o SF local é logicamente dividido em 2 partes, a privada e a partilhada. Cada máquina exporta o seu SF local. Limitações: A gestão do espaço de nomes não é normalmente uniformizada. A gestão dos discos não é melhorada Problemas em ambientes com grande mobilidade - Um SF separado que pode ser acedido através da rede por todas as máquinas (AFS). Aqui, o SF é um serviço, implementado por um ou mais servidores. Cada máquina utilizador passa a dispor da parte cliente do SF, que lhe permite aceder aos ficheiros guardados no servidor(es). Têm espaço de nomes único; a administração é bastante simplificada; mais simples gerir espaço físico do disco; mobilidade facilitada; Mais complexo que o anterior. 8.2. PROBLEMAS TÉCNICOS 8.2.1. Desempenho A expectativa dos utilizadores é que o desempenho seja idêntico ao do sistema local. O mecanismo de cache é a técnica fundamental para conseguir um bom desempenho. Mantém na máquina local uma cópia da informação que se espera venha a ser acedida num futuro próximo. 8.2.2. Espaço de Nomes Problemas adicionais: - Âmbito do nome: global ou local, em relação ao cliente - Pureza do nome: o nome da máquina faz parte do espaço de nomes (EN)? juntar no mesmo EN SF com regras de prod. de A forma- Heterogeneidade: habitual de construir o espaço de nomes é com basediferentes em pontos de nomes montagem (mounting points): permite estabelecer a associação entre dois SF distintos, ligando o nome de um ficheiro (normalmente um directório) de um SF à raiz do outro SF. Acessos subsequentes ao directório, são redireccionados para o outro SF. O ponto de montagem passa a conter, para além do identificador do SF, a identificação do servidor por ele responsável. 8..3. Compatibilidade da Interface de Programação Tentou aproveitar-se o do centralizado, mas o SDF coloca novos problemas como necessidade de introduzir novas chamadas sistema ou a obrigação de impor uma semântica diferente para algumas das chamadas existentes. Ex. open() pode falhar porque servidor não está acessível. Os fabricantes esforçam-se e os SDF preservam as interfaces de programação dos sistemas onde se integram. 8.2.4. Integridade presença de falhas No SDF há várias na fontes adicionais de incoerências: - Faltas nas comunicações (mensagens perdias ou duplicadas) - Faltas no servidor ou num cliente antes de este actualizar o disco com os dados da cache. As políticas de gestão da cache têm de prever estes problemas mesmo que à custa de alguma perda de desempenho.
8.2.5. Controlo de concorrência Para gerir o acesso concorrente ao mesmo ficheiro por vários processos. Exige aqui um mecanismo de sincronização distribuído, o que se pode tornar extremamente complexo e ineficaz. A maioria dos SFD oferece soluções parcelares. 8.2.6. Segurança Existem 3 aspectos fundamentais: - Autenticação : problema fundamental. Normalmente usam-se mecanismos de chave simétrica (ex. Kerberos) para autenticar os clientes do SDF - Controlo de Acesso : mecanismos iguais aos SDF centralizados - Privacidade : normalmente é deixado a cargo das aplicações. 8.2.7. Localização Quando há vários servidores tem de haver um mecanismo de localização (em que servidor) do ficheiro que se procura. Normalmente resolve-se agrupando os ficheiros em volumes, em que cada volume é idêntico a um SDF centralizado e os vários volumes são interligados através de pontos de montagem. 8.2.8. Mapeamento nos dispositivos físicos A gestão dos dispositivos físicos passa a ser feita apenas no servidor, o que permite simplificar o processo de gestão dos discos físicos. 8.2.9. Disponibilidade A concentração num só servidor levanta o problema de todos os ficheiros poderem ficar inacessíveis. A dispersão pode ser a solução mas pode ainda conduzir a maiores problemas se os vários ficheiros necessários a uma dada aplicação estiverem dispersos. Para aumentar a disponibilidade usa-se a recuperação de falhas no servidor (cliente interpreta como serviço lento) e a replicação (normalmente de volumes, mas só para leitura). 8.3. Características dos Acessos a Ficheiros 8.4. Arquitectura dos SDF Têm normalmente uma arquitectura cliente-servidor. A comunicação utiliza um mecanismo RPC. O servidor armazena os ficheiros no seu disco local e exporta a interface RPC, na qual há uma correspondência quase directa entre as chamadas sistema e as rotinas exportadas pelo servidor. 8.4.1.quase Arquitectura do cliente de fazer parte do SO. As mesmas chamadas sistema funcionam Tem obrigatoriamente tanto para o sistema centralizado como para o distribuído. Por esse motivo, tem de ser o código de cada chamada sistema a verific ar se o ficheiro a que esta se destina é local ou remoto. Se for local, chama a componente do SDF centralizado. Se for remoto, então terá de chamar a rotina de adaptação (stub) para efectuar o RPC para o servidor. A decisão sobre o ponto de agulhagem entre o SDL e o SDF pode ser feita em vários pontos: - Logo no início deste processo, por exemplo, nas rotinas de interface ou nas funções sistema correspondentes; - No fim do processo, na fase de acesso ao disco, correspondendo basicamente a um acesso remoto ao disco - Algures a meio do processamento, num ponto onde seja possível uniformizar as várias chamadas sistema e obter o melhor desempenho possível. Newcastle Connection tentou a primeira mas tem 2 problemas: -- desempenho cliente não tem hipótesededecada usarchamada cache local) incapacidade inaceitável de lidar com(porque SO heterogéneos (semântica tem de ser exactamente igual no cliente e no servidor) A segunda é limitada, porque se o servidor não trabalha ao nível do ficheiro, mas do bloco, perde a possibilidade de garantir a coerente utilização do ficheiro (na cache) pois servido r ignora quem está a usar o ficheiro.
A 3ª é a normalmente adoptada, depois de algum processamento no cliente, mas dando conhecimento ao servidor de qual o ficheiro e bloco a aceder, pelo que se pode usar a(s) cache(s), no lado do cliente e no lado do servidor. Cliente e servidor podem usar SO diferentes, apenas precisando de se adaptar ao nível onde é feita a agulhagem (ex.NFS) 8.4.2. Arquitectura do Servidor Executa-se normalmente dentro do espaço de endereçamento do núcleo, o que lhe permite utilizar uma interface optimizada para aceder aos ficheiros. O servidor é normalmente composto por várias tarefas concorrentes. Desta forma, podem estar vários pedidos a ser servidos simultaneamente. As componentes cliente e servidor (inclusive de SO diferentes) podem coexistir na mesma máquina. 8.5. SOLUÇÕES TÉCNICAS 8.5.1. Nomes e Localização A organização do espaço de nomes é fundamental. Determina em larga medida a visão que os utilizadores têm do sistema e a capacidade que os administradores têm para o gerir de forma eficiente. É construído ligando vários sistemas de ficheiros centralizados através de pontos de montagem (comando mount). Desta forma indica-se não só a indicação do SFC, mas também a identificação do servidor onde está esse SF. O ponto de montagem é uma estrutura, normalmente volátil (desaparece quando se reinicializa o SO) que fica associada ao directório onde é efectuada a montagem. Quando um directório que tem associado um ponto de montagem é acedido, o sistema verifica que não se trata de um directório vulgar e, em vez de aceder ao directório do disco local, reencaminha o pedido para o servidor referenciado no ponto de montagem. ex: $ mount dir serv sf Este mecanismo está intimamente associado à localização dos ficheiros. Um ficheiro é localizado quando se resolve o seu nome. A resolução no Unix produz um inode. No SDF é um vnode (inode virtual), cujo identificador tem de ser único a que chamamos fhandle. O objectivo no SDF é pois traduzir um nome num fhandle, para com ele construir um vnode. O ponto de montagem armazena o fhandle do directório raiz do sistema de ficheiros montado. Alguns sistemas usam um formato fhandle impuro que contém a localização do ficheiro, outros usam um servidor de nomes intermédio. A resolução do nome pode ser iterativa. Uma optimização é enviar ao servidor remoto toda a parte do nome que falta resolver. A parte recursiva pode ficar a cargo do servidor de nomes ou do cliente. Os sistemas que suportam a noção de volume permitem um nível de flexibilidade adicional. No ponto de montagem é indicado não o par servidor-SF mas apenas o identificador do volume. A tradução entre o identificador de volume e endereço do servidor pode ser feita por uma tabela replicada em todos os servidores. As alterações da tabela são propagadas pelo administrador. 8.5.2. Cache É a técnica fundamental para um bom desempenho (e escalabilidade) em SFD. Situa-se nos clientes e memoriza (numa memória rápida) os últimos blocos a que a máquina cliente acedeu. Arquitecturas de cache Tanto o cliente como o servidor continuam a aceder à sua memória secundária através da cache já existente no sistema de ficheiros centralizado (ex. NFS). Poupa-se tempo na busca da informação e na sobrecarga da linha e do servidor. A cache dos sistemas implementa ejáa2escrita mecanismos fundamentais da optimização do desempenho: a leitura centralizados em avanço (read-ahead) retardada (write-back). A efectividade da cache é comprovada pela análise das características dos acessos aos ficheiros, na qual se mostrava uma grande localidade de acesso aos ficheiros. A cache do servidor faz todo o sentido porque, muitas organizações têm clientes de baixo porte (pequenas caches) e um servidor de grande porte (grande cache). Desta forma uma falta na cache do cliente pode ser servida pela cache do servidor (é mais rápido do que ler no disco local).
A cache dos clientes pode ser em memória central ou em disco, o que permite ficheiros para dias ou semanas.
Coerência da cache A coisa pode começar a complicar-se quando as operações não são só de leitura (mais frequente), como implícito anteriormente, mas também de escrita e que dois ou mais clientes acedem simultaneamente ao mesmo ficheiro. O principal problema a resolver numa cache é a sua coerência, isto é, os valores que podem ser retornados pelas operações de leitura. Informalmente, um sistema de cache está coerente se a informação lida por um cliente for a que foi escrita mais recentemente, por esse ou por outro cliente. Como nos sistemas distribuídos as escritas não se podem propagar imediatamente, considera-se que as escritas de um cliente têm de poder ser lidas por outro desde que estejam suficientemente separadas no tempo e que as escritas no mesmo bloco por vários clientes têm de ser vistas pela mesma ordem por todos os clientes. Nos SDF a responsabilidade de manter a coerência pode ser atribuída aos clientes ou aos servidores. Se for do cliente este tem de se certificar que a cache está coerente antes de lhe aceder. Isso faz-se contactando o servidor com uma mensagem de controlo que é respondida rapidamente. Se válida utiliza-a, se não, pede ao servidor a mais recente. Uma optimização comum é o servidor, no caso de inválida, responder logo com a info válida, outra é o cliente assumir que está válida dentro de um período de tempo (ex. 5 seg.). Se a responsabilidade for do servidor, o cliente utiliza sempre a info da sua cache. Se for inválida é da responsabilidade do servidor enviar uma mensagem a todos os clientes para estes descartarem a info em causa. Quando os clientes lhe acederem encontram a info inválida e solicitam cópia ao servidor. Esta última é semântica mais precisa mas obriga o servidor a trabalho extra (manter estado com informação sobre todos os clientes e ficheiros em utilização). Propagação das alterações É problema relacionado com o anterior mas mais subtil, pois determina quando é que uma escrita de um cliente deve ser vista pelos outros clientes. Idealmente seria imediatamente, mas isso pesa muito no desempenho. O NFS envia alterações de 30 em 30 s para o servidor. Outra é quando se precisa de usar um bloco modificado, tem de ser primeiro enviado ao servidor. Quando o ficheiro é fechado todos os sistemas propagam alterações para o servidor. É prático pois raramente há a partilha do mesmo ficheiro por vários utilizadores (ex. AFS – o fecho tem a semântica de o servidor invalida primeiro as caches de outros clientes e atomicamente actualiza o ficheiro para conter a nova versão). NFS usa esquema mais simples enviando actualizações ao servidor mas não garantindo que fica logo em disco. Sistemas que procuram replicar o SFC (Sprite) têm 2 modos. Igual ao AFS e sem cache para quando o mesmo ficheiro está aberto por dois clientes, um para escrever outro para ler. Alterações à metainformação dos ficheiros (raro) são normalmente propagadas de imediato ao servidor, minimizando as incoerências que poderiam ocorrer se o servidor for abaixo. Protocolo de comunicação Info de controlo o protocolo baseia-se num RPC sobre um protocolo de transporte do tipo datagrama. Dados: As organizações de cache baseadas em blocos em memória (NFS) trocam sempre blocos do ficheiro, podem usar também protocolo de transporte baseado em datagrama. A aproximação de transferir grandes segmentos ou ficheiros completos (AFS) permitem utilizar protocolos optimizados para utilização da largura de banda quando se transferem grandes quantidades de dados. A contrapartida é trx. mais do que o necessário. Resumo da Cache - Informação a manter na cache: dados, metadados (inodes) e nomes. - Unidade de dados na cache: Bloco, segmento de ficheiro ou ficheiro completo - Responsabilidade de manter a coerência da cache: cliente ou servidor - Propagação das alterações: quando ficheiro é fechado, outras alturas. A metainformação é de imediato
- Protocolo de comunicação: baseado em RPC, usa datagramas para info de controlo e datagramas ou protocolos com ligação para transferir ficheiros. 8.5.3. Escalabilidade Determina quantos clientes e servidores o sistema consegue suportar de forma eficiente. Factores que a limitam: 1. Desempenho: A carga no servidor aumenta com o nº de clientes. O factor de carga depende sobretudo da organização da cache. Cache em memória central dá para poucas dezenas de clientes. Em disco é muito superior pois o papel do servidor é só carregar os ficheiros na cache do cliente e depois todos os acessos são locais. Como as caches são maiores (cabem vários working-sets) considerando uma semana. Como a maioria dos ficheiros são acedidos para leitura, o servidor não é pura e simplesmente contactado. Só quando fecho os ficheiros é que seguem para o servidor os modificados. acresce que a maioria dos ficheiros são privados do utilizador, poucas alterações para os outros utilizadores o servidor tem de fazer. assim, o principal factor de carga do servidor é a escrita retardada dos ficheiros modificados nas caches locais. Ex. o AFS foi concebido para suportar centenas ou milhares de clientes. 2. Organização do espaço dos nomes: Organizações uniformes do espaço de nomes, de forma a este ser visto de forma idêntica por todos os utilizadores, são mais escaláveis, porque permitem diminuir a complexidade global do espaço de nomes e porque limitam a construção de pontos de montagem aos servidores, sendo então independentes do nº de clientes. Um outro ponto importante é o espaço de nomes conter mecanismos para a definição de domínios e sua interligação através de outros protocolos de nomes. O AFS usa o conceito de célula (normalmente uma empresa), idêntico ao do serviço de nomes do DCE. a célula é autosuficiente em todos os aspectos e podem ser interligadas através de outros sistemas de nomes como o X.500 ou o DNS construindo um SFD à escala mundial. 3. Administração do sistema. 8.5.4. Segurança 1. Autenticação: Normalmente, agora são baseados em chave privada. Cada mensagem contém um autenticador cifrado com uma chave de sessão, anteriormente negociada com o servidor de autenticação. Os dados são normalmente enviados em claro. O AFS foi dos primeiros a usar o Kerberos. 2. Controlo de Acesso: Similar aos dos centralizados mas com mecanismos mais sofisticados como as Listas de Controlo de Acesso (cap.6) 3. Privacidade: Tem 2com aspectos: Comunicação com o servidor – os dados são apenas cifrados para trx. na rede, a mesma chave de sessão, mas evita-se por causa do desempenho. Em serem alternativa podem ser cifrados no cliente com base numa chave fornecidas pelo utiliz ador e enviados para o servidor já cifrados (vantagem de ser independente do SFD e os dados são guardados cifrados no disco) – mecanismo implementado a nível de aplicação (ex. PEM). 8.5.5. Disponibilidade e Tolerância a Faltas É conseguida distribuindo cópias por vários servidores. A replicação pode ser feita a nível do SO (cap.7) ou do SFD. Neste caso o SDF controla onde estão as réplicas e encaminha os pedidos (no ponto de montagem). cada cliente é normalmente configurado com um servidor preferencial. A unidade de replicação é normalmente o volume ou a partição lógica e é decisão do administrador de sistema quais e onde. A maioria só suporta replicação de volumes para leitura. O AFS diferencia volumes comuns dos só para leitura. 8.5.6. VáriosHeterogeneidade tipos: 1. Máquinas de arquitecturas diferentes (e SO diferentes) partilhem o mesmo SDF; 2. Utilizador numa máquina possa aceder, de forma uniforme, a SDF diferentes situados em máquinas distintas. Na primeira o SDF tem de suportar dados em diferentes representações, mas as aplicações é que os convertem.
8.5.7. Administração Embora as opções de arquitectura se dividam entre distribuir os ficheiros pelas várias máquina ou concentrá-los num servidor, é unânime que a administração deve ser centralizada e integrada. Por ex. o NFS possui utilitários (ex. ONC) que permitem manter base de dados centralizada com toda a informação relevante do ponto de vista da administração, como os ficheiros de configuração, de definição de utilizadores, etc. Nos sistemas de arquitectura centralizada, como o AFS, a gestão concentra-se no servidor. Os clientes só têm o endereço dos servidores de autenticação e de ficheiros. A administração fica assim simplificada, mas é mais complexa para administradores. Os 4 aspectos importantes na administração de um SFD, são: 1. Gestão de Utilizadores; 2. Gestão do Espaço de Nomes 3. Gestão do Espaço de Disco 4. Salvaguarda Periódica dos Ficheiros (backups) A primeira centra-se no ficheiro de configuração que define o nome de utilizador, palavra chave, uid, gid (ficheiro /etc/passwd no Unix). Em sistemas de arquitectura distribuída, como o NFS esse ficheiro é mantido num ponto centralizado e é difundido pelas máquinas clientes quando for modificado. Nos centralizados (AFS) a identificação dos utilizadores é feita por acesso remoto ao servidor de autenticação usando um modelo semelhante ao Kerberos. A segunda refere-se aos pontos de montagem. É mais simples no AFS, pois estes estão todos no servidor. No NFS também pode ser mantido de forma centralizada e difundido, para que cliente tenham visão global. A 3ª é complexa e por vezes a única solução é acrescentar discos onde falta o espaço. Quando os ficheiros estão central izados no servidor é mais fácil a gestão. O AFS tem a noção de volume que corresponde a partição lógica, sendo que a zona de cada utilizador corresponde a um volume. Os volumes são as unidades de composição do espaço de nomes e podem ser mapeados em qualquer partição física do disco. Desta forma pode-se transferir volumes para discos que tenham espaço, de forma transparente e até e, copy-on-write. A 4ª pode-se fazer de qualquer máquina pois os ficheiros estão acessíveis em todo o lado. 8.6. NETWORK FILE SYSTEM (NFS)
