WO2007138228A2

WO2007138228A2 - Method, device and naming system, method and terminal for accessing a resource, method for responding to a query and resolving server

Info

Publication number: WO2007138228A2
Application number: PCT/FR2007/051347
Authority: WO
Inventors: Daniel Migault; Loïc HOUSSIER; Philippe Fouquart
Original assignee: France Telecom
Priority date: 2006-05-31
Filing date: 2007-05-29
Publication date: 2007-12-06
Also published as: WO2007138228A3

Abstract

The method for accessing an element having an identifier comprises: at least one querying step

Description

METHOD, APPARATUS AND SYSTEM FOR NAMING, PROCESS AND TERMINAL FOR ACCESSING A RESOURCE, METHOD OF RESPONSE TO AN INTERROGATION AND RESOLUTION SERVER

The present invention relates to a method and system for naming resources on a computer network, a device and method for accessing a resource on a computer network, and a method and a device for responding to a query. It applies, in particular, to allow access, on the Internet, to data not referenced by the DNS domain name naming system. Computer systems connected to the Internet communicate with each other using an IP address ("internet protocol" acronym for internet protocol), such as "10.192.123.234", for example. The DNS ("Domain Name System") system is a naming system, that is to say associating an alphanumeric identifier with a hierarchical IP address ₁ . The purpose of this naming architecture is to make it possible to establish a link between an identifier, here a domain name, for example www.wanadoo.fr (Wanadoo is a registered trademark), and an IP address, This system has been designed to give the various computer systems accessible on the Internet "humanly understandable" names. Indeed, it is easier to remember "www.wanadoo.fr" than an IP address. It is, in a way, a global directory that matches a name and a number. Subsequently, this architecture is generalized and is used to link a domain name and information different from a site. The DNS system is therefore generally considered as a hierarchical architecture for linking a domain name and connectivity information.

By "root domain" is meant the root common to all domain names. It is noted "." This root has a limited number of subdomains called higher level domains, "top surveyed! domain "," TLD ". There are three categories of TLDs. The first contains TLDs that designate country names (eg "uk", "jp"). They are called Country Code TLDs (ccTLDs). The second is a TLD reserved for technical experimentation, named ".arpa". Finally the other TLDs (for example, ".com", ".Org", ".edu") are called "generic TLDs" or generic top-level domains (gTLDs).

The domain names are distributed, from the root, in TLD, This scheme is reproduced iteratively from each TLD until it reaches the leaf of the tree. This prioritization allows each entity with a domain name to be universally listed and to administer its domain hierarchically and independently.

With regard to the organization of domain name resolution servers, the hierarchical structure is subdivided into domains and subdomains allowing the establishment of a distributed and hierarchical service. At the naming structure level, name servers each manage their domain and redirect clients to the subdomains to which management is delegated. Thus, taking over the domain name www.opera-de-paris.fr, the root or root domain does not know the answer directly, but knows the references of the server managing the ".fr" subdomain. It redirects the request to this server and so on until the complete resolution of the name.

We distinguish the servers actually hosting the DNS data servers that obtained the data during a previous query. The servers actually hosting the data of a zone are called the "primary" servers. DNS servers that have the response to a request because they have already issued this request and keep the response are called "cache" servers.

At the data level, a validity period is associated with each DNS data. As long as the validity date has not expired, the data remains in the network thanks to the presence of caches. Caches are files that contain data that has already been the subject of DNS queries. They are kept as long as the expiry date has not expired. A client issuing a request to a cache can receive the response from the cache, which can avoid querying DNS servers.

Figure 1 illustrates the operation of DNS within the network, in the case of a recursive resolution. In the illustrated example, a user terminator 110 wishes to know the IP address of the Web server www.orange.fr (Orange is a registered trademark), it first sends a request 101 to a local resolution server 115 (in English). "Local resolver") also called server "recursive cache", "Cache" because it retains the results it receives, during their validity and "recursive" because it performs a succession of queries on behalf of the user terminal. The local resolution server 115 then sends a request 102 to the master server 120 of the domain ". And receives, in return, a message 103 indicating an IP address of the master server of the domain ", fr" 125. The local resolution server 115 then sends a request 104 to the server 125 and receives, in return, a message 105 indicating an IP address of the server of the domain "orange.fr" 130. The local resolution server 115 then sends a request 106 to the server 130 and receives, in return, a message 107 indicating an address IP server 135 with the contents of the domain www.orange.fr 135. The terminal 110 can then use this IP address to access the domain "www.orange.fr".

Thus, the domain name "www.orange.fr. "Means a domain name on four levels: -". Is the root domain,

- "fr" refers to the TLD, specifically the ccTLD

- "orange" means the domain managed by Orange (registered trademark) and

- "WWW" is the name given to the web server. The domain name is the sole entry of the database, and the names must meet certain rules, especially ifs must follow a hierarchy. Thus "www" is a subdomain of "orange" which itself is a subdomain of "fr" which itself is a subdomain of "root" or "."

However, while the DNS architecture is suitable for a hierarchical naming structure such as the one that governs traditional domain names on the Internet, the DNS is, on the other hand, not designed to respond to a naming structure without hierarchy, or still called "flat" naming. For example, the DNS system can not handle the case where each machine or entity in the network has an identifier without a structure, such as a random number. Indeed, it should have a zone file containing all the identifiers, which in the case of identifiers of a length, for example, of 12 bits, that is to say the same length as the IPv6 addresses, seems unrealistic because of the number of addresses considered. However, the use of non-hierarchical identifiers is develops because it allows to integrate features, such as security, directly into the naming system.

For example, based on the HiP protocol (acronym for "host identity protocol" for host identity protocol), the bit sequence designating the identifier is formed from the condensate or "hash" of a public key. This is called "cryptographic" identifiers. The use of such identifiers makes it possible to integrate functionalities such as secure attachment procedures, proof of membership, data relating to the confidentiality of information. HIP ₁ protocols and projects like "Ambient Network" assume that the identity of a node or any element accessible on the network is designated by its public key / key pair. private.

More generally, the use of a naming system without hierarchy facilitates automatic configurations within a network. Indeed if 234543267098765 and 039543266098705 are two binary identifiers written in decimal base, without apparent link, they can belong to two machines having no connection between them or, on the contrary, be associated with two very close nodes like two terminals belonging to one even under network.

The advantages found at the network level, in a naming system without hierarchy, especially with regard to the simplification of automatic configuration operations meet, at the level of the naming system, a new problem: How to manage the whole binary identifiers? Indeed, as explained above, it is not possible to set up a centralized database having all the possible identifiers.

The use of a non-hierarchical naming system in the DNS architecture is particularly complex since we have to deal with two different conceptions of naming systems, one non-hierarchical, the other centralized, the one oriented content (file or data), the other oriented connection information. The present invention proposes to allow the DNS structure to integrate at least one non-hierarchical namespace.

For this purpose, the present invention aims, in a first aspect, a method of accessing an element having an identifier, which comprises: at least one interrogation step of a name resolution server of a hierarchical naming system, responsible for a domain represented by said identifier, said interrogation comprising said identifier, a step of receiving a response from a said name resolution server, said response being representative of at least one server name different from said identifier and hierarchically at the same level as said identifier and

an interrogation step of a server having a said different name of said identifier.

Thanks to these arrangements, an element having an unknown identifier of the address resolution system, for example DNS, can be found via the server whose name is different from the identifier of the element, in particular when this another server is linked to a network comprising said element. The present invention thus aims to integrate two naming systems, hierarchical and non-hierarchical, so as to use, in the DNS system, identifiers having, in part, a non-hierarchical identifier specific to a domain.

The implementation of the present invention therefore has the following advantages:

on the one hand, the hierarchical naming system, for example DNS, is not encumbered by names associated with each accessible element and

- On the other hand, non-hierarchical naming systems do not have to manage elements outside the domain. According to particular characteristics, during the step of receiving a response, said response is representative of at least one server name which is, in the lexicographic order and in the memory of said name resolution server, immediately higher or immediately below said identifier. Thanks to these provisions, the access method benefits both from the advantages of the DNS system and from the advantages of the non-hierarchical naming systems, which allow, for example, the easy or fast addition or removal of files or nodes. . In fact, in non-hierarchical naming systems, the elements are managed by the servers having the closest identifier, it being understood that the notion of proximity depending on a distance function defined for the non-hierarchical naming system.

According to particular characteristics, during the step of receiving a response, said response is representative, on the one hand, of the fact that said identifier is unknown to said name resolution server and, on the other hand, of each said different name of said identifier.

With these provisions, the DNSSEC extension of the DNS naming system can be implemented to implement the present invention. According to particular features, the access method as succinctly set forth above further comprises a step of determining to obtain access to said element from a server with a name different from said identifier and , in the absence of obtaining said access to said element, an interrogation step of another server having a said name different from said identifier.

Thanks to these arrangements, if the access to the sought element can not be obtained from a server having a name which follows, in the lexicographic order, the identifier of the searched element, it is obtained from the from a server with a name that precedes, in lexicographic order, the combined identifier.

According to particular characteristics, during each interrogation step, said identifier is a so-called "combined" identifier representative, on the one hand, of the name of said domain and, on the other hand, of an element identifier on a said non-hierarchical network comprising said server having said name different from said identifier and said element.

Thanks to these provisions, the DNS naming system can use the domain name concerned and the non-hierarchical network can then use ('element identifier.

According to particular features, said non-hierarchical network implements a non-hierarchical naming system in which the identifiers are managed by juxtaposed intervals.

Thanks to these provisions, one can find the manager of the searched element without having to search all the elements of the non-hierarchical network. According to particular features, the method as briefly described above comprises, iteratively, a determination step, by a server having a name different from said identifier, if it is responsible for said element and - if yes, a step of providing access to said element and

- if not, a step of selecting, by said server that has a different name identifier of said _"another name server of the non-hierarchical network different from said identifier and closer to said identifier as the identifier of the server performing said determining step. Thanks to these provisions, progressively converges towards the manager of the desired element.

According to particular features, during the iterative steps, a table is implemented mapping each element identifier of said non-hierarchical network and a server name of said non-hierarchical network. According to particular features, said table contains identifiers of elements that are representative of results of a hash function of at least a part of the name and / or content of said elements.

According to particular features, during the iterative steps, a hashing system is implemented distributed on the servers of the non-hierarchical network.

With each of these features, the present invention can be implemented with hash-table naming systems, referred to as DHTs.

According to particular features, the method as briefly described above comprises a step of referencing, with a name resolution server of the hierarchical naming system, the server having the name different from said identifier, a representative name on the one hand , said domain and, on the other hand, a non-hierarchical identifier.

According to a second aspect, the present invention aims at a naming system which assigns, for at least one element, a combined identifier representative of, on the one hand, a name according to a hierarchical naming system and, on the other hand, to an element identifier of a non-hierarchical naming system, the identifier of the hierarchical naming system allowing access to a server and the identifier of the non-hierarchical naming system allowing access to the elements accessible to said server, by implementing the non-hierarchical naming system.

According to particular characteristics, the naming system assigns a combined identifier to a server whose non-hierarchical identifier is the last identifier of all the non-hierarchical identifiers.

According to particular features, the naming system as succinctly set forth above determines the identifier of a non-hierarchical naming system by hashing at least a part of the name and / or content of said element.

The advantages, aims and special features of this naming system being similar to those of the method of access to an element as succinctly explained above, they are not recalled here.

According to a third aspect, the present invention provides a method for naming an element of a non-hierarchical network on which the identifiers are managed by interval, which comprises a step of assigning, to said element, a hierarchical name of a domain having a server of said non-hierarchical network and a step of assigning, to said element, a name complement representing its identifier on the non-hierarchical network. According to particular features, the naming method as briefly described above also includes a step of updating a distributed table in which each element of the non-hierarchical network is put in relation with a responsible server identifier. said element.

According to particular features, the naming method as succinctly set forth above further comprises a step of referencing at least one server of said non-hierarchical network on at least one domain name resolution server.

In particular characteristics, the naming method as briefly described above includes a step of assigning a combined identifier to a server whose non-hierarchical identifier is the last identifier of the set of non-hierarchical identifiers.

The advantages, aims and special features of this naming process being similar to those of the access method to an element such as succinctly stated above, they are not recalled here.

According to a fourth aspect, the present invention aims at a method of response, by a server, to a name resolution interrogation comprising an identifier, which comprises: when said server keeps, in memory, an address corresponding to said identifier, a step of response during which said server provides said address and

when said server does not store, in memory, an address corresponding to said identifier, a response step during which said server provides a response representative of at least one server name different from said identifier and hierarchically at the same level as said identifier , without indicating that said name is different from said identifier.

According to particular characteristics, when said server does not store, in memory, an address corresponding to said identifier, during the response step, said response is representative of a server name which is, in the lexicographic order and in the memory of said server, immediately higher or immediately lower than said identifier.

Since the advantages, aims and particular characteristics of this response method are similar to those of the access method to an element as succinctly described above, they are not recalled here.

According to a fifth aspect, the present invention aims at an access terminal to an element having an identifier, which comprises:

an interrogation means adapted to interrogate at least one name resolution server of a hierarchical naming system, responsible for a domain represented by said identifier, said interrogation comprising said identifier and

means for receiving a response from a said name resolution server, said response being representative of at least one server name different from said identifier and hierarchically at the same level as said identifier,

said interrogation means being adapted to interrogate a server having a said name different from said identifier. According to particular features, the response reception means is adapted so that said response is representative, on the one hand, of the fact that said identifier is unknown to said name resolution server and, on the other hand, of each said name. different from said identifier. According to particular features, said interrogation means is adapted so that said identifier is a so-called "combined" identifier representative, on the one hand, of the name of said domain and, on the other hand, of an element identifier on a network which comprises said server having said name different from said identifier and said element According to particular characteristics, the interrogation means is adapted to determine whether an access to said element has been obtained from a said server having a name different from said identifier and, if not, to interrogate another server having a said different name of said identifier.

According to particular features, the interrogation means is adapted to implement an identifier of a non-hierarchical naming system in which the identifiers are managed at intervals.

The benefits, goals and special features of this termina! access to an element being similar to those of the method of access to an element as briefly described above, they are not recalled here. According to a sixth aspect, the present invention aims at a device for naming an element of a non-hierarchical network on which the identifiers are managed by interval, which comprises means for allocating, to said element, a hierarchical name of a domain having a server of said non-hierarchical network and means for allocating, to said element, a name complement representing its identifier on the non-hierarchical network,

According to particular features, the naming device as succinctly set forth above further comprises a device for updating a distributed table in which each element of the non-hierarchical network is put in relation with a responsible server identifier. said element. According to particular features, the naming device as succinctly set forth above further comprises means for referencing at least one server of said non-hierarchical network on at least one domain name resolution server. According to particular features, the naming device as succinctly set forth above further comprises means for referencing a server of said non-hierarchical network having the last of the identifiers used on the non-hierarchical network, on at least one domain name resolution server.

The advantages, aims and special features of this naming device being similar to those of the naming process as succinctly described above, they are not recalled here.

According to a seventh aspect, the present invention aims at a name resolution server comprising an identifier comprising a memory in which identifiers are associated with addresses in response to a query, characterized in that it comprises an adapted response means

when said memory retains an address corresponding to said identifier, to provide a response representative of said address and when said memory does not retain an address corresponding to said identifier, to provide a response representative of at least one server name different from said identifier and hierarchically at the same level as said identifier, without indicating that said name is different from said identifier. The advantages, goals and special features of this server being similar to those of the interrogation response method as succinctly set forth above, they are not recalled here.

Due to the characteristics of each of the aspects of the present invention, the DNS system is not encumbered by addresses or names of elements accessible by nodes of a non-hierarchical network but only manages the addresses of the nodes having a DNS name. . In addition, the advantages of non-hierarchical naming systems, which allow, for example, the easy or quick addition or removal of elements, data, files or nodes, are advantages of each of the aspects of the present invention. The present invention also relates to a computer program loadable in a computer system, said program containing instructions for implementing the method of access method to an element having an identifier as succinctly explained above, when this program is loaded and executed by a computer system.

The present invention also relates to a computer program loadable in a computer system, said program containing instructions for implementing the method of naming method of an element as briefly described above, when this program is loaded and executed by a computer system.

The present invention also provides a computer program loadable in a computer system, said program containing instructions for implementing the method of response to a query as succinctly explained above, when this program is loaded and executed by a computer system.

Since the benefits, goals, and features of these computer programs are similar to those of the methods they implement, as succinctly discussed above, they are not repeated here. The various aspects of the present invention and their particular features are intended to be combined to combine the advantages of these features.

Other advantages, aims and features of the present invention will emerge from the description which follows, made for an explanatory and non-limiting purpose with reference to the appended drawings, in which:

FIG. 1 represents, schematically, exchanges of requests and responses for obtaining an IP address in the DNS system,

FIG. 2 schematically represents a network implementing a DHT naming system; FIG. 3 schematically represents a first embodiment of a naming system according to the present invention;

FIG. 4 represents, schematically, a second embodiment of a naming system according to the present invention,

FIG. 5 represents, schematically, exchanges of requests and responses for the implementation of the present invention,

FIGS. 6A to 6C represent, respectively, logigrams of steps implemented for additions and withdrawals of resources accessible on a global computer network and to respond to a request,

FIG. 7 represents, in the form of a logic diagram, steps implemented by a computer system attempting to access an element of a non-hierarchical network, by implementing a first embodiment of the access method. to an element object of the present invention and

FIG. 8 represents, in the form of a logic diagram, steps implemented by a computer system attempting to access an element of a non-hierarchical network, by implementing a second embodiment of the access method. to an object of the present invention. Before describing particular embodiments of the present invention, with reference to the figures, given below, elements useful for its understanding. Throughout the description, the terms d ^! "Identifier" and "name" are used interchangeably and "keys" are particular identifiers.

Throughout the description, the terms "node" or "server" are used interchangeably.

Throughout the description, the terms d ^! "Element" or "resources" are used interchangeably.

According to the present invention, in order to be able to access the resources associated with these identifiers of a non-hierarchical network, from a computer system outside the non-hierarchical network, in accordance with the present invention, the identifier of these resources is associated with the non-hierarchical network, connectivity information, in the form of a hierarchical domain name, at least one node of the non-hierarchical network belonging to said domain.

Thanks to this naming system, the combined name of an element that is to be accessed from outside the non-hierarchical network can be processed, first, by the DNS domain name resolution servers, in a manner known in the art. itself, with the exception of the last DNS server implemented, as explained below, then the non-hierarchical identifier of the element can be processed by the non-hierarchical network in a manner known per se. For example, to integrate your cryptographic credentials into a DNS domain, we define a set of Chord nodes that make up a Chord naming architecture for that domain. Thus, for example, a domain name such as "wanadoo.fr" can define a set of elements (for example, servers, data or files) Chord, for example, whose combined names are formed from the addition of a cryptographic identifier with a domain name, for example "201.wanadoo.fr", "207.wanadoo.fr", "203.wanadoo.fr", etc. These combined names thus constitute the naming system object of the present invention, which makes it possible to establish a link between a cryptographic identifier and a connectivity information, at least one of the nodes having a combined name being known from the DNS system and giving thus access to other Chord resources.

Among the non-hierarchical naming methods, the present invention preferably implements those called "DHT" (acronym for "distributed hash tables" for condensate tables, or hashes, distributed) which classify, without hierarchy, the data accessible and distributed on the network to access. Various DHT protocols have been developed in order to be able to add data on the network and to find the data.

Among these, the mechanism named Chord, a non-hierarchical naming system, aims to allow a classification of keys. In the Chord naming system, each node in the network has an identifier. The identifier of the files or data to be referenced is generated by a hash function that produces a condensate. Thus Chord is a system adapted to manage a set of files. The integration of DNS and DHT naming systems object of the present invention is carried out in the context of the use of identifiers ordered on the non-hierarchical network, that is to say having, between them, a relationship of order, for example of cryptographic identifiers in the HIP protocol, each node being represented by an identifier formed from the condensate, or hash, of a public key associated with this node.

A table of names is a structure that associates a name with each element accessible by this structure, the set of names having a relation of order, in the mathematical sense of the term. A hash table is a table that associates with an element an identifier consisting of a cryptographic key obtained by a hash function, for example implemented during an electronic signature, of at least part of the name and / or the content of this element. A distributed table is a table that is divided, in pieces, between different nodes of a network. In a non-hierarchical structure, each node is responsible for some of the associations between names and elements, typically of a range of names. The part of the distributed table which he keeps therefore contains, at least, the name-element associations for which he is responsible.

Each node is associated with a Chord identifier that indicates the range of names it has been responsible for. For example, in the Chord system, the node's identifier is a name that follows the last element name for which it is responsible. Depending on the nature of the application, the names and elements represent different things. In the case of a file exchange application, a name is a file identifier, and the corresponding element is the list of IP addresses of the nodes that own the file, that is to say, keeps it in memory .

In a DHT distributed hash table, finding an element first returns to find the node responsible for its key, then, in a second step, to query it on the value of the corresponding element, the term "Value" can mean both the content of the element sought, for example data, and the IP address where this content is accessible. The node can thus have the data, or include an indirection, and indicate where to download the data, for example. Likewise, publishing an item is like finding the node responsible for its key before sending it the key-item association.

In order for the search of an element by one node to be effective, the nodes form a structured network where each node has partial knowledge of the other nodes. For this purpose, it is possible to implement an index table that associates with certain elements of the network, the nodes that are responsible for it. Preferentially, each node of the network has more information on the elements whose names are closest to the name of this node than on the elements whose names are more distant, the notion of distance being here that which is defined by a topoiogy associated with the naming system. Different topologies can be used. The topologies can be adopted _"for example, be the hypercube, torus or de Bruijn graph. These different topologies define, among other things, the routing algorithms to look for the node responsible for a key.

A distributed hash table (or DHT) associates an element with a cryptographic key, in a distributed table where the key-element associations are distributed over the nodes of the network. We thus access each element of the table via its cryptographic key. The two elementary operations performed on a hash table are the creation of an association between an element and a cryptographic key, by hashing its contents, and the recovery of an element by using its key, as exposed in relation to the figure 2.

Figure 2 is a representation of a space of node responsibilities in a DHT ₁ system here the Chord system. In FIG. 2, the nodes 200, 203, 206, 210 and 211 are represented by black disks and the elements 201, 202, 204, 205, 207, 208, 209 and 211 to 215 by black squares. The topoiogy used in Chord is hypercube. Each node has a unique identifier belonging to the interval [0, 2 ^b -1] which defines its position in the represented ring, with the value of the number "b" sufficiently high that the interval can accommodate all the nodes of the node. Chord system. Typically, "b" = 64 or 128 or even 256. In FIG. 2, "b" is equal to 4. To constitute the numerical references used in FIG. 2, 200 has been added to the Chord identifier of each node. Thus, for example, the reference 203 designates the node whose Chord identifier is "3" and the reference 207 designates the element whose Chord identifier is "7".

The identifier of the node defines the interval of the element keys for which the node is responsible, this key space being delimited by the identifier of the node and by that of the node which has the immediately lower identifier. Thus, the node 210 is responsible for the elements whose identifiers go from 207 to 210. The neighboring nodes are filled in such a way that each node has more knowledge of the nodes having an identifier close to its own than nodes having an identifier remote from its . In the distributed hash table, each identifier node "i" knows, for each value i + 2 ^k (modulo 2 ^b ), with "k" in the interval [O, b-1], the node having the identifier immediately greater than i + 2 ^k , that is to say the node responsible for the element having as identifier i + 2 ^k . These node identifiers constitute the index table of the node in question. For example, the node 200, identifier "0" has the following index table:

1 3

2 3 4 6 8 10 and the node 210, identifier "10" has the following table of indes:

1 11

2 0 4 0 8 3

To find the node responsible for an identifier "j", that is to say the node whose identifier is immediately greater than or equal to "j", a node looks in its index table for the identifier of the node having the identifier immediately below "j". it sends a request to this node having, in its index table, the identifier immediately below "j" and the latter repeats these steps until the last node interrogated has, in its index table , as an immediate successor, that is to say in the first line of its index tabie, an identifier node "m" greater than "j", In this case, the searched node is the identifier node " m "and, to access the identifier element" j ", a request is made to the identifier node" m ", which can retain the element" j "in memory or know, by its table of distributed hash, which node stores the desired "j" element in memory.

For example, if the node 203 searches for the identifier of the node responsible for the element 215, it interrogates the node 211 and the latter, having as immediate successor the node 200, determines that the node 200 is responsible for the element 215 .

The manner in which the intervals are chosen means that the search is done in a dichotomous manner and has a complexity of log (n), where "n" is the number of nodes connected to the system.

It may also be noted that a node may be referenced by several nodes which have pointers in their index table which designate it, which improves the tolerance to faults or failures, for example in the event of disconnection of nodes.

To join the DHT topology, a node fills its index table and reports to nodes that might have it in their index table. It must also recover the key-element associations for which it becomes responsible. Conversely, before leaving, a node must signal its departure to the nodes that have it in their index table and send the associations to the node that has the identifier immediately. superior to his own and who will become responsible for these associations.

In order to implement the present invention, in response to a request identifying a searched element, by its combined name, the domain name server responsible for the domain comprising the elements of a non-hierarchical network and which does not recognize the desired identifier transmits to the minus the name of the "closest" node of the identifier in question.

The client, who seeks access to the element in question can then use the name of this node "closest" to the identifier in question and _" thanks to the structure of the non-hierarchical network, thus accesses a node of the network non-hierarchical who directs it, directly or indirectly, towards the desired element.

Two main embodiments of the present invention are represented in the figures: a global DHT-chord namespace and

- a DHT-chord namespace at the private level, that is to say for a specific domain, such as "wanadoo.fr".

In the first particular embodiment, illustrated in FIG. 3, the invention includes the designation of a ".chord" domain name for example, which will be considered as a TLD ("Top Survey! higher level) in the DNS architecture, domain where all the identifiers of the nodes that manage a key interval are arranged in a non-hierarchical naming system. In this first embodiment, it is thus provided a specific TLD, dedicated to the hosting of DHT-chord type data. This space is preferentially managed, as is the current DNS, by a global consortium. The nodes hosting the data are managed as the different "root" servers by this international consortium. In the second embodiment, illustrated in FIG. 4, all the nodes hosting the binary identifiers are managed by the organization to which this domain name belongs. This corresponds to the case where an entity decides to administer its own zone.

It is observed that in Figure 3, the public and global domain intended to become a TLD illustrated in Figure 3 corresponds, first, to the Chord.arpa domain.

Indeed, it is the function of the domain ".arpa" to host, at least in a first implementation, this kind of extension to the global DNS architecture.

In Figure 4, the reserved area for the binary identifiers of

University of Berkeley is represented. In both cases, within a domain, a set of nodes defines the DHT-chord architecture belonging to that domain. Each node of the non-hierarchical network referenced in the DNS system is defined by a new type of DNS record called "ChordNODE".

Once the domain is identified by this new type of record, we define the different nodes of the DHT-Chord architecture. These nodes have the following information:

- the domain name to which they are attached (in the cases shown in Figure 3, this is the domain "Chord.arpa" and, in Figure 4, the domain

"Berkeley.edu") - the "locators" attached to it (in the case represented, it is an IP address).

Figure 2 shows the chord DHT structure implemented at Berkeley.

This architecture has three nodes of type ChordNODE, whose characteristics are as follows: - Node 0:

- non-hierarchical identifier: 0

- address \ P: 192.234.98.98

- domain name: chord.berkeley.edu - combined identifier: O. chord.berkeley.edu

- Node 1:

- non-hierarchical identifier: 1

- IP address: 192.234.98.99 - domain name: chord.berkeley.edu

- combined identifier: 1.chord.berkeley.edu

- Node 3:

- non-hierarchical identifier: 3

- IP address: 192.234.98.100 - domain name: chord.berkeley.edu

- combined identifier: 3.chord. berkeley.edu

The implementation, at the level of the DNS file, is as follows (the data in right characters are those due to the use of the DNS protocol, the implementation data of Ia presents the invention being in italics): $ ORIGIN chord. berkeley.edu. $ TTL 8640

@ IN SOA ns bogdan \ .marinoiu.rdirancetelecom.com. (2005112301; YY / MM / DD / version 200; update delay 100; retry

604800; give up 100)

IN NS ns ns IN A 10.193.171.53

0 IN ChordNODE "192.234.98.98" "chord.berkeiey.edu."

1 IN ChordNODE "192.234.98.99" "chord.berkeiey.edu." 3 IN ChordNODE "192.234.98.100" "chord.berkeley.edu."

It is observed that the fields "SOA" and "ns" are fields of the DNS protocol. Thus, if we look for the information corresponding to the identifier "2" of the Chord network, which is not referenced in the DNS system, we first interrogate the node whose identifier is "3" on this network, which is referenced in the DNS system. Indeed, the identifiers of the elements are hosted by the node that follows, that is to say that it is the node that follows who has the responsibility.

Also, in embodiments of the present invention adapted to non-hierarchical networks of the "Chord" type, the resolution of the identifier "2" uses mechanisms making it possible to give the sender of the request access to the node closer to the non-hierarchical network that is referenced in the DNS system and follows the desired identifier.

For this purpose, in particular embodiments of the present invention, a property of the DNSSEC extension is used. Indeed, the NSEC DNS fields make it possible to give the sender a request on a domain name. not belonging to the zone (in this case the node whose identifier is "2") the closest node identifier and which follows the searched identifier which has not been found.

A DNSSEC file is obtained from a DNS file. For didactic purposes, the secure DNS extension called "DNSSEC" is described below, however, it is observed that the implementation of the present invention does not require the use of the NSEC field of this protocol.

Described for the first time by the IETF standardization organization ("internet engineering task force" sigy for the engineering work force of the intemet) in the RFC document ("request for comments" sigie for comment request) 2535, this extension is now described in RFC 4033, RFC 4034, and RFC 4035. DNSSEC was primarily designed to authenticate the origin of DNS messages and ensure their integrity during transport.

To authenticate negative responses (for example, the requested name or record does not exist), the NSEC records (formerly named "NXT") have been added. They bind the records of a zone cyclically by indicating, for each name, which types of record are associated with it and what is the next name (in lexicographic order) located in the zone file, We obtain the certainty that there is no record corresponding to a request if the NSEC record is checked for the name which is, from the lexicographic point of view 'the closest predecessor of the name concerned by the request.

The "SOA" record specifies the primary server name of the zone, "dnssed", but without a suffix. The suffix, for example ".mabanquea.fr", is added to all the names that do not end with ". ". This record also gives the e-mail address (or "e-mail address") of the zone administrator as well as deadlines for updating the slave servers.

The "NS" record specifies a name server for the domain. "A" records give "IPv4" addresses for the name server and for a web server, or web server, that belongs to the domain.

The records of a NSEC type name indicate the following DNS name in the area, in lexicographic order, and the list of types of its records make cyclic closure of the area ("mabanquea.fr" to "dnssed .mabanquea.fr To www.mabanquea.fr to "mabanquea.fr").

Thus, in particular embodiments of the present invention, the DNSSEC file takes the following form, in which the implementation data of the present invention are in italics, the other data being due to the use of the DNS / DNSSEC protocol : dnssec_signzone version 9.3.1 $ ORIGIN chord.berkeley.edu @. 8640 IN SOA ns.berkeley.edu. bogdanlrnarinoiu.rd.francetelecom.com.

(

2005112301; serial 200; refresh (1 minute 40 seconds)

100; retry (3 minutes 20 seconds) 604800; expires (1 week) 100; minimum (1 minute 40 seconds)

) 8640 RRSIG SOA 52 864020060104100453 (

20051205100453 48254 chord.berkeley.edu

5Vl! FIUdNmJvVZfpiHKYbRW4LePhRIWAdopf gcizuuYZ + PFg6FtM9RU1AXυVUS7UYH189p8 ttyQMXAFm 1 CADeddJoNT3ZXLx9quxzCYC3g2 2ACvLbjmljlvexV4OMWb8VHUCcc45ubYjP8 8RQtOF3juNMCBW + OVXDwy15u / H4 =) 8640 NS ns.berkeiey.edu. 8640 RRSIG NS 52 8640 20060104100453 (

20051205100453 48254 chord.berkeley.edu, db2Tsfm / cnFyaSkHaYWlBon2r2HYtBrwQsYC BR2A300WuCk1ejMOP0464RkKDIKWJSz4JF6r OttW / TCwUy50yrXq + WMfZMjQ7GR5VTAs5UJQ b4WVOqfL YLxQ4sPaiorzolwWid 1 + Y + J8WUbdj nzj1hFPp Bx82dxJCdtyO6eAVAI =)

100 NSEC 0. chord.berkeley.edu. NS SOA RRSIG NSEC DNSKEY 100 RRSIG NSEC 5 2 100 20060104100453 (

20051205100453 48254 chord.berkeiey.edu. scYwzOQihvasXeXUX1u3QwWbnH / mzkvuOQdc

MpD + BJzn7LSHF28kbiuizdua3ukN18IVjqtC m4MhmaVvxJpBtXbxMoOQG6eE0Wf6lvV / Gsbd bh8DSfudtU2ZuU7V0bpkQRodlgidyhnPbAZ BGC3KWbBplz9TuDprmGWm6CυiJ8≈) 8640 DNSKEY 2563 5 (

AQPvG9Z4OwGpYryJeQ5oDGRJYc45hvLiLE99 MzLwJ3Coix / FtidVexBqHRC9Js + fg / UVWSm ue6VMIuEteShtEohlc418 / K9qAQcwyCS8ZNx scBKc1W1 $ w5RmCkCprGkltSυCUeP10SP / cPK yN / Z6 / qSgvXxA Vjh7IMauhVeltv2iw ==

); key id = 48254 8640 DNSKEY 2573 5 (

AQOzHiM1NL7E5fuA3hpddBdXcHq3deTPHkLK nt3N3QPRc8XrXJ6WgHp9dreqS8uvp8bF76sB pen / XP8bn9ybOJBz9 ++ wOScugKzlYbF6E / zE vGrKitky5iz1pZ + VsHwy78QKbDSMIslqT25T L8Sx2VthbWJF1lRLuuTAMo7sGnNERw≈ =); key id = 27075

8640 RRSlG DNSKEY 52864020060104100453 (

20051205100453 27075 chord.berkeley.edu. G063oIGAPTN0fUr4KK2xqAAiexfd9PTa1IU4 dl6NMrU8FfOhXKQemh / QGP + GCxa2bindz / lf RRYVICOWU 2BDA GPNHVFDoZDSLxJSPiHDWa TL h 7FpnJt0XQ44SFadA0 VtQZiOGFJgAasewfnK 9υhx + Q0HM60GXorQxS / RU8jlMB4 =) 8640 RRSlG DNSKEY 52864020060104100453 (2005120510045348254 chord.berkeley.edu. Θ5lYxOf / jJToz / tFa2wRt2NRZTOY02zoxwiq

7zoQhj2IR5IGHQkzvndqg54XmLldg8V + SwPf1 UqeX + G + wnuAθjLfGrqt2TkQSsVvZ3mVgJt + j EExuuWBFUxwgO7GDsM + WZvQ67HQbshυC2NkC UCGW0V6ddylEPbW2UVhyi6AyLQ =)

0.chord.berkeley.ec! U.8640 IN ChordNODE "192.234.98.98"

"Chord.berkeley.edu."

8640 RRSfG ChordNODE 5 3 8640 2Û060104100453 (2005120510045348254 chord.berkeley.edu.zjJsbRND8YziK26rYbABkYT07 + IC + gφvea

## EQU1 ##. ChordNODE RRSIG NSEC

100 RRSIG NSEC 5 3 10020060104100453 (

20051205100453 48254 chord.berkeley.edu. ] XLIkQJJUDz3me0n4L8is3M JIHxaCkkEh 10V ZSdlCLXx2A6Y7H0w0xKKJp + 1zdMlc4mBÛuZG 1 H8bdSaG6Do7R8s1 K5jOT8gOAuoGVho5PPob Z2WTLfRqDcYBAxr9hSL4GMi0FGYTq2V6h8zg AbWOyCcZm + 6hknQVTiKgf6nZTei =)

1.chord.berkeley.edu.8640 IN ChordNODE «192.234.98.99»

"Chord.berkeley.edu." 8640 RRSiG ChordNODE 5 3 8640 20060104100453

20051205100453 48254 chord.berkeley.edu. zjJsbRND8YziK26rYbABkYT07 + iC + gdjsvea

9oOjtL + NYFxE / ZVqdfhdlD2PaX2WoKaxOVq ljvvxllC2759C1 MG2WqzGFwf1 yyoNbcLtRNl qqq4l9kXm4Mgj + JHLEv6z2cJbZou [JU5e62l 7d6lU2MYg + KYsY + DQMq / XLv3gOA =) 100 NSEC 3.chord.berkeley.edu. ChordNODE RRSlG NSEC

100 RRSlG NSEC 5 3 100 20060104100453 (

20051205100453 48254 chord.berkeley.edu. jXLIkGJJUDz3me0n4L8is3MJlHxaCkkEh1OV ZSdiCLXx2A6Y7H0w0xKKJp + 1zdM! c4mB0uZG 1 H8bdSaG6Do7R8s1 K5jOT8gOAuoGVho5PPob

Z2WTLfRqDcYBAxr9hSL4GMi0FGYTq2V6h8zg AbWOyCcZm + 6hknQVTiKgf6nZTei =) 3.chord. berkeley.edu.8640 IN ChordNODE "192.234.98.100"

"Chord.berkeiey.edu." 8640 RRSIG ChordNODE 5 3 8640 20060104100453

20051205100453 48254 chhord.berkeley.edu. zjJsbRND8YziK26rYbABkYT07 + IC + gdjsvea 9oOjitL + NYFxE / ZVqdfhdlD2PaX2WoKaxOVq ljvvxIIC2759C1 MG2WqzGFwf1 yyoNbcLtRNl qqq4l9kXm4Mg] + JHLEv6z2cJbZoulJU5e62l

7d6IU2MYg + KYsY + DQMq / XLv3gOA =) 100 NSEC chord.berkeley.edu. ChordNODE RRSIG NSEC 100 RRSIG NSEC 5 3 100 20060104100453 (

20051205100453 48254 chord.berkeley.edu. jXLIkQJJUDz3me0n4L8is3MJIHxaCkkEh1OV ZSdlCLXx2AδY7H0w0xKKJp + 1zdMlc4mB0uZG 1 H8bdSaG6Do7R8s1 K5jOT8gOAuoGVho5PPob

Z2WTLfRqDcYBAxr9hSL4GMi0FGYTq2V6h8zg AbWOyCcZm + 6hknQVTiKgf6nZTel =)

A lighter version, without the values associated with the signature type fields, gives the following file:; dnssec_signzone version 9.3.1 $ ORIGIN chord.berkeley.edu

@, 8640 IN SOA ns.berkeley.edu. bogdanïmarinoiu.rd.francetelecom.com. (

2005112301; Serial

200; refresh (1 minute 40 seconds) 100; retry (3 minutes 20 seconds) 604800; expires (1 week) 100; minimum (1 minute 40 seconds)

)

8640 RRStG SOA [...]

8640 NS ns.berkeley.edu.

8640 RRSIG NS [...] 100 NSEC O.chord.berkeley.edu. NS SOA RRSIG NSEC DNSKEY

100 RRSIG NSEC [...]

8640 DNSKEY2563 5 ( AQPvG9Z4OwGpYryJeQ5oDGRJYc45hvLiLE99 MzLwJ3Coix / FtidVexBqHRC9Js + fg / iJVWSm ue6VMIuEteShtEohlc418 / K9qAQcwyCS8ZNx scBKc1W1sw5RmCkCprGkItSUCuuP10SP / cPK yN / Z6 / qSgvXxA Vjh 7IMauh Veltv2iw ==

); key id = 48254 8640 DNSKEY 2573 5 (

AQOzHIM1NL7E5fuA3hpddBdXcHq3deTPHkLK nt3N3QPRc8XrXJ6WgHp9dreqS8uvp8bF76sB pen / XP8bn9ybOJBz9 ++ wOScugKz! YbF6E / zE vGrKitky5iz1pZ + VsHwy78QKbDSMIslqT25T L8Sx2VthbWJF1IRLuuTAMo7sGnNERw ==); key id = 27075 8640 RRSIG DNSKEY [...] 8640 RRSlG DNSKEYf ...]

O.chord. berkeiey.edu.8640 iN ChordNODE «192.234.98.98»

"Chord.berkeley.edu." 8640 RRSIG ChordNODE [...] 100 NSEC 1.chord.berkeley.edu. A RRSIG NSEC

100 RRSIG NSEC [...]

1. chord.berkeley.edu. 8640 IN ChordNODE «192.234.98.99»

"Chord.berkeiey.edu." 8640 RRSIG ChordNODE [...]

100 NSEC 3.chord.berkeley.edu. ChordNODE RRSiG NSEC 100 RRSlG NSEC [...] 3.chord.berkeley.edu, 8640 IN ChordNODE

"192.234.98.100" "chord.berkeley.edu." 8640 RRSiG ChordNODE [.,.]

100 NSEC chord.berkeley.edu. ChordNODE RRSIG NSEC 100 RRSiG NSEC [...]. In this last file, we see that the NSEC fields indicate systematically the nearest field that follows. When queried for the "2. chord.berkeley.edu" field, the server implementing DNSSEC returns a message of type "NXDOMAIN" indicating that the field does not exist but, thanks to the NSEC type field, it indicates that the identifier "Lchord.berkeley.edu" is just followed by the identifier "3.chord. berkeley.edu ».

Quote that seeks access to the "2.chord. berkeley.edu "then receives a response which, although not allowing direct access to the searched element, allows it to access the non-hierarchical network and, indirectly, the node hosting the data relating to the identifier "2. chord. berkeiey.edu ».

Below, with reference to FIG. 5, is described the operation of a resolution of a combined identifier implemented in particular embodiments of the present invention, starting from the example given described above. in the case of the resolution of the identifier "2" in the domain "chord.berkeley.edu".

A client 500, for example of the general purpose computer or server type, comprises processing means 550, interrogation means 555 and response receiving means 560, of known type but adapted to implement the present invention. Client 500 is considered to want to access the "2" identifier element of the "chord.berkeley.edu" domain. He therefore needs to solve the combined identifier "2. chord. berkeley.edu ", that is to say obtain the locators (in French, iocators) relating to this identifier, such as, for example, the IP address. The combined identifier "2. chord. berkeley.edu "is representative, on the one hand, of the hierarchical domain name to which the Chord network is linked, non-hierarchical, and, on the other hand, of the identifier of the element of this Chord network to which the 500 customer wants to access, the name "2, chord. berkeley.edu "being unknown to domain name resolution servers, for example DNS servers.

The interrogation means 555 thus issue a request 505 indicating the identifier combined with the DNS servers successively responsible for the domains and subdomains represented hierarchically by the combined identifier. After three queries with the servers managing the domains ". ",", Edu "and" berkeley.edu ", the request arrives on the DNS server 510 responsible for the" chord.berkeley.edu "domain. The DNS server 510 has a memory 580 maintaining a database of domain names and IP addresses of servers responsible for said so-called domains, processing means 565, request receiving means 570 and response sending means 575, of known type but adapted to implement the present invention. The combined domain name does not exist in the DNS server database 510. The error message then returned by the DNS server 510 is of type "NXDOMAIN". Indeed, since the DNS server 510 implements the DNSSEC option, the error message 515 is completed by the field "NSEC" indicating the domain name which precedes the domain name being the subject of the request, and the name following the domain name that is the subject of the request, that is, in the example, respectively "S.chord.berkeley.edu. And "1. chrord.berkeley.edu". Indeed, the domain names being classified by lexicographic order within the zone, the domain names which frame the sought identifier constitute evidence of non existence of the searched domain name.

Preferentially, the client 500 indicates, for the combined identifiers, as type of request, the ChordNode type and the DNS server 510 performs a response with the "NSEC" field only for this type of request. This prevents the DNS server 510 performs, for any type of request, a response with the "NSEC" field and encumber, and the hierarchical network.

The additional field "NSEC" of the response sent by the DNS server 510 to the client 500 also includes the IP addresses of the domain names mentioned by the "NSEC" type field.

Once the response received by the receiving means 560, the client 500 interprets the response 515 it receives, that is to say an error message "NXDOMAIN" indicating that the domain name does not exist, and continue searching for the item using the DNS server response and following the Chord protocol. The interrogation means 555 then issue the request 520 to the domain name 525 which follows, in the lexicographic order, that which is the subject of the request, that is to say, here the chord node having the binary identifier "3", and the combined identifier "3. chord. berkeley.edu. According to the Chord protocol.

The node 525 of identifier "3" being capable, according to the Chord protocol set out above, of guiding the client towards the sought-after element, if he does not possess directly access to this element, it communicates to the client 500 the identifier of a server of the Chord network closer to the desired element, by implementing its index table. Thus, if it does not have the answer, it allows the client to obtain it by query iterations of servers of the Chord network, even if these servers have an unknown identifier of the hierarchical naming system, until the client obtains access to the searched element, for example in the form of an IP address of the server having the searched element and returns it to the client 500, in a response 530.

The architecture described for particular embodiments of the present invention allows to insert, within a single naming architecture, here the DNS, a namespace dedicated to binary identifiers.

The invention makes it possible, for example, to integrate the Chord system with the DNS system via a new DNS field of "ChordNODE" type.

Figure 6 relates to the management of identifiers during the creation, addition, removal and referencing in the DNS system, of servers on this network Chord,

FIG. 6 shows a step 605 of adding creation of a Chord network with at least one server, comprising a step 606 of assigning the last non-hierarchical identifier to a server, in the order relation, according to techniques known per se, a step 607 for allocating to each server of the Chord network the responsibility for elements of said Chord network, for example in a distributed hash table and a step 608 for creating an index table for each said server.

Then, during a step 610, a combined identifier is assigned to at least one server of the Chord network, at least the server having the last non-hierarchical identifier, by completing the identifier of each said server on the Chord network by the domain name to which this network belongs and, possibly, information indicating that it is a combined identifier.

During a step 615, the database of the server responsible for said domain is updated and, during a step 620, the combined identifier is propagated on the cache servers of said domain.

During a step 625, it is determined whether a server is added in the Chord network. Otherwise, go to step 650, If yes, during a step 626, one assigns a non-hierarchical identifier to said server, during a step 627, said server is assigned responsibility for elements of said Chord network having a non-hierarchical identifier, for example in a distributed hash table, during a step 628 , an index table is created of said server and in a step 629, each index table of each other server of said Chord network is updated. Then, during a step 630, it is determined whether said server must be referenced in the DNS name resolution server of the domain to which the Chord network belongs. If not, we go to step 650. If yes, during a step 635, we assign a combined identifier to said server, by completing its identifier on the Chord network by the domain name to which this network belongs and, where appropriate, , by information indicating that this identifier is of combined identifier type, within the meaning of the present invention. During a step 640, the database of the server responsible for said domain is updated and, during a step 645, the combined identifier is propagated on the cache servers of said domain.

During a step 650, it is determined whether a server is removed from the Chord network. Otherwise, we return to step 625. If yes, during a step 655, we assign to at least one other server in the Chord network, the responsibility for elements of said Chord network that were under the responsibility of the outgoing server. Then, during a step 660, each index table of each other server of said Chord network is updated. Then, during a step 665, it is determined whether this server has the last identifier of the Chord network. If no, go to step 685. If yes, during a step 670, another server of the Chord network whose combined name is referenced in the domain name resolution server database is selected. belongs to the Chord network. During a step 675, the last identifier of the Chord network is assigned to the selected server. Then, during a step 680, the assignments of the elements of the Chord network between the servers of this network are modified in order to respect the assignment rules of this type of network and the index tables of the servers are updated. of the Chord network.

Then, during a step 685, it is determined whether this server is referenced in the database of the name resolution server of the domain to which the Chord network belongs. Otherwise, go to step 625. If yes, during a step 690, the database of the server responsible for said domain is updated and, during a step 695, the combined identifier is propagated on the cache servers of said domain and we return to step 625.

FIG. 7 represents, in the form of a logic diagram, steps implemented by a computer system attempting to access an element of a non-hierarchical network, by implementing a first embodiment of the access method of an object of the present invention.

During a step 705, the client determines the name of an element to which it must access as well as the name of the domain to which this element belongs, During a step 710, the client applies a hash function to at least a part of said element name to determine the identifier of the element on a non-hierarchical network.

During a step 715, the client determines the combined name of the element by completing the result of the hash function with the domain name to which the element belongs.

During a step 720, the client makes a request concerning the element to which access is sought, indicating that the type of request is a "ChordNode" type.

In a step 725, the polled DNS server responds to the request by providing the IP address of the DNS server responsible for the next subdomain in the hierarchical order of the subdomains represented by the hierarchical portion of the combined identifier. . We then return to step 720, steps 720 and 725 repeating until the last DNS server, responsible for the last subdomain represented by the hierarchical part of the combined identifier. During a step 730, the latter DNS server responds to the request by indicating, in a "NSEC" field:

- that he does not know the name of the object element of the request,

the name of the element that succeeds, in its database, to the identifier requested, the IP address corresponding to this name,

the name of the element which precedes, in its database, the requested identifier,

- the IP address corresponding to this name. The response of the DNS server is thus preferentially representative of at least one server name which is, in the exographic order and in the memory of said name resolution server, immediately greater or lesser than said identifier. It is observed that the implementation of steps 700 to 730 presents both the advantages of the DNS system and the advantages of non-hierarchical naming systems, for example, the easy or fast addition or removal of files or nodes. In fact, in non-hierarchical naming systems, the elements are managed by the servers that have the closest identifier, it being understood that the notion of proximity depending on a distance function defined for the non-hierarchical naming system.

During a step 735, the client determines that the answer includes an "NSEC" field and extracts the IP address of the server having the name that succeeds the requested identifier. During a step 740, the client sends a request identical to that sent during steps 710 to the server having the name that succeeds the requested identifier.

During a step 745, the server that receives this request determines whether it handles the requested element. If yes, during a step 750, it provides the client access to the requested element, for example in the form of a file, data or an IP address where the client can download the requested element. Otherwise, the server determines, by implementing the distributed hash table DHT, the name and the IP address of a server of the non-hierarchical network which is closer to the name of the requested element and which succeeds it, during of a step 755 and returns this name and this IP address to the client, during a step 760.

During a step 765, the client sends a request identical to that sent during steps 710 to the server having the name identified in step 755. Then, we return to step 740.

The first embodiment of the access method that is the subject of the present invention, illustrated in FIG. 7, corresponds to the case where the non-hierarchical network is structured as explained with reference to FIG. 6, that is to say with, in permanently, a server with an identifier on the non-hierarchical network higher than the identifiers of all the other elements of this non-hierarchical network, this server being referenced in the DNS system.

The second embodiment of the method that is the subject of the present invention, illustrated in FIG. 8, corresponds to the case where the elements can have an identifier on the non-hierarchical network that is greater than each server identifier of this network referenced in the DNS system.

FIG. 8 represents, in the form of a logic diagram, steps implemented by a computer system attempting to access an element of a non-hierarchical network, by implementing a first embodiment of the access method to an object of the present invention.

During a step 805, the client determines the name of an element to which he must access as well as the name of the domain to which this element belongs.

During a step 810, the client applies a hash function to at least a part of said element name to determine the identifier of the element on a non-hierarchical network.

During a step 815, the client determines the combined name of the element by completing the result of the hash function with the domain name to which the element belongs.

During a step 820, the client makes a request concerning the element to which access is sought, indicating that the type of request is a "ChordNode" type.

In a step 825, the polled DNS server responds to the request by providing the IP address of the DNS server responsible for the next subdomain in the hierarchical order of the subdomains represented by its hierarchical portion of the combined identifier. . Then return to step 820, steps 820 and 825 repeating until the last DNS server _. responsible for the last subdomain represented by the hierarchical part of the combined identifier.

During a step 830, the latter DNS server responds to the request by indicating, in a "NSEC" field: - that it does not know the object element name of the request,

the name of the element that succeeds, in its database, to the identifier requested,

- the IP address corresponding to this name, the name of the element which precedes, in its database, the requested identifier,

- the IP address corresponding to this name.

During a step 835, the client determines that the response includes a "NSEC" field and extracts the IP addresses of the servers having, for (one, the name that succeeds the requested identifier and, for the other, , the name that precedes the requested identifier.

During a step 840, the client sends a request identical to that sent during steps 810 to the server having the name that succeeds the requested identifier, that is to say the server having the last of the two names. from the "NSEC" field.

The client then determines whether the response it receives is an error message, which would indicate that the server that received the request is not part of the non-hierarchical network, in a step 845. If yes, the client, during a step 850, a request identical to that issued during steps 840 to the server having the name that precedes the requested identifier, that is to say to the server having the first of the two names of the NSEC field.

The access method thus comprises a determination step of obtaining access to the searched element, from a server having a name different from the sought identifier and, in the absence of obtaining this access, an interrogation step of another server having a different name of said identifier. Thus, if the access to the sought element can not be obtained from a server having a name which follows, in the lexicographic order, the identifier of the searched element, it is obtained from a server with a name that precedes, in lexicographic order, the combined identifier.

The server that received the request issued during step 850 or the server that received the request issued during step 840 and is part of the non-hierarchical network, determines, during a step 855, it manages the requested element. If yes, during a step 860, it provides the client access to the requested element, for example in the form of a file, data or an IP address where the client can download the requested element. Otherwise, the server considered determines, by implementing the distributed hash table DHT, the name and IP address of a server of the non-hierarchical network that is closer to the name of the server. the requested element and succeeding it, during a step 865 and returns this name and IP address to the client, during a step 870.

During a step 875, the client sends a request identical to the one sent during steps 810 to the server having the name identified in step 865. Then, it returns to step 855.

As can be seen from FIGS. 3 to 8, in accordance with the present invention, to obtain access to an element having an identifier, the client interrogates the name resolution servers of a hierarchical naming system, here DNS, by providing them the combined identifier. One of these servers responds by providing at least one server name different from said identifier and hierarchically at the same level as said identifier, server of the non-hierarchical network referenced in the DNS system. Then, the customer asks at least one te! server.

Thus, regardless of the complexity and the dynamic changes of the non-hierarchical network, an element having an unknown identifier of the address resolution system can be found via the server of the non-hierarchical network referenced in the DNS system, although its name is different from the identifier of the searched element.

The implementation of the present invention thus makes it possible to integrate two naming systems, hierarchical and non-hierarchical, so as to use, in the DNS system, identifiers having, in part, a non-hierarchical identifier specific to a domain.

The present invention is not limited to the embodiments described and shown. It applies, on the contrary, to any method and device in which, in response to a request specifying an element identifier on a network, unknown identifier of a computer system, it responds by providing an identifier (name or IP address, for example) which is known from M and, preferably, the identifier thus provided is the closest, among all the known identifiers of the computer system, in the lexicographic order, of the object identifier of the request.

Thus, in some embodiments of the present invention applied to Chord type networks, the client does not implement any new step. For example, the last DNS server polled responds to the request that is addressed to it by providing the identifier he knows closest and immediately superior, in lexicographic order, to the identifier specified in the request sent by the customer, without indicating who! is not the server with the identifier specified in the request. Thus, unlike the embodiments illustrated in FIGS. 7 and 8, the client is not informed of this difference between the supplied identifier and the required identifier. It is observed, however, that these two identifiers are then, preferably, at the same hierarchical level in the hierarchical naming system since they represent the same domain name and two different non-hierarchical network identifiers. Using the identifier returned to it in a new query, as if it is! was the address corresponding to the identifier specified in the request, the client then accesses a server of the non-hierarchical network and obtains, directly or indirectly, as exposed with reference to Figure 7, the access to the element having said identifier. This particular embodiment has the advantage of not requiring any modification, hardware or software, at the customer level.

Claims

1 - Method for accessing an element having an identifier, characterized in that it comprises: - at least one interrogation step (720, 820) of a name resolution server of a hierarchical naming system, responsible for a domain represented by said identifier, said interrogation comprising said identifier,

a step of receiving (730, 830) a response from a said name resolution server, said response being representative of at least one server name different from said identifier and hierarchically at the same level as said identifier and

an interrogation step (740, 840, 850) of a server having a said name different from said identifier. 2 - Method according to claim 1, characterized in that, during the step of receiving a response (730 830), said response is representative, on the one hand, that said identifier is unknown to said server of name resolution and, on the other hand, each said different name of said identifier.

3 - naming system characterized in that it assigns, for at least one element (200 to 215), a combined identifier representative, on the one hand, of a name according to a hierarchical naming system and, on the other hand , an element identifier of a non-hierarchical naming system, the identifier of the hierarchical naming system allowing access to a server and the identifier of the non-hierarchical naming system allowing access to the accessible elements server, by implementing the non-hierarchical naming system.

4 - Method for naming an element of a non-hierarchical network on which the identifiers are managed by interval, characterized in that it comprises a step of assigning (610 to 620), to said element, a hierarchical name a domain having a server of said non-hierarchical network and an assigning step (610), to said element, of a name complement representing its identifier on the non-hierarchical network.

5 - Process according to claim 4, characterized in that it further comprises a step of updating a distributed table in which each element of the a non-hierarchical network is connected to a server identifier responsible for said element.

6 - Process according to any one of claims 4 or 5, characterized in that it further comprises a step of referencing (615, 620, 630 to 645) of at least one server of said non-hierarchical network on the least one domain name resolver (510). hierarchical.

7 - Method of response, by a server, to a name resolution interrogation comprising an identifier, characterized in that it comprises: - when said server stores, in memory, an address corresponding to said identifier, a response step to the course said server provides said address (725) and

when said server does not store, in memory, an address corresponding to said identifier, a response step during which said server provides a response representative of at least one server name different from said identifier and hierarchically at the same level as said identifier; , without indicating that said name is different from said identifier (730).

8 - Process according to claim 7, characterized in that, when said server does not store, in memory, an address corresponding to said identifier, during the response step (730), said response is representative of at least one server name which is, in the lexicographic order and in the memory of said server, immediately higher or immediately lower than said identifier. 9 - Terminal (500) for access to an element having an identifier, characterized in that it comprises;

interrogation means (555) adapted to interrogate at least one name resolution server of a hierarchical naming system, responsible for a domain represented by said identifier, said interrogation comprising said identifier and

means for receiving (560) a response from a said name resolution server, said response being representative of at least a server name (525) different from said identifier and hierarchically at the same level as said identifier, said interrogation means being adapted to interrogate a server having a said name different from said identifier, 10 - Terminal according to claim 9, characterized in that this interrogation means (555) is adapted so that said identifier is a so-called "combined" identifier representative, on the one hand, of the name of said domain and, on the other hand, of an element identifier on a network said "non-hierarchical" (200 to 215) which comprises said server having said name different from said identifier and said element.

11 - Terminal according to any one of claims 9 to 10, characterized in that the interrogation means (555) is adapted to determine whether an access to said element has been obtained from a said server (525) having a name different from said identifier and, in the negative, to interrogate another server having a said different name of said identifier.

12 - Name resolution server (510) comprising an identifier comprising a memory (580) in which identifiers are associated with addresses in one interrogation, characterized in that it comprises an adapted response means

when said memory retains an address corresponding to said identifier, to provide a response representative of said address and

when said memory does not retain an address corresponding to said identifier, to provide a response representative of at least one server name different from said identifier and hierarchically at the same level as said identifier, without indicating that said name is different from said identifier.

13 - Computer program loadable in a computer system, said program containing instructions for implementing the method of access method to an element having an identifier according to any one of claims 1 to 2, when this program is loaded and executed by a computer system.

14 - computer program loadable in a computer system, iedit program containing instructions for implementing the method of naming method of an element according to any one of claims 4 to 6, when this program is loaded and executed by a computer system, 15 - computer program loadable in a computer system, said program containing instructions for implementing the method of response to a query seion any one of claims 7 or 8, when this program is loaded and executed by a computer system.