Brevet FR2877798A1 — publié le 20060512

L'invention concerne un procédé et un dispositif de gestion du traitement d'une ou de plusieurs requêtes provenant d'au moins une machine client dans un réseau de communication. L'infrastructure existante du réseau Internet comporte de nombreux noeuds intermédiaires entre un serveur et des machines client et qui sont souvent munis d'un espace de stockage, appelé également cache. Certains sont connus sous le nom de "Proxy". Une fonction de ces noeuds intermédiaires est de stocker les requêtes et réponses au format http, afin de répondre ultérieurement, à la place du serveur, à des requêtes déjà présentes dans le cache du noeud. L'objectif alors visé est de réduire le délai de réponse aux requêtes formulées par les clients en allégeant la tâche du serveur. Les stratégies existantes dites de "caching" dans ces noeuds intermédiaires sont essentiellement basées sur la comparaison des requêtes des clients les unes par rapport aux autres. Par ailleurs, on connaît le standard JPIP qui définit un protocole dédié à la transmission progressive d'images conformes au standard JPEG2000 sur Internet et qui définit notamment deux nouveaux types de média, appelés "media types" en anglais. Ces média sont adaptés à transporter des données d'images conformes au standard JPEG2000: les media types JPP- STREAM et JPT-STREAM. Or, concernant les requêtes au format JPIP et les réponses au format JPPou JPT-STREAM de ce standard JPIP, deux requêtes différentes peuvent conduire à des réponses très redondantes. Par conséquent, l'utilisation de noeuds intermédiaires existants 30 utilisant le format http conduirait à une quantité importante de données redondantes stockées séparément dans le cache. Le brevet US 6 463 508 propose une méthode pour stocker des parties d'un flux multimédia dans des serveurs intermédiaires de type "Proxy". Selon ce brevet, des blocs de données reçus à partir d'un flux de données multimédia sont regroupés dans des segments et les blocs sont ensuite classifiés en fonction de leur distance temporelle par rapport au début du flux considéré auquel ils appartiennent. Le serveur intermédiaire ne stocke alors qu'un ensemble de segments correspondant au début de la séquence multimédia considérée. Lorsque le flux est demandé par un client, le serveur intermédiaire sert les blocs stockés (début de la séquence) et requiert les blocs restants au serveur distant. On notera que le brevet US 6 463 508 est adapté à un flux multimédia dont les segments de données présentent un ordonnancement naturel, comme une séquence vidéo ordonnée par le temps. Cependant, cette méthode fait systématiquement appel au serveur distant pour satisfaire à une requête d'un client puisque le serveur intermédiaire ne stocke que les blocs du début du flux multimédia et non la totalité du flux. Par ailleurs, ce brevet ne prévoit pas de mécanisme pour s'intéresser uniquement à quelques-unes des données stockées dans un segment. Compte tenu de ce qui précède, il serait donc intéressant de disposer d'un procédé et d'un dispositif permettant de gérer le traitement de requêtes de machines client, notamment de requêtes au format JPIP, de façon simple, tout en allégeant la tâche du serveur distant. A cet effet, la présente invention a pour objet un procédé de gestion du traitement d'une requête d'au moins une machine client dans un réseau de communication comportant une unité de traitement qui est distincte de la machine client et d'un serveur distant et qui est associée à un espace de stockage intermédiaire, caractérisé en ce que la requête comporte des informations et notamment identifie au moins une zone d'un signal numérique d'image ou de vidéo et au moins une entité élémentaire P relative à cette zone, le procédé comportant les étapes suivantes effectuées par l'unité de traitement: 2877798 3 - détermination, à partir d'informations présentes dans la requête, des données nécessaires à la machine client sous la forme d'au moins un incrément P, len de données d'entité élémentaire, ledit au moins un incrément comprenant des données d'entité élémentaire qui sont complémentaires de données d'entité élémentaire déjà présentes dans la machine client, - identification, dans l'espace de stockage intermédiaire, des données stockées qui sont relatives au signal numérique, les données stockées étant présentes sous la forme d'au moins un incrément de données d'entité élémentaire, comparaison des données nécessaires avec les données stockées identifiées, - en fonction du résultat de la comparaison, décision quant à savoir si l'unité de traitement est apte à émettre des données nécessaires vers la machine client. De façon correspondante, l'invention a également pour objet un dispositif de gestion du traitement d'une requête d'au moins une machine client dans un réseau de communication comportant une unité de traitement qui est distincte de la machine client et d'un serveur distant et qui est associée à un espace de stockage intermédiaire, caractérisé en ce que la requête comporte des informations et notamment identifie au moins une zone d'un signal numérique d'image ou de vidéo et au moins une entité élémentaire P relative à cette zone, le dispositif comportant: - des moyens de détermination, à partir d'informations présentes dans la requête, des données nécessaires à la machine client sous la forme d'au moins un incrément P, len de données d'entité élémentaire, ledit au moins un incrément comprenant des données d'entité élémentaire qui sont complémentaires de données d'entité élémentaire déjà présentes dans la machine client, - des moyens d'identification, dans l'espace de stockage intermédiaire, des données stockées qui sont relatives au signal numérique, les données stockées étant présentes sous la forme d'au moins un incrément de données d'entité élémentaire, 2877798 4 - des moyens de comparaison des données nécessaires avec les données stockées identifiées, - des moyens de décision quant à savoir si l'unité de traitement est apte à émettre des données nécessaires vers la machine client en fonction du résultat de la comparaison. L'invention permet de répondre à une ou plusieurs requêtes d'une machine client spécifiant un ou plusieurs incréments d'entités élémentaires que souhaite recevoir cette machine. A cet effet, une unité de traitement intermédiaire prévoit le stockage d'incréments d'entités élémentaires de même type et relatifs au même signal dans un espace de stockage intermédiaire associé. L'unité de traitement est ainsi apte à effectuer une analyse de requêtes très spécifiques, ce qui allège la tâche du serveur distant et permet de servir rapidement la machine client lorsque les données nécessaires sont immédiatement disponibles dans l'espace de stockage intermédiaire. Lorsque l'unité de traitement est capable de répondre à la requête sans faire appel au serveur, ce dernier peut alors être libéré pour d'autres tâches. On constate également une efficacité accrue du système de transmission client-serveur dans son ensemble. Lorsque le serveur distant ne mémorise pas l'état du cache de la mémoire de la machine client entre deux requêtes successives (mode sans état), le délai total de traitement des requêtes est diminué par rapport à l'art antérieur. Par ailleurs, contrairement à l'enseignement de l'art antérieur US 6 463 508 précité, l'invention s'applique à des signaux numériques (ex. : signaux d'image JPEG2000) dans lesquels on accède aux données de façon non connue à l'avance, en fonction de la trajectoire de navigation choisie par l'utilisateur. En outre, on obtient dans l'unité de traitement un bon compromis entre la capacité à répondre à des requêtes en mode sans état et la complexité d'un serveur complet. En effet, cela signifie que l'on évite de remplir des tâches, jugées trop lourdes pour l'unité de traitement telles que l'analyse complète de toutes les données d'en-tête d'un flux binaire. L'invention proposée permet toutefois de traiter un nombre conséquent de requêtes spécifiques qui simplifient 2877798 5 considérablement la gestion du traitement de l'ensemble des requêtes client-serveur. Selon une caractéristique, la requête identifie au moins une entité élémentaire et une quantité de données relatives à cette entité élémentaire et qui sont déjà présentes dans une mémoire associée à la machine client. Ainsi, la requête peut, par exemple, identifier les incréments de données que souhaite recevoir la machine client en identifiant les données qu'elle détient déjà, signifiant par là même qu'elle souhaite recevoir les données complémentaires de ces dernières. Selon une caractéristique, à partir de la quantité de données exprimée en nombre d'octets, l'étape de détermination identifie l'octet d'au moins un incrément de données d'entité élémentaire à partir duquel la machine client souhaite recevoir les octets suivants. Ainsi, par exemple, les données souhaitées par la machine client ne 15 sont pas limitées aux données complémentaires de l'entité élémentaire concernée. En effet, les données souhaitées peuvent également impliquer d'autres entités élémentaires concernées par la zone du signal numérique identifiée dans la requête. Selon une caractéristique, la requête identifie au moins un incrément de données d'entité élémentaire que souhaite recevoir la machine client à partir de son point de départ dans l'entité élémentaire. On notera que la requête identifie dans ce cas de figure les incréments de données souhaités par la machine client et non les données 25 qu'elle détient. Selon une caractéristique, le point de départ dudit au moins un incrément identifie un octet de l'entité élémentaire à partir duquel la machine client souhaite recevoir les octets suivants de l'entité élémentaire. Dans cet exemple, les incréments de données souhaités sont limités 30 aux données complémentaires de l'entité élémentaire concernée. 2877798 6 En effet, ici les autres entités élémentaires concernées par la zone du signal numérique identifiée dans la requête ne font pas partie des données souhaitées par la machine client. Selon une caractéristique, le procédé comporte, préalablement à 5 l'étape de détermination, une étape d'analyse d'un champ spécifique présent dans la requête et fournissant une liste du ou des incréments d'entité(s) élémentaire(s) que souhaite recevoir la machine client. Ce champ contient une liste des incréments d'entité(s) élémentaire(s) qui sont manquants dans le cache du client. Selon une caractéristique, lorsque l'étape de comparaison fait apparaître qu'au moins une partie des données nécessaires est contenue dans un ou plusieurs incréments de données d'entité élémentaire identifiés dans l'espace de stockage intermédiaire, le procédé comporte une étape d'émission de ce ou ces incréments d'entité(s) élémentaire(s) vers la machine client. Selon une caractéristique, le procédé comporte en outre une étape de détermination de la présence dans la requête d'un champ indiquant la taille des données de réponse (len) et, en cas de présence, d'utilisation de cette indication de taille pour la sélection d'incréments d'entités élémentaires à émettre vers la machine client. Le but de ce champ "len" est de limiter la taille de la réponse transmise au client, afin d'assurer une bonne réactivité de l'application client lorsque l'utilisateur modifie sa fenêtre de visualisation. Sans sa présence, une réponse peut être très longue en nombre d'octets, et donc occasionner une longue durée de transmission et un temps de traitement élevé par le client. Selon une caractéristique, lorsque le résultat de l'étape de comparaison fait apparaître que des données nécessaires, appelées données manquantes, ne sont pas contenues dans l'espace de stockage intermédiaire, le procédé comporte une étape d'émission vers le serveur d'une requête spécifiant les données manquantes. Selon une caractéristique, le procédé comporte une étape de stockage, dans l'espace de stockage intermédiaire, des données manquantes reçues du serveur. 2877798 7 Ce stockage est effectué sous la forme d'un ou de plusieurs incréments d'entités élémentaires. Selon une caractéristique, le stockage est effectué dans un fichier qui contient toutes les données relatives à un même signal et à un même type d'entités élémentaires. Selon une caractéristique, le fichier de stockage est formé par concaténation de l'ensemble d'incréments d'entité(s) élémentaire(s) de même type relatives au signal et transitant par l'unité de traitement. Selon une caractéristique, le procédé comporte une étape de réception en provenance du serveur et de stockage, dans l'espace de stockage intermédiaire, d'informations sur la zone spatiale du signal dont font partie les données manquantes. Selon une caractéristique, le procédé comporte une étape d'analyse, dans l'unité de traitement, d'une fenêtre de visualisation spécifiée dans la requête afin d'en déduire les entités élémentaires concernées par la requête. Selon une caractéristique, le procédé comporte une étape d'émission vers la machine client de toutes les données nécessaires relatives aux incréments de données d'entité(s) élémentaire(s) déterminés à partir de la requête, incluant les données manquantes. Au cas où des données sont manquantes dans l'espace de stockage intermédiaire, on peut en effet choisir d'attendre de recevoir ces dernières du serveur afin d'envoyer l'ensemble de toutes les données de réponse nécessaires à la machine client. Il est également possible de procéder en deux étapes, à savoir envoyer d'abord les données disponibles dans l'espace de stockage intermédiaire pour servir rapidement la machine client et envoyer ultérieurement les données manquantes reçues de la part du serveur. Selon une caractéristique, les requêtes et les données de réponse aux requêtes sont établies conformément au protocole de communication JPIP. Le traitement des requêtes JPIP dans l'unité de traitement est très simplifié par rapport au traitement effectué dans un serveur JPIP complet car il 2877798 8 ne nécessite pas de décoder des données JPEG2000 contenues dans un flux de données de réponse et notamment pas les entêtes de paquets d'un tel signal. Selon une caractéristique, les entités élémentaires sont choisies parmi les méta-données d'un signal numérique d'image conforme à la norme JPEG2000, les données d'en-tête de ce signal et les ensembles de blocs de données ayant la même localisation spatiale dans différentes sous-bandes de fréquence d'un même niveau de résolution du signal. Selon un autre aspect, l'invention vise aussi un moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé de gestion du traitement de requêtes selon l'invention tel que celui exposé brièvement ci-dessus. Selon encore un autre aspect, l'invention vise un programme d'ordinateur chargeable dans un appareil programmable, comportant des séquences d'instructions ou portions de code logiciel pour mettre en oeuvre des étapes du procédé de gestion du traitement de requêtes selon l'invention, lorsque ledit programme d'ordinateur est chargé et exécuté par l'appareil programmable. D'autres caractéristiques et avantages apparaîtront au cours de la description qui va suivre donnée uniquement à titre d'exemple non limitatif et faite en référence aux dessins annexés, sur lesquels: - la figure 1 représente une architecture de réseau dans laquelle l'invention est mise en oeuvre; - la figure 2 représente un exemple de réalisation de l'unité 12 et du 25 cache 14 de la figure 1; - la figure 3 illustre de façon schématique la notion de "precinct" utilisée dans le standard JPEG2000; - la figure 4 illustre de façon schématique les notions d'incrément de precinct utilisé dans l'invention; - la figure 5 représente un algorithme de traitement d'une requête dans l'unité 12 de la figure 1; - la figure 6 représente un algorithme détaillant les opérations effectuées lors de l'étape S7 de la figure 5; - la figure 7 représente un algorithme détaillant les opérations effectuées lors de l'étape S13 de la figure 5; - la figure 8 illustre de façon schématique la constitution du cache 14 de la figure 1. La figure 1 illustre un scénario typique d'utilisation de l'invention dans un réseau de communication impliquant, par exemple, un serveur distant JPIP noté 10, une unité intermédiaire de traitement 12 associée à un espace de stockage intermédiaire ou cache 14 et une ou plusieurs machines client JPIP 16, 18, 20 et 22. Selon le scénario considéré ici, des requêtes par exemple de type JPIP sont émises par une ou plusieurs machines client et reçues par l'unité intermédiaire 12. On notera que l'invention peut aussi s'appliquer à des signaux 15 d'image ou des signaux vidéo en dehors du contexte JPIP présenté dans cet exemple de réalisation. Cette unité intermédiaire 12 analyse la ou les requêtes des machines client et teste si son cache 14 contient, dans un ou plusieurs fichiers cache, des données pertinentes vis-à-vis de cette ou ces requêtes. Si ce n'est pas le cas, l'unité 12 fait suivre cette ou ces requêtes au serveur JPIP distant 10 initialement visé par la ou les requêtes. Si, par contre, l'unité 12 a stocké préalablement des données pertinentes par rapport à une requête client, alors elle extrait ces données du fichier cache correspondant et les transmet à la machine client concernée. Si toutes les données nécessaires requises par le client ne sont pas stockées par l'unité 12, alors cette dernière se charge de rapatrier les données manquantes depuis le serveur JPIP 10 en amont, après avoir interrogé ce dernier, et transmet ensuite la réponse complète à la machine client. Enfin, au fur et à mesure que des données de réponse (données de retour) provenant du serveur 10 traversent l'unité intermédiaire, elles sont stockées par celle-ci dans son cache 14. La figure 2 représente un dispositif dans lequel l'invention peut être mise en oeuvre. Un tel dispositif correspond, par exemple, à l'unité intermédiaire 12 de la figure 1 et à l'espace de stockage associé 14. Cependant, l'espace de stockage 14 peut physiquement être séparé de l'unité 12. Comme représenté à la figure 2, le dispositif selon l'invention est, par exemple, un micro-ordinateur 100 connecté à différents périphériques, par exemple, une caméra numérique 102 (ou un scanner, ou tout moyen d'acquisition ou de stockage d'images) reliée à une carte graphique et fournissant des informations à compresser. Le dispositif 100 comporte une interface de communication 104 reliée à un réseau 106 apte à transmettre des données numériques à compresser ou à transmettre des données compressées par le dispositif. Le dispositif 100 comporte également un moyen de stockage 108 tel que, par exemple, un disque dur. II comporte aussi un lecteur de disquette 110. Une disquette 112, tout comme le disque 108, peuvent contenir des données compressées ainsi que le code de l'invention qui, une fois lu par le dispositif 100, sera stocké dans le disque dur 108. :20 Selon une première variante, le programme noté "Progr" permettant au dispositif de mettre en oeuvre l'invention, pourra être stocké dans une mémoire morte ROM 114. En seconde variante, le programme pourra être reçu pour être stocké de façon identique à celle décrite précédemment par l'intermédiaire du:25 réseau de communication 106. Par ailleurs, le dispositif 100 est relié à un micro 116 par l'intermédiaire d'une carte d'entrée/sortie 118. Ce même dispositif possède un écran 120 permettant de visualiser des données ou de servir d'interface avec un utilisateur qui pourra paramétrer :30 certains modes d'exécution de l'unité intermédiaire, à l'aide du clavier 122 ou de tout autre moyen (souris par exemple). Une unité centrale CPU 124 va exécuter les instructions relatives à la mise en oeuvre de l'invention, instructions stockées dans la mémoire morte 114 ou dans les autres éléments de stockage. Lors de la mise sous tension, le ou les programmes stockés dans une mémoire non volatile, par exemple la mémoire 114, sont transférés dans une mémoire vive RAM 126 qui contiendra alors le code exécutable de l'invention ainsi que des registres pour mémoriser les variables nécessaires à la mise en oeuvre de l'invention. Bien entendu, les disquettes peuvent être remplacées par tout support d'information tel qu'un CD-ROM ou une carte mémoire. De manière plus générale, un moyen de stockage d'informations, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un ou plusieurs programmes mettant en oeuvre le procédé de gestion du comportement de l'unité intermédiaire et, notamment, du traitement des requêtes provenant d'une ou de plusieurs machines client. Un bus de communication 128 permet la communication entre les différents éléments inclus dans le micro-ordinateur 100 ou reliés à lui. La représentation du bus 128 n'est pas limitative et notamment l'unité centrale 124 est susceptible de communiquer des instructions à tout élément du micro-ordinateur 100 directement ou par l'intermédiaire d'un autre élément de ce dernier. On va maintenant rappeler brièvement les principaux éléments constitutifs d'un signal d'image conforme au standard JPEG2000. Un fichier d'image conforme au standard JPEG2000 est composé d'un préambule JPEG2000 optionnel et d'un train binaire ("codestream" en anglais) comportant un en-tête principal et au moins une tuile qui représente de façon compressée une partie rectangulaire de l'image originale considérée. Chaque tuile est formée d'un en-tête de tuile ("Nepart header" en anglais) et d'un ensemble de données d'image compressées ("Ne-part bitstream" en anglais). Chaque ensemble de données d'image comporte une séquence de paquets contenant chacun un en-tête et un corps. Le corps d'un paquet contient au moins un bloc de données ("code-block" en anglais) qui constitue une représentation compressée d'une partie rectangulaire élémentaire d'une image éventuellement transformée en sousbandes de fréquence. L'en-tête de chaque paquet, d'une part, résume la liste des blocs contenus dans le corps considéré et, d'autre part, contient des paramètres de compression propres à chacun de ces blocs. Chaque bloc est compressé sur plusieurs niveaux de qualité incrémentaux constitués d'une couche de base et de couches de raffinement, et chaque niveau ou couche de qualité d'un bloc est contenu dans un paquet distinct. Un paquet d'un ensemble de données d'image d'un fichier JPEG2000 contient donc un ensemble de blocs correspondant à une tuile, une composante, un niveau de résolution, un niveau de qualité et une position spatiale ("precinct" en anglais). Il convient de noter que la portion de train binaire correspondant à une tuile peut être divisée en plusieurs segments de tuile contigus ("tueparts" en anglais. Autrement dit, une tuile contient au moins un segment de tuile qui contient un en-tête ("Ne-part header" en anglais) et une séquence de paquets. La division en segments de tuile s'opère donc obligatoirement à des frontières de paquets. La figure 3 illustre la notion de position spatiale ou "precinct" dans une image conforme au standard JPEG2000. Comme le montre la figure, un precinct est un groupement de blocs dans les sous-bandes de fréquence d'un même niveau de résolution et correspondant à une même zone spatiale de l'image. L'image étant composée, dans un même niveau de résolution, par exemple le niveau de résolution 2 sur la figure 3, de plusieurs niveaux ou couches de qualité (couches de qualité 0, 1, ...), la contribution d'une couche de qualité à un precinct correspond exactement à un paquet de données du train binaire JPEG2000. En d'autres termes, un paquet par couche de qualité contribue à un precinct donné. Ces paquets contribuent de façon incrémentale à la qualité de reconstruction des blocs contenus dans le precinct. On notera qu'une position spatiale ou precinct constitue une entité élémentaire possible relative à une partie d'un signal d'image, mais d'autres entités élémentaires (segments de tuiles, méta données, données d'en-tête ou éventuellement couches de qualité, paquets, blocs, ... dans un mode de réalisation non compatible avec le protocole JPIP) sont également envisageables. Avant de décrire la figure 4, on va introduire différentes notions propres au standard JPIP utilisé pour la transmission progressive sur l'Internet d'images conformes au standard JPEG2000. Le protocole JPIP définit des segments ou portions de données d'un fichier JPEG2000 appelés "data-bins". On parle aussi d'entités élémentaires du signal. Les types de média JPP-STREAM et JPT-STREAM définissent une syntaxe de flux binaire utile à transporter des données d'un fichier JPEG2000 dans un ordre quelconque. Ces flux binaires sont constitués d'une séquence de messages concaténés, chacun constitué d'un en-tête et d'un corps transportant une portion ou incrément de data-bin. L'en-tête d'un message contient les champs suivants: Bin-ID[, Csn], MsgOffset, MsgLength [, Aux] . Les champs Bin-ID et [, Csn] ont pour but d'identifier de façon unique l'élément "data-bin" auquel le message considéré contribue et transportent les trois informations suivantes: l'indice du train binaire (signal d'image) auquel appartient l'élément "databin" dans le cas où le fichier initial JPEG2000 contient plusieurs trains binaires; dans ce cas le champ Csn est présent et fournit précisément cet indice de train binaire; l'identifiant de la classe (Class-Id) de l'élément "data-bin" considéré ; - l'identifiant de l'élément "data-bin" au sein de sa classe ("In-ClassId"). Les champs MsgOffset et MsgLength qui suivent dans l'en-tête identifient l'incrément de données dans le corps du message pour le data-bin considéré. Le champ MsgOffset indique la position du premier octet du corps du message dans ce segment de données. Le champ MsgLength indique le nombre d'octets de données utiles contenus dans le corps du message et qui sont extraits du "data-bin" à partir de la position MsgOffset. Enfin, le corps du message est constitué d'une suite de MsgLength octets extraits de l'élément "data-bin" considéré à partir de la position MsgOffset. Le protocole JPIP définit les classes de segment de données d'un fichier JPEG2000 suivantes: "Metadata-bin" : un "metadata-bin" consiste en une suite d'octets consécutifs du train binaire contribuant à une ou plusieurs boîtes du format de fichier JPEG2000. On trouvera plus de détails sur la définition des "metadata-bins" dans le document intitulé "JPEG2000 image coding system Part 9: Interactivity tools, APIs and protocols Final Committee Draft 2" ISO/IEC JTC1/SC29 WG1 N2790, R. Prandolini, S. Houchin, G. Colyer, 16 December 2003. L'élément "In-Class-Id" d'un "metadata-bin" est attribué par le serveur, en fonction de sa stratégie de formation des "metadata-bins" et identifie le "metadata bin" au sein de sa classe. "Main header data-bin" : un "main header data-bin" consiste en une concaténation de marqueurs ("marker segments" en anglais) contenus dans l'en-tête principal d'un fichier JPEG2000. Certains marqueurs, inutiles au client JPIP, sont exclus. "Tite header data-bin" : un "tile header data-bin" consiste en la concaténation de marqueurs du premier "tile-part header" d'une tuile donnée. "Precinct data-bin" : un "precinct data-bin" consiste en une suite d'octets formée en concaténant tous les paquets d'un train binaire JPEG2000 appartenant à un unique precinct. L'identifiant d'un "precinct data-bin" est donné par la formule suivante: P = t + (c + s x num _ components) x num _ales, où t et c représentent respectivement les indices de tuile et de composante correspondant au precinct, et s est le numéro de séquence (défini par JPIP) du precinct considéré dans la tuile t et la composante c. Les quantités num components et num tiles désignent respectivement le nombre de composantes et le nombre de tuiles dans le fichier JPEG2000 considéré. "Tile data-bin" : un "tile data-bin" consiste en la concaténation de tous les "tile-parts" contenus dans une tuile. On va maintenant décrire les requêtes des machines client et les données de réponse aux requêtes envoyées à ces machines et qui sont établies conformément au protocole de communication JPIP. Dans le mode de fonctionnement qualifié de "sans état" ("stateless" en anglais) du protocole JPIP, le serveur 10 de la figure 1 n'établit pas de session permanente avec le client (machines 16 à 22) et ne mémorise donc pas l'état du cache du client entre deux requêtes successives. Les requêtes JPIP dans le mode sans état comprennent huit types de champs: Identification de la ressource: des champs notés "target", "subtarget" et "tid" servent à identifier de manière unique la ou les images JPEG2000 concernées par la requête JPIP. Champs de fenêtre de visualisation: ces champs indiquent au serveur la zone d'intérêt courante ou fenêtre désirée par le client. On identifie ainsi une ou plusieurs parties du signal d'image. Ces champs incluent, notamment, le niveau de résolution de l'image associé à la zone, la position de la fenêtre dans l'image, la taille de la fenêtre (hauteur et largeur), les composantes et le nombre de couches de qualité JPEG2000 d'intérêt pour la zone considérée. Champs de contrôle de la quantité de données transférées: le standard JPIP prévoit plusieurs paramètres optionnels, utiles pour contrôler la quantité de données retournées par le serveur. Ces paramètres optionnels indiquent un nombre maximum d'octets de données JPEG2000 autorisé pour la zone considérée, un facteur de qualité d'image à satisfaire pour la zone d'intérêt, ou encore une valeur indiquant la portion de bande passante disponible qu'il est possible d'allouer à la requête courante. Champs de contrôle du serveur: le protocole JPIP fournit des champs permettant de contrôler certains paramètres de la réponse du serveur aux machines client. Parmi ceux-ci, le champ "type" permet de choisir le type de données de réponse ou de retour pour l'image considérée, entre JPPSTREAM, JPT-STREAM, JPEG, JP2, etc. Dans l'exemple de réalisation, les données de retour JPIP sont conformes au media type JPP-STREAM. Ce media type utilise les data-bins de type metadata-bin , main header data-bin et precinct data-bin définis plus haut. L'en-tête http Accept: joue un rôle identique au champ type introduit ci-dessus. Il peut être utilisé à sa place lorsque le protocole JPIP est utilisé au-dessus du protocole http. Champs de gestion de cache: le standard JPIP définit les champs optionnels "model", "tpmodel", "need" et "tpneed" qui sont utiles au client pour informer le serveur de l'état du cache du client. Les champs "model" et "need" s'appliquent au media type JPP-STREAM, tandis que le champ "tpmodel" ne s'applique qu'au media type JPT-STREAM. Le champ "model" indique à la fois les éléments "data-bins" déjà présents dans le cache client et pertinents vis-à-vis de la fenêtre de visualisation spécifiée, ainsi que les éléments "data-bins" que le client a effacés de son cache. Le champ "tpmodel" remplit exactement la même fonction que le champ "model", mais lorsque le media type JPT-STREAM est utilisé. Le champ "tpneed" remplit exactement la même fonction que le champ "need", mais lorsque le media type JPT-STREAM est utilisé. Le champ "need", quant à lui, permet au client de spécifier au serveur les incréments d'éléments "data-bins" qu'il souhaite recevoir en précisant le ou les incréments d'entités élémentaires concernés. Une réponse JPIP consiste en un paragraphe d'en-tête conforme au protocole http/1.1, suivi d'une séquence de messages de retour conformes au media type JPP-STREAM ou JPT-STREAM, introduits précédemment. On notera que les données de réponse sont stockées dans l'unité 12 de telle façon qu'elles peuvent être réutilisées lors du traitement de futures requêtes qui peuvent s'avérer différentes des requêtes précédemment traitées. La figure 4 illustre les notions de "precinct-data-bin" (exemple d'entité élémentaire) et d'incrément de "precinct data-bin" (exemple d'incrément d'entité élémentaire) utilisées dans le media type JPP-STREAM. Un "precinct data-bin" peut être vu, comme l'illustre la figure 4, comme l'empilement de tous les paquets de données correspondant aux couches de qualité successives du train binaire JPEG2000 et contribuant à un precinct donné. Par ailleurs, deux incréments distincts du même "precinct data-bin" sont représentés sur cette figure et numérotés 0 et 1. Chaque incrément de "precinct data-bin" est représenté comme contenant plusieurs paquets, mais ceci n'est pas systématique. Le serveur 10 ou l'unité 12 a en effet la liberté de choisir la quantité de données utiles à insérer dans un incrément d'entité élémentaire (incrément de "data-bin"). Par conséquent, un incrément de "precinct data-bin" peut contenir seulement une fraction d'un paquet de données ou plusieurs paquets et n'est pas tenu de commencer ni de se terminer à la frontière d'un paquet. On notera que les incréments sont présentés comme des données d'entité(s) élémentaire(s) qui complètent en totalité ou en partie une ou plusieurs portions de données d'entité(s) élémentaire(s) que détient déjà une machine client. Chaque "precinct data-bin" est désigné par un identifiant P qui est calculé comme indiqué plus haut. L'algorithme de la figure 5 décrit le comportement de l'unité intermédiaire de traitement 12 (figure 1) munie du cache 14 spécifiquement 20 dédié au protocole JPIP. Cet algorithme comporte une série d'instructions ou de portions de code sur lesquelles s'appuie le programme d'ordinateur Progr de la figure 2 et qui correspondent à des étapes du procédé selon l'invention. Cet algorithme débute par une étape SI de réception d'une requête:25 JPIP sans état émanant d'une machine client et par une étape suivante S2 d'analyse de cette requête. Cette analyse s'appuie, par exemple, sur le champ spécifique "need" mentionné plus haut. L'application de l'algorithme à des requêtes ne comportant pas de champ "need" sera décrite ultérieurement. :30 L'analyse du champ "need" permet de déterminer une liste des incréments de données d'entité(s) élémentaire(s) nécessaires à la machine client à l'origine de la requête. Par exemple, dans la requête suivante: GET http://www.serveur.frjpip?tid=1543263EOGF321&fsiz=512,512&need =PO:112, P1:54, P2:203,P3,P4,P5& len=5000 HTTP/1.1 Accept: image/JPP-STREAM le champ "need" qui est présent signifie que le client souhaite recevoir les données nécessaires (définies sous la forme d'incréments d'entités élémentaires) suivantes relatives au signal numérique d'image identifié dans la requête: le "precinct data-bin" 0 au-delà des 112 premiers octets; le "precinct data-bin" 1 au-delà des 54 premiers octets; le "precinct data-bin" 2 au- delà des 203 premiers octets; les "precinct data-bins" 3, 4 et 5 à partir du premier octet. Les données complémentaires visées ci-dessus identifient, pour chaque entité élémentaire correspondante (P), l'indice d'octet (point de départ des données) à partir duquel le client ne dispose pas de données dans son cache. Par ailleurs, l'unité intermédiaire 12 analyse également la présence d'un éventuel champ "len" dans la requête JPIP et son contenu. Ce champ spécifie un nombre maximal d'octets de données utiles JPEG2000 limitant la quantité de données à transmettre au client. Dans l'exemple ci-dessus, ce champ indique une quantité maximale de 5000 octets comme taille des données de réponse. II est également prévu d'analyser les champs "target", "subtarget" et "tid" (Target ID) qui servent à identifier la fichier JPEG2000 visé par la requête. Le champ "target" fournit le nom du fichier JPEG2000, et le champ "subtarget", s'il est présent, spécifie une portion de ce fichier. De plus, le champ "tid" identifie de façon unique la version du fichier JPEG2000 stockée dans le cache client. L'unité 12 extrait en outre, s'ils sont présents, l'en-tête http "Accept:" ainsi que le champ "type=". Ces champs indiquent tous les deux le type de données de retour souhaitées par le client. Notons que le champ tid, s'il est présent et différent de 0, suffit à déterminer le media type requis. L'analyse des champs "tid", "type" ou "Accept:" permet donc de déterminer le fichier de cache utilisé pour stocker les données provenant de ce 5 fichier et conformes au type de données (étape S3). Il convient de noter que si ni l'en-tête "Accept:", ni le champ "type" ne sont présents dans la requête, alors le type des données de retour doit être déterminé par d'autres moyens qui sont fournis par le standard "JPEG2000 Part 1 Final Draft International Standard (corrected and formatted)" ISO/IEC JTC1/SC29 WG1, JPEG200, September 2000. Dans ce cas, l'unité 12 peut choisir le type de données de retour en fonction des fichiers de cache dont il dispose et qui correspondraient au même nom de fichier JPEG2000 que celui requis (champ "target"). L'algorithme comporte ensuite une étape de test S4 pour savoir si le 15 fichier de cache déterminé à l'étape S3 existe dans l'espace de stockage intermédiaire 14 (cache) de la figure 1. Dans l'affirmative, l'étape suivante S5 prévoit d'effectuer une analyse du contenu de cet espace de stockage intermédiaire. Au cours de cette analyse, il est prévu d'identifier les données 20 stockées qui sont relatives au signal d'image considéré. On notera que les données sont stockées sous la forme d'un ou de plusieurs incréments de données d'entité(s) élémentaire(s). Au cours de l'étape suivante S6, on effectue une comparaison entre les données nécessaires à la machine client qui ont été identifiées à partir de la requête client (étape S2) et les données identifiées dans l'espace de stockage intermédiaire (étape S5). Si des données nécessaires à la machine client sont présentes dans l'espace de stockage intermédiaire, alors l'étape de test S6 est suivie de l'étape S7 prévoyant le traitement de la requête client. Si le test pratiqué à l'étape S6 est négatif, alors la requête est transmise au serveur distant 10 de la figure 1 (étape S8), tout comme lorsque le résultat du test de l'étape S4 révèle que le fichier de cache déterminé à l'étape S3 n'existe pas dans l'espace de stockage intermédiaire. De retour à l'étape S7, le traitement de la requête client est effectué conformément à l'algorithme de la figure 6 qui sera décrit ultérieurement. Ce traitement conduit à élaborer une réponse contenant le ou les incréments de données d'entité(s) élémentaire(s) qui ont été identifiés dans l'espace de stockage intermédiaire. Comme indiqué sur la figure, l'unité de traitement peut émettre ces données complémentaires vers la machine client (étape S9) afin de satisfaire rapidement cette dernière sans attendre le résultat de l'étape de test SI O. Consécutivement au traitement de la requête client de l'étape S7, l'étape S10 prévoit d'effectuer un test afin de déterminer si des données déterminées comme étant nécessaires (étape S2), appelées données manquantes, ne sont pas contenues dans l'espace de stockage intermédiaire. Si la réponse formée à l'étape S7 répond complètement à la requête client, alors l'étape S10 est directement suivie de l'étape S11 d'émission d'une réponse complète vers la machine client et l'étape suivante S12 met fin à l'algorithme. Dans le cas contraire, l'étape S10 est suivie de l'étape S13 qui 20 prévoit d'envoyer au serveur distant une requête spécifiant les données manquantes. Le serveur 10 sollicité par la requête prévue à l'étape S13 ou S8 fournit alors à l'unité intermédiaire 12 une réponse JPIP correspondante qui est reçue à l'étape S14 et inclut les données manquantes. Au cours de l'étape suivante S15, ces données manquantes sont stockées dans l'espace de stockage intermédiaire en suivant l'algorithme illustré à la figure 7 et qui sera décrit ultérieurement. Lors de cette étape, le stockage des données est effectué dans un fichier qui contient toutes les données relatives au signal numérique d'image 30 considéré et à un même type d'entités élémentaires (ex: precincts). Plus particulièrement, le fichier de stockage est formé par concaténation de l'ensemble des incréments d'entités élémentaires de même type relatives au signal considéré et qui transitent par l'unité intermédiaire 12. L'étape S15 est ensuite suivie de l'étape S11 qui prévoit l'élaboration d'une réponse JPIP correspondant à la requête client et incluant, notamment, les données manquantes fournies par le serveur ainsi que la transmission de cette réponse à la machine client considérée. L'étape S11 est ensuite suivie de l'étape S12 déjà décrite ci-dessus mettant fin à l'exécution de cet algorithme. Comme annoncé plus haut, on va maintenant décrire l'algorithme de la figure 6 qui vient détailler les opérations effectuées au cours de l'étape S7 de la figure 5 concernant le traitement d'une requête JPIP au sein de l'unité intermédiaire 12. Les données fournies en entrée de cet algorithme sont les suivantes: la requête client à traiter; le résultat de l'analyse de cette requête effectuée à l'étape S2 de l'algorithme de la figure 5 et qui fournit notamment la quantité de données souhaitées en retour (analyse du champ "len"), ainsi qu'un ensemble d'incréments de données d'entités élémentaires souhaités noté: B={( Csn k, Classld k, inClassld k, MsgOffset k), k=1, ..., numBins}; dans l'expression ci-dessus, "numBins" représente le nombre d'incréments d'entités élémentaires spécifiés dans la requête; et le fichier de cache correspondant à la requête et déterminé à l'étape S3 de l'algorithme de la figure 5. La première étape S20 de l'algorithme consiste à se positionner au début du fichier de cache considéré. Etant donné la stratégie de construction progressive de ce cache qui sera abordée plus loin, le début du fichier correspond au début du premier message de retour contenu dans le fichier. L'étape suivante S21 prévoit donc de lire et de décoder l'en-tête du message de retour situé à la position courante notée pos dans le fichier et donc d'identifier, via les valeurs Classld, inClassld et Csn obtenues, l'élément "databin" correspondant au message courant. On obtient également les valeurs MsgOffset et MsgLength indiquant quel incrément d'entité élémentaire (incrément courant) est transporté dans le message de retour. Un test est alors pratiqué à l'étape suivante S22 afin de déterminer si le message courant est pertinent vis-à-vis de l'ensemble B des incréments spécifiés dans la requête. On cherche pour cela si l'ensemble B contient un incrément dont l'indice du premier octet demandé est inférieur à la valeur MsgOffset+MsgLength. Dans l'affirmative, alors l'incrément courant est pertinent par rapport à la requête traitée. On détermine alors à l'étape S23 si le budget en octets autorisé (fourni par l'indication de taille du champ "len") permet d'insérer le message de retour courant dans la réponse en cours de formation. Dans l'affirmative, alors on ajoute le message courant dans la réponse en cours d'élaboration (étape S24). Dans la négative, on supprime l'incrément de l'ensemble B précédent (étape S26). On utilise ainsi la taille des données de réponse souhaitées pour sélectionner des incréments d'entités élémentaires à fournir à une machine client. Si le résultat du test pratiqué à l'étape S22 est négatif, alors on passe à l'étape S25 qui sera décrite plus loin. On avance ensuite d'une longueur égale à MsgLength octets dans le fichier de cache considéré pour adopter une nouvelle position courante "pos" dans le fichier (étape S25). Au cours de l'étape suivante S27, on détermine si la position courante correspond à la fin de fichier. Dans la négative, on boucle sur l'étape de lecture et de décodage de l'entête du prochain message de retour dans le fichier de cache (étape S21). L'algorithme prend fin à l'étape S28 lorsque la position courante dans le fichier de cache correspond à la fin de ce fichier. A la fin de l'algorithme, un ensemble d'incréments d'entités élémentaires à transmettre au client est formé. Il reste alors à l'unité intermédiaire à former le paragraphe d'en-tête http approprié à l'ensemble de données utiles formé et à l'associer à cet ensemble pour former une réponse http conforme. Comme annoncé plus haut, on va maintenant décrite la figure 7 qui propose un algorithme très simple de construction d'un fichier de cache JPIP par l'unité intermédiaire 12 de la figure 1 et qui détaille les opérations effectuées au cours de l'étape S15 de l'algorithme de la figure 5. Suite à une requête transmise au serveur par l'unité 12 (étapes S8 et S13 de la figure 5), cette dernière reçoit à l'étape S30 (figure 7) la réponse correspondante (cette étape correspond aussi à l'étape S14 de la figure 5. Un test est pratiqué à l'étape suivante S31 et si la réponse contient l'en-tête http "Cache-Control: no-cache4", alors l'unité 12 n'est pas autorisée à stocker la réponse dans son cache et l'algorithme prend fin (étape S32). Dans le cas contraire, le processus de stockage a lieu et la suite de l'algorithme prévoit d'extraire (étape S33) les champs JPIP-tid ainsi que les en-têtes HTTP "JPIP-type:" ou "Content-Type:". Ces deux champs ont la même utilité : indiquer le type des données de réponse (JPP-STREAM ou JPTSTREAM) utilisé pour l'émission de la réponse à la machine client concernée. Dans le cas où le protocole JPIP est utilisé sur http, l'entête "Content-Type:" peut être utilisé à la place de "JPIP-type:". La combinaison de l'en-tête "JPIP-tid:", d'une part, et des en-têtes "JPIP-type" ou "Content-Type:", d'autre part, permet à l'étape suivante S34 de déterminer le fichier de cache utilisé dans l'espace de stockage intermédiaire 14 pour stocker les données de réponse. Dans le cas où l'unité intermédiaire a répondu partiellement à une requête (étape S9 de la figure 5) et que la réponse courante sert à compléter la réponse partielle de l'unité intermédiaire, on vérifie que c'est le même fichier de cache qui a été déterminé par les algorithmes des figures 5 (étape S3) et 7 (étape S34). Dans le cas où le fichier de cache déterminé n'existe pas, il est alors créé. L'étape suivante S35 consiste à extraire le corps de la réponse fournie par le serveur 10 à l'étape S30. Un test est ensuite pratiqué à l'étape S36 et si l'en-tête http "TransferEncoding: chunked" est présent dans la réponse, alors le stockage des données consiste à extraire chaque bloc de données ("chunk" en anglais) de la réponse et à concaténer son contenu à la fin du fichier de cache. Plus particulièrement, l'étape S36 est suivie d'une étape S37 qui procède à la lecture de la longueur 1 du prochain bloc ("chunk") dans la réponse fournie par le serveur. Un test est pratiqué au cours de l'étape suivante S38 afin de déterminer si cette longueur est nulle et, dans l'affirmative, il est mis fin à l'algorithme conformément à l'étape S32 précédemment évoquée. Dans le cas contraire, l'étape S38 est suivie d'une étape S39 au cours de laquelle il est prévu d'extraire les I prochains octets (correspondant aux blocs de données précités) du corps de la réponse du serveur. Au cours de l'étape suivante S40, ces données extraites sont écrites à la fin du fichier de cache et l'étape S37 déjà décrite est alors à nouveau exécutée à l'égard du prochain bloc de données. De retour à l'étape S36, en cas de réponse négative, l'en-tête 20 "Content-length:" doit être présent dans la réponse et celui-ci fournit la longueur du corps de la réponse. Il suffit alors d'extraire ce corps et de le concaténer à la fin du fichier de cache (étape S41), ce qui met fin à l'algorithme (étape S32). La figure 8 illustre la structure du fichier cache qui a été élaboré 25 grâce à l'algorithme de la figure 7 au fur et à mesure que des données de retour provenant du serveur 10 transitent par l'unité 12. Ce fichier comprend un en-tête principal destiné à permettre la détermination du fichier de cache correspondant à une requête provenant d'un client (étape S34 de la figure 7). L'en-tête principal de fichier de cache collecte donc des informations identifiant l'image, la version de l'image stockée dans ce fichier de cache, l'adresse du serveur d'où provient l'image et le media type JPIP auquel se conforment les données binaires JPIP stockées dans le fichier de cache. Comme l'indique la figure 8, ces informations proviennent donc respectivement des champs de requête "target", "subtarget" (définis précédemment), des champs de réponse "JPIP-tid" et "JPIP-type" (fournis par le serveur pour associer un identifiant unique et un type à un flux de retour, en réponse aux champs de requête "tid" et "type" définis précédemment), et de l'adresse du serveur d'où provient ce flux de retour JPIP. La suite du fichier contient une suite de messages binaires conformes à l'un des deux media types JPP-STREAM et JPT-STREAM définis précédemment. Conformément à la définition des media types JPIP et comme l'indique la figure 8, chacun de ces messages possède un en-tête et un corps. Le premier message de réponse JPIP 200 comprend un en-tête 202 comportant les éléments suivants: Bin-ID, Csn, MsgOffset, MsgLength, Aux et un corps de message 204 comprenant des données au format JPEG2000 (incréments de data-bins ou d'entités élémentaires, d'une longueur égale à Msg-Length octets. De façon identique, d'autres messages de réponse JPIP sont concaténés (deuxième message 206, troisième message 208...). On notera que chacun des messages binaires correspond à une requête préalablement envoyée par l'unité intermédiaire 12 et l'ensemble de ces messages de retour reçus par l'unité intermédiaire en provenance du serveur 10 sont concaténés tels quels à la fin du fichier de cache au fur et à mesure de leur réception. Dans l'exemple de réalisation, les données de réponse provenant du serveur 10 sont conformes à l'un des deux média types JPP-STREAM ou JPTSTREAM. II convient de noter que le mécanisme de construction progressive d'un fichier de cache dans l'espace de stockage intermédiaire 14 de la figure 1 peut s'appliquer à des données transmises dans les deux modes d'utilisation du protocole JPIP, à savoir le mode sans état et le mode avec état. On notera que l'invention s'applique notamment à des requêtes JPIP présentant un champ "need" spécifiant des incréments d'entités élémentaires ("precinct data-bin") avec des indices d'octets. Un champ "Ien" peut être présent et utilisé pour sélectionner les incréments d'entités élémentaires à retourner à la machine client, par exemple, en limitant la quantité de données retournées. Par ailleurs, si le champ "model" est utilisé à la place du champ "need", l'unité intermédiaire 12 est capable de traiter la requête si le champ "model" prend la forme suivante: mode)=M*, H m, H*, P*,-P0:121,-Pl:231,P3. Dans ce cas, le champ "model" est équivalent au champ "need" suivant: need=P0:121,P1:231,P3 et peut être traité par l'unité 12. De même, dans le cas où le media type JPT-STREAM est utilisé pour une image donnée, la présente invention s'applique également pour des requêtes "sans état" dont le champ "tpmodel" prend la forme suivante: tpmodel=0.0-65535,-4.0-5.2, l'expression d'un tel champ "tpmodel" signifiant que le client veut les parties de tuile 0, 1 et 2 des tuiles 4 et 5. La description qui précède fournit une méthode simple et efficace pour stocker des données d'un flux multimédia, par exemple de type JPPSTREAM et JPT-STREAM, dans un cache intermédiaire, et pour traiter simplement certaines requêtes, par exemple conformes au protocole de communication JPIP, à l'aide des données stockées dans le cache. Des mécanismes complémentaires proposés ci-dessous peuvent être introduits afin que l'unité intermédiaire 12 puisse traiter un plus grand nombre de requêtes. Une variante consiste à ajouter des informations spatiales dans les réponses du serveur 10 à destination de l'unité 12. Ces informations peuvent, par exemple, informer l'unité 12 pour chaque élément "tile databin" ou "precinct data-bin" de la zone spatiale (position, taille et niveau de résolution) que l'entité élémentaire considérée sert à reconstruire. L'unité 12 stocke alors une table de correspondance entre le ou les indices de precinct ou de tuile et la zone spatiale de reconstruction et enrichit cette table au fur et à mesure que des données de retour JPIP lui parviennent, couplées à ces informations spatiales. L'avantage de cette variante est qu'elle permet à l'unité 12 de déterminer les entités élémentaires (ou les data-bins ), par exemple de type JPIP, contenues dans son cache et pertinentes par rapport à une fenêtre d'intérêt spécifiée dans une requête. Cette variante permet de traiter toute requête de fenêtre de visualisation, par exemple de type JPIP, en utilisant le champ "Ien" pour contrôler le débit des réponses. Selon une autre variante, l'unité 12 est munie d'un outil d'analyse des incréments d'entités élémentaires de type "Metadata", "Main Header" et "Tite Header" contenus dans ses fichiers de cache JPIP, ainsi que des outils d'analyse d'une fenêtre de visualisation d'une requête JPIP. L'unité 12 détermine les precincts ou tuiles nécessaires à la reconstruction de la fenêtre de visualisation spécifiée dans la requête à partir de la requête et des tailles des precincts ou tuiles déduites des en-têtes principaux JPEG2000 qui sont stockés dans le cache de l'unité 12. Cette tâche ne nécessite pas de décoder des en-têtes de paquets JPEG2000 et est donc de faible complexité. (è 28 REVENDICATIONS 1. Procédé de gestion du traitement d'une requête d'au moins une machine client dans un réseau de communication comportant une unité de traitement qui est distincte de la machine client et d'un serveur distant et qui est associée à un espace de stockage intermédiaire, caractérisé en ce que la requête comporte des informations et notamment identifie au moins une zone d'un signal numérique d'image ou de vidéo et au moins une entité élémentaire (P) relative à cette zone, le procédé comportant les étapes suivantes effectuées par l'unité de traitement: - détermination, à partir d'informations présentes dans la requête, des données nécessaires à la machine client sous la forme d'au moins un incrément (P, Ien) de données d'entité élémentaire, ledit au moins un incrément comprenant des données d'entité élémentaire qui sont complémentaires de données d'entité élémentaire déjà présentes dans la machine client, - identification, dans l'espace de stockage intermédiaire, des données stockées qui sont relatives au signal numérique, les données stockées étant présentes sous la forme d'au moins un incrément de données d'entité élémentaire, comparaison des données nécessaires avec les données stockées identifiées, - en fonction du résultat de la comparaison, décision quant à savoir si l'unité de traitement est apte à émettre des données nécessaires vers la machine client. 2. Procédé selon la revendication 1, caractérisé en ce que la requête identifie au moins une entité élémentaire et une quantité de données relatives à cette entité élémentaire et qui sont déjà présentes dans une mémoire associée à la machine client. 3. Procédé selon la revendication 2, caractérisé en ce que, à partir de la quantité de données exprimée en nombre d'octets, l'étape de détermination identifie l'octet d'au moins un incrément de données d'entité élémentaire à partir duquel la machine client souhaite recevoir les octets suivants. 4. Procédé selon la revendication 1, caractérisé en ce que la requête identifie au moins un incrément de données d'entité élémentaire que souhaite recevoir la machine client à partir de son point de départ dans l'entité élémentaire. 5. Procédé selon la revendication 4, caractérisé en ce que le point de départ dudit au moins un incrément identifie un octet de l'entité élémentaire à partir duquel la machine client souhaite recevoir les octets suivants de l'entité élémentaire. 6. Procédé selon l'une des revendications 4 et 5, caractérisé en ce qu'il comporte, préalablement à l'étape de détermination, une étape d'analyse d'un champ spécifique présent dans la requête et fournissant une liste du ou des incréments d'entité(s) élémentaire(s) que souhaite recevoir la machine client. 7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que, lorsque l'étape de comparaison fait apparaître qu'au moins une partie des données nécessaires est contenue dans un ou plusieurs incréments de données d'entité(s) élémentaire(s) identifiés dans l'espace de stockage intermédiaire, le procédé comporte une étape d'émission de ce ou ces incréments d'entité(s) élémentaire(s) vers la machine client. 8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce qu'il comporte en outre une étape de détermination de la présence dans la requête d'un champ indiquant la taille des données de réponse (len) et, en cas de présence, d'utilisation de cette indication de taille pour la sélection d'incréments d'entité(s) élémentaire(s) à émettre vers la machine client. 9. Procédé selon l'une des revendications 1 à 8, caractérisé en ce que, lorsque le résultat de l'étape de comparaison fait apparaître que des données nécessaires, appelées données manquantes, ne sont pas contenues dans l'espace de stockage intermédiaire, le procédé comporte une étape d'émission vers le serveur d'une requête spécifiant les données manquantes. 10. Procédé selon la revendication 9, caractérisé en ce qu'il comporte une étape de stockage, dans l'espace de stockage intermédiaire, des données manquantes reçues du serveur. 11. Procédé selon la revendication 10, caractérisé en ce que le stockage est effectué dans un fichier qui contient toutes les données relatives à un même signal et à un même type d'entités élémentaires. 12. Procédé selon la revendication 11, caractérisé en ce que le fichier de stockage est formé par concaténation de l'ensemble d'incréments d'entité(s) élémentaire(s) de même type relatives au signal et transitant par l'unité de traitement. 13. Procédé selon l'une des revendications 9 à 12, caractérisé en ce qu'il comporte une étape de réception en provenance du serveur et de stockage, dans l'espace de stockage intermédiaire, d'informations sur la zone spatiale du signal dont font partie les données manquantes. 14. Procédé selon l'une des revendications 9 à 12, caractérisé en ce qu'il comporte une étape d'analyse, dans l'unité de traitement, d'une fenêtre de visualisation spécifiée dans la requête afin d'en déduire les entités élémentaires concernées par la requête. 15. Procédé selon l'une des revendications 10 à 14, caractérisé en ce qu'il comporte une étape d'émission vers la machine client de toutes les données nécessaires relatives aux incréments de données d'entité(s) élémentaire(s) déterminés à partir de la requête, incluant les données manquantes. 16. Procédé selon l'une des revendications 1 à 15, caractérisé en ce que les requêtes et les données de réponse aux requêtes sont établies conformément au protocole de communication JPIP. 17. Procédé selon l'une des revendications 1 à 16, caractérisé en ce que les entités élémentaires sont choisies parmi les méta-données d'un signal numérique d'image conforme à la norme JPEG2000, les données d'en-tête de ce signal et les ensembles de blocs de données ayant la même localisation spatiale dans différentes sous-bandes de fréquence d'un même niveau de résolution du signal. 18. Dispositif de gestion du traitement d'une requête d'au moins une :30 machine client dans un réseau de communication comportant une unité de traitement qui est distincte de la machine client et d'un serveur distant et qui est associée à un espace de stockage intermédiaire, caractérisé en ce que la requête comporte des informations et notamment identifie au moins une zone d'un signal numérique d'image ou de vidéo et au moins une entité élémentaire (P) relative à cette zone, le dispositif comportant: des moyens de détermination, à partir d'informations présentes dans la requête, des données nécessaires à la machine client sous la forme d'au moins un incrément (P, len) de données d'entité élémentaire, ledit au moins un incrément comprenant des données d'entité élémentaire qui sont complémentaires de données d'entité élémentaire déjà présentes dans la machine client, - des moyens d'identification, dans l'espace de stockage intermédiaire, des données stockées qui sont relatives au signal numérique, les données stockées étant présentes sous la forme d'au moins un incrément de données d'entité élémentaire, - des moyens de comparaison des données nécessaires avec les 15 données stockées identifiées, - des moyens de décision quant à savoir si l'unité de traitement est apte à émettre des données nécessaires vers la machine client en fonction du résultat de la comparaison. 19. Dispositif selon la revendication 18, caractérisé en ce que la requête identifie au moins une entité élémentaire et une quantité de données relatives à cette entité élémentaire et qui sont déjà présentes dans une mémoire associée à la machine client. 20. Dispositif selon la revendication 18, caractérisé en ce que la requête identifie au moins un incrément de données d'entité élémentaire que souhaite recevoir la machine client à partir de son point de départ dans l'entité élémentaire. 21. Dispositif selon l'une des revendications 18 à 20, caractérisé en ce qu'il comporte des moyens d'analyse d'un champ spécifique présent dans la requête et fournissant une liste du ou des incréments d'entité(s) élémentaire(s) que souhaite recevoir la machine client. 22. Dispositif selon l'une des revendications 18 à 21, caractérisé en ce qu'il comporte des moyens d'émission d'un ou de plusieurs incréments d'entité(s) élémentaire(s) vers la machine client lorsque la comparaison fait apparaître qu'au moins une partie des données nécessaires est contenue dans ce ou ces incréments de données d'entité élémentaire identifiés dans l'espace de stockage intermédiaire. 23. Dispositif selon l'une des revendications 18 à 22, caractérisé en ce qu'il comporte en outre des moyens de détermination de la présence dans la requête d'un champ indiquant la taille des données de réponse (len) et, en cas de présence, d'utilisation de cette indication de taille pour la sélection d'incréments d'entité(s) élémentaire(s) à émettre vers la machine client. 24. Dispositif selon l'une des revendications 18 à 23, caractérisé en ce qu'il comporte des moyens d'émission vers le serveur d'une requête spécifiant les données manquantes lorsque le résultat de la comparaison fait apparaître que des données nécessaires, appelées données manquantes, ne sont pas contenues dans l'espace de stockage intermédiaire. 25. Dispositif selon la revendication 24, caractérisé en ce qu'il comporte des moyens de stockage, dans l'espace de stockage intermédiaire, des données manquantes reçues du serveur. 26. Dispositif selon l'une des revendications 24 à 25, caractérisé en ce qu'il comporte des moyens de réception en provenance du serveur et de stockage, dans l'espace de stockage intermédiaire, d'informations sur la zone spatiale du signal dont font partie les données manquantes. 27. Dispositif selon l'une des revendications 24 à 25, caractérisé en ce que l'unité de traitement comporte un outil d'analyse d'une fenêtre de visualisation spécifiée dans la requête afin d'en déduire les entités élémentaires concernées par la requête. 28. Dispositif selon l'une des revendications 18 à 27, caractérisé en ce qu'il comporte des moyens d'émission vers la machine client de toutes les données nécessaires relatives aux incréments de données d'entité(s) élémentaire(s) déterminés à partir de la requête, incluant les données manquantes. 29. Moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé de gestion du traitement de requêtes selon l'une des revendications 1 à 17. 30. Programme d'ordinateur chargeable dans un appareil programmable, caractérisé en ce qu'il comporte des séquences d'instructions ou des portions de code logiciel pour mettre en oeuvre les étapes du procédé de gestion du traitement de requêtes selon l'une des revendications 1 à 17, lorsque ce programme d'ordinateur est chargé et exécuté par l'appareil programmable.