MobUser - Distributed Systems Group - INESC-ID

MobUser: Uma plataforma para partilha de
informação centrada no utilizador para
dispositivos móveis
Mauro Silva, João Leitão, Carlos Ribeiro
[email protected], [email protected], [email protected]
INESC-ID, Instituto Superior Técnico, Universidade Técnica de Lisboa
Resumo Dispositivos móveis com capacidade de comunicação sem fios
são uma constante na nossa vida quotidiana. Este facto introduz a possibilidade destes dispositivos trocarem informação que assista o utilizador
nas suas tarefas quotidianas. Consideremos, por exemplo, a troca de
informação sobre pontos de interesse em locais comummente frequentados pelo utilizador. Seria útil o suporte de aplicações que efectuassem
essa troca, de forma descentralizada (tendo apenas como suporte interacções entre pares), sem qualquer interacção por parte do utilizador
e sem recorrer a uma entidade centralizada, protegendo dessa forma informação potencialmente sensı́vel do utilizador. No entanto, as actuais
soluções não são adequadas para tal visto que a grande maioria dependem de algum tipo de centralização (sejam brokers ou nós que servem
de ponto de encontro), as soluções encontradas que não dependem deste
tipo de arquitectura apresentam um grande custo visto que são baseadas
em soluções de publicação/subscrição baseadas em conteúdo.
Para enfrentar este desafio, apresentamos neste artigo o MobUser, um
novo serviço de publicação-subscrição baseado em tópicos especialmente
adaptado para suportar operações conscientes da localização para dispositivos móveis de forma descentralizada. Mostramos, através de simulações, que o MobUser oferece melhor desempenho e maior taxa de
entrega de eventos, usando o cenário previamente descrito como caso de
estudo, quando comparado com outro sistema de publicação/subscrição
para ambientes móveis.
1
Introdução
Os dispositivos móveis com capacidade de comunicação sem fios são uma
constante na nossa vida diária e os utilizadores esperam que os seus dispositivos
tenham acesso constante a informação.
Embora o acesso a servidores centralizados por dispositivos móveis possa ser
dispendioso e, por vezes, mesmo impossı́vel, os dispositivos cruzam-se constantemente com outros que podem ter informação útil. Uma vez que estes dispositivos
têm um alto nı́vel de mobilidade, a informação disseminada pelos mesmos tem
a possibilidade de ser propagada para localizações distantes sem a necessidade
de soluções centralizadas.
1
Este artigo surgiu de uma ideia para uma aplicação móvel, similar ao ’Foursquare’1 ,
cujo desenho não requeira um componente centralizado. Com esta aplicação os
dispositivos seriam capazes de trocar informação relativa a pontos de interesse
entre si de forma a que, quando um utilizador sentisse necessidade de procurar
algo, a informação já estaria guardada no seu dispositivo.
Para conseguir desenvolver esta aplicação, a abstracção proporcionada pelos
sistemas de publicação/subscrição adequa-se perfeitamente aos requisitos, uma
vez que permitem uma comunicação independente do tempo, do espaço e de
sincronização[1]. Além disso, os sistemas de publicação/subscrição baseados em
tópicos, também apresentam a vantagem de poder filtrar informação que não
irá ser útil ao utilizador subscrevendo apenas tópicos que façam parte dos seus
interesses.
A disseminação de informação numa rede com altos nı́veis de mobilidade e
com dispositivos que, por várias razões (entre as quais limitações de energia),
não estão constantemente conectados, apresenta alguns custos. Por exemplo, é
complexo assegurar nı́veis elevados de fiabilidade sem propagar constantemente
informação, e para todos os vizinhos, dessa forma inundando a rede[2].
Este artigo apresenta um algoritmo de disseminação de eventos que concretiza
um sistema de publicação/subscrição baseado em tópicos para redes sem fios ad
hoc e compara o mesmo com uma solução existente na literatura[2]. Resultados
experimentais demonstram que o nosso algoritmo apresenta um alto nı́vel de
fiabilidade, o que se traduz no facto de os subscritores receberem os eventos nos
quais estão interessados com elevada probabilidade, mesmo quando existe um
grau de conectividade baixo na rede ad hoc.
Visto o nosso algoritmo não assumir qualquer protocolo de encaminhamento,
é facilmente adaptável para várias tecnologias de comunicação sem fios (como
Bluetooth ou 802.11). A sua inerente escalabilidade provém deste se basear em
trocas entre-pares.
O resto do artigo está organizado da seguinte forma: a Secção 2 apresenta trabalho relacionado relevante. A Secção 3 motiva, apresenta e descreve o MobUser.
Na Secção 4 avaliamos e comparamos o nosso trabalho com uma das soluções
descritas na literatura e, por fim, a Secção 5 conclui o artigo.
2
Trabalho Relacionado
Esta secção introduz soluções existentes que à primeira vista se poderiam adequar ao problema abordado neste artigo. Primeiramente, apresentamos alguns
algoritmos de disseminação epidémica para redes ad hoc. De seguida, examinamos algumas soluções existentes de publicação/subscrição em redes ad hoc.
2.1
Disseminação epidémica em redes ad hoc
Algoritmos de comunicação epidémica são uma classe de algoritmos em que
periodicamente um nó escolhe um conjunto de nós vizinhos para trocar in1
https://foursquare.com/about/new
2
formação. Especificamente para redes ad hoc foi proposta no passado a variante
de Opportunistic Gossip[3], na qual a mobilidade dos nós é aceite e usada como
forma de disseminar a informação em locais distantes (similar à nossa solução).
Outro algoritmo de disseminação epidémica para redes ad hoc que usa a mobilidade dos nós para potenciar o seu funcionamento é o Autonomous Gossip[4],
que tem propriedades semelhantes ao nosso sistema porém neste sistema os dados são tratados como um organismo vivo e o perfil do dispositivo é visto como
uma descrição do ecossistema do dispositivo. Neste sistema os dados competem
pela memória de acordo com o perfil dos dispositivos. Esta solução, no entanto
pode levar a que grande parte da comunicação feita seja para obtenção de dados
inúteis, o que faria com que o dispositivo gastasse bateria sem ganho para o
seu utilizador. Adicionalmente, os tópicos com percentagem de subscrição baixa
tendencialmente não são disseminados, afectando assim a fiabilidade do sistema.
2.2
Sistemas de publicação/subscrição em redes ad hoc
O JEDI[5] é um sistema de publicação/subscrição que permite, explicitamente, mobilidade. Contudo, este sistema tem um suporte de mobilidade bastante limitado, baseando-se essencialmente em duas operações: moveOut e moveIn.
Estas operações permitem aos nós explicitamente mover-se na topologia da rede,
não sendo adequado ao nosso problema.
Existe algum interesse em permitir um crescente nı́vel de mobilidade em
sistemas de publicação/subscrição para redes ad hoc[6,7,8,2] porque a natureza
independente do paradigma de publicação/subscrição é especialmente eficaz para
este tipo de redes. Porém a maioria dos estudos publicados foca-se em sistemas
baseados em conteúdo[6,9], incorrendo em custos adicionais elevados, ou confiam
em arquitecturas com algum tipo de centralização (como o uso de brokers ou
de nós que servem como ponto de encontro)[6], sendo por isso inadequados a
ambientes com elevada mobilidade e sem infraestrutura.
Algumas soluções como o SpiderCast[7] e o Sub-2-Sub[8] apresentam sistemas
de publicação/subscrição baseados em tópicos que são totalmente distribuı́dos.
Porém estes baseiam-se na construção de redes sobrepostas que apresentam elevado custo de manutenção em ambientes de elevada mobilidade. Adicionalmente,
visto que as redes sobrepostas são criadas de acordo com tópicos, os eventos de
tópicos com baixa subscrição dificilmente chegarão aos interessados, visto ser
improvável que estas redes sobrepostas sejam conexas.
O trabalho que mais se assemelha ao nosso é o Mobility Friendly Publish/Subscribe (MFPS)[2], esta solução difunde o seu perfil (tópicos aos quais
subscreve) e a sua velocidade actual com um intervalo de tempo configurável.
Quando um ou mais dispositivos estabelecem contacto trocam mensagens com
os identificadores únicos dos eventos que possuem. Posteriormente usam essa
informação para trocar os eventos que tenham tópicos de interesse dos vizinhos
e que os vizinhos ainda não tenham. Os autores declaram que assumem que o
identificador é de tamanho muito reduzido quando comparado com a informação
transferida, porém para que um identificador seja razoavelmente único num sistema distribuı́do de larga escala e de forma a não ser necessária uma entidade
3
central que os emita, o tamanho do identificador pode não ser desprezável. No
nosso trabalho experimental usamos este algoritmo como termo de comparação
com a nossa solução.
Um aspecto negativo a todas as soluções discutidas previamente, é a sua
baixa fiabilidade para tópicos com baixo número de subscrições.
3
MobUser
Nesta secção, descrevemos o MobUser. Começamos por apresentar o modelo assumido, seguido de uma perspectiva global do protocolo, introduzindo os
componentes principais da nossa solução. Seguidamente descrevemos detalhadamente cada componente.
3.1
Modelo de sistema
Descrevemos agora o modelo de sistema assumido neste trabalho.
O sistema visa operar numa área com mobilidade de estilo urbano. Neste
modelo os dispositivos são móveis e têm capacidade para comunicar directamente
entre si quando se encontram no raio de alcance de cada um. Assumimos que os
dados trocados entre dispositivos são guardados parcialmente nos dispositivos
(existe limite de memória associada aos dispositivos).
A rede é assumida como sendo totalmente ad hoc sem qualquer dispositivo
de infraestrutura presente. O número de dispositivos com os quais cada dispositivo consegue comunicar varia constantemente e não está restrito quanto a um
número máximo.
É assumido que os dispositivos tenham energia, memória e processamento
limitado.
3.2
Perspectiva Global
A nossa solução usa o sistema de detecção de vizinhos que for disponibilizada
pela tecnologia de comunicação em utilização (e.g. Wireless ou Bluetooth). Caso
essa tecnologia não disponibilize tal serviço mas disponibilizar um meio de difusão de mensagens podemos simplesmente usar esse serviço para difundir o
nosso interesse em comunicar.
O funcionamento da nossa solução baseia-se numa tarefa recorrente que é
executada com um intervalo configurável. Esta tarefa procura dispositivos com
os quais possa trocar informação. Cada dispositivo tem um perfil que consiste no
conjunto de tópicos nos quais o seu utilizador está interessado, ou seja, os tópicos
subscritos pelo utilizador. Os tópicos são definidos na altura da implementação
do sistema e conhecidos globalmente. Quando um novo vizinho é encontrado
ambos trocam perfis gerados nessa altura com base na procura dos tópicos que
cada um tem registado e no perfil que têm armazenado.
Após a troca dos perfis os dispositivos trocam qualquer evento que pertença
a um tópico subscrito pelo seu vizinho e armazenam os eventos recebidos nas estruturas de dados apropriadas. Os eventos são caracterizados por um nome, um
4
tópico, uma estampilha temporal, uma localização e uma reputação. Os eventos
podem ser guardados em três listas, a lista de eventos recentes, a lista de eventos populares e a lista de eventos irrelevantes. Estas listas são listas ordenadas
sendo que a sua ordenação depende da lista. A função da lista de eventos recentes é armazenar os eventos recebidos mais recentemente, logo está ordenada
do mais recente para o menos recente. A função da lista de eventos populares é
armazenar os eventos com maior reputação e, portanto, está ordenada do evento
com maior reputação para menor reputação. A função da lista de eventos irrelevantes é auxiliar a disseminação de eventos pertencentes a tópicos menos
subscritos mantendo os eventos que foram retransmitidos menos vezes. A informação da quantidade de vezes que foram retransmitidos está codificada na
reputação e, como tal, esta lista está ordenada do evento com menor reputação
para o evento com maior reputação.
3.3
Armazenamento de eventos
No armazenamento de eventos os eventos são verificados e caso pertençam a
um tópico que não foi subscrito no perfil gerado são descartados. Caso pertençam
ao perfil gerado, mas não ao perfil definido pelo utilizador então são guardados
na lista de eventos irrelevantes caso exista espaço livre para tal.2 Se os eventos
pertencerem ao perfil do utilizador é feita uma pesquisa na lista de eventos recentes e populares, caso o evento exista na lista de eventos recentes esse evento
é transferido para a lista de eventos populares e a sua reputação é aumentada.
Caso exista na lista de eventos populares, a sua reputação é aumentada. Caso
não exista em qualquer uma das listas, o evento é adicionado à lista de eventos
recentes. No caso de qualquer uma das listas estar cheia o novo evento simplesmente toma o lugar do evento que está em último lugar na ordenação referida
anteriormente.
3.4
Disseminação
A fase de disseminação começa por descobrir os vizinhos com qual o dispositivo consegue contactar. Para cada vizinho descoberto é gerado um perfil
temporário (perfil gerado) que consiste em adicionar à lista de tópicos definidos
pelo utilizador os tópicos com menos procura. Esta procura é uma visão subjectiva de cada dispositivo recolhida através de contadores associados aos tópicos
que denota o padrão dos perfis que o dispositivo recebeu no passado. O perfil
gerado é partilhado com o dispositivo vizinho. O facto de adicionarmos os perfis
menos procurados no sistema tem dois efeitos, ofuscar o perfil real do utilizador,
dificultando assim a tarefa de associar um perfil de utilizador ao seu dispositivo,
e também facilitar a difusão de eventos associados a tópicos menos subscritos.
Visto que os identificadores usados neste sistema são apenas para efeitos de comunicação, podemos ainda gerar novos identificadores após cada interacção ou
após um conjunto de interacções. Isto é implementado no protótipo desenvolvido,
2
Os detalhes de geração do perfil encontram-se mais a frente no texto
5
mas que não é apresentado devido a limites de espaço, onde mudamos o endereço
MAC entre interacções para dificultar ainda mais a associação de um perfil a
um dispositivo fı́sico.
Quando um dispositivo recebe o perfil de outro, responde com o seu perfil e
também procura nas três listas já referidas por eventos que estejam de acordo
com o perfil recebido. Caso sejam encontrados eventos cujo tópico esteja contido
no perfil do vizinho, esses eventos são enviados para o mesmo. Este envio pode
ser feito de duas maneiras, de forma aglomerada, em que todos os eventos são
enviados no mesmo pacote, ou de forma interactiva, em que cada dispositivo tem
de enviar um evento antes de receber o próximo. A vantagem de enviar todos os
eventos no mesmo pacote é pouparmos em termos de comunicação. A vantagem
de enviar de forma interactiva é que previne comportamento egoı́sta, em que um
dispositivo apenas recebe informação e nunca a envia.
Cada evento enviado da lista de eventos irrelevantes tem a sua reputação
aumentada por cada envio. Após a disseminação dos eventos segue-se uma fase
de armazenamento de eventos que segue os procedimentos descritos na secção
anterior.
4
Avaliação
Nesta secção apresentamos a avaliação da nossa solução, bem como os detalhes de cada teste efectuado. Começamos por descrever o simulador utilizado, de
seguida apresentamos as configurações comuns a todos os testes e, por fim, os
resultados obtidos.
4.1
Ambiente de teste
Para avaliar a nossa solução simulámos o nosso algoritmo usando o Network Simulator (v2.35)(também conhecido por NS2)3 . Para criar os modelos de
movimento utilizamos o BonnMotion (v2.0)[10] com o modelo de movimento
Manhattan Grid.
4.2
Configurações comuns
Simulámos os protocolos como um Agent do NS2, que usa directamente a
camada MAC do 802.11b. Definimos como alcance máximo da antena 10 metros,
uma vez que o nosso protocolo é suposto ser possı́vel de executar em qualquer
dispositivo móvel, sendo que as duas tecnologias de comunicação sem fios mais
utilizadas nos dispositivos móveis são o 802.11 e o Bluetooth.
O modelo de propagação usado foi o Two-Ray Ground, uma vez que se trata
do modelo usado pela solução com a qual comparamos o desempenho do nosso
sistema. Os valores usados para RXThresh , para definir o alcance da antena, do
NS2 foram calculados usando a ferramenta threshold contida no próprio NS2.
Para gerar os padrões de movimento usamos o modelo já referido, com as
seguintes propriedades:
3
http://www.isi.edu/nsnam/ns/
6
– Número de segundos ignorados do inı́cio da simulação: 3600. Este
valor foi usado uma vez que é o valor padrão do BonnMotion para todos os
cenários.
– Altura e largura da área de simulação: 300 metros, excepto nos testes
de densidade.
– Número de dispositivos simulados: 100.
– Probabilidade de mudança de velocidade: 20%.
– Velocidade mı́nima: 0.5m/s e Velocidade média: 1m/s. Estes valores
foram escolhidos de acordo com [11].
– Probabilidade de parar: 0%.
– Probabilidade de mudar de direcção: 50%.
– Numero de quarteirões por dimensão: 15, excepto nos testes de densidade. Este valor foi escolhido de forma a criar quarteirões de 20 metros não
permitindo assim que dispositivos em ruas paralelas consigam comunicar.
A avaliação experimental tem como principal objectivo medir a fiabilidade e a
quantidade de dados transmitidos. Definimos a fiabilidade como a percentagem
de eventos publicados que chega aos dispositivos que subscreveram ao tópico
desse evento. Os resultados apresentados resultam da execução de 10 testes independentes com diferentes padrões de movimento. Em todos os gráficos apresentados, com excepção dos gráficos da evolução de fiabilidade, são representados
os intervalos de confiança para um alfa de 0,01. Em todos os testes o intervalo
de tempo entre pesquisas por novos vizinhos foi configurada para 300 segundos
para o nosso sistema. Para o Mobility Friendly Publish/Subscribe (MFPS)[2]
esse intervalo varia entre 150 e 450 segundos, sendo que, como o MFPS usa a
velocidade dos nós à sua volta para calcular o seu intervalo, a média está nos
300 segundos.
4.3
Resultados
Nesta secção começamos por apresentar o resultado experimental que nos
permitiu escolher a melhor configuração para o nosso sistema. De seguida, apresentamos resultados que analisam o comportamento das soluções em três dimensões distintas: Tempo, Probabilidade de Subscrição e Densidade. Começamos
por analisar o comportamento das soluções ao longo do tempo, passando para
uma análise do comportamento com diferentes probabilidades de subscrição a
um determinado tópico e finalizamos com uma análise com diferentes densidades
de nós.
Configuração do sistema Visto que o sistema tem um limite máximo de
memória, começamos por determinar a melhor proporção de tamanhos para as
listas de eventos anteriormente descritas. Para tal, criamos um teste em que
todos os nós subscrevem o mesmo tópico, e todos os nós publicam um evento
nesse tópico. Estipulamos um valor máximo de 20 eventos no total para guardar
em memória e definimos os valores máximos de cada lista para 10% do total
para a lista de eventos irrelevantes, e alteramos o máximo da lista de eventos
7
recentes para ir de 10 a 80%, sendo que a lista de eventos populares ocupa o
espaço de sobra. O ambiente foi simulado durante uma hora. De acordo com os
resultados experimentais a configuração com melhores resultados é 70% para a
lista de eventos recentes e 20% para eventos populares.
(a)
(b)
Figura 1. Em (a) temos a evolução de fiabilidade com o tempo, e em (b) temos a
evolução da quantidade de dados transmitidos com o tempo.
Tempo Após averiguar a melhor configuração para o nosso sistema, avaliamos
a fiabilidade dos sistemas ao longo do tempo. Para avaliar essa evolução efectuamos simulações de 1, 4, 8, 12 e 24 horas. Os resultados estão apresentados
na Figura 1(a). Neste teste todos os dispositivos subscrevem ao mesmo tópico
e cada um publica um evento para esse mesmo tópico. A linha com o nome
MobUserFlood representa um sistema que, como o nosso, apenas procura por
vizinhos com um intervalo de 300 segundos, mas não tem qualquer limite de
memória e troca sempre todos os eventos que tem com os seus vizinhos, independentemente de subscrições. Esta alternativa pretende averiguar a fiabilidade
máxima que se pode obter no nosso sistema. É usado o limite máximo, tanto
para o nosso sistema como para o MFPS, de 20 eventos guardados em memória,
sendo que no caso do nosso sistema esses 20 eventos estão repartidos pelas três
listas de eventos na proporção já descrita (10% para irrelevantes, 20% para populares e 70% para recentes). As Figuras 1(a) e 1(b) mostram claramente que a
nossa solução oferece melhor fiabilidade com um custo de comunicação similar.
Podemos também observar que o nosso sistema providencia uma entrega muito
mais rápida, sendo que cerca de 90% dos subscritores tinham recebido o evento
após 5 horas e meia em comparação com o MFPS que apenas se aproxima dos
90% de entrega após 16 horas.
8
(a)
(b)
Figura 2. Em (a) temos a evolução de fiabilidade com a probabilidade de subscrição,
e em (b) temos a evolução da quantidade de dados transmitidos com a mesma.
Probabilidade de Subscrição Após este teste focamo-nos na fiabilidade com
diferentes percentagens de subscritores para um tópico. Para tal alteramos a
probabilidade de um dispositivo subscrever a um dado tópico variando entre 100
a 10%. As simulações para este teste simulam quatro horas de actividade. Para
cada ponto deste teste, cada dispositivo tinha uma determinada probabilidade
de subscrever a um tópico. Caso subscrevesse então publicava um evento para
esse mesmo tópico. Como é possı́vel observar na Figura 2(a), apenas 10% de
espaço usado para eventos que não são relevantes para o dispositivo em si torna
o sistema muito menos vulnerável a alterações de subscrição. Podemos ver que
no caso do MFPS, com uma probabilidade de 10% de subscrição o resultado
tem um intervalo de confiança de 71% a 94% o que demonstra que está bastante
dependente da topologia. No nosso caso, quando a probabilidade de subscrição
baixa, os resultados são menos variáveis, demonstrando uma menor dependência
da topologia. É interessante reparar que a fiabilidade aumenta com probabilidades de subscrição mais baixas. Isto ocorre porque para probabilidades mais
baixas de subscrição existem menos eventos produzidos e a necessitar de entrega.
É tambem importante notar a evolução que ambos os protocolos têm com
subscrições baixas. Podemos ver na Figura 3 que o MobUser apresenta uma
evolução na fiabilidade mais rápida, sendo que cerca de 2000 segundos após o
inicio da simulação, quase todos os subscritores recebem o evento. O MFPS tem
uma evolução lenta e altamente dependente da topologia.
Densidade Finalmente, avaliamos a fiabilidade do nosso sistema para densidades de nós variáveis. A configuração deste teste é semelhante ao anterior, com
a excepção que o tamanho de cada lado da área de simulação varia entre 100 e
1000 metros. Podemos ver na Figura 4(a) que o MobUser é menos afectado pela
densidade que o MFPS. Com densidades mais baixas, a fiabilidade do MobUser
é similar à da variante MobUserFlood, que como descrito anteriormente não
tem limites de memória. A Figura 4(b) mostra que o MobUser tem um custo de
9
(a)
(b)
Figura 3. Evolução da fiabilidade ao longo do tempo com diversas probabilidades de
subscrição, em (a) temos o MFPS, e em (b) temos o MobUser.
(a)
(b)
Figura 4. Em (a) temos a evolução de fiabilidade com a densidade, e em (b) temos a
evolução da quantidade de dados transmitidos com a mesma.
10
comunicação maior comparativamente com as alternativas. Isto deve-se à troca
de perfis efectuada pelo nosso sistema. No entanto, este custo adicional não é
significativo.
(a)
(b)
Figura 5. Evolução da fiabilidade ao longo do tempo com diversas densidades, em (a)
temos o MFPS, e em (b) temos o MobUser.
Mais uma vez podemos verificar na Figura 5 que a latência na entrega dos
eventos no nosso sistema é menor.
Efectuamos também testes usando o padrão de movimento Random Waypoint, que não apresentamos devido a limites de espaço. Estes testes revelam
resultados consistentes com os apresentados anteriormente.
5
Conclusão
Apresentámos neste artigo um algoritmo de disseminação de eventos que
implementa uma solução de publicação/subscrição baseada em tópicos. Este algoritmo foi desenhado para redes sem fios ad hoc e tem como base trocas entrepares. Motivo pelo qual tem uma inerente escalabilidade e descentralização. A
11
nossa solução não só suporta mobilidade como a alavanca para disseminar a
informação em locais distantes. Contribuı́mos também com uma estrutura de
armazenamento de eventos que não só assegura que o uso da memória é limitado
mas também permite que eventos de tópicos com baixa percentagem de subscrição possam ser disseminados. Os resultados experimentais demonstram que
o MobUser apresenta melhor fiabilidade, menor latência na entrega dos eventos
e um uso mais eficiente da bateria, quando comparado com o [2]. Estimamos que
soluções que tenham como base comunicação com redes sobrepostas apresentem
resultados inferiores devido ao custo de manutenção das mesmas.
Referências
1. Eugster, P.T., Felber, P.A., Guerraoui, R., Kermarrec, A.M.: The many faces of
publish/subscribe. ACM Comput. Surv. 35(2) (June 2003) 114–131
2. Baehni, S., Chhabra, C.S., Guerraoui, R.: Mobility Friendly Publish/Subscribe.
Technical report (2004)
3. Friedman, R., Gavidia, D., Rodrigues, L., Viana, A.C., Voulgaris, S.: Gossiping
on manets: the beauty and the beast. SIGOPS Oper. Syst. Rev. 41(5) (October
2007) 67–74
4. Datta, A., Quarteroni, S., Aberer, K.: Autonomous gossiping: A self-organizing
epidemic algorithm for selective information dissemination in wireless mobile adhoc networks. In Bouzeghoub, M., Goble, C., Kashyap, V., Spaccapietra, S., eds.:
Semantics of a Networked World. Volume 3226 of Lecture Notes in Computer
Science. Springer Berlin / Heidelberg (2004) 126–143 10.1007/978-3-540-301455 8.
5. Cugola, G., Di Nitto, E., Fuggetta, A.: The jedi event-based infrastructure and
its application to the development of the opss wfms. Software Engineering, IEEE
Transactions on 27(9) (sep 2001) 827 –850
6. Baldoni, R., Beraldi, R., Cugola, G., Migliavacca, M., Querzoni, L.: Structure-less
content-based routing in mobile ad hoc networks. In: Pervasive Services, 2005.
ICPS ’05. Proceedings. International Conference on. (july 2005) 37 – 46
7. Chockler, G., Melamed, R., Tock, Y., Vitenberg, R.: Spidercast: a scalable interestaware overlay for topic-based pub/sub communication. In: Proceedings of the 2007
inaugural international conference on Distributed event-based systems. DEBS ’07,
New York, NY, USA, ACM (2007) 14–25
8. Voulgaris, S., Rivière, E., Kermarrec, A.M., Van Steen, M.: Sub-2-Sub: SelfOrganizing Content-Based Publish and Subscribe for Dynamic and Large Scale
Collaborative Networks. Rapport de recherche RR-5772, INRIA (2005)
9. Fiege, L., Gärtner, F.C., Kasten, O., Zeidler, A.: Supporting mobility in contentbased publish/subscribe middleware. In: Proceedings of the ACM/IFIP/USENIX
2003 International Conference on Middleware. Middleware ’03, New York, NY,
USA, Springer-Verlag New York, Inc. (2003) 103–122
10. Aschenbruck, N., Ernst, R., Gerhards-Padilla, E., Schwamborn, M.: Bonnmotion:
a mobility scenario generation and analysis tool. In: Proc. of the 3rd International
ICST Conference on Simulation Tools and Techniques. SIMUTools ’10, ICST, Brussels, Belgium, Belgium, ICST (Institute for Computer Sciences, Social-Informatics
and Telecommunications Engineering) (2010) 51:1–51:10
11. Tarawneh, M.S.: Evaluation of pedestrian speed in jordan with investigation of
some contributing factors. Journal of Safety Research 32(2) (2001) 229 – 236
12