Sistemas operacionais distribuídos

Transcrição

1 Sistemas operacionais distribuídos Em um sistema operacional distribuído, os usuários acessam recursos remotos da mesma forma que fazem com recursos locais. A migração de dados e processos de um site para outro estão sob controle do sistema operacional distribuído. Migração de dados Vamos supor que um usuário no site A deseje acessar dados (como um arquivo) que residem no site B. Existem dois métodos básicos para o sistema efetuar a transferência de dados. Uma abordagem à migração de dados é transferir o arquivo inteiro para o site A. A partir daí, todo o acesso ao arquivo será local. Quando o usuário não precisar mais acessar o arquivo, uma cópia do mesmo (se tiver sido modificado) será enviada de volta ao site B. Mesmo nos casos em que foi feita uma pequenina mudança em um grande arquivo, todos os dados devem ser transferidos. Esse mecanismo pode ser considerado um sistema de FTP automático. Essa abordagem foi usada no Andrew File System (AFS) mas se mostrou ineficiente demais. A outra abordagem é transferir para o site A apenas as partes do arquivo que são de fato necessárias para o uso imediato. Se outra parte for necessária mais tarde, outra transferência ocorrerá. Quando o usuário não desejar mais acessar o arquivo, toda parte dele que tenha sido modificada deverá ser enviada de volta ao site B. (Observe a semelhança com a paginação sob demanda.) O protocolo Network File System (NFS) da Sun Microsystems utiliza esse método, assim como as versões mais recentes do AFS. O protocolo SMB da Microsoft (que executa sobre os protocolos TCP/IP ou Microsoft NETBUI) também permite o compartilhamento de arquivos via rede. Evidentemente, se apenas uma pequena parte de um arquivo grande estiver sendo acessada, a última abordagem é preferível. Se partes significativas do arquivo estiverem sendo acessadas, será mais eficiente copiar o arquivo todo. Observe que não basta apenas transferir dados de um site para outro. O sistema também deverá realizar várias traduções de dados se os dois sites envolvidos não forem diretamente compatíveis (por exemplo, se utilizarem diferentes representações de código de caracteres ou representarem inteiros com um número ou ordem de bits diferente). Migração de computação Em alguns casos, pode ser mais eficiente transferir a computação, em vez dos dados, pelo sistema; essa abordagem é chamada migração de computação. Por exemplo, considere um job que precisa acessar vários arquivos grandes que residem em sites diferentes, para obter um resumo desses arquivos. Seria mais eficiente acessar os arquivos nos sites em que residem e depois retornar os resultados desejados para o site que iniciou a computação. Em geral, se o tempo para transferir os dados for maior do que o tempo necessário para executar o comando remoto, o comando remoto deverá ser usado. Tal computação poderá ser executada de várias formas. Vamos supor que o processo P deseje acessar um arquivo no site A. O acesso ao arquivo é feito no site A, e pode ser iniciado por uma chamada de procedimento remoto (RPC). Uma RPC utiliza um protocolo de datagrama (UDP na Internet) para executar uma rotina em um sistema remoto. O processo P chama um procedimento predefinido no site A. O procedimento executa adequadamente e, em seguida, retorna os resultados para P. Como alternativa, o processo P pode enviar uma mensagem para o site A. O sistema operacional em A pode então criar um novo processo Q cuja função é executar a tarefa designada. Quando o processo Q conclui sua execução, ele envia o resultado necessário para P via o sistema de mensagens. Observe que, nesse esquema, o processo P pode executar ao mesmo tempo que o processo Q e que, na verdade, pode haver vários processos executando ao mesmo tempo em vários sites. Ambos os métodos podem ser utilizados para acessar vários arquivos que residam em vários sites. Uma chamada de procedimento remoto pode resultar na ativação de outra chamada de procedimento remoto ou até na transferência de mensagens para outro site. Da mesma forma, o processo Q poderia,

2 durante sua execução, enviar uma mensagem para outro site, que por sua vez criaria outro processo. Esse processo poderia enviar uma mensagem de volta a Q ou repetir o ciclo. Migração de processos Uma extensão lógica da migração de computação é a migração de processos. Quando um processo é submetido para execução, ele nem sempre é executado no site em que foi iniciado. Pode ser vantajoso executar o processo inteiro, ou partes dele, em sites diferentes. Esse esquema pode ser usado por vários motivos: Balanceamento de carga: Os processos (ou subprocessos) podem ser distribuídos em toda a rede para equilibrar a carga de trabalho. Aumento na velocidade de computação: Se um processo único puder ser dividido em vários subprocessos que possam ser executados concorrentemente em diferentes sites, o tempo total de retorno (tournaround time) do processo poderá ser reduzido. Preferência de hardware: O processo pode ter características que o tornem mais adequado para execução em algum processador especializado (como inversão de matriz em um processador vetorial, em vez de em um microprocessador). Preferência de softivare: O processo pode requerer software que esteja disponível apenas em determinado site, e talvez o software não possa ser movido ou seja menos caro mover o processo. Acesso a dados: Assim como na migração da computação, se os dados sendo utilizados na computação forem numerosos, pode ser mais eficiente fazer com que um processo execute remotamente, em vez de transferir todos os dados localmente. Basicamente, é possível usar duas técnicas complementares para mover os processos em uma rede de computador. Na primeira, o sistema pode tentar ocultar o fato de que o processo migrou do cliente. Esse esquema tem a vantagem de que o usuário não precisa codificar o programa explicitamente para realizar a migração. Esse método em geral é empregado para obter o balanceamento de carga e o aumento na velocidade de computação entre sistemas homogéneos, já que não há necessidade de auxílio do usuário para ajudar a executar os programas remotamente. A outra abordagem é permitir (ou exigir) que o usuário especifique explicitamente como o processo deve migrar. Esse método é geralmente utilizado nos casos em que o processo deve ser movido para satisfazer uma preferência de hardware ou de software. Você provavelmente já se deu conta de que a Web tem muitos aspectos de um ambiente de computação distribuído. Certamente, ela permite a migração de dados (entre um servidor Web e um cliente Web). Também fornece migração da computação. Por exemplo, um cliente Web poderia disparar uma operação de banco de dados em um servidor Web. Finalmente, com Java, ela oferece uma forma de migração de processos: os applets Java são enviados do servidor para o cliente onde são executados. Um sistema operacional de rede fornece a maior parte desses recursos, mas um sistema operacional distribuído os torna transparentes e facilmente acessíveis. O resultado é um ambiente poderoso e fácil de usar - um dos motivos do grande crescimento da World Wide Web. Tipos de redes Existem basicamente dois tipos de redes: as redes locais e as redes de longa distância. A principal diferença entre as duas é a maneira em que estão distribuídas geograficamente. As redes locais (LANs - local área net-works) são formadas por processadores distribuídos em pequenas áreas geográficas, como um único prédio ou alguns prédios adjacentes. As redes de longa distância (WANs - Wide Área Networks), por outro lado, são formadas por processadores autónomos distribuídos em uma grande área geográfica (como os Estados Unidos). Essas diferenças implicam grandes variações de velocidade e confiabilidade da rede de comunicação e se refletem no projeto do sistema operacional distribuído.

3 Redes locais As LANs surgiram no início da década de 1970 como um substituto para os grandes sistemas mainframé. Para muitas empresas, é mais económico ter muitos computadores pequenos, cada qual com seus próprios aplicativos autocontidos, do que ter um único e grande sistema. Como cada computador pequeno tende a precisar de um conjunto completo de dispositivos periféricos (como discos e impressoras) e como é provável que ocorra alguma forma de compartilhamento de dados dentro da empresa, é um passo natural conectar esses pequenos sistemas em uma rede. As LANs são geralmente projetadas para cobrir uma pequena área geográfica (como um único prédio, ou alguns prédios adjacentes) e, na maior parte das vezes, são utilizadas em um ambiente de escritório. Todos os sites em sistemas desse tipo são próximos uns aos outros, de modo que os links de comunicação tendem a ter maior velocidade e menor taxa de erro que seus equivalentes nas WANs. Para alcançar essa maior velocidade e confiabilidade, cabos de alta qualidade (e caros) são necessários. Também é possível utilizar o cabo exclusivamente para o tráfego da rede de dados. Em grandes distâncias, o custo de utilizar cabos de alta qualidade é enorme, e o uso exclusivo do cabo tende a ser proibitivo. Os links mais comuns em uma LAN são cabeamento de par trançado e fibra ótica. As configurações mais comuns são redes de barramento de acesso múltiplo, em anel e em estrela. As velocidades de comunicação variam de l megabit por segundo, para redes como AppleTalk e infravermelho, até l gigabit por segundo para gigabit-ethernet. Dez megabits por segundo é o mais comum, e corresponde à velocidade da Ethernet 10BaseT. O padrão Ethernet lbaset requer um cabo de maior qualidade mas trabalha a 100 megabits por segundo e está se tornando comum. As redes FDDI baseadas em fibra ótica vêm aumentando sua participação no mercado. Essas redes são baseadas em fichas (tokens) e trabalham a mais de 100 megabits por segundo. Uma LAN típica pode consistir em vários computadores diferentes, de mainframes a laptops ou PDAs, diversos dispositivos periféricos compartilhados (como impressoras a laser ou unidades de fita magnética), e um ou mais gateways (processadores especializados) que fornecem acesso a outras redes. A tecnologia Ethernet é comumente usada para construir LANs. Não existe controladora central em uma rede Ethernet, porque é um barramento de acesso múltiplo, por isso novos hosts podem ser facilmente adicionados à rede. Rede local

4 Redes de longa distância As WANs surgiram no final dos anos 60, principalmente como um projeto de pesquisa académica para fornecer comunicação eficiente entre diferentes locais, permitindo o compartilhamento do hardware e software de forma conveniente e económica por uma grande comunidade de usuários. A primeira WAN a ser projetada e desenvolvida foi a Arpanet. O trabalho na Arpanet começou em 1968 e ela cresceu de uma rede experimental de quatro pontos para se tornar uma rede mundial de redes, a Internet, reunindo milhões de sistemas de computadores. Existem também várias redes internacionais, privadas e comerciais que realizam a comunicação entre pontos de comunicação fixos, como filiais de empresas. Essas redes fornecem aos clientes a capacidade de acessar uma ampla gama de recursos de Hardware e software. Como os sites em uma WAN são fisicamente distribuídos em uma grande área geográfica, os links de comunicação são, relativamente lentos e pouco confiáveis. Os links típicos são linhas telefônicas, enlaces de microondas e canais de satélite. Esses links de comunicação são controlados por processadores de comunicação especiais, que são responsáveis por definir a interface através da qual os sites se comunicam pela rede, assim como por transferir informações entre os vários sites. Processadores de comunicação em uma rede de longa distância Como exemplo, vamos considerar a WAN Internet. O sistema permite que computadores em locais geograficamente separados se comuniquem entre si. Os computadores geralmente diferem entre si em termos de tipo, velocidade, tamanho de palavra, sistema operacional etc. Os computadores em geral estão em LANS, que, por sua vez, são conectadas à Internet via redes regionais. As redes regionais, tais como a NSFnet no nordeste dos Estados Unidos, são interligadas com roteadores para formar a rede mundial. As conexões entre as redes frequentemente utilizam um serviço de telefonia chamado Tl, que fornece uma taxa de transferência de megabits por segundo em uma linha dedicada. Para os sites que exijam acesso mais rápido à Internet, as Tis são reunidas em múltiplas unidades de Tl que funcionam em paralelo para fornecer mais throughput. Por exemplo, uma conexão T3 é composta por 28 conexões Tl e tem uma taxa de transferência de 45 megabits por segundo. Os roteadores controlam

5 o caminho de cada mensagem pela rede. Esse roteamento pode ser dinâmico, para aumentar a eficiência da comunicação, ou estático, para reduzir os riscos de segurança ou permitir o cálculo dos gastos com a comunicação. Outras WANs em operação utilizam linhas telefónicas padrão como seu principal meio de comunicação. Os modems são dispositivos que aceitam dados digitais do lado do computador e os convertem em sinais analógicos usados pelo sistema telefónico. Um modem no site de destino converte o sinal analógico de volta em sinal digital e o destino recebe os dados. A rede News do UNIX, via UUCP, permite que os sistemas se comuniquem entre si em horas predeterminadas, via modems, para trocar mensagens. As mensagens são então roteadas para outros sistemas vizinhos e, dessa forma, serão propagadas a todos os hosts na rede (mensagens públicas) ou se rão transferidos aos seus pontos de destino (mensagens privadas). As WANs em geral são mais lentas do que as LANs; suas taxas de transmissão variam de 1200 bits por segundo a mais de l megabit por segundo. O UUCP está rapidamente sendo suplantado pelo Potnt-to-Point Protocol (PPP). O PPP é uma versão do IP que funciona sobre conexões de modem, permitindo que os computadores domésticos sejam plenamente conectados à Internet. Comunicação Agora que já discutimos os aspectos físicos das redes, passemos ao seu funcionamento interno. O projetista de uma rede de comunicação deve abordar cinco questões básicas: Nomeação e resolução de nomes: Como dois processos localizam um ao outro para se comunicar? Estratégias de roteamento: Como as mensagens são enviadas pela rede? Estratégias de pacotes: Os pacotes são enviados individualmente ou como uma sequência? Estratégias de conexão: Como dois processos enviam uma sequência de mensagens? Disputa: Como resolver demandas conflitantes para uso da rede, considerando que ela é um recurso compartilhado? Nomeação e resolução de nomes O primeiro componente da comunicação em rede é a nomeação dos sistemas na rede. Para um processo no site A trocar informações com um processo no site B, eles devem ser capazes de especificar um ao outro. Dentro de um sistema de computação, cada processo tem um id de processo, e as mensagens podem ser endereçadas com o id de processo. Como os sistemas em rede não compartilham memória, eles inicialmente não têm conhecimento do host do seu processo alvo ou mesmo se o outro processo existe. Para resolver esse problema, os processos nos sistemas remotos são geralmente identificados pelo par <nome do host, identificador >, onde "nome do host" é um nome exclusivo na rede e "identificador" pode ser um id de processo ou outro número exclusivo naquele host. Um nome de host geralmente é um identificador alfanumérico, em vez de um número, para facilitar a especificação por parte dos usuários. Por exemplo, o site A pode ter hosts chamados " homer", "marge", "bart" e "lisa". "Bart" é certamente mais fácil de lembrar do que" ". Os nomes são convenientes para uso por seres humanos, mas os computadores preferem números por questão de velocidade e simplicidade. Por esse motivo, deve haver um mecanismo para resolver o nome do host em um id de host que descreva o sistema de destino para o hardware de rede. Esse mecanismo de resolução é semelhante à ligação nome-endereço que ocorre durante a compilação, linkedição, carga e execução de um programa. No caso de nomes de host, existem duas possibilidades. Em primeiro lugar, todo host pode ter um arquivo de dados contendo os nomes e endereços de todos os outros hosts alcançáveis pela rede (semelhante à resolução de nomes em tempo de compilação). O problema com esse modelo é que adicionar ou remover um host da rede requer a atualização dos arquivos de dados em todos os hosts. A alternativa é distribuir as informações entre os sistemas na rede. A rede deve usar então um protocolo para distribuir e recuperar essas informações. Esse esquema

6 é como a resolução de nomes em tempo de execução. O primeiro método foi o método original usado na Internet; à medida que a Internet cresceu, no entanto, ele se tornou insustentável e, por isso, um segundo método, o domain name service (DNS) agora está em uso. O DNS especifica a estrutura de nomeação dos hosts, assim como a resolução de nome para endereço. Os hosts na Internet são endereçados logicamente por um nome com várias partes. Os nomes têm sua estrutura organizada em partes de endereço que vão do mais específico para o mais geral, com pontos separando os campos. Por exemplo, "bob.cs.brown.edu" refere-se ao host "bob" no Departamento de Ciência da Computação na Brown University. Em geral, o sistema resolve os endereços examinando os componentes do nome do host em ordem inversa. Cada componente tem um servidor de nomes (simplesmente um processo em um sistema) que aceita um nome e retorna o endereço do servidor de nomes responsável por esse nome. Como etapa final, o servidor de nomes do host em questão é contactado e um id de host é retornado. Para nosso sistema de exemplo, "bob.cs.brown.edu", as seguintes etapas devem ser seguidas como resultado de um pedido feito por um processo em um sistema A para comunicação com "bob.cs.brown.edu": 1. O kernel do sistema A emite um pedido para o servidor de nomes para o domínio "edu", solicitando o endereço do servidor de nomes para "brown.edu". O servidor de nomes para o domínio "edu" deve estar em um endereço conhecido, de modo que possa ser consultado. (Outros domínios alto de nível incluem "com" para sites comerciais, "org" para organizações, e um para cada país conectado à rede - para os sistemas especificados por seus países em vez de tipo de organização.) 2. O servidor de nomes "edu" retorna o endereço do host no qual reside o servidor de nomes "brown.edu". 3. O kernel no sistema A consulta o servidor de nomes nesse endereço e pergunta sobre "cs.brown.edu". 4. Um endereço é retornado e um pedido a esse endereço para "bob.cs.brown.edu" finalmente retorna um id de host no formato endereço na Internet para aquele host (por exemplo, ). Esse protocolo pode parecer ineficiente, mas caches locais são geralmente mantidos em cada servidor de nomes para acelerar o processo. Por exemplo, o servidor de nomes "edu" poderia ter "brown.edu" no seu cache e poderia informar o sistema A que ele pode resolver duas partes do nome, retornando um ponteiro para o servidor de nomes "cs.brown.edu". Evidentemente, o conteúdo desses caches deve ser renovado com o tempo caso o servidor de nomes seja movido ou seu endereço mude. Na verdade, esse serviço é tão importante que existem muitas otimizações no protocolo, e muitas proteções. Considere o que poderia acontecer se o servidor de nomes primário "edu" falhasse. É possível que nenhum host "edu" conseguisse ter seus endereços resolvidos, tornando todos inalcançáveis! A solução é utilizar servidores de nomes secundários de backup que duplicam o conteúdo dos servidores principais. Antes de o serviço de nomes de domínio ser criado, todos os hosts na Internet precisavam ter cópias de um arquivo contendo os nomes e endereços de cada host na rede. Todas as alterações a esse arquivo tinham de ser registradas em um site (host SRI-NIC) e periodicamente todos os hosts tinham de copiar o arquivo atualizado de SRI-NIC para poder entrar em contato com novos sistemas ou encontrar hosts cujos endereços tinham mudado. No serviço de nomes de domínio, cada site de servidor de nomes é responsável por atualizar as informações do host para esse domínio. Por exemplo, quaisquer mudanças de hosts da Brown University são responsabilidade do servidor de nomes em "brown.edu" e não precisam ser relatadas em qualquer outro lugar. As pesquisas de DNS recuperarão automaticamente as informações atualizadas porque "brown.edu" é contactado diretamente. Nos domínios, pode haver subdomínios autónomos para distribuir ainda melhor a responsabilidade pelas mudanças nos nomes e ids de host. Em geral, é responsabilidade do sistema operacional aceitar de seus processos uma mensagens destinada a <nome do host, identificador> e transferir essa mensagem para o host apropriado. O kernel

7 no host de destino é então responsável por transferir a mensagem para o processo nomeado pelo identificador. Essa troca não é absolutamente simples. Estratégias de roteamento Quando um processo que está no site A deseja se comunicar com um processo que está no site B, como a mensagem é enviada? Se só houver um caminho físico de A para B (como em uma rede em estrela ou hierárquica), a mensagem deverá enviada por esse caminho. No entanto, se houver múltiplos caminhos físicos de A para B, então existem várias opções de roteamento. Cada site tem uma tabela de roteamento, indicando os caminhos alternativos que podem ser usados para enviar uma mensagem para outros sites. A tabela pode incluir informações sobre a velocidade e o custo dos vários caminhos de comunicação, e pode ser atualizada conforme necessário, quer manualmente ou via programas que troquem informações de roteamento. Os três esquemas mais comuns de roteamento são roteamento fixo, roteamento virtual e roteamento dinâmico: Roteamento fixo: Um caminho de A a B é especificado com antecedência e não muda a menos que uma falha de hardware desabilite esse caminho. Em geral, o caminho mais curto é escolhido, de modo que os custos de comunicação sejam minimizados. Roteamento virtual: Um caminho de A a B é fixo pela duração de uma sessão. Diferentes sessões envolvendo as mensagens de A para B podem ter caminhos diferentes. Uma sessão pode ser curta como uma transferência de arquivo ou longa como um período de login remoto. Roteamento dinâmico: O caminho usado para enviar uma mensagem do site A para o B é escolhido apenas quando uma mensagem é enviada. Como a decisão é tomada dinamicamente, mensagens separadas podem ser atribuídas a caminhos diferentes. O site A tomará a decisão de enviar a mensagem para o site C; C, por sua vez, decidirá enviá-la para o site D e assim por diante. Por fim, um site entregará a mensagem para B. Em geral, um site envia uma mensagem para outro através do link menos utilizado naquele instante determinado. Existem prós e contras nesses três esquemas. O roteamento fixo não pode se adaptar a falhas de link ou mudanças de carga. Em outras palavras, se um caminho foi estabelecido entre A e B, as mensagens devem ser enviadas ao longo desse caminho, mesmo se o caminho estiver inativo ou for muito utilizado enquanto outro caminho possível é pouco utilizado. Podemos resolver parcialmente esse problema utilizando roteamento virtual e podemos evitá-lo completamente utilizando o roteamento dinâmico. O roteamento fixo e o roteamento virtual asseguram que as mensagens de A a B serão entregues na ordem em que foram enviadas. No roteamento dinâmico, as mensagens podem chegar fora de ordem. Podemos resolver esse problema anexando um número de sequência a cada mensagem. Observe que o roteamento dinâmico é o mais complicado de configurar e manter. Entretanto, é a melhor forma de gerenciar o roteamento em ambientes complicados. O UNIX fornece o roteamento estático para uso em hosts em redes simples e o roteamento dinâmico para ambientes de rede complicados. Também é possível combinar os dois. Em um site, os hosts podem apenas precisar saber como chegar ao sistema que conecta a rede local a outras redes (como redes empresariais ou a Internet). Um nó desse tipo é chamado de gateway. Esses hosts individuais têm uma rota estática até o gateway. O gateway propriamente dito utiliza o roteamento dinâmico para chegar a qualquer host no restante da rede. Um roteador é uma entidade na rede de computação responsável por rotear mensagens. Um roteador pode ser um computador com software de roteamento ou um dispositivo de hardware dedicado. De qualquer forma, um roteador deve ter pelo menos duas conexões de rede, caso contrário, ele não terá para onde rotear as mensagens. O roteador decide se determinada mensagem precisa ser passada da rede na qual é recebida para qualquer outra rede conectada ao roteador. Essa determinação é feita examinando o endereço Internet de destino da mensagem. O roteador examina suas tabelas para determinar a posição do host de destino ou, pelo menos, da rede à qual enviar a mensagem para o host de destino. No caso do roteamento estático, essa tabela só é alterada por atualização manual (um novo arquivo é carregado no roteador). Com o roteamento dinâmico, um

8 protocolo de roteamento é usado entre os roteadores para informá-los sobre as alterações na rede e permitir que eles atualizem suas tabelas de roteamento automaticamente. Observe que os gateways e roteadores geralmente são dispositivos de hardware dedicados. Executam código em firmware, em vez de um sistema operacional de uso geral que executa aplicações de rede. Estratégias de pacote As mensagens geralmente têm tamanho variável. Para simplificar o projeto do sistema, normalmente implementamos a comunicação com mensagens de tamanho fixo chamadas pacotes, quadros ou datagramas. Uma comunicação implementada em um pacote pode ser enviada para seu destino em uma mensagem sem conexão. Uma mensagem sem conexão pode ser não-confiável e, nesse caso, o remetente não tem qualquer garantia, nem pode dizer se o pacote chegou ao seu destino. Como alternativa, o pacote pode ser confiável e, nesse caso, em geral um pacote é retornado do destino indicando que o outro pacote chegou. (Obviamente, o pacote de retorno poderia se perder pelo caminho.) Se uma mensagem for longa demais para caber em um pacote, ou se muitos pacotes precisarem fluir entre os dois pontos de comunicação, uma conexão será estabelecida para permitir a troca confiável de vários pacotes. Estratégias de conexão Assim que as mensagens conseguirem alcançar seu ponto de destino, os processos podem estabelecer sessões de comunicação para trocar informações. Existem várias formas diferentes de conectar pares de processos que desejam se comunicar na rede. Os três esquemas mais comuns são comutação de circuitos, comutação de mensagens e comutação de pacotes: Comutação de circuitos: Se dois processos desejam se comunicar, um link físico permanente é estabelecido entre eles. Esse link é alocado durante toda a sessão de comunicação, e nenhum outro processo pode usar esse link durante o período (mesmo se os dois processos não estiverem se comunicando ativamente durante algum tempo). Esse esquema é semelhante ao utilizado no sistema de telefonia. Assim que uma linha de comunicação tiver sido aberta entre duas partes (ou seja, a parte A liga para a parte B), ninguém mais pode usar esse circuito até que a comunicação seja encerrada explicitamente (por exemplo, quando uma das partes desliga). Comutação de mensagens: Se dois processos desejam se comunicar, um link temporário é estabelecido pela duração da transferência de uma mensagem. Os links físicos são alocados dinamicamente entre os correspondentes conforme necessário e são alocados apenas por curtos períodos. Cada mensagem é um bloco de dados, com informações do sistema (tais como origem, destino e códigos de correção de erro) que permitem que a rede de comunicação entregue a mensagem ao destino corretamente. Esse esquema é semelhante ao sistema de correio normal. Cada carta é considerada uma mensagem que contém o endereço de destino e o endereço de origem (de retorno). Observe que muitas mensagens (de usuários diferentes) podem ser enviadas através do mesmo link. Comutação de pacotes: Uma mensagem lógica talvez tenha de ser dividida em vários pacotes. Cada pacote pode ser enviado para seu destino separadamente e, portanto, deve incluir um endereço de origem e de destino com seus dados. Cada pacote pode utilizar um caminho diferente na rede. Os pacotes devem ser montados novamente em mensagens assim que chegam. Existem compensações óbvias entre esses esquemas. A comutação de circuitos exige tempo substancial de configuração, mas incorre em menos custo para enviar cada mensagem e pode desperdiçar largura de banda da rede. As comutaçõs de mensagens e de pacotes, por outro lado, requerem menos tempo de configuração, mas incorrem em mais custo por mensagem. Além disso, na comutação de pacotes, cada mensagem deve ser dividida em pacotes e mais tarde remontada. A comutação de pacotes é o método mais comum utilizado na redes de dados porque faz melhor uso da largura de banda de rede, e não é prejudicial para os dados serem divididos em pacotes, possivelmente roteados separadamente e remontados no ponto de destino. Quebrar um sinal de áudio (por exemplo,

9 uma comunicação telefónica), por outro lado, poderia causar grande confusão se não fosse feito com cuidado. Disputa Dependendo da topologia da rede, um link pode conectar mais de dois sites na rede de computação, por isso é possível que vários sites desejem transmitir informações em um link ao mesmo tempo. Essa situação ocorre principalmente em uma rede de barramento de acesso múltiplo ou em anel. Nesse caso, as informações transmitidas podem ficar misturadas e precisam ser descartadas. Os sites precisam ser notificados sobre o problema, para que possam retransmitir as informações. Se nenhuma medida especial for tomada, essa situação pode se repetir, resultando em degradação de desempenho. Várias técnicas foram desenvolvidas para evitar colisões repetidas, incluindo a detecção de colisões (CD), passagem de fichas e slots de mensagens. CSMA/CD: Antes de transmitir uma mensagem em um link, um site deve ouvir para determinar se outra mensagem está sendo transmitida naquele link; essa técnica á chamada de carrier sense with multiple access (CSMA). Se o link estiver livre, o site poderá iniciar a transmissão. Caso contrário, deverá esperar (e continuar a ouvir) até que o link esteja livre. Se dois ou mais sites começarem a transmitir exatamente ao mesmo tempo (cada um achando que nenhum outro site está usando o link), então eles registrarão uma detecção de colisão (CD - collision detection) e interromperão a transmissão. Cada site tentará novamente depois de um intervalo de tempo aleatório. Observe que, quando o site A começa a transmitir em um link, ele deve ouvir continuamente para detectar colisões com mensagens de outros sites. O principal problema com essa abordagem é que, quando o sistema está muito ocupado, muitas colisões podem ocorrer e, assim, pode haver degradação de desempenho. No entanto, o CSMA/CD tem sido usado com sucesso no sistema Ethernet, o sistema de rede mais comum. (O protocolo Ethernet é definido pelo padrão IEEE ) Para limitar o número de colisões, limitamos o nú mero de hosts por rede Ethernet. Adicionar mais hosts a uma rede congestionada pode resultar em baixo throughput de rede. À medida que os sistemas ficam mais rápidos, eles são capazes de enviar mais pacotes por segmento de tempo. Como resultado, o número de sistemas por segmento Ethernet geralmente está diminuindo, para manter o desempenho da rede aceitável. Passagem de fichas: Um tipo exclusivo de mensagem, conhecido como token (ficha), circula continuamente no sistema (em geral uma estrutura em anel). Um site que deseja transmitir informações deve esperar até que a ficha chegue. Ele remove a ficha do anel e começa a transmitir suas mensagens. Quando o site completa sua rodada de troca de mensagens, ele retransmite a ficha. Essa ação, por sua vez, permite que outro site receba e remova a ficha, e inicie sua transmissão de mensagens. Se a ficha se perder, os sistemas deverão detectar a perda e gerar uma nova ficha. Eles geralmente fazem isso proclamando uma eleição, para eleger um site único no qual uma nova ficha será gerada. Um esquema de passagem de fichas foi adotado pêlos sistemas IBM e HP/Apollo. O benefício de uma rede de passagem de fichas é que o desempenho é constante. Adicionar novos sistemas a uma rede pode aumentar o tempo que o sistema espera pela ficha, mas não causará uma grande redução de desempenho, como pode acontecer com a Ethernet. Em redes com pouca carga, no entanto, a Ethernet é mais eficiente, porque os sistemas podem enviar mensagens a qualquer momento. Slots de mensagens: Uma série de slots de mensagens de tamanho fixo circula continuamente no sistema (em geral, uma estrutura em anel). Cada slot pode armazenar uma mensagem de tamanho fixo e informações de controle (tais como qual é a origem e o destino, e se o slot está vazio ou cheio). Um site que está pronto para transmitir deve esperar até a chegada de um slot vazio. Em seguida, ele insere sua mensagem no slot, ajustando as informações de controle apropriadas. O slot com a sua mensagem prossegue na rede. Quando ele chega em um site, esse site inspeciona as informações de controle para determinar se o slot contém uma mensagem para ele. Se não contiver, o site recircula o slot e a mensagem. Caso contrário, ele remove a mensagem, ajustando as informações de controle para indicar que o slot está vazio. O site pode então utilizar o slot para enviar sua própria mensagem ou liberar o

10 slot. Como um slot pode conter apenas mensagens de tamanho fixo, uma única mensagem lógica talvez tenha de ser quebrada em vários pacotes menores, cada qual sendo enviado em um slot separado. Esse esquema foi adotado no sistema experimental Cambridge Digital Communication Ring. Robustez Um sistema distribuído pode sofrer de vários tipos de falha de hardware. A falha de um link, a falha de um site e a perda de uma mensagem são as falhas mais comuns. Para garantir que o sistema seja robusto, devemos detectar qualquer uma dessas falhas, reconfigurar o sistema de modo que a computação possa continuar e recuperar quando um site ou link for reparado. Detecção de falhas Em um ambiente sem memória compartilhada, geralmente não é possível fazer a distinção entre falha de link, falha de site e perda de mensagens. Em geral, é possível detectar que uma dessas falhas ocorreu, mas talvez não seja possível identificar o tipo de falha em questão. Assim que uma falha for detectada, ação apropriada deverá ser tomada, dependendo da aplicação específica. Para detectar uma falha de link e site, usamos um procedimento de handshaking. Vamos supor que os sites A e B tenham um link físico direto entre eles. Em intervalos fixos, ambos enviam uma mensagem "I am up" ("Estou ativo") um ao outro. Se o site A não receber essa mensagem em um período predeterminado, ele pode considerar que o site B falhou, que o link entre A e B falhou ou que a mensagem de B foi perdida. Neste momento, A tem duas opções. Pode esperar por outro intervalo de tempo para receber uma mensagem "Iam up" de B ou pode enviar uma mensagem "Are you up?" ("Você está ativo?") para B. Se A não receber a mensagem "Iam up" ou uma resposta à sua consulta, o procedimento poderá ser repetido. A única conclusão que A pode tirar com segurança é que algum tipo de falha ocorreu. O site A pode tentar diferenciar entre a falha de link e a falha do site enviando uma mensagem "Are you up?" para B por outra rota (se houver). Se e quando B receber essa mensagem, ele responderá imediatamente de forma positiva. Essa resposta positiva informa A que B está ativo, e que a falha está no link direto entre eles. Corno não sabemos de antemão quanto tempo a mensagem levará para passar de A para B e voltar, devemos usar um esquema de time-out. No momento em que A envia a mensagem "Are you up?", ele especifica um intervalo de tempo durante o qual está disposto a esperar por uma resposta de B. Se A receber a mensagem de resposta dentro desse intervalo de tempo, então poderá concluir com segurança que B está ativo. Se, no entanto, ele não receber a mensagem de resposta dentro desse intervalo (ou seja, se ocorrer um time-out), então A poderá concluir apenas que uma ou mais das seguintes situações ocorreu: O site B está inativo. O link direto (se houver) de A para B está inativo. O caminho alternativo de A para B está inativo. A mensagem foi perdida. Entretanto, A não pode determinar qual desses eventos de fato ocorreu. Reconfiguração Vamos supor que A tenha descoberto, por meio do mecanismo descrito na seção anterior, que ocorreu uma falha. Ele deverá então iniciar um procedimento que permitirá ao sistema reconfigurar e continuar seu modo de operação normal. Se um link direto de A para B falhou, essa informação deve ser transmitida para todos os sites no sistema, de modo que as várias tabelas de roteamento possam ser atualizadas corretamente. Se o sistema acreditar que um site falhou (porque ele não pode mais ser alcançado), então todos os sites no sistema deverão ser notificados para que não tentem mais usar os serviços do site em falha. A falha de um site que serve como coordenador central de alguma atividade (como detecção de deadlocks) requer a escolha de um novo coordenador. Da mesma forma, se o site em falha for parte de

11 um anel lógico, então um novo anel lógico deverá ser criado. Observe que, se o site não tiver falhado (ou seja, se estiver ativo, mas não puder ser alcançado), então poderemos ter a indesejável situação na qual dois sites servem como coordenador. Quando a rede é particionada, os dois coordenadores (cada qual para sua própria partição) poderão iniciar ações conflitantes. Por exemplo, se os coordenadores forem responsáveis por implementar exclusão mútua, poderemos ter uma situação na qual dois processos estarão executando ao mesmo tempo nas suas seções críticas. Recuperação após falhas Quando um link ou site em falha é reparado, ele deve ser integrado ao sistema de forma suave e harmoniosa. Vamos supor que um link entre A e B falhou. Quando ele for reparado, A e B deverão ser notificados. Essa notificação poderá ser feita repetindo continuamente o procedimento de handshaking. Vamos supor que B falhou. Quando ele se recuperar, deverá notificar todos os outros sites de que está ativo novamente. B poderá então ter de receber de outros sites várias informações para atualizar suas tabelas locais; por exemplo, ele poderá precisar de informações da tabela de roteamento, uma lista de sites inativos, ou mensagens e correio não entregues. Observe que, se o site não falhou, mas simplesmente não pôde ser alcançado, então essas informações ainda são necessárias.