ES2429222A1 - Método y nodo de extremo para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido - Google Patents
Método y nodo de extremo para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido Download PDFInfo
- Publication number
- ES2429222A1 ES2429222A1 ES201130760A ES201130760A ES2429222A1 ES 2429222 A1 ES2429222 A1 ES 2429222A1 ES 201130760 A ES201130760 A ES 201130760A ES 201130760 A ES201130760 A ES 201130760A ES 2429222 A1 ES2429222 A1 ES 2429222A1
- Authority
- ES
- Spain
- Prior art keywords
- real
- time
- streaming
- segments
- end node
- 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.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/765—Media network packet handling intermediate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- 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/104—Peer-to-peer [P2P] networks
- H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
- H04L67/1078—Resource delivery mechanisms
-
- 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/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
-
- 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
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
- H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/65—Transmission of management data between client and server
- H04N21/658—Transmission by the client directed to the server
- H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
Método y nodo de extremo para distribuir flujo contínuo de contenido en tiempo real en una red de distribución de contenido. El método comprende la gestión y entrega de un flujo continuo en tiempo real solicitado usando una arquitectura basada en P2P, en el que los iguales que intercambian contenido entre sí son nodos de extremo de una CDN. La entrega del flujo continuo en tiempo real solicitado a uno o más usuarios finales se realiza desde uno o más de dichos nodos de extremo. El flujo continuo en tiempo real solicitado se divide en segmentos que obtienen los nodos de extremo de servicio, preferiblemente, de nodos de extremo de entorno y/o del servidor original del flujo continuo en tiempo real usando un algoritmo de planificación y dependiendo de la disponibilidad de segmentos del mismo. El nodo de extremo está diseñado para implementar el método de la invención.
Description
Campo de la técnica
La presente invención se refiere, en general, en un primer aspecto, a un método para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido (CON), y más particularmente a un método que comprende la gestión y entrega de un flujo continuo en tiempo real solicitado según una arquitectura basada en P2P (peer-to-peer, de igual a igual), en el que los iguales son nodos de extremo (también denominados servidores de contenido) de dicha CON.
Un segundo aspecto de la invención se refiere a un nodo de extremo para una CON diseñado para implementar el método del primer aspecto.
Estado de la técnica anterior
Los sistemas de igual a igual (P2P) han tenido éxito a la hora de distribuir archivos a un gran número de usuarios. Los sistemas P2P también se usan ampliamente para la distribución de contenido de vídeo incluyendo descargas de vídeo (en las que es necesario que los usuarios descarguen todo el archivo de vídeo antes de poder ver el vídeo) y transmisión en flujo continuo de medios en tiempo real (tal como Coolstreamíng). Recientemente se han diseñado nuevos sistemas [1, 1O, 11] para permitir una experiencia de vídeo bajo demanda (VoO; Vídeo on Demand) usando P2P. Sin embargo, tales servicios asumen de manera implícita que los usuarios visualizan el contenido desde el inicio hasta el final a la tasa de reproducción. El soporte de la funcionalidad de OVO (pausa/reanudar, saltar hacia delante o hacia atrás a través del vídeo) es un requisito natural para la mayor parte de los sistemas de VoO. Aunque muchos sistemas centralizados populares (denominados así porque ofrecen un flujo continuo dedicado entre el servidor de contenido de un propietario de contenido y el usuario final solicitante) como Youtube [19], Netflix [20] y sistemas de cine en casa ofrecen funcionalidad de búsqueda, las funciones de OVO se ignoran en gran parte por muchos de los sistemas de VoO P2P.
El diseño de los sistemas de VoO basados en P2P con funcionalidad de OVO no es trivial debido a la falta de sincronización entre los usuarios finales que reduce la oportunidad para la compartición basada en P2P. A medida que los usuarios van saltando por un vídeo, disminuye su posibilidad de compartición y es necesario proporcionar contenido desde el servidor original que almacena la copia maestra del contenido para garantizar una buena experiencia de visualización para el usuario. Un buen diseño requiere un retardo reducido al realizar las operaciones de OVO y una tasa de reproducción mantenida al tiempo que se minimiza la cantidad de datos proporcionados por el servidor original. Esto implica hallar los iguales adecuados, planificar el contenido para su intercambio en el momento adecuado, una tarea de diseño que no es trivial. Aunque es de difícil ejecución en un entorno de VoO, los objetivos del diseño son similares para una solución de transmisión en flujo continuo en tiempo real. La implementación de soluciones basadas en P2P es relativamente más fácil de implementar en un entorno de transmisión en flujo continuo en tiempo real sin una carga mantenida en el servidor original puesto que proporcionan iguales con numerosas oportunidades para compartir contenido. Sin embargo, una solución de este tipo aún proporciona desafíos considerables a la hora de encontrar los iguales adecuados para planificar el intercambio de datos entre los iguales.
Los primeros sistemas de entrega de vídeo basados en P2P se construyeron para transmisión en flujo continuo de vídeo en tiempo real e incluían superposiciones basadas en árboles tales como Slípstream, y superposiciones basadas en mallas, tales como Coolstreamíng y PPLíve. Los sistemas P2P de vídeo de próxima generación se diseñaron para soportar V o O, entre los que se incluyen BitOS [11 ], BASS [10], Redcarpet [1], Toast [14]. Por ejemplo, BiToS divide los bloques que faltan en dos conjuntos (prioridad baja y prioridad alta), y planifica peticiones de manera correspondiente desde iguales y el servidor. BASS amplía BitTorrent para proporcionar servicios de V o O, con una alta dependencia del servidor. En [1], los autores muestran los beneficios de codificación de red para simplificar el problema de planificación de segmentos y proporcionar servicios de VoO de alta calidad. En [6], los autores presentan una formulación analítica del impacto de diversas políticas de planificación para optimizar el rendimiento de VoO. En [3], los autores describen los desafíos a los que se enfrenta un sistema de VoO P2P comercial desplegado por PPLive y proponen algoritmos de planificación, replicación y descubrimiento de contenido para afrontar estos desafíos.
Recientemente, [12] [7] y [2] han analizado algunos de los problemas que pueden surgir a la hora de diseñar sistemas P2P que soportan una funcionalidad similar a OVO. En particular, [12] introdujo el concepto de anclajes para realizar una prebúsqueda de datos en puntos previamente definidos del vídeo y permitir saltos a tales puntos. En Bulletmedia [2], los autores propusieron un almacenamiento en caché proactivo más agresivo, que crea de manera proactiva múltiples copias de cada segmento en una superposición, reduciendo así la dependencia de la fuente. El objetivo es garantizar que todos los bloques se repliquen en la superposición, independientemente de cuándo el conjunto de iguales activos en la superposición requerirá que soporten una reproducción actual. En [7] proponen un protocolo gossíp a través de un anillo, en el que cada igual mantiene algunos vecinos próximos así como algunos vecinos remotos siguiendo un radio de ley exponencial, y muestran a través de simulaciones que pueden gestionar búsquedas aleatorias.
En [21] los autores determinan los intercambios fundamentales y las limitaciones sobre la carga del servidor original y la experiencia de usuario usando rastros de salto de usuario final en tiempo real obtenidos a partir de un despliegue de un sistema real para validar sus opciones de diseño. Mediante el uso de patrones de salto de usuario final realistas y una implementación de trabajo, muestran que es posible conseguir una experiencia de usuario muy buena sin sobrecargar de manera agresiva el sistema.
Muchas CON usan o bien la solución de servidor de medios de transmisión en flujo continuo de Microsoft [17] o bien el servidor de medios flash de Adobe [18] para distribuir flujos continuos de contenido en tiempo real. Los servidores en ambos casos proporcionan un flujo continuo a cada uno de los usuarios finales solicitantes. También aprovechan la transmisión en flujo continuo dinámica y multidifusión IP.
Tanto Octoshape [22] como Rawflow [16] son sistemas basados en P2P que se usan para distribuir contenido a usuarios finales solicitantes. Los usuarios finales que usan Octoshape descargan un complemento (plug-ín) basado en P2P que se utiliza a continuación por los anfitriones de usuario final para distribuir contenido.
Para Rawflow [16], los usuarios finales conocidos como clientes de distribución de contenido inteligente (ICD; lntellígent Content Dístríbutíon) contactan con el servidor de ICD y comienzan a recibir el flujo continuo desde el mismo. El reproductor en el usuario final reproduce el flujo continuo a medida que lo recibe el cliente de ICD. Los clientes de ICD se unen para formar una red. Un cliente de ICD también acepta conexiones desde otros clientes en la red a los que puede retransmitir parte de o todo el flujo continuo que recibe según se solicita. El cliente de ICD monitoriza la calidad del flujo continuo que recibe y, con cualquier reducción de calidad o pérdida de conexión, busca de nuevo en la red para detectar recursos disponibles mientras continúa dando
- servicio al reproductor de medios desde su memoria intermedia. La memoria
- intermedia evita la interrupción de la reproducción y garantiza que la experiencia del
- usuario final no se vea afectada.
- Problemas con las soluciones existentes:
- 5
- La mayor parte de operadores CON usan o bien el servidor de medios de
- transmisión en flujo continuo de Microsoft o bien el servidor de medios flash de Adobe
- para distribuir contenido. El proveedor de servicios CON también tiene poco control
- sobre la forma en que estas soluciones utilizan la red y tiene pocas oportunidades para
- optimizar la red para la entrega de contenido, más aún en el caso de flujos continuos
- 1O
- en tiempo real.
- Varios sistemas basados en P2P presentados anteriormente se centran o bien
- en cómo realizar una prebúsqueda de contenido por todo el enjambre o bien en cómo
- los iguales deben estar relacionados entre sí, y usan simulaciones para evaluar
- patrones de saltos aleatorios simples, que podrían afectar al diseño del sistema. La
- 15
- prebúsqueda agresiva podría dar como resultado un desperdicio de los recursos del
- servidor original y de los iguales si no se producen saltos de usuario final (más aún
- para un flujo continuo en tiempo real), y correlacionar iguales es sólo una parte del
- espacio de diseño y requiere una combinación cuidadosa con otras opciones de
- diseño tales como políticas de planificación inteligente o estrategias de control de
- 20
- admisión eficaces. Además, el uso de los sistemas anteriores en una CON para
- distribuir contenido en tiempo real presenta desafíos excepcionales, puesto que los
- usuarios esperan vídeos de alta calidad con experiencia de usuario de tipo TV incluso
- cuando se realizan operaciones de OVO.
- La mayor parte de las soluciones basadas en P2P se basan en usuarios finales
- 25
- que se comportan como iguales para participar en la distribución de contenido. Esto
- requiere que los nodos de extremo o bien descarguen una aplicación o bien
- descarguen un complemento para el explorador para formar parte de la red de
- distribución de contenido. Las soluciones P2P puras usan por tanto recursos
- informáticos del usuario final, una infraestructura poco fiable por lo que respecta a una
- 30
- distribución de contenido fiable.
- Mediante el uso de recursos informáticos en los usuarios finales, los
- distribuidores de contenido desplazan su parte del coste de ancho de banda a los
- usuarios finales, una práctica que no proporciona un ancho de banda fiable (o
- suficiente) para un intercambio de contenido de alta calidad. Además, como parte de la
aceptación del usuario final para usar un software de este tipo, dicho software también se reserva el derecho de ampliar el alcance de lo que dicho software puede realizar en un sistema de usuario final [22] dando como resultado una acción impredecible en el usuario final (tal como deshabilitar el software). Dado lo imprevisible de tales sistemas para distribuir contenido en tiempo real, ello implica que no pueden atraer a suficientes usuarios para conseguir una masa crítica para formar parte de una infraestructura fiable para la transmisión en flujo continuo en tiempo real.
Descripción de la invención
Es necesario proporcionar una alternativa al estado de la técnica existente que cubra las lagunas encontradas en la misma, en particular las encontradas en los diseños CON existentes que soportan transmisión en flujo continuo en tiempo real que sobrecargan el servidor original que se carga con la distribución de un flujo continuo en tiempo real de este tipo.
Para ello, la presente invención se refiere, en un primer aspecto, a un método para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido, que comprende proporcionar, una entidad de dicha red de distribución de contenido, o CON, un flujo continuo en tiempo real solicitado a al menos un usuario final, en el que el método se guía por una arquitectura basada en P2P.
Según el método de la invención, la gestión y entrega de dicho flujo continuo en tiempo real solicitado se realiza usando una arquitectura basada en P2P, en el que los iguales son nodos de extremo de dicha CON que intercambian contenido entre sí, en el que la entrega de dicho flujo continuo en tiempo real solicitado a dichos uno o más usuarios finales se realiza desde al menos uno de dichos nodos de extremo.
En una realización preferida, el método comprende obtener, dicho nodo de extremo, dicho flujo continuo en tiempo real solicitado por fragmentos o segmentos en los que previamente se ha dividido, desde un servidor original y/o desde nodos de extremo de entorno, dependiendo de su disponibilidad.
Otras realizaciones del método del primer aspecto de la invención se describen según las reivindicaciones 2 a 22, y en una sección posterior relativa a la descripción detallada de varias realizaciones.
Un segundo aspecto de la invención se refiere a un nodo de extremo para una CON que comprende un módulo de flujo continuo en tiempo real que implementa un planificador que incluye un módulo predictor del punto de reproducción en tiempo real, un módulo gestor de descarga P2P y un módulo servidor de flujo continuo en tiempo real, para distribuir flujo continuo de contenido en tiempo real realizando las acciones del método del primer aspecto de la invención según la realización descrita en la reivindicación 13 adjunta.
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 es un diagrama secuencial para implementar transmisión en flujo continuo en una CON del proveedor de servicios según el método del primer aspecto de la invención; y
la figura 2 muestra el módulo de transmisión en flujo continuo en tiempo real del nodo de extremo del segundo aspecto de la invención, compuesto por tres submódulos.
Descripción detallada de varias realizaciones La terminología y definiciones que pueden ser útiles para entender las diferentes realizaciones de la presente invención son las siguientes:
- -
- 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 (Internet Servíce Províder; proveedor de servicios de Internet) normalmente tienen múltiples PoP.
- -
- Red de distribución de contenido (CON): 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.
-URL: En términos sencillos, el Uníform Resource Locator (URL, localizador uniforme de recursos) es la dirección de una página web en la world-wíde web. No hay
dos URL idénticos. Si son idénticos, apuntan al mismo recurso.
- -
- Contenedor: Un contenedor es un compartimento lógico para un cliente que contiene el contenido del cliente CON. Un contenedor o bien establece un enlace entre el URL del servidor original y el URL de la CON 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 transmitan automáticamente nuevas versiones del contenido en el servidor original al contenedor en los nodos de extremo y se eliminen 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 para un usuario final. Los datos de geolocalización de la dirección IP (Internet Protocol; protocolo de Internet) pueden incluir información tal como país, región, ciudad, código postal, latitud/longitud de un usuario.
- -
- Unidad de negocio (OB; Operatíng Business): Un OB es un área geográfica arbitraria en la que está instalada la CON del proveedor de servicios. Un 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. Un OB puede estar compuesto por más de una región. Un OB puede estar compuesto por uno o más ISP. Un OBtiene 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 PIDen su dominio.
A continuación se describe cada componente de los subsistemas del proveedor de servicios CON. La infraestructura consiste en servidores originales, rastreadores, nodos de extremo y punto de publicación.
- -
- Punto de publicación: Cualquier cliente CON puede interaccionar con la
infraestructura del proveedor de servicios CON ú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 CON 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 CON. Una vez que la infraestructura CON descarga el contenido, los archivos se mueven a otro directorio para su postprocesamiento. Las etapas de postprocesamiento 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.
Para contenido en tiempo real, el cliente CON sólo proporciona a la CON un URL del flujo continuo en tiempo real.
- -
- Nodo de extremo: Un nodo de extremo es la entidad que gestiona la comunicación entre usuarios finales y la infraestructura CON. Esencialmente es un servidor HTTP personalizado.
- -
- Archivo hdr/hdx: En transmisión en flujo continuo en tiempo real, cuando se divide contenido (de cualquier formato), se crean dos tipos de archivos, los archivos hdr y hdx. Un archivo hdr es en realidad un archivo de cabecera que contiene información de cabecera sobre los medios, resolución, tasa de transmisión de bits, etc. y el archivo hdx es una memoria intermedia circular de URL de segmentos del flujo continuo en tiempo real original que residen en el divisor en tiempo real.
- -
- Rastreador: El rastreador es la entidad clave que permite la inteligencia y coordinación de la infraestructura del proveedor de servicios CON. 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.
-Servidor original: Es el servidor en la infraestructura del proveedor de servicios CON que contiene 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 CON no tiene acceso al servidor original. La infraestructura del proveedor de servicios CON mueve los datos desde el punto de publicación al servidor original tras realizar comprobaciones de seguridad en los datos descargados.
Para contenido en tiempo real, el divisor en tiempo real sirve como servidor original. Su memoria intermedia limita la cantidad de contenido en tiempo real almacenado en el divisor en tiempo real. Esto permite a un usuario final realizar operaciones de OVO en un flujo continuo en tiempo real durante una duración igual o no superior al tamaño de la memoria intermedia.
En esta sección se detalla el diseño de soporte de transmisión en flujo continuo en tiempo real en una CON del proveedor de servicios que se basa en una arquitectura basada en P2P. Los nodos de extremo en el mismo centro de datos que proporcionan contenido en tiempo real se consideran iguales en este diseño. Sin embargo, los usuarios finales que solicitan contenido no se consideran iguales para la finalidad de distribuir contenido.
Esta invención se basa en una arquitectura P2P que permite a los nodos de extremo intercambiar contenido entre sí en un centro de datos. Como los nodos de extremo en un centro de datos están bien aprovisionados, no sufren las mismas limitaciones informáticas y de ancho de banda a las que se enfrentan los sistemas basados en P2P tradicionales [16][22] que se basan en usuarios finales como iguales.
A continuación se proporciona una descripción detallada de cómo un cliente CON puede configurar la distribución de contenido en tiempo real y cómo se trata una señal en tiempo real una vez que entra en una CON del proveedor de servicios. También se detalla la arquitectura del módulo de transmisión en flujo continuo en tiempo real en un nodo de extremo en una CON del proveedor de servicios y cómo los nodos de extremo intercambian contenido entre sí cuando es posible, y también cómo los nodos de extremo dan servicio a un usuario final solicitante.
A continuación se describe en detalle el diseño y la arquitectura de transmisión en flujo continuo en tiempo real en una CON del proveedor de servicios para algunas realizaciones.
Una vez que un flujo continuo en tiempo real está dentro del ecosistema del proveedor de servicios CON, se segmenta y se crea una lista de reproducción de los segmentos. Este segmentador sirve como servidor original para el flujo continuo en tiempo real. La lista de reproducción se reenvía a los nodos de extremo que hayan solicitado el flujo continuo en tiempo real. Una vez que los nodos de extremo reciben la lista de reproducción, intercambian los segmentos de la lista de reproducción entre ellos cuando es posible y obtienen los segmentos del servidor original cuando es necesario.
En primer lugar se detalla la manera en la que un flujo continuo en tiempo real se asocia en primer lugar con un contenedor en tiempo real que constituye la base para la entrega de flujos continuos en tiempo real.
Crear un contenedor en tiempo real
En este caso, se crea un contenedor en tiempo real y se asocian metadatos con el mismo. El propietario de contenido crea el contenedor en tiempo real en el gestor CON. Cuando se crea un contenedor en tiempo real, también se especifica la dirección del divisor en tiempo real para el flujo continuo en tiempo real.
El contenedor en tiempo real soporta crear, recuperar, actualizar y borrar llamadas a API (Applícatíon Programmíng Interface; interfaz de programación de aplicaciones) en un contenedor. El contenedor en tiempo real también soporta una diversidad de parámetros que permite al propietario de contenido (el cliente CON) establecer una serie de propiedades de distribución de contenido en el contenedor (es decir, fecha de inicio, fecha de finalización, geobloqueo, lista blanca, lista negra, formato del flujo continuo en tiempo real emitido, etc.). Una llamada a estadísticas en el contenedor recupera información estadística (bytes proporcionados por el flujo continuo CON en tiempo real).
Los metadatos para el tamaño de un segmento se definen en el momento en que se crea un contenedor. Para una explicación más sencilla, se usa un tamaño de segmento de 5 s. Además, se define una lista de reproducción de 12 segmentos. Así, una instancia de una lista de reproducción con una duración de un minuto tiene URL de 12 segmentos. Cada 30 s, se envía una lista de reproducción a los nodos de extremo. Este valor se elige para no sobrecargar el servidor original del flujo continuo en tiempo real para actualizar peticiones. Estos valores para duración de segmento y tamaño de lista de reproducción se usan con motivos ilustrativos únicamente y no restringen el alcance de la invención.
Además, se usa una API de nivel de archivo para gestionar el flujo continuo en tiempo real. Se usa una llamada a API de inicio/detención en un contenedor en tiempo real para o bien iniciar o bien detener un flujo continuo. Una llamada a API de estatus en un contenedor en tiempo real recupera el estatus actual de un flujo continuo en tiempo real.
Arquitectura de alto nivel para obtener el flujo continuo en tiempo real
En este caso, se describe una arquitectura de alto nivel para proporcionar un flujo continuo en tiempo real a un usuario final solicitante. La figura 1 muestra el diagrama secuencial para proporcionar un flujo continuo en tiempo real de este tipo.
En general, tres elementos CON están implicados en la distribución de un flujo continuo en tiempo real; el gestor CON, el divisor en tiempo real y el nodo de extremo.
El propietario de contenido crea un contenedor (o contenedor) en tiempo real y asocia metadatos con el contenedor. Esto se realiza a través del servidor de publicación en la CON del proveedor de servicios. El servidor de publicación se conecta con el gestor CON.
Una vez creado un contenedor en tiempo real, el gestor CON emite un comando al divisor en tiempo real para iniciar el flujo continuo en tiempo real. El divisor en tiempo real a su vez obtiene el flujo continuo en tiempo real de la fuente de flujo continuo en tiempo real. Cuando el divisor en tiempo real se pone en marcha, también inicia un segmentador. El segmentador está diseñado para crear segmentos a partir de un flujo continuo en tiempo real.
Una vez que el divisor en tiempo real se ha puesto en marcha, lanza un segmentador. El divisor en tiempo real empieza a descargar el flujo continuo desde la fuente de flujo continuo en tiempo real. El segmentador obtiene el flujo continuo en tiempo real en el divisor en tiempo real y genera segmentos a partir del flujo continuo en tiempo real recibido. Estos segmentos residen en un directorio de la máquina que alberga el divisor en tiempo real que a continuación actúa como servidor original para el flujo continuo en tiempo real. El divisor en tiempo real construye una lista de reproducción (que en realidad es una lista de URL) usando los segmentos creados a partir del flujo continuo en tiempo real. La lista de reproducción forma el contenido del archivo hdx.
Procesar el flujo continuo en tiempo real en el divisor en tiempo real y los nodos de extremo:
En este caso, se explican los detalles de cómo se procesa un flujo continuo en tiempo real en el divisor en tiempo real. El flujo continuo en tiempo real tiene un segmentador que se lanza una vez que se pone en marcha el divisor en tiempo real.
Una vez que el divisor en tiempo real obtiene un flujo continuo en tiempo real, pasa el
flujo continuo al segmentador.
Se divide una señal en tiempo real en el segmentador en segmentos, cada uno de 5 s de duración. Estos segmentos se usan para crear una lista de reproducción. Además, se crea un archivo de metainformación que tiene la siguiente información (a) tamaño de segmento (5 s), (b) primer y (e) último segmento, (d) tasa de transmisión de trama, (e) resolución, (f) tasa de transmisión de datos, etc. El divisor en tiempo real sirve como servidor original para flujos continuos en tiempo real.
Los segmentos, metadatos y la lista de reproducción se descargan por el nodo de extremo a través de su módulo de descarga. En el nodo de extremo, el módulo de flujo continuo en tiempo real implementa un planificador que tiene tres módulos, un predictor del punto de reproducción en tiempo real, un módulo gestor de descarga P2P y un módulo servidor de flujo continuo en tiempo real. El predictor del punto de reproducción en tiempo real estima el segmento actual y la posición actual del flujo continuo con respecto al punto de flujo continuo en tiempo real para un usuario final que recibe un flujo continuo en tiempo real. El módulo gestor de descarga P2P se usa para obtener los segmentos en la lista de reproducción generada por el segmentador. Este módulo implementa un planificador que usa una combinación de política egoísta y política del menos frecuente localmente. La política egoísta obtiene segmentos en el entorno inmediato de la posición de reproducción actual. La política del menos frecuente localmente obtiene los segmentos que se reproducirán algo después en el futuro y hay pocos nodos de extremo en el entorno que tengan el segmento. La política egoísta garantiza que el nodo de extremo continuará ateniendo la solicitud sin interrupción mientras que la política del menos frecuente localmente garantiza que el nodo de extremo es altruista respecto a los nodos de extremo de su entorno. Esto permite al nodo de extremo dar servicio a sus vecinos de modo que no sea necesario que cada nodo de extremo de entorno obtenga los segmentos del archivo hdx del servidor original (en el caso del flujo continuo en tiempo real, el divisor de flujo continuo).
Es preferible tener el divisor en tiempo real cerca del elemento de difusión que envía el flujo continuo para evitar una pérdida de calidad en la transmisión del flujo continuo en tiempo real.
Iniciar y detener un flujo continuo en tiempo real:
Tal como se observa en la figura 1, el divisor en tiempo real se encarga de
obtener el flujo continuo en tiempo real del propietario de contenido. Una vez que el tiempo actual supera el tiempo de inicio del flujo continuo en tiempo real se dispara un evento en el divisor en tiempo real. Una consecuencia de este disparo es que la petición de flujo continuo en tiempo real se envía al propietario de contenido y el divisor en tiempo real recibe un flujo continuo en tiempo real.
Cuando el tiempo actual supera el tiempo de finalización del flujo continuo en tiempo real, se dispara un evento en el divisor en tiempo real que da como resultado el cierre de la conexión entre el divisor en tiempo real y el propietario de contenido.
La deshabilitación por parte del propietario de contenido de un contenedor en tiempo real también deshabilita un flujo continuo en tiempo real y cierra la conexión con el propietario de contenido.
Cómo los nodos de extremo construyen el flujo continuo en tiempo real:
Los nodos de extremo obtienen los metadatos del contenedor en tiempo real una vez creado. Esto permite a los nodos de extremo que están configurados para proporcionar un flujo continuo en tiempo real identificar el servidor original para el flujo continuo en tiempo real. Para proporcionar un flujo continuo en tiempo real a usuarios finales solicitantes, un nodo de extremo debe obtener los segmentos del servidor original del flujo continuo en tiempo real o de otros nodos de extremo en el mismo centro de datos. Para ello, un nodo de extremo usa su gestor de entorno, su unidad de descarga y su módulo de transmisión en flujo continuo en tiempo real.
La unidad de descarga en un nodo de extremo es responsable de todo el acceso a Internet (ya sean los nodos de entorno o el servidor original). El gestor de entorno en un nodo de extremo mantiene una lista de todos sus vecinos (en el mismo centro de datos). El rastreador proporciona la lista de direcciones IP de entorno a un nodo de extremo. El gestor de entorno también hace un seguimiento de todos los vecinos que tienen un determinado archivo (o segmento como en el caso de la transmisión en flujo continuo en tiempo real). A continuación se describe con más detalle el módulo de transmisión en flujo continuo en tiempo real.
El nodo de extremo tiene tres submódulos, tal como muestra la figura 2, que forman parte del módulo de transmisión en flujo continuo en tiempo real: el predictor del punto de reproducción en tiempo real, el gestor de descarga P2P y el servidor de flujo continuo en tiempo real. A continuación se define la función de cada uno de los
módulos en la unidad de transmisión de flujo continuo en tiempo real en el nodo de
extremo.
Predictor del punto de reproducción en tiempo real: Este módulo es responsable de la obtención del archivo hdr desde el divisor en tiempo real. Este archivo hdr contiene toda la información de metadatos de cabecera sobre el contenido en tiempo real: la tasa de transmisión de trama, resolución, tasa de transmisión de datos, primer y último segmento, etc.
Este módulo también obtiene el archivo hdr desde el divisor en tiempo real periódicamente. Este archivo tiene una lista de URL que el gestor de descarga P2P usa para obtener los segmentos individuales. Este módulo también se usa para estimar el punto de reproducción en tiempo real actual en el flujo continuo. Esto es especialmente útil si el archivo hdx se pierde o retarda. La recepción de un archivo hdx nuevo sincroniza la estimación local del punto de reproducción en tiempo real actual respecto al punto de reproducción en tiempo real, real, en el divisor en tiempo real que actúa como servidor original para el flujo continuo en tiempo real.
Gestor de descarga P2P: El archivo hdx contiene una lista de URL (cada uno de una duración de 5 s). El módulo de transmisión en flujo continuo en tiempo real conoce la posición actual del flujo continuo en tiempo real, el segmento actual que está visualizando el usuario y el tamaño de la memoria intermedia. Basándose en esta información, el archivo hdx y la información de entorno, el gestor de descarga P2P planifica las descargas de segmentos según el algoritmo de planificación descrito en [23]. En este caso, la planificación se basa en una combinación de planificación egoísta (que obtiene los segmentos necesarios para la reproducción inmediata) y planificación del primero menos frecuente (el nodo de extremo descarga los segmentos que están menos replicados entre los nodos de extremo de su entorno).
La memoria intermedia permite a un usuario final realizar operaciones de OVO en un flujo continuo en tiempo real. La duración en la que un usuario final puede retroceder en un flujo continuo en tiempo real está limitada sólo por el tamaño de la memoria intermedia en el nodo de extremo.
Cuando el gestor de descarga P2P descarga un segmento, permite al gestor de entorno local conocer la existencia del segmento nuevo. El gestor de entorno local informa a todos los demás nodos de extremo dedicados a la transmisión en flujo continuo en tiempo real acerca de la existencia del segmento recibido recientemente. No todos los vecinos van al divisor en tiempo real (servidor original) para descargar
todos los archivos en el hdx. Con un retardo aleatorio de [0-1] segundos, cada uno de
los vecinos realiza una petición de cada archivo en el hdx entre sí.
La unidad de descarga comprueba en primer lugar si el archivo solicitado está disponible en los discos locales. Si no está disponible en el disco local, comprueba con el gestor de entorno desde qué vecino puede obtener los datos. Sólo como último paso obtiene la unidad de descarga los datos del servidor original. Si hay un gran número de vecinos, introduciendo el retardo aleatorio, este esquema permite a los vecinos obtener los archivos en el hdx en gran medida uno de otro sin que todos los nodos de extremo sobrecarguen el servidor original.
Servidor de flujo continuo en tiempo real: El servidor de flujo continuo en tiempo real obtiene los segmentos del módulo gestor de descarga P2P y los combina para formar un flujo continuo en tiempo real. Este flujo se proporciona entonces al (a los) usuario(s) final( es) solicitante(s).
Los nodos de extremo solicitan la lista de reproducción en el archivo hdx periódicamente (cada 30 s). Aunque la lista de reproducción enviada desde el divisor en tiempo real se pierda o retarde, el nodo de extremo puede predecir los URL de la lista de reproducción basándose en la petición recibida con éxito previa (y el tiempo requerido para reproducir los segmentos en la lista). En realidad, los nodos de extremo conocen el tamaño del anillo de memoria intermedia que almacena los URL y el punto de reproducción actual de la ventana deslizante de la lista de reproducción).
Una vez que el usuario final solicita un flujo continuo en tiempo real, el nodo de extremo que proporcionará el contenido se identifica mediante el servicio de DNS del proveedor de servicios CON. El nodo de extremo solicitará entonces el flujo continuo en tiempo real al servidor original (divisor en tiempo real) y a otros nodos de extremo en el mismo centro de datos.
¿Cómo proporciona un nodo de extremo un flujo continuo en tiempo real?
Una vez que un usuario final solicita un flujo continuo en tiempo real, el nodo de extremo comprueba en primer lugar los metadatos del contenedor en tiempo real. El nodo de extremo garantiza entonces que el usuario final satisface los siguientes criterios:
- -
- El nodo de extremo comprueba en primer lugar la dirección IP del usuario
final para asegurarse de que el usuario final no está sujeto a geobloqueo.
-El nodo de extremo realiza una comprobación para asegurarse de que la petición del usuario final de un flujo continuo en tiempo real se recibe entre los
metadatos de tiempo de inicio y tiempo de finalización especificados para el
contenedor en tiempo real.
Una vez satisfechos los criterios anteriores, el nodo de extremo está listo para dar servicio a los usuarios finales solicitantes. El nodo de extremo ya tiene la dirección del divisor en tiempo real a partir de los metadatos del contenedor en tiempo real. Puesto que el divisor en tiempo real sirve como servidor original para el flujo continuo en tiempo real, el nodo de extremo realiza una petición del flujo continuo. Si un usuario final llega después del tiempo de finalización de un evento en tiempo real, la petición del flujo continuo en tiempo real se rechaza con un mensaje de error generado por el nodo de extremo.
Al recibir una petición de flujo continuo en tiempo real válida, el nodo de extremo obtiene en primer lugar el archivo hdr y obtiene periódicamente archivos hdx actualizados desde el divisor en tiempo real. El nodo de extremo construye entonces el flujo continuo en tiempo real tal como se comentó anteriormente y proporciona el flujo continuo al usuario final solicitante.
Realizar operaciones de OVO en un flujo continuo en tiempo real:
El nodo de extremo mantiene una memoria intermedia del flujo continuo en tiempo real. Esto permite a un usuario final realizar operaciones de OVO (retroceder para ver de nuevo un punto interesante en el evento) incluso en un flujo continuo en tiempo real. La duración durante la que un usuario final puede retroceder en el tiempo está limitada por el tamaño de la memoria intermedia en el nodo de extremo. Este tamaño de memoria intermedia es en realidad el mínimo de la memoria intermedia en el divisor en tiempo real y el nodo de extremo de servicio.
Una vez que un usuario final realiza operaciones de OVO (vuelve en el tiempo) en un flujo continuo en tiempo real, se reinicia el punto de reproducción actual. Sin embargo, el punto de reproducción en tiempo real actual del flujo continuo sigue avanzando (al igual que el último segmento que puede almacenarse en la memoria intermedia). Basándose en el algoritmo de [23] el gestor de descarga P2P descargará segmentos usando una estrategia que usa una combinación híbrida de política egoísta y política del menos frecuente localmente para planificar las descargas de segmentos basándose en el segmento actual que está reproduciéndose (y el tiempo de reproducción esperado de segmentos posteriores).
¿Qué sucede cuando el último usuario final abandona un nodo de extremo?
El nodo de extremo mantiene un recuento de referencia para todos los usuarios
finales que están visualizando un flujo continuo en tiempo real. Una vez que un usuario
final abandona (deja de visualizar) un flujo continuo en tiempo real, el nodo de extremo
cierra el socket con el usuario final y reduce el recuento de referencia para el flujo
continuo en tiempo real. Cuando el recuento de referencia es igual a cero, el nodo de extremo deja de
obtener el contenido de flujo en tiempo real del divisor en tiempo real.
El diseño de sistema tiene una serie de ventajas:
- -
- Al dividir un flujo continuo en tiempo real y crear una lista de reproducción, crea la impresión de obtener el archivo de un contenedor en un nodo de extremo.
- -
- Uso de algoritmos P2P (de múltiples fuentes) que permiten a los nodos de extremo en un centro de datos obtener segmentos del flujo continuo de vídeo unos de otros. Esto reduce significativamente la carga en el divisor en tiempo real (que sirve como servidor original para el flujo continuo en tiempo real).
- -
- El diseño del sistema de transmisión en flujo continuo en tiempo real usado en la CON es un sistema híbrido; usa P2P para obtener contenido de otros nodos de extremo cuando es posible y del divisor en tiempo real (el servidor original) cuando es necesario.
- -
- Al mantener una memoria intermedia en un flujo continuo en tiempo real en los nodos de extremo, se permite a un usuario final realizar operaciones de OVO en un flujo continuo en tiempo real (pausa, retroceder en el tiempo, etc.).
- -
- Al mantener una memoria intermedia en un flujo continuo en tiempo real en el divisor en tiempo real, los nodos de extremo pueden obtener contenido del divisor en tiempo real en respuesta a operaciones de OVO en un flujo continuo en tiempo real por parte de un usuario final.
-Uso de HTTP como mecanismo de transporte para entregar el flujo continuo
en tiempo real desde un nodo de extremo a usuarios finales solicitantes.
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 Une; Línea de abonado digital asimétrica
- CON
- Content Distribution Network; Red de distribución de contenido
- DNS
- Domain Name Service; Servidor de nombres de dominio
- PoP
- Point of Presence; Punto de presencia
- URL
- Uniform Resource Locator; Localizador uniforme de recursos
Bibliografía
[1] S. Annapureddy, S. Guha, C. Gkantsidis, D. Gunawardena y P. Rodriguez. ls High-Quality VoD feasible using P2P Swarming. En WWW, 2007.
[2] B. Cheng, H. Jin y X. Liao. Supporting VCR functions in P2P VoD Services Using Ring-Assisted Overlays. En ICC, 2007.
[3] Y. Huang, T. Z. J. Fu, D.M. Chiu, J.C.S. Lui y C. Huang. Challenges, Design and Analysis of a Large-scale P2P VoD System. En Proc. of Sigcomm, 2008.
[4] A. Hu. Video-on-demand broadcasting protocols: A comprehensive study. En IEEE lnfocom, 2001.
[5] K. Almeroth, y M. Ammar. On the use of multicast delivery to provide a scalable and interactive Video-on Demand service. En Journal of Selected Areas in Communications, 1996.
[6] Y. Zhou, D. Chiu y J. Lui. A Simple Model for Analyzing P2P Streaming Protocols. En Proc. of ICNP, 2007.
[7] N. Vratonjic, P. Gupta, N. Knezevic, D. Kostic, A. Rowstron. Enabling DVD-Iike features in P2P Video-on-Demand-Systems. En ACM P2P-TV Workshop, 2007.
[8] A. Vahdat, K. Yocum, K. Walsh, P. Mahadevan, D. Kosti, J. Chase, D. Becker Scalability and Accuracy in a Large-Scale Network Emulator En Proc. of OSDI, 2002.
[9] C. Jin, Q. Chen, S. Jamin. lnet: Internet topology generator. Univ. de Michigan TR CSE-TR-433-00, 2000.
[1 O] C. Dana, D. Ll, D. Harrison, y C. Chuah. BASS: Bit-Torrent assisted streaming system for video-on-demand. MMSP, 2005.
[11] A. Vlavianos, M. lliofotou, y M. Faloutsos Enhancing BitTorrent for supporting streaming applications. En IEEE Global Internet, 2006.
[12] B. Cheng, X. Liu, Z. Zhang, y H. Jin. A Measurement Study of a Peer-to-Peer Video-on-Demand System. IPTPS 2007.
[13] P. Marciniak, N. Liogkas, A. Legout, E Kohler, quot;Small ls Not Always Beautiful,quot; En Proc. of IPTPS, 2008.
[14] Yung Ryn Choe, Derek L. Schuff, Jagadeesh M. Dyaberi, Vijay S. Pai,
lmproving VoD server efficiency with bittorrent En Proc. of IEEE Multimedia 5 2007.
[15] J.J.D. Mol, J.A. Pouwelse, M. Meulpolder, D.H.J. Epema, y H.J. Sips, Give-to-Get: Free-riding-resilient Video-on-Demand in P2P Systems, MMCN08
[16] Rawflow. En http:/ /en. wikipedia.org/wiki/Rawflow y http://www.rawflow.com
10 [17] Windows Media Services. En http://en.wikipedia.org/wiki/Windows_Media_Services y http://www.microsoft.com/windows/windowsmedia/forpros/server/server.aspx
[18] Adobe Flash Media Server Family,
http://www.adobe.com/products/flashmediaserver/ 15 [19] Youtube. En http://www.youtube.com
[20] Netflix. En http://www.netflix.com
[21] X. Yang, M. Gjoka, P. Chhabra, A. Markopoulou, y P. Rodriguez, quot;Kangaroo: Video Seeking in P2P Systemsquot;, En Proc. of IPTPS'09, Boston, EE.UU., abril de 2009
20 [22] Octoshape. En http://www.octoshape.com y http://en.wikipedia.org/wiki/Octoshape
[23] EP09382307.8, Method for Downloading Segments of a Video File in a Peer-To-Peer Network
Claims (21)
- REIVINDICACIONES
- 1.
- Método para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido, que comprende proporcionar, una entidad de dicha red de distribución de contenido, o CON, un flujo continuo en tiempo real solicitado a al menos un usuario final, estando el método caracterizado porque la gestión y entrega de dicho flujo continuo en tiempo real solicitado se realiza usando una arquitectura basada en P2P, en el que los iguales son nodos de extremo o servidores de contenido de dicha CON que intercambian contenido entre sí, y en el que la entrega de dicho flujo continuo en tiempo real solicitado a dicho al menos un usuario final se realiza desde al menos uno de dichos puntos finales, o nodo de extremo de servicio.
-
- 2.
- Método según la reivindicación 1, en el que dichos nodos de extremo iguales están ubicados en el mismo centro de datos.
-
- 3.
- Método según la reivindicación 1 ó 2, que comprende obtener, dicho nodo de extremo, dicho flujo continuo en tiempo real solicitado por fragmentos o segmentos en los que previamente se ha dividido el flujo continuo en tiempo real.
-
- 4.
- Método según la reivindicación 3, que comprende obtener, dicho nodo de extremo, dichos segmentos de un flujo continuo en tiempo real desde un servidor original y/o desde nodos de extremo de entorno.
-
- 5.
- Método según la reivindicación 4, en el que dicho servidor original es un divisor en tiempo real que comprende un segmentador, y comprendiendo el método dividir dicho flujo continuo en tiempo real por medio de dicho segmentador.
-
- 6.
- Método según la reivindicación 5, que comprende generar una lista de reproducción de enlaces o URL de dichos segmentos por medio de dicho segmentador, y obtener, dicho nodo de extremo, dichos segmentos a través de dichos enlaces de la lista de reproducción.
-
- 7.
- Método según la reivindicación 6, que comprende descargar, dicho al menos un nodo de extremo de servicio, dicha lista de reproducción de dicho divisor en tiempo real.
-
- 8.
- Método según la reivindicación 6, que comprende reenviar, dicho divisor en tiempo real, dicha lista de reproducción a dicho al menos un nodo de extremo de servicio.
-
- 9.
- Método según la reivindicación 8, en el que dichos enlaces de la lista de
reproducción se refieren sólo a parte de los segmentos de todo el flujo continuo en tiempo real, comprendiendo el método generar una nueva lista de reproducción con URL de nuevos segmentos y reenviar periódicamente dicha nueva lista de reproducción a cada uno de los nodos de extremo de servicio como una actualización enviada o bien tras una petición o bien automáticamente.1O. Método según la reivindicación 7, 8 ó 9, que comprende: -crear, un propietario de contenido o cliente CON, un contenedor o contenedor en tiempo real, y asociar metadatos con el contenedor, asignar el URL del flujo continuo en tiempo real y la dirección del divisor en tiempo real a los metadatos de dicho contenedor en tiempo real; -emitir, el gestor CON del proveedor de servicios CON, un comando a dicho divisor en tiempo real para iniciar el flujo continuo en tiempo real una vez creado dicho contenedor en tiempo real; -el divisor en tiempo real, tras la recepción de dicho comando,:- -
- lanzar el segmentador; -comenzar con la descarga del flujo continuo en tiempo real desde el URL proporcionado por el propietario de contenido y reenviar el flujo continuo en tiempo real recibido al segmentador; -crear y almacenar los segmentos del flujo continuo en tiempo real en el segmentador, generar una lista de reproducción a partir de dichos segmentos y crear un archivo de cabecera de metainformación;
- -
- descargar, al menos un nodo de extremo de servicio, dicha lista de reproducción del flujo continuo en tiempo real, los segmentos de la lista de reproducción y dicho archivo de cabecera de metainformación desde el divisor en tiempo real y recibir actualizaciones periódicas de URL de la lista de reproducción desde el divisor en tiempo real.
- 11. Método según la reivindicación 1O, que comprende cerrar dicha conexión establecida al dispararse cualquiera de los siguientes eventos: -que el tiempo actual en el divisor en tiempo real supere el tiempo de finalización del flujo continuo en tiempo real especificado por el propietario de contenido en los metadatos de contenedor del flujo continuo en tiempo real; -que dicho flujo continuo en tiempo real se detenga porque el propietario de contenido deshabilite dicho contenedor en tiempo real a través de los metadatos de contenedor;
- -
- que el contenedor en tiempo real supere la duración durante la que puede
estar activo especificada por el propietario de contenido en los metadatos decontenedor. - 12. Método según la reivindicación 1O, en el que dicho archivo de cabecera de metainformación tiene al menos la siguiente información: tamaño de segmento, tasa de transmisión de trama del primer y el último segmento, resolución y tasa de transmisión de datos.
- 13. Método según la reivindicación 1 O ó 12, en el que dicho al menos un nodo de extremo de servicio comprende: -usar un módulo predictor del punto de reproducción en tiempo real para: -estimar el segmento y la posición del flujo continuo actualmente en reproducción con respecto al punto de flujo continuo en tiempo real, y -obtener dicho archivo de cabecera de metainformación como un archivo hdr y dicha lista de reproducción como URL de segmentos como un archivo hdx desde el divisor en tiempo real;
- -
- obtener los segmentos indicados en la lista de reproducción a la manera de P2P usando un módulo gestor de descarga que usa un algoritmo de planificación que usa información sobre segmentos presentes en otros nodos de extremo de su gestor de entorno y que también usa la información proporcionada por dicho módulo predictor del punto de reproducción en tiempo real, dicho archivo hdr, información sobre el tamaño de la memoria intermedia prevista para almacenar los segmentos; y -combinar los segmentos recibidos para formar un flujo continuo en tiempo real y proporcionar el flujo continuo a los usuarios finales solicitantes por medio de un módulo servidor de flujo continuo en tiempo real.
-
- 14.
- Método según la reivindicación 13, en el que dicho algoritmo de planificación usado por dicho módulo de gestor de descarga P2P en un nodo de extremo se basa en una combinación de planificación egoísta para obtener los segmentos necesarios para la reproducción inmediata, y planificación del primero menos frecuente para descargar los segmentos que están menos replicados entre los nodos de extremo de su entorno.
-
- 15.
- Método según la reivindicación 13 ó 14, que comprende comprobar, dicho módulo de gestor de descarga P2P, en primer lugar si el segmento solicitado
- 16.
-
- 17.
-
- 18.
-
- 19.
- 20.está disponible en sus discos locales, y si no está disponible: -comprobar qué nodo de extremo de entorno tiene dicho segmento, y:
- -
- descargar el segmento requerido desde un nodo de extremo de
entorno que tenga el segmento, o- -
- si ningún nodo de extremo de entorno tiene dicho segmento requerido,
descargar el segmento del divisor en tiempo real que actúa comoservidor original para el flujo continuo en tiempo real. Método según la reivindicación 15, que comprende usar, varios nodos de extremo participan en la transmisión en flujo continuo en tiempo real, cada uno sus módulos de gestor de descarga P2P respectivos para descargar segmentos unos de otros después de un retardo aleatorio pequeño e ir al servidor original del flujo continuo en tiempo real para descargar segmentos sólo como último recurso para garantizar una reproducción continua para un usuario final. Método según cualquiera de las reivindicaciones 13 a 16, que comprende informar, dicho módulo gestor de descarga P2P, al descargar un nuevo segmento, a los nodos de extremo de su entorno acerca de la existencia del nuevo segmento usando dicho módulo gestor de entorno. Método según la reivindicación 13, que comprende dimensionar dicha memoria intermedia prevista para almacenar los segmentos recibidos en el nodo de extremo para permitir que un usuario final realice operaciones de OVO en el flujo continuo en tiempo real proporcionado al mismo, incluyendo operaciones de rebobinado hasta el tamaño de la memoria intermedia. Método según la reivindicación 13, que comprende obtener, dicho módulo predictor del punto de reproducción en tiempo real de dicho nodo de extremo de servicio, dicho archivo de cabecera de metainformación una vez creado un contenedor en tiempo real por dicho propietario de contenido CON e iniciar, el divisor en tiempo real, el flujo continuo en tiempo real. Método según la reivindicación 19, que comprende proporcionar, dicho nodo de extremo, el flujo continuo en tiempo real a un usuario final solicitante sólo si no está sujeto a geobloqueo y la petición del usuario final de un flujo continuo en tiempo real se recibe entre los metadatos de tiempo de inicio y de tiempo de finalización del contenedor en tiempo real especificados por el propietario de contenido. - 21. Método según cualquiera de las reivindicaciones anteriores, que comprende identificar el nodo de extremo que proporcionará el contenido solicitado a través del servicio de DNS de la CON en respuesta a un usuario final que solicita un flujo continuo en tiempo real.5 22. Método según la reivindicación 1 O, que comprende mantener, dicho nodo de extremo de servicio, un recuento de referencia para todos los usuarios finales que visualizan el flujo continuo en tiempo real proporcionado, y: -una vez que un nodo de extremo empieza a dar servicio a un usuario final solicitante, aumentar el recuento de referencia para ese flujo continuo en10 tiempo real en el nodo de extremo, y -una vez que un usuario final abandona un flujo continuo en tiempo real, cerrar el nodo de extremo que proporciona el flujo continuo en tiempo real, la conexión de socket con el usuario final y reducir dicho recuento de referencia para el flujo continuo en tiempo real en dicho nodo de extremo, y15 -una vez que el recuento de referencia para un flujo continuo en tiempo real es igual a cero, dejar de obtener, el nodo de extremo que recibe el flujo continuo en tiempo real, el contenido de flujo continuo en tiempo real desde el divisor en tiempo real.
- 23. Nodo de extremo para una red de distribución de contenido, caracterizado20 porque comprende un módulo de flujo continuo en tiempo real que implementa un planificador que incluye un módulo predictor del punto de reproducción en tiempo real, un módulo gestor de descarga P2P y un módulo servidor de flujo continuo en tiempo real, para distribuir flujo continuo de contenido en tiempo real realizando las acciones del método según la reivindicación 13.
Priority Applications (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
ES201130760A ES2429222B1 (es) | 2011-05-12 | 2011-05-12 | Método y nodo de extremo para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido |
BR112013028992A BR112013028992A2 (pt) | 2011-05-12 | 2012-05-09 | método para distribuir fluxo de conteúdo ao vivo em uma rede de liberação de conteúdo e sistema para distribuir fluxo de conteúdo ao vivo em uma rede de liberação de conteúdo para implementar um método |
EP12721479.9A EP2708009A1 (en) | 2011-05-12 | 2012-05-09 | Method and end point for distributing live content stream in a content delivery network |
PCT/EP2012/058515 WO2012152817A1 (en) | 2011-05-12 | 2012-05-09 | Method and end point for distributing live content stream in a content delivery network |
US14/116,855 US20140165118A1 (en) | 2011-05-12 | 2012-05-09 | Method and end point for distributing live content stream in a content delivery network |
ARP120101651A AR086340A1 (es) | 2011-05-12 | 2012-05-10 | Metodo y nodo de extremo para distribuir flujo continuo de contenido en tiempo real en una red de distribucion de contenido |
CL2013003224A CL2013003224A1 (es) | 2011-05-12 | 2013-11-11 | Metodo y nodo de extremo para distribuir flujo continuo de contenido en tiempo real en una red de distribucion de contenido donde el metodo comprende la gestion y entrega de un flujo continuo en tiempo real solicitado usando una arquitectura basada en p2p, en el que los iguales que intercambian contenido entre sí son nodos de extremo de una cdn. |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
ES201130760A ES2429222B1 (es) | 2011-05-12 | 2011-05-12 | Método y nodo de extremo para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido |
Publications (2)
Publication Number | Publication Date |
---|---|
ES2429222A1 true ES2429222A1 (es) | 2013-11-13 |
ES2429222B1 ES2429222B1 (es) | 2014-06-05 |
Family
ID=46085934
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES201130760A Withdrawn - After Issue ES2429222B1 (es) | 2011-05-12 | 2011-05-12 | Método y nodo de extremo para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido |
Country Status (7)
Country | Link |
---|---|
US (1) | US20140165118A1 (es) |
EP (1) | EP2708009A1 (es) |
AR (1) | AR086340A1 (es) |
BR (1) | BR112013028992A2 (es) |
CL (1) | CL2013003224A1 (es) |
ES (1) | ES2429222B1 (es) |
WO (1) | WO2012152817A1 (es) |
Families Citing this family (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6030572B2 (ja) * | 2011-01-04 | 2016-11-24 | トムソン ライセンシングThomson Licensing | ライブメディアコンテンツを送信する装置及び方法 |
US20160057185A1 (en) * | 2013-03-21 | 2016-02-25 | Telefonaktiebolaget L M Ericsson (Publ) | Streaming Service Provision Support in a P2P-CDN Streaming System |
US20140351871A1 (en) * | 2013-05-22 | 2014-11-27 | Microsoft Corporation | Live media processing and streaming service |
US8718445B1 (en) | 2013-09-03 | 2014-05-06 | Penthera Partners, Inc. | Commercials on mobile devices |
US9244916B2 (en) * | 2013-10-01 | 2016-01-26 | Penthera Partners, Inc. | Downloading media objects |
KR20150041253A (ko) * | 2013-10-07 | 2015-04-16 | 한국전자통신연구원 | 디지털 디스플레이 단말, 컨텐츠 서버, 및 컨텐츠 송수신 방법 |
TWI533678B (zh) * | 2014-01-07 | 2016-05-11 | 緯創資通股份有限公司 | 即時轉播同步方法以及使用該方法的系統 |
US9432431B2 (en) * | 2014-03-18 | 2016-08-30 | Accenture Global Servicse Limited | Manifest re-assembler for a streaming video channel |
US9923951B2 (en) * | 2014-03-26 | 2018-03-20 | Sling Media L.L.C. | Placeshifting recommendations using geolocation and related systems and methods |
US9614724B2 (en) | 2014-04-21 | 2017-04-04 | Microsoft Technology Licensing, Llc | Session-based device configuration |
US9384334B2 (en) | 2014-05-12 | 2016-07-05 | Microsoft Technology Licensing, Llc | Content discovery in managed wireless distribution networks |
US10111099B2 (en) | 2014-05-12 | 2018-10-23 | Microsoft Technology Licensing, Llc | Distributing content in managed wireless distribution networks |
US9384335B2 (en) | 2014-05-12 | 2016-07-05 | Microsoft Technology Licensing, Llc | Content delivery prioritization in managed wireless distribution networks |
US9430667B2 (en) | 2014-05-12 | 2016-08-30 | Microsoft Technology Licensing, Llc | Managed wireless distribution network |
US9874914B2 (en) | 2014-05-19 | 2018-01-23 | Microsoft Technology Licensing, Llc | Power management contracts for accessory devices |
US10069730B2 (en) | 2014-06-03 | 2018-09-04 | Disney Enterprises, Inc. | Systems and methods for predictive delivery of high bit-rate content for playback |
US10037202B2 (en) | 2014-06-03 | 2018-07-31 | Microsoft Technology Licensing, Llc | Techniques to isolating a portion of an online computing service |
US9367490B2 (en) | 2014-06-13 | 2016-06-14 | Microsoft Technology Licensing, Llc | Reversible connector for accessory devices |
US10452837B1 (en) * | 2014-09-26 | 2019-10-22 | Amazon Technologies, Inc. | Inbound link handling |
US10511864B2 (en) | 2016-08-31 | 2019-12-17 | Living As One, Llc | System and method for transcoding media stream |
US11412272B2 (en) | 2016-08-31 | 2022-08-09 | Resi Media Llc | System and method for converting adaptive stream to downloadable media |
US9602846B1 (en) | 2016-08-31 | 2017-03-21 | Living As One, Llc | System and method for asynchronous uploading of live digital multimedia with guaranteed delivery |
KR102135737B1 (ko) * | 2017-06-19 | 2020-08-26 | 한국전자통신연구원 | 피어 및 피어의 시작 지점 조정 방법 |
US11704300B2 (en) * | 2017-06-23 | 2023-07-18 | Charter Communications Operating, Llc | Apparatus and methods for packetized data management and delivery in a digital content distribution network |
CN109819004B (zh) * | 2017-11-22 | 2021-11-02 | 中国人寿保险股份有限公司 | 用于部署多活数据中心的方法和*** |
CN108924609B (zh) * | 2018-07-13 | 2021-06-29 | 广州虎牙信息科技有限公司 | 流媒体数据传输的方法、电子设备、装置及存储介质 |
US11083961B2 (en) * | 2018-12-21 | 2021-08-10 | Universal City Studios Llc | Scalable interactive video systems and methods |
TR201909266A2 (tr) * | 2019-06-21 | 2019-07-22 | Medianova Internet Hizmetleri Ve Ticaret Anonim Sirketi | İçerik Dağıtım Ağlarına Uyumlu Çalışan Bir Medya Akış Sistemi |
CN111556324B (zh) * | 2020-04-04 | 2022-05-10 | 网宿科技股份有限公司 | 一种视频直播的方法、装置、设备及*** |
CN116939233A (zh) * | 2022-04-08 | 2023-10-24 | 腾讯科技(深圳)有限公司 | 直播视频处理方法、装置、设备、存储介质及计算机程序 |
CN116916048B (zh) * | 2023-09-07 | 2023-11-17 | 典基网络科技(上海)有限公司 | 一种用于流媒体传输优化的混合架构、方法、设备和介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008017502A1 (en) * | 2006-08-11 | 2008-02-14 | Velocix Limited | Content distribution network |
EP2028804A1 (en) * | 2007-04-03 | 2009-02-25 | Huawei Technologies Co., Ltd. | Media delivery system, apparatus and stream media playing method |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
TW443064B (en) | 1998-02-19 | 2001-06-23 | Canon Kk | Image sensor |
US7136662B2 (en) * | 2000-02-02 | 2006-11-14 | Ntt Docomo, Inc. | Wireless base station, method of selecting wireless base station, method of multicasting, and wireless terminal |
US7633887B2 (en) * | 2005-01-21 | 2009-12-15 | Panwar Shivendra S | On demand peer-to-peer video streaming with multiple description coding |
US8909806B2 (en) * | 2009-03-16 | 2014-12-09 | Microsoft Corporation | Delivering cacheable streaming media presentations |
FR2959372A1 (fr) * | 2010-04-23 | 2011-10-28 | Orange Vallee | Procede et systeme de gestion d'une session de diffusion en continu d'un flux video affiche en direct |
WO2012065186A2 (en) * | 2010-11-12 | 2012-05-18 | Realnetworks, Inc. | Traffic management in adaptive streaming protocols |
WO2012154287A2 (en) * | 2011-02-28 | 2012-11-15 | Bittorrent, Inc. | Peer-to-peer live streaming |
-
2011
- 2011-05-12 ES ES201130760A patent/ES2429222B1/es not_active Withdrawn - After Issue
-
2012
- 2012-05-09 EP EP12721479.9A patent/EP2708009A1/en not_active Withdrawn
- 2012-05-09 US US14/116,855 patent/US20140165118A1/en not_active Abandoned
- 2012-05-09 BR BR112013028992A patent/BR112013028992A2/pt not_active IP Right Cessation
- 2012-05-09 WO PCT/EP2012/058515 patent/WO2012152817A1/en active Application Filing
- 2012-05-10 AR ARP120101651A patent/AR086340A1/es not_active Application Discontinuation
-
2013
- 2013-11-11 CL CL2013003224A patent/CL2013003224A1/es unknown
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008017502A1 (en) * | 2006-08-11 | 2008-02-14 | Velocix Limited | Content distribution network |
EP2028804A1 (en) * | 2007-04-03 | 2009-02-25 | Huawei Technologies Co., Ltd. | Media delivery system, apparatus and stream media playing method |
Also Published As
Publication number | Publication date |
---|---|
CL2013003224A1 (es) | 2014-08-01 |
BR112013028992A2 (pt) | 2017-02-07 |
AR086340A1 (es) | 2013-12-04 |
ES2429222B1 (es) | 2014-06-05 |
US20140165118A1 (en) | 2014-06-12 |
EP2708009A1 (en) | 2014-03-19 |
WO2012152817A1 (en) | 2012-11-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2429222B1 (es) | Método y nodo de extremo para distribuir flujo continuo de contenido en tiempo real en una red de distribución de contenido | |
Anjum et al. | Survey on peer-assisted content delivery networks | |
WO2021213184A1 (zh) | 一种基于分布式选举的端到端内容分发网络***和分发方法 | |
CN110336843B (zh) | 一种用于众包的内容分发方法、中心节点及边缘节点 | |
US7908389B2 (en) | Methods and systems for retrieving fragments from peer clients and servers | |
Buford et al. | P2P networking and applications | |
KR101549803B1 (ko) | 피어-투-피어 콘텐츠 배포 시스템에서 피어-수신된 콘텐츠의 완전성 검증 | |
US20140280604A1 (en) | Adaptive distributed application streaming | |
JP2023510272A (ja) | 特定ネットワークデバイス並びに特定ローカルエリアネットワークの接続、コンテンツ発見、データ転送、及び制御方法 | |
Li et al. | Peerstreaming: design and implementation of an on-demand distributed streaming system with digital rights management capabilities | |
Tian et al. | A novel caching mechanism for peer-to-peer based media-on-demand streaming | |
KR101144331B1 (ko) | 시간 기반의 메쉬 오버레이 네트워크 시스템 및 이를 이용한 메쉬 오버레이 네트워크 구축 방법 | |
Johnsen et al. | Peer-to-peer networking with BitTorrent | |
Lareida et al. | Augmenting home routers for socially-aware traffic management | |
Wang et al. | SmartPeerCast: a Smart QoS driven P2P live streaming framework | |
Yang et al. | A novel on-demand streaming service based on improved BitTorrent | |
Birman et al. | Network perspective | |
Sze | Providing robust and cost-effective large-scale video-on-demand services in networks | |
Talaei et al. | Adding multimedia streaming to BitTorrent | |
Koulouris | A framework for the dynamic management of Peer-to-Peer overlays | |
Olavarrieta et al. | Large scale distributed storage and search for a video on demand streaming system | |
PRIYANKA et al. | Agent Based Content Distribution of Online Forums using P2P Assisted Multimedia Sharing | |
Jeon | Optimization Strategies for Qos-Sensitive VOD Service Delivery in Cooperative Environments | |
Wang et al. | Is playing-as-downloading feasible in an eMule P2P file sharing system? | |
Dony | Video-on-Demand over Internet |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FG2A | Definitive protection |
Ref document number: 2429222 Country of ref document: ES Kind code of ref document: B1 Effective date: 20140605 |
|
FA2A | Application withdrawn |
Effective date: 20141015 |