lp2pfs:umclientevfs...

LP2PFS: Um Cliente VFSLinux para o Sistema LP2P

por

Daniel Stefani Marcon

UNIVERSIDADE DO VALE DO RIO DOS SINOS

DANIEL STEFANI MARCON

LP2PFS: Um Cliente VFS Linux parao Sistema LP2P

Monografia apresentada como requisitoparcial para a obtenção do grau deBacharel em Ciência da Computação

Prof. Dr. Rafael Bohrer ÁvilaOrientador

São Leopoldo, Dezembro de 2010

“Making the simple complicated is commonplace;making the complicated simple, awesomely simple,

that’s creativity.— Charles Mingus

DEDICATÓRIA

Dedico este trabalho a minha dinda-mãe Darcila, que sempre me apoiou e meajudou em todos os momentos da minha vida.

AGRADECIMENTOS

Agradeço, em primeiro lugar, a Deus, por ter me proporcionado finalizar estetrabalho.

Agradeço a minha dinda-mãe Darcila e ao meu dindo Fausto pela ajuda emtodos os momentos durante esse trabalho, que me apoiaram durante toda a minhavida para mim chegar até aqui.

Agradeço ao meu orientador Rafael, por toda a orientação durante o trabalho,pelos conselhos sobre a melhor forma de implementar o sistema de arquivos, sobreo que escrever e como apresentar o projeto nessa monografia e pelas revisões dessetexto.

Agradeço a todos os meus amigos que me ajudaram durante esse trabalho, diretaou indiretamente.

SUMÁRIO

LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . 7

LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

LISTA DE LISTAGENS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1 Sistemas Centralizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.1 Network File System - NFS . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.2 Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Sistemas Distribuídos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.1 Coda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.2 Serverless Network File System - xFS . . . . . . . . . . . . . . . . . . . 26

2.3 Sistemas Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3.1 Gnutella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3.2 Freenet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3.3 Ivy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.4 BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4 Síntese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3 LOCAL PEER-TO-PEER PROTOCOL . . . . . . . . . . . . . . . . . . 40

3.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.2 Mensagens de Comunicação Interna . . . . . . . . . . . . . . . . . . . . . 44

3.3 Módulos Externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4 LP2P FILE SYSTEM . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.1 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.1.1 Virtual File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.1.1.1 Mapeamento dos Metadados dos Arquivos . . . . . . . . . . . . . . . 55

4.1.2 Page Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.1.2.1 Mapeamento dos Dados dos Arquivos . . . . . . . . . . . . . . . . . 57

4.2 Otimizações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.3 Comunicação com o LP2P . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.4 Notificação de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.5 Arquivo no Sistema Procfs . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.6 Opções de Montagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5 VALIDAÇÃO E RESULTADOS EXPERIMENTAIS . . . . . . . . . . . 64

5.1 Versões do Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2 Disponibilização dos Arquivos . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3 Testes no Sistema LP2P . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface

CA-NFS Congestion Aware Network File System

CIFS Common Internet File System

CHK Content-hash Key

DNS Domain Name System

DNS-SD Domain Name System Based Service Discovery

FTP File Transfer Protocol

GCC GNU Compiler Collection

GNU GNU’s Not Unix!

HTTP Hypertext Transfer Protocol

KSK Keyword-signed Key

LAN Local Area Network

LFS Log-structured File Systems

LRU Least Recently Used

mDNS Multicast Domain Name System

NFS Network File System

P2P Peer-to-Peer

pNFS Parallel Network File System

POSIX Portable Operating System Interface

RAID Redundant Arrays of Inexpensive Disks

RPC Remote Procedure Call

RTT Round-Trip Time

SHA Secure Hash Algorithm

SMB Server Message Block

SSK Signed-subspace Key

VFS Virtual File System

TTL Time-to-live

xFS Serverless Network File System

LISTA DE FIGURAS

Figura 1.1: Estrutura do sistema LP2P . . . . . . . . . . . . . . . . . . . . . . 17

Figura 2.1: Estado da página em memória com escrita assíncrona . . . . . . . . 21

Figura 2.2: Estrutura de um cliente Coda . . . . . . . . . . . . . . . . . . . . . 25

Figura 2.3: Leitura de um bloco no sistema xFS (fonte: Anderson et al. (1996)) 27

Figura 2.4: Estrutura da rede Gnutella . . . . . . . . . . . . . . . . . . . . . . 29

Figura 2.5: Rede de sobreposição Gnutella com os nodos mal distribuídos . . . . 30

Figura 2.6: Procura de um arquivo na rede Freenet . . . . . . . . . . . . . . . . 33

Figura 2.7: Estrutura do sistema Ivy . . . . . . . . . . . . . . . . . . . . . . . . 34

Figura 3.1: Funcionamento do LP2P . . . . . . . . . . . . . . . . . . . . . . . 41

Figura 3.2: Arquitetura do sistema LP2P . . . . . . . . . . . . . . . . . . . . . 42

Figura 3.3: Comunicação interna do sistema LP2P . . . . . . . . . . . . . . . . 44

Figura 3.4: Estrutura da mensagem LP2P . . . . . . . . . . . . . . . . . . . . . 44

Figura 3.5: Formato da mensagem llist . . . . . . . . . . . . . . . . . . . . . . 45

Figura 3.6: Formato da mensagem lsendl . . . . . . . . . . . . . . . . . . . . . 45

Figura 3.7: Formato da mensagem lgetu . . . . . . . . . . . . . . . . . . . . . 46

Figura 3.8: Formato da mensagem lsendu . . . . . . . . . . . . . . . . . . . . . 46

Figura 3.9: Formato da mensagem lget . . . . . . . . . . . . . . . . . . . . . . 46

Figura 3.10: Formato da mensagem lsendf . . . . . . . . . . . . . . . . . . . . . 47

Figura 4.1: A camada de abstração do VFS . . . . . . . . . . . . . . . . . . . . 49

Figura 4.2: Relações entre os objetos do VFS (fonte: Mauerer (2008)) . . . . . 54

Figura 4.3: Relação entre as estruturas do VFS e do Page Cache (fonte: Mauerer(2008)) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Figura 4.4: Exemplo de uma árvore radix (fonte: Mauerer (2008)) . . . . . . . . 58

Figura 4.5: Estrutura com alinhamento de bytes (fonte: Mauerer (2008)) . . . . 60

Figura 4.6: Montagem do sistema LP2PFS . . . . . . . . . . . . . . . . . . . . 60

Figura 4.7: Leitura do conteúdo de um arquivo . . . . . . . . . . . . . . . . . . 61

Figura 5.1: Compartilhamento de pacotes Debian . . . . . . . . . . . . . . . . . 65

Figura 5.2: Vazão de dados usando TCP . . . . . . . . . . . . . . . . . . . . . 66

Figura 5.3: Latência de comunicação usando TCP . . . . . . . . . . . . . . . . 67

Figura 5.4: Vazão individual de cada peer para arquivos de 1 MB . . . . . . . . 68



Figura 5.7: Vazão agregada do sistema . . . . . . . . . . . . . . . . . . . . . . 71

LISTA DE LISTAGENS

Listagem 4.1: Estrutura super_block . . . . . . . . . . . . . . . . . . . . . . . 49

Listagem 4.2: Estrutura inode . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Listagem 4.3: Estrutura dentry . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Listagem 4.4: Estrutura file . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Listagem 4.5: Estrutura file_system_type . . . . . . . . . . . . . . . . . . . 54

Listagem 4.6: Estrutura address_space . . . . . . . . . . . . . . . . . . . . . 56

Listagem 4.7: Funções de leitura de páginas . . . . . . . . . . . . . . . . . . . . 57

Listagem 4.8: Função __builtin_expect . . . . . . . . . . . . . . . . . . . . 59

Listagem 4.9: Macros likely e unlikely . . . . . . . . . . . . . . . . . . . . 59

LISTA DE TABELAS

Tabela 2.1: Síntese das características dos sistemas estudados . . . . . . . . . . 39

Tabela 5.1: Teste do sistema com arquivos de 1 MB . . . . . . . . . . . . . . . 68



Tabela 5.4: Vazão agregada do sistema . . . . . . . . . . . . . . . . . . . . . . 71

RESUMO

Sistemas de distribuição de arquivos em rede tem como principal objetivo per-mitir o compartilhamento de dados entre os seus usuários, provendo uma ou maisdas seguintes características: transparência de localização, replicação de arquivos,tolerância a falhas, eficiência, segurança e consistência. Nesse contexto, no âm-bito do Programa Interdisciplinar de Pós-Graduação em Computação Aplicada daUnisinos (PIPCA), surgiu a proposta de desenvolver um sistema peer-to-peer pararedes locais, o Local Peer-to-Peer Protocol (LP2P), possibilitando a rápida trocade arquivos entre os componentes da rede. Esse sistema, através de seus módulosexternos, disponibiliza funções de descoberta de serviços e mecanismos de segurançae otimização para a transferência de arquivos entre os peers da rede. No entanto, énecessário o desenvolvimento de uma interface robusta e de fácil utilização para osistema. Desse modo, nesse projeto, foi implementado um módulo para o kernel doLinux, que atua como um sistema de arquivos, denominado LP2PFS. Esse módulopermite disponibilizar os arquivos presentes no sistema LP2P, atuando como a suainterface com o usuário. O LP2PFS foi desenvolvido com base na camada de abs-tração do kernel para sistemas de arquivos, o Virtual File System (VFS), utilizandoo subsistema de Page Cache para o armazenamento dos dados na memória. O sis-tema de arquivos apresenta as funcionalidades de notificação de eventos ocorridosno sistema às aplicações, através da interface fsnotify, além de possuir um arquivovirtual no sistema Procfs, com dados da sua montagem e dos arquivos presentesno sistema. O módulo LP2PFS obteve êxito em todos os testes executados. A suaimplementação é compatível com diversas versões do kernel do Linux e a disponi-bilização dos arquivos presentes no sistema LP2P foi alcançada, sendo comprovadapela verificação da integridade dos dados desses arquivos através do algoritmo MD5.Por fim, foram realizados testes de desempenho do sistema de arquivos em conjuntocom o sistema LP2P, através dos quais foi comprovado o desempenho e a eficiênciado módulo implementado.

Palavras-chave: Sistema de arquivos. peer-to-peer. LP2P.

ABSTRACT

LP2PFS: A VFS Linux Client for the LP2P System

Network file distribution systems aim to allow data sharing among users, pro-viding some of the following features: location transparency, file replication, faulttolerance, efficiency, security and consistency. In this sense, at PIPCA, it was pro-posed the development of a peer-to-peer system for local networks, the Local Peer-to-Peer Protocol (LP2P), allowing fast file exchange among the participants of thenetwork. This system, through its external modules, also provide other functions,like service discovery, security and otimization for data exchange among the hostsof the network. However, this system needs a powerful and easy to use interface.Therefore, in this project, it was developed a Linux kernel module, a file systemcalled LP2PFS, to make the files in the LP2P system available to all participants,operating as the user interface of the system. The LP2PFS was structured based onthe abstraction layer of the kernel for file systems, the Virtual File System (VFS),using the Page Cache subsystem to store data in the memory. LP2PFS also providethe functionality to notify events in the file system to the applications, through thefsnotify interface, and it was developed an entry in the Procfs system with infor-mation about its mount data and metadata of all files in the LP2P system. Allexperiments executed with the LP2PFS were succesful. Its implementation is com-patible with many versions of the Linux kernel and all the files in the system weresuccesfully shared, since data integrity was verified with MD5 algorithm. Lastly,the file system was tested together with the LP2P daemon, through which it wasconfirmed the performance and efficiency of the module.

Keywords: file systems, peer-to-peer, LP2P.

15

1 INTRODUÇÃO

O desenvolvimento contínuo de hardware de maior desempenho possibilita aexpansão da Internet, tornando possível taxas cada vez maiores de download e deupload, e o aumento da capacidade de processamento dos computadores, possibili-tando a criação e a troca de arquivos com tamanhos gigantescos, inimagináveis háalgum tempo atrás (COULOURIS; DOLLIMORE; KINDBERG, 2007).

O modelo cliente/servidor apresenta problemas em algumas situações desse novocenário, já que os servidores podem ficar sobrecarregados ao enviar arquivos grandespara diversos clientes ao mesmo tempo, ou seja, o seu nível de escalabilidade érelativamente baixo. Assim, houve a necessidade de buscar um novo modelo para atroca de dados e o compartilhamento de recursos.

Contrastando com o modelo cliente/servidor, sistemas distribuídos apresentammaior escalabilidade e melhor utilização dos recursos disponíveis. Nesse cenário,sistemas de arquivos distribuídos são definidos como uma coleção de computado-res fracamente acoplados, interligados por uma rede de comunicação, permitindoque processos em diferentes máquinas compartilhem dados por longos períodos detempo. Eles permitem que arquivos sejam armazenados e acessados em qualquercomputador pertencente à rede (TANENBAUM, 2007; TANENBAUM; STEEN,2006).

Esse tipo de sistema é composto por três módulos principais: um serviço, queprovê um ou vários tipos de funções aos clientes, um servidor, que coordena asações de todo o sistema, e um cliente, que provê a interface do sistema com ousuário. Sendo assim, em um sistema de arquivos distribuído, os três módulos(serviço, servidor e cliente) estão dispersos pela rede (COULOURIS; DOLLIMORE;KINDBERG, 2007).

O sistema deve aparentar aos seus usuários ser um sistema de arquivos locale centralizado. A dispersão de seus servidores deve permanecer invisível para ousuário, fazendo com que não seja perceptível a diferença entre arquivos locais eremotos. Entretanto, na prática, essas características nem sempre são alcançadas.Também é preciso considerar o desempenho do sistema, principalmente a quantidadede tempo necessária para satisfazer as requisições dos usuários, o que inclui o tempode enviar a requisição ao servidor, o tempo do servidor responder, além do overheaddo protocolo de comunicação (SILBERSCHATZ; GALVIN; GAGNE, 2008).

Já o modelo peer-to-peer (P2P), cujas redes não possuem uma infraestrutura

16

centralizada e dedicada, mas dependem da participação voluntária de peers1 (nodosda rede), apresenta um meio eficiente e de baixo custo para o compartilhamentode recursos e de arquivos presentes nas máquinas participantes da rede (SAROIU;GUMMADI; GRIBBLE, 2002). Assim, a pesquisa nessa área cresceu exponencial-mente nos últimos anos. Dentre as principais iniciativas, destacam-se o BitTorrent(COHEN, 2003), o Gnutella (PORTMANN et al., 2001) e o Freenet (CLARKE etal., 2001).

Nesse contexto, no âmbito do Programa Interdisciplinar de Pós-Graduação emComputação Aplicada da Unisinos (PIPCA), surgiu a proposta de desenvolver umsistema P2P para redes locais (LANs), o Local P2P (LP2P), possibilitando a rá-pida troca de arquivos entre os nodos da rede. Desse modo, a proposta do sistemaLP2P é permitir o compartilhamento de arquivos em redes locais, com o auxílio detecnologias para anúncio e descoberta de serviços, como Multicast DNS (mDNS)(CHESHIRE; KROCHMAL, 2010b) e DNS Based Service Discovery (DNS-SD)(CHESHIRE; KROCHMAL, 2010a; CHESHIRE; STEINBERG, 2006), e a apli-cação de mecanismos de segurança e a otimização da transferência de arquivos entreos peers da rede (ROCHA; MARCON; ÁVILA, 2010).

Entretanto, torna-se necessário desenvolver uma interface de acesso aos arquivospresentes no sistema LP2P. Essa interface deve exigir o menor esforço possível dousuário, adaptando-se ao modelo com o qual o usuário já está familiarizado emseu cotidiano. Uma interface amplamente utilizada pelos usuários é a interface desistema de arquivos, que, do ponto de vista do usuário, é utilizada da mesma maneiraem diversos sistemas operacionais.

Essa interface oferecida pelo sistema operacional requer um esforço mínimo dousuário, que já está adaptado a ela, conhecendo as suas diversas funcionalidades.Dessa maneira, o usuário necessita de pouco ou nenhum aprendizado, já que elea utiliza diariamente para todas as suas atividades no computador, desde a maissimples, até atividades complexas, que necessitem de conhecimentos avançados.

Além disso, a interface de sistema de arquivos viabiliza a leitura de arquivos semo usuário ter conhecimento da localização na rede desses arquivos. Isso possibilitaao sistema de arquivos distribuído disponibilizar arquivos remotos da mesma formaque um sistema de arquivos local disponibiliza arquivos locais, do ponto de vista dousuário. Portanto, a utilização do sistema de arquivos como interface do sistemaLP2P deve oferecer ao usuário os seguintes benefícios:

• Transparência de localização de arquivos, cuja localização física na rede só éconhecida pelo sistema LP2P;

• Eficiência, realizando as operações requisitadas pelo usuário em um intervalode tempo próximo ao de um sistema de arquivos local;

• Minimização da complexidade do sistema do ponto de vista do usuário, quesó necessita interagir com o sistema de arquivos.

1Esse termo não será traduzido nem destacado em itálico, por ser utilizado com muita frequên-cia ao longo do trabalho e pelo autor considerar que sua tradução prejudica o entendimento dotexto. Outros termos, utilizados frequentemente, também não serão destacados em itálico: kernel,hardware, software, Internet, host, peer-to-peer, byte, kilobyte, megabyte e gigabyte.

17

Dessa forma, a proposta desse trabalho de conclusão é desenvolver um módulopara o kernel do Linux (SALZMAN, 2009), com o objetivo de realizar a ligação entreos dados dos arquivos distribuídos pela rede, cujas informações estão presentes nodaemon LP2P, e o usuário. Assim, o módulo atuará como um sistema de arquivos,denominado LP2PFS, podendo-se realizar operações sobre tais arquivos, abstraindo-se a sua localização e toda a comunicação existente entre o sistema de arquivos e odaemon LP2P, dando ao usuário a impressão de estar manipulando arquivos locais.A estrutura completa do sistema peer-to-peer, desde a camada de rede até o sistemade arquivos LP2PFS pode ser visualizada na Figura 1.1.

Figura 1.1: Estrutura do sistema LP2P

O objetivo principal do projeto é a implementação de um sistema de arquivospara a interação com o daemon LP2P, proporcionando o compartilhamento de arqui-vos entre os nodos de uma LAN, através da interface padrão do kernel do Linux parasistemas de arquivos, o Virtual File System (VFS). Assim, os objetivos específicossão:

• Permitir o acesso aos compartilhamentos LP2P via sistema de arquivos Linux;

• Estudar a interface de programação do kernel do Linux, com foco no VFS eno Page Cache;

• Analisar como são desenvolvidos os sistemas de arquivos com característicasdistribuídas, principalmente o Network File System (NFS), o Serverless NetwokFile System (xFS) e o Ivy;

• Estudar as técnicas de otimização de código proporcionadas pela interface deprogramação do kernel do Linux.

Esta monografia está organizada da seguinte forma: o Capítulo 2 apresenta al-guns trabalhos relacionados, suas vantagens e suas desvantagens, e o Capítulo 3apresenta o sistema LP2P, o seu protocolo de comunicação e os seus diversos mó-dulos. No Capítulo 4, é descrito o sistema de arquivos LP2PFS, sua estrutura, ométodo de armazenamento de dados em memória e as suas funcionalidades. Por fim,no Capítulo 5, são apresentados os resultados dos testes realizados com o sistema

18

LP2PFS em conjunto com o sistema LP2P e, no Capítulo 6, são feitas as conside-rações finais sobre esse projeto, bem como os trabalhos futuros a serem realizados.

19

2 REFERENCIAL TEÓRICO

Os sistemas de distribuição de arquivos em rede podem ser divididos em trêsgrandes grupos: i) sistemas centralizados, os quais são desenvolvidos, em sua grandemaioria, no modelo cliente/servidor, possuindo uma única máquina que gerencia osistema; ii) sistemas distribuídos, que são uma coleção de computadores independen-tes que compartilham recursos e que aparentam ser um sistema único para o usuário(TANENBAUM; STEEN, 2006); iii) sistemas peer-to-peer, que são sistemas cujarede é formada dinamicamente e com controle distribuído entre os participantes(CEBALLOS; GORRICHO, 2006).

Este capítulo apresenta alguns projetos relacionados ao desenvolvimento dessetrabalho, dando ênfase ao módulo cliente desses projetos, o qual interage diretamentecom o usuário do sistema, analisando criticamente suas vantagens e desvantagens.

2.1 Sistemas Centralizados

Os sistemas centralizados são, em sua grande maioria, desenvolvidos no modelocliente/servidor, o que limita a sua escalabilidade e a sua eficiência, já que umamáquina necessita atender as requisições de todos os clientes. Entretanto, o geren-ciamento de consistência dos dados é facilitado, uma vez que há uma única máquinaresponsável pelos dados, que, nesse caso, é o servidor (COULOURIS; DOLLIMORE;KINDBERG, 2007).

Dentre esses sistemas, destacam-se o Network File System (NFS) (PAWLOWSKIet al., 1994, 2000) e o Samba (VERNOOĲ, 2009).

2.1.1 Network File System - NFS

O protocolo NFS é uma coleção de procedimentos que permitem aos clientesacessarem arquivos armazenados remotamente em um servidor, sendo independentede arquitetura, sistema operacional e protocolo de rede. Esse protocolo possui 4versões:

• A primeira versão existiu somente internamente na Sun Microsystems;

• A segunda versão foi lançada em 1984 (SUN MICROSYSTEMS, 1989);

20

• As versões 3 (CALLAGHAN; PAWLOWSKI; STAUBACH, 1995) e 4 (SHE-PLER et al., 2003) resolvem alguns problemas encontrados nas versões ante-riores, principalmente na questão de desempenho e eficiência (PAWLOWSKIet al., 1994, 2000).

O protocolo NFS é stateless até a versão 3, já que cada requisição contém todasas informações necessárias para ser processada. Entretanto, o servidor deve mantero estado dos dados que estão armazenados no disco rígido, além do mapeamentodos descritores para os dados dos arquivos no sistema de arquivos. Na versão 4, oNFS tornou-se stateful, devido às necessidades de trava de arquivo e delegação deserviços (PAWLOWSKI et al., 2000).

Em sua segunda versão, de acordo com Pawlowski et al. (1994), o protocoloapresentava alguns problemas desde o seu projeto até a sua implementação, dentreos quais os mais sérios eram a limitação de 4 gigabytes do tamanho de arquivose a escrita de dados síncrona, de forma que o servidor só gerava uma resposta aocliente após os dados terem sido escritos no disco rígido, ocasionando aos clientesuma considerável perda de desempenho.

A versão 3 do protocolo (NFSv3), por outro lado, introduziu melhorias que afeta-ram positivamente não somente o desempenho do sistema, mas também a eficiênciae o tempo de resposta dos clientes. Dentre essas melhorias, destacam-se a escritaassíncrona de dados, o armazenamento de tamanhos de arquivos em estruturas de64 bytes, a operação de leitura de diretórios otimizada, a recuperação de falhas e aconsistência fraca de memória cache.

A escrita assíncrona eliminou o gargalo da escrita existente na versão anterior.Ao receber uma requisição de escrita de um cliente, o servidor responde imediata-mente, possibilitando ao cliente continuar o seu processamento. Após algum tempo,o cliente verifica se os dados foram escritos em um meio não-volátil. O servidor,então, responde a essa requisição somente após os dados terem sido armazenados.Entretanto, essa função é opcional na especificação do protocolo e, consequente-mente, as implementações podem escolher não suportá-la.

A Figura 2.1 mostra o diagrama de estados para a realização da escrita assín-crona de uma página de memória alterada no cliente. Quando a página for marcadacomo suja (dirty), ou seja, tiver sido alterada em memória, o cliente envia umamensagem de escrita assíncrona ao servidor. Enquanto ele não receber do servidoruma mensagem de operação realizada (COMMIT), a página permanece armazenadaem cache na sua memória, pois, em caso de erro no servidor, ele reenviará a página,dessa vez em uma operação de escrita síncrona (PAWLOWSKI et al., 1994).

Para a recuperação de falhas, o NFS adota a filosofia de clientes “espertos”, ouseja, o cliente mantém em cache uma cópia dos dados até o servidor responder queesses dados foram armazenados em meio físico. Desse modo, se houver uma falhano servidor, o cliente irá reenviar os dados.

Outra operação introduzida foi a leitura de diretórios otimizada, que retornaos descritores de arquivos juntamente com os atributos de cada arquivo presente nodiretório. Essa operação ocasionou uma grande redução do overhead de comunicaçãoentre clientes e servidores, já que, até então, uma operação de leitura de diretório

21

Figura 2.1: Estado da página em memória com escrita assíncrona

era seguida por diversas operações de requisição de atributos de arquivos, de acordocom o número de arquivos presentes no diretório lido (PAWLOWSKI et al., 1994).

Entretanto, essa versão do protocolo possui alguns problemas, principalmenterelacionados à segurança, à perda de desempenho e à baixa extensibilidade do pro-tocolo, além de problemas com travas de arquivos. Dessa maneira, foi desenvolvidaa versão 4 da especificação do protocolo NFS.

Na versão 4 (NFSv4), uma grande diferença estrutural em relação às 3 versõesanteriores está na eliminação de protocolos auxiliares, já que as versões anterioresutilizavam o protocolo mount para obter o descritor de arquivo inicial e o protocoloNetwork Lock Manager para travas de arquivos, e a introdução de operações paracomunicação entre cliente e servidores, substituindo os procedimentos RPC.

Essas operações, também denominadas de procedimento composto (COMPOUND),correspondem a várias ações a serem realizadas no sistema de arquivos em uma únicacomunicação, o que não era possível nas versões anteriores do protocolo, já que cadaprocedimento RPC correspondia a uma ação específica a ser executada no sistema dearquivos. Esse tipo de operação não é atômica, ou seja, em um conjunto de operaçõesrequisitadas sobre o sistema de arquivos, o servidor as processa em ordem, até o finalou até aquela que retornar erro, não processando as operações seguintes do conjuntorequisitado. Assim, o servidor retorna a resposta ao cliente de todas as operaçõesou até a operação que retornou erro, inclusive o erro (PAWLOWSKI et al., 2000).

Outra diferença estrutural marcante é a introdução de estado na operações deabertura e fechamento de arquivo, tornando o protocolo stateful. A introdução deestado no protocolo proporciona a delegação de operações em um arquivo para umcliente específico, o que aumenta consideravelmente o desempenho do cliente atravésda realização de um mecanismo forte de cache dos dados, já que o cliente detém atrava do arquivo.

Krishnan et al. (2007) conduziram um estudo para avaliar os mecanismos dedetecção e recuperação de falhas na implementação do NFS no Linux. Os resultadosdos testes mostraram-se preocupantes em certos casos, já que o NFS nem sempreconsegue detectar a corrupção de metadados, agindo de maneiras inesperadas. Emcertas operações de erro, o cliente retorna ao usuário informações de sucesso daoperação, em outras, o kernel do sistema do cliente é afetado, tornando todo o

22

sistema instável.

Já Traeger, Thangavelu e Zadok (2007) propuseram um modelo de privacidaderound-trip para o NFSv4, já que essa versão só define a segurança dos dados sendotransmitidos entre clientes e servidores. A segurança do protocolo NFS apresentadeficiências, devido ao fato de servidores com acesso à Internet possuírem dados des-protegidos. Dessa forma, o servidor só deveria armazenar dados cifrados, garantindoa segurança de tais dados caso ele seja invadido.

Nesse novo modelo de segurança, o tempo de processamento para atender requi-sições dos clientes é menor no servidor, já que ele não precisa cifrar e decifrar dados.Assim, o gargalo da rede (o servidor) é aliviado e, ao mesmo tempo, a privacidade dosdados é aumentada. Além disso, de acordo com os testes realizados, a escalabilidadenão é afetada pelas medidas extras de segurança (TRAEGER; THANGAVELU;ZADOK, 2007).

Além disso, em momentos de congestionamento do sistema, não é definida ne-nhuma ação a ser tomada pelo NFS. Por isso, não há um estabelecimento de priori-dades para realizar as operações pendentes. Dessa forma, no estudo conduzido porBatsakis et al. (2009), é proposto um framework para coordenar e gerenciar o usodos recursos do sistema de arquivos entre todos os clientes nas operações realizadaspelo NFS, denominado Congestion Aware NFS (CA-NFS).

Ao atingir um estado crítico, o CA-NFS realiza um escalonamento de priorida-des, sendo preferencial operações de leitura e escrita síncronas em relação às assín-cronas, além de ser dada preferência para escritas de blocos de dados que bloqueiemleituras. Esse framework foi implementado na versão 2.6.18 do kernel do Linux.

Baseados nessa medição de recursos, os clientes CA-NFS tem a opção de atrasarou acelerar uma escrita assíncrona. A aceleração de uma escrita é feita se a utilizaçãode rede estiver baixa ou se o cliente estiver com problemas de memória cache. Alémdisso, as operações de leitura assíncrona no cliente, baseadas na quantidade de dadosa serem lidos antecipadamente (readahead), são otimizadas com base na utilizaçãodos recursos de rede e de disco.

Outro projeto desenvolvido com base no protocolo NFSv4 é o Parallel NFS(pNFS), com o objetivo de eliminar o gargalo dos servidores em clusters, enquantoé mantida a facilidade de gerenciamento e interoperabilidade do NFS. Ele foi proje-tado como uma extensão à especificação do protocolo NFS, permitindo a separaçãoentre dados e metadados, possibilitando aos clientes o acesso direto e em paralelo aservidores (CHAI et al., 2007; HILDEBRAND; HONEYMAN, 2007).

2.1.2 Samba

O Samba (VERNOOĲ, 2009) é um projeto de código aberto, que possibilita ocompartilhamento de arquivos e o acesso a serviços de impressão a clientes que rodemsistemas operacionais diferentes do Microsoft Windows e que utilizem os protocolosServer Message Block (SMB) e Common Internet File System (CIFS) (STORAGENETWORKING INDUSTRY ASSOCIATION, 2002). Além disso, a aplicação podedesempenhar o papel de servidor, disponibilizando arquivos a clientes Windows. Porisso, o principal objetivo desse projeto é prover interoperabilidade entre clientes e

23

servidores operando em diferentes sistemas operacionais (BLAIR, 1998).

No Linux, para acessar arquivos disponibilizados através do protocolo SMB,foram implementados dois sistemas de arquivos clientes em espaço de kernel, o smbfse o cifs.

O smbfs é um cliente SMB limitado, já que ele só implementa parcialmenteas semânticas POSIX e as suas configurações são especificadas através do arquivosmb.conf. Além disso, ele só possui a opção de leitura de 1 página de memóriapor vez, limitando o seu desempenho. Entretanto, o smbfs suporta a autenticaçãoatravés do protocolo Kerberos, que não é suportada pelo cifs.

Por outro lado, o cliente cifs suporta completamente as semânticas POSIX ea sua configuração é feita dinamicamente através do sistema Procfs, em arquivospresentes no diretório fs/cifs/, ou pela passagem de parâmetros no carregamentodo módulo. Ele suporta hardlinks, leitura e escrita de várias páginas simultâneas dememória e trava de arquivos (LINUX KERNEL ORGANIZATION, 2010). Foi pro-jetado de acordo com a referência técnica SNIA CIFS (STORAGE NETWORKINGINDUSTRY ASSOCIATION, 2002) e possui suporte ao Windows 2000, WindowsXP, Samba e a servidores cifs (FRENCH, 2007).

Algumas das opções mais importantes do sistema de arquivos, que afetam dire-tamente o seu desempenho, são as seguintes:

• Tamanho do buffer de escrita de dados de arquivos (wsize): define a quanti-dade média de bytes que o sistema de arquivos envia para o servidor a cadarequisição de escrita. Por padrão, o sistema define 14 páginas de memória;

• Tamanho do buffer de leitura de dados de arquivos (rsize): define a quantidademédia de bytes que o sistema de arquivos requisita ao servidor. Por padrão,o sistema define 4 páginas de memória. Alterar esse valor influenciará muitopouco o desempenho do sistema, já que o buffer de requisição possui um ta-manho aproximado de 4 páginas de memória também. Entretanto, é possívelalterar o tamanho do buffer no momento do carregamento do módulo;

• Número máximo de requisições a um servidor: passado por parâmetro nomomento do carregamento do módulo. Por padrão, são 50 requisições.

Além dos objetos padrões do Virtual File System, o cifs define diversos objetosde uso específico, no arquivo fs/cifs/cifsglob.h, como um objeto de informaçõessobre o servidor TCP, um objeto que identifica o usuário que realizou uma montagemno sistema, um objeto para cada compartilhamento montado e um objeto auxiliarpara cada representação de arquivo (definida pela estrutura inode) do sistema.

No momento do carregamento do módulo, é criada uma thread de gerenciamentode cache, principalmente para a escrita dos dados. Uma segunda thread, denominada“cifsd”, é criada no momento da montagem do sistema, encarregada de gerenciaras conexões de rede do compartilhamento, e uma terceira thread é criada para anotificação de eventos em diretórios do sistema de arquivos.

O sistema também aloca 3 buffers para o gerenciamento de requisições (cifs_small_rq), cifs_request e cifs_mpx_ids). O tamanho de cada buffer pode ser

24

configurado no momento de carregamento do módulo. Entretanto, se muitas apli-cações acessarem o sistema de arquivos simultaneamente, serão alocados e desalo-cados dinamicamente mais buffers. Para aumentar o desempenho, o cifs tambémutiliza o subsistema do kernel de Page Cache para armazenar os dados dos arquivos(FRENCH, 2007).

2.2 Sistemas Distribuídos

Os sistemas distribuídos, ao contrário dos sistemas centralizados, não possuemum servidor para coordenar as ações dos clientes, fator que aumenta a sua escalabi-lidade e a tolerância a falhas, porém necessita de um projeto mais complexo, devidoa necessidade de coerência de dados entre os nodos da rede.

Nessa categoria, encontram-se sistemas como o Coda (SATYANARAYANAN,2002) e o Serverless Network File System (xFS) (ANDERSON et al., 1996).

2.2.1 Coda

OCoda, desenvolvido na Carnegie Mellon University, com base no AFS-2 (SATYA-NARAYANAN, 1990), foi projetado para operar em ambientes de clientes Unix nãoconfiáveis e servidores Unix confiáveis. Cada cliente enxerga o Coda como um sis-tema de arquivos, com transparência de localização, no qual o processo denominadoVênus obtém e mantém em cache os volumes mapeados.

Segundo Satyanarayanan (2002), esse sistema utiliza dois mecanismos para agarantir alta disponibilidade:

• Replicação de servidores: para permitir que os volumes possuam cópia compermissão de escrita em vários servidores, mantendo um baixo custo devidoàs operações de cache realizadas nos clientes e ao uso de protocolos de acessoparalelo;

• Operação desconectada: em períodos de falha da rede, quando um volumede dados ficar indisponível, o módulo Vênus do cliente processa as requisiçõesdo sistema de arquivos baseando-se somente no conteúdo da sua memóriacache.

Além disso, o sistema apresenta outras características importantes:

• Realização de operações de cache no cliente;

• Modelo de segurança bem definido para autenticação, controle de acesso ecifragem dos dados;

• Adaptação a banda de rede disponível;

• Escalabilidade, adotando-se diversos mecanismos, dentre os quais os mais im-portantes são coerência de cache e armazenamento em cache de arquivos in-teiros, para que, em eventuais falhas da rede, um problema na busca de dados

25

ocorrer somente em uma operação de abertura de arquivo, nunca em uma ope-ração de leitura ou de escrita (CARNEGIE MELLON UNIVERSITY, 2000);

• Semânticas de compartilhamento bem definidas.

A estrutura dos clientes Coda é ilustrada na Figura 2.2. Em cada máquina cli-ente do sistema, há um processo denominado Vênus, implementado em espaço deusuário, devido à sua complexidade e a fim de garantir portabilidade. As chamadasde sistema chegam até a interface vnode no kernel, que as repassa para um filtroMiniCache em espaço de kernel e, finalmente, chegam ao processo Vênus, em espaçode usuário. Esse filtro MiniCache é utilizado para filtrar as comunicações entre okernel e o Vênus, com o objetivo de minimizar o overhead do sistema (SATYANA-RAYANAN, 2002).

Figura 2.2: Estrutura de um cliente Coda

Ao receber uma chamada de sistema, primeiramente o processo Vênus procurapela resposta em seu cache. Caso não a encontre, ele envia uma mensagem aosservidores que possuem o arquivo associado a chamada de sistema e, caso nenhumaresposta seja recebida, ele começará a executar em modo desconectado (CARNEGIEMELLON UNIVERSITY, 2000).

Ao receber uma requisição de abertura de arquivo pela primeira vez, o Vênusrequisita dos servidores os dados do arquivo completo, através de procedimentosRPC. Assim, as próximas requisições a esse arquivo serão completamente locais,inclusive as de escrita, não havendo comunicação em rede. O mesmo procedimento érealizado para diretórios, já que diretórios também são arquivos. Quando o arquivoé fechado, se ele tiver sido modificado, o processo Vênus enviará o arquivo aosservidores. Desse modo, o processo Vênus só envia um arquivo aos servidores que opossuem caso ele tenha sido alterado. Qualquer alteração efetuada é propagada aosservidores, desde a criação de arquivos em um diretório até a remoção de um linksimbólico.

Esse mecanismo agressivo de cache nos clientes permite ao sistema de arquivosoperar em modo desconectado em ocasiões de falhas da rede, muitas vezes sem ousuário perceber. Além disso, estudos confirmaram que os usuários abrem arquivos

26

em modo somente leitura na maioria das vezes, o que beneficia a estratégia utilizadano desenvolvimento do Coda (CARNEGIE MELLON UNIVERSITY, 2000).

Esse sistema está em uso constante na Carnegie Mellon University, como sis-tema de arquivos de uso geral e para aplicações específicas apropriadas para utilizara característica de operação desconectada. O sistema também pode ser utilizadopara aplicações de espelho de sites de FTP (File Transfer Protocol) e replicação deservidores web.

2.2.2 Serverless Network File System - xFS

O Serverless Network File System (xFS) foi desenvolvido com o propósito dedistribuir as responsabilidades do servidor através de um grande número de má-quinas, que cooperam entre si, tornando-o um sistema totalmente descentralizado,com armazenamento e controle de processamento distribuídos. Assim, qualquermáquina na rede pode armazenar, manter cache ou controlar um bloco de dados.Esse esquema de controle e processamento distribuído permite ao sistema migrarresponsabilidades em situações de falhas de componentes, ocasionando alta dispo-nibilidade.

Segundo Anderson et al. (1996), a arquitetura totalmente distribuída do xFSdeve-se a três fatores:

• O controle de processamento é distribuído dinamicamente em uma granulosi-dade por arquivo;

• O armazenamento de dados é distribuído em diversos servidores, implementando-se Redundant Arrays of Inexpensive Disks (RAID) em software, utilizando-seum sistema baseado em log;

• É feito um esquema de cache cooperativo, tornando parte da memória docliente um segmento de uma cache global do sistema.

O software RAID, em um sistema com N discos de armazenamento de dados,particiona cada arquivo em N-1 blocos de dados, sendo o enésimo bloco de paridade.Assim, cada bloco é armazenado em um disco diferente, aumentando-se o desem-penho através do acesso paralelo aos discos, além do bloco de paridade prover umbom mecanismo de tolerância a falhas, já que é possível recuperar o conteúdo deum disco com problemas através dos outros blocos e do bloco de paridade.

Contudo, há o overhead gerado pelo RAID, que pode aumentar para a escritade porções muito pequenas de dados. Esse empecilho é contornado pelo sistema dearmazenamento baseado em log, o LFS (Log-structured File System), que adicionaem um buffer escritas pequenas, enviando ao disco os dados em grupos contínuos egrandes, denominados segmentos de log.

O controle de metadados e de consistência de cache é feito pelos gerenciadoresde metadados. Esses gerenciadores utilizam quatro mapeamentos para localizar osdados de blocos de arquivos quando necessário:

• Manager map: para localizar o responsável do sistema por um arquivo;

27

• Imap: permite ao gerenciador encontrar o local do log do disco onde estãoarmazenados os seus arquivos;

• File directories: utilizado para determinar o índice do arquivo, a partir doseu nome;

• Stripe group map: contém o mapeamento dos identificadores de segmentopresentes nos logs para as máquinas que possuem os dados armazenados.

Para a leitura de um bloco de dados, são necessários diversos passos a seremseguidos. Primeiramente, é necessário a abertura do diretório ao qual o arquivopertence, a fim de determinar o índice do arquivo.

Após, o cliente procura os dados requisitados em seu cache e, caso eles nãoestejam na sua memória, é gerada uma requisição pela rede. Nessa etapa, o sistemautiliza o manager map para localizar a máquina gerenciadora do arquivo, a partirde seu índice no diretório, para, após, enviar a requisição à máquina gerenciadora.

A máquina gerenciadora procura por clientes que possuam os dados em cachee, se encontrá-los, ela repassa a requisição para uma das máquinas encontradas, queenviará os dados para o cliente que originou a requisição. Caso nenhuma máquinapossua os dados em cache, o gerenciador procura na tabela imap para encontrar oíndice do nodo do bloco. O gerenciador pode ter esse dado em memória ou lê-lo dodisco, usando o stripe group map para determinar qual o servidor de armazenamentoacessar.

O próximo passo é o gerenciador enviar uma requisição de índice de bloco parao servidor de armazenamento, que responderá ao gerenciador. O gerenciador, então,utiliza o índice do nodo para identificar o endereço do log do bloco de dados, enviandouma requisição para o servidor com o endereço do log e o stripe group map do blocode dados. O servidor, ao receber essa requisição, responde diretamente ao clienteque requisitou os dados. A leitura de um bloco de dados é representada na Figura2.3.

Figura 2.3: Leitura de um bloco no sistema xFS (fonte: Anderson et al. (1996))

Do mesmo modo que a leitura é realizada em uma granulosidade de bloco, tam-bém é a consistência da memória cache de cada cliente. Antes de modificar umbloco de dados, o cliente precisa adquirir a permissão de alteração daquele bloco,

28

enviando uma mensagem ao gerenciador de blocos. O gerenciador de blocos, então,invalida todas as cópias daquele bloco em outros clientes, atualiza a informação nasua memória cache e envia a permissão ao cliente para escrever naquele bloco.

Uma vez com permissão de escrita, o cliente tem a possibilidade de escrever nobloco quantas vezes forem necessárias. Essa permissão será revogada quando outrocliente solicitar uma operação de leitura ou escrita sobre o bloco, o que forçará ocliente com a permissão sobre o bloco a enviar o bloco de dados para o servidor dearmazenamento e, também, a enviá-lo ao cliente que solicitou o bloco.

O protótipo do sistema foi implementado em quatro partes distintas: um módulopara o kernel do sistema Solaris, possibilitando o acesso a interface vnode do sistema,e três daemons em espaço de usuário, que desempenham as funções de processamentoe comunicação com outros nodos do sistema caso o cliente não possua os dadoslocalmente (ANDERSON et al., 1996).

Os testes de desempenho, escalabilidade e disponibilidade realizados no xFSapresentaram resultados satisfatórios, com índices de desempenho superiores aosalcançados pelo NFS.

O principal destaque nos testes foi a grande escalabilidade apresentada pelosistema, já que o desempenho não foi afetado com o acréscimo de clientes, sendo queos testes possuíram ummáximo de 32 clientes. A largura de banda do sistema atingiuum pico de 13.8 MB/s para leitura e também para a escrita de dados. Entretanto,o protótipo do sistema está longe de um estado ideal, já que a comunicação em redefoi realizada com RPC, o que acrescenta um overhead significativo, além do sistemarodar com três módulos em espaço de usuário e um módulo em espaço de kernel(ANDERSON et al., 1996).

O sistema, entretanto, é apropriado somente para máquinas confiáveis, conecta-das a uma rede de alta velocidade. Essa questão de segurança é a maior desvantagemdo projeto, que tem a possibilidade de suportar clientes não confiáveis, mas com ouso de outros protocolos de comunicação, o que ocasionará um aumento do overheaddo sistema.

2.3 Sistemas Peer-to-Peer

Os sistemas peer-to-peer (P2P) são sistemas altamente escaláveis e robustos,cujos nodos da rede, denominados peers, realizam download e upload de dados,ou seja, cada nodo disponibiliza e, ao mesmo tempo, consome recursos da rede(LEGOUT et al., 2007).

As redes P2P são formadas através da criação de uma camada lógica de so-breposição na camada de rede subjacente, por exemplo, a Internet. As principaispropriedades dessas redes são:

• Nenhum peer possui uma visualização global da rede;

• Os dados e serviços oferecidos são acessíveis a partir de qualquer nodo;

• Não há um ponto central de coordenação;

29

• Não há um banco de dados central.

Esse tipo de rede pode ser classificada em rede estruturada e rede não estru-turada, variando de acordo com a forma de organização dos dados utilizados parasatisfazer requisições de procura. Em redes estruturadas, as informações são arma-zenadas com um método pré-definido, através do auxílio de tabelas hash, enquantoredes não estruturadas são organizadas de forma hierárquica, como, por exemplo,com peers e super-peers, armazenando informações de localização de dados somenteem alguns nodos da rede, nesse caso os super-peers (CEBALLOS; GORRICHO,2006).

Os sistemas mais representativos para esse projeto são o Gnutella (PORTMANNet al., 2001), o Freenet (CLARKE et al., 2001), o Ivy (MUTHITACHAROEN et al.,2002) e o BitTorrent (LEGOUT et al., 2007).

2.3.1 Gnutella

O Gnutella é um protocolo aberto, implementado por diversas empresas, como aLimewire e a Bearshare. Ele foi um dos primeiros sistemas descentralizados, desen-volvido com o objetivo de compartilhamento de arquivos (DUFOUR; TRAJKOVIĆ,2006).

A comunicação entre os peers consiste de mensagens com um time-to-live (TTL)definido, já que é adotado o esquema de inundação de mensagens. A estruturada rede é organizada em duas camadas, com ultra-peers e nodos folhas, como émostrado na Figura 2.4. Cada ultra-peer conecta-se com diversos outros ultra-peerse controla um grupo de nodos folhas, e cada nodo folha, os quais são a maioria narede, está conectado a um ou mais ultra-peers. Além disso, são os ultra-peers quecontém as informações de localização dos nodos folhas, bem como os seus arquivossendo compartilhados, e administram as requisições de procura por arquivos na rede(STUTZBACH; REJAIE; SEN, 2008; MOTTA; NIENABER; JENKINS, 2008).

Figura 2.4: Estrutura da rede Gnutella

O cliente Gnutella decide, no momento da sua inicialização, qual dos dois papéisna rede ele desempenhará. Primeiramente, ele contata um servidor para obter oendereço de alguns peers. Essa é a primeira e única vez que o servidor é contatado.O cliente, então, envia mensagens de conexão aos peers que o servidor passou oendereço. Após estabelecer conexões, os clientes enviam periodicamente mensagens

30

gnutella ping aos seus vizinhos, que também as enviarão a todos os seus vizinhose, assim, sucessivamente, até que o TTL da mensagem chegue ao valor zero. Essamensagem é enviada para procurar por nodos que aceitem novas conexões, os quaisresponderão com uma mensagem gnutella pong (DUFOUR; TRAJKOVIĆ, 2006).

Caso um nodo folha não encontre um ultra-peer disponível na rede, ele verificaa sua conexão e, se ele possuir uma alta largura de banda e puder receber conexões,ele reconfigura-se como um ultra-peer. Desse modo, é possível manter uma taxaaceitável entre ultra-peers e nodos folha.

Entretanto, não há uma regra para a conexão entre os nodos, o que pode levara diversas conexões distantes, aumentando a latência de comunicação entre os vizi-nhos. Também é possível a formação de redes mal estruturadas, o que ocasiona asubutilização dos recursos disponíveis. Um exemplo de rede cujos recursos são malaproveitados é mostrado na Figura 2.5 (DUFOUR; TRAJKOVIĆ, 2006).

Figura 2.5: Rede de sobreposição Gnutella com os nodos mal distribuídos

Para localizar arquivos na rede, na primeira versão do protocolo era realizadauma inundação de mensagens entre os nodos da rede (KUROSE; ROSS, 2009; BAR-BOSA et al., 2004). Já na segunda versão, a fim de diminuir o tráfego de rede, ocliente envia mensagens de query para os ultra-peers que ele conhece. O ultra-peer,ao receber uma mensagem de query, procura em seu banco de dados se os seus nodosfolhas estão compartilhando o arquivo sendo procurado. Caso ele encontre o arquivoem nodos folhas, ele envia os resultados em uma mensagem query hit ao cliente queiniciou a busca. Caso contrário, ele repassa a busca para outros ultra-peers. Aoser localizado um ou mais resultados, são enviadas ao cliente mensagens query hit(MOTTA; NIENABER; JENKINS, 2008).

Para fazer o download do arquivo, o cliente se conecta diretamente ao nodo quepossui o arquivo, utilizando o protocolo HTTP para a transferência dos dados doarquivo.

Com o objetivo de analisar a rede Gnutella, Stutzbach, Rejaie e Sen (2008) apre-sentam uma aplicação, denominada Cruiser, para mapear essa rede de sobreposição.Foi constatado que a rede se recupera rapidamente aos peers que saem dela, mesmoque sejam ultra-peers. Os ultra-peers com mais tempo de vida na rede se conectamformando um núcleo denso, provendo conectividade estável e eficiente para os outrosnodos da rede. Quanto mais um nodo permanece na rede, mais vizinhos que estão

31

há bastante tempo na rede ele consegue. Por isso, é sugerido que as requisições deprocura nessa rede sejam direcionadas para esse núcleo de ultra-peers.

Por outro lado, Dufour e Trajković (2006) questionam o desempenho da rede,devido a latência na comunicação entre os nodos da rede. Por isso, é proposta autilização de um algoritmo de seleção de vizinhos que considera a informação delocalização física do nodo, levando em consideração o tempo de ida e volta de umamensagem (round-trip time - RTT).

Com esse novo método de escolha de vizinhos, foram realizadas simulaçõeslevando-se em consideração o número médio de nodos que recebem as mensagens dequery e o número médio de mensagens query hits recebidas de volta. Os resultadosmostraram que o desempenho da rede melhora com essa nova metodologia de esco-lha de vizinhos, diminuindo o tempo de propagação das mensagens trocadas entreos nodos.

Outro estudo foi realizado por Motta, Nienaber e Jenkins (2008) sobre as ame-aças de segurança e problemas de desempenho na rede Gnutella. Um dos principaisobjetivos dessa pesquisa foi obter informações sobre nodos que retornam respos-tas falsas, espalhando conteúdo mal-intencionado na rede. Esse aspecto acarretaa transferência de arquivos maliciosos, possibilitando ataques de negação de servi-ços. Ao analisar-se os endereços IP dos nodos responsáveis pelas respostas falsas,foi observado que são os mesmos com o passar do tempo e que eles aparecem emdeterminados segmentos da rede. Além disso, eles entram na rede como super-peerse apresentam certos padrões que sugerem que estejam sendo executados clientesmodificados.

Para aumentar a segurança da rede, foram propostas duas opções. A primeiraopção é a criação de um arquivo com endereços IPs de nodos maliciosos. Essearquivo seria atualizado dinamicamente e de maneira distribuída, possibilitando acontribuição de todos os peers da rede, mas controlado por uma autoridade central,sendo baixado pelo cliente através do protocolo HTTP antes de entrar na redeGnutella. A segunda opção seria a aplicação cliente verificar os arquivos sendocompartilhados, procurando por certos padrões de dados suspeitos. Apesar de havera possibilidade de modificar o código fonte da aplicação, a maioria dos usuários nãopossui o conhecimento necessário para isso.

Chawathe et al. (2003) destacam o problema da escalabilidade dessas redes. Paracontornar esse problema, foi proposto um novo sistema P2P baseado no protocoloGnutella, denominado Gia. As principais modificações são: acréscimo de controle defluxo, principalmente com relação a mensagens de busca de arquivos, tratamento daheterogeneidade dos nodos e adaptação dinâmica da topologia de rede, na qual nodosmais poderosos possuem mais vizinhos. Os testes mostraram que a escalabilidadedo sistema aumenta em até 5 vezes.

2.3.2 Freenet

Freenet é um sistema distribuído de armazenamento de informações, com o ob-jetivo prover segurança, disponibilidade de dados e independência de localização. Osistema permite ao usuário adicionar e requisitar arquivos anonimamente. Segundo

32

Clarke et al. (2001), os principais objetivos do sistema são:

• Proteção da identidade dos usuários;

• Negação ao acesso de informações a usuários não autorizados;

• Armazenamento dinâmico e roteamento eficiente de informação;

• Descentralização de todas as funções da rede.

O sistema executa em nível de aplicação e, apesar da necessidade de medidas desegurança para a transferência de dados, é independente de protocolo de transporte.O protocolo de comunicação é orientado a mensagens, sendo que cada mensageminclui um identificador, a fim dos nodos conhecerem o estado das operações emexecução. Também não há garantias que um arquivo seja armazenado permanen-temente, já que isso é dependente da capacidade de armazenamento do sistema, aqual varia dinamicamente de acordo com os nodos que estão na rede.

Em cada nodo do sistema, pode ou não haver um espaço para armazenamentode arquivos, sendo que os peers possuem permissão de escrita e leitura nos espaçosdisponibilizados pelos nodos. Cada nodo também possui uma tabela dinâmica deroteamento, que contém endereços de outros peers da rede, bem como os arquivosque eles armazenam, cada um representado por uma chave que o identifica. Dessemodo, o sistema permite aos usuários compartilharem o espaço no disco rígido quenão está sendo utilizado, podendo-se utilizar o sistema como uma extensão do discorígido para o armazenamento de dados.

Como mencionado anteriormente, os arquivos presentes na rede são identificadospor chaves, obtidas através do algoritmo SHA-1. Ao todo, há 3 tipos diferentes dechaves:

• Keyword-signed key (KSK): é gerada a partir do texto de descrição do arquivo.A partir desse texto, são geradas as chaves pública, que representará o arquivo,e privada, utilizada para garantir uma verificação mínima de integridade doarquivo;

• Signed-subspace key (SSK): permite ao usuário criar espaços de nomes (names-paces) pessoais, evitando que dois usuários possuam a mesma chave de arquivopara arquivos diferentes com a mesma descrição. Assim, o usuário deve criarum espaço de nomes, gerar um par de chaves (pública e privada), inserir oarquivo, passar o algoritmo de hash na chave pública do espaço de nomes e nachave pública do arquivo, fazer uma operação de XOR entre os dois resultadosde hash e passar o algoritmo de hash novamente no resultado do XOR;

• Content-hash key (CHK): formada a partir do hash do conteúdo do arquivo.

Para localizar um arquivo na rede, o cliente deve, primeiramente, calcular achave do arquivo. Após, ele envia uma mensagem de requisição do arquivo para aaplicação local. A aplicação local verifica se possui o arquivo e retorna se encontrá-lo. Caso contrário, ela procura em sua tabela de rotamento pela chave mais próxima

33

da chave procurada e envia uma mensagem de requisição com um determinado TTLpara o nodo correspondente. Cada nodo que recebe a mensagem verifica se possuio arquivo e, se não possui-lo, repassa a mensagem para o nodo que possuir a chavede arquivo mais próxima da procurada. O TTL da mensagem é decrementado acada nodo, evitando a propagação indefinida da mensagem caso o arquivo não sejaencontrado (BARBOSA et al., 2004; CLARKE et al., 2001).

Esse processo continua até o arquivo ser encontrado ou o campo TTL da men-sagem atingir o valor nulo. Nos dois casos é enviada uma resposta pelo caminhoinverso. No caso do arquivo ter sido encontrado, a resposta irá conter o arquivo.Assim, cada nodo em que a resposta passar armazenará uma cópia do arquivo local-mente e criará uma nova entrada na sua tabela de roteamento associando o arquivoa si mesmo.

Um exemplo de busca por um arquivo é mostrado na Figura 2.6. Nela, é mos-trado que um nodo, quando não possuir vizinhos para enviar a requisição (nodoc), retorna uma mensagem de erro ao nodo do qual ele recebeu a mensagem (nodob). Nesse caso, o nodo b envia para outro vizinho a requisição pelo arquivo. Outrasituação é a ocorrência de loop na busca (identificada pelas comunicações 4, 5 e 6),detectada pelo nodo b, que envia uma mensagem de falha ao nodo e. Desse modo,o nodo e envia a mensagem para outro vizinho (nodo d), o qual possui o arquivosendo procurado (CLARKE et al., 2001).

Figura 2.6: Procura de um arquivo na rede Freenet

Com a forma de armazenamento de arquivos adotada pelo sistema, na qual, emmensagens de resposta geradas pela busca por um arquivo, todos os nodos que re-passam a resposta armazenam o arquivo contido na mensagem, um nodo maliciosopossui muita dificuldade de modificar um arquivo presente no sistema ou mesmo deremovê-lo. Isso ocorre devido a possibilidade do arquivo estar armazenado em diver-sos nodos e, por causa da característica de anonimato dos nodos, o peer maliciosonão conhece todos os nodos que possuem o arquivo.

2.3.3 Ivy

O Ivy é um sistema de arquivos peer-to-peer para leitura e escrita de dados.Ele não possui nenhum componente centralizado e provê integridade mesmo naocorrência de usuários não confiáveis (MUTHITACHAROEN et al., 2002).

34

O sistema consiste em um conjunto de logs, um por participante. Cada partici-pante possui permissão de escrita somente em seu log e permissão de leitura nos logsde todos os participantes da rede. Cada log consiste em uma lista encadeada de re-gistros e contém todas as modificações feitas pelo cliente em dados e em metadadosdos arquivos.

Os logs são armazenados por tempo indeterminado em uma tabela hash distri-buída, que consiste no mapeamento de chaves em valores. Cada cliente da redepossui uma tabela local, mas as entradas dessa tabela são replicadas em outros cli-entes, evitando a perda de dados caso um cliente falhe. A integridade dos dados databela é verificada de duas maneiras possíveis: a chave na tabela deve ser o hashdo seu valor com o algoritmo SHA-1 ou a chave deve ser uma chave pública e o seuvalor ser assinado com a chave privada correspondente.

Assim, é possível verificar a autenticidade de todos os dados retirados da tabelahash, prevenindo a inserção de dados em um arquivo feita por um nodo malicioso.Além disso, os peers da rede comunicam-se somente no momento da montagem dosistema e, após, através do compartilhamento de informações da tabela hash.

Dessa maneira, é possível que diversos clientes escrevam no mesmo arquivo con-correntemente. Essas operações serão armazenadas nos logs de cada cliente, para,após, o sistema agregar os logs dos clientes, ordená-los e aplicar as alterações noarquivo.

A implementação desse sistema foi realizada em C++, utilizando-se o clienteNFSv3 como interface do sistema de arquivos com o usuário. Ele está dividido emvários módulos, que cooperam entre si. Cada cliente possui um servidor Ivy, queopera como cliente da tabela hash distribuída (DHash), e um agente, que armazenaas chaves privadas do sistema. O módulo DHash se comunica com os módulos DHashde outros clientes, trocando informações sobre as modificações feitas nos arquivosdo sistema. A Figura 2.7 mostra a estrutura do sistema de arquivos Ivy em umcliente na rede (MUTHITACHAROEN et al., 2002).

Figura 2.7: Estrutura do sistema Ivy

O sistema armazena os proprietários e as permissões de cada arquivo, mas nãoutiliza essas informações para evitar ou permitir o acesso aos arquivos. Se um ar-quivo não deve ser visto por alguns participantes da rede, a única maneira disponível

35

é criptografar o seu conteúdo. Além disso, o sistema foi intencionalmente modeladopara que não seja possível inserir automaticamente um participante na rede an-tes que todos os participantes concordem com a sua entrada, a fim de aumentar asegurança da rede.

Outro mecanismo de segurança adotado é a recuperação do sistema após umparticipante malicioso realizar alguma ação prejudicial. Assim, mesmo que um par-ticipante normal passe a prejudicar o sistema, é possível excluir esse participante dosistema, ignorando as suas ações no log, ou aceitar as operações desse usuário atéum certo instante, antes dele tornar-se um nodo malicioso.

O desempenho do Ivy é inferior ao do NFS em aproximadamente 33% (MUTHI-TACHAROEN et al., 2002). Os fatores mais influentes nesse resultado são a latênciana comunicação em rede e a geração de assinaturas digitais dos dados armazenadosna tabela hash distribuída.

2.3.4 BitTorrent

O BitTorrent é um sistema peer-to-peer robusto e altamente escalável (LEGOUTet al., 2007; LEVIN et al., 2008). Esse sistema, implementado e disponibilizado em2001, é o responsável por uma taxa de 18% a 35% de todo o tráfego de dados daInternet. O sistema permite que múltiplos clientes, denominados peers, possamrealizar o download de um arquivo concorrentemente, através do compartilhamentodos blocos de dados do arquivo (SALMON; TRAN; ABHARI, 2008; LUAN; TSANG,2006).

Segundo Salmon, Tran e Abhari (2008), o protocolo BitTorrent pode ser divididoem 3 componentes principais:

• Seeder inicial: é o peer que contém o arquivo completo sendo distribuído;

• Tracker: é um servidor centralizado que mantém uma lista de todos os peerspresentes na rede, além de coletar estatísticas de utilização da rede;

• Arquivo torrent: é um arquivo de metadados com informações sobre os da-dos sendo distribuídos na rede, possuindo a extensão .torrent. Esse arquivoé criado pelo seeder inicial, que divide o arquivo a ser compartilhado em blocosde dados, normalmente com tamanho entre 65 kilobytes e 1 megabyte (SAL-MON; TRAN; ABHARI, 2008). Além disso, esse seeder calcula o checksumpara cada bloco criado, utilizando um algoritmo de hash. Dessa maneira, oarquivo torrent contém o nome do arquivo original sendo compartilhado, otamanho e o hash de cada bloco de dados do arquivo e o endereço do tracker.

Para entrar nessa rede, primeiramente o cliente deve contatar um tracker, que éo único componente centralizado do sistema. Ao ser contatado, o tracker adiciona onovo cliente a sua lista de peers e envia um subconjunto randômico de peers para onovo cliente poder entrar na rede (ARTHUR; PANIGRAHY, 2006). O cliente, porsua vez, ao receber a lista, fará tentativas de estabelecimento de conexão com umou mais nodos, e, caso ele consiga poucos vizinhos, há a possibilidade de solicitaroutros endereços de peers ao tracker. Inicialmente, o cliente é chamado de leecher,

36

pois ele dá preferência ao recebimento de dados. Ao completar o arquivo, o clientetorna-se um seeder no sistema, pois ele somente enviará dados para outros peers darede, não consumindo recursos (PARVEZ et al., 2008).

Após estar na rede, o cliente começa a requisitar blocos de dados. A seleção deblocos de dados é feita com extrema cautela, já que um julgamento errado pode levara uma situação em que o cliente terá todos os blocos que estejam sendo oferecidos,não conseguindo os restantes, ou, por outro lado, não tendo nenhum bloco paraenviar aos seus vizinhos.

No início, quando o cliente não possui nenhum bloco completo para realizar oupload, ele seleciona blocos aleatórios para pegar, até que ele complete o primeirobloco de dados. Após ter um bloco completo, é utilizado o algoritmo rarest-first paraa seleção de blocos. Esse algoritmo seleciona o bloco que o menor número de peersvizinhos possui, ou seja, o bloco mais raro naquela área da rede de sobreposição.Assim, o objetivo do algoritmo é realizar o download de blocos de outros peers,somente pegando dos seeders blocos que nenhum vizinho possui (COHEN, 2003;PARVEZ et al., 2008; LUAN; TSANG, 2006; SHERMAN; NIEH; STEIN, 2009).

O cliente conhece os blocos que seus vizinhos possuem através das mensagenstrocadas no estabelecimento da conexão, que possuem um campo de bits, no qualsão informados quais blocos completos o cliente possui. Além disso, cada peer enviamensagens para seus vizinhos quando ele completa o recebimento de um novo bloco(NGIWLAY; INTANAGONWIWAT; TENG-AMNUAY, 2008).

Para decidir com qual peer trocar dados, o cliente utiliza o algoritmo de cho-king. O algoritmo dá preferência aos peers com altas taxas de upload, além de ter oobjetivo de eliminar clientes que não compartilham dados (NGIWLAY; INTANA-GONWIWAT; TENG-AMNUAY, 2008).

A grande vantagem desse sistema é que a rede possui múltiplas cópias do arquivosendo compartilhado, devido a sua divisão em blocos. O número de cópias aumentade dois modos: quando um cliente finaliza o download do arquivo ou quando umconjunto de clientes podem combinar os seus blocos para formar uma nova cópia doarquivo (SALMON; TRAN; ABHARI, 2008). Entretanto, de acordo com (GUO etal., 2005), o BitTorrent possui 3 desvantagens principais:

• A disponibilidade dos dados do sistema decai rapidamente, devido ao decrés-cimo da chegada de peers com o passar do tempo e a falta de seeders. Issoocasiona uma dificuldade crescente aos peers em localizar certos blocos doarquivo;

• O desempenho dos clientes no sistema é instável, variando de acordo com ospeers presentes na rede;

• A taxa de compartilhamento de dados dos clientes (taxa de upload dividia pelataxa de download) decresce muito rapidamente.

Além disso, ao finalizar um download, não há incentivos para o cliente per-manecer conectado, exceto pelo fato do compartilhamento de dados. Também háo problema da cifragem de dados, que é necessária devido às restrições impostas

37

pelos servidores de acesso à Internet, ocasionando um overhead extra ao sistema(SALMON; TRAN; ABHARI, 2008).

Legout et al. (2007) realizaram um estudo experimental sobre as propriedadesdo protocolo, o uso da largura de banda dos peers, principalmente de upload, ea metodologia de incentivo ao compartilhamento de arquivos, variando-se algunsparâmetros entre os testes, como a taxa de upload de leechers e seeders, a fim deavaliar o algoritmo de choking.

Em testes de incentivo de compartilhamento, com um seeder inicial com grandecapacidade de upload, foi demonstrado que o algoritmo de choking empregado peloBitTorrent desempenha bem a sua função: os clientes que mais contribuem comdados para a rede são os primeiros a completar o download do arquivo. Além disso,leechers lentos acabam recebendo maior quantidade de dados provenientes de seeders,que enviam dados aos peers sem levar em conta a velocidade de upload de cada um(LEGOUT et al., 2007).

Apesar da descentralização, o sistema ainda possui um componente centralizado,o tracker. Fry e Reiter (2006) apresentam um modelo para remover completamenteesse componente, substituindo-o por um conjunto de protocolos distribuídos base-ados em caminhadas aleatórias pela rede, porém sem localizar todos os nodos dosistema.

Nesse modelo, a entrada de um peer na rede é feita a partir de pontos de entrada(entry points), que desempenham uma função semelhante a de um tracker, podendoou não pertencer a rede. Dessa forma, em um primeiro momento, cada ponto deentrada na rede só conhece alguns peers.

Para fornecer ao novo cliente da rede um conjunto aleatório de peers, há duasopções: o ponto de entrada utiliza o caminhamento aleatório pela rede, a partir deseus vizinhos, ou o novo nodo pode realizar esse caminhamento pela rede, reduzindoo overhead do ponto de entrada. Além disso, caso um nodo esteja precisando devizinhos, ele pode adquiri-los a partir de qualquer nodo da rede, já que todos podemdesempenhar a função de ponto de entrada.

Os testes realizados com esse novo modelo mostraram que o sistema é expandidode modo similar ao modelo com tracker, ou, em certas ocasiões, essa expansão é atésuperior. Entretanto, a expansão do sistema pode ser melhorada, renovando-se oconjunto de vizinhos dos pontos de entrada. Essa renovação pode ser feita após umdeterminado período de tempo, aleatoriamente removendo-se vizinhos ou realizando-se o caminhamento aleatório nos vizinhos de algum vizinho.

Há também a possibilidade de integrar-se esse modelo com o modelo atual doBitTorrent, com tracker junto com pontos de entrada. Dessa maneira, novos clientespoderiam entrar na rede mesmo se o tracker estivesse com problemas.

2.4 Síntese

Com base nos sistemas apresentados, percebe-se diversas características distri-buídas entre os diferentes projetos que levam ao seu êxito, desempenhando uma fun-ção vital na obtenção de resultados satisfatórios. Entretanto, esses sistemas também

38

apresentam desvantagens, alguns no seu projeto e outros na sua implementação.

No caso do NFS, houve uma grande evolução da versão 3 para a versão 4,principalmente no que diz respeito ao overhead de comunicação entre os clientes e oservidor. Além disso, o NFS roda em espaço de kernel, o que diminui o overhead deprocessamento do sistema. Embora o NFS seja um sistema projetado nos mínimosdetalhes, ele foi baseado no modelo cliente/servidor, o que limita consideravelmentea sua escalabilidade. Ele também não possui um controle de falhas eficiente, já que,em casos de corrupção de dados, a resposta do NFS ao usuário pode não refletir o querealmente ocorreu na operação, muitas vezes retornando sucesso em uma operaçãoque falhou ou até mesmo corrompendo partes do kernel do Linux. Também há aquestão do uso de RPC para a comunicação em rede, ocasionando um overheadmuito grande.

Já o Coda apresenta os mecanismos de operação desconectada, ocultando possí-veis falhas do servidor, e de cache persistente no cliente, aumentando o desempenhodo sistema e possibilitando ao usuário continuar a utilizá-lo em eventuais falhas darede. Embora a operação desconectada seja uma característica que traz benefícios,há também problemas, já que ela exige uma grande quantidade de memória cacheno cliente, além de acarretar problemas de consistência de dados caso a rede falhe eum arquivo seja alterado em mais de um cliente durante essa falha.

O xFS apresenta diversas características importantes para um sistema completa-mente distribuído, destacando-se o armazenamento dos dados dos arquivos, no qualesses dados são divididos entre os nodos da rede em uma granulosidade de bloco.Contudo, a granulosidade de distribuição em bloco de dados é pequena. Portanto,essa completa distribuição do sistema acarreta um overhead de comunicação muitogrande, devido a grande quantidade de informações que precisam ser trocadas entreos nodos do sistema.

O BitTorrent apresenta como diferenciais o controle da taxa de compartilha-mento de dados dos peers da rede, limitando o download dos clientes que não com-partilham seus dados na mesma proporção em que requisitam novos dados, e aescalabilidade, possibilitando a formação de uma rede de sobreposição entre milha-res de peers. Por outro lado, os algoritmos utilizados pelo BitTorrent nem semprealcançam o objetivo desejado. Há ocasiões em que a taxa de compartilhamento dedados dos peers é muito baixa e o maior dos problemas é quando o seeder inicialdo sistema possuir uma baixa largura de banda para o compartilhamento de umdeterminado arquivo.

A Tabela 2.1 resume os sistemas estudados com alguns dos principais atributosde sistemas de distribuição de arquivos. Para cada atributo apresentado na tabela,foram definidos três valores possíveis em ordem crescente: baixo, médio e alto. Ovalor do atributo para cada sistema na tabela indica o quanto esse atributo influenciaa execução desse sistema.

Ao analisar essas características, percebe-se a importância de se projetar e imple-mentar com cuidado um sistema peer-to-peer, dando especial atenção aos seguintesdetalhes:

• Comunicação em rede, evitando a troca exagerada de mensagens entre os peers

39

Tabela 2.1: Síntese das características dos sistemas estudados

Sistema Escalabilidade Utilização dememória

Overhead decomunicação

em redeDisponibilidade Robustez

NFS Baixa Média Alto Alta Altasmbfs / cifs Baixa Média Médio Alta Média

Coda Alta Alta Alto Alta MédiaxFS Alta Média Alto Alta Alta

Gnutella Média Baixa Médio Média MédiaFreenet Alta Alta Alto Média MédiaIvy Média Média Alto Média Média

BitTorrent Alta Média Médio Alta Alta

da rede;

• Armazenamento de dados de arquivos na memória do cliente, já que essamemória é utilizada como cache do sistema

• Overhead de processamento do sistema.

Dessa forma, é necessário desenvolver uma interface otimizada para o sistema,capaz de atender às requisições do usuário em um intervalo de tempo, idealmente,igual ao de um sistema de arquivos local. Entretanto, também é necessário controlara utilização de memória ocasionada pelo armazenamento dos dados dos arquivosremotos. Com base nisso, é preciso que haja um balanceamento entre o tempo deresposta das requisições do usuário e a utilização de memória do sistema.

40

3 LOCAL PEER-TO-PEER PROTOCOL

O Local Peer-to-Peer Protocol (LP2P) (ROCHA; MARCON; ÁVILA, 2010) éuma plataforma de comunicação P2P para uso em ambientes de redes locais (LANs),sendo totalmente descentralizado, escalável, autogerenciável e auto-organizável. Elereúne características da arquitetura peer-to-peer e das redes locais para prover ocompartilhamento de arquivos de forma eficiente e distribuída. Além disso, o LP2Pemprega mecanismos de confiança e recompensa e possui um módulo de descobertade serviços, minimizando o overhead da comunicação em rede e aumentando a trans-parência das ações efetuadas perante o usuário.

Dessa forma, é necessário que cada usuário execute o daemon LP2P localmente.À medida que o LP2P de vários clientes são inicializados na rede, é realizada umaverificação quanto ao conjunto de compartilhamentos especificados por cada usuário,sendo que esses compartilhamentos são definidos através de dados de inicialização.O conceito de compartilhamento é similar ao conceito de “pasta compartilhada”,presente em diversos sistemas operacionais. Há também a possibilidade de criaçãode compartilhamentos sigilosos, cuja transferência de conteúdo é protegida por meiode criptografia, com o acesso inicial sendo autorizado mediante a apresentação decredenciais válidas (senhas ou chaves criptográficas). Após a sua inicialização, odaemon presente em cada máquina busca verificar o conteúdo disponível nos demaisintegrantes dos compartilhamentos que ele possui.

Assim, é formada uma base de conhecimento composta por compartilhamentos,hosts e dados compartilhados, que, por sua vez, estão disponíveis para o uso deaplicações externas presentes em cada peer e que se comunicam com a plataformaLP2P localmente. Essas aplicações, que utilizam as informações fornecidas peloLP2P, formam a interface do sistema aos usuários, contendo a relação de arquivosdisponíveis como uma pasta única, porém fisicamente distribuída.

Um exemplo do funcionamento do LP2P pode ser visualizado na Figura 3.1.Nesse exemplo, o peer01 e o peer04 ingressam no compartilhamento mapas e opeer02 e o peer03 conectam-se ao compartilhamento pesquisa (ROCHA; MAR-CON; ÁVILA, 2010).

O LP2P realiza toda a interface entre peers e aplicações, empregando uma abor-dagem descentralizada e escalável. De acordo com o modelo peer-to-peer descentra-lizado, a arquitetura conta com o envolvimento de todos os participantes da redepara garantir a manutenção dos índices responsáveis pela localização e distribuiçãodos arquivos disponíveis em cada compartilhamento.

41

recife.gif

peer01

redes.pdf

peer02

mapas.gz

peer04

lp2p.tex

peer03pesquisa

redes.pdflp2p.tex

mapas

mapas.gzrecife.gif

Figura 3.1: Funcionamento do LP2P

Vale ressaltar que esse protocolo foi planejado e desenvolvido com o objetivode gerar um baixo overhead de comunicação, mas com alta eficiência. Com essameta, foi especificado um conjunto de mensagens de controle, que empregam em suamaioria mensagens do tipo multicast, e de transferência de dados, que são do tipounicast. A diferenciação na forma de envio desses pacotes melhora o aproveitamentoda largura de banda e auxilia nas questões de escalabilidade do modelo.

Esse capítulo está estruturado da seguinte maneira: a arquitetura do sistema éexplicada na Seção 3.1, o formato das mensagens de comunicação interna do sistema,as quais são utilizadas para a comunicação com o sistema de arquivos desenvolvidonesse projeto, é mostrado na Seção 3.2 e, por fim, na Seção 3.3, são descritos osmódulos externos ao sistema.

3.1 Arquitetura

A arquitetura do LP2P foi definida modularmente, a fim de garantir o funcio-namento do sistema com aplicações externas, como interfaces HTTP e sistemas demontagem de arquivos, bem como com os sistemas para descoberta de serviços e me-canismos de recompensa e confiança. Ela é mostrada na Figura 3.2, apresentandoas seguintes características:

• Pilha de protocolos: para garantir a modularização da arquitetura, facili-tando o seu desenvolvimento e a escalabilidade do sistema;

• Correlação: para definir a relação de funcionamento entre os diferentes mó-dulos do sistema;

• Sistema de mensagens: para estabelecer um padrão de mensagens no sis-tema, tanto internamente no host, quanto externamente na comunicação en-tre os participantes da rede. Esse conjunto de mensagens é responsável peladivulgação de informações de controle e de transferência de dados, tanto re-motamente entre os peers quanto de cada peer às aplicações locais;

• Método de transporte: define o protocolo de transporte a ser utilizado e otamanho dos blocos de dados.

42

Hardware

LP2P

Aplicações

LP2P-CORE

LP2PFSMGT-MSGMGT-BDTrust

LP2PSec-SD

Figura 3.2: Arquitetura do sistema LP2P

O módulo LP2P-CORE disponibiliza uma interface de comunicação entre todosos componentes do sistema, oferecendo uma camada de abstração entre as plata-formas de comunicação, de descoberta de serviços, de sistema de recompensa, deinteração com a base de conhecimento e de aplicações externas. Seu comportamentodependerá do tipo de ação a ser executada, bem como dos aspectos de segurançaempregados aos compartilhamentos da rede. Assim, as seguintes situações são pos-síveis:

• Inicialização: é efetuada na entrada de um peer na rede. Primeiramente, érealizada a verificação dos compartilhamentos disponíveis na rede, validando-os com os parâmetros locais. Após, são enviadas solicitações multicast paraa obtenção dos recursos disponíveis e de suas respectivas informações. Casoexista um compartilhamento de acesso restrito, é necessário que o móduloexterno Sec-SD envie ao LP2P-CORE uma chave de grupo, possibilitando aopeer requisitar chaves de sessão no futuro;

• Atualização: para garantir a consistência dos dados presentes no sistema, érealizado o monitoramento periódico de alterações nos arquivos presentes noscompartilhamentos do sistema. Ao detectar modificações em arquivos, o mó-dulo realiza duas ações. A primeira ação consiste na atualização da base localde conhecimento, com a ajuda do módulo LP2P-BD. Após, a segunda açãoconsiste em propagar essa modificação aos demais participantes da rede, coma ajuda do módulo LP2P-MSG. A mensagem de notificação é transmitida viamulticast, com a possibilidade de ser criptografada caso o compartilhamentoem que ocorreu a alteração seja restrito;

• Estabelecimento de Chaves de Sessão: ao identificar a necessidade detrocar dados de forma segura, o LP2P-CORE verifica a existência de umachave de sessão para o peer. Caso o peer não possua essa chave, ocorre umanegociação entre os peers envolvidos, com o auxílio da chave de grupo obtidana inicialização. Ao adquirir essa chave, o peer irá armazená-la na sua base deconhecimento, possibilitando o estabelecimento de conexões seguras no futuro;

• Transferência de dados: o LP2P-CORE consulta a base de conhecimento dopeer, com o auxílio do módulo LP2P-BD, a fim de obter as fontes do recurso,bem como a sua reputação. De acordo com as informações obtidas, o módulo

43

define para qual peer será feita a solicitação de dados e envia uma mensagemde solicitação de dados ao peer escolhido;

• Comunicação Interna: envolve o recebimento de mensagens locais proveni-entes de sistemas de arquivos ou de outras aplicações que realizem a interfacedo sistema com o usuário.

O LP2P-CORE se comunica com o módulo LP2P-BD, que é o gerenciador dabase de conhecimentos do peer. Essa comunicação é feita com o objetivo de populara base de conhecimentos local, a qual utiliza um banco de dados local para regis-trar informações do sistema, como reputação, segurança, vizinhos, recursos locais erecursos disponíveis na rede.

O módulo LP2P-MSG é o responsável pelo envio e recebimento de mensagens nosistema. Dessa maneira, a comunicação entre os peers remotos e entre o sistema comas aplicações é feita através da troca de mensagens. Essas mensagens são divididasem quatro grupos, denominados grupos de primitivas, os quais são:

• Manipulação de arquivos: engloba toda ação referente a manipulação dearquivos no sistema. Esse grupo é dividido em quatro mensagens principais:

– List: enviada por um peer da rede aos outros para solicitar a listagemde arquivos presentes em um determinado compartilhamento;

– Send list (sendl): enviada em resposta ao recebimento de uma men-sagem list, contendo os arquivos que o peer possui no compartilhamentoespecificado na mensagem list;

– Get: mensagem de solicitação de envio de um conjunto de dados de umarquivo;

– Send file (sendf): mensagem gerada pelo peer em resposta ao recebi-mento da mensagem get, contendo os dados solicitados;

• Notificações do sistema: são mensagens informativas sobre modificaçõesque ocorrem no sistema. Podem ser de:

– Adição de arquivos: informa que um ou mais arquivos foram adicio-nados a um determinado compartilhamento;

– Remoção de arquivos: atua na informação de remoção de um ou maisarquivos de um determinado compartilhamento;

• Erros do sistema: para mensagens que informam a ocorrência de erros du-rante uma determinada operação do sistema;

• Comunicação interna: utilizada para a comunicação interna do LP2P comas aplicações que realizem a interface com o usuário do sistema. Um exem-plo da comunicação do daemon LP2P com o sistema de arquivos LP2PFS éapresentado na Figura 3.3.

44

Figura 3.3: Comunicação interna do sistema LP2P

3.2 Mensagens de Comunicação Interna

A troca de dados entre o daemon e os módulos locais do LP2P é feita através doprotocolo da camada de transporte TCP. O formato geral da mensagem, que podeser visualizado na Figura 3.4, possui os seguintes campos:

• Protocolo, que possui o valor padrão “LP2P”;

• Versão, que indica a versão do LP2P em uso;

• Primitiva, que representa o grupo de primitivas do protocolo;

• Operação, que define a operação a ser executada de acordo com a primitiva;

• Um campo de tamanho variável, que possui os dados sendo transferidos.

Figura 3.4: Estrutura da mensagem LP2P

As primitivas objetivam agrupar de forma hierárquica o conjunto de operaçõesdefinidas pelo protocolo. Dessa maneira, o protocolo oferece um conjunto de 65536operações possíveis no sistema, já que os campos primitiva e operação possuem 1byte cada um. Resumidamente, os 7 primeiros bytes são fixos, enquanto o tama-nho do último campo, o payload da mensagem, dependerá do tipo de operação doprotocolo.

A primitiva de comunicação local, definida pelo grupo 4, é utilizada para a co-municação interna no peer, sendo, portanto, utilizada pela comunicação do daemoncom o sistema de arquivos LP2PFS. Nesse contexto, há 6 tipos de mensagens troca-das, os quais são local list (llist), local send list (lsenl), local get update (lgetu), localsend update (lsendu), local get (lget) e local send file (lsendf).

45

Local list (llist)

Esta mensagem é enviada ao LP2P para requisitar a listagem de conteúdo deum determinado compartilhamento. Basicamente, essa mensagem é enviada nomomento da montagem do sistema de arquivos. O campo de primitiva possui valor4 e o campo de operação possui valor 1. O seu formato pode ser visualizado naFigura 3.5.

Figura 3.5: Formato da mensagem llist

Local send list (lsendl)

É uma mensagem enviada pelo LP2P em resposta à mensagem list, contendoas informações dos arquivos presentes no compartilhamento solicitado. O campode primitiva possui valor 4 e o campo de operação possui valor 2. O formato damensagem lsendl pode ser visualizado na Figura 3.6.

Figura 3.6: Formato da mensagem lsendl

Local get update (lgetu)

A mensagem lgetu é enviada pelo sistema de arquivos ao ser solicitada a listagemdos arquivos presentes no compartilhamento montado, a fim de obter-se as informa-ções necessárias sobre eventuais alterações de arquivos desde a última comunicaçãocom o daemon. O campo de primitiva possui valor 4 e o campo de operação possuivalor 3. O seu formato é mostrado na Figura 3.7.

Local send update (lsendu)

Essa mensagem é gerada pelo LP2P em resposta ao recebimento de uma mensa-gem lgetu. Nela, estarão as informações de todos os arquivos adicionados, excluídos

46

Figura 3.7: Formato da mensagem lgetu

e alterados no compartilhamento desde a última comunicação. O campo de primi-tiva possui valor 4 e o campo de operação possui valor 4. O seu formato é mostradona Figura 3.8.

Figura 3.8: Formato da mensagem lsendu

Local get (lget)

É enviada pelo sistema de arquivos para solicitar um subconjunto dos dadosde um determinado arquivo. O campo de primitiva possui valor 4 e o campo deoperação possui valor 5. O seu formato é mostrado na Figura 3.9.

Figura 3.9: Formato da mensagem lget

Local send file (lsendf)

É uma mensagem gerada em resposta ao recebimento da mensagem lget, con-tendo os dados solicitados. O campo de primitiva possui valor 4 e o campo deoperação possui valor 6. O seu formato pode ser visualizado na Figura 3.10.

3.3 Módulos Externos

O LP2P possui diversos módulos sendo desenvolvidos externamente ao núcleodo sistema, dentre os quais destacam-se o Secure Service Discovery (Sec-SD), oTrustLP2P e o LP2PFS.

47

Figura 3.10: Formato da mensagem lsendf

O módulo Sec-SD provê ao sistema recursos de descoberta de serviços em redeslocais. O módulo garante a segurança dos dados nos compartilhamentos de arquivosdo sistema, já que há a possibilidade de existência de arquivos confidenciais, os quaispodem ser acessados somente por um grupo específico de usuários do sistema, alémde ser necessário que um peer possa verificar a autenticidade de outro peer que lheenvia um arquivo. Dessa forma, o módulo possui recursos de descoberta e anúnciode serviços, possibilitando a automatização na descoberta de peers no sistema.

Outro módulo externo é o TrustLP2P, que é um sistema de reputação parao LP2P, cujo objetivo é recompensar os hosts da rede de acordo com o seu com-portamento, além de combater possíveis tipos de ataques maliciosos. Outro dadoutilizado é o valor de confiança, que é utilizado para determinar o quanto um peerconfia mesmo que o outro é quem está dizendo ser.

O terceiro módulo externo é o módulo do sistema de arquivos LP2PFS, que foidesenvolvido nesse projeto, o qual disponibiliza ao usuário os arquivos presentes noscompartilhamentos através da interface de sistema de arquivos do Linux. O sistemaLP2PFS é apresentado no capítulo 4.

48

4 LP2P FILE SYSTEM

O sistema de arquivos LP2P (LP2PFS) foi desenvolvido como um módulo parao kernel do Linux (SALZMAN, 2009), sendo um sistema de arquivos como qualqueroutro do ponto de vista do usuário. O objetivo do sistema de arquivos é proporcionarao usuário o acesso aos arquivos sendo compartilhados através do LP2P. Portanto,na primeira versão, o sistema de arquivos é um sistema somente leitura (read-only).

Para o sistema ser montado, basta ser digitado no terminal o seguinte comando:

# mount -t lp2pfs <nome_do_compartilhamento> <ponto_de_montagem>

onde:

• -t lp2pfs: significa o tipo de sistema de arquivos;

• <nome_do_compartilhamento>: informa o nome do compartilhamentodo sistema LP2P a ser montado;

• <ponto_de_montagem>: local em que o sistema de arquivos será montado.

A implementação do sistema de arquivos é descrita na Seção 4.1, sendo apresen-tada a sua estrutura na Seção 4.1.1 e o mecanismo de armazenamento de dados emmemória na Seção 4.1.2. Após, são apresentadas as otimizações feitas no código dosistema na Seção 4.2, de acordo com as técnicas oferecidas pela interface de progra-mação do kernel do Linux, e, na Seção 4.3, é descrita a comunicação com o sistemaLP2P. Por fim, são apresentadas algumas das funcionalidades do sistema, como no-tificação de eventos para as aplicações na Seção 4.4, o arquivo virtual do sistemaLP2PFS no sistema de arquivos Procfs na Seção 4.5 e as opções de montagem dosistema na Seção 4.6.

4.1 Implementação

A estrutura do sistema de arquivos deve estar de acordo com a camada do VirtualFile System (VFS) do kernel do Linux e, consequentemente, com o Page Cache parao armazenamento dos dados dos arquivos em memória.

49

4.1.1 Virtual File System

O kernel do Linux disponibiliza aos desenvolvedores uma camada de abstraçãopara a implementação de sistemas de arquivos, denominada Virtual File System(VFS). Assim, o principal objetivo do VFS é prover um método uniforme para amanipulação de arquivos, diretórios e outros objetos de diferentes sistemas de ar-quivos, como sistemas de arquivos locais (ext3 e ext4), sistemas de arquivos virtuais(Procfs e Sysfs) e sistemas de arquivos em rede (NFS) (LINUX KERNEL ORGA-NIZATION, 2010; MAUERER, 2008; BOVET; CESATI, 2005).

Na camada de abstração, são definidas as interfaces e estruturas de dados co-muns a todos os sistemas de arquivos. Dessa maneira, o detalhes específicos deimplementação de cada sistema são invisíveis ao kernel, que só necessita conhecer osmétodos genéricos de acesso ao sistema, que são definidos pelo VFS. Na Figura 4.1é mostrada a importância do VFS, possibilitando o suporte a vários sistemas dearquivos.

Figura 4.1: A camada de abstração do VFS

Apesar do código do VFS ter sido desenvolvido na linguagem C, foi utilizadoo conceito de orientação a objetos, simulando-o com o uso de estruturas. Nele, háquatro objetos principais, que formam a base de todos os sistemas de arquivos doLinux (LOVE, 2005b):

• super_block: é utilizado par armazenar informações de um determinado sis-tema, representando um sistema de arquivos montado. Essa estrutura estádefinida em <linux/fs.h> e uma versão simplificada é mostrada na Lista-gem 4.1.

Listagem 4.1: Estrutura super_blockstruct super_block {

struct list_head s_list;dev_t s_dev;unsigned long s_blocksize;unsigned char s_blocksize_bits;unsigned char s_dirt;unsigned long long s_maxbytes;struct file_system_type *s_type;const struct super_operations *s_op;/* ... */

50

unsigned long s_flags;unsigned long s_magic;struct dentry *s_root;struct rw_semaphore s_umount;struct mutex s_lock;int s_count;/* ... */struct list_head s_inodes;struct list_head s_dirty;/* ... */struct list_head s_instances;/* ... */void *s_fs_info;/* ... */

};

Nesse objeto, estão definidas diversas propriedades do sistema de arquivos,dentre as quais destacam-se o tamanho máximo de um arquivo, tamanho debloco de dados, um ponteiro para o diretório root do sistema montado e umalista de todos os inodes do sistema.Essa estrutura também apresenta um ponteiro (s_op) para a estrutura super_operations, a qual é composta por ponteiros de funções que devem ser de-finidas pelo sistema de arquivos para a manipulação do objeto super-bloco.Dentre essas funções, destacam-se os métodos utilizados para alocar e desalo-car um inode, preparar o sistema para ser desmontado e gerar estatísticas dosistema montado.

• inode: representa um arquivo e seus metadados. A estrutura está definida em<linux/fs.h> e uma versão simplificada pode ser visualizada na Listagem 4.2.

Listagem 4.2: Estrutura inodestruct inode {

struct hlist_node i_hash;struct list_head i_list;struct list_head i_sb_list;struct list_head i_dentry;unsigned long i_ino;atomic_t i_count;unsigned int i_nlink;uid_t i_uid;gid_t i_gid;dev_t i_rdev;u64 i_version;loff_t i_size;/* ... */struct timespec i_atime;struct timespec i_mtime;struct timespec i_ctime;/* ... */umode_t i_mode;spinlock_t i_lock;struct mutex i_mutex;struct rw_semaphore i_alloc_sem;const struct inode_operations *i_op;const struct file_operations *i_fop;

51

struct super_block *i_sb;struct file_lock *i_flock;struct address_space *i_mapping;/* ... */unsigned int i_flags;/* ... */void *i_private;

};

A maior parte dos elementos dessa estrutura é dedicada ao gerenciamento deinformações do arquivo, como data de modificação, data de criação, tamanhoem bytes, tamanho em blocos, o identificador do usuário e do grupo do usuárioque criou o arquivo e um número que identifica o objeto unicamente no sistemade arquivos. Entretanto, o nome do arquivo não está presente nesse objeto.Além disso, o inode é colocado em diversas listas, dentre as quais destacam-seuma tabela hash para acesso rápido, uma lista por super-bloco de todos osinodes e, por fim, em uma lista que varia de acordo com o estado atual doobjeto, podendo haver 3 estados principais:

– O objeto existe em memória, mas não está associado a nenhum arquivoválido;

– O objeto está em memória e sendo acessado por um ou mais processos;– O objeto está em uso, com seus dados tendo sido modificados.

A estrutura também contém um ponteiro para uma estrutura que representaas operações possíveis sobre um objeto inode, chamada inode_operations.Dentre as principais operações presentes na estrutura, destacam-se os métodospara criação e remoção de diretórios, criação de arquivos especiais, criação delinks simbólicos e manipulação de atributos de um arquivo.

• dentry: representa uma entrada de diretório, um único componente em um ca-minho para um arquivo. Esse objeto é definido no arquivo <linux/dcache.h>e pode ser visualizado na Listagem 4.3.

Listagem 4.3: Estrutura dentrystruct dentry {

atomic_t d_count;unsigned int d_flags;spinlock_t d_lock;struct inode *d_inode;struct hlist_node d_hash;struct dentry *d_parent;struct qstr d_name;struct list_head d_lru;union {

struct list_head d_child;struct rcu_head d_rcu;

} d_u;struct list_head d_subdirs;struct list_head d_alias;unsigned long d_time;struct dentry_operations *d_op;

52

struct super_block *d_sb;void *d_fsdata;

#ifdef CONFIG_PROFILINGstruct dcookie_struct *d_cookie;

#endifint d_mounted;unsigned char d_iname[DNAME_INLINE_LEN_MIN];

};

O conceito de dentry não é perceptível do ponto de vista do usuário, já queesse tipo de objeto é criado e destruído dinamicamente pelo VFS. Um exemplode uso desse tipo de objeto é a resolução de um caminho para um arquivo,como no caso do caminho /bin/ls. Nesse caso, são criadas dentries para /,bin e ls. Esses objetos são utilizados para a procura de arquivos no sistema,já que eles garantem a validade do caminho. Vale destacar que é nesse objetoque são armazenados os nomes dos arquivos.

As instâncias desses objetos formam uma rede de mapeamento da estruturado sistema de arquivos, já que uma entrada de diretório contém ponteirospara as instâncias das entradas dos seus arquivos e também das entradas dodiretório pai. Contudo, essa topologia do sistema de arquivos não é mape-ada totalmente, já que só permanecem na memória as entradas dos arquivosmais utilizados, principalmente devido ao tamanho da memória RAM e aodesempenho do sistema.

Esse objeto possui 3 estados possíveis:

– Usado: o objeto aponta para um inode válido, apontado pelo campod_inode e o seu contador (d_count) é positivo, indicando que o arquivoestá em uso;

– Não usado: o objeto aponta para um inode válido, mas ele não está emuso pelo VFS no momento, ou seja, o valor do campo d_count é zero. Oobjeto é mantido em memória por algum tempo, caso o arquivo venha aser utilizado, a fim de aumentar o desempenho do sistema.

– Negativo: significa que o objeto não está associado a nenhum inode, ouseja, o campo d_inode possui valor NULL.

Cada requisição ao sistema de arquivos leva o VFS a criar um objeto dentry,a fim de armazenar os resultados da requisição. Após o objeto ser criadoe inicializado, o kernel o coloca no directory entry cache, para possibilitar orápido acesso aos objetos em memória. Esse cache consiste em três partes:

– Uma tabela hash;

– Lista de dentries que referenciam o mesmo objeto inode, acessadasatravés do campo i_dentry desse objeto inode. Esse campo é imple-mentado como uma lista, pois um arquivo pode possuir vários links e,consequentemente, várias dentries;

– Uma lista LRU de dentries não usadas e negativas.

53

A estrutura também possui um ponteiro para um objeto que representa as ope-rações possíveis sobre uma entrada de diretório, a estrutura dentry_operations.As principais operações são: determinação da validade de uma entrada de di-retório, criação de um valor hash do objeto, comparação do objeto com outroobjeto e a remoção do objeto.

• file: representa um arquivo aberto, associado a um processo. O objeto écriado dinamicamente em resposta a chamada de sistema open e destruído nachamada close. A estrutura file está definida no arquivo <linux/fs.h> e émostrada na Listagem 4.4.

Listagem 4.4: Estrutura filestruct file {

union {struct list_head fu_list;struct rcu_head fu_rcuhead;

} f_u;struct path f_path;

#define f_dentry f_path.dentry#define f_vfsmnt f_path.mnt

const struct file_operations *f_op;atomic_t f_count;unsigned int f_flags;mode_t f_mode;loff_t f_pos;struct fown_struct f_owner;unsigned int f_uid, f_gid;struct file_ra_state f_ra;u64 f_version;

#ifdef CONFIG_SECURITYvoid *f_security;

#endifvoid *private_data;

#ifdef CONFIG_EPOLLstruct list_head f_ep_links;spinlock_t f_ep_lock;struct address_space *f_mapping;

#ifdef CONFIG_DEBUG_WRITECOUNTunsigned long f_mnt_write_state;

#endif};

O objeto representa a visão do processo sobre o arquivo, podendo haver di-versos objetos para um mesmo arquivo em um mesmo momento, se váriosprocessos estiverem com o arquivo aberto. Ele contém informações do modode abertura do arquivo, qual usuário invocou a chamada open e ponteiros paraoutras estruturas, como para a estrutura dentry do arquivo e para a estruturafile_operations, que contém ponteiros para funções de manipulação do ar-quivo. As principais funções são de leitura e escrita síncrona e assíncrona doarquivo, de mapeamento de memória e de sincronização dos dados do arquivo.

O VFS possui também outros objetos auxiliares, como a estrutura vfsmount,definida em <linux/mount.h>, que contém informações sobre a montagem do sis-

54

tema de arquivos, como o ponto de montagem e as opções passadas no momento damontagem.

Por fim, há a estrutura file_system_type, que é o ponto de entrada para osistema de arquivos no momento da montagem. Essa estrutura possui o nome dosistema de arquivos e ponteiros paras as funções que alocam (get_sb) e desalocam(kill_sb) o objeto super-bloco. Ela está definida em <linux/fs.h> e uma versãosimplificada é mostrada na Listagem 4.5.

Listagem 4.5: Estrutura file_system_typestruct file_system_type {

const char *name;int fs_flags;int (*get_sb) (struct file_system_type *, int,

const char *, void *, struct vfsmount *);void (*kill_sb) (struct super_block *);struct module *owner;struct file_system_type *next;struct list_head fs_supers;/* ... */

};

As relações entre alguns dos objetos do VFS são apresentadas na Figura 4.2.

Figura 4.2: Relações entre os objetos do VFS (fonte: Mauerer (2008))

Outras estruturas, presentes na estrutura de cada processo (task_struct), estãorelacionadas ao sistema de arquivos: a estrutura files_struct, definida no arquivo

55

<linux/file.h>, contém todas as informações dos arquivos abertos pelo processo,e a estrutura fs_struct, definida em <linux/fs_struct.h>, contém informaçõesdo sistema de arquivos relacionadas ao processo.

4.1.1.1 Mapeamento dos Metadados dos Arquivos

Para obter as informações dos arquivos presentes no compartilhamento montado,o LP2PFS envia as mensagens de requisição de lista de arquivos (llist) e requisiçãode atualização de arquivos no compartilhamento (lgetu). O daemon LP2P respondecom as mensagens de lista de arquivos no compartilhamento (lsendl) e atualização dalista de arquivos no compartilhamento (lsendu), respectivamente. Essas mensagensde resposta recebidas pelo sistema de arquivos possuem as seguintes informaçõessobre cada arquivo:

• Identificador (id) no sistema LP2P;

• Nome do arquivo;

• Tamanho do arquivo;

• Data de modificação do arquivo.

Com essas informações, o sistema de arquivos irá criar, para cada arquivo, umobjeto inode e um objeto dentry.

O objeto inode será alocado com um identificador único de inode dentro do sis-tema, armazenando o tamanho do arquivo e a sua data de modificação. Além disso,no campo i_private do objeto, o qual é utilizado para uso específico do sistemade arquivos, é colocado o identificador do arquivo no sistema LP2P. É importanteressaltar que o identificador do inode e o identificador do arquivo no sistema LP2Psão campos diferentes, não possuindo nenhuma relação entre si. Além disso, o objetoé colocado na lista de inodes do sistema, na tabela hash para acesso rápido e nalista que indica que o objeto está em memória.

O objeto dentry, por sua vez, é criado e associado ao inode do arquivo, ar-mazenando o nome desse arquivo. Esse objeto é colocado em uma lista hash paraacesso rápido e em uma lista de dentries que referenciam o mesmo inode.

4.1.2 Page Cache

O kernel utiliza parte da memória RAM para assegurar que os dados mais aces-sados e mais importantes estejam disponíveis quando houver uma requisição poreles, a fim de aumentar a eficiência do sistema, minimizando operações de entradae saída de dados (LOVE, 2005b).

O page cache manipula páginas da memória, dividindo a memória RAM e a me-mória virtual em pequenos segmentos, denominados páginas. Assim, ele é utilizadopara operações que estejam baseadas em unidades de páginas de memória. Alémdisso, a camada do VFS utiliza uma página de memória como unidade básica de

56

Figura 4.3: Relação entre as estruturas do VFS e do Page Cache (fonte: Mauerer(2008))

leitura e escrita em memória. É possível visualizar a relação entre o Virtual FileSystem e o Page Cache na Figura 4.3.

A base desse sistema é a estrutura address_space, que está associada a uminode e mantém todas as informações dos dados que estão na memória referentesàquele arquivo. Assim, essa estrutura estabelece a ligação entre os dados armazena-dos na memória e o dispositivo utilizado para se obter tais dados. Essa estrutura édefinida no arquivo <linux/fs.h> e uma parte dela é mostrada na Listagem 4.6.

Listagem 4.6: Estrutura address_spacestruct address_space {

struct inode *host;struct radix_tree_root page_tree;spinlock_t tree_lock;unsigned int i_mmap_writable;struct prio_tree_root i_mmap;struct list_head i_mmap_nonlinear;spinlock_t i_mmap_lock;unsigned int truncate_countunsigned long nrpages;pgoff_t writeback_index;const struct address_space_operations *a_ops;unsigned long flags;struct backing_dev_info *backing_dev_info;spinlock_t private_lock;struct list_head private_list;struct address_space *assoc_mapping;

} __attribute__((aligned(sizeof(long))));

Essa estrutura armazena diversas informações, dentre as quais as mais importan-tes são um ponteiro para o inode do arquivo correspondente, o número de páginasde dados armazenados na memória, a árvore em que estão armazenado os dadosem memória e uma estrutura que representa o meio físico em que os dados estãoarmazenados, denominada estrutura backing_dev_info.

57

Além disso, a estrutura apresenta um ponteiro para uma estrutura que definefunções para a manipulação de páginas, dentre as quais as mais relevantes são asfunções readpage e readpages, cujo protótipo é apresentado na Listagem 4.7. Essasfunções são invocadas para a leitura de uma página e de várias páginas por vez,respectivamente. Atualmente, o kernel chama, em situações normais, somente afunção readpages, aumentando o desempenho da busca por dados. Entretanto,em situações de exceção, como, por exemplo, ao ser retornado um erro pela funçãoreadpages, o kernel faz uma segunda tentativa de leitura dos dados do arquivoatravés da função readpage.

Listagem 4.7: Funções de leitura de páginasint (*readpage)(struct file *, struct page *);int (*readpages)(struct file *filp,

struct address_space *mapping,struct list_head *pages, unsigned nr_pages);

Vale ressaltar que na estrutura backing_dev_info há um campo denominadora_pages, no qual é definido o número médio de páginas lidas antecipadamente(readahead), com o objetivo de aumentar a eficiência do sistema.

Para o gerenciamento das páginas de dados em memória, é utilizada uma árvoreradix. Essa árvore não é balanceada, ou seja, cada galho da árvore pode possuirqualquer profundidade. As folhas da árvore são definidas como ponteiros para void,podendo ser instâncias de qualquer estrutura.

A raiz da árvore é definida pela estrutura radix_tree_root, que contém a alturamáxima da árvore e um ponteiro para o primeiro nodo da árvore. Os nodos sãorepresentados pela estrutura radix_tree_node, a qual possui um ponteiro para umarray (denominado slots) de filhos do nodo, cujo tamanho é definido pelo resultadoda operação 2RADIX_TREE_MAP_SHIFT. Cada nodo possui também um vetor de tags,sendo possível um número RADIX_TREE_MAX_TAGS de tags diferentes para cada filhodo nodo.

As folhas da árvore, nesse caso representadas pela estrutura page, contém os da-dos dos arquivos. O formato da estrutura da página é independente de arquitetura,somente a quantidade de dados armazenadas em cada página varia de arquiteturapara arquitetura, sendo definida pela constante PAGE_CACHE_SIZE. Além disso, aestrutura apresenta um campo de flags, que representam os atributos da página.Um exemplo de árvore radix é apresentado na Figura 4.4.

4.1.2.1 Mapeamento dos Dados dos Arquivos

Para obter os dados do arquivo requisitado pelo VFS, o LP2PFS envia a men-sagens de requisição de dados de um determinado arquivo (lget). O daemon LP2Presponde com uma mensagem contendo o intervalo de dados requisitado do arquivo(lsendf). A mensagem de resposta recebida pelo sistema de arquivos possui os se-guintes dados:

• Identificador (id) do arquivo no sistema LP2P;

• Posição inicial dos dados no arquivo;

58

Figura 4.4: Exemplo de uma árvore radix (fonte: Mauerer (2008))

• Tamanho do conjunto de dados;

• Os dados do arquivo.

O VFS irá requisitar esses dados através da chamada das funções readpage ereadpages. Essas funções são chamadas para a leitura de uma página e de várias pá-ginas de dados, respectivamente. O número de páginas lidas pela função readpagesé definido pelo VFS, levando-se em consideração o valor de páginas de readaheaddefinido no campo ra_pages da estrutura backing_dev_info. Essas funções irãose comunicar com o daemon LP2P, recebendo a mensagem com os dados.

Assim, os dados recebidos são armazenados em páginas da memória, PAGE_CACHE_SIZE bytes por página. Além disso, as páginas que possuem dados são adicionadasna árvore radix da estrutura address_space do arquivo. Os dados são sempre lidosem quantidades múltiplas do valor definido na constante PAGE_CACHE_SIZE, excetoquando o final do arquivo for atingido, quando a parte da página que não for pre-enchida com dados será completada com bytes de valor zero (0).

4.2 Otimizações

O kernel do Linux possui alguns mecanismos para otimizar certas partes do có-digo, além certos detalhes que o programador deve ter atenção para não desperdiçarmemória.

O compilador GCC define um conjunto de funções que permitem manipular aexecução de aplicativos de um modo que não seria possível sem recorrer a códigoAssembly. Cada arquitetura possui uma série dessas funções, denominadas funçõesbuiltin, entretanto algumas delas são comuns a todas as arquiteturas, sendo duasdelas utilizadas pelo kernel.

A função mais importante é a __builtin_expect, cujo protótipo pode ser vi-sualizado na Listagem 4.8. Ela influencia as predições do processador, ajudando ocompilador a otimizá-las. O primeiro argumento passado é a condição a ser avaliada

59

e o segundo argumento é o resultado mais frequente da condição: 1 caso ela sejafrequentemente verdadeira ou 0 caso contrário.

Listagem 4.8: Função __builtin_expect__builtin_expect(long expression, long c);

Dessa maneira, são definidas duas macros no arquivo <linux/compiler.h> docódigo fonte do kernel: likely, para condições que serão verdadeiras na maioriadas vezes, e unlikely, para condições que serão falsas na maioria das vezes. Essasmacros podem ser visualizadas na Listagem 4.9.

Listagem 4.9: Macros likely e unlikely# define likely(x) __builtin_expect(!!(x), 1)# define unlikely(x) __builtin_expect(!!(x), 0)

Uma curiosidade é o fato da dupla negação na definição dessas macros, queocorre devido a dois fatores: em primeiro lugar, isso permite que macros sejamutilizadas com ponteiros que são implicitamente convertidos em valores-verdade e,por fim, isso permite que valores-verdade maiores que zero sejam convertidos parao valor um, que é o esperado pela função __builtin_expect (MAUERER, 2008).

Outro recurso oferecido é a possibilidade da declaração de funções inline. Aoadicionar a palavra-chave inline na declaração da função, o compilador copia ocódigo dessa função para a posição na qual a função é chamada, exatamente comona utilização de uma macro. A grande vantagem de utilização desse método é quea verificação de tipos de dados é feita em tempo de compilação, como em chamadasnormais de funções.

O uso dessa técnica é importante, pois, apesar das chamadas de funções emC acrescentarem pouco overhead, em seções críticas e trechos de código frequente-mente chamados, é importante reduzir o tempo de processamento o máximo possível.Entretanto, essa técnica apresenta desvantagens, já que ao tornar inline funçõesfrequentemente utilizadas, o código binário gerado terá um tamanho muito maior,o que pode gerar problemas em certos sistemas (LOVE, 2005b).

Também é importante verificar questões de alinhamento de bytes, já que qual-quer dado elementar deve ser armazenado na memória em endereços divisíveis pelotamanho (largura) do seu tipo de dado. Na maioria das operações, isso não causaproblemas, pois ao alocar-se memória, o kernel assegura que os bytes estejam ali-nhados. Entretanto, isso pode levar a um aumento de utilização da memória, sem oconhecimento do programador (LOVE, 2005b; MAUERER, 2008).

Por exemplo, ao ser definida uma estrutura, pode ser necessário que o compiladoracrescente espaços na memória entre os campos da estrutura, denominados padding,devido à necessidade de alinhamento dos dados. Um caso possível é mostrado naFigura 4.5, cuja estrutura possui os seguintes campos: um ponteiro para string(“ptr1”), um caractere (“c”) e outro ponteiro para string (“ptr2”), na qual o kernelacrescentará um espaço livre entre o segundo campo e o terceiro, a fim de manter oponteiro “ptr2” alinhado.

Apesar disso, o kernel também disponibiliza métodos para o acesso de dadosnão alinhados em memória através das funções get_unaligned, utilizada para ler

60

Figura 4.5: Estrutura com alinhamento de bytes (fonte: Mauerer (2008))

um ponteiro não alinhado, e put_unaligned, que escreve um valor em um ponteironão alinhado.

4.3 Comunicação com o LP2P

A comunicação com o LP2P é feita apenas localmente, não sendo possível aosistema de arquivos comunicar-se com os daemons LP2P de outros peers da rede,devido a diversos fatores, dentre os quais destacam-se a confidencialidade e a inte-gridade dos dados. A comunicação local é feita através do protocolo da camada detransporte TCP. Essa comunicação ocorre nas seguintes situações:

• No momento da montagem do sistema de arquivos, a fim de buscar a lista dearquivos do compartilhamento solicitado, ocasionando o envio de uma mensa-gem llist e o consequente recebimento de uma mensagem lsendl. Essa situaçãopode ser visualizada na Figura 4.6, que exibe também as chamadas de funçõesdo VFS até o sistema de arquivos LP2PFS;

Figura 4.6: Montagem do sistema LP2PFS

• Quando o usuário solicitar a visualização dos arquivos presentes no comparti-lhamento montado, acarretando o envio de uma mensagem lgetu para requisi-tar as informações atualizadas dos arquivos no compartilhamento e o recebi-

61

mento de uma mensagem lsendu, com as informações dos arquivos que foramalterados desde a última comunicação com o LP2P;

• Ao ser aberto um arquivo, ocasionando o envio de uma mensagem de requisiçãodos dados do arquivo (lget) e o recebimento de uma mensagem com os dados doarquivo requisitado (lsendf). Essa situação pode ser visualizada na Figura 4.7;

Figura 4.7: Leitura do conteúdo de um arquivo

• Em determinados momentos, quando o kernel chamar a função de leitura as-síncrona dos dados do arquivo, que é invisível ao usuário. Essa chamada ocorredevido a função de readahead de dados presente no kernel, aumentando a efi-ciência do sistema do ponto de vista do usuário;

• O sistema possui uma thread com o objetivo de atualizar os arquivos presentesno compartilhamento. Essa thread requisita atualizações ao daemon LP2P emintervalos regulares de tempo. O intervalo de tempo entre as atualizações édefinido na constante UPDATE_INTERVAL.

4.4 Notificação de Eventos

O kernel do Linux necessita prover às aplicações um método rápido e eficientede sinalização para a ocorrência de modificações em arquivos de um determinadosistema. Para esse propósito, há duas interfaces disponíveis: dnotify e inotify.

A interface dnotify (directory notify) foi introduzida na versão 2.4 do kernel parareportar às aplicações modificações em diretórios. Já a interface inotify, que significainode notify e foi introduzida na versão 2.6.13 do kernel, atua como um subsistema,possuindo as mesmas funções da interface dnotify, exceto pelo fato dessa interfaceavisar às aplicações as mudanças ocorridas em qualquer arquivo do sistema, nãosomente em diretórios.

Desse modo, esse subsistema permite às aplicações requisitarem o monitora-mento de um conjunto de arquivos para uma lista de eventos. Ao ocorrer um evento,

62

a aplicação é notificada. Segundo Love (2005a), as vantagens desse subsistema emrelação a interface dnotify são:

• Com a interface dnotify só é possível monitorar diretórios. Por outro lado,inotify é baseado em inodes, possibilitando o monitoramento de eventos paraqualquer tipo de arquivo;

• dnotify necessita manter um descritor de arquivo aberto para o diretório sendomonitorado. Isso implica em problemas na desmontagem do sistema de arqui-vos ao qual o diretório pertence e em problemas relacionados a quantidade dedescritores de arquivos abertos quando for necessário monitorar diversos dire-tórios. Já a interface inotify não necessita de um descritor de arquivo abertopara o seu monitoramento;

• dnotify envia sinais às aplicações. Com inotify, a comunicação com a aplicaçãoé feita através de um único descritor de arquivo.

Apesar dessas vantagens, essas duas interfaces apresentam um problema emcomum: são interfaces complexas de serem implementadas pelos sistemas de arquivose pouco otimizadas. Por isso, foi desenvolvida a interface fsnotify, que implementaas duas interfaces de notificação de eventos de forma otimizada, aumentando odesempenho dos sistemas de arquivos (LINUX KERNEL ORGANIZATION, 2010).

Além disso, a interface fsnotify foi desenvolvida com um objetivo secundário:servir como camada intermediária para o novo subsistema de notificação do kernelque está sendo desenvolvido, chamado fanotify, cujo objetivo é integrar todos ossistemas de notificação em um só e servir como scanner de código malicioso emsistemas Linux (PARIS, 2009; CORBET, 2009).

Dessa forma, o sistema LP2PFS implementa a interface fsnotify para a noti-ficação de eventos para as aplicações, possibilitando às aplicações a utilização dequalquer uma das duas interfaces de notificação de eventos. Assim, as aplicaçõespodem requisitar o conjunto de arquivos a serem monitorados, bem como a lista deeventos. Isso também já proporciona ao sistema LP2PFS ser totalmente compatívelcom o novo sistema fanotify.

4.5 Arquivo no Sistema Procfs

O sistema de arquivos virtual Procfs, localizado em /proc, fornece um meca-nismo para os módulos do kernel enviarem informações para aplicações em espaçode usuário e para os próprios usuários (SALZMAN, 2009).

Há duas APIs disponíveis no kernel para a implementação de um arquivo nessesistema:

• A API padrão, que pode ser facilmente implementada. Entretanto, ela é útilsomente para lidar com pequenas quantidades de dados, que podem ser de,no máximo, PAGE_CACHE_SIZE bytes. Ela possibilita a criação de arquivose diretórios, sendo necessário especificar somente duas funções, uma para aleitura e outra para a escrita de dados no arquivo;

63

• A API seq_file, desenvolvida para facilitar a leitura dos arquivos presentesnesse sistema. Assim, é possível ler grandes quantidades de bytes, não havendonenhuma restrição sobre a quantidade de bytes a serem lidos. Também é pos-sível realizar operações de posicionamento do ponteiro dentro de um arquivo(seek). Entretanto, com essa API, as aplicações não podem realizar a operaçãode escrita no arquivo virtual (LINUX KERNEL ORGANIZATION, 2010).

Portanto, o módulo LP2PFS implementa a interface disponibilizada pela APIseq_file para o acesso de informações do sistema de arquivos. O arquivo virtualestá localizado em fs/lp2pfs/<nome_do_compartilhamento>. Nesse arquivo, sãodisponibilizados os seguintes dados: local da montagem do sistema, nome do com-partilhamento e as informações de todos os arquivos presentes no compartilhamentomontado, as quais são: número de identificação do inode no sistema de arquivos,ID do arquivo no sistema LP2P e nome e tamanho em bytes do arquivo.

4.6 Opções de Montagem

O sistema LP2PFS apresenta as seguintes opções de montagem:

• uid=<usuário>: representa o usuário que será o proprietário dos arquivospresentes no compartilhamento. Por padrão, se essa opção não for especificada,será utilizado o usuário do processo que chamou o comando de montagem dosistema de arquivos;

• gid=<grupo>: representa o grupo de usuários que será o proprietário dosarquivos presentes no compartilhamento. Caso essa opção não seja especifi-cada, o sistema utilizará o grupo principal do usuário que chamou o comandode montagem do sistema;

• port=<porta>: especifica a porta que será utilizada para realizar a comu-nicação com o LP2P. Caso essa opção não seja especificada, o sistema utilizaráa porta padrão definida na constante LOCAL_PORT.

64

5 VALIDAÇÃO E RESULTADOS EXPERIMENTAIS

A fim de validar o LP2PFS, foram realizados diversos testes, desde testes decompatibilidade com várias versões do kernel do Linux, até testes de desempenhodo sistema de arquivos em conjunto com o sistema LP2P.

A distribuição1 Linux escolhida para a realização dos testes foi a distribuiçãoDebian estável. Essa escolha deve-se, principalmente, a dois fatores: a estabilidadedo sistema e ao kernel utilizado.

A versão estável dessa distribuição é robusta, possuindo um bom sistema demonitoramento e correção de bugs, ao contrário de outras distribuições, que apre-sentam diversos erros, principalmente para os desenvolvedores que necessitam deum sistema estável. O segundo fator está relacionado ao código fonte do kernelutilizado por essa distribuição. Enquanto a maioria das distribuições aplica diversospatches2 ao código do kernel, visando customizá-lo para os seus interesses, a dis-tribuição Debian aplica somente patches de segurança, possibilitando a esse kernelser similar a versão original disponibilizada nos repositórios do kernel do Linux, emhttp://www.kernel.org.

Esse capítulo está organizado da seguinte maneira: na Seção 5.1 é descrito acompatibilidade do módulo do sistema implementado com as diferentes versões dokernel do Linux, com o objetivo de não restringir o módulo a uma única versãodo kernel. Já na Seção 5.2 são mostrados os testes de disponibilidade dos arquivospresentes no sistema, que é o principal objetivo do projeto. Por fim, na Seção 5.3,são apresentados os resultados de testes do sistema de arquivos em conjunto com osistema LP2P.

5.1 Versões do Kernel

A interface de programação do kernel do Linux sofre diversas alterações a cadanova versão do kernel disponibilizada. As principais alterações no VFS são em

1Uma distribuição é uma versão do Linux feita por uma companhia, organização ou por umindivíduo. Cada distribuição possui o seu conjunto de ferramentas e aplicações, entretanto todasutilizam como base o kernel do Linux (LINUX ONLINE INC., 2010).

2Um patch é um arquivo texto que contém as diferenças entre o código original e o novo código,além de informações adicionais sobre nomes de arquivos e números de linhas. Para aplicar um patchao código fonte do kernel, o programa patch é utilizado (LINUX KERNEL ORGANIZATION,2010).

65

seus objetos que representam as operações possíveis de serem realizadas sobre outroobjeto, com a adição e remoção de algumas funções desses objetos. Além disso, hávárias alterações nos protótipos de diversas funções essenciais para o programadorem espaço de kernel.

Devido a esses fatores, foi necessário comprovar o funcionamento do sistemade arquivos desenvolvido em diversas versões do kernel do Linux. Desse modo,o módulo LP2PFS foi compilado e executado com êxito no sistema Debian nasseguintes versões do kernel: 2.6.25, 2.6.26, 2.6.27, 2.6.28, 2.6.29, 2.6.30, 2.6.31,2.6.32, 2.6.33, 2.6.34 e 2.6.35.

5.2 Disponibilização dos Arquivos

A disponibilização dos arquivos presentes nos compartilhamentos do sistemaLP2P é o principal objetivo do trabalho de conclusão. Esse objetivo foi alcançadocom êxito, como é possível verificar na Figura 5.1, na qual é mostrado a sequen-cia de comandos desde o carregamento do módulo LP2PFS, a sua montagem e avisualização dos arquivos no compartilhamento montado através do comando ls.

Figura 5.1: Compartilhamento de pacotes Debian

Além disso, como é possível visualizar na Figura 5.1, o usuário pode acessaros arquivos sem possuir o conhecimento da sua localidade física, o que garante aosistema o objetivo de transparência de localização dos arquivos, possibilitando aousuário manipulá-los como se eles estivessem armazenados localmente.

Entretanto, nesse cenário de distribuição de arquivos entre diversas máquinas deuma rede local (LAN), torna-se necessário verificar a integridade dos dados recebidosda rede. Por esse motivo, no código fonte do sistema, na função de recebimento dedados, é feita uma verificação sobre a quantidade de dados esperada e a quantidadede dados recebida. Vale ressaltar que não é necessário verificar a integridades decada byte recebido, visto que a conexão com o daemon LP2P é feita através doprotocolo da camada de transporte TCP, que garante essa integridade de dados.

66

Apesar disso, foram realizados testes de integridade dos dados dos arquivospresentes no compartilhamento com o algoritmo MD53. Desse modo, a integridadedos dados dos arquivos presentes no compartilhamento foi comprovada.

5.3 Testes no Sistema LP2P

Foram realizados diversos testes de desempenho do sistema de arquivos LP2PFSem conjunto com o sistema LP2P. O protótipo do sistema LP2P utilizado para ostestes foi implementado na linguagem Java. Desse modo, o sistema de arquivosLP2PFS atuou como um front-end entre usuário e a pilha de protocolos LP2P.

Os testes foram executados no Laboratório de Uso Geral do PIPCA, com umarede local formada por 16 estações Linux (distribuição Debian Lenny com kernel2.6.26-2-686), com 4 GB de memória RAM, 250 GB de HD e processadores IntelCore 2 Duo de 1.8 GHZ. A estrutura de rede conta com tecnologia FastEthernet eswitches 3COM 10/100/1000, viabilizando a conexão dos peers a uma velocidade de100 Mbps. A versão do kernel do Linux utilizada para os testes foi a 2.6.26-2-686devido ao fato dessa versão ser a versão oficial do sistema estável da distribuiçãoDebian, possibilitando maior confiabilidade ao sistema e aos testes realizados.

Primeiramente, foi implementada uma aplicação do tipo PingPong entre doiscomputadores da rede, a fim de avaliar o desempenho puro do TCP nessa rede.Essa aplicação foi implementada na linguagem Java, já que o processo daemon doLP2P está sendo desenvolvido nessa linguagem de programação. A vazão de dadosde acordo com o tamanho das mensagens é mostrada na Figura 5.2, na qual é possívelverificar que a vazão de cada peer atinge um valor próximo do ideal com mensagenscujo tamanho se aproxima de 1 megabyte, e na Figura 5.3 é mostrada a latência decomunicação com o TCP.

2

3

4

5

6

7

8

9

10

11

12

1k 2k 4k 8k 16k 32k 64k 128k 256k 512k 1M

Vaz

ão (

MB

/s)

Tam. msg (bytes, log scale)

Figura 5.2: Vazão de dados usando TCP

3Message-Digest algorithm 5 (MD5) (RIVEST, 1992) é um algoritmo de hash que converte umconjunto arbitrário de bytes em uma saída de 128 bits. É utilizado para a verificação de integridadede dados.

67

0

200

400

600

800

1000

1200

1400

1600

1800

0 5000 10000 15000 20000 25000 30000

Latê

ncia

(us

)

Tam. msg (bytes)

Figura 5.3: Latência de comunicação usando TCP

Após o teste do PingPong, foram executados os testes com os sistemas LP2PFSe LP2P com 3 tamanhos diferentes de arquivos: 1 megabyte, 8 megabytes e 16 me-gabytes. Como o objetivo principal desses testes foi medir o desempenho e a eficiên-cia somente do sistema de arquivos, foram utilizadas diferentes configurações parao sistema de arquivos. Durante o desenvolvimento do módulo LP2PFS, foi consta-tado que o desempenho de um sistema de arquivos, nesse caso especificamente deum sistema de arquivos que requisita dados através de uma rede de alta velocidade,é dependente do número de páginas de dados configurado para o kernel requisitar aleitura antecipada desses dados, que é chamado de readahead.

Como mencionado no Capítulo 4, o readahead do sistema é definido no campora_pages da estrutura backing_dev_info. Esse valor é utilizado pelo kernel do Li-nux para definir a quantidade de páginas requisitadas para leitura através da funçãoreadpages da estrutura address_space_operations. Para calcular a quantidadede páginas a serem requisitadas, o kernel utiliza o número de páginas de readaheaddefinido pelo sistema de arquivos, além de considerar o número total de páginaslivres que o sistema operacional possui e o tamanho do arquivo.

Devido a necessidade de comunicação em rede, o valor do readahead torna-se essencial para garantir um bom tempo de resposta às requisições do usuário.Entretanto, esse valor não pode ser muito elevado, pois, quanto maior for o valor,maior será a utilização de memória do sistema.

Os testes foram feitos da seguinte maneira: cada peer presente na rede lê todosos arquivos de um mesmo tamanho presentes no compartilhamento, entretanto emordens diferentes. Por exemplo, o peer1 da rede lê os arquivos do peer2 até o peer16e, por fim, lê o seu próprio arquivo, já o peer2 lê o arquivo do peer3 até o peer16, lê dopeer1 e, por último, lê o seu próprio arquivo, e assim sucessivamente. Dessa forma,em qualquer instante de tempo do teste, cada peer está lendo um arquivo e enviandooutro arquivo para outro peer. Além disso, para cada tamanho de arquivo, o sistemade arquivos foi executado com os seguintes valores de readahead (em número depáginas de memória): 0, 25, 50, 75, 100, 125, 150, 175 e 200. Todos os resultadosdos testes mostrados são médias de, no mínimo, 30 repetições do experimento.

68

Os tempos de leitura de arquivos de 1 megabyte e a vazão individual obtidapor cada peer da rede são mostrados na Tabela 5.1 e na Figura 5.4, que mostrao gráfico da vazão de cada peer para os diferentes valores de readahead utilizados.Nesse caso, mesmo em arquivos de tamanho reduzido, é possível observar o quãoimportante é o papel desempenhado pela leitura dos dados de um conjunto grandede páginas por vez, representada pelo readahead do sistema. Nesse teste, a vazão dopeer não sofreu grandes alterações a partir do valor de 100 páginas de readahead,principalmente devido ao tamanho do arquivo.

Tabela 5.1: Teste do sistema com arquivos de 1 MB

Readahead (empáginas)

Arquivo de 1 MBTempo Vazão do Peer

0 14.838s 1.078 MB/s25 2.936s 5.450 MB/s50 2.686s 5.956 MB/s75 2.590s 6.177 MB/s100 2.586s 6.187 MB/s125 2.622s 6.103 MB/s150 2.623s 6.099 MB/s175 2.574s 6.217 MB/s200 2.543s 6.291 MB/s

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

0 25 50 75 100 125 150 175 200

Vaz

ão d

o pe

er (

em M

B/s

)

Readahead (em número de páginas)

Arquivos de 1 MB

Figura 5.4: Vazão individual de cada peer para arquivos de 1 MB

Com arquivos de 8 megabytes, os resultados são mostrados na Tabela 5.2 e naFigura 5.5. É possível, novamente, perceber a diferença de desempenho dos peers(mostrada pela vazão individual de cada peer) quando não há readahead definidoe quando há um valor definido, mesmo que baixo. É importante ressaltar que noscasos em que não há readahead definido (valor 0), o kernel requisitará ao sistema

69

de arquivos sempre a leitura de uma página de dados por vez, aumentando enorme-mente o overhead de comunicação pela rede do sistema LP2P. Novamente, o sistemaapresentou os melhores resultados com o readahead com valores de 175 e 200 páginasde memória.



Arquivo de 8 MBTempo Vazão do Peer

0 116.523s 1.098 MB/s25 19.923s 6.425 MB/s50 17.691 7.235 MB/s75 17.266s 7.413 MB/s100 16.594s 7.714 MB/s125 16.183s 7.910 MB/s150 16.108s 7.947 MB/s175 15.979s 8.010 MB/s200 15.178s 8.041 MB/s

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

0 25 50 75 100 125 150 175 200

Vaz

ão d

o pe

er (

em M

B/s

)



Os resultados dos testes com arquivos de 16 megabytes são mostrados na Ta-bela 5.3 e na Figura 5.6. Nesses testes, foi atingido o maior valor de vazão individualde um peer: 8.320 MB/s com 200 páginas de readahead. Com os resultados dos 3testes, é possível comprovar que o o readahead afeta diretamente o desempenho dosistema de arquivos, já que com valores maiores, a vazão do peer aumenta. En-tretanto, a partir de 150 páginas de readahead, a vazão do peer não sofre grandesvariações. Além disso, a vazão também é influenciada pelo tamanho do arquivosendo requisitado, já que em arquivos de 1 megabyte, a vazão máxima foi de 6.291MB/s, chegando a 8.041 MB/s com arquivos de 8 megabytes e atingindo o máximode 8.320 MB/s com arquivos de 16 megabytes.

70



Arquivo de 16 MBTempo Taxa (em MB/s)

0 233.858s 1.095 MB/s25 39.378s 6.501 MB/s50 34.867s 7.342 MB/s75 33.796s 7.575 MB/s100 32.591s 7.855 MB/s125 31.580s 8.106 MB/s150 31.707s 8.074 MB/s175 31.128s 8.224 MB/s200 30.769s 8.320 MB/s

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

0 25 50 75 100 125 150 175 200

Vaz

ão d

o pe

er (

em M

B/s

)



Não foram mostrados testes para arquivos maiores que 16 megabytes, devido aofato de, com arquivos de 16 megabytes, já ser possível saturar a rede com dados,visto que com arquivos desse tamanho e com um alto valor de readahead do sistemade arquivos (150 páginas ou mais), o kernel já requisita um grande número de dadospara leitura antecipada. Com isso, o sistema de arquivos requisitará, na maioria dasvezes, quantidades de dados que se aproximam do valor de 1 megabyte, com o qual oTCP atinge um valor de vazão de dados próximo do ideal, como pode ser comprovadopela Figura 5.2. Desse modo, com arquivos maiores, o desempenho individual decada peer permaneceu entre 8 MB/s e 8.5 MB/s, para valores de readahead maioresque 150 páginas de memória.

Na Tabela 5.4 e na Figura 5.7 são mostrados os valores da vazão agregada4

4Vazão agregada é o somatório da vazão de dados de todos os peers do sistema em um deter-minado momento.

71

do sistema para os 3 testes realizados, para cada um dos valores de readahead.É possível verificar facilmente que a medida que o valor de readahead aumentou,a vazão agregada também aumentou, além de aumentar também a medida queaumenta o tamanho do arquivo utilizado nos testes.

Tabela 5.4: Vazão agregada do sistema


Vazão agregada (VAG) do sistemaArquivo de 1 MB Arquivo de 8 MB Arquivo de 16 MB

0 18.332 MB/s 18.674 MB/s 18.610 MB/s25 92.655 MB/s 109.222 MB/s 110.519 MB/s50 101.252 MB/s 123.001 MB/s 124.818 MB/s75 105.006 MB/s 126.025 MB/s 128.774 MB/s100 105.186 MB/s 131.132 MB/s 133.532 MB/s125 103.752 MB/s 134.464 MB/s 137.810 MB/s150 103.691 MB/s 135.092 MB/s 137.258 MB/s175 105.687 MB/s 136.179 MB/s 139.810 MB/s200 106.950 MB/s 136.703 MB/s 141.442 MB/s

0

10

20

30

40

50

60

70

80

90

100

110

120

130

140

150

160

170

0 25 50 75 100 125 150 175 200

Vaz

ão a

greg

ada

do s

iste

ma

(em

MB

/s)


Arquivos de 1 MBArquivos de 8 MB

Arquivos de 16 MB

Figura 5.7: Vazão agregada do sistema

Entretanto, nos testes do sistema com 16 peers, não foi possível atingir umavazão individual de cada peer acima de 10 MB/s, o que seria o esperado paraum sistema que utiliza conexão de rede de 100 Mbps. Dessa forma, foi realizadooutro teste no sistema de arquivos LP2PFS. Com o objetivo de comprovar o realdesempenho do LP2PFS e que o resultado da vazão do sistema deve-se ao fatodo daemon LP2P estar em fase inicial de desenvolvimento, foi feito um teste queconsiste em ler um arquivo localizado localmente, não utilizando a conexão do LP2Pentre hosts remotos.

72

O arquivo utilizado para o teste possui o tamanho de 200 megabytes. Foi utili-zado um arquivo de tamanho maior para esse teste devido ao fato da leitura local sermuito rápida, não havendo como obter valores precisos com os arquivos utilizadosnos testes anteriores. Dessa maneira, a leitura local do arquivo a partir do sistemade arquivos LP2PFS segue os seguintes passos:

• Para cada requisição de dados que o LP2PFS envia ao LP2P

1. O LP2P requisita o intervalo de dados do arquivo ao sistema ext3 (oarquivo lido está armazenado em um sistema de arquivos ext3);

2. O sistema ext3 lê o intervalo de dados requisitado do disco rígido;3. O LP2P envia os dados para o LP2PFS.

Para esse experimento, foram realizadas 20 execuções e a média de tempo parao LP2PFS atender a requisição de cópia do arquivo foi de 3.614 segundos. Após, foirealizado o mesmo teste, entretanto sem a presença dos sistemas LP2P e LP2PFS,a fim de verificar o overhead imposto pelo sistema. Lendo o arquivo diretamente dosistema ext3, a média de tempo foi de 3.522 segundos.

Dessa forma, o overhead imposto pelo sistema LP2P e LP2PFS é de apenas2.61%, o que comprova o desempenho e a eficiência do sistema de arquivos LP2PFS,comprovando que o gargalo atual do sistema está no processo daemon LP2P.

Embora o sistema de arquivos LP2PFS esteja 100% completo, a implementaçãodo sistema LP2P ainda está em fase inicial de desenvolvimento. Para os testes, foiutilizado um protótipo do LP2P, que foi implementado, em sua primeira versão,apenas com o objetivo de permitir o compartilhamento de arquivos, sem consideraro desempenho das operações realizadas.

Além disso, considerando a relação do número de páginas de memória de rea-dahead definido no sistema e a utilização de memória, foi definida uma função nosistema de arquivos para calcular dinamicamente o valor de readahead no momentoda montagem do sistema, denominada set_readahead. Essa função define um valorbaseando-se na quantidade total de memória do sistema e no número páginas livresque o sistema possui no momento da montagem. Como resultado, a função calculao número ideal de páginas de readahead, que pode ser um valor entre 0 e 150 pági-nas. O valor superior ficou definido em 150 páginas, já que mesmo que o sistemapossua uma grande quantidade de memória livre, deve-se levar em consideração queo sistema de arquivos só terá disponível uma parte dessa memória.

73

6 CONCLUSÃO

Este trabalho apresentou o desenvolvimento de um sistema de arquivos em es-paço de kernel para atuar como a interface do sistema LP2P com o usuário, possibi-litando a interação do usuário com o sistema LP2P através de uma interface simplese amplamente utilizada.

O sistema de arquivos foi implementado em modo somente-leitura (read-only),devido ao fato do protocolo LP2P, atualmente, suportar somente operações de lei-turas de dados de arquivos. Ao montar o sistema, o usuário tem a possibilidade deinformar o uid e o gid do usuário do sistema que será o proprietário dos arquivos nosistema de arquivos, além de poder especificar a porta TCP em que a conexão como processo daemon do LP2P local será realizada.

O sistema de arquivos LP2PFS foi desenvolvido com base na estrutura da ca-mada de abstração do kernel do Linux para sistemas de arquivos, o Virtual FileSystem (VFS). Essa camada de abstração possibilita ao sistema ser montado den-tro de qualquer outro sistema de arquivos Linux, possibilitando ao usuário o acessouniforme a arquivos em diferentes sistemas de arquivos.

O gerenciamento dos dados dos arquivos em memória foi implementado coma utilização do subsistema de Page Cache, já que a interface do VFS utiliza essesubsistema para a manipulação de dados em memória. A unidade básica de dados deum arquivo é denominada página de memória, cujo tamanho varia entre as diferentesarquiteturas, mas, no kernel, é definido pela constante PAGE_CACHE_SIZE.

Além da funcionalidade básica de um sistema de arquivos, ou seja, possibilitaraos usuários o acesso aos arquivos presentes no sistema, foi implementado tambéma notificação de eventos do sistema para as aplicações. Desse modo, as aplicaçõesem espaço de usuário podem utilizar as interfaces fsnotify ou fanotify para requisitaro recebimento de eventos ocorridos no sistema de arquivos. Cada aplicação podeescolher os tipos de eventos que interessam, descartando os demais.

Outra funcionalidade importante, nesse caso voltada para os desenvolvedores,foi a criação de um arquivo virtual no sistema de arquivos Procfs. Esse arquivo estálocalizado em fs/lp2pfs/<nome_do_compartilhamento>, possibilitando o acessoa informações do sistema, como ponto de montagem, informações internas do sis-tema, como número dos inodes dos arquivos, e acesso aos metadados dos arquivospresentes no sistema.

Desse modo, o sistema de arquivos LP2PFS alcançou o seu objetivo, que é

74

disponibilizar os arquivos presentes nos compartilhamentos do LP2P aos usuários,provendo integridade de dados. Além disso, o sistema é compatível com diversasversões do kernel, não restringindo o usuário ao uso de uma versão específica.

Nos testes de desempenho, foi comprovado que o desempenho do sistema dearquivos é dependente do número de páginas de dados requisitadas pelo kernel doLinux para leitura. Esse número é influenciado de maneira direta pelo valor defi-nido, dentro do sistema de arquivos, na variável ra_pages, presente na estruturabacking_dev_info.

Os valores alcançados de vazão de dados dos peers não foram os ideais, mas esseresultado foi fortemente influenciado pelo estágio de desenvolvimento do sistemaLP2P, que possui implementado apenas um protótipo com poucas funcionalidadese que não está devidamente otimizado. Além disso, foi comprovado que o overheadpara a leitura de arquivos locais imposto pelo sistema completo (LP2P e LP2PFS) éde apenas 2.61%, indicando que o gargalo do sistema, atualmente, é a comunicaçãoem rede entre os processos daemon do LP2P.

O desenvolvimento desse trabalho de conclusão possibilitou a publicação doartigo “Comunicação Peer-to-Peer aplicado a Redes Locais”, publicado no Fórum dePós-Graduação da Escola Regional de Redes de Computadores de 2010, sendo eleitoo melhor artigo na sua categoria. Também foi enviado o artigo “LP2P: A Peer-to-Peer System for Local Area Networks” para a Conferência Internacional sobreNovas Tecnologias, Mobilidade e Segurança (Fourth IFIP International Conferenceon New Technologies, Mobility and Security).

Como trabalhos futuros, é possível citar a adição da funcionalidade de escritade dados em arquivos, quando o protocolo LP2P suportar essa operação. Tambémé possível portar o sistema de arquivos para outras versões do kernel do Linux queainda não são suportadas.

75

REFERÊNCIAS

ANDERSON, T. E. et al. Serverless network file systems. ACM Trans. Comput.Syst., ACM, New York, NY, USA, v. 14, n. 1, p. 41–79, 1996. ISSN 0734-2071.

ARTHUR, D.; PANIGRAHY, R. Analyzing bittorrent and related peer-to-peernetworks. In: SODA ’06: Proceedings of the seventeenth annual ACM-SIAMsymposium on Discrete algorithm. New York, NY, USA: ACM, 2006. p. 961–969.ISBN 0-89871-605-5.

BARBOSA, M. W. et al. Using locality of reference to improve performance ofpeer-to-peer applications. In: WOSP ’04: Proceedings of the 4th internationalworkshop on Software and performance. New York, NY, USA: ACM, 2004. p.216–227. ISBN 1-58113-673-0.

BATSAKIS, A. et al. Ca-nfs: A congestion-aware network file system. Trans.Storage, ACM, New York, NY, USA, v. 5, n. 4, p. 1–24, 2009. ISSN 1553-3077.

BLAIR, J. Introducing samba. Linux J., Specialized Systems Consultants, Inc.,Seattle, WA, USA, p. 12, 1998. ISSN 1075-3583.

BOVET, D.; CESATI, M. Understanding the Linux Kernel, Third Edition. 3. ed.[S.l.]: O’Reilly Media, Inc., 2005. Paperback. ISBN 0596005652.

CALLAGHAN, B.; PAWLOWSKI, B.; STAUBACH, P. RFC 1813 - NFS Version3 Protocol Specification. 1995. Disponível em <http://www.rfc-archive.org/getrfc.php?rfc=1813>. Acesso em abr. 2010.

CARNEGIE MELLON UNIVERSITY. Coda File System. 2000. Disponível em<http://www.coda.cs.cmu.edu/>. Acesso em maio 2010.

CEBALLOS, M.-R.; GORRICHO, J.-L. P2p file sharing analysis for a betterperformance. In: ICSE ’06: Proceedings of the 28th international conferenceon Software engineering. New York, NY, USA: ACM, 2006. p. 941–944. ISBN1-59593-375-1.

CHAI, L. et al. pNFS/PVFS2 over infiniband: early experiences. In: PDSW ’07:Proceedings of the 2nd international workshop on Petascale data storage. NewYork, NY, USA: ACM, 2007. p. 5–11. ISBN 978-1-59593-899-2.

CHAWATHE, Y. et al. Making gnutella-like p2p systems scalable. In: SIGCOMM’03: Proceedings of the 2003 conference on Applications, technologies, architectures,

76

and protocols for computer communications. New York, NY, USA: ACM, 2003. p.407–418. ISBN 1-58113-735-4.

CHESHIRE, S.; KROCHMAL, M. DNS Based Service Discovery. 2010. Disponívelem <http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt>. Internet draft.Acesso em abr. 2010.

CHESHIRE, S.; KROCHMAL, M. Multicast DNS. 2010. Disponível em<http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt>. Internetdraft. Acesso em abr. 2010.

CHESHIRE, S.; STEINBERG, D. H. Zero Configuration Networking. [S.l.]:O’Reilly Media, 2006.

CLARKE, I. et al. Freenet: A Distributed Anonymous Information Storage andRetrieval System. Lecture Notes in Computer Science, v. 2009, p. 46–66, 2001.

COHEN, B. Incentives Build Robustness in BitTorrent. [S.l.], 2003. Disponível em:<http://jmvidal.cse.sc.edu/library/cohen03a.pdf>.

CORBET, J. The fanotify API. 2009. Disponível em <http://lwn.net/Articles/339399/>. Documentação explicativa sobre o sistema fanotify. Acesso em ago. 2010.

COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed Systems:Concepts and Design. [S.l.]: Bookman, 2007.

DUFOUR, A.; TRAJKOVIĆ, L. Improving gnutella network performance usingsynthetic coordinates. In: QShine ’06: Proceedings of the 3rd internationalconference on Quality of service in heterogeneous wired/wireless networks. NewYork, NY, USA: ACM, 2006. p. 31. ISBN 1-59593-537-1.

FRENCH, S. Linux CIFS Client Guide. 2007. Disponível em <http://pserver.samba.org/samba/ftp/cifs-cvs/linux-cifs-client-guide.pdf>. Acesso em out. 2010.

FRY, C. P.; REITER, M. K. Really truly trackerless bittorrent. [S.l.], 2006.

GUO, L. et al. Measurements, analysis, and modeling of bittorrent-like systems.In: IMC ’05: Proceedings of the 5th ACM SIGCOMM conference on InternetMeasurement. Berkeley, CA, USA: USENIX Association, 2005. p. 4–4.

HILDEBRAND, D.; HONEYMAN, P. Direct-pnfs: scalable, transparent, andversatile access to parallel file systems. In: HPDC ’07: Proceedings of the 16thinternational symposium on High performance distributed computing. New York,NY, USA: ACM, 2007. p. 199–208. ISBN 978-1-59593-673-8.

KRISHNAN, S. et al. The effects of metadata corruption on NFS. In: StorageSS’07: Proceedings of the 2007 ACM workshop on Storage security and survivability.New York, NY, USA: ACM, 2007. p. 37–41. ISBN 978-1-59593-891-6.

KUROSE, J. F.; ROSS, K. W. Computer Networking: A Top-Down Approach.5th. ed. USA: Addison-Wesley Publishing Company, 2009. ISBN 0136079679,9780136079675.

77

LEGOUT, A. et al. Clustering and sharing incentives in bittorrent systems. In:SIGMETRICS ’07: Proceedings of the 2007 ACM SIGMETRICS internationalconference on Measurement and modeling of computer systems. New York, NY,USA: ACM, 2007. p. 301–312. ISBN 978-1-59593-639-4.

LEVIN, D. et al. Bittorrent is an auction: analyzing and improving bittorrent’sincentives. In: SIGCOMM ’08: Proceedings of the ACM SIGCOMM 2008conference on Data communication. New York, NY, USA: ACM, 2008. p. 243–254.ISBN 978-1-60558-175-0.

LINUX KERNEL ORGANIZATION. The Linux Kernel Archives. 2010. Disponívelem <http://www.kernel.org>. Acesso em abr. 2010.

LINUX ONLINE INC. The Linux Home Page. 2010. Disponível em <http://www.linux.org>. Acesso em set. 2010.

LOVE, R. Intro to inotify. Linux Journal, 2005.

LOVE, R. Linux Kernel Development (2nd Edition). [S.l.]: Novell Press, 2005.ISBN 0672327201.

LUAN, H.; TSANG, D. H. K. A simulation study of block management inbittorrent. In: InfoScale ’06: Proceedings of the 1st international conference onScalable information systems. New York, NY, USA: ACM, 2006. p. 58. ISBN1-59593-428-6.

MAUERER, W. Professional Linux Kernel Architecture. Birmingham, UK, UK:Wrox Press Ltd., 2008. ISBN 0470343435, 9780470343432.

MOTTA, R.; NIENABER, W.; JENKINS, J. Gnutella: integrating performanceand security in fully decentralized p2p models. In: ACM-SE 46: Proceedings of the46th Annual Southeast Regional Conference on XX. New York, NY, USA: ACM,2008. p. 272–277. ISBN 978-1-60558-105-7.

MUTHITACHAROEN, A. et al. Ivy: a read/write peer-to-peer file system.SIGOPS Oper. Syst. Rev., ACM, New York, NY, USA, v. 36, n. SI, p. 31–44, 2002.ISSN 0163-5980.

NGIWLAY, W.; INTANAGONWIWAT, C.; TENG-AMNUAY, Y. Bittorrentpeer identification based on behaviors of a choke algorithm. In: AINTEC ’08:Proceedings of the 4th Asian Conference on Internet Engineering. New York, NY,USA: ACM, 2008. p. 65–74. ISBN 978-1-60558-127-9.

PARIS, E. fanotify: the fscking all notification system. 2009. Disponível em<http://lwn.net/Articles/339253/>. Documentação escrita pelo desenvolvedor dosistema. Acesso em ago. 2010.

PARVEZ, N. et al. Analysis of bittorrent-like protocols for on-demand stored mediastreaming. In: SIGMETRICS ’08: Proceedings of the 2008 ACM SIGMETRICSinternational conference on Measurement and modeling of computer systems. NewYork, NY, USA: ACM, 2008. p. 301–312. ISBN 978-1-60558-005-0.

78

PAWLOWSKI, B. et al. Nfs version 3 - design and implementation. In: InProceedings of the Summer USENIX Conference. [S.l.: s.n.], 1994. p. 137–152.

PAWLOWSKI, B. et al. The nfs version 4 protocol. In: In Proceedings of the 2ndInternational System Administration and Networking Conference (SANE 2000.[S.l.: s.n.], 2000.

PORTMANN, M. et al. The cost of peer discovery and searching in the gnutellapeer-to-peer file sharing protocol. In: ICON ’01: Proceedings of the 9th IEEEInternational Conference on Networks. Washington, DC, USA: IEEE ComputerSociety, 2001. p. 263. ISBN 0-7695-1186-4.

RIVEST, R. RFC 1321 - The MD5 Message-Digest Algorithm. 1992. Disponívelem <http://www.rfc-archive.org/getrfc.php?rfc=1321>. Acesso em set. 2010.

ROCHA, E. S.; MARCON, D. S.; ÁVILA, R. B. Comunicação peer-to-peeraplicado a redes locais. In: Escola Regional de Redes de Computadores - Fórum dePós-Graduação. [S.l.: s.n.], 2010.

SALMON, R.; TRAN, J.; ABHARI, A. Simulating a file sharing system basedon bittorrent. In: SpringSim ’08: Proceedings of the 2008 Spring simulationmulticonference. San Diego, CA, USA: Society for Computer SimulationInternational, 2008. p. 1–5. ISBN 1-56555-319-5.

SALZMAN, P. J. The Linux Kernel Module Programming Guide. Paramount, CA:CreateSpace, 2009. ISBN 1441418865, 9781441418869.

SAROIU, S.; GUMMADI, P. K.; GRIBBLE, S. D. A measurement study ofpeer-to-peer file sharing systems. In: . [S.l.: s.n.], 2002.

SATYANARAYANAN, M. Scalable, secure, and highly available distributed fileaccess. Computer, IEEE Computer Society Press, Los Alamitos, CA, USA, v. 23,n. 5, p. 9–18, 20–21, 1990. ISSN 0018-9162.

SATYANARAYANAN, M. The evolution of coda. ACM Trans. Comput. Syst.,ACM, New York, NY, USA, v. 20, n. 2, p. 85–124, 2002. ISSN 0734-2071.

SHEPLER, S. et al. RFC 3530 - Network File System (NFS) version 4 Protocol.2003. Disponível em <http://www.rfc-archive.org/getrfc.php?rfc=3530>. Acessoem abr. 2010.

SHERMAN, A.; NIEH, J.; STEIN, C. Fairtorrent: bringing fairness to peer-to-peersystems. In: CoNEXT ’09: Proceedings of the 5th international conference onEmerging networking experiments and technologies. New York, NY, USA: ACM,2009. p. 133–144. ISBN 978-1-60558-636-6.

SILBERSCHATZ, A.; GALVIN, P. B.; GAGNE, G. Operating System Concepts.[S.l.]: Wiley Publishing, 2008. ISBN 0470128720.

STORAGE NETWORKING INDUSTRY ASSOCIATION. CIFS TechnicalReference. 2002. Disponível em <http://www.snia.org/tech_activities/CIFS/CIFS-TR-1p00_FINAL.pdf>. Acesso em jul. 2010.

79

STUTZBACH, D.; REJAIE, R.; SEN, S. Characterizing unstructured overlaytopologies in modern p2p file-sharing systems. IEEE/ACM Trans. Netw., IEEEPress, Piscataway, NJ, USA, v. 16, n. 2, p. 267–280, 2008. ISSN 1063-6692.

SUN MICROSYSTEMS. RFC 1094 - NFS: Network File System ProtocolSpecification. 1989. Disponível em <http://www.rfc-archive.org/getrfc.php?rfc=1094>. Acesso em abr. 2010.

TANENBAUM, A. S. Modern Operating Systems. Upper Saddle River, NJ, USA:Prentice Hall Press, 2007. ISBN 9780136006633.

TANENBAUM, A. S.; STEEN, M. v. Distributed Systems: Principles andParadigms. 2nd. ed. Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 2006. ISBN0132392275.

TRAEGER, A.; THANGAVELU, K.; ZADOK, E. Round-trip privacy with nfsv4.In: StorageSS ’07: Proceedings of the 2007 ACM workshop on Storage security andsurvivability. New York, NY, USA: ACM, 2007. p. 1–6. ISBN 978-1-59593-891-6.

VERNOOĲ, J. R. Samba Developers Guide. 2009. Disponível em <http://samba.org/samba/docs/Samba-Developers-Guide.pdf>. Acesso em jul. 2010.

lp2pfs:umclientevfs...

Documents