FR2838268A1 - Dispositif de compression de donnes a la volee de mise en oeuvre facilitee - Google Patents
Dispositif de compression de donnes a la volee de mise en oeuvre facilitee Download PDFInfo
- Publication number
- FR2838268A1 FR2838268A1 FR0204248A FR0204248A FR2838268A1 FR 2838268 A1 FR2838268 A1 FR 2838268A1 FR 0204248 A FR0204248 A FR 0204248A FR 0204248 A FR0204248 A FR 0204248A FR 2838268 A1 FR2838268 A1 FR 2838268A1
- Authority
- FR
- France
- Prior art keywords
- compression
- module
- request
- data
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- 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/04—Protocols for data compression, e.g. ROHC
-
- 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- 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/565—Conversion or adaptation of application format or content
- H04L67/5651—Reducing the amount or size of exchanged application data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/563—Data redirection of data network streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
-
- 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]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Information Transfer Between Computers (AREA)
Abstract
L'invention concerne un procédé de compression à la volée de données fournies par un serveur (40) d'un réseau collectif tel qu'internet en réponse à une requête d'un terminal de consultation (30), dans lequel procédé on fournit un module de compression de données (20), et un module de redirection (10) prévu pour recevoir des données fournies par le serveur (40) et les rediriger vers le module de compression (20), ce module de redirection (10) étant également prévu pour recevoir des données depuis le module de compression (20) et les rediriger vers le terminal de consultation (30), procédé selon lequel on examine dans la requête une indication concernant une aptitude à la décompression du terminal (30) et on effectue dans le module de compression (20), sur les données demandées par la requête et fournies par le serveur (40) une compression qui est adaptée aux indications d'aptitude contenues dans la requête.
Description
de communication qui doit être fournie à un utilisateur du terminal.
L'invention concerne les outils de compression de données à la volée
utilisés sur les réscaux, et en particulier sur Internet.
Ces outils visent à optimiser le flux ou " bande passante " et augmenter ainsi la vitesse d'affichage des informations au niveau du client internaute. Pour le client, ces outils permettent une réduction du temps de chargement des contenus, c'est à dire une meilleure perception de la qualité de service (QoS) et également une réduction des coûts lorsque la
connexion est facturée au volume.
Il existe à ce jour plusieurs solutions d'accélération de flux sur le réseau internet, appelées Booster Web, qui répondent à cette problématique, mais aucune ne correspond à une réelle offre en c_ur de
réseau, applicable de manière simple à différents types d 'utilisateurs.
Les Booster avec client nécessitent l'installation d'un module particulier sur ie poste du client. Ce module local on plug'in va en fait modifier la structure des messages échangés entre le client et le booster. A la communication selon le protocole habituel HTTP (Hypertext Transport
Protocol) se substitue un protocole propriétaire.
Les Booster " TCP " modifient la structure des messages, d'autres se contentent de modifier la logique de reprise d'envoi TCP en l'adaptant au
temps de réponse du réseau comme les téléphones mobiles par exemple.
Les Booster sans client ne modifient pas les messages http port 80, ils utilisent des entêtes classiques. Mais il est alors indispensable de les déclarer dans les propriétés des navigateurs comme on le ferait pour un cache classique. De plus, certains boosters possèdent aussi une fonction " cache " et d'autres annoncent étre conformes au protocole ICP (protocole
de communication entre caches).
Ces solutions nécessitent donc d'intervenir sur les logiciels installés au niveau de l'ordinateur de l'internaute et sont donc loin d'être
transparentes pour l'utilisateur.
On se propose selon l'invention de résoudre cet inconvénient, c'est à dire de proposer un outil et un procédé de compression de données à la volée qui soit transparent pour l'internaute, c'est à dire qui ne nécessite pas
d'intervention sur l'ordinateur ou le réscau local de celui-ci.
Ce but est atteint selon l' invention grâce à u n procédé de compression à la volée de données fournies par un serveur d'un réseau collectif tel qu'internet en réponse à une requête d'un terminal de consultation, dans lequel procédé on fournit un module de compression de données, et un module de redirection prévu pour recevoir des donnces fournies par le serveur et les rediriger vers le module de compression, ce module de redirection étant également prévu pour recevoir des données depuis le module de compression et les rediriger vers le terminal de consultation, procédé selon lequel on examine dans la requête une indication concernant une aptitude à la décompression du terminal et on effectue dans le module de compression, sur les donnces demandées par la requête et fournies par le serveur une compression qui est adaptée aux
indications d'aptitude contenues dans la requête.
On propose également selon l'invention un dispositif de compression de données à la volée dans un réscau collectif tel que le réseau Internet, comprenant un module de compression et un module de redirection, ce module de redirection étant prévu pour recevoir des données fournies par un serveur en réponse à une requête de consultation émise par un terminal de consultation, et rediriger ces données vers le module de compression, ce module de redirection étant également prévu pour recevoir des données fournies en retour par le module de compression et les rediriger vers le terminal de consultation, ce dispositif incluant en outre des moyens pour examiner, dans une requête de consultation de donnces émise par un terminal, une indication concernant une aptitude à la décompression du terminal considéré, et des moyens pour commander une compression par le module de compression qui est adaptée à l'indication d'aptitude à la
décompression contenue dans la requête.
D'autres caractéristiques7 buts et avantages de l'invention
appara^tront mieux à la lecture de la description détaillée qui va suivre, faite
en référence aux figures annexées sur lesquelles: - la figure 1 est un schéma simplifié d'un ensemble de compression de donnces selon l'invention; - la figure 2 est un autre schéma simplifié d'un ensemble selon l'invention; - la figure 3 représente de manière détaillée ce même ensemble selon l'invention; - la figure 4 représente de manière détaillée un serveur iCAP conforme à une variante de l'invention; - la figure 5 est un organigramme représentatif d'un procédé selon une variante de l'invention; - la figure 6 est un organigramme de donnces et d'instructions selon
une variante de l'invention.
Le dispositif décrit ci-après utilise un protocole d'échange de données destiné à permettre des modifications de contenus sur l'internet,
protocole appelé iCAP - Internet Content Adaptation Protocol -.
Le dispositif de la figure 1 est architecturé autour de deux modules 10 et 20 de type iCAP, à savoir un cache 10 du type iCAP client et un serveur 20 de modification de contenu, du type serveur iCAP à " modification de réponse " selon la terminologie énoncée par le protocole iCAP. Lorsqu'un utilisateur demande, par l'intermédiaire d'un logiciel navigateur fonctionnant sur son ordinateur personnel 30, à accéder à une page Web, les étapes suivantes sont mis en _uvre dans le dispositif de la
figure 1.
D'abord une requête HTTP est envoyée vers le cache 10, également appelé << proxy cache 10 ", configuré dans le navigateur de l'utilisateur 30 (mais ce pourrait tout aussi bien être un proxy cache fonctionnant en mode
transparent dans le cadre d'un ISP - Internet Service Provider -).
Le cache 10 envoie alors une requête HTTP à un serveur Web
d'origine 40, contenant cette page.
Le serveur Web 40 renvoie la page demandée au cache 10.
Le cache 10 agissant maintenant comme client iCAP redirige cette réponse vers le serveur iCAP 20 précédemment mentionné, en lui faisant
passer la page complète.
Le serveur iCAP 20 traite alors cette demande en faisant appel à un service de modifications de contenus intégré au serveur, puis répond au cache 10 en renvoyant le résultat du traitement: la page modifiée (ou non
comme on le verra par la suite).
Enfin, le cache 10 retourne à l'utilisateur final 30 ia réponse du
serveur iCAP 10 et stocke également cette réponse.
Le scénario que nous décrivons ici se déroule lorsque le cache 10 ne possède pas déjà le document demandé en mémoire, dans le cas contraire il répond immédiatement à l'utilisateur en renvoyant la page qu'il a précédemment stockée (c'est à dire soit la page originale, soit la page
modifiée si la modification de celle-ci s'est avérée opportune).
Le cache 10 de type " client iCAP " est à ce jour disponible sur le
marché dans une version industrielle.
Le principe du protocole iCAP repose sur une base simple: à toute requête HTTP correspond une réponse provenant d'un serveur Web ou d'un cache: il suffit donc de transformer soit la requête, soit la réponse pour offrir un service de transformation de contenu. iCAP propose deux modes principaux (" Request Modification " et " Response Modification ") qui sont
basés sur le protocole HTTP.
Le rôle d'iCAP n'est pas d'effectuer lui-même la transformation de contenu. Il se limite juste à relier des " iCAP clients " (caches Web, routeurs....) avec des " iCAP serveurs ", ces derniers étant responsables
de la transformation.
Le iCAP forum (http://www.i-cap.orq) a été créé en décembre 1999 sous l'impuision des sociétés Network Appliance et Akamai. Son objectif est de standardiser, au travers du protocole iCAP (Internet Content Adaptation, Protocol), les échanges entre les équipements représentatifs des architectures du Web (serveurs Web, caches, load balancers, routeurs...) et
les systèmes de transformation de contenu.
s La spécification ICAP 1.25 est la plus récente. Elle a déjà fait l'objet de plusieurs implémentations dans le cadre des services à valeur ajoutée de transformation de fichiers dont voici quelques exemples: - filtrage de virus - filtrage de contenu Le protocole iCAP a aussi été soumis le 27 novembre 2000 à l'IETF (Internet-Draft " iCAP the internet content adaptation protocol " hitp:/lwww.ietf.orq/internet-drafts/draftelson-opes-icap-00.txt) dans le
Working Group (groupe de travail) Open Proxy Extensible Services.
11 n'existe pas beaucoup d'implémentations techniques de services utilisant le protocole iCAP. Seuis les éditeurs de logiciel d'Anti-virus bénéficiant de leur savoir-faire en solutions réseaux s'installant sur des FireWall (rideau de feu) ou des proxies (mandataire) proposent un portage
de leurs services sur iCAP.
On voit aussi l'apparition de nouveaux intervenants commerciaux
dans le domaine du filtrage de contenu.
Mais pour toutes les autres applications éventuellement envisagées, I'investissement de départ reste lourd et coûteux. Ceci explique encore
pourquoi les services à valeur ajoutée utilisant iCAP tardent à sortir.
Utilisant ici le protocole ICAP et notamment le fait de récupérer des flux provenant des serveurs WEB via un module de redirection iCAP, ici constitué par le cache 10, on met en _uvre un procédé de compression à
la volée particulièrement avantageux.
Le fonctionnement du présent outil de compression iCAP, ou " ICAP Zipper ", peut se représenter simplement par le schéma générique de la
figure 2.
Les étapes principales du service de compression sont les suivantes:
a) le client 30 émet une requête à destination d'un serveur Web 40.
Cette requête passe éventuellement par un équipement de redirection, ici le
cache 10.
b) le serveur 40 transmet sa réponse au client 30 par l'intermédiaire
du cache 10.
c) le service de redirection 10 (client iCAP) redirige la réponse vers le serveur iCAP 20. On dénommera ci-après ce serveur par l'expression plus générale " module de compression 20 " afin de qualifier la fonction
principale de ce serveur.
d) la réponse du serveur 40 est si possible compressée et/ou
optimisoe par le module de compression 20.
e) le module de compression 20 renvoie la requête au module de
redirection 10.
f) le module de redirection 10 renvoie la réponse au client 30.
g) le navigateur client 30 décompresse automatiquement le
document reçu avant de l'afficher.
La décompression automatique des données du côté client est une fonctionnalité définie dans le protocole HTTP 1.1 (Standard IETF défini par la RFC 2616). Cette fonctionnalité se retrouve ainsi dans la majorité des navigateurs actuels qui intègrent un mécanisme de décompression de type gzip (Internet Explorer - marque déposée - de Microsoft, version 4 et supérieures, Netscape Communicator (marque déposée) de Netscape,
version 4 et supérieures).
Ce système de compression (sans client spécifique ni module local ou plug'in -) offre l'avantage de ne pas intervenir sur les logiciels installés au niveau de l'ordinateur 30 de l'internaute (ou au niveau du téléphone mobile
ou de tout autre terminal de consultation utilisé).
Ce service de compression ne modifie pas non plus les couches réseaux et protocolaires, ce qui évite les incompatibilités éventuelles avec d'autres types de services ou d'équipements qui seraient situés entre le
service de compression et l'utilisateur final.
Les figures 3 et 4 représentent de manière plus détaillée le dispositif préférentiel décrit ici. Sur ces figures, le module de compression 20 (ou module iCAP de transformation de contenu), se décompose en un module administrateur 22, un module adaptateur de flux 23, et un module de service ou sous-module 25 dédié spécifiquement aux tâches de
compression des données.
L'adaptateur de flux 23 a pour fonction d'adapter les contenus entre
le module de redirection (client iCAP 10) et le module de service 25.
Un tel adaptateur de flux 23 est préférentiellement prévu pour adapter les flux de données également pour une série d'autres modules de services supplémentaires, mettant en _uvre des services autres que la compression, ces modules pouvant par exemple être des modules de
filtrage de contenu ou des modules de filtrage anti-virus.
L'adaptateur 23 est situé dans le module de compression 20, pour d'une part, dans le sens client 10 - serveur 20, adapter les fichiers pour qu'ils puissent être directement utilisés pour les services de transformation de fichier, et d'autre part, dans le sens serveur 20 client 10, assurer un
contrôle d'intégrité du fichier transformé et éventuellement sa reconstitution.
L'adaptateur 23 permet de formaliser les échanges entre le module de redirection 10 (client iCAP) et le module de service 25 (service de transformation de fichier) grâce à une adaptation des flux iCAP pour les rendre compatibles avec le module de service de compression 25, ainsi qu'avec d'autres modules correspondant à des services de transformation de fichier, sans qu'il soit nocessaire de développer une couche iCAP au niveau de ces services. Ceci permet alors de définir des services de transformation de fichiers, modulaires, évolutifs et indépendants des
couches iCAP.
Ainsi, on récupère les flux provenant des serveurs Web via un adaptateur de contenus iCAP et on les convertit ensuite au format Zip, qui
est un format de décompression habituel.
On voit ciairement sur la figure 4 que le module de service 25 est structurellement intégré à la couche iCAP, ce qui signifie que le module de service 25, c'est à dire la partie spécifique au service de compression, est ici très simple à réaliser, notamment en adoptant l'architecture fonctionnelle
d'un adaptateur de flux iCAP tel que précédemment décrit.
Le service ou procédé général décrit ici va donc permettre de compresser les contenus http, par exemple les objets encodés au format htm, html, pour optimiser les taux de transfert et ce en c_ur de réseau et de
manière transparente pour le client.
Pour mettre en _uvre ce service, on met en place une détection des
capacités du navigateur 30 à décoder un contenu compressé.
La connaissance de ces propriétés différentie particulièrement le présent compresseur iCAP (ou l'iCAP Zipper) des autres systèmes de Booster, qui ne sont valables que pour un type de client donné ou une
configuration réseau particulière.
Le présent ensemble de compression est de ce fait capable de prendre dynamiquement en compte les particularités des clients et ainsi
d'adapter la compression à la volée.
Lors de l'envoi d'une requête http vers un serveur Web 40, le navigateur 30 annonce, dans l'entête de cette requête, I'ensemble des
caractéristiques qualifiant ce navigateur.
Le module de compression 20 (serveur iCAP) va alors tester
l'existence d'une ligne " Accept-encoding " dans la requête http.
Si cette ligne n'existe pas, cela signifie que le navigateur 30 n'accepte aucune page compressée. Le module de compression 20 doit
alors renvoyer les pages sans les modifier.
Si cette ligne existe, le serveur 20 doit regarder la valeur des types d'éléments compressés qui sont acceptés par les navigateurs pour choisir
un bon encodeur ou sous-module de compression.
Le module de service 25 modifie alors le contenu de l'entête à retourner au client 30, compresse les données, et les retourne au
navigateur 30 via le moduie de redirection 10.
Le module de service 25 réailsant spécifiquement la compression de contenus, fonctionne donc ici nativement en mode " modification de
réponse ".
La procédure de compression exécutée dans ce dispositif d'ensemble, mise en _uvre selon une méthode " Data Analysis " de la classe CicapServiceZip, est la suivante, ici détaillée selon une série
d'étapes A) à 1) également représentées sur le diagramme de la figure 6.
La procédure décrite ici est réalisée à l'aide d'un module de compression 20 conforme à l'architecture représentée sur la figure 4, mais comportant plusieurs modules de service 25 intogrés dans le même serveur iCAP 20, ces différents modules de service 25 correspondant chacun à une
compression d'un type d'objet différent.
On fait abstraction ici des étapes relatives à la préparation des
différents objets passés au module de compression 20.
On précise simplement que l'entête de la requête de consultation initialement émise par le terminal 30 se voit transmise au module de compression 20, par le module de redirection 10, associée aux donnces
fournies par le serveur 40 en réponse à une telle requête.
Les objets pa ssés sont, p lu s gén é ra l em ent, des objets correspond ant aux différentes entêtes http relatives au client 10, au serveur 20, et au
contenu fourni.
A) Le module de compression 20 recherche dans l'entête de requête client la chane " Accept Encoding >>, permettant de savoir si le contenu peut être compressé. Si la valeur n'est pas égale à " gzip " ou " deflate " ou si la chane n'existe pas, aucune compression n'est effectuce (passage
au point I ci-après).
B) Le module de compression 20 recherche dans cette même entête une chane " User-Agent ?) permettant de conna^tre la version minimale de navigateur utilisé par le client. Si la valeur extraite n'est pas au moins égale à 4 (numéro de version majeure des navigateurs), aucune compression
n'est effectuce (passage au point 1).
C) Cette opération remplit une fonction de module d'aiguillage. En fonction de l'entête de réponse http (renseignée par le serveur Web d'origine) et plus précisément de la chane " Content-Type ", on redirige le flux vers un sous-module de compression 25 le plus adapté pour le type de contenu déclaré. Par exemple, une indication " Content-Type:text.html " dans les données renvoyées par le serveur, permet de savoir que le
contenu est de type HTML - Hypertext Markup Language - (texte).
D) Cette opération est rénlisée au niveau du module de service 25 (sousmodule de compression): on recherche dans l'entête de réponse http la chane " Content-Encoding ", permettant de savoir si le contenu est déjà compressé. La compression ne se fait pas si cette chane est présente et si une de ces deux valeurs (" gzip " ou " deflate ") est présente (dans ce cas
passage au point 1).
E) on compare les premiers octets du contenu avec les octets suivants: il se peut qu'une mauvaise implémentation d'un serveur Web 40 introduise des erreurs de codage et il faut alors s'assurer que le contenu est bien du texte. Si le contenu n'est pas de type HTML, il n'est pas modifié
(passage au point I ci-après).
F) On appelle une fonction de compression " compress " qui retourne le contenu compressé dans un tampon (buffer) auquel il est nécessaire d'ajouter les octets suivants: 1F 8B 08 00 00 00 00 00, qui
définissent le début d'entête d'une compression de type gzip.
Il est également nécessaire alors de modifier les deux premiers
octets 00 03 à la fin de l'entête de compression gzip.
G) On remplace le contenu dans un objet
picapSocketDataResponseContent par le contenu de ce buffer.
H) On modifie et on ajoute, en fin de l'entête de réponse, la ligne
" Content-Encoding: gzip ".
I) On envoi la réponse (modifiée ou non) au client iCAP 10.
Le diagramme de classes de la figure 6 montre les liens de généralisation et de dépendance entre les classes du serveur et les classes
spécifiques du service.
Le diagramme de classe complet d'un compresseur iCAP (iCAP Zipper) préférentiel est la fusion logique de ce diagramme avec celui d'un
adaptateur de flux iCAP tel que décrit précédemment.
La classe ClcapServiceZip est la classe fille de la classe de services iCAP ClcapService. Elle contient les fonctionnalités utilisées pour la
compression des objets.
La classe CicapGlobalsService est la classe abstraite fille de la classe de définitions de constantes et de variables communes aux classes
d u service. El le n'est pas instanciable.
La classe ClcapErrorService définit les constantes d'erreur
spécifiques pour le service. Elle n'est pas instanciable.
Les mécanismes de compression fournis par le service décrit ici
peuvent agir différemment en fonction des contenus à traiter.
Ces mécanismes peuvent agir pour rébuire le volume des données
échangées (compression des données) avec ou sans pertes.
11s peuvent également optimiser les donnces échangées par
réorganisation des données.
Pour favoriser l'essor d'iCAP et étendre la gamme de services de transformation de contenus en c_ur de réseau, on propose donc ici un service de compression à la volée en c_ur de réseau qui se traduit par une accélaration du téléchargement de pages Web et généralement de
contenus sur http.
Ce service trouve une application immédiate pour toute connectivité à Internet depuis des terminaux mobiles (un PC - ordinateur personnel - ou un PDA - assistant digital de poche - via un terminal GPRS - Generai
Packet Radio Service - ou CSD - Circuit Switched Data).
Il n'est cependant pas limité aux seuis opérateurs mobiles et peut
être applicable à tout fournisseur d'accès Internet (FAI).
Il permet alors non seulement d'augmenter la qualité de service perçue par l'utilisateur final, mais aussi d'optimiser la bande passante du FAI sur la portion la plus critique: entre le point d'accès internet et l'utilisateur. Ce service trouve également son efficacité dans les connections d'utilisateurs nomades avec leur Intranet d'entreprise. En effet, c'est au travers de connexions de type RTC (Réseau Téléphonique Commuté) qu'ils récupèrent des donnces d'lntranet, et, à ce titre, la compression à la volée offre un gain en bande passante relative et une rébuction du temps de
téléchargement des nouvelles informations non négligeables.
Enfin, du point de vue d'un fournisseur de service, le compresseur iCAP ou iCAP Zipper décrit ici présente l'intérêt primordial d'une économie
en bande passante et d'une amélioration de la qualité de service offerte.
Claims (16)
1. Procédé de compression à la volée de donnces fournies par un serveur (40) d'un réseau collectif tel qu'internet en réponse à une requête d'un terminai de consultation (30), dans lequel procédé on fournit un module de compression de données (20), et un module de redirection (10) prévu pour recevoir des données fournies par le serveur (40) et les rediriger vers le module de compression (20), ce module de redirection (10) étant également prévu pour recevoir des données depuis le module de compression (20) et les rediriger vers le terminal de consuitation (30), procédé selon lequel on examine dans la requête une indication concernant une aptitude à la décompression du terminal (30) et on effectue dans le module de compression (20), sur les données demandées par la requête et fournies par le serveur (40), une compression qui est adaptée à l'indication
d'aptitude contenue dans la requête.
2. Procédé selon la revendication 1, caractérisé en ce qu'on ne met en _uvre aucune compression dans le cas o itindication de la requête révèle
une inaptitude du terminal (30) à la décompression.
3. Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce que l'on recherche dans la requête une indication d'aptitude concernant l'un quelconque de plusieurs types de décompression, et on met en _uvre celui des types de compression qui correspond spécifiquement à l'indication
d'aptitude contenue dans la requête.
4. Procédé selon la revendication 3, caractérisé en ce que le module de compression (20) comporte des moyens pour mettre en _uvre lesdits plusieurs types de compressions, et en ce que la recherche d'indications concernant les différents types de compressions est effectuée par le module
de compression (20).
5. Procédé selon l'une quelconque des revendications précédentes,
caractérisé en ce que le module de compression (20) et le module de redirection (10) sont prévus pour échanger des donnces selon le protocole
ICAP - Internet Content Adaptation Protocol.
6. Procédé selon l'une quelconque des revendications précédentes,
caractérisé en ce que le module de redirection (10) est un module de mémorisation de masse prévu pour fournir plusieurs fois des donnces mémorisoes dans ce module (20) en réponse à plusieurs requêtes demandant ces mêmes données, sans avoir à interroger, entre ces
requêtes, un serveur (40) ayant initialement fourni ces données.
7. Procédé selon l'une quelconque des revendications précédentes,
caractérisé en ce que le module de compression (20) inclut plusieurs sous-
modules dédiés chacun à la compression d'un type d'objet différent, et en ce qu'on identifie dans les donnces à compresser la présence d'objets ayant l'un quelconque de ces différents types, puis on dirige chaque objet ainsi identifié vers un module spécifiquement dédié à la compression du
type de l'objet considéré.
8. Procédé selon i'une quelconque des revendications précédentes,
caractérisé en ce que la requête de consultation est une requête du type
HTTP - HyperText Transport Protocol.
9. Dispositif de compression de données à la volée dans un réseau collectif tel que le réseau Internet, comprenant un module de compression (20) et un module de redirection (10), ce module de redirection (10) étant prévu pour recevoir des donnces fournies par un serveur (40) en réponse à une requête de consultation émise par un terminal de consultation (30), et rediriger ces données vers le module de compression (20), ce module de redirection (10) étant également prévu pour recevoir des données fournies en retour par le module de compression (20) et les rediriger vers le terminal de consultation (30), ce dispositif incluant en outre des moyens (20) pour examiner, dans une requête de consultation de données émise par un terminal (30), une indication concernant une aptitude à la décompression du terminal considéré (30), et des moyens (20) pour commander une compression par le module de compression (20) qui est adaptée à
I'indication d'aptitude à la décompression contenue dans la requête.
10. Dispositif selon la revendication 9, caractérisé en ce que les moyens (20) prévus pour examiner une indication d'aptitude à la décompression dans la requête sont prévus pour ne commander aucune compression dans le cas o cette indication révèle une inaptitude du terminal (30) à la décompression.
11. Dispositif selon la revendication 9 ou la revendication 10, caractérisé en ce que les moyens (20) prévus -pour examiner une indication d'aptitude à la décompression dans la requête sont prévus pour rechercher dans la requête des indications d'aptitude concernant plusieurs types de décompression, et commander celui des types de compression qui correspond spécifique ment à i' ind ication d 'aptitude co nte n u e da ns la requête.
12. Dispositif selon la revendication 11, caractérisé en ce que le module de compression (20) comporte des moyens pour mettre en _uvre lesUits plusieurs types de compressions, et en ce que la recherche d'indications concernant plusieurs types de compression est effectuée par le module de
compression (20).
13. Dispositif selon l'une quelconque des revendications 9 à 12,
caractérisé en ce que le module de compression (20) et le module de redirection (10) sont prévus pour échanger des donnces selon le protocole
ICAP - Internet Content Adaptation Protocol.
14. Dispositif selon l'une quelconque des revendications 9 à 13,
caractérisé en ce que le module de redirection (10) est un module de mémorisation de masse prévu pour fournir plusieurs fois des données mémorisoes dans ce module (20) en réponse à plusieurs requêtes demandant ces mêmes données, sans avoir à interroger, entre ces
requêtes, un serveur ayant initialement fourni ces données.
15. Dispositif selon l'une quelconque des revendications 9 à 14,
caractérisé en ce que le module de compression (20) inclut plusieurs sous modules dédiés chacun à la compression d'un type d'objet différent, et en ce qu'il comprend des moyens pour identifier dans les donnces à compresser la présence d'objets ayant l'un quelconque de ces différents types, puis pour diriger chaque objet ainsi identifié vers un module
spécifiqueme nt déd ié à la compress ion d u type d 'objet considéré.
16. Disposes seen rune quelconque des nevenddons g 1 5, carac16dsh en ce quill es1 pave pour 1raiter des requA1es du type HOP Hypee Trnspod PFotocoL
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0204248A FR2838268A1 (fr) | 2002-04-05 | 2002-04-05 | Dispositif de compression de donnes a la volee de mise en oeuvre facilitee |
| AU2003260725A AU2003260725A1 (en) | 2002-04-05 | 2003-04-04 | Device and method for in-flight data compression |
| PCT/FR2003/001074 WO2003085927A1 (fr) | 2002-04-05 | 2003-04-04 | Dispositif et procede de compression de donnees a la volee |
| EP03740571A EP1495619A1 (fr) | 2002-04-05 | 2003-04-04 | Dispositif et procede de compression de donnees a la volee |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0204248A FR2838268A1 (fr) | 2002-04-05 | 2002-04-05 | Dispositif de compression de donnes a la volee de mise en oeuvre facilitee |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2838268A1 true FR2838268A1 (fr) | 2003-10-10 |
Family
ID=28052133
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0204248A Pending FR2838268A1 (fr) | 2002-04-05 | 2002-04-05 | Dispositif de compression de donnes a la volee de mise en oeuvre facilitee |
Country Status (4)
| Country | Link |
|---|---|
| EP (1) | EP1495619A1 (fr) |
| AU (1) | AU2003260725A1 (fr) |
| FR (1) | FR2838268A1 (fr) |
| WO (1) | WO2003085927A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112804271B (zh) * | 2021-04-15 | 2021-07-20 | 中国气象科学研究院 | 数据压缩方法、装置、终端及计算机可读存储介质 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6185625B1 (en) * | 1996-12-20 | 2001-02-06 | Intel Corporation | Scaling proxy server sending to the client a graphical user interface for establishing object encoding preferences after receiving the client's request for the object |
| WO2002010929A1 (fr) * | 2000-07-28 | 2002-02-07 | Remote Communications Inc. | Systeme et procede permettant de prendre en charge un contenu compresse sur un reseau informatique |
-
2002
- 2002-04-05 FR FR0204248A patent/FR2838268A1/fr active Pending
-
2003
- 2003-04-04 WO PCT/FR2003/001074 patent/WO2003085927A1/fr not_active Application Discontinuation
- 2003-04-04 EP EP03740571A patent/EP1495619A1/fr not_active Withdrawn
- 2003-04-04 AU AU2003260725A patent/AU2003260725A1/en not_active Abandoned
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6185625B1 (en) * | 1996-12-20 | 2001-02-06 | Intel Corporation | Scaling proxy server sending to the client a graphical user interface for establishing object encoding preferences after receiving the client's request for the object |
| WO2002010929A1 (fr) * | 2000-07-28 | 2002-02-07 | Remote Communications Inc. | Systeme et procede permettant de prendre en charge un contenu compresse sur un reseau informatique |
Non-Patent Citations (1)
| Title |
|---|
| NETWORK APPLIANCE, INC: "INTERNET CONTENT ADAPTATION PROTOCOL (ICAP)", ICAP FORUM, 30 July 2001 (2001-07-30), XP002226584, Retrieved from the Internet <URL:http://www.i-cap.org/docs/icap_whitepaper_v1-01.pdf> [retrieved on 20030109] * |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1495619A1 (fr) | 2005-01-12 |
| AU2003260725A1 (en) | 2003-10-20 |
| WO2003085927A1 (fr) | 2003-10-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1376410B1 (fr) | Procédé de gestion d'informations de contexte par serveur intermédiaire | |
| FR2828970A1 (fr) | Systeme d'interoperabilite entre messages mms et messages sms/ems et procede d'echange associe | |
| Ardon et al. | MARCH: A distributed content adaptation architecture | |
| FR2814829A1 (fr) | Procede et systeme d'optimisation de consultations d'ensembles de donnees par une pluralite de clients | |
| FR2979509A1 (fr) | Procede et serveur pour le suivi des utilisateurs au cours de leur navigation dans un reseau de communication | |
| FR2924241A1 (fr) | Serveur de telechargement a deux ports et procede associe | |
| EP1381978B1 (fr) | Dispositif et procede d'echange de flux entre un dispositif client et un serveur | |
| FR2880966A1 (fr) | Procede de navigation automatique en mode interposition | |
| FR2973188A1 (fr) | Procede et dispositif d'extraction de donnees d'un flux de donnees circulant sur un reseau ip | |
| FR2838268A1 (fr) | Dispositif de compression de donnes a la volee de mise en oeuvre facilitee | |
| FR2784837A1 (fr) | Procede economique de mise en communication de deux terminaux a travers l'internet et terminal de communication | |
| FR2858152A1 (fr) | Gestion automatique de champ d'en-tete dans une reponse | |
| WO2003036888A1 (fr) | Procede d'envoi d'un contenu vers au moins un terminal et serveurs pour la mise en oeuvre du procede | |
| FR2915650A1 (fr) | Procede et dispositif d'interface entre les protocoles udp ou tcp et sctp | |
| FR2918527A1 (fr) | Procede et dispositif d'insertion d'une adresse dans une requete | |
| FR2855695A1 (fr) | Procede et dispositif de diffusion cyclique radio vers des clients differents | |
| FR2857191A1 (fr) | Systeme de transmission de parametres caracteristiques d'une session de communication d'un terminal vers un serveur distant | |
| EP1671451B1 (fr) | Procede et systeme de mise a disposition d'informations de taxation d'un service payant delivre par un fournisseur de services | |
| EP1471714A2 (fr) | Procédé et système de redirection sur détection d'erreur de résolution DNS | |
| EP2171966B1 (fr) | Gestion de sessions multi-flux entre un terminal et un serveur | |
| EP1212703B1 (fr) | Procede et dispositif de telechargement de fichiers | |
| FR2808640A1 (fr) | Dispositif de supervision de terminaux | |
| EP1843518B1 (fr) | Procédé de protection d'adrresse de messagerie, système et dispostifs associes | |
| FR2851390A1 (fr) | Dispositif et procede de mise en communication de modules de mise en oeuvre d'un bouquet de services et plate-forme de mise en oeuvre d'un bouquet de services correspondante | |
| EP1642442A1 (fr) | Dispositif de personnalisation du traitement de communications |