Protocoles de Peer to Peer Etudes d’approfondissement A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Sommaire 1. Présentation du sujet 2. Le protocole GNUtella 3. La plate-forme de développement JXTA A.Thaveau & M-A Bourgeot

Historique et définition Concept ancien : existant depuis l’informatique distribuée (~=30 ans). Il a vraiment été popularisé par Napster. Un système d'échange direct de ressources entre machines connectées. Au départ, Internet était vu comme un système Peer-to-Peer. A.Thaveau & M-A Bourgeot

Définition et avantages Littéralement " égal à égal " : les ordinateurs sont à la fois clients et serveurs. Possibilités de plus en plus accrues avec l'évolution des ordinateurs. Permet la décentralisation des contenus ainsi qu’une meilleure répartition des taches. A.Thaveau & M-A Bourgeot

Applications typiques Calcul distribué : projet SETI. Echange de fichiers : Napster, Gnutella … Stockage distribué : Chord, CFS (MIT). Plate-forme de développement et groupe de collaboration : JXTA (Sun). A.Thaveau & M-A Bourgeot

Les deux types d’architecture. Architecture répartie assistée par un serveur central permettant d’indexer les ressources. Typiquement l’architecture du système Napster. A.Thaveau & M-A Bourgeot

Les deux types d’architecture. Architecture purement décentralisée. Utilisé par Gnutella, FastTracks. Plus difficile à réaliser mais plus intéressant car plus robuste et plus distribué. A.Thaveau & M-A Bourgeot

Une architecture changeante Au départ Internet était conçu pour des ordinateurs disposant d’une adresse IP fixe. Allocation dynamiques des adresses IP, NAT et firewalls en compliquent le fonctionnement. Les développeurs et les opérateurs doivent s’adapter. A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Le protocole GNUtella Histoire et concept. Fonctionnement Evolutions A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot GNUtella Développé par NullSoft (J.Frankel & T.Pepper) qui fut ensuite racheté par AOL-Time-Warner. Diffusé peu de temps sur le Web, il put être implémenté par de multiples programmeurs sur différents OS. C’est un protocole et non un programme. A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot GNUtella : le concept Le programme exécutant est un " servant " : à la fois client et serveur. Il permet de faire des demandes d’informations ainsi que des réponses à celles-ci. Il permet de faire des téléchargements ainsi que des envois. A.Thaveau & M-A Bourgeot

GNUtella : concept technique Le protocole est utilisé par des nœuds connectés avec TCP/IP. Des milliers de connections à travers des milliers de nœuds créent une " web " d’ordinateurs : le réseau GNUtella. Les téléchargements se font directement via HTTP. A.Thaveau & M-A Bourgeot

GNUtella : fonctionnement 1.L’ordinateur trouve un ordinateur auquel se connecter. 2.L’ordinateur annonce qu’il est arrivé sur le réseau. 3.L’ordinateur peut ensuite émettre des requêtes et y répondre, il route aussi les messages. 4.Il peut télécharger ou envoyer des fichiers. A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot GNUtella : Connexion Pour trouver une machine déjà connectée, il faut se connecter à un hostcache. Le hostcache garde les adresses de certaines machines connectées. Le client à généralement une liste de hostcache. A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot GNUtella : connexion Une fois une machine trouvée, il faut s’y connecter : Demande : GNUTELLA CONNECT/0.4\r\n User-Agent: Gnucleus 1.4.5.0\r\n \r\n Si l’ôte accepte la connexion, il envoie : GNUTELLA/0.4 200 OK\r\n User-Agent: Gnucleus 1.4.5.2\r\n \r\n Après cela, les échanges peuvent commencer : GNUTELLA/0.4 200 OK\r\n \r\n A.Thaveau & M-A Bourgeot

GNUtella : arrivée sur le réseau Utilisation du paquet ping : il sert à decouvrir les autres nœuds sur le réseau. Sert à donner une mesure de la taille de l' "horizon". Caractéristiques du paquet (commun à tous les paquets gnutella): GUID : identifiant du paquet Function : identifiant du type paquet TTL : time to live Hops : nombre de sauts déjà accomplis Payload length : longueur du descripteur suivant l’en-tête A.Thaveau & M-A Bourgeot

GNUtella : arrivée sur le réseau Description du paquet pong : Caractéristiques : En-tête Port : le port sur lequel le servant écoute. Host : IP du servant File Count : nombre de fichiers partagés File Size : taille de tous les fichiers partagés Ce paquet est routé jusqu’au "pinger". A.Thaveau & M-A Bourgeot

GNUtella : arrivée sur le réseau Ping Pong A.Thaveau & M-A Bourgeot

GNUtella : les requêtes Pour une demande de fichier, on envoie un paquet de type Query : Caractéristiques : En-tête Minimum Speed : vitesse minimum de transfert d’un client qui aurait un fichier correspondant Query : Mots-clés correspondant à la recherche. A.Thaveau & M-A Bourgeot

GNUtella : les requêtes Si un ordinateur possède un fichier correspondant à une requête, il envoie un paquet de type QueryHit : Caractéristiques : En-tête. Number of hits : Nombre de "coups au but" dans le Result Set. Port : le port sur lequel le servant écoute. Host : IP du servant. Speed : vitesse du servant atteint. Result Set : Ensemble de réponses à la requête correspondante ( Number of hits ) ->File Index : identifiant du fichier. ->File Size : taille du fichier ->File Name : nom du fichier correspondant à l’index. Servent identifier : Chaîne de 16 octets qui identifie le servent répondant à la requête. A.Thaveau & M-A Bourgeot

GNUtella : le paquet push Un servant ne peut initier de connexion HTTP avec un autre servant derrière un firewall. Avec le paquet push, il demande au servant du fichier d'initier la connexion. Caractéristiques : En-tête. Servent identifier : Chaîne de 16 octets qui identifie le servent qui doit pousser le fichier. File Index : identifiant du fichier devant être poussé. Host : IP du servant vers lequel le fichier doit être poussé. Port : le port vers lequel le fichier doit être poussé. A.Thaveau & M-A Bourgeot

GNUtella : le routage des paquets Technique de "flooding" -> inondation. Les pings sont envoyés à tous les voisins sauf à l'émetteur. Les pongs empruntent le même chemin que les pings. Le routage des paquets QueryHits fonctionne comme celui des pongs. A.Thaveau & M-A Bourgeot

GNUtella : téléchargement Une fois un fichier choisi, le téléchargement se fait par connexion HTTP directe entre 2 servants. Demande : GET /get/2975/How Towels Work.txt HTTP/1.0\r\n User-Agent: LimeWire 1.8\r\n Range: bytes=0-\r\n \r\n Réponse : HTTP 200 OK\r\n Server: Gnucleus 1.4.5.2\r\n Content-type:application/binary\r\n Content-length: 2894894\r\n \r\n A.Thaveau & M-A Bourgeot

GNUtella : première topologie du réseau Les nœuds sont tous égaux et jouent exactement le même rôle. Saturation lors de la montée en charge. Trop de messages circulant. A.Thaveau & M-A Bourgeot

GNUtella : nouvelle topologie du réseau Besoin de changements. Comment améliorer le réseau? Utilisation des "ultrapeers". A.Thaveau & M-A Bourgeot

GNUtella : les ultrapeers Fin 2001 : LimeWire relance le concept et l'implemente dans son client. Une hierarchie de nœuds est créée : Ultrapeers : Bonne capacité de calcul et de transfert. "Nœuds Feuilles" : Ordinateurs "normaux". A.Thaveau & M-A Bourgeot

GNUtella : les ultrapeers Envoi périodique d’ "indexing queries" à ses fils. L’ultrapeer ne fait suivre les "queries" qu’aux clients qui ont une entrée correspondante. Compatible avec les clients anciens qui sont vus comme des ultrapeers sans fils. A.Thaveau & M-A Bourgeot

GNUtella : choix des ultrapeers L’ordinateur ne doit pas être situé derrière un firewall et doit avoir un système d’exploitation relativement récent. Doit avoir une bande passante et un processeur de bonne qualité. Doit être sur le réseau depuis assez longtemps. A.Thaveau & M-A Bourgeot

Etablissement des connexions : feuille sur ultrapeer GNUTELLA CONNECT/0.6 X-Ultrapeer: False User-Agent: LimeWire 1.9 X-Query-Routing: 0.1 X-My-Address: 10.254.0.16:6349 GNUTELLA/0.6 200 OK X-Ultrapeer: True X-Ultrapeer-Needed: false X-Try-Ultrapeers: 23.35.1.146:6346,18.207.63.25:6347 X-Try: 24.37.144.122:6346,193.205.63.22:6346 X-My-Address: 10.254.0.16:6346 X-Query-Routing: 0.1 -> GNUTELLA/0.6 200 OK A.Thaveau & M-A Bourgeot

Etablissement des connexions : feuille sur feuille protégée GNUTELLA CONNECT/0.6 X-Ultrapeer: False GNUTELLA/0.6 503 I am a shielded leaf node X-Try-Ultrapeers: 18.2.3.14:6346, 18.1.17.2:6346 [terminates connection] A.Thaveau & M-A Bourgeot

Etablissement des connexions : ultrapeer vers ultrapeer GNUTELLA CONNECT/0.6 X-Ultrapeer: True GNUTELLA/0.6 200 OK X-Ultrapeer-Needed: True A.Thaveau & M-A Bourgeot

Etablissement des connexions : ultrapeer vers ultrapeer GNUTELLA CONNECT/0.6 X-Ultrapeer: True GNUTELLA/0.6 200 OK X-Ultrapeer-Needed: false X-Ultrapeer: False   A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Problèmes Répartition des fichiers inégales. Beaucoup de «pillards». Perte d’intérêt de l’architecture. A.Thaveau & M-A Bourgeot

Réplication des données Différentes réplications connues : Réplication après téléchargement. Réplication " sur le chemin ". A.Thaveau & M-A Bourgeot

Réplication des données Réplication au hasard. Evite une concentration des fichiers. Difficile à mettre en place. A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Problèmes Tensions entre les développeurs utilisant GNUtella. Logiciels commerciaux et communautaires sur le même réseau, problèmes de compatibilité entre les clients. Logiciel qui a toujours été développé dans un esprit libre, pas de chef de file pour l’instant. A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Evolution Dynamisme et multiplicité des développeurs. De nombreuses idées prometteuses mais pas encore mis en place. Besoin d'une harmonisation des clients. A.Thaveau & M-A Bourgeot

Quelques clients GNUtella LimeWire Shareazaa BearShare Gnucleus Morpheus Ares A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot JuXTApose Le projet JXTA A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Sommaire Présentation Les objectifs de JXTA Le réseau virtuel de JXTA JXTA « Work and Play » L’architecture JXTA Les concepts du JXTA Core Les protocoles du JXTA Core Les protocoles standards de JXTA Les services JXTA Le Shell JXTA JXTA Search A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Présentation Projet de recherche de Sun Microsystems, Inc. The O’Reilly P2P conference Ensemble de protocoles peer-to-peer libres et généraux www.jxta.org A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Les objectifs de JXTA Interopérabilité Permettre à tous les Peers de toutes les communautés de communiquer entre eux grâce à une même plate forme P2P Multi plate forme Langage de programmation (C, Java, Perl, Python, Ruby) Système d’exploitation (Solaris, Linux, Windows, MacOS, …) Réseaux (TCP/IP, Bluetooth, …) Ubiquité Implémentation possible sur tout type de machine (PDA, routeur, PC, serveur, téléphones mobiles, …) Interopérabilité - rassembler toutes les communautés (AOL Messenger + Napster + Gnutella) - localiser facilement les autres peers, communiquer facilement et offrir des services Multi plate forme - on peut développer une application JXTA en C pour UNIX sur TCP/IP et communiquer avec un peer dont l’application est faite en Java sous Windows. A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Réseau virtuel de JXTA A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot JXTA « Work and Play » Industries : Télécommunications Gouvernement Divertissements Finances (enchères) Applications : communication et collaboration : instant messaging, partage de fichiers, partage d’environnement et de ressources (CPU, disques, bande passante, …) Architectures distribuées Intra entreprise : diffusion d’information, formation Nouvelle génération de jeux en réseaux A.Thaveau & M-A Bourgeot

L’architecture de JXTA JXTA Core - équivalent à une couche réseau - contient les primitives communes à tous les réseaux P2P (Peers, Peer Group, discovery, communication, éléments de sécurité) - couche responsable de l’interopérabilité JXTA Services - services réseaux utiles et préférables mais pas indispensables - recherche, partage, indexation, traduction de protocoles, agrégation de ressources, éléments de sécurité, … JXTA Applications - implémentation des applications : partage de fichiers, partage de ressources, instant messaging, e-mail - application verticale (stand alone) ou interopérable avec d’autres applications JXTA Frontière entre Services et Applications pas rigide (ex : interprétation du shell) A.Thaveau & M-A Bourgeot

Les concepts du JXTA Core (1) Peer Implémente les protocoles Core de JXTA Unique (Peer Id), indépendant et asynchrone Relations persistantes ou temporaires (Peer Group) Offre des services Peers identiques interchangeables Peer Group Ensemble de Peers en relation (sécurité, intérêts communs, surveillance) Unique (Peer Group Id) World Peer Group Peer Group Services (Discovery, Membership, Access, Pipe, Resolver, Monitoring) Peer - machine qui supporte le JXTA core = serveur, PCs, PDAs, équipements industriels ou médicaux, téléphones mobiles - Peer Id = identifiant unique pour chaque Peer - les Peers sont indépendants les uns des autres et communiquent de manière asynchrone - les Peers offrent des services aux autres Peers (routage) - les Peers qui offrent les mêmes services sont interchangeables de manière transparente - la communication directe entre 2 Peers est très rare; les messages traversent plusieurs Peers avant d’arriver au destinataire Peer Group - 3 motivations : * créer un environnement sécurisé : échange de données sensibles * rassembler certaines personnes : intérêts communs, autarcie * surveiller un ensemble de Peers spéciaux : machines critiques - un Peer Group peut être ouvert à tous ou alors hautement sécurisé et protégé - World Peer Group est le Peer Group par défaut auquel tout Peer appartient - Services (pas obliger de tous les implémenter dans un groupe): * discovery : accéder aux ressources partagées par les Peers du groupe (peers, peer groups, pipes, services) * membership : utiliser par les membres pour accepter/refuser les nouvelles demandes d’adhésion * access : accepter/refuser certaines requêtes entre les Peers du groupe * pipe : gérer la communication entre les Peers * resolver : interroger un service proposer par un Peer et recevoir une réponse de ce service * monitoring : permettre à un Peer de surveiller d’autres Peers A.Thaveau & M-A Bourgeot

Les concepts du JXTA Core (2) Peer Pipe Canal virtuel de communication entre Peer Endpoints Différentes qualités de services Unidirectionnel et asynchrone Synchronisé Streaming Sécurisé Point-to-point pipe (1~1) et propagate pipe (1~n) Messages XML Peer Monitoring, Peer Metering Capacité d’obtenir un ensemble d’information sur un Peer Peer Pipe - pour envoyer et recevoir des messages (datagrammes) entre les services ou entre les applications - ils supportent le transport de code binaire, de chaîne de caractères, d’objets Java et d’applets - abstraction au-dessus des Peer Endpoints (interfaces réseaux des Peers) - les Pipes sont liés dynamiquement aux Peer Endpoints et sont indépendents du lieu où se trouve le Peer (Pipe Binding Protocol) - seul les Pipes « asynchrones et unidirectionnels » sont obligatoires pour utiliser les protocoles JXTA - XML pour l’aspect « Multi plate forme » Peer Monitoring - Permet d’obtenir l’état actuel d’un Peer et de contrôler son comportement - Permet de prévenir les pannes de Peer « critiques » et d’effectuer les actions adéquates (correction, remplacement, …) Peer Metering - Mesure d’éléments d’activité d’un Peer en vue d’analyse A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Les Peer Pipes A.Thaveau & M-A Bourgeot

Les protocoles du JXTA Core Peer Resolver Protocol (PRP) Interrogation d’un service dans un Peer Group Utilise le Rendezvous Protocol Handler Name Resolver Query Message, Resolver Response Message Endpoint Routing Protocol (ERP) Trouver une route vers un Peer qui n’est pas accessible (routage non déterministe) Peer Routers Route Query Message, Route Response Message Marquage des messages Peer Resolver Protocol - généralement envoyées par des services - requêtes adressées au groupe, pas à un Peer spécifique - seuls les Peers habilités peuvent répondre = ceux qui détiennent le service avec le bon Handler Name - le Rendezvous protocol permet de distribuer l’information à tous les Peers du groupe Endpoint Routing Protocol - les routes changent rapidement et les Peers peuvent partir à tout moment - n’importe quel Peer peut devenir Peer Router - Peer Routers utiles pour relier différents réseaux physiques ou pour franchir des firewalls - si un Peer Router possède une route obsolète, alors il doit lui-même en trouver une autre (Peer Discovery Protocol) - marquage des messages par chaque Peer Router pour éviter les bouclages - un Route Query Message est contenu comme requête dans un Resolver Query Message A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Resolver Query Schema <xs:element name="ResolverQuery" type="jxta:ResolverQuery"/> <xs:complexType name="ResolverQuery"> <xs:all> <xs:element ref="jxta:Cred" minOccurs="0"/> <xs:element name="SrcPeerID" type="jxta:JXTAID"/> <xs:element name="HandlerName" type="xs:string"/> <xs:element name="QueryID" type="xs:string"/> <xs:element name="Query" type="xs:anyType"/> </xs:all> </xs:complexType> <jxta:Cred> éléments de sécurité requis par le Peer Group. <HandlerName> destination de la requête. <SrcPeerID> PeerId de l’expéditeur <QueryID> identifiant requis pour reconnaître les réponses retournées <Query> contient la requête. A.Thaveau & M-A Bourgeot

Les protocoles standard de JXTA Peer Discovery Protocol (PDP) Recherche de ressources (Peers, Peers group, pipe, services) Utilise les services pour valoriser son cache Discovery Query Message, Discovery Response Message Rendezvous Protocol (RVP) Propage les messages dans un Peer Group Contrôle de la propagation (TTL, loopback detection, …) Peer Information Protocol (PIP) Obtenir des informations sur d’autres Peers (capacités, état, …) Pipe Binding Protocol (PBP) Etablir un Pipe entre 2 ou plusieurs Peers Pipe Resolver Message Peer Discovery Protocol - faire des recherche dans son Peer Group (au début dans le World Peer Group) - un Peer Group peut utiliser son propre PDP - utilise le Peer Resolver Protocol pour router les requêtes et les réponses Rendezvous Protocol - pour propager des requêtes vers les autres Peers du groupe ou pour en recevoir Peer Information Protocol - exemple : ping Pipe Binding Protocol - utilisés par les services et les applications - permet de chercher un « Input Endpoint » - Pipe Resolver Message : une partie pour la query, une partie pour la réponse - voir les Pipes comme des files de messages auquel on se connecte pour lire ou écrire des messages, et puis desquels on se détache A.Thaveau & M-A Bourgeot

Discovery Query Schema <xs:element name="DiscoveryQuery" type="jxta:DiscoveryQuery"/> <xsd:simpleType name="DiscoveryQueryType"> <xsd:restriction base="xsd:string"> <!-- peer --> <xsd:enumeration value="0"/> </xsd:restriction> </xsd:simpleType> <xs:complexType name="DiscoveryQuery"> <xs:sequence> <xs:element name="Type" type="jxta:DiscoveryQueryType"/> <xs:element name="Threshold" type="xs:unsignedInt" minOccurs="0"/> <xs:element name="Attr" type="xs:string" minOccurs="0"/> <xs:element name="Value" type="xs:string" minOccurs="0"/> <!-- The following should refer to a peer adv, but is instead a whole doc for historical reasons --> <xs:element name="PeerAdv" type="xs:string" minOccurs="0"/> </xs:sequence> </xs:complexType> <Type> 0 Peer Advertisements 1 Peergroup Advertisements 2 Any Advertisements <Threshold> nombre max de résultats fourni par UN Peer (si type=0 et threshold=0 alors ping broadcast) A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Les services JXTA Equivalents aux librairies UNIX Fonctions au-dessus du JXTA Core Facilite le développement d’application Proposent différents mécanismes Recherche, indexation Partage de ressources Cache Transport via TCP/IP, HTTP, TLS Traitements distribués et parallèles Envoi de requêtes à l’ensemble d’un Peer Group Structure de données (XML) Communications sécurisées Usage professionnel (Intranet et Extranet) A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Le Shell JXTA (1) Accès interactif au JXTA Core Publier, rechercher et exécuter des ressources Découvrir de nouveaux Peers ou Peer Groups Envoyer et recevoir des messages Propriétés des commandes Chargées dynamiquement lors de l’appel Création de nouvelles commandes Appel : JXTA> NomCommande [-options] [arguments] Redirection des E/S (dynamique, crossing pipe) Importation/Exportation de données (share/unshare) Batch files Pipe JXTA : comme les pipes sont asynchrones et unidirectionnels, on peut les déconnecter et les reconnecter facilement (très utile pour la tolérance aux pannes) Crossing pipe : output cmd1 relié à input cmd2 et output cmd2 relié à input cmd1 (« cmd1 <> cmd2 ») A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot Le Shell JXTA (2) Commandes de base shell, env, man, exit, version more, cat, grep, ls whoami : informations sur le Peer talk peers : recherche et liste les Peers groups : recherche et liste les Peer Group mkpgrp/chpgrp : créer/changer de groupe join/leave : rejoindre/quitter un groupe search : rechercher un codat mkpipe : création d’un pipe get/put : lecture/écrire dans un message send/recv : envoyer/recevoir un message importfile/exportfile A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot JXTA Search (1) Motivations Augmentation perpétuelle de la quantité d’informations accessibles par Internet Moteurs de recherche dépassés « Hidden Web » = 400 fois plus d’informations Avantages de JXTA Protocoles en XML = Multi plate forme Requêtes distribuées (architecture décentralisée) Les acteurs Fournisseurs Consommateurs Peer Hub spécialisés (géographie, contenu, application) Avantages: - Protocoles JXTA en XML = utilisation de n’importe quel langage de programmation - Moteur de recherche distribué Les acteurs : - toutes machines supportant JXTA = serveur, PCs, PDAs, téléphones - Peer Hub = service proposé par certains Peers pour s’occuper des requêtes - spécialités : * gère les requêtes pour une certaine zone * gère les requêtes suivant leur contenu * gère les requêtes suivant l’application qui les ont générées A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot JXTA Search Network A.Thaveau & M-A Bourgeot

A.Thaveau & M-A Bourgeot JXTA Search (2) Recherche profonde (Deep Search) Pertinence Accessibilité Efficacité Query Routing Protocol (QRP) 3 composants : registers, queries, responses Query Spaces, Query Predicates Query Resolution and Routing Utilisations Recherche Internet (Google) Échanges commerciaux (Communication et synchronisation) Recherche profonde : - pertinence : pas d’indexation, prise en compte immédiate des nouveautés (modification de la registration dans les hubs) - accessibilité : on ne se sert plus de requêtes pour les pages dynamiques; infos directement fournies - efficacité : recherches de l’utilisateur accélérées par les registres; les fournisseurs ne reçoivent que les requêtes qui les concernent QRP : - Query Spaces = mots-clés - Query Predicate = opérateur de description (AND, OR) pour préciser le contenu de la requête - Query Resolution and Routing = indexation des Query Spaces, nombre de fournisseurs minimum A.Thaveau & M-A Bourgeot