Fernanda Andrade Oliveira
Estudo sobre Redes Ad-Hoc Móveis com Suporte à Descoberta
de Serviços
Vitória-ES
28 de março de 2011
Fernanda Andrade Oliveira
Estudo sobre Redes Ad-Hoc Móveis com Suporte à Descoberta
de Serviços
Monografia apresentada para obtenção do Grau
de Bacharel em Ciência da Computação pela
Universidade Federal do Espírito Santo.
Orientadora:
Profa. Dra. Roberta Lima Gomes
DEPARTAMENTO DE INFORMÁTICA
CENTRO TECNOLÓGICO
UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO
Vitória-ES
28 de março de 2011
Monografia de Projeto Final de Graduação sob o título “Estudo sobre Redes Ad-Hoc
Móveis com Suporte à Descoberta de Serviços”, defendida por Fernanda Andrade
Oliveira e aprovada em 28 de março de 2011, em Vitória, Estado do Espírito Santo, pela
banca examinadora constituída pelos professores:
______________________________
Profa. Dra. Roberta Lima Gomes
Universidade Federal do Espírito Santo
Orientadora
______________________________
Prof. Dr. Magnos Martinello
Universidade Federal do Espírito Santo
______________________________
Renan Manola
Universidade Federal do Espírito Santo
DEDICATÓRIA
À minha mãe, minha madrinha
e minhas avós (In Memoriam).
AGRADECIMENTOS
Agradeço à minha família pelo amor e suporte em todos esses anos. Em especial à minha
mãe, meu padrasto e minhas irmãs por estarem sempre perto, nos bons e maus momentos.
Agradeço também à minha madrinha e sua família, pelo carinho e incontáveis orações. À
minha grande amiga Mariana que me aguentou e me escutou nos momentos de desespero e
nos momentos de superação.
Agradeço à minha orientadora Roberta, pela paciência, comprometimento e pela
oportunidade que me foi dada, aprendi muito nesse último ano e a isso sou eternamente
grata. Agradeço também ao Magnos e Renan pelo apoio e ensinamentos.
Agradeço aos meus amigos de turma Carol e Julião, pelos 4 anos e meio de luta, vocês
fizeram o percurso ser mais agradável. Ao João Thompson e Aline pela companhia agradável
no laboratório e cantina. E ao João Vitor que inúmeras vezes me ajudou com os problemas
no LPRM.
Por fim, agradeço aos meus amigos de Aruanda, sem vocês eu não teria conseguido chegar
até aqui.
« Il faut être convaincu qu’on est doué pour quelque chose et que
cette chose, quel qu’en soit le prix, doit être atteinte. »
Marie Curie
RESUMO
Este trabalho consiste em um estudo sobre redes ad-hoc e dispositivos móveis dando
enfoque à descoberta de serviços. São discutidos os conceitos, tecnologias e padrões de
redes ad-hoc móveis e descoberta de serviços. O padrão Zero Configuration Networking
(ZeroConf) é apresentado e os seus protocolos componentes são descritos de forma
detalhada. O trabalho também apresenta a plataforma para dispositivos móveis Android,
dando enfoque ao suporte a redes ad-hoc. Através da API JmDNS, que implementa o padrão
ZeroConf em Java, são desenvolvidas duas aplicações: uma de descoberta de serviços e outra
de mensagem instantânea para redes ad-hoc.
ABSTRACT
This work presents a study on ad-hoc networks and mobile devices with focus on service
discovery. Discuss the concepts, technologies and patterns of ad-hoc networks and service
discovery. The pattern Zero Configuration Networking (ZeroConf) is presented and its
protocol components are described in detail. The work also features the Android platform
for mobile devices, focusing on the support of ad-hoc networks. Through the API JmDNS,
which implements the pattern in Java, are developed two applications: a service discovery
and a instant messaging application for ad-hoc networks.
SUMÁRIO
LISTA DE FIGURAS
LISTA DE SIGLAS E ABREVIATURAS
1 INTRODUÇÃO............................................................................................................
1.1 OBJETIVOS...........................................................................................................
1.2 METODOLOGIA...................................................................................................
1.3 ESTRUTURA DA MONOGRAFIA...........................................................................
14
15
15
16
2 FUNDAMENTAÇÃO TEÓRICA...................................................................................
2.1 DISPOSITIVOS PORTÁTEIS...................................................................................
2.1.1 Tecnologias...............................................................................................
2.2 REDES AD-HOC MÓVEIS......................................................................................
2.2.1 WiFi............................................................................................................
2.3 DESCOBERTA DE SERVIÇOS.................................................................................
2.3.1 Arquitetura de Descoberta de Serviços...................................................
2.3.2 Tecnologias de Descoberta de Serviços...................................................
2.4 CONSIDERAÇÕES SOBRE O CAPÍTULO.................................................................
17
17
18
19
22
24
25
27
29
3 ZERO CONFIGURATION NETWORKING....................................................................
3.1 ENDEREÇOS IP SEM DHCP .................................................................................
3.1.1 Atribuição Manual....................................................................................
3.1.2 Servidor DHCP...........................................................................................
3.1.3 Auto-atribuição com IPv4LL.....................................................................
3.2 RESOLUÇÃO DE NOMES SEM DNS......................................................................
3.2.1 Multicast DNS...........................................................................................
3.3 BUSCANDO POR SERVIÇOS.................................................................................
3.4 IMPLEMENTAÇÕES.............................................................................................
3.5 CONSIDERAÇÕES SOBRE O CAPÍTULO................................................................
30
31
31
32
33
34
34
35
38
39
4 IMPLEMENTAÇÃO.................................................................................................... 40
4.1 PLATAFORMA ANDROID..................................................................................... 40
4.1.1 Arquitetura............................................................................................... 41
4.1.2 Ambiente de Desenvolvimento............................................................... 42
4.2 AD-HOC EM ANDROID........................................................................................ 44
4.3 JmDNS................................................................................................................. 46
4.4 APLICAÇÃO DE DESCOBERTA DE SERVIÇOS........................................................ 46
4.4.1 Cenário de Utilização da Aplicação......................................................... 47
4.5 APLICAÇÃO DE MENSAGEM INSTANTÂNEA........................................................ 52
4.5.1 Cenário de Utilização da Aplicação......................................................... 52
4.6 DIFICULDADES NA IMPLEMENTAÇÃO................................................................ 54
4.7 CONSIDERAÇÕES SOBRE O CAPÍTULO................................................................ 55
5 CONCLUSÕES E TRABALHOS FUTUROS ................................................................... 57
5.1 TRABALHOS FUTUROS......................................................................................... 59
REFERÊNCIAS
LISTA DE FIGURAS
Figura 1: Rede ad-hoc multi-hop............................................................................ 20
Figura 2: Arquitetura de camadas MANET............................................................
21
Figura 3: Rede WiFi infraestruturada e ad-hoc...................................................... 23
Figura 4: Registros A, SRV e PTR............................................................................
36
Figura 5: Registros não preenchidos...................................................................... 37
Figura 6: Arquitetura Android................................................................................ 41
Figura 7: (a) Tela inicial da aplicação (b) Tela de registro de serviço (c) Tela de
descoberta de serviços..........................................................................................
47
Figura 8: Alice busca por serviços..........................................................................
48
Figura 9: Nenhum serviço encontrado..................................................................
48
Figura 10: Alice registra serviço de presença........................................................ 49
Figura 11: Bob registra serviço de presença .........................................................
49
Figura 12: Bob busca por serviços de presença.....................................................
50
Figura 13: Resultado de busca de serviços............................................................
50
Figura 14: Resolução de serviço............................................................................. 51
Figura 15: Resultado da resolução de serviço.......................................................
51
Figura 16: Tela de conexão....................................................................................
53
Figura 17: (a) Tela de troca de mensagens (b) Chat..............................................
53
LISTA DE SIGLAS E ABREVIATURAS
AAPT
Android Asset Packaging Tool
ADB
Android Debug Bridge
ADT
Android Development Tools
AODV
Ad-Hoc On-Demand Distance Vector
AP
Access Point
API
Application Programming Interface
CSMA/CA
Carrier Sense Multiple Access with Collision Avoidance
CT
Centro Tecnológico
DCF
Distributed Coordination Function
DDMS
Dalvik Debug Monitor Server
DHCP
Dynamic Host Configuration Protocol
DNS
Domain Name System
DNS-SD
Domain Name System – Service Discovery
DSR
Dynamic Source Routing
DSSS
Direct Sequence Spread Spectrum
FHSS
Frequency Hopping Spread Spectrum
FTP
File Transfer Protocol
GPS
Global Positioning System
HTTP
HyperText Transfer Protocol
IBSS
Independent Basic Service Set
IDE
Integrated Development Environment
IEEE
Institute of Electrical and Electronics Engineers
IETF
Internet Engineering Task Force
IP
Internet Protocol
IPP
Internet Printing Protocol
IPv4LL
Internet Protocol version 4 Link Local
ISM
Industrial, Scientific and Medical
LAN
Local Area Network
LPRM
Laboratório de Pesquisas em Redes e Multimídia
MAC
Media Access Control
MANET
Mobile Ad-Hoc Network
mDNS
Multicast Domain Name System
OHA
Open Handset Alliance
OLSR
Optimized Link State Routing
P2P
Peer-to-Peer
PAN
Personal Area Network
PDA
Personal Digital Assistant
QoS
Quality of Service
RFC
Request for Comments
RREP
Route Reply
RREQ
Route Request
SDK
Software Development Kit
SO
Sistema Operacional
SSDP
Simple Service Discovery Protocol
TBRPF
Topology Broadcast based on Reverse-Path Forwarding
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
UI
User Interface
UPnP
Universal Plug and Play
WiFi
Wireless Fidelity
WiMAX
Worldwide Interoperability for Microwave Access
XML
Extensible Markup Language
XMPP
Extensible Messaging and Presence Protocol
ZeroConf
Zero Configuration Networking
14
1 INTRODUÇÃO
A última década presenciou uma revolução na área de informática denominada computação
móvel. O desenvolvimento de diferentes tecnologias possibilitou que dispositivos móveis
como celulares, se tornassem menores e mais potentes, resultando em uma grande
demanda por aplicações e soluções para tais dispositivos.
Ao mesmo tempo, as redes sem fio se desenvolveram, tornando-se mais confiáveis, mais
seguras e mais populares. No escopo de redes sem fio se destacam as redes ad-hoc, que são
redes que não necessitam de infraestrutura para serem estabelecidas. As redes ad-hoc
caracterizam um vasto assunto de pesquisa e apresentam grandes desafios como, por
exemplo, a implementação de seu roteamento. Entretanto, seu uso ainda é pouco comum
entre os usuários de dispositivos móveis, o que demonstra um potencial de utilização ainda
não explorado e um mercado promissor de aplicações.
Diante da expansão e popularização dos dispositivos móveis, aumentam-se as situações de
uso e aplicações de redes móveis (ou redes de dispositivos móveis) e também a necessidade
de se pesquisar soluções para problemas que envolvam especificamente redes móveis. Tais
pesquisas devem sempre visar o melhor aproveitamento dos recursos dos equipamentos e
praticidade para os usuários.
Junto ao desenvolvimento de dispositivos móveis e redes sem fio, existe também o aumento
da oferta de serviços em redes. Além dos serviços tradicionais que foram definidos com o
estabelecimento da Internet, tais como serviços de Telnet, FTP e serviços de correio
eletrônico, atualmente existem diversos novos serviços e a expectativa de um maior
crescimento do número de serviços disponíveis em uma rede local, por exemplo. Em redes
sem fio móveis os serviços ficam espalhados pela rede e a disponibilidade de serviços é
ainda maior, pois cada dispositivo componente da rede tem a potencialidade de prover
serviços enquanto pertencer à rede.
Com o crescimento do número de serviços e com a dinamicidade com que esses serviços
podem ser disponibilizados ou removidos de uma rede sem fio, tem-se a necessidade de se
utilizar “descoberta de serviços”. Uma aplicação de descoberta de serviço possibilita que o
15
usuário da rede localize os serviços oferecidos pela rede, provendo um maior
aproveitamento dos recursos da rede.
O surgimento de novas tecnologias para dispositivos móveis, principalmente tecnologias
abertas, a possibilidade de se utilizar redes ad-hoc em diversos cenários, o suporte de
mecanismos de descoberta e publicação de serviços nessas redes, e a necessidade de
melhor compreensão e utilização dessas redes, são as principais motivações deste trabalho.
1.1 OBJETIVOS
Este trabalho tem como objetivo geral o estudo de tecnologias de suporte à criação de redes
ad-hoc com dispositivos móveis, com foco nos mecanismos de descoberta de serviços para
este tipo de ambiente. Este objetivo geral desdobra-se nos seguintes objetivos específicos:
•
pesquisar as diversas plataformas de dispositivos móveis disponíveis;
•
estudar os fundamentos e protocolos envolvendo redes ad-hoc móveis;
•
escolher e estudar uma plataforma móvel específica para por em prática os estudos
realizados neste trabalho;
•
estudar e testar o suporte aos mecanismos de redes ad-hoc na plataforma escolhida;
•
estudar protocolos e bibliotecas de descoberta de serviço no contexto de redes adhoc móveis;
•
realizar testes de bibliotecas abertas para implementação de mecanismos de
descoberta de serviços em redes;
•
implementar aplicação móvel que utilize a descoberta de serviços.
1.2 METODOLOGIA
A metodologia utilizada foi a leitura e análise de artigos e livros sobre os assuntos de
dispositivos móveis, redes sem fio, redes ad-hoc e descoberta de serviços. Busca e estudo de
16
protocolos de redes ad-hoc e descoberta de serviços. Também foram pesquisadas
bibliotecas ou APIs que implementassem os protocolos utilizados.
Para testar e por em prática os conceitos estudados, uma plataforma móvel aberta foi
escolhida e estuda. Foi necessário verificar o suporte dessa plataforma quanto à criação de
redes ad-hoc, e solucionar os possíveis problemas relacionados à rede.
Dentre as APIs estudas, foi escolhida uma para servir de base à implementação de duas
aplicações: uma de descoberta/publicação de serviços, e uma de mensagem instantânea que
utiliza informações coletadas pela primeira aplicação.
1.3 ESTRUTURA DA MONOGRAFIA
A presente monografia encontra-se estruturada da seguinte forma:
O CAPÍTULO 2: Apresenta a fundamentação teórica que abrange dispositivos móveis, suas
características e limitações e apresenta algumas tecnologias de celulares e smartphones.
Esse capítulo também discorre sobre redes ad-hoc móveis e a tecnologia de redes sem fio
WiFi. Ainda nesse capítulo, é discutida a descoberta de serviços e são apresentados alguns
protocolos para a localização de serviços.
CAPÍTULO 3: Apresenta uma explicação detalhada das características e do funcionamento do
padrão Zero Configuration Networking. Um padrão que compreende a criação de redes IP e
descoberta de serviços baseada em DNS (Domain Name System).
CAPÍTULO 4: Apresenta a plataforma para celulares Android, expõe a falta de suporte do
Android à redes ad-hoc, trazendo uma solução para essa limitação. Apresenta também a API
JmDNS que é usada na implementação das aplicações de descoberta de serviços e
mensagem instantânea. O capítulo também explica o funcionamento das aplicações,
trazendo ao seu final considerações sobre as dificuldades encontradas nas implementações.
CAPÍTULO 5: Apresenta as conclusões e trabalhos futuros.
17
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo consiste na explanação dos conceitos de dispositivos portáteis, redes ad-hoc e
descoberta de serviços. Esses conceitos estão interligados e são necessários para o
entendimento das redes ad-hoc móveis habilitadas com descoberta de serviços.
2.1 DISPOSITIVOS PORTÁTEIS
Dispositivos portáteis, também chamados de dispositivos móveis, são diversos
equipamentos que possuem características em comum, como tamanho reduzido, tela
pequena, baixo poder de processamento, pouca memória e limitada autonomia de bateria,
possuindo ainda uma ou mais interfaces de comunicação sem fio. Esses equipamentos
apresentam limitações de recursos computacionais se comparados a computadores desktop
ou notebooks devido ao seu tamanho reduzido. Entretanto desde o surgimento dos
primeiros dispositivos portáteis, verifica-se um aumento expressivo de seu poder
computacional, o que vem possibilitando o desenvolvimento de aplicações que antes só
eram encontradas em desktops. Exemplos comuns são celulares, smartphones, relógios, mp3
players e PDAs (Personal Digital Assistant). No escopo deste trabalho, os dispositivos
portáteis serão representados pelos celulares e smartphones, e doravante referenciados
como celulares.
Além dos serviços básicos de telefonia, os celulares apresentam funcionalidades de
multimídia como câmera de vídeo e fotos, players de áudio, interfaces de rede Bluetooth e
WiFi, sistema de localização por GPS, entre outras. O conjunto de funcionalidades oferecidos
dependem do modelo e marca do dispositivo, sendo os mais populares os que apresentam o
maior número de funcionalidades.
Com o aumento da oferta de serviços e operações possíveis de se realizar com o dispositivo,
cresce também o problema causado pela limitação do recurso de energia. A complexidade
das operações exige uma maior disponibilidade de bateria. As transmissões de rede são um
18
dos processos mais custosos em termos de energia, necessitando uma maior atenção do
desenvolvedor para implementar técnicas que evitam o desperdício desse recurso.
Existem diversos sistemas operacionais para celulares. Alguns são de hardware específico,
como os iPhones da Apple, que é responsável pelo desenvolvimento tanto do dispositivo
quanto do software. Outros como Windows Mobile e Android, são sistemas que aparecem
em diversos tipos de hardware.
2.1.1 Tecnologias
Diante da diversidade de sistemas e plataformas, atualmente se destacam algumas
tecnologias, tanto por número de vendas quanto pela qualidade da estrutura oferecida para
desenvolvedores. Alguns desses sistemas são:
•
iOS: É o sistema operacional do iPhone, iTouch e iPad. Lançado em 2007, apesar de
possuir um SDK (Software Development Kit), somente aplicações autorizadas pela
Apple podem ser instaladas no dispositivo. As aplicações são escritas em Objective-C;
•
Symbian OS: É o sistema operacional dos aparelhos Nokia. Possui também um SDK e
é programado em C++;
•
Windows Mobile: É encontrado em diversas marcas de aparelhos. De código
proprietário, vem sendo substituído pelo Windows Phone 7. Suas aplicações são
programadas em C++;
•
BlackBerry OS: É o sistema de código proprietário dos aparelhos BlackBerry. Não
possui uma SDK, mas fornece uma API (Application Programming Interface) para
desenvolvimento de códigos de terceiros com funcionalidade limitada;
• Android: Lançado em 2007, é uma pilha de software de código aberto para celulares.
Mantido pela Google, procura ser a maior concorrência ao iPhone. As aplicações são
escritas em Java.
19
2.2 REDES AD-HOC MÓVEIS
Conhecidas como MANET (Mobile Ad-Hoc Networks) redes ad-hoc móveis são redes
formadas por dispositivos móveis (nós móveis) equipados com interface de rede sem fio que
se comunicam entre si sem o auxilio de infraestrutura. Neste esquema, cada nó pode ser um
servidor, cliente ou roteador. MANET também é o nome dado ao grupo de trabalho da IETF
responsável pelo desenvolvimento e padronização de tais redes.
Os conceitos de redes ad-hoc remontam à década de 70 com o projeto da DARPA (Defence
Advanced Research Projects Agency), tais redes eram chamadas Packet Radio Networking
naquela época. Inicialmente, portanto, as redes ad-hoc eram utilizadas para fins militares,
possibilitando a comunicação em campos de batalha. A partir da década de 90 com os
avanços nas tecnologias de radio comercial e redes sem fio, as pesquisas em redes ad-hoc se
intensificaram e novos usos, fora do campo militar, surgiram.
Essas redes são úteis em cenários onde não é possível se instalar uma infraestrutura, ou
também onde não há necessidade de infraestrutura devido ao caráter temporário da rede.
Alguns cenários possíveis são interação entre serviços de emergência em desastres naturais,
conferencias e seminários, salas de aulas, ou simples necessidade de troca de arquivos.
A rede ad-hoc mais simples é uma rede peer-to-peer formada por dispositivos que se
encontram dentro de um mesmo alcance, e se auto-configuram numa rede single-hop.
Entretanto, essa rede fica limitada a equipamentos que estão no mesmo alcance de
transmissão, essa limitação pode ser superada pelo paradigma multi-hop.
Numa rede multi-hop, os pacotes são encaminhados da fonte até o destino. Nós próximos
podem se comunicar diretamente através de uma tecnologia sem fio single-hop, nós que
não estão diretamente conectados, se comunicam encaminhando seus pacotes através de
uma sequência de nós intermediários, como pode se verificar na figura 1.
20
Figura 1: Rede ad-hoc multi-hop
Na figura 1, os círculos representam o alcance de cada nó, as setas em azul demonstram a
rota necessária para se atingir os nós periféricos.
A flexibilidade e conveniência das redes ad-hoc móveis trazem alguns novos desafios. Além
dos problemas tradicionais de redes sem fio, falta de estrutura fixa, a mobilidade dos nós e a
natureza multi-hop adicionam novas características, complexidades e dificuldades
específicas dessas redes, como por exemplo, topologia dinâmica da rede dificultando o
roteamento, variação da capacidade dos enlaces e entrada e saída constante de novos nós.
O grupo de trabalho MANET1 da IETF adotou uma visão IP-cêntrica das MANETs que herdam
as camadas da pilha TCP/IP. Conti e Giordano em (CONTI; GIORDANO, 2007) apresentam
uma arquitetura formada pelas seguintes camadas: tecnologias de base (enabling
technologies), rede (networking), middleware e aplicações (applications), como pode ser
visto na figura 2.
1
http://tools.ietf.org/wg/manet
21
Figura 2: Arquitetura de camadas MANET (CONTI; GIORDANO, 2007)
As tecnologias de base garantem a comunicação single-hop entre os dispositivos,
compreendendo a camada MAC e a camada física da pilha TCP/IP. Os seguintes padrões
suportam o paradigma de redes ad-hoc: IEEE 802.15.4 também conhecido como Zigbee para
uso em redes de curto alcance e baixa taxa de dados, IEEE 802.15.1 ou Bluetooth para redes
pessoais, 802.11 ou WiFi para redes de alta velocidade com médio alcance e 802.16 também
chamado de WiMAX para redes de alta velocidade e alto alcance. A tecnologia mais utilizada
é a 802.11 devido a prévia popularidade das redes sem fio WiFi.
Os protocolos de rede utilizam os serviços de single-hop fornecidos pelas tecnologias de
base para oferecer serviços de entrega fim-a-fim, do transmissor ao receptor fora da área de
alcance. Roteamento e encaminhamento são os serviços básicos de rede. Roteamento é a
função de identificar um caminho entre o transmissor e o receptor, encaminhamento é a
função de entregar os pacotes através do caminho identificado. Essas funções estão ligadas
com as características da topologia da rede. Devido à natureza imprevisível e dinâmica das
redes ad-hoc móveis, seu roteamento apresenta grandes desafios.
De acordo com o grupo de trabalho da IETF, os protocolos de roteamento são classificados
em duas categorias principais: protocolos proativos ou reativos (sob demanda).
Os
protocolos proativos tentam manter informações de roteamento consistentes e atualizadas
para cada par de nós da rede através da propagação de mensagens de atualização de rotas
enviadas periodicamente. Por outro lado, protocolos reativos estabelecem rotas para
encaminhamento somente quando necessário. De acordo com (CONTI; GIORDANO, 2007)
22
os quatro principais protocolos implementados são os reativos, AODV (Ad-Hoc On-Demand
Distance Vector) e DSR (Dynamic Source Routing) e os proativos OLSR (Optimized Link State
Routing) e TBRPF (Topology Dissemination Based on Reverse Path Forwarding).
Dentre as questões que envolvem todas as camadas da rede estão controle do consumo de
energia, segurança e qualidade de serviço (QoS). O consumo de energia é uma questão
crucial quando se tratando de dispositivos móveis, faltando energia, os serviços ficam
indisponíveis. A escolha de protocolos que visam a diminuição do consumo de energia é
necessária. A qualidade de serviço não é garantida nativamente, pesquisas e padrões devem
ser desenvolvidos.
Redes ad-hoc são uma evolução importante das redes sem fio. Elas comportam diversas
potencialidades que não estão disponíveis em redes sem fio tradicionais e podem ser
utilizadas em diferentes ambientes. Como os sistemas móveis são relativamente recentes, a
demanda por suporte a redes ad-hoc também é recente, ocasionando uma instabilidade no
suporte a essas redes pelas tecnologias. Assim, apesar dos avanços e da quantidade de
pesquisas, ainda há muito a ser desenvolvido e padrões a serem estabelecidos.
2.2.1 WiFi
IEEE 802.11 2 ou WiFi é um padrão de transmissão de dados sem fio nas frequências de 2.4 e
5 GHz da banda ISM (Industrial Scientific and Medical). O grupo de trabalho responsável pelo
padrão é o “Working Group for WLAN Standards” 3.
O padrão proporciona redes LAN entre computadores, dispositivos móveis e redes físicas
infraestruturadas. Definindo uma camada física e uma camada MAC nas suas especificações.
Três diferentes tecnologias são definidas como interface da camada física: infravermelho,
FHSS (Frequency Hopping Spread Spectrum) e DSSS (Direct Sequence Spread Spectrum). A
tecnologia mais utilizada é a DSSS que oferece uma taxa de bits de 11 Mbps na faixa de
2
3
Disponível em http://standards.ieee.org/about/get/.
http://www.ieee802.org/11/index.shtml
23
2.4GHz e 54 Mbps na faixa de 5 GHz. O método de acesso básico da camada MAC é o
Distributed Coordination Function (DCF) com Carrier Sense Multiple Access with Collision
Avoidance (CSMA/CA).
WiFi pode ser utilizado para implementar LANs infraestruturadas ou ad-hoc. Como pode ser
visto na figura 3 que ilustra uma rede infraestruturada e seus componentes, e uma rede adhoc.
Figura 3: Rede WiFi infraestruturada e ad-hoc (GIORDANDO, 2002)
Em uma rede infraestruturada, existe uma entidade central de controle para cada célula
chamado Access Point. Todo tráfego passa pelo AP, que também é responsável por conectar
a rede sem fio a possíveis redes cabeadas existentes e fornecer o acesso a Internet.
No modo ad-hoc, os dispositivos na mesma célula, chamada Independent Basic Service Set
(IBSS), podem se comunicar diretamente com qualquer outro dispositivo dentro da célula,
sem a interferência de uma entidade centralizadora. Devido à flexibilidade do algoritmo
CSMA/CA, a sincronização dos dispositivos é suficiente para a correta recepção e
transmissão de dados.
O padrão 802.11 apresenta várias versões representadas por letras, em cada versão
diferencia-se frequência de utilização, capacidade de vazão de bits entre outros aspectos.
24
2.3 DESCOBERTA DE SERVIÇOS
A maioria das pesquisas envolvendo MANETs se concentram na conectividade entre os nós
móveis devido às dificuldades impostas pelo dinamismo das redes. O dinamismo é
consequência da mobilidade dos nós, condições adversas do canal sem fio, e limitações de
energia dos dispositivos móveis, o que ocasiona frequentes desconexões e falha nos nós.
Entretanto, para a adoção de MANETs, é necessário mais do que a solução do problema de
conectividade. Como o objetivo dessas redes é possibilitar a troca de dados e serviços entre
usuários móveis, também são necessários arquiteturas, mecanismos e protocolos para
descoberta de serviços.
Descoberta de serviços possibilita aos nós da rede:
•
a publicação de seus serviços;
•
a consulta de serviços fornecidos por outras entidades;
•
a seleção do serviço mais apropriado;
•
a invocação dos serviços.
Inicialmente, descoberta de serviços era utilizada no contexto de redes infraestruturadas.
Em MANETs, novos desafios surgem devido às características da rede, como:
•
Disponibilidade dos serviços, devido à mobilidade dos nós;
•
Frequentes desconexões do servidor ou do cliente ou de nós intermediários,
quebrando ou modificando o acesso ao serviço ou algum parâmetro para sua
seleção, como seu endereço IP por exemplo.
•
Variabilidade do canal, levando a variabilidade de características de comunicação
como taxa de envio de dados e atrasos.
De acordo com (VERVERIDIS; POLYZOS, 2008) MANETs atraíram uma enorme atenção da
comunidade científica nos últimos anos, entretanto a quantidade de aplicações civis
permanece insignificante. Descoberta de serviços eficiente é um dos pontos chaves que
precisam ser resolvidos para a aceitação de MANETs.
25
2.3.1 Arquitetura de Descoberta de Serviços
Os protocolos de descoberta de serviços podem ser classificados devido a características que
apresentam. Características como arquitetura, modo de operação, camada de rede em que
são baseados, entre outras. Existem três arquiteturas básicas que um protocolo de
descoberta de serviços pode adotar: arquitetura baseada em diretórios, arquitetura sem
diretórios e arquitetura híbrida.
Na arquitetura baseada em diretórios, um nó pode apresentar três papeis. Pode ser um
servidor (provedor de serviços, oferecendo serviços para os outros nós), um cliente
(solicitador de serviços, requisitando serviços de outros nós) ou um diretório de serviços
(facilitador de comunicação entre servidores e clientes). Provedores de serviços registram
seus serviços nos diretórios e os solicitadores de serviços são informados dos serviços
disponíveis somente através dos diretórios.
Um diretório pode ser centralizado ou distribuído, sendo que o primeiro é adotado
principalmente em redes infraestruturadas, pois um diretório centralizado representa um
ponto de falha. Em redes ad-hoc, a melhor solução são diretórios distribuídos pois nem
sempre todos os nós estão disponíveis em todos os momentos. Diretórios distribuídos
contribuem também para uma maior escalabilidade da estrutura, um único nó móvel teria
dificuldade de responder a todas as requisições da rede.
É importante ressaltar que a abordagem baseada em diretórios compreende custos
adicionais de comunicação da rede para se manter a estrutura dos diretórios e no caso de
diretórios distribuídos, também para se manter a consistência dos dados entre os
componentes do diretório distribuído.
A arquitetura sem diretórios difere da acima citada pois não há uma entidade mediadora
entre os provedores e solicitadores de serviços. É uma arquitetura mais simples pois não
necessita de mecanismos para seleção e manutenção de diretórios. Provedores publicam
seus serviços e solicitadores requisitam serviços de forma broadcast pela rede.
26
Um problema básico na abordagem sem diretórios é determinar a frequência de mensagens
de anúncio de serviços, de forma a diminuir a carga da rede e evitar transmissões
redundantes. Uma solução encontrada é o scheduling, provedores anunciam os serviços
periodicamente com o auxilio de algoritmo de back-off exponencial, ou seja os anúncios são
cada vez menos frequentes até atingir um limiar determinado pelo algoritmo. Uma outra
forma de se diminuir a carga da rede é utilizar multicasting. Servidores publicam seus
serviços para um grupo multicast, e clientes requisitam serviços da mesma forma.
Na arquitetura híbrida, caso encontrem um diretório, os provedores de serviços registram
seus serviços nesses diretórios, caso contrário, eles simplesmente publicam seus serviços de
forma broadcast. O mesmo acontece para os solicitadores de serviços, se conhecem algum
diretório da rede, buscam por serviços no diretório, se não conhecem, buscam por serviços
de forma broadcast.
Pode-se confirmar em (VERVERIDIS; POLYZOS, 2008) que apesar das muitas publicações
envolvendo cada uma das arquiteturas apresentadas, pesquisadores não chegaram a um
consenso sobre qual arquitetura é melhor. Os critérios para avaliar as arquiteturas são:
disponibilidade dos serviços, overhead de mensagens e latência. A dificuldade de se escolher
uma arquitetura é devido às diferenças das características das MANETs, como número de
nós, mobilidade dos nós, razão entre clientes e servidores, sendo assim cada arquitetura
apropriada para um determinado cenário. Por exemplo, para uma MANET com alto grau de
mobilidade e baixa frequência de requisição de serviços, uma arquitetura sem entidade
mediadora é mais eficiente do que uma arquitetura baseada em diretório, pois a última teria
informações constantemente desatualizadas ou teria um gasto altíssimo para manter a
integridade das informações.
Independente da arquitetura apresentada existem três possíveis modos de operação para
um solicitador de serviços adquirir informações: modo reativo, modo proativo e modo
híbrido.
No modo reativo o cliente envia uma query ou para os servidores ou para o diretório em
busca de serviços. No modo proativo, os servidores anunciam seus serviços em
determinados intervalos de tempo. No modo hibrido, servidores anunciam seus serviços e
clientes buscam serviços através de queries. Novamente, dependendo das características da
27
rede, um modo de operação é mais eficiente que outro. Quando o número de servidores é
maior do que o de clientes, a abordagem mais apropriada é a reativa, no caso contrário, a
mais apropriada é a proativa.
Com relação a camada de rede, temos duas principais abordagens de descoberta de
serviços, baseada na camada de aplicação ou cross-layer. A maioria dos protocolos baseados
na camada de aplicação já eram utilizados em redes infraestruturadas. Mensagens de
anúncio e descoberta são trocadas a nível de aplicação. Já a descoberta de serviços crosslayer, são específicas para redes móveis ad-hoc, e se utilizam das informações de
roteamento para a descoberta de serviços. Descoberta de serviços cross-layer exploram a
capacidade de conseguir informações sobre serviços juntamente com informações sobre
rotas (pelas mesmas mensagens), carregando informações sobre serviços dentro das
mensagens de roteamento. Dessa forma, transmissões redundantes na camada de aplicação
são evitadas.
Em suma, há diversas arquiteturas e características disponíveis. Devido às diferenças de
composição e configuração das MANETs, não se pode classificar como uma arquitetura
sendo melhor que outra, só a que melhor se adapta a uma situação. Na próxima seção são
apresentados algumas tecnologias para implementação ou suporte de descoberta de
serviços.
2.3.2 Tecnologias de Descoberta de Serviços
Tecnologias de descoberta de serviços são desenvolvidas para simplificar o uso de
dispositivos em redes, permitindo que serviços e equipamentos sejam descobertos,
configurados e usados por outros dispositivos com o mínimo de trabalho manual. De acordo
com (RICHARD, 2000), apesar desses padrões de descoberta de serviços apresentarem
funcionalidades similares, nenhuma das tecnologias compreende todas as outras e é madura
o suficiente para dominar o mercado.
28
Como exemplo de protocolos de descoberta de serviços retirados de (VERVERIDIS; POLYZOS,
2008) e (SU; GUO, 2008) temos:
•
Jini: Desenvolvida pela Sun, é uma arquitetura que especifica a descoberta e
invocação de serviços para dispositivos habilitados com Java, uma máquina virtual
Java é obrigatória. Jini possui um servidor de lookup que funciona como um diretório,
armazenando serviços publicados por provedores de serviços e respondendo a
queries de clientes. Os provedores de serviço registram seus serviços no servidor de
lookup enviando objetos de serviços e seus atributos. Objetos de serviços são proxies
escritos em Java que servem de interface para o acesso remoto de clientes ao
serviço. Os clientes recebem esses proxies dos servidores de lookup, através de suas
requisições;
•
Simple Service Discovery Protocol: SSDP é o protocolo de descoberta de serviços
utilizado pelo UPnP (Universal Plug and Play). UPnP é um conjunto de protocolos que
busca expandir o conceito de Plug and Play para os componentes de uma rede,
buscando o reconhecimento e configuração automáticos de novos dispositivos na
rede. O protocolo apresenta estrutura de diretórios opcionais denominados pontos
de controle. A descoberta de serviços se dá utilizando HTTP sobre UDP multicast ou
unicast. SSDP é considerado um protocolo custoso, principalmente em memória,
dificultando
sua
implementação
em
dispositivos
com
limitados
recursos
computacionais.
•
DNS Service Discovery: DNS-SD é o protocolo de descoberta de serviços proposto
pelo padrão Zero Configuration Networking. Desenvolvido para ser utilizado em
diversos dispositivos com interface de rede IP, inclusive pequenos dispositivos como
sensores ou câmeras, é um protocolo simples e leve, adequado ao uso em aparelhos
celulares. A descoberta de serviços é baseada em DNS (Domain Name System),
usando os registros do já estabelecido padrão DNS para efetuar a busca e registro de
serviços.
•
AODV Service Discovery: É a descoberta de serviços cross-layer baseada no
protocolo de roteamento AODV (Ad-Hoc On-Demand Distance Vector). O protocolo
aproveita os mecanismos de roteamento para a descoberta de serviços. AODV-SD
estende o formato das mensagens de RREQ (Route Request) e RREP (Route Reply) do
29
protocolo de roteamento. Assim, cada nó contém uma lista com informações de
serviços. Cada linha da lista contém um identificador único do serviço, seu endereço
IP, a duração do serviço e os atributos do serviço.
2.4 CONSIDERAÇÕES SOBRE O CAPÍTULO
O capítulo discorreu sobre os conceitos fundamentais de redes ad-hoc móveis e descoberta
de serviços. A descoberta de serviços é uma ferramenta essencial para o bom uso e
aproveitamento dos recursos da rede, principalmente redes ad-hoc em que os usuários têm
grande mobilidade, saindo e entrando do alcance da rede, fazendo com que os serviços
disponíveis sejam desconhecidos à maioria dos participantes. Apesar do grande número de
pesquisas e protocolos propostos, não há ainda uma solução definitiva em relação ao
roteamento da rede. Com relação às camadas física e MAC, o protocolo 802.11 se apresenta
como uma tecnologia bem desenvolvida e estável.
O estudo sobre redes ad-hoc se mostra necessário, pois em termos de usuários finais, ainda
são pouco aproveitadas as capacidades que a rede oferece, muito mais do que aplicações de
troca de conteúdo multimídia, redes ad-hoc podem tornar a troca de informações mais
rápida, simples e ubíqua.
O próximo capítulo apresenta-se de forma mais detalhada o conjunto de protocolos Zero
Configuration Networking que se adapta bem ao uso em redes ad-hoc, oferecendo um
protocolo de auto-atribuição de endereços IP e um protocolo de descoberta de serviço, o
DNS-SD.
30
3 ZERO CONFIGURATION NETWORKING
Zero Configuration Networking ou ZeroConf representa um conjunto de protocolos que
envolve três tecnologias com o propósito de se construir redes IP de forma ad-hoc com o
mínimo de configuração possível, buscando a simplicidade e visando ser utilizado também
por periféricos com pouca capacidade computacional como câmeras e impressoras de rede.
Essas tecnologias são: IPv4 Link-Local Address, Multicast DNS e DNS Service Discovery.
Desde 1999 existe um grupo de trabalho da IETF (Internet Engineering Task Force)
responsável por padronizar o ZeroConf. De acordo com seu criador, Stuart Cheshire
(CHESHIRE; STEINBERG, 2005), o objetivo é tornar redes IP tão simples como redes elétricas,
onde é possível se plugar um equipamento e ele já está pronto para usar. Assim, ZeroConf
propõe a criação de redes IP em que os usuários não se deparam com configurações de
endereço IP ou máscaras de subrede, por exemplo. Além disso, ZeroConf também dispensa
a necessidade de infraestrutura de rede. Servidores de DNS e DHCP são substituídos pelas
tecnologias que compõe o protocolo.
ZeroConf compreende endereçamento, nomeação e busca por serviços. O endereçamento é
proposto sem configuração manual ou servidor DHCP e é implementado pelo IPv4 Link-Local
Address (IPv4LL). A resolução de nomes dispensa o uso do servidor DNS, pois é realizada pelo
Multicast DNS (mDNS). A busca por serviços ou descoberta de serviços é baseada em DNS,
realizada também pelo mDNS e chamada de DNS Service Discovery (DNS-SD). É necessário
esclarecer, entretanto, que essas três tecnologias podem ser utilizadas em separado. Podese utilizar mDNS em uma rede onde o endereçamento é realizado por um servidor DHCP por
exemplo. Neste capítulo serão descritas essas tecnologias e o papel das mesmas no
ZeroConf.
31
3.1 ENDEREÇOS IP SEM DHCP
Todo equipamento pertencente a uma rede IP necessita de um endereço IP que seja único
na rede. Assim, para se atribuir um endereço IP é necessário escolher um endereço IP válido
e confirmar sua unicidade na rede.
Existem diferentes formas de se atribuir um endereço IP, sendo estas: atribuição manual,
servidor DHCP ou auto-atribuição com IPv4LL.
3.1.1 Atribuição Manual
Toda plataforma possibilita a configuração manual do endereço IP. Para a configuração são
necessários:
•
endereço de rede: os endereços do tipo IPv4 são formados por 4 octetos formando
um total de 32 bits. Cada octeto pode ser representado de forma decimal, sendo
separados por pontos, como em “192.168.010.005”. O endereço é formado por uma
porção que identifica a rede e outra porção que identifica o host.
•
máscara de subrede: identifica quais bits do endereço IP representam a porção da
rede;
•
endereço de gateway: endereço de um dispositivo da rede que possibilita a conexão
entre hosts de diferentes redes;
•
endereço de DNS padrão: endereço do serviço que possibilita a resolução de nomes
em endereços IP.
Uma autoridade central é responsável pela distribuição dos endereços e por evitar conflitos,
normalmente essa autoridade é o administrador da rede. O administrador da rede é
responsável por determinar a faixa de endereços válidos e quais estão disponíveis.
32
Das atribuições de endereço IP, a manual é a mais trabalhosa e propensa a erros. É mais fácil
atribuir endereços inválidos ou repetidos quando essa atribuição é realizada por um ser
humano. A escalabilidade da rede fica comprometida pela atribuição manual, pois em caso
de reconfiguração da rede (troca da subrede por exemplo), se a rede for composta por
muitas máquinas, essa reconfiguração levará muito tempo para ser executada.
3.1.2 Servidor DHCP
O servidor DHCP (Dynamic Host Configuration Protocol) é uma forma automatizada,
portanto menos propensa a erros, de se atribuir endereços IP aos equipamentos.
O servidor é configurado com uma faixa de endereços válidos que pode distribuir aos
equipamentos requisitantes. Há duas formas básicas de se configurar um servidor para a
distribuição de endereços. A forma mais comum é tratar os equipamentos de forma
anônima e distribuir os endereços com o princípio “primeiro a chegar, primeiro a ser
servido” (first-come, first-served). Outra forma é distribuir um endereço IP específico para
cada equipamento de acordo com uma tabela que liga o endereço IP ao endereço MAC da
máquina. Esta tabela se encontra dentro do servidor.
Algumas vantagens da utilização do servidor DHCP são a confiabilidade, pois os servidor
garante que não haja dois equipamentos com o mesmo endereço IP na rede, e a
automatização na atribuição dos endereços, o que torna uma possível reconfiguração da
rede uma atividade mais veloz.
Uma das desvantagens é que o usuário comum não sabe configurar um servidor DHCP, o
que dificulta o uso de DHCP em redes em que não haja um administrador.
33
3.1.3 Auto-atribuição com IPv4LL
Auto-atribuição com IPv4LL (IPv4 Link Local) é a atribuição de endereço IP proposta pelo
ZeroConf. As atribuições anteriores, manual ou servidor DHCP, necessitam de uma
autoridade central para controlar a distribuição de endereços. Já na auto-atribuição com
IPv4LL, a seleção de endereços é feita de forma distribuída. Cada equipamento é responsável
por escolher um endereço e verificar se é possível utilizá-lo.
IPv4LL é um bloco de endereços definidos pelo RFC 3330 que só são válidos no domínio local
da rede, e tem o propósito de serem utilizados para a auto-atribuição de IP. Os endereços
IPv4LL estão compreendidos na subrede 169.254.0.0/16.
O protocolo ARP (Address Resolution Protocol) é normalmente utilizado para a resolução de
endereços IP em endereços MAC4. Entretanto, o protocolo ZeroConf faz uso de mensagens
ARP para a atribuição de endereços IP.
A atribuição de endereço IP se divide em duas partes: escolha do endereço IP e verificação
da unicidade de tal endereço. A escolha se dá de forma randômica de um endereço
compreendido de 169.254.1.0 a 169.254.254.255. A verificação da unicidade ocorre da
seguinte maneira: envia-se uma mensagem ARP com o endereço intencionado para a rede.
Se houver uma resposta a essa mensagem, significa que alguém já possui esse endereço,
portanto deve-se reiniciar o processo e escolher outro endereço. Se não houver resposta
após o envio de três mensagens ARP, entende-se que o endereço IP não está sendo
utilizado, portanto o endereço escolhido é único. Antes de começar a utilizar o endereço
escolhido, é necessário anunciar que o equipamento está utilizando aquele IP através de
outra mensagem ARP.
O bom funcionamento do protocolo depende da cooperação de todos os equipamentos da
rede. Uma das características do protocolo é ser descentralizado, adequando-o ao uso em
redes ad-hoc.
4
Endereço MAC é um endereço de 6 bytes, único, atribuído pelo fabricante da interface de rede com o
propósito de identificá-lo.
34
3.2 RESOLUÇÃO DE NOMES SEM DNS
Para o funcionamento da rede IP, é necessário que cada equipamento tenha seu endereço
IP, entretanto memorizar endereços IP não é uma atribuição fácil ao ser humano, assim os
endereços IP são normalmente relacionados a nomes. Surge então a necessidade de se
resolver nomes em endereços IP.
DNS (Domain Name System) é um sistema para nomeação de computadores e serviços de
redes usado para localizar computadores e serviços através de nomes de fácil compreensão.
O sistema associa o nome ao endereço IP do serviço.
3.2.1 Multicast DNS
No sistema de servidor DNS, o cliente faz uma requisição de resolução de nome para o
servidor, e esse responde com o endereço IP relativo ao nome. Uma alternativa mais simples
e barata para redes locais é o Multicast DNS (mDNS).
Multicast DNS funciona com a colaboração de todas as máquinas da rede. Quando uma
máquina faz uma query, ao invés de ela enviar para um servidor DNS ela envia para um
endereço IP multicast, assim todas as máquinas envolvidas no processo recebem essa query.
Cada máquina tem uma porção de software denominada Responder, responsável por
escutar as queries. Quando uma máquina escuta uma query que é para si, ela a responde,
como um servidor DNS convencional faria.
A atribuição de nomes com mDNS segue os mesmos princípios da auto-atribuição de
endereços IP. É escolhido um nome, e depois através das queries é verificado a unicidade
dos nomes. Em caso de nomes repetidos, pode-se pedir outro nome ao usuário ou anexar
números ao final do nome para diferenciá-lo do nome já existente.
35
A resolução de nomes ocorre de uma forma colaborativa, todas as queries e respostas são
enviadas ao endereço multicast 224.0.0.251 que é o endereço multicast reservado para o
protocolo mDNS.
3.3 BUSCANDO POR SERVIÇOS
Depois de se ter um endereço IP e um nome que referencia este endereço, tornando-o mais
fácil de se manipular, surge a necessidade de se conhecer os recursos oferecidos pela rede.
Em uma rede com diversos dispositivos é comum a oferta de diferentes serviços. Conhecer e
ter acesso aos serviços de forma automática, garante uma maior usabilidade da rede,
principalmente em redes ad-hoc que são muito dinâmicas, tornando a disponibilidade dos
serviços imprevisível.
Surge assim a descoberta de serviços. Os nomes que representam os serviços aparecem em
uma listagem, não necessitando mais decorar os nomes ou serviços existentes na rede. A
descoberta de serviços proporciona o conhecimento e melhor aproveitamento de todos os
serviços disponíveis na rede. Uma impressora, uma câmera, ou mesmo pessoas disponíveis
para conversar.
ZeroConf opta pela descoberta de serviços ao invés de descoberta de equipamentos, apesar
de ser sutil a diferença, a descoberta por serviços desacopla a necessidade de ser o mesmo
hardware oferecendo um serviço de impressão, por exemplo. Pode-se trocar a impressora,
mas o serviço oferecido é o mesmo. Mantendo-se o mesmo nome do serviço, garante-se ao
usuário que o serviço oferecido é o mesmo.
Outra característica da descoberta de serviço oferecida pelo ZeroConf é a noção de late
binding (ligação tardia). Como em muitos casos, decorre-se um tempo entre descobrir o
serviço e realmente utilizá-lo, o serviço só é associado ao seu endereço IP no momento da
utilização. Associar um serviço a seu endereço IP e porta é chamado de resolução de serviço.
36
A descoberta de serviços proposta pelo ZeroConf é baseada no DNS. As mensagens
envolvidas na descoberta e resolução de serviços são do mesmo formato de queries DNS. As
queries são do tipo SRV,PTR, A e TXT, já utilizadas pelos serviços DNS.
O DNS se utiliza de vários registros ou mensagens para a resolução de nomes. Desses
registros 4 são reutilizados pelo DNS-SD para a descoberta de serviço. O registro SRV contém
nome, porta do serviço e nome do host, é utilizado para o registro e resolução do serviço. O
registro PTR é na verdade um ponteiro, guarda o tipo de serviço e nome do serviço, é
através do registro PTR que é realizada a busca dos nomes dos serviços disponíveis. O
registro A guarda o endereço IP do serviço e o registro TXT é utilizado para informações
adicionais do serviço, como características dos serviços e informações de configurações.
Figura 4: Registros A, SRV e PTR
Na figura 4 temos o exemplo dos três registros principais preenchidos: A, SRV e PTR. No
registro A, observa-se o nome do host e o seu endereço IP. No registro SRV encontra-se o
nome do serviço,a porta e o nome do host. Já no registro PTR, encontra-se o tipo de serviço
e o serviço. Para a busca dessas informações, utiliza-se os registros não preenchidos, os
registros de resposta à busca são da forma preenchida. Os registros não preenchidos podem
ser observados na figura 5.
37
Figura 5: Registros não preenchidos
O mDNS é mecanismo responsável pela descoberta e resolução dos serviços utilizando essas
queries. Portanto, a descoberta de serviços não requisita mais implementação de código,
todo o código utilizado é o da implementação do mDNS.
Os serviços são classificados em tipos de serviços, para facilitar a busca. O tipo de serviço, na
maioria dos casos, é o protocolo utilizado pelo serviço. Alguns exemplos de tipos de serviços
são:
•
presença: Os serviços de presença anunciam a presença de um usuário, como em
uma aplicação de mensagem instantânea, apresentando uma lista de pessoas
disponíveis para conversar;
•
ipp: Para serviços de impressão que utilizam o protocolo de impressão Internet
Printing Protocol.
•
http: Para serviços que funcionam sobre o protocolo HTTP e pode ser visualizado em
um web browser.
Vale ressaltar que é possível registrar mais serviços à medida que são criadas aplicações
diferentes. Em (http://www.dns-sd.org/ServiceTypes.html) é possível acessar o RFC 2782 que
padroniza os nomes de tipos de serviços, e verificar a lista com todos os tipos de serviços já
registrados bem como orientações para o registro de novos tipos.
Qualquer API que implemente a descoberta de serviços precisa fornecer três operações
básicas: registrar, buscar e resolver. Uma aplicação de descoberta de serviços deve
possibilitar que se registre o serviço a ser anunciado, especificando o nome do serviço, o tipo
de serviço, seu endereço IP e sua porta. Deve também possibilitar buscar o serviço. Essa
busca deve ser feita por tipo de serviço, assim a relação de todos os serviços de determinado
38
tipo disponíveis na rede deve ser mostrada. E finalmente, resolver os serviços. Na busca de
serviços a operação realizada apenas lista os nomes dos serviços disponíveis, os nomes dos
serviços são descobertos através de trocas de mensagens do tipo PTR. Porém para se utilizar
os serviço é necessário saber seu IP e porta. Para se obter essas informações é necessário
uma nova operação que é chamada resolução de serviço, onde os dados do serviço
escolhido são descoberto através de trocas de mensagens do tipo SRV. A resolução do
serviço é feita no momento de se utilizar o serviço para garantir que os dados fornecidos
sejam atuais.
A descoberta de serviços para redes ad-hoc é uma ferramenta que torna a usabilidade da
rede muito maior. É comum, participantes de redes ad-hoc não conhecerem os outros nós
da rede e assim, não conhecerem os serviços disponíveis na rede. A descoberta de serviços
proporciona que sejam implementadas diversas aplicações que possam ser publicadas e bem
utilizadas pelos integrantes da rede.
3.4 IMPLEMENTAÇÕES
O protocolo de auto-atribuição com IPv4LL surgiu anteriormente ao padrão ZeroConf. As
primeiras implementações de IPv4 Link-Local apareceram no MAC OS 8.5, MAC OS X 10.0,
Windows 98 e no Linux através do ZCIP5. Clientes Multicast DNS podiam ser encontrados no
MAC OS 9.2, MAC OS X, no Windows através do Bonjour for Windows 6 e no Linux através do
NICTA. DNS-SD estava disponível no MAC OS X 10.2 em diante e no Linux através do projeto
open-source Darwin7.
Implementações ZeroConf são encontradas nas principais plataformas. A implementação
mais conhecida é a Apple Bonjour 8, seguida do Ahavi 9, a implementação ZeroConf para
Linux e BSD. Há também o Bonjour for Windows.
5
http://sourceforge.net/projects/zeroconf/
http://support.apple.com/en_US/downloads/#bonjour for windows
7
http://darwinsource.sourceforge.net/
8
http://developer.apple.com/opensource/
9
http://avahi.org/
6
39
Além de implementações para os principais sistemas operacionais, existem diversos projetos
open-source que disponibilizam APIs em diversas linguagens, para o desenvolvimento de
aplicações
ZeroConf.
Um projeto
open-source
bem
estruturado,
em
constante
10
desenvolvimento é o JmDNS , que implementa Multicast DNS em Java e disponibiliza uma
API para descoberta de serviços. Em python existe o projeto pyZeroConf11.
3.5 CONSIDERAÇÕES SOBRE O CAPÍTULO
ZeroConf oferece uma solução prática, simples e fácil de se implementar uma rede IP,
proporcionando ao usuário comum a habilidade de criar uma rede com o mínimo de
configuração e tendo a seu dispor a ferramenta de descoberta de serviço. Por ser um
protocolo que visa ser utilizado em equipamentos com pouca capacidade computacional
como câmeras e impressoras, é ideal para ser utilizados em redes de dispositivos móveis. A
descoberta de serviços proporciona que a rede seja muito mais fácil de utilizar e que seus
recursos sejam melhor utilizados. Com isso, pretende-se mostrar no próximo capítulo a
implementação de descoberta de serviços em celulares Android, para serem utilizados em
redes ad-hoc, através da API JmDNS.
Foi escolhida a API JmDNS por ela ser escrita em Java, o que facilita a adaptação para o uso
em Android, já que em Android se programa em Java Standard Edition com exceção da parte
gráfica. E também por ser uma API atual que está em constante aprimoramento.
10
11
http://jmdns.sourceforge.net/
http://sourceforge.net/projects/pyzeroconf/
40
4 IMPLEMENTAÇÃO
Como forma de concretizar e por em prática os estudos realizados neste trabalho, foi
realizada uma etapa de implementação. Nesta etapa visou-se a criação de redes ad-hoc com
suporte à descoberta de serviços utilizando-se como base uma plataforma móvel aberta.
Para essa implementação foi escolhida a plataforma Android pois, além de ser uma
plataforma open source, trata-se de uma tecnologia consideravelmente recente. Outro
aspecto motivador, é seu SDK que apresenta ferramentas que facilitam o desenvolvimento
de aplicações.
Como protocolo para descoberta de serviços foi utilizado o DNS Service Discovery, proposto
pelo padrão ZeroConf e implementado pela API open source JmDNS. Como foi dito
anteriormente, o padrão ZeroConf se adapta bem ao uso em redes ad-hoc, entre outras
razões por apresentar um protocolo de descoberta de serviços descentralizado. JmDNS foi
escolhida por ser um projeto open source ativo que apresenta frequentes melhorias, e
também por ser implementado em Java que é compatível com Android. A API compreende a
implementação de um Multicast DNS, com os registros DNS que são as mensagens trocadas
pelos nós para a descoberta dos serviços fornecendo também os métodos necessários para
o registro, descoberta e resolução dos serviços.
Este capítulo consiste numa explanação sobre a plataforma Android, sobre redes ad-hoc em
Android e sua implementação. Além disso, apresenta a API utilizada JmDNS e descreve as
duas aplicações teste desenvolvidas, de descoberta de serviços e de mensagem instantânea.
4.1 PLATAFORMA ANDROID
Google Android é uma plataforma open source para dispositivos móveis. É mantida pela
Open Handset Alliance (OHA), uma aliança composta por fabricantes de aparelhos móveis,
operadoras de celulares, fabricantes de semicondutores, empresas de softwares e empresas
de comercialização. A aliança tem como objetivos proporcionar inovações em dispositivos
41
móveis e melhor responder às necessidades do consumidor. São também aspirações da
aliança garantir aos desenvolvedores uma estrutura open source que possibilite uma maior
liberdade para o desenvolvimento e oportunidades de colaboração e aproveitamento de
código.
A plataforma foi lançada em novembro de 2007, sendo disponibilizado um Software
Development Kit (SDK), contendo todas as ferramentas necessárias ao desenvolvimento de
aplicações. De 2007 a 2011 foram lançadas 10 versões da plataforma e SDK, demonstrando
um rápido desenvolvimento e constante melhoria da plataforma.
As aplicações são desenvolvidas em Java, utilizando uma máquina virtual otimizada criada
especialmente para a plataforma. A SDK fornece diversas ferramentas para auxiliar o
desenvolvimento, como o emulador que permite o teste das aplicações, possibilitando o
desenvolvimento mesmo de quem não possui um aparelho Android.
4.1.1 Arquitetura
A pilha de softwares Android é composta por um kernel Linux, bibliotecas C/C++, Android
Runtime, framework de aplicações e a camada de aplicações como mostra a figura 6.
Figura 6: Arquitetura Android
42
Na base da pilha tem-se um kernel Linux 2.6 responsável pelos drivers, gerenciamento de
processamento e memória, segurança e gerenciamento de energia. Acima do kernel estão as
bibliotecas C/C++ como libc, biblioteca de mídia para áudio e vídeo, SGL e OpenGL para
gráficos 2D e 3D, WebKit para web browser, entre outras.
O Android Runtime é componente que roda as aplicações e junto às bibliotecas formam a
base do framework de aplicações. É composto por bibliotecas centrais e pela máquina virtual
Dalvik. As bibliotecas centrais provêem as funcionalidades disponíveis nas bibliotecas
centrais Java e também nas bibliotecas específicas Android e são implementadas em Java.
Dalvik é uma máquina virtual baseada em registradores que foi otimizada para rodar em
dispositivos móveis, ela substitui a Java Virtual Machine. Todo o hardware e serviços do
sistema são acessados através da máquina virtual, o que garante o desenvolvimento
independente de hardware. A máquina virtual executa Dalvik executable files (.dex), sendo
estes arquivos otimizados gerados a partir das classes Java.
O framework de aplicações fornece as classes utilizadas nas aplicações Android,
disponibilizando uma abstração para acesso ao hardware e gerenciamento para a interface
do usuário e recursos de aplicações.
Todas as aplicações, nativas ou de terceiros são construídas utilizando as mesmas
bibliotecas. As aplicações rodam no Android Runtime utilizando classes e serviços
disponibilizados pelo framework de aplicações.
4.1.2 Ambiente de Desenvolvimento
O SDK Android inclui diversas ferramentas para a criação, teste e debug dos projetos.
Compreendendo Android SDK and Virtual Device Manager, emulador, Dalvik Debug Monitor
Service (DDMS), Android Asset Packaging Tool (AAPT) e Android Debug Bridge (ADB).
Android SDK and Virtual Device Manager é uma ferramenta usada para criar dispositivos
virtuais para rodarem no emulador. Na criação dos dispositivos virtuais são atribuídas
43
características como nome, versão da plataforma e resolução de tela. É possível a criação de
vários dispositivos virtuais, constituindo assim vários cenários para testes de aplicações. Esta
ferramenta também é utilizada para a instalação e atualização de SDKs e seus componentes.
O emulador é uma implementação da máquina virtual Android que roda dispositivos virtuais
para o teste das aplicações desenvolvidas. O emulador provê o acesso a redes WiFi,
possibilitando o teste de aplicações na rede. Para a conexão entre duas instâncias do
emulador em um mesmo host é necessário o redirecionamento de portas. As limitações do
emulador compreendem conexões USB, captura de vídeo, simulação de bateria, Bluetooth e
multicast.
DDMS é uma ferramenta de debug que permite interagir com processos ativos, visualizar
pilha e heap de memória, visualizar e pausar threads, e explorar o sistema de arquivos, tanto
do emulador quanto de um aparelho Android.
AAPT é a ferramenta utilizada para construir o pacote de arquivos de extensão (.apk). É o
formato de distribuição de aplicações Android.
ADB é uma ferramenta que permite a conexão com o emulador ou aparelho. É composta por
um daemon que roda no emulador, um serviço que roda no hardware de desenvolvimento e
uma aplicação cliente (como o DDMS) que se comunica com o daemon através do serviço. O
ADB permite a instalação de aplicações, a manipulação de arquivos e a utilização de
comandos shell no emulador ou aparelho.
Para facilitar o desenvolvimento é utilizada a IDE (Integrated Development Environment)
Eclipse, uma IDE conhecida para o desenvolvimento em Java, juntamente com um plug-in
para Android chamado ADT (Android Development Tools). O plug-in incorpora as
ferramentas de desenvolvimento ao Eclipse.
44
4.2 AD-HOC EM ANDROID
Apesar de ser uma plataforma muito bem estruturada e oferecer diversos recursos ao
programador, a plataforma ainda é nova e apresenta alguns pontos que precisam ser
melhorados. Sendo uma plataforma open source, pode-se contar com a colaboração da
comunidade de desenvolvedores Android para as soluções de alguns problemas ainda não
resolvidos pelas versões oficiais da Google.
Um desses pontos falhos é a ausência de suporte a redes ad-hoc em Android. Somente o
WiFi infraestruturado é disponibilizado ao usuário. Não existem APIs que possibilitem a
criação e manipulação de redes ad-hoc.
Durante a pesquisa, foram encontradas duas soluções, propostas pela comunidade de
desenvolvedores, para este problema. A primeira envolve a alteração de arquivos de
configuração do WiFi do sistema, a segunda envolve a troca do sistema instalado no celular.
Acesso root, é um tipo de acesso ao sistema Linux que possibilita a modificação de arquivos
de configuração, entre outras modificações do sistema. Por motivos de segurança, em um
sistema Linux convencional só o administrador do sistema possui o acesso root. Em Android,
o usuário não tem acesso root ao sistema, o que impossibilita que certas alterações sejam
feitas no kernel Linux.
Para habilitar o celular a redes ad-hoc, pelas duas soluções encontradas é necessário
primeiramente garantir acesso root ao sistema. Isso é conseguido através de aplicações
disponibilizadas pela comunidade de desenvolvedores, por exemplo a aplicação “Universal
Androot” 12.
A
primeira
solução,
que
consistia
em
alterar
os
arquivos
de
configuração
wpa_supplicant.conf e tiwlan.ini, foi descartada pois era necessário definir o nome da rede
nos arquivos, ou seja, uma vez escolhida o nome da rede ad-hoc, o aparelho só reconheceria
a rede que tivesse aquele nome definido nos arquivos de configuração. Por se tratar de uma
solução limitada, ela foi descartada.
12
Disponibilizada em http://www.droidware.com.br/apks/UniversalAndroot_1.6.1.apk
45
A solução escolhida foi a troca do sistema Android do aparelho, por um sistema modificado
que reconhece as redes ad-hoc da mesma forma que reconhece as redes infraestruturadas.
Para o usuário, é transparente se a rede listada é ad-hoc ou infraestruturada.
O novo sistema a ser instalado chama-se CyanogenMod 13. Para cada tipo de aparelho, HTC
Magic ou Dream 14 por exemplo, há uma versão do sistema para ser instalada. Mais
informações de como executar essa troca é encontrada na documentação15 do projeto
CyanogenMod.
A troca do sistema é uma operação delicada, pois um erro no procedimento pode causar a
inutilização total do aparelho. Além disso, como a instalação depende do tipo do aparelho,
há diferentes formas de se instalar o novo sistema, o que requereu uma análise mais atenta
da forma adequada de se fazer a instalação.
Nenhuma das duas soluções, entretanto, possibilitam a criação da rede ad-hoc diretamente
do celular, o que se pode fazer é reconhecer a existência de uma rede ad-hoc e conectar-se a
ela. Uma solução ideal possibilitaria a criação de redes ad-hoc diretamente no aparelho,
permitindo a formação de uma MANET composta por celulares Android.
Foram efetuadas diversas tentativas da criação de redes ad-hoc diretamento dos celulares.
Em (JRADI; REEDTZ, 2010) encontra-se um roteiro para a criação dessas redes mas para
outros modelos de celular. Mesmo seguindo o roteiro, não foi possível a criação da rede.
Sendo necessária uma solução alternativa, onde os celulares se juntavam à uma rede já
existente.
A rede, portanto, foi inicializada por um netbook rodando ubuntu 10.4. O ubuntu oferece ao
usuário a possibilidade de criar redes ad-hoc, após criada, os celulares Android reconheciam
a rede e se conectavam à mesma.
Assim, foi possível a formação de rede ad-hoc com a participação de celulares Android. O
netbook serviu apenas como inicializador da rede, não interferindo nos outros experimentos
realizados. É importante salientar que a rede criada é single-hop, visto que a implementação
13
Encontrado em http://www.cyanogenmod.com/.
São modelos distintos de aparelhos Android que apresentam diferentes versões de SO e diferenças de
hardware, como presença ou ausência de teclado.
15
http://wiki.cyanogenmod.com/index.php?title=Main_Page
14
46
de roteamento apresentou-se como um desafio grande não havendo tempo hábil para
execução do mesmo âmbito deste trabalho.
Após estabelecida a rede, o próximo passo é a implantação da descoberta de serviços, para
facilitar o uso e reconhecimento de funcionalidades da rede. A implementação do autoendereçamento que também compõe o padrão ZeroConf, foge ao escopo desse trabalho,
sendo proposto como trabalho futuro.
4.3 JmDNS
Para o desenvolvimento da aplicação de descoberta de serviços foi utilizada a API JmDNS 16.
A API é um projeto open source e implementa em Java o multicast DNS e a descoberta de
serviços pelo protocolo DNS Service Discovery, propostos pelo padrão ZeroConf. É
importante ressaltar, que a API não implementa a auto-atribuição com IPv4LL.
A API oferece as funcionalidades de publicação, descoberta e resolução de serviços. Apesar
de não ser uma API específica para Android, ela foi compatível com o desenvolvimento em
Android. Somente um método da classe InetAddress mostrou-se incompatível com Android,
e foi substituído. Uma das desvantagens da API é a falta de documentação, que tornou o
trabalho muito mais custoso e demorado.
4.4 APLICAÇÃO DE DESCOBERTA DE SERVIÇOS
A aplicação desenvolvida, nomeada de “ZeroConf for Android”, tem o intuito de testar os
passos de publicação, descoberta e resolução de serviços. As telas principais da aplicação
são:
16
http://sourceforge.net/projects/jmdns/
47
(a)
(b)
(c)
Figura 7: (a) Tela inicial aplicação de descoberta de serviço (b) Tela de registro de serviço (c) Tela de descoberta de serviços
Na figura 7(a) temos a tela inicial, que dá as opções de registro de serviço ou descoberta de
serviços. Ao selecionar o registro de serviço, é apresentado ao usuário a figura 7(b), onde é
possível preencher os campos de nome do serviço, tipo de serviço e porta em que esse
serviço espera conexões. O nome do serviço é o identificador do serviço, caso haja dois
nomes iguais, um sufixo numérico é colocado no nome para diferenciá-lo. Ao selecionar a
descoberta de serviços, é apresentada ao usuário a interface ilustrada na figura 7(c), com a
listagem dos serviços existentes na rede.
Por motivos de simplificação da implementação, a aplicação de descoberta de serviços busca
por um tipo especifico de serviço. O tipo de serviço usado é o serviço de presença, que pode
ser utilizado, por exemplo, por aplicações de chat para notificar o status de presença do
usuário, on-line ou off-line. Esse serviço será exemplificado pela aplicação de mensagem
instantânea descrita posteriormente.
4.4.1 Cenário de Utilização da Aplicação
Alice está conectada à rede LPRM_ADHOC e deseja verificar se tem algum de seus colegas na
proximidade do CT IX. Pela aplicação ZeroConf for Android, faz uma busca por serviços de
presença. Na figura 8 pode-se verificar a tela inicial da aplicação de descoberta de serviços.
48
No lado direito da figura é ilustrada uma representação da rede ad-hoc estabelecida entre
Alice e os outros nós da rede, um registro PTR é enviado de forma multicast aos nós da rede
buscando por serviços de presença.
Figura 8: Alice busca por serviços
Como não há outros usuários registrados na rede, o registro PTR enviado anteriormente não
será respondido. Assim na figura 9, Alice descobre que não há serviços de presença sendo
anunciados. Quando a aplicação não encontra nenhum serviço fornece a mensagem “No
Services”.
Figura 9: Nenhum serviço encontrado
Alice decide assim, publicar sua própria presença e continuar seus afazeres, quando seus
amigos entrarem na rede, poderão verificar sua presença. Anunciar a presença significa
49
publicar a existência do serviço escrevendo o IP e porta do serviço num registro SRV como
pode ser verificado na figura 10. Esse registro SRV criado deve ser enviado aos nós da rede
também de forma multicast.
Um nome deve ser escolhido, o nome é o identificador único do serviço, assim é verificada a
unicidade do nome, caso contrário é adicionado um número a frente do nome para garantir
a exclusividade. A verificação e garantia de unicidade do nome é realizada pela API JmDNS
no momento do registro do serviço.
Figura 10: Alice registra serviço de presença
Passado um tempo, Bob se conecta à rede LPRM_ADHOC, abre sua aplicação de serviços, e
registra sua presença, como pode ser verificado na figura 11. Da mesma forma que a figura
anterior, é criado um registro SRV com todas as informações do serviço de presença de Bob.
Figura 11: Bob registra serviço de presença
50
Depois de registrada a presença, Bob decide verificar se há alguém disponível para
conversar, através da descoberta de serviços. Na figura 12, pode-se observar que Bob envia
um registro PTR buscando pelos serviços de presença publicados na rede.
Figura 12: Bob busca por serviços de presença
Bob descobre que Alice está presente. Como pode ser verificado na figura 13, Bob recebe
como resposta um registro PTR indicando que o serviço “alice” está disponível. Na tela de
descoberta de serviço são listados os serviços da rede.
Figura 13: Resultado de busca de serviços
Bob pretendendo iniciar uma conversa com Alice, clica na linha “alice._presence._tcp.local”
para a resolução desse serviço. Como ilustrado na figura 14, ao clicar na linha é enviado um
registro SRV com o nome do serviço, pedindo pelo IP e porta. A resolução é sempre
51
separada da descoberta do serviço, pois um serviço com mesmo nome pode assumir
endereços IPs diferentes dependendo do momento. Por exemplo, ao sair e entrar na rede,
pode ser atribuído outro endereço IP ao dispositivo que roda o serviço.
Figura 14: Resolução de serviço
Pela figura 15 observa-se que a resolução do serviço “alice” é executado. É possível conferir
o IP e porta do serviço de presença na tela da aplicação. Para a resolução do serviço, Alice
responde com um registro SRV completo, o mesmo usado para o registro de seu serviço.
Figura 15: Resultado da resolução de serviço
As informações de endereço IP e porta são suficientes para o funcionamento da aplicação de
mensagem instantânea. Entretanto, através do registro TXT, é possível descobrir
informações adicionais do serviço, como parâmetros e atributos de interesse do cliente. Por
52
exemplo, um serviço de impressão anunciado pode ter em seu registro TXT informações
sobre o tipo de impressão (laser ou jato de tinta) ou tinta disponível (preto e branco e/ou
colorida).
Após a resolução do serviço, é possível criar uma conexão TCP que proporcionará a troca de
mensagens entre os usuários.
4.5 APLICAÇÃO DE MENSAGEM INSTANTÂNEA
A aplicação de mensagem instantânea “IM Android” serve como prova de conceito. Utilizada
como uma ilustração da utilidade da descoberta de serviços, nesse caso do serviço de
presença. O serviço de presença é utilizado para o reconhecimento dos usuários da rede que
desejam que seu status on-line seja público.
Após escolher alguém para conversar através da aplicação ZeroConf for Android, é possível
iniciar uma conversa através de uma stream TCP com a porta e IP indicados. Só é possível
conversar com uma pessoa por vez. O propósito da aplicação é testar a possibilidade de
utilização do IP e portas anunciados.
A aplicação de mensagem instantânea foi escolhida devido a sua utilidade, uma das
funcionalidades mais básicas da rede é o de chat entre seus componentes, e também devido
a facilidade de implementação.
4.5.1 Cenário de Utilização da Aplicação
A aplicação de mensagem instantânea foi implementada como uma extensão da aplicação
de descoberta de serviços. Assim como pode-se observar na figura 16, na tela de resolução
de serviços aparece a opção de se conectar ao serviço ou recusá-lo. Bob, portanto, clica no
53
botão “connect”. Nesse momento são estabelecidos os sockets e os streams de texto para o
início da conversa.
Figura 16: Tela de conexão
Após o estabelecimento da conexão, é apresentada tanto a Alice quanto a Bob, a tela de
troca de mensagens. Como mostra a figura 17(a), a tela apresenta um setor com o histórico
das mensagens trocadas e outro para a escrita e envio das mensagens. Na figura 17(b),
pode-se observar o inicio da conversa, com o histórico mostrando as mensagens do próprio
usuário e as mensagens recebidas.
(a)
(b)
Figura 17: (a) Tela de troca de mensagens (b) Chat
54
Assim, a aplicação de mensagem instantânea está pronta para ser utilizada. Por
simplificação, só é possível conversar com um usuário por vez.
4.6 DIFICULDADES NA IMPLEMENTAÇÃO
Diversas dificuldades e limitações durante o curso das implementações realizadas tornaram
o estudo mais aprofundado e desafiador. A plataforma Android, apesar de ser bem
estruturada e apresentar uma SDK completa e robusta, ainda é muito recente. A literatura
disponível apresenta pouco material sobre conceitos e programação mais avançada. A
comunidade de desenvolvedores, que pode ser alcançada através de diversos fóruns,
também tem dificuldade em solucionar problemas mais complexos, encontrando-se sempre
soluções superficiais e não otimizadas para os problemas de assuntos como threads e
handlers (manipulador utilizado para a troca de mensagens entre as threads de background
e a thread da UI) e a API WiFi.
A troca constante de versões do sistema apesar de demonstrar uma evolução do sistema,
apresenta também uma instabilidade. É comum que de uma versão para outra algumas
bibliotecas sejam extintas, inativando algumas funcionalidades antes existentes.
O emulador não dá suporte a multicasting, o que impossibilitou os testes de serem
executados no SDK. Os testes foram executados em dois celulares um HTC Dream e um HTC
Magic, tornando o processo de testes mais demorado. Vale ressaltar que a instalação das
aplicações no celular é mais trabalhosa.
Com relação à adaptação da API JmDNS, como foi dito anteriormente, houve um método da
classe InetAddress utilizado pela API que em Android não é muito estável, de acordo com a
própria documentação do Android. O uso desse método causou uma falha da resolução dos
serviços. Era possível listar os serviços existentes, mas não era possível dizer seu IP e porta.
Assim até ser encontrado a razão desse problema, atrasou-se a implementação em algumas
semanas.
55
Houve a tentativa de criar uma rede ad-hoc diretamente dos celulares. Não foi possível a
criação da rede pois o aparelho não reconhecia a atribuição de endereço IP fixo. Apesar de
ser possível setar um endereço IP fixo, esse endereço não é reconhecido pelo próprio
sistema. Tornando assim, necessário o auxílio de outro sistema (netbook) para a criação da
rede ad-hoc.
4.7 CONSIDERAÇÕES SOBRE O CAPÍTULO
Este capítulo descreveu as atividades práticas realizadas envolvendo os conceitos estudados
de redes ad-hoc e descoberta de serviços. Inicialmente foi feita uma apresentação mais
detalhada do ambiente Android, que foi a plataforma de desenvolvimento móvel adotada.
Apesar de bem estruturada e oferecer um SDK completo, a plataforma é ainda recente. Por
isso, apresenta certas limitações, como a falta de suporte a redes ad-hoc de forma nativa. O
desenvolvimento para essa plataforma também fica comprometido, pois sua literatura
disponível sobre a programação avançada é escassa e trata os conceitos de forma
superficial.
As atividades práticas realizadas consistiram na habilitação ao reconhecimento de redes adhoc pelos dispositivos Android e a implementação de aplicações para serem usadas nas
mesmas. A solução encontrada para habilitar os celulares à redes ad-hoc consistiu na troca
do sistema operacional do aparelho por uma versão implementada pela comunidade de
desenvolvedores. Nessa versão, as redes ad-hoc existentes podem ser visualizadas
juntamente com as redes infraestruturadas.
As aplicações desenvolvidas foram baseadas no padrão ZeroConf e utilizaram a API JmDNS,
que implementa o multicast DNS e DNS Service Discovery do padrão ZeroConf em Java.
A primeira aplicação desenvolvida, ZeroConf for Android dá suporte a descoberta de
serviços às redes ad-hoc formadas por dispositivos Android. A descoberta de serviços é
importante pois proporciona um melhor aproveitamento dos recursos disponíveis na rede,
principalmente em redes ad-hoc que são dinâmicas e os nós variam bastante. Neste caso
56
específico, a aplicação se destina a descoberta de serviços de presença, serviços tais que são
usados na segunda aplicação desenvolvida: IM Android.
IM Android é uma aplicação de mensagem instantânea adaptada ao uso em redes ad-hoc.
Ao invés de possuírem uma lista de amigos, os usuários publicam e descobrem serviços de
presença. O serviço de presença informa quais usuários da rede estão disponíveis ao chat. A
aplicação de mensagem instantânea é um exemplo da utilidade da descoberta de serviços,
vários outros serviços podem ser implementados e incorporados à aplicação de descoberta
de serviços.
57
5 CONCLUSÕES E TRABALHOS FUTUROS
Este trabalho apresentou um estudo focado em três assuntos principais correlacionados:
dispositivos móveis, redes ad-hoc móveis e descoberta de serviços. Esses assuntos foram
escolhidos devido à situação atual de desenvolvimento das tecnologias de hardware e
software de dispositivos móveis que impulsionaram o uso de redes móveis e redes ad-hoc
móveis. A descoberta de serviços, apesar de já existir em redes cabeadas, ganha maior
relevância e utilização no contexto de redes ad-hoc, devido a sua importância para a boa
utilização dessas redes.
O desenvolvimento de aplicações e soluções para dispositivos móveis requer um maior
cuidado na implementação devido às limitações dos recursos desses dispositivos (CPU,
memória, bateria) e também devido ao tamanho reduzido de telas e teclados. Apesar dessas
diferenças em relação a sistemas desktop, as plataformas móveis vêm sendo melhoradas,
facilitando a migração de programas desktop para celulares. Além disso, o suporte a redes
WiFi ou mesmo ad-hoc tem sido cada vez mais promovido.
As pesquisas em redes ad-hoc atuais se concentram no problema do roteamento. Pois o
comportamento dinâmico da rede e a imprevisibilidade de sua topologia, o torna um dos
maiores desafios. Assim, não há um protocolo de roteamento que se destaque em relação
aos outros.
A descoberta de serviços é utilizada em redes infraestruturadas e ad-hoc, entretanto tem
uma maior relevância no contexto das redes ad-hoc. A descoberta de serviços se mostra
essencial pela dificuldade de se conhecer previamente os nós da rede ad-hoc visto que pode
haver uma alta rotatividade dos nós que a formam. Portanto, para se conhecer os serviços
disponíveis na rede e poder utilizá-los, se faz necessário algum mecanismo de descoberta e
anúncio de serviços.
Dos protocolos estudados, o que o escolhido para o desenvolvimento da aplicação foi o DNS
Service Discovery, proposto pelo padrão ZeroConf. Pois o DNS-SD é um protocolo
descentralizado, que utiliza de mensagens multicast e colaboração dos componentes da
58
rede para a descoberta de serviços. Essas características propiciaram sua aplicação a redes
ad-hoc.
O padrão ZeroConf além de propor um protocolo de descoberta de serviços, especifica o
Multicast DNS que é o mecanismo utilizado na descoberta de serviços, e também propõe a
auto-atribuição de endereços IP. A auto-atribuição também pode ser implementada para
redes ad-hoc, porém sua implementação fugiu ao escopo desse trabalho devido à limitação
de tempo.
Além dos estudos teóricos realizados, o trabalho consistiu em uma parte prática para teste
dos conceitos estudados. Foi então escolhida a plataforma móvel Android o
desenvolvimento de aplicações e para o uso de redes ad-hoc.
Android é uma plataforma recente, lançada em 2007. É open source, dispõem de uma SDK
completa que facilita o desenvolvimento de aplicações e a linguagem utilizada para a
programação é Java. Entretanto, a plataforma apresenta algumas limitações, como por
exemplo não suportar nativamente a criação e uso de redes ad-hoc. Mesmo assim, acreditase no potencial da plataforma Android e que com o amadurecimento do sistema, poderá se
tornar uma das plataformas mais populares e estáveis.
Devido à limitação do suporte nativo a redes ad-hoc pelos celulares Android, foi necessário
habilitar os celulares para oferecer este suporte. Através da comunidade de
desenvolvedores, foi possível encontrar uma versão não oficial do sistema Android, cujas
modificações possibilitavam o reconhecimento de redes ad-hoc existentes. Assim, os
celulares Android, após serem atualizados com essa nova versão do sistema foram capazes
de se juntarem a redes ad-hoc pré-existentes. O problema da criação de uma rede ad-hoc
por um celular Android não foi solucionado, ficando dependente de novas melhorias do
sistema.
Foram implementadas duas aplicações para a plataforma Android. Uma aplicação de
descoberta de serviços para ser utilizada em redes ad-hoc e uma aplicação de mensagem
instantânea que usa a descoberta de serviços no seu funcionamento.
Ambas as aplicações foram desenvolvidas com o auxílio da API JmDNS, que se trata de um
projeto open source que implementa o Multicast DNS e o DNS Service Discovery do padrão
59
ZeroConf. A API foi escolhida por ser de código aberta, ser escrita em Java, além de ser um
projeto que encontra-se ativo e em constante melhoria. A falta de documentação da API
dificultou a implementação das aplicações, aumentando consideravelmente o tempo de
desenvolvimento das mesmas. Após superada a curva de aprendizado da API, ela facilitou
muito a implementação das aplicações.
A aplicação de descoberta de serviços possibilita o anúncio e descoberta de serviços de
presença, que são serviços que anunciam a presença de algum usuário da rede. Na
descoberta de serviços é possível verificar quais usuários estão disponíveis na rede,
descobrindo também IP e porta para a comunicação com esses usuários.
As aplicações de descoberta de serviços e mensagem instantânea estão fortemente
relacionadas, pois a segunda utiliza os serviços de presença descobertos pela primeira.
Através das informações de IP e porta é realizada uma conexão entre os usuários, que
podem assim trocar mensagens de texto.
O desenvolvimento para celulares é uma área bastante promissora. Por ser recente a
popularização desses dispositivos, há ainda muitos problemas específicos de computação
móvel e redes ad-hoc móveis. Este estudo teve um caráter exploratório, e com o estudo
pôde ser observada a correlação entre os temas apresentados.
5.1 TRABALHOS FUTUROS
Ficam como sugestões de trabalhos futuros:
•
A criação de redes ad-hoc formada unicamente por celulares Android. O estado
atual de desenvolvimento das versões oficiais e não oficiais do Android, não
permitem a criação de redes ad-hoc diretamente pelos celulares, por enquanto só é
possível aderir a uma rede já existente;
•
A implementação de roteamento para redes ad-hoc em Android. Devido à extensão
do trabalho de implementar o roteamento e a falta de tempo, as redes ad-hoc multihop não puderam ser implementadas;
60
• Atribuição automática de endereço IP com IPv4LL. Na solução apresentada, os
endereços IPs são distribuidos pelo servidor DHCP do netbook responsável pela
criação da rede ad-hoc. Uma rede ad-hoc composta somente por celulares
necessitará de atribuição automática ou manual de endereço IP, sendo aquela mais
aconselhável.
61
REFERÊNCIAS
CHESHIRE, S.; STEINBERG, D.H. Zero Configuration Networking: The Definitive Guide. EUA:
O’Reilly, 2005.
CONTI, M.; GIORDANO, S. Multihop Ad Hoc Networking: The Theory. IEEE Communications
Magazine, v. 45, n. 4, p. 78-86, 2007.
GIORDANO, S. Mobile Ad-Hoc Networks. In: STOJMENOVIC, I. Handbook of Wireless
Networks and Mobile Computing. John Wiley & Sons, 2002.
JRADI, R.K.; REEDTZ, L.S. Ad-hoc network on Android. 2010. Monografia (Graduação em
Informática) – Informatics and Mathematical Modeling, Techinical University of Denmark,
Dinamarca.
RICHARD III, G.G. Service Advertisement and Discovery: Enabling Universal Device
Cooperation. IEEE Internet Computing, v. 4, n. 5, p. 18-26, 2000. p. 398-404.
SU, J.; GUO, W. A Survey of Service Discovery Protocols for Mobile Ad Hoc Networks. In:
International Conference on Communications, Circuits and Systems, 2008.
VERVERIDIS, C.N.; POLYZOS, G.C. Service Discovery for Mobile Ad Hoc Networks: A Survey of
Issues and Techniques. IEEE Communications Survey & Tutorials, v. 10, n. 3, p. 30-45, 2008.