Luciana dos Santos Lima Um Protocolo para Descoberta e Seleção ...

Luciana dos Santos Lima
Um Protocolo para Descoberta
e Seleção de Recursos em
Grades Móveis Ad hoc
TESE DE DOUTORADO
DEPARTAMENTO DE INFORMÁTICA
Programa de Pós-Graduação em Informática
Rio de Janeiro
Junho de 2007

Luciana dos Santos Lima
Um Protocolo para Descoberta e Seleção
de Recursos em Grades Móveis Ad hoc
Tese de Doutorado
Tese apresentada como requisito parcial para
obtenção do título de Doutor pelo Programa de Pós-
Graduação em Informática da PUC-Rio.
Orientador: Markus Endler
Co-orientadores: Luiz Fernando Gomes Soares
Antônio Tadeu Azevedo Gomes
Artur Ziviani
Rio de Janeiro, junho de 2007

Luciana dos Santos Lima
Um Protocolo para Descoberta e Seleção
de Recursos em Grades Móveis Ad hoc
Tese apresentada como requisito parcial para obtenção
do título de Doutor pelo Programa de Pós-Graduação em
Informática da PUC-Rio. Aprovada pela Comissão
Examinadora abaixo assinada.
Markus Endler
Orientador
PUC-Rio
Luiz Fernando Gomes Soares
Co-orientador
PUC-Rio
Antônio Tadeu Azevedo Gomes
Co-orientador
LNCC
Artur Ziviani
Co-orientador
LNCC
Antonio Alfredo Ferreira Loureiro
UFMG
José Ferreira de Rezende
UFRJ
Renato Fontoura de Gusmão Cerqueira
PUC-Rio
Sérgio Colcher
PUC-Rio
José Eugenio Leal
Coordenador Setorial do Centro Técnico Científico - PUC-Rio
Rio de Janeiro, 15 de junho de 2007

Todos os direitos reservados. É proibida a reprodução total ou
parcial do trabalho sem autorização da universidade, da autora
e do orientador.
Luciana dos Santos Lima
Graduou-se em Ciência da Computação na UFAL
(Universidade Federal de Alagoas) em 1999. Especializou-se
em Tecnologia da Informação no TCI/UFAL em 2000. Obteve
o título de Mestre em Informática, pela PUC-Rio, em 2002. É
pesquisadora na área de Redes de Computadores e Sistemas
Distribuídos, com ênfase em redes sem fio, descoberta de
serviços, colaboração móvel e grades móveis. Desenvolveu
pesquisas por dois anos em projetos na área de grades móveis
no Laboratório Nacional de Computação Científica e
atualmente está afiliada ao Laboratório Tecgraf/PUC-Rio.
Lima, Luciana dos Santos
Ficha Catalográfica
Um protocolo para descoberta e seleção de recursos
em grades móveis ad hoc / Luciana dos Santos Lima;
orientador: Markus Endler; co-orientadores: Luiz Fernando
Gomes Soares, Antônio Tadeu Azevedo Gomes, Artur
Ziviani. – 2007.
213 f. : il. (col.) ; 30 cm
Tese (Doutorado em Informática) – Pontifícia
Universidade Católica do Rio de Janeiro, Rio de Janeiro,
2007.
Inclui referências bibliográficas.
1. Informática – Teses. 2. Descoberta de recursos. 3.
Seleção de recursos. 4. Grades móveis. 5. Redes sem fio.
I. Endler, Markus. II. Soares, Luiz Fernando Gomes. III.
Gomes, Antônio Tadeu Azevedo. IV. Ziviani, Artur. V.
Pontifícia Universidade Católica do Rio de Janeiro.
Departamento de Informárica. VI. Título.
CDD: 004

Este trabalho é dedicado
a Deus, que, há muitos anos, fez-me uma promessa, a
mim e a todos os Seus filhos, promessa essa que vem se
cumprindo em minha vida:
“Ele (o filho de Deus) é como árvore plantada junto a
corrente de águas, que, no devido tempo, dá o seu fruto,
e cuja folhagem não murcha; e tudo quanto ele faz será
bem sucedido.” [Sl, 1:3]
Ao meu Senhor e Salvador a minha gratidão eterna:
“Graças te dou, visto que por um modo
assombrosamente maravilhoso me formaste; as tuas
obras são admiráveis, e a minha alma o sabe muito
bem;” [Sl, 139:14]
Luciana Lima

Agradecimentos
Ao meu orientador, Markus Endler, por ter me acolhido como sua orientanda, pela
sua disponibilidade e boa vontade, qualidades essenciais em um orientador.
Agradeço por ter me dado liberdade para crescer como pesquisadora e me
incentivado a percorrer o caminho árduo e, por vezes, doloroso de definição de
um tema de tese. Obrigada pelo respeito com que lapidou as minhas idéias e pela
confiança em mim depositada: respeito e confiança, características que nortearam
esses quatro anos de convivência.
Ao meu eterno “ori” e atual “co-ori”, Luiz Fernando Gomes Soares, o meu
agradecimento sincero. Você foi fundamental na construção da minha carreira
acadêmica, responsável pelo “alicerce” sobre o qual, com este trabalho, deposito
mais alguns “tijolinhos”. Existe um pouco de você em tudo o que sou hoje como
pesquisadora. Tomei para mim a sua disciplina, responsabilidade e
perfeccionismo. Tive lições inesquecíveis como sua orientanda de mestrado, não
só do profissional que você é, mas também do ser humano que consegue nos
surpreender com demonstrações de desprendimento e amor ao próximo. Levarei,
por toda a vida, os seus ensinamentos preciosos. Muito Obrigada!
Aos meus co-orientadores, Antônio Tadeu e Artur Ziviani, meu reconhecimento
sincero. Tive a oportunidade de conviver de perto durante esses últimos dois anos
com esses pesquisadores incríveis. Completamente apaixonados pelo “fazer
ciência”, motivados e meus principais motivadores, os verdadeiros “culpados”
pela conclusão do meu doutorado. Agradeço de coração por tudo que pude
aprender com vocês. Espero continuar a minha caminhada contando com a
colaboração e a parceria que construímos ao longo desse período.
Ao professor, Bruno Schulze, que esteve conosco no início deste trabalho,
contribuindo com o seu conhecimento e abrindo as portas para que pudéssemos
utilizar a grade fixa do ComCiDis (http://comcidis.lncc.br/), projeto por ele

coordenado, o meu agradecimento sincero.
Aos bolsistas de Iniciação Científica PIBIC do LNCC, Bruno Bastos e Pedro
Alcover, o meu muitíssimo obrigada! Em pouco mais de um ano e meio de
convivência científica, esses dois “meninos” contribuíram, e muito, para a
realização deste trabalho. Bruno desvendando os “mistérios” do Globus Toolkit e
viabilizando a integração das soluções, aqui propostas, para as grades móveis,
com a grade fixa do projeto ComCiDis. Pedro estudando os simuladores
escolhidos para realizar a avaliação de desempenho deste trabalho. Fico
extremamente feliz de ver o quanto vocês evoluíram nesse período e o excelente
trabalho que desenvolveram. Mais uma vez, obrigada de coração.
Aos colaboradores franceses, Nicolas Bolicaut e Guillaume Chelius, o meu muito
obrigada! Ao Nicolas, gostaria de agradecer pela receptividade que demonstrou
nos testes que desenvolvemos juntos no testbed do INRIA/INSA-Lyon. Ao
Guillaume, por ter discutido conosco os aspectos que envolvem os mecanismos de
difusão em uma rede sem fio ad hoc de saltos múltiplos.
Antes dos agradecimentos, gostaria de render uma homenagem à banca de
avaliação desta tese, constituída pelos Professores Antonio Loureiro, José
Rezende, Renato Cerqueira, Sérgio Colcher e pelas suplentes Noemi Rodriguez e
Simone Martins. Durante o desenvolvimento da minha vida acadêmica, pude
acompanhar o trabalho que cada um de vocês vem construindo em suas
respectivas áreas de pesquisa. É, para mim, motivo de orgulho saber que a
contribuição de cada um de vocês estará depositada nas páginas deste trabalho.
Muito obrigada por vocês terem aceitado participar da minha defesa de doutorado.
Agradeço a compreensão e o apoio incondicional de minha mãe, Maria José, e de
minhas irmãs queridas, Adriana e Nathalie. Vocês conhecem o meu coração
melhor do que eu mesma e por isso mesmo devem saber o quanto as amo e a
importância que vocês têm em minha vida. Em momento algum vocês duvidaram
de que eu concluiria, com êxito, o meu doutorado, mesmo quando eu,
desacreditada do meu trabalho, pensei em desistir. Obrigada, vocês são a melhor
família que alguém poderia sonhar em ter. Aproveito para registrar o carinho com

que as minhas “maninhas” revisaram o meu texto, em busca de “erros do meu
português ruim” – como diria Roberto Carlos – na verdade, não tão ruim assim ;-)
Na conclusão dessa etapa tão importante da minha vida, não poderia deixar de
registrar o meu agradecimento ao meu amor maior, primeiro e mais importante
exemplo: meu pai, José Maria (in memorian). A vida nos separou muito cedo, mas
permitiu que eu tivesse com você a mais importante lição: ser uma pessoa
honesta, independentemente das circunstâncias, e lutar sempre, com muita
vontade e determinação, por tudo o que se quer. Desde que você se foi, vivo
angustiada com a idéia de não ter te dito, suficientemente e repetidas vezes, o
quanto eu te amo. Registro aqui, para todo o sempre, o meu amor incondicional
por você, o homem mais íntegro e generoso que já conheci.
Nada mais justo do que registrar o meu agradecimento especial a Maíra Greco, a
Déborah de Barros e à Profª. Simone Junqueira. Em um momento de muita
dificuldade, decidi abandonar o doutorado, foi um período muito doloroso, e essas
três pessoas se preocuparam comigo e me confortaram, dedicando um pouco do
seu tempo a me incentivar e encorajar, não permitindo que eu concluísse o meu
intento. Obrigada de coração pelo que vocês representaram para mim naqueles
momentos tão difíceis.
Para tornar real um grande sonho, é preciso o apoio e amor de pessoas muito
especiais, que, por afinidade, unem-se a você durante essa longa caminhada que
chamamos de “vida”. Esses são os nossos amigos, a família que temos a liberdade
de escolher para compartilhar conosco as nossas dores e alegrias. Moreno e
Lorenza, amo vocês, eu os considero como verdadeiros irmãos e admiro
profundamente a relação de amor e respeito que vocês construíram. Obrigada por
todo o afeto que vocês me dedicaram. Lucimar, Maíra (novamente ela!), Paulinha,
Taci e Vivi – em ordem alfabética para não criar problemas :-) –, minhas amigas
queridas, o que dizer de vocês Sempre presentes nesses sete anos de Rio de
Janeiro, tanta coisa aconteceu e, com fé em Deus, permaneceremos unidas nas
tantas “aventuras” que ainda hão de vir. Obrigada a vocês pela nossa amizade.
Adéle, quando a mente já não dava conta do trabalho a cumprir, você era a minha
companheira de descontração, juntas seguíamos animadas até o Rio Scenarium,

um sentimento especial de afinidade nos uniu, sou grata por na reta final do meu
doutorado termos estreitado os nossos laços de amizade.
O maior presente que já “ganhei” através da Internet foi um amigo. É verdade, em
uma lista de discussão técnica sobre o protocolo IP Móvel, na época, idos de
1999, tema do meu trabalho de conclusão de curso da graduação em Ciência da
Computação na Universidade Federal de Alagoas. Emmanuel Coelho Alves, um
francês que hoje reside na China, um amigo ao mesmo tempo tão distante e tão
próximo. Pude contar com o seu apoio nesses oito anos de amizade, recheados de
demonstrações constantes de solidariedade. Devoto a você um sentimento sincero
de gratidão, pois nos momentos mais difíceis da minha vida, apesar de nunca
termos tido sequer um encontro real, você sempre esteve presente, dando
conselhos, incentivo e me fortalecendo com as suas palavras e atitudes. Como
amigos também dizem “eu te amo”, registro aqui o meu amor phileo por você.
Durante o meu doutorado, pude contar com o apoio material e humano daqueles
que fazem o laboratório Tecgraf. Gostaria de agradecer ao meu coordenador de
projeto, Alberto Raposo, pela oportunidade que ele me concedeu. Obrigada
também aos meus companheiros de trabalho, Cezar Pozzer, Eduardo Teles e Börje
Karlsson. Pude aprender e me divertir muito com vocês, não vou esquecer os
nossos almoços no Bandejão da PUC (meu prato só perdia para o do Pozzer!) e as
sessões de XP. O meu agradecimento também a toda equipe do grupo de VR, é
muito bom fazer parte desse time. Não poderia deixar de registrar, aqui, o meu
carinho a uma pessoa muito especial, Sr. Ernesto Fleck. Obrigada por
compartilhar comigo a sua sabedoria e pela “adoção”, afinal, como o Senhor
mesmo sempre brinca – e eu levo a sério! –, eu sou a sua filha mais velha, sei que
a minha conquista é motivo de orgulho para o Senhor. Mais uma vez, obrigada!
Eu simplesmente fugia de qualquer tipo de atividade física até que, em plena reta
final da escrita da minha dissertação de mestrado, diagnosticada com LER (Lesão
por Esforço Repetitivo), fui obrigada a praticar algum tipo de atividade física.
Entrei na Gávea Gym e acabei simplesmente “viciada”. Gostaria de agradecer a
todos os profissionais da GG, que sempre tão cuidadosos, ajudam a colocar o meu
corpo em ordem quando, nem sempre, a minha mente está. E foi lá na GG

também que travei o primeiro contato com o Yôga – metodologia estritamente
prática que conduz ao samádhi, o estado de hiperconsciência e megalucidez que
só o Yôga proporciona. Registro, aqui, o meu pújá efetivo aos mestres de Yôga
que tive: Vinícius, Humberto e Rafaella, claro, como não poderia deixar de ser, o
meu pújá ao mestre DeRose, responsável pelo resgate das raízes ancestrais do
Yôga que hoje pratico. Saúdo a você com o nome do nosso Yôga: Swásthya!
Agradeço ao Posto 10 (Country Club) por ter se firmado, durante esses quatro
anos de doutorado, como o meu melhor ambiente de trabalho. Entre um sucolé do
Claudinho e um copinho de LimãoPlus (diet, é claro!), estudei para provas, li e
revisei artigos, além de ter buscado inspiração para definir vários pontos desta
tese. Pois é, além de “concentração e transpiração”, esse trabalho também traz
consigo o barulhinho das ondas do mar de Ipanema, o cheirinho de maresia e a
beleza do pôr-do-sol mais lindo do mundo, aplaudido de pé por seus fiéis
admiradores, dentre os quais me incluo.
Posso dizer que o meu doutorado teve como trilha sonora as composições do
4 Cabeça (é assim mesmo que se escreve!), em especial, do meu querido amigo,
Luis Carlinhos. LC, a sua música e o seu sorriso conseguiam um verdadeiro
milagre nos meus momentos de maior tensão: acalentar a minha alma, devolvendo
a alegria ao meu semblante e me proporcionando momentos de pura magia.
Saindo do mundo da arte e fazendo uma parada, obrigatória, no universo da
tecnologia, gostaria de agradecer ao grupo de desenvolvedores do Google, por
terem proporcionado um mecanismo de busca tão eficiente e preciso, que em
muito contribuiu, durante todo o processo de pesquisa do meu doutorado, para o
desenvolvimento desta tese.
Agradeço o apoio financeiro que recebi da PUC-Rio, através do Departamento de
Informática, pela bolsa VRAC e ao CNPq, pela bolsa PCI, concedida através de
convênio com o LNCC.

Resumo
Lima, Luciana dos Santos; Endler, Markus; Soares, Luiz Fernando Gomes;
Gomes, Antônio Tadeu Azevedo; Ziviani, Artur. Um Protocolo para
Descoberta e Seleção de Recursos em Grades Móveis Ad hoc. Rio de
Janeiro, 2007. 213p. Tese de Doutorado – Departamento de Informática,
Pontifícia Universidade Católica do Rio de Janeiro.
Nos últimos anos, o uso de dispositivos móveis em grades computacionais
tem sido alvo de crescente investigação. Entretanto, um problema mais desafiador,
referente ao estabelecimento dinâmico de grades móveis, baseadas
exclusivamente em redes sem fio ad hoc, ainda tem sido pouco investigado. Uma
contribuição desta tese é a proposta de uma arquitetura de software específica para
grades móveis, que pode ser igualmente aplicável a redes sem fio infraestruturadas
e ad hoc. Em grades fixas, a responsabilidade de prover um serviço
computacional é compartilhada entre dispositivos com relativa abundância de
recursos, se comparadas a grades móveis. Nestas últimas, é interessante que a
descoberta e a seleção de recursos para execução de tarefas sejam tratadas
conjuntamente, de modo a promover a seleção automática dos dispositivos com
maior disponibilidade de recursos, considerando-se os requisitos da aplicação.
Entretanto, tais elementos têm sido tradicionalmente tratados em separado na
literatura relacionada a grades móveis e, em grande parte das abordagens
existentes, assume-se que a seleção de recursos seja executada de forma manual
pelos usuários da grade móvel. Esta tese propõe, como uma outra contribuição,
um protocolo que integra as fases de descoberta e seleção automática de recursos
em grades móveis, permitindo que a provisão de serviços computacionais seja
escalonada entre os dispositivos com maior disponibilidade dos recursos
requeridos pelo serviço. Devido à característica dinâmica dos recursos que
correspondem às requisições dos usuários em uma grade móvel (por exemplo,
tempo de CPU livre e memória disponível), o protocolo baseia-se unicamente no
envio, sob demanda, de requisições via broadcast. No entanto, principalmente em
redes sem fio ad hoc de saltos múltiplos, essa estratégia pode acarretar uma
sobrecarga nos dispositivos envolvidos, tanto na difusão de requisições quanto no
encaminhamento de respostas. Uma terceira contribuição desta tese é o
desenvolvimento de um mecanismo que permite reduzir a sobrecarga, devido à
difusão de mensagens de resposta, por meio da supressão de respostas excedentes

ao longo da rede. O mecanismo, embora implementado no contexto do protocolo
proposto nesta tese, pode ser aplicado também a outros protocolos de descoberta
baseados no envio de requisições via broadcast. Os resultados experimentais,
obtidos em redes de testes e em plataformas de simulação, mostram que o
protocolo proposto provê um balanceamento de carga eficiente entre os
dispositivos, mediante o aumento do número de requisições. Além disso, pode-se
observar que o mecanismo de supressão de respostas é escalável no que diz
respeito ao crescimento do número de dispositivos, em comparação com
protocolos de descoberta baseados puramente no envio de requisições por
broadcast em redes sem fio ad hoc.
Palavras-chave
Fio.
Descoberta de Recursos; Seleção de Recursos; Grades Móveis; Redes Sem

Abstract
Lima, Luciana dos Santos; Endler, Markus; Soares, Luiz Fernando Gomes;
Gomes, Antônio Tadeu Azevedo; Ziviani, Artur. A Protocol for Resource
Discovery and Selection in Mobile Ad hoc Grids. Rio de Janeiro, 2007.
213p. PhD Thesis – Departamento de Informática, Pontifícia Universidade
Católica do Rio de Janeiro.
In the last few years, the use of mobile devices in computational grids has
seen a growing interest. Nevertheless, a more challenging issue, the dynamic
establishment of mobile grids on wireless ad hoc networks, has been so far only
partially addressed. The first contribution of this thesis is the proposal of a
software architecture for mobile grids that can be used for both infrastructured and
ad hoc wireless networks. In the execution of conventional applications in grids,
the responsibility to provide the service is shared among the most resourceful
mobile devices. In mobile grids, it is fundamental that resource discovery and
selection of resources are jointly handled. This calls for a mechanism that
promotes the automatic selection of the best resource providers amongst the
discovered nodes, taking into account the requirements of the application.
Discovery and selection, however, have been traditionally handled separately and
in most approaches the selection of resources and services requires explicit
intervention by the user of the mobile grid. As a second contribution of this thesis,
we propose a protocol that integrates the phases of resource discovery and
automatic selection in mobile grids, allowing that computational resource
provisioning is scheduled among the most resourceful nodes. Due to the dynamics
of the resources needed in a mobile grid (for example, free CPU time and
available memory), the protocol is based solely on demand-driven broadcasts.
However, mainly in multihop ad hoc wireless networks, this strategy can incur in
overhead at the involved devices, due to the diffusion of requests and replies. A
third contribution of this thesis is the development of a mechanism that allows to
reduce this overhead by means of the suppression of redundant replies in the
network. The mechanism has been implemented in the context of the proposal
protocol, but can be applied as well to other query-based discovery protocols
based on broadcasts. The experimental results obtained from executions in a
testbed and through simulations show that the proposed protocol provides
efficient load balancing between devices with an increasing number of requests.

Moreover, it can be observed that the mechanism for suppression of replies scales
well with respect to an increasing number of devices when compared to other
discovery protocols in wireless ad hoc networks that are purely based on requests
via broadcast.
Keywords
Resource Discovery; Resource Selection; Mobile Grids; Wireless Networks.

Sumário
1 Introdução 24
1.1. Motivação 24
1.2. Requisitos para a Descoberta de Serviços em Grades Móveis
ad hoc 26
1.3. Objetivos 30
1.4. Sumário das Principais Contribuições 32
1.5. Organização da Tese 33
2 A Arquitetura MoGrid 36
2.1. Introdução 36
2.2. Modelo de Serviços da Arquitetura MoGrid 37
2.3. Um Middleware para Grades Móveis 40
2.3.1. Camada de Descoberta P2P 41
2.3.1.1. API de Descoberta 41
2.3.1.2. Entidades de Descoberta 44
2.3.2. Camada de Transparência 47
2.3.2.1. Subcamada de Acesso Transparente aos Recursos 48
2.3.2.2. Requisitos da Camada de Acesso Transparente aos Recursos 51
2.3.2.3. Subcamadas de Adaptação 55
2.4. Os Modelos de Falhas da Arquitetura MoGrid 56
2.5. Trabalhos Relacionados 60
2.5.1. Discussão sobre os Trabalhos Relacionados 62
2.5.2. Análise Comparativa 66
2.5.3. Contribuições Alcançadas 70
3 Trabalhos Relacionados à Descoberta de Serviços 72
3.1. Apresentação 72
3.2. Classificação dos Protocolos de Descoberta de Serviços 74
3.2.1. Os Mecanismos de Descoberta de Serviços 80

3.2.1.1. Descoberta Passiva 81
3.2.1.2. Descoberta Ativa 85
3.2.2. O Mecanismo de Seleção de Serviços 89
3.2.3. Mecanismos para oferecer suporte à Mobilidade 91
3.3. Visão Geral dos Protocolos de Descoberta de Serviços 95
3.4. Resumo Comparativo dos Protocolos de Descoberta de Serviços
para MANETs 97
4 O Protocolo P2PDP 100
4.1. Introdução 100
4.2. Suposições a Respeito do Sistema 103
4.3. Visão Geral do Protocolo P2PDP 104
4.4. Classificação do Protocolo P2PDP 105
4.5. Funcionamento do Protocolo P2PDP 110
4.6. O Algoritmo de Supressão de Respostas 115
4.7. O Algoritmo para o Cálculo do Retardo no Envio de Respostas 121
4.8. O Mecanismo para o Reconhecimento do Envio de Respostas 124
4.9. Análise Comparativa do Protocolo P2PDP 128
5 Implementação 135
5.1. Tecnologias Utilizadas 135
5.2. Implementação do Protocolo P2PDP 137
5.2.1. Descrição de Recursos e Controle de Admissão 138
5.2.2. Mensagens de Controle P2PDP 138
5.2.3. Canal de Comunicação P2PDP 139
5.2.4. Entidades de Descoberta P2PDP 140
5.2.5. Cenários de Uso 144
5.3. Integração do MoGrid com o Globus Toolkit 145
5.3.1. O Globus Toolkit 145
5.3.2. Requisições de Descoberta P2PDP em uma Grade Globus 146
5.3.3. Monitoramento de Recursos em uma Grade Globus 148
5.3.4. Controle de Admissão em uma Grade Globus 149
5.3.5. Implementação do Proxy de Colaboração 150
5.4. Aplicações de Teste 152

5.4.1. Ambientes de Teste Reais 154
5.4.2. Ambiente de Teste Simulado 156
6 Avaliação de Desempenho 161
6.1. Cenários de Simulação e Métricas de Avaliação 161
6.2. Análise de Escalabilidade 165
6.2.1. Análise da Influência do P2PDP na Carga Média da MANET 168
6.2.2. Análise do Mecanismo de Supressão de Respostas do P2PDP 174
6.2.3. Visão Geral da Análise de Escalabilidade 180
6.3. Controle da Ocorrência de Colisões 181
6.4. Balanceamento de Carga 182
6.5. Visão Geral dos Resultados Obtidos 185
6.6. Avaliação do P2PDP na Presença de Mobilidade 185
6.6.1. Composição dos Cenários 186
6.6.2. Métrica de Avaliação 187
6.6.3. Resultados Obtidos 188
7 Conclusões 191
7.1. Contribuições da Tese 191
7.1.1. Contribuições para o Estado da Arte 192
7.1.2. Contribuições Tecnológicas 194
7.2. Trabalhos Futuros 195
7.2.1. Arquitetura MoGrid 195
7.2.2. Incorporação de Novos Mecanismos ao Protocolo P2PDP 196
7.2.3. Otimização de Mecanismos do Protocolo P2PDP 199
7.3. Considerações Finais 201
8 Referências Bibliográficas 202
A Apêndice 210
A.1. Detalhes sobre o Ambiente de Simulação NCTUns 210
A.2. Gráficos Complementares referentes à Análise da Influência do
P2PDP na Carga Média da MANET 211

Lista de Figuras
Figura 1 – Formação de uma grade móvel pela proximidade
geográfica dos dispositivos. 26
Figura 2 – Arquitetura MoGrid. 40
Figura 3 – API de descoberta. 41
Figura 4 – Estrutura do parâmetro serviceDescriptor. 42
Figura 5 – Entidades envolvidas no processo de descoberta. 44
Figura 6 – Arquitetura MoGrid: a camada de transparência. 48
Figura 7 – Mecanismos de descoberta de serviços. 81
Figura 8 – Mecanismo de anúncio incremental do Konark. 82
Figura 9 – Encaminhamento de requisições baseado em grupos de
serviços (adaptada de [Strang 2005]). 87
Figura 10 – Critérios de seleção de serviços. 90
Figura 11 – Métodos de provisão de suporte à mobilidade. 93
Figura 12 – Funcionamento básico do protocolo P2PDP em uma
MANET. 110
Figura 13 – Mensagem InitiatorRequest (IReq). 111
Figura 14 – Representação ASN.1 da mensagem
InitiatorRequest (IReq). 112
Figura 15 – Estrutura de dados pendingList. 112
Figura 16 – Representação ASN.1 da estrutura de dados
pendingList. 113
Figura 17 – Mensagem CollaboratorReply (CRep). 114
Figura 18 – Representação ASN.1 da mensagem
CollaboratorReply (CRep). 114
Figura 19 – Estrutura de dados resumeList. 115
Figura 20 – Representação ASN.1 da estrutura de dados
resumeList. 115
Figura 21 – O algoritmo de supressão de respostas por vizinhança
SbV. 116
Figura 22 – Cenário ilustrando a supressão de mensagens CRep

com o algoritmo SbV. 119
Figura 23 – Propagação em eco de mensagens CRep pelo
protocolo P2PDP. 125
Figura 24 – O algoritmo de tratamento de requisições. 126
Figura 25 – O algoritmo de reconhecimento de envio de respostas. 127
Figura 26 – O proxy de colaboração MoGrid. 137
Figura 27 – Descrição de recursos e controle de admissão. 138
Figura 28 – Declaração das mensagens de controle P2PDP. 139
Figura 29 – Canal de comunicação P2PDP. 140
Figura 30 – Entidades iniciador e coordenador e a subcamada de
adaptação. 141
Figura 31 – Entidade colaborador. 142
Figura 32 – Seqüência de invocação de operações associadas à
descoberta de serviço. 144
Figura 33 – Seqüência de invocação de operações associadas à
recepção de uma requisição de serviço no colaborador. 144
Figura 34 – Mensagem CollaboratorReply (CRep) modificada. 148
Figura 35 – Entidade proxy de colaboração. 151
Figura 36 – Seqüência de invocação de operações associadas à
recepção de uma requisição de serviço no proxy de colaboração. 151
Figura 37 – Exemplo de rodada de simulação do protocolo P2PDP. 157
Figura 38 – Rodada de simulação NCTUns com mobilidade. 160
Figura 39 – P2PDP: cenário de uso favorável. 162
Figura 40 – P2PDP: cenário de uso desfavorável. 163
Figura 41 – Carga na MANET para 20% de colaboradores ativos (p). 170
Figura 42 – Carga na MANET para 40% de colaboradores ativos (p). 171
Figura 43 – Carga na MANET para 60% de colaboradores ativos (p). 171
Figura 44 – Carga na MANET para 80% de colaboradores ativos (p). 172
Figura 45 – Eficiência da descoberta de serviços (extraída de
[Lee et al. 2003]). 173
Figura 46 – Número médio de supressões para R=4 e N=60. 175
Figura 47 – Número médio de supressões para R=4 e N=120. 175
Figura 48 – Número médio de supressões para R=4 e N=240. 176

Figura 49 – Distribuição das supressões de mensagens de resposta
para N=60. 177
Figura 50 – Distribuição das supressões de mensagens de resposta
para N=120. 178
Figura 51 – Distribuição das supressões de mensagens de resposta
para N=240. 179
Figura 52 – Carga cumulativa do uso da CPU nos nós colaboradores. 184
Figura 53 – Exemplo de distribuição inicial dos dispositivos em um
cenário móvel. 187
Figura 54 – Eficiência da descoberta: percentual de respostas
recebidas em função do número de respostas solicitadas. 190
Figura 55 – Carga na MANET para 20% de colaboradores ativos (p). 211
Figura 56 – Carga na MANET para 40% de colaboradores ativos (p). 212
Figura 57 – Carga na MANET para 60% de colaboradores ativos (p). 212
Figura 58 – Carga na MANET para 80% de colaboradores ativos (p). 213

Lista de Tabelas
Tabela 1 – Resumo comparativo dos projetos relacionados à
arquitetura MoGrid. 69
Tabela 2 – Resumo comparativo dos protocolos de descoberta de
serviços para redes sem fio. 98
Tabela 3 – Resumo comparativo entre o protocolo P2PDP e os
protocolos de descoberta de serviços para MANETS de saltos
múltiplos. 130
Tabela 4 – Parâmetros de simulação NCTUns sem contemplar
mobilidade. 157
Tabela 5 – Parâmetros de simulação NCTUns contemplando a
mobilidade. 159
Tabela 6 – Parâmetros de simulação ns-2. 168
Tabela 7 – Número total de transmissões de pacotes. 169
Tabela 8 – Número médio de supressões para p=20 e p=60
com N=60. 177
Tabela 9 – Número médio de supressões para p=20 e p=60
com N=120. 178
Tabela 10 – Número médio de supressões para p=40 e p=80
com N=240. 179
Tabela 11 – Parâmetros de simulação dos cenários com mobilidade. 187
Tabela 12 – Eficiência da descoberta em função da velocidade de
deslocamento. 188

Lista de Acrônimos
AKOGRIMO
ALLIA
AODV
API
ARES
ASA
ASL
ASN.1
AWK
BEB
Bluetooth
Bluetooth SDP
CBRP
CDC/PP
CLDC
CoG
COLOMBA
CoS
DARC*
DEAPspace
DNS
DR
DSR
FDC
FTA
GIIS
Access to KnOwledge through the GRId in a MObile world
Do termo inglês “allia-nce”.
Ad hoc On-demand Distance Vector
Application Programming Interface
Architectures de RésEaux de Services
Audio Sharing Application
Adaptation SubLayers
Abstract Syntax Notation One
Aho, Weinberger, Kernighan
O acrônimo corresponde as iniciais dos nomes de seus inventores.
Binary Exponential Back-off
Do dinamarquês, Blåtand (Blue Tooth em inglês)
Harald “Blåtand” Gormson, rei dinamarquês (940 a 985 D.C.) que
unificou os reinos da Dinamarca e da Noruega. Esse viking era
conhecido pela sua diplomacia e capacidade de negociação. O logo
do Bluetooth foi inspirado nas letras H e B do alfabeto rúnico
[Bluetooth 2003].
Bluetooth Service Discovery Protocol
Cluster Based Routing Protocol
Connected Device Configuration/Personal Profile
Connected Limited Device Configuration
Commodity Grid
Context and Location-based Middleware for Binding Adaptation
Capacity of Service
Distributed Ad Hoc Resource Coordination
Pronuncia-se “dark star”.
Distributed Embedded Application Platform space
Domain Name System
Delayed Replies
Dynamic Source Routing
Função de Distribuição Cumulativa
Field Theoretic Approach
Grid Index Information Service

GRADEp
GRAM
GridFTP
GRIS
GSD
GSI
GTK
HTTP
IETF
INRIA
INSA
GRADE pervasiva
Globus Resource Allocation Manage
Grid File Transfer Protocol
Grid Resource Information Service
Group-based Service Discovery
Grid Security Infrastructure
Globus ToolKit
Hyper Text Transfer Protocol
Internet Engineering Task Force
Institut National de Recherche en Informatique et en Automatique
Institut Supérieur des Sciences Appliquées
IPv6 Internet Protocol version 6
ISAM
ISO
J2ME
J2SE
JINI
K*Grid
LRU
Lua
M3
MAC
MANET
MARTIN
MASGRID
MDS
MIDP
MILD
MoCA
MoGrid
NCTUns
Infra-estrutura de Suporte às Aplicações Móveis distribuídas
International Organization for Standardization
Java 2 Micro Edition
Java 2 Standard Edition
Projeto Jini da Sun.
Pronuncia-se “GEE-nee”, sua origem está relacionada à palavra
árabe que corresponde, em português, a “mágico”.
Korean national Grid
Least Recently Used
Inicialmente foi definido o acrônimo SOL (Simple Object
Language), entretanto o escopo da linguagem foi reduzido, dai veio
a inspiração; já que a linguagem seria algo menor do que o
proposto inicialmente – SOL –, porque não se chamar Lua.
Matrix-Matrix Multiplication
Medium Access Control
Mobile Ad hoc NETwork
Mechanisms and ARchitectures for TeleINformatics
Mobile Ad hoc Service GRID
Monitoring and Discovery Service
Mobile Information Device Profile
Multiplicative Increase Linear Decrease
Mobile Collaboration Architecture
Mobile Grid
National Chiao Tung University network simulator

NGG
ns
nsTOOL
OGSA
ORION
OTcl
OWL
P2P
P2PDP
PDA
QoS
RAS
RDS
RNP
RPC
RSSI
RTT
RWP
SLP
SOAP
SSDP
TCP/IP
TEP
TIMELY
TRAP
TRAS
UDP
UPnP
UUID
VAN
Wi-Fi
WLAN
WSDL
XML
Next Generation Grid
network simulator
ns dispaTcher and pOst-prOcessing Launcher
Open Grid Services Architecture
Optimized Routing Independent Overlay Network
Object Tool Command Language
Ontology Web Language
Peer-to-Peer
P2P Discovery Protocol
Personal Digital Assistant
Quality of Service
Resource Access Service (MASGRID)
Resource Discovery Service (MASGRID)
Rede Nacional de Pesquisa
Remote Procedure Call
Radio Signal Strength Indications
Round-trip Time
Random WayPoint
Service Location Protocol
Simple Object Access Protocol
Simple Service Discovery Protocol
Transmission Control Protocol/Internet Protocol
Tabela de Execuções Pendentes
The Illinois Mobile Environment LaboratorY
Transparent Resource Access Protocol
Transparent Resource Access Sublayer
User Datagram Protocol
Universal Plug and Play
Universally Unique IDentifier
Vehicular Area Networks
Wireless Fidelity
Wireless Local Area Network
Web Services Description Language
eXtensible Markup Language

1
Introdução
1.1.
Motivação
Grades computacionais são a nova tendência em computação distribuída
[Foster 2003]. Originalmente concebido como um conceito para o
compartilhamento de recursos computacionais e de comunicação entre nós fixos,
o conceito de grade tem, gradativamente, sido estendido para ambientes móveis
[KGrid 2002; Yamin et al. 2003; Akogrimo 2004; Kurkovsky et al. 2004;
McKnight et al. 2004; Litke et al. 2004; Ihsan et al 2005; Lima et al. 2005].
Existem duas abordagens principais para a integração de redes sem fio em
ambientes de grades computacionais. Na primeira abordagem, dispositivos móveis
são usados apenas como interfaces para acesso sem fio às grades fixas
convencionais [Hwang & Aravamudham 2004]. Na segunda abordagem,
dispositivos móveis atuam como elementos computacionais da grade
propriamente dita, disponibilizando os seus recursos e serviços, ou seja, esses
dispositivos são responsáveis pelo processamento compartilhado e pela execução
colaborativa de tarefas. Essa segunda abordagem, denominada nesta tese de
grades móveis, é propiciada pela tendência atual de utilização de dispositivos
móveis com capacidade de processamento e comunicação cada vez maiores, mas
cujo uso atual tem sido predominantemente pessoal.
O maior desafio colocado pelas grades móveis é o compartilhamento de
recursos dinâmicos – como capacidade de processamento e memória – dos
dispositivos móveis, considerando-se as limitações dos mesmos em termos desses
recursos e de outros recursos envolvidos – como fonte limitada de energia. Esse
compartilhamento permite que um usuário, através de seu dispositivo móvel,
possa interagir com dispositivos de outros usuários, utilizando os recursos
computacionais dinâmicos e de comunicação desses dispositivos para a execução
de tarefas complexas, que demandam maior capacidade computacional. Esse

Introdução 25
compartilhamento só é possível através da utilização de arquiteturas e protocolos
que permitam a identificação e seleção dos recursos e serviços computacionais
ofertados na grade móvel. Essa perspectiva de compartilhamento cria formas
inovadoras de utilização dos dispositivos sem fio, como, por exemplo, em
situações de emergência, com a coordenação da tomada de decisões na gestão de
crises provocadas por causas naturais – como terremotos e maremotos – ou pela
ação do homem – como em atentados terroristas de grandes dimensões –, onde
não existe uma infra-estrutura de comunicação ou a infra-estrutura existente não
está disponível. Esses exemplos ilustram a necessidade de grades móveis
[McKnight et al. 2004]. Em tais situações, o compartilhamento dos recursos
computacionais dos dispositivos móveis é crucial para que se obtenha, em tempo
hábil, formas de trabalho colaborativo, como, por exemplo, através da coleta e do
processamento automático de informações sobre grandes grupos de pessoas
feridas, de modo a promover uma melhor alocação dos recursos médicos
disponíveis [Hwang & Aravamudham 2004].
Uma condição extrema de funcionamento de grades móveis ocorre nas redes
sem fio ad hoc (Mobile Ad hoc NETworks – MANETs). Essas redes são
caracterizadas pela total ausência de infra-estrutura, onde todos os dispositivos
participantes são móveis e a topologia da rede é formada temporariamente, de
forma dinâmica e independente, com os dispositivos podendo participar ou sair da
grade móvel a qualquer momento, formando cenários de compartilhamento
temporários. Os desafios relacionados a essas redes são ainda maiores quando se
consideram cenários de saltos múltiplos. Em MANETs de saltos múltiplos, tanto a
demanda quanto a disponibilidade de serviços e recursos podem apresentar uma
alta variabilidade, em comparação com os cenários encontrados nas redes fixas e
redes sem fio infra-estruturadas. A Figura 1 ilustra a formação de uma grade
móvel ad hoc através de uma MANET de saltos múltiplos mostrando como um
grupo de dispositivos móveis, localizados em uma mesma região geográfica
[Figura 1(a)], interconectam-se. Na Figura 1(b), cada círculo tracejado representa
o alcance de transmissão do nó posicionado no seu centro.

Introdução 26
( a ) Dispositivos co-localizados ( b ) Formação de topologia temporária
Figura 1 – Formação de uma grade móvel pela proximidade geográfica dos dispositivos.
1.2.
Requisitos para a Descoberta de Serviços em Grades Móveis ad hoc
O mecanismo de descoberta de serviços é um elemento fundamental em
ambientes computacionais auto-organizáveis e, em particular, nas grades móveis
ad hoc. De uma forma geral, protocolos de descoberta de serviços viabilizam a
detecção automática de dispositivos e dos serviços oferecidos por esses
dispositivos em uma rede de computadores [Marin-Perianu et al. 2005; Mian et al.
2006]. Em outras palavras, descoberta de serviços corresponde à ação de
encontrar um provedor para um serviço requisitado. Um serviço, em uma rede,
pode ser qualquer entidade de software ou hardware que um usuário deseje
utilizar. Quando a localização do serviço solicitado é obtida – tipicamente o
endereço do provedor –, o usuário pode, posteriormente, acessá-lo para sua
utilização.
Nos ambientes de grade, os serviços são caracterizados como uma
composição de recursos computacionais altamente dinâmicos. A disponibilidade
desses recursos está sujeita a variações abruptas, como é o caso, por exemplo, da
carga de CPU, cuja distribuição é bimodal, apresentando picos de utilização, ao
longo do tempo, que variam entre carga total (100% de utilização) e valores
próximos à inatividade [Bolosky et al. 2000]. Além disso, a flutuação verificada
na disponibilidade dos recursos dinâmicos pode variar consideravelmente em
períodos curtos de tempo. Nas grades móveis, particularmente, essa característica
é agravada em função da mobilidade dos dispositivos e da sua heterogeneidade, o

Introdução 27
que se reflete na capacidade, em termos de recursos, dos mesmos. Em redes sem
fio, a taxa de mobilidade pode ser elevada e o tempo de permanência dos
dispositivos na grade é variável, caracterizando altas taxas de churn. 1 Portanto,
além da constituição dos serviços como recursos dinâmicos, típico das grades
computacionais, nas grades móveis é importante considerar também aspectos
relacionados à mobilidade dos dispositivos, que caracterizam esses ambientes
como altamente dinâmicos, onde se verifica uma flutuação constante na topologia
da rede. Devido a esses fatores, um protocolo de descoberta de recursos e serviços
para grades móveis deve ser primordialmente reativo, baseando-se no envio de
requisições sob demanda [Frank & Karl 2004].
Nesse ponto é necessário deixar claro o cenário alvo deste trabalho. A
solução aqui apresentada para a descoberta e seleção de recursos dinâmicos, em
muitos aspectos, é genérica para ambientes de grades computacionais,
considerando-se que algumas adaptações sejam feitas, entretanto, a sua
especificação foi concebida tendo como foco um ambiente para execução
distribuída de tarefas entre dispositivos sem fio, organizados de forma ad hoc em
uma grade móvel [McKnight et al. 2004; Kurkovsky et al. 2004;
Lima et al. 2005]. Esse trabalho surgiu no contexto da arquitetura MoGrid
(Mobile Grid) [Lima et al. 2005], apresentada em mais detalhes no Capítulo 2,
que foi projetada com o intuito de facilitar o desenvolvimento de aplicações de
grade para execução entre dispositivos móveis interconectados através de uma
rede sem fio. É importante ressaltar que a solução proposta nesta tese foi avaliada
somente no contexto das grades móveis.
Do que foi exposto, pode-se destacar três requisitos principais que devem
ser atendidos por um protocolo de descoberta e seleção de recursos e serviços,
especificado para uma grade móvel organizada através de uma rede sem fio ad
hoc de saltos múltiplos, conforme será discutido nos próximos parágrafos: (i)
reduzir o impacto do problema da implosão de mensagens de resposta a uma
requisição, (ii) minimizar a ocorrência de colisões provocadas pelo aumento do
tráfego de dados no enlace sem fio – em virtude da transmissão de mensagens do
1 Termo comumente empregado em redes P2P para definir a transitoriedade dos dispositivos, que

Introdução 28
protocolo de descoberta – e (iii) realizar uma distribuição uniforme das
requisições de serviço, promovendo um balanceamento de carga implícito através
da seleção dos dispositivos mais aptos.
Redução do impacto do problema da implosão de mensagens de resposta.
É comum que ocorra uma sobrecarga nos dispositivos em protocolos de
descoberta de serviços reativos, nos quais as requisições de serviço são feitas sob
demanda e dá-se uma interação direta entre clientes e provedores de serviço. Essa
sobrecarga é acarretada pela troca de mensagens de descoberta entre eles, tanto no
que diz respeito ao seu processamento quanto no aumento do consumo de energia
provocado pela sua transmissão. Como nas abordagens reativas a requisição é
propagada na rede utilizando um mecanismo de difusão por broadcast, é esperado
que os dispositivos que oferecem o serviço solicitado respondam prontamente,
provocando uma implosão de mensagens de resposta [Duffield et al. 1999]. Esse
problema é decorrente do volume potencialmente grande de respostas geradas
pelos dispositivos provedores do serviço requisitado, situação essa que se agrava
em redes de grande escala. Para aplacar os efeitos colaterais da transmissão por
difusão, é necessária a utilização de um mecanismo capaz de reduzir o tráfego de
mensagens de resposta na rede, levando em consideração o número de instâncias
de serviço solicitadas pelo dispositivo requisitante. Essa redução deve considerar a
adequação dos dispositivos respondentes em oferecer o serviço, promovendo uma
estratégia de seleção das respostas com maior qualidade ao longo da rede. A
solução para essa questão é obtida através de um mecanismo de supressão das
respostas excedentes, que atua nos nós intermediários, conforme elas são
encaminhadas na rede em direção ao dispositivo que solicitou o serviço.
Redução do número de colisões provocadas pelo aumento do tráfego de
mensagens de descoberta. A probabilidade de ocorrência de colisões pode crescer
em decorrência do aumento de tráfego no enlace sem fio, provocado pela intensa
troca de mensagens de controle – requisição e resposta – do protocolo de
descoberta entre os dispositivos móveis. Nesse cenário, é verificado um alto
índice de propagação de mensagens de requisição de descoberta na rede e, como
conseqüência, um volume potencialmente grande de respostas, caracterizando,
entram e saem do sistema a qualquer instante [Stutzbach & Rejaie 2006].

Introdução 29
respectivamente, situações típicas de inundação e implosão de mensagens, o que
provoca um aumento na probabilidade da ocorrência de colisões [Ni et al. 1999;
Duffield et al. 1999; Tseng et al. 2003]. Para reduzir o impacto do problema
descrito, além de adotar um mecanismo de supressão de respostas excedentes,
como descrito no item anterior, faz-se necessário adotar um mecanismo de retardo
programado que promova, implicitamente, um assincronismo no envio das
mensagens de controle do protocolo de descoberta, propiciando, dessa forma, a
redução do número de colisões dessas mensagens.
Balanceamento de carga em função da distribuição das requisições de
serviços. Para se obter uma distribuição uniforme de serviços entre os dispositivos
da grade móvel, com um balanceamento de carga, deve-se considerar a alocação
prévia dos recursos, efetuada através do envio de mensagens de resposta e da
utilização dos serviços. Portanto, em uma grade móvel, o escalonamento deve
adotar uma abordagem distribuída, podendo ser realizado em dois pontos
distintos: no envio das requisições por serviços ou no encaminhamento das
mensagens de respostas a essas requisições. Na primeira abordagem os
dispositivos devem trocar periodicamente informações sobre a sua disponibilidade
de recursos e serviços para que a entrega da requisição seja efetuada somente para
os dispositivos mais aptos, incorporando um mecanismo de anúncio ao protocolo
de descoberta. Essa abordagem é descartada haja vista a defesa realizada no início
desta seção por um mecanismo de descoberta exclusivamente reativo para as
grades móveis. Na segunda abordagem, cada dispositivo qualifica a sua própria
resposta em função da sua disponibilidade de recursos, ou seja, a partir do seu
conhecimento sobre os recursos disponíveis localmente, sem depender do
conhecimento da disponibilidade de recursos dos demais dispositivos da rede. Em
um cenário com tantas restrições e tamanha dinamicidade da topologia de rede, é
importante que, ao se efetuar uma requisição de serviço, possa haver uma seleção
natural das melhores respostas, isto é, dos dispositivos mais aptos a atender às
necessidades definidas na requisição. Sob a óptica desta tese, as melhores
respostas são aquelas provenientes dos dispositivos com mais recursos
disponíveis. Essas respostas são selecionadas no seu encaminhamento na rede,
sendo privilegiadas em detrimento das demais, consideradas excedentes. A
implementação do critério de seleção de respostas baseia-se na informação de

Introdução 30
contexto de cada dispositivo. Nesta tese, entende-se por contexto toda informação
que represente o estado dos dispositivos móveis, incluindo a qualidade do enlace
sem fio, carga de CPU, carga residual da bateria, memória disponível e espaço de
armazenamento em disco.
1.3.
Objetivos
O objetivo desta tese é o desenvolvimento e a avaliação de desempenho de um
protocolo de descoberta e seleção de recursos e serviços que atenda às
necessidades das grades móveis, considerando fatores como a intermitência dos
enlaces sem fio e a variação na disponibilidade dos serviços. Para tanto, o
protocolo de descoberta deve adotar uma abordagem reativa, em que os serviços
são descobertos sob demanda pelos dispositivos requisitantes, através da difusão
de mensagens de requisição, e as respostas são selecionadas enquanto são
encaminhadas da sua origem até o nó requisitante.
Nesta tese é proposta uma arquitetura descentralizada para atender a
demanda das grades móveis organizadas através de redes sem fio ad hoc. Essa
arquitetura, denominada MoGrid, foi projetada para oferecer um ambiente de
descoberta e execução de serviços, definidos como uma composição de recursos
dinâmicos, em grades móveis, promovendo a distribuição, entre os dispositivos
sem fio, da execução dos serviços requisitados, adotando uma abordagem peer-topeer
(P2P). Essa arquitetura compreende uma camada de descoberta e seleção de
recursos e serviços e uma camada de transparência que trata as questões
relacionadas à conectividade irregular da grade móvel. Durante o processo de
especificação e implementação da arquitetura MoGrid, optou-se por concentrar o
desenvolvimento desta tese na camada de descoberta e seleção de serviços, que,
por si só, já possui uma complexidade considerável.
Nesta tese, é proposto o P2PDP (Peer-to-Peer Discovery Protocol), um
novo protocolo que integra os mecanismos de descoberta e seleção de recursos e
serviços ao mecanismo de roteamento de pacotes de dados, em uma abordagem
completamente descentralizada, independente de um endereçamento de rede
explícito, operando no nível da camada de aplicação. No caso de serviços não
específicos, como ciclos de processamento e espaço de armazenamento, os quais,

Introdução 31
tipicamente, podem ser oferecidos por muitos dispositivos, a responsabilidade de
prover o serviço é compartilhada entre os dispositivos que constituem a grade
móvel. Esse compartilhamento é feito de modo uniforme, através do uso do
protocolo P2PDP, tendo como critério de distribuição da tarefa de provisão de
serviços a quantidade de recursos disponível em cada dispositivo. Já com os
serviços de um tipo específico, como um serviço de impressão, em cuja requisição
está implícita a necessidade do cliente por um único provedor do serviço, o
objetivo do protocolo P2PDP é selecionar, dentre as possíveis respostas a
requisição de serviço, aquela que melhor atenda às necessidades do cliente,
considerando, também, em alguns casos, o nível de energia disponível, a
qualidade do enlace sem fio e a proximidade física entre provedor e cliente,
definida em função da distância em número de saltos.
O protocolo de descoberta P2PDP atende às necessidades das grades
móveis ad hoc, promovendo a descoberta de serviços sob demanda, em tempo de
execução, acionada pela necessidade dos usuários. O processamento introduzido
pelo P2PDP não promove gargalos na sua execução e nem gera uma sobrecarga
administrativa nos dispositivos da rede, o que se verifica pelo fraco acoplamento
entre as entidades envolvidas no processo de descoberta – provedores de serviços
e clientes –, as quais entram e saem da rede, a qualquer instante, sem que isso
comprometa o funcionamento do mecanismo de descoberta. O protocolo P2PDP
foi desenvolvido no contexto da arquitetura MoGrid, com o intuito de facilitar o
desenvolvimento de aplicações colaborativas, baseadas no compartilhamento de
recursos dinâmicos, para a execução de serviços na grade móvel. A arquitetura
MoGrid é apresentada em mais detalhes no Capítulo 2.
A avaliação do protocolo proposto foi realizada em duas frentes. A primeira
corresponde a sua implementação, dentro de um middleware para grades móveis,
e, subseqüentemente, a sua utilização no desenvolvimento de aplicações-protótipo
para essas grades; nessa frente, é realizada uma avaliação experimental do
protocolo através da análise do seu funcionamento em cenários reais,
representados por redes de teste. A segunda frente diz respeito à realização de
simulações para avaliar o seu desempenho em cenários de maior escala.

Introdução 32
1.4.
Sumário das Principais Contribuições
Esta tese apresenta o projeto, implementação e avaliação de desempenho de um
protocolo para descoberta e seleção de recursos e serviços, especificamente
desenvolvido para atender às necessidades das grades móveis ad hoc: o protocolo
P2PDP (Peer-to-peer Discovery Protocol). As principais contribuições alcançadas
na área de descoberta de serviços, com o desenvolvimento deste trabalho, podem
ser classificadas em duas categorias: contribuições para o estado da arte e
contribuições tecnológicas.
Contribuições para o estado da arte
O desenvolvimento desta tese teve como resultado duas contribuições
principais para o estado da arte na área de descoberta de serviços, a especificação
do protocolo P2PDP e da arquitetura MoGrid, a saber:
• A concepção, implementação e avaliação de desempenho do algoritmo de
supressão de respostas por vizinhança (Suppression by Vicinity – SbV),
que permite tratar o problema da implosão de respostas em protocolos de
descoberta para MANETs, baseados na transmissão por difusão,
utilizando broadcast;
• A concepção, implementação e avaliação de desempenho do algoritmo de
retardo programado no envio de mensagens de resposta (Delayed Replies
– DR), com o intuito de promover uma seleção natural entre as respostas
que melhor se adequam às especificidades de uma dada requisição de
serviço;
• Especificação de um conjunto de requisitos para o desenvolvimento de um
protocolo para descoberta e seleção de recursos e serviços em grades
móveis ad hoc. Os requisitos do projeto do protocolo de descoberta levam
em consideração as particularidades dos recursos computacionais
dinâmicos, que caracterizam os serviços disponíveis em uma grade móvel;
• Definição de uma arquitetura genérica em camadas, denominada MoGrid,
que serviu de base para o desenvolvimento de um middleware, de mesmo

Introdução 33
nome, que trata aspectos relacionados à computação distribuída em grades
móveis, organizadas através de redes sem fio infra-estruturadas e ad hoc.
Contribuições tecnológicas
Além das contribuições científicas para o estado da arte, foi desenvolvido
um conjunto de artefatos de software para auxiliar o desenvolvimento de
aplicações colaborativas, em grades móveis, baseadas no compartilhamento de
recursos e serviços, a saber:
• Implementação do middleware MoGrid e do protocolo de descoberta
P2PDP;
• Implementação de um proxy de colaboração com a funcionalidade de
permitir o acesso de dispositivos sem fio aos serviços e recursos
disponíveis em uma grade fixa;
• Uso do middleware MoGrid para o desenvolvimento de aplicações
colaborativas, baseadas no compartilhamento de serviços gerenciado pelo
protocolo P2PDP.
1.5.
Organização da Tese
O restante desta tese está organizada como se segue:
O Capítulo 2 contextualiza este trabalho apresentando a arquitetura MoGrid,
projetada com o intuito de oferecer suporte ao desenvolvimento de aplicações
baseadas no compartilhamento de recursos em grades móveis, para a tomada de
decisões referentes à descoberta e ao acesso a esses recursos. A arquitetura
compreende uma camada de descoberta de serviços peer-to-peer – na qual foi
desenvolvido o protocolo de descoberta P2PDP, proposto nesta tese – e uma
camada de transparência – que lida com problemas relacionados a períodos de
desconexão durante os processos de descoberta de recursos, submissão e execução
de tarefas. Ao final do capítulo, são apresentados os trabalhos relacionados que
dizem respeito a arquiteturas de grades móveis.
O Capítulo 3 é reservado aos trabalhos relacionados à área-tema desta tese –
descoberta de serviços para redes sem fio ad hoc –, que é feita tendo como base

Introdução 34
uma classificação genérica proposta para os protocolos de descoberta de serviços
em redes de computadores. Na revisão bibliográfica é dada uma maior ênfase aos
trabalhos que tratam, especificamente, da descoberta de serviços em redes sem fio
ad hoc de saltos múltiplos, abordagem similar à adotada no protocolo P2PDP. Ao
final do capítulo, tem-se um resumo comparativo, que utiliza os critérios
enumerados na classificação apresentada, incluindo os principais protocolos
desenvolvidos para as redes fixas que foram adaptados às redes sem fio infraestruturadas,
os protocolos para as redes sem fio ad hoc de salto único e os
protocolos para as redes sem fio de saltos múltiplos.
No Capítulo 4, é apresentado o protocolo para descoberta e seleção de
recursos em grades móveis ad hoc, denominado P2PDP (Peer-to-Peer Discovery
Protocol), sendo o foco principal deste trabalho. O núcleo do protocolo se baseia
em um mecanismo distribuído, que emprega dois algoritmos principais: o
algoritmo de supressão de mensagens de resposta por vizinhança (Suppression by
Vicinity) e o algoritmo de retardo programado no envio de mensagens de resposta
(Delayed Replies). Esses algoritmos oferecem uma estratégia para reduzir a
implosão e a colisão de respostas em grades móveis ad hoc, além de proporcionar
um mecanismo de seleção das melhores respostas às requisições de serviço.
O Capítulo 5 é dedicado às questões relacionadas à implementação do
protocolo P2PDP, trazendo as decisões de projeto quanto às tecnologias
utilizadas, além de alguns diagramas de classe e de seqüência, com o intuito de
facilitar a compreensão do comportamento das entidades envolvidas no processo
de descoberta e seleção de recursos. Esse capítulo traz maiores detalhes sobre a
utilização do protocolo P2PDP e da API fornecida pela arquitetura MoGrid no
desenvolvimento de três aplicações colaborativas diferenciadas. Um cenário de
simulação é utilizado para atestar a correção da implementação da arquitetura
MoGrid e do protocolo P2PDP.
No Capítulo 6, é feita a avaliação de desempenho do protocolo P2PDP por
meio da interpretação dos resultados obtidos a partir das simulações e da rede de
teste. Diferentes cenários foram utilizados com a variação de parâmetros, como o
tamanho da rede, a densidade de dispositivos, o raio de transmissão, o impacto de
diferentes taxas de requisição, o percentual de dispositivos atuando como
provedores de serviço, entre outros.

Introdução 35
Finalmente, no Capítulo 7, são tecidas as considerações finais, com destaque
para as contribuições decorrentes deste trabalho e a apresentação de problemas
não tratados, mas que podem gerar trabalhos futuros interessantes.
O Apêndice traz alguns detalhes sobre as simulações executadas para avaliar
a correção e o desempenho do protocolo de descoberta P2PDP e do middleware
MoGrid.

2
A Arquitetura MoGrid
2.1.
Introdução
Na etapa de definição do tema desta tese, foi proposta uma arquitetura em
camadas, denominada MoGrid, que permite a distribuição de tarefas entre os
dispositivos que constituem uma grade móvel. Essa arquitetura trata aspectos
relacionados à computação distribuída em redes sem fio, constituídas por grupos
de dispositivos móveis, que atuam, colaborativamente, para a execução de tarefas
e utilização de serviços e recursos. As duas camadas que compõem a arquitetura
MoGrid especificam os mecanismos associados à descoberta de serviços e ao
acesso transparente aos mesmos. Através da abordagem em camadas, os
diferentes mecanismos relacionados ao compartilhamento e à utilização de
serviços são separados, podendo ser utilizados como módulos independentes,
acoplados, inclusive em outras arquiteturas.
Um aspecto central para a arquitetura proposta é o mecanismo responsável
pela descoberta de serviços, modelado através do protocolo P2PDP. Esse
protocolo coordena a distribuição de tarefas entre os dispositivos sem fio,
associando a “necessidade” por recursos com a “disponibilidade” dos mesmos, em
cada possível colaborador na rede – o que caracteriza o conceito de resource
matching. Durante o processo de especificação e implementação da arquitetura
MoGrid, optou-se por concentrar o desenvolvimento desta tese na camada de
descoberta de serviços, que, por si só, já possui uma complexidade considerável.
A camada de transparência de acesso atua sobre os resultados obtidos através do
processo de descoberta, garantindo a utilização dos serviços e recursos
descobertos, em meio a períodos de desconexão de provedores de serviços e seus
clientes. A decisão de focar o trabalho desenvolvido nesta tese na camada de
descoberta tem como intuito oferecer um mecanismo robusto e confiável de
descoberta de serviços, sob o qual a camada de transparência possa atuar.

A Arquitetura MoGrid 37
2.2.
Modelo de Serviços da Arquitetura MoGrid
Pode-se afirmar que um modelo de serviços para grades móveis deve considerar
uma das seguintes abordagens: (i) os dispositivos sem fio atuando como interfaces
de acesso aos recursos disponibilizados por grades computacionais convencionais
ou (ii) os dispositivos sem fio atuando como elementos computacionais da grade
disponibilizando os seus recursos e serviços. A segunda abordagem corresponde
ao modelo de serviços adotado nesta tese. Esse modelo oferece suporte à categoria
de aplicações que consideram a formação de grupos de dispositivos heterogêneos
e autônomos em uma rede sem fio, em um modo ad hoc. Nessa linha, são
apresentados diversos cenários de uso no levantamento efetuado em [Lima 2005],
os quais ilustram o modelo de serviços adotado nesta tese.
Alguns aspectos devem ser considerados em função do modelo de serviços
definido, os quais serão brevemente discutidos nos parágrafos subseqüentes.
• Perfil dos dispositivos. A arquitetura MoGrid foi desenvolvida
considerando-se tanto dispositivos com restrições em relação aos recursos
a serem compartilhados – caracterizados por apresentar conexões de rede
intermitentes, largura de banda limitada, processadores lentos, visores de
dimensões reduzidas, tempo de autonomia de bateria e memória
limitados, como alguns modelos de celulares, pagers, e PDAs –, os quais
atuam na arquitetura apenas como consumidores de recursos, ou seja,
desempenhando o papel de iniciador das requisições de serviço, quanto
dispositivos com uma configuração de hardware mais potente,
apresentando uma maior disponibilidade de recursos e uma conectividade
mais estável – como notebooks e modelos mais modernos de celulares e
PDAs –, os quais desempenham simultaneamente os papéis de produtores
e consumidores de recursos, atuando, respectivamente, como
colaboradores e iniciadores. É importante ressaltar que a arquitetura
MoGrid oferece suporte às plataformas Windows e Linux;
• Suposições sobre a rede sem fio. A arquitetura MoGrid é independente
de um endereçamento de rede explícito, a identificação dos dispositivos é
feita através de um identificador único associado dinamicamente a cada
dispositivo, o que possibilita que a arquitetura opere sem a necessidade de

A Arquitetura MoGrid 38
um protocolo de roteamento, adaptando-se com poucas modificações a
qualquer tipo de rede sem fio. Os dispositivos devem ser interconectados
através de enlaces sem fio bidirecionais, o que possibilita o envio e a
recepção de dados entre dois dispositivos quaisquer na rede. Para
possibilitar a detecção de vizinhança, os dispositivos devem ser capazes
de transmitir pacotes de dados os seus vizinhos imediatos, por broadcast
local. A latência de transmissão da rede pode interferir de forma negativa
no desempenho da arquitetura MoGrid. Considerações a respeito de
falhas e interferências relacionadas ao enlace sem fio encontram-se na
Seção 2.4;
• Perfil de mobilidade dos dispositivos. A arquitetura MoGrid foi
especificada para prover suporte a grupos de dispositivos móveis em
cenários de mobilidade moderada que reproduzam a mobilidade humana,
deslocando-se com uma velocidade média de até 4 m/s. Em cenários de
alta mobilidade, as taxas de churn são muito elevadas, o que inviabiliza a
formação de grupos espontâneos por um período de tempo suficiente para
contemplar o processamento envolvido nas etapas de descoberta, seleção,
submissão e execução de tarefas, etapas essas que caracterizam uma grade
computacional, móvel ou fixa;
• Suposições sobre os serviços. A arquitetura MoGrid se adequa a
execução de tarefas distribuídas paralelizadas, que não apresentem
relações de interdependência, caracterizadas no ambiente de grades fixas
por uma abordagem mestre-escravo, também conhecida como bag-oftasks.
Para deixar claro os conceitos de serviço, tarefa e recurso na
arquitetura MoGrid, é utilizada a ilustração de um dispositivo que precisa
executar uma bateria de simulações, considerando-se um cenário ideal.
Para que a simulação seja executada, é necessário que os dispositivos na
grade possuam instalado o simulador no qual a simulação foi
desenvolvida. Nesse caso, o serviço solicitado é o “serviço de simulação”;
as tarefas correspondem a cada rodada que compõe a bateria de
simulações, as quais devem ser distribuídas entre os dispositivos mais
aptos, ou seja, com mais recursos disponíveis; e os recursos – que no
exemplo da simulação podem ser ,

A Arquitetura MoGrid 39
e – determinam em função da sua disponibilidade se os
dispositivos estão aptos ou não a executar as rodadas de simulação;
• Requisitos de QoS. A arquitetura MoGrid deve prover um nível aceitável
de QoS na execução dos serviços disponibilizados na grade móvel que
reflita a percepção de qualidade do usuário do serviço. Para tanto, é
necessário que os colaboradores ofereçam garantias mínimas sobre a
disponibilidade de seus recursos ao responderem a uma requisição de
descoberta de serviço. Essas garantias são expressas através de requisitos
de QoS. Na arquitetura MoGrid esses requisitos são especificados em
função das informações de contexto do dispositivo que disponibiliza o
serviço. Ao receber uma requisição, o dispositivo avalia, em função das
informações de contexto priorizadas pelo cliente, se ele está ou não em
condições de oferecer o serviço. Por exemplo, ao submeter suas tarefas
para execução em uma grade móvel, uma aplicação de longa duração,
com consumo elevado de CPU, pode especificar os recursos , , e como
requisitos de execução. Além disso, a aplicação pode ainda estabelecer
diferentes níveis de prioridade entre esses recursos, associando um peso
relativo a cada um deles, podendo definir, por exemplo, que o requisito
é mais importante do que o requisito
na escolha do dispositivo que irá
executar a tarefa. No tratamento de requisições concorrentes, para que
garantias mínimas de QoS sejam oferecidas, implementou-se um
mecanismo de adaptação simples, que reduz o indicador da disposição do
dispositivo em colaborar em função do aumento do número de
requisições pendentes (vide Subseção 2.3.1.2 e Seção 4.5). É importante
mencionar que no instante em que o serviço for de fato utilizado, o
provedor do serviço não tem meios de garantir que as mesmas condições
irão se verificar. Após a fase de descoberta, podem ocorrer alterações no
estado de qualquer um dos recursos considerados, comprometendo a
submissão ou execução do serviço solicitado, entretanto, esse tópico não é
o foco deste trabalho. O tempo de descoberta aceitável foi especificado

A Arquitetura MoGrid 40
em 10 s, que corresponde ao período que transcorre entre o envio da
requisição e o recebimento das primeiras respostas pelo nó requisitante;
• Segurança. A questão da segurança é especialmente relevante na
integração das grades móveis com as grades fixas. Entretanto, aspectos
relacionados à segurança não foram especificados na arquitetura MoGrid,
os quais devem ser incorporados como trabalhos futuros.
2.3.
Um Middleware para Grades Móveis
A arquitetura MoGrid foi especificada tendo como finalidade oferecer suporte ao
desenvolvimento de aplicações de grade em redes sem fio infra-estruturadas e ad
hoc, possibilitando aos dispositivos sem fio executar tarefas computacionalmente
complexas utilizando os recursos disponíveis na grade móvel. Nesse processo
foram identificados dois aspectos principais: (i) a descoberta e seleção dos
dispositivos mais aptos a executar as tarefas na grade móvel, em função das
necessidades por recursos definidas na aplicação, e (ii) o gerenciamento da
execução dessas tarefas, garantindo a sua conclusão mesmo mediante variações na
qualidade do enlace sem fio e períodos de desconexão dos dispositivos da grade
móvel. A arquitetura MoGrid compreende uma camada de descoberta peer-topeer
e uma camada de transparência, como se pode observar na Figura 2.
Figura 2 – Arquitetura MoGrid.
A arquitetura MoGrid possibilita a descoberta simultânea de múltiplas
instâncias de um mesmo serviço, possibilitando a manutenção de um grau de
redundância do mesmo. Essa abordagem é indicada para atender a demanda das
grades móveis na execução de tarefas complexas, que demandam maior
capacidade computacional, situação na qual, assim como nas grades

A Arquitetura MoGrid 41
computacionais fixas, o serviço provido é o próprio poder de processamento dos
dispositivos.
A arquitetura oferece suporte a dois tipos principais de aplicações: (i)
aplicações de grade cientes da mobilidade dos dispositivos e (ii) aplicações
convencionais de grade, como transferência particionada de arquivos e aplicações
do tipo mestre-escravo, para as quais o uso da arquitetura deve ser transparente. O
primeiro tipo de aplicação faz uso direto dos serviços oferecidos pela camada de
descoberta e se responsabiliza, durante a submissão e execução de tarefas, pela
gerência de questões relacionadas à conectividade irregular da grade móvel. No
segundo tipo de aplicação, as questões são tratadas pela camada de transparência,
que se responsabiliza também por acionar o serviço de descoberta.
2.3.1.
Camada de Descoberta P2P
A camada de descoberta P2P é composta de três partes principais: a API de
descoberta, as entidades envolvidas no processo de descoberta e o protocolo de
descoberta e seleção de recursos P2PDP (Peer-to-Peer Discovery Protocol), o
qual é apresentado em detalhes no Capítulo 4.
2.3.1.1.
API de Descoberta
Aplicações executando em um dispositivo móvel devem usar as operações
disponíveis na API de descoberta – diretamente ou através da camada de
transparência – para usufruir dos benefícios dos mecanismos de descoberta e
seleção de serviços da arquitetura. A API de descoberta provê, às aplicações,
operações para registro de serviços, anúncio de serviços, especificação do perfil
da requisição e descoberta de serviços. A Figura 3 mostra as principais operações
desta API.
Figura 3 – API de descoberta.

A Arquitetura MoGrid 42
Para que um serviço torne-se acessível na grade móvel, o dispositivo que
provê o serviço faz o seu registro localmente, através da operação register().
Na arquitetura MoGrid, cada serviço é descrito por meio de um conjunto de
atributos (serviceDescriptor), que é passado como parâmetro da operação
register(). Esse conjunto de atributos define uma representação padronizada
para todos os serviços na grade móvel através de um identificador único universal,
uma descrição sucinta do serviço, um conjunto de palavras-chave e a sua
localização, como ilustrado na Figura 4. O identificador único universal de um
serviço é definido como um valor de 16 bytes gerado a partir da combinação da
identificação do nó que o disponibiliza, do identificador mnemônico do serviço e
do tempo corrente do sistema. Através da operação deregister(), é possível
efetuar a remoção dos serviços registrados localmente, passando como parâmetro
o seu identificador único universal (serviceID).
Figura 4 – Estrutura do parâmetro serviceDescriptor.
Um serviço registrado pode ser anunciado periodicamente na grade móvel
(operação advertise()) – em uma abordagem proativa –, ou as informações
sobre o novo serviço disponível podem ser obtidas sob demanda como resultado
das requisições das aplicações para descoberta de serviços (operação discover())
– em uma abordagem reativa. Caso as duas abordagens sejam adotadas é
caracterizado um mecanismo híbrido de descoberta de serviços.
No processo de descoberta, é necessária a descrição da requisição de serviço
(resourceQuery), que é passada como parâmetro da operação discover(). A
requisição contém uma descrição sucinta do serviço e um conjunto de palavraschave
associadas ao mesmo. Esses atributos são comparados, em cada dispositivo,
com as informações sobre os serviços por ele oferecidos, informações estas
registradas em uma estrutura de dados local, cujas entradas correspondem a pares
do tipo {serviceID, serviceDescriptor}. A API permite ainda que as
aplicações personalizem previamente suas requisições para descoberta de serviços
(operação createRequestProfile()), gerando um perfil da requisição
(reqProfile), que será informado na operação de descoberta (discover()). Essa
personalização é útil quando são geradas várias requisições a serviços com as

A Arquitetura MoGrid 43
mesmas características, evitando que as mesmas informações sejam passadas em
cada requisição. O perfil da requisição define o número de colaboradores que o
iniciador necessita envolver na execução do serviço (numMaxReplies; zero
significa tantos colaboradores quanto os disponíveis na rede sem fio), por quanto
tempo a aplicação está disposta a esperar por respostas (maxReplyDelay 1 ) e a
informação de contexto de interesse (ctxtInfo). A informação de contexto de
interesse determina quais recursos devem ser considerados em uma requisição e a
importância relativa entre eles, sendo denominado de “perfil de execução”. As
informações contidas no perfil de execução são utilizadas no cálculo do retardo
programado associado ao envio das mensagens de resposta do protocolo de
descoberta. O retardo gerado é inversamente proporcional à disponibilidade dos
recursos do dispositivo que são necessários para a provisão do serviço solicitado.
Esse parâmetro é utilizado no processo de seleção para medir a qualidade das
respostas encaminhadas, identificando o grupo de colaboradores mais aptos,
dentre aqueles que se prontificaram a oferecer o serviço.
O conceito de perfil de execução proposto na arquitetura MoGrid é similar
ao conceito de “resource matching” [Tangmunarunkit et al. 2003; Farooq &
Khalil 2006] da área de grades computacionais, o qual define a seleção do grupo
de dispositivos que irá colaborar na execução de um conjunto de tarefas, com base
nos recursos disponíveis em cada elemento do grupo, considerando-se os
requisitos da aplicação. A informação de perfil de execução é um parâmetro
importante durante o processo de seleção na arquitetura MoGrid, pois reflete os
requisitos do serviço que devem ser considerados ao se medir a qualidade das
mensagens de resposta a uma dada requisição. Contudo, após a fase de descoberta,
podem ocorrer alterações no estado de qualquer um dos recursos considerados no
perfil de execução de um dado serviço que venham a comprometer a submissão
ou execução das tarefas. As aplicações que fazem uso direto dos serviços
oferecidos pela camada de descoberta se responsabilizam, durante a submissão e
execução de tarefas, pela gerência de questões relacionadas à conectividade
irregular da grade móvel. Por outro lado, para as aplicações que não acessam
1 Esse valor de retardo pode ser definido estaticamente ou ajustado dinamicamente através de um
algoritmo adaptativo, baseado em estimativas de RTT (Round Trip Time).

A Arquitetura MoGrid 44
diretamente o serviço de descoberta (vide Figura 2 da Seção 2.3), o tratamento
desse tipo de condição é feito pela camada de transparência, que aciona esse
serviço em benefício da aplicação. As funções da camada de transparência são
descritas em detalhes na Subseção 2.3.2.
2.3.1.2.
Entidades de Descoberta
A forma como as entidades envolvidas no processo de descoberta de serviços se
relacionam, bem como a interação entre elas, através da troca de mensagens do
protocolo de descoberta P2P (P2PDP), é ilustrada na Figura 5. Essa dinâmica é
representada em dois cenários distintos: em redes sem fio ad hoc [Figura 5(a)] e
em redes sem fio infra-estruturadas [Figura 5(b)].
( a ) Rede sem fio ad hoc
( b ) Rede sem fio infra-estruturada
Figura 5 – Entidades envolvidas no processo de descoberta.
A camada de descoberta P2P define três entidades principais –
colaboradores, iniciadores e coordenadores – que correspondem aos diferentes
papéis que um dispositivo pode desempenhar no processo de descoberta de
serviços, como ilustrado na Figura 5. Colaboradores estão disponíveis para a
execução de tarefas da grade móvel. Um dispositivo móvel está apto a atuar como
colaborador após registrar seus serviços localmente (operação register()).
Iniciadores submetem, aos colaboradores, as requisições por serviços e o perfil de

A Arquitetura MoGrid 45
execução desses serviços, que especifica quais recursos são necessários para o
processamento de tarefas da aplicação. Qualquer dispositivo móvel pode ser um
iniciador em uma grade móvel. Finalmente, coordenadores atuam como
intermediadores entre iniciadores e colaboradores. Coordenadores encaminham as
requisições dos iniciadores para descoberta de serviços aos colaboradores e, com
base nas respostas recebidas, disponibilizam, aos iniciadores, uma lista contendo
os colaboradores mais apropriados. É importante ressaltar que, embora o foco
principal desta tese sejam as grades móveis implantadas em redes sem fio ad hoc
[Figura 5(a)], a arquitetura MoGrid também contempla a implementação do
serviço em uma rede com um coordenador centralizado, se uma rede sem fio
infra-estruturada estiver disponível. Nesse tipo de rede, um ou mais dispositivos
conectados à rede fixa atuam como coordenadores da grade móvel, gerenciando as
requisições de todos os dispositivos sem fio. Isso evita que os dispositivos móveis
sejam sobrecarregados devido ao processamento adicional das funções associadas
à coordenação de suas requisições, que é o comportamento padrão em uma rede
sem fio ad hoc. A Figura 5(b) ilustra esse cenário alternativo.
Dois serviços desempenham funções importantes na arquitetura proposta: o
monitor e o gerente de contexto (ContextListener). Cada dispositivo, na grade
móvel, possui um monitor residente. O serviço monitor é responsável por coletar a
informação de contexto dos dispositivos móveis, incluindo a qualidade do enlace
sem fio, carga de CPU, carga residual da bateria, memória disponível e espaço de
armazenamento. Em uma rede sem fio ad hoc, cada dispositivo possui também
um gerente de contexto residente [Figura 5(a)]; em contraste, uma rede sem fio
infra-estruturada pode ter um gerente de contexto centralizado [Figura 5(b)]. O
serviço de gerente de contexto recebe, periodicamente, do serviço monitor, a
informação de estado coletada, e deduz, a partir de tal informação, a
disponibilidade de recursos dos dispositivos. Quando um coordenador consulta os
colaboradores sobre a disponibilidade de recursos de seus dispositivos, para a
execução de uma tarefa, os colaboradores interagem com o serviço de
gerenciamento de contexto para verificar se eles oferecem o perfil de execução
necessário para participar na execução da tarefa.
Basicamente, um colaborador adota dois critérios para decidir se está apto a
prover o iniciador com o serviço solicitado. O primeiro critério representa um

A Arquitetura MoGrid 46
parâmetro subjetivo que indica a disposição do usuário em participar ou não da
provisão do serviço, de acordo com a sua “boa vontade” em colaborar
(willingness). O segundo critério atua como um “controlador de admissão”
(AdmissionController), verificando se o colaborador pode disponibilizar o serviço
solicitado pelo iniciador e a sua “adequação” (suitability) para participar na
execução das tarefas nas quais o serviço é particionado, considerando o seu nível
de comprometimento com as demais requisições às quais tenha respondido.
Fundamentalmente, a adequação de um colaborador é medida de acordo com o
perfil de execução do serviço provido pelo iniciador que efetuou a requisição
(ctxtInfo na operação createRequestProfile()). Retomando o exemplo de
uma aplicação de longa duração, que exija um processamento intensivo,
colaboradores com níveis mais elevados de energia tipicamente serão
selecionados para executar uma tarefa. O mecanismo de seleção é implementado
de forma distribuída no protocolo P2PDP, que é apresentado em detalhes no
Capítulo 4.
O tratamento de requisições concorrentes merece ser discutido. Caso um
colaborador tenha respondido a uma dada requisição, mas a execução do serviço
ainda não tenha sido iniciada – por exemplo, a execução de uma rodada de
simulação –, essa resposta representa uma reserva antecipada de recursos para a
execução do serviço [Wolf et al. 1995; Smith et al. 2000], caracterizando o
compromisso do dispositivo em atender à requisição. A validade dessa reserva é
indicada quando a requisição é gerada, sendo definida através do parâmetro
maxReplyDelay, que especifica o tempo que a aplicação está disposta a esperar
por respostas. Ao receber uma nova requisição, o colaborador deve considerar o
seu nível de comprometimento com as demais requisições já respondidas como
um dos critérios determinantes para se definir a sua aptidão. Esse aspecto é
fundamental para oferecer alguma garantia 2 quanto à qualidade do serviço que
está sendo entregue e, em situações extremas, que o serviço seja, de fato,
disponibilizado, mesmo que a qualidade na qual ele esteja sendo entregue não
2 As garantias oferecidas na entrega de um serviço em ambientes computacionais móveis não são
garantias absolutas, pois estão condicionadas às peculiaridades desses ambientes, como a
qualidade do enlace sem fio, a disponibilidade de largura de banda e a mobilidade dos dispositivos.

A Arquitetura MoGrid 47
corresponda integralmente as expectativas do usuário. O nível de
comprometimento de um colaborador mede o quanto os recursos necessários para
a entrega do serviço solicitado já estão comprometidos com a execução de outras
requisições, impedindo que ele responda a mais requisições do que é capaz de
atender. O monitoramento das condições do dispositivo é feito pelo serviço de
gerenciamento de contexto.
Coordenadores tratam os casos de requisições não completamente atendidas,
em que são recebidas menos respostas do que o esperado – devido, por exemplo, a
respostas perdidas na rede. Em tais casos, a aplicação (ou a camada de
transparência) que disparou a requisição do iniciador terá que lidar com essa
situação através do envio de uma requisição adicional ao protocolo de descoberta
ou da notificação de falha no processo de descoberta ao cliente da aplicação. Um
cenário oposto ocorre quando o coordenador recebe mais respostas do que
solicitado pelo iniciador. Em tais casos, o coordenador seleciona as respostas mais
apropriadas, com base em critérios pré-estabelecidos, antes de encaminhá-las para
o iniciador interessado. Esses critérios podem ser definidos pelo usuário, de
acordo com as características dos serviços que ele usualmente solicita, ou, então,
podem ser adotados os critérios-padrão definidos na arquitetura MoGrid. A
abordagem mais comumente utilizada, na seleção de respostas a uma solicitação
de descoberta, adota a distância, em número de saltos, entre o cliente e o provedor
do serviço como critério de decisão [Lenders et al. 2005; Varshavsky et al. 2005].
Na arquitetura MoGrid, dois critérios são utilizados para selecionar as melhores
respostas caso o coordenador receba mais respostas do que as que foram
solicitadas: a distância, em número de saltos, do colaborador até o iniciador, e o
perfil de execução contido na resposta do colaborador. Essa seleção é feita de
forma automática pelo coordenador em benefício do iniciador.
2.3.2.
Camada de Transparência
A camada de transparência é responsável por gerenciar as questões relacionadas à
conectividade irregular da grade móvel, decorrente de períodos de desconexão,
provocados pela instabilidade do enlace ou mesmo pela indisponibilidade dos
provedores durante a fase de descoberta de recursos e, posteriormente, de

A Arquitetura MoGrid 48
submissão e execução de tarefas. A camada de transparência é composta pela
subcamada de acesso transparente aos recursos e pelas subcamadas de adaptação,
como ilustrado na Figura 6.
Figura 6 – Arquitetura MoGrid: a camada de transparência.
2.3.2.1.
Subcamada de Acesso Transparente aos Recursos
Considerando-se o fator mobilidade, simplificando a definição apresentada em
[Peddermors et al., 2004], existem dois possíveis comportamentos que uma
aplicação pode adotar, o que influenciará no nível de transparência de acesso
oferecido: (i) aplicações que não têm consciência da mobilidade e,
conseqüentemente, não gerenciam o problema da desconexão; e (ii) aplicações
que têm consciência da mobilidade e tratam o gerenciamento de desconexão na
própria aplicação. Para oferecer suporte ao gerenciamento de desconexão às
aplicações que se comportam como descrito em (i), foi idealizada a subcamada de
acesso transparente aos recursos (Transparent Resource Access Sublayer –
TRAS).
Normalmente, após receber a lista dos colaboradores mais aptos, em
resposta à uma requisição de serviço, o iniciador, que efetuou a requisição, pode
realizar a distribuição de tarefas, entre eles, usando um protocolo padrão, como,
por exemplo, o GridFTP [Foster & Kesselman 1997] ou alguma implementação
projetada para atender às necessidades da aplicação cliente. Cada colaborador,
após executar completamente uma tarefa, envia os resultados obtidos para o
iniciador. No entanto, durante a submissão ou execução de tarefas, o iniciador, ou
qualquer dos colaboradores, pode passar por um período de desconexão, que pode
ser voluntária (por exemplo, dispositivo sendo deslocado ou entrando no modo de
economia de energia) ou involuntária (como a perda abrupta de conectividade).

A Arquitetura MoGrid 49
Quando o coordenador é centralizado [Figura 5(b)], ele pode lidar com a
desconexão dos iniciadores, atuando como um proxy, em benefício dos mesmos,
armazenando os resultados enviados pelos colaboradores, até que a conexão com
o iniciador possa ser restabelecida, quando, então, ele entrega os resultados
obtidos. Vale ressaltar a necessidade de se definir políticas, no coordenador, que
estabeleçam critérios para a manutenção do armazenamento desses resultados.
Essas políticas podem ser definidas localmente, onde cada coordenador determina
a sua, ou podem ser definidas de forma global, nesse caso, todos os dispositivos
da rede adotam o mesmo conjunto de políticas. No caso da desconexão dos
colaboradores, o coordenador atua em benefício do iniciador que efetuou a
requisição, selecionando novos colaboradores, com o auxílio do protocolo P2PDP.
Quando as desconexões dos colaboradores são voluntárias, independentemente do
coordenador ser centralizado ou distribuído, mecanismos para migração de
tarefas, entre colaboradores, podem ser empregados [Milojicic et al. 2000]. Os
colaboradores podem enviar, para o coordenador, uma mensagem de notificação
de desconexão, incluindo, nessa mensagem, informações sobre o estado de
execução da tarefa que cada um estava executando. Ao receber essa notificação, o
coordenador aciona o processo de seleção de um novo colaborador, atuando como
um intermediador no processo de migração da execução da tarefa.
Para coordenadores descentralizados [Figura 5 (a)], como ocorre
tipicamente no caso das redes sem fio ad hoc, algumas considerações adicionais
devem ser feitas. O restante desta seção tem como foco os requisitos de projeto da
TRAS para oferecer suporte à desconexão das entidades de descoberta, em redes
sem fio ad hoc, e a forma como ela se relaciona com o protocolo P2PDP.
No caso de desconexão voluntária do iniciador, ele notifica antecipadamente
esse evento aos seus colaboradores atuais. Quando finalizam a execução da tarefa,
os colaboradores notificados armazenam os resultados correspondentes até que o
iniciador anuncie que está novamente conectado, ou até que um temporizador
(waiting-for-initiator), disparado no instante em que a tarefa é concluída, expire.
Nesse último caso, os colaboradores descartam os resultados que foram
armazenados. Cada colaborador define o seu temporizador de forma independente
em relação aos demais colaboradores.

A Arquitetura MoGrid 50
Quando um colaborador detecta que irá se desconectar, ele suspende as
tarefas em andamento e notifica esse evento a todos os iniciadores com os quais
ele está cooperando. A partir desse ponto, dependendo do tempo de conexão
restante e da disponibilidade de seus recursos, o colaborador pode apresentar dois
comportamentos distintos: (i) ele descarta os resultados parciais obtidos e
transfere a responsabilidade de selecionar um novo colaborador, para reiniciar a
execução da tarefa, ao iniciador, que, para isso, acionará o coordenador, ou (ii) ele
se encarrega de fazer a migração do estado atual da sua execução para um novo
colaborador, o qual deve retomar a execução da tarefa do ponto em que ela foi
interrompida. Na primeira abordagem, em resposta à notificação de desconexão, o
iniciador dispara o envio de mensagens P2PDP IReq para a seleção de um novo
colaborador. Só então, após receber o resultado indicando quem foi o colaborador
selecionado, a tarefa é resubmetida, sendo executada desde o início. Na segunda
abordagem, o colaborador utiliza o protocolo P2PDP para selecionar um
substituto, restringindo a consulta a sua vizinhança física, ou seja, aos dispositivos
que estão conectados diretamente ao colaborador. Essa estratégia é indicada para
reduzir o consumo de energia adicional provocado pela inundação da rede com a
difusão de uma nova mensagem de requisição do iniciador para encontrar um
substituto ao colaborador que se tornou indisponível. O colaborador atual
transfere a tarefa para o novo colaborador, juntamente com o seu estado de
execução, gerenciando o processo de migração através da camada de
transparência. Ao finalizar a execução da tarefa, o colaborador substituto entrega
o resultado da execução ao iniciador. Caso a seleção de um novo colaborador não
seja bem sucedida, o colaborador se comporta como descrito na primeira
abordagem, transferindo a responsabilidade da seleção de um novo colaborador
para o iniciador.
Para a detecção de possíveis desconexões involuntárias, tanto para o
iniciador quanto para o colaborador, a camada de transparência pode monitorar os
eventos, processados pelo serviço de gerenciamento de contexto, relacionados à
qualidade do enlace sem fio e a sua reserva de energia; inferindo, a partir desses
recursos, um estado de desconexão iminente. Ao detectar esse estado, o gerente de
contexto notifica a entidade de descoberta, que executa os mesmos procedimentos
acionados em uma desconexão voluntária. A implementação de um mecanismo

A Arquitetura MoGrid 51
eficiente de detecção de desconexões involuntárias apresenta uma série de
dificuldades. A detecção pode não ser imediata, impossibilitando que a entidade
de descoberta seja notificada em tempo hábil para acionar os procedimentos de
desconexão necessários. Em uma situação oposta, o dispositivo pode apresentar
uma indisponibilidade temporária de seus recursos. Nesse quadro, o gerente de
contexto pode interpretar essa indisponibilidade como um evento de desconexão
involuntária e notificá-lo à entidade de descoberta, que aciona, então, os
procedimentos de desconexão, antecipando uma situação que, nesse caso, não vai
acontecer. É importante mencionar, que subcamadas de adaptação distintas podem
aplicar tratamentos diferenciados para lidar com os períodos de desconexão
involuntária das entidades de descoberta, como discutido na Subseção 2.3.2.3.
Esses tratamentos são determinados pelas características específicas da família de
aplicações à qual cada subcamada de adaptação provê suporte.
2.3.2.2.
Requisitos da Camada de Acesso Transparente aos Recursos
Para prover suporte ao gerenciamento das desconexões involuntárias, é necessário
que se defina um outro protocolo – complementar ao P2PDP – no âmbito da
camada de transparência. Nesta subseção, é apresentada uma discussão quanto aos
requisitos necessários para auxiliar na especificação do protocolo de acesso
transparente aos recursos (Transparent Resource Access Protocol – TRAP). A
especificação desse protocolo tem o propósito de definir um nível aceitável de
qualidade na execução dos serviços descobertos na grade móvel, definido de
forma subjetiva, em função da percepção do usuário do serviço. Para tanto, é
necessário que os colaboradores ofereçam garantias mínimas sobre a
disponibilidade de seus recursos ao responderem a uma requisição de serviço. O
projeto e a implementação do TRAP não são o foco desta tese; entretanto, os
próximos parágrafos trazem uma discussão sobre os requisitos básicos que o
protocolo de acesso deve atender para que os serviços descobertos na grade móvel
sejam utilizados, independentemente de desconexões involuntárias.
Mecanismo de comunicação. É necessário definir como a comunicação
entre o cliente e o provedor de serviço será estabelecida. Duas abordagens
principais podem ser adotadas. Na primeira, o mecanismo de comunicação

A Arquitetura MoGrid 52
utilizará o protocolo de roteamento adotado na MANET para promover o
encaminhamento de mensagens de invocação do serviço e de entrega do resultado
da sua execução. Na segunda abordagem, indicada para cenários de baixa
mobilidade, o TRAP pode manter uma estrutura de dados, denominada tabela de
execuções pendentes (TEP), com informações sobre o caminho entre a origem
(colaborador) e o destino (iniciador) do serviço descoberto. Essas informações
permitem que as mensagens de invocação e de resultado sejam encaminhadas,
salto-a-salto, do cliente até o provedor, e vice-versa, através das informações
armazenadas na tabela mantida, localmente, pelos nós intermediários. Em face a
períodos de alta mobilidade, apenas a primeira abordagem seria viável, dado que a
manutenção da TEP exigiria um mecanismo de atualização, acionado em função
da quebras de rotas. Esse mecanismo faria uso do protocolo P2PDP para descobrir
um novo caminho entre a origem e o destino. Nesse caso, o serviço requisitado
seria a localização do destino.
Monitoramento do provedor do serviço. O TRAP deve fornecer garantias
que o provedor do serviço selecionado desempenhe as suas funcionalidades com
um nível de qualidade que não extrapole um limite mínimo de tolerância (QoS min ),
oferecendo, com uma certa probabilidade, a garantia de que o resultado gerado
atenda às necessidades do cliente. Para garantir essa propriedade, um mecanismo
de monitoramento da disponibilidade dos recursos do provedor do serviço deve
ser incorporado ao TRAP. Os recursos monitorados seriam aqueles definidos na
requisição do serviço, em função das características da aplicação. Esse monitor
notificaria ao TRAP caso o provedor atingisse um nível de disponibilidade de
recursos insatisfatório para a execução do serviço. Com essa informação, o TRAP
poderia, automaticamente, acionar o mecanismo de redescoberta e dar início à
migração de serviço ou, simplesmente, comunicar ao cliente (iniciador) a
indisponibilidade do provedor (colaborador). A ação a ser executada, em resposta
ao recebimento de uma notificação de indisponibilidade do provedor, é definida
na subcamada de adaptação, através do mecanismo de callbacks. O resultado do
monitoramento dos provedores de serviço também pode ser utilizado na
implementação de um mecanismo de reputação [Rheingold 2003]. O
funcionamento desse mecanismo se baseia na preocupação que os usuários de
sistemas computacionais – como aqueles que constituem uma grade móvel – têm

A Arquitetura MoGrid 53
em manter a sua reputação elevada, evitando assim qualquer comportamento que
reduza o seu conceito perante os demais membros do grupo. Esse fator pode ainda
ser utilizado para adaptar o parâmetro que indica a disposição de um colaborador
em participar na execução de um serviço, em função da reputação do dispositivo
requisitando o serviço; caso a reputação do iniciador seja considerada
insatisfatória, o colaborador pode se negar a atender a sua requisição de serviço. É
importante levar em consideração, na implementação do mecanismo de
monitoramento, que deve ser definido o que caracteriza uma indisponibilidade
real de uma flutuação temporária na disponibilidade de recursos do provedor,
evitando que notificações precipitadas sejam disparadas. Esse é um problema não
trivial, intrínseco às redes sem fio, e para que o mecanismo de monitoramento seja
implementado, é preciso que se faça uma investigação aprofundada sobre o tema.
Manutenção do estado da execução. Para que haja migração de serviço
entre os colaboradores, é necessário que o estado da sua execução possa ser
recuperado para que a nova instância do serviço retome a sua execução a partir do
ponto em que ela foi interrompida. Segundo Milojicic et al. [2000], o estado de
execução inclui o espaço de endereçamento do processo, o ponto de execução –
conteúdo dos registradores –, o estado da comunicação – como arquivos abertos e
canais de mensagens que foram estabelecidos – e estados dependentes do sistema
operacional. É importante mencionar a necessidade de se definir operações para
interromper e reiniciar um serviço. Para isso, é obrigatório que a implementação
do serviço ofereça algum tipo de interface que possibilite as funções de
exportação e importação para extrair o estado de execução do serviço do provedor
de origem e recuperá-lo no provedor de destino. Essas interfaces normalmente são
providas pelo sistema operacional ou por bibliotecas específicas associadas à
linguagem de programação utilizada.
Migração de serviço. Esse requisito diz respeito à transferência do serviço,
entre dois provedores – a origem e o destino – durante a sua execução. A
transferência inclui a migração do serviço e do seu estado de execução. A camada
TRAS requer um mecanismo de migração de processos para os serviços statefull.
Existem diversos trabalhos que tratam essa questão, adotando abordagens
diferenciadas. A implementação desse mecanismo exige uma investigação
meticulosa sobre o tema. Levando em consideração o algoritmo definido por

A Arquitetura MoGrid 54
Milojicic et al. [2000], na camada de acesso transparente, a migração de um
serviço deve cumprir as seguintes etapas: (i) a migração é requisitada em função
da notificação de uma indisponibilidade iminente do colaborador (provedor do
serviço); (ii) é efetuada a escolha do novo colaborador, dando início a um novo
processo de descoberta através do protocolo P2PDP; (iii) a execução do serviço é
suspensa no colaborador de origem; (iv) os canais de comunicação utilizados pelo
serviço são estabelecidos no novo colaborador; (v) o estado do serviço é extraído
da instância em suspensão no colaborador de origem; (vi) uma instância do
serviço é criada no novo colaborador; (vii) o estado de execução do serviço, que
foi transferido, é importado pela instância em execução no novo colaborador e
(viii) a nova instância do serviço pode então ter a sua execução retomada do ponto
em que foi interrompida, e a instância do serviço, no colaborador de origem, pode
finalmente ser removida.
Mecanismo de redescoberta. Caso seja necessário substituir um
colaborador durante a execução de um dado serviço, torna-se necessário acionar o
mecanismo de redescoberta de colaboradores para que a execução do serviço
possa ser concluída no substituto. Para que esse requisito seja alcançado, é preciso
acionar, mais uma vez, o protocolo de descoberta P2PDP. Essa etapa pode ser
gerenciada pelo provedor do serviço (colaborador P2PDP) ou pelo próprio cliente
(iniciador P2PDP), dependendo da ação disparada pelo protocolo TRAP quando o
colaborador é notificado sobre um evento de indisponibilidade do serviço em
execução. O colaborador pode acionar automaticamente o mecanismo de
redescoberta ou simplesmente comunicar ao iniciador que houve uma falha na
execução do serviço, transferindo para ele essa responsabilidade. Uma outra
abordagem seria acionar o mecanismo de redescoberta, automaticamente, quando
um provedor de serviço enviasse ao iniciador uma mensagem de notificação de
indisponibilidade. Essa mensagem seria, então, encaminhada por broadcast
limitado, na grade móvel, e encapsularia uma mensagem de requisição P2PDP
(IReq). Ao receber uma notificação destinada a um outro dispositivo, os nós
intermediários, no caminho entre o antigo colaborador e o iniciador, respondem ao
iniciador, caso se adeqüem ao perfil de execução do serviço, encapsulando a
mensagem de resposta (CRep) do protocolo P2PDP na notificação de
indisponibilidade. Nesse caso, ao receber a notificação de indisponibilidade do

A Arquitetura MoGrid 55
antigo colaborador, o iniciador receberá também uma lista com os novos
colaboradores.
2.3.2.3.
Subcamadas de Adaptação
Em contraste com as aplicações cientes da utilização da arquitetura, as aplicaçõespadrão
de grades fixas não têm conhecimento de detalhes particulares da API de
descoberta. Para oferecer suporte a essas aplicações, a camada de transparência
estabelece a cooperação entre o iniciador e os seus colaboradores potenciais,
utilizando o protocolo P2PDP, através das funcionalidades oferecidas pelas
subcamadas de adaptação (Adaptation SubLayers – ASLs). Como já foi
mencionado, a subcamada TRAS provê mecanismos independentes da aplicação
que garantem a transparência no acesso e utilização dos recursos; no entanto, cada
tipo de aplicação, em uma grade móvel, apresenta requisitos específicos. Por
exemplo, aplicações baseadas no paradigma de computação paralela mestreescravo
demandam maior poder de processamento, mas são menos suscetíveis à
conectividade intermitente. De um modo geral, o resultado do processamento
desse tipo de aplicação gera um volume de dados pequeno que pode ser
transferido em um breve período de conectividade estável, exigindo pouco do
meio sem fio em termos de transmissão de dados. Entretanto, aplicações dessa
mesma categoria, que gerem resultados volumosos, irão demandar, também,
estabilidade da conexão e carga residual da bateria, devido à necessidade de
transmissão de uma quantidade de dados considerável. Por outro lado, para
aplicações que efetuam replicação de dados, requisitos como capacidade de
armazenamento, estabilidade da conexão e carga residual da bateria são mais
importantes, dado o grande volume de dados transferidos no meio sem fio. O
processo de replicação implica na necessidade de espaço físico para armazenar os
dados e uma conectividade estável para lidar com uma taxa de transmissão
constante, responsável por um aumento no consumo de energia. O principal
propósito das subcamadas de adaptação é implementar o tratamento dos eventos
relacionados à mobilidade e à desconexão da forma que melhor se adeqüe a cada
tipo de aplicação, implementando os procedimentos que devem ser acionados em
caso de notificação de eventos de exceção.

A Arquitetura MoGrid 56
Cada subcamada de adaptação deve implementar algumas operações de
callback que definem o comportamento esperado dos iniciadores, coordenadores e
colaboradores no caso de eventos de exceção, como requisições não atendidas ou
desconexões voluntárias e, quando possível, exceções decorrentes da detecção de
desconexões involuntárias. Apesar de não trivial, idealmente, a subcamada TRAS
deve, ao detectar qualquer evento de exceção, identificá-lo e acionar a callback
correspondente. Ao se implementar uma ASL específica, é fundamental que se
definam os possíveis eventos de exceção e se ofereçam mecanismos de
identificação dos mesmos. Além disso, deve-se realizar a associação entre esses
eventos e as callbacks correspondentes, que devem ser implementadas na ASL.
No caso de eventos determinísticos, como desconexão voluntária e requisições
não atendidas, é fácil fazer essa associação. O mesmo não acontece no caso dos
eventos cuja detecção está associada ao monitoramento das condições da rede e da
variação da disponibilidade de recursos no próprio dispositivo, como desconexões
involuntárias e redução na qualidade do serviço oferecido. Nessa situação, deve-se
definir condições limites que caracterizem a exceção – como intervalos temporais
nos quais as variações são permitidas, valores mínimos que cada recurso pode
assumir em um dado intervalo – além de se permitir a composição dessas
condições considerando-se diferentes recursos, definindo, por exemplo, para a
detecção de um evento de redução de QoS, que a carga residual da bateria não
pode ser inferior a 50% e a carga de processamento não pode se manter abaixo de
40% por um período de tempo superior a um minuto. Nesse cenário, quando uma
entidade não consegue efetuar o mapeamento entre uma exceção específica e a
sua callback de tratamento, a aplicação deve, então, ser notificada imediatamente.
A caracterização das exceções não é trivial e requer conhecimento a respeito dos
requisitos da aplicação cliente.
2.4.
Os Modelos de Falhas da Arquitetura MoGrid
Falhas podem ter diversas origens, que vão desde causas físicas – como
rompimento de uma trilha em um circuito eletrônico ou ruídos na rede elétrica –,
até falhas de origem humana, quer sejam intencionais ou não – como erros de
projeto ou mesmo erros causados pelo mau uso dos sistemas. Em um cenário de
comunicação sem fio, existem ainda os problemas provocados pela perda de

A Arquitetura MoGrid 57
pacotes de dados e desconexões constantes, problemas esses que tornam o sistema
ainda mais propenso à manifestação de falhas. Independentemente da sua origem,
em um sistema de tempo real distribuído, uma falha pode ser classificada de
acordo com o comportamento do componente que a detecta após a sua ocorrência,
como descrito em [Chow & Johnson 1997]. Os modelos de falhas considerados
serão analisados nos próximos parágrafos em função dos dispositivos sem fio e
dos canais de comunicação da grade móvel. Como o colaborador desempenha o
papel mais crítico da arquitetura, os modelos de falhas serão ilustrados em função
do comportamento deste componente, tendo como foco a camada de descoberta
da arquitetura MoGrid.
Fail-Stop. Um dispositivo atuando como um colaborador da grade móvel
é desativado, quer seja por intervenção humana ou por alguma falha no
equipamento, deixando de responder a requisições de serviço e de executar as
requisições com as quais já tenha se comprometido. Nesse caso, o dispositivo não
executará operações inválidas e simplesmente deixará de funcionar, o que não
interferirá no funcionamento da arquitetura como um todo, pois os demais
dispositivos continuarão desempenhando as suas funções corretamente e irão
detectar, com o tempo, a sua indisponibilidade. Existe ainda a possibilidade de um
colaborador que faz parte do caminho de retorno de uma mensagem de resposta
deixar de funcionar, provocando a quebra da rota estabelecida no processo de
descoberta entre um candidato a colaborador e o requisitante do serviço. Nesse
caso, se o mecanismo de reconhecimento do envio de respostas não conseguir
recuperar a falha ocorrida no encaminhamento da resposta, a mesma não será
entregue ao nó requisitante, podendo ser substituída por uma resposta de
qualidade inferior, proveniente de um colaborador com menos recursos mas cujo
caminho reverso tenha se mantido durante o período de tempo transcorrido entre
as etapas de requisição e descoberta do serviço.
Falha Bizantina. As falhas bizantinas ou arbitrárias pressupõe um
comportamento incorreto dos componentes do sistema. Na arquitetura MoGrid, as
entidades de descoberta poderiam gerar mensagens com erro ou mesmo
maliciosas que comprometeriam o funcionamento do protocolo. Além disso, os
nós poderiam gerar mensagens falsas aleatoriamente, como, por exemplo,
iniciadores emitindo requisições de serviço com uma freqüência elevada ou

A Arquitetura MoGrid 58
colaboradores respondendo a requisições de serviço às quais não estejam aptos a
atender. Na arquitetura MoGrid esse tipo de falha não é tratado. Os protocolos
especificados para solucionar o problema do consenso apresentam uma
complexidade computacional extremamente elevada e, em muitos casos,
especialmente em redes instáveis como as redes sem fio ad hoc, apresentam
problemas de convergência [Angluin et al. 2006].
Falhas de Omissão. Falhas como desconexões voluntárias e involuntárias
de dispositivos – provocadas por quebras de rotas em função do particionamento
da rede, atenuação do sinal no enlace sem fio, o problema do terminal oculto,
entre outros – são responsáveis por fazer com que um ou mais componentes da
arquitetura fiquem incomunicáveis por períodos variáveis de tempo. Em
decorrência dessas falhas de comunicação, os dispositivos ficam impossibilitados
de responder a novas requisições de serviço ou mesmo executar as requisições as
quais tenham respondido anteriormente – quando atuando como colaboradores – e
de submeter tarefas para a grade móvel e de receber os resultados da execução das
mesmas – quando atuando como iniciadores. Nesse caso, as conseqüências das
falhas são mais graves.
Falhas Temporais. Esse tipo de falha pode ocorrer em função da falta de
sincronização de relógios entre os dispositivos da grade ou em função de
variações abruptas da latência do sinal do enlace sem fio. Na arquitetura MoGrid,
respostas mais adequadas, provenientes de dispositivos com mais recursos, que
tenham sido atrasadas ou mesmo estejam sendo transmitidas no tempo certo
podem ser suprimidas por respostas menos aptas. Essa situação se verifica caso os
dispositivos que originaram essas respostas antecipem o envio das mesmas ou elas
trafeguem através de enlaces com menor latência. Nesse caso, o requisitante não
deixará de ser atendido, entretanto, o serviço disponibilizado não será o de melhor
qualidade em função das falhas temporais que ocorreram, prejudicando o processo
de seleção das respostas. Analisando as falhas temporais, tem-se que a principal
demanda da camada de descoberta, em relação às camadas inferiores, diz respeito
ao mecanismo de sincronização de relógios entre os dispositivos que constituem a
grade móvel. Para o correto funcionamento da arquitetura, é necessário que a
diferença de velocidade entre os relógios dos dispositivos seja desprezível.

A Arquitetura MoGrid 59
O conceito básico para se implementar tolerância a falhas é redundância,
de hardware ou software. Em termos gerais, a redundância pode assumir dois
formatos: temporal ou espacial. A redundância temporal implica que após a
detecção da falha, uma ação corretiva seja acionada como, por exemplo, a
repetição do procedimento que gerou a falha. Esse tipo de redundância é em geral
menos aplicável a sistemas críticos, já que o procedimento de recuperação pode
violar as especificações rígidas de tempo (hard deadlines). No caso da
redundância espacial, uma mesma ação crítica é executada por vários
componentes replicados. Nesse caso, existe a possibilidade da falha ser mascarada
no sentido de que a falha de um componente é compensada pela ação correta de
outros componentes replicados. A redundância espacial é adequada para sistemas
críticos, por não gerar atrasos extras nos processos de detecção e recuperação de
erros [Macêdo et al. 2004]. Na arquitetura MoGrid, o mecanismo de tolerância a
falhas da camada de descoberta pode ser implementado através de redundância
espacial, onde várias instâncias do mesmo serviço são selecionadas para atender a
uma requisição específica. Na camada de transparência, o mecanismo de
tolerância a falhas pode ser implementado através de redundância temporal, onde
o anúncio de desconexões voluntárias e a detecção de desconexões involuntárias
disparam ações corretivas.
Pelo que foi exposto, é possível observar que a arquitetura MoGrid
pressupõe apenas a ocorrência de falhas do tipo fail-stop, apresentando para esses
tipos de falhas mecanismos de tolerância baseados em redundância espacial.
Entretanto, os mecanismos de redundância implementados não necessariamente
garantem que as respostas às requisições de descobertas obtidas na presença de
falhas sejam as de melhor qualidade. Os problemas decorrentes das falhas
bizantinas, de omissão e temporais podem ser tratados na arquitetura MoGrid
através da camada de transparência. Na Subseção 2.3.2, é apresentada uma
discussão inicial sobre as medidas de correção que podem ser acionadas em
função da ocorrência de falhas de omissão. Soluções para esses tipos de falhas
devem ser incorporadas com a conclusão da especificação da camada de
transparência.

A Arquitetura MoGrid 60
2.5.
Trabalhos Relacionados
Como é possível constatar nos trabalhos publicados na área de grades
computacionais, nos últimos anos, há um interesse crescente em viabilizar
aplicações baseadas na tecnologia de grades, sejam elas móveis ou fixas, para
dispositivos portáteis, o que tem apontado modelos alternativos para computação
em grade. Tal interesse tem motivado o desenvolvimento de grades P2P [Bhatia
2005; Fox et al. 2003; P-Grid 2002] e grades pervasivas [Geyer et al. 2005],
embora na maioria desses trabalhos seja oferecido suporte apenas para que os
dispositivos móveis sejam utilizados, exclusivamente, como interfaces para o
acesso sem fio às grades fixas. Nesta seção, são descritos alguns projetos
específicos que oferecem algum nível de suporte para as grades móveis ou que se
aproximam desse propósito, oferecendo suporte a ambientes móveis de
colaboração. Inicialmente será feita uma breve apresentação desses trabalhos, os
quais serão posteriormente discutidos na Subseção 2.5.1.
ISAM (Infra-estrutura de Suporte às Aplicações Móveis distribuídas)
[Yamin et al. 2003]. Projeto que propõe a integração de três conceitos principais –
consciência do contexto, mobilidade e grade computacional – em um ambiente de
computação pervasiva. Esse ambiente oferece suporte ao desenvolvimento de
aplicações móveis distribuídas que apresentam um comportamento adaptativo.
Pesquisas envolvendo o conceito de grades pervasivas em ambientes P2P foram
desenvolvidas no contexto do projeto ISAM, através do Grupo de Trabalho da
RNP GRADEp [Geyer et al. 2005], no período de 2004 a 2005. O projeto
GRADEp teve, por objetivo, a extensão da perspectiva tradicional de computação
em grade, pela inclusão de aspectos de mobilidade de dispositivos, de usuário e de
componentes das aplicações. O middleware GRADEp oferece suporte a operações
no modo desconectado para dispositivos fixos e móveis em uma grade fixa. O
projeto oferece suporte à mobilidade, considerando em sua especificação que o
ponto de acesso à rede fixa pode mudar com o tempo. Os dispositivos são
associados a um identificador único de modo que eles possam ser localizados na
grade independente do ponto de acesso ao qual eles estão conectados.
Um ambiente de resolução de problemas baseado em grades sem fio
[Kurkovsky et al. 2004]. Este projeto propõe um ambiente de resolução de

A Arquitetura MoGrid 61
problemas baseado em uma grade computacional móvel, organizada através de
uma rede sem fio infra-estruturada, na qual os dispositivos móveis são
visualizados como agentes colaborativos em um sistema multi-agente. Tal
ambiente trata aspectos referentes à distribuição, coordenação e remontagem de
tarefas complexas de grade, lidando com aspectos como instabilidade da rede,
transparência de acesso e fidedignidade. Nesse projeto os dispositivos sem fio
atuam como elementos computacionais da grade propriamente dita,
disponibilizando os seus recursos e serviços, sendo acionados para a execução
colaborativa de tarefas.
AKOGRIMO (Access to KnOwledge through the GRId in a MObile world)
[Akogrimo 2004]. Este é um projeto promovido pelo fundo europeu, com o
propósito de desenvolver arquiteturas e protótipos para as grades de próxima
geração (Next Genaration Grid – NGGs), baseadas na arquitetura OGSA,
motivado pelo crescimento de usuários de dispositivos portáteis na Europa.
Atualmente, o projeto AKOGRIMO tem como foco a proposição de aplicações
inovadoras para grades móveis organizadas através de redes sem fio infraestruturadas
em WLANs (Wireless Local Area Networks), baseadas no protocolo
IPv6, de modo que se possa oferecer serviços aos cidadãos comuns, auxiliando-os
em atividades do seu dia-a-dia em um contexto comercial. O domínio de tais
aplicações abrange e-health, e-learning, gerenciamento de crises e catástrofes,
logística, turismo, entre outros. Entretanto, nas especificações do projeto não há
referências sobre o tratamento dado a dispositivos com restrições de recursos. O
projeto AKOGRIMO trata as questões referentes à mobilidade em um nível mais
elevado, sob a perspectiva de serviços móveis.
MASGRID (Mobile Ad hoc Service Grid) [Ihsan et al 2005]. Nesse
trabalho, os autores propõem uma arquitetura que ofereça funcionalidades
similares às disponíveis no Globus Toolkit [Foster & Kesselman 1997], para o
estabelecimento e utilização de uma grade móvel organizada através de uma rede
sem fio ad hoc, de forma simplificada, de modo que essas funções possam ser
utilizadas pelos dispositivos móveis que a constituem. A arquitetura define dois
mecanismos principais: o serviço de descoberta de recursos (Resource Discovery
Service – RDS) e o serviço de acesso aos recursos (Resource Access Service –
RAS), os quais dependem, respectivamente, dos protocolos de conectividade e de

A Arquitetura MoGrid 62
roteamento, utilizados na MANET. Os autores apresentam um modelo conceitual,
definindo as funções que cada um dos mecanismos deve desempenhar; entretanto,
eles não se detém em aspectos operacionais referentes à sua implementação. A
proposta do mecanismo de descoberta, apesar de ser brevemente apresentada,
recebe maior atenção em relação ao mecanismo de acesso aos recursos.
2.5.1.
Discussão sobre os Trabalhos Relacionados
O surgimento das grades móveis tornou-se viável devido à disponibilidade de
dispositivos móveis com capacidade de processamento e comunicação cada vez
maiores, o que é comprovado pelo número crescente de vendas de notebooks e
PDAs em todo o mundo, chegando a casa dos milhões anualmente. 3
Essa
realidade proporciona um novo tipo de rede de compartilhamento de recursos que
explora a larga disseminação dos dispositivos sem fio que, considerando-se a sua
capacidade de interconexão, promove um ambiente de colaboração que não deve
ser desprezado [McKnight et al. 2004]. Apesar das restrições de recursos
apresentadas por esses dispositivos, em decorrência das suas dimensões cada vez
mais reduzidas, a integração dos dispositivos móveis, interconectados através de
enlaces sem fio, é defendida como uma possibilidade real de colaboração em uma
grade computacional [Phan et al 2002]. O desafio de integração dos dispositivos
sem fio em uma grade móvel é ampliado quando esses dispositivos estão
organizados através de uma MANET de saltos múltiplos, mas não inviabilizado,
como demonstram os estudos apresentados em [Red Herring 2005;
Lima et al. 2005; Gomes et al. 2007].
Nos projetos anteriormente citados nesta seção, não é oferecido suporte ao
desenvolvimento de aplicações de grade baseadas no compartilhamento de
recursos em redes sem fio ad hoc, nas quais é oferecida uma visão mais focada do
conceito de grades móveis – onde a infra-estrutura da rede é dinâmica, devido às
constantes modificações provocadas pela mobilidade dos usuários. Para ilustrar o
3 Segundo o estudo “Worldwide Quarterly PC Tracker” da consultoria IDC referente ao quarto
trimestre de 2006, as vendas de notebooks irão ultrapassar as dos computadores pessoais de mesa

A Arquitetura MoGrid 63
que foi dito, pode-se mencionar o projeto GRADEp que, apesar dos resultados
expressivos na inclusão de dispositivos móveis como elementos computacionais
da grade, não se aplica às grades móveis pois foi desenvolvido para oferecer
suporte à mobilidade de dispositivos e usuários – com ênfase em pervasividade –
em uma grade fixa.
É imprescindível, em uma grade móvel, a adoção de uma abordagem
cooperativa e completamente descentralizada para prover a descoberta e
coordenação de recursos. A abordagem que mais se aproxima desse objetivo é
aquela proposta em [Kurkovsky et al. 2004], que apresenta um ambiente para
solução de problemas para grades móveis organizadas através de uma rede sem
fio infra-estruturada. Entretanto, nessa abordagem, a responsabilidade de
coordenar a distribuição e execução das tarefas da grade é delegada a um
elemento central, conectado à rede fixa. Por outro lado, durante o período de
vigência (2004 – 2007) do contrato europeu para implementação do projeto
AKOGRIMO, vários resultados foram publicados. Esses trabalhos, entretanto,
apesar de também apostarem na utilização dos recursos disponíveis na grade
móvel para a provisão de serviços para os dispositivos da grade, baseiam sua
arquitetura na presença de elementos centrais, com alta concentração de recursos,
para coordenar os mecanismos associados ao compartilhamento de recursos e
serviços.
A arquitetura MASGRID foi especificada para oferecer suporte a grades
móveis ad hoc, entretanto, os mecanismos propostos não foram desenvolvidos, de
modo que não existem resultados que comprovem a sua aplicabilidade. De modo
similar, no projeto coreano K*Grid [KGrid 2002], foi apresentada uma proposta
promissora com o intuito de oferecer suporte à formação de grades móveis
pervasivas, organizadas como WLANs, investindo no uso de recursos ociosos dos
dispositivos sem fio. Entretanto, não há, até o presente momento, nenhum registro
da evolução do projeto K*Grid nessa área específica, motivo pelo qual ele não se
encontra entre os trabalhos apresentados nesta seção.
em 2011. Disponível em . Acesso em: 01 abr. 2007.

A Arquitetura MoGrid 64
Uma outra possibilidade de comparação mais específica, que no entanto
merece ser mencionada, diz respeito aos requisitos da camada de transparência,
descrita na Subseção 2.3.2, os quais se assemelham, em muitos aspectos, às
funcionalidades oferecidas pelas arquiteturas de provisão de qualidade de serviço
(Quality of Service – QoS) para redes sem fio. Nas grades móveis, exemplos de
parâmetros de QoS relacionados à execução de serviços incluem o tempo de
conclusão das tarefas e o grau de precisão dos resultados. Já em relação a
capacidade dos dispositivos da grade móvel, pode-se considerar a taxa de
ocupação do processador, o percentual de memória disponível e a qualidade do
enlace sem fio, entre outros.
No contexto das arquiteturas de provisão de QoS, o middleware
COLOMBA (Context and Location-based Middleware for Binding Adaptation)
[Bellavista et al. 2003] oferece suporte à associação dinâmica de recursos através
da exploração de metadados. Esses metadados são utilizados para descrever
recursos, dispositivos, informações sobre os usuários, estratégias preferenciais e
serviços do middleware. O middleware é estruturado em dois componentes: (i) o
binder manager, que intermedia o acesso aos recursos de acordo com a política
especificada e (ii) o policy manager, que oferece suporte à especificação,
instalação dinâmica e alocação de políticas.
Em [Lima 2002] é proposto um conjunto de frameworks para provisão de
QoS em redes sem fio baseados em conceitos como (i) noção de intervalos de
QoS, (ii) adoção de parâmetros de QoS relacionados à mobilidade, (iii) classes de
QoS, (iv) reservas antecipadas de recursos e (iv) políticas de controle de acesso
aos recursos. Abordagem similar é adotada pelo grupo de pesquisa TIMELY (The
Illinois Mobile Environment LaboratorY), que propõe uma arquitetura de
gerenciamento de recursos adaptativa para ambientes de computação móvel
[Bharghavan et al. 1998]. A arquitetura oferece um modelo de serviços adaptativo
que permite às aplicações e aos gerente de recursos renegociar a QoS em função
de alterações nas condições da rede sem fio.
Como as aplicações de grade exigem um processamento intensivo, elas têm
o seu desempenho afetado pela mobilidade dos dispositivos que participam da sua
execução. Se esses dispositivos apresentam um perfil de mobilidade elevada, isso
pode impactar de forma adversa no tempo necessário para concluir a execução da
tarefa. Fazendo um paralelo entre os mecanismos de gerenciamento de recursos

A Arquitetura MoGrid 65
das arquiteturas de QoS mencionadas anteriormente e os requisitos da camada de
transparência da arquitetura MoGrid, é possível observar que a questão da
mobilidade está diretamente relacionada a questão da provisão de qualidade de
serviço. O objetivo fim das aplicações colaborativas desenvolvidas para as grades
móveis é oferecer aos usuários de dispositivos móveis em redes sem fio as
mesmas garantias de QoS experimentadas pelos usuários de dispositivos
computacionais em redes fixas. Vale ressaltar que mesmo nos ambientes fixos, as
“garantias” oferecidas durante a execução de um serviço não são garantias
“absolutas”, o que se agrava ainda mais em ambientes computacionais móveis,
nos quais essas garantias estão condicionadas à qualidade do enlace sem fio e à
mobilidade dos dispositivos. Dessa forma, as garantias são válidas apenas se os
recursos do dispositivo e do enlace sem fio não sofrerem variações que degradem
o seu desempenho.
Um aspecto de fundamental importância, comum tanto à camada de
transparência – especialmente à subcamada de acesso transparente aos recursos –
quanto às arquiteturas de provisão de QoS, diz respeito ao monitoramento da
qualidade do serviço durante a sua utilização, visando a manutenção da QoS. No
processo de manutenção da QoS, em alguns casos pode mesmo haver a
necessidade da substituição dos provedores de serviço, já que a ocorrência
freqüente de desconexões dos dispositivos pode resultar em um nível de QoS
insatisfatório. De acordo com as especificações definidas na Subseção 2.3.2, na
arquitetura MoGrid essas questões devem ser tratadas na subcamada de acesso
transparente ao recurso, com a substituição dos colaboradores – no caso de
desconexões voluntárias ou involuntárias – e a migração de tarefas; ações que
“garantem” a provisão de um nível mínimo de QoS na grade móvel. Esse
procedimento se assemelha ao mecanismo de sintonização, 4 utilizado nas
arquiteturas de QoS. Esse mecanismo deve ser investigado com o intuito de
enriquecer as discussões quanto aos requisitos necessários para a especificação da
camada de transparência, podendo ser incorporado no seu desenvolvimento, com
algumas adaptações, para atender as necessidades de uma grade móvel.

A Arquitetura MoGrid 66
2.5.2.
Análise Comparativa
A seguir, são definidos, de forma breve, alguns parâmetros para mensurar o
quanto as diferentes propostas, apresentadas nesta seção, adequam-se aos cenários
de mobilidade das redes sem fio, destacando a forma como as características desse
tipo de rede são tratadas nos projetos aqui mencionados. Os parâmetros que serão
apresentados nos próximos parágrafos são utilizados, na Tabela 1, como base de
comparação entre as propostas discutidas nesta seção e a arquitetura MoGrid.
Provisão de Suporte a Redes Sem Fio Infra-estruturadas e Ad hoc. Para
que uma arquitetura de descoberta de recursos e serviços atenda às necessidades
de uma grade móvel, de acordo com a visão defendida nesta tese – onde os
dispositivos sem fio desempenham o papel de elementos computacionais da grade
móvel, não atuando apenas como consumidores de recursos e serviços –, a
arquitetura deve oferecer suporte tanto às redes sem fio infra-estruturadas quanto
às redes sem fio ad hoc.
Gerenciamento de Mobilidade. Em grades móveis, a taxa de mobilidade
dos dispositivos pode ser elevada e o tempo de permanência dos dispositivos na
grade é variável, caracterizando altas taxas de churn. Portanto, é importante que se
considerem aspectos relacionados à mobilidade e, conseqüentemente, aos
períodos de desconexão, na especificação de uma arquitetura para esse ambiente.
Diretório de Serviços Distribuído. Uma arquitetura de descoberta de
recursos e serviços é definida em função do uso de um serviço de diretório – que
pode ser classificado em centralizado ou distribuído – para armazenar as
informações sobre os recursos e serviços disponíveis na grade. A escolha do tipo
de diretório influencia a forma como as informações sobre os serviços são
recuperadas no processo de descoberta. No caso de um diretório centralizado, os
clientes devem inicialmente obter a identificação de rede do diretório para então
consultá-lo sobre os serviços disponíveis. Nesse caso, pode-se ainda implementar
no diretório um mecanismo de notificação de informações sobre os serviços, que é
4 Na provisão de QoS o mecanismo de sintonização é responsável pelo redimensionamento da
parcela de utilização dos recursos, a qual foi disponibilizada ao usuário do serviço durante a

A Arquitetura MoGrid 67
ativado a partir do registro de interesse do cliente a respeito de informações sobre
recursos e serviços específicos. No caso de um diretório distribuído, cada
dispositivo da rede deve armazenar localmente as informações a respeito dos
serviços que ele próprio disponibiliza, podendo ainda utilizar uma estratégia de
cache para armazenar também as informações sobre os demais serviços oferecidos
na grade, obtidas através de um mecanismo de anúncios periódicos de serviços.
Essa abordagem é recomendada para as redes sem fio ad hoc nas quais a ausência
de qualquer infra-estrutura pré-existente obriga que os serviços oferecidos sejam
especificados de forma flexível e distribuída, sem a dependência de um ponto
central de coordenação. O uso de diretórios de serviços distribuídos evita que o
deslocamento ou mesmo a desconexão dos dispositivos comprometa o
funcionamento do mecanismo de descoberta da grade móvel.
Transparência de Acesso. Uma arquitetura de descoberta de serviços deve
oferecer mecanismos que garantam a transparência de acesso ao recurso pelo
dispositivo que o solicita. Na grade móvel, o importante é a disponibilidade do
recurso e não a sua origem ou localização. A arquitetura deve oferecer suporte ao
gerenciamento do problema da desconexão dos dispositivos móveis, tanto as
voluntárias quanto as involuntárias.
Heterogeneidade. Nas grades móveis, um fator de complexidade adicional
diz respeito à heterogeneidade de hardware, de software e dos ambientes nos
quais os dispositivos sem fio estão conectados, envolvendo diferentes tecnologias
de rede, como Ethernet, Wi-Fi, celular, entre outros. Os novos ambientes
propostos pelas grades móveis apontam para o compartilhamento de recursos e
serviços através de redes com enlaces intermitentes e dispositivos finais que não
necessariamente adotam políticas de segurança. Nesse novo ambiente, é
importante a adoção de mecanismos para descoberta e acesso aos recursos e
serviços que sejam independentes do protocolo de roteamento utilizado na
MANET e não se restrinjam a uma tecnologia de rede sem fio específica. Outro
fator que deve ser considerado é a diversidade de plataformas de hardware e
sistemas operacionais. É de fundamental importância a utilização de mecanismos
negociação da QoS, na fase de estabelecimento do contrato de serviço.

A Arquitetura MoGrid 68
para oferecer portabilidade como, por exemplo, o uso de uma linguagem de
desenvolvimento multiplataforma.
Migração de Execução. Um problema específico que deve ser considerado
é a migração da execução de tarefas entre colaboradores quando, por exemplo, um
dispositivo infere que está prestes a perder a sua conectividade com a grade móvel
que ele integra. A migração de tarefas deve ser realizada, idealmente, com a
manutenção do estado de execução, o que aumenta consideravelmente a sua
complexidade. Outro fator agravante nesse processo diz respeito a
heterogeneidade de dispositivos, o que implica em hardware e software distintos
entre os dispositivos da grade móvel; esse fator deve ser considerado ao se definir
uma API para a migração de execução de tarefas.
Descrição de Recursos. A descrição de recursos deve ser implementada de
forma padronizada a fim de garantir a uniformidade entre as requisições e as
descrições de recursos publicadas, promovendo a interoperabilidade entre redes e
equipamentos. É importante considerar mecanismos de adaptação que
possibilitem a extensão do modelo adotado, sem prejuízo ao processo de
descoberta.
A Tabela 1 apresenta um resumo comparativo entre os trabalhos
apresentados nesta seção e a arquitetura MoGrid. Os símbolos “T”, “NT”, “PT” e
“” indicam, respectivamente, “tratado”, “não tratado”, “parcialmente tratado” e
“não pôde ser avaliado”.

A Arquitetura MoGrid 69
Tabela 1 – Resumo comparativo dos projetos relacionados à arquitetura MoGrid.
MoGrid
ISAM/
GRADEp
[Kurkovsky
et al. 2004]
AKOGRIMO
MASGRID
Rede Sem Fio:
Infra-estruturada
Ad hoc
T
T
T
NT
T
NT
T
NT
T
NT
Gerenciamento de Mobilidade PT NT PT T T
Diretório de Serviços Distribuído T NT NT NT 5 T
Transparência de Acesso PT T T
Heterogeneidade T NT NT NT NT
Migração de Execução NT PT 6 NT PT NT
Descrição de Recursos PT PT T NT
Dentre as arquiteturas apresentadas as abordagens propostas em [Kurkovsky
et al. 2004], AKOGRIMO e MASGRID são as que mais se aproximam da visão
de grade móvel defendida nesta tese, ou seja, um ambiente onde os dispositivos
móveis atuam como elementos computacionais da grade propriamente dita.
Dessas propostas, apenas a arquitetura MASGRID se propõe a oferecer suporte a
uma grade móvel ad hoc, as demais se limitam a uma WLAN infra-estruturada,
apresentando dependências quanto às tecnologias de rede e de software, o que
viola a condição de heterogeneidade inerente às grades móveis. Entretanto, a
arquitetura MASGRID é apresentada como uma proposta preliminar, sem
especificar detalhes a respeito das soluções adotadas e muito menos oferecer uma
implementação que possa ser utilizada. Por sua vez, nas soluções apresentadas em
[Kurkovsky et al. 2004] e AKOGRIMO a especificação da arquitetura de
descoberta de recursos se baseia na presença de um elemento central, um
dispositivo rico em recursos conectado tanto à rede fixa quanto à rede móvel. Essa
solução é inviável para as grades móveis organizadas através de redes sem fio ad
hoc devido a ausência de um elemento central estável que possa gerenciar os
processos de descoberta de recursos e de execução de tarefas, dado que nesse tipo
5
Adota um serviço de diretório centralizado, baseado em uma implementação do SLP
[Guttman 1999].
6 A migração da execução de tarefas no GRADEp é gerenciada pelo próprio usuário, de forma
programada, e seu alcance se restringe ao escopo da rede local; não há gerenciamento de
mobilidade física.

A Arquitetura MoGrid 70
de rede todos os dispositivos são móveis e todos se conectam através do enlace
sem fio. Além disso, em redes ad hoc situações de particionamento são
freqüentes, o que provocaria a ausência do serviço de diretório, por um período
indeterminado, em n-1 partições da rede, considerando n igual ao número de
partições. A única alternativa que pode minimizar o efeito do particionamento das
redes ad hoc na disponibilização das informações sobre os serviços da grade é a
replicação dessas informações através da utilização de vários servidores de
diretórios. Entretanto, ao se aumentar o número de servidores cria-se um novo
problema, o da manutenção da consistência entre eles, cuja solução apresenta um
nível de complexidade elevado em redes fixas, o qual pode crescer
consideravelmente em redes sem fio ad hoc, inviabilizando o uso dessa alternativa
[Carter et al. 2003; Farkas et al. 2004].
2.5.3.
Contribuições Alcançadas
A arquitetura MoGrid foi proposta com o intuito de oferecer suporte ao
desenvolvimento de aplicações para grades móveis e auxiliar a tomada de
decisões referentes à descoberta e à seleção de recursos, bem como ao acesso e a
utilização desses recursos. Algumas propostas foram desenvolvidas para oferecer
suporte às grades móveis, entretanto, a maior parte dessas propostas tem adotado
abordagens centralizadas, baseadas em redes fixas ou em redes sem fio infraestruturadas
[Yamin et al. 2003; Kurkovsky et al. 2004]. A arquitetura MoGrid é
independente de elementos centralizados e provê um ambiente de execução de
tarefas que oferece, ao desenvolvedor de aplicações de grade, um conjunto de
funcionalidades que tratam os aspectos relacionados à colaboração entre
dispositivos heterogêneos em uma rede sem fio.
Esta tese traz entre as suas principais contribuições a especificação de uma
arquitetura para grades móveis que oferece suporte tanto às redes sem fio infraestruturadas
quanto às redes sem fio ad hoc, tendo sido concebida de modo a
também ser integrável com tecnologias de grade fixa. A arquitetura MoGrid adota
uma abordagem peer-to-peer, totalmente descentralizada, independente da
tecnologia de rede utilizada e de protocolos de roteamento em uso na MANET,
tendo sido projetada para atender às necessidades específicas das grades móveis.

A Arquitetura MoGrid 71
Por ter sido especificada de forma modular, adotando uma abordagem em
camadas, os diferentes mecanismos relacionados à descoberta (camada de
descoberta) e à utilização de serviços (camada de transparência) são separados,
podendo ser utilizados como módulos independentes, acoplados, inclusive, em
outras arquiteturas. Como é o caso do protocolo de descoberta e seleção de
recursos P2PDP (Capítulo 4) e do algoritmo de supressão de mensagens de
resposta por vizinhança (Seção 4.6).
No próximo capítulo, os trabalhos relacionados à área-tema desta tese –
descoberta de serviços para redes sem fio ad hoc – são apresentados. As
peculiaridades de cada trabalho ilustram os diferentes critérios apontados na
classificação genérica para os protocolos de descoberta de serviços introduzidos
no mesmo capítulo. Na revisão bibliográfica é dada uma maior ênfase aos
trabalhos que tratam, especificamente, da descoberta de serviços em redes sem fio
ad hoc de saltos múltiplos, abordagem similar à adotada no protocolo para
descoberta e seleção de recursos em grades móveis ad hoc proposto nesta tese,
denominado P2PDP (Peer-to-Peer Discovery Protocol). O protocolo P2PDP é
descrito em detalhes no Capítulo 4.

3
Trabalhos Relacionados à Descoberta de Serviços
3.1.
Apresentação
Descoberta de serviços é um tópico que sempre despertou muito interesse de
pesquisa e desenvolvimento nas áreas de sistemas distribuídos e redes de
computadores, originando propostas nos mais diversos cenários, tanto para redes
fixas quanto redes sem fio. Durante muito tempo, os protocolos de descoberta de
serviços seguiram o modelo clássico de aplicações cliente-servidor. Nessa visão,
de uma forma geral, servidores centralizados atuam como diretórios, armazenando
um índice global dos serviços disponíveis na rede e gerenciando todo o processo
de descoberta. Devido a essas características, esses protocolos são mais adequados
a redes fixas. Dentre os protocolos que fazem parte desse modelo, destacam-se
Jini [Sun 1999a] da Sun, Salutation [Salutation 1999] da IBM e SLP (Service
Location Protocol) [Guttman 1999] da IETF. 1 Esses protocolos foram adaptados
para dispositivos móveis conectados através de redes locais sem fio infraestruturadas;
a maioria com o objetivo de atender às necessidades das redes
domésticas e empresariais por recursos e serviços de hardware – como
impressoras multifuncionais, projetores multimídia, entre outros. As soluções
obtidas nada mais são do que uma adaptação da solução original, desenvolvida
para ambientes fixos, onde servidores centralizados oferecem suporte ao
mecanismo de descoberta a serviços específicos, o que restringe a sua
aplicabilidade. O protocolo UPnP [UPnP 2000] apresenta proposta similar aos
protocolos mencionados anteriormente, entretanto, o UPnP não adota o
1 Por não ser o foco deste trabalho, esses protocolos não serão discutidos em mais detalhes,
entretanto, na Tabela 2 é feito um resumo com as suas principais características, de acordo com os
critérios de classificação apresentados na Seção 3.2. Maiores informações sobre esses protocolos
podem ser encontradas em [Lima et al. 2007a].

Trabalhos Relacionados à Descoberta de Serviços 73
mecanismo de diretórios de serviços, apresentando uma abordagem distribuída
que utiliza comunicação peer-to-peer.
O interesse crescente em viabilizar o compartilhamento de recursos e
serviços entre dispositivos móveis, organizados através de uma rede sem fio, tem
motivado o surgimento de modelos alternativos. Existem alguns protocolos
desenvolvidos, especificamente, para oferecer suporte às redes sem fio ad hoc de
salto único, dentre os quais se destacam o Bluetooth SDP [Bluetooth 2001] e o
DEAPspace [Nidd 2001; Hermann et al. 2001]. Por sua vez, a pesquisa na área de
descoberta de serviços em redes sem fio ad hoc de saltos múltiplos é
relativamente nova, ainda não existindo um padrão consolidado que possa ser
utilizado pela indústria. O principal motivo para a falta de maturidade dos
protótipos produzidos, deve-se à mobilidade irrestrita dos dispositivos, os quais
podem entrar e sair, espontaneamente, do sistema. Esse tipo de rede, de uma
forma geral, é associado à formação de grupos de colaboração temporários – por
exemplo, em situações de resgate em grandes áreas e na cooperação veicular em
auto-estradas e no trânsito das grandes cidades, através de redes veiculares
(Vehicular Area Networks – VANs) – ou ao estabelecimento de redes de sensores
– por exemplo, em regiões inóspitas e vastas, como florestas densas –, adequandose
a situações onde não existe uma infra-estrutura de comunicação ou a infraestrutura
existente não está disponível. Nesses cenários, tanto a demanda quanto a
disponibilidade de recursos e serviços podem apresentar uma variabilidade sem
par, em comparação aos cenários de redes fixas e redes sem fio ad hoc de salto
único. Dentre algumas das principais propostas de protocolos de descoberta de
serviços, da academia, para MANETs de saltos múltiplos, pode-se mencionar:
GSD (Group-based Service Discovery) [Chakraborty et al. 2002; Chakraborty et
al. 2005; Chakraborty et al. 2006], Allia (Allia-nce) [Ratsimor et al. 2002;
Ratsimor et al. 2004], Konark [Lee et al. 2003; Helal et al. 2003], ORION
(Optimized Routing Independent Overlay Network) [Klemm et al. 2003], a
abordagem cross-layer de Varshavsky et al. [2005] e a abordagem FTA (Field
Theoretic Approach) que se baseia na teoria de campo eletrostático [Lenders et al.
2005]. Esses protocolos serão discutidos mais adiante, ilustrando a classificação
proposta para os protocolos de descoberta de serviços apresentada na Seção 3.2.

Trabalhos Relacionados à Descoberta de Serviços 74
3.2.
Classificação dos Protocolos de Descoberta de Serviços
Os protocolos de descoberta de serviços existentes geralmente empregam
terminologias específicas com o propósito de ressaltar as características positivas
dos mesmos, identificadas como aspectos singulares de cada proposta em relação
ao estado da arte. A utilização de uma terminologia comum para a classificação
auxilia na análise das vantagens e desvantagens das diferentes abordagens,
revelando-se um mecanismo de comparação eficiente. A seguir, será apresentada
uma classificação obtida a partir da avaliação de diferentes protocolos de
descoberta de serviços encontrados na literatura, bem como da convergência das
classificações propostas para esses trabalhos por diferentes autores [Marin-
Perianu et al. 2005; Cho & Lee 2005; Zhu et al. 2005; Edwards 2006; Mian et al.
2006; Seno et al. 2007]. Essa classificação foi elaborada levando-se em
consideração um conjunto de critérios que se constituem em uma base de
comparação, a saber:
• A arquitetura de descoberta de serviços. Uma arquitetura especifica a
organização de qualquer sistema e o modo como os seus principais
componentes estão conectados entre si. As arquiteturas de descoberta de
serviços podem adotar uma abordagem baseada no uso de diretórios de
serviços centralizados, os quais são responsáveis pelo processamento de
anúncios e consultas em nome de todos os dispositivos da rede, ou
distribuídos, onde cada dispositivo é responsável por manter as
informações sobre os serviços que disponibiliza ou conhece;
• O escopo da descoberta de serviços. O escopo da descoberta corresponde
ao conjunto de serviços que podem ser descobertos por um dado cliente.
A determinação do escopo de um protocolo de descoberta permite o
controle dos mecanismos que são utilizados para obter informações sobre
os serviços na rede. A definição do escopo da descoberta é feita com base
em critérios, como a topologia da rede, as permissões de acesso
embutidas nos diferentes papéis de usuário em um domínio
administrativo e as informações de contexto de alto nível – tais como as
informações temporais (como data, hora e fuso horário), espaciais (como
latitude, longitude e posição relativa) e àquelas relacionadas às atividades

Trabalhos Relacionados à Descoberta de Serviços 75
desempenhadas pelos usuários dos dispositivos no seu dia-a-dia. Em
protocolos de descoberta de serviços distribuídos, cujo escopo é definido
em função da topologia da rede, o alcance do mecanismo de descoberta é
determinado, em parte, pelas regras de roteamento em vigência. Nesses
protocolos, a requisição de serviço pode ser encaminhada apenas aos
dispositivos que constituem a rede local do dispositivo que a originou, ou
alcançar dispositivos em outras redes físicas, a vários saltos de distância
de onde a requisição foi originada. Em protocolos de descoberta de
serviços centralizados, baseados na estrutura de diretórios, o escopo pode
ser expandido interconectando-se diretórios em diferentes domínios
administrativos com relações de confiança previamente estabelecidas;
nesses sistemas, pode-se empregar políticas de controle de acesso aos
serviços com base na autenticação dos usuários dos dispositivos, segundo
os seus papéis;
• As técnicas de descrição de serviços. Descrição de serviço é uma
abstração das características e facilidades inerentes a um serviço. Essa
abstração torna-se necessária em diferentes etapas do processo de
descoberta: (i) quando um serviço, na arquitetura baseada no uso de
diretórios centralizados, é registrado pelo seu provedor junto ao diretório;
(ii) quando um provedor, na arquitetura baseada no uso de diretórios
distribuídos, divulga na rede, através de mensagens de anúncios, a
disponibilidade dos serviços que oferece; e (iii) quando o serviço é
requisitado por outros dispositivos ou mesmo por outros serviços. Em um
protocolo de descoberta, os clientes procuram por um serviço específico
consultando as descrições de serviços anunciadas pelos provedores ou
enviando uma requisição à rede contendo a descrição do serviço que
desejam. Existem duas abordagens empregadas com maior freqüência: os
pares atributo-valor e as linguagens de descrição. Serviços descritos
através de pares atributo-valor, que é o formato mais comumente
utilizado em protocolos de descoberta, são representados através de um
nome e de um conjunto de atributos. Serviços descritos através de

Trabalhos Relacionados à Descoberta de Serviços 76
linguagens de descrição permitem uma representação do serviço através
do uso de ontologias; 2
• O mecanismo de consulta às informações de serviços. O método de
consulta utilizado em um protocolo de descoberta de serviços pode ser
entendido como um processo de busca atrelado a um casamento
(matching) entre as requisições de descoberta (demandas) e as descrições
de serviços locais e remotos (ofertas), estas últimas divulgadas através de
anúncios ou registradas em diretórios. O algoritmo de matching utilizado
pelo mecanismo de consulta representa uma função que aceita, como
entrada, a demanda e um conjunto de descrições de ofertas, provendo,
como resultado, o subconjunto das ofertas que satisfazem a demanda
especificada. Segundo [Gonzalez-Castillo et al. 2001], pode-se alcançar
uma melhoria do processo quando o algoritmo retorna uma lista ordenada
das k melhores ofertas, para cada demanda. Uma vez que o processo de
matching é baseado em comparações, linguagens que permitam, de forma
natural, especificar tipos, restrições e relações entre conceitos agregam
valor semântico ao protocolo de descoberta de serviços, como ocorre com
as linguagens de descrição baseadas em XML [W3C 2001; W3C 2004];
• O armazenamento das informações de serviços. Informações de serviço
são divulgadas pelo provedor do serviço (ou diretório) através de
mecanismos de anúncio ou em resposta a mensagens de requisição. A
informação de um serviço é utilizada para descrever, identificar e
selecionar o serviço na rede. A informação pode incluir o nome do
serviço, o seu identificador, o endereço do provedor do serviço, o
protocolo que o cliente e o provedor devem utilizar para invocar o
serviço, o período no qual a informação é válida, entre outros itens. As
informações sobre os serviços devem ser armazenadas em repositórios, de
modo que os demais dispositivos possam recuperá-las e contactar o
provedor de um serviço particular. De acordo com o modo como esses
2 Em ciência da computação, uma ontologia é um modelo de dados que representa um domínio
específico. Ontologias permitem que se façam inferências sobre os objetos em um dado domínio e
sobre as relações entre eles [Berners-Lee et al. 2001].

Trabalhos Relacionados à Descoberta de Serviços 77
repositórios são organizados, eles são classificados como centralizados ou
distribuídos. Na primeira abordagem, as informações sobre todos os
serviços disponíveis na rede são armazenadas em diretórios
compartilhados com acesso centralizado. Na segunda abordagem, os
dispositivos da rede possuem o seu próprio repositório local, onde
armazenam informações sobre os serviços que disponibilizam, assim
como sobre os serviços divulgados na rede. A abordagem distribuída pode
ainda ser subdividida em cooperativa, quando os nós mantêm
informações parciais sobre os serviços da rede, que se complementam, e
não cooperativa, quando os dispositivos armazenam as informações sobre
todos os serviços da rede, mantendo uma visão global do sistema. O
mecanismo utilizado para determinar a validade das informações sobre
um serviço define se essas informações estão armazenadas como soft
state ou hard state. Quando as informações sobre os serviços são
mantidas na forma soft state – estratégia comumente empregada no
armazenamento distribuído – a sua validade é especificada na mensagem
de anúncio e precisa ser atualizada, periodicamente, pelo seu provedor,
antes que expire, o que tornaria o serviço inalcançável. Quando as
informações sobre os serviços são mantidas como hard state, elas só são
removidas se o provedor do serviço solicitar, explicitamente, a sua
remoção ou for constatada a indisponibilidade do serviço, ao se tentar
utilizá-lo;
• Os mecanismos de descoberta de serviços. Os mecanismos de descoberta
podem ser utilizados para localizar o dispositivo que hospeda o diretório
responsável por armazenar as informações sobre os serviços da rede ou
para localizar diretamente os dispositivos provedores de serviços. A
abordagem adotada no processo de descoberta depende da arquitetura de
descoberta e de como os serviços são registrados. Basicamente, existem
duas formas para se consultar informações sobre os serviços disponíveis
na rede: a descoberta passiva, onde os provedores anunciam
periodicamente os seus serviços para toda a rede, e a descoberta ativa,
onde o cliente envia requisições de descoberta para provedores ou

Trabalhos Relacionados à Descoberta de Serviços 78
diretórios com o intuito de obter informações sobre um serviço específico
ou sobre todos os serviços disponíveis;
• Os mecanismos de seleção de serviços. Embora o escopo do mecanismo
de descoberta restrinja o número de respostas recebidas pelo cliente, o
resultado de uma requisição a um determinado serviço pode conter não
somente informações de um, mas de vários provedores do mesmo serviço.
Neste caso, o ideal é que o melhor provedor seja selecionado, sem que
haja a necessidade de interferência do usuário. Os protocolos de
descoberta podem oferecer opções de seleção manual, com a intervenção
direta do usuário da aplicação, ou automática, através de um algoritmo
implementado no lado cliente, selecionando a melhor opção em função
das características da aplicação. Nos protocolos de descoberta que
utilizam repositórios centralizados, o algoritmo de seleção pode ser
implementado no próprio diretório, que se encarrega de fazer a seleção do
melhor serviço, em nome do cliente, de acordo com critérios
especificados na requisição;
• O mecanismo de invocação de serviços. Embora seja um tópico à parte,
muitos protocolos de descoberta de serviços tratam a questão da
invocação do serviço. Depois que a seleção é processada, o protocolo de
descoberta de serviços pode oferecer mecanismos para que o cliente
utilize o serviço, a partir das informações contidas na resposta
selecionada. Os protocolos de descoberta oferecem suporte à invocação
de serviços em três níveis diferentes, que podem ser cumulativos. No
primeiro nível, o cliente obtém a localização do serviço, através do
mecanismo de descoberta, e se conecta diretamente ao provedor que o
oferece através do seu endereço de rede; as aplicações que utilizam o
protocolo de descoberta são responsáveis por definir o mecanismo de
comunicação entre clientes e servidores e o conjunto de operações
disponíveis no serviço. Em um segundo nível, o protocolo de descoberta
especifica os mecanismos de comunicação entre os clientes e os serviços.
Em um terceiro nível, o protocolo de descoberta pode definir um conjunto
de operações específicas para um domínio de aplicação, em adição à
localização do serviço e ao mecanismo de comunicação;

Trabalhos Relacionados à Descoberta de Serviços 79
• Os mecanismos para oferecer suporte à mobilidade. O suporte à
mobilidade implica que a informação sobre os serviços disponíveis na
rede, quer seja armazenada em diretórios centralizados ou distribuídos,
deva ser atualizada em função das modificações na topologia da rede,
provocadas pela mobilidade dos dispositivos. Caso as informações
mantidas por um dispositivo sobre os serviços da rede estejam obsoletas,
há uma grande chance desse dispositivo responder a uma requisição de
serviço com informações desatualizadas. Ao receber a resposta a sua
solicitação, o cliente tentará acessar o serviço e, só então, irá detectar a
sua indisponibilidade, pois o provedor do serviço pode ter se deslocado
ou se tornado inalcançável;
• Os mecanismos de segurança. A questão da segurança apresenta vários
desafios no projeto de protocolos de descoberta de serviços,
especialmente em MANETs. A necessidade de se atender a requisitos de
usabilidade, como configuração automática, implementação simplificada
e redução do tráfego de mensagens de controle na rede, implica na adoção
de esquemas de segurança muito simples. Uma grande parte dos
protocolos de descoberta de serviços encontrados na literatura não tratam
a questão da segurança ou apenas a embutem em suas propostas,
utilizando as soluções implementadas nas tecnologias sobre as quais elas
se baseiam. No projeto de alguns protocolos de descoberta de serviços, é
possível constatar a tentativa de inserir um nível mínimo de controle com
fins de segurança, como acontece no Bluetooth SDP, com a provisão de
mecanismos opcionais de criptografia da comunicação no nível de enlace,
e no Allia, com a especificação de políticas de segurança próprias,
baseadas na percepção do usuário. Além de restringir a usabilidade, em
MANETs, a implementação de mecanismos de segurança adiciona
também um alto custo computacional ao projeto de um protocolo de
descoberta de serviços. Entretanto, essa medida pode se mostrar
necessária em ambientes onde usuários que não possuem uma relação de
confiança pré-estabelecida se comunicam livremente, constituindo
comunidades virtuais com potencial para colaboração.

Trabalhos Relacionados à Descoberta de Serviços 80
Nas próximas seções, os protocolos de descoberta de serviços para redes
sem fio ad hoc, mencionados na Seção 3.1, são revisitados em função da
classificação aqui apresentada. É importante registrar que apenas os critérios
relevantes ao projeto de um protocolo de descoberta e seleção de recursos para
grades móveis ad hoc serão apresentados nas próximas seções, a saber: os
mecanismos de descoberta de serviços, o mecanismo de seleção de serviços e os
mecanismos para oferecer suporte à mobilidade. Os exemplos que serão utilizados
restringem-se aos protocolos de descoberta de serviços projetados para as
MANETs, por essa abordagem estar diretamente relacionada com o trabalho
desenvolvido nesta tese: o projeto, a implementação e a avaliação de desempenho
de um protocolo de descoberta e seleção de recursos para grades móveis
organizadas através de redes sem fio ad hoc de saltos múltiplos, denominado
P2PDP (Peer-to-Peer Discovery Protocol), o qual é descrito em detalhes no
Capítulo 4. Maiores informações sobre a classificação aqui apresentada e sobre as
peculiaridades de cada protocolo de descoberta mencionado na Seção 3.1 podem
ser encontradas em [Lima et al. 2007a].
3.2.1.
Os Mecanismos de Descoberta de Serviços
Os mecanismos de descoberta podem ser utilizados para localizar o dispositivo
que hospeda o diretório responsável por armazenar as informações sobre os
serviços da rede ou para localizar diretamente os dispositivos provedores de
serviços. A abordagem adotada no processo de descoberta depende da arquitetura
de descoberta e de como os serviços são registrados. Basicamente, existem duas
formas para se consultar informações sobre os serviços disponíveis na rede
(Figura 7): a descoberta passiva, onde os provedores anunciam periodicamente os
seus serviços para toda a rede, como ocorre no DEAPspace, e a descoberta ativa,
onde o cliente envia mensagens de descoberta para provedores ou diretórios com
o intuito de obter informações sobre um serviço específico ou sobre todos os
serviços disponíveis, como no Bluetooth SDP e no ORION. Essas abordagens
também são conhecidas, na literatura, como proativa e reativa, respectivamente,
em uma alusão à classificação utilizada com os protocolos de roteamento planos
para MANETs. Na maioria dos casos, os protocolos de descoberta de serviços
implementam ambas as abordagens, como acontece com os protocolos GSD,

Trabalhos Relacionados à Descoberta de Serviços 81
Allia, Konark, ORION, FTA e com a abordagem cross-layer de Varshavsky et al.
[2005].
Figura 7 – Mecanismos de descoberta de serviços.
3.2.1.1.
Descoberta Passiva
Nessa abordagem, quando um serviço anuncia as suas características e a sua
disponibilidade, todas as partes envolvidas recebem essa informação. Na
arquitetura baseada no uso de diretórios centralizados, os provedores registram as
informações sobre os serviços que disponibilizam junto aos diretórios e esses
fazem anúncios periódicos divulgando os serviços que gerenciam. Na arquitetura
baseada no uso de diretórios distribuídos, os clientes mantêm atualizado o seu
conhecimento sobre os serviços disponíveis através dos anúncios de serviços que
são difundidos, periodicamente, na rede, pelos provedores de serviços. Um
dispositivo pode emitir anúncios contendo apenas informações sobre os serviços
que disponibiliza, ou incluir também informações sobre os serviços oferecidos por
outros dispositivos do sistema a respeito dos quais tenha conhecimento, como
acontece no DEAPspace, GSD, FTA e na a abordagem cross-layer de
Varshavsky et al. [2005]. Em alguns protocolos, as informações sobre os serviços
remotos se restringem àquelas referentes aos dispositivos na vizinhança do
receptor do anúncio. Entretanto, existem abordagens que defendem a replicação
das informações sobre os serviços da rede em todos os dispositivos, criando uma
visão global do sistema em cada dispositivo. Este é o caso do DEAPspace, onde
os dispositivos anunciam, em janelas de tempo reservadas, a sua visão global do
sistema. No Konark, é proposto o mecanismo de anúncio incremental, como uma
melhoria à abordagem apresentada no DEAPspace, onde a consistência da visão
global é obtida por um mecanismo de filtragem: cada anúncio corresponde à
diferença (delta) entre o conhecimento adquirido pelo dispositivo e a visão global

Trabalhos Relacionados à Descoberta de Serviços 82
divulgada pelos demais dispositivos da rede (Figura 8). Esse mecanismo
caracteriza um “protocolo epidêmico”, também conhecido como protocolo de
disseminação de “rumores” (gossip). O objetivo do mecanismo de disseminação é
compartilhar o conhecimento da visão global de serviços disponíveis no sistema
entre todos os nós da rede, com a máxima convergência, gerando a menor
quantidade possível de tráfego de mensagens de anúncio. Como avaliado em [Lee
et al. 2003], a extensão ao protocolo Konark baseada na disseminação de rumores
(Konark gossip) obtém uma convergência tão rápida quanto a alcançada pelo
DEAPspace-plus, 3 com um tráfego de dados bem menor, o que o torna mais
eficiente. Entretanto, o funcionamento do protocolo de descoberta Konark é
atrelado a pré-existência de um mecanismo que ofereça suporte ao roteamento
multicast na MANET.
Figura 8 – Mecanismo de anúncio incremental do Konark.
Em muitas propostas, é definido um parâmetro configurável denominado
“diâmetro do anúncio”, responsável por delimitar o alcance dos anúncios em
termos do número de saltos que eles irão percorrer, como é o caso dos protocolos
GSD, Allia e FTA. Em uma rede de salto único, o diâmetro corresponde a “0”,
3 DEAPspace-plus corresponde a uma extensão ao protocolo DEAPspace que oferece suporte às
redes sem fio ad hoc de saltos múltiplos.

Trabalhos Relacionados à Descoberta de Serviços 83
enquanto que, em redes de saltos múltiplos, esse valor é definido no intervalo
fechado [1, n], onde n representa o limite máximo.
No protocolo GSD, os nós efetuam anúncios periódicos para seus vizinhos,
anúncios esses restritos a um número de saltos configurável. Ao receber uma
mensagem de anúncio, as informações referentes aos serviços são extraídas e
armazenadas localmente como soft state, até que a sua validade expire, quando
elas são removidas do repositório de serviços do dispositivo. As mensagens de
anúncio de serviços carregam, de carona, informações sobre os grupos de serviços
anunciados na vizinhança do nó. As informações sobre grupos de serviço
viabilizam o mecanismo de matching aproximado, oferecendo resultados
aproximados a uma consulta. Por exemplo, se a requisição especifica uma
impressora InkJet, o mecanismo de matching faz uma consulta considerando o
grupo ao qual o serviço pertence (Printer). Dessa forma, é possível descobrir
uma impressora LaserJet presente na vizinhança; a resposta a essa requisição
trará informações sobre os dois serviços, impressora InkJet e impressora
LaserJet.
No Allia, os anúncios podem ser de dois tipos: anúncio de serviço e anúncio
de plataforma (ou dispositivo). Os anúncios de serviço transportam informações
sobre os serviços disponibilizados pelo dispositivo anunciante. Esses anúncios
podem ser emitidos periodicamente ou em função de eventos específicos, como
quando um agente no dispositivo recebe um novo anúncio ou detecta a presença
de um novo dispositivo na vizinhança. Os anúncios de plataforma servem para um
dispositivo notificar seus vizinhos sobre a sua presença, e são emitidos
periodicamente. Um anúncio de plataforma serve ainda para atualizar a validade
das informações divulgadas pelos anúncios de serviços do dispositivo anunciante.
No Allia, a periodicidade de envio do anúncio pode ser ajustada em função de
políticas locais. Várias políticas podem ser utilizadas para ajustar as taxas de
envio, como mencionado a seguir. Em redes estáveis, pode-se empregar uma taxa
de freqüência constante de anúncios. Nos cenários de topologia dinâmica, pode-se
adotar o algoritmo MILD (Multiplicative Increase Linear Decrease) ou o BEB
(Binary Exponential Back-off), para aumentar a freqüência de envio dos anúncios
de serviços. Uma terceira abordagem reduz a freqüência com que os anúncios são
gerados, restringindo o seu envio à detecção da presença de novos dispositivos,

Trabalhos Relacionados à Descoberta de Serviços 84
caracterizando um aumento na taxa de mobilidade da MANET, o que se infere
através do recebimento de novos anúncios de serviços. Uma característica
particular do Allia é a formação de “alianças” (Allia-nce) de dispositivos. A
aliança de um dado dispositivo consiste no conjunto de dispositivos dos quais ele
armazena anúncios de serviço. Tanto o número de membros quanto o diâmetro de
uma aliança são determinados pela política local do dispositivo. O número de
membros está associado ao número de anúncios remotos que podem ser
armazenados pelo nó, já o diâmetro, ao número de saltos que os anúncios podem
percorrer. Em ambientes altamente dinâmicos, é recomendada a redução do
diâmetro da aliança, para evitar que as informações armazenadas a partir dos
anúncios de serviço tornem-se obsoletas muito rapidamente, devido ao constante
deslocamento dos nós. No Allia, o uso de políticas locais garante a flexibilidade
do protocolo e a sua adaptabilidade, em tempo de execução, às características do
ambiente, à capacidade do dispositivo, às configurações específicas das aplicações
hospedadas pelo dispositivo e às preferências do usuário.
A idéia central, em torno da qual a abordagem FTA foi desenvolvida,
baseia-se na distribuição das informações sobre os serviços para toda a vizinhança
da rede usando uma analogia com campos eletrostáticos: um serviço é visto como
uma carga eletrostática (positiva), que gera um campo sobre a rede, e as
requisições de descoberta são vistas como cargas de teste (negativas), que são
atraídas para o serviço, em função do gradiente de campo gerado. Os anúncios de
serviços são disseminados na rede sem fio através de um mecanismo de difusão
por broadcast. Esses anúncios contém informações sobre a capacidade do
provedor em oferecer cada tipo de serviço e o gradiente de campo associado a
cada serviço.
Em oposição aos trabalhos mencionados, o protocolo P2PDP não
implementa o mecanismo de descoberta passiva. Como a sua especificação foi
definida em função das especificidades das grades móveis, o mecanismo de
anúncio mostrou-se proibitivo, visto que, nesses ambientes, a provisão do serviço
está associada ao compartilhamento de recursos dinâmicos entre os dispositivos
da grade. Esses recursos se caracterizam por apresentarem flutuações na sua
disponibilidade em função do tempo, sendo influenciados por fatores como a
qualidade do enlace sem fio e variações na topologia da rede. Considerando-se,

Trabalhos Relacionados à Descoberta de Serviços 85
por exemplo, a conexão entre dois nós, ela pode deixar de existir em uma fração
de segundo, quer seja em função de variações na qualidade do enlace sem fio,
quer seja pelo deslocamento de um ou mais nós que constituem o caminho entre
eles. Em uma rede sem fio, a manutenção da conectividade entre dois nós
quaisquer – A e B – só é garantida com a colaboração dos nós vizinhos. A conexão
entre os nós A e B pode sofrer interferências caso ocorram tentativas de
comunicação entre os nós na sua vizinhança nesse período. Nesse caso, segundo
[Yang & De Veciana 2005], o recurso de interesse não é o enlace entre os dois nós
e sim o canal sem fio da região geográfica na qual eles se encontram.
Devido as características anteriormente mencionadas, a manutenção de um
mecanismo periódico de anúncios contendo informações sobre os recursos
disponíveis na grade móvel e o armazenamento dessas informações nos
dispositivos, incorre no aumento do consumo de recursos como ciclos de
processamento e espaço de armazenamento. As alterações freqüentes na
disponibilidade dos recursos dinâmicos implica na redução dos intervalos entre a
transmissão de anúncios para garantir que as informações armazenadas sobre
esses recursos, nos dispositivos da grade móvel, mantenham-se atualizadas e
consistentes. Como foi verificado na análise de desempenho do protocolo Allia,
realizada em [Ratsimor et al. 2004], um efeito colateral do aumento da freqüência
de envio dos anúncios é o crescimento do tráfego de dados no canal sem fio,
aumentando a probabilidade de ocorrência de colisões e provocando uma redução
na taxa de entrega de pacotes. Como conseqüência do aumento do número de
transmissões, verifica-se a redução da carga residual da bateria dos dispositivos
sem fio, o que reduz o tempo de vida dos dispositivos na grade móvel. De um
modo geral, quando os recursos providos são altamente dinâmicos, o uso do
mecanismo de anúncios em redes ad hoc torna-se proibitivo [Frank & Karl 2004].
3.2.1.2.
Descoberta Ativa
Nessa abordagem, o cliente envia mensagens de descoberta para obter
informações sobre os serviços ou diretórios da rede. Ao receber uma requisição
originada localmente, o dispositivo a processa; se a descrição corresponder a um
serviço que ele disponibiliza, uma resposta é gerada e entregue ao cliente; caso

Trabalhos Relacionados à Descoberta de Serviços 86
contrário, a requisição é então encaminhada aos demais dispositivos da rede.
Requisições para um mesmo serviço, provenientes de clientes diferentes, são
tratadas e respondidas separadamente. Na arquitetura baseada no uso de diretórios
centralizados, inicialmente, os clientes usam multicast UDP ou broadcast UDP
para descobrir o diretório que gerencia as informações sobre os serviços. Feito
isso, as requisições passam a ser enviadas em unicast ao diretório que responde,
também em unicast, informando as características e a localização do serviço;
posteriormente, o cliente se conecta diretamente ao provedor para ter acesso ao
serviço. Na arquitetura baseada no uso de diretórios distribuídos, as mensagens de
descoberta são transmitidas por difusão para todos os dispositivos na rede, através
de broadcast ou multicast – Bluetooth SDP, GSD, Konark, ORION, FTA e a
abordagem cross-layer de Varshavsky et al. [2005]. Quando o encaminhamento
de pacotes em saltos múltiplos é tratado, o alcance da mensagem (número de
saltos pelos quais ela irá trafegar) é geralmente definido, assim como acontece
com os anúncios de serviço na descoberta ativa, por um parâmetro configurável,
denominado “diâmetro da requisição”. Alguns protocolos implementam
mecanismos diferenciados de encaminhamento de requisições. Nessas propostas,
as requisições são difundidas, de forma seletiva, na direção dos nós que têm a
maior probabilidade de oferecer o serviço, o que é feito com base em critérios prédefinidos.
No GSD, o critério utilizado diz respeito ao grupo ao qual o serviço
pertence, no Allia às políticas definidas pelo usuário e no FTA ao potencial do
dispositivo em prover o serviço. Cada um desses critérios é comentado a seguir.
No GSD, quando um dispositivo precisa utilizar um serviço, inicialmente é
realizada uma consulta às informações de serviços armazenadas localmente, que
correspondem às informações sobre os serviços disponibilizados pelos seus
vizinhos a no máximo N saltos de distância. Caso não exista referência ao serviço
em questão, o dispositivo gera uma mensagem de requisição e a encaminha,
adotando uma abordagem seletiva, orientada aos grupos de serviços presentes na
sua vizinhança. A Figura 9 ilustra a dinâmica do mecanismo de roteamento
inteligente de requisições de serviços para uma rede sem fio ad hoc de saltos
múltiplos simplificada, com o diâmetro da requisição (parâmetro HOP_COUNT)
igual a 4.

Trabalhos Relacionados à Descoberta de Serviços 87
Figura 9 – Encaminhamento de requisições baseado em grupos de serviços (adaptada
de [Strang 2005]).
A Figura 9 mostra uma seqüência de nós interconectados, onde os círculos
tracejados delimitam a vizinhança dos nós. As legendas S e G representam,
respectivamente, os serviços e os grupos aos quais eles pertencem. O dispositivo
N 1 corresponde ao nó que originou a requisição e o dispositivo N 6 corresponde ao
provedor do serviço requisitado (S 1 ). Quando a requisição {S 1 (G 1 )}, solicitando o
serviço S 1 que pertence ao grupo G 1 , é recebida pelos nós N 2 e N 3 , eles verificam,
nas suas bases de informações de serviços, as entradas associadas ao grupo G 1 na
sua vizinhança. Como o nó N 2 não possui nenhuma entrada associada ao grupo
G 1 , ele descarta a requisição. O nó N 3 encontra uma entrada para o grupo G 1
associada ao nó N 4 ; a requisição é, então, seletivamente, encaminhada a esse nó.
O procedimento descrito se repete em todos os outros nós, até que a requisição
alcance o nó N 6 , onde é descoberta uma entrada direta para o serviço requisitado
(S 1 ). Quando o GSD falha na identificação do conjunto de nós para efetuar o
encaminhamento seletivo, a requisição é, então, transmitida através de broadcast.
O desempenho do protocolo GSD decai especialmente quando as requisições não
são especificadas em termos dos grupos de serviço, utilizando outros atributos, o
que implica em um esquema de inundação da rede.
Com o intuito de prevenir a inundação da rede pela difusão das mensagens
de requisição, causada pelo uso de broadcast [Ni et al. 1999; Tseng et al. 2003], o

Trabalhos Relacionados à Descoberta de Serviços 88
Allia implementa um mecanismo de encaminhamento seletivo, através do uso de
multicast baseado em políticas. Essa abordagem restringe a transmissão a um
conjunto de vizinhos em particular – especificados nas políticas locais do
dispositivo –, como, por exemplo, aqueles mais ativos. Ao receber uma
requisição, o dispositivo decide se irá processá-la, ou não, com base na sua
política local. Caso nenhuma referência ao serviço seja encontrada, a requisição é
enviada para o agente de encaminhamento, que consulta a política local para
decidir se a encaminha, ou não, para os outros dispositivos na sua aliança.
Na abordagem FTA, as requisições para uma instância de um dado tipo de
serviço são encaminhadas seletivamente na direção do provedor que gerou o
maior gradiente de campo, de forma similar ao roteamento de mensagens anycast.
Para que as requisições possam ser encaminhadas de forma apropriada, os valores
dos campos eletrostáticos, calculados por cada dispositivo, para os diferentes tipos
de serviços, devem ser trocados periodicamente entre os nós vizinhos, o que é
feito através dos anúncios periódicos de serviços disseminados por broadcast.
Para amenizar os efeitos provocados pela inundação da rede com mensagens de
anúncio, o FTA propõe uma estratégia para aumentar a escalabilidade dessa
solução com o armazenamento das informações contidas nesses anúncios nos nós
intermediários, entretanto essa estratégia só se mostra eficaz quando aplicada a
múltiplas instâncias de um mesmo tipo de serviço, mostrando-se inepta quando na
rede são disponibilizados diferentes tipos de serviços distintos.
No protocolo ORION, os dispositivos não fazem a divulgação das
informações sobre os serviço os quais disponibilizam; as informações sobre os
serviços são obtidas através de requisições sob demanda. Nesse protocolo, cada nó
armazena as informações de serviços contidas nas respostas às requisições de
serviços que trafegam na rede por seu intermédio, o que caracteriza um
mecanismo de anúncio “implícito”.
Propostas adeptas da integração dos mecanismos de roteamento e
descoberta de serviços, recomendam a utilização de protocolos de roteamento para
redes sem fio ad hoc, como o protocolo reativo AODV (Ad hoc On-demand
Distance Vector) [Perkins et al. 2003], caso falhas sejam detectadas no caminho
utilizado para o encaminhamento da mensagem de resposta em direção ao nó que
originou a requisição, como ocorre no GSD e no ORION. No caso dos protocolos

Trabalhos Relacionados à Descoberta de Serviços 89
que adotam uma abordagem cross-layer, como em [Varshavsky et al. 2005], as
mensagens de requisição e anúncio de serviços são encapsuladas nas mensagens
de controle do protocolo de roteamento sobre o qual o mecanismo de descoberta
foi implementado.
De forma similar aos trabalhos mencionados anteriormente, o protocolo
P2PDP implementa o mecanismo de descoberta ativa e utiliza o conceito de
diâmetro de requisição. Como contribuição da abordagem proposta no protocolo
P2PDP, é introduzido o conceito de perfil de execução, que identifica os
requisitos necessários, em termos de recursos dinâmicos, para a execução das
tarefas pelos dispositivos da grade móvel. Essa informação é transmitida na
requisição de serviço, o que permite que ao receber uma requisição o nó possa
verificar a sua adequação ao perfil de execução antes de respondê-la. Esse
conceito é comum aos ambientes de grade fixa, no qual os dispositivos são
selecionados para executar tarefas em função de um conjunto de requerimentos
associados a disponibilidade de recursos nos mesmos.
3.2.2.
O Mecanismo de Seleção de Serviços
Embora o escopo do mecanismo de descoberta restrinja o número de respostas
recebidas pelo cliente, o resultado de uma requisição para um determinado serviço
deve conter não só informações de um, mas de vários provedores do mesmo
serviço. Neste caso, o ideal é que o melhor provedor seja selecionado, sem que
haja a necessidade de interferência do usuário. Como ilustrado na Figura 10, os
protocolos de descoberta de serviços podem oferecer opções de seleção manual,
com a intervenção direta do usuário da aplicação – como ocorre nos protocolos
Bluetooth SDP, DEAPspace, GSD, Allia, Konark e ORION –, ou automática,
através de um algoritmo implementado no lado cliente, selecionando a melhor
opção em função das características da aplicação, como ocorre no FTA e na
abordagem cross-layer de Varshavsky et al. [2005]. Quando a abordagem de
seleção automática é implementada, deve-se considerar as métricas que irão
definir qual é a melhor oferta. Na abordagem cross-layer de Varshavsky et al.
[2005], o critério de seleção utilizado é a menor distância, em número de saltos,
entre o dispositivo que originou a requisição e o provedor do serviço. Os autores

Trabalhos Relacionados à Descoberta de Serviços 90
mencionam a possibilidade de se utilizar métricas específicas associadas ao
serviço, às condições do provedor – como, por exemplo, a sua carga de
processamento, que está diretamente relacionada ao número de requisições sendo
atendidas – ou mesmo às condições da rede. Na abordagem FTA, quando há mais
de um provedor para o mesmo tipo de serviço, a seleção é feita de forma
automática pelo sistema de descoberta, que escolhe, em prol do cliente, o
provedor mais adequado, em função de duas métricas: a distância entre o cliente e
a instância do serviço, calculada tendo como base o número de saltos entre eles, e
a capacidade de serviço (Capacity of Service – CoS), que representa a carga do
serviço, em uma analogia a cargas em um campo eletrostático. Nessa abordagem,
cada tipo de serviço determina o CoS em função de características específicas do
serviço que devem ser padronizadas em todos os dispositivos da rede. Por
exemplo, o CoS de um serviço de provisão de acesso à Internet pode indicar a
capacidade do enlace das suas conexões, já o CoS de um serviço de impressão
pode indicar a sua velocidade. O CoS assume valores positivos em um intervalo
[CoS min , CoS max ] definido para cada tipo de serviço; esses intervalos devem ser
representados de modo uniforme por todos os dispositivos na rede.
Figura 10 – Critérios de seleção de serviços.
Como mencionado, na maioria dos protocolos apresentados, a seleção dos
serviços de interesse é feita manualmente pelo usuário ou pela aplicação que
utiliza o sistema. As exceções ficam por conta da abordagem cross-layer de
Varshavsky et al. [2005] e do FTA nos quais, assim como no protocolo P2PDP, a
seleção é implementada de forma automática. Um diferencial do protocolo P2PDP
em relação a esses trabalhos diz respeito a forma como o critério de seleção é
aplicado. Diferentemente do FTA, onde a seleção é feita no encaminhamento da
requisição de serviço, no P2PDP a seleção ocorre durante o encaminhamento das
respostas, permitindo que mais de uma resposta seja selecionada, o que não ocorre
no FTA, onde uma única instância do serviço é retornada. Esse comportamento do
protocolo P2PDP se deve ao fato da sua especificação ter sido determinada pelos
requisitos do mecanismo de seleção das grades computacionais, onde uma

Trabalhos Relacionados à Descoberta de Serviços 91
requisição deve receber como resposta, informações sobre múltiplas instâncias do
mesmo serviço. A vantagem de se implementar a seleção no encaminhamento das
respostas e não no das requisições se deve ao fato de não haver a necessidade de
se manter informações atualizadas, armazenadas em cada dispositivo, sobre a
disponibilidade de serviços nos outros nós da rede. A implementação do
mecanismo de seleção durante o encaminhamento das requisições introduz a
necessidade de se especificar um parâmetro de comparação – no caso do FTA, o
CoS – que estabeleça um critério de seleção entre os diferentes tipos de serviço de
cada provedor sobre os quais se tenha informações, de modo que as requisições
sejam encaminhadas seletivamente na direção dos melhores provedores.
Em relação a abordagem cross-layer de Varshavsky et al. [2005], na qual a
seleção é feita somente quando as mensagens de resposta chegam ao dispositivo
que originou a requisição, no P2PDP, como já foi mencionado, a seleção é feita no
encaminhamento das respostas, de uma forma cooperativa, pelos dispositivos no
diâmetro da requisição. A seleção no encaminhamento das mensagens de resposta
no P2PDP é implementada pelo mecanismo de supressão, o que permite que as
respostas menos aptas sejam removidas da rede antes de chegar ao seu destino, o
que evita o desperdício de recursos como ciclos de CPU e energia no
processamento e encaminhamento dessas mensagens pelos nós intermediários.
Além disso, no P2PDP é permitido configurar, na requisição de serviço, o número
de respostas esperado e o tempo máximo que o requisitante está disposto a esperar
por essas respostas, opção não disponível nos trabalhos apresentados. Esses
parâmetros são necessários em uma grade computacional, pois estão relacionados
diretamente aos mecanismos de distribuição e execução de tarefas, determinando,
respectivamente, o número de dispositivos necessários para a execução das tarefas
que compõem uma requisição de serviço e uma fração do retardo máximo
tolerado na iniciação do serviço, a qual diz respeito ao tempo de resposta do
mecanismo de descoberta.
3.2.3.
Mecanismos para oferecer suporte à Mobilidade
Em uma rede sem fio, os dispositivos se movimentam constantemente, alterando a
sua localização física, o que torna obsoletas as rotas através das quais eles eram

Trabalhos Relacionados à Descoberta de Serviços 92
alcançáveis. Uma abordagem de armazenamento de informação de serviço é dita
completamente distribuída, quando cada dispositivo mantém informações somente
a respeito dos serviços que ele próprio disponibiliza, sem ter que gerenciar
informações sobre os serviços disponibilizados pelos demais dispositivos. Nesse
cenário, o problema de se manter, mediante a presença da mobilidade, as
informações sobre os serviços atualizadas é contornado através da descoberta
ativa. Nesse caso, pode-se verificar uma atualização implícita das informações
sobre os serviços [Marin-Perianu et al. 2005]. São realizadas consultas aos
serviços disponíveis na rede, sob demanda, através do envio de mensagens de
requisição a endereços de multicast ou broadcast (ver Subseção 3.2.1).
O suporte à mobilidade implica que a informação sobre os serviços
disponíveis na rede, quer seja armazenada nos diretórios (centralizada) ou nos
dispositivos da rede (distribuída), deva ser atualizada em função das modificações
na topologia da rede, provocadas pela mobilidade dos dispositivos. Se, em um
dado grupo, um dispositivo armazena informações sobre os serviços dos demais
dispositivos, espera-se que ele mantenha informações corretas, na medida do
possível. Se o dispositivo altera a sua posição em relação ao grupo, ou se algum
membro do grupo se desloca, as informações de serviços devem ser atualizadas o
mais rapidamente possível. Somente dessa forma, pode-se esperar, com uma certa
probabilidade, que um protocolo de descoberta de serviços consiga descobrir um
dado serviço em tempo hábil. Caso as informações mantidas por um dispositivo
sobre os serviços da rede estejam obsoletas, há uma grande chance desse
dispositivo responder, a uma requisição de serviço, com informações
desatualizadas; ao receber a resposta a sua solicitação, o cliente tentará acessar o
serviço e, só então, irá detectar a sua indisponibilidade, pois o provedor do serviço
pode ter se deslocado ou se tornado inalcançável. Existem dois métodos principais
para solucionar esse problema (Figura 11): proativo e reativo. No método
proativo, os dispositivos mantêm uma visão atualizada das informações sobre os
serviços disponíveis na rede com a troca periódica de mensagens de anúncio
contendo dados mais recentes sobre o serviço. No método reativo, a informação é
atualizada em razão da ocorrência de eventos na rede, como, por exemplo, a
indisponibilidade de uma rota para um provedor ou a detecção de mudanças de
estado informadas pelo próprio serviço. Nesse método, a disponibilidade do

Trabalhos Relacionados à Descoberta de Serviços 93
serviço pode ser consultada pelos clientes, junto a provedores (ou diretórios), de
forma direta, sob demanda, ou através de notificações. Um terceiro método diz
respeito à manutenção das informações sobre os serviços atualizadas mediante À
mobilidade da rede de um modo implícito, em decorrência da adoção de um
mecanismo de descoberta reativo, baseado puramente no envio de requisições de
serviço sob demanda, como é o caso do Bluetooth SDP. Nesse protocolo, como a
descoberta é feita em função do modelo requisição-resposta, não há manutenção
das informações de serviços, o que caracteriza uma atualização “implícita”.
Figura 11 – Métodos de provisão de suporte à mobilidade.
Protocolos de descoberta que adotam a abordagem cross-layer podem
implementar os dois métodos, como é o caso de [Varshavsky et al. 2005], que
utiliza as informações de roteamento e aquelas contidas nas mensagens de
controle do protocolo de descoberta para inferir a respeito da validade das
informações mantidas sobre os serviços e, conseqüentemente, sobre a
disponibilidade desses serviços. Em protocolos de descoberta baseados na
manutenção da estrutura da rede sobreposta, como é o caso do ORION, a
atualização das informações sobre os serviços da rede é associada à manutenção
das informações de roteamento e, portanto, a indisponibilidade do caminho para
um provedor indica a indisponibilidade de um serviço, seguindo uma abordagem
de manutenção das informações sobre os serviços reativa. No ORION, o único
tipo de serviço provido é a transferência de arquivos, o que o caracteriza como um
protocolo de propósito específico.
Em alguns protocolos de descoberta de serviços, como é o caso do Konark e
da abordagem cross-layer de Varshavsky et al. [2005], o tráfego referente ao
mecanismo de descoberta – mensagens de anúncios, requisições e respostas de
serviços – é interceptado e processado, pelos nós intermediários, de modo que se
obtenham informações sobre serviços adicionais.
Uma prática comum, é a manutenção das informações sobre os serviços na
forma soft state: o período de validade da informação é especificado nas

Trabalhos Relacionados à Descoberta de Serviços 94
mensagens de anúncio, o que caracteriza o método proativo de provisão de
suporte à mobilidade. Antes que o período de validade associado ao serviço
expire, o seu provedor deve encaminhar um novo anúncio para revalidar as
informações sobre o serviço, o que se obtém através de um mecanismo de
anúncios periódicos. A periodicidade com que esses anúncios são divulgados
pode ser definida através de parâmetros configuráveis pelo usuário – como
acontece nos protocolos GSD, Allia e FTA –, através do monitoramento das
condições da rede – como no Allia e na abordagem cross-layer de
Varshavsky et al. [2005] – ou, ainda, uma combinação das duas abordagens,
levando sempre em consideração a mobilidade dos dispositivos e de sua
vizinhança. Alguns protocolos de descoberta de serviços que implementam o
método proativo usam a limitação do número de saltos da propagação dos
anúncios, para restringir o alcance da transmissão das informações sobre os
serviços da rede, como é o caso dos protocolos GSD, Allia e FTA. Essa
abordagem tem como intuito facilitar a manutenção das informações sobre os
serviços, limitando a sua divulgação aos dispositivos mais próximos
geograficamente, que constituem uma vizinhança física, aumentando, com isso, as
chances de se localizar um serviço dentro da vizinhança do dispositivo.
O P2PDP foi projetado para um cenário dinâmico, sendo intrínseco ao seu
funcionamento prover mecanismos que ofereçam suporte à mobilidade dos nós,
mantendo as informações sobre os serviços atualizadas, o que é obtido de forma
“implícita” pelo mecanismo de descoberta ativa, através de requisições de serviço
sob demanda, em função da necessidade dos usuários. Os demais trabalhos
apresentados, com exceção do Bluetooth SDP, implementam um mecanismo
explícito de provisão de suporte à mobilidade para minimizar o problema de se
manter as informações sobre os serviços atualizadas. Nesses protocolos, essas
informações são obtidas através das mensagens de anúncio e das respostas às
mensagens de requisição. No protocolo P2PDP cada dispositivo armazena
exclusivamente informações sobre os serviços que ele disponibiliza; para obter
informações sobre os serviços disponíveis na rede, são realizadas requisições sob
demanda, as quais obtém como resposta informações atualizadas sobre os
serviços. Dentre as suas vantagens, essa abordagem não introduz custos adicionais
em função do armazenamento das informações de serviço – presente nas

Trabalhos Relacionados à Descoberta de Serviços 95
abordagens que utilizam os métodos reativo e proativo – e do aumento da carga da
rede em decorrência do envio periódico de anúncios de serviços
[Engelstad et al. 2006], além do custo de comunicação ao se tentar contactar
provedores de serviço que não estão mais disponíveis, em função da consulta a
informações de serviços desatualizadas.
3.3.
Visão Geral dos Protocolos de Descoberta de Serviços
Como os protocolos para as redes fixas alcançaram a maturidade no seu
desenvolvimento, é possível observar uma tendência crescente no sentido de
desenvolver novas soluções com o intuito de oferecer suporte à descoberta de
serviços para as redes sem fio, especialmente para as redes sem fio ad hoc. Os
protocolos de descoberta de serviços desenvolvidos para as MANETs de saltos
múltiplos são iniciativas recentes da área acadêmica e não existe, até o momento,
uma especificação que possa ser adotada como padrão pela indústria. Nessas
redes, a mobilidade introduz questões desafiadoras, como a manutenção das
informações sobre os serviços mediante as freqüentes mudanças de topologia da
rede – o que implica no controle da periodicidade e do alcance das mensagens de
anúncio –, aspectos relacionados à escalabilidade, o gerenciamento dos recursos
dos dispositivos sem fio – especialmente a energia, recurso constantemente
solicitado nas transmissões geradas pelos protocolos de descoberta – e
mecanismos para controlar o tráfego de mensagens de requisição e resposta, que
são as responsáveis, respectivamente, pela inundação e implosão de mensagens no
enlace sem fio, aumentando a probabilidade da ocorrência de colisões.
A seleção automática de serviços apresenta-se como um aspecto importante
no desenvolvimento de um protocolo de descoberta de serviços para redes sem fio
ad hoc, como destacado na proposta do protocolo FTA e na abordagem crosslayer
de Varshavsky et al. [2005]. Devido à mobilidade dos dispositivos que
constituem esse tipo de rede, a seleção do provedor de serviço mais adequado –
dentre aqueles que disponibilizam o serviço – é fundamental para garantir que o
serviço possa ser, de fato, utilizado após a sua descoberta. Critérios como a
distância da rede e a capacidade do provedor são geralmente utilizados na
implementação da escolha dos provedores mais adequados. Em [Varshavsky
et al. 2005], é enfatizada a necessidade de um mecanismo de reavaliação do

Trabalhos Relacionados à Descoberta de Serviços 96
serviço selecionado, que garanta a qualidade do serviço de descoberta oferecido,
através do registro de rotinas de callback, para que o cliente seja notificado
quando um servidor mais adequado for detectado na sua vizinhança. Mecanismos
de seleção de serviços devem ser aprimorados no sentido de embutir algum nível
de provisão de QoS nos protocolos de descoberta de serviços para as redes sem fio
ad hoc.
As abordagens apresentadas até aqui, não atendem às necessidades
originadas pelas grades móveis organizadas através de redes sem fio ad hoc, que
necessitam de um mecanismo completamente descentralizado, onde cada
dispositivo deve se responsabilizar pelo gerenciamento de seus serviços de forma
autônoma. Isso se deve ao fato dos dispositivos sem fio e, conseqüentemente, os
serviços que eles disponibilizam se deslocarem freqüentemente, alterando a
topologia da rede, o que inviabiliza a manutenção das informações de serviço em
um dispositivo central. Na grande maioria dos protocolos apresentados neste
capítulo, os anúncios estão associados a recursos estáticos, ou seja, recursos que
não apresentam flutuações na sua disponibilidade, como acontece, por exemplo,
com impressoras multifuncionais, as quais estão disponíveis todo o tempo em que
permanecerem ativas. A sua disponibilidade não é fracionada, como ocorre com
os recursos dinâmicos, os quais estão associados aos serviços não-específicos que
demandam, por exemplo, um alto consumo de processamento e energia.
Em se tratando de grades móveis ad hoc, a descoberta de serviços deve ser
realizada, preferencialmente, sob demanda, através de consultas à vizinhança,
evitando que o meio sem fio seja inundado com mensagens de divulgação
periódica de informações de serviços, cujo tempo de validade deve ser reduzido,
devido à instabilidade da topologia, provocada pelas altas taxas de churn. Nesse
modelo, quando um dispositivo realiza uma requisição, os demais dispositivos o
auxiliam a “espalhar” o pedido e a receber a(s) resposta(s), atuando de forma
colaborativa. Além disso, de acordo com a revisão bibliográfica realizada, não há
nenhum protocolo de descoberta de serviços que realize explicitamente a seleção
simultânea de nós múltiplos como os provedores mais adequados de um serviço
específico. Tal característica, de forma similar às técnicas de meta-escalonamento
em grades fixas [Czajkowski et al. 2004], é particularmente importante em grades
móveis para oferecer um ambiente de execução para aplicações de processamento
intensivo.

Trabalhos Relacionados à Descoberta de Serviços 97
A discussão anterior apenas reforça a necessidade de um novo protocolo de
descoberta que contemple as peculiaridades das grades móveis ad hoc. Nesta tese,
é proposto o protocolo P2PDP (Peer-to-Peer Discovery Protocol) com o intuito
de suprir a carência de um mecanismo integrado de descoberta e seleção de
recursos para as grades móveis ad hoc [Gomes et al. 2007; Lima et al. 2007b]. Por
adotar uma abordagem reativa – baseada no envio de requisições de descoberta e
de respostas a essas requisições, sob demanda, utilizando difusão por broadcast –
o protocolo P2PDP trata os problemas de inundação [Ni et al. 1999;
Tseng et al. 2003] e de implosão [Duffield et al. 1999], respectivamente das
requisições e de suas respostas, comuns a esse tipo de abordagem. O protocolo
P2PDP é descrito em detalhes no Capítulo 4.
3.4.
Resumo Comparativo dos Protocolos de Descoberta de Serviços
para MANETs
Como foi mencionado na Seção 3.1, as soluções propostas para a descoberta de
serviços em redes sem fio têm se concentrado em três cenários distintos: (i) as
soluções projetadas para redes fixas adaptadas às redes sem fio, (ii) as soluções
projetadas para as redes sem fio ad hoc de salto único e (iii) as soluções projetadas
para as redes sem fio ad hoc de saltos múltiplos. Na Tabela 2, a classificação
apresentada na Seção 3.2 é utilizada como base de comparação entre as principais
iniciativas de prover mecanismos de descoberta de serviços para as redes sem fio.

Tabela 2 – Resumo comparativo dos protocolos de descoberta de serviços para redes sem fio.
Soluções para redes fixas adaptadas às redes sem fio
Soluções para redes sem
fio ad hoc de salto único
Soluções para redes sem fio ad hoc de saltos múltiplos
Salutation SLPv2 Jini UPnP SSDP
Bluetooth
SDP
DEAPspace GSD Allia
Konark
Gossip
ORION
[Varshavsky
et al. 2005]
FTA
P2PDP
Arquitetura de
Descoberta
Diretório
centralizado
hierárquico ou
plano
Diretório
centralizado
plano ou
distribuído
Diretório
centralizado
Diretório
distribuído
Diretório
distribuído
Diretório
distribuído
Diretório
distribuído
Diretório
distribuído
Diretório
distribuído
Diretório
distribuído
Diretório
distribuído
Diretório
distribuído
Diretório
distribuído
Escopo
Topologia da
rede (PANs a
WANs)
Topologia da
rede e papéis
de usuário
(escopos)
Topologia da
rede, papéis de
usuário e
contexto
Topologia da
rede (PANs a
WANs)
Topologia da
rede
Topologia da
rede
Topologia da
rede
Topologia da
rede
Topologia da
rede
Topologia da
rede
Topologia da
rede
Topologia da
rede
Topologia da
rede e contexto
Descrição de
Serviços
Pares atributovalor
baseados
em templates e
elementos prédefinidos
(unidades
funcionais)
Pares atributovalor
baseados
em templates
de atributos
Descrição de
pares atributovalor
utilizando
linguagem de
programação
Descrição em
XML baseada
em templates
UPnP
Pares atributovalor
baseados
Pares atributovalor
em templates e
elementos prédefinidos
Ontologia
Independente
Descrição em
XML, com
templates prédefinidos
Pares atributovalor
Independente
Descrição de
Não tratada
pares atributovalor
utilizando
(considera-se o
uso de
linguagem de
ontologias)
programação
Métodos de
Busca
(matching)
Baseado na
comparação de
vários atributos
Comparação de
vários atributos
utilizando
predicados
lógicos
Dependente da
linguagem de
programação
utilizada
Baseado na
comparação de
um único
atributo
Baseado na
comparação de
vários atributos
do tipo UUID
Baseado na
comparação de
vários atributos
Semântico
Compatível com
o mecanismo
de descrição
adotado
Semântico e
baseado na
comparação de
diferentes
atributos
Baseado na
comparação de
diferentes
atributos
Módulo de
comparação
adaptável
Não Tratado
Dependente da
linguagem de
programação
utilizada
Armazenagem
da Informação
de Serviço
Centralizada,
mantida como
hard state
Centralizada ou
distribuída nãocooperativa,
mantida como
soft state
Centralizada,
mantida como
soft state
(leasing)
Distribuída não
cooperativa,
mantida como
soft state
Distribuída
cooperativa,
mantida como
hard state
Distribuída não
cooperativa,
mantida como
soft state
Distribuída
cooperativa,
mantida como
soft state
Distribuída
cooperativa,
mantida como
soft state
Distribuída não
cooperativa,
mantida como
soft state
Distribuída
cooperativa,
mantida como
hard state, (uso
da política LRU
Distribuída
cooperativa:
mantida como
soft state
Distribuída
cooperativa:
mantida como
soft state
Distribuída
cooperativa,
mantida como
hard state
Anúncio de
Serviços
Broadcast
Multicast
Multicast e
notificação por
inscrição
Multicast Não Tratado Broadcast
Broadcast
limitado ao
diâmetro do
anúncio
Broadcast
limitado à
aliança
Anúncios
incrementais,
através de
multicast
Não Tratado
A difusão
depende do
protocolo de
roteamento
usado
Broadcast
limitado pelo
número de
saltos
Não Tratado

Tabela 2 – Resumo comparativo dos protocolos de descoberta de serviços para redes sem fio (continuação).
Soluções para redes fixas adaptadas às redes sem fio
Soluções para redes sem
fio ad hoc de salto único
Soluções para redes sem fio ad hoc de saltos múltiplos
Salutation SLPv2 Jini UPnP SSDP
Bluetooth
SDP
DEAPspace GSD Allia
Konark
Gossip
ORION
[Varshavsky
et al. 2005]
FTA
P2PDP
Requisição de
Serviços
Seleção de
Serviços
Invocação de
Serviços
Provisão de
Suporte à
Mobilidade
Segurança
Requisições
são enviadas
ao Salutation
Manager (SLM)
via unicast ou
através de
broadcast
quando se usa
diretório
distribuído
User Agents
(UAs) enviam
requisições em
unicast para o
Directory Agent
(DA) ou através
de multicast
para os Service
Agents (SAs)
Serviços,
clientes e LUSs
(LookUp
Services) usam
multicast ou
fazem
requisições aos
LUSs via
unicast
Requisições via
unicast ou
multicast
Requisições
através de
broadcast
Não Tratada
Encaminhada,
em modo
seletivo, com
base no(s)
grupo(s) do
serviço
Encaminhada
para as
plataformas de
agentes
vizinhas,
utilizando
broadcast ou
multicast
Encaminhada
para o
endereço de
grupo do
Konark
(multicast)
Encaminhada
por multicast ou
broadcast
Disseminadas
através de
broadcast (ex.
DSR e AODV)
ou unicast (ex.
CBRP)
Encaminhada à
instância do
serviço mais
próximo ou com
maior gradiente
do campo
Encaminhada
por broadcast
local, limitado
pelo número de
saltos
Manual Manual Manual Manual Manual Manual Manual Manual Manual Manual Automática Automática Automática
Localização do
serviço,
mecanismo de
comunicação
Reativa
Localização do
serviço (URLs)
Proativa e
Reativa
Uso opcional de
Autenticação do assinaturas
usuário no RPC digitais
(autenticação)
Localização do
serviço
mecanismo de
comunicação e
operações
Proativa e
Reativa
Nível de
segurança
provido pela
linguagem de
programação
(Java)
Localização do
serviço,
mecanismo de
comunicação e
operações
Proativa e
Reativa
Extensões
oferecem um
framework para
controle de
acesso e
autenticação de
dispositivos
Localização do
serviço
Não tratada Não Tratada Não Tratada
Implícita Proativa Proativa Proativa
Estabelecida na
fase de
negociação da
conexão; a
comunicação
pode ser
criptografada
no nível de
enlace
Não Tratada
Não Tratada
Uso de políticas
locais para
definir
restrições de
segurança,
como direito de
acesso e
verificação de
credenciais
Localização do
serviço,
mecanismo de
comunicação e
operações
específicas
Proativa e
Reativa
Localização do
serviço e
mecanismo de
comunicação
Reativa
Não Tratada
Proativa e
Reativa
Não Tratada
Proativa
Localização do
Serviço
Implícita
Não Tratada Não Tratada Não Tratada Não Tratada Não Tratada

4
O Protocolo P2PDP
4.1.
Introdução
A pesquisa na área de descoberta de serviços em redes sem fio ad hoc de saltos
múltiplos é relativamente nova e mais desafiadora – em relação àquela para redes
fixas e redes sem fio infra-estruturadas –, em particular, devido ao maior
dinamismo da topologia de rede determinado pela mobilidade de todos os
dispositivos sem fio, o que resulta na instabilidade dos enlaces e das rotas. Nas
MANETs de saltos múltiplos, cada dispositivo atua como um roteador e, para
tanto, precisa manter informações de roteamento localmente. A instabilidade
desses ambientes, provocada pela transitoriedade da topologia da rede e pela
escassez de recursos – como energia e memória –, torna desafiador o
armazenamento de informações de roteamento e, principalmente, a garantia de sua
consistência. Algumas propostas integram as funcionalidades de descoberta de
serviços e de roteamento em um único protocolo [Koodli and Perkins 2002;
Harbird et al. 2005; Varshavsky et al. 2005]. Por outro lado, existe um número
considerável de propostas que oferecem soluções para a descoberta de serviços no
nível de aplicação [Ratsimor et al. 2002; Helal et al. 2003; Lenders et al. 2005;
Chakraborty et al. 2006]. Essas propostas são independentes da utilização de um
protocolo de roteamento na MANET, podendo ser utilizadas mesmo na sua
ausência, pois não dependem da disponibilidade e precisão de informações sobre a
topologia da rede, como, por exemplo, informações a respeito de dispositivos
vizinhos localizados a um ou dois saltos de distância. Nesses protocolos, a
responsabilidade de transmitir as requisições de descoberta é distribuída entre os
nós da rede, sendo geralmente realizada no nível de aplicação por multicast ou
broadcast. Entretanto, quando o protocolo de descoberta de serviços adota um
mecanismo de difusão, ele incorre no problema da inundação da rede
[Ni et al. 1999; Tseng et al. 2003]. Esse problema diz respeito à ocorrência de

O Protocolo P2PDP 101
colisões, redundâncias e contenção de acesso ao meio à medida que a quantidade
de nós aumenta. Essa situação é agravada quando o esquema de difusão adotado
se baseia em inundação cega (blind flooding), ou seja, na primeira vez em que um
nó recebe uma mensagem ele a retransmite aos seus vizinhos.
As aplicações de computação distribuída em grades, de uma forma geral,
caracterizam-se pelo particionamento de um serviço em várias tarefas menores de
forma que elas possam ser executadas em paralelo, como forma de obter
resultados intermediários, promovendo o compartilhamento dos recursos da grade
através da seleção dos dispositivos mais aptos a colaborar no instante em que o
serviço foi solicitado. Essa abordagem exige um protocolo que ofereça suporte à
descoberta simultânea de múltiplas instâncias de um mesmo serviço,
possibilitando a manutenção de redundância do mesmo. Essa situação é agravada
em uma grade móvel organizada através de uma rede sem fio ad hoc, dado que,
dentre as suas peculiaridades, em uma MANET, os elementos que a constituem
devem atuar de maneira altamente cooperativa: as tarefas da rede – roteamento,
descoberta de serviços, entre outras – são distribuídas entre os dispositivos móveis
e qualquer operação é o resultado da colaboração de um grupo desses dispositivos
[Hubaux et al. 2001]. Quando o protocolo de descoberta de serviços adota um
mecanismo de difusão, ele incorre no problema da implosão de mensagens de
resposta [Duffield et al. 1999]. Esse problema é decorrente do volume,
potencialmente grande de respostas gerado pelos dispositivos provedores do
serviço requisitado, em especial, em redes de grande escala.
Neste capítulo, é apresentado um novo protocolo de descoberta e seleção de
recursos para grades móveis organizadas através de redes sem fio ad hoc de saltos
múltiplos, denominado P2PDP (Peer-to-Peer Discovery Protocol). Esse protocolo
foi desenvolvido no contexto do middleware MoGrid [Lima et al. 2005], descrito
no Capítulo 2. Com o uso do protocolo P2PDP, a responsabilidade de provisão de
um serviço é distribuída entre os nós com mais recursos na MANET através de
um mecanismo automático de seleção que considera o número de instâncias
desejadas do serviço em questão, parâmetro informado na requisição. O protocolo
adota uma abordagem peer-to-peer, totalmente descentralizada, independente de
protocolos de roteamento, ou mesmo de um nível de endereçamento explícito na
MANET, para garantir o seu funcionamento. A seleção dos nós que irão

O Protocolo P2PDP 102
efetivamente colaborar na provisão de serviços é baseada em um mecanismo
distribuído que combina dois algoritmos: o algoritmo de supressão de mensagens
de resposta por vizinhança (Suppression by Vicinity – SbV) e o algoritmo que
calcula o retardo no envio de mensagens de resposta (Delayed Replies – DR).
Esses algoritmos estão entre as principais contribuições desta tese e têm como
finalidade tratar os problemas de implosão e colisão de mensagens de resposta,
respectivamente, os quais são intrínsecos às abordagens que implementam a
descoberta de recursos e serviços através de broadcast. O funcionamento dos
algoritmos SbV e DR será descrito, respectivamente, nas Seções 4.6 e 4.7.
As requisições de serviço e as respostas do protocolo P2PDP são
transmitidas por broadcast através de mecanismos distintos. As requisições de
serviço são transmitidas na MANET através de inundação seletiva, utilizando um
parâmetro configurável que determina o seu diâmetro, ou seja, o número máximo
de saltos que a requisição deve seguir, e uma espera aleatória inserida no
encaminhamento da requisição para evitar a contenção de acesso ao meio em
função de transmissões concomitantes. Já as respostas são encaminhadas ao
dispositivo requisitante por broadcast salto-a-salto no nível de aplicação,
denominado nesta tese de “broadcast direcionado”. Esses mecanismos serão
apresentados em detalhes na próxima seção.
Como os protocolos de descoberta baseados em comunicação por difusão
que se têm registro na literatura sempre realizam a transmissão das requisições por
broadcast e das respostas a essas requisições por unicast, cabe aqui uma breve
discussão sobre a razão de se utilizar no protocolo de descoberta P2PDP
broadcast salto-a-salto no nível de aplicação e não unicast na transmissão das
mensagens de resposta. No modo de transmissão unicast, para que um nó possa
interceptar as respostas de seus vizinhos, a sua interface de rede deve ser
configurada para operar em modo promíscuo. Além das questões de segurança
envolvidas, essa alternativa introduz o inconveniente de que, nesse modo de
operação, o nó deve processar a porção de dados (payload) de todos os pacotes
que trafegam no enlace sem fio e não somente daqueles gerados pelo protocolo
P2PDP. Isso resulta em um desperdício de recursos, como CPU, memória e
energia, que são fundamentais para a execução de serviços computacionais. Em
contrapartida, utilizando-se a transmissão em broadcast salto-a-salto no nível de

O Protocolo P2PDP 103
aplicação, os pacotes continuam sendo processados no nível MAC como acontece
em qualquer tipo de transmissão, inclusive unicast. Entretanto, no nível de
aplicação, somente os pacotes P2PDP são processados, já que, nessa abordagem,
não existe a necessidade da interface de rede atuar no modo promíscuo.
4.2.
Suposições a Respeito do Sistema
Considerou-se um certo conjunto de suposições na especificação do protocolo
P2PDP, que exercem influência na implementação proposta, descrita em detalhes
no Capítulo 5. Antes que o protocolo P2PDP seja apresentado em detalhes, faz-se
necessário descrever essas suposições, as quais são introduzidas a seguir:
• Os dispositivos devem ser capazes de transmitir pacotes de dados para
todos os seus vizinhos imediatos, por broadcast local;
• Os enlaces sem fio são bidirecionais, possibilitando o envio e a recepção
de dados entre dois dispositivos quaisquer na rede, ou seja, se o nó N 1 é
capaz de realizar transmissões para N 2 , então N 2 também é capaz de
transmitir para N 1 ;
• Cada dispositivo tem a capacidade de executar uma transmissão sem fio e
escalonar tal transmissão para um período de tempo específico, assim
como cancelar essa transmissão caso ela ainda não tenha sido efetuada;
• Na implementação dos mecanismos de temporização – presentes no
retardo do envio de mensagens de resposta, no agendamento de reenvio de
respostas em caso de reconhecimento negativo, na sumarização de
respostas provenientes dos colaboradores pelo coordenador e na
manutenção dos registros de requisições pendentes (vide Seção 4.5) –
considera-se que a diferença de velocidade entre os relógios dos
dispositivos na grade móvel é desprezível.
Apesar de considerar-se que os relógios dos dispositivos na grade móvel
estão relativamente sincronizados, é importante ressaltar, a necessidade de se
avaliar, futuramente, o impacto da diferença de velocidade dos relógios desses
dispositivos nos mecanismos de temporização implementados. O assincronismo
dos relógios pode influenciar negativamente o mecanismo de supressão de

O Protocolo P2PDP 104
respostas e, conseqüentemente, afetar a qualidade das respostas selecionadas. Isso
se explica pelo fato de que, se a velocidade dos relógios é diferente entre os
dispositivos, um colaborador mais apto pode esperar mais tempo absoluto para
enviar a sua resposta em relação a um outro colaborador menos apto, cujo relógio
apresenta uma velocidade mais alta.
4.3.
Visão Geral do Protocolo P2PDP
Nesta seção, é apresentada uma visão geral do protocolo P2PDP que reflete a
delimitação do seu escopo de atuação, enumerando as soluções propostas às
questões que nortearam a sua especificação, discutidos na introdução deste
capítulo (Seção 4.1).
Os mecanismos implementados no protocolo P2PDP atendem às
necessidades de uma grade móvel ad hoc, oferecendo soluções para (i) reduzir os
problemas de inundação da rede, devido à difusão de requisições de serviços,
limitando o seu alcance através do conceito de diâmetro da requisição; (ii) reduzir
o impacto do problema da implosão de respostas a essas requisições, através da
utilização do algoritmo SbV, que faz a supressão das respostas excedentes; (iii)
minimizar a ocorrência de colisões provocadas pelo aumento do tráfego de dados
no enlace sem fio, em virtude da transmissão de mensagens de controle –
problema minimizado pelo uso do mecanismo de retardo programado no envio
das respostas, oferecido pelo algoritmo DR; (iv) efetuar o resource matching com
a seleção dos melhores colaboradores para executar as tarefas da grade móvel
através da implementação do mecanismo de seleção das melhores respostas, que é
viabilizado pelo uso conjunto do conceito de adequação do dispositivo em
colaborar na realização de tarefas em função dos recursos necessários para a sua
execução e do agendamento do envio das respostas, utilizando o retardo
programado – fator que proporciona uma ordenação entre as respostas, com
aquelas mais adequadas sendo as primeiras a serem entregues ao iniciador; (v)
prover um mecanismo limitado de redundância de colaboradores, configurável
através do parâmetro que determina o número de respostas esperado pelo iniciador
e, por fim, (vi) garantir que o funcionamento do dispositivo não será afetado pela
sua colaboração na grade móvel, através da definição de um parâmetro

O Protocolo P2PDP 105
configurável, que indica a disposição do dispositivo em participar da execução de
tarefas e do conceito de adequação, que leva em consideração as condições do
dispositivo, em termos de disponibilidade de recursos, antes de responder a uma
requisição, gerando retardos de envio maiores quanto maior for o
comprometimento dos seus recursos com a execução de tarefas da grade móvel.
4.4.
Classificação do Protocolo P2PDP
Nesta seção, é apresentada uma classificação do protocolo P2PDP em função dos
critérios apresentados no Capítulo 3 para analisar os protocolos de descoberta de
serviços. A especificação do protocolo P2PDP é resumida nos próximos
parágrafos, sendo aprofundada nas seções subseqüentes.
Arquitetura de Descoberta de Serviços. O P2PDP foi projetado para
oferecer suporte a uma arquitetura de descoberta baseada no uso de diretórios
distribuídos, com os dispositivos se comunicando de forma peer-to-peer,
abordagem defendida em um estudo detalhado apresentado em
[Engelstad et al. 2006]. Nesse estudo os autores mostram que o uso de diretórios
centralizados não apresenta um bom desempenho quando empregadas com um
mecanismo de descoberta reativo. A razão principal é que o aumento na
disponibilidade de serviços – definida em função da descoberta e, posteriormente,
do acesso ao serviço para sua utilização – é insignificante se comparado ao custo
adicional provocado pelo aumento no número de mensagens referentes ao anúncio
e registro das informações de serviços.
Escopo da Descoberta de Serviços. O escopo da descoberta no P2PDP é
definido em função da topologia da rede; o alcance do mecanismo de descoberta é
determinado em função do diâmetro da requisição. No P2PDP, a requisição de
serviço pode alcançar dispositivos a vários saltos de distância de onde ela foi
originada, através da difusão por broadcast limitado.
Descrição de Serviços. Os serviços no protocolo P2PDP são descritos
através de implementações de uma interface comum denominada
ServiceDescription, em uma abordagem similar à utilizada por Jini [Sun 1999a].
Os atributos da interface ServiceDescription compreendem um identificador único

O Protocolo P2PDP 106
universal para o serviço, um identificador mnemônico, uma breve descrição, um
conjunto de palavras-chave e a sua localização.
Consulta às Informações de Serviços. O algoritmo de matching efetua
comparações entre a descrição do serviço requisitado e as informações sobre os
serviços oferecidos pelo dispositivo, considerando-se todos os atributos definidos
na interface ServiceDescription. Ao receber uma requisição, o dispositivo verifica
(i) se está disponível para colaborar (willingness) e (ii) se possui o serviço
solicitado (AdmissionController) e está apto a colaborar em função dos seus
recursos (suitability), ou seja, do perfil de execução definido na requisição. O
módulo de busca é implementado através do controle de admissão, que faz a
comparação entre a descrição da requisição remota e a descrição dos serviços
disponibilizados localmente. Ao ser detectado um serviço que atenda às
características exigidas na requisição (ii), o colaborador envia a sua descrição
completa como resposta ao nó que originou a requisição, além disso, são enviadas
informações a respeito dos recursos especificados no perfil de execução.
Armazenamento das Informações de Serviços. O armazenamento das
informações dos serviços é feito de forma distribuída cooperativa. Cada
dispositivo é responsável por armazenar apenas as informações a respeito dos
serviços que disponibiliza. Essas informações são mantidas como hard state, o
que significa que, para que um serviço se torne indisponível, é necessário que o
seu registro seja removido. A API de descoberta MoGrid oferece operações para
registro (register()) e remoção (deregister()) das informações sobre os
serviços (Subseção 2.3.1.1).
Anúncio de Serviços. O protocolo P2PDP foi projetado no contexto das
grades móveis [Lima et al. 2005], onde os serviços são caracterizados como uma
composição de recursos computacionais altamente dinâmicos, os quais
apresentam flutuações na sua disponibilidade, pois são influenciados por fatores
como a qualidade do enlace sem fio e variações na topologia da rede. Devido a
essa peculiaridade, as informações sobre os serviços tornam-se inválidas em um
período de tempo muito reduzido, o que exige que a periodicidade de envio dos
anúncios de serviços seja aumentada e que se utilize um mecanismo otimizado de
armazenamento dessas informações. Nas condições apresentadas, essa solução se
torna inviável, especialmente em redes sem fio ad hoc de maior escala, já que

O Protocolo P2PDP 107
aumenta consideravelmente o consumo de largura de banda e de recursos dos
dispositivos – como energia, ciclos de processamento, espaço de armazenamento
e memória – com o processamento e armazenamento dessas informações,
podendo causar contenção de acesso ao meio [Frank & Karl 2004]. Na avaliação
de desempenho do protocolo Allia, mais especificamente na análise do
mecanismo de anúncios de serviço, foi constatado que o aumento na periodicidade
de envio dos anúncios provoca um aumento considerável no volume de dados que
trafegam na MANET, ocasionando uma redução na taxa de entrega de pacotes de
dados [Ratsimor et al. 2004]. Por essa razão, o P2PDP, em sua implementação
atual, não apresenta suporte ao mecanismo de anúncio, o qual, entretanto, pode ser
facilmente acoplado com a adição de mensagens de anúncio (operação
advertise(), Subseção 2.3.1.1) e esquemas de gerenciamento do
armazenamento desses anúncios nos dispositivos que constituem a grade móvel.
Requisição de Serviços. O protocolo P2PDP tem como base o mecanismo
de descoberta ativa, o qual é feito através de requisições de serviços sob demanda.
Para oferecer suporte às grades móveis, como diferencial em relação às
abordagens apresentadas no Capítulo 3, no P2PDP uma mensagem de requisição
deve considerar, além do serviço solicitado, o perfil de execução necessário ao
dispositivo que irá atendê-la. Em uma aplicação de compartilhamento de arquivos,
o objeto da requisição é o arquivo, que pode ser um áudio, um vídeo, uma imagem
ou mesmo um documento de texto. Para esse tipo de aplicação, é desejável que o
dispositivo atendendo a requisição apresente uma conectividade estável e um bom
nível de energia, o que indica que provavelmente ele permanecerá alcançável e
ativo durante o tempo que durar a transferência do arquivo solicitado. Os nós
colaboradores respondem a uma requisição, encaminhando, através de broadcast
direcionado, a descrição do serviço e o perfil de execução do dispositivo,
seguindo o caminho inverso ao percorrido pela requisição correspondente. Os nós
intermediários verificam se eles estão no caminho de retorno da mensagem; em
caso afirmativo, eles consultam uma estrutura de dados local (pendingList), que
faz a associação entre uma requisição e o caminho para alcançar a sua origem,
determinando qual é o próximo salto.
Seleção de Serviços. Em uma grade móvel ad hoc, a seleção dos
dispositivos que irão colaborar na execução de um conjunto de tarefas deve estar

O Protocolo P2PDP 108
embutida no mecanismo de descoberta, o que não ocorre nas propostas
encontradas na literatura [Litke et al. 2004; McKnight et al. 2003], que tratam
desses aspectos separadamente. Como demonstram os estudos realizados em
[Tyan & Mahmoud 2005; Varshavsky et al. 2005], em uma MANET, a seleção de
serviços influencia o desempenho da rede, afetando a sua capacidade, o que
implica na necessidade de se implementar esse mecanismo de forma integrada ao
mecanismo de descoberta. A seleção de serviços torna-se necessária quando uma
requisição recebe um número de respostas maior do que o solicitado. Nesse
procedimento, no protocolo P2PDP, são considerados dois critérios para
“ordenar” as respostas: a distância, em número de saltos, do colaborador até o
iniciador, e o perfil de execução do colaborador. O protocolo de descoberta
descrito em [Varshavsky et al. 2005] também utiliza como métrica, para realizar a
seleção das respostas, a distância em número de saltos entre o provedor do serviço
e o cliente, entretanto a seleção é efetuada pelo dispositivo que originou a
requisição de descoberta ao receber as respostas à sua requisição. Já no protocolo
P2PDP, a seleção é feita de forma distribuída no encaminhamento das mensagens
de resposta, possibilitando que respostas excedentes sejam descartadas pelos nós
intermediários. Na abordagem FTA [Lenders et al. 2005], o mecanismo de seleção
é aplicado no encaminhamento da requisição, que é direcionada ao provedor mais
apto, tendo como resultado uma única resposta. Já no protocolo P2PDP, o número
de respostas selecionadas é configurável, sendo especificado no perfil da
requisição, o que atende a necessidade das grades móveis de descobrir múltiplas
instâncias de um mesmo serviço. Para oferecer suporte ao encaminhamento
direcionado das requisições de serviço, o FTA propaga as informações sobre a
capacidade de cada provedor em oferecer os serviços da rede através de
inundações periódicas.
Invocação de Serviços. No protocolo P2PDP, em resposta a uma requisição
de descoberta o cliente obtém apenas a localização do serviço. Para invocar o
serviço, o cliente deve se conectar diretamente ao provedor que o oferece através
do seu endereço de rede. As aplicações da grade são responsáveis por definir o
mecanismo de comunicação entre clientes e provedores e o conjunto de operações
disponíveis no serviço. Utilizando-se o protocolo P2PDP em conjunto com a
arquitetura MoGrid, é possível beneficiar-se do mecanismo de invocação de

O Protocolo P2PDP 109
serviços especificado na camada de transparência (Subseção 2.3.2); mais
precisamente, na subcamada de adaptação (Subseção 2.3.2.3). Na arquitetura
MoGrid a invocação do serviço é feita considerando-se a sua localização e os
mecanismos de comunicação definidos na camada de transparência.
Provisão de Suporte à Mobilidade. O P2PDP foi projetado para um cenário
dinâmico, sendo intrínseco ao seu funcionamento prover mecanismos que
mantenham as informações sobre os serviços da grade móvel atualizadas, mesmo
frente à mobilidade dos nós, o que é obtido, de forma implícita, pelo mecanismo
de descoberta ativa, através de requisições de serviço sob demanda. Além disso,
alguns parâmetros são configuráveis em função da mobilidade do nó e da
percepção de mobilidade da sua vizinhança, como o diâmetro da requisição, o
número de respostas esperado e o tempo de espera por respostas, todos campos da
mensagem de requisição. Abordagens similares foram descritas na Subseção
3.2.3, onde o encaminhamento das mensagens de resposta é realizado através da
integração dos mecanismos de roteamento e de descoberta de serviços [Klemm et
al. 2003; Ratsimor et al. 2004; Lenders et al. 2005; Varshavsky et al. 2005;
Chakraborty et al. 2006]. Vários estudos indicam que essa integração, em
MANETs, aumenta a eficiência do sistema, incentivando a adoção de abordagens
cross-layer [Raman et al. 2001; Shakkottai et al. 2003; Conti et al. 2004]. Esses
estudos sugerem, para as redes sem fio ad hoc, a integração das camadas de
enlace, roteamento e descoberta de serviços, unificando a pilha de rede em
oposição ao modelo tradicional em camadas. O protocolo P2PDP funciona
independentemente da utilização de mecanismos de roteamento, promovendo a
integração da camada de roteamento à camada de descoberta no nível de
aplicação, em uma abordagem que pode ser denominada cross-layer. Isso se deve
ao fato de que, através do mecanismo de descoberta, as mensagens são
encaminhadas utilizando uma estratégia de roteamento baseada em serviços e não
no endereço dos nós. Além disso, especificamente no roteamento das mensagens
de resposta, é empregado um mecanismo de encaminhamento seletivo,
implementado através do algoritmo SbV (Seção 4.6).
Mecanismos de Segurança. No projeto do protocolo P2PDP, assim como
na maioria das propostas apresentadas no Capítulo 3, não foi definido nenhum
mecanismo específico para tratar questões de segurança, as quais, segundo [Mian

O Protocolo P2PDP 110
et al. 2006], representam, por si só, uma área de pesquisa relevante, que precisa
ser investigada mais atentamente.
4.5.
Funcionamento do Protocolo P2PDP
O protocolo P2PDP formaliza o relacionamento das entidades envolvidas no
processo de descoberta – iniciador, coordenador e colaborador – definindo três
mensagens de controle: InitiatorRequest (IReq), CollaboratorReply (CRep)
e CollaboratorReplyList (CRepList). A Figura 12 ilustra o funcionamento
básico do protocolo em MANETs, considerando-se um cenário ideal, sem a
ocorrência de falhas. Na figura, assume-se que todos os dispositivos
colaboradores na rede respondem à requisição do iniciador, o dispositivo i. Em
uma MANET, as entidades de descoberta são implementadas em cada dispositivo,
como ilustra a Figura 5(a) na Subseção 2.3.1.2. Os dispositivos são responsáveis
por coordenar as suas próprias requisições, pois, diferentemente das redes sem fio
infra-estruturadas, na MANET não existe um coordenador centralizado. As
mensagens e o funcionamento geral do protocolo são descritos ao longo desta
seção. As Seções 4.6 e 4.7 oferecem mais detalhes sobre os algoritmos que
regulam o funcionamento do protocolo.
Figura 12 – Funcionamento básico do protocolo P2PDP em uma MANET.
Mensagens InitiatorRequest (IReq) são enviadas do iniciador para o seu
coordenador e encaminhadas posteriormente, por esse, para os colaboradores por

O Protocolo P2PDP 111
difusão (passo 1 da Figura 12). Como ilustrado na Figura 13, uma mensagem
IReq é composta: (i) por um identificador único universal da requisição, usado
para fazer o mapeamento entre as requisições e suas respostas (reqID); (ii) pelo
retardo máximo de resposta que um iniciador admite (maxReplyDelay); (iii) pelo
número de colaboradores que o iniciador necessita envolver (numMaxReplies);
(iv) pela informação de contexto na qual a aplicação está interessada (ctxtInfo);
(v) pelo diâmetro atual (numHops) e diâmetro máximo (maxHops) – em número de
saltos – associados à propagação da requisição e (vi) pela identificação do
dispositivo que gerou a requisição (hopID) que pode ser, por exemplo, em redes
802.11, o endereço MAC do dispositivo. É importante destacar que o campo
reqID de uma requisição corresponde a um valor de 16 bytes gerado a partir da
combinação da identificação do nó que originou a requisição (hopID), do
identificador mnemônico do serviço solicitado e do tempo corrente do sistema
(timestamp), resultando em um identificador único universal. A Figura 14 traz a
representação da mensagem IReq, utilizando a notação ASN.1.
Figura 13 – Mensagem InitiatorRequest (IReq).
Existe um aspecto do encaminhamento das mensagens de requisição que
merece ser comentado. Ao receber uma requisição, os dispositivos que se
encontram no mesmo raio de transmissão a encaminham para a rede em
broadcast, considerando o diâmetro da requisição. O diâmetro da requisição
(numHops) indica o número máximo de saltos que uma requisição de serviço pode
trafegar na rede. Esse parâmetro limita o alcance da requisição, oferecendo um
mecanismo de difusão controlado, evitando que a mensagem se propague
indefinidamente na rede. Nessa situação, os dispositivos podem iniciar a
transmissão da requisição em instantes de tempo muito próximos, ou mesmo
coincidentes, o que pode ocasionar a contenção de acesso ao canal de
comunicação sem fio. Para tratar esse problema, na implementação do mecanismo
de encaminhamento de requisições foi adicionado um retardo aleatório,
denominado requestDelay. Desse modo, dois parâmetros são utilizados para
controlar a inundação de uma mensagem IReq na rede: o diâmetro da requisição –

O Protocolo P2PDP 112
parâmetro maxHops, vide Figura 13 – e o retardo aleatório, introduzido pelo
parâmetro requestDelay.
Figura 14 – Representação ASN.1 da mensagem InitiatorRequest (IReq).
Ao receber uma mensagem IReq, o colaborador a registra como uma
requisição pendente em uma estrutura de dados local, denominada pendingList,
que é representada na Figura 15. Além de armazenar os campos reqID,
numMaxReplies e hopID, que são extraídos da mensagem IReq, cada entrada, em
uma pendingList, possui um campo numReplies (inicialmente configurado com
o valor “0”) e dois temporizadores relacionados (replyDelay e cleanUp). Cada
registro em uma pendingList é mantido por um período que determina o seu
tempo de vida (cleanUp). Os temporizadores numReplies e cleanUp são
descritos na Seção 4.6; o temporizador replyDelay é descrito na Seção 4.7. A
Figura 16 traz a representação da estrutura de dados pendingList, utilizando a
notação ASN.1.
Figura 15 – Estrutura de dados pendingList.

O Protocolo P2PDP 113
Figura 16 – Representação ASN.1 da estrutura de dados pendingList.
Após atualizar a pendingList, o colaborador responde à requisição
(mensagem IReq) de acordo com a sua disposição em colaborar (willingness),
como descrito na Seção 4.7. Além de responder às requisições, os nós podem
atuar como intermediários na difusão das mensagens IReq para os demais
colaboradores na MANET, caso numHops < maxHops. As mensagens IReq são
retransmitidas utilizando-se broadcast limitado. Independentemente do
mecanismo adotado, antes que uma requisição seja retransmitida, ela deve ter o
campo numHops incrementado e o campo hopID atualizado com a identificação do
nó que realizou a retransmissão. A atualização do valor de hopID possibilita que
os nós mais distantes na MANET mantenham o caminho de retorno em suas
estruturas locais pendingList.
Mensagens CollaboratorReply (CRep) são enviadas salto-a-salto por
broadcast direcionado pelos colaboradores para os coordenadores em resposta às
mensagens IReq (passos 2/2’ e 3 da Figura 12). Ao receber uma mensagem CRep,
se o dispositivo integra o seu caminho de retorno, ele procura, em sua
pendingList, por um registro correspondente àquela requisição para determinar
qual será o próximo salto através do qual a mensagem deverá ser encaminhada.
Esse processo continua até que a mensagem alcance o seu destino final, ou seja, o
nó que originou a requisição de serviço (mensagem IReq). Cada mensagem CRep
é associada à requisição que o dispositivo está respondendo pelo identificador
obtido a partir da mensagem IReq correspondente (reqID). Uma mensagem CRep
informa ao coordenador sobre o endereço do nó colaborador (collabAddr), bem
como sobre a sua disponibilidade de recursos (resInfo) de acordo com o perfil da
requisição informado pelo iniciador na requisição correspondente. Como o perfil

O Protocolo P2PDP 114
de execução do serviço, embutido no perfil da requisição, é descrito em termos de
recursos dinâmicos, é importante ressaltar que, para alguns desses recursos, o
mecanismo de descoberta deve estar associado com alguma forma de reserva
antecipada [Wolf et al. 1995; Smith et al. 2000], o que oferece um nível mínimo
de garantia de que o serviço será de fato utilizado após ser descoberto. Como
ilustrado na Figura 17, além dos campos reqID, collabAddr e resInfo, uma
mensagem CRep também é composta pela identificação do nó que encaminhou a
requisição ao colaborador (retPath). O colaborador obtém essa identificação a
partir do valor do campo hopID na entrada correspondente à mensagem IReq na
sua pendingList. A Figura 18 traz a representação da mensagem CRep, utilizando
a notação ASN.1.
Figura 17 – Mensagem CollaboratorReply (CRep).
Figura 18 – Representação ASN.1 da mensagem CollaboratorReply (CRep).
Finalmente, as mensagens CollaboratorReplyList (CRepList) são
enviadas pelo coordenador para o iniciador. Uma mensagem CRepList é
composta de uma lista que resume as respostas dos colaboradores selecionados no
contexto de uma mesma requisição (passo 4 da Figura 12). Coordenadores
constroem mensagens CRepList como descrito a seguir. Quando um coordenador
recebe uma mensagem IReq, ele insere uma nova entrada representando a

O Protocolo P2PDP 115
requisição em uma estrutura de dados local, denominada resumeList, que é
representada na Figura 19. Cada registro em uma resumeList é constituído pelo
identificador da requisição (reqID) e pelo número de colaboradores que o
iniciador necessita envolver na distribuição da tarefa (numMaxReplies). Tal
entrada é associada a um temporizador (resumeDelay), configurado em função do
retardo de resposta máximo (maxReplyDelay) que o iniciador admite. 1 Quando
esse temporizador expira, o coordenador sumariza todas as mensagens CRep que
foram recebidas, associadas à requisição pendente, descartando, se preciso, as
mensagens CRep excedentes. A lista resultante é então enviada ao iniciador que
efetuou a requisição em uma única mensagem CRepList. A Figura 20 traz a
representação da estrutura de dados resumeList, utilizando a notação ASN.1.
Figura 19 – Estrutura de dados resumeList.
Figura 20 – Representação ASN.1 da estrutura de dados resumeList.
4.6.
O Algoritmo de Supressão de Respostas
Nesta seção, é apresentado o mecanismo de supressão de mensagens de resposta
por vizinhança (Suppression by Vicinity – SbV), que permite tratar o problema da
implosão de respostas em protocolos de descoberta para MANETs baseados em
difusão [Duffield et al. 1999]. O mecanismo SbV adota uma abordagem peer-topeer,
independente de protocolos de roteamento ou mesmo do endereçamento no
nível de rede na MANET. Embora tenha sido projetado no contexto do protocolo
1 No caso de um coordenador centralizado, esse temporizador deve considerar também o retardo
de transferência entre iniciadores e coordenadores.

O Protocolo P2PDP 116
P2PDP, esse mecanismo pode ser empregado em diferentes protocolos de
descoberta, sejam eles reativos – em que serviços são descobertos, sob demanda,
pelos dispositivos requisitantes – ou proativos – baseados no envio periódico de
anúncios de serviços pelos dispositivos provedores. Pelos resultados
experimentais, obtidos através do uso do mecanismo SbV com o protocolo
P2PDP, foi possível atestar a sua eficiência (vide Capítulo 6).
A Figura 21 traz o pseudocódigo do algoritmo de supressão, descrito a
seguir.
Figura 21 – O algoritmo de supressão de respostas por vizinhança SbV.
No mecanismo SbV as respostas são transmitidas salto-a-salto, através de
broadcast, pelos dispositivos na vizinhança da origem de uma requisição. Nesse
contexto, “vizinhança” diz respeito aos dispositivos localizados no diâmetro da
requisição, os quais são denominados de “vizinhos”. Ao receber uma resposta, o
dispositivo verifica se a mesma não corresponde a uma mensagem por ele
originada (linha 1). Essa condição é verificada caso exista uma entrada para a
requisição em questão, identificada através do campo msg.reqID, em sua
pendingList e o valor do campo msg.collabAddr seja igual ao identificador do

O Protocolo P2PDP 117
dispositivo local (localID). Nesse caso, a mensagem é então encaminhada para o
processamento de reconhecimento de envio de mensagens de resposta (vide Seção
4.8). Caso contrário, a mensagem é processada como descrito a seguir.
Quando um dispositivo recebe uma resposta correspondendo a uma
requisição dele originada, o dispositivo processa a mensagem e a retira da
MANET (linha 4). Se, ao invés, a resposta estiver endereçada a um outro
dispositivo, o receptor verifica primeiramente se a mesma corresponde a uma
resposta válida, ou seja, se há uma entrada em sua pendingList relacionada à
requisição correspondente e se nenhuma outra resposta do dispositivo em questão
(msg.collabAddr) foi processada anteriormente. Em caso negativo, a resposta é
descartada. 2 Senão, o dispositivo incrementa o valor do campo numReplies (N R ) e
compara o novo valor de N R com o valor do campo numMaxReplies (N M ) na
entrada correspondente em sua pendingList. Se N R = N M , isso indica que já
foram encaminhadas mensagens de resposta suficientes para atender à requisição
do iniciador. Nesse caso, o dispositivo suprime uma eventual resposta sua que não
tenha sido ainda transmitida. A seguir, o dispositivo compara sua própria
identificação com o valor do campo retPath na resposta. Se os valores são
iguais, o dispositivo se encontra no caminho de retorno da mesma. Nesse caso, se
N R ≤ N M , o dispositivo pode encaminhar a mensagem de resposta na direção do
dispositivo que corresponde ao próximo salto no caminho de retorno da resposta.
A identificação desse dispositivo é obtida pelo campo hopID, na entrada
relacionada à requisição correspondente em sua pendingList. Se N R > N M , o
dispositivo suprime a resposta recebida. Para permitir futuras supressões, a
entrada correspondente na pendingList é mantida no dispositivo até que o
temporizador cleanUp expire. Na implementação proposta (veja o Capítulo 5),
cada dispositivo configura individualmente o temporizador cleanUp associado a
cada entrada na sua pendingList para τ max unidades de tempo, como dado por
τ = − HS
(1)
max
Dmax 2
2 Em condições ideais, essa situação não poderia acontecer, devido ao mecanismo de inundação de
requisições. Contudo, fatores como colisões ou o uso de esquemas inibidores de redundância em
inundações [Tseng et al. 2003] podem ocasionar situações desse tipo.

O Protocolo P2PDP 118
Na Equação (1), D max corresponde ao retardo máximo de envio da resposta
tolerado pelo iniciador. H e S são parâmetros de sintonização, usados para
contabilizar os retardos de transferência que as mensagens IReq e CRep podem
experimentar. H representa a distância, em número de saltos, entre o dispositivo
colaborador e o que originou a requisição; essa associação é feita com fins de
garantir justiça entre os colaboradores, evitando que os nós mais distantes
apresentem os maiores retardos. 3 S permite a sintonização do valor de τ max de
acordo com o retardo de transferência 4 experimentado em cada dispositivo. Os
valores de D max e H são obtidos, respectivamente, a partir dos campos
maxReplyDelay e hopCount da mensagem IReq. Dessa forma, o cálculo de τ max
possibilita que um nó colaborador, mais próximo do nó que originou a requisição,
mantenha entradas em sua pendingList por mais tempo do que os nós mais
distantes, considerando os retardos adicionais, aos quais as respostas dos nós mais
distantes estão sujeitas.
O parâmetro S é configurável, podendo ser alterado pelo usuário. Entretanto,
na especificação do protocolo P2PDP o valor default de S foi configurado para
10 ms. Esse valor corresponde a mesma ordem de grandeza que o retardo sofrido
por pacotes de dados de 1500 bytes sendo transmitidos a uma taxa de 1 Mbps,
percorrendo uma distância de 100 m, desconsiderando possíveis variações
provocadas pelo enfileiramento de pacotes nos buffers de transmissão e recepção e
mecanismos de contenção de acesso ao meio.
A Figura 22 ilustra o funcionamento do mecanismo SbV. Na figura, os nós
w e z estão no raio de transmissão do nó y. A Figura 22(a) traz a configuração
inicial das estruturas pendingList dos nós z e y. Na Figura 22(b), o nó y recebe
3 Dependendo do tipo de serviço requisitado, pode ser necessário privilegiar as respostas
provenientes dos colaboradores mais próximos (considerando o número de saltos). Segundo
[Lenders et al. 2005], existem muitas razões para se querer privilegiar as instâncias mais próximas
de um serviço. Para mencionar algumas, a comunicação entre nós co-localizados geralmente reduz
o retardo fim-a-fim e a probabilidade de falha na rota, devido a mobilidade dos nós, reduzindo
também a interferência causada pelas transmissões de dados; a observação desses aspectos, de um
modo geral, aumenta a capacidade da rede.
4 O retardo de transferência corresponde a soma dos retardos de acesso e de transmissão, sendo, na
grande maioria dos casos, uma variável aleatória. No entanto, em alguns protocolos, o maior valor
que o retardo de transferência pode assumir é finito.

O Protocolo P2PDP 119
uma resposta (CRep) para uma requisição (IReq) com reqID=1000 5 e incrementa
o valor de N R do campo numReplies na entrada correspondente em sua
pendingList. Como, na Figura 22(c), o nó y é o caminho de retorno da resposta,
y reencaminha a mensagem, fazendo broadcast local direcionado ao nó w, que
corresponde ao próximo salto de y no caminho de retorno. O nó z “escuta” a
mensagem e, assim como y, incrementa o valor de N R do campo numReplies na
entrada correspondente em sua pendingList, mas ele não reencaminha a
mensagem, pois z não está no seu caminho de retorno. Na Figura 22(d), z recebe
uma nova resposta para a requisição com reqID=1000, mas, embora ele esteja em
seu caminho de retorno, ele não a encaminha, pois o campo numMaxReplies, na
entrada correspondente em sua pendingList, indica que ele já encaminhou ou
“escutou” N M mensagens.
( a ) ( b )
( c ) ( d )
Figura 22 – Cenário ilustrando a supressão de mensagens CRep com o algoritmo SbV.
5 O valor “1000” utilizado para representar o valor de reqID é meramente ilustrativo. Como já foi
mencionado no início do capítulo, o valor do campo reqID é calculado de forma a se obter um
identificador único universal.

O Protocolo P2PDP 120
No mecanismo SbV, ao receber uma requisição específica, um dispositivo
móvel pode detectar – antes de enviar a sua própria resposta –, se algum outro
dispositivo, com mais recursos, já tenha respondido àquela requisição. Desse
modo, o envio das mensagens de resposta através de broadcast permite que as
respostas dos dispositivos mais aptos suprimam respostas excedentes provenientes
dos outros dispositivos da vizinhança, os quais possuem menos recursos
disponíveis. Em uma rede sem fio ad hoc de saltos múltiplos, mesmo com a
adoção do mecanismo de supressão, o envio de mensagens de controle –
requisição e descoberta – através de broadcast ainda poderia provocar a implosão
de respostas. Isso se deve à redundância de caminhos seguidos pelas mensagens
de controle até o seu destino, o que provoca, como efeito colateral, uma
sobrecarga com o seu processamento nos nós intermediários, além de consumir
recursos escassos em MANETs, como banda passante e energia. Para evitar esse
problema, no algoritmo SbV uma mensagem CRep é enviada, através do seu
caminho de retorno, na direção do nó que originou a requisição, mas cada nó
intermediário, nesse caminho, informa aos seus vizinhos – devido ao mecanismo
de broadcast salto-a-salto – sobre as requisições que já foram respondidas,
possibilitando futuras supressões ao longo desse caminho, incluindo a vizinhança
dos dispositivos no caminho. Isso permite reduzir a implosão de respostas, que é
intrínseca às abordagens de descoberta baseadas em broadcast
[Duffield et al. 1999]. Além disso, conforme demonstram os resultados
experimentais (vide Capítulo 6), esse mecanismo promove um aumento na
supressão de mensagens de resposta redundantes à medida que as respostas vão se
aproximando do dispositivo requisitante – considerando a proximidade física dos
dispositivos em função da distância em número de saltos –, configurando, desse
modo, uma solução escalável no que diz respeito ao número de dispositivos
participantes e à densidade da MANET.
Vale destacar que, em MANETs cujo controle de acesso ao meio físico é
baseado no protocolo CSMA/CA (Carrier Sense Multiple Access / Collision
Avoidance), o uso de um esquema de broadcast salto-a-salto, como proposto pelo
mecanismo SbV, exclui a aplicação dos mecanismos de acesso baseados em
confirmação ou no diálogo RTS/CTS (Request-To-Send / Clear-To-Send),
oferecidos por esse protocolo, tornando as transmissões de mensagens menos

O Protocolo P2PDP 121
confiáveis devido à maior probabilidade de perdas por colisão. A ausência de
reconhecimento pode ser solucionada indiretamente no próprio mecanismo SbV
(vide discussão a respeito na Seção 4.8). Contudo, é interessante também que, em
conjunto com o SbV, seja adotado algum mecanismo que garanta um certo
assincronismo na transmissão das respostas, de modo a reduzir a probabilidade de
colisões. Isso pode ser conseguido, por exemplo, através de um retardo
programado no envio das respostas [Duffield et al. 1999]. O algoritmo DR,
descrito na próxima seção, supre essa necessidade no protocolo P2PDP como um
efeito colateral benéfico. O algoritmo DR foi projetado com o intuito de promover
a seleção das melhores respostas a uma requisição de serviço em função da
disponibilidade de recursos em cada colaborador.
4.7.
O Algoritmo para o Cálculo do Retardo no Envio de Respostas
No protocolo P2PDP, cada nó disposto a colaborar na provisão de um serviço
específico retarda a transmissão de suas mensagens CRep de acordo com o
temporizador replyDelay, associado à requisição em questão (reqID), na entrada
correspondente em sua pendingList. O algoritmo de “retardo de respostas”
(Delayed Replies – DR) configura esse temporizador de modo que ele seja
inversamente proporcional à disponibilidade dos recursos do nó que são
necessários para prover o serviço requisitado. Como resultado, os dispositivos
com mais recursos são os primeiros a responder às requisições de descoberta de
serviços. Além disso, o retardo diferenciado do envio reduz o problema de colisão
de mensagens de resposta. O algoritmo DR é executado de forma distribuída e
completamente independente em cada colaborador para cada requisição
respondida.
É preciso ressaltar que a determinação do retardo no envio da resposta é
flexível no que tange aos recursos sendo considerados, para a provisão do serviço
– por exemplo, qualidade do enlace sem fio, carga de CPU livre, energia
disponível na bateria –, e à importância relativa entre eles – denominada “peso” –,
o que permite que com os mesmos recursos possam ser especificados critérios de
seleção diferenciados para aplicações com características distintas. A informação
sobre quais recursos devem ser considerados no cálculo da adequação de um nó e

O Protocolo P2PDP 122
os pesos relativos é transportada pelas mensagens IReq, no campo ctxtInfo,
definido no requisitante. Como foi visto na Subseção 2.3.1.2, esse campo é
determinado em função das características da aplicação, podendo ser definido pelo
desenvolvedor da aplicação ou, ainda, através de valores padrões, especificados na
subcamada de adaptação implementada para a família a qual a aplicação pertence
(Subseção 2.3.2.3). Quando um nó recebe uma requisição, ele obtém seu estado
atual, através do serviço MoGrid de gerência de contexto (ContextListener), em
função dos recursos de interesse para calcular o retardo de resposta. Para esse
algoritmo funcionar a contento, todos os nós, na MANET, devem empregar o
mesmo critério no cálculo do retardo. Na implementação do P2PDP (veja o
Capítulo 5), um nó colaborador configura o temporizador replyDelay, na entrada
correspondente ao identificador da requisição recebida (reqID) em sua
pendingList, para τ unidades de tempo, conforme dado por
⎛ ⎛ ⎞⎞
τ = ⎜1 − ω τ ,
⎜
⎝ ⎝ ⎠⎠
N
⎜ αiPi
⎟⎟
0 ≤ ≤1
∑ N
max
i=
1 ⎜ ∑ P ⎟⎟
0 < ω ≤1
j=
1 j
α
(2)
A Equação (2) pode ser dividida em duas partes: a primeira, expressando a
“função de adequação” do dispositivo e a segunda, representando o valor de τ max ,
obtido através da Equação (1). Na função de adequação, ω indica a disposição
(“boa vontade”) do nó colaborador em participar da provisão do serviço, podendo
assumir qualquer valor no intervalo (0, 1]. ω é um parâmetro subjetivo, um fator
determinado pelo usuário que descreve o nível de interesse do usuário em permitir
que o seu dispositivo colabore com os outros na MANET. τ não é definido para
ω = 0, uma vez que tal valor significa que o usuário não deseja participar da
provisão do serviço. Nesse caso, nenhuma resposta será enviada pelo nó
colaborador; ele apenas atuará como um nó intermediário no encaminhamento de
mensagens do protocolo de descoberta. N representa o número dos diferentes tipos
de recursos que o nó colaborador deve considerar. P i corresponde ao peso que
descreve a importância relativa de cada recurso do tipo i, 1 ≤ i ≤ N. Os valores de
{P 1 , P 2 , ..., P N } são obtidos a partir do campo ctxtInfo transmitido na requisição
(mensagem IReq). α i corresponde ao nível normalizado de disponibilidade, no
intervalo [0, 1], do recurso do tipo i no nó colaborador. Considerando-se, por
exemplo, o recurso energia, α energia assumirá um valor percentual de 0% a 100%

O Protocolo P2PDP 123
em função da carga residual da bateria disponível no dispositivo. Já o valor de
P energia é definido pelo iniciador, na requisição, em função da importância do
recurso para a execução do serviço solicitado. É importante mencionar
que os diferentes tipos de recursos que podem ser monitorados são determinados
pela implementação do serviço monitor do MoGrid, aos quais está associada uma
ordenação única, que garante a correta associação entre α i e P i . Finalmente, o
valor de τ max corresponde a expressão (D max – 2HS), que é descrita na Equação (1),
pelo algoritmo SbV, e corresponde a uma parcela do valor de retardo máximo que
uma resposta pode sofrer (maxReplyDelay); lembrando que o valor de D max é
definido pelo iniciador na mensagem de requisição de serviço (IReq).
É importante mencionar que o parâmetro S, presente nas Equações (1) e (2),
é ajustado em função da qualidade do enlace sem fio que influencia no retardo de
transferência, sendo responsável pelo cálculo dos temporizadores associados ao
retardo de envio de respostas (τ) e da validade das entradas na pendingList
(τ max ), relacionadas à construção do caminho reverso ao percorrido pela requisição
que é utilizado no encaminhamento das respostas. Os registros da estrutura de
dados local pendingList são criados durante o processamento da requisição e
mantidos como soft state até que a sua validade – determinada pelo campo
cleanUp – expire. As informações contidas nessa estrutura de dados auxiliam no
roteamento das mensagens de resposta; caso não sejam localizadas entradas na
pendingList, o roteamento das respostas é feito por broadcast local nãodirecionado,
ou seja, alcançando todos os nós no raio de transmissão do nó
intermediário.
A seguir é feita uma análise da correspondência entre os valores obtidos,
para τ e τ max , para uma dada requisição. Na Equação (1), o cálculo de τ max define o
tempo máximo que as informações sobre uma dada requisição devem ser mantidas
na tabela de requisições pendentes, considerando-se o tempo que o iniciador está
disposto a esperar por respostas, a distância entre o colaborador e o iniciador e o
retardo de transferência que as mensagens trocadas entre eles experimentam. Um
colaborador que esteja apto a responder a essa requisição deve enviar a sua
resposta em um período inferior ou igual a τ max , dado que, depois que esse tempo
tiver transcorrido, a sua resposta não será recebida em tempo hábil. O algoritmo
DR utiliza a função de adequação do colaborador – somatório dos valores de

O Protocolo P2PDP 124
{α 1 , α 2 , ..., α N }, normalizados por {P 1 , P 2 , ..., P N }, aplicados à ω – para gerar
retardos no envio das respostas, calculados através da Equação (2), que sejam
inversamente proporcionais a sua disponibilidade de recursos. Desse modo,
quanto maior for o valor obtido pelo cálculo da função de adequação, mais
rapidamente a resposta do colaborador será transmitida, promovendo um
mecanismo de seleção das melhores respostas no seu envio. O cálculo da função
de adequação é realizado com as informações obtidas através do monitoramento
do contexto de cada dispositivo da rede que é realizado pelo serviço monitor da
arquitetura MoGrid (Subseção 2.3.1.2). Se ainda assim o número total de
respostas produzido – numReplies (N R ) – for maior do que o número máximo de
respostas solicitado pelo nó requisitante – numMaxReplies (N M ) –, o coordenador
da requisição se encarrega de selecionar as N M primeiras respostas recebidas. O
algoritmo DR garante que as mensagens dos colaboradores mais aptos a prover o
serviço serão privilegiadas pelos coordenadores das requisições.
4.8.
O Mecanismo para o Reconhecimento do Envio de Respostas
Como foi mencionado na Seção 4.6, o uso de um esquema de encaminhamento de
mensagens por broadcast salto-a-salto, como o proposto pelo algoritmo SbV,
exclui da aplicação qualquer tipo de mecanismo de acesso baseado em
confirmação na camada de acesso ao meio físico, o que torna as transmissões de
mensagens menos confiáveis, devido ao aumento da probabilidade de perdas
provocadas pela ocorrência de colisões. Para contornar o problema da baixa
confiabilidade das transmissões broadcast, no protocolo CSMA/CA, foi
desenvolvido um mecanismo de reconhecimento salto-a-salto de respostas, que
aproveita a própria transmissão em broadcast de uma resposta por um dispositivo
como reconhecimento para a transmissão dessa mesma resposta pelo dispositivo
anterior, no caminho de retorno da mensagem. Para isso, utilizou-se a
característica de “propagação em eco” da comunicação por broadcast, em redes
sem fio ad hoc de saltos múltiplos, para implementar um mecanismo de
reconhecimento implícito no SbV. Como ilustrado na Figura 23, propagação em
eco diz respeito à recepção de uma mensagem de resposta, pelo dispositivo que a
originou, através do seu vizinho direto, que corresponde ao próximo salto em

O Protocolo P2PDP 125
direção ao dispositivo que originou a requisição. No exemplo dessa figura, o
dispositivo N 1 gerou uma resposta (CRep 1 ) e a transmitiu na MANET por
broadcast local direcionado, alterando o campo retPath da mensagem para o
valor do identificador do nó N 4 . De acordo com o algoritmo SbV, como os nós N 2
e N 3 não estão no caminho de retorno da mensagem, eles a descartam (linha 23, na
Figura 21). Ao receber a mensagem de resposta, por sua vez, N 4 procede de modo
similar à N 1 , já que ele se encontra no caminho de retorno da mensagem, e a
encaminha por broadcast local na direção do nó que originou a requisição,
alterando o campo retPath da mensagem para o valor do identificador do nó N 5 .
Como conseqüência da propagação em eco das mensagens pelo P2PDP, o nó N 1
receberá a própria resposta que ele originou de N 4 , o dispositivo que corresponde
ao próximo salto no caminho de retorno, levando a uma confirmação implícita da
transmissão anterior.
Figura 23 – Propagação em eco de mensagens CRep pelo protocolo P2PDP.
O mecanismo de reconhecimento atua em dois instantes distintos: (i) no
tratamento de mensagens de requisição, quando o dispositivo pode colaborar e
envia uma mensagem de resposta ao nó que requisitou o serviço, e (ii) no
tratamento das mensagens de resposta duplicadas que são “escutadas” pelo
dispositivo, embutido na lógica do algoritmo SbV (Figura 21, linha 2). Em (i) o
dispositivo agenda o reenvio da mensagem de resposta para um tempo específico
caso o seu reconhecimento não seja recebido antes que esse tempo expire. Já em
(ii), o dispositivo monitora as respostas que ele encaminha ou apenas “escuta”,

O Protocolo P2PDP 126
cancelando o reenvio agendado se o reconhecimento do envio da sua resposta for
recebido.
A Figura 24 traz o pseudocódigo do algoritmo de tratamento das
requisições P2PDP (IReq), onde o mecanismo de reconhecimento é inicializado.
Figura 24 – O algoritmo de tratamento de requisições.
Ao receber uma requisição de serviço, o dispositivo verifica se ela já não
foi tratada localmente, consultando se há uma entrada em sua pendingList
relacionada à requisição correspondente. Em caso positivo, a requisição já foi
processada pelo dispositivo e é então descartada. Senão, o dispositivo encaminha
a requisição, em broadcast local, para os seus vizinhos, obedecendo à restrição
imposta pelo diâmetro da requisição, isto é, a requisição só será encaminhada se
numHops ≤ maxHops. A seguir, o dispositivo verifica se pode colaborar, ou seja, se
ele disponibiliza o serviço, e se o valor de ω está no intervalo (0, 1]. Se essas
condições se verificam, então, o dispositivo adiciona a requisição como uma
entrada em sua pendingList, pelo período de tempo definido por τ max , que é
calculado por meio da Equação (1). Na linha 7 da Figura 24, a resposta à
requisição é gerada, e o seu envio é escalonado em função do temporizador τ –
calculado utilizando-se a Equação (2). A resposta gerada é encaminhada por
broadcast local direcionado ao nó que a originou, utilizando como próximo salto,
no caminho de retorno ao percorrido pela requisição, o identificador de
dispositivo obtido através do campo hopID na pendingList local. Nesse ponto, é
acionado o mecanismo de reconhecimento, com o agendamento de reenvio da

O Protocolo P2PDP 127
mensagem de resposta para o tempo definido pelo temporizador ackTimer (linha
9). O período de duração desse temporizador é calculado tendo como resultado
um valor no intervalo (τ, τ max ). O reenvio da resposta, associado a esse
agendamento, só será de fato realizado caso o dispositivo não receba o
reconhecimento na recepção da mensagem de resposta.
A Figura 25 traz o pseudocódigo do algoritmo de monitoramento das
mensagens de resposta do protocolo P2PDP (CRep). Esse algoritmo possibilita o
reconhecimento de envio de respostas originadas pelo próprio dispositivo, como
pode ser visto, a seguir, em mais detalhes.
Figura 25 – O algoritmo de reconhecimento de envio de respostas.
Como se pode observar no pseudocódigo do algoritmo SbV, ilustrado na
Figura 21, quando um dispositivo recebe uma resposta, originada por ele, a uma
requisição de serviço da MANET, o dispositivo detecta que a mensagem foi
originada localmente (teste na linha 1) e aciona o mecanismo de reconhecimento
implícito de envio de respostas (linha 2). No pseudocódigo do algoritmo de
reconhecimento de envio de mensagens de resposta, Figura 25, o dispositivo
averigua, primeiramente, se há uma entrada em sua pendingList relacionada à
requisição correspondente. Em caso positivo, o dispositivo testa se o identificador
do nó que entregou a mensagem (msg.source) corresponde ao próximo salto
(entrada.hopID), para a requisição em questão (msg.reqID), na sua
pendingList, ou se o número de respostas recebidas (N R ) é maior ou igual ao
número de respostas esperado (N M ), para a mesma requisição (msg.reqID). Se a
primeira condição se verifica (msg.source = entrada.hopID), o dispositivo tem
uma confirmação de que a sua resposta foi recebida pelo nó no próximo salto no
caminho de retorno, em direção ao dispositivo que originou a requisição. Se a
segunda condição se verifica (N R ≥ N M ), isso significa que já foram encaminhadas
mensagens de resposta suficientes para atender à requisição do iniciador. Se

O Protocolo P2PDP 128
qualquer das duas condições se verifica (teste na linha 4), o agendamento de
reenvio da resposta é cancelado (linha 5), caso o temporizador de reenvio
(ackTimer) ainda não tenha expirado. Caso contrário, é detectada a ocorrência de
uma colisão pela não propagação do eco da mensagem de resposta dentro do
período de tempo esperado (ackTimer) e, como resultado, o reenvio da resposta é
efetivado. O reenvio é feito definindo-se o próximo salto da mensagem de
resposta como o endereço de broadcast local. Como conseqüência do reenvio,
todos os nós que são vizinhos diretos do dispositivo que originou a resposta irão
tratá-la, encaminhando-a na MANET, por broadcast direcionado – caso conheçam
a identificação do dispositivo que corresponde ao próximo salto em direção ao
dispositivo que solicitou o serviço – ou por broadcast local. Esse procedimento é
repetido em todos os nós intermediários até que a mensagem alcance o seu
destino.
Atualmente, o reconhecimento de envio de respostas no protocolo P2PDP
não é processado nos nós intermediários, apenas no nó que originou a requisição.
Essa solução pode ser estendida, contemplando todos os dispositivos no caminho
de retorno da mensagem. É importante ressaltar que o mecanismo de
retransmissão de mensagens de resposta oferece uma solução preliminar
considerada nesta tese para o tratamento de falhas no enlace, devido à mobilidade
dos dispositivos. Caso a mensagem de resposta gerada por um dispositivo seja
suprimida por todos os seus vizinhos diretos, não será possível efetuar o
reconhecimento de envio da mensagem em questão. Nesse caso, a retransmissão
da mensagem não poderá ser evitada.
4.9.
Análise Comparativa do Protocolo P2PDP
O objetivo desta seção é comparar os protocolos de descoberta de serviços para
redes sem fio ad hoc de saltos múltiplos, apresentados no Capítulo 3, com as
principais contribuições propostas no protocolo P2PDP, a saber:
Boa vontade em colaborar (willingness). Parâmetro configurável pelo
usuário para indicar o quanto ele está disposto a colaborar com os demais,
independentemente do seu dispositivo oferecer, ou não, os serviços que estão
sendo solicitados. Como foi mencionado na Seção 4.7, esse parâmetro pode ser

O Protocolo P2PDP 129
definido em tempo de execução, sendo ajustado automaticamente em função de
variações na disponibilidade dos recursos do dispositivo móvel.
Diâmetro da requisição. Parâmetro configurável pelo usuário para indicar o
número máximo de saltos (maxHops) que as suas requisições por serviços podem
trafegar. Esse parâmetro limita o alcance da requisição, oferecendo um
mecanismo de difusão controlado, evitando que a mensagem se propague
indefinidamente na rede.
Controle do número de respostas a cada requisição. Configurável pelo
usuário e utilizado para reduzir o tráfego de mensagens de resposta na rede
(numMaxReplies). A cada requisição é associado um número limite de respostas
esperado.
Nível de adequação do colaborador à requisição (suitability). Cada
dispositivo calcula, segundo uma função de adequação, o quanto ele está apto para
atender à requisição dos outros nós. O resultado obtido corresponde a um valor no
intervalo [0, 1]. A função de adequação é aplicada considerando-se os recursos
computacionais que o dispositivo possui no momento em que a requisição é
recebida e o perfil de execução do serviço requisitado, que define a prioridade que
cada recurso computacional tem para a utilização do serviço.
Retardo programado do envio de mensagens de resposta. As respostas às
requisições são retardadas em função da adequação do nó em atender à
solicitação, analisando a capacidade do dispositivo em função do perfil de
execução do serviço requisitado (veja a descrição do algoritmo DR, Seção 4.7). A
requisição do usuário indica o tempo que o dispositivo que originou a requisição
está disposto a aguardar por respostas à sua solicitação (campo maxReplyDelay
da mensagem IReq). A uma variação desse tempo de espera – valor de τ max obtido
através da Equação (1) –, é aplicado o valor obtido através da função de
adequação – vide Equação (2); o resultado é usado para ajustar o temporizador,
que determinará quão rapidamente um colaborador deverá responder à requisição
do iniciador.
Supressão de mensagens de resposta na vizinhança. As mensagens de
resposta no P2PDP são enviadas por broadcast local direcionado e retransmitidas
através do caminho reverso ao realizado pela mensagem de requisição. Durante o

O Protocolo P2PDP 130
encaminhamento da resposta, os nós intermediários podem suprimir mensagens de
resposta de acordo com o parâmetro numMaxReplies (veja a descrição do
algoritmo SbV, Seção 4.6). Esse parâmetro é usado pelos dispositivos para inibir
o envio de suas próprias respostas – se ele se identificou como um possível
colaborador –, ou das respostas que são encaminhadas através dele, caso o número
de respostas que ele tenha “escutado” já seja suficiente para atender à requisição
do iniciador.
A Tabela 3 traz um resumo comparativo do P2PDP, com os protocolos para
descoberta de serviços em redes sem fio ad hoc de saltos múltiplos introduzidos
no Capítulo 3, em função dos parâmetros apresentados nesta seção. Os símbolos
“NT” e “PT” indicam, respectivamente, “não tratado” e “parcialmente tratado”.
Tabela 3 – Resumo comparativo entre o protocolo P2PDP e os protocolos de descoberta
de serviços para MANETS de saltos múltiplos.
Boa Vontade
(Willingness)
Diâmetro da
Requisição
Número de
Respostas
Adequação
(Suitability)
Retardo
Programado
Supressão de
Respostas
P2PDP
Parâmetro
configurável pelo
usuário, de modo
manual ou
dinâmico,
variando de [0,1],
que indica o
quanto o
dispositivo está
disposto a
colaborar
O parâmetro
maxHops limita o
número de saltos
que uma
mensagem de
requisição (IReq)
pode trafegar
O parâmetro
numMaxReplies
é utilizado para
limitar o número
de mensagens de
resposta na rede
A função de
adequação de um
colaborador é
mensurada de
acordo com o
perfil de
execução provido
pelo iniciador que
efetuou a
requisição
(ctxtInfo na
operação
createRequest
Profile())
As respostas às
requisições são
temporizadas em
função da
adequação do nó
em atender à
solicitação e do
tempo máximo
que o solicitante
está disposto a
esperar
(maxReply
Delay)
Os nós
intermediários
escutam as
respostas a todas
as requisições e
restringem o
encaminhamento
da mensagem
em função da
informação sobre
o número de
respostas
esperado pelo
iniciador
GSD
NT
Diâmetro limitado
por um parâmetro
configurável pelo
usuário e também
pela semântica
de grupos,
responsável pelo
encaminhamento
seletivo das
requisições para
os dispositivos
que possuem
informações
sobre o mesmo
grupo de serviço
da requisição
NT NT NT
NT
Múltiplas
respostas podem
ser geradas por
um mesmo nó,
caso ele possua
mais de uma
entrada para o
serviço em sua
tabela (serviços
locais ou
remotos),
entretanto, a
seleção de
serviços é
manual

O Protocolo P2PDP 131
Boa Vontade
(Willingness)
Diâmetro da
Requisição
Número de
Respostas
Adequação
(Suitability)
Retardo
Programado
Supressão de
Respostas
Allia
Ao receber uma
requisição, o
dispositivo decide
se irá processála,
ou não, com
base na sua
política local.
Especificação na
política local de
um parâmetro
que restringe o
número de saltos
que a requisição
pode trafegar
(diâmetro da
aliança)
NT NT NT NT
Konark
Gossip
NT
NT
A requisição é
enviada para o
endereço de
grupo Konark,
utilizando
multicast
NT
PT
As propriedades
associadas ao
serviço podem
ser usadas para
indicar a
adequabilidade
do provedor
O envio de
anúncios é
temporizado para
evitar inundação
(multicast) e
permitir que o nó
“aprenda” mais
sobre a rede,
enviando
respostas mais
completas e
sumarizadas
PT
Implementa
sumarização; as
respostas são
enviadas de
forma
incremental; cada
nó ouve as
respostas que
trafegam na rede
e só respondem
caso possuam
alguma
informação
adicional
ORION NT NT NT NT NT
Os nós
intermediários
sumarizam as
respostas que
recebem, antes
de entregá-las ao
solicitante
[Varshavsky
et al. 2005]
NT
NT
Depende do
protocolo de
roteamento
utilizado
NT NT NT NT
FTA
NT
A requisição é
encaminhada ao
provedor que
oferecer o melhor
tradeoff entre
proximidade
física e
capacidade de
oferecer o serviço
PT
Cada requisição
emitida sempre
terá como
resultado apenas
uma resposta
É introduzido o
conceito de CoS
(Capacity of
Service); esse
valor é calculado
e divulgado, na
rede, por cada
provedor,
definindo a sua
capacidade em
prover o serviço
NT
PT
Promove uma
supressão
implícita de
respostas, já que
os nós que irão
responder são
“selecionados” no
encaminhamento
da requisição
Em uma grade móvel ad hoc, a seleção dos dispositivos que irão colaborar
na execução de um conjunto de tarefas deve estar embutida no mecanismo de
descoberta, o que não ocorre nas propostas encontradas na literatura [Litke et al.
2004; McKnight et al. 2003], as quais, tradicionalmente, sugerem abordagens
independentes para tratar esses dois aspectos. Com o uso do P2PDP, as aplicações
se beneficiam dos mecanismos de descoberta e seleção, embutidos em um único
protocolo, sem a sobrecarga provocada pelo gerenciamento de mensagens de

O Protocolo P2PDP 132
anúncios de recursos e serviços, abordagem tipicamente adotada pelos protocolos
de descoberta de serviços propostos para MANETs de saltos múltiplos, como
aqueles descritos no Capítulo 3. Cabe aqui incluir uma comparação mais
detalhada entre o protocolo P2PDP e os protocolos que apresentam um
comportamento mais similar ao seu. Considerando-se os resumos comparativos
efetuados nas Tabelas 2 e 3, dentre os trabalhos analisados, a abordagem crosslayer
de Varshavsky et al. [2005] e o protocolo FTA [Lenders et al. 2005] são os
que apresentam maiores semelhanças com o protocolo P2PDP.
Diferentemente da maioria dos protocolos de descoberta de serviços
propostos para MANETs de saltos múltiplos, no protocolo P2PDP, a seleção das
melhores respostas é realizada de forma automática, sem a necessidade de
intervenção do usuário, como parte integrante do mecanismo de supressão de
respostas desnecessárias. Mesmo na abordagem cross-layer de Varshavsky et al.,
que oferece um mecanismo automático de seleção de respostas, o critério utilizado
não é o que melhor se adequa ao conceito de resource matching dos ambientes de
grade (Subseção 2.3.1); na abordagem proposta, o critério de seleção adotado é a
distância, em número de saltos, entre o cliente e os provedores de serviço. Como
se pode observar pelo resumo apresentado na Tabela 3, no protocolo FTA, é
apresentada uma abordagem que se adapta melhor às necessidades das grades
móveis ad hoc. Na proposta apresentada, o critério de seleção é configurável,
podendo ser implementado em função da distância na rede entre os dispositivos
envolvidos, na capacidade de cada provedor em oferecer o serviço (Capacity of
Service – CoS) ou utilizando uma combinação dos dois critérios. Entretanto, no
FTA, o gerenciamento da informação sobre a capacidade de prover o serviço
implica na troca periódica de mensagens de anúncios para atualizar o valor do
CoS, através da inundação da rede; cada tipo de serviço possui um CoS
específico. O gradiente de campo gerado por cada tipo de serviço que um
dispositivo disponibiliza na rede é definido através do cálculo de potencial do
serviço (φ) como o somatório do CoS de cada provedor do serviço pela distância
em número de saltos do dispositivo ao provedor, informações obtidas através das
mensagens de anúncio de serviços. A informação sobre o gradiente de campo
gerado por cada instância de serviço na rede é distribuída entre os vizinhos do
dispositivo a até um número de saltos específico, configurável pelo usuário.

O Protocolo P2PDP 133
A abordagem proposta no protocolo FTA é similar à adotada no protocolo
P2PDP, ambas implementam um mecanismo de seleção distribuído, entretanto, no
FTA, a seleção é feita no encaminhamento da requisição, que é direcionada ao
provedor mais apto, o que resulta na entrega de uma única resposta ao dispositivo
que originou a requisição de serviço. Por sua vez, no protocolo P2PDP, a seleção
é feita no encaminhamento das mensagens de resposta. O assincronismo no envio
dessas mensagens, obtido pela utilização do algoritmo DR (Seção 4.7), garante
que os provedores mais aptos serão os primeiros a responder. No FTA, cada
dispositivo precisa ter conhecimento prévio da CoS dos demais dispositivos, para
então definir o seu potencial para oferecer o serviço; no P2PDP, o dispositivo só
precisa ter conhecimento da sua informação de contexto, que diz respeito a
disponibilidade dos seus recursos, para definir se está apto ou não a colaborar
(suitability). Cada vez que um dispositivo recebe um anúncio de serviço, com uma
atualização do valor do CoS, é necessário que ele refaça o cálculo do seu potencial
em relação ao tipo de serviço em questão e o divulgue na MANET, o que incorre
em um problema de escalabilidade.
No P2PDP, os diferentes tipos de serviço definem perfis de execução que
combinam um conjunto de recursos dinâmicos comuns a todos os tipos de
serviços, como a qualidade do enlace sem fio, carga de CPU, espaço de
armazenamento em disco, memória e energia disponíveis. A combinação da
disponibilidade desses recursos, para determinar o potencial do dispositivo em
prover o serviço, é diferenciada, para cada família de aplicações, em função dos
níveis de prioridade entre eles. Em uma grade móvel, caracterizada como um
ambiente distribuído de execução de tarefas, existe a necessidade real, em se
tratando de serviços não específicos, de se obter, em resposta a uma requisição de
serviço, a indicação de mais de um provedor, o que não é contemplado pela
abordagem proposta no FTA. O que se justifica por essa proposta não ter sido
desenvolvida para se adequar às características de um ambiente de grade, mas sim
à descoberta de serviços específicos em MANETs.
Pelo que foi discutido, é possível afirmar que dentre os protocolos
apresentados, o P2PDP é o que melhor atende às necessidades de uma grade
móvel ad hoc. Isso se deve ao fato do P2PDP ter sido especificado levando em

O Protocolo P2PDP 134
consideração os requisitos necessários a um protocolo de descoberta desenvolvido
para esse ambiente particular, os quais são descritos na Seção 1.2.

5
Implementação
Este capítulo é dedicado a apresentar a implementação da arquitetura MoGrid e,
mais especificamente, do protocolo P2PDP, trazendo as suposições adotadas para
o seu desenvolvimento, as decisões de projeto quanto às tecnologias utilizadas,
além dos cenários de uso que constituem o protocolo de descoberta e seleção de
recursos e serviços. Esses cenários de uso são representados por alguns diagramas
de seqüência, com o intuito de facilitar a compreensão do comportamento das
entidades envolvidas no processo de descoberta e seleção de recursos e serviços.
Além disso, são apresentados os detalhes da integração do middleware MoGrid
com uma grade fixa através do Globus Toolkit [Foster & Kesselman 1997]. Este
capítulo traz também maiores detalhes sobre a utilização do protocolo P2PDP e da
API fornecida pela arquitetura MoGrid, através do desenvolvimento de aplicações
colaborativas diversificadas e do teste de correção da implementação do protocolo
utilizando o simulador NCTUns [Wang & Lin 2005].
5.1.
Tecnologias Utilizadas
A implementação foi desenvolvida na linguagem Java da SUN [Sun 1994], sendo
adotado o perfil CDC (Connected Device Configuration) do J2ME [Sun 1999b]
como plataforma de referência para a implementação. Uma versão simplificada da
implementação também foi desenvolvida adotando o perfil CLDC/MIDP
(Connected Limited Device Configuration/Mobile Information Device Profile).
Nessa versão, foram implementadas somente as entidades iniciador e coordenador
do protocolo P2PDP, devido às restrições do perfil CLDC/MIDP no que se refere
ao controle de execução de tarefas, mecanismos de temporização e ao
monitoramento de recursos, que são essenciais para a entidade colaborador. As
entidades de descoberta – iniciador, coordenador e colaborador – foram
explicadas em detalhes na Subseção 2.3.1.2 e na Seção 4.5. A linguagem Java foi

Implementação 136
escolhida por ser uma linguagem multiplataforma e oferecer recursos de
programação para dispositivos móveis.
O serviço monitor (Subseção 2.3.1.2), utilizado nas versões desenvolvidas
para Windows XP e Linux, corresponde à implementação disponível na
arquitetura MoCA (Mobile Collaboration Architecture) [Sacramento et al. 2004].
Esse serviço foi desenvolvido como um daemon executando em cada dispositivo
móvel, responsável por coletar informações de estado, tais como a qualidade do
enlace sem fio, nível de energia, uso de CPU e memória disponível. Essas
informações são processadas pelo gerente de contexto (Subseção 2.3.1.2), que
alimenta o colaborador, informando-o, quando solicitado, sobre a disponibilidade
de recursos do dispositivo. Essa informação será utilizada pelo algoritmo DR
(Seção 4.7) para o cálculo do retardo de envio de mensagens de resposta. A
utilização dessa implementação do monitor deve-se ao fato dos estudos iniciais
que conduziram a este trabalho terem sido desenvolvidos durante o processo de
especificação da arquitetura MoCA.
Para que os dispositivos portáteis possam atuar como uma interface de
acesso à grade fixa, utilizando os serviços e recursos que ela disponibiliza, foi
necessária a definição de uma nova entidade na arquitetura MoGrid, capaz de
fazer a tradução do protocolo P2PDP para os protocolos usados em grades fixas.
Essa entidade, denominada proxy de colaboração, atua como um intermediador na
descoberta e seleção de recursos e submissão de tarefas em uma grade fixa,
através dos dispositivos provenientes de uma grade móvel, como ilustrado na
Figura 26. O conceito do proxy de colaboração é genérico na arquitetura MoGrid,
podendo ser especializado para tecnologias de grade fixa particulares. A
implementação do proxy de colaboração desenvolvida nesta tese é responsável
pela integração do MoGrid com o Globus [Foster & Kesselman 1997] – um
toolkit de software para construção de grades fixas. O proxy deve ser um
dispositivo presente, simultaneamente, na grade móvel e na grade fixa; qualquer
dispositivo que hospede o software cliente do Globus e o middleware MoGrid é
passível de se tornar um proxy de colaboração. A escolha do Globus Toolkit deve-

Implementação 137
se ao fato da grade fixa do projeto ComCiDis 1 , na qual foram realizados os
experimentos com o proxy de colaboração, ter sido implantada utilizando essa
tecnologia.
Figura 26 – O proxy de colaboração MoGrid.
5.2.
Implementação do Protocolo P2PDP
As próximas subseções trazem detalhes sobre a implementação do protocolo de
descoberta P2P. Foi adotado o paradigma de orientação a objetos tanto na
modelagem quanto na implementação. As principais classes do protocolo, bem
como o relacionamento entre elas, são apresentados através de diagramas de
classe e de seqüência UML (Unified Modeling Language) [OMG 2005], com o
intuito de facilitar a compreensão do comportamento das entidades envolvidas no
processo de descoberta e seleção de serviços. Nos diagramas de classe, foi
utilizada uma grafia diferenciada para representar as classes abstratas (itálico) e as
concretas (regular). Além disso, classes que implementam interfaces têm essas
interfaces identificadas pelo estereótipo “”.
1 A página do projeto ComCiDis está disponível em . Acesso em: 15
mai. 2007.

Implementação 138
5.2.1.
Descrição de Recursos e Controle de Admissão
A Figura 27 ilustra as classes responsáveis pela descrição dos recursos e pelo
controle de admissão do protocolo.
Figura 27 – Descrição de recursos e controle de admissão.
Cada recurso disponível na grade é representado por uma instância da classe
ResourceDescriptor e é registrado, pelo dispositivo que o disponibiliza, através do
método put() da classe ResourceRegistry. Ao ser registrado, o recurso é
associado a um identificador único universal, representado pela classe
ResourceIdentifier. Ao receber uma requisição de serviço, o colaborador consulta
o mecanismo de controle de admissão para verificar se o serviço solicitado é
oferecido pelo dispositivo; esse procedimento é efetuado através do método
admit() da classe AdmissionController.
5.2.2.
Mensagens de Controle P2PDP
As mensagens de controle do protocolo de descoberta P2PDP, descritas na Seção
4.5, são representadas como subclasses da classe abstrata P2PDPMessageImpl,
como ilustrado na Figura 28. A manipulação de qualquer campo presente nessas

Implementação 139
mensagens pelas entidades do protocolo ocorre por intermédio desse conjunto de
classes. A classe P2PDPMessageImpl implementa os métodos que manipulam
campos comuns a todas as mensagens de controle P2PDP – IReq, CRep e
CRepList. Esses métodos são definidos na interface .
Figura 28 – Declaração das mensagens de controle P2PDP.
5.2.3.
Canal de Comunicação P2PDP
As mensagens do protocolo P2PDP trafegam na MANET utilizando canais de
comunicação criados a partir da classe P2PDPConnectionFactory, como ilustrado
na Figura 29. Na implementação do protocolo P2PDP para redes sem fio ad hoc,
apenas um canal de comunicação broadcast é criado, o qual é representado por
uma instância da classe P2PDPBroadcastConnection. Isso se deve ao fato de que,
nesse tipo de rede, as entidades iniciador e coordenador são implementadas no
mesmo dispositivo, comunicando-se diretamente, através de chamadas a métodos
das classes Initiator e Coordinator, ilustradas na Figura 30, sem a necessidade de
criação de um canal de comunicação específico entre elas (classe
P2PDPUnicastConnection). Em uma implementação do P2PDP para uma rede
sem fio infra-estruturada, o coordenador pode ser implementado na estação base,
que é o dispositivo mais rico em recursos da rede sem fio, podendo atuar como
coordenador para todos os iniciadores da grade móvel. Nesse caso, a comunicação

Implementação 140
entre iniciador e coordenador é feita através de um canal de comunicação unicast
(classe P2PDPUnicastConnection); a comunicação entre coordenador e
colaboradores utiliza, assim como nas redes sem fio ad hoc, o canal de
comunicação broadcast.
Figura 29 – Canal de comunicação P2PDP.
As classes P2PDPUnicastConnection e P2PDPBroadcastConnection são
representadas na Figura 30 como subclasses da classe abstrata
P2PDPConnectionImpl que implementa a interface .
Essas classes oferecem às entidades do protocolo P2PDP os mecanismos para
acesso ao canal de comunicação oferecido pela plataforma de hardware ou
software – no caso, o sistema operacional do dispositivo sem fio.
5.2.4.
Entidades de Descoberta P2PDP
A Figura 30 ilustra as classes que representam as entidades de descoberta –
iniciador (classe Initiator) e coordenador (classe Coordinator) – e a interface que
representa as operações fornecidas pelas subcamadas de adaptação (ASLs) da
camada de transparência (interface ), que foram descritas
na Subseção 2.3.2.3. Uma aplicação MoGrid inicia o processo de descoberta
acionando o método submitRequest() de uma classe que implementa
. Essa aplicação desenvolvida deve implementar a
interface , que define o método
receiveReplyList() para recepção dos resultados do processo de descoberta.

Implementação 141
Figura 30 – Entidades iniciador e coordenador e a subcamada de adaptação.
A Figura 30 ilustra também uma implementação default de ASL (classe
AdaptationSublayerImpl). Aplicações que apresentem características específicas
podem demandar o desenvolvimento de ASLs também específicas; isso é
conseguido por meio de classes que implementam a interface
. Um exemplo que ilustra a necessidade do
desenvolvimento de ASLs específicas é a implementação do método
selectReplies(). Apesar do protocolo P2PDP implementar a seleção das
melhores respostas ao longo da rede (Seções 4.6 e 4.7), em algumas situações o
coordenador pode receber mais respostas do que as que foram solicitadas pelo
iniciador. Para atender a esses casos, o método selectReplies() é responsável
por efetuar a seleção de respostas, mantendo o processo de seleção automático,
sem a necessidade de intervenção direta do cliente da aplicação. No caso da classe
default AdaptationSublayerImpl, esse método devolve simplesmente as primeiras
respostas que chegam ao coordenador. Outras aplicações podem implementar
outras estratégias de seleção nesse método por intermédio de classes específicas
que implementam , conforme discutido ao final da
Subseção 2.3.1.2.
A Figura 31 traz as classes que representam a entidade colaborador (classe
Collaborator), o mecanismo de controle de admissão (classe
AdmissionController) e os serviços responsáveis pelo monitoramento das

Implementação 142
informações dos recursos do dispositivo (classe MoCAMonitor) e pela inferência
do seu nível de colaboração (classe ContextListener).
Figura 31 – Entidade colaborador.
Ao processar uma requisição de serviço, através do método
handlerIReqMessage(), o colaborador primeiro verifica se a requisição já foi
tratada por ele (isIReqMessageDuplicate()), descartando-a em caso afirmativo.
Caso contrário, o colaborador consulta o atributo willingness, para definir se
está disposto (0 < willingness ≤ 1) ou não (willingness = 0) a colaborar. Se o
dispositivo está atuando no modo de colaboração ativa, ele então verifica se
oferece o serviço solicitado, através do método admit(), da classe
AdmissionController. No modo de colaboração ativa, o dispositivo não somente
auxilia no encaminhamento das mensagens P2PDP – o que caracteriza o modo
passivo – como também disponibiliza os seus recursos para os demais na rede. Se
o colaborador possui o serviço em questão, ele então gera uma mensagem de
resposta (CRep) e escalona o seu envio através do método sendCRepMessage(). O
algoritmo DR, implementado através da classe CollaborationReplyDelay-
Function, é acionado para calcular o instante de tempo (getReplyDelay()) em
que a resposta do colaborador será enviada, bem como coletar a informação sobre
o perfil de execução do dispositivo (getExecutionProfile()). Essa informação
é transmitida na mensagem CRep, podendo ser usada pela ASL da aplicação que

Implementação 143
requisitou o serviço como critério de seleção das melhores respostas, quando essas
ultrapassam o número solicitado. Logo após o envio da sua resposta, o
colaborador aciona o método waitCRepAcknowledgment() e fica aguardando
pelo reconhecimento implícito de que a sua mensagem foi encaminhada, na rede,
em direção ao nó que requisitou o serviço (pseudocódigo da Figura 25). Se o
reconhecimento não for recebido (handlerDuplicateCRep()) dentro de um
intervalo de tempo específico, então o colaborador reenvia a sua resposta, dessa
vez, tendo como próximo salto no caminho de retorno todos os seus vizinhos
diretos, o que é definido pela utilização do endereço de broadcast, conforme é
descrito na Seção 4.8.
É importante mencionar que o valor do atributo willingness (ω), definido
na Equação (2) apresentada no Capítulo 4, foi calculado como ω
usr
2L, onde ω usr
representa o nível de interesse (no intervalo [0, 1]) do usuário em permitir que o
seu dispositivo colabore com os outros na MANET e L representa o número de
requisições que foram respondidas pelo dispositivo. Desta forma, implementou-se
um mecanismo de adaptação simples, que oferece uma reserva antecipada de
recursos na medida em que reduz o indicador da disposição do dispositivo em
colaborar (willingness) quando o número de requisições pendentes aumenta. A
adaptação do valor de ω tem como objetivo não apenas oferecer níveis mínimos
de garantia de que o recurso requisitado esteja disponível quando a execução da
tarefa for iniciada, como também preservar o dispositivo colaborador, evitando
que ele fique sobrecarregado por atender mais requisições do que a sua
capacidade permite. O ajuste desse parâmetro facilita o controle de admissão pois
se ω atinge o seu valor mínimo (ω = 0), o colaborador passa a não responder às
requisições da grade, mesmo que ele ofereça os serviços solicitados. Caso esse
parâmetro seja mantido no seu valor máximo (ω = 1) durante a participação do
dispositivo na grade móvel, mesmo assim o cálculo do retardo no envio das
mensagens garante que o temporizador τ seja configurado para um valor elevado,
próximo ao limite definido pelo iniciador da requisição (maxRepDelay), fazendo
com que a sua resposta seja preterida, sendo retirada da rede pelo mecanismo de
supressão (Seção 4.8).

Implementação 144
5.2.5.
Cenários de Uso
Esta subseção ilustra os aspectos dinâmicos da colaboração entre as entidades de
descoberta e os serviços de monitoração, através da utilização de diagramas de
seqüência.
A seqüência de invocação de métodos referente à descoberta de serviços, no
P2PDP, é ilustrada pelo diagrama apresentado na Figura 32.
Figura 32 – Seqüência de invocação de operações associadas à descoberta de serviço.
A seqüência de invocação de métodos referente ao tratamento de uma
requisição de serviço pela entidade colaborador (classe Collaborator), no P2PDP,
é ilustrada pelo diagrama apresentado na Figura 33.
Figura 33 – Seqüência de invocação de operações associadas à recepção de uma
requisição de serviço no colaborador.

Implementação 145
5.3.
Integração do MoGrid com o Globus Toolkit
Um desafio no desenvolvimento de aplicações para grades móveis é a
possibilidade de integração com grades fixas convencionais. Embora grades
móveis possam, a princípio, ser pensadas como agrupamentos isolados de
processamento, a aproximação de uma grade móvel a um ponto de acesso para
uma rede fixa pode expandir, consideravelmente, a capacidade computacional da
grade móvel. Nesta seção, os serviços que compõem o Globus Toolkit são
brevemente apresentados, assim como as adaptações que se fizeram necessárias na
arquitetura MoGrid, especialmente, na camada de descoberta, para que os
dispositivos que constituem a grade móvel pudessem ter acesso aos recursos da
grade fixa Globus de uma forma transparente. Nessa direção, são discutidos
aspectos como a implementação do monitoramento dos recursos e do mecanismo
de controle de admissão da grade fixa.
5.3.1.
O Globus Toolkit
O Globus Toolkit (GTK) é um conjunto de ferramentas usado na criação de
sistemas e aplicações em grades. O GTK permite que problemas
computacionalmente complexos sejam executados rapidamente, dividindo-os em
partes e os submetendo, sob a forma de tarefas (processos), às máquinas da grade,
de acordo com os recursos disponíveis nas mesmas e com as necessidades
específicas do problema. Cada tarefa deve ser instanciada na máquina remota em
que for executada; para isso, um programa executável (ou script) que implemente
a tarefa pode ter que ser previamente copiado para a máquina remota. O Globus
oferece mecanismos para efetuar a transferência de arquivos entre as máquinas
que constituem a grade.
Para prover essas funcionalidades, o Globus Toolkit oferece vários serviços:
• Grid Security Infrastructure (GSI). Provê segurança e permite um login
único de usuário em toda a grade. Dessa forma, um usuário não precisa
efetuar login em cada máquina usada no processamento de suas tarefas,
mas utiliza uma única credencial, que fornece o acesso temporário a todas
as máquinas usadas na grade;

Implementação 146
• Globus Resource Allocation Manager (GRAM). Provê mecanismos de
alocação de recursos e de criação e monitoração de tarefas, informando o
andamento das tarefas durante o seu tempo de execução;
• Grid File Transfer Protocol (GridFTP). Responsável pela transferência
de arquivos (por exemplo, para cópia de executáveis) entre as máquinas da
grade, por meio do protocolo FTP;
• Monitoring and Discovery Service (MDS). Provê uma área de acesso
público que disponibiliza informações sobre a grade. O MDS provê dois
tipos de serviço:
o Grid Resource Information Service (GRIS). Presente localmente em
cada máquina da grade; envia informações sobre a máquina (sistema
operacional, CPU livre, memória disponível, etc.) para uma determinada
máquina na grade, que hospeda o GIIS;
o Grid Index Information Service (GIIS). Recebe as informações,
enviadas pelos GRIS, que estão localmente em cada máquina da grade.
Desta forma, o GIIS é capaz de consolidar informações sobre a grade
como um todo, oferecendo, às máquinas que têm acesso ao GIIS,
informações específicas sobre um recurso qualquer.
O GTK disponibiliza o CoG Kit [CoG 1997], implementado em várias
linguagens, como Python e Java, para oferecer facilidades no desenvolvimento de
aplicações para a grade Globus. Essa API permite que programadores
implementem aplicações que possam ter acesso a serviços Globus, tais como
submissão de tarefas (GSI, GRAM), transferência de arquivos (GridFTP) e
descoberta de recursos (MDS). A implementação Java dessa API foi utilizada na
implementação da integração da grade Globus à arquitetura MoGrid.
5.3.2.
Requisições de Descoberta P2PDP em uma Grade Globus
Quando um usuário MoGrid requisita, no dispositivo móvel, a descoberta de
recursos ou a submissão de uma tarefa, e essa requisição é recebida pelo proxy de
colaboração, este se autentica na grade Globus apresentando um certificado de
usuário e obtendo uma credencial temporária, válida enquanto durar a sessão. Não

Implementação 147
é necessário que um usuário MoGrid possua esse certificado, porém é necessário
que o proxy autentique um usuário Globus junto ao serviço GSI, ou seja, o usuário
MoGrid personifica um usuário Globus através do proxy. Logo, qualquer máquina
com acesso à grade Globus, e que tenha o MoGrid instalado, está apta a atuar
como um proxy para a submissão de tarefas da grade móvel para a grade fixa. 2
Ao receber uma requisição P2PDP, o proxy só enviará, ao usuário MoGrid
requisitante, informações sobre os recursos dos nós da grade Globus em que puder
se autenticar para a submissão de tarefas. O proxy envia ao cliente MoGrid
exatamente o número de respostas solicitadas na requisição, encarregando-se de
selecionar previamente os melhores colaboradores dentre as máquinas na grade
fixa aptas a atender a requisição. O proxy torna transparente para o usuário
MoGrid a existência de uma grade fixa e os nós da grade Globus são vistos como
nós MoGrid alcançáveis através do proxy. Já na execução de uma tarefa, o proxy
recebe, do usuário MoGrid requisitante, o nome do arquivo executável, seus
argumentos, os arquivos que devem ser copiados para a execução e o endereço do
“nó MoGrid” (na realidade, um nó na grade Globus) em que a tarefa será
executada. O proxy é responsável também pela gerência do ciclo de vida dos
arquivos que devem estar na máquina remota no momento da execução, ou seja, o
proxy deve copiá-los antes que a execução da tarefa tenha início e removê-los
logo após a sua conclusão.
Para possibilitar a comunicação entre os dispositivos MoGrid e Globus, foi
necessário acrescentar um campo à mensagem de resposta CRep do P2PDP. Esse
novo campo, denominado proxyID, fornece o identificador do dispositivo que
atua como proxy entre as duas grades. Para nós que não atuam como proxies,
proxyID = 0. Dessa forma, o processo de submissão de tarefas obedece a mesma
lógica tanto na grade móvel quanto na grade fixa. A Figura 34 traz a representação
da mensagem CRep modificada.
2 Deve-se ressaltar que as questões relacionadas ao mapeamento do usuário Globus para usuários
MoGrid não são consideradas nesta tese. Essas questões dizem respeito aos mecanismos de
segurança, que de uma forma global não são tratados nesta tese.

Implementação 148
Figura 34 – Mensagem CollaboratorReply (CRep) modificada.
5.3.3.
Monitoramento de Recursos em uma Grade Globus
Para que se possa implementar o mecanismo de seleção dos dispositivos mais
aptos a executar as tarefas da grade através do mecanismo de retardo no envio das
mensagens de resposta, é necessário realizar o monitoramento das informações de
contexto dos dispositivos na grade fixa, para que se possa efetuar o cálculo do
temporizador replyDelay (vide Equação (2) na Seção 4.7).
Para a escolha das máquinas responsáveis pela execução das tarefas na
grade fixa – considerando-se que a qualidade do enlace sem fio e o nível de
energia são constantes –, os recursos levados em consideração, na especificação
do perfil de execução, foram CPU, memória e espaço em disco. O monitoramento
desses recursos no GTK é feito através do MDS. Como o monitor MoCA,
utilizado no middleware MoGrid, passa as informações sobre os recursos de uma
forma diferente da utilizada no MDS, foi necessário desenvolver uma interface
padrão para a descoberta de recursos que homogeneizasse essas informações,
permitindo, assim, a integração dos mecanismos de monitoramento de recursos
entre a grade móvel e a grade fixa.
Diferentemente do monitor MoCA utilizado no MoGrid, que é executado
como um daemon em cada dispositivo móvel, o monitor do Globus foi
implementado, no middleware MoGrid, como um cliente do MDS que recebe
informações sobre os recursos de todas as máquinas da grade fixa. No monitor do
Globus (classe GlobusMonitor), essas informações são tratadas, sendo separadas
pela identificação da máquina e enviadas, uma a uma, ao proxy MoGrid que
solicitou a informação, mantendo a interface padrão de monitoramento de
recursos MoGrid.

Implementação 149
5.3.4.
Controle de Admissão em uma Grade Globus
O MDS trata apenas informações sobre os recursos físicos das máquinas, porém
algumas aplicações podem exigir recursos lógicos, como programas e scripts
desenvolvidos em uma linguagem específica, que precisem localizar o seu
ambiente de execução. Isso acontece, por exemplo, com aplicações Java que
precisam de uma máquina virtual para serem executadas. Na API de descoberta
MoGrid, existem operações para registro e remoção de serviços (operações
register() e deregister()). O registro é feito de forma distribuída, com cada
dispositivo na grade móvel se responsabilizando por gerenciar as informações
sobre os serviços que disponibiliza. Como as máquinas, na grade fixa, não têm
conhecimento do middleware MoGrid, não existe um mecanismo de registro das
informações de serviços que cada máquina disponibiliza. Ao receber uma
requisição de descoberta, antes de verificar quais máquinas da grade fixa atendem
ao perfil de execução do serviço requisitado, o proxy precisa determinar quais
máquinas, da grade fixa, disponibilizam o serviço. Esse procedimento
corresponde às ações de um controle de admissão, que é responsável por
determinar a existência dos recursos solicitados – como softwares instalados nas
máquinas da grade fixa – aos quais o proxy tem acesso. Como o GTK só oferece
suporte à execução de tarefas em máquinas executando sistemas operacionais da
família UNIX, a solução para determinar se um dado serviço existe na grade fixa
foi utilizar shell scripts. Cada serviço é associado a um determinado script, com
uma lógica específica, para verificar a sua existência. Caso o serviço seja
encontrado, esse script deve retornar a sua localização exata na máquina remota;
caso contrário, o resultado é vazio.
Para otimizar o mecanismo de controle de admissão ao inicializar o proxy, o
seu administrador pode cadastrar scripts para localizar os serviços mais
freqüentemente requisitados. Esses scripts podem ser executados de forma reativa
ou proativa; independentemente da abordagem adotada, o resultado obtido é
cadastrado, no proxy, através da operação register() da API de descoberta
MoGrid, da mesma forma como é feito nos dispositivos da grade móvel. Na
abordagem reativa, cada vez que o proxy recebe uma requisição, ele executa o
script correspondente ao serviço solicitado nas máquinas da grade fixa – caso

Implementação 150
exista algum script associado ao serviço. Na abordagem proativa, o proxy executa
os scripts cadastrados periodicamente nas máquinas da grade fixa. Na
implementação do ProxyCollaborator, a abordagem adotada foi a proativa.
5.3.5.
Implementação do Proxy de Colaboração
Nesta seção, são apresentadas as extensões que se fizeram necessárias na entidade
colaborador para que o proxy de colaboração pudesse ser implementado.
A Figura 35 traz as classes associadas ao proxy de colaboração; o
relacionamento entre essas classes é similar ao que foi apresentado na Figura 31.
As alterações introduzidas no proxy de colaboração (classe ProxyCollaborator),
em relação ao colaborador, dizem respeito à autenticação do dispositivo na grade
fixa Globus e ao acesso aos serviços de monitoramento oferecidos pelo GTK.
Ao ser instanciado, o proxy de colaboração se autentica na grade Globus
através do método sign() da classe ProxyInit, que, por sua vez, ativa a criação do
monitor do Globus (classe GlobusMonitor) através do método
createGlobusMonitor() da classe GridAuthentication. O processamento de
requisições de serviços e das respostas a essas requisições é efetuado de forma
similar ao que foi descrito para o colaborador. A diferença é que, ao tratar uma
requisição, o proxy gera tantas respostas quantas forem as máquinas disponíveis,
na grade fixa, para atendê-las, conforme descrito na Subseção 5.3.2.

Implementação 151
Figura 35 – Entidade proxy de colaboração.
A seqüência de invocação de métodos referente ao tratamento de uma
requisição de serviço pelo proxy de colaboração no P2PDP é ilustrada na
Figura 36.
Figura 36 – Seqüência de invocação de operações associadas à recepção de uma
requisição de serviço no proxy de colaboração.

Implementação 152
5.4.
Aplicações de Teste
Esta seção ilustra a utilização do protocolo P2PDP e da API de descoberta da
arquitetura MoGrid por meio de um conjunto de aplicações colaborativas.
Primeiramente, é apresentada uma aplicação P2P de compartilhamento de
arquivos de áudio. A seguir, são apresentadas duas aplicações de processamento
distribuído: uma aplicação de multiplicação de matrizes e uma outra que gerencia
a execução de simulações paralelas do simulador ns-2 [ISI 1995].
A aplicação que gerencia o compartilhamento de arquivos de áudio,
denominada ASA (Audio Sharing Application), foi inspirada em aplicações como
Gnutella [Gnutella 2005] e Napster [Napster 2005]. O perfil de execução dessa
aplicação é definido por uma subcamada de adaptação (ASL) desenvolvida
especificamente para a família de aplicações de transferência de arquivos. Para
essas aplicações, é importante balancear a qualidade do enlace sem fio e o tempo
de autonomia da bateria do colaborador selecionado para prover o serviço
requisitado. Portanto, para essa aplicação, o perfil de execução foi definido
levando-se em consideração os recursos energia e a qualidade do enlace sem fio.
Na implementação da ASL, optou-se por considerar os dois recursos com pesos
iguais. Assim, os parâmetros da Equação (2) foram configurados como: N = 2 e
P energia = P qualidade do enlace = 1. Nos testes realizados, foi utilizado o valor default de
S (vide Seção 4.6), ou seja, S = 10 ms.
A segunda aplicação desenvolvida utilizando o protocolo P2PDP,
denominada M3 (Matrix-Matrix Multiplication), usa uma abordagem mestreescravo
para multiplicação distribuída de matrizes. O objetivo dessa aplicação,
desenvolvida como um “toy problem”, 3
foi ilustrar a utilização de recursos
tipicamente disponíveis em uma grade fixa por dispositivos portáteis em uma
grade móvel. Nessa aplicação foi utilizado um algoritmo de multiplicação
distribuída bastante simples: dadas duas matrizes, A mxn e B nxp , um nó-mestre
(iniciador) calcula C mxp = AB selecionando m nós-escravos (colaboradores) e
3 Termo comumente empregado na literatura especializada para designar a criação de uma versão
simplificada de um problema complexo, usado para demonstrar um conceito através da
investigação ou teste de algoritmos relacionados a um problema real.

Implementação 153
enviando, para cada escravo i (1 ≤ i ≤ m), uma cópia da matriz B com a matrizlinha
i
A 1 xn
, cujos elementos correspondem à i-ésima linha de A. Cada escravo i
calcula a matriz-linha
i i
c1 x p
= a1
xnB
e a retorna para o nó-mestre. Ao receber o
resultado, o nó-mestre alimenta, então, cada i-ésima linha de C com a matriz-linha
i
c 1
obtida. A seleção dos nós-escravos, na MANET, é feita através do protocolo
x p
P2PDP, levando-se em consideração os nós que possuem a maior quantidade
disponível dos recursos CPU e memória. Esses recursos constituem o perfil de
execução da aplicação M3. A ASL utilizada por essa aplicação foi desenvolvida
para a família de aplicações de processamento intensivo. Para essas aplicações,
variações na qualidade do enlace sem fio não influenciam a escolha dos
colaboradores para a ASL – dado que a transferência de informações entre
iniciadores e colaboradores é mínima e discreta. No caso específico da aplicação
M3, por ser um toy problem, o tempo médio de execução de cada tarefa –
considerando-se matrizes com tamanho máximo 20x20 – ficou em torno de 1 ms,
motivo pelo qual o tempo de autonomia da bateria do dispositivo foi
desconsiderado na seleção de colaboradores. Assim, na implementação da
aplicação M3 os parâmetros da Equação (2) foram configurados como: N = 2,
P CPU = P memória = 1 e S = 100 ms. O valor de S foi definido empiricamente, com
base nos resultados obtidos nos testes realizados com a variação desse parâmetro.
Nesse ponto é importante ressaltar que as aplicações ASA e M3 foram
desenvolvidas única e exclusivamente para avaliar a correção da implementação
do protocolo P2PDP e do middleware MoGrid, auxiliando na realização de testes
que resultaram em refinamentos sucessivos dessas implementações. As aplicações
ASA e M3 não foram especificadas para atender as necessidades de cenários
realistas ou visando uma utilidade mais ampla.
A terceira aplicação desenvolvida foi uma ferramenta que inicia, gerencia e
pós-processa um conjunto de simulações paralelas do simulador ns-2. O pósprocessamento
trata os dados coletados, nas simulações, para obtenção dos
resultados em função de critérios de análise pré-definidos. A ferramenta,
denominada nsTOOL (ns dispaTcher and pOst-prOcessing Launcher), oferece
uma interface gráfica e uma interface textual para facilitar a automatização do
processo de submissão de múltiplos cenários de simulação para os dispositivos da

Implementação 154
grade móvel aptos a colaborar. Isso inclui o proxy MoGrid, o que possibilita o
envio dos scripts de simulação para as máquinas de uma grade fixa Globus
qualquer. Como a aplicação nsTOOL pertence à mesma família da aplicação M3 –
família de aplicações de processamento intensivo –, foi utilizada a mesma ASL.
Entretanto, na aplicação nsTOOL – caracterizada como uma aplicação de longa
duração –, o tempo de execução de cada tarefa é considerável, pois cada
colaborador é responsável por um dado conjunto de simulações. Nesse caso, o
tempo de autonomia da bateria do dispositivo é essencial na seleção dos
colaboradores na grade móvel que irão gerenciar as rodadas de simulação e
executar o pós-processamento de seus resultados. Na implementação da aplicação
nsTOOL, os parâmetros da Equação (2) foram configurados como: N = 3,
P energia = 3, P CPU = 2 e P memória = 1. Nos testes realizados, foi utilizado o valor
default de S (vide Seção 4.6), ou seja, S = 10 ms.
5.4.1.
Ambientes de Teste Reais
As três aplicações descritas neste capítulo foram executadas inicialmente em três
cenários de teste reais distintos, descritos a seguir.
Primeiramente, cada uma das três aplicações foi executada na rede do
laboratório MARTIN 4
(Mechanisms and ARchitectures for TeleINformatics),
constituída por cinco máquinas Linux e uma máquina Windows, todas
interligadas por uma rede Ethernet. Para emular o funcionamento em uma rede
sem fio, foi instalado em todas as máquinas um módulo de emulação do
Monitor/Sim MoCA, o que permitiu reproduzir variações das informações de
contexto referentes a qualidade do enlace sem fio, além de emular a variação dos
níveis de energia disponíveis através de uma função linear decrescente. A
qualidade do enlace sem fio foi medida em função da intensidade do sinal de rádio
(Radio Signal Strength Indications – RSSI), configurado no intervalo [-20 dBm, -
85 dBm], com os valores limites representando, respectivamente, o melhor e o
pior nível de intensidade do sinal. As informações de contexto referentes a CPU,
4 A página do projeto está disponível em . Acesso em: 10 fev. 2007.

Implementação 155
memória e espaço em disco foram obtidas pelo módulo de execução real do
monitor MoCA em cada máquina.
Posteriormente, a aplicação M3 foi executada em uma rede sem fio de testes
implementada no projeto ARES 5 (Architectures de RésEaux de Services) do
INRIA/INSA-Lyon. Essa rede é constituída por quatro laptops e quatro mini-PCs
(shuttles) executando Linux, sendo configurada em modo ad hoc.
Por fim, as aplicações M3 e nsTOOL foram executadas novamente na rede
do projeto MARTIN, dessa vez para verificar o funcionamento do proxy de
colaboração. Para isso, uma das máquinas dessa rede foi registrada também como
parte integrante do projeto InteGridade [Integridade 2003] que oferece uma grade
baseada no Globus versão 2.4.
Em todos os cenários supracitados, os mecanismos de descoberta e seleção
do protocolo P2PDP apresentaram o comportamento esperado, retornando como
resultado o número de respostas solicitadas na requisição, com a seleção das
respostas de melhor qualidade e a supressão das respostas desnecessárias. Pela
observação do arquivo de trace do protocolo P2PDP, que registra o envio e
recepção de requisições e respostas, incluindo a ocorrência de supressões, foi
possível rastrear o encaminhamento dessas mensagens e verificar a distribuição da
ocorrência de supressões entre os nós que compunham o caminho de retorno das
mensagens de resposta. Através da comparação do perfil de execução de todos os
dispositivos respondentes, foi possível observar que os colaboradores que tiveram
as suas respostas selecionadas para cada requisição foram os que apresentaram a
maior disponibilidade dos recursos indicados no perfil da requisição. Monitorando
um bom número dessas execuções com o comando top – presente no sistema
operacional Linux – e o gerenciador de tarefas (taskmgr) – presente no sistema
operacional Windows –, foi possível observar a variação na disponibilidade de
recursos dos dispositivos em função do processamento das requisições de
descoberta e verificar a correção dos valores de retardo de envio gerados pelos
colaboradores. Entretanto, é importante ressaltar que os experimentos realizados
5 Os testes foram realizados em cooperação com os pesquisadores Guillaume Chelius e Nicolas
Bolicaut. A página do projeto está disponível em . Acesso
em: 10 fev. 2007.

Implementação 156
têm um caráter inicial, dada a simplicidade das aplicações implementadas, não
sendo possível obter resultados conclusivos que apresentem uma validade mais
geral sobre o desempenho do P2PDP, o que é feito no Capítulo 6.
5.4.2.
Ambiente de Teste Simulado
É importante ressaltar que os experimentos realizados nos cenários descritos na
seção anterior têm um caráter de prova de conceito somente, dada a simplicidade
das aplicações implementadas e dos ambientes de teste disponíveis. Para
possibilitar testes da implementação do middleware MoGrid e do protocolo
P2PDP em cenários mais complexos, foram realizadas rodadas de execução
simulada da aplicação M3 no simulador NCTUns [Wang & Lin 2005]. Esse
simulador permite a configuração de vários dispositivos virtuais em uma mesma
máquina. Cada um desses dispositivos virtuais pode executar uma instância real
da implementação, conferindo assim um ambiente de simulação muito similar a
de um ambiente real de testes. Nos testes realizados sobre o NCTUns, os
dispositivos virtuais foram organizados como uma rede sem fio ad hoc de saltos
múltiplos. Os testes sobre o simulador NCTUns foram executados em duas etapas.
Na primeira etapa, os parâmetros relacionados à mobilidade foram
desconsiderados. Em uma segunda etapa, a mobilidade dos dispositivos foi
considerada.
Para ser possível a execução dos testes sobre o NCTUns, foi necessário
adaptar o serviço monitor de modo a atender algumas características do ambiente
de simulação. Como uma única máquina executando o NCTUns é usada para
simular vários dispositivos em uma MANET, o uso do serviço monitor original
incorreria em um cenário irreal, com todos os dispositivos na rede sem fio
apresentando as mesmas informações de estado. Para solucionar esse problema,
foi implementado um serviço monitor modificado que, a partir das informações de
estado reais – obtidas através do serviço monitor –, retorna valores aleatórios
diferenciados para cada nó que compõe o cenário sem fio simulado.
A Tabela 4 apresenta os valores dos parâmetros usados na constituição das
rodadas de simulação do cenário que não contempla a mobilidade dos

Implementação 157
dispositivos. Foi considerado para esse cenário uma densidade fixa de dispositivos
na MANET, usando topologias em grade. A escolha dos dispositivos que irão
atuar como colaboradores ativos é feita de forma aleatória a cada rodada pelo
script NCTUns que gera a topologia da rede, considerando o valor de p.
Tabela 4 – Parâmetros de simulação NCTUns sem contemplar mobilidade.
Parâmetro
Valores
Número de dispositivos (N) 16
Densidade de dispositivos por raio de transmissão
4 dispositivos
Distância média entre dispositivos
240 m
Alcance da transmissão
250 m
Percentual de dispositivos colaboradores ativos (p) 20%
Número máximo de respostas (R) 2
A Figura 37 ilustra o comportamento das entidades P2PDP no processo de
descoberta em uma rodada de simulação específica no NCTUns, para o cenário
determinado na Tabela 4, com os dispositivos sem fio dispostos regularmente em
grade.
(a) Encaminhamento da requisição
(b) Encaminhamento das respostas
Figura 37 – Exemplo de rodada de simulação do protocolo P2PDP.
Na Figura 37, o nó 7 atua como o iniciador do processo de descoberta, os
nós 12, 13 e 14 atuam no modo de colaboração ativa e os demais nós no modo
passivo, apenas encaminhando as mensagens de controle do P2PDP que lhes são
enviadas. Na Figura 37(a), o iniciador submete uma requisição de serviço
(mensagem IReq) à rede, com o número máximo de respostas configurado para

Implementação 158
dois (numMaxReplies = 2) e o tempo máximo de espera por respostas para dez
segundos (maxReplyDelay = 10). Ao receber uma requisição, os colaboradores
verificam duas condições: (i) se eles estão no modo de colaboração ativo
(0 < willingness ≤ 1), ou seja, se eles podem colaborar, e (ii) se eles oferecem o
serviço solicitado. Cada colaborador ativo calcula o retardo de envio da sua
mensagem de resposta (replyDelay), de forma independente e distribuída,
utilizando o algoritmo DR, e, a seguir, agenda o envio da sua resposta no instante
de tempo obtido. Os valores obtidos para os temporizadores replyDelay, nos
colaboradores 12, 13 e 14, foram, respectivamente, 1744 ms, 4087 ms e 8827 ms
na rodada ilustrada na figura. As respostas são encaminhadas salto-a-salto em
broadcast local direcionado, ou seja, todos os vizinhos diretos de um nó que tenha
emitido uma resposta escutam a mensagem, mas apenas o nó que está no seu
caminho de retorno a encaminha adiante na rede; os outros nós a descartam,
conforme especificado no algoritmo SbV. Na Figura 37(b), as setas tracejadas
representam as respostas encaminhadas aos nós que não se encontram no caminho
de retorno dessas mensagens e os círculos tracejados representam o descarte das
mensagens nesses nós. O caminho de retorno da resposta originada pelo nó 12
(CRep 12 ) é 121615117, o do nó 13 (CRep 13 ) é 139567 e o do nó
14 (CRep 14 ) é 1410117. Ao escutar as mensagens de resposta dos nós 12 e
13, o nó 14 suprime a sua própria mensagem, pois a classifica como excedente, já
que o valor do seu replyDelay é muito maior do que o dos demais; a supressão é
representada na Figura 37(b) pelo círculo contornado pela linha sólida.
Nos cenários de teste realizados considerando-se a mobilidade dos
dispositivos foram executadas rodadas de simulação utilizando os valores dos
parâmetros definidos na Tabela 5. Foi considerado para esse cenário uma
topologia determinada aleatoriamente a cada rodada pelo script NCTUns. A
escolha dos dispositivos que irão atuar como colaboradores ativos é feita também
de forma aleatória a cada rodada, considerando o valor de p.

Implementação 159
Tabela 5 – Parâmetros de simulação NCTUns contemplando a mobilidade.
Parâmetro
Valores
Número de dispositivos (N) 10
Densidade média de dispositivos por raio de transmissão
3 dispositivos
Distância média entre dispositivos
240 m
Alcance da transmissão
250 m
Velocidade máxima de deslocamento
2 m/s
Pausa entre deslocamentos
10 s
Percentual de dispositivos colaboradores ativos (p) 60%
Número máximo de respostas (R) 2
A Figura 38 ilustra o comportamento das entidades P2PDP no processo de
descoberta em uma rodada de simulação específica, de acordo com o cenário
descrito pelos parâmetros da Tabela 5. O tempo máximo de espera por uma
resposta (maxReplyDelay) é configurado para 10 s. Nesse cenário, o nó 4 atua
como o iniciador do processo de descoberta, os nós 2, 5, 7, 8, 9 e 10 atuam no
modo de colaboração ativa e os demais nós, no modo passivo. As setas, na figura,
indicam o deslocamento dos nós durante o tempo de simulação, que foi de 53
segundos. Os círculos tracejados indicam a área que corresponde ao alcance de
transmissão de cada nó no início da rodada de simulação; o círculo com a borda
contínua indica a área que corresponde ao alcance de transmissão do iniciador
(nó 4) após completar o seu deslocamento.
Pela observação da Figura 38, no início da colaboração, desconsiderando-se
a adequação dos dispositivos, os colaboradores mais próximos do iniciador são os
nós 5 e 10. Conforme os dispositivos vão se movimentando, os colaboradores 2,
5, 9 e 10 vão se aproximando do iniciador, permanecendo no seu alcance de
transmissão ao final do deslocamento. Pela análise do arquivo de trace da
simulação, é possível observar que os colaboradores 7 e 8 foram os únicos a não
responder à requisição do iniciador, por se encontrarem fora do alcance de
transmissão dos demais nós, durante a difusão da mensagem. Os nós 2, 5, 9 e 10
agendam o envio de suas respostas, conforme especificado no algoritmo SbV, em
função do temporizador replyDelay, calculado de forma distribuída e
independente, em cada colaborador, através do algoritmo DR. Os valores obtidos
para os temporizadores replyDelay nos colaboradores 2, 5, 9 e 10 foram,
respectivamente, 1667 ms, 3829 ms, 2884 ms e 6830 ms. Por fim, o iniciador
recebe as respostas dos colaboradores 2 e 9, com as demais respostas sendo

Implementação 160
suprimidas ao longo do seu caminho de retorno. A resposta do colaborador 5 é
descartada pelo iniciador, pois ele já havia recebido o número de respostas que
havia solicitado (R = 2). A resposta do colaborador 10 é suprimida por ele mesmo
ao escutar as respostas dos colaboradores 2 e 9. Como resultado das simulações
executadas, foi possível verificar a correção dos mecanismos de descoberta e
seleção de recursos implementados no protocolo P2PDP, considerando-se o
deslocamento dos nós. É importante ressaltar que a escolha do cenário
reproduzido na Figura 38 foi simplesmente o de ilustrar o comportamento do
protocolo P2PDP em uma rede sem fio ad hoc de saltos múltiplos, mediante a
mobilidade dos nós. O número de dispositivos foi escolhido por uma questão
meramente didática, com o intuito de facilitar a explanação sobre o
funcionamento do protocolo P2PDP. Cenários de maior escala são retratados no
Capítulo 6, onde é feita a avaliação de desempenho do protocolo P2PDP.
Figura 38 – Rodada de simulação NCTUns com mobilidade.

6
Avaliação de Desempenho
Um dos grandes desafios no desenvolvimento de soluções para grades móveis é a
necessidade de se avaliar o desempenho destas soluções para um grande número
de dispositivos sem fio que podem compor a grade móvel. Mesmo que essas
soluções tenham sido validadas com uma implementação em pequena escala, é
importante a sua avaliação em um ambiente de maior escala, devido à
complexidade adicional introduzida pelo comportamento dinâmico de um grande
número de dispositivos sem fio. Com base nestas considerações, a simulação
apresenta-se como a única alternativa viável para a avaliação de desempenho em
larga escala.
O objetivo deste capítulo é apresentar, em detalhes, os resultados obtidos
através da simulação do protocolo de descoberta e seleção de recursos P2PDP
com a utilização de diferentes cenários de simulação. Como foi mencionado nos
capítulos anteriores, o P2PDP envolve a difusão de uma mensagem de requisição
de descoberta para um recurso específico na grade móvel. A essa requisição,
pode-se seguir um conjunto de mensagens de resposta, partindo de vários outros
dispositivos na grade que possam oferecer o recurso solicitado. A idéia é que, para
garantir a escalabilidade do protocolo, parte dessas mensagens de resposta possam
ser suprimidas, ao longo do seu caminho de retorno, à medida que a requisição
seja plenamente satisfeita por outras respostas [Gomes et al. 2007; Lima et al.
2007b].
6.1.
Cenários de Simulação e Métricas de Avaliação
Nesta seção, são discutidos os cenários de simulação que refletem os casos de uso
favoráveis e desfavoráveis do protocolo P2PDP. Dando continuidade a essa
discussão, ao final desta seção são apresentados alguns fatores que influenciam o

Avaliação de Desempenho 162
desempenho do protocolo, o que irá auxiliar na identificação das métricas que
melhor se adequam à avaliação de desempenho do protocolo proposto.
Nos cenários de simulação ilustrados pela Figura 39 e pela Figura 40, os
círculos representam o alcance de transmissão dos dispositivos posicionados no
seu centro. Nesses cenários, considera-se que a mensagem de requisição (IReq) é
propagada para todos os dispositivos (colaboradores C 1 a C 7 ) e que esses
dispositivos podem colaborar, enviando mensagens de resposta (CRep),
representadas pelas setas tracejadas, para o nó que originou a requisição (iniciador
I), em função da sua disponibilidade de recursos. Para evitar que as figuras
ficassem sobrecarregadas, foi omitida a representação da entrega de cada resposta
para todos os nós no alcance de transmissão do colaborador que a originou. Por
exemplo, na Figura 39, a resposta do nó C 2 é recebida pelos nós I, C 1 e C 5 , os
quais se encontram no alcance de transmissão de C 2 , entretanto, apenas o caminho
C 5 C 2 foi representado.
Figura 39 – P2PDP: cenário de uso favorável.
A Figura 39 ilustra um cenário de simulação favorável do protocolo P2PDP,
onde os vizinhos diretos (colaboradores C 1 e C 2 ) do nó que originou a requisição
(iniciador I) encontram-se no alcance de transmissão um do outro. Nessa situação,
o mecanismo de supressão apresenta o seu melhor desempenho, pois as
mensagens de resposta que chegam aos vizinhos diretos do iniciador, nós (C 1 e
C 2 ), sobrevivendo às supressões realizadas nos nós intermediários, são escutadas

Avaliação de Desempenho 163
por ambos, que podem então suprimir as suas próprias respostas ou mesmo as
mensagens provenientes dos outros nós da rede, caso elas sejam reconhecidas
como excedentes pelo algoritmo SbV.
Figura 40 – P2PDP: cenário de uso desfavorável.
A Figura 40 ilustra um cenário de simulação desfavorável do protocolo
P2PDP. Nesse cenário, todos os vizinhos diretos (colaboradores C 1 , C 2 e C 3 ) do
nó que originou a requisição (iniciador I) encontram-se fora do alcance de
transmissão uns dos outros. Nesse caso, o mecanismo de supressão pode
apresentar o seu pior desempenho, pois as mensagens de resposta que chegam a
cada um desses nós (C 1 , C 2 e C 3 ), não seriam “escutadas” pelos demais, o que
inviabiliza a supressão de respostas entre esses nós. Nessa situação, o número de
respostas recebidas pelo iniciador pode chegar, em um caso extremo, ao número
de respostas solicitadas (numMaxReplies), vezes o número de vizinhos diretos do
iniciador (N).
O desempenho do protocolo P2PDP, nos cenários de simulação
apresentados, pode sofrer variações em função de parâmetros como o número de
dispositivos na grade móvel, a densidade de dispositivos – parâmetro que
determina o número de dispositivos na área de cobertura equivalente ao raio de
transmissão –, a distância média entre os dispositivos, o percentual de dispositivos
atuando no modo de colaboração ativa e o número máximo de respostas esperado.

Avaliação de Desempenho 164
Esses fatores influenciam o número de mensagens que trafegam pelo enlace sem
fio e, conseqüentemente, a atuação do mecanismo de supressão de respostas. A
seguir, são apresentadas as métricas que serão empregadas como medidas de
avaliação de desempenho do protocolo P2PDP, levando em consideração a
variação dos parâmetros acima mencionados:
• Número total de transmissões. Indica a carga média da MANET em
termos do número total de mensagens de requisição e resposta do
protocolo P2PDP, que varia em função do aumento do número de
dispositivos na grade móvel;
• Diâmetro de supressão. O diâmetro de supressão das mensagens de
resposta por vizinhança mede a distância – em número de saltos – dos
dispositivos onde ocorrem as supressões até o dispositivo requisitante. O
tamanho do diâmetro de supressão determina a distribuição do
processamento gerado pelo algoritmo SbV entre os dispositivos da grade
móvel;
• Balanceamento de carga. Essa métrica quantifica o nível de
balanceamento de carga obtido, em função do mecanismo de seleção que
promove uma distribuição uniforme das requisições de serviço, entre os
dispositivos da rede mais aptos a atendê-las. A carga é medida em termos
do percentual de CPU compartilhado por cada dispositivo da grade móvel
durante o processamento das requisições.
Essas métricas foram escolhidas por representarem os requisitos definidos
na Seção 1.2, que dizem respeito às características desejáveis a um protocolo de
descoberta de serviços em uma grade móvel ad hoc, os quais são retomados na
Seção 6.5. As métricas número total de transmissões e diâmetro de supressão
estão relacionadas à avaliação do impacto do problema de implosões de respostas
e de colisões; já a métrica balanceamento de carga diz respeito à avaliação da
distribuição das requisições de serviço no protocolo P2PDP.
A discussão apresentada no início deste capítulo definiu a simulação como a
única alternativa viável para a avaliação de desempenho do protocolo P2PDP em
um ambiente de maior escala. Dadas as características do protocolo P2PDP e as
medidas de desempenho que se pretende utilizar, o ns-2 [ISI 1995] foi o simulador

Avaliação de Desempenho 165
escolhido. Outros aspectos que motivaram a escolha do simulador ns-2 dizem
respeito a sua utilização ser bastante difundida na comunidade científica, a grande
quantidade de documentação disponível e listas de discussão ativas sobre o
mesmo; a versão do simulador utilizada corresponde a 2.29.
6.2.
Análise de Escalabilidade
O protocolo P2PDP teve a sua escalabilidade avaliada com simulações realizadas
no ns-2, as quais foram modeladas sobre uma rede sem fio ad hoc de saltos
múltiplos “fixa”, ou seja, sem especificar parâmetros referentes à mobilidade dos
dispositivos, utilizando a camada MAC IEEE 802.11 com a sua configuração
padrão. Portanto, esses experimentos correspondem a cenários com baixa
mobilidade ou ausência de mobilidade. Nesses cenários, o tempo necessário para a
descoberta equivale ao RTT (round-trip time) entre o envio da requisição e o
recebimento das primeiras respostas, que correspondem as respostas de melhor
qualidade, pelo nó requisitante. Uma baixa taxa de movimentação dos nós, nesse
caso, garante uma relativa estabilidade da topologia da rede, de forma que o
caminho seguido pelas primeiras respostas deverá ser o caminho inverso ao
seguido pela requisição de descoberta.
Nos cenários apresentados, a topologia da rede sem fio foi definida como
um conjunto de nós dispostos regularmente na forma de grade, como ilustrado na
Figura 37 do Capítulo 5. Os scripts desenvolvidos para a simulação no ns-2,
implementados em OTcl (Object Tool Command Language), reproduzem o
comportamento do algoritmo SbV nas entidades de descoberta P2PDP em cada
dispositivo. Esses scripts tiveram como objetivo avaliar os caminhos seguidos por
diferentes mensagens de resposta do protocolo P2PDP e medir o grau médio de
sobreposição desses caminhos. Esse parâmetro define em que altura do caminho
seguido pela mensagem de resposta, entre o colaborador e o iniciador, ocorre a
supressão da resposta; o grau médio de sobreposição é medido em termos do
números de saltos. Essa abordagem permitiu que se medisse o nível de supressão
de respostas P2PDP. Em cada script, é configurado o parâmetro N = m x n, que
especifica o número total de dispositivos da grade. Um segundo parâmetro de
simulação, p, determina a porcentagem de colaboradores ativos, ou seja, o

Avaliação de Desempenho 166
percentual de dispositivos da grade que irão responder à requisição do nó
requisitante, enviando uma resposta por unicast em sua direção. Um terceiro
parâmetro, R, define quantas respostas são esperadas pelo nó requisitante. Assim,
pôde ser avaliada a influência do número relativo de colaboradores ativos e
respostas esperadas pelo requisitante sobre o desempenho do protocolo. Em
função da topologia de grade utilizada, o uso de unicast na transmissão das
respostas mostrou-se uma solução simples e eficiente para reproduzir o
comportamento da transmissão das respostas através do caminho de retorno, sem
a necessidade de se implementar o monitoramento (“escuta”) dessas mensagens
pelos nós que não fazem parte do caminho. Após a definição do número de nós
que atuarão como colaboradores ativos (p x N), é aplicada uma função que
escolhe aleatoriamente a posição que esses nós irão ocupar na grade.
Um segundo script, em Lua [Ierusalimschy et al. 2006], é então aplicado ao
resultado da simulação. Esse script processa (i) o arquivo textual gerado pelo
script ns-2, que descreve a topologia em grade utilizada na simulação e (ii) o
arquivo de trace dos pacotes da simulação no ns-2. A partir do processamento
desses arquivos, o script extrai algumas informações, como o nó que corresponde
ao destino final e todos os seus vizinhos diretos, os nós que correspondem às
origens dos pacotes transmitidos e, por fim, o caminho, salto-a-salto, percorrido
por cada pacote, reproduzido através de tuplas constituídas pelo nó-origem, nódestino
e pela identificação do pacote. Com isso, é montada uma tabela, através da
qual são analisadas as supressões das mensagens de resposta ao longo da grade
simulada. O objetivo de se utilizar esse script de pós-processamento, é identificar
supressões por vizinhança em potencial e calcular quantas transmissões de pacotes
e quantas supressões, por diâmetro de supressão, efetivamente ocorreriam se o
algoritmo SbV fosse de fato implementado na simulação.
O motivo de se adotar um modelo em grade sem fio fixa para as simulações
no ns-2 foi gerar topologias com comportamento de encaminhamento de pacotes
bem definido. Essa abordagem foi escolhida com o intuito de obter
comportamentos regulares e previsíveis para assim poder efetuar uma análise mais
precisa da escalabilidade do algoritmo, levando em consideração os cenários de
uso do protocolo P2PDP mais e menos favoráveis descritos na Seção 6.1. A
topologia adotada corresponde a uma fotografia instantânea de uma rede sem fio

Avaliação de Desempenho 167
com baixa taxa de movimentação, caracterizando um cenário bem específico. Esse
cenário específico pode ser representado utilizando-se, por exemplo, o modelo de
mobilidade RWP (Random WayPoint), a velocidade média de deslocamento dos
nós de 2 m/s – velocidade que caracteriza o perfil de mobilidade de uma pessoa
caminhando –, sem períodos de pausa entre os deslocamentos. Além disso, é
necessário que se façam algumas considerações adicionais: (i) o período de tempo
decorrido entre o envio de uma requisição e a recepção das respostas
correspondentes transcorre em 10 s (maxReplyDelay = 10), (ii) o alcance de
transmissão de cada dispositivo é configurado para 250 m (padrão da camada
MAC IEEE 802.11, implementada no ns-2) e (iii) as distâncias máxima e mínima
entre os dispositivos vizinhos são configuradas para 200 m e 10 m,
respectivamente, o que implica em um deslocamento coletivo, com os dispositivos
não se afastando mais do que 200 m uns dos outros. Nesse cenário de baixa
mobilidade, os nós continuarão alcançáveis com uma grande probabilidade – a
menos que ocorra alguma falha com o próprio dispositivo ou no enlace sem fio, o
que não foi considerado nesse exemplo. A baixa mobilidade dos dispositivos não
interfere nos resultados de simulação obtidos pois a topologia da rede é mantida.
Foi realizada uma série de experimentos reproduzindo o comportamento do
algoritmo SbV, considerando-se uma densidade fixa de dispositivos na MANET –
usando topologias com número fixo de dispositivos em um mesmo raio de
transmissão –, de modo a avaliar o efeito do aumento no número de dispositivos
na MANET, sobre o mecanismo de supressão de respostas. Os resultados
apresentados nesta seção correspondem às médias dos resultados coletados, em
um total de cem rodadas por cenário de simulação, com um nível de confiança de
95%. Os experimentos visaram, primordialmente, a avaliação de duas métricas: o
número total de transmissões, considerando-se a carga de mensagens de resposta
na MANET, e o diâmetro de supressão dessas mensagens. A Tabela 6 apresenta
os valores dos parâmetros de simulação usados na constituição das rodadas de
simulação.

Avaliação de Desempenho 168
Tabela 6 – Parâmetros de simulação ns-2.
Parâmetro
Valores
Número de dispositivos (N) 25 a 240
Densidade de dispositivos
5 dispositivos
Distância média entre dispositivos
10 m
Percentual de dispositivos colaboradores ativos (p) 20% a 80%
Número máximo de respostas (R) 1 a 10
Na Tabela 6, o número de dispositivos (N) varia de 25 até 240 nós, ou seja,
os pares m x n variam de 5 x 5 até 16 x 15, formando uma seqüência do tipo
{5 x 5, 5 x 6, 6 x 6, 6 x 7 ... 15 x 16}, com m e n variando em passos de 1. O valor
de p varia no intervalo de 20% até 80% em passos de 20%, ou seja, são atribuídos
a p os valores 20%, 40%, 60% e 80%, o valor de R varia de 1 a 10 em passos de 1.
6.2.1.
Análise da Influência do P2PDP na Carga Média da MANET
A carga média decorrente do tráfego de mensagens de resposta, foi medida
calculando-se, para cada cenário, a média do número total de transmissões de
pacotes relativos a essas mensagens. Para essa métrica, foi feita uma comparação
entre dois protocolos de descoberta de serviços simples, os quais tiveram o seu
comportamento reproduzido através de scripts ns-2, um baseado puramente em
requisições por broadcast e respostas por unicast (chamado, aqui, de “UCast”) e o
protocolo P2PDP, baseado em requisições e respostas por broadcast,
incorporando o mecanismo SbV no encaminhamento de respostas. Em ambos os
protocolos, não há o emprego de anúncios de serviços. Os gráficos das
Figuras 41, 42, 43 e 44 ilustram os resultados das medições do volume de
mensagens de resposta, em função do número de dispositivos na MANET, para
diferentes percentuais de dispositivos respondentes; as barras verticais indicam os
níveis de confiança. É possível observar, nesses gráficos, que através do
mecanismo SbV obtém-se uma redução crescente no número total de
transmissões, para um número crescente de dispositivos na MANET, quando
comparado, nas mesmas condições, ao comportamento do protocolo UCast. Podese
constatar resultados ainda mais acentuados de supressão quando se aumenta o
percentual de dispositivos (p) com interesse em colaborar na provisão de serviços.

Avaliação de Desempenho 169
Esses resultados indicam uma boa escalabilidade para protocolos que adotam o
mecanismo SbV no tratamento de respostas, como no P2PDP.
Como esperado, a adoção do mecanismo de supressão por vizinhança reduz
consideravelmente o número total de transmissões, se comparado ao protocolo
UCast. Como é ilustrado na Tabela 7, para um número máximo de respostas (R)
igual a 10, o uso do mecanismo SbV reduz em média em até 2,77 vezes o número
total de transmissões na rede; essa redução chega a 14,24 quando o número
máximo de respostas (R) é configurado para 1. Fazendo a mesma comparação em
relação ao percentual de colaboradores ativos (p), verifica-se que para p=20% o
uso do mecanismo SbV reduz em média em até 12,08 vezes o número total de
transmissões na rede; essa redução chega a 24,60 quando o percentual de
colaboradores ativos (p) cresce para 80%. Através da observação direta desses
resultados, constata-se que o aumento na densidade do número de colaboradores
ativos (p) influencia diretamente no aumento do volume de dados gerado na rede,
em função da transmissão de respostas por broadcast na rede. Com a utilização do
mecanismo SbV é possível verificar que quanto maior a densidade de
colaboradores ativos, mais drasticamente esse volume de dados é reduzido.
Tabela 7 – Número total de transmissões de pacotes.
p (%) SbV R=1 SbV R=2 SbV R=4 SbV R=6 SbV R=8 SbV R=10 UCast
20 36 74 134 173 201 223 368
40 59 99 178 242 291 331 737
60 76 119 200 280 343 396 1093
80 93 135 217 308 382 439 1467
Considerando-se um cenário de grade móvel realista, o número de
dispositivos pode variar da casa das dezenas – estudantes em uma sala de aula – a
centenas – pessoas em um aeroporto aguardando os seus vôos ou mesmo
participantes de uma conferência. De acordo com os resultados obtidos em
pesquisas relacionadas à colaboração em sistemas P2P, uma parcela significativa
dos usuários não contribui com recursos na comunidade. Segundo os resultados
obtidos em [Saroiu et al. 2002], no Gnutella [Gnutella 2005] cerca de 25% dos
dispositivos atuam exclusivamente como consumidores de recursos e serviços; no
Napster [Napster 2005] esse número varia de 20% a 40%. Considerando-se a
ocorrência de números similares em uma grade móvel para aplicações de
compartilhamento de arquivos, infere-se que em média 72% dos dispositivos

Avaliação de Desempenho 170
atuarão como colaboradores ativos. Fazendo uma estimativa baseada nos
resultados mostrados na Tabela 7, o uso do mecanismo SbV reduz em até 23,57
vezes o número total de transmissões na rede para p = 72%.
Com relação ao número de dispositivos na rede (N), é possível observar que,
no mecanismo SbV, o aumento do número de transmissões acontece de forma
suave, proporcionalmente ao aumento de colaboradores ativos (p). O número total
de transmissões de pacotes de dados na rede está diretamente relacionado aos
valores de N e p, ou seja, quanto maior o número de colaboradores ativos ( N × p )
é natural que haja um aumento proporcional no número de respostas trafegando na
rede. Ainda em relação ao mecanismo SbV, o crescimento do número de total de
transmissões é controlado pela supressão de respostas desnecessárias, que são
retiradas da rede antes de chegar ao seu destino. Como a supressão é feita
levando-se em consideração o número máximo de respostas (R) solicitadas na
requisição de descoberta, quanto menor for o valor de R maior será o número de
supressões, o que é atestado comparando-se os valores obtidos para R=1 e R=9
nos gráficos reproduzidos nas Figuras 41, 42, 43 e 44.
Figura 41 – Carga na MANET para 20% de colaboradores ativos (p).

Avaliação de Desempenho 171
Figura 42 – Carga na MANET para 40% de colaboradores ativos (p).
Figura 43 – Carga na MANET para 60% de colaboradores ativos (p).

Avaliação de Desempenho 172
Figura 44 – Carga na MANET para 80% de colaboradores ativos (p).
É importante ressaltar que a comparação do protocolo P2PDP com
protocolos que adotam um mecanismo de descoberta baseado no encaminhamento
de anúncios periódicos de serviços – quer seja exclusivamente proativa ou híbrida
– não ofereceria um nível de comparação coerente. Isso se deve ao fato do
protocolo P2PDP adotar uma abordagem de descoberta reativa – baseada no envio
de requisições de serviço sob demanda –, tendo sido desenvolvido
especificamente para oferecer suporte à descoberta de recursos dinâmicos em uma
grade móvel ad hoc, em conformidade com os requisitos definidos na Seção 1.2.
Neste trabalho, optou-se por colocar o desempenho do P2PDP sob perspectiva,
comparando-o com um protocolo de descoberta de recursos reativo, baseado
puramente no uso de broadcast para difusão das requisições e no encaminhamento
das respostas em unicast até o nó que originou a requisição (UCast). Essa
comparação se mostra válida tendo em vista os resultados apresentados na
avaliação comparativa de desempenho dos protocolos proativos Konark-gossip
[Lee et al. 2003] e Allia [Ratsimor et al. 2004] com um protocolo baseado no
mecanismo de descoberta reativo. A especificação do protocolo UCast definida
nesta tese é similar a do protocolo reativo utilizado como base de comparação
nesses trabalhos.; esse protocolo será denominado genericamente como UCast
desse ponto em diante. Os resultados obtidos mostram que o UCast apresenta
desempenho satisfatório em comparação com as abordagens proativas. Os

Avaliação de Desempenho 173
gráficos apresentados em [Lee et al. 2003] mostram que o tempo de resposta do
protocolo UCast é consideravelmente maior do que o das abordagens proativas,
especialmente quando o diâmetro da requisição é configurado para menos de
quatro saltos. Entretanto, o volume de tráfego gerado pelo protocolo UCast é bem
menor do que a maioria dos protocolos reativos analisados, superando, inclusive,
o protocolo que apresentou o melhor desempenho entre os proativos. No gráfico
apresentado em [Lee et al. 2003], reproduzido aqui na Figura 45, a eficiência da
descoberta de serviços é representada considerando como critério de avaliação o
tempo de resposta da solicitação de descoberta pelo volume de tráfego de dados
gerado pelas mensagens de descoberta – anúncio, requisição e resposta. Através
da análise desse gráfico, pode-se observar que o protocolo UCast – identificado
como “broadcast” na Figura 45 – apresentou o desempenho mais aproximado do
protocolo Konark-gossip, que foi o que obteve a melhor avaliação. Considerando
ainda a eficiência da descoberta de serviços, o protocolo UCast supera o
desempenho do protocolo Konark-gossip quando o diâmetro da requisição é
configurado para zero, ou seja, quando a requisição é entregue apenas aos
vizinhos diretos do nó que a originou. No gráfico da Figura 45 o tempo de
resposta é dado em segundos e o volume do tráfego de dados é dado em bytes; a
legenda TTL (Time-To-Live) representa o número de saltos através do qual uma
requisição de descoberta é encaminhada.
Figura 45 – Eficiência da descoberta de serviços (extraída de [Lee et al. 2003]).
Ao final dessa discussão, é possível concluir que como o uso do algoritmo
SbV reduz consideravelmente o tráfego de dados gerado pelo protocolo UCast, o

Avaliação de Desempenho 174
protocolo P2PDP tem o potencial de apresentar um resultado superior, em relação
a esse mesmo parâmetro, se comparado aos protocolos proativos Allia e Konarkgossip.
Para a obtenção de um resultado mais preciso é necessário que,
futuramente, seja realizada uma análise comparativa de desempenho do protocolo
P2PDP com os protocolos proativos em questão.
6.2.2.
Análise do Mecanismo de Supressão de Respostas do P2PDP
O diâmetro de supressão das mensagens de resposta mede a distância – em
número de saltos – dos dispositivos onde ocorrem as supressões até o dispositivo
requisitante. Essa métrica permite avaliar a distribuição da ocorrência de
supressões, nos dispositivos na MANET, propiciada pelo mecanismo SbV, graças
ao não encaminhamento das mensagens de resposta excedentes na rede.
Como pode ser observado nos gráficos reproduzidos nas Figuras 46, 47
e 48, o número médio de supressões mantém uma taxa de crescimento
proporcional em função do aumento do diâmetro de supressão para todos os
percentuais de colaboradores ativos (p). Por esse motivo, sem incorrer em prejuízo
para a análise dos resultados relativos à métrica diâmetro de supressão, apenas os
gráficos referentes aos valores p =20% e p = 60% serão apresentados. É
importante mencionar que nos gráficos reproduzidos abaixo, o número de
respostas solicitadas (R) é igual a 4, que corresponde a uma amostra representativa
para os demais valores de R.

Avaliação de Desempenho 175
Figura 46 – Número médio de supressões para R=4 e N=60.
Figura 47 – Número médio de supressões para R=4 e N=120.

Avaliação de Desempenho 176
Figura 48 – Número médio de supressões para R=4 e N=240.
Os gráficos reproduzidos nas Figuras 49, 50 e 51 ilustram os resultados das
medições do diâmetro das supressões, para diferentes números de dispositivos e
percentuais de dispositivos respondentes na MANET, sob a forma de uma
distribuição cumulativa de probabilidades. Para ilustrar a distribuição das
supressões pela MANET, os resultados das medições são contrastados com uma
função de distribuição cumulativa uniforme (FDC), que é representada, no
gráfico, pela linha contínua na diagonal. Essa abordagem se mostra como uma boa
alternativa para apresentar os resultados obtidos pois permite verificar o quanto a
função de distribuição relativa ao diâmetro de supressão se afasta da FDC
uniforme. Quanto mais próxima a função de distribuição do diâmetro de supressão
se apresenta da FDC uniforme, isso significa que, a responsabilidade pela
supressão é espalhada pelos vários dispositivos da grade móvel, não provocando a
sobrecarga de dispositivos específicos.
Nos gráficos apresentados, pode-se observar uma melhor distribuição das
supressões com o aumento no número de dispositivos (N) e percentuais de
dispositivos respondentes (p) na rede, o que novamente indica a escalabilidade da
estratégia proposta. É possível observar também, que conforme o número de
respostas esperadas (R) aumenta, a função de distribuição do diâmetro de
supressão se afasta proporcionalmente da FDC uniforme, o que é esperado, já que
como o número de respostas que devem ser entregues ao iniciador aumenta é
natural que a ocorrência de supressões diminua.

Avaliação de Desempenho 177
Tabela 8 – Número médio de supressões para p=20 e p=60 com N=60.
Diâmetro
de
SbV R=1 SbV R=2 SbV R=4 SbV R=6 SbV R=8 SbV R=10
Supressão 20% 60% 20% 60% 20% 60% 20% 60% 20% 60% 20% 60%
1 1,50 4,00 1,50 3,90 1,60 3,91 1,44 4,00 1,00 4,16 0,75 3,90
2 1,90 5,80 2,70 7,20 3,10 8,89 2,60 9,72 2,20 10,28 1,65 10,85
3 3,10 8,70 2,80 8,20 1,69 8,32 1,20 8,08 0,84 7,48 0,50 6,40
4 2,40 7,50 1,90 8,00 1,15 6,61 0,60 4,96 0,32 4,00 0,25 2,80
5 1,90 6,40 1,40 5,10 0,49 3,82 0,24 2,40 0,16 1,44 0,10 0,85
6 1,00 3,10 0,70 3,10 0,19 1,60 0,08 0,64 0,08 0,24 0,00 0,15
7 0,50 1,80 0,10 0,60 0,04 0,22 0,00 0,08 0,00 0,00 0,00 0,00
( a ) Percentual de colaboradores ativos (p) igual a 20%
( b ) Percentual de colaboradores ativos (p) igual a 60%
Figura 49 – Distribuição das supressões de mensagens de resposta para N=60.

Avaliação de Desempenho 178
Tabela 9 – Número médio de supressões para p=20 e p=60 com N=120.
Diâmetro
de
SbV R=1 SbV R=2 SbV R=4 SbV R=6 SbV R=8 SbV R=10
Supressão 20% 60% 20% 60% 20% 60% 20% 60% 20% 60% 20% 60%
1 1,62 3,48 1,60 3,68 1,75 4,16 2,00 4,50 1,80 4,16 1,44 3,72
2 2,34 5,58 3,00 6,60 4,60 8,36 5,30 10,85 5,40 12,52 5,44 14,28
3 3,06 9,24 3,72 8,80 3,90 10,48 3,65 11,00 3,28 11,64 2,72 11,60
4 3,78 9,72 3,76 12,08 3,45 11,8 3,05 12,30 2,20 11,32 1,48 10,52
5 4,02 13,14 3,68 11,60 2,70 11,64 2,00 10,00 1,32 9,56 0,80 9,00
6 3,54 10,00 3,00 10,68 1,85 8,76 1,10 8,15 0,68 7,28 0,32 6,24
7 2,94 9,18 1,96 7,44 1,00 6,60 0,60 5,55 0,28 3,72 0,08 2,00
8 1,80 5,00 1,12 5,44 0,60 4,00 0,25 1,90 0,16 0,76 0,00 0,16
9 1,26 4,08 0,64 2,52 0,00 0,80 0,00 0,25 0,00 0,16 0,00 0,00
10 0,24 0,84 0,00 0,32 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
( a ) Percentual de colaboradores ativos (p) igual a 20%
( b ) Percentual de colaboradores ativos (p) igual a 60%
Figura 50 – Distribuição das supressões de mensagens de resposta para N=120.

Avaliação de Desempenho 179
Tabela 10 – Número médio de supressões para p=40 e p=80 com N=240.
Diâmetro
de
SbV R=1 SbV R=2 SbV R=4 SbV R=6 SbV R=8 SbV R=10
Supressão 40% 80% 40% 80% 40% 80% 40% 80% 40% 80% 40% 80%
1 1,68 2,88 1,50 3,65 1,90 4,00 2,10 4,50 2,00 4,15 2,00 3,90
2 2,40 7,20 3,35 7,25 5,20 8,90 5,90 11,00 7,00 13,10 7,45 15,75
3 2,96 7,36 3,90 9,00 4,40 10,55 5,30 12,00 4,90 13,35 5,00 13,60
4 4,16 12,40 4,40 11,7 4,80 13,00 4,40 14,00 4,45 14,20 4,20 14,40
5 4,56 11,92 4,80 13,45 4,50 14,45 4,15 14,45 3,50 14,10 3,15 13,80
6 5,36 16,00 4,80 15,42 4,10 14,15 3,20 13,35 2,40 12,70 1,80 11,50
7 4,88 13,00 4,25 13,32 3,00 12,40 2,15 10,70 1,75 10,25 1,30 9,95
8 3,60 12,64 3,25 11,34 2,15 10,25 1,35 8,90 0,85 7,70 0,55 6,80
9 3,12 8,72 2,35 11,28 1,30 7,40 0,60 6,10 0,35 4,95 0,25 3,70
10 2,64 7,84 1,60 8,46 0,70 4,85 0,30 3,40 0,20 2,05 0,20 1,10
11 1,36 4,16 0,90 6,42 0,35 2,50 0,20 0,95 0,10 0,35 0,20 0,30
12 0,88 2,80 0,40 4,02 0,20 0,45 0,10 0,15 0,00 0,15 0,00 0,00
13 0,00 0,00 0,00 1,50 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
( a ) Percentual de colaboradores ativos (p) igual a 20%
( b ) Percentual de colaboradores ativos (p) igual a 60%
Figura 51 – Distribuição das supressões de mensagens de resposta para N=240.

Avaliação de Desempenho 180
Através dos resultados obtidos, sumariados nas Tabelas 8, 9 e 10, podemos
observar que conforme o número de respostas esperadas aumenta (R),
independentemente do número de dispositivos da rede (N), verifica-se que a
ocorrência de supressões se aproxima do dispositivo requisitante, apresentando
uma freqüência mais intensa nos dispositivos a uma distância de 2 a 4 saltos do
iniciador. Esse comportamento é esperado pois dado que o número de respostas
solicitadas aumenta, menor é a ocorrência de supressões nos dispositivos mais
distantes, pois eles “escutarão” um número menor de mensagens. Os dispositivos
mais próximos do iniciador “escutam” mais mensagens, realizando um número
maior de supressões, que ocorrem quando o número de respostas escutadas por
esses dispositivos ultrapassam o número de respostas solicitadas na requisição.
6.2.3.
Visão Geral da Análise de Escalabilidade
Nesta seção, foram apresentados os resultados das simulações no ns-2, com o
protocolo P2PDP, tendo, como foco, o mecanismo de supressão de mensagens de
resposta por vizinhança (SbV), em uma topologia de grade sem fio fixa. Em
particular, mostrou-se que o mecanismo de supressão por vizinhança,
implementado no P2PDP, possibilita uma redução significativa na sobrecarga de
tráfego de comunicação associado ao processo de descoberta. Além disso, o
mecanismo SbV distribui a supressão de respostas entre os dispositivos da rede,
reduzindo a ocorrência de supressões à medida que as respostas vão se
aproximando do dispositivo requisitante. O uso do protocolo P2PDP, em conjunto
com o mecanismo SbV, mostrou-se eficaz em controlar o volume de respostas
recebidas pelo requisitante do serviço, sem comprometer a qualidade das respostas
recebidas no protocolo P2PDP – isto é, favorecendo as respostas dos
colaboradores mais aptos. É importante ressaltar que, no P2PDP, a seleção das
mensagens de resposta de melhor qualidade é implementado de forma distribuída,
nos nós colaboradores, através do retardo programado introduzido no envio dessas
respostas. O retardo é calculado de modo a ser inversamente proporcional à
qualidade das respostas, que é medida em função da disponibilidade dos recursos
do dispositivo que são necessários para a provisão do serviço solicitado. Ou seja,
as respostas de melhor qualidade são enviadas primeiro, favorecendo assim a
supressão posterior das respostas de pior qualidade pelo mecanismo SbV,

Avaliação de Desempenho 181
consideradas excedentes. Pode-se observar, ainda, que o processamento adicional,
gerado pelo mecanismo de supressão, é distribuído uniformemente entre os
dispositivos da rede, evitando que os vizinhos diretos do dispositivo requisitante
sejam sobrecarregados, promovendo um balanceamento indireto no consumo de
bateria.
6.3.
Controle da Ocorrência de Colisões
É importante ressaltar que, apesar do uso de comunicação por broadcast tanto no
encaminhamento das requisições de descoberta quanto no encaminhamento das
respostas a essas requisições, a ocorrência de colisões provocadas pelo tráfego de
mensagens de descoberta do protocolo P2PDP manteve-se estável nos
experimentos realizados. Esse resultado foi verificado empiricamente pela
observação dos resultados obtidos nos ambientes de teste descritos na Seção 5.4.
Nos ambientes de teste reais, descritos na Subseção 5.4.1, os resultados foram
obtidos pela comparação entre o número de respostas solicitadas e o número de
respostas que foram de fato entregues ao dispositivo que originou a requisição. Já
no ambiente de teste simulado, descrito na Subseção 5.4.2, os resultados foram
obtidos pela análise dos arquivos de trace das simulações realizadas no NCTUns.
Nos primeiros experimentos com o protocolo P2PDP, foi possível verificar a
ocorrência de um número considerável de colisões. A partir da utilização do
parâmetro requestDelay (Seção 4.5) e do mecanismo de retardo programado
(Seção 4.7), aplicados, respectivamente, no encaminhamento das requisições de
descoberta e das mensagens de resposta a essas requisições, foi introduzido um
assincronismo na transmissão das mensagens de descoberta do protocolo P2PDP.
Como resultado, observou-se que o número de colisões foi reduzido
consideravelmente, passando a não interferir no resultado dos experimentos
realizados. Entretanto, deve-se deixar claro que, apesar da importância dos
resultados obtidos empiricamente, esses resultados precisam ser investigados em
mais detalhes através da realização de simulações.
Nos experimentos realizados, o retardo programado foi calculado através da
Equação (2), utilizando-se o algoritmo DR. Por sua vez, o parâmetro

Avaliação de Desempenho 182
requestDelay foi configurado em cada retransmissão para um valor aleatório,
em milisegundos, no intervalo [0, 30].
6.4.
Balanceamento de Carga
Uma bateria de testes foi realizada com o intuito de estimar a capacidade de
balanceamento de carga do protocolo P2PDP obtidas em função do mecanismo
de seleção, que promove uma distribuição uniforme das requisições de serviço
entre os dispositivos da rede mais aptos a atendê-las. Durante a execução de um
serviço pode ocorrer uma redução na sua qualidade, que pode ser provocada por
variações na disponibilidade dos recursos disponíveis no dispositivo executando o
serviço, introduzindo tempos de resposta elevados. A implementação do
balanceamento de carga no P2PDP foca na distribuição uniforme da
responsabilidade de execução das tarefas da grade, o que se faz em função da
disponibilidade de recursos dos nós. Ao receber uma requisição de descoberta, os
dispositivos da grade apresentam níveis diferenciados de disponibilidade de
recursos, o que faz com que os retardos no envio das respostas à requisição sejam
configurados de forma distinta em cada nó. Esse comportamento do protocolo
P2PDP oferece implicitamente um mecanismo de balanceamento de carga
dinâmico, baseado na auto-avaliação da disponibilidade de recursos em cada
dispositivo, e comparações com as respostas provenientes dos demais dispositivos
da grade, que pode até mesmo provocar a supressão do envio da sua própria
resposta.
Para ilustrar o comportamento do mecanismo de balanceamento de carga do
protocolo P2PDP, considere um dispositivo atuando como iniciador e dois
dispositivos (C 1 e C 2 ) atuando como colaboradores. O iniciador espera receber
apenas uma resposta para cada requisição. Ao receber a primeira requisição, o
nível de disponibilidade de recursos do colaborador C 1 é superior ao de C 2 , em
função do mecanismo de retardo no envio das respostas, a resposta de C 1 é
privilegiada e esse dispositivo passa a executar o serviço. Enquanto C 1 está
executando o serviço, o iniciador envia uma nova requisição. Ao receber a nova
requisição, os recursos disponíveis em C 1 estão comprometidos com a execução
da primeira requisição, nesse intervalo o colaborador C 2 torna-se mais apto. Como

Avaliação de Desempenho 183
conseqüência, C 1 gera um retardo de envio maior do que C 2 , que tem a sua
resposta privilegiada e é então encarregado de atender a segunda requisição. Essa
situação se repete, o que faz com que a carga gerada pelo processamento das
requisições seja distribuída uniformemente entre os colaboradores mais aptos,
com os dispositivos se revezando na execução de serviços na grade móvel.
Os experimentos foram realizados em uma rede de teste constituída por três
máquinas Linux e uma máquina Windows, todas executando a aplicação M3
(Matrix-Matrix Multiplication). Para quantificar o nível de balanceamento de
carga obtido com a utilização do protocolo P2PDP, o consumo dos recursos CPU
e memória foram monitorados durante as baterias de execução realizadas na rede
de teste. As variações no consumo de memória durante as baterias de execução
não foram significativas, por esse motivo, a análise dos resultados aqui
apresentados contempla apenas o recurso CPU. Para produzir uma carga
cumulativa nos nós colaboradores, foi adicionada uma espera ocupada ao código
original da aplicação M3 que foi descrita na Seção 5.4. Em função dessa
modificação, a aplicação processa um laço vazio de um milhão de iterações após o
cálculo da matriz-linha resultado. Essa carga cumulativa foi criada para forçar os
colaboradores a atingirem níveis próximos a indisponibilidade devido ao alto
percentual de CPU sendo utilizada, chegando a picos de 100% de utilização.
Quando um dado colaborador executa a aplicação M3 ele gera um retardo de
envio de resposta bem maior em relação aos colaboradores que não estão
executando a mesma aplicação, o que fará com que a sua resposta seja preterida
em favor das respostas geradas pelos outros colaboradores. As requisições são
geradas, pela aplicação M3, em intervalos regulares de 30 s e o tempo máximo de
espera (maxReplyDelay), por cada resposta, é configurado para 10 s. Esses
valores foram escolhidos pois o tempo de execução média de cada tarefa gerada
pela aplicação M3 é de 20s e o tempo no qual o processo de descoberta deve ser
concluído considerado mínimo é de 10s [Hermann et al. 2001]. Em função desses
valores, espera-se no intervalo de 30s a requisição de descoberta seja respondida e
a aplicação M3 executada no colaborador selecionado. Para esses experimentos
foram realizadas trinta baterias de teste, com cada uma gerando trinta requisições
de serviço M3. Os resultados obtidos são ilustrados através do gráfico na
Figura 52.

Avaliação de Desempenho 184
Figura 52 – Carga cumulativa do uso da CPU nos nós colaboradores.
O gráfico reproduzido na Figura 52 mostra o compartilhamento da carga de
CPU para cada nó, durante um experimento específico, que reflete o
comportamento obtido em todas as baterias de teste executadas. O
compartilhamento de CPU diz respeito a distribuição percentual de utilização da
CPU em cada um dos dispositivos durante o processamento das requisições, que
inclui as etapas de descoberta e utilização de recursos. É possível observar no
gráfico da Figura 52 que os nós colaboradores têm a sua carga de CPU balanceada
após um estado inicial de calibragem do mecanismo de seleção que corresponde
ao período em que as três primeiras requisições são atendidas; o protocolo P2PDP
proporciona o balanceamento de carga, entre os nós colaboradores, a medida que
o número de requisições cresce. Como era de se esperar, a utilização de CPU é
distribuída de modo uniforme entre os três dispositivos colaboradores, que se
alternam na execução das requisições de serviço M3. A análise dos arquivos de
log de cada dispositivo, nos quais foram registradas as variações na
disponibilidade de CPU, reforça os estudos feitos em [Bolosky et al. 2000], onde a
distribuição da utilização da carga de CPU é caracterizada como bimodal, ou seja,
os seus valores alternam entre períodos de utilização total e outros próximos à
inatividade.

Avaliação de Desempenho 185
6.5.
Visão Geral dos Resultados Obtidos
O desempenho do protocolo de descoberta P2PDP foi avaliado em cenários
estáticos, utilizando-se duas estratégias distintas: simulações em uma grade sem
fio fixa no ns-2 e baterias de execução de aplicações MoGrid em uma rede de
teste. Para a avaliação dos experimentos, algumas métricas foram definidas:
número total de transmissões de mensagens de resposta do protocolo P2PDP,
diâmetro de supressão de mensagens de resposta por vizinhança e balanceamento
de carga em função do mecanismo de seleção de respostas que,
conseqüentemente, privilegia as respostas dos colaboradores mais aptos. Para
medir a escalabilidade do protocolo, foram gerados cenários de simulação em
função da variação de diferentes parâmetros, como o número de dispositivos na
rede, a densidade de dispositivos, a distância média entre os dispositivos, o
alcance de transmissão, o percentual de dispositivos atuando no modo de
colaboração ativa e o número máximo de respostas esperado.
Os resultados obtidos foram satisfatórios, atestando a adequabilidade do
protocolo P2PDP frente às exigências apontadas no Capítulo 1 como requisitos
necessários a um protocolo de descoberta de recursos para grades móveis ad hoc,
a saber: (i) reduzir o impacto do problema da implosão de mensagens de resposta
a uma requisição, (ii) minimizar a ocorrência de colisões provocadas pelo
aumento do tráfego de dados no enlace sem fio – em virtude da transmissão de
mensagens do protocolo de descoberta – e (iii) realizar uma distribuição uniforme
das requisições de serviço, promovendo um balanceamento de carga implícito
através da seleção dos dispositivos mais aptos.
6.6.
Avaliação do P2PDP na Presença de Mobilidade
Para avaliar a implementação do protocolo de descoberta P2PDP na presença de
mobilidade, foram definidos cenários dinâmicos, garantindo uma topologia
conexa no instante “0” da simulação.

Avaliação de Desempenho 186
6.6.1.
Composição dos Cenários
Os cenários móveis foram compostos por 40 nós dispostos em uma área de
500 x 500 m 2 , onde a posição de cada nó é definida por um script, criado
especificamente para esse propósito. O primeiro nó é inserido na coordenada
central da área de simulação. O nó seguinte é inserido em uma coordenada
compreendida dentro do raio de transmissão do primeiro nó. No processo de
criação dos nós subseqüentes, um nó é escolhido aleatoriamente entre os nós já
existentes de modo a servir como referência para o posicionamento do novo nó,
esse nó é denominado “nó base”. A aleatoriedade na escolha do nó base é
influenciada pelo parâmetro de seleção, que indica quantas vezes um mesmo nó
pode ser escolhido como nó base. O valor desse parâmetro foi deduzido
empiricamente, sendo configurado como 3, por ser esse o valor que apresentou a
melhor distribuição espacial dos nós.
Um novo nó é inserido na vizinhança do nó base escolhido a uma distância
compreendida entre 0,5 e 0,9 do raio de transmissão desse nó. O valor do raio de
transmissão é configurado como 100 m para todos os nós. É importante destacar
que com a utilização do script para o posicionamento inicial dos nós, o parâmetro
densidade não é mais configurável, sendo determinado de forma variável em
função da escolha do nó base.
A Figura 53 ilustra a topologia inicial de um dos cenários de simulação
gerados para a avaliação do protocolo P2PDP.

Avaliação de Desempenho 187
Figura 53 – Exemplo de distribuição inicial dos dispositivos em um cenário móvel.
6.6.2.
Métrica de Avaliação
Os experimentos com mobilidade visaram, primordialmente, a avaliação da
métrica eficiência da descoberta, que consiste no percentual de vezes, em cada
rodada, em que o iniciador obteve exatamente o número desejado de respostas à
requisição de descoberta. Esses resultados foram obtidos utilizando-se proporção
amostral. A Tabela 11 apresenta os valores dos parâmetros de simulação usados
na constituição das rodadas.
Tabela 11 – Parâmetros de simulação dos cenários com mobilidade.
Parâmetro
Valores
Número de dispositivos (N) 40
Distância média inicial entre dispositivos
50 m ou 90 m
Alcance da transmissão
100 m
Velocidade de deslocamento
0 m/s a 8 m/s
Pausa entre deslocamentos
0 s
Percentual de dispositivos colaboradores ativos (p) 25%
Número de requisições 1
Número máximo de respostas (R) 4

Avaliação de Desempenho 188
Para avaliar a eficiência da descoberta utilizando-se o protocolo P2PDP em
cenários que contemplam a mobilidade, a aplicação M3 (vide Seção 5.4) foi
utilizada, sendo executada no simulador NCTUns, de modo similar ao que foi
descrito na Subseção 5.4.2. Nos cenários de simulação, os dispositivos se
deslocam de acordo com o modelo de mobilidade RWP (Random WayPoint),
assumindo velocidades uniformes no intervalo de [0, 8] m/s, variando em passos
de 1, sem pausas entre os deslocamentos. Cada cenário de simulação foi
executado em cem rodadas, totalizando novecentas execuções. Em cada rodada
um único iniciador foi criado, com 25% dos dispositivos móveis atuando como
colaboradores ativos, ou seja, aptos a responder à requisição de descoberta. Esse
percentual foi escolhido pois, segundo estudos realizados com redes P2P – as
quais, de forma similar às grades móveis, baseiam-se no conceito de colaboração
através do compartilhamento de recursos –, apesar de cerca de 75% dos
dispositivos atuarem como colaboradores ativos, apenas 25% dos dispositivos são
responsáveis por responder a 98% das requisições de descoberta
[Hughes et al. 2005].
6.6.3.
Resultados Obtidos
Os resultados apresentados nesta seção correspondem a proporção amostral dos
resultados coletados, em um total de cem rodadas por cenário de simulação, com
um nível de confiança de 95%. Em nossas simulações, apenas um dispositivo
atuava como iniciador, efetuando uma única requisição de serviço em cada
rodada. A Tabela 12 ilustra os resultados obtidos considerando-se a métrica
eficiência da descoberta.
Tabela 12 – Eficiência da descoberta em função da velocidade de deslocamento.
Velocidade Eficiência da descoberta (%) Intervalo de confiança (%)
0 92 ± 4,13
1 79 ± 7,98
2 58 ± 9,67
3 44 ± 9,73
4 31 ± 9,06
5 24 ± 8,37
6 28 ± 8,80
7 26 ± 8,60
8 15 ± 7,00

Avaliação de Desempenho 189
Com relação aos resultados obtidos, de uma forma geral, é verificada uma
redução da eficiência do protocolo de descoberta inversamente proporcional ao
aumento da velocidade de deslocamento dos dispositivos. O protocolo P2PDP
apresenta um bom desempenho para as velocidades de 0, 1 e 2 m/s, podendo ainda
ser utilizado com as velocidades de 3 e 4 m/s. Com o aumento da velocidade de
deslocamento dos dispositivos, a eficiência do protocolo é consideravelmente
prejudicada. É possível observar um comportamento estatisticamente equivalente
do protocolo P2PDP para as velocidades de 5, 6 e 7 m/s, onde o resultado se
estabiliza em aproximadamente 20-30%, apresentando uma queda mais acentuada
na eficiência da descoberta a partir da velocidade de 8 m/s. Uma hipótese possível
é a de que esse comportamento ocorra em função da área utilizada pelos cenários
de simulação (500 x 500 m 2 ). Em uma área restrita, como a utilizada nesses
experimentos, mesmo com o deslocamento contínuo dos dispositivos, é esperado
que a partir de uma dada velocidade, ao encontrar um obstáculo, os dispositivos
sigam o caminho oposto, o que faz com que eles se cruzem com uma freqüência
maior do que o esperado, apresentando um comportamento semelhante. Em uma
área maior, os dispositivos tendem a se distanciar mais uns dos outros. Entretanto,
para se fazer qualquer afirmação nesse sentido é necessário a realização de novas
rodadas de simulação variando a área utilizada.
O gráfico reproduzido na Figura 54 ilustra os resultados apresentados na
Tabela 12. É importante destacar que o protocolo P2PDP foi concebido tendo
como foco a mobilidade humana. Considerando a eficiência do protocolo de
descoberta P2PDP, a sua utilização é recomendada para o perfil de mobilidade
que se enquadra no intervalo entre as velocidades de [1, 4] m/s, cujos extremos
caracterizam, respectivamente, uma pessoa caminhando lentamente e uma pessoa
correndo.

Avaliação de Desempenho 190
Figura 54 – Eficiência da descoberta: percentual de respostas recebidas em função do
número de respostas solicitadas.
Como se pode observar, para a velocidade de 0 m/s, ou seja, em cenários
estáticos, o protocolo P2PDP não apresenta um percentual de eficiência da
descoberta de 100%, isso se deve a fatores como a ocorrência de colisões, o
retardo máximo tolerado na recepção das mensagens de resposta e a forma como
os dispositivos estão distribuídos. Dependendo do nível de dispersão dos
dispositivos, é normal que, em alguns casos, o posicionamento do iniciador no
cenário de teste, que é definido de forma aleatória, influencie de forma negativa os
resultados obtidos. Caso o iniciador se posicione em algum extremo da área
utilizada na simulação (500 x 500 m 2 ), é possível que o tempo máximo de espera
por respostas definido na requisição de serviço não seja atendido pelos
colaboradores que se encontram nos extremos opostos da área de simulação, o que
provocaria o descarte das mensagens desses colaboradores por atraso.

7
Conclusões
Nesta tese, apresentou-se o projeto, a implementação e a avaliação de desempenho
de um protocolo de descoberta e seleção de recursos para grades móveis ad hoc,
denominado P2PDP (Capítulo 4). O protocolo P2PDP foi desenvolvido no
contexto da arquitetura MoGrid – uma arquitetura de software específica para
grades móveis, aplicável a redes sem fio infra-estruturadas e ad hoc (Capítulo 2) –
como solução para a descoberta e seleção de recursos entre os dispositivos da
grade móvel. O protocolo adota uma abordagem reativa, baseando-se no envio,
sob demanda, de requisições de descoberta por difusão, completamente distribuída
e independente da utilização de qualquer mecanismo de roteamento da MANET,
com as requisições e respostas originadas sob demanda. Com o intuito de reduzir
a implosão de mensagens de resposta, foi proposto o mecanismo de supressão de
respostas por vizinhança, implementado através do algoritmo SbV (Seção 4.6).
Para implementar um mecanismo justo de alocação dos recursos às tarefas na
grade móvel, foi utilizado um mecanismo que classifica as respostas em função da
seleção dos colaboradores mais aptos, implementado através do algoritmo DR,
que introduz um retardo programado no envio de mensagens de resposta (Seção
4.7), promovendo um balanceamento de carga implícito na rede mediante o
aumento do número de requisições. Como resultado indireto da aplicação do
algoritmo DR, foi possível minimizar a ocorrência de colisões, provocadas pelo
aumento do tráfego na grade, proveniente da transmissão de mensagens de
resposta P2PDP.
7.1.
Contribuições da Tese
As principais contribuições alcançadas com o desenvolvimento deste trabalho,
foram classificadas, no Capítulo 1, em duas categorias: (i) contribuições para o
estado da arte na área de descoberta de serviços e (ii) contribuições tecnológicas.

Conclusões 192
Essas contribuições, sumariadas na Seção 1.4, serão revisitadas, em mais detalhes,
nesta seção.
Antes de apresentar as principais contribuições desta tese, é importante
ressaltar o trabalho de pesquisa desenvolvido sobre os protocolos de descoberta de
recursos e serviços para redes de computadores que deu origem a [Lima et al.
2007a]. No estudo desenvolvido, foram avaliados os protocolos propostos para as
redes sem fio ad hoc e as adaptações propostas aos protocolos desenvolvidos para
redes fixas, com o intuito de oferecer suporte às redes sem fio infra-estruturadas.
Esse estudo foi decisivo para a elaboração do Capítulo 3, proporcionando uma
visão ampla das estratégias utilizadas nas mais diferentes propostas de protocolos
de descoberta de serviços para redes sem fio. Essa abordagem permitiu que se
identificassem as necessidades das grades móveis definindo, na Seção 1.2, os
principais requisitos para o projeto de um protocolo de descoberta de serviços
para uma grade móvel ad hoc.
7.1.1.
Contribuições para o Estado da Arte
O desenvolvimento desta tese teve como resultado duas contribuições principais
para o estado da arte na área de descoberta de serviços, a especificação do
protocolo P2PDP e da arquitetura MoGrid, a saber:
• A concepção, implementação e avaliação de desempenho do algoritmo de
supressão de respostas por vizinhança (Suppression by Vicinity – SbV),
que permite tratar o problema da implosão de respostas em protocolos de
descoberta para MANETs, baseados em difusão, utilizando broadcast. O
mecanismo proposto de supressão de respostas por vizinhança mostrou-se
eficaz em controlar o volume de respostas recebido pelo requisitante do
serviço, sem comprometer a qualidade dessas respostas – ou seja,
favorecendo à seleção das respostas dos colaboradores mais aptos. Podese
observar, ainda, que o processamento adicional, gerado pelo
mecanismo de supressão, é distribuído uniformemente entre os
dispositivos da grade móvel, evitando que os vizinhos diretos do
dispositivo requisitante sejam sobrecarregados. Esse comportamento
promove um balanceamento de carga indireto, além de evitar que ocorra

Conclusões 193
um aumento no consumo de energia graças à redução do número de
transmissões de mensagens de descoberta P2PDP. Os resultados
experimentais obtidos, apresentados na Seção 6.2, indicam uma boa
escalabilidade para protocolos de descoberta reativos que adotem o
mecanismo SbV no tratamento de implosão de respostas, como acontece
no P2PDP;
• A concepção, implementação e avaliação de desempenho do algoritmo de
retardo no envio de mensagens de resposta (Delayed Replies – DR), com o
intuito de promover uma seleção entre as respostas que melhor se
adequam às especificidades de uma dada requisição de serviço. A
utilização desse mecanismo produz, como efeito colateral benéfico, a
distribuição uniforme da execução dos serviços entre os colaboradores da
grade móvel, como mostram os resultados obtidos a partir dos
experimentos realizados na rede de teste, apresentados na Seção 6.4. A
análise desses resultados reforça os estudos feitos em [Bolosky et al.
2000], onde a distribuição da utilização de recursos dinâmicos é
caracterizada como bimodal, o que se verifica, por exemplo, com a carga
de CPU, cujos valores alternam entre períodos de utilização total e outros
próximos à inatividade;
• Especificação de um conjunto de requisitos para o desenvolvimento de um
protocolo de descoberta e seleção de recursos em grades móveis ad hoc,
onde os dispositivos se organizam através de uma rede sem fio ad hoc de
saltos múltiplos. Os requisitos do projeto do protocolo de descoberta
levam em consideração as particularidades dos recursos dinâmicos, típicos
dos ambientes de grade móvel. Essa característica foi determinante na
adoção de uma abordagem reativa – baseada na requisição de recursos e
serviços sob demanda –, dada a alta flutuação na disponibilidade dos
recursos dinâmicos, os quais determinam o perfil de execução dos
serviços nos colaboradores P2PDP;
• Definição de uma arquitetura genérica, em camadas, denominada MoGrid,
que serviu de base para o desenvolvimento de um middleware, de mesmo
nome, que trata aspectos relacionados à computação distribuída em grades
móveis. Essas grades são organizadas através de redes sem fio infra-

Conclusões 194
estruturadas e ad hoc, constituídas por grupos de dispositivos sem fio, que
atuam, colaborativamente, para a execução de tarefas. A arquitetura
MoGrid foi concebida de modo a também ser integrável com tecnologias
de grade fixa. Através da abordagem em camadas, a arquitetura oferece
suporte tanto às aplicações cientes da mobilidade, projetadas para utilizar
o middleware MoGrid, quanto às aplicações legadas – típicas dos cenários
de computação paralela – para as quais o uso da arquitetura é transparente.
Em função dessa abordagem, os diferentes mecanismos relacionados à
descoberta (camada de descoberta) e à utilização de serviços (camada de
transparência) – como o protocolo de descoberta e seleção de recursos
P2PDP (Capítulo 4) e o algoritmo de supressão de mensagens de resposta
por vizinhança (Seção 4.6) – são separados, podendo ser utilizados como
módulos independentes, acoplados, inclusive, em outras arquiteturas.
7.1.2.
Contribuições Tecnológicas
Além das contribuições científicas para o estado da arte, foi desenvolvido um
conjunto de artefatos de software para auxiliar o desenvolvimento de aplicações
colaborativas, em grades móveis, baseadas no compartilhamento de recursos e
serviços, a saber:
• Implementação do middleware MoGrid para os ambientes Linux e
Windows XP, utilizando a linguagem de programação Java [Sun 1994;
Sun 1999b], oferecendo suporte à mobilidade, através de um mecanismo
descentralizado de descoberta e compartilhamento de recursos para a
execução distribuída de tarefas em uma grade móvel;
• Implementação do protocolo de descoberta P2PDP para os ambientes
Linux e Windows XP, utilizando a linguagem de programação Java
[Sun 1994; Sun 1999b]. A seleção dos dispositivos que irão colaborar na
provisão de serviços foi realizada pela implementação de dois algoritmos
distribuídos, citados nas contribuições para o estado da arte (SbV e DR);
• Implementação de um proxy de colaboração com a funcionalidade de
permitir o acesso de dispositivos sem fio aos serviços e recursos
disponíveis em uma grade fixa, implantada sobre a plataforma Globus

Conclusões 195
Toolkit 2.4 [Foster & Kesselman 1997]. O proxy MoGrid é responsável
pela tradução de protocolos entre a grade fixa e a grade móvel. Os
recursos da grade fixa são identificados pelo proxy MoGrid – através do
serviço Globus MDS (Monitoring and Discovery System) –, após o seu
credenciamento na grade fixa, e, a partir daí, podem ser descobertos pelos
dispositivos que compõem a grade móvel, através do protocolo P2PDP;
• Desenvolvimento de uma ferramenta que incorpora um gerenciador de
simulações de rede para o ns-2 [ISI 1995], baseado nas camadas de
descoberta e acesso aos recursos disponibilizadas pelo middleware
MoGrid, responsável por disparar as rodadas de simulação de forma
paralela e executar o pós-processamento dos resultados obtidos em cada
rodada. A ferramenta, denominada nsTOOL (ns dispaTcher and pOstprOcessing
Launcher), oferece uma interface gráfica e uma interface
textual, para facilitar a automatização do processo de submissão de
múltiplos cenários de simulação para os dispositivos da grade móvel aptos
a colaborar. Essa ferramenta também pode ser utilizada em conjunto com
o proxy de colaboração permitindo que as rodadas de simulação da grade
móvel sejam executadas por dispositivos na grade fixa, que são mais ricos
em recursos se comparados aos dispositivos sem fio da grade móvel.
7.2.
Trabalhos Futuros
Existem alguns aspectos sobre os quais vislumbra-se a necessidade de futuras
adaptações na especificação e implementação do protocolo P2PDP e da
arquitetura MoGrid. A seguir, esses aspectos são apresentados como sugestões de
pesquisas futuras.
7.2.1.
Arquitetura MoGrid
Nesta subseção são discutidas algumas frentes de pesquisa que podem ser
investigadas, dando continuidade ao desenvolvimento da arquitetura MoGrid.
Para prover suporte ao gerenciamento das desconexões involuntárias, é
necessário que a especificação da camada de transparência da arquitetura MoGrid

Conclusões 196
seja concluída. Apesar dos esforços em se efetuar um levantamento preliminar dos
requisitos e funcionalidades da camada de transparência (vide Subseção 2.3.2),
muitos aspectos relacionados a essa camada ainda precisam ser investigados,
sendo necessário um esforço considerável no sentido de prover uma especificação
dos módulos que a constituem. Em uma etapa subseqüente, deve-se analisar os
requisitos especificados para a camada de transparência com o objetivo de definir
o projeto, a implementação e a avaliação de um outro protocolo – complementar
ao P2PDP – no âmbito dessa camada – o protocolo TRAP (Transparent Resource
Access Protocol) –, de modo a estabelecer um padrão de comunicação entre as
entidades de descoberta na fase de acesso e utilização dos recursos recémdescobertos.
Na arquitetura MoGrid, a entidade proxy de colaboração pode corresponder
tanto a um dispositivo fixo com uma interface sem fio, que lhe permite se
comunicar com os dispositivos da grade móvel, quanto a um dispositivo sem fio
que se conecta temporariamente à grade fixa, através de uma rede sem fio infraestruturada.
No primeiro caso, o perfil de execução da entidade proxy não
influenciará na qualidade das respostas que ele gera em nome dos dispositivos da
grade fixa, entretanto, no segundo caso, o perfil de execução da entidade proxy
deve ser considerado no cálculo da adequação desses dispositivos (vide Equação
(2) na Seção 4.7), dado que, como o tempo de execução de uma tarefa pode ser
longo – como ocorre com as aplicações de grade de processamento intensivo –, é
grande a chance do proxy, ou da grade móvel como um todo, se mover e tornar
impossível a obtenção dos resultados gerados pelos colaboradores da grade fixa.
Ainda em relação ao proxy de colaboração, aspectos relacionados à segurança são
especialmente relevantes na integração das grades móveis com as grades fixas,
sendo necessária a autenticação dos usuários móveis na grade fixa, o que deve ser
incorporado em versões futuras da arquitetura MoGrid.
7.2.2.
Incorporação de Novos Mecanismos ao Protocolo P2PDP
Nesta subseção é discutida a possibilidade de incorporar alguns mecanismo
adicionais ao protocolo P2PDP com a finalidade de introduzir novas

Conclusões 197
funcionalidades que, em alguns casos, resultam na ampliação do seu escopo de
aplicação.
O protocolo P2PDP utiliza um modo de encaminhamento de requisições
baseado em inundação por broadcast, delimitado em função do diâmetro da
requisição – número de saltos que a mensagem pode trafegar. Nessa abordagem,
denominada broadcast limitado, as requisições são encaminhadas através de
inundação, com todos os nós dentro do diâmetro especificado recebendo as
requisições de descoberta. Caso os nós intermediários, responsáveis pelo
encaminhamento das requisições, armazenassem algum tipo de informação sobre
os serviços disponíveis na sua vizinhança – como, por exemplo, através do
armazenamento das respostas que passam por esses nós –, algum tipo de filtragem
poderia ser efetuada no roteamento dessas requisições, evitando que elas fossem
disseminadas em regiões onde o serviço solicitado não vem sendo oferecido há
algum tempo. O modo de encaminhamento por broadcast limitado, implementado
no P2PDP, poderia ser incrementado, utilizando-se abordagens que fazem o
encaminhamento seletivo das mensagens de requisição de serviço. Em
[Chakraborty et al. 2006], o encaminhamento das requisições é feito com base na
informação sobre os grupos de serviço aos quais o serviço pertence, o que permite
a obtenção de resultados aproximados. Por exemplo, se uma requisição especifica
um serviço que possa ser executado em sistemas baseados em um processador de
uma determinada família (por exemplo, Intel Pentium) e uma instância desse
serviço, compatível com sistemas baseados nessa família, for descoberta, um
resultado aproximado é encontrado. Nessa abordagem, ao receber uma requisição,
o nó verifica a informação sobre o(s) grupo(s) do serviço solicitado e tenta validála
com as informações de grupo na sua vizinhança, encaminhando a requisição
somente aos nós que disponibilizam informações sobre o(s) grupo(s) em questão.
Já na abordagem FTA [Lenders et al. 2005], o critério de encaminhamento de
requisições se baseia na distância da rede – calculada em função do número de
saltos entre o cliente e os possíveis provedores de serviço – e na capacidade do
serviço (CoS), divulgada periodicamente por cada nó na sua vizinhança.
A arquitetura MoGrid prevê, em sua API, uma operação para anúncio das
informações de serviços na grade móvel. Um trabalho interessante seria
incorporar, ao protocolo P2PDP, um mecanismo de descoberta proativo – baseado

Conclusões 198
no envio periódico de anúncios contendo informações sobre os recursos e serviços
disponíveis na grade –, o que implicaria na análise de técnicas para gerenciar o
armazenamento dessas informações em cada dispositivo. A adição de mecanismos
de anúncio, mais especificamente anúncio incremental [Lee et al. 2003] – que
corresponde ao delta da visão do dispositivo em relação à visão global da rede –,
pode se mostrar eficaz caso se deseje ampliar o escopo de atuação do protocolo
P2PDP para a descoberta de recursos e serviços específicos, associados aos
recursos estáticos, os quais não apresentam tantas variações em sua
disponibilidade quanto os recursos dinâmicos tratados em uma grade móvel. Com
a implementação dessa abordagem, o uso do protocolo P2PDP continuaria
contemplando as grades móveis ad hoc, mas não se restringiria apenas a esse
ambiente, podendo oferecer suporte à descoberta de serviços em qualquer tipo de
rede que se caracterize pela mobilidade dos nós que a constituem.
Na especificação atual do P2PDP, a descrição dos recursos é feita através da
implementação de uma interface comum Java, denominada ServiceDescription.
Uma abordagem que pode ser implementada é a incorporação de uma linguagem
de descrição de recursos, baseada em XML, para prover maior flexibilidade e
poder de expressão à descrição de recursos e serviços no protocolo P2PDP, o que
seria refletido no algoritmo de matching. Os protocolos propostos em [Lee et al.
2003; Chakraborty et al. 2005; Chakraborty et al. 2006] seguem essa abordagem,
utilizando linguagens de descrição semântica baseadas em ontologias, o que,
segundo análise realizada pelos autores, garante uma maior eficiência no
algoritmo de matching.
Por fim, os cenários de simulação utilizados consideraram dispositivos com
mobilidade moderada, deslocando-se a velocidades no intervalo [0, 4] m/s,
reproduzindo a mobilidade humana. Em cenários envolvendo topologias
altamente dinâmicas, o conceito de caminho de retorno – usado pelas mensagens
de resposta – pode falhar, por exemplo, se algum dispositivo, no caminho, se
afastar do mesmo. Nesse sentido, é interessante investigar mecanismos que
permitam o uso alternativo de protocolos de roteamento reativos para MANETs –
como, por exemplo, o AODV [Perkins et al. 2003] – quando é detectada uma
falha no caminho de retorno, utilizado para o encaminhamento da mensagem de
resposta, em direção ao nó que originou a requisição.

Conclusões 199
7.2.3.
Otimização de Mecanismos do Protocolo P2PDP
Nesta subseção são discutidos alguns aspectos referentes à implementação atual
do protocolo P2PDP que podem ser modificados com o objetivo de torná-lo mais
adaptativo em resposta às constantes alterações verificadas tanto nas condições e
topologia da rede sem fio quanto na disponibilidade de recursos dos dispositivos
móveis.
Analisando os protocolos de descoberta de recursos e serviços sob a
perspectiva das arquiteturas de QoS [Bharghavan et al. 1998; Lima 2002;
Bellavista et al. 2003], os mesmos podem ser comparados, em muitos aspectos,
aos protocolos de reserva de recursos, usuais na provisão de serviços com QoS.
Por essa razão, é válida a análise de alguns trabalhos representativos dessa área
que possam auxiliar na especificação de um mecanismo mais elaborado para
efetuar reservas antecipadas de recursos. Esse mecanismo incluiria o tratamento
de underbooking, ou seja, situação que pode acontecer se os colaboradores
reservam recursos que não serão utilizados – o que se deve ao fato da resposta do
colaborador ser suprimida antes que ela possa chegar até o nó que originou a
requisição. Embora a reserva efetuada seja temporária, pois a sua validade está
associada ao período que determina o tempo de vida da requisição pendente,
armazenada em uma estrutura de dados local do dispositivo, ela pode causar
impacto no processamento de requisições concorrentes, impedindo que um
colaborador apto possa responder a uma requisição de descoberta em tempo hábil.
Na implementação atual do protocolo P2PDP, a adequação de uma entidade
colaborador é calculada levando-se em conta somente o seu perfil de execução,
sem considerar o perfil de execução dos dispositivos na sua vizinhança. Em
[Lenders et al. 2005] as requisições de serviço são encaminhadas na direção do
dispositivo mais apto a oferecer o serviço levando em consideração o seu
potencial como provedor, que é calculado em função da capacidade de cada
provedor da rede oferecer o serviço, informação que é disseminada
periodicamente por broadcast. Em uma grade móvel é comum a interconexão de
dispositivos heterogêneos, com capacidades de hardware distintas, desse modo, a
avaliação dos percentuais de disponibilidade de recursos de forma isolada, em
cada dispositivo, pode prejudicar a qualidade dos resultados obtidos através do

Conclusões 200
mecanismo de seleção. É necessário avaliar o quanto essa abordagem pode
impactar na provisão de balanceamento de carga, proporcionada pelo mecanismo
de seleção, e investigar soluções alternativas, de modo a estender o mecanismo
atualmente em uso. Um outro ponto que advém dessa discussão é a adição de um
parâmetro que identifique o perfil do dispositivo no cálculo de sua adequação
(vide Equação (2) na Seção 4.7). A título de ilustração, 80% de 16 Mb de espaço
em disco de um PDA é bem inferior a 10% de 80 Gb de um notebook, por
exemplo. Ainda nessa linha de argumentação, os colaboradores de uma grade fixa,
introduzidos na grade móvel através da entidade proxy de colaboração, devem ter
as suas respostas privilegiadas na seleção em relação aos dispositivos portáteis por
apresentarem, apenas para mencionar alguns itens, um nível de conectividade
relativamente constante e fonte de energia ilimitada (considerando-se o uso de nobreaks).
É importante investigar a influência do parâmetro maxReplyDelay na
eficiência do mecanismo de supressões. O ajuste desse parâmetro de forma
dinâmica – por exemplo, em função do retardo de transferência das mensagens –
pode auxiliar a reduzir o tempo de descoberta sem aumentar o número de colisões
de respostas. Ainda nesse contexto, vale ressaltar a importância de se estudar o
impacto da diferença de velocidade dos relógios dos dispositivos nos mecanismos
de temporização implementados.
Em função da variação na disponibilidade de recursos nos dispositivos sem
fio, provocada pela execução de tarefas da grade móvel e do consumo de recursos
gerado por demandas locais, o valor do parâmetro ω – que indica a disposição do
nó colaborador em participar da provisão do serviço da grade móvel – pode ser
alterado, de forma adaptativa, em tempo de execução. A sintonização automática
do valor de ω possibilitaria que a carga de processamento do dispositivo fosse
considerada também na decisão de participar ou não da execução de tarefas na
grade móvel, sem a necessidade de constante intervenção do usuário da aplicação.
ω poderia ser adaptado, por exemplo, em função de valores limites, definidos pelo
usuário do dispositivo, que determinariam a sua tolerância em relação aos níveis
de utilização de seus recursos, para que o dispositivo continuasse atuando como
um colaborador ativo na grade. Um usuário poderia restringir a sua colaboração,

Conclusões 201
por exemplo, caso a carga residual da bateria atingisse 50% e a carga de
processamento ultrapassasse 60% de utilização.
7.3.
Considerações Finais
Esta tese é concluída oferecendo diversas oportunidades a serem exploradas,
apontando diferentes perspectivas de pesquisa relacionadas à área de descoberta e
seleção de recursos e serviços em grades móveis. Além disso, foram levantados
um conjunto de requisitos de projeto para auxiliar a especificação e o
desenvolvimento de uma camada de acesso transparente aos recursos e serviços da
grade móvel, que, por si só, representam uma área de pesquisa relevante, que
merece ser investigada mais atentamente.

8
Referências Bibliográficas
AKOGRIMO Consortium: Access to Knowledge through the Grid in a Mobile
World. European FP6-IST Project, Number FP6-2004-IST-2-004293. 2004 –
2007. Disponível em: . Acesso em: 01 fev. 2007.
ANGLUIN, D.; FISCHER, M.J.; JIANG, H. Stabilizing Consensus in Mobile
Networks. In: Proceedings of Distributed Computing in Sensor Systems:
Second IEEE International Conference, Lecture Notes in Computer Science,
Springer-Verlag. 2006. Volume 4026, p. 37-50.
BELLAVISTA, P.; CORRADI, A.; MONTANARI, R.; STEFANELLI, C.
Dynamic Binding in Mobile Applications, a Middleware Approach. In: IEEE
Internet Computing, 2003. Volume 7, Issue 2, p. 34-42.
BERNERS-LEE, T.; HENDLER, J.; LASSILA, O. The Semantic Web. In:
Scientific American, 2001. Volume 284, Number 5, p. 34-43.
BHARGHAVAN, V.; LEE, Kang-Won; LU, Songwu; HA, Sungwon; LI, Jin-Ru;
DWYER, D. The TIMELY Adaptive Resource Management Architecture. In:
IEEE Personal Communications Magazine, 1998. Volume 5, Issue 4, p. 20-31.
BHATIA, K. Peer-To-Peer Requirements on the Open Grid Services Architecture
Framework, GFD.49, GGF Document Series, OGSA P2P Research Group. 2005.
BOLOSKY, W. J.; DOUCEUR, J. R.; ELY, D.; THEIMER, M. Feasibility of a
Serverless Distributed File System Deployed on an Existing Set of Desktop PCs.
In: Proceedings of the 2000 ACM SIGMETRICS international Conference on
Measurement and Modeling of Computer Systems (Santa Clara, California,
United States). ACM Press, New York. 2000. p. 34-43. ISBN 1-58113-194-1.
BLUETOOTH CONSORTIUM. Specification of the Bluetooth System, v. 1.1
core. 2001. Disponível em: . Acesso em: 01 fev. 2007.
BLUETOOTH .ORG. What´s in a name The story of Bluetooth. 2003.
Disponível em: .
Acesso em: 01 fev. 2007.
CARTER, C.; YI, S.; RATANCHANDANI, P.; KRAVETS, R. Manycast:
exploring the space between anycast and multicast in ad hoc networks. In
Proceedings of the 9th Annual international Conference on Mobile
Computing and Networking, San Diego, CA, USA, 2003. ACM Press, New
York, p. 273-285. ISBN 1-58113-753-2.
CHAKRABORTY, D.; JOSHI, A.; FININ, T.; YESHA, Y. GSD: A Novel Groupbased
Service Discovery Protocol for MANETS. In: 4 th IEEE Conference on
Mobile and Wireless Communications Networks. 2002.

Referências Bibliográficas 203
CHAKRABORTY, D.; JOSHI, A.; FININ, T.; YESHA, Y. Service Composition
for Mobile Environments. In: Mobile Networks and Applications. 2005.
Volume 10, Issue 4, p. 435-451.
CHAKRABORTY, D.; JOSHI, A.; YESHA, Y.; FININ, T. Toward Distributed
Service Discovery in Pervasive Computing Environments. In: IEEE
Transactions on Mobile Computing. 2006. Volume 5, Issue 2, p. 97-112.
CHO, C.; LEE, D. Survey of Service Discovery Architectures for Mobile Ad
hoc Networks. Term Paper, Computer and Information Science and Engineering
Department, University of Florida. Gainesville, 2005.
CHOW, R.; JOHNSON, T. Distributed Operating Systems and Algorithms,
Addison Wesley, 1997.
CoG. Java CoG Kit. 1997. Disponível em: . Acesso em:
10 fev. 2007.
CONTI, M.; MASELLI, G.; TURI, G.; GIORDANO, S. Cross-layering in mobile
ad hoc network design. In: IEEE Computer, 2004. Volume 37, Issue 2, p. 48-51.
CZAJKOWSKI, K.; FOSTER, I.; KESSELMAN. C. Resource and service
management. In: I. Foster and C. Kesselman, editors, The Grid 2: Blueprint for
a New Computing Infrastructure, Morgan Kaufmann Publishers, Second
Edition, New York, 2004.
DUFFIELD, N.G.; GROSSGLAUSER, M.; RAMAKRISHNAN, K.K. Distrust
and Privacy: Axioms for Multicast Congestion Control. In: Proc. 9 th
International Workshop on Network and Operating Systems Support for
Digital Audio and Video. 1999.
EDWARDS, W.K. Discovery Systems in Ubiquitous Computing. In: IEEE
Pervasive Computing. 2006. Volume 5, Number 2, p. 70-77.
ENGELSTAD, P.E.; ZHENG, Y.; KOODLI, R.; PERKINS, C.E. Service
Discovery Architectures for On-Demand Ad Hoc Networks. In: International
Journal of Ad Hoc Sensor Wireless Networks, Old City Publishing (OCP
Science), 2006. Volume 2, Number 1, p. 27-58.
FARKAS, K.; RUF, L.; MAY, M.; PLATTNER, B. Framework for Service
Provisioning in Mobile Ad Hoc Networks. In: Proceedings of the First
International Conference on Telecommunications and Computer Networks,
San Sebastian, Spain, 2004.
FAROOQ, U.; KHALIL, W. A Generic Mobility Model for Resource Prediction
in Mobile Grids. In: International Symposium on Collaborative Technologies
and Systems. 2006. ISBN 0-9785699-0-3. p. 189-193.
FOSTER, I. The Grid: A new infrastructure for the 21 st century science. In: Grid
Computing: Making the Global Infrastructure a Reality. John Wiley & Sons
Ltd. 2003. p. 51-63. ISBN 978-0-470-85319-1. Disponível em:
. Acesso em: 10 fev. 2007.
FOSTER, I., KESSELMAN, C. Globus: A Metacomputing Infrastructure Toolkit.
In: International Journal of Supercomputer Applications and High
Performance Computing, 1997. Volume 11, Number 2, p. 115-128.

Referências Bibliográficas 204
FOX, G.; GANNON, D.; KO, S.; LEE, S.; PALLICKARA, S.; PIERCE, M.;
QIU, X.; RAO, X.; UYAR, A.; WANG, M.; WU, W. Peer-to-peer Grids. In:
Berman, F., Fox, G., Hey, T., eds.: Grid Computing - Making the Global
Infrastructure a Reality. John Wiley & Sons Ltd. 2003. p. 471-490.
FRANK, C.; KARL, H. Consistency challenges of service discovery in mobile ad
hoc networks. In: Proceedings of the 7 th ACM international Symposium on
Modeling, Analysis and Simulation of Wireless and Mobile Systems, Venice,
Italy (ACM Press, New York, NY), 2004. p. 105-114.
GEYER, C.F.R.; DA SILVA, L.C.; YAMIN, A.C.; AUGUSTIN, I.; FILHO,
A.E.S.; MORAES, M.C.; REAL, R.A.; FRAINER, G.C.; PIRES, R.P. GRADEp:
Towards Pervasive Grid Executions. In: III Workshop de Grade
Computacional e Aplicações. Rio de Janeiro, 2005.
GNU. GAWK: Effective AWK Programming: A User’s Guide for GNU Awk, 3 rd
Edition, Free Software Foundation, Inc. 1989-2003. Disponível em:
. Acesso em: 20 fev.
2007.
GNUTELLA. 2005. Disponível em: . Acesso em: 01
fev. 2007.
GOMES, A.T.A.; ZIVIANI, A.; LIMA, L.S.; ENDLER, M. DICHOTOMY: A
Resource Discovery and Scheduling Protocol for Multihop Ad hoc Mobile Grids.
In: 1st International Workshop on Context-Awareness and Mobility in Grid
Computing, co-located with IEEE CCGrid 2007. Rio de Janeiro, 2007.
GONZALEZ-CASTILLO, J.; TRASTOUR, D.; BARTOLINI, C. Description
Logics for Matchmaking Services. In: Proceedings of the Workshop on
Applications of Description Logics at KI-2001. Vienna, Austria, 2001.
GUTTMAN, E. Service Location Protocol: Automatic Discovery of IP Network
Services. In: IEEE Internet Computing. 1999. Volume 3, Number 4, p. 71-80.
HARBIRD, R.; HAILES, S.; MASCOLO, C. Adaptive Resource Discovery for
Ubiquitous Computing. In: Proceedings of 2 nd Workshop on Middleware for
Pervasive and Ad-Hoc Computing. 2004. Volume 77, p. 155-160.
HELAL, S.; DESAI, N.; VERMA, V.; LEE, C. Konark – A Service Discovery
and Delivery Protocol for Ad hoc Networks. In: Proceedings of the Third IEEE
Conference on Wireless Communication Networks. New Orleans, 2003.
HERMANN, R.; HUSEMANN, D.; MOSER, M.; Nidd, M.; ROHNER, C.;
SCHADE, A. DEAPspace – Transient Ad hoc Networking of Pervasive Devices.
In: Computer Networks. 2001. Volume 35, Issue 4, p. 411-428.
HUBAUX. J.-P.; GROSS, T., LE BOUDEC, J.-Y.; VETTERLI, M. Toward Self-
Organized Mobile Ad Hoc Networks: The Terminodes Project. In: IEEE
Communications, 2001. Volume 39, Number 1, p. 118-124.
HUGHES, D.; COULSON, G.; WALKERDINE, J. Free Riding on Gnutella
Revisited: The Bell Tolls In: IEEE Distributed Systems Online. 2005. Volume
6, Issue 6. DOI 10.1109/MDSO.2005.31.
HWANG, J.; ARAVAMUDHAM, P. Middleware Services for P2P Computing in
Wireless Grid Networks. In: IEEE Internet Computing. 2004. Volume 8,
Number 4, p. 40-46.

Referências Bibliográficas 205
IERUSALIMSCHY, R.; de FIGUEIREDO, L.H.; CELES W. Lua 5.1 Reference
Manual. Lua.org, 2006. ISBN 85-903798-3-3.
IHSAN, I.; QADIR, M.A.; IFTIKHAR, N. Mobile Ad-Hoc Service Grid –
MASGRID. In: Transactions on Engineering, Computing and Technology,
World Enformatika Society. 2005. ISBN 975-98458-4-9. Volume 5, pp 124-127.
INTEGRIDADE Project. 2003. Disponível em: .
Acesso em: 01 abr. 2007.
ISI – Information Sciences Institute. The Network Simulator – ns-2. 1995 –
2007. Disponível em: . Acesso em: 01 fev. 2007.
KLEMM, A.; LINDEMANN, C.; WALDHORST, O.P. A Special-Purpose Peerto-Peer
File Sharing System for Mobile Ad Hoc Networks. In: Proceedings of
IEEE Semiannual Vehicular Technology Conference, Orlando, FL. 2003.
ISBN 0-7803-7954-3.
KOODLI, R.; PERKINS, C.E. Service Discovery in on-demand Ad Hoc
Networks. In: IETF Internet Draft (expired). 2002.
KURKOVSKY, S.; BHAGYAVATI, R.A.; YANG, M. Modeling a Grid-Based
Problem-Solving Environment for Mobile Devices. In: Proceedings of the IEEE
International Conference on Information Technology: Coding and
Computing. Las Vegas, USA, 2004. ISBN: 0-7695-2108-8.
K*Grid Project. 2002-2006. Disponível em: . Acesso em: 01 fev. 2007.
LEE, C.; HELAL, A.; DESAI, N.; VERMA, V.; ARSLAN, B. Konark: A System
and Protocols for Device Independent, Peer-to-Peer Discovery and Delivery of
Mobile Services. In: Systems, Man and Cybernetics, Part A, IEEE
Transactions. 2003. Volume 33, Issue 6, p. 682- 696.
LENDERS, V; MAY, M.; PLATTNER, B. Service discovery in mobile ad hoc
networks: A field theoretic approach. In: Sixth IEEE International Symposium
on a World of Wireless Mobile and Multimedia Networks. 2005. p. 120-130.
ISBN 0-7695-2342-0.
LIMA, L. dos S. Um Framework para Provisão de QoS em Redes Móveis Sem
fio. Dissertação de Mestrado. Departamento de Informática. Pontifícia
Universidade Católica do Rio de Janeiro. 2002.
LIMA, L. dos S. Grades sem Fio: Desenvolvendo Aplicações para o
Compartilhamento de Recursos e Informações. Relatório Técnico. Departamento
de Informática. Pontifícia Universidade Católica do Rio de Janeiro. 2005. .
LIMA, L. dos S.; GOMES, A.T.A.; ZIVIANI, A.; ENDLER, M.; SCHULZE, B.;
SOARES, L.F.G. Peer-to-Peer Resource Discovery in Mobile Grids. In:
Proceedings of 3 rd International Workshop on Middleware for Grid
Computing. 2005. ACM 1-59593-269-0/05/11.
LIMA, L. dos S.; GOMES, A.T.A.; ZIVIANI, A.; ENDLER, M. Descoberta de
Serviços em Redes de Computadores (minicurso). In: XXV Simpósio Brasileiro
de Redes de Computadores. Belém, PA, Brasil, 2007.

Referências Bibliográficas 206
LIMA, L. dos S.; GOMES, A.T.A.; ZIVIANI, A.; FRANÇA, P.A.; BASTOS,
B.F.; ENDLER, M. Reduzindo a Implosão de Respostas em Protocolos de
Descoberta de Serviços para Redes sem fio Ad hoc de Saltos Múltiplos. In: XXV
Simpósio Brasileiro de Redes de Computadores. Belém, PA, Brasil, 2007.
LITKE, A.; SKOUTAS, D.; VARVARIGOU, T. Mobile Grid Computing:
Changes and Challenges of Resource Management in a Mobile Grid Environment.
In: International Conference on Practical Aspects of Knowledge
Management. 2004.
MACÊDO, R.J.A.; LIMA, G.M.; BARRETO, L.P.; ANDRADE, A.M.S.;
BARBOZA, F.J.R.; SÁ, A.; ALBUQUERQUE, R.; ANDRADE, S. Tratando a
Previsibilidade em Sistemas de Tempo-real Distribuídos: Especificação.
Linguagens, Middleware e Mecanismos Básicos (minicurso). In: XXII Simpósio
Brasileiro de Redes de Computadores. Gramado, RS, Brasil, 2004.
MARIN-PERIANU, R.S.; HARTEL, P.; SCHOLTEN, H. A Classification of
Service Discovery Protocols, Technical Report TR-CTIT-05-25, Centre for
Telematics and Information Technology, University of Twente. Enschede, 2005.
ISSN 1381-3625.
MCKNIGHT, L.W.; HOWISON, J. Towards a Sharing Protocol for Wireless
Grids. In: International Conference on Computing, Communication and
Control Technologies. Orlando, Florida, 2003.
MCKNIGHT, L.W.; HOWISON, J.; BRADNER, S. Wireless grids: Distributed
resource sharing by mobile, nomadic, and fixed devices. In: IEEE Internet
Computing. 2004. Volume 8, Number 4, p. 24-31.
MIAN, A.N.; BERALDI, R.; BALDONI, R. Survey of Service Discovery
Protocols in Mobile Ad Hoc Networks, Technical Report 4/06, Dipartimento di
Informatica e Sistemistica “Antonio Ruberti”, Università degli Studi di Roma “La
Sapienza”. Rome, Italy, 2006.
MILOJICIC, D.S.; DOUGLIS, F.; PAINDAVEINE, Y.; WHEELER, R.; ZHOU,
S. Process Migration. In: ACM Computing Surveys. 2000. Volume 32, Number
3, p. 241-299.
NAPSTER. 2005. Disponível em: . Acesso em 01 fev.
2007.
NI, S.-Y.; TSENG, Y.-C.; CHEN, Y.-S.; SHEU, J.-P. The Broadcast Storm
Problem in a Mobile Ad hoc Network. In: Proceedings of the 5th Annual
ACM/IEEE International Conference on Mobile Computing and
Networking, ACM Press. New York, NY, USA, 1999. p. 151-162.
NIDD, M. Service Discovery in DEAPspace. In: IEEE Personal
Communications. 2001. Volume 8, Number 4, p. 39-45.
OMG. UML Notation Guide (version 2.0). Rational Software Corporation.
Object Management Group. 2005. Disponível em: .
Acesso em: 10 fev. 2007.
PEDDERMORS, A.; ZANDBELT, H.; BARGH, M. A Mechanism for Host
Mobility Management supporting Application Awareness. In: Proceedings of the
2nd international conference on Mobile systems, applications, and services,
ACM Press. Boston, USA, 2004. ISBN 1-58113-793-1.

Referências Bibliográficas 207
PERKINS, C.; BELDING-ROYER, E.; DAS, S. Ad hoc On-Demand Distance
Vector (AODV) Routing, IETF RFC 3561. 2003.
P-GRID Project. 2002 – 2007. Disponível em: . Acesso
em: 01 fev. 2007.
PHAN, T.; HUANG, L.; DULAN, C. Challenge: Integrating Mobile Wireless
Devices into the Computational Grid. In: Proceedings of the 8 th ACM
International Conference on Mobile Computing and Networking. 2002.
RAMAN, B.; BHAGWAT, P.; SESHAN, S. Arguments for cross-layer
optimizations in bluetooth scatternets. In: Proceedings of Symposium on
Applications and the Internet. San Diego, California, USA, 2001. p. 176-184.
ISBN 0-7695-0942-8.
RATSIMOR, O.; CHAKRABORTY, D.; JOSHI, A.; FININ, T. Allia: Alliancebased
Service Discovery for Ad hoc Environments. In: Proceedings ACM
Mobile Commerce Workshop. 2002.
RATSIMOR, O.; CHAKRABORTY, D.; JOSHI, A.; FININ, T.; YESHA, Y.
Service Discovery in Agent-Based Pervasive Computing Environments. In:
Mobile Networks and Applications. 2004. Volume 9, Issue 6, p. 679- 692,
Disponível em: .
Acesso em: 01 fev. 2007.
RED HERRING. Startup Takes on the Home: Wireless Grid promises to
transform home networking with P2P-like technology. 2005. Disponível em:
. Acesso em: 01 fev. 2007
RHEINGOLD, H. The Evolution of Reputation. In: Smart Mobs (the next social
revolution), Perseus Publishing, 2003. p. 113-132. Disponível em:
. Acesso em: 20 fev. 2007.
RICHARD III, G.G. Service Advertisement and Discovery Enabling Universal
Device Cooperation. In: IEEE Internet Computing. 2000. Volume 4, Number 5,
p. 18-26.
SACRAMENTO, V.; ENDLER, M.; RUBINSZTEJN, H.K.; LIMA, L. dos S.;
GONÇALVES, K.; NASCIMENTO, F.N.; BUENO, G.A. MoCA: A Middleware
for Developing Collaborative Applications for Mobile Users. In: IEEE
Distributed Systems Online. 2004. Volume 5, Number 10.
SALUTATION Consortium Inc. Salutation Architecture Specification [site
desativado]. 1999.
SAROIU, S.; GUMMADI, P.K.; GRIBBLE, S.D. A Measurement Study of Peerto-Peer
File Sharing Systems. In: Proceedings of the Multimedia Computing
and Networking Conference. San Jose, CA, USA, 2002. p. 156-170.
SENO, S.A.H; BUDIARTO, R.; WAN, T.-C. Survey and new Approach in
Service Discovery and Advertisement for Mobile Ad hoc Networks. In:
International Journal of Computer Science and Network Security, 2007.
Volume 7, Number 2, p. 275-284.
SHAKKOTTAI, S.; RAPPAPORT, T.S.; KARLSSON, P.C. Cross-layer design
for wireless networks. In: IEEE Communications Magazine, Texas University,
Austin, TX, USA, 2003. Volume 41, Issue 10, p. 74-80.

Referências Bibliográficas 208
SMITH, W.; FOSTER, I.; TAYLOR, V. Scheduling with advance reservations.
In: IEEE International Parallel and Distributed Processing Symposium. 2000.
p. 127-132.
STUTZBACH, D.; REJAIE, R. Understanding churn in peer-to-peer networks. In:
Proceedings of the 6th ACM SIGCOMM on Internet Measurement. Rio de
Janeiro, Brazil, 2006. ACM Press, New York, p. 189-202.
STRANG, T. Service Discovery Protocols. In: Lecture Ubiquitous Computing.
2005. Disponível em: . Acesso em: 01 fev. 2007.
SUN Microsystems. Java Platform, Standard Edition (J2SE). 1994 – 2007.
Disponível em: . Acesso em: 01 fev. 2007.
SUN Microsystems. Jini Technology. 1999a. Disponível em:
. Acesso em: 01 fev. 2007.
SUN Microsystems. Java 2 Micro Edition Technology for Creating Mobile
Devices (J2ME). 1999b – 2007. Disponível em: .
Acesso em: 01 fev. 2007.
TANGMUNARUNKIT, H.; DECKER, S.; KESSELMAN, C. Ontology-based
Resource Matching in the Grid – The Grid meets the Semantic Web. In:
Proceedings of the Second International Semantic Web Conference. Sanibel-
Captiva Islands, Florida, USA, 2003.
TSENG, Y.-C.; NI, S.-Y.; SHIH, E.-Y. Adaptive Approaches to Relieving
Broadcast Storms in a Wireless Multihop Mobile Ad Hoc Network. In: IEEE
Transactions on Computers. 2003. Volume 52, Number 5, p. 545-557.
TYAN, J.; MAHMOUD, Q.H. A Comprehensive Service Discovery Solution for
Mobile Ad Hoc Networks. In: Mobile Networks and Applications, 2005.
Volume 10, Issue 4, p. 423-434.
UPnP Forum. 2000. Disponível em: . Acesso em: 01 fev.
2007.
VARSHAVSKY, A.; REID, B.; de LARA, E. A Cross-Layer approach to Service
Discovery and Selection in MANETs. In: Proceedings of 2 nd IEEE
International Conference on Mobile Ad hoc and Sensor Systems. 2005. ISBN
0-7803-9465-8.
WANG, S.Y; LIN, Y.B. NCTUns Network Simulation and Emulation for
Wireless Resource Management. In: Wiley Wireless Communications and
Mobile Computing. 2005. Volume 5, Issue 8, p. 899-916.
WOLF, L.; DELGROSSI, L.; STEINMETZ, R.; SCHALLER, S.; WITTIG, H.
Issues of reserving resources in advance. In: ACM International Workshop on
Network and Operating System Support for Digital Audio and Video. 1995.
p. 51-162.
W3C Consortium. Web Services Description Language. 2001. Disponível em:
. Acesso em: 01 fev. 2007.
W3C Consortium. Ontology Web Language. 2004. Disponível em:
. Acesso em: 01 fev. 2007.

Referências Bibliográficas 209
YAMIN, A.C.; BARBOSA, J.B.; AUGUSTIN, I.; SILVA, L.C.; REAL, R.;
GEYER, C.F.R.; CAVALHEIRO, G. Towards Merging Context-Aware, Mobile
and Grid Computing. In: International Journal of High Performance
Computing Applications. 2003. Volume 17, Number 2, p. 191-203.
YANG, X.; DE VECIANA, G. Inducing spatial clustering in MAC contention for
spread spectrum ad hoc networks. In Proceedings of the 6 th ACM international
Symposium on Mobile Ad Hoc Networking and Computing, Urbana-
Champaign, IL, USA, 2005. ACM Press, New York, NY, p. 121-132.
ZHU, F.; MUTKA, M.W.; NI, L.M. Service Discovery in Pervasive Computing
Environments. In: IEEE Pervasive Computing. 2005. Volume 4, Issue 4, p. 81-
90.

A
Apêndice
A.1.
Detalhes sobre o Ambiente de Simulação NCTUns
Como o simulador ns-2 [ISI 1995] não é capaz de tratar adequadamente certos
eventos de interesse no P2PDP, como a interceptação de pacotes em modo
promíscuo em redes sem fio, cogitou-se a possibilidade de alterar o código-fonte
do ns-2. Porém, esta seria uma escolha que demandaria um tempo considerável de
desenvolvimento. Por esse motivo, optou-se pela busca de alternativas
complementares para esse simulador. A solução encontrada foi a adoção, em
conjunto com o ns-2, do simulador NCTUns [Wang & Lin 2005], versão 3.0, haja
vista que, dentre outras características, o NCTUns possibilita o uso da própria
implementação do protocolo P2PDP, em Java, sem alterações, como gerador de
tráfego para as simulações. O NCTUns faz uso da pilha de protocolos TCP/IP e,
com isso, permite simulações mais fidedignas, além de possibilitar a integração de
nós simulados e emulados. A opção por se manter os dois ambientes de simulação
se deve ao fato do NCTUns apresentar uma restrição em função da configuração
da máquina em que as simulações são executadas; o tamanho máximo da grade
suportado pelo processador da máquina simuladora é de 56 nós. Devido a essa
restrição, o uso do NCTUns não permite avaliar a escalabilidade do protocolo, o
que é viabilizado pelo uso do simulador ns-2. Por sua vez, o NCTUns possibilitou
que as implementações do protocolo P2PDP e do middleware MoGrid tivessem a
sua correção atestada, facilitando, inclusive a depuração do código, reproduzindo
de forma fidedigna as peculiaridades de uma rede sem fio. Por esse motivo, optouse
pela manutenção dos dois simuladores, com o ns-2 utilizado na avaliação de
desempenho e o NCTUns na verificação de correção da implementação e na
avaliação do percentual de eficiência da descoberta do protocolo P2PDP.
Como o formato do trace do simulador NCTUns não permite rastrear os
pacotes pela sua identificação (ID), dado que cada pacote repassado recebe uma

Apêndice 211
nova ID, foi implementado, então, um script em awk [GNU 2003], para depurar o
arquivo de trace do NCTUns e rastrear o caminho dos pacotes em uma topologia
simulada. Como no trace o tamanho de cada pacote é exibido, a solução
implementada foi a de gerar, durante a execução da simulação, um número
aleatório de bytes em cada mensagem, com o intuito de diferenciá-las umas das
outras, o que possibilitou o seu posterior rastreamento. Um outro aspecto
interessante, observado em função dos testes realizados no NCTUns, é o de que,
em uma rede fixa, o tempo da aplicação (tempo real) é semelhante ao simulado.
Porém, em uma rede sem fio, o tempo de simulação é bem menor que o da
aplicação. Por essa razão, foi escolhido o uso do tempo real para simular o
protocolo P2PDP no contexto do middleware MoGrid.
A.2.
Gráficos Complementares referentes à Análise da Influência do
P2PDP na Carga Média da MANET
A seguir, são apresentados gráficos complementares aos apresentados na
Subseção 6.2.1, Figuras 55, 56, 57 e 58, ilustrando o comportamento do protocolo
P2PDP com o número máximo de respostas (R) variando no intervalo [1, 10].
Figura 55 – Carga na MANET para 20% de colaboradores ativos (p).

Apêndice 212
Figura 56 – Carga na MANET para 40% de colaboradores ativos (p).
Figura 57 – Carga na MANET para 60% de colaboradores ativos (p).

Apêndice 213
Figura 58 – Carga na MANET para 80% de colaboradores ativos (p).