Choix d’implémentation

Le prototype a été réalisé en Java. Les nœuds légers sont représentés par des iPAQ H3950 et

pour les nœuds centraux, nous avons utilisé des ordinateurs de type PIII. La machine

virtuelle choisie est celle de Personal Java qui est adaptée au développement d’applications

sur terminaux nomades. Le type de réseau utilisé est Wifi 802.11b et le réseau filaire a

également été exploité pour la connexion entre les différents nœuds centraux. La distribution

entre les différents services de localisation est gérée par l’API JNDI (JNDI – Java Naming

Directory Service). Les communications entre les différents nœuds de l’applicatio n sont

gérées en utilisant des sockets. En effet, l’utilisation intensive d’une technologie telle que les

Java RMIs (RMI – Remote Method Invocation) pose des problèmes de surcharge au niveau

des terminaux nomades qui se bloquent alors rapidement.

Concerna nt la découverte de ses nœuds voisins, un serveur multicast est géré par chaque

nœud de l’application. Ce serveur est activé lorsque l’utilisateur souhaite participer à

l’application : rechercher ou partager de l’information. Ce serveur est implémenté à l’aide

d’une socket en « écoute » sur une adresse de groupe multicast. L’adresse de groupe

multicast est définie pour l’application. Lorsqu’un nœud souhaite mettre à jour son

environnement, un message est envoyé sur cette adresse de groupe. Les nœuds connectés

sont alors prévenus et envoient grâce à une socket unicast, leurs informations. Les mises à

jour des informations concernant les voisins d’un nœud sont effectuées à intervalles définis

par le profil de mobilité de l’utilisateur : plus l’utilisateur est mobile, plus l’intervalle de

temps entre deux mises à jour est réduit.

La diffusion des informations au sein d’ISLANDS repose également sur l’utilisation de

groupes multicasts auxquels les nœuds s’inscrivent s’ils sont susceptibles d’être intéressés

par les informations diffusées dans un groupe particulier.

5. Synthèse

De nombreuses topologies peuvent être envisagées dans le cadre d’une application de

proximité ; en effet, dans une application de commerce électronique de proximité, par

exemple, le nombre de nœuds varie considérablement en fonction des heures de la journée.

Pour évaluer notre solution de localisation, nous avons envisagé différents types

d’environnements et testé notre solution dans ces environnements :

- Environnement dense où le nombre de noeuds est important (environ un noeud sur 2m²

par exemple).

- Environnement peu dense

- Environnement bien connecté : où il n’existe qu’une seule sphère de communication

pour l’ensemble des participants.

- Environnement peu connecté : plusieurs sphères existent et chaque participant peut ne

pas être en mesure de communiquer avec tous les autres participants.

- Environnement où l’ensemble des localisations est exprimé en données physiques : ces

localisations peuvent cependant être soit estimées (via notre algorithme), soit issues

d’une technologie de géo- localisation.

- Environnement où l’ensemble des localisations est exprimé en données symboliques :

ces localisations peuvent cependant être soit estimées (via notre algorithme), soit exactes

(décrites par l’utilisateur).

- Environnement mixte où les localisations sont représentées à la fois par des données

physiques et symboliques.

Pour chaque environnement, des tests d’évaluation des requêtes dépendantes de la

localisation ont été effectués grâce au prototype implémenté. Les résultats obtenus sont

globalement concluants. L’évaluation d’une LDQ basée sur notre solution d’estimation de la

localisation fournit de bons résultats dans la majorité des environnements. Toutefois, pour

certaines configurations, notre solution peut présenter quelques limites que nous décrivons

ci-dessous.

Salle 1 Salle 2

A

B

C

Figure 6.8.a. Exemple de répartitions

Salle 1 Salle 2

A

B

C

P1

P2

Figure 6.8.b

Une des premières constatations est que dans un environnement dense, il devient impossible

de différencier les différents noeuds voisins lorsque l’on a atteint le grain de représentation le

plus fin (la pièce par exemple), si la localisation est représentée en données symboliques.

Cette constatation est cependant à relativiser : si on a atteint le grain de représentation le plus

fin, la marge d’erreur est négligeable (quelques mètres si la structure choisie pour la

représentation symbolique est finement décrite).

La deuxième constatation concerne la différence de résultats entre un traitement basé sur des

localisations symboliques fixes et un traitement basé sur des localisations physiques issues

d’une technologie de géo- localisation : nous obtenons des différences puisque pour la

représentation en données physiques, nous calculons la distance exacte entre les différents

noeuds sans prendre en compte les obstacles : murs, sols etc. Ainsi comme l’illustre la figure

6.8.a, si on recherche le voisin le plus proche de A : la réponse est B dans le cas d’une

représentation symbolique et C sinon. En nous basant sur cette constatation, il peut être

intéressant lorsque cela est possible, de choisir le type de données de localisation utilisé en

fonction de l’environnement dans lequel on se situe, pour mieux répondre aux requêtes. Par

exemple, s’il s’agit d’un grand hall, sans obstacle, où le grain utilisé pour la représentation

en données symboliques n’est pas extrêmement fin, on favorise le traitement en données

physiques et inversement.

La troisième constatation concerne l’estimation de la localisation basée sur des données

symboliques : l’estimation utilise la « distance » qui sépare un noeud de ses différents

voisins. La comparaison des fichiers est quant à elle une comparaison entre représentations

symboliques. Si le noeud se trouve à la limite d’une section géographique, la réponse peut

être erronée : par exemple, dans la figure 6.8.b, le noeud A recherche le produit P le plus

proche de lui mais il ne connaît pas sa localisation. Donc, suivant l’algorithme d’estimation

de la localisation, la localisation de A est représenté par une liste de couples (localisation,

degré d’approximation) où la localisation de C risque d’être en première position avec le

degré le plus petit. L’évaluation de la requête repose ensuite sur une comparaison des

données symboliques et donc, va retourner comme réponse que le produit P le plus proche

est le produit P2 se situant dans la salle 2. Cependant, comme le calcul du degré

d’approximation repose sur le signal entre deux machines, les obstacles sont pris en compte

et cette erreur est souvent atténuée.

A ^B

P1

P2

Connexion

Pas de connexion

Figure 6.9. Exemple de répartition de noeuds

Et enfin, la dernière constatation est que dans un environnement faiblement connecté, notre

algorithme d’estimation de la localisation peut entraîner des réponses erronées. Comme

l’illustre la figure 6.9, si A recherche le produit P le plus proche de lui, sa localisation est

basée sur la localisation de B puisque B est le seul noeud connecté à A, il obtient donc, en

réponse, le produit P2.

6. Conclusion

Le prototype a permis dans un premier temps de valider le service de localisation ISLANDS

et plus particulièrement le modèle d’évaluation des requêtes dépendantes de la localisation.

Quelques limites ont été mises en évidence dans un environnement peu connecté : dans ce

cas, l’application de proximité utilise plusieurs sphères de communication et l’accès à

l’ensemble des informations disponibles dans l’application devient impossible.

La première version du prototype a également permis de mettre en évidence certaines limites

et nous a aidé à définir quelles contraintes étaient à considérer pour proposer des

optimisations adaptées. En effet, les contraintes en terme de temps de réponse et de

consommation des ressources sont importantes à considérer dans les applications de

proximité. En particulier, l’autonomie des terminaux nomades s’est avérée très

problématique. D’autre part, les expérimentations effectuées grâce au prototype ont été

utilisées pour le calibrage de nos simulations d’optimisations. Une version évoluée du

prototype est actuellement en cours de développement. Cette version intègre l’ensemble des

optimisations proposées dans les chapitres précédents.

Actuellement, nous étudions également la possibilité de développer et de déployer ce

prototype au sein d’une gare de la région Nord Pas de Calais. L’application de commerce

électronique de proximité doit être adaptée à l’environnement d’une gare. Cette expérience

nous permettra de mettre en évidence et de résoudre d’autres problématiques intéressantes

telles que la montée en charge et le déploiement automatisé. Le matériel dont nous

disposions ne nous a pas permis, pour le moment, d’aborder ces problématiques.

Dans le document Requêtes dépendantes de la localisation : Expression, évaluation et optimisation (Page 130-136)