ES2408131A2

ES2408131A2 - Sistema y método para interconexión de redes de distribución de contenido

Info

Publication number: ES2408131A2
Application number: ES201130756A
Authority: ES
Inventors: Pablo Rodriguez Rodriguez; Armando Antonio GARCIA MENDOZA; Parminder Chhabra; Xiaoyuan Yang
Original assignee: Telefonica SA
Current assignee: Telefonica SA
Priority date: 2011-05-12
Filing date: 2011-05-12
Publication date: 2013-06-18
Anticipated expiration: 2031-05-12
Also published as: BR112013016659A2; WO2012152743A9; EP2708011A1; BR112013016659B1; ES2770652T3; AR086337A1; ES2408131R1; WO2012152743A1; ES2408131B1; EP2708011B1; US20140052822A1

Abstract

Sistema y método para interconexión de redes de distribución de contenido. El sistema comprende una pluralidad CDN, que definen, cada una, una unidad de negocio (OBi) que tiene su respectivo servidor original local (OSi), y medios informáticos para realizar la interconexión de dicha pluralidad CDN, en el que dichos medios informáticos comprenden un servidor original global (OSG) que coordina la formación de una red global conectándose a los servidores originales locales (OS{i}). El método comprende usar un servidor original global para coordinar la formación de una red global mediante su conexión a servidores originales locales CDN.

Description

Sistema y método para interconexión de redes de distribución de contenido.

Campo de la técnica

La presente invención se refiere, en general, en un primer aspecto, a un sistema para interconexión de redes de distribución de contenido y, más en particular, a un sistema que comprende un servidor original global que coordina la formación de una red global conectándose a servidores originales locales de una pluralidad de redes de distribución de contenido o CDN.

Un segundo aspecto de la invención se refiere a un método que comprende usar un servidor original global para coordinar la formación de una red global mediante su conexión a servidores originales locales CDN.

Estado de la técnica anterior

Se incluye la terminología y definiciones que podrían ser útiles para entender la presente invención.

PoP: Un punto de presencia es una demarcación artificial o punto de interfaz entre dos entidades de comunicación. Es un punto de acceso a Internet que aloja servidores, conmutadores, encaminadores y agregadores de llamadas. Los ISP normalmente tienen múltiples PoP.

Red de distribución de contenido (CDN): Esto se refiere a un sistema de nodos (u ordenadores) que contienen copias de contenido de cliente que está almacenado y situado en diversos puntos en una red (o Internet pública). Cuando se replica contenido en diversos puntos en la red, el ancho de banda se utiliza mejor a lo largo de la red y los usuarios tienen tiempos de acceso más rápidos al contenido. De este modo, el servidor original que contiene la copia original del contenido no experimenta atascos.

Sistema de resolución de DNS de ISP: Los usuarios residenciales se conectan a un ISP. Cualquier petición para resolver una dirección se envía a un sistema de resolución de DNS mantenido por el ISP. El sistema de resolución de DNS de ISP enviará la petición de DNS a uno o más servidores DNS dentro del dominio administrativo del ISP.

URL: En términos sencillos, el Uniform Resource Locator (URL, localizador uniforme de recursos) es la dirección de una página web en la world-wide web. No hay dos URL idénticos. Si son idénticos, apuntan al mismo recurso.

Redirección de URL (o HTTP): La redirección de URL también se conoce como reenvío de URL. Puede ser necesario redireccionar una página (1) si su nombre de dominio ha cambiado, (2) si se crean alias significativos para URL largos o que cambian frecuentemente (3) si el usuario deletrea mal el nombre de dominio al teclearlo (4) si se manipula a los visitantes, etc. Para los fines de la presente invención, un servicio de redirección típico es uno que redirecciona usuarios al contenido deseado. Un enlace de redirección puede usarse como dirección permanente para contenido que cambia frecuentemente de anfitrión (host) (casi como de DNS).

Contenedor: Un contenedor es un compartimento lógico para un cliente que contiene el contenido del cliente CDN. Un contenedor o bien establece un enlace entre el URL del servidor original y el URL de la CDN o bien puede contener el propio contenido (que se carga en el contenedor en el punto de entrada). Un nodo de extremo replicará archivos desde el servidor original a archivos en el contenedor. Cada archivo en un contenedor puede correlacionarse exactamente con un archivo en el servidor original. Un contenedor tiene varios atributos asociados con él – el tiempo desde y el tiempo hasta que el contenido es válido, geobloqueo de contenido, etc. También se utilizan mecanismos para garantizar que se transmiten automáticamente nuevas versiones del contenido en el servidor original al contenedor en los nodos de extremo y se eliminan versiones antiguas.

Un cliente puede tener tantos contenedores como desee. Un contenedor es realmente un directorio que contiene archivos de contenido. Un contenedor puede contener subdirectorios y archivos de contenido dentro de cada uno de estos subdirectorios.

Geolocalización: Es la identificación de ubicaciones geográficas reales de un dispositivo conectado a Internet. El dispositivo puede ser un ordenador, dispositivo móvil o un aparato que permita la conexión a Internet a un usuario final. Los datos de geolocalización de la dirección IP pueden incluir información tal como país, región, ciudad, código postal, latitud / longitud de un usuario.

Unidad de negocio (OB): Una OB es un área geográfica arbitraria en la que el proveedor del servicio de CND está instalado. Una OB puede operar en más de una región. Una región es un área geográfica arbitraria y puede representar un país, o parte de un país o incluso un conjunto de países. Una OB puede estar compuesta por más de una región. Una OB puede estar compuesta por uno o más ISP. Cada región en una OB está compuesta por exactamente un rastreador y un servidor DNS de región. Una OB tiene exactamente una instancia de servidor de topología.

ID de partición: Es una correlación global de prefijos de dirección IP con números enteros. Se trata de una correlación uno a uno. Por tanto, no hay dos OB con el mismo PID en su dominio.

Unidad de negocio por defecto: OB0 se define como una unidad de negocio por defecto en la que reside el servidor DNS TLD. Todos los prefijos de IP que no forman parte de otras regiones son por defecto de esta región. Por diseño, la OB0 por defecto está diseñado para tener sólo una región que puede usarse para proporcionar contenido a estos prefijos de IP (que no forman parte de ninguna otra OB).

Aplicación de función hash (hashing) consistente: Este método proporciona la funcionalidad de una tabla hash de modo que la adición o eliminación de una ranura no altera significativamente la correlación de llaves con ranuras. La aplicación de función hash consistente es un modo de distribuir peticiones entre una población grande y cambiante de servidores web. La adición o eliminación de un servidor web no altera significativamente la carga en los otros servidores.

Red superpuesta: Una red superpuesta es una red informática construida encima de otra red. Los nodos en una red superpuesta están conectados mediante enlaces virtuales / lógicos. Cada enlace lógico puede consistir en un trayecto constituido por múltiples enlaces físicos en la red subyacente.

Interconexión de redes de distribución de contenido (CDI): La interconexión de redes de distribución de contenido es la capacidad de conectar muchas CDN administradas de manera independiente para formar una federación CDN. Esto permite a una CDN extenderse más allá de su dominio administrativo para aumentar el alcance de contenido.

Protocolo de control de transporte (TCP): El protocolo de control de transporte es uno de los protocolos principales de los protocolos de Internet. TCP es responsable de una entrega ordenada y fiable de flujos continuos de datos entre dos anfitriones de red.

A continuación se describe cada componente del subsistema del proveedor de servicio CDN. La infraestructura consiste en servidores originales, rastreadores, nodos de extremo y punto de entrada.

-: Punto de publicación: Cualquier cliente CDN puede interaccionar con la infraestructura del proveedor de servicio CDN únicamente a través del punto de publicación (también denominado a veces punto de entrada para mayor simplicidad). El punto de publicación ejecuta una interfaz de servicios web con usuarios de cuentas registradas para crear / borrar y actualizar contenedores.

Un cliente CDN tiene dos opciones para cargar contenido. El cliente puede o bien cargar archivos en el contenedor o bien dar los URL de los archivos de contenido que residen en el sitio web del cliente CDN. Una vez que la infraestructura CDN descarga el contenido, los archivos se mueven a otro directorio para su posprocesamiento. Las etapas de posprocesamiento implican comprobar la consistencia de los archivos y si hay algún error. Sólo entonces se mueve el archivo descargado al servidor original. El servidor original contiene la copia maestra de los datos.

-: Nodo de extremo: Un nodo de extremo es la entidad que gestiona la comunicación entre usuarios finales y la infraestructura CDN. Esencialmente es un servidor HTTP personalizado.

Además, los nodos de extremo mantienen una geobase de datos de IP y una tabla de una lista de centros de datos.

-: Rastreador: El rastreador es la entidad clave que permite la inteligencia y coordinación de la infraestructura del proveedor de servicio CDN. Para ello, un rastreador mantiene (1) información detallada acerca del contenido en cada nodo de extremo y (2) recopila estadísticas de uso de recursos periódicamente de cada nodo de extremo. Mantiene información tal como el número de bytes salientes, número de bytes entrantes, número de conexiones activas para cada contenedor, tamaño del contenido proporcionado, etc.

Cuando un usuario final realiza una petición de contenido, el rastreador usa la información estadística a su disposición para determinar si (1) el contenido puede proporcionarse al usuario final solicitante y si es así, (2) determina el nodo de extremo más cercano y uno con la menor carga para dar servicio a un usuario final. Así, el rastreador actúa como un equilibrador de carga para la infraestructura CDN.

-: Servidor original: Este es el (los) servidor(es) en la infraestructura del proveedor de servicio CDN que contiene(n) la copia maestra de los datos. Cualquier nodo de extremo que no tenga una copia de los datos puede solicitarla del servidor original. El cliente CDN no tiene acceso al servidor original. La infraestructura del proveedor de servicio CDN mueve los datos desde el punto de publicación al servidor original tras realizar comprobaciones de seguridad en los datos descargados.

Las CDN operan normalmente como entidades globales individuales; tienen múltiples puntos de presencia y en ubicaciones que están geográficamente alejadas. Como resultado, una CDN puede tener múltiples réplicas de cada contenido alojado. La definición de servidores originales para proveedores CDN se generaliza de la manera siguiente:

(1) una entidad (tal como un servidor) que reside en el dominio administrativo del cliente CDN. El contenido se replica en nodo(s) de extremo tras la primera petición de contenido por parte de un usuario final. (2) Todos los servidores originales están bajo el control administrativo del mismo proveedor CDN y almacena contenido de clientes CDN. Estos servidores contienen la copia maestra del contenido y la replican en el (los) nodo(s) de extremo. Añadir capacidad de almacenamiento adicional en el proveedor de servicio CDN es meramente cuestión de añadir servidores originales adicionales bajo su control administrativo.

Existen muchos diseños diferentes CDN. Por ejemplo, [2] usa una jerarquía de servidores DNS [1] junto con información de geolocalización para encontrar el servidor de contenido que está más próximo a un usuario final solicitante para proporcionarle contenido. Otras soluciones como [3] se basan en un número pequeño de grandes centros de datos o [6] un gran número de pequeños centros de datos conectados por una red privada bien abastecida para identificar en primer lugar el centro de datos que está más próximo al usuario solicitante. Una vez identificado el centro de datos, se identifica un nodo de extremo en el centro de datos para distribuir el contenido. Sólo en esta etapa final la CDN se conecta a la Internet pública. Además, [5] se basa en una infraestructura de almacenamiento extensivo y de almacenamiento en caché en los puntos de intercambio directo de tráfico (peering) principales. Amazon [4] proporciona servicio CDN usando Amazon Cloudfront junto con su servicio de almacenamiento sencillo permitiendo a los usuarios finales obtener datos de diversas ubicaciones de borde de Internet con las que Amazon intercambia tráfico directamente. De estos, sólo [2] se conecta a la Internet pública y proporciona un servicio CDN global y se encuentra bajo un único dominio administrativo. Los otros diseños CDN se encuentran bajo dominios administrativos diferentes.

Independientemente del control administrativo, el contenido almacenado originalmente en servidores originales se replica en nodos de extremo para su distribución a usuarios finales solicitantes. Los servidores originales en el proveedor de servicio CDN siempre contienen la copia maestra del contenido obtenido de un cliente CDN. El servicio CDN está diseñado para funcionar como una CDN global.

Existen varios motivos por los que diversas OB pueden desear permanecer y operar de manera independiente y aún así reunirse para formar una CDN global.

Cada OB puede ser una unidad de negocio independiente en un país y, por tanto, puede desear un control completo de todos los elementos de la infraestructura de la CDN. Las OB puede aún así forma parte de una única entidad global.

Dado que una OB opera en un país, es más fácil que una OB establezca una relación íntima con los proveedores de contenido de ese país y opere según sus leyes.

Al permitir que los proveedores de contenido en la OB decidan si su contenido es visible sólo dentro de esa OB o puede mostrarse en otras OB (o incluso globalmente), las OB pueden dar a los proveedores de contenido todo el control que deseen sobre su contenido.

Puede que una OB no desee exponer la información topológica detallada acerca de su red a otras OB y aún así formar parte de la CDN global para compartir contenido y expandir el alcance del contenido.

La presencia de varias CDN, cada una operando su propia convención de nomenclatura (es decir, con sus propios URL CDN) y su propia infraestructura de DNS para identificar el contenido solicitado, hace imposible extender la escala y alcance de las CDN. Se han realizado varias propuestas denominadas interconexión de redes de distribución de contenido (CDI) con el objetivo de que las CDN intercambien directamente tráfico. Los objetivos principales del intercambio directo de tráfico entre CDN son (a) aumentar la capacidad, (b) mejorar los puntos de entrega en la red, (c) expandir el alcance del contenido a una base de clientes más amplia, (d) proporcionar mejor tolerancia a fallos y (e) lograr mejores economías de escala y (f) una mejor experiencia global de usuario.

En [8] los autores introducen definiciones para la interconexión de redes de distribución de contenido (CDI) o intercambio directo de tráfico entre CDN y definen la terminología. Conciben que la interconexión de redes de contenido está compuesta por interconexión de redes de contabilidad, pasarelas de interconexión de redes de contenido, interconexión de redes de encaminamiento de peticiones. Los autores comentan muchos mecanismos de encaminamiento de peticiones conocidos en [9]. Comentan esquemas de encaminamiento de peticiones basados en DNS que incluyen resolución de múltiples niveles, difusión al mejor destino (anycast) y codificación de objetos en DNS. Además, comentan esquemas de encaminamiento de peticiones de capa de transporte y aplicación que incluyen reescritura de URL y redirección de HTTP. En [10], los autores presentan diversos escenarios de interconexión de redes de contenido. Proponen pasarelas de interconexión de redes de contenido para encaminar peticiones de contenido y contabilidad en diversos escenarios, poniéndose particular énfasis en la interconexión de redes de contabilidad.

Una técnica llamada intermediación CDN ha sido definida por la Content Alliance. En este caso, intermediación CDN es la capacidad de una CDN de redireccionar clientes de manera dinámica entre dos o más CDN. Una realización de este tipo es el sistema basado en DNS, Intelligent Domain Name Server (IDNS, servidor de nombres de dominio inteligente). El IDNS [7] es un intermediario de DNS que usa una distribución de probabilidad en la región en la que las CDN operan para determinar qué CDN atenderá la petición. Sin embargo, esto requiere que las CDN contengan los nombres de contenido y los nodos de extremo desde los que se proporcionan en cachés. Los nombres de contenido se identifican a partir de la petición de HTTP de las cabeceras. Aunque esto funciona para descargas HTTP, no puede funcionar para transmisión en flujo continuo en tiempo real de contenido.

La mayoría de las propuestas respecto a CDI son muy amplias y ofrecen sólo directrices y pocos protocolos concretos de implementación. Se han detectado algunos problemas con las propuestas existentes:

-: algunos proveedores de servicio CDN grandes pueden elegir que sus CDN sean de “marca blanca”. En este caso, el proveedor CDN de marca blanca y CDN de origen maneja realmente dos CDN con dos controles administrativos

diferentes. No pueden combinarse para formar una única CDN sin discontinuidades por un motivo fundamental: Los URL de contenido para la CDN de marca blanca son diferentes de los del proveedor CDN grande. Para formar una red global sin discontinuidades, ambas CDN tendrán que entender y reescribir los URL de la otra, una tarea enorme.

-: El uso de difusión al mejor destino tiene sus inconvenientes puesto que el servidor DNS puede no ser el más próximo para el encaminamiento al cliente y la carga de servidor no se tiene en cuenta durante el encaminamiento de peticiones.

-: DNS sólo resuelve peticiones a nivel de dominio. Aunque una resolución de petición ideal debe atender peticiones a nivel de objeto, esto es difícil de hacer especialmente cuando se resuelven objetos a través de las CDN.

-: Tener una jerarquía de dominios de DNS también puede implicar tanto complejidad como incompatibilidad puesto que algunas regiones pueden no soportar más de una jerarquía de nivel.

-: El uso de DNS junto con redireccionadores es especialmente complejo a través de las CDN puesto que un sistema de este tipo también tendría que implementar traducciones de URL entre CDN.

-: El desarrollo de sistemas de intermediación para encaminamiento de peticiones y reenvío de contenido requerirá escribir un nuevo conjunto de protocolos entre CDN. Tales sistemas son difíciles de implementar tal como evidencia la ausencia de soluciones de trabajo concretas. Por otro lado, no es difícil implementar sistemas que meramente intercambien información de contabilidad de tráfico.

-: Aunque [10] presenta diversos escenarios en los cuales dos CDN pueden encaminar peticiones a través de pasarelas de interconexión de redes de contenido, no existe ninguna descripción del diseño de tales pasarelas y de cómo las dos CDN deben implementar tales protocolos.

En general, los esfuerzos de normalización en CDI son pobres con poca o ninguna actividad durante la mayor parte de una década.

Notación usada

Se describe ahora la notación usada en el resto de la invención:

OBi: Cualquier unidad de negocio arbitraria i puede indicarse mediante OBi. De manera similar, se han indicado mediante OBk, OBl, OBm las unidades de negocio k, l y m. En este caso, i, k, l, m, etc. son todos números enteros.

OSi: Cualquier unidad de negocio arbitraria i (OBi) tiene un servidor original indicado mediante OSi.

OB0: Se usa para indicar la unidad de negocio por defecto 0.

OSG: Se usa para indicar el servidor original global.

OS{j}: Se usa para indicar una lista de servidores originales que pueden contener un contenido solicitado. Si los servidores originales en j, k, l u m contienen el contenido solicitado, OS{j} = (OSj, OSk, OSl, OSm). En este caso, {j} = (j, k, l, m).

Descripción de la invención

Es necesario proporcionar una alternativa al estado de la técnica, que cubra las lagunas encontradas en la misma, en particular las relacionadas con los problemas indicados anteriormente relacionados con las propuestas de CDI conocidas.

Para ello, la presente invención se refiere, en un primer aspecto, a un sistema para interconexión de redes de distribución de contenido, o CDI, que comprende una pluralidad de redes de distribución de contenido, o CDN, que definen, cada una, una unidad de negocio que tiene su respectivo servidor original local, y medios informáticos para realizar la interconexión de dicha pluralidad CDN.

A diferencia de otras propuestas de CDI conocidas, en la proporcionada por el sistema del primer aspecto de la invención, dichos medios informáticos comprenden un servidor original global que coordina la formación de una red global conectándose a algunos de (o todos) los servidores originales locales en las OB.

Otras realizaciones del sistema del primer aspecto de la invención se describen según las reivindicaciones adjuntas 2 a 14, y en una sección posterior relativa a la descripción detallada de varias realizaciones.

Mediante el sistema de la invención, una CDI puede ejecutarse en una única jerarquía de servidores DNS y puede combinar un número arbitrario CDN al tiempo que se conecta a la Internet pública.

Un segundo aspecto de la invención proporciona un método para interconexión de redes de distribución de contenido. El método comprende realizar la interconexión a una pluralidad CDN, que definen, cada una, una unidad de negocio con su propio servidor original local.

A diferencia de otros métodos conocidos, la CDI proporcionada por el segundo aspecto de la invención comprende usar un servidor original global para coordinar la formación de una red global conectando dicho servidor original global a algunos de (o todos) dichos servidores originales locales.

Otras realizaciones del método del segundo aspecto de la invención se describen según las reivindicaciones adjuntas 15 a 18, y en una sección posterior correlativa a la descripción detallada de varias realizaciones.

Las realizaciones descritas para el sistema del primer aspecto de la invención también son válidas para el método del segundo aspecto, en cuanto a las funciones que realizan los diferentes elementos del sistema.

Breve descripción de los dibujos

Las ventajas y características anteriores, y otras, se entenderán de manera más completa a partir de la siguiente descripción detallada de realizaciones, con referencia a los dibujos adjuntos, que deben considerarse de manera ilustrativa y no limitativa, en los que:

La figura 1 muestra el sistema del primer aspecto de la invención para una realización para la que comprende tres OB de negocio independientes con su propio punto de publicación, rastreador, un servidor DNS autorizado para la única región en las OB, un servidor original y nodos de extremo. Las tres OB forman una CDN global con la ayuda de un servidor original global. Un servidor DNS TLD es el servidor de nombres para t-cdn.net.

La figura 2 muestra el diagrama secuencial para la comunicación entre una OB y OSG para localizar el contenido solicitado de otra OB, para una realización del método del segundo aspecto de la invención.

La figura 3 muestra otra realización del método del segundo aspecto de la invención, en forma de un diagrama secuencial cuando un servidor original de una nueva OB, entra en línea y se llevan a cabo actualizaciones regulares entre OSi y OSG.

Descripción detallada de varias realizaciones

A continuación, se facilitará una descripción de la invención para varias realizaciones, en referencia tanto al sistema como al método de la invención.

Esta invención muestra cómo combinar muchas CDN similares pero que operan de manera independiente para que se unan para formar una red CDN global sin discontinuidades. Como parte de esto, la función tradicional de un servidor original de una entidad autónoma en una CDN que envía contenido a un nodo de extremo para su distribución posterior se extiende a una adaptada al contenido. En una red CDN global que consiste en un conjunto de unidades de negocio (OB), cada OB tiene su propia infraestructura CDN, de modo que los servidores originales de todas las OB forman una red superpuesta de servidores originales que comparten contenido para su replicación en nodos de extremo. Sólo los nodos de extremo dentro de las OB son responsables de distribuir contenido a los usuarios finales solicitantes.

La clave de la arquitectura CDI es (i) la presencia de un servidor original global, OSG. Este OSG mantiene los metadatos de todos los contenedores que están en cada OS de todas las OB en las CDN. (ii) Todos los OS y el OSG se unen para formar una superposición global de servidores originales.

Si el contenido solicitado no está en el OSi de la CDNi solicitante, la ubicación del contenido se determina a partir del OSG. Posteriormente, el OSi descarga el contenido a partir del conjunto de servidores originales OS{j} de las CDN {j, |j| ; 1} en las que el contenido existe. El OSi entonces proporciona el contenido al usuario final solicitante.

Así, todas las CDN que operan en dominios administrativos independientes se unen para formar una CDN global sin discontinuidades.

A continuación, se presentarán los detalles de la arquitectura del sistema de la invención, para interconectar CDN que operan de manera independiente para que se unan para formar una CDN global sin discontinuidades.

Tal como se ve a partir de la figura 1, cada OBi tiene sus propios DNS, rastreador, punto de publicación, servidor original y nodos de extremo. Cada una de estas entidades individuales está bajo el control administrativo y físico de una OB.

Cada OBi tiene un punto de publicación que los clientes de la CDN dentro de la OBi pueden usar para publicar su contenido en la CDN. Los clientes pueden usar dos técnicas para cargar su contenido a la CDN. (1) cargar contenido en sus contenedores en el punto de publicación o (2) proporcionar al punto de publicación la dirección del servidor web para descargar el contenido. Tras el posprocesamiento, el contenedor de cliente con contenido está disponible en el servidor original en el que está listo para proporcionarse a los nodos de extremo. A nivel de contenedor y archivo, el cliente puede determinar la región geográfica en la que puede mostrarse el contenido. La región geográfica está correlacionada con las OB.

Además de un servidor original en cada OB, también existe un servidor original global OSG. El servidor original global mantiene una conexión TCP abierta con cada uno de los OS en las otras OB.

Existe un único servidor de dominio de nivel superior (TLD) para el dominio t-cdn.net. El DNS en cada OB resuelve todas las direcciones IP en el dominio de segundo nivel para la OB (es el servidor autorizado en la subzona de DNS de la OB).

El proveedor de servicio CDN está compuesto por unidades de negocio (OB) independientes que forman juntas una CDN global. Algunos aspectos clave de la CDN global son:

-: Cada OB posee la infraestructura y opera su propia CDN local. Aún así, las OB forman parte de una infraestructura de red CDN global.

-: Además, es necesario realizar funciones centralizadas en todas las OB. La infraestructura para soportar estas funciones puede residir en cualquier OB. Estas funciones centralizadas son (a) desplegar el servidor DNS para resolver el dominio de nivel superior (TLD) para t-cdn.net. (b) desplegar un servidor original global (OSG) que se comunique con cada uno de los servidores originales a través de todas las OB.

-: La OB que aloja el DNS TLD y el OSG se ha designado como OB0. La OB0 también puede tener su propia infraestructura CDN como cualquier otra OB. Sin embargo, no existe un tratamiento preferencial para OB0. La OB0 no es más que un igual para OB1 y OB2, al igual que OB1 es un igual para OB2 (OB0 se usa meramente para mayor comodidad). Todas las OB son iguales y se tratan de igual manera.

El rastreador en cada OBi mantiene un anillo de función hash consistente para todo el contenido que reside en la infraestructura de la OBi.

La construcción de una CDN global sin discontinuidades a partir de un conjunto CDN individuales con sus dominios administrativos individuales consiste en dos etapas principales: En la primera etapa la resolución de DNS se realiza para identificar un nodo de extremo que proporcionará contenido al usuario final solicitante. En la segunda etapa, el nodo de extremo obtendrá el contenido a partir de la red de servidores originales y proporcionará el contenido. A continuación, se comentará la resolución de DNS:

Cuando un usuario final, digamos en OBi, solicita el contenido b87.t-cdn.net/87/video01.flv, el sistema de resolución de DNS del ISP resuelve en primer lugar t-cdn.net de TLD. El servidor DNS TLD resuelve la subzona de OBi usando su geobase de datos de IP. El sistema de resolución de DNS ISP consulta entonces al servidor DNS autorizado en la OBi que reenvía la petición a un nodo de extremo en la OBi.

El nodo de extremo comprueba en primer lugar si el contenedor y contenido solicitados forman parte del OSi. Si no es así, el nodo de extremo comprueba con el servidor original si el contenido forma parte del OSG. Si tampoco forma parte del OSG, se devuelve un error al usuario final. Si el contenido está o bien en el OSi o bien en el OSG, el nodo de extremo determina el centro de datos más próximo al DNS ISP del usuario solicitante (denominado ID de partición, en este caso, digamos 34). El nodo de extremo también calcula la función hash consistente del URL solicitado y devuelve HTTP 302, ubicación movida b87-p34-abf8.t-cdn.net al usuario final. El usuario final envía ahora una petición de resolución de dirección para b87-p34-abf8.t-cdn.net al servidor DNS de la OBi. A continuación, el servidor DNS reenvía la petición al rastreador que da servicio a la OBi. El rastreador realiza una función hash constante del URL recibido e identifica el nodo de extremo que debe proporcionar el contenido solicitado.

La figura 1 muestra el punto de publicación para cada OB. Una vez que la petición de contenido en la forma b87-p34abf8.t-cdn.net llega al servidor DNS autorizado en la OB, la petición se reenvía al nodo de extremo apropiado (etiquetas b y c).

Si el OSi en la OBi tiene el contenido solicitado, se descarga al nodo de extremo que proporciona el contenido al usuario final (etiqueta d en la figura 1). Por otro lado, si el contenido no está en el OSi, como segunda etapa, la red de servidores originales proporcionará el contenido de la manera siguiente:

Una red lógica de servidores originales (OS) se construye con el servidor original global (OSG) como cabeza. El servidor original global OSG mantiene una conexión abierta con los servidores originales a través de todas las OB. Usa esta conexión abierta para sincronizar los contenedores con los servidores originales a través de todas las OB.

Tal como se muestra en la figura 1, si el contenido no está disponible en la OB local (etiqueta 4), el OS1 en la OB1 reenvía la petición a la OBG (etiqueta 5). La OBG responde con la dirección del OS3 de la OB3 como una que tiene el contenido solicitado (etiqueta 6). el OS1 se conecta al OS3 para obtener el contenido (etiquetas 7 y 8). El contenido se reenvía entonces al nodo de extremo apropiado en la OB1 para su entrega al usuario final.

Para obtener el contenido usando el servidor original global OSG se puede utilizar un algoritmo de sincronización. El OSG mantiene una conexión abierta con cada uno de los servidores originales en todas las OB. De manera periódica (cada 2 minutos), cada OS reenvía metadatos para los contenedores y archivos en cada contenedor al OSG. Una vez que cada OS a través de todas las OB ha reenviado su conjunto inicial de contenedores y archivos al OSG, la comunicación posterior con el OSG sólo envía actualizaciones de archivos / contenedores. Esto reduce la sobrecarga de la red en el OSG en presencia de muchas OB.

El OSG puede recibir contenido de los servidores originales en otras OB mediante uno de los siguientes métodos: (1) El OSG toma uno de los servidores originales en las otras OB que tiene el contenido, y reenvía su dirección al OS de la OB solicitante. El OS de la OB solicitante descarga el contenido y lo reenvía al usuario final solicitante. (2) El OSG reenvía una lista de servidores OS en todas las OB que tienen el contenido solicitado. El OS solicitante puede usar (a) un protocolo P2P para descargar el contenido de los OS de las OB que tienen el contenido y reenviar el contenido al usuario final solicitante o (b) obtenerlo de uno de los servidores originales de entre la lista devuelta por el OSj.

En la figura 2, el nodo de extremo obtiene una petición de un archivo harrypotter.flv en el contenedor 87 de un usuario final en la OBi. El OSi en la OBi envía una petición OS_getFile al OSG para determinar los OS que contienen el archivo. El OSG devuelve una lista ordenada {OSl, OSm, OSn} al servidor original OSi. El OSi obtiene el archive del OSl. Una vez que el OSi ha descargado el archivo del OSl, envía el archivo al nodo de extremo solicitante en el OSi. El nodo de extremo da servicio a su vez al usuario final solicitante en la OBi.

Diseño del servidor original global OSG:

A continuación se comenta el diseño del OSG para una realización del sistema del primer aspecto de la invención. El servidor original local OSi en cada OBi en la infraestructura del proveedor de servicio CDN contiene una copia maestra de los datos cargados por todos los clientes CDN en esa OB. El OSG, por otro lado, no contiene una copia maestra de ningún dato. Es la entidad la que coordina la formación de una CDN global conectando todos los OSi inconexos.

Cualquier nodo de extremo que no tenga una copia de los datos puede solicitarla del servidor original. Un cliente CDN no tiene acceso al servidor original. La infraestructura del proveedor de servicio CDN mueve el contenido desde el punto de entrada al servidor original tras realizar comprobaciones de seguridad en los datos descargados.

En total, se definen siete mensajes que deben soportarse como parte del protocolo wire (esto es independiente de si se usa HTTP o un protocolo de paso de mensajes). El OSG soporta los siguientes mensajes:

(1): Obtener la lista de contenedores (OS_getBucketList). El OSG envía este mensaje cuando se establece por primera vez una conexión TCP entre OSi y OSG.

(2): Actualización de contenedores recibida (OS_receivedBucketUpdate). Este mensaje se envía al OSi que envió la lista de contenedores y archivos actualizada.

(3): Lista de servidores originales para el archivo solicitado (OS_listForFile). Este mensaje se envía al OSi que solicitó el archivo en respuesta al mensaje OS_getFile.

(4): Abortar la conexión (OS_connectionAbort). El OSG puede abortar conexiones con cualquiera de (o todos) los OSi si es necesario someter al servidor a mantenimiento o si detecta que no ha recibido ninguna actualización. Esto forzará al OSi a abrir una nueva conexión.

El OSG tiene tres módulos: módulo de conexión, módulo de entorno y un módulo de contenedor. Se describe la función de cada uno de los módulos a continuación.

-: Módulo de conexión: El módulo de conexión tiene un gestor de conexión que es responsable de mantener la conexión con cada uno de los OSi que forman parte de la infraestructura CDN global. Este módulo también es responsable de procesar un mensaje recibido y enviar mensajes al OSi en otras OB.

-: Módulo de entorno: El módulo de entorno tiene un gestor de entorno que conoce a cada uno de los OSi que forma parte de la CDN global. El gestor de entorno también procesa la información estadística recibida de cada uno de los OSi. Así, conoce cuál de los servidores originales está relativamente menos cargado. Si más de un OS tiene el contenido solicitado, se elige el OSj menos ocupado para proporcionar el contenido al OSi.

-: Módulo de contenedor: El módulo de contenedor tiene un gestor de contenedores en el OSG que obtiene una lista de todos los contenedores (y archivos de los contenedores) de cada uno de los OSi. Así, el gestor de contenedor conoce a todos los OSi que tienen un archivo solicitado.

Cuando llega una petición de contenido al OSG, el gestor de conexión recibe la petición. El gestor de contenedores identifica el OS{i} que tiene el archivo solicitado. El gestor de entorno clasifica los OS{i} en orden desde el servidor original más cargado al menos cargado. La lista se envía entonces al OSi solicitante mediante el módulo de conexión.

Diseño del OS en las OB:

El OSi en una OBi todavía almacena una copia maestra de todo el contenido en la OBi. Además, para obtener contenido de otros OS, necesita soportar los siguientes mensajes en un protocolo wire:

(5): Lista de contenedores (OS_bucketList). Este mensaje, junto con una lista de contenedores (y archivos en los contenedores) se envía al OSG en respuesta a OS_getBucketList.

(6): Actualización de lista de contenedores (OS_updateBucketList). Este mensaje se envía al OSG junto con una lista de

actualizaciones de los archivos y contenedores desde la última actualización. Las estadísticas relacionadas con el OSi se adjuntan a las actualizaciones de contenedores enviadas al OSG.

(7): Obtener archivo (OS_getFile). Un OSi obtiene una lista de direcciones IP para el contenido solicitado. Obtiene las direcciones IP en orden desde el servidor original menos ocupado, OSj, primero. El OSi se conecta entonces al OSj y obtiene el contenido solicitado.

Cada uno de los OSi implementa tres módulos, un modulo de conexión, un modulo de estadísticas y un módulo de contenedor.

-: Módulo de conexión: El módulo de conexión tiene un gestor de conexión que gestiona la conexión entre el servidor original local y el OSG. Si el OS local (OSi) cierra la conexión (por cualquier motivo) con el OSG, el gestor de conexión es responsable de reestablecer la conexión con el OSG. El gestor de conexiones en el OSi es responsable de enviar mensajes a y procesar mensajes recibidos desde OSG.

-: Módulo de estadísticas: El módulo de estadísticas mantiene estadísticas de nivel de sistema (consumo de CPU, bytes entrantes y salientes) entre dos periodos de notificación en el OSi.

-: Módulo de contenedor: Este módulo tiene un gestor de contenedores que mantiene una lista de todos los contenedores y archivos en cada uno de los contenedores. El gestor de contenedores también envía actualizaciones de contenedores entre periodos de notificación al OSG.

El usuario final no está en ninguna OB:

Si un usuario final solicitante no está en ninguno de los dominios administrativos de las OB y si el contenido solicitado puede mostrarse en la geografía del usuario final, la petición de contenido se reenvía a la OBl más próxima. El rastreador en la OBl determina entonces el nodo de extremo en la OBl que puede adecuarse mejor para descargar contenido al usuario final solicitante.

Si un nodo de extremo en la OBl que el rastreador asigna para dar servicio al usuario final solicitante no tiene el contenido solicitado, el OSl obtiene en primer lugar la dirección del OS{j}, a partir del OSG, que tiene el contenido solicitado. Posteriormente, el OSl descarga el contenido y lo envía al nodo de extremo asignado en la misma OBl que proporcionará el contenido al usuario final.

Cuando una nueva OB entra en línea:

Cuando una nueva OB (llámese OBn) entra en línea, el OSn en la OBn realiza lo siguiente:

Como parte de su inicialización, se asigna al OSn la dirección IP del servidor original global, OSG. Cuando aparece el servidor original OSn, abre una conexión TCP con el OSG.

El servidor original global OSG recibe la siguiente información de cada uno de los OSi para todas las OBi que se unen para formar una red de interdistribución global. Periódicamente, cada uno de los OSi notifica el número de bytes salientes, el número de bytes entrantes, el número de conexiones activas y la utilización de CPU. El OSG usa esta información para inferir la carga en el OS. El OSi envía esta información con actualizaciones de los contenedores y archivos en cada contenedor.

El diagrama secuencial en la figura 3 describe la comunicación entre OSi y OSG cuando OSi entra en línea:

Cuando una OB entra en línea (digamos OBi), el OSi en la OBi establece una conexión TCP con el OSG. A continuación, el OSG envía un mensaje OS_getBucketList a la OBi. En respuesta, el OSi envía una lista de todos los contenedores y archivos en cada uno de los contenedores al OSG. Tras el intercambio de mensajes inicial, el OSi actualiza el OSG con los cambios en la lista de archivos / contenedores cada par de minutos a través de OS_updateBucketList. Este mensaje también contiene la información estadística en el OSi. En respuesta, el OSG acusa recibo de la información desde la OBi a través de una respuesta OS_receivedBucketUpdate.

Cuando falla una OB:

Cuando falla una OB (la conexión entre OSi y OSG deja de funcionar), el gestor de contenedores en el OSG elimina todos los contenedores y archivos asociados con el OSi. El gestor de entorno en el OSG elimina el OSi de su lista de nodos de entorno y todos los contenedores asociados con el OSi. Cuando un OSi en la OBi entra en línea, intenta abrir una conexión con el OSG.

Normalmente, se crea un espejo del OSG por motivos de redundancia. Sin embargo, si el OSG debe dejar de funcionar por motivos de mantenimiento (o por cualquier otro motivo inesperado) y aparece de nuevo, comienza la interconexión entre las CDN inconexas. Una vez que cada uno de los OSi se conecta con el OSG, responden a la petición OS_getBucketList con una lista de contenedores y archivos en los contenedores. Posteriormente, cada uno de los OSi envía periódicamente las actualizaciones de archivos y contenedores al OSG.

Funciones clave del servidor original global: El servidor original global OSG tiene las siguientes funcionalidades:

-: El OSG ayuda a cada uno de los OSi a formar una red de servidores originales.

-: Periódicamente, el OSG se comunica con cada uno de los servidores originales OSi

1.: Obtiene una lista de contenedores y archivos en los contenedores de cada uno de los OSi.

2.: Obtiene actualizaciones de cualquiera de los archivos / contenedores en cada uno de los OSi.

3.: Obtiene información estadística sobre el estado de cada uno de los OSi. Esto permite al OSG inferir qué OSk es mejor para atender la petición de contenido para OSj.

Así, el OSG conoce la ubicación de cada contenido en cada OB. Cuando un OSi en una OBi busca un contenido, obtiene una lista ordenada de OB{i} de las cuales puede solicitar el contenido.

Ventajas de la invención: Las principales ventajas de esta invención son:

-: Permite a OB en distintos dominios administrativos unirse para formar una red CDN global sin discontinuidades.

-: Desacopla identificación de contenido y reenvío de la DNS a servidores originales a través de diferentes OB. El encaminamiento de contenido realizado en el OS de la OB que da servicio es en el nivel de transporte.

-: Evita la complejidad del intercambio directo de contenido entre CDN. Realiza esto usando un servidor original global OSG que tiene una visión global de todo el contenido en los servidores originales a través de todas las OB.

-: Los nodos de extremo, cuando solicitan contenido, se conectan a una red de servidores originales superpuestos. En realidad, reciben contenido sólo del servidor original local de la OB. Así, los nodos de extremo no necesitan conocer o resolver las direcciones de otras OB.

-: El método garantiza sobrecarga de comunicación baja a través de la red de OS pasando sólo las actualizaciones entre OS y OSG individuales en lugar de enviar toda la lista de contenedores cada vez.

Un experto en la técnica puede introducir cambios y modificaciones en las realizaciones descritas sin apartarse del alcance de la invención tal como se define en las reivindicaciones adjuntas.

SIGLAS Y ABREVIATURAS ADSL ASYMMETRIC DIGITAL SUBSCRIBER LINE; LÍNEA DE ABONADO DIGITAL ASIMÉTRICA CDN CONTENT DISTRIBUTION NETWORK; RED DE DISTRIBUCIÓN DE CONTENIDO DNS DOMAIN NAME SERVICE; SERVIDOR DE NOMBRES DE DOMINIO

5 POP POINT OF PRESENCE; PUNTO DE PRESENCIA

TLD TOP LEVEL DOMAIN; DOMINIO DE NIVEL SUPERIOR FTP FILE TRANSFER PROTOCOL; PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS HTTP HYPERTEXT TRANSFER PROTOCOL; PROTOCOLO DE TRANSFERENCIA DE HIPERTEXTO MD5 MESSAGE-DIGEST ALGORITHM 5; ALGORITMO DE RESUMEN DEL MENSAJE 5

10 URL UNIFORM RESOURCE LOCATOR; LOCALIZADOR UNIFORME DE RECURSOS

ISP INTERNET SERVICE PROVIDER; PROVEEDOR DE SERVICIOS DE INTERNET TTL TIME TO LIVE; TIEMPO DE VIDA OB OPERATING BUSINESS; UNIDAD DE NEGOCIO CDI CONTENT DISTRIBUTION INTERNETWORKING; INTERCONEXIÓN DE REDES DE DISTRIBUCIÓN DE

15 CONTENIDO

TCP TRANSPORT CONTROL PROTOCOL; PROTOCOLO DE CONTROL DE TRANSPORTE BIBLIOGRAFÍA

[1] Domain Name System definition. http://en.wikipedia.org/wiki/Domain_Name_System

[2] Akamai. http://www.akamai.com

[3] Limelight Networks, http://www.limelightnetworks.com/ 5 [4] Amazon Cloudfront, http://aws.amazon.com/cloudfront/

[5] Edgecast, http://www.edgecast.com/

[6] Highwinds Network Group, http://www.highwinds.com/

[7] A. Biliris, C. Cranor, F. Douglis, M. Rabinovich, S. Sibal, O. Spatscheck, y W. Sturm, "CDN Brokering", Proceedings of the 6th International Workshop on Web Caching and Content Distribution, Boston, MA, junio de 2001.

10 [8] M. Day, B. Cain, G. Tomlinson y P. Rzewski, A Model for Content Internetworking (CDI), Internet Engineering Task Force RFC 3466, febrero de 2003. www.ietf.org/rfc/rfc3466.txt

[9] A. Barbir, B. Cain, F. Douglis, M. Green, M. Hofmann, R. Nair, D. Potter y O. Spatscheck, Known Content Network (CN) Request-Routing Mechanisms, mayo de 2002. www.ietf.org/rfc/rfc3568.txt

[10] P. Rzewski, M. Day y D. Gilletti, Content Internetworking (CDI) Scenarios, RFC 3570, julio de 2003. 15 www.ietf.org/rfc/rfc3570.txt

Claims

REIVINDICACIONES

1. Sistema para interconexión de redes de distribución de contenido, que comprende una pluralidad de redes de distribución de contenido, o CDN, que definen, cada una, una unidad de negocio (OBi), y medios informáticos para realizar la interconexión de dicha pluralidad CDN, en el que el sistema está caracterizado porque:

-

dichos medios informáticos comprenden un servidor original global (OSG) que coordina la formación de una red global conectándose a algunos de o todos dichos servidores originales locales (OSi) en cada una de dichas unidades de negocio (OBi); y

-

dicho servidor original global (OSG) mantiene metadatos de los contenedores que están en cada uno de dichos servidores originales locales (OSi) en la pluralidad CDN,

de este modo permite la localización de contenido, en el caso de que dicho servidor original local (OSi) no contenga un contenido solicitado, por dicho servidor original global (OSG).
2.

Sistema según la reivindicación 1, en el que dicho servidor original global (OSG) se conecta a cada uno de dichos servidores originales locales (OSi) en cada una de dichas unidades de negocio (OBi) manteniendo una conexión TCP abierta con cada uno de dichos servidores originales locales (OSi).
3.

Sistema según las reivindicaciones 1 o 2, que comprende un único servidor de dominio de nivel superior, TLD, común para todas las unidades de negocio (OB).
4.

Sistema según la reivindicación 3, en el que dicho servidor TLD está desplegado en una de dichas unidades de negocio (OB0).
5.

Sistema según cualquiera de las reivindicaciones anteriores, en el que dicho servidor original global (OSG) está desplegado en una de las unidades de negocio (OB0).
6.

Sistema según cualquiera de las reivindicaciones anteriores, en el que dicho servidor original global (OSG) se encarga de devolver una lista de direcciones IP de uno o más servidores originales locales (OS{j}) que tienen el contenido específico solicitado por el servidor original local, OSi.
7.

Sistema según la reivindicación 6, en el que dicho servidor original local (OSi) solicitante se conecta a uno de los servidores originales locales de la lista de servidores originales (OS{j}), y descarga el contenido solicitado.
8.

Sistema según cualquiera de las reivindicaciones anteriores, en el que dicho servidor original global (OSG) comprende un módulo de conexión que tiene un gestor de conexión que es responsable de mantener una conexión TCP abierta con cada uno de los servidores originales locales (OSi) en cada una de dichas unidades de negocio (OBi).
9.

Sistema según la reivindicación 8, cuando depende de la reivindicación 6, en el que dicho módulo de conexión de dicho servidor original global (OSG) es responsable de procesar un mensaje recibido desde un servidor original local (OSi) solicitando un contenido específico, y devolver en respuesta al mismo servidor original local (OSi), un mensaje que incluye una lista de direcciones IP de uno o más servidores originales (OS{j}) que tienen el contenido solicitado.
10.

Sistema según la reivindicación 9, en el que dicho servidor original global (OSG) comprende un módulo de contenedor que tiene un gestor de contenedores que obtiene una lista de todos los contenedores y archivos en los contenedores de cada uno de los servidores originales locales (OSi), y es responsable de identificar la lista de servidores originales locales (OS{j}) que tienen el contenido solicitado.
11.

Sistema según la reivindicación 10, en el que dicho servidor original global (OSG) comprende un modulo de entorno que tiene un gestor de entorno con información acerca de cada uno de los servidores originales locales (OSi) en cada una de dichas unidades de negocio (OBi) que también procesa información estadística recibida desde cada uno de los servidores originales e identifica en primer lugar la lista de servidores originales locales (OS{j}) que pueden proporcionar el contenido solicitado, y a continuación crea y devuelve una lista ordenada desde el servidor original menos cargado hasta el servidor original más cargado, de dichos uno o más servidores originales locales (OS{j}) que pueden proporcionar el contenido solicitado.
12.

Sistema según cualquiera de las reivindicaciones anteriores, en el que cada uno de dichos servidores originales locales (OSi) en cada una de las unidades de negocio (OBi) comprende un módulo de conexión con un gestor de conexión que gestiona la conexión entre los servidores originales locales (OSi) en cada una de dichas unidades de negocio (OBi) y el servidor original global (OSG), para enviar y recibir mensajes, para procesar los mensajes recibidos, y para reestablecer dicha conexión en caso de que se haya cerrado.
13.

Sistema según la reivindicación 12, en el que cada uno de dichos servidores originales locales (OSi) en cada una de dichas unidades de negocio (OBi) comprende un módulo de estadística que mantiene estadísticas de nivel de sistema entre dos periodos de notificación.
14.

Sistema según la reivindicación 12 ó 13, en el que cada uno de dichos servidores originales locales (OSi) en cada una de dichas unidades de negocio (OBi) comprende un módulo de contenedor con un gestor de contenedores que mantiene una lista de todos los contenedores y archivos en cada uno de los contenedores y envía cualquier actualización de contenedor entre dos periodos de notificación al servidor original global (OSG).
15.

Método para interconexión de redes de distribución de contenido, que comprende realizar la interconexión de una pluralidad de redes de distribución de contenido, o CDN, que definen, cada una, una unidad de negocio (OBi) que tiene su propio servidor original local (OSi), estando el método caracterizado porque comprende, para realizar dicha interconexión:

-

usar un servidor original global (OSG) para coordinar la formación de una red global conectando dicho servidor original global (OSG) a algunos de o todos dichos servidores originales locales (OSi) en cada una de dichas unidades de negocio (OBi);

-

mantener dicho servidor original global (OSG) metadatos de los contenedores que están en cada uno de dichos servidores originales locales (OSi) en la pluralidad CDN; y

-

en el caso de que un contenido solicitado no esté en dicho servidor original local (OSi), realizar una petición a dicho servidor original global (OSG) para recuperar dicho contenido solicitado.
16. Método según la reivindicación 15, que comprende:

-solicitar un usuario final un contenido específico de un nodo de extremo en una de dichas unidades de negocio (OBi); -recibir dicho nodo de extremo dicha petición de contenido de dicho usuario final; -enviar dicho nodo de extremo en dicha unidad de negocio (OBi) la petición de contenido al servidor original

local (OSi) en dicha unidad de negocio (OBi);

-recibir el servidor original local (OSi) dicha petición de contenido de dicho nodo de extremo en dicha unidad de negocio (OBi); -comprobar, dicho servidor original local (OSi), si tiene el contenido solicitado, y si no lo tiene, enviar la petición

de contenido a dicho servidor original global (OSG) -identificar el servidor original global (OSG) uno o más servidores originales locales (OS{j}) que tienen el

contenido solicitado y crear una lista ordenada con sus direcciones IP empezando con el servidor original menos cargado y enviar dicha lista de servidores originales (OS{j}) al servidor original local (OSi) que solicitó el contenido; -seleccionar de dicha lista, el servidor original local (OSi) que no tiene el contenido solicitado: -si sólo hay en la lista una dirección de servidor original local (OS{j}), la dirección de dicho servidor original local

(OSj); o

-

si en la lista hay más de una dirección de servidor original local (OS{j}), la dirección del servidor original local (OSj) menos cargado, -conectarse, el servidor original local (OSi) que no tiene el contenido solicitado, al servidor original local

seleccionado (OSj), y descargar el contenido solicitado;

-

reenviar, el servidor original local (OSi) que ha descargado el contenido solicitado, el contenido descargado al nodo de extremo solicitante; y -enviar el nodo de extremo el contenido al usuario final solicitante.
17.

Método según la reivindicación 15 ó 16, que comprende un servidor original local (OSi) que entra en línea: -establecer dicho servidor original local (OSi) una conexión TCP con dicho servidor original global (OSG); -enviar el servidor original global (OSG) al servidor original local (OSi), a través de dicha conexión TCP, un

mensaje solicitando información acerca de sus contenedores; y -enviar el servidor original local (OSi) al servidor original global (OSG) dicha información requerida en forma de una lista de todos los contenedores y archivos en cada uno de los contenedores en el servidor original local (OSi).
18.

Método según la reivindicación 15 ó 16, que comprende, comunicarse periódicamente dicho servidor original global (OSG), con cada uno de los servidores originales locales (OSi), para

-

obtener una lista de contenedores y archivos en los contenedores de cada uno de los servidores originales locales (OSi);

-

obtener actualizaciones de cualquiera de los archivos / contenedores en cada uno de los servidores originales locales (OSi); y

-

obtener información estadística sobre el estado de cada uno de los servidores originales locales (OSi).

Figura 2

Figura 3