SistDistrResLivro

7/29/2019 SistDistrResLivro

1/27

PREFCIOSistematizao e sntese dos problemas de base provocados pela distribuio, os modelosnecessrios ao enquadramento do problema bem como as solues da engenharia decomputadores. Enquadramento geral do problema com exemplos de sistemas que se encontramem uso.Quais so os novos desafios aos sistemas operativos? Do livro anterior vm 2: a distribuio earquitecturas multiprocessador. Estas mexem apenas com o ncleo, tcnicas portanto. a

distribuio introduz um conjunto de problemas de grande complexidade, derivada dos fenmenosde escala, da complexidade do modelo de faltas e da vulnerabilidade da segurana; o que temimplicaes directas na programao das aplicaes, pelo que o modelo tem de ser perceptvel aoprogramador.

Organizao do Texto...

1. INTRODUOOs desafios continuam a ser essencialmente os mesmos que estiveram na sua gnese dossistemas multiprogramados:

. Simplificar a interface com o sistema. Extrair o mximo rendimento da infra-estrutura de hardwareDepois dos 20 anos de consolidao, que terminaram nos anos 70, h um aperfeioamento eincluso das ideias base dessa investigao. Por ex. o Windows NT usa muitas das ideias doVMS. O papel charneira do SO entre o hardware, as redes de dados e as aplicaes, implicou queo sistema passasse progressivamente a englobar um nmero crescente de funcionalidadesrelacionadas com a distribuio, a gesto da informao e a interface homem-mquina. Da o usode Software de Sistema: ncleo + servidores, bibliotecas e protocolos.

1.1. Condicionantes da EvoluoH uma technology push e tb. as imposies dos utilizadores.

1.1.1. A TecnolgicaEvolues tecnolgicas mais marcantes:. As redes de computadores. Os computadores pessoais. Os sistemas abertos. As arquitecturas multiprocessador

Redes de ComputadoresOs pioneiros foram os bancos e transportadoras areas com a sua necessidade de sistemastransaccionais e interactivos.Os operadores pblicos na Europa introduziram servios de trx. de dados (ex. X-25) que permitems 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 deescala e segurana.RDIS (2x64Kbits).ATM que comea a ser usada nas redes pblicas.LANs (Ethernet, Token-Ring), com dezenas de Mbps.

Computadores PessoaisTecnologia Evoluo da Densidade (de 3

em 3 anos)Evoluo do Desempenho(tempo de ciclo)

Circuitos LgicosMemriasDiscos

DuplicaQuadruplicaDuplica

50% em 2 anos33% em 10 anos33% em 10 anos


2/27

A evoluo, em termos de hardware, com maior impacto em toda a estrutura da indstria foi aintroduo no mercado dos computadores pessoais.A existncia dos PCs acelerou, de forma considervel, a percepo da necessidade dos sistemasdistribudos.Os gestores de empresas passaram a considerar a hiptese de descentralizarem o seu suporteinformtico, 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 aplicaesinformticas, o modelo cliente-servidor.

Sistemas AbertosFabricantes de hardware desenvolviam o SO optimizado. Impossvel mudar de fornecedor. Apresso dos grandes utilizadores levou a criao de sistemas abertos: separao clara entre ohardware 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 atornar-se padro de facto.

Arquitecturas MultiprocessadorNa dcada de 70 e 80 eram especializados, hoje so correntes.As limitaes fsicas e custos de desenvolvimento que permitiram ir melhorando os acessos svolumosas bases de dados e interfaces complexos em computadores, esto a ser substitudospelas arquitecturas multiprocessador que aumentam o desempenho mantendo os ambientes dedesenvolvimento de software. Existem mltiplos esquemas para classificar os multiprocessadorescom base na forma como organizam os fluxos de dados e de instrues. Neste livro usaremos sas arquitecturas MIMD (Multiple Instruction, Multiple Data), que corresponde aos casos em quecada processador executa as suas instrues e trabalha sobre os seus dados. As MIMD podemser de dosi tipos: Memria Central Partilhada (+ vulgares e mais interessantes se pensarmos quese pensa em incluir, na mesma pastilha, vrios processadores) e as de Memria Distribuda.

1.1.2. Requisitos dos Utilizadores FinaisSer isolados dos detalhes complexos introduzidos pelos novos ambientes computacionais:Procura de transparncia: nomes, comandos e semnticas idnticas para todos os objectos sobcontrolo do SO (invocar aplicaes, aceder a ficheiros, utilizar perifricos, etc.). Isso requersistemas de nomes homogneos, interfaces simples, viso integrada dos vrios sistemas deficheiros, etc.A vantagem mais visvel ao utilizador com a distribuio a partilha de informao. Umaaplicao 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 adisponibilidade.

Requisitos do ProgramadorUm requisito, relacionado com os sistemas abertos, a simplificao da portabilidade deaplicaes atravs da definio de interfaces normalizadas ou API (Application ProgrammingInterface) com o software de sistema. Estas interfaces tm a ver no s com as funes de ncleodo SO, como com os mecanismos de comunicao, partilha de ficheiros, segurana, etc.O programador tambm pretende um ambiente de programao que lhe facilite odesenvolvimento 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 GestorA capacidade de evoluo modular e a extensibilidade. O aumento da fiabilidade edisponibilidade.Finalmente, importante a capacidade de gesto global do sistema que permita a reutilizaode equipamentos, a gesto integrada dos arquivos de informao, diminuio das tarifas.


3/27

1.2. Dificuldades e Vantagens Introduzidas pela Distribuio1.2.1. Os ProblemasComunicao Exclusivamente por MensagemNos sistemas multiprogramados, no ncleo toda a comunicao se efectua atravs de um espaode endereamento partilhado. Nos distribudos no h memria comum, introduz caractersticasdiferentes no modelo de comunicao.A taxa de erros, se bem que venha diminuindo, sempre maior que a interna a uma mquina.


4/27

Captulo 2...Nvel de SubredeA camada inferior do modelo Internet especfica a cada tecnologia fsica de transmisso, quedefine o encapsulamento do nvel superior.Na Internet apenas se define o protocolo entre camadas correspondentes, ou sej, o formato dasmensagens, 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 disponibilizadapara o nvel de interligao de rede.Embora no garanta opacidade entre nveis, tem a vantagem de as normas de encapsulamentotirarem partido das caractersticas especficas da tecnologia de subrede para implementaoeficiente. Existem especificaes de encapsulamento de pacotes do nvel IP para todas astecnologias (analgicas, ATM, etc.)

Nvel de Interligao de RedesDisponibiliza 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 esforopossvel). No necessrio este nvel na comunicao entre 2 ns da mesma subrede masuniformiza se utilizado.

Nvel de TransporteNa 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 ligaoque garante a retransmisso de pacotes corrompidos, a eliminao de pacotes duplicados eentrega dos pacotes pela mesma ordem; define o esquema de endereamento utilizando oconceito 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 AplicaoUtilizam 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 knownports).

2.5. Redes Locais de ComputadoresForam um dos factores decisivos na evoluo das arquitecturas centralizadas para distribudas.Caractersticas da normalizao: com partilha efectiva do meio fsico; apenas os dois primeirosnveis do modelo OSI; de 1 a 20Km.

Transmisso de difuso; em anel ou bus.

2.5.1. Controlo de Acesso ao Meio de ComunicaoUm dos primeiros problemas que se colocou na definio da norma foi a inadequao dasubdiviso considerada no modelo OSI entre nvel fsico e de ligao de dados e a estrutura decontrolo de trx. da maioria das redes locais. Para eficincia no podia haver independncia entrenvel 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 debanda larga. Desvantagens ao nvel de gesto e complexidade do equipamento, onde oestabelecimento de canais varia continuamente.

Multiplexagem no Tempo


5/27

a alternativa mais usada. O problema fundamental a resolver a forma como controlada apartilha entre os vrios emissores.

Multiplexagem no Tempo SncronaO tempo dividido em intervalos de durao fixa, sncronos com relgio central. Cada emissordispe 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 assimregular.

Multiplexagem no Tempo: Assncrona preciso algoritmo de atribuio de tempos:- Aleatrio;- Passagem de testemunho;- Controlo centralizadoO aleatrio baseia-se na reduzida probabilidade de dois emissores comearem, no memsoinstante, a trx. A estao que pretende emitir f-lo- assim que detectar que o meio est livre. Asoutras 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 anellgico. Apenas a estao na posse do testemunho pode emitir. As vantagens que a rede podeser mais facilmente modelizvel e, portanto, os dbitos podem ser assegurados atravs de gestode prioridades adequada. As desvantagens alguma complexidade para garantir o bomfuncionamento do testemunho na inicializao e em caso de falhas. Introduz atrasos no acessoquando 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 sepretendem 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 EthernetRemonta a 1974. a mais usada. IEEE 802.3.

Nvel FsicoA topologia de base bus e velocidade de trx. original de 10Mbps. O suporte fsico inicial era ocabo 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 utilizaode 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 defrequncia (Base ou Broad); D indica distncia mxima.Ex: 10BaseT 10Mbps, banda de base, 100 metros de comprimento mximo da ligao, parentranado.A topologia em bus tem sido mantida do ponto de vista conceptual, mas a definio de siatemasde cablagem estruturada conduziu a solues baseadas em concentradores (hub) que agregamvrias 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 MultipleAcess/Collision Detection).Normalmente as funes de comunicao so implementadas por hardware no comunicadorethernet. O funcionamento deste controlador pode resumir-se:


6/27

Aps activao da recepo, o comunicador analisa o endereo de destino das tramas quepassam no canal e recebe as que lhe so dirigidas ou as que tm o endereo de difuso. Paratrx., o comunicador constri a trama no tampo de trx., encapsulando os dados que lhe sofornecidos pelos nveis superiores. A partir deste momento, o comunicador escuta o trfego nobus (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 paraverificar 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 evitarsituaes ambguas, os pacotes tm um tamanho mnimo tal que o seu tempo de trx. o dobro dotempo de propagao.Antes de retransmitir aguarda um nmero inteiro de slot-time, num algoritmo Truncated BinaryExponential Backoff.

Formato das Tramas- Prembulo de 64 bits (101010101...1011) para sincronizao dos relgios e delimitao fsica datrama;- Endereos de 6 octetos para destino e origem;- Campo tipo, na norma Ethernet, identifica o campo de dados face aos protocolos de nvelsuperior, 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 InterfaceConcebida para ser usada como espinha dorsal (backbone) de grandes centros computacionaisou para interligao de redes locais.A vel. de trx. 100Mbps. A verso inicial foi revista para suportar trfego iscrono, MANs, e fibrasmonomodo. Universidades usam muito.

Nvel FsicoO meio de trx. a fibra ptica.

A norma prev anel duplo (A e B), permitindo a continuao da operao em caso de quebra deinterligao entre dois ns.A distncia entre estaes pode ir at 2km e a rede pode ir at um permetro de 200Km e at1000 estaes.

Mtodo de Controlo de Acesso ao MeioO 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, umaestao tem de estar na posse do testemunho. A mensagem circula no anel e retirada quandoretorna estao emissora. Ao contrrio do token ring, o testemunho libertado assim que aestao 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 RedesNas redes de grande escala, o nvel rede caracteriza o servio oferecido.Existem 2 filosofias para a realizao deste nvel: Circuito virtual (preferida dos Operadores deTelecomunicaes) 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 deentrega e controlo de fluxo.Na segunda, defendida pela comunidade Internet, todo o controle deve ser feito pelas entidadesdialogantes, face diversidade de subredes.A expresso prtica desta diferena o X.25 e o IP.

2.6.1. Equipamento de Interligao


7/27

Se a ligao for meramente ao nvel fsico repetidores (utilizados por ex. para ligar 2 segmentosduma rede Ethernet, idnticas portanto).A ponte (bridge) opera ao nvel lgico o que pressupe redes com nvel lgico idntico. A pontecopia tramas duma rede para outra. Como as tramas tm endereo, pode fazer-se filtragem. Sousadas 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 origemFinalmente, a interligao no sentido mais abrangente efectua-se no nvel rede. o encaminhador(router) (gateway, ou porta, genrico, sendo tb. software que compatibiliza protocolos dequalquer nvel)

2.6.2. Rede X.25Implementao de um servio pblico para comunicao entre mquinas geograficamentedistantes.As mquinas dos utilizadores interligam-se rede atravs de uma ligao ponto-a-ponto aocomutador da rede.

Nvel FsicoConsiste na ligao ponto-a-ponto utilizando linhas analgicas ou digitais.

Nvel LgicoUsa o protocolo LAPB (Link Acess Procedure), que implementa controlo de fluxo, recuperao deerros e garante que o comutador recebeu correctamente o pacote.As tramas so de 3 tipos: informao, superviso e no numeradas.

Nvel RedePodemos esquematizar o funcionamento da rede X.25 do seguinte modo: quando um DTEpretende comunicar com outro, tem de estabelecer um circuito virtual. Corresponde ao envio deum 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 fastselect em que o pacote de call request pode incluir 128 octetos de dados. O receptor pode recusara ligao com um clear request que tambm foi expandido para ter 128 octetos de dados, o queevita pois a ligao.O endereamento semelhante ao do servio telefnico com cdigo por pas, rede e n e oendereo 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 deligao de dados implementam ambos o controlo de fluxo.As limitaes de desempenho permitem prever a sua substituio pelo Frame Relay, que d umservio 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 IPA filosofia completamente diferente da X.25, pressunpondo-se que os utilizadores possuemredes que pretendem interligar rede global e que, para tal, dispem de mquinas comcapacidade 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 on 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, comexcepo dos ns da mesma rede em que pelo endereo do n.


8/27

Endereos IP cosntitudo de forma hierrquica por um par: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) paraformar 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 umarede.Classe A: 0 7-rede 24-hostClasse B: 10 14-rede 16 hostClasse C: 110 21-rede 8-hostOs 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 tabelasonde ele se encontra- No caaso da mquina ter vrios endereos, os protocolos utilizam a especificao de redecontida no endereo, mesmo que outros caminhos fossem mais eficientes.Endereos IP actuais tm 32 bits. No possvel tipo telefnico, devido grande diversidade deredes tamanhos dos endereos locais dificuldade no sistema de atribuio vs. desempenho.Para simplificar legibilidade so representados por 4 dgitos separados por pontos, cada dgitorepresentando 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 IPO 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 oudatagrama, 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 --> 13bits --> 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 dasubrede fsica). Se for indirecto preciso envi-lo ao n que actua como encaminhador. Amquina emissora tem de conhecer os endereos das portas de encaminhamento, que tmtabelas.


9/27

CAPTULO 3 Interface de Comunicao3.1. Modelo da Comunicao DistribudaO modelo computacional tem de oferecer ao programador de aplicaes uma viso coerente dosobjectos de comunicao e das funes que lhes esto associadas.A comunicao num ambiente distribudo uma evoluo de comunicao entre processos numanica mquina.Corresponde tambm troca de mensagens entre 2 processos.

O modelo computacional constitudo por objectos de comunicao ou portos e por funesagrupadas numa biblioteca. a interface API (Application Programming Interface) dacomunicao.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 (abstracodos 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 queexista 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 protocolode alto nvel.Quando a qualidade de servio oferecida pelo canal no pode ser mantida, o sistema deve avisaro processo atravs do mecanismo de excepes, que no caso dos sistemas distribudos assumeum papel mais importante devido a haver mais falhas.As interfaces utilizadas numa aplicao distribuda podem, portanto, ser diferentes consoante oSO. A garantia da capacidade de comunicao dada pelo protocolo de transporte queimplementa o canal.

3.2. Caracterizao da Interface3.2.1. Canal com ou sem ligao

No caso de uma nica mquina, o canal implementado por zonas de memria partilhada, logoelevada fiabilidade. Tal no se passa nos distribudos, sendo essa uma diferena fundamental. Odesempenho tb. menor.A fiabilidade e desempenho devem ser explcitos para o programador (qualidades de serviovrias, 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 deforma permanente e ter tempo de latncia significativo no estabelecimento do canal.O segundo adapta-se melhor comunicao com muitos interlocutores, a mensagens de pequenadimenso (tpicas dos sistemas client-servidor)

3.2.2. Portos de ComunicaoPara transferir informao os processos interactuam com um porto que representa a extremidadedo 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 detransporte.O identificador associado ao protocolode trnsporte pode ser explcito na interface (ex. sockets) ouencapsulado (ex. Mach).Quando um porto criado pode logo ser estabelecida a associao entre o identificador local e oendereo 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 portosTCP/IP nos sockets, existem mecanismos para designar os portos por nome inteligveis serviode nomes.


10/27

Do elenco de operaes associadas aos portos temos as funes de envio e recepo dasmensagens, criar e eliminar um porto, associar um endereo de transporte e definirparametrizao do canal.No caso do canal sem ligao, o porto receptor comporta-se como uma caixa de correio qualso enviadas mensagens e que, normalmente, tem capacidade para armazenar um determinadon de octetos. O canal estabelecido para cada mensagem. H direitos. Na mensagem deve serenviado o endereo do porto emissor para que o receptor possa estabelecer o canal de resposta.

3.2.3. Semntica da Funo de EnvioNo tocante sincronizao, a operao de envio de mensagens, pode ter vrias semnticas quese relacionam com a deteco de faltas na comunicao:- Assncrona: A funo copia a informao da mensagem para os tampes do protocolo detransporte e retorna depois de iniciar a operao de envio. O processo emissor desbloqueadoassim que a funo retorna do ncleo, mas no tem qualquer garantia que a mensagem chegouao seu destino.- Sncrona: O processo emissor fica bloqueado at que o porto destinatrio confirme que recebeua 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 processosparalelos levanta grandes problemas a nvel de sincronizao (protocolos prprios) e asaplicaes tm de ser programadas com muito mais cuidado (por eventos, ao contrrio do que seest habituado), que levam no muita utilizao. Ser eficiente no caso de trfegodesequilibrado (FTP, Telnet). Na pergunta-resposta no tem vantagens.O sncrono oferece garantia que a informao foi correctamente trx. mas no permite detectarqualquer falha na execuo do servio. Tb. de programao complexa, para evitarinterblocagens. CSP.A cliente-servidor procura garantir a execuo da operao, assegurando-se que o processo scontinua a sua execuo quando recebe resposta. Esta interface semanticamente bastante maisrica, pelo que tem sido usada como base de programao do modelo cliente/servidor. Mas implicaconjunto de operaes que no existem no protocolo de transporte.

3.2.4. Estrutura das MensagensPode ser individualizada ou serem apenas sequncias de octetos de tamanho varivel (bytestream) 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 existerelao directa com as estruturas de dados dos programas.Normalmente o sistema de suporte comunicao no impe formatao especfica smensagens. 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 oprocesso. 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 detodos os processos interlocutores, mas assim no possvel estabelecer prioridades. Por estarazo frequente os servidores criarem vrios portos para mensagens, de tipo ou deinterlocutores 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 conjuntode 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 setorna verdadeira, desbloqueia o processo. frequente associar primitiva de recepo uma temporizao (cominicao bidireccionalremota).A primitiva select dos sockets um exemplo de uma funo de recepo mltipla comtemporizao associada.A funo de recepo tambm pode ser assncrona (teste da existncia de mensagens no porto.caso no existam retorna ao processo).


11/27

3.2.6. ParalelismoA sincronizao das primitivas de envio e recepo de dados est fortemente relacionado com omodelo de concorrncia em termos de processos e tarefas. A necessidade de paralelismo coloca-se fortemente na programao de processo que actuam como servidores -> atendersimultaneamente vrios clientes.Uma forma de introduzir paralelismo no servidor utilizar vrios processos em paralelo. Estasoluo obriga, porm, partilha de estruturas de dados (memria e sincronizao), que

sempre de programao delicada, porque reintroduz o problema dos mltiplos pontos desincronizao.O modelo computacional mais adequado um modelo multitarefa com vrios fios de execuoconcorrentes que se sincronizam no acesso a variveis partilhadas. Tem vrias vantagens: omodelo 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; permiteexplorar situaes em que uma tarefa se bloqueia durante o servio a um pedido, por exemplopara aceder ao disco; tira partido dos eventuais vrios processadores existentes.Progressivamente os SO tm vindo a fornecer suporte para mecanismos multitarefa integrados nagesto dos processos.

3.2.7. Faltas na ComunicaoPodem ter numerosas origens, sendo as mais frequentes relacionadas com a quebra do canal decomunicao. tal pode acontecer porque a rede fsica falhou ou os protocolos esgotaam ostampes. O Mach usa tratamento de excepes.

3.2.8. Difuso de MensagensNas locais h mecanismos eficientes e intrnsecos. Nas grandes no pois a indiscriminao podeoriginar muitas mensagens suplementares na rede.Devido ao interesse dos algoritmos baseados na difuso, foram propostos mecanismos de difusomais restritos a grupos de portos. Os grupos tm nomes que os identificam e podem ser criadosdinamicamente. 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 osuporte indicado para polticas de replicao (mais complexos ISIS). Os outros no garantem aentrega a todos (melhor esforo) IP, Chorus.

3.2.9. Alternativas de ImplementaoGenericamente temos 3 formas de integrao das funes de comunicao no modelocomputacional 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 denormalizao 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 nasinterfaces de E/S serem insuficientes face s necessidades dos protocolos de comunicao.enviar e receber tudo bem, mas estabelecimento de ligao, parametrizao ou recepomltipla... A soluo funo de parametrizao genrica, ex. ioctl do Unix para tudo, mas issotorna a programao pouco clara e introduz facilmente erros.A alternativa a utilizao de biblioteca dedicada, que esconde detalhes das E/S e dos protocolosde transporte (ex. NetBios e DOS), mas obriga a distinguir entre comunicao remota e local, oque 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 mquinascom SO diferentes. Verifica-se o habitual compromisso entre eficincia e coerncia.Nos sistemas resultantes da evoluo de SO centralizados manteve-se a distino entremecanismos IP locais e as interfaces de comunicao distribuda. Ex. Unix V.4 tem IPC e TLI.


12/27

Nos SO estruturados com base em micro-ncleos como, p.ex. o Mach e o Amoeba procurou-seevitar esta duplicidade, mas, hlas, so incompatveis.Vamos ilustrar estes conceitos com 3 interfaces: os sockets so seguramente a inteface maisdivulgada e tendem a ser norma de facto nos sistemas abertos. O NetBios representativo deuma biblioteca de interface desenvolvida para o ambiente DOS e que no procurou reutilizar ainterface das E/S ou dos ficheiros. Finalmente o Mach IPC corresponde a uma abordagemintegrada, onde a comunicao local e remota foram consideradas como idnticas.

3.3. Interfaces de Sockets3.3.1. Caracterizao dos SocketsUnix, desde incio teve mecanismos para suporte da distribuio. A de Berkely (1982) inovou comos sockets como interface de comunicao. No Unix V foi para a API TLI (Transport LayerInterface).Os sockets propunham-se dar resposta a:- Independncia do Protocolo (de transporte);- Transparncia: a comunicao no deve depender da localizao dos processos, devendo seridntica para o caso local ou distribudo.- Compatibilidade: O novo mecanismo devia inserir-se na interface clssica de comunicao eE/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, sendosemelhante aos pipes sem nome.- Domnio Xerox NSNa criao do socket, para alm da especificao do domnio especificado o tipo de serviopretendido:- stream canal com ligap, bidireccional, fivel e com garantia de ordem. A interface do tiposequncia 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 dasmensagens.- 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 (comesquema de endereamento prprio).A estrutura genrica do identificador do socket definido em :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 eTCP, descrito no captulo anterior. Endereo IP da mquina (32 bits) e o nmero de um porto detransporte codificado com 2 octetos.


13/27

1.5 ResumoOs SO sofreram uma evoluo natural, resultante do grande desenvolvimento tecnolgico dasduas 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 dadoscom 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 dasredes com uma filosofia aberta de gesto como a Internet. Esta rede adquiriu recentemente umanotoriedade que a coloca como o meio mais adequado para a introduo de reais aplicaesdistribudas. Uma outra vertente da evoluo da tecnologia das comunicaes foi a das redeslocais LAN. Esta forma de interconexo de computadores iniciou-se na dcada de 80 e evoluiurapidamente, em particular na reduo de custos das interfaces que permitem hoje em dia queseja margina o custo de interligao dos computadores em rede local.2 Os computadores pessoais foram os equipamentos com maior impacto nos sistemasinformticos. Estes equipamentos de reduzido custo revolucionaram a experincia do uso dainformtica pelos utilizadores. A capacidade de processamento e armazenamento local, aliada auma interface cada vez mais ergonmica, obrigou a repensar os sistemas de informaocentralizados das dcadas anteriores. Apesar de o SO MS-DOS ser muito rudimentar, dificultandoa sua interligao coerente em rede, o enorme mercado motivou o desenvolvimento de diversassolues de partilha de ficheiros e impressoras que progressivamente tem vindo a aproximar-sedas arquitecturas existentes nas redes com equipamentos mais potentes com sistemas Unix.3 O s sistemas abertos apareceram devido presso dos grandes utilizadores quepretenderam no ficar totalmente dependentes dos seus fornecedores de hardware que ofereciamSO proprietrios, aos quais ficavam indissociavelmente ligadas as aplicaes. O movimento nosentido dos sistemas abertos procurou criar o conceito de plataformas de hardware, plataformasde SO e plataformas de SGBD, com interfaces bem definidos que permitem o transporte fcil dasaplicaes e criaram um mercado competitivo. Uma das reas mais influenciadas pela filosofiados sistemas abertos foi a comunicao entre computadores, pois os problemas colocados pela

interligao de sistemas heterogneos obrigaram a solues multivendedor. As redes actuais demaior sucesso, quer pblicas quer locais, baseiam-se em normas adoptadas por toda a indstria.4 As arquitecturas multiprocessadorso um meio natural para aumentar o desempenho dosprocessadores e justificam-se para as mquinas que actuam como grandes servidores deinformao. As arquitecturas dominantes so os multiprocessadores simtricos de memriapartilhada. Os multiprocessadores de memria distribuda interligam, sobre uma rede local ou umsistema de interconexo de alto dbito, mquinas independentes. A sua influncia na evoluodos sistemas operativos distribudos tem sido grande.

Os sistemas distribudos resultam da confluncia destes factores tecnolgicos e procuram darresposta a um conjunto de requisitos colocados pelos utilizadores, pelos programadores e pelosgestores de sistemas informticos.

Os utilizadores pretendem:transparncia que lhes evite terem de conhecer diferentes interfaces para os objectos dossistemas;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, emparticular de uma acrescidaergonomia,segurana,fiabilidade edisponibilidade.

Para os programadores, os requisitos so:


14/27

A necessidade de interfaces normalizadas (API) que permitam o desenvolvimento e transportedas aplicaes;ambientes de programao que escondam os detalhes da distribuio, dos mecanismos datolerncia 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 modulare garantem a extensibilidade do sistema. Um requisito importante a capacidade de gestoglobal 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 numamemria partilhada;modelo de faltas o modelo de faltas mais complexo, porque existem mais componentes e opadro de faltas mais complexo pela total independncia dos sistemas;sistema operativo repartido a distribuio implica a cooperao entre vrios ncleos de SO, noexistindo uma memria central para comunicao e sincronizao. Numa rede difcil criarmecanismos de sincronizao atmicos, devido s caractersticas temporais dos meios decomunicao e pelas hipteses de falha. A informao de gesto (nomes de utilizadores, ficheiros,perifricos) encontra-se dispersa por numerosas mquinas, sendo necessrio ao sistema executarprotocolos entre mltiplos ns para efectuar determinadas operaes;segurana nos sistemas multiprogramados, o ncleo dos sistema era considerado comoseguro, numa rede as mensagens podem ser escutadas ou modificadas e, no limite, nada impedeum utilizador de modificar um SO, pelo que se tem de partir do princpio de suspeio mtua emrelao a todos os interlocutores nas redes;heterogeneidade as diferenas entre processadores obrigam a tratar de forma transparente osdiversos 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 distribudosque ultrapassem os problemas sem sacrificar o desempenho.

Com natural, os problemas mencionados anteriormente tm soluo e a distribuio teminteressantes vantagens potenciais. Algumas so evidentes comoadequao repartio geogrfica,modularidade,extensibilidade. Outras so mais complexas de perceber como:maior disponibilidade devido existncia de mltiplas mquinas independentes permitindoreplicar a informao ou as aplicaes;melhor desempenho devido utilizao das mquinas mais adequadas a cada tipo deprocessamento;

custo mais reduzido decorrente da utilizao de computadores pessoais como interface paraos servidores.

Existem mltiplas formas de conceber os mecanismos de suporte construo deaplicaes distribudas.A forma mais simples apenas oferecer os mecanismos bsicos de intercomunicao entreprocessos. O programador tem neste caso de desenvolver as aplicaes cliente e servidor e osprotocolos de aplicao. Apesar desta soluo ser fcil de implementar nas mquinas existentes,tem diversas desvantagens: limitada reutilizao de cdigo e protocolos; dificuldade denormalizao; desempenho limitado devido implementao fora do ncleo.Existem, contudo, algumas vantagens neste mecanismo: simplicidade os programadoresapenas tm de conhecer interfaces de comunicao que no so muito diferentes das existentesnos sistemas centralizados; facilidade de transporte para outras arquitecturas - como osmecanismos utilizados no recorrem praticamente ao SO, o transporte das aplicaes simples.


15/27

Um nvel mais elaborado de suporte oferecido pelas plataformas cliente/servidor. No existeuma definio clara e consensual de qual a funcionalidade destas plataformas, apesar de seremvulgarmente considerados os seguintes servios: comunicao entre clientes e servidores porchamada de procedimento remoto; gesto de nomes; mecanismos de segurana paraautenticao e cifra das comunicaes; suporte a transaces distribudas; sistema de ficheirosdistribudo.A componente de base destas plataformas a comunicao utilizando o paradigma de chamada

remota de procedimento. Este mecanismo procura simplificar a interaco remota, assemelhando-a sintctica e semanticamente chamada de procedimento.

Os SO distribudos baseiam-se na interligao de todas as componentes do sistema: gesto dememria, gesto de processos, etc. O sistema funciona de um modo homogneo, permitindoexplorar 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 possamser interligados desta forma, necessrio que ofeream interfaces idnticas, o que obriga a quediversos fabricantes tornem os modelos dos seus sistemas compatveis.Para alm do suporte distribuio, uma caracterstica que tem marcado o desenvolvimento dosnovos SO a tentativa de modularizao da sua estrutura interna. Uma tendncia geral aestruturao interna dos sistemas em micro-ncleo, assegurando as funes de gesto deprocessos e de comunicao, e em servidores que executam as restantes funes. A prpriacomunicao entre o SO e o ncleo efectua-se por mensagem, permitindo a sua fcil adaptao distribuio ou s arquitecturas multiprocessador.

As arquitecturas multiprocessadortiveram 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, osprocessadores esto ligados mesma memria atravs de um bus partilhado. Os processadorestm uma cache local onde guardam as palavras de memria recentemente acedidas. A coernciadas 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 emsistemas existentes como o Unix, onde, devido ao pseudoparalelismo, o ncleo tinha extensasseces crticas.Uma outra linha de evoluo criar mecanismos a nvel de utilizador para explorar o paralelismoreal dos multiprocessadores. Certos algoritmos podem ser optimizados se executados em paralelopor vrias tarefas dentro do mesmo processo, em que todas as tarefas partilham o mesmo espaode endereamento. as tarefas (threads) passam a ser entidades geridas pelo SO que efectua orespectivo escalonamento, tirando partido dos diversos processadores.Os multiprocessadores de memria distribuda so compostos por processadores commemria privada e interligados por uma rede de alto dbito. Nestas mquinas, o SO um sistemadistribudo, onde todas as componentes habituais (processos, ficheiros) podem ser geridos deforma 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 interfacesemelhante a sistemas multiprogramdos clssicos, com o Unix, escondendo os detalhes daarquitectura.


16/27

CAP. 2As redes de dados tm caractersticas estruturais que as tornam muito mais complexas do que asE/S, nomeadamente: escala o nmero de unidades interligadas muito superior a qualquersistema de perifricos; heterogeneidade as redes interligam mquinas com processadores e Sosdiferentes e so elas prprias heterogneas devido a diferentes meios fsicos, tcnicas detransmisso 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; aslimitaes tecnolgicas associadas banda de transmisso e atenuao em funo da distncia;o custo das diferentes tecnologias; os requisitos das aplicaes que diferem quando se consideradados impulsionais, voz, imagens ou vdeo.Devido aos elevados investimentos efectuados nas linhas telefnicas em cobre, os operadoresprocuram reutiliz-las para redes de dados. A elevada atenuao e limitaes da banda passantedos cabos em cobre introduziram limitaes arquitectura das redes. Para pequenas redes, autilizao de meios fsicos mais eficazes e a possibilidade tcnica de efectuar a gesto de modomais eficiente conduziram ao desenvolvimento de redes de elevado desempenho e custoreduzido. estas diferenas tecnolgicas e as diferenas de explorao das redes pblicas e redesprivadas conduziram a uma segmentao das redes em : redes de grande escala (WAN), redespara reas metropolitanas (MAN) e redes locais (LAN).

Dada a enorme complexidade das redes, houve, desde o incio, interesse em encontrar modelosque subdividissem a complexidade considerando diversos nveis. Uma subdiviso natural entrea arquitectura fsica e a arquitectura lgica. A primeira prende-se com as topologias deinterligao e com as caractersticas fsicas dos meios de transmisso. A segunda procura criaruma rede com um conjunto de caractersticas susceptvel de suportar eficientemente asaplicaes.A arquitectura fsica relaciona-se com a topologia e as tecnologias de transmisso. As topologiashabituais 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 casosredundncia na ligao entre ns.

Historicamente, o cobre foi o meio fsico mais usado, mas progressivamente tem vindo a sersubstitudo 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 fibraspticasPara enquadrar a arquitectura lgica, foram criados vrios modelos de referncia. O maisdivulgado o modelo OSI, da organizao internacional de normalizao, a ISO. Este modelo, doincio da dcada de 80, reflecte a tecnologia da poca e tem diversas limitaes amplamentedivulgadas, contudo, continua a ser a referncia utilizada quer na rea da Informtica, quer emTelecomunicaes. Um outro modelo importante o que adoptou a Internet, designado pormodelo catnet. Neste modelo considera-se a rede como uma interligao de redesindependentes. Diversos fabricantes tambm propuseram os seus modelos, a maioria dos quaissem interesse actual, com excepo da arquitectura SNA da IBM que influenciou

significativamente o modelo OSI e tem ainda considervel impacto em alguns domnios como nossistemas 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 quedefine o formato e o significado das mensagens. Em cada sistema existe um fluxo decomunicao na vertical atravs das interfaces de servio dos vrios nveis de comunicao.Entre sistemas, a comunicao efectuada atravs dos protocolos dos nveis correspondentesnos sistemas.

Os protocolos podem ser com ligao ou sem ligao. Nos protocolos com ligao pretende-seemular 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 apenasexiste a fase de conversao. Ambas as solues apresentam vantagens e inconvenientes. osprotocolos com ligao podem aproveitar os estabelecimento da ligao para negociar parmetros


17/27

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 decomunicao, 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 protocoloimplementado em cada nvel, pretendeu-se tornar a arquitectura flexvel e modular. No entanto, asimplementaes 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 deendereamento.

O modelo OSI estrutura-se em 7 nveis. Os nveis inferiores esto mais prximos do meio fsicode 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; onvel de ligao de dados utiliza os servios do nvel fsico para o envio de tramas (frames) entreduas mquinas na mesma rede fsica; o nvel rede responsvel por suportar os mecanismosnecessrios ao encaminhamento (routing) dos pacotes de dados entre quaisquer sistemas ligados rede, independentemente da rede fsica; o nvel de transporte oferece um servio detransmisso de mensagens entre dois sistemas extremo a extremo, normalmente com vriasclasses de qualidade de servio. O servio de transporte caracteriza-se por um conjunto defacilidades: 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). Umutilizador dever poder aceder de forma transparente a recursos em qualquer dessas redes. Paratal, os pacotes do utilizador passaro por uma srie de redes, em trnsito, at ao destino. Oprocesso de encaminhamento transparente para o utilizador, bastando-lhe conhecer o endereoInternet do destino. A Internet parte de uma camada nuclear para toda a arquitectura: o nvel deinterligao de redes (Internetworking Layer) que se encarrega de suportar grande parte da

funcionalidade requerida pelo modelo. Esta camada baseia-se num nico protocolo, o InternetProtocol (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 dasarquitecturas centralizadas para as distribudas. Devido enorme diversidade de tecnologiasdisponveis, era fundamental definirem-se normas que permitissem o desenvolvimento de circuitosintegrados indispensveis para reduzir o custo das interfaces. O IEEE encarregou-se de efectuara normalizao numa comisso designada 802, nome por que ficaram conhecidas as normas aespecificadas.Na anlise dos mecanismos mais eficientes para implementao de redes locais, foi patente que aindependncia 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 AcessControl) que controla a partilha do meio e que, apesar de logicamente pertencer ao nvel deligao 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 cadacanal de comunicao uma frequncia prpria;Multiplexagem no Tempo (TDM), o meio fsico partilhado com base numa atribuio deintervalos de tempo a cada emissor de informao. Existem vrias formas de controlo daatribuio dos intervalos aos vrios emissores: Diviso no Tempo Sncrona intervalos dedurao fixa, sncronos com um relgio central so atribudos aos emissores; Diviso TemporalAssncrona neste caso, podem-se considerar 3 polticas de gesto: Aleatria; Controlada deforma distribuda; Controlada de forma centralizada.


18/27

As redes locais mais conhecidas so as Ethernet caractersticas: bus, cabo coaxial, TDM comcontrolo 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 dehierarquias de redes locais caractersticas: duplo anel, fibra ptica, TDM com controlodistribudo, 100Mbits/s.

O nvel rede caracteriza o servio oferecido nas redes de grande escala. Existem 2 filosofias debase na definio deste nvel: estabelecimento de um canal virtual entre os dois ns quepretendem comunicar antes de se iniciar a fase de transferncia de informao. O circuito virtualgarante controlo de erros, fluxo e sequencialidade; comutao de pacotes que so encaminhadosdinamicamente na rede at ao seu destino final, no procurando o nvel rede assegurarfuncionalidade suplementar que, caso seja necessria, dever sempre ser efectuada a nvel dotransporte. A expresso prtica desta diferena ilustrada pelos dois tipos de protocolos maisutilizados nas redes de grande escala: X.25 e a rede IP. A redundncia funcional da pilha deprotocolos X.25 e a ptica da interligao de redes, em vez da interligao de mquinas, do umamaior versatilidade e eficincia ao modelo Internet, consubstanciado no protocolo IP que seapresenta hoje como proposta com maior potencial no domnio da interligao de redes.


19/27

CAP 3.Os protocolos so fundamentais para que a comunicao se possa efectuar de forma normalizadae eficiente entre mquinas heterogneas. Contudo, para que esta infra-estrutura de comunicaoseja til, necessrio incorpor-la no modelo de programao, integrando as funes decomunicao no ambiente de desenvolvimento das aplicaes. A interface uma biblioteca defunes ou API (Application Programming Interface) que permite interactuar com um determinadonvel do modelo de comunicao, normalmente o transporte. As interfaces tratadas neste captulo

permitem um grau de abstraco em relao aos protocolos de comunicao, mas sonormalmente o equivalente funcional dos mecanismos existentes nos protocolos de transporte.

A comunicao pode modelizar-se como interaco entre um processo produtor que gera ainformao e um processo consumidor que ir trat-la. A informao transmitida genericamente designada por mensagem, devendo ser interpretada segundo um protocolo dealto nvel, acordado entre o produtor e o consumidor. A transferncia de informao suportadapor um canal, uma abstraco dos mecanismos de transporte que suportam a comunicaofsica. O canal de comunicao tem duas extremidades designadas portos que so objectos doSO e constituem a interface do sistema com os programas aplicacionais.

Na intercomunicao entre processos numa nica mquina, o canal implementado por zonas dememria partilhada, gerida pelo ncleo, oferecendo uma elevada fiabilidade, o que no se passanum ambiente distribudo. O desempenho tambm sensivelmente menor, sendo maispenalizado quanto menor for o dbito das redes subjacentes.

O modelo de canal projecta-se directamente nos conceitos discutidos no captulo anterior para onvel de transporte: com ligao estabelecimento prvio do canal entre os dois processosinterlocutores antes da troca de informao; sem ligao o canal conceptualmenteestabelecido apenas para o envio de uma mensagem.

Os portos so objectos do sistema a que est associado um espao de nomes e um conjunto defunes. 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 permiteenderear o porto na rede de comunicao.Para alm das funes de envio e recepo, existem funes especficas para criar, eliminar eparametrizar os portos. A funcionalidade destas rotinas diferente, consoante o canal seestabelece de forma permanente ou temporria. Se existe ligao, os portos do emissor ereceptor ficam implicitamente associados, assumindo-se como as extremidades do canalbidireccional atravs do qual se enviam e recebem dados.

As mensagens podem ser individualizadas ou sequncias de octetos (byte stream). O formatodas mensagens pode ser imposto pelo sistema ou pelo protocolo de alto nvel entre aplicaes. Aimposio de formatos prdefinidos na interface de comunicao uma restrio suplementar aoprogramador, sendo de uma forma geral evitada.

No envio de mensagens, preciso definir qual o tipo de servio oferecido pelo canal quando amensagem lhe entregue. As semnticas habituais so:assncrona a funo copia informao da mensagem para os tampes do protocolo detransporte e retorna depois de iniciar a operao de envio. O processo emissor desbloqueadoassim que a funo retorna do ncleo, mas no tem qualquer garantia que a mensagem chegouao seu destino;sncrona o processo emissor fica bloqueado at que o porto destinatrio confirme que recebeua 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, casonenhuma esteja presente, bloquear o processo. Se o servidor estabelecer simultaneamentecanais com vrios clientes, coloca-se o problema tpico de mltiplos pontos de sicronizao. Aexistncia de mltiplos canais relaciona-se com o modelo com ou sem ligao. Se o canal for sem


20/27

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 autilizar mltiplos portos. A soluo para este problema criar um mecanismo de recepo mltiplasobre um conjunto de portos. Na recepo mltipla, um processo bloqueia-se at que um dosportos 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 modelode paralelismo em termos de processos e tarefas. A necessidade de paralelismo coloca-se comparticular relevo na programao de processos que actua, como servidores. A recepo mltiplaresolve o problema dos mltiplos pontos de sincronizao, mas se apenas existir um processo, eles poder servir um pedido de cada vez, tendo os restantes clientes de esperar que os pedidosanteriores sejam executados. Uma forma de introduzir o paralelismo no servidor utilizar vriosprocessos em paralelo; esta soluo obriga, porm, partilha de estruturas de dados entre osprocessos (memria partilhada e sincronizao). A soluo mais interessante dispor de ummodelo multitarefa no servidor que permita a execuo concorrentemente de mltiplos fios deexecuo que se sincronizam no acesso a variveis partilhadas.

As faltas de comunicao podem ter numerosas origens. As mais frequentes relacionam-se coma impossibilidade de entrega da mensagem, devido a quebra do canal de comunicao. Adeteco da falta diferente, consoante se utiliza um canal com ou sem ligao. No primeirocaso, 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 dasfaltas de comunicao.Quando detectada uma falha, esta situao tem de ser transmitida ao processo. A forma maissimples atravs de um valor de retorno da execuo da funo que indique o estado daexecuo. 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, namaioria 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 enviaruma mensagem em difuso a mltiplos receptores. Do ponto de vista do programador a difusopode conduzir simplificao de diversos algoritmos, por exemplo: localizao, sincronizao,replicao de dados, alertar simultaneamente vrios processos para um acontecimento dosistema, etc. Devido ao interesse dos algoritmos baseados na difuso, foram propostosmecanismos de difuso mais restritos a grupos de portos. No mecanismo de difuso em grupoexiste uma distino importante entre os que garantem entrega fivel (difuso atmica) a todos oua nenhum dos participantes no grupo e aqueles que apenas enviam a mensagem numa base domelhor esforo, mas que no asseguram que todo o grupo a recebeu.

Considermos trs formas de integrao das funes de comunicao no modelocomputacional 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 protocolosde comunicao, a maior dificuldade na sua utilizao directa. As funes de E/S s se adaptambem s operaes simples de enviar e receber. A alternativa a utilizao de uma bibliotecadedicada, uma soluo de implementao simples que permite oferecer uma interface coerenteque 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. Aintegrao das funes de comunicao no IPC permite eliminar as bibliotecas de interfaceespecficas, tornando o modelo de programao totalmente coerente. Uma das desvantagensdesta aproximao a estruturao imposta pela organizao interna de um dado SO que torna o


21/27

protocolo do IPC proprietrio. Actualmente, apenas utilizado em sistemas distribudosexperimentais.

Os sockets podem ser considerados como uma evoluo dos pipes, a que foram adicionados osmecanismos de gesto dos canais e de gesto de nomes que permitem a comunicao entreprocessos 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. Nacriao do socket, para alm da definio do domnio, especificado o seu tipo que tem a vercom a qualidade de servio pretendida. Essencialmente, define se o canal estabelecido deforma permanente ou temporria: stream; datagram; sequenced packet; raw.Os sockets so criados com a chamada socket que devolve um ndice para um descritor deficheiro aberto. para o socket ser enderevel pelos restantes processos, necessrio associar-lhe um nome global, utilizando a funo bind.

Na utilizao tpica dos sockets com ligao, o servidor cria um socket e atribui-lhe um nomepara 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 acceptbloqueia o servidor at recepo de pedidos de ligao. esta primitiva tem uma semnticacomplexa: quando a ligao estabelecida, o sistema cria um novo socket que ficar associadoao novo canal de comunicao, deixando livre o socket inicial para continuar a receber pedidos deligao. Do lado do cliente, a criao do socket semelhante. O pedido de estabelecimento deuma ligao efectuado pela funo connect.Na utilizao dos sockets sem ligao, a interface semelhante das caixas de correio habituaisnos sistemas de intercomunicao entre processos. As funes sendto e recvfrom permitemenviar e receber mensagens.

A funo select indica ao sistema que o processo pretende ficar bloqueado at que umaoperao 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 desenvolvidapara os sockets, de utilizao geral para todas as funes de E/S. No texto efectua-se aindauma comparao da interface de sockets, com a evoluo proposta na verso V do Unix, ainterface TLI.

Existem diversos mecanismos de comunicao para redes de PC, por exemplo: NetBios; Lanmanager; 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 amplamentedivulgada, tambm oferecida pelo Lan Manager e pelo Netware. O NetBios realmente uma

interface de comunicao, ou seja, no h um protocolo nico, existindo diferentesimplementaes para redes diferentes. Contudo, a interface idntica permitindo o transporte dasaplicaes. Apesar de muito simples, existe no NetBios a maioria dos mecanismos quedescrevemos 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, comuma funcionalidade bsica, dos servios oferecidos pelo SO. O ncleo ou micro-ncleo apenasexecuta os aspectos bsicos: gesto de tarefas (despacho e escalonamento); intercomunicaoentre tarefas (IPC); interface ao hardware da mquina.Os conceitos relevantes no sistema IPC so os portos e as mensagens. Um porto um objecto doncleo que representa uma extremidade de um canal de comunicao. Os portos soequivalentes a uma caixa de correio residente no ncleo e que possui um tampo para oarmazenamento de mensagens. os portos so protegidos por capacidades que definem quem temo direito de receber e o direito de envio para o porto. Apenas uma tarefa pode ter num dado


22/27

instante o direito de receber mensagens num determinado porto. O envio de um porto numamensagem confere ao receptor da mensagem o direito de envio.Cada objecto conhecido no sistema tem associado um porto, ao qual podem ser enviadas asmensagens respeitantes sua utilizao. Os portos so assim simultaneamente os objectos decomunicao, mas tambm o sistema de designao das entidades do ncleo.As mensagens so estruturas tipificadas que descrevem para cada campo qual o tipo de dadosque 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 dosprocessos, permitindo que a informao possa ser transferida sem ter de efectuar cpias doespao 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 temuma estrutura relativamente complexa tendo sete parmetros. A semntica de envio pode serassncrona ou cliente-servidor. Para permitir a recepo mltipla, existe o conceito de conjunto deportos (port set) que agrupa diversos portos.Em conjuntos de mquinas que tenham como sistema o Mach, o IPC permite a intercomunicaoentre processos que se executam em mquinas distintas. esta funcionalidade proporcionada porum processo servidor, o NetMsgServer.Uma das facilidades providenciadas pelo sistema de comunicao a independncia delocalizao das entidades. O NetMsgServer responsvel por efectuar a correspondncia entreos identificadores locais na mquina e os identificadores remotos. O NetMsgServer esconde doutilizador os detalhes associados aos protocolos de comunicao. Conceptualmente, osprotocolos utilizados pelo NetMsgServer so transparentes para aplicaes.


23/27

CAP. 4 PROCEDIMENTOS REMOTOSA designao de arquitectura Cliente/Servidor estabelece a distino entre dois tipos deprocessos com comportamentos diferentes: os servidores implementam um conjunto de funesde interesse geral para outros processos que remotamente lhes podero aceder; os clientesefectuam a interface com os utilizadores, podendo executar parte das aplicaes localmente eacedem remotamente a processos servidores para executarem as funes mais complexas demanipulao de dados, clculo, entrada/sada, impresso, etc.

Os servidores devem publicitar os seus servios e quais os protocolos que podem ser utilizados. Aidentificao do servio lgica e no pressupe uma localizao fsica, possibilitando a mudanade mquina do servidor sem necessidade de modificar o cdigo dos seus clientes. O cliente deveestabelecer 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 omecanismo de transporte de informao. A mensagem contm a identificao do procedimentoremoto e os respectivos parmetros. Do lado do servidor efectuam-se as operaes inversas. Ociclo principal do servidor espera por uma mensagem, valida os dados recebidos, converte osparmetros para o formato interno e chama o procedimento apropriado. Quando este retornar, osresultados so empacotados, de acordo com a estrutura prdefinida e transmitidos de volta aocliente.

Para simplificar a programao de aplicaes baseadas no modelo cliente/servidor, foidesenvolvida uma metodologia de programao distribuda baseada na Chamada deProcedimentos Remotos que abreviaremos porRPC (Remote Procedure Call). O RPC permiteuma transferncia de controlo e dados entre espaos de endereamento disjuntos quer residentesna mesma mquina quer em mquinas distintas.

A ambio deste mecanismo ser totalmente transparente em relao ao modelo deprogramao habitual, podendo idealmente desenvolver-se uma aplicao de forma independenteda rede ou das mquinas que a iro suportar. Para que o modelo seja coerente, o RPC deverestar integrado transparentemente num ambiente de programao. A transparncia total ,

contudo, difcil de atingir e para a analisar podemos subdividi-la nos aspectos: sintaxe dalinguagem de programao; passagem de parmetros; semntica de execuo doprocedimento; desempenho.

A forma de especificao dos procedimentos remotos baseia-se numa linguagem de descriode interfaces ou IDL (Interface Description Language) que segue uma sintaxe inspirada naslinguagens tradicionais (C, Pascal, C++), convenientemente estendidas para evitar ambiguidades.As linguagens de especificao de interfaces so uma verso simplificada de uma linguagem deprogramao dado que apenas necessitam da parte declarativa das linguagens. A sua gramticadefine 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 compiladorso ficheiros com o cdigo fonte das rotinas, normalmente em C, que devero ser em seguidacompilados e interligados com o cdigo das aplicaes.A transparncia sintctica fcil, as linguagens de especificao apresentam sintaxes prximasdo C ou Pascal; a transparncia semntica mais complexa, porque as diferenas introduzidaspela separao dos espaos de endereamento no podem ser totalmente escondidas, atransparncia em termos de desempenho naturalmente impossvel, sendo muito diferente otempo de execuo no espao de endereamento de um processo, numa nica mquina oudistribuda.Na declarao dos parmetros, necessrio eliminar as ambiguidades na definio dos tipos dedados: 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 parapermitir desambiguar as situaes bastante permissivas existentes nesta linguagem. Atransferncia de parmetros por referncia no pode ser implementada de forma directa, devidoao RPC ser utilizado entre espaos de endereamento disjuntos. A passagem por referncia


24/27

obriga a copiar a estrutura no cliente para a mensagem, detectando a sua dimenso, e no servidora reserva dinmica da memria para onde ir ser copiada. Nos iniciais sistemas de RPC erarestringida 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 dadosdinmicas se adequa bem aos algoritmos. Existem vrios problemas e solues na passagem deparmetros por referncia que tem de ser convenientemente analisados em cada sistema deRPC.

A heterogeneidade na representao de dados um dos factores limitativos da transparnciana interaco distribuda. A tipificao dos parmetros na especificao da interface permite aocompilador 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 deendereamento de um processo, numa nica mquina ou distribuda. Este um dos aspectos emconstante evoluo, fruto dos avanos tecnolgicos. Contudo, nunca ser possvel esbatertotalmente as diferenas, pelo que o programador ter de ter sensibilidade a estescondicionamentos, sabendo os limites da transparncia em termos de desempenho.

A chamada de procedimento remoto uma abstraco lgica; na realidade, as chamadas remotascomeam com uma chamada a um procedimento local que se encarrega de iniciar a invocaoremota. Estas rotinas de adaptao (stub routines) tm um papel preponderante na arquitecturado sistema. No lado cliente, o procedimento de adaptao responsvel por: converter eempacotar os parmetros numa forma apropriada para transmisso; enviar a mensagem para oservidor usando um servio de transporte; esperar pela resposta do servidor. Quando esta forrecebida, desempacota os resultados, convertendo-os para a representao local dos dados namquina do cliente. Do lado do servidor, a rotina de adaptao tem finalidade simtrica. Se existirparalelismo no servidor necessrio introduzir nas rotinas de adaptao do servidor asincronizao 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 chamadaremota, a converso dos dados e a ligao aos mecanismos de transporte. Como natural, asfunes de suporte incluem tambm mecanismos para registo do nome nos servidores de nomese para o tratamento de erros e excepes. A biblioteca de funes com as respectivas estruturasde dados globais constitui o ambiente de suporte (run-time) execuo do RPC que sercarregado em memria com a aplicao distribuda.

Antes da invocao de um procedimento remoto, o cliente tem de localizar o servidor eestabelecer uma sesso atravs de um protocolo de ligao (binding). O estabelecimento dasesso permite, em seguida, executar as operaes remotas com uma latncia reduzida. A formacomo esta ligao se estabelece depende de diversas decises de arquitectura (transportecom/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 endereodos servidores que pretendem aceder;autenticao, dependendo das caractersticas de segurana, o servidor pode exigir ao clienteuma identificao segura, de forma a validar a sua identidade, o cliente pode tambm quererassegurar-se que o servidor realmente o processo correcto e no outro que lhe tenha usurpadoa identidade;estabelecimento da sesso, do lado cliente preenchida uma estrutura com o canal associadoao 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, oservidor no mantm estado, devendo, neste caso, utilizar canais de transporte sem ligao. Avantagem desta soluo que torna o servidor completamente independente dos clientes,podendo ser reinicializado sem qualquer precauo especial.


25/27

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 temessencialmente 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 damensagem no interior do servidor; falha do servidor, tornando-se impossvel determinar qual asituao da execuo do procedimento invocado remotamente; perda da mensagem de respostado servidor; o cliente aborta antes de ter processado a mensagem de resposta. As semnticas deexecuo 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 numintervalo 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 estasemntica, o servidor deve apenas oferecer funes idempotentes, em que mltiplas execuesda mesma chamada so idnticas a uma s execuo com os mesmo parmetros; na semnticano-mximo-uma-vez (at-most-once), a operao remota executada apenas uma vez ou poderno ser executada se existirem faltas de paragem nas mquinas cliente ou servidor. O protocolode suporte do RPC deve filtrar pedidos duplicados no servidor, confirmar todas as operaes emanter as mensagens at ter a garantia da sua recepo correcta. O problema de garantir asemntica exactamente-uma-vez advm da impossibilidade de, no caso de um servidor falhardurante a execuo de uma operao remota, saber exactamente o momento em que tal sucedeue qual o estado em que ficou a execuo da invocao. Para implementar uma semnticaexactamente-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 mensagemum descritor que identifica o tipo;implcita na mensagem so enviados apenas dados, existindo convenes que permitemdeterminar as converses a efectuar para cada tipo de mquina. O tratamento implcito tem duasvariantes: considerar que existe uma forma cannica de transmisso, a qual dever ser utilizadaem todas as mensagens; enviar os dados na forma como esto representados na mquina deorigem, incluindo na mensagem uma identificao do tipo de mquina. O receptor efectuar, senecessrio, a converso para o seu formato interno (receiver makes it right). esta soluo evita oproblema da possvel dupla converso, mas obriga a uma componente de gesto mais complexapelo que a primeira alternativa a mais utilizada.

Um dos aspectos importantes do sistema a optimizao do desempenho dos servidores. Algica do RPC adapta-se bem utilizao de tarefas no servidor que ficam a actuar comoprolongamento do fio de execuo do cliente. A existncia de vrias tarefas obriga a que o cdigoda biblioteca de RPC contenha sincronizao explcita para regies crticas e dados partilhados.No servidor, um conjunto de tarefas criadas inicialmente fica bloqueado espera de umamensagem. Quando ela chega, uma tarefa desbloqueada e serve o pedido de uma formaidntica ao caso sequencial. Realizaes mais sofisticadas criam dinamicamente novas tarefasquando 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 segundoservidor. 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 possacomportar tambm como cliente e que qualquer cliente possa ser tambm servidor. O primeirocaso no levanta grandes dificuldades, o servidor limita-se a chamar a rotina de adaptao do


26/27

servio que pretende invocar. Permitir que um cliente se comporte tambm como servidor maiscomplicado. O cliente tem de registar as chamadas em ricochete que quiser tratar, efectuandopara isso um procedimento idntico ao de um servidor quando regista um servio no servidor denomes.

O desempenho de um sistema RPC crucial para o desempenho global das aplicaes que outilizam. 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 clienteapenas efectua uma interaco com o servidor. Este um dos argumentos na defesa dautilizao de protocolos de transporte simples sem ligao que evitem o tempo inicial deestabelecimento do canal. O tempo de um RPC simples tem as seguintes componentes: tempo deconverso e empacotamento dos parmetros de entrada e sada no cliente e no servidor; tempode execuo do SO: chamadas ao sistema, comutao de processos, etc.; tempo de transmissodas mensagens.Estas componentes so muito semelhantes s que foram consideradas na discusso sobreprotocolos de comunicao. O que um sistema de RPC tem de particular a sua utilizaocorrente como mecanismo de estruturao de aplicaes distribudas. Nestas, a esmagadoramaioria das rotinas tem poucos parmetros e envolve poucos dados, sendo a transfernciamacia de dados muitas vezes efectuada por intermdio de protocolos especializados detransferncia de ficheiros. Por este motivo, o desempenho de um sistema RPC geralmenteoptimizado no sentido de diminuir a latncia das chamadas mais comuns, aquelas que enviam erecebem poucos dados.Para ilustrar os conceitos anteriores, descreve-se no texto um sistema de RPC desenvolvido pelaSun Microsystems para servir de suporte ao seu sistema de ficheiros distribudos NFS. Como a amaioria dos sistemas de RPC em Unix, o Sun-RPC utiliza sockets ou TLI como interface para osmecanismos de transporte de informao. A Sun assumiu que o protocolo de controlo do RPCdeveria ser independente do protocolo de comunicao, podendo usar-se transportes com ou semligao. No texto descreve-se: a linguagem de especificao, o tratamento da heterogeneidade, abiblioteca de suporte do RPC e o protocolo de comunicao.


27/27

CAP. 5 GESTO DE NOMESOs nomes so fundamentais nos sistemas informticos para permitir identificar, localizar epartilharos objectos.Nos SO, para alm destas funes, os nomes

SistDistrResLivro

Documents

Transcript of SistDistrResLivro