Curso de Engenharia de Computação CONCEITOS, CARACTERÍSTICAS E PROPOSTA DE IMPLEMENTAÇÃO DE LABORATÓRIOS VIRTUAIS USANDO PROTOCOLOS HTTP E SNMP

Transcrição

1 Curso de Engenharia de Computação CONCEITOS, CARACTERÍSTICAS E PROPOSTA DE IMPLEMENTAÇÃO DE LABORATÓRIOS VIRTUAIS USANDO PROTOCOLOS HTTP E SNMP Marcelo Augusto Gonçalves Bardi Itatiba São Paulo Brasil Dezembro de 2008

2 ii Curso de Engenharia de Computação CONCEITOS, CARACTERÍSTICAS E PROPOSTA DE IMPLEMENTAÇÃO DE LABORATÓRIOS VIRTUAIS USANDO PROTOCOLOS HTTP E SNMP Marcelo Augusto Gonçalves Bardi Monografia apresentada à disciplina Trabalho de Conclusão de Curso II, do Curso de Engenharia da Computação da Universidade São Francisco, sob a orientação do Prof. Ms. Sidney Pio de Campos, como exigência parcial para conclusão do curso de graduação. Orientador: Prof. Ms. Sidney Pio de Campos Itatiba São Paulo Brasil Dezembro de 2008

3 iii Conceitos, características e proposta de implementação de laboratórios virtuais usando protocolos HTTP e SNMP Marcelo Augusto Gonçalves Bardi Monografia defendida e aprovada em 11 de dezembro de 2008 pela Banca Examinadora assim constituída: Prof Ms. Sidney Pio de Campos (Orientador) USF Universidade São Francisco Itatiba SP. Prof Ms. José Aparecido Carrilho (Membro Interno) USF Universidade São Francisco Itatiba SP. Prof Ms. Thales de Társis Cezare (Membro Interno) USF Universidade São Francisco Itatiba SP. O registro de arguição e defesa consta de ATA DE ARGUIÇÃO FINAL DE MONOGRAFIA, devidamente assinada e arquivada na Coordenação do curso.

4 iv O começo de todas as ciências é o espanto de as coisas serem o que são Aristóteles In: Aristóteles. Metafísica

5 v A meus pais, Ana e Sergio, os quais me forneceram refúgio e coragem durante esta jornada.

6 vi Agradecimentos Agradeço a Deus pela coragem que me deu nos momentos difíceis da realização deste trabalho, e também pelas alegrias decorrentes do mesmo. Ao Prof. Sidney Pio de Campos por seus preciosos ensinamentos, sugestões e críticas, além de sua compreensão, conselhos e amizade no decorrer de todo este trabalho, além de ser o incentivador para iniciar no mundo da programação e no mundo UNIX. Ao Prof. Cláudio Kiyoshi Umezu por sua inestimável ajuda na montagem do sistema de teste via hardware. Ao Prof. Alencar de Melo Junior pelas orientações recebidas durante a disciplina Trabalho de Conclusão de Curso II, além de ter sido um dos incentivadores da realização deste projeto quando Coordenador do Curso de Engenharia de Computação. Ao Prof. Rodrigo Chavez Monteiro do Prado por auxiliar durante a fase inicial do projeto, a definir um escopo de pesquisa e fornecer orientações iniciais para o trabalho, durante a disciplina Trabalho de Conclusão de Curso I. Ao Prof. André Leon Sampaio Gradvohl pelo apoio recebido durante a fase de publicação dos resultados deste trabalho. Aos Prof. Antonio de Assis Bento Ribeiro e Prof. Derval dos Santos Rosa pela ajuda na fase de maturação do projeto, fornecendo primitivas para a definição do tema e recursos para que o mesmo pudesse ser proposto. Por fim, agradeço à Universidade São Francisco, instituição que me abrigou durante esse período, e ao corpo docente do curso de Engenharia de Computação, aos quais devo o aprendizado para o início na minha carreira profissional.

7 vii Sumário Lista de Siglas...ix Lista de Figuras...xi Resumo...xii Abstract...xiii 1 Introdução Objetivos Organização do trabalho ASPECTOS TEÓRICOS Laboratórios virtuais Evolução Questões de projeto Arquitetura e implementação dos laboratórios virtuais Controle e monitoramento locais (Software servidor) Controle e monitoramento remotos (Software cliente) Segurança, agendamento e trabalho colaborativo Protocolos de comunicação HyperText Transfer Protocol (HTTP) Simple Network Management Protocol (SNMP) METODOLOGIA Pré-Requisistos Especificações Mínimas Necessárias Ferramentas de Desenvolvimento Hardware de teste Desenvolvimento Determinação da Arquitetura Configuração do Servidor Apache Configuração da Biblioteca Net-SNMP Desenvolvimento das Ferramentas de Teste RESULTADOS E DISCUSSÃO Análise da Arquitetura Proposta Testes de Integração Controle de motor de passo Coleta de informações Dificuldades encontradas Conclusão Contribuições Extensões...24 Referências Bibliográficas...26 Bibliografia consultada...28

8 viii Apêndice 1 Arquivo de configuração /etc/snmp/snmpd.conf...29 Apêndice 2 Página inicial do protótipo /var/www/motor.psp...31 Apêndice 3 Script Python para motor de passo rotacionar automaticamente a direita / var/www/execsnmp_a_d.psp...32 Apêndice 4 Código C para motor de passo /var/www/motor.c...33 Apêndice 5 Script Python para coletar informações, armazenar em base de dados e exibir ao cliente /var/www/execsnmp_temp.psp...35 Apêndice 6 Exemplos de telas de execução do sistema Tela inicial do protótipo, apresentando as opções ao usuário Tela apresentando o fim da operação de rotação do motor de passo Resultado da operação snmpwalk sobre o objeto que mapeia o motor de passo logo após sua execução...38

9 ix Lista de Siglas AJAX API ASCII ASN.1 ASP BSD CAN CFM CGI CMOS DHCP FTP GNU GPIB HTTP IETF IMAP IP JRE JSP MIB MIME MIT P2P PIC PLD RFC RTP SMTP SNMP SQL SOAP TCP UDP URI URL USB XML Asynchronous Javascript And XML Application Programming Interface American Standard Code for Information Interchange Abstract Syntax Notation number One Active Server Pages Berkeley Software Distribution Campus Area Network Cold Fusion Markup Language Common Gateway Interface Complementary Metal Oxide Semiconductor Dynamic Host Configuration Protocol File Transfer Protocol GNU s Not Unix General Purpose Interface Bus HyperText Transfer Protocol Internet Enginnering Task Force Internet Message Access Protocol Internet Protocol Java Runtime Environment JavaServer Pages Management Information Base Multipurpose Internet Mail Extensions Massachusetts Institute of Technology Peer-TO-Peer Programmable Interface Controler Programmable Logic Device Request for Comments Real Time Protocol Simple Mail Transfer Protocol Simple Network Management Protocol Structured Query Language Simple Object Access Protocol Transmission Control Protocol User Datagram Protocol Uniform Resource Identifier Uniform Resource Locator Universal Serial Bus extensible Markup Language

10 x

11 xi Lista de Figuras Figura 1: Parâmetros para o desenvolvimento do projeto de laboratórios virtuais...6 Figura 2: Arquitetura genérica de laboratório virtual...7 Figura 3: Esquema de uma transação via protocolo HTTP...12 Figura 4: Dispositivo de hardware utilizado para teste, incluindo motor de passo e placa de comunicação...15 Figura 5: Arquitetura proposta para o laboratório virtual, empregando somente software livre e protocolos de comunicação de domínio público...16 Figura 6: Diagrama de seqüência para uma transação do laboratório virtual...17

12 xii BARDI, Marcelo Augusto Gonçalves. Conceitos, características e proposta de implementação de laboratórios virtuais usando protocolos HTTP e SNMP p. Monografia (Bacharelado em Engenharia de Computação) Curso de Engenharia da Computação da Universidade São Francisco, Campus de Itatiba. Resumo Com o crescente desenvolvimento de atividades que exijam um processamento prolongado e contínuo, o conceito de laboratórios virtuais (ou weblabs) vem se tornando cada vez mais comum. O objetivo deste trabalho é apresentar um protótipo de laboratório virtual que permita a conexão de quaisquer equipamentos, tendo-se como base os principais protocolos de comunicação de domínio público. A arquitetura proposta é baseada em três entidades: servidores de processo (SP), clientes (CLI) e service broker (SB), sendo este responsável pelas negociações entre os clientes e os servidores de processo por meio de rotinas Python Service nele implementadas. A comunicação CLI-SB é realizada por meio de requisições HTTP, enquanto que a interação SB-SP utiliza o protocolo de gerenciamento de redes (SNMP). Testes de integração foram realizados e foi possível utilizar dois modos de experimentos: passando parâmetros a um motor de passo e coletando informações a partir de máquinas conectadas à rede e armazenando-as em base de dados. PALAVRAS-CHAVE: laboratório virtual, protocolos, SNMP, Python Service, software livre

13 xiii BARDI, Marcelo Augusto Gonçalves. Definition, characteristic and prototype for web laboratories using HTTP and SNMP protocols p. Monograph (Bachelor in Computer Engineering) Course of Computer Engineering, São Francisco University, Campus Itatiba. Abstract The wide development of activities that require a non-interrupt processing and the reduction of human resources to control them have led to the study of web laboratories. The aim of this work is to obtain a prototype for a web laboratory that allows the connection of whichever equipments, taking hands of both communication protocols of public domain (HTTP and SNMP) and free software. The architecture is composed of three entities: process servers (PS), clients (CLI) and service broker (SB), which is responsible for negotiating the transactions PS-CLI by means of Python Server routines. The CLI-SB communication is performed by HTTP, whereas the SB-PS interactions use the network management protocol (SNMP). Tests were performed where it was possible both to set parameters into a path motor and retrieve information from controlled equipments, which were later stored into a database. KEYWORDS: web laboratory, protocols, SNMP, Python Service, free software

14 1 1 INTRODUÇÃO O controle de processos e atividades é algo que vem intrigando a humanidade desde o início dos tempos modernos, sendo seus ideais presentes em todos os momentos e fatos históricos marcantes, culminando nas Primeira e Segunda Revoluções Industriais. Os exemplos mais claros seriam o controle de máquinas na produção de bens de consumo, idealizados por Henry Ford (séculos XIX e XX) e a exploração de ambientes agressivos aos seres humanos, tais como as profundezas dos oceanos e a imensidade do universo, com dispositivos totalmente controlados de forma remota (segunda metade do século XX e início do século XXI) (Bardi et al., 2008). Atualmente, com os constantes avanços nas técnicas de controle de processos, não mais se necessita a presença constante e, de certa forma, atuante de quaisquer atores humanos para que uma atividade possa ser realizada em plenitude. Pelo primeiro adjetivo, uma presença constante é substituída por uma rede de comunicação remota que permite que usuários acompanhem o desenrolar de certa atividade a distância. Já pela segunda qualidade, o agente não necessita ser vigilante ao sistema de atividade durante todo o seu desenvolvimento, de modo a disponibilizar seu foco de atenção para outras atividades que também o requisitam. Dessa forma, pode-se sugerir que as formas de controle descriminadas anteriormente podem ser implementadas usando diversas ferramentas que a Computação nos oferece. Para a questão do controle remoto, pode-se empregar a rede mundial de computadores, e os protocolos de domínio público que a compõem, na elaboração de uma arquitetura simples e poderosa para quaisquer tipo de processos. Com relação à vigilância e zelo pela atividade, ferramentas simples permitem que uma atividade seja perfeitamente protegida de quaisquer erros externos (atores mal-intencionados agindo sobre o sistema) e internos (problemas decorrentes da execução da atividade) (Bardi et al., 2008). 1.1 Objetivos Este trabalho tem por objetivo estudar a tecnologia de laboratórios virtuais através de diversos enfoques e apresentar um protótipo de laboratório virtual que permita a conexão de quaisquer equipamentos para conexão de quaisquer equipamentos como entrada ao mesmo, tendo-se como base as arquiteturas atualmente propostas e os principais protocolos de comunicação de domínio público disponibilizados pela rede mundial de computadores.

15 2 Além disso, pretende-se criar um sistema gráfico que permita visualizar o ensaio em andamento de forma local no laboratório onde esteja sendo realizado o experimento ou remotamente, através da Internet. Ainda, a aplicação deverá ser capaz de alterar parâmetros de configuração do ensaio e outros serviços adicionais aos usuários cadastrados em sua base de dados, bem como fornecer um relatório explicativo e detalhado sobre o ensaio quando solicitado pelo usuário. 1.2 Organização do trabalho Esta monografia apresenta uma revisão bibliográfica sobre os principais tópicos abordados, tratados na seção Aspectos Teóricos, com a definição formal de laboratório virtual, suas principais arquiteturas e implementações, com um enfoque maior sobre o emprego de softwares livres. Ainda serão apresentadas algumas questões relevantes de projeto que direcionaram esta pesquisa. Mais detalhadamente, devem ser discutidos alguns protocolos de comunicação que possam ser adotados à arquitetura do laboratório virtual, principalmente o HyperText Transfer Protocol (HTTP) e Simple Network Management Protocol (SNMP), bem como formas de tratamento de informações para processamento contínuo de informações. Em seguida, a seção Técnicas e Metodologia de Desenvolvimento apresenta as ferramentas utilizadas e uma descrição detalhada das etapas de desenvolvimento e implementação do projeto, principalmente o esquemático da arquitetura proposta, com todos os seus protocolos e detalhes internos de operação, descrevendo detalhadamente cada entidade envolvida na arquitetura. Já a seção Resultados e Discussões ilustra os resultados mais importantes deste projeto,, incluindo um roteiro de testes completo. Por fim, a seção Conclusões destaca as idéias marcantes obtidas durante o desenvolvimento de tal trabalho, bem como sugestões de expansão do mesmo e algumas das contribuições que este projeto veio trazer para a comunidade científica engajada na pesquisa sobre os laboratórios virtuais. Nos Apêndices são encontrados os scripts utilizados para a configuração do sistema (Apêndice 1), para a etapa de testes (Apêndices 2-6).

16 3 2 ASPECTOS TEÓRICOS Esta seção apresenta um levantamento bibliográfico que amparará as observações realizadas durante o desenvolvimento desta monografia. Além disso, deve-se também apresentar algumas definições e explicações que se fazem necessárias para melhor compreender a relevância nas considerações do tema. 2.1 Laboratórios virtuais Com o advento da Internet como principal meio de comunicação entre pessoas geograficamente distantes, uma gama de aplicações desenvolvidas especialmente para a World Wide Web tem despontado cada vez mais com maior freqüência (Fjeldly e Shur, 2003). Aliados a esse conceito, pode-se citar técnicas cada vez mais avançadas de computação móvel (Miyake, Hall e Koschmann, 2001) e de automação (Markin e Whalen, 2000) e robótica (Guimarães et al, 2003) como maximizadores desse processo de popularização de aplicações Internet. Além disso, pesquisas têm sido realizadas para que possa também empregar a Internet como substituta a recursos humanos para que os mesmos não sejam empregados em atividades de supervisão que podem ser realizadas remotamente com a integração de hardware, software e a rede mundial de computadores para sua realização. Assim, se definiu os laboratórios virtuais. De acordo com Sandhu (2002), a prática de automação de experimentos permite que grupos de pessoas possam, em conjunto, estudar, em tempo real, a ocorrência de determinado fenômeno e expor suas idéias, mesmo que distantes do experimento realizado. No trabalho citado, imaginou-se utilizar sistemas automáticos na realização de experimentos constantes do curso de Engenharia Mecânica do MIT e que pudessem ser visualizados remotamente, via webcam ou vídeo-conferência. Laverty Jr. (2004) realizou estudos sobre um laboratório virtual desenvolvido para análises mecânicas em ambientes marinhos, de modo a estudar conceitos de hidrodinâmica marinha através de experiências laboratoriais. De acordo com o referido trabalho, o laboratório virtual permite que usuários acessem remotamente experimentos em andamento e a processar informações já coletadas e armazenadas nos bancos de dados do sistema. Sandhu (2002) avaliou a implementação de laboratórios virtuais para fins pedagógicos, utilizando preceitos de educação a distância, procurando cultivar entre os

17 4 discentes os espírito de novas descobertas e de cooperativismo. Essas mudanças permitiram que novos experimentos físicos, módulos de aprendizagem via Web, bem como ambientes educacionais mais prazerosos para os alunos fossem adotados pelo Departamento de Engenharia Mecânica do MIT. Esse sistema ficou conhecido como ilab. Khan (2000) apresenta algumas outras características dos experimentos acessados via Web: Requisitos mínimos de pessoal capacitado para operação; Configuração unificada para usuários múltiplos; Equipamentos laboratoriais podem ser acessados de qualquer lugar em qualquer momento; Redução no tempo de treinamento; Redução nas questões de risco pessoal com o aumento de segurança; Capacidade de interação com outros usuários para discussão dos resultados à distância. Ainda de acordo com Sandhu (2002), critérios de custo e espaço físico são considerados como negativos para a realização de atividades laboratoriais, enquanto que laboratórios remotos acessíveis via Web fornecem um ambiente para que os alunos possam usufruir eficientemente dos equipamento do laboratório, dando aos mesmos o conforto de conduzir determinado experimento a partir de um browser Web. Estes experimentos podem ter diferenciados graus de complexidade e também estar localizados em espaços geograficamente distribuídos, permitindo que uma grande gama de experimentos possa ser realizada pelos laboratórios virtuais. A abordagem de experimentos acessíveis via web podem perfeitamente ser enquadrados nos moldes dos atuais contextos da globalização da informação, incluindo alterações nas etapas de preparação, montagem, acompanhamento e divulgação dos resultados da pesquisa (Khan, 2000), eliminando-se assim totalmente as fronteiras físicas das paredes de um laboratório. Ainda um ponto a ser considerado é que uma única configuração do laboratório pode ser utilizada tanto para fins educacionais quanto como método de pesquisa por instituições de todo o mundo.

18 Evolução O projeto ilab desenvolvido pelo MIT foi pioneiro com a idéia de englobar experiências remotas com conceitos pedagógicos de ensino à distância. Liderado pelo Prof. Jesús A. del Álamo, foi primeiramente implantado na forma de um laboratório virtual de microeletrônica, de modo que os alunos pudessem adquirir dados dos mais modernos hardwares CMOS presentes no Centro de Desenvolvimento Alpha da Compaq, localizado no estado americano de Massachusetts (Sandhu, 2002). Devido ao grande sucesso do projeto, posteriormente este foi também extendido para diversas disciplinas dos cursos de Engenharia Civil, Engenharia Química, Aeronáutica e Astronáutica, e Arquitetura. Khan (2000) incorporou ao projeto ilab um módulo de controle de um sistema trocador de calor, primeiramente com a idéia de simulação de um sistema, e posteriormente adaptada para controlar um dispositivo físico que realizasse tal tarefa, dando então início ao controle físico de equipamento, e não somente da simulação. Atualmente, os laboratórios virtuais vêm se tornando cada vez mais populares, pois são capazes de conduzir um experimento a qualquer hora e de qualquer lugar (Guimarães et al, 2003; James et al, 2004). García-Zubia e colaboradores (2006) ainda afirmam que o uso de laboratórios virtuais está crescendo em importância devido à necessidade de se descentralizar funções em laboratórios e salas de aula, permitindo que seus recursos estejam disponíveis em qualquer lugar e em qualquer momento. 2.2 Questões de projeto No planejamento de sistemas que possuem certa complexidade de implementação e que várias entidades estejam presentes, George (1999) diz que cada ciclo do desenvolvimento pode se beneficiar de seus estados predecessores, desde que exista uma conexão de/para o próximo passo do desenvolvimento. Assim, para o planejamento de sistemas de laboratórios virtuais, as seguintes etapas de planejamento podem ser úteis, tal como descrito por Sandhu (2002): Desenvolvimento conceitual, onde os objetivos e as ações a serem adotadas para a realização dos mesmos são traçados; Desenvolvimento inicial dos módulos web, com o número de módulos a serem adicionados ao sistema, suas funcionalidades e as formas de comunicação com os demais componentes;

19 6 Exploração individual dos módulos web, com testes isolados em cada módulo, inclusive inserindo contatos diretos com os usuários, verificando suas observações de cada ação realizada pelo sistema; Integração total, onde todos os módulos são interligados entre si através dos sistemas de comunicação propostos, e os usuários passam a ter uma visão global de todo o sistema. Ainda, o laboratório virtual deve se apresentar como uma ferramenta didática e profissional ao usuário, além de favorecer a universalidade de conexões ao mesmo, e também de vanguarda, permitindo que o sistema apresente sempre às mais novas atualizações em tecnologias e dispositivos (Fig. 1). Figura 1: Parâmetros para o desenvolvimento do projeto de laboratórios virtuais. 2.3 Arquitetura e implementação dos laboratórios virtuais Como questões de implementação, deve-se considerar que o laboratório virtual promova uma forma de fácil navegação pelo usuário do sistema e promovendo uma sistematização de suas atividades enquanto estiver atuando sobre a interface remota. Assim, pode-se dividir essas funcionalidades em quatro classes distintas (Khan, 2000) (Fig. 2): Software para controle local e monitoramento do equipamento a partir do servidor; Software para controle remoto e monitoramento do equipamento a partir do cliente; Cadastramento, autenticação e agendamento do experimento; Interações entre múltiplos usuários.

20 7 Dessa forma, baseado nestes critérios, pode-se observar uma evolução na forma de implementar os sistemas, de modo que pode-se enumerá-las em quatro arquiteturas distintas, a saber: INTRANET INTERNET/ INTRANET SERVICE BROKER SERVIDORES DE PROCESSOS PROTOCOLOS DE COMUNICAÇÃO CLIENTES Figura 2: Arquitetura genérica de laboratório virtual. Solução firmada na criação de sockets e no uso de applets proprietárias, descrita por García-Zubia e colaboradores (2006) implementado em linguagem C e se comunicando com o servidor por meio de sockets BSD. Esta arquitetura foi desenvolvida como protótipo e utilizada somente pelos próprios desenvolvedores. Solução baseada em Web (García-Zubia, 2006): nesta implementação, o lado servidor era composto de (a) um servidor Python o qual se comunicava através de porta serial com um controlador PIC ligado a um PLD e (b) uma webcan do servidor que transmitia as imagens capturadas. Essa solução permitia que usuários acessassem o sistema a partir de um browser web de qualquer lugar geográfico. Porém, problemas com a segurança foram detectados, já que um alerta de invasão era disparado sempre que o usuário fazia o download do applet controlador, visto que essa aplicação requeria acesso ao sistema de arquivos do computador de modo a realizar o upload de um arquivo com a nova lógica de programação. Além disso, essa implementação ainda necessitava de duas portas constantemente abertas no

21 8 firewall do servidor: uma para o servidor da webcam e outra para o servidor de controle, o que causou problemas no gerenciamento do firewall. Solução baseada em Web e AJAX: uma única aplicação cliente é apresentada no navegador dos usuários e se comunica com o servidor através de HTTP. É implementada com um sistema seguro de firewall programado em AJAX. O principal benefício deste recurso é que funciona em qualquer navegador web, sem a necessidade da instalação de quaisquer plug-ins. A aplicação cliente é assim uma solução pura de HTML/JavaScript, seguindo o modelo de interação web AJAX. Essa tecnologia vem atualmente sendo aplicada com sucesso em aplicações web sofisticadas, tais como Gmail, Google Maps e Flickr (García-Zubia, 2006). O lado do servidor é composto de elementos das arquiteturas descritas anteriormente e também de uma aplicação ASP.NET, a qual oferece uma interface de serviços web SOAP às aplicações cliente. Nesta implementação, o laboratório virtual suporta tanto Microsoft Windows quanto GNU/Linux, além de não depender mais de Java. Ainda, pode-se trabalhar com ela em ambientes móveis que operam com sistema operacional Symbian e navegador Opera. Solução Web baseada em AJAX e em micro-servidor: Solução baseada em web, com firewalls seguros e alta escalabilidade (fornece acesso a muitos dispositivos programáveis via IP), permitindo que grupos de usuários acessem simultaneamente quaisquer dispositivos programáveis conectados em rede, além de que usuários multiplataformas interajam com o lado servidor. As linguagens de implementação foram unificadas em Python, mantendo segurança e compatibilidade com as demais arquiteturas. Ainda, a presença de microservidores adicionam a cada dispositivo controlável um endereço IP distinto e assim capacidade de serem programados remotamente, de modo que toda a comunicação agora é baseada em Internet. Os micro-servidores possibilitam muitas aplicações: uso de XML linguagem de facto para troca de dados, criação de laboratórios virtuais autônomos sem a necessidade de um servidor centralizado, fácil configuração de uma rede local Intranet entre os dispositivos, os baixos custos dos micro-servidores, sua versatilidade e desempenho levam a vislumbrar tal arquitetura como satisfatória às aplicações correntes. Todavia, verifica-se que o uso de micro-servidores leva a uma mudança no paradigma cliente-servidor em cujas bases se encontravam as tecnologias de laboratórios virtuais anteriores, tendendo agora a ser inserida no contexto de redes descentralizadas P2P.

22 9 O projeto ilab, do MIT, leva em conta vários módulos que fornecem ao usuário um meio independente de exploração dos experimentos (Sandhu, 2002), empregando para tanto applets Java, ASP e SQL Server para apresentar conteúdo dinâmico e interativo que enfoque os tópicos abordados por cada disciplina. Cada módulo web apresenta oito componentes, destacando simulações e exercícios de fixação de conteúdos abordados. Nas próximas subseções, analisa-se cada um dos parâmetros apresentados por Khan (2000), bem como algumas das ferramentas de desenvolvimento descritas na literatura pesquisada Controle e monitoramento locais (Software servidor) O lado servidor deve fornecer controle local bem como controle remoto ao equipamento. Essa versão local do software de controle e monitoramento tem como função recuperar os dados do equipamento, controlar a entrada de parâmetros necessários à configuração do equipamento (inputs), publicar os dados recuperados na Internet e permitir que qualquer máquina cliente possa controlar o equipamento da Internet. Além disso, esse servidor deve fornecer um nível se segurança tal que somente determinados parâmetros do experimento possam ser configurados remotamente, e assim ocultando os demais do usuário. Isso se torna necessário para que um usuário acidentalmente não altere parâmetros críticos e que podem comprometer a vida útil e até mesmo a integridade do equipamento controlável (Khan, 2000). De acordo com Sandhu (2002), os requisitos mínimos para implementação do lado servidor do laboratório virtual seriam: Servidor configurado para gerar conteúdo dinâmico; Base de dados; Conjunto de ferramentas para desenvolvimento de sites Web; Capacidade de multithreading. Além disso, é necessário que no lado servidor existam drivers específicos para cada equipamento a ser controlado, os quais podem ser fornecidos pelo próprio revendedor ou então desenvolvidos pelo responsável pelo laboratório virtual (Khan, 2000). Para o lado servidor, Khan (2000) lançou mão do ambiente LabView, uma linguagem de programação de 4ª geração, desenvolvida pela National Instruments, pois, de acordo com o referido trabalho, este já apresenta um conjunto de rotinas pré-implementadas que reduz

23 10 consideravelmente o tempo de desenvolvimento. Além disso, o LabView possui também um módulo de publicação de dados na web conhecido por DataSocket Server, também desenvolvido pela National Instruments, o qual atribui para cada experimento uma URI específica Controle e monitoramento remotos (Software cliente) É necessário que uma aplicação web possa atuar no terminal cliente do sistema, através dos quais usuários remotos possam controlar o equipamento e assim realizar seus experimentos. Já para os usuários do sistema, somente é requerido que exista um navegador Web e o ambiente de execução Java (JRE), além de configurações que permitam o acesso do usuário à rede que possua o sistema ilab, tal como endereços DHCP, já que a rede ilab foi primeiramente descrita como uma CAN de acesso restrito (Sandhu, 2002). Khan (2000) empregou um conjunto de APIs para fazer a conexão entre o clientes e o DataSocket (seção 2.2.1), utilizando para tanto os recursos de ActiveX e de Java; entretanto, o autor afirma que a escolha destas APIs devem estar ligadas com a escolha do navegador com o qual o cliente estará interagindo com o sistema. Em seu trabalho, assim, foi adotado os applets Java por serem independentes do navegador Segurança, agendamento e trabalho colaborativo O número de usuários que podem atuar simultaneamente no controle e na realização de experimentos deve depender da própria capacidade do equipamento físico e do sistema implementado, e assim devem existir módulos que permitam o controle de admissão de usuários e de experimentos, com filas ou outras estruturas mais complexas. Ainda, deve ser interessante que pelo menos dois níveis de privilégios sejam também fornecidos aos usuários, de modo que a integridade do experimento seja garantida e que somente o responsável pelo mesmo possa alterar os parâmetros da atividade (Sandhu, 2002). Por fim, informações úteis para uma constante melhora do serviço por ser obtida através da realização de pesquisas de satisfação periódicas entre os usuários e as análises de relatórios de log do sistema, o qual deve conter registros de acessos, tentativas de extravio de informações, bugs durante processamento de experimentos e outros dados, tal como sugerido por Sandhu (2002).

24 11 Algumas das ferramentas mais empregadas para a implementação de tais ações, tal como citado por seriam as linguagens de script como ASP, JSP, CFM e CGI. Para o banco de dados, pode-se citar o Microsoft Access, Microsoft SQL, Oracle e MySQL. Khan (2000) empregou ASP.NET como ambiente de implementação de agendamento, registro e autenticação no sistema, visto que o mesmo permite um fácil desenvolvimento, integração com banco de dados e configuração simples do lado servidor. Já como tecnologia de banco de dados, o Microsoft SQL Server foi adotado por permitir um maior controle sobre os dados e a facilidade de se trabalhar com stored procedures. Assim, verifica-se que a escolha das ferramentas de desenvolvimento e de integração entre os módulos do projeto de laboratório virtual se mostra como uma das etapas mais importantes do projeto, visto que as mesmas determinarão os limites das funcionalidades que podem ser implementadas (Khan, 2000). 2.4 Protocolos de comunicação Além da definição estática das funções de cada entidade do sistema de laboratório virtual, a forma como as mesmas se comunicam também devem ser bem planejadas e definidas (Stallings, 2005). Tanembaum (2003) define esse acordo ou regras entre as partes que se comunicam como protocolos de comunicação. Ainda, cabe aos protocolos gerar uma forma única e compreensível por ambos os extremos da rede (Soares et al, 2003). Tradicionalmente, os protocolos mais utilizadas são definidos pelo órgão padronizador IETF em forma de RFC s (Tanembaum, 2003) Um protocolo é definido por três elementos chaves (Stallings, 2005): Sintaxe, que define a forma de organização dos blocos de dados; Semântica, que inclui as informações de controle para sincronização e tratamento de erros; Temporização, que trata das questões de seqüenciamento e de velocidade de transmissão. Os principais protocolos atualmente utilizados seriam IP, DHCP, TCP, HTTP, SNMP, FTP, SMTP e IMAP. Todavia, apesar da enorme quantidade de protocolos existentes, para esse trabalho, serão analisados o HTTP e o SNMP.

25 HyperText Transfer Protocol (HTTP) O HyperText Transfer Protocol (HTTP), definido na RFC 2616, é um protocolo de aplicação responsável pelo tratamento de pedidos/respostas entre cliente e servidor na World Wide Web, orientado a conexão e stateless (Kurose, 2006; Stallings, 2005). As solicitação trafegam por meio de códigos ASCII no formato MIME (Tanembaum, 2003). Usa o TCP como protocolo da camada de transporte (Kurose, 2006). De acordo com Stallings (2005), o HTTP utiliza o modelo cliente-servidor, como a maioria dos protocolos de rede, baseando-se na comunicação entre os agentes de usuários (browsers) e os servidores de origem, onde o primeiro envia uma solicitação ao segundo, efetuando uma conexão, e este, por sua vez, retorna o conteúdo solicitado ao primeiro, desfazendo a conexão. A Figura 3 apresenta esta dinâmica. GET /path/rec.html HTTP CLIENTE /path/rec.html SERVIDOR Figura 3: Esquema de uma transação via protocolo HTTP. Tanembaum (2003) apresenta alguns dos principais métodos implementados pelo protocolo HTTP: Get: agente de usuário solicita do servidor de origem uma página de informação; Put: agente de usuário solicita o armazenamento de uma página de informação, salvando informações de um servidor de origem; Post: semelhante ao método put, de forma que os dados são anexados diretamente a URL da página de informação desejada do servidor de origem Simple Network Management Protocol (SNMP) O protocolo SNMP é um protocolo de gerência típica de redes TCP/IP (Stallings, 2005), da camada de aplicação, que facilita o intercâmbio de informação entre os dispositivos de rede, como placas e switches. O software de gerência de redes não segue o modelo cliente-servidor, possuindo assim uma arquitetura própria, composta por:

26 13 Estação de Gerenciamento (Management Station), responsável por realizar requisições aos agentes mestres, interfacear o ambiente de monitoramento com o usuário e gerenciar um banco de dados com todas as informações extraídas dos agentes monitorados (Stallings, 2005). Agentes ou Agentes Mestres (Master Agents), que são as plataformas presentes na rede a ser gerenciada, e que interagem com a estação de gerenciamento, através de respostas às suas requisições ou, em muitos casos, fornecer espontaneamente suas informações à estação de gerenciamento (Stallings, 2005). Base de Informações de Gerenciamento (MIB), que corresponde a uma coleção de todas as variáveis de dados para os aspectos do agente de gerenciamento, convenientemente denominados de objetos (Kurose, 2006; Stallings, 2005). Cada objeto é referenciado de acordo com o seu mapeamento na notação ASN.1, a qual atribui a cada objeto um prefixo longo que garante a unicidade do nome (Kurose, 2006). Protocolo de gerenciamento de rede, no caso o SNMP em suas diversas versões: SNMPv1, SNMPv2 (RFC s 1901, , ) e SNMPv3. É um protocolo não orientado a conexão e é baseado em UDP (Stallings, 2005). As requisições de gerenciamento são enviadas pela porta 161 e os agentes enviam traps pela porta 162 (Kurose, 2006). O protocolo SNMPv2 possui os seguintes métodos principais, de acordo com Stallings (2005): Get: estação de gerenciamento recupera o valor dos objetos nos agentes; Set: estação de gerenciamento define o valor dos objetos nos agentes; Notify: agentes enviam informações não solicitadas à estação de gerenciamento. Kurose (2006) defende a criação de aplicações SNMP, as quais atribuem as seguintes características adicionais a cada unidade analisada anteriormente: A estação de gerenciamento é constituída basicamente de um gerador de comandos, um receptor de notificações e um transmissor de informações; Os agentes seriam constituídos de um elemento gerador de comandos e um receptor de notificações.

27 14 3 METODOLOGIA Esta seção apresenta a metodologia de desenvolvimento do trabalho, destacando as ferramentas e recursos computacionais utilizados, bem como a arquitetura e formas de comunicação empregadas. 3.1 Pré-Requisistos Especificações Mínimas Necessárias Os requisitos mínimos de sistema são: Computador com processador Intel Pentium 3x ou superior; Espaço livre em disco inferior a 200MB, no caso do service broker, ou inferior 10MB para os clientes; 250MB de memória RAM ou superior; Sistema Operacional MS Windows 9x ou superior / Unix-like; Navegador (web browser): MS Internet Explorer 5.5 ou Netscape 6.0 ou Mozilla Firefox ou superiores; Porta paralela padrão bidirecional para teste com hardware Ferramentas de Desenvolvimento utilizadas: Para a realização das atividades deste trabalho, as seguintes ferramentas foram Sistema operacional Debian GNU/Linux versão 4.0 r3 Etch, para arquitetura Intel x86; Pacote Linux Net-SNMP, com deamon SNMPd; Banco de dados MySQL versão 5.0; Linguagem Python versão 2.4; Biblioteca MySQLdb para Python;

28 15 Servidor Apache versão 1.3; Módulo Apache Mod_Python versão 2.7; Compilador gcc versão 3; Aplicativo Wink versão 1.5; Aplicativo Umbrello versão Hardware de teste Os requisitos de hardware de teste (Fig. 4) utilizados foram: Motor de passo; Placa de comunicação paralela para motor de passo. Figura 4: Dispositivo de hardware utilizado para teste, incluindo motor de passo e placa de comunicação. 3.2 Desenvolvimento Determinação da Arquitetura A Figura 5 apresenta um modelo da arquitetura proposta para o sistema de laboratório virtual. Pela Figura 5, modificada de García-Zubia (2004), verifica-se que o sistema proposto é composto por três entidades principais: servidores de processo, usuários finais e service broker, cujas funcionalidades foram descritas na revisão da literatura apresentada na seção 2.

29 16 p P Service Broker r o c e SNMP s s o s s Servidores HTTP u Usuários Finais Figura 5: Arquitetura proposta para o laboratório virtual, empregando somente software livre e protocolos de comunicação de domínio público. A arquitetura proposta permite que cada nível da mesma apresente um tipo de implementação própria e diferenciada, porém comunicantes entre si (Bardi e Campos, 2008), tal como descritos a seguir: Os servidores de processo seriam as aplicações físicas em si que estão em contato direto com o service broker. Cada servidor deve apresentar uma base de dados específica que permite armazenar, em tempo real, os dados que estão sendo coletados e que, quando solicitados, enviem suas informações para uma base temporária no service broker. Os servidores devem ser implementados de forma simples, de preferência em linguagem C, padrão ANSI. A comunicação entre os servidores e o service broker deve ser realizada via protocolo SNMP; O Service Broker é a entidade hierárquica responsável por fazer a interação entre os usuários finais e os servidores de processo, fornecendo autorização para acessar determinadas informações. Note que esta entidade é única e centralizadora de poderes, restringindo o acesso indevido de usuários não-autorizados. Em caso de falhas, permite que os servidores de processo continuem funcionando

30 17 normalmente, visto que a interação entre os servidores e o service broker não é contínua. Basicamente, duas aplicações estarão em funcionamento nesta entidade: o servidor Apache e as bases de dados MySQL, além das rotinas de operações apresentadas em scrips empregando-se Python; Já as aplicações dos usuários finais seriam meros ambientes desenvolvidos para browser Internet, que interage diretamente com o Service Broker. Algumas das funcionalidades inerentes seriam autenticação do usuário, solicitação de serviços, atuação em servidores de processo e visualização de resultados. A comunicação entre os usuários finais e o service broker é realizada via HTTP. virtual. A Figura 6 apresenta um diagrama de seqüência para uma transação do laboratório Figura 6: Diagrama de seqüência para uma transação do laboratório virtual Configuração do Servidor Apache De modo a poder aceitar conexões de diversos clientes na rede e também interagir com os demais serviços da arquitetura proposta na Figura 2, o servidor Apache foi obtido a partir do repositório Debian, empregando-se o seguinte comando: apt-get install apache2

31 18 O arquivo de configuração httpd.conf praticamente não foi modificado, permitindo que o modelo fornecido pela própria documentação do servidor embarcada ao mesmo fosse utilizada no projeto. Para que o Apache pudesse reconhecer scripts CGI implementados em linguagem Python, o pacote Mod_Python foi instalado da seguinte forma: apt-get install mod-python Os scripts Python que podem ser gerados a partir desta integração Apache+Python devem ser identificados com a extensão característica.psp, pela qual pode-se escrever um código Python mesclado a tags HTML, o que permite que o processamento do script seja mais rapidamente realizado quando chamado pelo cliente. O código Python é diferenciado do código HTML através dos delimitadores: <% %>.<código> Quando se deseja que o retorno de um comando Python seja apresentado no brower Web, os seguintes delimitadores são empregados: <%= <código> %> Configuração da Biblioteca Net-SNMP Para se lançar mão das funcionalidade do protocolo SNMP, seu deamon foi obtido a partir do repositório Debian, empregando-se o seguinte comando: apt-get install snmpd O arquivo de configuração snmpd.conf modificado para ser utilizado encontra-se no Apêndice 1, construído de acordo com o modelo fornecido pela própria documentação do servidor embarcada ao mesmo.

32 19 Dentre os comandos implementados nesta biblioteca, é conveniente apresentar a descrição de alguns para manipulação de objetos na MIB, que são: snmpwalk -v 1 -c public <ID_máquina> <OID > Este comando permite navegar pela extensão da MIB definida em <OID>, exibindo seus valores de acordo com a notação SNMP. snmpget -v 1 -c public <ID_máquina> <OID_objeto> Este comando permite retornar o valor armazenado em um determinado objeto, além de seu tipo e uma referência a MIB em questão. Podem ser usados, em conjunto, funções de formatação de dados, de modo a se eliminar informações indesejáveis (ex. função sed(<expr_regular>) do UNIX) snmpset -v 1 -c public <ID_máquina> <OID_objeto> <tipo> <valor> Este comando permite inserir no objeto indicado <OID_objeto> um valor <valor>, dependendo do tipo explicitado em <tipo>. Este comando, conforme veremos adiante, está sujeito a restrições de acesso/alterações impostas pela MIB Desenvolvimento das Ferramentas de Teste Para que o sistema de teste fosse devidamente validado, foi desenvolvido um hardware para controlar um motor de passo conectado à porta paralela do microcomputador. Além disso, foi desenvolvida uma ferramenta para coletar valores de temperatura de CPU placa-mãe de máquinas conectadas ao laboratório virtual, armazenadas em uma base de dados no service broker e então, quando solicitadas, enviadas ao cliente. O Apêndice 2 apresenta o código da interface em browser de interação com o usuário para movimentar o motor de passo e para a coleta de informações a respeito das máquinas. O Apêndice 3 apresenta o script Python para controlar a passagem de parâmetros ao driver do motor, este último implementado em linguagem C, e apresentando no Apêndice 4. O Apêndice 5 apresenta o script para coleta de informações de temperatura de máquinas em tempo real. Já o Apêndice 6 apresenta imagens em tempo de execução dos ambientes.

33 20 4 RESULTADOS E DISCUSSÃO Esta seção apresenta os resultados obtidos deste trabalho, incluindo discussões sobre o uso de software livre no desenvolvimento, testes de usabilidade e de potenciais de expansão do projeto. 4.1 Análise da Arquitetura Proposta A organização em três camadas permite que o foco no desenvolvimento de aplicações para o laboratório virtual esteja estritamente no lado do servidor de processos. Ainda, não requer nenhuma aplicação ou recurso específico ao lado cliente, o que deixa toda a aplicação centrada no servidor web. Por fim, a fase de transmissão da informação se torna completamente transparente tanto ao usuário final quando ao desenvolvedor, visto que as etapas da transação já estão definidas no service broker. Quando em uma operação real, o gerente do sistema do laboratório virtual terá controle total sobre os ensaios que estão sendo atualmente sendo executados, visto que, de acordo com a definição do protocolo SNMP, todos os processos que são executados por este devem estar mapeados em sua MIB, o que implica estar devidamente declarados no arquivo de configuração snmpd.conf (Apêndice 1). Esta arquitetura ainda permite um controle no fluxo de acessos ao sistema, com a verificação de identidade de usuários e a geração de estatísticas e logs. Quanto a prevenção contra falhas, nota-se que embora o enlace cliente service broker seja realizado via protocolo HTTP e, assim, susceptível às sensibilidade da rede, o sistema de coleta de informação (transações service broker processos) não será prejudicado, garantindo a integridade dos dados armazenados. O uso de ferramentas de software livre para o desenvolvimento também tornou o sistema extremamente simples e portáveis, sendo que pode ser acessado de qualquer momento e também expandido facilmente por não depender de funções proprietárias. 4.2 Testes de Integração Os testes de integração entre ambas as partes do laboratório virtual foram divididos em duas grande partes: o controle de motor de passo e a coleta de informações.

34 21 Para tanto, cada ensaio teve que estar devidamente declarado no arquivo snmpd.conf localizado no service broker, de acordo com a seguinte sintaxe: exec <objeto_oid> <identificação> <path do executável> {<arg1> <arg2>} Nota-se que cada processo deve, então, possuir uma entrada na MIB restrita a ele, a qual estará localizada sempre no endereço da MIB , que representa as MIB s estendidas, e então definidas identificadores únicos (no caso,.54, para o motor de passo). Posteriormente, para cada processo, alguns objetos padrões são criados, tal como segue (tais informações podem ser facilmente exibidas através do comando snmpwalk na MIB desejada): OID apresenta o retorno do processo, caso exista. Se não, retorna 0 como default; OID.101.1, OID.101.2, OID.101.3,... apresentam os resultados da execução do processo, caso existam. Podem existir tantas entradas quanto o número de resultados. Todos os resultados são armazenados na forma de string. OID e OID indicam o fim dos objetos, onde o primeiro apresenta como valor 1 e o segundo uma string vazia. Para a inicialização do sistema e execução dos testes, as seguintes etapas devem ser executadas no service broker: 1. Parar o servidor Apache, através da chamada no bash: $> /etc/init.d/apache stop 2. Iniciar o servidor Apache2, através da chamada no bash: $> /etc/init.d/apache2 start 3. Iniciar o deamon snmpd, através da chamada no bash: $> /etc/init.d/snmpd start

35 Controle de motor de passo Verificou-se que o desenvolvimento de aplicações em linguagem C (Apêndice 4) são facilmente integradas ao sistema, inclusive a passagem remota de parâmetros, tal como o sentido de rotação (esquerda e direita) e a forma de rotação do mesmo (passo a passo ou automática). As seguintes convenções para definição dos valores do objeto de entrada do processo foram adotadas para se definir a forma e o sentido de rotação do motor (Apêndices 2-3: Rotação manual para a direita: objeto definido como +1; Rotação manual para a esquerda: objeto definido como -1; Rotação automática para a direita: objeto definido como +1000; Rotação manual para a esquerda: objeto definido como Parâmetros podem ser passados desde que informados a um objeto da MIB por meio do comando snmpset e capturados pelo cliente por meio de snmpget. A atualização das informações é constante, o que leva a uma resposta quase que imediata do motor de passo. É interessante destacar que nesta implementação de SNMP utilizada, só é permito o uso do comando snmpset em objetos da MIB passíveis de serem alterados externamente. Assim, neste caso, o objeto utilizado foi o system.sysname.0. Para que os dados possam ser corretamente tratados, o processo destino deve efetuar uma conversão de tipos, visto que o SNMP armazena por padrão informações no tipo string, enquanto estamos tratando com valores numéricos Coleta de informações Aplicações podem se comunicar com os clientes enviando informações quando solicitadas pelos mesmos, desde que as mesmas estejam armazenadas nas bases de dados do service broker. Neste caso, as temperaturas da placa-mãe e da CPU foram coletadas e dispostas em tabelas e exibidas pelo cliente quando solicitadas, o que simula perfeitamente uma leitura de dados de um experimento real. O service broker faz constantemente consultas ao objeto referenciado na MIB que conterá as informações de temperatura através de chamadas getsnmp e armazenadas. O cliente, simplesmente, faz uso deste recurso e apresenta no browser as temperaturas

36 23 armazenadas. Os objetos que foram alvo de leitura são identificados por e na máquina drc3-ns. Para este, foi realizada uma integração entre Apache, Python, SNMP e MySQL, de modo que o próprio script Python, armazenado no service broker, é capaz de direcionar diretamente os resultados de uma consulta SQL ao cliente que a solicitou, além ainda de realizar uma chamada ao sistema para se verificar o período de tempo no qual foi realizado a coleta. Ainda, o script ficará constantemente armazenando, por si só, as informações recebidas diretamente em tabelas definidas na base de dados (Apêndice 5). 4.3 Dificuldades encontradas Durante a realização deste trabalho, algumas dificuldades foram encontradas, principalmente no que diz respeito ao caráter deste trabalho, no qual conhecimentos de programação, redes de computadores, sistemas distribuídos e sistemas operacionais deveriam ser integrados de forma a apresentar um sistema completamente transparente e didático ao usuário, e simples e extensível ao programador de processos. A busca por um módulo expansor do Apache que suportasse scripts Python, e que, além de suportar, ainda conseguisse interagir com MySQL e browsers Web foi realmente interessante e desafiador, além de requerer um considerável tempo no aprendizado da linguagem mista com Python e HTML que o mesmo compreende. A compreensão do arquivo de configuração do SNMP, bem como suas rotinas e parâmetros, também foi um processo lento. Viu-se que a definição de visões e níveis de segurança podem vir a comprometer a usabilidade do sistema, cujos parâmetros são definidos diretamente no snmpd.conf. Ainda com relação ao arquivo de configuração do SNMP, duas dificuldades foram também encontradas: a impossibilidade de se gerar um objeto novo que servisse simplesmente como receptor de parâmetros de programa e também a necessidade de se apresentar explicitamente o argumento de um processo logo na sua definição no arquivo snmpd.conf. Por fim, a geração de um código em C que permitisse o interfaceamento do computador, com Linux, com um motor de passo, a correta descoberta dos sinais que deveriam ser enviados pela porta paralela, além de como realizar a passagem de parâmetros indiretamente também causou alguns inconvenientes.

37 24 5 CONCLUSÃO Com base nos critérios e resultados apresentados nesta monografia, onde se buscou o desenvolvimento de um protótipo de laboratório virtual para controle universal de processos a ele conectados utilizando os protocolos SNMP e HTTP, as seguintes conclusões podem ser obtidas: A arquitetura proposta se mostrou adequada ao protótipo, apresentando-se bem estruturada e com seus componentes bem acoplados e interagindo entre si; Verificou-se uma completa integração entre as ferramentas livres utilizadas (Linux, Apache, MySQL, Python, SNMP), e que as mesmas permitem a geração de sistemas poderosos, além de gerar um interfaceamento com hardwares dos mais diversos tipos sem a necessidade de recursos complexos e/ou proprietários; Os testes realizados mostraram que tanto as etapas de interação quanto a de supervisão podem ser feitas por meio de interações entre os protocolos HTTP e SNMP. 5.1 Contribuições Resumidamente, as principais contribuições deste estudo são a aplicação de ferramentas de domínio livre na supervisão/interação com processos remotos e a facilidade de uso do sistema. Outra contribuição seria o emprego do protocolo SNMP para outras funções além das tradicionalmente impostas ao mesmo, que seria simplesmente a de gerenciamento de redes. Além disso, este trabalho ainda forneceu um trabalho completo submetido, aceito e apresentado no 18º Congresso Brasileiro de Engenharia e Ciência dos Materiais (18º CBECiMat), e uma apresentação realizada no Congresso Internacional de Software Livre (CONISLI 2008) 5.2 Extensões Este trabalho pode ser continuado da seguinte forma: Implementação de transmissão de vídeo por streaming ou armazenado por meio da interação com os protocolos SNMP/HTTP e RTP.

38 25 Integração deste sistema com processo que sejam interfaceados com interfaces GPIB, RS-232 (barramento serial) e até mesmo interfaceamento via USB. Realização de testes contínuos com processos que exigem que dados sejam coletados continuamente e armazenados ou então apresentados aos clientes na forma de gráficos. Integração deste sistema a redes de alto desempenho dedicadas exclusivamente a questões de ensino/pesquisa.

39 26 Referências Bibliográficas BARDI, M. A. G.; CAMPOS, S. P. WebLabs: conceitos, características e proposta de implementação usando software livre In: CONGRESSO INTERNACIONAL DE SOFTWARE LIVRE, 2008, São Paulo. Resumos... São Paulo: CONISLI, BARDI, M. A. G.; UMEZU, C. K.; CAMPOS, S. P.; ROSA, D. S. Desenvolvimento de ambiente computacional para laboratório virtual (weblab) de sistema de biodegradação aeróbica de materiais poliméricos. In: CONGRESSO BRASILEIRO DE ENGENHARIA E CIÊNCIA DOS MATERIAIS, 18., 2008, Porto de Galinhas. Resumos... São Paulo: Metallum, FJELDLY, T. A.; SHUR, M. S. Lab on the web: Running real electronics experiments via the Internet. New York: John Willey & Sons, GARCÍA-ZUBIA, J.; LÓPEZ-DE-IPIÑA, D.; ORDUÑA, P.; HERNÁNDE, U.; TRUEBA, I. Questions and answers for designing useful weblabs. International Journal of Online Engineering, vol.2, no.3, 6p., GEORGE, J.; COWAN, J. A handbook of techniques for formative evaluation. London: Kogan-Page, GUIMARÃES, E.; MAFFEIS, A.; PEREIRA, J.; RUSSO, B.; CARDOZO, E.; BERGERMAN, M. ; MAGALHÃES, M. F. REAL: A virtual laboratory for mobile robot experiments. IEEE Trans. Education, vol. 46, no.1, pp.37-41, Feb HOLDEN, G.; WELLS, N.; KELLER, M. Apache Server. São Paulo: Makron Books, JAMES, J. A.; SANTISEBAN, J. R.; EDWARDS, L.; DAYMOND, M. R. A virtual laboratory for neutron and synchrotron strain scanning. Physica B: Condesend Matter, vol.350, no.1-3, sup.1, pp.e743-e746, Jul KHAN, R. A. Software architecture for web-accessible heat exchanger experiment f. Dissertação (Mestrado em Engenharia Civil e Ambiental) Departmento de Engenharia Civil e Ambiental, Massachusetts Institute of Technology, Cambridge, USA. KUROSE, J. F., ROSS, K. W. Redes de computadores e a Internet: uma abordagem top-down. 3 ed. São Paulo: Pearson Addison Wesley, LAVERTY Jr., S. M. Experimental hydrodynamics of spherical projectiles impacting on a free surface using high speed imaging techniques f. Dissertação (Mestrado em Engenharia Mecânica) Departmento de Engenharia Mecânica, Massachusetts Institute of Technology, Cambridge, USA. MARKIN, R. S.; WHALEN, S. A. Laboratory automation: trajectory, technology, and tactics. Clinical Chemistry, vol. 43, no.1, pp , MIYAKE, N.; HALL, R.; KOSCHMANN, T. Carrying the conversation forward. Mahwah: Erlbaum, SANDHU, J.S. An active engagement pedagogy for introductory solid mechanics f. Dissertação (Mestrado em Engenharia Mecânica) Departmento de Engenharia Mecânica, Massachusetts Institute of Technology, Cambridge, USA. SOARES, L. F. G.; LEMOS, G.; COLCHER, S. Redes de Computadores: das LANs, MANs e WANs às redes ATM. 2. ed. São Paulo: Editora Campus, STALLINGS, W. Redes e sistemas de comunicação de dados. Rio de Janeiro: Elsevier, TALAVERA, D.J. On-line laboratory for remote polymer crystallization experiments using optical microscopy f. Dissertação (Mestrado em Engenharia Eletrica e Ciencia da Computacao )

40 27 Departmento de Engenharia Eletrica e Ciencia da Computacao, Massachusetts Institute of Technology, Cambridge, USA. TANEMBAUM, A. S. Redes de computadores. 4 ed. Rio de Janeiro: Elsevier, 2003.

41 28 Bibliografia consultada COMER, D. E. Internetworking with TCP/IP. Vol. 1: Principles, protocols, and architecture. 4 ed. New Jersey: Prentice Hall, DEITEL, H. M.; DEITEL, P. J.; NIETO, T. R. Internet & World Wide Web: Como programar. Porto Alegre: Bookman, 2003.

42 29 Apêndice 1 Arquivo de configuração /etc/snmp/snmpd.conf ########################################################################### Controle de Acesso ########################################################################### #### # First, map the community name (COMMUNITY) into a security name # (local and mynetwork, depending on where the request is coming # from): # sec.name source community #com2sec paranoid default public com2sec readonly default public com2sec readwrite default private #### # Second, map the security names into group names: # sec.model sec.name group MyROSystem v1 paranoid group MyROSystem v2c paranoid group MyROSystem usm paranoid group MyROGroup v1 readonly group MyROGroup v2c readonly group MyROGroup usm readonly group MyRWGroup v1 readwrite group MyRWGroup v2c readwrite group MyRWGroup usm readwrite #### # Third, create a view for us to let the groups have rights to: # incl/excl subtree mask view all included.1 80 view system included.iso.org.dod.internet.mgmt.mib-2.system #### # Finally, grant the 2 groups access to the 1 view with different # write permissions: # context sec.model sec.level match read write notif access MyROSystem "" any noauth exact system none none access MyROGroup "" any noauth exact all none none access MyRWGroup "" any noauth exact all all none # ########################################################################### # Seções de extensão da MIB. ###########################################################################

43 30 # You can also have programs run by the agent that return a single # line of output and an exit code. Here are two examples. # # exec NAME PROGRAM [ARGS...] # # NAME: A generic name. # PROGRAM: The program to run. Include the path! # ARGS: optional arguments to be passed to the program exec motor /var/www/motor exec temp /var/www/temp # ########################################################################### # Controle de Subagente # # The agent can support subagents using a number of extension mechanisms. # From the release, AgentX support is being compiled in by default. # However, this is still experimental code, so should not be used on # critical production systems. # Please see the file README.agentx for more details. # # If having read, marked, learnt and inwardly digested this information, # you decide that you do wish to make use of this mechanism, simply # uncomment the following directive. # # master agentx # # I repeat - this is *NOT* regarded as suitable for front-line production # systems, though it is probably stable enough for day-to-day use. # Probably. # # No refunds will be given. ########################################################################### # Maiores Informações # # See the snmpd.conf manual page, and the output of "snmpd -H". # MUCH more can be done with the snmpd.conf than is shown as an # example here.

44 31 Apêndice 2 Página inicial do protótipo /var/www/motor.psp <HTML> <HEAD><TITLE>LABORATORIO VIRTUAL</TITLE></HEAD> <BODY> <% import os %> <H1>UNIVERSIDADE SAO FRANCISCO</H1> <H2>Engenharia de Computacao</H2> <H3>Trabalho de Conclusao de Curso</H3> <% os.system("snmpset -c private -v 1 localhost system.sysname.0 s '0'") %> <HR> <H3> CONTROLE MANUAL DE ROTACAO DE WEBCAM</H3> <FORM ACTION="/execSNMP_man_d.psp" METHOD="POST"> <INPUT TYPE="submit" VALUE="Direita"> </FORM> <FORM ACTION="/execSNMP_man_e.psp" METHOD="POST"> <INPUT TYPE="submit" VALUE="Esquerda"> </FORM> <P> <H3> CONTROLE AUTOMÃチTICO DE ROTACAO DE WEBCAM</H3> <FORM ACTION="/execSNMP_aut_d.psp" METHOD="POST"> <INPUT TYPE="submit" VALUE="Direita"> </FORM> <FORM ACTION="/execSNMP_aut_e.psp" METHOD="POST"> <INPUT TYPE="submit" VALUE="Esquerda"> </FORM> <P> <H3> TEMPERATURA DE MÃチQUINAS </H3> <FORM ACTION="/execSNMP_temp.psp" METHOD="POST"> <INPUT TYPE="submit" VALUE="Ver dados"> </FORM> </BODY> </HTML>

45 32 Apêndice 3 Script Python para motor de passo rotacionar automaticamente a direita /var/www/execsnmp_a_d.psp <HTML> <BODY> <% import os %> <% os.system("snmpset -c private -v 1 localhost system.sysname.0 s '1000'") %> <H1> ConcluÃdo </H1> <FORM ACTION="/motor.psp" METHOD="POST"> <INPUT TYPE="submit" VALUE="Home"> </FORM> </HTML> </BODY>

46 33 Apêndice 4 Código C para motor de passo /var/www/motor.c #include <stdio.h> #include <string.h> #include <stdlib.h> #include <sys/io.h> #define base 0x378 /* Endereço da porta da impressora */ int main(){ int j,i,value,flag, sinal[8], p[2], backup; char buf[1000]; backup = dup(1); close(0); close(1); pipe(p); system("snmpget -c private -v 1 -Oq -Ov localhost system.sysname.0"); dup2(backup, 1); while(fgets(buf, 1000, stdin)){ printf("%s", buf); } flag = atoi(buf); if (ioperm(base,1,1)){ fprintf(stderr, "Erro: Usuário não tem permissão para acessar a porta %x\n", base), exit(1); } sinal[0] = 1; sinal[1] = 3; sinal[2] = 2; sinal[3] = 6; sinal[4] = 4; sinal[5] = 12; sinal[6] = 8; sinal[7] = 9; if( flag > 0){ while ( flag ){ for(j = 1 ; j <= 15 ; j ++){ if( flag ){ value = sinal[0]; } else { value = sinal[7]; }

47 34 } for( i = 0 ; i<=7 ; i++ ){ outb((unsigned char)value, base); usleep(500); if( flag ){ value = sinal[i]; } else { value = sinal[7-i]; } } } } else { flag = flag - 1; if( flag < 0 ){ while ( flag ){ for(j = 1 ; j <= 15 ; j ++){ if( flag ){ value = sinal[0]; } else { value = sinal[7]; } } for( i = 9 ; i>=2 ; i-- ){ outb((unsigned char)value, base); usleep(500); if( flag ){ value = sinal[i]; } else { value = sinal[7+i]; } } flag = flag + 1; } } } else { system("pause"); } return 1; }

48 35 Apêndice 5 Script Python para coletar informações, armazenar em base de dados e exibir ao cliente /var/www/execsnmp_temp.psp <HTML> <BODY> <% import sys import MySQLdb import os import time from commands import getoutput a = time.asctime(time.localtime(time.time())) b = getoutput("snmpget -v 2c -c public -Oq -Ov drc3-ns ") c = getoutput("snmpget -v 2c -c public -Oq -Ov drc3-ns ") try: conn = MySQLdb.connect(host = "localhost", user = "root", passwd = "magbardi", db = "Teste") except MySQLdb.Error, e: msg_usr= 'Erro %d: %s' % (e.args[0], e.args[1]) sys.exit(1) cursor = conn.cursor() cursor.execute("create TABLE IF NOT EXISTS board(tempo CHAR(30), temperatura CHAR(4))") cursor.execute("create TABLE IF NOT EXISTS cpu(tempo CHAR(30), temperatura CHAR(4))") cursor.execute("insert INTO board (tempo, temperatura) VALUES( %s, %s)", (a, b)) cursor.execute("insert INTO cpu (tempo, temperatura) VALUES( %s, %s)", (a, c)) %> <H1> <%= a %> </H1> <H1> <%= b %> </H1> <H1> <%= c %> </H1> <% d = cursor.execute("select * FROM board") reg = cursor.fetchall() %> <% cursor.close() conn.commit() conn.close()

49 36 %> </BODY> </HTML>

50 37 Apêndice 6 Exemplos de telas de execução do sistema Tela inicial do protótipo, apresentando as opções ao usuário. Tela apresentando o fim da operação de rotação do motor de passo.