Amigo. Application de partage de données. Protocole spécifique & Conception logicielle

(1)

Amigo

Application de partage de données

Protocole spécifique

&

Conception logicielle

(2)

Amigo – application de partage de données basée sur Jabber

Sommaire

A. Introduction...4

B. Présentation du concept Amigo...4

B.1. Introduction...4

B.2. Amigo dans une infrastructure Jabber de messagerie instantanée...4

B.2.a. Le partage de données est basé sur la liste de contacts du profil Jabber...5

B.2.b. Minimiser les risques de collision avec un client de messagerie instantanée...5

B.2.c. Limitations...6

B.3. Exemples : cas d'utilisation d'Amigo...6

B.3.a. Un interlocuteur souhaite informer ses amis d'un évènement : la fête d'anniversaire qu'il compte organiser le weekend suivant...6

B.3.b. Leo a perdu le message et se connecte avec un client Amigo. Lorsqu'il se connecte, seul Eric est en ligne...7

C. Le Protocole Amigo : une surcouche de Jabber...8

C.1. Espaces de Nom Amigo...8

C.1.a. Les services...8

C.1.b. Les données...9

C.2. Les données : contenu XML...9

C.2.a. La base commune...9

C.2.b. amigo:data:message...10

C.2.c. amigo:data:event...10

C.2.d. amigo:data:presence...10

C.2.e. amigo:data:vcard...10

C.2.f. amigo:file:file...10

C.2.g. amigo:file:image...11

C.3. Messages et Requêtes Amigo...11

C.3.a. Création/modification de données à l'aide de <message/>...12

C.3.b. Requêtes <iq/>...12

C.3.b.1. Découverte des services...12

C.3.b.2. Récupération des données liées à un service...13

C.3.b.3. Récupération de fichiers liés à une donnée amigo:file:*...14

C.3.c. Gestion d'erreurs...14

C.4. Conclusion ...16

D. Implémentation logicielle...16

D.1. Introduction...16

D.2. Planning de développement...16

D.2.a. Choix des technologies utilisées...16

D.2.b. Conception UML de l'application...16

D.2.c. Développement itératif de l'application...16

D.3. Conception Orientée Objet...16

D.4. Le stockage des données...17

D.5. Environnement de développement, langages...17

E. Conclusion générale...17

(3)

Amigo – application de partage de données basée sur Jabber

F. Annexes...18

F.1. Les spécifications Jabber étudiées...18

F.2. Bibliographie...18

F.3. Webographie...18

(4)

Amigo – application de partage de données basée sur Jabber Introduction

A. Introduction

Suite à l'étude du protocole Jabber précédemment menée, j'ai décidé de me baser sur ce protocole pour la conception de l'application Amigo de partage de données privées.

Le protocole Jabber présentait les caractéristiques idéales pour cette application, à savoir : – Gestion de l'identification/authentification des utilisateurs

– Système décentralisé ne nécessitant pas de phase de recherche (le système est décentralisé, mais la recherche d'un interlocuteur se fait directement par interrogation de son serveur)

– Échange de données structurées évident grâce à l'extensibilité du protocole XML – Échange de fichiers en véritable pair-à-pair

Les difficultés résidaient dans la définition d'un protocole de communication et dans une gestion simple des droits sur le partage de données. Par ailleurs, il était nécessaire de prévoir un fonctionnement compatible avec

l'utilisation de la messagerie instantanée pour éviter à chaque utilisateur d'avoir deux comptes Jabber : l'un pour la messagerie et l'autre pour le partage de données.

Compte tenu du temps disponible pour la réalisation de ce projet, les technologies qui ont été étudiées sont Jabber principalement, ainsi qu'une réflexion sur l'opportunité d'une application web. cf rapports Etude de Jabber et Comparaison des technologies. La technologie JXTA n'a pas été retenue car elle était principalement orientée JAVA, et je ne voulais pas lier le concept à un langage de programmation particulier.

Ainsi Amigo est-il une sur-couche de Jabber qui pourra être implémentée quelque soit le langage choisi, à partir de n'importe quelle librairie et/ou application implémentant les fonctionnalités de Jabber/XMPP.

Prérequis pour comprendre ce document : compréhension du protocole jabber, et notamment des dialogues de type info/query <iq/>

(5)

Amigo – application de partage de données basée sur Jabber Présentation du concept Amigo

B. Présentation du concept Amigo

B.1. Introduction

A la manière de SQL pour les bases de données, Jabber définit un langage de requêtes entre applications basé sur xml et xmlnamespaces. Ce protocole a été imaginé de manière extrêmement générique dans le but d'être

extensible aisément pour des applications particulières de la technologie. Amigo est l'illustration même de ce concept.

Chaque client Jabber compatible Amigo pourra générer des requêtes en xml par l'utilisation des namespaces Amigo destinées à ses interlocuteurs. Ceux-ci, s'ils savent interpréter ces requêtes pourront alors répondre. En fait les espaces de nom définis pour Amigo sont utilisés dans deux cas :

– les messages <message/> pour l'envoi de nouvelles données

– les requêtes <iq/>pour pouvoir interroger les interlocuteurs présents.

La fin de cette partie illustre le fonctionnement d'Amigo à travers quelques cas d'utilisation. Mais pour le moment, voyons comment Amigo va s'intégrer dans une infrastructure de messagerie instantanée Jabber en conservant une transparence maximale pour l'utilisateur.

B.2. Amigo dans une infrastructure Jabber de messagerie instantanée

Les problèmes d'intégration apparaissant rapidement en envisageant une application dédiée de Jabber, dans le cadre d'une utilisation en parallèle de messagerie instantanée sont les suivants :

– Il ne faut pas que le client Amigo intercepte les messages et requêtes concernant une discussion en cours, sinon l'application utilisée par le destinataire ne recevra jamais les réponses.

– Il faut éviter au maximum d'envoyer des requêtes et/ou messages de type Amigo sur des clients “classiques”.

D'une part parce que s'ils sont mal implémentés ils risquent de réagir de manière inattendue à ces messages, d'autre part parce que dans le cas où l'application n'est pas compatible Amigo, l'envoi de tels messages surcharge inutilement le réseau.

– D'autre part, il faut que le client Amigo réceptionne lui-même les messages qui lui sont destinés, et donc qu'ils ne soient pas interceptés par un client de messagerie instantanée quelconque.

– Il peut être rapidement intéressant de partager des fichiers avec certains groupes de personnes, tout en donnant accès à certaines données aux différents groupes. Par ailleurs le relais des données provenant d'autre

interlocuteurs doit être automatique, il doit donc être possible que l'application sache automatiquement à qui elle est autorisée de relayer les informations.

Pour résoudre ces différentes problématiques, différentes solutions ont été étudiées, solutions qui profitent simplement des caractéristiques propres de Jabber :

B.2.a. Le partage de données est basé sur la liste de contacts du profil Jabber.

La liste des contacts enregistrés dans les systèmes de messagerie instantanée Jabber est sauvegardée sur le serveur. Ceci permet de se connecter à son profil de n'importe quel poste. Pour faire bénéficier Amigo de cette fonctionnalité, il fallait se baser sur cette liste de contacts.

Voici à quoi ressemble une entrée du carnet de contacts Jabber :

<group>famille</group>

</item>

La solution la plus évidente pour partager des données automatiquement avec les personnes susceptibles d'être intéressées est de s'appuyer sur le contenu de la balise <group/>. Ainsi toutes les personnes qui sont inscrites dans mon compte comme faisant partie du groupe “famille” seront tenues au courant des nouvelles données que je recevrait d'un autre membre du groupe famille.

(6)

Un problème intervient à ce niveau. En effet si l'on fonctionne de la sorte, une personne ne pourra pas faire partie de deux groupes de partage différent, pour la simple raison que les serveurs Jabber considèrent que chaque jid (identifiant Jabber) est entré au maximum une fois dans la liste de contacts.

La première solution que j'avais imaginée était l'utilisation d'une hiérarchie en créant des groupes tels que famille et famille/proche. Ainsi les membres de famille/proche seraient également membres de famille. le problème dans cette approche arborescente est d'interdire l'inscription dans deux listes complètement distinctes.

Finalement l'approche qui laisse le plus de liberté pour chaque utilisateur est une approche de groupes définis par mot-clés. Ainsi, les membres du groupe “famille amis” pourront recevoir toutes les données destinées à famille, et également toutes celles destinées à amis. C'est une approche un peu similaire aux ACL. L'avantage est que chacun choisit avec qui il partage les données (tout en sachant que ses interlocuteurs savent éventuellement à qui il accepte de retransmettre les données).

B.2.b. Minimiser les risques de collision avec un client de messagerie instantanée

Pour qu'Amigo soit facilement utilisable et adopté par une communauté de gens, il est nécessaire qu'il fonctionne de manière transparente pour l'utilisateur. Et notamment :

– qu'il n'intercepte pas les messages destinés à un autre client.

– que les messages qui lui sont destinés ne soient pas interceptés par un autre client

La première solution qui vient à l'esprit est d'utiliser deux comptes distincts. Cette solution lourde n'a pas été retenue car elle nécessite la gestion de deux comptes pour l'utilisateur. Par ailleurs, dans le cas du partage d'un annuaire, l'utilisateur serait dans l'obligation de mettre à jour sa carte de visite électronique pour chacun de ses comptes.

La seconde solution, bien meilleure du fait qu'elle n'exclut pas la première, est d'utiliser une ressource spécifique dans l'envoi des messages et requêtes. Un identifiant Jabber se présente sous la forme

monlogin@serveur/ressource. La ressource est libre de définition, elle permet simplement de donner des précisions quant à l'interlocuteur. Par exemple elle pourrait être maison ou travail pour indiquer que

l'interlocuteur se trouve chez lui ou au travail. Dans notre cas, il paraît judicieux d'utiliser une ressource intitulée amigo qui permettra à chaque application d'envoyer les messages et requête spécifiquement au client répondant de cette ressource.

Rappelons au passage que l'envoi d'un message Jabber pour lequel la ressource n'est pas spécifiée arrivera à tout client Jabber connecté, tandis que si la ressource est précisée, il sera relayé à l'application correspondante uniquement.

D'autre part, pour éviter au client Amigo d'intercepter les messages qui ne lui sont pas destinés, l'utilisation d'une priorité faible devrait faire l'affaire (la priorité indique à quel client envoyer les messages si aucune ressource n'est précisée dans le message).

Ces solutions ne sont pas complètement “sûres”, dans le sens où des interceptions sont possibles, néanmoins elles sont faciles à mettre en oeuvre. Dans le cas où l'utilisateur souhaite éviter totalement une quelconque interception de message, la solution d'un compte Jabber dédié conviendra.

B.2.c. Limitations

Ces solutions conservent tout de même certaines limitations. Il serait possible d'y pallier en utilisant un protocole Amigo plus spécifique. Les limitations actuelles sont notamment :

– le contrôle des personnes recevant des données est réalisé de proche en proche. La liste de contacts n'étant pas forcément la même pour chacun, l est possible qu'un destinataire qui n'était pas prévu le devienne par

l'entremise des autres. Ceci n'est pas un problème spécifique à Amigo : rien n'empêche à un utilisateur de transférer un message email, par exemple, à un destinataire qui n'était originellement pas prévu. Par ailleurs, le partage des données est basé sur celui des contacts, aussi chacun est en mesure de savoir à qui les messages

(7)

seront relayés, et par l'intermédiaire de qui. Si les données sont vraiment trop sensibles, rien n'empêche de les crypter/décrypter à l'aide de clé privée/clé publique.

– Des messages destinés à un client de messagerie instantanée peuvent toujours être interceptés et l'inverse également. Ceci générera un trafic inutile mais pas de perte de données grâce à l'utilisateur possible de requêtes pour interroger ses interlocuteurs.

– Il n'est pas impossible qu'un intermédiaire modifie des données et les fasse passer pour celles de quelqu'un d'autre. Le client, pour éviter d'accorder trop d'importance à des données non fiables pourra définir un niveau de fiabilité en fonction de l'interlocuteur dont il a rapatrié l'information, le niveau maximal étant celui lié à l'expéditeur réel.

– Pour préciser l'aspect sécuritaire du partage de proche en proche de données, il est tout à fait envisageable que chaque utilisateur définisse une clé privée de cryptage et qu'il transmette la clé publique aux interlocuteurs auxquels il désirent envoyer des messages sensibles. Cela étant, une fois le message décrypté, rien n'empêche l'utilisateur de les transférer à d'autres personnes sous forme décryptée.

Voyons maintenant quelques cas d'utilisation illustrant le concept.

B.3. Exemples : cas d'utilisation d'Amigo

B.3.a. Un interlocuteur souhaite informer ses amis d'un évènement : la fête d'anniversaire qu'il compte organiser le weekend suivant.

L'application Amigo lui permet de saisir les données liées à l'évènement (lieu, date, détail, etc). Avant de valider l'évènement, il indique également à quel groupe de personnes il désire l'envoyer. Les mots clés qu'il tape sont par exemple “amis-paris famille, amis-enst”.

Lorsqu'il valide l'évènement, l'application va effectuer les tâches suivantes : 1. Extraire des mots-clés les groupes de personnes concernés par l'évènement.

2. A partir de ces différents groupes, générer une liste de destinataires 3. Envoyer un message Jabber <message/> contenant les données structurées.

Ce message sera reçu par le destinataire dès qu'il se connecte (ou instantanément s'il est déjà connecté). En intégrant les données également sous forme non structurée, le message pourra être lu via n'importe quel client Jabber.

L'évènement reste à disposition sur l'ordinateur de l'expéditeur, et accessible à tout moment via des requêtes

<iq/> pour les personnes autorisées.

Pour chaque destinataire, le message Jabber envoyé aura une forme similaire à ceci :

<subject>23/06/2005 18h - Anniversaire de Bernard</subject>

<body>

Lieu : Chez Bernard à Paris Date : 23/06/2005 18h00

Evènement : Anniversaire de Bernard

Détail : Je compte sur vous pour ma petite fête pour mes 21 ans jeudi 23 juin.

</body>

<id>2005-06-14T17:45:32bernard@jabber.org</id>

<title>Anniversaire de Bernard</title>

<place>Chez bernard à Paris</place>

<body>Je compte sur vous pour ma petite fête pour mes 21 ans jeudi 23 juin.</body>

</item>

</x>

</message>

(8)

Quelques remarques :

– Les données Amigo sont accessibles en lecture à tout client Jabber, même s'il n'est pas compatible Amigo.

C'est un avantage indéniable qui pourra inciter les utilisateurs à faire le pas, eux aussi, vers l'utilisation d'Amigo.

– Chaque type de donnée comporte un “id” censé être unique composé de la date correspondant au moment où le message a été écrit et du jid de l'auteur. Ainsi il y a un risque quasiment nul que les données se chevauchent (en réalité, pour que deux éléments se chevauchent, il faudrait que l'utilisateur écrive deux messages dans la même seconde... sous réserve bien entendu qu'il n'ait pas changé l'heure de son ordinateur entre temps).

B.3.b. Leo a perdu le message et se connecte avec un client Amigo. Lorsqu'il se connecte, seul Eric est en ligne.

L'application Amigo va se mettre à jour en demandant à ses interlocuteurs présents de lui envoyer les données qu'ils ont. le client de Leo envoie au client d'Eric :

</item>

</query>

</iq>

Ce qui signifie : “indique-moi tous les évènements se déroulant après le 02/06/2005”. Notez que date ici n'est pas lié à la date de parution de l'évènement mais à la date de l'évènement. Comme nous le verrons plus tard, si l'on veut se référer à la date de parution (ou date d'écriture/dernière modification), il faut utiliser la balise <datetime/>.

A ce message, le client d'Eric devrait répondre ceci :

<author>bernard@jabber.org</author>

<title>Anniversaire de Bernard</title>

<body>Je compte sur vous pour ma petite fête pour mes 21 ans jeudi 23 juin.</body>

</item>

</query>

</iq>

Les différents types de requêtes possibles, espaces de nom et paramètres utilisables sont définis dans la partie suivante.

(9)

Amigo – application de partage de données basée sur Jabber Le Protocole Amigo : une surcouche de Jabber

C. Le Protocole Amigo : une surcouche de Jabber

Jabber définit un certains nombres de données manipulables en standard, ainsi que les méthodes et espaces de noms qui y sont liés. Dans cette optique, Amigo s'inspire largement de la structure largement éprouvée de Jabber.

Voyons donc quels sont les espaces de nom définis ainsi que les éléments qui permettront de gérer les données et requêtes.

C.1. Espaces de Nom Amigo

Amigo gère le partage de données. On peut rassembler ces données au sein de services qui permettrons de les gérer. En fait la distinction entre service et donnée provient du fait qu'un service donné peut permettre de manipuler différentes données.

Prenons l'exemple précédent. Bernard organise un anniversaire, c'est à dire qu'au sein d'Amigo il va créer une donnée de type event. On peut très bien imaginer que le service de gestion d'évènements accepte également de manipuler des données de type presence qui permet à chacun de préciser sa présence. Ainsi Léo pourrait à son tour créer une donnée de type presence indiquant qu'il sera vraisemblablement là, accompagné d'un texte permettant de détailler textuellement sa venue.

C.1.a. Les services

Les espaces de nom liés aux services permettent d'une part d'apprendre quels sont les services implémentés par un interlocuteur, d'autre part de gérer différentes données au sein d'un même service.

Les premiers espaces de noms définis sont les suivants :

– amigo:services : permet d'interroger un client pour savoir quels service il est à même de gérer – amigo:service:data : concerne les services de type données textuelles (xml uniquement : messages,

évènements)

– amigo:service:file : concerne les services de partage de données texte+fichier (photos, fichiers, etc)

L'espace de nom amigo:services permet de découvrir quels services sont proposés par un interlocuteur donné, et quels attributs y sont liés (par exemple la vitesse de connexion qui permettra à l'interlocuteur de choisir à partir de quel pair il est le plus judicieux de télé-charger un fichier)

Les services de type amigo:service:data nécessitent uniquement une communication jabber “standard”, c'est à dire qu'il ne comportent pas de fichiers à télé-charger en pair-à-pair.

Les services de type amigo:service:file nécessitent le télé-chargement du contenu lié par un mécanisme de pair-à- pair (mécanisme de transfert du protocole Jabber).

– amigo:service:data:event : permet de dialoguer avec un client gérant le service d'évènements – amigo:service:data:message : idem pour le service de messages

– amigo:service:data:vcard : idem pour le service de carnet d'adresse – amigo:service:file: : pour le partage de fichiers quelconques

– amigo:service:file:photo : pour le partage de photos

– amigo:service:file:any : pour le partage de fichiers quelconques – ...

(10)

C.1.b. Les données

Les espaces de nom de données permettront aux interlocuteur de savoir comment traiter les données reçus via l'infrastructure Jabber sous-jacente.

Dans un premier temps, les données de type data sont les suivantes : – amigo:data:message : message quelconque

– amigo:data:event : évènement

Comme expliqué précédemment, ces données ne nécessitent ni de télé-chargement supplémentaire, ni de traitement quelconque. En revanche les données de type file nécessitent, quant à elles l'implémentation du télé- chargement pair-à-pair standard de Jabber :

– amigo:file:file : espace de nom générique pour le transfert de fichiers – amigo:file:image : espace spécifique aux photos/images.

C.2. Les données : contenu XML

L'intérêt de définir des espaces de noms pour les données est de connaître précisément quelles seront les données reçues, ou les méta-données dans le cas de transfert de fichiers

C.2.a. La base commune

Toutes les données échangées possèdent une base commune indispensable pour leur traitement. Elles s'échangeront sous la forme suivante :

</item>

Explications :

– l'attribut xmlns de la balise <item/> définit le type de contenu à traiter. Il doit donc faire partie des espaces de nom définis auparavant

– <datetime/> est la date et l'heure de création (et modification si le message est modifié) au format définit par la JEP-0082 de la fondation Jabber. C'est à dire qu'elle s'écrit par exemple sous la forme CCYY-MM-

DDThh:mm:ss où :

– CCYY représente l'année – MM le mois (format numérique) – DD le jour (format numérique)

– hh, mm, ss respectivement les heures, minutes et secondes au format numérique sur 24 heures – le tout en heure UTC.

– cf la JEP-0082 pour plus de détail

– <author/> est renseigné à l'aide du jid de l'auteur, mais sans la ressource. Ainsi il sera plus facile de retrouver le message en cas de modification.

– <id/> est la concaténation du contenu de <datetime/> lors de la création et de <author/>. Si les données sont amenées à être modifiées, c'est cet identifiant unique qui permettra de retrouver quelles données mettre à jour.

– <title/> correspond au titre de la donnée – <body/> correspond au contenu textuel

– <parentid/>contient l'id de la donnée parente. C'est notamment utile dans le cas de réponses à des messages.

C'est une balise facultative : en son absence la donnée est considérée comme étant de niveau 0.

– <deleted/> est facultatif et indique simplement que la donnée a été supprimée.

(11)

En fonction du type de données, cette base pourra être enrichie.

C.2.b. amigo:data:message

</item>

Les données de type message sont en quelque sorte l'équivalent des news d'un site web : leur objectif est de donner des nouvelles. Le format de données est exactement le modèle de base qui est, dans ce cas, suffisant. Cela amène une remarque concernant l'implémentation : toute donnée transférée à l'aide du protocole Amigo pourra être traitée comme un message standard.

C.2.c. amigo:data:event

<date></date>

<place></place>

</item>

Les nouveaux champs à renseigner son <date/> et <place/>, respectivement la date de l'évènement (au format Jabber) et le lieu (une simple chaîne de caractères).

C.2.d. amigo:data:presence

Dans le cadre de la gestion d'évènements, il peut être intéressant que chacun indique sa présence. Cela se fera à l'aide du namespace amigo:data:presence dont le contenu est le suivant.

<presence></presence>

<parentid></parentid>

</item>

La seule nouveauté est la présence de la balise <presence/>, dont le contenu sera yes, no ou rien. Le cas ou le contenu est vide signifiant “indéterminé”. Pour donner plus de précision, il faudra spécifier dans le titre ou dans le corps le détail.

La présence de la balise <parentid/> est fondamentale pour rattacher la présence à un évènement. Le client recevant une donnée de ce type devra bien entendu s'assurer que le parent existe, et qu'il est de type amigo:data:event.

C.2.e. amigo:data:vcard

Pour ce qui est de la vcard, il serait long et inutile de préciser son contenu. En effet, la JEP-0054 de la fondation Jabber définit déjà exhaustivement son format. Il sera tout simplement réintégré ici, en complément des éléments de base d'une donnée Amigo (cf précédemment).

(12)

C.2.f. amigo:file:file

Le format de partage de fichiers est un peu spécial. Il doit permettre le transfert des méta-données dans le flux XML et également permettre le télé-chargement du fichier. Il reprendra donc le format de base des données Amigo tout en précisant également les données liées au fichier :

<name></name>

<size></size>

<hash></hash>

</item>

Le contenu de <name/> sera simplement le nom du fichier (test.txt, par exemple), <size/> comportera la taille du fichier en octets et hash la somme MD5 du contenu du fichier. Ces valeurs sont les mêmes que celles qui apparaissent dans le brouillon de spécification JEP-0096 (Transfert de fichier).

La présence d'une balise <download/> dans une requête <iq/> signifiera que l'interlocuteur désire initier le transfert du fichier. Ceci est nécessaire car le transfert de fichiers via Jabber doit être initié par le client qui possède le fichier et non par celui qui souhaite le récupérer. En la présence de cette balise, le client recevant la requête initiera le transfert classiquement vers le client qui a effectué la requête.

Pour éviter de lancer de trop nombreux télé-chargements sur une requête de ce type, la présence de <download/>

ne sera prise en compte que si un <id/> est spécifié et valide. Ainsi les transferts de fichiers s'effectueront à l'unité.

Cette méthode est plus verbeuse, mais elle limitera l'utilisation de la bande passante dans le cas d'une requête erronée.

C.2.g. amigo:file:image

L'objectif du partage de fichiers de type image, est partiellement lié à la création d'albums photos partagés. Dans ces conditions, il est nécessaire de pouvoir préciser des éléments de tri et regroupement de photos. En plus des champs classiques, la présence de champs permettant de lier les photos à des personnes permettra de trier les données soit par personne, soit par évènement :

<people jid=””></people>

<event id=””></event>

</item>

Le nombre de balises <people/> n'est pas limité (il peut y avoir plusieurs personnes sur une photo) mais <event/>

sera unique. L'id permettra de lier si nécessaire la photo à un évènement présent dans Amigo, idem pour jid ; ces champs peuvent toutefois rester vide.

(13)

C.3. Messages et Requêtes Amigo

Les données échangées à l'aide du protocole Amigo seront principalement échangées via des messages de type info/query <iq/>. Les seuls données échangées via la balise <message/> seront les données provenant directement du créateur de la donnée. En d'autres termes, tout ce qui concerne le relayage des données fournis par d'autres personnes le seront grâce au système de requêtes.

En terme d'implémentation, cela signifie que les seuls <messages/> à traiter sont ceux dont l'expéditeur est le même que celui se trouvant dans le champ <author/>. Ceci permet de gérer un niveau de fiabilité accru de l'information. L'infrastructure Jabber remplit en effet elle-même le champ “from” d'un message, pour éviter le spoofing d'adresses. Si un élément doit faire foi, c'est donc bien celui-ci.

L'envoi systématique de messages <message/> lors de la création/modification de données (modification des données créées par soi-même) permet de garantir :

1. l'accès à l'information pour chacun 2. la fiabilité de l'information

En résumé, les requêtes de type <iq/> doivent être utilisées pour : – Rechercher une information spécifique accidentellement supprimée

– Récupérer une archive à partir d'un ordinateur temporaire (en voyage par exemple) – Récupérer les fichiers partagés

Dans le doute, une application manipulant les données Amigo devra systématiquement accorder une importance supérieure à une information obtenue par un message <message/>.

C.3.a. Création/modification de données à l'aide de <message/>

Dans le cas où un utilisateur souhaite créer des données ou modifier celles qui le concernent personnellement. Il enverra un message Jabber classique complété par la balise <x/> dont l'attribut xmlns aura été judicieusement précisé en fonction du service concerné.

Le ou les items contenus dans cette balise <x/> seront correctement renseignés. Dans le cas d'une modification, il est fondamental de renvoyer tous les éléments, qu'ils soient modifiés ou non. Le contenu de l'id permettra au client de déterminer lui-même s'il s'agit d'une création ou d'une modification, tandis qu'il remplacera tous les autres éléments par leur nouvelle valeur.

Dans la mesure du possible, il serait de bon ton de générer un corps de message complet permettant également à un utilisateur non-Amigo d'accéder aux données :

<subject>25/06/2005 18h - Anniversaire de Bernard – changement de date</subject>

<body>

Lieu : Chez Bernard à Paris Date : 25/06/2005 18h00

Evènement : Anniversaire de Bernard

Détail : Je compte sur vous pour ma petite fête pour mes 21 ans jeudi 23 juin.

</body>

<title>Anniversaire de Bernard – changement de date</title>

<body>Je compte sur vous pour ma petite fête pour mes 21 ans jeudi 23 juin.

Finalement ce sera le 25 et non le 23. Prenez-en bonne note !</body>

</item>

</x>

</message>

(14)

C.3.b. Requêtes <iq/>

Il faut bien comprendre le mécanisme de partage des données. Les données sont systématiquement envoyées à chacun (sauf en cas de coupure inopinée de la connexion, de plantage ou autre) par l'auteur original. Les seules raisons d'être des requêtes de type <iq/> sont :

– la mise à jour d'initialisation

– la perte de données (qui revient en quelque sorte à une initialisation)

– le transfert de fichiers qui permet de mutualiser la bande passante dont dispose chaque pair du réseau

d'échange (il vaut mieux télé-charger un fichier sur un ordinateur dont la connexion est très rapide que sur un ordinateur connecté par modem, même si celui-ci est l'expéditeur original).

C.3.b.1. Découverte des services

La première chose que doit faire un client lorsqu'il se connecte est de savoir quels sont ses interlocuteurs disponibles. Il pourra dialoguer avec ceux-ci pour découvrir quelles sont les nouveautés.

Pour découvrir ce qu'est susceptible de transférer un interlocuteur, la requête de base est la découverte des services Amigo qu'il propose, de la manière suivante :

<query>

</iq>

Éventuellement, le contenu de <query/> pourra être précisé grâce à l'insertion de balises <item/> du type de service recherché :

ou plus précisément même à l'aide d'un item correspondant directement au service recherché :

L'interlocuteur devra alors répondre en tenant compte des éléments de précision donnés. La présence de plusieurs

<item/> devra être interprétée comme un OU logique.

Illustration : Eric souhaite récupérer toutes les données liées aux services de partage de fichiers et celles concernant les évènements :

<query>

</iq>

A la réception de ce message, Léo qui est le destinataire devra répondre en précisant tout ce qu'il propose, dans le cadre de la requête d'Eric :

<query>

</iq>

La balise <connexion-speed/> permet d'indiquer la vitesse de connexion du client en kbit/s, libre à Eric ensuite de lancer un télé-chargement. Cela permettra notamment de choisir la connexion la plus rapide dans le cas où plusieurs clients proposent le télé-chargement des données. Cela n'aura sans doute pas énormément d'incidence dans le cas de données amigo:data mais pourra être décisif dans le cas de données de type amigo:file.

(15)

Par ailleurs, si Léo ne souhaite pas proposer de télé-chargement, il n'aura qu'à répondre en omettant l'item <item xmlns=”amigo:service:photo”/>.

Les balises permettant une découverte adaptée des services sont les suivantes :

– <connexion-speed/> : indique la vitesse de connexion en débit descendant, en kbit/s. Dans une requête de type

“get”, elle indiquera la vitesse minimale requise, dans le cas d'une requête de type “result”, elle indiquera la vitesse disponible.

– <datetime type=””/> permettant d'indiquer qu'on souhaite connaître les services comportant des éléments plus récents (type=”since”) ou plus anciens (type=”until”).

Ces deux balises doivent se trouver à l'intérieur des <item>, permettant de les préciser. S'ils ne sont pas précisés lors de la requête, ils pourront être omis dans la réponse.

C.3.b.2. Récupération des données liées à un service

Pour récupérer des données, les requêtes à construire doivent contenir le type de service concerné, ainsi que les critères de recherche. Ces critères sont à considérer comme des ET logiques (c'était d'ailleurs le cas dans l'exemple précédent pour les éléments de précision <datetime/> et <connexion-speed/>).

Tous les éléments de données peuvent être utilisés comme critères de requête. Sans précision, ils seront considérés comme une recherche exacte. Les seules critères qui peuvent être utilisés de manière “restrictive”

seront ceux de type <date/> et <datetime/>. Si aucun type n'est indiqué, il faut chercher la valeur exacte, sinon, le type doit être “since” pour des données plus récentes ou “until” pour des données plus anciennes.

Une balise <maxnumber/> peut également être intégré pour demander à n'être mis à jour que pour un nombre limité d'entrées.

La fin du transfert sera toujours indiquée par un retour “vide” de type :

</iq>

Ainsi le transfert d'un grand nombre de données pourra se faire en plusieurs paquets de moindre volume.

C.3.b.3. Récupération de fichiers liés à une donnée amigo:file:*

Dans le cas d'une demande de téléchargement, la requête sera similaire à celle de la récupération de données liées à un service. La différence réside dans le fait que le transfert sera initié si la requête contient un élément

<download/> fils de <item/> et si <id> est précisé. Ceci permettra de ne pas lancer de téléchargement trop nombreux.

Ensuite, le transfert de fichier s'effectuera classiquement selon les spécifications de la fondation Jabber. a la réception d'un fichier, le client pourra comparer les hash pour s'assurer que le fichier reçu correspond bien à une requête qu'il a effectuée, et que le fichier est le bon.

(16)

C.3.c. Gestion d'erreurs

La présentation de ce projet de protocole ne fait pas état de gestion des erreurs. Cela est prévu, les erreurs seront gérée à la manière de Jabber, par insertion d'un élément <error code=””></error>. L'attribut permettra d'indiquer le code d'erreur que le logiciel devra gérer, tandis que le contenu sera un message d'erreur explicite.

La gestion des erreurs sera simplement conforme à la spécification JEP-0086, dont on n'utilisera, dans le cas précis de Amigo, que les entrées suivantes :

Cas Code Sens XML Element

Requête incomprise 400 Bad Request <bad-request/>

Requête provenant d'un jid inconnu 401 Not

Authorized

<not-authorized/>

Requête provenant d'un jid n'appartenant pas au groupe correspondant

403 Forbidden <forbidden/>

Elément non trouvé. 404 Not Found <item-not-found/>

Requête de transfert de fichier ou de transfert de donnée non prévu

405 Not Allowed <not-allowed/>

Requête de téléchargement de fichier sans id précisé 406 Not Acceptable

<not-acceptable/>

Requête sur un service non implémenté 501 Not

Implemented

<feature-not-implemented/>

Requête sur un service implémenté mais désactivé 503 Service Unavailable

<service-unavailable/>

C.4. Conclusion

Le protocole défini ainsi comporte sans doute des zones d'imprécision. Dans ce cas, il sera bien entendu précisé de manière à lever les ambiguïtés. Il s'appuie largement sur ce qui existe actuellement au sein même de Jabber, adapté à l'utilisation désirée dans le cadre du projet Amigo.

(17)

Amigo – application de partage de données basée sur Jabber Implémentation logicielle

D. Implémentation logicielle

D.1. Introduction

La partie précédente présentait le protocole de dialogue Amigo. Une implémentation est envisagée afin de mettre en oeuvre le partage de données. Nous allons voir les détails de cette implémentation.

D.2. Planning de développement

Actuellement, l'architecture du logiciel n'a pas encore été définie. Un planning de travail a néanmoins été défini afin de mener à terme le projet, en dehors du cadre de la formation de l'ENST. En effet, des logiciels aux

fonctionnalités un peu similaires existent, notamment Picasa, le logiciel de gestion de photos proposé par Google.

Cela valide l'intérêt du concept, dont l'avantage sera d'implémenter une solution comparable, évolutive et libre.

Voici le détail du planning prévisionnel pour la suite du projet.

D.2.a. Choix des technologies utilisées Durée : 3 semaines

Bien que certains choix technologiques aient déjà été faits, il reste des éléments à préciser (cf partie

Environnement de développements, langages). Une rapide analyse des éléments utilisables pour développer ce projet permettra notamment de choisir les librairies et autres toolkits à utiliser.

D.2.b. Conception UML de l'application Durée : 1 mois

Le développement de l'application sera orienté objet. Cela permettra une meilleur modularité, et la conception UML permettra une reprise du travail plus aisée par la suite. Ce faisant, la conception UML ne sera pas complète, elle comptera principalement le diagramme de classes et quelques cas d'utilisation correspondant à ce qui a été défini dans la présentation du protocole.

D.2.c. Développement itératif de l'application Durée : indéfinie

A partir du moment où une première conception UML aura été proposée, le développement pourra démarrer. Il se déroulera de manière itérative, différentes tâches évoluant en parallèle :

– Développement du corps de l'application : les librairies implémentant le protocole – Développement d'un prototype de test en mode texte

– Développement d'une interface graphique

– Développement des classes de stockage des données

L'assemblage des différentes parties se fera progressivement, l'objectif étant de proposer une application sans interface graphique (pour une utilisation de type daemon unix) et une application orientée utilisateur.

En parallèle, un travail de « marketing » et de recherche de contributeurs sera menée afin d'accélérer le développement. L'intérêt de l'application n'est plus à démontrer, compte-tenu de l'existence d'une solution similaire proposée par la société Google (cf conclusion).

(18)

Amigo – application de partage de données basée sur Jabber Implémentation logicielle

D.3. Conception Orientée Objet

Compte-tenu de l'ambition de l'application et de son orientation OpenSource, il paraît presque évident que la conception soit orientée objet. UML permettra de mettre cela en pratique simplement, notamment par l'utilisation d'environnements de développement adéquats et d'outils de modélisation et reverse-engineering (cf brique projet de Yves Vilbé du second trimestre).

D.4. Le stockage des données

L'application utilisant un framework Jabber basé sur XML, le stockage des données sera effectué sous cette forme. Cette homogénéité entre le stockage des données, le protocole et le format d'échange permettra de factoriser le code d'une manière appréciable.

Les données binaires (ie fichiers) seront stockées selon une arborescence à définir mais étroitement liée à l'architecture des différents composants.

Le stockage n'est pas la base du système, mais son implémentation devra être faite en parallèle au coeur de l'application afin de faciliter les tests au fur et à mesure du développement de l'application.

D.5. Environnement de développement, langages

Le choix de la technologie Jabber a été partiellement dicté par l'aspect messagerie instantanée et le format XML, mais aussi par la richesse des librairies disponibles dans de très nombreux langages. Ceci permettait de ne pas choisir de langage a priori.

Néanmoins, après analyse des solutions disponibles et des contraintes (interface graphique, orientation multi- plate-forme, librairies Jabber), deux solutions sortent du lot :

– C++ / QT – Java / Swing

Compte-tenu de la disponibilité d'environnements de développements avancés et libres pour la technologie Java, c'est a priori vers cette solution que s'oriente le développement.

L'utilisation de l'environnement Eclipse permettra un gain de temps appréciable, et la disposition de plugins de reverse-engineering pour Java est un plus indéniable.

Enfin, l'un des gros avantages de Java est de compiler l'application une unique fois pour la déployer sur tout type de plate-forme. Là encore, cela évite d'avoir à maintenir plusieurs exécutables (même si cela ne dispense pas d'effectuer des tests).

(19)

Amigo – application de partage de données basée sur Jabber Conclusion générale

E. Conclusion générale

Ce projet a été très intéressant et formateur. Basé sur un projet personnel, cette brique d'enseignement a été l'occasion de vraiment y passer du temps et de s'intéresser à différentes technologies. La difficulté principale qui s'est présentée à moi était de travailler seul. En effet, lorsqu'un travail est encadré il y a des contraintes à respecter, des délais à tenir. C'était bien entendu le cas également dans cette brique projet, mais la difficulté résidait dans le fait d'être juge et partie.

Ce projet a également été l'occasion de découvrir ce qu'était véritablement un protocole et d'en spécifier un. Le protocole Amigo défini ici est bien entendu massivement basé sur Jabber, c'est là tout l'intérêt de l'extensibilité de Jabber.

La conception n'a pas été abordée, faute de temps. C'est un point regrettable, néanmoins le projet me tenant à coeur, je vais le poursuivre dans un cadre personnel. Comme indiqué dans la partie Implémentation logicielle, l'orientation projet Open Source sera un moyen de prolonger le projet jusqu'à une implémentation et la publication d'une application complètement opérationnelle.

Le concept d'Amigo, à savoir partager des données numériques au sein d'un groupe de personnes défini est un principe intéressant les gens auxquels j'en ai parlé. La démocratisation des messageries instantanée en est un signe, et l'apparition récente d'une application de partage de photos basée sur le même principe (proposée par Google) est la preuve du bien fondé de l'idée. Les gros avantages d'Amigo par rapport à cette solution propriétaire, qui a l'avantage d'exister déjà, sont :

– l'appui sur une technologie de messagerie instantanée (Jabber) en plein développement

– une orientation multi-plateforme laissant l'utilisateur libre d'utiliser le système d'exploitation qu'il souhaite – un protocole ouvert et documenté qui permettra, le cas échéant, à quiconque de développer son application.

(20)

Amigo – application de partage de données basée sur Jabber Annexes

F. Annexes

F.1. Les spécifications Jabber étudiées

Voici la liste des spécifications que j'ai étudiées avant d'imaginer le protocole Amigo. Les JEP qui sont sans intérêt dans le concept d'Amigo sont grisées.

Intérêt Sujet Nom Url

- Data Forms JEP-0004 http://www.jabber.org/jeps/jep-0009.html

- Jabber-RPC JEP-0009 http://www.jabber.org/jeps/jep-0009.html

+ Service Discovery JEP-0030 http://www.jabber.org/jeps/jep-0030.html

+ Multi-User Chat JEP-0045 http://www.jabber.org/jeps/jep-0045.html

++ vcard-temp JEP-0054 http://www.jabber.org/jeps/jep-0054.html

++ XHTML-IM JEP-0071 http://www.jabber.org/jeps/jep-0071.html

+ In-Band Registration JEP-0077 http://www.jabber.org/jeps/jep-0078.html - NON-SASL Authentication JEP-0078 http://www.jabber.org/jeps/jep-0078.html ++ Jabber Date and Time Profiles JEP-0082 http://www.jabber.org/jeps/jep-0082.html ++ Error Condition Mappings JEP-0086 http://www.jabber.org/jeps/jep-0086.html ++ Roster Item Exchange JEP-0093 http://www.jabber.org/jeps/jep-0093.html

++ File Transfert JEP-0096 http://www.jabber.org/jeps/jep-0096.html

F.2. Bibliographie

– Programming Jabber, de DJ Adams, aux éditions O'reilly, janvier 2002

F.3. Webographie

Titre Url

Serveur de news de développement Jabber news://gmane.network.jabber.devel Site web dela fondation Jabber http://www.jabber.org

Liste des spécifications de la fondation Jabber http://www.jabber.org/jeps/jeplist.shtml

Le site web du projet Amigo http://amigo.tuxfamily.org

Amigo. Application de partage de données. Protocole spécifique & Conception logicielle

Amigo

Application de partage de données

Protocole spécifique

&

Conception logicielle

Sommaire

A. Introduction...4

B. Présentation du concept Amigo...4

B.1. Introduction...4

B.2. Amigo dans une infrastructure Jabber de messagerie instantanée...4

B.2.a. Le partage de données est basé sur la liste de contacts du profil Jabber...5

B.2.b. Minimiser les risques de collision avec un client de messagerie instantanée...5

B.2.c. Limitations...6

B.3. Exemples : cas d'utilisation d'Amigo...6

B.3.a. Un interlocuteur souhaite informer ses amis d'un évènement : la fête d'anniversaire qu'il compte organiser le week­end suivant...6

B.3.b. Leo a perdu le message et se connecte avec un client Amigo. Lorsqu'il se connecte, seul Eric est en ligne...7

C. Le Protocole Amigo : une surcouche de Jabber...8

C.1. Espaces de Nom Amigo...8

C.1.a. Les services...8

C.1.b. Les données...9

C.2. Les données : contenu XML...9

C.2.a. La base commune...9

C.2.b. amigo:data:message...10

C.2.c. amigo:data:event...10

C.2.d. amigo:data:presence...10

C.2.e. amigo:data:vcard...10

C.2.f. amigo:file:file...10

C.2.g. amigo:file:image...11

C.3. Messages et Requêtes Amigo...11

C.3.a. Création/modification de données à l'aide de <message/>...12

C.3.b. Requêtes <iq/>...12

C.3.b.1. Découverte des services...12

C.3.b.2. Récupération des données liées à un service...13

C.3.b.3. Récupération de fichiers liés à une donnée amigo:file:*...14

C.3.c. Gestion d'erreurs...14

C.4. Conclusion ...16

D. Implémentation logicielle...16

D.1. Introduction...16

D.2. Planning de développement...16

D.2.a. Choix des technologies utilisées...16

D.2.b. Conception UML de l'application...16

D.2.c. Développement itératif de l'application...16

D.3. Conception Orientée Objet...16

D.4. Le stockage des données...17

D.5. Environnement de développement, langages...17

E. Conclusion générale...17

F. Annexes...18

F.1. Les spécifications Jabber étudiées...18

F.2. Bibliographie...18

F.3. Webographie...18

A. Introduction

B. Présentation du concept Amigo

B.1. Introduction

B.2. Amigo dans une infrastructure Jabber de messagerie instantanée

B.3. Exemples : cas d'utilisation d'Amigo

C. Le Protocole Amigo : une surcouche de Jabber

C.1. Espaces de Nom Amigo

C.2. Les données : contenu XML

C.3. Messages et Requêtes Amigo

C.4. Conclusion

D. Implémentation logicielle

D.1. Introduction

D.2. Planning de développement

D.3. Conception Orientée Objet

D.4. Le stockage des données

D.5. Environnement de développement, langages

E. Conclusion générale

F. Annexes

F.1. Les spécifications Jabber étudiées

F.2. Bibliographie

F.3. Webographie

B.3.a. Un interlocuteur souhaite informer ses amis d'un évènement : la fête d'anniversaire qu'il compte organiser le weekend suivant...6