Você está na página 1de 0

UNIVERSIDADE FEDERAL DE PERNAMBUCO

CENTRO DE INFORMTICA - CIn


GRADUAO EM CINCIA DA COMPUTAO
2005.1





OS DI S POS I TI VOS MVEI S
E
AS REDES PEER- TO- PEER ( P2 P)


Por
LUCI ANA P EREI RA OLI VEI RA
T r a b a l h o d e Gr a d u a o e m Re d e s d e Co mp u t a d o r e s












Recife
Agosto, 2005





2




UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMTICA - CIn
GRADUAO EM CINCIA DA COMPUTAO
2005.1




LUCIANA PEREIRA OLIVEIRA


Os Di s pos i t i vos Mve i s e As Re de s
Pe e r - To- Pe e r ( P2P)






Este trabalho foi apresentado ao programa de
graduao em Cincia da Computao do Centro de
Informtica da Universidade Federal de Pernambuco
como requisito parcial para obteno do grau de
Bacharel em Cincia da Computao.

Orientador: Djamel Fawzi Hadj Sadok



Recife
Agosto, 2005


Dedicatria

Dedico aos meus pais, a minha irm e a minha av pelo apoio, incentivo, amor e
carinho que recebi em todos os momentos da minha vida.

3

Agradecimentos

Aos meus pais, Vicente e Maria das Graas, minha irm, Ana Lcia e meu cunhado
Tlio por todo amor, carinho, companhia, dedicao e apoio nas horas mais difceis da
minha vida. Obrigada por me ajudarem a no deixar de realizar meus sonhos.

Ao meu namorado, Luis Ricardo, pelo amor, pela companhia e amizade. Tambm
agradeo a sua famlia, em especial, a sua me, Ins, pelo apoio.

Aos professores J udith Kelner e Djamel Sadok por fazer parte do Grupo de Pesquisa em
Redes e Telecomunicaes (GPRT), como tambm pela orientao.

Ao GPRT pela excelente infra-estrutura e o apoio necessrio em termos fsicos para a
realizao deste trabalho.

Ao grupo de trabalho em computao colaborativa (GT-P2P) pela motivao ao estudo
dos assuntos abordados nesta monografia.

A J oseane Fidalgo e a Ramide por permitirem a dedicao exclusiva a este trabalho de
graduao nas ltimas semanas.

Ao professor Carlos Kamienski pela orientao e, principalmente, pelo o
acompanhamento das avaliaes de desempenho.

A Gabriel pela ajuda e reviso desta monografia.
4

Sumrio


Dedicatria....................................................................................................................... 3
Agradecimentos................................................................................................................ 4
Lista de Figuras................................................................................................................ 7
Lista de Tabelas................................................................................................................ 9
Resumo........................................................................................................................... 10
Abstract........................................................................................................................... 11
1 Introduo.................................................................................................................... 12
1.1 Motivao............................................................................................................. 13
1.2 Objetivos............................................................................................................... 14
1.3 Trabalhos Relacionados........................................................................................ 15
1.4 Estrutura da Monografia....................................................................................... 16
2 Restries e Requisitos para P2P-Mvel..................................................................... 18
2.1 Restries Existentes em Redes P2P.................................................................... 18
2.2 Restries dos Dispositivos Mveis..................................................................... 19
2.3 Tecnologia de Acesso........................................................................................... 20
2.3.1 Taxa de Transferncia................................................................................... 23
2.3.2 Estrutura da Rede Celular.............................................................................. 25
2.4 Aspectos Econmicos........................................................................................... 26
2.5 Consideraes Finais............................................................................................ 28
3 Aplicaes................................................................................................................... 29
3.1 Monitorando Equipamento de uma Rede P2P...................................................... 29
3.2 Voz sobre IP em uma Rede Peer-to-Peer ............................................................ 30
3.3 Compartilhamento de Arquivos........................................................................... 30
3.4 Blog...................................................................................................................... 31
3.5 Troca de Mensagens............................................................................................. 31
3.6 J ogos..................................................................................................................... 32
3.7 Ferramenta Educacional com Entretenimento...................................................... 32
3.8 Consideraes Finais............................................................................................ 34
4 Arquiteturas P2P.......................................................................................................... 35
4.1 Arquitetura P2P-Mvel Pura................................................................................ 37
4.1.1 Mobile CHEDAR.......................................................................................... 38
4.1.2 Proem............................................................................................................. 41
4.1.3 Proem X Mobile CHEDAR........................................................................... 43
4.2 Arquitetura P2P-Mvel Hbrida........................................................................... 43
4.2.1 Arquitetura J XTA para Dispositivos Mveis (J XME).................................. 43
4.2.2 Arquitetura X-Peer ........................................................................................ 47
4.2.3 X-Peer x J XTA-J XME.................................................................................. 50
4.3 Arquitetura para Comunicao entre as Redes P2P Pura e Hbrida..................... 51
4.4 Arquitetura P2P-Mvel de Propsito Geral e Especfico..................................... 54
4.4.1 Arquitetura P2P-Mvel de Propsito Geral (PnPAP) ................................... 54
4.4.2 Arquiteturas para Compartilhamento de Arquivos em Dispositivos Mveis57
4.4.2.1 Utilizando Servio MMS............................................................................ 57
4.4.2.2 Utilizando um Peer Intermedirio.............................................................. 59
4.4.2.3 Extenso do eDonkey................................................................................. 61
4.4.2.4 Comparaes entre as Arquiteturas para Compartilhamento de Arquivos. 63
4.5 Consideraes Finais............................................................................................ 63
5 Modificaes na Arquitetura X-Peer........................................................................... 65
5

5.1 Proposta e Implementao da Transmisso de Dados com UDP......................... 65
5.2 Proposta de Novos Servios para P2P-Mvel ...................................................... 67
5.3 Proposta LBS (Location Based Services)............................................................. 69
5.4 Contribuies........................................................................................................ 72
6 Avaliao de Desempenho.......................................................................................... 73
6.1 Motivao e Trabalhos Relacionados................................................................... 73
6.2 Objetivo................................................................................................................ 73
6.3 Ambiente de Avaliao........................................................................................ 74
6.3.1 Metodologia de Avaliao............................................................................. 74
6.3.2 Ambiente de Medio.................................................................................... 75
6.4 Parmetros e Mtricas.......................................................................................... 77
6.5 Aplicativo da Avaliao de Desempenho............................................................. 78
6.5.1 Requisito de Coleta da Mtrica RTT............................................................. 79
6.5.2 Requisito de coleta da Mtrica Vazo........................................................... 81
6.6 Cenrios e Resultados........................................................................................... 82
6.6.1 Cenrio 1: C1................................................................................................. 82
6.6.2 Cenrio 2: C2................................................................................................. 86
6.6.3 Cenrio 3: C3................................................................................................. 89
6.6.4 Cenrio 4: C4................................................................................................. 90
6.7 Avaliao dos Resultados..................................................................................... 94
6.8 Dificuldades Encontradas..................................................................................... 96
6.9 Consideraes Finais............................................................................................ 97
7 Concluso.................................................................................................................... 98
7.1 Consideraes Finais............................................................................................ 98
7.2 Principais Contribuies....................................................................................... 99
7.3 Trabalhos Futuros............................................................................................... 100
Referncias................................................................................................................... 102
Apndice A Glossrio................................................................................................ 106






6

Lista de Figuras

Figura 1 Redes GPRS e WLAN utilizando tcnica relay server e SIP........................... 19
Figura 2 Padronizaes da tecnologia de redes sem fio................................................. 21
Figura 3 Percurso de uma mensagem em uma rede ad-hoc........................................... 22
Figura 4 Estrutura simplificada da rede para transporte de pacotes de dados................ 25
Figura 5 Aparelho Firefly da empresa GadgetMadness ................................................ 32
Figura 6 Aparelho i-Care da empresa Sogi ................................................................... 32
Figura 7 Interface grfica baseada em teoria dos conjuntos do software FolkMusic..... 33
Figura 8 Arquitetura hbrida com super-peers................................................................ 37
Figura 9 Topologias de redes Bluetooth......................................................................... 38
Figura 10 Topologia estrela numa rede Mobile CHEDAR............................................ 39
Figura 11 Entrega de dados entre os ns Mobile CHEDAR e CHEDAR...................... 40
Figura 12 Arquitetura do Middleware Proem................................................................ 42
Figura 13 Arquitetura J XTA .......................................................................................... 44
Figura 14 Entidades de uma rede J XTA......................................................................... 45
Figura 15 Arquitetura J XTA com J XME 1.0................................................................. 46
Figura 16 Arquitetura proxyless J XME ......................................................................... 46
Figura 17 Infra-estrutura X-Peer na rede da RNP.......................................................... 47
Figura 18 Arquitetura X-Peer......................................................................................... 48
Figura 19 Tamanho mdio das mensagens referentes aos servios X-Peer................... 50
Figura 20 Arquitetura para comunidade P2P................................................................. 52
Figura 21 Modelagens do Proxy Mobile........................................................................ 53
Figura 22 Multi-hop X Multi-destination....................................................................... 54
Figura 23 Arquitetura PnPAP......................................................................................... 55
Figura 24 Exemplo da comunicao entre o ME e o Motor........................................... 56
Figura 25 Busca e compartilhamento de arquivo MMS................................................. 58
Figura 26 Exemplo de transao MMS.......................................................................... 59
Figura 27 Peer intermedirio.......................................................................................... 60
Figura 28 Viso geral da arquitetura P2P-Mvel ........................................................... 61
Figura 29 Comunicao direta com TCP ...................................................................... 66
Figura 30 Comunicao indireta com TCP ................................................................... 66
Figura 31 Componente refletor na rede X-Peer.............................................................. 67
Figura 32 Modificao da arquitetura X-Peer para atender a mobilidade...................... 68
Figura 33 Modificao na arquitetura X-Peer para atender LBS................................... 71
Figura 34 Uso do servio XLB com GPS...................................................................... 71
Figura 35 Diagrama do ambiente de medio................................................................ 76
Figura 36 Tempo de resposta ou RTT............................................................................ 78
Figura 37 Execuo de uma comunicao indireta........................................................ 79
Figura 38 Execuo de uma comunicao direta........................................................... 79
Figura 39 Diagrama de seqncia simplificado do aplicativo para coletar RTT ........... 80
Figura 40 Diagrama de seqncia simplificado do aplicativo para coletar RTT ........... 81
Figura 41 RTT e Vazo da comunicao direta entre peer mveis............................... 83
Figura 42 RTT e Vazo da comunicao indireta entre peer......................................... 84
Figura 43 Comportamento do tempo de resposta com o aumento das mensagens........ 84
Figura 44 Latncia no X-Peer na comunicao peer fixo - peer fixo............................. 85
Figura 45 Descrio do diagrama de seqncia da troca de mensagens DHTDeliver... 86
Figura 46 RTT (ms) e vazo (msg/s) da comunicao direta entre um peer mvel e um
peer fixo.......................................................................................................................... 87
Figura 47 RTT (ms) e vazo (msg/s) da comunicao indireta entre um peer mvel e
7

um peer fixo.................................................................................................................... 88
Figura 48 RTT e vazo na comunicao entre um dispositivo mvel e um desktop..... 88
Figura 49 Comparando os cenrios 2 e 3....................................................................... 90
Figura 50 Comparando o tempo de resposta UDP e TCP.............................................. 91
Figura 51 Comparao do RTT usando apenas J 2ME e Mdulo P2P........................... 92
Figura 52 Comparao do RTT usando apenas J 2ME e Mdulo P2P no emulador...... 93
Figura 53 RTT X gnero do jogo X rede sem fio.......................................................... 95
Figura 54 Problema com coletas automatizadas............................................................ 96


8

Lista de Tabelas

Tabela 1 Taxa de transferncia das tecnologias de acesso............................................. 23
Tabela 2 Canais utilizados no padro 802.16................................................................. 24
Tabela 3 Estimativa de custos de contedo download................................................... 27
Tabela 4 J ogadores X Arquitetura.................................................................................. 32
Tabela 5 Resumo das caractersticas de redes Cliente/Servidor e Peer-to-Peer............. 36
Tabela 6 Parmetros para o cenrio 1............................................................................. 82
Tabela 7 Parmetros para o cenrio 2............................................................................. 87
Tabela 8 Parmetros para o cenrio 3............................................................................. 91
Tabela 9 RTT em diferentes jogos................................................................................. 94

9

Resumo

Os dispositivos mveis e as redes peer-to-peer (P2P), se analisados separadamente,
apresentam um grande crescimento no nmero de usurios. No entanto, existe uma
diversidade de aparelhos com diferentes capacidades e grande variedade de tecnologias
para a comunicao sem fio (Wi-Fi, Wi-Max, Bluetooth, GPRS, UMTS), e a
combinao de aparelhos e interfaces de rede apenas um dos novos desafios para os
ambientes P2P.

Atualmente, existem aplicaes que utilizam a tecnologia Wi-Fi e a arquitetura para
P2P-Mvel. O grupo desenvolvedor do aplicativo Skype, que permite a transmisso de
voz utilizando VoIP (Voice over Internet Protocol) e a arquitetura P2P, est
disponibilizando uma verso para Pocket PC, denominada PocketSkype. O grupo eMule
tambm est explorando a arquitetura P2P com dispositivos mveis que resultou,
inicialmente, no lanamento de uma aplicao para celulares denominada MobileMule.
Este aplicativo permite aos usurios terem um maior controle do compartilhamento de
arquivos atravs dos celulares, principalmente, quando no estiverem prximos de seus
desktops que utilizam o eMule para compartilhar arquivos.

Outro fato que est ocorrendo no campo de redes P2P a criao de novo protocolos e
modificao de antigos protocolos para atender aos peers mveis. A arquitetura P2P
hbrida possibilita a existncia de dois tipos de peers (peers e super-peers), existindo
uma diferena de hierarquia em que os super-peers possuem o nvel superior aos peers.
J XTA um exemplo deste tipo de arquitetura P2P. O grupo que desenvolveu essa
arquitetura criou uma verso dos protocolos do framework J XTA para atender
especificamente dispositivos mveis, denominada J XME.

Um exemplo de modificao de protocolos para atender aos peer mveis foi realizado
pelo grupo de trabalho em computao colaborativa ( GT-P2P ) que desenvolveu a
infra-estrutura X-Peer. Em 2004, o grupo identificou que o tempo para realizar o
processamento dos protocolos definidos em XML (Extensible Markup Language) era
muito elevado. Por isso, em 2005, o grupo decidiu que todos os protocolos utilizados no
X-Peer fossem substitudos por protocolos no formato binrio. Esses protocolos so
menores e requerem pouco processamento, o que desejado pelas aplicaes P2P em
aparelhos mveis, tais como handhelds.

Desse modo, este trabalho descreve o estudo realizado sobre P2P-Mvel, considerando
os novos desafios aos ambientes P2P, as aplicaes e as arquiteturas. Em especial, a
arquitetura X-Peer foi avaliada, o que resultou na apresentao de propostas para que
essa arquitetura atenda melhor aos dispositivos mveis. Para realizar esta avaliao,
uma aplicao foi desenvolvida com o objetivo de coletar amostras do tempo de
resposta e vazo na camada de aplicao, de forma a permitir o melhor estudo dos peers
utilizando uma rede X-Peer em ambiente real.


Palavras-Chave: P2P-Mvel, peer-to-peer, peers mveis e X-Peer.


10

Abstract

The mobile devices and the peer-to-peer (P2P) networks, if analyzed separately,
presents a great growth in their number of users. However, there is a wide diversity of
devices, with different capacities and great variety of technologies for wireless
communications (Wi-Fi, Wi-Max, Bluetooth, GPRS, UMTS), and the combination of
devices and networks interfaces is only one of the new challenges for P2P
environments.

Nowadays, there are several applications that use Wi-Fi technology and Mobile-P2P
architecture. The developer group of Skype provides internet telephony service that is
based on the P2P principle and already launched a version of their product for Pocket
PC, named PocketSkype. The eMule group is also exploring P2P architecture for
mobile devices and launched an application called MobileMule. This application allows
the users to have a bigger control of their shared files through cell phones, mainly when
they are not close to their desktops, that use emule to share files.

Another fact that is occurring in the field of P2P networks, is the creation and
modification of protocols to assist the mobile peers. Hybrid P2P architecture allows the
existence of two types of peers (super-peers and peers), thus existing a hierarchy
difference where the super-peers are in a superior level compared to the peers. J XTA is
an example of this type of P2P architecture. The group that developed this architecture
created a different version of the J XTA framework protocols to assist mobile devices,
called J XME.

An example of protocol modification to assist mobile peers was developed by the work
group in collaborative computation - GTP2P that developed the X-Peer infrastructure.
In 2004, the group identified that the time to accomplish the processing of protocols
defined in XML (Extensible Markup Language) was very high. Therefore, in 2005, the
group decided that all the protocols used in the X-Peer would be replaced by protocols
in the binary format. Since those protocols are smaller and require less processing time,
they are exactly what is desired by P2P applications in mobile devices, such as
handhelds.

This work describes the study carried through on the Mobile-P2P, considering the new
challenges to P2P environments, the applications and the architectures. In especial, the
X-Peer architecture was evaluated, what resulted in modification proposals so that this
architecture assists better the mobile devices. To accomplish the evaluation work, an
application was developed with the objective of collecting samples of response time and
dataflow in the application layer, to allow the study of peers using a X-Peer network in
a real environment.


Key Works: Mobile-P2P, peer-to-peer, mobile peers and X-Peer.



11

1 Introduo

Na literatura existem diversas definies para peer-to-peer (P2P). Algumas dessas
definies restringem o conceito, que classifica um sistema ou aplicao, como P2P ou
cliente/servidor. As duas definies a seguir, encontradas na literatura, exemplificam o
caso, em que o conceito P2P restrito.

1. Stoica e Balakrishnan [1] definiram P2P como: Sistemas e aplicaes peer-to-
peer so sistemas distribudos sem qualquer forma de controle centralizado ou
hierarquia organizacional, onde o software que est sendo executado em cada
n equivalente em funcionalidade;

2. Rowstron e Druschel [2] tambm reforam essa restrio com a seguinte frase:
Sistemas peer-to-peer podem ser caracterizados como sistemas distribudos
nos quais todos os ns possuem capacidades e responsabilidades idnticas e
toda comunicao simtrica.

No entanto, variaes sobre as definies anteriores surgiram para contemplar casos em
que existem compartilhamentos e comunicao direta entre equipamentos da rede, mas
tambm h uma certa diferenciao entre os participantes da rede, sendo possvel haver
alguma organizao hierrquica na rede, em que os ns possuem autonomia parcial ou
total em relao a um servidor centralizado.

A vantagem das redes peer-to-peer quanto distribuio que oferece:

- Escalabilidade, porque no h gargalos para o crescimento em relao
capacidade do servidor. Em um sistema cliente/servidor, os servidores so os
nicos responsveis por toda a carga do sistema. Em determinados horrios,
estes servidores podem ficar sobrecarregados e o sistema como um todo tende a
oferecer um servio de baixa qualidade. Em um sistema P2P, quando o nmero
de clientes na rede aumenta, cresce tambm o nmero de servidores, uma vez
que todos podem atuar como clientes e servidores, aumentando na mesma
proporo quantidade de recursos compartilhados.

- Robustez, porque no h um ponto nico de falha. Em um sistema
cliente/servidor, se ocorrer a impossibilidade de acessar um servidor, todos os
clientes necessitaram aguardar o restabelecimento do servidor, para ento
continuar com suas atividades. Em um sistema P2P, um outro peer poder
disponibilizar os mesmo servios do peer que est fora da rede.

- Flexibilidade, porque pode ser feita uma auto-configurao ou configurao
dinmica. Um exemplo a rede automaticamente identificar um novo peer e
realizar a redistribuio do contedo da rede.

Neste contexto, os dispositivos mveis tambm podem representar um peer na rede
P2P, denominado peer mvel ou n mvel. Este caracterizado, principalmente, pela
mobilidade proporcionada pela rede sem fio, e pelas diversas restries que sero
detalhadas no segundo captulo desta monografia.

12

As redes peer-to-peer (P2P) e os dispositivos mveis que acessam redes sem fio, se
analisados separadamente, apresentam um grande crescimento no nmero de usurios.
Sabe-se que a tecnologia P2P tem crescido exponencialmente desde o surgimento do
Napster [3]. Estatsticas apresentam que o trfego referente aos aplicativos KaZaa [4] e
Gnutella [5] tem sido da ordem de 40% a 60% de todo o trfego da Internet [6]. Em
relao somente a redes Wi-Fi
1
, o nmero de usurio, em 2003, era de 9,3 milhes e
estudos apresentados no congresso Telexpo 2004 prevem que em 2008 sero cerca de
707 milhes de usurios, com uma taxa de crescimento anual de 127%[7]. Portanto,
qual a viabilidade do uso de dispositivos mveis em redes peer-to-peer? A edio
especial da veja de julho de 2005 [8] publicou: A empresa de anlise e pesquisa
britnica Datamonitor prev que, at 2009, pelo menos 13 milhes de consumidores
europeus usaro a transmisso wireless para compartilhar arquivos de udio e vdeo....

Nesta viso, em que os dispositivos mveis podero participar das redes P2P, so
realizadas proposta de novas arquiteturas P2P (publicadas em [31], [32] e [36]) e de
modificao de antigas arquiteturas P2P (publicadas em [13], [28], [29], [34], [35] e
[39]) para fornecer um melhor ambiente a esses equipamentos restritos em capacidade
de processamento, de memria entre outros recursos. As redes P2P que permitem a
existncia e participao de peers mveis podem ser denominadas P2P-Mvel.
Portanto, os peers de uma rede P2P-Mvel podem ser apenas aparelhos mveis, ou
aparelhos fixos e mveis. As aplicaes so denominadas aplicaes P2P-Mvel,
quando os aplicativos utilizam o conceito P2P (realiza, em algum momento, a
comunicao direta entre peers) e so executadas em um dispositivo mvel.


1.1 Motivao

Como foi identificado na introduo deste captulo, existe um grande crescimento do
nmero de usurio de rede sem fio, no entanto Wi-Fi apenas um elemento de um
grande conjunto formado por padres para comunicao sem fio. Outros padres que
fazem parte desse conjunto so: Bluetooth
2
, UWB
3
, ZigBee
4
, Wi-Max
5
, assim como os
padres da telefonia celular, tais como GPRS (General Packet Radio Service) e UMTS
(Universal Mobile Telecommunications System).


1
Wi-Fi um nome comercial para um padro de rede Wireless chamado de 802.11b. A velocidade e
alcance so tipicamente de 12Mbps e 100m respectivamente.
2
Bluetooth Apresenta conexo via rdio e freqncia com alcance de 10m e capacidade de transmitir
720 Kbps.
3
UWB (Ultra Wide Band) Esta uma tecnologia de transmisso de dados sem fio que ao invs de
operarem numa freqncia fixa, os transmissores UWB utilizam um nmero quase infinito de freqncias
entre 0 e 60 GHz, sem permanecer em uma nica freqncia por mais do que algumas fraes de
segundo. Apenas as duas partes envolvidas conhecem o padro de freqncias utilizado, o que ajuda a
manter a segurana dos dados. Tem a capacidade de transmitir dados at 500Kbps, mas com um alcance
de apenas 10 metros.
4
ZigBee Tem como proposta tornar-se padro wireless de baixo consumo e curto alcance para
monitorao e automao de aplicaes industriais, comerciais ou urbanas, sua taxa de transferncia de
200Kbps e tem o alcance de 75m.
5
Wi-Max (Worldwide Interoperability for Microwave Access) o padro 802.16 tambm conhecido
como Air Interface for Fixed Broadband Wireless Access Systems com alcance de at 40Km,
possibilitando taxas de transferncia de at 75Mbps.
13

A combinao dessas interfaces de comunicao, e das diversas capacidades e restries
dos dispositivos mveis gera novos desafios para o desenvolvimento de arquiteturas e
aplicaes peer-to-peer.

Esses novos peers so caracterizados pela grande mudana de localizao e modificao
de estado (online ou offline). Diante dessa descrio, possvel identificar um novo tipo
de dado localizao geogrfica dos usurios que poder ser interessante para uma
comunidade P2P.

A publicao e compartilhamento da posio geogrfica pelos peers mveis e fixos,
assim como as buscas de informaes relacionadas com a localizao, proporcionam
novos servios e aplicaes. Um exemplo o cenrio em que turistas de uma excurso
formam uma rede P2P-Mvel. Os peers mveis, que representam os turistas, podero
no s compartilhar as fotos, msicas e agenda da viagem, mas tambm localizaes de
pontos tursticos e localizaes de cada turista, durante a viagem. Esse
compartilhamento facilitar o inter-relacionamento de todo o grupo, provavelmente,
evitando atrasos causados por desencontros. Desse modo, P2P-Mvel pode
proporcionar ambientes mais dinmicos aos usurios de dispositivos mveis.

Para viabilizar o atendimento aos peers mveis, novas arquiteturas e protocolos esto
sendo propostos, assim como antigas arquiteturas e protocolos P2P esto sendo
modificados. Um exemplo de modificao de protocolos, para levar em considerao os
peer mveis, foi realizado pelo grupo de trabalho em computao colaborativa (GT-
P2P), que desenvolveu a infra-estrutura X-Peer. No final de 2004, foi identificado que o
tempo, para realizar o processamento dos protocolos do X-Peer definidos em XML
(Extensible Markup Language), era muito elevado. Por isso, em janeiro de 2005, o
grupo decidiu que todos os protocolos utilizados no X-Peer seriam substitudos por
protocolos no formato binrio. Essa modificao proporcionou protocolos menores e
um menor processamento, o que requerido e desejado por aplicaes P2P-Mvel em
aparelhos com restries de recursos, tais como handhelds.


1.2 Objetivos

A participao no grupo de trabalho em computao colaborativa resultou no
desenvolvimento de mdulos que facilitam a implementao de aplicaes P2P para a
arquitetura X-Peer. Assim como, o desenvolvimento de aplicaes para equipamentos
com baixas restries (por exemplo, desktops e notebooks) e para dispositivos com altas
restries (por exemplo, handhelds e PocketPCs).

O conhecimento obtido nesse projeto motivou no estudo aprofundado dos desafios que
os ambientes sem fio trazem para as aplicaes P2P, assim como a pesquisa de outras
arquiteturas P2P que permitam a participao de peers mveis.

Dessa forma, considerando-se redes peer-to-peer e dispositivos mveis, o objetivo
principal deste trabalho de graduao estudar aspectos relacionados s redes P2P-
Mvel, propor modificaes na arquitetura X-Peer para que ela oferea um melhor
ambiente aos dispositivos mveis, assim como realizar uma avaliao de desempenho
da atual arquitetura X-Peer, por meio de medies em ambiente real. Desse modo,
14

verificar a viabilidade de aplicaes P2P-Mvel. Para isso, os objetivos especficos
deste trabalho so descritos abaixo:

1 Compreender problemas e requisitos dos dispositivos mveis para a participao de
uma rede P2P-Mvel.

2 Identificar as aplicaes existentes para dispositivos mveis.

3 Identificar arquiteturas P2P que permitem a participao de peers mveis, e em
seguida realizar comparaes.

4 Obter maior conhecimento sobre a arquitetura X-Peer para descrever uma proposta
de modificao.

5 Desenvolver uma aplicao utilizando o X-Peer, para ser utilizada na avaliao de
desempenho. Esta aplicao tem como objetivo permitir a realizao de coletas para
as medies da avaliao.

6 Realizar avaliao de desempenho com a finalidade de verificar a viabilidade de
aplicaes P2P-Mvel, utilizando a arquitetura X-Peer.


1.3 Trabalhos Relacionados

P2P-Mvel um assunto recente (a referncia mais antiga de 2001), por isso no
foram encontrados trabalhos que descrevessem um levantamento bibliogrfico de
aspectos dessas redes P2P. Portanto, sero apresentados os trabalhos relacionados para
cada assunto abordado nesta monografia, exceto ao assunto de identificao de
problemas e requisitos dos dispositivos mveis, porque os trabalhos relacionados esto
em quase todas as referncias neste documento.

Um dos assuntos abordados nesta monografia a identificao de aplicaes em que os
equipamentos mveis utilizam uma rede P2P e aplicaes P2P-Mvel. Para isso, so
utilizadas as seguintes pesquisas. Em [16] e [14] os autores apresentam aplicaes que
so P2P-Mvel, assim como aplicaes que no so P2P-Mvel, mas que utiliza uma
rede P2P. O artigo, em [21], descreve uma breve comparao de arquitetura P2P versus
nmero de jogadores, assim como descreve aspectos relacionados com jogos vrios
usurios utilizando dispositivos mveis. Em [24], Wiberg inova com a proposta de uma
aplicao educativa P2P-Mvel. Esses foram os trabalhos mais relevantes em relao
descrio de aplicaes em rede P2P com dispositivos mveis.

Em relao a arquiteturas, um outro conjunto de pesquisas e trabalhos correlacionados
ser apresentado. Em primeiro lugar esta pesquisa se baseia em [27], esta referncia
descreve a arquitetura X-Peer que possui um framework semelhante ao de J XTA. Os
documentos [34] e [35] apresentam J XTA e sua extenso para P2P-Mvel. Em [28] e
[29], a arquitetura CHEDAR e sua extenso so apresentadas. CHEDAR tambm se
inspira em conceitos e mecanismos para fornecer uma arquitetura P2P, no entanto
classificada como uma arquitetura diferente das duas anteriores. Em [31] e [32], outra
arquitetura semelhante a extenso de CHEDAR, denominada Proem, apresentada. Em
[36] descrita uma proposta para que possa existir a comunicao de peers que utilizam
15

as arquiteturas hbridas (J XTA e X-Peer) e puras (CHEDAR e Proem). Em [13] e [39],
a extenso de uma arquitetura especfica para compartilhamento de arquivos (eDonkey)
apresentada utilizando conceitos caching e crawler. Diferente desta ltima, em [9],
proposta uma arquitetura genrica para o desenvolvimento de aplicaes P2P, em que
abstrai o tipo da interface de comunicao e do protocolo P2P e P2P-Mvel.

Alm dos documentos enumerados anteriormente, outros trabalhos relevantes foram
utilizados para descrever a proposta de modificao da arquitetura X-Peer. A pesquisa
em [38] aborda uma tcnica para permitir a comunicao direta utilizando UDP, mesmo
quando os peer esto sob NAT. Esta foi a principal referncia para no s propor, mas
tambm implementar um componente que facilita a implementao de aplicaes P2P e
P2P-Mvel, mesmo sob NAT. Em [22], descrito um trabalho sobre LBS (Location
Based Services), que contribui na proposta para permitir que exista este servio em uma
rede X-Peer.

Foram encontradas poucas pesquisas sobre avaliao de desempenho de arquiteturas
P2P-Mvel, por isso apenas as seguintes referncias foram utilizadas. Em [13] e [39],
apresentado um modelo de simulao para avaliar a proposta de modificao da
arquitetura eDonkey. A referncia [13] analisa apenas as estratgias de caching para o
peer caching. Em [39], so avaliados o peer crawler e as modificaes no servidor de
ndices. O artigo [15] outra referncia que avalia a questo de aplicaes de
compartilhamento de arquivos utilizando dispositivos moveis. Esse trabalho realizou
uma medio por meio de um software para verificar a viabilidade de compartilhamento
de arquivos em dispositivos mveis. Pode-se perceber que poucos artigos (apenas [13],
[15] e [39]) foram publicados em relao avaliao de desempenho no ambiente P2P-
Mvel. Alm disso, esses trabalhos focam principalmente na analise da viabilidade de
aplicaes de compartilhamento de arquivos. Portanto, a avaliao realizada neste
trabalho de graduao tem como objetivo geral contribuir na avaliao de uma
arquitetura diferente da eDonkey, assim como verificar a viabilidade da utilizao de
outras aplicaes P2P em ambiente mveis sem fio. O diferencial deste trabalho a
realizao da medio de P2P-Mvel com tecnologia 802.11 e o estudo da viabilidade
de aplicaes P2P utilizando a arquitetura X-Peer que permite o desenvolvimento de
diversas aplicaes, ou seja, no restringe a avaliao a aplicaes de compartilhamento
de arquivos.


1.4 Estrutura da Monografia

O documento composto por sete captulos, cada um apresentado da seguinte forma:

Captulo 1 Apresenta uma introduo a respeito de conceitos sobre redes peer-to-peer,
peers mveis, aplicaes e redes P2P-Mvel. Descreve a motivao para o estudo de
P2P-Mvel e para a elaborao deste trabalho de graduao, assim como o objetivo da
monografia e trabalhos relacionados a este documento.

Captulo 2 Identifica as restries dos aparelhos mveis e os requisitos para
viabilidade de arquiteturas e aplicaes P2P-Mvel.

Captulo 3 Apresenta aplicaes que utilizam uma rede P2P e aplicaes P2P-Mvel
para diapositivos mveis.
16


Capitulo 4 Apresenta arquiteturas para P2P-Mvel e finaliza comparando as
arquiteturas citadas neste captulo.

Captulo 5 Descreve a proposta de modificao da arquitetura X-Peer. Esta arquitetura
apresentada no captulo 4.

Captulo 6 Descreve a aplicao que foi implementada para realizar a medio, assim
como a avaliao de desempenho, seus resultados e dificuldades encontradas. O
captulo finaliza com concluses obtidas na avaliao.

Captulo 7 Apresenta as concluses sobre o trabalho, enfatizando as principais
contribuies e sugestes para trabalhos futuros.
17

2 Restries e Requisitos para P2P-Mvel

O crescimento do uso de dispositivos mveis smartphone e PDAs
6
trouxe novos
desafios para a construo de aplicaes P2P-Mveis [9]. Por isso, o uso de aplicaes
peer-to-peer em ambientes mveis requer a compreenso no s dos problemas
encontrados em redes P2P, mas tambm das restries intrnsecas dos dispositivos
mveis, das redes sem fio e aspectos econmicos. Esses tpicos sero abordados nas
sees a seguir.


2.1 Restries Existentes em Redes P2P

Um das dificuldades existentes em redes P2P, independentes de a rede ser fixa ou
mvel, a questo de mquinas sob Network Address Translation (NAT) e firewalls7
que esto cada dia mais comuns, mas restringido a alcanabilidade entre os
computadores. Um firewall normalmente bloqueia conexes Transmission Control
Protocol (TCP) provenientes de computadores externos, impedindo ento que os peers
externos se conectem ao computador protegido.

Os dispositivos sob NAT, por sua vez, no possuem um endereo IP (Internet Protocol)
globalmente rotevel, ou seja, o host no encontrado fora do domnio, sendo
denominado IP invlido ou privado. Estes hosts ficam em redes denominadas privadas
e, para cada rede dessas, h apenas um endereo pblico que compartilhado pelos
outros hosts contidos na rede, ou seja, o NAT fornece atribuio de endereo dinmica
aos dispositivos dentro do NAT, mas esses endereos no so endereos vlidos
publicamente na Internet. Qualquer host, dentro de uma NAT, pode fazer conexes para
fora (outgoing), mas conexes de fora para NAT (conexes incoming) apenas so
aceitas, se a conexo estiver estabelecida entre os hosts.

Para solucionar esses problemas, existem tcnicas que, entretanto prejudicam o tempo
de resposta. Uma possvel tcnica para solucionar problemas com NAT em P2P-Mvel
o uso de um refletor central (relay server) com o protocolo SIP (Session Iniciation
Protocol) [10]e [12]. Essa ltima tcnica pode ser observada na Figura 1, que apresenta
celulares de uma rede GPRS se comunicando com notebooks de uma rede Wireless
Local Area Networks (WLAN). Nestes cenrios, os celulares se comportam como
mquina sob NAT, porque mesmo no possuindo IP na tecnologia 2/2,5G, eles podem
obter um identificador por meio do Gateway GPRS Support Node (GGSN). A estrutura
de rede celular e seus problemas esto detalhados na seo 2.3.2.


6
PDA - Personal Digital Assistant, termo que designa pequenos aparelhos de mo, ou palm tops, com
funcionalidade de computador. Alguns lanamentos incorporam celulares - e estes a funcionalidade de
um PDA.
7
Firewall Software para gerenciamento de entrada e sada de informaes pela rede.
18


Fonte: referncia [10]
Figura 1 Redes GPRS e WLAN utilizando tcnica relay server e SIP

Outra restrio, que no particular para P2P-Mvel, a interoperabilidade entre os
protocolos P2P existentes. Atualmente, existe uma grande quantidade de protocolos e
mensagens P2P disponveis, portanto um requisito desejvel, no s para a comunicao
P2P entre os dispositivos mveis, a interoperabilidade entre os protocolos e
mensagens P2P existentes. Os protocolos J XTA
8
e J XME
9
so interoperveis, mas
J XTA no nativamente interopervel com outros protocolos P2P. Ao contrrio desses,
os protocolos J abber e SIP so facilmente interoperveis com outros protocolos e
mensagens P2P, devido estrutura modular e a disponibilidade de plugins [9].

Um dos problemas na interoperabilidade entre os protocolos P2P a questo do
endereamento. Basicamente todo protocolo P2P tem seu prprio mtodo de nomear e
enderear os peers, por isso existe a necessidade de traduo de endereos [9].


2.2 Restries dos Dispositivos Mveis

Os dispositivos mveis, quando comparados com os computadores desktops, possuem
vrias restries de recursos. A memria, a capacidade de processamento e o tempo de
vida das baterias so limitados; as interfaces areas so relativamente estreitas e caras;
existe tambm uma alta variao da presena ou desconexo (online-offline) do
dispositivo na rede. Porm, a evoluo das tecnologias de redes e dos dispositivos
mveis diminui essas limitaes, e deste modo surgiu a possibilidade de usar aplicaes
P2P tambm em dispositivos mveis [13]e [9].

Apesar das limitaes, a capacidade de armazenamento em memria est aumentando
continuamente. Cartes de memria com capacidade de at 4GB
10
, atualmente esto
disponveis no mercado. Isso deixa claro que o tamanho de memria no um

8
J XTA: plataforma para desenvolvimento de aplicaes P2P. Maiores detalhes na seo de arquiteturas.
9
J XME: extenso de J XTA que permite o desenvolvimento de aplicaes P2P para dispositivos mveis.
Maiores detalhes na seo de arquiteturas.
10
Cartes de memria com capacidade de 4GB podem ser encontrados venda no link:
http://froogle.google.com/froogle?q=MemoryStick+PRO+de+4+GB+%24&hl=en&lr=&sa=N&tab=ff&o
i=froogler
19

empecilho hoje em dia. Entretanto, vale a pena lembrar que a maioria dos celulares
possui somente um pequeno chip de memria embutido.

O poder de processamento tambm est crescendo. Os processadores podem manipular
com as vrias larguras de banda no acesso sem fio e realizar processamentos que
permitem ao usurio utilizar vdeo conferncia e jogos cheios de interaes [14].

O tempo de vida das baterias tambm cresce, mas em um ritmo menor que os dois itens
anteriores, por isso continuar a ser o grande gargalo da tecnologia dos dispositivos
mveis. Conseqentemente, os usurios desses equipamentos mveis continuaro a
estar menos online, se comparados aos dispositivos no mveis, em que a maioria das
aplicaes P2P roda hoje em dia. A reduo do tempo online dos peers afeta
extremamente o tempo de download, o que compromete a utilizao de aplicaes de
compartilhamento de arquivos em redes P2P-Mveis [13]. J untamente com a
capacidade de bateria, as limitaes da potncia de transmisso fazem com que a largura
de banda de uplink
11
seja significativamente mais cara que a de downlink
12
.

A possibilidade de utilizar aplicaes que permitem aos usurios uma grande interao
prometida pelas operadoras da 3G, no entanto, essas aplicaes requerem um alto gasto
da bateria, ou seja, o tempo disponvel para utilizar os prometidos servios da 3G ser
menor do que usar os servios da 2G [14].

A escolha da linguagem ou API (Application Programming Interface) para
programao de aplicaes para dispositivos mveis tambm pode ser considerada
como um obstculo, porque ela pode apresentar restries de acesso a certos recursos.
Um exemplo a API J 2ME (Java 2 Micro Edition) CLDC/MIDP
13
que no permiti um
componente externo acessar o sistema de arquivo dos celulares. Porm, esta preveno
criada pelas aplicaes MIDP pode no permitir a transferncia de arquivos entre os
peers em um sistema de compartilhamento de arquivos. Outro exemplo a API
SuperWaba
14
que no permite a implementao de um aplicativo P2P (cliente/servidor),
uma vez que no disponibiliza a funcionalidade de abrir um socket para escutar o pedido
de abertura de conexes. SuperWaba permite apenas que a aplicao solicite a abertura
de conexes a uma mquina desktop, conseqentemente s possvel desenvolver
aplicaes que se comportem como cliente. Algumas APIs de linguagem de
programao, tal como Symbian C++, fornece quase acesso ilimitado para os recursos
mveis [9].


2.3 Tecnologia de Acesso

As redes sem fio geram uma srie de vantagens, entre elas esto: mobilidade,
flexibilidade e custo. A mobilidade do usurio pode ser muito rpida e freqente. No

11
Uplink: termo tcnico para a transmisso de dados no sentido do usurio para a rede ou provedor de
servio da Internet. Tambm designado por canal de retorno.
12
Downlink: Termo tcnico usado para definir a transmisso de dados na seqncia rede/operadora ou
provedor de servio/Internet ao usurio.
13
CLDC/MIDP - (Connected Limited Device Configuration)/ (Mobile Information Device Profile)
fornecem um ambiente de execuo completo para uma aplicao de J 2ME que tem como alvo os
dispositivos mveis, como celulares, pagers e PDAs.
14
SuperWaba uma plataforma para desenvolvimento de software para aplicaes cujo alvo so os
PDAs. Maiores detalhes em http://www.superwaba.com.br
20

cenrio sem fio, rpida significa que um peer pode se mover vrias vezes durante uma
sesso de comunicao, e freqente significa que existe uma alta probabilidade que
um peer no seja encontrado em uma mesma localizao. A maioria dos protocolos de
descoberta P2P normalmente suporta a rara mobilidade, devido ao fornecimento de um
conjunto de endereos peer para se conectar. No entanto, isto pode se tornar muito
ineficiente se um peer tem de usar a lista de endereos freqentemente [10].

Existem diferentes tipos de redes sem fio que variam em tecnologia e aplicao, sendo
possvel classific-las em quatro tipos: WPANs (Wireless Personal Area Network),
WLANs (Wireless Local Area Netowrk), WMANs (Wireless Metropolitan Area
Network) e WWANs (Wireless Wide Area Network WWAN). A Figura 2 apresenta estes
tipos de redes que sero exemplificadas nos prximos pargrafos [44] e [45].


Fonte: referncia [44]
Figura 2 Padronizaes da tecnologia de redes sem fio

Bluetooth um exemplo de tecnologia de redes WPANs as quais cobrem pequenas
distncias e oferecem baixas velocidades, se comparada a outras tecnologias sem fio.

A tecnologia 802.11, tambm conhecida como Wi-Fi, um exemplo de rede WLAN a
qual oferece grande flexibilidade para seus usurios, principalmente os que utilizam
laptops e PDAs. Este tipo de rede define duas formas de comunicao: ponto a ponto
(ad-hoc) ou modo infra-estrutura.

O modo ad-hoc permite que um pequeno grupo de mquinas se comunique diretamente,
sem a necessidade de um Access Point (AP ou Ponto de Acesso) e de uma rede fsica
para conectar as estaes. Neste modo todas as estaes so conectadas diretamente
umas s outras. Outras caractersticas da rede ad-hoc incluem um modo de operao
ponto a ponto distribudo, roteamento multi-hop, e mudanas relativamente freqentes
na concentrao dos ns da rede. A responsabilidade por organizar e controlar a rede
distribuda entre os prprios terminais. Em redes ad-hoc, alguns pares de terminais no
so capazes de se comunicar diretamente entre si, ento alguma forma de re-transmisso
de mensagens, atravs de vrios saltos, necessria, para que estes pacotes sejam
entregues ao seu destino, como pode ser visto na Figura 3.

21


Fonte: referncia [11]
Figura 3 Percurso de uma mensagem em uma rede ad-hoc

No modo de infra-estrutura, a rede possui pontos de acessos fixos que conectam a rede
sem fio rede convencional e estabelecem a comunicao entre os diversos clientes.
Dessa forma, uma rede sem fio tambm pode ser caracterizada pela existncia de ns
fixos (tal como estaes base e pontos de acesso) que servem a uma rea ou a clula
particular. Desse modo, a rede pode ser formada por peers com alta mobilidade e por
peers fixos que possuem localizao fixa [10]e [11].

A rede WMAN se aplica a regies urbanas. A tecnologia 802.16, tambm denominada
Wi-Max est classificada neste tipo de rede que oferece uma cobertura geogrfica
consideravelmente maior que as WLANs, chegando a distncias de at 50 km.

As redes WWAN so redes com grande disperso geogrfica, voltadas para aplicaes
mveis que utilizem telefones celulares e PDAs. Elas apresentam um crescente uso de
conexes de banda larga e servios de comutao de pacote de dados para permitir a
transmisso de e-mails, textos, imagens, som e vdeo, com a mesma qualidade e
velocidade que os dispositivos ligados por fios. As seguintes tecnologias se enquadram
neste tipo de rede: GPRS, EDGE (Enhanced Data rates for Global Evolution) e UMTS.

Neste contexto, atualmente um dispositivo pode ter interfaces conectadas a vrios tipos
de redes (possivelmente ao mesmo tempo, desde que estas redes possam se sobrepor).
Eles tambm podem ter mltiplos endereos IP (multihoming) [10].
Essas tecnologias de acesso diferem em termos de interface area, capacidade de QoS
(Quality of Service), disponibilidade da taxa de transferncia e mecanismos de
transporte na rede [13]. Comparaes e detalhes relacionados a taxas de transferncia
sero apresentados na seo 2.3.1.
As duas principais restries da interface area so: uma largura de banda relativamente
baixa, e alta latncia. Por isso, essencial reduzir o overhead da sinalizao at que seja
possvel registrar uma performance aceitvel. Caso contrrio, as aplicaes com alto
trfego de sinalizao so consideradas muito caras, principalmente, em rede celular.
Uma maneira para otimizar a comunicao P2P seria utilizar estratgias como caching
para reduzir a banda e o trfego de sinalizao. Deve-se diminuir o trfego direto entre
os peers entre os dispositivos mveis, porque na comunicao P2P entre dois
dispositivos mveis, os recursos da interface area utilizada duas vezes, se comparada
com as transmisses entre o dispositivo mvel e a rede fixa [13]e [15]. No entanto,
caching ainda no uma abordagem utilizada em rede P2P.





22

2.3.1 Taxa de Transferncia

A interface area comumente vista como o gargalo em sistemas de comunicao sem
fio, embora o recente desenvolvimento de tecnologias de acesso a dados tem aumentado
a velocidade de 9,6Kbps at 54Mbps. A tpica taxa de transferncia apresentada na
Tabela 1[13]e [14].

Tabela 1 Taxa de transferncia das tecnologias de acesso
Tecnologia de Acesso Taxa de Transferncia
HSCSD Acima de 43,2 Kbps
GPRS 43,2 Kbps
EDGE (4+2) 236KBps DL(downlink)/ 118KBps UL(uplink)
WCDMA Acima de 384Kbps DL/ 128Kbps UL
HSDPA/HSUPA Mximo 13,3Mbps, esperado 3,36Mbps / mximo 5,671Mbps,
esperado 1,46Mbps
WLAN Mximo 112Mbps, tipicamente 11 Mbps.
Fonte: referncia [14]

A taxa mxima de dados nos servios peer-to-peer tem sido calculada levando em
considerao a conexo uplink do contedo disponibilizado e a conexo downlink do
contedo consumido, na qual a menor taxa de transferncia de dados ser a taxa usada
na comunicao entre os peers. Um exemplo ambos os peers estiverem usando
HSDPA e HSUPA como tecnologia de acesso. Neste caso a HSUPA representa o
gargalo da tecnologia de acesso, uma vez que a taxa mxima de dados com que os
mveis podem trocar de HSUPA, ou seja, a taxa de dados de 1,46 Mbps [14].

Uma observao interessante que o trfego de redes P2P tradicionais caracterizado
pelo uso simtrico das tecnologias de acesso, em termos de consumo de banda. Isso
diferente em relao Web que fornece consumo de banda assimtrico por natureza.
Devido ao interesse em diminuir o trfego direto entre peers mveis e evitar um cenrio
como o do pargrafo anterior, deve-se ser analisada a simetria ou assimetria em rede
P2P-Mvel com o uso de caching.

Ainda em relao Tabela 1, pode-se afirmar que o downloading em tempo real pode
ser facilitado apenas no caso da WCDMA e suas extenses HSDPA/HSUPA, no entanto
a tecnologia mais adequada para aplicaes de compartilhamento de arquivos a
WLAN. O trabalho na tecnologia de acesso a dados 3G UTRAN (Terrestrial Radio
Access Network) est avanando em 3GPP (Third Generation Partneship Project). Em
um futuro prximo, uma tecnologia de alta capacidade esperada, denominada Wi-Max
[14].

O padro IEEE 802.16 (Wi-Max) caracterizado pela arquitetura totalmente
centralizada que suporta uma topologia ponto-multiponto em que cada estao base se
comunica com at centenas de estaes estacionarias de usurios. Um ponto diferencial
do padro 802.16 que a interface area foi projetada para transmitir dados ou trfego
multimdia que necessitam de alto suporte de qualidade de servio. O padro 802.16
completamente orientado a conexes a fim de garantir qualidade de servio para
comunicao de telefonia e multimdia, as quais no admitem atrasos.

23

Ao contrrio do IEEE 802.11 (Wi-Fi), o padro IEEE 802.16 utiliza um espectro
varivel, ou seja, emprega um sistema de modulao adaptativa, com a utilizao de trs
esquemas de modulao diferentes: QAM-64, QAM-16 e QPSK. Quando a intensidade
do sinal na banda milimtrica cai com o aumento da distncia da estao base, o
esquema de modulao modificado dependendo da distncia que a estao do
assinante se encontra em relao estao base. Para assinantes prximos usado o
QAM-64, com 6 bits/baud, no caso de assinantes situados a uma distncia mdia
usado o QAM-16 com 4 bits/baud, e para assinantes distantes usado o QPSK com 2
bits/baud. Os esquemas QAM-16 e QPSK permitem um aumento no alcance do sinal,
mas trazem, como conseqncia, a reduo da vazo. Na especificao 802.16, so
definidos canais de 20MHz, 25MHz (tipicamente dos EUA) e 28MHz (tipicamente
europeu), conforme mostrado na Tabela 2 que mostra quanto mais distante estiver o
assinante em relao estao base, mais baixa ser a taxa de dados. [44] e [45].

Tabela 2 Canais utilizados no padro 802.16

Fonte: referncia [44]

Apesar das vantagens prometidas pelo padro 802.16, este possui certa semelhana com
a estrutura da rede celular. Essas duas possui topologia muito centralizada e hierrquica.
Portanto, o padro 802.16 tambm apresenta um forte contraste proposta da maioria
das topologias das redes overlay para sistemas P2P.

Nos sistemas da terceira gerao (3G), como UMTS e a tecnologia HSDPA, o custo da
transmisso de dados sobre a interface area geralmente alto, se comparado com redes
fixas. Isso atualmente verdade para os sistemas da segunda gerao (2G) e 2,5G, como
GSM/GPRS, que teoricamente possuem taxas de transferncia de at 171Kbps e
tipicamente registram taxas de transferncia entre 28 e 50Kbps. Alm disso, a mdia
dos tempos de resposta significativamente mais alta do que em sistemas com fio
devido ao grande overhead dos protocolos e esquemas de correo de erros complexos,
acarretando em uma baixa performance especialmente do TCP [13]. O uso da
transmisso de dados com TCP sofre retransmisses de pacotes devido s perdas de
pacotes [15]. Estes resultados tambm foram confirmados em [13] pela medio do
eDonkey utilizando GPRS.

O GPRS uma tecnologia de comutao de pacotes, nela os canais fsicos podem ser
compartilhados entre diferentes usurios mveis e somente atribudo um canal fsico
quando for necessrio transmitir ou receber dados. Por isso, as taxas de dados usando
GPRS dependem do nmero total da relao voz/dados dos usurios em uma clula e do
suporte a taxa de dados de uma estao mvel (Mobile Station - SM). Na rede
GSM/GPRS, a comutao de circuitos (voz) e a comutao de pacotes dos usurios
existem em paralelo. A combinao dos canais uplink/downlink depende do terminal
mvel e referenciada como uma classe multi-slot. Conseqentemente, eles competem
24

por recursos existentes na interface area. No entanto, a alocao dinmica da largura de
banda baseada em conceder prioridade ao trfego de voz, incluindo a opo de parar
as transmisses de dados em favor a chamadas de voz [15].


2.3.2 Estrutura da Rede Celular

Em geral, a estrutura de um sistema de comunicao mvel projetada de forma
hierrquica. Para GPRS ou UMTS, o trfego do fluxo de dados de cada dispositivo
mvel atravessa a estrutura da rede, da UTRAN da UMTS atravs do domnio da
comutao de pacote e volta [13]. At no caso de dois MSs trocando dados e presentes
na mesma GGSN, o caminho entre os MS e a GGSN sempre percorrido duas vezes
[15].

Na GGSN, os hosts dos dispositivos mveis obtm determinado identificador (chamado
nesta seo 2.3.2 de endereo IP), semelhante ao endereo IP de uma mquina sob
NAT. Ento, a GGSN a interface (ou roteador especial) para a Internet e para os
outros dispositivos mveis no domnio mvel, fazendo tambm o ponto na estrutura da
rede onde todo trfego de pacotes concentrado, visto na Figura 4. Depois de passar no
GGSN, a operadora ir rotear o dado para um celular de acordo com sua especificao
[16]. Semelhante Figura 4, geralmente, existem vrios GGSN na estrutura da rede,
cada um servindo como um gateway para uma grande parte da rede mvel. Esta
hierarquia, topologia muito centralizada, um forte contraste a proposta da maioria das
topologias das redes overlay para sistemas P2P [13].


Fonte: referncia [13]
Figura 4 Estrutura simplificada da rede para transporte de pacotes de dados

Dessa forma, para transferir um dado da Internet para o celular, os dados passam por um
tnel que finalizado no GGSN, gateway GPRS [16]. Uma das principais
conseqncias dessa estrutura o alto tempo de atraso na transferncia de um pacote IP
em um dado caminho entre dois terminais [15].

Essa estrutura possui vrias limitaes para aplicaes P2P. Primeiramente, o GGSN
pode variar durante a transferncia de dados de um terminal mvel em movimento e
principalmente o SGSN (Serving GPRS Support Node). Este ltimo ir varia mais,
porque atendem a uma menor rea de cobertura. Isto causa a mudana do endereo IP
25

dos terminais mveis e como conseqncia no possvel manter conexes ativas
durante movimento. Uma forma de manter conexes ativas, seria implementar esta
caracterstica na rede, por exemplo, com SIP, que cria, modifica e encerra conexes
entre usurios. Com este protocolo a operadora sempre saber qual a localizao atual
(endereo IP) do usurio e ento a conexo ativa poder ser mantida [16].

No ambiente 2/2,5G existe a restrio de que dados e voz no podem ser enviadas
simultaneamente, a menos que o telefone mvel pertena na classe A ou a operadora
adicione novas caractersticas a rede. A primeira opo, telefones mveis na classe A,
exigir da CPU muito processamento. A segunda opo, modificaes na rede, exigir
um alto investimento e atualmente no parecem existir operadoras que concordem em
investir nesta tecnologia [16].

Atualmente as operadoras no permitem que os terminais mveis ajam como terminais
independentes com um endereo IP, elas no do suporte a conexes fim-a-fim e
possuem total controle sobre a rede, incluindo portas TCP/IP, por isso as operadoras s
permitem enviar dados atravs de porta que sempre esto abertas. Dois exemplos so as
operadoras Sonera e Elisa (maiores operadoras da Finlndia) que controlam cada dado
transmitido pelas aplicaes para um celular de acordo com [16].

Alm disso, outros dos mais importantes requisitos operacionais das operadoras de
redes de celulares so manter o controle da cobrana dos servios fornecidos e do
trfego em seu prprio domnio, para evitar o custo, devido ao trfego do interdomnio.
Isto verdade para ambas operadoras, linha fixa e celular. Se o P2P-Mvel integrado
dentro da estrutura de servios, ser, ento, necessrio fornecer meios para controlar e
para debitar. Por outro lado, o mecanismo de controle para um sistema P2P-Mvel deve
ser cuidadosamente selecionado, a fim evitar a total degenerao do sistema
centralizado. Os mecanismos do controle no devem alterar conceitos fundamentais do
P2P, tais como a descentralizao. O modelo do negcio usado para debitar tambm
deve cumprir com aplicaes P2P, um exemplo seria recompensar os usurios que
compartilham. Por outro lado, um sistema P2P-Mvel pode ser beneficiado pela
existncia da infra-estrutura de um sistema de comunicao mvel. Isso porque a rede
fornece conhecimentos de localizao, status online-offline e o contrato de servios dos
usurios de celulares, que pode ser utilizado para sinalizar overhead e o crescimento da
qualidade de servio [13].


2.4 Aspectos Econmicos

Nas redes de celular, a questo financeira ainda um problema para aplicaes P2P,.
Porm existe operadora demonstrando o interesse em oferecer servios peer-to-peer em
ambientes mveis. Um exemplo a operadora coreana SK Telecom que decidiu
oferecer servios P2P baseados em compartilhamento de contedo. Estes permitiro aos
usurios trocar figuras, msicas e vdeo, sem levar em considerao se o contedo
copyright ou no. Dessa forma, nesta seo, sero ressaltados problemas relacionados
ao preo e regulamentao do contedo compartilhado.

Primeiramente, o preo dos servios est entrelaado com a viabilidade dos servios
P2P. De acordo com um simples clculo da Tabela 3, o esquema de preos dos servios
de dados oferecido pelas operadoras 2G/3G no permite a total adoo dos servios de
compartilhamento de arquivos. Na maioria dos casos, o custo da transmisso de dados
26

de um arquivo de msica entre dois celulares mais caro, do que o preo de um servio
de contedo da internet que oferece um arquivo de msica por volta de $1. A menor
taxa, fornecida pela operadora PTC 2G/3G para clientes poloneses, 50% do preo do
contedo anterior, considerando um modelo muito otimista, que provavelmente
adequar consumidores de alta capacidade de consumo [14].

Tabela 3 Estimativa de custos de contedo download
Servio /
Custo do download
em Euro

Custo por Ms

Custo por MB
sobre o limite
Custo de download
de arquivo MP3
(3MB)*
Custo de download
de foto (60kb)*
PTC Poland: Blue
connect GPRS/ EDGE/
3G/ WLAN

Taxa do plano:
23.6e


2GB garantido


0.472e


0.0009e
Three Sweden:
NetConnect
Free
GPRS/3G

87,1e/GB

0.4e

1.742e

0.0033e
Three Sweden:
NetConnect
Flex
GPRS/3G


5.3e
0-25MB
0.9e
26-100MB
0.7e
100MB<0.4e


2.506


0.0048e
VodaFone Swede:
Data
GPRS/3G

61e/150MB

0.7e (mudana
atravs de 1kb)

3.32e

0.0064e
Orange UK: World
Access 400
GPRS/3G

400MB/77.3e

0.73e

1.314e

0.0025e
Orange UK: World
Access Max
GPRS/3G

1000MB/128.9
e

(poltica de uso
justo)

2.19e

0.0042e
* Considerando: usurios baixam 300MB de dados por ms (100MB de dados sobre P2P, 50MB navegando
pela WEB, 50MB e-mail). A taxa de dados P2P calculada considerando a sada de dados (dados
produzidos) e trfego de entrada (contedo consumido). A sinalizao P2P e overhead dos protocolos no
so incluindo.
Fonte: referncia [14]

Uma das vises futuras para esta questo de custo, que provavelmente, as operadoras
podero oferecer pacotes para servios P2P com servios de acesso a dados, em vez
de baixar os preos, a fim de estimular a adoo do servio. Atualmente, de acordo com
a anlise de [14], a maioria das operadoras, consideradas nas Tabela 3, permite livre
acesso para seus servios de contedo atravs de WAP (Wireless Aplications Protocol).

Outro problema a regulamentao. Freqentemente, os celulares possuem limitaes
para enviar uma msica (ring-tone), smbolos e figuras, mas no devido tecnologia. O
motivo para estas limitaes est relacionado a questes econmicas das operadoras,
que esto interessadas em proteger as suas vendas de msicas (ring-tone), smbolos e
figuras. Isso dificulta ou mesmo impossibilita a existncia de compartilhamento de
arquivos em redes mveis [16]. A indstria da msica tambm uma barreira para o
fornecimento de compartilhamento de arquivos em rede de celular, sendo por isso
realizados trabalhos, com a finalidade de proteger a propriedade intelectual. Um dos
resultados de estudos para proteger a propriedade intelectual o DRM (Digital Rights
Management), que um conceito avanado para esta proteo. O DRM permite que os
varejistas possam facilmente determinar as condies da transao, tais como o
pagamento por preo nico, pelo pacote, ou para executar um software ou uma msica.
27



2.5 Consideraes Finais

Neste captulo, foi possvel observar que as dificuldades encontradas em sistemas P2P
tradicionais tambm podem estar presentes em P2P-Mvel. Este fato foi exemplificado
atravs da dificuldade de permitir a interoperabilidade entre protocolos P2P e da
alcanabilidade de peers sob NAT e/ou firewall. Tambm foram identificados desafios
devido escolha da linguagem e a API para implementao de aplicaes P2P-Mvel, e
s restries quanto memria, ao processamento e bateria dos diversos dispositivos
mveis.

A caracterstica de mobilidades dos peers mvel, proporcionada pelas redes sem fio, foi
apresentada como outro desafio relacionado tecnologia de acesso ou estrutura da rede.
Um exemplo a presena da caracterstica de forte centralizao na rede Wi-Max e na
estrutura da rede celular, porque representando o oposto da proposta das topologias das
redes P2P.

Foi identificado que em uma rede P2P-Mvel pode conter uma variedade de tecnologias
de acesso. No entanto, a menor taxa de transferncia determina o valor mximo para
transferncia de dados entre dois peers. Dessa forma, estes dois fatos motivam a
utilizao de assimetria na comunicao P2P por meio de caching.

Por fim, as questes econmicas foram apresentadas como relevantes em relao
viabilidade de P2P-Mvel. Observou-se que os valores cobrados pelas operadoras e a
questo de propriedade intelectual resultam em grandes barreiras para as aplicaes
P2P-Mvel, principalmente na estrutura de rede celular.

No prximo captulo, sero apresentados tipos de aplicaes, exemplificados por meio
de aplicativos, no contexto de redes P2P e dispositivos mveis.

28

3 Aplicaes

Este captulo tem como principal objetivo apresentar aplicaes que utilizam
arquiteturas peer-to-peer e so executadas em dispositivos mveis. O captulo tambm
apresentar aplicativos que podem ser classificados como aplicaes P2P-Mvel,
porque eles utilizam em algum momento a comunicao direta com a inteno de
compartilhar alguma informao.


3.1 Monitorando Equipamento de uma Rede P2P

eMule um aplicativo que utiliza uma rede peer-to-peer para compartilhar arquivos.
Este software deve ser executado em computadores pessoais e age como um P2P-Client.
Isso porque o eMule permite que o usurio possa est conectado diretamente a vrios
outros usurios para baixar e disponibilizar msicas, filmes entre outros recursos. A
partir do crescimento do numero de pessoas que acessam uma rede sem fio com celular,
existiu a motivao de criar uma aplicao (MobileMule
15
) para controlar de maneira
remota uma mquina com eMule executando.

O MobileMule permite que qualquer dispositivo mvel possa obter informaes de
equipamentos participantes de uma rede peer-to-peer. No entanto, esta aplicao no
um P2P-Client, mas sim um exemplo de controle remoto de um computador, onde o
celular o controle.

O MobileMule conecta-se atravs de redes de telecomunicaes, como um cliente para
um servidor eMule em um computador na porta 80. O MobileMule permite que o
usurio solicite o inicio de uma busca, selecione arquivos para realizar download no
computador, checar status dos arquivos que esto sendo baixados, checar propriedade
dos arquivos (nome, tamanho do arquivo e quantidade de fontes, que corresponde ao
nmero de usurios compartilhando este arquivo) e realizar o preview que permite
visualizar o primeiro frame de um arquivo de vdeo. Tambm esto disponveis os
comandos de fechar a aplicao eMule, desligar e ligar o computador remotamente.

Quando se solicita a busca de um arquivo, no mximo, so retornados quinze resultados
ordenados pela maior quantidade de fontes disponveis para o arquivo procurado. O
MobileMule tambm mostra o nmero total de arquivos disponveis para a determinada
busca, no formato de dois dgitos, ou seja, mesmo que existam 500 arquivos, a interface
grfica do software apresentar 99 [16].

Existe uma proposta de modificao da rede eDonkey para permitir a participao de
dispositivos mveis no compartilhamento de arquivos, ou seja, os dispositivos mveis
seriam mais do um controle remoto, eles tambm poderiam agir como peers que
disponibilizam recursos. Essa e outras propostas de arquiteturas para compartilhamento
de arquivos esto na seo 4.4.2.



15
O software MobileMule est disponvel em http://mobil.emule-
project.net/index.php?page=download&language=en
29

3.2 Voz sobre IP em uma Rede Peer-to-Peer

O Skype foi criado por Niklas Zennstrm e por J anus Friis, fundadores do KaZaA. Este
programa, baseado no princpio P2P, fornece servio de telefonia na internet VoIP
(Voice over Internet Protocol). Todas as aplicaes do Skype agem como peers em uma
rede P2P distribuda. O nico elemento central do sistema o servidor de login.

A tecnologia VoIP, permite que a voz seja codificada em tempo real e enviada para um
peer que decodifica o stream de udio e envia para a sada de som. Todos os peers
participantes em uma sesso VoIP tm a capacidade de simultaneamente de enviar e
receber stream de udio em tempo real [18].

Inicialmente o Skype fornecia aplicativos para desktops e em 2005 lanou o primeiro
produto para dispositivo mvel, denominado PocketSkype. Esse primeiro produto
atende a PocketPC com interface area WLAN. A empresa tambm fez parceria com a
Motorola para desenvolver novas aplicaes Skype, a fim de atender aos usurios dos
dispositivos da Motorola e incluir uma variedade de dispositivo com tecnologia de
acesso Bluetooth [14].

Em relao performance do PocketSkype, necessria uma conexo rpida. Em
conexes ADSL de 256kbps, atravs de Wi-Fi ou Ethernet, as denominadas apresentam
pequenos e eventuais cortes, nada que recrimine o uso, mesmo nesta velocidade a
qualidade razovel. Em conexes compartilhadas por ActiveSync via USB ou
Bluetooth, foi possvel estabelecer chamadas, no entanto as conversas apresentavam
muitas interrupes, tornando invivel qualquer dilogo. Via GPRS, no recomendado
o seu uso [17].

XVoice uma outra aplicao que utiliza uma arquitetura P2P e VoIP. Ela foi
desenvolvida pelo grupo de trabalho em computao colaborativa (GTP2P), que tem o
objetivo de fornecer este aplicativo para equipamentos restritos, tais como PocketPC.


3.3 Compartilhamento de Arquivos

A empresa NewBay lanou, em 26 de outubro de 2004, o software FoneShare, a
primeira aplicao para compartilhamento de contedo para dispositivos mveis.
Usando o FoneShare, os usurios podem procurar, comprar, armazenar, compartilhar e
recomendar contedo (tais como ringtones, jogos, msica, papel de parede e trailers)
para outros usurios de dispositivos mveis.

Esta aplicao foi construda conceitualmente atravs de comunidades. O sistema tem o
objetivo de incentivar os usurios mveis, que esto satisfeitos com uma compra, a
recomendar contedos a seus grupos de amigos. Para esta aplicao, tambm existe
critrio de reputao e recompensa em que os usurios do aplicativo FoneShare podem
formar identidades online, comprar contedo e sugerir compras a outros usurios do
FoneShare. A cada usurio so concedidos os pontos de mrito baseados em sua
atividade, e os super-usurios podem ser recompensados com contedos ou descontos
em servios.

30

Dessa forma, a aplicao FoneShare oferece a operadoras de dispositivos mveis o
aumento das vendas de contedo, das vendas do servios de mensagens e reduo nos
custos de marketing [14] e [19].


3.4 Blog

Algumas aplicaes P2P permitem que o usurio possa escrever diretamente em pginas
WEB denominadas de Blog, e nelas tambm disponibilizar arquivos, tais como MP3.
Os usurios podem criar seus Blogs de acordo com um tema. Por exemplo, um Blog
privativo para uma equipe de trabalho discutir projetos e apresentar solues. Um
sistema Blogger encontrado em (www.blogger.com.br) [20].

A empresa NewBay tambm desenvolveu uma aplicao do tipo Blog, denominada
PhoneBlog, que permite, aos usurios de equipamentos mveis, colocar fotografias,
udio, texto e vdeo em seu Blog ou lbum. Todo esse contedo imediatamente visvel
usando WAP ou um web browser padro. PhoneBlog tem sido oferecido por algumas
das operadoras T-Mobile EUA, O2 Ireland e SETAR NV em Aruba sob o servio
denominado Waw!Blog. Em mdia, so enviadas quatro mensagens MMS por o ms,
utilizando esse servio. O servio tem gerado cinco milhes de mensagens MMS em um
perodo de seis meses e a mdia do trfego WAP de 4.8 MB/ativao usurio/ms.

Outra aplicao para dispositivos mveis do tipo Blog criada pela Futurice a
denominada Futublog. A Futublog tem a finalidade de permitir, aos usurios de
celulares, compartilhar e armazenar fotos que foram tiradas pela cmera do seu
aparelho.

Semelhante ao que foi informado no incio desta seo, o desenvolvimento de
aplicaes do tipo Blog para dispositivos mveis, tambm poderia utilizar o conceito de
P2P em que os peers compartilham as informaes, que posteriormente sero
disponibilizadas no formato Blog, geralmente apenas HTML [14].


3.5 Troca de Mensagens

A possibilidade de poder observar as pessoas entrando na rede e enviar uma mensagem
em tempo real, tem tornado as aplicaes de mensagem instantnea (IM Instant
Messaging) uma das mais populares da Internet.

As conhecidas aplicaes para desktop (AIM
16
, ICQ
17
, MSN
18
e Yahoo
19
) atualmente
esto disponveis para diversos tipos de dispositivos mveis.

Muitas arquiteturas, como J XME, X-Peer e outras, que permitem P2P-Mvel, tambm
disponibilizam simples aplicativos IM para realizar testes da arquitetura.


16
Aplicativo AIM para dispositivo mvel disponvel em http://www.aol.ca/aim/mobile/index.adp
17
Software ICP para dispositivo mvel disponvel em http://www.icq.com/channels/wireless/
18
Aplicativo MSN para dispositivo mvel disponvel para dispositivos mveis em http://mobile.msn.com/
19
Aplicao Yahoo para dispositivos mveis disponvel em http://mobile.yahoo.com/messenger
31


3.6 Jogos

As aplicaes de J ogos com vrios usurios tambm podem extrair vantagens da
arquitetura P2P, que permitir encontrar esses usurios e estabelecer comunicaes P2P
para troca de mensagens durante o jogo, o que muito comum em jogo em rede.

Em Setembro de 2003, a Nokia disponibilizou uma plataforma denominada N-Gage
para jogos multi-usurio em dispositivos mveis. A plataforma permite que os usurios
possam jogar com vrios usurios conectados localmente via Bluetooth e/ou
remotamente sobre uma rede mvel. Leisure Suit Larry um exemplo de jogo para esta
plataforma. Este jogo oferece a oportunidade de testar capacidades sociais entre os
jogadores via Bluetooth. Bngo um celular com funcionalidade de handheld e
possibilita jogos utilizando Bluetooth com capacidade mxima de oito jogadores [21].

A vantagem de se utilizar arquitetura P2P para construo de jogos pode ser observada
na Tabela 4, em que P2P se enquadra tanto em jogos com pouco jogadores, como em
jogos com vrios jogadores.

Tabela 4Jogadores X Arquitetura
Nmero de J ogadores Arquitetura
Pequeno 1-16 P2P Puro
Grande 16-200 Cliente/Servidor e P2P
Hbrido
Muito grande acima de 200 P2P Hbrido
Fonte: referncia [21].

No entanto, no foram encontras propostas de arquiteturas P2P, especificas para o
desenvolvimento de jogos.


3.7 Ferramenta Educacional com Entretenimento

O uso de dispositivos mveis, atualmente, no atende apenas os adultos. Existem
aparelhos no mercado dedicados a atender crianas e adolescentes. Atualmente
possvel comprar um celular com teclados especficos para realizar chamadas
programadas para o pai e a me da criana. As Figura 5 e Figura 6 mostram exemplos
destes aparelhos.


Figura 5 Aparelho Firefly da empresa
GadgetMadness
(http://www.gadgetmadness.com)


Figura 6 Aparelho i-Care da empresa Sogi
(http://www.sogi.com.tw)
32



Devido esta disponibilidade de acesso a dispositivos mveis por crianas e adolescente,
surge o interesse em desenvolver softwares educativos para os aparelhos mveis. O
prottipo FolkMusic um exemplo de ferramenta que mescla diverso e aprendizado. Essa
aplicao explora os fundamentos da teoria dos conjuntos (incluindo elementos, conjuntos,
unies e intersees de diferentes conjuntos), onde os usurios que esto em uma
determinada localizao representam um conjunto que contm elementos (por exemplo,
msicas MP3) armazenados em um dispositivo mvel (por exemplo, smartphone ou PDA).
Quando duas pessoas se encontram, a unio de dois conjuntos pode ser realizada. Alm
disso, a interseo desses dois conjuntos indica quais os arquivos MP3 eles possuem em
comum. Tambm se pode considerar como conjunto, membros de uma comunidade,
dispositivos mveis de uma pessoa, um local, ou uma posio geogrfica. Isso significa que
um lugar pode ser carregado com arquivos de msica, os elementos msica podem ser
posicionados geograficamente.

A outra funcionalidade do FolkMusic permitir, ao mesmo tempo, a diverso durante o
aprendizado, porque aps encontrar os arquivos de msicas, elas podem ser escutadas,
antes mesmo de serem completamente baixadas para o dispositivo mvel.

A verso atual desse prottipo foi implementada utilizando a arquitetura peer-to-peer, com
possibilidade de uso em rede ad-hoc. O cdigo est disponvel para Laptop com tecnologia
de acesso WLAN (IEEE 802.11b) e um equipamento receptor GPS para traar a posio
geogrfica e associar os arquivos de msicas com a localizao. Para permitir que os
usurios explorem a teoria dos conjuntos, enquanto escutam msica, a interface grfica de
busca de MP3 foi desenvolvida baseada na teoria dos conjuntos como pode ser vista na
Figura 7. E tem como trabalho futuro porta o cdigo para PocketPC [24].


Figura 7 Interface grfica baseada em teoria dos conjuntos do software FolkMusic


33

3.8 Consideraes Finais

Neste captulo, foram apresentadas diferentes aplicaes em termos de requisitos de banda
e de qualidade de servio em geral. Esses diversos aplicativos esto disponveis no s para
equipamento com baixa restrio de hardware, mas tambm para dispositivos com alta
restrio de recursos.

Tambm foi identificada uma tendncia em portar aplicaes dos tradicionais sistemas P2P
para ambientes mveis, e um exemplo disto, o desejo do grupo GT-P2P em disponibilizar
a aplicao XVoice para dispositivos mveis.

Esse interesse geral em desenvolver aplicaes P2P para ambientes mveis, juntamente
com os desafios abordados no captulo 2, motivam o estudo aprofundado dos sistemas P2P-
Mvel. Assim como, possvel identificar a importncia de uma avaliao sobre a
viabilidade destas aplicaes.

No prximo captulo, ser apresentado um estudo detalhado de arquiteturas para dar
suporte construo dessas aplicaes.
34

4 Arquiteturas P2P

Os sistemas P2P tradicionais podem ser implementados de maneira hbrida ou totalmente
descentralizada (sistema puro). Um sistema P2P tradicional puro se subdivide em sistemas
puros estruturados e no estruturados, que se diferenciam, respectivamente, pela capacidade
de recuperar todas as informaes disponveis na rede ou apenas parte delas. Exemplos de
sistemas estruturados so os sistemas baseados em tabelas hash distribudas (DHT
Distributed Hash Tables), como Chord [1], Pastry [2], Tapestry [25] e CAN [26]. O
exemplo mais caracterstico de sistema no estruturado o Gnutella.

Sistemas hbridos tambm podem ser subdivididos em totalmente centralizados e
hierrquicos. Os sistemas hbridos totalmente centralizados possuem um n central com
todas as informaes (status online-offline dos peers, contedos compartilhados, entre
outros) de todos os peers da rede, um exemplo deste sistema o Napster. Os sistemas
hbridos hierrquicos possuem ns especiais (denominados super-ns, super-peers ou
refletores), que servem como servidores para um pequeno grupo de ns. A comunicao
entre esses super-ns, por sua vez, realizada atravs de um mecanismo dependente de
implementao. Por exemplo, os super-ns do KaZaA se comunicam entre si de maneira
totalmente no estruturada, o que dificulta a recuperao de todas as informaes
existentes na rede [27]. O resumo destes conceitos e comparao com a arquitetura
cliente/servidor est apresentado na tabela 4.

35


Tabela 5 Resumo das caractersticas de redes Cliente/Servidor e Peer-to-Peer
Cliente-
Servidor Peer-to-Peer
1. Recursos compartilhados entre os peers.
2. Recursos podem ser acessados diretamente de outros peers.
3. Peer ao mesmo tempo fornecedor e solicitador. (conceito de Servent).
P2P Hbrido P2P Puro
P2P Centralizada P2P Hierrquico No
Estruturado
Estruturada
Baseada em
DHT
1. Servidor uma
entidade
central e s ele
fornece
servios e
contedos.
->Rede
gerenciada
pelo
servidor.
2. Servidor tem
sistema com
alto
desempenho.
3. Cliente possui
sistema com
baixo
desempenho
Exemplo: WEB
1. Inclui todas as
caractersticas de
P2P.
2. necessria
uma entidade
central para
fornecer servios.
3. A entidade
central um tipo
de banco de dados
de ndice/grupo
Exemplo: Napster
1. Inclui todas
as caractersticas
de P2P.
2. Qualquer
entidade terminal
pode ser
removida sem
perdas de
funcionalidade.
3. -> Entidade
central dinmica


Exemplo: J XTA
1. Incl
ui todas as
caractersticas
de P2P.
2. Qua
lquer entidade
terminal pode
ser removida
sem perdas de
funcionalidade.
3. ->
No existe
entidade
central.

Exemplo: Gnutella
0.4 e Freenet.
1. Inclui
todas as
caractersticas
de P2P.
2. Qualquer
entidade
terminal pode
ser removida
sem perdas de
funcionalidade.
3. -> No
existe entidade
central.
4. Conexes
na overlay so
fixas.
Exemplo: Chord e
CAN.
N14
m=6 m=6
N8+
N8+
N8+
N8+
N8+
N8+
Fing
N8+
N8+
N8+
N8+
N8+
N8+
Fing
N38 N42+1
N42+2
N42+4
N42+8
N42+16
N42+32
N48
N48
N48
N51
N1
N1
Finger table
N38 N42+1
N42+2
N42+4
N42+8
N42+16
N42+32
N48
N48
N48
N51
N1
N1
N38 N42+1
N42+2
N42+4
N42+8
N42+16
N42+32
N48
N48
N48
N51
N1
N1
Finger table
N51+1
N51+2
N51+4
N51+8
N51+16
N51+32
N56
N56
N56
N1
N1
N1
Finger table
N51+1
N51+2
N51+4
N51+8
N51+16
N51+32
N56
N56
N56
N1
N1
N1
Finger table
N51+1
N51+2
N51+4
N51+8
N51+16
N51+32
N56
N56
N56
N1
N1
N1
N51+1
N51+2
N51+4
N51+8
N51+16
N51+32
N51+1
N51+2
N51+4
N51+8
N51+16
N51+32
N56
N56
N56
N1
N1
N56
N56
N56
N1
N1
N1
Finger table
N1
N8
N32
N21
N48
N51
N56
K54
2
m
-
10
+32
+16
+8
+4
+2
+1
N42
lookup(K54)
N38
N1
N8
N32
N21
N48
N51
N56
K54
2
m
-
10
+32
+16
+8
+4
+2
+1
N42
lookup(K54)
N38

Neste contexto, essas classificaes de P2P, tambm podem ser aplicadas a P2P-Mvel. Em
geral, a arquitetura hbrida hierrquica exemplificada na Figura 8 e na Tabela 5 tem se
apresentado como a mais eficiente em termos de uso de recursos mveis e controle, uma
vez que o uso da arquitetura hbrida centralizada no eficiente quando os usurios P2P
esto distribudos em diferentes operadoras [14]. No entanto, tambm existem
implementaes de arquitetura pura para P2P-Mvel.

36


Fonte: referncia [14]
Figura 8 Arquitetura hbrida com super-peers

Desse modo, este captulo est estruturado da seguinte forma. Na seo 4.1, sero descritas
arquiteturas P2P-Mvel pura que utilizam rede ad-hoc na camada de rede. Na seo 4.2,
sero apresentadas arquiteturas hbridas para P2P-Mvel. A seo 4.3 apresentar uma
arquitetura que pretende solucionar a comunicao entre as arquiteturas anteriores (P2P-
Mvel Pura e Hbrida) e na seo 4.4 so apresentadas arquiteturas para propsito geral e
especfico em relao s arquiteturas P2P-Mvel. A seo 4.5 finaliza este captulo
descrevendo consideraes finais.


4.1 Arquitetura P2P-Mvel Pura

Enfatizando a descrio da topologia MANET (mobile ad-hoc network), apresentada na
seo 2.3, esta no possui uma estrutura predeterminada consistindo, geralmente, de ns
mveis em uma rede sem fio, que podem se comunicar atravs de ns intermedirios. Os
ns de uma rede MANET se comportam semelhante a uma rede P2P pura, a diferena que
elas trabalham em diferentes camadas. MANET est especificada at a camada de rede,
enquanto o P2P se limite camada de aplicao. Desse modo, a combinao dessas
camadas tambm pode ser denominada P2P-Mvel (peer-to-peer mvel).

Existem algumas dificuldades identificadas nessa combinao, tais como os protocolos P2P
tradicionais so incapazes de determinar se est utilizando uma infra-estrutura de rede fixa
ou uma MANET. Desse modo, quando se utiliza MANET e ocorrem desconexes devido
mobilidade dos ns, uma aplicao P2P tradicional tentar re-estabelecer a conexo usando
a mesma informao de roteamento. Porm poderia haver outras fontes que forneceriam um
melhor servio, devido s mudanas na topologia da rede.

Nesta seo, sero apresentadas duas arquiteturas que podem ser classificadas como P2P-
Mvel pura e que utilizam uma rede MANET. A arquitetura Mobile CHEDAR ser
apresentada na seo 4.1.1, a Proem na seo 4.1.2 e na seo 4.1.3 essas duas arquiteturas
so comparadas.


37

4.1.1 Mobile CHEDAR

CHEDAR
20
(CHEap Distributed ARchitecture) um middleware peer-to-peer projetado
em J 2SE (Java 2 Platform, Standard Edition) e comunicao atravs de TCP para o fcil
desenvolvimento de aplicaes P2P. CHEDAR permite encontrar e manipular qualquer
recurso de uma rede, tais como dados (arquivos), software (sistemas operacionais ou
aplicaes especficas) e hardware (computadores, impressoras e monitores). Dessa modo,
CHEDAR pode ser usado para encontrar computadores inativos e com certas caractersticas
a fim de executar processamento intenso de dados.

Cada n de CHEDAR identificado por um pseudo-identificador (CHEDAR ID). Os ns
mantm tambm uma base de dados dos recursos localmente disponveis e compartilhados
pelo proprietrio do dispositivo. Os recursos remotos, descobertos na rede, tambm podem
ser adicionados base de dados, combinados com a informao sobre seu proprietrio e
identificados por CHEDAR ID e meta-informao. A meta-informao pode conter
diversas informaes, tais como o tipo, o nome e a verso dos dados para aplicaes, ou
toda a descrio til para o hardware. A base de dados de recursos armazenada no
formato XML usando um DTD
21
(Document Type Declaration) especfico. Esta
organizao dos dados em XML permite a realizao de complexas consultas base de
dados utilizando XPath
22
.

Para satisfazer os computadores mveis e as propriedades inerentes de P2P em rede sem fio
com configurao ad hoc, o projeto CHEDAR est sendo estendido plataforma mvel sob
o nome de Mobile CHEDAR. Este fornece funcionalidades de registrar recursos no
dispositivo mvel e consultar outros peers. Esta extenso foi implementada usando J 2ME,
que apropriada para dispositivos mveis sem fio. Mobile CHEDAR usa Bluetooth, como
tecnologia de transmisso de dados, no entanto aplicou certa restrio sobre essa tecnologia
de acesso.

A Figura 9 mostra as possveis topologias quando se utiliza Bluetooth.

Fonte: referncia [47].
Figura 9 Topologias de redes Bluetooth

20
Mais informaes sobre o projeto CHEDAR podem ser encontradas em http://tisu.it.jyu.fi/cheesefactory/
21
DTD uma forma de validar o documento XML, por meio da especificao de elementos ou atributos
que so permitidos em um documento XML, e em que local do documento eles podem aparecer.
22
XPath (XML Path Language) - uma linguagem para manipulao de documento XML, formada por um
conjunto de regras de sintaxe para definir partes de um documento XML. Esta linguagem usa uma notao de
caminhos para navegar atravs da estrutura hierrquica de um documento XML, de forma semelhante ao que
se faz para referenciar um diretrio no disco. Para isso XPath define uma biblioteca de funes padro.
38


Em a, tem-se uma piconet com um nico escravo. Em b, tem-se uma piconet com mltiplos
escravos. Em c, tem-se uma possvel configurao de uma scatternet onde cada piconet
tenha apenas um master, porm, escravos podem participar de diferentes piconets inclusive
o master de uma piconet, pode ser slave de outra piconet.

No entanto, o trabalho sobre Mobile CHEDAR informa que atualmente existe uma
restrio das implementaes da tecnologia Bluetooth em relao topologia c da Figura 9,
ou seja, hoje em dia um peer no pode se conectar, ao mesmo tempo, a mais de uma
piconet
23
. Ento, possvel apenas a implementao de uma nica topologia disponvel, a
estrela, em que um dispositivo tem a funo de master e os outros a funo de slave. A
Figura 10 exemplifica a topologia estrela, em que o peer gateway possui a funo mster e
os ns Mobile Chedar possuem a funo de slave.


Fonte: referncia [46].
Figura 10 Topologia estrela numa rede Mobile CHEDAR

Esta arquitetura se destaca por permitir uma maior alcanabilidade dos peers mveis que
utilizam Bluetooth, devido adio de um n gateway Mobile CHEDAR/CHEDAR. Este
dispositivo alm de possui a funcionalidade de master, tambm representa uma estao
adaptada com Bluetooth e TCP. Isto permite que os peers Mobile CHEDAR possam se
comunicar com outro grupo de peers mveis, assim como existir a comunicao entre peer
mveis e os peers de uma rede fixa. A Figura 11 exemplifica a alcanabilidade.

23
Piconet - Micro-redes de dispositivos. um termo utilizado na tecnologia Bluetooth, onde os dispositivos
que esto prximos uns dos outros automaticamente estabelecem contato entre si, formando pequenas redes.
39


Fonte: referncia [46].
Figura 11 Entrega de dados entre os ns Mobile CHEDAR e CHEDAR.

A descoberta de ns vizinhos um pr-requisito para realizar consultas de recursos. Utiliza-
se o protocolo Bluetooths Service Discovery (SDP), desde que os ns estejam disponveis
a se comunicarem utilizando o canal sem fio. Para disponibilizar uma informao nesta
rede, o n Mobile CHEDAR anuncia a outros ns usando o SDP e, ao buscar os vizinhos,
as mensagens recebidas so adicionadas base de dados de recursos, caso a base de dados
no esteja atualizada em relao nova informao. Essa informao armazenada na base
de dados de pelo menos um n deve ao menos conter o CHEDAR ID e seu endereo MAC
de Bluetooth.

A descoberta dos recursos executada com uma consulta de um salto, que identificada
pelo identificador nico da mensagem. Este salto deve atingir todos os ns dentro do
alcance de Bluetooth. Desse modo, quando a consulta chega a um n gateway
CHEDAR/Mobile CHEDAR, o n verifica se a consulta foi recebida anteriormente: se no
foi, o n gateway envia a mensagem a todos os vizinhos do n CHEDAR com um timeout;
se foi recebida anteriormente, a consulta descartada.

Nessa consulta, se a mensagem recebida combinar com um dos recursos possudos pelo n,
o n responde ao vizinho, de que recebeu a pergunta (a mensagem da resposta deve ser
marcada com o mesmo identificador da mensagem da consulta). Desse modo, a mensagem
de resposta vai at ao n de origem da consulta, percorrendo um caminho contrrio
trajetria da consulta. Aps a localizao do recurso (ou localizaes, se o recurso existir
em exemplos mltiplos na rede) ser descoberta, o n Mobile CHEDAR informa a
aplicao, que decide como adquirir ou usar o recurso [28]e [29].


40

4.1.2 Proem

Semelhante a arquitetura Mobile CHEDAR, Proem
24
leva em considerao que um sistema
P2P-Mvel um sistema descentralizado, em que no existe um n central e todos os peers
possuem as mesmas funes e responsabilidade; os links de comunicao so altamente
transientes, ou seja, conexes e desconexes ocorrem freqentemente e de forma no
esperada; os hosts mveis podem freqentemente se mover e independentemente um do
outro, sendo possvel mudar de topologia de forma no esperada.

Dessa forma, Proem um middleware que possibilita desenvolver aplicaes colaborativas,
com mobilidade altamente dinmica e com dispositivos heterogneos. Ele suporta conexo
802.11b no modo ad hoc. Este middleware consiste em trs componentes: uma aplicao
em ambiente runtime, conjunto de servios e uma pilha de protocolos e seus principais
objetivos foram:

Permitir o desenvolvimento em alto nvel de aplicaes P2P-Mvel.

Ser independente de plataforma.

Permitir interoperabilidade e extenso.

Dar suporte a conexes intermitentes.

Fornecer funes para nomeao, descoberta e identificao da presena de
servios, comunicao, gerenciamento de identificadores, de espao de dados e de
comunidades, segurana e privacidade.

Em uma rede com Proem, podem existir quatro entidades: peer que o dispositivo, usurio,
espao de dados e comunidade, que corresponde a um conjunto de entidades. Essas
entidades podem ser referenciadas por um ou mais nomes expressos em Uniform Resource
Identifiers (URL). No entanto, cada nome deve ser nico e apenas referenciar a uma
entidade. Proem tambm permite indiretamente referenciar as entidades por meio de profile
baseado em dados XML para descrever a entidade.

Nesta arquitetura (ver Figura 12) as aplicaes so denominadas peerlets e so executadas
em ambiente runtime pelos peerlet engine. Os peerlets so baseados em eventos, que so
enviados na comunicao. O ambiente runtime emite os eventos para os peerlets, como
reao a mudanas no estado interno ou externo, assim como reao a mensagens recebidas
por peers prximos. Os peerlets tambm podem ser adicionados ou retirados de um peerlet
engine.


24
Mais informaes sobre o projeto Proem podem ser encontradas em
http://wearables.cs.uoregon.edu/proem/index.html
41


Fonte: referncia [30]
Figura 12 Arquitetura do Middleware Proem

O Proem definiu a sintaxe e semntica das mensagens trocadas pelos peers por meio de
quatro protocolos um protocolo de transporte de baixo nvel e trs protocolos de alto
nvel. Essa definio garante a interoperabilidade entre implementaes do Proem em
diferentes hardware e software. Isso porque os peers Proem podem ser implementados em
qualquer linguagem e no requerem um protocolo de transporte especfico. No entanto,
fornecido apenas um ambiente de desenvolvimento para aplicaes com J ava.

O protocolo de transporte d suporte s conexes bsicas entre os peers e utiliza XML para
representar seu conjunto de mensagens. Este protocolo pode ser implementado sobre
qualquer protocolo existente, tais como TCP/IP, UDP e HTTP. O protocolo de presena
permite que o usurio anuncie sua presena e descubra a presena de outros usurios; o
protocolo de dados permite aos peers compartilhar e sincronizar os dados; e o protocolo de
comunidade permite que os peers estabeleam relacionamentos de confiana pela formao
de grupos de peers mutuamente confiveis.

O conjunto de servios fornece funcionalidades comuns para os peerlets. Esses servios so
apresentados em uma API de alto nvel. O servio gerenciamento de presena responsvel
por anunciar a presena de usurios e por descobrir usurios prximos (a proximidade
depende da topologia da rede e inclui os usurios alcanveis diretamente ou
indiretamente); o gerenciador de perfil mantm informaes sobre identificao de usurios
e recursos compartilhados; gerenciador de espao de dados responsvel pela persistncia
do armazenamento do espao de dados, assim como controle de acesso; gerenciador da
comunidade mantm os rastros dos peers em um grupo e tambm valida os peers no grupo;
o banco de dados do peer mantm um persistente log de encontros com outros peers (e
usurios) e permite peerlets adicionar meta-infomaes customizadas, o que permite
determinar quando e qual a freqncia de um particular peer ou usurios tem sido
encontrado no passado; e o barramento de eventos permite a comunicao baseada em
eventos entre os peerlets [28], [30], [31] e [32].


42

4.1.3 Proem X Mobile CHEDAR

As arquiteturas Proem e Mobile CHEDAR podem ser classificadas como arquitetura P2P-
Mvel pura e as mesmas apresentam certas vantagens e desvantagens. Ambas possibilitam
o desenvolvimento em alto nvel de aplicaes P2P-Mvel que sero executadas em
ambiente caracterizado pela grande mobilidade, pela existncia de dispositivos
heterogneos e pelos links de comunicao muito transientes. Essas caractersticas causam
a mudana de topologia de forma no esperada.

A desvantagem de ambas arquiteturas P2P-Mvel pura a provvel ineficincia em relao
performance, devido ao uso de XML. Proem usa XML nos protocolos de comunicao,
enquanto Mobile CHEDARutiliza XML no formato dos dados armazenados.

Quanto identificao dos peers, na arquitetura Mobile CHEDAR, cada peer
referenciado por um identificador nico denominado CHEDAR ID, enquanto na Proem um
peer pode ser referenciado por vrios nomes nicos nos formatos URL ou XML. Isto
facilita a interoperabilidade na Internet, que por outro lado, adiciona complexidade.

Mobile CHEDAR permite apenas a tecnologia de acesso Bluetooth (WPAN) e atualmente
no dar suporte a transferncia de dados de udio/vdeo. A Proem permite a tecnologia de
acesso 802.11b (WLAN) e possibilita a transferncia de dados em diversas aplicaes, tais
como uma aplicao de chat e compartilhamento de MP3.

Mobile CHEDAR destaca-se em relao integrao de rede fixa e mvel, assim como em
relao alcanabilidade entre peers. Provavelmente a alcanabilidade entre peers de uma
rede Proem ser menor que em uma rede CHEDAR/Mobile CHEDAR Isso porque s
possvel utilizar a estrutura ad-hoc na rede Proem. Enquanto na outra rede, podem existir
ns com funcionalidade adicional de gateway entre redes CHEDAR formadas por peers
mveis e fixos.


4.2 Arquitetura P2P-Mvel Hbrida

Nesta seo, sero apresentadas arquiteturas que permitem o desenvolvimento de
aplicaes P2P-Mvel, em ambientes onde os peers podem formar uma rede P2P-Mvel
hbrida. Na seo 4.2.1, a arquitetura J XME ser apresentada, a seo 4.2.2 descreve a
arquitetura X-Peer e a seo apresenta comparaes entre essas arquiteturas em relao a
P2P-Mvel.

4.2.1 Arquitetura JXTA para Dispositivos Mveis (JXME)

J XTA
25
uma arquitetura P2P que disponibiliza um conjunto de protocolos genricos para
programao avanada de aplicaes P2P. Ela tem sido testada em redes fixas e possui

25
Detalhes sobre o projeto J XTA podem ser encontrados em http://www.jxta.org
43

atualmente duas verses para peers mveis, desenvolvidas pelo projeto J XTA-J 2ME
(J XME
26
).

Os peers J XTA criam uma rede virtual e ad-hoc sobre a rede existente. Esses peers se
comunicam por meio de um modelo estruturado DHT. Ela disponibiliza tecnologias WEB
tais como HTTP (HyperText Transfer Protocol), TCP/IP e XML.

A arquitetura J XTA pode ser apresentada em trs camadas: camada principal, camada de
servios e camada de aplicao como visto na Figura 13. A camada principal est dividida
em peer para estabelecimento, gerenciamento da comunicao, tais como roteamento, e
outras tarefas do nvel de redes. A camada de servio est dividida em conceitos de alto
nvel tais como indexao, busca e compartilhamento de arquivos. A camada de aplicao
inclui aplicaes como sistemas de e-mail, de leilo e armazenamento.


Fonte: referncia [34]
Figura 13 Arquitetura J XTA

O modelo de endereamento do J XTA baseado em um modelo uniforme e de localizao
independente do endereamento lgico. Todos os recursos da rede possuem um peer ID,
independente do endereo fsico. A arquitetura padro baseada em super-peers
Rendezvous e Relays. Rendezvous so peers que so responsveis por armazenar ndices
dos peers ligados aos super-peers, eles fornecem o servio de busca de peers para depois
ser realizada a comunicao P2P entre os peers, mesmo quando estes estiverem conectados
a super-peers diferentes, mas no possui a capacidade de atravessar firewalls. Relays so
peers que possuem um mecanismo para comunicao com outros peers separados por
firewalls ou NAT. Estas entidades podem ser vistas na Figura 14.


26
Mais informaes sobre o projeto J XME esto disponibilizadas em http://jxme.jxta.org/
44


Figura 14 Entidades de uma rede JXTA

Em novembro de 2001, foi divulgado que a expanso dos protocolos de J XTA para permitir
o desenvolvimento de aplicaes P2P em dispositivos mveis, ou seja, a primeira verso do
J XME, seria realizada [33]. Atualmente J XME possui duas verses: proxied (J XME 1.0) e
proxyless ou sem proxy (J XME 2.0). O propsito destas verses permitir que J XTA
fornea funcionalidades compatveis com J 2ME, usando o Connected Limited Device
Configuration (CLDC) e o Mobile Information Device Profile (MIDP). Portanto,
teoricamente, qualquer dispositivo MIDP capaz de participar de atividades P2P com outro
dispositivo MIDP [9].

Alguns dos objetivos iniciais do J XME foram: interoperabilidade com J XTA em desktops e
workstations, fornecer uma infra-estrutura para pequenos dispositivos, ser pequeno o
suficiente para poder rodar em celulares e PDAs, assim como ser compatvel com MIDP
1.0. No entanto, a verso MIDP 1.0 possui limitaes como: a ausncia de um parser para
XML e suporta apenas HTTP. A verso proxied atendeu a esses objetivos, mas possu as
limitaes do MIDP 1.0 que impossibilita que os peers mveis oferecessem servios aos
outros peers [16]e [34].

A verso proxyless utiliza XML e possui quase todas as funcionalidades do J XTA nativo,
ao passo que a verso proxied mais leve e precisa de um peer J XTA nativo para agir
como seu proxy. Isso porque a verso proxied utiliza comunicaes com codificao
binria (mais leve) com seu proxy. Este tem a funo de converso entre formatos XML e
binrio, para permitir a interoperabilidade entre a verso proxied, proxyless e J XTA.
Analogamente, as duas verses de J XME no podem ser executadas como super-peers.
Uma das restries de J XME que ele trabalha atualmente apenas no ambiente J ava e
ainda no existem verses J XTA portadas para a linguagem Symbian C++[9].

Como descrito no pargrafo anterior, a verso proxied necessita de um peer com funo de
proxy, denominados J XTA relay. Dessa forma, os peers mveis agem praticamente como
pontos de viso (clientes). Os relays ficam encarregados de realizar tarefas com intenso
processamento, busca de recursos, fornece a interoperabilidade com os protocolos J XTA
entre outras funcionalidades para otimizar e permitir a participao dos peers mveis. Esta
arquitetura pode ser vista na Figura 15, em que no existi a comunicao P2P entre peers
mveis.

45


Fonte: referncia [34]
Figura 15 Arquitetura J XTA com J XME 1.0

Na Figura 15, os dispositivos mveis solicitam uma busca ao relay J XTA que encaminha
para rede J XTA, as respostas para os peers mveis passam pelo proxy que enxuga,
otimiza a mensagem e transfere para o dispositivo, uma das suas vantagens que a reduo
da mensagem lida a uma reduo do volume do trfego [16]e [34].

importante salientar que o uso de relays J XTA no uma nova idia para J XTA. Eles
existiam anteriormente, quando dois peers no eram alcanveis, devido existncia de
firewall e, ou NAT. Diferente do modelo cliente-servidor, os peers mveis no precisam
estabelecer e manter um relacionamento esttico com os relays J XTA. Dois peers mveis
podem se conectar a diferentes relays, descobrirem-se e comunicarem-se; tambm podem
dinamicamente mudar de relay, ou ter vrios relays. A referncia [10] informa que no
futuro, os peers mveis podero procurar por relays de J XTA e configurar ento um deles
para ser seu representante.

A verso J XME 2.0 tem o intuito de: d suporte a descoberta de grupos J XTA e contedos;
criar grupos e contedos; participar e entrar em grupos; e realizar o estabelecimento de
comunicaes com outros peers. Atualmente, ela apenas permite a abstrao de NAT e
firewall quando a comunicao utiliza TCP. A arquitetura desta nova verso (proxyless)
pode ser vista na Figura 16[16].


Fonte: referncia [16]
Figura 16 Arquitetura proxyless J XME

O prximo objetivo do projeto J XME, informado em 2005 na referncia [35], atualizar
J XME para que seja retirada sua dependncia a um proxy.
46



4.2.2 Arquitetura X-Peer

Com o objetivo de extrair as maiores vantagens de cada um dos modelos citados na seo
4, foi proposto o middleware X-Peer
27
, que utiliza o conceito de super-ns executando
sobre um modelo estruturado DHT para garantir escalabilidade e robustez. Dessa forma, o
X-Peer pode ser configurado para ser desde um sistema P2P centralizado, caso exista
apenas um n X-Peer, at um sistema totalmente descentralizado, caso um X-Peer execute
em cada n da rede. Se o X-Peer for configurado para trabalhar com um nmero
intermedirio de ns X-Peer, ele se comporta como o modelo hbrido do KaZaA, sendo que
os super-ns se comunicam de maneira estruturada, atravs de um sistema DHT.

Cada n X-Peer mantm um conjunto de usurios (aplicaes que utilizam servios do X-
Peer) conectados a ele, onde as meta-informaes referentes a cada usurio ficam
distribudas entre os super-ns que compem a rede X-Peer. Essas informaes podem ser
acessadas por qualquer outro super-n X-Peer em no mximo log(n) saltos, uma vez que o
X-Peer modelado sobre um DHT [36], onde n o nmero de super-ns que a rede X-Peer
contm.

Atualmente esta arquitetura est em execuo em trs pontos de presena (POP) da RNP
(Rede Nacional de Pesquisa). A Figura 17 mostra os locais em que os super-ns que
formam a rede X-Peer esto sendo executados: Pernambuco (PE), Minas Gerais (MG) e
Paran (PR). Como pode ser visto, atende a peers fixos, assim como peers mveis.


Figura 17 Infra-estrutura X-Peer na rede da RNP

Atravs do uso do X-Peer, qualquer super-n da rede pode deixar de funcionar e mesmo
assim as aplicaes conectadas continuam em execuo. Outra caracterstica inerente s
aplicaes P2P, presente nesse middleware, a capacidade de um super-n acessar
diretamente qualquer outro super-n da rede.


27
Informaes adicionais sobre X-Peer esto disponibilizadas em http://www.gprt.ufpe.br/gtp2p/
47

Nesta arquitetura podem existir dois tipos de comunicao direta (P2P) e indireta. Uma
comunicao indireta ocorre, quando os usurios no conseguem estabelecer uma
comunicao, devido presena de firewall e/ou NAT entre os peers. Todo super-n tem
papel de cliente e de servidor, operando como servidor, quando compartilha meta-
informaes, e como cliente, quando recupera meta-informaes na rede. As aplicaes por
sua vez tambm possuem o papel de cliente e servidor quando compartilham dados entre si.

A arquitetura do X-Peer dividida em trs camadas principais, ilustradas pela Figura 18.
R
e
g
i
s
t
e
r
J
o
i
n
P
o
s
t
S
c
o
p
e
G
e
t
S
e
a
r
c
h
R
e
m
o
v
e
D
e
l
i
v
e
r
L
e
a
v
e
X-Peer Core
Pastry Storage
R
e
g
i
s
t
e
r
J
o
i
n
R
e
g
i
s
t
e
r
J
o
i
n
P
o
s
t
S
c
o
p
e
P
o
s
t
S
c
o
p
e
G
e
t
S
e
a
r
c
h
G
e
t
S
e
a
r
c
h
R
e
m
o
v
e
D
e
l
i
v
e
r
L
e
a
v
e
X-Peer Core
Pastry Storage

Figura 18 Arquitetura X-Peer

Camada de Servios (Register, J oin, etc) Contm os servios disponibilizados
pelo X-Peer, teis para a construo de aplicaes P2P;

Camada de Aplicao (X-Peer Core) uma aplicao distribuda que atende
solicitaes de diversas aplicaes conectadas simultaneamente;

Camada de Mdulos teis (Pastry e Storage) Fornece alguns componentes para
prover servios camada de aplicao.

Pastry: soluo DHT adotada, que fica encapsulada sob uma interface genrica
DHT, e, portanto, pode ser substituda por outra soluo DHT que fornea a mesma
API, como o Chord.

Storage: sistema de armazenamento em arquivo desenvolvido especificamente para
o X-Peer.

Semelhante a arquitetura J XTA, o X-Peer foi projetada com a inteno de ser um
framework flexvel para o desenvolvimento de aplicaes P2P. Este o diferencial em
relao s outras arquiteturas P2P tradicionais como KaZaA e Skype. Estas redes P2P so
dedicadas a atender apenas um tipo de aplicao P2P.

Os servios que a infra-estrutura X-Peer disponibiliza para auxiliar aplicaes so descritos
abaixo:

- Join Atravs desse servio o usurio solicita a sua participao na rede.

48

- Leave Esse servio faz com que o usurio deixe a rede requisitando rede X-Peer
que remova as informaes publicadas pelo usurio. No entanto, este servio
chamado automaticamente pela rede X-Peer, quando a rede identifica que o usurio
se desconectou sem solicitar o servio Leave.

- Scope Especifica a rede visvel por um usurio, ou seja, define os usurios que
so acessveis durante uma busca.

- Post Cada usurio pertencente rede X-Peer mantm uma estrutura de dados com
informaes pblicas, que servem para localizar o usurio na rede. O Post o
servio que permite adicionar informaes nessa estrutura.

- Get Recupera informaes pblicas atravs do servio Post.

- Remove Remove um campo publicado atravs do Post.

- Search Esse servio permite localizar um usurio na rede X-Peer. Essa
localizao pode ser feita atravs do nome do usurio ou de uma informao
publicada por ele. O nome do campo, publicado atravs do Post, tambm pode ser
utilizado para recuperar um usurio.

Este middleware possui dois protocolos XApplicationProtocol e o XDHTProtocol. O
primeiro formado por um conjunto de mensagens trocadas entre as aplicaes que esto
conectadas e o X-Peer. O segundo formado por um conjunto de mensagens trocadas entre
os X-Peers para atenderem um servio. Inicialmente os protocolos deste middleware foram
implementados utilizando XML e J ava com a API J 2SE.

Em 2004, o conjunto de mensagens do protocolo XApplicationProtocol foi reestruturado
para atender dispositivos mveis e por isso implementadas com a API J 2ME. Aps a
implementao, foram realizadas avaliaes de desempenho utilizando a aplicao desta
monografia (descrita na seo 6.0). Os resultados das avaliaes apresentaram tempos de
respostas inviveis para qualquer aplicao que utilizasse o protocolo XApplicationProtocol
em equipamentos restritos como celulares e handhelds.

Aps a identificao da baixa performance com os protocolos em XML, devido
principalmente a execuo do parser do XML nos dispositivos, os conjuntos de mensagens
dos protocolos foram reimplementados utilizando o formato binrio.

A Figura 19 ilustra o tamanho das mensagens em bytes quando possuam o formato XML.
Pode-se observar que o valor mdio obtido ficava em torno de 135 bytes e o tamanho da
mensagem varia de servio para outro, mas a maioria das mensagens menor que 180
bytes. Aps a mudana para o formato binrio, as mensagens passaram a ser muito
pequenas, quando comparadas com as do formato XML. Um exemplo a mensagem Leave
que possui atualmente o tamanho de 3 byte, enquanto a mesma no formato XML possua
um pouco menos de 60bytes. Portanto, as modificaes resultaram em mensagens menores
e mais eficientes, permitindo um melhor uso de aplicaes P2P-Mveis na rede X-Peer.

49


Fonte: referncia [27]
Figura 19 Tamanho mdio das mensagens referentes aos servios X-Peer

Desse modo, esta arquitetura permite que aplicaes P2P-Mveis possam se comunicar
diretamente independente do hardware que esteja sendo executada. Uma das vantagens
desta arquitetura P2P-Mvel a possibilidade de realizar a comunicao entre diferentes
equipamentos utilizando TCP, sem a necessidade de proxys para realizar converses das
mensagens XML e binria. Essa converso acrescentaria um overhead adicional de
comunicao P2P entre dispositivos mveis.


4.2.3 X-Peer x JXTA-JXME

Os projetos J XTA e X-Peer inicialmente foram desenvolvidos para permitir a construo de
aplicaes em rede P2P do tipo hbrida e com configurao de conexo no modo de infra-
estrutura. No princpio, tambm estavam caracterizadas como um framework flexvel para
o desenvolvimento de aplicaes P2P tradicionais que seriam executadas em computadores
com baixas restries de recursos.

O crescimento no uso de dispositivos mveis motivou estes projetos a reestruturarem suas
arquiteturas para permitir a implementao de aplicaes P2P-Mvel. No entanto, essas
reestruturaes foram realizadas de maneiras diferentes.

J XTA optou por continuar a usar protocolos em XML e, para tal, foi necessrio fornecer
um menor protocolo em XML para a segunda verso de J XME. Alm disso, o grupo
adicionou proxys na rede J XTA para realizar converses entre os protocolos no formato
XML e formato binrio. Desse modo, a rede J XTA utiliza converses para atender aos
dispositivos mveis com alta restrio de hardware, os quais utilizam a primeira verso de
J XME (protocolos no formato binrio). J o projeto X-Peer optou por modificar todo o
conjunto de mensagens dos protocolos do formato XML para a estrutura binria, porque
prioriza o requisito de performance.

De maneira semelhante, as duas arquiteturas fornecem APIs para que os desenvolvedores
construam aplicaes sem se preocupar com NAT e firewall, comuns em grandes redes,
50

como a Internet. Essas APIs s abstraem esses elementos, quando se utiliza o protocolo de
transporte TCP para realizar as comunicaes P2P.

A vantagem de J XME que o mesmo permite desenvolver aplicaes utilizando o
protocolo HTTP e programar com todas as APIs de J 2ME, mas a comunicao P2P
impossvel na primeira verso de J 2ME.

A desvantagem da arquitetura X-Peer que ela restringe a implementao de aplicaes
para dispositivos mveis, porque a API dependente da verso de J 2ME 2.0 ou superior,
uma vez que as anteriores a 2.0 de J 2ME no permitem abrir conexes com Socket. Isto
impossibilita a comunicao P2P. No entanto, esta arquitetura possui a vantagem de possuir
protocolos simples, principalmente, quando comparados com mensagens em XML, e no
possui entidade intermediria para realizar tradues de protocolos, que causam um atraso
adicional.


4.3 Arquitetura para Comunicao entre as Redes P2P Pura e Hbrida

Todas as entidades de uma comunicao peer-to-peer tm um conjunto de interesses
comuns e obedecem a um conjunto comum de polticas, construindo uma comunidade P2P.
A arquitetura da Figura 20 prope a possibilidade de comunicao entre as duas redes P2P
puras e uma hbrida. Estas redes foram apresentadas na introduo deste captulo e nas
sees anteriores. Para esta integrao, foram definidas as seguintes trs novas entidades:

- Mobile proxy oferece funcionalidades adicionais para dispositivos de capacidade
restrita;

- Control node uma entidade administrativa. Esta entidade gerencia a comunidade
P2P na rede P2P. Ela fornece vrias funes independentes de aplicaes, tais como
resoluo de nome, disponibilizao de informaes para roteamento, otimizao da
topologia da rede, autenticao de ns e gerenciamento de grupos multicast;

- Gateway node a entidade intermediaria entre as redes P2P pura e hbrida. As trs
principais funes so: traduzir a ordem imposta pelo control node, coletar
informaes da topologia das redes P2P puras, em seguida reportar para o control
node e dar suporte a comunicao entre rede P2P hbrida e pura.

51


Fonte: referncia [36]
Figura 20 Arquitetura para comunidade P2P

O proxy mobile permite que um dispositivo mvel possa agir virtualmente como um n
peer-to-peer, entidade independente, e tenha uma performance necessria para
funcionalidades da arquitetura P2P. Para isso, este proxy pode ser modelado de trs formas,
vistas na Figura 21:

Tipo (a) Os dispositivos mveis compartilham o mesmo proxy, sendo assim
considerados juntamente um n na rede P2P.

Tipo (b) Cada dispositivo mvel virtualmente um n e identificado
separadamente por nomes diferentes. Para a realizao deste tipo de
proxy mobile, algumas funcionalidades devem ser implementadas no n
C, tais como transformao de mensagens recebidas de um dispositivo
mvel para uma mensagem do protocolo peer-to-peer.

Tipo (c) Este proxy mobile formado por um par de um dispositivo mvel e uma
funo proxy. Neste caso, um dispositivo mvel tem seu prprio nome e
age como ns separadamente atravs do proxy mobile que no age como
um n separadamente.

52


Fonte: referncia [36]
Figura 21 Modelagens do Proxy Mobile

Pode-se observar que este trabalho inova a abordagem de uso de proxys para atendes aos
dispositivos mveis. O cenrio para compartilhamento de arquivos um exemplo em que
esses proxys podem se comportar de maneiras diferentes. Nos prximos pargrafos, ser
exemplificado o comportamento desses proxys para atender a uma aplicao de
compartilhamento de arquivos.

Para o tipo de proxy (a), o equipamento com a funcionalidade de proxy existiria para
atender uma rede WPAN. Esta rede se comportaria como um nico peer na rede P2P para
compartilhar arquivos. A rede P2P poderia solicitaria ao proxy uma certa msica, em
seguida o proxy solicita diferentes fragmentos a cada peer da sua rede WPAN e retornando
um nico resultado.

Para o tipo de proxy (b), o equipamento com a funcionalidade de proxy no existiria apenas
para atender uma rede WPAN. Ao chegar uma solicitao de arquivo para o proxy, ele
identificaria se a mensagem para o prprio proxy (n C) ou para um dos peers da rede
WPAN.

Para o tipo de proxy (c), o equipamento com a funcionalidade de proxy existiria apenas para
atender uma rede WPAN. No entanto, apresentaria comportamento diferente do proxy tipo
(a). Ao chegar uma solicitao de arquivo para o proxy, ele identificaria qual dos peers da
rede WPAN est sendo solicitado para entregar um arquivo.

Portanto, esses trs tipos de modelagens devem existir, para que os proxys se adequem aos
requisitos da aplicao peer-to-peer.

O modelo de comunicao, para a arquitetura desta seo, fornece a possibilidade de trs
tipos de comunicao: unicast, multicast e broadcast. Uma mensagem unicast enviada ao
n de destino diretamente, usando multi-hop unicast ou multi-destination unicast, a
diferena pode ser observada na Figura 22. Quando um n recebe uma mensagem multicast
de um n de um grupo multicast, o n receptor encaminha a mensagem recebida ao grupo
53

de ns adjacentes restantes usando multi-hop unicast. O tipo de mensagem broadcast
ocorre, quando um n envia uma mensagem broadcast a todos os ns adjacentes, mas o
encaminhamento de uma mensagem broadcast controlado por sua contagem de saltos.
Isso porque, os mecanismos de nomeao e de roteamento de mensagens do P2P Core
Protocol so definidos de forma independente do protocolo de transporte. As mensagens de
pedido, de resposta e de anuncio de comunicao permitem realizar a comunicao peer-to-
peer.


Fonte: referncia [36]
Figura 22 Multi-hop X Multi-destination

Os protocolos definidos para esta arquitetura foram implementados com XML e
desenvolvidos usando HTTP, TCP e Bluetooth [36]. Uma camada P2P Core Protocol foi
definida para processar as mensagens peer-to-peer que podem ser multi-hop, broadcast e
unicast, a fim de permitir essas mensagens nas redes peer-to-peer puro e hbrido. Uma vez,
que no modelo puro caracterizado por existir multi-hop ebroadcast, enquanto o modelo
hbrido caracterizado pelas mensagens unicast.

Apesar da definio dos protocolos em XML, possvel que as aplicaes P2P para peers
mveis sejam eficientes, devido s trs abordagens de proxy na rede. Portanto, o uso da
arquitetura J XTA-J XME, juntamente com esses tipos de proxys uma soluo para
implementao de aplicaes mais eficientes em relao presena de peers moveis em
uma rede P2P que utiliza XML.


4.4 Arquitetura P2P-Mvel de Propsito Geral e Especfico

A seo 4.4.1 apresentar uma arquitetura P2P-Mvel de propsito geral a fim de
solucionar o problema de interoperabilidade descrito na seo de problemas do capitulo 2.
A seo 4.4.2 apresentar arquiteturas que tem um propsito especfico de tratar questes
de compartilhamento de arquivos em P2P-Mvel.


4.4.1 Arquitetura P2P-Mvel de Propsito Geral (PnPAP)

Atualmente, os desenvolvedores de aplicativos P2P deparam-se com diversos protocolos e
tecnologias de acesso. No entanto, eles precisam decidir a escolha de um antigo protocolo
que permite interoperabilidade, ou novo protocolo que fornece maior nmero de requisitos
54

necessrios para a aplicao. Ocorrem casos em que necessrio escolher um protocolo
com a maior compatibilidade, mesmo possuindo menor nmero de caractersticas
necessrias para a aplicao, o que acarreta em dependncias entre a aplicao e um
conjunto de protocolos.

A arquitetura PnPAP (Plug-and-Play Application Platform) foi projetada para abstrair a
situao anterior. Ela uma plataforma que tem o objetivo de fornecer a comunicao entre
aplicaes mveis que utilizam diferentes protocolos P2P e diferentes tecnologias de
conexo de maneira flexvel e eficiente. A PnPAP resolve um dos problemas da
interoperabilidade, porque possui mtodos para traduzir as diferentes maneiras de
endereamento de cada protocolo P2P. Dessa forma, ela permite a construo de aplicaes
sem se preocupar com a interoperabilidades de protocolos e tecnologias de acesso.

PnPAP permite ser utilizada por todas as linguagens de programao em rede que possam
rodar em dispositivos mveis, assim como abstrai a tecnologia de acesso utilizada para
conexo. Isso porque foi acoplada com a camada de gerenciamento Hcon (Holistic
Connectivity), que pode dinamicamente usar diferentes tecnologias de conexo de rede, tais
como WLAN, Bluetooth, EDGE e GPRS.

A Figura 23 ilustra a estrutura da PnPAP que consiste de uma interface e de um motor, que
reage a requisies recebidas atravs da interface. A seguir sero detalhadas a camada
HCon e o motor da arquitetura PnPAP.


Fonte: referncia [9]
Figura 23 Arquitetura PnPAP

HCon tem o conhecimento e controle das diferentes tecnologias de conexo de rede.
PnPAP utiliza essa camada para mudar o tipo de conexo de maneira transparente, sem que
o usurio ou aplicao requisite.

55

A referncia [9] informa que a rede de peers pode se conectar usando a melhor tecnologia
para uma determinada tarefa. Considerando o cenrio em que existe um equipamento A
com apenas Bluetooth e um equipamento B com Bluetooth e WLAN, PnPAP escolher a
conexo utilizando Bluetooth no equipamento A e WLAN no equipamento B. De acordo
com o captulo 2, em uma comunicao que utiliza Bluetooth e WLAN, a taxa de
transferncia utilizada na comunicao P2P ser a menor (Bluetooth). Portanto, no existe a
vantagem de otimizao da tecnologia de acesso.

Para realizar esta otimizao na escolha do protocolo, existe um motor na plataforma
PnPAP que controlado por uma mquina de estados (ME). Neste modelo, o motor e a ME
se comunicam usando eventos em que o motor pode enviar um evento para a ME disparar a
transio de estado. A transio pode gerar um evento que define uma ao a ser melhorada
no motor. Um exemplo, visto na Figura 24, o motor gera o evento SIP disponvel. Isto
pode gerar a transio de estado e gerar o evento trocar para SIP no motor.

ME
Motor
PnPAP
SIP disponvel
trocar para SIP

Figura 24 Exemplo da comunicao entre o ME e o Motor

A inovao deste acesso na representao da ME. A representao explicita e baseada
em um XML denominado RDF (Resource Description Framework). A ME executada
pelo interpretador de mquinas de estados que atualmente se comunica com o motor. O
artigo tambm indica que a vantagem que o comportamento do motor pode ser
modificado sem mudar o cdigo no necessrio re-compilar ou instalar nova verso. Em
vez disso, o motor passa a descrio da ME para o interpretador como um dado. Essa
descrio passada quando o motor inicializado e novas descries podem ser passadas,
quando a aplicao est em execuo.

As vantagens listadas no artigo [9] em relao existncia de uma ME controlando a
PnPAP e HCon foram:

- Ambiente uniforme para todas as aplicaes P2P.

- Fcil desenvolvimento e manuteno das aplicaes.

- O melhor protocolo P2P e conectividade so sempre escolhidos.

- Melhor interoperabilidade entre protocolos, dispositivos e redes.

- O comportamento da PnPAP pode ser modificado, devido interpretao da ME
que baseada em RDF.
56


No entanto, foi identificado no captulo 2, que as aplicaes mveis so caracterizadas por
diversas restries, em que se destaca o processamento e energia. Desse modo, pode-se
chegar a uma concluso contrria ao do artigo. Provavelmente, a flexibilidade do motor
uma desvantagem para dispositivos mveis. Isso fica claro como desvantagem, quando
indicada, no trabalho, a necessidade da mudana da representao do motor de RDF para
um formato binrio, pois a atualizao da ME no muito freqente.

possvel concorda com o trabalho da arquitetura PnPAP, quando este considerado como
uma soluo para otimizar o consumo de memria e processamento em relao ao
overhead e baixa performance causados por diferentes protocolos. Isso porque o SIP, por
exemplo, mais leve que o J XTA.


4.4.2 Arquiteturas para Compartilhamento de Arquivos em Dispositivos Mveis

Uma das reas, em que a tecnologia P2P tem se mostrado de grande sucesso na Internet, a
troca e armazenamento de contedo, por isso esta seo apresentar arquiteturas de
propsito especfico para o compartilhamento de arquivos.

As aplicaes P2P, para compartilhar recursos, necessitam ter suporte a dois requisitos
fundamentais: coordenao ou mecanismos de mediao de recursos e funes de controle.
Um exemplo para o primeiro requisito seria a disponibilizao de uma funo que permita
localizar recursos ou entidades. Exemplos para mecanismos de controle so funes que
permitem, priorizam e agendam os acessos aos recursos. A arquitetura P2P Pura
implementa ambos os mecanismos nos ns da rede, enquanto sistemas P2P Hbridos
possuem estas funes em entidades centrais.

As sees 4.4.2.1 e 4.4.2.2 apresentam cenrios em que a troca de arquivos atualmente
pode ser realizada entre dispositivos mveis utilizando a rede celular com a tecnologia
2/2,5G. A seo 4.4.2.3 descreve a proposta de modificao da arquitetura eDonkey para
permitir que dispositivos mveis possam compartilhar arquivos utilizando P2P-Mvel. Na
seo 4.4.2.4, uma comparao entre as arquiteturas de compartilhamento de arquivos
realizada.


4.4.2.1 Utilizando Servio MMS

Esta arquitetura hbrida apresenta a possibilidade de compartilhamento de arquivos para
dispositivos mveis utilizando um ou mais servidores (super-peers) dedicados. Os
servidores permitem o cadastrado e armazenamento dos nmeros (MSISDN
28
) dos
celulares e listas de arquivos vinculados ao nmero do usurio. O servidor armazena estas

28
MSISDN - Mobile Station ISDN (Integrated Services Digital Network) o nmero que permite realizar um
conjunto de chamadas para um assinante correspondente. Um assinante pode ter vrios MSISDNs,
correspondentes a diferentes servios.
57

informaes em um banco de dados. A interface com o banco de dados pode ser utilizando
um WAP ou uma pgina de buscas XHTML (Extensible HyperText Markup Language).

Esta arquitetura est exemplificada na Figura 25. Inicialmente, o dispositivo mvel utiliza a
interface com o banco de dados, para saber se existe um usurio que possui um
determinado arquivo para ser compartilhado. Se o usurio, possuidor do arquivo desejado,
for encontrado, o nmero do celular retornado. Aps o dispositivo obter o nmero, ele
solicita um pedido de compartilhamento usando mensagens do servio MMS (Multimedia
Messaging System) e finalmente a transferncia do arquivo realizada de maneira P2P.
Portanto, esta arquitetura, admite a existncia da comunicao direta com MMS entre os
celulares, aps o encontro do nmero do celular que contm um arquivo [16].

TCP/IP
1. Eu Tenho U2.mid 2. Quem tem U2.mid ?
3. Pode me enviar
U2.mid?
4. Aqui est U2.mid
2/2,5G
TCP/IP
1. Eu Tenho U2.mid 2. Quem tem U2.mid ?
3. Pode me enviar
U2.mid?
4. Aqui est U2.mid
2/2,5G

Figura 25 Busca e compartilhamento de arquivo MMS

Pode-se observa que uma desvantagem desta arquitetura a questo de privacidade dos
usurios. Semelhante a arquitetura Napster, os usurios podem ser identificados. Neste
caso, o nmero do celular leva ao usurio.

As mensagens do servio MMS foram escolhidas para transferncia dos arquivos, devido
ao rpido crescimento do uso dessas mensagens nas operadoras de celulares. Essas
mensagens so semelhantes a do servio SMS (Short Messaging Service). A diferena
que o usurio pode emitir uma mensagem MMS com vrias informaes e o tamanho no
limitado, permitindo voz e texto. O receptor reconhecido usando o nmero de MSISDN
ou um endereo de e-mail. Apesar do MMS ser considerado como tendo tamanho ilimitado,
as limitaes de capacidade e de tamanho mximo da memria do telefone mvel
restringem o tamanho da mensagem. Entretanto, poderia se usar um software que
converteria arquivos grandes em menores, para revolver esta limitao.

Uma das concluses obtidas, no captulo 2, foi a necessidade de menores preos para
motivar o uso da estrutura de rede celular para acessar servios P2P-Movl. Dessa forma,
considerando a existncia de bons preos, esta arquitetura seria boa para as operadoras,
quando se avalia o crescimento no uso de MMS gerado pelo compartilhamento de arquivos.
58

No entanto, seria ruim para os proprietrios de contedo, se no for utilizada alguma
maneira de garantir a propriedade intelectual (uso de DRM, por exemplo).

Apesar da referncia [16] apresentar como uma arquitetura P2P para compartilhamento de
arquivos utilizando a estrutura da rede celular, a Figura 26 contradiz a comunicao P2P,
por meio de um exemplo de mensagem MMS enviada de um usurio para outro. possvel
observar que a comunicao no ocorre diretamente, porque as centrais SMS e MMS
aparecem como entidades intermedirias durante a comunicao. O receptor da mensagem
primeiramente recebe uma notificao da mensagem MMS (indicado como B, na figura) e
da, se usurio desejar baixar o arquivo, conecta-se ao MMSC (Central MMS) e efetua o
download do arquivo (indicado como C). Em seguida a origem recebe uma confirmao da
entrega (indicado como D) [37].


Fonte: referncia [37]
Figura 26 Exemplo de transao MMS


4.4.2.2 Utilizando um Peer Intermedirio

Inicialmente esta arquitetura pode parecer uma contradio do paradigma P2P, mas o peer
intermedirio uma soluo para permitir que dispositivos mveis com baixa restrio de
recursos, possam compartilhar arquivos indiretamente. Isso porque o peer intermedirio
dever ser responsvel por gerenciar a transferncia de arquivos da rede P2P hbrida, assim
como ser responsvel por escolher o protocolo e tecnologia de acesso adequado para a
transmisso dos dados.

Nesta arquitetura, os peers mveis precisam estar associados a um peer intermedirio. O
peer intermedirio, na Internet, compartilha e busca recursos entre todos os outros peers
intermedirios. Quando um dispositivo mvel deseja compartilhar arquivos, ele deve
transferir seus arquivos para seu peer intermedirio, que ir compartilhar com os outros.
Pode-se observar que existe a comunicao direta entre os peers intermedirios, mas no
existe a comunicao direta entre os peer mveis.

59

O peer intermedirio caracterizado por possuir um software capaz de abrir qualquer tipo
de conexo com um dispositivo mvel, tais como infravermelho ou Bluetooth, e de
disponibilizar funcionalidade de busca e de compartilhamento de arquivos, que tambm
sero intermediadas pelo software [16]. Adicionalmente, importante que o peer
intermedirio seja capaz de realizar converses de protocolos fornecidos para os aparelhos
restritos (tais como HTTP, MMS, SMS) e os protocolos da rede fixa (tais como TCP/IP,
UDP) utilizados pelos peers intermedirios para transferir informaes de controle e de
coordenao.

4. Transferindo U2.mid
1. Quem tem U2.mid ?
2/2,5G
TCP/IP
3. Transferir U2.mid
2. Buscar U2.mid
Peer
conectado
a Internet
4. Transferindo U2.mid
1. Quem tem U2.mid ?
2/2,5G
TCP/IP
3. Transferir U2.mid
2. Buscar U2.mid
Peer
conectado
a Internet

Figura 27 Peer intermedirio

Na Figura 27, exemplificada a busca de arquivos por um peer mvel utilizando a rede de
peers intermedirios os quais utilizam, entre eles, o protocolo TCP/IP para realizar a busca
e transferncia de arquivo. Primeiramente, o peer intermedirio de um peer mvel solicita
um arquivo, em seguida o peer intermedirio se comunica de maneira P2P com outros
peers intermedirios que aps encontrar o arquivo, transfere o arquivo para o seu peer
mvel, utilizando a tecnologia de acesso e protocolo adequados. A entidade intermediria,
tambm pode realizar alteraes no arquivo, antes de transferi-lo. Um exemplo seria a
reduo da resoluo de uma figura. Dessa forma, o arquivo seria adaptado para as
restries de recursos de um determinado equipamento.

Algumas desvantagens presentes nesta arquitetura so: possivelmente o peer intermedirio
poder apresentar um atraso significativo, poder apresentar falta de privacidade, visto que
os peers dependero existencialmente dele, esta arquitetura tambm no apresenta
escalabilidade, porque o crescimento no nmero de peers mveis depender da capacidade
dos peers intermedirios e a perda da autenticidade, devido possibilidade do peer
intermedirio modificar o arquivo, no entanto, esta ltima tambm pode ser visto como
uma vantagem para melhorar a performance.


60

4.4.2.3 Extenso do eDonkey

Os sistemas P2P para compartilhamento de arquivos em ambiente mveis das sees
4.4.2.1 e 4.4.2.2 preservam os dois requisitos da seo 4.4.2 (coordenao ou mecanismos
de mediao de recursos e funes de controle), mas no atendem o mnimo desejo das
operadoras de rede mvel, que ter o controle do trfego e contedo dos dados. Dessa
forma, esta seo descreve uma proposta de uma arquitetura para melhorar a performance
de uma rede P2P com dispositivos mveis, assim como atender tambm esse requisito das
operadoras.

Para isso, foi proposta em [13] a criao de uma arquitetura P2P baseada no protocolo de
compartilhamento de arquivos eDonkey, devido a robustez e popularidade dessa rede. A
extenso da arquitetura eDonkey foi realizada por meio da modificao dos servidores de
ndices, adio de peers caching e de peers crawler, como pode ser isto na Figura 28.


Figura 28 Viso geral da arquitetura P2P-Mvel

O protocolo eDonkey foi projetado como um protocolo de rede P2P hbrida. Esse protocolo
permite que um recurso (filme, msica e outros) possa ser baixado utilizando vrios
recursos (vrias mquinas, assim como vrios fragmentos do filme). A coordenao entre
as varias fontes um tanto difcil, uma vez que os arquivos podem ser modificados ou
renomeados. Tambm necessrio o controle das cpias e fragmentos dos arquivos.

Os servidores de ndices, na arquitetura eDonkey, fornecem dois principais servios: buscar
por nome e requisitar uma fonte. Uma das modificaes nesta arquitetura foi adio de
novas funcionalidades aos servidores de ndices: monitorar todos os recursos conhecidos no
domnio da rede sem fio, identificar os arquivos mais populares, emitir uma sinalizao
para o peer cache informando a freqncia de acesso a um recurso e alterar a mensagem de
requisio de recurso, se for identificado que o recurso est disponvel em um peer cache.

61

Quando os servidores de ndices so requisitados para buscar um recurso, eles identificam a
freqncia de acesso ao recurso pelo identificador (ID) e decide considerar a popularidade
desse recurso, ou seja, mais relevante a quantidade de diferentes IDs dos peers que esto
em busca do recurso, do que a quantidade total de requisies de um recurso. Isso porque o
tempo de transmisso e tamanho do arquivo pode influenciar na quantidade de solicitaes
de requisies de um peer para um mesmo recurso.

A sinalizao enviada pelo servidor de ndice para o peer cache permite que este peer
decida, se o recurso deve ser inserido, ou retirado do conjunto de arquivos mais populares
na rede. Dessa forma, o peer cache armazena as informaes mais populares da rede, para
reduzir o uso da cara interface area dos dispositivos mveis, assim como diminuir o
trfego na rede P2P.

O peer cache foi projetado para fornecer rpidas respostas ao peers e menores filas de
espera por recursos. Ento, o cache ir permitir um nmero grande e significativo de
uploads simultneos da rede para os peers mveis que esto na margem da rede P2P. Isso
porque os peers mveis iro receber fragmentos das instncias do peers caching que
tambm esto na rede. As simulaes de [13] mostram que isto pode reduzir o trfego da
rede com dispositivos mveis e diminuir o tempo para baixar um arquivo.

Os peers crawling do suporte aos servidores de ndices com os recursos no conhecidos
no domnio da rede mvel, o que garante o controle de todo o contedo que est sendo
compartilhado pelos peers de uma operadora. Se primeiro servidor de ndice no encontrar
o resultado de uma consulta (busca de um recurso), o peer crawling automaticamente
conecta a outro servidor de ndice e realiza uma nova consulta no outro servidor. Dessa
forma, a entidade peer crawling essencial para permite que um peer mvel acesse o
contedo de peer caching de outro domnio, uma vez que os outros servidores de ndice no
podem distinguir os peers caching. Portanto, esta extenso do eDonkey atende os requisitos
de controle do trfego e contedo dos dados na rede das operadoras, para o caso de cada
servidor de ndice ser uma operadora de celular.

Para maximizar os benefcios das modificaes da arquitetura eDonkey, os peers mveis
devem se conectar ao melhor servidor de ndice. A entidade crawler usada para realizar a
coordenao entre o servidor de ndice de um domnio mvel, com os servidores de ndices
na Internet. O servidor de ndice solicita um recurso no conhecido ao crawler, que
encaminha o meta-dado para os servidores de ndices na Internet. Dessa forma, qualquer
recurso disponvel dentro da comunidade global eDonkey pode ser localizado e acessado.

A busca por recursos a partir de peers mveis, geralmente possui uma pequena
alcanabilidade e taxa de transferncia. Alm disso, os peers mveis geram trfego
duplicado (a informao percorre o caminho GGSN para rede eDonkey na Internet e o
caminho inverso) comparado com a transferncia de um recurso a partir dos super-ns da
rede. Portanto, essa extenso da arquitetura eDonkey melhora muito a performance, porque
evita baixar os recursos a partir dos peers mvies, que esto nas margens da rede [13].

A proposta desse trabalho acaba por permitir, assim como priorizar o uso assimtrico das
tecnologias de acesso, o que comum na Web. Provavelmente, interessante utilizar esta
62

estratgia em beneficio da performance, mesmo de certa forma descaracterizando a
tradicional rede P2P que utiliza a comunicao simtrica.


4.4.2.4 Comparaes entre as Arquiteturas para Compartilhamento de Arquivos

Todas as arquiteturas de propsito especficas para aplicao de compartilhamento de
arquivos descritas, na seo 4.4.2, podem ser classificadas como arquitetura P2P-Mvel
hbrida. Isso no implica que o compartilhamento de arquivos s pode ocorrer neste tipo de
arquitetura, porque a arquitetura Proem que P2P-Mvel pura tambm permite a
implementao de aplicaes de compartilhamento de arquivos em uma rede mvel ad-hoc.

A desvantagem das arquiteturas da seo 4.4.2.1 e 4.4.2.2 a quebra quase completa do
paradigma P2P, porque no permite a comunicao direta entre as aplicaes mveis. Essas
arquiteturas no permitem a comunicao P2P entre os peers mveis, porque priorizam
atender os requisitos das operadoras, especificamente, a arquitetura da seo 4.4.2.2,
quando utiliza HTTP, como protocolo da camada de transporte, apresenta estrutura
semelhante arquitetura da primeira verso de J XME.

A extenso da arquitetura eDonkey (seo 4.4.2.3) uma abordagem inovadora para as
arquiteturas de P2P-Mvel hbrida e permite a comunicao P2P entre os peers mveis.
Esta extenso tambm no permite a comunicao direta entre peer mvel e fixo, devido
existncia de proxy A comunicao direta entres os peers so evitadas, por motivo da
adio de peers caching e o peer crawler. Desse modo, esta proposta tambm quebra
parcialmente o conceito P2P. No entanto, existe a contribuio para melhorar a
performance de aplicaes P2P que utilizam arquiteturas P2P-Mveis. Alm disso a
contribuio mais relevante para cenrios em que se utilizam dispositivos mveis e
aplicaes compartilhamento de arquivos.

Portanto, a quebra do conceito P2P pode ser considerada como um preo aceitvel, visto
que a maior preocupao de P2P-Mvel lidar com os problemas inerentes a ambientes
sem fio.


4.5 Consideraes Finais

Neste captulo, foram apresentadas arquiteturas P2P-Mvel existentes. Esta pesquisa teve
como resultado o levantamento de vantagens e desvantagens das abordagens utilizadas
pelas arquiteturas, por meio de comparaes. Assim como, novas entidades foram
identificadas para melhorar a performance dos peers em uma rede P2P-Mvel, tais como:

- Proxys para converter protocolos, geralmente, para um formato binrio;

- Node gateway para aumentar a alcanabilidade de peers e integrao de redes P2P;

63

- Peers caching para reduzir o trfego na rede P2P e diminuir o uso da interface
area.

- Peers crawler para controlar o trfego e o contedo da rede P2P;

A entidade proxy foi encontrada na arquitetura da seo 4.3, na arquitetura de J XTA,
quando os peers mveis utilizam a verso 1.0 de J XME, e em arquiteturas especificas para
compartilhamento de arquivos (da seo 4.4.2.2 e 4.4.2.3).

A entidade node gateway foi encontrada na arquitetura da seo 4.3 e da seo 4.1.1
(Mobile CHEDAR). Nesta ltima, essa entidade denominada gateway CHEDAR/Mobile
CHEDAR. A arquitetura Mobile CHEDAR foi considerada em [28] e [29] como uma
arquitetura P2P-Mvel pura, mas seria possvel contradizer esta classificao, apenas
quando existir pelo menos uma entidade node gateway na rede. Isso porque, no incio deste
captulo, uma arquitetura ser P2P-Mvel, se todos os ns possurem a mesma
funcionalidade. No entanto, o node gateway possui funcionalidade diferente de todos os
outros peers. Dessa forma, quando existir um node gateway, a arquitetura Mobile
CHEDAR deveria ser classificada como P2P-Mvel hbrida, apesar de est utilizando uma
rede MANET na camada fsica.

Os super-ns das arquiteturas P2P hbridas (tais como, J XTA e X-Peer) tambm poderiam
ser vistos como entidades gateway, visto que eles, geralmente, possuem o objetivo de
permitir a alcanabilidade dos peers que esto sob NAT e/ou firewall.

As entidades peers caching e peers crawler foram encontradas apenas na extenso da
arquitetura eDonkey da seo 4.4.2.4.

Tambm foi identificado que a maioria das arquiteturas utiliza XML, o que leva a pensar na
provvel ineficincia dessas arquiteturas, visto que os trabalhos sobre X-Peer e PnPAP
relataram problemas relacionados a performance, quando se utiliza XML em equipamentos
restritos. No entanto, a proposta de trs possibilidades de implementao para proxy da
seo 4.3 pode ser uma alternativa para as arquiteturas que utilizam XML.

Em relao camada de rede, foi possvel identificar que sistemas P2P-Mvel puro
utilizam o modo de conexo ad-hoc, enquanto sistemas P2P-Mvel hbridos utilizam o
modo de conexo de infra-estrutura. possvel que isto seja uma caracterstica desses
sistemas, porque a performance de um sistema P2P-Mvel puro diminui medida que a
rede cresce, enquanto P2P-Mvel hbrido tem objetivo de transmitir dados a longa
distncia.

No prximo captulo, sero apresentadas propostas para modificao da arquitetura X-Peer.

64

5 Modificaes na Arquitetura X-Peer

Para esta monografia, foram identificadas trs propostas para serem realizadas na
arquitetura X-Peer, com diferentes nveis de dificuldades:

1. A primeira alterao faz com que aplicaes P2P e P2P-Mvel da infra-estrutura X-
Peer possam se comunicar utilizando UDP, mesmo quando estiverem sob NAT e
firewall, permitindo o desenvolvimento de aplicaes em tempo real. Um exemplo
VoIP;

2. A segunda proposta corresponde adio de novos servios que permitam
desconexes (temporrias) dos peer mveis. Desconexes ocorrem com freqncia
em um ambiente mvel, mas a atual rede X-Peer prejudicava a performance, porque
a solicitao do servio J oin sempre necessria para continuar a usar cada
aplicao em que os peer mveis anteriormente estavam conectados;

3. A terceira proposta modifica a arquitetura X-Peer para que ela permita o
desenvolvimento de aplicaes que utilizam LBS.

Respectivamente, cada uma destas propostas ser apresentada nas prximas sees.


5.1 Proposta e Implementao da Transmisso de Dados com UDP

A arquitetura Proem (seo 4.1.2) permite a comunicao entre os peers mveis utilizando
qualquer protocolo da camada de transporte, no entanto, no foi identificada a resoluo de
problemas relacionados a peers sob NAT, de forma que seja transparente para a aplicao.

At ento, a arquitetura X-Peer fornece um mdulo denominado Mdulo P2P. Este mdulo
abstrai o problema de comunicao direta (presena de firewalls e NATs) utilizando o
protocolo TCP. Isso porque, o mdulo se encarrega de testar a conectividade entre os peers
e aplicar algumas tcnicas para permitir a conexo entre eles. Dependendo da situao de
conexo de cada peer a comunicao entre eles pode ocorrer de duas formas diferentes.

As possveis situaes de conectividades de um peer A e outro peer B so:

1. B est acessvel por A. Esta situao pode ocorrer para qualquer configurao em
A (NAT e/ou firewall ou nenhum) e para B no estando sob firewall nem NAT.

2. B no est acessvel por A, mas A est acessvel por B. Esta situao pode ocorrer
para B estando sob firewall e/ou NAT e A no estando sob firewall nem NAT.

3. B no est acessvel por A nem A est acessvel por B. Esta situao pode ocorrer
quando tanto o peer A quanto o peer B esto sob firewall e/ou NAT.

65

Esse mdulo original ao identificar as situaes 1 e 2 permite que a troca de mensagens seja
realizada diretamente por meio de conexes peer-to-peer com TCP (Figura 29). Na
situao 3, A e B no conseguem trocar mensagens de forma direta, portanto o mdulo
responsvel por controlar a comunicao indireta, por meio de servio Deliver
disponibilizados pelo X-Peer (Figura 30).
Aplicao-P2P
Aplicao-P2P
Aplicao-XPeer

Figura 29 Comunicao direta com TCP
Aplicao-P2P
Aplicao-P2P
Aplicao-XPeer

Figura 30 Comunicao indireta com TCP

No entanto, existem aplicaes que requerem o uso do protocolo UDP. Por isso, a extenso
deste mdulo P2P foi proposta e implementada, para que este abstraia a presena de NAT,
quando se estiver desenvolvendo um aplicativo que utiliza o protocolo UDP. Outra funo
deste novo mdulo P2P possibilitar a transmisso de dados para o X-Peer utilizando
UDP. Nos pargrafos a seguir, a implementao da soluo ser detalhada.

Em [38] so identificadas duas maneiras de permitir a comunicao P2P entre peers que
esto sob NAT: hole punching implementado neste trabalho e relay que so peers
responsveis por encaminhar mensagens. Esta ltima uma boa tcnica a ser utilizada
quando a primeira falhar por motivos de firewall.

A implementao da tcnica hole punching permite que possa existir a comunicao direta
entre os peers, quando estes estiverem sob NAT (Figura 31). Isso evita a sobrecarga dos
ns X-Peer, o consumo da largura da banda e reduz atraso na comunicao.

A tcnica de hole punching corresponde a troca de mensagens UDP utilizando ip:porta
pblicos e privados entre dois peers e ao mesmo tempo.

66

XPeer
POP-PR
XPeer
POP-PR
NAT
155.199.25.11
Sesso A-XPeer
200.133.0.31:6000
192.168.0.197:1010
Sesso B-XPeer
200.133.0.31:6000
192.168.0.192:1040
A
192.168.0.197:1010
B
192.168.0.192:1040
XPeer
200.133.0.31:6000
Sesso A-XPeer
155.199.25.11:4545
200.133.0.31:6000
Sesso B-XPeer
138.76.29.7:1212
200.133.0.31:6000
NAT
138.76.29.7

Figura 31 Componente refletor na rede X-Peer

Para implementar a tcnica hole-punching, no Mdulo P2P, foi necessrio adicionar um
componente acoplado em cada X-Peer. Este componente foi denominado RemoteUDP, que
tem a funo de enviar mensagens Return para o peer que enviou uma mensagem UDP. A
mensagem Return contm o host:porta pblico e privados do peer que enviou a mensagem
UDP.

Outro componente denominado P2PUDP foi implementado para ser utilizado pelas
aplicaes. Este utiliza a tcnica hole-puching para permitir a abstrao da existncia de
NAT na comunicao entre os peers. O componente foi estruturado de forma a permitir a
implementao de aplicaes P2P tanto para peers fixos, como mveis. O P2PUDP utiliza
inicialmente o RemoteUDP para saber o ip:porta pblico e privado de cada aplicao.
Posteriormente, cada peer envia uma rajada de mensagens UDP solicitando hole-punching.
No momento em que um peer identifica o recebimento de uma mensagem, a tcnica
finalizada. Aps essa identificao, os peers podem realizar a comunicao P2P utilizando
UDP, mesmo existindo NAT entre os peers.

Pode-se observar que esta proposta contempla apenas a abstrao de cenrios em que os
peers esto sob NAT. A tcnica de relays identificada anteriormente poderia ser utilizada
em cenrio em que existem firewall. No entanto, na seo 6.5.3 foi identificada uma
provvel ineficincia de UDP da API de J 2ME. Por isso, a implementao da tcnica de
relay, que ir abstrair a comunicao entre peers sobre firewall, foi adicionada como
trabalho futuro.


5.2 Proposta de Novos Servios para P2P-Mvel

Durante a avaliao de desempenho (detalhada no captulo 6), foi identificado que o X-Peer
no oferece um adequado ambiente para aplicaes P2P-Mvel, quando os dispositivos
mveis que possuam alta ocorrncia de desconexes, porque a arquitetura realiza
automaticamente o servio Leave, no momento em que ocorre a desconexo de uma
67

aplicao com a rede X-Peer. Esse chamado automtico do servio Leave realizado com a
finalidade de evitar a permanncia de conexes abertas, causada pela implementao
inadequada de aplicaes, ou mesmo a desconexes de usurios que no re-conectaram
para solicitar o servio Leave.

Como conseqncia da automtica chamada do servio Leave, as aplicaes P2P-Mvel
tambm precisam solicitar o servio J oin, mesmo quando ocorrem desconexes por
questes de mobilidade, agravando a performance de qualquer aplicao. Portanto, esta
seo tem como objetivo descrever novos servios para o X-Peer, a fim de que as
aplicaes P2P-Mvel possam explorar essa arquitetura de maneira mais eficiente,
principalmente quando existir alta ocorrncia de desconexes. Esses novos servios esto
destacados na Figura 32.

X-Peer Core
Pastry Storage Cache-Mobile
R
e
g
i
s
t
e
r
J
o
i
n
P
o
s
t
S
c
o
p
e
G
e
t
S
e
a
r
c
h
R
e
m
o
v
e
D
e
l
i
v
e
r
L
e
a
v
e
J
o
i
n
-
M
o
b
i
l
e
S
y
n
c
h
r
o
n
i
z
e
d
-
M
o
b
i
l
e
PeerCache
X-Peer Core
Pastry Storage Cache-Mobile
R
e
g
i
s
t
e
r
J
o
i
n
P
o
s
t
S
c
o
p
e
P
o
s
t
S
c
o
p
e
G
e
t
S
e
a
r
c
h
R
e
m
o
v
e
D
e
l
i
v
e
r
L
e
a
v
e
J
o
i
n
-
M
o
b
i
l
e
S
y
n
c
h
r
o
n
i
z
e
d
-
M
o
b
i
l
e
PeerCache

Figura 32 Modificao da arquitetura X-Peer para atender a mobilidade

O componente adicional (Cache-Mobile) diferente da proposta de peer cache da seo
4.4.2.3, pois ele no tem o objetivo de evitar as comunicaes P2P. O Cache-Mobile
armazenar apenas as informaes transmitidas para o peer mvel, durante um intervalo de
tempo em que o peer mvel estiver ausente da rede. Um exemplo o cenrio em que peer
est fazendo download de um arquivo e ocorrer sua desconexo devido mobilidade. Neste
cenrio, o Cache-Mobile receber os dados que seriam enviados para o peer mvel.

O segundo novo componente (PeerCache) tem a funcionalidade semelhante ao peer cache
da seo 4.4.2.3. No entanto, o PeerCache depender do interesse da aplicao em utiliz-
lo ou no para melhorar a performance. Por isso, proposto que os servios Register e
Search sejam modificados. A aplicao utilizar Register para informe a rede X-Peer que
poder utilizar o PeerCache. Caso a aplicao tenha interessem em utilizar o PeerCache
na busca, um campo da mensagem Search preenchido.

Desse modo, quando o X-Peer identifica a necessidade de busca com PeerCache,
primeiramente ele verificar se a aplicao permite utilizar o novo componente. Em
seguida, se o contedo estiver no PeerCache, a rede X-Peer retorna o local do PeerCache,
caso contrrio o X-Peer retornar o local do peer que possui o contedo. Neste ltimo caso,
a informao ser repassada para o peer solicitante do servio Search e para o PeerCache,
ou seja, este componente tambm ir buscar o novo contedo.

68

O uso do PeerCache proposto como opcional, porque no faz sentido o uso deste
componente para todas aplicaes. Aplicao de troca de mensagem um exemplo em que
o PeerCache nunca deve ser usado, mas a aplicao de compartilhamento de arquivos
deveria utilizar o PeerCache.

A justificativa para o uso de PeerCache est relacionada com um dos problemas atuais do
paradigma P2P que sempre realiza a transferncia fim-a-fim at em situaes em que o
arquivo se encontra no cache local. Os sistemas de cache existentes foram desenvolvidos
para trabalhar com objetos Web. Por isso poderia-se utilizar o novo componente,
dependendo da aplicao, para melhorar o desempenho do X-Peer. Objetivo procurar
solues para minimizar o trfego.

O servio Join-Mobile permite que o usurio informe ao X-Peer que esta executando uma
certa aplicao em um dispositivo mvel. Isto significa que o usurio est informando
previamente que podero ocorrer desconexes devido mobilidade ou falta de energia
fornecida pela bateria. A proposta que a mensagem, enviada pelo dispositivo para
solicitar este servio, seria semelhante mensagem que permite a solicitao do servio
J oin, a diferena que o usurio, de maneira complementar, informar tambm um timeout,
ou seja, o tempo que poder ficar ausente devido mobilidade ou falta de energia fornecida
pela bateria. Dessa forma, a rede X-Peer no ir desconectar o usurio da aplicao de
forma automtica. Alm disso, se o dispositivo conseguir entrar na rede X-Peer dentro do
intervalo de tempo informado pelo Join-Mobile, a aplicao no precisar enviar uma nova
mensagem Join-Mobile ou J oin.

O timeout informado na mensagem Join-Mobile utilizada pelo componente Cache-Mobile
para que ele atue como receptor de mensagens para o peer mvel desconectado, durante
esse intervalo de tempo.

O servio Synchronized-Mobile uma opo que permitir o usurio da aplicao recuperar
toda informao armazenada no Cache-Mobile. Uma observao importante que este
servio s poder ser utilizado para aqueles usurios que entraram na rede X-Peer
utilizando o servio Join-Mobile. Outra informao relevante que s existir informao
no componente Cache-Mobile, se o tempo de ausncia do peer mvel no exceder o
timeout informado pela mensagem correspondente ao servio Join-Mobile.


5.3 Proposta LBS (Location Based Services)

LBS um tipo de SIG (Sistema de Informao Geogrfica) que tem a sua principal funo
de prover contedo baseado em localizao.

A motivao, para a disponibilizao deste servio, est relacionada com o crescimento do
uso de LBS em arquiteturas cliente/servidor. Em So Paulo, comum, txis estarem
munidos com equipamentos de navegao capazes de traar rotas por menor caminho e, at
mesmo, de determinar rotas alternativas para desviar de trfegos congestionados. Segundo
69

o International Data Corporation (IDC), a receita gerada somente pelos servios de
localizao deve ser superior a US$ 5 bilhes em 2004 [22].

A VIVO, empresa prestadora de servios de telecomunicaes mveis, est
disponibilizando aplicaes com servio de localizao de alta preciso que utilizam
tecnologia sem fio para clientes de So Paulo e do Rio de J aneiro. Baseado na tecnologia
gpsOne, da Qualcomm, que faz utilizao de satlites GPS e Estaes Rdio Base (ERBs),
da rede CDMA2000 1x da VIVO, o sistema oferece resultado com preciso de 5 a 50
metros. Atualmente ela fornece trs aplicativos: VIVO Localiza, VIVO Aqui Perto e
VIVO Onde Estou?:

- VIVO Localiza um servio de localizao de pessoas, que identifica com preciso
a posio de um usurio ou a localizao de um ponto de interesse a partir do
prprio celular.

- VIVO Aqui Perto um aplicativo desenvolvido em parceria com a Webraska para
procurar estabelecimentos comerciais, como bares, restaurantes e cinemas.

- O aplicativo VIVO Onde Estou? indica a localizao do celular, com logradouro,
nmero, bairro e cidade do prprio usurio.

Em relao ao preo, o aplicativo VIVO Localiza estipula valores variados (R$ 9,99 por
pacote de utilizao - para cinco localizaes; trs localizaes custam R$ 7,99 e uma
localizao por R$ 5,99) mais trfego de dados. VIVO Aqui Perto tem a tarifa mensal que
possibilita a utilizao do servio para 5 localizaes por R$ 9,99 [23].

Existem basicamente duas maneiras de implementar o LBS: utilizar solues baseadas em
handset (handsetbased) ou rede (network-based), que dependem da base de informaes de
clientes e da base de informaes geogrfica. As solues handset-based especificam que o
dispositivo ter que ter um receptor GPS (Global Positioning System) para fazer o processo
de localizao. As solues network-based fazem com que a localizao seja feita de
acordo com a rea de cobertura das clulas. Esta ltima soluo disponibilizada por
operadoras de telefonia celular (por exemplo, a empresa VIVO). A unio de solues
handset-based com network-based proporcionou o surgimento de uma terceira soluo
denominada hbrida.

Diante deste crescimento de aplicativo e servios LBS que utilizam este tipo de SIG, seria
interessante adicionar a funcionalidade de compartilhamento de informao geogrfica no
X-Peer. Portanto, esta seo apresentar a proposta de modificao da arquitetura, no
entanto, ser dependente de uma rede celular ou equipamento GPS, porque seria difcil sem
dados mais precisos, como os fornecidos pelas operadoras ou GPS.

Para atender este novo requisito, seria adicionado um novo protocolo denominado
XLocalizationProtocol e formado por um conjunto de mensagens para atender o novo
servio denominado XLBS servio de localizao no X-Peer. Este protocolo seria
formado por trs mensagens: XPeerAround, RegisterLBS e SearchLBS. A primeira seria
utilizada por dispositivos mveis, para qual o X-Peer mais prximo dele; o segundo tipo de
70

mensagem permitir que as aplicaes informem o interesse em compartilhar a localizao
do dispositivo; a terceira mensagem permitir que o dispositivo recupere servios,
aplicaes e peers baseados na localizao dos outros peers que tambm esto
compartilhando a localizao.

Quanto estrutura do X-Peer, seria adicionado um componente de banco de dados
geogrfico (BDGEO) em um ou mais ns X-Peer para armazenar e consultar as
informaes geogrficas coletadas por qualquer n X-Peer. Dessa forma, a Figura 33
mostra a modificao na arquitetura X-Peer com a adio do servio XLBS (servio de
localizao realizado pelo X-Peer) e o componente BDGEO que est destacado, porque ele
pode est presente em apenas um X-Peer.

X-Peer Core
Pastry Storage
R
e
g
i
s
t
e
r
J
o
i
n
P
o
s
t
S
c
o
p
e
G
e
t
S
e
a
r
c
h
R
e
m
o
v
e
D
e
l
i
v
e
r
L
e
a
v
e
X
L
B
S
BDGEO
X-Peer Core
Pastry Storage
R
e
g
i
s
t
e
r
J
o
i
n
R
e
g
i
s
t
e
r
J
o
i
n
P
o
s
t
S
c
o
p
e
P
o
s
t
S
c
o
p
e
G
e
t
S
e
a
r
c
h
G
e
t
S
e
a
r
c
h
R
e
m
o
v
e
D
e
l
i
v
e
r
L
e
a
v
e
X
L
B
S
BDGEO

Figura 33 Modificao na arquitetura X-Peer para atender LBS

A Figura 34 exemplifica o uso da mensagem RegisterLBS. Os peers podero utilizar, por
exemplo, um receptor GPS para obter a localizao. Em seguida, os peers enviaro a
mensagem RegisterLBS com as informaes da posio geogrfica, para qualquer n X-
Peer. Este ltimo encaminhar para o n X-Peer com o componente BDGEO.



Rede X-Peer XPeer
POP-PE
XPeer
POP-PE
BDGEO
RegisterLBS
GPS
Rede X-Peer XPeer
POP-PE
Rede X-Peer XPeer
POP-PE
XPeer
POP-PE
BDGEO
XPeer
POP-PE
XPeer
POP-PE
BDGEO
RegisterLBS
GPS

Figura 34 Uso do servio XLB com GPS

71

5.4 Contribuies

Neste captulo, foram apresentadas propostas para melhorar a arquitetura X-Peer em
relao a peer mveis. Ele foi resultado do estudo detalhado sobre P2P-Mvel, por meio do
levantamento de restries e pr-requisitos dos dispositivos mveis, das aplicaes, das
arquiteturas e da avaliao de desempenho que ser detalhado no prximo captulo.

possvel identificar as seguintes contribuies mais relevantes, deste captulo:

- Proposta e implementao da extenso do mdulo P2P. Esta extenso teve como
objetivo permitir a alcanabilidade de aplicaes que esto sob NAT e utilizam
UDP na camada de transporte.

- Proposta de modificao da arquitetura X-Peer, para melhor atender aos peers
mveis, por meio de dois novos componentes (Cache-Mobile e Peer-Cache) e
adio de servios para solucionar a dificuldade de aplicaes P2P-Mvel em
utilizar freqentemente o servio J oin.

- Proposta de modificao da arquitetura X-Peer para disponibilizar um servio de
LBS. Este novo servio permitir que os peers registrem e compartilhem dados
geogrficos, assim como a busca de ns X-Peer, aplicaes, peers, entre outros
recursos por meio da localizao geogrfica.

No prximo captulo, sero apresentadas a avaliao de desempenho e a aplicao
desenvolvida para realizar as medies nessa avaliao.

72

6 Avaliao de Desempenho

Este captulo apresentar a avaliao de desempenho de aplicaes P2P em dispositivos
mveis. A seo 6.1 descreve a motivao e os trabalhos relacionados. A seo 6.2
apresenta o objetivo geral e especifico da avaliao de desempenho. A seo 6.3 apresenta
o ambiente da avaliao. A seo 6.4 indica os parmetros e as mtricas A seo 6.5
descreve o aplicativo desenvolvido para coletar as mtricas. A seo 6.6 fornece os
resultados de cada cenrio definido na mesma e a seo 6.7 avalia os resultados em relao
a aplicaes P2P-Mvel. A seo 6.8 descreve as dificuldades encontradas durante a
avaliao e a seo 6.9 conclui a avaliao apresentada neste captulo.


6.1 Motivao e Trabalhos Relacionados

Muitas das arquiteturas analisadas (no captulo 4) no apresentam avaliaes sobre
desempenho e experimentos para validar o uso dessas abordagens inovadoras. Foram
encontradas referncias relacionadas apenas a arquitetura eDonkey.

Em [13] e [39], apresentado um modelo de simulao para avaliar a proposta de
modificao da arquitetura eDonkey. A extenso desta arquitetura (seo 4.4.2.3) adiciona
peers caching, peers crawler e modifica os servidores de ndices. A referncia em [13]
analisa apenas as estratgias de caching para o peer caching. Em [39], so avaliados o peer
crawler e as modificaes no servidor de ndices.

O artigo [15] outra referncia que avalia a questo de aplicaes de compartilhamento de
arquivos utilizando dispositivos moveis. Esse trabalho realiza uma medio por meio de um
software que captura pacotes na comunicao entre dispositivos mveis. O cenrio avaliado
utiliza a atual arquitetura eDonkey e a tecnologia GPRS durante a medio.

Pode-se perceber que poucos artigos (apenas [13], [15] e [39]) foram publicados em relao
avaliao de desempenho no ambiente P2P-Mvel. Estes trabalhos focam principalmente
na analise da viabilidade de aplicaes de compartilhamento de arquivos. Assim como,
concluram que este tipo de aplicao vivel em redes sem fio e apresentaram a
importncia do uso de caching para reduzir o atraso na transmisso dos arquivos.

A restrio das avaliaes anteriores (apenas o uso da arquitetura eDonkey) foi uma
motivao para a realizao desta avaliao utilizando outra arquitetura P2P. Outra
motivao para esta avaliao de desempenho saber que os resultados a serem
apresentados podero direcionar e despertar o interesse na criao de novas aplicaes,
assim como servios para P2P-Mveis.


6.2 Objetivo

O objetivo geral desta avaliao estudar a viabilidade da utilizao de aplicaes P2P em
ambientes mveis sem fio utilizando a arquitetura X-Peer.
73


Para responder ao objetivo geral, foram identificados objetivos especficos enumerados
abaixo, e que este captulo se prope a responder.

1) Comunicao mvel-mvel via TCP: Qual o impacto no tempo de resposta e
vazo se o tamanho da mensagem a ser enviada for aumentada na comunicao
direta entre peers e na comunicao indireta (usando o X-Peer), quando apenas
dispositivos mveis so utilizados? Qual a diferena entre os tempos de respostas,
quando a comunicao for direta e indireta?

2) Comunicao mvel-fixo via TCP: Qual o impacto no tempo de resposta e vazo
se o tamanho da mensagem a ser enviada for aumentada na comunicao direta
entre peers e na comunicao indireta, quando se utiliza um dispositivo mvel e
uma mquina fixa? Qual a diferena entre os tempos de respostas, quando a
comunicao for direta e indireta?

3) Comparao dos itens 1 e 2: Comparar os tempos de respostas quando existe a
participao de dois peers mveis e quando existe a comunicao entre peer mvel
e fixo.

4) Aplicao utilizando UDP: Verificar a viabilidade das aplicaes P2P-Mvel que
utilizam o novo mdulo P2P desenvolvido neste trabalho de graduao (ver seo
5.1).

5) Comparao entre TCP e UDP: Realizar a comparao dos tempos de resposta,
quando se utiliza UDP e TCP na comunicao direta entra peers.

6) Avaliar atrasos: Verificar se os atrasos encontrados nos experimentos permitiro
usar certas aplicaes.


6.3 Ambiente de Avaliao

Esta seo tem a finalidade de descrever como e onde foram realizadas as anlises de
desempenho. A seguir sero descritas: a metodologia de avaliao e o ambiente
disponibilizado para realizar a avaliao.


6.3.1 Metodologia de Avaliao

Modelagem analtica, simulao e medio so tcnicas de avaliao de desempenho
conhecidas. Dentre elas, a medio foi escolhida, apesar de proporcionar resultados mais
lentos e um custo mais alto, quando comparada com um processo de simulao. Porm
atravs da medio ser possvel responder as perguntas da seo 6.2 com valores reais.

74

A desvantagem da medio quanto aos recursos fsicos e ao tempo para realizao dos
experimentos que restringem a quantidade de verificaes do desempenho, dificultando a
variao da carga e ambientes. No entanto, a medio considerada uma tcnica til para a
anlise de sistemas computacionais e requer que o sistema a ser analisado esteja disponvel.
Para atender a este requisito, um aplicativo (descrito na seo 6.5) foi implementado e a
arquitetura X-Peer foi escolhida, sobretudo, devido aos recursos que ela fornece (ver seo
4.2.2). Outro fato que influenciou na escolha da arquitetura X-Peer foi a participao no
GT-P2P. A familiaridade com o cdigo fonte facilitou a extenso da arquitetura e tambm
sua avaliao.


6.3.2 Ambiente de Medio

Na avaliao, foram utilizados os recursos operacionais do Grupo de Pesquisa de Redes de
Telecomunicaes (GPRT). A composio da rede interna do GPRT heterognea. Esta
rede formada por microcomputadores, computadores sem fio, estaes de trabalho, dois
pontos de acesso de rede sem fio, vrios servidores com diferentes plataformas
operacionais, tais como Windows 2000, Windows XP e Linux.

Quatro mquinas foram disponibilizadas para o desenvolvimento e teste da aplicao, assim
como para coleta do experimento. Dentre esses equipamentos, dois dispositivos mveis de
mo, CLI da Sony, com sistema operacional PalmOs v.5.2, CPU i.MXL, memria RAM
de 32MB, interface de rede Wireless LAN (IEEE802.11b), freqncia da banda 2.4 GHz.

O aplicativo para avaliao de desempenho (seo 6.4) foi instalado nos dispositivos
mveis e em um computador Pessoal, com sistema operacional Microsoft Windows 2000,
processador AMD Athlon (TM) XP 2000, memria RAM de 512 MB, interface de rede
Ethernet e freqncia da banda de 2.4 GHz. Em outro computador pessoal com mesma
configurao anterior foi instalado o middleware X-Peer representando um super-n da
rede X-Peer.

Foi utilizando apenas um ponto de acesso sem fio da marca DLink AirPlus Xtreme DI-624.
Este equipamento disponibiliza a comunicao sem fio IEEE 802.11g que compatvel
com o padro IEEE 802.11b (utilizado pelos dispositivos mveis, CLI), freqncia da
banda 2.4 GHz e taxa de transferncia de 108Mbps.

O ambiente de medio utilizado est descrito no diagrama da Figura 35.

75

Ethernet
Ethernet
Aplicao-XPeer
Aplicao-P2P
Rede do GPRT
Ponto de Acesso
WLAN 802.11g
WLAN 802.11b
Aplicao-P2P
WLAN 802.11b
Aplicao-P2P
Router /Switch
Ethernet
Ethernet
Aplicao-XPeer
Aplicao-P2P
Rede do GPRT
Ponto de Acesso
WLAN 802.11g
WLAN 802.11b
Aplicao-P2P
WLAN 802.11b
Aplicao-P2P
Router /Switch

Figura 35 Diagrama do ambiente de medio

Uma breve descrio dos componentes da Figura 35 pode ser observada a seguir:

- Aplicao-P2P: Componente que representa o software desenvolvido para medir,
coletar e armazenar as mtricas. Ele responsvel por enviar e receber as
mensagens, assim como ligar e desligar o contador de uma determinada mtrica. A
aplicao oferece uma interface para configurar os parmetros de entrada que esto
descritos na seo 6.4. Os dados coletados por este componente so posteriormente
carregados em uma planilha Excel para gerarem grficos. Portanto, como pode ser
visto na Figura 35, o componente foi instalado em todos equipamentos. Cada
medio sempre realizada entre dois determinados equipamentos (entre dois peers
mveis, entre dois peers fixos ou entre um peer fixo e um peer mvel).

- Ethernet: Componente que representa o tipo da tecnologia da interface de
comunicao utilizado nos equipamentos do tipo desktop.

- WLAN 802.11b: Componente que representa o tipo da tecnologia da interface de
comunicao utilizado nos dispositivos mveis.

- Ponto de acesso sem fio WLAN 802.11g: Componente responsvel por distribuir
uma banda de conexo wireless na rede GPRT. Este componente compatvel com
o 802.11b.

- Router/Switch: o equipamento responsvel por interligar o ponto de acesso sem
fio e as interfaces de rede Ethernet.

Neste ambiente, tambm foram instalados alguns softwares necessrios para execuo,
desenvolvimento e testes do aplicativo da seo 6.4. Nos computadores pessoais, foram
instaladas as mquinas virtuais (VM Virtual Machine), fornecidas pela SUN, para a
execuo da aplicao da seo 6.4 e X-Peer que foram desenvolvidas em J ava e utilizam a
76

API J 2SE; a ferramenta J 2ME Wireless Toolkit 2.0 foi instalada para permitir o
desenvolvimento da aplicao da seo 6.5 em J 2ME e um ambiente de testes por meio de
um emulador. A KVM (Kilobyte Virtual Machine) fornecida pela IBM foi instalada nos
PDAs, para ser possvel executar o cdigo desenvolvido com a ferramenta J 2ME Wireless
Toolkit 2.0.


6.4 Parmetros e Mtricas

Parmetro tudo aquilo que pode ser configurvel em uma avaliao de desempenho.
Fatores so os parmetros que variam entre os experimentos. Nveis so os valores que os
fatores podem assumir durante os experimentos. Dessa forma, abaixo sero listados os
parmetros. Apenas o ltimo foi um parmetro fixo, enquanto os nveis e fatores dos
experimentos sero definidos na seo de cenrios (seo 6.6).

- Tipo de comunicao: representa o tipo de comunicao entre os peers. Quando os
dispositivos esto sob NAT ou firewall, os peers utilizam o X-Peer para realizar a
comunicao indireta, caso contrrio o mdulo P2P (ver seo 5.1) permite que os
peers realizem a comunicao direta.

- Tamanho da mensagem: representa o tamanho em bytes do contedo da mensagem
a ser enviada e recebida entre os dispositivos.

- Equipamento: indica qual o hardware utilizado no experimento.

- Tipo do protocolo: indica qual o protocolo da camada de transporte utilizado.

- Nmero de super-ns: representa o nmero de ns X-Peers que formaro um rede
P2P. Este foi definido como um parmetro fixo, existindo apenas um X-Peer na
rede local do GPRT. Essa escolha foi limitada por questes fsicas para realizar o
experimento.

As seguintes mtricas so utilizadas para obter resultados das medies atravs da
aplicao para analise de desempenho: tempo de resposta ou RTT (Round Trip Time),
vazo e latncia no X-Peer. Cada uma dessas definies ser descrita nos prximos
pargrafos.

Tempo de resposta ou RTT. O tempo de resposta T
iAB
RTT
= T
iA
final
- T
iA
inicial
a medio
na camada de aplicao do experimento i entre os dispositivos A e B, onde T
iA
inicial

corresponde ao valor do instante anterior ao envio de uma mensagem pelo dispositivo A
para o dispositivo B, e T
iA
final
representa o valor do instante da chegada de uma mensagem
no dispositivo A. O dispositivo A receber a mensagem quando o dispositivo B responder
a chegada da mensagem de A, por meio do envio de uma mensagem para o dispositivo A.
Esta definio pode ser vista na Figura 36.

77

A B
T
iA
inicial
T
iA
final
T
iA
RTT
A B
T
iA
inicial
T
iA
final
T
iA
RTT

Figura 36 Tempo de resposta ou RTT

Latncia no X-Peer: o tempo que um pacote demora a sair de um n X-Peer, aps a
chegada do mesmo pacote. Nesta avaliao, esta mtrica apenas uma estimativa, porque o
tempo de transmisso desprezvel, em uma rede local e cabeada, visto que o tempo de
transmisso nessa rede por volta de 1 a 2 ms. Portanto a latncia do experimento i
T
i
Latncia =
T
iXPeer
RTT -
T
iP2P
RTT
, onde T
iXPeer
RTT
o valor da medio do tempo de resposta
quando a comunicao indireta peers fixos, ou seja, utilizam o X-Peer, e T
iP2P
RTT
o
valor da medio do tempo de resposta da comunicao direta entre peers fixos.

Vazo nos peers mveis: mede a quantidade de mensagens em bytes recebida pela
aplicao do dispositivo mvel em intervalos de k segundos. A vazo de um experimento i,
em um peer mvel, V
i
x=
{ (B
i
1
/ X)/ k , (B
i
2
/ X) / k, ..., (B
i
n-1
/ X) / k, (B
i
n
/ X) / k }
mensagens/segundo (msg/s), onde B
i
1
o nmero de bytes coletados no primeiro k
segundos, X o tamanho da mensagem em bytes. Desse modo, (B
i
1
/ X) representa o
nmero de mensagens recebidas.

importante ressaltar que cada amostra representa o resultado de uma mtrica coletada
durante um intervalo de tempo.


6.5 Aplicativo da Avaliao de Desempenho

Atualmente, o GT-P2P disponibiliza uma aplicao para dispositivos mveis denominada
XatMobile. Esta aplicao no adequada para essa avaliao, porque no permite o
controle das mensagens enviadas. Dessa forma, a falta de controle poderia influenciar nos
resultados.

Por isso, uma aplicao, denominada AplicaoP2P, foi implementada para realizar a
avaliao de desempenho. Este aplicativo se comporta de maneira semelhante ao comando
ping
29
, porm implementado na camada de aplicao.

A aplicao implementa um protocolo simples, composto de duas mensagens: PING, que
representa a mensagem enviada para um equipamento, e PONG, que representa a resposta a
mensagem PING.

29
O comando ping utiliza mensagens ICMP, portanto na camada de rede. Dessa forma, no adequada para
esta avaliao porque se pretende avaliar o tempo de resposta no nvel da camada de aplicao. Dessa forma,
sero considerados os atrasos causados pela mquina virtual e pelos componentes disponibilizados pelo GT-
P2P para implementar aplicaes P2P que utilizam uma rede X-Peer.
78


Este aplicativo teve como objetivo coletar as mtricas RTT e vazo. Para atender a esse
objetivo, foram identificados dois requisitos: o requisito de coleta da mtrica RTT
(detalhado na seo 6.5.1) e o requisito de coleta da mtrica vazo (detalhado na seo
6.5.1).

A aplicao desenvolvida utilizou a arquitetura X-Peer, que foi escrito totalmente em J ava.
Tambm foi usada a extenso do mdulo de comunicao P2P, implementado neste
trabalho de graduao. Este mdulo tambm foi implementado apenas na linguagem J ava e
restrito a APIs (Application Programming Interfaces) J 2SE e J 2ME. Portanto, foram
utilizadas as APIs J 2SE, J 2ME e do X-Peer, especificamente o pacote que permite utilizar a
extenso do mdulo de P2P (ver seo 5.1) e mdulo de comunicao com X-Peer.


6.5.1 Requisito de Coleta da Mtrica RTT

Este um dos requisitos do aplicativo para avaliao de desempenho. Este requisito tem a
inteno de realizar a coleta de vrias amostras da mtrica RTT ou tempo de resposta. Cada
amostra obtida no instante inicial de sada de uma mensagem PING e o tempo final
correspondente chegada da mensagem PONG, a qual representa a resposta mensagem
PING. Cada uma das mensagens est definida em um byte e elas fazem parte do protocolo
de comunicao da aplicao implementada. A troca de mensagens pode ser observada
indireta e direta esto representadas respectivamente nas Figura 37 e Figura 38.

Incio
Fim
Aplicao-P2P
Aplicao-P2P
Aplicao-XPeer
Mensagem PING
Mensagem PONG

Figura 37 Execuo de uma comunicao indireta

Incio
Fim
Aplicao-P2P
Aplicao-P2P
Aplicao-XPeer
Mensagem PING
Mensagem PONG

Figura 38 Execuo de uma comunicao direta

79

A seqncia da Figura 39 mostra como realizada a coleta da mtrica RTT. Quando se
inicia uma medio, a aplicao solicita ao usurio a configurao dos parmetros de
entradas. Aps realizar a configurao, a aplicao se conecta a um n X-Peer e solicita
servios Register para registrar a aplicao e um usurio. Em seguida, o aplicativo solicita o
servio J oin infra-estrutura X-Peer, para informar que o usurio est online na aplicao
de medio. Aps essa configurao do ambiente de medio, iniciada a medio de
acordo com o cenrio a ser avaliado. Tambm necessrio configurar o aplicativo do
segundo equipamento que segue a mesma seqncia da Figura 39, exceto os ltimos
passos. Isso porque o segundo equipamento aguarda mensagens PONG e, quando recebe
PONG, envia uma mensagem PING.


Figura 39 Diagrama de seqncia simplificado do aplicativo para coletar RTT

importante ressaltar que as coletas realizadas consideram o atraso desde a camada fsica
at a camada de aplicao, uma vez que o foco deste trabalho est em apresentar as
caractersticas viveis de aplicaes P2P-Mveis.


80

6.5.2 Requisito de coleta da Mtrica Vazo

Este o segundo requisito da aplicao de medio. Este requisito tem o objetivo de
realizar a coleta de vrias amostras da mtrica vazo. Cada amostra obtida a cada
intervalo de tempo definido na interface de configurao da aplicao. A coletado ocorre
durante a troca de mensagens PING e PONG, ou seja, a medio da vazo obtm valores
para uma aplicao caracterizada por uma sincronizao da troca de mensagens.

A seqncia da Figura 40 mostra como realizada a coleta da mtrica Vazo. Esta mtrica
capturada por apenas um equipamento, que executa a aplicao configurada para aguardar
mensagens PING. Isso, porque o equipamento, configurado para aguardar mensagens
PONG, segue o diagrama de seqncia da Figura 39.


Figura 40 Diagrama de seqncia simplificado do aplicativo para coletar RTT

Quando se inicia uma medio da Vazo, a aplicao solicita ao usurio a configurao dos
parmetros de entrada. Aps realizar a configurao, a aplicao se conectar a um n X-
Peer e solicita servios Register para registrar a aplicao e um usurio. Em seguida, o
aplicativo solicita o servio J oin infra-estrutura X-Peer, para informar que o usurio est
online na aplicao de medio. Aps essa configurao do ambiente de medio,
iniciada a medio de acordo com o cenrio a ser avaliado. Durante esta medio so
realizadas as aes: responder mensagens PING e coletar a quantidade de bytes recebida
81

pela aplicao em intervalos de tempo. O valor deste parmetro (intervalo de tempo)
determinado pelo usurio na interface de configuraes.


6.6 Cenrios e Resultados

Os objetivos desta anlise foram citados na seo 6.2 e esto relacionados com a
transmisso de dados entre usurios e a arquitetura X-Peer, considerando a participao de
peers mveis.

Devido ao grande nmero de combinaes possveis para os parmetros da seo 6.4,
optou-se por definir os fatores e nveis dos parmetros em cada cenrios.

Em todos os cenrios, foram realizadas 3 repeties para cada conjunto de 32 medies
(envio de 32 mensagens PING), porque foi identificado um elevado desvio padro para um
conjunto de 300 ou mais medies e devido a outras restries detalhadas na seo de
dificuldades. Foram rotulados intervalos de confiana ao nvel de 95%.


6.6.1 Cenrio 1: C1

As aplicaes em geral transmitem mensagens com tamanhos variados, portanto este
cenrio tem como objetivo responder o segundo questionamento da seo 6.2: saber a
variao do tempo de resposta medida que o tamanho das mensagens cresce, assim como
avaliar o tempo de resposta na comunicao direta e indireta entre peers mveis.

Foram escolhidos diferentes tamanhos de mensagens, com crescimento exponencialmente o
que pode ser visto na Tabela 6. Estes valores foram atribudos para saber o impacto no
tempo de resposta nas comunicaes diretas e indiretas, quando o tamanho da mensagem a
ser enviado cresce.

Tabela 6 Parmetros para o cenrio 1
Parmetros
Fatores Nveis
Tipo de comunicao Direta e Indireta
Tamanho da mensagem 32, 64, 128, 256, 512, 1024, 2048, 4096,
8192, 16384 bytes
Equipamento Comunicao entre dois dispositivos mveis
Tipo de protocolo TCP

A Figura 41 mostra os tempos de respostas e as taxas de mensagens recebidas por um peer
mvel (vazo) medida que o tamanho das mensagens cresce exponencialmente, na
comunicao direta. Pode-se observar que, a partir do tamanho de mensagem 8192 bytes,
inicia-se um crescimento do RTT e a queda da vazo. Ainda no existe uma justificativa
para isso.

82

De acordo com [42] cada rede impe um tamanho mximo a seus pacotes - MTU
(Maximum Transmission Unit). Dentre as principais causas esto:

1. Hardware (por exemplo, diferentes equipamentos de ponto de acesso sem fio podem
determinar diferentes tamanhos de pacotes);

2. Sistema operacional (por exemplo, todos os buffers tm 512 bytes);

3. Protocolo (o tamanho mximo para TCP pode ser maior ou menor que para UDP);

4. Compatibilidade de algum padro (por exemplo, Ethernet e 802.11b);

5. Desejo de reduzir de alguma forma as retransmisses provocadas por erro;

6. Desejo de evitar que um pacote ocupe o canal por muito tempo.

De acordo com [43], o tamanho MTU em uma rede 802.11 de 8191 bytes, por isso, a
curva de crescimento do RTT iniciada quando a mensagem possui tamanho de 8192
bytes, devido ao aumento no nmero de pacotes a serem transmitidos.

Portanto, provavelmente, a curva de crescimento do RTT iniciada quando a mensagem
possui tamanho de 8192 bytes, devido necessidade da fragmentao dos quadros em
vrios pacotes na camada de rede [42], ou seja, devido ao aumento no nmero de pacotes a
serem transmitidos.


Figura 41 RTT e Vazo da comunicao direta entre peer mveis

A Figura 42 mostra a variao do tempo de resposta e da vazo medida que a mensagem
cresce exponencialmente, na comunicao indireta. Pode-se observar que, a partir do
tamanho de mensagem 2048 bytes, apresentado o incio de um crescimento do RTT e a
queda da vazo.
83


Ainda no existe uma justificativa para isso, semelhante a explicao da Figura 41.
necessrio realizar mais estudos sobre este resultado, principalmente, para responder o
seguinte questionamento: Porque medida que as mensagens crescem acima de 2048 bytes,
no ocorrem mudanas significativas na curva de crescimentos?


Figura 42 RTT e Vazo da comunicao indireta entre peer

A Figura 43 mostra as mdias dos resultados anteriores relacionados com o tempo de
resposta e vazo da comunicao direta e indireta. Os tempos de respostas da comunicao
direta e indireta so muito prximos quando a mensagem inferior a 2048bytes, porque ,
provavelmente, as mensagens com estes tamanhos no precisam ser fragmentadas.

Figura 43 Comportamento do tempo de resposta com o aumento das mensagens

Ainda no existe uma justificativa para o comportamento da curva daFigura 43. De acordo
com [43] as redes Ethernet e 802.11 possuem tamanhos MTU diferentes e de acordo [42]
uma das causas da necessidade de fragmentao devido a compatibilidade dos padres
84

Ethernet e 802.11. Portanto, provavelmente, a diferena do incio da curva de crescimento
ocorre devido aos diferentes tamanhos de MTU para os padres de rede Ethernet e 802.11.

Tambm necessrio realizar mais estudos sobre o comportamento da curva da Figura 43,
para saber por que o atraso presente na comunicao indireta muito elevado. Existem
duas provveis suspeitas que precisam ser melhor analisados:

- Duas fragmentaes: entre as redes 802.11 e Ethernet, pois os pacotes percorrem
duas vezes o caminho peer mvel - ponto de acesso sem fio - X-Peer - ponto de
acesso sem fio - peer mvel;

- Latncia na rede X-Peer, mesmo sendo formado por apenas um n, neste ambiente
de avaliao. Ela tambm cresce medida que necessrio fragmentar mais
pacotes. Os prximos pargrafos explicam a causa deste crescimento.

O crescimento da latncia no X-Peer pode ser observado na Figura 44.


Figura 44 Latncia no X-Peer na comunicao peer fixo - peer fixo

Existe o crescimento da latncia no X-Peer medida que as mensagens crescem, porque,
quando uma aplicao deseja solicitar a execuo do servio Deliver, ocorre uma maior
quantidade de trocas de mensagens denominadas DHTDeliver utilizando UDP. Isso
representa o crescimento no atraso da comunicao indireta. A explicao para o
crescimento da latncia no X-Peer vista na Figura 45 apresentada em seguida, por meio do
diagrama de seqncia da troca de mensagens na rede X-Peer. Esse aumento da latncia
ocorre mesmo quando existe apenas um n na rede X-Peer.

85


Figura 45 Descrio do diagrama de seqncia da troca de mensagens DHTDeliver

A Figura 45 apresenta a seqncia de trocas de mensagens na rede X-Peer formada por
apenas um n. A aplicao de medio cria uma mensagem Deliver para solicitar a
execuo da transmisso de dados em uma comunicao indireta.

O n X-Peer ao recebe a mensagem Deliver cria uma mensagem DHTGet para saber o host
do X-Peer em que a aplicao do usurioB est conectado. Aps obter essa informao, o
n X-Peer envia para ele mesmo uma mensagem DHTDeliver e para cada DHTDeliver
enviada, um DHTReturn recebida. importante salientar que os ns da rede X-Peer
utilizam UDP para transmitir as mensagens DHTGet, DHTDeliver e DHTReturn; e
utilizam TCP para transmitir a mensagem Deliver.

Portanto, medida que cresce o tamanho da mensagem enviada pela aplicao de medio,
tambm cresce o nmero de pacotes UDP enviados pelo n X-Peer para ele mesmo e o
nmero de pacote utilizando TCP enviado para as aplicaes de medio.


6.6.2 Cenrio 2: C2

A arquitetura X-Peer, diferente das outras do captulo de arquitetura (captulo 4), permite a
comunicao entre um peer fixo e um peer mvel sem a presena de um Proxy. Este
cenrio tem como objetivo d continuidade da resposta do segundo questionamento da
seo de objetivos, assim como validar a comunicao direta e indireta entre um dispositivo
mvel e um desktop.

Foram escolhidos diferentes tamanhos de mensagens, com crescimento exponencialmente o
que pode ser visto na Tabela 7. Este valores foram atribudos para saber o impacto no
tempo de resposta nas comunicaes diretas e indiretas, quando o tamanho da mensagem a
ser enviado cresce.
86


Tabela 7 Parmetros para o cenrio 2
Parmetros
Fatores Nveis
Tipo de comunicao Direta e Indireta
Tamanho da mensagem 32, 64, 128, 256, 512, 1024, 2048, 4096,
8192, 16384 bytes
Equipamento Comunicao entre desktop e um dispositivo
mvel
Tipo de protocolo TCP

A Figura 46 mostra os tempos de respostas e as taxas de mensagens recebidas por um peer
fixo (vazo) medida que as mensagens crescem exponencialmente, na comunicao
direta. Pode-se observar que, a partir do tamanho de mensagem 2048bytes, inicia-se um
crescimento do RTT. Este crescimento mais claro quando se observa a queda da vazo em
2048 bytes. Ainda no existe uma justificativa para isso, mas possivelmente ocorre devido
fragmentao, semelhante a explicao do cenrio 1. Portanto, necessrio realizar novos
experimentos para confirmar a hiptese sobre a questo da fragmentao.


Figura 46 RTT (ms) e vazo (msg/s) da comunicao direta entre um peer mvel e um peer fixo

A Figura 47 mostra os tempos de respostas e as taxas de mensagens recebidas por um peer
fixo (vazo) medida que as mensagens crescem exponencialmente, na comunicao
indireta. Pode-se observar que, a partir do tamanho de mensagem 2048bytes, inicia um
crescimento do RTT, este crescimento mais claro quando se observa a queda da vazo em
2048 bytes. Ainda no existe uma justificativa para isso, mas possivelmente ocorre devido
fragmentao, semelhante a explicao do cenrio 1.

87

Figura 47 RTT (ms) e vazo (msg/s) da comunicao indireta entre um peer mvel e um peer fixo

A Figura 48 mostra as mdias dos resultados relacionados com o tempo de resposta e vazo da
comunicao direta e indireta. O tempo de resposta da comunicao direta inferior ao RTT da
comunicao indireta, existindo uma pequena diferena entre a comunicao direta e indireta.

Figura 48 RTT e vazo na comunicao entre um dispositivo mvel e um desktop

Os tempos de respostas da comunicao direta e indireta so muito prximos independente
do tamanho da mensagem. Ainda no existe uma justificativa para o comportamento da
curva da Figura 44. Observado na Figura 44 da seo 6.6.1, pode-se verificar que a latncia
no X-Peer muito pequena. Neste caso o caminho peer mvel ponto de acesso sem fio
X-Peer ponto de acesso sem fio peer mvel percorrido apenas uma vez, porque o
desktop est na rede mesma rede do X-Peer.

Os mesmos experimentos foram realizados com o ponto de acesso sem fio Trendnet
802.11g modelo Tew-410 APB Plus com taxa de transferncia de 54 Mbps. Essa mudana
de ponto de acesso sem fio representou em um RTT duas vezes maior.

88

Portanto, utilizando o resultado anterior, os percursos dos pacotes entre os peers e a
comparao entre a Figura 44 e a Figura 43, pode-se supor que o atraso mais significativo
para determinar o RTT na comunicao entre os peers o overhead causado pela
fragmentao entre as duas redes e o hardware do ponto de acesso sem fio. No entanto,
ainda seria necessrio realizar mais experimentos.


6.6.3 Cenrio 3: C3

O terceiro objetivo desta avaliao comparar os cenrios anteriores C1 e C2 que pode ser
observado na Figura 49. possvel observar que os RTTs, no intervalo de tamanho 32
1024 bytes, so muito prximos. Tambm se pode ver a escala do tempo de resposta de
resposta do menor para o maior:

1) O menor RTT representado pela comunicao direta entre um peer fixo e um peer
mvel;

2) O segundo menor tempo de resposta encontrado na comunicao indireta entre um
peer fixo e um peer mvel utilizando o X-Peer;

3) O terceiro menor RTT est na comunicao direta entre peers mveis.

4) O maior tempo de resposta encontrado na comunicao indireta entre os peers
mveis utilizando o X-Peer.

89


Figura 49 Comparando os cenrios 2 e 3

A partir do tamanho de mensagem 1024bytes, existe uma maior variao entre os tempos
de resposta. Isso ocorre provavelmente devido a diferentes fragmentaes da rede 802.11 e
Ethernet entre os peer mveis e o ponto de acesso sem fio, uma vez que existe a suspeita de
que o RTT determinado pela comunicao em que peer mveis esto presentes. Esta
ltima suposio foi apresentada no cenrio C2.


6.6.4 Cenrio 4: C4

Este cenrio tem o objetivo de responder o questionamento dos itens 3 e 4 da seo 6.2:
verificar a viabilidade de aplicaes P2P-Mvel que utilizam o novo Mdulo P2P da seo
5.1 e comparar o tempo de resposta, quando se utiliza UDP e TCP na comunicao direta
entra peers.

O ambiente de medio foi configurado de acordo com a Tabela 8, para realizar este
experimento.
90


Tabela 8 Parmetros para o cenrio 3
Parmetros
Fatores Nveis
Tipo de comunicao Direta
Tamanho da mensagem 32 bytes
Equipamento Comunicao entre peer mveis
Tipo de protocolo TCP e UDP

A literatura mostra que existe um maior atraso quando se utiliza o protocolo TCP, devido
sinalizao utilizada por esse protocolo para garantir a entrega dos pacotes, visto que TCP
um protocolo orientado a conexo. Portanto era esperado um menor tempo de resposta para
as mensagens que utilizaram UDP. No entanto, os resultados deste cenrio no se
comportaram de maneira esperada. A Figura 50 mostra o tempo de resposta quando se
utiliza UDP e TCP por meio do novo Mdulo P2P.

Figura 50 Comparando o tempo de resposta UDP e TCP

Aps identificar que o RTT da transmisso com o protocolo UDP maior que o RTT da
transmisso com o protocolo TCP, foram realizados novos experimentos isolando a API
J 2ME do cdigo do novo Mdulo P2P. Desse modo, pretendia-se saber se a diferena do
RTT est relacionada com a implementao do novo mdulo P2P. Para isso, foi necessrio
implementar uma aplicao que utiliza apenas Socket (Apenas TCP) e Datagram (Apenas
UDP).

Os resultados presentes, na Figura 51, mostram os tempos de resposta, quando se realiza a
comunicao direta entre peers mveis utilizando mensagem de tamanho 32 bytes com
91

TCP e UDP. Pode-se observar que o RTT da transmisso com o protocolo TCP inferior
ao tempo de resposta das mensagens enviadas com protocolo UDP. Portanto, os resultados
continuam a contradizer a literatura e se pode concluir que o problema no est relacionado
com a implementao do novo Mdulo P2P.

0
100
200
300
400
500
600
700
800
900
T
e
m
p
o

d
e

r
e
s
p
o
s
t
a
Mdia +IC
Mdia
Mdia - IC
Mdia +IC
563,6214099 325,5457077 151,5184728 501,3429202
Mdia 469,45 288,2 108,35 450,75
Mdia - IC
375,2785901 250,8542923 65,18152723 400,1570798
Mdulo UDP Mdulo TCP Apenas TCP Apenas UDP

Figura 51 Comparao do RTT usando apenas J2ME e Mdulo P2P

Novos experimentos foram realizados para isolar a possibilidade de que o problema esteja
relacionado com a mquina virtual dos dispositivos mveis. Para isso, as aplicaes foram
executadas com emulador de J 2ME em dois desktops. Durante a medio, este
computadores utilizaram a rede local do GPRT e dessa maneira isolando apenas a questo
da mquina virtual. Neste ambiente, o RTT das mensagens que utilizam UDP continuou a
ser maior que as mensagens que utilizavam TCP.

Dessa forma, o passo seguinte foi tambm isolar a rede de comunicao. As aplicaes
foram executadas em um nico computador sem utilizar a rede local. Os resultados dos
tempos de respostas apresentaram valores prximos. No entanto, como pode ser visto na
Figura 53, os resultados continuam a contradizer a literatura.
92

0
10
20
30
40
50
60
70
80
90
100
T
e
m
p
o

d
e

r
e
s
p
o
s
t
a
Mdia +IC
Mdia
Mdia - IC
Mdia +IC 31,9390347 28,1740196 24,9740538 29,1751475
Mdia
26,4242424 21,7272727 19,9393939 23,2727273
Mdia - IC
20,9094501 15,2805259 14,9047341 17,370307
Mdulo
UDP
Mdulo TCP
Apenas
TCP
Apenas
UDP

Figura 52 Comparao do RTT usando apenas J2ME e Mdulo P2P no emulador

Dessa forma, surgiu a suspeita de que o problema poderia est na implementao de J 2ME
em relao ao uso de UDP. Para isso, foi implementada uma aplicao de medio que
utilizasse Socket e Datagram da API J 2SE. Esta aplicao transmitiu mensagens de 32
bytes na rede local do GPRT entre dois desktops. Verificou-se que a mdia do RTT de
mensagens que utilizam UDP de 0,26ms e o tempo de resposta das mensagens que
utilizaram TCP foi em mdia de 32 ms. Portanto, a aplicao que coleta RTT e o novo
Mdulo P2P no esto implementados incorretamente, mas provavelmente o problema est
na implementao de J 2ME, ou mquina virtual para PalmOS, ou problema com a pilha
TCP do PalmOS.

Devido aos valores no esperados, foi realiza uma pesquisa sobre a ineficincia de J 2ME
quanto comunicao com UDP. Nenhum artigo comprovou essa ineficincia. O artigo
[40] tambm identificou resultados no esperados com UDP e TCP, quando avaliava
aplicaes em C e J 2ME. Esse artigo apenas suspeita que possa existir algum problema
com a mquina virtual para o dispositivo da Palm.

Foi identificado em alguns fruns que algumas pessoas tambm se deparam com este
problema, mas nenhuma apresentou a causa do problema. Tambm foi adicionada a
identificao deste problema no frum da Sun para desenvolvedores que utilizam J 2ME,
mas nenhuma resposta foi postada at este momento (10/08/2005).

Portanto, seria um trabalho futuro implementar uma aplicao de medio em C para
verificar o tempo de resposta utilizando Socket e Datagram, assim como instalar a
aplicao em J 2ME em outro dispositivo para verificar o RTT. Aps a realizao desses
experimentos, seria possvel considerar que o atraso causado pela mquina virtual,
implementao de J 2ME, ou pela pilha TCP do sistema operacional PalmOS.

93


6.7 Avaliao dos Resultados

Esta seo tem como objetivo avaliar os resultados obtidos, por meio dos experimentos, e
verificar se eles permitem utilizar aplicaes como jogos, aplicao que exija mobilidade
semelhante ao aplicativo da seo 3.6, troca de mensagens e transmisso de voz.

A referncia [41] disponibiliza informaes sobre viabilidade de jogos de acordo com
atrasos encontrados em redes sem fio. Esse trabalho classifica, em trs categorias, os jogos
para serem analisados em relao ao RTT no ambiente em rede sem fio:

1. Action games (J ogos de ao): Quake II.

2. Real-time strategy games (Estratgia em tempo real): Age of Kings.

3. Turn-based strategy games (J ogos baseados em estratgia): Panzer General 3D.

Esta referncia considera que existem dois atrasos mximos: o atraso para iniciar o jogo
(primeira fase) e o atraso durante o jogo (segunda fase). O atraso mximo de 900ms para
a primeira fase do jogo Panzer General 3D e 1400ms para Quake II e Age of Kings.

Durante o jogo, o RTT afeta a performance do jogo de acordo com a classificao do jogo.
Os atrasos mximos esto na Tabela 9.

Tabela 9 RTT em diferentes jogos

Fonte: referncia [41]
94

A Figura 53 apresentar os tempos de respostas classificados como aceitveis ou no
para determinadas classificaes de jogos em diferentes redes sem fio. Pode-se perceber
que todos os jogos que se enquadram na classificao da referncia [41], provavelmente
apresentaro boa ou aceitvel performance, independente da combinao da
comunicao (direta ou indireta) x tipo do peer (peer mvel ou peer fixo), uma vez que
o intervalo do atraso dessas combinaes est entre 200 e 400.



Fonte: referncia [41]
Figura 53 RTT X gnero do jogo X rede sem fio

A partir desta mesma referncia [41] pode-se concluir que aplicaes de trocas de
mensagens (por exemplo, xatMobile, disponvel pelo GTP2P) tambm so viveis. Isso
porque todos os jogos listados anteriormente possuem a funcionalidade de troca de
mensagens entre os jogadores. Desse modo, uma aplicao que apenas troca mensagens
provavelmente ser eficiente.

Durante a avaliao de desempenho, foi possvel identificar que uma aplicao
semelhante a da seo 3.6 no ser eficiente. Ela uma aplicao em que a mobilidade
fundamental, porm a arquitetura X-Peer no fornecer um ambiente favorvel a
desconexes que ocorrem geralmente durante a mobilidade, ou mesmo falta de energia
da bateria do dispositivo mvel.

Tambm foi identificado que no vivel implementar qualquer aplicao que utilize
UDP para transmisso de dados. Isso porque provavelmente existe a ineficincia de
UDP da API de J 2ME. Logo, seria interessante implementar a mesma aplicao de
medio em C ou C++e em seguida, verificar se o RTT com UDP e TCP iro se
comportar de maneira adequada (T
UDP
RTT
<T
TCP
RTT
). Aps essa verificao, poder-se-ia
fornecer o componente P2P em C ou C++. Dessa forma, a aplicao XVoice, disponvel
pelo GTP2P para executar em computadores locais, precisar aguardar o novo
componente P2P, para ento est disponvel para dispositivos mveis.



6.8 Dificuldades Encontradas

Existiu a inteno de tornar mais automtica possvel a aplicao desenvolvida para
coletar informaes do desempenho de aplicaes para P2P-Mveis. No entanto,
identificou-se a impossibilidade da execuo de um grande nmero de medies
seqencialmente. Primeiramente, porque aps 300 medies, o tempo de resposta varia
muito. Essa variao no tempo de resposta pode ser visto na Figura 54.

0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
22000
1
1
3
2
2
6
3
3
9
4
5
2
5
6
5
6
7
8
7
9
1
8
1
0
4
9
1
1
8
0
1
3
1
1
1
4
4
2
1
5
7
3
1
7
0
4
Nmero do Experimento
T
e
m
p
o

d
e

R
e
s
p
o
s
t
a

Figura 54 Problema com coletas automatizadas

Alm dessa variao, o equipamento bloqueado e apresenta o erro em MemoryMgr.c,
Line:4613, aps um indeterminado nmero de coletas. Esse erro obriga o usurio a
reiniciar o sistema operacional. A Figura 54 mostra um exemplo em que a aplicao foi
configurada para realizar 100000 coletas. Porm, o dispositivo mvel parou de executar
na coleta 1850 e o tempo de resposta comeou a variar intensamente acima de 500
coletas executadas.

Inicialmente se imaginou que a aplicao estava criando vrios objetos dinamicamente
o que levaria a falta de memria, visto que so aparelhos restritos em recursos. Aps a
melhor anlise da aplicao desenvolvida, observou-se que os nmeros de objetos
criados no variavam com o tempo e, na Web, o mesmo erro foi encontrado em uma
outra situao.

Para contornar este problema, foi definido um nmero fixo de 32 experimentos para
cada configurao de parmetro. Aps o fim da medio, o aparelho e todo o ambiente,
inclusive o X-Peer, so reiniciados. Realizando os experimentos dessa forma, no foi
identificado o erro de performance apresentado anteriormente. No entanto, esta maneira
no totalmente automatizada, e por isso gerando um longo tempo para realizao da
medio, assim como uma maior monitorao do dispositivo mvel por um ser humano.

96

Tambm foi definido que cada conjunto de 32 medies seria repetido trs vezes,
devido restrio da automatizao e do tempo para realizar a avaliao de desempenho
para este trabalho de graduao.

Um problema identificado na arquitetura X-Peer a questo de permitir um ambiente
vivel para a mobilidade. O X-Peer restringe que os aplicativos s possam solicitar os
servios se eles estiverem registrados e enviado uma mensagem J oin. Quando o
aplicativo fecha a conexo com a infra-estrutura X-Peer, essa rede realiza
automaticamente o servio Leave, por isso obrigando o envio de uma nova mensagem
J oin.

A identificao dos inesperados valores dos tempos de repostas inviabilizou a anlise do
novo componente P2P e resultou em uma anlise mais detalhada sobre o problema
identificado.

A existncia de um ambiente muito heterognio, tambm foi uma dificuldade, porque
exigia uma maior ateno para obter um certo controle do ambiente. Modificaes nos
resultados poderiam ser causadas por diversos fatores, e muitas vezes imaginava-se que
poderia ser a verso da aplicao de medio. Um exemplo em que a heterogeneidade
representou uma dificuldade foi a identificao de um elevada RTT, quando comparado
com medies anteriores. Inicialmente se sups que poderia ser um problema de verso
ou mesmo da implementao da AplicaoP2P, mas posteriormente identificou-se que
o uso de um diferente ponto de acesso sem fio sem fio estava causando o elevado valor
do RTT.


6.9 Consideraes Finais

Neste trabalho, so fornecidos valores reais da medio de atraso em comunicaes
diretas e indiretas utilizando uma rede X-Peer, peers fixos e mveis. Foi demonstrada
uma provvel ineficincia de aplicaes que utilizam UDP da API J 2ME e
conseqentemente uma certa impossibilidade de implementao do XVoice utilizando
o novo Mdulo P2P (seo 5.1). No entanto, foi identificada a viabilidade do uso de
jogos que utilizam o protocolo TCP nesta rede P2P-Mvel, assim como a
implementao de aplicaes de troca de mensagens.

Tambm foi observado que se deve evitar a troca de grandes mensagens entre peer
mveis e peer fixo, devido ao alto overhead, causado, provavelmente, pela a
fragmentao. Assim como, deve-se evitar a comunicao indireta entre peers mveis e
peers fixos. Alm disso, interessante priorizar a comunicao direta entre um peers
mveis e um peers fixos, no intervalo entre 32-1024 bytes. Portanto, a existncia de
uma entidade peer caching na rede X-Peer tambm beneficiaria a transferncia de
mensagens para peer mvel e peer fixo.

Em relao apenas a questo de avaliaes de desempenho, os trabalhos futuros seriam
a avaliao do novo componente implementado em outra linguagem; avaliar o X-Peer
aps a implementao da proposta para permitir um ambiente mais favorvel a
mobilidade. Assim como d continuidade as investigaes sobre o questionamento d a
existncia de fragmentao entre a rede sem fio e a rede local Ethernet e investigar a
possibilidade de mudana de tamanho MTU nas rede analisadas.
97

7 Concluso

Neste captulo, sero apresentados as consideraes finais, as principais contribuies e
os possveis trabalhos futuros.


7.1 Consideraes Finais

Esta monografia teve como objetivo o estudo dos novos desafios que os ambientes sem
fio trazem para as aplicaes P2P, considerando as diversas restries de recursos para
dispositivos mveis, aplicaes e arquiteturas P2P que permitem a participao de peers
mveis.

Como resultado da pesquisa de P2P-Mvel, inicialmente, foram apresentados as
restries e os pr-requisitos para peers mveis. Foi identificado que a presena dos
peers mveis na rede P2P poder diminuir a taxa de transferncia, uma vez que a menor
taxa de transferncia entre dois peers ser utilizada nesta comunicao P2P. Isso
motivou a utilizao de assimetria na comunicao P2P, por meio de caching. Tambm
se observou que as questes econmicas so relevantes em relao viabilidade de
P2P-Mvel, uma vez que os valores cobrados pelas operadoras e a questo de
propriedade intelectual resultam em grandes barreiras para as aplicaes P2P-Mvel,
principalmente na estrutura de rede celular.

Posteriormente foi possvel verificar que aplicaes atualmente existentes no tradicional
P2P esto sendo disponibilizadas para dispositivos mveis, assim como surgem novas
aplicaes. Um exemplo o aplicativo com o intuito educativo da seo 3.7.

Para finalizar o levantamento bibliogrfico, foram identificadas arquiteturas P2P-Mvel.
Foi possvel observar que as arquiteturas das redes P2P-Mvel podem ser classificadas
de maneira semelhante classificao das tradicionais arquiteturas P2P (pura e hbrida).
O uso de XML algo comum entre as arquiteturas, o que garanti a flexibilidade, no
entanto existe a perda de performance. Tambm comum a proposta de incluso de
proxys, quando a arquitetura da rede P2P-Mvel classificada como hbrida. A
arquitetura da seo 4.3 se destaca por apresentar trs maneiras de implementar proxys
na rede P2P-Mvel. Dentre as arquiteturas identificadas, foram encontradas vrias
arquiteturas especificas para compartilhamento de arquivos, em que a maioria utiliza a
estrutura hbrida. A extenso da arquitetura eDonkey se destaca pelas propostas de
peers caching e peers crawler que quebram o conceito P2P de simetria em benefcio da
performance. Isso porque essas entidades minimizam o uso da interface area a fim de
reduzir o atraso na transmisso, a banda e o trfego de sinalizao.

O objetivo deste trabalho de graduao tambm foi realizar uma avaliao de
desempenho para verificar a viabilidade de aplicaes P2P-Mvel. A arquitetura X-Peer
foi escolhida, sobretudo, devido ao destaque entre as arquiteturas P2P-Mvel pela
inexistncia de proxys e no utilizar XML nos seus protocolos. Isso porque o grupo, que
a desenvolveu, priorizou a performance reduzindo o overhead na comunicao P2P. Os
resultados obtidos pela aplicao implementada neste trabalho foram animadores em
relao viabilidade da construo de aplicaes P2P-Mvel utilizando o protocolo
TCP.

98

No entanto, a avaliao verificou que a arquitetura X-Peer dificulta a mobilidade dos
dispositivos. Assim como, identificou uma provvel ineficincia do uso do protocolo
UDP da API J 2ME. Este possvel problema com J 2ME teve como conseqentemente a
inviabilidade da proposta e implementao da extenso do Mdulo P2P, pois o
componente foi implementado utilizando a API de J 2ME.

O levantamento bibliogrfico e avaliao de desempenho resultaram em duas
modificaes mais relevantes para a arquitetura X-Peer:

- Proposta de modificao da arquitetura X-Peer, para melhor atender aos peers
mveis, por meio dois diferentes componentes (Cache-Mobile e PeerCache) e
adio de servios para solucionar a dificuldade de aplicaes P2P-Mvel em
utilizar freqentemente o servio J oin.

- Proposta de modificao da arquitetura X-Peer para disponibilizar um servio de
LBS. Este servio permitir o registro e compartilhamento de dados geogrficos,
assim como a busca de ns X-Peer, aplicaes, peers, entre outros recursos por
meio da localizao geogrfica.


7.2 Principais Contribuies

O trabalho realizado resultou em um estudo detalhado sobre P2P-Mvel que pode ser
enumerado em: levantamento de restries e pr-requisitos dos dispositivos mveis,
aplicaes, arquiteturas, avaliao de desempenho e propostas para melhorar a
arquitetura X-Peer. Adicionalmente, importante destacar algumas contribuies
relevantes, dentre as quais se podem citar:

- O levantamento bibliogrfico sobre P2P-Mvel resultou na descrio detalhada
do estudo sobre P2P-Mvel. Alm disso, representou a contextualizao para
compreenso das propostas de modificao da arquitetura X-Peer para que esta
fornea um melhor ambiente para esses novos peers.

- A avaliao da arquitetura X-Peer em relao participao de dispositivos
mveis resultou em:

a. Verificao da viabilidade de aplicaes P2P-Mvel utilizando o
protocolo TCP e identificao de um provvel problema com a API
J 2ME. Foi identificado que todas as arquiteturas P2P-Mvel listadas
neste documento utilizam J 2ME. Portanto esta suspeita de ineficincia de
J 2ME extremamente importante para todas essas arquiteturas, assim
como para qualquer tipo de aplicao que utilize o protocolo UDP por
meio da API J 2ME.

b. Identificao da importncia em evitar a troca de grandes mensagens
entre peer mvel e peer fixo devido ao, provvel, overhead durante a
fragmentao entre as rede sem fio e rede local Ethernet.

c. Identificao da importncia em priorizar a comunicao direta entre um
peer mvel e um peer fixo, no intervalo entre 32-1024 bytes. Portanto, a
99

existncia de uma entidade peer caching na rede X-Peer tambm
beneficiaria a transferncia de mensagens para peer mvel e peer fixo.

d. Levantamento do questionamento sobre a existncia de fragmentao
entre a rede sem fio e a rede local Ethernet para realizar uma melhor
investigao.

- A proposta e implementao da extenso do Mdulo P2P foram mais relevantes
para a arquitetura X-Peer em ambientes P2P tradicional. Isso porque a provvel
ineficincia de J 2ME, em relao ao protocolo UDP, acarretou na inviabilidade
do uso da extenso deste mdulo.

- A proposta de modificao da arquitetura X-Peer foi um dos resultados da
avaliao de desempenho, assim como do levantamento bibliogrfico. Este
ltimo apresentou uma arquitetura P2P-Mvel que prope a adio de peers
caching na rede, enquanto a avaliao identificou a dificuldade de aplicaes
P2P-Mvel em utilizar freqentemente o servio J oin. As sugestes de
modificaes tiveram como finalidade mostrar uma soluo para que a
arquitetura X-Peer fornea um melhor servio aos peers mveis.

- A proposta de modificao da arquitetura X-Peer para disponibilizar um servio
de LBS. Isso permitir o compartilhamento de recursos e recuperao desses
baseados em localizao.


7.3 Trabalhos Futuros

- Continuar a avaliao de J 2ME: finalizar a identificao da suspeita de
ineficincia da API J 2ME em relao transmisso de UDP. Para isso seria
interessante testar a aplicao de medio em outros dispositivos mveis, a fim
de verificar a existncia de algum problema quanto a mquina virtual da IMB
fornecida para PalmOS. Tambm se deve desenvolver uma aplicao em C/C++
para verificar se existe algum problema com a pilha TCP do sistema PalmOS.

- Implementar Mdulo P2P e sua extenso: Se for confirmado o problema com
J 2ME, uma sugesto de trabalho futuro seria a re-implementao do Mdulo
P2P e sua extenso em C ou C++para dispositivos mveis.

- Finalizar implementao da extenso do componente P2P: a implementao
desta extenso no foi finalizada, porque no abstrai cenrios em que os peers
esto sob firewall. Na seo 5.1, proposto o uso da tcnica com relay para
finalizar a implementao da extenso do componente P2P.

- Verificar a viabilidade da aplicao XVoice em peers mveis: atualmente,
invivel implementar qualquer aplicao P2P-Mvel utilizando UDP por meio
do novo Mdulo P2P. Portanto, aps identificar o problema ao se usar o
protocolo UDP da API J 2ME e solucionar este problema, seria interessante
avaliar aplicaes que utilizam UDP. Essa avaliao teria como objetivo
verificar a viabilidade de aplicaes semelhantes aplicao XVoice em peers
mveis em uma rede X-Peer.
100


- Avaliar outra tecnologias de rede sem fio: neste trabalho foram realizadas
medies em cenrios utilizando apenas a tecnologia 802.11 e Ethernet.
Portanto, poderia-se medir os mesmos cenrios modificando a tecnologia de
acesso, uma dessas poderia ser GPRS.

- Investigar melhor o RTT da comunicao com TCP: foram levantadas suspeitas
em relao aos resultados dos tempos de respostas da comunicao utilizando
UDP. Portanto, necessrio finalizar esta investigao, por meio de um maior
controle do ambiente de medio. Verificar o nmero de pacotes trocados
durante o experimento. Verificar se o tamanho MTU realmente diferente nas
redes sem fio Wi-Fi e rede Ethernet. Assim como, investigar a questo da
fragmentao entre as duas redes.

- Implementar a proposta da seo 5.2: implementar a proposta de modificao do
X-Peer para atender o requisito de mobilidade e avaliao de desempenho
voltada para a questo de mobilidade.

- Implementar a proposta da seo 5.3: implementar a proposta para disponibilizar
o compartilhamento de dados relacionados localizao dos peers, atravs do
novo servio XLBS e a adio de um ou vrios bancos de dados geogrficos na
rede X-Peer.
101




Referncias

[1] STOICA, I.; MORRIS, R.; KARGER, D. R.; KAASHOCK, M; DABEK, F.;
BALAKRISHNAN, H. Chord: A scalable peer-to-peer lookup protocol for
internet applications. In Proceedings of the ACM SIGCOMM, pages 149--160,
San Diego, California, Agosto de 2001.
[2] ROWSTRON, A.; DRUSCHEL, P. Pastry: Scalable, distributed object location
and routing for large-scale peer-to-peer systems. In Proc. 18th IFIP/ACM
International Conference on Distributed Systems Platforms (Middleware),
Heidelberg, Germany, pages 329-350, Outubro de 2001.
[3] NAPSTER. Pgina do Napster. Disponvel em: <http://www.napster.com>.
Acesso em: julho de 2005.
[4] KAZAA. Pgina do Kazza. Disponvel em: <http://www.kazaa.com>. Acesso em:
julho de 2005.
[5] GNUTELLA. Pgina do Gnutellla. Disponvel em: <http://www.gnutella.com>.
Acesso em: julho de 2005.
[6] DURANTE, G. B. Redes Peer-to-Peer. Disponvel em:
<www.gta.ufrj.br/grad/04_1/p2p/>. Acesso em: julho de 2005.
[7] A exploso do Wi-Fi. Disponvel em:
<http://www.cpqd.com.br/site/ContentView.php?cd=1431>. Acesso em: maio de
2005.
[8] Tecnologia: eles chegaram!. Revista Veja, edio especial n 46, julho de 2005. p.
60 61.
[9] HARJ ULA, E.; YLIANTTILA, M.; ALA-KURIKKA, J .; RIEKKI, J .; SAUVOLA,
J . Plug-and-Play Application Platform: Towards Mobile Peer-to-Peer, in the
3rd International conference on Mobile and Ubiquitous multimedia (MUM2004),
College Park, Maryland, USA, October 2004. p. 63 69.
[10] DELGADO, D. U. Implementation and Evaluation of the Service Peer
Discovery Protocol. Maio de 2004. Tese (Doutorado em Cincia da Computao)
Dept. of Microelectronics and Information Technlogy (IMIT). p. 4-10.
[11] Tutorial Wireless. Disponvel em:
<http://www.babooforum.com.br/idealbb/view.asp?topicID=269602>. Acesso em:
agosto de 2005.
[12] B. Ford. Network Address Translation and Peer-to-Peer Applications
(NATP2P). Disponvel em <http://pdos.csail.mit.edu/~baford/nat/draft-ford-
natp2p-00.txt>. Acesso em: agosto de 2005.
[13] ANDERSEN, F.; MEER, H,; DEDINSKI, I.; HOFELD, T.; KAPPLER, C.;
MDER, A.; OBERENDER, J . O.; TUTSCHKU, K. An Architecture Concept
for Mobile P2P File Sharing Services.
[14] MATUSZEWSKI, M. Business Study of Mobile Peer-to-Peer Content
Distribution. 2005. Disponvel em: <http://www.tml.tkk.fi/Opinnot/T-
109.551/2005/reports/Mobile_P2P.pdf>. Acesso em agosto de 2005.
[15] HOFELD, T.; TUTSCHKU, K.; TRAN-GIA, P.; ANDERSEN, F. Mapping of
File-Sharing onto Mobile Environments: Enhancement by UMTS. Mobile
Peer-to-Peer Computing MP2P, in conjunction with the 3rd IEEE International
Conference on Pervasive Computing and Communications (PerCom'05), Kauai
Island, Hawaii. Maio 2005.
102

[16] BISTRM, J .; PARTANEN, V. Mobile P2P Creating a mobile file-sharing
environment. Relatrio tcnico, n 344, novembro de 2004. Disponvel em:
<http://www3.informatik.uni-wuerzburg.de/staff/hossfeld>. Acesso em: agosto de
2005.
[17] IZZO, C. A. Skype: Voz sobre IP em Pocket PC. Disponvel em:
<http://www.mundosemfio.com.br/news/000022.shtml>. Acesso em: agosto de
2005.
[18] HOWIE, D.; YLIANTTILA, M.; HARJ ULA, E.; SAUVOLA, J . State-of-the-art
SIP mobile application supernetworking, proc. Nordic Radio Symposium 2004,
Oulu, Finland. Disponvel em:
<http://www.mediateam.oulu.fi/projects/allip/?lang=en>. Acesso em: agosto 2005.
[19] http://www.wirelessdevnet.com/news/2004/oct/27/news3.html 24/06/2005
[20] CALLADO, A.; KAMIENSKI, C.; SADOK, D. H.; SOUTO, E.; J NIOR, J .;
DOMINGUE, M. A. O.; SILVESTRE, G. Peer-to-Peer: Computacao
colaborativa na Internet. Minicurso apresentado no Simpsio Brasileiro de Redes
de Computadores SBRC 2004. Disponvel em:
<www.cin.ufpe.br/~cak/publications/sbrc2004_minicurso_p2p.pdf>. Acesso em:
agosto 2005.
[21] AKKAWI, A.; SCHALLER S.; WELLNITZ O.; WOLF, L. C. Networked Mobile
Gaming for 3G-Networks, ICEC 2004: Third International Conference,
Eindhoven, The Netherlands, September 1-3, 2004. p. 457 467.
[22] KUHNEN, A. Prottipo de uma aplicao LBS utilizando GPS conectado em
celular para consultar dados georeferenciados. 2003. p. 11 23.Monografia
(Trabalho de concluso de curso em cincia da computao) - Universidade
Regional de Blumenau.
[23] Vivo lana servios de localizao no celular. Setembro de 2004. Disponvel em:
<http://www.vivo.com.br/portal/press_releases_-
_vivo_lanca_servicos_de_localizacao_no_celular.php>. Acesso em: agosto 2005.
[24] WIBERG, M. FolkMusic: A Mobile Peer-to-Peer Entertainment System,
Proceedings of the 37th Hawaii International Conference on System Sciences,
USA: Big Island, 2004. p. 90290.2.
[25] STRIBLING, J .; RHEA, S.; J OSEPH, A.; KUBIATOWICZ, J . Tapestry: A
Resilient Global-scale Overlay for Service Deployment, IEEE J ournal on
Selected Areas in Communications, J aneiro 2004.
[26] RATNASAMY, S.; FRANCIS, P.; HANDLEY, M.; KARP, R.; SHENKER, S. A
Scalable Content-Addressable Network. ACM SIGCOMM 2001, Agosto de
2001.
[27] J NIOR, J . R.; FIDALGO, J .; DANTAS, R.; OLIVEIRA, L. KAMIENSKI C.;
SADOK, D. H. X-Peer: Um Middleware para Aplicaes Peer-to-Peer.
Workshop de Peer-to-Peer (WP2P). SBRC 2005 - Simpsio Brasileiro de Redes de
Computadores. 2005.
[28] KURHINEN, J .; VAPA, M.; WEBER, M.; KOTILAINEN, N.; VUORI, J . Short
Range Wireless P2P for Co-operative Learning, 3rd International Conference
on Emerging Technologies and Applications (ICETA 2004), Kosice, Slovakia,
2004.
[29] KOTILAINEN, N.; WEBER, M.; VAPA, M.; VUORI, J . Mobile Chedar - A
Peer-to-Peer Middleware for Mobile Devices, Workshops Proceedings of the
Third IEEE Conference on Pervasive Computing and Communications (Percom
2005), pp. 86-90, Kauai Island, Hawaii, USA, 2005.
103

[30] KORTUEM, G. Proem: A Middleware Platform for Mobile Peer-to-Peer
Computing, ACM SIGMOBILE Mobile Computing and Communications Review,
vol. 6, no. 4. p. 6264, 2002.
[31] DING, G.; BHARGAVA, B. Peer-to-peer File-sharing over Mobile Ad hoc
Networks, in proc. 2nd IEEE Conf. on Pervasive Computing and Communications
Workshops. Orlando, Florida, 2004.
[32] KORTUEM, G; SCHNEIDER, J .; PREUITT, D.; THOMPSON, T. G. C.;
FICKAS, S.; SEGALL, Z. When peer-to-peer comes Face-to-face: collaborative
peer-to-peer computing in mobile ad hoc Networks. IEEE Computer Society
2001. 1st International Conference on Peer-to-Peer Computing (P2P 2001),
Linkping, Sweden, 2001. p. 27-29.
[33] SIEBES, R. Peer to Peer solutions in the Semantic Web context: an overview
[34] AURORA. A.; HAYWOOD, C.; PABLA, K. S. JXTA for J2ME Extending the
Reach of Wireless With JXTA Technology. 2002. Sun Microsystems.
Disponvel em: < http://whitepapers.zdnet.co.uk/0,39025945,60062410p-
39000518q,00.htm>. Acesso em : agosto de 2005. p. 1 5.
[35] J XME. Pgina do projeto JXME. Disponvel em: <http://jxme.jxta.org/>. Acesso
em: agosto 2005.
[36] Kato, T.; ISHIKAWA, N.; SUMINO, H.; HJ ELM, J .; YU, Y.; MURAKAMI, S. A
Platform and Applications for Mobile Peer-to-Peer Communications.
Disponvel em: <http://www.research.att.com/~rjana/Takeshi_Kato.pdf>. Acesso
em: agosto de 2005.
[37] MEIRELES, R. R. Tutoriais Telefonia Celular. Disponvel em:
<http://www.teleco.com.br/tutoriais/tutorialmwm/pagina_4.asp>. Acesso em:
agosto de 2005.
[38] Peer-to-Peer Communication Across Network Address Translators.
Disponvel em: <http://www.brynosaurus.com/pub/net/p2pnat/>. Acesso em:
agosto de 2005.
[39] HOFELD, T.; MDER, A.; TUTSCHKU, K.; TRAN-GIA, P.; ANDERSEN, T.;
MEER, H,; DEDINSKI, I. Comparison of Crawling Strategies for an
Optimized Mobile P2P Architecture. Ser publicado na 19th International
Teletraffic Congress (ITC19), Beijing, China, September 2005. Disponvel em:
<http://www3.informatik.uni-wuerzburg.de/staff/hossfeld/>Acesso em: agosto de
2005.
[40] Forum Nokia. Multiplayer Game Performance over Cellular Networks
[41] BANSAL, V.; DALTON, A. A Performance Analysis of Web Services on
Wireless PDAs
[42] TUNEMBAUM, A. S. Redes de computadores. Traduo 3 edio, editora
campus. p. 463 467.
[43] Theoretical Maximum Throughput of IEEE 802.11 and its Applications
[44] CMARA, J . M. O. Redes sem fio metropolitanas baseadas no padro 802.16:
um estudo de caso para Belm. 2005. p.12 49. Dissertao para obteno do
grau de mestre em cincias em engenharia de sistemas e computao -
Universidade Federal do Rio de J aneiro.
[45] J NIOR, P. D. M. Modelagem e anlise de um protocolo de acesso alternativo
para o padro IEEE 802.16 de redes metropolitanas sem fio. Abril de 2005.
p.12 49. Monografia (Trabalho de concluso de curso em cincia da computao)
- Universidade Federal do Par.
104

[46] KOTILANINEN, N. Mobile Chedar A Peer-to-Peer Middleware for Mobile
Devices. Maro de 2005. Apresentao para o workshop internacional em
MP2P05 (Mobile Peer-to-Peer Computing).
[47] BILLO, E. A. Uma pilha de protocolos Bluetooth adaptvel aplicao.
Fevereiro de 2003. p. 13 14.Monografia (Trabalho de concluso de curso em
cincia da computao) - Universidade Federal de Santa Catarina.



105

Apndice A Glossrio

802.11b Padro de conexo wireless, nomeado comercialmente como
Wi-Fi, que utiliza freqncia de 2.4 Ghz (aproximadamente)
tendo uma velocidade de 11 Mbps, e uma Cobertura Nominal de
100m.

3GPP Third Generation Partneship Project.

Ad-hoc Tipo de configurao da camada de rede para realizar
comunicao entre as estaes de trabalho diretamente, sem a
necessidade de um ponto de acesso (AP) e de uma rede fsica
para conectar as estaes.

API Application Programming Interface.

Aplicao P2P-Mvel Aplicao que utiliza o conceito P2P (realiza, em algum
momento, a comunicao direta entre peers) e executada em
um dispositivo mvel.

Bluetooth Conexo via rdio freqncia com alcance de 10m, utilizados
para conexes em uma PAN, tal como interconectar PDAs,
celulares, etc.

CHEDAR CHEap Distributed ARchitecture

CLDC Connected Limited Device Configuration.

Downlink Termo tcnico usado para definir a transmisso de dados na
seqncia rede/operadora ou provedor de servio/Internet ao
usurio.

DRM Digital Rights Management
.
DTD Document Type Declaration.

EDGE Enhanced Data rates for Global Evolution

Firewall Software para gerenciamento de entrada e sada de informaes
pela rede.

GGSN General Packet Radio Service.

GPRS General Packet Radio Service.

Hot Spots Pontos de acesso pblico, que utilizam um Acces Point para
fornecer a distribuio de sinal.

HTTP HyperText Transfer Protocol

106

Infra-estrutura Sistema de Conexo Wireless baseado em acesso de vrios
clientes a um ponto de acesso, que gerencia as informaes da
rede com toda a politica de diretrizes e segurana Cabvel.

Infrared Conexo que utiliza raios infravermelhos para transmisso de
dados. Apesar de barata, uma conexo bem lenta. Encontrado
comumente em controles remotos, PDAs ,etc.

IP Internet Protocol.

ISDN Integrated Services Digital Network

J 2ME Java 2 Micro Edition.

J 2SE Java 2 Platform, Standard Edition

J XTA Plataforma para desenvolvimento de aplicaes P2P.

J XME Extenso de J XTA que permite o desenvolvimento de
aplicaes P2P para dispositivos mveis.

LAN Local Area NetWork.

MAC Address Endereo Fsico de um componente de rede (como Access Point
e Placa de rede ) que nico e imutvel.

MANET mobile ad-hoc networks

MIDP Mobile Information Device Profile.

MMS Multimedia Messaging System

MS Mobile Station, ou estao mvel.

MSISDN Mobile Station ISDN o nmero que permite realizar um
conjunto de chamadas para um assinante correspondente. Um
assinante pode ter vrios MSISDNs, correspondentes a
diferentes servios.

MTU Maximum Transmission Units

NAT Network Address Translation.

PAN Personal Area Network. Prove acesso aos aparelhos proximos
ao utilizador como celulares, PDAs, notebooks entre outros.

PDA Personal Digital Assistant. Termo que designa pequenos
aparelhos de mo, ou palm tops, com funcionalidade de
computador. Alguns lanamentos incorporam celulares - e estes
a funcionalidade de um PDA.
107


Piconet Micro-redes de dispositivos. um termo utilizado na tecnologia
Bluetooth, onde os dispositivos que esto prximos uns dos
outros automaticamente estabelecem contato entre si, formando
pequenas redes.

RDF Resource Description Framework.
Ponto de Acesso Conhecido no ingls por Acces Point, sendo responsvel por
distribuir uma banda de conexo wireless em um ambiente.

QoS Quality of Service

Rede P2P-Mvel Rede P2P que permitem a existncia e participao de peers
mveis.

SuperWaba Plataforma para desenvolvimento de software para aplicaes
cujo alvo so os PDAs.

SIP Session Iniciation Protocol

SMS Short Messaging Service.

TCP Transmission Control Protocol

UMTS Universal Mobile Telecommunications System.

Uplink Termo tcnico para a transmisso de dados no sentido do
usurio para a rede ou provedor de servio da Internet. Tambm
designado por canal de retorno.

UTRAN Terrestrial Radio Access Network.

UWB Ultra Wide Band. Esta uma tecnologia de transmisso de
dados sem fio que ao invs de operarem numa freqncia fixa,
os transmissores UWB utilizam um nmero quase infinito de
freqncias entre 0 e 60 GHz, sem permanecer em uma nica
freqncia por mais do que algumas fraes de segundo. Apenas
as duas partes envolvidas conhecem o padro de freqncias
utilizado, o que ajuda a manter a segurana dos dados. Tem a
capacidade de transmitir dados at 500Kbps, mas com um
alcance de apenas 10 metros.

WAN Wide Area Network. Rede Para utilizao em prdios
corporativos e interligaes no prximas fisicamente, mas no
to distantes como a WMAN.

WAP Wireless Aplications Protocol

108

Wi-Fi Conexo sem fio, tambm conhecido como 802.11, que trabalha
em freqncias de rdios para transportar dados. Velocidade,
cobertura nominal e freqncia variam de acordo com o padro.

WiMax Worldwide Interoperability for Microwave Access. o padro
802.16 com alcance de at 40Km, possibilitando taxas de
transferncia de at 75Mbps.

WLAN Wireless Local Area Network. Rede interna para uso, na maioria
das vezes, domstica.Conhecida tambm como Rede local.

WMAN Wireless Metropolitan Area Network. Rede externa de uso
pblico em acesso as grandes metrpoles e centros urbanos.

XHTML Extensible HyperText Markup Language.

XML Extensible Markup Language

XPath XML Path Language

ZigBee Tem como proposta tornar-se padro wireless de baixo consumo
e curto alcance para monitorao e automao de aplicaes
industriais, comerciais ou urbanas, sua taxa de transferncia de
200Kbps e tem o alcance de 75m.




109