WO2000042526A1 - Interfonctionnement et systeme de caches cooperants et caches repartis - Google Patents

Interfonctionnement et systeme de caches cooperants et caches repartis Download PDF

Info

Publication number
WO2000042526A1
WO2000042526A1 PCT/FR2000/000042 FR0000042W WO0042526A1 WO 2000042526 A1 WO2000042526 A1 WO 2000042526A1 FR 0000042 W FR0000042 W FR 0000042W WO 0042526 A1 WO0042526 A1 WO 0042526A1
Authority
WO
WIPO (PCT)
Prior art keywords
cache memories
cooperating
distributed
local
memories
Prior art date
Application number
PCT/FR2000/000042
Other languages
English (en)
Inventor
Ahmed Mokhtar
Stéphane LEDIOT
Rémi POULET
Original Assignee
France Telecom
Telediffusion De France
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
Priority claimed from FR9900283A external-priority patent/FR2788398A1/fr
Application filed by France Telecom, Telediffusion De France filed Critical France Telecom
Publication of WO2000042526A1 publication Critical patent/WO2000042526A1/fr

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/2866—Architectures; Arrangements
    • H04L67/2885—Hierarchically arranged intermediate devices, e.g. for hierarchical caching
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
    • 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/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5682—Policies or rules for updating, deleting or replacing the stored data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to a method for transmitting HTTP requests for access to an object, consisting of files such as HTML pages, images or the like.
  • One solution to reduce or solve this problem consists in using, in order to assist the origin servers, managers of these objects of which they ensure the distribution, of the cache memories installed in user / server interfacing systems, called “pro ies "in Anglo-Saxon language.
  • These proxies and hidden memories as represented in FIG. 1a are part of a set called conjugate comprising an HTML analysis and transformation module, Mi, a anticipation module M, a module M 3 for online conversion of documents and finally the actual cache memory M 4 .
  • the cache memories play the role of an auxiliary server.
  • the cache memory M 4 On HTTP request to access a document, A, by the user terminal, the cache memory M 4 returns the document, B, to the latter. Otherwise, a request message, HTTP request, is sent, C, from the cache memory M 4 to the origin server, which transmits in return, D, the requested document to the memory M 4 , thanks to the proxy associated with it. , stores a copy of this document, after indexing, E, and transmits the content of this document, F, to the user terminal.
  • the management protocol for each CARP cache memory comprises, following the sending and receiving of an HTTP access request 1a, a verification of this request, lb. If the request is verified, a hash function is applied, the, to find the CARP cache memory holding the document. In the case ld where this cache memory has this document, the latter is transmitted to the "holder on. Otherwise, an lf access to the origin server is made to collect the document and if necessary make a backup copy in the memory CARP cache of the most appropriate network.
  • the ICP protocol described by way of pure nonlimiting example, consists above all in locating the object required by the user terminal in a group of cooperating cache memories each associated with a proxy, the cooperation of cache memories of the group of cooperating cache memories being produced between a local cooperating cache memory, memory receiving the HTTP access request sent by the client terminal, and the cooperating cache memories of the group, called neighboring cooperating cache memories.
  • neighboring cooperating cache memories in hierarchical order, in parent and similar cooperating cache memories (sibling in Anglo-Saxon language). The function of the parent cooperating caches and the like will not be described in detail since it is known as such from the state of the art.
  • the management protocol for each ICP cache memory comprises steps 2a, of receiving the HTTP request for access to the document and of verification 2b, of the request by the local cooperating cache memory.
  • an ICP request is launched, 2c, from the local cooperating cache memory to the neighboring cooperating cache memories of the group. If the document is found in the latter, this document is transmitted to the user terminal and the local cooperating cache memory makes a backup copy of the latter, 2f. Otherwise, the local cooperating cache memory, 2e, sends a request message to the origin server, which transmits the document sought to the local cooperating cache memory. Step 2f is then carried out.
  • the ICP protocol is satisfactory but, while in the absence of the document sought in the neighboring cooperating cache memories, no response message is transmitted to the local cooperating cache memory, the interrogation of the origin server is launched by the latter after a determined time, generating an overall overall delay.
  • the required document is systematically saved at the level of the local cooperating cache memory, which ultimately, for all the cooperating cache memories of the group, furthermore imposes the supply of significant mass memory means and the management of these.
  • the object of the present invention is to remedy the drawbacks of the aforementioned cache memory management protocols by implementing a method for transmitting HTTP requests for access to an object, by means of distributed and cooperating cache memories, in which the drawbacks of using, separately, the protocols for managing the distributed and cooperating cache memories are eliminated.
  • another object of the present invention is the implementation of a method for transmitting HTTP requests for access to an object from the protocols for managing the distributed and cooperating cache memories in which these protocols are adapted to one to the other and vice versa.
  • another object of the present invention is the implementation of a method of transmitting HTTP requests for access to an object from the protocols for managing the distributed and cooperating cache memories in which the communication interfaces of each of these protocols and the mechanisms or operating modes of these protocols are mutually adapted to each other.
  • Another object of the present invention is the implementation of a method for transmitting HTTP requests for access to an object constituted by HTML pages in which the memory space necessary for each cooperating cache memory is optimized.
  • Another object of the present invention is, finally, the implementation of a method of transmitting HTTP requests for access to an object, consisting of HTML pages, in which the number of accesses to the origin server and the congestion of the network are appreciably reduced.
  • the method for transmitting HTTP requests for access to an object consisting of files such as HTML pages, images or the like managed by an origin server, between a user terminal, cooperating distributed caches and this server origin, object of the present invention, is remarkable in that it consists in configuring the distributed cache memories as first level cache memories, these memories being adapted to receive and send requests and HTTP responses relating to this object and to store this object on memory management criteria and to configure the cooperating cache memories as second level cache memories.
  • the distributed cache memories are adapted to receive this request, and, in the presence of this object in the latter, to transmit to the user terminal an HTTP response for transmitting this object. .
  • this object in the latter are adapted to transmit to a local cooperating cache an HTTP request for access to this object.
  • the latter is transmitted to the distributed cache memories, then to the user terminal.
  • a search message for this object is transmitted from the latter to the neighboring cooperating cache memories.
  • this object is transmitted from the neighboring cooperating cache memories to the local cooperating cache memory, in the absence of a backup copy of this object in the latter, then to the distributed memories and the user terminal.
  • an HTTP request for access to this object is transmitted from this local cooperating cache memory to the origin server.
  • An HTTP response containing this object is then transmitted to the local cooperating cache memory, the distributed cache memories and the user terminal.
  • This operating mode makes it possible to reduce the number of accesses and the occupation time of the origin server.
  • FIGS. 1a, 1b, 1c and 1d relating to the prior art:
  • FIG. 2a shows a general flowchart illustrating the process, object of the present invention
  • FIG. 2b represents, on a hardware configuration corresponding to the interconnection of the cache memories distributed in a network and of cooperating cache memories, the essential steps implemented by the process of cooperation between distributed cache memories and cooperating cache memories configured in cache memories first and second level respectively, according to the method of the invention as shown in Figure 2a;
  • FIG. 2c shows a more detailed flowchart of the steps implemented by the cooperation process between distributed cache memories and memories cooperating caches configured in first and second level cache memories respectively, in accordance with the method which is the subject of the present invention as shown in FIG. 2a and 2b;
  • - Figure 3a shows, at. by way of nonlimiting example, the structure of a local cooperating cache memory in accordance with the object of the present invention;
  • Figure 3b shows a particular non-limiting embodiment of the local cooperating cache memory shown in Figure 3a;
  • FIG. 4 shows, by way of non-limiting example, the structure of a local cooperating cache memory according to the object of the present invention, in which the function of distributing an object in the distributed cache memories is in additionally established;
  • FIGS. 5 and 6 represent a preferred structure of a local cooperating cache memory, particularly suitable for managing HTTP requests and ICP requests from a database in thumbnail mode, and such a thumbnail respectively, a thumbnail being associated with an HTTP request or an ICP request, in order to ensure optimized management of the search and transmission of the document required by the requester;
  • - Figure 7 shows an alternative embodiment of Figure 5, in which the database, external to the local cooperating cache memory, is managed by means of the management protocol of the cooperating cache memories;
  • FIG. 8 represents, in the case of a local cooperating cache memory conforming to the object of the present invention as shown in Figure 5 or 7, a preferred process for managing HTTP requests respectively ICP received by this local cooperating cache memory.
  • the object of the present invention is to ensure the transmission of HTTP requests for access to the aforementioned object, this object and the corresponding HTML pages for example being managed by an origin server in order to allow HTTP responses containing this object to be obtained by the user who made the aforementioned access request.
  • the request is made by the latter from a user terminal and the HTTP requests and corresponding HTTP responses, implemented by the method which is the subject of the present invention as shown in FIG. 2a, intervene between the aforementioned user, memories distributed caches, managed according to a distributed cache memory management protocol, and cooperating cache memories managed according to a cooperative cache memory management protocol.
  • the distributed cache memories are interconnected in a network and can constitute, for example, cache memories of a corporate network or the like.
  • Cooperating cache memories include at least one local cooperating cache memory, which is deemed to receive the HTTP request relating to an object, and neighboring cooperating cache memories and the distributed cache memories being interconnected in a network to the origin server.
  • the distributed cache memories are configured as first level cache memories, these distributed cache memories being adapted to receive HTTP requests from the user terminal and to send requests to the local cooperating cache and receive HTTP responses relating to this object.
  • the distributed cache memories are adapted so as to store, on memory management criteria, the aforementioned object.
  • a standard memory management criterion may consist in an equal distribution in volume of the data stored at the level of each distributed cache memory. All of the distributed cache memories are therefore interconnected in a network, each distributed cache memory thus not comprising the same documents stored in the latter.
  • the memory management criterion of the distributed memories and in particular the function of distribution of the objects constituted by the HTML pages most frequently requested by the user will not be described in detail since they correspond to processes commonly implemented in the technique , in particular in the case where the distributed memories are managed according to the CARP management protocol.
  • the method which is the subject of the present invention, it consists in configuring the cooperating cache memories as second level cache memories.
  • the operating mode of the method, object of the present invention, between distributed cache memories and cooperating cache memories is then as follows, with reference to FIG. 2a.
  • the method, object of the present invention consists in transmitting to the user terminal, in a step 1001, an HTTP response for transmitting this object.
  • the method which is the subject of the present invention consists, on the contrary, in transmitting to the local cooperating cache memory an HTTP request for access to this object.
  • the local cooperating cache memory is that which is intended to receive the request relating to a given object from a network constituted by a set of distributed cache memories. This transmission is carried out by simple addressing determined from a specific distributed cache memory. This procedure, known as such, will not be described in detail for this reason.
  • the request 1002, HTTP request represented in FIG. 2a thus consists in transmitting a request for access to the document considered from all of the first level memories to the second level memories constituted by the cooperating cache memories.
  • object of the present invention in the presence of this object in the local cooperating cache memory, this consists in transmitting, in a step 1003, constituting an HTTP response, from the local cooperating cache memory to the distributed cache memories, the object under consideration then, of course, to the user terminal by a response HTTP analogous to response 1001 previously mentioned.
  • the method, object of the present invention consists in transmitting from this local cooperating cache memory to the neighboring cooperating cache memories, a search message MR for this object , in an operation 1004.
  • the method then consists, in a step 1005, of transmitting this object from the neighboring cooperating cache memories to the local cooperating cache memory.
  • This operation performed, and in accordance with a particularly advantageous aspect of the method which is the subject of the present invention, no backup copy of this object in the local cooperating cache memory is then performed, unlike the management protocol for cooperating cache memories such as the ICP protocol.
  • the object is then transmitted to the distributed cache memories and the user terminal by steps analogous to steps 1003 and 1001 previously mentioned in the description.
  • the method which is the subject of the present invention consists in transmitting an HTTP request for access to this object from the local cooperating cache memory to the origin server, step 1006 shown in Figure 2a produced via the Internet and more particularly the WWW, HYPERMEDIA distributed system previously mentioned in the description.
  • an HTTP 1007 response containing the object is then transmitted from the origin server to the local cooperating cache memory via the WWW and then to the cache memories distributed via an HTTP response analogous to the response 1003 previously described, and finally, to the user terminal via an HTTP response 1001 previously described.
  • the first level cache memories formed by the distributed cache memories receive the HTTP access request sent by the user, verify the local existence of the document requested in the aforementioned distributed cache memories. If this document does not exist in the latter, the first level cache memories transmit a request to the second level memories, which are constituted by the cooperating cache memories implementing a lean management protocol, due to the failure to make a backup copy of a document at the local cooperating cache memory, so as to locate the document in the neighboring cooperating cache memories.
  • this document is then simply returned to the local cooperating cache memory, which can then be configured so as not to carry out the backup copy as mentioned previously but, at the otherwise, so as to simply transmit this document to the first level cache memories, which then allow this same document to be transferred to the user, after of course having made a backup copy of this document, in accordance with the memory management criterion distributed cache memories previously mentioned in the description.
  • the local cooperating cache memory plays the role of a simple transfer system in the absence of memorization and storage of a backup copy.
  • cooperating cache memories in particular the local cooperating cache memory
  • cooperating cache memories can be changed in their configuration so as to simply transfer the support data of the document sought which was stored, either in one of the neighboring cooperating cache memories, or, if necessary, in another network of distributed cache memories.
  • the aforementioned document can then be stored, either in a mass memory when the local cooperating cache memory is provided with such a mass memory, or, on the contrary, externally to this local cooperating cache memory, when the latter does not have a mass memory.
  • the distributed cache memories appear to be particularly suitable for carrying out the function of storing the backup copy.
  • the first level cache memories distributed memories, constituted by way of purely illustrative example, are represented by three distributed cache memories referenced RCMi, RCM 2 , RCM 3 , these memories being for example managed according to the protocol CARP.
  • the cooperating cache memories of the second level have been represented as constituted by a local cooperating cache memory CCMi, neighboring cooperating cache memories constituted by a similar cooperating cache memory denoted CCM 2 and a parent cooperating cache memory denoted CCM 3 .
  • the similar neighboring and cooperating cooperating cache memories and the local cooperating cache memory are deemed to be managed by the ICP protocol.
  • the local and neighboring cooperating cache memories are interconnected in a network and the latter's network is also interconnected, on the one hand, to the network of first level distributed cache memories as well as to the Internet network, that is to say to the Hypermedia WWW interface system and thus to the origin server.
  • the HTTP requests and responses sent by or to the user 1000, 1001, by or to the first level cache memories 1002, 1003, by or to the local cooperating cache memory 1004 and 1005 and 1006, 1007 bear the same references as those indicated in FIG. 2a.
  • the local cooperating cache memory CCMi before proceeding to send the HTTP request 1006 to the origin server, can advantageously proceed to a exploration of each neighboring cooperating cache memory, that is to say of the similar memory CCM 2 and of the parent memory CCM 3 .
  • this can consist in communicating to the cooperating cache memory local, the CCMi memory, information, denoted CCR, relating to the distribution of the content of the distributed cache memories.
  • information denoted CCR, relating to the distribution of the content of the distributed cache memories.
  • the method which is the subject of the present invention can consist in storing, at the level of the local cooperating cache memory CCMi, a content index IC of this object, this index being representative of an address of the content of this object, storage address of the latter.
  • This index can, as mentioned previously, be linked to the information relating to the distribution of the content of the distributed cache memories.
  • the method which is the subject of the present invention also consists in communicating to the local cooperating cache memory CCMi the distribution function FR of the distributed cache memories.
  • the management function of the cache memories distributed at the level of the local cooperating cache memory CCMi it is possible to delocalize, at least in part, the management function of the cache memories distributed at the level of the local cooperating cache memory CCMi, the latter then being able in this case to be adapted from the function of 18
  • FIG. 2c A more detailed description of the process, object of the present invention, when the latter is implemented from first level cache memories managed according to the CARP protocol and second level cache memories managed according to the ICP protocol, will now be given in link with FIG. 2c in the more specific context of the exchange between first level distributed cache memories and second level cooperating cache memories.
  • FIG. 2c the references relating to HTTP requests and responses have been reproduced with reference to FIG. 2b.
  • the method, object of the present invention can then consist, at the level of one of the distributed cache memories RCMi to RCM 3 in step 2000, in a step of verifying the request formulated by the latter.
  • This step of checking request 2000 is followed by a step 2001 of the true value of this check.
  • a step 2002 consisting of process A previously described in the description, which makes it possible to manage the verification defect at the true value.
  • a step 2003 is performed by the aforementioned distributed cache memory, 19
  • step 2003 is itself followed by a step 2004 consisting in verifying the presence of this document in the local cooperating cache memory CCMi.
  • step 2005 is provided, consisting of a response to the client, that is to say to the user, which implements the steps 1003 and 1001 previously mentioned in connection with FIG. 2b.
  • a step 2006 is planned, which consists of sending a search message MR, message 1004 of FIG. 2b, to the neighboring cooperating cache memories. It is recalled that the transmission of this search message can be carried out in the case where the second level cooperating cache memories are managed by the ICP protocol by a GET procedure. It is also recalled that the procedure 2006, that is to say the sending of the search message MR during the operation 2004, can be carried out for all of the neighboring cooperating cache memories as mentioned previously in the description.
  • the above-mentioned MR 2006 search message sending procedure is itself followed by a test step 2007 consisting in determining, at the level of the local cooperating cache memory CCMi, whether the document sought has been found. If this is not the case, that is to say in negative response to the 2007 test, the step of sending an HTTP request to access the original server, step 1006, is carried out and, as a result, the HTTP response step 1007 is also made to the local cooperative cache memory CCM X.
  • step 2008 which consists in transmitting the sought document from the cooperating cache memory local to the distributed cache memories, then to the user terminal according to steps 1003 and 1001 previously described in connection with FIG. 2b.
  • the method which is the subject of the present invention makes it possible to recover any document requested by an HTTP request via second level cache memories in the absence of making a backup copy at the level of the latter.
  • Such an operating mode allows in particular a simplification of the management of second level cache memories and, in particular, of implementation of the latter, any mass memory being able to be deleted.
  • the method which is the subject of the present invention naturally allows access to distant databases, that is to say to the origin server, to be maintained under conditions similar to the method for managing first level memories. , CARP management method, and second level cooperating cache memory management method, ICP management protocol method.
  • the method that is the subject of the invention also allows the application of a hash function used for the management of first level distributed cache memories to allow the allocation of documents required by an external ICP cache memory, this operating mode constituting a compatibility factor of the process, object of the present invention, with respect to existing management protocols.
  • the elements necessary for implementing the method, object of the present invention can be implemented in the form of instructions in the BIOS of the operating system of the processor equipping the proxy. managed by the ICP management protocol if it does not include a mass memory.
  • the distributed memory management protocol when this management protocol is the CARP protocol, can also be modified if necessary.
  • the implementation of the method which is the subject of the present invention thus makes it possible to obtain essential advantages such as maintaining the balance of the loads and the performances offered by the CARP management protocol while retaining the benefit of the advantages of the protocol. of ICP management for the localization of nonexistent documents in the neighboring caches, without it being necessary to have systematic access to the origin server.
  • Another advantage of the method, object of the present invention also consists in the fact that there is no need for mass memory space due to the absence of execution of a backup copy at the cache memory level. local cooperant.
  • the first level distributed cache memories carry the references RCMi to RCM 3 and that the second level cooperating cache memories carry the references CCMi for the local cooperating cache memory, CCM 2 for a cache memory similar cooperating and CCM 3 for a parent cooperating cache, all of these cooperating cache memories constituting second level cooperating cache memories.
  • the first level distributed cache memories RCMi to RCM 3 ensure the sharing of the cache function vis-à-vis the original server. It is understood in particular that the first level distributed cache memories share the cache function vis-à-vis the original server shown in FIG. 2b, but also vis-à-vis any server interrogated by the non-user terminal. shown in the drawing.
  • the second level cooperating cache memories give priority to the transmission of HTTP requests, responses to these requests and the transmission of the object requested by the user terminal. from another second-level cooperating cache or from the aforementioned original server.
  • the cooperating cache memories allow, by the management protocol of these cooperating cache memories, the ICP protocol as mentioned previously in the description by way of illustration, to search for and transmit the required document, either at the level of the origin server, that is to say at the level of a set of first level distributed caches.
  • the first level distributed cache memories provide top-down management of each unsatisfied HTTP request, request 1000 in FIG. 2b, to the cooperating cache memories of second level, and the entire decision-making process relating to the distributed backup of the object required in the first level distributed cache memories RCMi to RCM 3 .
  • each local cooperating cache memory such as the CCMi memory belonging to the second level cooperating cache memories can thus include a calculation unit, denoted 1, and a read only memory, denoted 2.
  • the computing unit 1 advantageously comprises a microprocessor or a microcontroller, noted CCPU, which is interconnected to a RAM memory.
  • the ROM 2 type ROM 2 is also connected to the computing unit 1, and more specifically to the microprocessor or the microcontroller.
  • the read-only memory can be a read-only memory of ROM type accessible only for reading or, if necessary and preferably, an electrically reprogrammable read-only memory, called of REPROM type.
  • an input / output unit 3, denoted I / O is provided, which is also connected by a bus link to the calculation unit 1.
  • the local cooperating cache memory CCMi thus makes it possible to ensure the transmission of HTTP requests, responses to these requests and the transmission of the object in the absence backup memory for this object.
  • each local cooperating cache memory such as the CCMi memory represented in FIG. 2b and belonging to the second level cooperating cache memories, can advantageously include, in the read only memory 2, a series of instructions allowing the implementation of an interactive protocol for accessing the stored data of the first level distributed cache memories.
  • the local cooperating cache memory CCMi is also associated with an internal database containing an index of the documents stored at the level of the cache memories distributed RCMi to RCM 3 .
  • 1007 represents an ICP request originating from an external cooperating cache memory not shown in FIG. 2b
  • 1007a represents a request from the local cooperating cache CCMi to the database internal
  • 1007b represents the response of the internal database to the local cooperating cache CCMi.
  • an ICP response containing the index data is generated in 1006 by the local cooperating cache memory CCMi. It is understood that the aforementioned index includes an indication relating to the document and an indication relating to the cache memory comprising this document. On the contrary, when receiving a request
  • each HTTP request can itself be provided with an index corresponding to the format of the indexes contained in the internal database.
  • the responses to the HTTP request 1000 bear the references 1003, 1002 and 1001 as shown in FIG. 2b.
  • the updating of the internal database can be carried out from the cache memories distributed RCMi to RCM 3 by a synchronization signal.
  • each local cooperating cache memory such as the CCMi memory, also includes in the previously mentioned read-only memory 2 the function of distributing this object in the first level distributed cache memories. .
  • the distribution function FR has been represented as consisting in a set of digital data FRi, FR 2 , FR 3 stored in the aforementioned read-only memory 2, this read-only memory in this case being constituted by an electrically reprogrammable memory.
  • the distribution function comprises an index relating to the document stored in each distributed cache memory RCMi, RCM 2 , RCM 3 , and a storage address in each corresponding memory according to the availability of each distributed cache memory. It will be recalled that the management of the distributed cache memories is carried out according to a management procedure known as such, this management being ensured for example according to the CARP protocol previously mentioned in the description.
  • the local cooperating cache memory CCMi is then able, from a hash function, to search for each object or document saved in the first level distributed cache memories, and required by an ICP request for example, by direct addressing of the memories covers distributed RCMx to RCM 3 above.
  • the concept of direct addressing is symbolized by the arrows directly connecting the distribution function FR via the hash function to each aforementioned distributed cache memory.
  • the database associated with this cache memory system can be external.
  • the database is no longer located at the level of the local cooperating cache CCME for example, but can be installed on any location on the network.
  • a request management mode a request management mode
  • HTTP and ICP requests in thumbnail mode are preferably implemented. It is indicated that the concept of thumbnail corresponds substantially to that of index for the internal database, with the difference that each thumbnail is thus associated with an HTTP request or an ICP request in order to manage the addresses of the distributed cache memories containing the document sought.
  • the external database contains an indexed file of the content of the first level distributed cache memories represented by RCMj., RCM 2 and RCM 3 in FIG. 5.
  • HTTP request 1000 On HTTP request 1000, this request being provided with a thumbnail containing at least an identification index of the document or object sought, index noted ID-OBJ, the search for the document is transmitted by an HTTP request 1003 to the distributed cache memories mentioned above.
  • HTTP request 1003 On a positive response, the document being found in one of the aforementioned cache memories with reference to the identification number ID-OBJ of this document, an HTTP response 1002 is sent back to the user terminal. If the document is not found in the aforementioned distributed cache memories, an ICP request is sent by the local cooperating cache memory CCMi to the external database.
  • the external database can be linked to the local cooperating cache memory, either via an interactive protocol, denoted 1008a, 1008b, when the external database is on the same site as the local cooperating cache memory, or by the management protocol for cooperating cache memories, ICP protocol, when the database is not located in the vicinity of the local cooperating cache memory, as will be described later in the description.
  • Querying the aforementioned external database then makes it possible to complete the thumbnail using the data contained in the aforementioned database, to the object identification number ID-OBJ being added by concatenation a distributed cache memory address containing the document you are looking for.
  • the corresponding thumbnail represented in FIG. 6 is added to the ICP request, which is then transmitted for example in a step 1006 in FIG. 5.
  • the interactive communication protocol used is established between this external database and the user / server interface system designated by "proxy".
  • the external database is shown situated at any location on the network, that is to say in fact outside any neighborhood of the local cooperating cache memory CCMi.
  • the interrogation of the database is carried out from the local cooperating cache memory CCMi via the management protocol of the cooperating cache memories, that is to say from the ICP protocol via ICP requests and responses 1006, 1007, 1008, 1009.
  • the external database can be updated from the first level distributed cache memories.
  • the operation of updating the external database can then be carried out from the monitoring of the data flow for each object.
  • This management mode relates to a local cooperating cache memory such as the CCMi memory, the embodiment of which corresponds substantially to the embodiment of FIG. 5 in the case where the database is external.
  • the requests and the responses have the same references as in the case of FIG. 5.
  • each local cooperating cache memory is systematically in the waiting state, 3000, for receiving an HTTP request or an ICP request.
  • this HTTP request comprising at least the identification ID-OBJ of the object in thumbnail mode
  • the existence of this thumbnail is verified in a step 3002 at the cooperating cache memory local.
  • a search for the document corresponding to the identification number ID-OBJ of the latter is carried out in the cache memories distributed RCi to RC 3 .
  • the search for the document is carried out as a function of the latter's identification number, in step 3003.
  • the document is of course transmitted and the local cooperating cache memory returns to the waiting state 3000.
  • the HTTP request is ignored in step 3004.
  • this ICP request includes at least one sticker comprising the number identification of the document or object sought.
  • a test 3006 is performed by interrogating the external database when the thumbnail is present in the ICP request.
  • the ICP request is transmitted to the external database by an ICP request and the database, in step 3007, returns a response, the response 1009, in which the thumbnail has been completed with the reference number of the cache memory containing the document or object sought.
  • An ICP response with the completed sticker is returned by the local cooperating cache memory CCMi and the latter returns to the waiting state 3000.
  • thumbnail mode appears particularly interesting insofar as it is likely to be implemented by a simple configuration of the HTTP protocol using each GET instruction [Document] where Document represents a list of different documents research.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un procédé et un système de transmission de requêtes et de réponses HTTP d'accès à un objet HTML. Les mémoires caches réparties et mémoires caches coopérantes étant configurées comme mémoires caches de premier respectivement de deuxième niveau, le procédé, sur requête HTTP d'accès (1000) à un objet, consiste pour les mémoires caches réparties, en l'absence de cet objet, à transmettre une requête HTTP (1002) vers les mémoires caches coopérantes, lesquelles, à partir d'une mémoire cache coopérante locale, procèdent à une recherche (1004) dans les mémoires caches coopérantes voisines. Sur réception (1005) de l'objet, la mémoire cache coopérante locale transmet l'objet par réponse HTTP (1003, 1001) en l'absence de copie de sauvegarde. Sinon, une requête HTTP (1006) est transmise vers le serveur d'origine. Application à la gestion du réseau INTERNET et de l'interface W.W.W.

Description

INTERFONCTIONNEMENT ET SYSTEME DE CACHES COOPERANTS ET CACHES REPARTIS
L'invention concerne un procédé de transmission de requêtes HTTP d'accès à un objet, constitué de fichiers tels que des pages HTML, des images ou autres.
La transmission de messages, en particulier de fichiers tels que notamment les pages HTML, pour Hypertext Mark-up Language en langage anglo-saxon, ou pages WEB, sur le réseau INTERNET est actuellement confrontée à des problèmes de volume de trafic, et donc de débit de transmission de données, largeur de bande passante consommée et de temps d'attente. C'est en particulier le cas pour ce qui concerne le système W.W.W, World Web Wide en langage anglo-saxon, lequel permet couramment la transmission de documents hypertextes sous forme de pages HTML, d'images ou autres.
Une solution pour réduire ou résoudre ce problème consiste à utiliser, afin d'assister les serveurs d'origine, gestionnaires de ces objets dont ils assurent la diffusion, des mémoires caches implantées dans des systèmes d' interfaçage utilisateur/serveur, appelés "pro ies" en langage anglo-saxon. Ces proxies et mémoires caches tels que représentés en figure la font partie d'un ensemble appelé conjugué comportant un module d'analyse et de transformation HTML, Mi, un module d'anticipation M , un module M3 de conversion en ligne des documents et enfin la mémoire cache proprement dite M4.
D'une manière générale, les mémoires caches, ainsi que représenté en figure lb, jouent le rôle d'un serveur auxiliaire. Sur requête HTTP d'accès à un document, A, par le terminal utilisateur, la mémoire cache M4 renvoie le document, B, à ce dernier. Sinon, un message de requête, requête HTTP, est envoyé, C, de la mémoire cache M4 au serveur d'origine, lequel transmet en retour, D, le document demandé à la mémoire M4, grâce au proxy qui lui est associé, stocke une copie de ce document, après indexation, E, et transmet le contenu de ce document, F, au terminal utilisateur.
Afin d'améliorer la fonction de cache des mémoires précitées, des protocoles de gestion spécifique de ces mémoires caches ont été mis en œuvre, ces protocoles ayant avant tout pour objet, soit de conférer à ces mémoires caches des fonctions de mémoires caches réparties, soit de mémoires caches coopérantes. Parmi les protocoles de gestion les plus couramment utilisés, le protocole ICP pour Internet Caching Protocol et le protocole CARP pour Cache Array Routing Protocole en langage anglo-saxon, sont les plus répandus . Le protocole CARP, décrit à titre de pur exemple non limitatif, consiste essentiellement à mettre en œuvre un ensemble de plusieurs mémoires caches en réseau assorti d'une équi-répartition des documents mémorisés dans différents répertoires de ces dernières. Ce type de protocole est avant tout mis en œuvre dans le cadre d'une entreprise, le caractère en réseau du mode opératoire de ces mémoires ne nécessitant pas la mise en œuvre d'une copie de sauvegarde de chaque document dans chaque mémoire. En référence à la figure le, le protocole de gestion de chaque mémoire cache CARP comporte, suite à l'envoi et la réception d'une requête HTTP d'accès la, une vérification de cette requête, lb . Si la requête est vérifiée, une fonction de hachage est appliquée, le, pour retrouver la mémoire cache CARP détentrice du document. Dans le cas ld où cette mémoire cache dispose de ce document, ce dernier est transmis au" titulaire le. Sinon, un accès lf au serveur d'origine est effectué pour collecter le document et le cas échéant effectuer une copie de sauvegarde dans la mémoire cache CARP du réseau la plus appropriée. Le protocole ICP, décrit à titre de pur exemple non limitatif, consiste avant tout à localiser l'objet requis par le terminal utilisateur dans un groupe de mémoires caches coopérantes associées chacune à un proxy, la coopération des mémoires caches du groupe de mémoires caches coopérantes étant réalisée entre une mémoire cache coopérante locale, mémoire réceptrice de la requête HTTP d'accès émise par le terminal client, et les mémoires caches coopérantes du groupe, appelées mémoires caches coopérantes voisines. Ces dernières sont subdivisées, par ordre hiérarchique, en mémoires caches coopérantes parentes et semblables (sibling en langage anglo-saxon) . La fonction des mémoires caches coopérantes parentes et semblables ne sera pas décrite en détail car elle est connue en tant que telle de l'état de la technique. En référence à la figure ld, le protocole de gestion de chaque mémoire cache ICP comporte des étapes 2a, de réception de la requête HTTP d'accès au document et de vérification 2b, de la requête par la mémoire cache coopérante locale. Lorsque la requête est vérifiée, une requête ICP est lancée, 2c, de la mémoire cache coopérante locale vers les mémoires caches coopérantes voisines du groupe. Si le document est trouvé dans ces dernières, ce document est transmis au terminal utilisateur et la mémoire cache coopérante locale effectue une copie de sauvegarde de ce dernier, 2f. Sinon, la mémoire cache coopérante locale transmet, 2e, un message de requête au serveur d'origine, lequel transmet le document recherché à la mémoire cache coopérante locale. L'étape 2f est alors réalisée .
Le protocole ICP donne satisfaction mais, alors qu'en l'absence du document recherché dans les mémoires caches coopérantes voisines, aucun message de réponse n'est transmis à la mémoire cache coopérante locale, l'interrogation du serveur d'origine est lancée par cette dernière au bout d'un temps déterminé, générateur d'un retard global d'ensemble. En outre, le document requis est systématiquement sauvegardé au niveau de la mémoire cache coopérante locale, ce qui finalement, pour toutes les mémoires caches coopérantes du groupe, impose en outre la fourniture de moyens de mémoire de masse importants et la gestion de ces derniers.
La simple association de mémoires caches réparties et de mémoires caches coopérantes par juxtaposition dans un réseau, ne peut être directement envisagée. En effet, alors que les mémoires caches réparties impliquent une succession d'opérations au niveau local, les mémoires caches coopérantes impliquent une succession d'opérations au niveau étendu, dans le groupe, ainsi que l'existence de la mise en œuvre systématique d'une copie de sauvegarde du document dans la mémoire cache coopérante locale, en l'absence préalable de celui-ci dans cette dernière, implique une surcharge importante de temps machine et d'occupation mémoire.
La présente invention a pour objet de remédier aux inconvénients des protocoles de gestion de mémoires caches précités par la mise en œuvre d'un procédé de transmission de requêtes HTTP d'accès à un objet, au moyen de mémoires caches réparties et coopérantes, dans lesquels les inconvénients de l'utilisation, séparée, des protocoles de gestion des mémoires caches réparties et coopérantes sont supprimés .
En particulier, un autre objet de la présente invention est la mise en œuvre d'un procédé de transmission de requêtes HTTP d'accès à un objet à partir des protocoles de gestion des mémoires caches réparties et coopérantes dans lequel ces protocoles sont adaptés l'un à l'autre et réciproquement.
En conséquence, un autre objet de la présente invention est le mise en œuvre d'un procédé de transmission de requêtes HTTP d'accès à un objet à partir des protocoles de gestion des mémoires caches réparties et coopérantes dans lequel les interfaces de communication de chacun de ces protocoles et les mécanismes ou modes opératoires de ces protocoles sont réciproquement adaptés l'un à l'autre. Un autre objet de la présente invention est la mise en œuvre d'un procédé de transmission de requêtes HTTP d'accès à un objet constitué par des pages HTML dans lequel l'espace mémoire nécessaire à chaque mémoire cache coopérante est optimisé. Un autre objet de la présente invention est, enfin, la mise en œuvre d'un procédé de transmission de requêtes HTTP d'accès à un objet, constitué par des pages HTML, dans lequel le nombre d'accès au serveur d'origine et l'encombrement du réseau sont sensiblement réduits.
Le procédé de transmission de requêtes HTTP d'accès à un objet, constitué de fichiers tels que des pages HTML, des images ou autres gérées par un serveur d'origine, entre un terminal utilisateur, des mémoires caches réparties coopérantes et ce serveur d'origine, objet de la présente invention, est remarquable en ce qu'il consiste à configurer les mémoires caches réparties comme mémoires caches de premier niveau, ces mémoires étant adaptées à recevoir et émettre des requêtes et des réponses HTTP relatives à cet objet et à mémoriser cet objet sur critère de gestion de mémoire et à configurer les mémoires caches coopérantes comme mémoires caches de deuxième niveau. Sur requête HTTP d'accès à cet objet émise par le terminal utilisateur, les mémoires caches réparties sont adaptées à recevoir cette requête, et, en présence de cet objet dans ces dernières, à transmettre au terminal utilisateur une réponse HTTP de transmission de cet objet. En l'absence de cet objet dans ces dernières, celles-ci sont adaptées à transmettre vers une mémoire cache coopérante locale une requête HTTP d'accès à cet objet . En présence de cet objet dans cette mémoire cache coopérante locale, ce dernier est transmis vers les mémoires caches réparties, puis vers le terminal utilisateur. En l'absence de cet objet dans la mémoire cache coopérante locale, un message de recherche de cet objet est transmis de cette dernière vers les mémoires caches coopérantes voisines. En présence de cet objet dans ces dernières, cet objet est transmis des mémoires caches coopérantes voisines vers la mémoire cache coopérante locale, en l'absence de copie de sauvegarde de cet objet dans cette dernière, puis vers les mémoires réparties et le terminal utilisateur. En l'absence de cet objet dans ces dernières, une requête HTTP d'accès à cet objet est transmise de cette mémoire cache coopérante locale vers le serveur d'origine. Une réponse HTTP contenant cet objet est ensuite transmise vers la mémoire cache coopérante locale, les mémoires caches réparties et le terminal utilisateur .
Ce mode opératoire permet de réduire le nombre d'accès et le temps d'occupation du serveur d'origine.
Il sera mieux compris à la lecture de la description et à l'observation des dessins ci-après dans lesquels, outre les figures la, lb, le et ld relatives à l'art antérieur :
- la figure 2a représente un organigramme général illustratif du procédé, objet de la présente invention ; - la figure 2b représente, sur une configuration matérielle correspondant à l'interconnexion des mémoires caches réparties en réseau et de mémoires caches coopérantes, les étapes essentielles mises en œuvre par le processus de coopération entre mémoires caches réparties et mémoires caches coopérantes configurées en mémoires caches de premier et de deuxième niveau respectivement, conformément au procédé objet de l'invention tel que représenté en figure 2a ;
- la figure 2c représente un organigramme plus détaillé des étapes mises en œuvre par le processus de coopération entre mémoires caches réparties et mémoires caches coopérantes configurées en mémoires caches de premier et de deuxième niveau respectivement, conformément au procédé objet de la présente invention tel que représenté en figure 2a et 2b ; - la figure 3a représente, à. titre d'exemple non limitatif, la structure d'une mémoire cache coopérante locale conforme à l'objet de la présente invention ;
- la figure 3b représente un mode de réalisation particulier non limitatif de la mémoire cache coopérante locale représentée en figure 3a ;
- la figure 4 représente, à titre d'exemple non limitatif, la structure d'une mémoire cache coopérante locale conforme à l'objet de la présente invention, dans laquelle la fonction de répartition d'un objet dans les mémoires caches réparties est en outre implantée ;
- les figures 5 et 6 représentent une structure préférentielle d'une mémoire cache coopérante locale, particulièrement adaptée à une gestion des requêtes HTTP et requêtes ICP à partir d'une base de données en mode vignette, et une telle vignette respectivement, une vignette étant associée à une requête HTTP ou à une requête ICP, afin d'assurer une gestion optimisée de la recherche et de la transmission du document requis par le demandeur ; - la figure 7 représente une variante de réalisation de la figure 5, dans laquelle la base de données, externe à la mémoire cache coopérante locale, est gérée par l'intermédiaire du protocole de gestion des mémoires caches coopérantes ; - la figure 8 représente, dans le cas d'une mémoire cache coopérante locale conforme à l'objet de la présente invention telle que représentée en figure 5 ou 7 , un processus préférentiel de gestion des requêtes HTTP respectivement ICP reçues par cette mémoire cache coopérante locale. Une description plus détaillée du procédé de transmission de requêtes HTTP d'accès à un objet constitué de fichiers tels que des pages HTML, des images ou autres, objet de la présente invention, sera maintenant donnée en liaison avec les figures 2a à 2c. D'une manière générale, on indique que le procédé, objet de la présente invention, a pour objet d'assurer la transmission de requêtes HTTP d'accès à l'objet précité, cet objet et les pages HTML correspondantes par exemple étant gérés par un serveur d'origine afin de permettre l'obtention de réponses HTTP contenant cet objet par l'utilisateur auteur de la requête d'accès précitée. La requête est effectuée par ce dernier à partir d'un terminal utilisateur et les requêtes HTTP et réponses HTTP correspondantes, mises en œuvre par le procédé objet de la présente invention ainsi que représenté en figure 2a, interviennent entre l'utilisateur précité, des mémoires caches réparties, gérées selon un protocole de gestion de mémoires caches réparties, et des mémoires caches coopérantes gérées selon un protocole de gestion de mémoires caches coopérantes.
Les mémoires caches réparties sont interconnectées en réseau et peuvent constituer par exemple des mémoires caches d'un réseau d'entreprise ou analogue.
Les mémoires caches coopérantes comportent au moins une mémoire cache coopérante locale, laquelle est réputée recevoir la requête HTTP relative à un objet, et des mémoires caches coopérantes voisines et les mémoires caches réparties étant interconnectées en réseau au serveur d'origine.
Selon un aspect particulièrement remarquable du procédé, objet de la présente invention, ainsi que représenté en figure 2a, les mémoires caches réparties sont configurées comme mémoires caches de premier niveau, ces mémoires caches réparties étant adaptées à recevoir du terminal utilisateur des requêtes HTTP et à émettre vers la mémoire cache coopérante locale des requêtes et à recevoir des réponses HTTP relatives à cet objet. En outre, les mémoires caches réparties sont adaptées de manière à mémoriser, sur critère de gestion de mémoire, l'objet précité. Un critère de gestion de mémoire classique peut consister en une équi-répartition en volume des données mémorisées au niveau de chaque mémoire cache répartie. L'ensemble des mémoires caches réparties est de ce fait interconnecté en réseau, chaque mémoire cache répartie ne comportant ainsi pas les mêmes documents mémorisés dans ces dernières. Le critère de gestion de mémoire des mémoires réparties et en particulier la fonction de répartition des objets constitués par les pages HTML les plus fréquemment demandés par l'utilisateur ne seront pas décrits en détail car ils correspondent à des processus mis en œuvre couramment dans la technique, en particulier dans le cas où les mémoires réparties sont gérées selon le protocole de gestion CARP.
Selon un autre aspect remarquable du procédé, objet de la présente invention, celui-ci consiste à configurer les mémoires caches coopérantes comme mémoires caches de deuxième niveau. Le mode opératoire du procédé, objet de la présente invention, entre mémoires caches réparties et mémoires caches coopérantes est alors le suivant, en référence à la figure 2a. Sur requête HTTP émise en une étape 1000 par le terminal utilisateur en vue d'une demande d'accès à un document donné, cette requête est reçue par les mémoires caches réparties connectées en réseau et formant les mémoires de premier niveau. En présence de l'objet considéré dans les mémoires caches réparties, le procédé, objet de la présente invention, consiste à transmettre au terminal utilisateur, en une étape 1001, une réponse HTTP de transmission de cet objet. En l'absence de cet objet dans les mémoires caches réparties, le procédé, objet de la présente invention, consiste au contraire à transmettre vers la mémoire cache coopérante locale une requête HTTP d'accès à cet objet. On rappelle que, par définition, la mémoire cache coopérante locale est celle qui est destinée à recevoir la requête relative à un objet donné de la part d'un réseau constitué par un ensemble de mémoires caches réparties. Cette transmission est effectuée par simple adressage déterminé à partir d'une mémoire cache répartie spécifique. Ce mode opératoire, connu en tant que tel, ne sera pas décrit en détail pour cette raison. La requête 1002, requête HTTP représentée en figure 2a, consiste ainsi à transmettre une requête d'accès au document considéré de l'ensemble des mémoires de premier niveau aux mémoires de second niveau constituées par les mémoires caches coopérantes. Selon un premier aspect du procédé, objet de la présente invention, en présence de cet objet dans la mémoire cache coopérante locale, celui-ci consiste à transmettre, en une étape 1003, constituant une réponse HTTP, de la mémoire cache coopérante locale vers les mémoires caches réparties, l'objet considéré puis, bien entendu, vers le terminal utilisateur par une réponse HTTP analogue à la réponse 1001 précédemment mentionnée.
Au contraire, en l'absence de cet objet dans la mémoire cache coopérante locale, le procédé, objet de la présente invention, consiste à transmettre de cette mémoire cache coopérante locale vers les mémoires caches coopérantes voisines, un message de recherche MR de cet objet, en une opération 1004. En présence de cet objet dans les mémoires caches coopérantes voisines précitées, le procédé consiste alors, en une étape 1005, à transmettre cet objet des mémoires caches coopérantes voisines vers la mémoire cache coopérante locale. Cette opération réalisée, et conformément à un aspect particulièrement avantageux du procédé, objet de la présente invention, aucune copie de sauvegarde de cet objet dans la mémoire cache coopérante locale n'est alors effectuée, contrairement au protocole de gestion des mémoires caches coopérantes tel que le protocole ICP. Suite à l'étape 1005 précitée, l'objet est alors transmis vers les mémoires caches réparties et le terminal utilisateur par des étapes analogues aux étapes 1003 et 1001 précédemment mentionnées dans la description.
En l'absence de cet objet dans les mémoires caches coopérantes voisines, le procédé, objet de la présente invention, consiste à transmettre une requête HTTP d'accès à cet objet de la mémoire cache coopérante locale vers le serveur d'origine, étape 1006 représentée sur la figure 2a réalisée par l'intermédiaire du réseau Internet et plus particulièrement du W.W.W, système HYPERMEDIA distribué précédemment mentionné dans la description. Suite à cet accès au serveur d'origine, une réponse HTTP 1007 contenant l'objet est alors transmise du serveur d'origine vers la mémoire cache coopérante locale par l'intermédiaire du W.W.W. puis vers les mémoires caches réparties par l'intermédiaire d'une réponse HTTP analogue à la réponse 1003 précédemment décrite, et enfin, vers le terminal utilisateur par l'intermédiaire d'une réponse HTTP 1001 précédemment décrite.
Ainsi, et en référence à la figure 2a, on indique que selon le procédé, objet de la présente invention, les mémoires caches de premier niveau constituées par les mémoires caches réparties reçoivent la requête d'accès HTTP émise par l'utilisateur, vérifient l'existence locale du document demandé dans les mémoires caches réparties précitées. En cas de non-existence de ce document dans ces dernières, les mémoires caches de premier niveau transmettent une requête aux mémoires de second niveau, lesquelles sont constituées par les mémoires caches coopérantes mettant en œuvre un protocole de gestion allégé, en raison de l'absence de réalisation d'une copie de sauvegarde de document au niveau de la mémoire cache coopérante locale, de manière à localiser le document dans les mémoires caches coopérantes voisines.
En particulier, on indique qu'il n'est pas nécessaire au niveau des mémoires caches de deuxième niveau, c'est-à-dire des mémoires caches coopérantes locales, de vérifier la requête transmise par l'utilisateur, puisque cette vérification a déjà été effectuée par les mémoires caches réparties constituant les mémoires caches de premier niveau.
Dans le cas où le document est trouvé dans les mémoires caches voisines, ce document est alors simplement retourné vers la mémoire cache coopérante locale, laquelle peut alors être configurée de façon à ne pas procéder à la copie de sauvegarde ainsi que mentionné précédemment mais, au contraire, de façon à simplement transmettre ce document vers les mémoires caches de premier niveau, lesquelles permettent alors de transférer ce même document vers l'utilisateur, après bien entendu avoir effectué une copie de sauvegarde de ce document, conformément au critère de gestion de mémoire des mémoires caches réparties précédemment mentionné dans la description. On comprend ainsi que la mémoire cache coopérante locale joue le rôle d'un simple système de transfert en l'absence de mémorisation et de stockage d'une copie de sauvegarde .
Ainsi, conformément à un aspect particulièrement remarquable du procédé, objet de la présente invention, et dans le but d'assurer la compatibilité entre mémoires caches de premier et de second niveau, les mémoires caches coopérantes, en particulier la mémoire cache coopérante locale, peuvent être modifiées dans leur configuration de façon à effectuer simplement le transfert des données support du document recherché qui était mémorisé, soit dans l'une des mémoires caches coopérantes voisines, soit, le cas échéant, dans un autre réseau de mémoires caches réparties . Dans ces conditions, on notera selon un aspect particulièrement remarquable du procédé, objet de la présente invention, que le document précité peut alors être stocké, soit dans une mémoire de masse lorsque la mémoire cache coopérante locale est munie d'une telle mémoire de masse, soit, au contraire, de manière externe à cette mémoire cache coopérante locale, lorsque cette dernière n'est pas munie d'une mémoire de masse. Dans ce dernier cas, et conformément à un aspect particulièrement remarquable du procédé, objet de la présente invention, les mémoires caches réparties apparaissent particulièrement adaptées à la réalisation de la fonction de stockage de la copie de sauvegarde.
Une description plus détaillée d'un mode de mise en œuvre spécifique du procédé, objet de la présente invention, sera maintenant donnée dans un exemple non limitatif dans le cas où les mémoires caches réparties sont gérées selon le protocole CARP et les mémoires caches coopérantes par l'intermédiaire d'un protocole de gestion de type ICP, en référence à la figure 2b.
Sur la figure 2b, on a représenté les mémoires caches de premier niveau, mémoires réparties, constituées à titre d'exemple purement illustratif, par trois mémoires caches réparties référencées RCMi, RCM2, RCM3, ces mémoires étant par exemple gérées selon le protocole CARP.
De même, on a représenté les mémoires caches coopérantes du deuxième niveau comme constituées par une mémoire cache coopérante locale CCMi, des mémoires caches coopérantes voisines constituées par une mémoire cache coopérante semblable notée CCM2 et une mémoire cache coopérante parente notée CCM3. Les mémoires caches coopérantes voisines semblable et parente et la mémoire cache coopérante locale sont réputées gérées par le protocole ICP. Les mémoires caches coopérantes locale et voisine sont interconnectées en réseau et le réseau de ces dernières est également interconnecté, d'une part, au réseau des mémoires caches réparties de premier niveau ainsi qu'au réseau Internet, c'est-à-dire au système d'interface Hypermedia W.W.W et ainsi au serveur d' origine.
Sur la figure 2b, les requêtes et réponses HTTP émises par ou vers l'utilisateur 1000, 1001, par ou vers les mémoires caches de premier niveau 1002, 1003, par ou vers la mémoire cache coopérante locale 1004 et 1005 et 1006, 1007, portent les mêmes références que celles indiquées dans la figure 2a. On comprend en outre que dans le cas de l'existence de plusieurs mémoires caches coopérantes voisines, la mémoire cache coopérante locale CCMi, avant de procéder à l'envoi de la requête HTTP 1006 vers le serveur d'origine, peut avantageusement procéder à une exploration de chaque mémoire cache coopérante voisine, c'est-à-dire de la mémoire semblable CCM2 et de la mémoire parente CCM3. Par convention et sans présumer du routage effectif de l'une et l'autre des requêtes, on a représenté les différentes requêtes acheminées par une seule et même voie afin de ne pas surcharger le dessin, étant entendu que la requête HTTP 1006 et la réponse HTTP 1007, lesquelles ne sont pas adressées à la mémoire parente CCM3, ne sont aucunement perturbées dans leur transmission par cette dernière.
Ainsi que représenté sur la figure 2b, on indique que selon un aspect particulièrement avantageux du procédé, objet de la présente invention, celui-ci peut consister à communiquer à la mémoire cache coopérante locale, la mémoire CCMi, une information, notée CCR, relative à la répartition du contenu des mémoires caches réparties. Dans le cas où une telle information consiste en une mise en correspondance biunivoque d'une adresse de chaque mémoire cache répartie RCMi à RCM3 et du contenu de ces dernières, ce contenu permettant d'identifier les documents mémorisés par chacune d'elles, la mémoire cache coopérante locale CCMi est ainsi en mesure, à partir de cette information, d'assurer directement la gestion des documents correspondants vers la mémoire cache répartie la plus appropriée.
En outre, ainsi que représenté également sur la figure 2b de manière non limitative, le procédé, objet de la présente invention, peut consister à mémoriser, au niveau de la mémoire cache coopérante locale CCMi, un index de contenu IC de cet objet, cet index étant représentatif d'une adresse du contenu de cet objet, adresse de mémorisation de ce dernier. Cet index peut, ainsi que mentionné précédemment, être lié à l'information relative à la répartition du contenu des mémoires caches réparties .
Enfin, dans un autre mode de réalisation non limitatif avantageux, ainsi que représenté en figure 2b, le procédé, objet de la présente invention, consiste en outre à communiquer à la mémoire cache coopérante locale CCMi la fonction de répartition FR des mémoires caches réparties. Dans un tel cas, il est possible de délocaliser, au moins pour partie, la fonction de gestion des mémoires caches réparties au niveau de la mémoire cache coopérante locale CCMi, cette dernière pouvant alors dans ce cas être adaptée à partir de la fonction de 18
répartition précitée, notée FR sur la figure 2b, d'établir l'existence ou la non-existence de l'objet dans les mémoires caches réparties et d'assurer la transmission d'un document à mémoriser dans ces dernières vers l'adresse de la mémoire cache répartie RCMi à RCM3 la mieux adaptée.
Une description plus détaillée du procédé, objet de la présente invention, lorsque ce dernier est mis en œuvre à partir de mémoires caches de premier niveau gérées selon le protocole CARP et de mémoires caches de deuxième niveau gérées selon le protocole ICP, sera maintenant donnée en liaison avec la figure 2c dans le cadre plus spécifique de l'échange entre mémoires caches réparties de premier niveau et mémoires caches coopérantes de deuxième niveau. Sur la figure 2c, les références relatives aux requêtes et réponses HTTP ont été reproduites en référence à la figure 2b.
Suite à la réception de la requête HTTP d'accès du client ou utilisateur aux mémoires caches réparties CARP à l'étape 1000, le procédé, objet de la présente invention, peut alors consister, au niveau de l'une des mémoires caches réparties RCMi à RCM3 à l'étape 2000, en une étape de vérification de la requête formulée par ce dernier. Cette étape de vérification de requête 2000 est suivie d'une étape 2001 de la valeur vraie de cette vérification. En cas de réponse négative au test 2001, une étape 2002 consistant en le processus A précédemment décrit dans la description, lequel permet de gérer le défaut de vérification à la valeur vraie. Sur réponse positive au test 2001, une étape 2003 est réalisée par la mémoire cache répartie précitée, 19
laquelle consiste à appliquer une fonction de hachage pour assurer, en l'absence du document dans l'une des mémoires caches réparties, la transmission de la requête HTTP 1002 vers la mémoire cache coopérante locale CCMi . L'étape 2003 est elle-même suivie d'une étape 2004 consistant à vérifier la présence de ce document dans la mémoire cache coopérante locale CCMi. Sur réponse positive au test 2004, une étape 2005 est prévue, consistant en une réponse au client, c'est-à-dire à l'utilisateur, laquelle met en œuvre les étapes 1003 et 1001 précédemment mentionnées en liaison avec la figure 2b.
Sur réponse négative au test 2004, une étape 2006 est prévue, laquelle consiste en un envoi d'un message de recherche MR, message 1004 de la figure 2b, aux mémoires caches coopérantes voisines. On rappelle que la transmission de ce message de recherche peut être effectuée dans le cas où les mémoires caches coopérantes de deuxième niveau sont gérées par le protocole ICP par une procédure GET . On rappelle également que la procédure 2006, c'est-à-dire l'envoi du message de recherche MR lors de l'opération 2004, peut être effectuée pour l'ensemble des mémoires caches coopérantes voisines ainsi que mentionné précédemment dans la description.
La procédure d'envoi de message de recherche MR 2006 précitée est elle-même suivie d'une étape de test 2007 consistant à déterminer, au niveau de la mémoire cache coopérante locale CCMi, si le document recherché a été trouvé. Si tel n'est pas le cas, c'est-à-dire en réponse négative au test 2007, l'étape d'envoi d'une requête HTTP d'accès au serveur d'origine, étape 1006, est réalisée et, en conséquence, l'étape de réponse HTTP 1007 est également réalisée vers la mémoire cache coopérante locale CCMX .
Le document recherché ayant été trouvé soit auprès des mémoires caches coopérantes voisines, soit auprès du serveur d'origine, la réponse au test 2007 est positive et suivie d'une étape 2008, laquelle consiste en la transmission du document recherché de la mémoire cache coopérante locale aux mémoires caches réparties, puis au terminal utilisateur selon les étapes 1003 et 1001 précédemment décrites en liaison avec la figure 2b.
On a ainsi décrit un procédé de transmission de requêtes HTTP d'accès à un objet constitué par des pages HTML particulièrement performant dans la mesure où, grâce à la mise en œuvre d'une hiérarchisation de mémoires caches réparties, mémoires de premier niveau, et de mémoires caches coopérantes, mémoires de second niveau, et en particulier en introduisant une légère modification du protocole de gestion des mémoires caches de second niveau lorsque le protocole de gestion utilisé est le protocole ICP, la réalisation de certaines tâches au sein des mémoires caches de premier niveau permet de supprimer la réalisation de tâches semblables dans les mémoires caches coopérantes de deuxième niveau. Cette approche est particulièrement remarquable en ce qui concerne la sauvegarde d'un document recherché lorsque ce document est présent dans les mémoires caches de premier niveau. En particulier, la suppression de la réalisation d'une copie de sauvegarde de ce document dans les mémoires caches de deuxième niveau est essentielle pour assurer la compatibilité entre les mémoires caches de premier niveau, mémoires caches réparties, et les mémoires caches de deuxième niveau, mémoires caches coopérantes.
Ainsi, le procédé, objet de la présente invention, permet-il de récupérer tout document demandé par une requête HTTP par l'intermédiaire des mémoires caches de deuxième niveau en l'absence de réalisation de copie de sauvegarde au niveau de ces dernières. Un tel mode opératoire permet en particulier une simplification de la gestion des mémoires caches de deuxième niveau et, notamment, de mise en œuvre de ces dernières, toute mémoire de masse pouvant être supprimée.
Le procédé, objet de la présente invention, permet bien entendu de maintenir l'accès à des bases de données lointaines, c'est-à-dire au serveur d'origine, dans des conditions semblables au procédé de gestion de mémoires de premier niveau, procédé de gestion CARP, et procédé de gestion des mémoires caches coopérantes de deuxième niveau, procédé protocole de gestion ICP.
Le procédé objet de l'invention permet également l'application d'une fonction de hachage utilisée pour la gestion des mémoires caches réparties, de premier niveau, pour permettre l'allocation de documents requis par une mémoire cache ICP externe, ce mode opératoire constituant un facteur de compatibilité du procédé, objet de la présente invention, vis-à-vis des protocoles de gestion existants .
Les éléments nécessaires à la mise en œuvre du procédé, objet de la présente invention, peuvent être implémentés sous forme d'instructions dans le BIOS du système d'exploitation du processeur équipant le proxy géré par le protocole de gestion ICP dans le cas où celui- ci ne comporte pas de mémoire de masse.
Si au contraire une mémoire de masse est présente, alors, des données relatives à la gestion des mémoires caches réparties de premier niveau peuvent être mémorisées au niveau de cette mémoire de masse, bien que la réalisation d'une copie de sauvegarde ne soit pas nécessaire .
Enfin, le protocole de gestion des mémoires réparties, lorsque ce protocole de gestion est le protocole CARP, peut également être modifié si nécessaire.
La mise en œuvre du procédé, objet de la présente invention, permet ainsi d'obtenir des avantages essentiels tels que le maintien de l'équilibre des charges et des performances offertes par le protocole de gestion CARP tout en conservant le bénéfice des avantages du protocole de gestion ICP pour la localisation de documents non- existants dans les mémoires caches voisines, sans qu'il soit nécessaire d'avoir systématiquement accès au serveur d'origine.
Un autre avantage du procédé, objet de la présente invention, consiste également dans le fait de l'absence de nécessité d'espace mémoire de masse en raison de l'absence d'exécution d'une copie de sauvegarde au niveau de la mémoire cache coopérante locale.
La mise en œuvre du procédé, objet de la présente invention, a révélé une amélioration de 30% des performances de l'ensemble vis-à-vis de la seule utilisation du protocole de gestion CARP. Une description plus détaillée d'un système de mémoires caches particulièrement adapté à la mise en œuvre du procédé, objet de la présente invention, sera maintenant donnée en liaison avec la figure 2b et les figures 3a, 3b et suivantes.
En référence à la figure 2b, on rappelle que les mémoires caches réparties de premier niveau portent les références RCMi à RCM3 et que les mémoires caches coopérantes de deuxième niveau portent les références CCMi pour la mémoire cache coopérante locale, CCM2 pour une mémoire cache coopérante semblable et CCM3 pour une mémoire cache coopérante parente, l'ensemble de ces mémoires caches coopérantes constituant des mémoires caches coopérantes de deuxième niveau.
Selon un aspect particulièrement remarquable du système de mémoires caches, objet de la présente invention, on indique que les mémoires caches réparties de premier niveau RCMi à RCM3 assurent le partage de la fonction cache vis-à-vis du serveur d'origine. On comprend en particulier que les mémoires caches réparties de premier niveau assurent le partage de la fonction cache vis-à-vis du serveur d'origine représenté en figure 2b, mais également vis-à-vis de tout serveur interrogé par le terminal utilisateur non représenté au dessin.
Selon un autre aspect particulièrement remarquable du système de mémoires caches, objet de la présente invention, les mémoires caches coopérantes de deuxième niveau assurent prioritairement la transmission des requêtes HTTP, des réponses à ces requêtes et la transmission de l'objet requis par le terminal utilisateur à partir d'une autre mémoire cache coopérante de deuxième niveau ou du serveur d'origine précédemment cité. On comprend en effet que par le jeu de la connexion en réseau de l'ensemble des mémoires caches précitées, les mémoires caches coopérantes permettent, par le protocole de gestion de ces mémoires caches coopérantes, le protocole ICP ainsi que mentionné précédemment dans la description à titre illustratif, de rechercher et de transmettre le document requis, soit au niveau du serveur d'origine, soit au niveau d'un ensemble de mémoires caches réparties de premier niveau.
Ainsi, selon une caractéristique particulièrement remarquable du système de mémoires caches, objet de la présente invention, les mémoires caches réparties de premier niveau assurent la gestion descendante de chaque requête HTTP non satisfaite, requête 1000 sur la figure 2b, vers les mémoires caches coopérantes de deuxième niveau, et l'ensemble du processus décisionnel relatif à la sauvegarde répartie de l'objet requis dans les mémoires caches réparties de premier niveau RCMi à RCM3.
Compte tenu du système de mémoires caches et du procédé de gestion de ces mémoires caches conformes à l'objet de la présente invention, il est alors possible, dans un mode de réalisation préférentiel non limitatif des mémoires caches coopérantes locales, telles que la mémoire CCMi par exemple, de définir une structure préférentielle non limitative telle que représentée en figure 3a. Conformément au système de mémoires caches, objet de la présente invention, chaque mémoire cache coopérante locale telle que la mémoire CCMi appartenant aux mémoires caches coopérantes de deuxième niveau peut ainsi comprendre une unité de calcul, notée 1, et une mémoire morte, notée 2. L'unité de calcul 1 comprend, de manière avantageuse, un microprocesseur ou un microcontrôleur, noté CCPU, lequel est interconnecté à une mémoire vive RAM. La mémoire morte 2 de type ROM est également connectée à l'unité de calcul 1, et de manière plus spécifique au microprocesseur ou au microcontrôleur. La mémoire morte peut être une mémoire morte de type ROM accessible uniquement en lecture ou, le cas échéant et de préférence, une mémoire morte reprogrammable électriquement, dite de type REPROM. Enfin, une unité d'entrée/sortie 3, notée I/O, est prévue, laquelle est reliée également par une liaison par BUS à l'unité de calcul 1.
Dans la structure telle que représentée de manière non limitative en figure 3a, on indique que la mémoire cache coopérante locale CCMi permet ainsi d'assurer la transmission des requêtes HTTP, des réponses à ces requêtes et la transmission de l'objet en l'absence de mémoire de sauvegarde de cet objet.
Dans un autre mode de réalisation spécifique tel que représenté en figure 3b, chaque mémoire cache coopérante locale, telle que la mémoire CCMi représentée en figure 2b et appartenant aux mémoires caches coopérantes de deuxième niveau, peut avantageusement comprendre, dans la mémoire morte 2, une série d'instructions permettant la mise en œuvre d'un protocole interactif d'accès aux données mémorisées des mémoires caches réparties de premier niveau. Dans ce but, et de manière non limitative ainsi que représenté sur la figure 3b, à la mémoire cache coopérante locale CCMi est en outre associée une base de données interne contenant un index des documents mémorisés au niveau des mémoires caches réparties RCMi à RCM3. Ainsi que représenté sur la figure 3b, et en référence aux notations précédentes, 1007 représente une requête ICP provenant d'une mémoire cache coopérante externe non représentée en figure 2b, 1007a représente une requête de la mémoire cache coopérante locale CCMi à la base de données interne, 1007b représente la réponse de la base de données interne à la mémoire cache coopérante locale CCMi .
Si l'index relatif au document a été trouvée, une réponse ICP contenant les données d'index est engendrée en 1006 par la mémoire cache coopérante locale CCMi . On comprend que l'index précité comporte une indication relative au document et une indication relative à la mémoire cache comportant ce document. Au contraire, lors de la réception d'une requête
HTTP provenant du terminal utilisateur, requête notée 1000 sur la figure 3b, chaque requête HTTP peut elle-même être munie d'un index correspondant au format des index contenus dans la base de données interne. Les réponses à la requête HTTP 1000 portent les références 1003, 1002 et 1001 ainsi que représenté en figure 2b. La mise à jour de la base de données interne peut être effectuée à partir des mémoires caches réparties RCMi à RCM3 par un signal de synchronisation. Dans un mode de réalisation spécifique tel que représenté en figure 4, chaque mémoire cache coopérante locale, telle que la mémoire CCMi, comporte en outre dans la mémoire morte 2 précédemment mentionnée la fonction de répartition de cet objet dans les mémoires caches réparties de premier niveau. Sur la figure 4, on a représenté la fonction de répartition FR comme consistant en un ensemble de données numériques FRi, FR2, FR3 mémorisées dans la mémoire morte 2 précitée, cette mémoire morte étant dans ce cas constituée par une mémoire reprogrammable électriquement. La fonction de répartition comprend un index relatif au document mémorisé dans chaque mémoire cache répartie RCMi, RCM2, RCM3, et une adresse de mémorisation dans chaque mémoire correspondante en fonction des disponibilités de chaque mémoire cache répartie. On rappelle que la gestion des mémoires caches réparties est effectuée selon une procédure de gestion connue en tant que telle, cette gestion étant assurée par exemple selon le protocole CARP précédemment mentionné dans la description. La mémoire cache coopérante locale CCMi est alors en mesure, à partir d'une fonction de hachage, de rechercher chaque objet ou document sauvegardé dans les mémoires caches réparties de premier niveau, et requis par une requête ICP par exemple, par adressage direct des mémoires caches réparties RCMx à RCM3 précitées. Sur la figure 4, la notion d'adressage direct est symbolisée par les flèches reliant directement la fonction de répartition FR par l'intermédiaire de la fonction de hachage à chaque mémoire cache répartie précitée .
Bien entendu, la constitution d'une base de données interne au niveau de chaque mémoire cache coopérante locale peut être envisagée. Toutefois, l'introduction d'une telle base de données interne, laquelle doit être intégrée comme un module spécifique de la mémoire cache coopérante locale, implique l'adjonction d'une mémoire non volatile reprogrammable telle qu'une mémoire utilisée dans les cartes à microprocesseurs par exemple afin d'assurer la mise à jour de l'ensemble. Une telle mémoire n'est pas représentée en figure 3a mais peut correspondre à celle qui est nécessaire à la mise en œuvre de la base de données interne représentée sur la figure 3b.
Afin de remédier à l'inconvénient précité et conformément à un aspect particulièrement remarquable du système de mémoires caches, objet de la présente invention, tel que représenté en figure 5, la base de données associée à ce système de mémoires caches peut être externe. Dans un tel cas, la base de données n'est plus localisée au niveau de la mémoire cache coopérante locale CCME par exemple, mais peut être implantée sur un endroit quelconque du réseau. Dans un tel cas, un mode de gestion des requêtes
HTTP et requêtes ICP en mode vignette est préférentiellement mis en œuvre. On indique que la notion de vignette correspond sensiblement à celle d'index pour la base de données interne, à la différence que chaque vignette est ainsi associée à une requête HTTP ou à une requête ICP afin de gérer les adresses des mémoires caches réparties contenant le document recherché.
En tout état de cause, la base de données externe contient un fichier indexé du contenu des mémoires caches réparties de premier niveau représentées par RCMj., RCM2 et RCM3 sur la figure 5.
Sur requête HTTP 1000, cette requête étant munie d'une vignette contenant au moins un index d'identification du document ou objet recherché, index noté ID-OBJ, la recherche du document est transmise par une requête HTTP 1003 aux mémoires caches réparties précitées. Sur réponse positive, le document étant trouvé dans l'une des mémoires caches précitées en référence au numéro d'identification ID-OBJ de ce document, une réponse HTTP 1002 est renvoyée vers le terminal utilisateur. Si le document n'est pas trouvé dans les mémoires caches réparties précitées, une requête ICP est envoyée par la mémoire cache coopérante locale CCMi vers la base de données externe. La base de données externe peut être reliée à la mémoire cache coopérante locale, soit par l'intermédiaire d'un protocole interactif, noté 1008a, 1008b, lorsque la base de données externe est sur un même site que la mémoire cache coopérante locale, soit par le protocole de gestion des mémoires caches coopérantes, protocole ICP, lorsque la base de données n'est pas située au voisinage de la mémoire cache coopérante locale, ainsi qu'il sera décrit ultérieurement dans la description. L'interrogation de la base de données externe précitée permet alors de compléter la vignette à partir des données contenues dans la base de données précitée, au numéro d'identification d'objet ID-OBJ étant ajouté par concaténation une adresse de mémoire cache répartie contenant le document recherché. La vignette correspondante représentée en figure 6 est ajoutée à la requête ICP, laquelle est alors transmise par exemple en une étape 1006 sur la figure 5.
Lorsque la base de données externe est située au voisinage de la mémoire cache coopérante locale, le protocole de communication interactif utilisé est établi entre cette base de données externe et le système d' interfaçage utilisateur/serveur désigné par "proxy". Sur la figure 7, on a représenté au contraire la base de données externe située à un endroit quelconque du réseau, c'est-à-dire en fait en dehors de tout voisinage de la mémoire cache coopérante locale CCMi . Dans ce cas, l'interrogation de la base de données est effectuée à partir de la mémoire cache coopérante locale CCMi par l'intermédiaire du protocole de gestion des mémoires caches coopérantes, c'est-à-dire du protocole ICP par l'intermédiaire des requêtes et réponses ICP 1006, 1007, 1008, 1009.
La base de données externe peut être mise à jour à partir des mémoires caches réparties de premier niveau.
Dans le cas où la base de données externe est gérée par l'intermédiaire du protocole de gestion des mémoires caches coopérantes, le protocole ICP, l'opération de mise à jour de la base de données externe peut alors être effectuée à partir du suivi du flux de données relatif à chaque objet.
Un mode de gestion plus particulier des requêtes HTTP et ICP en mode vignette sera maintenant décrit en liaison avec la figure 8.
Ce mode de gestion concerne une mémoire cache coopérante locale telle que la mémoire CCMi, dont le mode de réalisation correspond sensiblement au mode de réalisation de la figure 5 dans le cas où la base de données est externe. Les requêtes et les réponses portent les mêmes références que dans le cas de la figure 5.
En référence à la figure 8, on rappelle que chaque mémoire cache coopérante locale est systématiquement en état d'attente, 3000, de réception d'une requête HTTP ou d'une requête ICP. Sur réception d'une requête HTTP, en 3001, cette requête HTTP comportant au moins l'identification ID-OBJ de l'objet en mode vignette, l'existence de cette vignette est vérifiée en une étape 3002 au niveau de la mémoire cache coopérante locale. Sur réponse positive à l'étape 3002 et en présence de la vignette considérée, une recherche du document correspondant au numéro d'identification ID-OBJ de ce dernier est effectuée dans les mémoires caches réparties RCi à RC3. La recherche du document est effectuée en fonction du numéro d'identification de ce dernier, à l'étape 3003. Le document est bien entendu transmis et la mémoire cache coopérante locale retourne à l'état d'attente 3000.
Sur réponse négative au test de vérification de la vignette 3002, la requête HTTP est ignorée à l'étape 3004. Lors de la réception d'une requête ICP, à l'étape 3005, cette requête ICP comporte au moins une vignette comprenant le numéro d'identification du document ou objet recherché . Un test 3006 est effectué par interrogation de la base de données externe lorsque la vignette est présente dans la requête ICP.
Sur réponse négative au test 3006, la vignette n'étant pas présente dans la requête ICP, cette requête est ignorée à l'étape 3004.
Au contraire, sur réponse positive à l'étape 3006, la requête ICP est transmise à la base de données externe par une requête ICP et la base de données, à l'étape 3007, renvoie une réponse, la réponse 1009, dans laquelle la vignette a été complétée avec le numéro de référence de la mémoire cache contenant le document ou l'objet recherché. Une réponse ICP avec la vignette complétée est renvoyée par la mémoire cache coopérante locale CCMi et cette dernière revient à l'état d'attente 3000.
Le processus de gestion en mode vignette précité apparaît particulièrement intéressant dans la mesure où il est susceptible d'être mis en œuvre par un simple paramétrage du protocole HTTP à l'aide de chaque instruction GET [Document] où Document représente une liste de différents documents recherchés.

Claims

REVENDICATIONS
1. Système de mémoires caches dans un réseau de transmission de requête HTTP d'accès à un objet constitué notamment par des pages HTML gérées par un serveur d'origine et de réponses HTTP contenant cet objet entre un utilisateur auteur de la requête d'accès à partir d'un terminal utilisateur, ce réseau comportant des mémoires caches réparties, gérées selon un protocole de gestion de mémoires caches réparties, et des mémoires caches coopérantes, comportant au moins une mémoire cache coopérante locale et des mémoires caches coopérantes voisines, les mémoires caches réparties et coopérantes, locales et voisines étant interconnectées en réseau au serveur d'origine, caractérisé en ce que ledit système comporte :
- des mémoires caches réparties de premier niveau assurant le partage de la fonction cache vis-à-vis du serveur d'origine, et
- des mémoires caches coopérantes de deuxième niveau assurant prioritairement la transmission desdites requêtes HTTP, des réponses à ces requêtes et la transmission de cet objet à partir d'une autre mémoire cache coopérante de deuxième niveau ou du serveur d'origine, lesdites mémoires caches réparties de premier niveau assurant la gestion descendante de chaque requête HTTP non satisfaite vers lesdites mémoires caches coopérantes de deuxième niveau et l'ensemble du processus décisionnel relatif à la sauvegarde répartie de cet objet dans lesdites mémoires caches réparties de premier niveau.
2. Système selon la revendication 1, caractérisé en ce que chaque mémoire cache coopérante locale appartenant auxdites mémoires caches coopérantes de deuxième niveau comprend une unité de calcul et une mémoire morte, permettant d'assurer la transmission desdites requêtes HTTP, des réponses à ces requêtes et la transmission de cet objet, en l'absence de mémoire de sauvegarde de cet objet.
3. Système selon la revendication 2, caractérisé en ce que chaque mémoire cache coopérante locale appartenant auxdites mémoires caches coopérantes de deuxième niveau comporte en outre dans ladite mémoire morte une série d'instructions permettant la mise en œuvre d'un protocole interactif d'accès aux données mémorisées desdites mémoires caches réparties de premier niveau.
4. Système selon la revendication 3, caractérisé en ce que chaque mémoire cache coopérante locale appartenant auxdites mémoires caches coopérantes de deuxième niveau comporte en outre dans ladite mémoire morte la fonction de répartition de cet objet dans lesdites mémoires caches réparties de premier niveau, ce qui permet à ladite mémoire cache coopérante locale de rechercher chaque objet sauvegardé dans lesdites mémoires caches réparties de premier niveau par adressage direct de ces mémoires caches réparties .
5. Système selon la revendication 3, caractérisé en ce que celui-ci comporte en outre une base de données externe contenant un fichier indexé du contenu des mémoires caches réparties de premier niveau, ladite base de données étant mise à jour par un processus de synchronisation en relation avec lesdites mémoires caches réparties de premier niveau.
6. Système selon la revendication 5, caractérisé en ce que ladite base de données externe est gérée par l'intermédiaire d'un protocole de communication interactif entre cette base de données externe et le système d' interfaçage utilisateur/serveur "proxy" .
7. Système selon la revendication 5, caractérisé en ce que ladite base de données externe est gérée par l'intermédiaire du protocole de gestion des mémoires caches coopérantes, l'opération de mise à jour étant effectuée à partir du suivi du flux de données relatif à chaque objet.
8. Système selon l'une des revendications 6 ou 7 , caractérisé en ce que pour une gestion en mode vignette des requêtes et des réponses HTTP et des requêtes et des réponses des mémoires caches coopérantes de deuxième niveau, à chaque requête HTTP est associée une vignette comportant au moins un numéro de référence du document recherché par le terminal utilisateur, et en ce que chaque mémoire cache coopérante locale étant en état d'attente de réception d'une requête HTTP ou d'une requête selon le protocole de gestion des mémoires caches coopérantes de deuxième niveau, chaque mémoire cache coopérante locale permet : sur réception d'une requête HTTP : " de vérifier la présence de cette vignette et sur réponse positive à cette étape de vérification, " de retrouver le document recherché dans la mémoire cache répartie à partir de cette vignette ; " de retourner à cet état d'attente après transmission du document recherché au terminal utilisateur ; et - sur réception d'une requête selon le protocole de gestion des mémoires caches coopérantes de deuxième niveau, chaque mémoire cache coopérante locale permet : • d'adresser une requête contenant ladite vignette à la base de données externe ;
" de compléter au niveau de la base de données externe ladite vignette avec l'adresse ou numéro d'identification de la mémoire cache répartie contenant ledit document recherché ; " de transmettre à partir de la mémoire cache coopérante locale une réponse selon le protocole de gestion des mémoires caches coopérantes comportant ladite vignette comportant l'adresse de la mémoire cache répartie contenant le document recherché ; " de retourner à l'état d'attente.
9. Procédé de transmission de requêtes HTTP d'accès à un objet constitué notamment par des pages HTML gérées par un serveur d'origine et de réponses HTTP contenant cet objet entre un utilisateur auteur de la requête d'accès à partir d'un terminal utilisateur, des mémoires caches réparties, gérées selon un protocole de mémoires caches réparties, et des mémoires caches coopérantes, gérées selon un protocole de mémoires coopérantes, les mémoires caches coopérantes comportant au moins une mémoire cache coopérante locale et des mémoires caches coopérantes voisines, les mémoires caches réparties et coopérantes, locale et voisines, étant interconnectées en réseau audit serveur d'origine, caractérisé en ce que ce procédé consiste : - à configurer lesdites mémoires caches réparties comme mémoires caches de premier niveau, lesdites mémoires caches réparties étant adaptées à recevoir dudit terminal utilisateur et émettre, vers la mémoire cache coopérante locale, des requêtes respectivement des réponses HTTP, relatives audit objet, et à mémoriser, sur critère de gestion de mémoire, ledit objet ;
- à configurer lesdites mémoires caches coopérantes comme mémoires caches de deuxième niveau, lesdites mémoires caches réparties et coopérantes, sur requête HTTP d'accès à cet objet émise par le terminal utilisateur étant adaptées :
" pour les mémoires caches réparties, à recevoir cette requête HTTP d'accès, et, en présence dudit objet dans ces mémoires caches réparties, à transmettre au terminal utilisateur une réponse HTTP de transmission dudit objet, et, en l'absence de cet objet dans ces mémoires caches réparties, à transmettre vers la mémoire cache coopérante locale une requête HTTP d'accès audit objet ;
" pour lesdites mémoires caches coopérantes locale et voisines, en présence dudit objet dans cette mémoire cache coopérante locale, à transmettre de cette mémoire cache coopérante locale ledit objet vers ces mémoires caches réparties puis vers le terminal utilisateur, et, en l'absence dudit objet dans cette mémoire cache coopérante locale, à transmettre de cette mémoire cache coopérante locale vers les mémoires caches coopérantes voisines un message de recherche de cet objet, et, en présence de cet objet dans ces mémoires caches coopérantes voisines, à transmettre ledit objet de ces mémoires caches coopérantes voisines vers la mémoire cache coopérante locale en l'absence de copie de 38
sauvegarde de cet objet dans cette mémoire cache coopérante locale, puis vers les mémoires caches réparties et le terminal utilisateur, et, en l'absence de cet objet dans lesdites mémoires caches coopérantes voisines, à transmettre une requête HTTP d'accès à cet objet de cette mémoire cache coopérante locale vers le serveur d'origine et à transmettre une réponse HTTP contenant ledit objet vers la mémoire cache coopérante locale, les mémoires caches réparties et le terminal utilisateur, ce qui permet de réduite le nombre d'accès et le temps d'occupation dudit serveur d'origine.
10. Procédé selon la revendication 9, caractérisé en ce que celui-ci consiste en outre à communiquer à ladite mémoire cache coopérante locale une information relative à la répartition du contenu desdites mémoires caches réparties.
11. Procédé selon la revendication 9, caractérisé en ce que celui-ci consiste en outre à mémoriser au niveau de ladite mémoire cache coopérante locale un index de contenu dudit objet, cet index étant représentatif d'une adresse du contenu de cet objet.
12. Procédé selon la revendication 9, caractérisé en ce que celui-ci consiste en outre à communiquer à ladite mémoire cache coopérante locale la fonction de répartition desdites mémoires caches réparties, ladite mémoire cache locale étant adaptée, à partir de ladite fonction de répartition, à établir l'existence ou la non- existence dudit objet dans lesdites mémoires caches réparties .
13. Procédé selon l'une des revendications 9 à 12 précédentes, caractérisé en ce que lesdites mémoires caches réparties sont gérées selon le protocole de gestion CARP.
14. Procédé selon l'une des revendications 9 à 13 précédentes, caractérisé en ce que lesdites mémoires caches coopérantes sont gérées selon le protocole ICP.
PCT/FR2000/000042 1999-01-13 2000-01-11 Interfonctionnement et systeme de caches cooperants et caches repartis WO2000042526A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
FR99/00283 1999-01-13
FR9900283A FR2788398A1 (fr) 1999-01-13 1999-01-13 Interfonctionnement de caches cooperants et caches repartis
FR9903653A FR2788352B1 (fr) 1999-01-13 1999-03-24 Interfonctionnement et systeme de caches cooperants et caches repartis
FR99/03653 1999-03-24

Publications (1)

Publication Number Publication Date
WO2000042526A1 true WO2000042526A1 (fr) 2000-07-20

Family

ID=26234761

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2000/000042 WO2000042526A1 (fr) 1999-01-13 2000-01-11 Interfonctionnement et systeme de caches cooperants et caches repartis

Country Status (2)

Country Link
FR (1) FR2788352B1 (fr)
WO (1) WO2000042526A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2853177A1 (fr) * 2003-03-31 2004-10-01 France Telecom Procede et systeme de controle d'acces a des sites internet
EP2438742B1 (fr) * 2009-06-03 2013-12-18 Telefonaktiebolaget LM Ericsson (publ) Procédé et n ud permettant de distribuer un contenu électronique dans un réseau de distribution de contenu

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
CHANKHUNTHOD A ET AL: "A hierarchical Internet object cache", PROCEEDINGS OF THE USENIX 1996 ANNUAL TECHNICAL CONFERENCE, PROCEEDINGS OF USENIX, SAN DIEGO, CA, USA, 22-26 JAN. 1996, 1996, Berkeley, CA, USA, USENIX Assoc, USA, pages 153 - 163, XP002121950 *
MENAUD J -M ET AL: "A new protocol for efficient cooperative transversal web caching", DISTRIBUTED COMPUTING. 12TH INTERNATIONAL SYMPOSIUM, DISC'98. PROCEEDINGS, PROCEEDINGS OF 12TH INTERNATIONAL SYMPOSIUM ON DISTRIBUTED COMPUTING (DISC 98), ANDROS, GREECE, 24-26 SEPT. 1998, 1998, Berlin, Germany, Springer-Verlag, Germany, pages 288 - 302, XP000852783, ISBN: 3-540-65066-0 *
YU P S ET AL: "Performance study of a collaborative method for hierarchical caching in proxy servers", COMPUTER NETWORKS AND ISDN SYSTEMS,NL,NORTH HOLLAND PUBLISHING. AMSTERDAM, vol. 30, no. 1-7, pages 215-224, XP004121425, ISSN: 0169-7552 *

Also Published As

Publication number Publication date
FR2788352B1 (fr) 2001-11-02
FR2788352A1 (fr) 2000-07-13

Similar Documents

Publication Publication Date Title
EP0599706B1 (fr) Dispositif de traitement de l'information permettant la gestion d'une ressource informatique par un système d'administration
FR2801697A1 (fr) Procede d'acces selon divers protocoles a des objets d'un arbre representatif d'au moins une ressource de systeme
EP1797696A1 (fr) Procede et systeme de resolution dns distribuee
EP2791798B1 (fr) Bus logiciel
FR2857763A1 (fr) Procede d'acces et de partage d'un document numerique dans un reseau de communication p2p
FR2870022A1 (fr) Procede et dispositif de distribution de donnees numeriques notamment pour reseau pair-a-pair
FR2863127A1 (fr) Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques
EP0692891A1 (fr) Système d'interconnexion de réseaux locaux utilisant un protocole de routage de type "routage depuis la source" et équipement d'interconnexion destiné à être utilisé dans un tel système
EP2088511A1 (fr) Système informatique multiprocesseur
WO2007107674A2 (fr) Procede de communication de donnees entre des systemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede
FR2847406A1 (fr) Procede et dispositif modulaire de tracage d'un message multimedia a travers un reseau de telecommunications
WO2000042526A1 (fr) Interfonctionnement et systeme de caches cooperants et caches repartis
EP2577920B1 (fr) Procédé de routage pseudo-dynamique dans un cluster comprenant des liens de communication statiques et programme d'ordinateur mettant en oeuvre ce procédé
FR3023098A1 (fr) Procede et systeme de traitement d'une demande de resolution d'un nom d'un serveur, emise par une application cliente sur un reseau de communication.
EP3688932A2 (fr) Procédé et dispositif de traitement d'une requête d'instanciation d'un service réseau
FR2788398A1 (fr) Interfonctionnement de caches cooperants et caches repartis
FR2794597A1 (fr) Procede de recherche automatique par un aeronef d'une adresse de communication d'une entite au sol d'un reseau atn
FR2818853A1 (fr) Serveur d'annuaire reparti
EP3257234B1 (fr) Procede de resolution d'une adresse ip, serveur et programme d'ordinateur correspondants
WO2006016009A1 (fr) Procede et dispositif de traitement d’une requete de traduction d’un nom de domaine
FR2801704A1 (fr) Procede de communication sous plusieurs protocoles entre une application et une ressource de systeme
FR2853788A1 (fr) Procede et dispositif d'acces a un document numerique dans un reseau de communication du type poste a poste
FR2809255A1 (fr) Procede et appareil de fourniture et d'administration de services sur le reseau internet
WO2024083978A1 (fr) Procédé de traitement d'une requête d'exécution d'un service dans un réseau de communication, procédé de validation de la requête, entité intermédiaire, entité de validation, système et programme d'ordinateur correspondants
EP1622339A1 (fr) Procédé et dispositif de distinction de requêtes HTTP utilisateur

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

WWE Wipo information: entry into national phase

Ref document number: 09601399

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase