PREFCIO Sistematizao e sntese dos problemas de base provocados pela distribuio, os modelos necessrios ao enquadramento do problema bem como

as solues da engenharia de computadores. Enquadramento geral do problema com exemplos de sistemas que se encontram em uso. Quais so os novos desafios aos sistemas operativos? Do livro anterior vm 2: a distribuio e arquitecturas multiprocessador. Estas mexem apenas com o ncleo, tcnicas portanto. a distribuio introduz um conjunto de problemas de grande complexidade, derivada dos fenmenos de escala, da complexidade do modelo de faltas e da vulnerabilidade da segurana; o que tem implicaes directas na programao das aplicaes, pelo que o modelo tem de ser perceptvel ao programador. Organizao do Texto ... 1. INTRODUO Os desafios continuam a ser essencialmente os mesmos que estiveram na sua gnese dos sistemas multiprogramados: . Simplificar a interface com o sistema . Extrair o mximo rendimento da infra-estrutura de hardware Depois dos 20 anos de consolidao, que terminaram nos anos 70, h um aperfeioamento e incluso das ideias base dessa investigao. Por ex. o Windows NT usa muitas das ideias do VMS. O papel charneira do SO entre o hardware, as redes de dados e as aplicaes, implicou que o sistema passasse progressivamente a englobar um nmero crescente de funcionalidades relacionadas com a distribuio, a gesto da informao e a interface homem-mquina. Da o uso de Software de Sistema: ncleo + servidores, bibliotecas e protocolos. 1.1. Condicionantes da Evoluo H uma technology push e tb. as imposies dos utilizadores. 1.1.1. A Tecnolgica Evolues tecnolgicas mais marcantes: . As redes de computadores . Os computadores pessoais . Os sistemas abertos . As arquitecturas multiprocessador Redes de Computadores Os pioneiros foram os bancos e transportadoras areas com a sua necessidade de sistemas transaccionais e interactivos. Os operadores pblicos na Europa introduziram servios de trx. de dados (ex. X-25) que permitem s empresas a utilizao de redes pblicas para transferncia de informao. Redes abertas universitrias (Arpa, Cyclades). Internet, como exemplo paradigmtico de sistema distribudo, com todos os seus problemas de escala e segurana. RDIS (2x64Kbits). ATM que comea a ser usada nas redes pblicas. LANs (Ethernet, Token-Ring), com dezenas de Mbps. Computadores Pessoais Tecnologia Circuitos Lgicos Memrias Discos Evoluo da Densidade (de 3 Evoluo do Desempenho em 3 anos) (tempo de ciclo) Duplica 50% em 2 anos Quadruplica 33% em 10 anos Duplica 33% em 10 anos

A evoluo, em termos de hardware, com maior impacto em toda a estrutura da indstria foi a introduo no mercado dos computadores pessoais. A existncia dos PCs acelerou, de forma considervel, a percepo da necessidade dos sistemas distribudos. Os gestores de empresas passaram a considerar a hiptese de descentralizarem o seu suporte informtico, colocando mquinas de menor porte junto dos grupos que as utilizavam directamente. Os utilizadores fazendo aplicaes necessitaram de utilizar bases de dados centrais. Ao principio (com o DOS) era s partilha de servidores de ficheiros e de impressoras. O desenvolvimento culminou com um novo paradigam no desenvolvimento das aplicaes informticas, o modelo cliente-servidor. Sistemas Abertos Fabricantes de hardware desenvolviam o SO optimizado. Impossvel mudar de fornecedor. A presso dos grandes utilizadores levou a criao de sistemas abertos: separao clara entre o hardware e o SO e entre este e as aplicaes. Apareceram as plataformas. O Unix foi o que mais se aproximou de um sistema aberto e, hoje em dia, o Windows NT tem a tornar-se padro de facto. Arquitecturas Multiprocessador Na dcada de 70 e 80 eram especializados, hoje so correntes. As limitaes fsicas e custos de desenvolvimento que permitiram ir melhorando os acessos s volumosas bases de dados e interfaces complexos em computadores, esto a ser substitudos pelas arquitecturas multiprocessador que aumentam o desempenho mantendo os ambientes de desenvolvimento de software. Existem mltiplos esquemas para classificar os multiprocessadores com base na forma como organizam os fluxos de dados e de instrues. Neste livro usaremos s as arquitecturas MIMD (Multiple Instruction, Multiple Data), que corresponde aos casos em que cada processador executa as suas instrues e trabalha sobre os seus dados. As MIMD podem ser de dosi tipos: Memria Central Partilhada (+ vulgares e mais interessantes se pensarmos que se pensa em incluir, na mesma pastilha, vrios processadores) e as de Memria Distribuda. 1.1.2. Requisitos dos Utilizadores Finais Ser isolados dos detalhes complexos introduzidos pelos novos ambientes computacionais: Procura de transparncia: nomes, comandos e semnticas idnticas para todos os objectos sob controlo do SO (invocar aplicaes, aceder a ficheiros, utilizar perifricos, etc.). Isso requer sistemas de nomes homogneos, interfaces simples, viso integrada dos vrios sistemas de ficheiros, etc. A vantagem mais visvel ao utilizador com a distribuio a partilha de informao. Uma aplicao local pode aceder a informao remota. Uma outra vertente comunicao entre utilizadores humanos. Outra a ergonomia das interfaces. Isto quanto funcionalidade. Quanto qualidade temos a segurana, a fiabilidade e a disponibilidade. Requisitos do Programador Um requisito, relacionado com os sistemas abertos, a simplificao da portabilidade de aplicaes atravs da definio de interfaces normalizadas ou API (Application Programming Interface) com o software de sistema. Estas interfaces tm a ver no s com as funes de ncleo do SO, como com os mecanismos de comunicao, partilha de ficheiros, segurana, etc. O programador tambm pretende um ambiente de programao que lhe facilite o desenvolvimento das aplicaes, tornado o cdigo independente da arquitectura das mquinas, da rede, dos protocolos, dos SO locais e mesmo do nmero de mquinas e utilizadores. Requisitos do Gestor A capacidade de evoluo modular e a extensibilidade. O aumento da fiabilidade e disponibilidade. Finalmente, importante a capacidade de gesto global do sistema que permita a reutilizao de equipamentos, a gesto integrada dos arquivos de informao, diminuio das tarifas.

1.2. Dificuldades e Vantagens Introduzidas pela Distribuio 1.2.1. Os Problemas Comunicao Exclusivamente por Mensagem Nos sistemas multiprogramados, no ncleo toda a comunicao se efectua atravs de um espao de endereamento partilhado. Nos distribudos no h memria comum, introduz caractersticas diferentes no modelo de comunicao. A taxa de erros, se bem que venha diminuindo, sempre maior que a interna a uma mquina.

Captulo 2 ... Nvel de Subrede A camada inferior do modelo Internet especfica a cada tecnologia fsica de transmisso, que define o encapsulamento do nvel superior. Na Internet apenas se define o protocolo entre camadas correspondentes, ou sej, o formato das mensagens, o seu significado e as aces associadas, no existindo uma interface de servio para cada camada. Logo, cada tecnologia de subrede tem de definir a interface disponibilizada para o nvel de interligao de rede. Embora no garanta opacidade entre nveis, tem a vantagem de as normas de encapsulamento tirarem partido das caractersticas especficas da tecnologia de subrede para implementao eficiente. Existem especificaes de encapsulamento de pacotes do nvel IP para todas as tecnologias (analgicas, ATM, etc.) Nvel de Interligao de Redes Disponibiliza s camadas superiores um servio de encaminhamento dos pacotes atravs da rede (conjunto de subredes independentes). O servio oferecido pelo nvel IP no d qualquer garantia de fiabilidade (melhor esforo possvel). No necessrio este nvel na comunicao entre 2 ns da mesma subrede mas uniformiza se utilizado. Nvel de Transporte Na famlia Internet definem-se 2 protocolos nesta camada (a mais parecida com OSI): O TCP (Transmission Control Protocol) servio semelhante ao de um canal de trx. fivel, com ligao que garante a retransmisso de pacotes corrompidos, a eliminao de pacotes duplicados e entrega dos pacotes pela mesma ordem; define o esquema de endereamento utilizando o conceito de porto para identificar o utilizador final do servio de transporte; e o UDP (Unit Datagram Protocol) no fivel, como o IP, em cujos servios se baseia, adicionando checksum e endereamento dos portos de acesso ao servio de transporte UDP. A distino entre as mensagens do protocolo UDP e do TCP efectuada pelo tipo de pacote IP. Pertencem pois a espaos de endereamento distintos. Nvel de Aplicao Utilizam os servios de transporte para fornecer funcionalidades adicionais. So transparentes rede. ex: SMTP, TELNET, FTP, DNS. A cada um dos servios/aplicaes atribudo um porto especfico de transporte (well known ports). 2.5. Redes Locais de Computadores Foram um dos factores decisivos na evoluo das arquitecturas centralizadas para distribudas. Caractersticas da normalizao: com partilha efectiva do meio fsico; apenas os dois primeiros nveis do modelo OSI; de 1 a 20Km. Transmisso de difuso; em anel ou bus. 2.5.1. Controlo de Acesso ao Meio de Comunicao Um dos primeiros problemas que se colocou na definio da norma 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 locais. Para eficincia no podia haver independncia entre nvel fsico e lgico. Ento criou-se 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 redes de banda larga. Desvantagens ao nvel de gesto e complexidade do equipamento, onde o estabelecimento de canais varia continuamente. Multiplexagem no Tempo

 a alternativa mais usada. O problema fundamental a resolver a forma como controlada a partilha entre os vrios emissores. Multiplexagem no Tempo Sncrona O tempo dividido em intervalos de durao fixa, sncronos com relgio central. Cada emissor dispe de um intervalo de tempo fixo para colocar a informao no meio (ex. trx. de voz digital: PCM trama bsica de 32 blocos de 8 bits) adapta-se bem a fluxos contnuos de informao como voz ou vdeo. Nos ambientes computacionais habituais, as trx. no tm padro assim regular. Multiplexagem no Tempo: Assncrona preciso algoritmo de atribuio de tempos: - Aleatrio; - Passagem de testemunho; - Controlo centralizado O aleatrio baseia-se na reduzida probabilidade de dois emissores comearem, no memso instante, a trx. A estao que pretende emitir f-lo- assim que detectar que o meio est livre. As outras aguardam. O problema surge com as colises. a base da Ethernet. Na segunda h um testemunho lgico (token) que circula entre as vrias estaes de um anel lgico. Apenas a estao na posse do testemunho pode emitir. As vantagens que a rede pode ser mais facilmente modelizvel e, portanto, os dbitos podem ser assegurados atravs de gesto de prioridades adequada. As desvantagens alguma complexidade para garantir o bom funcionamento do testemunho na inicializao e em caso de falhas. Introduz atrasos no acesso quando a estao tem de esperar pelo testemunho. Suporta melhor o funcionamento em carga elevada que a Ethernet. O controle centralizado numa estao que se encarrega de inquirir (polling) s restantes se pretendem emitir. mais simples mas depende muito da estao que controla quanto fiabilidade e desempenho. Desenvolvimento levou a distribuio vertical ou dorsal (backbone fibra ptica) atravs de pontes ou encaminhadores. FDDI representativa das redes de alto dbito. 2.5.2. Rede Ethernet Remonta a 1974. a mais usada. IEEE 802.3. Nvel Fsico A topologia de base bus e velocidade de trx. original de 10Mbps. O suporte fsico inicial era o cabo coaxial e mximo segmento de 500 m extensvel a 1,5 km com repetidores. A evoluo alargou para par entranado e fibra ptica. Estruturou-se a cablagem, com a utilizao de cabos mais baratos UTP (Unshielded Twisted Pair) e STP (Shielded Twisted Pair). Existem especificaes normalizadas para a qualidade dos cabos, suportando a amsi elevada (classe 5) at 100Mbps. usual distinguir os diversos tipos de tecnologia Ethernet com recurso a mnemnica B/Modo/D, com B- largura de banda; Modo distingue a utilizao em banda de base ou em modulao de frequncia (Base ou Broad); D indica distncia mxima. Ex: 10BaseT 10Mbps, banda de base, 100 metros de comprimento mximo da ligao, par entranado. A topologia em bus tem sido mantida do ponto de vista conceptual, mas a definio de siatemas de cablagem estruturada conduziu a solues baseadas em concentradores (hub) que agregam vrias ligaes Ethernet s mquinas (bus funciona conceptualmente dentro do concentrador). Mtodo de Controlo de Acesso ao Meio por diviso no tempo assncrono com controlo aleatrio, CSMA/CD (Carrier Sense Multiple Acess/Collision Detection). Normalmente as funes de comunicao so implementadas por hardware no comunicador ethernet. O funcionamento deste controlador pode resumir-se:

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 trx., 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 (carier sense) e lana automaticamente a tx. quando detecta o canal livre. Pode haver coliso. Para a detectar, a estao emissora escuta simultaneamente o bus para verificar se o sinal emitido no foi adulterado (collision detection). Se detecta coliso, pra de emitir e refora a coliso. Depois retira-se do canal e volta a tentar mais tarde. Para evitar situaes ambguas, os pacotes tm um tamanho mnimo tal que o seu tempo de trx. o dobro do tempo de propagao. Antes de retransmitir aguarda um nmero inteiro de slot-time, num algoritmo Truncated Binary Exponential Backoff. Formato das Tramas - Prembulo de 64 bits (101010101...1011) para sincronizao dos relgios e delimitao fsica da trama; - Endereos de 6 octetos para destino e origem; - Campo tipo, na norma Ethernet, identifica o campo de dados face aos protocolos de nvel superior, tendo na norma 802.3, o significado do tamanho de campo de dados; - O comprimento mximo dos dados de 1500 bytes; - O CRC tem 32 bits e abrange todo o pacote, excepto o prembulo. 2.5.3. FDDI Fiber Distributed Data Interface Concebida para ser usada como espinha dorsal (backbone) de grandes centros computacionais ou para interligao de redes locais. A vel. de trx. 100Mbps. A verso inicial foi revista para suportar trfego iscrono, MANs, e fibras monomodo. Universidades usam muito. Nvel Fsico O meio de trx. a fibra ptica. A norma prev anel duplo (A e B), permitindo a continuao da operao em caso de quebra de interligao entre dois ns. A distncia entre estaes pode ir at 2km e a rede pode ir at um permetro de 200Km e at 1000 estaes. Mtodo de Controlo de Acesso ao Meio O controlo de acesso ao meio feito atravs de um protocolo de testemunho temporizado, semelhante ao 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. e no quando a mensagem volta. Os endereos so de 48 bits. Oferece extenso para trfego iscrono para trx, de voz e vdeo. 2.6. Interligao de Redes Nas redes de grande escala, o nvel rede caracteriza o servio oferecido. Existem 2 filosofias para a realizao deste nvel: Circuito virtual (preferida dos Operadores de Telecomunicaes) ou sem ligao. Na primeira o protocolo de transporte negoceia a qualidade de servio pretendida. A rede responsvel por criao de mecanismos que assegurem a entrega fivel dos pacotes, ordem de entrega e controlo de fluxo. Na segunda, defendida pela comunidade Internet, todo o controle deve ser feito pelas entidades dialogantes, face diversidade de subredes. A expresso prtica desta diferena o X.25 e o IP. 2.6.1. Equipamento de Interligao

Se a ligao for meramente ao nvel fsico repetidores (utilizados por ex. para ligar 2 segmentos duma rede Ethernet, idnticas portanto). A ponte (bridge) opera ao nvel lgico o que pressupe redes com nvel lgico idntico. A ponte copia tramas duma rede para outra. Como as tramas tm endereo, pode fazer-se filtragem. So usadas na hierarquizao (razes: trfego excessivo, grandes distncias, gesto em depts., etc.) de redes locais (interligao de LANs) complexo se redes diferentes. 2 tipos: ponte transparente (com memria interna, onde ir progressivamente guardar os enderos das redes que liga); pontes com encaminhamento na origem Finalmente, a interligao no sentido mais abrangente efectua-se no nvel rede. o encaminhador (router) (gateway, ou porta, genrico, sendo tb. software que compatibiliza protocolos de qualquer nvel) 2.6.2. Rede X.25 Implementao de um servio pblico para comunicao entre mquinas geograficamente distantes. As mquinas dos utilizadores interligam-se rede atravs de uma ligao ponto-a-ponto ao comutador da rede. Nvel Fsico Consiste na ligao ponto-a-ponto utilizando linhas analgicas ou digitais. Nvel Lgico Usa o protocolo LAPB (Link Acess Procedure), que implementa controlo de fluxo, recuperao de erros e garante que o comutador recebeu correctamente o pacote. As tramas so de 3 tipos: informao, superviso e no numeradas. Nvel Rede Podemos esquematizar o funcionamento da rede X.25 do seguinte modo: quando um DTE pretende comunicar com outro, tem de estabelecer um circuito virtual. Corresponde ao envio de um pacote de call request. O destinatrio, se quiser, responde com call accepted. Para ter minar a ligao qualquer um pode enviar um clear request que deve ser confirmado. Para satisfazer a necessidade de um servio datagrama foi introduzido um mecanismo de fast select em que o pacote de call request pode incluir 128 octetos de dados. O receptor pode recusar a ligao com um clear request que tambm foi expandido para ter 128 octetos de dados, o que evita pois a ligao. O endereamento semelhante ao do servio telefnico com cdigo por pas, rede e n e o endereo pode ter at 14 dgitos decimais. O X.25 ilustra o problema da redundncia funcional j referido no OSI. O nvel de rede e o de ligao de dados implementam ambos o controlo de fluxo. As limitaes de desempenho permitem prever a sua substituio pelo Frame Relay, que d um servio mnimo que no oferece mecanismos de recuperao de dados e de controlo de fluxo. Posiciona-se melhor para uma tecnologia de interligao de LANs (pacotes at 1600 octetos), sobre linhas com altas velocidades e sobrecarga de protocolo muito menor. 2.6.3. Rede IP A filosofia completamente diferente da X.25, pressunpondo-se 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 oferecido sem ligao; - O servio na base do melhor esforo ; - O endereo de um n subdivide-se em duas 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; - A deciso de encaminhamento feita com base no identificador da subrede de destino, com excepo dos ns da mesma rede em que pelo endereo do n.

Endereos IP cosntitudo de forma hierrquica por um par: <identificador Rede netid; identificador Mquina hostid> O nmero de bits associado a cada elemento no fixo, existindo 3 classes: A, B e C. Qualquer organizao com um endereo IP pode subdividi-la (pelos bits menos significativos) para formar subredes internas. Um endero IP pode identificar uma mquina (netid=0) ou uma rede (hostid=0). Os endereos de difuso tm todos os bits de hostid=1. Um endereo no representa uma mquina, mas um ponto de ligao de uma mquina a uma rede. Classe A: 0 7-rede 24-host Classe B: 10 14-rede 16 host Classe C: 110 21-rede 8-host Os problemas deste tipo de endereos so os comuns a hierarquizao: - Se a mquina muda de rede, torna-se necessrio mudar o seu endereo bem como tabelas onde ele se encontra - No caaso da mquina ter vrios endereos, os protocolos utilizam a especificao de rede contida no endereo, mesmo que outros caminhos fossem mais eficientes. Endereos IP actuais tm 32 bits. No possvel tipo telefnico, devido grande diversidade de redes tamanhos dos endereos locais dificuldade no sistema de atribuio vs. desempenho. Para simplificar legibilidade so representados por 4 dgitos separados por pontos, cada dgito representando um octeto. ex: 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) IPv6 vai ter 128 bits. Protocolo IP O protocolo de nvel rede simples. Implementa o encaminhamento atravs de tabelas fixas e um controlo de congesto com libertao de pacotes. A unidade de transferncia o pacote ou datagrama, formado por cabealho, bloco de dados, cuja dimenso total est limitada a 64Kbytes. Se redes impuserem pacotes mais pequenos o protocolo fragmenta. Cabealho: ta,anho total do datagrama (16 bits-->64Kbytes), identificao do pacote, deslocamento do fragmento. Os fragmentos so desdobrados em mltiplos de 8 octetos --> 13 bits --> 8192 fragmentos; TTL (time to live); header checksum. Ver pacote IP na pgina 85. Na mesma subrede o encaminhamento directo (traduz o endereo IP para o endereo da subrede fsica). Se for indirecto preciso envi-lo ao n que actua como encaminhador. A mquina emissora tem de conhecer os endereos das portas de encaminhamento, que tm tabelas.

CAPTULO 3 Interface de Comunicao 3.1. Modelo da Comunicao Distribuda O modelo computacional tem de oferecer ao programador de aplicaes uma viso coerente dos objectos de comunicao e das funes que lhes esto associadas. A comunicao num ambiente distribudo uma evoluo de comunicao entre processos numa nica mquina. Corresponde tambm troca de mensagens entre 2 processos. O modelo computacional constitudo por objectos de comunicao ou portos e por funes agrupadas numa biblioteca. a interface API (Application Programming Interface) da comunicao. No h transparncia entre a interface e os protocolos subjacentes (s idealmente). As caractersticas da interface so quase as do servio de transporte. Os protocolos de comunicao so geralmente integrados no ncleo. A comunicao pode modelizar-se por um processo emissor, outro receptor e o canal (abstraco dos mecanismos de transporte que permitem a comunicao. As extremidades do canal so os portos. Conceptualmente o canal pode ser considerado como a associao de dois portos. Para que exista comunicao, esta associao tem de se estabelecer, podendo ter uma forma duradoura, no canal com ligao, ou apenas para uma interaco, no canal sem ligao. A informao transmitida designada por mensagem, devendo ser interpretada por um protocolo de alto nvel. Quando a qualidade de servio oferecida pelo canal no pode ser mantida, o sistema deve avisar o processo atravs do mecanismo de excepes, que no caso dos sistemas distribudos assume um papel mais importante devido a haver mais falhas. As interfaces utilizadas numa aplicao distribuda podem, portanto, ser diferentes consoante o SO. A garantia da capacidade de comunicao dada pelo protocolo de transporte que implementa o canal. 3.2. Caracterizao da Interface 3.2.1. Canal com ou sem ligao No caso de uma nica mquina, o canal implementado por zonas de memria partilhada, logo elevada fiabilidade. Tal no se passa nos distribudos, sendo essa uma diferena fundamental. O desempenho tb. menor. A fiabilidade e desempenho devem ser explcitos para o programador (qualidades de servio vrias, cada qual melhor adaptvel aplicao). A forma mais vulgar de traduzir o tipo de servio : - Canal com ligao: fivel, bidireccional e c/ garantia de sequencialidade; - Sem ligao ou Datagrama: No oferece garantias de fiabilidade. O primeiro prefervel quando existe fluxo contnuo de informao, mas consome recursos de forma permanente e ter tempo de latncia significativo no estabelecimento do canal. O segundo adapta-se melhor comunicao com muitos interlocutores, a mensagens de pequena dimenso (tpicas dos sistemas client-servidor) 3.2.2. Portos de Comunicao Para transferir informao os processos interactuam com um porto que representa a extremidade do canal, que so uma abstraco para o SO, como os sockets, caixas de correio. Tm um sistema de designao e conjuntos de funes. So interface entre o SO e o protocolo de transporte. O identificador associado ao protocolode trnsporte pode ser explcito na interface (ex. sockets) ou encapsulado (ex. Mach). Quando um porto criado pode logo ser estabelecida a associao entre o identificador local e o endereo de comunicao ou num momento posterior (ex. sockets por bind). No caso em que os programadores tm de conhecer os endereos de transporte, como os portos TCP/IP nos sockets, existem mecanismos para designar os portos por nome inteligveis servio de nomes.

Do elenco de operaes associadas aos portos temos as funes de envio e recepo das mensagens, criar e eliminar um porto, associar um endereo de transporte e definir parametrizao do canal. No caso do canal sem ligao, o porto receptor comporta-se como uma caixa de correio qual so enviadas mensagens e que, normalmente, tem capacidade para armazenar um determinado n de octetos. O canal estabelecido para cada mensagem. H direitos. Na mensagem deve ser enviado o endereo do porto emissor para que o receptor possa estabelecer o canal de resposta. 3.2.3. Semntica da Funo de Envio No tocante sincronizao, a operao de envio de mensagens, pode ter vrias semnticas que se relacionam com a deteco de faltas na comunicao: - Assncrona: A funo copia a informao da mensagem para os tampes do protocolo de transporte e retorna depois de iniciar a operao de 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 destinatrio confirme que recebeu a mensagem - Cliente/Servidor: o processo emissor fica bloqueado at receber a mensagem de resposta. A assncrona de aparente maior desempenho, mas a possibilidade de muitas processos paralelos levanta grandes problemas a nvel de sincronizao (protocolos prprios) e as aplicaes tm de ser programadas com muito mais cuidado (por eventos, ao contrrio do que se est habituado), que levam no muita utilizao. Ser eficiente no caso de trfego desequilibrado (FTP, Telnet). Na pergunta-resposta no tem vantagens. O sncrono oferece garantia que a informao foi correctamente trx. mas no permite detectar qualquer falha na execuo do servio. Tb. de programao complexa, para evitar interblocagens. CSP. A cliente-servidor procura garantir a execuo da operao, assegurando-se que o processo s continua a sua execuo quando recebe resposta. Esta interface semanticamente bastante mais rica, pelo que tem sido usada como base de programao do modelo cliente/servidor. Mas implica conjunto de operaes que no existem no protocolo de transporte. 3.2.4. Estrutura das Mensagens Pode ser individualizada ou serem apenas sequncias de octetos de tamanho varivel (byte stream) que emula as interfaces dos ficheiros de texto ou das E/S para terminal. Se for byte stream o nvel aplicao tem de traduzir significado. Quando individualizadas existe relao directa com as estruturas de dados dos programas. Normalmente o sistema de suporte comunicao no impe formatao especfica s mensagens. Uma possvel razo para a impor seria a heterogeneidade. 3.2.5. Semntica de Recepo retirar a primeira mensagem existente no porto ou, caso nenhuma esteja presente, bloquear o processo. Se houver vrias ligaes especficas coloca-se o clssico problema dos mltiplos pontos de sincronizao. Relaciona-se com: se for sem ligao pode usar-se um porto para receber as mensagens de todos os processos interlocutores, mas assim no possvel estabelecer prioridades. Por esta razo frequente os servidores criarem vrios portos para mensagens, de tipo ou de interlocutores de classes diferentes. No canal com ligao, o porto fica associado ao canal. A soluo de ambos os problemas criar um mecanismo de recepo mltipla sobre um conjunto de portos. O processo bloqueia-se at que um dos portos receba uma mensagem que lhe destinada. 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 (cominicao bidireccional remota). A primitiva select dos sockets um exemplo de uma funo de recepo mltipla com temporizao associada. A funo de recepo tambm pode ser assncrona (teste da existncia de mensagens no porto. caso no existam retorna ao processo).

3.2.6. Paralelismo A sincronizao das primitivas de envio e recepo de dados est fortemente relacionado com o modelo de concorrncia em termos de processos e tarefas. A necessidade de paralelismo colocase fortemente na programao de processo que actuam como servidores -> atender simultaneamente vrios clientes. Uma forma de introduzir paralelismo no servidor utilizar vrios processos em paralelo. Esta soluo obriga, porm, partilha de estruturas de dados (memria e sincronizao), que sempre de programao delicada, porque reintroduz o problema dos mltiplos pontos de sincronizao. O modelo computacional mais adequado um modelo multitarefa com vrios fios de execuo concorrentes que se sincronizam no acesso a variveis partilhadas. Tem vrias 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 a um pedido, por exemplo para aceder ao disco; tira partido dos eventuais vrios processadores existentes. Progressivamente os SO tm vindo a fornecer suporte para mecanismos multitarefa integrados na gesto dos processos. 3.2.7. Faltas na Comunicao Podem ter numerosas origens, sendo as mais frequentes relacionadas com a quebra do canal de comunicao. tal pode acontecer porque a rede fsica falhou ou os protocolos esgotaam os tampes. O Mach usa tratamento de excepes. 3.2.8. Difuso de Mensagens Nas locais h mecanismos eficientes e intrnsecos. Nas grandes no pois a indiscriminao pode originar muitas mensagens suplementares na rede. Devido ao interesse dos algoritmos baseados na difuso, foram propostos mecanismos de difuso mais restritos a grupos de portos. Os grupos tm nomes que os identificam e podem ser criados dinamicamente. Existe opcionalmente no IPv4 e generaliza-se no IPv6. H que distinguir tambm: Os protocolos com entrega fivel a todos so designados por difuso atmica. Tm despertado grande interesse em polticas de tolerncia a faltas dado que so o suporte indicado para polticas de replicao (mais complexos ISIS). Os outros no garantem a entrega a todos (melhor esforo) IP, Chorus. 3.2.9. Alternativas de Implementao Genericamente temos 3 formas de integrao das funes de comunicao no modelo computacional de um SO multiprogramado: - Funes E/S genricas - Funes especficas dedicadas apenas interface com os protocolos de transporte - Incluso no mecanismo de intercomunicao entre processos do SO. A primeira tornou a comunicao num gestor de perifricos, com todos os problemas de normalizao que da advinham. A normalizao veio via Unix que adoptou a interface do sistema de ficheiros. Mas esta soluo tem severa limitao, devido s operaes disponveis nas interfaces de E/S serem insuficientes face s necessidades dos protocolos de comunicao. enviar e receber tudo bem, mas estabelecimento de ligao, parametrizao ou recepo mltipla... A soluo funo de parametrizao genrica, ex. ioctl do Unix para tudo, mas isso torna a programao pouco clara e introduz facilmente erros. A alternativa a utilizao de biblioteca dedicada, que esconde detalhes das E/S e dos protocolos de transporte (ex. NetBios e DOS), mas obriga a distinguir entre comunicao remota e local, o que diminui portabilidade. Os sockets Unix so uma tentativa da compatibilizao das funes de comunicao com as E/S, mas tambm acaba por ser hbrida. Uma evoluo tenta estender o IPC local, de forma coerente. A desvantagem desta aproximao que cada SO impe uma estruturao prpria das mensagens e se pretende ligar mquinas com SO diferentes. Verifica-se o habitual compromisso entre eficincia e coerncia. Nos sistemas resultantes da evoluo de SO centralizados manteve-se a distino entre mecanismos IP locais e as interfaces de comunicao distribuda. Ex. Unix V.4 tem IPC e TLI.

Nos SO estruturados com base em micro-ncleos como, p.ex. o Mach e o Amoeba procurou-se evitar esta duplicidade, mas, hlas, so incompatveis. Vamos ilustrar estes conceitos com 3 interfaces: os sockets so seguramente a inteface mais divulgada e tendem a ser norma de 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, onde a comunicao local e remota foram consideradas como idnticas. 3.3. Interfaces de Sockets 3.3.1. Caracterizao dos Sockets Unix, desde incio teve mecanismos para suporte da distribuio. A de Berkely (1982) inovou com os sockets como interface de comunicao. No Unix V foi para a API TLI (Transport Layer Interface). Os sockets propunham-se dar resposta a: - Independncia do Protocolo (de transporte); - Transparncia: a comunicao no deve depender da localizao dos processos, devendo ser idntica para o caso local ou distribudo. - Compatibilidade: O novo mecanismo devia inserir-se na interface clssica de comunicao e E/S do Unix. Os sockets apresentam interface baseada nos descritores de ficheiros (evoluo dos pipes). A independncia materializou-se na noo de domnio. Expls. de domnios: - Domnio Internet TCP e UDP - Domnio Unix Permite a comunicao entre processos numa nica mquina, sendo semelhante aos pipes sem nome. - Domnio Xerox NS Na criao do socket, para alm da especificao do domnio especificado o tipo de servio pretendido: - stream canal com ligap, bidireccional, fivel e com garantia de ordem. A interface do tipo sequncia de octetos tal como nos pipes ou ficheiros. - datagram canal sem ligao, bidireccional, sem... - sequenced packet canal sem ligao, mas com envio sncrono que garante entrega das mensagens. - raw acesso directo aos mecanismos de comunicao. Ex. ao IP. Nem todas as combinaes de tipo e domnio tm sentido (ver tabela na pg. 108) Os identificadores de transporte associados aos sockets so diferentes para cada domnio (com esquema de endereamento prprio). A estrutura genrica do identificador do socket definido em <sys/socket.h> : struct sockaddr { u_short family; /*definio do domnio*/ char sa_data[14]; /* endereo definido no domnio*/ No domnio Unix, os nomes so caminhos de acesso com a estrutura habitual (ex. /tmp/servidor) struct sockaddr_un { u_short family; /*definio do domnio*/ char sun_path[108]; /*caminho de acesso*/ No domnio Internet o identificador corresponde ao endereo de transporte dos protocolos UDP e TCP, descrito no captulo anterior. Endereo IP da mquina (32 bits) e o nmero de um porto de transporte codificado com 2 octetos.

1.5 Resumo Os SO sofreram uma evoluo natural, resultante do grande desenvolvimento tecnolgico das duas ltimas dcadas. Apesar de se poderem considerara mltiplos factores para esta evoluo, salientamos quatro que nos parecem mais decisivos: 1 As redes de computadores tiveram uma evoluo significativa. Nas redes de grande escala (WAN), a evoluo resultou da oferta pelos operadores de telecomunicaes de redes de dados com elevada fiabilidade e custos mais reduzidos que as linhas dedicadas. Esta evoluo ir a curto prazo materializar-se nas redes integradas de voz e dados, RDIS na banda estreita e, futuramente, ATM na banda larga. Nas redes pblicas particularmente importante o papel das redes com uma filosofia aberta de gesto como a Internet. Esta rede adquiriu recentemente uma notoriedade que a coloca como o meio mais adequado para a introduo de reais aplicaes distribudas. Uma outra vertente da evoluo da tecnologia das comunicaes foi a das redes locais LAN. Esta forma de interconexo de computadores iniciou-se na dcada de 80 e evoluiu rapidamente, em particular na reduo de custos das interfaces que permitem hoje em dia que seja margina o custo de interligao dos computadores em rede local. 2 Os computadores pessoais foram os equipamentos com maior impacto nos sistemas informticos. Estes equipamentos de reduzido custo revolucionaram a experincia do uso da informtica pelos utilizadores. A capacidade de processamento e armazenamento local, aliada a uma interface cada vez mais ergonmica, obrigou a repensar os sistemas de informao centralizados das dcadas anteriores. Apesar de o SO MS-DOS ser muito rudimentar, dificultando a sua interligao coerente em rede, o enorme mercado motivou o desenvolvimento de diversas solues de partilha de ficheiros e impressoras que progressivamente tem vindo a aproximar-se das arquitecturas existentes nas redes com equipamentos mais potentes com sistemas Unix. 3 Os sistemas abertos apareceram devido presso dos grandes utilizadores que pretenderam no ficar totalmente dependentes dos seus fornecedores de hardware que ofereciam SO proprietrios, aos quais ficavam indissociavelmente ligadas as aplicaes. O movimento no sentido dos sistemas abertos procurou criar o conceito de plataformas de hardware, plataformas de SO e plataformas de SGBD, com interfaces bem definidos que permitem o transporte fcil das aplicaes e criaram um mercado competitivo. Uma das reas mais influenciadas pela filosofia dos sistemas abertos foi a comunicao entre computadores, pois os problemas colocados pela interligao de sistemas heterogneos obrigaram a solues multivendedor. As redes actuais de maior sucesso, quer pblicas quer locais, baseiam-se em normas adoptadas por toda a indstria. 4 As arquitecturas multiprocessador so um meio natural para aumentar o desempenho dos processadores e justificam-se para as mquinas que actuam como grandes servidores de informao. As arquitecturas dominantes so os multiprocessadores simtricos de memria partilhada. Os multiprocessadores de memria distribuda interligam, sobre uma rede local ou um sistema de interconexo de alto dbito, mquinas independentes. A sua influncia na evoluo dos sistemas operativos distribudos tem sido grande. Os sistemas distribudos resultam da confluncia destes factores tecnolgicos e procuram dar resposta a um conjunto de requisitos colocados pelos utilizadores, pelos programadores e pelos gestores de sistemas informticos. Os utilizadores pretendem: transparncia que lhes evite terem de conhecer diferentes interfaces para os objectos dos sistemas; mecanismos eficientes para partilha de informao; suporte para a comunicao entre utilizadores humanos como o correio electrnico, as news, etc. Todas estas funcionalidades devem ser acompanhadas de uma maior qualidade do sistema, em particular de uma acrescida ergonomia, segurana, fiabilidade e disponibilidade. Para os programadores, os requisitos so:

A necessidade de interfaces normalizadas (API) que permitam o desenvolvimento e transporte das aplicaes; ambientes de programao que escondam os detalhes da distribuio, dos mecanismos da tolerncia a faltas e de segurana, simplificando o desenvolvimento das aplicaes. Na ptica do gestor de recursos informticos, os requisitos principais relacionam-se com a capacidade de evoluo do sistema. Os sistemas distribudos facilitam uma evoluo modular e garantem a extensibilidade do sistema. Um requisito importante a capacidade de gesto global do sistema, no obrigando a numeroso pessoal de suporte. Com natural, a distribuio introduz um conjunto de problemas ou agudiza outros: comunicao por mensagem a fiabilidade e o determinismo da comunicao por mensagem totalmente diferente da habitual nos sistemas centralizados onde se efectua com base numa memria partilhada; modelo de faltas o modelo de faltas mais complexo, porque existem mais componentes e o padro de faltas mais complexo pela total independncia dos sistemas; sistema operativo repartido a distribuio implica a cooperao entre vrios ncleos de SO, no existindo uma memria central para comunicao e sincronizao. Numa rede difcil criar mecanismos de sincronizao atmicos, devido s caractersticas temporais dos meios de comunicao e pelas hipteses de falha. A informao de gesto (nomes de utilizadores, ficheiros, perifricos) encontra-se dispersa por numerosas mquinas, sendo necessrio ao sistema executar protocolos entre mltiplos ns para efectuar determinadas operaes; segurana nos sistemas multiprogramados, o ncleo dos sistema era considerado como seguro, numa rede as mensagens podem ser escutadas ou modificadas e, no limite, nada impede um utilizador de modificar um SO, pelo que se tem de partir do princpio de suspeio mtua em relao a todos os interlocutores nas redes; heterogeneidade as diferenas entre processadores obrigam a tratar de forma transparente os diversos tipos de dados suportados pelos processadores; desempenho para ultrapassar os problemas anteriores, utilizam-se protocolos e servidores de sistema, mas estes tm impacto sobre o desempenho. O desafio construir sistemas distribudos que ultrapassem os problemas sem sacrificar o desempenho. Com natural, os problemas mencionados anteriormente tm soluo e a distribuio tem interessantes vantagens potenciais. Algumas so evidentes como adequao repartio geogrfica, modularidade, extensibilidade. Outras so mais complexas de perceber como: maior disponibilidade devido existncia de mltiplas mquinas independentes permitindo replicar a informao ou as aplicaes; melhor desempenho devido utilizao das mquinas mais adequadas a cada tipo de processamento; custo mais reduzido decorrente da utilizao de computadores pessoais como interface para os servidores. Existem mltiplas formas de conceber os mecanismos de suporte construo de aplicaes distribudas. A forma mais simples apenas oferecer os mecanismos bsicos de intercomunicao entre processos. O programador tem neste caso de desenvolver as aplicaes cliente e servidor e os protocolos de aplicao. Apesar desta soluo ser fcil de implementar nas mquinas existentes, tem diversas desvantagens: limitada reutilizao de cdigo e protocolos; dificuldade de normalizao; desempenho limitado devido implementao fora do ncleo. Existem, contudo, algumas vantagens neste mecanismo: simplicidade os programadores apenas tm de conhecer interfaces de comunicao que no so muito diferentes das existentes nos sistemas centralizados; facilidade de transporte para outras arquitecturas - como os mecanismos utilizados no recorrem praticamente ao SO, o transporte das aplicaes simples.

Um nvel mais elaborado de suporte oferecido pelas plataformas cliente/servidor. No existe uma definio clara e consensual de qual a funcionalidade destas plataformas, apesar de serem vulgarmente considerados os seguintes servios: comunicao entre clientes e servidores por chamada de procedimento remoto; gesto de nomes; mecanismos de segurana para autenticao e cifra das comunicaes; suporte a transaces distribudas; sistema de ficheiros distribudo. A componente de base destas plataformas a comunicao utilizando o paradigma de chamada remota de procedimento. Este mecanismo procura simplificar a interaco remota, assemelhandoa sintctica e semanticamente chamada de procedimento. Os SO distribudos baseiam-se na interligao de todas as componentes do sistema: gesto de memria, gesto de processos, etc. O sistema funciona de um modo homogneo, permitindo explorar as vrias componentes hardware da rede como se de uma s mquina se tratasse. Representa o objectivo mais ambicioso dos SO distribudos. Para que todos os sistemas possam ser interligados desta forma, necessrio que ofeream interfaces idnticas, o que obriga a que diversos fabricantes tornem os modelos dos seus sistemas compatveis. Para alm do suporte distribuio, uma caracterstica que tem marcado o desenvolvimento dos novos SO a tentativa de modularizao da sua estrutura interna. Uma tendncia geral a estruturao interna dos sistemas em micro-ncleo, assegurando as funes de gesto de processos e de comunicao, e em servidores que executam as restantes funes. A prpria comunicao entre o SO e o ncleo efectua-se por mensagem, permitindo a sua fcil adaptao distribuio ou s arquitecturas multiprocessador. As arquitecturas multiprocessador tiveram uma influncia grande na evoluo tcnica dos SO. Podemos dividir esta arquitectura em 2 grandes grupos: os de memria partilhada e os de memria distribuda. Na arquitectura de memria partilhada, os processadores esto ligados mesma memria atravs de um bus partilhado. Os processadores tm uma cache local onde guardam as palavras de memria recentemente acedidas. A coerncia das caches mantida pelo hardware de gesto de bus partilhado. Estas mquinas obrigaram paralelizao do SO, ou seja, a reduzir a um gro muito fino as seces crticas existentes no cdigo do sistema. Como evidente, esta operao complexa, sobretudo quando efectuada em sistemas existentes como o Unix, onde, devido ao pseudoparalelismo, o ncleo tinha extensas seces crticas. Uma outra linha de evoluo criar mecanismos a nvel de utilizador para explorar o paralelismo real dos multiprocessadores. Certos algoritmos podem ser optimizados se executados em paralelo por vrias tarefas dentro do mesmo processo, em que todas as tarefas partilham o mesmo espao de endereamento. as tarefas (threads) passam a ser entidades geridas pelo SO que efectua o respectivo escalonamento, tirando partido dos diversos processadores. Os multiprocessadores de memria distribuda so compostos por processadores com memria privada e interligados por uma rede de alto dbito. Nestas mquinas, o SO um sistema distribudo, onde todas as componentes habituais (processos, ficheiros) podem ser geridos de forma distribuda. A comunicao por mensagem semelhante existente nas redes de dados, mas claramente optimizada para tirar partido da rede de interligao de alto dbito subjacente arquitectura. Normalmente, os fabricantes destes sistemas procuram oferecer uma interface semelhante a sistemas multiprogramdos clssicos, com o Unix, escondendo os detalhes da arquitectura.

CAP. 2 As redes de dados tm caractersticas estruturais que as tornam muito mais complexas do que as E/S, nomeadamente: escala o nmero de unidades interligadas muito superior a qualquer sistema de perifricos; heterogeneidade as redes interligam mquinas com processadores e Sos diferentes e so elas prprias heterogneas devido a diferentes meios fsicos, tcnicas de transmisso e multiplexagem, tcnicas de gesto, etc. Mltiplas razes justificam a enorme diversidade de arquitecturas das redes: o interesse dos fabricantes de desenvolverem redes que prolongassem as suas arquitecturas proprietrias; as limitaes tecnolgicas associadas banda de transmisso e atenuao em funo da distncia; o custo das diferentes tecnologias; os requisitos das aplicaes que diferem quando se considera dados impulsionais, voz, imagens ou vdeo. Devido aos elevados investimentos efectuados nas linhas telefnicas em cobre, os operadores procuram reutiliz-las para redes de dados. A elevada atenuao e limitaes da banda passante dos cabos em cobre introduziram limitaes arquitectura das redes. Para pequenas redes, a utilizao de meios fsicos mais eficazes e a possibilidade tcnica de efectuar a gesto de modo mais eficiente conduziram ao desenvolvimento de redes de elevado desempenho e custo reduzido. estas diferenas tecnolgicas e as diferenas de explorao das redes pblicas e redes privadas conduziram a uma segmentao das redes em : redes de grande escala (WAN), redes para reas metropolitanas (MAN) e redes locais (LAN). Dada a enorme complexidade das redes, houve, desde o incio, interesse em encontrar modelos que subdividissem a complexidade considerando diversos nveis. Uma subdiviso natural entre a arquitectura fsica e a arquitectura lgica. A primeira prende-se com as topologias de interligao e com as caractersticas fsicas dos meios de transmisso. A segunda procura criar uma rede com um conjunto de caractersticas susceptvel de suportar eficientemente as aplicaes. A arquitectura fsica relaciona-se com a topologia e as tecnologias de transmisso. As topologias habituais so: bus, anel, estrela, rvore e malhada. As primeiras usam-se nas redes locais, enquanto nas redes de grande escala a topologia malhada, garantindo na maioria dos casos redundncia na ligao entre ns. Historicamente, o cobre foi o meio fsico mais usado, mas progressivamente tem vindo a ser substitudo nas WAN por fibras pticas que proporcionam maior velocidade de transmisso, menor atenuao e maior fiabilidade. Nas LAN utilizam-se par entranado, cabos coaxiais e fibras pticas Para enquadrar a arquitectura lgica, foram criados vrios modelos de referncia. O mais divulgado o modelo OSI, da organizao internacional de normalizao, a ISO. Este modelo, do incio da dcada de 80, reflecte a tecnologia da poca e tem diversas limitaes amplamente divulgadas, contudo, continua a ser a referncia utilizada quer na rea da Informtica, quer em Telecomunicaes. Um outro modelo importante o que adoptou a Internet, designado por modelo catnet. Neste modelo considera-se a rede como uma interligao de redes independentes. Diversos fabricantes tambm propuseram os seus modelos, a maioria dos quais sem interesse actual, com excepo da arquitectura SNA da IBM que influenciou significativamente o modelo OSI e tem ainda considervel impacto em alguns domnios como nos sistemas transaccionais. O modelo OSI estrutura-se em nveis aos quais est associada uma interface de servio, correspondente funcionalidade que disponibiliza aos nveis superiores e um protocolo que define o formato e o significado das mensagens. Em cada sistema existe um fluxo de comunicao na vertical atravs das interfaces de servio dos vrios nveis de comunicao. Entre sistemas, a comunicao efectuada atravs dos protocolos dos nveis correspondentes nos sistemas. Os protocolos podem ser com ligao ou sem ligao. Nos protocolos com ligao pretende-se emular um canal virtual ponto-a-ponto entre os interlocutores. A comunicao decorre em 3 fases: estabelecimento da ligao, conversao, corte da ligao. Nos protocolos sem ligao apenas existe a fase de conversao. Ambas as solues apresentam vantagens e inconvenientes. os protocolos com ligao podem aproveitar os estabelecimento da ligao para negociar parmetros

de servio, podem controlar erros e sincronizao, dando maiores garantias aos nveis superiores. Os protocolos sem ligao so mais simples e podem resultar em mecanismos mais eficientes de comunicao, por no terem necessidade de passar por uma fase prvia de estabelecimento. A interface de servio definida com base num conjunto de primitivas abstractas: Pedido, Indicao, Resposta, Confirmao. A distinguir entre o servio prestado e o protocolo implementado em cada nvel, pretendeu-se tornar a arquitectura flexvel e modular. No entanto, as implementaes reais raramente conseguem garantir um completo isolamento entre protocolo e interface de servio, em especial no que se refere aos aspectos de configurao local e de endereamento. O modelo OSI estrutura-se em 7 nveis. Os nveis inferiores esto mais prximos do meio fsico de comunicao e os superiores das aplicaes e utilizadores finais dos servios de comunicao. O nvel fsico tem por funo transmitir correctamente um bit sobe o meio fsico de interligao; o nvel de ligao de dados utiliza os servios do nvel fsico para o envio de tramas (frames) entre duas mquinas na mesma rede fsica; o nvel rede responsvel por suportar os mecanismos necessrios ao encaminhamento (routing) dos pacotes de dados entre quaisquer sistemas ligados rede, independentemente da rede fsica; o nvel de transporte oferece um servio de transmisso de mensagens entre dois sistemas extremo a extremo, normalmente com vrias classes de qualidade de servio. O servio de transporte caracteriza-se por um conjunto de facilidades: com ligao/sem ligao; garantia de entrega fivel da mensagem; fragmentao; controlo de fluxo; mecanismo de janela; garantia de ordem. A rede Internet tem por base um modelo de concatenao de redes denominado (con)cate(nation) net ou catenet. Esse modelo assume que existe um grande nmero de redes independentes, possivelmente utilizando tecnologias diferentes, interligadas entre si por portas (gateways). Um utilizador dever poder aceder de forma transparente a recursos em qualquer dessas redes. Para tal, os pacotes do utilizador passaro por uma srie de redes, em trnsito, at ao destino. O processo de encaminhamento transparente para o utilizador, bastando-lhe conhecer o endereo Internet do destino. A Internet parte de uma camada nuclear para toda a arquitectura: o nvel de interligao de redes (Internetworking Layer) que se encarrega de suportar grande parte da funcionalidade requerida pelo modelo. Esta camada baseia-se num nico protocolo, o Internet Protocol (IP) que define os aspectos mais relevantes para toda a arquitectura da Internet. As redes locais so a tecnologia mais importante na interligao de sistemas computacionais. Estas redes de custo muito reduzido so as principais responsveis pela evoluo das arquitecturas centralizadas para as distribudas. Devido enorme diversidade de tecnologias disponveis, era fundamental definirem-se normas que permitissem o desenvolvimento de circuitos integrados indispensveis para reduzir o custo das interfaces. O IEEE encarregou-se de efectuar a normalizao numa comisso designada 802, nome por que ficaram conhecidas as normas a especificadas. Na anlise dos mecanismos mais eficientes para implementao de redes locais, foi patente que a independncia entre o nvel fsico e a ligao de dados do modelo OSI no era possvel. Foi definido um subnvel designado por Mecanismo de Acesso ao Meio MAC (Medium Acess Control) que controla a partilha do meio e que, apesar de logicamente pertencer ao nvel de ligao de dados, no pode ser separado do nvel fsico para que foi definido. Existem vrias alternativas para efectuar a partilha do meio: Multiplexagem na Frequncia (FDM), define-se um espectro de frequncias e atribui-se a cada canal de comunicao uma frequncia prpria; Multiplexagem no Tempo (TDM), o meio fsico partilhado com base numa atribuio de intervalos de tempo a cada emissor de informao. Existem vrias formas de controlo da atribuio dos intervalos aos vrios emissores: Diviso no Tempo Sncrona intervalos de durao fixa, sncronos com um relgio central so atribudos aos emissores; Diviso Temporal Assncrona neste caso, podem-se considerar 3 polticas de gesto: Aleatria; Controlada de forma distribuda; Controlada de forma centralizada.

As redes locais mais conhecidas so as Ethernet caractersticas: bus, cabo coaxial, TDM com controlo aleatrio, velocidade de transmisso de 10 Mbits/s; o Token Ring caractersticas: anel, TDM, com controlo distribudo, 16 Mbits/s. Nas redes de alta velocidade, FDDI uma das redes mais utilizadas para espinha dorsal de hierarquias de redes locais caractersticas: duplo anel, fibra ptica, TDM com controlo distribudo, 100Mbits/s. O nvel rede caracteriza o servio oferecido nas redes de grande escala. Existem 2 filosofias de base na definio deste nvel: estabelecimento de um canal virtual entre os dois ns que pretendem comunicar antes de se iniciar a fase de transferncia de informao. O circuito virtual garante controlo de erros, fluxo e sequencialidade; comutao de pacotes que so encaminhados dinamicamente na rede at ao seu destino final, no procurando o nvel rede assegurar funcionalidade suplementar que, caso seja necessria, dever sempre ser efectuada a nvel do transporte. A expresso prtica desta diferena ilustrada pelos dois tipos de protocolos mais utilizados nas redes de grande escala: X.25 e a rede IP. A redundncia funcional da pilha de protocolos X.25 e a ptica da interligao de redes, em vez da interligao de mquinas, do uma maior versatilidade e eficincia ao modelo Internet, consubstanciado no protocolo IP que se apresenta hoje como proposta com maior potencial no domnio da interligao de redes.

CAP 3. Os protocolos so fundamentais para que a comunicao se possa efectuar de forma normalizada e eficiente entre mquinas heterogneas. Contudo, para que esta infra-estrutura de comunicao seja til, necessrio incorpor-la no modelo de programao, integrando as funes de comunicao no ambiente de desenvolvimento das aplicaes. A interface uma biblioteca de funes ou API (Application Programming Interface) que permite interactuar com um determinado nvel do modelo de comunicao, normalmente o transporte. As interfaces tratadas neste captulo permitem um grau de abstraco em relao aos protocolos de comunicao, mas so normalmente o equivalente funcional dos mecanismos existentes nos protocolos de transporte. A comunicao pode modelizar-se como interaco entre um processo produtor que gera a informao e um processo consumidor que ir trat-la. A informao transmitida genericamente designada por mensagem, devendo ser interpretada segundo um protocolo de alto nvel, acordado entre o produtor e o consumidor. A transferncia de informao suportada por um canal, uma abstraco dos mecanismos de transporte que suportam a comunicao fsica. O canal de comunicao tem duas extremidades designadas portos que so objectos do SO e constituem a interface do sistema com os programas aplicacionais. Na intercomunicao entre processos numa nica mquina, o canal implementado por zonas de memria partilhada, gerida pelo ncleo, oferecendo uma elevada fiabilidade, o que no se passa num ambiente distribudo. O desempenho tambm sensivelmente menor, sendo mais penalizado quanto menor for o dbito das redes subjacentes. O modelo de canal projecta-se directamente nos conceitos discutidos no captulo anterior para o nvel de transporte: com ligao estabelecimento prvio do canal entre os dois processos interlocutores antes da troca de informao; sem ligao o canal conceptualmente estabelecido apenas para o envio de uma mensagem. Os portos so objectos do sistema a que est associado um espao de nomes e um conjunto de funes. Os portos so normalmente referenciados por dois identificadores, um local ao sistema ou mesmo local ao processo e outro correspondente ao endereo de transporte que permite enderear o porto na rede de comunicao. Para alm das funes de envio e recepo, existem funes especficas para criar, eliminar e parametrizar os portos. A funcionalidade destas rotinas diferente, consoante o canal se estabelece de forma permanente ou temporria. Se existe ligao, os portos do emissor e receptor ficam implicitamente associados, assumindo-se como as extremidades do canal bidireccional atravs do qual se enviam e recebem dados. As mensagens podem ser individualizadas ou sequncias de octetos (byte stream). O formato das mensagens pode ser imposto pelo sistema ou pelo protocolo de alto nvel entre aplicaes. A imposio de formatos prdefinidos na interface de comunicao uma restrio suplementar ao programador, sendo de uma forma geral evitada. No envio de mensagens, preciso definir qual o tipo de servio oferecido pelo canal quando a mensagem lhe entregue. As semnticas habituais so: assncrona a funo copia informao da mensagem para os tampes do protocolo de transporte e retorna depois de iniciar a operao de 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 destinatrio confirme que recebeu a mensagem; cliente/servidor o processo fica bloqueado at receber a mensagem de resposta. A semntica da funo receber 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 tpico de mltiplos pontos de sicronizao. A existncia de mltiplos canais relaciona-se com o modelo com ou sem ligao. Se o canal for sem

ligao, pode usar-se um porto para receber as mensagens de todos os processos interlocutores. Num canal com ligao o porto fica associado ao canal, pelo que mltiplas ligaes obrigam a utilizar mltiplos portos. A soluo para este problema criar um mecanismo de recepo mltipla sobre um conjunto de portos. Na recepo mltipla, um processo bloqueia-se at que um dos portos receba uma mensagem que lhe destinada. frequente a possibilidade de associar primitiva de recepo uma temporizao. A sincronizao das primitivas de envio e recepo de dados est relacionada com o modelo de paralelismo em termos de processos e tarefas. A necessidade de paralelismo coloca-se com particular relevo na programao de processos que actua, como servidores. A recepo mltipla resolve o problema dos mltiplos pontos de sincronizao, mas se apenas existir um processo, ele s poder servir um pedido de cada vez, tendo os restantes clientes de esperar que os pedidos anteriores sejam executados. Uma forma de introduzir o paralelismo no servidor utilizar vrios processos em paralelo; esta soluo obriga, porm, partilha de estruturas de dados entre os processos (memria partilhada e sincronizao). A soluo mais interessante dispor de um modelo multitarefa no servidor que permita a execuo concorrentemente de mltiplos fios de execuo que se sincronizam no acesso a variveis partilhadas. As faltas de comunicao podem ter numerosas origens. As mais frequentes relacionam-se com a impossibilidade de entrega da mensagem, devido a quebra do canal de comunicao. A deteco da falta diferente, consoante se utiliza um canal com ou sem ligao. No primeiro caso, o protocolo de transporte responsvel por detectar se o canal de comunicao est activo, podendo, por exemplo, assinalar imediatamente a quebra do canal. No caso do canal sem ligao, os protocolos datagrama no implementam normalmente um mecanismo de recuperao das faltas de comunicao. Quando detectada uma falha, esta situao tem de ser transmitida ao processo. A forma mais simples atravs de um valor de retorno da execuo da funo que indique o estado da execuo. Esta forma de assinalar erros existe genericamente para indicar os erros de utilizao (ex: tentar ligar um porto j em ligao). Contudo, como as operaes de transmisso so, na maioria dos caso, assncronas, para assinalar uma falha necessrio recorrer a um mecanismo de excepes assncronas. Uma propriedade interessante de alguns sistemas de comunicao a possibilidade de enviar uma mensagem em difuso a mltiplos receptores. Do ponto de vista do programador a difuso pode conduzir simplificao de diversos algoritmos, por exemplo: localizao, sincronizao, replicao de dados, alertar simultaneamente vrios processos para um acontecimento do sistema, etc. Devido ao interesse dos algoritmos baseados na difuso, foram propostos mecanismos de difuso mais restritos a grupos de portos. No mecanismo de difuso em grupo existe uma distino importante entre os que garantem entrega fivel (difuso atmica) a todos ou a nenhum dos participantes no grupo e aqueles que apenas enviam a mensagem numa base do melhor esforo, mas que no asseguram que todo o grupo a recebeu. Considermos trs 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; extenso do mecanismo de intercomunicao entre processo (IPC) do SO. A limitao das operaes disponveis nas interfaces de E/S, face s necessidades dos protocolos de comunicao, a maior dificuldade na sua utilizao directa. As funes de E/S s se adaptam bem s operaes simples de enviar e receber. A alternativa a utilizao de uma biblioteca dedicada, uma soluo de implementao simples que permite oferecer uma interface coerente que esconde os detalhes das E/S e dos protocolos de transporte (ex: NetBios). Contudo, no genrica, obrigando a distinguir partida as interaces remotas e locais. A integrao das funes de comunicao no IPC permite eliminar as bibliotecas de interface especficas, tornando o modelo de programao totalmente coerente. Uma das desvantagens desta aproximao a estruturao imposta pela organizao interna de um dado SO que torna o

protocolo do IPC proprietrio. Actualmente, apenas utilizado em sistemas distribudos experimentais. Os sockets podem ser considerados como uma evoluo dos pipes, a que foram adicionados os mecanismos de gesto dos canais e de gesto de nomes que permitem a comunicao entre processos num ambiente distribudo. A noo de domnio permite garantir alguma independncia entre o modelo de comunicao das aplicaes e o nvel de transporte. Exemplos de domnios so: Internet; Unix; NS/Xerox. Na criao do socket, para alm da definio do domnio, especificado o seu tipo que tem a ver com a qualidade de servio pretendida. Essencialmente, define se o canal estabelecido de forma permanente ou temporria: stream; datagram; sequenced packet; raw. Os sockets so criados com a chamada socket que devolve um ndice para um descritor de ficheiro aberto. para o socket ser enderevel pelos restantes processos, necessrio associarlhe um nome global, utilizando a funo bind. Na utilizao tpica dos sockets com ligao, o servidor cria um socket e atribui-lhe um nome para que os clientes possam pedir o estabelecimento se uma ligao. Antes de aceitar ligaes, indica a sua disponibilidade para receber chamadas atravs da primitiva listen. A funo accept bloqueia o servidor at recepo de pedidos de ligao. esta primitiva tem uma semntica complexa: quando a ligao estabelecida, o sistema cria um novo socket que ficar associado ao novo canal de comunicao, deixando livre o socket inicial para continuar a receber pedidos de ligao. Do lado do cliente, a criao do socket semelhante. O pedido de estabelecimento de uma ligao efectuado pela funo connect. Na utilizao dos sockets sem ligao, a interface semelhante das caixas de correio habituais nos sistemas de intercomunicao entre processos. As funes sendto e recvfrom permitem enviar e receber mensagens. A funo select indica ao sistema que o processo pretende ficar bloqueado at que uma operao ou vrias operaes de recepo ou envio se tenham realizado. As operaes so identificadas pelo descritor de ficheiro a que esto associadas. Apesar de ter sido desenvolvida para os sockets, de utilizao geral para todas as funes de E/S. No texto efectua-se ainda uma comparao da interface de sockets, com a evoluo proposta na verso V do Unix, a interface TLI. Existem diversos mecanismos de comunicao para redes de PC, por exemplo: NetBios; Lan manager; Netware; PC/NFS; Winsocket. Apesar de terem entre eles diferenas significativas, todos procuram oferecer uma interface de programao para aplicaes distribudas, onde possvel reconhecer os elementos do modelo de comunicao que descrevemos. O NetBios interessante porque corresponde a uma interface de comunicao amplamente divulgada, tambm oferecida pelo Lan Manager e pelo Netware. O NetBios realmente uma interface de comunicao, ou seja, no h um protocolo nico, existindo diferentes implementaes para redes diferentes. Contudo, a interface idntica permitindo o transporte das aplicaes. Apesar de muito simples, existe no NetBios a maioria dos mecanismos que descrevemos neste captulo (canal com e sem ligao, difuso, recepo mltipla). O Mach insere-se na tendncia de estruturao dos SO em que se procura isolar o ncleo, com uma funcionalidade bsica, dos servios oferecidos pelo SO. O ncleo ou micro-ncleo apenas executa os aspectos bsicos: gesto de tarefas (despacho e escalonamento); intercomunicao entre tarefas (IPC); interface ao hardware da mquina. Os conceitos relevantes no sistema IPC so os portos e as mensagens. Um porto um objecto do ncleo que representa uma extremidade de um canal de comunicao. Os portos so equivalentes a uma caixa de correio residente no ncleo e que possui um tampo para o armazenamento de mensagens. os portos so protegidos por capacidades que definem quem tem o direito de receber e o direito de envio para o porto. 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. 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. As mensagens so estruturas tipificadas que descrevem para cada campo qual o tipo de dados que transmitido. A passagem de apontadores na mensagem permite a transferncia de blocos de memria por referncia. O SO encarrega-se de actualizar as tabelas de pginas dos processos, permitindo que a informao possa ser transferida sem ter de efectuar cpias do espao de endereamento da tarefa emissora para o ncleo e deste para a tarefa receptora. O envio e recepo de mensagens efectuado por uma funo nica, o mach_msg, que tem uma estrutura relativamente complexa tendo sete parmetros. A semntica de envio pode ser assncrona ou cliente-servidor. Para permitir a recepo mltipla, existe o conceito de conjunto de portos (port set) que agrupa diversos portos. Em conjuntos de mquinas que tenham como sistema o Mach, o IPC permite a intercomunicao entre processos que se executam em mquinas distintas. esta funcionalidade proporcionada por um processo servidor, o NetMsgServer. Uma das facilidades providenciadas pelo sistema de comunicao a independncia de localizao das entidades. O NetMsgServer responsvel por efectuar a correspondncia entre os identificadores locais na mquina e os identificadores remotos. O NetMsgServer esconde do utilizador os detalhes associados aos protocolos de comunicao. Conceptualmente, os protocolos utilizados pelo NetMsgServer so transparentes para aplicaes.

CAP. 4 PROCEDIMENTOS REMOTOS A designao de arquitectura Cliente/Servidor estabelece a distino entre dois tipos de processos com comportamentos diferentes: os servidores implementam um conjunto de funes de interesse geral para outros processos que remotamente lhes podero aceder; os clientes efectuam a interface com os utilizadores, podendo executar parte das aplicaes localmente e acedem remotamente a processos servidores para executarem as funes mais complexas de manipulao de dados, clculo, entrada/sada, impresso, etc. Os servidores devem publicitar os seus servios e quais os protocolos que podem ser utilizados. A identificao do servio lgica e no pressupe uma localizao fsica, possibilitando a mudana de mquina do servidor sem necessidade de modificar o cdigo dos seus clientes. O cliente deve estabelecer uma ligao com o servidor (bind) antes de invocar um procedimento. O estabelecimento da ligao inclui normalmente vrias operaes: localizao do servidor; estabelecimento de um canal de transporte; autenticao do cliente e/ou do servidor. O cliente invoca uma operao remota no servidor, enviando-lhe os dados necessrios sobre o mecanismo de transporte de informao. A mensagem contm a identificao do procedimento remoto e os respectivos parmetros. Do lado do servidor efectuam-se as operaes inversas. O ciclo principal do servidor espera por uma mensagem, valida os dados recebidos, converte os parmetros para o formato interno e chama o procedimento apropriado. Quando este retornar, os resultados so empacotados, de acordo com a estrutura prdefinida e transmitidos de volta ao cliente. Para simplificar a programao de aplicaes baseadas no modelo cliente/servidor, foi desenvolvida uma metodologia de programao distribuda baseada na Chamada de Procedimentos Remotos que abreviaremos por RPC (Remote Procedure Call). O RPC permite uma transferncia de controlo e dados entre espaos de endereamento disjuntos quer residentes na mesma mquina quer em mquinas distintas. A ambio deste mecanismo ser totalmente transparente em relao ao modelo de programao habitual, podendo idealmente desenvolver-se uma aplicao de forma independente da rede ou das mquinas que a iro suportar. Para que o modelo seja coerente, o RPC dever estar integrado transparentemente num ambiente de programao. A transparncia total , contudo, difcil de atingir e para a analisar podemos subdividi-la nos aspectos: sintaxe da linguagem de programao; passagem de parmetros; semntica de execuo do procedimento; desempenho. A forma de especificao dos procedimentos remotos baseia-se numa linguagem de descrio de interfaces ou IDL (Interface Description Language) que segue uma sintaxe inspirada nas linguagens tradicionais (C, Pascal, C++), convenientemente estendidas para evitar ambiguidades. 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 sua gramtica define a forma de especificar os procedimentos, os tipos de dados e a sua origem (entrada, sada, bidireccionais). Para gerar as rotinas de adaptao existe um compilador. Tem como entrada a especificao da interface e gera as rotinas de adaptao para o cliente e para o servidor. A sada deste compilador so ficheiros com o cdigo fonte das rotinas, normalmente em C, que devero ser em seguida compilados e interligados com o cdigo das aplicaes. A transparncia sintctica fcil, as linguagens de especificao apresentam sintaxes prximas do C ou Pascal; a transparncia semntica mais complexa, porque as diferenas introduzidas pela separao dos espaos de endereamento no podem ser totalmente escondidas, a transparncia em termos de desempenho naturalmente impossvel, sendo muito diferente o tempo de execuo no espao de endereamento de um processo, numa nica mquina ou distribuda. Na declarao dos parmetros, necessrio eliminar as ambiguidades na definio dos tipos de dados: apontadores genricos, cadeias de caracteres ou vectores de tamanho varivel. Devido maioria das IDL ser inspirada na linguagem C, a definio dos tipos tem de ser enriquecida para permitir desambiguar as situaes bastante permissivas existentes nesta linguagem. A transferncia de parmetros por referncia no pode ser implementada de forma directa, devido ao RPC ser utilizado entre espaos de endereamento disjuntos. A passagem por referncia

obriga a copiar a estrutura no cliente para a mensagem, detectando a sua dimenso, e no servidor a reserva dinmica da memria para onde ir ser copiada. Nos iniciais sistemas de RPC era restringida a utilizao desta forma de transferncia de parmetros; contudo, esta limitao demasiado restritiva na maioria dos sistemas onde a utilizao de lista e estruturas de dados dinmicas se adequa bem aos algoritmos. Existem vrios problemas e solues na passagem de parmetros por referncia que tem de ser convenientemente analisados em cada sistema de RPC. A heterogeneidade na representao de dados um dos factores limitativos da transparncia na interaco distribuda. A tipificao dos parmetros na especificao da interface permite ao compilador introduzir no cdigo das rotinas de adaptao as chamadas s funes de converso, de acordo com um protocolo de apresentao de dados definido para o sistema de RPC. O desempenho naturalmente muito diferente quando se considera a execuo no espao de endereamento de um processo, numa nica mquina ou distribuda. Este um dos aspectos em constante evoluo, fruto dos avanos tecnolgicos. Contudo, nunca ser possvel esbater totalmente as diferenas, pelo que o programador ter de ter sensibilidade a estes condicionamentos, sabendo os limites da transparncia em termos de desempenho. A chamada de procedimento remoto uma abstraco lgica; na realidade, as chamadas remotas comeam com uma chamada a um procedimento local que se encarrega de iniciar a invocao remota. Estas rotinas de adaptao (stub routines) tm um papel preponderante na arquitectura do sistema. No lado cliente, o procedimento de adaptao responsvel por: converter e empacotar os parmetros numa forma apropriada para transmisso; enviar a mensagem para o servidor usando um servio de transporte; esperar pela resposta do servidor. Quando esta for recebida, desempacota os resultados, convertendo-os para a representao local dos dados na mquina do cliente. Do lado do servidor, a rotina de adaptao tem finalidade simtrica. Se existir paralelismo no servidor necessrio introduzir nas rotinas de adaptao do servidor a sincronizao compatvel com os mecanismos de multiplexagem de contexto. As rotinas de adaptao recorrem a uma biblioteca de funes para todas as operaes genricas do sistema de RPC. As funes de biblioteca efectuam controlo da semntica da chamada remota, a converso dos dados e a ligao aos mecanismos de transporte. Como natural, as funes de suporte incluem tambm mecanismos para registo do nome nos servidores de nomes e para o tratamento de erros e excepes. A biblioteca de funes com as respectivas estruturas de dados globais constitui o ambiente de suporte (run-time) execuo do RPC que ser carregado em memria com a aplicao distribuda. Antes da invocao de um procedimento remoto, o cliente tem de localizar o servidor e estabelecer uma sesso atravs de um protocolo de ligao (binding). O estabelecimento da sesso permite, em seguida, executar as operaes remotas com uma latncia reduzida. A forma como esta ligao se estabelece depende de diversas decises de arquitectura (transporte com/sem ligao, servidor com/sem estado). Genericamente, podemos considerar os seguintes passos no estabelecimento da ligao: localizao do servidor os clientes contactam o servidor de nomes para determinar o endereo dos servidores que pretendem aceder; autenticao, dependendo das caractersticas de segurana, o servidor pode exigir ao cliente uma identificao segura, de forma a validar a sua identidade, o cliente pode tambm querer assegurar-se que o servidor realmente o processo correcto e no outro que lhe tenha usurpado a identidade; estabelecimento da sesso, do lado cliente preenchida uma estrutura com o canal associado ao servidor. No servidor poder ou no existir uma estrutura que fique a referenciar o cliente. Quando esta estrutura mantida, o servidor conserva o estado das ligaes, alternativamente, o servidor no mantm estado, devendo, neste caso, utilizar canais de transporte sem ligao. A vantagem desta soluo que torna o servidor completamente independente dos clientes, podendo ser reinicializado sem qualquer precauo especial.

A execuo da chamada remota pode considerar-se como a conjugao de trs protocolos: protocolo de apresentao para resolver a heterogeneidade; protocolo de controlo da semntica de execuo; protocolo de transporte para a transmisso de dados. O protocolo de controlo define a semntica de execuo do procedimento. A semntica tem essencialmente a ver com a forma como so tratadas as faltas que podem surgir durante a execuo de um procedimento remoto: a perda da mensagem inicial do cliente; perda da mensagem no interior do servidor; falha do servidor, tornando-se impossvel determinar qual a situao da execuo do procedimento invocado remotamente; perda da mensagem de resposta do servidor; o cliente aborta antes de ter processado a mensagem de resposta. As semnticas de execuo da chamada remota habituais so: talvez (may-be) no trata o erro e ao fim de um determinado intervalo de tempo sem resposta, liberta o processo cliente; pelo-menos-uma-vez (at-least-once) se a mensagem de resposta no for recebida num intervalo de tempo prdeterminado, reenviada a mensagem de invocao at obter resposta. Garante-se que o procedimento foi executado pelo menos uma vez porque houve uma resposta, mas pode ter sido mais que uma vez. Para garantir um funcionamento correcto com esta semntica, o servidor deve apenas oferecer funes idempotentes, em que mltiplas execues da mesma chamada so idnticas a uma s execuo com os mesmo parmetros; na semntica no-mximo-uma-vez (at-most-once), a operao remota executada apenas uma vez ou poder no ser executada se existirem faltas de paragem nas mquinas cliente ou servidor. O protocolo de suporte do RPC deve filtrar pedidos duplicados no servidor, confirmar todas as operaes e manter as mensagens at ter a garantia da sua recepo correcta. O problema de garantir a semntica exactamente-uma-vez advm da impossibilidade de, no caso de um servidor falhar durante a execuo de uma operao remota, saber exactamente o momento em que tal sucedeu e qual o estado em que ficou a execuo da invocao. Para implementar uma semntica exactamente-uma-vez, so necessrios mecanismos de tipo transaccional no servidor. O protocolo de apresentao tem de permitir s rotinas de converso do receptor conhecer o tipo de dados presentes na mensagem. Existem duas solues gerais: explcita para cada dado ou bloco de dados de um determinado tipo colocado na mensagem um descritor que identifica o tipo; implcita na mensagem so enviados apenas dados, existindo convenes que permitem determinar as converses a efectuar para cada tipo de mquina. O tratamento implcito tem duas variantes: considerar que existe uma forma cannica de transmisso, a qual dever ser utilizada em todas as mensagens; enviar os dados na forma como esto representados na mquina de origem, incluindo na mensagem uma identificao do tipo de mquina. O receptor efectuar, se necessrio, a converso para o seu formato interno (receiver makes it right). esta soluo evita o problema da possvel dupla converso, mas obriga a uma componente de gesto mais complexa pelo que a primeira alternativa a mais utilizada. Um dos aspectos importantes do sistema a optimizao do desempenho dos servidores. A lgica do RPC adapta-se bem utilizao de tarefas no servidor que ficam a actuar como prolongamento do fio de execuo do cliente. A existncia de vrias tarefas obriga a que o cdigo da biblioteca de RPC contenha sincronizao explcita para regies crticas e dados partilhados. No servidor, um conjunto de tarefas criadas inicialmente fica bloqueado espera de uma mensagem. Quando ela chega, uma tarefa desbloqueada e serve o pedido de uma forma idntica ao caso sequencial. Realizaes mais sofisticadas criam dinamicamente novas tarefas quando se esgotam as criadas inicialmente e terminam-nas quando no so mais necessrias. H situaes em que um servidor, para processar um pedido, necessita de aceder a um segundo servidor. Um caso particular tem lugar quando este segundo servidor o cliente inicial. Este caso, em que o servidor necessita de chamar o cliente denomina-se chamada em ricochete (callback). Do ponto de vista da biblioteca de RPC, esta situao requer que qualquer servidor se possa comportar tambm como cliente e que qualquer cliente possa ser tambm servidor. O primeiro caso no levanta grandes dificuldades, o servidor limita-se a chamar a rotina de adaptao do

servio que pretende invocar. Permitir que um cliente se comporte tambm como servidor mais complicado. 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. O desempenho de um sistema RPC crucial para o desempenho global das aplicaes que o utilizam. Apesar de ser um factor de segunda ordem quando se utiliza continuamente um servidor, o tempo de estabelecimento da ligao pode ter uma 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 que evitem o tempo inicial de estabelecimento do canal. O tempo de um RPC simples tem as seguintes componentes: tempo de converso e empacotamento dos parmetros de entrada e sada no cliente e no servidor; tempo de execuo do SO: chamadas ao sistema, comutao de processos, etc.; tempo de transmisso das mensagens. Estas componentes so muito semelhantes s que foram consideradas na discusso sobre protocolos de comunicao. O que um sistema de RPC tem de particular a sua utilizao corrente como mecanismo de estruturao de aplicaes distribudas. Nestas, a esmagadora maioria das rotinas tem poucos parmetros e envolve poucos dados, sendo a transferncia macia de dados muitas vezes efectuada por intermdio de protocolos especializados de transferncia de ficheiros. Por este motivo, o desempenho de um sistema RPC geralmente optimizado no sentido de diminuir a latncia das chamadas mais comuns, aquelas que enviam e recebem poucos dados. Para ilustrar os conceitos anteriores, descreve-se no texto um sistema de RPC desenvolvido pela Sun Microsystems para servir de suporte ao seu sistema de ficheiros distribudos NFS. Como a a maioria dos sistemas de RPC em Unix, o Sun-RPC utiliza sockets ou TLI como interface para os mecanismos de transporte de informao. A Sun assumiu que o protocolo de controlo do RPC deveria ser independente do protocolo de comunicao, podendo usar-se transportes com ou sem ligao. No texto descreve-se: a linguagem de especificao, o tratamento da heterogeneidade, a biblioteca de suporte do RPC e o protocolo de comunicao.

CAP. 5 GESTO DE NOMES Os nomes so fundamentais nos sistemas informticos para permitir identificar, localizar e partilhar os objectos. Nos SO, para alm destas funes, os nomes