UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE TECNOLOGIA FACULDADE DE ENGENHARIA DA COMPUTAÇÃO CURSO DE GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE TECNOLOGIA FACULDADE DE ENGENHARIA DA COMPUTAÇÃO CURSO DE GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO Antônio Braga Chucre Segundo Nielsen Alves Gonçalves ESTUDO DE VIABILIDADE DE IMPLEMENTAÇÃO DE MODELO DE COMPUTAÇÃO BASEADA EM SERVIDOR EM REDES EM MALHA SEM FIO Belém 2008

2 UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE TECNOLOGIA FACULDADE DE ENGENHARIA DA COMPUTAÇÃO CURSO DE GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO Antônio Braga Chucre Segundo Nielsen Alves Gonçalves ESTUDO DE VIABILIDADE DE IMPLEMENTAÇÃO DE MODELO DE COMPUTAÇÃO BASEADA EM SERVIDOR EM REDES EM MALHA SEM FIO Trabalho de Conclusão de Curso apresentado à Faculdade de Engenharia de Computação e ao Instituto de Tecnologia da Universidade Federal do Pará como condição para obtenção do título de Engenheiro de Computação. Belém 2008

3 UNIVERSIDADE FEDERAL DO PARÁ INSTITUTO DE TECNOLOGIA FACULDADE DE ENGENHARIA DA COMPUTAÇÃO CURSO DE GRADUAÇÃO EM ENGENHARIA DA COMPUTAÇÃO Antônio Braga Chucre Segundo Nielsen Alves Gonçalves ESTUDO DE VIABILIDADE DE IMPLEMENTAÇÃO DE MODELO DE COMPUTAÇÃO BASEADA EM SERVIDOR EM REDES EM MALHA SEM FIO Trabalho de Conclusão de Curso Apresentado como condição para obtenção do título de Engenheiro de Computação. Data da defesa: 04 de julho de Conceito: BANCA EXAMINADORA Prof. Dr. Kelvin Lopes Dias Faculdade de Engenharia da Computação/UFPA - Orientador Prof. Dr. Antônio Jorge Gomes Abelém Dep. de Informática/UFPA - Membro Eng. José Jaílton Henrique Ferreira Júnior Programa de Pós-graduação em Ciência da Computação/UFPA - Membro Belém 2008

4 AGRADECIMENTOS Por mais repetitivo que possa ser, não posso deixar de agradecer a Deus, pela vida e à minha família, pelo apoio incondicional e fundamental em todos os momentos. Respirar é repetitivo, mas ainda sim, necessário. Agradeço à minha noiva, Patrícia Corrêa, pelo incentivo que me ajudou a ganhar confiança nos momentos difíceis. Não poderia deixar de dedicar meu agradecimento especial a todos os pinguins, membros (e ex-membros) da equipe do GT-SET, a base deste trabalho, em especial à Sandra Rocha. Agradeço também pela ajuda da equipe do GT-Mesh, que ofereceu um ponto de partida prático fundamental ao desenvolvimento deste trabalho. Nielsen Gonçalves Agradeço em primeiríssimo lugar ao meu pai Antonio Braga Chucre e minha mãe Maria do Socorro dos Santos Chucre por terem acreditado que mesmo estando muito longe de seus olhos atentos e fraternos, eu estaria seguindo um bom caminho para a minha realização pessoal e profissional. É logico que durante essa trajetória muitos erros foram cometidos, mas tenho a certeza que todos os acertos juntos me deixam de cabeça erguida para galgar objetivos ainda maiores. À Rafaela Moraes de Araújo Chucre, que um dia, assim há de se chamar, pois nestes quatro anos de convivência pude aprender e vivenciar a incomparável experiência de construir minha própria família, compartilhar meus sonhos e objetivos de vida. Em segundo à Sandra de Fátima Rocha Trindade. égua da baixinha! sem sombra de dúvidas a profissional que qualquer um gostaria de ter como chefa. Aliás, mais que chefa uma amiga-irmã. Aos muleques doidos que comigo estiveram nessa jornada profissional em pról da liberdadeeeeeeeee. Por fim, aos meus amigos, que não serão citados para que injustiças não ocorram, mas que sabem do grande papel que desempenharam em minha vida, presenciando minhas alegrias e tristezas, ouvindo meus lamentos e toda uma enxurrada de angustias. Guardo todos no coração. Antonio Braga Chucre Segundo

5 "Só se dedicará a um assunto com toda a seriedade alguém que esteja envolvido de modo imediato e que se ocupe dele com amor. É sempre de tais pessoas, e não dos assalariados, que vêm as grandes descobertas." (Arthur Schopenhauer)

6 RESUMO A evolução da Tecnologia da Informação e Comunicação proporcionou o desenvolvimento das modernas alternativas em termos de soluções de Computação Baseada em Servidor. Estas soluções propuseram inicialmente uma transição entre os antigos Mainframes e as alternativas sucessoras, principalmente em ambientes corporativos, porém, a aplicação destas novas soluções se estendeu a diversas outras áreas de atividade. Dentre as diversas soluções existentes do modelo, destacam-se aquelas baseadas no uso de software livre, o que viabiliza uma economia adicional de recursos, gerando benefícios diretos à sociedade e permitindo o desenvolvimento de soluções de Inclusão Digital de baixo custo, inclusive pelo reaproveitamento de equipamentos obsoletos. Entretanto, as dificuldades de infra-estrutura de conectividade impedem um progresso ainda maior destas soluções. A proposta de utilização de redes em malha sem fio permite romper as limitações com infra-estrutura por meio de uma solução de custo relativamente baixo e fácil implantação, além de diversos outros benefícios práticos. Este trabalho tem como objetivo avaliar a viabilidade de uso de uma solução de Computação Baseada em Servidor através de uma rede em malha sem fio. Palavras-chave: Computação Baseada em Servidor, Servidor de Terminais e Redes Mesh.

7 ABSTRACT The evolution of the Information and Communication Technology provided the development of modern alternatives in terms of solutions of Computer Based on Server. These solutions initially proposed a transition between the old Mainframes and alternatives successors, especially in enterprise environments, however, the implementation of these new solutions has spread to several other areas of activity. Among the various solutions of the existing model, it is those based on the use of free software, which enables an economy of additional resources, generating direct benefits to society and allowing the development of solutions of Digital Inclusion of low cost, including the reuse of obsolete equipment. However, the infrastructure difficulties for connectivity prevent an even greater progress of these solutions. The proposed use of wireless mesh networks allows breaking the infrastructure limitations through a solution of relatively low cost and easy deployment, and several other practical benefits. This paper aims to assess the feasibility of using a Server Based Computing through a wireless mesh network. Keywords: Server Based Computing, Terminals Server and Mesh Networks.

8 SUMÁRIO 1. Introdução e motivação Justificativa Objetivos Organização do trabalho Modelo Server Based Computing (SBC) Histórico Definição de Thin Client Sistema X Window Arquitetura do Sistema X Window Mensagens do Protocolo X Display Manager (XDM) Protocolo X Display Manager Control Protocol (XDMCP) Parâmetros de desempenho em conexões a Desktops Remotos Segurança Técnicas para melhoria de eficiência Linux Terminal Server Project (LTSP) Processo de Boot no LTSP Projeto SET Redes Mesh Definição Histórico Arquitetura de Redes Mesh...32

9 3.4 Características das Redes Mesh Padrão s Implementações pré-mesh Protocolos de Roteamento Métricas de qualidade do enlace OpenWRT Estudo de Caso Objetivos e resultados esperados Equipamentos Cenários Cenário Indoor Metodologia Experimentos Resultados Resultados do experimento Resultados do experimento Resultados do experimento Análise dos Resultados Considerações Finais e Trabalhos futuros Cenário Outdoor...60

10 LISTA DE FIGURAS Figura 1: [Hewlett-Packard] Thin Client...18 Figura 2: Diagrama simplificado da arquitetura do sistema X WIndow...22 Figura 3: Diálogo de conexão do protocolo XDMCP...23 Figura 4: Modúlo de Administração (Projeto SET)...29 Figura 5: [AKYILDIZ, 2007] Modelo de rede mesh infra-estruturada...33 Figura 6: [AKYILDIZ, 2007] Modelo de rede mesh de clientes...33 Figura 7: [AKYILDIZ, 2007] Modelo de rede mesh híbrida...34 Figura 8: Método tradicional de inundação...39 Figura 9: Método de inundação por MPRs...39 Figura 10: Linksys WRT54GS...43 Figura 11: Amazonpc L81 (Servidor)...44 Figura 12: Acer 4520 (Cliente)...45 Figura 13: Local dos teste Indoor...47 Figura 14: Log da negociação de uma sessão remota (wireshark)...51 Figura 15: Tráfego de pacotes do experimento Figura 16: Tráfego de pacotes do experimento Figura 17: Informações da rede para o experimento Figura 18: Tráfego de pacotes do experimento Figura 19: Informações da rede para o experimento Figura 20: [GTMesh] Rede Mesh do Grupo de Trabalho Mesh/UFPA...60

11 LISTA DE SIGLAS AP CPU CSV DARPA DHCP ETT ETX FUSE GPL GUI IETF IP LAN LDM LTSP MIMO MPR NFS NX OLSR PXE QoS RFB Access Point Central Process Unit Comma Separeted Values Defense Advanced Research Projects Agency Dynamic Host Configuration Protocol Expected Transmission Time Expected Transmission Count Filesystem in Userspace GNU Public License Grafical User Interface Internet Engineering Task Force Internet Protocol Local Area Network Light Display Manager Linux Terminal Server Project Multiple-Input Multiple-Output Multi-Point Relays Network File System No Machine Optimized Link State Routing Preboot execution Environment Quality of Service Remote Frame Buffer

12 RAM ROM RTT SBC SSH UDP UMPC VBC XDM XDPC WMN Ramdom Access Memory Read Only Memory Round Trip Time Server Based Computing Secure Shell User Datagrama Protocol Ultra Mobile Personal Computer Virtualization Based Computing X Display Manager X Differencial Protocol Compression Wireless Mesh Networks

13 13 1. Introdução e motivação 1.1 Justificativa A rápida e contínua evolução dos microcomputadores proporciona equipamentos com poder computacional cada vez mais elevado. Em contrapartida, a necessidade básica de uso de grande parte dos usuários destes equipamentos não evolui da mesma forma, sobretudo em ambientes corporativos, nos quais o uso de estações de trabalho resume-se basicamente a processadores de texto e navegadores Web. Impulsionados pela indústria, muitos usuários adquirem equipamentos cuja capacidade computacional é muito superior às necessidades já citadas, resultando em gastos excessivos, sub-utilização e sucateamento gerado pelos sucessivos e desnecessários upgrades. Diante deste quadro, a proposta de utilização de servidores de terminais torna-se uma alternativa capaz de proporcionar um uso mais racional dos recursos computacionais, proporcionando economia de capital e até mesmo a diminuição do impacto ambiental ocasionado pelo contínuo descarte de materiais. Com a evolução das redes sem fio, uma nova característica é adicionada a este cenário: a possibilidade de conexão por meio de aparelhos portáteis sem a necessidade de infra-estrutura cabeada. Novas tecnologias nessa área passam a tornar viável a disponibilidade de aplicações gráficas a partir de servidores remotos de modo transparente via rede, e além disso fora dos limites de uma ambiente Indoor. Embora ainda em processo de evolução e padronização, as redes em malha sem fio permitem vislumbrar um cenário em que servidores possam ser acessados em redes sem fio de grande cobertura, como por exemplo campi universitários, bairros, ou até mesmo cidades inteiras.

14 Objetivos Este trabalho tem como objetivo apresentar a alternativa do uso de uma aplicação de servidor gráfico remoto através de uma rede em malha sem fio, aliando as características da computação baseada em servidor à versatilidade deste novo modelo de redes sem fio. 1.3 Organização do trabalho O trabalho econtra-se dividido em cinco tópicos principais sendo eles: conceituação, definição de cenários, coleta de dados, análise de resultados e estudos fututros. No Capítulo 2 é abordada a temática de Computação Baseada em Servidor com definição de conceitos, um breve histórico, sistemas utilizados, segurança e experiências de trabalho adquiridas na área. No Capítulo 3 encontram-se as principais características das redes em malha sem fio, bem como arquitetura, topologias, padronização, implementações realizadas além de métricas para avaliação de qualidade de enlace. No Capítulo 4 é realizado um estudo de caso para avaliação de viabilidade da solução proposta. São abordadados a descrição dos equipamentos e cenários, a metodologia utilizada na coleta dos dados e por fim a análise dos resultados. No capítulo 5 são discorridas as considerações finais, bem como são indicadas linhas de pesquisa para possíveis trabalhos futuros.

15 15 2. Modelo Server Based Computing (SBC) O modelo Server Based Computing (SBC) vem ganhando popularidade sobretudo no cenário nacional, uma vez que promove o reaproveitamento de equipamentos obsoletos permitindo uma considerável economia de custos. Apenas a economia com a aquisição de discos rígidos em um laboratório ou telecentro típico já representa expressiva economia no custo total de implantação do mesmo [NIEH, 2000 & YANG, 2000], porém existem diversas outras vantagens advindas do uso deste modelo, dentre as quais podemos destacar: Gerenciamento centralizado: Permite um controle central do acesso aos recursos do sistema, simplificando a disponibilização de software para múltiplos usuários, inviabilizando a instalação não autorizada de softwares em ambientes corporativos, além de centralizar o armazenamento de dados, tornando simples as rotinas de backup, por exemplo. Menor custo de manutenção: Os equipamentos utilizados como terminais têm um custo reduzido e normalmente não possuem partes móveis como ventoinhas e motores de disco, tendo portanto uma espectativa de vida útil maior se comparados aos computadores de mesa convencionais; Ubiqüidade: Devido à disponibilidade em rede, não apenas os dados mas a área de trabalho como um todo passa a estar disponível a qualquer usuário a partir de qualquer terminal conectado a rede, tornando o uso do sistema independente do terminal de acesso; Escalabilidade: A adição de novas máquinas à rede torna-se bastante simplificada uma vez que não há a necessidade de instalação de softwares aplicativos diretamente na estação de trabalho local. Um setor crescente é responsável pela produção de equipamentos específicos para uma das formas mais recentes de aplicação do modelo SBC os chamados ThinClients, que oferecem uma solução satisfatória e de baixo custo.

16 Adicionalmente, diversas empresas têm desenvolvido soluções de software baseadas em SBC, como por exemplo a Microsoft, com o Windows Terminal Server. Existem ainda grupos integradores, que dispõem de soluções completas de hardware e software, atendendo às necessidades de diversos perfis corporativos. Embora os setores citados no modelo sejam comumente atendidos por soluções proprietárias, existem alternativas baseadas na produção de software de código aberto, permitindo uma redução ainda maior nos custos de implantação. A tabela 1 lista comparativamente as principais soluções SBC existentes. Programa Protocolo Licença Em Linux Em Mac OS Em Windows AnywhereTS RDP, ICA Proprietário Não Não Sim Apple Remote Desktop RFB Proprietário Não Sim Não Citrix XenApp RFB Proprietário Sim Sim Sim Crossloop RFB GPL Não Não Sim FreeNX NX, RDP, RFB GPL Sim Não Não jrdesktop Proprietário GPL Sim Sim Sim GoToMyPC Desconhecido Proprietário Sim Sim Sim I'm Touching Proprietário Proprietário Sim Sim Sim IBM Director Remote Proprietário Proprietário Não Não Sim Krfb/Krdc RFB GPL Sim Não Não NX Server MacOS Screen Sharing NX, RDP, RFB Proprietário Sim Não Não RFB Proprietário Não Sim Não rdesktop RDP GPL Sim Sim Sim Real VNC Free RFB GPL Sim Não Sim Real VNC Enterprise Symantec PCAnywhere RFB Proprietário Sim Não Sim Proprietário Proprietário Sim Sim Sim Tight VNC RFB GPL Sim Sim Sim Ultra VNC RFB GPL Não Não Sim XDMCP X11 MIT Sim Sim Não Tabela 1: Comparativo entre diversas soluções de Terminal Gráfico Remoto 16

17 17 O uso de aplicativos gráficos por meio de acesso remoto tornou-se o grande diferencial na transição entre os mainframes e as soluções baseadas em ThinClients, viabilizando a disponibilidade de uma larga variedade de softwares baseados em Grafical User Interface (GUI), permitindo portanto uma maior diversificação de cenários de aplicação da solução. 2.1 Histórico O conceito de Computação Baseada em Servidor remete às próprias origens da informática. A abordagem foi amplamente utilizada desde o advento dos grandes servidores corporativos, e embora existam alternativas atuais ao uso desse modelo, o mesmo ainda permanece vantajoso em diversos casos de uso da mesma forma como foi originalmente concebido, uma vez que suas características principais, tais como segurança e escalabilidade, ainda satisfazem os interesses dos proprietários desses sistemas. No entanto, a evolução tecnológica trouxe consigo novas necessidades a serem atendidas, demandando adaptações ao modelo, preservando contudo as principais características do mesmo. Segundo [Vaughan, 2003], transformar os PCs atuais em estações não tão burras tornou-se um nicho de mercado que alimenta as empresas de tecnologia. Aguçadas pelas perdas originadas com o down-sizing no início dos anos 90 e com a possibilidade de fomentar o mercado com estações de trabalho um pouco mais modernas que aquelas deixadas para trás na década passada, empresas como IBM e HP uniram-se às indústrias de software (destacamse a Microsoft e Citrix... ) para trazer às grandes corporações soluções economicamente viáveis e tecnicamente superiores ao que vinha se instalando nas empresas até então. [Madden, 2003]. Atualmente, a SBC, ao lado da Computação Baseada em Virtualização (Virtualization Based Computing - VBC), estão entre as soluções com maior crescimento no mercado de TI corporativo.

18 Definição de Thin Client Thin Client ou Cliente Magro é um microcomputador especialmente projetado para redes baseadas na arquitetura cliente-servidor, onde a maior parte do processamento é realizada em um servidor central com maior poder computacional. O termo thin (magro) refere-se a um hardware bem mais simplificado que o encontrado nos computadores atuais, onde as freqüências de barramento e capacidade de memória comumente atingem valores da ordem de Giga Hertz, as unidades de disco já são associadas à TeraBytes e as CPUs e GPUs multiplicam-se e ganham cada vez mais núcleos. De forma antagônica, os ThinClients (conforme ilustra a figura 1) executam ciclos de clock de centenas de Mega Hertz, possuem memória diminuta de poucos MegaBytes e até ignoram a presença de unidades de armazenamento em massa. Porém, ao contrário do que muito se pensa, não são "Dumb Terms" ou "Terminais Burros" pois executam e processam aplicações localmente, tais como o carregamento de um Kernel, detecção de mídias locais e execução de um servidor gráfico local para disponibilizar ao usuário uma via de acesso ao servidor. Figura 1: [Hewlett-Packard] Thin Client

19 Sistema X Window Uma das premissas básicas para viabilizar o conceito de ThinClients é possibilidade de executar aplicações gráficas remotamente. Em ambientes baseados em UNIX isso se torna possível por meio do Sistema de Janelas X (X Window System), originalmente concebido no MIT e desenvolvido por um consórcio (X Consortium, Inc), disponibilizado para uma grande variedade de plataformas, a maioria baseadas em UNIX, suportando monitores baseados em mapa de bits Arquitetura do Sistema X Window A arquitetura definida pelo protocolo do sistema X Window é do tipo clienteservidor, que fornece uma camada de abstração entre o hardware e as aplicações e suporta qualquer protocolo de rede orientado a stream de bytes, seja ele local ou remoto [GODOY, 2004]. Dessa forma, o acesso a servidores gráficos remotos se torna bastante facilitado, permitindo que sessões gráficas a partir de servidores remotos façam uso transparente dos dispositivos de entrada e saída. O servidor X é a aplicação local responsável por exibir os componentes gráficos das aplicações, receber informações dos dispositivos de entrada básicos (teclado e mouse), gerando a partir destas eventos que serão interpretados pelas aplicações e resultarão eventualmente em um novo ciclo de eventos. As aplicações gráficas construídas com base nas bibliotecas compatíveis com o Sistema X Window são chamadas de clientes X e podem ser executadas tanto local como remotamente. Cada cliente X envia solicitações ao servidor e recebe informações de eventos a partir deste. O servidor X, portanto: Exibe as solicitações de desenho e imagens na tela Responde às solicitações de informações a partir de aplicativos Relata erros em uma solicitação Gerencia o teclado, mouse e o monitor Multiplexa entradas de teclado e mouse entre os aplicativos

20 20 Cria, mapeia e destrói janelas e desenha elementos nas mesmas O cliente X: Envia solicitações ao servidor Recebe eventos do servidor Recebe erros do servidor Mensagens do Protocolo Solicitações São feitas em múltiplos de 4 bytes. Os clientes X fazem solicitações ao servidor X por determinadas ações como por exemplo criar uma janela. Nem todas as solicitações demandam uma resposta. As solicitações de maior impacto no desempenho são entregues ao servidor, que as executa diretamente, nesses casos, o tratamento de erros fica a cargo do protocolo de rede. Respostas As respostas X são feitas em múltiplos de 4 bytes, com um mínimo de 32 bytes. O servidor X responde às solicitações do cliente X que exigem uma resposta. Eventos Os eventos X têm 32 bytes. O servidor X repassa ao cliente X um evento que a aplicação esteja esperando. Isto inclui entrada via mouse ou teclado. Para minimizar o tráfego na rede, apenas os eventos esperados são enviados aos clientes X. Erros Os erros do X possuem o mesmo tamanho que os eventos para simplificar seu manuseio. Eles são enviados para a rotina de tratamento de erros do cliente X (possuem 32 bytes). O método de requisição e resposta pelo qual ocorre a troca de informações entre cliente e servidor é bastante eficiente e gera um tráfego de informações significativamente reduzido se comparado a outros modos de transmissão gráfica em rede como o Remote Frame Buffer (RFB), por exemplo permitindo que as

21 21 aplicações atualizem as informações gráficas mesmo em redes com valores de vazão relativamente baixos, sem penalizar de modo significativo a experiência de usuário. A grande maioria dos programas gráficos utilizados em plataformas baseadas no UNIX é projetado com base nas especificações do sistema X Window X Display Manager (XDM) O X Display Manager (XDM) é a aplicação responsável por gerenciar o acesso do servidor X às aplicações gráficas que serão executadas, estejam elas disponíveis na máquina local ou mesmo em uma máquina remota. O acesso às aplicações é feito a partir da abertura de uma sessão. O controle da sessão é baseado na execução de um processo especial chamado de Gerenciador de Sessão (Session Manager Process SMP). A finalização deste processo caracteriza o encerramento de uma sessão. O XDM, portanto, pode ser definido como o equivalente gráfico dos programas login, getty, utilizados para fornecer prompt de autenticação de sistemas em modo texto baseados em Unix. O XDM permite que servidores X solicitem o acesso a aplicativos gráficos por meio de um processo de autenticação, o que permite o controle de permissões de acesso aos aplicativos, impedindo o uso não autorizado de aplicações, o que preserva a segurança do sistema. A figura 2 apresenta de forma simplificada a arquitetura do sistema X Window

22 22 Figura 2: Diagrama simplificado da arquitetura do sistema X WIndow Protocolo X Display Manager Control Protocol (XDMCP) X Display Manager Control Protocol (XDMCP) foi desenvolvido a partir da necessidade de gerenciar a oferta de Sessões X em rede, uma vez que o controle de servidores X disponíveis era feito de forma pouco eficiente, através da leitura do arquivo Xservers, que continha a relação de servidores disponíveis e era consultado apenas na inicialização do XDM, gerando diversos inconvenientes. O protocolo de controle permite que cada servidor X, ao ser iniciado, envie uma solicitação à uma máquina remota, e que esta responda esta solicitação autorizando ou não a obtenção de uma sessão X remota. Este processo é descrito de maneira mais detalhada a seguir. O X Display Manager Control Protocol (Protocolo de controle e gerenciamento

23 23 do display X) faz uso da porta UDP 177 para enviar um pacote de solicitação (query), com o objetivo de identificar a possibilidade de conexão à um gerenciador de login gráfico remoto. Se a requisição for autorizada, o gerenciador remoto retorna um pacote de informando a disponibilização do serviço (Willing). Uma vez identificada a disponibilidade para a autenticação no servidor, um pacote de requisição (Request) é enviado ao gerenciador. O gerenciador deverá então responder com um pacote Accept contendo informações baseadas em algum método de autenticação pré-definido, como por exemplo o fornecimento de uma chave secreta. Quando a autenticação é bem sucedida ocorre o envio de um pacote Manage de informação pelo gerenciador e finalmente a tela de Login conectada ao servidor X é exibida tal como em uma sessão de um cliente X local. Durante a sessão o gerenciador mantém a sua comunicação e checa a reciprocidade através do envio de pacotes KeepAlive em determinados intervalos de tempo; não ocorrendo este envio, o servidor X presume que a execução do gerenciador foi interrompida e pode finalizar a conexão. A figura 3 representa o diagrama de seqüência do sistema de autenticação descrito. Figura 3: Diálogo de conexão do protocolo XDMCP

24 Parâmetros de desempenho em conexões a Desktops Remotos Vazão A vazão pode ser definida como o número de pacotes processados com sucesso a cada unidade de tempo em uma transmissão de rede Latência De forma geral, a latência pode ser definida como o tempo transcorrido entre um evento e seu efeito. Em redes de comunicação a latência pode ser definida como tempo entre o início da transmissão de um pacote e sua total recepção no destino. RTT Também conhecido como Atraso de Ida e volta, este parâmetro caracterizase o tempo decorrido entre a transmissão de uma mensagem e a obtenção de uma resposta em uma rede Segurança O protocolo X não oferece nenhum método nativo de criptografia aos dados em tráfego, tornando-os vulneráveis à interceptação, sobretudo os dados de autenticação enviados pelo XDM. Isto pode ser justificado pelo fato de o protocolo ser tradicionalmente utilizado com clientes e servidor em uma única máquina ou através de uma rede local. Em relação aos dados de autenticação, existem Gerenciadores de Login cuja implementação contempla o uso de alguma forma de encriptação, como por exemplo o LTSP Display Manager (LDM), desenvolvido para uso na versão 5 do LTSP. Quanto aos dados dos aplicativos, uma alternativa é o uso do X sob uma conexão Secure Shell (SSH encriptado), por meio de tunelamento de tráfego. O SSH implementa nativamente o suporte a tunelamento de conexões entre clientes e servidores X.

25 Técnicas para melhoria de eficiência Compressão de Dados: Diminuição da quantidade de bits necessários para representar informações digitais, por meio de algoritmos freqüentemente baseados no tratamento de redundâncias nos dados. O processo de compressão de dados permite em determinados casos reduzir drasticamente os requisitos de vazão, porém o processo de compressão e descompressão demanda esforço computacional tanto na origem quanto no destino da transmissão. Proxy de Respostas: Uma das técnicas possíveis para diminuir os valores de Round Trip Time (RTT) é simplesmente diminuir o número de respostas necessárias no protocolo. As requisições de resposta podem ser tratadas por um proxy no lado cliente, de modo a "simular" de maneira mais rápida a resposta solicitada permitindo a transmissão de novos pacotes. O proxy encarrega-se então de checar o sucesso das transmissões, porém a uma taxa bastante inferior àquela obtida em condições normais, proporcionando grandes ganhos de performance ao modelo. Cache de dados: Parte das informações transmitidas durante uma sessão gráfica pode ser reutilizada pelo servidor X, gerando um impacto positivo na performance, uma vez que tais dados, como por exemplo ícones e outros elementos de imagem, permanecem disponíveis sem a necessidade de retransmissão por parte dos aplicativos clientes. Transferência Diferencial: A técnica consiste em transmitir apenas a variação de dados entre pacotes vizinhos, no que diz respeito às informações de montagem de janelas e seu conteúdo. Nesta abordagem é novamente importante mencionar a necessidade de utilização de CPU no processo de análise diferencial. Existem diversas implementações das técnicas citadas, algumas vezes de

26 26 forma combinada, de forma a melhorar a qualidade da comunicação sobretudo em redes de maior abrangência e conseqüentemente sujeitas a maior latência, ou ainda em redes com largura de banda reduzida, como forma de compensar a baixa vazão de dados. Low BandWidth X (LBX): O protocolo LBX foi desenvolvido como uma extensão ao X Window com o objetivo de viabilizar o uso de sessões X através de redes com alta latência, baixa largura de banda ou ambos. O protocolo foi desenvolvido em 1996 mas nunca chegou a ser utilizado em larga escala, sendo gradativamente descontinuado, o que levou à sua desativação e posterior remoção das implementações mais recentes do X. O princípio de funcionamento do X baseava-se na utilização de cache e compressão de dados, além do uso de proxy para respostas; X Display PC: O Projeto XDPC implementa um compressor de protocolo baseado em compressão diferencial. É utilizado um esquema de proxy, que atua como um X server virtual recebendo as solicitações de aplicativos, comprimindo-as e enviando através da rede. No lado cliente, um segundo proxy é encarregado de receber as informações e descompactá-las adequadamente; NX / FreeNX: O NX é o método mais utilizado de otimização do protocolo X, sendo base para várias soluções e implementações. O projeto FreeNX reescreveu o NX utilizando proporcionando uma alternativa de código aberto. O modelo permite também a interoperabilidade com protocolos proprietários como Remote Desktop Protocol (RDP), utilizado no Windows Terminal Server. O NX faz uso de todos os métodos de otimização citados neste trabalho, além de permitir múltiplas conexões, o que o torna uma opção eficiente no acesso a servidores remotos. 2.7 Linux Terminal Server Project (LTSP) O Projeto LTSP teve início em meados do ano 1996 a partir da solicitação feita por uma empresa para o criador do projeto. Esta desejava utilizar um servidor

27 27 de aplicações que permitisse conexão gráfica remota e tivesse baixo custo, permitindo o uso de aplicativos básicos de escritório [MCQUILLAN, 1996]. Com o êxito da solução implementada, esta foi melhorada e passou a ser desenvolvida de maneira colaborativa, resultando, após alguns anos, em uma solução completa e funcional para Servidor de Terminais utilizando software livre. Com a evolução do projeto, este passou a receber apoio cada vez mais expressivo e tornou-se uma solução atraente para ambientes corporativos. Mais tarde o projeto foi remodelado e passou a ser suportado por diversos distribuidores. Além do uso corporativo, as características da solução a tornaram bastante utilizadas em programas governamentais de inclusão digital, por meio da montagem de telecentros e laboratórios de informática Processo de Boot no LTSP A estação de trabalho deve ser configurada de modo a utilizar a rotina de inicialização via rede. Esta rotina consiste em um pequeno software (cerca de 40 kilobytes) chamado Etherboot que pode ser gravado em mídia removível, no disco rígido ou na ROM da placa de rede, ou ainda pode ser encontrado na ROM de alguns modelos de placa-mãe. Pode-se ainda utilizar o protocolo PXE, desenvolvido pela Intel para este mesmo fim. A primeira etapa desse processo se dá com a obtenção de um endereço IP, o qual pode ser pré-definido no arquivo de inicialização, porém comumente é atribuído por meio do protocolo DHCP. O servidor DHCP precisa ser configurado de modo a fornecer também informações acerca do kernel a ser obtido pela estação. Após a obtenção de uma configuração de rede válida inicia-se a transferência do kernel para a memória da estação. A transferência é feita por meio do protocolo FTP, utilizando um cliente bastante diminuto, embutido no software de boot. Com o kernel armazenado em memória inicia-se a próxima etapa do processo, na qual os serviços básicos necessários são iniciados. A rotina de inicialização é configurada de modo que o sistema de arquivos temporário seja substituído por uma pasta compartilhada via Network File System (NFS), exportada em modo somente-leitura pelo servidor e utilizada como sistema de arquivos raiz pela estação.

28 28 O sistema de arquivos NFS contém as informações necessárias à detecção de dispositivos de hardware. O hardware de vídeo, por exemplo, é detectado de forma automática por meio de um script específico. As versões mais recentes do LTSP incorporam ainda módulos especiais que permitem a detecção de mídias removíveis por meio do Filesystem in Userspace (FUSE). Com a etapa final do processo de boot, é disponibilizado um gerenciador de login configurado para fazer uso do protocolo XDMCP, aproveitando as características de rede do sistema X Window, que permitem o funcionamento do referido servidor gráfico de modo transparente através da rede de modo bastante eficiente. Uma vez autenticado no servidor o usuário passa a dispor dos recursos computacionais do mesmo, o que permite que máquinas de baixo poder computacional apresentem um desempenho satisfatório. O uso do processador é integralmente aproveitado e, se bem dimensionado, permite atender confortavelmente a uma quantidade considerável de usuários. A memória é compartilhada e necessita ser proporcional a quantidade de usuários, seguindo atualmente a seguinte relação: 256MB + 70MBxN Onde N representa o número de estações, de modo que torna-se possível atender vinte usuários com menos de 2GB. O restante da memória, utilizado para cache de disco, é compartilhado entre as estações, de modo que todas as instâncias de um mesmo aplicativo em geral se beneficiam da cache alocada pela primeira instância do mesmo, o que reflete positivamente no desempenho geral desse modelo. O uso típico de estações de trabalho básicas caracteriza-se pela utilização de aplicativos que consomem relativamente poucos recursos da máquina, sobretudo do tempo de CPU e da memória RAM, viabilizando o uso simultâneo de diversas estações de trabalho.

29 Projeto SET Grande parte deste trabalho baseia-se nas experiências vivenciadas no Grupo de Trabalho do projeto SET (Servidor de Estações de Trabalho) desenvolvido na UFPA. O Projeto SET tem por objetivo a implementação de uma solução completa para laboratórios de informática de uso geral, baseado na solução SBC desenvolvida pelo LTSP. Ao longo do projeto, a equipe de desenvolvimento pôde agregar à solução LTSP diversas melhorias, como por exemplo, no suporte a mídias locais, além do desenvolvimento de ferramentas de gerenciamento simplificadas, com o objetivo de facilitar a administração por parte dos bolsistas da Universidade Federal do Pará lotados como monitores nos laboratórios assistidos pelo projeto. A figura 4 apresenta a tela inicial do módulo de Administração desenvolvido pela equipe do projeto SET. Figura 4: Modúlo de Administração (Projeto SET)

30 30 O projeto foi implantado em 20 laboratórios na UFPA, sendo 10 na capital, e outros 10 em outros campi no estado do Pará. Cada laboratório atende em média 1000 alunos de diversos cursos, disponibilizando a cada um destes uma conta de usuário, e associada a esta uma área de trabalho personalizável, disponível a partir de qualquer estação dentro do laboratório. O projeto permite que com poucos investimentos em hardware, até mesmo reaproveitando-se equipamentos obsoletos, seja possível a implantação de um laboratório de informática que torne viável a execução de tarefas básicas como edição de texto e acesso a internet. Devido à sua reconhecida eficiência, o projeto foi expandido para algumas escolas da rede pública de ensino na região metropolitana da capital, com vistas em sua futura implantação em cidades no interior do Estado do Pará, porém, falta de infra-estrutura de rede apresenta-se como um fator limitante da solução, sobretudo em localidades mais afastadas. Nestas situações, o uso de uma solução sem fios baseada em redes mesh proporcionaria um meio de minimizar o problema. A solução SET-MESH surge nesse contexto, propondo a possibilidade de expansão do projeto sem estrutura de rede cabeada, por meio do uso LTSP associado à tecnologia das redes mesh.

31 31 3. Redes Mesh Neste capítulo serão abordados os principais conceitos sobre Redes em Malha Sem Fio (Mesh). Após uma breve definição e contextualização histórica, serão definidos os componentes da arquitetura, a padronização da mesma (ainda em andamento), bem como suas principais características. 3.1 Definição Redes em malha sem fio podem ser definidas como redes formadas por dispositivos distintos que podem ou não apresentar infra-estrutura fixa e que não têm como premissa um planejamento minucioso dos enlaces de comunicação, ou seja, em uma rede mesh os dispositivos são responsáveis por realizar conexões adaptativas uns aos outros, permitindo que sejam capazes de se auto-configurar e auto-organizar, a partir da obtenção periódica de parâmetros de qualidade, que serão utilizados na eventual redefinição das tabelas de roteamento, dispensando a necessidade de gerenciadores de tráfego dedicados para esta tarefa, uma vez que cada nó da rede é capaz de executá-la [RAMANATHAN & REDI, 2002]. Os nós podem se apresentar como dispositivos roteadores de posições fixas que realizam função de gateway ou bridge ou como nós clientes, que apresentam mobilidade e são os grandes responsáveis pela peculiaridade da rede (a sua autonomia), pois à medida em que novos clientes são inseridos, novas rotas de comunicação entre dois pontos de acesso podem ser estabelecidas, aumentando assim a complexidade da rede, o que não implica em uma queda no desempenho da comunicação, ao invés disto, pode torná-la até mais eficiente, uma vez que com o surgimento de novas rotas, em casos de saturação ou degradação da qualidade de serviço de um determinado caminho, têm-se um maior número de alternativas que possibilitam a entrega bem sucedida de pacotes.

32 Histórico A concepção das redes em malha teve seu início durante a década de 1960, porém, o seu desenvolvimento passou a ocorrer de forma mais consistente apenas na década de 1990, motivado pela Agência de Defesa Americana DARPA (Defense Advanced Research Projects Agency)[BREUEL, 2004]. O objetivo da pesquisa na época era desenvolver redes que pudessem atender às necessidades de comunicação em campo de batalha, tais como capacidade de reconfiguração e independência de um nó central. 3.3 Arquitetura de Redes Mesh No que refere-se à arquitetura, as redes Mesh podem ser classificadas em 2 tipos distintos: Redes com infra-estrutura::modelo em que existe uma infra-estrutura básica formada por roteadores mesh implementando a auto-organização e permitindo a agregação de diversos tipos de dispositivo, incluindo os dispositivos sem fio que necessitem de uma conexão convencional, ou ainda dispositivos ethernet, conforme mostra a figura 5. Estes clientes tradicionais acessam a rede por meio da funcionalidade de gateway/bridge adicionada aos roteadores mesh, permitindo a manutenção da estrutura de rede convencional [AKYILDIZ et al, 2007].

33 33 Figura 5: [AKYILDIZ, 2007] Modelo de rede mesh infra-estruturada Redes Cliente: Redes mesh construídas por meio de conexão ponto a ponto entre os clientes, dispensando a necessidade de roteadores, conforme ilustra a figura 6. Redes cliente podem ser definidas basicamente como redes Ad- Hoc, entretanto, os próprios clientes necessitam desempenhar as funções de auto-organização inerentes ao modelo mesh, gerando portanto uma carga adicional aos mesmos [idem]. Figura 6: [AKYILDIZ, 2007] Modelo de rede mesh de clientes

34 34 Redes Híbridas: Com o objetivo de aproveitar as características de ambas as arquiteturas, comumente são empregadas redes compostas de acordo com ambos os modelos. Desse modo, a infra-estrutura dos roteadores mesh oferece conectividade com outros tipos de rede (celular, redes de sensores, ethernet, etc) enquanto os clientes mesh implementam funções de roteamento de modo a ampliar a área de alcance da malha [ibidem]. A figura 7 ilustra a composição de uma rede mesh hibrida. Figura 7: [AKYILDIZ, 2007] Modelo de rede mesh híbrida 3.4 Características das Redes Mesh A arquitetura de rede mesh tem conceitualmente o foco na solução de problemas específicos encontrados em redes sem fio. Ao longo do desenvolvimento do modelo, suas características foram aplicadas na solução de diversas outras situações em que o modelo tradicional mostrou-se pouco eficaz, pode-se citar como exemplo: Aumento da área de cobertura em redes urbanas; Viabilização do acesso em regiões geograficamente isoladas; Viabilização do acesso a áreas sem visada direta; Redução de custo de infra-estrutura;

35 35 Uso em locais temporários. Embora tragam vantagens em diversos cenários de comunicação, as redes mesh sem fio ainda apresentam problemas e pendências em todas as camadas do modelo OSI, sobretudo devido ao seu estado de desenvolvimento atual ainda não apresentar grande nível de maturidade e padronização. As diversas questões e problemas têm sido foco de estudo de inúmeros grupos. 3.5 Padrão s O padrão s terá como finalidade definir as características necessárias à comunicação nas redes em malha sem fio e definirá a maneira pela qual os diversos dispositivos wireless podem se interconectar afim de formarem uma rede autogerenciável. Trata-se de uma extensão do IEEE MAC e suas variações (802.11a, b e g), onde serão definidas a arquitetura e o protocolo capazes de suportar a comunicação broadcast, multicast e unicast através da definição de métricas adequadas de comunicação por rádio aliadas à topologia de auto-configuração e à organização para múltiplos saltos [TASKGROUP, 2007]. 3.6 Implementações pré-mesh Embora sejam uma tecnologia experimental cujos projetos de padronização e desenvolvimento ainda estão em processo de execução, as redes mesh, sob o ponto de vista de alguns grupos da indústria de TIC, já apresentam vantagens suficientes que justifiquem investimentos em soluções de conectividade. Tais grupos definiram seus próprios padrões para viabilizar soluções comercializáveis utilizando redes em malha sem fios. Entretanto, a inexistência de um padrão universal compromete a interoperabilidade entre estas soluções. Estas iniciativas são denominadas implementações pré-mesh, dentre as quais podem ser destacadas:

36 36 Roofnet Roofnet é uma rede mesh b/g de caráter experimental desenvolvida no Laboratório de Inteligência Artificial e de Ciência da Computação do Instituto de Tecnologia de Massachussetts (MIT), onde parte do projeto de pesquisa inclui avaliações de níveis de sinal, descoberta de rotas com alto throughput em detrimento aos links problemáticos, adaptação de links, e o aprimoramento dos protocolos de roteamentos que possibilitem melhor rendimento na comunicação por rádio, que possui diversas peculiaridades. O protocolo de roteamento em aprimoramento é chamado de SrcRR e nele são usados dois tipos de broadcasts, o primeiro executa transmissões periódicas como intuito de determinar a métrica chamada Expected Transmission Count, e o segundo é responsável pelo descoberta armazenamento de novas tabelas de rotas [MIT, 2007]. V-Mesh V-Mesh é um projeto de investigação aplicada com as seguintes metas: Estudar as diversas abordagens na construção de redes sem fio eficientes, de baixo custo e de menor infra-estrutura de rede. Estudar protocolos de comunicações que abrangem diferentes aspectos e funcionalidade das redes Ad-Hoc. Construir uma rede sem fio de ensaio experimental Construir um dispositivo roteador sem fio baseado facilmente acessível, de baixo custo, sem um hardware existente. Desenvolver software para manutenção e operação de rede. Experiência com questões relacionadas com a mobilidade em uma rede Mesh.

37 37 UCSB MeshNET A Universidade de Santa Bárbara, no estado americano da Califórnia, desenvolve uma malha de rede sem fio experimental implantada no campus Universítário. A rede é composta de 25 nós que utilizam múltiplas redes sem fio no padrão IEEE a/b/g. É uma rede sem fio onde há predominância na comunicação verticalizada, pois os nós são distribuídos em cinco andares do prédio de Engenharia no campus 1 [UCSB, 2007]. Microsoft Mesh Pesquisadores da Microsoft Research em Cambridge e no Vale do Silício trabalham para aperfeiçoar tecnologia de redes em malha sem fio onde cada membro de uma vizinhança possa interligar sua rede particular a uma estrutura comunitária de rede mesh. Nela os moradores de uma determinada localidade não precisam instalar gateways próprios, mas tornam-se membros ativos na topologia ao conectarem-se a gateways que encontram-se fixos em determinados pontos. Assim, cada novo cliente inserido na malha pode resultar em uma nova rota de acesso ao meio externo, além disso, pacotes gerados dentro da rede circulam livremente sem precisarem passar por um provedor de serviços e de internet tornando o acesso a Internet mais eficiente, de menor volume de dados e de menor custo para todos [MICROSOFT, 2005]. 3.7 Protocolos de Roteamento Protocolos de roteamento determinam o conteúdo das tabelas de roteamento, ou seja, são eles que ditam a forma como a tabela é montada e de quais informações ela é composta [RNP, 1997]. Existem dois tipos de protocolos de roteamento utilizados atualmente, sendo o primeiro reativo, que determina suas rotas usadas sob-demanda, ou seja, somente quando necessita de uma rota é que o protocolo irá iniciar o descobrimento desta. Um exemplo de protocolo reativo é o Ad hoc On-Demand Distance Vector

38 38 (AODV), que é um protocolo de roteamento dinâmico e auto-iniciável, que estabelece rotas entre nós móveis que possibilitam e mantém redes ad hoc. Permite obter rapidamente rotas para novos destinos, e evita com que nós mantenham rotas para destinos que não estão em comunicação ativa. [PERKINS, 2003] O segundo é de característica pró-ativa, onde existe a constante propagação das informações de rotas, mantendo assim o conhecimento dos caminhos sempre atualizado, para que quando um pacote necessite de uma rota, a mesma já esteja determinada e seja usada imediatamente. [FERNANDES, 2006] Optimized Link State Routing (OLSR) O Optimized Link State Routing Protocol é um protocolo de roteamento de IP especificado na RFC 3626 do IETF (Internet Engineering Task Force) e proposto originalmente para uso em redes Ad-Hoc genéricas e posteriormente reimplementado para incluir suporte específico a redes Mesh. Trata-se de um protocolo pró-ativo, uma vez que o mesmo realiza consultas periódicas sobre a qualidade dos enlaces com o intuito de atualizar constantemente suas tabelas de roteamento. O que o difere de outros protocolos pró-ativos é o conceito de multipoint relays (MPRs). O uso de MPR consiste em eleger nós específicos para a transferência das informações de qualidade aos demais nós (flooding), diminuindo o overhead de comunicação da rede [CLAUSEN et al, 2003], como ilustram as figuras 8 e 9:

39 39 Figura 8: Método tradicional de inundação Figura 9: Método de inundação por MPRs A eleição dos nós MPR e feita por critério de proximidade: Cada nó MPR deverá ser capaz de alcançar outros nós com até dois saltos de distância, sem o intermédio de outros nós MPR no trajeto. 3.8 Métricas de qualidade do enlace As métricas de qualidade comumente utilizadas nas implementações de redes em malha sem fios são as seguintes:

40 40 Expected Transmission Count (ETX) A métrica ETX de um enlace é calculada usando as taxas de recepção de pacotes em ambos os sentidos do enlace, pois a taxa de recepção é a probabilidade com que um pacote de dados chegue no próximo nó do caminho. A probabilidade esperada com que uma transmissão seja recebida com sucesso e seja reconhecida é o produto entre taxa de recepção de ida (df) e a taxa de recepção de volta (dr) do enlace. Logo, o valor damétrica ETX é dado por: ETX = 1 / (df x dr). As taxas de recepção (d) são medidas utilizando pacotes HELLO do protocolo OLSR modificados, enviados a cada t segundos (t=2, por padrão). Cada nó calcula o número de HELLOs recebidos em um período de w segundos (w=20, por padrão) e divide pelo número de HELLOs que deveriam ter sido recebidos no mesmo período (10, por padrão). Cada pacote HELLO modificado informa o número de HELLOs recebidos pelo vizinho durante os últimos w segundos, para permitir que cada vizinho calcule a taxa de recepção no outro sentido do enlace. Quanto pior a qualidade do enlace, maior o valor de ETX. O valor mínimo de ETX é 1 em um enlace perfeito e pode ser 0 somente se nenhum pacote HELLO for recebido durante o período de w segundos. No caso de um caminho com múltiplos saltos, o valor de ETX da rota completa é dado pelo soma do valor de ETX de cada salto. Logo, em uma rota do nó A ao nó C, passando pelo nó B, o valor final de ETX é dado por: ETXAC = ETXAB + ETXBC. Expected Transmission Time A métrica ETT é derivada o conceito de ETX, porém leva em consideração a largura de banda. Segundo [DIAS, 2005] a métrica é obtida multiplicando-se o valor de ETX pela largura de banda do link para se obter o tempo gasto na transmissão do pacote no link. Seja S o tamanho do pacote e B a largura de

41 41 banda do link, então: ETT = ETX * S/B Hop Count A métrica Hop Count baseia-se na quantidade de saltos necessário até o destino da transmissão, considerando ótimo o caminho que contiver o menor número de saltos até o destino. 3.9 OpenWRT Em virtude do alto custo e pouca compatibilidade oferecida pelas soluções proprietárias, foi desenvolvida uma solução alternativa baseada em software livre, utilizando equipamentos Wi-Fi tradicionais, os quais têm seu firmware substituido por uma instalação do sistema operacional linux embarcada. Esta solução, devido ao seu custo relativamente baixo de implementação, tem sido adotada em diversas instituições. Este trabalho utilizou como base a distribuição OpenWRT, a qual foi obtida, instalada e configurada para a realização do estudo de caso mostrado a seguir.

42 42 4. Estudo de Caso 4.1 Objetivos e resultados esperados Os experimentos realizados neste trabalho têm como objetivo avaliar o comportamento de conexões a servidores gráficos remotos utilizando os protocolos do Sistema X Window através de redes Mesh. O sucesso destes experimentos indica a viabilidade do aproveitamento de equipamentos portáteis já obsoletos e a utilização de equipamentos Ultraportáteis (UMPC's) para a execução remota de tarefas que exijam maior poder computacional, entre inúmeras outras aplicações práticas. 4.2 Equipamentos Foram utilizados para este experimento 3 access points e dois computadores portáteis, de acordo com as descrições a seguir. Linksys WRT54GS: seguem abaixo as especificações mais relevantes acerca dos equipamentos utilizados. Segundo [OPENWRT] têm-se : Fabricante: Linksys (a Cisco Division) Modelo: WRT54GS + SpeedBooster Freqüência de Operação: 200Mhz Memória RAM: 16MB. Memória Flash: 4MB. Placa de Rede: Integrated Broadcom BCM2050KML

43 43 Figura 10: Linksys WRT54GS O firmware original dos roteadores foi modificado neste experimento, sendo substituído por uma distribuição do sistema operacional GNU/Linux específica chamada OpenWRT. Foi instalada a versão mais recente da distribuição, bem como foram adicionados os seguintes pacotes de software extras: olsrd Serviço de roteamento dinâmico que implementa o algorítimo OLSR. olsrd-mod-httpinfo Módulo que inicia um pequeno servidor Web, permitindo acompanhar através do navegador as informações sobre o funcionamento do serviço olsrd. O OpenWRT é um firmware especialmente desenvolvido para ser embarcado em roteadores sem fio. Trata-se de uma mini-distribuição desenvolvida sob a GPL (General Public License) e que possui funcionalidades reduzidas em relação àquelas desenvolvidas para uso geral, porém isso ocorre devido à necessidade de adequação do firmware à memória dos dispositivos utilizados [WIKI-OPENWRT, 2007]. O que basicamente difere o OpenWRT das versões originais de firmwares

44 44 fornecidas pelos fabricantes é que, ao invés de se ter um firmware único e estático, cujas aplicações e configurações tornam-se limitadas, no OpenWRT encontra-se um sistema de arquivos de livre acesso/escrita e com suporte a gerenciamento de pacotes, através do sistema ipackage, que diretamente permite ao desenvolvedor selecionar as aplicações que mais lhe são necessárias, tornando assim o sistema customizado para suas aplicações específicas. Em decorrência das restrições na disponibilidade de material, apenas três roteadores foram utilizados neste experimento. Notebook 1 (Servidor): foi utilizado como servidor um notebook modelo AMZ L81 cujas especificações constam abaixo Processador: Intel Core 2 DUO 1.86GHz 2MB L2 Placa-mãe: IntelTM Memória: 2x 512MB DDR2. Armazenamento: HD 40Gb Sata2 7200RPM Western Digital. Rede: Intel 10/100/1000. Rede Wireless: Atheros Wireless Sistema Operacional: Kubuntu Linux 7.10 Figura 11: Amazonpc L81 (Servidor)

45 Notebook 2 (Cliente): para o acesso remoto foi utilizado um notebook modelo AS 4550 com as seguintes características: 45 Rede Wireless: Broadcom BCM43XX Sistema Operacional: Kubuntu Linux 7.10 Como utiliza-se o acesso remoto no cliente, apenas a via de comunicação com o servidor é relevante, uma vez que todo o processamento é realizado no ponto central. Figura 12: Acer 4520 (Cliente) A tabela 2 descreve o esquema de endereçamento utilizado no experimento. Dispositivo Endereço IP Máscara de Rede Hostname Wlan AP1 Wlan AP2 Wlan AP3 Servidor server Cliente x cliente Tabela 2: Descritivo do endereçamento IP utilizado no experimento

46 46 Foram estabelecidas duas subredes distintas para a organização lógica da comunicação e identificação dos nós em cada tipo de interface. As interfaces sem fio dos APs foram configuradas com IPs de classe B, com endereço X.1, onde o X representa o AP em questão (variando de 1 a 3) e máscara de rede Nas interfaces cabeadas o servidor DHCP de cada ponto de acesso foi habilitado e configurado de modo que entregasse IPs de classe C de faixa X0.Y, na qual o X representa a sub-rede do AP(variando de 1 a 3) e o Y representa o número atribuido à cada cliente. 4.2 Cenários Para que as medições realizadas pudessem apresentar resultados satisfatórios, constatou-se a necessidade de fazer o estudo em ambientes heterogêneos, pois assim seria possível fazer uma abordagem de situações encontradas no cotidiano. Portanto este trabalho teve como objetivo a realização dos experimentos em dois cenários distintos, sendo o primeiro cenário Indoor, adotandose como base para coleta de dados uma rede provisória montada no Centro de Tecnologia de Informação e Comunicação (CTIC) - UFPA; e o segundo sendo um cenário Outdoor, que onde as aferições seriam realizadas na rede Mesh desenvolvida pelo Grupo de Trabalho de Redes Mesh da Universidade Federal do Pará Cenário Indoor Para o cenário indoor foi montada uma rede com topologia linear, pois havia disponibilidade de somente três Acess Point WRT54GS. Além disso, a limitação do espaço físico e os equipamentos não permitiam a definição de topologias mais complexas. Para melhor compreensão do cenário e da topologia aplicada, verifica-se na figura 13 um esquemático do prédio utilizado e suas medidas:

47 47 Figura 13: Local dos teste Indoor Na Figura 13 é possível observar a organização dos três acess points. Na Sala 1 foi fixado o servidor e o AP1 como nó de referência. Na sala 2 temos o AP2 que funcionará como salto adicional ou rota alternativa, e na sala 3 temos o AP3 conectado ao cliente tornando-os os pontos mais extremos da rede. Pode-se observar claramente que as topologias em questão associam-se a um triângulo escaleno, no qual nenhum dos três segmentos de reta que compõem a forma geométrica são iguais. Tal disposição foi fundamental para a realização dos testes pois como as distâncias entre os pontos de acesso são diferentes, um determinado pacote pode seguir duas rotas distintas que devem ser determinadas pelo algoritmo de roteamento, baseando-se na qualidade do enlace de cada um desses caminhos.

48 Metodologia As métricas adotadas para a avaliação dos ambientes foram a vazão de dados e o tempo de atraso de ida e volta (Round Trip Time - RTT), de modo a avaliar o comportamento do sistema quando submetido a uma rotina de inicialização de sessão e uma breve execução de tarefas. Para que pudesse ser simulada a utilização da estação de trabalho por um usuário comum, fez-se necessária a criação de um pequeno script, que é responsável por executar e finalizar programas pré-estabelecidos e que fora programado para auto-execução imediatamente após o inicio da sessão. Desta forma seriam evitadas variações de tráfego de rede geradas entre as medições advindas de alterações entre os experimentos, pois com a adoção de um comportamento procedural do inicio ao fim da coleta, tem-se então uma inicialização eqüitativa em todas as amostras de cada experimento. O script de simulação de tarefas está listado junto aos anexos deste documento. Os parâmetros da rede foram medidos por meio do uso do software GPL Wireshark [COMBS, 1998]. O software consiste em um Analisador de Protocolos de rede capaz de fornecer de forma abrangente diversos tipos de informação. Embora não seja desenvolvido especificamente para redes sem fio, o programa é capaz de capturar as informações sobre a rede de forma satisfatória ao experimento. O Analisador de Protocolos foi executado na máquina utilizada como servidor de aplicações, capturando as informações sobre o tráfego e armazenando-as em um arquivo de log, a partir do qual torna-se possível a extração de uma grande quantidade informações sobre as características do tráfego. Como medida de avaliação do tempo de resposta ao envio de pacotes na rede, foi utilizada a ferramenta traceroute, que consiste em obter o caminho que um pacote atravessa por uma rede de computadores até chegar ao destinatário. O traceroute também ajuda a detectar onde ocorrem os congestionamentos na rede, já que é dada, no relatório, a latência até cada máquina interveniente.

49 49 As medições foram repetidas, sendo coletadas dez amostras de cada experimento, com a finalidade de confirmar o comportamento médio e determinar os valores de confiabilidade para os mesmos, com exceção do experimento utilizado como base de comparação, no qual não houve comunicação sem fio. Este último experimento foi realizado apenas uma vez. Ao longo das medições os valores de ETX foram monitorados utilizando-se a interface Web dos roteadores, por meio do plugin olsrd-mod-httpinfo citado anteriormente. 4.4 Experimentos Para que pudesse ser melhor observada a influência dos saltos na qualidade da sessão, o estudo de caso foi dividido em três experimentos. Abaixo seguem maiores detalhes: Experimento 1: Nessa primeira etapa, a coleta de dados deu-se em uma rede cabeada, na qual estavam ligados tanto o servidor quanto o cliente no mesmo concentrador. Com a coleta de dados neste cenário, foi possível analisar o comportamento da comunicação entre servidor e cliente em uma situação relativamente próxima do ideal, na qual torna-se possível obter um melhor desempenho do sistema, uma vez que os dados trafegarão em altas taxas de transmissão e baixas taxas de atraso se comparados ao meio sem fio. O comando traceroute apresentou a seguinte saída para o experimento 1: traceroute to ( ), 30 hops max, 40 byte packets 1 cliente ( ) ms ms ms traceroute to ( ), 30 hops max, 40 byte packets 1 cliente ( ) ms ms ms traceroute to ( ), 30 hops max, 40 byte packets 1 cliente ( ) ms ms ms Observando a saída do comando traceroute depreende-se que o número 1 representa a quantidade de HOPs, e portanto valida a configuração de uma rota

50 50 comum aos integrantes de rede, ou seja, na situação exposta tanto servidor quanto cliente estavam no mesmo nó (AP1). Experimento 2: Neste experimento os roteadores foram utilizados em suas potências de transmissão definidas como padrões de operação (19dB), o que permitiu a conexão direta entre os nós AP1 e AP3, (vide marcação correspondente na figura 13). Para essa configuração o comportamento desejado era a não adoção da rota alternativa, pois já que todas as potências de transmissão eram iguais e suficientes pra abranger uma área de cobertura muito maior que o espaço utilizado no experimento, o fator distância não seria um impecílio na degradação do sinal, portanto neste caso, o nó AP2 seria descartado. Abaixo constam as saídas do comando traceroute para a segunda situação: traceroute to ( ), 30 hops max, 40 byte packets 1 ap3 ( ) ms ms ms 2 ap1 ( ) ms ms ms 3 cliente ( ) ms ms ms Observa-se na saída do traceroute para este experimento a presença dos nós 1 e 3, representando AP3 e AP1 respectivamente, o que mostra claramente que desta vez os pacotes trafegaram até o destino mediante a realização de 1 salto (singlehop). Além disso torna-se visível também um maior atraso na entrega de pacotes em relação a situação ideal adotada no experimento 1. No sub-item 4.5, será feita uma análise mais detalhada do comportamento da rede e dos dados coletados para cada um dos cenários. Experimento 3: Consistiu no ajuste da potência de transmissão dos 3 Access Points, de modo que as rotas de acesso entre os pontos extremos fossem estabelecidas por meio do nó intermediário. As potências foram todas reguladas para 4 db, que correspondia ao limite em que as rotas entre todos os nós da rede eram estabelecidas, porém, como na topologia implementada nenhuma das rotas eram equidistantes, a queda na qualidade do enlace representado pelo maior segmento de reta entre cliente e servidor foi bastante perceptível. Verificou-se um considerável aumento da latência e ETX, com a perda de aproximadamente 60% dos pacotes devido à distância e conseqüente dificuldade de alcance do sinal.

51 51 Devido a esta notável degradação do sinal o protocolo OLSR adotou o nó intermediário como rota alternativa àquela que encontrava-se instável (Figura 13). Abaixo constam as saídas do comando traceroute, evidenciando a trajetória estabelecida através do nó intermediário: traceroute to ( ), 30 hops max, 40 byte packets 1 ap3 ( ) ms ms ms 2 ap2 ( ) ms ms ms 3 ap1 ( ) ms ms ms 4 cliente ( ) ms ms ms Neste caso ocorre a inserção do nó AP2 como rota intermediária adotada pelos pacotes até o destino e ratifica que este comportamento aconteceu devido a degradação da qualidade do sinal no caminho direto. A seguir serão mostradas em detalhes todas as situações abordadas, os dados aferidos e um comparativo geral. 4.5 Resultados Os dados coletados com o Analisador de Protocolos foram armazenados em arquivo log, cuja visualização permite observar as principais características da comunicação por meio do protocolo X Window. O trecho mostrado na figura 14 permite observar o tráfego de pacotes relativos à negociação de uma sessão: Figura 14: Log da negociação de uma sessão remota (wireshark)

52 52 No trecho destacado é claramente observável a aplicação da teoria de comunicação do protocolo XDMCP anteriormente abordada. Toda a execução do processo de negociação de sessão pode ser observada nas cinco primeiras linhas do log em questão. Para que pudessem ser avaliados os resultados, os dados coletados pelo Analisador de Protocolos foram exportados para o formato de valores separados por vírgula (Comma Separated Values - CSV), permitindo sua manipulação por meio de planilhas eletrônicas. Os dados foram classificados e foram geradas as médias de cada experimento, bem como seu desvio padrão. Foram gerados gráficos, que viabilizaram a visualização dos resultados e da média destes Resultados do experimento 1 O tráfego do experimento 1, é mostrado através do gráfico da figura 15: Figura 15: Tráfego de pacotes do experimento 1 A média de tráfego de pacotes obtida é 298,3 pacotes/s.

53 Resultados do experimento 2 O tráfego médio de pacotes das dez amostras do experimento 2 é mostrado através do gráfico da figura 16: Figura 16: Tráfego de pacotes do experimento 2 O desvio padrão médio obtido paras as médias de quantidades de pacotes entre as dez amostras é de Porém, o desvio atinge valores consideravelmente baixos, da ordem de décimos, para os momentos de baixa vazão (intervalos 14s-26s, 34s-46s e 58s-60s) e valores altos nos momentos de pico, (atingindo o valor máximo de 581 pacotes no instante 56s).