ES2970866T3 - Gestión de recursos de contenido en caché - Google Patents

Gestión de recursos de contenido en caché Download PDF

Info

Publication number
ES2970866T3
ES2970866T3 ES16900654T ES16900654T ES2970866T3 ES 2970866 T3 ES2970866 T3 ES 2970866T3 ES 16900654 T ES16900654 T ES 16900654T ES 16900654 T ES16900654 T ES 16900654T ES 2970866 T3 ES2970866 T3 ES 2970866T3
Authority
ES
Spain
Prior art keywords
client device
server
caches
cache
content resource
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.)
Active
Application number
ES16900654T
Other languages
English (en)
Inventor
Stefan Håkansson
Adam Bergkvist
Christer Holmberg
Daniel Lindström
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2970866T3 publication Critical patent/ES2970866T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2457—Query processing with adaptation to user needs
    • G06F16/24573—Query processing with adaptation to user needs using data annotations, e.g. user-defined metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • 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/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5681—Pre-fetching or pre-delivering data based on network characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • 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/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • 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/52—Network services specially adapted for the location of the user terminal

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Library & Information Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un servidor (500), un dispositivo cliente (502) y métodos en el mismo, para manejar recursos de contenido almacenados en caché. Al recibir (5:3) una solicitud del dispositivo cliente (502) en una sesión de descarga, el servidor (500) identifica (5:4) un conjunto de cachés (504, 506) a los que puede acceder el dispositivo cliente (502). El servidor (500) luego envía (5:6)5 un mapa de caché al dispositivo cliente (502) indicando que un primer recurso de contenido está almacenado en una primera caché (504) del conjunto identificado de cachés y un segundo recurso de contenido está almacenado en una segunda caché (506) del conjunto de cachés identificado. De este modo, el servidor (500) puede adaptar el mapa de caché dependiendo de a qué cachés puede acceder el dispositivo cliente (502), para garantizar que el dispositivo cliente 10 (502) pueda recuperar los recursos de contenido de manera eficiente. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Gestión de recursos de contenido en caché
Campo técnico
La descripción se refiere a un servidor, a un dispositivo de cliente y a métodos allí presentes, así como a programas de ordenador para gestionar recursos de contenido en caché.
Antecedentes
En los últimos años, la cantidad de tráfico en las redes de comunicación como, por ejemplo, Internet y redes inalámbricas, ha aumentado enormemente debido al uso costoso de varios servicios web donde los usuarios descargan contenido como, por ejemplo, páginas web de diferentes sitios web en sus dispositivos de cliente. En la presente descripción, el término “dispositivo de cliente” se usa para representar cualquier entidad de comunicación que pueda descargar contenido de un servidor u otro almacenamiento de contenido en una red de comunicación. Además, el término “servidor” se usa para representar cualquier entidad de comunicación que pueda entregar contenido como, por ejemplo, páginas web a dispositivos de cliente en una red de comunicación que puede incluir Internet y/o una red inalámbrica. También puede hacerse referencia al servidor descrito a lo largo de la presente descripción como un servidor de contenido, un servidor de origen, un anfitrión de servidor de contenido o un anfitrión de servidor de origen.
Normalmente, las páginas web, o sus partes, se descargan en una sesión de navegación donde un usuario de un dispositivo de cliente puede navegar por un sitio web o similar y hacer clic en enlaces para obtener varios recursos web. Otros tipos de contenido como, por ejemplo, películas, música y programas de TV, pueden también descargarse de un servidor. El término “recurso de contenido” se usa en la presente memoria para representar cualquier contenido que pueda descargarse en una sesión de navegación. Un recurso de contenido puede, por consiguiente, sin limitación, ser una página web o alguna parte de ella, o algún vídeo o contenido de audio al que pueda accederse desde un sitio web.
Con el fin de reducir la cantidad de tráfico provocada por dichas descargas, puede emplearse almacenamiento en caché donde los recursos de contenido ofrecidos por un servidor se almacenan en una ubicación que es “más cercana” a los dispositivos de cliente en términos de la cantidad de enlaces de transporte y nodos de red implicados y, de esta manera, se reduce la distancia de transporte y también el tiempo que lleva obtener un recurso de contenido solicitado. Por ejemplo, recursos de contenido solicitados con frecuencia pueden almacenarse en caché de esta manera para reducir el tráfico en la red provocado por dichas solicitudes y la comunicación resultante entre los dispositivos de cliente y el servidor, al que se hace referencia como viajes de ida y vuelta.
La ubicación donde los recursos de contenido se almacenan en memoria de esta manera se denomina comúnmente “una caché”, cuyo término se usará en la presente memoria. Una caché es, por consiguiente, un almacenamiento para recursos de contenido. El término “servidor de origen” también se usa comúnmente para denotar un servidor, o anfitrión de servidor, donde originalmente se almacena contenido, cuyo contenido puede almacenarse de manera temporal, a saber, en caché, en una caché.
Cuando se descargan recursos de contenido de un servidor accediendo a un sitio web o similar, puede requerirse una gran cantidad de viajes de ida y vuelta entre el dispositivo de cliente y el servidor cuando cada recurso de contenido debe solicitarse por separado, solo para dirigirse a la caché. Ello se requiere cuando HTTPS (protocolo de transferencia de hipertexto seguro, HTTPS, por sus siglas en inglés) se emplea mientras que cuando se emplea un HTTP (protocolo de transferencia de hipertexto, HTTP, por sus siglas en inglés) las solicitudes terminan en la caché. Para HTTPS, se ha introducido el concepto de "Caché Ciega", BC, por sus siglas en inglés, también conocido como "Caché fuera de banda", OOBC, por sus siglas en inglés, para permitir el almacenamiento en caché eficiente también cuando se emplea HTTPS. Brevemente descrito, BC o OOBC permiten traer recursos de contenido directamente de una caché incluso cuando los recursos de contenido están encriptados, p. ej., mediante el uso de HTTPS. La cantidad de viajes de ida y vuelta en una sesión de navegación puede reducirse empleando el así llamado mapa de caché con información sobre de dónde un rango de recursos de contenido diferentes puede traerse o recuperarse de una caché. También puede hacerse referencia al mapa de caché como un mapa de recursos. A lo largo de la presente descripción, los términos “que recupera(n)” y “que descarga(n)” se usan de manera intercambiable.
En breve, el servidor, normalmente un servidor de origen o similar, envía el mapa de caché al dispositivo de cliente de forma temprana en una sesión de descarga, y cada vez que se trae un nuevo recurso de contenido como, por ejemplo, cuando un usuario hace clic en o de otra manera activa un enlace en una página web, el dispositivo de cliente verifica si dicho recurso de contenido está presente en el mapa de caché. Una página web puede estar asociada a numerosos recursos de contenido individuales, a veces cientos de ellos, y cuando el usuario navega en dicha página web, el dispositivo de cliente necesita traer todos dichos recursos de contenido. Si cualquiera de los recursos de contenido está presente en el mapa de caché, el dispositivo de cliente puede recuperar dichos recursos de contenido de una caché según el mapa de caché, en lugar de solicitarlos del servidor solo para redirigirlos a la caché. Para una mayor descripción del mapa de caché, se hace referencia al documento"Delivering contení via Out-Of-Band Cache" drafteriksson-oob- caché-00.text,de G. Eriksson y C. Holmberg: https://github.com/EricssonResearch/blind-cachedraft/blob/master/draft-eriksson-oob- cache-latest.txt, recuperado el 8 de febrero de 2016.
Sin embargo, es un problema con procedimientos convencionales que las cachés descritas más arriba para almacenar y proveer recursos de contenido a dispositivos de cliente pueden no utilizarse de manera eficiente. Por ejemplo, una caché indicada en un mapa de caché para un recurso de contenido puede no ser adecuada para recuperar el recurso de contenido de allí por un dispositivo de cliente.
El documento US-2014/0359045-A1 describe un servidor de gestión de caché que gestiona, de forma dinámica, la distribución de contenido específico para el usuario a una o más cachés distribuidas según ubicaciones de usuario conocidas o esperadas.
Compendio
Mediante el uso de un servidor, un dispositivo de cliente y métodos allí presentes según se definen en las reivindicaciones independientes anexas, la gestión de recursos de contenido en caché puede mejorarse y ser más eficiente, p. ej., en términos de latencia y carga, en comparación con los procedimientos convencionales.
El alcance de la invención se define por las reivindicaciones anexas.
Breve descripción de los dibujos
La solución se describirá ahora en mayor detalle por medio de realizaciones a modo de ejemplo y con referencia a los dibujos anexos, en los cuales:
La Figura 1 es un escenario de comunicación que ilustra cómo una caché puede usarse para proveer recursos de contenido, que pueden emplearse cuando se implementan realizaciones descritas en la presente memoria.
La Figura 2 es un diagrama de flujo que ilustra un procedimiento en un servidor, según algunas realizaciones posibles.
La Figura 3 es un diagrama de flujo que ilustra un procedimiento en un dispositivo de cliente, según realizaciones posibles adicionales.
La Figura 4 es un diagrama de bloques que ilustra ejemplos de cómo un dispositivo de cliente puede configurarse para permitir realizaciones descritas en la presente memoria.
La Figura 5 es un diagrama de señalización que ilustra un ejemplo más detallado de un procedimiento cuando se usa la solución, según realizaciones posibles adicionales.
La Figura 6 es una ilustración esquemática de entradas en un mapa de caché, según realizaciones posibles adicionales.
La Figura 7 es un diagrama de bloques que ilustra un servidor y un dispositivo de cliente en mayor detalle, según realizaciones posibles adicionales.
Descripción detallada
Descrito brevemente, se provee una solución para permitir la recuperación eficiente de recursos de contenido en caché para un dispositivo de cliente, y también para permitir, en general, la distribución flexible y eficiente de recursos de contenido a lo largo de múltiples cachés. Lo descrito más arriba puede lograrse de la siguiente manera. Cuando el dispositivo de cliente envía una solicitud a un servidor en una sesión de descarga, el servidor identifica un conjunto de cachés a las que puede acceder el dispositivo de cliente. Dichas cachés accesibles pueden indicarse en la propia solicitud o pueden ser conocidas por el servidor con antelación, p. ej., en la forma de capacidades preconfiguradas o similar. El servidor entonces envía un mapa de caché al dispositivo de cliente que indica que los recursos de contenido se almacenan en dos o más de las cachés identificadas como accesibles para el dispositivo de cliente.
En mayor detalle, el mapa de caché indica que al menos un primer recurso de contenido se almacena en una primera caché y un segundo recurso de contenido se almacena en una segunda caché, donde tanto la primera como la segunda cachés están presentes en el conjunto de cachés identificado. De esta manera, el servidor también puede adaptar el mapa de caché dependiendo de a cuáles cachés puede acceder el dispositivo de cliente y asegurar que el dispositivo de cliente puede recuperar los recursos de contenido de manera eficiente. Dado que el mapa de caché señala más de una caché, es también posible distribuir la carga en las cachés provocada por las operaciones de recuperación del dispositivo, de manera flexible. Otra ventaja es que no es necesario que el servidor empuje o transfiera un recurso de contenido a una caché que no tiene dicho recurso de contenido, si ya está almacenado y disponible desde otra caché que se identifica como accesible para el dispositivo de cliente.
Además, un recurso de contenido puede almacenarse en más de una caché, lo cual puede indicarse en el mapa de caché de modo que el dispositivo de cliente puede seleccionar la mejor caché y recuperar el recurso de contenido desde allí, si fuera necesario. El término “mejor caché” implica que esta caché es, en algún aspecto, la más adecuada para la recuperación, p. ej., en términos de proximidad en el sentido de que la caché puede estar “más cerca” del dispositivo de cliente, en el sentido de que la cantidad de enlaces de transporte y nodos de red entre ellos puede ser menor que las otras cachés que tienen el mismo recurso de contenido. De esta manera, la distancia de transporte y también el tiempo que lleva recuperar el recurso de contenido serán más cortos. La elección de caché se controla además por medio de uno o más criterios de selección que se comprenden en el mapa de caché enviado al dispositivo de cliente. Algunos ejemplos de cómo puede usarse un criterio de selección se describirán más adelante más abajo.
La Figura 1 ilustra un escenario de comunicación donde puede emplearse la solución de la siguiente manera. En el presente escenario, un servidor 100 está operativo para permitir que un dispositivo 102 de cliente descargue recursos de contenido en una red 104 de comunicación. En otras palabras, el servidor 100 está operativo para proveer recursos de contenido al dispositivo 102 de cliente. "Red de comunicación" es un término general usado aquí para representar cualquier tipo de red en la cual puedan transportarse recursos de contenido, p. ej., incluida una red inalámbrica o móvil si el dispositivo 102 de cliente es un dispositivo inalámbrico con capacidad de comunicación radioeléctrica. La solución descrita en la presente memoria también es aplicable para un dispositivo de cliente que utiliza una conexión fija o cableada a la red 104 de comunicación. La red 104 de comunicación esquemáticamente ilustrada puede también incluir Internet. El servidor 100 puede comprender un almacenamiento 100A que contiene todos los recursos de contenido provistos por el servidor 100 de modo que cualquier recurso de contenido puede descargarse, a saber, traerse, del propio servidor 100 si no de una caché.
En algunos ejemplos descritos en la presente memoria, se supone que el dispositivo de cliente se utiliza por un usuario, aunque las realizaciones en la presente memoria no se encuentran limitadas a ello y algunos ejemplos no restrictivos de dispositivos se ilustran más abajo. El dispositivo 102 de cliente es, en el presente ejemplo ilustrado esquemáticamente, como un teléfono móvil en la forma de un teléfono inteligente en la Figura 1, pero puede también ser cualquiera de un ordenador portátil, una tableta, un decodificador, un TV inteligente, un módem inalámbrico y un dispositivo de sensor. También puede ser un dispositivo más estacionario como, por ejemplo, una unidad telemática incorporada en o que puede fijarse a un vehículo como, por ejemplo, un automóvil, camión, autobús, barco, tren, avión y dron volador. El dispositivo 102 de cliente puede también, por ejemplo, estar incorporado en o fijarse a un electrodoméstico como, por ejemplo, productos de línea blanca, cerraduras de puertas, equipo de vigilancia y alarma, y aspiradoras y cortacéspedes autónomos.
El dispositivo de cliente también puede estar incorporado en o fijarse a unidades telemáticas para robots e impresoras 3D con fines industriales o funciones de apoyo doméstico. Otros ejemplos de dónde puede incorporarse o añadirse el dispositivo de cliente incluyen equipos de servicio público como, por ejemplo, alumbrado público, cámaras de vigilancia y equipo de admisión de entrada para el transporte público. El dispositivo de cliente descrito en la presente memoria puede, en otras palabras, estar, o puede implementarse en, cualquier equipo que pueda utilizar la conectividad a la red 104 de comunicación. Ejemplos adicionales de dichos dispositivos de cliente son equipos usados en servicios de salud y en terminales de pago, p. ej., terminales de pago para tarjetas de crédito.
Una primera acción 1:1 ilustra que el servidor 100 lleva a cabo el almacenamiento en caché de varios recursos de contenido almacenándolos en diferentes cachés 106, de ahí que se denomine almacenamiento en caché, para permitir descargas más rápidas a los dispositivos de cliente. Por ejemplo, el servidor 100 puede transferir contenido a las cachés 106, o el servidor puede, de manera alternativa, enviar una lista de recursos de contenido a las cachés 106 que, a su vez, traerán dichos recursos del servidor 100. De manera alternativa, una caché 106 puede traer el recurso de contenido del servidor 100 si el recurso solicitado no estaba disponible en la caché. Se ha descrito más arriba cómo el almacenamiento en caché puede proveer una descarga más eficiente de recursos de contenido. Se supone que el dispositivo 102 de cliente puede traer recursos de contenido de al menos algunas de las cachés 106 de manera más eficiente que trayéndolos del servidor 100. Esta acción de almacenamiento en caché puede llevarse a cabo de una vez por todas, o en diferentes ocasiones, p. ej., cuando un recurso de contenido se convierta en disponible en el servidor 100 o cuando un dispositivo de cliente solicite un recurso de contenido.
Las siguientes acciones en la Figura 1 ilustran cómo una sesión de descarga puede ejecutarse para el dispositivo 102 de cliente en el escenario que se muestra. La sesión de descarga puede comenzar, p. ej., cuando un usuario hace clic en un enlace a una página web u otro contenido, o cuando alguna aplicación que se está ejecutando en el dispositivo necesita un recurso de contenido, lo cual hace que el dispositivo 102 de cliente envíe una solicitud de contenido al servidor 100. La siguiente acción 1:2 ilustra, por consiguiente, que el dispositivo 102 de cliente envía una solicitud de descarga al servidor 100, que puede ser la primera solicitud, o al menos una solicitud “temprana”, de recurso de contenido en la sesión de descarga. Según se describe más arriba, la selección de un enlace a cierto contenido puede hacer que el dispositivo de cliente descargue una serie de recursos de contenido individuales asociados a dicho enlace, cada operación de descarga requiriendo, normalmente, una solicitud de descarga del dispositivo de cliente.
En respuesta a la solicitud de descarga de la acción 1:2, el servidor 100 envía una respuesta que incluye un mapa de caché al dispositivo 102 de cliente, ilustrado por la siguiente acción 1:3. La respuesta en la presente acción puede también contener un recurso de contenido solicitado en la solicitud de descarga. El mapa de caché enviado indica que los recursos de contenido se almacenan en dos o más cachés que se han identificado como accesibles para el dispositivo de cliente, lo cual se describirá en mayor detalle más adelante más abajo. Ejemplos de cómo el mapa de caché puede configurarse en la práctica por el servidor 100 también se describirán más adelante más abajo. Una acción 1:4 final ilustra que el dispositivo 102 de cliente recupera uno o más recursos de contenido de al menos una de las cachés 106, según el mapa de caché.
En la comunicación de las acciones descritas más arriba, el protocolo HTTP puede usarse, p. ej., según cualquiera de los siguientes 3 ejemplos.
Ejemplo 1: el dispositivo 102 de cliente envía una solicitud HTTP GET de un recurso de contenido en la acción 1:2. En respuesta a ello, el servidor 100 envía un 200 OK en la acción 1:3, y añade content-encoding: out-of-band. El contenido de 200 OK contiene el mapa de caché en lugar del recurso real.
Ejemplo 2: el dispositivo 102 de cliente envía una solicitud HTTP GET de un recurso de contenido en la acción 1:2. En respuesta a ello, el servidor 100 envía un 200 OK en la acción 1:3 con content-type: multipart/mixed. Una parte del cuerpo es el contenido solicitado y la otra es el mapa de caché.
Ejemplo 3: el dispositivo 102 de cliente envía una solicitud HTTP GET de un recurso de contenido en la acción 1:2. En respuesta a ello, el servidor 100 envía un 200 OK en la acción 1:3 con un encabezamiento de enlace y un cuerpo que contiene el recurso solicitado. El encabezamiento de enlace en el 200 OK informa al dispositivo 102 de cliente que hay un mapa de caché disponible en cierta dirección de mapa de caché. El encabezamiento de enlace en el 200 OK puede, p. ej., ser
Enlace: https://a_server.com/path_to_resource_map; rel="resource-map"
El cliente entonces envía una solicitud HTTP GET a la dirección de mapa de caché y obtiene el mapa de caché.
Ahora, se describirá un ejemplo con referencia al diagrama de flujo en la Figura 2, de cómo puede emplearse la solución en términos de acciones que pueden llevarse a cabo en un servidor como, por ejemplo, el servidor 100 descrito más arriba, para gestionar recursos de contenido en caché. A veces, también se hará referencia, sin limitar las características descritas, al ejemplo que se muestra en la Figura 1. El procedimiento ilustrado en la Figura 2 puede, por consiguiente, usarse para lograr la funcionalidad descrita más arriba para el servidor 100 en comunicación con el dispositivo 102 de cliente.
Una primera acción 200 ilustra que el servidor 100 recibe una solicitud de descarga del dispositivo 102 de cliente en una sesión de descarga. Se ha descrito más arriba, con referencia a la acción 1:2, cómo dicha solicitud de descarga puede comunicarse. En una siguiente acción 202, el servidor 100 identifica un conjunto de cachés a las que puede acceder el dispositivo 102 de cliente. También puede hacerse referencia al conjunto de cachés identificado como las “cachés accesibles”, para abreviar, cuyo término se utilizará en la presente memoria.
La identificación de más arriba de cachés accesibles puede llevarse a cabo según cualquiera de los siguientes ejemplos no restrictivos. En un ejemplo, el cliente puede indicar a cuáles cachés puede acceder en la propia solicitud, p. ej., en la forma de una lista de cachés accesibles. El servidor 100 puede identificar las cachés accesibles accediendo a algunas capacidades o similares que se han preconfigurado para el dispositivo 102 de cliente. Dichas capacidades pueden mantenerse por el propio servidor 100 o por una red de acceso, p. ej., una red inalámbrica, usada por el dispositivo 102 de cliente.
El servidor 100 entonces puede crear un mapa de caché que se adapta al dispositivo 102 de cliente “señalando” al menos algunas de las cachés accesibles identificadas donde pueden recuperarse varios recursos de contenido. El servidor 100 puede seleccionar qué recursos de contenido incluir en el mapa de caché para el dispositivo 102 de cliente, lo cual está, de alguna manera, fuera del alcance del presente procedimiento. Ello puede llevarse a cabo de varias maneras diferentes, dependiendo de las circunstancias. Una posibilidad es incluir todos los recursos de contenido que se han almacenado en caché por el servidor 100, o una selección de recursos de contenido que se considera que son de potencial interés para el dispositivo de cliente.
Puede ocurrir que un recurso de contenido que se incluirá en el mapa de caché no esté actualmente almacenado en las cachés identificadas accesibles. En dicho caso, el servidor puede seleccionar una de las cachés accesibles y transferir dicho recurso de contenido a la caché seleccionada. Una siguiente acción 204 opcional indica, por consiguiente, una realización a modo de ejemplo donde el servidor 100 puede transferir al menos un recurso de contenido indicado en el mapa de caché a una o más cachés en el conjunto de cachés identificado. Antes de que se ejecute esta acción, el servidor puede investigar si el al menos un recurso de contenido ya se encuentra almacenado en alguna de las cachés identificadas. Si es así, el servidor puede simplemente indicar el(los) recurso(s) de contenido en el mapa de caché de manera acorde. Si no, la acción 204 debe ejecutarse también.
Una acción 206 final ilustra que el servidor 100 envía el mapa de caché al dispositivo 102 de cliente en respuesta a la solicitud de descarga recibida de la acción 200. El mapa de caché enviado indica, al menos, que un primer recurso de contenido se encuentra almacenado en una primera caché del conjunto de cachés identificado y un segundo recurso de contenido se encuentra almacenado en una segunda caché del conjunto de cachés identificado. De hecho, es posible que el mapa de caché pueda indicar que cualquier cantidad de recursos de contenido se encuentra almacenada en la primera y segunda cachés, y la solución no se encuentra limitada en este aspecto. Además, el mapa de caché puede indicar cualquier cantidad de cachés accesibles donde se almacenan recursos de contenido de potencial interés, y la solución tampoco se encuentra limitada en este aspecto.
Varias realizaciones adicionales no restrictivas son posibles de emplear en el procedimiento descrito más arriba y ahora se describirán algunos ejemplos de realizaciones. En una realización a modo de ejemplo, la primera y segunda cachés pueden explorarse para verificar si el primero y segundo recursos de contenido, respectivamente, se encuentran almacenados allí antes de enviar el mapa de caché al dispositivo 102 de cliente. Por ejemplo, el servidor 100 puede necesitar confirmación de que el primero y segundo recursos de contenido aún están almacenados en las respectivas cachés para garantizar que el mapa de caché es relevante y útil al dispositivo de cliente.
El mapa de caché indica que al menos un recurso de contenido se almacena en al menos dos cachés del conjunto de cachés identificado y, de esta manera, se permite que el dispositivo 102 de cliente seleccione una de las al menos dos cachés y recupere el al menos un recurso de contenido de la caché seleccionada. El mapa de caché comprende uno o más criterios de selección que controlan cuál de las al menos dos cachés debe seleccionarse por el dispositivo de cliente. Los criterios de selección pueden configurarse por el servidor 100, p. ej., dependiendo de la situación o capacidad de carga actual en las cachés y/o en la red 104. De esta manera, el servidor puede controlar la distribución de la carga a lo largo de las cachés configurando los criterios de selección, p. ej., para evitar la sobrecarga en una caché haciendo que el dispositivo de cliente recupere uno o más recursos de contenido de otra caché que esté menos cargada o incluso “infrautilizada”. Los criterios de selección también pueden estar relacionados con la ubicación o proximidad de las cachés con respecto al dispositivo 102 de cliente.
Ahora se describirán algunas realizaciones adicionales a modo de ejemplo de cómo pueden usarse los criterios de selección. En una realización adicional a modo de ejemplo, los criterios de selección pueden indicar que una de las al menos dos cachés debe seleccionarse para recuperar el al menos un recurso de contenido si se cumple una condición predefinida. En realizaciones adicionales a modo de ejemplo, la condición predefinida de más arriba puede referirse a cualquiera de los siguientes factores A-F:
A) Hora del día o semana. Esta condición predefinida puede configurarse dependiendo de la carga normal o esperada en las cachés en diferentes horarios para evitar cualquier sobrecarga. Por ejemplo, la condición predefinida puede establecer que una caché debe seleccionarse durante horas laborables, y que otra caché debe seleccionarse fuera de las horas laborables.
B) Posición actual del dispositivo de cliente. Esta condición predefinida puede configurarse dependiendo de la proximidad actual del dispositivo con respeto a la caché respectiva básicamente en relación con la distancia de transporte y/o el tiempo que lleva recuperar el recurso de contenido. Por ejemplo, la condición predefinida puede establecer que una caché debe seleccionarse cuando el dispositivo de cliente se ubica en un área, y que otra caché debe seleccionarse cuando el dispositivo de cliente se ubica en otra área. En otro ejemplo, la condición predefinida puede depender de la posición geográfica del dispositivo de cliente y de la caché, respectivamente, como, por ejemplo, si se encuentran dentro del mismo país o no, con el fin de tener en cuenta normativas nacionales u obstáculos de itinerancia.
C) Estado actual de la batería en el dispositivo de cliente. Esta condición predefinida puede configurarse dependiendo de cuánta potencia queda en la batería. Por ejemplo, la condición predefinida puede establecer que el dispositivo de cliente debe abstenerse de recuperar el recurso de contenido cuando el nivel de batería se encuentra por debajo del umbral.
D) Espacio de memoria disponible en el dispositivo de cliente. Esta condición predefinida puede configurarse dependiendo de si hay suficiente espacio en la memoria para almacenar el recurso de contenido. Por ejemplo, la condición predefinida puede establecer que una caché debe seleccionarse cuando el espacio de la memoria se encuentra por encima de cierto umbral, y que otra caché donde se almacena el recurso de contenido con menos bits de información debe seleccionarse cuando el espacio de la memoria se encuentra por debajo de dicho umbral. La condición predefinida puede también establecer que el dispositivo de contenido debe abstenerse de recuperar el recurso de contenido cuando el espacio de la memoria se encuentra por debajo del umbral.
E) Caudal de red actual. Esta condición predefinida puede configurarse dependiendo del diferente caudal en diferentes partes de la red utilizada para la descarga como, por ejemplo, la red 104 de comunicación en la Figura 1. Por ejemplo, la condición predefinida puede establecer que una caché debe seleccionarse cuando el caudal en la parte de red usada para acceder a dicha caché es mayor que el caudal en la parte de red utilizada para acceder a otra caché.
F) Coste de recuperación. El uso del almacenamiento en caché puede asociarse a un coste que puede diferir entre cachés. Al incluir el coste en el mapa de caché, el cliente puede seleccionar la caché apropiada dependiendo de la situación actual. Por ejemplo, puede ser preferible seleccionar una caché de coste relativamente bajo, pero con mal rendimiento, si el coste se considera más importante o crucial que el rendimiento.
En otra realización a modo de ejemplo, el criterio de selección puede, como una alternativa al uso de una condición predefinida, indicar que una de las al menos dos cachés debe intentarse primero para recuperar el al menos un recurso de contenido. La presente realización puede emplearse en caso de que sea deseable que dicha caché “preferida” deba usarse principalmente, si fuera posible. Si la recuperación falla, el dispositivo de cliente puede intentar recuperar el recurso de contenido de otra caché indicada en el mapa de caché. En otra realización a modo de ejemplo, el criterio de selección puede comprender prioridades de las al menos dos cachés para indicar un orden de intentos de recuperar el al menos un recurso de contenido. Por ejemplo, si un recurso de contenido se almacena en tres cachés C1, C2, C3, el criterio de selección puede indicar prioridades descendentes para C1-C3 y, de esta manera, indicar que el dispositivo de cliente debe intentar la recuperación del recurso de contenido en dicho orden.
En otra realización a modo de ejemplo, el criterio de selección puede configurarse dependiendo de la carga actual en las al menos dos cachés. Esta realización puede, por consiguiente, usarse como otro medio para distribuir la carga a lo largo de las cachés, p. ej., como una alternativa más dinámica y sensible a la carga con respecto a la condición predefinida descrita más arriba del factor A) que es fija para diferentes horas del día o semana según la carga esperada.
Los recursos de contenido pueden almacenarse en las cachés en forma encriptada y pueden usarse diferentes claves de encriptación en diferentes cachés, p. ej., para proveer protección frente a la descarga no autorizada. En otra realización a modo de ejemplo, el mapa de caché puede, en el presente caso, comprender una primera clave de encriptación útil para desencriptar el al menos un recurso de contenido cuando se recupera de una primera caché de las al menos dos cachés, y además comprender una segunda clave de encriptación útil para desencriptar el al menos un recurso de contenido cuando se recupera de una segunda caché de las al menos dos cachés. Aunque solo una primera clave y una segunda clave se describen en la realización de más arriba, puede comprenderse que es posible utilizar cualquier cantidad de claves de encriptación para protección de los recursos de contenido en cualquier cantidad de cachés. La misma clave de encriptación puede también usarse en más de una caché.
En otra realización a modo de ejemplo, la primera clave de encriptación puede indicarse por metadatos en una entrada para la primera caché en el mapa de caché, y la segunda clave de encriptación puede indicarse por metadatos en una entrada para la segunda caché en el mapa de caché. Un ejemplo de la presente realización se describirá más adelante más abajo con referencia a la Figura 6.
Ahora se describirá otro ejemplo, con referencia al diagrama de flujo de la Figura 3, de cómo puede emplearse la solución en términos de acciones que pueden llevarse a cabo en un dispositivo de cliente como, por ejemplo, el dispositivo 102 de cliente descrito más arriba, para gestionar recursos de contenido en caché. A veces, también se hará referencia, sin limitar las características descritas, al ejemplo que se muestra en la Figura 1. El procedimiento ilustrado en la Figura 3 puede, por consiguiente, usarse para lograr la funcionalidad descrita más arriba para el dispositivo 102 de cliente en comunicación con el servidor 100.
Una primera acción 300 opcional ilustra que el dispositivo 102 de cliente puede enviar una solicitud de descarga al servidor 100 en una sesión de descarga, por consiguiente, correspondiente a la acción 200 en la Figura 2. En una siguiente acción 302, el dispositivo 102 de cliente recibe un mapa de caché del servidor 100 durante una sesión de descarga, el mapa de caché indicando que el al menos un recurso de contenido se almacena en al menos dos cachés.
En algún momento posterior, se descubre que el dispositivo 102 de cliente necesita recuperar el al menos un recurso de contenido indicado en el mapa de caché, p. ej., cuando un usuario selecciona un enlace o similar, o cuando una aplicación en el dispositivo requiere el(los) recurso(s) de contenido para su funcionamiento. En una siguiente acción 304, el dispositivo 102 de cliente selecciona una de las al menos dos cachés que se han indicado en el mapa de caché recibido, p. ej., según la condición de selección descrita más arriba. Algunos ejemplos de cómo puede llevarse a cabo esta selección se describirán más adelante más abajo con referencia a realizaciones adicionales a modo de ejemplo. Una acción 306 final ilustra que el dispositivo 102 de cliente recupera el al menos un recurso de contenido de la caché seleccionada. La recuperación como tal de un recurso de contenido puede llevarse a cabo en una manera convencional que no es necesario describir en la presente memoria.
El mapa de caché comprende un criterio de selección que controla cuál de las al menos dos cachés debe seleccionarse, y dicha selección de caché puede, en dicho caso, llevarse a cabo según los criterios de selección. Más arriba se ha descrito cómo dicho criterio de selección puede emplearse por el servidor. Sin embargo, algunas realizaciones a modo de ejemplo del criterio de selección se describen brevemente de la siguiente manera.
En otra realización a modo de ejemplo, el criterio de selección puede indicar que una de las al menos dos cachés debe seleccionarse para recuperar el al menos un recurso de contenido si se cumple una condición predefinida. En otra realización a modo de ejemplo, la condición predefinida se refiere a cualquiera de: hora del día o semana, posición actual del dispositivo de cliente, estado actual de la batería en el dispositivo de cliente, espacio de memoria disponible en el dispositivo de cliente, caudal de red actual y coste de recuperación. Dichos factores se han descrito en mayor detalle más arriba y, por consiguiente, no se repetirán aquí.
En otra realización a modo de ejemplo, los criterios de selección pueden, en lugar de usar la condición predefinida de más arriba, indicar que una de las al menos dos cachés debe intentarse primero para recuperar el al menos un recurso de contenido. En dicho caso, en otra realización a modo de ejemplo, puede ser que el criterio de selección comprenda prioridades de las al menos dos cachés para indicar un orden de intentos de recuperar el al menos un recurso de contenido.
En algunas realizaciones adicionales a modo de ejemplo, traer previamente el al menos un recurso de contenido de la caché puede ejecutarse por medio de un agente de caché en el dispositivo de cliente. Las Figuras 4A-4C ilustran algunos ejemplos de cómo dicho agente de caché puede implementarse en el dispositivo 400 de cliente. El agente 402 de caché se denota "agente BC" en dichos ejemplos, donde BC deriva de Caché Ciega, BC, por sus siglas en inglés. El agente 402 de caché puede implementarse en cualquiera de:
- una aplicación 400A de cliente que se ejecuta en el dispositivo de cliente, como se muestra en la Figura 4A,
- una secuencia de comandos de un ServiceWorker 400B, como se muestra en la Figura 4B, y
- un protocolo de transferencia de hipertexto, HTTP, Library 400C, como se muestra en la Figura 4C.
En otra realización a modo de ejemplo, el mapa de caché puede comprender una primera clave de encriptación útil para desencriptar el al menos un recurso de contenido cuando se recupera de una primera caché de las cachés, y una segunda clave de encriptación útil para desencriptar el al menos un recurso de contenido cuando se recupera de una segunda caché de las cachés. En otra realización a modo de ejemplo, la primera clave de encriptación puede indicarse por metadatos en una entrada para la primera caché en el mapa de caché, y la segunda clave de encriptación se indica por metadatos en una entrada para la segunda caché en el mapa de caché.
En otra realización a modo de ejemplo, el mapa de caché puede recibirse en respuesta a una solicitud enviada al servidor en la sesión de descarga. La presente realización se ilustra por la acción 300 en la Figura 3.
Otro ejemplo ilustrativo, pero no restrictivo, de cómo pueden funcionar un servidor y un dispositivo de cliente en mayor detalle y cuándo se usan al menos algunas de las realizaciones descritas más arriba, se describirá ahora con referencia al diagrama de señalización de la Figura 5. En la presente figura, se muestran un servidor 500, un dispositivo 502 de cliente y un conjunto de cachés 504, 506 accesibles. Por consiguiente, se supone que las cachés 504, 506 que se muestran representan un conjunto de cachés a las que puede acceder el dispositivo 502 de cliente que puede consistir en cualquier cantidad de cachés, aunque solo dos se describen aquí en aras de la simplicidad.
Las primeras acciones 5:1A y 5:1B que se muestran ilustran que el servidor 500 almacena en caché varios recursos de contenido en las cachés 504, 506, respectivamente, las cuales corresponden a la acción 1:1 descrita más arriba. El recurso de contenido se denota RC en la figura. En una siguiente acción 5:2, el dispositivo 502 de cliente recibe cierta entrada de un usuario que acciona una sesión de descarga que comienza con el envío por parte del dispositivo 502 de cliente de una solicitud de descarga al servidor 500, en una acción 5:3, que corresponde a las acciones 1:2, 200 y 300 descritas más arriba. La entrada en la acción 5:2 puede, de manera alternativa, provenir de cierta aplicación que se está ejecutando en el dispositivo 502.
En una siguiente acción 5:4, el servidor 500 identifica el conjunto de cachés 504, 506 a las que puede acceder el dispositivo 502 de cliente. La presente acción corresponde a la acción 202 descrita más arriba. Aquí, debe comprenderse que el servidor 500 puede identificar cualquier cantidad de cachés accesibles y la solución no se encuentra limitada en este aspecto. Algunos ejemplos de cómo esta acción puede llevarse a cabo se han descrito más arriba. Más arriba se ha descrito que un recurso de contenido que se incluirá en el mapa de caché puede no estar actualmente almacenado en las cachés 504, 506 accesibles identificadas. El servidor 500 puede, en dicho caso, seleccionar una de las cachés accesibles y transferir el recurso de contenido a la caché 504 seleccionada, en otra acción 5:4A. Después de la acción 5:4, el servidor 500 puede, por consiguiente, verificar si el recurso de contenido que se incluirá ya se encuentra almacenado en alguna de las cachés 504, 506 accesibles identificadas y, si no se encuentra caché alguna, se lleva a cabo la acción 5:4A.
En una siguiente acción 5:5, el servidor 500 puede, de manera opcional, establecer el criterio de selección y su inclusión en el mapa de caché. También se ha descrito más arriba cómo puede definirse dicho criterio de selección dependiendo de varios factores y circunstancias que no se repetirán aquí. El servidor 500 entonces envía una respuesta con el mapa de caché al dispositivo 502 de cliente, en una acción 5:6, que corresponde a las acciones 1:3, 206 y 302 descritas más arriba. En el presente ejemplo, la respuesta también incluye el criterio de selección establecido en la acción 5:5.
En algún momento más adelante, el dispositivo 502 de cliente recibe cierta entrada de un usuario, en una acción 5:7, que indica que un recurso de contenido necesita presentarse o usarse, p. ej., realizarse, en el dispositivo 502 de cliente. El dispositivo 502 de cliente entonces verifica el mapa de caché previamente recibido y descubre que el recurso de contenido que se necesita está disponible tanto en la caché 504 como en la caché 506. Una acción 5:8 adicional ilustra que el dispositivo 502 de cliente selecciona la caché 504 según el criterio de selección previamente recibido, y recupera el recurso de contenido que se necesita de la caché 504 seleccionada, en otra acción 5:9. Una vez que el recurso de contenido se haya recuperado, puede presentarse o de otra manera usarse en el dispositivo 502 de cliente, como se muestra en una acción 5:10 final. Debe observarse que la acción 5:7, y las posteriores acciones 5:8 - 5:10, pueden llevarse a cabo sin entrada de usuario específica. La primera respuesta de servidor a la cual se fija el mapa de caché puede ser una página html, y a medida que el dispositivo 502 de cliente analiza la página, pueden recuperarse recursos de contenido adicionales.
Se ha descrito más arriba que el mapa de caché puede configurarse de diferentes maneras para llevar a cabo la solución y las realizaciones descritas en la presente memoria, y que las claves de encriptación pueden indicarse por metadatos en el mapa de caché. Un ejemplo de dos entradas de mapa de caché que indican que el mismo recurso de contenido se almacena en dos cachés accesibles diferentes se ilustra, de forma esquemática, en la Figura 6. Una primera entrada 600 de mapa de caché comprende una identificación del recurso de contenido en cuestión en 600A, denotada "ID de Recurso ID X", y una identificación de una primera caché en 600B donde se encuentra disponible el recurso de contenido, denotada "ID de caché A". La otra entrada 602 de mapa de caché comprende la misma identificación "ID de Recurso X" del recurso de contenido en 602A, y una identificación de una segunda caché en 602B donde el recurso de contenido también se encuentra disponible, denotada "ID de caché B". Ambas entradas 600, 602 también contienen información sobre de qué tipo de contenido es el recurso, en 600C y 602C, respectivamente.
La entrada 600 del mapa de caché además comprende metadatos en 600D que incluyen el criterio/los criterios de selección descritos más arriba denotados "Criterios de selección A", y metadatos adicionales en 600E que incluyen información de encriptación como, por ejemplo, una clave de encriptación denotada "Clave de encriptación A", en caso de que el recurso de contenido esté encriptado en la primera caché A y necesite desencriptarse por el dispositivo de cliente. De la misma manera, la entrada 602 del mapa de caché comprende metadatos en 602D que incluyen un criterio/criterios de selección denotados "Criterios de selección B", que pueden ser diferentes de los Criterios de selección A, y metadatos adicionales en 602E que incluyen una clave de encriptación denotada "Clave de encriptación B", que puede ser diferente de la Clave de encriptación A o no. Un ejemplo de cómo las entradas de mapa de caché pueden configurarse en la práctica para tres recursos de contenido diferentes distribuidos a lo largo de tres cachés se presenta más abajo.
I
" r e s o u r c e - o r i g i n " : " h t L p s : / / o r i g i n . c o m
/ i m a g e / d o g . j p g " ,
" r e s o u r c e - m a p p e d " : " h t t p s : / / o r i g i n . c o m / a b e / 001 " ,
" c o n t e n t - t y p e " : " i m a g e / j p e g " ,
" m a p p e d - h o s t " : " b e l . c o m "
} .
" r e s o u r c e - o r i g i n " : " h t t p s : / / o r i g i n . com
/ i m a g e / c a r . j p g " ,
" r e s o u r c e - m a p p e d " : " h t t p s : / / o r i g i n - c o m / e f g / 007 " ,
" c o n t e n t - t y p e " : " i m a g e / j p e g " ,
" m a p p e d - h o s t " : " b c 2. c o m " ,
" e n c r y p t i o n " : {
" k e y " : " s o m e - s e c r e t - k e y " ,
" s a l t " : " so m e s a l t "
} ,
" r e s o u r c e - o r i g i n " : " h t t p s : / / o r i g i n . com
/ i m a g e / c a t . j p g " ,
" r e s o u r c e - m a p p e d " : " h t t p s : / / o r í g i n . c o m / a b e / 003 " ,
" c o n t e n t - t y p e " : " i m a g e / j p e g " ,
" m a p p e d - h o s t " : " b c 3. c o m "
}
El ejemplo de más arriba, por consiguiente, muestra tres entradas de mapa de caché para tres recursos de contenido respectivos que incluyen imágenes de un perro, un coche y un gato, que se almacenan en tres cachés diferentes denotadas bc1, bc2 y bc3, respectivamente. En el presente ejemplo, la encriptación se emplea solo para car.jpg en la caché bc2 mediante el uso de una clave de encriptación esquemáticamente denotada "some-secret-key".
Otro ejemplo de cómo pueden configurarse entradas del mapa de caché en la práctica para un recurso de contenido, la imagen del coche, almacenadas en dos cachés bc1 y bc2, se presenta más abajo.
{
"resource-origin": "https://origin.com
/image/car.jpg",
"resource-mapped": "https://origin.com/abe/002",
"content-type": "image/jpeg",
"mapped-host": "bcl.com",
" e n c r y p t i o n " : {
" k e y " : " s o m e - s e c r e t - k e y " ,
" s a l t " : " s o m e s a l t "
> ,
} ,
{
" r e s o u r c e - o r i g i n " : " h t t p s : / / o r i g i n . c o m
/ i m a g e / c a r . j p g” ,
" r e s o u r c e —m a p p e d " h t t p s : / / o r i g i n . c o m / y a y / 88 a j 93 í " , " c o n t e n t - t y p e ” : " i m a g e / j p e g " ,
" m a p p e d - h o s t " : " b c 2. com" ,
" e n c r y p t i o n " : {
" k e y " : " s o m e - s e c r e t - k e y " ,
" s a l t " : " so m e s a l t "
>
En el presente ejemplo, la encriptación se emplea en ambas cachés bc1 y bc2 mediante el uso de una clave de encriptación esquemáticamente denotada "some-secret-key". Debe observarse que puede usarse la misma clave o diferentes claves en las cachés bc1 y bc2, como se describe más arriba.
Incluso un ejemplo de cómo pueden configurarse las dos entradas del mapa de caché de más arriba en la práctica cuando se añade el criterio/los criterios de selección, se presenta más abajo.
<sn ip>
í
" r e s o u r c e - o r i g i n " : " h t t p s : / / o r i g i n . c o m
/ i m a g e s / c a r . j p g " ,
" re sou rce -m a ppe d " : " h t t p s : / / o r i g i n . com/ab e /002",
" c o n t e n t - t y p e " : " im a g e / j p e g " ,
"mapped-host " : "bc l . c o m " ,
" e n c r y p t i o n " : {
"k ey " : " so m e - se c r e t - k e y " ,
" s a l t " : "some s a l t "
>,
" s e l e c t i o n - c r i t e r i o n " : [
{ " t im e " : "<9am" } ,
) ,
{
" r e s o u r c e - o r i g i n " : " h t t p s : / / o r i g i n . c o m
/ i m a g e s / c a r - j p g " ,
" r e s o u r c e - m a p p e d " : " h t t p s : / / o r i g i n . c o m / a b c / 002 " ,
" c o n t e n t - t y p e " : " i m a g e / j p e g " ,
" m a p p e d - h o s t " : " b c 2.c o m " ,
" e n c r y p t i o n " : {
" k e y " : " s o m e - s e c r e t - k e y " ,
" s a l t " : "some s a l t "
>,
" s e l e c t i o n - c r i t e r i o n " : [
{ " t i m e " : ">-9am" }
1
< s n i p >
El ejemplo de más arriba, por consiguiente, muestra que la imagen del coche del recurso de contenido debe<recuperarse de la caché bc1 si la hora actual es anterior a las 9 a. m., y que debe recuperarse de la caché bc1 si la>hora actual es igual o superior a las 9 a. m.
Un ejemplo no restrictivo de cómo pueden estructurarse un servidor y un dispositivo de cliente para provocar la solución descrita más arriba y sus realizaciones, se describirá ahora con referencia al diagrama de bloques de la Figura 7. En la presente figura, el servidor 700 y el dispositivo 702 de cliente pueden configurarse para funcionar según cualquiera de los ejemplos y realizaciones de empleo de la solución según se describe más arriba, cuando corresponda, y de la siguiente manera. Cada uno del servidor 700 y dispositivo 702 de cliente se muestra como uno que comprende un respectivo procesador 700P, 702P, una respectiva memoria 700M, 702M y un circuito de comunicación denotado "C" con equipo adecuado para transmitir y recibir información y mensajes en la manera descrita en la presente memoria.
El circuito de comunicación C en cada uno del servidor 700 y dispositivo 702 de cliente comprende, por consiguiente, equipo configurado para la comunicación mediante el uso de un protocolo adecuado dependiendo de la implementación. Más arriba se ha descrito que HTTP puede usarse en la comunicación. La solución, sin embargo, no se encuentra limitada a tipos específicos de mensajes o protocolos. Ejemplos de cómo puede llevarse a cabo la comunicación se han descrito más arriba con referencia a las Figuras 1 y 5.
Las acciones de las Figuras 2 y 3 pueden llevarse a cabo por medio de unidades funcionales en los respectivos procesadores 700P, 702P en el servidor 700 y el dispositivo 702 de cliente. Por ejemplo, el servidor 700 puede comprender medios configurados o dispuestos para llevar a cabo al menos algunas de las acciones del diagrama de flujo de la Figura 2 en la manera descrita más arriba. Además, el dispositivo 702 de cliente puede comprender medios configurados o dispuestos para llevar a cabo al menos algunas de las acciones del diagrama de flujo en la Figura 3 en la manera descrita más arriba.
El servidor 700 se dispone para gestionar recursos de contenido en caché. El servidor 700, por consiguiente, comprende el procesador 700P y la memoria 700M, dicha memoria 700M comprendiendo instrucciones ejecutables por dicho procesador 700P, por medio de lo cual el servidor 700 se configura de la siguiente manera.
El servidor 700 se configura para recibir una solicitud de descarga de un dispositivo 702 de cliente en una sesión de descarga. La presente operación de recepción puede llevarse a cabo por una unidad 700A de recepción en el servidor 700, p. ej., en la manera descrita para la acción 200 de más arriba. El servidor 700 también se configura para identificar un conjunto de cachés al que puede acceder el dispositivo 702 de cliente. Esta función de identificación puede llevarse a cabo por una unidad 700B de identificación en el servidor 700, p. ej., en la manera descrita para la acción 202 de más arriba.
El servidor 700 se configura además para enviar un mapa de caché al dispositivo 702 de cliente en respuesta a la solicitud recibida, el mapa de caché indicando que un primer recurso de contenido se almacena en una primera caché del conjunto de cachés identificado y un segundo recurso de contenido se almacena en una segunda caché del conjunto de cachés identificado. Esta función de envío puede llevarse a cabo por una unidad 700C de envío en el servidor 700, p. ej., en la manera descrita para la acción 206 de más arriba.
El dispositivo 702 de cliente se dispone para gestionar recursos de contenido en caché. El dispositivo 702 de cliente, por consiguiente, comprende el procesador 702P y la memoria 702M, dicha memoria comprendiendo instrucciones ejecutables por dicho procesador, por medio de lo cual el dispositivo 702 de cliente es utilizable de la siguiente manera.
El dispositivo 702 de cliente puede configurarse para enviar una solicitud de descarga al servidor 700 en una sesión de descarga. Esta función de envío puede llevarse a cabo por una unidad 702A de envío en el dispositivo 702 de cliente, p. ej., en la manera descrita para la acción 300 de más arriba. El dispositivo 702 de cliente se configura para recibir un mapa de caché del servidor 700 durante una sesión de descarga, el mapa de caché indicando que al menos un recurso de contenido se almacena en al menos dos cachés. Esta función de recepción puede llevarse a cabo por una unidad 702B de recepción en el dispositivo 702 de cliente, p. ej., en la manera descrita para la acción 302 de más arriba.
El dispositivo 702 de cliente también se configura para seleccionar una de las al menos dos cachés. La función de selección puede llevarse a cabo por una unidad 702C de selección en el dispositivo 702 de cliente, p. ej., en la manera descrita para la acción 304 de más arriba. El dispositivo 702 de cliente también se configura para recuperar el al menos un recurso de contenido de la caché seleccionada. La función de recuperación puede llevarse a cabo por una unidad 702D de recuperación en el dispositivo 702 de cliente, p. ej., en la manera descrita para la acción 306 de más arriba.
Debe observarse que la Figura 7 ilustra varias unidades funcionales en el servidor 700 y dispositivo 702 de cliente, respectivamente, y la persona con experiencia en la técnica puede implementar dichas unidades funcionales en la práctica usando software y hardware adecuados. Por consiguiente, la solución no está, en general, limitada a las estructuras que se muestran del servidor 700 y dispositivo 702 de cliente, y las unidades 700A-C y 702A-D funcionales allí pueden configurarse para funcionar según cualquiera de las características y realizaciones descritas en la presente descripción, cuando corresponda.
Las unidades 700A-C y 702A-D funcionales descritas más arriba pueden implementarse en el respectivo servidor 700 y dispositivo 702 de cliente por medio de un respectivo programa 704 y 708 de ordenador que comprende medios de código que, cuando se ejecutan por el procesador 700P, 702P hacen que el respectivo servidor 700 y dispositivo 702 de cliente lleven a cabo las acciones y los procedimientos descritos más arriba. Cada procesador 700P, 702P puede comprender una sola unidad central de procesamiento (CPU, por sus siglas en inglés), o puede comprender dos o más unidades de procesamiento. Por ejemplo, cada procesador 700P, 702P puede incluir un microprocesador de propósito general, un procesador de conjunto de instrucciones y/o conjuntos de chips relacionados y/o un microprocesador de propósito especial como, por ejemplo, un circuito integrado para aplicaciones específicas (ASIC, por sus siglas en inglés). En otras palabras, las unidades funcionales descritas pueden implementarse en hardware puro. Cada procesador P puede también comprender un almacenamiento con fines de almacenamiento en caché.
Cada programa 704, 708 de ordenador puede llevarse por un producto 706 y 710 de almacenamiento de programa de ordenador, respectivamente, en cada uno del servidor 700 y dispositivo 702 de cliente en la forma de una memoria que tiene un medio legible por ordenador y que puede conectarse al respectivo procesador 700P, 702P. El producto 706, 710 de almacenamiento de programa de ordenador en cada uno del servidor 700 y dispositivo 702 de cliente puede, por consiguiente, comprender un medio legible por ordenador en el cual se almacena el respectivo programa 704, 708 de ordenador, p. ej., en la forma de módulos de programas de ordenador o similares. Por ejemplo, la memoria 700M, 702M en cada nodo puede ser una memoria flash, una memoria de acceso aleatorio (RAM, por sus siglas en inglés), una memoria de solo lectura (ROM, por sus siglas en inglés) o una ROM programable eléctricamente borrable (EEPROM, por sus siglas en inglés), y los módulos de programas pueden, en realizaciones alternativas, distribuirse en diferentes productos de almacenamiento de programas de ordenador en la forma de memorias dentro del respectivo servidor 700 y dispositivo 702 de cliente.
La solución descrita en la presente memoria puede, por consiguiente, implementarse en cada uno del servidor 700 y dispositivo 702 de cliente por un programa 704, 708 de ordenador que comprende instrucciones que, cuando se ejecutan en el servidor 700 y dispositivo 702 de cliente, hacen que el servidor 700 y dispositivo 702 de cliente lleven a cabo las acciones según las respectivas realizaciones de más arriba, cuando fuera apropiado. La solución puede también implementarse en cada uno del servidor 700 y dispositivo 702 de cliente en un producto 706, 710 de almacenamiento de programas de ordenador que comprende instrucciones que, cuando se ejecutan en el servidor 700 y dispositivo 702 de cliente, hacen que el servidor 700 y dispositivo 702 de cliente llevan a cabo las acciones según las respectivas realizaciones de más arriba, cuando fuera apropiado.
Aunque la solución se ha descrito con referencia a realizaciones específicas a modo de ejemplo, la descripción solo pretende, en general, ilustrar el concepto inventivo y no debe tomarse como restrictiva del alcance de la solución. Por ejemplo, los términos “servidor”, “dispositivo de cliente”, “recurso de contenido”, “caché”, "mapa de caché", "criterio de selección", "criterios de selección", "condición predefinida" y "metadatos" se han usado a lo largo de la presente descripción, aunque puede también usarse cualquier otra entidad, función y/o parámetro correspondiente que tenga los aspectos y las características aquí descritas. El alcance de la invención se define por las reivindicaciones anexas.

Claims (13)

REIVINDICACIONES
1. Un método llevado a cabo por un servidor (500) para gestionar recursos de contenido en caché, el método comprendiendo:
- recibir (200, 5:3) una solicitud HTTP GET que comprende una solicitud de un recurso de contenido de un dispositivo (502) de cliente en una sesión de descarga,
- identificar (202, 5:4) un conjunto de cachés (504, 506) al que puede acceder el dispositivo (502) de cliente, dicha identificación llevándose a cabo por el servidor según una indicación en la solicitud HTTP GET que indica a cuáles cachés puede acceder el cliente o el servidor que accede a información sobre la capacidad del dispositivo de cliente mantenido por el servidor o por una red de acceso usada por el dispositivo de cliente, y
- enviar (206, 5:6) un mapa de caché al dispositivo (502) de cliente en una respuesta 200 OK a la solicitud HTTP GET recibida, el mapa de caché indicando que un primer recurso de contenido de potencial interés para la posterior recuperación por el dispositivo de cliente se almacena en una primera caché del conjunto de cachés identificado y un segundo recurso de contenido de potencial interés para la posterior recuperación por el dispositivo de cliente se almacena en una segunda caché del conjunto de cachés identificado y que al menos un recurso de contenido de potencial interés para la posterior recuperación por el dispositivo de cliente se almacena en al menos dos cachés (504, 506) del conjunto de cachés identificado, y el mapa de caché comprendiendo al menos un criterio de selección que controla cuál de las al menos dos cachés (504, 506) debe seleccionarse para el al menos un recurso de contenido y, de esta manera, permitir que el dispositivo (502, 702) de cliente seleccione una de las al menos dos cachés (504, 506) según el criterio de selección y recupere el al menos un recurso de contenido de la caché (504) seleccionada.
2. Un servidor (500, 700) dispuesto para gestionar recursos de contenido en caché, el servidor (500, 700) comprendiendo un procesador (700P) y una memoria (700M) que contiene instrucciones ejecutables por el procesador, por medio de lo cual el servidor (700) se configura para:
- recibir (700A) una solicitud HTTP GET que comprende una solicitud de un recurso de contenido de un dispositivo (502, 702) de cliente en una sesión de descarga,
- identificar (700B) un conjunto de cachés (504, 506) al que puede acceder el dispositivo (502, 702) de cliente, dicha identificación llevándose a cabo por el servidor según una indicación en la solicitud HTTP GET que indica a cuáles cachés puede acceder el cliente o el servidor que accede a información sobre la capacidad del dispositivo de cliente mantenido por el servidor o por una red de acceso usada por el dispositivo de cliente; y
- enviar (700C) un mapa de caché al dispositivo (502, 702) de cliente en una respuesta 200 OK a la solicitud HTTP GET recibida, el mapa de caché indicando que un primer recurso de contenido de potencial interés para la recuperación posterior por el dispositivo de cliente se almacena en una primera caché del conjunto de cachés identificado y un segundo recurso de contenido de potencial interés para la posterior recuperación por el dispositivo de cliente se almacena en una segunda caché del conjunto de cachés identificado y que al menos un recurso de contenido de potencial interés para la recuperación posterior por el dispositivo de cliente se almacena en al menos dos cachés (504, 506) del conjunto de cachés identificado, y el mapa de caché comprende al menos un criterio de selección que controla cuál de las al menos dos cachés (504, 506) debe seleccionarse para el al menos un recurso de contenido y, de esta manera, permitir que el dispositivo (502, 702) de cliente seleccione una de las al menos dos cachés (504, 506) según el criterio de selección y recupere el al menos un recurso de contenido de la caché (504) seleccionada.
3. Un servidor (500, 700) según la reivindicación 2, en donde el servidor (500, 700) se configura para transferir al menos un recurso de contenido indicado en el mapa de caché (204, 5:4A) a una caché en el conjunto de cachés (504, 506) identificado.
4. Un servidor (500, 700) según la reivindicación 2, en donde el criterio (600D, 602D) de selección indica que una de las al menos dos cachés (504, 506) debe seleccionarse para recuperar el al menos un recurso de contenido si se cumple una condición predefinida.
5. Un servidor (500, 700) según la reivindicación 4, en donde la condición predefinida se refiere a cualquiera de: hora del día o semana, posición actual del dispositivo (502, 702) de cliente, estado actual de la batería en el dispositivo (502, 702) de cliente, espacio de memoria disponible en el dispositivo (502, 702) de cliente, caudal de red actual y coste de recuperación.
6. Un servidor (500, 700) según la reivindicación 2, en donde el criterio (600D, 602D) de selección indica que una de las al menos dos cachés (504, 506) debe intentarse primero para recuperar el al menos un recurso de contenido.
7. Un método llevado a cabo por un dispositivo (502) de cliente para gestionar recursos de contenido en caché, el método comprendiendo:
- enviar una solicitud HTTP GET que comprende una solicitud de recurso de contenido a un servidor (500, 700) en una sesión de descarga,
- recibir (302, 5:6) un mapa de caché en una respuesta 200 OK del servidor (500) durante la sesión de descarga, el mapa de caché indicando que
al menos un recurso de contenido se almacena en al menos dos cachés (504, 506) identificadas por el servidor como accesibles por el dispositivo de cliente según una indicación en la solicitud HTTP GET sobre a cuáles cachés puede acceder el cliente, o
por el servidor que accede a información sobre la capacidad del dispositivo de cliente mantenido por el servidor o por una red de acceso usada por el dispositivo de cliente, y
el mapa de caché comprende al menos un criterio de selección que controla cuál de las al menos dos cachés (504, 506) debe seleccionarse,
- seleccionar (304, 5:8) una de las al menos dos cachés (504, 506) según el criterio de selección, y
- recuperar (306, 5:9) el al menos un recurso de contenido de la caché (504) seleccionada.
8. Un dispositivo (502, 702) de cliente dispuesto para gestionar recursos de contenido en caché, el dispositivo (502, 702) de cliente comprendiendo un procesador (702P) y una memoria (702M) que contiene instrucciones ejecutables por el procesador, por medio de lo cual el dispositivo (502, 702) de cliente se configura para:
- enviar una solicitud HTTP GET que comprende una solicitud de un recurso de contenido a un servidor (500, 700) en una sesión de descarga,
- recibir (702B) un mapa de caché en una respuesta 200 OK del servidor (500, 700) durante la sesión de descarga, el mapa de caché indicando que al menos un recurso de contenido se almacena en al menos dos cachés (504, 506) identificadas por el servidor como accesibles por el dispositivo de cliente según una indicación en la solicitud HTTP GET de a cuáles cachés puede acceder el cliente, o
por el servidor que accede a información sobre la capacidad del dispositivo de cliente mantenido por el servidor o por una red de acceso usada por el dispositivo de cliente, y
el mapa de caché comprende al menos un criterio de selección que controla cuál de las al menos dos cachés (504, 506) debe seleccionarse,
- seleccionar (702C) una de las al menos dos cachés (504, 506) según el criterio de selección, y
- recuperar (702D) el al menos un recurso de contenido de la caché (504) seleccionada.
9. Un dispositivo (502, 702) de cliente según la reivindicación 8, en donde el criterio de selección indica que una de las al menos dos cachés (504, 506) debe seleccionarse para recuperar el al menos un recurso de contenido si se cumple una condición predefinida.
10. Un dispositivo (502, 702) de cliente según la reivindicación 9, en donde la condición predefinida se refiere a cualquiera de: hora del día o semana, posición actual del dispositivo (502, 702) de cliente, estado actual de la batería en el dispositivo (502, 702) de cliente, espacio de memoria disponible en el dispositivo (502, 702) de cliente, caudal de red actual y coste de recuperación.
11. Un dispositivo (502, 702) de cliente según la reivindicación 8, en donde el criterio de selección indica que una de las al menos dos cachés (504, 506) debe intentarse primero para recuperar el al menos un recurso de contenido.
12. Un programa (704) de ordenador que comprende instrucciones que, cuando se ejecutan en un servidor (700), hacen que el servidor (700) lleve a cabo el método según la reivindicación 1.
13. Un programa (708) de ordenador que comprende instrucciones que, cuando se ejecutan en un dispositivo (702) de cliente, hacen que el dispositivo (702) de cliente lleve a cabo el método según la reivindicación 7.
ES16900654T 2016-04-28 2016-04-28 Gestión de recursos de contenido en caché Active ES2970866T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2016/050376 WO2017188871A1 (en) 2016-04-28 2016-04-28 Server, client device and methods therein for handling cached content resources

Publications (1)

Publication Number Publication Date
ES2970866T3 true ES2970866T3 (es) 2024-05-31

Family

ID=60160936

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16900654T Active ES2970866T3 (es) 2016-04-28 2016-04-28 Gestión de recursos de contenido en caché

Country Status (6)

Country Link
US (1) US10298716B2 (es)
EP (2) EP3449614B1 (es)
CN (1) CN109417559B (es)
ES (1) ES2970866T3 (es)
PL (1) PL3449614T3 (es)
WO (1) WO2017188871A1 (es)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10805421B2 (en) 2018-04-03 2020-10-13 Citrix Systems, Inc. Data caching for cloud services
US11520789B2 (en) * 2019-10-21 2022-12-06 Teradata Us, Inc. Caching objects from a data store
JP7428081B2 (ja) * 2020-06-05 2024-02-06 コニカミノルタ株式会社 振り分け装置、画像処理システム及びプログラム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8245128B1 (en) * 2002-07-17 2012-08-14 Oracle International Corporation Intelligent client agent for a hybrid online/offline application
CN101039170B (zh) * 2006-03-15 2011-08-03 华为技术有限公司 支持数据包重传分割级联的方法
US8812651B1 (en) * 2007-02-15 2014-08-19 Google Inc. Systems and methods for client cache awareness
CN100478918C (zh) * 2007-10-31 2009-04-15 中国人民解放军国防科学技术大学 微处理器中分段高速缓存的设计方法及分段高速缓存
US8386629B2 (en) * 2007-12-27 2013-02-26 At&T Intellectual Property I, L.P. Network optimized content delivery for high demand non-live contents
CN101656985B (zh) * 2009-08-18 2012-12-19 中兴通讯股份有限公司 一种管理url资源缓存的方法和装置
WO2011073707A1 (en) 2009-12-14 2011-06-23 Telefonaktiebolaget L M Ericsson (Publ) Dynamic cache selection method and system
US8903955B2 (en) * 2011-12-02 2014-12-02 Cisco Technology, Inc. Systems and methods for intelligent video delivery and cache management
WO2014090761A1 (en) * 2012-12-10 2014-06-19 Koninklijke Kpn N.V. Digital rights management for segmented content
US9591093B2 (en) 2013-05-31 2017-03-07 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for cached content delivery to roaming devices
US9882984B2 (en) * 2013-08-02 2018-01-30 International Business Machines Corporation Cache migration management in a virtualized distributed computing system
US10097637B2 (en) * 2014-11-13 2018-10-09 Tenoware R&D Limited Grid distributed cache

Also Published As

Publication number Publication date
WO2017188871A1 (en) 2017-11-02
CN109417559B (zh) 2021-08-03
US20180097906A1 (en) 2018-04-05
EP3449614B1 (en) 2024-02-07
EP4340332A2 (en) 2024-03-20
EP3449614A4 (en) 2019-03-27
US10298716B2 (en) 2019-05-21
CN109417559A (zh) 2019-03-01
EP4340332A3 (en) 2024-08-07
EP3449614C0 (en) 2024-02-07
PL3449614T3 (pl) 2024-07-29
EP3449614A1 (en) 2019-03-06

Similar Documents

Publication Publication Date Title
EP4156642A1 (en) Information centric network tunneling
JP6274584B2 (ja) 広告処理方法及び装置
US20130254544A1 (en) Method and Apparatus for Provisioning a Temporary Identity Module Using a Key-Sharing Scheme
US20130208888A1 (en) Managing content distribution in a wireless communications environment
ES2338362T3 (es) Suscripciones de dispositivos moviles por via aerea.
ES2970866T3 (es) Gestión de recursos de contenido en caché
US20140344901A1 (en) Method And System For Sharing A File
KR20120102972A (ko) 클라우드 환경에서의 데이터 암호화 처리 장치 및 방법
CN103634935A (zh) 基于wps或qss的网络接入方法和装置
ES2887925T3 (es) Nodo de borde y método para entregar contenido en el borde una red de malla
CN103685426A (zh) 信息处理设备和信息处理方法
US20100190481A1 (en) System and method for retrieving the dynamic state of a mobile communication device
JP2017500642A (ja) ポリシー制御機能の管理メカニズムのためのシステム及び方法
US20130268629A1 (en) Method and device for digital data communication
US9788192B2 (en) Making subscriber data addressable as a device in a mobile data network
US10652352B2 (en) Server, client device and methods therein for handling
US10237592B2 (en) Method and apparatus for video transmission
US10516723B2 (en) Distributing subscriber data in a mobile data network
BR112014027847B1 (pt) Método e sistema para pré-busca de dados
JP2015138401A (ja) データ管理装置、データ配信システム
KR20150050669A (ko) 멀티소스(multi-source) 다운로드 시스템 및 그 방법
dos Santos Low-Cost, Lightweight IoT Platform with Custom LPWAN LoRa Integration
KR20150039986A (ko) 컨텐츠 전송 제어 방법 및 이를 위한 장치
JP2005352667A (ja) 分散システム
CN105025033A (zh) 能够防止非法接入的项目发布装置