( PDF ) Definição de uma arquitetura P2P baseada em reputação e orientada a serviços

Download PDF

ads:

Universidade Federal do Maranh˜ao

Centro de Ciˆencias Exatas e Tecnologia

Programa de P´os-Gradua¸c˜ao em Engenharia de Eletricidade

DEFINIC¸

AO DE UMA ARQUITETURA P2P

BASEADA EM REPUTAC¸

AO E

ORIENTADA A SERVIC¸OS

Fl´avio Marc´ılio Paiva Ramos

S˜ao Lu´ıs

2009

ads:

Livros Grátis

http://www.livrosgratis.com.br

Milhares de livros grátis para download.

Universidade Federal do Maranh˜ao

Centro de Ciˆencias Exatas e Tecnologia

Programa de P´os-Gradua¸c˜ao em Engenharia de Eletricidade

DEFINIC¸

AO DE UMA ARQUITETURA P2P

BASEADA EM REPUTAC¸

AO E

ORIENTADA A SERVIC¸OS

Fl´avio Marc´ılio Paiva Ramos

Disserta¸c˜ao apresentada ao Programa de P´os-Gradua¸c˜ao

em Engenharia de Eletricidade da Universidade Federal do

Maranh˜ao, como parte dos requisitos necess´arios para

obten¸c˜ao do grau de Mestre em Engenharia de Eletricidade.

S˜ao Lu´ıs

2009

ads:

Ramos, Fl´avio Marc´ılio Paiva

Deﬁni¸c˜ao de uma Arquitetur a P2P Baseada em Reputa¸c˜ao e Orien-

tada a Servi¸cos / Fl´avio Marc´ılio Paiva Ramos. - S˜ao Lu´ıs, 2009.

144f.:il.

Disserta¸c˜ao (Mestrado em Engenharia de Eletricidade) - Centro de

Ciˆencias Exatas e Tecnologia, Universidade Federal do Maranh˜ao,

2009.

1. Redes Peer-to-Peer. 2. Computa¸c˜ao Orientada a Servi¸cos. 3.

Protocolos. 4. Reputa¸c˜ao. I.T´ıtulo.

CDU 004.722.2

“Quando uma porta se fecha outra se abre;

mas n´os quase sempre olhamos tanto e de

maneira t˜ao arrependida para a que se fechou,

que n˜ao vemos aquelas que foram abertas para n´os”.

Alexander Graham Bell

A minha esposa e ﬁlhos.

A minha m˜ae, meu pai e minha irm˜a.

Agradecimentos

A Deus pelo milagre da vida.

A minha m˜ae Zulmira por seu amor e sacrif´ıcios para proporcionar-me,

atrav´es da educa¸c˜ao, a b usca do conhecimento.

A meu pai Antˆonio pelos seus exemplos de supera¸c˜ao.

A minha esposa Gabryela pelo seu amor e apoio incondicional em todas as

horas.

Aos meus ﬁlhos Jo˜ao Gabriel e Pedro Fl´avio que aceitaram meus momentos

de ausˆencia.

A minha irm˜a Cl´audia e minha sobrinha Lisa, que apesar da distˆancia, sem-

pre estiveram torcendo por mim.

A meus sogros Gilmar e Concei¸c˜ao pelo reconhecimento do meu esfor¸co.

A minha v´o Rosa (in memoriam) que deve estar muito feliz onde quer que

ela esteja.

Ao meu orientador, professor Zair Abdelouhab por acreditar na minha ca-

pacidade e por seus valiosos ensinamentos.

Ao meu co-orientador, professor M´ario Meireles, por suas importantes opini˜oes,

cr´ıticas e pelas horas em que esteve dispon´ıvel para guiar-me neste trabalho.

Ao Coordenador do Programa de P´os-Gradua¸c˜ao de Engenharia de Eletrici-

dade, Sebastian Yuri Catunda, pela oportunidade.

Aos professores Miguel Franklin e Omar Cortes por aceitarem participar

desta banca.

A professora Maria da Guia pelos conselhos dados para maior empenho na

conclus˜ao deste mestrado.

Aos professores Anselmo, Auxiliadora, Alexandre, Arist´ofanes, Carlos Sales,

Francisco Silva e Ivo; Rosa, Lucinete (“Baixinha”) e todos que comp˜oem o Depar-

tamento de Inform´atica da UFMA, com os quais tive oportunidade de trabalhar na

´area docente, como professor substituto.

A todos os colegas de mestrado, Aline, Helaine, Johneth, Falkner e Gilberto,

pela amizade, for¸ca, incentivo e uni˜ao durante todo o tempo que passamos juntos,

al´em dos momentos de confraterniza¸c˜ao que realizamos.

A todos os colegas do LAWS (Laboratory of Advanced Web Systems) pela

contribui¸c˜ao para este trabalho.

A Alcides por sua aten¸c˜ao dispensada a todos os alunos do programa de

mestrado.

Aos colegas de trabalho (TRT - 16

Regi˜ao) pelo incentivo e apoio para que

esta meta fosse atingida.

E a todos que direta e ind iretamente contribu´ıram nesta importante jornada.

Resumo

As redes peer-to-peer (P2P) s˜ao muito populares atualmente, principalmente

quando se deseja buscar ou compartilhar uma grande quantidade de informa¸c˜oes e

recursos entre os seus participantes. Uma das grandes diﬁculdades desse tipo de tec-

nologia ´e evitar que esses participantes mantenham, ao mesmo temp o, um n´umero

consider´avel de arquivos compartilhados, e ainda garantir que esses arquivos n˜ao se-

jam conte´udo polu´ıdo ou corrompido. Outro problema bem comum nas redes P2P,

´e a falta de interoperabilidade entre as diversas redes existentes, principalmente de-

vido `as incompatibilidades dos metadados e das interfaces das opera¸c˜oes utilizadas

na comunica¸c˜ao entre os n´os. Este trabalho descreve o P2PWSRep, um protocolo

de gerenciamento de reputa¸c˜ao para identiﬁcar n´os que n˜ao desejam cooperar ou

que podem prejudicar o desempenho da rede pelo compartilhamento de arquivos

corrompidos, infectados ou inexistentes. A infraestrutura da rede do P2PWSRep

foi baseada em servi¸cos web para contornar problemas de interoperabilidade e fa-

cilitar sua extensibilidade, tornand o-o f´acil de ser utilizado por diversas aplica¸c˜oes

de redes P2P. O protocolo P2PWSRep possui um c´alculo de reputa¸c˜ao distribu´ıdo,

utilizando-se uma m´edia ponderada exponencial, que considera o valor da reputa¸c˜ao

anterior do n´o e o valor atual, obtido dos demais n´os da rede, e regulado por um

parˆametro de ajuste, para obter a reputa¸c˜ao ﬁnal, de forma que o hist´orico do com-

portamento do n´o seja considerado. O protocolo P2PWSRep ´e validado por meio

de simula¸c˜ao e os resultados obtidos mostram que o mesmo ´e capaz de apontar os

n´os ou recursos mais conﬁ´aveis da rede, ao mesmo tempo em que isola aqueles n´os

que n˜ao s˜ao ´ıntegros ou pouco cooperativos, al´em de n˜ao impor uma sobrecarga

desnecess´aria `a rede P2PWS.

Palavras-Chave: Redes Peer-to-peer. Servi¸cos Web. Proto colos. Reputa¸c˜ao.

Abstract

Nowadays, peer-to-peer networks are very popular mainly, when we wish to search

or share a considerable amount of information and resources among various partici-

pants. One of the main diﬃculties of this technology is how to avoid that those par-

ticipants maintain, at the same time, a considerable number of shared resources and

to guarantee that those resources are not corrupted or polluted content. Another

problem commonly found in P2P networks is the lack of interoperability among

existing P2P solutions especially because the inconsistencies of metadata and ope-

ration interfaces used in node communication. This work describes P2PWSRep, a

reputation management protocol that identiﬁes non-cooperative nodes or that can

hinder network performance by sharing corrupted, infected or non-existent ﬁles.

P2PWSRep infrastructure was based on web services in order to tackle interopera-

bility problems and to facilitate its extensibility, making it feasible to be accessed

by several other P2P applications. The P2PWSRep protocol employs a distributed

reputation computation using an exponentially weighted average that takes into

account the current and previous node reputation and which is tuned by an adjust-

ment parameter in order to obtain the ﬁnal reputation, thus considering the node’s

behavior. The P2PWSRep protocol is validated by means of simulation and our

results show that it is able to point out the more trustable nodes in the network as

well as to insulate those which are not reliable or cooperative. Besides, the protocol

does not unnecessarily impacts on the network load P2PWS.

Keywords: Peer-to-peer Networks. Web Services. Protocols. Reputation.

Lista de Figuras

1.1 Cen´ario da Internet na d´ecada de 80. (Computer Museum History) 12

2.1 Arquitetura SOA. (W3C, 2008) . . . . . . . . . . . . . . . . . . . . 21

2.2 Linguagem XML como base de servi¸cos web. (W3C, 2008) . . . . . 23

2.3 Estrutura da mensagem SOAP. (W3C, 2008) . . . . . . . . . . . . . 27

2.4 Estrutura do documento WSDL. (W3C, 2008) . . . . . . . . . . . . 31

3.1 Exemplo de uma rede P2P. . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Tr´afego das redes P2P entre 1993 e 2006. (CacheLogic Reseach, 2006) 37

3.3 Rede overlay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.4 Rede P2P descentralizada versus centralizada. (Addison, 2002) . . 42

3.5 Arquiteturas de redes P2P: (a) Centralizada com busca centraliza-

da; (b) Descentralizada com busca desestruturada; (c) H´ıbrida com

busca descentralizada estruturada (Barcellos and Gaspary, 2006). . 43

3.6 Travessia de ﬁrewall com HTTP Tunneling. . . . . . . . . . . . . . 49

3.7 Rede Gnutella. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.8 Arquitetura do Napster (Addison, 2002). . . . . . . . . . . . . . . . 55

4.1 Reputa¸c˜ao de um vendedor do site Mercado Livre. . . . . . . . . . . 58

4.2 Mecanismo de c´alculo de reputa¸c˜ao do eBay. . . . . . . . . . . . . . 59

4.3 Fases do protocolo XREP. . . . . . . . . . . . . . . . . . . . . . . . 70

5.1 Caso de uso de ingresso na rede . . . . . . . . . . . . . . . . . . . . 77

5.2 Caso de uso de busca de recursos . . . . . . . . . . . . . . . . . . . 78

5.3 Roteamento das mensagens na rede P2PWS. . . . . . . . . . . . . . 79

5.4 Obten¸c˜ao da reputa¸c˜ao de um n´o da rede. . . . . . . . . . . . . . . 80

5.5 Download realizado diretamente do n´o escolhido . . . . . . . . . . . 81

5.6 Caso de uso de gerenciamento de reputa¸c˜ao . . . . . . . . . . . . . 81

5.7 Inﬂuˆencia do parˆametro alfa no c´alculo da reputa¸c˜ao . . . . . . . . 89

5.8 Diagrama de sequˆencia do protocolo P2PWSRep . . . . . . . . . . . 95

6.1 Exemplo da topologia da rede P2PWS. . . . . . . . . . . . . . . . . 99

6.2 Gr´aﬁco de varia¸c˜ao da reputa¸c˜ao. . . . . . . . . . . . . . . . . . . . 110

6.3 Gr´aﬁco de varia¸c˜ao da reputa¸c˜ao de um n´o da rede. . . . . . . . . . 113

6.4 Gr´aﬁco do n´umero de requisi¸c˜oes de arquivos corrompidos. . . . . . 115

6.5 Gr´aﬁco do tr´afego de mensagens versus alcance de busca. . . . . . . 117

6.6 Gr´aﬁco do n´umero de respostas de reputa¸c˜ao versus temp o. . . . . . 118

Lista de Tabelas

5.1 Tabela de n´os. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.2 Tabela de reputa¸c˜ao dos n´os. . . . . . . . . . . . . . . . . . . . . . . 83

5.3 Tabela de conﬁgura¸c˜ao do n´o. . . . . . . . . . . . . . . . . . . . . . 83

5.4 Tabela de recursos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.5 Tabela de reputa¸c˜ao de recursos. . . . . . . . . . . . . . . . . . . . 85

5.6 Opera¸c˜oes do protocolo P2PWSRep . . . . . . . . . . . . . . . . . . 92

Lista de Listagens

2.1 Exemplo de mensagem SOAP . . . . . . . . . . . . . . . . . . . . . 28

6.1 Trecho da classe P2PWSRepNode . . . . . . . . . . . . . . . . . . . 99

6.2 Classe SMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

6.3 Classe GnutellaProtocol . . . . . . . . . . . . . . . . . . . . . . . . 105

A.1 Arquivo de conﬁgura¸c˜ao da simula¸c˜ao . . . . . . . . . . . . . . . . . 131

A.2 Log de sa´ıda da simula¸c˜ao da rede P2PWS . . . . . . . . . . . . . . 132

Lista de Abreviaturas

ATC Approximate Trust Computation

ATM Asynchronous Transfer Mode

BFS Breath First Search

DDoS Distributed Denial of Service

DHT Distributed Hash Table

DTD Document Type Deﬁnitions

DTM Dynamic Trust Computation

FTP File Transfer Protocol

GPL General Public License

HTTP Hypertext Transfer Protocol

IP Internet Protocolo

IPS Intrusion Prevent System

IRTF Internet Research Task Force

LAN Local Area Network

MPLS Multiprotocol Label Switching

NAT Network Address Translation

OASIS Organization for the Advancement of Structured

Information Standards

P2P Peer-to-peer

P2PWSRep Peer-to-peer Web Service Reputation Protocol

RPC Remote Procedure Call

SGML Standard Gen eralized Markup L anguage

SHA Secure Hash Algorithm

SMS Short Message Service

SMTP Simple Mail Transfer Protocol

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

TTL Time to Live

UDDI Universal Description, Discovery and Integration

URI Uniform Resource Identiﬁers

URL Universal Resource Locators

W3C World Wide Web Consortium

WSDL Web Services Deﬁnition Language

WWW World Wide Web

XML Extensible Markup Language

Sum´ario

1 Introdu¸c˜ao 11

1.1 Motiva¸c˜ao e Justiﬁcativa . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3 Objetivos Espec´ıﬁcos . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.4 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.5 Estrutura da Disserta¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . 17

2 Servi¸cos Web 18

2.1 Introdu¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Servi¸co . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Arquitetura Orientada a Servi¸cos . . . . . . . . . . . . . . . . . . . 20

2.4 Linguagem XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.1 Document Type Deﬁnitions (DTD) . . . . . . . . . . . . . . 24

2.4.2 XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5 Simple Object Access Protocol (SOAP) . . . . . . . . . . . . . . . . 25

2.5.1 Mensagem SOAP . . . . . . . . . . . . . . . . . . . . . . . . 26

2.5.2 Modelo de Processamento SOAP . . . . . . . . . . . . . . . 28

2.5.3 SOAP sobre Protocolos de Transporte . . . . . . . . . . . . 29

2.6 Web Services Description Language (WSDL) . . . . . . . . . . . . . 30

2.6.1 Estrutura do Do cumento WSDL . . . . . . . . . . . . . . . . 31

2.7 Universal Description, Discovery and Integration (UDDI) . . . . . . 32

2.7.1 Registro UDDI . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.8 Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Redes P2P 35

3.1 Introdu¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2 Evolu¸c˜ao das Redes P2P . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3 Caracter´ısticas das Redes P2P . . . . . . . . . . . . . . . . . . . . . 37

3.4 Aplica¸c˜oes P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4.1 Compartilhamento de Arquivos . . . . . . . . . . . . . . . . 38

3.4.2 Computa¸c˜ao Distribu´ıda . . . . . . . . . . . . . . . . . . . . 39

3.4.3 Troca de Mensagens . . . . . . . . . . . . . . . . . . . . . . 39

3.4.4 Transmiss˜ao de Dados . . . . . . . . . . . . . . . . . . . . . 40

3.5 Redes P2P versus Redes Overlay . . . . . . . . . . . . . . . . . . . 40

3.6 Arquitetura das Redes P2P . . . . . . . . . . . . . . . . . . . . . . 40

3.6.1 Redes P2P Centralizadas . . . . . . . . . . . . . . . . . . . . 41

3.6.2 Redes P2P Descentralizadas . . . . . . . . . . . . . . . . . . 44

3.6.3 Redes P2P com Supern´os . . . . . . . . . . . . . . . . . . . 45

3.7 Tipos de Busca em Redes P2P . . . . . . . . . . . . . . . . . . . . . 46

3.7.1 Busca Centralizada . . . . . . . . . . . . . . . . . . . . . . . 46

3.7.2 Busca Descentralizada Desestruturada . . . . . . . . . . . . 47

3.7.3 Busca Descentralizada Estruturada . . . . . . . . . . . . . . 47

3.8 Firewalls versus Redes P2P . . . . . . . . . . . . . . . . . . . . . 48

3.9 Seguran¸ca em Redes P2P com Reputa¸c˜ao . . . . . . . . . . . . . . . 49

3.10 Solu¸c˜oes de Redes P2P . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.10.1 Gnutella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.10.2 Napster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.11 Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4 Reputa¸c˜ao em Redes P2P 57

4.1 Introdu¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2 Tipos de Reputa¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2.1 Reputa¸c˜ao de N´os . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2.2 Reputa¸c˜ao de Recursos . . . . . . . . . . . . . . . . . . . . . 61

4.3 Sistemas Baseados em Com´ercio e Reputa¸c˜ao . . . . . . . . . . . . 63

4.3.1 PPay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.3.2 Sistemas de Escambo . . . . . . . . . . . . . . . . . . . . . . 64

4.3.3 EigenTrust . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.3.4 XRep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.3.5 PeerTrust . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.4 Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5 Protocolo de Reputa¸c˜ao P2PWSRep 73

5.1 Introdu¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2 Descri¸c˜ao da Arquitetura P2PWSRep . . . . . . . . . . . . . . . . . 76

5.2.1 Modelagem dos Casos de Uso . . . . . . . . . . . . . . . . . 76

5.3 Metadados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.3.1 Metadados de N´os . . . . . . . . . . . . . . . . . . . . . . . 82

5.3.2 Metadados de Recursos . . . . . . . . . . . . . . . . . . . . . 84

5.4 O Protocolo P2PWSRep . . . . . . . . . . . . . . . . . . . . . . . . 84

5.5 Descri¸c˜ao das Interfaces dos Servi¸cos do Protocolo P2PWSRep . . . 91

5.6 Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6 Simula¸c˜ao do Protocolo P2PWSRep 97

6.1 Introdu¸c˜ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.2 Descri¸c˜ao do Ambiente de Simula¸c˜ao . . . . . . . . . . . . . . . . . 98

6.3 Cen´ario 1 - An´alise do Protocolo de Reputa¸c˜ao dos N´os . . . . . . . 108

6.3.1 Descri¸c˜ao do Cen´ario . . . . . . . . . . . . . . . . . . . . . . 109

6.3.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6.3.3 An´alise dos Resultados . . . . . . . . . . . . . . . . . . . . . 112

6.4 Cen´ario 2 - An´alise do Protocolo de Reputa¸c˜ao dos Recursos . . . . 113

6.4.1 Descri¸c˜ao do Cen´ario . . . . . . . . . . . . . . . . . . . . . . 114

6.4.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

6.4.3 An´alise dos Resultados . . . . . . . . . . . . . . . . . . . . . 115

6.5 Cen´ario 3 - An´alise do Protocolo quanto `a Carga na Rede . . . . . . 116

6.5.1 Descri¸c˜ao do Cen´ario . . . . . . . . . . . . . . . . . . . . . . 116

6.5.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

6.5.3 An´alise dos Resultados . . . . . . . . . . . . . . . . . . . . . 118

6.6 Considera¸c˜oes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . 119

7 Conclus˜ao 121

7.1 Contribui¸c˜oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

7.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

A 131

A.1 Anexo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

A.2 Anexo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Cap

ıtulo 1

Introdu¸c˜ao

A Internet ´e o resultado do desenvolvimento de uma ﬁlosoﬁa de interliga¸c˜ao

de redes de computadores, cuja caracter´ıstica mais relevante ´e a total transparˆencia

aos usu´arios dos detalhes relativos `as tecnologias e a forma como a interliga¸c˜ao

e comunica¸c˜ao ´e feita (Chiozzotto and Mauro, 1999). No ﬁnal da d´ecada de 90,

milh˜oes de usu´arios j´a utilizavam a rede mundial de computadores, sendo que, no

princ´ıpio, o modelo de intera¸c˜ao era atrav´es de uma divis˜ao hier´arquica clara, onde

os servi¸cos ﬁcavam dispon´ıveis em m´aquinas chamadas de servidores e os clientes,

para acess´a-los, ut ilizavam conex˜oes ainda bem lentas e de baixa qualidade. Esse

modelo, bem conhecido e utilizado at´e hoje, ´e chamado de Modelo Cliente/Servi-

dor.

E um modelo hier´arquico, sendo que h´a claramente a divis˜ao de pap´eis entre

os elementos da rede, onde quem fornece o servi¸co ´e o elemento servidor e quem

consome o servi¸co ´e o elemento cliente. Com o crescimento acelerado da Internet,

logo surgiram preocupa¸c˜oes a respeito de sua infraestrutura, j´a que os mais pes-

simistas apostavam no seu colapso, aﬁrmando que esta n˜ao suportaria a demanda

de milhares de computadores que ingressavam na rede por dia, enquanto outros

n˜ao concordavam com as restri¸c˜oes de provedores para armazenamento ou troca de

arquivos e estavam em busca de alguma tecnologia que possibilitasse uma intera¸c˜ao

ad-hoc, sem dependˆencia de uma entidade ou elemento de rede centralizado. A

Figura 1.1 mostra o cen´ario, ainda na d´ecada de 80, da Internet. Percebe-se que

j´a havia uma cobertura bem grande no territ´orio americano e conex˜oes com outros

CAP

ITULO 1. INTRODUC¸

AO 12

continentes.

Figura 1.1: Cen´ario da Internet na d´ecada de 80. (Computer Museum History)

Na d´ecada de 90, os usu´arios da Internet j´a contavam com m´aquinas que

possu´ıam recursos que h´a uma d´ecada eram inexistentes e a um custo relativa-

mente baixo, assim estavam em busca de se livrar das restri¸c˜oes dos provedores,

como mencionado anteriormente. Foi ent˜ao que um novo modelo de troca de in-

forma¸c˜oes surgiu na Internet: as redes de conex˜ao ponto-a-ponto (pee-to-peer). As

redes P2P distinguiam-se do modelo Cliente/Servidor por utilizar uma comunica¸c˜ao

n˜ao hier´arquica, onde as partes que constituem o grupo podem se comunicar livre-

mente umas com as outras, numa comunica¸c˜ao ad-hoc, compartilhando seus recur-

sos e utilizando os dos demais, isto ´e, n˜ao h´a rotula¸c˜ao de pap´eis do tipo cliente ou

servidor dentro da rede. Nessas redes, os integrantes s˜ao chamados de n´os (peers) e

interagem diretamente, sem necessidade de um elemento para intermediar a comu-

nica¸c˜ao, da´ı a denomina¸c˜ao dessa rede de peer-to-peer.

As redes P2P alcan¸caram seu auge por volta do ano 2000, com um servi¸co

chamado de Napster (Napster, 2008), que no seu melhor momento, teve mais de 50

CAP

ITULO 1. INTRODUC¸

AO 13

milh˜oes de usu´arios trocando arquivos de m´usicas, o que representou a maior vio-

la¸c˜ao de direitos autorais em toda a hist´oria da ind´ustria fonogr´aﬁca. As empresas

fonogr´aﬁcas ent˜ao se reuniram e come¸caram uma batalha judicial para por ﬁm ao

Napster, e ﬁnalmente conseguiram. Mas, logo ap´os a interrup¸c˜ao do funcionamento

do Napster, surgiram outras redes P2P, n˜ao necessariamente para compartilhar

m´usicas, mas qualquer tipo de arquivo, sendo que as novas redes criadas surgi-

ram com a preocupa¸c˜ao de preservar o anonimato de cada integrante e garantir a

descentraliza¸c˜ao das informa¸c˜oes e r ecursos compartilhados na rede. Atualmente,

al´em de compartilhamento de arquivos e recursos, as redes P2P est˜ao presentes

nas mais diversas ´areas, tais como, jogos on-line, comunica¸c˜ao instantˆanea, sites de

relacionamento, telefonia sobre Internet, etc.

1.1 Motiva¸c˜ao e Justiﬁcativa

As redes P2P s˜ao o meio mais utilizado atualmente quando se deseja compar-

tilhar uma grande quantidade de informa¸c˜oes e recursos, j´a que ´e dif´ıcil concentrar o

mesmo volume de dados em poucos servidores de arquivos. A principal diﬁculdade ´e

preservar o desempenho da rede, sem a utiliza¸c˜ao de um elemento que centralize as

informa¸c˜oes a respeito dos n´os que integram a rede ou a qualidade e conﬁabilidade

do que ´e compartilhado entre mesmos. A inser¸c˜ao de elementos moderadores, sejam

eles autˆonomos ou controlados, facilita o gerenciamento da rede, mas tamb´em in-

troduz outros problemas, tais como conﬁabilidade, desempenho e seguran¸ca, j´a que

este elemento representa um ponto de falha e sua capacidade depende diretamente

do n´umero de n´os que o utilizam, tornando-se um alvo f´acil a ataques direcionados.

A designa¸c˜ao de um n´o da rede para executar opera¸c˜oes de gerenciamento (supern´o)

tamb´em induz o usu´ario a retirar-se da rede ou alterar o protocolo a ﬁm de evitar

ter qualquer sobrecarga em sua m´aquina.

A baixa interoperabilidade entre as diversas redes existentes tamb´em afeta

as redes P2P, principalmente devido `as incompatibilidades dos metadados e das

interfaces das opera¸c˜oes utilizadas na comunica¸c˜ao entre os n´os. Os usu´arios, `as

CAP

ITULO 1. INTRODUC¸

AO 14

vezes, tˆem em suas m´aquinas v´arios clientes de rede P2P, o que muitas vezes os

for¸cam a ter v´arias c´opias do mesmo arquivo armazenado em seu disco, devido a

conﬁgura¸c˜oes exigidas para cada rede. Este problema de interoperabilidade pode ser

resolvido colocando-se entre as redes elementos chamados de gateways, que fazem

interconex˜ao entre redes P2P diferentes. Mas ´e bom lembrar que esses elementos

podem impor limita¸c˜oes de desempenho e escalabilidade.

Como mencionado anteriormente, as redes P2P visam o compartilhamento

e troca de arquivos entre seus integrantes. Nesta curta deﬁni¸c˜ao do seu objetivo,

identiﬁcam-se dois elementos cruciais, o primeiro deles, s˜ao os arquivos (ou recursos,

como s˜ao chamados nas redes P2P), principal alvo ou meio de ataque `a rede e

aos seus integrantes. O segundo s˜ao os usu´arios, que podem agir de duas formas,

sendo uma menos prejudicial em termos de seguran¸ca, mas que afeta diretamente

desempenho da rede, j´a que eles n˜ao costumam compartilhar os dados que obtˆem

dos demais; e outra mais prejudicial, onde os mesmos utilizam a rede para distribuir

arquivos contaminados por v´ırus e outros c´odigos maliciosos, disponibilizar arquivos

corrompidos e espalhar na rede informa¸c˜oes inconsistentes.

A justiﬁcativa para realiza¸c˜ao deste trabalho ´e propor um protocolo de re-

puta¸c˜ao que seja aplicado a qualquer rede P2P e que possa, de forma eﬁciente,

identiﬁcar os usu´arios que tentam prejudicar o desempenho e conte´udo das mesmas.

Al´em disso, apresentar a deﬁni¸c˜ao da infraestrutura orientada a servi¸cos de uma

rede P2P para proporcionar interoperabilidade, em n´ıvel de opera¸c˜oes e de recursos

disponibilizados, incluindo o protocolo de reputa¸c˜ao.

1.2 Objetivo Geral

Apesar de muitos pensarem que as redes P2P j´a esgotaram seus temas

de pesquisa, ainda h´a in ´umeros pr oblemas a serem solucionados. Este trabalho

trata da identiﬁca¸c˜ao de n´os mal intencionados e a interoperabilidade entre redes

P2P, atrav´es da utiliza¸c˜ao de um protocolo de gerenciamento de reputa¸c˜ao para

identiﬁcar quais os melhores e piores n´os da rede, n˜ao necessariamente por m´etricas

CAP

ITULO 1. INTRODUC¸

AO 15

j´a consideradas ineﬁcazes, tais como, largura de banda, tempo de conex˜ao do n´o,

n´umero de recursos, volume de dados armazenados, etc., pois essas m´etricas s˜ao

caracter´ısticas obtidas diretamente do n´o, sem nenhuma participa¸c˜ao dos demais.

O gerenciamento de reputa¸c˜ao atrav´es do protocolo P2PWSRep pretende diminuir

o n´umero de n´os que possam comprometer o desempenho da rede, bem como, o

conte´udo corrompido. A interoperabilidade ´e tratada atrav´es da deﬁni¸c˜ao de uma

arquitetura orientada a servi¸cos, que est´a presente na infraestrutura b´asica da rede

e em opera¸c˜oes como ingresso n a rede, busca de recursos, anota¸c˜ao dos dados,

gerenciamento de reputa¸c˜ao e transferˆencia de arquivos.

1.3 Objetivos Espec´ıﬁcos

Este trabalho tem dois objetivos bem deﬁnidos. Decerto, ´e sabido que o

gerenciamento de repu ta¸c˜ao traz a grande contribui¸c˜ao para as tecnologias de redes

P2P, mas a busca de uma interoperabilidade perfeita tamb´em ´e muito importante.

Para atingir os dois objetivos gerais deste trabalho, alguns objetivos espec´ıﬁcos

tiveram que ser atingidos:

• Estudo da viabilidade de utiliza¸c˜ao de tecnologias de servi¸cos web na cons-

tru¸c˜ao de infraestruturas P 2P, para possibilitar as intera¸c˜oes entre os compo-

nentes da rede;

• Deﬁni¸c˜ao das interfaces servidor e cliente de cada n´o, incluindo a deﬁni¸c˜ao

dos dados contidos nas intera¸c˜oes entre os servi¸cos;

• Deﬁni¸c˜ao de reposit´orios de metadados para anota¸c˜ao dos n´os, recursos e

outras informa¸c˜oes armazenadas nos mesmos;

• Deﬁni¸c˜ao dos mecanismos de busca de n´os e recursos na rede;

• Estudo de algoritmos de reputa¸c˜ao aplicados em redes P2P;

• Deﬁni¸c˜ao de um protocolo de reputa¸c˜ao apto a tratar os problemas de polui¸c˜ao

e interoperabilidade na rede;

CAP

ITULO 1. INTRODUC¸

AO 16

• Estudo comparativo do protocolo proposto com outros protocolos existentes;

• Simula¸c˜ao e valida¸c˜ao do protocolo de reputa¸c˜ao.

1.4 Metodologia

Este trabalho foi realizado em trˆes etapas, baseadas nos procedimentos me-

todol´ogicos que orientam a realiza¸c˜ao de uma p esquisa cient´ıﬁca. A primeira etapa

consistiu no levantamento bibliogr´aﬁco, atrav´es da leitura artigos, disserta¸c˜oes,

livros e sites da web, a ﬁm de obter conhecimento das ´areas que foram estudadas

durante a pesquisa. As seguintes ´areas foram destacadas como importantes para o

trabalho:

• Arquiteturas Orientadas a Servi¸cos;

• Servi¸cos Web;

• Redes Peer-to-Peer;

• Reputa¸c˜ao;

• Ferramentas de Simula¸c˜ao de Redes.

A segunda etapa do trabalho consistiu na deﬁni¸c˜ao do protocolo de repu-

ta¸c˜ao P2PWSRep, com uma infraestrutura orientada a servi¸cos, para identiﬁcar a

reputa¸c˜ao de n´os e recursos na rede P2P, baseando-se em informa¸c˜oes fornecidas

pelos demais n´os da rede e utilizando-se de valores anteriores da reputa¸c˜ao dos n´os

procurados. Nesta etapa, foram realizados estudos dos protocolos de reputa¸c˜ao bem

aceitos pela comunidade cient´ıﬁca. A terceira etapa abordou a valida¸c˜ao d o proto-

colo atrav´es de um modelo de simula¸c˜ao, onde foram estudadas v´arias ferramentas

de simula¸c˜ao, de tal forma que se pudesse utilizar uma que fosse mais adequada ao

prop´osito do trabalho. A ´ultima etapa concentrou-se em deﬁnir uma rede orientada

a servi¸cos utilizando o protocolo de reputa¸c˜ao P2PWSRep, deﬁnindo as interfaces

dos servi¸cos, m´etodos, estruturas de dados para armazenamento e manipula¸c˜ao dos

dados e outros detalhes da arquitetura.

CAP

ITULO 1. INTRODUC¸

AO 17

1.5 Estrutura da Disserta¸c˜ao

Esta disserta¸c˜ao esta organizada em 7 cap´ıtulos. O Cap´ıtulo 1 traz uma

vis˜ao geral do trabalho e est´a dividido em contextualiza¸c˜ao, motiva¸c˜ao, objetivos,

justiﬁcativa e metodologia. O Cap´ıtulo 2 apresenta os conceitos relacionados com

servi¸cos web, apresentando o embasamento te´orico importante para o entendimento

deste trabalho, onde s˜ao descritos, a arquitetura orientada a servi¸cos e seus compo-

nentes b´asicos. O Cap´ıtulo 3 traz os conceitos referentes `as redes P2P, aplica¸c˜oes

de redes P2P, suas arquiteturas, t ipos de busca, seguran¸ca e exemplos de redes

P2P, sendo apresentados neste trabalho, o Gnutella e Napster. No Cap´ıtulo 4 s˜ao

apresentados os conceitos de reputa¸c˜ao e apresentados trabalhos relacionados, abor-

dando vantagens e problemas encontrados em cada um deles. O Cap´ıtulo 5 apre-

senta o protocolo de reputa¸c˜ao P2PWSRep, resultado deste trabalho de mestrado,

onde ´e descrita a sua arquitetura e algoritmo. O Cap´ıtulo 6 descreve a valida¸c˜ao

do protocolo P2PWSRep por simula¸c˜ao, onde ´e apresentado cada experimento e

an´alise dos resultados obtidos. O Cap´ıtulo 7 apresenta as conclus˜oes do presente

estudo e trabalhos futuros que podem ser desenvolvidos a partir do mesmo.

Cap

ıtulo 2

Servi¸cos Web

Neste cap´ıtulo s˜ao apresentados os conceitos da Arquitetura Orientada a

Servi¸cos (SOA) e do elemento essencial dessa arquitetura, o servi¸co. Al´em de apre-

sentar uma vis˜ao geral sobre servi¸cos web e das tecnologias fundamentais formadoras

de sua base, XML, SOAP, WSDL e UDDI.

2.1 Introdu¸c˜ao

As organiza¸c˜oes est˜ao adotando cada vez mais a Arquitetura Orientada a

Servi¸cos com a ﬁnalidade d e suportar suas aplica¸c˜oes. SOA (Service Oriented Ar-

chitecture) ´e um paradigma computacional que emergiu como consequˆencia direta

da necessidade de colabora¸c˜ao e integra¸c˜ao de componentes funcionais, disponi-

bilizados nesse contexto como servi¸cos, entre empresas, de forma interoper´avel e

com fraco acoplamento. Servi¸cos web s˜ao uma implementa¸c˜ao poderosa dessa ar-

quitetura, que podem ser basicamente deﬁnidos como uma interface para recursos

computacionais, acess´ıvel atrav´es da troca d e mensagens baseadas em XML (Ex-

tensible Markup Language) e constru´ıda com a utiliza¸c˜ao de protocolos padr˜oes da

Internet.

Segundo a deﬁni¸c˜ao do W3C (World Wide Web Consortium), Servi¸co Web

´e um sistema de software projetado para suportar interoperabilidade m´aquina a

m´aquina atrav´es de intera¸c˜oes sobre uma rede de computadores. Sua interface ´e

CAP

ITULO 2. SERVIC¸ OS WEB 19

descrita em um formato que ´e processado em ambos os lados, especiﬁcamente em

WSDL (Web Services Deﬁnition Language). As bases para a constru¸c˜ao de um

servi¸co web s˜ao os padr˜oes XML e SOAP (Simple Object Access Protocol).

O SOAP ´e um protocolo leve para troca de informa¸c˜ao estruturada em um

ambiente descentralizado e distribu´ıdo.

E baseado na linguagem XML e consiste

em trˆes partes: um envelope, isto ´e, seu cabe¸calho, que descreve a mensagem, seu

conte´udo e como process´a-la, um conjunto de regras para codiﬁcar instˆancias de

tipos de dados da aplica¸c˜ao e uma conven¸c˜ao para representar chamadas de proce-

dimentos remotos e suas respostas. O transporte dos dados ´e realizado normalmente

via protocolo HTTP (Hypertext Transfer Protocol), mas tamb´em podem ser utiliza-

dos outros protocolos, tais como SMTP (Simple Mail Transfer Protocol) e FTP

(File Transfer Protocol). Os dados s˜ao transferidos no formato XML, encapsulados

pelo protocolo SOAP.

Um servi¸co web ´e uma solu¸c˜ao utilizada na integra¸c˜ao de sistemas e na co-

munica¸c˜ao entre aplica¸c˜oes diferentes. Com esta tecnologia, ´e poss´ıvel que novas

aplica¸c˜oes possam interagir com aquelas j´a existentes e que sistemas desenvolvi-

dos em plataformas diferentes sejam integrados. Em uma deﬁni¸c˜ao mais objetiva,

servi¸cos web s˜ao componentes que permitem as aplica¸c˜oes enviar e receber dados em

formato XML. Cada aplica¸c˜ao pode ter a sua pr´opria linguagem, que ´e traduzida

para uma linguagem universal, o formato XML. O processo de publica¸c˜ao, pesquisa

e descoberta de servi¸cos web utiliza o protocolo UDDI (Universal Description, Dis-

covery and Integration).

2.2 Servi¸co

Um servi¸co est´a dispon´ıvel em um ponto particular de uma rede de com-

putadores, recebendo e enviando mensagens; e comporta-se de acordo com sua es-

peciﬁca¸c˜ao. Os aspectos funcionais de um servi¸co s˜ao descritos usando metadados,

e as limita¸c˜oes e condi¸c˜oes que est˜ao associadas com o uso do servi¸co s˜ao especi-

ﬁcadas atrav´es de pol´ıticas que podem ser adicionadas a esses metadados. Inter-

CAP

ITULO 2. SERVIC¸ OS WEB 20

faces e pol´ıticas que descrevem os termos e as condi¸c˜oes que guiam a utiliza¸c˜ao do

servi¸co s˜ao publicadas de forma que os usu´arios possam descobrir e receber toda

a informa¸c˜ao de que eles precisam para se associar, muitas vezes dinamicamente,

`aquele servi¸co.

A informa¸c˜ao que ´e publicada sobre o servi¸co fornece detalhes daquilo que o

servi¸co oferece. O servi¸co tamb´em oferece toda a informa¸c˜ao necess´aria, para que,

no ambiente onde est´a hospedado, um cliente do servi¸co possa acess´a-lo e interagir

com ele de forma bem-sucedida. Embora o ambiente precise dessa informa¸c˜ao, o

cliente n˜ao necessita ﬁcar ciente desse tipo de informa¸c˜ao de acesso, j´a que n˜ao est´a

interessado em entender os detalhes sobre a implementa¸c˜ao do servi¸co. Al´em de p er-

mitir que um consumidor potencial concentre-se especiﬁcamente na funcionalidade

que est´a sendo ofertada, outra vantagem do modelo de servi¸co est´a na capacidade de

cria¸c˜ao de novos servi¸cos a partir daqueles j´a existentes sem abandonar o paradigma

(W3C, 2008).

2.3 Arquitetura Orientada a Servi¸cos

A Arquitetura Orientada a Servi¸cos (SOA) ´e um paradigma para orga-

niza¸c˜ao e utiliza¸c˜ao de competˆencias distribu´ıdas que est˜ao sob controle de diferen-

tes dom´ınios p ropriet´arios. A SOA utiliza servi¸cos como elementos fundamentais

para desenvolver aplica¸c˜oes ou solu¸c˜oes (OASIS, 2008).

Na arquitetura SOA, todos os componentes de software s˜ao modelados como

servi¸cos, possibilitando que processos de neg´ocio sejam projetados para serem uti-

lizados remotamente e acessados atrav´es de protocolos Internet. A Figura 2.1 mostra

os pap´eis e as prin cipais opera¸c˜oes desta arquitetura. Qualquer servi¸co cont´em trˆes

pap´eis principais: o servi¸co requisitante (service requestor), o provedor do servi¸co

(service provider) e um registro de servi¸cos (service registry) (Ferris and Farrell,

2003).

Um provedor de servi¸co ´e compar´avel com o “servidor” do modelo clien-

te/servidor. Ele ´e respons´avel por criar uma descri¸c˜ao do servi¸co, disponibilizando-o

CAP

ITULO 2. SERVIC¸ OS WEB 21

Figura 2.1: Arquitetura SOA. (W3C, 2008)

no ambiente distribu´ıdo e tornando-o acess´ıvel por outras entidades da rede. Ele

tamb´em ´e respons´avel por publicar o servi¸co em um ou mais servi¸co de registros

(UDDI) e receber requisi¸c˜oes de um ou mais servi¸cos requisitantes, encaminhando-

as para o servi¸co adequado de acordo com a descri¸c˜ao contida na requisi¸c˜ao. Assim,

pode-se visualizar o provedor de servi¸cos como uma entidade que disponibiliza seus

servi¸cos na Internet.

O servi¸co requisitante ´e compar´avel com a ﬁgura do “cliente” da arquitetura

cliente-servidor. Ele ´e respons´avel por achar um servi¸co atrav´es de uma descri¸c˜ao,

que submetida a um registro de servi¸cos retorna sua localiza¸c˜ao. Uma vez localizado

o servi¸co, ele faz a requisi¸c˜ao ao servi¸co hospedado no provedor de servi¸cos. O regis-

tro de servi¸cos ´e respons´avel por manter as descri¸c˜oes dos servi¸cos publicados pelos

provedores de servi¸cos e por permitir que requisitantes de servi¸cos pesquisem em

sua cole¸c˜ao de servi¸cos publicados. A pesquisa e publica¸c˜ao dos servi¸cos no cat´alogo

de servi¸cos n˜ao ´e obrigat´oria, pois o provedor pode dar a descri¸c˜ao dos servi¸cos que

oferece diretamente ao requisitante, desde que este ´ultimo saiba a localiza¸c˜ao do

provedor.

As opera¸c˜oes SOA s˜ao:

• Publica¸c˜ao (publish) -

E a a¸c˜ao da publica¸c˜ao, pelo provedor de servi¸cos,

dos seus servi¸cos em um registro;

CAP

ITULO 2. SERVIC¸ OS WEB 22

• Busca (ﬁnd) -

E a a¸c˜ao de pesquisar em um registro quais provedores de

servi¸cos oferecem determinados servi¸cos, de acordo com a descri¸c˜ao fornecida;

• Intera¸c˜ao (bind) -

E a opera¸c˜ao de comunica¸c˜ao entre o requisitante (cliente)

e o provedor do servi¸co (servidor).

2.4 Linguagem XML

Servi¸cos web ´e uma das concep¸c˜oes mais bem sucedidas da arquitetura

orientada a servi¸cos. Podem ser deﬁnidos como u m m´etodo de integra¸c˜ao de dados

e aplica¸c˜oes via padr˜oes XML atrav´es de plataformas computacionais e sistemas

operacionais (Benz and Durant, 2003). Aplica¸c˜oes habilitadas para servi¸cos web

fazem chamadas e enviam respostas umas `as outras por meio de um formato XML

chamado de SOAP. Servi¸cos web s˜ao descritos aos clientes e a outras aplica¸c˜oes

servidoras atrav´es do uso de outro formato XML chamado de WSDL. Informa¸c˜ao

de registro e localiza¸c˜ao de um servi¸co web pode ser publicada em um diret´orio

UDDI.

O XML desempenha papel vital no n´ucleo da tecnologia, por ser facilmente

transport´avel, compat´ıvel e comum com a camada de transp orte pela qual ´e trans-

mitida em todos os formatos de comunica¸c˜ao. A Figura 2.2 ilustra como XML

posiciona-se na base dos trˆes principais padr˜oes adotados para formar a tecnologia

de servi¸co web. Outros padr˜oes tamb´em compat´ıveis com servi¸co web empregam

XML como sua linguagem b´asica.

A Linguagem XML ´e derivado da SGML (Standard Generalized Markup Lan-

guage) (ISO 8879), um padr˜ao internacional para deﬁnir documentos eletrˆonicos.

SGML ´e uma linguagem de deﬁni¸c˜ao de documentos auto-explicativos usada para

descrever os mais variados tipos de documentos. Ela especiﬁca formas de como

descrever por¸c˜oes de um documento com marcadores de identiﬁca¸c˜ao. XML ´e

uma vers˜ao especializada de SGML usada para descrever documentos eletrˆonicos

dispon´ıveis na Internet. Ela n˜ao ´e na pr´atica uma linguagem, mas uma metalin-

guagem para deﬁnir novas linguagens. A deﬁni¸c˜ao de XML ´e independente de

CAP

ITULO 2. SERVIC¸ OS WEB 23

Figura 2.2: Linguagem XML como base

de servi¸cos web. (W3C, 2008)

plataforma e ´e especiﬁcada usando Unicode, permitindo-a representar conte´udo de

v´arias linguagens naturais. Devido a estes fatores e d o largo suporte de XML por

parte da maioria dos fornecedores de software, XML tem se tornado o formato de

fato para a troca de dados entre entidades diferentes.

XML descreve a estrutura de documentos ao esp eciﬁcar marcadores que iden-

tiﬁcam e delimitam por¸c˜oes de documentos. Cada uma dessas por¸c˜oes ´e chamada de

elemento. Elementos podem aparecer aninhados, sendo que o elemento mais externo

´e chamado de elemento raiz, e os contidos no elemento raiz s˜ao seus elementos ﬁlhos.

Cada um desses elementos podem, por sua vez, ter seus pr´oprios elementos ﬁlhos.

Al´em disso, XML fornece uma forma de associar pares nome e valor, chamados de

atributos, junto aos elementos.

Elementos XML come¸cam com um marcador inicial e terminam com um

marcador ﬁnal. Cada tipo de documento possui um conjunto de marcadores v´alidos.

Marcadores iniciais consistem de um nome colocado entre os sinais de menor e maior,

CAP

ITULO 2. SERVIC¸ OS WEB 24

como em < inicio >. O marcador ﬁnal correspondente ´e similar ao marcador inicial,

s´o diferenciando deste pelo acr´escimo da barra (/) depois do sinal de menor, como

em < /inicio >. Atributos podem ser usados para caracterizar elementos entre os

marcadores inicial e ﬁnal. As restri¸c˜oes sint´aticas, por exemplo, a exigˆencia de que

um marcador ﬁnal complemente um marcador inicial, ´e deﬁnido por XML. Essas

restri¸c˜oes capacitam o uso de analisadores sint´aticos (parsers) de XML, que devem

ser ﬂex´ıveis o bastante para trabalhar com qualquer documento especiﬁcado por

XML.

Uma propriedade importante dos documentos XML ´e a capacidade de serem

unidos para criar um novo documento, resultado da combina¸c˜ao de elementos e

atributos de diversas fontes, cada uma trabalhando ind ependentemente das outras.

Essa capacidade de reutiliza¸c˜ao d e documentos XML para comp or n ovos documen-

tos produz dois problemas: reconhecimento e conﬂito. O problema de reconheci-

mento diz respeito `a possibilidade do processador XML reconhecer e separar quais

elementos do novo documento pertencem aos documentos que o originaram. O

problema do conﬂito o corre quando existem elementos repetidos e recorrentes em

mais de um documento usado para construir o documento ﬁnal.

2.4.1 Document Type Deﬁnitions (DTD)

Na maioria das aplica¸c˜oes que utilizam documentos XML, o fato de ser bem

formado n˜ao garante que os mesmos possam ser processados e cumpram a fun¸c˜ao

para a qual foram criados. Nesse contexto, tem-se a no¸c˜ao de validade. O DTD

(W3C, 2008) constitui-se em mecanismo declarativo que pode automatizar a vali-

da¸c˜ao de conte´udos XML quando est es s˜ao processados por analisadores sint´aticos.

Para manipular a checagem de valida¸c˜ao, o mecanismo DTD pode implementar

regras nos seguintes aspectos d e um documento XML: identiﬁca¸c˜ao de elementos

que podem ou devem estar presentes em um documento, identiﬁca¸c˜ao da ordem e

da rela¸c˜ao entre elementos e identiﬁca¸c˜ao de atributos de todos os elementos, al´em

da determina¸c˜ao de quais destes atributos s˜ao obrigat´orios ou opcionais.

Apesar de representarem um signiﬁcativo avan¸co na valida¸c˜ao de documentos

CAP

ITULO 2. SERVIC¸ OS WEB 25

XML, deﬁciˆencias podem ser encontradas em DTDs, o que limita sua utiliza¸c˜ao em

um grande n´umero de aplica¸c˜oes, principalmente naquelas orientadas a dados. Entre

estas limita¸c˜oes pode-se citar: os arquivos de valida¸c˜ao DTDs n˜ao s˜ao escritos em

XML, tornando sua manipula¸c˜ao e processamento complexos; DTDs foram proje-

tados antes dos XML Namespaces, que s˜ao fundamentais para aplica¸c˜oes orientadas

a dados; DTDs n˜ao comportam no¸c˜oes sobre tipos de dados, o que impossibilita a

representa¸c˜ao de estruturas de dados provenientes de linguagens de programa¸c˜ao.

2.4.2 XML Schemas

XML Schema (W3C, 2008) ´e uma metalinguagem usada com especiﬁca¸c˜oes

XML para descrever estrutura de dados, limita¸c˜oes sobre o conte´udo, e tipos de

dados. Foi desenvolvido para fornecer um controle mais poderoso sobre os dados

do que aquele proporcionado por DTDs. Diferentemente dos DTDs, XML Schema

´e expresso em XML, o que elimina a necessidade dos analisadores sint´aticos ma-

nipularem outra sintaxe, al´em de produzir o ganho do poder de XML. O pr´oprio

vocabul´ario do XML Schema tamb´em ´e autodeﬁnido empregando XML.

Al´em de especiﬁcar estruturas XML, XML Schema deﬁne um conjunto de

tipos de d ados simples que pode ser usado para estabelecer valores para atributos e

elementos, e construtores recursivos de tipo, para deﬁnir arbitrariamente estruturas

complexas de tipo. Uma vez que o esquema tenha sido deﬁnido, processadores

de esquema s˜ao capazes de validar um do cu mento para assegurar que o mesmo

corresponda `a estrutura do esquema e aos valores permitidos. Essa veriﬁca¸c˜ao pode

eliminar a origem de v´arias das vulnerabilidades que prejudicam sistemas baseados

na Web.

2.5 Simple Object Access Protocol (SOAP)

Na arquitetura de servi¸cos web, o protocolo padr˜ao de fato para comu-

nica¸c˜ao entre duas partes ´e o S OAP. SOAP ´e um p rotocolo baseado em XML que

fornece um mecanismo simples para a troca de informa¸c˜ao tipada e estruturada

CAP

ITULO 2. SERVIC¸ OS WEB 26

entre servi¸cos. Foi projetado para reduzir o custo e a complexidade de se integrar

aplica¸c˜oes constru´ıdas em diferentes plataformas de hardware e software.

Uma das caracter´ısticas mais importantes do SOAP ´e a separa¸c˜ao entre o

formato do dado a ser transmitido e o protocolo de n´ıvel inferior que ir´a transportar

o dado, garantindo a independˆencia de plataforma e linguagem, pois emprega-se

XML para descrever os dados e protocolos bem estabelecidos na Internet, como

HTTP, para transportar as mensagens (Abinaer and Lins, 2006). Geralmente, os

dados transportados em uma mensagem SOAP representam chamadas remotas de

procedimentos (RPC) que invocam procedimentos espec´ıﬁcos em um provedor de

servi¸co. A especiﬁca¸c˜ao do protocolo SOAP limita-se em formalizar quest˜oes b´asicas

que informam precisamente como aplica¸c˜oes diferentes, estabelecidas em ambientes

de comunica¸c˜ao distintos, devem proceder para trocar mensagens SOAP. Projetado

para manter a compatibilidade, a capacidade de expans˜ao e adequa¸c˜ao ao ambiente

da Internet, SOAP pode expandir-se para acomodar tecnologias e padr˜oes emer-

gentes, bem como acomodar padr˜oes j´a estabelecidos.

2.5.1 Mensagem SOAP

Uma mensagem SOAP ´e a unidade b´asica de comunica¸c˜ao entre n´os SOAP,

representada por um documento XML bem formado que cont´em trˆes elementos

distintos: um envelop e (Envelope), um cabe¸calho (Header) e um corpo (Body). A

Figura 2.3 mostra como os trˆes principais elementos de uma mensagem SOAP s˜ao

estruturados. Al´em destes elementos, o protocolo SOAP deﬁne o elemento Fault

para manipula¸c˜ao de erros que devem ser reportados ao emissor da mensagem.

O elemento envelop e funciona como container para os elementos cabe¸calho

e corpo.

E o elemento raiz da mensagem SOAP, sua fun¸c˜ao principal ´e indicar

ao receptor da mensagem onde come¸ca e termina a mensagem. Ao encontrar o

marcador < Envelope >, o receptor sabe que pode processar a mensagem de acordo

com a especiﬁca¸c˜ao SOAP.

Opcionalmente, uma mensagem SOAP pode conter um cabe¸calho, designa-

do pelo marcador < Header >. Caso esteja presente na mensagem, ele deve ser

CAP

ITULO 2. SERVIC¸ OS WEB 27

Figura 2.3: Estrutura da men-

sagem SOAP. (W3C, 2008)

o primeiro imediatamente ap´os o elemento envelope. O elemento cabe¸calho possi-

bilita uma se¸c˜ao na qual podem ser adicionados metadados relativos ao conte´udo do

elemento corpo e/ou instru¸c˜oes para processamento espec´ıﬁco da mensagem SOAP.

Apesar de n˜ao obrigat´orio, o cabe¸calho constitui-se no mecanismo chave para

a capacidade de expans˜ao do protocolo SOAP, j´a que com a adi¸c˜ao apropriada de

entradas no cabe¸calho, n´os de processamento s˜ao instru´ıdos a se comportarem de

modo espec´ıﬁco em determinados contextos como autentica¸c˜ao, autoriza¸c˜ao, rotea-

mento, etc. Ao receber a mensagem SOAP com este atributo, o n´o dever´a executar

o que determina a entrada ou, em caso de falha, enviar uma mensagem padr˜ao de

erro.

O elemento corpo, indicado pelo marcador < Body >, deve obrigatoriamente

estar presente em todas as mensagens SOAP. Este elemento carrega a carga ´util des-

tinada ao receptor ﬁnal da mensagem. A carga ´util pode conter uma chamada RPC,

uma resposta RPC ou docum entos XML. O elemento < F aul t > ´e um mecanismo

soﬁsticado e preciso para informar ao emissor a ocorrˆencia de algum erro ou falha

no processamento de mensagens, tamb´em pode aparecer no corpo da mensagem.

CAP

ITULO 2. SERVIC¸ OS WEB 28

O c´odigo apresentado n a Listagem 2.1 mostra uma mensagem SOAP simples com

alguns elementos poss´ıveis: envelope, cabe¸calho e corpo.

Listagem 2.1: Exemplo de mensagem SOAP

1 <?xml version="1.0" enconding="uft -8"?>

2 <SOAP−ENV:Envelope x m l n s : x s i="http: // www.w3.org /2001/XMLSchema -

3 instance" xmlns:xsd="http: // www .w3.org /2001/ XMLSchema"

4 xmlns:SOAP−ENV="http: // schemas . xmlsoap . org/soap / envelope">

5 <SOAP−ENV:Header>

6 < a : a u t h e t i c a t i o n xmln s :a="http:// www.wrox .com/soap/authetication"

7 SOAP−ENV:mustUnderstand="1">

8 <a:username>u s u a r i o</ a:username>

9 <a :pas s word>senha</ a:p assw o rd>

10 < a : a u t h e t i c a t i o n>

11 </SOAP−ENV:Header>

12 <SOAP−ENV:Body>

13 <cmd:processReboot xmlns:cmd="http: // www.wrox .com/soap/cmd">

14 <i p x s i : t y p e=" xsd:string "> 1 9 2 . 1 6 8 . 1 . 3</ ip>

15 </ cmd:processReboot>

16 </SOAP−ENV:Body>

17 </SOAP−ENV:Envelope>

2.5.2 Modelo de Processamento SOAP

O comportamento de um n´o SOAP, ao manusear mensagens SOAP, ´e de-

terminado pelo modelo de processamento. Um n´o SOAP ´e uma implementa¸c˜ao

das regras de processamento descritas na especiﬁca¸c˜ao SOAP e pode enviar, re-

ceber e processar mensagens SOAP. Trˆes categorias de n´os de processamento s˜ao

deﬁnidas por SOAP, emissor, receptor e intermedi´ario. Se um n´o SOAP envia uma

mensagem, ele ´e chamado de emissor SOAP. Diferentemente do receptor SOAP, res-

pons´avel por receber uma mensagem. Alguns n´os se situam entre o consumidor e o

provedor do servi¸co, atuando tanto como emissor quanto como receptor. Nesse caso,

eles s˜ao chamados de intermedi´arios. Geralmente, um n´o intermedi´ario tamb´em ´e

um servi¸co web capaz de adicionar funcionalidades `as transa¸c˜oes que passam por

CAP

ITULO 2. SERVIC¸ OS WEB 29

ele.

Uma mensagem SOAP pode destinar cabe¸calhos para n´os espec´ıﬁcos, de

modo a garantir que a mensagem seja roteada passo a passo, obedecendo `a sequˆencia

de processamento pr´e-estabelecida. Cada entrada no cabe¸calho deve conter o nome

do n´o a qual se destina, informa¸c˜ao identiﬁcada atrav´es do atributo actor na entrada

do cabe¸calho.

Essa sequˆencia de processamento faz com que uma mensagem SOAP em

algumas ocasi˜oes atravesse v´arios n´os SOAP. Um emissor SOAP inicial cria a men-

sagem; a mensagem por sua vez passa por v´arios intermedi´arios antes de chegar

ao receptor SOAP ﬁnal, cuja fun¸c˜ao principal ´e processar a carga ´util do corpo

da mensagem. Esse conjunto de n´os SOAP ´e chamado de caminho da mensagem

SOAP.

2.5.3 SOAP sobre Protocolos de Transporte

Uma mensagem SOAP pode ser transmitida sobre diferentes protocolos de

transporte: HTTP, protocolo de correio eletrˆonico (SMTP) ou at´e mesmo protoco-

los propriet´arios de transporte. O protocolo selecionado talvez forne¸ca recursos adi-

cionais como garantia de entrega, correla¸c˜ao de u ma resposta para uma solicita¸c˜ao,

ou detec¸c˜ao e corre¸c˜ao de erro, mecanismos esses que estendem as funcionalidades

b´asicas oferecidas pelo protocolo SOAP. Al´em disso, o protocolo base de transmiss˜ao

talvez suporte padr˜oes de troca de mensagem mais complexos do que a troca de

mensagem em sentido ´unico especiﬁcada por SOAP.

Devido a sua grande utiliza¸c˜ao na Internet, HTTP ´e de longe o protocolo de

transporte mais utilizado na troca de mensagens SOAP. At´e mesmo a especiﬁca¸c˜ao

SOAP oferece tratamento especial para HTTP, descrevendo com detalhes como a

semˆantica do modelo de troca de mensagens SOAP ´e mapeado para HTTP. SOAP

sobre HTTP ´e naturalmente compat´ıvel com as conven¸c˜oes RPC do SOAP (so-

licita¸c˜ao/resposta), j´a que HTTP ´e um protocolo baseado neste modelo. Uma men-

sagem de solicita¸c˜ao SOAP ´e enviada a um servidor HTTP junto a u ma solicita¸c˜ao

HTTP, e o servidor retorna a mensagem de resposta SOAP em uma resposta HTTP.

CAP

ITULO 2. SERVIC¸ OS WEB 30

2.6 Web Services Description Language (WSDL)

WSDL ´e um formato XML para descrever servi¸cos de rede como um conjunto

de pontos de acesso que funcionam atrav´es de mensagens contendo informa¸c˜ao ori-

entada ao documento ou orientada ao procedimento. As opera¸c˜oes e as mensagens

s˜ao descritas de forma abstrata e ligadas ao protocolo de transporte e ao formato

da mensagem para deﬁnir um ponto de acesso. WSDL ´e extens´ıvel para permitir

que a descri¸c˜ao de pontos de acesso e suas mensagens n˜ao levem em considera¸c˜ao

quais formatos de mensagem ou protocolos de transporte est˜ao sendo usados na

comunica¸c˜ao (Weerawarana et al, 2005).

O provedor de um servi¸co web utiliza a WSDL para construir um documento

que descreve detalhes necess´arios na invoca¸c˜ao do servi¸co por um cliente. Deta-

lhes como: a interface do servi¸co, quais m´etodos est˜ao dispon´ıveis, as assinaturas

dos m´etodos e os valores retornados, o endere¸co onde o servi¸co est´a localizado e

o protocolo que o servi¸co ´e capaz de processar para efetuar a comunica¸c˜ao, s˜ao

disponibilizados para a captura independente de plataforma e linguagem. O uso da

WSDL proporciona algumas vantagens:

• Torna mais f´acil a cria¸c˜ao e a manuten¸c˜ao de servi¸cos atrav´es do fornecimento

de uma abordagem mais estruturada para deﬁnir interfaces de servi¸cos web;

• Facilita o consumo de servi¸cos web ao reduzir a quantidade de c´odigo (e erros

potenciais) que uma aplica¸c˜ao cliente p recisa implementar;

• Facilita a implementa¸c˜ao de mudan¸cas que provavelmente ser˜ao menos im-

pactantes `as aplica¸c˜oes clientes SOAP. A descoberta dinˆamica de descri¸c˜oes

WSDL permite que tais mudan¸cas sejam repassadas automaticamente aos

clientes que estejam usando WSDL, de forma que modiﬁca¸c˜oes custosas no

c´odigo do cliente n˜ao tenham que ser feitas a cada vez que uma mudan¸ca

ocorra.

CAP

ITULO 2. SERVIC¸ OS WEB 31

2.6.1 Estrutura do Documento WSDL

Um documento WSDL organiza-se em duas se¸c˜oes l´ogicas: uma descri¸c˜ao

abstrata e uma descri¸c˜ao concreta. A parte abstrata, composta pelos elementos

< types >, < message > e < portT ype >, descreve o comportamento de um

servi¸co web em rela¸c˜ao `as mensagens que ele consome e produz. A parte concreta

se ocupa em informar como e onde acessar a implementa¸c˜ao de um servi¸co. Essas

informa¸c˜oes s˜ao cobertas pelos elementos < binding > e < service >. A estrutura

sint´atica do documento WSDL ´e mostrada na Figura 2.4.

Figura 2.4: Estrutura

do documento WSDL.

(W3C, 2008)

Arquivos WSDL iniciam com um elemento raiz < definitions >, que cont´em

geralmente atributos deﬁnindo namespaces que descrevem quais XML Schemas s˜ao

usados ao longo do documento WSDL. O elemento < types > engloba a deﬁni¸c˜ao

dos t ipos de dados relevantes para as mensagens trocadas entre o servi¸co e o cliente.

CAP

ITULO 2. SERVIC¸ OS WEB 32

To d as as mensagens que possam vir a ser trocadas entre o consumidor do

servi¸co e o servi¸co s˜ao listadas no documento WSDL, atrav´es do emprego do ele-

mento < message >. Esse elemento ´e respons´avel por deﬁnir de forma abstrata

o conte´udo das mensagens. O elemento < portT ype > deﬁne um conjunto de

opera¸c˜oes relacionadas que um servi¸co web suporta. Uma opera¸c˜ao ´e um agrupa-

mento das mensagens que podem ser t rocadas em uma intera¸c˜ao particular com o

servi¸co e ´e indicado pelo elemento < operation >. Quatro tipos de opera¸c˜oes s˜ao

suportados:

• Unidirecional - Uma mensagem chega ao servi¸co e n˜ao ´e produzido nada

como resposta;

• Solicita¸c˜ao/Resposta - Uma mensagem chega ao servi¸co e ´e produzida uma

mensagem como resposta;

• Pedido/Resposta - O servi¸co envia uma mensagem e obt´em uma resposta

de volta;

• Notiﬁca¸c˜ao - O servi¸co envia uma mensagem e n˜ao recebe nada como res-

posta.

O protocolo usado para transportar as mensagens ´e especiﬁcado na descri¸c˜ao

concreta pelo elemento < binding >. Esse elemento associa um protocolo espec´ıﬁco

(SOAP, HTTP, SMTP, etc) a um elemento < portT ype > particular. O elemento

< service > ´e a parte ﬁnal da descri¸c˜ao de um servi¸co. Atrav´es de seu elemento

ﬁlho < port > ele indica o endere¸co de rede onde o servi¸co web est´a localizado,

aguardando para ser acessado.

2.7 Universal Description, Discovery and Inte-

gration (UDDI)

Um cons´orcio de companhias, incluindo Ariba, IBM e Microsoft, come¸cou o

desenvolvimento do conceito d e um diret´orio de neg´ocios na Internet. Esse desen-

CAP

ITULO 2. SERVIC¸ OS WEB 33

volvimento produziu como resultado o projeto UDDI, uma infraestrutura integrada

para descri¸c˜ao, publica¸c˜ao e descoberta de informa¸c˜oes sobre servi¸cos web ofere-

cidos na Internet. Como se trata de uma iniciativa aberta da ind´ustria para ofe-

recer u m servi¸co de diret´orio, UDDI foi estabelecido como um mecanismo aberto,

padronizado e independente de plataforma, cujo foco ´e facilitar a localiza¸c˜ao de

servi¸cos dispon´ıveis.

Basicamente, UDDI disponibiliza uma forma estruturada de descrever uma

organiza¸c˜ao, os servi¸cos que s˜ao oferecidos por essa organiza¸c˜ao e uma interface

para os servi¸cos. A necessidade do uso de UDDI justiﬁca-se cada vez mais `a medida

que o n´umero de servi¸cos web considerados para a escolha e utiliza¸c˜ao cresce muito.

Nesse cen´ario, UDDI garante que pelo menos grande parte dos potenciais parceiros

que oferecem servi¸cos web, aderentes aos requisitos procurados, fossem realmente

considerados nessa escolha.

Antes do aparecimento do projeto UDDI, n˜ao havia na ind´ust ria uma forma

padronizada de oferecer a clientes e p arceiros maiores informa¸c˜oes sobre servi¸cos

web disponibilizados pelas organiza¸c˜oes. N˜ao havia m´etodo uniforme e padr˜ao que

detalhasse como integrar os sistemas e processos j´a estabelecidos e dispon´ıveis, e

como esta integra¸c˜ao se daria entre parceiros de neg´ocios que se interessassem pelos

servi¸cos web oferecidos.

2.7.1 Registro UDDI

Um registro UDDI ´e um reposit´orio de dados sobre os neg´ocios e os servi¸cos

oferecidos por eles. Possibilita a qualquer um recuperar dados UDDI existentes,

bem como a qualquer empresa registrar-se a si pr´opria e seus respectivos servi¸cos.

A implementa¸c˜ao do registro UDDI ´e semelhante a uma lista telefˆonica constitu´ıda

de p´aginas brancas, amarelas e verdes.

Nas p´aginas brancas est˜ao dispon´ıveis informa¸c˜oes sobre contato e identiﬁ-

cadores da empresa, incluind o nome da empresa, endere¸co, n´umeros de telefone,

al´em de outras informa¸c˜oes sobre a empresa. A fun¸c˜ao das p´aginas brancas ´e per-

mitir a descoberta de servi¸cos web oferecidos atrav´es da identiﬁca¸c˜ao de cada em-

CAP

ITULO 2. SERVIC¸ OS WEB 34

presa. As p´aginas amarelas descrevem servi¸cos web usando diferentes categorias,

permitindo sua descoberta, segund o um grupo, uma classiﬁca¸c˜ao que re´une servi¸cos

similares. As p´aginas verdes s˜ao usadas para indicar os servi¸cos web oferecidos pelas

empresas, incluindo todas as informa¸c˜oes t´ecnicas necess´arias na intera¸c˜ao com o

servi¸co, ou com sua utiliza¸c˜ao, como parˆametros, localiza¸c˜ao e outras.

2.8 Considera¸c˜oes Finais

Nos ´ultimos anos, os servi¸cos web tˆem chamado a aten¸c˜ao de muitas em-

presas e pesquisadores que buscam solu¸c˜oes para criar e integrar aplica¸c˜oes sem

altos investimentos, utilizando-se de padr˜oes da Internet. Servi¸cos web foram cria-

dos para construir aplica¸c˜oes deste tipo ou possibilitar tal integra¸c˜ao. A facilidade

que servi¸cos web trouxeram para desenvolvedores, devido `a utiliza¸cao de documen-

tos XML para troca de informa¸c˜oes, os tornam independente de plataforma, sendo

poss´ıvel que novas aplica¸c˜oes possam interagir com aquelas j´a existentes e que sis-

temas desenvolvidos em plataformas diferentes sejam compat´ıveis. Cada aplica¸c˜ao

pode ter a sua pr´opria “linguagem”, que ´e traduzida para um a linguagem universal,

o formato XML. Assim, servi¸cos web, atualmente, se apresentam como a melhor

escolha para integrar e desenvolver solu¸c˜oes.

Cap

ıtulo 3

Redes P2P

3.1 Introdu¸c˜ao

A rede mundial de computadores sempre teve como proposta principal pro-

mover a liberdade, que deve se traduzir no acesso irrestrito a todos os recursos da

rede, de qualquer lugar e a qualquer hora. Apesar disso, a Web ainda est´a presa

ao modelo cliente/servidor, no qual servidores centralizados executam tarefas para

clientes distribu´ıdos, ou seja, a maior parte das m´aquinas participam da Web apenas

como coadjuvantes, acessando recursos providos pela minoria (Rocha et al., 2004).

A tecnologia P2P (peer-to-peer) surge para mudar o paradigma existente, `a

medida que n˜ao depende de uma organiza¸c˜ao central ou hier´arquica, al´em d e dispor

aos seus integrantes as mesmas capacidades e responsabilidades (Parameswaran et

al., 2001). Atrav´es dessa tecnologia qualquer dispositivo pode acessar diretamente

os recursos de outro, sem nenhum controle centralizado.

3.2 Evolu¸c˜ao das Redes P2P

As redes P2P s˜ao sistemas que est˜ao emergindo como uma nova forma de

computa¸c˜ao distribu´ıda, principalmente quando se fala de uma organiza¸c˜ao inde-

pendente de restri¸c˜oes, estrutura descentralizada, autˆonoma e com participa¸c˜ao ir-

restrita dos integrantes (Ting and Deters, 2003). Essa evolu¸c˜ao come¸cou na d´ecada

CAP

ITULO 3. REDES P2P 36

de 90, com o ganho de capacidade de computadores desktop e a desmotiva¸c˜ao de

usu´arios da Internet com as restri¸c˜oes para troca e armazenamento de dados nos

provedores de acesso. O surgimento d as redes P2P representou a primeira ex-

periˆencia de uma rede totalmente livre de cl´ausulas contratuais e restri¸c˜oes tec-

nol´ogicas impostas pelos provedores. Esse surgimento se deu com a populariza¸c˜ao

da Internet, melhores equipamentos e aumento da largura de banda das conex˜oes

de acesso. A Figura 3.1 mostra o modelo b´asico de uma rede P2P. Percebe-se que

todos os n´os podem ser interconectados entre si. Cada participamente tem um

identiﬁcador ´unico dentro da rede e as mesmas funcionalidades est˜ao presentes em

todos os n´os.

Figura 3.1: Exemplo de uma rede P2P.

As redes P2P s˜ao tidas como sistemas colaborativos (GT-P2P, 2008) que

emergiram a partir de 2000, principalmente com as aplica¸c˜oes para distribui¸c˜ao

de arquivos. Os n´os conectados ao sistema colaborativo formam uma rede virtual

sobre a rede de dados subjacente, baseada n o protocolo IP, no caso da Internet.

Os sistemas P2P trazem a conectividade para as bordas da rede, permitindo que

qualquer equipamento conectado se comunique e colabore com os demais (Sadok,

2003).

Segundo (Loo, 2003), o modelo de rede P2P colaborativo tem sido apontado

como uma das maiores transforma¸c˜oes da Internet nos ´ultimos anos e com tendˆencia

de expans˜ao. Esse modelo ´e atrativo por v´arias raz˜oes: os sistemas P2P oferecem

CAP

ITULO 3. REDES P2P 37

meios para agregar e utilizar recursos geograﬁcamente distribu´ıdos; o custo para a

cria¸c˜ao dos ambientes colaborativos ´e baixo e n˜ao requer investimento maci¸co em

equipamentos; a natureza descentralizada desses sistemas torna-os inerentemente

resistentes a falhas ou ataques intencionais; e, alta escalabilidade para tratar do

crescimento de elementos que se juntam `a rede P2P (Righi et al., 2004).

Atualmente, as redes P2P respondem pela maior parte do tr´afego da Internet.

Considerando que muitas das trocas de recursos s˜ao falhas, deve-se empregar cada

vez mais mecanismos para evitar que isto ocorra, possibilitando melhor desempenho

das redes P2P e por sua vez, da Internet. A Figura 3.2 mostra um gr´aﬁco do aumento

do tr´afego das aplica¸c˜oes P2P na Internet de 1993 a 2006. Percebe-se que o tr´afego

de dados gerado pelas redes P2P, em 2006, j´a superava o dos demais protocolos,

como o FTP, HTTP (Web) e o SMTP (e-mail). Isto mostra que estes protocolos j´a

n˜ao s˜ao t˜ao utilizados para troca de dados como outrora.

Figura 3.2: Tr´afego das redes P2P entre 1993 e 2006. (Cache-

Logic Reseach, 2006)

3.3 Caracter´ısticas das Redes P2P

Redes P2P s˜ao redes virtuais que funcionam sobre a infraestrutura da In-

ternet com o objetivo de compartilhar recursos entre seus participantes, sendo que

CAP

ITULO 3. REDES P2P 38

por princ´ıpio n˜ao h´a diferencia¸c˜ao entre os mesmos. O grupo de pesquisa sobre

redes P2P da Internet Research Task Force (IRTF-P2P-GROUP, 2008) as deﬁne

como compartilhamento de recursos e servi¸cos compu tacionais diretamente entre

sistemas. Em geral, ´e aceito pela comunidade que sistemas P2P devem sup ortar os

seguintes requisitos:

• N´os podem estar localizados nas bord as da red e;

• N´os com conectividade vari´avel ou tempor´aria e endere¸cos tamb´em tempor´arios;

• A capacidade de lidar com diferentes taxas de transmiss˜ao entre n´os;

• N´os com autonomia parcial ou total com rela¸c˜ao a um servidor centralizado;

• Assegurar que os n´os possuam capacidades iguais de fornecer e consumir re-

cursos de seus n´os;

• A rede deve ser escal´avel;

• A capacidade dos n´os se comunicarem diretamente uns com os outros.

Tendo todas estas caracter´ısticas, uma rede pod e ser dita P2P, mesmo que

algumas das fun¸c˜oes de controle da rede estejam localizadas em um servidor central.

3.4 Aplica¸c˜oes P2P

As redes P2P tˆem se colocado como a melhor solu¸c˜ao para muitas aplica¸c˜oes

que necessitam de uma ampla participa¸c˜ao e intera¸c˜ao dos usu´arios no seu funciona-

mento. Nesta se¸c˜ao ser˜ao apresentadas as principais aplica¸c˜oes que fazem uso deste

tipo de rede (Da Silva, 2007).

3.4.1 Compartilhamento de Arquivos

S˜ao as aplica¸c˜oes mais populares e foram respons´aveis pelo cen´ario atual das

redes P2P. Normalmente n˜ao h´a restri¸c˜oes de publica¸c˜ao e obten¸c˜ao do conte´udo

CAP

ITULO 3. REDES P2P 39

disponibilizado. Por´em, essas redes tˆem sido um dos principais motivos d e estudos

para melhoria do desempenho, j´a que elas s˜ao respons´aveis por grande parte do

conte´udo que trafega na Internet. As redes P2P deste tipo mais populares s˜ao Naps-

ter (Napster, 2008), Gnutella (Gnutella, 2008), eDonkey (eDonkey, 2008), Kazaa

(Kazaa, 2008) e BitTorrent (BitTorrent, 2008).

3.4.2 Computa¸c˜ao Distribu´ıda

S˜ao aplica¸c˜oes que visam utilizar os recursos de milhares de computadores

para prover um poder de processamento intensivo atrav´es da forma¸c˜ao de uma grade.

Recentes projetos tˆem estimulado o interesse, o projeto SETI@home (Seti@Home,

2008), por exemplo, possui um poder computacional de aproximadamente 25 TFlo-

ps/s (trilh˜oes de opera¸c˜oes de ponto ﬂutuante por segundo), coletado de mais de

trˆes milh˜oes de computadores conectados `a Internet. Esse projeto visa utilizar essa

grande capacidade de processamento para analisar os sinais obtidos a partir do

r´adio-telesc´opio d o observat´orio de Arecibo `a procura de algum sinal inteligente

de vida extraterrestre. Outros exemplos s˜ao o OurGrid (Andrade et al., 2008),

InteGrade (InteGrade, 2008) e Genome@Home (Genome@Home, 2008).

3.4.3 Troca de Mensagens

A necessidade de troca de mensagens instantˆaneas ´e muito grande atual-

mente. Muitos sistemas P2P de compartilhamento de arquivos tamb´em possuem

o recurso dos usu´arios se comunicarem, mesmo n˜ao sabendo sua identidade. Ou-

tros sistemas permitem mensagens de voz, v´ıdeo, troca de arquivos e integra¸c˜ao

dos sistemas com sistemas de mensagens SMS (Short Message Service). Exem-

plos de aplica¸c˜oes desse tipo s˜ao MSN Messenge r Live ( MSN, 2008), Google Talk

(GoogleTalk, 2008), Yahoo Messenger (YahooMessenger, 2008), Jabber (Jabber,

2008), ICQ (ICQ, 2008), Skype (Skype, 2008) e LawsTalk (LawsTalk, 2008).

CAP

ITULO 3. REDES P2P 40

3.4.4 Transmiss˜ao de Dados

Tamb´em conhecidos como sistemas overlay multicast, formam uma infraestru-

tura de comunica¸c˜ao baseada em multicast em n´ıvel de aplica¸c˜ao. Possibilitam que

conte´udo seja distribu´ıdo a um n´umero potencialmente grande de n´os disp ersos

geograﬁcamente. Normalmente essa tecnologia ´e empregada para a transmiss˜ao

de eventos ao vivo (live streaming). Pode-se citar como exemplo o End System

Multicast (ESM, 2008).

3.5 Redes P2P versus Redes Overlay

Uma rede overlay ´e uma rede “virtual” criada sobre u ma rede existente, por

exemplo, a Internet. A rede overlay cria uma arquitetura com n´ıvel mais alto de

abstra¸c˜ao, de modo a poder solucionar v´arios problemas que, em geral, s˜ao dif´ıceis

de serem tr atados no n´ıvel dos roteadores da rede subjacente (Andersen et al.,

2001). A pr´opria Internet pratica o paradigma overlay quando usa o protocolo IP

como solu¸c˜ao de internetworking sobre tecnologias de r edes de v´arias tecnologias,

tais como ATM (Asynchronous Transfer Mode), Frame Relay, MPLS (Multiprotocol

Label Switching), Ethernet, etc.

Numa perspectiva de alto n´ıvel, uma rede P2P pode ser considerada uma rede

overlay, uma vez que funciona como uma rede virtual, formada pela interconex˜ao

dos n´os, executando sobre a infraestrutura de uma rede f´ısica. A Figura 3.3 mostra

a top ologia de uma Rede Overlay. Percebe-se que as conex˜oes entre os n´os da rede

Overlay sobrep˜oem as interconex˜oes da rede IP, onde a simples comunica¸c˜ao direta

entre dois n´os, ´e viabilizada por um complexo mecanismo de roteamento IP.

3.6 Arquitetura das Redes P2P

As redes P2P p odem ser organizadas sob diversos asp ectos, e embora todas

elas possuam problemas de seguran¸ca em comum, cada arquitetura possui seus

pr´oprios problemas. Aqui s˜ao apresentados os modelos arquiteturais comuns das

CAP

ITULO 3. REDES P2P 41

Figura 3.3: Rede overlay.

redes P2P, mostrando as vantagens e os problemas normalmente encontrados. Esses

tipos de redes podem ser divididos basicamente de duas formas: com rela¸c˜ao `a

centraliza¸c˜ao ou n˜ao da rede, e com rela¸c˜ao `a est rutur a¸c˜ao da busca de recursos

(Do Carmo et al., 2004).

Com rela¸c˜ao `a sua distribui¸c˜ao, podem ser organizadas em trˆes tipos: cen-

tralizadas, descentralizadas ou descentralizadas com uso de supern´os. As redes

centralizadas possuem um n´o central que realiza alguma fun¸c˜ao especial, como con-

trole de acesso ou busca de recursos. Redes descentralizadas s˜ao as chamadas redes

P2P puras, nas quais cada n´o tem exatamente as mesmas funcionalidades que os

outros, isto ´e, tem um papel de cliente e servidor. As redes com supern´os possuem

n´os com maior capacidade de armazenamento e processamento, que s˜ao eleitos para

realizar fun¸c˜oes especiais, como reposit´orio para busca de recursos. A diferen¸ca em

rela¸c˜ao `as redes centralizadas ´e que esses n´os podem se tornar supern´os somente por

um determinado per´ıodo de tempo e a rede deve ser capaz de funcionar mesmo que

nenhum supern´o esteja presente. A Figura 3.4 ilustra bem essas redes. Veem-se n´os

conectados diretamente e n´os conectados e gerenciados por um ou mais n´os centrais.

3.6.1 Redes P2P Centralizadas

Do ponto de vista de seguran¸ca, as redes P2P centralizadas s˜ao as que

possuem melhores condi¸c˜oes de se tornarem seguras. Isto porque a entidade cen-

tralizadora se responsabiliza pela maior parte da seguran¸ca da rede. Embora possa

parecer que redes P2P centralizadas n˜ao possuam riscos grandes `a seguran¸ca, alguns

pontos devem ser observados para que se obtenha uma rede P2P segura.

CAP

ITULO 3. REDES P2P 42

Figura 3.4: Rede P2P descentralizada versus centralizada.

(Addison, 2002)

Normalmente, uma rede P2P centralizada pressup˜oe um n´o central que ´e res-

pons´avel p or algumas funcionalidades ausentes nos outros n´os, sendo assim, redes

centralizadas possuem uma organiza¸c˜ao hier´arquica onde todos os n´os dependem

de um ou mais servidores. Por exemplo, no caso do Napster, a rede possui um n´o

central que realiza as buscas de conte´udo, controle de ingresso e conex˜ao `a rede.

Sem esse n´o, a rede n˜ao funciona.

E interessante destacar que o n´o central pode ser

representado por um ou mais servidores em cluster. O n´o central ´e o ponto alto da

hierarquia do sistema, sendo todas as pesquisas feitas ao servidor central, por´em os

recursos ﬁcam presentes nos n´os. Assim, o servidor passa a referˆencia de onde est´a

o recurso e o n´o requisitante se conecta diretamente para fazer a transferˆencia. A

Figura 3.5 (a) mostra esta estrutura.

Em redes P2P, o n´o central ´e respons´avel pela distribui¸c˜ao de identiﬁcadores

´unicos, distribui¸c˜ao de chaves p´ublicas, c´alculo de reputa¸c˜ao de n´os, entre outros

servi¸cos que ajudam a tornar a rede segura. Entretanto, um n´o central n˜ao pode

assegurar algumas quest˜oes, como garantir a inexistˆencia de conte´udo malicioso con-

tido em informa¸c˜oes supostamente conﬁ´aveis. Como as informa¸c˜oes n˜ao trafegam

pelo servidor, ele n˜ao ´e capaz de garantir a qualidade dos dados. Por´em, apesar

da maior seguran¸ca em redes P2P centralizadas, o fator que mais diﬁculta o cresci-

mento dessa arquitetura ´e sua escalabilidade, j´a que a rede ﬁca restrita `a capacidade

do n´o central. Al´em disso, a rede ﬁca totalmente dependente da operabilidade desse

CAP

ITULO 3. REDES P2P 43

Figura 3.5: Arquiteturas de redes P2P: (a) Centralizada com busca

centralizada; (b) Descentralizada com busca desestruturada; (c)

H´ıbrida com busca descentralizada estruturada (Barcellos and Gas-

pary, 2006).

n´o. Mesmo que n´os auxiliares do n´o central sejam implantados, a rede ainda ter´a

problemas s´erios de escalabilidade, j´a que a capacidade de provimento de recursos

de um n´o ´e limitada. Com v´arios n´os auxiliares a rede se descaracteriza e deixa de

ser considerada uma rede centralizada. A utiliza¸c˜ao de cluster de servidores, como

no Napster, ´e uma ´otima solu¸c˜ao, mas torna a estrutura cara e com necessidade de

uma equipe para administr´a-los.

CAP

ITULO 3. REDES P2P 44

3.6.2 Redes P2P Descentralizadas

Redes P2P descentralizadas n˜ao devem possuir nenhum n´o com qualquer

diferen¸ca de funcionalidade dos demais, ou seja, cada n´o ´e igual ao outro do ponto

de vista de suas fun¸c˜oes no sistema. Este fato ajuda na escalabilidade do sistema,

que n˜ao necessita de pontos realizando fun¸c˜oes especiais como controle de acesso

ou busca de recursos. Outro ponto positivo ´e a tolerˆancia a falhas que esse modelo

possui, j´a que nenhum n´o ´e essencial ao sistema. Pode-se notar nesse esquema que

n˜ao h´a qualquer forma de hierarquia entre os n´os, j´a que um modelo hier´arquico

pressup˜oe controle dos n´os inferiores pelos n´os superiores. Modelos hier´arquicos

normalmente possuem facilidades de seguran¸ca. Em modelos hier´arquicos, os pontos

superiores realizam certas funcionalidades de seguran¸ca respons´aveis p or garantir

a seguran¸ca de toda a rede. Al´em disso, os n´os superiores podem monitorar as

a¸c˜oes dos n´os inferiores para que eles se comportem de maneira aceit´avel dentro do

sistema. As redes P2P descentralizadas tˆem sua seguran¸ca muito mais complexa

que redes hier´arquicas, j´a que, nessas redes, nenhum n´o pode ser capaz de garantir

a seguran¸ca. Esse mo delo ´e chamado de rede P2P pura. A Figura 3.5 (b) mostra

este tipo de arquitetura.

Podem-se destacar dois modelos de seguran¸ca para redes P2P descentrali-

zadas. No primeiro, a rede como um todo tenta se manter segura com a ajuda de

todos os n´os colaborando. Esse ´e um bom modelo, desde que a rede consiga mini-

mizar a¸c˜oes de n´os que, porventura, tentem corromper ou desvirtuar esse trabalho,

ou seja, esse modelo normalmente ´e vulner´avel a ataques internos, promovidos prin-

cipalmente por n´os inseridos na rede com o c´odigo do protocolo alterado para gerar

diversos ataques, tais como, inunda¸c˜ao de requisi¸c˜oes, respostas falsas, adultera¸c˜ao

de pacotes para que eles percorram mais n´os, etc. Para que o modelo de seguran¸ca

funcione, a rede deve ser capaz de identiﬁcar e ignorar n´os internos maliciosos. J´a

contra ataques externos `a rede, esse modelo funciona bem, j´a que ataques `a segu-

ran¸ca de um ´unico n´o na rede deve notiﬁcar tod a a rede contra a amea¸ca.

Outro modelo para seguran¸ca de redes P2P descentralizadas ´e quando cada

n´o tem sua pr´opria pol´ıtica de seguran¸ca. Um bom exemplo disso ´e o trabalho

CAP

ITULO 3. REDES P2P 45

(Kamvar et al., 2003). Nesse trabalho, cada n´o deﬁne o quanto pode e deseja

conﬁar nos outros n´os. Esse n´o s´o ser´a afetado por um problema de seguran¸ca se

conﬁar em um n´o malicioso. O problema desse modelo com rela¸c˜ao ao anterior ´e

que ele ´e menos eﬁciente contra ataques externos, embora seja bem mais eﬁciente

contra ataques internos.

3.6.3 Redes P2P com Supern´os

Supern´os podem ser uma solu¸c˜ao ao problema da escalabilidade das redes

P2P centralizadas. Se forem usados diversos supern´os em pontos est rat´egicos, uma

rede P2P pode crescer sem maiores problemas de escalabilidade. Apesar disso ser

um ponto positivo, existem fatores que comprometem esse modelo. Um fator im-

portante com rela¸c˜ao ao uso de supern´os ´e o controle d esse uso. Na rede Kazaa,

qualquer n´o pode se tornar um supern´o. Essa liberdade dada aos n´os da rede tem

diversas consequˆencias, tanto positivas quanto negativas. Um ponto positivo ´e que

os n´os se tornam mais autˆonomos para decidir sobre suas obriga¸c˜oes com a rede.

Outra vantagem ´e um ganho de desempenho no sentido de que, se existe controle,

necessariamente deve existir tamb´em uma troca de mensagens para que o controle

funcione. J´a um ponto negativo ´e que alguns n´os pouco capazes podem en carregar-

se de obriga¸c˜oes e diminuir o desempenho da rede, pois n´os com pouco poder de

processamento n˜ao conseguiriam atender `as obriga¸c˜oes em um tempo aceit´avel.

Quando existe um controle de acesso ao grupo de supern´os, uma s´erie de a¸c˜oes

devem ser tomadas. Uma delas ´e estabelecer as condi¸c˜oes que s˜ao submetidas aos

n´os para se tornar um supern´o. Isso demanda troca de mensagens entre os n´os,

consequentemente aumentando o tr´afego da rede. Outro ponto que pode ser levado

em conta ´e a localiza¸c˜ao geogr´aﬁca dos n´os. Se o controle levar em conta esse fator,

j´a estar´a em vantagem em rela¸c˜ao ao modelo anterior, pois se os n´os se tornam

supern´os por uma simples autoproclama¸c˜ao, podem ocorrer regi˜oes da rede que es-

tejam superlotadas de supern´os e outras sem nenhum supern´o ao redor. A Figura

3.5 (c) ilustra este tipo de rede.

CAP

ITULO 3. REDES P2P 46

3.7 Tipos de Busca em Redes P2P

A busca de recursos nas redes P2P pode ser feita de trˆes modos (Gupta,

2003). No primeiro, a busca centralizada, acontece quando um n´o central realiza

as buscas e armazena os dados necess´arios. Este modelo n˜ao existe em redes P2P

puras. O segundo ´e a desestruturada, a qual um n´o que busca determinado recurso

faz uma pergunta aos n´os mais pr´oximos e estes ou respondem aﬁrmativamente

ou repassam a pergunta a outros n´os. Nesse modelo a busca ´e mais simp les de

ser implementada, por´em pode se tornar menos efetiva e mais lenta, j´a que n´os

muito distantes tˆem diﬁculdades de se comunicarem. O outro modelo, chamado de

estruturado, ocorre quando uma rede P2P como um todo mant´em uma tabela hash

distribu´ıda, ou DHT (Distributed Hash Table), com a localidade dos recursos. Nessa

arquitetura, cada n´o armazena uma parte da DHT. Os n´os tamb´em s˜ao respons´aveis

por manter a DHT atualizada. Essa arquitetura ´e mais elaborada e exige maiores

cuidados com seguran¸ca. Apesar disso, se for bem utilizada, leva a uma melhor

utiliza¸c˜ao dos recursos d e uma rede P2P, caso n˜ao exceda na utiliza¸c˜ao da largura

de banda para opera¸c˜oes de manuten¸c˜ao da tabela.

3.7.1 Busca Centralizada

A busca centralizada caracteriza-se pela existˆencia de um n´o respons´avel

pelas buscas de todo o sistema. Quando algum n´o da rede deseja procurar por

um recurso ele encaminha um pedido de busca ao n´o central e este pesquisa se o

recurso existe e onde se encontra o recurso.

E importante diferenciar esse modelo de

busca com a arquitetura centralizada. Na arquitetura centralizada o n´o central n˜ao

´e respons´avel apenas por realizar as buscas do sistema. Por exemplo, em uma rede

P2P centralizada o n´o central presente pode realizar o controle de acesso ao sistema

e a rede pode realizar uma busca desestruturada. Nesse exemplo, a arquitetura ´e

centralizada, mas a busca n˜ao. Um exemplo de rede P 2P que utiliza este mecanismo

de busca ´e o Napster.

CAP

ITULO 3. REDES P2P 47

3.7.2 Busca Descentralizada Desestruturada

A busca descentralizada desestruturada se caracteriza por, quando algum

ponto do sistema deseja procurar algum dado na rede, o n´o faz uma pergunta a seus

n´os vizinhos. Se algum deles tiver o dado, responde ao requisitante. Se n˜ao tiver, os

n´os repassam a requisi¸c˜ao a outros n´os, sendo que esse pedido tem um valor ﬁnito de

n´os que deve percorrer. Esse valor ﬁnito serve para n˜ao propagar indeﬁnidamente

pedidos pela rede. Como uma rede P2P descentralizada normalmente n˜ao ´e capaz

de saber seu tamanho e organiza¸c˜ao estrutural, esse valor ﬁnito ´e necess´ario. Por´em,

isto acarreta numa perda de funcionalidade, pois dois n´os podem estar separados por

um valor muito alto de saltos que se tornam inalcan¸c´aveis um ao outro. Exemplo

de rede que utiliza esse tipo de busca ´e Gnutella v0.4.

3.7.3 Busca Descentralizada Estruturada

O outro tipo de b usca descentralizada ´e a busca estruturada, feita pelo uso

de uma tabela hash distribu´ıda. Essa tabela hash ´e dividida pela rede de forma

que, cada n´o, dependendo de sua coloca¸c˜ao no sistema e de seu identiﬁcador, ﬁca

respons´avel por uma parte dessa tabela. Quando um determinado recurso deve ser

colocado na tabela, o n´o possuidor do recurso deve notiﬁcar o n´o respons´avel por

armazenar a posi¸c˜ao em que esse recurso deve ser indexado. Se algum outro n´o

deseja requisitar o recurso, ele faz uma pesquisa na DHT para saber quem possui

o recurso. Como o algoritmo de busca na DHT ´e conhecido por todos os n ´os, ´e

mais r´apido para o requisitante encontrar o n´o que armazena a por¸c˜ao da DHT na

qual se deve encontrar as informa¸c˜oes do possuidor do recurso, j´a que a busca ´e

direcionada. Assim, o n´o requisitante d escobre onde est´a localizada a informa¸c˜ao

que deseja dentro da DHT. Este modelo tem a vantagem de proporcionar uma

busca direcionada aos r ecursos de uma rede P2P. Apesar disso, deve haver uma

colabora¸c˜ao total de cada n´o d a rede para o bom funcionamento do sistema. Se,

por exemplo, um n´o se recusa a responder `as requisi¸c˜oes sobre sua parte cab´ıvel da

DHT, os recursos nela listados estar˜ao inalcan¸c´aveis mesmo para os n´os vizinhos

ao detentor da informa¸c˜ao. O uso de DHT pode ser tamb´em encontrado em redes

CAP

ITULO 3. REDES P2P 48

P2P desestruturadas com supern´os. Os supern´os seriam respons´aveis pela DHT,

enquanto que os outros n´os apenas se encarregam de enviar as informa¸c˜oes `a DHT

e a utilizarem para buscas. Embora o uso de supern´os diminua a quantidade de n´os

em que a DHT est´a presente, isso n˜ao acarreta na mudan¸ca da pol´ıtica de seguran¸ca

da DHT. A rede eDonkey, Gnutella v0.6 e Kazaa utilizam este mecanismo de busca.

3.8 Firewalls versus Redes P2P

A escolha de servi¸cos web para o prot´otipo da rede P2PWSRep foi motivada

por dos fatores. O primeiro ´e a facilidade de implementar a interoperabilidade

com outras redes P2P, al´em de facilitar a extensibilidade do protocolo, sem muitos

impactos em vers˜oes anteriores. O segundo ´e o fato das redes P2P utilizando servi¸cos

web poderem atravessar elementos de prote¸c˜ao como Firewalls e Proxies. Um n´o

em uma rede interna n˜ao pode ser acessado por um n´o da rede externa. Para isso, as

conex˜oes tˆem que ser criadas de dentro para fora da intranet, devido `a necessidade

de realiza¸c˜ao de NAT (Network Address Translation) para que os pacotes gerados

por esses n´os acessem a Internet. Assim, o uso combinado d e ﬁrewalls e NAT acaba

resultando em uma especial diﬁculdade para a comunica¸c˜ao P2P. Segundo (Wilson,

2004), na maioria das redes internas, o protocolo HTTP ´e geralmente habilitado para

iniciar conex˜oes. Infelizmente, cada conex˜ao HTTP envia um pedido e aguarda a

resposta, sendo assim quando uma conex˜ao faz um pedido inicial de comunica¸c˜ao

ter´a que ﬁcar aberta at´e receber uma resposta. Embora o HTTP possa prover

mecanismos para enviar pedidos da rede interna, n˜ao provˆe a capacidade para os

n´os externos cruzarem o limite dos ﬁrewalls.

A ´unica forma que um n´o dentro de uma LAN (Local Area Network) possui

para resolver alguns destes problemas ´e sua capacidade para criar conex˜oes de rede

em um n´o fora da prote¸c˜ao de ﬁrewalls. N´os podem usar protocolos permitidos pelo

ﬁrewall para criar um t´unel para a rede externa (HTTP Tunneling). Por´em, se um

ﬁrewall ´e conﬁ gurado para negar todas as conex˜oes que partem da rede interna, a

comunica¸c˜ao do n´o se torna imposs´ıvel, mas, com um protocolo de rede que usa a

CAP

ITULO 3. REDES P2P 49

porta 80, j´a que um ﬁrewall, por padr˜ao, n˜ao tem como fazer o bloqueio.

Para solucionar este problema, um n´o de rota, como ´e chamado, dentro de

uma rede interna protegido por um ﬁrewall utiliza um n´o localizado fora da prote¸c˜ao

do mesmo, como mostrado na Figura 3.6. Qualquer n´o da Internet ao tentar se

comunicar com um n´o da LAN n˜ao conseguir´a, por restri¸c˜oes do ﬁrewall. Para

resolver o problema, o n´o 1 faz uma conex˜ao ao n´o 4, para manter uma conex˜ao.

Assim, as requisi¸c˜oes pod em ser enviadas para qualquer n´o da LAN utilizando o n´o

1 como rota de entrada e todas as mensagens direcionadas para os n´os internos s˜ao

liberadas para comunica¸c˜ao.

Figura 3.6: Travessia de ﬁrewall com HTTP Tunneling.

3.9 Seguran¸ca em Redes P2P com Reputa¸c˜ao

Nesta se¸c˜ao, trataremos de alguns ataques a que as redes P2P s˜ao suscet´ıveis.

O primeiro ataque ´e conhecido como whitewashing e apenas ocorre quando n´os

podem trocar sua identidade facilmente, o que ´e o caso de muitas redes P2P. Um n´o

pode deixar a rede e voltar em seguida com uma nova identidade, em uma tentativa

de se livrar de qualquer reputa¸c˜ao ruim que ele tenha acumulado. Se um n´o n˜ao

consegue distinguir um novo n´o de um antigo, ent˜ao whitewhashers podem causar

o colapso do sistema se nenhuma contramedida for tomada (Feldman et al., 2004).

Al´em disso, o n´o pode adquirir m´ultiplos identiﬁcadores para si, caracterizando

CAP

ITULO 3. REDES P2P 50

um segundo tipo de ataque, chamado de Sybil, conforme (Douceur, 2002). Isso

possibilita o n´o utilizar as v´arias identidades para agir de acordo com seus interesses.

O terceiro tipo de ataque ´e o de conluio contra sistemas de reputa¸c˜ao. Este

tipo de ataque ´e frequentemente efetivo, porque em sistemas de reputa¸c˜ao t´ıpicos,

um n´o deve consultar outros n´os sobre a reputa¸c˜ao de um terceiro. Se muitos n´os

est˜ao comprometidos, ent˜ao este grupo pode fornecer falso testemunho, no sentido

de aumentar a reputa¸c˜ao de um n´o malicioso ou de atacar um n´o ´ıntegro, diminuindo

a sua reputa¸c˜ao.

O quarto tipo de ataque ´e o de n´o traidor (Marti and Garcia-Molina, 2006).

Em tal ataque, um n´o se comporta adequadamente por um tempo de forma a

construir uma boa reputa¸c˜ao, e ent˜ao explora o sistema valendo-se da mesma. Este

ataque ´e especialmente efetivo quando os n´os ganham privil´egios `a medida que

conquistam reputa¸c˜ao. Um exemplo do ataque de traidor ´e quando um usu´ario no

eBay (eBay, 2006) constr´oi uma reputa¸c˜ao com muitas transa¸c˜oes de pequeno valor,

e ent˜ao lesa algu´em em uma transa¸c˜ao de grande valor. Em termos sistˆemicos, um

n´o traidor pode surgir n˜ao de uma mudan¸ca comportamental de um usu´ario, mas

de uma mudan¸ca no ambiente: por exemplo, uma m´aquina cliente perfeitamente

correta pode ser infectada com um v´ırus estilo Cavalo de Tr´oia, que ent˜ao poderia

aleatoriamente abusar da boa reputa¸c˜ao do n´o. A resistˆencia a esse tipo de ataque

pode ser aumentada usando a an´alise da hist´oria recente de um n´o (Feldman et al.,

2004).

Por ﬁm, a reputa¸c˜ao de um n´o ´e tipicamente usada na pol´ıtica de sele¸c˜ao

de um n´o com quem interagir. Segundo (Dumitriu et al., 2005), ´e caracterizado o

impacto de pol´ıticas de sele¸c˜ao entre respostas adotadas por n´os P2P que originam

buscas. S˜ao identiﬁcadas diversas pol´ıticas, dentre as quais incluem-se escolher o n´o

que anuncia a melhor capacidade. Sob o ponto de vista de ataques, a pior pol´ıtica

de escolha de um n´o ´e aquela que seleciona o n´o que se anuncia como o melhor. Por

exemplo, se uma informa¸c˜ao de desempenho ´e facilmente falsiﬁc´avel, uma busca s´o

ter´a sucesso quando nenhuma resposta for de um n´o malicioso, pois um n´o malicioso

sempre ser´a escolhido. Sistemas de reputa¸c˜ao n˜ao conseguem resolver esse problema

CAP

ITULO 3. REDES P2P 51

mesmo quando os erros do sistema de reputa¸c˜ao s˜ao m´ınimos. T´ecnicas baseadas

em aleatoriedade s˜ao efetivas para aumentar a resistˆencia de um sistema P2P a

ataques. Entretanto, aleatoriedade imp acta negativamente no desempenho quando

atacantes n˜ao est˜ao presentes.

3.10 Solu¸c˜oes de Redes P2P

Nas pr´oximas se¸c˜oes ser˜ao apresentadas duas redes P2P bem populares que

re´unem as p rincipais caracter´ısticas dos t´opicos abordados nas se¸c˜oes anteriores:

a rede Gnutella, que at´e hoje serve como base para a cria¸c˜ao de outras redes que

desejam caracter´ısticas de redes P2P puras, e a rede Napster, que atingiu uma marca

de milh˜oes de usu´arios no 2000.

3.10.1 Gnutella

E um sistema de compartilhamento de arquivos de topologia ad-hoc. Sua ar-

quitetura ´e descentralizada, isto ´e, pura. Seu mecanismo de busca ´e descentralizado

e desestruturado, sendo todos os n´os funcionalmente idˆenticos. Os n´os nessas redes

tamb´em s˜ao chamados serv ents, porque s˜ao servidores e clientes ao mesmo tempo e

as buscas por arquivos s˜ao realizadas atrav´es d e uma inunda¸c˜ao de escopo limitado,

utilizando um campo no cabe¸calho, chamado de TTL, que limita o n´umero de vezes

que o pacote ´e encaminhado (Buford et al., 2009). Os n´os que possuem o arquivo

solicitado respondem ao n´o que encaminhou a solicita¸c˜ao, sendo que a resposta `a

busca tamb´em segue o mesmo caminho da solicita¸c˜ao. O n´o requisitante ent˜ao es-

colhe um dos n´os que retornaram a resposta e faz o download diretamente deste n´o.

O Gnutella, pelo seu bom desempenho, e apesar de utilizar mecanismos de busca

por inunda¸c˜ao, consegue atender satisfatoriamente `as caracter´ısticas de desempen ho

das redes que seguem este modelo, considerando-se o tempo de resposta das buscas

de recursos.

A Figura 3.7 mostra um exemplo de arquitetura Gnutella, onde um n´o faz

uma inunda¸c˜ao para localizar um arquivo. Os n´os que n˜ao possuem a informa¸c˜ao

CAP

ITULO 3. REDES P2P 52

Figura 3.7: Rede Gnutella.

buscada reencaminh am a busca para seus vizinhos. Perceba que h´a setas com uma

barra, representando que a busca j´a atingiu a profundidade especiﬁcada. Uma vez

encontrado o recurso, o n´o requisitante faz download diretamente de um dos n´os

que responderam positivamente.

Vis˜ao Geral do Protocolo Gnutella v0.4

Um n´o X estabelece uma conex˜ao com o n´o Y , que j´a est´a conectado `a

rede. A conex˜ao se d´a da seguinte forma, o n´o X envia uma requisi¸c˜ao contendo a

string “GNUTELLA CONNECT/0.4/n/n” p ara estabelecer uma conex˜ao com o n´o

Y . O n´o Y pode aceitar a conex˜ao, enviando para o n´o X a string “GNUTELLA

OK/n/n”, ou recusar a conex˜ao, enviando qualquer resposta que n˜ao seja a que con-

tenha a string de aceita¸c˜ao de conex˜ao. Uma vez que o n´o X est´a conectado a rede,

ele pode se comunicar com outros n´os enviando e recebendo mensagens gnutella,

tamb´em chamadas de descritores. Cada descritor possui 22 bytes de cabe¸calho con-

sistindo dos seguintes campos: Descriptor ID (byte 0 a 15), Payload Descriptor (byte

16), TTL (byte 17), Hops (byte 18) e Payload Length (byte 19 a 22). O descriptor

ID ´e um identiﬁcador ´unico da mensagem na rede e tipicamente criado usando um

gerador randˆomico. O time to live (TTL) ´e o n´umero de vezes que a mensagem

ser´a encaminhada pelos n´os antes de ser exclu´ıda. Hops representa o n´umero de

vezes que a mensagem ser´a encaminhada entre os n´os. Cada vez que a mensagem ´e

encaminhada o TTL da mensagem ´e decrementado em um e o hops ´e incrementado

CAP

ITULO 3. REDES P2P 53

em um. O payload descriptor cont´em o c´odigo do tipo da mensagem. Os c´odigo

s˜ao 0x00 para Ping message, 0x01 para Pong message, 0x40 para Push message,

0x80 para Query message, 0x81 para Query Hit message. O payload length cont´em

o tamanho da mensagem que segue o cabe¸calho, isto ´e a carga ´util. Ent˜ao, o total

da mensagem ´e 22 bytes + o payload length.

Um n´o pode descobrir a informa¸c˜ao (endere¸co IP e n´umero de porta, n´umero

de recursos, etc.) sobre os outros n´os enviando uma mensagem Ping. Uma men-

sagem Pin g tem um payload length zero. Ao receber uma Ping message, um n´o ir´a

encaminh´a-la para todos os n´os diretamente ligados a ele, exceto o n´o que enviou a

mensagem. Ao mesmo tempo o n´o ir´a enviar uma mensagem Pong, com o mesmo

descriptor ID correspondente `a men sagem Ping, em resposta ao n´o que enviou a

mensagem. A mensagem Pong tem como conte´udo o n´umero de arquivos compar-

tilhados, o n´umero de kilobytes compartilhados, o end ere¸co IP e o n´umero da porta

de conex˜ao.

Enquanto as mensagens Ping e Pong s˜ao usadas para descobrir outros n´os

na rede, mensagens Query e Query

Hit s˜ao usadas para localizar recursos. Para

localizar um recurso, um n´o envia uma mensagem Query que cont´em como conte´udo

a velocidade de rede m´ınima exigida dos n´os, que possam conter o recurso e a string

que descreve o recurso requisitado. Similar ao processo de mensagem Ping, uma

mensagem Query ´e recebida por um n´o ´e encaminhada em broadcasting para todos

os n´os conectados diretamente a ele, exceto ao n´o que enviou a mensagem. As

mensagens Query s˜ao tamb´em sujeitas ao incremento do hop e decremento do TTL

para limitar a profundidade da busca. Cada mensagem ser´a replicada e p ropagada

na rede at´e que um n´o atenda a requisi¸c˜ao ou que o valor do TTL seja excedido

para todos os pacotes. Os n´os que s˜ao capazes de oferecer o recurso respondem com

a mensagem Query Hit. A mensagem Query Hit cont´em a informa¸c˜ao sobre o n´o

que compartilha o recurso buscado.

Mensagens Pong e mensagens Query Hit s˜ao roteadas pelo mesmo caminho

de volta por onde as mensagens Ping e Query passaram. Isto ´e feito atrav´es de um

registro mantido nos n´os por onde essas mensagens passaram atrav´es do descriptor

CAP

ITULO 3. REDES P2P 54

ID da mensagem e o payload descriptor do cabe¸calho correspondente. Quando

um n´o recebe uma mensagem de resposta, ele ir´a checar se ela foi gerada de um

Ping ou Query que ele encaminhou. S e o n ´o n˜ao ´e o destino, ele ir´a checar se foi

encaminhado um Ping ou Query que tem o descriptor ID. Se n˜ao houve um Ping

ou Query passando por ele, a mensagem ´e exclu´ıda, sen˜ao ela ser´a enviada para o

destino. Uma vez que um n´o destino recebe uma mensagem Query

Hit, gerada por

outro n´o, em resposta a sua mensagem Query, ele ir´a acessar o recurso usando o

protocolo HTTP.

3.10.2 Napster

Precursor em termos de compartilhamento de arquivos, o Napster foi a rede

P2P mais conhecida, principalmente devido a problemas legais, sendo que at´e hoje

´e tido como o principal disseminador do ideal das redes P2P. Apesar disso, o Naps-

ter vai contra os princ´ıpios das redes P2P pura, porque depende de um servidor

central para seu funcionamento. O Napster obteve enorme sucesso ao permitir o

compartilhamento de arquivos de m´usica, por´em o conte´udo publicado no Napster

era protegido por copyright e n˜ao poderia ser copiado por outros usu´arios, sendo

este o principal motivo de interrup¸c˜ao da sua rede P2P de uso aberto. Usu´arios que

ingressam na rede Napster oferecem conte´udo enviando informa¸c˜oes sobre arquivos

locais ao servidor central; opera¸c˜oes de busca s˜ao resolvidas no servidor, que re-

torna ao n´o requisitante uma lista de endere¸cos dos n´os disponibilizando o arquivo

procurado. O download do arquivo ent˜ao se d´a diretamente entre os n´os envolvidos,

sem sobrecarregar o servidor. A arquitetura do Napster est´a ilustrada na Figura

3.8 (Addison, 2002). Computadores d e usu´arios buscam informa¸c˜oes sobre arquivos

no diret´orio central e ent˜ao se comunicam com outros n´os diretamente para obter

os arquivos desejados. De acordo com estudos, a rede Napster chegou a contar com

mais de 50 milh˜oes de usu´arios em 2001 (OpenNap, 2008).

A arquitetura da rede Napster, apesar de usar um modelo centralizado, de-

monstrou que ´e poss´ıvel atingir um grau de escalabilidade grande, comprovado pelo

grande n´umero de usu´arios que a rede atingiu. Isso se deve principalmente ao tipo

CAP

ITULO 3. REDES P2P 55

Figura 3.8: Arquitetura do Napster (Addison, 2002).

de infraestrutura tecnol´ogica adotada na parte que se refere ao servidor central. Na

verdade o Napster possu´ıa v´arios servidores, conﬁgurados em cluster. Isso d´a ao

usu´ario a impress˜ao que existe uma ´unica entidade servidora, mas na verdade as

requisi¸c˜oes s˜ao distribu´ıdas para um dos membros do cluster. Isso torna um modelo

de rede P2P complexo de administrar e consideravelmente caro. Por´em, mostra a

simplicidade do protocolo de registro de n´os, de busca de recursos e download de

arquivos.

O funcionamento da rede Napster ´e bem simples. Tudo come¸ca com o registro

do n´o na rede. O registro ´e feito em um dos servidores de metadados. Cada servidor

tem capacidade para atender at´e 15.000 n´os simultaneamente. O n´o, ao se registrar

no servidor, recebe uma identidade e passa os dados dos recursos que compartilha

para o servidor. Cada vez que o cliente entra na rede, ele se conecta ao ser vidor e

atualiza v´arios dados, tais como, os recursos dispon´ıveis e o endere¸co IP corrente.

Um n´o quando necessita de um recurso, abre uma conex˜ao com o ser vidor e informa o

nome do recurso que est´a buscando. O servidor varre suas tabelas de metadados em

busca do recurso, acha os n´os que disp˜oem do mesmo e responde ao n´o requisitante.

O n´o recebe os dados que identiﬁcam os n´os que contˆem o recurso e os endere¸cos

IP correspondentes, ent˜ao se conecta diretamente ao n´o destino e faz o download

do arquivo. As redes P2P com este tipo de arquitetura tˆem uma baixa latˆencia

nas buscas, no caso do Napster o tempo de resposta diﬁcilmente ultrapassava 15

segundos (Addison, 2002).

CAP

ITULO 3. REDES P2P 56

3.11 Considera¸c˜oes Finais

O pontencial das redes P2P foi revelado nos ´ultimos anos pela grande de-

manda a esta tecnologia, principalmente na ´area de compartilhamento de recursos.

Esse sucesso se deve a diversas formas de projetar uma rede P2P, pela variedade de

arquiteturas, mecanismos de busca, transmiss˜ao de dados e aplica¸c˜oes que se ade-

quam a este modelo, permitindo que uma rede P2P seja desenvolvida considerando

as caracter´ısticas da aplica¸c˜ao. O crescimento e populariza¸c˜ao dessas redes gera

um tr´afego intenso na rede mundial de computadores ou nas redes lo cais onde elas

est˜ao presentes, e como qualquer sistema que se sobressai, desperta para cria¸c˜ao de

outras tecnologias que buscam prejudicar o funcionamento natural para o qual foi

proposto, seja para tirar maior vantagem ou simplesmente causar um desequil´ıbrio,

explorando falhas e criando mecanismos avan¸cados de ataques. Por´em, as redes

P2P tˆem evolu´ıdo para superar estes problemas. Assim, projetar sistemas que te-

nham como base as redes P2P exige que sejam revistas v´arias caractar´ısticas destas

redes e inseridos novos mecanismos que possam torn´a-las mais seguras e conﬁ´aveis,

mantendo seu desempenho.

Cap

ıtulo 4

Reputa¸c˜ao em Redes P2P

4.1 Introdu¸c˜ao

Estudos (Adar and Huberman, 2000) demonstraram que 70% dos usu´arios

integrantes de redes P2P s´o est˜ao interessados em utilizar o sistema sem cooperar,

isto ´e, n˜ao compartilham os recursos que possuem ou que obtiveram na rede. Outro

dado que foi mostrado na pesquisa ´e que 50% das respostas `as buscas s˜ao retornadas

por apenas 1% dos n´os integrantes da rede. Estudos tamb´em recentes de (Liang et

al., 2005) mostraram que 50% dos arquivos mais populares disponibilizados na rede

FastTrack (FastTrack, 2008) s˜ao corrompidos. Esses dados demonstram que devem

existir mecanismos que possam ajudar a manter um n´ıvel de colabora¸c˜ao entre os

n´os participantes da rede e informa¸c˜oes sobre os recursos que est˜ao disponibilizados

pelos mesmos.

4.2 Tipos de Reputa¸c˜ao

4.2.1 Reputa¸c˜ao de N´os

Os mecanismos de reputa¸c˜ao aumentam a conﬁabilidade das redes P2P

porque permitem que os n´os possam avaliar o comportamento dos demais e ent˜ao

deﬁnir de onde obter informa¸c˜oes conﬁ´aveis. Os mecanismos propostos na lite-

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 58

ratura sugerem construir e manter a reputa¸c˜ao de um n´o atrav´es de avalia¸c˜oes

enviadas por outros n´os `a medida que o mesmo interage na rede, bem como validar

a informa¸c˜ao para saber se a mesma ´e integra. Este tipo de reputa¸c˜ao ´e muito

semelhante `a utilizada para classiﬁca¸c˜ao de usu´arios de sites de com´ercio eletrˆonico

como eBay (Ebay, 2008) e Mercado Livre (MercadoLivre, 2008), onde os membros

s˜ao classiﬁcados levando em considera¸c˜ao o n´umero de produtos vendidos, n´umero

de produtos comprados, prazo de entrega, qualiﬁca¸c˜ao dos compradores, qualidade

dos produtos, etc. Todos os membros podem ser vendedores e compradores, sendo

que as transa¸c˜oes s˜ao feitas diretamente entre eles. O sistema gera um percentual

que permite aos clientes escolherem os vendedores pelo escore, mas mesmo assim

ﬁcam livres para negociar com novos vendedores, fazendo com que estes vendedores

elevem seus escores. Os vendedores tamb´em podem, com base na reputa¸c˜ao do

comprador, rejeitar o pedido de transa¸c˜ao de compra devido a uma reputa¸c˜ao ne-

gativa. A Figura 4.1 mostra a reputa¸c˜ao utilizada pelo site Mercado Livre. Perceba

que existem v´arias m´etricas para avaliar um vendedor: o n´umero de transa¸c˜oes,

qualiﬁca¸c˜oes positivas e negativas e tempo que o vendedor ´e membro do sistema.

Tamb´em s˜ao utilizados estere´otipos para permitir que os usu´arios assimilem visual-

mente e rapidamente a reputa¸c˜ao de um vendedor.

Figura 4.1: Reputa¸c˜ao de um vendedor do site Mercado

Livre.

O site de vendas americano eBay tem um mecanismo igual ao do site brasileiro

Mercado Livre. Ao ﬁnal de uma transa¸c˜ao de compra e venda s˜ao realizadas

avalia¸c˜oes das partes. O produto tamb´em pode ser avaliado da mesma forma que o

vendedor e comprador. A Figura 4.2 mostra como ´e realizado o c´alculo de repu ta¸c˜ao

do eBay. O n´umero de transa¸c˜oes positivas ´e dividido pelo somat´orio de todas as

transa¸c˜oes ocorridas em um per´ıodo de um ano, desconsiderando-se as avalia¸c˜oes de

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 59

um mesmo membro na mesma semana. O resultado em percentual ´e a reputa¸c˜ao

do participante.

Figura 4.2: Mecanismo de c´alculo de reputa¸c˜ao do eBay.

A reputa¸c˜ao de n´os em uma rede P2P pode ser gerenciada de trˆes formas. A

primeira ´e com os n´os executando o algoritmo de reputa¸c˜ao e mantendo as m´etricas

de todos os outros n´os que ele j´a interagiu ou pretende interagir. Esse modelo ´e

descentralizado. A segunda abordagem ´e atrav´es de um elemento central mantendo

uma base de informa¸c˜ao de todos os n´os. Os n´os individualmente enviam seus dados

para este servidor e o mesmo executa um algoritmo para identiﬁcar a reputa¸c˜ao do

n´o. A terceira e ´ultima abordagem ´e um modelo h´ıbrido, onde as informa¸c˜oes

s˜ao processadas e armazenadas localmente. Neste caso, o servidor central tamb´em

recebe dados dos n´os e os disponibiliza.

E um modelo mais complexo, pois envolve

uma gerˆencia de reputa¸c˜ao tanto nos n´os, quanto em um servidor central, havendo

a necessidade de manter uma integridade dos dados em ambos os locais.

Os sistemas de reputa¸c˜ao permitem manter um hist´orico de transa¸c˜oes pra-

ticadas por ou com um n´o da rede P2P. Esse hist´orico possibilita que o n´o possa

manter um grau de conﬁan¸ca no n´o com o qual deseja interagir e que possa responder

as requisi¸c˜oes de reputa¸c˜ao a respeito deste n´o com base na sua experiˆencia. Sabe-se

que a maioria dos n´os que integram uma rede P2P usufruem mais dos recursos do

que os disponibilizam. N´os de uma rede P2P que n˜ao colab oram podem ser divididos

em ego´ıstas e maliciosos. O objetivo de ego´ıstas ´e usufruir o m´aximo do sistema

P2P contribuindo com o m´ınimo de recursos compartilhados. Esse comportamento ´e

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 60

muito comum nas redes P2P que n˜ao tˆem uma gerˆencia de reputa¸c˜ao. Em contraste,

o objetivo dos maliciosos ´e causar mal a um dos n´os ou ao sistema como um todo.

N´os maliciosos est˜ao dispostos a empregar recursos para ataque, tal como injetar

arquivos corrompidos, o que n˜ao ocorre com n´os ego´ıstas, responder requisi¸c˜oes

com adultera¸c˜ao da resposta original, simular juntamente com outros n´os, atrav´es

de intera¸c˜oes que n˜ao existiram, uma reputa¸c˜ao forjada, dentre muitas outras.

Existem diferentes abordagens para se incentivar n´os a colaborarem. Desta-

cam-se duas classes gerais de mecanismos de incentivo. O primeiro s˜ao os baseados

em conﬁan¸ca e reputa¸c˜ao, amparados na reciprocidade, isto ´e, cada n´o possui uma

reputa¸c˜ao associada, que parte de um estado inicial e ´e constru´ıda ao longo da

vida do mesmo, com base em suas intera¸c˜oes com os outros. Essa informa¸c˜ao de

reputa¸c˜ao pode inﬂuenciar a decis˜ao de um n´o sobre os parceiros de sua pr´oxima

intera¸c˜ao, buscando reciprocidade. Por exemplo, um n´o pode preferir solicitar um

servi¸co a outro que t em lhe respondido correta e eﬁcientemente as ´ultimas requi-

si¸c˜oes, desconsiderando certos n´os que tˆem lhe retornado arquivos com conte´udo

corrompido. Reciprocidade ´e obtida em um sistema P2P atrav´es de um sistema de

gerenciamento de reputa¸c˜ao. Os termos reputa¸c˜ao e conﬁan¸ca est˜ao intimamente

ligados (Grandison and Sloman, 2000).

Conﬁan¸ca ´e a base para permitir que um n´o use ou manipule recursos do

outro. O grau de conﬁan¸ca em uma opera¸c˜ao tem rela¸c˜ao inversamente proporcional

ao seu risco. Sobre a rela¸c˜ao entre os termos, um sistema de gerˆencia de reputa¸c˜ao

determina a reputa¸c˜ao de n´os baseado no hist´orico das a¸c˜oes dos mesmos e permite

que sejam formadas opini˜oes sobre o grau de conﬁan¸ca acerca de outros. As rela¸c˜oes

de conﬁan¸ca podem ser de um para outro (conﬁar em um n´o para troca de recursos),

de um para v´arios (conﬁar em um conjunto de n´os com os quais recursos podem

seguramente ser trocados), de v´arios para um (nesse caso, todos os n´os d evem

se reportar a um s´o n´o, em que conﬁam) e de v´arios para v´arios (quando um

grupo conﬁa em outro). Uma das propriedades mais importantes de conﬁan¸ca ´e a

transitividade: se A conﬁa em B e B conﬁa em C, ent˜ao ´e poss´ıvel que A conﬁe

(pelo menos limitadamente) em C.

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 61

A conﬁan¸ca de um n´o em outro ´e baseada, naturalmente, na vis˜ao do n´o

sobre a reputa¸c˜ao do outro. Os sistemas de reputa¸c˜ao tˆem em comum trˆes partes

principais: coleta de informa¸c˜oes, determina¸c˜ao de escore e ranqueamento e a¸c˜oes

de resposta (Marti and Garcia-Molina, 2006). A coleta de informa¸c˜oes est´a rela-

cionada ao esquema de identiﬁca¸c˜ao usado, `as fontes de informa¸c˜ao, `a agrega¸c˜ao de

informa¸c˜oes e `a pol´ıtica adotada para n´os que ingressam no sistema sem hist´orico

associado. Um dos problemas fundamentais de sistemas de reputa¸c˜ao ´e garantir

a validade das informa¸c˜oes prestadas por outros n´os. Portanto, ´e natural que na

determina¸c˜ao do escore de reputa¸c˜ao de um estranho, experiˆencias anteriores do

pr´oprio n´o sejam valorizadas em rela¸c˜ao `a opini˜ao de outros.

O segundo esquema de incentivo, baseado em com´ercio, inclui mecanismos

de micropagamento e esquemas de troca de recursos. Para isso, os n´os, para obter

recursos compartilhados, tˆem que pagar por eles atrav´es de uma moeda virtual que

existe na rede P2P ou oferecer seus recursos em troca dos que ele obteve ou pretende

obter, isto ´e, uma esp´ecie de escambo (Righi et al., 2004).

4.2.2 Reputa¸c˜ao de Recursos

Com o objetivo de minimizar as a¸c˜oes dos n´os ego´ıstas e de n´os maliciosos

nas redes P2P, ser´a ab ordado outro pr oblema mais relacionado aos arquivos com-

partilhados pelos n´os. Para um n´o, quando um recurso ´e encontrado e baixado, ´e

feita uma veriﬁca¸c˜ao do seu conte´udo. Se n˜ao houve detec¸c˜ao de altera¸c˜ao no hash

do arquivo, ent˜ao ele ´e dado como ´ıntegro e a reputa¸c˜ao do n´o que disponibilizou

o arquivo ´e incrementada. Por´em, este arquivo pode conter conte´udo perigoso, tal

como spyware, cavalo de tr´oia ou outros tipos de amea¸cas. Assim, a reputa¸c˜ao apli-

cada somente a n´os da rede P2P n˜ao ´e totalmente segura, o ideal ´e fazer o uso de

reputa¸c˜ao tanto em n´ıvel dos n´os quanto dos recursos presentes na rede. Esse pro-

blema relacionado aos recursos ´e conhecido por dissemina¸c˜ao de conte´udo polu´ıdo

em redes P2P. Fazendo uma compara¸c˜ao com sistemas reais, utilizados nos sites de

com´ercio eletrˆonico, isso equivale `a avalia¸c˜ao do produto pelos compradores. Assim,

antes de fechar a compra, o interessado pode fazer u ma veriﬁca¸c˜ao se h´a opini˜oes

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 62

negativas sobre o produto que o mesmo est´a pretendendo comprar. A presen¸ca

de recursos corrompidos nas redes P2P causa um grande desperd´ıcio de largura de

banda, j´a que atualmente o tr´afego gerado pelos sistemas P2P responde por grande

parte do tr´afego na Internet.

Cada um dos v´arios sistemas P2P utilizados atualmente possui um determi-

nado n´ıvel de polui¸c˜ao de recursos. Esses n´ıveis podem levar essas redes ao desuso,

assim como aconteceu com muitas outras que foram substitu´ıdas por redes P2P que

ofereciam melhores resultados na obten¸c˜ao de recu rsos ´ıntegros. No trabalho de

(Costa et al., 2005) foram avaliados d ois tipos de redes: moderadas e n˜ao mode-

radas. Nas redes moderadas, existe a presen¸ca de um agente moderador humano

capaz de interferir nos arquivos que est˜ao sendo compartilhados na rede, como no

caso da rede BitTorrent (BitTorrent, 2008). As redes n˜ao moderadas constituem os

demais tipos de redes. Al´em disso, foi avaliado qual o efeito da polui¸c˜ao da rede,

no espalhamento, quando os usu´arios do sistema recebem incentivos para apagar

arquivos polu´ıdos.

A rede BitTorrent ´e uma das redes P2P moderadas mais utilizadas atual-

mente. Percebe-se que quando uma rede P2P tem a participa¸c˜ao dos usu´arios para

identiﬁcar os recursos corrompidos, a mesma mant´em um n´ıvel de polui¸c˜ao aceit´avel

pelos usu´arios. Por´em, nota-se que a maioria dos usu´arios s˜ao negligentes, pois ape-

sar de detectar os recursos corrompidos, n˜ao os apagam. Isso acaba contribuindo

para a queda do desempenho da rede. O mecanismo utilizado pelo BitTorrent con-

siste na publica¸c˜ao de informa¸c˜oes sobre os arquivos disponibilizados na rede. Os

usu´arios que decidem obter este arquivo receber˜ao peda¸cos uns dos outros, seguindo

uma pol´ıtica “olho por olho, dente por dente” (tit-for-tat), o que implica que os n´os

s´o ir˜ao ceder recursos para outros n´os que tˆem tendˆencia a cooperar. Os moderado-

res consistem de usu´arios que disponibilizam o arquivo de metadados que cont´em

informa¸c˜oes suﬁcientes para um participamente da rede obter o arquivo buscado.

Esse moderador pode apagar o metadado caso perceba que aquele arquivo est´a cor-

rompido (Costa et al., 2005). Existem sites na Internet que disponibilizam arquivos

bem recentes de metadados para fontes (peda¸cos) de arquivos disponibilizados na

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 63

rede BitTorrent.

4.3 Sistemas Baseados em Com´ercio e Reputa¸c˜ao

Neste trabalho, ser˜ao apresentadas cinco abordagens para diminuir proble-

mas das redes P2P segundo ( Barcellos and Gaspary, 2006). V´arios desses trabalhos

foram utilizados como base para a deﬁni¸c˜ao do protocolo P2PWSRep. Os dois

primeiros s˜ao baseados em com´ercio, o sistema PPay e redes de Escambo. Por´em,

esses trabalhos diminuem apenas o alastramento de n´os caronas (freeriders), mas

n˜ao evitam que a qualidade dos recursos trocados seja considerada no que se refere

`a corru p¸c˜ao de dados e infec¸c˜ao por v´ırus. Os trˆes ´ultimos trabalhos s˜ao baseados

em reputa¸c˜ao. S˜ao os sistemas EingenTrust, XRep e PeerTrust. Esses sistemas

utilizam algoritmos que controlam o grau de conﬁan¸ca de um n´o ou recurso com-

partilhado atrav´es de m´etricas baseadas nas transa¸c˜oes dos n´os, que reﬂetem seu

comportamento.

4.3.1 PPay

Sistemas baseados em com´ercio tamb´em podem ser chamados de modelo

de micropagamentos. S˜ao respons´aveis por controlar o ﬂuxo de recursos entre os

participantes da rede P2P. Baseiam-se na ideia de compra de recursos, onde um n´o

apenas adquire acesso aos recursos que deseja, se pagar por ele. Para isso, existe

uma esp´ecie de moeda, um “dinheiro virtual” adquirido pelos participantes da red e

P2P. Essa moeda tem um ´unico motivo: evitar que n´os caronas possam usufruir dos

recursos dispon´ıveis sem pagar p or eles. Isso estimula n´os que n˜ao queiram investir

a deixar a rede. Os recursos podem ter valores diferentes, dependendo do tipo e at´e

mesmo do n´o que o hospeda. Por´em, isso pode gerar uma “inﬂa¸c˜ao virtual”, quando

poucos n´os possuem o recurso e passam a cobrar caro por eles. Percebe-se que n˜ao h´a

uma preocupa¸c˜ao em determinar a qualidade do recurso compartilhado e tamb´em

n˜ao h´a como o participante que adquiriu um recurso reclamar ou divulgar uma

negocia¸c˜ao frustrada, aﬁm d e evitar que outros participantes possam ser v´ıtimas de

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 64

novos “golpes”.

Muitos esquemas de micropagamentos se baseiam em conﬁan¸ca e s˜ao geren-

ciados por um n´o central, chamado de intermedi´ario. Ele ´e respons´avel por gerenciar

contas de usu´arios, distribuir e trocar dinheiro envolvido nas transa¸c˜oes e manter a

seguran¸ca do sistema. Al´em disso, para que os pagamentos ocorram, o intermedi´ario

dever´a estar dispon´ıvel para participar em cada transa¸c˜ao. A desvantagem desse

esquema ´e a limita¸c˜ao que este n´o pode impor ao sistema, comprometendo sua esca-

labilidade e desempenho, no caso de grande n´umero de participantes e transa¸c˜oes.

O proto colo PPay (Yang and Garcia-Molina, 2003) tem um esquema de mi-

cropagamento onde os usu´arios obt´em “dinheiro virtual” para utilizar em transa¸c˜oes

com outros participantes da rede. Cada recurso que um n´o deseja adquirir tem um

valor estipulado por seu propriet´ario. O PPay requer somente um intermedi´ario

envolvido quando n´os desejam abrir ou fechar suas contas, e em alguns casos, para

realizar opera¸c˜oes em nome de outros n´os. Neste protocolo, os n´os s˜ao respons´aveis

pelo seu pr´oprio dinheiro, sem necessidade do intermedi´ario.

Para garantir a seguran¸ca, o sistema utiliza certiﬁcados associados ao di-

nheiro virtual. Esses certiﬁcados s˜ao obtidos quando um usu´ario obt´em um cr´edito

virtual e limitam quanto de dinheiro ele est´a autorizado a utilizar. O esquema de

micropagamento consiste em que as transa¸c˜oes sejam sustentadas por baixos valo-

res trocados por usu´arios bem intencionados, mas, se um u su´ario mal-intencionado

desejar fazer um ataque, por mais que ele possa ter adquirido cr´editos de forma

normal, ele gastar´a rapidamente seu dinheiro virtual, no caso de um ataque de

DDoS (Distributed Denial of Service), por exemplo.

4.3.2 Sistemas de Escambo

Os sistemas baseados em Escambo, assim como o modelo de micropagamen-

tos, tamb´em s˜ao respons´aveis por controlar o ﬂuxo de recursos entre os participantes

da rede P2P, por´em ele se baseia na ideia de troca de recursos, onde um n´o apenas

adquire acesso aos recursos que deseja se possuir outros recursos para disponibilizar

no ambiente colaborativo. Dessa forma, participantes que s˜ao parasitas (aqueles que

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 65

n˜ao colaboram com os demais) ter˜ao acesso restrito `as vantagens que a rede propor-

ciona e, ent˜ao, s˜ao encorajados a sa´ırem da condi¸c˜ao de caronas para desfrutarem

integralmente a comunidade P2P.

A diminui¸c˜ao dos n´os caronas propiciada pelo Escambo gera uma s´erie de

vantagens aos sistemas colaborativos. O n´umero reduzido de n´os caronas possibilita

uma melhor distribui¸c˜ao do tr´afego da rede, p ois os recursos ﬁcam mais espalhados

na topologia. A disponibilidade dos recursos na rede melhora, j´a que um maior

n´umero de informa¸c˜oes est´a dispon´ıvel para os usu´arios leg´ıtimos. Em alguns pro-

tocolos P2P, ob tˆem-se vantagens tamb´em no tempo de resposta das solicita¸c˜oes.

Al´em desses benef´ıcios t´ecnicos, o baixo n´umero de participantes caronas consegue

tornar a comunidade P2P mais justa e harmoniosa, colaborando socialmente para

o progresso do sistema.

O modelo de escambo modiﬁca a estrutura normal das redes P2P para al-

can¸car os seus objetivos. Nele, um n´o que recebe uma solicita¸c˜ao por um recurso

que det´em, deve antes de permitir o acesso, veriﬁcar se o n´o requisitante tamb´em

disp˜oe de recursos na rede P2P. O Escambo deve oferecer uma sistem´atica que pos-

sibilite reconhecer quais n´os s˜ao caronas e quais n˜ao o s˜ao. A pol´ıtica de controle

de acesso aos recursos informa quais as condi¸c˜oes que o n´o cliente deve suprir para

acessar os recursos do n´o servidor. Divide-se em trˆes categorias:

• Tamanho total dos recursos compartilhados (medido em bytes);

• N´umero de arquivos oferecidos;

• Tipo de recursos disponibilizados.

O Escambo utiliza um modo simpliﬁcado de micropagamento. O micropaga-

mento introduz o conceito de pagamento pelo acesso a um recurso ou pedido de

atividade. Esse pagamento pode ser de dois tipos:

• O n´o servidor n˜ao recebe nenhum valor e o cliente paga-o geralmente com

trabalho (c´alculo de uma tarefa computacional complexa);

• O cliente utiliza algum sistema de pagamento, por exemplo, d inheiro virtual,

para pagar o detentor dos recursos, o qual tem acesso ao montante recebido.

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 66

No caso espec´ıﬁco do Escambo, o n´o cliente paga o servidor atrav´es da oferta

de recursos na rede P2P. A reputa¸c˜ao nos sistemas colaborativos P2P tradicionais

informa quais participantes da rede s˜ao honestos ou bons servidores de recursos.

A reputa¸c˜ao dos n´os ´e adquirida atrav´es das experiˆencias dos p r´oprios membros

da rede e das trocas de informa¸c˜oes de reputa¸c˜ao entre os pares que conﬁam um

no outro (Damiani et al., 2002). O conceito de reputa¸c˜ao encontrado no Escambo

distancia-se do mencionado anteriormente, pois a reputa¸c˜ao de cada n´o est´a asso-

ciada `a quantidade e qualidade do material que ele disponibiliza na rede P2P e n˜ao

depende da opini˜ao de outros participantes do sistema (o n´o ´e o ´unico respons´avel

por sua reputa¸c˜ao). As arquiteturas P2P, e nesse caso, especialmente o Escambo,

devem possuir mecanismos para evitar que o sistema de reputa¸c˜ao seja en ganado. O

Escambo deve estar precavido contra usu´arios que alteram as mensagens passadas

entre os n´os em benef´ıcio pr´oprio.

4.3.3 EigenTrust

EigenTrust (Kamvar et al., 2003) ´e um algoritmo para gerˆencia de repu-

ta¸c˜ao para sistemas de compartilhamento de arquivos. Cada n´o possui associada

uma reputa¸c˜ao global, que ´e baseada no hist´orico de uploads de arquivos. A repu-

ta¸c˜ao global de um n´o i ´e calculada com base nos ´ındices de reputa¸c˜ao atribu´ıdos

localmente a i por cada n´o j , k, l , etc. e pesados de acordo com a pr´opria reputa¸c˜ao

daqueles n´os. No estudo realizado, a abordagem ajudou a reduzir o n´umero de

arquivos corrompidos compartilhados. Os valores de conﬁan¸ca atribu´ıdos por um

n´o s˜ao normalizados. Isso ´e necess´ario para evitar que um n´o subverta o sistema

atribuindo reputa¸c˜oes arbitrariamente altas a outros n´os maliciosos, inﬂuenciando

o valor de reputa¸c˜ao global em um ataque combinado. Em um n´o i, a reputa¸c˜ao do

n´o j ´e normalizada dividindo-se o valor de reputa¸c˜ao de j em i pelo somat´orio de

todos os valores de reputa¸c˜ao que i mant´em. Ou seja, todos os valores de reputa¸c˜ao

atribu´ıdos por um n´o situam-se entre 0 e 1. As desvantagens dessa normaliza¸c˜ao

s˜ao duas. Primeiro, n ˜ao h´a distin¸c˜ao entre n´os novos e m´a reputa¸c˜ao. Segundo, os

valores s˜ao relativos e, portanto, n˜ao podem ser interpretados de forma absoluta.

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 67

Por exemplo, se em i dois n´os j e k possuem o mesmo valor de reputa¸c˜ao r, ent˜ao

se sabe que aos olhos de i , j e k s˜ao igualmente reput´aveis, mas n˜ao se sabe se

ambos tˆem boa ou m´a reputa¸c˜ao. Para agregar os valores normalizados computados

por cada n ´o, um n´o i pergunta aos seus n´os vizinhos, contidos em sua tabela de

n´os, sobre os valores de reputa¸c˜ao que eles atribu´ıram a um n´o k , e usa uma m´edia

ponderada com as reputa¸c˜oes deles p ara calcular a conﬁan¸ca de i em k .

Para aumentar o conhecimento, um n´o pode pedir a opini˜ao dos vizinhos

dos vizinhos, e assim por diante, recursivamente, at´e atingir a rede inteira. N˜ao ´e

poss´ıvel permitir que cada n´o seja respons´avel por calcular e reportar sua pr´opria

reputa¸c˜ao. Portanto, a reputa¸c˜ao de um n´o ´e calculada por mais de um n´o na rede,

e armazenada em outro n´o. M´ultiplos n´os computam o escore de um n´o, e uma

pesquisa DHT ´e usada para encontrar tais n´os. O algoritmo proposto evita que um

n´o saiba a identidade do n´o para o qual ele est´a calculando a conﬁan¸ca, de forma

que um n´o malicioso n˜ao possa aumentar artiﬁcialmente a reputa¸c˜ao de outro n´o

malicioso. N´os que entram no sistema n˜ao podem escolher qual a posi¸c˜ao em que

entram no espa¸co de IDs, evitando que um n´o retorne exatamente na posi¸c˜ao do

n´o respons´avel por calcular a sua reputa¸c˜ao.

Valores globais de reputa¸c˜ao podem ser usados ent˜ao para isolamento de

n´os maliciosos. Um n´o usa a reputa¸c˜ao dos candidatos como pol´ıtica de sele¸c˜ao

de onde ir´a baixar um arquivo. Entretanto, uma escolha desse tipo concentra as

requisi¸c˜oes nos n´os com reputa¸c˜ao mais alta e n˜ao permite que outros n´os corretos

adquiram reputa¸c˜ao. A proposta ´e usar um esquema onde o n´o ´e selecionado de

forma semi-aleat´oria, com inﬂuˆencia da reputa¸c˜ao. Segundo (Marti and Garcia-

Molina, 2006), EigenTrust oferece uma solu¸c˜ao puramente descentralizada, mas usa

uma identidade fraca, tornando-o suscet´ıvel a ataques de whitewashing, que ´e um

tipo de artif´ıcio de que um n´o se utiliza, saindo da rede e entrando novamente

para obter um novo identiﬁcador, pois isso permite que a m´a reputa¸c˜ao anterior

seja perdida. Al´em disso, (Cheng and Friedman, 2005) indicam que EigenTrust ´e

suscet´ıvel ao ataque Sybil (Douceur, 2002), uma vez que um n´o malicioso pode criar

uma subpor¸c˜ao inteira do grafo da rede. O ataque Sybil permite que um ´unico n´o

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 68

falsiﬁque a existˆencia de v´arias identidades dentro da rede. Este tipo de ataque ´e

complexo de ser resolvido em um sistema amplamente distribu´ıdo, mas pode ser

controlado atrav´es da existˆencia de autoridades certiﬁcadoras.

4.3.4 XRep

Em (Damiani et al., 2002), prop˜oe-se um esquema para gerˆencia de repu-

ta¸c˜ao para a rede Gnutella. Diferentemente de outras abordagens, a reputa¸c˜ao de

n´os ´e combinada com a reputa¸c˜ao de recursos, aumentando a resistˆencia contra

ataques do tipo Sybil. Reputa¸c˜oes s˜ao cooperativamente gerenciadas atrav´es de um

algoritmo distribu´ıdo de polling de maneira a reﬂetir a vis˜ao da comunidade sobre o

risco de download e uso de um recurso. O protocolo proposto pelos autores estende

o p rotocolo de bu sca do Gnutella com passos e mensagens adicionais, facilitando

a atrib ui¸c˜ao, o compartilhamento e a combina¸c˜ao de reputa¸c˜oes de n´os e recursos.

O princ´ıpio b´asico do esquema ´e o protocolo XRep, uma extens˜ao ao protocolo

de busca do Gnutella. No Gnutella, um n´o inicia uma busca enviando mensagens

(QUERY ) aos seus vizinhos; todos os n´os que encontram o objeto requisitado re-

tornam mensagens de resposta atrav´es do mesmo caminho pelo qual vieram. Ap´os

receber m´ultiplas respostas positivas (mensagens QUERY

HIT ), o n´o pergunta a

outros n´os opini˜oes sobre os n´os que ofereceram o recu rso buscado. O processo de

polling ´e composto de cinco fases, mostradas na Figura 4.3 e descritas abaixo:

1. Busca de recursos - Nesta fase, nas mensagens QUERY HIT que s˜ao re-

tornadas pelos n´os que detˆem um ou mais objetos que satisfazem a busca,

acrescenta-se um digest para cada objeto referenciado na mensagem;

2. Sele¸c˜ao de recurso e voto por polling - O n´o requisitante escolhe o melhor

n´o dentre aqueles que parecem satisfazer sua busca (ou seja, que responderam).

Para tanto, o n´o envia uma mensagem a seus vizinhos contendo uma requisi¸c˜ao

de voto sobre a reputa¸c˜ao dos objetos oferecidos e dos n´os que os oferecem.

Estas mensagens s˜ao implementadas usando mensagens convencionais QUERY

e contˆem uma chave p´ublica a ser usada na cifragem da resposta, para proteger

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 69

a integridade e a conﬁdencialidade das respostas. N´os que recebem a pergunta

veriﬁcam seus reposit´orios de experiˆencia e respond em;

3. Avalia¸c˜ao dos votos - O n´o descarta mensagens adulteradas e os autores

indicam que um n´o faz tamb´em um agrupamento e combina¸c˜ao de votos que

s˜ao oriundos de um mesmo n´o para evitar ataques Sybil. Ap´os o descarte, o

n´o seleciona um conjunto de votantes e envia uma outra mensagem de polling

(TRUEVOTE) direto a cada um para que respondam conﬁrmando seus votos,

obrigando n´os atacantes a usarem IPs reais;

4. Veriﬁca¸c˜ao de melhor n´o - O n´o mais conﬁ´avel ´e contactado para veriﬁcar

se ele realmente disp˜oe do recurso;

5. Download do recurso - O n ´o requisitante contacta o n´o que disp˜oe do

recurso e solicita o download do mesmo, depois disso ele veriﬁca a integridade

do recurso recebido atrav´es do digest e atualiza seu reposit´orio de experiˆencias.

4.3.5 PeerTrust

PeerTrust (Xiong and Liu, 2004) ´e um framework de reputa¸c˜ao que inclui

um modelo de conﬁan¸ca adaptativo para quantiﬁcar e comparar a conﬁan¸ca de

n´os baseado em um sistema de transa¸c˜oes com feedback, e uma implementa¸c˜ao

descentralizada de tal modelo em uma rede P2P. As d uas caracter´ısticas principais

do PeerTrust s˜ao a deﬁni¸c˜ao de trˆes parˆametros b´asicos de conﬁan¸ca e dois fatores

adaptativos na computa¸c˜ao do grau de conﬁan¸ca em um n´o e a deﬁni¸c˜ao de uma

m´etrica geral de conﬁan¸ca para combinar esses parˆametros. Os fatores que um n´o

leva em considera¸c˜ao no c´alculo de n´ıvel de conﬁan¸ca no PeerTrust s˜ao:

• Feedback recebido de out ros n´os, n a forma d e um valor;

• Escopo do feedback, tal como o n´umero de transa¸c˜oes que um n´o possui com

outro;

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 70

Figura 4.3: Fases do protocolo XREP.

• Fator de credibilidade para um n´o que forneceu o feedback, diferenciando a

qualidade do feedback recebido de outros n´os de acordo com a conﬁan¸ca nos

mesmos;

• Fator de contexto de transa¸c˜ao para diferenciar as mais importantes das menos

importantes, associando pesos `as transa¸c˜oes;

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 71

• Fator de contexto da comunidade para tratar caracter´ısticas relacionadas `a

comunidade e vulnerabilidades peculiares, por exemplo, criar um incentivo `a

submiss˜ao de feedback sobre outros n´os.

Para implementa¸c˜ao desse modelo de conﬁan¸ca, cada n´o possui um gerente

de conﬁan¸ca e um localizador de dados. O primeiro ´e respons´avel pela submiss˜ao de

feedback e avalia¸c˜ao de conﬁan¸ca atrav´es de um banco de dados com um segmento

da base global. J´a o localizador de dados serve para aloca¸c˜ao e localiza¸c˜ao de dados

de conﬁan¸ca na rede P2P (overlay) .

O gerente executa duas fun¸c˜oes principais. A primeira ´e a submiss˜ao do

feedback para rede atrav´es do localizador, que roteia a informa¸c˜ao para outros n´os.

A segunda fun¸c˜ao ´e a avalia¸c˜ao do n´ıvel de conﬁan¸ca de um determinado n´o, que

´e executado em dois passos. Primeiro, ele coleta informa¸c˜oes de conﬁan¸ca sobre o

n´o em quest˜ao atrav´es do localizador, e ent˜ao calcula o valor de conﬁan¸ca. Dois

m´etodos s˜ao p ropostos para c´alculo do n´ıvel de conﬁan¸ca: c´alculo dinˆamico de

conﬁan¸ca (DTM, Dynamic Trust Computation), que emprega informa¸c˜oes recentes

obtidas sob demanda de todos os outros n´os da rede e a computa¸c˜ao aproximada

de conﬁan¸ca (ATC, Approximate Trust Computation), que ´e mais eﬁciente, por´em

menos precisa, pois calcula a conﬁan¸ca por informa¸c˜oes presentes em uma cache.

Cada n´o mant´em uma cache contendo os valores de conﬁan¸ca fornecidos por outros

n´os com que ele recentemente se comunicou, sendo que isso s´o ´e preciso quando

ele n˜ao encontra um n´o em sua cache. Essa ´e uma caracter´ıstica interessante do

protoloco PeerTrust, pois diminui bastante o tr´afego de requisi¸c˜oes na rede.

Quando a reputa¸c˜ao de um n´o ´e baseada na m´edia cumulativa de suas

transa¸c˜oes de seu tempo de vida, e um n´o adquiriu uma s´olida reputa¸c˜ao, as

transa¸c˜oes atuais tˆem pouco impacto na reput a¸c˜ao e, portanto um n´o possui menor

incentivo para se comportar de forma honesta. Um n´o pode, mesmo assim, oscilar

entre um comportamento honesto e desonesto de forma a manter uma reputa¸c˜ao

razo´avel, apesar de agir incorretamente em determinadas transa¸c˜oes. Os aut ores

prop˜oem um algoritmo simples de janela de tempo deslizante. Os valores de con-

ﬁan¸ca s˜ao computados de forma global e recente, e ent˜ao s˜ao comparados. A ideia

CAP

ITULO 4. REPUTAC¸

AO EM REDES P2P 72

´e que uma boa reputa¸c˜ao seja dif´ıcil de atingir, leve tempo para constru ir, por´em

possa ser destru´ıda rapidamente ap´os poucas transa¸c˜oes incorretas. Para evitar

problemas de seguran¸ca relativos ao armazenamento e transmiss˜ao das informa¸c˜oes

de conﬁan¸ca, o PeerTrust emprega criptograﬁa com chaves p´ublicas e privadas.

Cada n´o ´e obrigado a ter um par de chaves e assinar suas mensagens de feedback

com sua chave privada, e fornecer a chave p´ublica, garantido a integridade e au-

tenticidade. O identiﬁcador de cada n´o ´e um digest de sua chave p´ublica, ou sua

pr´opria chave p´ublica.

4.4 Considera¸c˜oes Finais

Neste cap´ıtulo, foram apresentados os conceitos b´asicos de reputa¸c˜ao em

redes P2P e os principais sistemas que aplicam essas t´ecnicas. Sabe-se que quanto

mais s˜ao criados sistemas reﬁnados para controle de reputa¸c˜ao, mais os atacantes

se adaptam a estes ambientes. Reunir todas as solu¸c˜oes que possam tornar a rede

segura e garantir recursos ´ıntegros ´e um grande desaﬁo, al´em de adicionar risco no

comprometimento do desempenho da rede com excesso de execu¸c˜ao de mecanismos

de controle. Apesar das contribui¸c˜oes apresentadas por cada um dos sistemas serem

validas, a an´alise da natureza da aplica¸c˜ao no qual ser˜ao aplicadados tamb´em deve

ser consideradas.

Cap

ıtulo 5

Protocolo de Reputa¸c˜ao

P2PWSRep

Os protocolos de reputa¸c˜ao em redes P2P tˆem um papel importante na

seguran¸ca da rede. Esses protocolos s˜ao respons´aveis por auxiliar os n´os a encontrar

a fonte mais conﬁ´avel de um determinado recurso que desejam obter. Normalmente

os protocolos baseiam-se em experiˆen cias anteriores para calcular um valor num´erico

que represente um valor de conﬁan¸ca com rela¸c˜ao a um determinado n´o possuidor

do recurso ou ao pr´oprio recurso. Dentro da rede, o protocolo P2PWSRep, proposto

neste trabalho, far´a o gerenciamento de reputa¸c˜ao de n´os e recursos, sendo projetado

com a tecnologia de servi¸cos web para possibilitar uma melhor integra¸c˜ao com outras

tecnologias e a extensibilidade do seu c´odigo, al´em de permitir que o tr´afego da rede

P2P possa passar por ﬁrewalls e outros elementos de prote¸c˜ao.

5.1 Introdu¸c˜ao

O P2PWSRep ´e um protocolo de gerenciamento de reputa¸c˜ao dos n´os da

rede P2PWS

e de seus recursos compartilhados. Os recursos podem ser de diversos

Neste trabalho, o termo P2PWS refere-se `a rede que segue a deﬁni¸c˜ao da arquitetura de

servi¸cos web para redes P2P e o termo P2PWSRep ´e referente ao protocolo de reputa¸c˜ao utilizado

por redes P2P, orientadas a servi¸cos ou n˜ao.

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 74

tipos, depen dendo da natureza da aplica¸c˜ao P2P. Assim, para uma rede de comparti-

lhamento de arquivos, existem arquivos de dados, m´usicas, v´ıdeos; para uma rede

de relacionamento, existe o perﬁl do integrante; para uma grade de computadores,

tem-se a capacidade de processamento, etc. O P2PWSRep ser´a capaz de controlar

qualquer um destes recursos, devido ao seu projeto permitir sua extensibilidade e

portabilidade para diversas aplica¸c˜oes P2P.

O P2PWSRep tem uma arquitetura descentralizada, isto ´e, n˜ao h´a um servi-

dor central para autenticar usu´arios ou auxiliar na busca de recursos na rede. Essas

duas caracter´ısticas adicionam dois problemas, que s˜ao: como um n´o ir´a ingressar

na rede e como um recurso compartilhado ser´a localizado. O primeiro problema ´e

causado pela caracter´ıstica dinˆamica das redes P2P, j´a que os n´os entram e saem da

rede overlay de forma n˜ao previs´ıvel e pode ser solucionado por uma estrat´egia de

pong caching, onde uma resposta ao Ping leva consigo uma lista de n´os vizinhos com

endere¸cos pr´e-conﬁgurados para que o n´o possa ingressar na rede com um conheci-

mento m´ınimo de alguns n´os. O segundo problema pode ser contornado utilizando

uma estrat´egia chamada cega, onde a consulta ´e encaminhada para o maior n´umero

de n´os poss´ıveis, sem levar em considera¸c˜ao consultas pr´evias.

O protocolo P2PWSRep se baseia no protocolo Gnutella vers˜ao 0.4, mas suas

interfaces foram deﬁnidas para funcionar em qualquer arquitetura de rede P2P. O

motivo desta escolha ´e validar seu funcionamento em uma arquitetura totalmente

desestruturada, sem qualquer mecanismo de otimiza¸c˜ao de ingresso e busca de re-

cursos. Assim, pode-se observar como o protocolo ir´a funcionar com problemas

j´a conhecidos dessas redes, tais como, comprometimento da largura de banda e

escalabilidade, quando a rede possui milhares de n´os.

O mecanismo de roteamento das mensagens ´e similar ao Gnutella, conhecido

como inunda¸c˜ao, onde uma mensagem ´e enviada para todos os vizinhos exceto o que

originou a mensagem. Esta forma de encaminhamento ´e chamada de cega e gera um

itenso tr´afego na rede. O n´umero de vezes que as mensagens ser˜ao encaminhadas

depende do valor de um campo de cabe¸calho TTL (time to live), que impede que

uma mensagem seja encaminhada na rede indeﬁnidamente. Em uma estrat´egia

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 75

guiada uma consulta ´e encaminhada com base em similaridade, isto ´e, toda vez que

uma mensagem for enviada, o n´o analisa e procura todos os n´os que j´a responde-

ram a consultas parecidas, ent˜ao envia a mensagem para estes n´os. Esta est rat´egia

apresenta uma redu¸c˜ao consider´avel do n´umero de mensagens na rede.

A p roposta de deﬁnir um protocolo de reputa¸c˜ao para redes P2P foi motivado

pelo fato da maioria das redes P2P existentes n˜ao possu´ırem mecanismos efetivos

para evitar a presen¸ca de n´os ego´ıstas e maliciosos, bem como restri¸c˜oes para barrar

ou detectar a inser¸c˜ao de conte´udo corrompido. A elimina¸c˜ao desses problemas e

controle de uma s´erie de ataques, que foram mencionados neste trabalho, sendo os

mais comuns o whitewashing, sybil e ataque do traidor, al´em de incompatibilidades

de opera¸c˜oes e metadados dessas redes, fez com que o prot´otipo da rede P2PWSRep

fosse totalmente port´avel para todas as aplica¸c˜oes que desejem integr´a-lo. Por

exemplo, caso um site de vendas queira utilizar o controle de reputa¸c˜ao do protocolo

P2PWSRep, ent˜ao poder´a, atrav´es da interface de servi¸cos web do protocolo fazˆe-lo,

j´a que o protocolo n˜ao ´e voltado especiﬁcamente ao conte´udo que ´e disponibilizado,

mas `a qualidade de quem oferece e do que ´e oferecido. Para possibilitar que o

protocolo possa ser facilmente adaptado para suportar novos ataques, e utilizado

por diversos tipos de aplica¸c˜oes P2P, a tecnologia de servi¸cos web foi utilizada para

facilitar tal integra¸c˜ao.

A incompatibilidade refere-se aos metadados das diferentes redes P2P, diﬁ-

cultando a reutiliza¸c˜ao d e recursos, e por vezes, a comunica¸c˜ao entre estas redes.

Por isso, os metadados foram propostos de tal forma que facilitem a integra¸c˜ao,

sem necessidade de elementos intermedi´arios, como gateways, diminuindo assim o

volume de arquivos duplicados na rede, mas mantendo os identiﬁcadores de cada

um, j´a que utilizam mecanismos diferentes de gera¸c˜ao de identiﬁcadores.

Dois fatores contribu´ıram para a escolha de uma infraestrutura baseada em

servi¸cos web: o crescente n´umero de aplica¸c˜oes que utilizam essa tecnologia, fa-

cilidade de conﬁgura¸c˜ao sem que haja muitas interven¸c˜oes por parte dos admi-

nistradores de rede, j´a que o tr´afego das requisi¸c˜oes passa atrav´es de elementos de

prote¸c˜ao, tais como ﬁrewalls, proxies, IPS (Intrusion Prevent System), etc., pois

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 76

os pacotes HTTP est˜ao liberados na maioria dos mesmos, al´em da simplicidade da

infraestrutura orientada a servi¸cos e de suas requisi¸c˜oes. Al´em disso, a utiliza¸c˜ao

desta tecnologia proporciona a interoperabilidade com outros servi¸cos, oferecendo

portabilidade para a aplica¸c˜ao e uma ﬂexibilidade para que a mesma seja esten-

dida, apenas agregando-se novos servi¸cos web. Os metadados da infraestrutura

ser˜ao escritos em XML. Isso facilitar´a a integra¸c˜ao com outras ferramentas de com-

partilhamento e at´e mesmo com outras infraestruturas orientadas a servi¸cos.

5.2 Descri¸c˜ao da Arquitetura P2PWSRep

5.2.1 Modelagem dos Casos de Uso

As funcionalidades b´asicas do protocolo P2PWSRep est˜ao representadas

nos casos de uso que se seguem. Atrav´es dos mesmos, tem-se uma vis˜ao geral do

funcionamento e o papel desempenhado por cada n´o no sistema. Os casos de uso

est˜ao divididos em trˆes categorias: Caso de Uso Ingressar na Rede, Caso de Uso

Realizar Pesquisa de Recursos, Caso de Uso de Atualizar Reputa¸c˜ao.

O primeiro caso de uso, Ingressar na Rede P2P, est´a apresentado na Figura

5.1. Nota-se que ele executa trˆes outros casos de u so para realizar toda a opera¸c˜ao.

Tudo come¸ca com um n´o que pretende entrar na rede. Assim, ele deve contactar um

n´o que j´a faz parte da mesma, chamado de anﬁtri˜ao, passando seus dados. Os dados

podem incluir informa¸c˜oes d e capacidade (que ser˜ao veriﬁcadas), disponibilidade de

recursos compartilhados, como quantidade e volume em kilobytes.

Ao receber os dados do n´o interessado em participar da rede, ´e gerado um

identiﬁcador atrav´es de um algoritmo de gera¸c˜ao de n´umeros randˆomicos, SHA-1

(Secure Hash Algorithm). O identiﬁcador ´e chamado de peerID e passa a servir como

uma identidade ´unica do n´o em toda rede. O identiﬁcador ´e transferido para o novo

n´o, juntamente com a tabela de n´os vizinhos do n´o anﬁtri˜ao. A tabela ´e chamada

de TabPeer e seus campos s˜ao basicamente o identiﬁcador de cada n´o conhecido e

seu endere¸co corrente. Como s˜ao utilizados servi¸cos web para comunica¸c˜ao, ent˜ao

este endere¸co ´e representado por uma url para o servi¸co. Ao peerID ´e associado um

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 77

carimbo de tempo para permitir que se conhe¸ca quando o n´o ingressou na rede. Ao

ﬁnal das etapas, o n´o j´a faz parte da red e P2P e todas as vezes que o n´o se conectar

`a rede, ele envia para seus vizinhos seu peerID para infomar que est´a ativo. Isso

possibilita a seus vizinhos medir disponibilidade do n´o. Segundo (Stallings, 2007), a

possibilidade de duplica¸c˜ao de um identiﬁcador gerado por um algoritmo de n´umeros

aleat´orios com chave de 160 bits ´e muito improv´avel, sendo suﬁcientemente seguro

para uma rede P2P.

Figura 5.1: Caso de uso de ingresso na rede

O Caso de Uso Realizar Pesquisa de Recursos ´e o que executa mais opera-

¸c˜oes, e ´e mostrado na Figura 5.2. Inicialmente, o n´o interessado em um recurso

faz uma pesquisa na rede P2P. A pesquisa ´e enviada para todos os n´os vizinhos

contidos em sua TabPeer que est˜ao on-line, atrav´es de uma mensagem que cont´em

a descri¸c˜ao do recurso buscado (string) em seu cabe¸calho, al´em de outros dados do

protocolo que ser˜ao detalhados nas pr´oximas se¸c˜oes.

A Figura 5.3 mostra o roteamento das men sagens da rede P2PWS. As setas

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 78

Figura 5.2: Caso de uso de busca de recursos

cont´ınuas representam as requisi¸c˜oes de busca e as setas tracejadas a resposta da

requisi¸c˜ao de busca. O n´o E inicia uma busca pelo arquivo rock. Uma mensagem ´e

gerada com a string de busca e TTL igual a 3, al´em de identiﬁca¸c˜ao do n´o de origem,

timestamp, id da mensagem e outras informa¸c˜oes. A mensagem ´e enviada a todos os

n´os ligados diretamente a ele. Os n´os B e C respondem positivamente. Note-se que

o n´o B envia a mensagem de resposta pelo mesmo caminho que recebeu a requisi¸c˜ao,

isto ´e, atrav´es do n´o A. As mensagens de A-D, C-D e D-B s˜ao descartadas por c´opia

duplicada.

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 79

Figura 5.3: Roteamento das mensagens na rede P2PWS.

Ao receber a resposta dos n´os que contˆem os recursos, o n´o que iniciou a busca

tamb´em iniciar´a a obten¸c˜ao da reputa¸c˜ao dos n´os e recursos dispon´ıveis. Ap´os ter

a reputa¸c˜ao dos n´os e dos recursos, ´e realizado um ranqueamento dos recursos en-

contrados, o qual ´e mostrado ao usu´ario, como se vˆe na Figura 5.4. O usu´ario, ao

escolher o recurso que pretende fazer o download, ´e feita uma veriﬁca¸c˜ao de capaci-

dade do n´o fornecedor. Essa veriﬁca¸c˜ao tem como objetivo avaliar a disponibilidade

do n´o em atender a requisi¸c˜ao, para que n˜ao venha a sobrecarreg´a-lo. O n´o estando

apto a atender, o download do arquivo ent˜ao ´e iniciado. Percebe-se, no Caso de Uso

da Figura 5.2, que h´a um estere´otipo << extend >> mostrando que nem sempre

o download ´e realizado por problemas de capacidade do n´o fornecedor, no entanto,

estat´egias de enﬁleiramento podem ser empregadas para diminuir a sobrecarga do

fornecedor e atender futuramente a requisi¸c˜ao.

Por ´ultimo, ap´os o download do recurso, ´e realizado o Caso de Uso Atualizar

Reputa¸c˜ao, apresentado na Figura 5.6. A atualiza¸c˜ao ´e realizada positivamente caso

o download ocorra com sucesso, isto ´e, sem interrup¸c˜ao, mas mesmo que o arquivo

baixado n˜ao tenha tido problemas na transmiss˜ao, ´e veriﬁcada a integridade do

arquivo. Para isso, ´e gerado um hash do mesmo e iniciada uma consulta `a rede,

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 80

Figura 5.4: Obten¸c˜ao da reputa¸c˜ao de um n´o da rede.

similar `a busca de reputa¸c˜ao de n ´os e recursos. Logo os n´os que conhecem o recurso,

ir˜ao responder com o c´odigo do arquivo para aquele n´o. A Figura 5.5 mostra o

download sendo realizado diretamente do n´o escolhido. Por´em, antes do download

´e realizada uma requisi¸c˜ao ao n´o, que veriﬁca sua capacidade de atendimento da

requisi¸c˜ao.

Existe uma tabela espec´ıﬁca para reputa¸c˜ao dos recursos (tabResourceRepu-

tation). Isso possibilita que nas pr´oximas buscas de reputa¸c˜ao do recurso, o mesmo

seja identiﬁcado como conte´udo polu´ıdo. Para cada entrada desta tabela, ir´a existir

o identiﬁcador do n´o, o identiﬁcador do recurso e o c´odigo de erro. Esse c´odigo de

erro informa se o arquivo ´e corrompido, n˜ao autˆentico, com v´ırus ou verme, etc.

Uma notiﬁca¸c˜ao ´e enviada ao n´o que forneceu o arquivo para que ele possa remover

o arquivo de seu reposit´orio de arquivos compartilhados. A reputa¸c˜ao do n´o que

forneceu o recurso tamb´em ´e decrementada, j´a que o mesmo foi negligente em deixar

um recurso n˜ao ´ıntegro na rede.

At´e o momento, a identiﬁca¸c˜ao dos recursos n˜ao havia sido mencionada.

Cada recurso possui um identiﬁcador ´unico, chamado resourceID, gerado por um

algoritmo de hash, SHA-1, com um tamanho de chave 160 bits. O mecanismo de

gera¸c˜ao ´e o mesmo utilizado para gerar o peerID.

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 81

Figura 5.5: Download realizado diretamente do n´o escolhido

Figura 5.6: Caso de uso de gerenciamento de reputa¸c˜ao

5.3 Metadados

Para a realiza¸c˜ao do gerenciamento de reputa¸c˜ao, dados referentes aos n´os,

recursos e outras informa¸c˜oes s˜ao necess´arios. Agora, ser´a apresentada a modelagem

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 82

dos dados necess´arios ao funcionamento do p rotocolo P2PWSRep. Cada n´o cont´em

cinco tabelas, sendo duas para controle dos n´os e recursos compartilhados, duas

para controle da reputa¸c˜ao dos n´os e controle da reputa¸c˜ao dos recursos presentes

na rede e uma quinta tabela ´e u sada para guardar informa¸c˜oes pertinentes ao n´o, tais

como seu identiﬁcador, descri¸c˜ao, localiza¸c˜ao, informa¸c˜oes para controle de valor de

hops adaptativo, reputa¸c˜ao conhecida atrav´es de outros n´os na rede, localiza¸c˜ao dos

metadados de n´os e recursos, data do ingresso na rede, etc.

5.3.1 Metadados de N´os

Os metadados dos n´os s˜ao informa¸c˜oes para controle dos n´os e da reputa¸c˜ao.

S˜ao tabelas que n˜ao possuem um n´umero muito grande de dados, somente de seus

vizinhos, para que as buscas realizadas localmente pelo n´o nestas tabelas n˜ao possam

comprometer o desempenho do protocolo. S˜ao trˆes as tabelas que armazenam dados

dos n´os. A Tabela 5.1 - Tabela de N´os (tabPeer), armazena informa¸c˜oes sobre os

n´os vizinhos, isto ´e, os n´os que se ligam diretamente ao pr opriet´ario da tabela.

Nome do Campo Descri¸c˜ao

peerID Identiﬁcador gerado por uma fun¸c˜ao hash. O algoritmo

utilizado para gera¸c˜ao da chave ´e o SHA-1, com

um hash de 160 bits.

peerUrl Endere¸co de conex˜ao do servi¸co.

E dado atrav´es do

IP corrente e o port type do servi¸co. O endere¸co IP

utiliza a vers˜ao IPv4.

joiningDate Data do ingresso na rede. Utilizado para veriﬁcar

desde quando o n´o est´a presente na rede.

E importante para determina¸c˜ao da conﬁabilidade do n´o,

bem como sua disponibilidade.

protoVersion Vers˜ao do protocolo P2PWSRep.

Tabela 5.1: Tabela de n´os.

A Tabela 5.2, Tabela de Reputa¸c˜ao de N´os, ´e referente aos metadados dos

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 83

n´os, ´e chamada de tabPeerReputation, armazena as informa¸c˜oes necess´arias para

controle de reputa¸c˜ao dos n´os presentes na rede. A tabela cont´em apenas n´os que

j´a interagiram com o propriet´ario da tabela. Cada n´o possui sua tabela de reputa¸c˜ao.

Nome do Campo Descri¸c˜ao

peerID Identiﬁcador do n´o conhecido.

satTrans N´umero de transa¸c˜oes satisfat´orias com este n´o.

unsatTrans N´umero de transa¸c˜oes insatisfat´orias com este n´o.

previousRep Valor da reputa¸c˜ao, para o n´o buscado, obtida

anteriormente. Isto possibilita que este valor

seja utilizado para considerar a evolu¸c˜ao do

n´o com rela¸c˜ao `a reputa¸c˜ao atual.

Tabela 5.2: Tabela de reputa¸c˜ao dos n´os.

A Tabela 5.3, Tabela de Conﬁgura¸c˜oes (tabSettings), armazena as informa¸c˜oes

de conﬁgura¸c˜ao dos n´os, contendo dados importantes para o funcionamento dos

mesmos e da pr´opria rede.

Nome do Campo Descri¸c˜ao

peerID Identiﬁcador do n´o.

nodeName Nome do n´o (32 caracteres).

description Descri¸c˜ao do n´o. (64 caracteres).

location localiza¸c˜ao do n´o (pa´ıs).

reputation Reputa¸c˜ao recente do n´o. Este dado ´e obtido de outros

n´os e n˜ao pode ser atribu´ıdo ou calculado pelo pr´oprio n´o.

Tabela 5.3: Tabela de conﬁgura¸c˜ao do n´o.

O campo reputation tem como ﬁnalidade fazer com que o usu´ario conhe¸ca

sua rep uta¸c˜ao na rede. O processo de obten¸c˜ao da reputa¸c˜ao para o pr´oprio n´o ´e

o mesmo que ´e realizado para busca de reputa¸c˜ao de qualquer outro n´o, podendo

este valor ser atualizado toda vez que o n´o se conecta na rede ou periodicamente.

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 84

5.3.2 Metadados de Recursos

Os metadados dos recursos, assim como dos n´os, armazenam dados referentes

aos recuros compartilhados na rede e dados necess´arios para controle da reputa¸c˜ao

pelo protocolo P2PWSRep. S˜ao duas as tabelas, a primeira ´e a tabResource, que

armazena informa¸c˜oes sobre os recursos que o n´o compartilha, sendo sua apresentada

na Tabela 5.4.

Nome do Campo Descri¸c˜ao

resourceID Identiﬁcador do recurso gerado por uma fun¸c˜ao hash.

O tamanho do hash ´e de 160 bits, gerado atrav´es do

algoritmo SHA-1.

name Nome do recurso na rede.

description Descri¸c˜ao do recurso.

resourceCount Contador de acesso para o recurso. Pode ser utilizado

para fornecer estat´ısticas dos recursos mais buscados na

rede.

Tabela 5.4: Tabela de recursos.

A Tabela 5.5 - Tabela de Reputa¸c˜ao de Recursos (tabResourceReputation)

armazena a reputa¸c˜ao dos recursos. Ela ´e semelhante a uma lista negra de recur-

sos presentes na rede, s´o que de forma descentralizada, onde cada n´o mant´em a

reputa¸c˜ao de recursos.

E importante salientar que o protocolo P2PWSRep ´e distribu´ıdo, assim o

gerenciamento da reputa¸c˜ao de n´os e recursos ´e realizado por cada n´o, tendo em

suas tabelas valores que n˜ao necessariamente s˜ao iguais em toda rede, pois n˜ao h´a

uma sincroniza¸c˜ao de dados das tabelas entre os n´os.

5.4 O Protocolo P2PWSRep

Nesta se¸c˜ao ser´a descrito o protocolo P2PWSRep, com detalhes do rotea-

mento de mensagens e do c´alculo de reputa¸c˜ao. Cada n´o possui uma tabela do

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 85

Nome do Campo Descri¸c˜ao

resourceID Identiﬁcador do recurso.

peerID Identiﬁcador do n´o que cont´em o recurso.

errorType Tipo de erro do recurso:

1 - recurso corrompido;

2 - recurso cont´em v´ırus ou verme;

3 - recurso adulterado;

4 - recurso inexistente na origem.

Tabela 5.5: Tabela de reputa¸c˜ao de recursos.

hist´orico das transa¸c˜oes satisfat´orias (satTrans) e insatisfat´orias (unsatTrans) com

os demais n´os. Na infraestrutura proposta, a tabela armazena apenas o somat´orio

dessas transa¸c˜oes, sendo que n˜ao h´a informa¸c˜ao temporal de cada uma delas. Para

que o comportamento da reputa¸c˜ao do n´o com rela¸c˜ao ao tempo seja considerado,

ser´a armazenada para cada n´o a ´ultima reputa¸c˜ao obtida. Esse valor ser´a impor-

tante para o m´etodo que ser´a aplicado para o c´alculo da reputa¸c˜ao, j´a que ser´a

utilizada uma s´erie temporal, a m´edia ponderada exponencial.

A Tabela 5.2 (Reputa¸c˜ao de N´os) ´e chamada de tabPeerReputation. Cada

linha da tabela mostra o n´o que j´a forneceu dados compartilhados e o n´umero de

transa¸c˜oes que foram completadas com sucesso e as que falharam por diversos mo-

tivos, tais como: interrup¸c˜ao da conex˜ao, baixa qualidade de conex˜ao, arquivo n˜ao

encontrado, etc. O proto colo P2PWSRep n˜ao considera o contexto da transa¸c˜ao,

apenas avalia se ela foi completada ou n˜ao. Para cada n´o tamb´em ´e guardado o

valor da ´ultima reputa¸c˜ao obtida da rede, no campo previousRep. Esse dado ´e in-

teressante no c´alculo da reputa¸c˜ao atual em rela¸c˜ao com sua m´edia hist´orica. Caso

n˜ao exista este valor, isto ´e, o n´o nunca teve troca de dados com o requisitante,

ent˜ao ele n˜ao ser´a considerado no c´alculo.

Quando um n´o faz a pesquisa de um recurso, recebe a listagem de todos os

n´os que cont´em o recurso e sua localiza¸c˜ao. A rede segue o princ´ıpio do anonimato

dos n´os, j´a que ´e utilizado um identiﬁcador espec´ıﬁco, que n˜ao revela quem ´e quem

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 86

dentro da rede. Essa identiﬁca¸c˜ao ´e feita atrav´es do identiﬁcador peerID, obtido

uma ´unica vez, no momento do ingresso na rede.

E interessante destacar que o

anonimato do n´o n˜ao ´e real, sendo tamb´em chamado de pseudoanonimato, j´a que

alguns dados s˜ao imposs´ıveis de ocultar. Um exemplo ´e o endere¸co IP que o n´o est´a

utilizando na conex˜ao.

A busca ´e desestruturada, sendo baseada no protocolo Gnutella v0.4. As

requisi¸c˜oes de buscas s˜ao enviadas para todos os vizinhos. Cada requisi¸c˜ao leva

consigo uma string com a descri¸c˜ao do recurso buscado e um n´umero de vezes que

a requisi¸c˜ao deve ser encaminhada. Em cada n´o que a requisi¸c˜ao chega, este valor

´e decrementado e, quando atingir o valor zero, a requisi¸c˜ao ´e removida da rede. A

resposta ´e enviada pelo mesmo caminho que a requisi¸c˜ao de busca percorreu. Isto

´e poss´ıvel devido a forma de roteamento das mensagens, que ´e realizada da mesma

forma do protocolo Gnutella v0.4. Cada n´o gu arda o identiﬁcador da requisi¸c˜ao

de busca. Quando uma resposta chega ao n´o, ele veriﬁca se houve a passagem

dessa requisi¸c˜ao; se houve, a requisi¸c˜ao ´e encaminhada ao pr´oximo n´o em dire¸c˜ao

ao destino, caso contr´ario ela ´e exclu´ıda. Isso evita que requisi¸c˜oes falsas sejam

inseridas na rede e que haja um aumento do n´umero de respostas devido `a inunda¸c˜ao

natural de redes com estrat´egia cega.

Localizados os recursos, o pr´oximo passo ´e obter a reputa¸c˜ao dos n´os que

possuem os recursos. Assim, o n´o requisitante envia para todos os n´os que ele

possui na sua tabela de n´os uma requisi¸c˜ao da reputa¸c˜ao dos n´os que possuem o

recurso desejado. Essa requisi¸c˜ao ´e encaminhada para todos os n´os em profundidade

e por inunda¸c˜ao. O n´umero de encaminhamentos ´e controlado atrav´es dos campos

hops e TTL, contidos no cabe¸calho da requisi¸c˜ao.

Uma alternativa para o mecanismo de envio de mensagens do protocolo

P2PWSRep ´e fazer com que o valor TTL seja adaptativo. Para isso baseou-se

no protocolo de inicializa¸c˜ao lenta (slow start) (Jacobson, 1988). Assim, a men-

sagem de busca ´e enviada com um valor de TTL baixo, se n˜ao existir nenhuma

resposta `a busca, ent˜ao o valor do TTL ´e incrementado em 1. Ser´a estabelecida

uma janela de tempo para a espera m´axima das respostas. Caso as respostas `as

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 87

buscas estejam demorando muito, isso pode signiﬁcar que a profundidade ´e grande

demais para causar uma latˆencia na rede. Este valor ﬁca armazenado temporaria-

mente, at´e que o n´o se desconecte, para que nas pr´oximas mensagens de busca seja

utilizado o melhor valor de profundidade de busca.

Antes de enviar o resultado, ´e feito o c´alculo da reputa¸c˜ao. O c´alculo ´e

realizado pela F´ormula 5.1:

reputation

i,j

sat (i, j) − unsat (i, j)

sat (i, j)

O c´alculo da reputa¸c˜ao ´e realizado em todos os n´os que receberam o pe-

dido de reputa¸c˜ao sobre um determinado n´o, sendo i o n´o local e j o n´o que est´a

sendo pesquisada a reputa¸c˜ao. Ent˜ao sat(i,j ) corresponde ao n´umero de transa¸c˜oes

satisfat´orias que ocorreram entre i e j e unsat(i, j ) corresponde ao n´umero de

transa¸c˜oes insatisfat´orias que ocorreram entre i e j . O valor obtido atrav´es da

f´ormula ´e enviado ao n´o que solicitou a reputa¸c˜ao de j . Os n´os que obtiverem como

valor de reputa¸c˜ao para o n´o j igual a zero n˜ao necessitam enviar a resposta da

requisi¸c˜ao para o n´o requisitante. Isso faz com que ocorra uma redu¸c˜ao do n´umero

de requisi¸c˜oes desnecess´arias na rede, principalmente quando o n´o pesquisado ´e um

n´o novo.

As respostas, ao chegarem ao n ´o requisitante, todas as requisi¸c˜oes prove-

nientes dos n´os consultados acerca da reputa¸c˜ao do n´o j , s˜ao armazenadas para que

a reputa¸c˜ao global seja calculada. Este armazenamento ´e realizado em uma ﬁla de

mensagens, que ser´a processada ao ﬁm da janela de tempo. O c´alculo ´e realizado

da seguinte forma: todos os valores s˜ao somados e ´e feita uma m´edia aritm´etica. O

valor da m´edia dos valores de reputa¸c˜ao recebidos dos k n´os consultados na rede a

respeito do n´o j , ´e chamado de reputa¸c˜ao atual para j (currentRep). A F´ormula

5.2 mostra este c´alculo:

currentRep

i,j



Reputation

k,j

totalResponses

Com a reputa¸c˜ao atual e a reputa¸c˜ao anterior do n´o, outrora obtida e contida

na tabPeer, ser´a feita uma m´edia ponderada exponencial. Dessa forma, o protocolo

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 88

P2PWSRep considera que dados pontuais mais recentes tˆem maior peso, com este

peso declinando exponencialmente `a medida que esses dados tornam-se ultrapassa-

dos.

A constante alfa de ajuste aplicada determinar´a o n´ıvel de ajuste e a veloci-

dade de transi¸c˜ao da reputa¸c˜ao, para a diferen¸ca entre as previs˜oes e as ocorrˆencias

reais. A determina¸c˜ao da constante pode at´e ser arbitr´aria, mas de acordo com

simula¸c˜oes realizadas neste trabalho, optou-se por utilizar o valor de alfa como 0.4.

Analisando a F ´ormula 5.3, pode-se observar que quanto maior o valor de alfa, h´a

uma valoriza¸c˜ao da reputa¸c˜ao anterior (o hist´orico da reputa¸c˜ao). Caso o alfa esteja

tendendo a um valor mais baixo, ent˜ao h´a uma valoriza¸c˜ao da reputa¸c˜ao atual. A

considera¸c˜ao para a escolha desse valor ´e que a reputa¸c˜ao atual tem um maior peso,

muito embora o reﬂexo da reputa¸c˜ao anterior ´e tamb´em considerado. Al´em disso,

deﬁni¸c˜ao do valor de alfa, leva a entender que a reputa¸c˜ao pode ser facilmente ser

modiﬁcada em poucas intera¸c˜oes, mas isso se deve a necessidade de obter um co-

nhecimento do comportamento dos n´os da rede na simula¸c˜ao, com uma quantidade

de ciclos menores.

Ao fazer o c´alculo da reputa¸c˜ao dos n´os que contˆem os recursos, ent˜ao os

mesmos s˜ao mostrados em ordem da maior reputa¸c˜ao. Por enquanto, n˜ao est˜ao

sendo inclu´ıdos outros dados para fazer o ranqueamento dos recursos encontrados,

somente o valor da reputa¸c˜ao. A obten¸c˜ao da reputa¸c˜ao se d´a pela F´ormula 5.3:

reputation = (1 − α) · currentRep + previousRep · α

O gr´aﬁco da Figura 5.7 p ode mostrar melhor o que foi considerado. Nesta

simula¸c˜ao, o n´o possu´ıa uma reputa¸c˜ao de 0.8, armazenado na tabPeer d o n´o inte-

ressado. Ap´os consultados os n´os na rede, o resultado da reputa¸c˜ao atual para o n´o

foi de 0.655. Isto signiﬁca que o n´o n ˜ao cometeu muitas transa¸c˜oes insatisfat´orias na

rede. O protocolo de P2PWSRep n˜ao implica em que a reputa¸c˜ao seja considerada

sem que sejam levado em considera¸c˜ao o fator temporal. A partir do gr´aﬁco, pode-se

ver como o alfa inﬂuencia na reputa¸c˜ao ﬁnal. Para alfa igual a 1, a reputa¸c˜ao atual

n˜ao afeta o valor anterior, o que n˜ao ´e interessante para o protocolo. Para alfa igual

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 89

Figura 5.7: Inﬂuˆencia do parˆametro alfa no c´alculo da reputa¸c˜ao

a zero, o valor da reputa¸c˜ao anterior n˜ao ´e considerado na reputa¸c˜ao ﬁnal. Para

alfa igual a 0.5, o valor da reputa¸c˜ao sofre uma queda para o valor de 0.7275, uma

perda de 9,06% da reputa¸c˜ao. Para o valor de alfa de 0.4, o valor ﬁnal da reputa¸c˜ao

sofre uma queda para 0.713, uma perda de 10,87%, o requerido para o protocolo. O

protocolo foi projetado para que as perdas n˜ao sejam t˜ao abruptas, j´a que o n´o pode

ser prejudicado por fatores em que ele n˜ao esteja envolvido diretamente, tal como,

falhas na rede. Imagine um cliente de um banco h ´a 10 anos, que nunca deixou de

pagar suas contas em d ia, mas, por um problema de comunica¸c˜ao entre sua empresa

empregadora e o banco, seu sal´ario n˜ao foi creditado, assim todas as opera¸c˜oes de

d´ebito autom´atico foram recusadas e cheques foram devolvidos. Este cliente ﬁcaria

prejudicado se perdesse sua reputa¸c˜ao abruptamente. O protocolo P2PWSRep tenta

contornar esse tipo de problema, num cen´ario de compartilhamento de recursos em

redes P2P.

Quando todos os valores de reputa¸c˜ao ﬁnais s˜ao obtidos para os n´os que

possuem o recurso buscado, o n´o requisitante iniciar´a a busca da reputa¸c˜ao desses

recursos. O processo ´e muito semelhante `a busca de reputa¸c˜ao de n´os. Para isso, o

requisitante envia para seus vizinhos uma mensagem que cont´em a lista dos recursos

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 90

pesquisados e os n´os que os compartilham. Os n´os recebem a requisi¸c˜ao e respondem

ao requisitante com a reputa¸c˜ao dos recursos, enviando uma lista, com o peerID,

resourceID e o c´odigo de erro (errorType). O mecanismo de roteamento, controle de

mensagens duplicadas, TTL adaptativo e janela de processamento das respostas s˜ao

os mesmos para busca de reputa¸c˜ao de n´os. Ap´os o t´ermino da busca da reputa¸c˜ao

dos recursos, uma lista ´e exibida ao usu´ario com os recursos dispon´ıveis, ranqueados

de acordo com os dados da reputa¸c˜ao de n´os e recursos. O usu´ario ﬁca livre para

escolher qualquer recurso para fazer o download.

Ao escolher a fonte, o n´o que possui o recurso ir´a fazer testes de capacidade

de atendimento da requisi¸c˜ao e retornar ao n´o que est´a solicitando uma resposta,

que pode ser uma requisi¸c˜ao aceita, requisi¸c˜ao recusada ou requisi¸c˜ao enﬁleirada.

Isso evita que um n´o de alta reputa¸c˜ao e com um grande n´umero de recursos com-

partilhados seja sobrecarregado, pois ser´a natural que o mesmo sempre seja bem

ranqueado nas buscas. Caso ocorram falhas de conex˜ao, queda de conex˜ao ou outro

problema de comunica¸c˜ao, o n´umero de transa¸c˜oes insatisfat´orias (unsatTrans) ´e

incrementado em 1 (um).

Para gerenciar a reputa¸c˜ao dos recursos, cada recurso tem um identiﬁcador

´unico gerado atrav´es de uma fun¸c˜ao hash. Isso possibilita que os recursos compar-

tilhados, por mais que tenham nomes diferentes, sejam identiﬁcados de forma ´unica

dentro da rede P2P. Isso possibilita a utiliza¸c˜ao de reputa¸c˜ao para os recursos ou

uso de blacklist de recursos maliciosos ou n˜ao ´ıntegros.

Ap´os o t´ermino da transmiss˜ao do recurso, o mesmo ´e avaliado atrav´es de

uma fun¸c˜ao de veriﬁca¸c˜ao de integridade. Caso o arquivo seja ´ıntegro, ent˜ao o

n´umero de transa¸c˜oes satisfat´orias com o n´o fornecedor do recurso ´e incrementado

em 1 (um); caso contr´ario, o n´umero de transa¸c˜oes insatisfat´orias ´e incrementado

em 1 (um) e tamb´em ´e atu alizada a tabela de reputa¸c˜ao de recursos tabResource-

Reputation, informando o identiﬁcador do n´o, o identiﬁcador do recurso e o c´odigo

de erro do recurso. Nas pr´oximas consultas de reputa¸c˜ao do recurso, este dado ser´a

repassado para os requisitantes.

Al´em disso, em melhorias futuras do protocolo, pode-se colocar como peso,

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 91

dados a respeito da velocidade da conex˜ao e largura de banda real do n´o fornecedor.

Nesse caso, o valor de incremento n˜ao ser´a um valor 1, mas seguindo um intervalo

entre 0 e 1, j´a que o peso ir´a inﬂuenciar na opini˜ao do requisitante.

5.5 Descri¸c˜ao das Interfaces dos Servi¸cos do Pro-

tocolo P2PWSRep

A arquitetura da rede P2PWS ´e baseada na rede Gnutella, sendo descentra-

lizada, com mecanismo de busca realizado atr av´es de encaminhamentos sucessivos.

O protocolo P2PWSRep insere mecanismos de otimiza¸c˜ao da busca e diminui¸c˜ao de

sobrecarga de mensagens geradas na rede. As mensagens enviadas entre os n´os tˆem

roteamento semelhante a da rede Gnutella, mas s˜ao realizadas por meio de servi¸cos

web. As requisi¸c˜oes aos servi¸cos s˜ao realizadas utilizando chamadas s´ıncronas ou

ass´ıncronas (callback), o que signiﬁca que o n´o n˜ao ﬁcar´a bloqueado esperando a

resposta.

A Tabela 5.6 mostra as principais opera¸c˜oes d o protocolo P2PWSRep. No

nome d a opera¸c˜ao, ´e destacado o tipo de mensagem, que pode ser s´ıncrona ou

ass´ıncrona. Na descri¸c˜ao, s˜ao detalhadas as funcionalidades das opera¸c˜oes.

Al´em das opera¸c˜oes mostradas na Tabela 5.6, os n´os executam algumas

opera¸c˜oes durante o processamento das mensagens. As opera¸c˜oes s˜ao implemen-

tadas na interface cliente ou servidor dos n´os, atrav´es de m´etodos que s˜ao invocados

ou controlados por meio de threads. O diagrama de sequˆencia da Figura 5.8 mostra

as intera¸c˜oes das opera¸c˜oes do protocolo P2PWSRep.

• Gera¸c˜ao do identiﬁcador ´unico do n´o - Cada n´o da rede P2PWSRep

tem um indentiﬁcador ´unico, chamado de peerID. Este identiﬁcador ´e gerado

atrav´es do m´etodo GeneratePeerID(), da interface servidor, que utiliza uma

fun¸c˜ao SHA-1 para gera¸c˜ao de hash.

• Busca de recursos - Quan do um n´o recebe uma requisi¸c˜ao, a string de con-

sulta, contida na carga ´util da requisi¸c˜ao, ´e usada para pesquisar no reposit´orio

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 92

Nome da Opera¸c˜ao Descri¸c˜ao

(S´ıncrona) anﬁtri˜ao gera um peerID e o envia

junto com a sua tabela de n´os para o novo n´o.

Connect Opera¸c˜ao realizada cada vez que o n´o se

(S´ıncrona) conecta `a rede. Ele atualiza seu IP corrente na

rede e faz a veriﬁca¸c˜ao do seu peerID.

QueryResource Envia a descri¸c˜ao do recurso (string) a ser

(Ass´ıncrona) pesquisado na rede.

QueryResourceHit Resposta para um QueryResource. Traz consigo

(Ass´ıncrona) os endere¸cos (urls) dos recursos pesquisados.

QueryPeerReputation Busca a r eputa¸c˜ao dos n´os que possuem o recurso,

(Ass´ıncrona) atrav´es QueryResourceHit.

QueryPeerReputationHit Resposta para o QueryPeerReputation. Traz como

(Ass´ıncrona) resultado os valores de reputa¸c˜ao dos n´os, obtidos

dos demais n´os da rede.

QueryResourceReputation Busca da reputa¸c˜ao dos recursos encontrados

(Ass´ıncrona) nos n´os.

QueryResourceReputationHit Resposta para o QueryResourceReputation,

(Ass´ıncrona) trazendo como resultado a reputa¸c˜ao dos recursos.

Download (S´ıncrona) Solicita¸c˜ao do download do recurso.

QueryMyReputation O n´o faz uma busca de como est´a sua

(Ass´ıncrona) reputa¸c˜ao na rede.

NotifyDeletion Informa ao n´o que cont´em um recurso corrompido,

(Ass´ıncrona) que o mesmo deve ser removido do seu reposit´orio.

Tabela 5.6: Opera¸c˜oes do protocolo P2PWSRep

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 93

de dados do n´o. O m´etodo SearchRepository(), da interface servidor, ´e uti-

lizado para obter os recursos que o n´o cont´em. A opera¸c˜ao QueryResourceHit

envia a resposta ao n´o requisitante.

• Veriﬁca¸c˜ao do n´umero de hops - A cada n´o que a mensagem ´e encami-

nhada, o n´umero de hops ´e decrementado, quando o valor chega a zero, a

mensagem ´e removida da rede. Isto possibilita que as mensagens n˜ao ﬁquem

trafegando indeﬁnidamente na rede. Os m´etodos que realizam estes controles

s˜ao o Foward() e o DropMessage(), da interface servidor.

• Veriﬁca¸c˜ao de mensagem duplicada - Cada mensagem possui em seu

cabe¸calho um identiﬁcador e um timestamp, al´em do peerID do n´o que a gerou,

que possibilita que a mensagem, ao passar por um n´o, tenha seus dados grava-

dos em uma tabela. Caso uma outra mensagem chegue ao n´o, ele pesquisa

na tabela, se encontrar, ent˜ao ´e uma mensagem que j´a foi roteada, sendo a

mesma removida da rede. Esse processo de veriﬁca¸c˜ao de mensagens dupli-

cadas ´e realizado pelo m´etodo VerifyDuplicateMessage() e DropMessage(), da

interface do servidor.

• Controle do TTL adaptativo - O valor do TTL inicia baixo (com valor

2) e vai sendo incrementado (at´e o valor 6) quando as buscas de recursos

ou reputa¸c˜ao `a rede n˜ao retornam resultados dentro da janela de tempo. Isso

possibilita uma diminui¸c˜ao do n´umero de mensagens na rede e uma adapta¸c˜ao

dinˆamica do valor do TTL. O m´etodo que realiza esse mecanismo ´e o Adap-

tativeTTL(), da interface do cliente.

• Controle da janela para processamento de mensagens - Este mecanis-

mo ´e realizado pela interface cliente, em v´arios m´etodos, tais como, Process-

ResourceList(), CalculateCurrentRep(), CalculateReputation() e ProcessRepu-

tationResource(). Quando uma pesquisa ´e iniciada, uma janela de tempo ´e

criada, controlada por uma thread, sendo as mensagens que chegam dentro

da janela enﬁleiradas. Ao ﬁm da janela, as mensagens s˜ao processadas. As

mensagens que chegam fora da janela s˜ao descartadas.

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 94

• C´alculo da reputa¸c˜ao - Existem trˆes m´etodos para processamento de dados

de reputa¸c˜ao. O primeiro m´etodo ´e realizado pela interface servidor, Cal-

culateReputation(), que c´alcula a reputa¸c˜ao de um n´o, pelo seu hist´orico de

transa¸c˜oes satifat´orias e insatisfat´orias. O valor obtido ´e transferido para o n´o

requisitante atrav´es da opera¸c˜ao QueryPeerReputationHit. O segundo e ter-

ceiro m´etodo, CalculateCurrentRep() e CalculateReputation(), s˜ao realizados

pela interface cliente, com os dados de reputa¸c˜ao recebidos dos n´os.

• Ranqueamento dos recursos - Ap´os obter os dados da reputa¸c˜ao dos n´os

e dos recursos, ´e realizado um ranqueamento dos melhores recursos para que

o usu´ario possa escolher para download. O m´etodo Ranking() da interface

cliente realiza est´a tarefa.

• Teste da capacidade de atendimento do download - Quando o usu´ario

seleciona um recurso para ser baixado, o n´o destino, que compartilha o re-

curso, faz uma veriﬁca¸c˜ao de capacidade para atendimento do n´o. O m´etodo

respons´avel por este teste ´e o TestDownload(), da interface servidor. Caso,

esteja com uma sobrecarga de conex˜oes, o n´o pode negar a requisi¸c˜ao ou en-

ﬁleirar, para atendˆe-la mais tarde.

• Veriﬁca¸c˜ao de integridade do recurso - Ao baixar um recurso, o n´o rea-

liza uma veriﬁca¸c˜ao de integridade do mesmo, aplicando uma fun¸c˜ao hash,

para saber se o hash obtido condiz com o original. Esta fun¸c˜ao ´e realizada

pelo m´etodo VerifyResourceHash(), da interface cliente. Caso o recurso esteja

corrompido, adulterado ou infectado por v´ırus, o n´o usa a opera¸c˜ao Notify-

Deletion para informar o n´o de origem. Al´em de adicionar o recurso na tabela

tabResourceReputation, com o c´odigo de erro obtido pela fun¸c˜ao de valida¸c˜ao.

• Atribui¸c˜ao valor de transa¸c˜ao - Ao ﬁnal da transa¸c˜ao, um valor de reputa-

¸c˜ao ´e atribu´ıdo `a mesma. Se foi satisfat´oria, o campo satTrans do n´o, na tabela

tabPeer ´e incrementado, caso contr´ario o campo unsatTrans ´e incrementado.

Esta fun¸c˜ao ´e realizada pelo m´etodo SetReputation(), da interface cliente.

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 95

Figura 5.8: Diagrama de sequˆencia do protocolo P2PWSRep

No diagrama de sequˆencia da Figura 5.8, est˜ao representados apenas trˆes

n´os. Cada n´o possui uma interface para as opera¸c˜oes do cliente e servidor. As

opera¸c˜oes s˜ao realizadas atrav´es de servi¸cos web. A opera¸c˜ao se inicia com um n´o

ingressando na rede. Para isto, existe uma opera¸c˜ao chamada de Login(), onde

o n´o solicita a um n´o j´a conectado a rede, chamado de anﬁtri˜ao, o seu ingresso.

Ao receber a solicita¸c˜ao, o n´o anﬁtri˜ao gera um peerID para o novo n´o e o envia

juntamente com sua tabela de n´os vizinhos. Isto possibilita que o novo n´o passe

a conhecer seus vizinhos. Todas as vezes que o n´o ingressar na rede, ele executa

a opera¸c˜ao Connect(), passando seu peerID e seu endere¸co IP atual, j´a que pelo

fator dinˆamico das redes P2P, h´a necessidade de identiﬁca¸c˜ao do n´o apenas pelo seu

CAP

ITULO 5. PROTOCOLO DE REPUTAC¸

AO P2PWSREP 96

peerID, preservando seu anonimato. Por´em h´a necessidade de atualizar o endere¸co

atual utilizado pelo n ´o. Todas as opera¸c˜oes est˜ao detalhadas na Tabela 5.6 e os

principais m´etodos foram descritos nesta se¸c˜ao.

5.6 Considera¸c˜oes Finais

Neste cap´ıtulo, foram apresentadas as principais caracter´ısticas do projeto

do protocolo P2PWSRep, incluindo a arquitetura desta rede P2P, topologia e me-

canismo de roteamento de mensagens. Seu mecanismo de controle de repu ta¸c˜ao ´e

baseado nos protocolos de reputa¸c˜ao apresentados neste trabalho, adicionando-se

mecanismos para torn´a-lo simples e sem sobrecargas de processamento nos n´os. A

principal ﬁnalidade deste protocolo ´e controlar a reputa¸c˜ao dos n´os presentes na

rede e dos recursos compartilhados de forma distribu´ıda, sem depender de nenhum

elemento central, utilizando como base a tecnologia de servi¸cos web para possibilitar

a interoperabilidade com outras redes P2P e extensibilidade de c´odigo para suportar

adi¸c˜oes de melhorias e contornar problemas de desempenho e seguran¸ca da rede.

Cap

ıtulo 6

Simula¸c˜ao do Protocolo

P2PWSRep

6.1 Introdu¸c˜ao

As aplica¸c˜oes que utilizam servi¸cos web tˆem um desempenho dito inferior

em rela¸c˜ao `as tecnologias convencionais de desenvolvimento de software distribu´ıdo.

Assim, ad icionar mecanismos complexos de controle de seguran¸ca a essas redes as

deixam mais lentas. O P2PWSRep ´e um protocolo sem excessos de mecanismos de

seguran¸ca, mas que ofere¸ce meios de combater as principais vulnerabilidades das

redes P2P, contribuindo para que ocorra a adi¸c˜ao de sucessivas melhorias, por este

ser extens´ıvel e port´avel. A etapa de simula¸c˜ao foi importante para este trabalho,

por comprovar que o protocolo P2PWSRep pode ser vi´avel para boa parte das

aplica¸c˜oes de redes P2P, orientadas ou n˜ao a servi¸cos.

A simula¸c˜ao do protocolo P2PWSRep se ateve ao mecanismo de reputa¸c˜ao

aqui proposto, independentemente da forma com que as mensagens s˜ao trans-

portadas, at´e porque o n´ucleo do protocolo pode ser utilizado por qualquer outra

rede, mesmo que n˜ao seja orientada a servi¸cos. A ferramenta de simula¸c˜ao utilizada

neste trabalho foi o PeerSim (PeerSim, 2009), desenvolvido e mantido pelo Projeto

BISON d a Universidade de Bolonha, na It´alia. Alguns crit´erios foram emprega-

dos na escolha do simulador, tais como, atividade atual do p rojeto, documenta¸c˜ao

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 98

dispon´ıvel, linguagem em que o simulador foi escrito e tipo de licenciamento. O

projeto PeerSim est´a atualmente ativo e tem uma vasta documenta¸c˜ao dispon´ıvel,

com v´arios exemplos de cen´arios de simula¸c˜ao. Seu c´odigo ´e escrito em Java e tem

licen¸ca GPL (General Public License).

Outro fator prepoderante na escolha do simulador foi a possibilidade de fazer

simula¸c˜oes para uma grande quantidade de n´os, bem como utilizar tanto uma ar-

quitetura de simula¸c˜ao estruturada, como desestruturada. O PeerSim possui esca-

labilidade, podendo chegar a 1 milh˜ao de n´os, sendo que na simula¸c˜ao do protocolo

P2PWSRep foram utilizados 10 mil n´os para obten¸c˜ao dos resultados. Al´em disso,

o PeerSim possibilita implenta¸c˜ao de simula¸c˜ao dirigida a ciclos (cycle-based model)

e dirigida a eventos (event-based model), sendo necess´aria a utiliza¸c˜ao dos dois tipos

de simula¸c˜ao para a valida¸c˜ao deste trabalho, especialmente devido `as particulari-

dades do protocolo P2PWSRep.

6.2 Descri¸c˜ao do Ambiente de Simula¸c˜ao

Para facilitar o entendimento da rede simulada, ´e apresentada uma pequena

rede P2P com apenas 10 n´os, baseada na topologia do P2PWSRep simulada com

10.000 n´os. O objetivo de mostrar esta pequena rede ´e fazer com que se possa

visualizar a forma com que os n´os se interligam, isto ´e, a topologia da rede.

Na topologia ilustrada na Figura 6.1, percebem-se algumas caracter´ısticas do

projeto P2PWSRep. Ele ´e baseado na rede Gnutella vers˜ao 0.4, assim n˜ao existem

n´os que centralizam fun¸c˜oes espec´ıﬁcas da rede, tais como ingresso na rede, busca

de recursos e controle de reputa¸c˜ao; e todas as intera¸c˜oes entre os n´os s˜ao realizadas

por meio de encaminhamentos sucessivos.

Para conﬁgurar o ambiente de simula¸c˜ao no PeerSim, foram implementadas

as classes base do protocolo P2PWSRep. O elemento principal d a simula¸c˜ao ´e o n´o

(peer), ao qual est˜ao associadas todas as opera¸c˜oes, recursos que o n´o compartilha

e informa¸c˜oes de reputa¸c˜ao dos pr´oprios n´os e recursos. O simulador PeerSim tem

uma interface chamada Node que ´e implementada pela classe GeneralNode, ambas

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 99

Figura 6.1: Exemplo

da topologia da rede

P2PWS.

do pacote peersim.core, que cont´em as principais opera¸c˜oes para simular uma rede

P2P, tais como: cria¸c˜ao do n´o, obten¸c˜ao de identiﬁcador, ingresso e sa´ıda de n´os

da rede e implenta¸c˜ao do protocolo n´ucleo da rede simulada. O n´o do protocolo

P2PWSRep foi criado extendendo-se a classe GeneralNode, sendo a classe resultante

a P2PWSRepNode. A seguir, na Listagem 6.1, ´e mostrada uma parte do c´odigo da

classe escrito em linguagem Java:

Listagem 6.1: Trecho da classe P2PWSRepNode

1 package p2pwsrep ;

3 import j ava . u t i l . Hashtab l e ;

4 import pe ersim . c o r e . GeneralNode ;

6 public c l a s s P2PWSRepNode extends GeneralNode {

7 /∗ i d e n t i f i c a d o r do n´o ∗/

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 100

8 private long pe er Id ;

9 private boolean s tr o ng ;

11 /∗ t a b e l a de nos ∗/

12 private Hashtable tabPeer ;

13 /∗ t a b e l a de r ec u r so s ∗/

14 private Hashtable tabReso u rce ;

15 /∗ t a b e l a de r epu tac ao de nos ∗/

16 private Hashtable tabPe erReputation ;

17 /∗ t a b e l a de r epu tac ao de r e cu rs o ∗/

18 private Hashtable tab Resource Reputat i on ;

19 /∗ t a b e l a de c o nf i gu r ac a o ∗/

20 private Hashtable t a b S e t t i ng s ;

22 /∗ usado em re d es e s t r u t u r a d a s ∗/

23 private boolean supernode = f a l s e ;

25 /∗ Co nst ruc to r ∗/

26 /∗ ∗ Cria uma nova i n s t a n c i a de P2PWSRepNode ∗/

27 public P2PWSRepNode( S t r i n g p r e f i x ) {

28 super ( p r e f i x ) ;

29 supernode = f a l s e ;

31 tabPeer = new Hashtable ( ) ;

32 tabResour c e = new Hashtable ( ) ;

33 tabPeer Reputation = new Hashtable ( ) ;

34 tabR esourceR eputati o n = new Hashtable ( ) ;

35 t a b S et t i n g s = new Ha shtable ( ) ;

36 }

37 [ . . . ]

No c´odigo, pode-se notar que cada n´o tem como principais atributos seu

identiﬁcador (peerID) e as tabelas de n´os vizinhos (tabPeer), tabela de recursos

(tabResource), tabela de reputa¸c˜ao de n´os (tabPeerReputation) e de recursos (tabRe-

sourceReputation) e uma tabela que cont´em os dados de conﬁgura¸c˜ao do n´o (tabSet-

tings). Essas tabelas tˆem os campos descritos na se¸c˜ao de metadados, apresentada

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 101

no Cap´ıtulo 5. Fisicamente, os dados s˜ao armazenadas em arquivos XML e s˜ao

manipulados por classes que fazem o parsing destes arquivos.

Outra parte fundamental para a simula¸c˜ao ´e a deﬁni¸c˜ao da estrutura da

mensagem. O simulador oferece uma classe chamada de SMessage. Esta classe

implementa a interface cloneable, que permite criar m´ultiplas c´opias das mensagens.

A seguir, na Listagem 6.2, h´a uma parte do c´odigo da classe SMessage, j´a com as

adi¸c˜oes referentes ao protocolo P2PWSRep.

Listagem 6.2: Classe SMessage

1 package p2pwsrep ;

3 import j ava . s q l . Timestamp ;

5 import pe ersim . cdsim . CDState ;

6 import pe ersim . c o r e . Node ;

8 public c l a s s SMessage implements C l one able {

9 /∗ d e f i n i c a o dos t i p o s de mensagens do p r o t o c o lo de re put aca o ∗/

10 public s t a t i c f i n a l i n t QRY = 0;

11 public s t a t i c f i n a l i n t FWD = 1 ;

12 public s t a t i c f i n a l i n t HIT = 2 ;

14 /∗ busca da r epu tac ao do nos que contem o re cu r so ∗/

15 public s t a t i c f i n a l i n t QRYREP = 3 ;

16 /∗ r e s p o s t a da busca da r epu tac ao ∗/

17 public s t a t i c f i n a l i n t HITREP = 4;

18 /∗ busca da r epu tac ao do r ec u r s o en c ontrado ∗/

19 public s t a t i c f i n a l i n t QRYREPRESOURCE = 5 ;

20 /∗ r e s p o s t a da busca da r epu tac ao do r e cu rs o ∗/

21 public s t a t i c f i n a l i n t HITREPRESOURCE = 6;

23 private s t a t ic int s e q

g e n e r a t o r = 0 ;

25 public int hops , type , seq , s t a r t ;

26 public Node o r i g i n a t o r ;

27 public S t r in g payload ; /∗ arr ay de s t r i n g s ∗/

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 102

28 public Timestamp time ;

30 public SMessage ( Node o r i g i n a t o r , i n t type , int hops , Timestamp

timestamp , S t r i n g payload ) {

31 th i s . o r i g i n a t o r = o r i g i n a t o r ;

32 th i s . type = type ;

33 th i s . hops = hops ;

34 th i s . timestamp = timestamp ;

35 th i s . payload = payload ;

36 th i s . s eq = ++s e q

g e n e r a t o r ;

37 th i s . s t a r t = CDState . ge tCy cle ( ) ;

38 }

39 [ . . . ]

Destacam-se no c´odigo alguns pontos importantes, tais como os atributos

hops, type e timestamp. O campo TTL indica o n´umero de vezes que a mensagem

ser´a encaminhada antes de ser removida da rede; a cada n´o por onde a mensagem

passa, o valor de TTL ´e decrementado em 1 e o hops ´e incrementado em 1. Quando

o valor chega a zero, a mensagem ´e descartada da rede. O Campo type determina

o tipo de mensagem, podendo ser uma mensagem de pesquisa de recurso, pesquisa

de reputa¸c˜ao de n´o, pesquisa de reputa¸c˜ao do recurso, mensagem de resposta de

busca a recursos, resposta de busca da reputa¸c˜ao de um n´o ou resposta de busca

de reputa¸cao de um recurso. O campo timestamp armazena uma marca de tempo,

indicando o exato momento em que a men sagem foi gerada. O timestamp permite

controlar o momento em que as mensagens chegam ao destino. Existe um intervalo

m´aximo de espera das respostas pelas mensagens de busca, chamado de intervalo de

janela. Caso as mensagens cheguem fora da janela de tempo, isto ´e, ap´os o intervalo

de espera, elas ser˜ao descartadas pelo n´o que iniciou a busca. Caso contr´ario, s˜ao

armazenadas em uma ﬁla para posterior processamento, ou seja, quando a janela

de tempo se esgotar.

O n´ucleo do protocolo P2PWSRep foi implementado no simulador na classe

P2PWSRepProtocol a partir de trˆes interfaces. A CDProtocol (Cycle Driven), que

possibilita a simula¸c˜ao de opera¸c˜oes que devem se repetir a cada ciclo de execu¸c˜ao

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 103

do simulador, de acordo com a conﬁgura¸c˜ao do experimento, realizada por meio

de um arquivo de entrada de dados. O EDProtocol (Event Driven) utilizado por

opera¸c˜oes simuladas a partir da gera¸c˜ao d e um evento, tal como o recebimento de

uma mensagem, solicita¸c˜ao de um download, etc.; e, por ´ultimo a Linkable que ´e

respons´avel por controlar as conex˜oes entre o n´o e seus vizinhos. Alguns m´etodos

desta classe s˜ao destacados a seguir:

• send(Node n, SMessage mes ) - Ao iniciar uma busca, uma mensagem

com a string de busca para o recurso ´e gerada e enviada atrav´es do m´etodo

send(). Uma ﬁla ´e utilizada para controlar as buscas pendentes. Assim, para

cada busca iniciada, ´e adicionada, em uma tabela, seu identiﬁcador. Essa

tabela ´e implementada atrav´es de uma hashtable, tendo como campos chave o

identiﬁcador da busca e seu timestamp. A cada mensagem que chega, o tipo da

mensagem ´e checado e ´e veriﬁcado na tabela se a busca foi realizada pelo n´o.

Para cada tipo de mensagem, existe uma tabela espec´ıﬁca para que n˜ao ocorra

uma sobrecarga de processamento caso todas as mensagens estivessem em uma

s´o tabela. Se a busca foi iniciada pelo n´o, ent˜ao a r esposta ´e enﬁleirada em u ma

tabela, aguardando o t´ermino da janela de tempo. Quando a janela de tempo

se esgota, todas as mensagens s˜ao processadas. Uma thread ﬁca respons´avel

por notiﬁcar o momento do processamento das mensagens enﬁleiradas. Todas

as mensagens que chegarem ap´os o ﬁm da janela de tempo s˜ao descartadas.

O tamanho da janela ´e associado ao TTL: para um TTL maior, uma janela

maior; caso contr´ario, uma janela menor ´e utilizada. Este controle ´e realizado

no n´o que iniciou a busca de recursos e busca de reputa¸c˜ao. As mensagens

de resposta n˜ao possuem o controle de janela de tempo. Assim, quando um

n´o responde a uma requisi¸c˜ao, seja ela qual for, a mensagem com o conte´udo

da resposta ´e colocada no campo payload e o valor do campo hops ´e utilizado

dependendo da profundidade em que este n´o se encontra.

• updateRoutingTable(Node n, SMessage mes) - A cada mensagem que

´e enviada ou recebida, a tabela de roteamento ´e atualizada. Em cada n´o,

existe uma hashtable que controla o roteamento das mensanges seguindo o

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 104

mecanismo de roteamento do Gnutella, isto ´e, quando uma mensagem ´e en-

viada ou encaminhada, seu identiﬁcador ´e armazenado em uma tabela para

que, quando uma mensagem de reposta chegue, seja feita uma veriﬁca¸c˜ao se

o n´o participou do envio ou encaminhamento da mesma.

• forward(Node n, Smessage mes) - Caso a mensagem tenha passado pelo

n´o, ele c´opia (clona) a mensagem e a encaminha, atrav´es deste m´etodo, para

seus vizinhos, exceto para o vizinho que lhe enviou. Caso contr´ario, a men-

sagem ´e descartada. Esse mecanismo permite que as men sagens retornem

pelo mesmo caminho que percorreram para atingir um alvo. Ao clonar a

mensagem, ´e realizada a altera¸c˜ao do valor do campo TTL e hops.

• process(SMessage mes) - Ao esgotar a janela de tempo, as mensagens s˜ao

processadas atrav´es deste m´etodo. No processamento, ´e veriﬁcado o tipo de

mensagem e, de acordo com o tipo, a mensagem ´e enviada para o m´etodo

espec´ıﬁco de processamento, seja para uma simples pesquisa a um recurso ou

para uma busca de reputa¸c˜ao. No caso da busca de recursos, o n´o que recebe

a mensagem extrai a string e pesquisa, em seu reposit´orio de arquivos com-

partilhados, se h´a algum arquivo que possua a string buscada. Caso encontre,

ele responde para o n´o que originou a busca, enviando a mensagem por en-

caminhamento sucessivos. Caso a mensagem seja uma busca de reputa¸c˜ao,

ent˜ao o n´o que recebeu o pedido veriﬁca em sua tabela de reputa¸c˜ao de n´os se

ele conhece o n´o procurado. Caso seja u m n´o com que ele j´a interagiu, ent˜ao

re´une as informa¸c˜oes para o c´alculo da reputa¸c˜ao local, que s˜ao o n´umero de

transa¸c˜oes satisfat´orias e o n´umero de transa¸c˜oes insatisfat´orias, realizando o

c´alculo de acordo com a F´ormula 5.1. Ent˜ao, o resultado ´e enviado para o

n´o interessado. Caso a reputa¸c˜ao do n´o procurado seja zero, a resposta n˜ao ´e

enviada.

A topologia e o mecanismo de roteamento das mensagens foram implemen-

tadas na classe ´e GnutellaProtocol, mostrada na Listagem 6.3, que implementa o

protocolo Gnutella vers˜ao 0.4.

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 105

Listagem 6.3: Classe GnutellaProtocol

1 public c l a s s G nu t el l a P ro t oc ol extends P2PWSRepProtocol{

2 /∗∗ Cr eate s a ne w i n s t an c e o f G nu t e ll a P r o t o c ol ∗/

3 public G nu te l la Pr o to c ol ( S t r in g p r e f i x ) {

4 super ( p r e f i x ) ;

5 }

7 public void nex tCycle ( Node node , i n t p ro t oc ol ID ) {

8 super . nextCycl e ( node , p r o t oc ol ID ) ;

9 /∗ ∗ I f we have t o produce a query ∗/

10 S t r i n g data = t h i s . pickQueryData ( ) ;

11 i f ( data != nul l ) {

13 SMessage m = new SMessage ( node , SMessage .QRY, 0 , new Timestamp

( System . c ur r en t T im e Mi l l i s () ) , data ) ;

15 /∗ ∗ This node a l r ea d y i s knows ∗/

16 i f ( ! th i s . match (m) ) {

17 // I f I don ’ t

18 for ( int i = 0 ; i < t h i s . view . s i z e ( ) &&

19 i < t h i s . de gre e ( ) ; i ++){

20 System . out . p r i n t l n ( "Node : "+node . getID ( )+" sending to "+

21 ( ( Node ) t h i s . getNeig hbor ( i ) ) . getID ( ) ");

22 this.send (( Node) this . getNeighbor (i) , m);}

23 } else {

24 /* I know this node , so I don ’t need to propagate */

25 this . messageTable .put(m, new Integer (0) );

26 [...]

27 }

28 }

29 [...]

To d as as mensagens s˜ao armazenadas em uma tabela quando chegam no n´o

que solicitou a reputa¸c˜ao, esperando pelo ﬁm da janela de tempo. Quando o tempo

se esgota, todas as mensagens s˜ao processadas.

E realizado um c´alculo com todos os

valores recebidos, aplicando uma m´edia aritm´etica para obter a reputa¸c˜ao recebida

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 106

da rede, pela F´ormula 5.2. Com este valor, ´e realizado outro c´alculo, utilizando a

F´ormula 5.3 para se obter a reputa¸c˜ao ﬁnal. O novo valor ser´a armazenado no campo

previousRep, sobrescrevendo o valor anterior, contido na tabela tabReputation do

n´o que iniciou a busca.

A pr´oxima etapa do protocolo ´e a busca da reputa¸c˜ao dos recursos. Esta

opera¸c˜ao ´e mais r´apida, pois n˜ao envolve c´alculo distribu´ıdo. Somente ´e realizada

uma consulta na rede para veriﬁcar se o recurso tem alguma restri¸c˜ao no n´o em

que ele est´a dispon´ıvel. Assim, ´e realizada uma consulta aos n´os da rede atrav´es

de uma mensagem QUERYREPRESOURCE, contendo na sua carga ´util uma lista

dos recursos a serem pesquisados, para que os que j´a obtiveram o arquivo do n´o

possam fornecer a informa¸c˜ao sobr e os recursos. Isso ´e importante para diminuir o

n´umero de mensagens do proto colo P2PWSRep na rede, caso fosse utilizada uma

mensagem para consultar a reputa¸c˜ao de cada recurso.

Ao ﬁnal deste processo, os recursos s˜ao ranqueados de acordo com a repu-

ta¸c˜ao dos n´os que os compartilham e a lista ´e exibida ao usu´ario, excluindo-se os

recursos com reputa¸c˜ao duvidosa. Havendo empate, ´e considerado o n´o com maior

n´umero de transa¸c˜oes satisfat´orias. Caso persista o empate, o n´o mais antigo na

rede ´e melhor ranqueado. Cada n´o possui uma tabela de reputa¸c˜ao de recursos,

sendo que a estrutura da tabela ´e o identiﬁcador do recurso, identiﬁcador do n´o e

um array de c´odigos de reputa¸c˜ao do recurso. Para a tabela n˜ao crescer muito e

comprometer o desempenho do protocolo, somente s˜ao armazenados os c´odigos de

recursos corrompidos, infectados ou inexistentes. Outros c´odigos podem ser criados

e inclu´ıdos no protocolo.

To d os os processos acima s˜ao iniciados pelo m´etodo main() da classe Simu-

lator. Para carregar os dados dos metadados de arquivos e reputa¸c˜ao, s˜ao utilizadas

classes de inicializa¸c˜ao, para fornecer a carga de trabalho da simula¸c˜ao e os dados

iniciais para conﬁgura¸c˜ao de toda a rede P2P.

• P2PWSRepInitializerFiles - Instancia aleatoriamente um conjunto de ar-

quivos para os n´os da rede.

• P2PWSRepInitializerReputation - Atribui valores de reputa¸c˜ao aos n´os

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 107

da rede.

• P2PWSRepInitializerReputationFiles - Atribui valores aleat´orios de re-

puta¸c˜ao aos recursos, de forma que se possa ter parte dos arquivos da rede

´ıntegros, corrompidos, infectados ou inexistentes, de acordo com um per-

centual estabelecido no cen´ario do experimento.

• P2PWSRepInitializer - Faz a inicializa¸c˜ao da simula¸c˜ao, onde ´e deﬁnida a

arquitetura da rede, n ´umero de n´os, protocolo da rede e execu¸c˜ao dos exp eri-

mentos.

A primeira inicializa¸c˜ao dos dados ´e o preenchimento aleat´orio da tabela

de recursos, realizada pela classe P2PWSRepInitializerReputationFiles. A segunda

inicializa¸c˜ao ´e a de reputa¸c˜ao, onde valores de reputa¸c˜ao s˜ao atribu´ıdos aleato-

riamente aos n´os. Esses valores dividem os n´os em basicamente quatro grupos:

´otimos, bons, regulares, ruins e p´essimos, sendo que os grupos est˜ao nos seguintes

intervalos, respectivamente, 1 e 0.8; 0.79 e 0.6; 0,59 e 4, 0.39 e 2; 0.19 e 0. Os

valores atribu´ıdos aos n´os s˜ao transa¸c˜oes satisfat´orias, insatisfat´orias e ´ultima re-

puta¸c˜ao conhecida do n´o previousRep. A classe respons´avel por esta inicializa¸c˜ao

´e a P2PWSRepInitializerReputation. A terceira inicializa¸c˜ao ´e a da reputa¸c˜ao dos

arquivos, implementada pela classe P2PWSRepInitializerReputationFiles, caracte-

rizando os arquivos somente por valores associados a um status: 1 - corrompido, 2

- infectado, 3 - adulterado, 4 - inexistente.

To d as as inicializa¸c˜oes s˜ao realizadas durante a pr´opria inicializa¸c˜ao do si-

mulador. Cada n´o da rede ´e instanciado com base em uma classe padr˜ao para o

n´o. A arquitetura P2PWSRep d eﬁne um n´o que ´e instanciado na inicializa¸c˜ao.

Esse n´o recebe um identiﬁcador e ´e inserido aleatoriamente na rede atrav´es de uma

distribui¸c˜ao bayes´ıana para liga¸c˜ao com os demais n´os da rede. A classe que deﬁne

um n´o da rede P2PWS ´e P2PWSRepNode.

A conﬁgura¸c˜ao do ambiente de simula¸c˜ao, tais como, tamanho da rede, ini-

cializa¸c˜ao, logs de sa´ıda ´e realizada pelo arquivo de conﬁgura¸c˜ao do simulador,

mostrado no Anexo 1.

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 108

Para que se possa visualizar o mecanismo de inicializa¸c˜ao da simula¸c˜ao e

encaminhamento d as mensagens, ´e apresentado um trecho do log de sa´ıda de uma

simula¸c˜ao, no Anexo 2.

Na sa´ıda mostrada no Anexo 2, foram omitidos os pacotes referentes `as buscas

de reputa¸c˜ao. Pela caracter´ıstica do protocolo Gnutella, as mensagens ser˜ao enca-

minhadas para os n´os vizinhos at´e que seu TTL seja esgotado. Para as mensagens

de reputa¸c˜ao, bem como outros tipos de mensagens, ´e veriﬁcado se a mensagem j´a

passou pelo n´o. O teste sendo positivo, a mesma n˜ao ser´a processada, nem enca-

minhada novamente. Isso conseguiu reduzir o n´umero de mensagens de reputa¸c˜ao

trafegando na rede.

A valida¸c˜ao do protocolo P2PWSRep foi realizada em v´arios cen´arios, para

que fossem obtidos resultados que demonstrem o comportamento do protocolo em

apontar corretamente a reputa¸c˜ao de um n´o ou recurso e o impacto do protocolo no

gera¸c˜ao de tr´afego na rede. Nas pr´oximas se¸c˜oes s˜ao apresentados os resultados para

cen´arios distintos. S˜ao eles: An´alise do Protocolo de Reputa¸c˜ao dos N´os, An´alise

do Protocolo de Reputa¸c˜ao dos Recursos e An´alise do Protocolo Quanto `a Carga

na Rede.

6.3 Cen´ario 1 - An´alise do Protocolo de Reputa-

¸c˜ao dos N´os

O objetivo da simula¸c˜ao para o protocolo P2PWSRep, em rela¸c˜ao a rep uta-

¸c˜ao dos n´os, ´e validar seu mecanismo de obten¸c˜ao de dados e c´alculo da reputa¸c˜ao,

sem que haja comprometimento do funcionamento da rede. A importˆancia da re-

puta¸c˜ao na rede P2PWS ´e fazer com que n´os novos ou de baixa reputa¸c˜ao possam

melhorar sua reputa¸c˜ao caso cooperem de forma satisfat´oria na rede, isto ´e, com-

partilhando seus recursos e mantendo somente recursos ´ıntegros em seu reposit´orio.

Al´em disso, mostrar que, quando um n´o tem boa reputa¸c˜ao, para mantˆe-la o mesmo

tem que continuar cooperando de forma positiva, caso contr´ario sua rep uta¸c˜ao ser´a

decrementada pelo protocolo P2PWSRep.

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 109

6.3.1 Descri¸c˜ao do Cen´ario

Neste cen´ario, uma rede com 10.000 n´os foi “povoada” com recursos ´ıntegros

e corrompidos e com valores de reputa¸c˜ao aleat´orios. Estes dados foram inseridos

nas tabelas de reputa¸c˜ao de n´os e recursos. Foram elaborados para este primeiro

cen´ario quatro experimentos, onde um n´o i ser´a o n´o observador, isto ´e, o n´o

que far´a as requisi¸c˜oes de reputa¸c˜ao ao n´o observado, chamado de j . Os demais

n´os da rede fornecer˜ao dados relativos aos valores de reputa¸c˜ao de j, baseando-se

nas transa¸c˜oes satisfat´orias e insatisfat´orias ocorridas com o n´o j , contidas em sua

tabela de reputa¸c˜ao. O n´o i tem um valor de reputa¸c˜ao do n´o j , em sua tabela de

reputa¸c˜ao, no campo previousRep, igual a 0.8. O valor da reputa¸c˜ao do n´o j obtido

da rede foi de 0.655.

Foi considerado alfa igual a 0.4 para o protocolo P2PWSRep, o que possibilita

que haja um ganho de reputa¸c˜ao e uma perda gradual, fazendo com que a curva de

perda seja mais suave, valorizando mais as transa¸c˜oes recentes. Cada situa¸c˜ao foi

simulada de forma independente, sendo os resultados apresentados em um mesmo

gr´aﬁco (Figura 6.2) para que se possa fazer u ma compara¸c˜ao entre as trˆes abordagens

e veriﬁcar como o protocolo funciona e age em diferentes situa¸c˜oes na rede P2P. A

ferramenta utilizada para construir os gr´aﬁcos foi o GnuPlot

6.3.2 Resultados

Na primeira simula¸c˜ao, um n´o n˜ao ir´a cooperar na rede, assim ele n˜ao ter´a

realizado ao ﬁnal da simula¸c˜ao transa¸c˜oes satisfat´orias ou insatisfat´orias. O ob-

jetivo deste primeiro cen´ario ´e mostrar que, um n´o que n˜ao realize os dois tipos

de transa¸c˜oes citados anteriormente, n˜ao pode manter sua reputa¸c˜ao atual, j´a que

este comportamento caracteriza um n´o carona ou ego´ısta, um n´o que s´o consome

os recursos da rede, mas n˜ao compartilha seus recursos com os demais. O proto-

colo de reputa¸c˜ao P2PWSRep age nesse n´o reduzindo sua reputa¸c˜ao, por´em mais

lentamente que a de um n´o com um hist´orico negativo. Percebe-se que a reputa¸c˜ao,

ap´os v´arias consultas diminuem, isso retrata que um n´o que n˜ao ´e muito acessado

P´agina Inicial: http://www.gnuplot.info

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 110

perde reputa¸c˜ao. Este comportamento ´e mostrado no gr´aﬁco da Figura 6.2, onde se

percebe que, ao ﬁnal da simula¸c˜ao, que durou 100 ciclos, o valor da reputa¸c˜ao ´e igual

a 0.653, que representa o valor do campo previousRep do n´o observado para o n´o

que ﬁnalizou esta simula¸c˜ao em busca da reputa¸c˜ao. Isso representa uma perda de

reputa¸c˜ao em termos percentuais de 18.37%. Em termos reais, a simula¸c˜ao equivale

a estressar o n´o pelo n´umero de transa¸c˜oes. O resultado da simula¸c˜ao equivale ao

esperado na deﬁni¸c˜ao do protocolo P2PWSRep, j´a que, em rela¸c˜ao a reputa¸c˜ao,

houve uma queda de 0.655 para 0.653. Isto mostra que apesar de n˜ao existir uma

centraliza¸c˜ao das informa¸c˜oes de reputa¸c˜ao na rede, os valores de reputa¸c˜ao sempre

s˜ao bem pr´oximos quando consideramos uma amostragem geral da reputa¸c˜ao de

um n´o qualquer na rede, validando a id´eia do protocolo P2PWSRep, que, mesmo

descentralizado, pode apontar para um valor de reputa¸c˜ao que seja bem semelhante

em toda a rede.

Figura 6.2: Gr´aﬁco de varia¸c˜ao da reputa¸c˜ao.

A segunda simula¸c˜ao, utilizou a mesma caracteriza¸c˜ao da carga de trabalho,

10.000 n´os na rede e valor de alfa de 0.4, tamb´em com uma reputa¸c˜ao inicial de 0.8

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 111

para o n´o observado. O comportamento atribu´ıdo para o n´o ´e que o diferencia n este

cen´ario, onde o n´o realizar´a v´arias transa¸c˜oes positivas, enquanto sua reputa¸c˜ao

´e pesquisada na rede pelo n´o observador. Neste caso, espera-se que, ao ﬁnal da

simula¸c˜ao, a reputa¸c˜ao apresente um ganho. Por´em, teremos que considerar o peso

de sua reputa¸c˜ao obtida na rede. O n´o interessado pela reputa¸c˜ao pode ter um valor

no seu campo previousRep que n˜ao caracterize o comportamento do n´o ultimamente,

isso s´o pode ser obtido na rede atrav´es de uma consulta `a reputa¸c˜ao. Ap´os a busca,

o n´o obteve uma reputa¸c˜ao de 0.655.

Observando o gr´aﬁco da Figura 6.2 em rela¸c˜ao `a curva que mostra a varia¸c˜ao

das transa¸c˜oes positivas consecutivas, faz-se com que a baixa reputa¸c˜ao do n´o obtida

da rede provoque uma queda na primeira metade da simula¸c˜ao, fazendo com que na

segunda metade, a partir do ciclo 50 a reputa¸c˜ao come¸ce a ter um ganho, ﬁnalizando

em 0.721, o que representou um acr´escimo de 9.87%. Pode parecer estranho que um

n´o realizando somente transa¸c˜oes satisfat´orias tenha uma queda de reputa¸c˜ao no

in´ıcio da simula¸c˜ao, mas isto ´e justiﬁcado pela natureza do protocolo de reputa¸c˜ao

P2PWSRep, que leva em considera¸c˜ao as experiˆencias anteriores dos demais n´os da

rede com este n´o, bem como a experiˆencia anterior do n´o que est´a negociando uma

troca de recursos com ele. O que era esperado como resultado ao ﬁm d a simula¸c˜ao,

pela concep¸c˜ao do projeto P2PWSRep, foi obtido.

O pr´oximo experimento considera o n´o j , o n´o observado, realizando transa-

¸c˜oes insatisfat´orias durante a simula¸c˜ao, onde o n´o i faz sucessivas requisi¸c˜oes de sua

reputa¸c˜ao. Considerando que transa¸c˜oes insatisfat´orias s˜ao prejudiciais `a reputa¸c˜ao

de um n´o, o gr´aﬁco da Figura 6.2 deixa bem claro que o protocolo P2PWSRep

penaliza o n´o com um decr´escimo de reputa¸c˜ao consider´avel, como mostrado na

curva de reputa¸c˜ao mais acentuada ap´os estas transa¸c˜oes insatisfat´orias ao ﬁnal dos

100 ciclos de simula¸c˜ao. Assim, tendo a reputa¸c˜ao de j de 0.8 na tabela de reputa¸c˜ao

do n´o i, ao ﬁnal da reputa¸c˜ao seu valor equivale a 0.512, representando um a perda

de reputa¸c˜ao de 36% em rela¸c˜ao `a sua reputa¸c˜ao inicial. Ap´os a ocorrˆencia de v´arias

transa¸c˜oes negativas, a reputa¸c˜ao do n´o cai, inﬂuenciada pela reputa¸c˜ao anterior,

tamb´em baixa, e pelo comportamento negativo do n´o na rede P2P.

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 112

6.3.3 An´alise dos Resultados

Os resultados mostrados no gr´aﬁco da Figura 6.2 demonstram que o proto-

colo P2PWSRep conseguiu apresentar valores esperados para o comportamento dos

n´os, sendo que seria interessante considerar que o usu´ario pode ter em sua interface

gr´aﬁcos gerados pelo protocolo P2PWSRep que mostram o risco ou benef´ıcio de in-

teragir com determinados n´os na rede.

E bom ressaltar que o P2PWSRep n˜ao toma

decis˜oes autˆonomas para restringir o acesso a um n´o que tenha baixa reputa¸c˜ao,

at´e porque uma caracter´ıstica de redes que utilizam mecanismos de reputa¸c˜ao ´e que

os n´os novos tenham reputa¸c˜ao mais baixa que os n´os mais velhos, e para ganhar

reputa¸c˜ao devem oferecer recursos. O protocolo P2PWSRep mant´em associado ao

peerID `a idade do n´o. Assim, quando o usu´ario tomar conhecimento da reputa¸c˜ao

de um n´o, poder´a identiﬁcar se ele ´e um n´o antigo ou novo na rede. Controlar a

reputa¸c˜ao dos n´os pode ser algo inclusive independente do controle de reputa¸c˜ao de

recursos. Por´em, desaconselha-se que a reputa¸c˜ao de n´os e recursos do protocolo

P2PWSRep sejam trabalhadas de forma independente, pois a deﬁni¸c˜ao do protocolo

considera mais segura a aplica¸c˜ao das duas abordagens.

Para ajudar na compreens˜ao do proto colo de reputa¸c˜ao P2PWSRep, o gr´aﬁco

da Figura 6.3 apresenta a evolu¸c˜ao da reputa¸c˜ao de um n´o na rede. Este n´o foi ob-

servado na simula¸c˜ao enquanto as transa¸c˜oes satisfat´orias e insatisfat´orias ocorriam

aleatoriamente com v´arios n´os da rede, que interagiam com ele em busca de seus

recursos. Alguns recursos do n ´o foram assinalados como corrompidos para que nas

requisi¸c˜oes sejam geradas a¸c˜oes negativas e possam reﬂitir a reputa¸c˜ao do n´o. Em

vinte ciclos de simula¸c˜ao, o n´o parte de uma reputa¸c˜ao de 0.8 para 0.51, perdendo

36.25% de sua reputa¸c˜ao inicial. Percebe-se no gr´aﬁco que, nos momentos em que

o n´o realiza intera¸c˜oes positivas, ele come¸ca a ganhar reputa¸c˜ao, como observado

entre os ciclos 9 e 11, por´em as transa¸c˜oes insatisfat´orias se tornam novamente a

maioria, fazendo com que a reputa¸c˜ao descres¸ca novamente.

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 113

Figura 6.3: Gr´aﬁco de varia¸c˜ao da reputa¸c˜ao de um n´o da rede.

6.4 Cen´ario 2 - An´alise do Protocolo de Reputa-

¸c˜ao dos Recursos

O objetivo da simula¸c˜ao aplicada nesta se¸c˜ao ´e comprovar a eﬁciˆencia do

protocolo P2PWSRep em rela¸c˜ao ao controle de recursos corrompidos, infectados

ou com altera¸c˜oes de metadados a ﬁm de indisponibilizar o acesso aos mesmos na

rede P2P. O p rotocolo P2PWSRep foi elaborado com o objetivo de fazer tamb´em o

controle da reputa¸c˜ao dos recursos, j´a que o preju´ızo provocado por um n´o ego´ısta ´e

o desperd´ıcio de banda e intera¸c˜oes na rede, tornando-a mais lenta, por´em o preju´ızo

causado por recursos corrompidos na rede ´e bem maior, pois as taxas de transmiss˜ao

desperdi¸cadas por arquivos corrompidos s˜ao bem maiores que os causados por n ´os

ego´ıstas, sendo isso uma amea¸ca `a rede. Al´em disso, um arquivo infectado ´e uma

amea¸ca ao n´o participante da rede, e por conseguinte, `a rede. Evitar que estes

recursos permane¸cam na rede ou apontar para os n´os que os compartilham ´e um

dos objetivos do protocolo P2PWSRep.

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 114

6.4.1 Descri¸c˜ao do Cen´ario

Neste cen´ario, uma rede com 10.000 n´os foi populada com recursos ´ıntegros

e corrompidos. Os arquivos corrompidos foram disponibilizados em diversos n´os da

rede. V´arios n´os foram utilizados para fazer requisi¸c˜oes aos recursos contidos nestes

n´os que compartilham estes arquivos, e foi observada a evolu¸c˜ao das requisi¸c˜oes aos

n´os que possuem estes arquivos daniﬁcados. A simula¸c˜ao durou 25 ciclos e foram

iniciadas as requisi¸c˜oes em n´umero de mil por ciclo. A cada requisi¸c˜ao, o mecanis-

mo de obten¸c˜ao de reputa¸c˜ao de recurso foi utilizado, fazendo com que os n´os da

rede obtivessem os valores da reputa¸c˜ao dos recursos. Os mesmos recursos foram

espalhados na rede de forma que uma parte seja corrompida e outra parte, seja

´ıntegra. Para realiza¸c˜ao da simula¸c˜ao foi utilizado um mecanismo de inicializa¸c˜ao

de recursos aleatoriamente na rede, onde os n´os recebem recursos que podem ser

´ıntegros ou n˜ao. Alguns n´os que possuem recursos corrompidos foram assinalados

para serem observados durante a simula¸c˜ao. Apesar do protocolo P2PWSRep pos-

suir um mecanismo adaptativo para controle de TTL, nesta simula¸c˜ao utilizou-se

um valor ﬁxo de 4.

6.4.2 Resultados

Os resultados da simula¸c˜ao s˜ao apresentados no gr´aﬁco da Figura 6.4, onde se

percebe que inicialmente o n´umero de requisi¸c˜oes era de 997 requisi¸c˜oes por ciclo aos

n´os observados. A cada ciclo, dos 25 considerados, os n´os executaram o algoritmo de

reputa¸c˜ao para detec¸c˜ao dos arquivos corrompidos. Quando uma reputa¸c˜ao obtida

esta “corrompida”, o identiﬁcador do recurso e do n´o s˜ao adicionados `a tabela de

reputa¸c˜ao do n´o que iniciou a busca. Isso permite que, nas pr´oximas pesquisas de

busca na rede, da reputa¸c˜ao deste recurso, seja notiﬁcado ao n´o requisitante sobre a

reputa¸c˜ao ruim, fazendo que o mesmo busque outra fonte. O protocolo P2PWSRep

tamb´em notiﬁca o n´o que possui o recurso corrompido para que o mesmo seja

apagado, al´em de incrementar o n´umero de transa¸c˜oes insatisfat´orias com o n´o,

pois o mesmo est´a disponibilizando conte´udo polu´ıdo na rede.

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 115

Figura 6.4: Gr´aﬁco do n´umero de requisi¸c˜oes de arquivos corrompidos.

6.4.3 An´alise dos Resultados

O gr´aﬁco da Figura 6.4 mostra que, no ﬁnal da simula¸c˜ao, os n´umeros

de requisi¸c˜oes aos n´os que possuem os recursos corrompidos diminuiram para 603

requisi¸c˜oes por ciclo, o que comprova que a reputa¸c˜ao dos recursos corrompidos

foi propagada na rede e contribuiu para redu¸c˜ao do tr´afego da rede e aumento da

seguran¸ca, j´a que fez com que as fontes de arquivos corrompidos fossem identiﬁcadas

e que, requisi¸c˜oes que seriam realizadas para estas fontes fossem redirecionadas a ou-

tros n´os. Uma op¸c˜ao do protocolo P2PWSRep ´e apagar o arquivo da origem. Por´em,

isso abre para um novo tipo de ataque. O que pode ser feito ´e uma pr´e-negocia¸c˜ao da

remo¸c˜ao do arquivo, fazendo com que o n´o, mesmo com o arquivo corrompido, tenha

um ganho de reputa¸c˜ao por contribuir na elimina¸c˜ao do conte´udo polu´ıdo da rede

P2P. A redu¸c˜ao de requisi¸c˜oes a arquivos corrompidos foi consider´avel, 39.51%, em

uma simula¸c˜ao de 25 ciclos. Claro que deve ser considerado o volume de conte´udo

polu´ıdo, sendo que o mesmo p er maneceu constante durante a simula¸c˜ao, n˜ao tendo

sido injetados novos arquivos corrompidos.

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 116

6.5 Cen´ario 3 - An´alise do Protocolo quanto `a

Carga na Rede

A an´alise do protocolo P2PWSRep em rela¸c˜ao `a carga gerada na rede tem

como objetivo ter conhecimento e comprovar que ´e vi´avel utilizar o protocolo, sem

que seja adicionado um n´umero grande de intera¸c˜oes que possam aumentar o ﬂuxo

de dados de controle na rede, al´em de aumentar o tempo de resposta das opera¸c˜oes,

como busca de recursos, download de recursos, dentre outros, j´a que essas opera¸c˜oes

envolvem a ativa¸c˜ao do algoritmo de reputa¸c˜ao.

6.5.1 Descri¸c˜ao do Cen´ario

Na simula¸c˜ao, foi utilizada uma rede de 10.000 n´os, no mesmo ambiente

computacional das simula¸c˜oes anteriores. Os dados observados na simula¸c˜ao foram

o n´umero de mensagens trafegando na rede, considerando a varia¸c˜ao do TTL para

veriﬁcar o alcan¸ce da busca, isto ´e, o n´umero de n´os consultados na rede. Foram

injetadas v´arias consultas na rede, geradas por n´os que ﬁzeram opera¸c˜oes de buscas

de arquivos, de reputa¸c˜ao de n´os e de recursos. Medir o tempo de resposta das

opera¸c˜oes e o n´umero de n´os consultados na rede e os n´os que efetivamente res-

ponderam por alguma das requisi¸c˜oes foram os pontos principais observados nesta

simula¸c˜ao.

6.5.2 Resultados

O primeiro gr´aﬁco, ilustrado na Figura 6.5, mostra que, para um TTL de

valor 1 e 2, o alcance da rede ´e muito pequeno em rela¸c˜ao ao tamanho da mesma. O

valor d e TTL a p artir de 3 mostrou- se bom, j´a que se tem como resultado quase 50%

de n´os da rede consultados. Para o TTL igual 4, o n´umero de mensagem na rede

gerado foi de 12.053, sendo que o n´umero de n´os que foram consultados foi de 7.807,

representando 78% dos n´os da rede. Para o TTL igual a 5, o n´umero de mensagens

teve um aumento de pouco mais de 5.000 mensagens, para um aumento de alcance

de pouco mais de 1.600 n´os. Nos TTLs 6 e 7, o alcance ´e praticamente total na

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 117

rede, por´em o n´umero de mensagens geradas gira em torno de 20.000 trafegando na

rede, com a quantidade de n´os consultados bem pr´oxima de 10.000, isto ´e, quase a

totalidade da rede.

Figura 6.5: Gr´aﬁco do tr´afego de mensagens versus alcance de busca.

A Figura 6.6 traz os resultados de uma simula¸c˜ao para o tempo de resposta

de consultas de reputa¸c˜ao. Os dados avaliados foram o n´umero de mensagens de

reputa¸c˜ao recebidas como resposta, o n´umero de n´os consultados, de um total de

100 n´os que possuem informa¸c˜ao de reputa¸c˜ao para o n´o buscado e o tempo de

resposta. Os 100 n´os foram assinalados na inicializa¸c˜ao do experimento. No gr´aﬁco,

vˆe-se uma an´alise mais espec´ıﬁca do tempo de resposta de uma consulta de reputa¸c˜ao

versus a quantidade de n´os que respondem, dependendo do valor do TTL associado

`a consulta. A simula¸c˜ao aqui considerada populou 100 n´os da rede em rela¸c˜ao `a

reputa¸c˜ao de um n´o que ser´a pesquisada. O tamanh o da rede ´e de 10.000 n´os. Para

TTL 1 n˜ao houve resposta em rela¸c˜ao a reputa¸c˜ao do n´o buscado. Isso signiﬁca que

a profundidade da busca foi pequena demais para obter dados de reputa¸c˜ao. Com

TTL 2 e 3, o volume de n´os que responderam foi suﬁciente para que o protocolo

P2PWSRep tivesse dados para o c´alculo da reputa¸c˜ao, com um tempo de resposta

bom e dentro do esperado, entre 3 e 5 segundos. Para TTL 4 e 5, o n´umero de n´os

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 118

consultados foi bem pr´oximo: 69 e 72 n´os responderam, respectivamente, ao pedido

de reputa¸c˜ao. Por´em, o tempo de resposta foi alto, entre 8 e 11 segundos. Para

TTL 6 e 7, houve um aumento signiﬁcativo no tempo de reposta, chegando a ser

quase o dobro em rela¸c˜ao aos TTLs desses valores, por´em a resposta dos n´os foi

quase 100% dos n´os que tˆem dados de reputa¸c˜ao a respeito do n´o pesquisado.

Figura 6.6: Gr´aﬁco do n´umero de respostas de reputa¸c˜ao versus tempo.

6.5.3 An´alise dos Resultados

Diante dos dados, pode-se veriﬁcar que quanto maior o TTL, maior a pr o-

fundidade da consulta. Por´em, o volume de m ensagens trafegando na rede pode

sobrecarregar os n´os, j´a que os mecanismos de processamento de roteamento e re-

puta¸c˜ao utilizam ﬁlas (tabelas hashtable) para fazer esses controles, acarretando

em um n´umero muito grande de mensagens armazenadas nas ﬁlas e um n´umero

muito grande de r´eplicas trafegando na rede. O TTL usual para a rede P2PWS

´e 3. O pr otocolo P2PWSRep possui um mecanismo adaptativo que ajusta o TTL

para um n´umero de respostas que pode ser aceito pelo protocolo ou usu´ario. Assim,

o protocolo P2PWSRep pode variar seu alcance de 2 a 6, fazendo que a maioria

das consultas possa obter respostas sem u ma profundidade muito grande, logo nos

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 119

primeiros valores de TTL.

Isso nos permite avaliar que o atraso na resposta da reputa¸c˜ao pode ser

prejudicial pelo tamanho da janela de tempo deﬁnida no n´o que iniciou a busca.

O protocolo P2PWSRep utiliza um mecanismo adaptativo para regular o TTL, de

forma que isso possa ser de acordo com a posi¸c˜ao do n´o na rede e dos recursos que

ele b usca, mas isso n˜ao signiﬁca que haja uma limita¸c˜ao da profundidade da rede,

mas sim uma diminui¸c˜ao do n´umero de mensagens devido `a obten¸c˜ao de recursos e

dados de reputa¸c˜ao em fontes mais pr´oximas. O valor da janela de tempo para a

pesquisa, ent˜ao, ser´a regulada de acordo com o TTL. Assim, o protocolo ﬁca livre

para fazer controle de TTL adaptativo at´e o TTL de valor 6, sendo que o valor

m´ınimo que o protocolo P2PWSRep tr abalha ´e 2.

6.6 Considera¸c˜oes Finais

Pelos resultados apresentados nos trˆes cen´arios de simula¸c˜ao realizados,

conclui-se que o protocolo P2PWSRep teve um comportamento esperado para o

que foi proposto e, em compara¸c˜ao a outros protocolos, um desempenho bastante

razo´avel, j´a que foi deﬁnido em uma arquitetura descentralizada e sem qualquer

mecanismo de otimiza¸c˜ao de buscas e consultas na rede. O n´umero de mensagens

geradas na rede foi melhorado pela janela de tempo estabelecida no n´o requisitante,

de buscas a recursos e reputa¸c˜ao, pelo TTL adaptativo que possibilita uma redu¸c˜ao

no n´umero de requisi¸c˜oes para TTLs menores e pela forma com que a reputa¸c˜ao de

n´os e recursos ´e consultada, isto ´e, n˜ao h´a uma mensagem de consulta para cada n´o

ou recurso, mas uma mensagem que cont´em um array de n´os ou recursos que ser˜ao

consultados.

O tempo de resposta em rela¸c˜ao `as consultas de reputa¸c˜ao tamb´em mostrou

que o protocolo tem um mecanismo de c´alculo simples, sem envolver um n´umero

muito grande de intera¸c˜oes ou controles mais seguros de troca de mensagens, uti-

lizando criptograﬁa, como ocorre em outros protocolos.

O protocolo P2PWSRep foi p rojetado para controlar a reputa¸c˜ao de n´os e

CAP

ITULO 6. SIMULAC¸

AO DO PROTOCOLO P2PWSREP 120

recursos, sendo que os dados obtidos da reputa¸c˜ao mostraram que o n´umero de

requisi¸c˜oes a arquivos corrompidos foi reduzido em 40%, levando `a conclus˜ao que o

protocolo consegue eliminar da rede as intera¸c˜oes com n´os que detˆem estes recursos

esp´urios. A evolu¸c˜ao da reputa¸c˜ao de n´os tamb´em foi como esperada, onde no gr´aﬁco

da Figura 6.2 s˜ao mostradas trˆes curvas de varia¸c˜ao de reputa¸c˜ao, que permitem

visualizar um comportamento de reputa¸c˜ao bem comum em redes sociais ou P2P.

Uma an´alise geral do resultado da aplica¸c˜ao do protocolo P2PWSRep mostra

que o n´o que n˜ao compartilha seus dados perde reputa¸c˜ao naturalmente, devido `a

inﬂuˆencia hist´orica de sua reputa¸c˜ao ser inferior `a atual, al´em do que o c´alculo da

reputa¸c˜ao u tilizado pelo protocolo P2PWSRep preza pela reputa¸c˜ao mais recente,

dada a parametriza¸c˜ao escolhida. Quanto `a reputa¸c˜ao de recursos, a diminui¸c˜ao do

n´umero de requisi¸c˜oes a fontes comprometidas mostra mais um ponto positivo no

protocolo, al´em dos mecanismos inseridos para ajuste de busca na rede, diminuindo

o grau de inunda¸c˜ao, n´umero de mensagens e tempos de reposta.

Cap

ıtulo 7

Conclus˜ao

A deﬁni¸c˜ao do protocolo de reputa¸c˜ao P2PWSRep possibilita o emprego de

t´ecnicas para identiﬁcar e evitar que n´os mal-intencionados prejudiquem o desem-

penho da infraestrutura da r ede P2P, bem como a diminui¸c˜ao do conte´udo polu´ıdo

nessas redes. O trabalho tamb´em busca demonstrar que a interoperabilidade e

extensibilidade das redes P2P ´e vi´avel, com a utiliza¸c˜ao de servi¸cos web.

7.1 Contribui¸c˜oes

Reduzir o n´umero de n´os mal-intencionados e conte´udo polu´ıdo das redes

P2P n˜ao ´e uma tarefa trivial, principalmente devido `as particularidades dessas redes,

que prezam por anonimato e uma independˆencia em rela¸c˜ao a elementos moderado-

res. Propor um protocolo de reputa¸c˜ao e apresentar um modelo baseado em servi¸cos

foi um desaﬁo, pois a alta escalabilidade das redes P2P e o volume do tr´afego gerado

por esse tipo de rede exige que as intera¸c˜oes do protocolo n˜ao adicionem sobrecargas

`a r ede. O protocolo P2PWSRep prezou, desde sua concep¸c˜ao, pela deﬁni¸c˜ao de

mecanismos para redu¸c˜ao do overhead de processamento de mensagens, mas sem

deixar de lado a seguran¸ca contra os principais ataques a que estas r edes est˜ao

suscept´ıveis. Dentre as contribui¸c˜oes deste trabalho, podemos enumerar:

• Arquitetura simples e que proporciona escalabilidade, uma vez que utiliza

uma arquitetur a de redes descentralizada e um modelo orientado a servi¸cos,

121

CAP

ITULO 7. CONCLUS

AO 122

que reduz as limita¸c˜oes impostas por ﬁrewalls, proxies, IPS e outros tipos

de ferramentas de seguran¸ca de redes, j´a que as mensagens trafegam sobre o

protocolo HTTP;

• Protocolo gen´erico, que pode ser utilizado por v´arios tipos de aplica¸c˜oes, pois

o mesmo faz a avalia¸c˜ao da repu ta¸c˜ao em rela¸c˜ao a um recurso qualquer,

considerando caracter´ısticas da aplica¸c˜ao e n˜ao do recurso compartilhado;

• C´alculo de reputa¸c˜ao distribu´ıdo realizado em trˆes etapas. A primeira ´e a

obten¸c˜ao da reputa¸c˜ao do n´o (F´ormula 5.1) atrav´es de uma busca na rede.

Na segunda etapa, ´e realizada uma m´edia aritm´etica (F´ormula 5.2) no n´o

que busca a reputa¸c˜ao a ﬁm de normalizar os valores obtidos da rede. Por

´ultimo, ´e realizado o c´alculo da reputa¸c˜ao utilizando uma m´edia ponderada

exponencial (F´ormula 5.3), considerando o ´ultimo valor da reputa¸c˜ao obtido

da rede, contido no campo previousRep e o valor atual obtido. O parˆametro

alfa da F´ormula 5.3, da m´edia ponderada exponencial ´e utilizado para dar

mais ˆenfase `a reputa¸c˜ao atual ou a anterior. No caso do P2PWSRep, o valor

de alfa escolhido foi de 0.4, dando mais ˆenfase `a reputa¸c˜ao atual, por´em sem

desconsiderar a reputa¸c˜ao anterior do pr´oprio n ´o, j´a que considerar somente

a reputa¸c˜ao dada por outros n´os poderia comprometer a transa¸c˜ao;

• Proporciona interoperabilidade e extensibilidade ao seguir a metodologia de

orienta¸c˜ao a servi¸cos e a deﬁni¸c˜ao de metadados em formato XML. A deﬁni¸c˜ao

de suas interfaces possibilita o protocolo ser extens´ıvel, podendo ser utilizado

por v´arios tipos de aplica¸c˜oes de redes P2P, tais como, compartilhamento

de arquivos, grades de computadores que compartilham recursos, sites de

vendas de mercadorias, an´alise de risco de mercado ﬁnanceiro, sites de rela-

cionamentos, dentre muitas outras. A extensibilidade possibilita a adi¸c˜ao de

mecanismos de seguran¸ca, altera¸c˜oes de mecanismos de b usca ou at´e mesmo

a topologia da rede, d e forma mais simples e modular, al´em da possibilidade

de integra¸c˜ao com redes P2P j´a existentes, pela deﬁni¸c˜ao de gateways.

• Redu¸c˜ao na gera¸c˜ao do n´umero de mensagens, em rela¸c˜ao a outros protocolos,

CAP

ITULO 7. CONCLUS

AO 123

utilizando v´arios mecanismos. O primeiro deles ´e a busca de reputa¸c˜ao de n´os

e recursos utilizando um array com v´arios n´os ou recursos a serem consultados,

ao inv´es de gerar uma mensagem para cada n´o ou recurso pesquisado. O array

para as buscas ´e bem estruturado, contendo somente o identiﬁcador de cada

n´o ou recurso. A resposta adiciona um campo ao array que ´e o valor de repu-

ta¸c˜ao para os n´os ou c´odigo de avalia¸c˜ao do recurso. O segundo mecanismo

´e o TTL adaptativo associado a uma janela de tempo para processamento

das mensagens, que possibilita que as buscas utilizem uma profundidade de

acordo com a localiza¸c˜ao dos n´os na rede, em rela¸c˜ao aos recursos ou reputa-

¸c˜oes buscadas. Esses mecanismos contribuem diretamente para a redu¸c˜ao do

n´umero de mensagens na rede, apresentando um bom desempenho e tempo

de resposta, como mostrado nas simula¸c˜oes realizadas, mesmo para uma rede

P2P descentralizada como a aqui proposta.

7.2 Trabalhos Futuros

As redes P2P tˆem sido muito utilizadas em diversos tipos de aplica¸c˜oes.

Contudo, um fator negativo em rela¸c˜ao ao seu crescimento ´e o surgimento de novas

t´ecnicas para comprometer o funcionamento das mesmas. Algoritmos de reputa¸c˜ao

tˆem sido uma boa solu¸c˜ao para diminuir o impacto desses ataques e reduzir o n´umero

de n´os mal-intencionados e a polui¸c˜ao dessas redes, causadas pelo grande volume de

recursos corrompidos ou infectados. Todavia, as redes P2P n ˜ao est˜ao livres desses

ataques, pois muitos deles trabalham abaixo da camada do protocolo de reputa¸c˜ao,

atingindo o mecanismo de ingresso na rede, gera¸c˜ao de identiﬁcadores, roteamento

de mensagens, etc. Assim, durante a elabora¸c˜ao do protocolo P2PWSRep foram

identiﬁcados algumas contribui¸c˜oes que podem ser adicionadas por trabalhos fu-

turos, tais como:

• Adi¸c˜ao de mecanismos de seguran¸ca ao protocolo, atrav´es da utiliza¸c˜ao de

criptograﬁa segundo o padr˜ao WS-Security (OASIS), proporcionando suporte

`a integridade e conﬁdencialidade das mensagens, ao permitir que os integrantes

CAP

ITULO 7. CONCLUS

AO 124

da rede se comuniquem trocando mensagens criptografadas e assinadas digital-

mente. Al´em disso, valida¸c˜ao de identiﬁcadores de n´os e recursos para evitar

ataques do tipo sybil ou whitewashing;

• A implementa¸c˜ao do prot´otipo em si, da rede P2PWSRep, pois foram deﬁnidos

o modelo de servi¸cos e realizadas simula¸c˜oes do algoritmo de reputa¸c˜ao. Obter

resultados de uma aplica¸c˜ao real ser´a muito interessante para consolidar o

protocolo P2PWSRep como uma boa solu¸c˜ao para aplica¸c˜oes P2P;

• Adapta¸c˜ao do protocolo P2PWSRep para utilizar uma arquitetura centrali-

zada ou com supern´os;

• Introdu¸c˜ao de mecanismos de resposta autom´atica a ataques, tais como de-

tec¸c˜ao e remo¸c˜ao de n´os da rede identiﬁcados como maliciosos e detec¸c˜ao e

remo¸c˜ao de recursos da rede corrompidos ou infectados;

• Utiliza¸c˜ao de outras m´etricas, tais como volume de dados compartilhados,

n´umero de respostas a buscas de reputa¸c˜ao de n´os e recursos, diponibilidade

do n´o, etc., para avaliar a reputa¸c˜ao dos n´os, al´em de transa¸c˜oes efetivamente

conclu´ıdas.

Referˆencias Bibliogr´aﬁcas

[Abinader and Lins] , Abinader, Jorge Ab´ılio; Lins, Rafael Dueire. Web Services

em Java. Rio de Janeiro. Brazport, 2006.

[Adar and Huberman, 2000] , E. Adar e B. Huberman, Free Riding on Gnutella.

Xerox Palo Alto Research Center, Technical Report, August - 2000. Dispon´ıvel:

http://citeseer.ist.psu.edu/adar00free.html.

[Addison, 2002] , Addison Wesley, Peer to Peer: Collaboration and Sharing over

the Internet, 2002.

[Andersen et al., 2001] , Andersen, D., Balakrishnan, H., Kaashoek, F. Morris, R.,

Resilient Overlay Networks, 18th ACM Symposium on Operating Systems Prin-

ciples, Banﬀ/Canada, Outubro de 2001.

[Andrade et al., 2008] , Andrade, N., Brasileiro, F., Cirne, W., and Mowbray, M.

(2004). Discouraging free riding in a peer-to-peer cpu-sharing grid. In 13th IEEE

Symposium on High Performance Distributed Computing (HPDC’04).

[Barcellos and Gaspary, 2006] , Seguran¸ca e m Redes P2P: Princ´ıpios, Tecnologias

e Desaﬁos, 2006.

[Benz and Durant, 2003] , Benz, Brian., Durant, John R., XML Programming

Bible, 2003.

[BitTorrent, 2008] , BitTorrent. http://bitconjurer.org/bittorrent/.

[Buford et al., 2009] , Bu ford, John F., Yu, Heather., Lua, Eng Keong. P2P Net-

working and Applications, Morgan Kaufmann, 2009.

125

REFER

ENCIAS BIBLIOGR

AFICAS 126

[CacheLogic Reseach, 2006] , http://www.cachelogic.com/research., 2006.

[Cheng and Friedman, 2005] , Cheng, A. and Friedman, E. (2005). Sybilproof repu-

tation mechanisms. In P2PECON ’05: Proceeding of the 2005 ACM SIGCOMM

workshop on Economics of peer-to-peer systems, pages 128-132, New York, NY,

USA. ACM Press.

[Costa et al., 2005] , Costa, Cristiano., Soares, Vanessa., Benevenuto, Fabricio.,

Vasconcelos, Marisa., Almeida, Jussara., Almeida, Virgilio., Mowbray, Miranda.

Dissemina¸c˜ao de Conte´udo Polu´ıdo em redes P2P, UFMG, 2005.

[Chiozzotto and Silva, 1999] , Chiozzotto, Mauro., Silva, Lu´ıs Antonio Pinto da.

TCP/IP: tecnologia e implementa¸c˜ao, Ed.

Erica, S˜ao Paulo, 1999.

[Da Silva, 2007] , Da Silva, Juliano Freitas., M´etodos para Conten¸c˜ao de Polui¸c˜ao

em Redes P2P, UNISINOS, 2007.

[Damiani et al., 2002] , Damiani, E., Vimercati, S. C., Paraboschi, S., Samarati,

P. and Violante, F. (2002). A Reputation-Based Approach for Choosing Reliable

Resources in Peer-to-Peer Networks. In: Computer and Communications Security

(CCS’02), November 18-22, Washington DC, USA.

[Do Carmo et al., 2006] , Do Carmo, S. B., Barbar, G. S., Coelho, Barbosa, J. F.,

A New Classiﬁcation for Peer-to-peer Networks Architectures. IEEE, 2006.

[Douceur, 2002] , Douceur, J. R. (2002). The sybil attack. In 1st International Work-

shop on Peer-to-Peer Systems.

[Dumitriu et al., 2005] , Dumitriu, D., Knightly, E., Kuzmanovic, A., Stoica, I., and

Zwaenepoel, W. (2005). Denial-of-service resilience in peer-to-peer ﬁle sharing

systems. In ACM SIGMETRICS, 2005.

[eBay, 2008] , eBay (2008). Ebay website. http://www.ebay.com/.

[eDonkey, 2008] , eDonkey Overnet(2008). http://edonkey2000.com/.

[ESM, 2008] , ESM (2008), End System Multicast. http://esm.cs.cmu.edu/.

REFER

ENCIAS BIBLIOGR

AFICAS 127

[FastTrack, 2008] , Fasttrack. http://www.fasttrack.com.

[Feldman et al., 2004] , Feldman, M., Lai, K., Stoica, I., and Chuang, J. . Robust

incentive techniques for peer-to-peer networks. Proceed ings of the 5th ACM con-

ference on Electronic commerce, pages 102 111, New York, NY, USA. ACM Press,

2004.

[Ferris and Farrell, 2003] , What are Web Services?, Communications of the ACM,

Vol. 46, No. 62003, June 2003.

[Genome@Home, 2008] , Genome (2006). Genome@home.

http://genomeathome.stanford.edu/.

[Gnutella, 2008] , Gnutella (2008). Gnutella website. http://www.gnutella.com/.

[GoogleTalk, 2008] , Google Inc. (2008), www.google.com/talk/intl/pt-BR/.

[Grandison and Sloman, 2000] , Grandison, T. and Sloman, M. (2000). A survey of

trust in internet applications. IEEE Communications Surveys, 3(4):2-16.

[GT-P2P, 2008] , Grupo de Trabalho em Computa¸c˜ao Colaborativa (GT-P2P) -

RNP, www.gprt.ufpe.br/gtp2p, 2008.

[Gupta, 2003] , Gupta, M., Judge, P., and Ammar, M. (2003). A Reputation System

for Peer-to-peer Networks. In NOSSDAV ’03: Proceedings of the 13th interna-

tional workshop on Network and operating systems support for digital audio and

video, pages 144-152, New York, NY, USA. ACM Press.

[ICQ, 2008] , ICQ (2008). ICQ.com website. http://www.icq.com/.

[InteGrade, 2008] , Integrade, www.integrade.org.br, 2008.

[IRTF-P2P-GROUP, 2008] , Peer-to-Peer Research Group.

http://www.irtf.org/charters/p2prg.html.

[Jabber, 2008] , Jabber (2008). Jabber: Open instant messaging and a whole lot

more, powered by xmpp. http://www.jabber.org/.

REFER

ENCIAS BIBLIOGR

AFICAS 128

[Jacobson, 1988] , Jacobson. Congestion avoidance and control, 1988.

[(Kamvar et al., 2003] , Kamvar, S. D., Schlosser, M. T., and Garcia-Molina, H.

(2003). The eigentrust algorithm for reputation management in p2p networks. In

Proceedings of the 12th international conference on World Wide Web (WWW

’03), pages 640-651, New York, NY, USA. ACM Press.

[Kazaa, 2008] , Kazaa (2008). Kazza web site. http://www.kazaa.com.

[LawsTalk, 2008] , Lawstalk, http://laws.deinf.ufma.br, 2008.

[Liang et al., 2005] , Liang, J., Kumar, R., Xi, Y., and Ross, K. W. (2005). Pollution

in p2p ﬁle sharing systems. In Proc. of IEEE Infocom, Miami, FL, USA.

[Loo, 2003] , A. W. Loo, The Future of The Peer-to-Peer Computing, Communica-

tions of the ACM, 46(9), pp.57-61, 2003.

[Marti and Garcia-Molina, 2006] , Marti, S. and Garcia-Molina, H. (2006). Taxon-

omy of trust: Categorizing p2p reputation systems. Comput er Networks, 50(4):472

484.

[MercadoLivre, 2008] , Mercado Livre web si te. http://www.mercadolivre.com.br.

[MSN, 2008] , MSN (2008). MSN.com website. http://www.msn.com/.

[Napster, 2008] , Napster, www.napster.com/., 2008.

[Oasis, 2008] , Modelo de Referˆencia para Arquitetura Orientada a Servi¸co 1.0. OA-

SIS Committee Speciﬁcation Business Transaction Protocol, Vers˜ao 1.0, Julho

2006.

[OpenNap, 2008] , OpenNap (2006). OpenNap: Open Source Napster Server web-

site. http://opennap.sourceforge.net/.

[PeerSim, 2009] , Jelasity., M´ark , Montresor., Alberto , Jesi, Gian Paolo., Voul-

garis., Spyros. The PeerSim Simulator. http://peersim.sf.net/.

REFER

ENCIAS BIBLIOGR

AFICAS 129

[Parameswaran et al., 2001] , Parameswaran, M., Susarla, A., Whinston, A., P2P

Networking: An Information-S haring Alternative. IEEE Computer, Julho de

2001.

[Righi et al., 2004] , RIGHI, Rafael R., Pellissari, Felipe R., Westphall, Carla M.

Escambo: Um Modelo de Reputa¸c˜ao e Micropagamentos para Sistemas Peer-to-

Peer, CBComp. 2004.

[Rocha et al., 2004] , Peer-to-Peer: Computa¸c˜ao Colaborativa na Internet. Mini-

curso, SBRC, 2004.

[Sadok, 2003] , Computa¸c˜ao Colaborativa (P2P), Technical Work, Gru po

de Trabalho da Rede Nacional de Pesquisa - mar¸co 2003. Dispon´ıvel:

http://www.rnp.br/arquivo/gt/2003/p2p.pdf.

[Seti@Home, 2008] , SETI (2006). SETI@home website.

http://setiathome.ssl.berkeley.edu/.

[Skype, 2008] , Skype (2008). Skype. http://www.skype.com/.

[Stallings, 2007] , Stallings, William., Criptograﬁa e Seguran¸ca de Redes: Princ´ıpios

e Pr´aticas. Prentice-Hall, 2007.

[Ting and Deters, 2003] , Ting, Nyik San, Deters, Ralph. A Generic Peer-to-Peer

Network Simulator, technical report, Department of Computer Science, Univer-

sity of Saskatchewan, Junho de 2003.

[W3C, 2008] , Web services deﬁnition from W 3C Web S ervices Architecture Work-

ing Group, Web Services Architecture Requirements, W3C Working Draft, ( Aug.

19, 2002); www.w3.org/TR/2002/WD-wsa-reqs-20020819

[Weerawarana et al, 2005] , Weerawarana, Sanjiva; Curbera, Francisco; Leymann,

Frank; Storey, Tony; Ferguson, Donald F. Web Services Platform Architecture:

SOAP, WSDL, W S-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging,

and More. Prentice Hall, 2005.

REFER

ENCIAS BIBLIOGR

AFICAS 130

[Wilson, 2004] , Brendon J. Project Jxta book, Vancouver, Canada, 2004.

[Xiong and Liu, 2004] , L. Xiong and L. Liu. Peertrust: Supporting reputation-based

trust for peer-to-peer electronic communities. IEEE TKDE,16(7):843-857, July

2004.

[YahooMessenger, 2008] , Yahoo Inc., http://br.messenger.yahoo.com, 2008.

[Yang and Molina, 2003] , B. Yang e H. Garcia-Molina, Ppay: Micropayments for

Peer-to-Peer Systems, in Proc. 2003 CCS, pp. 27-31.

Apˆen d iceAn exos

endice A

Listagens de c´odigos de arquivos fontes e arquivos de conﬁgura¸c˜ao do ambiente de

simula¸c˜ao.

A.1 Anexo 1

Este anexo mostra o arquivo utilizado para conﬁgura¸c˜ao do simulador PeerSim.

Listagem A.1: Arquivo de conﬁgura¸c˜ao da simula¸c˜ao

1 s i m ul a t io n . c y c l e s 200

2 s i m ul a t io n . ex per imen ts 1

4 c o n t r o l . 0 p eersim . cdsim . S h u f f l e

6 network . s i z e 10000

7 network . maxSize 15000

8 network . node P2PWSRepNode

10 i n c l u d e . p r o t o c o l gnu

12 p r o t o c ol . gnu p2pwsrep . Gn u t e ll a Pr ot o co l

13 p r o t o c ol . gnu . t t l 4

15 i n i t . 0 peers im . dynamics . WireScaleFreeBA

16 i n i t . 0 . p r o t o c o l gnu

17 i n i t . 0 . k 2

18 i n i t . 0 . und ir

131

ENDICE A. 132

20 i n i t . 1 p2pwsrep . P 2P WS Re pI n it ia li ze rF ile s

21 i n i t . 2 p2pwsrep . P2PWSRep I nitializerReputa t ion

22 i n i t . 3 p2pwsrep . P 2PW SR epI ni tia li z er Rep ut ati on F il es

24 i n i t . 4 p2pwsrep . P2PWSRepInitializer

25 i n i t . 4 . p r o t o c o l gnu

26 i n i t . 4 . keyword rock

27 i n i t . 4 . que ry

nod es 1

28 i n i t . 4 . q u e r y

i n t e r v a l 4

29 i n i t . 4 . max

que rie s 1

31 c o n t r o l . 0 p eersim . r e p o r t s . GraphStats

32 c o n t r o l . 0 . p r o t o c o l p2pwsrep

33 c o n t r o l . 0 . undi r

34 c o n t r o l . 0 . n l 1

35 c o n t r o l . 0 . nc −1

37 c o n t r o l . 1 p2pwsrep . P2PWSRepGraphStats

38 c o n t r o l . 1 . p r o t o c o l p2pwsrep

39 c o n t r o l . 1 . o u tf graph−s t a t s

40 c o n t r o l . 1 . o n ly o n e c y c l e

41 c o n t r o l . 1 . from 0

A.2 Anexo 2

Este anexo mostra um log de sa´ıda de uma simula¸c˜ao.

Listagem A.2: Log de sa´ıda da simula¸c˜ao da rede P2PWS

1 Sim ulat or : lo ad i n g c o n f i g u r a t i o n

2 C o n f i gP r o p e r t i e s : F i l e temp late /p2wsprep−s im u la t or . tx t loa d ed .

3 Sim ulat or : Number o f ex p eri ment s 1

4 Sim ulat or : s t a r t i n g experiment 0 in vo ki ng pe ersim . cdsim . CDSimulator

5 Random see d : 123456789

6 CDSimulator : r e s e t t i n g

7 tamanho da red e : 10

ENDICE A. 133

8 CDSimulator : r u n ning i n i t i a l i z e r s

9 C o n f ig u ra t io n f i l e s to nodes

10 The s i m ul a t io n w i l l se a rc h f o r : rock

11 − Running i n i t i a l i z e r i n i t . 0 : cl a ss pee rsim . dynamics . WireScaleFreeBA

12 − Running i n i t i a l i z e r i n i t . 1 : cl a ss p2pwsrep . P2P WS Re pI ni t ia li ze rF il e s

13 <<< F i l e c r e a t e in node 8 >>>

14 <<< F i l e c r e a t e in node 3 >>>

15 − Running i n i t i a l i z e r i n i t . 2 : cl a ss p2pwsrep .

P2PWSRepIn i tializerReputatio n

16 − Running i n i t i a l i z e r i n i t . 4 : cl a ss p2pwsrep . P2PWSRepInitializer

17 CDSimulator : s t a r t i n g s im u l at i o n

18 I t ’s searching in nodeId : 0

19 Node : 0 sending to: 2

20 It’ s s e a r ch i n g in nodeId : 2

21 2 f or wa r di ng to node : 8 t t l : 1 type : 0

22 2 f or wa r di ng to node : 3 t t l : 1 type : 0

23 2 f or wa r di ng to node : 4 t t l : 1 type : 0

24 2 f or wa r di ng to node : 1 t t l : 1 type : 0

25 I t ’s searching in nodeId : 3

26 File found in nodeId 3 ---> File name: rock music

27 It’ s s e a r ch i n g in nodeId : 4

28 4 f or wa r di ng to node : 1 t t l : 2 type : 0

29 4 f or wa r di ng to node : 5 t t l : 2 type : 0

30 5 f or wa r di ng to node : 9 t t l : 1 type : 3

31 5 f or wa r di ng to node : 6 t t l : 1 type : 3

32 5 f or wa r di ng to node : 7 t t l : 1 type : 3

33 5 f or wa r di ng to node : 8 t t l : 1 type : 3

34 [ . . . ]

36 7 f or wa r di ng to node : 9 t t l : 2 type : 3

37 7 f or wa r di ng to node : 1 t t l : 2 type : 3

38 I t ’s searching in nodeId : 7

39 7 forwarding to node: 9 ttl: 4 type: 0

40 7 forwarding to node: 1 ttl: 4 type: 0

41 It’ s s e a r ch i n g in nodeId : 8

42 F i l e found i n nodeId 8 −−−> F i l e name : rock music

43 8 f or wa r di ng to node : 2 t t l : 1 type : 4

ENDICE A. 134

44 8 f or wa r di ng to node : 2 t t l : 2 type : 3

45 I t ’s searching in nodeId : 9

46 9 forwarding to node: 5 ttl: 1 type: 4

47 It’ s s e a r ch i n g in nodeId : 1

48 1 f or wa r di ng to node : 3 t t l : 2 type : 0

49 1 f or wa r di ng to node : 4 t t l : 1 type : 3

50 1 f or wa r di ng to node : 2 t t l : 1 type : 3

51 [ . . . ]

Livros Grátis
( http://www.livrosgratis.com.br )
 
Milhares de Livros para Download:
 
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas

Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
 
 