CAP 1.

INTRODUO Neste livro procura-se analisar a evoluo dos SO para responder aos desafios colocados pela distribuio e pela evoluo da arquitectura dos computadores. Os desafios continuam essencialmente os mesmos: - Simplificar a interface com o sistema - Extrair o mximo 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 alm do ncleo, o conjunto de servidores, bibliotecas e protocolos que o complementam e permitem uma integrao transparente em sistema distribudos. 1.1. Condicionantes da Evoluo 1.1.1. A Tecnolgica 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 aviao e sector bancrio, que definiram assim requisitos para os sistemas interactivos e transaccionais. Desenvolveram mecanismos comunicacionais; Operadores pblicos ofereceram servios de de dados (ex. X.25); Internet teve um impacto enorme sobre os sistemas distribudos demonstrao prtica de problemas de segurana e de gesto que se colocam a esta escala. Operadores continuam com RDIS e ATM que permitir ligar inmeros equipamentos computador. Simultaneamente as LANs evoluiram. os trx. na ao

Computadores Pessoais Os gestores das empresas passaram a considerar a hiptese de descentralizarem o seu suporte informtico, colocando mquinas de menor porte junto dos grupos que as utilizavam directamente. a distribuio tornou-se, assim, uma caracterstica inevitvel nos sistemas informticos actuais. A evoluo interessante deu-se quando foi possvel inserir mecanismos que permitem interligar um grande nmero de computadores pessoais partilhando, coerentemente, informaes e servios. O culminar deste processo deu origem a um novo paradigma no desenvolvimento das aplicaes informticas, o modelo cliente-servidor. Sistemas Abertos Durante muito tempo, caso se mudasse de fabricante tal implicava a substituio do SO e, consequentemente, do ambiente de desenvolvimento das aplicaes. Utilizadores pressionaram para Sistemas Abertos, onde a ideia simples uma separao clara entre o hardware e o SO e entre este a as aplicaes. Isto levou ao conceito de plataforma, que procura virtualizar as caractersticas especficas de um dado equipamento ou programa, colocando a nfase na definio de uma interface normalizada que permite a sua fcil integrao em sistemas existentes ou a desenvolver. Arquitecturas Multiprocessador Os processos de microelectrnica vo-se aproximando do limite e o custo de desenvolvimento de um novo microprocessador so elevados, da o interesse pelas arquitecturas multiprocessador, que permitem aumentar o desempenho, mantendo basicamente os ambientes de desenvolvimento de software. Interessa ento por os processos num ambiente de concorrncia real. Neste livro s estamos interessados em arquitecturas MIMD (Multiple Instruction, Multiple Data), onde cada processador executa as suas instrues e trabalha sobre os seus dados. Podem ser classificadas em 2 categorias: de memria central partilhada (bus comum, os mais comuns) e de memria distribuda (atravs de rede local ou sistema dedicado de alto dbito).

1.1.2. Os Requisitos dos Utilizadores por actividade profissional: - Utilizadores finais dos sistemas computacionais - Os programadores - Os gestores de informtica Requisitos dos utilizadores finais Funcionalidade dos sistemas: Isolamento dos detalhes Transparncia na utilizao do sistema -> comandos, nomes e semnticas idnticas para todos os objectos sob controlo do SO. A vantagem da distribuio mais perceptvel para o utilizador vulgar relaciona-se com a partilha de informao. Uma outra vertente da distribuio a possibilidade de usar os computadores para suportar mais eficazmente a comunicao ente utilizadores humanos. tambm importante a ergonomia das interfaces. Qualidade dos sistemas: Segurana; Fiabilidade; Disponibilidade. Requisitos do Programador Para alm da funcionalidade do mecanismo de suporte, pretende que as interfaces com o software sistema se integrem harmoniosamente nos ambientes de programao. Um requisito, relacionado com os sistemas abertos, a simplificao da portabilidade de aplicaes atravs da definio de interfaces normalizadas ou API (Application Programming Interface). O programador tambm pretende um ambiente de programao que simplifique o desenvolvimento da aplicaes, tornado idealmente o cdigo independente da arquitectura das mquinas, da rede, dos protocolos, dos SO locais e mesmo do n de mquinas ou utilizadores. Requisitos do Gestor Para rentabilizar: 1. Capacidade de evoluo modular 2. Extensibilidade 3: Aumento da fiabilidade e disponibilidade 4. Capacidade de gesto global do sistema 1.2. Dificuldades e Vantagens Introduzidas pela Distribuio 1.2.1. Os Problemas Comunicao Exclusivamente por Mensagem Os multiprogramados tm mecanismos de comunicao por mensagem, mas internamente ao ncleo tudo feito por espao de endereamento partilhado. Na distribuio no h partilha de memria fsica, o que dificulta as coisas. H sempre perdas, duplicaes e atrasos inseridos pelas vrias entidades (gestores de perifricos, routers, armazenamento das mensagens, etc.) Para garantir a fiabilidade e sequenciamento das mensagens necessrio um nvel suplementar de protocolos que assegurem estas propriedades. Modelo de Faltas Tm sempre um maior nmero de causas e maior probabilidade de ocorrncia devido ao maior n de componentes. Uma rede introduz um novo conjunto de componentes que pode falhar (controladores de rede, ligao ao sistema de cablagem, cabos, equipamentos de transmisso, etc.). H tambm a correlao das falhas. A deteco tambm mais complexa sendo difcil distinguir entre a falha de um servidor ou apenas um congestionamento do servio. O modelo de tolerncia a faltas tem de contar com tudo isso e introduz perdas no desempenho dos sistema. Distribuio do Sistema Operativo

O software sistema encontra-se repartido por diversas mquinas, dificultando a sincronizao e o acesso informao de gesto. Por exemplo a descodificao do caminho de acesso a um ficheiro d-se no interior do ncleo numa nica operao, nos centralizados. Outro exemplo: A sincronizao nos sistemas centralizados baseia-se numa aco atmica a nvel dos mecanismos elementares que controlam o acesso memria. Numa arquitectura distribuda tal impossvel, havendo necessidade de existncia de protocolos especializados na sincronizao. A sincronizao um dos aspectos delicados. O tratamento do tempo tambm apresenta muito mais dificuldades no distribudo, havendo necessidade de um protocolo (complexo) de sincronizao de relgios. Segurana A existncia das redes introduz grande vulnerabilidade no sistema, porque, na maioria delas, no existem mecanismos de segurana fsica que impeam a escuta das mensagens ou mesmo a sua substituio e falsificao. Por outro lado qualquer utilizador pode instalar software que no respeita as boas maneiras A validao da identidade dos utilizadores que trocam informao nas redes e dos respectivos direitos passa a ser um problema complexo. Para alm disso h os problemas de interligao de servios pblicos e privados com polticas de segurana diversas. Heterogeneidade Com mltiplas mquinas de fabricantes diversos, a representao dos dados necessariamente heteognea (ex. big endian ou little endian). Desempenho Introduz-se um acrscimo do tempo de trx. de mensagens que pelo menos uma ordem de grandeza superior ao da comunicao local. Isto no s devido trx. fsica mas tambm ao software usado para garantir comunicao fivel, segura e normalizada. 1.2.2. Vantagens Potenciais Adequao Repartio Geogrfica A centralizao baseada em acesso por terminais remotos implica custos de comunicao significativos, porque no tira partido da possibilidade de trabalho local, em particular na interaco com o utilizador final das aplicaes. Modularidade Os investimentos podem ser, portanto, programados da forma mais adequada ao crescimento da organizao. Extensibilidade A capacidade de evoluo de um sistema centralizado limitada, devido essencialmente estrutura do bus e do processador. Na distribuda a capacidade de processamento pode ser aumentada facilmente. Para alm disso os SD pode expandir-se com mquinas de diferentes geraes tecnolgicas, no existindo estruturas centrais (bus, controladores) que limitem partida a capacidade fsica de evoluo. Maior Disponibilidade Advm da existncia de mquinas independentes que podem continuar a assegurar um servio quando uma delas falha (replicao/redundncia) Desempenho Optimizado No na eficincia de uma mquina isolada que os sistema poder fornecer maior desempenho, mas na possibilidade de atribuir s mquinas mais adequadas as tarefas que elas podem optimizar.

Custo Argumento fundamental. baixa de custos nos PCs e servidores multiprocessador. claro que os sistemas distribudos implicam custos de comunicaes, equipamento de rede e de superviso, mas eliminam outros como os grandes centros de clculo com ambiente controlado e elevados custos de explorao. 1.3. ARQUITECTURA DO SISTEMA A programao de aplicaes executadas em sistemas computacionais independentes que no partilhem uma memria comum pode efectuar-se de diversas formas, desde a simples utilizao dos gestores de perifricos da rede, directamente pelas aplicaes, at o SO oferecer transparentemente suporte para as operaes distribudas. 1.3.1. Suporte Comunicao Distribuda Nos primrdios as aplicaes distribudas eram programadas utilizando directamente a interface do gestor de perifrico e cabendo ao programador resolver os problemas de fiabilidade, heterogeneidade, gesto de recursos, etc. A evoluo natural que facilitou a programao e a portabilidade foi a virtualizao destas interfaces, oferecendo uma API estvel suportada pelo SO. Do ponto de vista do programador, o suporte comunicao materializa-se numa biblioteca de funes para envio e recepo de mensagens. Um dos exemplos mais conhecidos o dos sockets do Unix (ex. telnet, ftp). Por ex. o ftp pode ser visto como a cooperao entre 2 aplicaes, uma cliente outra servidor.... A programao efectuada directamente, chamando as funes da biblioteca de sockets, tendo, portanto, uma relao directa com os detalhes dos protocolos. apesar desta soluo ser expedita tem problemas: - Reutilizao cada aplicao reinventa os seus protocolos, gesto de nomes, etc. - Normalizao aplicao proprietria ou pblica - Desempenho A nvel de ncleo melhor - Segurana Quando se implementa o suporte das aplicaes no ncleo mais fcil assegurar mecanismos de proteco. A implementao de aplicaes distribudas, usando apenas os mecanismos de comunicao, apresenta, no entanto, algumas vantagens complementares: - Programao Sistema Tradicional - Facilidade de Adaptao portabilidade para sistemas heterogneos. 1.3.2. Plataformas Cliente/Servidor Numa fase posterior a comunidade acadmica procurou encontrar mtodos e tecnologias para suportar o desenvolvimento de aplicaes distribudas. Inicialmente, as redes foram utilizadas como mero mecanismo de acesso remoto a um computador, mantendo-se as aplicaes no modelo habitual dos sistemas multiprogramados. Era tudo feito em sesso remota e as aplicaes continuavam a executar-se na mquina onde estavam instaladas. Esta soluo no explora eficientemente a distribuio, no utiliza a capacidade total de processamento e obriga a manter uma compatibilidade de interfaces com os multiprogramados, normalmente do tipo alfanumrica, o que paradoxal face ao Windows. Problema semelhante tinha ocorrido no ambiente Unix onde se implementaram ento aplicaes cuja estrutura se baseava na separao entre um programa que implementava o essencial o servidor e outro que implementava a interface o cliente -. A designao de arquitectura Cliente/Servidor estabelece a distino entre 2 tipos de processos com comportamentos diferentes e, portanto, assimtricos: - Os servidores implementam um conjunto de funcionalidades de interesse geral para outros processo com comportamentos que remotamente lhes podem aceder. - Os clientes efectuam a interface com os utilizadores e podem executar parte das aplicaes localmente e acedem remotamente aos servidores. Os servidores devem publicitar a existncia dos seus servios e quais os protocolos utilizados. A identificao dos servios deve ser lgica permitindo a mudana de mquina servidora transparentemente.

Para diminuir a incidncia de algumas limitaes da utilizao directa das bibliotecas das interfaces de comunicao, procurou-se criar um ambiente de suporte que facilite a programao, introduza normalizao para as funes de base, d mais garantia de segurana e tolerncia a faltas e procure optimizar o desempenho. Esta evoluo tem sido apresentada como o objectivo das plataformas cliente/servidor. Embora no exista definio clara e consensual destas plataformas, devem apresentar: 1. Comunicao entre clientes e servidores por chamada de procedimento remoto 2. Linguagem de descrio de interfaces e respectivo ambiente de desenvolvimento 3. Gesto de nomes 4. Mecanismos de segurana para autenticao e privacidade das comunicaes 5. sistema de ficheiros distribudo 6. Sincronizao de relgios A evoluo das plataformas cliente-servidor deu-se na direco dos sistemas distribudos de objectos, de que podem ser consideradas como uma sntese de vrios conceitos: o modelo cliente-servidor, a programao por objectos, as bases de dados orientadas aos objectos. 1.3.3. Sistema Operativo Distribudo A distino que fazemos entre um SOD e um sistema cliente-servidor prende-se com o grau de integrao dos diferentes componentes do sistema. Nos SOD a integrao de todos os mecanismos o objectivo primordial. A gesto de processos permite ilustrar as diferenas. Nas aproximaes anteriores, os processos so locais a uma mquina e qualquer actividade remota passa pela interaco com um processo servidor. Se a gesto de processos for realizada de forma integrada, os processos passam a ser entidades com capacidade de migrar entre mquinas existentes no sistema. esta facilidade permite no s polticas de equilbrio da carga computacional (load balancing), como implementar facilidades de redireco no caso de falhas de componentes do sistema. Uma extenso semelhante poderia ser considerada para a gesto de memria: faltas de pginas colmatadas por outra mquina, transparentemente. A homogeneidade destes SOD um problema complexo. A modularizao da sua estrutura interna tambm uma das preocupaes. A separao entre um ncleo de dimenso reduzida, oferecendo os servios bsicos (gesto de processos, gesto de memria e intercomunicao 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 tcnica que tem vindo a ser seguida na maioria dos sistemas actuais como o Mach e Chorus. Eles usam como base um micro-ncleo com funcionalidade mnima que permite uma evoluo do SO mais flexvel, protegendo o investimento significativo que representa o software aplicacional para uma dada verso do SO. Os micro-ncleos tm diversas vantagens: modularidade, adaptao distribuio, separao entre os mecanismos de base e as polticas de sistema, dando ao programador a possibilidade de escolha de servios adequados s caractersticas de uma aplicao que pode, ela prpria, implementar as suas polticas, por exemplo, de segurana ou de tolerncia a faltas. 1.4. ARQUITECTURAS MULTIPROCESSADOR 1.4.1. Multiprocessadores de Memria Partilhada Os vrios processadores esto ligados memria central atravs de bus partilhado. Os processadores tm cache privada. A coerncia entre as caches dos diversos processadores mantida pelo hardware de gesto de bus partilhado. Nestas mquinas existe apenas uma cpia 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 tm de ter mecanismos para execuo simultnea em paralelo de vrios processos, um em cada processador. estes podem comunicar por pipes, sockets, etc, quer por memria partilhada e semforos. Assim se suportam um maior n de utilizadores ou executar mais trabalhos. Paralelizao do Sistema Operativo Os multiprocessadores obrigaram paralelizao do cdigo do SO para que este se execute correctamente e com bom desempenho nestas arquitecturas.

A paralelizao do cdigo do sistema operativo obriga introduo de sincronizao explcita em todos os seus pontos de entrada, em vez de se basear na ausncia de preempo. Mas regies crticas muito extensas diminui o paralelismo, pelo que esta deve ser efectuada num gro mais fino, dividindo a regio crtica em vrias zonas, cada uma delas protegida por uma varivel de sincronizao. Desta forma possvel ter vrios processadores a criarem simultaneamente processos, pois cada um est normalmente a operar em dados diferentes. As regies crticas globais (atribuio de pid) so de curta durao. Paralelismo a Nvel Utilizador Uma forma de explorar o paralelismo intrnseco de certos algoritmos permitir a execuo em paralelo de vrias tarefas que partilham o mesmo espao de endereamento, dentro do mesmo processo (ex ADA e Modula2). As tarefas so os elementos activos vistos pelo sistema operativo e usados pelo escalonador na atribuio dos processadores. 1.4.2. Multiprocessadores de Memria Distribuda Cada processador tem uma memria privada, interligados por uma rede de alto dbito. A forma de comunicao por mensagens. Podemos ir aqui at centenas ou milhares de processadores. Ao fim e ao cabo um sistema distribudo com rede de interligao fivel permitindo protocolos mais simples; todos os processadores esto sob a mesma administrao e correm o mesmo SO o que simplifica o problema de segurana e de tolerncia a faltas. A viso oferecida ao utilizador e, em grande parte, ao programador idntica a um sistema centralizado. Devido ao seu elevado custo de aquisio e manuteno, estas mquinas tm de ser extremamente robustas e extensveis. O sistema tem de conseguir tolerar a falha de parte dos processadores e reconfigurar-se para utilizar apenas os restantes; h que poder efectuar parties lgicas em que grupos de processadores se comportam como uma mquina autnoma e a contabilizao dos custos de utilizao tem de se feita de uma forma extremamente precisa. A utilizao de micro-ncleos eficazes que asseguram a gesto bsica dos processadores, complementados por servidores que oferecem as funcionalidades dos sistemas clssicos, apresenta-se como a soluo mais promissora.

CAP. 2 REDES DE DADOS 2.1. Introduo Fundamental neste contexto a percepo do modelo conceptual das redes e dos nveis de protocolos com as respectivas interfaces funcionais e mecanismos de endereamento. 2.1.1. A Complexidade das Redes de Dados A complexidade face a uma simples operao de E/S advm, sobretudo, dos problemas estruturais relacionados com a escala e a heterogeneidade mas tambm de um mecanismo a que se exige cada vez mais desempenho e fiabilidade. Esta dimenso (ex. Internet) coloca problemas totalmente novos na interaco do software sistema com o ambiente exterior e que no tem paralelo nas E/S tradicionais. Por outro lado h muitos tipos de rede no que se refere a meios fsicos de transmisso, partilha do meio, mtodos de trx., etc. Isso tem a ver com sistemas proprietrios mas tambm com a tecnologia (diferentes caractersticas de propagao, fiabilidade e imunidade ao rudo, gesto de multiplexagem. Isso tem implicaes no binmio custo/desempenho (hardware, explorao, manuteno). 2.1.2. Redes Locais, Metropolitanas e de Grande Escala A razo da importncia da escala como factor diferenciador da tecnologia das redes, deriva das limitaes associadas banda de trx. disponvel e distncia. Diferentes meios de trx. como par entranado, cabo coaxial, guias de ondas e fibra ptica tm velocidades de propagao, atenuao, taxas de erros e custo diferentes. Dependendo da rea geogrfica de implantao e dos requisitos de explorao, as vrias propostas de arquitectura fsica das redes procuraram encontrar a relao custo/desempenho que optimizasse a estrutura da rede. Comeou com as ofertas dos operadores de telecomunicaes em redes implantadas para voz no original, o que condicionou indirectamente os protocolos de nveis 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 diferena entre redes geograficamente diferentes. Para j h, em termos de escala: LAN Redes Locais extenso inferior a 10km MAN Redes Metropolitanas entre 10 e 100km WAN Redes de Larga Escala acima dos 100km A extenso condiciona tambm o usa-se meios prprios ou de operadores. Nas locais tudo (meios de trx, gesto e equipamentos) da organizao. Nas de longa distncia para alm de ser caro h monoplio, por vezes, dos operadores. possvel 2 abordagens: a utilizao de uma rede pblica de dados; a implementao de uma rede privada, alugando aos operadores apenas os meios de trx. O custo proporcional largura de banda e distncia. a realizao de redes de grande escala, alugando os meios de trx. aos operadores, designa-se por rede privada, sendo normalmente a gesto da rede da organizao e os meios fsicos do operador. Os operadores diversificaram, propondo tambm redes pblicas de dados (X.25, frame-relay, MAN/DQBD, Internet). Na rede privada o investimento inicial elevado mas procura-se uma posterior utilizao intensiva, pois os custos de aluguer so proporcionais ao trfego, para alm de um aluguer. 2.2. Arquitecturas das Redes de Dados Para os utilizadores a interface tipo telefone a ideal. a presso exercida pelos utilizadores no sentido dos Sistemas Abertos tem obrigado a indstria a assumir progressivamente uma atitude que privilegia a normalizao e a definio de esquemas de interoperacionalidade dos diversos sistemas. 2.2.1. Arquitectura Fsica e Lgica As redes so complexas e obrigam considerao de vrios nveis de abstraco (desde as caractersticas dos sinais elctricos ou pticos at s interfaces de programao utilizveis nas aplicaes).

Seguindo a estratgia habitual nos sistemas computacionais de subdividir um problema complexo em vrios nveis de abstraco, procurou-se criar nas redes um modelo que estabelea os principais nveis de abstraco e o modo como estes se relacionam entre si. Uma diviso natural considerar a existncia de 2 nveis, correspondendo arquitectura fsica e arquitectura lgica. A fsica define os meios de transmisso, a topologia descrita pelos sistemas e as ligaes entre os mesmos. A ligao entre os ns da rede depende em grande medida da forma como controlada a transmisso. Uma diferena importante tem a ver com a utilizao de um meio fsico partilhado difuso, ou de ligaes ponto-a-ponto em que os sistemas se interligam aos pares. No primeiro tem de se estabelecer como controlar o direito de transmisso, no segundo a gesto da trx. mais fcil mas o encaminhamento dos pacotes mais complexo. Dependendo destas caractersticas, os ns podem interligar-se ao meio fsico 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 difuso. As topologias mais comuns so tipo bus e anel. A topologia tem relao directa com a forma como efectuado o controlo de partilha do meio. Por exemplo, num anel as ligaes devem ser activas e actuar como repetidores, mantendo o sincronismo de funcionamento do anel, ao contrrio, num bus as unidades de interligao so passivas e podem ser inseridas e retiradas com a rede a funcionar. A arquitectura lgica procura dotar a rede de um conjunto de propriedades adequadas ao seu campo de aplicaes, como por ex. endereamento transparente, desempenho, determinismo na entrega das mensagens, tolerncia a faltas, endereamento em difuso, garantia de ordenamento dos pacotes, etc. Um dos objectivos da diviso por nveis do modelo de comunicao das redes flexibilizar a adopo da arquitectura lgica mais apropriada ao campo de aplicao, independentemente da arquitectura fsica subjacente. Ex. arquitecturas lgicas em anel sobre topologias fsicas em bus. Estou enfim a virtualizar a rede fsica. assim, a arquitectura lgica de uma rede pode ser representada por uma malha de ligaes entre redes que podem ter inclusivamente arquitecturas fsicas diversas. O nvel de separao entre AL e AF diferente no sistema telefnico clssico e nas redes de computadores. 2.2.2. Os Modelos de Referncia (p/ AL) Como existem muitas hipteses, procurou-se definir modelos de referncia que constituam um elemento agregador e sistematizante de toda a arquitectura de comunicao. H os proprietrios. actualmente o modelo mais usado o OSI. Foi definido e normalizado no incio da dcada de 80, reflecte parcialmente a envolvente tecnolgica da poca, por isso tem limitaes. Mas como genrico permite um fcil enquadramento de outras arquitecturas desenvolvidas independentemente e com maior implantao que a OSI. Com origem na Arpanet desenvolveu-se uma arquitectura de rede que conduziu hoje Internet. A famlia de protocolos Internet, mais conhecidos por protocolos TCP/IP, teve um grande desenvolvimento na 2 metade da dcada de 80 e tomou em grande medida o lugar do OSI como tecnologia independente dos fabricantes e portanto como Sistema Aberto realmente utilizvel. menos formal mas mais usado, pelo que o usaremos sobretudo ao longo do livro. O protocolo de transporte OSI tambm. 2.3. O Modelo OSI O objectivo era definir uma arquitectura de comunicao aberta. Ele estrutura a arquitectura de comunicaes num conjunto de nveis ou camadas estanques com funes e interfaces bem definidas. Em cada nvel existe uma interface de servio que define a funcionalidade que esse nvel disponibiliza camada superior e um protocolo que define o formato e o significado das mensagens trocadas entre nveis correspondentes. Em cada sistema existe um fluxo de comunicao vertical atravs das interfaces. Entre nveis idnticos a comunicao feita atravs de um protocolo. O protocolo associado a um dado nvel define 2 aspectos: - O formato das mensagens campos prprios ao protocolo + campo opaco que contm a informao recebida da camada superior.

- O significado e as aces a desencadear em funo de cada mensagem trocada. A estanquidade e encapsulamento obtida atravs de cabealhos. O PDU da camada N igual ao SDU da camada N-1. Uma caracterstica importante dos protocolos em qualquer nvel tem a ver com o tipo de associao entre as entidades que comunicam: - Com ligao (connection oriented) - Sem ligao (connectionless) No 1 caso a comunicao decorre em 3 fases: estabelecimento da ligao, a conversao e a fase de corte da ligao (assemelha-se aos sistemas tradicionais de telecomunicaes). No segundo caso os dados so enviados sem qualquer interaco prvia, existindo, conceptualmente, apenas a fase de conversao (correio). Vantagens e inconvenientes: Os com ligao podem aproveitar a fase de estabelecimento para negociar parmetros relevantes para a fase de conversao, incluindo aspectos de segurana. Podem ainda implementar mecanismos de controlo de erros, que oferecem mais garantias s camadas superiores simplificando-as. Os sem ligao so mais simples e mais eficientes por eliminarem a latncia da fase de estabelecimento. Tendem a consumir menos recursos de memria e processamento. No entanto obrigam ao endereamento completo em cada mensagem consumindo largura de banda e necessria deciso de encaminhamento em cada n. caso as taxas de erros sejam baixas e as camadas superiores implemente controlo de recuperao de faltas, so mais eficientes para comunicaes que no envolvem grandes volumes de dados. A difuso tambm mais fcil. O modelo OSI define protocolos com ligao para os nveis de transporte e superiores, e nos de rede e de enlace tambm so comuns o que pode originar trocas de 18 conjuntos de dados antes da conversao. A interface de servio definida com base num conjunto de primitivas abstractas: Pedido, Indicao, Resposta e Confirmao. Estas funes abstractas cumprem o objectivo de independncia do modelo OSI, definindo MC independente do SO e arquitectura de software de comunicaes. A desvantagem obrigar cada implementao a esforo adicional de adaptao ao modelo e condicionamento do desempenho devido complexidade. Ao distinguir claramente entre servio prestado e protocolo implementado pretendeu-se arquitectura modular e flexvel. Este isolamento raramente se consegue em implementaes reais. 2.3.1. Os Nveis Inferiores Nvel Fsico Tem a funo de conseguir transmitir correctamente um bit sobre o meio fsico de interligao. Preocupa-se com caractersticas de propagao do sinal como a velocidade, atenuao, imunidade ao rudo logo nveis elctricos e temporais e protocolos de codificao que tm em conta os parmetros de funcionamento da rede (taxa de erros, recuperao de relgio). Tambm interface elctrica e mecnica. Nvel Lgico ou de Ligao de Dados (data link) Utiliza os servios do nvel fsico para o envio de pacotes de dados ou tramas (frames) entre 2 mquinas ligadas mesma rede fsica. Encapsula numa trama que tem delimitadores, endereo do destinatrio, informao de controlo e CRC. Uma funo primordial deste nvel o contrlo da multiplexagem do meio de trx., de modo a poder enviar a trama. No modelo OSI, este nvel tambm responsvel por garantir que os dados enviados so recebidos correctamente sem serem adulterados por faltas no meio fsico. Usa-se deteco de erros (CRC) e retrx. Nas redes de grande escala tradicionais este nvel era tambm responsvel pelo controlo de fluxo com mecanismos de janela deslizante.

Tambm se coloca aqui o problema da unidade bsica de informao a trx. pois os dados dos nveis superiores podem estruturar-se em byte oriented (ASCII, EBCDIC) ou bit oriented. O SDLC da IBM bit oriented com prembulo 01111110 e bit stuffing. Nvel Rede Neste nvel considera-se a rede como uma entidade lgica que interliga mquinas independentemente das redes fsicas a que esto ligadas. responsvel pelo encaminhamento (routing) independentemente da rede fsica. Esta camada foi criada na ptica das redes malhadas de grande escala. A funcionalidade deste nvel foi alvo de controvrsia. 2 filosofias: A defendida pelos operadores de telecomunicaes pretende que o nvel rede assegure uma ligao fivel que garanta a sequencialidade e o controlo de fluxo. Outra da Arpanet/Internet que considera que o nvel de subrede inerentemente pouco fivel pelo que a fiabilidade deve ficar a cargo do nvel de transporte de extremo a extremo (ex.IP). Neste caso o nvel deve s encaminhar. 2.3.2. Nvel de Transporte Oferece um servio de trx. de mensagens que permite a comunicao entre utilizadores finais. Dispe de vrias classes de qualidade de servio. Noutra perspectiva, o 1 nvel em que os mecanismos de comunicao so virtualizados criando canais de comunicao entre processos. Existe normalmente a opo entre servio com (criam uma abstraco de um canal de dados fivel e bidireccional) ou sem ligao (datagrama). Para garantir uma comunicao fivel, tem de detectar a existncia de faltas (corrupo de dados, perda de mensagens, duplicao, recepo na ordem incorrecta do nvel inferior) e assegurar a sua recuperao. Deteco CRC, para alm do de rede pois pode haver falhas na memria (tampes das mquinas finais ou encaminhadores). O receptor deve confirmar a mensagem. Deve tambm haver temporizador. A recuperao feita por retrx. que, por sua vez pode originar duplicaes e mensagens fora de ordem. As duplicaes e alteraes de ordem so detectadas enviando ns de sequncia. Mas a garantia de envio fivel da mensagem no normalmente suficiente para uma aplicao. Aplicao pretende tambm assegurar outros requisitos como processo servidor est operacional e que recebeu correctamente o pedido. Para tal preciso confirmao da aplicao; como ela confirma implicitamente a recepo adequada a nvel de transporte, a sobrecarga suplementar de um mecanismo de transporte fivel pode ser evitada. Isolar o utilizador das limitaes fsicas da rede implica que o transporte efectue a fragmentao das mensagens e sua numerao. Outro problema que a capacidade do tampo do receptor limitado, pelo que o emissor tem de ser bloqueado controlo de fluxo. Nos protocolos com ligao habitual considerar um mecanismo de janela que corresponde ao nmero mximo de pacotes que possvel enviar antes de receber confirmao do receptor. Uma outra facilidade importante para algumas aplicaes a garantia de sequencialidade. ex. SGBD. O assinalar de condies assncronas depende do SO, por exemplo na interface de sockets do Unix, existe a possibilidade de notificar o utilizador da quebra do canal com ligao atravs de um signal. Sintetizando as propriedades habituais do servio de transporte: - Com ligao/Sem Ligao - Garantia de entrega fivel da mensagem - Fragmentao - Controlo de fluxo - Mecanismo de janela - Garantia de ordem - Mecanismo de deteco e notificao de excepes que correspondem a quebra de servio 2.3.3. Os Nveis Superiores

So locais a cada extremo da comunicao e transparentes rede. Reflectem os problemas inerentes compatibilizao de sistemas heterogneos, por forma a permitir a comunicao transparente para as aplicaes e utilizadores. Nvel de Sesso Tem por funo a multiplexagem de vrias instncias de comunicao sobre a mesma ligao de transporte. Nvel de Apresentao Controla a representao dos dados a trocar entre sistemas heterogneos. Nvel de Aplicao Engloba as funcionalidades relativas s aplicaes propriamente ditas. No mbito do OSI definiram-se aplicaes para terminal virtual, transferncia de ficheiros, correio electrnico, etc., pelo que num ambiente OSI h aqui uma srie de subnveis que pretendem maximizar a reutilizao de componentes comuns. 2.4. O Modelo Internet Resultado de projectos de investigao na rea da comunicao de pacotes. Tem 4 nveis. Tem por base um modelo de concatenao 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 endereo Internet.. - O nvel de subrede protocolos de ligao de dados associados aos meios fsicos de trx. utilizados - Nvel de Interligao de rede assegura o encaminhamento dos pacotes - Nvel de transporte envia e recebe as mensagens das palicaes que interactuam de extremo a extremo - Nvel de Aplicao H uma camada nuclear: o nvel de interligao de redes. Baseia-se num nico protocolo (IP) que define os aspectos mais relevantes para toda a arquitectura da Internet: - O endereamento - A distino entre n (host) e rede As diferenas de fundo com OSI so: - O modelo Internet define comunicao entre redes. O foco na interligao de redes em vez da interligao de sistemas - O modelo no pretende tratar a tecnologia da rede fsica Nvel de Subrede A camada inferior do modelo Internet especfica a cada tecnologia fsica de transmisso, sendo suportada por RFC prprios que definem o modo como o encapsulamento do nvel 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 aces associadas, no existindo uma interface de servio para cada camada. Embora tenha o inconveniente de no garantir a opacidade entre nveis, tem a vantagem de as normas de encapsulamento tirarem partido das caractersticas especficas da tecnologia de subrede para uma implementao eficiente, evitando lacunas de especificao, fonte de problemas de interoperacionalidade. Existem especificaes para o encapsulamento dos pacotes do nvel IP para todas as tecnologias (redes locais, ATM, Sonet, linhas srie, etc.) Nvel de Interligao de Redes O objectivo disponibilizar s camadas superiores um servio de encaminhamento dos pacotes atravs da rede. Rede formada por vrias subredes independentes e de tecnologias diferentes.

O servio oferecido pelo nvel IP no d qualquer garantia de fiabilidade. melhor esforo possvel. Se houver problemas de erro de trx. ou congestionamento, o nvel superior no avisado. Nvel de Transporte Tem caractersticas semelhantes camada OSI correspondente, nomeadamente esta camada apenas existe nos sistemas no extremo da conversao. Na famlia Internet definem-se 2 protocolos nesta camada: o TCP e o UDP. O TCP oferece um servio semelhante ao de um canal de trx. fivel. O TCP oferece um servio de transporte com ligao que garante a entrega de pacotes corrompidos, a eliminao de duplicaes e a entrega sequencial. O TCP define um esquema de endereamento, utilizando o conceito de porto, para identificar o utilizador final. O UDP oferece um servio de transporte datagrama, no fivel, com base no melhor esforo, como o IP. Na prtica baseia-se na utilizao dos servios do IP, adicionando checksum e endereamento dos portos de acesso ao servio de transporte UDP. Os portos UDP e TCP pertencem, portanto, a espaos de endereamento distintos. Nvel de Aplicao Inclui todos aqueles protocolos, servios e aplicaes implementados em cada n da Internet que utilizam os servios de transporte para fornecer funcionalidades adicionais. So transparentes rede, ou seja, em toda a infra-estrutura de comunicao que interliga os ns no tm qualquer componente. Ex. SMTP, TELNET, FTP, DNS. A cada um desses servios/aplicaes normalmente atribudo um porto especfico de transporte (well known ports). 2.5. Redes Locais de Computadores So a tecnologia de comunicao mais relevante para a interligao de sistemas computacionais nas subredes. Foram um dos factores decisivos na evoluo das arquitecturas centralizadas para distribudas. A comisso 802 do IEEE liderou o processo e foi definido que apenas analisaria redes coma as seguintes caractersticas: - Com partilha efectiva do meio fsico - Apenas os 2 primeiros nveis do modelo OSI - Com cobertura geogrfica de 1 a 20km A comisso decidiu-se logo pela difuso em vez do ponto-a-ponto e pelas topologias em anel e bus em vez da estrela da comutao telefnica. 2.5.1. Controlo de Acesso ao Meio de Comunicao Um dos primeiros problemas foi a inadequao da subdiviso considerada no modelo OSI entre nvel fsico e de ligao de dados e a estrutura de controlo de trx. da maioria das redes de dados. O nvel de ligao de dados responsvel pela partilha do meio fsico, contudo impossvel definir uma mquina de estados eficiente para o nvel de trama que fosse independente do modo como o envio de 1 bit se processava. Isto levou criao de um subnvel designado por Controlo de Acesso ao Meio MAC. Multiplexagem na Frequncia a soluo tradicional para multiplexar vrios canais de comunicao num meio fsico. So redes de banda larga. A desvantagem so o custo, complexidade do equipamento de modulao/desmodulao e a dificuldade da gesto dinmica da atribuio das frequncias 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 vrios emissores que querem trx. simultaneamente. Multiplexagem no Tempo: Sncrona

O tempo dividido em intervalos de durao fixa, sncronos com um relgio central. Cada emissor dispe de um intervalo de tempo prdefinido para colocar informao no meio. Ex. PCM Pulse Code Modulation sistema de trx. de voz digital. A sua utilizao adapta-se bem trx. de fluxos contnuos de informao, como voz ou vdeo. Multiplexagem no Tempo: Assncrona Como os intervalos de tempo so assncronos, preciso um algoritmo que seleccione quem tem direito a trx.: - Aleatrio - Passagem de testemunho - Controlo Centralizado O controlo aleatrio baseia-se na reduzida probabilidade de dois emissores comearem, no mesmo instante, a trx. Na ausncia de qualquer controlo determinista, a estao 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 estaes emitem antes de reconhecerem que h uma trx. em curso. Neste caso d-se uma coliso e torna-se necessrio implementar um mecanismo que a resolva. a base da Ethernet. Para evitar a aleatoriedade existem mtodos de controlo determinstico do direito de emitir, usando um testemunho lgico (token) que circula entre as vrias estaes de um anel lgico. As vantagens so que a rede pode ser mais facilmente modelizvel e, portanto, os dbitos podem ser assegurados atravs de uma gesto de prioridades adequada. As desvantagens so: alguma complexidade adicional para garantir o bom funcionamento do testemunho na inicializao e em caso de falhas; introduo de atrasos no acesso ao meio. Ex. token-ring da IBM e token-bus em automatizao industrial. Finalmente, no controlo centralizado, h uma estao que se encarrega de inquirir (polling) s restantes se pretendem emitir. Esta soluo simples mas do ponto de vista de fiabilidade e desempenho est fortemente dependente da estao 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 Mtodo de Controlo Controlo Controlo Aleatrio Acesso distribudo distribudo Distribudo Designao Ethernet Token bus Token Ring MAN/DQDB Comercial 2.5.2. Rede Ethernet Serviu de base norma IEEE 802.3. O seu sucesso ditou numerosas evolues como a utilizao de vrios tipos de cabo coaxial, fibra ptica, aumento de vel. de trx., etc. Nvel Fsico A topologia de base um bus e a vel. de trx. da norma original de 10Mbps. tambm na origem o suporte fsico era o cabo coaxial limitado a 500m extensvel a 1,5km atravs de repetidores. A evoluo alargou ao par tranado e fibra ptica. Associada s arquitecturas de cablagem estruturada tem havido a tendncia de usar cabos mais baratos (UTP e STP). H especificaes para a qualidade dos cabos suportando a categoria 5 at 100MBps. comum distinguir as tecnologias Ethernet por uma mnemnica B/Modo/D, com B-largura de banda (Mbps); Modo distingue entre utilizao em banda base ou modulao em frequncia e Ddistncia mxima de um segmento ou o tipo de cablagem, ficando a distncia implcita. Ex. 10BaseT -> 10Mbps, banda base, 100m. A topologia em bus tem sido mantida do ponto de vista conceptual, mas a deinio dos sistemas de cablagem estruturada conduziu a solues baseadas em concentradores (hyb) que agregam vrias ligaes Ethernet s mquinas. Neste caso o bus funciona conceptualmente dentro do concentrador pseudo-estrela a partir do concentrador. Mtodo de Controlo de Acesso ao Meio por diviso no tempo assncrono com controlo aleatrio CSMA/CD

Normalmente as funes de comunicao so implementadas por hardware: Aps activao da recepo, o comunicador analisa o endereo de destino das tramas que passam no canal e recebe as que lhe so dirigidas ou as que tm o endereo de difuso. Para transmitir, o comunicador constri a trama no tampo de trx., encapsulando os dados que lhe so fornecidos pelos nveis superiores. A partir deste momento, o comunicador escuta o trfego no bus (carrier sense) e lana automaticamente a trx. quando detecta o canal livre. A coliso d-se quando dois ou mais comunicadores interpretam o canal como estando livre. Isto deve-se ao tempo de propagao. O intervalo de tempo em que existe a possibilidade de coliso depende da distncia e da velocidade de propagao do meio. As normas definem as caractersticas dos meios fsicos assim como o comprimento mximo do bus, pelo que possvel tirar o intervalo de tempo para a situao mais desfavorvel. Para detectar a coliso, a estao emissora escuta simultaneamente o bus para verificar se o sinal emitido no foi adulterado (collision detection). Se detecta coliso emite reforo de coliso; em seguida retira-se do canal e volta a tentar de novo passado um tempo. Para evitar situaes ambguas, em que algumas estaes no detectam as colises,os pacotes tm um comprimento mnimo de 64 bytes + prembulo, por forma a que a durao da sua trx. seja dupla do tempo mximo de propagao no cabo. Para evitar nova coliso na retrx., o comunicador espera um n inteiro de slot-time, valor esse que aleatrio, de 0 a k. Se houver nova coliso k duplicado e assim sucessivamente: Mtodo Truncated Binary Exponential Backoff. Formato das Tramas 1- Prembulo de 64 bits (101010...1011) para sincronizao dos relgios e delimitao fsica da trama 2- Endereos de 6 bytes cada 3- Campo tipo, na forma Ethernet, identifica o campo de dados aos nveis superiores, na 802.3 significa o tamanho do campo de dados 4- Dados mximo 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 interligao de redes locais. Nvel Fsico O meio de trx. a fibra ptica multimodo. H extenses para cabo coaxial, ou at mistura de pares tranados com fibra. A norma prev anel duplo, permitindo a continuao da operao em caso de quebra de interligao entre 2 ns; no normal funcionamento operam em paralelo, com sentidos de circulao inversos. A distncia entre estaes pode ser de 2 km e a rede pode ter um permetro de 200km. A configurao mxima prev at 1000 estaes -> redes metropolitanas. Mtodo 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 tambm considera 4 nveis de prioridade. Para emitir, uma estao tem de estar na posse do testemunho. A mensagem circula no anel e retirada quando retorna estao emissora. Ao contrrio do token-ring, o testemunho libertado assim que a estao acaba de trx., devido s dimenses. Os endereos so de 48 bits e o formato das tramas semelhante ao do token-bus, enquadrando-se pois nas normas IEEE. 2.6. Interligao de Redes Nas redes de grande escala, o nvel rede caracteriza o servio oferecido, dado que o nvel que, do ponto de vista dos equipamentos de comunicao, define a funcionalidade do sistema de comunicao. H 2 filosofias: Uma estabelece um circuito virtual, outra baseia-se numa aproximao sem ligao.

O nvel de transporte pode negociar com o nvel rede a qualidade de servio pretendida, ficando assim, o nvel de rede responsvel pela criao dos mecanismos que assegurem a entrega fivel dos pacotes, garantam ordem de entrega e controlo de fluxo. Noutra aproximao (comunidade Internet), considera-se que a diversidade de solues para as subredes no permite uma soluo eficiente que garanta a fiabilidade da rede, pelo que o controle dos erros, do fluxo e da sequencialidade devem ficar a cargo do nvel de transporte, simplificando o nvel de rede que ficar s responsvel pelo encaminhamento. 2.6.1. Equipamento de Interligao H conceitos ambguos. A interligao das redes pode efectuar-se a diversos nveis do modelo. Se for s ao nvel fsico usam-se os repetidores que se limitam a copiar os sinais elctricos de um segmento da rede para outro (ex. 2 segmentos de 1 rede Ethernet). Apenas podem ser usados entre redes fsicas idnticas. A ponte (bridge) opera a nvel lgico. Copia tramas de uma rede para outra. Como as tramas tm endereos pode fazer-se filtragem. Usam-se na hierarquizao das redes locais (interligao de LANs). As razes para se interligar LANs so trfego excessivo numa LAN que serve demasiadas estaes de trabalho, por exemplo, quando se consideram SFD; distncia demasiado grandes; gesto da empresa em departamentos; isolamento de faltas. Apesar da grande complexidade em interligar redes diferentes, a comisso props 2 coisas: A diferena essencial tema ver como que a ponte conhece os endereos dos ns das redes que interliga. A proposta ponte transparente impe memria interna na ponte, onde ir progressivamente registando os endereos dos ns e respectivas redes. No incio difunde tudo. Outra proposta as pontes com encaminhamento na origem, em que o n de origem deve definir ele o encaminhamento da trama anexando trama essa informao. Finalmente, a interligao no sentido mais abrangente efectua-se no nvel de rede e o encaminhador (router) ou gateways. gateway ou porta, um termo genrico que se aplica quer a este tipo de interligao, quer ao software que compatibiliza protocolos de qualquer nvel. 2.6.2. Rede X.25 Tem por base a filosofia do sistema telefnico. Visa a implementao de um servio pblico para comunicao entre mquinas geograficamente distantes. as mquinas dos utilizadores interligamse rede atravs de uma ligao ponto a ponto ao comutador da rede. Nvel Fsico O nvel fsico consiste na ligao ponto a ponto utilizando linhas analgicas ou linhas digitais. Nvel Lgico Uma nova verso do HDLC, a LAPB (Link Acess Procedure) seria adoptada pela X.25. O protocolo implementa controlo de fluxo, recuperao de erros e garante que o computador recebeu correctamente o pacote. mas no assegura que o comutador aceitou transmiti-lo, isso a nvel de rede. O formato semelhante ao do SDLC, incluindo cdigo detector de erros e um campo de controlo. As tramas so de 3tipos: informao, superviso e no numeradas, a que correspondem funes diferentes do campo de controlo (n seq. da trama e confirmao das j recebidas. Usa um protocolo de janela deslizante com 3 bits. Nvel de Rede Esquema de funcionamento: Quando um DTE pretende comunicar, tem de estabelecer um circuito virtual envio de pacote call-request. O destinatrio se quiser estabelecer ligao envia callaccepted. Depois enviam pacotes de dados. H regulao de fluxo e deteco de erros. Qualquer interlocutor pode terminar com um clear-request que deve ser confirmado. Para satisfazer a necessidade de servio 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 comunicao sem ligao. Endereos podem ter at 14 dgitos decimais. O X.25 ilustra a redundncia funcional j referido no modelo OSI. Por exemplo o nvel de rede e o de ligao implementam ambos o controle de fluxo.

As limitaes de desempenho permitem prever que esta tecnologia ser substituda pelo FrameRelay que d um servio mnimo que no oferece mecanismos de recuperao de erros e de controlo de fluxo, posicionando-se melhor para interligao 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 pressupe que a rede so os comutadores, aos quais se ligam os hosts, aquela pressupe que os utilizadores possuem redes que pretendem interligar rede global e que, para tal, dispem de mquinas com capacidade de execuo de protocolos. Os princpios bsicos do IP so: - O servio sem ligao - O servio com base no melhor esforo - O endereo de um n subdivide se em 2 componentes: a identificao da subrede a que o n se encontra ligado e a identificao do n nessa subrede. - O encaminhamento efectuado independentemente para cada pacote, pelo que todos devem ser endereados. - A deciso de encaminhamento feita com base no identificador da subrede de destino, com excepo dos ns com ligao directa a essa subrede que encaminham com base no endereo do n. Endereos IP constitudo de forma hierrquica por um par <identificador rede netid; identificador Mquina hostid> O n de bits associado a cada elemento do par no fixo, existindo 3 tipos de endereo 3 classes: A, B e C. A razo prende-se com o n de ns nas subredes. Qualquer organizao com um endereo IP pode subdividi-lo para formar subredes internas. As subparties efectuam-se sobre os bits menos significativos do endereo e dependem do tipo de endereo. Por ex. para um tipo B podem usar 16 bits (8 referenciam uma subrede e 8 o n dentro da rede) Um endereo IP pode identificar uma mquina (netid=0) ou uma rede (hostid=0). Endereos de difuso tm todos os bits de hostid a 1. Como hierrquico, uma mquina que tenha ligao a 2 redes tem 2 endereos. Um endereo IP no representa pois uma mquina mas sim um ponto de ligao. Problemas do endereos IP: - Se a mquina mudar de rede, torna-se necessrio mudar o seu endereo e tabelas onde est - Se mquina tiver vrios endereos protocolos usam a especificao de rede contida no endereo mesmo que outros caminhos fossem mais eficientes. Os endereos IP tm 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 endereo de difuso) Protocolo IP de nvel rede e bastante simples. Implementa o encaminhamento atravs de tabelas fixas e um controlo de congesto com libertao de pacotes. a unidade o pacote ou datagrama com cabealho, dados 8limitado a 64kbytes). IP pode fragmentar se subredes assim o exigirem. 0 8 16 31 Version IHL TOS Total Lenght Identification Flags Fragment Offset TTL Protocol Header Checksum Source adress Destination Adress Options Padding Internet Datagram Data

3. INTERFACE DE COMUNICAO 3.1. Modelo da Comunicao Distribuda Os protocolos que vimos so fundamentais para comunicao eficiente e normalizada entre redes heterogneas, mas necessrio incorporar a infra-estrutura de comunicao no modelo computacional, integrando as funes de comunicao no ambiente de desenvolvimento das aplicaes. O MC tem de oferecer ao programador de aplicaes uma viso coerente dos objectos de comunicao e das funes que lhe esto associadas. A comunicao num AD uma evoluo da comunicao entre processos numa nica mquina, correspondendo troca de mensagens entre 2 processos. O MC constitudo por objectos de comunicao ou portos e por funes agrupadas numa biblioteca. vulgar designar esta interface por API da comunicao. As interfaces permitem um pequeno grau de abstraco em relao aos protocolos de comunicao, mas continuam fortemente relacionadas com estes. Na maioria dos sistemas existe uma quase total correspondncia entre os servios oferecidos pelo protocolo de transporte e a interface. os protocolos de comunicao so, geralmente implementados no ncleo do SO. A interface de comunicao efectua as chamadas ao sistema necessrias para executar as operaes do protocolo. A comunicao pode modelizar-se como a interaco entre um processo emissor e um processo receptor. a transferncia suportada por um canal, que no mais que a abstraco dos mecanismos de transporte. a interaco 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 associao de dois portos. para que exista comunicao, esta associao tem de estabelecer-se, podendo ter uma forma duradoura no canal de ligao, ou apenas para uma interaco, no canal sem ligao. A informao trx. a mensagem, devendo ser interpretada segundo um protocolo de elevado nvel acordado entre produtor e consumidor. Idealmente, quando a qualidade de servio do canal no pode ser mantida, deve usar-se o mecanismo de excepes que tem aqui uma maior importncia face ao maior n de falhas nos SD. de notar que os SO podem ser diferentes. as interfaces utilizadas numa aplicao distribuda podem, portanto, ser diferentes consoante o SO. a garantia de capacidade de intercomunicao dada pelo protocolo de transporte que implementa o canal. a portabilidade das aplicaes que fica prejudicada. 3.2. Caracterizao da Interface 3.2.1. Canal Com ou Sem Ligao Na centralizada o canal implementado por zonas de memria partilhada, normalmente no espao de endereamento do ncleo -> elevada fiabilidade. Num AD no assim. O desempenho tambm menor. Esta fiabilidade e desempenho devem ser explcitos para o programador para que este possa escolher a qualidade de servio adequada aplicao. a forma mais vulgar de traduzir o tipo de servio de comunicao a utilizao de um canal com ou sem ligao: - Com Ligao Antes da fase de ligao estabelecido um canal entre os 2 processo interlocutores. O canal normalmente fivel, bidireccional e com garantia de sequencialidade. - Sem Ligao ou Datagrama O canal conceptualmente estabelecido apenas para o envio de uma mensagem. No oferece normalmente garantias de fiabilidade. O primeiro prefervel quando existe um fluxo contnuo de informao. A sua desvantagem consumir recursos de forma permanente e de existir um tempo de latncia significativo no estabelecimento do canal. O segundo adapta-se melhor comunicao com mltiplos interlocutores, a mensagens de pequena dimenso (tpicas dos sistemas cliente/servidor) e reduz o tempo inicial de latncia. 3.2.2. Portos de Comunicao Para transferir informao os processo interactuam com um porto que representa a extremidade do canal de comunicao. Do ponto de vista do SO os portos so uma abstraco do mesmo tipo dos ficheiros e perifricos virtuais.

Os portos so objectos de interface entre o SO local e os protocolos de transporte, pelo que tm 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 so diferentes da a duplicao, mas h indireco. O associado ao protocolo pode ser explcito na interface, obrigando a que o programador o conhea (ex: sockets) ou encapsulado por camadas que transparentemente efectuam a traduo (ex: Mach) Quando um porto criado pode logo ser criada a associao entre o local e o de comunicao ou deixado par depois. Por ex. nos sockets a associao feita por uma funo especfica (bind); a criao s devolve o local. H os servios de nomes que facilitam a vida aos programadores. Do elenco das operaes associadas aos portos, fazem parte as funes de envio e recepo das mensagens e funes especficas para criar/eliminar um porto, associar um endereo de transporte e definir parametrizao do canal. A funcionalidade depende do MC, do SO e do PT, sendo diferente consoante o canal com ou sem ligao. No com ligao so necessrias funes para estabelecer a ligao, correspondendo a associar implicitamente os portos do emissor e receptor. Neste caso, como a ligao permanece estabelecida, os portos no so multiplexados; h que terminar uma ligao para se poder iniciar outra. No sem ligao, 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 no existe ligao, o porto recebe mensagens de todos os processos que possuam o seu identificador. Naturalmente existem proteco com direitos de acesso. Na mensagem deve ser enviado o identificador do porto do emissor para que o destinatrio possa estabelecer um canal de resposta. 3.2.3. Semntica da Funo de Envio Conceptualmente transfere a mensagem do espao de endereamento do processo emissor at ao porto receptor. No tocante sincronizao, esta operao pode ter vrias semnticas que se relacionam com a deteco de faltas na comunicao: - Assncrona: a funo copia a info para os tampes do protocolo de transporte e retorna depois de iniciar o envio. O processo emissor desbloqueado assim que a funo retorna do ncleo, mas no tem qualquer garantia que a mensagem chegou ao seu destino. - Sncrona: O processo emissor fica bloqueado at que o porto de destino confirme que recebeu a mensagem - Cliente/Servidor: O processo emissor fica bloqueado at receber a mensagem de resposta. A assncrona aparentemente mais eficiente. Contudo, a hiptese de explorar o paralelismo, criando mltiplos fluxos de actividade despoletados por vrias mensagens, conduz a numerosos problemas de sincronizao. O tipo de programao por eventos, diferente dos paradigmas de programao a que estamos habituados e assim, raro que o paralelismo seja convenientemente explorado. Se a comunicao remota for do tipo pergunta-resposta, a assncrona no proporciona vantagem. Contudo se for essencialmente assncrona ou unidireccional (FTP, Telnet) interessante. O envio sncrono oferece garantia de que a info foi correctamente trx., mas no permite detectar qualquer falha na execuo do servio. a programao tambm complexa para evitar interblocagens. A cliente/servidor mais rica (procura garantir a execuo da operao, assegurando que o processo s continua a sua execuo quando recebe a mensagem de resposta do servidor (na ausncia de faltas)) pelo que tem sido a base da programao do modelo cliente/servidor. S que implica um conjunto de operaes que naturalmente no existem no protocolo de transporte 3.2.4. Estrutura das Mensagens Pode ser estrutura individualizada ou apenas compostas por sequncias de bytes de tamanho varivel (byte stream).

Normalmente o sistema de suporte comunicao no impe uma formatao especfica das mensagens. A imposio de formatos predefinidos na interface de comunicao uma imposio do programador, sendo, em geral, evitada neste nvel. Uma possvel razo para impor uma estruturao da mensagem no mecanismo bsico de comunicao prende-se com os mecanismos de suporte heterogeneidade. 3.2.5. Semntica da Recepo retirar a primeira mensagem existente no porto ou, caso nenhuma esteja presente, bloquear o processo. Se o servidor estabelecer simultaneamente canais com vrios clientes, coloca-se o problema dos mltiplos pontos de sincronizao (mltiplos portos, no pode bloquear num vazio). A existncia de mltiplos canais relaciona-se com o modelo com ou sem ligao. Se sem ligao pode usar-se um porto para receber as mensagens de todos os processos. Mas neste caso no possvel estabelecer prioridades. Por esta razo frequente os servidores criarem vrios portos para as mensagens de tipo ou de interlocutores de classes diferentes. No com ligao, o porto fica associado ao canal, pelo que mltiplas ligaes obrigam a mltiplos portos. A soluo para ambos os caso criar um mecanismo de recepo mltipla 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 vrios portos. A funo funciona como um comando com guardas lgicas que, quando uma delas se torna verdadeira, desbloqueia o processo. frequente associar primitiva de recepo uma temporizao, associada com a comunicao remota, bidireccional, para o receptor no ficar indefinidamente bloqueado caso haja falha. A primitiva select dos sockets um exemplo de uma funo de recepo mltipla com uma temporizao associada. A funo de recepo tambm pode ser assncrona (teste peridico ou associar a acontecimento assncrono). 3.2.6. Paralelismo A sincronizao das primitivas de envio e recepo de dados est fortemente relacionada com o modelo de concorrncia em termos de processos e tarefas. a necessidade de paralelismo colocase sobretudo na programao de processos servidores -< atender simultaneamente vrios clientes. Uma forma de introduzir paralelismo no servidor utilizar vrios processos em paralelo. Isso obriga a partilha de estruturas de dados (memria partilhada e sincronizao) o que obriga a programao delicada, porque reintroduz os problemas dos mltiplos pontos de sincronizao. Um MC mais adequado o modelo multitarefa com vrios fios de execuo concorrente que se sincronizam no acesso a variveis partilhadas. Vantagens: O modelo de programao continua simples, pois o seu cdigo idntico a um servidor sequencial, apenas com a introduo da sincronizao no acesso a estruturas de dados partilhadas; permite explorar situaes em que uma tarefa se bloqueia durante o servio de um pedido; torna eficiente a partilha de dados e a sincronizao entre as vrias tarefas; tira partido de possveis mltiplos processadores. 3.2.7. Faltas na Comunicao Podem ter numerosas origens. As mais frequentes so as devidas a quebra do canal de comunicao (rede fsica falhou, esgotamento de tampes para os dados). Nas interfaces de comunicao habituais no so introduzidos mecanismos suplementares de tolerncia a faltas. essa evoluo das interfaces feita nos sistemas de Chamada de Procedimento Remoto (RPC) onde os mecanismos de suporte comunicao asseguram a deteco e recuperao das faltas de comunicao. No com ligao o protocolo de transporte responsvel por garantir que o canal de comunicao est activo, podendo assinalar a sua quebra. No sem ligao raro o protocolo de transporte assegurar entrega fivel. Um segundo problema a forma como as situaes de excepo resultantes so trx. aos processos. a forma mais simples atravs de um valor de retorno da execuo da funo que indique o estado da execuo (utilizvel em situaes do tipo tentar enviar a um porto inexistente ou ocupado). Na trx. assncrona isto no possvel, o que torna o problema mais complexo,

sendo necessrio mecanismos intrnsecos do SO que permitem a execuo de aces assncronas. O Unix usa os signals, o VMS associa rotinas assncronas ao envio das mensagens. isto rudimentar. O Mach, por cada processo existe um porto para recepo de mensagens de excepo, reservando-se uma tarefa para o tratamento das excepes. 3.2.8. Difuso das Mensagens Simplifica a programao, por ex. no que toca a localizao de uma entidade na rede, sincronizao distribuda, replicao de dados, etc. Nas LANs simples, nas de larga escala no devido ao grande n de mensagens extra introduzidas. Devido ao interesse dos algoritmos baseados na difuso, foram propostos mecanismos de difuso mais restritos a grupos de portos. existe uma abstraco para representar o grupo de portos tm nomes e podem ser criados dinamicamente. Generaliza-se no IPv6. Os protocolos com entrega fivel so designados de difuso atmica so importantes nos sistemas de tolerncia a faltas. H tambm os de melhor esforo (IP, Chorus). 3.2.9. Alternativas de Implementao 3 formas de integrao das funes de comunicao no modelo computacional de um SO multiprogramado: - Funes de E/S genricas - Funes especficas dedicadas apenas interface com os protocolos de transporte - Incluso no mecanismo de intercomunicao entre processos do SO A primeira origina problemas de normalizao. O Unix ainda adoptou a interface dos sistemas de ficheiros, mas esta soluo sofre de uma limitao importante, devido s operaes disponveis nas interfaces de E/S serem insuficientes face s necessidades dos protocolos de comunicao (ex. estabelecimento de ligao, parametrizao ou recepo mltipla). A soluo habitual recorrer a uma forma de parametrizao genrica (ex. ioctl do Unix) mas o estilo de programao fica pouco claro e susceptvel de muitos erros. A alternativa biblioteca dedicada (soluo simples) (ex. NetBios) que oferece interface coerente e esconde detalhes, no genrica pois obriga a distinguir partida comunicao local e remota, obrigando reprogramao das aplicaes. Os sockets do Unix so um exemplo da tentativa de compatibilizao das funes de E/S, mas tambm houve que desenvolver funes especficas -> modelo hbrido. Uma outra viso considerava estender o IPC (Inter Process Communication) local para termos s uma interface. Mas h uma desvantagem importante: cada SO impe uma estruturao prpria das mensagens. Como nas redes se pretende ligar SO diferentes, a formatao imposta pelas mensagens do IPC torna complexo o transporte dos protocolos para outros SO. Nos sistemas resultantes da evoluo de SOC para SOD manteve-se a distino entre os mecanismos de IPC locais e interfaces de comunicao distribuda. No Unix V.4 h o IPC local e o TLI (Transport Layer Interface). O Mach e Amoeba so coerentes mas incompatveis entre si, face ao que se referiu. Vamos estudar os sockets, o NetBios e o Mach. Os sockets so 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 no 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. Caracterizao dos Sockets (Unix 4.3BSD) Os sockets propunham-se dar resposta a: - Independncia do protocolo (a interface) - Transparncia (remoto e local) - Compatibilidade (inserir-se na interface clssica de comunicao e E/S do Unix) Apresentam uma interface baseada nos descritores de ficheiros, permitindo a utilizao por programas existentes como uma evoluo dos pipes. Adicionaram-se funes especficas (criao de canais, ligao, gesto de nomes). a independncia materializou-se na noo de domnio:

- Domnio Internet Utiliza os protocolos TCP e UDP descritos no cap. anterior - Domnio Unix Permite a comunicao entre processos numa nica mquina, sendo semlhante aos pipes com nome - Domnio Xerox Na criao do socket, para alm da definio do domnio, especificado o tipo de servio pretendido. Os tipos de sockets mais significativos so: - stream canal com ligao, bidireccional, fivel e com garantia de ordem. a interface do tipo sequncia de bytes tal como nos pipes e ficheiros - datagram canal sem ligap, bidireccional, no sendo garantida sequencialidade, fiabilidade nem eleiminao de mensagens duplicadas. - sequenced packet canal sem ligao, mas com envio sncrono que garante a entrega de mensagens - raw acesso directo aos mecanismos de comunicao. No domnio Internet permite aceder ao nvel IP Nem todas as combinaes de domnio e tipo tm sentido. Os identificadores de transporte associados aos sockets so diferentes para cada domnio. No domnio Unix os nomes so caminhos de acesso, at 108 bytes; no domnio Internet, o identificador corresponde ao endereo de transporte dos protocolos UDP e TCP, descrito no cap. anterior. composto pelo endereo IP da mquina (32 bits) e o n de um porto de transporte codificado em 2 bytes. No domnio NS 4 bytes para o NetId, 6 para o HostId e 2 para o porto. Os valores dos portos utilizveis pelas aplicaes encontram-se restringidos por razes de segurana e de eficcia. No Unix BSD: - Portos reservados: 1-1023 (para servidores que normalmente existem em todos os sistemas Ftp, Telnet) - Portos atribudos dinamicamente pelo sistema: 1024-5000 (ex. clientes com canais com ligao) - Portos para servidores no privilegiados: > 5000 3.3.2. Criao de um Socket Os sockets, como os pipes so referenciados no SO por um descritor de ficheiro. int socket (int domnio, int tipo, int protocolo) Na criao de um socket no 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 enderevel pelos restantes processos, necessrio associar-lhe um nome global. Esta associao efectuada pela primitiva bind. int bind(int sockfd, struct sockaddr *nome, int dim) a funo bind no domnio Internet, associa ao socket o endereo de transporte TCP ou UDP, ou seja, o endereo IP da mquina e o porto de transporte. O bind tambm pode ser utilizado pelos clientes para associarem ao seu socket um endereo Internet, por exemplo, para fixarem o porto remetente quando comunicarem em modo datagram. 3.3.3. Sockets com Ligao Antes de aceitar ligaes, o servidor tem de indicar a sua disponibilidade para receber chamadas (primitiva listen) int listen (int sockfd, int maxpendentes) maxpendentes no limita o n de ligaes do servidor, mas apenas a fila de espera dos pedidos de ligao. A primitiva listen no bloqueante, a funo accept que sincroniza o servidor com os pedidos de ligao, bloqueando-o at chegada de uma mensagem requisitando uma ligao. Quando a ligao estabelecida, o sistema cria automaticamente um outro socket que ficar associado ao novo canal de comunicao, deixando livre o socket inicial para continuar a receber pedidos de ligao. O descritor de ficheiro correspondente ao novo socket devolvido como parmetro de sada da funo accept. Esta primitiva tem uma semntica relativamente complexa, efectuando 3 operaes: a sincronizao na espera de ligao; a ligao com o socket do cliente; a criao automtica 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 vrios. int connect (int sockfd, struct sockaddr *nome, int dim) A primitiva connect idntica abertura de um ficheiro, tendo como parmetro de entrada o nome do socket do servidor e devolvendo, em caso de sucesso, o descritor de ficheiro que ficou associado ao canal de comunicao. Nome especifica o endereo do socket do servidor e poder ter sido codificado directamente. H outras funes para o envio e recepo, que permitem parametrizaes adicionais. Funes de Uso Geral Eliminam o problema da heterogeneidade nos valores inteiros e fazem a gesto de nomes. Comunicaes Urgentes H mecanismo especial (out of band). Utiliza-se um modificador no campo flag da primitiva send. Quando as info so 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 simulao da tecla delete remotamente. 3.3.4. Sockets Sem Ligao Na utilizao dos sockets sem ligao ou datagrama, a interface semelhante das caixas de correio habituais nos sistemas de intercomunicao 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 *origem, int *dim); Neste diagrama o cliente e servidor fazem socket e bind e depois vrios recvfrom e sendto. ...

3.4. Interface de Programao NetBios 3.4.1. Estrutura de Base Na rea dos computadores pessoais, a comunicao foi particularmente relevante desde o incio como forma de partilha dos ficheiros e de interligao dos sistemas a outros de maior complexidade. Existem diversos mecanismos de comunicao para redes de PC: - NetBios - Lan Manager - Netware - PC/NFS - Winsocket Apesar das significativas diferenas todas procuram oferecer uma interface de programao para aplicaes distribudas. O NetBios interessante, porque corresponde a uma interface de comunicao amplamente divulgada. Considera que a rede local se baseia num meio partilhado que suporta difuso. Mas existem especificaes para o adaptarem a diferentes protocolos de transporte como o TCP/IP. realmente uma interface, no h um protocolo nico existindo vrias implementaes para redes diferentes. Isto permite o transporte das aplicaes. 3.4.2. Funcionalidade habitual dividir a interface do NetBios em 3 tipos de comandos: - Servio de nomes - Servio de comunicao - Gesto Nomes Como em qualquer sistema de comunicao, o nvel de transporte do NetBios usa endereos para identificar na rede os processos correspondentes. So compostos de 16 bytes, tm estrutura plana e so cadeias de caracteres. H 2 tipos de nomes: nomes nicos (na rede local) e nomes de grupo (permitem difuso em grupo). So mantidos nas tabelas locais do NetBios e tm de ser explicitamente apagados. Comunicao com Ligao Designado como servio de sesso, fornece transporte com as seguintes caractersticas: - Com ligao - Preserva as fronteiras das mensagens - Confirmao da recepo - Deteco de mensagens duplicadas - Garantia de ordem - Controlo de fluxo O modelo de programao baseia-se na execuo pelo servidor de um Listen sobre um determinado nome. O cliente efectua um Call. Quando a ligao se estabelece, cada uma das aplicaes interlocutoras recebe a notificao do estabelecimento de ligao e um identificador de sesso LSN (Local Session Number). inteiro mdulo 255. Como habitual, este identificador usado nas funes de Send e Receive para especificar uma dada sesso. A operao normal de Send sncrona, implicando uma confirmao da mquina de destino. H o Send-No-Ack que tem semntica assncrona para as redes token-ring. Dados so limitados a 64Kbytes, havendo no entanto o Chain-Send para 128Kbytes. O Receive, como habitual sncrono. Para permitir recepo mltipla existe o Receive-Any sobre mltiplas sesses. Comunicao Sem Ligao Mensagens de tamanho limitado (512 bytes por omisso). Podem ser enviadas a nome nico, grupo ou difuso. As primitivas so Send-Datagram e Receive-Datagram e a semntica de envio

no a habitual, dado que se o NetBios recebe uma mensagem para um dado nome em que no tenha sido feito um Receive, a mensagem ignorada. O envio em difuso Send-Broadcast-Datagram, havendo o Receive correspondente. 3.5. Interface de Comunicao no Mach 3.5.1. Conceito de Micro-Ncleo Nos micro-ncleos toda a comunicao se processa por transferncia de mensagens entre processos, mesmo na invocao de funes do sistema operativo. O IPC portanto muito genrico e com uma riqueza funcional que no existe noutras arquitecturas. Os micro-ncleos constituem um caso limite da utilizao da comunicao entre processos como o elemento estruturador de toda a arquitectura do SO. Os SO, apesar de camadas so complexos e difceis de evoluir e modificar. Ento esta filosofia isola o ncleo que s faz: - Gesto de tarefas - Intercomunicao entre processos (IPC) - Interface com o hardware da mquina A funcionalidade habitual do SO executada por processos em modo utilizador que comunicam entre si, usando os mecanismos de IPC do micro-ncleo. Como os processos so independentes (e concorrentes) podem ser reprogramados sem obrigar a recompilar o sistema. O mecanismo de chamada sistema diferente nesta arquitectura, dado que necessrio que o processo utilizador e o servidor sistema troquem mensagens, no se tratando de uma simples mudana de contexto. As chamadas sistema so decomponveis num envio de mensagem para o processo sistema que implementa a funcionalidade requerida e na recepo da mensagem de resposta. Para isto ser eficiente a intercomunicao tem de permitir a transferncia de dados sem implicar numerosas cpias. Isto similar a chamadas remotas de procedimento mas como so na mesma mquina so optimizadas. Tambm h que contemplar a segurana. 3.5.2. Mach Foi desenvolvido como variante do BSD que oferecia ao utilizador tarefas reais (threads). Na verso 3 a funcionalidade do BSD foi exportada para um processo servidor. A perspectiva bsica do Mach : - Um ncleo simples que suporte a comunicao - Objectos do sistema so identificados e associados a canais de comunicao - Um modelo de comunicao cliente/servidor usando IPC sncrono e assncrono - Tarefas que se executam em modo utilizador e que implementam a maioria das operaes do SO clssico Os elementos do MC relacionam-se com estes conceitos: - Task unidade de reserva de recursos do sistema (espaos de endereamento, 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 gesto do espao de endereamento no Mach. Corresponde a um bloco contguo de pginas (de memria virtual) com um identificador prprio (evoluo dos segmentos do Unix) - Portos objectos de comunicao - Mensagens Os conceitos relevantes no sistema do IPC so os portos e as mensagens. Um porto um objecto do ncleo que representa uma extremidade de um canal de comunicao. So 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 o direito de envio para que este possa responder. Cada objecto conhecido no sistema tem associado um porto, ao qual podem ser enviadas as mensagens respeitantes sua utilizao. Os portos so assim simultaneamente os objectos de comunicao, mas tambm o sistema de designao das entidades do ncleo. Os portos so um conceito inovador. O conhecimento de um porto permite comunicar com o objecto, independentemente da sua localizao podendo ser trx. nas mensagens e mantido nas estruturas

de dados volteis ou persistentes. Apesar da implementao diferente desempenham uma funo conceptualmente semelhante aos URL da Web. As mensagens so estruturas tipificadas que descrevem para cada campo qual o tipo de dados que trx.. So compostas por um cabealho e um n varivel de campos tipificados. O cabealho contm 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 constitudo por dados tipificados, portos ou referncias para objectos de memria. A tipificao resolve os problemas de heterogeneidade, mas sobretudo til para identificar as referncias ou apontadores para objectos de memria e para a trx. de portos, permitindo que o ncleo controle a sua trx. entre tasks. A passagem de apontadores evita mltiplas cpias, at em redireccionamentos do ncleo. necessrio definir a semntica da utilizao da informao transferida. No Mach copy-onwrite, mas faz-se s mapeamento, sendo as pginas apenas duplicadas quando escritas. O envio e recepo de mensagens efectuado por uma funo nica, o mach_msg que tem estrutura complexa com 7 parmetros. A semntica de envio pode ser assncrona ou cliente-servidor e h o prt set para permitir recepo mltipla. Uma tarefa que receba de um conjunto de portos bloqueia-se at que um dos portos receba uma mensagem. Em conjuntos de mquinas que tenham como sistema o Mach, o IPC permite a intercomunicao entre processos que se executam em mquinas diferentes. esta funcionalidade proporcionada por um processo servidor, o NetMsgServer. Ele efectua a correspondncia entre identificadores locais e remotos, duma forma transparente.

CAP. 4 PROCEDIMENTOS REMOTOS 4.1. Introduo 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 ligao ao modelo de programao das linguagens procedimentais delicada, devido semntica totalmente diferente das interaces. As mensagens so normalmente enviadas assincronamente e pressupem fluxos paralelos de actividade; as linguagens procedimentais consideram o simples fluxo de actividade que sincronamente chama funes. O modelo de mensagens tambm pouco transparente para o programador habitual, expondo os mecanismos de transporte (endereamento, formatao das mensagens, tratamento da heterogeneidade). Ento associou-se ao modelo cliente/servidor uma metodologia de programao distribuda baseado na Chamada de Procedimento Remoto. O RPC consiste numa generalizao deste mecanismo que visa permitir uma transferncia de controlo e dados entre espaos de endereamento disjuntos quer residentes na mesma mquina, quer em mquinas distintas. A interaco do tipo pergunta-resposta, implcita no RPC, permite simplificar alguns dos requisitos de fiabilidade dos nveis de comunicao inferiores, tornando possvel a utilizao de protocolos de transporte sem ligao. Antes de utilizar o servidor o cliente deve estabelecer uma ligao com ele. Este binding pode incluir vrias operaes: localizao do servidor, normalmente usando um servio de nomes; estabelecimento de um canal de transporte; autenticao do cliente e/ou servidor. Depois o cliente invoca uma operao remota no servidor e envia-lhe a info. necessria. A mensagem contm a identificao do procedimento remoto e os respectivos parmetros. Do lado do servidor ao contrrio... Os requisitos de desempenho so tambm diferentes. Um servidor deve poder processar simultaneamente vrias invocaes remotas, pelo que a sua estrutura interna deve basear-se num mecanismo de multiplexagem de fluxos de actividade, normalmente usando tarefas. Uma evoluo possvel deste modelo a existncia de mltiplos servidores idnticos. Numerosos projectos de I&D propuseram abordagens diferentes para arquitectura e implementao dos sistemas RPC (ex: Sun-RPC, Dce) e existem diversos esforos de normalizao. A noo de RPC uma abstraco lgica, dado que, quando o cliente invoca uma operao, chamando aparentemente a funo definida no servidor, na realidade est a efectuar uma chamada a um procedimento local que se encarrega de iniciar a invocao remota. estes procedimentos, que designaremos por rotinas de adaptao (stub routines), tm um papel preponderante na arquitectura do sistema. No lado do cliente responsvel por converter e empacotar os parmetros numa forma apropriada para a trx.; enviar a mensagem para o servidor usando um servio de transporte; esperar pela resposta do servidor. Quando esta recebida desempacota os resultados, convertendo-os para a representao local. Do lado do servidor, a rotina de adaptao tem a funo simtrica. A ambio a total transparncia em relao ao modelo de programao habitual, podendo idealmente desenvolver-se uma aplicao de forma independente da rede ou mquinas que a iro suportar. assim, o RPC deve estar transparentemente integrado no ambiente de programao. A transparncia total difcil e podemos dividi-la nos aspectos: - Sintaxe da linguagem de programao - Passagem de parmetros - Semntica de execuo do procedimento - Desempenho O primeiro relativamente fcil de obter. A forma de especificao dos procedimentos remotos baseia-se numa linguagem de descrio de interfaces ou IDL inspirada no C, Pascal e C++ a que so acrescentadas algumas palavras-chave. A passagem de parmetros levanta vrios problemas na definio do RPC: heterogeneidade dos tipos de dados em mquinas diferentes; passagem por valor ou referncia. a primeira um dos factores limitativos da transparncia. O compilador ter de introduzir no cdigo das rotinas de adaptao as chamadas s funes de converso, de acordo com um protocolo de apresentao.

A passagem por valor simples pois sabendo o servidor e cliente o tipo dos dados, basta reservar memria de acordo; ao contrrio da passagem por referncia pois os espaos de endereamento so diferentes. A transparncia na semntica de execuo do procedimento mais complexa, porque as diferenas introduzidas no modelo de faltas e pela interveno de mquinas distintas no podem ser totalmente escondidas, vindo a reflectir-se na fiabilidade das aplicaes. necessrio um protocolo. O desempenho naturalmente muito diferente, e ser sempre apesar da evoluo. 4.2. Especificao da Interface dos Servios As linguagens de especificao de interfaces so uma verso simplificada de uma linguagem de programao, dado que apenas necessitam da parte declarativa das linguagens. A linguagem IDL possui palavras-chave para fornecer indicaes na definio dos servios: identificao do servio; verses; semntica desejada, etc. Faz parte dos sistema RPC uma espcie de compilador com entrada a especificao da interface e gera as rotinas de adaptao para o cliente e servidor. a sada em C ou Pascal que devem ser novamente compiladas e ligadas s aplicaes. Na declarao dos parmetros, necessrio eliminar as ambiguidades na definio do tipo de dados. IDL enriquecido pois C muito permissivo. A passagem por referncia obriga a copiar a estrutura referenciada no cliente para a mensagem e no servidor a reserva dinmica da memria para onde ser copiada. H problemas com a passagem de apontadores, vectores, strings e ainda mais listas e rvores. denotar que na programao em linguagem C, os apontadores so um mecanismo a que os programadores associam grande eficincia, sendo o contrrio no mecanismo de RPC (reserva dinmica de memria, cpia dos dados, validao dos apontadores, etc.). Mais difcil ainda so os rings e listas circulares, que no tm o NULL. Situaes deste tipo tm de ser resolvidas pelo programador e no pelo compilador RPC. ex. do banco... 4.3. Arquitectura do Sistema de RPC 4.3.1. Suporte de Execuo do RPC As rotinas de adaptao estabelecem a interface entre o cdigo das aplicaes e os protocolos das redes, mas, como natural, recorrem a uma biblioteca de funes para todas as operaes de base do sistema de RPC. As funes de biblioteca suportam todos os mecanismos genricos do funcionamento da chamada remota: inicializao do servidor e registo do nome dos servios no servidor de nomes; protocolo de ligao entre o cliente e o servidor; converso de dados, controlo da semntica da chamada remota e a ligao aos mecanismos de envio e recepo das mensagens do protocolo de transporte. Tambm incluem funes para tratamento de excepes e erros. a biblioteca de funes com as respectivas estrutura de dados globais constitui o ambiente de suporte (run-time) execuo do RPC que ser carregado em memria com a aplicao distribuda. As principais funes do sistema de suporte so: Um servidor tem uma fase de inicializao em que estabelece o seu ambiente de comunicao: - Criar os portos de comunicao. Nesta fase definem-se os protocolos (famlia de protocolos, com e sem ligao, etc.) - Associar ao porto um procedimento de despacho/rotina de adaptao agulha mensagens recebidas para a rotina do servio com base num identificador de procedimento presente na mensagem - Registar o servio no servidor de nomes a identificao do servio, o protocolo e os respectivo endereo do porto. - Invoca uma rotina que o bloqueia espera da recepo de mensagens. A ligao do cliente ao servidor tem os seguintes passos, desencadeados pelo cliente: - Obter o endereo do porto do servidor atravs do servio de nomes - Executar o protocolo de ligao (binding) que cria os canais de comunicao e poder eventualmente tratar de aspectos de autenticao. A invocao remota de um servio pode decompor-se em 3 protocolos: - Apresentao trata da converso de formato de dados internos para a trx.

- Controlo da invocao trata das faltas de comunicao ou das mquinas - Transporte As rotinas na biblioteca de suporte do RPC suportam as diversas etapas dos protocolos que podemos resumir da seguinte forma: Cliente: - Converso dos parmetros de entrada e construo da mensagem - Envio da mensagem, bloqueando-se a aguardar resposta Servidor: - Recepo da mensagem - Invocao da rotina de despacho - Converso dos campos da mensagem nos parmetros da rotina invocada - Chamada ao procedimento interno do servidor - Converso dos parmetros de sada e construo da mensagem de resposta - Envio da mensagem de resposta Cliente: - Recepo da mensagem - Converso dos campos da mensagem para os parmetros de sada Esta descrio pressupes que no h faltas. Numa viso mais prxima do modelo OSI, dizemos que o protocolo de RPC engloba o nvel de sesso na abertura e fecho de ligaes; de apresentao no tratamento de heterogeneidade; aplicao parte especfica dos servios. Cdigo do Cliente Rotinas de adaptao Biblioteca de suporte Transporte dos dados Protocolo de Apresentao Protocolo de Controlo Protocolo de Transporte Cdigo do servidor Rotinas de adaptao Biblioteca de suporte Transporte de dados

4.3.2. Ligao Cliente Servidor O cliente antes de efectuar uma chamada remota precisa de saber: - O protocolo de transporte - Endereo da mquina (nesse protocolo) onde se executa o servidor - O identificador do porto a que est associado o servidor Conceptualmente a ligao pode ser efectuada explicitamente, implicitamente ou de forma automtica na RPC. Esta ltima apesar de mais simples para o programador raramente se usa pois aumenta a latncia da chamada e no permite certas sofisticaes em que um servio se executa em mltiplos servidores. No Sun-RPC explcita, no DEC h 2 alternativas. Genericamente podemos considerar os seguintes passos no protocolo de ligao: - Localizao do servidor - Autenticao - Estabelecimento de uma sesso Localizao H vrias formas. Uma soluo imediata consiste em codificar directamente o porto do servidor no programa cliente, o que um bocado inflexvel, tornando-a pouco interessante. Uma alternativa utilizar um ficheiro onde so registados os nomes e endereos dos servidores, mas a actualizao dos ficheiros trabalhosa e susceptvel de se tornar inconsistente, pelo que apenas se utiliza para registar alguns servios fundamentais (well-known) que devem estar presentes na inicializao do sistema. A aproximao mais geral a utilizao do Servio de Nomes. O servidor de nomes tem um endereo bem conhecido que permite localiz-lo na inicializao. Como o servidor regista os seus servios no Servio de nomes. Na definio dos servios, coloca-se o habitual problema da designao de um tipo de servio de forma abstracta ou da sua instanciao num dado servidor. ex. servio de impresso. Por vezes o cliente apenas est interessado em obter um servio de um determinado tipo, noutras pretende seleccionar a instncia. alguns sistemas de RPC efectuam a distino permitindo escolher a forma de ligao. Outros, como o Sun-RPC, no dissociam a interface da sua instanciao obrigando o cliente a conhecer antecipadamente a mquina onde quer efectuar o

servio. No DCE, as interfaces tm nomes universais (UUID) e, portanto, o nome independente da localizao. No caso de existirem vrios servidores devolvida uma lista para o cliente escolher. H gestes de nomes que permitem ao utilizador escolher segundo critrios geogrficos, por ex. Situao mais complexa quando a interface igual mas as instncias de dados so diferentes (ex. servio bancrio com contas diferentes ou servidor de impresso com impressoras diferentes). Estes casos resolvem-se a nvel da aplicao criando servidores que conhecem a localizao dos objectos e indicam qual a mquina que o cliente deve ligar-se. No DCE este problema resolvido pelo prprio mecanismo de ligao que permite especificar os objectos. Autenticao Quando se estabelece a ligao o cliente deve indicar a sua identidade para que o servidor valide os direitos de acesso. A autenticao levante enormes problemas devido s ameaas de segurana (escutas, modificaes de mensagens). Isto tratado por protocolos de autenticao que podem ser includos na maioria dos protocolos de RPC. Estabelecimento da sesso No final do protocolo de ligao, o cliente tem de registar a informao sobre o servidor que utilizar nas chamadas seguintes. o processo conduz ao preenchimento de uma estrutura de dados que funcionar como identificador da sesso (binding handle). Por exemplo criando um socket e registando a sua referncia. Do lado do servidor, o estabelecimento da ligao poder ou no dar origem criao 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 precauo alguma, isto nos canais sem ligao. O identificador de sesso pode aparecer explicitamente como parmetro das funes de adaptao ou ser escondido no suporte de execuo e utilizado implicitamente. No Sun so sempre explcitas. No DCE pode optar-se por 3 hipteses: - Explcita obriga a estabelecer a ligao chamando as rotinas de biblioteca, de que resulta o preenchimento de um binding handle que deve ser passado como primeiro parmetro para as rotinas de adaptao. - Automtica o cliente no efectua explicitamente a ligao, sendo esta transparentemente despoletada pela invocao de uma chamada remota. - Implcita soluo intermdia em que se efectua a ligao de forma explcita, mas a informao da estrutura de ligao mantida em variveis globais no suporte do RPC, evitando pass-la como parmetro. Isto d ao programador a possibilidade de escolha entre um mecanismos simples e um complexo mas que permite criar polticas de interaco mais sofisticadas (mltiplos servidores, segurana) 4.3.3. Semntica da Execuo Modelo de Faltas Num ambiente local a percepo da falta relativamente bvia: o processo aborta, a mquina pra, etc. Num ambiente distribudo 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 - O cliente aborta A forma como o protocolo RPC recupera das faltas define a semntica de execuo da chamada remota. Idealmente devia ser igual a local mas isso no atingvel. S interessa tratar as faltas que comprometem a oferta do servio e que tm elevada probabilidade de ocorrer. As outras so erros ou catstrofes. O RPC s trata as primeiras. As faltas de comunicao so as mais provveis.

As perdas de mensagem no nvel de transporte podem ser eliminadas com um transporte com ligao, mas isto tem o tempo de latncia. As faltas por paragem nas mquinas so mais complexas de tratar porque obrigam a manter o estado voltil. No so normalmente tidas em conta no modelo do RPC, sendo tratadas nos sistemas de tolerncia a faltas do tipo transaccional. Recuperao das Faltas Tem de se usar um temporizador, se no as faltas nunca mais eram detectadas, para libertar o processo cliente. Mas isto no recupera a falta, o que limita a transparncia. esta semntica do tipo talvez (may-be). talvez se tenha executado talvez no, e pode ser adequada a redes com diminutas taxas de erros ou que prefiram optimizar o desempenho em detrimento da fiabilidade. A soluo habitual reenviar a mensagem de invocao. Mas como o cliente no consegue discernir entre uma perda de trx. ou demora do servidor, possvel que o servidor receba a invocao em duplicado. a semntica de pelo-menos-uma-vez (at-least-once). Isto no o que se espera e em algumas aplicaes pode ser perigoso (actualizao de contas bancrias). Para garantir o funcionamento correcto com esta semntica o servidor deve apenas oferecer funes idempotentes. Uma semntica que se aproxima mais do habitual em modo local a no-mximo-uma-vez (atmost-once). Aqui necessrio filtrar as mensagens duplicadas, pelo que estas tm de ter um identificador e o servidor tem de ter uma tabela com a identificao das operaes em curso. O cliente e o servidor devem manter as mensagens, respectivamente de invocao e de resposta at que estas seja confirmadas. a mais habitual em sistemas comerciais. O problema de garantir a semntica exactamente-uma-vez advm da impossibilidade de se o servidor falhar saber exactamente o seu estado. So necessrios mecanismos do tipo transaccional que permitam manter o estado voltil da execuo das invocaes remotas. Protocolo de Controlo Um dos seus objectivos garantir a semntica da execuo e optimizar o desempenho, tendo em conta a relativamente conhecida natureza da interaco entre cliente e servidor. O protocolo de transporte com ligao mascara algumas faltas, como vimos, simplificando o protocolo de controlo. Mas para interaces espordicas o tempo de latncia sobrepe-se ao de trx. Uma soluo a definio de protocolo de RPC que implemente todos os mecanismos de controlo necessrios sobre um transporte mnimo sem ligao e sem fragmentao. Um dos mais conhecidos da Xerox. Implementa a no-mximo-uma-vez e tenta minimizar o n de mensagens trocadas, que no caso ideal podem ser apenas 2. para alm do identificador de procedimento a invocar e dos argumentos, enviado na mensagem de invocao um identificador de chamada, que permite ao cliente assegurar-se do correcto emparelhamento entre a mensagem de invocao e de resposta e ao servidor filtrar os pacotes resultantes de retrx. O identificador de chamada tem 3 campos: - Endereo da mquina cliente - Identificador do processo cliente - N de sequncia (CallID) O par dos 2 primeiros forma uma actividade. O servidor mantm tabela de actividades, rejeitando mensagens duplicadas. O servidor no pede confirmao imediata da resposta pois sabe que haver interaco futura e, nessa altura (prxima mensagem) o cliente confirmar. Por outro lado como o protocolo de transporte no efectua a fragmentao, existe a possibilidade de os dados e enviar excederem a dimenso 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 so enviados em pacotes sucessivos, tendo o servidor que confirmar a recepo antes do envio do prximo. Desta forma garante-se a ordem correcta de recepo. 4.3.4. Protocolo de Apresentao de Dados Na converso dos dados para um formato coerente no sistema distribudo, colocam-se 2 problemas: a descrio do tipo de dados para evitar ambiguidades na converso e o protocolo que define o formato para a trx. No esforo de normalizao OSI, a ASN1 uma notao abstarcta, independente de uma linguagem; a norma 8825 define a transfer syntax.

Na maioria dos sistemas RPC evitou-se a estruturao em 2 nveis, usando a linguagem de definio das rotinas de interface como especificao dos tipos de dados. Para trx. preciso protocolo. H 2 solues: - Explcita para cada bloco de dados colocado na mensagem um descritor (tag) que identifica o tipo - Implcita Na mensagem vo s dados e existem convenes para cada tipo de mquina. O primeiro mtodo simples mas obriga a construes complexas das mensagens. No contexto OSI e no Mach foi adoptado o ASN para transfer syntax. O tratamento implcito tem 2 variantes. A mais vulgar considerar que existe uma forma cannica de trx. que deve ser usada em todas as mensagens. de fcil gesto mas pode obrigar a converses duplas e desnecessrias se as mquinas comunicantes forem do mesmo tipo. O Sun usa esta soluo. A alternativa enviar os dados na forma como esto representados na mquina de origem, incluindo na mensagem uma identificao do tipo de mquina. bvio que esta soluo de gesto mais difcil. 4.4. Implementao e Desempenho 4.4.1. Tarefas nos Servidores Um servidor tem normalmente de servir pedidos de vrios clientes. O paralelismo vem da conjugao de mltiplos canais e utilizao de tarefas. Como natural, na programao das rotinas do servidor tem de se ter em conta o paralelismo introduzido pelas tarefas, utilizando mecanismos de sincronizao para a definio de seces crticas, gesto de recursos ou algoritmos de cooperao entre tarefas independentes. No servidor criado, na inicializao, um certo n de tarefas que se bloqueiam espera de pedidos. No entanto, este n depende do paralelismo possvel no servidor, no adiantando ter demasiadas tarefas, porque elas se bloqueariam espera de recursos partilhados. Realizaes mais sofisticadas criam dinamicamente tarefas. No cliente tambm pode haver paralelismo, dedicando uma tarefa para cada invocao remota. Uma tarefa para invocar outra para receber as respostas. Em termos de semntica levanta-se um problema com a ordem de recepo dos pedidos do lado do servidor, o que em certas aplicaes pode ser grave e uma posterior pode ultrapassar outra que se bloqueou. A sincronizao simples das tarefas no suficiente, pois a sequncia de operaes receber o pedido, sincronizar para estabelecer a ordem no atmica. Uma soluo 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 em Ricochete H situaes em que 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 situao pode repetir-se e h, como na recursividade, uma profundidade dos ricochetes que limitada. Do ponto de vista da biblioteca do RPC, esta situao requer que qualquer servidor possa ser cliente (fcil) e qualquer cliente possa ser servidor (difcil). O cliente tem de registar as chamadas em ricochete que quiser tratar, efectuando para isso um procedimento idntico ao de um servidor quando regista um servio no servidor de nomes. Nas bibliotecas que suportam mltiplas 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 tambm receber pedidos de invocao enviados noutro canal. Note-se que a existncia de chamadas em ricochete faz com que o cdigo no cliente seja concorrente, pois, enquanto ele est bloqueado espera de uma resposta, h um fluxo de execuo que vai processar o ricochete, pelo que a sincronizao se torna complexa. Se a chamada em ricochete tentar adquirir um recurso j detido 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 ligao com o servidor - Latncia de uma chamada simples O primeiro pode ter importncia determinante se o cliente apenas efectua uma interaco com o servidor. Este um dos argumentos na defesa da utilizao de protocolos de transporte simples, sem ligao. A execuo de um RPC simples tem as seguintes componentes temporais: - Tempo de converso e empacotamento dos parmetros de entrada e sada no cliente e no servidor (uns so mais flexveis outros mais rpidos) - Tempo de execuo do SO (Mach e Amoeba enviam pedido e esperam resposta logo evitando chamadas separadas e mudanas de contexto e interrupes) - Tempo de trx. das mensagens (normalmente no determinante) RPC Local Um caso particular de optimizao o RPC local em que tanto o cliente como o servidor se executam na mesma mquina (Mach, Chorus, Windows NT). O desempenho local determinante para o desempenho global do sistema. Existem vrias tcnicas de optimizao. A passagem de parmetros pode fazer-se por intermdio de uma regio de memria partilhada entre o cliente e o servidor, evitando-se assim cpias adicionais dos dados. H uma outra tcnica (hand-off) que extremamente eficiente porque o servidor executa a parte do cdigo que necessita de privilgios especiais, mas entendido como uma extenso do cliente; o cliente oferece o seu contexto ao servidor, havendo apenas transferncia do espao de endereamento para o do servidor apenas alterando os registos que definem esse espao de endereamento. No retorno a mesma tcnica 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 portteis, privilegiam normalmente a flexibilidade e generalidade em detrimento do desempenho. Os sistemas experimentais, pelo contrrio, usam tcnicas mais agressivas de optimizao.

CAP. 5 GESTO DE NOMES 5.1. OBJECTIVOS DA GESTO DE NOMES O que importante a definio, propriedades, funcionalidade e respectiva arquitectura do servio, que na maioria das vezes aparece agregado a outras componentes do sistema. Os nomes so fundamentais para identificar, localizar e partilhar os objectos. Nos SO so ainda indispensveis para simplificar a interface com o utilizador e gerir os recursos informticos. No mbito dos SO tm um contedo semntico simples, representando uma associao (binding) entre um nome e um objecto sob controle do sistema (servidor, mquina, utilizador, ficheiro, impressora, etc.). A gesto dessas associaes o objectivo principal do servio. Os nomes identificam as entidades ou objectos sob controlo do sistema, de forma a que seja possvel discrimin-los identificadores. A localizao pode fazer interagir vrios servios de nomes nas camadas hierrquicas que constituem o sistema distribudo, at obter um identificador cuja resoluo (em geral pelo hardware) permita o acesso fsico ao objecto. Para que utilizadores e programadores partilhem recursos comuns os nomes devem ser uniformes e normalizados. Praticamente todos os mecanismos de comunicao pressupem a existncia de um servio de nomes para estabelecer a ligao. Esta caracterstica implica que os nomes possam ser transmitidos entre mquinas e SO heterogneos. So tambm indispensveis na criao de mecanismos de interface do sistema com os utilizadores. Mas tm de ser lgicos (inteligveis e mnemnicos) e no fsicos. Simplificam tambm a gesto do sistema por mecanismos de indireco que permitem alterar transparentemente a correspondncia entre os nomes e os objectos. A distribuio refora a utilidade da gesto de nomes pelas numerosas entidades que preciso designar e partilhar (endereos, nomes de mquinas, servidores, discos remotos, etc.) 5.2. CONCEITOS DE BASE Os nomes so definidos num espao de nomes que caracteriza a sua estrutura. Este espao pode ser visto como um conjunto de regras que define os nomes admissveis. Um conjunto de associaes pertencentes a um determinado espao de nomes ser designado por contexto correspondendo a uma viso parcial ou total das associaes existentes. Esta noo de contexto pode materializar-se numa tabela, ou conjunto de tabelas, que suporta o registo das associaes e que permite a resoluo dos nomes directrio. A organizao pode ser hierrquica pelo que pelo que os contextos podem ter referncias para outros contextos. Como os sistemas so hierrquicos, a resoluo pode necessitar de um conjunto de passos. Frequentemente, um objecto tem associado mais que um nome. Os nomes so simblicos, isto , usado como referncia ou elo de ligao (link) para um outro nome no mesmo espao de nomes e no referencia directamente o objecto. 5.3. ESPAO 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 no pode estar associado a dois objectos distintos. A operao de registo de um nome tem de ser autorizada por uma entidade que detm o controlo sobre um dado espao de nomes ou sob um contexto, autoridade essa que tem a responsabilidade de gerir o recurso que suporta a implementao do objecto. 5.3.2. MBITO DE UM NOME Classificao da organizao da gesto de nomes: - Global (nome absoluto) Um nome tem o mesmo significado em qualquer contexto do sistema onde o espao de nomes vlido. - Local (nome relativo) O contexto apenas engloba uma parte limitada do sistema (ex. mquina, processo), no sendo vlidos fora do contexto onde so criados. A dificuldade de implementar um sistema de nomes globais advm da dimenso do sistema. H vrias solues: - Centralizar numa nica entidade a atribuio de nomes -> maior latncia e ponto singular de falha

- Utilizar mecanismos de difuso -> limita escala a redes locais - Utilizar espaos de nomes de grande amplitude referencial As 2 primeiras solues no so escalveis para sistemas de dimenso mdia ou que tenham fortes requisitos de desempenho ou disponibilidade. O DCE utiliza a hora, data e n telefone do instalador, com 128 bits mas no prtico, normalmente impor regras demasiado complicadas. Pelo contrrio, garantir a unicidade nos nomes locais fcil, porque cada contexto pode ser gerido separadamente por uma nica autoridade, sem sacrifcio do desempenho e da disponibilidade. A desvantagem que no podem ser utilizados fora do contexto, obrigando a uma traduo. A forma mais simples de formar nomes globais, mantendo as vantagens dos locais, considerar que os nomes so formados por vrias componentes numa estrutura hierrquica (sub-contextos a nvel local). O nome obtido por concatenao do nome do contexto com o nome do objecto. Esta tcnica permite subdividir a complexidade da criao de nomes, obrigando contudo a nomes mais complexos. Ex. rede telefnica actual, endereos TCP (IP + porto). Estes nomes hierrquicos so os mais utilizados nos sistemas distribudos. 5.3.3. PUREZA DE UM NOME Para alm do problema da criao (propriedades anteriores) a pureza tem implicaes a nvel da resoluo. Se o nome tiver informao sobre a localizao do objecto, o algoritmo de resoluo pode ser optimizado. Ento teremos: - Nomes Puros: O algoritmo de resoluo no utiliza qualquer informao presente no nome para inferir da localizao do objecto ou da autoridade que o controla. ex. matrculas em Portugal, UUID do DCE. A sua vantagem a independncia da localizao do objecto relativamente informao do seu nome -> fcil aos objectos migrar do local onde foram criados, o que cada vez mais importante nos sistemas distribudos. A desvantagem a dificuldade dos algoritmos de resoluo: no h indicao de onde iniciar a pesquisa. A soluo simplista aceder a um servidor centralizado mas isso reduz desempenho. Usam-se ento tcnicas de mecanismos de cache (mas tem de continuar a haver servidor central a quem recorrer), replicar a base de nomes, difuso (custos grandes fora do contexto de rede local), utilizao de nomes com pistas (hints) caso no se consiga resolver na cache local. - Nomes Impuros: ex. portos TCP/UDP, nomes globais dos ficheiros Unix, rede telefnica fixa, URLs o que impede a mobilidade das pginas ->URI. A designao de puro/impuro ortogonal ao mbito local/global: 5.3.4. ESTRUTURA SINTCTICA DOS NOMES A diferena entre nomes e identificadores reflecte-se, essencialmente, no tipo de estrutura de dados associada ao identificador. Nos sistemas distribudos mais complexos pode haver a necessidade de interligar espaos de nomes de sistemas de mltiplos fabricantes (ex. DCE). Um exemplo interessante de um grande espao de nomes heterogneo o definido na WWW para referenciar pginas de documentos (URLs), que pretendem ser nomes universais utilizveis por todas as aplicaes que manipulam documentos na Internet. Os URL baseiam-se numa estrutura hierrquica, em que o primeiro campo define qual o esquema de designao, ou seja, qual o espao de nomes que se aplica e quais os protocolos que permitem o acesso ao objecto. <esquema>:<parte especfica> ex: http://hostport/[path][?search] 5.3.5. INFORMAO ASSOCIADA AOS NOMES A associao nome objecto pode conter, alm do identificador, atributos que sejam importantes para caracterizar os objectos em diversas aplicaes. Por ex., no Unix associam-se ao nome do utilizador o seu directrio por omisso, o shell, as variveis de ambiente. A funo de resoluo pode tambm ser complementada com facilidades para pesquisas mais complexas sobre vrios atributos. Sistemas mais elaborados como a norma X.500 aproximam-se mais do esquema conceptual das bases de dados, mas com consistncia relaxada e funes de pesquisa limitadas (servios de directrio, para distinguir dos servios de nomes tradicionais). 5.4. FUNCIONALIDADE DO SERVIO DFE NOMES Gere as associaes lgicas entre nomes e objectos. A funo inicial corresponde ao registo da associao, isto , criao de um nome.

Esta operao verifica se a sintaxe est de acordo com as regras e a unicidade referencial. a criao tem de ser validada pela autoridade. Uma nova associao deve ser dada a conhecer a todos os contextos (distribuio das associaes) onde suposto ser vlida, o que pode implicar actualizao de directrios em vrias mquinas, colocando os problemas habituais de consistncia na presena de faltas. A actividade mais frequente da gesto de nomes a resoluo, que pode implicar vrios contextos e espaos de nomes, sendo uma operao crtica em termos de desempenho. A gesto de nomes e a segurana so ortogonais. 5.5. ARQUITECTURA DO SISTEMA DE GESTO DE NOMES 5.5.1. MODELO Nos sistemas multiprogramados clssicos, a gesto de nomes no corresponde a uma componente autnoma e funcionalmente bem identificada dentro do sistema. Nos sistemas distribudos, o maior volume de nomes, as necessidades de partilha e a heterogeneidade obrigam a uma arquitectura diferente, tornando o servio de nomes uma componente autnoma. Tem, por isso, os problemas normais de uma arquitectura distribuda, reforados por: - Disponibilidade a gesto de nomes quase sempre usada no estabelecimento de ligao entre processos -> tem de ter disponibilidade levada - Desempenho das operaes de resoluo - Escala escalabilidade sem comprometer os pontos anteriores. Uma soluo trivial replicar toda a informao relevante nas diversas mquinas. Os problemas de gesto, coerncia e desperdcio de espao so evidentes. Inicialmente a gesto dos nomes dos sockets era assim, atravs dos ficheiros /etc/hosts e /etc/services que, em cada mquina, so o repositrio dos nomes necessrios para a comunicao distribuda, mas a gesto destes ficheiros por diferentes administradores leva a incongruncias, no sendo portanto escalvel, Uma outra soluo usar a difuso para traduzir um nome. O cliente envia o pedido parta a rede e o servidor que tivesse a associao no seu contexto respondia. Isto s aplicvel a redes locais, devido apreo e no escalvel (ex. NetBios e Windows). A gesto de nomes uma aplicao intrinsecamente distribuda, pelo que uma arquitectura cliente-servidor permite criar uma soluo que resolve os problemas referidos anteriormente. Podemos considerar os seguintes componentes: - Interface com os programas utilizadores Agente do servio de nomes - Estrutura do servidor de nomes - Mecanismos de armazenamento nos servidores. 5.5.2. O AGENTE DO SERVIO DE NOMES Coloca-se o problema da inicializao do agente. Para efectuar a primeira operao sobre o servio de nomes, o agente tem de conhecer o endereo do servidor e no o pode obter atravs do servio de nomes. Existem vrias solues que diferem na flexibilidade de definio do endereo e no aumento de trfego na rede que geram: - Considerar que o porto associado ao servidor fixo (well-known) - Difuso peridica do endereo dos servidores - Pedido em difuso na inicializao do agente, do endereo do servidor de nomes Depois de obtido o endereo, o agente invoca uma operao, geralmente uma resoluo. No caso da resoluo no poder ser executada pelo servidor contactado, a sua finalizao 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 responsvel, reenviando o pedido a outros servidores - Transitivo O servidor transfere o pedido para o servidor seguinte. O servidor inicial no fica responsvel. A soluo iterativa a mais simples para o servidor. Na Internet este protocolo implementado por todos os servidores. As solues recursiva e iterativa simplificam a funcionalidade do agente pois o servidor actua como nico responsvel da resoluo do nome. A recursiva til em diversos casos agentes simples; diferenas de protocolo; servidor fica em contacto com a gente e refresca a sua cache.

5.5.3. O SERVIDOR DE NOMES Um servidor centralizado impraticvel, no 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 frequncia e algumas inconsistncias so tolerveis, redundando apenas num maior tempo de latncia (ex. socket associado a um determinado servidor num RPC mudou, d erro, mas cliente pode tentar traduzir novamente). As 2 caractersticas simplificam mecanismos de cache (aumento de desempenho) e replicao (aumento de disponibilidade). O algoritmo de resoluo simples: o servidor verifica se o nome pertence ao contexto que gere e, em caso afirmativo, procura informao local. Se for de outro contexto contacta o servidor responsvel ou informa o cliente. Se o nome impuro com uma estrutura hierrquica, 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 mantm caches dos nomes traduzidos recentemente Princpio da Localidade permite augurar boas perfomances. Mas como a cache pode no estar actualizada o cliente tem de ser informado que a resoluo da cache e no da raiz. S no caso de o nome no se encontrar na cache, ter de ser contactado o servidor de um contexto presente no nome. DISPONIBILIDADE DO SERVIDOR Como em qualquer situao de replicao, existe implcito um compromisso entre a consistncia dos dados e a sobrecarga nos ns gestores e na rede de comunicao. A organizao mais simples o servidor mestre se encarregar da gesto dos servidores replicados. Os problemas colocam-se em 2 situaes: - Quando o mestre falha antes de propagar actualizaes - Existncia de falhas de comunicao ou nos escravos como h uma certa tolerncia, as actualizaes peridicas chegam para resolver o problema. ARMAZENAMENTO DA INFORMAO Nos servidores h informao voltil e persistente. Esta coloca os problemas clssicos da busca em bases de informao enormes (tempo). Uma boa soluo so os programas para gesto de ficheiros sequenciais indexados como o dbm. No preciso SGBD comerciais. 5.6. EXEMPLOS DE SERVIOS DE NOMES Duas arquitecturas com objectivos parcialmente diferentes: - O DNS para rede de grande escala (preocupaes de redundncia, optimizao de desempenho e reduo de trfego) - O NIS simplificar gesto de redes locais Unix 5.6.1. DOMAIN NAME SERVICE Gere os nomes das mquinas na Internet. O sistema de nomes inicial da Internet era global e puro, gerido de forma central com distribuio via ftp para actualizao das caches, o que rapidamente se revelou insustentvel. ESPAO DE NOMES global, hierrquico e impuro. Os nomes so definidos numa estrutura em rvore como uma hierarquia de contextos. Cada contexto designado de domnio e identificado por uma cadeia de caracteres e tem associado uma autoridade. O nome global resulta de concatenao, com separao por ponto (.) A ordem da concatenao parte das folhas para a raiz, ao contrrio dos ficheiros Unix. A raiz representada por uma cadeia de caracteres vazia. ex. sina.inesc.pt. . Os domnios so lgicos. A autoridade pt a FCCN. REGISTOS Os nomes DNS podem ser associados a diferentes tipos de informao. Esta encontra-se organizada em registos, normalmente designados RR (resource register). Os registos tm tamanho varivel e so tipificados em termos de classe e tipo. A classe discrimina famlias de nomes associados a protocolos diferentes, ou seja, espaos de nomes diferentes que podem coexistir no mesmo servio 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 Contedo

A MX CNAME NS SOA PTR TXT WKS HINFO

Endereo IP Mquina ou domnio do servidor preferencial de correio electrnico Nome simblico para outro nome DNS Servidores de uma zona Parmetros que definem a zona Nome DNS para a resoluo inversa de um endereo IP Texto arbitrrio Descrio de um servio com os respectivos nomes e protocolos Arquitectura e sistema operativo do n

A operao mais relevante no DNS a resoluo do nome para obter a informao contida no registo respectivo. Estas operaes so parametrizadas pela classe e tipo do registo pretendido ARQUITECTURA DO DNS Baseia-se no conceito de zona, que corresponde a uma subrvore que comea num domnio e se estende at s folhas ou at um domnio onde comeam outras zonas. Cada zona gerida por uma autoridade que tem a responsabilidade de instalar e gerir os servidores de nomes. O BIND uma implementao do servio de nomes DNS desenvolvida para a verso 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 primrio gere os ficheiros com as tabelas de nomes e actualiza o secundrio que s rplica e s tem cache. A cada entrada associado um TTL (time to live). Para optimizar a estrutura do servio em redes locais, existem duas possibilidades de configurao que designaremos por servidor remoto e de reencaminhamento (forwarding). No primeiro, o resolver actua como um cliente remoto de um servidor que se executa numa mquina com acesso Internet, pelo que a mquina local no tem servidor DNS. No segundo, o servidor local, perante um pedido no satisfeito, reenvia-o para uma lista de servidores que implementam a resoluo recursiva dos nomes, que so os que se encarregam da interaco com os servidores externos. Isto duplamente interessante pois evita que sejam logo contactados os servidores primrios de outros domnios pelo servidor que no tem a informao em cache e o servidor mestre da rede pode progressivamente ter em cache um maior n de nomes, reduzindo os acessos ao exterior. A informao de base para o servidor primrio 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 primrio) hostmaster.inesc.pt (endereo de e-mail do responsvel pela gesto do domnio) (1995083015; serial (contador incrementado sempre que o ficheiro de base seja alterado e que permite sinalizar aos servidores secundrios que a base de dados foi modificada) + refresh frequncia de actualizao dos servidores, temporizao para o refrescamento, perodo limite sem refrescamento e TTL) 5.6.2. NIS NETWORK INFORMATION SERVICE Para a gesto de uma rede local de mquinas Unix, a SUN desenvolveu o servio NIS. O sistema pretende simplificar, evitando que os nomes utilizados (pelo SO e utilitrios) nas vrias mquinas sejam mantidos de forma fragmentada. Usando o NIS o administrador da rede pode distribuir e actualizar a informao sobre nomes de um nico ponto da rede, de forma automtica e fivel. ESPAO DE NOMES Nomes so encontrados nos ficheiros da directoria /etc, por ex. passwd, group, hosts, networks, services, protocols, ethers, etc. A partir destes ficheiros o NIS constri mapas. O contexto onde os nomes so vlidos o de uma rede local, locais a um domnio portanto. O NIS no 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 existncia de um servidor mestre por domnio e vrios escravos que devem gerir os mesmos mapas. O servidor designa-se por ypserv e podem existir vrios 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 ligao com o servidor ypserv. O processo ypbind apenas fornece ao cliente a informao de ligao e executa-se em todos os ns da rede. Quando um n se inicializa, o

ypbind envia um pedido em difuso 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 instalao do NIS: - Definir um domnio NIS para um grupo de mquinas (atribuir nome ao domnio, definir mquina que tem servidor mestre, n de servidores escravos necesasrios, respectivos ns e os ns clientes) - Modificar os ficheiros do directrio /etc nos clientes - Verificar no servidor mestre se os ficheiros no directrio /etc esto actualizados e se so necessrias alteraes 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 execuo o servidor do domnio (ypserv) - Inicializar nas mquinas cliente os servidores escravo atravs do comando init, mas especificando o n onde se executa o mestre. A alterao de informao sempre feita no servidor mestre e propagada aos escravos. 5.7. NORMALIZAO NA GESTO DE NOMES 5.7.1. A NORMA X.500 Pretende definir um servio de nomes distribudo de grande dimenso a grande lista telefnica mundial (directrio) para os sistemas informticos, no s relacionados com agesto de rede mas tambm com as aplicaes distribudas. A informao no directrio chama-se DIB (Directory Information Base) ESPAO DE NOMES Tem uma estrutura hierrquica em rvore (DIT Directory Information table). Cada objecto tem um nome local (RDN). O nome global (DN) composto pela concatenao a partir da raiz de todos os nomes locais, ou seja, dos RDN. A aproximao com base em classes de objectos. O directrio oferece 3 tipos de servio: Leitura, Pesquisa e Modificao. ARQUITECTURA Cada utilizador representado por um DUA (Directory User Agent) que se considera como sendo uma aplicao que interage com um conjunto de Directory System Agents (DSA). Para o utilizador transparente a que DSA se ligou. Usa tambm o mtodo recursivo ou iterativo, para alm da existncia de um de difuso, em que um DSA envia o pedido a todos os DSA que conhece. 5.7.2. GESTO DE NOMES INTEGRADA NO DCE O espao de nomes global, hierrquico e heterogneo... ler primeiro

CAP. 6 SEGURANA NOS SISTEMAS DISTRIBUDOS 6.1. INTRODUO Proteger um bem de um conjunto de ameaas. No caso dos computadores, aceder ou modificar alguma informao. Na definio global de uma estratgia de segurana que se apoia em diversos mecanismos de proteco informao, dever-se- ter em conta o valor potencial dessa informao, as ameaas esperadas, as formas de ataque e os custos. Nos militares a confidencialidade, nos comerciais a integridade. Com base nestes elementos estabelece-se uma poltica de segurana com determinados procedimentos e mecanismos. Quer no mundo real quer nos sistemas informticos, a existncia de partilha a principal fonte de ameaas. Os mecanismos que implementam a segurana tm sempre um custo, a nvel de hardware ou a nvel de tempo. A complementaridade entre poltica e mecanismos de proteco crucial para atingor o resultado final. 6.2. POLTICAS DE SEGURANA NOS SISTEMAS INFORMTICOS Historicamente o problema da segurana nos SO apareceu aquando das partilhas de recursos nos sistemas multiprogramados. Num sistema de informao genrico as ameaas so: - Acesso no autorizado informao - Modificao no autorizada da informao - Execuo de operaes que conduzam ao uso no autorizado de recursos do sistema ou sob sua gesto - Perturbar o acesso legtimo de utilizadores a recursos do sistema - Aces de vandalismo Para descrever a segurana num SI usa-se no modelo o agente (utilizador ou algum com responsabilidade na oferta de um servio), que representa uma entidade que pretende executar uma operao sobre um objecto. O agente est representado no sistema atravs de um processo que a entidade activa que executa as operaes. Nos sistemas multiprogramados as polticas de segurana classificam-se em 3 tipos: - Isolamento dos Agentes o agente est confinado sua mquina virtual. Todas as interaces com o exterior so controladas pelo sistema. - Controlo dos Direitos de Acesso extenso do anterior. Os agentes podem partilhar recursos (ler, escrever e executar). Com base na lista de operaes que o recurso disponibiliza, estabelece-se os direitos de cada agente. Controlado por um componente do sistema - Controlo do Nvel de Segurana da Informao Poltica dinmica de controlo de acesso que tem em conta a funo do agente e um nvel de segurana do objecto, definido com base em regras o direito de acesso, num dado instante do agente ao objecto. A extenso para sistemas distribudos relativamente bvia. 6.2.1. ISOLAMENTO DOS AGENTES Os objectos geridos pelo sistema pertencem a um nico agente, o que estabelece uma relao de dono entre o objecto e o agente. Nos multiprogramados, como bvio, o isolamento lgico, existindo vrios utilizadores que partilham a mesma mquina. O gestor de mquinas virtuais, ou seja, o SO responsvel por garantir que todas as interaces so estritamente controladas, de acordo com o princpio do isolamento. A poltica de isolamento dos agentes obriga a que exista uma operao de base que valide a identidade do agente e que designaremos por autenticao desafio (login). As hipteses de ataque ao isolamento so: - Descobrir as palavras-chave de identificao - Assumir a identidade de outro utilizador no SO - Executar operaes que indirectamente ultrapassam os mecanismos de proteco - Infiltrar cdigo (cavalos de Tria, vrus, vermes) em programas utilizador ou do sistema que permitem executar sub-repticiamente aces que ultrapassem os mecanismos de proteco do sistema

- Canis encobertos (covert channels) que permitem obter informao atravs da medida de outras grandezas Os ataques s palavras chave so feitos habitualmente construindo dicionrios de palavras (actores,...) que depois so cifrados e comparados com as do ficheiro passwd. Um dos parmetros que fragiliza a segurana das palavras-chave prende-se com o tempo de execuo do algoritmo de cifra. A personificao pode se feitas depois de obter a palavra-chave de um utilizador, ou mais sofisticadamente capturar a informao de identificao nos pacotes que circulam na rede e reutiliz-la mais tarde. Os cavalos de Tria surgem nos sistemas onde se permite a partilha de cdigo, o que comum por razes bvias de diminuio do espao de memria utilizada. Se a um programa com privilgios se adicionar um pedao de cdigo que execute outras funes (tipo acedam a informao confidencial como as passwords o que permite ao atacante ultrapassar os mecanismos de proteco). Os cavalos de Tria dos PCs so vrus, nos sistemas distribudos so vermes. A distino depende dos autores mas todos significam adio de cdigo a programas inofensivos, que aproveitam a execuo do programa hospedeiro para detectar outros que podem infectar. No DOS muito fcil devido inexistncia de proteco da memria e dos ficheiros. Os vermes tm um comportamento semelhante no sistema distribudo, detectando as mquinas acessveis a partir de um n e exportando-se associados a mensagens entre aplicaes distribudas como o sendmail ou o ftp. Uma ameaa potencial advm da existncia de operaes de E/S e de aces assncronas de que difcil verificar se mantm o mesmo princpio de isolamento. O isolamento entre o ncleo do sistema e os processos pode ser tambm uma ameaa, por exemplo, subvertendo as funes sistema atravs de parmetros indevidos, como endereos virtuais do espao de endereamento de outros agentes ou do ncleo. 6.2.2. CONTROLO DOS DIREITOS DE ACESSO Pode ser considerado como uma evoluo da anterior, permitindo a partilha de objectos entre mquinas virtuais. O conceito de base nesta poltica 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 operaes que sobre ele se podem executar. A matriz especifica para cada par agente/objecto os direitos que o agente tem de executar operaes nos objectos. A matriz lgica e materializada em estrutura de dados de 1 de 2 formas possveis: - 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 tm vantagens, dependendo do n de agentes e de objectos do sistema, pelo que a comparao difere quando se consideram sistemas centralizados e distribudos. Neste caso temos de ter 2 operaes de base: - Autenticao Operao de validao da identidade do agente - Autorizao Operao que valida os direitos do agente sobre o objecto A entidade que verifica a autorizao o monitor de controlo de referncias, que uma abstraco que representa o conjunto de mecanismos de controlo de acesso, normalmente residente no cdigo de suporte ao servidor onde o objecto reside. Os direitos associados a cada objecto podem ser mudados pelo dono do objecto, que tem controlo discricionrio sobre o objecto. Normalmente a revogao de direitos s entra em vigor na prxima utilizao do objecto porque a revogao imediata complexa. Os ataques so 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 referncias. Os objectos s podem ser acedidos atravs do monitor, dai os processos utilizador no poderem fazer E/S directamente (ex. ficheiros).

Num sistema multiprogramado a informao relativa matriz mantida no ncleo. Nos distribudos tem de haver comunicao entre elas, pelo que h o perigo de serem interceptadas. Em Unix agente identifica-se no login -> UID que fica registado no contexto ncleo do processo e, portanto, fica protegido pelo sistema. O UID identifica o agente perante o monitor nas operaes de autorizao. No sistema de ficheiros Unix, os direitos de acesso so armazenados numa ACL mantida no descritor do ficheiro (inode). 6.2.3. MODIFICAO DINMICA DOS DIREITOS DE ACESSO A associao anterior esttica, que mais simples mas torna inflexvel o comportamento dos agentes em relao aos objectos durante a execuo. O conceito anterior pode ser estendido, considerando um nvel de indireco que vamos designar por domnio de proteco. Podemos na matriz de direitos considerar que na coluna no identificamos directamente os agentes, mas domnios de proteco. Cada domnio define os respectivos direitos sobre os objectos. Um agente executa-se sempre num determinado domnio de proteco, contudo, durante a execuo o domnio pode ser dinamicamente alterado. Para isso preciso mais uma operao: de alterao do domnio associado a um agente, sempre de acordo com regras preestabelecidas. O Multics introduziu este conceito para gesto da proteco do espao de endereamento dos processos, que conhecido por mecanismo de proteco em anis, onde para mudar de anel, invocada uma gate. Ainda hoje existe nos Intel. No Unix atravs do set UID (SUID). Quando se executa um ficheiro atravs da funo exec, h a possibilidade de o processo mudar a identificao do utilizador, se no ficheiro executvel existir uma indicao especial que faz com que o processo assuma a identidade do dono do ficheiro durante a execuo do programa. O processo tem 2 domnios associados: o do utilizador UID e o do grupo GID. A operao de alterao de domnio conceptualmente muito crtica para a segurana, porque permite a personificao de qualquer outro agente. Precisamente o setUID revela-se um dos pontos fracos da segurana do Unix. 6.2.4.CONTRLO DO NVEL DE SEGURANA DA INFORMAO O poder discricionrio do dono nos mtodos de controlo de acesso que vimos anteriormente podem ser antes mandatrios sobre os objectos, obrigando ao cumprimento de regras de proteco que tm em conta o grau de segurana que se atribui ao agente e o tipo de utilizao que pretende do objecto. uma viso militar. Os objectos so classificados de acordo com o seu nvel de confidencialidade, por ex. Muito Secreto, Secreto, Restrito, No Classificado. Para alm disso a informao classificada de acordo com o assunto (Nato, Comunicaes). Os agentes tm autorizaes (clearances) que definem os compartimentos e o nvel de segurana a que podem aceder. 6.3. BASE COMPUTACIONAL DE CONFIANA Os mecanismos de proteco so hierrquicos e por isso, para ser tudo coerente, deve ser concebida uma plataforma, que se baseia em tcnicas elementares e provadamente eficazes, que servem para edificar a arquitectura do sistema de segurana. No caso dos sistemas multiprogramados os utilizadores consideram o SO como o garante da segurana. Esse SO usa os mecanismos elementares: - Isolamento dos espaos de endereamento (hardware de gesto de memria) - Restrio execuo em modo utilizador de instrues privilegiadas que possam ultrapassar o isolamento dos espaos de endereamento (ex. interrupes, operaes E/S) - Utilizao do ncleo exclusivamente atravs de funes sistema - Algoritmos de criptografia Os mecanismos de proteco podem, contudo, no ser suficientes contra determinadas ameaas, que por deficiente cobertura dos ataques quer por efeitos indirectos que permitam ultrapass-los. Para explicitar a parte do SO responsvel pela segurana, foi introduzido o conceito de Base Computacional de Confiana (TCB). Faz parte do TCB tudo o que no SO necessrio para garantir a poltica de segurana. O Departamento de Defesa dos EUA props uma taxonomia para caracterizar o nvel de segurana o Orange Book de que em Portugal usada a verso SEGNAC-4. Nesse book so definidas 4 classes:

D proteco mnima C Poltica baseada no controlo de acessos, vulgar nos SO comerciais B Polticas baseadas em controlo mandatrio A A classificao mais elevada que implica no s a existncia dos mecanismos mas a sua verificao formal. 6.4. POLTICA DE SEGURANA NOS SISTEMAS DISTRIBUDOS 6.4.1. AMEAAS A TCB tem de ser reequacionada tendo em conta a escala que a torna propcia a diversos ataques. Ao nvel da comunicao, podemos considerar os seguintes mtodos de ataque: - Escuta de mensagens - Modificao, insero ou remoo de mensagens para que o receptor aceite dados falsificados - Repetio de mensagens antigas A mais simples a escuta (interpretao dos pacotes captura e escrita em ficheiros de todas as mensagens). H at programas de verificao Ethernet que, duma forma promscua permitem isso. A soluo o recurso criptografia canais seguros com esquemas de cifra. A modificao j implica esquema que permita interpretar o protocolo de comunicao e capacidade de recepo e envio de mensagens. A soluo a combinao de preveno, deteco e tcnicas de recuperao, como por ex. o CRC embora este no elimine totalmente pois o pirata pode alterar e recalcular o CRC. Ento tcnicas baseadas em criptografia permitem obter cdigos que asseguram a integridade das mensagens (MIC) que no podem ser alterados sem que algum conhea uma chave. Veremos esta tcnica na assinatura digital de documentos. O 3 ataque mais subtil porque se baseia em informao correcta gerada por agentes autnticos. Para detectar mensagens desactualizadas h que pr nonces ou timestamps -> sincronizao das mquinas. A viso genrica da TCB pode hierarquizar-se: - Rede e SO considerados seguros - Rede no segura e SO seguros - Rede e SO no seguros No pressupor que uma rede segura a situao mais vulgar quando se consideram redes de alguma dimenso ou que ultrapassem os limites fsicos de uma instituio. Basta pensar na Internet -> as dificuldades de garantir um sistema seguro so maiores. Na definio de uma poltica para este sistema dever-se- suspeitar do interlocutor quer seja cliente ou servidor. O princpio da suspeita mtua obriga a uma validao cuidadosa de todas as interaces, apesar dos custos libertam manuteno por pessoal especiazado. 6.4.2. MODELO Nos sistemas distribudos partimos do modelo inicial em que um agente que pretende executar uma dada operao sobre um objecto mantido num servidor. O canal de comunicao tem de ser seguro. No servidor ter de ser verificada a identidade do agente e validar se o agente tem direito a executar essa operao, o que feito pelo monitor de controlo de referncias. O canal seguro implementado por mecanismos de criptografia. O mecanismo de autenticao para ser seguro no basta ser do tipo desafio, fazendo intervir as tcnicas de base de constituio de canais de informao seguros e evitam a repetio da informao. O mecanismo de autorizao 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 poltica de controlo de acessos aos SD, o TCB deve oferecer os seguintes mecanismos: - Canais de comunicao seguros - Autenticao dos agentes - Autorizao no acesso aos objectos - Integridade e autenticidade da informao. 6.5. CANAIS DE COMUNICAO SEGUROS 6.5.1. CRIPTOGRAFIA

Baseia-se na aplicao de uma funo que transforma a informao inteligvel (claro) em cifrada. Para obter a informao original preciso conhecer a funo inversa. As funes muito simples podem ser facilmente detectadas por anlise de padres. Para dificultar, as funes so 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 segurana de um mecanismos de cifra no se baseia no segredo do algoritmo da funo de cifra mas na dificuldade de descobrir a chave em tempo til. Difcil 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 tambm autenticar os agentes. Se a mensagem for lida pelo receptor com uma dada chave e nela estiver um valor pr-acordado, pode-se, com justificvel certeza admitir que foi enviada por um agente que possua a chave. Se a distribuio das chaves for segura, um canal criptogrfico autentica os agentes que o usam. Uma soluo bvia inserir o mecanismo no nvel de ligao, mas isso implica que os ataques podem ser feitos a mensagens nos buffers dos routers, pelo que a introduo de segurana no canal end-to-end mais seguro. Para ser independente do transporte usado faz-se normalmente no protocolo de RPC. As tcnicas criptogrficas para implementar o canal de extremo a extremo podem subdividir-se em 2 grupos: - Chave secreta ou criptografia simtrica uma chave partilhada exclusivamente pelos 2 agentes que interactuam sobre um canal - Chave Pblica ou criptografia assimtrica existem 2 chaves, uma conhecida publicamente que permite cifrar ou decifrar a informao e outra chave que dever ser mantida secreta. 6.5.3. CHAVE SECRETA Baseiam-se na existncia de uma funo de cifra e uma chave que apenas deve ser do conhecimento do emissor e do receptor. Os algoritmos de cifra com chave pblica baseiam-se em permutaes (para difundir) e substituies (para confundir) seguindo um princpio explicitado por Shanon que considera que as 2 tcnicas para esconder informao so: confuso para que a entrada no tenha a ver com a sada e difuso para espalhar o efeito das modificaes por toda a informao. O problema inerente a este algoritmo que se baseia na partilha de uma chave a toda a partilha induz uma fragilidade de segurana. A distribuio de chaves aos interlocutores, ou pelo menos um deles, um dos problemas deste mtodo. A chave deve ser enviada de forma segura. Admitindo que o foi, o canal de comunicao seguro 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, em notao simplificada: E -> R: {M}k O algoritmo DES (Data Encription Standard) a base dos sistemas computorizados de criptografia simtrica. Na verso mais usual transforma um bloco de 64 (quanto maior melhor mas torna processamento muito complexo, 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 aplicao palavra de 64 bits de permutaes e substituies por funes no invertveis. O algoritmo tem 18 etapas e pode ser estudado na pgina 264 + 265. intensivo em termos computacionais, sendo lento quando executado em software mas adaptase bem em CIs. H 2 formas de utilizao de sistemas de cifra: stream e padding. Os stream so mais robustos e fceis de construir mas apresentam o problema de um erro num bit poder tornar indecifrvel 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 informao produz o mesmo texto, permitindo anlise de padres. CBC Chipter Block Chaining ... OFB Output Feedback Mode ... 6.5.4. CHAVE PBLICA Evitam a transferncia 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 pblica 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 informao trx., devido ao conhecimento da chave privada. O mtodo baseia-se na dificuldade de factorizar ns grandes, de cerca de uma centena de dgitos em ns primos. A maioria dos algoritmos de chave pblica baseia-se numa aritmtica modular, que usa ns inteiros inferiores a N. Os resultados das operaes aritmticas so divididos por N e tomando-se apenas o resto (ex. multiplicao modular: X*Y mod N). No quadro da pgina 269 (X*Y) mod 10, pode ver-se que a multiplicao por 3, 5, 7 (primos) constitui uma cifra de substituio para valores numricos, porque permite efectuar uma substituio biunvoca dos algarismos. Se escolhssemos 3 para cifrar as mensagens numricas, decifrar a informao implicaria multiplicar pelo inverso do n. Mas numa aritmtica modular, o valor inverso no a fraco inversa do multiplicador, mas o n que respeita a seguinte equao X*X-1 mod N = 1 Ex. 7 seria o inverso multiplicativo de 3 mas complexo determinar este inverso para ns de 100 dgitos. Com a exponenciao existem resultados semelhantes, que so a base dos mtodos de chave pblica. O RSA o mais usado e base da norma nos EUA. Genericamente, o algoritmo utiliza uma aritmtica modular (mdulo N9, cifrando com base na exponenciao modular com a chave pblica Kp e decifrando ao efectuar a exponenciao modular com a chave privada que o inverso exponencial da chave pblica numa aritmtica modular. A informao subdividida em blocos de 2k < N (usualmente 256 ou 512 bits): Emissor: {M}Kp = (MKp) mod N Receptor: M = {M}Kp Ks mod N Para ilustrar o clculo das chaves, ver pg. 270 e 271 Diffie-Hellman anterior ao RSA. ... 6.5.5. DISTRIBUIO DAS CHAVES Em ambos os mtodos coloca-se o problema da distribuio das chaves. No mtodo da chave secreta, os 2 processos dialogantes tm de ter a certeza que possuem uma chave que no foi divulgada. A transmisso segura da chave assume, portanto, particular relevncia. No sendo rentvel e eficiente o uso de vias separadas, pode-se utilizar uma 3 entidade que se assume segura, um Servidor de Distribuio de Chaves (KDS), que se encarrega de autenticar ios interlocutores e distribuir as chaves. No sistema de chave pblica, o problema anterior no se pe, porque no h partilha de chaves, mas o atacante, porque se deve obter a chave pblica de um servidor, fabricar um par e alterando o endereo fazer-se passar pelo servidor. A soluo, tal como anteriormente, ter uma autoridade segura de distribuio de chaves pblicas, associando-se ainda uma assinatura digital, que consiste em cifrar a chave pblica pretendida com a chave privada do servidor. Neste caso os servidores fornecem certificados aos seus utilizadores. Quando um agente contacta o servidor para saber a chave pblica de um outro agente, -lhe devolvido um certificado composto pelo nome do agente que pretende contactar e pela respectiva chave pblica. Esta informao cifrada com a chave privada do servidor. Para que os agentes sejam capazes de usar esta chave, tm de possuir a chave pblica do servidor. Como os certificados no so falsificveis, podem ser colocados em servidores de nomes sem mecanismos extra de segurana. claro que o servidor de certificados (CA) torna-se o ponto crtico.

6.5.6. CONSIDERAES SOBRE OS MTODOS Para se comparar os 2 mtodos temos de atender ao nvel de segurana, desempenho e complexidade do sistema. Admitindo que a distribuio de chaves igualmente segura, o nvel de segurana ainda no foi objecto de ataques com sucesso em nenhum dos mtodos mas o RSA claramente mais robusto contra ataques sistemticos. Os sistemas de chave secreta so muito mais rpidos (1000 vezes). A complexidade no pode ser avaliada de forma absoluta. O de chave secreta obriga existncia de um canal seguro, o que complexo. O de chave pblica aparentemente mais simples, mas implica autenticao para evitar que impostores divulguem chaves pblicas. Uma combinao interessante utilizar um sistema de chave pblica para a troca de chave secreta entre o agente e o servidor e, em seguida, utilizar um mtodo criptogrfico de chave secreta, com maior desempenho. 6.6. AUTENTICAO EM SISTEMAS DISTRIBUDOS Neste contexto referimo-nos autenticao entre processos computacionais: o agente utilizador e o agente servidor. Muitas aplicaes reutilizam o mtodo da autenticao 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 ligao ao servio; este responde enviando um valor que o cliente dever retornar, cifrando-o com a chave secreta associada ao canal cliente-servidor. Tem vrios problemas: no recproco, s autentica o cliente; o valor de D tem de variar; necessrio 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 impe sincronizao elevada entre relgios. O problema da chave secreta mais complexo e impe um KDS. O servidor de autenticao tem, para cada agente registado no seu servio, uma chave secreta que foi introduzida na sua base de dados de forma segura e que o agente conhece. Baseados na concluso que conhecer uma chave permite autenticar quem a possui, Needham e Schroeder definiram um servio de autenticao, utilizando sistemas de chave privada e de chave pblica. 6.6.1. CHAVE SECRETA O mecanismo baseia-se na existncia de uma chave secreta para garantir a autenticao mtua entre cliente e servidor. O protocolo tem 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 PBLICA Baseia-se na assuno que o servidor de chaves pblicas seguro. 1: C -> Saut C,S 2: Saut -> C {Kps, S} KsSaut 3: C -> S {Nc,C} Kps 4: S -> Saut C,S 5: Saut -> S {Kpc,C} KsSaut 6: S -> C {Nc, Ns} Kpc 7: C -> S {Ns}Kps 6.6.3. KERBEROS

O Kerberos foi concebido para implementar um servio de autenticao do projecto Athena, um sistema distribudo de grande dimenso 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 diferena funcional a existncia de 2 servidores de autenticao, um para a autenticao 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 vrios sistemas de ficheiros distribudos (NFS, AFS) e como componente de autenticao no DCE. H 3 tipos de objectos de segurana: - Chaves de sesso - Credencial (tickets) - Autenticadores contm informao que um servidor pode comparar com a credencial para provar a autenticidade do agente. A lgica subjacente ao sistema que o cliente efectua a sua autenticao perante o Kerberos, recebendo uma credencial para aceder ao servio de distribuio de credenciais, o TGS. Quando o cliente pretender aceder a um servio contacta o TGS que lhe fornecer a respectiva credencial. As credenciais ou tickets tm a seguinte estrutura: ticket(c,s) {c, s, t1, t2, Kcs} Ks a validade de 8 horas. Os autenticadores utilizados para validar a informao contida nas credenciais so: aut(c) {c, t} Kcs O autenticador, usado em conjunto com o ticket, permite garantir que este no est a ser usado indevidamente por algum que se apossou da credencial e indica tambm 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, Operao, Parmetros 6: S -> C {Tc+1}Kc,s, Parmetros da resposta O Kerberos implementado por um conjunto de servidores que se executam em mquinas seguras. O algoritmo de criptografia , normalmente, o DES. Os agentes podem mudar as suas palavras-chave, sendo estas actualizaes reflectidas na cpia do servidor mestre. 6.7. MECANISMOS DE AUTORIZAO 6.7.1. LISTAS DE CONTROLO DE ACESSO As listas de controlo de acesso so a forma mais vulgar de implementar os mecanismos de autorizao nos sistemas multiprogramados. No Unix um processo tem associado dois domnios de proteco definidos pelo seu cdigo de utilizador (UID) e cdigo de grupo (GID). Estes cdigos so atribudos quando o utilizador se autentica e herdados pelos processos filho. Para garantir a sua inviolabilidade, so armazenados no contexto ncleo do processo, sendo usados nas funes sistema de acesso aos objectos para validar a possibilidade de execuo de determinada operao. Conceptualmente, a matriz de controlo de acessos de um sistema Unix teria tantas linhas quantos os valores dos UID e GID definidos numa mquina e um n de colunas igual ao somatrio de objectos sob controlo do sistema: ficheiros, processo, semforos, caixas de correio, zonas de memria partilhada, etc.. Cada coluna da matriz constitui uma lista de controlo de acesso que deveria ser armazenada junto do respectivo objecto. Todavia, por razes histricas ... a especificao da informao de segurana foi compactada, no sistema de ficheiros, sendo restringida a 3 categorias: dono, grupo, restantes utilizadores (world). Ou seja, a matriz define os direitos de acesso para 2 domnios, sendo todos os outros, por omisso, considerados na 3 entrada. Num sistema distribudo, os grupos tm uma formulao diferente, dado que so realmente conjuntos dinmicos constitudos 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 privilgios. As listas de acesso efectuam a correspondncia entre os utilizadores e grupos nos respectivos privilgios de acesso aos objectos. As listas so conceptualmente constitudas por 2 sublistas: uma de direitos positivos e outra de negativos, que so forma expedita de revogao de direitos. O algoritmo de verificao de direitos relativamente simples. Para um dado utilizador ou grupo, podem-se calcular todos os grupos a que pertence pela transitividade da funo membro de. Este conjunto denominado CPS (Current Protection Subdomain) e representa todos os domnios de proteco a que um utilizador est ligado. Quando um utilizador se posiciona num directrio, os grupos da respectiva lista de acesso e o CPS do utilizador so comparados sistematicamente. 6.7.2. CAPACIDADES ...

CAP. 7 TOLERNCIA A FALTAS 7.1. AS FALTAS NOS SISTEMAS COMPUTACIONAIS O sistema falha quando se desvia da sua especificao de funcionamento, ou seja, quando num determinado estado se observa que o resultado produzido por uma dada entrada no corresponde ao resultado esperado. Conceptualmente vamos considerar que uma falta um acontecimento que altera o padro normal de funcionamento de um dado componente do sistema, e que poder obrigar o sistema a evoluir para um estado interno errado (no pertence ao conjunto de estados admissveis na sua especificao), ou que poder evoluir para um estado admissvel mas atravs de uma sequncia de estados incorrecta. Ento deu-se um erro. Em resposta a determinadas entradas, um sistema num estado errado ir ser incapaz de oferecer o servio especificado e teremos um falha. A falta pode ser latente enquanto no se produzir um erro. E um erro pode ser latente se no se produzir uma falha e no houver mecanismos de autodeteco 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 manuteno 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 servio. falta -> erro -> falha Um sistema composto por vrios componentes, de uma forma hierrquica, sendo normalmente uma falha num subsistema, uma falta no nvel hierarquicamente superior. A anlise destas relaes fundamental para definir um modelo de faltas de um determinado nvel do sistema. As faltas de hardware esto associadas fiabilidade dos componentes, as de software aos problemas de desenvolvimento dos programas, sendo as mais difceis de tratar aquelas que apenas se manifestam em situaes particulares de carga do sistema ou de sincronizao dos processos. H ainda as resultantes de operao humana. Ao contrrio do hardware, cuja fiabilidade tem aumentado, o software permanece com a maior fonte de problemas, apesar das tcnicas modernas usadas. A regra emprica que h 3 erros em cada mil linhas de cdigo. As falhas so particularmente relevantes quando pem em causa a informao persistente, pelo que a tolerncia a faltas apareceu muito associada aos sistemas de gesto de base de dados. Tipos de Faltas Laprie Taxonomia baseada na causa, origem e durao. A causa pode ser: Fsica (elctrica, mecnica) ou Humana (concepo, operao, maliciosa) A origem pode ser Interna ou Externa (temperatura, energia elctrica) A durao pode ser Permanente (+ fcil de detectar) ou Temporria (elevao de temperatura) As temporrias so caractersticas dos sistemas de comunicao, onde alteraes do campo electromagntico conduzem a alterao da informao no meio de trx. -> a maioria recuperada com repetio. Nas humanas h as acidentais e as intencionais (prendem-se com a segurana-cap.6). sempre necessrio subdividir entre expectveis e altamente improvveis ou de custo no compensatrio para toler-las. Como sempre preciso ponderar a relao custo/confiana face ao domnio de aplicao do sistema. Os erros que permanecerem fora do conjunto que decidirmos tratar/tolerar so considerados catstrofes. A relao entre os erros que tm possibilidade de ser tratados e o conjunto global dos erros possveis a taxa de cobertura. Na definio do universo de faltas necessria uma aproximao estruturada que considere que determinadas componentes so encapsuladas dentro de um subsistema que dever prestar um servio, interessando apenas o comportamento nas suas interfaces para evitar exploso combinatria. Por ex. num sistema centralizado vulgar considerar apenas 2 componentes susceptveis de falhar: o sistema computacional propriamente dito (hardware + SO + aplicaes) mquina ou n - -> perde-se memria voltil + cache, dando origem a uma falha por paragem (system crash) e o armazenamento persistente (media failure) estudo diz que 49% das falhas atribuveis ao hardware so devidas aos discos (cabeas...)

O comportamento do subsistema quando detecta um erro interno um aspecto relevante na definio dos mecanismos que suportam as polticas de tolerncia a falatas referidas. Simplifica de forma considervel o tratamento dos erros o facto de um sistema autodetectar a situao de erro e tomar a iniciativa de desencadear uma excepo falha silenciosa. Por ex. os discos tm controle de erros em cada sector, se no teramos de usar 2 ou 3 discos com a mesma informao. H tambm a falha rpida um estado errado detectado rapidamente e o SO ir parar a mquina. Nos sistemas distribudos, frequentemente considerado que a falha de paragem de uma mquina uma falha rpida. Nas faltas no expectveis h 2 tipos: Faltas Densas resultam da acumulao de faltas Faltas Bizantinas ou arbitrrias fogem ao padro de comportamento esperado para o componente. Ex. n que envia mensagens correctas a um interlocutor e incorrectas a outro. De difcil tratamento. Exigem mais redundncia para ser tratadas mas se no o forem so as que aparecem mais. Faltas nos Sistemas Distribudos A comunicao e independncia das mquinas conduz a modelo de faltas mais complexo. As na comunicao advm de perturbaes electromagnticas nas linhas de trx., falhas nos rgos de conexo rede, incapacidade de comutao ou recepo de pacotes, etc. Aqui vulgar considerar que a falta temporria e portanto recupervel com a repetio. Uma dificuldade intrnseca num sistema distribudo distinguir a falha de um n remoto da lentido na resposta a uma mensagem. Uma soluo so os temporizadores mas que s funcionaro adequadamente se se souber os valores mximos de comunicao e de execuo do processador remoto (difcil). Isto pressupe sistema sncrono (de relgios), que difcil. Esta situao levou a que os protocolos de deteco de faltas que funcionem sem que exista alguma dependncia em relao ao tempo tenham vindo a ser alvo de grande interesse, mas obviamente de complexidade acrescida. Outro problema o da contaminao, que pode ser de difcil tratamento se no houver mecanismos que confinem o erro. Fiabilidade E Disponibilidade A fiabilidade (reliability) mede a probabilidade de num dado intervalo de tempo no existir nenhuma falta no sistema. importante para sistemas que mexem com vida humana ou por dificuldades em reparar (satlites). A disponibilidade (availability) definida como a probabilidade do sistema estar operacional num instante de tempo, admitindo que ocorreram falhas, mas que foram todas recuperadas atravs da manuteno adequada. So complementares para a qualidade. Ex. satlite exige boa fiabilidade; caixa multibanco mais importante disponibilidade. habitual caracterizar os sistemas reparveis por grandezas como o MTBF (mean-time-betweenfailure) e o MTTR (mean-time-to-repair). Nos no reparveis usa-se o MTTF (mean-time-tofailure). 7.2. Polticas de Tolerncia a Faltas O objectivo evitar que um erro num subsistema conduza impossibilidade de prestar o servio e, portanto, falha do sistema. O primeiro passo a deteco e identificao. Levou criao de cdigos de deteco de erros (bit de paridade, CRC) pressupem um dado padro de faltas. Qualquer poltica de tolerncia a faltas baseia-se na existncia de um mecanismo redundante que possibilite que a funo da componente comprometida seja obtida de outra forma. S dispondo de redundncia, possvel tolerar faltas. Pode assumir diversas formas: espacial, com duplicao de componentes; temporal, com repetio da mesma aco; conjugao de informao adicional com algoritmos que permitem calcular o estado correcto. H 2 classes de polticas de tratamento de erros com objectivos diferentes e, consequentemente, implicando meios diferentes:

A poltica de recuperao do erro substitui um estado errado por um estado correcto, podendo tornar sem efeito algumas etapas do processamento j efectuado. A poltica de compensao do erro baseia-se na possibilidade de, mesmo na presena de um erro numa componente, ser possvel calcular um estado correcto a partir de componentes redundantes. Esta abordagem procura limitar ou eliminar o perodo de recuperao, ou seja, maximizar a disponibilidade do sistema. Ex. sensores de avio. So de grande interesse mas aplicam-se normalmente a sistemas especializados onde se pretende uma elevada disponibilidade. Para ilustrar polticas vamos mostrar 2 arquitecturas representativas: 7.3. Replicao Passiva A forma mais simples de estruturar uma aplicao distribuda ter um servidor que executa as operaes e mltiplos clientes que interactuam com ele. Em vez de um s servidor com a sua disponibilidade podemos ter mais. No caso concreto da replicao de servidores, as duas polticas de tolerncia a faltas e processamento do erro, traduzem-se respectivamente por: - Replicao 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 primrio falhou, torna-se o primrio. - Replicao Activa Todos os servidores recebem pela mesma ordem os pedidos dos clientes, efectuam a operao, determinam qual o resultado correcto por votao e respondem ao cliente. A replicao passiva implica uma menor redundncia e menos processamento, sendo a tcnica mais utilizada em sistemas comerciais. Nele verificam-se as seguintes propriedades: - Num dado instante apenas pode existir um servidor primrio - Num dado instante um cliente apenas conhece a identidade de um servidor - Um servidor que no primrio quando recebe mensagens de um cliente, ignora-as Os 2 problemas maiores so: - Detectar a paragem do servidor primrio - Garantir a coerncia do estado dos servidores Vamos assumir que os processos servidores so de falha rpida, ou seja, toma a iniciativa de pararem quando detectam alguma situao anormal. Os protocolos baseiam-se na ausncia de mensagens para detectar a falha de paragem do servidor principal. O servidor primrio envia periodicamente mensagens de prova de vida (Im alive). necessrio estar seguro de que se distingue a paragem do servidor de um simples atraso na resposta, o que coloca o problema do sistema ser sncrono, ou seja, que existam limites conhecidos para o tempo mximo de trx. de mensagens. A coerncia de estados entre os servidores complexo, porque obriga a que o secundrio receba todas as mensagens pela ordem correcta e efectue as actualizaes correspondentes. O primrio tem, portanto, de enviar para o secundrio as mensagens que recebe dos clientes, podendo justapor (piggyback) as mensagens de prova de vida. crucial que o sistema de comunicao garanta que a ordem de recepo das mensagens no secundrio a mesma, para que no 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 alm das faltas por paragem dos servidores habitual considerar as faltas na comunicao. Nestas h ainda que distinguir as temporrias das permanentes. frequente considerar 3 aspectos na avaliao dos protocolos de rplica passiva: o grau de replicao depende do modelo de faltas considerado (tipo e nmero de faltas); o tempo de latncia mximo de resposta ao cliente depende do incremento de tempo introduzido pelo protocolo entre o primrio e o secundrio; o tempo de indisponibilidade do sistema em que o servidor secundrio no detectou a falha no primrio. Um exemplo de utilizao desta arquitectura o servidor HA-NFS que pretende implementar um servidor de NFS com capacidade de tolerar falhas de paragem e comunicao. 7.4. Transaces Atmicas Mais complexo considerar situaes em que mltiplos servidores mantm estados diferentes e se pretende que um cliente tenha acesso e modifique a informao em vrios deles, garantindo que a operao decorre de forma consistente, mesmo na presena de faltas.

Na tecnologia actual dos sistemas distribudos, as tcnicas de recuperao 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 aplicaes que manipulam estruturas de dados persistentes (normalmente bases de dados) tm possibilidade de recuperar de estados errados, garantindo que simultaneamente sincronizam as suas aces de forma consistente com outras transaces que utilizam os mesmos dados. Ex. mover dinheiro da conta A para B. O procedimento deveria ser atmico, garantindo que todas as operaes se executam ou que, na presena de faltas, se considera nulo o efeito das operaes j executadas e se repe o estado inicial. O que se pretende a consistncia na base de dados. Obviamente durante a execuo das operaes, os estados parciais so inconsistentes, mas se no forem utilizados por outras operaes concorrentes no violada a consistncia global do sistema. esta garantia de isolamento entre as transaces importante, pois na maioria dos sistemas as estruturas de dados so partilhadas com outras aplicaes. 7.4.2. Propriedades Para definir formalmente as transaces, considera-se um conjunto de propriedades (ACID): - Atomicidade (Atomic) Para um observador externo, uma transaco ou se executa na totalidade ou no se executa. Sempre que existam faltas, possvel recuperar o sistema para o estado inicial da transaco. O desfazer das operaes (rollback) implica manter o estado parcial da transaco numa forma que facilite a sua confirmao ou anulao; - Consistncia (Consistent) Cada transaco deve, a partir de um estado inicial vlido e caso se execute completamente, atingir um novo estado vlido; - Seriabilidade (Isolation) Se diversas transaces se executarem em paralelo sobre os mesmos objectos, tudo se passa como se as transaces se executassem em srie numa determinada ordem. - Persistncia (Durability) Os resultados de uma transaco que confirmou permanecem depois de esta acabar e so supostos sobreviver ao conjunto de faltas expectveis dos mecanismos de armazenamento. Tipos de Transaces Apesar de todos os sistemas transaccionais terem o objectivo comum de manter a informao persistente e consistente mesmo quando h operaes concorrentes e falhas no sistema, os sistemas no so todos idnticos. Classificao: - Localizao - Durao - Estrutura a localizao procura caracterizar se os dados sobre os quais a transaco se realiza esto todos no mesmo local fsico ou repartidos por vrios sistemas.. As distribudas podem ser consideradas como um complemento do sistema de RPC permitindo uma arquitectura em que mltiplos clientes e servidores interactuam de forma fivel. A durao reflecte a diferena entre as transaces destinadas a actualizaes interactivas (online) da base de dados e aquelas que iro ser executadas sobre grandes volumes de informao, normalmente de forma no interactiva (off-line) (durao longa). A estrutura caracteriza a possibilidade de uma transaco apenas poder corresponder a um nico fio de execuo ou existirem mltiplos fluxos de execuo no interior de uma transaco. Na primeira flat, na segunda nested. 7.4.3. Tipologia das Faltas - Aborto explcito da transaco - Falta de paragem do sistema - Falta nos sistemas de armazenamento persistente - Falta na comunicao

O aborto da transaco a falta mais simples de tratar, dado que no necessita de deteco, porque explicitamente desencadeada pelo programa (no falta mas tratamento de excepes). uma forma de resolver interblocagens. Na falta por paragem do sistema assume-se que, devido a faltas com mltiplas origens (energia, hardware, SO, etc.) houve paragem do sistema e, consequentemente perdeu-se a memria voltil. A existncia de uma falta nos discos (media failure) das que acontecem mais e necessrio redundncia da informao. As faltas de comunicao podem ter diversas origens mas normalmente so temporrias e podem recuperar-se repetindo as mensagens. Uma situao mais complexa ocorre se existirem faltas permanentes que conduzem a uma partio da rede fsica. Poder-se- continuara tentar oferecer o servio se houver uma replicao das bases de dados. importante ter a noo que no se considera o aparecimento simultneo de 2 faltas. 7.4.4. Modelo de Sincronizao A necessidade de sincronizao das operaes de leitura e escrita deriva da propriedade de isolamento (atomicidade). No posso ler saldo antes de acabar transferncia. Quando um conjunto de transaces se executa concorrentemente, as suas operaes de leitura/escrita vo ser intercaladas pelo escalonamento normal dos SO multiprogramados. A sincronizao do acesso a variveis partilhadas o problema clssico de sincronizao dos leitores/escritores. Leitura Escrita Leitura Compatvel Conflito Escrita Conflito Conflito A propriedade do isolamento implica que a execuo das transaces seja serializvel. O objectivo garantir que as histrias so serializveis, mas que a sincronizao s impede a progresso de uma transaco se for estritamente necessrio, ou seja, quando existe um conflito nas operaes histria equivalente a sequencial. A forma mais simples de garantir a serializao sincronizar o acesso a uma varivel partilhada com base em trincos de excluso mtua, mas restritivo pois leituras no conflituam. Ento usam-se os trincos com o algoritmo dos escritores/leitores. Antes de utilizar qualquer objecto, a transaco requisita um trinco de leitura ou escrita consoante o acesso que pretende efectuar. Mltiplos acessos em leitura so permitidos, mas um acesso em escrita bloquear todos os acessos subsequentes. se uma transaco detiver um trinco de leitura sobre um dado registo, no ser permitida a outra obter um trinco de escrita. A transaco que o pretenda fazer ficar bloqueada at que todos os trincos de leitura sejam libertados. Um dos aspectos de base na programao concorrente garantir que as variveis partilhadas so protegidas por mecanismos de sincronizao (excluso mtua) que assegurem que a sua actualizao consistente -> 2 coelhos... Sincronizao em 2 fases A transaco numa primeira fase comea 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 formulao determinar o ponto em que mais nenhum trinco ser necessrio. O mais habitual a sincronizao em 2 fases estrita (strict two-phase locking), quando a fase de libertao dos trincos ocorre apenas quando a transaco termina. Isto pode obrigar uma transaco a esperar por transaces demoradas apenas porque se iniciaram antes. Para aumentar o paralelismo, h sistemas que permitem libertar alguns dos trincos antes de terminar a transaco. soluo complexa e pode originar abortos em cascata se algumas das transaces posteriores tiverem usado os resultados da inicial que vai abortar. A viso optimista considera que os conflitos so raros e que, portanto, as transaces se podem executar mais rapidamente sem sincronizao e no fim confirmar-se e abortar a transaco se for caso disso. No se usa nos comerciais e so maus em carga alta. Interblocagem H sistemas que pretendem evitar e outros recuperar. Nas tcnicas para evitar h um conjunto conhecido por preveno -> regras: estabelecer uma ordem para as operaes de sincronizao sobre trincos. conceptualmente simples mas difcil

quando se usam linguagens de alto nvel, manter a relao entre as estruturas de dados e os trincos, de forma a garantir uma ordem de utilizao. Outra obrigar a efectuar requisio de todos os trincos no incio da transaco e s a deixar prosseguir se os tiver obtido. Caso contrrio liberta todos os trincos e bloqueia-se. fortemente limitativa da concorrncia e s vezes nem possvel saber de incio todos os trincos que vou precisar. Na recuperao, a forma mais simples de deteco de interblocagem usar um temporizador que, quando expira, assinala que a transao est possivelmente bloqueada numa condio de interblocagem. simples mas pouco precisa, mas boa pois a interblocagem rara. A forma mais simples de recuperao abortar a transaco. H mais sofisticados por grafo. 7.4.5. Subtransaces Encaixadas (Nested) ... 7.5. Arquitectura dos Sistemas Transaccionais 7.5.1. Sistema Transaccional numa Arquitectura Centralizada necessria uma mquina virtual que garanta as propriedades das transaces (Sistema Transaccional). O sistema transaccional interactua com as aplicaes, quer localmente, quer atravs de chamadas remotas de procedimento, disponibilizando s aplicaes dois grupos de operaes: controlo da transaco (iniciar, confirmar, abortar) e as que modificam ou lem os dados (escrever, ler). Internamente o sistema transaccional composto por diversas funes que asseguram as propriedades j descritas. As unidades funcionais so: - Gestor de Escalonamento (responsvel pela sincronizao de todos os acessos aos dados manipulados pelas transaces) - Gestor da Cache (Gere a relao entre os discos e a memria voltil) - Gestor do Dirio ( O dirio log- uma lista onde fica toda a informao que permite recuperar de falta, isto , a reposio de um estado correcto) - Gestor da Recuperao (Tem a funo de recuperar o sistema para um estado consistente sempre que uma falta for detectada) - Gestor da Memria Estvel (deve garantir a persistncia dos dados)

CAP.8 SISTEMAS DE FICHEIROS DISTRIBUDOS 8.1. Introduo Um sistema de ficheiros distribudo (SFD) permite a um processo aceder a ficheiros situados noutras mquinas, de uma forma idntica que utiliza para o acesso a ficheiros locais. Complementar com o mecanismo cliente-servidor (CS). Em modelos de programao distribuda baseados em RPC, os dados so acedidos localmente e a computao que se desloca entre o cliente e o servidor (function shipping); num SDF, a computao sempre local e so os dados que se deslocam entre o servidor de ficheiros e a mquina local onde se executa a aplicao (data shipping). Perspectivas dos SDF, nas realizaes mais comuns: - Um mecanismo que se adiciona ao SO local para permitir o acesso remoto aos SF j existentes na mquina (NFS, LAN Manager, Windows for Workgroups). Normalmente, o SF local logicamente dividido em 2 partes, a privada e a partilhada. Cada mquina exporta o seu SF local. Limitaes: A gesto do espao de nomes no normalmente uniformizada. A gesto dos discos no melhorada Problemas em ambientes com grande mobilidade - Um SF separado que pode ser acedido atravs da rede por todas as mquinas (AFS). Aqui, o SF um servio, implementado por um ou mais servidores. Cada mquina utilizador passa a dispor da parte cliente do SF, que lhe permite aceder aos ficheiros guardados no servidor(es). Tm espao de nomes nico; a administrao bastante simplificada; mais simples gerir espao fsico do disco; mobilidade facilitada; Mais complexo que o anterior. 8.2. PROBLEMAS TCNICOS 8.2.1. Desempenho A expectativa dos utilizadores que o desempenho seja idntico ao do sistema local. O mecanismo de cache a tcnica fundamental para conseguir um bom desempenho. Mantm na mquina local uma cpia da informao que se espera venha a ser acedida num futuro prximo. 8.2.2. Espao de Nomes Problemas adicionais: - mbito do nome: global ou local, em relao ao cliente - Pureza do nome: o nome da mquina faz parte do espao de nomes (EN)? - Heterogeneidade: juntar no mesmo EN SF com regras diferentes de prod. de nomes A forma habitual de construir o espao de nomes com base em pontos de montagem (mounting points): permite estabelecer a associao entre dois SF distintos, ligando o nome de um ficheiro (normalmente um directrio) de um SF raiz do outro SF. Acessos subsequentes ao directrio, so redireccionados para o outro SF. O ponto de montagem passa a conter, para alm do identificador do SF, a identificao do servidor por ele responsvel. 8..3. Compatibilidade da Interface de Programao Tentou aproveitar-se o do centralizado, mas o SDF coloca novos problemas como necessidade de introduzir novas chamadas sistema ou a obrigao de impor uma semntica diferente para algumas das chamadas existentes. Ex. open() pode falhar porque servidor no est acessvel. Os fabricantes esforam-se e os SDF preservam as interfaces de programao dos sistemas onde se integram. 8.2.4. Integridade na presena de falhas No SDF h vrias fontes adicionais de incoerncias: - Faltas nas comunicaes (mensagens perdias ou duplicadas) - Faltas no servidor ou num cliente antes de este actualizar o disco com os dados da cache. As polticas de gesto da cache tm de prever estes problemas mesmo que custa de alguma perda de desempenho.

8.2.5. Controlo de concorrncia Para gerir o acesso concorrente ao mesmo ficheiro por vrios processos. Exige aqui um mecanismo de sincronizao distribudo, o que se pode tornar extremamente complexo e ineficaz. A maioria dos SFD oferece solues parcelares. 8.2.6. Segurana Existem 3 aspectos fundamentais: - Autenticao : problema fundamental. Normalmente usam-se mecanismos de chave simtrica (ex. Kerberos) para autenticar os clientes do SDF - Controlo de Acesso : mecanismos iguais aos SDF centralizados - Privacidade : normalmente deixado a cargo das aplicaes. 8.2.7. Localizao Quando h vrios servidores tem de haver um mecanismo de localizao (em que servidor) do ficheiro que se procura. Normalmente resolve-se agrupando os ficheiros em volumes, em que cada volume idntico a um SDF centralizado e os vrios volumes so interligados atravs de pontos de montagem. 8.2.8. Mapeamento nos dispositivos fsicos A gesto dos dispositivos fsicos passa a ser feita apenas no servidor, o que permite simplificar o processo de gesto dos discos fsicos. 8.2.9. Disponibilidade A concentrao num s servidor levanta o problema de todos os ficheiros poderem ficar inacessveis. A disperso pode ser a soluo mas pode ainda conduzir a maiores problemas se os vrios ficheiros necessrios a uma dada aplicao estiverem dispersos. Para aumentar a disponibilidade usa-se a recuperao de falhas no servidor (cliente interpreta como servio lento) e a replicao (normalmente de volumes, mas s para leitura). 8.3. Caractersticas dos Acessos a Ficheiros 8.4. Arquitectura dos SDF Tm normalmente uma arquitectura cliente-servidor. A comunicao utiliza um mecanismo RPC. O servidor armazena os ficheiros no seu disco local e exporta a interface RPC, na qual h uma correspondncia quase directa entre as chamadas sistema e as rotinas exportadas pelo servidor. 8.4.1. Arquitectura do cliente Tem quase obrigatoriamente de fazer parte do SO. As mesmas chamadas sistema funcionam tanto para o sistema centralizado como para o distribudo. Por esse motivo, tem de ser o cdigo de cada chamada sistema a verificar se o ficheiro a que esta se destina local ou remoto. Se for local, chama a componente do SDF centralizado. Se for remoto, ento ter de chamar a rotina de adaptao (stub) para efectuar o RPC para o servidor. A deciso sobre o ponto de agulhagem entre o SDL e o SDF pode ser feita em vrios pontos: - Logo no incio deste processo, por exemplo, nas rotinas de interface ou nas funes 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 possvel uniformizar as vrias chamadas sistema e obter o melhor desempenho possvel. Newcastle Connection tentou a primeira mas tem 2 problemas: - desempenho inaceitvel (porque cliente no tem hiptese de usar cache local) - incapacidade de lidar com SO heterogneos (semntica de cada chamada tem de ser exactamente igual no cliente e no servidor) A segunda limitada, porque se o servidor no trabalha ao nvel do ficheiro, mas do bloco, perde a possibilidade de garantir a coerente utilizao do ficheiro (na cache) pois servidor 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 nvel onde feita a agulhagem (ex.NFS) 8.4.2. Arquitectura do Servidor Executa-se normalmente dentro do espao de endereamento do ncleo, o que lhe permite utilizar uma interface optimizada para aceder aos ficheiros. O servidor normalmente composto por vrias tarefas concorrentes. Desta forma, podem estar vrios pedidos a ser servidos simultaneamente. As componentes cliente e servidor (inclusive de SO diferentes) podem coexistir na mesma mquina. 8.5. SOLUES TCNICAS 8.5.1. Nomes e Localizao A organizao do espao de nomes fundamental. Determina em larga medida a viso que os utilizadores tm do sistema e a capacidade que os administradores tm para o gerir de forma eficiente. construdo ligando vrios sistemas de ficheiros centralizados atravs de pontos de montagem (comando mount). Desta forma indica-se no s a indicao do SFC, mas tambm a identificao do servidor onde est esse SF. O ponto de montagem uma estrutura, normalmente voltil (desaparece quando se reinicializa o SO) que fica associada ao directrio onde efectuada a montagem. Quando um directrio que tem associado um ponto de montagem acedido, o sistema verifica que no se trata de um directrio vulgar e, em vez de aceder ao directrio do disco local, reencaminha o pedido para o servidor referenciado no ponto de montagem. ex: $ mount dir serv sf Este mecanismo est intimamente associado localizao dos ficheiros. Um ficheiro localizado quando se resolve o seu nome. A resoluo 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 directrio raiz do sistema de ficheiros montado. Alguns sistemas usam um formato fhandle impuro que contm a localizao do ficheiro, outros usam um servidor de nomes intermdio. A resoluo do nome pode ser iterativa. Uma optimizao 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 noo de volume permitem um nvel de flexibilidade adicional. No ponto de montagem indicado no o par servidor-SF mas apenas o identificador do volume. A traduo entre o identificador de volume e endereo do servidor pode ser feita por uma tabela replicada em todos os servidores. As alteraes da tabela so propagadas pelo administrador. 8.5.2. Cache a tcnica fundamental para um bom desempenho (e escalabilidade) em SFD. Situa-se nos clientes e memoriza (numa memria rpida) os ltimos blocos a que a mquina cliente acedeu. Arquitecturas de cache Tanto o cliente como o servidor continuam a aceder sua memria secundria atravs da cache j existente no sistema de ficheiros centralizado (ex. NFS). Poupa-se tempo na busca da informao e na sobrecarga da linha e do servidor. A cache dos sistemas centralizados implementa j 2 mecanismos fundamentais da optimizao do desempenho: a leitura em avano (read-ahead) e a escrita retardada (write-back). A efectividade da cache comprovada pela anlise das caractersticas 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 organizaes tm 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 rpido do que ler no disco local).

A cache dos clientes pode ser em memria central ou em disco, o que permite ficheiros para dias ou semanas. Coerncia da cache A coisa pode comear a complicar-se quando as operaes no so s de leitura (mais frequente), como implcito anteriormente, mas tambm de escrita e que dois ou mais clientes acedem simultaneamente ao mesmo ficheiro. O principal problema a resolver numa cache a sua coerncia, isto , os valores que podem ser retornados pelas operaes de leitura. Informalmente, um sistema de cache est coerente se a informao lida por um cliente for a que foi escrita mais recentemente, por esse ou por outro cliente. Como nos sistemas distribudos as escritas no se podem propagar imediatamente, considera-se que as escritas de um cliente tm de poder ser lidas por outro desde que estejam suficientemente separadas no tempo e que as escritas no mesmo bloco por vrios clientes tm de ser vistas pela mesma ordem por todos os clientes. Nos SDF a responsabilidade de manter a coerncia pode ser atribuda 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 vlida utiliza-a, se no, pede ao servidor a mais recente. Uma optimizao comum o servidor, no caso de invlida, responder logo com a info vlida, outra o cliente assumir que est vlida dentro de um perodo de tempo (ex. 5 seg.). Se a responsabilidade for do servidor, o cliente utiliza sempre a info da sua cache. Se for invlida 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 invlida e solicitam cpia ao servidor. Esta ltima semntica mais precisa mas obriga o servidor a trabalho extra (manter estado com informao sobre todos os clientes e ficheiros em utilizao). Propagao das alteraes 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 alteraes 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 alteraes para o servidor. prtico pois raramente h a partilha do mesmo ficheiro por vrios utilizadores (ex. AFS o fecho tem a semntica de o servidor invalida primeiro as caches de outros clientes e atomicamente actualiza o ficheiro para conter a nova verso). NFS usa esquema mais simples enviando actualizaes ao servidor mas no garantindo que fica logo em disco. Sistemas que procuram replicar o SFC (Sprite) tm 2 modos. Igual ao AFS e sem cache para quando o mesmo ficheiro est aberto por dois clientes, um para escrever outro para ler. Alteraes metainformao dos ficheiros (raro) so normalmente propagadas de imediato ao servidor, minimizando as incoerncias que poderiam ocorrer se o servidor for abaixo. Protocolo de comunicao Info de controlo o protocolo baseia-se num RPC sobre um protocolo de transporte do tipo datagrama. Dados: As organizaes de cache baseadas em blocos em memria (NFS) trocam sempre blocos do ficheiro, podem usar tambm protocolo de transporte baseado em datagrama. A aproximao de transferir grandes segmentos ou ficheiros completos (AFS) permitem utilizar protocolos optimizados para utilizao da largura de banda quando se transferem grandes quantidades de dados. A contrapartida trx. mais do que o necessrio. Resumo da Cache - Informao 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 coerncia da cache: cliente ou servidor - Propagao das alteraes: quando ficheiro fechado, outras alturas. A metainformao de imediato

- Protocolo de comunicao: baseado em RPC, usa datagramas para info de controlo e datagramas ou protocolos com ligao 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 organizao da cache. Cache em memria 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 so locais. Como as caches so maiores (cabem vrios working-sets) considerando uma semana. Como a maioria dos ficheiros so acedidos para leitura, o servidor no pura e simplesmente contactado. S quando fecho os ficheiros que seguem para o servidor os modificados. acresce que a maioria dos ficheiros so privados do utilizador, poucas alteraes 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. Organizao do espao dos nomes: Organizaes uniformes do espao de nomes, de forma a este ser visto de forma idntica por todos os utilizadores, so mais escalveis, porque permitem diminuir a complexidade global do espao de nomes e porque limitam a construo de pontos de montagem aos servidores, sendo ento independentes do n de clientes. Um outro ponto importante o espao de nomes conter mecanismos para a definio de domnios e sua interligao atravs de outros protocolos de nomes. O AFS usa o conceito de clula (normalmente uma empresa), idntico ao do servio de nomes do DCE. a clula autosuficiente em todos os aspectos e podem ser interligadas atravs de outros sistemas de nomes como o X.500 ou o DNS construindo um SFD escala mundial. 3. Administrao do sistema. 8.5.4. Segurana 1. Autenticao: Normalmente, agora so baseados em chave privada. Cada mensagem contm um autenticador cifrado com uma chave de sesso, anteriormente negociada com o servidor de autenticao. Os dados so 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 2 aspectos: Comunicao com o servidor os dados so apenas cifrados para serem trx. na rede, com a mesma chave de sesso, mas evita-se por causa do desempenho. Em alternativa podem ser cifrados no cliente com base numa chave fornecidas pelo utilizador e enviados para o servidor j cifrados (vantagem de ser independente do SFD e os dados so guardados cifrados no disco) mecanismo implementado a nvel de aplicao (ex. PEM). 8.5.5. Disponibilidade e Tolerncia a Faltas conseguida distribuindo cpias por vrios servidores. A replicao pode ser feita a nvel do SO (cap.7) ou do SFD. Neste caso o SDF controla onde esto as rplicas e encaminha os pedidos (no ponto de montagem). cada cliente normalmente configurado com um servidor preferencial. A unidade de replicao normalmente o volume ou a partio lgica e deciso do administrador de sistema quais e onde. A maioria s suporta replicao de volumes para leitura. O AFS diferencia volumes comuns dos s para leitura. 8.5.6. Heterogeneidade Vrios tipos: 1. Mquinas de arquitecturas diferentes (e SO diferentes) partilhem o mesmo SDF; 2. Utilizador numa mquina possa aceder, de forma uniforme, a SDF diferentes situados em mquinas distintas. Na primeira o SDF tem de suportar dados em diferentes representaes, mas as aplicaes que os convertem.

8.5.7. Administrao Embora as opes de arquitectura se dividam entre distribuir os ficheiros pelas vrias mquina ou concentr-los num servidor, unnime que a administrao deve ser centralizada e integrada. Por ex. o NFS possui utilitrios (ex. ONC) que permitem manter base de dados centralizada com toda a informao relevante do ponto de vista da administrao, como os ficheiros de configurao, de definio de utilizadores, etc. Nos sistemas de arquitectura centralizada, como o AFS, a gesto concentra-se no servidor. Os clientes s tm o endereo dos servidores de autenticao e de ficheiros. A administrao fica assim simplificada, mas mais complexa para administradores. Os 4 aspectos importantes na administrao de um SFD, so: 1. Gesto de Utilizadores; 2. Gesto do Espao de Nomes 3. Gesto do Espao de Disco 4. Salvaguarda Peridica dos Ficheiros (backups) A primeira centra-se no ficheiro de configurao que define o nome de utilizador, palavra chave, uid, gid (ficheiro /etc/passwd no Unix). Em sistemas de arquitectura distribuda, como o NFS esse ficheiro mantido num ponto centralizado e difundido pelas mquinas clientes quando for modificado. Nos centralizados (AFS) a identificao dos utilizadores feita por acesso remoto ao servidor de autenticao usando um modelo semelhante ao Kerberos. A segunda refere-se aos pontos de montagem. mais simples no AFS, pois estes esto todos no servidor. No NFS tambm pode ser mantido de forma centralizada e difundido, para que cliente tenham viso global. A 3 complexa e por vezes a nica soluo acrescentar discos onde falta o espao. Quando os ficheiros esto centralizados no servidor mais fcil a gesto. O AFS tem a noo de volume que corresponde a partio lgica, sendo que a zona de cada utilizador corresponde a um volume. Os volumes so as unidades de composio do espao de nomes e podem ser mapeados em qualquer partio fsica do disco. Desta forma pode-se transferir volumes para discos que tenham espao, de forma transparente e at e, copy-on-write. A 4 pode-se fazer de qualquer mquina pois os ficheiros esto acessveis em todo o lado. 8.6. NETWORK FILE SYSTEM (NFS)