CA2889329A1 - Procede de recuperation d'un contenu correspondant a une adresse url par un dispositif client - Google Patents
Procede de recuperation d'un contenu correspondant a une adresse url par un dispositif client Download PDFInfo
- Publication number
- CA2889329A1 CA2889329A1 CA2889329A CA2889329A CA2889329A1 CA 2889329 A1 CA2889329 A1 CA 2889329A1 CA 2889329 A CA2889329 A CA 2889329A CA 2889329 A CA2889329 A CA 2889329A CA 2889329 A1 CA2889329 A1 CA 2889329A1
- Authority
- CA
- Canada
- Prior art keywords
- client device
- content
- server
- url
- address
- 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.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/21—Server components or server architectures
- H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
-
- 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]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
- G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
- G06F16/986—Document structures and storage, e.g. HTML extensions
-
- 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
-
- 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/14—Session management
- H04L67/141—Setup of application sessions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
- H04N21/4782—Web browsing, e.g. WebTV
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6143—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a satellite
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Computer Networks & Wireless Communication (AREA)
- Astronomy & Astrophysics (AREA)
- Information Transfer Between Computers (AREA)
- Radio Relay Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
La présente invention concerne un procédé de récupération d'un contenu tel qu'une page HTML correspondant à une adresse URL par un dispositif client comportant les étapes suivantes : - à partir d'une adresse URL correspondant au contenu, vérification par le dispositif client de la présence du contenu de l'adresse URL dans une mémoire cache du dispositif client; - en l'absence du contenu de l'adresse URL dans la mémoire cache, création par le dispositif client d'un message court incluant l'adresse URL; - transmission du message par le dispositif client vers un dispositif serveur selon un protocole de transmission unidirectionnel sans connexion donné; - téléchargement sur le réseau internet par le dispositif serveur du contenu correspondant à l'adresse URL; - transmission du contenu par le dispositif serveur vers le dispositif client via un protocole unidirectionnel avec codage sans acquittement; - réception du contenu par le dispositif client, récupération et stockage par le dispositif client du contenu dans la mémoire cache.
Description
Procédé de récupération d'un contenu correspondant à une adresse URL par un dispositif client La présente invention concerne un procédé de récupération d'un con-tenu tel qu'une page HTML correspondant à une adresse URL par un dispo-sitif client. Le procédé selon l'invention trouve une application particulière-ment intéressante dans le cas d'une installation de réception de signaux sa-tellitaires disposant d'une voie aller très efficace (débit binaire élevé) et d'une voie retour très limitée (débit binaire faible).
Actuellement, la diffusion de programmes de télévision numérique par voie satellite (par exemple selon l'une des normes DVB-S, DVB-S2 ou DVB-SH) est largement utilisée à travers le monde. De nombreux dispositifs sont installés chez des millions d'utilisateurs. Les dispositifs installés sont majori-tairement des dispositifs de réception qui comportent une unité extérieure incluant un réflecteur parabolique qui focalise les signaux hyperfréquences modulés, sur la source, appelé cornet, d'un LNB (de l'anglais Low Noise Block et qui se traduit par bloc de réception), le LNB transformant les si-gnaux hyperfréquences reçus en signaux électriques en bande satellite in-termédiaire afin de les transmettre, par l'intermédiaire d'un câble coaxial au décodeur satellite STB. Le décodeur comprend un bloc de démodulation (DVB-S, DVB-S2 ou DVB-SH) qui extrait un signal modulé utile dans le signal modulé transmis sur le câble coaxial et démodule le signal utile extrait. Le signal utile démodulé peut, par exemple, être utilisé pour l'affichage d'images vidéo sur un écran de télévision.
Les offres de diffusion de programmes de télévision numérique par voie satellitaire sont aujourd'hui essentiellement purement passives, c'est-à-dire unidirectionnelles ( one-way service en anglais).
Il peut toutefois s'avérer utile de pouvoir offrir des services nécessi-tant une voie retour à débit limité ; c'est le cas par exemple des services in-teractifs (votes, consommation de contenus à accès conditionnel par échange de clefs, commandes de nouveaux services tels que de la vidéo à
la demande). En outre, cette voie retour peut trouver des applications parti-culièrement intéressantes dans le domaine des communications de machine
Actuellement, la diffusion de programmes de télévision numérique par voie satellite (par exemple selon l'une des normes DVB-S, DVB-S2 ou DVB-SH) est largement utilisée à travers le monde. De nombreux dispositifs sont installés chez des millions d'utilisateurs. Les dispositifs installés sont majori-tairement des dispositifs de réception qui comportent une unité extérieure incluant un réflecteur parabolique qui focalise les signaux hyperfréquences modulés, sur la source, appelé cornet, d'un LNB (de l'anglais Low Noise Block et qui se traduit par bloc de réception), le LNB transformant les si-gnaux hyperfréquences reçus en signaux électriques en bande satellite in-termédiaire afin de les transmettre, par l'intermédiaire d'un câble coaxial au décodeur satellite STB. Le décodeur comprend un bloc de démodulation (DVB-S, DVB-S2 ou DVB-SH) qui extrait un signal modulé utile dans le signal modulé transmis sur le câble coaxial et démodule le signal utile extrait. Le signal utile démodulé peut, par exemple, être utilisé pour l'affichage d'images vidéo sur un écran de télévision.
Les offres de diffusion de programmes de télévision numérique par voie satellitaire sont aujourd'hui essentiellement purement passives, c'est-à-dire unidirectionnelles ( one-way service en anglais).
Il peut toutefois s'avérer utile de pouvoir offrir des services nécessi-tant une voie retour à débit limité ; c'est le cas par exemple des services in-teractifs (votes, consommation de contenus à accès conditionnel par échange de clefs, commandes de nouveaux services tels que de la vidéo à
la demande). En outre, cette voie retour peut trouver des applications parti-culièrement intéressantes dans le domaine des communications de machine
2 à machine ( Machine ta machine en anglais) ou M2M pour contrôler cer-tains appareils (alarme, chauffage,...) et/ou récupérer des données mesu-rées par des capteurs ou compteurs (gaz, électricité...) présents au sein des foyers.
Une solution connue à ce problème consiste à utiliser une voie retour utilisant une connexion de type ADSL fournie par des opérateurs de télé-phonie fixe (RTC ou Réseau Téléphonique Commuté ) ou une connexion de type GPRS/UMTS fournie par des opérateurs de téléphonie mobile. Cette solution nécessite donc du matériel supplémentaire ainsi qu'un abonnement additionnel ; par ailleurs, la commutation téléphonique n'est pas particuliè-rement adaptée à la transmission de messages peu volumineux tels que des messages de vote ou de commande (coût relativement élevé, problèmes de saturation du réseau...). En outre la couverture territoriale de ces réseaux terrestres est limitée.
Une autre solution consiste à utiliser des terminaux satellitaires bidi-rectionnels à haut débit, mais le coût de l'équipement et de l'abonnement peut être trop élevé pour une application qui utilise seulement un débit d'émission très faible.
La plupart des offres de télévision par satellite n'intègre pas de voie retour. On peut toutefois citer un exemple de système de diffusion bidirec-tionnel de télévision par satellite décrit dans le document de brevet EP0888690 ; ce système utilise une voie aller en bande large Ku et une voie retour en bande étroite L. Ce système est encombrant, complexe et coûteux dans la mesure où il nécessite la présence de deux réflecteurs (pour chaque bande Ku et L) ou d'un réflecteur dédié comprenant un réflecteur apte à re-cevoir des signaux en bande Ku et intégrant une antenne de transmission en bande L. Ce système entraîne également la présence de deux voies physiques d'acheminement de données, l'une de l'antenne en bande Ku vers le décodeur à l'intérieur de la maison et l'autre du décodeur vers l'antenne en bande L. On comprend aisément que ce type d'installation en-traîne un changement complet des systèmes standards équipant actuelle-ment les foyers et un surcoût non négligeable.
Une solution connue à ce problème consiste à utiliser une voie retour utilisant une connexion de type ADSL fournie par des opérateurs de télé-phonie fixe (RTC ou Réseau Téléphonique Commuté ) ou une connexion de type GPRS/UMTS fournie par des opérateurs de téléphonie mobile. Cette solution nécessite donc du matériel supplémentaire ainsi qu'un abonnement additionnel ; par ailleurs, la commutation téléphonique n'est pas particuliè-rement adaptée à la transmission de messages peu volumineux tels que des messages de vote ou de commande (coût relativement élevé, problèmes de saturation du réseau...). En outre la couverture territoriale de ces réseaux terrestres est limitée.
Une autre solution consiste à utiliser des terminaux satellitaires bidi-rectionnels à haut débit, mais le coût de l'équipement et de l'abonnement peut être trop élevé pour une application qui utilise seulement un débit d'émission très faible.
La plupart des offres de télévision par satellite n'intègre pas de voie retour. On peut toutefois citer un exemple de système de diffusion bidirec-tionnel de télévision par satellite décrit dans le document de brevet EP0888690 ; ce système utilise une voie aller en bande large Ku et une voie retour en bande étroite L. Ce système est encombrant, complexe et coûteux dans la mesure où il nécessite la présence de deux réflecteurs (pour chaque bande Ku et L) ou d'un réflecteur dédié comprenant un réflecteur apte à re-cevoir des signaux en bande Ku et intégrant une antenne de transmission en bande L. Ce système entraîne également la présence de deux voies physiques d'acheminement de données, l'une de l'antenne en bande Ku vers le décodeur à l'intérieur de la maison et l'autre du décodeur vers l'antenne en bande L. On comprend aisément que ce type d'installation en-traîne un changement complet des systèmes standards équipant actuelle-ment les foyers et un surcoût non négligeable.
3 Un autre exemple de système de diffusion bidirectionnel de télévision par satellite est décrit dans la demande de brevet W02011076791 déposée par la demanderesse. Ce système utilise une voie aller en bande large Ku ou Ka et une voie retour en bande étroite S ou en bande C, les signaux étant multiplexés sur un même câble coaxial. Le gain du réflecteur pour re-cevoir les signaux hyperfréquences en bande Ku ou Ka est utilisé pour transmettre les signaux en voie retour dans la bande S ou la bande C.
Dans les situations évoquées ci-dessus, la voie retour est une voie re-tour en bande très étroite avec un débit binaire réduit. On comprend donc que l'utilisation d'une telle voie retour est aujourd'hui limitée aux applications telles que des services interactifs et ne permet d'accéder à Internet, no-tamment en naviguant sur le Web. L'accès normal à internet est en effet ba-sé sur le protocole TCP/IP ; ce dernier requiert un certain niveau de débit binaire et une latence limitée pour la voie retour de façon à assurer l'envoi des acquittements propres à ce protocole. Dès lors, un tel protocole fonc-tionne très difficilement avec une voie retour limitée en débit et avec une latence importante (par exemple supérieure à 1s).
Une solution connue à ce problème dans le cas des réseaux satelli-taires consiste à utiliser des accélérateurs TCP ( TCP accelerator en an-glais) de manière à améliorer les performances du protocole TCP/IP sur un lien avec une latence importante. L'accélérateur tente de réduire le nombre d'acquittements sans pour autant supprimer l'ensemble des acquittements.
L'accélérateur ne supprime pas d'avantage les demandes d'établissement de connexion avec l'utilisation d'un drapeau de synchronisation SYN. En conséquence, même en présence d'un accélérateur TCP, le fort déséqui-libre entre une voie aller et une voie retour rend très difficile l'utilisation du protocole TCP/IP qui nécessite de nombreux aller/retour par le biais d'envoi de requêtes et d'acquittements et donc une utilisation intensive de la voie retour non adaptée.
Dans ce contexte, la présente invention vise à fournir un procédé de récupération d'un contenu tel qu'une page HTML correspondant à une adresse URL par un dispositif client dans un système disposant d'une voie aller très performante et d'une voie retour réduite en termes de débit binaire.
Dans les situations évoquées ci-dessus, la voie retour est une voie re-tour en bande très étroite avec un débit binaire réduit. On comprend donc que l'utilisation d'une telle voie retour est aujourd'hui limitée aux applications telles que des services interactifs et ne permet d'accéder à Internet, no-tamment en naviguant sur le Web. L'accès normal à internet est en effet ba-sé sur le protocole TCP/IP ; ce dernier requiert un certain niveau de débit binaire et une latence limitée pour la voie retour de façon à assurer l'envoi des acquittements propres à ce protocole. Dès lors, un tel protocole fonc-tionne très difficilement avec une voie retour limitée en débit et avec une latence importante (par exemple supérieure à 1s).
Une solution connue à ce problème dans le cas des réseaux satelli-taires consiste à utiliser des accélérateurs TCP ( TCP accelerator en an-glais) de manière à améliorer les performances du protocole TCP/IP sur un lien avec une latence importante. L'accélérateur tente de réduire le nombre d'acquittements sans pour autant supprimer l'ensemble des acquittements.
L'accélérateur ne supprime pas d'avantage les demandes d'établissement de connexion avec l'utilisation d'un drapeau de synchronisation SYN. En conséquence, même en présence d'un accélérateur TCP, le fort déséqui-libre entre une voie aller et une voie retour rend très difficile l'utilisation du protocole TCP/IP qui nécessite de nombreux aller/retour par le biais d'envoi de requêtes et d'acquittements et donc une utilisation intensive de la voie retour non adaptée.
Dans ce contexte, la présente invention vise à fournir un procédé de récupération d'un contenu tel qu'une page HTML correspondant à une adresse URL par un dispositif client dans un système disposant d'une voie aller très performante et d'une voie retour réduite en termes de débit binaire.
4 A cette fin, l'invention propose un procédé de récupération d'un con-tenu sous la forme d'une page HTML correspondant à une adresse URL par un dispositif client comportant les étapes suivantes :
- à partir d'une adresse URL correspondant au dit contenu, vérification par le dispositif client de la présence du contenu de l'adresse URL
dans une mémoire du dispositif client ;
- en l'absence du contenu de l'adresse URL dans la mémoire, création par le dispositif client d'un message court incluant l'adresse URL ;
- transmission dudit message par le dispositif client vers un dispositif serveur selon un protocole de transmission unidirectionnel sans con-nexion donné ;
- téléchargement sur le réseau internet par le dispositif serveur du con-tenu correspondant à ladite adresse URL ;
- analyse dudit contenu par le dispositif serveur et téléchargement sur le réseau internet par le dispositif serveur des éléments tels que les images et les scripts dont le lien est contenu dans ledit contenu ;
- création par le dispositif serveur d'un unique fichier incorporant ledit contenu ainsi que les éléments précédemment téléchargés ;
- transmission dudit contenu ainsi que des éléments précédemment té-léchargés par le dispositif serveur vers le dispositif client sous la forme dudit unique fichier via un protocole unidirectionnel avec co-dage sans acquittement ;
- réception dudit unique fichier par le dispositif client ;
- récupération et stockage par le dispositif client dudit unique fichier dans ladite mémoire.
Grâce à l'invention, on utilise avantageusement un dispositif client et un dispositif serveur localisés respectivement auprès d'un terminal utilisateur et d'une station terrestre. Le dispositif client envoie une requête correspon-dant à une demande d'accès à un contenu tel qu'une page web associée à
une adresse URL. Cette requête est réalisée sous la forme d'un message court unique en utilisant par exemple une technique de modulation basée sur un protocole à étalement de spectre tel qu'un protocole asynchrone à
accès aléatoire multiple à étalement de bande par modulation du type SPREAD ALOHA (un tel protocole est par exemple décrit dans le document ETSI TS 102 721-3). Ce message court peut également être envoyé par SMS ( Short Message Service ) en utilisant un réseau cellulaire terrestre.
- à partir d'une adresse URL correspondant au dit contenu, vérification par le dispositif client de la présence du contenu de l'adresse URL
dans une mémoire du dispositif client ;
- en l'absence du contenu de l'adresse URL dans la mémoire, création par le dispositif client d'un message court incluant l'adresse URL ;
- transmission dudit message par le dispositif client vers un dispositif serveur selon un protocole de transmission unidirectionnel sans con-nexion donné ;
- téléchargement sur le réseau internet par le dispositif serveur du con-tenu correspondant à ladite adresse URL ;
- analyse dudit contenu par le dispositif serveur et téléchargement sur le réseau internet par le dispositif serveur des éléments tels que les images et les scripts dont le lien est contenu dans ledit contenu ;
- création par le dispositif serveur d'un unique fichier incorporant ledit contenu ainsi que les éléments précédemment téléchargés ;
- transmission dudit contenu ainsi que des éléments précédemment té-léchargés par le dispositif serveur vers le dispositif client sous la forme dudit unique fichier via un protocole unidirectionnel avec co-dage sans acquittement ;
- réception dudit unique fichier par le dispositif client ;
- récupération et stockage par le dispositif client dudit unique fichier dans ladite mémoire.
Grâce à l'invention, on utilise avantageusement un dispositif client et un dispositif serveur localisés respectivement auprès d'un terminal utilisateur et d'une station terrestre. Le dispositif client envoie une requête correspon-dant à une demande d'accès à un contenu tel qu'une page web associée à
une adresse URL. Cette requête est réalisée sous la forme d'un message court unique en utilisant par exemple une technique de modulation basée sur un protocole à étalement de spectre tel qu'un protocole asynchrone à
accès aléatoire multiple à étalement de bande par modulation du type SPREAD ALOHA (un tel protocole est par exemple décrit dans le document ETSI TS 102 721-3). Ce message court peut également être envoyé par SMS ( Short Message Service ) en utilisant un réseau cellulaire terrestre.
5 De façon générale, on entend par envoi d'un message court le fait d'utiliser une technologie permettant d'envoyer un nombre limité de mes-sages par jour, chacun avec moins de 2000 octets par message, avec une latence importante, et sans établissement préalable d'une connexion (par exemple via l'échange d'un handshake ), la durée d'émission d'un message étant inférieure ou égale à ls.
Selon un mode préférentiel de réalisation de l'invention, le message court incluant l'adresse URL comporte uniquement un ou plusieurs paquets de la couche 2 liaison de données du modèle OSI. Ainsi, lorsque le dis-positif client envoie ledit message, il ne spécifie pas une adresse de destina-taire. Ce mode préférentiel de réalisation de l'invention est particulièrement intéressant dans le cas d'une communication par satellite entre le dispositif client et le dispositif serveur. Le message court pourra avantageusement comporter uniquement un seul paquet de la couche 2 liaison de don-nées .
Selon un autre mode de réalisation de l'invention, l'envoi du message court incluant l'adresse URL par le dispositif client vers le dispositif serveur pourra être conforme au protocole UDP (User Datagram Protocol).
Le dispositif serveur reçoit l'adresse URL et va agir comme un ser-veur proxy en retrouvant le contenu (i.e. la page web) associé à l'adresse URL sur Internet. Une fois le contenu récupéré (ainsi que, le cas échéant, les images et scripts dont le lien est contenu dans la page, qui sont néces-saires pour l'affichage), le dispositif serveur transmet au dispositif client un fichier incorporant le contenu sous la forme d'un envoi unique en utilisant un protocole unidirectionnel avec codage sans acquittement tel qu'un des pro-tocoles utilisés pour la technologie push (dite également datacast ).
Le dispositif client va stocker le contenu et agir comme un proxy-cache vers l'utilisateur. L'utilisateur communique directement via son terminal utilisateur
Selon un mode préférentiel de réalisation de l'invention, le message court incluant l'adresse URL comporte uniquement un ou plusieurs paquets de la couche 2 liaison de données du modèle OSI. Ainsi, lorsque le dis-positif client envoie ledit message, il ne spécifie pas une adresse de destina-taire. Ce mode préférentiel de réalisation de l'invention est particulièrement intéressant dans le cas d'une communication par satellite entre le dispositif client et le dispositif serveur. Le message court pourra avantageusement comporter uniquement un seul paquet de la couche 2 liaison de don-nées .
Selon un autre mode de réalisation de l'invention, l'envoi du message court incluant l'adresse URL par le dispositif client vers le dispositif serveur pourra être conforme au protocole UDP (User Datagram Protocol).
Le dispositif serveur reçoit l'adresse URL et va agir comme un ser-veur proxy en retrouvant le contenu (i.e. la page web) associé à l'adresse URL sur Internet. Une fois le contenu récupéré (ainsi que, le cas échéant, les images et scripts dont le lien est contenu dans la page, qui sont néces-saires pour l'affichage), le dispositif serveur transmet au dispositif client un fichier incorporant le contenu sous la forme d'un envoi unique en utilisant un protocole unidirectionnel avec codage sans acquittement tel qu'un des pro-tocoles utilisés pour la technologie push (dite également datacast ).
Le dispositif client va stocker le contenu et agir comme un proxy-cache vers l'utilisateur. L'utilisateur communique directement via son terminal utilisateur
6 avec le dispositif client en utilisant son navigateur internet : l'utilisateur a l'impression de naviguer sur internet en utilisant le protocole TCP/IP.
On notera que le dispositif client est de préférence intégré à un dispo-sitif fonctionnant en émission et en réception à la fois capable de transmettre des messages courts (objet de l'invention) mais également de recevoir des signaux (par exemple satellitaires) modulés tels que des signaux TV. Le dis-positif client intègre dans ce cas un démodulateur permettant la démodula-tion des signaux reçus en voie aller par voie satellitaire fonctionnant par exemple selon la norme DVB-S2 (ETSI EN 302 307 v1.2.1 Digital Video Broadcasting (DVB) ; Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathe-ring and other broadband satellite applications) et un modulateur pour la création des messages courts (par exemple un modulateur fonctionnant sui-vant un protocole asynchrone à accès aléatoire multiple selon la norme dé-crite dans le document ETSI TS 102 721-3 : Satellite Earth Stations and Systems. Air Interface for 5-band Mobile Interactive Multimedia (S-MIM);
Part 3 : Physical Layer Specification, Return Link Asynchronous Access. ) Le procédé selon l'invention peut également présenter une ou plu-sieurs des caractéristiques ci-dessous, considérées individuellement ou se-Ion toutes les combinaisons techniquement possibles :
- le procédé selon l'invention comporte une étape d'extraction par le dispositif client à partir dudit unique fichier du contenu ainsi que des éléments précédemment téléchargés dont le lien est contenu dans ledit contenu, de stockage dudit contenu et desdits éléments précé-demment téléchargés dans la mémoire du dispositif client, et de mise à la disposition d'un terminal utilisateur dudit contenu et desdits élé-ments précédemment téléchargés ;
- le procédé selon l'invention comporte une étape de création par le dispositif serveur d'un unique fichier incorporant ledit contenu, ledit contenu étant transmis sous la forme dudit fichier par le dispositif ser-veur vers le dispositif client via ledit protocole unidirectionnel avec co-dage sans acquittement ;
On notera que le dispositif client est de préférence intégré à un dispo-sitif fonctionnant en émission et en réception à la fois capable de transmettre des messages courts (objet de l'invention) mais également de recevoir des signaux (par exemple satellitaires) modulés tels que des signaux TV. Le dis-positif client intègre dans ce cas un démodulateur permettant la démodula-tion des signaux reçus en voie aller par voie satellitaire fonctionnant par exemple selon la norme DVB-S2 (ETSI EN 302 307 v1.2.1 Digital Video Broadcasting (DVB) ; Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathe-ring and other broadband satellite applications) et un modulateur pour la création des messages courts (par exemple un modulateur fonctionnant sui-vant un protocole asynchrone à accès aléatoire multiple selon la norme dé-crite dans le document ETSI TS 102 721-3 : Satellite Earth Stations and Systems. Air Interface for 5-band Mobile Interactive Multimedia (S-MIM);
Part 3 : Physical Layer Specification, Return Link Asynchronous Access. ) Le procédé selon l'invention peut également présenter une ou plu-sieurs des caractéristiques ci-dessous, considérées individuellement ou se-Ion toutes les combinaisons techniquement possibles :
- le procédé selon l'invention comporte une étape d'extraction par le dispositif client à partir dudit unique fichier du contenu ainsi que des éléments précédemment téléchargés dont le lien est contenu dans ledit contenu, de stockage dudit contenu et desdits éléments précé-demment téléchargés dans la mémoire du dispositif client, et de mise à la disposition d'un terminal utilisateur dudit contenu et desdits élé-ments précédemment téléchargés ;
- le procédé selon l'invention comporte une étape de création par le dispositif serveur d'un unique fichier incorporant ledit contenu, ledit contenu étant transmis sous la forme dudit fichier par le dispositif ser-veur vers le dispositif client via ledit protocole unidirectionnel avec co-dage sans acquittement ;
7 - le procédé selon l'invention comporte une étape de vérification par le dispositif serveur de la présence du contenu de l'adresse URL dans une mémoire du dispositif serveur de sorte que ledit téléchargement sur le réseau internet par le dispositif serveur du contenu correspon-dant à ladite adresse URL se fait en l'absence du contenu de l'adresse URL dans la mémoire ;
- le contenu est une page HTML, ledit procédé comportant l'étape d'analyse dudit contenu par le dispositif serveur et le cas échéant, té-léchargement sur le réseau internet par le dispositif serveur des élé-ments tels que les images et les scripts dont le lien est contenu dans ledit contenu ; en d'autres termes, si l'adresse URL correspond à une page web, le dispositif serveur va télécharger sur le réseau internet le contenu référencié par le code HTML (images, script Javascript, ...) ;
- ledit dispositif serveur envoie lesdits éléments de façon asynchrone, ledit dispositif client étant prêt à recevoir lesdits éléments et à les stocker dans sa mémoire ;
- le procédé selon l'invention comporte les étapes suivantes :
o tentative d'ouverture du lien associé à l'adresse URL sur le na-vigateur d'un terminal utilisateur ;
o transmission d'une requête DNS dudit terminal utilisateur vers le dispositif client ;
o vérification par le dispositif client de la présence du nom de serveur associé à la requête DNS dans une base de données locale du dispositif client ;
o si le nom de serveur est présent dans ladite base de données, transmission par le dispositif client vers le terminal utilisateur de l'adresse IF déjà associée au dit nom de serveur ;
o si le nom de serveur n'est pas présent dans ladite base de données, création par le dispositif client d'une adresse IF tem-poraire associée au dit nom de serveur puis transmission par le dispositif client vers ledit terminal utilisateur de ladite
- le contenu est une page HTML, ledit procédé comportant l'étape d'analyse dudit contenu par le dispositif serveur et le cas échéant, té-léchargement sur le réseau internet par le dispositif serveur des élé-ments tels que les images et les scripts dont le lien est contenu dans ledit contenu ; en d'autres termes, si l'adresse URL correspond à une page web, le dispositif serveur va télécharger sur le réseau internet le contenu référencié par le code HTML (images, script Javascript, ...) ;
- ledit dispositif serveur envoie lesdits éléments de façon asynchrone, ledit dispositif client étant prêt à recevoir lesdits éléments et à les stocker dans sa mémoire ;
- le procédé selon l'invention comporte les étapes suivantes :
o tentative d'ouverture du lien associé à l'adresse URL sur le na-vigateur d'un terminal utilisateur ;
o transmission d'une requête DNS dudit terminal utilisateur vers le dispositif client ;
o vérification par le dispositif client de la présence du nom de serveur associé à la requête DNS dans une base de données locale du dispositif client ;
o si le nom de serveur est présent dans ladite base de données, transmission par le dispositif client vers le terminal utilisateur de l'adresse IF déjà associée au dit nom de serveur ;
o si le nom de serveur n'est pas présent dans ladite base de données, création par le dispositif client d'une adresse IF tem-poraire associée au dit nom de serveur puis transmission par le dispositif client vers ledit terminal utilisateur de ladite
8 adresse IF temporaire et enregistrement de ladite adresse IF
temporaire dans ladite base de données ;
o tentative d'établissement d'une connexion TCP par le terminal utilisateur avec le serveur correspondant à ladite adresse IF
temporaire, ledit dispositif client se substituant au serveur en s'attribuant ladite adresse IF temporaire de sorte que la con-nexion TCP est établie entre le terminal utilisateur et le disposi-tif client ;
o transmission d'une requête HTTP incluant l'adresse URL par le terminal utilisateur vers le dispositif client, la réception de l'adresse URL par le dispositif client entraînant ladite étape de vérification par ledit dispositif client de la présence du contenu de ladite adresse URL dans une mémoire du dispositif client ;
o récupération du contenu par le dispositif client et envoi du con-tenu au terminal utilisateur à travers la connexion TCP établie.
- ledit protocole unidirectionnel avec codage sans acquittement est un des protocoles utilisés pour la technologie push dite aussi data-cast ;
- ladite transmission du message par le dispositif client vers le disposi-tif serveur est réalisée par une transmission par satellite, ledit procédé
comportant les étapes suivantes :
o transmission en voie montante par le dispositif client dudit message incorporé dans un signal modulé vers le satellite ;
o transmission en voie descendante par le satellite d'un signal incorporant ledit signal modulé incorporant le message vers une station terrestre connectée au dispositif serveur ;
- le signal modulé incorporant le message émis par le dispositif client est modulé selon un protocole à étalement de spectre fonctionnant selon un protocole asynchrone à accès aléatoire multiple à étalement de spectre ;
- ladite transmission du contenu par le dispositif serveur vers le disposi-tif client est réalisée par une transmission par satellite ;
temporaire dans ladite base de données ;
o tentative d'établissement d'une connexion TCP par le terminal utilisateur avec le serveur correspondant à ladite adresse IF
temporaire, ledit dispositif client se substituant au serveur en s'attribuant ladite adresse IF temporaire de sorte que la con-nexion TCP est établie entre le terminal utilisateur et le disposi-tif client ;
o transmission d'une requête HTTP incluant l'adresse URL par le terminal utilisateur vers le dispositif client, la réception de l'adresse URL par le dispositif client entraînant ladite étape de vérification par ledit dispositif client de la présence du contenu de ladite adresse URL dans une mémoire du dispositif client ;
o récupération du contenu par le dispositif client et envoi du con-tenu au terminal utilisateur à travers la connexion TCP établie.
- ledit protocole unidirectionnel avec codage sans acquittement est un des protocoles utilisés pour la technologie push dite aussi data-cast ;
- ladite transmission du message par le dispositif client vers le disposi-tif serveur est réalisée par une transmission par satellite, ledit procédé
comportant les étapes suivantes :
o transmission en voie montante par le dispositif client dudit message incorporé dans un signal modulé vers le satellite ;
o transmission en voie descendante par le satellite d'un signal incorporant ledit signal modulé incorporant le message vers une station terrestre connectée au dispositif serveur ;
- le signal modulé incorporant le message émis par le dispositif client est modulé selon un protocole à étalement de spectre fonctionnant selon un protocole asynchrone à accès aléatoire multiple à étalement de spectre ;
- ladite transmission du contenu par le dispositif serveur vers le disposi-tif client est réalisée par une transmission par satellite ;
9 - ledit dispositif client crée ledit message incluant ladite adresse URL
sous un format compressé ;
- ledit dispositif serveur ignore le message quand il a déjà envoyé le contenu demandé de façon asynchrone et que le dispositif client a émis ledit message avant d'avoir reçu le contenu ;
- ledit dispositif client reçoit et sauvegarde dans sa mémoire cache tout le contenu envoyé par le serveur de façon asynchrone. Ainsi, si la voie aller est une voie de type broadcast ou diffusion (donc reçue par beaucoup de dispositifs clients en même temps), une telle étape permet de remplir les mémoires caches des dispositifs clients, en augmentant la probabilité que le contenu soit déjà là quand l'utilisateur le demandera;
- ledit dispositif serveur marque certains fichiers incorporant du contenu avec un ou plusieurs indicateurs tels que des flags pour qu'ils soient reçus et stockés par plusieurs dispositifs clients en même temps. Ce ciblage grâce à des indicateurs permet d'augmenter la probabilité de satisfaire une demande de l'utilisateur en utilisant la mémoire cache du dispositif client.
La présente invention a également pour objet un dispositif client et un dispositif serveur pour la mise en oeuvre du procédé selon l'invention.
D'autres caractéristiques et avantages de l'invention ressortiront clai-rement de la description qui en est donnée ci-dessous, à titre indicatif et nul-lement limitatif, en référence aux figures annexées :
- La figure 1 représente schématiquement une installation d'émission/réception pour la mise en oeuvre du procédé selon l'invention ;
- La figure 2 illustre les différentes étapes du procédé selon l'invention.
La figure 1 représente schématiquement une installation d'émission/réception 1 pour la mise en oeuvre du procédé selon l'invention.
Il est entendu que l'installation 1 n'est donnée qu'à titre illustrative et que de nombreuses variantes sont possibles pour la mise en oeuvre du procédé
sans sortir du cadre de la présente invention.
L'installation d'émission/réception 1 comporte :
- un réflecteur parabolique 3 apte à recevoir des signaux reçus d'un premier satellite 102 et à émettre des signaux vers un second satel-lite 103 ;
- une unité d'émission/réception 2 (par exemple extérieure à une mai-5 son) ;
- un câble coaxial 20 ;
- un boitier 21 (par exemple destiné à être logé à l'intérieur de la mai-son).
Le réflecteur parabolique 3 reçoit par exemple des signaux issus du
sous un format compressé ;
- ledit dispositif serveur ignore le message quand il a déjà envoyé le contenu demandé de façon asynchrone et que le dispositif client a émis ledit message avant d'avoir reçu le contenu ;
- ledit dispositif client reçoit et sauvegarde dans sa mémoire cache tout le contenu envoyé par le serveur de façon asynchrone. Ainsi, si la voie aller est une voie de type broadcast ou diffusion (donc reçue par beaucoup de dispositifs clients en même temps), une telle étape permet de remplir les mémoires caches des dispositifs clients, en augmentant la probabilité que le contenu soit déjà là quand l'utilisateur le demandera;
- ledit dispositif serveur marque certains fichiers incorporant du contenu avec un ou plusieurs indicateurs tels que des flags pour qu'ils soient reçus et stockés par plusieurs dispositifs clients en même temps. Ce ciblage grâce à des indicateurs permet d'augmenter la probabilité de satisfaire une demande de l'utilisateur en utilisant la mémoire cache du dispositif client.
La présente invention a également pour objet un dispositif client et un dispositif serveur pour la mise en oeuvre du procédé selon l'invention.
D'autres caractéristiques et avantages de l'invention ressortiront clai-rement de la description qui en est donnée ci-dessous, à titre indicatif et nul-lement limitatif, en référence aux figures annexées :
- La figure 1 représente schématiquement une installation d'émission/réception pour la mise en oeuvre du procédé selon l'invention ;
- La figure 2 illustre les différentes étapes du procédé selon l'invention.
La figure 1 représente schématiquement une installation d'émission/réception 1 pour la mise en oeuvre du procédé selon l'invention.
Il est entendu que l'installation 1 n'est donnée qu'à titre illustrative et que de nombreuses variantes sont possibles pour la mise en oeuvre du procédé
sans sortir du cadre de la présente invention.
L'installation d'émission/réception 1 comporte :
- un réflecteur parabolique 3 apte à recevoir des signaux reçus d'un premier satellite 102 et à émettre des signaux vers un second satel-lite 103 ;
- une unité d'émission/réception 2 (par exemple extérieure à une mai-5 son) ;
- un câble coaxial 20 ;
- un boitier 21 (par exemple destiné à être logé à l'intérieur de la mai-son).
Le réflecteur parabolique 3 reçoit par exemple des signaux issus du
10 satellite 102 en bande Ku (10,7 GHz - 12,75 GHz) et émet des signaux vers le satellite 103 en bande C (5.85-6.42 GHz) ou en bande Ka (29.5-30 GHz);
on notera que les informations concernant les fréquences utilisées sont données à titre purement illustratif et non limitatif. En outre, même si l'invention est ici décrite avec deux satellites, il est entendu que l'utilisation d'un seul et même satellite pour la voie aller et la voie retour est également possible.
L'unité d'émission/réception 2 comporte :
- un bloc LNB 4 ;
- un bloc d'émission 9 ;
- un coupleur/découpleur hyperfréquences de signaux radioélectriques 15.
Il peut alors s'avérer intéressant d'utiliser un dispositif d'adjonction 33 du bloc d'émission/réception 9 sur le LNB 4 du récepteur parabolique déjà
équipé, pointé et réglée sans qu'il soit nécessaire de modifier le montage ou le réglage de l'antenne existante. Un tel dispositif d'adjonction 33 est par exemple décrit dans la demande de brevet FR08/56940.
Le boîtier 21 comporte :
- un coupleur/découpleur 22 ;
- un modulateur 25 ;
- un démodulateur 24;
- un dispositif client 101 dont nous préciserons les caractéristiques dans la suite de la description ;
on notera que les informations concernant les fréquences utilisées sont données à titre purement illustratif et non limitatif. En outre, même si l'invention est ici décrite avec deux satellites, il est entendu que l'utilisation d'un seul et même satellite pour la voie aller et la voie retour est également possible.
L'unité d'émission/réception 2 comporte :
- un bloc LNB 4 ;
- un bloc d'émission 9 ;
- un coupleur/découpleur hyperfréquences de signaux radioélectriques 15.
Il peut alors s'avérer intéressant d'utiliser un dispositif d'adjonction 33 du bloc d'émission/réception 9 sur le LNB 4 du récepteur parabolique déjà
équipé, pointé et réglée sans qu'il soit nécessaire de modifier le montage ou le réglage de l'antenne existante. Un tel dispositif d'adjonction 33 est par exemple décrit dans la demande de brevet FR08/56940.
Le boîtier 21 comporte :
- un coupleur/découpleur 22 ;
- un modulateur 25 ;
- un démodulateur 24;
- un dispositif client 101 dont nous préciserons les caractéristiques dans la suite de la description ;
11 - des moyens 26 de connexion sans fil à un réseau local du type WiFi apte à assurer une interface entre le dispositif client 101 et un termi-nal utilisateur 100;
- une sortie 32 apte à délivrer des signaux démodulés par le démodula-teur 24 vers un décodeur satellite 31 dit encore STB ( Set Top Box en anglais).
Le câble coaxial 20 relie le boîtier 21 via son coupleur/découpleur 22 et l'unité d'émission/réception 2 via son coupleur/découpleur 15.
Le démodulateur 24 est par exemple un démodulateur fonctionnant selon la norme DVB-52 Le modulateur 25 fonctionne par exemple suivant un protocole asyn-chrone à accès aléatoire multiple à étalement de bande par modulation du type SPREAD ALOHA optimisé pour que le hub satellitaire puisse utiliser des moyens d'élimination d'interférences (un tel protocole est par exemple décrit dans la norme décrite dans le document ETSI TS 102 721-3 : Satel-lite Earth Stations and Systems. Air Interface for 5-band Mobile Interactive Multimedia (S-MIM); Part 3: Physical Layer Specification, Return Link Asyn-chronous Access. ).
L'ensemble des signaux est couplé sur le seul câble coaxial 20.
L'installation 1 repose sur une partie fonctionnant en voie aller per-mettant de recevoir des signaux TV et des données en bande Ku émis par une station terrestre (hub satellitaire) 104 (équipée d'un modula-teur/encapsulateur DVB-52 et d'un démodulateur fonctionnant suivant un protocole asynchrone à accès aléatoire multiple à étalement de bande) vers le satellite 102, et une voie retour en bande C ou Ka du satellite 103 vers ladite station 104 permettant la mise en place de services interactifs (votes, consommation de contenus à accès conditionnel par échange de clefs, commandes de nouveaux services tels que de la vidéo à la demande).
Il existe un fort déséquilibre en termes de débit binaire entre la voie aller et la voie retour de sorte que l'utilisation du protocole TCP/IP de ma-nière fiable et efficace est impossible.
Le procédé selon l'invention va avantageusement utiliser cette voie retour pour permettre à un utilisateur muni d'un terminal utilisateur 100 (par
- une sortie 32 apte à délivrer des signaux démodulés par le démodula-teur 24 vers un décodeur satellite 31 dit encore STB ( Set Top Box en anglais).
Le câble coaxial 20 relie le boîtier 21 via son coupleur/découpleur 22 et l'unité d'émission/réception 2 via son coupleur/découpleur 15.
Le démodulateur 24 est par exemple un démodulateur fonctionnant selon la norme DVB-52 Le modulateur 25 fonctionne par exemple suivant un protocole asyn-chrone à accès aléatoire multiple à étalement de bande par modulation du type SPREAD ALOHA optimisé pour que le hub satellitaire puisse utiliser des moyens d'élimination d'interférences (un tel protocole est par exemple décrit dans la norme décrite dans le document ETSI TS 102 721-3 : Satel-lite Earth Stations and Systems. Air Interface for 5-band Mobile Interactive Multimedia (S-MIM); Part 3: Physical Layer Specification, Return Link Asyn-chronous Access. ).
L'ensemble des signaux est couplé sur le seul câble coaxial 20.
L'installation 1 repose sur une partie fonctionnant en voie aller per-mettant de recevoir des signaux TV et des données en bande Ku émis par une station terrestre (hub satellitaire) 104 (équipée d'un modula-teur/encapsulateur DVB-52 et d'un démodulateur fonctionnant suivant un protocole asynchrone à accès aléatoire multiple à étalement de bande) vers le satellite 102, et une voie retour en bande C ou Ka du satellite 103 vers ladite station 104 permettant la mise en place de services interactifs (votes, consommation de contenus à accès conditionnel par échange de clefs, commandes de nouveaux services tels que de la vidéo à la demande).
Il existe un fort déséquilibre en termes de débit binaire entre la voie aller et la voie retour de sorte que l'utilisation du protocole TCP/IP de ma-nière fiable et efficace est impossible.
Le procédé selon l'invention va avantageusement utiliser cette voie retour pour permettre à un utilisateur muni d'un terminal utilisateur 100 (par
12 exemple un Smartphone, un PC ou une tablette tactile) équipé d'un naviga-teur ( browser en anglais) web connecté au dispositif client 101 d'avoir accès au contenu de pages HTML via son navigateur. Pour ce faire, le hub 104 est équipé d'un dispositif serveur 105 connecté au réseau internet 106 et dont nous préciserons les caractéristiques dans la suite de la description.
Les différentes étapes du procédé 200 selon l'invention sont illustrées en référence à la figure 2.
Le dispositif client 101 comporte :
- un ensemble 111 comportant un serveur DHCP 109 (Dynamic Host Configuration Protocol) et un serveur DNS 110 (Domain Name Sys-tem) ;
- une mémoire cache 108 ;
- des moyens clients 107 de réception de flux de données en mode push connectés au démodulateur 24.
Le dispositif serveur 105 comporte :
- une mémoire cache 112 ;
- des moyens 113 de connexion à Internet ;
- des moyens 114 d'émission de flux de données en mode push ;
- des moyens 115 de réception des messages envoyés par les termi-naux.
Nous partons ici de l'hypothèse que le dispositif client 101 est confi-guré en tant que serveur proxy HTTP pour le navigateur du terminal 100.
Cette configuration peut être manuelle soit à-travers une réponse à une re-quête DHCP si le terminal utilisateur supporte cette technologie (WPAD
Web Proxy Auto Discovery ).
Selon une étape 201, le terminal utilisateur 100 transmet une requête HTTP incluant l'adresse URL (dont il cherche à obtenir le contenu, typique-ment une page web) vers le dispositif client 101.
Selon une étape 202, la réception de l'adresse URL par le dispositif client 101 entraîne une vérification par le dispositif client 101 de la présence du contenu de ladite adresse URL dans sa mémoire cache. Si le contenu est présent, la page HTML correspondant à l'adresse URL est directement
Les différentes étapes du procédé 200 selon l'invention sont illustrées en référence à la figure 2.
Le dispositif client 101 comporte :
- un ensemble 111 comportant un serveur DHCP 109 (Dynamic Host Configuration Protocol) et un serveur DNS 110 (Domain Name Sys-tem) ;
- une mémoire cache 108 ;
- des moyens clients 107 de réception de flux de données en mode push connectés au démodulateur 24.
Le dispositif serveur 105 comporte :
- une mémoire cache 112 ;
- des moyens 113 de connexion à Internet ;
- des moyens 114 d'émission de flux de données en mode push ;
- des moyens 115 de réception des messages envoyés par les termi-naux.
Nous partons ici de l'hypothèse que le dispositif client 101 est confi-guré en tant que serveur proxy HTTP pour le navigateur du terminal 100.
Cette configuration peut être manuelle soit à-travers une réponse à une re-quête DHCP si le terminal utilisateur supporte cette technologie (WPAD
Web Proxy Auto Discovery ).
Selon une étape 201, le terminal utilisateur 100 transmet une requête HTTP incluant l'adresse URL (dont il cherche à obtenir le contenu, typique-ment une page web) vers le dispositif client 101.
Selon une étape 202, la réception de l'adresse URL par le dispositif client 101 entraîne une vérification par le dispositif client 101 de la présence du contenu de ladite adresse URL dans sa mémoire cache. Si le contenu est présent, la page HTML correspondant à l'adresse URL est directement
13 transmise au terminal utilisateur via la connexion TCP établie. Ce cas peut par exemple se produire si la page a déjà été demandée par l'utilisateur.
Selon une étape 203, en l'absence du contenu de l'adresse URL dans sa mémoire cache, le dispositif client 101 crée un message court incluant l'adresse URL. Pour envoyer ce message, le dispositif client 101 utilise par exemple le modulateur 25 fonctionnant suivant un protocole asynchrone à
accès aléatoire multiple à étalement de bande par modulation du type SPREAD ALOHA. Il convient de noter que le dispositif client 101 peut éga-lement procéder à une étape préalable de compression des données à en-voyer par exemple en utilisant un algorithme ZIP de façon à n'obtenir qu'un seul message court intégrant l'adresse URL, même si l'adresse URL est très longue. Comme nous le verrons plus dans ce qui suit, le message va en-suite être envoyé via la voie retour de l'installation 1 (ici en bande C ou Ka).
L'invention n'est toutefois pas limitée à une voie retour satellitaire et il est également possible de créer un message court de type SMS qui sera alors transmis par voie retour terrestre (connexion GPRS ou GSM-SMS). On note-ra ici que les voies aller et retour peuvent être totalement découplées ; à
l'extrême, le message peut être transmis comme une suite de chiffres com-posés sur une ligne téléphonique avec un clavier (i.e. on utilise les tonalités ( tones ) du téléphone en voie retour). De même, on peut parfaitement envisager d'autre scenarios possibles, par exemple que le dispositif client qui envoie la requête ne soit pas le même que celui qui reçoit le contenu demandé.
Selon une étape 204, le message est ensuite transmis par le disposi-tif client 101 vers le dispositif serveur 105 selon un protocole de transmis-sion unidirectionnel sans connexion. Comme indiqué précédemment, le message est par exemple envoyé sur la voie retour de l'installation 1 de sorte que le message transite par le satellite 103 puis est récupéré par le hub 104. Le dispositif serveur 105 est soit intégré au hub 104 soit commu-nique avec lui. Le dispositif serveur 105 va utiliser le démodulateur fonction-nant suivant un protocole asynchrone à accès aléatoire multiple à étalement de bande pour récupérer l'adresse URL.
Selon une étape 203, en l'absence du contenu de l'adresse URL dans sa mémoire cache, le dispositif client 101 crée un message court incluant l'adresse URL. Pour envoyer ce message, le dispositif client 101 utilise par exemple le modulateur 25 fonctionnant suivant un protocole asynchrone à
accès aléatoire multiple à étalement de bande par modulation du type SPREAD ALOHA. Il convient de noter que le dispositif client 101 peut éga-lement procéder à une étape préalable de compression des données à en-voyer par exemple en utilisant un algorithme ZIP de façon à n'obtenir qu'un seul message court intégrant l'adresse URL, même si l'adresse URL est très longue. Comme nous le verrons plus dans ce qui suit, le message va en-suite être envoyé via la voie retour de l'installation 1 (ici en bande C ou Ka).
L'invention n'est toutefois pas limitée à une voie retour satellitaire et il est également possible de créer un message court de type SMS qui sera alors transmis par voie retour terrestre (connexion GPRS ou GSM-SMS). On note-ra ici que les voies aller et retour peuvent être totalement découplées ; à
l'extrême, le message peut être transmis comme une suite de chiffres com-posés sur une ligne téléphonique avec un clavier (i.e. on utilise les tonalités ( tones ) du téléphone en voie retour). De même, on peut parfaitement envisager d'autre scenarios possibles, par exemple que le dispositif client qui envoie la requête ne soit pas le même que celui qui reçoit le contenu demandé.
Selon une étape 204, le message est ensuite transmis par le disposi-tif client 101 vers le dispositif serveur 105 selon un protocole de transmis-sion unidirectionnel sans connexion. Comme indiqué précédemment, le message est par exemple envoyé sur la voie retour de l'installation 1 de sorte que le message transite par le satellite 103 puis est récupéré par le hub 104. Le dispositif serveur 105 est soit intégré au hub 104 soit commu-nique avec lui. Le dispositif serveur 105 va utiliser le démodulateur fonction-nant suivant un protocole asynchrone à accès aléatoire multiple à étalement de bande pour récupérer l'adresse URL.
14 Selon une étape 205, le dispositif serveur 105 vérifie la présence du contenu de l'adresse URL dans sa mémoire cache.
Selon une étape 206, en l'absence du contenu de l'adresse URL dans sa mémoire cache, le dispositif serveur 105 se connecte au réseau Internet 106 pour télécharger la page web correspondant à l'adresse URL.
Selon une étape 207, le dispositif serveur 105 peut également faire du pré-chargement ( pre-fetching en langue anglaise) en récupérant des informations que l'utilisateur est susceptible de vouloir visiter dans un proche avenir. Pour ce faire, le dispositif serveur 105 analyse la page web HTML
téléchargée pour trouver les images et autres éléments dont le lien est con-tenu dans ladite page HTML. La page HTML et les éléments/images asso-ciées sont téléchargées et stockés dans la mémoire cache du dispositif ser-veur 105.
Selon une étape 208, le dispositif serveur 105 crée ensuite un fichier unique (par exemple un fichier compressé au format .zip) incluant la page HTML ainsi que les éléments/images pré-chargés.
Selon une étape 209, le dispositif serveur va utiliser ses moyens d'émission de flux de données en mode push pour transmettre le fichier via un protocole utilisé pour la technologie push (dit également datacast ) c'est à dire un protocole unidirectionnel avec codage sans acquittement. Ce protocole datacast peut nécessiter des opérations additionnelles telles que l'ajout de codes de correction d'erreur de manière à garantir une très forte probabilité de transmission sans erreur. Le fichier en tant que tel est transmis via un protocole de niveau physique tel que le DVB-52 en transi-tant par exemple par le satellite 102.
Le principe de la diffusion de contenus en mode push est qu'il n'y a pas de connexion à initier, et le contenu peut être reçu par plusieurs ou tous les dispositifs clients au même moment.
Selon une étape 210, les moyens clients de réception de flux de don-nées en mode push du dispositif client 101 intègrent des moyens logiciels qui écoutent et reçoivent en permanence ce qui est diffusé par le dispositif serveur. Ainsi, le dispositif client 101 récupère la page HTML correspondant à l'adresse URL ainsi que les éléments de ladite page dont le lien est conte-nu dans la page. Une fois récupérés, la page et les éléments sont stockés dans la mémoire cache du dispositif client 101.
Selon une étape 211, le terminal utilisateur 100 qui communique avec le dispositif client via sa connexion TCP reçoit la page HTML. Grâce au pre-5 fetching réalisé, le terminal utilisateur 100 peut également avoir un accès rapide aux informations visées par les liens contenus dans ladite page et stockées dans la mémoire cache du dispositif client 101.
Si le dispositif client 101 n'est pas configuré en tant que navigateur proxy, un mécanisme possible est illustré en figure 3.
10 Selon une première étape 301, le dispositif client 101 qui comporte un serveur DHCP reçoit une requête DHCP de la part du terminal 100 et alloue une adresse IF locale pour le terminal 100 ; il enregistre cette adresse asso-ciée au terminal dans sa mémoire cache. Le dispositif client 101 transmet sa propre adresse IF en tant que serveur DNS et passerelle par défaut au ter-
Selon une étape 206, en l'absence du contenu de l'adresse URL dans sa mémoire cache, le dispositif serveur 105 se connecte au réseau Internet 106 pour télécharger la page web correspondant à l'adresse URL.
Selon une étape 207, le dispositif serveur 105 peut également faire du pré-chargement ( pre-fetching en langue anglaise) en récupérant des informations que l'utilisateur est susceptible de vouloir visiter dans un proche avenir. Pour ce faire, le dispositif serveur 105 analyse la page web HTML
téléchargée pour trouver les images et autres éléments dont le lien est con-tenu dans ladite page HTML. La page HTML et les éléments/images asso-ciées sont téléchargées et stockés dans la mémoire cache du dispositif ser-veur 105.
Selon une étape 208, le dispositif serveur 105 crée ensuite un fichier unique (par exemple un fichier compressé au format .zip) incluant la page HTML ainsi que les éléments/images pré-chargés.
Selon une étape 209, le dispositif serveur va utiliser ses moyens d'émission de flux de données en mode push pour transmettre le fichier via un protocole utilisé pour la technologie push (dit également datacast ) c'est à dire un protocole unidirectionnel avec codage sans acquittement. Ce protocole datacast peut nécessiter des opérations additionnelles telles que l'ajout de codes de correction d'erreur de manière à garantir une très forte probabilité de transmission sans erreur. Le fichier en tant que tel est transmis via un protocole de niveau physique tel que le DVB-52 en transi-tant par exemple par le satellite 102.
Le principe de la diffusion de contenus en mode push est qu'il n'y a pas de connexion à initier, et le contenu peut être reçu par plusieurs ou tous les dispositifs clients au même moment.
Selon une étape 210, les moyens clients de réception de flux de don-nées en mode push du dispositif client 101 intègrent des moyens logiciels qui écoutent et reçoivent en permanence ce qui est diffusé par le dispositif serveur. Ainsi, le dispositif client 101 récupère la page HTML correspondant à l'adresse URL ainsi que les éléments de ladite page dont le lien est conte-nu dans la page. Une fois récupérés, la page et les éléments sont stockés dans la mémoire cache du dispositif client 101.
Selon une étape 211, le terminal utilisateur 100 qui communique avec le dispositif client via sa connexion TCP reçoit la page HTML. Grâce au pre-5 fetching réalisé, le terminal utilisateur 100 peut également avoir un accès rapide aux informations visées par les liens contenus dans ladite page et stockées dans la mémoire cache du dispositif client 101.
Si le dispositif client 101 n'est pas configuré en tant que navigateur proxy, un mécanisme possible est illustré en figure 3.
10 Selon une première étape 301, le dispositif client 101 qui comporte un serveur DHCP reçoit une requête DHCP de la part du terminal 100 et alloue une adresse IF locale pour le terminal 100 ; il enregistre cette adresse asso-ciée au terminal dans sa mémoire cache. Le dispositif client 101 transmet sa propre adresse IF en tant que serveur DNS et passerelle par défaut au ter-
15 minal 100.
Selon une étape 302, le terminal 100 transmet une requête DNS vers le dispositif client 101 correspondant à l'adresse URL saisie dans le naviga-teur.
Selon une étape 303, le dispositif client 101 vérifie la présence du nom du serveur de serveur associé à la requête DNS dans sa mémoire cache.
Selon une étape 304, si le nom de serveur associé à la requête DNS
est présent dans la mémoire cache, le dispositif client 100 transmet au ter-minal utilisateur 100 l'adresse IF déjà associée au nom de serveur.
Selon une étape 305, si le nom de serveur n'est pas présent dans la mémoire cache, le dispositif client 100 crée une adresse IF temporaire as-sociée au nom de serveur puis la transmet au terminal utilisateur 101 ; cette adresse IF temporaire est également enregistrée dans la mémoire cache.
L'adresse IF temporaire est une adresse fictive qui ne correspond effective-ment pas à l'adresse IF du nom de serveur, la seule condition étant que cette adresse temporaire n'appartienne pas au réseau local du terminal utili-sateur 100. En d'autres termes, le dispositif client 101 dupe le terminal utili-
Selon une étape 302, le terminal 100 transmet une requête DNS vers le dispositif client 101 correspondant à l'adresse URL saisie dans le naviga-teur.
Selon une étape 303, le dispositif client 101 vérifie la présence du nom du serveur de serveur associé à la requête DNS dans sa mémoire cache.
Selon une étape 304, si le nom de serveur associé à la requête DNS
est présent dans la mémoire cache, le dispositif client 100 transmet au ter-minal utilisateur 100 l'adresse IF déjà associée au nom de serveur.
Selon une étape 305, si le nom de serveur n'est pas présent dans la mémoire cache, le dispositif client 100 crée une adresse IF temporaire as-sociée au nom de serveur puis la transmet au terminal utilisateur 101 ; cette adresse IF temporaire est également enregistrée dans la mémoire cache.
L'adresse IF temporaire est une adresse fictive qui ne correspond effective-ment pas à l'adresse IF du nom de serveur, la seule condition étant que cette adresse temporaire n'appartienne pas au réseau local du terminal utili-sateur 100. En d'autres termes, le dispositif client 101 dupe le terminal utili-
16 sateur 100 en lui transmettant une fausse adresse comme s'il avait réso-lu le nom du serveur.
Selon une étape 306, le terminal utilisateur 100 tente d'établir une connexion TCP avec le serveur correspondant à l'adresse IF temporaire ; en réalité, le dispositif client 101 se substitue au serveur en s'attribuant ladite adresse IF temporaire de sorte que la connexion TCP est établie entre le terminal utilisateur 100 et le dispositif client 101 ; le dispositif client 101 si-mule ainsi une connexion TCP entre le terminal utilisateur 100 et le serveur associé à l'adresse URL. On retrouve à ce niveau l'étape 201 décrite en ré-férence à la figure 2.
Il est entendu que dans la description des étapes du procédé telles qu'illustrées sur les figures 2 et 3, les étapes ne sont pas nécessairement séquentielles ; les différents équipements (notamment le dispositif client 101 et le dispositif serveur 105) suivent chacun leurs propres étapes, lesdits dis-positifs pouvant fonctionner en parallèle.
Le dispositif client et le dispositif serveur sont destinés à la gestion des différentes opérations à exécuter pour mettre en oeuvre le procédé se-lon l'invention. Pour ce faire, ils comportent plusieurs moyens logiciels (i.e.
applications) dont certains sont dédiés à la mise en oeuvre de l'invention.
Dans d'autres exemples de réalisation, ces moyens logiciels pourraient être remplacés par des circuits électroniques spécifiques.
Bien entendu, l'invention n'est pas limitée au mode de réalisation qui vient d'être décrit.
Ainsi, l'invention a été plus particulièrement décrite dans le cas d'une utilisation en bande C ou Ka mais elle peut également être utilisée en bande S satellitaire (1980 ¨ 2010 MHz et 2170¨ 2200 MHz).
En outre, même si la voie aller a été plus spécifiquement décrite dans le cas d'une modulation/démodulation DVB-52, il est entendu que d'autres modulations/démodulations peuvent être utilisées telles que les normes DVB-T, DVB-T2, DVB-S ou DVB-SH.
De même, les étapes de pre-fetching peuvent aller au-delà des liens contenus dans la page demandée de sorte que le dispositif serveur peut également télécharger des pages particulièrement demandées ( best of the
Selon une étape 306, le terminal utilisateur 100 tente d'établir une connexion TCP avec le serveur correspondant à l'adresse IF temporaire ; en réalité, le dispositif client 101 se substitue au serveur en s'attribuant ladite adresse IF temporaire de sorte que la connexion TCP est établie entre le terminal utilisateur 100 et le dispositif client 101 ; le dispositif client 101 si-mule ainsi une connexion TCP entre le terminal utilisateur 100 et le serveur associé à l'adresse URL. On retrouve à ce niveau l'étape 201 décrite en ré-férence à la figure 2.
Il est entendu que dans la description des étapes du procédé telles qu'illustrées sur les figures 2 et 3, les étapes ne sont pas nécessairement séquentielles ; les différents équipements (notamment le dispositif client 101 et le dispositif serveur 105) suivent chacun leurs propres étapes, lesdits dis-positifs pouvant fonctionner en parallèle.
Le dispositif client et le dispositif serveur sont destinés à la gestion des différentes opérations à exécuter pour mettre en oeuvre le procédé se-lon l'invention. Pour ce faire, ils comportent plusieurs moyens logiciels (i.e.
applications) dont certains sont dédiés à la mise en oeuvre de l'invention.
Dans d'autres exemples de réalisation, ces moyens logiciels pourraient être remplacés par des circuits électroniques spécifiques.
Bien entendu, l'invention n'est pas limitée au mode de réalisation qui vient d'être décrit.
Ainsi, l'invention a été plus particulièrement décrite dans le cas d'une utilisation en bande C ou Ka mais elle peut également être utilisée en bande S satellitaire (1980 ¨ 2010 MHz et 2170¨ 2200 MHz).
En outre, même si la voie aller a été plus spécifiquement décrite dans le cas d'une modulation/démodulation DVB-52, il est entendu que d'autres modulations/démodulations peuvent être utilisées telles que les normes DVB-T, DVB-T2, DVB-S ou DVB-SH.
De même, les étapes de pre-fetching peuvent aller au-delà des liens contenus dans la page demandée de sorte que le dispositif serveur peut également télécharger des pages particulièrement demandées ( best of the
17 web ) qui seront ensuite stockées dans les mémoires cache du dispositif serveur et des dispositifs clients. On parlera dans ce cas d'opération de type advanced caching . Pour ce faire, le serveur peut utiliser des indicateurs qui sont reconnus par tous les clients visés par ce contenu : ces clients vont recevoir et stocker le contenu même si l'utilisateur ne l'a pas demandé.
Claims (15)
1. Procédé de récupération d'un contenu sous la forme d'une page HTML
correspondant à une adresse URL par un dispositif client comportant les étapes suivantes :
- à partir d'une adresse URL correspondant au dit contenu, vérification par le dispositif client de la présence du contenu de l'adresse URL
dans une mémoire du dispositif client ;
- en l'absence du contenu de l'adresse URL dans la mémoire, création par le dispositif client d'un message court incluant l'adresse URL ;
- transmission dudit message par le dispositif client vers un dispositif serveur selon un protocole de transmission unidirectionnel sans con-nexion donné ;
- téléchargement sur le réseau internet par le dispositif serveur du con-tenu correspondant à ladite adresse URL ;
- analyse dudit contenu par le dispositif serveur et téléchargement sur le réseau internet par le dispositif serveur des éléments tels que les images et les scripts dont le lien est contenu dans ledit contenu ;
- création par le dispositif serveur d'un unique fichier incorporant ledit contenu ainsi que les éléments précédemment téléchargés ;
- transmission dudit contenu ainsi que des éléments précédemment té-léchargés par le dispositif serveur vers le dispositif client sous la forme dudit unique fichier via un protocole unidirectionnel avec co-dage sans acquittement ;
- réception dudit unique fichier par le dispositif client ;
- récupération et stockage par le dispositif client dudit unique fichier dans ladite mémoire.
correspondant à une adresse URL par un dispositif client comportant les étapes suivantes :
- à partir d'une adresse URL correspondant au dit contenu, vérification par le dispositif client de la présence du contenu de l'adresse URL
dans une mémoire du dispositif client ;
- en l'absence du contenu de l'adresse URL dans la mémoire, création par le dispositif client d'un message court incluant l'adresse URL ;
- transmission dudit message par le dispositif client vers un dispositif serveur selon un protocole de transmission unidirectionnel sans con-nexion donné ;
- téléchargement sur le réseau internet par le dispositif serveur du con-tenu correspondant à ladite adresse URL ;
- analyse dudit contenu par le dispositif serveur et téléchargement sur le réseau internet par le dispositif serveur des éléments tels que les images et les scripts dont le lien est contenu dans ledit contenu ;
- création par le dispositif serveur d'un unique fichier incorporant ledit contenu ainsi que les éléments précédemment téléchargés ;
- transmission dudit contenu ainsi que des éléments précédemment té-léchargés par le dispositif serveur vers le dispositif client sous la forme dudit unique fichier via un protocole unidirectionnel avec co-dage sans acquittement ;
- réception dudit unique fichier par le dispositif client ;
- récupération et stockage par le dispositif client dudit unique fichier dans ladite mémoire.
2. Procédé selon la revendication précédente caractérisé en ce qu'il com-porte une étape d'extraction par le dispositif client à partir dudit unique fi-chier du contenu ainsi que des éléments précédemment téléchargés dont le lien est contenu dans ledit contenu, de stockage dudit contenu et desdits éléments précédemment téléchargés dans la mémoire du dispositif client, et de mise à la disposition d'un terminal utilisateur dudit contenu et desdits éléments précédemment téléchargés.
3. Procédé selon l'une des revendications précédentes caractérisé en ce qu'il comporte une étape de vérification par le dispositif serveur de la pré-sence du contenu l'adresse URL dans une mémoire du dispositif serveur de sorte que ledit téléchargement sur le réseau internet par le dispositif serveur du contenu correspondant à ladite adresse URL se fait en l'absence du con-tenu de l'adresse URL dans la mémoire.
4. Procédé selon la revendication précédente caractérisé en ce que ledit dispositif serveur envoie lesdits éléments de façon asynchrone, ledit disposi-tif client étant prêt à recevoir lesdits éléments et à les stocker dans sa mé-moire.
5. Procédé selon l'une des revendications précédentes caractérisé en ce qu'il comporte les étapes suivantes :
- tentative d'ouverture du lien associé à l'adresse URL sur le navigateur d'un terminal utilisateur ;
- transmission d'une requête DNS dudit terminal utilisateur vers le dis-positif client ;
- vérification par le dispositif client de la présence du nom de serveur associé à la requête DNS dans une base de données locale du dis-positif client ;
- si le nom de serveur est présent dans ladite base de données, trans-mission par le dispositif client vers le terminal utilisateur de l'adresse IP déjà associée au dit nom de serveur ;
- si le nom de serveur n'est pas présent dans ladite base de données, création par le dispositif client d'une adresse IP temporaire associée au dit nom de serveur puis transmission par le dispositif client vers le-dit terminal utilisateur de ladite adresse IP temporaire et enregistre-ment de ladite adresse IP temporaire dans ladite base de données ;
- tentative d'établissement d'une connexion TCP par le terminal utilisa-teur avec le serveur correspondant à ladite adresse IP temporaire, le-dit dispositif client se substituant au serveur en s'attribuant ladite adresse IP temporaire de sorte que la connexion TCP est établie entre le terminal utilisateur et le dispositif client ;
- transmission d'une requête HTTP incluant l'adresse URL par le termi-nal utilisateur vers le dispositif client, la réception de l'adresse URL
par le dispositif client entraînant ladite étape de vérification par ledit dispositif client de la présence du contenu de ladite adresse URL
dans une mémoire du dispositif client ;
- récupération du contenu par le dispositif client et envoi du contenu au terminal utilisateur à travers la connexion TCP établie.
- tentative d'ouverture du lien associé à l'adresse URL sur le navigateur d'un terminal utilisateur ;
- transmission d'une requête DNS dudit terminal utilisateur vers le dis-positif client ;
- vérification par le dispositif client de la présence du nom de serveur associé à la requête DNS dans une base de données locale du dis-positif client ;
- si le nom de serveur est présent dans ladite base de données, trans-mission par le dispositif client vers le terminal utilisateur de l'adresse IP déjà associée au dit nom de serveur ;
- si le nom de serveur n'est pas présent dans ladite base de données, création par le dispositif client d'une adresse IP temporaire associée au dit nom de serveur puis transmission par le dispositif client vers le-dit terminal utilisateur de ladite adresse IP temporaire et enregistre-ment de ladite adresse IP temporaire dans ladite base de données ;
- tentative d'établissement d'une connexion TCP par le terminal utilisa-teur avec le serveur correspondant à ladite adresse IP temporaire, le-dit dispositif client se substituant au serveur en s'attribuant ladite adresse IP temporaire de sorte que la connexion TCP est établie entre le terminal utilisateur et le dispositif client ;
- transmission d'une requête HTTP incluant l'adresse URL par le termi-nal utilisateur vers le dispositif client, la réception de l'adresse URL
par le dispositif client entraînant ladite étape de vérification par ledit dispositif client de la présence du contenu de ladite adresse URL
dans une mémoire du dispositif client ;
- récupération du contenu par le dispositif client et envoi du contenu au terminal utilisateur à travers la connexion TCP établie.
6. Procédé selon l'une des revendications précédentes caractérisé en ce que ledit protocole unidirectionnel avec codage sans acquittement est un des protocoles utilisés pour la technologie push dite aussi datacast .
7. Procédé selon l'une des revendications précédentes caractérisé en ce que ladite transmission du message par le dispositif client vers le dispositif serveur est réalisée par une transmission par satellite, ledit procédé compor-tant les étapes suivantes :
- transmission en voie montante par le dispositif client dudit message incorporé dans un signal modulé vers le satellite ;
- transmission en voie descendante par le satellite d'un signal incorpo-rant ledit signal modulé incorporant le message vers une station ter-restre connectée au dispositif serveur.
- transmission en voie montante par le dispositif client dudit message incorporé dans un signal modulé vers le satellite ;
- transmission en voie descendante par le satellite d'un signal incorpo-rant ledit signal modulé incorporant le message vers une station ter-restre connectée au dispositif serveur.
8. Procédé selon la revendication précédente caractérisé en ce que le signal modulé incorporant le message émis par le dispositif client est modulé selon un protocole à étalement de spectre fonctionnant selon un protocole asyn-chrone à accès aléatoire multiple à étalement de spectre.
9. Procédé selon l'une des revendications précédentes caractérisé en ce que ladite transmission du contenu par le dispositif serveur vers le dispositif client est réalisée par une transmission par satellite.
10. Procédé selon l'une des revendications précédentes caractérisé en ce que ledit dispositif client crée ledit message incluant ladite adresse URL
sous un format compressé.
sous un format compressé.
11. Procédé selon l'une des revendications précédentes caractérisé en ce que ledit dispositif serveur ignore le message quand il a déjà envoyé le con-tenu demandé de façon asynchrone et que le dispositif client a émis ledit message avant d'avoir reçu le contenu.
12. Procédé selon l'une des revendications précédentes caractérisé en ce que ledit dispositif serveur marque certains fichiers incorporant du contenu avec un ou plusieurs indicateurs tels que des flags pour qu'ils soient reçus et stockés par plusieurs dispositifs clients en même temps.
13. Procédé selon la revendication précédente caractérisé en ce que ledit dispositif client reçoit et enregistre dans sa mémoire tous les fichiers qui sont marqués par le dispositif serveur avec un indicateur présent dans une liste préétablie.
14. Dispositif client comportant des moyens pour la mise en uvre du pro-cédé selon l'une quelconque des revendications précédentes.
15. Dispositif serveur comportant des moyens pour la mise en uvre du procédé selon l'une quelconque des revendications 1 à 14.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1260262A FR2997598B1 (fr) | 2012-10-26 | 2012-10-26 | Procede de recuperation d'un contenu correspondant a une adresse url par un dispositif client |
| FR1260262 | 2012-10-26 | ||
| PCT/EP2013/071650 WO2014063971A1 (fr) | 2012-10-26 | 2013-10-16 | Procede de recuperation d'un contenu correspondant a une adresse url par un dispositif client |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2889329A1 true CA2889329A1 (fr) | 2014-05-01 |
Family
ID=47356221
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2889329A Abandoned CA2889329A1 (fr) | 2012-10-26 | 2013-10-16 | Procede de recuperation d'un contenu correspondant a une adresse url par un dispositif client |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US10523734B2 (fr) |
| EP (1) | EP2912849A1 (fr) |
| BR (1) | BR112015009293A2 (fr) |
| CA (1) | CA2889329A1 (fr) |
| FR (1) | FR2997598B1 (fr) |
| MX (1) | MX353184B (fr) |
| RU (1) | RU2015119609A (fr) |
| WO (1) | WO2014063971A1 (fr) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2984641B1 (fr) * | 2011-12-15 | 2014-06-13 | Eutelsat Sa | Installation d'emission/reception de signaux radioelectriques |
| JP2015108970A (ja) * | 2013-12-04 | 2015-06-11 | ソニー株式会社 | サーバ装置、及び、情報処理方法 |
| DE102015011875A1 (de) * | 2015-09-10 | 2017-03-16 | Kathrein-Werke Kg | Einrichtung zum Senden und Empfangen von Mobilfunk-Signalen mittels einer stationären Antenne |
| US10419066B1 (en) * | 2017-10-05 | 2019-09-17 | Harmonic, Inc. | Remote radio frequency (RF) AGC loop |
| US11265301B1 (en) * | 2019-12-09 | 2022-03-01 | Amazon Technologies, Inc. | Distribution of security keys |
| US20230350965A1 (en) * | 2022-03-10 | 2023-11-02 | Hexagon Technology Center Gmbh | System and Method for Validating a Protocol-Compliant Uniform Resource Locator |
| US20240070151A1 (en) * | 2022-08-26 | 2024-02-29 | Salesforce, Inc. | Database systems and client-side query transformation methods |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6199107B1 (en) * | 1998-07-22 | 2001-03-06 | Microsoft Corporation | Partial file caching and read range resume system and method |
| US6332158B1 (en) * | 1998-12-03 | 2001-12-18 | Chris Risley | Domain name system lookup allowing intelligent correction of searches and presentation of auxiliary information |
| US7861275B1 (en) * | 1999-04-23 | 2010-12-28 | The Directv Group, Inc. | Multicast data services and broadcast signal markup stream for interactive broadcast systems |
| US6697850B1 (en) * | 2000-05-09 | 2004-02-24 | Northrop Grumman Corporation | Satellite-based communications system having an on-board internet web proxy cache |
| KR100451541B1 (ko) * | 2001-07-10 | 2004-10-08 | (주)니트 젠 | 웹을 통한 이용자인터페이스 제공방법 |
| US20070250597A1 (en) * | 2002-09-19 | 2007-10-25 | Ambient Devices, Inc. | Controller for modifying and supplementing program playback based on wirelessly transmitted data content and metadata |
| US8010670B2 (en) * | 2003-12-23 | 2011-08-30 | Slipstream Data Inc. | Meta-data based method for local cache utilization |
| KR100774933B1 (ko) * | 2005-10-28 | 2007-11-09 | 엘지전자 주식회사 | 이동통신 단말기, 이를 이용한 송신측 링크 관리방법 및수신측 링크 관리방법 |
| US8037126B2 (en) * | 2007-03-12 | 2011-10-11 | Citrix Systems, Inc. | Systems and methods of dynamically checking freshness of cached objects based on link status |
| US8769156B2 (en) * | 2009-12-23 | 2014-07-01 | Citrix Systems, Inc. | Systems and methods for maintaining transparent end to end cache redirection |
| FR2954869B1 (fr) * | 2009-12-24 | 2017-11-24 | Eutelsat Sa | Installation d'emission/reception de signaux satellitaires |
| US8468130B2 (en) * | 2010-04-02 | 2013-06-18 | Skyfire Labs, Inc. | Assisted hybrid mobile browser |
| US20120185783A1 (en) * | 2011-01-19 | 2012-07-19 | Abel Avellan | System and method for zero latency browsing |
| KR101852815B1 (ko) * | 2011-06-21 | 2018-06-04 | 엘지전자 주식회사 | 클라이언트용 및 서버용 단말기 및 그 제어 방법 |
| US9094090B2 (en) * | 2011-09-23 | 2015-07-28 | Gilat Satellite Networks Ltd. | Decentralized caching system |
-
2012
- 2012-10-26 FR FR1260262A patent/FR2997598B1/fr not_active Expired - Fee Related
-
2013
- 2013-10-16 CA CA2889329A patent/CA2889329A1/fr not_active Abandoned
- 2013-10-16 BR BR112015009293A patent/BR112015009293A2/pt not_active IP Right Cessation
- 2013-10-16 WO PCT/EP2013/071650 patent/WO2014063971A1/fr active Application Filing
- 2013-10-16 MX MX2015005213A patent/MX353184B/es active IP Right Grant
- 2013-10-16 RU RU2015119609A patent/RU2015119609A/ru not_active Application Discontinuation
- 2013-10-16 EP EP13783276.2A patent/EP2912849A1/fr not_active Withdrawn
- 2013-10-16 US US14/438,297 patent/US10523734B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| WO2014063971A1 (fr) | 2014-05-01 |
| US20150295987A1 (en) | 2015-10-15 |
| FR2997598B1 (fr) | 2015-12-25 |
| EP2912849A1 (fr) | 2015-09-02 |
| BR112015009293A2 (pt) | 2017-07-04 |
| MX2015005213A (es) | 2016-02-10 |
| MX353184B (es) | 2018-01-05 |
| FR2997598A1 (fr) | 2014-05-02 |
| US10523734B2 (en) | 2019-12-31 |
| RU2015119609A (ru) | 2016-12-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2889329A1 (fr) | Procede de recuperation d'un contenu correspondant a une adresse url par un dispositif client | |
| US11252210B2 (en) | Content set based deltacasting | |
| US11777654B2 (en) | Transport protocol for anticipatory content | |
| US6845230B2 (en) | System and method for a push-pull gateway-directed digital receiver | |
| EP2188954B1 (fr) | Méthode de transmission de messages acars sur ip. | |
| US7756465B2 (en) | Digital radio feedback apparatuses, system, and methods | |
| EP3416302B1 (fr) | Systeme de telecommunications comprenant un serveur de cache embarque dans une plateforme a haute altitude et procede de transmission de donnees associe | |
| WO2008155181A1 (fr) | Disposition de gestion de reception par des terminaux de contenus multimedia transmis par des infrastructures mettant en oeuvre des techniques de transmission differentes | |
| EP2792087B1 (fr) | Emission/réception de signaux hyperfréquences de diffusion par satellite avec voie de retour interactive utilisant un protocole à étalement de spectre. | |
| EP3149917B1 (fr) | Dispositif et procede pour passerelle de mise a jour consistente des services d'un reseau domestique | |
| EP2587700B1 (fr) | Installation d'émission/réception de signaux radioélectriques | |
| EP2460330B1 (fr) | Procede de diffusion de donnees par un serveur vers des terminaux utilisateurs | |
| FR2697699A1 (fr) | Dispositif de réamplification d'un signal radiofréquence, notamment pour des applications domestiques, et systèmes de réception correspondant. | |
| FR2672756A1 (fr) | Systeme de radiomessagerie et terminal d'abonne pour recevoir des messages du systeme. | |
| EP2928088B1 (fr) | Procédé pour l'établissement de liaisons radiofréquences par satellite avec voie aller et retour utilisant la même bande de fréquence permettant un fonctionnement à saturation de la chaîne d'amplification du satellite. | |
| FR2947414A1 (fr) | Procedes d'emission pour un reseau sans fil et procede de reception correspondant. | |
| US7873703B2 (en) | Method and apparatus for broadcasting information | |
| WO2023083763A1 (fr) | Procédé de gestion des communications dans un réseau de communication mettant en œuvre au moins un équipement intermédiaire mobile, système et programme d'ordinateur correspondants | |
| EP1843489A1 (fr) | Dispositif de traitement de données à transmettre sur une voie retour d'un réseau de communication et ne necessitant pas d'acquittement systématique sur une voie aller | |
| WO2002001845A2 (fr) | Boitier de reception de donnees numeriques a deux interfaces de type modem | |
| TR2023005997A2 (tr) | Uydu iletişimde gecikme azaltma sistemi ve yöntemi | |
| FR2988939A1 (fr) | Diffusion hybride alternative | |
| FR2933254A1 (fr) | Methode et systeme de diffusion de donnees | |
| FR2947690A1 (fr) | Systeme de gestion d'autorisations geographiques pour terminaux sans licence operant dans les bandes vhf et uhf | |
| FR2752345A1 (fr) | Systeme de transmission par satellite presentant un canal de retour |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request |
Effective date: 20180618 |
|
| FZDE | Discontinued |
Effective date: 20210831 |
|
| FZDE | Discontinued |
Effective date: 20210831 |