PREFÁCIO Sistematização e síntese dos problemas de base provocados pela distribuição, os modelos necessários ao enquadramento do problema bem como

as soluções da engenharia de computadores. Enquadramento geral do problema com exemplos de sistemas que se encontram em uso. Quais são os novos desafios aos sistemas operativos? Do livro anterior vêm 2: a distribuição e arquitecturas multiprocessador. Estas mexem apenas com o núcleo, técnicas portanto. a distribuição introduz um conjunto de problemas de grande complexidade, derivada dos fenómenos de escala, da complexidade do modelo de faltas e da vulnerabilidade da segurança; o que tem implicações directas na programação das aplicações, pelo que o modelo tem de ser perceptível ao programador. Organização do Texto ... 1. INTRODUÇÃO Os desafios continuam a ser essencialmente os mesmos que estiveram na sua génese dos sistemas multiprogramados: . Simplificar a interface com o sistema . Extrair o máximo rendimento da infra-estrutura de hardware Depois dos 20 anos de consolidação, que terminaram nos anos 70, há um aperfeiçoamento e inclusão das ideias base dessa investigação. 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 aplicações, implicou que o sistema passasse progressivamente a englobar um número crescente de funcionalidades relacionadas com a distribuição, a gestão da informação e a interface homem-máquina. Daí o uso de Software de Sistema: núcleo + servidores, bibliotecas e protocolos. 1.1. Condicionantes da Evolução Há uma technology push” e tb. as imposições dos utilizadores. 1.1.1. A Tecnológica Evoluções tecnológicas 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 aéreas com a sua necessidade de sistemas transaccionais e interactivos. Os operadores públicos na Europa introduziram serviços de trx. de dados (ex. X-25) que permitem às empresas a utilização de redes públicas para transferência de informação. Redes abertas universitárias (Arpa, Cyclades). Internet, como exemplo paradigmático de sistema distribuído, com todos os seus problemas de escala e segurança. RDIS (2x64Kbits). ATM que começa a ser usada nas redes públicas. LANs (Ethernet, Token-Ring), com dezenas de Mbps. Computadores Pessoais Tecnologia Circuitos Lógicos Memórias Discos Evolução da Densidade (de 3 Evolução do Desempenho em 3 anos) (tempo de ciclo) Duplica 50% em 2 anos Quadruplica 33% em 10 anos Duplica 33% em 10 anos

A evolução, em termos de hardware, com maior impacto em toda a estrutura da indústria foi a introdução no mercado dos computadores pessoais. A existência dos PCs acelerou, de forma considerável, a percepção da necessidade dos sistemas distribuídos. Os gestores de empresas passaram a considerar a hipótese de descentralizarem o seu suporte informático, colocando máquinas de menor porte junto dos grupos que as utilizavam directamente. Os utilizadores fazendo aplicações 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 aplicações informáticas, o modelo cliente-servidor. Sistemas Abertos Fabricantes de hardware desenvolviam o SO optimizado. Impossível mudar de fornecedor. A pressão dos grandes utilizadores levou a criação de sistemas abertos: separação clara entre o hardware e o SO e entre este e as aplicações. 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 padrão de facto. Arquitecturas Multiprocessador Na década de 70 e 80 eram especializados, hoje são correntes. As limitações físicas e custos de desenvolvimento que permitiram ir melhorando os acessos às volumosas bases de dados e interfaces complexos em computadores, estão a ser substituídos pelas arquitecturas multiprocessador que aumentam o desempenho mantendo os ambientes de desenvolvimento de software. Existem múltiplos esquemas para classificar os multiprocessadores com base na forma como organizam os fluxos de dados e de instruções. Neste livro usaremos só as arquitecturas MIMD (Multiple Instruction, Multiple Data), que corresponde aos casos em que cada processador executa as suas instruções e trabalha sobre os seus dados. As MIMD podem ser de dosi tipos: Memória Central Partilhada (+ vulgares e mais interessantes se pensarmos que se pensa em incluir, na mesma pastilha, vários processadores) e as de Memória Distribuída. 1.1.2. Requisitos dos Utilizadores Finais Ser isolados dos detalhes complexos introduzidos pelos novos ambientes computacionais: Procura de transparência: nomes, comandos e semânticas idênticas para todos os objectos sob controlo do SO (invocar aplicações, aceder a ficheiros, utilizar periféricos, etc.). Isso requer sistemas de nomes homogéneos, interfaces simples, visão integrada dos vários sistemas de ficheiros, etc. A vantagem mais visível ao utilizador com a distribuição é a partilha de informação. Uma aplicação local pode aceder a informação remota. Uma outra vertente é comunicação entre utilizadores humanos. Outra é a ergonomia das interfaces. Isto quanto à funcionalidade. Quanto à qualidade temos a segurança, a fiabilidade e a disponibilidade. Requisitos do Programador Um requisito, relacionado com os sistemas abertos, é a simplificação da portabilidade de aplicações através da definição de interfaces normalizadas ou API (Application Programming Interface) com o software de sistema. Estas interfaces têm a ver não só com as funções de núcleo do SO, como com os mecanismos de comunicação, partilha de ficheiros, segurança, etc. O programador também pretende um ambiente de programação que lhe facilite o desenvolvimento das aplicações, tornado o código independente da arquitectura das máquinas, da rede, dos protocolos, dos SO locais e mesmo do número de máquinas e utilizadores. Requisitos do Gestor A capacidade de evolução modular e a extensibilidade. O aumento da fiabilidade e disponibilidade. Finalmente, é importante a capacidade de gestão global do sistema que permita a reutilização de equipamentos, a gestão integrada dos arquivos de informação, diminuição das tarifas.

1.2. Dificuldades e Vantagens Introduzidas pela Distribuição 1.2.1. Os Problemas Comunicação Exclusivamente por Mensagem Nos sistemas multiprogramados, no núcleo toda a comunicação se efectua através de um espaço de endereçamento partilhado. Nos distribuídos não há memória comum, introduz características diferentes no modelo de comunicação. A taxa de erros, se bem que venha diminuindo, é sempre maior que a interna a uma máquina.

Capítulo 2 ... Nível de Subrede A camada inferior do modelo Internet é específica a cada tecnologia física de transmissão, que define o encapsulamento do nível superior. Na Internet apenas se define o protocolo entre camadas correspondentes, ou sej, o formato das mensagens, o seu significado e as acções associadas, não existindo uma interface de serviço para cada camada. Logo, cada tecnologia de subrede tem de definir a interface disponibilizada para o nível de interligação de rede. Embora não garanta opacidade entre níveis, tem a vantagem de as normas de encapsulamento tirarem partido das características específicas da tecnologia de subrede para implementação eficiente. Existem especificações de encapsulamento de pacotes do nível IP para todas as tecnologias (analógicas, ATM, etc.) Nível de Interligação de Redes Disponibiliza Às camadas superiores um serviço de encaminhamento dos pacotes através da rede (conjunto de subredes independentes). O serviço oferecido pelo nível IP não dá qualquer garantia de fiabilidade (“melhor esforço possível). Não é necessário este nível na comunicação entre 2 nós da mesma subrede mas uniformiza se utilizado. Nível de Transporte Na família Internet definem-se 2 protocolos nesta camada (a mais parecida com OSI): O TCP (Transmission Control Protocol) – serviço semelhante ao de um canal de trx. fiável, com ligação que garante a retransmissão de pacotes corrompidos, a eliminação de pacotes duplicados e entrega dos pacotes pela mesma ordem; define o esquema de endereçamento utilizando o conceito de porto para identificar o utilizador final do serviço de transporte; e o UDP (Unit Datagram Protocol) – é não fiável, como o IP, em cujos serviços se baseia, adicionando checksum e endereçamento dos portos de acesso ao serviço de transporte UDP. A distinção entre as mensagens do protocolo UDP e do TCP é efectuada pelo tipo de pacote IP. Pertencem pois a espaços de endereçamento distintos. Nível de Aplicação Utilizam os serviços de transporte para fornecer funcionalidades adicionais. São transparentes À rede. ex: SMTP, TELNET, FTP, DNS. A cada um dos serviços/aplicações é atribuído um porto específico de transporte (well known ports). 2.5. Redes Locais de Computadores Foram um dos factores decisivos na evolução das arquitecturas centralizadas para distribuídas. Características da normalização: com partilha efectiva do meio físico; apenas os dois primeiros níveis do modelo OSI; de 1 a 20Km. Transmissão de difusão; em anel ou bus. 2.5.1. Controlo de Acesso ao Meio de Comunicação Um dos primeiros problemas que se colocou na definição da norma foi a inadequação da subdivisão considerada no modelo OSI entre nível físico e de ligação de dados e a estrutura de controlo de trx. da maioria das redes locais. Para eficiência não podia haver independência entre nível físico e lógico. Então criou-se um subnível designado por Controlo de Acesso ao Meio – MAC. Multiplexagem na Frequência É a solução tradicional para multiplexar vários canais de comunicação num meio físico – redes de banda larga. Desvantagens ao nível de gestão 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 vários emissores. Multiplexagem no Tempo Síncrona O tempo é dividido em intervalos de duração fixa, síncronos com relógio central. Cada emissor dispõe de um intervalo de tempo fixo para colocar a informação no meio (ex. trx. de voz digital: PCM – trama básica de 32 blocos de 8 bits) – adapta-se bem a fluxos contínuos de informação como voz ou vídeo. Nos ambientes computacionais habituais, as trx. não têm padrão assim regular. Multiplexagem no Tempo: Assíncrona É preciso algoritmo de atribuição de tempos: - Aleatório; - Passagem de testemunho; - Controlo centralizado O aleatório baseia-se na reduzida probabilidade de dois emissores começarem, no memso instante, a trx. A estação que pretende emitir fá-lo-à assim que detectar que o meio está livre. As outras aguardam. O problema surge com as colisões. É a base da Ethernet. Na segunda há um testemunho lógico (token) que circula entre as várias estações de um anel lógico. Apenas a estação na posse do testemunho pode emitir. As vantagens é que a rede pode ser mais facilmente modelizável e, portanto, os débitos podem ser assegurados através de gestão de prioridades adequada. As desvantagens é alguma complexidade para garantir o bom funcionamento do testemunho na inicialização e em caso de falhas. Introduz atrasos no acesso quando a estação tem de esperar pelo testemunho. Suporta melhor o funcionamento em carga elevada que a Ethernet. O controle centralizado numa estação que se encarrega de inquirir (polling) às restantes se pretendem emitir. É mais simples mas depende muito da estação que controla quanto À fiabilidade e desempenho. Desenvolvimento levou a distribuição vertical ou dorsal (backbone – fibra óptica) através de pontes ou encaminhadores. FDDI é representativa das redes de alto débito. 2.5.2. Rede Ethernet Remonta a 1974. É a mais usada. IEEE 802.3. Nível Físico A topologia de base é bus e velocidade de trx. original de 10Mbps. O suporte físico inicial era o cabo coaxial e máximo segmento de 500 m extensível a 1,5 km com repetidores. A evolução alargou para par entrançado e fibra óptica. Estruturou-se a cablagem, com a utilização de cabos mais baratos UTP (Unshielded Twisted Pair) e STP (Shielded Twisted Pair). Existem especificações 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 mnemónica B/Modo/D, com B- largura de banda; Modo – distingue a utilização em banda de base ou em modulação de frequência (Base ou Broad); D – indica distância máxima. Ex: 10BaseT – 10Mbps, banda de base, 100 metros de comprimento máximo da ligação, par entrançado. A topologia em bus tem sido mantida do ponto de vista conceptual, mas a definição de siatemas de cablagem estruturada conduziu a soluções baseadas em concentradores (hub) que agregam várias ligações Ethernet às máquinas (bus funciona conceptualmente dentro do concentrador). Método de Controlo de Acesso ao Meio É por divisão no tempo assíncrono com controlo aleatório, CSMA/CD (Carrier Sense Multiple Acess/Collision Detection). Normalmente as funções de comunicação são implementadas por hardware no comunicador ethernet. O funcionamento deste controlador pode resumir-se:

Após activação da recepção, o comunicador analisa o endereço de destino das tramas que passam no canal e recebe as que lhe são dirigidas ou as que têm o endereço de difusão. Para trx., o comunicador constrói a trama no tampão de trx., encapsulando os dados que lhe são fornecidos pelos níveis superiores. A partir deste momento, o comunicador escuta o tráfego no bus (carier sense) e lança automaticamente a tx. quando detecta o canal livre. Pode haver colisão. Para a detectar, a estação emissora escuta simultaneamente o bus para verificar se o sinal emitido não foi adulterado (collision detection). Se detecta colisão, pára de emitir e reforça a colisão. Depois retira-se do canal e volta a tentar mais tarde. Para evitar situações ambíguas, os pacotes têm um tamanho mínimo tal que o seu tempo de trx. é o dobro do tempo de propagação. Antes de retransmitir aguarda um número inteiro de slot-time, num algoritmo Truncated Binary Exponential Backoff. Formato das Tramas - Preâmbulo de 64 bits (101010101...1011) para sincronização dos relógios e delimitação física da trama; - Endereços de 6 octetos para destino e origem; - Campo tipo, na norma Ethernet, identifica o campo de dados face aos protocolos de nível superior, tendo na norma 802.3, o significado do tamanho de campo de dados; - O comprimento máximo dos dados é de 1500 bytes; - O CRC tem 32 bits e abrange todo o pacote, excepto o preâmbulo. 2.5.3. FDDI – Fiber Distributed Data Interface Concebida para ser usada como espinha dorsal (backbone) de grandes centros computacionais ou para interligação de redes locais. A vel. de trx. é 100Mbps. A versão inicial foi revista para suportar tráfego isócrono, MANs, e fibras monomodo. Universidades usam muito. Nível Físico O meio de trx. é a fibra óptica. A norma prevê anel duplo (A e B), permitindo a continuação da operação em caso de quebra de interligação entre dois nós. A distância entre estações pode ir até 2km e a rede pode ir até um perímetro de 200Km e até 1000 estações. Método de Controlo de Acesso ao Meio O controlo de acesso ao meio é feito através de um protocolo de testemunho temporizado, semelhante ao token ring da IBM e que também considera 4 níveis de prioridade. Para emitir, uma estação tem de estar na posse do testemunho. A mensagem circula no anel e é retirada quando retorna à estação emissora. Ao contrário do token ring, o testemunho é libertado assim que a estação acaba de trx. e não quando a mensagem volta. Os endereços são de 48 bits. Oferece extensão para tráfego isócrono para trx, de voz e vídeo. 2.6. Interligação de Redes Nas redes de grande escala, o nível rede caracteriza o serviço oferecido. Existem 2 filosofias para a realização deste nível: Circuito virtual (preferida dos Operadores de Telecomunicações) ou sem ligação. Na primeira o protocolo de transporte negoceia a qualidade de serviço pretendida. A rede é responsável por criação de mecanismos que assegurem a entrega fiável 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 expressão prática desta diferença é o X.25 e o IP. 2.6.1. Equipamento de Interligação

Se a ligação for meramente ao nível físico – repetidores (utilizados por ex. para ligar 2 segmentos duma rede Ethernet, idênticas portanto). A ponte (bridge) opera ao nível lógico o que pressupõe redes com nível lógico idêntico. A ponte copia tramas duma rede para outra. Como as tramas têm endereço, pode fazer-se filtragem. São usadas na hierarquização (razões: tráfego excessivo, grandes distâncias, gestão em depts., etc.) de redes locais (interligação de LANs) – complexo se redes diferentes. 2 tipos: ponte transparente (com memória interna, onde irá progressivamente guardar os enderços das redes que liga); pontes com encaminhamento na origem Finalmente, a interligação no sentido mais abrangente efectua-se no nível rede. É o encaminhador (router) (gateway, ou porta, é genérico, sendo tb. software que compatibiliza protocolos de qualquer nível) 2.6.2. Rede X.25 Implementação de um serviço público para comunicação entre máquinas geograficamente distantes. As máquinas dos utilizadores interligam-se à rede através de uma ligação ponto-a-ponto ao comutador da rede. Nível Físico Consiste na ligação ponto-a-ponto utilizando linhas analógicas ou digitais. Nível Lógico Usa o protocolo LAPB (Link Acess Procedure), que implementa controlo de fluxo, recuperação de erros e garante que o comutador recebeu correctamente o pacote. As tramas são de 3 tipos: informação, supervisão e não numeradas. Nível 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 destinatário, se quiser, responde com call accepted. Para ter minar a ligação qualquer um pode enviar um clear request que deve ser confirmado. Para satisfazer a necessidade de um serviço 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 ligação com um clear request que também foi expandido para ter 128 octetos de dados, o que evita pois a ligação. O endereçamento é semelhante ao do serviço telefónico com código por país, rede e nó e o endereço pode ter até 14 dígitos decimais. O X.25 ilustra o problema da redundância funcional já referido no OSI. O nível de rede e o de ligação de dados implementam ambos o controlo de fluxo. As limitações de desempenho permitem prever a sua substituição pelo Frame Relay, que dá um serviço mínimo que não oferece mecanismos de recuperação de dados e de controlo de fluxo. Posiciona-se melhor para uma tecnologia de interligação 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, dispôem de máquinas com capacidade de execução de protocolos. Os princípios b´sicos do IP são: - O serviço oferecido é sem ligação; - O serviço é na base do “melhor esforço” ; - O endereço de um nó subdivide-se em duas componentes: a identificação da subrede a que o nó se encontra ligado e a identificação do nó nessa subrede; - O encaminhamento é efectuado independentemente para cada pacote; - A decisão de encaminhamento é feita com base no identificador da subrede de destino, com excepção dos nós da mesma rede em que é pelo endereço do nó.

Endereços IP É cosntituído de forma hierárquica por um par: <identificador Rede – netid; identificador Máquina – hostid> O número de bits associado a cada elemento não é fixo, existindo 3 classes: A, B e C. Qualquer organização com um endereço IP pode subdividi-la (pelos bits menos significativos) para formar subredes internas. Um enderço IP pode identificar uma máquina (netid=0) ou uma rede (hostid=0). Os endereços de difusão têm todos os bits de hostid=1. Um endereço não representa uma máquina, mas um ponto de ligação de uma máquina 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 endereços são os comuns a hierarquização: - Se a máquina muda de rede, torna-se necessário mudar o seu endereço bem como tabelas onde ele se encontra - No caaso da máquina ter vários endereços, os protocolos utilizam a especificação de rede contida no endereço, mesmo que outros caminhos fossem mais eficientes. Endereços IP actuais têm 32 bits. Não é possível tipo telefónico, devido à grande diversidade de redes tamanhos dos endereços locais dificuldade no sistema de atribuição vs. desempenho. Para simplificar legibilidade são representados por 4 dígitos separados por pontos, cada dígito 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 – endereço de difusão) IPv6 vai ter 128 bits. Protocolo IP O protocolo de nível rede é simples. Implementa o encaminhamento através de tabelas fixas e um controlo de congestão com libertação de pacotes. A unidade de transferência é o pacote ou datagrama, formado por cabeçalho, bloco de dados, cuja dimensão total está limitada a 64Kbytes. Se redes impuserem pacotes mais pequenos o protocolo fragmenta. Cabeçalho: ta,anho total do datagrama (16 bits-->64Kbytes), identificação do pacote, deslocamento do fragmento. Os fragmentos são desdobrados em múltiplos de 8 octetos --> 13 bits --> 8192 fragmentos; TTL (time to live); header checksum. Ver pacote IP na página 85. Na mesma subrede o encaminhamento é directo (traduz o endereço IP para o endereço da subrede física). Se for indirecto é preciso enviá-lo ao nó que actua como encaminhador. A máquina emissora tem de conhecer os endereços das portas de encaminhamento, que têm tabelas.

CAPÍTULO 3 – Interface de Comunicação 3.1. Modelo da Comunicação Distribuída O modelo computacional tem de oferecer ao programador de aplicações uma visão coerente dos objectos de comunicação e das funções que lhes estão associadas. A comunicação num ambiente distribuído é uma evolução de comunicação entre processos numa única máquina. Corresponde também à troca de mensagens entre 2 processos. O modelo computacional é constituído por objectos de comunicação ou portos e por funções agrupadas numa biblioteca. É a interface API (Application Programming Interface) da comunicação. Não há transparência entre a interface e os protocolos subjacentes (só idealmente). As características da interface são quase as do serviço de transporte. Os protocolos de comunicação são geralmente integrados no núcleo. A comunicação pode modelizar-se por um processo emissor, outro receptor e o canal (abstracção dos mecanismos de transporte que permitem a comunicação. As extremidades do canal são os portos. Conceptualmente o canal pode ser considerado como a associação de dois portos. Para que exista comunicação, esta associação tem de se estabelecer, podendo ter uma forma duradoura, no canal com ligação, ou apenas para uma interacção, no canal sem ligação. A informação transmitida é designada por mensagem, devendo ser interpretada por um protocolo de alto nível. Quando a qualidade de serviço oferecida pelo canal não pode ser mantida, o sistema deve avisar o processo através do mecanismo de excepções, que no caso dos sistemas distribuídos assume um papel mais importante devido a haver mais falhas. As interfaces utilizadas numa aplicação distribuída podem, portanto, ser diferentes consoante o SO. A garantia da capacidade de comunicação é dada pelo protocolo de transporte que implementa o canal. 3.2. Caracterização da Interface 3.2.1. Canal com ou sem ligação No caso de uma única máquina, o canal é implementado por zonas de memória partilhada, logo elevada fiabilidade. Tal não se passa nos distribuídos, sendo essa uma diferença fundamental. O desempenho tb. é menor. A fiabilidade e desempenho devem ser explícitos para o programador (qualidades de serviço várias, cada qual melhor adaptável à aplicação). A forma mais vulgar de traduzir o tipo de serviço é: - Canal com ligação: fiável, bidireccional e c/ garantia de sequencialidade; - Sem ligação ou Datagrama: Não oferece garantias de fiabilidade. O primeiro é preferível quando existe fluxo contínuo de informação, mas consome recursos de forma permanente e ter tempo de latência significativo no estabelecimento do canal. O segundo adapta-se melhor à comunicação com muitos interlocutores, a mensagens de pequena dimensão (típicas dos sistemas client-servidor) 3.2.2. Portos de Comunicação Para transferir informação os processos interactuam com um porto que representa a extremidade do canal, que são uma abstracção para o SO, como os sockets, caixas de correio. Têm um sistema de designação e conjuntos de funções. São interface entre o SO e o protocolo de transporte. O identificador associado ao protocolode trnsporte pode ser explícito na interface (ex. sockets) ou encapsulado (ex. Mach). Quando um porto é criado pode logo ser estabelecida a associação entre o identificador local e o endereço de comunicação ou num momento posterior (ex. sockets é por bind). No caso em que os programadores têm de conhecer os endereços de transporte, como os portos TCP/IP nos sockets, existem mecanismos para designar os portos por nome inteligíveis – serviço de nomes.

Do elenco de operações associadas aos portos temos as funções de envio e recepção das mensagens, criar e eliminar um porto, associar um endereço de transporte e definir parametrização do canal. No caso do canal sem ligação, o porto receptor comporta-se como uma caixa de correio à qual são 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 endereço do porto emissor para que o receptor possa estabelecer o canal de resposta. 3.2.3. Semântica da Função de Envio No tocante à sincronização, a operação de envio de mensagens, pode ter várias semânticas que se relacionam com a detecção de faltas na comunicação: - Assíncrona: A função copia a informação da mensagem para os tampões do protocolo de transporte e retorna depois de iniciar a operação de envio. O processo emissor é desbloqueado assim que a função retorna do núcleo, mas não tem qualquer garantia que a mensagem chegou ao seu destino. - Síncrona: O processo emissor fica bloqueado até que o porto destinatário confirme que recebeu a mensagem - Cliente/Servidor: o processo emissor fica bloqueado até receber a mensagem de resposta. A assíncrona é de aparente maior desempenho, mas a possibilidade de muitas processos paralelos levanta grandes problemas a nível de sincronização (protocolos próprios) e as aplicações têm de ser programadas com muito mais cuidado (por eventos, ao contrário do que se está habituado), que levam à não muita utilização. Será eficiente no caso de tráfego desequilibrado (FTP, Telnet). Na pergunta-resposta não tem vantagens. O síncrono oferece garantia que a informação foi correctamente trx. mas não permite detectar qualquer falha na execução do serviço. Tb. é de programação complexa, para evitar interblocagens. CSP. A cliente-servidor procura garantir a execução da operação, assegurando-se que o processo só continua a sua execução quando recebe resposta. Esta interface é semanticamente bastante mais rica, pelo que tem sido usada como base de programação do modelo cliente/servidor. Mas implica conjunto de operações que não existem no protocolo de transporte. 3.2.4. Estrutura das Mensagens Pode ser individualizada ou serem apenas sequências de octetos de tamanho variável (byte stream) que emula as interfaces dos ficheiros de texto ou das E/S para terminal. Se for byte stream o nível aplicação tem de traduzir significado. Quando individualizadas existe relação directa com as estruturas de dados dos programas. Normalmente o sistema de suporte à comunicação não impõe formatação específica às mensagens. Uma possível razão para a impor seria a heterogeneidade. 3.2.5. Semântica de Recepção É retirar a primeira mensagem existente no porto ou, caso nenhuma esteja presente, bloquear o processo. Se houver várias ligações específicas coloca-se o clássico problema dos múltiplos pontos de sincronização. Relaciona-se com: se for sem ligação pode usar-se um porto para receber as mensagens de todos os processos interlocutores, mas assim não é possível estabelecer prioridades. Por esta razão é frequente os servidores criarem vários portos para mensagens, de tipo ou de interlocutores de classes diferentes. No canal com ligação, o porto fica associado ao canal. A solução de ambos os problemas é criar um mecanismo de recepção múltipla sobre um conjunto de portos. O processo bloqueia-se até que um dos portos receba uma mensagem que lhe é destinada. A função funciona como um comando com guardas lógicas que, quando uma delas se torna verdadeira, desbloqueia o processo. É frequente associar à primitiva de recepção uma temporização (cominicação bidireccional remota). A primitiva select dos sockets é um exemplo de uma função de recepção múltipla com temporização associada. A função de recepção também pode ser assíncrona (teste da existência de mensagens no porto. caso não existam retorna ao processo).

3.2.6. Paralelismo A sincronização das primitivas de envio e recepção de dados está fortemente relacionado com o modelo de concorrência em termos de processos e tarefas. A necessidade de paralelismo colocase fortemente na programação de processo que actuam como servidores -> atender simultaneamente vários clientes. Uma forma de introduzir paralelismo no servidor é utilizar vários processos em paralelo. Esta solução obriga, porém, à partilha de estruturas de dados (memória e sincronização), que é sempre de programação delicada, porque reintroduz o problema dos múltiplos pontos de sincronização. O modelo computacional mais adequado é um modelo multitarefa com vários fios de execução concorrentes que se sincronizam no acesso a variáveis partilhadas. Tem várias vantagens: o modelo de programação continua simples, pois o seu código é idêntico a um servidor sequencial, apenas com a introdução da sincronização no acesso a estruturas de dados partilhadas; permite explorar situações em que uma tarefa se bloqueia durante o serviço a um pedido, por exemplo para aceder ao disco; tira partido dos eventuais vários processadores existentes. Progressivamente os SO têm vindo a fornecer suporte para mecanismos multitarefa integrados na gestão dos processos. 3.2.7. Faltas na Comunicação Podem ter numerosas origens, sendo as mais frequentes relacionadas com a quebra do canal de comunicação. tal pode acontecer porque a rede física falhou ou os protocolos esgotaam os tampões. O Mach usa tratamento de excepções. 3.2.8. Difusão de Mensagens Nas locais há mecanismos eficientes e intrínsecos. Nas grandes não pois a indiscriminação pode originar muitas mensagens suplementares na rede. Devido ao interesse dos algoritmos baseados na difusão, foram propostos mecanismos de difusão mais restritos a grupos de portos. Os grupos têm nomes que os identificam e podem ser criados dinamicamente. Existe opcionalmente no IPv4 e generaliza-se no IPv6. Há que distinguir também: Os protocolos com entrega fiável a todos são designados por difusão atómica. Têm despertado grande interesse em políticas de tolerância a faltas dado que são o suporte indicado para políticas de replicação (mais complexos – ISIS). Os outros não garantem a entrega a todos (melhor esforço) – IP, Chorus. 3.2.9. Alternativas de Implementação Genericamente temos 3 formas de integração das funções de comunicação no modelo computacional de um SO multiprogramado: - Funções E/S genéricas - Funções específicas dedicadas apenas à interface com os protocolos de transporte - Inclusão no mecanismo de intercomunicação entre processos do SO. A primeira tornou a comunicação num gestor de periféricos, com todos os problemas de normalização que daí advinham. A normalização veio via Unix que adoptou a interface do sistema de ficheiros. Mas esta solução tem severa limitação, devido às operações disponíveis nas interfaces de E/S serem insuficientes face Às necessidades dos protocolos de comunicação. enviar e receber tudo bem, mas estabelecimento de ligação, parametrização ou recepção múltipla... A solução é função de parametrização genérica, ex. ioctl do Unix para tudo, mas isso torna a programação pouco clara e introduz facilmente erros. A alternativa é a utilização de biblioteca dedicada, que esconde detalhes das E/S e dos protocolos de transporte (ex. NetBios e DOS), mas obriga a distinguir entre comunicação remota e local, o que diminui portabilidade. Os sockets Unix são uma tentativa da compatibilização das funções de comunicação com as E/S, mas também acaba por ser híbrida. Uma evolução tenta estender o IPC local, de forma coerente. A desvantagem desta aproximação é que cada SO impõe uma estruturação própria das mensagens e se pretende ligar máquinas com SO diferentes. Verifica-se o habitual compromisso entre eficiência e coerência. Nos sistemas resultantes da evolução de SO centralizados manteve-se a distinção entre mecanismos IP locais e as interfaces de comunicação distribuída. Ex. Unix V.4 tem IPC e TLI.

Nos SO estruturados com base em micro-núcleos como, p.ex. o Mach e o Amoeba procurou-se evitar esta duplicidade, mas, hélas, são incompatíveis. Vamos ilustrar estes conceitos com 3 interfaces: os sockets são 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 não procurou reutilizar a interface das E/S ou dos ficheiros. Finalmente o Mach IPC corresponde a uma abordagem integrada, onde a comunicação local e remota foram consideradas como idênticas. 3.3. Interfaces de Sockets 3.3.1. Caracterização dos Sockets Unix, desde início teve mecanismos para suporte da distribuição. A de Berkely (1982) inovou com os sockets como interface de comunicação. No Unix V foi para a API TLI (Transport Layer Interface). Os sockets propunham-se dar resposta a: - Independência do Protocolo (de transporte); - Transparência: a comunicação não deve depender da localização dos processos, devendo ser idêntica para o caso local ou distribuído. - Compatibilidade: O novo mecanismo devia inserir-se na interface clássica de comunicação e E/S do Unix. Os sockets apresentam interface baseada nos descritores de ficheiros (evolução dos pipes). A independência materializou-se na noção de domínio. Expls. de domínios: - Domínio Internet – TCP e UDP - Domínio Unix – Permite a comunicação entre processos numa única máquina, sendo semelhante aos pipes sem nome. - Domínio Xerox NS Na criação do socket, para além da especificação do domínio é especificado o tipo de serviço pretendido: - stream – canal com ligaçãp, bidireccional, fiável e com garantia de ordem. A interface é do tipo sequência de octetos tal como nos pipes ou ficheiros. - datagram – canal sem ligação, bidireccional, sem... - sequenced packet – canal sem ligação, mas com envio síncrono que garante entrega das mensagens. - raw – acesso directo aos mecanismos de comunicação. Ex. ao IP. Nem todas as combinações de tipo e domínio têm sentido (ver tabela na pg. 108) Os identificadores de transporte associados aos sockets são diferentes para cada domínio (com esquema de endereçamento próprio). A estrutura genérica do identificador do socket definido em <sys/socket.h> É: struct sockaddr { u_short family; /*definição do domínio*/ char sa_data[14]; /* endereço definido no domínio*/ No domínio Unix, os nomes são caminhos de acesso com a estrutura habitual (ex. /tmp/servidor) struct sockaddr_un { u_short family; /*definição do domínio*/ char sun_path[108]; /*caminho de acesso*/ No domínio Internet o identificador corresponde ao endereço de transporte dos protocolos UDP e TCP, descrito no capítulo anterior. Endereço IP da máquina (32 bits) e o número de um porto de transporte codificado com 2 octetos.

1.5 Resumo Os SO sofreram uma evolução natural, resultante do grande desenvolvimento tecnológico das duas últimas décadas. Apesar de se poderem considerara múltiplos factores para esta evolução, salientamos quatro que nos parecem mais decisivos: 1 – As redes de computadores tiveram uma evolução significativa. Nas redes de grande escala (WAN), a evolução resultou da oferta pelos operadores de telecomunicações de redes de dados com elevada fiabilidade e custos mais reduzidos que as linhas dedicadas. Esta evolução 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 públicas é particularmente importante o papel das redes com uma filosofia aberta de gestão como a Internet. Esta rede adquiriu recentemente uma notoriedade que a coloca como o meio mais adequado para a introdução de reais aplicações distribuídas. Uma outra vertente da evolução da tecnologia das comunicações foi a das redes locais – LAN. Esta forma de interconexão de computadores iniciou-se na década de 80 e evoluiu rapidamente, em particular na redução de custos das interfaces que permitem hoje em dia que seja margina o custo de interligação dos computadores em rede local. 2 – Os computadores pessoais foram os equipamentos com maior impacto nos sistemas informáticos. Estes equipamentos de reduzido custo revolucionaram a experiência do uso da informática pelos utilizadores. A capacidade de processamento e armazenamento local, aliada a uma interface cada vez mais ergonómica, obrigou a repensar os sistemas de informação centralizados das décadas anteriores. Apesar de o SO MS-DOS ser muito rudimentar, dificultando a sua interligação coerente em rede, o enorme mercado motivou o desenvolvimento de diversas soluções 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 à pressão dos grandes utilizadores que pretenderam não ficar totalmente dependentes dos seus fornecedores de hardware que ofereciam SO proprietários, aos quais ficavam indissociavelmente ligadas as aplicações. 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 fácil das aplicações e criaram um mercado competitivo. Uma das áreas mais influenciadas pela filosofia dos sistemas abertos foi a comunicação entre computadores, pois os problemas colocados pela interligação de sistemas heterogéneos obrigaram a soluções multivendedor. As redes actuais de maior sucesso, quer públicas quer locais, baseiam-se em normas adoptadas por toda a indústria. 4 – As arquitecturas multiprocessador são um meio natural para aumentar o desempenho dos processadores e justificam-se para as máquinas que actuam como grandes servidores de informação. As arquitecturas dominantes são os multiprocessadores simétricos de memória partilhada. Os multiprocessadores de memória distribuída interligam, sobre uma rede local ou um sistema de interconexão de alto débito, máquinas independentes. A sua influência na evolução dos sistemas operativos distribuídos tem sido grande. Os sistemas distribuídos resultam da confluência destes factores tecnológicos e procuram dar resposta a um conjunto de requisitos colocados pelos utilizadores, pelos programadores e pelos gestores de sistemas informáticos. Os utilizadores pretendem: transparência que lhes evite terem de conhecer diferentes interfaces para os objectos dos sistemas; mecanismos eficientes para partilha de informação; suporte para a comunicação entre utilizadores humanos como o correio electrónico, as news, etc. Todas estas funcionalidades devem ser acompanhadas de uma maior qualidade do sistema, em particular de uma acrescida ergonomia, segurança, fiabilidade e disponibilidade. Para os programadores, os requisitos são:

A necessidade de interfaces normalizadas (API) que permitam o desenvolvimento e transporte das aplicações; ambientes de programação que escondam os detalhes da distribuição, dos mecanismos da tolerância a faltas e de segurança, simplificando o desenvolvimento das aplicações. Na óptica do gestor de recursos informáticos, os requisitos principais relacionam-se com a capacidade de evolução do sistema. Os sistemas distribuídos facilitam uma evolução modular e garantem a extensibilidade do sistema. Um requisito importante é a capacidade de gestão global do sistema, não obrigando a numeroso pessoal de suporte. Com é natural, a distribuição introduz um conjunto de problemas ou agudiza outros: comunicação por mensagem – a fiabilidade e o determinismo da comunicação por mensagem é totalmente diferente da habitual nos sistemas centralizados onde se efectua com base numa memória partilhada; modelo de faltas – o modelo de faltas é mais complexo, porque existem mais componentes e o padrão de faltas é mais complexo pela total independência dos sistemas; sistema operativo repartido – a distribuição implica a cooperação entre vários núcleos de SO, não existindo uma memória central para comunicação e sincronização. Numa rede é difícil criar mecanismos de sincronização atómicos, devido às características temporais dos meios de comunicação e pelas hipóteses de falha. A informação de gestão (nomes de utilizadores, ficheiros, periféricos) encontra-se dispersa por numerosas máquinas, sendo necessário ao sistema executar protocolos entre múltiplos nós para efectuar determinadas operações; segurança – nos sistemas multiprogramados, o núcleo 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 princípio de suspeição mútua em relação a todos os interlocutores nas redes; heterogeneidade – as diferenças 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 têm impacto sobre o desempenho. O desafio é construir sistemas distribuídos que ultrapassem os problemas sem sacrificar o desempenho. Com é natural, os problemas mencionados anteriormente têm solução e a distribuição tem interessantes vantagens potenciais. Algumas são evidentes como adequação à repartição geográfica, modularidade, extensibilidade. Outras são mais complexas de perceber como: maior disponibilidade – devido à existência de múltiplas máquinas independentes permitindo replicar a informação ou as aplicações; melhor desempenho devido à utilização das máquinas mais adequadas a cada tipo de processamento; custo mais reduzido – decorrente da utilização de computadores pessoais como interface para os servidores. Existem múltiplas formas de conceber os mecanismos de suporte à construção de aplicações distribuídas. A forma mais simples é apenas oferecer os mecanismos básicos de intercomunicação entre processos. O programador tem neste caso de desenvolver as aplicações cliente e servidor e os protocolos de aplicação. Apesar desta solução ser fácil de implementar nas máquinas existentes, tem diversas desvantagens: limitada reutilização de código e protocolos; dificuldade de normalização; desempenho limitado devido à implementação fora do núcleo. Existem, contudo, algumas vantagens neste mecanismo: simplicidade – os programadores apenas têm de conhecer interfaces de comunicação que não são muito diferentes das existentes nos sistemas centralizados; facilidade de transporte para outras arquitecturas - como os mecanismos utilizados não recorrem praticamente ao SO, o transporte das aplicações é simples.

Um nível mais elaborado de suporte é oferecido pelas plataformas cliente/servidor. Não existe uma definição clara e consensual de qual é a funcionalidade destas plataformas, apesar de serem vulgarmente considerados os seguintes serviços: comunicação entre clientes e servidores por chamada de procedimento remoto; gestão de nomes; mecanismos de segurança para autenticação e cifra das comunicações; suporte a transacções distribuídas; sistema de ficheiros distribuído. A componente de base destas plataformas é a comunicação utilizando o paradigma de chamada remota de procedimento. Este mecanismo procura simplificar a interacção remota, assemelhandoa sintáctica e semanticamente à chamada de procedimento. Os SO distribuídos baseiam-se na interligação de todas as componentes do sistema: gestão de memória, gestão de processos, etc. O sistema funciona de um modo homogéneo, permitindo explorar as várias componentes hardware da rede como se de uma só máquina se tratasse. Representa o objectivo mais ambicioso dos SO distribuídos. Para que todos os sistemas possam ser interligados desta forma, é necessário que ofereçam interfaces idênticas, o que obriga a que diversos fabricantes tornem os modelos dos seus sistemas compatíveis. Para além do suporte à distribuição, uma característica que tem marcado o desenvolvimento dos novos SO é a tentativa de modularização da sua estrutura interna. Uma tendência geral é a estruturação interna dos sistemas em micro-núcleo, assegurando as funções de gestão de processos e de comunicação, e em servidores que executam as restantes funções. A própria comunicação entre o SO e o núcleo efectua-se por mensagem, permitindo a sua fácil adaptação à distribuição ou às arquitecturas multiprocessador. As arquitecturas multiprocessador tiveram uma influência grande na evolução técnica dos SO. Podemos dividir esta arquitectura em 2 grandes grupos: os de memória partilhada e os de memória distribuída. Na arquitectura de memória partilhada, os processadores estão ligados à mesma memória através de um bus partilhado. Os processadores têm uma cache local onde guardam as palavras de memória recentemente acedidas. A coerência das caches é mantida pelo hardware de gestão de bus partilhado. Estas máquinas obrigaram à paralelização do SO, ou seja, a reduzir a um grão muito fino as secções críticas existentes no código do sistema. Como é evidente, esta operação é complexa, sobretudo quando efectuada em sistemas existentes como o Unix, onde, devido ao pseudoparalelismo, o núcleo tinha extensas secções críticas. Uma outra linha de evolução é criar mecanismos a nível de utilizador para explorar o paralelismo real dos multiprocessadores. Certos algoritmos podem ser optimizados se executados em paralelo por várias tarefas dentro do mesmo processo, em que todas as tarefas partilham o mesmo espaço de endereçamento. as tarefas (threads) passam a ser entidades geridas pelo SO que efectua o respectivo escalonamento, tirando partido dos diversos processadores. Os multiprocessadores de memória distribuída são compostos por processadores com memória privada e interligados por uma rede de alto débito. Nestas máquinas, o SO é um sistema distribuído, onde todas as componentes habituais (processos, ficheiros) podem ser geridos de forma distribuída. A comunicação por mensagem é semelhante à existente nas redes de dados, mas é claramente optimizada para tirar partido da rede de interligação de alto débito subjacente à arquitectura. Normalmente, os fabricantes destes sistemas procuram oferecer uma interface semelhante a sistemas multiprogramdos clássicos, com o Unix, escondendo os detalhes da arquitectura.

CAP. 2 As redes de dados têm características estruturais que as tornam muito mais complexas do que as E/S, nomeadamente: escala – o número de unidades interligadas é muito superior a qualquer sistema de periféricos; heterogeneidade – as redes interligam máquinas com processadores e Sos diferentes e são elas próprias heterogéneas devido a diferentes meios físicos, técnicas de transmissão e multiplexagem, técnicas de gestão, etc. Múltiplas razões justificam a enorme diversidade de arquitecturas das redes: o interesse dos fabricantes de desenvolverem redes que prolongassem as suas arquitecturas proprietárias; as limitações tecnológicas associadas à banda de transmissão e atenuação em função da distância; o custo das diferentes tecnologias; os requisitos das aplicações que diferem quando se considera dados impulsionais, voz, imagens ou vídeo. Devido aos elevados investimentos efectuados nas linhas telefónicas em cobre, os operadores procuram reutilizá-las para redes de dados. A elevada atenuação e limitações da banda passante dos cabos em cobre introduziram limitações à arquitectura das redes. Para pequenas redes, a utilização de meios físicos mais eficazes e a possibilidade técnica de efectuar a gestão de modo mais eficiente conduziram ao desenvolvimento de redes de elevado desempenho e custo reduzido. estas diferenças tecnológicas e as diferenças de exploração das redes públicas e redes privadas conduziram a uma segmentação 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 início, interesse em encontrar modelos que subdividissem a complexidade considerando diversos níveis. Uma subdivisão natural é entre a arquitectura física e a arquitectura lógica. A primeira prende-se com as topologias de interligação e com as características físicas dos meios de transmissão. A segunda procura criar uma rede com um conjunto de características susceptível de suportar eficientemente as aplicações. A arquitectura física relaciona-se com a topologia e as tecnologias de transmissão. As topologias habituais são: 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 redundância na ligação entre nós. Historicamente, o cobre foi o meio físico mais usado, mas progressivamente tem vindo a ser substituído nas WAN por fibras ópticas que proporcionam maior velocidade de transmissão, menor atenuação e maior fiabilidade. Nas LAN utilizam-se par entrançado, cabos coaxiais e fibras ópticas Para enquadrar a arquitectura lógica, foram criados vários modelos de referência. O mais divulgado é o modelo OSI, da organização internacional de normalização, a ISO. Este modelo, do início da década de 80, reflecte a tecnologia da época e tem diversas limitações amplamente divulgadas, contudo, continua a ser a referência utilizada quer na área da Informática, quer em Telecomunicações. Um outro modelo importante é o que adoptou a Internet, designado por modelo catnet. Neste modelo considera-se a rede como uma interligação de redes independentes. Diversos fabricantes também propuseram os seus modelos, a maioria dos quais sem interesse actual, com excepção da arquitectura SNA da IBM que influenciou significativamente o modelo OSI e tem ainda considerável impacto em alguns domínios como nos sistemas transaccionais. O modelo OSI estrutura-se em níveis aos quais está associada uma interface de serviço, correspondente à funcionalidade que disponibiliza aos níveis superiores e um protocolo que define o formato e o significado das mensagens. Em cada sistema existe um fluxo de comunicação na vertical através das interfaces de serviço dos vários níveis de comunicação. Entre sistemas, a comunicação é efectuada através dos protocolos dos níveis correspondentes nos sistemas. Os protocolos podem ser com ligação ou sem ligação. Nos protocolos com ligação pretende-se emular um canal virtual ponto-a-ponto entre os interlocutores. A comunicação decorre em 3 fases: estabelecimento da ligação, conversação, corte da ligação. Nos protocolos sem ligação apenas existe a fase de conversação. Ambas as soluções apresentam vantagens e inconvenientes. os protocolos com ligação podem aproveitar os estabelecimento da ligação para negociar parâmetros

de serviço, podem controlar erros e sincronização, dando maiores garantias aos níveis superiores. Os protocolos sem ligação são mais simples e podem resultar em mecanismos mais eficientes de comunicação, por não terem necessidade de passar por uma fase prévia de estabelecimento. A interface de serviço é definida com base num conjunto de primitivas abstractas: Pedido, Indicação, Resposta, Confirmação. A distinguir entre o serviço prestado e o protocolo implementado em cada nível, pretendeu-se tornar a arquitectura flexível e modular. No entanto, as implementações reais raramente conseguem garantir um completo isolamento entre protocolo e interface de serviço, em especial no que se refere aos aspectos de configuração local e de endereçamento. O modelo OSI estrutura-se em 7 níveis. Os níveis inferiores estão mais próximos do meio físico de comunicação e os superiores das aplicações e utilizadores finais dos serviços de comunicação. O nível físico tem por função transmitir correctamente um bit sobe o meio físico de interligação; o nível de ligação de dados utiliza os serviços do nível físico para o envio de tramas (frames) entre duas máquinas na mesma rede física; o nível rede é responsável por suportar os mecanismos necessários ao encaminhamento (routing) dos pacotes de dados entre quaisquer sistemas ligados à rede, independentemente da rede física; o nível de transporte oferece um serviço de transmissão de mensagens entre dois sistemas extremo a extremo, normalmente com várias classes de qualidade de serviço. O serviço de transporte caracteriza-se por um conjunto de facilidades: com ligação/sem ligação; garantia de entrega fiável da mensagem; fragmentação; controlo de fluxo; mecanismo de janela; garantia de ordem. A rede Internet tem por base um modelo de concatenação de redes denominado (con)cate(nation) net ou catenet. Esse modelo assume que existe um grande número 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 passarão por uma série de redes, em trânsito, até ao destino. O processo de encaminhamento é transparente para o utilizador, bastando-lhe conhecer o endereço Internet do destino. A Internet parte de uma camada nuclear para toda a arquitectura: o nível de interligação 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 são a tecnologia mais importante na interligação de sistemas computacionais. Estas redes de custo muito reduzido são as principais responsáveis pela evolução das arquitecturas centralizadas para as distribuídas. Devido à enorme diversidade de tecnologias disponíveis, era fundamental definirem-se normas que permitissem o desenvolvimento de circuitos integrados indispensáveis para reduzir o custo das interfaces. O IEEE encarregou-se de efectuar a normalização numa comissão designada 802, nome por que ficaram conhecidas as normas aí especificadas. Na análise dos mecanismos mais eficientes para implementação de redes locais, foi patente que a independência entre o nível físico e a ligação de dados do modelo OSI não era possível. Foi definido um subnível designado por Mecanismo de Acesso ao Meio – MAC (Medium Acess Control) que controla a partilha do meio e que, apesar de logicamente pertencer ao nível de ligação de dados, não pode ser separado do nível físico para que foi definido. Existem várias alternativas para efectuar a partilha do meio: Multiplexagem na Frequência (FDM), define-se um espectro de frequências e atribui-se a cada canal de comunicação uma frequência própria; Multiplexagem no Tempo (TDM), o meio físico é partilhado com base numa atribuição de intervalos de tempo a cada emissor de informação. Existem várias formas de controlo da atribuição dos intervalos aos vários emissores: Divisão no Tempo Síncrona – intervalos de duração fixa, síncronos com um relógio central são atribuídos aos emissores; Divisão Temporal Assíncrona – neste caso, podem-se considerar 3 políticas de gestão: Aleatória; Controlada de forma distribuída; Controlada de forma centralizada.

As redes locais mais conhecidas são as Ethernet – características: bus, cabo coaxial, TDM com controlo aleatório, velocidade de transmissão de 10 Mbits/s; o Token Ring – características: anel, TDM, com controlo distribuído, 16 Mbits/s. Nas redes de alta velocidade, FDDI é uma das redes mais utilizadas para espinha dorsal de hierarquias de redes locais – características: duplo anel, fibra óptica, TDM com controlo distribuído, 100Mbits/s. O nível rede caracteriza o serviço oferecido nas redes de grande escala. Existem 2 filosofias de base na definição deste nível: estabelecimento de um canal virtual entre os dois nós que pretendem comunicar antes de se iniciar a fase de transferência de informação. O circuito virtual garante controlo de erros, fluxo e sequencialidade; comutação de pacotes que são encaminhados dinamicamente na rede até ao seu destino final, não procurando o nível rede assegurar funcionalidade suplementar que, caso seja necessária, deverá sempre ser efectuada a nível do transporte. A expressão prática desta diferença é ilustrada pelos dois tipos de protocolos mais utilizados nas redes de grande escala: X.25 e a rede IP. A redundância funcional da pilha de protocolos X.25 e a óptica da interligação de redes, em vez da interligação de máquinas, dão uma maior versatilidade e eficiência ao modelo Internet, consubstanciado no protocolo IP que se apresenta hoje como proposta com maior potencial no domínio da interligação de redes.

CAP 3. Os protocolos são fundamentais para que a comunicação se possa efectuar de forma normalizada e eficiente entre máquinas heterogéneas. Contudo, para que esta infra-estrutura de comunicação seja útil, é necessário incorporá-la no modelo de programação, integrando as funções de comunicação no ambiente de desenvolvimento das aplicações. A interface é uma biblioteca de funções ou API (Application Programming Interface) que permite interactuar com um determinado nível do modelo de comunicação, normalmente o transporte. As interfaces tratadas neste capítulo permitem um grau de abstracção em relação aos protocolos de comunicação, mas são normalmente o equivalente funcional dos mecanismos existentes nos protocolos de transporte. A comunicação pode modelizar-se como interacção entre um processo produtor que gera a informação e um processo consumidor que irá tratá-la. A informação transmitida é genericamente designada por mensagem, devendo ser interpretada segundo um protocolo de alto nível, acordado entre o produtor e o consumidor. A transferência de informação é suportada por um canal, uma abstracção dos mecanismos de transporte que suportam a comunicação física. O canal de comunicação tem duas extremidades designadas portos que são objectos do SO e constituem a interface do sistema com os programas aplicacionais. Na intercomunicação entre processos numa única máquina, o canal é implementado por zonas de memória partilhada, gerida pelo núcleo, oferecendo uma elevada fiabilidade, o que não se passa num ambiente distribuído. O desempenho é também sensivelmente menor, sendo mais penalizado quanto menor for o débito das redes subjacentes. O modelo de canal projecta-se directamente nos conceitos discutidos no capítulo anterior para o nível de transporte: com ligação – estabelecimento prévio do canal entre os dois processos interlocutores antes da troca de informação; sem ligação – o canal é conceptualmente estabelecido apenas para o envio de uma mensagem. Os portos são objectos do sistema a que está associado um espaço de nomes e um conjunto de funções. Os portos são normalmente referenciados por dois identificadores, um local ao sistema ou mesmo local ao processo e outro correspondente ao endereço de transporte que permite endereçar o porto na rede de comunicação. Para além das funções de envio e recepção, existem funções específicas para criar, eliminar e parametrizar os portos. A funcionalidade destas rotinas é diferente, consoante o canal se estabelece de forma permanente ou temporária. Se existe ligação, os portos do emissor e receptor ficam implicitamente associados, assumindo-se como as extremidades do canal bidireccional através do qual se enviam e recebem dados. As mensagens podem ser individualizadas ou sequências de octetos (byte stream). O formato das mensagens pode ser imposto pelo sistema ou pelo protocolo de alto nível entre aplicações. A imposição de formatos prédefinidos na interface de comunicação é uma restrição suplementar ao programador, sendo de uma forma geral evitada. No envio de mensagens, é preciso definir qual o tipo de serviço oferecido pelo canal quando a mensagem lhe é entregue. As semânticas habituais são: assíncrona – a função copia informação da mensagem para os tampões do protocolo de transporte e retorna depois de iniciar a operação de envio. O processo emissor é desbloqueado assim que a função retorna do núcleo, mas não tem qualquer garantia que a mensagem chegou ao seu destino; síncrona – o processo emissor fica bloqueado até que o porto destinatário confirme que recebeu a mensagem; cliente/servidor – o processo fica bloqueado até receber a mensagem de resposta. A semântica da função receber é retirar a primeira mensagem existente no porto ou, caso nenhuma esteja presente, bloquear o processo. Se o servidor estabelecer simultaneamente canais com vários clientes, coloca-se o problema típico de múltiplos pontos de sicronização. A existência de múltiplos canais relaciona-se com o modelo com ou sem ligação. Se o canal for sem

ligação, pode usar-se um porto para receber as mensagens de todos os processos interlocutores. Num canal com ligação o porto fica associado ao canal, pelo que múltiplas ligações obrigam a utilizar múltiplos portos. A solução para este problema é criar um mecanismo de recepção múltipla sobre um conjunto de portos. Na recepção múltipla, um processo bloqueia-se até que um dos portos receba uma mensagem que lhe é destinada. É frequente a possibilidade de associar à primitiva de recepção uma temporização. A sincronização das primitivas de envio e recepção 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 programação de processos que actua, como servidores. A recepção múltipla resolve o problema dos múltiplos pontos de sincronização, 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 vários processos em paralelo; esta solução obriga, porém, à partilha de estruturas de dados entre os processos (memória partilhada e sincronização). A solução mais interessante é dispor de um modelo multitarefa no servidor que permita a execução concorrentemente de múltiplos fios de execução que se sincronizam no acesso a variáveis partilhadas. As faltas de comunicação podem ter numerosas origens. As mais frequentes relacionam-se com a impossibilidade de entrega da mensagem, devido a quebra do canal de comunicação. A detecção da falta é diferente, consoante se utiliza um canal com ou sem ligação. No primeiro caso, o protocolo de transporte é responsável por detectar se o canal de comunicação está activo, podendo, por exemplo, assinalar imediatamente a quebra do canal. No caso do canal sem ligação, os protocolos datagrama não implementam normalmente um mecanismo de recuperação das faltas de comunicação. Quando é detectada uma falha, esta situação tem de ser transmitida ao processo. A forma mais simples é através de um valor de retorno da execução da função que indique o estado da execução. Esta forma de assinalar erros existe genericamente para indicar os erros de utilização (ex: tentar ligar um porto já em ligação). Contudo, como as operações de transmissão são, na maioria dos caso, assíncronas, para assinalar uma falha é necessário recorrer a um mecanismo de excepções assíncronas. Uma propriedade interessante de alguns sistemas de comunicação é a possibilidade de enviar uma mensagem em difusão a múltiplos receptores. Do ponto de vista do programador a difusão pode conduzir à simplificação de diversos algoritmos, por exemplo: localização, sincronização, replicação de dados, alertar simultaneamente vários processos para um acontecimento do sistema, etc. Devido ao interesse dos algoritmos baseados na difusão, foram propostos mecanismos de difusão mais restritos a grupos de portos. No mecanismo de difusão em grupo existe uma distinção importante entre os que garantem entrega fiável (difusão atómica) a todos ou a nenhum dos participantes no grupo e aqueles que apenas enviam a mensagem numa base do melhor esforço, mas que não asseguram que todo o grupo a recebeu. Considerámos três formas de integração das funções de comunicação no modelo computacional de um SO multiprogramado: funções de E/S genéricas; funções específicas dedicadas apenas à interface com os protocolos de transporte; extensão do mecanismo de intercomunicação entre processo (IPC) do SO. A limitação das operações disponíveis nas interfaces de E/S, face às necessidades dos protocolos de comunicação, é a maior dificuldade na sua utilização directa. As funções de E/S só se adaptam bem às operações simples de enviar e receber. A alternativa é a utilização de uma biblioteca dedicada, uma solução de implementação simples que permite oferecer uma interface coerente que esconde os detalhes das E/S e dos protocolos de transporte (ex: NetBios). Contudo, não é genérica, obrigando a distinguir à partida as interacções remotas e locais. A integração das funções de comunicação no IPC permite eliminar as bibliotecas de interface específicas, tornando o modelo de programação totalmente coerente. Uma das desvantagens desta aproximação é a estruturação imposta pela organização interna de um dado SO que torna o

protocolo do IPC proprietário. Actualmente, apenas é utilizado em sistemas distribuídos experimentais. Os sockets podem ser considerados como uma evolução dos pipes, a que foram adicionados os mecanismos de gestão dos canais e de gestão de nomes que permitem a comunicação entre processos num ambiente distribuído. A noção de domínio permite garantir alguma independência entre o modelo de comunicação das aplicações e o nível de transporte. Exemplos de domínios são: Internet; Unix; NS/Xerox. Na criação do socket, para além da definição do domínio, é especificado o seu tipo que tem a ver com a qualidade de serviço pretendida. Essencialmente, define se o canal é estabelecido de forma permanente ou temporária: stream; datagram; sequenced packet; raw. Os sockets são criados com a chamada socket que devolve um índice para um descritor de ficheiro aberto. para o socket ser endereçável pelos restantes processos, é necessário associarlhe um nome global, utilizando a função bind. Na utilização típica dos sockets com ligação, o servidor cria um socket e atribui-lhe um nome para que os clientes possam pedir o estabelecimento se uma ligação. Antes de aceitar ligações, indica a sua disponibilidade para receber chamadas através da primitiva listen. A função accept bloqueia o servidor até à recepção de pedidos de ligação. esta primitiva tem uma semântica complexa: quando a ligação é estabelecida, o sistema cria um novo socket que ficará associado ao novo canal de comunicação, deixando livre o socket inicial para continuar a receber pedidos de ligação. Do lado do cliente, a criação do socket é semelhante. O pedido de estabelecimento de uma ligação é efectuado pela função connect. Na utilização dos sockets sem ligação, a interface é semelhante à das caixas de correio habituais nos sistemas de intercomunicação entre processos. As funções sendto e recvfrom permitem enviar e receber mensagens. A função select indica ao sistema que o processo pretende ficar bloqueado até que uma operação ou várias operações de recepção ou envio se tenham realizado. As operações são identificadas pelo descritor de ficheiro a que estão associadas. Apesar de ter sido desenvolvida para os sockets, é de utilização geral para todas as funções de E/S. No texto efectua-se ainda uma comparação da interface de sockets, com a evolução proposta na versão V do Unix, a interface TLI. Existem diversos mecanismos de comunicação para redes de PC, por exemplo: NetBios; Lan manager; Netware; PC/NFS; Winsocket. Apesar de terem entre eles diferenças significativas, todos procuram oferecer uma interface de programação para aplicações distribuídas, onde é possível reconhecer os elementos do modelo de comunicação que descrevemos. O NetBios é interessante porque corresponde a uma interface de comunicação amplamente divulgada, também oferecida pelo Lan Manager e pelo Netware. O NetBios é realmente uma interface de comunicação, ou seja, não há um protocolo único, existindo diferentes implementações para redes diferentes. Contudo, a interface é idêntica permitindo o transporte das aplicações. Apesar de muito simples, existe no NetBios a maioria dos mecanismos que descrevemos neste capítulo (canal com e sem ligação, difusão, recepção múltipla). O Mach insere-se na tendência de estruturação dos SO em que se procura isolar o núcleo, com uma funcionalidade básica, dos serviços oferecidos pelo SO. O núcleo ou micro-núcleo apenas executa os aspectos básicos: gestão de tarefas (despacho e escalonamento); intercomunicação entre tarefas (IPC); interface ao hardware da máquina. Os conceitos relevantes no sistema IPC são os portos e as mensagens. Um porto é um objecto do núcleo que representa uma extremidade de um canal de comunicação. Os portos são equivalentes a uma caixa de correio residente no núcleo e que possui um tampão para o armazenamento de mensagens. os portos são 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 utilização. Os portos são assim simultaneamente os objectos de comunicação, mas também o sistema de designação das entidades do núcleo. As mensagens são estruturas tipificadas que descrevem para cada campo qual o tipo de dados que é transmitido. A passagem de apontadores na mensagem permite a transferência de blocos de memória por referência. O SO encarrega-se de actualizar as tabelas de páginas dos processos, permitindo que a informação possa ser transferida sem ter de efectuar cópias do espaço de endereçamento da tarefa emissora para o núcleo e deste para a tarefa receptora. O envio e recepção de mensagens é efectuado por uma função única, o mach_msg, que tem uma estrutura relativamente complexa tendo sete parâmetros. A semântica de envio pode ser assíncrona ou cliente-servidor. Para permitir a recepção múltipla, existe o conceito de conjunto de portos (port set) que agrupa diversos portos. Em conjuntos de máquinas que tenham como sistema o Mach, o IPC permite a intercomunicação entre processos que se executam em máquinas distintas. esta funcionalidade é proporcionada por um processo servidor, o NetMsgServer. Uma das facilidades providenciadas pelo sistema de comunicação é a independência de localização das entidades. O NetMsgServer é responsável por efectuar a correspondência entre os identificadores locais na máquina e os identificadores remotos. O NetMsgServer esconde do utilizador os detalhes associados aos protocolos de comunicação. Conceptualmente, os protocolos utilizados pelo NetMsgServer são transparentes para aplicações.

CAP. 4 – PROCEDIMENTOS REMOTOS A designação de arquitectura Cliente/Servidor estabelece a distinção entre dois tipos de processos com comportamentos diferentes: os servidores implementam um conjunto de funções de interesse geral para outros processos que remotamente lhes poderão aceder; os clientes efectuam a interface com os utilizadores, podendo executar parte das aplicações localmente e acedem remotamente a processos servidores para executarem as funções mais complexas de manipulação de dados, cálculo, entrada/saída, impressão, etc. Os servidores devem publicitar os seus serviços e quais os protocolos que podem ser utilizados. A identificação do serviço é lógica e não pressupõe uma localização física, possibilitando a mudança de máquina do servidor sem necessidade de modificar o código dos seus clientes. O cliente deve estabelecer uma ligação com o servidor (bind) antes de invocar um procedimento. O estabelecimento da ligação inclui normalmente várias operações: localização do servidor; estabelecimento de um canal de transporte; autenticação do cliente e/ou do servidor. O cliente invoca uma operação remota no servidor, enviando-lhe os dados necessários sobre o mecanismo de transporte de informação. A mensagem contém a identificação do procedimento remoto e os respectivos parâmetros. Do lado do servidor efectuam-se as operações inversas. O ciclo principal do servidor espera por uma mensagem, valida os dados recebidos, converte os parâmetros para o formato interno e chama o procedimento apropriado. Quando este retornar, os resultados são empacotados, de acordo com a estrutura prédefinida e transmitidos de volta ao cliente. Para simplificar a programação de aplicações baseadas no modelo cliente/servidor, foi desenvolvida uma metodologia de programação distribuída baseada na Chamada de Procedimentos Remotos que abreviaremos por RPC (Remote Procedure Call). O RPC permite uma transferência de controlo e dados entre espaços de endereçamento disjuntos quer residentes na mesma máquina quer em máquinas distintas. A ambição deste mecanismo é ser totalmente transparente em relação ao modelo de programação habitual, podendo idealmente desenvolver-se uma aplicação de forma independente da rede ou das máquinas que a irão suportar. Para que o modelo seja coerente, o RPC deverá estar integrado transparentemente num ambiente de programação. A transparência total é, contudo, difícil de atingir e para a analisar podemos subdividi-la nos aspectos: sintaxe da linguagem de programação; passagem de parâmetros; semântica de execução do procedimento; desempenho. A forma de especificação dos procedimentos remotos baseia-se numa linguagem de descrição 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 especificação de interfaces são uma versão simplificada de uma linguagem de programação dado que apenas necessitam da parte declarativa das linguagens. A sua gramática define a forma de especificar os procedimentos, os tipos de dados e a sua origem (entrada, saída, bidireccionais). Para gerar as rotinas de adaptação existe um compilador. Tem como entrada a especificação da interface e gera as rotinas de adaptação para o cliente e para o servidor. A saída deste compilador são ficheiros com o código fonte das rotinas, normalmente em C, que deverão ser em seguida compilados e interligados com o código das aplicações. A transparência sintáctica é fácil, as linguagens de especificação apresentam sintaxes próximas do C ou Pascal; a transparência semântica é mais complexa, porque as diferenças introduzidas pela separação dos espaços de endereçamento não podem ser totalmente escondidas, a transparência em termos de desempenho é naturalmente impossível, sendo muito diferente o tempo de execução no espaço de endereçamento de um processo, numa única máquina ou distribuída. Na declaração dos parâmetros, é necessário eliminar as ambiguidades na definição dos tipos de dados: apontadores genéricos, cadeias de caracteres ou vectores de tamanho variável. Devido à maioria das IDL ser inspirada na linguagem C, a definição dos tipos tem de ser enriquecida para permitir desambiguar as situações bastante permissivas existentes nesta linguagem. A transferência de parâmetros por referência não pode ser implementada de forma directa, devido ao RPC ser utilizado entre espaços de endereçamento disjuntos. A passagem por referência

obriga a copiar a estrutura no cliente para a mensagem, detectando a sua dimensão, e no servidor a reserva dinâmica da memória para onde irá ser copiada. Nos iniciais sistemas de RPC era restringida a utilização desta forma de transferência de parâmetros; contudo, esta limitação é demasiado restritiva na maioria dos sistemas onde a utilização de lista e estruturas de dados dinâmicas se adequa bem aos algoritmos. Existem vários problemas e soluções na passagem de parâmetros por referência que tem de ser convenientemente analisados em cada sistema de RPC. A heterogeneidade na representação de dados é um dos factores limitativos da transparência na interacção distribuída. A tipificação dos parâmetros na especificação da interface permite ao compilador introduzir no código das rotinas de adaptação as chamadas às funções de conversão, de acordo com um protocolo de apresentação de dados definido para o sistema de RPC. O desempenho é naturalmente muito diferente quando se considera a execução no espaço de endereçamento de um processo, numa única máquina ou distribuída. Este é um dos aspectos em constante evolução, fruto dos avanços tecnológicos. Contudo, nunca será possível esbater totalmente as diferenças, pelo que o programador terá de ter sensibilidade a estes condicionamentos, sabendo os limites da transparência em termos de desempenho. A chamada de procedimento remoto é uma abstracção lógica; na realidade, as chamadas remotas começam com uma chamada a um procedimento local que se encarrega de iniciar a invocação remota. Estas rotinas de adaptação (stub routines) têm um papel preponderante na arquitectura do sistema. No lado cliente, o procedimento de adaptação é responsável por: converter e empacotar os parâmetros numa forma apropriada para transmissão; enviar a mensagem para o servidor usando um serviço de transporte; esperar pela resposta do servidor. Quando esta for recebida, desempacota os resultados, convertendo-os para a representação local dos dados na máquina do cliente. Do lado do servidor, a rotina de adaptação tem finalidade simétrica. Se existir paralelismo no servidor é necessário introduzir nas rotinas de adaptação do servidor a sincronização compatível com os mecanismos de multiplexagem de contexto. As rotinas de adaptação recorrem a uma biblioteca de funções para todas as operações genéricas do sistema de RPC. As funções de biblioteca efectuam controlo da semântica da chamada remota, a conversão dos dados e a ligação aos mecanismos de transporte. Como é natural, as funções de suporte incluem também mecanismos para registo do nome nos servidores de nomes e para o tratamento de erros e excepções. A biblioteca de funções com as respectivas estruturas de dados globais constitui o ambiente de suporte (run-time) à execução do RPC que será carregado em memória com a aplicação distribuída. Antes da invocação de um procedimento remoto, o cliente tem de localizar o servidor e estabelecer uma sessão através de um protocolo de ligação (binding). O estabelecimento da sessão permite, em seguida, executar as operações remotas com uma latência reduzida. A forma como esta ligação se estabelece depende de diversas decisões de arquitectura (transporte com/sem ligação, servidor com/sem estado). Genericamente, podemos considerar os seguintes passos no estabelecimento da ligação: localização do servidor – os clientes contactam o servidor de nomes para determinar o endereço dos servidores que pretendem aceder; autenticação, dependendo das características de segurança, o servidor pode exigir ao cliente uma identificação segura, de forma a validar a sua identidade, o cliente pode também querer assegurar-se que o servidor é realmente o processo correcto e não outro que lhe tenha usurpado a identidade; estabelecimento da sessão, do lado cliente é preenchida uma estrutura com o canal associado ao servidor. No servidor poderá ou não existir uma estrutura que fique a referenciar o cliente. Quando esta estrutura é mantida, o servidor conserva o estado das ligações, alternativamente, o servidor não mantém estado, devendo, neste caso, utilizar canais de transporte sem ligação. A vantagem desta solução é que torna o servidor completamente independente dos clientes, podendo ser reinicializado sem qualquer precaução especial.

A execução da chamada remota pode considerar-se como a conjugação de três protocolos: protocolo de apresentação para resolver a heterogeneidade; protocolo de controlo da semântica de execução; protocolo de transporte para a transmissão de dados. O protocolo de controlo define a semântica de execução do procedimento. A semântica tem essencialmente a ver com a forma como são tratadas as faltas que podem surgir durante a execução de um procedimento remoto: a perda da mensagem inicial do cliente; perda da mensagem no interior do servidor; falha do servidor, tornando-se impossível determinar qual a situação da execução do procedimento invocado remotamente; perda da mensagem de resposta do servidor; o cliente aborta antes de ter processado a mensagem de resposta. As semânticas de execução da chamada remota habituais são: talvez (may-be) – não 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 não for recebida num intervalo de tempo prédeterminado, é reenviada a mensagem de invocação 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 semântica, o servidor deve apenas oferecer funções idempotentes, em que múltiplas execuções da mesma chamada são idênticas a uma só execução com os mesmo parâmetros; na semântica no-máximo-uma-vez (at-most-once), a operação remota é executada apenas uma vez ou poderá não ser executada se existirem faltas de paragem nas máquinas cliente ou servidor. O protocolo de suporte do RPC deve filtrar pedidos duplicados no servidor, confirmar todas as operações e manter as mensagens até ter a garantia da sua recepção correcta. O problema de garantir a semântica exactamente-uma-vez advém da impossibilidade de, no caso de um servidor falhar durante a execução de uma operação remota, saber exactamente o momento em que tal sucedeu e qual o estado em que ficou a execução da invocação. Para implementar uma semântica exactamente-uma-vez, são necessários mecanismos de tipo transaccional no servidor. O protocolo de apresentação tem de permitir às rotinas de conversão do receptor conhecer o tipo de dados presentes na mensagem. Existem duas soluções gerais: explícita – para cada dado ou bloco de dados de um determinado tipo é colocado na mensagem um descritor que identifica o tipo; implícita – na mensagem são enviados apenas dados, existindo convenções que permitem determinar as conversões a efectuar para cada tipo de máquina. O tratamento implícito tem duas variantes: considerar que existe uma forma canónica de transmissão, a qual deverá ser utilizada em todas as mensagens; enviar os dados na forma como estão representados na máquina de origem, incluindo na mensagem uma identificação do tipo de máquina. O receptor efectuará, se necessário, a conversão para o seu formato interno (receiver makes it right). esta solução evita o problema da possível dupla conversão, mas obriga a uma componente de gestão mais complexa pelo que a primeira alternativa é a mais utilizada. Um dos aspectos importantes do sistema é a optimização do desempenho dos servidores. A lógica do RPC adapta-se bem à utilização de tarefas no servidor que ficam a actuar como prolongamento do fio de execução do cliente. A existência de várias tarefas obriga a que o código da biblioteca de RPC contenha sincronização explícita para regiões críticas 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 idêntica ao caso sequencial. Realizações mais sofisticadas criam dinamicamente novas tarefas quando se esgotam as criadas inicialmente e terminam-nas quando não são mais necessárias. Há situações 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 situação requer que qualquer servidor se possa comportar também como cliente e que qualquer cliente possa ser também servidor. O primeiro caso não levanta grandes dificuldades, o servidor limita-se a chamar a rotina de adaptação do

serviço que pretende invocar. Permitir que um cliente se comporte também como servidor é mais complicado. O cliente tem de registar as chamadas em ricochete que quiser tratar, efectuando para isso um procedimento idêntico ao de um servidor quando regista um serviço no servidor de nomes. O desempenho de um sistema RPC é crucial para o desempenho global das aplicações que o utilizam. Apesar de ser um factor de segunda ordem quando se utiliza continuamente um servidor, o tempo de estabelecimento da ligação pode ter uma importância determinante se o cliente apenas efectua uma interacção com o servidor. Este é um dos argumentos na defesa da utilização de protocolos de transporte simples sem ligação que evitem o tempo inicial de estabelecimento do canal. O tempo de um RPC simples tem as seguintes componentes: tempo de conversão e empacotamento dos parâmetros de entrada e saída no cliente e no servidor; tempo de execução do SO: chamadas ao sistema, comutação de processos, etc.; tempo de transmissão das mensagens. Estas componentes são muito semelhantes às que foram consideradas na discussão sobre protocolos de comunicação. O que um sistema de RPC tem de particular é a sua utilização corrente como mecanismo de estruturação de aplicações distribuídas. Nestas, a esmagadora maioria das rotinas tem poucos parâmetros e envolve poucos dados, sendo a transferência maciça de dados muitas vezes efectuada por intermédio de protocolos especializados de transferência de ficheiros. Por este motivo, o desempenho de um sistema RPC é geralmente optimizado no sentido de diminuir a latência 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 distribuídos 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 informação. A Sun assumiu que o protocolo de controlo do RPC deveria ser independente do protocolo de comunicação, podendo usar-se transportes com ou sem ligação. No texto descreve-se: a linguagem de especificação, o tratamento da heterogeneidade, a biblioteca de suporte do RPC e o protocolo de comunicação.

CAP. 5 – GESTÃO DE NOMES Os nomes são fundamentais nos sistemas informáticos para permitir identificar, localizar e partilhar os objectos. Nos SO, para além destas funções, os nomes

Sign up to vote on this title
UsefulNot useful