Um terceiro grupo de requisitos está relacionado à modelagem comportamental do sistema, ou seja, aos comportamentos de pares e mecanismos de falhas. Inicialmente estão previstos cinco tipos de comportamentos de nós, são eles: Honestos, Maliciosos, Corruptos, Perturbadores e Egoístas. Cada comportamento busca reproduzir algum dos tipos de ameaça à sistemas de reputação P2P, citados na Seção3.2.3e são baseados no modelo descrito [Schlosser, Voss e Brückner 2005]. A implementação de um modelo de ameaças a nível de comportamento de usuário é importante para veri car a resposta dos protocolos diante de diferentes tipos de ataque e comportamentos agressivos. A descrição dos comportamentos é feita a seguir:
Honestos Agentes honestos comportam-se de maneira adequada no sistema. Iniciam boas transações, fornecem recursos quando são solicitados e suas avaliações são sempre corretas, isto é, transações e pares e recursos bons são avaliados como bons, ou ruins caso contrário.
Maliciosos Agentes maliciosos realizam transações boas, ruins ou neutras (quando não há repasse de recurso, ou a avaliação é nula) sempre ao acaso, mas com maior probabilidade para as transações boas. Seu objetivo é minar o sistema sempre com avaliações incorretas.
Conspiradores. Estes agentes tentam acumular uma alta reputação formando um grupo (conluio) onde todos se reconhecem e se avaliam positivamente. Sempre que um nó conspirador encontra outro conspirador ele interagem corretamente (i.e. repassa recursos, encaminha mensagens, etc.) e dá sempre uma avaliação positiva. Quando, por outro lado, encontra algum outro tipo de agente ele se recusa a interagir (i.e. transação neutra) e fornece avaliações nulas.
Egoístas. Agentes egoístas buscam imitar o comportamento dos "free-riders"em redes P2P, fazendo requisições e downloads de arquivos, mas se recusando a colaborar de qualquer maneira. Nós egoístas não encaminham mensagens, não fornecem arquivos sobre o seu domínio e não avaliam transações.
Perturbadores. Este tipo de agente implementa características de nós traidores e whitewashers. Ele opera com comportamento honesto até que sua reputação atinja um nível alto. Uma vez com alta reputação e tendo atingido um número mínimo de inter- ações com outros nós, agente perturbador muda para o comportamento malicioso. Ele permanece neste estado até que sua reputação atinja um nível mínimo especi cado pelo usuário do simulador, então sai da rede e retorna com novo identi cador e reputação inicial.
Além destes comportamentos, o sistema deve prover um mecanismo de falhas baseado na entrada e saída inesperada de nós. Esta última característica visa imitar o compor- tamento dinâmico das máquinas e usuários em uma rede real. Em ambientes P2P reais, a entrada e saída de nós é feita de forma aleatória, dependendo do interesse do usuário ou de eventuais falhas de hardware e rede. Os nós normalmente não avisam quando in- gressarão ou se retirarão da rede, mesmo porque, muitas vezes, estas ações independem da intervenção de usuários, como no caso de falhas de energia. Alguns comportamentos maliciosos, inclusive, usam a técnica de saídas inesperadas para corromper o sistema ou ganhar nova reputação. Nós perturbadores, por exemplo, renovam sua reputação sempre que ela atinge um valor mínimo, apagando seu histórico de transações ruins sempre que assume uma nova chave de identi cação na rede.
novas implementações de comportamento de forma facilitada. Um usuário pode querer, por exemplo, testar seus próprios modelos de ataques e, para isso, a API deve ser simples e portável o su ciente para que ele possa escrever seu próprio código e acoplá- lo ao simulador.
6.
Arquitetura do PeerRepSim
A arquitetura de um sistema é a sua organização fundamental, representada por com- ponentes e princípios que guiam o seu desenvolvimento e evolução. A arquitetura com- preende também os relacionamentos dos componentes entre si e deles com o ambiente. Um modelo arquitetural, por outro lado, é o conjunto de artefatos que documentam a arquitetura de um sistema [Hilliard 2000].
A elaboração da arquitetura é uma etapa crucial para o desenvolvimento e para a evolução de um sistema de software . Seu principal benefício é oferecer uma "visão global"do sistema, auxiliando a compreensão dos seus elementos mais importantes. Além disso, uma arquitetura bem elaborada contribui para a documentação de decisões de alto impacto e o incentivo ao reuso de componentes. Uma visão abrangente das principais características de um sistema também auxilia a comunicação entre as pessoas envolvidas no projeto (stakeholders). Por m, a elaboração de um modelo arquitetural estimula a identi cação de erros logo nas primeiras fases de desenvolvimento, o que pode contribuir para a redução dos custos de desenvolvimento e evolução do sistema. Este capítulo trata dos principais aspectos arquiteturais do PeerRepSim. Ele apresenta, além de uma descrição geral da arquitetura do simulador, os modelos detalhados da estrutura e do comportamento dos principais elementos do sistema. A Seção 6.1 apre- senta a estrutura básica do PeerRepSim, descrevendo módulos fundamentais. A Seção
6.2 lista e descreve os principais termos e entidades da arquitetura, usados no restante do texto. Em seguida, a Seção 6.3 descreve os detalhes mais profundos da arquitetura do simulador, apresentando diagramas de classes e comportamentos. A con guração e o modelo de interface de usuário do sistema são explicados na Seção 6.4, enquanto a Seção 6.5 descreve o modelo de coleta de resultados do simulador.
6.1 Modelo Conceitual
O PeerRepSim possui uma arquitetura semelhante ao modelo 3-LS citado na Seção
4.2. Conceitualmente, o sistema também é divido em camadas básicas que se comuni- cam entre si, cada uma fornece serviços para as camadas adjacentes. A Figura 6.1(a)
apresenta um esboço da arquitetura geral do simulador, listando seus componentes bá- sicos. O modelo reúne cinco grandes componentes: interface de usuário, motor de simulação, ambiente de simulação, análise de dados e entrada e saída. Cada
um destes componentes encapsula atributos e responsabilidades especí cas, sendo que suas interfaces oferecem serviços aos componentes adjacentes. Uma descrição de cada componente é feita a seguir:
Interface de Usuário O módulo de Interface de Usuário reúne entidades responsá- veis pela coleta de parâmetros de simulação de nidos pelos usuários do simulador. Dois modos de con guração podem ser utilizados: através da interface grá ca de usuário, ou através de arquivos de propriedades. O primeiro modo oferece ao usuário a possibilidade de con guração e supervisão do experimento através de uma interface grá ca baseada em Swing [Sun 2010]. A interface disponibiliza for- mulários de con guração da simulação, grá cos dinâmicos com estatísticas sobre o experimento e também controles de início e de interrupção do experimento. O segundo modo é destinado a usuários que desejam realizar um grande número de simulações em lote, como, por exemplo, simulações em grid computacional. Motor de Simulação Uma vez recebidos os parâmetros de con guração do usuário,
o Motor de Simulação é responsável por criar as entidades necessárias para a simulação (e.g. rede, nós, protocolos, repositórios, etc.) e iniciar a execução. O conjunto destas entidades compõe um Ambiente de Simulação. O Motor pode executar um ou mais Ambientes de Simulação ao mesmo tempo, porém cada um gera seus próprios resultados.
É também o Motor de Simulação que coordena os passos da execução (ticks), além de realizar periodicamente limpezas de memória, esvaziamento de buers e chamadas para a organização de dados do experimento. Durante um passo de simulação, o Motor escolhe aleatoriamente um número n, determinado pelo usuário, de nós que realizarão ciclos de busca. Após a realização dos ciclos de busca, o componente aciona o módulo de Análise de Dados para que este realize a organização dos dados gerados até então. Por m, o Motor de Simulação exclui os objetos excedentes, como listas de mensagens e buers temporários com o intuito de liberar espaço em memória.
Os nós escolhidos para realização de ciclos de busca em um passo de simulação, são acionados em paralelo pelo Motor de Simulação. Os ciclos de busca são realizados de forma sincronizada e a sincronização entre as transações é também uma responsabilidade deste componente.
Ambiente de Simulação O Ambiente de Simulação, detalhado na Figura 6.1(b), reúne as entidades básicas do simulador. É compostos por três camadas fun- damentais e um subsistema de coleta de dados. As camadas do Ambiente de Simulação assemelham-se ao modelo 3-LS, porém com características internas diferentes. São elas: camada Rede, responsável pelo encaminhamento de men- sagens entre os pares. A camada Protocolo, cuja entidade principal é o Peer,
que representa um nó da rede. Esta camada também inclui as implementações de protocolos e mensagens, além de estruturas de rede e reputação. Por m, a camada Usuário, que contém as implementações de modelos de comportamentos de usuários, necessárias nas tomadas de decisões dos protocolos.
O subsistema de coleta de dados é distribuído pelas três camadas básicas e é responsável pela coleta de estatísticas de simulação, como a contagem de mensa- gens na rede e o cálculo de reputações globais. O subsistema de coleta de dados comunica-se com módulo de Análise de Dados.
Análise de Dados O módulo de Análise de Dados é responsável pela organização e classi cação dos dados coletados, bem como pela elaboração de grá cos e conjun- tos de saída. Os grá cos gerados por este módulo são armazenados em arquivo através da interface oferecida pelo componente de entrada e saída.
A classi cação dos dados depende da natureza das amostras coletadas. Amostras de mensagens, por exemplo, podem ser agrupadas por tipo, ou por comporta- mento do remetente/destinatário. Médias globais de reputação são agrupadas por grupos de comportamento, enquanto transações são classi cadas como bem ou mal sucedidas.
Uma vez organizados, os dados podem ser exportados em grá cos e/ou arquivos separados por vírgula, para análises posteriores em outras ferramentas. A adição de um novo tipo de grá co para a análise envolve a implementação de interfaces de nidas neste componente, assim como a implementação de rotinas no subsis- tema de coleta de dados. O Motor de Simulação é programado para exportar cada um dos grá cos de nidos no módulo de Análise de Dados, não sendo necessária alterações fora do componente caso um novo modelo seja adicionado.
Entrada e Saída Este componente contém classes que auxiliam a leitura e escrita de arquivos separados por vírgula para entrada e saída de dados. Também fornecem interfaces para a leitura de arquivos de propriedades e conjuntos de comporta- mentos de nós.