1
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
LOG CENTRALIZADO VIA COMUNICAÇÃO EM GRUPO
Área de
Sistemas Distribuídos
por
Udo Francisco Wloch
Ademir Goulart, M.Sc.
Orientador
i
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
LOG CENTRALIZADO VIA COMUNICAÇÃO EM GRUPO
Área de
Sistemas Distribuídos
por
Udo Francisco Wloch
Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação.
Orientador: Ademir Goulart, M.Sc.
ii
AGRADECIMENTOS
A Universidade do Vale do Itajaí, por proporcionar o apoio necessário e o acesso aos laboratórios para a construção deste trabalho.
Ao meu orientador, Ademir Goulart M.Sc, pelo seu empenho a fim de enriquecer o trabalho e sua pronta disposição para o atendimento deste orientando.
Ao Jean Pierre Patzlaff e Amauri dos Santos Alves pelo auxilio na codificação dos programas em Visual Studio na linguagem C#, especialmente no tratamento da interface gráfica.
Aos avaliadores da banca Fabrício Bortoluzzi M.Sc e Gilberto da Silva Luy M.Sc por demonstrarem interesse e agregarem críticas construtivas para o desenvolvimento deste trabalho.
Aos amigo(a)s Allan Patrick, Ana Paula, Braz Pereira, Andréia Peixer e Robson Hamilton pela ajuda, apoio e principalmente paciência durante este 1 ano de desenvolvimento.
Em especial a minha família: minha mãe Luzia Wloch, minha vó Hilda Rebello Wloch e meu primo Fabricio Wloch pela compreensão e sempre que precisei, sem medir esforços, estavam pronta(o)s a me ajudar.
A todos os demais, não citados, que de forma direta ou indireta contribuíram para a realização deste trabalho.
iii
SUMÁRIO
LISTA DE ABREVIATURAS...v
LISTA DE FIGURAS ...6
RESUMO...7
ABSTRACT...8
INTRODUÇÃO...9
1.1
PROBLEMATIZAÇÃO ... 10
1.1.1
Formulação do Problema ... 10
1.1.2
Solução Proposta... 11
1.2
OBJETIVOS ... 12
1.2.1
Objetivo Geral ... 12
1.2.2
Objetivos Específicos ... 12
1.3
METODOLOGIA... 12
1.4
ESTRUTURA DO TRABALHO ... 13
2
FUNDAMENTAÇÃO TEÓRICA ... 13
2.1
SISTEMAS DISTRIBUÍDOS ... 13
2.2
COMUNICAÇÃO EM GRUPO... 15
2.3
MECANISMO DE COMUNICAÇÃO EM GRUPO SPREAD ... 17
2.4
TRABALHOS CORRELATOS ... 22
3
PROJETO ... 24
3.1
ESCOPO DO SISTEMA ... 24
3.2
ANÁLISE DE REQUISITOS... 24
3.2.1
Requisitos funcionais ... 24
3.2.2
Requisitos Não funcionais ... 25
3.2.3
Regras de Negócio ... 25
3.3
DIAGRAMA DE CASOS DE USO ... 26
3.3.1
Aplicativo Cliente... 26
3.3.2
Aplicativo Servidor ... 30
3.4
IMPLEMENTAÇÃO ... 33
3.4.1
INTERFACES... 33
3.4.2
Técnicas e ferramentas utilizadas ... 35
3.4.3
Processo de implementação... 36
4
DESENVOLVIMENTO ... 37
4.1 BANCO DE DADOS... 37
4.2 SISTEMA ... 37
4.2.1 LCCG Client... 38
4.2.2 LCCG Server ... 39
4.2.3 Testes ... 41
iv
5
CONSIDERAÇÕES FINAIS ... 44
REFERÊNCIAS BIBLIOGRÁFICAS... 45
APÊNDICE 1 CÓDIGO FONTE DETALHADO DE CADA BOTÃO... 48
v
LISTA DE ABREVIATURAS
API Application Programming Interface AIX Advanced interactive executive
BD Banco de Dados
C Linguagem programação C
HOP Protocolo SPREAD para conexão ponto a ponto INTERGROUP API para comunicação em grupo
JAVA Linguagem de programação
JGROUP API para comunicação em grupo
LAN Local area network
LOG Registro de eventos.
MySQL Banco de Dados MySQL
Open Source Código Aberto
Perl Practical Extraction and Report Language RING Protocolo SPREAD para domínios multicast. SPREAD API para comunicação em grupo
TCC Trabalho de Conclusão de Curso
Toolkit Biblioteca de rotinas
UNIVALI Universidade do Vale do Itajaí
UNIX Uniplexed Information and Computing System
6
LISTA DE FIGURAS
Figura 1 Solução proposta...11
Figura 2 Ilustração de um sistema distribuído. ...14
Figura 3 Ilustração de uma comunicação em grupo...16
Figura 4 Arquiteura do SPREAD...19
Figura 5 Exemplo de roteamento. ...21
Figura 6 Diagrama de casos de uso LCCG Client ...26
Figura 7 Diagarma de classe do aplicativo cliente...28
Figura 8 Diagrama de sequência envio de log para o servidor. ...29
Figura 9 Diagrama de casos de uso do aplicativo servidor...30
Figura 10 Diagrama de classes do aplicativo servidor...31
Figura 11 Diagrama de sequência inserindo log no Banco de Dados...32
Figura 12 Diagrama de sequência visualizando membros ativos. ...33
Figura 13 Aplicação cliente...34
Figura 14 Pasta de armazenamento de logs gerados no cliente. ...34
Figura 15 Aplicação servidor. ...35
Figura 16 Banco de Dados ...37
Figura 17 Daemon SPREAD em execução...39
Figura 18 Arquivo de configuração do servidor SPREAD. ...40
Figura 19 Configuração do arquivo spread.conf nos testes. ...42
Figura 20 Comando SQL para verificar os dados no banco de dados. ...43
Figura 21 Conexão com SPREAD ...48
Figura 22 Botão de execução de processo de envio...49
Figura 23 Ativar e desativar timer...50
Figura 24 Botão parar...51
Figura 25 Seleção de pasta onde será gerado os log’s ...52
Figura 26 Botão de conexão com o banco de dados. ...52
Figura 27 Log adicionado ao banco de dados...55
Figura 28 Conexões ativas ...55
7
RESUMO
WLOCH, Udo Francisco. Log centralizado via comunicação em grupo . Itajaí, 2010. 40 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2010.
O objetivo deste trabalho foi desenvolver um software que faz a centralização de arquivos de log usando o paradigma de Comunicação em Grupo. Considerando a necessidade de um gerenciamento centralizado de backups o trabalho centralizou em um único banco de dados, o resultado de diversos logs gerados em diferentes localidades por um software de backup. Com as características de confiabilidade e independência de quantos membros façam parte do grupo fornecidas pelo ambiente de comunicação em grupo foi possível implementar esta coleta para N locais diferentes de forma padronizada e automatizada. Um programa central estando continuamente recebendo as informações dos programas que rodam remotamente nos servidores de backup. Cada local onde o software de backup é executado tem um agendamento que dispara a execução desta transmissão para o ponto centralizador. As características da Comunicação em Grupo permitem que N arquivos sejam enviados simultaneamente para o ponto central de amazenamento destes Logs. O mecanismo de Comunicação em Grupo usado neste trabalho foi o SPREAD (Amir,1998).
8
ABSTRACT
The objective of this research was develop a software that centralize the log archives using a paradigm Group Communication Program. Considering the needs of a centralized management of backups, the purpose of this research is to centralize the result of various logs created in different places by backup´s software. With assurance and independence features of how many members will be part of this group provided by the group communication ambience, we`ll be able to implement this collect from N different places, standardized and automated. A local program will always be receiving the program`s information that is running remotely on the backup server. In each place that the backup server is executed, on the end of the backup, the transmission execution will be shot to the centralizer point. The Group Communication features allows to send simultaneously the N archives to the central point storage of these Logs. The Group Communication mechanism that will be used on this research will be the SPREAD ( Amir, 1998).
9
INTRODUÇÃO
Uma definição de sistemas distribuídos é aquela na qual os componentes de hardware e software localizados em computadores interligados por rede, comunicam e coordenam suas ações somente através da troca de mensagens (COULOURIS, 2007).
A comunicação entre os computadores interligados pode ocorrer de diferentes formas, usando diversos protocolos tanto em ambiente de rede local como ambiente de redes de longa distância. Um caso particular de comunicação ocorre quando uma mesma mensagem tem que ser enviada para diversos computadores na rede. Alguns ambientes físicos de rede permitem o broadcast, onde um único comando de envio manda a mensagem para todos os endereços da rede, porém a confiabilidade deste método não é garantida, podendo ocorrer alguma perda sem que o emissor da mensagem seja notificado da mesma.
Segundo Goulart (2002) com o intuito de atender a necessidade de comunicação de um para muitos ou de muitos para um, com confiabilidade, escalabilidade, e de forma transparente para quem desenvolve a aplicação, foi criado um novo paradigma chamado Comunicação em Grupo. Um protocolo de Comunicação em Grupo separa a complexidade de controle e gerenciamento das mensagens, da complexidade da aplicação, tratando os diversos computadores como sendo pertencentes a um grupo. Assim, o projetista se preocupa apenas com a aplicação, suas funcionalidades, seus procedimentos, seus algoritmos particulares, sem envolver-se com os problemas da comunicação. Passa a ser responsabilidade do Protocolo de Comunicação em Grupo o controle de fluxo, a confiabilidade, o sequenciamento e a garantia de entrega das mensagens ao aplicativo final, bem como, o controle de quais computadores estão fazendo parte deste grupo, gerenciando a entrada de novos membros no grupo, saída voluntária ou saída involuntária devido à quebra no computador ou particionamento da rede. Um particionamento da rede acontece quando existe uma separação de dois segmentos de redes que perdem a comunicação entre si.
Existem algumas formas de transferências de arquivos entre computadores como, por exemplo, FTP’s (File transfers Protocol), porém as empresas ainda esperam um software mais robusto, que garanta a transferenência e a chegada do arquivo, a partir de uma origem e destino e mantenha um controle se o arquivo foi realmente transferido
10
Este projeto contempla a chegada de todos os logs de diversos servidores distribuídos, clientes de backup, para um unico servidor centralizado, com o intuito de garantir a chegada deles em um único lugar usando o paradigma de comunicação em Grupo. Neste caso será uma comunicação de muitos pontos distribuídos para um único ponto centralizador baseado inteiramente em um servidor chamado SPREAD (AMIR, 1998) que atende este paradigma de comunicação em grupo.
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
O problema que se apresenta está na forma automática de coletar logs gerados em diferentes locais centralizando estes logs em um único ponto. Exemplificando, em cada cidade onde existe um servidor que atende as necessidades de processamento local existe também a necessidade de se produzir backup deste ambiente na filial. Para um gerenciamento centralizado é necessário que estes Logs dos backups sejam transmitidos para um ponto central onde será feito o gerenciamento centralizado.
Como a quantidade de locais de onde provem os logs é totalmente aleatória e visando uma automação no recebimento destes Logs será usado o paradigma de Comunicação em Grupo para abstrair se os logs estão vindo de uma ou de N localidades.
O software no ponto central receberá N Logs provenientes de diversas máquinas através de uma programação pré definida usando os recursos de Comunicação em Grupo.
Utilizou-se a API SPREAD para automatizar o transporte dos arquivos de Logs. Com a criaçao de grupos, o pograma cliente que estará sendo executado em alguma filial da Empresa somente será autorizado a enviar os arquivos para o servidor central se estiver dentro do grupo criado pela ferramenta SPREAD. .
11
1.1.2 Solução Proposta
A aplicação desenvolvida neste TCC não é uma extensão do SPREAD nem acrescenta novas funcionalidades ao mesmo. É uma ferramenta independente apenas usando todas as funcionalidades relativas à comunicação em grupo que são disponibilizadas pelo SPREAD através do uso de sua API.
Através da API foram criados dois novos softwares na qual um é responsável pelo envio do arquivo de Log e que chamaremos de LCCG Client. Esta aplicação é executada conforme o agendamento do cliente no próprio software . Assim que estiverem disponíveis as informações de Log, são transmitidas e o outro software que é chamado de LCCG Server que esta rodando em uma máquina centralizada recebe os arquivos. Após o recebimento todos os dados dos Logs, estes ficarão armazenados em um banco de dados, em um local único, para posterior processamento gerencial destes Logs.
12
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Desenvolver dois softwares, um para enviar e outro para receber arquivos, usando a API SPREAD.
1.2.2 Objetivos Específicos
Os objetivos específicos desse TCC são:
• Pesquisar e compreender detalhadamente a API SPREAD; • Pesquisar e analisar soluções de softwares similares;
• Estudar e aprender os recursos computacionais necessários à implementação da ferramenta;
• Realizar a modelagem conceitual da ferramenta; • Implementar a ferramenta;
• Testar e validar a implementação da ferramenta; e • Documentar o desenvolvimento e os resultados obtidos.
1.3 Metodologia
A metodologia nesta primeira parte do TCC foi composta por duas etapas. Na primeira etapa foi realizado um estudo sobre comportamento nos últimos anos da ferramenta de comunicação em grupo, ultimas versões de API do SPREAD e compreendido detalhadamente as funções e comandos da API SPREAD. Esse estudo foi baseado em livros sobre Sistemas Distribuídos, Redes de computadores e pesquisas na internet com o objetivo de entender como funciona a API SPREAD e as aplicações que utilizam esta API. Na segunda etapa foi realizada a modelagem do sistema que compreendeu a análise de requisitos, a elaboração do diagrama de casos de uso, diagrama de classes e o desenvolvimento dos protótipos de tela do sistema.
13
1.4 Estrutura do trabalho
Este documento foi dividido em quatro capítulos:
O primeiro capítulo: Introdução, apresenta uma visão geral sobre o projeto desenvolvido, o problema encontrado, a solução proposta, os objetivos do TCC e sua metodologia de desenvolvimento.
O segundo capítulo apresenta os conceitos, técnicas e ferramentas mais relevantes ao propósito do trabalho, bem como a descrição dos trabalhos correlatos.
O terceiro capítulo engloba a metodologia de desenvolvimento do trabalho, apresentando os requisitos principais do problema, a especificação, a implementação e a discussão dos resultados obtidos através de testes operacionais feitos a partir de um estudo de caso.
No quarto capítulo apresenta as Considerações Finais obtidas com o desenvolvimento do trabalho, bem como suas vantagens, limitações e as sugestões de extensão para trabalhos futuros.
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são apresentados os principais conceitos a respeito das seguintes tecnologias: sistemas distribuídos; comunicação em grupo; mecanismo de comunicação em grupo SPREAD e trabalhos correlatos utilizando este middleware.
2.1 SISTEMAS DISTRIBUÍDOS
Segundo Coulouris, Dollimore e Kindberg (2007), um sistema distribuído é um conjunto de componentes de hardware, geralmente computadores independentes, e de software interligados através de uma infra-estrutura de comunicação, como uma rede de computadores ou um barramento especial, que cooperam e se coordenam entre si através da troca de mensagens, e eventualmente, pelo compartilhamento de memória comum, para execução de aplicações distribuídas pelos diferentes componentes.
Tanenbaum e Steen (2002) dizem ainda que um sistema distribuído geralmente estará sempre disponível, mesmo que algumas partes estejam com problemas. Usuário e aplicação não são notificados que partes estão sendo trocadas ou consertadas, ou que novas partes foram adicionadas para servir mais usuários e aplicações.
14
Sendo assim, a utilização de sistemas distribuídos torna-se uma alternativa prática e geralmente econômica. É possível adicionar computadores ao longo de uma rede e integrá-los ao sistema distribuído aumentando seu poder de processamento ou desconectar computadores que necessitem de reparos, sem que o sistema seja interrompido ou que o usuário perceba estas alterações. É um sistema naturalmente redundante (JANKE, 2004).
Os maiores problemas na distribuição de um sistema dizem respeito ao gerenciamento da estrutura computacional disponível e a maneira como toda a estrutura comunica-se. A estrutura de uma rede de computadores é dinâmica, novos computadores podem conectar-se a qualquer momento, bem como os computadores já presentes podem deixar de fazer parte da rede. Vários eventos precisam ser tratados, o que acaba tornando o sistema de gerenciamento e comunicação complexo (JANKE, 2004).
A Figura 2 é apresentado a visualização de um sistema distríbuido.
15
2.2 COMUNICAÇÃO EM GRUPO
A troca de mensagens aos pares não é o melhor modelo para comunicação de um processo com um grupo de outros processos, como o que ocorre, por exemplo, quando um serviço é implementado através de diversos processos em computadores diferentes para fornecer tolerância a falhas ou melhorar a disponibilidade. Nesses casos, o emprego de difusão seletiva (multicast) é mais apropriado. –trata-se de uma operação que permite o envio de uma única mensagem para todos os membros de um grupo de processos de tal forma que membros participantes do grupo ficam totalmente transparentes para o remetente. Existem diversas possibilidades para o comportamente desejado de multicast. A Mais simples não fornece garantias a respeito da entrega ou do ordenamento das mensagens.
As mensagens multicast fornecem uma infra-estrutura útil para construção de sistemas distribuidos com as seguintes características:
1. Tolerância a falha baseada em serviços replicados: um serviço replicado consiste em um grupo de servidores. As requisições do cliente são difundidas para todos os membros do grupo, cada um dos quais executando uma operação idêntica. Mesmo quando alguns dos membros falham os clientes ainda podem ser atendidos
2. Localização dos servidores de descoberta na interligação em rede espontânea: Mensagens multicast podem ser usadas por servidores e clientes para localizar os serviços de descoberta disponíveis, para registrar suas interfaces ou para pesquisar as interfaces de outros serviços no sistema distribuído
3. Melhor desempenho através da replicação de dados: os dados são replicados para aumentar o desempenho de um serviço – em alguns casos, as réplicas são postas nos computadores dos usuários. Sempre que os dados mudam, o novo valor é enviado por multicast para os processos que gerenciam as réplicas.
4. Propagação de notificações de eventos: o multicast para um grupo pode ser usado para notificar os processos de quando algo acontece (Coulouris, 2007).
Em sistemas distribuídos é fundamental a comunicação entre os diversos computadores que compõem este ambiente de sistemas distribuídos. Em algumas situações é desejável que um processo possa se comunicar com diversos outros processos. Este mecanismo de comunicação que
16
trata múltiplas conexões é chamado de Comunicação em Grupo e segundo Tanenbaum e Steen (2002), tem peculiaridades e características específicas. Um grupo é uma coleção de processos que interagem entre si em algum sistema. A propriedade chave que todos os grupos tem é que quando uma mensagem é enviada para o grupo, todos os membros do grupo recebem esta mensagem. Esta forma é chamada Comunicação Um-Para-Muitos, um transmissor para muitos receptores.
Grupos são dinâmicos e assim novos grupos podem ser criados e grupos antigos podem ser destruídos. Um processo pode juntar-se a um grupo ou deixar um grupo. Um processo pode ser membro de diversos grupos ao mesmo tempo. Assim mecanismos são necessários para gerenciar grupos e os processos participantes dos grupos. Quando usamos mecanismos de comunicação em grupo os processos tratam com coleções de outros processos de forma abstrata. Se um processo envia uma mensagem para um grupo de servidores, este processo não precisa se preocupar quantos são os servidores nem onde eles estão localizados. Inclusive já na chamada seguinte o número de servidores deste grupo e suas localizações podem mudar sendo esta alteração transparente para o processo que envia a mensagem para o grupo (GOULART, 2002).
A figura 3 apresenta a ilustração de uma comunicação em grupo.
17
Goulart e Friedrich (2002, p. 4) enumeram os seguintes mecanismos de comunicação em grupo existentes: ISIS (BIRMAN; RENESSE,,1994); PHOENIX (MALLOTH, 1996); RMP (WHETTEN; MONTGOMER; KAPLAN,1994); TOTEM (MOSER et. al., 1996); HORUS (RENESSE,1996); ENSEMBLE (HAYDEN, 1998); TRANSIS (DOLEV; MALKI,1996); NEWTOP (EZHILCHELVAN; MACEDO; SHRIVASTAVA 1995); ATOMIC (KOCH, 2000); INTERGROUP (BERKET, 2000); JGROUP (MONTRESOR, 2000) e SPREAD (AMIR,1998).
Alguns destes mecanismos foram desenvolvidos, tiveram alguma evolução e depois permaneceram sem atualizações. Outros como INTERGROUP e JGROUP são bem recentes e totalmente baseados em ambiente Java/RMI. Já o SPREAD é um dos mecanismos de comunicação em grupo que vem evoluindo ao longo do tempo, com boa documentação, disponibilidade de fontes na modalidade Open Source. Está, portado para diversos sistemas operacionais como UNIX (AIX, BSDI, LINUX, FreeBSD, SGI, MAC OSX, SGI, SOLARIS, SUNos), Windows e Mac OS. Conta com bibliotecas que podem ser usadas em linguagens tipo C,C#, PERL e JAVA.
Para o presente TCC foi adotado o mecanismo de comunicação em grupo SPREAD (AMIR, 1998) por ser disponível em diversas plataformas, ter uma boa documentação e atender tanto comunicação em grupo para redes locais (LAN) como redes de longa distância (WAN). O SPREAD tem a funcionalidade de um middleware que separa a aplicação da plataforma. Assim a aplicação pode ser executada em qualquer ambiente de hardware ou sistema operacional que tenha a implementação do SPREAD já portada.
2.3 MECANISMO DE COMUNICAÇÃO EM GRUPO SPREAD
SPREAD é um toolkit de código aberto (open source) que fornece um serviço de alto desempenho e resistente a falhas em redes WAN e LAN. SPREAD é um ambiente de mensagens unificadas para aplicações distribuidas e provê um alto nível de aplicação multicast, comunicação em grupo e ponto a ponto. O SPREAD é totalmente confiável e garante a entrega das mensagens. (SPREAD, 2009)
SPREAD é bastante parametrizado, permitindo que o usuário possa configurar o mesmo de acordo com as suas necessidades. SPREAD pode ser configurado para usar um daemon único para toda a rede, um por segmento de rede ou até um em cada máquina rodando aplicação de comunicação em grupo. A complexidade no SPREAD está escondida atrás de uma simples, mas
18
completa interface de programação de aplicação (API) que pode ser usada tanto para serviços orientados a redes locais como para redes de grande distância sem mudança na aplicação e que prove um modelo claro de comunicação em grupo (GOULART, 2002).
Segundo Goulart (2002), o mecanismo de comunicação em grupo SPREAD trata as dificuldades encontradas em redes Wide Area Network (WAN) através de três principais características:
a) uso de diferentes protocolos de baixo nível que provêm o envio confiável de mensagens de acordo com a configuração da rede;
b) uso da arquitetura cliente-servidor, que dentre muitos benefícios, o mais importante é a habilidade de pagar um preço mínimo para as diferentes causas de alterações de membros do grupo, como o processo de entrada ou saída de um grupo que se resume a uma simples mensagem;
c) separar o mecanismo de disseminação e segurança local do protocolo de ordenação e estabilidade, permitindo o envio imediato de mensagens à rede, independente de outros controles de perda e ordenação.
Amir e Stanton (1998) explicam ainda que o SPREAD baseia-se no modelo cliente-servidor, onde um ou mais servidores, ou daemons, são responsáveis pela formação da rede de disseminação de mensagens e pelo fornecimento dos serviços de ordenação e gerência de membros dos grupos. Os clientes por sua vez são formados por aplicações que possuem uma pequena biblioteca introduzida em seu código que permite a conexão ao servidor SPREAD. Estes clientes podem estar em qualquer ponto da rede.
Outra característica do mecanismo de comunicação em grupo SPREAD é possuir uma estrutura tolerante a falhas que garante a continuidade da troca de mensagens mesmo nas situações em que vários nodos da rede deixam de funcionar. Sua arquitetura possibilita também que novos computadores sejam adicionados ao sistema distribuído sem que seja necessário alterar o código da aplicação (ZAWODNY, 2003).
Giordano e Jansch-Pôrto (2000) descrevem esta característica como implementada na camada de roteamento do mecanismo SPREAD, fazendo com que o sistema permaneça estável, provendo confiabilidade, robustez e consistência. O mecanismo SPREAD compreende uma camada de rede composta pelo protocolo Ring, para domínios multicast e redes do tipo LAN, e o protocolo Hop, para conexões ponto-a-ponto e redes do tipo WAN. Ambos os protocolos são integrados em um sistema baseado em árvores de roteamento que garantem um melhor desempenho em uma rede de comunicação confiável.
19 Figura 4 Arquiteura do SPREAD
Fonte: Goulart (2002)
A arquitetura do SPREAD é apresentada na Figura 4. Aplicações do usuário são ligadas com uma biblioteca SP_lib (ou usam classes JAVA) a qual prove o completo interface para o cliente , como descrito a seguir. A conexão entre a SP_lib e o daemon é uma conexão confiável ponto a ponto, seja IPC ou através da rede. Os módulos de Sessão e Grupos gerenciam as conexões de usuários, gerenciam o processo de participação dos membros no grupo, e traduzem as mudanças de membros do grupo no daemon em mudanças de membros do grupo no processo Grupo. A área sombreada na Figura 4 representa o protocolo interno do daemon. Os detalhes destes protocolos serão vistos na seqüência. Alguns principais pontos são:
• Múltiplas filas existem entre os módulos de Sessão e Transporte, um para cada sessão. Isto permite o manuseio de prioridades.
• O módulo de roteamento calcula as árvores de roteamento baseada nos dados do modulo de rede. O módulo de transporte consulta o módulo de roteamento para determinar os links (HOPs e RINGs) no qual cada mensagem será enviada.
20
• Diversas instâncias do módulo HOP podem existir, cada uma delas representando uma facilidade que é usada por uma ou mais árvores de roteamento.
• No mínimo um modulo RING trata da disseminação e confiabilidade no site local se mais de um daemon está ativo neste site.
• As instâncias de HOP e RING podem ser destruídas ou criadas de acordo com as mudanças dos membros do grupo.
O SPREAD trata com protocolos específicos para ligação local entre os daemons ou para ligação via rede WAN entre os daemons(GOULART, 2002).
As aplicações que constituem os clientes possuem uma biblioteca integrada ao seu código, que por sua vez fornece uma Application Program Interface (API) para a comunicação com o servidor SPREAD. Stanton (2002, p. 23) descreve detalhadamente esta API, que se resume nas seguintes funções:
a) sp_connect: estabelece a comunicação com o servidor SPREAD; b) sp_disconnet: finaliza a conexão com o servidor SPREAD; c) sp_join: entra em um determinado grupo;
d) sp_leave: sai de um determinado grupo;
e) sp_multicast: envia uma mensagem aos membros de um grupo; e
f) sp_receive: recebe mensagens enviadas por outros membros do grupo ou pelo servidor SPREAD. Um parâmetro da função informa se a mensagem é constituída por dados ou se contém informações de alteração nos grupos, como por exemplo, a entrada ou saída de um usuário.
Quanto ao processo de configuração do servidor SPREAD, deve-se determinar o endereço broadcast da rede onde o servidor irá atuar, bem como a porta em que irá aguardar por conexões. Deve-se também configurar um nome para o servidor e o endereço Internet Protocol (IP) de cada computador que estiver executando uma instância do servidor SPREAD.
O que se tem de mais importante no sistema SPREAD são os protocolos que suportam disseminação, confiabilidade, ordenação e estabilidade. Duas camadas de protocolos separados atendem este serviço no SPREAD:
• Camada de rede – composta de dois componentes: para o nível de link que provê confiabilidade e controle de fluxo para os pacotes, SPREAD implementa dois protocolos, o protocolo HOP para conexões ponto a ponto e o protocolo RING para
21
domínios multicast. Cada protocolo é otimizado para o seu domínio específico. O roteamento que constrói a rede de saída dos HOPs e RINGs baseado nos membros de grupos que estão conectados no daemon no momento e seu conhecimento sobre a rede a qual está trafegando. A rede construída é implementada através de uma árvore de disseminação diferente e residente em cada site. A figura 3 ilustra este esquema de roteamento.
• Camada de transporte – esta camada trata da entrega de mensagens, ordenação, estabilidade e fluxo de controle global. A camada de transporte opera através de todos os daemons ativos no sistema. (GOULART, 2002)
Figura 5 Exemplo de roteamento. Fonte: Goulart (2002).
Um exemplo de rede é mostrado na Figura 5, onde diversos sites são mostrados, geograficamente dispersos, com diferentes custos de link entre eles. Define-se como site uma coleção de máquinas que potencialmente pode encontrar outra máquina através de uma única mensagem, exemplo broadcast, hardware multicast ou IP multicast . Cada site pode ter até dezenas de máquinas nele, o qual não impacta a escalabilidade do sistema SPREAD, já que todas as operações não locais a este site escalam com o número de sites e não com o número total de máquinas envolvidas. Todos os daemons participantes de uma configuração SPREAD sabem o completo potencial dos membros participante quando iniciado, mas todo o conhecimento do atual
22
membro participante do daemon ativo é obtido dinamicamente durante a operação. Cada site tem um daemon que atua como representante do site, participando da disseminação na rede de longa distância. Este representante é determinado baseado nos membros participantes neste momento no site local e não é uma configuração fixa por hardware (GOULART, 2002).
2.4 TRABALHOS CORRELATOS
SPREAD tem sido usado por outros softwares bem conhecidos no mercado. Este reconhecimento da importância do SPREAD tem sido dado tanto por empresas como por usuários, Aplicações como MySQL ou APACHE tem usado a API para incrementar seus sistemas. A seguir são listados alguns exemplos de uso do produto SPREAD conjugado com outros produtos de mercado.
Perl Messaging:Courier library
A Perl Messaging API utiliza SPREAD como sua implementação de mensageiro básica. Se auto descreve como provendo "acesso sincrono e assincrono para as filas de requisições”.
MySQL API Message
A API MM é um conjunto de funções definidas pelo Usuário (UDFs) que habilitam o servidor MySQL a enviar e receber msgs através de uma rede. Ela permite usuários Mysql executarem simples consulta SQL que resultam em uma mensagem sendo enviada para outras aplicações ou serviço usando SPREAD. O código pode ser baixado inclusive do site principal ou por Google code.
Mod Log SPREAD
Um módulo Apache que oferece distribuição de logs confiável de um cluster de servidores apache. Um log de correção para httpd também esta disponivel. Este é geralmente usado por sites com dezenas de maquinas para prover logs centralizados para todo o cluster, bem como as várias copias de logs para redundância e razões de auditoria.
23 Splash
Um módulo de cache para Apache-SSl que permite um cluster de Servidores Web com SSL habilitada compartilhar a cache para conexões SSL ativas. Isto aumenta a performance do cluster prevenindo renegociações de chaves quando um cliente muda o servidor ao qual ele esta conectando (SPREAD, 2009).
24
3 PROJETO
Nesse capítulo é apresentado o escopo do sistema, a análise de requisitos, os diagramas de casos de uso, diagrama de classes e os protótipos de tela utilizados para a construção da aplicação cliente e servidor de log centralizado via comunicação em grupo.
3.1 ESCOPO DO SISTEMA
O Escopo deste trabalho se referiu ao desenvolvimento de um sistema concentrador de Logs utilizando a linguagem C# na qual utilizou a ferramenta SPREAD. Esta ferramenta, voltada para comunicação em grupo foi a responsável pela transferência e a garantia de chegada dos Logs a serem enviados dos clientes para um ponto central. O cliente foi executado com agendamento prévio logo após a rotina de backup, fazendo a comunicação com o ponto central e transmitindo o respectivo Log do backup usando Comunicação em Grupo.
3.2 Análise de Requisitos
A análise de requisitos foi realizada com o objetivo de identificar o escopo do projeto e definir as funcionalidades que o sistema disponibilizará. Na análise, os requisitos funcionais, os não funcionais e as regras de negócio foram elicitados, documentados e analisados. As seções seguintes apresentam o resultado desse trabalho.
3.2.1 Requisitos funcionais
Os requisitos funcionais descrevem o funcionamento do sistema e abrangem as tarefas que ele disponibilizará aos usuários. Para maior entendimento e dimensão da ferramenta, os requisitos funcionais foram divididos em dois aplicativos: LCCG Client e LCCG Server. Na etapa de análise os seguintes requisitos funcionais foram identificados:
LCCG Client:
• RF01: O sistema deverá permitir adicionar ou alterar uma conexão com o servidor. • RF02: O sistema deverá permitir adicionar ou alterar a hora de coletar os Logs. • RF03: O sistema deverá permitir selecionar a pasta onde será coletado o Logs.
25
• RF04 O sistema deverá permitir adicionar ou alterar a quantidade de tentativas de coletar os Logs; e
• RF05 O sistema deverá permitir adicionar ou alterar as horas de tentativas após o primeiro agendamento.
LCCG Server:
• RF01: O sistema deverá permitir cadastrar a conexão com o banco de dados. • RF02: O sistema deverá exibir as conexões ativas.
• RF03: O sistema deverá concentrar os logs no banco de dados; e • RF04: O sistema deverá visualizar o tráfego de conexões.
3.2.2
Requisitos Não funcionais
Os requisitos não funcionais especificam as características do software, neste caso, a linguagem de programação, o banco de dados e a plataforma utilizados.
• RNF01: O sistema deve ser voltado para aplicação desktop. • RNF02: O sistema deve ser desenvolvido na linguagem C#; e • RNF03: O sistema utilizará o Banco de Dados SQL Server 2008.
3.2.3
Regras de Negócio
As regras de negócio definem as particularidades do funcionamento da ferramenta:
• RN01: A aplicação cliente deverá transferir todo o log para o servidor. • RN02: A API SPREAD será responsável pelo transporte dos logs. • RN03: Os daemons serão executados em cada cliente.
26
3.3 Diagrama de Casos de Uso
O diagrama de caso de uso representa as funcionalidades do sistema do ponto de vista do usuário. A seguir são apresentados os casos de uso do LCCG Client e do LCCG Server que irão compor os dois softwares neste projeto.
3.3.1 Aplicativo Cliente
O diagrama de casos de uso do aplicativo cliente apresenta os casos de uso pertinentes ao usuário do aplicativo, que são: Configurar e alterar agendamentos, configurar e alterar pasta de geração de logs , configurar e alterar o servidor para onde será enviado os logs.
A Figura 4 ilustra esse caso de uso.
uc LCCG Client
LCCG Client
UC01 - Configurar e altera Agendamento
UC02 - Configurar e altera IP Serv idor
UC03 - Configura e altera pasta de geração Log´s
Figura 6 Diagrama de casos de uso LCCG Client
27
O caso de uso configurar e alterar agendamento na figura 6 refere-se à configuração da hora que será executado a coleta dos dados, assim como a quantidade de tentativas que ele tentará novamente em caso de falha e a hora para a nova tentantiva.
Já o caso de uso configurar e alterar pasta de geração de logs na figura 6 permite ao usuário definir exatamente onde o software cliente irá buscar os novos logs gerados.
A configuração do servidor de envio dos logs será feita pelo botão de configuração de IP do servidor, na qual será possível a alteração do servidor de envio e o teste de conexão bem sucedido.
A Figura 5 apresenta o diagrama de classes do aplicativo cliente, sendo estas as seguintes: FramePrincipal, ThreadControle, Servidor e Enviar. A classe FramePrincipal é responsável pela aparência gráfica da aplicação, ou seja, o controle da janela principal, menu e demais componentes visuais necessários.
A classe ThreadControle é responsável por todos os processos que envolvem o servidor SPREAD, como: conexão, troca de mensagens e gerência da entrada e saída de servidores do grupo principal. Uma instância da classe ThreadControle é na verdade uma thread, pois é necessário que a aplicação permaneça em loop verificando constantemente a existência de mensagens através da função SP_receive da API do mecanismo de comunicação em grupo SPREAD. A thread permanece ininterruptamente em execução, e somente é finalizada quando a aplicação é encerrada ou quando ocorre um erro na comunicação com o servidor SPREAD. A classe ThreadControle relaciona-se com a classe FramePrincipal, onde acessa recursos visuais. A função exectime é executada conforme a hora programada para pegar os logs.
A classe Enviar é chamada assim que a função Exectime é executada e é responsável por localizar na pasta de origem os logs e checar se o log já está disponível, enviando o log para o servidor através das informações da classe servidor.
28 class Client Class
LCCG Serv er::Principal + FramePrinicipal() + inicializathreadcontrole() LCCG Serv er:: Env iar + Getlog() + Sendlog()
LCCG Serv er::Serv idor
- Nome: char - Rede: char + Getnome() + Getrede() + Servidor() LCCG Serv er:: ThreadControle + Connectspread() + desconectspread() + Exectime() + Exitgroup() + JoinGroup() + run() + Sendmsgserver() 1 1 1 1 1 1 1 1
Figura 7 Diagarma de classe do aplicativo cliente
Quanto ao diagrama de seqüência, a Figura 8 apresenta o processo de envio do log para o servidor, onde o objeto da classe FramePrincipal aciona o método inicializathreadcontrole(), que irá criar um novo objeto da classe Threadcontrole, responsável pela execução do objeto Exectime na qual enviará os logs através da classe Enviar usando os métodos Getlog para buscar os logs e o método Sendlog para enviar os logs.
29 sd Client Sequence Principal (from ) Theadcontrole (from ) Server (from ) Enviar (from ) InicializaTheadControle() Startserver() Getserver() Connectspread() Joingroup() Exectime() Getlog() Sendlog()
30
3.3.2
Aplicativo Servidor
A especificação do aplicativo servidor é apresentada inicialmente pelo diagrama de caso de uso, que ilustra os casos de uso: configurar BD, visualizar conexões ativas, visualizar tráfego de conexões. A Figura 9 ilustra esse caso de uso.
uc Serv er UC Administrador UC01 - Visualiza conexões ativ as UC02 Configurar BD UC03 - Visualiza tráfego conexões
Figura 9 Diagrama de casos de uso do aplicativo servidor.
O caso de uso visualizar conexões ativas permite ao administrador visualizar todos os aplicativos clientes conectados naquele momento, tendo uma visualização real das máquinas ativas.
O caso de uso configurar BD o administrador ativará a conexão com o banco de dados. O Caso de uso visualiza tráfego de conexões o administrador poderá visualizar em sua tela as conexões com os clientes;
O aplicativo servidor, será composto pelas seguintes classes: ControleServer, na qual teremos o controle sobre das conexões com o SPREAD, o FramePrincipal, na qual será exibido as
31
conexões ativas e será exibido o tráfego de recebimento de conexões do SPREAD, uma classe chamada BD que será responsável pela conexão e inserção dos logs no banco de dados e uma Classe chamada VisualizaMembers que manterá atualizado para o administrador todos os clientes ativos no servidor. Apresentado na Figura 10.
class Serv er Class
FramePrincipal + Framaprincipal() + inicializaTheadcontrole() + inicializaview() VisualizaMembers + Viewmember() ControleServ er - Conexaospread: char - Nomeserver: char + Connectspread() + Delgroup() + Disconectspread() + Exitgroup() + Joingroup() + Receivespread() + run() BD + insertBD() 1 0..* 1 1 1 1
Figura 10 Diagrama de classes do aplicativo servidor
O diagrama de sequência na figura 11 mostra o objeto da classe BD inserindo no banco de dados os logs recebidos do cliente através da classe controleServer.
32 sd Serv er Sequence
Principal ControleServer Database
Inicializatheadcontrole()
Connectspread()
Joingroup()
Run()
InserdBD()
Figura 11 Diagrama de sequência inserindo log no Banco de Dados
O diagrama de sequência da Figura 12 apresenta a visualização das conexões ativas pelos clientes no servidor.
33 sd Serv er View
Principal Visualizamembers
inicializaview()
viewmembers()
Figura 12 Diagrama de sequência visualizando membros ativos.
3.4 IMPLEMENTAÇÃO
Este tópico apresenta as técnicas e ferramentas utilizadas no desenvolvimento do trabalho, como: método de desenvolvimento e implementação, ambiente e linguagem de programação. É apresentada também a explanação, com partes do código-fonte, das funcionalidades mais relevantes do sistema, como: transferência dos logs para o concentrador de logs com o mecanismo de comunicação em grupo SPREAD , troca de mensagens entre o cliente e os servidores, mecanismo de divisão de tarefas distribuídas.
3.4.1 INTERFACES
Na Figura 13 podemos ver a tela para o cliente na qual estaremos configurando o servidor para conexão de SPREAD, a pasta de backup onde será gerado os logs e o tempo que iniciará a execução da coleta do log.
34 Figura 13 Aplicação cliente
Na Figura 14 podemos ver uma pasta de armazenamento no próprio windows para coleta dos logs e após o envio, ele move automaticamente o log para pasta Enviados.
Figura 14 Pasta de armazenamento de logs gerados no cliente.
35
Na Figura 15 verifica-se o a tela do LGGC Server, na qual podemos verificar as conexões ativas com os clientes o botão de conexão com o banco de dados e o status de tráfego dos clientes conectando no servidor, nota-se que quando a conexão foi bem sucedida automaticamente o botão fica inativo, quando ocorrer algum erro ele gera uma mensagem informando que aconteceu algum erro na comunicação com o banco de dados.
Figura 15 Aplicação servidor.
3.4.2
Técnicas e ferramentas utilizadas
A linguagem de programação escolhida para o desenvolvimento do trabalho apresentado é a linguagem C#. Esta escolha deu-se principalmente pelo fato de que o mecanismo de comunicação em grupo SPREAD, utilizado no trabalho, é escrito e oferece uma API completa nesta mesma linguagem.
Verificou-se ainda durante a revisão bibliográfica, a existência desta mesma API para a linguagem Java e PERL, bem como bibliotecas de adaptação da API original do SPREAD para
36
plataformas como o Delphi. Será utilizada a linguagem C# motivado pelos ensinamentos da linguagem na Universidade e pelo maior domínio da linguagem.
Quanto ao ambiente de desenvolvimento, foi selecionado o Visual Studio 2008 para plataforma Windows, por oferecer um bom sistema de depuração e a existência de maior domínio sobre a ferramenta.
3.4.3 Processo de implementação
Quanto às funcionalidades implementadas, a interligação com o mecanismo SPREAD dá-se por meio de uma thread que é executada no momento em que na aplicação é inserido o IP do servidor e pressionado o botão conectar. Somente finaliza em caso de erro na conexão ou quando a aplicação for encerrada, tanto no aplicativo cliente quanto servidor. Inicialmente a thread tenta estabelecer uma conexão com o servidor SPREAD, e caso ocorra algum erro grave, a thread é encerrada. No caso de um erro por inatividade do servidor SPREAD, a thread continua em execução e tenta novamente estabelecer uma conexão em intervalos de tempo predefinidos.
37
4 DESENVOLVIMENTO
Nesta etapa do TCC são confeccionados os principais trechos de códigos fonte do sistema descrito na etapa de projeto, assim como a elaboração integral do sistema.
4.1 Banco de dados
Na criação do banco de dados vale destacar um ponto: a escolha do SQL Server 2008 que ocorreu devido a grande interação que há com o Visual Studio 2008. Como ambos são pacotes microsoft a integração entre eles é facilitada. Para a criação e manutenção da base de dados foi utilizado o SQL Server Management Studio que é uma ferramenta que é instalada juntamente com o SQL Server 2008. Para a utilização deste banco de dados foi necessário atualizar o Visual Studio para service pack 2. A utilização desse software de acesso ao banco de dados pode ser visualizada na Figura 16. As as tabelas continham colunas identificadas através de prefixo como sugere as boas práticas de programação.
Figura 16 Banco de Dados
38
4.2.1 LCCG Client
O LCCG Client é responsável por transferir o arquivo de LOG do computador na qual ele está instalado para o LCCG Server, que recebe este arquivo e insere no banco de dados. Nesta parte de desenvolvimento foi implementado os requisitos funcionais:
O sistema deverá permitir adicionar ou alterar uma conexão com o servidor O sistema deverá permitir adicionar ou alterar a hora de coletar os Logs. O sistema deverá permitir selecionar a pasta onde será coletado os Logs.
O sistema deverá permitir adicionar ou alterar a quantidade de tentativas de coletar os Logs. O sistema deverá permitir adicionar ou alterar as horas de tentativas após o primeiro
agendamento.
Na Figura 13 é possível ver todos estes requisitos.
A conexão é feita através da API SPREAD e com os daemons SPREAD em execução, rodando nos computadores locais, conforme podemos ver na figura 17
39 Figura 17 Daemon SPREAD em execução.
4.2.2 LCCG Server
O LCCG Server é responsável por coletar todos os log’s recebido pelos LCCG Client’s e armazenar no banco de dados. Localizado no LCCG Server, um daemon local também é executado conforme a figura 17. É feita a conexão através da API SPREAD, que utiliza o método
40
connection.Receive() para receber estes log’s e, posteriormente, através do método SqlCommand, é
feito as inserções no banco de dados SQL Server 2008 através do visual Studio 2008. Na figura 18 podemos ver o arquivo de configuração dos daemons.
Figura 18 Arquivo de configuração do servidor SPREAD.
Após a configuração do arquivo do SPREAD é necessário executar o spread.exe que passa a rodar juntamente com os processos do windows, apto a realizar a comunicação entre os grupos. Na figura 17 podemos ver ele em execução.
Os requisitos funcionais do LCCG Server são:
41 O sistema deverá exibir as conexões ativas.
O sistema deverá concentrar os logs no banco de dados O sistema deverá visualizar o tráfego de conexões.
Todos os requisitos foram implementados conforme podemos ver na tela referente a figura 15.
4.2.3 Testes
Os testes foram realizados em um laboratório usando 4 computadores e um notebook, que foi pré definido como servidor. No notebook estava instalado SQL Server 2008, visual studio 2008 atualizado para service pack 2, por compatibilidade. Sem esta atualização não seria possível instalar o SQL Server 2008. Nos computadores demonimados LCCG clientes foi executado um daemon conforme arquivo de configuração do spread.conf do daemon na figura 19
42
Figura 19 Configuração do arquivo spread.conf nos testes.
Foi feito a conexão no servidor SPREAD. Em todos os LCCG Clientes foi executada a entrada no grupo “Udo” definida no código fonte. Primeiro foram enviados manualmente os arquivos de log de cada LCCG Client. Logo após, foi feito um agendamento com tempo igual para todos os LCCG Clients e a execução foi feita sumultaneamente, conforme o agendamento. Depois da execução dos LCCG Clientes, foi feita a checagem no banco de dados através da aplicação SQL Server Management Studio e executado um comando SQL para verificar os dados adicionados. Ambos os testes foram bem sucedidos. Pode-se verificar este comando na figura 20.
43
44
5 CONSIDERAÇÕES FINAIS
Este trabalho apresentou o uma ferramenta para comunicação em grupo que realiza a transferência de arquivo de log’s de diversos clientes para um único servidor centralizado. O servidor tem a função de receber os log’s e armazenar em um banco de dados que, para este propósito, foi o SQL Server 2008
Para o desenvolvimento do sistema proposto foram estudadas algumas ferramentas utilizadas para comunicação em grupo existentes no mercado. Conforme mencionado as ferramentas neste TCC são as mais usadas e o foco nos estudos foi voltada para as mesmas.
No decorrer deste projeto, identificou-se a possibilidade de trabalhos futuros e ampliação do sistema através de outro software que poderá coletar as informações do banco de dados e exportar para um arquivo de texto ou em um formato mais amigável dos dados para o usuário.
45
REFERÊNCIAS BIBLIOGRÁFICAS
AMIR, Y.; STANTON, J. The SPREAD wide area group Communication System. Baltimore: Technical report, Center of Networking and Distributed Systems, Johns
HOPkins University,1998. Disponível em: <http://www.cnds.jhu.edu/publications/>. Acesso em: fev. 2010.
BERKET, K. The InterGroup Protocols: scalable group communication for the Internet. Dissertation -University of California– USA 2000. Disponível em: <http://www-itg.lbl.gov/InterGroup>. Acesso em: maio 2010.
BIRMAN, K; RENESSE, R. Van. Reliable Distributed Computing with the ISIS Toolkit. Los Alamitos: IEEE Computer Society Press, 1994.
COULORIS, George. Sistemas Distribuídos: conceitos e projetos; Tradução João Tortello. 4. ed. Porto Alegre: Bookman, 2007.
DOLEV, D.; MALKI, D. The Transis Approach to High Availability Cluster Communication. New York: Communications of the ACM, 39(4), Abril. 1996.
EZHILCHELVAN, P.; MACEDO, R.; SHRIVASTAVA, A. NEWTOP: A Fault -tolerante Group Communication Protocol. Vancouver: Proceedings of the 15th IEEE International Conference on Distributed Computing Systems, pag 296-306, maio 1995.
GIORDANO, Liliane; JANSCH-PÔRTO, Ingrid E. S. Roteamento dinâmico para melhorar
resultados decorrentes da imprecisão dos detectores de defeitos. Porto Alegre, [2000]. Disponível
em: <http://www.inf.ufrgs.br/pos/SemanaAcademica/Semana2000/Liliane/>. Acesso em: maio. 2010.
GOULART, Ademir; FRIEDRICH, Luis F. Gerenciamento de recursos em sistemas distribuídos
usando comunicação em grupo. Itajaí, 2002. Disponível em: <http://www.cbcomp.univali.br/anais/anais.htm>. Acesso em: mar. 2010.
GOULART, Ademir. Avaliação de mecanismos de comunicação em grupo para ambientes wan. 2002. 169 f. Dissertação (Mestrado em Ciências da Computação) - Universidade Federal de Santa Catarina, Florianópolis, 2002.
HAYDEN, M. The Ensenble System. PhD Thesis, Ithaca,NY: Departamento de Ciência da Computação, Universidade de Cornell, Janeiro 1998.
46
JANKE, Anderson Rodrigo. Busca distribuída utilizando comunicação em grupo para a resolução
do problema 8-puzzle. 2004. Disponível em: <http://www.inf.furb.br/>. Acesso em: abr. 2010.
KOCH, R.R. The atomic group protocols: reliable ordered message delivery for ATM networks. PhD Dissertação, Department of Electrical and Computer EngineeRING, Santa Barbara: Universidade da Colifórnia, Dezembro 2000.
MALLOTH, C. Conception and Implementation of a Toolkit for Building Fault-Tolerant Distributed Applications in Large-Scale Networks. PhD thesis, Lausanne, Switzerland: Ecole Polytechnique Federale de Lausanne, September 1996.
MONTRESOR, A. System Support for Programming Object -Oriented Dependable Applications
in Partitionable Systems. Technical Report UBLCS-2000-10 , Bologna: Universidade de Bologna,
2000. Disponível em: <http://www.cs.unibo.it>. Acesso em: 10 maio 2010.
MOSER, L. E.; MELLIAR-SMITH, P.M.; AGARWAL, D.A.;BUDHIA, R.;LINGLEY-PAPADOULOS, C. Totem: A Fault-Tolerant Group Communication System. New York: Communications of the ACM, 39(4), April 1996.
RENESSE, R. van; BIRMAN, K.P.; MAFFEIS, S. Horus: a flexible group communication system. New York: Communications of ACM, 39(4): 76-83, April. 1996.
SPREAD Concepts LLC. 2009. Disponível em: <http://www.SPREAD.org/>. Acesso em: mar. 2010.
STANTON, Jonathan R. A users guide to spread. [s.l.]: 2002. Disponível em: <http://www.spread.org/docs/guide/users_guide.pdf>. Acesso em: mar. 2010.
TANENBAUM, Andrew S.; STEEN, Maarten V. Distributed systems: principles and paradigms. Nova Jersey: Prentice Hall, 2002.
ZAWODNY, Jeremy. Do it yourself: the SPREAD toolkit. Linux Magazine, San Francisco, abril 2003. Disponível em: <http://www.linux-mag.com/2003-04/diy_01.html>. Acesso em: 10 maio 2010.
WHETTEN, B.; MONTGOMER, Y., T.; KAPLAN, S. A High Performance Totally Ordered Multicast Protocol. Proceedings of the International WorksHOP on Theory and Practice in Distributed Systems, pag 33-57, Dagstuhl Castle, Alemanha, Setembro 1994.
47
48
Apêndice 1 Código fonte detalhado de cada botão
LCCG Cliente
Detalhamento das funções do LCCG Cliente.
Conexão SPREAD
Na figura 21 executa-se a conexão com o SPREAD, assim como entra em um grupo pré definido.
Figura 21 Conexão com SPREAD
Código fonte conexão com SPREAD: private bool InicializaConexao() {
string[] sConfiguracao = this.ConfiguraConexao(); if (sConfiguracao != null)
{
string sEndereco = sConfiguracao[0]; string sPorta = sConfiguracao[1];
this._user.Conectar(this.user, sEndereco, Int32.Parse(sPorta));
this._user.EntrarGrupo(new string[] { "Udo" }); //entra no grupo
this._conectado = true; }
if (!this._conectado)
MessageBox.Show("Não foi possível conectar."); return this._conectado;
49
Processo de envio de dados
Na Figura 22 inicializa o processo de envio de LOG da máquina cliente para o servidor.
Figura 22 Botão de execução de processo de envio.
Código fonte do botão executar:
private void btnExec_Click(object sender, EventArgs e)
{ if (!this._conectado) this.InicializaConexao(); if (this._conectado) this.EnvioMensagem(); }
private void EnvioMensagem() {
if (string.IsNullOrEmpty(this.txtCaminhoPastaLog.Text))
MessageBox.Show("Por favor, selecione o caminho da pasta do arquivo de backup.");
//Verifica se o arquivo existe
string sNomeArquivo = this.txtCaminhoPastaLog.Text + "\\Backup.txt ";
if (!System.IO.File.Exists(sNomeArquivo)) {
MessageBox.Show("Arquivo de backup.txt da pasta selecionada não encontrado.");
return; }
//Lê o Arquivo
StreamReader objReader = new StreamReader(sNomeArquivo); string sLine = "";
ArrayList arrText = new ArrayList();
while (sLine != null) {
sLine = objReader.ReadLine(); if (sLine != null)
{
arrText.Add(sLine); //le o arquivo
} }
50
string Data = DateTime.Now.Day.ToString() +
DateTime.Now.ToString("HHmmsstt");
string filename = "Backup" + Data + ".txt "; foreach (string sOutput in arrText)
this._user.EnviarMsg(new string[] { "Udo" }, filename + ':' + sOutput); // envia o arquivo para o grupo
System.IO.File.Move(this.txtCaminhoPastaLog.Text + "\\Backup.txt",
this.txtCaminhoPastaLog.Text + "\\Enviadas\\" + filename); // move o arquivo para pasta enviadas e renomeia
}
Ativação do timer
Na ativação do timer é possível fazer o agendamento de um horário pré definido pelo usuário para começar o envio dos LOG’s para o servidor, é necessário definir o horário de inicio dos LOG’s, a quantidade de tentativas após a primeira, caso a primeira falhe, e o tempo para fazer uma nova tentativa.
Figura 23 Ativar e desativar timer.
Abaixo o código fonte do botão Ativar Timer
private void timerExec_Tick(object sender, EventArgs e) {
//Verifica se já está na hora inicial
DateTime dtHoraInicialTimer;
if (DateTime.TryParse(this.txtHinicial.Text, out
dtHoraInicialTimer))
if (DateTime.Now > dtHoraInicialTimer)
//Verifica se já extrapolou as tentativas
if (this._tentativasEfetuadas <
Int32.Parse(this.txtTentativas.Text))
{
this.btnExec_Click(this, null); }
this._tentativasEfetuadas++; }
private void btTimer_Click(object sender, EventArgs e) {
51
this.timerExec.Enabled = !this.timerExec.Enabled;
if (this.timerExec.Enabled) {
this.btTimer.Text = "Desativar Timer"; this.timerExec_Tick(this, null);
} else
this.btTimer.Text = "Ativar Timer"; }
private void txtHTentativas_Leave(object sender, EventArgs e) {
//Define tempo do timer em milisegundos
this.timerExec.Interval = this.ObterTempoTimer(); }
private void btnParar_Click(object sender, EventArgs e) {
this.timerExec.Enabled = false; this.btTimer.Text = "Ativar Timer";
}
private int ObterTempoTimer() {
int iMinutos = Int32.Parse(this.txtHTentativas.Text); return iMinutos * 60 * 1000;
}
Botão parar
Na figura 24, o botão parar desativa a execução do timer e deixa a aplicação cliente somente em modo de execução manual.
Figura 24 Botão parar
Abaixo código fonte do botão parar:
private void btnParar_Click(object sender, EventArgs e)
{
this.timerExec.Enabled = false; this.btTimer.Text = "Ativar Timer";
52
Selecionar pasta
Componente de seleção de pasta na qual define exatamente onde serão coletados os arquivos de log’s.
Figura 25 Seleção de pasta onde será gerado os log’s
Abaixo código fonte da seleção da pasta de geração de log’s.
private void btnSelectPastaLog_Click(object sender, EventArgs e) {
if (this.folderBrowserDialog1.ShowDialog() == DialogResult.OK) { this.txtCaminhoPastaLog.Text = this.folderBrowserDialog1.SelectedPath; } }
LCCG Server
Descrição de detalhamento de cada botão no LCCG Server
Conexão com banco de dados.
Executa a conexão no banco de dados assim como a conexão no SPREAD e no grupo pré definido pelo programador.
Figura 26 Botão de conexão com o banco de dados.
53 private string[] ConfiguraConexao() {
string sEndereco = "localhost"; string sPorta = "4803";
return new string[] { sEndereco, sPorta }; }
private void btnConnectDB_Click(object sender, EventArgs e) {
this.InicializaEnvioMsg(); }
private void timer1_Tick(object sender, EventArgs e) {
}
}
private void InicializaEnvioMsg() {
string[] sConfiguracao = this.ConfiguraConexao(); if (sConfiguracao != null)
{
string sEndereco = sConfiguracao[0]; string sPorta = sConfiguracao[1];
this._user.Conectar(this.user, sEndereco, Int32.Parse(sPorta));
this._user.EntrarGrupo(new string[] { "Udo" }); //entra no grupo
this._user.EnviarMsg(new string[] { "Udo" }, "Server:Servidor
connectado!"); // envia o arquivo para o grupo
this._user.Run();
}
public void Run()
{
rt = new recThread(connection);
rt.refUltimoClienteConectado = this.refUltimoClienteConectado; rt.refClientesConectados = this.refClientesConectados;
Thread rtt = new Thread(new ThreadStart(rt.run)); rtt.Start();
}
Inserção no Banco de Dados.
54
//string de conexão que informa dados do banco que irei acessar
//
string connectionString = @"Data Source=MICRO\SQLEXPRESS;Initial Catalog=master;Integrated Security=True";
//
// Query TSQL com comando será realizado no banco.
//
string query = "INSERT INTO LCCG_LOG (LCCG_CLIENT, LCCG_GROUP, LCCG_USER, LCCG_DESCRIPTION, LCCG_CREATED, LCCG_FILENAME) values (@client, @group, @user, @description, getdate(),@filename)";
SqlConnection conn = null;
try
{ //
//instância da conexão
//
conn = new SqlConnection(connectionString);
//
//verifica se conexão está fechada, se tiver abre.
//
if (conn.State == ConnectionState.Closed) { // //abre conexão // conn.Open(); } //
// Criação do objeto comando, que recebe a query que será utilizada na operação e a conexão com o banco.
//
SqlCommand cmd = new SqlCommand(query, conn);
//
// Adiciona parametros ao comando
//
cmd.Parameters.Add(new SqlParameter("client", newLog.Client)); cmd.Parameters.Add(new SqlParameter("group", newLog.Group)); cmd.Parameters.Add(new SqlParameter("user", newLog.User));
cmd.Parameters.Add(new SqlParameter("description", ewLog.Description)); cmd.Parameters.Add(new SqlParameter("filename", newLog.FileName)); //
// Executa comando
//
cmd.ExecuteNonQuery(); //
// Fecha conexão com o banco
//
conn.Close(); }
catch (Exception ex) {
55 MessageBox.Show(ex.Message); } finally { //
// Garante que a conexão será fechada mesmo que ocorra algum erro.
// Não existe problema em fechar uma conexão duas vezes.
// O problema esta em abrir uma conexão duas vezes.
// if (conn != null) { conn.Close(); } } }
Figura 27 Log adicionado ao banco de dados.
Lista de conexões ativas
Na lista de conexões estão todas as conexões ativas no grupo SPREAD
56
Abaixo código fonte da inserção e remoção das conexões ativas no SPREAD:
private void AdicionaClienteConectadoNaInterface(string pPc)
{
((ListBox)this.refClientesConectados).Items.Add(pPc); }
private void RemoveClienteConectadoNaInterface(string pPc)
{
((ListBox)this.refClientesConectados).Items.Remove(pPc);
