<?xml version="1.0"?>
<!DOCTYPE jxta:PipeAdvertisement>
<jxta:PipeAdvertisement xmlns:jxta="http://jxta.org">
    <Id>
        urn:jxta:uuid-
    59616261646162614E504720503250338E3E786229EA460DADC1A176B69B731504
    </Id>
    <Type>
         JxtaUnicast
    </Type>
    <Name>
        TestPipe.end1
    </Name>
</jxta:PipeAdvertisement>

PeerGroup netPeerGroup;
try
{
     // Création et démarrage du groupe par défaut de JXTA
     netPeerGroup = PeerGroupFactory.newNetPeerGroup();
}
catch (PeerGroupException e)
{
     // Impossible d’instancier le groupe
     e.printStackTrace();
     System.exit(1);
}

System.out.println("Hello from group "+netPeerGroup.getPeerGroupName());
System.out.println("Group ID = "+netPeerGroup.getPeerGroupID().toString());
System.out.println("Peer name = " +netPeerGroup.getPeerName());
System.out.println("Peer ID = " +netPeerGroup.getPeerID().toString());
netPeerGroup.stopApp();

Hello from group NetPeerGroup
Group ID = urn:jxta:jxta-NetGroup
Peer name = suzi
Peer ID = urn:jxta:uuid-59616261646162614A78746150325033F3B

PipeAdvertisement aPipeAdv = new PipeAdvertisement();
StructuredTextDocument aDoc = (StructuredTextDocument)
aPipeAdv.getDocument(new MIMETYPE("text/xml"));
try
{
     aDoc.sendToStream(System.out);
} catch(Exception e) {}

PipeAdvertisement myPipeAdvertisement = null;
try
{
nbsp;    FileInputStream is = new FileInputStream("service1.adv");
nbsp;    myPipeAdvertisement = (PipeAdvertisement)
nbsp;    AdvertisementFactory.newAdvertisement(new MimeMediaType("text/xml"), is);
}
catch (Exception e) {}

ModuleSpecAdvertisement msa = (ModuleSpecAdvertisement)AdvertisementFactory.
newAdvertisement(ModuleSpecAdvertisement.getAdvertisementType());

msa.setName("JXTASPEC:JXTA-CH15EX2");
msa.setVersion("Version 1.0");
msa.setCreator("Antho”);
msa.setModuleSpecID(IDFactory.newModuleSpecID(myService1ID));
msa.setSpecURI("");
msa.setPipeAdvertisement(myPipeAdvertisement);

import java.util.Enumeration;
import net.jxta.discovery.DiscoveryEvent;
import net.jxta.discovery.DiscoveryListener;
import net.jxta.discovery.DiscoveryService;
import net.jxta.exception.PeerGroupException;
import net.jxta.peergroup.PeerGroup;
import net.jxta.peergroup.PeerGroupFactory;
import net.jxta.protocol.DiscoveryResponseMsg;
import net.jxta.protocol.PeerAdvertisement;

public class DiscoveryDemo implements DiscoveryListener
…

// Obtention du service de discovery depuis le net peer group obtenu précédemment
DiscoveryService discovery = netPeerGroup.getDiscoveryService();
discovery.addDiscoveryListener(this);

// Fonction envoyant les requêtes dans une boucle
while (true)
{
     System.out.println(“Envoi d’un message de discovery”);
     discovery.getRemoteAdvertisements(null, DiscoveryService.PEER, null, null, 5);
     try
     {
    nbsp;    Thread.sleep(60 * 1000);
     }
     catch(Exception e) {}
}

// Fonction appelée en cas de Discover Event
public void discoveryEvent(DiscoveryEvent ev)
{
     // On récupère le message correspondent à l’évènement
     DiscoveryResponseMsg res = ev.getResponse();
     String name = "unknown";
     PeerAdvertisement peerAdv = res.getPeerAdvertisement();
     if (peerAdv != null)
     {
         String name = peerAdv.getName();
         System.out.println("Réception de "+res.getResponseCount()+" advertisements du
         peer : "+name) ;
        
         PeerAdvertisement adv = null;
         Enumeration en = res.getAdvertisements();
         if (en != null)
         {
             // On affiche les peers connus par le peer qui nous a répondu
              while (en.hasMoreElements())
             {
                  adv = (PeerAdvertisement) en.nextElement();
                 System.out.println (" Peer name = " + adv.getName());
              }
         }
     }
}

Envoi d’un message de discovery
Réception de 5 réponses du peer : unknown
Peer name = suz
Peer name = jsoto-2K
Peer name = peertopeer
Peer name = JXTA.ORG 237
Peer name = Frog@SF05

Enumeration localEnum;
try
{
     localEnum = DiscoveryService.getLocalAdvertisements(DiscoveryService.PEER,
     “Name”, “*test*”);
if (localEnum != null)
     {
         while (localEnum.hasMoreElements())
         {
             Element elem = localEnum.nextElement();
         }
     }
} catch (Exception e) {}

RendezVousService rdv = netPeerGroup.getRendezVousService();
System.out.printl("Attente de connexion au rendezvous...");
while (!rdv.isConnectedToRendezVous())
{
     try
     {
         Thread.sleep(2000);
     }
     catch (InterruptedException ex) {}
}

8.4.2) Notification asynchrone

Une autre possibilité est d’implémenter l’interface RendezVousListener.
Il suffit alors d’implémenter la méthode correspondante : rendezvousEvent(). Celle-ci sera appelée automatiquement lorsqu’un évènement lié au rendezvous a lieu.
Il peut s’agir d’un évènement de :

• Connexion (RdvConnect) : lorsque le peer est connecté au rendezvous.
• Déconnexion (RdvDisconnect) : le peer est déconnecté du rendezvous.
• Reconnexion (RdvReconnect)
• Echec (RdvFailed)

8.5) Publication d’un advertisement

Le service de discovery expliqué ci-dessus ne se limite pas aux fonctionnalités énoncées.
En effet, pour pouvoir découvrir des advertisements, il faut bien sûr que ceux-ci aient été préalablement publiés.

Il existe quatre méthodes permettant cette publication :

Ces méthodes peuvent donc être groupées suivant leur portée : locale ou distante.
Chaque advertisement publié possède une durée de vie par défaut de un an, mais celle-ci peut également être spécifiée grâce à une méthode polymorphe de la méthode.

8.5.1) Publication locale

Dans le cas d’une publication locale, l’advertisement est placé dans le cache du peer émetteur et est envoyé en mutlicast sur le réseau local.

DiscoveryService.publish(myAdvertisement, DiscoveryService.ADV);

8.5.2) Publication distante

Un advertisement publié de manière distante sera ajouté au cache du peer, publié sur le réseau local et surtout, envoyé aux différents rendezvous.
Cette technique est bien sûr à utiliser pour faire connaître son service sur tout le réseau, Internet y compris.

DiscoveryService.remotePublish(myAdvertisement, DiscoveryService.ADV);

8.6) Les groupes de peers

8.6.1) Création d’un groupe

Les groupes de peers (5.3) sont un des concepts de base d’un réseau peer to peer.
Ils permettent de regrouper des peers autour d’un même type de services.
L’exemple suivant va décrire la marche à suivre pour créer un tel groupe et publier des advertisements pour celui-ci, afin qu’il soit connu sur le réseau.
Il faut commencer par créer un ModuleImplAdvertisement, celui-ci contient tous les services de base que chaque groupe se doit d’implémenter. Il est obtenu par l’intermédiaire de la méthode getAllPurposePeerGroupImpleAdvertisement() de l’objet de type PeerGroup, instanciant le groupe de base : le Net Peer Group. Il s’agit du groupe obtenu lors du lancement de la plateforme JXTA (voir 8.1).
La méthode newGroup du groupe par défaut est alors appelée pour créer le nouveau groupe.

PeerGroup pg = myGroup.newGroup(null, implAdv, "Groupe 1”, "Groupe de test");

Quatre arguments sont passés à cette méthode :

• Un ID (PeerGroup) : il s’agit de l’ID du groupe qui va être créé. Si il est null, cet ID sera généré automatiquement.
• L’advertisement (Advertisement) de ce groupe.
• Le nom (String) du groupe.
• La description (String) du groupe.

L’appel à cette méthode newGroup va publier le groupe fraîchement créé dans le cache local.
Il faut ensuite procéder à une publication distante pour faire connaître ce groupe à l’extérieur du réseau local. Cela est réalisé très simplement grâce à une des méthodes expliquées au chapitre précédent (8.5.2) : remotePublish().

8.6.2) Rejoindre un groupe

L’exemple suivant décrit la méthode à adopter pour joindre un groupe.
Le Membership Service permet de ‘’postuler’’ pour rejoindre un groupe, de joindre celui-ci et de prolonger son bail dans ce groupe.
Ce service permet également à un peer de s’établir une identité dans le groupe.
Un credential est créé en correspondance avec cette identité, permettant de prouver que le peer possède réellement cette identité. Cette notion d’identité est utilisée par les services pour déterminer les droits de chaque peer.
Ce credential est représenté par un jeton et doit être présent dans chaque message envoyé. L’adresse de l’émetteur est placée dans l’enveloppe du message JXTA et est comparée avec l’identité de l’émetteur, qui se trouve dans le credential.
La séquence pour établir une identité est la suivante :

• Postuler : le peer fournit un credential initial au Membership Service. Celui-ci sera utilisé par le service pour déterminer quelle méthode d’authentification sera nécessaire pour établir l’identité de ce peer. Si le service autorise cette authentification, un objet d’authentificateur adéquat est retourné.
• Joindre : l’authentificateur complété est retourné au service et l’identité de ce peer est ajustée en fonction du nouveau credential disponible avec l’authentificateur.
• Prolonger : quelle que soit l’identité établie pour ce peer, elle revient automatiquement à l’identité « nobody » à intervalle régulier. La séquence doit donc être exécutée à nouveau pour prolonger son adhésion au groupe.

Le credential fournit donc deux pièces importantes : la méthode d’authentification demandée et l’identité qui sera fournie à cette méthode.
Toutes les méthodes d’authentification ne se basent pas sur l’identité.

Pour joindre un groupe donné, il faut donc commencer par générer le credential pour le peer :

Ce constructeur requière trois arguments :

• Le groupe (PeerGroup) : il s’agit du groupe pour lequel le credential est créé.
• La méthode d’authentification (String) : celle-ci sera demandée lorsque le credential sera envoyé au Membership Service du groupe.
• Informations d’identité (Element) : il s’agit d’informations optionnelles sur l’identité du peer, qui seront utilisées par la méthode d’authentification.

Il faudra ensuite récupérer le Membership Service du groupe que l’on souhaite rejoindre via la méthode getMembershipService(). Il suffit alors d’appeler la méthode apply() de ce service en lui passant le credential précédemment généré en paramètre.
Cet appel va retourner un objet de type Authentificator qui va permettre de vérifier le succès de l’opération. La technique pour ensuite compléter cet objet est unique à chaque méthode d’authentification. La seule fonction commune est isReadyForJoin() qui est assez explicite.
Après avoir postulé, l’étape suivante est de rejoindre le groupe. Cela s’effectuer simplement en appelant la méthode join() du service d’adhésion.
Il est important de remarquer que lorsqu’un peer rejoint un groupe, il cherche automatiquement un rendezvous pour ce groupe. Si il n’en trouve pas, il deviendra dynamiquement un rendezvous pour ce groupe.

8.7) Les pipes

8.7.1) Réception

Cet exemple illustre la méthode à utiliser pour établir une communication entre deux peers en utilisant les pipes (5.5). Les pipes fournissent un canal de communication unidirectionnel et asynchrone entre deux peers.
La classe PipeService définit un ensemble d’interfaces pour créer et accéder à des pipes, à l’intérieur d’un groupe de peers.
Une application qui souhaite établir une communication en réception avec d’autres peers doit créer un tube en entrée et lier celui-ci à un pipe advertisement spécifique.
L’application publie ensuite cet advertisement afin que d’autres applications puissent créer un tube en sortie, permettant d’envoyer des messages au tube correspondant en entrée.
Les pipes sont identifiés de manière unique par l’intermédiaire de pipes ID (UUID). Chaque pipe advertisement contient l’identifiant du pipe correspondant. C’est cet ID qui est utilisé pour associer les pipes en entré et en sortie.
Il est important de signaler qu’un pipe est indépendant de tout peer ou emplacement géographique. L’association entre le pipe et sa localisation physique est effectuée par l’intermédiaire du Pipe Binding Protocol (PBP). Il s’agit en fait d’un mécanisme de recherche permettant de trouver à chaque instant les peers qui utilisent un pipe donné.

Ce premier exemple va donc créer un pipe en entrée et écouter sur celui-ci en l’attente de tout message entrant.
La première étape est de créer une classe implémentant l’interface PipeMsgListener.
Il faut ensuite récupérer le Pipe Service par l’intermédiaire du net peer group et sa méthode getPipeService(). Il est nécessaire de créer un pipe advertisement, celui-ci pourra être généré à la volée ou être construit depuis un fichier (voir 8.2).
Le pipe est alors créé grâce à la méthode createInputPipe() du Pipe Service. Celle-ci prend deux paramètres en entrée, il s’agit de l’advertisement du pipe et du listener associé (l’objet qui recevra les évènements liés au pipe).
C’est bien sûr la classe qui vient d’être créée qui sera enregistrée comme listener. Sa méthode pipeMsgEvent() (apportée par l’interface PipeMsgListener) sera automatiquement invoquée pour chaque évènement de type pipeMsgEvent correspondant à la réception d’un message.
L’évènement possède sa méthode getMessage() permettant de renvoyer le message associé. Ce dernier est composé de plusieurs éléments sous forme de couple clé/valeur. Chaque élément peut être extrait via la méthode getMessageElement() prenant en paramètre le nom du tag à récupérer.

Une autre méthode que la notification asynchrone peut être utilisée, il s’agit du polling.
Il suffit pour cela d’appeler la méthode poll() :


Le paramètre est un timeout en millisecondes. Le système restera bloqué pendant la durée du timer ou jusqu’à ce qu’un message soit reçu.

8.7.2) Envoi

Cet exemple crée un pipe en sortie et envoie un message sur celui-ci.
La classe créée implémente l’interface OutputPipeListener.
La méthode de création s’utilise de la même façon que pour un tube en entrée, il s’agit de createOutputPipe() du Pipe Service. Les paramètres nécessaires sont l’advertisement du pipe et le listener.
La méthode outputPipeEvent() est appelée automatiquement lorsque les endpoints du pipe sont reliés. La méthode getOutputPipe() de l’évènement permet de récupérer le pipe qui vient d’être créé.
Il faut alors créer le message à envoyer en appelant le constructeur de la classe Message.
Un message est composé d’éléments, le pipe en entrée et en sortie doivent se mettre d’accord sur le format de ces messages.
Pour ajouter un élément au message, il faut commencer par le créer en appelant le constructeur de StringMessageElement, prenant comme paramètres, le nom du tag, la valeur et une éventuelle signature. Il suffit alors d’appeler la méthode addMessageElement() de l’objet message en lui passant l’élément à ajouter en paramètre.
Une fois le message assemblé, il ne reste plus qu’à l’envoyer via la méthode send du pipe, puis éventuellement fermer le tube via sa méthode close.

Pour information, voici la structure du fichier d’advertisement utilisé dans ces exemples :


Aussi bien le pipe en lecture que celui en écriture utilise ce fichier. Il est important qu’ils utilisent le même pipe ID pour être en mesure de communiquer.

8.8) Les pipes bidirectionnels

8.8.1) Serveur

Comme expliqué au point 5.6, les tubes bidirectionnels permettent d’effectuer des échanges fiables et dans les deux sens.
Dans l’exemple suivant, deux applications vont être créées : une va instancier un JxtaServerPipe et attendre pour des connexions tandis que l’autre va s’y connecter.

Les différentes étapes ayant déjà été expliquées précédemment, elles ne seront pas décrites ici. Il s’agit bien sûr du lancement de la plateforme JXTA, de l’adhésion au Net Peer Group et de la création du pipe advertisement (via un fichier ou à la volée).

Le JxtaServerPipe possède notamment les méthodes suivantes :

• bind : permet d’effectuer le lien entre le JxtaServerPipe et un advertisement spécifique. Les paramètres requis sont le groupe et le pipe advertisement.
• accept : permet de se placer en attente de connexions sur la socket, et d’accepter celles-ci.
• setPipeTimeout : spécifie le timeout pour établir une connexion avec un JxtaBidiPipe. Une valeur de 0 bloque indéfiniment.

On peut remarquer qu’il est ainsi très simple de mettre en place un serveur multi-thread, un thread prenant en charge chaque nouvelle connexion.

8.8.2) Client

Le client va quant à lui devoir créer un JxtaBiDsiPipe et se connecter au serveur.
Ce pipe est créé très simplement en appelant le constructeur correspondant : JxtaBiDiPipe().
Il suffit alors d’appeler la méthode connect et de s’enregistrer comme listener pour tout évènement lié à un message. La classe devra pour cela implémenter l’interface PipeMsgListener qui appellera sa méthode pipeMsgEvent automatiquement.

Les méthodes principales du JxtaBidiPipe sont :

• connect : permet de se connecter à un pipe distant. Il en existe plusieurs versions polymorphes, celle utilisée ici prenant en paramètres : le groupe, le peer ID, le pipe advertisement, un timeout et le listener.
• getMessage : lit un message sur le pipe.
• sendMessage : envoie un message sur le pipe.
• setReliable : permet rendre le tube fiable ou non.

8.9) Les sockets JXTA

La JxtaSocket est un tube bidirectionnel présentant la même interface qu’une socket Java classique. Les JxtaSockets s’utilisent donc de manière très similaire aux sockets de base.
Il est cependant important de noter que les sockets JXTA n’utilisent pas l’algorithme de Nagel. C’est donc le rôle des applications de « vider » les sockets lorsque c’est nécessaire, en utilisant la méthode flush().
Comme précédemment, cet exemple utilise deux applications, une créant le serveur et l’autre le client.

On constate que le code n’apporte aucune surprise et est bien connu.
Un avantage considérable est le fait de pouvoir créer des flux sans aucune difficulté. Il ne faut cependant pas oublier d’appeler les méthodes flush pour éviter toute mauvaise surprise.

Du côté du client, le code ressemble à ceci :


Le constructeur prenant les mêmes paramètres que la méthode connect des pipes (le groupe, le peer ID, l’advertisement et le timeout). La seule différence étant le boolean passé en dernier permettant de spécifier si la communication est fiable ou non.

8.10) Le multicast

JXTA n’a pas fini de nous étonner et introduit encore un autre moyen de communication.
La JxtaMulticastSocket va ainsi permettre de joindre des groupes multicast et d’envoyer d’une traite un message à tout un groupe.
Les avantages sont considérables, surtout pour une application de conférence comme celle développée dans le cadre de ce stage !
Les sockets utilisent des DatagramPacket comme moyen de communication et le contenu de ceux-ci doit être spécifié sous forme de bytes.
Les datagrammes transportent également un peerID qui est représenté par une InetAddress. Celle-ci est toujours composée du couple hôte/adresse IP, l’hôte étant l’ID du peer et l’adresse IP toujours égale à 0.0.0.0 (étant donné qu’elle n’a aucun sens dans un réseau JXTA).
La JxtaMulticastSocket est construite au dessus des tubes propagés et dérive de la MulticastSocket de base de Java.

Voici un exemple d’utilisation :

Une application peut également répondre directement à un message reçu sans envoyer la réponse à tout le groupe :

8.11) Les modules

8.11.1) Introduction

Les groupes de peers fournissent les fonctionnalités de bases nécessaires pour un système peer to peer. Il est cependant possible de compléter celles-ci en ajoutant des services additionnels, utilisables par tous les peers.
Un module est une des possibilités pour fournir un service. Il s’agit simplement d’une fonctionnalité destinée à être téléchargée, permettant à un peer d’instancier un nouveau comportement.
Par exemple, pour rejoindre un groupe particulier, un peer aurait à apprendre une méthode de recherche spécifique à ce groupe. Il lui faudrait pour cela instancier le module correspondant.
Ces modules sont annoncés par différents advertisements :

• Module Class : cet advertisement est utilisé pour annoncer l’existence d’une fonctionnalité. Chaque module class est identifié par un identifiant unique : le ModuleClassID.
• Module Specification : cette spécification contient toutes les informations nécessaires pour accéder et invoquer le module. Elle peut également contenir un pipe advertisement à utiliser pour communiquer avec le service. Il peut exister plusieurs modules specifications pour un module class donné. Chaque spécification étant identifiée par un ModuleSpecID. Le ModuleSpecID contenant le ModuleClassID indiquant le module class associé.
• Module Implementation : il s’agit de l’implémentation d’une spécification donnée. Il peut exister plusieurs implémentations pour une spécification donnée. Chaque implémentation contient le ModuleSpecID de la spécification associée.

Comme exemple, considérons le discovery service de base du noyau JXTA. Il possède un unique ModuleClassID l’identifiant comme étant un service de découverte. Il peut exister différentes spécifications pour ce service, chacune utilisant une technique de découverte différente, par exemple en fonction de la taille du réseau. Chaque spécification possède son propre ModuleSpecID pointant ver le ModuleClassID du service. Et enfin pour chaque spécification il peut exister de multiples implémentations contenant le ModuleSpecID correspondant. Ce système a été instauré car un des objectifs du peer to peer est que n’importe quel peer (et donc sur n’importe quel environnement, utilisant n’importe quel langage) puisse implémenter la même spécification. Les implémentations peuvent ainsi être écrites dans différents langages, tout en fournissant le même service.

8.11.2) Les advertisements

Le Module Class Advertisement est composé de trois éléments :

• Le MCID : ModuleClassID ;
• Le nom ;
• La description.

Cet advertisement est fort simple, l’élément important étant bien sûr le MCID qui sera utilisé par la spécification et l’implémentation.

Une fois que le Module Class Advertisement a été publié sur le réseau, il doit normalement être suivi par un Module Specification Advertisement. Un de ses objectifs est donc de fournir des informations sur le module class.

Cet advertisement est composé des éléments suivants :

• Le nom ;
• La description ;
• MSID : ModuleSpecID ;
• CRTR : une chaîne de caractères représentant l’auteur de la spécification ;
• SURI : une URI qui pointe vers une spécification actuelle ;
• Vers : une chaîne de caractères représentant la version de la spécification ;
• Parm : les paramètres qui peuvent être recherchés par le receveur de l’advertisement ;
• Pipe : un pipe advertisement qui peut être utilisé pour communiquer avec un peer qui implémente cette spécification ;
• Proxy : un ModuleSpecID optionnel d’un module qui peut être utilisé pour communiquer avec le module de cette spécification ;
• Auth : le ModuleSpecID d’un module qui peut être requis pour l’authentification avant l’utilisation de cette spécification.

Une fois que l’implémentation d’une spécification a été créée, il faut publier un Module Implementation Advertisement. Ce dernier est utilisé pour annoncer aux peers où trouver l’implémentation.

Les éléments de cet advertisement sont les suivants :

• Le nom ;
• La description ;
• Proxy : un élément utilisé pour garder une URL à travers laquelle la communication pourra être dirigée ;
• MSID : ModuleSpecID ;
• Comp : un élément avec les informations requises à propos de l’environnement sur lequel cette implémentation peut s’exécuter ;
• PURI : la localisation du package, si il n’est pas trouvé dans le code de la machine du client ;
• Code : informations nécessaires pour qu’un peer puisse charger et exécuter le code. Il peut s’agir du code complet ;
• Parm : paramètres pour l’implémentation ;
• Prov : une chaîne de caractères contenant les informations sur le fournisseur de cette implémentation.

8.11.3) Programmation

Dans cet exemple, un ModuleClassID est créé et publié dans un an ModuleClassAdvertisement. Un ModuleSpecID (basé sur le ModuleClassID) est ensuite créé et ajouté dans un ModuleSpecAdvertisement. Un pipe advertisement est ensuite ajouté dans le ModuleSpecAdvertisement qui est ensuite publié.
Les autres peers peuvent alors découvrir cet advertisement, en extraire le pipe advertisement et communiquer avec le service.

La première partie est celle du serveur, c’est lui qui va créer le service, ouvrir un tube en entrée, effectuer les différentes publications et se mettre à l’écoute des différents messages.

Le ModuleClassAdvertisement est créé par l’intermédiaire de l’objet AdvertisementFactory et sa méthode newAdvertisement() prenant en paramètre le type d’advertisement requis.
Il faut ensuite inititialiser cet advertisement en appelant ses différentes méthodes telles que setName, setDescription, setModuleClassID, etc. Le ModuleClassID est quant à lui généré via la méthode newModuleClassID() de l’objet statique IDFactory.
Il suffit alors de publier cet advertisement grâce aux méthodes maintenant bien connues du Discovery Service : publish() et remotePublish().
La technique est identique pour la création du ModuleSpecAdvertisement.
Il suffira alors de créer le pipe advertisement depuis un fichier, comme expliqué au chapitre 8.2.2.

Le code pourrait donc ressembler à ceci :

Le client quant à lui recherche le service nommé JXTA-EX1 et récupère l’advertisement du pipe correspondant. Il crée alors un tube en sortie sur celui-ci et envoie différents messages.
Cela s’effectue par l’intermédiaire du service de Discovery évoqué au chapitre 8.3.

Lors de la découverte du service, on récupère le pipe advertisement et on crée un tube en sortie sur celui-ci :

9) La sécurité

9.1) Introduction

Depuis le début de son élaboration, JXTA a été étudié suivant une certaine politique de sécurité.
Il s’agit d’un gros avantage car il a déjà été prouvé par le passé, qu’une application dont la sécurité n’est pas intégrée dès le départ dans le processus de développement, est beaucoup moins sécurisée et donc plus simple à attaquer.
La sécurité d’un réseau peer to peer n’est bien sûr pas évidente à implémenter et cela du au fait de sa propre architecture. En effet, l’environnement étant distribué, il n’existe pas d’autorité centralisée. Le chemin parcouru pour utiliser un service chez un peer distant n’est pas défini, il pourrait très bien passer par cinq peers intermédiaires dont les intentions pourraient être douteuses.
Les besoins en sécurité de JXTA sont très similaires aux systèmes traditionnels mais sa nature décentralisée rend plus difficile l’implémentation de la confidentialité, l’intégrité ou encore la non répudiation.

Le projet de sécurité JXTA, représenté par le security toolkit a trois objectifs principaux :

• Fournir des pipes sécurisés : cela est rendu possible grâce à l’option JxtaUnicastSecure qui assure que toutes les communications entre les peers seront chiffrées. Il s’agit d’une forme semblable au SSL, fournissant une connexion sécurisée transparente ;
• Assurer l’authenticité et l’intégrité des données : cette fonctionnalité est fournie par les algorithmes de chiffrement et différentes méthodes de checksum ;
• Assurer la non répudiation des transactions : le toolkit fournit pour cela la possibilité de signer les messages.

Le security toolkit (jxta.security) de JXTA fournit des mécanismes de base pour définir des clés secrètes et RSA, effectuer des chiffrements RC4, créer des messages digests au format SHA-1 et MD5, et créer des signatures digitales sécurisées.
Les APIs cryptographiques de JXTA sont fort différentes de celles du J2SE pour la bonne et simple raison que JXTA est basé sur le modèle des Java Card. Cela est bien sûr indispensable étant donné que les applications doivent pouvoir être exécutées sur différentes plateformes, et notamment J2ME (appareils mobiles et sans fils tels que les PDAs ou les smart phones).

9.2) Les clés

Le premier pas pour utiliser l’infrastructure de sécurité JXTA est d’obtenir une paire de clés.
Pour rappel, il en existe deux types :

• Les clés secrètes : ce sont des clés symétriques qui sont utilisées pour crypter et décrypter l’information. Elles sont dites symétriques car c’est la même clé qui est utilisée des deux côtés de la communication. JXTA utilise les clés secrètes pour les ciphers RC4.
• Les clés publiques et privées : il s’agit cette fois de clés asymétriques. Les données qui sont chiffrées (ou signées) avec une clé publique ne peuvent être que déchiffrée la clé privée correspondante et inversement. JXTA supporte les algorithmes basés sur les paires de clés RSA.

La différence principale entre ces deux types de clés est la façon dont elles sont partagées.
Dans le cas du chiffrement asymétrique, il suffit de partager sa clé publique. Ainsi toute personne qui souhaite vous contacter crypte les données avec votre clé publique. Vous serez alors le seul à pouvoir décrypter le message car vous êtes le seul à posséder la clé privée correspondante. De plus, lorsque vous chiffrez un message avec votre clé privée, il est très simple de s’assurer que le message vient bien de vous étant donné qu’il sera décrypté avec votre clé publique.
Les clés secrètes doivent quant à elles, comme indiqué dans leur nom, rester secrètes.
Seules les participants à la communication peuvent posséder cette clé, différents moyens doivent donc être mis en œuvre pour générer cette clé et s’assurer qu’elle est identique des deux côtés.

Toutes les clés utilisées dans JXTA implémentent l’interface Key (jxta.security.cipher.Key). Celle-ci définit les méthodes de base qui sont utilisées par toutes les clés.
Les clés publiques et privées implémentent respectivement les interfaces PublicKey et PrivateKey (jxta.security.publickey). En fonction du type de clés, elles peuvent encore implémenter d’autres interfaces telles que par exemple : RSAPublicKey (jxta.security.publickey.RSAPublicKey).

La classe KeyBuilder permet de créer des objets Key. Les types suivants sont disponibles :

La taille de la clé doit également être précisée : plus la clé est lourde, plus elle sera difficile à découvrir. L’objet KeyBuilder supporte les tailles de clé suivantes :


Il est important de remarquer que les clés ainsi produites ne sont pas initialisées, le processus pour effectuer cette initialisation va varier en fonction des algorithmes supportés par la clé.

9.2.1) Création d’une paire de clés RSA

La création de la clé s’effectue très simplement grâce au KeyBuilder.
L’initialisation se fait quant à elle par l’intermédiaire de l’objet de type PublicKeyAlgorithm obtenu via le JxtaCryptoSuite (celui-ci sera expliqué au chapitre suivant).
La méthode setPublicKey() va ensuite calculer la clé publique en fonction de la taille spécifiée.
L’appel de setPrivateKey() va quant à lui générer la clé privée en fonction de la clé publique. Il est donc très important de garder cet ordre d’invocation des méthodes.

Il est évidemment intéressant de sauver ces clés sur un support quelconque, il faut pour cela pouvoir récupérer leurs valeurs. Celles-ci sont représentées par la classe RSAxxxkeyData :


Il alors facile de recréer les clés depuis ces valeurs :

9.2.2) Création d’une clé RC4

Pour initialiser une clé RC4, il suffit d’obtenir un ensemble de bytes aléatoires, ceux-ci seront passés en paramètres à la méthode setKey :

9.3) La suite JxtaCrypto

Une suite est similaire à une factory.
Elle va donc permettre de récupérer un objet répondant à un profil prédéfini.

Les profils actuellement disponibles sont les suivants :

• PROFILE_RSA_RC4_SHA1
• PROFILE_RSA_RC4_MD5
• PROFILE_RSA_RC4_SHA1_MD5
• MEMBER_RC4

Si le développeur veut utiliser l’authentification des messages pour assurer l’intégrité de ceux-ci, les profils suivants sont également disponibles :

• ALG_RC4_SHA1
• ALG_RC4_MD5

Et si l’on souhaite signer les messages, on peut encore utiliser :

• ALG_RSA_SHA1_PKCS1
• ALG_RSA_MD5_PKCS1

La JxtaCryptoSuite est créée en utilisant un de ses nombreux constructeurs. Le prototype est le suivant :

Il existe donc trois manières pour utiliser les algorithmes dans le security toolkit :

• Instancier un JxtaCryptoSuite avec tous les algorithmes ;
• Instancier un JxtaCryptoSuite avec des algorithmes sélectionnés ;
• Ne pas utiliser la suite et instancier des algorithmes indépendants.

Exemple d’instanciation d’une suite :

La suite permet alors de récupérer des objets qui réalisent les opérations nécessaires :

• getJxtaCipher() ;
• getJxtaHash() ;
• getJxtaMAC() ;
• getJxtaPublicKeyAlgorithm() ;
• getJxtaSignature.

L’algorithme ainsi obtenu peut alors être utilisé pour chiffrer et déchiffrer des données.

9.4) Chiffrement/Déchiffrement

9.4.1) RSA

L’exemple suivant décrit la marche à suivre pour crypter et décrypter des données en utilisant le security toolkit.
Il faut commencer par créer la clé RSA et la JxtaCryptoSuite. Cette dernière prendra comme paramètre le profil RSA tandis que les autres seront nuls, ce qui signifie qu’aucun algorithme d’authentification et de signature n’est nécessaire. La suite permet alors de récupérer l’algorithme qui sera utilisé via la méthode getJxtaPublicKeyAlgorithm().
Les clés, publique et privée, sont alors initialisées avec setPublicKey() et setPrivateKey().
Les valeurs de celles-ci sont alors récupérées dans des objets de type RSAxxxkeyData.
Les tableaux de bytes sont ensuite créés à la taille exacte grâce à la méthode getMaxInputDataBlockLength().
La clé publique ou privée est alors positionnée, suivant qu’il s’agisse d’un cryptage ou d’un décryptage. Le chiffrement/déchiffrement est enfin effectué via la méthode Algorithm :

Le premier paramètre étant le tableau de bytes, le second est le byte pour commencer l’encryption, le troisième est la taille du tableau, le quatrième est la clé à utiliser et le dernier est un boolean spécifiant qu’on effectue un chiffrement (true) ou un déchiffrement (false).

Le code ressemble donc à ceci :

9.4.2) RC4

Le code de cet exemple est très similaire au précédent. La différence majeure étant le fait que RC4 peut traiter des tableaux de grande taille, contrairement à RSA qui limite celle-ci.

9.5) Signer les données

La classe signature (jxta.security.signature.Signature) permet de créer et de vérifier des signatures digitales.
Une telle signature permet de vérifier que les données proviennent bien de la bonne source.
Les signatures digitales sont basées sur les clés RSA. La signature est créée avec une clé privée tandis que la vérification s’effectue avec la clé publique correspondante.
L’objet permettant de traiter les signatures sera obtenu, on s’en doute, par l’intermédiaire de la JxtaCryptoSuite. Il faudra pour cela lui spécifier un comportement de type : ALG_RSA_SHA1_PKCS1 ou ALG_RSA_MD5_PKCS1.
Une fois l’objet Signature obtenu, il faut l’initialiser soit en mode signature ou en mode vérification. On utilisera pour cela sa méthode init() prenant comme paramètre le mode souhaité : MODE_SIGN ou MODE_VERIFY.
A noter que la méthode update peut être utilisée pour ajouter des données à signer ou vérifier.

9.6) Le hash

La classe Hash (jxta.security.hash.Hash) calcule le message digest ou hash des données.
Un digest est un petit tableau de bytes qui est calculé sur un ensemble de données. Il n’est pas garanti qu’un hash soit unique, mais la probabilité que deux ensembles de données différents produisent le même hash est vraiment très faible.
Une fois ce hash calculé sur le message, il est joint à celui-ci et envoyé sur le réseau. A la réception, le hash est recalculé sur les données et ensuite comparé avec celui envoyé sur le message. En cas de non égalité, on peut conclure que les données ont été modifiées durant le transport. Le problème est évidemment que si une personne modifie les données en cours de route, elle peut modifier le hash par la même occasion.
Pour éviter ce problème il faut signer ce hash avec une signature digitale ou préférer utiliser un MAC (voir chapitre suivant).
L’API JXTA supporte deux algorithmes de hash : MD5 et SHA1. Les objets Hash sont récupérés grâce à la méthode getJxtaHash() de la JxtaCryptoSuite.
Une fois cet objet Hash récupéré, il suffit d’ajouter les données sur lesquelles le hash sera généré via la méthode update. La génération du hash en lui-même est alors réalisée grâce à la méthode doFinal.

9.7) Le MAC

La classe MAC (jxta.security.mac.MAC) crée un hash sécurisé en le chiffrant avec RC4.
Un MAC peut donc être comparé à une signature, la différence étant située au niveau des clés utilisées. Ainsi, si une signature digitale utilise une paire de clés RSA (publique et privée), le MAC utilise quant à lui une clé secrète qui doit être partagée entre les correspondants. C’est donc la même clé qui servira pour la création et la vérification du MAC.
Il faut donc commencer par créer une clé secrète et l’initialiser avec un nombre aléatoire.
Les données du MAC sont ensuite ajoutées via la méthode update().
Le MAC est alors généré par l’intermédiaire de la méthode encrypt().

9.8) Des communications sécurisées

Les pipes utilisés jusqu’à présent sont non sécurisés et présentent donc les problèmes suivants :

• Les données transmises sur le réseau circulent en clair, n’importe quelle personne ayant accès au réseau peut donc les lire (confidentialité).
• Les données peuvent passer par d’autres ordinateurs qui peuvent donc en profiter pour les modifier (intégrité).
• On ne peut jamais être certain que l’on communique avec la même personne. Un peer peut en effet très bien se faire passer pour quelqu’un qu’il n’est pas (authentification).

Les tubes sécurisés offrent les solutions en utilisant des données signées permettant d’identifier les peers en communication. Les données sont également cryptées, assurant ainsi leur intégrité et leur confidentialité.
La technologie utilisée est en fait le JXTATLS qui est basée sur SSLv3 et TLSv1. JXTA utilise une paire de clés RSA pour initialiser la connexion, il utilise également le triple-DES pour chiffrer les données et enfin des signatures digitales. Une des caractéristiques du triple-DES est qu’il utilise des clés de 192 bits, ce qui le rend très difficile à pirater.
Pendant l’initialisation, chaque peer sur le pipe présente son certificat attestant de sa clé publique aux autres peers. Ceux-ci vont alors valider le certificat pour s’assurer de l’identité du peer distant.
Par défaut, les certificats utilisés sont issus de la plateforme JXTA elle-même, ce qui signifie que ces certificats sont auto signés et donc peu sûr. Il est cependant possible de modifier cela pour utiliser des certificats basés sur des autorités bien connues.

Mais comment tout ce système est-il mis en place ? La réponse est très simple, comme expliqué précédemment il existe plusieurs types de pipes et ce type est précisé dans le pipe advertisement. Pour créer un tube sécurisé il suffit donc d’appeler la méthode adéquate :

Rien de très compliqué… Il ne faut cependant pas oublier que l’utilisation de communications sécurisées ralenti évidemment les échanges, et cela du en fait des opérations de chiffrement/déchiffrement.

Avec toutes les techniques expliquées dans ce chapitre consacré à la sécurité, il serait cependant tout à fait possible de créer notre propre système de communication sécurisé. Cela permettrait par exemple d’avoir plus de contrôle sur les algorithmes de chiffrement à utiliser, etc.
Il faudrait donc par exemple commencer par créer une paire de clés RSA. Ensuite créer un pipe, publier son advertisement et se mettre en écoute sur celui-ci.
De l’autre côté, il suffirait de rechercher cet advertisement et de créer le pipe correspondant.
Le client peut alors demander la clé publique au serveur. Ce dernier sérialise donc celle-ci et la fait parvenir au client. Il recrée ainsi la clé RSA avec la valeur reçue et crypte un premier message de test. Le serveur décrypte se message et vérifie donc que tout est correct.
Il s’agit bien sûr d’un schéma assez simple, il peut cependant facilement être complété avec des certificats, des vérifications d’intégrité, etc.

Les opérations pourraient être représentées comme ceci :

10) Créer un groupe sécurisé

10.1) Introduction

Dans les exemples décrits jusqu’à présent, chaque peer peut rejoindre un groupe sans aucune restriction. Le Membership Service (voir 8.6.2) permet cependant de limiter l’accès à un groupe aux peers qui possèdent un ensemble de credentials suffisant. Le groupe examine donc les credentials d’un peer et détermine alors si celui-ci est autorisé à le rejoindre. Pour pouvoir implémenter un tel système d’authentification, il est nécessaire de créer une classe qui dérive de la class abstraite Membership. Cette classe implémente les politiques d’accès du groupe. Une implémentation existante est la classe PasswdMembershipService. Celle-ci est initialisée avec une liste d’utilisateurs et leurs passwords. Ainsi, chaque peer qui veut joindre un groupe utilisant ce service doit fournir un credential avec le password approprié.

10.2) Création de l’advertisement d’implémentation

Comme expliqué dans le chapitre consacré aux modules (voir 8.11), un groupe est représenté par plusieurs advertisements : module class, specification et implementation. Pour créer un groupe sécurisé, utilisant le PasswdMembershipService il faut créer un nouveau implementation advertisement qui contient les informations nécessaires à l’utilisation de ce service.
Pour effectuer cela, il faut copier l’advertisement par défaut et modifier les champs requis.

Les étapes pour créer son propre implementation advertisement sont les suivantes :

• Copier l’advertisement d’implémentation par défaut d’un groupe ;
• Retrouver le memebership service dans les éléments de cet advertisement ;
• Modifier l’élément membership avec les informations sur le PasswdMembreshipService ;
• Publier le nouvel advertisement.

Il faut donc commencer par créer un objet de type ModuleImplAdvertisement qui va être une copie de l’advertisement par défaut du net peer group. On utilise pour cela la méthode getAllPurposePeerGroupImplAdvertisement() du groupe par défaut.
Un groupe offre de nombreux services de base et pas uniquement celui de membership. Il faut donc d’abord retrouver ce dernier pour pouvoir le modifier. La méthode getParam() du ModuleImplAdvertisement permet de récupérer un PeerGroupParamAdv, il s’agit de la liste des services qui va pouvoir être récupérée dans une hashtable grâce à sa méthode getServices().
Cette hashtable va donc être parcourue, chacun de ses éléments est casté en ModuleClassID et la méthode isOfSameBaseClass() de ce dernier est appelée, prenant refMembershipSpecID en paramètre. Ce dernier est l’identifiant du service d’adhésion et la méthode isOfSameBaseClass() permet donc logiquement de déterminer si le MCID récupéré est celui du Membership Service.
Une fois que le service a été trouvé, il faut donc le modifier pour apporter le mécanisme d’authentification. Il suffit pour cela de modifier le nouvel advertisement en appelant les méthodes adéquates : setModuleSpecID pour spécifier le passwordMembershipSpecID, setCode pour signaler ou se trouve le code correspondant et setDescription pour annoncer qu’il s’agit d’un groupe sécurisé. L’ancien service peut alors être supprimé de la hashtable par un simple remove() et le nouveau ajouté via put().
Il ne reste alors qu’à publier l’advertisement en utilisant la technique déjà expliquée précédemment.

10.3) Création de l’advertisement du groupe

La création de cet advertisement se fait de manière habituelle, avec les nuances suivantes :

• Une nouvelle implémentation ayant été créée pour le groupe, il faut lui préciser la spécification pour celle-ci ;
• Il faut enregistrer la liste des logins et passwords dans la section Param de l’advertisement.

L’advetisement en lui-même est créé simplement via l’objet statique AdvertisementFactory (voir 8.3.3). Sa spécification est spécifiée en appelant la méthode setModuleSpecID, prenant en paramètre le ModuleSpecID de l’advertisement créé au chapitre précédent (mia.getModuleSpecID()).
Il faut alors créer un document structuré contenant les codes d’accès et placer celui-ci dans la section aram de l’advertisement du groupe.
Ce dernier peut alors être publié et il ne reste plus qu’à créer le groupe.

Il est important de noter que l’algorithme de chiffrement utilise par PasswdMembershipService.makePsswd est très faible et donc insécurisé. Il est donc vivement conseillé d’utiliser un autre algorithme pour crypter ses passwords.

10.4) Joindre le groupe

Une fois que le groupe a été découvert, un peer doit suivre différentes étapes pour y adhérer :

• Récupérer le credential d’authentification du groupe ;
• Obtenir l’authentificateur lié à ce document (voir 8.6.2) ;
• Compléter l’authentificateur avec les informations nécessaires ;
• Utiliser cet objet pour joindre le groupe.

Comme déjà expliqué, le credential est récupéré en passant le groupe au constructeur de AuthentificationCredential. Le MembershipService est quant à lui obtenu via la méthode getMembershipService du groupe.
Il faut alors appeler la méthode apply de ce service pour récupérer l’objet de type authentificator. Ce dernier sera ensuite casté en PasswdAuthentificator.
Le login et le password seront alors spécifiés en appelant les méthodes setAuth1Identity() et setAuth2_Password().
Le groupe peut alors être rejoint en appelant la méthode join du Membership Service.

Il va de soi que les informations demandées par l’authentificator varient en fonction du service d’adhésion utilisé. Dans notre cas il s’agit d’un login et d’un password car nous utilisons le PasswdMembershipService.
Ce dernier est très simple, il ne fait que comparer le password reçu avec ceux présents dans le champs Param de l’advertisement du groupe.
Je rappelle qu’il est cependant possible de créer ses propres services de membership, répondants à des critères d’adhésion très précis.
Un service plus complexe est Envision qui permet d’obliger à crypter les passwords, de signer les credentials ou encore d’interagir avec un annuaire LDAP.
Au niveau de la programmation, n’importe quel service respectera cependant les règles énoncées ci-dessus. La seule différence est les informations passées à l’authentificateur qui varient d’un service à un autre.

11) Un réseau privé

Une technique très simple pour protéger et sécuriser son réseau JXTA est de le rendre privé.
Cela permet d’isoler son réseau du reste du réseau public et donc d’apporter un certain niveau de sécurité.

Pour qu’un tel système puisse fonctionner, il devient bien sûr indispensable d’implémenter ses propres peers de rendezvous et de relay, permettant d’établir la communication entre les différents peers situés sur des extrémités différentes du réseau. Un réseau privé permet donc également d’avoir plus de contrôle sur le fonctionnement de ce lui-ci.
Si le cryptage est de plus implémenté sur le réseau privé, ce dernier pourrait alors être comparé à un VPN.
Pour éviter que chaque peer ne rejoignent le net peer group par défaut mais plutôt le réseau privé, il suffit de placer un fichier config.properties dans le dossier .jxta de chaque peer. Ce fichier contient les informations sur le groupe principal du réseau privé, à savoir : son ID, son nom et sa description.
Le code permettant de lancer la plateforme JXTA doit alors être adapté pour prendre en compte ce fichier. L’objet statique PeerGroupFactory déjà utilisé pour rejoindre le net peer group possède différentes méthodes permettant de le configurer. Parmi celles-ci, on remarque notamment : setNetPGID(), setNetPGName() et setNetPGDesc(). C’est donc grâce à elles qu’on va pouvoir configurer le groupe, en récupérant les informations du fichier properties.
Le code pourrait alors ressembler à ceci :

Une question qui peut venir à l’esprit est : comment générer l’ID de notre groupe privé?
Il suffit pour cela de créer un digest sur le nom et la description du groupe puis de passer celui-ci à la méthode newPeerGroupID() de l’objet IDFactory :

Si JXTA est encore peu connu, plus que probablement suite à la mauvaise réputation du peer to peer, il ne fait aucun doute qu’il s’agit d’une technologie très évoluée aux multiples avantages.
Cette suite de protocoles permet d’élaborer une couche réseau solide sur laquelle peut reposer tout type d’application destiné à fonctionner sur Internet. C’est pourquoi je ne serai pas surpris de voir JXTA intégré dans de nombreux projets futurs, commerciaux ou non.
Après un premier développement avec l’API Java de JXTA, une constatation s’impose : le modèle de cette technologie a été soigneusement étudié, offrant de nombreuses possibilités avec une grande facilité de développement.
JXTA a de plus l’énorme avantage d’être une solution Open Source, et donc en perpétuelle évolution …

  Version imprimable

Commentaires

Pseudo :
Code anti-spam :	(recopier : )

Salut as tu une adresse par laquelle on pourait se contacter stp? Je te donne la mienne : kevin36_69@hotmail.com. Merci ++

Posté par Kev le 28-04-2007

Superbe article ! Vraiment du beau travail, ça fait plaisir de trouver de la documentation française de cette qualité sur ce sujet. Un grand merci et bonne continuation.

Posté par Brice le 08-05-2007

Félicitation pour votre travail. Je me suis souvent rapporté à votre étude afin de mener à bien mon projet. Merci.

Posté par EZ3kiel le 13-05-2007

excellent article sur jxta, il y a beaucoup de chose que j'ai apris. Un grand merci. Je voulais vous demandez au passage, si vous pouviez s'il vous plait ajouter dans votre article, comment utilise etape par etape jxta 2.4 dans eclipse 3.2 en utilisant un simple exemple tel que l'exemple 8.1) HelloWorld, car je debute sur eclipse et jxta et je ne sais pas comment faire.

Posté par debutant le 01-06-2007

Superbe article ;Félicitation pour votre travail! meme question de mon frere (debutant )comment utilise etape par etape jxta 2.4 dans eclipse 3.2 en utilisant un simple exemple tel que l'exemple 8.1) HelloWorld, car je debute sur eclipse et jxta et je ne sais pas comment faire.pcq le projet de fin d'etude(techmique de p2p avec l'utilisation de jxta)Un grand grand merci et bonne continuation.

Posté par nabilchaabi22@hotmail.fr le 27-10-2007

Génial vraiment. Merci beaucoup.

Posté par Fabien le 12-11-2007

Bon boulot ! ça m