WO2003055141A2 - Procédé de transmission d'objets entre un serveur et un terminal client mettant en oeuvre une gestion de cache - Google Patents

Procédé de transmission d'objets entre un serveur et un terminal client mettant en oeuvre une gestion de cache Download PDF

Info

Publication number
WO2003055141A2
WO2003055141A2 PCT/FR2002/004199 FR0204199W WO03055141A2 WO 2003055141 A2 WO2003055141 A2 WO 2003055141A2 FR 0204199 W FR0204199 W FR 0204199W WO 03055141 A2 WO03055141 A2 WO 03055141A2
Authority
WO
WIPO (PCT)
Prior art keywords
server
client terminal
client
objects
cache memory
Prior art date
Application number
PCT/FR2002/004199
Other languages
English (en)
Other versions
WO2003055141A3 (fr
Inventor
Olivier Aubault
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Priority to EP02801101A priority Critical patent/EP1457023B1/fr
Priority to MXPA04005844A priority patent/MXPA04005844A/es
Priority to DE60206801T priority patent/DE60206801T2/de
Priority to AT02801101T priority patent/ATE307453T1/de
Priority to KR1020047009912A priority patent/KR100952190B1/ko
Priority to AU2002364818A priority patent/AU2002364818A1/en
Priority to JP2003555739A priority patent/JP4336583B2/ja
Priority to BR0215625-3A priority patent/BR0215625A/pt
Priority to US10/499,254 priority patent/US20050086318A1/en
Publication of WO2003055141A2 publication Critical patent/WO2003055141A2/fr
Publication of WO2003055141A3 publication Critical patent/WO2003055141A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • 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
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/131—Protocols for games, networked simulations or virtual reality
    • 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 field of the invention is that of the transmission of data through communication networks. More specifically, the invention relates to the transmission of data intended to be viewed interactively, and the management of corresponding caches.
  • the server therefore sends the client the information necessary for the reconstruction of the global scene, as well as the information relating to the various objects of the scene, which enter into the field of vision (or into the field of listening) of the user, depending on their position in the scene.
  • the invention applies in particular, but not exclusively, to such a transmission, as well as to the storage, for example for future use, of information of all types, accessible by a user via a data server.
  • a cache in which all the information necessary for the reproduction of the scene, in real time, by the terminal is stored.
  • the volume of information that the server must transmit on the one hand, and which must be managed in the cache on the other hand, is considerable, especially in the case where the user wishes to view data from very large, such as very large three-dimensional scenes.
  • a replacement algorithm which allows, when the cache filling rate is high , choose the stored data to be deleted to free up memory space
  • a method of transmission which governs the choice, by the server, of the data to be sent to the client, as well as the mode of transmission of this data.
  • two main methods of transmission are known, making it possible to create a dialogue between the client and the server, and indicating to the latter the information to be transmitted to the client.
  • the first known transmission method is described in particular in the document "Multi-Resolution Model Transmission in Distributed Virtual Environments "(in French” Transmission of multi-solution models in distributed virtual environments ”) by JHP Chim et al., NRST'98, p.25-34.
  • the amount of information transmitted from the client terminal to the server is therefore very high, which is particularly disadvantageous in the context of low-speed communication networks.
  • Another objective of the invention is to implement such a data transmission technique which is simple and inexpensive to implement.
  • Another object of the invention is to provide such a technique for transmitting data through a communication network, which is suitable for any type of network, and in particular both for networks exhibiting high latency and for low-speed networks.
  • Another objective of the invention is to propose such a data transmission technique which makes it possible to delete, or at least reduce, the requests for data sent by the client terminal intended for the server.
  • At least one list of objects present in said cache memory associated with one of said client terminals is managed, upstream of said client terminals, in order to limit the exchange of information relating to the content of said cache memory. between said client terminal and said server.
  • the invention is based on a completely new and inventive approach to the management of cache memories.
  • the invention is based on the innovative and advantageous idea of maintaining, upstream of a client terminal, a list, accessible to the data server, representative of the content of a cache associated with the client. This solution therefore allows the server to know at all times the content of the client's cache, without this content being duplicated at the level of server.
  • the patent document US Pat. No. 5,956,039 presents a technique for increasing the performance of a navigation system in real time in a 3D scene.
  • One such technique consists in assigning priorities to the various objects of the scene, so that the client terminal receives the objects having the highest priority first. These priorities are managed in a database containing information relating to each object in the current scene. However, this database is not managed upstream of the client terminal, and therefore does not make it possible to solve the technical problem of reducing exchanges between the server and the terminal to which the present invention provides a solution.
  • an identifier of each of said objects is stored in said list and, for at least one of said objects, information for restoring said object.
  • the server can therefore have access, not only to the list of objects contained in the client's cache, but also to the level of rendering at which they can be reproduced by the client.
  • said restitution information relates to a level of refinement of said object.
  • the server can therefore know if the client terminal can reproduce the object in rough or detailed form for example.
  • said list comprises a pair ⁇ O, L 0 > comprising said identifier O of said object and said information for restitution L 0 of said object.
  • At least one item of information relating to said client terminal and / or to a user of said client terminal, called display information, is associated with said list, so as to form a context.
  • the latter therefore manages a context comprising a list representative of the state of the cache associated with them, as well as display information.
  • Such information may in particular be representative of the capacity of the client's terminal, or of its speed of processing.
  • said display information belongs to the group comprising: position information of said user; an observation direction of said user; - the parameters for selecting said objects.
  • selection parameters include for example a threshold for selecting objects, as well as an angle of view of the observer.
  • the position information can be expressed in the form of a 3D point, the coordinates of which correspond to the position of the observer relative to the center of the scene.
  • the direction of observation can be expressed in the form of a 3D vector.
  • said list is managed by said server or by an intermediate element of said network.
  • the list can be managed by a proxy server, intermediary between the server and the client.
  • the server can then issue requests to the proxy to find out the status of the client's cache content.
  • such a method comprises a preliminary initialization phase implementing, for each of said client terminals, a first step of transmission to said server of initial viewing information, and a step of memorization, by said server, in said corresponding context, said initial viewing information.
  • said preliminary initialization phase further comprises a second step of transmission by said server to said client terminal of a rough version of the scene to be reproduced by said client terminal.
  • the entire database containing the objects that the client wishes to view is therefore not transmitted on initialization, which constitutes a considerable saving, in terms of memory for the client and in terms of network bandwidth, on initialization.
  • a database of 100 Mbits approximately and consider that the client and the server are connected by a network of the ADSL type (in English "Asymmetric Digital Subscriber Line" for "asymmetric digital link") having a maximum speed of 500 kbits / s.
  • the transmission of the entire database at the initialization of the connection between the client and the server, making it possible to load the entire scene to be viewed at the client, is therefore done in a minimum time of 200 s.
  • the invention making it possible to eliminate this transmission on initialization, is therefore particularly advantageous for the client since it allows him to view an at least coarse representation of the scene almost instantaneously, and therefore eliminates a long wait for at least minus 200 s, or more than three minutes, imposed by the techniques of the prior art.
  • each of said client terminals implements a step of transferring at least some of said display information to said server at predetermined time intervals and / or when said display information is modified.
  • said predetermined time intervals are fixed by said client terminal. us can in particular be forced by the client, depending for example on the frequency at which he wishes the scene to be viewed to be refreshed.
  • said predetermined time intervals are a function of at least one characteristic of said communication network.
  • these time intervals can depend on the network load, its speed or its latency time for example.
  • said method implements a step of updating said display information within said corresponding context.
  • said server implements the following steps: a step of determining, as a function of at least some of said updated display information, of at least one object d identifier O necessary for said client terminal, and a corresponding level of restitution L 0 ; a step of analyzing said list representative of said cache memory associated with said client terminal, so as to identify any possible pairs ⁇ O, L 0 >, corresponding to said object or objects of identifier O and of level of restitution L 0 necessary said client terminal, not stored in said list; a step of transmitting to said client terminal of said one or more possible objects of identifier O and of level of restitution L 0 , necessary for said client terminal, corresponding to said one or said possible pairs ⁇ O, L 0 > not stored in said list; a step of updating said list representative of said cache memory associated with said client terminal, adding, in said list, said pair or pairs ⁇ 0, L 0 > corresponding to said one or said possible objects emitted.
  • the step of determining one or more object (s) necessary for the client can result from a calculation carried out by the server, according to the information stored in the context of the client. Such a calculation can also be carried out by an independent calculation entity but associated with the server, for example prior to the connection of the client; the determination step then consists, for the server, in consulting the results of this calculation so as to identify, as a function of the display information associated with the client, the object or objects that are necessary for it.
  • the invention therefore makes it possible, with respect to the techniques of the prior art, to deport the calculation of the objects necessary for the client, from the client terminal to the server, or to the calculation entity associated with it.
  • said client terminal on receipt of at least one object sent by said server, implements the following steps: if the filling rate of said cache memory associated with said client terminal is less than a predetermined threshold, a step of storing said object received in said cache memory; otherwise, a step of evaluating a relevance criterion of said received object: • If at least one of said objects stored in said cache memory has an relevance criterion of value less than that of said relevance criterion of said received object, said client terminal implements a sub-step for deleting said less relevant object from said cache memory and a sub-step for storing said received object in said cache memory;
  • said client terminal implements a sub-step of rejecting said received object.
  • a relevance criterion may for example depend on the distance from the object to the observer.
  • said client terminal sends, to said server, at least information updating said memory cache associated with said client terminal, so that said server deletes from said list representative of said cache memory at least one pair ⁇ 0, L 0 > corresponding to said object deleted during said deletion sub-step and / or to an object, emitted by said server during said transmitting step, but not stored in said cache memory.
  • At least some of said objects include at least one index, so as to be able to selectively transmit a portion of said object from said associated index.
  • such a system comprises means of management, upstream of said client terminals, of at least one list of objects present in said cache memory associated with one of said client terminals, in order to limit the exchange of information relating to the content of said cache memory between said client terminal and said server.
  • the invention also relates to a data server, called objects, connected, via at least one communication network, to at least one client terminal, at least one cache memory, intended to store at least some of said objects transmitted by said server, being associated, within said network, with at least one of said client terminals.
  • a server comprises means for managing at least one list of objects present in said cache memory associated with at least one of said client terminals, in order to limit the exchange of information relating to the content of said cache memory with said associated client terminal.
  • the invention also relates to a client terminal of a data server as described above, comprising means for transmitting to said server at least one update information, so as to allow said server to update said representative list. of said cache memory associated with said terminal.
  • FIG. 6 is a block diagram of the different steps implemented by the server of the invention during a viewing phase;
  • FIG. 7 describes the different steps implemented according to the invention during an initialization phase;
  • - Figure 8 shows a block diagram of the different steps implemented according to the invention when an object is received by the client terminal.
  • FIG. 1 An example of a network architecture that can be implemented in the context of the invention is presented in relation to FIG. 1.
  • the data stored in the cache 1 can be "present” (that is to say in use by the client terminal 2), “future” (that is to say intended for use) data. later) or “past” (ie used previously but now at least temporarily obsolete).
  • the server 3 manages a database 5, in which are grouped a set of objects that the client 2 may wish to view. These objects are preferably referenced, within the database 5, by a unique identifier, recognizable both by the server 3 and by the client 2. These objects are for example 3D meshes, preferably with progressive transmission, sounds or any other type of raw data.
  • the database 5 can also contain a plurality of objects of different nature, necessary for the reproduction of a scene by the client terminal 2: for example, in the case where the client 2 wishes to view a concert of classical music, the database 5 can contain 3D objects to reproduce the scene graphically, and 3D sounds to reproduce the sounds produced by musical instruments. According to a preferred embodiment of the invention, and as illustrated in FIG.
  • the server 3 also manages a list 6, which refers to the cache 1 of the client 2.
  • the list 6 is not managed at the level of the server 3, but upstream of the client terminal 2, for example within a proxy server not illustrated in FIG. 2, intermediate between the client 2 and the server 3.
  • a proxy server not illustrated in FIG. 2, intermediate between the client 2 and the server 3.
  • List 6 is made up of a set of pairs ⁇ O, L 0 >, where O is the identifier of an object, and L 0 corresponds to a level of restitution of the object considered, which has been transferred to the terminal client 2.
  • L 0 can take several distinct forms, depending on the type of object O used.
  • FIG. 2 makes it possible, within the framework of the invention, to transfer part of the calculations for selecting the data to be viewed from the client terminal 2 to the server 3, which advantageously makes it possible to reduce the exchanges between the client 2 and the server 3.
  • This aspect of the invention will be described in more detail in the remainder of the document in relation to FIG. 3.
  • the client 2 can in particular create, within the cache 1, different sub-caches necessary for storing the data received from the server 3.
  • all the objects of the scene to be displayed are of the same nature, it is not necessary to create sub-caches within the cache 1.
  • the client 2 visualizes on its terminal a terrain relief
  • the client 2 and the server 3 can transmit and receive the data from the base 5 allowing the viewing by the client 2 of the scene considered.
  • the general principle of such a visualization phase is based on the transmission, by the client 2, to the server 3, of information that the server 3 stores in the context associated with the client 2, and uses to transmit to the client 2 the data or objects necessary for the further visualization of the scene.
  • the transmission of this information from client 2 to server 3 is symbolized by the arrow (a) in solid lines in FIG. 3. It takes place at a frequency which can be defined by client 2 (for example, every 5 seconds ), or determined according to the capacities of the network 4 and of the client terminal 2 (for example, the frequency of transmission of the display information can be fixed at 2 seconds for a high speed network, and at 6 seconds for a low speed network) .
  • the transmission of this information (a) is also advantageously conditioned by an event criterion, in order to limit the number of exchanges (a) between client 2 and server 3: thus, the transmission (a) of position information and direction of observation takes place only if they have been modified since their last transmission (a) to the server 3.
  • the server 3 on reception 61 of the position and orientation information transmitted (a) by the client 2, the server 3 performs an update 62 of the context associated with the client 2, by memorizing the new information therein. of position and orientation received.
  • Other information such as the parameters for selecting the objects to be transmitted, or information for updating the cache 1, is preferably transmitted according to an event criterion, namely their modification.
  • Such a transmission from client 2 to server 3 is symbolized by the arrow (b) in dotted lines in FIG. 3.
  • the server 3 On reception, the server 3 stores this information, ie in list 6 (for the cache update information), or more generally in the context associated with client 2.
  • the parameters for selecting objects (such as the threshold for selecting objects, the angle of view, or any other information allowing the modification of the selection of objects) will be transmitted when their value is modified.
  • the client 2 decides to modify the selection threshold defined during the initialization phase, so as for example to decrease it, in order to be able to obtain a more detailed reproduction of the scene.
  • a selection threshold can be defined in many ways, and in particular can be evaluated in degrees, in projected pixels, in size, etc.
  • the server 3 can transmit to the client 2 only the objects which, after projection on the screen of the client terminal 2, will be seen by the virtual observer at an angle greater than or equal to 1 °.
  • the selection threshold can for example be fixed so as to select only the wavelet coefficients inducing a deformation of the mesh greater than or equal to 2 °. If the object under consideration is a sound, the selection threshold may depend on the frequency of this sound, or on its duration. The selection threshold, as well as all the other selection parameters can also be defined in any other way allowing the server 3 to select the relevant objects to be transmitted to the client 2.
  • the server 3 transmits to the client 2 the objects or data which are visibly relevant. This transmission is symbolized by the continuous gray arrow (c) in FIG. 3.
  • the determination of the visually relevant objects can result from calculations made by the server 3, or by another entity of the network 4. It can also have been calculated before the establishment of the connection between the server 3 and the client 2, and stored within the network, for example in the server 3.
  • the server in the particular embodiment illustrated in FIG. 6, the server
  • the 3 determines (63), as a function of all or part of the display information (for example as a function of the position information, of the direction of observation of the client 2 and of the selection parameters) contained in the context of the client 2, the object or objects O necessary for the client terminal 2, at an adequate level of restitution.
  • the server 3 sends (65) this or these object (s) to the client terminal 2.
  • it is also possible to implement a anticipation method allowing the server 3 to transmit (c) to client 2 objects that are not yet necessary to it, but which the server anticipates will become so in the near future. For example, if the server 3 determines that the client 2 has moved several times successively in the same direction, it can transmit (c) to the client 2 an object which is not yet relevant for the client 2, but which will soon enter his field of vision if client 2 continues to move in this direction.
  • the server 3 modifies the list 6 associated with the client 2, by adding thereto, in the form of pairs ⁇ O, L 0 >, the data transmitted (c) to the client 2, considering that all the data transmitted to the client has been stored in cache 1.
  • This updating step is illustrated in FIG. 6 by the step referenced 66.
  • Such a modification of list 6 advantageously makes it possible to minimize transmission redundancies. It may happen that some of the data transmitted (c) by the server 3 to the client 2 is not stored in the cache 1, in the event for example of transmission error linked to the network, which leads to a loss of consistency between the state of cache 1 and list 6.
  • the invention advantageously provides for remedying this problem.
  • FIGS. 4A to 4C an example of visualization by the client 2 of three-dimensional models coded by geometric wavelets.
  • wavelet coding methods make it possible to represent a mesh as a succession of details added to a basic mesh.
  • the general theory of this technique is described in particular in the article by M. Lounsbery, T. DeRose and J. arren, "Multiresolution Analysis for Surfaces of Arbitrary Topological Type "(ACM Transaction on Graphics, Vol. 16, No. 1, pp. 34-73, January 1997).
  • mapping of the base 5.
  • this mapping corresponds for example to a set of values indicating to the client terminal 2 the location and size of the various objects of the base 5, for example in the form the location and size of boxes 41A and 42A encompassing these objects.
  • the basic meshes 41B, 42B each comprise n faces.
  • the list 6 managed by the server 3 for the client 2 will therefore consist of a set of pairs ⁇ O, ⁇ N1, ..., Nn ", where O represents the identifier of the object and where Ni represents the number wavelet coefficients present in the cache 1 for the face i of the basic mesh 41B, 42B.
  • O represents the identifier of the object
  • Ni represents the number wavelet coefficients present in the cache 1 for the face i of the basic mesh 41B, 42B.
  • the Ni for i E [l, n] are all initialized to zero.
  • server 3 knowledge of Ni for i G [l .n] is sufficient for server 3 to accurately determine the wavelet coefficients present in cache 1 of client 2, provided that a sort order of the coefficients of wavelets for each of the faces is previously determined.
  • the client 2 informs the server 3, during step (b) of FIG. 3, that he has 30 coefficients for the face n ° 8 of the mesh 41B
  • the server 3 will begin to transmit the coefficients , which are associated with the face n ° 8 of the mesh 41B, and relevant for the client 2, from 31 è e coefficient.
  • the selection of the relevant coefficients takes account of the display information stored in the context of the client, such as the position information, observation orientation, and the selection parameters.
  • the order of sorting the coefficients by face of the mesh is preferably kept when they arrive in the client's terminal 2.
  • the server 3 begins by transmitting to the client 2 a map of the database 5, which will allow the client 2 to know the data to be displayed. For each object of the base 5 which it considers potentially visible, the server 3 then transmits the object in its lowest level of detail 54 (that is to say the coarsest version of the object) to the client 2. During the visualization, the server 3 will then transmit the higher levels of detail 53 to 51, depending on the position of client 2 in the scene. Thus, if the client 2 progressively approaches the object of FIG. 5, the server 3 will gradually transmit the levels of detail 53, then 52, then 51, depending on the distance from the observer to the object.
  • L 0 will represent for the object O all of the refinement levels stored for this object in the cache 1 of the customer.
  • the server 3 will then know that it can transmit the levels of detail 1 and 3, corresponding respectively to the representations referenced 53 and 51, according to the location of the user in the scene (in particular according to his distance from the object considered, and his direction of observation).
  • the server 3 then knows that it can transmit the levels 3, 5, 6 and 8 to the client 2, according to the display information stored in the associated context.
  • this type of coding of L 0 is not restricted to 3D objects composed of faces, but can be applied to any type of data composed of non-progressive levels of detail, such as multi-resolution textures for example.
  • the restitution information L 0 may in this case be variable data of the form ⁇ N, N0, ..., Nn>, where N represents the number of known pages for this object (i.e. the number of pages stored in the client cache for this object), and where Ni indicates the name of the i ⁇ page.
  • the client terminal checks the filling rate of the cache 1 which is associated with it. In case cache 1 is not integrated into terminal 2, this verification is implemented by the entity responsible for managing the cache 1, for example a proxy server in which the cache 1 is integrated.
  • the received object O R is stored (83) in the client cover 1 2.
  • an object O s of the cache 1 which is visually less relevant than the object received O R for the observer.
  • Such an object O s can be an object which has gone out of the field of vision of the client 2, for example due to a recent displacement, or a change of direction of observation of the client 2.
  • the client terminal 2 then sends (87) information updating the state of the cache 1, to inform the server 3 that the object O R could not be stored in the cache 1.
  • This updating information also allows the server 3 to maintain consistency between the state of the cache 1 and the list 6 representative of its content.
  • the server 3 can in particular verify that all the objects which it has transmitted to the client 2, and which it has therefore added to the list 6, have indeed been received without error by client 2 and / or hides it 1. This makes it possible in particular to track down transmission problems which could be linked to a network failure 4.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de transmission de données, appelées objets, via au moins un réseau de communication (4), entre un serveur (3), et au moins un terminal client (2), au moins une mémoire cache (1), destinée à stocker au moins certains desdits objets transmis par ledit serveur (3), étant associée au sein dudit réseau, à l'un au moins desdits terminaux clients (2). Selon l'invention, on gère, en amont desdits terminaux clients (2), au moins une liste d'objets présents dans ladite mémoire cache (1) associée à l'un desdits terminaux clients (2), afin de limiter les échanges d'informations relatives au contenu de ladite mémoire cache (1) entre ledit terminal client (2) et ledit serveur (3).

Description

Procédé de transmission d'objets entre un serveur et un terminal client mettant en œuvre une gestion de cache, système de transmission, serveur et terminal correspondants.
Le domaine de l'invention est celui de la transmission de données au travers de réseaux de communication. Plus précisément, l'invention concerne la transmission de données destinées à être visualisées de manière interactive, et la gestion de caches correspondante.
Les développements extraordinaires des réseaux de communication permettent aujourd'hui aux utilisateurs de visualiser des modèles de type images, textures, modèles géométriques ou scènes 3D par exemple, de manière interactive, et en temps réel. Classiquement, les utilisateurs se connectent, via un terminal adapté, à un serveur distant, qui centralise dans une base de données l'ensemble des informations nécessaires à l'utilisateur pour une telle visualisation (on notera que, bien que l'on emploie ici le terme "visualisation", de telles informations peuvent inclure des données de toutes natures, et notamment de type son, de type paginées, etc.).
Les utilisateurs peuvent ainsi accéder à de nouvelles applications, du type leur permettant par exemple de se déplacer dans un environnement virtuel 3D, comme un musée virtuel, un relief de terrain, ou encore un concert de musique classique. Dans le cadre de ces applications, le serveur envoie donc au client les informations nécessaires à la reconstruction de la scène globale, ainsi que les informations relatives aux différents objets de la scène, qui entrent dans le champ de vision (ou dans le champ d'écoute) de l'utilisateur, en fonction de sa position dans la scène. L'invention s'applique notamment, mais non exclusivement, à une telle transmission, ainsi qu'au stockage, en vue par exemple d'une utilisation future, d'informations de tout type, accessibles par un utilisateur via un serveur de données.
En effet, afin de permettre une visualisation en temps réel (telle que décrite ci-dessus) d'une scène ou d'une vidéo par exemple, on associe généralement au terminal de l'utilisateur un cache, dans lequel sont stockées toutes les informations nécessaires à la reproduction de la scène, en temps réel, par le terminal.
Un tel cache mémorise classiquement des données dites "passées", c'est-à- dire des données qui ont déjà été utilisées par le terminal pour reproduire une scène ou une image, mais qui pourront peut-être être réutilisées ultérieurement, en fonction des besoins de l'utilisateur. Il stocke également les données dites "présentes", c'est-à-dire les données en cours d'utilisation par le terminal, et enfin éventuellement des données dites "futures", qui pourront être nécessaires au terminal dans un avenir proche, et qui résultent d'une anticipation du serveur sur les besoins de l'utilisateur.
Comme on le comprendra aisément, le volume d'informations que le serveur doit transmettre d'une part, et qui doivent être gérées dans le cache d'autre part, est considérable, notamment dans le cas où l'utilisateur souhaite visualiser des données de très grande taille, comme par exemple des scènes tridimensionnelles très vastes.
Pour résoudre les problèmes afférents au volume élevé de données échangées entre le client et le serveur correspondant, on a envisagé d'introduire plusieurs méthodes de traitement, et notamment : un algorithme de remplacement, qui permet, lorsque le taux de remplissage du cache est élevé, de choisir les- données stockées à supprimer pour libérer de l'espace mémoire ; une méthode de transmission, qui régit le choix, par le serveur, des données à envoyer au client, ainsi que le mode de transmission de ces données. On connaît à ce jour deux méthodes principales de transmission, permettant de créer un dialogue entre le client et le serveur, et indiquant à ce dernier les informations à transmettre au client.
La première méthode de transmission connue est notamment décrite dans le document "Multi-Resolution Model Transmission in Distributed Virtual Environments" (en français "Transmission de modèles multi-ré solution en environnements virtuels distribués") par J. H. P. Chim et al., NRST'98, p.25-34.
Selon cette première méthode, l'envoi, par le serveur, de données que le client souhaite visualiser se décompose en quatre étapes successives : - au cours d'une première étape, le terminal du client transmet au serveur une information relative à la position de l'utilisateur dans la scène à visualiser ; sur réception de cette information de position, le serveur calcule tous les objets nécessaires à l'utilisateur, et, au cours d'une deuxième étape, lui transmet la liste des couples <O, L0> d'objets nécessaires, où O est une référence de l'objet, et L0 un niveau de détail correspondant ; le terminal client choisit alors, parmi cette liste, et en fonction du contenu de son cache, les couples correspondant aux objets qu'il souhaite recevoir, et transmet au serveur le résultat de son choix, au cours d'une troisième étape ; au cours d'une quatrième étape, le serveur transfère les objets demandés par le terminal du client.
Un inconvénient de cette technique de l'art antérieur est qu'à chaque fois que la position de l'utilisateur dans la scène est modifiée, et donc à chaque fois que le serveur doit envoyer un ou plusieurs nouveaux, objets à l'utilisateur, deux échanges complets de données, sous forme d'allers-retours, sont nécessaires entre le serveur et le terminal client, avant que le ou les objet(s) nécessaire(s) ne devienne(nt) accessible(s) à l'utilisateur, via sa mémoire cache.
Une telle technique n'est donc pas adaptée à la transmission de données au travers des réseaux de communication qui présentent une grande latence : en effet, pour de tels réseaux, cette technique ne permet pas une visualisation en temps réel des données transmises par le serveur.
Une deuxième méthode de transmission connue est décrite dans l'article
"On Caching and Prefetching of Virtual Objects in Distributed Virtual Environments" (en français "Gestion de cache et préextraction d'objets virutels en environnements virtuels distribués") par J. H. P. Chim et al., Proceedings of the sixth ACM international conférence on Multimedia, 1998, pages 171-180.
Selon cette seconde méthode, qui est plus particulièrement adaptée à la transmission d'objets codés progressivement, le terminal client transmet au serveur, à chacun de ses mouvements dans la scène visualisée, une information sur sa position, ainsi qu'une information relative au contenu de son cache, sous la forme de couples <O, L0>. A nouveau, O représente une référence de l'objet contenu dans le cache du client, et L0 indique au- serveur le niveau de détail associé à cet objet. Le serveur calcule alors, en fonction de la position de l'utilisateur dans la scène, l'ensemble des objets visuellement pertinents, vérifie si ces objets sont ou non déjà présents dans le cache de l'utilisateur, et transmet au client l'ensemble des objets manquants.
Selon cette méthode, un seul aller-retour entre le client et le serveur est donc nécessaire pour transférer au client les données nécessaires à la visualisation de la scène.
Cependant, un inconvénient de cette technique de l'art antérieur est qu'elle est très consommatrice en termes de ressources réseau, et notamment en termes de bande passante. En effet, à chaque mouvement de l'utilisateur dans la scène, le terminal client transfère au serveur l'intégralité des informations relatives au contenu de son cache (c'est-à-dire l'ensemble des couples <O, LQ> correspondant aux objets contenus dans son cache).
Dans le cas de la visualisation de scènes très vastes, la quantité d'informations transmises du terminal client au serveur est donc très élevée, ce qui est particulièrement pénalisant dans le cadre des réseaux de communication à bas débit.
L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur.
Plus précisément, un objectif de l'invention est de fournir une technique de transmission, d'un serveur vers un terminal client, d'informations nécessaires à une visualisation en temps réel de données de grande taille, en minimisant les transferts entre le serveur et le terminal client.
Un autre objectif de l'invention est de mettre en œuvre une telle technique de transmission de données qui soit simple et peu coûteuse à mettre en œuvre. L'invention a encore pour objectif de fournir une telle technique de transmission de données à travers un réseau de communication, qui soit adaptée à tout type de réseau, et notamment aussi bien aux réseaux présentant une grande latence qu'aux réseaux à bas débit.
L'invention a également pour objectif de mettre en œuvre une telle technique de transmission de données qui permette d'éviter les redondances de transmission de données du serveur au terminal client.
Encore un objectif de l'invention est de proposer une telle technique de transmission de données qui permette de supprimer, ou à tout le moins de réduire, les requêtes de données émises par le terminal client à destination du serveur. Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints à l'aide d'un procédé de transmission de données, appelées objets, via au moins un réseau de communication, entre un serveur et au moins un terminal client, au moins une mémoire cache, destinée à stocker au moins certains desdits objets transmis par ledit serveur, étant associée, au sein dudit réseau, à l'un au moins desdits terminaux clients.
Selon l'invention, on gère, en amont desdits terminaux clients, au moins une liste d'objets présents dans ladite mémoire cache associée à l'un desdits terminaux clients, afin de limiter les échanges d'informations relatives au contenu de ladite mémoire cache entre ledit terminal client et ledit serveur. Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la gestion des mémoires caches. Notamment, l'invention repose sur l'idée innovante et avantageuse de maintenir, en amont d'un terminal client, une liste, accessible au serveur de données, représentative du contenu d'un cache associé au client. Cette solution permet donc au serveur de connaître à tout moment le contenu du cache du client, sans que ce contenu ne soit dupliqué au niveau du serveur. L'invention propose donc une solution qui, bien que peu coûteuse en termes de ressources, et notamment de mémoire, pour le serveur, permet de réduire considérablement le volume d'informations échangées entre le serveur et le client, lors de la visualisation d'une scène ou d'un ensemble d'objets par le client. Une telle solution est particulièrement avantageuse pour les terminaux clients de capacité réduites, ou pour les réseaux de communication de performances limitées.
On connaît déjà plusieurs techniques, décrites notamment dans les documents de brevet US 6 098 064 et US 5 956 039, prévoyant une gestion de listes d'objets ou de documents, dans le cadre d'échanges entre un serveur et un terminal client. Cependant, ces listes diffèrent fortement, tant en termes de formes que de fonctions, de la liste de la présente invention.
Ainsi, le document de brevet US 6 098 064 décrit une technique permettant de déterminer quels sont les documents (notamment sous forme de pages web) qu'il convient de stocker dans la mémoire cache d'un ordinateur, en fonction de la probabilité que ces documents soient requis à l'avenir par un utilisateur. Selon cette technique, on gère une liste de besoins répertoriant les documents présents dans la mémoire cache du terminal, ou susceptibles d'intéresser à l'avenir son utilisateur. Cette liste n'a pas pour fonction, et ne permet pas, contrairement à la liste de la présente invention, de réduire le nombre et/ou le volume des échanges d'informations entre le serveur et le terminal client, lors de la visualisation des documents par le client.
Le document de brevet US 5 956 039 présente quant à lui une technique permettant d'accroître les performances d'un système de navigation en temps réel dans une scène 3D. Une telle technique consiste à attribuer des priorités aux différents objets de la scène, de façon que le terminal client reçoive en premier les objets présentant la priorité la plus élevée. Ces priorités sont gérées au sein d'une base de données contenant des informations relatives à chaque objet de la scène courante. Cependant cette base de données n'est pas gérée en amont du terminal client, et ne permet donc pas de résoudre le problème technique de la réduction des échanges entre le serveur et le terminal auquel la présente invention apporte une solution.
Avantageusement, on mémorise, au sein de ladite liste, un identifiant de chacun desdits objets et, pour l'un au moins desdits objets, une information de restitution dudit objet.
Le serveur peut donc avoir accès, non seulement à la liste des objets contenus dans le cache du client, mais également au niveau de restitution auquel ils peuvent être reproduits par le client. Préférentiellement, pour l'un au moins desdits objets, ladite information de restitution est relative à un niveau de raffinement dudit objet.
Le serveur peut donc savoir si le terminal client peut reproduire l'objet sous forme grossière ou détaillée par exemple.
De manière préférentielle, pour chacun desdits objets stockés dans ladite mémoire cache, ladite liste comprend un couple <O, L0> comprenant ledit identifiant O dudit objet et ladite information de restitution L0 dudit objet.
Selon une caractéristique avantageuse de l'invention, pour chacun desdits terminaux clients, on associe à ladite liste au moins une information relative audit terminal client et/ou à un utilisateur dudit terminal client, appelée information de visualisation, de façon à former un contexte.
Pour chacun des clients connectés au serveur, ce dernier gère donc un contexte comprenant une liste représentative de l'état du cache qui leur est associé, ainsi que des informations de visualisation. De telles informations peuvent notamment être représentatives de la capacité du terminal du client, ou de sa rapidité de traitement.
Préférentiellement, ladite information de visualisation appartient au groupe comprenant : une information de position dudit utilisateur ; une direction d'observation dudit utilisateur ; - les paramètres de sélection desdits objets. De tels paramètres de sélection comprennent par exemple un seuil de sélection des objets, ainsi qu'un angle de vue de l'observateur. Dans le cas de la visualisation d'une scène 3D par le terminal du client, l'information de position peut être exprimée sous la forme d'un point 3D, dont les coordonnées correspondent à la position de l'observateur par rapport au centre de la scène. La direction d'observation peut quant à elle être exprimée sous la forme d'un vecteur 3D.
Avantageusement, ladite liste est gérée par ledit serveur ou par un élément intermédiaire dudit réseau. Par exemple, la liste peut être gérée par un serveur proxy, intermédiaire entre le serveur et le client. Le serveur peut alors émettre des requêtes à destination du proxy, pour connaître l'état du contenu du cache du client. Cette solution, bien que moins performante en ce qu'elle génère davantage d'échanges d'informations, peut être intéressante dans le cas où le serveur et le proxy sont reliés par un réseau de grande performance, et où l'on souhaite "décharger" le serveur (par exemple si le serveur est de capacité réduite).
Selon une caractéristique préférentielle de l'invention, un tel procédé comprend une phase préliminaire d'initialisation mettant en œuvre, pour chacun desdits terminaux clients, une première étape de transmission vers ledit serveur d'informations de visualisation initiales, et une étape de mémorisation, par ledit serveur, dans ledit contexte correspondant, desdites informations de visualisation initiales.
Avantageusement, ladite phase préliminaire d'initialisation comprend en outre une deuxième étape de transmission par ledit serveur audit terminal client d'une version grossière de la scène à reproduire par ledit terminal client.
Selon l'invention, et contrairement aux solutions de l'art antérieur, on ne transmet donc pas, à l'initialisation, l'intégralité de la base de données contenant les objets que le client souhaite visualiser, ce qui constitue une économie considérable, en termes de mémoire pour le client et en termes de bande passante du réseau, à l'initialisation. En effet, considérons une base de données de 100 Mbits environ, et considérons que le client et le serveur sont reliés par un réseau de type ADSL (en anglais "Asymmetric Digital Subscriber Line" pour "liaison numérique à débit asymétrique") présentant un débit maximum de 500 kbits/s. La transmission de l'intégralité de la base à l'initialisation de la connexion entre le client et le serveur, permettant de charger toute la scène à visualiser chez le client, se fait donc en un temps minimum de 200 s. L'invention, permettant de supprimer cette transmission à l'initialisation, est donc particulièrement avantageuse pour le client puisqu'elle lui permet de visualiser une représentation au moins grossière de la scène de manière quasi instantanée, et supprime donc une longue attente d'au moins 200 s, soit plus de trois minutes, imposée par les techniques de l'art antérieur.
De manière préférentielle, chacun desdits terminaux clients met en œuvre une étape de transfert d'au moins certaines desdites informations de visualisation vers ledit serveur à intervalles de temps prédéterminés et/ou lorsque lesdites informations de visualisation sont modifiées.
On notera que le choix consistant à transférer les informations de visualisation à intervalles de temps prédéterminés, à condition qu'elles aient été modifiées depuis leur dernière transmission, permet de minimiser le nombre de transmissions. Selon un premier mode de réalisation avantageux de l'invention, lesdits intervalles de temps prédéterminés sont fixés par ledit terminal client. us peuvent notamment être forcés par le client, en fonction par exemple de la fréquence à laquelle il souhaite que la scène à visualiser soit rafraîchie.
Selon un deuxième mode de réalisation avantageux de l'invention, lesdits intervalles de temps prédéterminés sont fonction d'au moins une caractéristique dudit réseau de communication.
Notamment, ces intervalles de temps peuvent dépendre de la charge du réseau, de son débit ou de son temps de latence par exemple. De manière préférentielle, à l'issue de ladite étape de transfert par ledit terminal client, ledit procédé met en œuvre une étape de mise à jour desdites informations de visualisation au sein dudit contexte correspondant.
Avantageusement, à l'issue de ladite étape de mise à jour, ledit serveur met en œuvre les étapes suivantes : une étape de détermination, en fonction d'au moins certaines desdites informations de visualisation mises à jour, d'au moins un objet d'identifiant O nécessaire audit terminal client, et d'un niveau de restitution L0 correspondant ; - une étape d'analyse de ladite liste représentative de ladite mémoire cache associée audit terminal client, de façon à identifier les éventuels couples <O, L0>, correspondant audit ou auxdits objets d'identifiant O et de niveau de restitution L0 nécessaires audit terminal client, non mémorisés dans ladite liste ; - une étape d'émission vers ledit terminal client dudit ou desdits éventuels objets d'identifiant O et de niveau de restitution L0, nécessaires audit terminal client, correspondant audit ou auxdits éventuels couples <O, L0> non mémorisés dans ladite liste ; une étape d'actualisation de ladite liste représentative de ladite mémoire cache associée audit terminal client, ajoutant, dans ladite liste, ledit ou lesdits couples <O, L0> correspondant audit ou auxdits éventuels objets émis.
L'étape de détermination d'un ou plusieurs objet(s) nécessaire(s) au client peut résulter d'un calcul effectué par le serveur, en fonction des informations mémorisées dans le contexte du client. Un tel calcul peut également être effectué par une entité de calcul indépendante mais associée au serveur, par exemple préalablement à la connexion du client ; l'étape de détermination consiste alors, pour le serveur, à consulter les résultats de ce calcul de façon à identifier, en fonction des informations de visualisation associées au client, le ou les objet(s) qui lui sont nécessaires. L'invention permet donc, par rapport aux techniques de l'art antérieur, de déporter le calcul des objets nécessaires au client, du terminal du client vers le serveur, ou vers l'entité de calcul qui lui est associée.
De manière avantageuse, ledit serveur met également en œuvre : une étape de détermination d'au moins un objet d'identifiant O et de niveau de restitution L0 qui pourrait être nécessaire audit terminal client, selon au moins un critère de probabilité prédéterminé ; une étape d'envoi par anticipation audit terminal client, dudit au moins un objet d'identifiant O et de niveau de restitution L0.
Le serveur évalue par exemple la probabilité que l'observateur se rapproche d'un objet de la scène, en fonction de l'évolution de ses déplacements antérieurs, et, si cette probabilité est supérieure à un seuil prédéterminé, le serveur prend l'initiative d'envoyer au client un objet qui lui sera nécessaire dans un avenu- proche s'il continue effectivement à se déplacer dans la même direction.
Préférentiellement, sur réception d'au moins un objet émis par ledit serveur, ledit terminal client met en œuvre les étapes suivantes : si le taux de remplissage de ladite mémoire cache associée audit terminal client est inférieur à un seuil prédéterminé, une étape de stockage dudit objet reçu dans ladite mémoire cache ; sinon, une étape d'évaluation d'un critère de pertinence dudit objet reçu : • Si. l'un au moins desdits objets stockés dans ladite mémoire cache présente un critère de pertinence de valeur inférieure à celle dudit critère de pertinence dudit objet reçu, ledit terminal client met en œuvre une sous-étape de suppression dudit objet moins pertinent de ladite mémoire cache et une sous-étape de stockage dudit objet reçu dans ladite mémoire cache ;
• Sinon, ledit terminal client met en œuvre une sous-étape de rejet dudit objet reçu. Un tel critère de pertinence peut par exemple dépendre de la distance de l'objet à l'observateur. Selon une caractéristique avantageuse de l'invention, à l'issue de ladite sous-étape de suppression et/ou de ladite sous-étape de rejet, ledit terminal client envoie, vers ledit serveur, au moins une information d'actualisation de ladite mémoire cache associée audit terminal client, de façon que ledit serveur supprime de ladite liste représentative de ladite mémoire cache au moins un couple <O, L0> correspondant audit objet supprimé au cours de ladite sous-étape de suppression et/ou à un objet, émis par ledit serveur au cours de ladite étape d'émission, mais non mémorisé dans ladite mémoire cache.
De manière préférentielle, au moins certains desdits objets comprennent au moins un index, de façon à pouvoir transmettre sélectivement une portion dudit objet à partir dudit index associé.
Notamment, ces objets sont par exemple de l'un des types suivants : les images 2D ; les maillages ; - les textures ; les sons ; les modèles géométriques ; les scènes 3D ; les données vidéo ; - les données paginées.
H apparaîtra de manière évidente que cette liste n'est pas exhaustive, et est donnée à simple titre d'exemple illustratif .
L'invention concerne aussi un système de transmission de données, appelées objets, via au moins un réseau de communication, entre un serveur et au moins un terminal client, au moins une mémoire cache, destinée à stocker au moins certains desdits objets transmis par ledit serveur, étant associée, au sein dudit réseau, à l'un au moins desdits terminaux clients.
Selon l'invention, un tel système comprend des moyens de gestion, en amont desdits terminaux clients, d'au moins une liste d'objets présents dans ladite mémoire cache associée à l'un desdits terminaux clients, afin de limiter les échanges d'informations relatives au contenu de ladite mémoire cache entre ledit terminal client et ledit serveur.
L'invention concerne également un serveur de données, appelées objets, connecté, via au moins un réseau de communication, à au moins un terminal client, au moins une mémoire cache, destinée à stocker au moins certains desdits objets transmis par ledit serveur, étant associée, au sein dudit réseau, à l'un au moins desdits terminaux clients. Un tel serveur comprend des moyens de gestion d'au moins une liste d'objets présents dans ladite mémoire cache associée à l'un au moins desdits terminaux clients, afin de limiter les échanges d'informations relatives au contenu de ladite mémoire cache avec ledit terminal client associé.
L'invention concerne encore un terminal client d'un serveur de données tel que décrit précédemment, comprenant des moyens de transmission vers ledit serveur d'au moins une information d'actualisation, de façon à permettre audit serveur de mettre à jour ladite liste représentative de ladite mémoire cache associée audit terminal.
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un synoptique d'une architecture client-serveur- adaptée à la mise en œuvre de l'invention ; la figure 2 illustre l'architecture de la figure 1 , complétée selon l'invention par ajout, au niveau du serveur, d'un bloc de gestion de liste d'objets ; la figure 3 illustre un exemple de dialogue client - serveur mis en œuvre selon l'invention ; les figures 4A à 4C présentent un exemple de mode de réalisation de l'invention dans le cadre de modèles 3D codés par ondelettes géométriques ; la figure 5 illustre un deuxième exemple de mode de réalisation de l'invention pour des objets utilisant des niveaux de détail non progressifs ; la figure 6 est un schéma synoptique des différentes étapes mises en œuvre par le serveur de l'invention lors d'une phase de visualisation ; la figure 7 décrit les différentes étapes mises en œuvre selon l'invention lors d'une phase d'initialisation ; - la figure 8 présente un schéma synoptique des différentes étapes mises en œuvre selon l'invention lors de la réception d'un objet par le terminal client.
Le principe général de l'invention repose sur la gestion, en amont d'un terminal client, d'une liste d'objets présents dans la mémoire cache associée à ce terminal, de façon à réduire les échanges d'informations entre un serveur, auquel le terminal client adresse des requêtes d'objets, et le terminal client lui-même.
On s'attache dans la suite du document à décrire une application particulière de l'invention à la transmission progressive de données, à travers un réseau de communication, pour une visualisation en temps réel d'une scène par le client. (On rappelle que la présente invention ne se limite pas à la visualisation d'objets, mais peut aussi s'appliquer à l'audition d'objets sonores, etc.)
On présente, en relation avec la figure 1, un exemple d'architecture réseau pouvant être mise en œuvre dans le cadre de l'invention.
Une telle architecture réseau est une architecture client-serveur. Un cache 1 est associé au client 2 : ce cache 1 lui permet de stocker des données transmises par un serveur 3 au travers du réseau de communication 4.
Les données stockées dans le cache 1 peuvent être des données "présentes" (c'est-à-dire en cours d'utilisation par le terminal du client 2), "futures" (c'est-à- dire prévues pour une utilisation ultérieure) ou "passées" (c'est-à-dire utilisées précédemment mais désormais au moins momentanément obsolètes).
Le cache 1 peut être intégré au terminal client 2, ou être simplement associé au terminal client 2, tout en étant situé en un autre point du réseau : par exemple, le cache 1 peut être intégré à un serveur intermédiaire entre le serveur 3 et le client 2, non illustré sur la figure 1, notamment à un serveur de type proxy. Dans une variante de réalisation de l'invention, le cache 1 peut être partagé par plusieurs clients 2. Par souci de simplification, on se limitera, dans la suite du document, à décrire le mode de réalisation particulier de l'invention dans lequel le cache 1 est intégré au terminal du client 2.
Le terminal client 2 gère un ensemble d'informations essentielles à la sélection des objets à afficher sur son écran, en fonction de leur visibilité, telles que la position du client dans la scène à visualiser, l'orientation de son observation, et des paramètres de sélection des objets à afficher ou à reproduire, comme le seuil de sélection des objets, un angle de vue, etc.
Le serveur 3 gère une base de données 5, dans laquelle sont regroupés un ensemble d'objets que le client 2 peut souhaiter visualiser. Ces objets sont de préférence référencés, au sein de la base de données 5, par un identifiant unique, reconnaissable aussi bien par le serveur 3 que par le client 2. Ces objets sont par exemple des maillages 3D, de préférence à transmission progressive, des sons ou tout autre type de données brutes. La base de données 5 peut aussi contenir une pluralité d'objets de nature différente, nécessaires à la reproduction d'une scène par le terminal client 2 : par exemple, dans le cas où le client 2 souhaite visualiser un concert de musique classique, la base de données 5 peut contenir des objets 3D pour reproduire graphiquement la scène, et des sons 3D pour reproduire les sons produits par les instruments de musique. Selon un mode de réalisation préféré de l'invention, et ainsi qu'illustré en figure 2, le serveur 3 gère en outre une liste 6, qui fait référence au cache 1 du client 2. Selon une variante de l'invention, la liste 6 n'est pas gérée au niveau du serveur 3, mais en amont du terminal client 2, par exemple au sein d'un serveur proxy non illustré sur la figure 2, intermédiaire entre le client 2 et le serveur 3. Par souci de simplification, on se limitera, dans la suite du document, à décrire le mode de réalisation particulier de l'invention dans lequel la liste 6 est gérée par le serveur 3, mais l'Homme du Métier déduira aisément de cette description la réalisation de l'invention dans le cas où la liste 6 est gérée en dehors du serveur 3, en amont du terminal client 2. La liste 6 est composée d'un ensemble de couples <O, L0>, où O est l'identifiant d'un objet, et L0 correspond à un niveau de restitution de l'objet considéré, qui a été transféré au terminal client 2. Comme illustré dans la suite du document en relation avec les figures 4 et 5, L0 peut prendre plusieurs formes distinctes, selon le type d'objet O utilisé.
Le serveur 3 peut en outre gérer un ensemble d'informations relatives au terminal client et/ou au client 2, en association avec la liste 6, au sein d'un contexte client non illustré sur la figure 2. Ces informations sont par exemple la position du client dans la base associée à la scène à visualiser, l'orientation de l'observation du client, et les paramètres de sélection des objets à visualiser (à savoir notamment un seuil de sélection et un angle de vue des objets de la scène).
L'architecture présentée en figure 2 permet, dans le cadre de l'invention, de transférer une partie des calculs de sélection des données à visualiser du terminal client 2 vers le serveur 3, ce qui permet avantageusement de réduire les échanges entre le client 2 et le serveur 3. Cet aspect de l'invention sera décrit plus en détails dans la suite du document en relation avec la figure 3.
Dans le cadre de l'architecture de la figure 2, on décrit, en relation avec la figure 7, les différentes étapes mises en œuvre lors d'une phase d'initialisation du dialogue entre le serveur 3 et le client 2. Ainsi, à la connexion du client 2 au serveur 3, certaines données sont transmises afin d'initialiser le serveur 3.
Au cours d'une étape référencée 71, le terminal client 2 transmet au serveur 3 des informations de visualisation initiales, telles que par exemple la position du client dans la scène à visualiser, son orientation, l'angle de vue ou encore le seuil de sélection des objets (en fonction notamment du niveau de détail que souhaite obtenir le client 2). On notera que le type du seuil de sélection peut varier en fonction du type d'objet considéré, ainsi qu'illustré dans la suite du document.
Au cours d'une étape de mémorisation 72, le serveur 3 stocke les informations de visualisation initiales reçues, dans le contexte associé au terminal client 2. Le serveur 3 peut alors transmettre (73) au terminal client 2 une version grossière de la scène à reproduire, aussi appelée cartographie. Une telle cartographie correspond à une version élémentaire de la base de données 5, et permet au client 2 d'afficher, au moins grossièrement, la scène à visualiser sur son terminal, dès le début de la connexion.
Sur réception de cette cartographie, le client 2 peut notamment créer, au sein du cache 1, différents sous-caches nécessaires au stockage des données reçues du serveur 3.
Selon l'invention, on choisit de stocker dans un même sous-cache tous les objets de même type reçus du serveur 3. Dans le cas où tous les objets de la scène à visualiser sont de même nature, il n'est pas nécessaire de créer de sous-caches au sein du cache 1. Dans l'exemple particulier où le client 2 visualise sur son terminal un relief de terrain, on créera de préférence, au sein du cache 1, un premier sous- cache pour stocker les données relatives à la géométrie du terrain, et un second sous-cache destiné à stocker la texture du terrain.
A l'issue d'une telle phase d'initialisation, le client 2 et le serveur 3 peuvent transmettre et recevoir les données de la base 5 permettant la visualisation par le client 2 de la scène considérée.
On décrit désormais, en relation avec les figures 3 et 6, le dialogue client- serveur au cours de la phase de visualisation de la scène à reproduire par le terminal client 2.
Le principe général d'une telle phase de visualisation repose sur la transmission, par le client 2, au serveur 3, d'informations que le serveur 3 stocke dans le contexte associé au client 2, et utilise pour transmettre au client 2 les données ou objets nécessaires à la poursuite de la visualisation de la scène.
Ces informations sont de différentes natures, et sont notamment modifiées à différentes fréquences par le client 2. Ainsi, les informations relatives à la position du client dans la scène à reproduire, et à sa direction d'observation sont modifiées tout au long de la visualisation de la scène, puisque le client 2, ou plus exactement l'observateur virtuel qui lui est associé, se déplace dans la scène et la parcourt du regard.
La transmission de ces informations du client 2 au serveur 3 est symbolisée par la flèche (a) en trait plein de la figure 3. Elle s'effectue à une fréquence qui peut être définie par le client 2 (par exemple, toutes les 5 secondes), ou déterminée en fonction des capacités du réseau 4 et du terminal client 2 (par exemple, la fréquence de transmission des informations de visualisation peut être fixée à 2 secondes pour un réseau haut débit, et à 6 secondes pour un réseau bas débit). La transmission de ces informations (a) est en outre avantageusement conditionnée par un critère événementiel, afin de limiter le nombre d'échanges (a) entre le client 2 et le serveur 3 : ainsi, la transmission (a) des informations de position et de direction d'observation n'a lieu que si elles ont été modifiées depuis leur dernière transmission (a) au serveur 3.
Par exemple, si le client 2 s'est déplacé dans la scène depuis la dernière transmission (a) d'informations de position et de direction d'observation au serveur 3, une nouvelle transmission (a) d'informations modifiées aura lieu 5 secondes plus tard (si la fréquence de transmission a été fixée à 5 secondes).
Selon l'invention, le client 2 n'attend pas de réponse de la part du serveur 3 à la transmission (a), qui peut donc se faire en mode non connecté (de type UDP par exemple, pour "User Datagram Protocol")".
Ainsi qu'illustré en figure 6, sur réception 61 des informations de position et d'orientation transmises (a) par le client 2, le serveur 3 effectue une mise à jour 62 du contexte associé au client 2, en y mémorisant les nouvelles informations de position et d'orientation reçues. D'autres informations, comme les paramètres de sélection des objets à transmettre, ou une information d'actualisation du cache 1, sont préférentiellement transmises selon un critère événementiel, à savoir leur modification. Une telle transmission du client 2 au serveur 3 est symbolisée par la flèche (b) en traits pointillés sur la figure 3. Sur réception, le serveur 3 stocke ces informations, soit dans la liste 6 (pour l'information d'actualisation du cache), soit plus généralement dans le contexte associé au client 2.
Ainsi, l'information d'actualisation du cache 1 du client 2 est transmise au serveur 3, sous la forme d'une liste de couples <O, L0> correspondant aux objets présents dans le cache 1 (ou dans l'un des sous-caches du cache 1), à chaque fois que : un ou plusieurs objet(s) ont été supprimés du cache 1 par le terminal client 2 pour permettre de stocker de nouveaux objets transmis par le serveur 3 ; ou - lorsqu'un ou plusieur(s) objet(s) transmis par le serveur 3 ont été rejetés par le terminal client 2.
Ces aspects seront décrits plus en détails par la suite en relation avec la figure 8, qui illustre le traitement effectué par le terminal client 2 sur réception d'objets transmis par le serveur 3. O représente un identifiant d'un objet de la scène, et L0 est une information relative au niveau de détail de restitution de l'objet O. La structure de L0 dépend bien sûr du type d'objet O, et de la méthode utilisée pour coder les niveaux de détail associés. Ainsi, L0 peut être une valeur représentative du niveau de détail (par exemple dans le cas où l'invention met en œuvre une technique de type HLOD pour "Hierarchical Level Of Détail", en français, "niveau de détail hiérarchique"), ou un ensemble de valeurs représentatives codant les raffinements géométriques de l'objet O, ainsi qu'illustré par la suite en relation avec les figures 4 et 5.
De même, les paramètres de sélection des objets (tels que le seuil de sélection des objets, l'angle de vue, ou toute autre information permettant la modification de la sélection des objets) seront transmis lors de la modification de leur valeur. On peut en effet envisager qu'en cours de visualisation, le client 2 décide de modifier le seuil de sélection défini lors de la phase d'initialisation, de façon par exemple à le diminuer, pour pouvoir obtenir une reproduction plus détaillée de la scène. On rappelle qu'un tel seuil de sélection peut être défini de nombreuses manières, et notamment être évalué en degrés, en pixels projetés, en taille, etc. Ainsi, le serveur 3 peut ne transmettre au client 2 que les objets qui, après projection sur l'écran du terminal client 2, seront vus par l'observateur virtuel sous un angle supérieur ou égal à 1°. Dans le cas d'un objet associé à un maillage codé par ondelettes, le seuil de sélection peut être par exemple fixé de façon à ne sélectionner que les coefficients d'ondelettes induisant une déformation du maillage supérieure ou égale à 2°. Si l'objet considéré est un son, le seuil de sélection peut dépendre de la fréquence de ce son, ou de sa durée. Le seuil de sélection, ainsi que tous les autres paramètres de sélection peuvent encore être définis de toute autre manière permettant au serveur 3 de sélectionner les objets pertinents à transmettre au client 2.
En fonction des informations contenues dans le contexte associé au client
2 (information de position, de direction d'obseravtion, paramètres de sélection, information relative au contenu du cache 1), le serveur 3 transmet au client 2 les objets ou données qui sont visiblement pertinents. Cette transmission est symbolisée par la flèche (c) grisée continue sur la figure 3. La détermination des objets visuellement pertinents peut résulter de calculs effectués par le serveur 3, ou par une autre entité du réseau 4. Elle peut également avoir été calculée préalablement à l'établissement de la connexion entre le serveur 3 et le client 2, et mémorisée au sein du réseau, par exemple dans le serveur 3.
Ainsi, dans le mode de réalisation particulier illustré en figure 6, le serveur
3 détermine (63), en fonction de toutes ou partie des informations de visualisation (par exemple en fonction de l'information de position, de direction d'observation du client 2 et des paramètres de sélection) contenues dans le contexte du client 2, le ou les objets O nécessaires au terminal client 2, à un niveau de restitution adéquat.
Le serveur 3 analyse alors (64) la liste 6 associée au cache 1 du terminal client 2, mise à jour en fonction des dernières informations d'actualisation reçues, pour déterminer si le ou les objet(s) nécessaire(s) au client 2, dans le niveau de raffinement L0 adéquat, sont déjà mémorisés dans le cache 1 du client 2.
Dans le cas contraire, le serveur 3 émet (65) ce ou ces objet(s) vers le terminal client 2. Selon l'invention, on peut également mettre en œuvre une méthode d'anticipation permettant su serveur 3 de transmettre (c) au client 2 des objets qui ne lui sont pas encore nécessaires, mais dont le serveur prévoit qu'ils le deviendront dans un futur proche. Par exemple, si le serveur 3 détermine que le client 2 s'est déplacé à plusieurs reprises successives dans la même direction, il peut transmettre (c) au client 2 un objet qui n'est pas encore pertinent pour le client 2, mais qui entrera prochainement dans son champ de vision si le client 2 continue à se déplacer dans cette direction.
Lors de cette transmission (c), le serveur 3 modifie la liste 6 associée au client 2, en y ajoutant, sous forme de couples <O, L0>, les données transmises (c) au client 2, en considérant que toutes les données transmises au client ont été stockées dans le cache 1. Cette étape d'actualisation est illustrée en figure 6 par l'étape référencée 66. Une telle modification de la liste 6 permet avantageusement de minimiser les redondances de transmission. Il peut arriver que certaines des données transmises (c) par le serveur 3 au client 2 ne soient pas stockées dans le cache 1 , en cas par exemple d'erreur de transmission liée au réseau, ce qui entraîne une perte de cohérence entre l'état du cache 1 et la liste 6. L'invention prévoit avantageusement de remédier à ce problème. Le maintien de la cohérence entre l'état du cache 1 et la liste 6 sera décrite plus en détails par la suite en relation avec la figure 8. On décrit désormais, en relation avec les figures 4A à 4C, un exemple de visualisation par le client 2 de modèles tridimensionnels codés par ondelettes géométriques. On rappelle que les méthodes de codage dites "à ondelettes" permettent de représenter un maillage comme une succession de détails ajoutés à un maillage de base. La théorie générale de cette technique est notamment décrite dans l'article de M. Lounsbery, T. DeRose et J. arren, "Multiresolution Analysis for Surfaces of Arbitrary Topological Type" (ACM Transaction on Graphics, Vol. 16, No.l, pp. 34-73, Janvier 1997).
Comme décrit précédemment, à l'issue de la phase d'initialisation du dialogue client- serveur, le serveur 3 transmet au terminal client 2 une version grossière, appelée cartographie, de la base 5. Dans le cas d'une base 5 constituée d'un ensemble de modèles 3D (illustré en figures 4 A à 4C), cette cartographie correspond par exemple à un ensemble de valeurs indiquant au terminal client 2 l'emplacement et la taille des différents objets de la base 5, par exemple sous la forme de l'emplacement et de la taille de boîtes 41A et 42A englobant ces objets. En fonction de la visibilité de ces objets (c'est-à-dire en fonction de leur présence partielle ou totale dans le champ de vision de l'observateur, de leur distance à l'observateur, etc.), le serveur 3 transmet ensuite le maillage de base 41B, 42B de ces objets au client 2. Ces maillages de base 41B, 42B permettent au client 2 de construire les différents sous-caches qui lui sont nécessaires pour stocker les données en provenance du serveur 3, et d'élaborer une liste de couples <O, L0> initiale correspondante.
Dans l'exemple des figures 4 A à 4C, on considère que les maillages de base 41B, 42B comprennent chacun n faces. La liste 6 gérée par le serveur 3 pour le client 2 sera donc constituée d'un ensemble de couples <O, <N1, ..., Nn», où O représente l'identifiant de l'objet et où Ni représente le nombre de coefficients d'ondelettes présents dans le cache 1 pour la face i du maillage de base 41B, 42B. Lors de la transmission du maillage de base 41B, 42B, les Ni pour i E[l,n] sont tous initialisés à zéro.
On notera que la connaissance des Ni pour i G[l .n] suffit au serveur 3 pour déterminer de façon exacte les coefficients d'ondelettes présents dans le cache 1 du client 2, à condition qu'un ordre de tri des coefficients d'ondelettes pour chacune des faces soit préalablement déterminé. Ainsi, si le client 2 informe le serveur 3, au cours de l'étape (b) de la figure 3, qu'il dispose de 30 coefficients pour la face n°8 du maillage 41B, le serveur 3 commencera à transmettre les coefficients, qui sont associés à la face n°8 du maillage 41B, et pertinents pour le client 2, à partir du 31è e coefficient. On rappelle que la sélection des coefficients pertinents tient compte des informations de visualisation mémorisées dans le contexte du client, telles que l'information de position, d'orientation d'observation, et les paramètres de sélection. L'ordre de tri des coefficients par face du maillage est préférentiellement conservé à leur arrivée dans le terminal du client 2.
A partir des coefficients transmis par le serveur pour chacune des faces visibles du maillage de base 41B, 41C, le terminal client 2 peut reconstruire une représentation détaillée 41C, 42C des objets de la scène. On présente désormais en relation avec la figure 5, un deuxième exemple de mise en œuvre de l'invention, pour des objets utilisant des niveaux de détail non progressifs. Contrairement à l'exemple précédent mettant en œuvre une technique de codage par ondelettes, dans lequel les objets, ou des portions d'objets, peuvent être raffinés sélectivement en fonction du point de vue de l'utilisateur, on présente ici le cas d'un objet représenté par quatre niveaux de détail successifs référencés 51 à 54.
Comme dans l'exemple des figures 4 A à 4C, le serveur 3 commence par transmettre au client 2 une cartographie de la base de données 5, qui permettra au client 2 de connaître les données à afficher. Pour chaque objet de la base 5 qu'il estime potentiellement visible, le serveur 3 transmet ensuite l'objet dans son niveau de détail le plus bas 54 (c'est-à-dire la version la plus grossière de l'objet) au client 2. Au cours de la visualisation, le serveur 3 transmettra ensuite les niveaux de détail supérieurs 53 à 51, en fonction de la position du client 2 dans la scène. Ainsi, si le client 2 s'approche progressivement de l'objet de la figure 5, le serveur 3 transmettra progressivement les niveaux de détail 53, puis 52, puis 51, en fonction de la distance de l'observateur à l'objet.
Le codage du niveau de raffinement L0 associé à l'objet O dépendra des contraintes imposées par l'application mise en œuvre, notamment du caractère obligatoire ou non de la transmission des objets dans l'ordre des niveaux de détail associés. Ainsi, dans le cas où le serveur 3 est obligé de transmettre les objets au client 2 dans l'ordre de leur niveau de raffinement, on choisira de donner à L0 la valeur du niveau de détail le plus élevé présent dans le cache 1 pour l'objet O. Si le cache 1 contient les niveaux de raffinement référencés 54 (niveau de raffinement 0) et 53 (niveau de raffinement 1) pour l'objet O, L0 prendra la valeur "1". La liste 6 contiendra alors le couple <O, "1">, et le serveur 3 en déduira que le cache 1 contient les niveaux de raffinement 0 et 1 pour l'objet O. Il ne transmettra donc au client 2, si nécessaire, que le niveau de détail directement supérieur, à savoir le niveau référencé 52 correspondant à un niveau de raffinement "2".
Dans le cas où la transmission du serveur 3 au client 2 dans l'ordre des niveaux de raffinement n'est pas obligatoire, L0 représentera pour l'objet O l'ensemble des niveaux de raffinement mémorisés pour cet objet dans le cache 1 du client. On choisira par exemple de coder L0 sur plusieurs bits, de façon que le bit, dont la position dans L0 correspond à un niveau de détail mémorisé dans le cache 1 du client 2, prenne la valeur 1. Dans l'exemple de la figure 5, si le cache 1 du client 2 contient les niveaux de raffinement "0" et "2", correspondant respectivement aux représentations référencées 54 et 52, on aura L0 = 0101. Le serveur 3 saura alors qu'il peut transmettre les niveaux de détail 1 et 3, correspondant respectivement aux représentations référencées 53 et 51, selon l'emplacement de l'utilisateur dans la scène (notamment selon sa distance à l'objet considéré, et sa direction d'observation).
De même, si l'on considère un objet auquel sont associés huit niveaux de détail successifs, et si le cache 1 du client 2 comprend pour cet objet les niveaux de détail 1, 2, 4 et 7, L0 aura la valeur "01001011". Le serveur 3 sait alors qu'il peut transmettre les niveaux 3, 5, 6 et 8 au client 2, selon les informations de visualisation mémorisées dans le contexte associé.
On notera que ce type de codage de L0 n'est pas restreint aux objets 3D composés de faces, mais peut être appliqué à tout type de données composées de niveaux de détail non progressifs, comme des textures multi-résolutions par exemple.
On présente désormais brièvement un troisième exemple d'application de l'invention au cas des données brutes de type son ou vidéo, ou encore au cas des données paginées (de type gestion de stock, de personnel, etc.).
Dans le cas de données brutes de type son par exemple, la transmission d'une cartographie par le serveur 3 peut ne pas exister. Elle peut aussi correspondre à la transmission par le serveur 3 d'un ensemble de données temporelles, indiquant par exemple au client 2 qu'un son de violon devra être joué ou reproduit dans 30 secondes. Pour ce type d'objets sonores, l'information de restitution L0 correspondra par exemple au pourcentage de données transmis. La valeur de L0 permettra ainsi au serveur 3 de savoir par exemple que les 15 premières secondes d'un son d'une durée de 2 min 30 s sont stockées dans le cache 1 du client 2. Dans le cas de données paginées, la cartographie émise à l'initialisation par le serveur 3 pourra par exemple correspondre au nombre total de pages existant pour chacune des données dans la base de données 5. L'information de restitution L0 pourra dans ce cas être une donnée variable de la forme <N, N0, ... , Nn>, où N représente le nombre de pages connues pour cet objet (c'est-à-dire le nombre de pages stockées dans le cache du client pour cet objet), et où Ni indique le nom de la i^ page.
On décrit désormais, en relation avec la figure 8, les différentes étapes mises en œuvre par le terminal client 2, sur réception 81 d'un ou plusieurs objets OR envoyés par le serveur 3 au cours de la transmission référencée (c) sur la figure 3. Par souci de simplification, on décrit ici le cas où le serveur 3 transmet un unique objet OR au client 2. La technique mise en œuvre dans le cas où plusieurs objets OR sont reçus par le client 2 et/ou le cache 1 s'en déduit bien sûr aisément.
Au cours d'une étape référencée 82, le terminal client vérifie le taux de remplissage du cache 1 qui lui est associé. Dans le cas où le cache 1 n'est pas intégré au terminal 2, cette vérification est mise en œuvre par l'entité chargée de la gestion du cache 1, par exemple un serveur proxy auquel le cache 1 est intégré.
Si le taux de remplissage du cache 1 est inférieur à un seuil de remplissage prédéterminé, indiquant ainsi qu'il est encore possible de stocker un ou plusieurs nouveaux objets dans le cache 1 , l'objet reçu OR est mémorisé (83) dans le cache 1 du client 2.
Dans le cas contraire, il n'est pas possible de stocker l'objet OR reçu du serveur 3 dans le cache 1 , en l'état. On détermine alors (84) s'il existe un objet Os du cache 1, qui est visuellement moins pertinent que l'objet reçu OR pour l'observateur. Un tel objet Os peut être un objet qui est sorti du champ de vision du client 2, en raison par exemple d'un déplacement récent, ou d'un changement de direction d'observation du client 2.
Si un tel objet moins pertinent Os existe, il est supprimé (86) du cache 1, de façon que le nouvel objet OR reçu du serveur 3 puisse être stocké dans le cache 1 à sa place.
Le terminal client 2 envoie alors (87) une information d'actualisation de l'état du cache 1 , pour informer le serveur 3 de la suppression de cet objet Os du cache 1 , et de la mémorisation correspondante de l'objet OR.
Si en revanche tous les objets stockés dans le cache 1 sont visuellement plus pertinents que l'objet ORreçu du serveur 3, l'entité chargée de gérer le cache 1 (le terminal client 2 par exemple) rejette cet objet OR.
Le terminal client 2 envoie alors (87) une information d'actualisation de l'état du cache 1, pour informer le serveur 3 que l'objet OR n'a pas pu être mémorisé dans le cache 1. Cette information d'actualisation permet également au serveur 3 de maintenir la cohérence entre l'état du cache 1 et la liste 6 représentative de son contenu. En effet, sur réception de cette information d'actualisation, le serveur 3 peut notamment vérifier que tous les objets qu'il a transmis au client 2, et qu'il a donc ajoutés à la liste 6, ont bien été reçus sans erreur par le client 2 et/ou le cache 1. Ceci permet notamment de traquer les problèmes de transmission qui pourraient être liés à une défaillance du réseau 4.
Le serveur 3 compare donc l'information d'actualisation reçue du client 2 et la liste 6, de manière à vérifier leur conformité et, le cas échant, à mettre à jour la liste 6 en fonction de l'information d'actualisation reçue.

Claims

REVENDICATIONS
1. Procédé de transmission de données, appelées objets, via au moins un réseau de communication, entre un serveur et au moins un terminal client, au moins une mémoire cache, destinée à stocker au moins certains desdits objets transmis par ledit serveur, étant associée, au sein dudit réseau, à l'un au moins desdits terminaux clients, caractérisé en ce qu'on gère, en amont desdits terminaux clients, au moins une liste d'objets présents dans ladite mémoire cache associée à l'un desdits terminaux clients, afin de limiter les échanges d'informations relatives au contenu de ladite mémoire cache entre ledit terminal client et ledit serveur.
2. Procédé de transmission selon la revendication 1, caractérisé en ce qu'on mémorise, au sein de ladite liste, un identifiant de chacun desdits objets et, pour l'un au moins desdits objets, une information de restitution dudit objet.
3. Procédé de transmission selon la revendication 2, caractérisé en ce que, pour l'un au moins desdits objets, ladite information de restitution est relative à un niveau de raffinement dudit objet.
4. Procédé de transmission selon l'une quelconque des revendications 2 et 3, caractérisé en ce que, pour chacun desdits objets stockés dans ladite mémoire cache, ladite liste comprend un couple <O, L0> comprenant ledit identifiant O dudit objet et ladite information de restitution L0 dudit objet.
5. Procédé de transmission selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, pour chacun desdits terminaux clients, on associe à ladite liste au moins une information relative audit terminal client et/ou à un utilisateur dudit terminal client, appelée information de visualisation, de façon à former un contexte.
6. Procédé de transmission selon la revendication 5, caractérisé en ce que ladite information de visualisation appartient au groupe comprenant : une information de position dudit utilisateur ; une direction d'observation dudit utilisateur ; - les paramètres de sélection desdits objets.
7. Procédé de transmission selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite liste est gérée par ledit serveur ou par un élément intermédiaire dudit réseau.
8. Procédé de transmission selon l'une quelconque des revendications 5 à 7, caractérisé en ce qu'il comprend une phase préliminaire d'initialisation mettant en œuvre, pour chacun desdits terminaux clients, une première étape de transmission vers ledit serveur d'informations de visualisation initiales, et une étape de mémorisation, par ledit serveur, dans ledit contexte correspondant, desdites informations de visualisation initiales.
9. Procédé de transmission selon la revendication 4, caractérisé en ce que ladite phase préliminaire d'initialisation comprend en outre une deuxième étape de transmission par ledit serveur audit terminal client d'une version grossière de la scène à reproduire par ledit terminal client.
10. Procédé de transmission selon l'une quelconque des revendications 5 à 9, caractérisé en ce que chacun desdits terminaux clients met en œuvre une étape de transfert d'au moins certaines desdites informations de visualisation vers ledit serveur à intervalles de temps prédéterminés et/ou lorsque lesdites informations de visualisation sont modifiées.
11. Procédé de transmission selon la revendication 10, caractérisé en ce que lesdits intervalles de temps prédéterminés sont fixés par ledit terminal client.
12. Procédé de transmission selon la revendication 11 , caractérisé en ce que lesdits intervalles de temps prédéterminés sont fonction d'au moins une caractéristique dudit réseau de communication.
13. Procédé de transmission selon l'une quelconque des revendications 10 à 12, caractérisé en ce qu'à l'issue de ladite étape de transfert par ledit terminal client, ledit procédé met en œuvre une étape de mise à jour desdites informations de visualisation au sein dudit contexte correspondant.
14. Procédé de transmission selon la revendication 13, caractérisé en ce qu'à l'issue de ladite étape de mise à jour, ledit serveur met en œuvre les étapes suivantes : une étape de détermination, en fonction d'au moins certaines desdites informations de visualisation mises à jour, d'au moins un objet d'identifiant
O nécessaire audit terminal client, et d'un niveau de restitution L0 correspondant ; - une étape d'analyse de ladite liste représentative de ladite mémoire cache associée audit terminal client, de façon à identifier les éventuels couples
<O, L0>, correspondant audit ou auxdits objets d'identifiant O et de niveau de restitution L0 nécessaires audit terminal client, non mémorisés dans ladite liste ; - une étape d'émission vers ledit terminal client dudit ou desdits éventuels objets d'identifiant O et de niveau de restitution L0, nécessaires audit terminal client, correspondant audit ou auxdits éventuels couples <O, L0> non mémorisés dans ladite liste ; une étape d'actualisation de ladite liste représentative de ladite mémoire cache associée audit terminal client, ajoutant, dans ladite liste, ledit ou lesdits couples <O, L0> correspondant audit ou auxdits éventuels objets émis.
15. Procédé de transmission selon la revendication 14, caractérisé en ce que ledit serveur met également en œuvre : - une étape de détermination d'au moins un objet d'identifiant O et de niveau de restitution L0 qui pourrait être nécessaire audit terminal client, selon au moins un critère de probabilité prédéterminé ; une étape d'envoi par anticipation audit terminal client, dudit au moins un objet d'identifiant O et de niveau de restitution L0.
16. Procédé de transmission selon l'une quelconque des revendications 14 et 15, caractérisé en ce que, sur réception d'au moins un objet émis par ledit serveur, ledit terminal client met en œuvre les étapes suivantes : si le taux de remplissage de ladite mémoire cache associée audit terminal client est inférieur à un seuil prédéterminé, une étape de stockage dudit objet reçu dans ladite mémoire cache ; sinon, une étape d'évaluation d'un critère de pertinence dudit objet reçu :
• Si l'un au moins desdits objets stockés dans ladite mémoire cache présente un critère de pertinence de valeur inférieure à celle dudit critère de pertinence dudit objet reçu, ledit terminal client met en œuvre une sous-étape de suppression dudit objet moins pertinent de ladite mémoire cache et une sous-étape de stockage dudit objet reçu dans ladite mémoire cache ;
• Sinon, ledit terminal client met en œuvre une sous-étape de rejet dudit objet reçu.
17. Procédé de transmission selon la revendication 16, caractérisé en ce qu'à l'issue de ladite sous-étape de suppression et/ou de ladite sous-étape de rejet, ledit terminal client envoie, vers ledit serveur, au moins une information d'actualisation de ladite mémoire cache associée audit terminal client, de façon que ledit serveur supprime de ladite liste représentative de ladite mémoire cache au moins un couple <O, L0> correspondant audit objet supprimé au cours de ladite sous-étape de suppression et/ou à un objet, émis par ledit serveur au cours de ladite étape d'émission, mais non mémorisé dans ladite mémoire cache.
18. Procédé de transmission selon l'une quelconque des revendications 1 à 17, caractérisé en ce que au moins certains desdits objets comprennent au moins un index, de façon à pouvoir transmettre sélectivement une portion dudit objet à partir dudit index associé.
19. Système de transmission de données, appelées objets, via au moins un réseau de communication, entre un serveur et au moins un terminal client, au moins une mémoire cache, destinée à stocker au moins certains desdits objets transmis par ledit serveur, étant associée, au sein dudit réseau, à l'un au moins desdits terminaux clients, caractérisé en ce qu'il comprend des moyens de gestion, en amont desdits terminaux clients, d'au moins une liste d'objets présents dans ladite mémoire cache associée à l'un desdits terminaux clients, afin de limiter les échanges d'informations relatives au contenu de ladite mémoire cache entre ledit terminal client et ledit serveur.
20. Serveur de données, appelées objets, connecté, via au moins un réseau de communication, à au moins un terminal client, au moins une mémoire cache, destinée à stocker au moins certains desdits objets transmis par ledit serveur, étant associée, au sein dudit réseau, à l'un au moins desdits terminaux clients, caractérisé en ce qu'il comprend des moyens de gestion d'au moins une liste d'objets présents dans ladite mémoire cache associée à l'un au moins desdits terminaux clients, afin de limiter les échanges d'informations relatives au contenu de ladite mémoire cache avec ledit terminal client associé.
21. Terminal client d'un serveur de données selon la revendication 20, caractérisé en ce qu'il comprend des moyens de transmission vers ledit serveur d'au moins une information d'actualisation, de façon à permettre audit serveur de mettre à jour ladite liste représentative de ladite mémoire cache associée audit terminal.
PCT/FR2002/004199 2001-12-20 2002-12-05 Procédé de transmission d'objets entre un serveur et un terminal client mettant en oeuvre une gestion de cache WO2003055141A2 (fr)

Priority Applications (9)

Application Number Priority Date Filing Date Title
EP02801101A EP1457023B1 (fr) 2001-12-20 2002-12-05 Procede de transmission d'objets entre un serveur et un terminal client mettant en oeuvre une gestion de cache
MXPA04005844A MXPA04005844A (es) 2001-12-20 2002-12-05 Metodo para transmitir objetos entre un servidor y un terminal de cliente usando manejo de memoria cache, sistema de transmision correspondiente, servidor y terminal.
DE60206801T DE60206801T2 (de) 2001-12-20 2002-12-05 Verfahren zur übertragung von datenobjekten von einem server zu einem client-terminal, das sich einer verwaltung des cache bedient
AT02801101T ATE307453T1 (de) 2001-12-20 2002-12-05 Verfahren zur übertragung von datenobjekten von einem server zu einem client-terminal, das sich einer verwaltung des cache bedient
KR1020047009912A KR100952190B1 (ko) 2001-12-20 2002-12-05 캐쉬 관리를 이용한 서버와 클라이언트 단말기 사이의오브젝트 전송 방법 및 대응하는 전송 시스템, 서버 및단말기
AU2002364818A AU2002364818A1 (en) 2001-12-20 2002-12-05 Method for transmitting objects between a server and a client terminal using cache management
JP2003555739A JP4336583B2 (ja) 2001-12-20 2002-12-05 サーバとクライアント端末との間でオブジェクトを送信する方法
BR0215625-3A BR0215625A (pt) 2001-12-20 2002-12-05 Processo de transmissão de objetos entre um servidor e um terminal cliente que implementa uma gestão de cache, sistema de transmissão, servidor e terminal correspondentes
US10/499,254 US20050086318A1 (en) 2001-12-20 2002-12-05 Method for transmitting objects between a server and a client terminal using cache management, corresponding transmission, server and terminal

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR01/16632 2001-12-20
FR0116632A FR2834104B1 (fr) 2001-12-20 2001-12-20 Procede de transmission d'objets entre un serveur et un terminal client mettant en oeuvre une gestion de cache, systeme de transmission, serveur et terminal correspondants

Publications (2)

Publication Number Publication Date
WO2003055141A2 true WO2003055141A2 (fr) 2003-07-03
WO2003055141A3 WO2003055141A3 (fr) 2003-12-24

Family

ID=8870818

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/004199 WO2003055141A2 (fr) 2001-12-20 2002-12-05 Procédé de transmission d'objets entre un serveur et un terminal client mettant en oeuvre une gestion de cache

Country Status (13)

Country Link
US (1) US20050086318A1 (fr)
EP (1) EP1457023B1 (fr)
JP (1) JP4336583B2 (fr)
KR (1) KR100952190B1 (fr)
CN (1) CN100505741C (fr)
AT (1) ATE307453T1 (fr)
AU (1) AU2002364818A1 (fr)
BR (1) BR0215625A (fr)
DE (1) DE60206801T2 (fr)
ES (1) ES2249638T3 (fr)
FR (1) FR2834104B1 (fr)
MX (1) MXPA04005844A (fr)
WO (1) WO2003055141A2 (fr)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8156074B1 (en) 2000-01-26 2012-04-10 Synchronoss Technologies, Inc. Data transfer and synchronization system
US6671757B1 (en) 2000-01-26 2003-12-30 Fusionone, Inc. Data transfer and synchronization system
US8620286B2 (en) 2004-02-27 2013-12-31 Synchronoss Technologies, Inc. Method and system for promoting and transferring licensed content and applications
EP1652048A4 (fr) 2003-07-21 2009-04-15 Fusionone Inc Systeme de gestion de messages de dispositifs
US7440559B2 (en) * 2003-10-22 2008-10-21 Nokia Corporation System and associated terminal, method and computer program product for controlling the flow of content
US20050102385A1 (en) * 2003-10-22 2005-05-12 Nokia Corporation System and associated terminal, method and computer program product for controlling storage of content
US7634509B2 (en) * 2003-11-07 2009-12-15 Fusionone, Inc. Personal information space management system and method
US9542076B1 (en) 2004-05-12 2017-01-10 Synchronoss Technologies, Inc. System for and method of updating a personal profile
ES2585353T3 (es) 2004-05-12 2016-10-05 Synchronoss Technologies, Inc. Sistema de identificación de contactos avanzado
US7831680B2 (en) * 2004-07-16 2010-11-09 National Instruments Corporation Deterministic communication between graphical programs executing on different computer systems
KR100662256B1 (ko) * 2004-12-20 2006-12-28 한국전자통신연구원 낮은 프로세스 점유율을 가지는 객체기반 스토리지 장치및 그 제어 방법
JP4745839B2 (ja) * 2005-01-28 2011-08-10 富士通株式会社 データ転送システム、送信プログラム、受信プログラム及びデータ送信方法
US8583827B2 (en) * 2005-05-26 2013-11-12 Citrix Systems, Inc. Dynamic data optimization in data network
US7610291B2 (en) * 2005-08-17 2009-10-27 International Business Machines Corporation Logical grouping and management of redundant objects in storage systems
SE531899C2 (sv) * 2007-07-10 2009-09-01 Agency 9 Ab System för grafikhantering
US8181111B1 (en) 2007-12-31 2012-05-15 Synchronoss Technologies, Inc. System and method for providing social context to digital activity
US8352871B2 (en) 2008-12-04 2013-01-08 International Business Machines Corporation System and method for virtual environment preservation based on automated item reduction
JP2011030179A (ja) * 2009-06-29 2011-02-10 Sony Corp 画像データ送信装置、制御方法およびプログラム
US8255006B1 (en) 2009-11-10 2012-08-28 Fusionone, Inc. Event dependent notification system and method
US8943428B2 (en) 2010-11-01 2015-01-27 Synchronoss Technologies, Inc. System for and method of field mapping
GB2500229B (en) * 2012-03-14 2014-08-06 Canon Kk Method,system and server device for transmitting a digital resource in a client-server communication system
US9854052B2 (en) * 2013-09-27 2017-12-26 Sap Se Business object attachments and expiring URLs
EP2963894A1 (fr) * 2014-07-04 2016-01-06 Thomson Licensing Procédé pour faire fonctionner un cache disposé le long d'un trajet de transmission entre des terminaux clients et au moins un serveur, antémémoire correspondante
EP3864626A1 (fr) * 2018-10-14 2021-08-18 Bentley Systems, Incorporated Génération à entraînement frontal dynamique d'un arbre hlod
WO2020081347A1 (fr) * 2018-10-14 2020-04-23 Bentley Systems, Incorporated Conversion d'une géométrie de modèle d'infrastructure en un format de tuile
US11012531B2 (en) * 2019-04-23 2021-05-18 Cesium GS, Inc. Systems and methods for culling requests for hierarchical level of detail content over a communications network

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5956039A (en) * 1997-07-25 1999-09-21 Platinum Technology Ip, Inc. System and method for increasing performance by efficient use of limited resources via incremental fetching, loading and unloading of data assets of three-dimensional worlds based on transient asset priorities
US6026474A (en) * 1996-11-22 2000-02-15 Mangosoft Corporation Shared client-side web caching using globally addressable memory
US6098064A (en) * 1998-05-22 2000-08-01 Xerox Corporation Prefetching and caching documents according to probability ranked need S list
WO2001058069A1 (fr) * 2000-02-07 2001-08-09 Netli, Incorporated Procédé de distribution à haute performance de contenu web

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5079695A (en) * 1988-04-25 1992-01-07 Hewlett-Packard Company Object management facility which includes a snapshot facility for providing data transfer between two objects
WO1998057273A1 (fr) * 1997-06-13 1998-12-17 Koninklijke Philips Electronics N.V. Systeme de communication ameliore
US6085193A (en) * 1997-09-29 2000-07-04 International Business Machines Corporation Method and system for dynamically prefetching information via a server hierarchy
US5924096A (en) * 1997-10-15 1999-07-13 Novell, Inc. Distributed database using indexed into tags to tracks events according to type, update cache, create virtual update log on demand
US6088698A (en) * 1998-02-27 2000-07-11 Oracle Corporation Method and apparatus for incrementally generating a virtual three-dimensional world
US6414679B1 (en) * 1998-10-08 2002-07-02 Cyberworld International Corporation Architecture and methods for generating and displaying three dimensional representations
US6377257B1 (en) * 1999-10-04 2002-04-23 International Business Machines Corporation Methods and apparatus for delivering 3D graphics in a networked environment
US7490166B2 (en) * 2000-05-26 2009-02-10 Citrix Systems, Inc. Remote control of a client's off-screen surface

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6026474A (en) * 1996-11-22 2000-02-15 Mangosoft Corporation Shared client-side web caching using globally addressable memory
US5956039A (en) * 1997-07-25 1999-09-21 Platinum Technology Ip, Inc. System and method for increasing performance by efficient use of limited resources via incremental fetching, loading and unloading of data assets of three-dimensional worlds based on transient asset priorities
US6098064A (en) * 1998-05-22 2000-08-01 Xerox Corporation Prefetching and caching documents according to probability ranked need S list
WO2001058069A1 (fr) * 2000-02-07 2001-08-09 Netli, Incorporated Procédé de distribution à haute performance de contenu web

Also Published As

Publication number Publication date
FR2834104B1 (fr) 2004-10-15
CN100505741C (zh) 2009-06-24
DE60206801D1 (de) 2006-03-02
MXPA04005844A (es) 2005-03-31
KR100952190B1 (ko) 2010-04-09
US20050086318A1 (en) 2005-04-21
ES2249638T3 (es) 2006-04-01
KR20040068338A (ko) 2004-07-30
EP1457023B1 (fr) 2005-10-19
AU2002364818A8 (en) 2003-07-09
AU2002364818A1 (en) 2003-07-09
EP1457023A2 (fr) 2004-09-15
WO2003055141A3 (fr) 2003-12-24
ATE307453T1 (de) 2005-11-15
BR0215625A (pt) 2004-12-21
JP4336583B2 (ja) 2009-09-30
JP2005513658A (ja) 2005-05-12
CN1615629A (zh) 2005-05-11
DE60206801T2 (de) 2006-07-27
FR2834104A1 (fr) 2003-06-27

Similar Documents

Publication Publication Date Title
EP1457023B1 (fr) Procede de transmission d&#39;objets entre un serveur et un terminal client mettant en oeuvre une gestion de cache
US20150019678A1 (en) Methods and Systems for Caching Content at Multiple Levels
EP1453582A1 (fr) Procede de creation et de gestion d univers virtuel
FR2842378A1 (fr) Procede et dispositif de traitement d&#39;une requete ou de donnees numeriques compressees
EP1101200A1 (fr) Affinement selectif de mailles
WO2006094919A1 (fr) Procede de transmission de donnees de visualisation d&#39;un contenu entre un serveur et au moins un terminal client, serveur, terminal et programme d&#39;ordinateur correspondants
EP1340195B1 (fr) Procede de codage par ondelettes d&#39;un maillage
EP1531428A2 (fr) Méthode et appareil pour la création, téléchargement et gestion d&#39;une animation
WO2006040270A2 (fr) Procede de decodage local d&#39;un train binaire de coefficients d&#39;ondelettes
FR2819321A1 (fr) Procede de traitement et d&#39;acces a des donnees dans un systeme de reservation par ordinateur, et systeme de mise en oeuvre
FR2870615A1 (fr) Procedes et dispositifs de manipulation, transmission et affichage d&#39;images numeriques
EP0995170B1 (fr) Signal de donnees d&#39;animation d&#39;une scene graphique a objet de quantification, procede et dispositif correspondants
EP1801716B1 (fr) Diffusion de données par groupement
EP1141899B1 (fr) Procede de simplification d&#39;un maillage source, tenant compte de la courbure locale et de la dynamique geometrique locale, et applications correspondantes
FR2901439A1 (fr) Procede de selection d&#39;au moins un pair serveur pour la transmission de donnees de visualisation,terminal,serveur, et produit programme d&#39;ordinateur correspondants.
FR2765982A1 (fr) Signal de donnees d&#39;animation d&#39;une scene graphique, procede et dispositif correspondants
EP2236985A1 (fr) Gestion de données dans un système d&#39;informations géographiques
EP1714458A1 (fr) Procede d&#39;edition d&#39;une page multimedia avec pre-memorisation
EP1121665B1 (fr) Procede de codage d&#39;un maillage source, avec optimisation de la position d&#39;un sommet resultant d&#39;une fusion d&#39;arete, et applications correspondantes
WO2005088928A1 (fr) Procede d’edition de pages multimedia aupres d’un terminal, avec pre-memorisation de parametres d’objets intervenant dans les scenes.
Kokoulin Modeling and Mathematical Performance Analysis of Distributed Imagery Data Storage System for CDN
Nowak et al. Progressive 3D Mesh Transmission in IP Networks: Implementation and Traffic Measurements
Kim et al. View-dependent mesh streaming with minimal latency
WO2009056743A2 (fr) Dispositif et procede de supervision d&#39;equipements source
Yilmaza et al. A PRACTICAL APPROACH FOR SERVING LARGE AMOUNTS OF GEOSPATIAL DATA VIA COMPUTER NETWORKS

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

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

Ref document number: PA/a/2004/005844

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 2002801101

Country of ref document: EP

Ref document number: 2003555739

Country of ref document: JP

Ref document number: 1020047009912

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2002827377X

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2002801101

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10499254

Country of ref document: US

WWG Wipo information: grant in national office

Ref document number: 2002801101

Country of ref document: EP