Projet de fin d étude Intergiciel de communication pair-à-pair utilisant de la synchronie virtuelle. Jérémy Cheynet Yann Sionneau

Transcription

1 Projet de fin d étude Intergiciel de communication pair-à-pair utilisant de la synchronie virtuelle Jérémy Cheynet Yann Sionneau 26 janvier 2011

2 Table des matières 1 Présentation du projet Le principe de fonctionnement de l API Architecture standard Architecture répartie Middleware de communication L API Le jeu I Comparaison des différents middleware Choix de l un d entre eux 7 2 Spread Résumé des fonctionnalités Facilité d installation et de mise en œuvre des exemples Qualité de la documentation, du support et du code source Disponibilité sur Android, iphone et réseau ad hoc Autre Appia Résumé des fonctionnalités Facilité d installation et de mise en œuvre des exemples Qualité de la documentation, du support et du code Disponibilité sur Android, iphone et réseau ad hoc Autre JGroups Résumé des fonctionnalités Facilité d installation et de mise en œuvre des exemples Qualité de la documentation, du support et du code Disponibilité sur Android, iphone et réseau ad hoc Autre Middleware choisi : JGroups Justification du choix Portage sous Android Les problèmes rencontrés Le multicast sous Android Le scheduler et le retransmitter incompatibles avec Android Exemple Draw et Touchsurface Exemple SimpleChat

3 II API 17 6 Remote Object API basée sur JGroups Analyse de l API Structure de l API Test de l API Exemple Exemple Validation du code III Bilan 20 7 Conclusion Les objectifs atteints Le travail restant Manuel Utilisation du port Android de JGroups Télécharger les sources Compiler les sources Utilisation des jars Utilisation de JGroupsRemoteObject Télécharger les sources Compiler les sources Utilisation des jars Utilisation de PlayManagementAPI

4 Introduction De nos jours, les applications sont de plus en plus réparties. Par exemple, git, qui est un système de gestion de version (un peu comme svn) est répartie. Il n y a pas de serveur centralisé. D autres part, le nombre de smartphones ne cesse d augmenter. Il y a de plus en plus d applications et de jeux qui fonctionnent sur Android ou sur iphone. Le but de notre projet est justement de travailler sur une API permettant de créer des jeux en réseau sur Android, mais de telle manière que toutes les données du jeu soient réparties sur les différentes machines des joueurs. 3

5 Chapitre 1 Présentation du projet 1.1 Le principe de fonctionnement de l API Architecture standard Un jeu standard fonction de la manière suivante : 1. Le joueur 1 se connecte et crée son personnage (un objet local) 2. Le joueur 2 se connecte et crée lui aussi son personnage 3. Le joueur 1, désirant attaquer le joueur 2, envoie à celui-ci une information lui signalant qu il vient de l attaquer avec x points de dégât 4. Le joueur 2 recevant cette information, met à jour son personnage (objet local) et renvoie au joueur 1 les informations dont il a besoin pour continuer de jouer Les objets correspondant aux personnages sont donc locaux (comme le montre la figure 1.1 à la page 4). Dès que l on fait une action sur un autre joueur, on lui envoie l action, et c est lui qui fait le calcul pour nous renvoyer le résultat. FIGURE 1.1 Architecture standard Architecture répartie Il existe un autre point de vue, qui est de répartir tous les objets sur tous les clients. La partie se déroule donc de la manière suivante : 1. Le joueur 1 se connecte et crée son personnage (un objet local) 2. Le joueur 2 arrive et demande qui est présent 3. Le joueur 2 demande au joueur 1 son personnage, et crée le sien avant de l envoyer au joueur 1 4. Le joueur 1, voulant attaquer le joueur 2, lui envoie cette information, avec le nombre de points de dégats qu il lui inflige 5. Le joueur 1 calcul, en local, la nouvelle valeur du joueur 2 (puisqu il a le nombre de points de dégat à infliger et l objet) 6. Le joueur 2 recevant l information va lui aussi mettre à jour son personnage. 4

6 Ainsi, dans cette structure, on limite le nombre de messages diffusés sur le réseau pendant la partie. Cependant, nous consommons plus de mémoire puisque tous les joueurs ont tous les objets en local (comme le montre la figure 1.2 à la page 5). FIGURE 1.2 Architecture répartie 1.2 Middleware de communication La première partie de notre projet consiste à choisir parmi plusieurs API de communication celle qui convient le mieux à notre problème. Pour cela, nous allons analyser et comparer les points forts, les points faibles, et les points qui nous paraissent important des 3 APIs suivantes : JGroups [1] Spread [2] Appia [3] 1.3 L API L API de jeu est basée sur plusieurs API plus petites. Parmi ces petites API de base se trouvent les API Remote Object API et Play Management API. Notre travail sur ces APIs consiste à les développer pour qu elles puissent communiquer à distance, en utilisant le middleware de communication que nous aurons choisi. L API repose donc sur Play Management API et Remote Object API. Play Management API utilise, en plus de notre middleware (JGroups), Remote Object API. Quant à Remote Object API, il utilise seulement JGroups (comme le montre la figure 1.3 à la page 5). FIGURE 1.3 Structure de l API 5

7 1.4 Le jeu A terme, l objectif est d implémenter un petit jeu qui fonctionne sur Android et qui utilise notre API. 6

8 Première partie Comparaison des différents middleware Choix de l un d entre eux 7

9 Le première étape de ce projet est de choisir un middleware de communication parmi 3 choix possibles : 1. Spread 2. Appia 3. JGroups Nous avons donc étudié ces différents middleware pour savoir lequel serait le plus adapté pour le développement de notre application. Pour cela nous avons pris en compte plusieurs paramètres pour chacun d entre eux, comme : Les fonctionnalités du middleware La facilité d installation du middleware et la facilité d utilisation des exemples La qualité de la documentation de l application, ainsi que la qualité du support (salon IRC, mailing list, bug tracker, etc...) et du code source La disponibilité du code source sur iphone ou sur Android La possibilité d utiliser l application sur un réseau ad hoc Et d autres paramètres comme le type de license 8

10 Chapitre 2 Spread 2.1 Résumé des fonctionnalités Spread est une application pour faire de l unicast, du multicast et du multigroup-multicast. Il est aussi fait pour être utilisé avec plusieurs langages différents dont (python, perl, ruby, java, C/C++). Il utilise une infrastructure du type client serveur. Pour l utiliser, il faut donc commencer par lancer un daemon qui tourne sur un serveur, et ensuite, lancer plusieurs clients qui vont se connecter à ce serveur pour faire de la diffusion de messages. 2.2 Facilité d installation et de mise en œuvre des exemples Pour l installation, il faut télécharger les sources et les compiler. En suivant le Userguide, on y arrive assez facilement. Lancer les exemples est un peu plus complexe : en effet, il faut d abord lancer le serveur, mais avec la bonne configuration, pour que les clients puissent s y connecter. Nous n avons malheureusement pas réussi à faire communiquer un client avec le serveur. Ce dernier se lançait bien, mais la configuration n était pas la bonne, et nous ne savions pas pourquoi. 2.3 Qualité de la documentation, du support et du code source Ce point d analyse du middleware est excellent. Il y a : Un Userguide : Il est disponible pour chacune des API en fonction du langage que l on utilise. Une F.A.Q. : Une F.A.Q. 1 qui permet d avoir les réponses aux questions de base. Une mailing list : Celle-ci est à jour, et bien utilisée. Un bug tracker : On peut signaler un bug par mail à partir du site aux développeurs. Un dépot svn : Il permet de télécharger des sources à jour, en plus d avoir accès aux différentes versions. Quand au code en lui même, il est bien fait et bien documenté, ce qui le rend facilement lisible. 2.4 Disponibilité sur Android, iphone et réseau ad hoc L API spread est disponible dans plusieurs langages différents (dont java et C/C++). Elle est donc utilisable à la fois sous téléphone Android, mais aussi sous iphone. Il existe un site web pour le portage de l API spread sur Android (http ://spreadandroid.com), mais celui-ci est vide à l heure actuelle. De plus, étant donné qu elle est implémenté par-dessus la couche TCP/IP 2, elle peut fonctionner sur un réseau ad hoc. 2.5 Autre Spread est opensource et utilise une license spreadlicense basée sur une license BSD Foire Aux Questions 2. Transmission Control Protocol / Internet Protocole 3. Berkeley Software Distribution License 9

11 Chapitre 3 Appia 3.1 Résumé des fonctionnalités Appia est un outil de développement permettant d avoir une couche de communication opensource. Il est constitué d un coeur de communication basé sur le protocole TCP/IP. Ensuite, on peut choisir différentes options lorsqu on l utilise. Cela permet entre autres d avoir des groupes de communication, un broadcast atomique, une garantie de l ordre d envoi et de réception des messages, Facilité d installation et de mise en œuvre des exemples Il est très facile de lancer l exemple de base. Pour cela, il suffit de créer un nouveau projet Java sous Eclipse, et d importer les librairies jar d Appia. Ensuite, il suffit de configurer le mode connexion (soit en utilisant des arguments, soit avec un fichier xml) et de lancer l application. 3.3 Qualité de la documentation, du support et du code Si vous faites une recherche sur google pour trouver de la documentation sur Appia, vous trouverez beaucoup de choses, mais rien sur Appia. Ce qui pose pas mal de problèmes pour l utilisation. De plus, le bugtracker est vide et la mailing list est quasiment inexistante (avec 11 personnes). Enfin, si vous voulez contacter les développeurs, il vous faudra écrire une jolie lettre à envoyer par la poste, car seule une adresse postale est disponible sur le site de l API. Par contre, la partie haut niveau de l application est bien codée. 3.4 Disponibilité sur Android, iphone et réseau ad hoc L application étant faite en Java, elle est portable sur Android. Pour iphone, avec du JNI 1 /JNA 2, il est probablement possible de faire le portage. Enfin, l API utilise la couche TCP/IP, il est donc tout à fait possible de l utiliser sur un réseau ad hoc. 3.5 Autre Ce middleware est sous license GPL Java Native Interface 2. Java Native Access 3. General Public License 10

12 Chapitre 4 JGroups 4.1 Résumé des fonctionnalités Il s agit d une API pour utiliser le multicast IP en Java. On peut utiliser d autres options comme envoyer des messages point à point, le choix du protocole réseau (TCP, UDP 1, JMS 2 ), rajouter du cryptage ou une politique d ordonnancement. De plus, cette API gère la fragmentation des messages pour que ceux-ci arrivent en entier, et dans le bon ordre. 4.2 Facilité d installation et de mise en œuvre des exemples On peut facilement importer l archive jar dans notre programme et lancer un des exemples fourni. Une autre solution possible est d importer directement les sources dans le projet. De plus, de très nombreux exemples sont disponibles comme l exemple Draw (que nous verrons un peu plus loin) ou Simple- Chat (chat entre plusieurs utilisateurs). 4.3 Qualité de la documentation, du support et du code Il existe un manuel disponible sur le site internet de JGroups [1] et de nombreux tutoriaux. De plus, une grande quantité de documentation est disponible sur internet. Il existe de nombreux tests de performance : 52 tests unitaires 11 tests de performance 10 stress tests 65 autres tests Enfin, il y a plusieurs solutions pour contacter rapidement les développeurs : Salon IRC : il y a peu de monde sur le canal IRC 3 (une dizaine de personne), mais ces personnes sont très actives et répondent rapidement aux questions Plusieurs mailing lists : Celles-ci sont actives. Un bug tracker 4.4 Disponibilité sur Android, iphone et réseau ad hoc Le code de cette application étant fait en Java, il est possible de l utiliser sur Android. De plus, Jonas Ådahl a déjà fait un portage de JGroups sur Android disponible sur son dépot git [4]. Pour le portage de l APi sur iphone, il est peut-être possible d utiliser JNI/JNA pour utiliser le Java sur iphone. Enfin, pour l aspect réseau ad hoc, cela ne pose aucun soucis puisque l application utilise la couche IP. 1. User Datagram Protocol 2. Java Message Service 3. Internet Relay Chat 11

13 4.5 Autre Cette API est sous license LGPL Lesser General Public License 12

14 Chapitre 5 Middleware choisi : JGroups 5.1 Justification du choix Une fois que nous avions analysé chacune des trois API, nous avons dû en choisir une. Plusieurs points sont importants dans le choix du middleware. Le tableau suivant (tableau 5.1) permet d avoir pour chaque critère, les points forts et les points faibles de chacune des API. Type de Test \ API Spread Appia JGroups Fonctionnalités Facilité d installation Mise en oeuvre des exemples Serveur facile Client plus complexe API de communication Simple à partir des jars Configurer les arguments ou le fichier xml et lancer le programme Simple à partir des jars Bien configurer le classpath avec le code source Simple, et exemples nombreux Qualité de la documentation UserGuide UserGuide bien fait Rien sur internet Canal IRC actif Bonne (Bug tracker, Mailing liste et bug traqueur Qualité du support Mailing listes activent mailing list, svn, etc...) quasi inexistant Bug tracker Adresse postale Disponibilité sous Android Oui Faisable car code en java Portage déjà fait en partie Disponibilité sous iphone Oui JNI / JNA JNI / JNA License SpreadLicense (Basée du BSD) GPL LGPL TABLE 5.1 tableau récapitulatif Voici les points vraiment importants qui doivent être analysés : Fonctionnalités : dans notre cas, nous avons besoin d une application répartie. Donc Spread qui fonctionne en mode Client Serveur n est pas recommandé pour notre application. Qualité de l API : ici, c est Appia, qui ayant très peu de documentation et quasiment aucun support, gagne un mauvais point. Disponibilité sous Android : les 3 middlewares on une implémentation en Java, donc portable sous Android. De plus, JGroups a déjà un portage effectué sous Android, ce qui lui permet de gagner un point. License : Il faut que cela soit totalement libre, et la license GPL est contaminante, donc un mauvais point pour Appia. C est pour toutes les raisons précedentes, que nous avons décidé d utiliser JGroups comme API de communication. 5.2 Portage sous Android Le portage sous Android ne fut pas une tâche si difficile qu il peut paraitre au final, mais qui a bien failli se solder par un échec à cause des problèmes de multicast qui seront évoqués plus tard dans ce rapport. 13

15 En effet, un Suédois du nom de Jonas Ådahl avait déjà porté une vieille version de JGroups sur Android 1.5 (plutôt ancien), nous avons pu ainsi nous inspirer des modifications qu il a fait afin de porter la toute dernière version de JGroups pour la dernière version d Android (2.3) ainsi que de rendre ce portage rétro-compatible avec les versions 2.1 et 2.2 d Android. Les sources du portage de Jonas Ådahl sont disponibles sur son compte github, ce qui nous a permis de regarder ses commits et de pouvoir voir ce qui a été modifié, c est à dire pas grand chose en réalité. Ceci dit entre temps JGroups a bien évolué et nous avons eu quelques modifications assez conséquentes en supplément à faire, comme enlever toutes les références à java.jmx ainsi qu à MBean. De plus Jonas Ådahl était très disponible sur gtalk, nous avons pu lui parler à maintes reprises, il répondait volontier à nos questions quand il le pouvait. Nous avons aussi reçu l aide de Bela Ban, un Suisse travaillant pour JBoss (Red Hat), cette personne n étant ni plus ni moins que le créateur et mainteneur de JGroups! En effet Bela était assez présent sur IRC et répondait très rapidement à nos messages par ou sur le salon #jgroups sur le réseau IRC FreeNode. Au final le portage n a pas été aussi difficile que nous l avions craint, en particulier grâce à ces quelques aides. Il fonctionne de manière satisfaisante d après nos tests. Le portage de l application de Démonstration Draw sur Android (renommée Touchsurface pour l occasion) a par exemple pris 2 fois plus de temps que le portage de l API JGroups en elle même! Il semble que le portage ait été apprécié dans la communauté du logiciel libre. En effet plusieurs personnes ont manifesté leur intérêt et leur gratitude pour ce portage pour Android sur les deux articles de blogs que Yann a dédié à ce portage sur son blog personnel[5]. De plus le créateur de JGroups (Bela Ban) a consacré un article aussi au portage et à l application Touchsurface sur son blog personnel [6]. 5.3 Les problèmes rencontrés Le multicast sous Android Le support du multicast sous Android reste pous nous un mystère, après une longue investigation il en ressort que depuis Android 1.5 le multicast est censé être supporté officiellement. Il existe une classe dans l API Android java.net.multicastsocket présente dès la première version de l API. Cependant après de nombreux tests, en suivant des tutoriels et des codes conseillés, nous n avons pu qu envoyer des paquets UDP multicast, mais jamais en recevoir (aucun paquet IGMP d inscription à un groupe multicast n était jamais envoyé par le téléphone). Ces tests ont bien sûr été faits à l aide de Wireshark afin de voir les paquets sortant du téléphone. Afin d économiser de la batterie, le téléphone "drop" tous les paquets qui ne lui sont pas destinés (donc les paquets multicasts, car l ip de destination est celle du groupe, différente de celle du téléphone). Il existe un verrou à acquérir dans l API Android afin de désactiver ce "drop" des paquets multicast. Le bout de code est le suivant : 1 MulticastLock lock; 2 WifiManager wifi = (WifiManager)getSystemService(Context.WIFI_SERVICE); 3 lock = wifi.createmulticastlock("mylock"); 4 lock.setreferencecounted(true); 5 lock.acquire(); Ce code nécessite évidemment que l application déclare avoir besoin de la permission "CHANGE_WIFI_MULTICAST_STATE" dans son AndroidManifest.xml Tout ceci n a rien changé à nos tests, le téléphone n envoyait toujours pas de paquets IGMP. Une vérification dans le /proc/config.gz du téléphone (fichier.config lors de la compilation du noyau Linux) nous indique : # cat config grep MULTIC # CONFIG_IP_MULTICAST is not set Le multicast ne semble pas compilé dans le noyau, le support du multicast semble donc compromis pour l instant, en tout cas sur les téléphones que nous avons testé (HTC Hero, HTC Desire et Google Nexus One) Nous soupçonnons en plus que certains paquets soient "drop" dès le driver de la carte wifi afin de conserver de l énergie en ne passant à la pile protocolaire du téléphone que le minimum de paquets possibles, mais nous n avons pour le moment trouvé aucun preuve de cela dans le dépot de code source d Android. 14

16 Après tous ces essais, nous en avons conclu que la piste de l utilisation de la diffusion IP multicast était à écarter afin d avancer. Nous avons discuté avec Bela Ban (le créateur de JGroups) sur son salon IRC et lui avons dit que nous avions besoin de JGroups mais que le multicast ne marchait pas. Il nous a alors répondu que tous les protocoles de découverte des membres de groupe étaient alors basés sur le multicast IP. Nous lui avons alors demandé quel était le niveau de difficulté pour implémenter un protocole de découverte basé sur le broadcast IP, ce à quoi il a répondu en se proposant de l implémenter lui-même. Le lendemain Bela Ban avait implémenté une couche protocolaire BPING (pour Broadcast PING), le PING étant le nom donné au protocole de découverte. Après quelques tests, il s est avéré que BPING était la couche qui nous manquait et qui a parfaitement remplacé le PING d origine basé sur le multicast IP. Nous avons donc concocté un fichier de configuration udp.xml "fait maison", utilisant l UDP unicast pour communiquer entre les noeuds et l UDP broadcast pour découvrir les noeuds membres du groupe Le scheduler et le retransmitter incompatibles avec Android 2.2 Le scheduler de task (ordonnanceur de tâches) par défaut de JGroups utilise la classe java.util.concurrent.concurrentskiplistmap qui n apparait dans l API java Android qu à partir de la version 9 (Android 2.3). Au début nous avions commencé à ré-écrire le scheduler (dans src/org/jgroups/util/timescheduler2.java) en remplaçant les ConcurrentSkipListMap par des HashMap. Cela n était pas si évident et entraînait des lourdeurs (en effet une ConcurrentSkipListMap est un ensemble ordonné, contrairement à la HashMap). La classe org.jgroups.stack.rangebasedretransmitter utilise aussi la ConcurrentSkipListMap, et une implémentation triviale et naïve en remplaçant par une HashMap entraînerait la perte de l ordre de retransmission des paquets et déboucherait sur une transmission désordonnée. Heureusement une alternative s est offerte à nous, il a suffit (en suivant les conseils de Bela Ban) d utiliser un autre scheduler (l ancien scheduler : TimeScheduler.java) ainsi que l ancien retransmitter (org.jgroups.stack.retransmitter) qui n utilisent pas de ConcurrentSkipListMap. Effectivement cela entraine une perte de performancec car lorsqu il y a N messages contigues à re-transmettre, l ancien retransmitter schedule N tasks, alors que le nouveau "Range Based" n en schedule qu une seule qui va envoyer les N messages dans l ordre. Cependant cela n arrive que lors de pertes de paquets ou de latences trop élevées, et n est pas une hausse insurmontable de charge. Les téléphones de nos jours étant presque aussi puissants que les ordinateurs portables d il y a 5 ans, ils s en sortent très bien avec ces anciennes versions du scheduler et du retransmitter. Afin d indiquer à JGroups d utiliser les bons composants, il a suffi de modifier le fichier de configuration de la pile protocolaire que nous utilisons, nous avons donc modifié le fichier conf/udp.xml afin de lui dire d utiliser les anciens composants. 5.4 Exemple Draw et Touchsurface Le premier contact que nous avons eu avec JGroups s est fait via un programme de démonstration nommé Draw. C est un programme qui consiste en un tableau blanc sur lequel on peut dessiner à plusieurs. Chaque participant lance le programme Draw et voit alors son tableau blanc se lancer, il peut dessiner dessus et son dessin se dessine en même temps sur les tableaux blancs des autres participants. Après avoir porté JGroups, il a fallu le tester pour voir si cela marchait convenablement, nous avons donc porté l application Draw sur Android. Ce portage n était pas si évident car Draw utilise une interface graphique faite avec le toolkit java classique java.awt. Or java.awt n existe pas sous Android, les évènements et l interface graphique ne se gèrent pas comme ça, il a fallu donc traduire le java.awt en interface graphique de chez Android (Android.graphics et Android.view). Au début, pour avoir un portage rapide, le bouton d effacement ainsi que la gestion des couleurs ont été supprimées de Touchsurface (le nom du portage de Draw sur Android) car les couleurs sont gérées différemment sur Android et en java.awt classique. Toutefois l application n était plus compatible avec la version PC (Draw), on ne pouvait donc pas jouer à la fois avec un téléphone et un PC, car dans le protocole de communication le PC envoie des informations supplémentaires correspondant à la couleur de chaque point alors que Touchsurface n envoie que les coordonnées et les commandes (dessiner ou effacer). Au final, après quelques commits supplémentaires, Touchsurface gère la couleur et la touche effacement (la touche MENU), et est donc à nouveau compatible avec la version PC (Draw). Vous pouvez télécharger l application en utilisant le QRCode de la figure 5.1 de la page 16, ou en allant sur le site de Yann [5]. 15

17 5.5 Exemple SimpleChat FIGURE 5.1 QRCode pour télécharger l application Android touchsurface Une autre application de démonstration JGroups a été portée sur Android afin de tester JGroups, il s agit de SimpleChat. Le portage fut trivial, car cette application est un simple chat qui prend comme entrée System.in et comme sortie System.out, donc aucune interface graphique n avait besoin de portage. L application marchait très bien sur les téléphones et était compatible avec la version PC, seulement la démonstration n est pas très impressionnante car il faut regarder les logs du téléphone (via adb logcat) afin de voir les conversations car nous n avons pas fait d interface graphique pour l application. Il faut donc que le téléphone reste branché à un ordinateur. 16

18 Deuxième partie API 17

19 Chapitre 6 Remote Object API basée sur JGroups 6.1 Analyse de l API Nous avons commencé par analyser l API qui nous a été proposée. Malheureusement, celle-ci n était pas adaptée pour utiliser JGroups. En effet, lorsque l on utilise JGroups, il y a une notion de canaux, qui n était pas présente dans les interfaces de l API existante. C est pour cette raison que nous avons développé notre propre API d objet distant, basé et pensé pour JGroups. 6.2 Structure de l API Le but de cette API est de partager des objets entre plusieurs noeuds. Un objet, pour être partageable, doit seulement implémenter l interface IRemotableObject qui oblige juste l objet à porter un nom et à avoir des getters et setters pour ce nom. De plus cette interface hérite de java.io.serializable ce qui permet d avoir des objets Serializable. L API permet d effectuer plusieurs actions : Rendre un objet "global", le partager entre les noeuds, via RemoteObjectSystem.CreateRemoteObject() Appeler une méthode sur un objet global (la méthode sera donc appelée sur tous les noeuds) via RemoteObjectSystem. CallRemoteObjectMethod() Mettre à jour les objets distants à partir de la copie locale via RemoteObjectSystem.updateRemotableObject() Supprimer des objets distants via RemoteObjectSystem.deleteRemotableObject() Lors de la mise à jour d un objet distant à partir de la copie locale, l objet local est sérializé dans un Message JGroups, puis envoyé dans le JChannel pour être enfin désérializé à la sortie du JChannel de l autre côté pour écraser la copie locale des autres noeuds, d où l importance d avoir un objet Serializable. 6.3 Test de l API Nous avons généré des tests pour vérifier la validité de notre code. Pour cela, nous avons créés 2 exemples, qui vont avoir des objets partagés. L exemple 1 va créer un objet distant, et le modifier avec différentes méthodes, alors que l exemple 2 va se contenter d afficher tout les attributs de son objet distant Exemple 1 Cette exemple procède de la manière suivante : 1. Il crée un RemoteObjectSystem en lui donnant le nom du canal qui va servir à partager l objet 2. Il crée un objet local et le donne au system pour que celui-ci l enregistre en tant qu objet réparti 3. Il donne un nom à l objet en local (pour vérifier que le changement reste local) 4. Il change le nom de l objet en appelant la méthode distante, pour vérifier que le nom change en local, mais aussi à distance 5. Il change à nouveau le nom en local, puis fait un update de l objet (pour renvoyer l objet local à distance) 6. Enfin, on supprime l objet distant 18

20 6.3.2 Exemple 2 Dans ce second exemple, à lancer en même temps que le premier, nous allons avoir un objet distant partagé entre les deux programmes. Dans l ordre, voici les étapes que nous allons suivre : 1. Comme pour le premier exemple, nous créons un RemoteObjectSystem en lui donnant en paramètre le même canal que le premier exemple 2. On va récupérer tout les objets distants, avec leur valeur, qui existent. S il n existent pas, on passe directement à la suite 3. Nous entrons dans une boucle qui affiche les objets distants que nous avons, et les valeurs de leurs attributs Validation du code L exécution des exemples nous permet de vérifierplusieurs choses : Si on crée un nouveau système, il récupère tous les objets distants qui existent. La création d objet distant fonctionne sur toutes les applications qui sont connectées au même canal. L appel de fonction distante fonctionne, et donc chaque application fait les calculs sur son objet. L update d objet distant fonctionne. Il permet d envoyer l objet local à distance. On peut supprimer un objet distant, et il est bien supprimé sur toutes les applications lancées. 19

21 Troisième partie Bilan 20

22 Chapitre 7 Conclusion 7.1 Les objectifs atteints Un middleware de communication de groupe (JGroups) a été porté sur Android et plusieurs applications "proof-ofconcept" ont été développées et testées. Une API de gestion d objets distribués basée sur JGroups a été développée et testée sur Android et sur ordinateur. 7.2 Le travail restant Il reste à implémenter la PlayManagementAPI en se basant sur la RemoteObjectAPI et sur JGroups. 21

23 Chapitre 8 Manuel 8.1 Utilisation du port Android de JGroups Dans la suite nous allons voir comment télécharger, compiler et utiliser notre port Android de JGroups Télécharger les sources Le code source de notre port est versioné sur github à l adresse https ://github.com/fallen/jgroups Il s agit d un fork du dépot github officiel de JGroups de Bela Ban auquel nous avons rajouté quelques commits. Pour télécharger les sources, vous pouvez soit cliquer sur le bouton "Downloads" de la page github qui vous fera télécharger un tar.gz de la branche master du dépot, soit effectuer un git clone du dépot en tapant : $ git clone git ://github.com/fallen/jgroups.git Compiler les sources Pour compiler les sources du port Android de JGroups, placez-vous dans le répertoire racine des sources et tapez la commande suivante : $ ant clean ; ant jar Une archive JAR va alors être produite et placée dans le dossier "dist" à la racine du dépot Utilisation des jars Il vous suffit alors d importer le fichier dist/jgroups-version.jar dans votre build path Eclipse pour pouvoir utiliser JGroups. Pour une application Android il est conseillé de placer le fichier conf/udp.xml dans le dossier "assets" du projet Eclipse. Le fichier conf/udp.xml correspond à la configuration de la pile protocolaire de JGroups, ce fichier contient une configuration compatible avec Android, utilisant le BPING (Broadcast Ping) pour découvrir les noeuds, l ancien Scheduler, l ancien Retransmitter et de l UDP unicast pour communiquer entre les noeuds. Le mettre dans le dossier "assets" du projet permet d y faire référence directement dans le code source par exemple de la création d un JChannel via la ligne JChannel channel = new JChannel("udp.xml") ;, en effet le fichier sera inclus dans le paquet d installation.apk et sera donc présent dans le téléphone une fois l application installée. 8.2 Utilisation de JGroupsRemoteObject Télécharger les sources Le code source de notre RemoteObjectAPI basée sur JGroups est versioné sur github à l adresse https ://github.com/fallen/jgroupsremoteobjectapi [7] Vous pouvez télécharger le code source de la même manière que précédemment : $ git clone git ://github.com/fallen/jgroupsremoteobjectapi.git 22

24 8.2.2 Compiler les sources Il suffit d importer les sources dans un projet Eclipse, puis de faire clique droit sur le projet puis "exporter" et d en faire une archive JAR. Pensez à ne pas inclure le fichier udp.xml dans l archive JAR, car celle-ci serait en conflit avec le fichier udp.xml que vous placeriez dans le dossier "assets" d un éventuel projet Android Utilisation des jars L archive JAR précédemment créée peut alors être mise dans le build path d un projet Eclipse Android pour permettre l utilisation de l API. Il ne faut pas oublier d importer aussi l archive JAR de JGroups et de placer le fichier udp.xml dans le répertoire "assets" du projet Eclipse. 8.3 Utilisation de PlayManagementAPI 23

25 Table des figures 1.1 Architecture standard Architecture répartie Structure de l API QRCode pour télécharger l application Android touchsurface

26 Bibliographie [1] Le site de JGroups : http :// [2] Le site de Spread : http ://spread.org [3] Le site de Appia : http ://appia.di.fc.ul.pt/wiki/index.php?title=main_page [4] Dépot git du portage de JGroups sous Android : https ://github.com/jadahl/jgroups-android [5] Blog de Yann Sionneau : http ://sionneau.net [6] Blog de Bela Ban : http ://belaban.blogspot.com [7] Lien vers le code source de la Remote Object API : https ://github.com/fallen/jgroupsremoteobjectapi 25