WO2010076536A2 - Procède de traitement de requêtes émises par un client - Google Patents

Procède de traitement de requêtes émises par un client Download PDF

Info

Publication number
WO2010076536A2
WO2010076536A2 PCT/FR2009/052713 FR2009052713W WO2010076536A2 WO 2010076536 A2 WO2010076536 A2 WO 2010076536A2 FR 2009052713 W FR2009052713 W FR 2009052713W WO 2010076536 A2 WO2010076536 A2 WO 2010076536A2
Authority
WO
WIPO (PCT)
Prior art keywords
request
data
node
nodes
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2009/052713
Other languages
English (en)
Other versions
WO2010076536A3 (fr
Inventor
Daniel Migault
Xavier Dinand
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of WO2010076536A2 publication Critical patent/WO2010076536A2/fr
Publication of WO2010076536A3 publication Critical patent/WO2010076536A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4552—Lookup mechanisms between a plurality of directories; Synchronisation of directories, e.g. metadirectories
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1061—Peer-to-peer [P2P] networks using node-based peer discovery mechanisms
    • H04L67/1065—Discovery involving distributed pre-established resource-based relationships among peers, e.g. based on distributed hash tables [DHT] 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1087—Peer-to-peer [P2P] networks using cross-functional networking aspects
    • H04L67/1091—Interfacing with client-server systems or between P2P systems

Definitions

  • the invention relates to a technique for processing a request sent by a client to obtain data.
  • the invention finds a particularly interesting application in "DNS” (Domain Name System) systems and their secure version “DNSSEC” (for "Domain Name System Security Extensions”).
  • DNS Domain Name System
  • DNSSEC Domain Name System Security Extensions
  • the DNS system is a fundamental element of the intemet which makes it possible, for example, to associate an understandable and easily rememberable machine name with an IP address, which is more difficult for a human to memorize.
  • the DNS system functions as an important database.
  • a success of the DNS system resides in the distribution of data, or DNS data records, within hidden servers. These hidden servers keep in memory information that has already been requested by one or more customers, and that have already passed through them.
  • hidden DNS servers like that of hidden DNSSEC servers, is as follows: a client who wishes to resolve a domain name via a DNS query, for example to obtain an IP address associated with a name of domain www.monserveur.com, is primarily addressed to a cache server.
  • This cache server first checks whether the response to the request is already present in its cache memory. In the case where the cache server holds the response, it sends the response to the client. In the event that it does not hold the cached response, it performs a DNS resolution by querying one, or DNS servers from the Internet, called authoritative servers. Once the resolution is complete, the cache server holds the response and responds to the client.
  • Using cached servers saves information transfer between clients and remote servers, and decreases response times to DNS queries.
  • each server cache 201, 202, 203, 204, 205 is a DHT node of the P2P network 20, responsible for a set of data.
  • a first DHT node 201 which receives a request req_DNS from a client 10 requesting data for which it is responsible, sends the client the data resp_DNS in response to the request. Either the data is in the cache of the node 201, or the node 201 retrieves the data on an Internet network 50 by interrogating an authoritarian server not shown. For a request concerning a data for which it is not responsible, the first node 201 consults a DHT identification table (not shown in FIG.
  • such an architecture is not suitable for processing a large quantity of simultaneous requests.
  • a first DHT node of the P2P network receives a request but does not have the cache response, it looks in its table a second appropriate node to process the request. Once this second determined node, the first node retransmits the request and then waiting for a response to retransmit the client. Thus, the first node that receives the request but does not have the answer to it must remain waiting for the response.
  • the DHT tables are adapted to handle a large amount of data
  • a DNS architecture based on DHT tables and cache servers organized in a P2P network is not suitable for supporting large loads.
  • the Quality of Service offered by such an architecture degrades as the load increases as the time to respond to requests increases.
  • One of the aims of the invention is to remedy deficiencies of the state of the art.
  • the invention responds to this need by proposing a system for processing a request sent by a client to obtain data, comprising: a plurality of nodes organized in a P2P network, adapted to store a set of data distributed in the different nodes and storing an identification table adapted to identify, that among the plurality of nodes that is able to provide the data in response to the request, characterized in that it comprises: a proxy server storing said table and to which the request is intended to be addressed, said server being adapted for, following receipt of the request, only:
  • the architecture according to the invention comprises a proxy server which is dedicated exclusively to the routing of the requests it receives.
  • each DHT node is adapted to store data and to route a request it receives to the DHT node which should host the data.
  • the routing function is extemalized and performed only by the proxy server.
  • this routing function is usually very time consuming in the conventional DHT architecture of the prior art.
  • the DHT nodes are dedicated solely to data storage and thus get rid of the expensive routing function.
  • the different tasks to be performed during DNS resolutions are performed by dedicated entities, unlike the solutions of the prior art.
  • the actual storage is realized by the nodes of the P2P network, and the routing of the requests of the clients inside the platform constituted by the nodes of the P2P network.
  • P2P network is exclusively performed by the proxy server.
  • the storage of data by the nodes corresponds to the DNS resolution itself.
  • the nodes of the P2P network in this case the DNS cache servers no longer function independently, but collaborate and each manage a part of the cached data.
  • the storage of data on the different cache servers is optimized, unlike a traditional DNS architecture where the same data can be stored on multiple DNS servers caches. This avoids redundancy in the stored data, which is advantageous when the number of data to be stored increases, and / or when the size of the data to be stored is important. This is the case in DNSSEC systems.
  • the architecture according to the invention is scalable in terms of the number of network nodes: it can easily adapt to increases in DNS traffic. An evolution in terms of number of nodes does not impact the clients, for example by additional messages. Thus, this makes it possible to define an architecture comprising a predefined large number of cache nodes, each managing little data but offering in return a fast memory access.
  • the node to which the request is retransmitted is adapted to send the data directly to the client.
  • the architecture according to the invention makes it possible to limit the exchanges of messages following a request from a client.
  • the request is sent from the client to the proxy server which routes it to the cache server responsible for processing it.
  • the server that holds the cached data sends this data directly to the client.
  • the response unlike the request, does not pass through the proxy server.
  • the system comprises a resolver server, able to receive the request from the node when the data in response is not stored on said node, to perform a resolution with an authoritative server of the Internet. to obtain the data, and to send the data directly to the customer.
  • the resolver server adapted to perform a DNS resolution by interrogating an authoritative server of the Internet transmits the data received from the authoritarian server on the one hand to the node responsible for caching, and on the other hand, directly to the client. in response to his request.
  • the architecture according to the invention optimizes the processing of the request by avoiding passing the data to be sent in response to the client by intermediate nodes.
  • the nodes are hidden DNS nodes and the request is a request for resolution of domain name.
  • the identification table is a DHT table.
  • the invention also relates to a network comprising the system according to the invention and a plurality of client terminals, said terminals being configured to send requests to obtain data exclusively to the proxy server.
  • the invention also relates to a terminal for the network according to the invention configured to send requests to obtain data exclusively to the proxy server.
  • the invention also relates to a method of processing a request sent by a client to obtain data, a set of data being distributed in a plurality of nodes of a P2P network storing an identification table adapted to identify, that among the plurality of nodes that is able to provide the data in response to the request, characterized in that it comprises:
  • the invention also relates to a proxy server comprising: means for receiving a request sent by a client to obtain data,
  • an identification table suitable for identifying, among a plurality of nodes organized in a P2P network, said nodes being adapted to store a set of data distributed in the different nodes, that among the plurality of nodes which is able to supply the data in response to the request,
  • identification means adapted to identify from the table the node capable of providing the data
  • transmission means adapted to retransmit the request to the identified node.
  • the invention also relates to a computer program on a data carrier and loadable in the internal memory of a server, the program comprising portions of code for executing the steps of the method according to the invention, when the program is executed on said client device.
  • the invention relates to a data carrier on which is recorded the computer program according to the invention.
  • FIG. 1 represents a processing architecture of a request from a client to obtain a data of the prior art
  • FIG. 2 represents an architecture, according to a first exemplary embodiment of the invention, adapted to process a client request in order to obtain data in a first where the identified node holds the data to be sent in response in its memory hidden ;
  • FIG. 3 shows the exchanges between the different entities of the architecture of the invention in a second case where the identified node does not yet hold the data in its cache memory;
  • FIG. 4 presents the steps of a method of processing a request from a client according to a particular embodiment of the invention
  • P2P network DHT 20 stores an identification table 200, or DHT table, or routing table associated with the cache server network P2P 20. Only the identification table 200 stored in the DHT node 201 is shown. 200 is stored by each of the nodes The identification table 200 makes it possible to identify from a request from a client the DHT node responsible for processing the request.
  • obtaining the data to be sent in response to the request from a resolver server which is adapted to make a DNS resolution by querying a authoritarian server of the internet.
  • the first case where the identified DHT node already has the data in its cache corresponds to the case where this data has already been requested from this DHT node by a previous request, sent for example by another client.
  • the second case where the identified DHT node does not have the data in its cache corresponds to the case where the data has not yet been requested from the DHT node.
  • the DHT protocol has already identified this node as being that which is supposed to hold the data to be sent in response or, in any event, its role is to obtain it.
  • FIG. 2 relates to the first case and Figure 3 to the second case.
  • FIG. 2 represents an architecture, according to a first exemplary embodiment of the invention, adapted to process a client request in order to obtain data in the first case mentioned above.
  • a client 10 is adapted to issue "DNS" requests (for "domain name service” or “domain name service”), denoted by “req”, in order to carry out name resolutions of field.
  • the client requests the IP address associated with the name "www.mabanque.fr", in order to access the website of the bank.
  • the client 10 is configured such that its DNS requests req are exclusively addressed to a proxy server 30.
  • a configuration is to specify the IP address of the proxy server 30 in a client-specific configuration file.
  • the architecture of FIG. 2 differs from that of FIG. 1 (prior art) in particular in that it comprises a proxy server 30.
  • the proxy server 30 comprises: reception means 301, adapted to receive the requests req issued by the client 10; storage means 302 adapted to store the identification table 200; identification means 303 adapted to identify, from the request received from the client and the identification table 200, the DHT node responsible for processing the request; transmission means 304 arranged to transmit the request received from the client 10 to the identified DHT node to process the request by the identification means 303.
  • the memory means 302 are for example a non-volatile memory of the "EEPROM” type (for "Electrically Erasable Programmable Read
  • the identification table 200 is intended to be imported by the proxy server 30 from at least one DHT node, as explained later in the description.
  • the identification table 200 comprises a set of indexes. Each index, more specifically, an index range identifies a DHT node so unique.
  • a client request is used to determine an index in the identification table. It is thus possible to determine from a client request, the DHT node responsible for processing this request.
  • the index associated with a client request is obtained by applying a hash function at the request of the client. For example, SHA-1 (for "Secure Hash Algorithm-1”) can be used. The invention is of course not limited to the SHA-1 function.
  • the identification means 303 of the node 201 comprise computation means adapted to calculate a hash of the request req received from the client 10 and search means for searching the identification table 200 for the DHT node by taking as an index the hash of the query.
  • the node identified as being responsible for processing the request req for example the DHT node 201, holds the data to be sent in response in its cache memory.
  • the node 201 is adapted to send a response resp comprising the data directly to the client.
  • the reply resp is not transmitted from the DHT node 201 to the proxy server 30 which transmitted the request req to the node 201. It is transmitted from the DHT node 201 to the client having sent the request, without passing through the proxy server 30 through which the request has passed.
  • a single client 10 is shown in Figure 2.
  • the invention is not limited to the processing of requests from a single client, but is adapted to handle requests from a plurality of clients.
  • proxy server 30 is shown in FIG. 2.
  • the invention is not limited to a single proxy server.
  • network equipment such as a router can be used to direct requests from clients to different proxy servers.
  • the identification table 200 stored on each DHT server of the P2P network 20 is also stored on the proxy server 30.
  • the proxy server 30 regularly sends a request to update the table to a DHT node geographically close to him.
  • a DHT node may be parameterized in order to regularly send the identification table 200 which it stores to the proxy server 30.
  • the DHT node may also be parameterized to send an update of the identification table only during an evolution of it. For example, such an evolution of the table may be necessary when a DHT node goes out of service.
  • the DHT protocol used is adapted to recalculate the DHT table from the still active nodes.
  • FIG. 3 represents the system according to the invention, and more precisely the exchanges between the entities of the system, in a second case.
  • This second case corresponds to the case where the node DHT 201 responsible for the processing of the request req sent by the client 10 does not yet hold the cached data, the node DHT 201 is adapted to obtain the data to be sent in response to the request.
  • a resolver server 40 For this purpose, the DHT node 201 comprises interrogation means (not shown in FIG. 3) of the resolver server 40.
  • the DHT node 201 transmits the request req to the resolver server 40 which is able to perform a DNS resolution by interrogating a DNS authoritative server (not shown in FIG. 3) through an Internet network 50.
  • the node 201 also comprises means for receiving an answer resp from the resolver server 40, in this case the response to the request req, and to memorize it in its cache memory.
  • the resolver server 40 is adapted to send the response resp directly to the client that issued the request.
  • the response is not sent by the DHT node to the client, but directly by the resolver 40 to the client.
  • the response time is optimized.
  • the resolver server 40 is adapted to receive in addition to the data response to the request, a signature of said data. It is also adapted to verify said signature.
  • the number of nodes of the P2P network is finite and less than a predetermined value, for example 300, and that these nodes are operated by the same operator.
  • a predetermined value for example 300
  • the predetermined value considered to correspond to a small number of nodes, allows each node to have knowledge of all the other nodes, and in accordance with the DHT technology, allows all the nodes of the network to share a number of nodes. same identification table.
  • Managing a single ID table for all P2P network nodes facilitates the export of the table to the proxy server and the externalization of the routing function. In addition, this optimizes the routing of client requests since a node responsible for processing a request is immediately identified by consulting the table. This may not be the case when a P2P network consists of several thousand nodes. Indeed, in this case, several DHT tables may be necessary to store all the information distributed over the nodes of the P2P network and finding information among these nodes may require several successive hops from one node to another.
  • the proxy server 30 of FIG. 2 receives from client 10 a DNS resolution request req.
  • the proxy server 30 consults the identification table 200 which it stores in order to identify the DHT node responsible for processing the request req.
  • the proxy server 30 retransmits the request req to the DHT node identified as being responsible for the processing of the request, for example the node 201 of FIG. 2.
  • the node 201 receives the request req from the proxy server 30.
  • the node 201 responsible for the processing of the request searches the data to be sent in response to the request in its cache memory.
  • the node 201 In the case where the node 201 holds the cached data, it sends directly to the client 10 according to FIG. 2, the data in a message resp.
  • the node 201 In the case where the node 201 does not have the cached data, then in a step not represented in FIG. 4, it sends the request req to the resolver server 40 according to FIG. 3 adapted to perform a DNS resolution in order to obtain the answer to the query.
  • the resolver server 40 sends the request req to an authoritative server (not shown) of the Internet 50 according to FIG. 3.
  • the resolver server 40 which has obtained from the authoritative server the data in response to the request req. , transmits it, on the one hand to the node 201 which stores it in its cache memory, and on the other hand directly to the client in response to the request req.
  • the resolver server receives from the authoritative server in addition to the data, a signature of the data used to verify the integrity of the data.
  • the resolver server is also adapted to verify the signature of the data.
  • the modules 301, 302, 303 and 304 of the proxy server 30 according to FIG. 2, or FIG. 3, are arranged to implement those of the previously described steps of the method of processing a request from a client who are implemented by the proxy server 30. These are preferably software modules comprising software instructions for executing the steps of the method of processing a request from a client by the proxy server.
  • the invention therefore also relates to:
  • a computer program comprising instructions for implementing the method of processing a request from a client as described above when this program is executed by a processor;
  • the software modules can be stored in, or transmitted by, a data carrier.
  • a data carrier This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a transmission medium such as a signal, or a telecommunications network.
  • the invention is described here in the case of processing DNS queries.
  • the invention is of course not limited to the processing of DNS queries and can be applied to any protocol based on sending requests to obtain data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Multi Processors (AREA)

Abstract

L'invention concerne un système de traitement d'une requête émise par un client pour obtenir une donnée, comprenant : une pluralité de noeuds (201, 202, 203, 204, 205) organisés en réseau P2P, adaptés pour stocker un ensemble de données réparties dans les différents noeuds et mémorisant une table d'identification (200) adaptée pour identifier, celui parmi la pluralité de noeuds qui est apte à fournir la donnée en réponse à la requête, caractérisé en ce qu'il comprend : un serveur mandataire (30) mémorisant ladite table et auquel la requête est destinée à être adressée, ledit serveur étant adapté pour, suite à la réception de la requête, uniquement : identifier, à partir de la table, le noeud apte à fournir la donnée en réponse à la requête; et retransmettre la requête au noeud identifié.

Description

Procédé de traitement de requêtes émises par un client
L'invention concerne une technique pour traiter une requête émise par un client pour obtenir une donnée.
L'invention trouve une application particulièrement intéressante dans des systèmes "DNS" (de l'anglais "Domain Name System") et leur version sécurisée "DNSSEC" (pour "Domain Name System Security Extensions").
Le système DNS est un élément fondamental de l'intemet qui permet d'associer par exemple un nom de machine compréhensible et facilement mémorisable à une adresse IP, plus difficile à mémoriser pour un être humain. Le système DNS fonctionne comme une importante base de données.
Un succès du système DNS réside dans une répartition des données, ou enregistrements de donnée DNS, au sein de serveurs caches. Ces serveurs caches gardent en mémoire des informations qui ont déjà été demandées par un ou des clients, et qui ont déjà transité par leur biais.
Le principe de fonctionnement des serveurs DNS caches, comme celui des serveurs DNSSEC caches est le suivant : un client qui souhaite résoudre un nom de domaine par l'intermédiaire d'une requête DNS, par exemple pour obtenir une adresse IP associée à un nom de domaine www.monserveur.com, s'adresse en premier lieu à un serveur cache. Ce serveur cache vérifie dans un premier temps si la réponse à la requête est déjà présente dans sa mémoire cache. Dans le cas où le serveur cache détient la réponse, il envoie la réponse au client. Dans le cas où il ne détient pas la réponse en cache, il effectue une résolution DNS en interrogeant un, ou des serveurs DNS de l'Internet, appelés serveurs autoritaires. Une fois la résolution effectuée, le serveur cache détient la réponse et répond au client. L'utilisation de serveurs caches permet d'économiser des transferts d'informations entre des clients et des serveurs distants, et de diminuer des temps de réponse à des requêtes DNS.
Cependant, la gestion des serveurs caches dans une architecture DNS n'est pas optimisée. En effet, les serveurs caches fonctionnent de manière indépendante les uns des autres. Ainsi, plusieurs serveurs DNS caches sont susceptibles de stocker les mêmes enregistrements DNS. D'autre part, la version sécurisée du système DNS, DNSSEC, nécessite des informations supplémentaires pour gérer un enregistrement de données. Un fichier DNSSEC est donc, par nature, de taille beaucoup plus importante qu'un fichier DNS. En outre, depuis plusieurs années, on observe un accroissement régulier du nombre de requêtes DNS. Cette tendance devrait s'accentuer à l'avenir avec un développement de services basés sur Internet, tels que des services de voix sur IP. Il en résulte un besoin croissant de stockage de données dans des serveurs caches, données qui sont de taille plus importante dans la version sécurisée DNSSEC. Or, si des mêmes données sont stockées dans une pluralité de serveurs caches, on comprend que l'espace mémoire des serveurs caches n'est pas gérée de manière optimale. On s'expose ainsi à des problèmes de performances, notamment à des temps de réponse à des requêtes de plus en plus importants. En définitive, cela peut conduire à une dégradation du service DNS.
En vue de faire face aux problèmes de performances tels que cités précédemment, des travaux ont étudié un remplacement d'une architecture DNS classique, par une architecture de type "P2P" (pour "Peer to Peer"). Dans une telle architecture, les données sont réparties entre les serveurs caches DNS qui forment des nœuds du réseau P2P. Dans cette architecture, les serveurs caches ne sont plus indépendants et communiquent entre eux. A cette fin, il est nécessaire de disposer d'une règle de répartition des enregistrements au sein des serveurs caches. Une mise en œuvre connue d'une telle architecture repose, pour les aspects stockage et accès aux données, sur l'utilisation d'une technologie appelée table de hachage distribuée, ou "table DHT" (DHT pour "Distributed Hash Table"), ou encore table de condensats. Une telle table permet l'identification et l'obtention d'une information dans un système réparti, comme par exemple dans certains réseaux P2P. Un exemple de protocole qui utilise une table de hachage distribuée est le protocole Pastry.
Un exemple d'architecture de l'art antérieur illustrant ces travaux est présenté en relation avec la figure 1. Dans cette architecture, chaque serveur cache 201 , 202, 203, 204, 205 est un nœud DHT du réseau P2P 20, responsable d'un ensemble de données. Un premier nœud DHT 201 qui reçoit une requête req_DNS d'un client 10 qui demande une donnée dont il est responsable, envoie au client la donnée resp_DNS en réponse à la requête. Soit la donnée est dans le cache du nœud 201 , soit le nœud 201 récupère la donnée sur un réseau Internet 50 par interrogation d'un serveur autoritaire non représenté. Pour une requête concernant une donnée dont il n'est pas responsable, le premier nœud 201 consulte une table d'identification DHT (non représentée sur la figure 1 ), appelée également table de routage, afin de déterminer un deuxième nœud 204 responsable de la donnée à envoyer en réponse. Le premier nœud 201 interroge alors (DHT_req) le deuxième nœud 204. Le deuxième nœud 204 envoie au premier nœud 201 la donnée DHT_resp en réponse à la requête et le premier nœud 201 forme alors une réponse resp_DNS à destination du client qui a émis la requête et lui envoie. Une telle architecture permet d'optimiser la répartition des données au sein des serveurs caches qui gèrent ainsi chacun un ensemble particulier de données et communiquent entre eux. Cependant, elle ne permet pas de répondre à tous les besoins inhérents à un système DNS.
En particulier, une telle architecture n'est pas adaptée pour traiter une grande quantité de requêtes simultanées. En effet, lorsqu'un premier nœud DHT du réseau P2P reçoit une requête mais ne possède pas la réponse en cache, il cherche dans sa table un deuxième nœud approprié pour traiter la requête. Une fois ce deuxième nœud déterminé, le premier nœud lui retransmet la requête puis reste en attente d'une réponse à retransmettre au client. Ainsi, le premier nœud qui reçoit la requête mais n'a pas la réponse à celle-ci doit rester en attente de la réponse. Il en résulte que, bien que les tables DHT soient adaptées pour gérer une grande quantité de données, une architecture DNS basée sur des tables DHT et des serveurs caches organisés en réseau P2P n'est pas adaptée pour supporter des charges importantes. En conséquence, la Qualité de Service offerte par une telle architecture se dégrade lorsque la charge augmente puisque les délais pour répondre aux requêtes augmentent. Un des buts de l'invention est de remédier à des insuffisances de l'état de la technique.
L'invention répond à ce besoin en proposant un système de traitement d'une requête émise par un client pour obtenir une donnée, comprenant : - une pluralité de nœuds organisés en réseau P2P, adaptés pour stocker un ensemble de données réparties dans les différents nœuds et mémorisant une table d'identification adaptée pour identifier, celui parmi la pluralité de nœuds qui est apte à fournir la donnée en réponse à la requête, caractérisé en ce qu'il comprend : - un serveur mandataire mémorisant ladite table et auquel la requête est destinée à être adressée, ledit serveur étant adapté pour, suite à la réception de la requête, uniquement :
- identifier, à partir de la table, le nœud apte à fournir la donnée en réponse à la requête, et - retransmettre la requête au nœud identifié.
De façon avantageuse, l'architecture selon l'invention comprend un serveur mandataire qui est dédié exclusivement au routage des requêtes qu'il reçoit. On rappelle ici que, dans l'architecture selon l'art antérieur basée sur les tables distribuées DHT, chaque nœud DHT est adapté pour stocker des données et pour router une requête qu'il reçoit vers le nœud DHT qui devrait héberger la donnée. Avec l'invention, la fonction de routage est extemalisée et réalisée uniquement par le serveur mandataire. Or, cette fonction de routage est habituellement très coûteuse en temps dans l'architecture DHT classique de l'art antérieur. Grâce à l'invention, les nœuds DHT sont uniquement dédiés au stockage de données et s'affranchissent ainsi de la fonction, coûteuse, de routage.
On comprend qu'avec l'architecture selon l'invention, les différentes tâches à effectuer lors de résolutions DNS sont effectuées par des entités dédiées, contrairement aux solutions de l'art antérieur. Ainsi, le stockage proprement dit, est réalisé par les nœuds du réseau P2P, et le routage des requêtes des clients à l'intérieur de la plate-forme constituée des nœuds du réseau P2P est exclusivement réalisé par le serveur mandataire. Le stockage de données par les nœuds correspond à la résolution DNS proprement dite.
En outre, avec l'architecture selon l'invention, les nœuds du réseau P2P, en l'espèce les serveurs caches DNS ne fonctionnent plus de manière indépendante, mais collaborent et gèrent chacun une partie des données mises en cache. Ainsi, le stockage des données sur les différents serveurs caches est optimisé, contrairement à une architecture DNS classique où des mêmes données peuvent être stockées sur plusieurs serveurs DNS caches. On évite ainsi une redondance au niveau des données stockées, ce qui est avantageux lorsque le nombre de données à stocker croît, et/ou lorsque la taille des données à stocker est importante. C'est le cas dans les systèmes DNSSEC.
L'architecture selon l'invention est évolutive en termes de nombre de nœuds réseau : elle peut s'adapter facilement à des augmentations de trafic DNS. Une évolution en termes de nombre de nœuds n'impacte pas les clients, par exemple par des messages supplémentaires. Ainsi, cela permet de définir une architecture comprenant un nombre prédéfini important de nœuds caches, chacun gérant peu de données mais offrant en contrepartie un accès mémoire rapide.
Avantageusement, avec le système selon l'invention, le nœud auquel la requête est retransmise est adapté pour envoyer la donnée directement au client.
L'architecture selon l'invention permet de limiter les échanges de messages suite à une requête d'un client. Ainsi, la requête est envoyée du client au serveur mandataire qui la route vers le serveur cache responsable de son traitement. De façon avantageuse, le serveur qui détient la donnée en cache envoie directement cette donnée au client. La réponse, contrairement à la requête, ne transite ainsi pas par l'intermédiaire du serveur mandataire.
Dans une réalisation de l'invention, le système comprend un serveur résolveur, apte à recevoir la requête du nœud lorsque la donnée en réponse n'est pas stockée sur ledit nœud, à effectuer une résolution auprès d'un serveur autoritaire de l'Internet pour obtenir la donnée, et à envoyer la donnée directement au client. De façon avantageuse, le serveur résolveur adapté pour effectuer une résolution DNS en interrogeant un serveur autoritaire de l'internet transmet la donnée reçue du serveur autoritaire d'une part au nœud responsable pour mémorisation en cache, et d'autre part, directement au client en réponse à sa requête. Ainsi, l'architecture selon l'invention optimise le traitement de la requête en évitant de faire transiter la donnée à envoyer en réponse au client par des nœuds intermédiaires.
Dans un exemple de réalisation du système selon l'invention, les nœuds sont des nœuds DNS caches et la requête est une requête de résolution de nom de domaine.
Dans un exemple de réalisation du système selon l'invention, la table d'identification est une table DHT.
L'invention concerne aussi un réseau comportant le système selon l'invention et une pluralité de terminaux clients, lesdits terminaux étant configurés pour envoyer des requêtes pour obtenir une donnée exclusivement au serveur mandataire.
L'invention concerne également un terminal pour le réseau selon l'invention configuré pour envoyer des requêtes pour obtenir une donnée exclusivement au serveur mandataire. L'invention porte également sur un procédé de traitement d'une requête émise par un client pour obtenir une donnée, un ensemble de données étant réparties dans une pluralité de nœuds d'un réseau P2P mémorisant une table d'identification adaptée pour identifier, celui parmi la pluralité de nœuds qui est apte à fournir la donnée en réponse à la requête, caractérisé en ce qu'il comprend :
- une étape de réception de la requête du client par un serveur mandataire mémorisant ladite table,
- une étape d'identification à partir de la table du nœud apte à fournir la donnée, et - une étape de retransmission de la requête au nœud identifié.
L'invention concerne aussi un serveur mandataire comprenant : - des moyens de réception d'une requête émise par un client pour obtenir une donnée,
- des moyens de mémorisation d'une table d'identification adaptée pour identifier, parmi une pluralité de nœuds organisés en réseau P2P, lesdits nœuds étant adaptés pour stocker un ensemble de données réparties dans les différents nœuds, celui parmi la pluralité de nœuds qui est apte à fournir la donnée en réponse à la requête,
- des moyens d'identification, adaptés pour identifier à partir de la table le nœud apte à fournir la donnée, et - des moyens de transmission, adaptés pour retransmettre la requête au nœud identifié.
L'invention concerne également un programme d'ordinateur sur un support de données et chargeable dans la mémoire interne d'un serveur, le programme comprenant des portions de code pour l'exécution des étapes du procédé selon l'invention, lorsque le programme est exécuté sur ledit dispositif client.
Enfin, l'invention concerne un support de données sur lequel est enregistré le programme d'ordinateur selon l'invention.
De nombreux détails et avantages de l'invention seront mieux compris à la lecture de la description d'un mode particulier de réalisation en référence aux figures annexées données à titre non limitatif et dans lesquels :
- le figure 1 (déjà commentée) représente une architecture de traitement d'une requête d'un client pour obtenir une donnée de l'art antérieur ; - la figure 2 représente une architecture, selon un premier exemple de réalisation de l'invention, adaptée pour traiter une requête de client en vue d'obtenir une donnée dans un premier où le nœud identifié détient la donnée à envoyer en réponse dans sa mémoire cache ;
- la figure 3 représente les échanges entre les différentes entités de l'architecture de l'invention dans un second cas où le noeud identifié ne détient pas encore la donnée dans sa mémoire cache ; - la figure 4 présente les étapes d'un procédé de traitement d'une requête d'un client selon un mode particulier de réalisation de l'invention ;
On rappelle au préalable que, dans l'architecture de l'art antérieur représentée sur la figure 1 , une pluralité de serveurs caches 201 , 202, 203,
204, 205 sont organisés en nœuds "DHT' (pour "Distributed Hash Table", ou table de condensats) d'un réseau "P2P" 20 (pour "Peer-to-Peer", ou réseau pair à pair). Chaque nœud DHT du réseau P2P 20 mémorise une table d'identification 200, ou table DHT, ou table de routage associée au réseau P2P 20 de serveurs caches. Seule la table d'identification 200 mémorisée dans le nœud DHT 201 est représentée. La même table d'identification 200 est stockée par chacun des nœuds. La table d'identification 200 permet d'identifier à partir d'une requête d'un client le nœud DHT responsable du traitement de la requête.
On notera d'emblée que, dans la présente description, on entend par traitement de la requête :
- dans le cas où le nœud DHT identifié possède en cache la donnée à envoyer en réponse à la requête, l'envoi de cette donnée de réponse au client, ou
- dans le cas où le nœud DHT identifié ne possède pas en cache la donnée à envoyer, l'obtention de la donnée à envoyer en réponse à la requête auprès d'un serveur résolveur, lequel est adapté pour faire une résolution DNS en interrogeant un serveur autoritaire de l'internet.
Le premier cas où le nœud DHT identifié possède déjà la donnée dans sa mémoire cache correspond au cas où cette donnée a déjà été demandée à ce nœud DHT par une requête précédente, envoyée par exemple par un autre client. Le deuxième cas où le nœud DHT identifié ne possède pas la donnée dans sa mémoire cache correspond au cas où la donnée n'a pas encore été demandée au nœud DHT. Cependant, le protocole DHT a déjà identifié ce nœud comme étant celui qui est présumé détenir la donnée à envoyer en réponse ou, en toute hypothèse, a pour rôle de l'obtenir.
La figure 2 est relative au premier cas et la figure 3 au deuxième cas. La figure 2 représente une architecture, selon un premier exemple de réalisation de l'invention, adaptée pour traiter une requête de client en vue d'obtenir une donnée dans le premier cas mentionné ci-dessus.
Dans l'architecture selon la figure 2, un client 10 est adapté pour émettre des requêtes "DNS" (pour "Domain Name Service", ou service de nom de domaine), notées req, en vue d'effectuer des résolutions de nom de domaine.
Par exemple, avec une telle requête, le client demande l'adresse IP associée au nom "www.mabanque.fr", afin d'accéder au site internet de la banque. Le client 10 est configuré de telle sorte que ses requêtes DNS req sont exclusivement adressées à un serveur mandataire 30. Par exemple, une configuration consiste à préciser l'adresse IP du serveur mandataire 30 dans un fichier de configuration propre au client.
L'architecture de la figure 2 diffère de celle de la figure 1 (art antérieur) notamment par le fait qu'elle comprend un serveur mandataire 30. Le serveur mandataire 30 comprend : des moyens 301 de réception, adaptés pour recevoir les requêtes req émises par le client 10 ; des moyens de mémorisation 302, adaptés pour mémoriser la table d'identification 200 ; - des moyens d'identification 303 adaptés pour identifier, à partir de la requête req reçue du client et de la table d'identification 200, le nœud DHT responsable du traitement de la requête ; des moyens de transmission 304, agencés pour transmettre la requête req reçue du client 10 au nœud DHT identifié pour traiter la requête par les moyens d'identification 303.
Les moyens 302 de mémorisation sont par exemple une mémoire non volatile de type "EEPROM" (pour "Electrically Erasable Programmable Read
OnIy Memory"). La table d'identification 200 est destinée à être importée par le serveur mandataire 30 depuis au moins un nœud DHT, comme expliqué plus loin dans la description.
La table d'identification 200 comprend un ensemble d'index. Chaque index, plus précisément, une plage d'index identifie un nœud DHT de manière unique. En outre, une requête de client permet de déterminer un index dans la table d'identification. Il est ainsi possible de déterminer à partir d'une requête de client, le nœud DHT responsable du traitement de cette requête. L'index associé à une requête de client est obtenu par application d'une fonction de hachage à la requête du client. Par exemple, la fonction SHA-1 (pour "Secure Hash Algorithm-1") peut être utilisée. L'invention n'est bien sûr pas limitée à la fonction SHA-1.
Ainsi, les moyens d'identification 303 du nœud 201 comprennent des moyens de calcul adaptés pour calculer un hash de la requête req reçue du client 10 et des moyens de recherche pour chercher dans la table d'identification 200 le nœud DHT en prenant comme index le hash de la requête.
Pour rappel, on suppose ici que le nœud identifié comme étant responsable du traitement de la requête req, par exemple le nœud DHT 201 , détient la donnée à envoyer en réponse dans sa mémoire cache. Selon le premier exemple de réalisation de l'architecture selon l'invention décrit ici en relation avec la figure 2, le nœud 201 est adapté pour envoyer une réponse resp comprenant la donnée directement au client. Autrement dit, la réponse resp n'est pas transmise du nœud DHT 201 au serveur mandataire 30 qui a transmis la requête req au nœud 201. Elle est transmise du nœud DHT 201 au client ayant émis la requête, sans passer par l'intermédiaire du serveur mandataire 30 par lequel la requête a transité.
Un seul client 10 est représenté sur la figure 2. Bien sûr, l'invention n'est pas limitée au traitement de requêtes issues d'un seul client, mais est adaptée pour traiter des requêtes issues d'une pluralité de clients.
De même, un seul serveur mandataire 30 est représenté sur la figure 2. L'invention n'est pas limitée à un seul serveur mandataire. En particulier, pour garantir une bonne Qualité de Service en termes de temps de réponse, notamment dans des situations de charge importante, il est possible d'avoir une pluralité de serveurs mandataires vers lesquels des requêtes de clients sont dirigées vers différents serveurs mandataires. Disposer de plusieurs serveurs mandataires permet de limiter la charge de chacun des serveurs. Par exemple, un équipement réseau, tel qu'un routeur peut être utilisé pour diriger les requêtes issues des clients vers les différents serveurs mandataires.
La table d'identification 200 stockée sur chaque serveur DHT du réseau P2P 20 est également mémorisée sur le serveur mandataire 30. Afin de maintenir une cohérence entre la table mémorisée sur le serveur mandataire 30 et la table stockée sur les nœuds DHT, il est prévu un mécanisme d'importation de la table d'identification 200 par le serveur mandataire 30 depuis un nœud DHT. Par exemple, le serveur mandataire 30 émet régulièrement une requête de mise à jour de la table vers un nœud DHT proche géographiquement de lui. Dans un autre exemple de réalisation, un nœud DHT peut être paramétré afin d'envoyer régulièrement la table d'identification 200 qu'il mémorise au serveur mandataire 30. Dans un autre exemple de réalisation, le nœud DHT peut également être paramétré pour n'envoyer une mise à jour de la table d'identification que lors d'une évolution de celle-ci. Par exemple, une telle évolution de la table peut être nécessaire lorsqu'un nœud DHT devient hors service. Dans ce cas le protocole DHT utilisé est adapté pour recalculer la table DHT à partir des nœuds encore actifs.
La figure 3 représente le système selon l'invention, et plus précisément les échanges entre les entités du système, dans un second cas de figure. Ce second cas de figure correspond au cas où le nœud DHT 201 responsable du traitement de la requête req envoyée par le client 10 ne détient pas encore la donnée en cache, le nœud DHT 201 est adapté pour obtenir la donnée à envoyer en réponse auprès d'un serveur résolveur 40. A cet effet, le nœud DHT 201 comprend des moyens d'interrogation (non représentés sur la figure 3) du serveur résolveur 40. Le nœud DHT 201 transmet la requête req au serveur résolveur 40 qui est apte à effectuer une résolution DNS en interrogeant un serveur autoritaire DNS (non représenté sur la figure 3) à travers un réseau Internet 50. Le nœud 201 comprend également des moyens pour recevoir une réponse resp du serveur résolveur 40, en l'espèce la réponse à la requête req, et pour la mémoriser dans sa mémoire cache. Dans cet exemple de réalisation, le serveur résolveur 40 est adapté pour envoyer la réponse resp directement au client qui a émis la requête. Avantageusement, dans ce mode de réalisation, la réponse n'est pas envoyée par le nœud DHT au client, mais directement par le résolveur 40 au client. Ainsi, le temps de réponse est optimisé. Dans un cas particulier où la requête req est une requête DNSSEC, alors le serveur résolveur 40 est adapté pour recevoir outre la donnée réponse à la requête, une signature de ladite donnée. Il est adapté également pour vérifier ladite signature.
Dans les exemples d'architecture décrits en relation avec les figures 2 et 3 et dédiées à un service de résolution DNS, on estime que le nombre de nœuds du réseau P2P est fini et inférieur à une valeur prédéterminée, par exemple 300, et que ces nœuds sont opérés par un même opérateur. Le fait que tous les nœuds du réseau P2P soient opérés par le même opérateur facilite la communication entre nœuds et la gestion des nœuds. En outre, la valeur prédéterminée, considérée comme correspondant à un petit nombre de nœuds, permet à chaque nœud d'avoir connaissance de tous les autres nœuds, et conformément à la technologie DHT, permet à l'ensemble des nœuds du réseau de partager une même table d'identification. Gérer une seule table d'identification pour l'ensemble des nœuds du réseau P2P facilite l'exportation de la table vers le serveur mandataire et l'extemalisation de la fonction de routage. En outre, cela optimise le routage des requêtes des clients puisqu'un nœud responsable du traitement d'une requête est immédiatement identifié par consultation de la table. Cela peut ne pas être le cas lorsqu'un réseau P2P est constitué de plusieurs milliers de nœuds. En effet, dans ce cas, plusieurs tables DHT peuvent être nécessaires pour stocker l'ensemble des informations réparties sur les nœuds du réseau P2P et trouver une information parmi ces nœuds peut nécessiter plusieurs bonds successifs d'un nœud à un autre.
Les étapes d'un procédé de traitement d'une requête selon un mode de réalisation particulier de l'invention vont maintenant être décrites en relation avec la figure 4. Au préalable, on notera que le client 10 est paramétré pour que les requêtes qu'il émet soient dirigées vers le serveur mandataire 30.
Dans une étape initiale EO, le serveur mandataire 30 de la figure 2 reçoit du client 10 une requête req de résolution DNS. Dans une étape E1 d'identification d'un nœud, le serveur mandataire 30 consulte la table d'identification 200 qu'il mémorise afin d'identifier le nœud DHT responsable du traitement de la requête req. Puis, dans une étape suivante E2 de retransmission, le serveur mandataire 30 retransmet la requête req au nœud DHT identifié comme étant responsable du traitement de la requête, par exemple le nœud 201 de la figure 2.
Dans une étape E'3, le nœud 201 reçoit la requête req du serveur mandataire 30.
Dans une étape E'4 de traitement de la requête, le nœud 201 responsable du traitement de la requête recherche la donnée à envoyer en réponse à la requête dans sa mémoire cache.
Dans le cas où le nœud 201 détient la donnée en cache, il envoie directement au client 10 selon la figure 2, la donnée dans un message resp.
Dans le cas où le nœud 201 ne possède pas la donnée en cache, alors dans une étape non représentée sur la figure 4, il envoie la requête req vers le serveur résolveur 40 selon la figure 3 adapté pour effectuer une résolution DNS afin d'obtenir la réponse à la requête. A cette fin, le serveur résolveur 40 émet la requête req auprès d'un serveur autoritaire (non représenté) de l'Internet 50 selon la figure 3. Le serveur résolveur 40 qui a obtenu du serveur autoritaire la donnée en réponse à la requête req, transmet celle-ci, d'une part au noeud 201 qui la stocke dans sa mémoire cache, et d'autre part directement au client en réponse à la requête req. Dans le cas du système DNSSEC, le serveur résolveur reçoit du serveur autoritaire outre la donnée, une signature de la donnée permettant de vérifier l'intégrité de la donnée. Le serveur résolveur est adapté également pour vérifier la signature de la donnée. Les modules 301 , 302, 303 et 304 du serveur mandataire 30 selon la figure 2, ou la figure 3, sont agencés pour mettre en œuvre celles des étapes précédemment décrites du procédé de traitement d'une requête d'un client qui sont mises en œuvre par le serveur mandataire 30. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé de traitement d'une requête d'un client par le serveur mandataire. L'invention concerne donc aussi :
- un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de traitement d'une requête d'un client tel que décrit précédemment lorsque ce programme est exécuté par un processeur ;
- un support d'enregistrement lisible par un serveur mandataire sur lequel est enregistré le programme d'ordinateur décrit ci-dessus.
Les modules logiciels peuvent être stockés dans, ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal, ou un réseau de télécommunication.
L'invention est décrite ici dans le cas du traitement de requêtes DNS. L'invention n'est bien sûr pas limitée au traitement de requêtes DNS et peut s'appliquer à tout protocole basé sur l'envoi de requêtes pour obtenir une donnée.

Claims

REVENDICATIONS
1. Système de traitement d'une requête émise par un client pour obtenir une donnée, comprenant : - une pluralité de nœuds (201 , 202, 203, 204, 205) organisés en réseau
P2P, adaptés pour stocker un ensemble de données réparties dans les différents noeuds et mémorisant une table d'identification (200) adaptée pour identifier, celui parmi la pluralité de nœuds qui est apte à fournir la donnée en réponse à la requête, caractérisé en ce qu'il comprend :
- un serveur mandataire (30) mémorisant ladite table et auquel la requête est destinée à être adressée, ledit serveur étant adapté pour, suite à la réception de la requête, uniquement :
- identifier, à partir de la table, le nœud apte à fournir la donnée en réponse à la requête, et
- retransmettre la requête au nœud identifié.
2. système selon la revendication 1 , dans lequel le nœud auquel la requête est retransmise est adapté pour envoyer la donnée directement au client.
3. Système selon la revendication 1 , comprenant un serveur résolveur, apte à recevoir la requête du nœud lorsque la donnée en réponse n'est pas stockée sur ledit nœud, à effectuer une résolution auprès d'un serveur autoritaire de l'Internet pour obtenir la donnée, et à envoyer la donnée directement au client.
4. Système selon la revendication 1 , dans lequel les nœuds sont des nœuds DNS caches et la requête est une requête de résolution de nom de domaine.
5. Système selon la revendication 1 , dans lequel la table est une table DHT.
6. Réseau comportant le système selon la revendication 1 et une pluralité de terminaux clients, lesdits terminaux étant configurés pour envoyer des requêtes pour obtenir une donnée exclusivement au serveur mandataire.
7. Terminal pour le réseau selon la revendication 6 configuré pour envoyer des requêtes pour obtenir une donnée exclusivement au serveur mandataire.
8. Procédé de traitement d'une requête émise par un client pour obtenir une donnée, un ensemble de données étant réparties dans une pluralité de nœuds d'un réseau P2P mémorisant une table d'identification adaptée pour identifier, celui parmi la pluralité de nœuds qui est apte à fournir la donnée en réponse à la requête, caractérisé en ce qu'il comprend :
- une étape (EO) de réception de la requête du client par un serveur mandataire mémorisant ladite table, - une étape (E 1 ) d'identification à partir de la table du nœud apte à fournir la donnée, et
- une étape (E2) de retransmission de la requête au nœud identifié.
9. Serveur mandataire (30) comprenant : - des moyens (301 ) de réception d'une requête émise par un client pour obtenir une donnée,
- des moyens (302) de mémorisation d'une table d'identification (200) adaptée pour identifier, parmi une pluralité de nœuds organisés en réseau P2P, lesdits nœuds étant adaptés pour stocker un ensemble de données réparties dans les différents nœuds, celui parmi la pluralité de nœuds qui est apte à fournir la donnée en réponse à la requête, - des moyens (303) d'identification, adaptés pour identifier à partir de la table le nœud apte à fournir la donnée, et
- des moyens (304) de transmission, adaptés pour retransmettre la requête au nœud identifié.
10. Programme d'ordinateur sur un support de données et chargeable dans la mémoire interne d'un serveur, le programme comprenant des portions de code pour l'exécution des étapes du procédé selon la revendication 8, lorsque le programme est exécuté sur ledit dispositif client.
11. Support de données sur lequel est enregistré le programme d'ordinateur selon la revendication 10.
PCT/FR2009/052713 2008-12-30 2009-12-29 Procède de traitement de requêtes émises par un client Ceased WO2010076536A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0859119 2008-12-30
FR0859119 2008-12-30

Publications (2)

Publication Number Publication Date
WO2010076536A2 true WO2010076536A2 (fr) 2010-07-08
WO2010076536A3 WO2010076536A3 (fr) 2010-10-21

Family

ID=41077568

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/052713 Ceased WO2010076536A2 (fr) 2008-12-30 2009-12-29 Procède de traitement de requêtes émises par un client

Country Status (1)

Country Link
WO (1) WO2010076536A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011144175A1 (fr) * 2011-01-13 2011-11-24 华为技术有限公司 Procédé de pré-lecture de données, nœud et système pour système de mémoire à table de hachage distribuée (dht)
CN105450703A (zh) * 2014-08-28 2016-03-30 杭州迪普科技有限公司 一种数据缓存方法和装置

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005333374A (ja) * 2004-05-19 2005-12-02 Toshiba Corp ネットワーク検索システム、情報検索方法、ブリッジ装置及びプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011144175A1 (fr) * 2011-01-13 2011-11-24 华为技术有限公司 Procédé de pré-lecture de données, nœud et système pour système de mémoire à table de hachage distribuée (dht)
US8738861B2 (en) 2011-01-13 2014-05-27 Huawei Technologies Co., Ltd. Data prefetching method for distributed hash table DHT storage system, node, and system
EP3131265A1 (fr) * 2011-01-13 2017-02-15 Huawei Technologies Co. Ltd. Procédé de préextraction de données pour système de stockage dans une table de hachage répartie dht, noeud et système
CN105450703A (zh) * 2014-08-28 2016-03-30 杭州迪普科技有限公司 一种数据缓存方法和装置

Also Published As

Publication number Publication date
WO2010076536A3 (fr) 2010-10-21

Similar Documents

Publication Publication Date Title
EP2000929B1 (fr) Utilisation d'un arbre de hachage à préfixes (PHT) pour la localisation des services au sein d'un réseau de communication poste-à-poste
EP2526670B1 (fr) Procede et systeme de prevention d'empoisonnement de caches dns
WO2006037865A1 (fr) Procede et systeme de resolution dns distribuee
FR3100676A1 (fr) Système de gestion de noms de domaine basé sur contrat intelligent
FR2855691A1 (fr) Securisation de la distribution de documents numeriques dans un reseau pair a pair
EP2783500A1 (fr) Procédé de traitement d'une requête dans un réseau de communication centré sur les informations
WO2007074286A1 (fr) Serveur et procede pour gerer des requetes dnssec
FR2870022A1 (fr) Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair
WO2015011296A2 (fr) Procédé de traitement de données de géolocalisation
EP2695363B1 (fr) Technique de communication entre des reseaux de distribution de contenus numeriques
FR2912023A1 (fr) Architecture ims utilisant une table de hachage distribuee
WO2008059150A2 (fr) Deploiement de base dnssec
WO1996018959A1 (fr) Procede d'echange d'informations en mode client/serveur, entre stations reliees par un reseau de communication
WO2010076536A2 (fr) Procède de traitement de requêtes émises par un client
EP3568989A1 (fr) Procédés et dispositifs de vérification de la validité d'une délégation de diffusion de contenus chiffrés
WO2018115647A1 (fr) Validation de livraison de contenu et de verification d'une delegation de livraison d'un contenu
EP3900306B1 (fr) Procédé de détermination d'une chaîne de délégation associée à une résolution d'un nom de domaine dans un réseau de communication
WO2023083772A1 (fr) Procédés de contrôle et de transmission, et entités configurées pour mettre en œuvre ces procédés
WO2020128238A1 (fr) Procédé d'acquisition d'une chaîne de délégation relative à la résolution d'un identifiant de nom de domaine dans un réseau de communication
EP3632089B1 (fr) Optimisation de la fréquence de rafraîchissement d'un enregistrement dns
CA2433216A1 (fr) Serveur d'annuaire reparti
WO2009056743A2 (fr) Dispositif et procede de supervision d'equipements source
WO2006016009A1 (fr) Procede et dispositif de traitement d’une requete de traduction d’un nom de domaine
FR2788398A1 (fr) Interfonctionnement de caches cooperants et caches repartis
FR3024315A1 (fr) Systeme et procede de mise a disposition de fichiers informatiques.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09805799

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09805799

Country of ref document: EP

Kind code of ref document: A2