ES2907064T3

ES2907064T3 - Protocolo de transporte para contenido anticipado

Info

Publication number: ES2907064T3
Application number: ES19211651T
Authority: ES
Inventors: William B Sebastian
Original assignee: Viasat Inc
Current assignee: Viasat Inc
Priority date: 2011-06-14
Filing date: 2012-06-14
Publication date: 2022-04-21
Anticipated expiration: 2032-06-14
Also published as: US9935740B2; EP3633918A1; US20220123866A1; EP2536065B1; US11139919B2; EP3633918B1; US20120320916A1; ES2774203T3; PT3633918T; EP4024760A1; EP2536065A3; US20150036686A1; EP2536065A2; US20180294923A1; US11777654B2; US8897302B2

Abstract

Un método para el funcionamiento en un sistema (100) de comunicaciones de multidifusión que tiene una trayectoria de comunicaciones entre un servidor (150) de contenido en un lado de servidor del sistema de comunicaciones y primer y segundo sistemas (110b,110m) de usuario en un lado de cliente del sistema de comunicaciones a través de un sistema (120) de servidor en el lado de servidor del sistema de comunicaciones, comprendiendo la trayectoria de comunicaciones un enlace directo compartido a través del que se comparten recursos de ancho de banda, comprendiendo el método: recibir (180), en el segundo sistema de usuario, un objeto a partir de una multidifusión (162) desde el lado de servidor a través de la trayectoria de comunicaciones, habiendo sido solicitado (160) el objeto por el primer sistema de usuario; almacenar (182), por el segundo sistema de usuario, el objeto recibido; en respuesta a una solicitud del objeto en el segundo sistema de usuario, enviar (184), por el segundo sistema de usuario a través de la trayectoria de comunicaciones al lado de servidor, una solicitud del objeto; recibir (186), en el segundo sistema de usuario a través de la trayectoria de comunicaciones desde el lado de servidor, datos de corrección de errores como parte de un segundo mensaje de reparación de objeto, comprendiendo el segundo mensaje de reparación de objeto y un primer mensaje de reparación de objeto cada uno individualmente información de reparación para un bloque de datos del objeto, habiéndose comunicado el primer mensaje de reparación de objeto previamente al primer sistema de usuario por el sistema de servidor después de la recepción en el sistema de servidor de un mensaje (170) de fiabilidad del primer sistema de usuario que identifica el bloque de datos del objeto en el que se ha identificado un error o una omisión; e integrar, en el segundo sistema de usuario, los datos de corrección de errores con el objeto almacenado para crear un objeto completamente comprobado en cuanto a errores que puede ser usado por el segundo sistema de usuario.

Description

DESCRIPCIÓN

Protocolo de transporte para contenido anticipado

Antecedentes

La presente descripción se refiere, generalmente, a comunicaciones y, pero no de forma excluyente, a la fiabilidad dentro de un protocolo de transporte para su uso en un sistema con un sistema de comunicaciones de multidifusión.

En algunas topologías de sistemas de comunicaciones, los grupos de usuarios comparten algunos o todos los enlaces directos e inversos. Por ejemplo, en algunos sistemas de comunicaciones por satélite, los usuarios comparten haces puntuales para comunicarse con un proveedor de servicios (p. ej., mediante una estación de base y/o puerta de enlace). En algunos sistemas de comunicación por cable, los usuarios comparten el ancho de banda en partes del sistema de comunicación cercanas o en la conexión de usuario o doméstica. Los servicios de comunicación suministrados a los usuarios a través del enlace directo compartido y los correspondientes enlaces inversos pueden verse afectados por un número de factores, incluyendo el ancho de banda y otras condiciones de enlace. Por ejemplo, dado que todos los usuarios que comparten el enlace directo también comparten el ancho de banda del enlace, cualquier redundancia innecesaria en las comunicaciones puede provocar la utilización insuficiente del enlace directo. De manera similar, en muchos sistemas todos los usuarios que comparten el enlace directo también comparten un enlace inverso que puede usarse para la fiabilidad y el control de errores, por lo que cualquier redundancia innecesaria en la comunicación, la fiabilidad y el control de errores puede provocar, además, el uso insuficiente del enlace inverso.

La utilización eficaz del ancho de banda es beneficiosa en un enlace inverso cuando no resulta posible la multidifusión eficaz en la dirección inversa. Por ejemplo, cuando el contenido se transmite en multidifusión desde una sola fuente de contenido a 1000 usuarios, el enlace inverso de 1000 usuarios a la única fuente de contenido puede incluir, de manera regular, información duplicada. Se conocen algunos métodos de uso más eficaz de un canal inverso. Por ejemplo, la designación de jerarquías de usuarios que se comunican entre sí antes de usar el canal inverso con el fin de identificar redundancias es un ejemplo de la mejora de la eficacia de un canal inverso. Otros métodos para la mejora de la eficacia usan temporizadores de retroceso para retardar el uso de un canal inverso en algunos usuarios para ver si una respuesta a la solicitud de usuarios se transmite en multidifusión basándose en una solicitud de un segundo usuario antes de que el primer usuario envíe la solicitud.

El uso de negative acknowledgement (confirmación negativa - NACK) para la comprobación de errores y la fiabilidad es otra manera de reducir el uso de un canal inverso en la multidifusión, especialmente cuando se combina con las otras técnicas mencionadas anteriormente. El protocolo de NACK oriented reliable multicast (multidifusión fiable orientada a NACK - NORM) usa la confirmación negativa para fijar normas de fiabilidad en un entorno de multidifusión. El NORM y todos los métodos usados anteriormente incluyen limitaciones de escala. Tales métodos pueden disminuir el uso de un canal inverso, pero el uso de canal inverso todavía sigue siendo un factor limitante en determinados entornos de multidifusión.

US 2010/0177642 A1 describe sistemas para utilizar un sistema de comunicaciones proporcionado a través de técnicas denominadas “deltadifusión” . Algunas realizaciones usan un optimizador del lado de servidor para interceptar y crear huellas digitales de datos de contenido a nivel de byte que atraviesan los enlaces del sistema de comunicaciones.

Sumario

En las reivindicaciones independientes se establecen aspectos de la invención.

Se proporcionan métodos, aparatos y sistemas para mejorar la utilización de un sistema de comunicaciones (p. ej., un sistema de comunicaciones por satélite), usando técnicas de fiabilidad retardadas como parte de un protocolo de transporte de multidifusión.

Las áreas adicionales de aplicación de la presente descripción resultarán evidentes a partir de la descripción detallada proporcionada en lo sucesivo en la presente memoria. Debe entenderse que la descripción detallada y los ejemplos específicos, aunque indican diversas realizaciones, están destinados únicamente a fines ilustrativos y no pretenden limitar necesariamente el alcance de la descripción.

Breve descripción de los dibujos

La presente descripción se describe conjuntamente con las figuras adjuntas:

la Fig. 1A muestra un diagrama de bloques simplificado de un aspecto de una realización de un sistema de comunicaciones de multidifusión para su uso con diversas realizaciones de las innovaciones presentadas en la presente memoria;

la Fig. IB muestra un diagrama de bloques simplificado de otra realización de un sistema de comunicaciones de multidifusión para su uso con diversas realizaciones de las innovaciones presentadas en la presente memoria;

la Fig. IC muestra un diagrama de flujo de un método ilustrativo para el uso de una realización de las innovaciones en la presente memoria para tratar la fiabilidad de tráfico de multidifusión a través de un sistema de comunicaciones.

la Fig. 2 muestra un diagrama de bloques de una realización de un sistema de comunicaciones por satélite que tiene un sistema de servidor en comunicación con múltiples sistemas de usuario a través de un satélite sobre múltiples haces puntuales, de acuerdo con diversas realizaciones de las innovaciones presentadas en el presente documento;

la Fig. 3 muestra un diagrama de bloques simplificado de un aspecto de una realización de un sistema de comunicaciones de multidifusión para su uso con diversas realizaciones de las innovaciones presentadas en la presente memoria;

la Fig.4 muestra un diagrama de bloques simplificado de un aspecto de una realización de un sistema de comunicaciones de multidifusión para su uso con diversas realizaciones de las innovaciones presentadas en la presente memoria;

la Fig. 5 muestra un diagrama de bloques simplificado de un aspecto de una realización de un sistema de comunicaciones de multidifusión para su uso con diversas realizaciones de las innovaciones presentadas en la presente memoria;

la Fig. 6 muestra un diagrama de flujo de un método ilustrativo de uso de una realización de las innovaciones en la presente memoria para tratar la fiabilidad de tráfico de multidifusión a través de un sistema de comunicaciones que incluye un aspecto de deltadifusión; y

la Fig. 7 muestra un diagrama de flujo de un método ilustrativo de uso de una realización de las innovaciones en la presente memoria para tratar la fiabilidad de tráfico de multidifusión a través de un sistema de comunicaciones.

La Fig. 8 muestra un diagrama de flujo de un método ilustrativo de uso de una realización de las innovaciones en la presente memoria para tratar la fiabilidad de tráfico de multidifusión a través de un sistema de comunicaciones sin ningún usuario solicitante inicial y con un usuario identificado o “canario” .

La Fig. 9 muestra un diagrama de flujo de un método ilustrativo de uso de una realización de las innovaciones en la presente memoria para tratar la fiabilidad de tráfico de multidifusión a través de un sistema de comunicaciones sin ningún usuario solicitante inicial y ningún usuario identificado o “canario” .

En las figuras adjuntas, los componentes y/o las características similares pueden tener la misma etiqueta de referencia. Además, pueden distinguirse diversos componentes del mismo tipo al ir la etiqueta de referencia seguida de un guion y una segunda etiqueta o una etiqueta de letra en conjunto con una etiqueta de número que distingue entre los componentes similares. Si únicamente se usa la primera etiqueta de referencia en la memoria descriptiva, la descripción es aplicable a uno cualquiera de los componentes similares que tengan la misma primera etiqueta de referencia, independientemente de la segunda etiqueta de referencia o letra asociada a la primera etiqueta de reverencia.

Descripción detallada

Las realizaciones de la invención descrita en la presente memoria incluyen un protocolo de transporte de multidifusión con una fiabilidad retardada para los objetos colocados prospectivamente. En un posible ejemplo de implementación no limitativo, un primer sistema de usuario solicita un objeto a través de un sistema que usa un protocolo de transporte de multidifusión. El sistema de comunicación determina que el objeto debe comunicarse al primer sistema de usuario a través de una conexión de multidifusión, que habilita que el objeto se coloque en un segundo sistema de usuario antes de que el objeto sea solicitado posteriormente por el segundo sistema de usuario. Dado que el primer sistema de usuario ha seleccionado el objeto, se comprueba que la multidifusión de copias al primer sistema de usuario no contenga errores y se reemplaza cualquier parte que falte o esté dañada con el fin de proporcionar al primer sistema de usuario una copia completa del objeto. Con el fin de evitar la sobrecarga del canal inverso con solicitudes de error, el segundo sistema acepta la copia de multidifusión del archivo, pero no puede enviar ninguna solicitud para reemplazar la misión o partes dañadas del archivo. En un momento posterior, generalmente después de que el segundo sistema de usuario haya solicitado el objeto, cualquier parte que falte o esté dañada del objeto recibido en el segundo sistema de usuario se arreglará para proporcionar al segundo sistema una copia completa del objeto.

La descripción consiguiente proporciona diversas realización y no pretende limitar el alcance, la aplicabilidad o la configuración de la descripción. Más bien, la descripción consiguiente de las realizaciones proporcionará a los expertos en la materia una descripción que habilite la implementación de determinadas realizaciones. Debe entenderse que pueden realizarse diversos cambios en la función y disposición de los elementos sin apartarse del alcance expuesto en las reivindicaciones adjuntas.

Las ventajas de las realizaciones del sistema pueden incluir permitir una mayor escalabilidad en un transporte de multidifusión. En determinadas circunstancias, tales como una conexión con pérdidas o un tiempo insuficiente en un enlace por satélite, las comprobaciones de fiabilidad en un canal inverso pueden sobrecargar el canal inverso debido a la naturaleza única a múltiple de la multidifusión. Los aspectos de las presentes innovaciones pueden implementarse conjuntamente con otras técnicas para reducir el uso de canal inverso con el fin de habilitar, además, números adicionales en el lado de recepción del canal de comunicaciones de multidifusión donde el ancho de banda de canal inverso puede ser un factor limitante. Como parte de esto, los aspectos de las presentes innovaciones pueden habilitar, además, una mayor frecuencia de búsqueda anticipada o colocación prospectiva de archivos, donde el canal inverso puede ser un factor limitante, especialmente en sistemas, tales como comunicaciones por satélite, donde el tamaño de un haz puntual tiene un potencial para un gran número de receptores.

I. Sistema de comunicaciones de multidifusión con un protocolo de transporte de multidifusión que incluye fiabilidad retardada

En referencia, en primer lugar, a la Fig. 1A, se muestra un diagrama de bloques simplificado de una realización de un sistema 100 de comunicaciones para su uso con diversas realizaciones, con comunicación entre un solo sistema 110 de usuario y un servidor 150 de contenido. El sistema 100 de comunicaciones facilita las comunicaciones entre un sistema 110 de usuario y un servidor 150 de contenido a través de un sistema 120 de servidor y una red 140. El sistema 120 de servidor puede configurarse para proporcionar de manera eficaz comunicación entre el sistema 110 de usuario, que está en un lado de cliente del sistema 100, y el servidor 150 de contenido, que está en un lado de servidor del sistema 100. El sistema 110 de usuario puede incluir el almacenamiento139 de cliente, que puede usarse para almacenar archivos, objetos solicitados y otros datos solicitados y que, además, puede configurarse para almacenar datos que pueden preposicionarse de manera especulativa en el sistema 100 de usuario antes de una solicitud futura. En determinadas realizaciones, un sistema 120 de servidor puede configurarse conjuntamente con el sistema 110 de usuario para proporcionar una funcionalidad de comunicaciones especializada que se describirá más con respecto a las Figs. 2-5.

En determinadas realizaciones, la funcionalidad descrita para el sistema 120 de servidor puede integrarse en la funcionalidad de los servidores 150 de contenido. En otras realizaciones alternativas, el sistema de comunicación 100 puede incluir un sistema de optimizador (p. ej., un optimizador de sistema de servidor y un optimizador de sistema de usuario) que puede implementarse de varias maneras sin alejarse del alcance de la invención. En algunas realizaciones, el optimizador puede implementarse como un sistema intermediario, de tal manera que el sistema 120 de servidor puede incluir un servidor intermediario y el sistema 110 de usuario puede incluir un cliente intermediario.

La Fig. IB muestra un diagrama de bloques simplificado del sistema 100 de comunicaciones que tiene múltiples sistemas 110a a 110n de usuario para su uso con diversas realizaciones. El sistema 100 de comunicaciones facilita las comunicaciones entre el servidor 150 de contenido usando un sistema 120 de servidor y múltiples sistemas 110 de usuario, así como un enlace 125 de comunicación cliente-servidor entre el sistema 120 de servidor y los sistemas 110a-110n de cliente. El enlace 125 de comunicación cliente-servidor soporta uno o más flujos de servicio 525 de unidifusión y uno o más flujos 515 de servicio de multidifusión para soportar el tráfico unidifusión y multidifusión, respectivamente. En una realización, el enlace 125 de comunicación cliente-servidor puede incluir un enlace de comunicación por satélite. Se apreciará que los satélites pueden difundir de manera eficaz todo su tráfico corriente abajo a todos los receptores que se ajustan a una portadora particular, haz, etc. Como tal, la unidifusión o multidifusión a uno o más sistemas 110 de usuario puede, de hecho, implicar la difusión de los datos a través del enlace por satélite y también la difusión de datos de control a receptores directos para que acepten o ignoren partes relevantes de los datos de difusión. De manera destacable, aunque algunos recursos de sistema pueden emplearse en configurar un flujo 515 de servicio de multidifusión y en la logística relacionada, “cuesta” al sistema de comunicaciones por satélite sustancialmente los mismos recursos de ancho de banda enviar un paquete a un sistema 110 de usuario o a todos los sistemas 110 de usuario (p. ej., en un haz puntual particular). Sin embargo, no ocurre lo mismo con los mensajes de todos los sistemas 110 de usuario de vuelta a un sistema de comunicación por satélite. En este canal inverso de cada sistema de usuario, cada mensaje adicional “cuesta” lo mismo que el primer mensaje, de tal manera que el mismo mensaje de tres usuarios en el canal inverso “cuesta” aproximadamente tres veces lo que “cuesta” un único mensaje.

De manera similar, en otra realización, el enlace 125 de comunicación cliente-servidor puede incluir un enlace de comunicación por cable. Por ejemplo, una compañía de cable puede tender una línea de cable a un agregador de vecindario, desde el que líneas coaxiales individuales comunican el tráfico del último kilómetro a los hogares individuales. Cada cable coaxial individual puede transportar todo el tráfico para todo el vecindario, incluso cuando parte del tráfico se destina únicamente a hogares particulares. Como en la realización de satélite descrita anteriormente, dado que todos los hogares de abonado por cable en el mismo vecindario reciben de manera eficaz todo el tráfico, los recursos de ancho de banda pueden compartirse mediante tráfico de multidifusión, cuando sea adecuado. Por supuesto, las redes por satélite y por cable son únicamente dos realizaciones ilustrativas de enlaces de comunicación cliente-servidor 125. Las realizaciones del enlace 125 de comunicación cliente-servidor pueden incluir cualquier tipo de enlace de comunicaciones que pueda tener recursos de ancho de banda limitados, donde los recursos de ancho de banda pueden compartirse al menos parcialmente a través de multidifusión.

Cada sistema 110 de usuario de la Fig. IB puede incluir el almacenamiento139 de cliente, de tal manera que el sistema 110a de usuario puede tener el almacenamiento 139a de cliente y el sistema 110n de usuario puede tener el almacenamiento 139n de cliente. Cada almacenamiento 139 de cliente puede usarse para almacenar archivos, objetos solicitados y otros datos solicitados y puede configurarse además para almacenar datos que se preposicionan de manera especulativa en el sistema 100 de usuario antes de una solicitud futura. En determinadas realizaciones alternativas, los sistemas 110 de usuario pueden compartir el almacenamiento 139 de cliente o partes del almacenamiento 139 de cliente. Los sistemas 110 de usuario pueden disponerse alternativamente en una estructura jerárquica de tal manera que un sistema de usuario se comunica con el servidor 150 de contenido a través de otro sistema de usuario, y puede acceder al almacenamiento 139 de cliente del sistema de usuario intermedio.

La Fig. IC describe un diagrama de flujo simplificado que detalla una posible realización de un protocolo de transporte de multidifusión que incluye fiabilidad retardada. Con fines ilustrativos, las etapas detalladas en la Fig. IC se describen a continuación como implementadas usando los sistemas descritos en las Figs. 1A y IB. Las etapas de la Fig. IC pueden implementarse, como alternativa, usando otros sistemas que incluyen los sistemas que incluyen servidores de contenido adicionales, múltiples niveles de clientes en una estructura jerárquica, dispositivos adicionales dispuestos entre un servidor de contenido de uno cualquiera o más usuarios o cualquier otra configuración aceptable que pueda incluir un canal de multidifusión entre un servidor de contenido y una pluralidad de usuarios.

En la primera etapa de la Fig. IC, la etapa 160, un primer sistema 110b de usuario solicita datos o un objeto de un servidor 150 de contenido. En respuesta a la solicitud, los datos solicitados pueden transmitirse en multidifusión a múltiples sistemas de usuario en la etapa 162 a través de un enlace directo compartido. Al menos dos sistemas de usuario reciben los datos de multidifusión en la Fig. IC, un primer sistema 110b de usuario y un segundo sistema 110 m de usuario. Cuando el primer sistema 110b de usuario, que es el sistema que solicitó los datos, recibe los datos de multidifusión, el primer sistema 110b de usuario comprueba que los datos no contengan errores y envía una solicitud de fiabilidad o mensaje de fiabilidad en la etapa 170. El mensaje de fiabilidad puede comunicarse al sistema 120 de servidor o a los servidores 150 de contenido. Este mensaje del primer sistema 110b de usuario puede ser en la forma de una confirmación de que los datos o partes de los datos, tales como paquetes o bloques individuales, se han recibido satisfactoriamente sin errores. Esta solicitud puede ser, como alternativa, en la forma de una confirmación negativa, de tal manera que una solicitud puede enviarse únicamente cuando se detecta un error o una omisión en los datos o una parte de los datos. Después de la comprobación de errores, el primer cliente almacena los datos con comprobación de errores en la etapa 172.

En paralelo a las etapas 170 y 172 relacionadas con el primer sistema 110b de usuario, un segundo sistema 110 m de usuario preposiciona de manera especulativa los datos de usuario del primer sistema 110b de usuario para habilitar una respuesta más eficaz a una posible solicitud futura de los datos desde el segundo sistema de usuario. Diversos sistemas y métodos de selección de datos para preposicionar de manera especulativa datos incluyen un historial de las selecciones anteriores por el segundo sistema de usuario, selecciones similares por sistemas de usuario similares o simplemente porque los datos se transmiten en multidifusión y el segundo sistema de usuario puede tener recursos disponibles y un almacenamiento de memoria asignado disponible para almacenar los datos en un almacenamiento139 de cliente. Como alternativa, el segundo sistema 110 m de usuario puede tener un almacenamiento de cliente completo 139, pero puede determinar que el uso de los datos puede ser más probable que los datos almacenados actualmente y puede borrar los datos almacenados actualmente para hacer espacio para los datos que se transmiten en multidifusión en respuesta a la solicitud por el primer sistema 110b de usuario.

En la etapa 180, el segundo sistema 110 m de usuario recibe los datos y, en la etapa 182, el segundo sistema 110 m de usuario almacena los datos sin corregir. El segundo sistema 110 m de usuario puede identificar las partes que faltan o están dañadas de los datos en este punto o simplemente puede almacenar los datos recibidos sin comprobar los errores. El segundo sistema 110 m de usuario, de manera adicional, puede seguir controlando los canales entrantes en busca de un primer mensaje de reparación de objeto que se transmite en multidifusión en respuesta a una solicitud de fiabilidad desde el primer sistema de usuario.

En determinadas realizaciones, el segundo sistema 110 m de usuario puede no iniciar, sin embargo, el uso del canal inverso para una solicitud de fiabilidad hasta que el segundo sistema de usuario solicite realmente los datos. Tal solicitud, hecha por una entrada de programa o de usuario al segundo sistema 110 m de usuario, se produce en la etapa 184. Cuando se produce la solicitud, el segundo sistema 110 m de usuario puede enviar una solicitud de fiabilidad indicando que los datos preposicionados tienen errores e identificando las partes que faltan o están dañadas de los datos. La solicitud de fiabilidad puede ser la comunicación inicial desde el segundo sistema 110 m de usuario o puede ser una comunicación de seguimiento después de que se realice una solicitud de datos convencional similar a la solicitud de datos en la etapa 160. Finalmente, en la etapa 186, el segundo sistema 110 m de usuario recibe datos de corrección de errores como parte de un segundo mensaje de reparación de objeto e integra los datos con el archivo de datos sin corregir para crear un objeto con comprobación completa de errores que puede ser usado por el segundo sistema de usuario.

En realizaciones alternativas, en lugar de crear un archivo con comprobación completa de errores que pueda usarse como objeto solicitado, el segundo sistema 110 m de usuario puede usar el archivo con comprobación de errores para una compresión altamente eficaz que puede habilitar una descarga del archivo después de que el segundo sistema 110 m de usuario realice la solicitud del objeto de una manera altamente eficaz, como se describe en mayor detalle a continuación.

De manera adicional, como se ha mencionado anteriormente, el objeto se preposiciona de manera especulativa en el segundo sistema 110 m de usuario, pero el segundo sistema 110 m de usuario puede no iniciar una solicitud del objeto o un mensaje de reparación de objeto hasta que un usuario del segundo sistema 110 m de usuario solicite realmente el objeto. Durante el retardo que puede producirse entre el preposicionamiento especulativo y la solicitud del objeto en el segundo sistema 110 m de usuario, diversas realizaciones alternativas pueden funcionar para tratar el objeto posicionado de manera especulativa de diferentes maneras. Un segundo sistema 110 m de usuario puede o no seguir observando el enlace directo en busca de mensajes de reparación de objeto de multidifusión y puede o no usar recursos de cálculo para analizar el objeto colocado de manera especulativa en busca de errores antes de la solicitud de usuario del objeto. En una posible realización, un sistema puede analizar el objeto colocado de manera especulativa, identificar los errores y crear un mensaje de confirmación negativa que esté listo para comunicarse tan pronto como el usuario solicite el objeto. En realizaciones similares adicionales, tal mensaje de acuse de recibo negativo puede actualizarse si parte de los errores se corrigen mediante un mensaje de reparación de datos de multidifusión, o descartarse si todos los errores se corrigen por dicho mensaje. En realizaciones alternativas adicionales, puede producirse una comprobación de errores en el momento en que un usuario solicita el contenido preposicionado de manera especulativa, puede enviarse una solicitud de contenido a un servidor de contenido meramente para fines de contabilidad en el servidor de contenido y un mensaje de reparación de objeto al usuario del segundo sistema 110 m de usuario puede ser simplemente un mensaje que verifique que el objeto es actual o “ nuevo” y adecuado para su uso en respuesta a la solicitud del usuario. En otras realizaciones, el segundo sistema 110 m de usuario puede controlar o recibir mensajes desde un sistema de control que proporciona información relativa a la disponibilidad del ancho de banda en un canal inverso y puede comunicar mensajes de reparación de objeto basándose en la disponibilidad del ancho de banda

II. Sistema de comunicaciones de multidifusión con un optimizador

La Fig. 2 muestra un diagrama de bloques de una realización de un sistema 200 de comunicaciones por satélite que tiene un sistema 220 de servidor en comunicación con múltiples sistemas 110 de usuario a través de un satélite 205 sobre múltiples haces puntuales 235, de acuerdo con diversas realizaciones. El sistema 220 de servidor puede incluir cualquier componente de servidor, incluyendo estaciones 215 de base, puertas 217 de enlace. El sistema 200 de comunicaciones por satélite puede incluir no solo una trayectoria de comunicación convencional desde los sistemas de usuario a un servidor de contenido, sino que también puede incluir al menos un optimizador 230 de servidor y al menos un optimizador 220 de cliente, y puede incluir una funcionalidad especializada, como se ha mencionado anteriormente. Esta funcionalidad especializada puede servir no solo para permitir una compresión extremadamente alta en el enlace directo, sino también en el enlace inverso, cuando se envían confirmaciones, confirmaciones negativas u otros mensajes de fiabilidad desde un sistema de usuario en respuesta a los objetos recibidos. Esto puede habilitar un uso extremadamente eficaz de un canal inverso cuando se usa conjuntamente con una fiabilidad retardada para datos de multidifusión preposicionados de manera especulativa.

Las realizaciones del optimizador (p. ej., el optimizador 230 de servidor y el optimizador 220 de cliente) pueden implementarse de varias maneras sin alejarse del alcance de la invención. En algunas realizaciones, el optimizador puede implementarse como un intermediario, de tal manera que el optimizador 230 de servidor es un servidor intermediario y el optimizador 220 de cliente es un cliente intermediario. Por ejemplo, puede usarse un intermediario de interceptación transparente para interceptar el tráfico de una manera que sea sustancialmente transparente a los usuarios en el lado de cliente del túnel intermediario. En otras realizaciones, el optimizador puede implementarse como optimizador en línea. Por ejemplo, el optimizador 220 de cliente se implementa dentro de un terminal de usuario y el optimizador 230 de servidor se implementa dentro de un terminal de proveedor (p. ej., una estación de base por satélite o puerta de enlace, un extremo de cabecera de cable, un digital subscriber line access multiplexer (multiplexor de acceso a la línea de abonado digital - DSLAM), etc.). Otras configuraciones son posibles en otras realizaciones. Por ejemplo, las realizaciones del optimizador 230 de servidor se implementan en la nube de Internet (p. ej., en el espacio de servidores arrendados de la red comercial). Las realizaciones del optimizador 220 de cliente se implementan dentro del ordenador personal de un usuario, dentro del módem de un usuario, en un componente separado físicamente en las instalaciones del cliente, etc.

Cabe señalar que debe interpretarse en sentido amplio que las referencias en la presente memoria a datos de “ interceptación” incluyen cualquier ralentización, muestreo, reencaminamiento y/u otras técnicas útiles que permitan el procesamiento de los datos según se requiera de acuerdo con diversas realizaciones. En algunas realizaciones, el tráfico pasa a través del optimizador 230 de servidor, donde se “ intercepta” almacenándose temporalmente para el análisis y procesamiento. Por ejemplo, el almacenamiento temporal puede usarse para ralentizar y acumular el tráfico para la generación y análisis de huellas digitales, como se describe más completamente a continuación. De manera destacable, determinadas realizaciones descritas como que usan un componente de optimizador (p. ej., el optimizador 230 de servidor) para interceptar el tráfico pueden implementarse realmente haciendo que un componente diferente intercepte el tráfico, desde el que el componente de optimizador puede recibir el tráfico interceptado para el procesamiento.

Las realizaciones del sistema 110 de usuario pueden incluir cualquier componente o componentes para proporcionar a un usuario una interactividad de red. Por ejemplo, el sistema 110 de usuario puede incluir cualquier tipo de dispositivo informático, dispositivo de interfaz de red, dispositivo de comunicaciones u otro dispositivo para comunicar datos a y desde el usuario. De manera típica, el sistema 100a de comunicaciones facilita las comunicaciones entre múltiples sistemas 110 de usuario y una diversidad de servidores 150 de contenido a través de una o más redes 140 (para mayor claridad, en la Fig. 1A únicamente se muestra uno de cada uno). Los servidores 150 de contenido están en comunicación con el optimizador 230 de servidor a través de una o más redes 140. La red 140 puede ser cualquier tipo de red 140 y puede incluir, por ejemplo, Internet, una red de protocolo de Internet (Internet Protocol - “ IP” ), una Intranet, una red de área amplia (Wide-Area Network, - “WAN”), una red de área local (Local-Area Network - “LAN” ), una red privada virtual (Virtual Private Network - “VPN” ), la red telefónica pública conmutada (Public Switched Telephone Network - “ PSTN” ) y/o cualquier otro tipo de red 140 que soporte la comunicación de datos entre los dispositivos descritos en la presente memoria, en diferentes realizaciones. La red 140 también puede incluir tanto conexiones por cable como inalámbricas, incluyendo enlaces ópticos.

Como se usa en la presente memoria, la expresión “ servidor o servidores de contenido” pretende incluir, en sentido amplio, cualquier fuente de contenido en la que los usuarios puedan estar interesados. Por ejemplo, un servidor 150 de contenido puede proporcionar un contenido de sitio web, contenido de televisión, intercambio de archivos, servicios multimedia, tratamiento de voz sobre protocolo de Internet (Voice-over-Internet-Protocol - VoIP) y/o cualquier otro contenido útil. Cabe señalar que, en algunas realizaciones, los servidores 150 de contenido están en comunicación directa con el optimizador 230 de servidor (p. ej., no a través de la red 140). Por ejemplo, el optimizador 230 de servidor puede localizarse en una puerta de enlace que puede incluir un servidor de contenido o de aplicación. Como tales, las descripciones de las realizaciones de la presente memoria con respecto a las comunicaciones con los servidores 150 de contenido a través de la red 140 únicamente pretenden ser ilustrativos y no deben interpretarse como limitantes.

En algunas realizaciones, cuando el sistema 110 de usuario se comunica con el servidor 150 de contenido, el optimizador 230 de servidor intercepta las comunicaciones para uno o más fines. Como se describe a continuación, el optimizador 230 de servidor puede ser parte de un sistema 220 de servidor que puede incluir componentes para las comunicaciones de lado de servidor (p. ej., estaciones de base, puertas de enlace, satellite modem termination systems (sistemas de terminación de módem por satélite - SMTS), digital subscriber line access multiplexers (multiplexores de acceso a la línea de abonado digital - DSLAM), etc., como se describe a continuación con referencia a la Fig. 2). El optimizador 230 de servidor puede actuar como intermediario transparente y/o de interceptación. Por ejemplo, el optimizador 220 de cliente está en comunicación con el optimizador 230 de servidor a través de un enlace 125 de comunicación cliente-servidor y el optimizador 230 de servidor está en comunicación con el servidor 150 de contenido a través de un enlace 135 de red de contenido. El optimizador 230 de servidor puede actuar como intermediario transparente para interceptar los datos a medida que pasan entre el enlace 125 de comunicación cliente-servidor y el enlace de red de contenido 135. Algunos fines de la interceptación pueden incluir filtrar, almacenar en memoria caché, analizar y/o procesar de otro modo las solicitudes y respuestas. Por ejemplo, cuando el sistema 110 de usuario solicita un objeto web desde un servidor 150 de contenido, el optimizador 230 de servidor puede interceptar y analizar la solicitud para implementar la búsqueda anticipada y/u otros tipos de funcionalidad.

Como se describe más detalladamente a continuación, las realizaciones del optimizador 230 de servidor usan diversas técnicas (p. ej., codificación de diccionario) para identificar redundancias entre los datos entrantes y los datos enviados previamente a través de los enlaces del sistema 100a de comunicación (p. ej., el enlace 125 de comunicación clienteservidor y el enlace 135 de red de contenido). En particular, diversas técnicas (p. ej., codificación delta, codificación de diccionario amplio, etc.) pueden permitir la identificación de redundancias en secuencias de bytes que atraviesan los enlaces incluso cuando se mantiene un gran historial. Pueden usarse estas técnicas para identificar y explotar las oportunidades de multidifusión para aumentar la utilización de los enlaces de comunicaciones. El uso de estas técnicas para identificar y aprovechar estas oportunidades de multidifusión puede denominarse en la presente memoria “deltadifusión” .

Se apreciará que se pretende que “codificación delta” , “codificación de diccionario” , “diccionario” , “deltadifusión” y otros términos y expresiones similares se interpreten en sentido amplio para incluir el uso de cualquier tipo de estructura similar a un diccionario para la optimización. Las realizaciones del diccionario incluyen fragmentos de datos de contenido (p. ej., implementados como diccionarios delta, diccionarios amplios, memorias caché de bytes y/u otros tipos de estructuras de diccionario). Por ejemplo, cuando los datos de contenido se almacenan en el diccionario, algunos o todos los bloques de datos que definen el contenido se almacenan en el diccionario de una manera no ordenada, pero indexada. Como tal, el contenido puede no ser directamente accesible desde el diccionario; más bien, el conjunto de índices puede ser necesario para recrear el contenido del conjunto de bloques no ordenados.

Cabe señalar que los datos pueden comunicarse a través de un sistema 100a de comunicaciones usando uno o más protocolos que definen, entre otras cosas, el formato de los datagramas (p. ej., paquetes, tramas, etc.). Cada datagrama puede incluir, de manera típica, una parte de encabezamiento y una parte de contenido. Como se usa en la presente memoria, el término “encabezamiento” pretende incluir, en sentido amplio, cualquier parte del datagrama diferente a las usadas para comunicar el contenido real (p. ej., datos de archivo), y no pretende limitarse a ningún formato de datagrama particular. Por ejemplo, un paquete de protocolo de Internet (IP) puede incluir un encabezamiento al comienzo de cada paquete, mientras que otros tipos de datagramas pueden proporcionar tipos de encabezamientos de información de otras formas (p. ej., usando preámbulos, postámbulos, midámbulos, fragmentos de propagación, subtramas, datos de señalización o control separados, etc.). Estas partes del encabezamiento pueden incluir información, tal como una dirección de origen, dirección de destino, prioridad, longitud de paquete, información de codificación, información de modulación, etc. Por supuesto, los expertos en la materia apreciarán que se pueden hallar categorías similares de información de partes de encabezamiento y de partes de contenido dentro de los datagramas de otros formatos de protocolo (p. ej., HTTP, FTP, etc.).

Puede deducirse mucho de las partes de encabezamiento de los datos. Por ejemplo, la parte de encabezamiento puede incluir metadatos u otra información acerca de la parte de contenido que puede usarse para ayudar a caracterizar la parte de contenido de los datos. De hecho, esta técnica puede usarse en determinados tipos de sistemas de distribución de contenido, como un video-on-demand (sistema de vídeo a la carta - VOD). Un sistema de VOD puede incluir una aplicación que se ejecuta en un servidor de contenido de VOD y/o en el equipo de las instalaciones de cliente (Customer Premises Equipment - CPE) del espectador final (p. ej., en un descodificador) para analizar y traducir los metadatos propietarios de los encabezamientos de paquete de solicitudes de usuario. De manera destacable, aunque el uso de los metadatos puede proporcionar un conocimiento relativamente sencillo del contenido que se solicita, el uso de etiquetas propietarias de esta forma puede requerir tener acceso a (p. ej., y ejecutar una aplicación en) el servidor de contenido.

Por ejemplo, un URL analizado puede tener el siguiente aspecto: “ http://www.VOD.com/movieplayer?70AX05nkd4868PRtD5g” . El URL ilustrativo puede incluir una cadena de caracteres generados como parte de una función de aplicación propietaria y puede descodificarse mediante la aplicación de servidor de VOD para identificar información, incluyendo la descarga particular solicitada, un identificador para la sesión, datos de cuenta o usuario, datos de carrito de compra, capacidades de reproducción de cliente, etc. Como tal, otra solicitud para la misma película de VOD, incluso desde el mismo servidor de contenido, puede tener diferentes URL (p. ej., encabezamientos de solicitud diferentes). Aunque el servidor de aplicación de VOD también puede ser capaz de entender las solicitudes como si fueran para la misma película (p. ej., el servidor de aplicaciones de VOD entenderá qué bytes especifican el contenido), un intermediario de interceptación transparente, como el de las realizaciones del optimizador 230 de servidor, puede no ser capaz de determinar esto a partir de solo los metadatos.

Las realizaciones del optimizador 230 de servidor generan huellas digitales (p. ej., huellas digitales, compendios, firmas, funciones de comprobaciones aleatorias, etc.) a partir de la parte de contenido de los datos que atraviesan los enlaces de comunicación. El optimizador 230 de servidor intercepta y analiza los datos a nivel de byte de la parte de contenido de una manera que pueda ser sustancialmente transparente para el usuario. Las realizaciones de las huellas digitales se generan para que resulten útiles en la identificación de redundancias entre los datos entrantes interceptados y los datos procesados anteriormente. Por ejemplo, se aplican funciones de comprobación aleatoria (“ hashing” ) al tráfico, después de ser interceptadas por el optimizador 230 de servidor, para su uso como identificadores (p. ej., identificadores “débiles” ) que son al menos lo suficientemente fuertes como para identificar coincidencias candidatas con bloques almacenados en un diccionario. Algunas realizaciones de las huellas digitales se generan para que sean útiles adicionalmente como identificadores fuertes para representar bloques coincidentes sustancialmente idénticos almacenados en un diccionario.

Varias dificultades surgen de la implementación de este tipo de optimizador para usar las huellas digitales (p. ej., en lugar de metadatos u otra información de encabezamiento). En un ejemplo, como se ha descrito anteriormente, los datos del encabezamiento (p. ej., particularmente los metadatos propietarios) pueden usarse para hacer varias determinaciones (p. ej., exactamente qué archivo de objeto se está solicitando) que pueden ser difíciles o imposibles de hacer a partir de solo los datos de contenido. En otro ejemplo, los datos propietarios o entornos de contenido limitado pueden permitir que se hagan determinadas suposiciones. Por ejemplo, cuando un usuario solicita una película de VOD, el servidor puede saber con exactitud qué bytes se solicitan (p. ej., cualesquiera bytes asociados a ese archivo de película particular en el servidor de VOD), cuál es el tamaño del archivo, que el espectador es probable que vea la película por secuencias, dónde se almacena la película, etc. Sin embargo, mediante el uso de la parte de contenido de los datos para generar huellas digitales, las realizaciones del optimizador 230 de servidor son relativamente agnósticas al contenido que se analiza, lo que puede proporcionar una determinada funcionalidad incluso cuando el optimizador 230 de servidor puede tener poco o ningún acceso a los metadatos propietarios y/u otra información de encabezamiento.

En algunas realizaciones, por ejemplo, el optimizador 230 de servidor genera huellas digitales de datos que se reciben a través del enlace 135 de red de contenido en respuesta a diversas solicitudes de diferentes usuarios en un haz puntual compartido de un sistema de comunicaciones por satélite (p. ej., cuando las solicitudes son atendidas por el optimizador 230 de servidor a través del enlace cliente-servidor 125 del sistema 100a de comunicaciones). El optimizador 230 de servidor determina a partir de las huellas digitales que los múltiples usuarios solicitan el mismo contenido sustancialmente al mismo tiempo. En respuesta, el optimizador 230 de servidor crea un flujo de servicio de multidifusión (p. ej., en el enlace cliente-servidor 125) a través del que transmite en multidifusión los datos solicitados a todos los usuarios solicitantes, ahorrando de ese modo ancho de banda con respecto a la unidifusión de múltiples copias del contenido a los múltiples usuarios.

Cabe señalar que las realizaciones del enlace 125 de comunicación cliente-servidor (p. ej., entre el optimizador 220 de cliente y el optimizador 230 de servidor) y el enlace 135 de red de contenido (p. ej., entre el optimizador 230 de servidor y los servidores 150 de contenido a través de las redes 140) pueden implementarse como diversos tipos de enlaces tienen características de enlace diferentes y/o cambiantes incluyendo, por ejemplo, diferencias en ancho de banda, latencia, coste por bit, etc. Por ejemplo, mientras que determinadas realizaciones se describen en el contexto de un sistema de comunicaciones vía satélite, donde el enlace 125 de comunicación cliente-servidor puede incluir al menos un enlace por satélite, son posibles otras topologías y tipos de enlace.

A continuación, se apreciará que las realizaciones del enlace 125 de comunicación cliente-servidor proporciona de manera eficaz una funcionalidad de aceleración transparente a los sistemas 110 de usuario. Esta funcionalidad se describirá con más detalle con respecto a los sistemas ilustrativos en las Figs. 2-5.

III. Sistema de comunicaciones de multidifusión con un optimizador y un protocolo de transporte de multidifusión que incluye fiabilidad retardada

Como se ha descrito anteriormente, la Fig. 2 muestra un diagrama de bloques de una realización de un sistema 200 de comunicaciones por satélite que tiene un sistema 220 de servidor en comunicación con múltiples sistemas 110 de usuario a través de un satélite 205 sobre múltiples haces puntuales 235, de acuerdo con diversas realizaciones. El sistema 220 de servidor puede incluir cualquier componente de servidor, incluyendo estaciones 215 de base, puertas 217 de enlace y otros componentes. Una estación 215 de base se puede denominar a veces concentrador o estación terrestre. En determinadas realizaciones, como se describe a continuación, la estación 215 de base tiene una funcionalidad que puede ser la misma o diferente de una puerta 217 de enlace. Por ejemplo, como se ilustra, una puerta 217 de enlace proporciona una interfaz entre la red 140 y el satélite 205 a través de varias estaciones 215 de base. Diversas realizaciones proporcionan diferentes tipos de interfaces entre las puertas 217 de enlace y las estaciones 215 de base. Por ejemplo, las puertas 217 de enlace y las estaciones 215 de base pueden estar en comunicación a través de líneas de gran ancho de banda arrendadas (p. ej., Ethernet sin procesar), un virtual private large-area network service (servicio de red privada virtual de gran área - VPLS), una Internet protocol virtual private network (red privada virtual de protocolo de Internet - IP VPN) o cualquier otra red pública o privada por cable o inalámbrica. Las realizaciones del sistema 220 de servidor están en comunicación con uno o más servidores 150 de contenido a través de una o más redes 140.

En algunas realizaciones, la puerta 217 de enlace puede configurarse para implementar funciones de encaminamiento relativamente sencillas. Por ejemplo, la puerta 217 de enlace puede recibir el tráfico de la red 140, determinar cuál de las estaciones de base 215 debería recibir el tráfico y encaminar el tráfico en consecuencia. En otras realizaciones, la puerta 217 de enlace realiza funciones relativamente complejas, incluyendo, por ejemplo, seguridad de red, contabilidad, aceleración de contenidos, análisis de tendencias, procesamiento y/o codificación de señales, etc. En otras realizaciones más, la puerta 217 de enlace y las estaciones 215 de base comparten algunas o todas las funcionalidades de red deseadas. Por ejemplo, puede ser deseable realizar determinadas funciones en una localización, realizar otras funciones de manera distribuida y realizar otras funciones más de manera redundante.

A medida que el tráfico atraviesa el sistema 200 de comunicaciones por satélite en múltiples direcciones, la puerta 217 de enlace puede configurarse para implementar una funcionalidad de comunicaciones multidireccionales. Por ejemplo, la puerta 217 de enlace puede enviar datos a y recibir datos de las estaciones 215 de base. De manera similar, la puerta 217 de enlace puede configurarse para recibir datos e información dirigidos a uno o más sistemas 110 de usuario y formatear los datos y la información para su distribución al respectivo dispositivo de destino a través del satélite 205; o recibir señales desde el satélite 205 (p. ej., desde uno o más sistemas 110 de usuario) dirigidas a un destino en la red 140 y procesar las señales recibidas para la transmisión a través de la red 140.

En una realización, el sistema 200 de comunicaciones por satélite puede incluir varias puertas 217 de enlace distribuidas en una región geográfica grande. Cada puerta 217 de enlace puede estar en comunicación con la red 140 a través de una conexión a alta velocidad (p. ej., un enlace de fibra de gran ancho de banda especializado). Cada puerta 217 de enlace también puede estar en comunicación con y se encarga de las comunicaciones de hasta veinte estaciones 215 de base (p. ej., veinte enlaces de conexión). Cada una de las veinte estaciones 215 de base se configura para dar servicio a un máximo de cuatro enlaces de usuario comunicando el contenido de esos enlaces de usuario al satélite 205 usando una antena 210.

En diversas realizaciones, uno o más de los enlaces por satélite son capaces de comunicarse usando uno o más esquemas de comunicación. En diversas realizaciones, los esquemas de comunicación pueden ser iguales o diferentes para diferentes enlaces. Los esquemas de comunicación pueden incluir diferentes tipos de combinaciones de codificación y modulación. Por ejemplo, diversos enlaces por satélite pueden comunicarse usando técnicas de codificación y modulación de transmisión de capa física usando esquemas de modulación y codificación adaptables, etc. Los esquemas de comunicación también pueden usar uno o más tipos diferentes de esquemas de multiplexación, incluyendo acceso múltiple por división de tiempo en múltiples frecuencias (Multi-Frequency Time-Division Multiple Access - “ MF-TDMA” ), acceso múltiple por división de tiempo (Time-Division Multiple Access -“TDMA” ), acceso múltiple por división de frecuencia (Frequency Division Multiple Access - “ FDMA” ), acceso múltiple por división de frecuencias ortogonales (Orthogonal Frequency Division Multiple Access - “ OFDMA” ), acceso múltiple por división de código (Code Division Multiple Access - “ CDMA” ) o cualquier número de otros esquemas.

Las realizaciones del satélite 205 pueden implementarse como un satélite 205 geoestacionario, un satélite 205 de órbita terrestre baja (Low Earth Orbit - “ LEO” ) o cargas útiles aéreas que no están en órbita y mantenidas en el aire por aviones, dirigibles, globos meteorológicos, etc. Otras realizaciones podrían tener varios satélites 205 en lugar de sólo uno. En otra realización, el satélite 205 puede configurarse como satélite “de guiaondas acodado” , en donde el satélite 205 puede convertir en frecuencia las señales de portadoras recibidas antes de retransmitir estas señales a su destino, pero por lo demás realiza poco o ningún otro procesamiento sobre el contenido de las señales. Podría haber una sola señal de portadora para cada haz puntual 235 de servicio o múltiples portadoras en diferentes realizaciones. De manera similar, una única o múltiples señales de portadora podrían usarse para los haces puntuales de conexión. El satélite 205 puede usar una diversidad de técnicas de codificación y modulación de transmisión de capa física, de acuerdo con determinadas realizaciones, incluyendo las definidas con la norma DVB-S2. En otras realizaciones, son posibles varias configuraciones (p. ej., el uso de satélites de LEO, redes de malla, redes de estrella, etc.).

El satélite 205 puede operar en modo de múltiples haces, transmitiendo varios haces puntuales 235, dirigido cada uno a una región diferente de la Tierra. Cada haz puntual 235 puede asociarse a uno de los enlaces de usuario y usarse para comunicarse entre el satélite 205 y un gran grupo (p. ej., miles) de sistemas 110 de usuario (p. ej., terminales 230 de usuario dentro de los sistemas 110 de usuario). Uno o más sistemas 110 de usuario pueden recibir las señales transmitidas desde el satélite 205, a través de la respectiva antena 225 de usuario. En algunas realizaciones, algunos o todos los sistemas 110 de usuario incluyen una o más terminales 230 de usuario y uno o más dispositivos de CPE 260. Las terminales 230 de usuario pueden incluir módem, módem por satélite, encaminadores o cualquier otro componente útil para tratar las comunicaciones de lado de usuario. En general, debe interpretarse que la referencia a “ usuarios” incluye cualquier usuario (p. ej., abonado, consumidor, cliente, etc.) de los servicios proporcionados a través del sistema 200 de comunicaciones por satélite (p. ej., por o a través del sistema 220 de servidor).

En un haz puntual 235 dado, algunos o todos los usuarios (p. ej., los sistemas 110 de usuario) a los que presta servicio el haz puntual 235 pueden ser capaces de recibir todo el contenido que atraviesa el haz puntual 235 debido al hecho de que el sistema 200 de comunicaciones por satélite emplea comunicaciones inalámbricas a través de diversas antenas (p. ej., 210 y 225). Sin embargo, una parte del contenido puede no estar destinada a ser recibida por determinados clientes. Como tal, el sistema 200 de comunicaciones por satélite puede usar diversas técnicas para “dirigir” contenido a un usuario o grupo de usuarios. Por ejemplo, el contenido puede etiquetarse (p. ej., usando información de encabezamiento de paquete de acuerdo con un protocolo de transmisión) con un determinado identificador de destino (p. ej., una dirección IP), usar diferentes puntos de código de modulación que pueden ser recibidos de manera fiable únicamente por determinados terminales 230 de usuario, enviar información de control a los sistemas 110 de usuario para dirigir los sistemas 110 de usuario a ignorar o aceptar determinadas comunicaciones, etc. Cada sistema 110 de usuario puede adaptarse, a continuación, para tratar los datos recibidos en consecuencia. Por ejemplo, el contenido destinado a un sistema 110 de usuario particular puede pasarse a su respectivo CPE 260, mientras que el contenido no destinado al sistema 110 de usuario puede ignorarse. En algunos casos, el sistema 110 de usuario almacena información no destinada al CPE 260 asociado para su uso si se halla posteriormente que la información es útil para evitar el tráfico a través del enlace por satélite, como se describe con mayor detalle a continuación.

En algunas realizaciones, cada sistema 110 de usuario implementa un optimizador 220 de cliente que está en comunicación con un optimizador 230 de servidor localizado en el sistema 220 de servidor (p. ej., en la puerta 217 de enlace). Los optimizadores 120 de cliente y el optimizador 230 de servidor pueden actuar para crear un túnel virtual entre los sistemas 110 de usuario y los servidores 150 de contenido, como se describe con referencia a la Fig. 1A. En una topología, como el sistema 200 de comunicaciones por satélite mostrado en la Fig. 2, grandes cantidades de tráfico pueden atravesar diversas partes del sistema 200 de comunicaciones por satélite en cualquier momento dado. Como se ha descrito anteriormente, al menos parte del tráfico que atraviesa la red puede ser interceptada por el optimizador 230 de servidor para un procesamiento adicional y para una funcionalidad adicional. La funcionalidad del optimizador 230 de servidor también puede ser asistida y/o explotada por otros componentes del sistema 220 de servidor y los sistemas 110 de usuario. Algunas de estas y otras funcionalidades de los componentes de un sistema 220 de servidor ilustrativo y un sistema 110 de usuario ilustrativo se describen con referencia a diversos tipos de bloques funcionales en las Figs. 3 y 4, respectivamente.

La Fig. 3 muestra un diagrama de bloques 300 simplificado que ilustra una realización de un sistema 220 de servidor acoplado entre una red 140 y una antena 210, de acuerdo con diversas realizaciones. El sistema 220 de servidor puede tener varios componentes, incluyendo un módulo 310 de interfaz de red, un módulo 330 de terminación de módem y un módulo transceptor de lado de servidor 360. Los componentes del sistema 220 de servidor pueden implementarse, total o parcialmente, en el soporte físico. Por tanto, estos pueden incluir uno o más Application Specific Integrated Circuits (Circuitos Integrados Específicos de Aplicación - ASIC) adaptados para realizar un subconjunto de las funciones aplicables en el soporte físico. Como alternativa, las funciones pueden realizarse mediante una o más otras unidades (o núcleos) de procesamiento, en uno o más circuitos integrados (CI). En otras realizaciones, pueden usarse otros tipos de circuitos integrados (p. ej., ASIC estructurados/de plataforma, matrices de puertas lógicas programables en campo [Field Programmable Gate Arrays - FPGA] y otros CI semipersonalizados), que pueden programarse. Cada una también puede implementarse, total o parcialmente, con instrucciones incorporadas en un medio legible por ordenador, a las que se da formato para ser ejecutadas por uno o más controladores generales o específicos de aplicación.

Las realizaciones del sistema 220 de servidor reciben datos desde la red 140 (p. ej., la red 140 de la Fig. 1A), incluyendo los datos que se originan a partir de uno o más servidores 150 de contenido (p. ej., u otros tipos de servidores, como se ha descrito anteriormente) y destinados a uno o más usuarios en un haz puntual (p. ej., en un sistema 110 de usuario en un haz puntual 235, como se muestra en la Fig. 2). Los datos se reciben en el módulo 310 de interfaz de red, que puede incluir uno o más componentes para la interfaz con la red 140. Por ejemplo, el módulo 310 de interfaz de red puede incluir un conmutador de red y un encaminador.

En algunas realizaciones, el módulo 310 de interfaz de red interactúa con otros módulos, incluyendo un servidor 312 de borde de terceros y/o un módulo 314 modelador de tráfico. El servidor 312 de borde de terceros puede adaptarse para duplicar contenido (p. ej., implementar una duplicación transparente, como se podría realizar en un punto de presencia [Point Of Presence - “ POP”] de una red de distribución de contenido [Content Delivery Network - “CDN”]) al sistema 220 de servidor. Por ejemplo, el servidor 312 de borde de terceros puede facilitar las relaciones contractuales entre los proveedores de contenido y los proveedores de servicios para acercar el contenido a los usuarios en una red de comunicaciones (p. ej., la red de comunicaciones por satélite 200 de la Fig. 2). El módulo 314 modelador de tráfico controla el tráfico desde la red 140 a través del sistema 220 de servidor, por ejemplo, para ayudar a optimizar el rendimiento del sistema de comunicaciones (p. ej., reduciendo la latencia, aumentando el ancho de banda eficaz, etc.). En una realización, el módulo 314 modelador de tráfico retarda los paquetes en un flujo de tráfico para ajustarse a un perfil de tráfico predeterminado.

El tráfico pasa del módulo 310 de interfaz de red a uno o más módulos de procesamiento. En algunas realizaciones, los módulos de procesamiento incluyen un módulo 350 acelerador de lado de servidor, un módulo programador 335 y módulos 346 de soporte. En algunas realizaciones, todo el tráfico del módulo 310 de interfaz de red puede pasarse al módulo 350 acelerador de lado de servidor para su tratamiento, como se describe más completamente a continuación. En otras realizaciones, parte o la totalidad del tráfico desde el módulo 350 acelerador de lado de servidor puede pasarse a los módulos 346 de soporte. Por ejemplo, en una realización, los tipos de datos en tiempo real (p. ej., el tráfico de datos de protocolo de datagrama de usuario [User Datagram Protocol - “ UDP” ], como la programación de televisión con protocolo de Internet [Internet-Protocol Television - “ IPTV” ]) sortean el módulo 350 acelerador de lado de servidor, mientras que los tipos de datos que no son en tiempo real (p. ej., el tráfico de datos de protocolo de control de transmisión [Transmission Control Protocol - “TCP” ], como el vídeo en la web) se encaminan a través del módulo 350 acelerador de lado de servidor para su procesamiento. Las realizaciones del módulo 350 acelerador de lado de servidor proporcionan diversos tipos de aplicación, WAN/LAN, y/u otra funcionalidad de aceleración. En una realización, el módulo 350 acelerador de lado de servidor implementa una funcionalidad de aplicaciones AcceleNet de Intelligent Compression Technologies, Inc. (“ ICT” ), una división de ViaSat, Inc. Esta funcionalidad puede usarse para aprovechar información de las capas de aplicación de la pila de protocolos (p. ej., las capas 4 - 7 de la pila de IP) a través del uso de soporte lógico o soporte físico modificado que opera en el sistema 110 de usuario (p. ej., en el terminal 230 de usuario y/o el CPE 260).

En algunas realizaciones, el módulo 350 acelerador de lado de servidor puede adaptarse para proporcionar una compresión de carga útil elevada. Esto permite una transferencia más rápida de los datos y potencia la capacidad eficaz de la red. El módulo 350 acelerador de lado de servidor también puede implementar métodos específicos de protocolo para reducir el número de viajes de ida y vuelta necesarios para completar una transacción, tal como mediante la búsqueda anticipada de objetos incorporados en páginas HTTP. En otras realizaciones, la funcionalidad del módulo 350 acelerador de lado de servidor está estrechamente integrada con el enlace por satélite a través de otros módulos, incluyendo los módulos 346 de soporte, el módulo programador 335, el módulo 330 de terminación de módem, etc., para reducir los requisitos de ancho de banda de carga útil y/o para programar más eficazmente el enlace por satélite. Por ejemplo, la capa de enlace puede utilizarse para determinar si los paquetes se distribuyen con éxito y esos paquetes pueden vincularse más estrechamente con el contenido que soportan a través de información de capa de aplicación. En determinadas realizaciones, estas y/u otras funciones del módulo 350 acelerador de lado de servidor las proporciona un optimizador 230 de servidor residente en (p. ej., o en comunicación con) el módulo 350 acelerador de lado de servidor.

En algunas realizaciones, el optimizador 230 de servidor puede implementarse con múltiples servidores. Cada uno de los múltiples servidores puede configurarse para tratar una parte del tráfico que pasa a través del módulo 350 acelerador de lado de servidor. Cabe señalar que la funcionalidad de diversas realizaciones descritas en la presente memoria usan datos que, a veces, pueden procesarse a través de múltiples servidores. Como tales, pueden proporcionarse uno o más módulos de gestión de servidor para el procesamiento (p. ej., seguimiento, encaminamiento, división, etc.) de datos a través de los múltiples servidores. Por ejemplo, cuando un servidor dentro del optimizador 230 de servidor recibe una solicitud de un usuario (p. ej., desde un sistema 110 de usuario en un haz puntual 235, como se muestra en la Fig. 2), el módulo de gestión de servidor puede procesar esa solicitud en el contexto de otras solicitudes recibidas en otros servidores en el optimizador 230 de servidor. En una realización, la coordinación entre los servidores se implementa en soporte a un almacenamiento singular de datos. Por ejemplo, puede ser deseable evitar almacenar en memoria caché la misma secuencia de bytes dos veces en dos servidores que están en comunicación entre sí (p. ej., cuando ambos servidores forman parte de una red 322 de área de almacenamiento [Storage Area Network - “ SAN” ] en el sistema 220 de servidor). En otra realización, los servidores se configuran para comunicarse a fin de facilitar la identificación de oportunidades de deltadifusión (p. ej., incluyendo multidifusión y/u otras), como se describe más completamente a continuación.

Se apreciará que, aunque el optimizador 230 de servidor puede ilustrarse como parte del sistema 220 de servidor, esto no debería interpretarse como limitante de la localización o implementación del optimizador 230 de servidor. En una realización, el optimizador 230 de servidor puede implementarse mediante un servidor en comunicación con el sistema 220 de servidor a través de la red 140. Por ejemplo, un tercero puede arrendar espacio de servidor al que se pueda acceder a través de Internet o una conexión privada (p. ej., una conexión de fibra a alta velocidad). El espacio de servidor arrendado puede usarse para servir al optimizador 230 de servidor.

Los datos procesados por el módulo 350 acelerador de lado de servidor pueden pasar a través de los módulos 346 de soporte hasta el módulo programador 335. Las realizaciones de los módulos 346 de soporte incluyen uno o más tipos de módulos para soportar la funcionalidad del módulo 330 de terminación de módem, por ejemplo, incluyendo un módulo multidifusor 340, un módulo 342 de política de acceso equitativo (F Access Policy - “ FAP” ) y un módulo 344 de codificación y modulación adaptativa (Adaptive Coding and Modulation - “ACM” ). En determinadas realizaciones, algunos o todos los módulos 346 de soporte incluyen tipos existentes de componentes.

Las realizaciones del módulo multidifusor 340 proporcionan diversas funciones relacionadas con la multidifusión de los datos a través de los enlaces del sistema de comunicaciones. Determinadas realizaciones del módulo multidifusor 340 usan datos generados por otros módulos de procesamiento (p. ej., el módulo 350 acelerador de lado de servidor) para preparar el tráfico para la multidifusión. Por ejemplo, el módulo multidifusor 340 puede preparar datagramas como flujo de multidifusión. Otras realizaciones del módulo multidifusor 340 realizan una funcionalidad relacionada con la multidifusión más compleja. Por ejemplo, el módulo multidifusor 340 puede contribuir a determinar si los datos se transmiten en unidifusión o multidifusión a uno o más usuarios (p. ej., usando la información generada por el módulo 350 acelerador de lado de servidor), qué códigos de modulación usar, si los datos deberían o no enviarse en función de los datos almacenados en los terminales 230 de usuario de destino, cómo tratar determinados tipos de cifrado, etc.

Las realizaciones del módulo 342 de contabilidad ilustran diversas funciones relacionadas con la contabilidad. En una realización, el módulo 342 de contabilidad recopila datos de múltiples componentes para determinar cuánto uso de red atribuir a un usuario particular. Por ejemplo, el módulo 342 de contabilidad puede determinar cómo se contabiliza el tráfico de carga o descarga en función de la política de acceso equitativo (FAP) de un usuario. En otra realización, el módulo 342 de contabilidad ajusta de manera dinámica las FAP de acuerdo con diversas condiciones de enlace y/o de uso de red. Por ejemplo, el módulo 342 de contabilidad puede ajustar las FAP para fomentar el uso de la red durante momentos de menor tráfico. En otra realización más, el módulo 342 de contabilidad afecta a la operación de otros componentes del módulo 330 de terminación de módem, en función de determinadas FAP y/u otras condiciones de contabilidad. Por ejemplo, el módulo 342 de contabilidad puede dirigir el módulo multidifusor 340 a la multidifusión de determinados tipos de datos o a evitar que determinados usuarios se unan a determinados flujos de multidifusión en función de la FAP u otras consideraciones.

Las realizaciones del módulo 344 de ACM implementan diversas funciones de ACM. Por ejemplo, el módulo 344 de ACM puede hacer el seguimiento de las condiciones de enlace para determinados haces puntuales, usuarios, etc., para su uso en el ajuste dinámico de los esquemas de modulación y/o de codificación. En algunas realizaciones, el módulo 344 de ACM puede ayudar a determinar qué usuarios deberían incluirse en qué agrupaciones de clientes o flujos de multidifusión en función de la optimización de los recursos a través de la configuración del código de modulación. En determinadas realizaciones, el módulo 344 de ACM implementa una codificación de datos compatible con ACM adaptada a la codificación progresiva. Por ejemplo, los datos de vídeo MPEG-4 pueden adaptarse a la codificación progresiva en capas (p. ej., una capa de base y capas de potenciación). El módulo 344 de ACM puede configurarse para fijar un código de modulación adecuado por separado para que cada capa optimice la distribución de vídeo.

Cuando el tráfico ha sido procesado por el módulo 350 acelerador de lado de servidor y/o los módulos 346 de soporte, el tráfico pasa al módulo programador 335. Las realizaciones del módulo programador 335 se configuran para proporcionar diversas funciones relacionadas con la programación de los enlaces del sistema de comunicaciones tratado por el sistema 220 de servidor. Por ejemplo, el módulo programador 335 puede gestionar el ancho de banda de enlace mediante la programación de concesiones de licencia dentro de un haz puntual.

En algunas realizaciones, la funcionalidad del sistema 220 de servidor implica la comunicación e interacción con la SAN 322. Las realizaciones de la SAN 322 incluyen un módulo de almacenamiento compartido 320, que puede incluir cualquier tipo útil de almacenamiento de memoria para diversos tipos de funcionalidad del sistema 220 de servidor. Por ejemplo, el módulo de almacenamiento compartido 320 puede incluir almacenamiento volátil o no volátil, servidores, archivos, colas, etc. En determinadas realizaciones, la SAN 322 puede incluir, además, un servidor de borde cautivo 325, que puede estar en comunicación con el módulo de almacenamiento compartido 320. En algunas realizaciones, el servidor de borde cautivo 325 proporciona una funcionalidad similar a la del servidor 312 de borde de terceros, incluyendo la duplicación de contenido. Por ejemplo, el servidor de borde cautivo 325 puede facilitar diferentes relaciones contractuales de las del servidor 312 de borde de terceros (p. ej., entre el proveedor del sistema 220 de servidor y diversos proveedores de contenido). En determinadas realizaciones, el servidor de borde cautivo 325 o el servidor 312 de borde de terceros están en comunicación con el almacenamiento de lado de servidor (p. ej., dentro de la SAN 322).

Se apreciará que los componentes del sistema 220 de servidor pueden proporcionar muchos tipos diferentes de funcionalidad. Por ejemplo, algunas realizaciones supervisar una diversidad de técnicas de descodificación, intercalado, descifrado y desaleatorización. Otras realizaciones gestionan funciones aplicables a la comunicación del contenido corriente abajo a través de un satélite (p. ej., el satélite 205 de la Fig. 2) a uno o más usuarios (p. ej., los sistemas 110 de usuario de la Fig. 2). Como se describe con mayor detalle a continuación con referencia a diversas realizaciones, el sistema 220 de servidor puede tratar diferentes tipos de tráfico de diferentes maneras. Por ejemplo, algunos usos del sistema de comunicaciones implican las relaciones y/u obligaciones contractuales con los proveedores de contenido terceros para interconectarse con sus servidores de borde (p. ej., a través del servidor 312 de borde de terceros), mientras que otros usos implican “ realojar” localmente determinado contenido (p. ej., a través del servidor 325 de borde cautivo). Además, algunos casos de uso tratan los tipos de datos en tiempo real (p. ej., los datos de UDP) de manera diferente a los tipos de datos no en tiempo real (p. ej., los datos de TCP). Son posibles muchos otros usos.

En algunas realizaciones, algunas o todas estas funciones de comunicaciones corriente abajo son tratadas por el módulo transceptor de lado de servidor 360. Las realizaciones del módulo transceptor de lado de servidor 360 codifican y/o modulan datos, usando una o más técnicas de corrección de errores, técnicas de codificación adaptativa, encapsulación de banda de base, creación de tramas, etc. (p. ej., usando diversos códigos de modulación, tablas de consulta, etc.). Otras funciones también pueden ser realizadas por el módulo transceptor de lado de servidor 360 u otros componentes del sistema 220 de servidor, incluyendo conversión ascendente, amplificación, filtrado, ajuste, seguimiento, etc. Por ejemplo, en el contexto del sistema 200 de comunicaciones por satélite de la Fig. 2, el módulo transceptor de lado de servidor 360 puede comunicar datos a una o más antenas 210 para su transmisión a través del satélite 205 a los sistemas 110 de usuario. Las realizaciones del sistema 220 de servidor también incluyen el módulo 330 de terminación de módem para recibir el tráfico de módem a través del enlace por satélite de los usuarios. En algunas realizaciones, el módulo 330 de terminación de módem se configura sustancialmente como un Satellite Modem Termination System (sistema de terminación de módem por satélite - SMTS).

En otras realizaciones, las funciones corriente abajo y/u otras funciones del sistema 220 de servidor se centralizan y/o distribuyen de acuerdo con diversas realizaciones de la invención. Por ejemplo, como se muestra en la Fig. 2, un sistema 220 de servidor puede incluir varias estaciones 215 de base, puertas 217 de enlace y/u otros componentes (p. ej., concentradores, conexiones cruzadas, núcleos, etc.). De manera similar, en otros tipos de sistemas de comunicaciones, múltiples componentes del sistema 220 de servidor pueden realizar diversas funciones en el lado de servidor del sistema de comunicaciones. En algunas realizaciones, sustancialmente cada nodo del sistema 220 de servidor (p. ej., cada estación 215 de base, puerta 217 de enlace, etc.) es capaz de realizar sustancialmente toda la funcionalidad del sistema 220 de servidor. En otras realizaciones, gran parte de la funcionalidad del sistema 220 de servidor de procesamiento avanzado se implementa en nodos de borde (p. ej., las estaciones 215 de base) del sistema 220 de servidor, mientras que otros nodos (p. ej., las puertas 217 de enlace, núcleos, conexiones cruzadas, etc.) proporcionan funciones de encaminamiento y/o conmutación más básicas. En otras realizaciones más, la funcionalidad del nodo de borde está bastante limitada, mientras que las funciones de procesamiento avanzado están más centralizadas (p. ej., en puertas 217 de enlace, nodos de núcleo, etc.).

Como se ha descrito anteriormente (p. ej., con referencia a las Figs. 1 y 2), el sistema 220 de servidor se comunica con uno o más sistemas 110 de usuario configurados para realizar diversas funciones de comunicaciones de lado de usuario (p. ej., lado de cliente). La Fig. 4 muestra un diagrama de bloques simplificado de una realización de un sistema 110a de usuario, incluyendo una realización de un terminal 230 de usuario acoplado entre una antena 225 de usuario y un CPE 260, de acuerdo con diversas realizaciones. Algunas realizaciones del sistema 110 de usuario se configuran, como se muestra en la Fig. 2, para comunicarse a través de sistema 200 de comunicaciones por satélite mediante la interfaz con un sistema 220 de servidor a través de un enlace por satélite (p. ej., el sistema 220 de servidor de la Fig. 3). La interfaz y otras funcionalidades del sistema 110 de usuario pueden ser proporcionadas por los componentes del terminal 230 de usuario, incluyendo un módulo 410 transceptor de terminal, módulos 415 de procesamiento de datos y un módulo 437 de almacenamiento de cliente. Las realizaciones de los módulos 415 de procesamiento de datos incluyen un módulo 450 de MAC, un módulo 430 acelerador de terminal y un módulo 420 de encaminamiento.

Los componentes pueden implementarse, total o parcialmente, en el soporte físico. Por tanto, estos pueden incluir uno o más ASIC adaptados para realizar un subconjunto de las funciones aplicables en el soporte físico. Como alternativa, las funciones pueden realizarse mediante uno o más otros módulos de procesamiento (o núcleos), en uno o más circuitos integrados. En otras realizaciones, pueden usarse otros tipos de circuitos integrados (p. ej., ASIC estructurados/de plataforma, FPGA y otros CI semipersonalizados), que pueden programarse. Cada una también puede aplicarse, total o parcialmente, con instrucciones incorporadas a un medio legible por ordenador, a las que se da formato para ser ejecutadas por uno o más procesadores generales o de aplicación específica.

Una señal desde la antena 225 de usuario es recibida por el terminal 230 de usuario en el módulo 410 transceptor de terminal. Las realizaciones del módulo 410 transceptor de terminal pueden amplificar la señal, adquirir la portadora y/o convertir descendentemente la señal. En algunas realizaciones, esta funcionalidad se realiza mediante otros componentes (ya sea dentro o fuera del terminal 230 de usuario).

En algunas realizaciones, los datos del módulo 410 transceptor de terminal (p. ej., la señal sometida a conversión descendente) se comunican a los módulos 415 de procesamiento de datos para su procesamiento. Por ejemplo, los datos se comunican al módulo 450 de MAC. Las realizaciones del módulo 450 de MAC preparan datos para su comunicación con otros componentes de, o en comunicación con, el terminal 230 de usuario, incluyendo el módulo 430 acelerador de terminal, el módulo 420 de encaminamiento y/o el CPE 260. Por ejemplo, el módulo 450 de MAC puede modular, codificar, filtrar, descifrar y/o procesar de otro modo los datos para que sean compatibles con el CPE 260.

En algunas realizaciones, el módulo 450 de MAC puede incluir un módulo 452 de preprocesamiento. El módulo 452 de preprocesamiento implementa una determinada funcionalidad para optimizar los otros componentes de los módulos 415 de procesamiento de datos. En algunas realizaciones, el módulo 452 de preprocesamiento procesa la señal recibida desde el módulo 410 transceptor de terminal interpretando (p. ej., y descodificando) esquemas de modulación y/o codificación, interpretando flujos de datos multiplexados, filtrando la señal digitalizada, analizando la señal digitalizada en diversos tipos de información (p. ej., extrayendo el encabezamiento de capa física), etc. En otras realizaciones, el módulo 452 de preprocesamiento filtra previamente el tráfico para determinar qué datos encaminar directamente al módulo 420 de encaminamiento y qué datos encaminar a través del módulo 430 acelerador de terminal para su procesamiento adicional.

Las realizaciones del módulo 430 acelerador de terminal proporcionan sustancialmente la misma funcionalidad que el módulo 350 acelerador de lado de servidor, incluyendo diversos tipos de aplicaciones, WAN/LAN, y/u otra funcionalidad de aceleración. En una realización, el módulo 430 acelerador de terminal implementa la funcionalidad de aplicaciones de AcceleNet™, como la interpretación de datos comunicados por el sistema 220 de servidor usando una compresión de carga útil alta, el tratamiento de diversas funciones de búsqueda anticipada, el análisis de guiones para interpretar solicitudes, etc. En algunas realizaciones, estas y/u otras funciones del módulo 430 acelerador de terminal son proporcionadas por un optimizador 220 de cliente residente en (p. ej., o en comunicación con) el módulo 430 acelerador de terminal. De manera destacable, en algunas realizaciones, el optimizador 220 de cliente se implementa como optimizador 220a de cliente en el terminal 230 de usuario y/o el optimizador 220b de cliente en el CPE 260b. Los datos del módulo 450 de MAC y/o el módulo 430 acelerador de terminal pueden encaminarse, a continuación, a uno o más CPE 260 mediante el módulo 420 de encaminamiento.

En algunas realizaciones, la salida de los módulos 415 de procesamiento de datos y/o el módulo 430 acelerador de terminal se almacena en el módulo 437a de almacenamiento de cliente. Además, los módulos 415 de procesamiento de datos y/o el módulo 430 acelerador de terminal pueden configurarse para determinar qué datos deberían almacenarse en el módulo 437a de almacenamiento de cliente y qué datos no (p. ej., qué datos deberían pasarse al CPE 260). Se apreciará que el módulo 437a de almacenamiento de cliente puede incluir cualquier tipo útil de almacenamiento de memoria para diversos tipos de funcionalidad del sistema 110 de usuario. Por ejemplo, el módulo 437a de almacenamiento de cliente puede incluir almacenamiento volátil o no volátil, servidores, archivos, colas, etc. Las realizaciones del módulo 437a de almacenamiento de cliente se configuran para almacenar parte o la totalidad de un diccionario 435 de cliente, como se describe más completamente a continuación.

En algunas realizaciones, la funcionalidad y/o la capacidad de almacenamiento se comparte entre un módulo 437a de almacenamiento de cliente integrado (p. ej., a bordo) y un módulo 439a de almacenamiento ampliado (p. ej., no a bordo). Por ejemplo, el módulo 439a de almacenamiento ampliado puede implementarse de diversas maneras, incluyendo como un dispositivo periférico conectado (p. ej., una unidad de almacenamiento en miniatura, un disco duro USB, etc.), un dispositivo periférico inalámbrico (p. ej., un disco duro inalámbrico), etc. En algunas realizaciones, el terminal 230 de usuario interactúa con el módulo 439a de almacenamiento ampliado a través de uno o más puertos 438a. En una realización, la funcionalidad del módulo 437 de almacenamiento de cliente se implementa como almacenamiento integrado en o en comunicación con el CPE 260 (p. ej., como módulo 437b de almacenamiento de cliente en el CPE 260b).

Algunas realizaciones del CPE 260 son dispositivos o sistemas de CPE 260 convencionales sin ningún soporte físico o soporte lógico específicamente diseñado (p. ej., mostradas como CPE 260a). Sin embargo, otras realizaciones del CPE 260 incluyen módulos de soporte físico y/o soporte lógico adaptados para optimizar o potenciar la integración del CPE 260 con el terminal 230 de usuario (p. ej., mostradas como CPE alternativo 260b). Por ejemplo, se muestra que el CPE alternativo 260b incluye un módulo 462 acelerador de CPE, un módulo 466 de procesador de CPE y un módulo 437b de almacenamiento de cliente. Las realizaciones del módulo 437b de almacenamiento de cliente se configuran para almacenar una parte o la totalidad del diccionario 435b de cliente. Las realizaciones del módulo 462 acelerador de CPE se configuran para implementar la misma funcionalidad, una similar o una complementaria a la del módulo 430 acelerador de terminal. Por ejemplo, el módulo 462 acelerador de CPE puede ser una versión de cliente de soporte lógico del módulo 430 acelerador de terminal. En algunas realizaciones, parte o toda la funcionalidad de los módulos 415 de procesamiento de datos se implementa mediante el módulo 462 acelerador de CPE y/o el módulo 466 procesador de CPE. En estas realizaciones, puede ser posible reducir la complejidad del terminal 230 de usuario cambiando la funcionalidad al CPE alternativo 260b.

Las realizaciones del módulo 437b de almacenamiento de cliente pueden incluir cualquier tipo de diccionario, almacenamiento en memoria caché de objetos o bytes, servicio de datos y/u otros componentes relacionados con el almacenamiento en o en comunicación con el CPE 260b alternativo (p. ej., un disco duro de ordenador, una grabadora de vídeo digital [Digital Video Recorder - “ DVR” ], etc.). En algunas realizaciones, el módulo 437b de almacenamiento de cliente puede estar en comunicación con un módulo 439b de almacenamiento ampliado, por ejemplo, a través de uno o más puertos 438b. Por supuesto, son posibles muchos tipos de CPE 260, y la funcionalidad del CPE 260 puede implementarse en varios tipos diferentes de dispositivos o sistemas. En algunas realizaciones, el CPE 260 puede ser un dispositivo terminal fijo o móvil para mostrar contenido al usuario, como una televisión, un ordenador personal, un sistema de cine en casa, un teléfono móvil, un reproductor de música o vídeo portátil, un asistente digital personal, etc. En otras realizaciones, el CPE 260 puede ser un dispositivo intermedio, configurado para comunicarse con otro dispositivo terminal del CPE 260 (o incluso con otro dispositivo intermedio del CPE 260). Por ejemplo, el CPE 260 puede incluir un descodificador, un componente de conexión de red doméstica (p. ej., un encaminador, un concentrador, una femtocelda, etc.) o cualquier otro tipo de dispositivo intermedio. Como se muestra, el CPE 260c está en comunicación con el terminal 230 de usuario indirectamente a través del CPE 260b, donde el CPE 260b actúa como dispositivo intermedio.

Además, en algunas realizaciones, el CPE 260 puede integrarse, parcial o totalmente, con el terminal 230 de usuario. Por ejemplo, puede construirse un sistema de cine en casa alrededor de un componente de interfaz principal que puede incluir una interfaz de red que tenga una funcionalidad del terminal 230 de usuario, determinadas funcionalidades del CPE 260 y puertos para la comunicación por cable o inalámbrica con dispositivos de CPE 260 adicionales. Las realizaciones de terminales 230 de usuario y/o CPE 260 también pueden configurarse para la compatibilidad con determinadas normas de comunicación. Por ejemplo, los CPE 260 pueden configurarse para soportar la funcionalidad de enchufar y usar (p. ej., a través de la norma de la Digital Living Network Alliance (Alianza para el estilo de vida digital en red -[DLNA]), la conexión de red inalámbrica (p. ej., a través de la norma 802.11), etc.

En determinadas realizaciones, el terminal 230 de usuario puede configurarse para transmitir datos de vuelta al sistema 220 de servidor. Las realizaciones de los módulos 415 de procesamiento de datos y el módulo 410 transceptor de terminal se configuran para proporcionar la funcionalidad de comunicar información de vuelta a través del sistema de comunicaciones (p. ej., a través del sistema 200 de comunicaciones por satélite de la Fig. 2 para dirigir la provisión de servicios). Por ejemplo, la información acerca de lo que se almacena en el diccionario 435 de cliente puede enviarse de vuelta al sistema de servidor 220 para limitar las transferencias de archivos repetitivas, como se describe más completamente a continuación.

Se apreciará que el sistema de comunicaciones puede usarse para proporcionar diferentes tipos de servicios de comunicación a los usuarios. Por ejemplo, el sistema 200 de comunicaciones por satélite de la Fig. 2 puede proporcionar contenido de los servidores 150 de contenido, a través de la red 140, al CPE 260 de un usuario, incluyendo contenido de Internet, contenido de difusión de televisión y radio, contenido a la carta, contenido de voz sobre protocolo de Internet (VoIP) y/o cualquier otro tipo de contenido deseado. Además, se apreciará que este contenido puede comunicarse a los usuarios de diferentes maneras, incluyendo a través de unidifusión, multidifusión, difusión, difusión simultánea y/u otras comunicaciones.

Como se ha descrito anteriormente, pueden facilitarse varias funciones de comunicaciones adicionales y/o mejoradas explotando el intercambio de contenido y/u otros tipos de oportunidades a través de deltadifusión. Por ejemplo, en un sistema de comunicación típico, como el sistema 200 de comunicaciones por satélite de la Fig. 2, múltiples clientes pueden solicitar el mismo contenido o sustancialmente similar al mismo tiempo o en momentos diferentes. Mediante la explotación de esta característica del sistema de comunicación, puede ser posible optimizar (al menos parcialmente) la provisión de diversos servicios de comunicación. Por ejemplo, pueden mejorarse las condiciones de enlace (p. ej., utilización de ancho de banda), pueden ofrecerse servicios mejorados a los clientes, pueden reducirse los costes relacionados con la provisión de servicios, etc.

El intercambio de contenido puede implementarse de muchas maneras diferentes, de acuerdo con las realizaciones. Por ejemplo, un determinado contenido puede transmitirse en multidifusión a varios usuarios en un haz puntual, permitiendo de este modo que múltiples sistemas 110 de usuario compartan los canales (es decir, aumentando potencialmente el rendimiento eficaz). En lugar de transmitir una copia del contenido a cada usuario solicitante a través de un canal de unidifusión privado, se pueden compartir menos copias del contenido por parte de múltiples usuarios. En determinadas realizaciones, se usan componentes personalizados o disponibles en el comercio para proporcionar esta funcionalidad evaluando múltiples flujos de comunicación y colapsando los mismos en un único flujo dentro de cierta tolerancia (p. ej., una pequeña “ventana de fluctuación” , que representa las variaciones de retardo entre paquetes). En otras realizaciones, los componentes especializados en el sistema 220 de servidor implementan esta funcionalidad.

De acuerdo con diversas realizaciones, la deltadifusión y la funcionalidad relacionada pueden implementarse al menos parcialmente a través de interacciones de cliente-servidor. Como se ha descrito anteriormente, un optimizador 230 de servidor puede determinar qué contenido está atravesando los diversos enlaces en el sistema de comunicación usando huellas digitales. Por ejemplo, las huellas digitales pueden usarse para identificar las tendencias de huellas digitales (p. ej., patrones de comunicaciones en secuencia de bytes) y/o para identificar características de contenido reales (p. ej., la información de las capas 4 - 7 de la pila de protocolo IP de OSI). Estas determinaciones pueden usarse a continuación para identificar y explotar las oportunidades de mejorar los servicios de comunicación a través del sistema de comunicaciones.

La Fig. 5 muestra un diagrama de bloques de una realización de un sistema 500 de comunicaciones, que ilustra la interactividad de cliente-servidor a través de un optimizador 220 de cliente y un optimizador 230 de servidor, de acuerdo con diversas realizaciones. En algunas realizaciones, el sistema 500 de comunicaciones puede ser una realización del sistema 100a de comunicaciones de la Fig. 1A o el sistema 200 de comunicaciones por satélite de la Fig. 2. Como se muestra, el sistema 500 de comunicaciones facilita las comunicaciones entre un sistema 110 de usuario y uno o más servidores 150 de contenido a través de al menos un enlace 125 de comunicación clienteservidor y al menos un enlace 135 de red de contenido. Por ejemplo, las interacciones entre el optimizador 220 de cliente y el optimizador 230 de servidor crean efectivamente un túnel 505 entre el sistema 110 de usuario y los servidores 150 de contenido. En algunas realizaciones, el enlace 135 de red de contenido puede incluir enlaces a través de una red 140, como la Internet. Asimismo, como se ilustra, las realizaciones del enlace 125 de comunicación cliente-servidor soportan uno o más flujos 525 de servicio de unidifusión y uno o más flujos 515 de servicio de multidifusión.

En algunas realizaciones, el sistema 110 de usuario puede incluir una graphical user interface (interfaz gráfica de usuario - GUI) 512 de cliente, un navegador web 514 y un redireccionador 516. La GUI 512 de cliente puede permitir a un usuario configurar aspectos de rendimiento del sistema 110 de usuario (p. ej., o incluso aspectos del mayor sistema 500 de comunicaciones en algunos casos). Por ejemplo, el usuario puede ajustar parámetros de compresión y/o algoritmos, alterar filtros de contenido (p. ej., para bloquear sitios web ilícitos) o habilitar o deshabilitar diversas características usadas por el sistema 500 de comunicaciones. En una realización, algunas de las características pueden incluir diagnósticos de red, la notificación de errores, así como el control, por ejemplo, de los componentes del optimizador 220 de cliente y/o el optimizador 230 de servidor.

En una realización, el usuario selecciona una dirección de universal recourse locator (localizador de recursos universal (URL) a través de la GUI 512 de cliente que dirige el navegador web 514 (por ejemplo Internet Explorer®, Firefox®, Netscape Navigator®, etc.) a un sitio web (p. ej., cnn.com, google.com, yahoo.com, etc.). El navegador web 514 puede emitir, a continuación, una solicitud al sitio web y los objetos asociados a la Internet. Cabe señalar que el navegador web 514 se muestra únicamente para fines ilustrativos. Aunque las realizaciones del sistema 110 de usuario pueden incluir, de manera típica, al menos un navegador web 514, los sistemas 110 de usuario pueden interactuar con los proveedores 150 de contenido de varias maneras diferentes sin alejarse del alcance de la invención.

La solicitud de contenido desde el sistema 110 de usuario (p. ej., desde el navegador web 514) puede ser interceptada por el redireccionador 516. Cabe señalar que las realizaciones del redireccionador 516 se implementan de diversas maneras. Por ejemplo, las realizaciones del redireccionador 516 se implementan dentro de un módem de usuario como parte de la funcionalidad de encaminamiento interno del módem. El redireccionador 516 puede enviar la solicitud al optimizador 220 de cliente. Cabe señalar que el optimizador 220 de cliente se muestra como separado del sistema 110 de usuario (p. ej., en comunicación a través de un bus local, en un sistema informático separado conectado al sistema 110 de usuario a través de un enlace de alta velocidad/baja latencia, como una subred de LAN de sucursal, etc.). Sin embargo, las realizaciones del optimizador 220 de cliente se implementan como parte del sistema 110 de usuario en cualquier localización útil de lado de cliente, incluyendo como parte de un terminal de usuario, como parte de un módem de usuario, como parte de un concentrador, como un componente de soporte físico separado, como una aplicación de soporte lógico en la máquina de cliente, etc.

En una realización, el optimizador 220 de cliente puede incluir un procesador 522a de objeto. El procesador 522a de objeto puede configurarse para realizar varias funciones diferentes de procesamiento, incluyendo el análisis de Java y el procesamiento de protocolos. Las realizaciones del procesador 522a de objeto pueden procesar un hypertext transfer protocol (protocolo de transferencia de hipertexto - HTTP), un file transfer protocol (protocolo de transferencia de archivos - FTP), diversos protocolos de medios, metadatos, información de encabezamiento y/u otra información relevante de los datos de solicitud (p. ej., paquetes) para permitir que el optimizador 220 de cliente realice sus funciones de optimizador. Por ejemplo, la solicitud puede procesarse mediante el procesador 522a de objeto para determinar qué objetos se están solicitando y si los datos necesarios para generar el objeto solicitado pueden estar ya almacenados en el almacenamiento de cliente (p. ej., en el diccionario 435 de cliente de una operación de búsqueda anticipada, una operación de preposicionamiento, una operación de almacenamiento en memoria caché de multidifusión, una operación de deltadifusión anterior, etc.).

En algunas realizaciones, el procesador 522a de objeto envía los datos de solicitud procesados a un codificador 524a de deltadifusión. El codificador 524a de deltadifusión puede codificar la solicitud en una versión comprimida de la solicitud usando uno o más algoritmos de compresión de datos. Por ejemplo, estos algoritmos pueden emplear una codificación de diccionario con el diccionario 435 de cliente configurado para almacenar cadenas de tal manera que los datos de los objetos web anteriores puedan usarse para comprimir los datos de las nuevas páginas. Por supuesto, son posibles otros tipos de codificación, de acuerdo con otras realizaciones del codificador 524a de deltadifusión.

Los datos de solicitud procesados y/o codificados pueden procesarse adicionalmente después mediante un procesador 528a de unidifusión en algunas realizaciones como preparación para comunicar los datos a través del enlace 125 de comunicación cliente-servidor (p. ej., como tráfico de IP privado). En diversas realizaciones, el procesador 528a de unidifusión procesa los datos de acuerdo con uno o más protocolos, por ejemplo, un protocolo de unidifusión, dependiendo al menos del tipo de enlaces de comunicación implementados como parte del enlace 125 de comunicación clienteservidor. Por ejemplo, el enlace 125 de comunicación cliente-servidor puede incluir un enlace inalámbrico, un enlace celular, un enlace por satélite, un enlace de acceso por red conmutada, etc. En determinadas realizaciones, el procesador 528a de unidifusión puede configurarse para implementar el protocolo de transporte de Intelligent Compression Technology® (ICT-[ITP]). En una realización, el ITP mantiene una conexión persistente entre el optimizador 220 de cliente y el optimizador 230 de servidor. La conexión persistente puede habilitar que el sistema 500 de comunicaciones reduzca o elimine las ineficiencias y los costes de sobrecarga asociados a la creación de una nueva conexión para cada solicitud. En realizaciones alternativas, puede sustituirse el ITP por cualquier otro transporte de unidifusión fiable, tanto para esta implementación como para cualquier otra implementación descrita en la presente memoria.

En algunas realizaciones, la comunicación puede ser recibida en el otro terminal del enlace 125 de comunicación cliente-servidor por un procesador 528b de unidifusión en el optimizador 230 de servidor. En algunas realizaciones, el procesador 528b de unidifusión en el optimizador 230 de servidor puede implementarse como un componente sustancialmente idéntico al procesador 528a de unidifusión en el optimizador 220 de cliente. En otras realizaciones, las implementaciones de los procesadores de unidifusión 528 pueden adaptarse a su localización (p. ej., en el optimizador 220 de cliente o el optimizador 230 de servidor). Cuando los datos de solicitud son recibidos por el procesador 528b de unidifusión, el procesador 528b de unidifusión puede procesar la solicitud de acuerdo con el uno o más protocolos aplicados. Por ejemplo, el procesador 528b de unidifusión puede configurarse para implementar el ITP, de tal manera que los datos enviados desde el procesador 528a de unidifusión de acuerdo con el protocolo ITP puedan procesarse en consecuencia.

Como se ha descrito anteriormente, los datos recibidos en el optimizador 230 de servidor desde el optimizador 220 de cliente pueden estar codificados (p. ej., codificados en diccionario) y/o procesados de otro modo (p. ej., de acuerdo con uno o más protocolos, como el HTTP). Las realizaciones del optimizador 230 de servidor incluyen un procesador 522b de objeto y un codificador 524b de deltadifusión. En algunas realizaciones, el procesador 522b de objeto y el codificador 524b de deltadifusión se configuran para tratar el procesamiento y/o la codificación de los datos de solicitud implementados por el procesador 522a de objeto y el codificador 524a de deltadifusión del optimizador 220 de cliente, respectivamente. Por ejemplo, las realizaciones del procesador 522b de objeto usan características de los tipos de información del codificador 524b de deltadifusión y/o del diccionario, que pueden almacenarse, o modelarse, en un módulo modelador 532 para descodificar los datos de solicitud. Por tanto, la solicitud puede procesarse (p. ej., traducirse, descodificarse, etc.) en un formato que sea accesible para una fuente del contenido solicitado (p. ej., un sitio web). Por supuesto, en determinadas realizaciones, las características adicionales de la solicitud pueden procesarse mediante estos u otros componentes. Por ejemplo, si la solicitud incluye una cookie (u otras instrucciones especiales), tal como un “ referido por” o tipo de codificación aceptado, la información acerca de la cookie o las instrucciones pueden almacenarse como parte de un modelo de cookie en el módulo 532 modelador u otra ubicación.

Las realizaciones del procesador 522b de objeto pueden reenviar a continuación la solicitud descodificada a un destino adecuado (p. ej., un servidor 150 de contenido) a través del enlace 135 de red de contenido (p. ej., a través de una red 140). El enlace 135 de red de contenido puede incluir, por ejemplo, una conexión de módem por cable, una conexión de digital subscriber line (línea de abonado digital - DSL), una conexión T1, una conexión de fibra óptica, etc. Como se ha descrito anteriormente, en algunas realizaciones del sistema 500 de comunicaciones, el enlace 135 de red de contenido manifiesta una latencia sustancialmente menor que la del enlace 125 de comunicación cliente-servidor.

Los datos de respuesta pueden recibirse mediante el procesador 522b de objeto, en respuesta a la solicitud, desde el destino adecuado (p. ej., el servidor 150 de contenido) a través del enlace 135 de red de contenido. Se apreciará que los datos de respuesta pueden incluir diversos tipos de información, tales como uno o más adjuntos (p. ej., archivos de medios, archivos de texto, etc.), referencias a objetos “en línea” necesarios para representar una página web, etc. Las realizaciones del procesador 522b de objeto pueden configurarse para interpretar los datos de respuesta, que pueden recibirse, por ejemplo, como HTML, XML, CSS, guiones Java u otros tipos de datos. Como se describe más completamente a continuación, el codificador 524b de deltadifusión puede generar una huella digital de los datos de la respuesta (p. ej., usando técnicas de codificación de diccionario) y usarla para diversos tipos de deltadifusión y/u otras funciones de optimización.

La huella digital puede usarse para determinar cómo tratar adicionalmente los datos de respuesta, como se describe a continuación. En algunas realizaciones, los datos de respuesta procesados y/o codificados (p. ej., comprimidos) se envían a través del enlace 125 de comunicación cliente-servidor al optimizador 220 de cliente. Los datos pueden enviarse como un flujo 525 de servicio de unidifusión desde el procesador 528b de unidifusión en el optimizador 230 de servidor hasta el procesador 528a de unidifusión en el optimizador 220 de cliente; y/o los datos pueden enviarse como uno o más flujos 515 de servicio de multidifusión desde el procesador 530b de multidifusión en el optimizador 230 de servidor hasta el procesador 530a de multidifusión en el optimizador 220 de cliente.

Además, cuando el enlace 125 de comunicación cliente-servidor puede incluir múltiples flujos 515 de servicio de multidifusión, los flujos 515 de servicio de multidifusión pueden configurarse de diversas maneras. En diversas realizaciones, por ejemplo, los flujos 515 de servicio de multidifusión se configuran para comunicarse cada uno en un punto de código de modulación diferente, en un haz puntual diferente y/o en una portadora diferente. Esto puede permitir una comunicación más eficaz del tráfico a los grupos de sistemas 110 de usuario que tienen unas características particulares. Por ejemplo, si se determina que un determinado tráfico se destina a un sistema 110 de usuario capaz de comunicarse en un punto de código de modulación particular, el tráfico puede transmitirse en multidifusión en un flujo 515 de servicio de multidifusión que opera en o cerca de este punto de código de modulación para lograr la máxima eficacia (p. ej., en lugar de en el punto de código de modulación más bajo necesario para transmitir a todos los sistemas del usuario 110 en el grupo de multidifusión). Aunque esto puede provocar, en determinados casos, que algunos de los sistemas 110 de usuario en el grupo de multidifusión sean incapaces de recibir de manera fiable todos los datos de multidifusión, todavía puede haber una mejora general en la operación del sistema 500 de comunicaciones.

En otras realizaciones, los códigos de modulación pueden tratarse (p. ej., seleccionarse, adaptarse, optimizarse, etc.) para diversos efectos. En una realización, como se ha descrito anteriormente, el código de modulación se selecciona de acuerdo con las condiciones de enlace entre el optimizador 230 de servidor y el optimizador 220 de cliente asociado a un cliente solicitante, si hubiera alguno (es decir, de tal manera que al menos el cliente solicitante pueda recibir la comunicación de manera fiable). En otra realización, el código de modulación puede seleccionarse de tal manera que al menos algún grupo umbral (p. ej., número) de clientes pueda recibir la comunicación de manera fiable. En otras realizaciones más, el código de modulación puede adaptarse a los cambios en las condiciones de enlace entre el optimizador 230 de servidor y uno o más optimizadores del cliente 120. Por ejemplo, pueden usarse técnicas de codificación y modulación adaptativas. El código de modulación puede adaptarse estimando o controlando las condiciones de enlace del lado de servidor (p. ej., estimando las relaciones de señal/ruido, el ancho de banda, etc.) o a través de la retroalimentación del lado de cliente. En una realización, el optimizador 220 de cliente comunica información, como si los paquetes se reciben de manera fiable, como retroalimentación al optimizador de servidor para ajustar de manera dinámica el código de modulación.

Los datos recibidos en el optimizador 220 de cliente desde el optimizador 230 de servidor pueden codificarse (p. ej., codificados en diccionario) y/o procesarse de otro modo (p. ej., de acuerdo con uno o más protocolos, como e1HTTP). Las realizaciones del procesador 522a de objeto y el codificador 524a de deltadifusión en el optimizador 220 de cliente se configuran para tratar el procesamiento y/o la descodificación de los datos de respuesta, respectivamente. Por ejemplo, las realizaciones del procesador 522a de objeto usan características del codificador 524a de deltadifusión, incluyendo la funcionalidad del diccionario 435 de cliente, para descodificar los datos de respuesta. Las realizaciones del procesador 522a de objeto pueden reenviar a continuación la respuesta descodificada al sistema 110 de usuario (o a otros componentes del sistema 110 de usuario, donde el optimizador 220 de cliente es parte del sistema 110 de usuario). La respuesta puede ser usada, a continuación, por los componentes del sistema 110 de usuario. Por ejemplo, un objeto de medios recibido como parte de los datos de respuesta puede reproducirse a través de un reproductor de medios en el sistema 110 de usuario, usarse para representar una página web a través del navegador web 514 de cliente, etc.

Se apreciará que, aunque la descripción anterior se centra en las solicitudes del navegador y las respuestas a esas solicitudes, las realizaciones de la invención funcionan dentro de muchos otros contextos. Por ejemplo, las realizaciones del sistema 500 de comunicación se usan para prestar servicios de Internet interactivos (p. ej., acceso a la red informática mundial, comunicaciones de correo electrónico, servicio e intercambio de archivos, etc.), servicios de televisión (p. ej., televisión de difusión por satélite, televisión de protocolo de Internet (IPTV), programación a la carta, etc.), comunicaciones de voz (p. ej., servicios telefónicos, telefonía de voz sobre protocolo de Internet (VoIP), etc.), servicios de conexión de red (p. ej., conexión de red de malla, VPN, VLAN, MPLS, VPLS, etc.) y otros servicios de comunicación. Como tales, los datos de “ respuesta” descritos anteriormente se conciben únicamente como un tipo ilustrativo de datos que puede recibir el optimizador 230 de servidor desde una fuente de contenido (p. ej., un servidor 150 de contenido). Por ejemplo, los datos de “ respuesta” pueden realmente enviarse, transmitirse en multidifusión o comunicarse de otro modo al usuario sin una solicitud explícita del usuario.

Para fines ilustrativos, el tráfico a través del sistema 500 de comunicaciones puede clasificarse en tráfico de interés privado y tráfico de interés público. El tráfico de interés privado puede incluir cualquier tráfico para el que la multidifusión del tráfico a múltiples sistemas 110 de usuario se considera ineficaz. Por ejemplo, cuando el tráfico es de interés únicamente para un sistema 110 de usuario, o un número muy pequeño de sistemas 110 de usuario, puede costar más configurar y procesar un flujo de servicio de multidifusión que simplemente transmitir en unidifusión el tráfico a cada sistema 110 de usuario interesado. De manera destacable, un sistema 110 de usuario puede actuar como nodo intermedio (p. ej., un concentrador, conmutador, encaminador, etc.) que reenvía información a múltiples usuarios finales. Por ejemplo, en una LAN, los datos pueden recibirse en el lado de cliente para todos los ordenadores en la LAN mediante un conmutador, que, a continuación, puede reenviar los datos a los usuarios adecuados en la LAN; tráfico que es de interés únicamente para un sistema 110 de usuario puede ser, de hecho, de: interés para muchos usuarios dentro de una LAN a la que presta servicio el sistema 110 de un usuario. Como alternativa, cada usuario en la LAN puede considerarse un sistema 110 de usuario separado que ejecuta un optimizador 220 de cliente separado. Como tal, la determinación relevante puede ser, desde la perspectiva del optimizador 230 de servidor, cuántos flujos 525 de servicio de unidifusión en el enlace 125 de comunicación cliente-servidor serían necesarios para transmitir en unidifusión los datos a todos los usuarios interesados. A diferencia del tráfico de interés privado, el tráfico de interés público puede incluir cualquier tráfico para el que la multidifusión del tráfico a múltiples sistemas 110 de usuario se considera más eficaz que la unidifusión del tráfico a cada sistema 110 de usuario interesado.

En particular, varios tipos de tráfico pueden ser o bien tráfico de interés privado o bien tráfico de interés público, dependiendo del contexto. Un ejemplo es el tráfico de control, que puede usarse para diversos tipos de control del sistema de comunicaciones. Por ejemplo, el tráfico de control puede usarse para enviar señales de control al optimizador 220 de cliente para dirigir al optimizador 220 de cliente a aceptar un flujo 515 de servicio de multidifusión particular. En una realización, el tráfico de control individual se envía como flujos 525 de servicio de unidifusión a optimizadores 120 de cliente particulares. En otra realización, un determinado tráfico de control se envía a los grupos de optimizadores 120 de cliente (p. ej., a algunos o todos los sistemas 110 de usuario a los que presta servicios un haz puntual particular de un sistema de comunicaciones por satélite) como uno o más flujos 515 de servicio de multidifusión.

Otro tipo de tráfico que puede ser o bien tráfico de interés privado o bien tráfico de interés público son los datos de objetos de medios. En una realización, un primer usuario graba un vídeo con una cámara digital como parte de una videoconferencia con un segundo usuario. El archivo de vídeo puede considerarse tráfico de interés privado, ya que puede ser de interés únicamente para el receptor y puede no solicitarse nunca, o incluso hacerse accesible, a otros usuarios en el sistema 500 de comunicaciones. En otra realización, un reportero de la CNN graba un vídeo con una cámara digital como parte de una transmisión en directo para CNN.com. El archivo de vídeo puede considerarse tráfico de interés público, ya que pueden acceder a él miles de usuarios en el sistema 500 de comunicaciones.

Por supuesto, la determinación de si clasificar el tráfico como tráfico de interés privado o tráfico de interés público puede hacerse de varias maneras y puede implicar muchos factores. Los factores usados para hacer la determinación pueden derivarse del propio tráfico o de otras fuentes (p. ej., de una evaluación de las condiciones de enlace actuales o el uso del sistema actual, de la información de terceros, etc.). Cuando se analiza el propio tráfico, la información puede derivarse de la parte de encabezamiento y/o la parte de contenido de los datagramas. Como se ha indicado anteriormente, la parte de encabezamiento puede proporcionar fuentes directas de información acerca de la comunicación y/o el contenido de la comunicación (p. ej., a través de información del protocolo, metadatos, etiquetas públicas o propietarias, etc.). Sin embargo, la información de la porción de encabezamiento puede estar limitada a menudo desde la perspectiva de un tipo intermediario de optimizador 230 de servidor. Por ejemplo, la información de encabezado relevante puede codificarse en un formato propietario, puede ser engañosa en cuanto a la secuencia subyacente, etc.

La parte de contenido del tráfico recibido en el optimizador 230 de servidor puede incluir los objetos reales (p. ej., los datos del archivo de contenido) que se envían a los usuarios a través de los respectivos sistemas 110 de usuario. Se apreciará que puede resultar difícil o imposible obtener determinados tipos de información observando únicamente la parte de contenido de los datagramas de tráfico, ya que la parte de contenido puede verse como una secuencia de bytes. Por supuesto, pueden usarse diversos tipos de procesamiento de datos (p. ej., análisis estadístico) para derivar información a partir de la secuencia de bytes, pero puede resultar difícil derivar información de nivel alto, tal como el tipo de archivo asociado a los datos. Por ejemplo, una película se emite desde un servidor de VOD (p. ej., como el servidor 150 de contenido) a un terminal de usuario 110. Las etiquetas propietarias en la parte de encabezamiento del tráfico pueden indicar el nombre de la película y el tipo de archivo para su procesamiento en el dispositivo de reproducción del usuario, mientras que la parte de contenido puede incluir únicamente la secuencia de bytes que definen el contenido de película real. Cuando la emisión de tráfico es interceptada por el optimizador 230 de servidor, el optimizador 230 de servidor puede ser incapaz de leer la parte de encabezamiento del tráfico, y puede, por lo tanto, ser incapaz de usar esa información para realizar la multidifusión y/u otras determinaciones.

Las realizaciones del optimizador 230 de servidor procesan la parte de contenido del tráfico como datos a nivel de byte usando diversas técnicas de deltadifusión. La Fig. 6 es un diagrama de flujo de un método 600 ilustrativo para el uso de deltadifusión para tratar el tráfico a través de un sistema de comunicaciones, de acuerdo con diversas realizaciones. Para mayor claridad, el método 600 se describe en el contexto del sistema 500 de comunicaciones de la Fig. 5. Se apreciará, sin embargo, que pueden realizarse diversas modificaciones en el sistema 500 de comunicaciones sin limitar el alcance del método 600.

Las realizaciones del método 600 comienzan en el bloque 604 recibiendo un bloque de datos de contenido. Por ejemplo, el bloque de datos de contenido (p. ej., datos de archivo, datos de emisión, datos de objeto web, etc.) puede recibirse como parte del tráfico interceptado por el optimizador 230 de servidor desde un servidor 150 de contenido a través del enlace 135 de red de contenido. En algunas realizaciones, en el bloque 608, se realiza una determinación inicial en cuanto a si el bloque de datos de contenido es un candidato de la multidifusión en función de uno o más criterios usados para definir un prefiltro de multidifusión 612. Esta determinación puede hacerse mediante el procesador 522b de objeto.

El prefiltro de multidifusión 612 puede definirse de acuerdo con cualquiera de los tipos de multidifusión o criterios de filtrado similares conocidos en la técnica. En una realización, el prefiltro de multidifusión 612 puede basarse en el tamaño del archivo del bloque de datos de contenido. Por ejemplo, únicamente los archivos más grandes que un determinado tamaño mínimo pueden considerarse para la multidifusión. En otra realización, la información de la parte de encabezamiento del tráfico puede usarse mediante el prefiltro de multidifusión 612. Por ejemplo, el prefiltro de multidifusión 612 puede definirse para realizar la determinación de multidifusión inicial en el bloque 608 de acuerdo con la dirección IP de origen, el URL de anfitrión, el IP de destino, el tipo de archivo, el protocolo, los metadatos de HTTP, etc. Por ejemplo, todos los archivos de vídeo por encima de un determinado tamaño procedentes de YouTube.com pueden considerarse candidatos de multidifusión, mientras que los archivos de vídeo que se envían como un adjunto de correo electrónico a un solo receptor pueden no considerarse candidatos de multidifusión.

En algunas realizaciones, los datos relevantes para el prefiltro de multidifusión 612 pueden potenciarse a través de relaciones de fuentes de confianza. Por ejemplo, pueden formarse relaciones contractuales con proveedores de contenido y servicios para permitir la visibilidad por parte de los proveedores de servicios en el contenido que atraviesa la red. Las realizaciones de las relaciones de fuentes de confianza incluyen acceso a claves de cifrado (p. ej., incluyendo claves maestras), autorización para servir o alojar de nuevo contenido (p. ej., a través de una relación de duplicación, como se describe más completamente a continuación), etc. En el contexto de estas relaciones, el optimizador 230 de servidor puede ser capaz de usar determinados tipos de metadatos propietarios para hacer determinaciones iniciales de multidifusión.

Cuando se determina en el bloque 608 que el bloque de datos de contenido no es un candidato de multidifusión, el bloque de datos de contenido (p. ej., o al menos una parte del bloque de datos de contenido) puede transmitirse en unidifusión, junto con cualquier dato de control relevante, al sistema o los sistemas 110 de usuario adecuados. Por ejemplo, como se ha descrito anteriormente, el bloque de datos de contenido puede procesarse mediante el procesador 522b de objeto y/o el codificador 524b de deltadifusión y enviarse como un flujo 525 de servicio de unidifusión a través del enlace 125 de comunicación cliente-servidor mediante los procesadores 528 de unidifusión. A continuación, los datos pueden recibirse mediante el optimizador del cliente 220, procesarse y/o descodificarse y reenviarse, según corresponda, a los componentes del sistema o los sistemas 110 de usuario.

Cuando se determina en el bloque 608 que el bloque de datos de contenido es un candidato de multidifusión (p. ej., de acuerdo con los criterios del prefiltro 612 de multidifusión), el bloque de datos de contenido se procesa adicionalmente mediante el optimizador 230 de servidor para determinar si va a enviarse de hecho, parte o la totalidad del bloque de datos de contenido a través de uno o más flujos 515 de servicio de multidifusión. En el bloque 620, se genera una huella digital (p. ej., se calcula una huella digital). En algunas realizaciones, la huella digital se genera en el bloque 620 mediante el codificador 524b de deltadifusión del optimizador 230 de servidor.

En determinadas realizaciones, la huella digital puede generarse usando funciones de comprobaciones aleatorias criptográficas (p. ej., generadas mediante una técnica de Message-Digest algorithm (algoritmo 5 de compendio de mensaje -[MD5]), funciones de comprobaciones aleatorias no seguras (p. ej., generadas mediante una técnica de cyclic redundancy check (comprobación de redundancia cíclica - [CRC]) u otras técnicas similares. En otras realizaciones, la huella digital puede generarse de cualquier manera, de tal manera que la huella digital resultante pueda usarse para indicar que una secuencia de bytes particular (o una parte de la secuencia de bytes) coincide con otra secuencia de bytes particular (p. ej., o una parte de otra secuencia de bytes). Se describen con más detalle realizaciones de la codificación de diccionario (p. ej., particularmente la codificación delta) y técnicas relacionadas en la solicitud de patente estadounidense n.° u S-12/477.814, titulada “ METHODS AND SYSTEMS FOR UTILIZING DELTA CODING IN ACCELERATION PROXY SERVERS” , presentada el 3 de junio de 2009.

En algunas realizaciones, la huella digital puede ser una versión comprimida de la secuencia de bytes. En otras realizaciones, la huella digital es una suma de verificación, comprobación aleatoria u otra técnica aplicada a algunos o todos los datos de objeto. Por ejemplo, en una realización, una suma de verificación del primer megabyte de datos en la secuencia de bytes puede usarse como huella digital. Esta huella digital puede compararse a continuación con otras huellas digitales para hallar una coincidencia. De manera destacable, las realizaciones pueden buscar, en última instancia, oportunidades de multidifusión y/u otras oportunidades de optimización del sistema 500 de comunicaciones. Como tal, puede ser ineficaz la generación de huellas digitales en bloques muy pequeños de datos (p. ej., a altas densidades), dado que puede no ser eficaz la explotación de las oportunidades cuando solo se identifican bloques pequeños como coincidencias. Además, la disminución del tamaño de los bloques puede aumentar el tamaño del diccionario.

Cabe señalar que el tráfico puede incluir más de solo el bloque de datos de contenido para el que se genera una huella digital o el tráfico puede incluir múltiples bloques de datos de contenido diferentes para los que se generan las huellas digitales. En un ejemplo, se recibe un archivo de medios en el procesador 522b de objeto del optimizador de servidor. El procesador 522b de objeto y/o el codificador 524b de deltadifusión pueden extraer los datos (p. ej., la información de encabezamiento) que no son necesarios para generar la huella digital en el bloque 620. En otro ejemplo, se recibe un correo electrónico que tiene el archivo de medios como adjunto. El procesador 522b de objeto y/o el codificador 524b de deltadifusión pueden realizar una etapa adicional de extracción de los datos de correo electrónico, además de los datos de encabezamiento y de otro tipo, para aislar eficazmente la secuencia de bytes para la generación de la huella digital en el bloque 620.

En el bloque 624, la huella digital se coteja con otras huellas digitales de otros bloques de datos de contenido en el sistema 500 de comunicaciones. La determinación de qué otros bloques de datos de contenido están “en el sistema 500 de comunicaciones” puede incluir diferentes tipos de análisis para diferentes casos de uso. Por ejemplo, en una realización, resulta deseable saber si la huella digital indica un bloque de datos de contenido coincidente ya almacenado en un sistema 110 de usuario particular (p. ej., en el diccionario 435 de cliente, etc.). En otra realización, resulta deseable saber si la huella digital indica un bloque de datos coincidente ya almacenado en el lado de servidor del sistema 500 de comunicaciones (p. ej., en el almacenamiento de lado de servidor (no mostrado) u otro almacenamiento accesible al optimizador 230 de servidor). En todavía otra realización, resulta deseable saber si la huella digital indica un bloque de datos coincidente que se comunica actualmente a través de un flujo 525 de servicio de unidifusión o uno o más flujos 515 de servicio de multidifusión. En diversas realizaciones, el módulo modelador 532 en el optimizador 230 de servidor se configura para almacenar modelos que pueden ser útiles para realizar diversas determinaciones (p. ej., modelos de diccionarios 435 de cliente, modelos de memorias caché o diccionarios de lado de servidor, modelos de flujos pasados y actuales enviados como flujos 525 de servicio de unidifusión o flujos 515 de servicio de multidifusión, etc.).

Se apreciará que pueden realizarse varios tipos diferentes de determinaciones, dependiendo de los bloques que se evalúan para hallar una coincidencia, facilitando cada una posibles oportunidades de deltadifusión. Se realiza tal determinación en algunas realizaciones en el bloque 628, donde la huella digital del bloque de datos de contenido generado en el bloque 620 se compara con los bloques del modelo de diccionario 632 de cliente para determinar si hay una coincidencia. Por ejemplo, las realizaciones del diccionario 435 de cliente en el optimizador 220 de cliente representan lo que se almacena en un cliente particular (p. ej., en un sistema 110 de usuario) y las realizaciones del módulo modelador 532 en el optimizador 230 de servidor almacenan un modelo de cada diccionario 435 de cliente. Si el bloque de datos de contenido se destina a un cliente particular, el optimizador 230 de servidor puede usar el modelo del respectivo diccionario 435 de cliente almacenado en el módulo modelador 532 para buscar coincidencias.

Si se identifica una coincidencia, esto indica que la secuencia de bytes (o la parte de la secuencia de bytes) ya está almacenada localmente en el cliente (p. ej. en el diccionario 435 de cliente del cliente). En ese caso, en el bloque 636, la totalidad o las partes relevantes del bloque de datos de contenido pueden comprimirse usando el modelo de diccionario (p. ej., índices de diccionario). En el bloque 640, la versión altamente comprimida del bloque de datos de contenido puede transmitirse en unidifusión a continuación al cliente. En algunas realizaciones, el bloque de datos de contenido se comprime mediante el codificador 524b de deltadifusión de lado de servidor y se comunica como flujo 525 de servicio de unidifusión al optimizador 220 de cliente a través de los procesadores de unidifusión 528.

Si no se encuentra ninguna coincidencia en el bloque 628, se evalúan uno o más tipos de oportunidades de multidifusión en el bloque 644. De acuerdo con diversas realizaciones, las oportunidades de multidifusión evaluadas en el bloque 628 pueden incluir oportunidades para la multidifusión de algunos o todos los datos del bloque de datos de contenido (p. ej., u otros datos) en función del hallazgo de coincidencias entre el bloque de datos de contenido y otros bloques en el sistema 500 de comunicaciones, como se ha descrito anteriormente. En un ejemplo, donde un bloque de datos de contenido que se solicita por parte de un primer usuario puede haberse comunicado ya a uno o más otros usuarios (determinado en función de los datos a nivel de byte), puede ser deseable crear un flujo 515 de servicio de multidifusión o añadir el usuario solicitante a un flujo 515 de servicio de multidifusión existente.

En algunas realizaciones, el método 600 evalúa las oportunidades de multidifusión en el bloque 644 incluso cuando se halla una coincidencia en el bloque 628 (p. ej., si se identifica una coincidencia parcial). Sin embargo, cabe señalar que la identificación de una coincidencia identificada en el bloque 628 puede indicar de manera típica que es posible una compresión muy alta de los datos (p. ej., en algunos casos, está disponible una compresión de 10.000 a l usando el diccionario 435 de cliente). Como tal, puede suponerse en algunas realizaciones que siempre es más eficaz sólo transmitir en unidifusión los datos altamente comprimidos en el bloque 640 que usar recursos de sistema para evaluar las oportunidades de multidifusión en el bloque 644 (p. ej., y potencialmente para configurar un flujo 515 de servicio de multidifusión).

Cuando las oportunidades de multidifusión se evalúan en el bloque 644, puede hacerse una determinación en el bloque 648 en cuanto a si existen oportunidades de multidifusión y si estas debieran explotarse. Por ejemplo, incluso cuando existe una oportunidad de multidifusión, puede ser ineficaz emplear los recursos para aprovechar la oportunidad (p. ej., para configurar un flujo 515 de servicio de multidifusión). De manera destacable, un tipo similar de determinación se ha descrito anteriormente con referencia al bloque 608. Sin embargo, la evaluación o las evaluaciones realizadas en el bloque 608 observó los metadatos, tamaños de archivo y otros tipos de encabezamientos de información. La evaluación o las evaluaciones realizadas en el bloque 644, por el contrario, usan datos a nivel de byte de la parte de contenido de los datagramas de tráfico y/o sus respectivas huellas digitales para ajustarse a determinados criterios (p. ej., otros bloques, etc.). Como se ha descrito anteriormente, la realización de las evaluaciones a nivel de byte (p. ej., usando huellas digitales) puede ser difícil por varios motivos.

Además, las oportunidades de multidifusión pueden evaluarse y la generación de huella digital puede adaptarse de diversas maneras dependiendo de los tipos de oportunidades que se evalúen (p. ej., la huella digital puede, por sí misma, ser una secuencia de bytes o parte de un sistema más complejo de determinación de la secuencia de bytes asociada). A modo de ejemplo, las huellas digitales pueden usarse en el contexto de la identificación de oportunidades de multidifusión con flujos de servicio actuales (p. ej., para ver si el contenido solicitado por un usuario se transmite en unidifusión o multidifusión actualmente a otros usuarios). A fin de facilitar este tipo de identificación, una realización genera mapas que tienen claves que son las diversas huellas digitales que identifican el bloque de datos de contenido y las cargas útiles que proporcionan datos acerca de las transferencias en progreso u otra información útil.

En determinadas realizaciones, los mapas pueden controlarse o fijarse o limitarse para que sean de un tamaño máximo predeterminado para evitar el procesamiento innecesario de datos. Por ejemplo, se usan técnicas para restringir los casos en los que la huella digital se añade al mapa. En una realización, se excluyen los protocolos que son “ no interesantes” . Por ejemplo, las huellas digitales pueden crearse únicamente para los protocolos conocidos (p. ej., predeterminados) que son interesantes, tales como HTTP, determinados protocolos de descarga de medios, etc. (p. ej., como se ha filtrado previamente en el bloque 608). En otra realización, se excluyen los objetos pequeños, tal como se ha descrito anteriormente con referencia al bloque 608. Por ejemplo, si el tamaño del objeto solicitado es conocido (o predecible) por adelantado, este puede usarse como filtro, si el objeto es más pequeño que algún tamaño umbral, la huella digital no se añade al mapa. Cuando el tamaño del objeto es desconocido (o no predecible prácticamente), las realizaciones pueden esperar hasta que se haya recibido al menos una cantidad mínima de datos y, a continuación, filtran el ruido (p. ej., los objetos muy pequeños). Por supuesto, puede ser importante evitar el retardo de la entrada del mapa demasiado tiempo, de tal manera que se provoque que el optimizador pierda una determinada coincidencia con una nueva descarga. En algunas realizaciones, cuando se completa la descarga, la huella digital se retira del mapa.

Si se realiza una determinación en el bloque 648 de que no existen oportunidades de multidifusión o que las oportunidades de multidifusión no deberían explotarse, los datos del bloque de datos de contenido y/o cualquier dato de control relacionado se transmite en unidifusión en el bloque 652, cuando sea adecuado. Por ejemplo, si el bloque de datos de contenido se solicita por parte de un usuario y no existe ninguna oportunidad de multidifusión, los datos del bloque de datos de contenido pueden transmitirse en unidifusión al usuario solicitante. En algunas realizaciones, la unidifusión de los datos en el bloque 652 implica comunicar los datos como un flujo 525 de servicio de unidifusión al optimizador 220 de cliente a través de los procesadores de unidifusión 528.

Si se hace una determinación en el bloque 648 de que existe una oportunidad de multidifusión y que debería explotarse, el bloque de datos de contenido puede transmitirse en multidifusión a uno o más clientes en el bloque 656 (p. ej., incluyendo el cliente solicitante, cuando sea adecuado). En algunas realizaciones, la multidifusión de los datos en el bloque 656 implica comunicar los datos de bloque de contenido a través de uno o más flujos 515 de servicio de multidifusión al optimizador 220 de cliente mediante los procesadores 530 de multidifusión. En determinadas realizaciones, la huella digital generada en el bloque 620 u otra representación de los datos (p. ej., la propia secuencia de bytes, una versión comprimida o una parte de la secuencia de bytes o un tipos diferentes de huella digital) se almacena en el lado de servidor para su uso posterior por parte del sistema 500 de comunicaciones. Por ejemplo, el almacenamiento de información relevante puede ser útil en la generación o identificación de futuras oportunidades de multidifusión, el seguimiento y/o la caracterización del uso de red, la búsqueda anticipada, etc.

De manera similar al proceso descrito anteriormente para el sistema de las Figs. 1A-IC, cuando un sistema 210 de usuario haya solicitado los datos de archivo para los que un bloque se transmite en multidifusión actualmente, se procederá inmediatamente a la comprobación y corrección de errores con el fin de permitir que el sistema de usuario que solicitó los datos del archivo use los datos de archivo en la etapa 690. Con el fin de evitar sobrecargar el canal inverso, las solicitudes de error de los bloques preposicionados de manera especulativa en la etapa 692 para al menos una parte de los sistemas en los que el objeto se preposicionó de manera especulativa pueden no producirse hasta que el sistema en el que se ha preposicionado el archivo solicite el archivo. En un sistema que usa huellas digitales, el servidor que crea las huellas digitales puede proporcionar un identificador único a nivel global para todos los bloques que se transmiten en multidifusión. Por tanto, cualquier sistema puede usar el identificador único a nivel mundial para identificar los bloques de datos en los que haya errores o paquetes que falten. En los sistemas en los que los datos se preposicionaron de manera especulativa, esta lista de bloques que contienen errores puede almacenarse hasta que se solicite el objeto asociado al bloque. Esta lista de bloques puede habilitar además que un sistema observe un canal para detectar mensajes de reparación de objeto de multidifusión.

Al igual que en el 608, un sistema decide si un bloque de datos que se envía como mensaje de reparación de objeto puede ser un candidato de multidifusión, el sistema puede usar un proceso similar o idéntico para determinar si transmitir en multidifusión un mensaje de reparación de objeto. Basándose en la determinación, un mensaje de reparación de objeto puede enviarse como mensaje de reparación de objeto de unidifusión o como mensaje de reparación de objeto de multidifusión. En una posible realización, un sistema de multidifusión puede identificar los paquetes que faltan y retransmitir esos paquetes. En realizaciones alternativas, un sistema de multidifusión puede recibir un mensaje de fiabilidad que incluya simplemente el identificador único a nivel mundial para un bloque de datos, indicando que un primer usuario identificó errores en ese bloque de datos. El sistema de multidifusión puede determinar a continuación si el bloque de datos puede ser un candidato de multidifusión. Tal determinación puede basarse en mensajes de fiabilidad recientemente recibidos asociados al mismo bloque o basarse en consideraciones de ancho de banda. Si el bloque es un candidato de multidifusión, todo el bloque puede transmitirse en multidifusión como un mensaje de reparación de objeto, junto con el identificador único a nivel mundial. Un primer usuario recibirá el bloque como parte de un primer mensaje de reparación de objeto y comprobará inmediatamente si hay errores con la copia recientemente recibida del bloque. Los sistemas que han recibido inicialmente el objeto colocado de manera especulativa pueden almacenar la segunda transmisión del bloque junto con la primera transmisión del bloque hasta que el objeto se solicite en esos sistemas. Como alternativa, esos sistemas pueden iniciar un proceso de comprobación de errores basándose en la recepción de la segunda copia del bloque y comprobar si hay errores en ambas copias.

Se apreciará, en algunas realizaciones, que los datos de multidifusión o unidifusión se implementan de diferentes maneras. Por ejemplo, en el sistema 200 de comunicaciones por satélite de la Fig. 2, algunos o todos los receptores (p. ej., los sistemas 110 de usuario) en un haz puntual 235 pueden ser capaces intrínsecamente de recibir al menos una parte de cualquier tráfico que se envíe a través del haz puntual 235 en virtud de lo cual se sintonizan a la portadora apropiada, capaces de recibir datos en el punto de código de modulación actual, etc.; de manera eficaz, el sistema 200 de comunicaciones por satélite difunde todo por el aire. Como tal, como se ha descrito anteriormente con referencia a la Fig. 1B, la unidifusión o multidifusión a uno o más sistemas 110 de usuario puede implicar, de hecho, la difusión de los datos a través del enlace por satélite o el sistema de comunicación por cable y también la difusión de datos de control a receptores directos para que acepten o ignoren partes relevantes de los datos de difusión.

En una realización ilustrativa, un sistema puede determinar que el contenido solicitado por un usuario tiene una alta probabilidad de ser accedido por un grupo de usuarios no solicitantes que compartan un haz puntual por satélite en el sistema 500 de comunicaciones. El contenido se difunde a través del enlace por satélite con un identificador de flujo que lo designa como flujo de multidifusión. Los datos de control también se envían dirigiendo los sistemas 110 de usuario asociados con los usuarios interesados a “escuchar” el flujo de multidifusión (p. ej., a aceptar, en lugar de ignorar, datos con ese identificador de flujo a medida que se reciben). De hecho, esto crea un grupo de multidifusión de los usuarios interesados. En diferentes realizaciones, los datos de control pueden comunicarse al grupo de multidifusión o bien como flujos 525 de servicio de unidifusión respectivos a cada cliente a través de los procesadores 528 de unidifusión o bien como parte de un canal de control de multidifusión enviado a través de un flujo 515 de servicio de multidifusión mediante los procesadores 530 de multidifusión. Se apreciará que, en aras de la eficacia de ancho de banda, las realizaciones envían de manera típica los datos de control a través del canal de control de multidifusión. Por ejemplo, todos los sistemas 110 de usuario pueden estar escuchando constantemente el canal de control de multidifusión para averiguar (p. ej., entre otras cosas) qué flujos deberían aceptar. Por supuesto, son posibles otras implementaciones de acuerdo con diversas realizaciones para la unidifusión o multidifusión de los datos a través de diversos flujos 525 de servicio de unidifusión y/o flujos 515 de servicio de multidifusión al optimizador u optimizadores 120 de cliente.

Una vez que los datos se reciben en el optimizador 220 de cliente, pueden almacenarse en el lado de cliente (p. ej., los bloques de los datos pueden almacenarse e indexarse por el diccionario 435 de cliente). En determinadas realizaciones, el almacenamiento en el diccionario 435 de cliente provoca en última instancia que se refleje un registro de los datos en el optimizador 230 de servidor si se actualiza un modelo del diccionario 435 de cliente de lado de cliente (p. ej., a través de la sincronización del módulo 532 modelador). Cuando se determina en el bloque 648 que los datos se transmitirán en multidifusión en el bloque 656 (p. ej., y/o cuando se determina que los datos se transmitirán en unidifusión en el bloque 652), los datos pueden comprimirse y/o codificarse de otro modo antes de que se envíen a través del enlace 125 de comunicación cliente-servidor. En una realización, los datos se codifican en formato zip antes que se envíen a través del enlace 125 de comunicación cliente-servidor. Cuando los datos codificados en formato zip se reciben en el optimizador 220 de cliente, los datos se añaden al diccionario 435 de cliente.

Incluso con el uso de esta codificación, el ancho de banda del canal inverso sigue siendo valioso y puede usarse una fiabilidad retardada para los objetos buscados de manera anticipada. Por tanto, después de la multidifusión en la etapa 656, se procederá inmediatamente a la comprobación y corrección de errores en la etapa 690 para el sistema 210 de usuario que solicitó los datos de archivo para los que se transmite en multidifusión actualmente un bloque, con el fin de permitir que el sistema de usuario que solicitó los datos del archivo use los datos de archivo. Con el fin de evitar sobrecargar o usar innecesariamente el canal inverso, incluso con las eficacias de codificación de biblioteca, las solicitudes de error de los bloques preposicionados de manera especulativa pueden no producirse hasta que el sistema en el que el archivo se ha preposicionado solicite el archivo en la etapa 692.

A continuación, se apreciará que las realizaciones permiten el uso de huellas digitales, generadas a nivel de byte de la parte de contenido del tráfico que atraviesa la red, para identificar y/o explotar las oportunidades de multidifusión. Por supuesto, la generación de las huellas digitales, como se describe en el contexto del método 600 de la Fig. 6, puede habilitar también características adicionales. En particular, la generación de las huellas digitales puede permitir un nivel de conocimiento del contenido, incluso cuando el optimizador 230 de servidor actúa como protocolo de interceptación transparente y tiene poco o ningún acceso a determinada información de alto nivel (p. ej., información de parte de encabezamiento, como URL, tipos de archivo u otros metadatos).

Por ejemplo, aunque el método 600 se describió en términos de procesamiento de un único bloque de datos a medida que se recibía en el bloque 602, realizaciones del sistema 500 de comunicaciones pueden llevar a cabo, de hecho, estas etapas numerosas veces. Por ejemplo, durante un período de operación de red, pueden procesarse millones de solicitudes de miles de clientes, lo que da como resultado cantidades masivas de tráfico que atraviesan el sistema 500 de comunicaciones. Mientras tanto, pueden generarse y/o almacenarse grandes cantidades de huellas digitales de datos, lo que puede producir oportunidades de procesamiento estadístico para determinar las tendencias y/u otra información de uso. Este tipo de información puede usarse a continuación para desarrollar indirectamente un conocimiento de contenido (p. ej., hacer determinadas suposiciones sobre las secuencias de bytes, como la popularidad de contenido, las correlaciones de usuario, etc.), incluso cuando se limita el uso de los metadatos.

Cabe señalar que el uso de huellas digitales (p. ej., y/u otras técnicas de codificación de diccionario) para hacer la multidifusión y determinación relacionada puede proporcionar varias características. Una característica es que las oportunidades de deltadifusión pueden identificarse y/o explotarse incluso cuando hay poco o ningún acceso a determinados metadatos. Por ejemplo, como se ha descrito anteriormente, el optimizador de servidor genera firmas basándose en datos a nivel de byte y puede no requerir el conocimiento de información de la “parte de encabezamiento” (p. ej., tipos de archivo, etiquetas propietarias, etiquetas de protocolo, etc.) para realizar sus determinaciones.

Otra característica es que las técnicas de registro de huella digital pueden permitir que se identifiquen oportunidades de deltadifusión, incluso cuando la fuente de contenido u otra información de “parte de encabezamiento” (p. ej., los metadatos) es diferente. Por ejemplo, se dice que los espectadores están viendo el mismo programa de televisión en el mismo momento desde diferentes fuentes (p. ej., diferentes canales de televisión están difundiendo el mismo contenido, diferentes sitios web están duplicando el mismo contenido, etc.). Las técnicas de registro de huella digital pueden hallar bloques coincidentes, ya que los bloques coincidirán incluso cuando las fuentes de contenido son diferentes. De manera similar, pueden identificarse las oportunidades de deltadifusión incluso cuando se usan la reducción de almacenamiento en memoria caché, el anonimizador, la suplantación de identidad, la duplicación y/u otras técnicas (p. ej., para alterar URL, para implementar la funcionalidad de la red de datos de contenido (CDN), etc.).

Otra característica es que pueden usarse técnicas de deltadifusión de manera transparente para conservar las comunicaciones desde la perspectiva de los usuarios finales y las fuentes de contenido. En particular, un usuario final y una fuente de contenido pueden experimentar de manera eficaz las mismas comunicaciones byte a byte con o sin deltadifusión. Por ejemplo, aunque las solicitudes y/o respuestas se interceptan de acuerdo con las realizaciones de deltadifusión, cuando un usuario solicita datos de una fuente de contenido, la fuente de contenido puede proporcionar, en última instancia, los mismos bytes al usuario final como si hubiera un enlace de unidifusión entre el usuario final y la fuente de contenido.

También cabe señalar que las realizaciones permiten la optimización sustancialmente transparente de las comunicaciones, al tiempo que conservan determinadas relaciones legales y comerciales, incluyendo derechos de autor, gestión de derechos digitales, suscripción y/u otras obligaciones. Por ejemplo, como se ha descrito anteriormente, los datos de contenido se almacenan en diccionarios de manera eficaz como bloques disociados de datos, de tal manera que el contenido pueda recrearse únicamente a partir de esos bloques usando referencias de diccionario adecuadas (p. ej., índices). De acuerdo con diversas realizaciones, esas referencias de diccionario no están disponibles para los clientes sin una nueva solicitud de la fuente de contenido.

IV. Realizaciones alternativas

En una posible realización, un único procesador 530b de multidifusión puede servir a todas las sesiones en un optimizador 529 de servidor. Pueden soportarse múltiples canales, de tal manera que el protocolo de transporte puede permitir que cualquier sesión use cualquier canal, y las asignaciones de sesión se realizan en un módulo que usa el transporte. Cada canal puede tener una instancia de control separada que contenga los módulos asociados al canal, tales como un grupo regulador, un módulo remitente, colas redundantes y datos de control. Muchos flujos de datos diferentes pueden enviarse de manera simultánea a través de un único canal en tal sistema, con los algoritmos separados proporcionados para el envío de paquetes de control y de datos. Los paquetes de control pueden enviarse en un canal en el que todos los usuarios están escuchando. Los paquetes de control contienen información acerca de los datos que se envían sobre los canales. En una posible realización, un canal de control podría usar una tasa de símbolos baja, de tal manera que puedan recibirla todos los clientes, y, a continuación, los clientes podrían usar estos datos para decidir qué flujos recibir.

En esta posible realización no limitante, los paquetes de control pueden necesitar una estrategia de fiabilidad diferente de la estrategia de fiabilidad usada por los datos. Debido a que los paquetes de control consisten a menudo en paquetes individuales aislados y se envían a todos los usuarios sin ningún usuario preferido, puede no ser preferible la confirmación negativa para los paquetes de control. En tal realización, el envío de una o más copias redundantes, con un retardo entre las mismas para reducir las posibilidades de que un problema de enlace temporal provoque que ambas copias se descarten, puede ser un método preferible de compensación de los posibles errores, sin que se usen ACK ni NACK para estos paquetes.

En cuanto a la fiabilidad de los datos en una posible realización, la estrategia para la fiabilidad del paquete de datos puede ser el uso de NACK más los números de secuencias que permitan al receptor detectar huecos en la secuencia. Los últimos paquetes en una página o un flujo tienen banderas fijadas de tal manera que el receptor pueda usar un temporizador para detectar los paquetes que faltan al final. Las copias redundantes del último paquete pueden enviarse para reducir la dependencia de los temporizadores para identificar el final de una transmisión. En una posible realización, todos los receptores pueden emitir NACK, con los receptores que están preposicionando de manera especulativa los datos esperando hasta que los datos sean solicitados por el receptor individual específico para emitir una NACK para los paquetes que faltan.

La Fig. 7 describe una realización ilustrativa de un protocolo de transporte de multidifusión con fiabilidad retardada para su uso con un canal de comunicación de multidifusión de acuerdo con la realización inmediatamente descrita anteriormente. El proceso de la Fig. 7, de manera típica, comienza con una solicitud de un objeto hecha por un primer sistema de usuario. En la etapa 702, la solicitud de objeto se recibe en el sistema 220 de servidor y se comunica, a continuación, al servidor 250 de contenido. En la etapa 704, el objeto se recibe en el sistema 220 de servidor, se identifica mediante el sistema como un candidato de multidifusión y se notifica a un módulo programador 335.

En la etapa 706, se envía un mensaje de control de flujo de inicio. Un flujo es un archivo o una serie de archivos implicados en una única transferencia de deltadifusión. Un paquete o más paquetes de control pueden proporcionar información acerca del flujo que se enviará y el ID de flujo de tal manera que cada receptor puede decidir si aceptar y almacenar en memoria caché el flujo. El paquete o los paquetes de control de flujo de inicio que son parte del mensaje de control pueden incluir el nombre de anfitrión de HTTP y el URL. Si cada receptor va a tomar decisiones de almacenamiento en memoria caché, el paquete o los paquetes de control de flujo de inicio también podrían incluir otros datos acerca del flujo, tales como diversos clasificadores y palabras clave que describan el contenido. Si las decisiones de almacenamiento en memoria caché se van a controlar desde el lado de servidor, el paquete de control puede incluir una lista de terminales de usuario o clasificaciones de terminales de usuario que deberían almacenar en memoria caché los datos. El sistema puede comprobar primero si se ha inicializado una conexión desde un sistema 220 de servidor hasta un sistema 210 de usuario. Si no, puede crearse una conexión de multidifusión de UDP de acuerdo con los parámetros de configuración proporcionados para el canal particular. A continuación, el paquete de control puede enviarse a la conexión de UDP y comunicarse a los sistemas de usuario. Una vez que el flujo ha comenzado, un codificador de deltadifusión 524 puede enviar datos a través del procesador 530 de multidifusión. Los módulos de envío pueden recibir un bloque de datos desde un codificador junto con la información de control, tal como el canal, ID de flujo, ID de página y posición de página.

Cuando se envía un flujo nuevo, un procesador 530 de multidifusión puede ajustar primero la pertenencia a un grupo regulador asociado a un canal. Si el paquete es el primer paquete para un conjunto de flujo asociado, el flujo puede añadirse a un grupo regulador para un canal. El fin del grupo regulador es bloquear las conexiones entrantes cuando el canal de multidifusión está respaldado debido a las restricciones de ancho de banda. Si el paquete es el último paquete para un conjunto de flujo, el flujo puede retirarse del grupo regulador para el canal.

A continuación, se añade un paquete o grupo de paquetes a una cola. Cuando el sistema está listo para emitir paquetes, aparece un bloque al principio de la lista. Cuando todos los datos se han empaquetado, el bloque se libera y el procesador 530 de multidifusión emite tantos datos como permitan los actuales límites de ancho de banda. Después de que cada paquete se sintetice, se añade una copia a una lista de retransmisión en caso de que se reciba una NACK u otra solicitud de fiabilidad desde un usuario dentro de un período de tiempo dado. Después de enviar el paquete, se comprueba el regulador para ver si el envío del paquete permite liberar el regulador. Los paquetes se transmiten a continuación a los sistemas de usuario como parte de la etapa 706.

En la etapa 708, un receptor de sistema de usuario controla un conjunto de canales para los datos entrantes. Tal receptor puede simplemente leer los datos de todas las entradas o puede distinguir entre los datos y los paquetes de control con el fin de determinar qué objetos recibir. En determinadas realizaciones, un receptor lee el encabezamiento del paquete entrante. Si el paquete está comenzando un nuevo flujo, el receptor comienza un nuevo archivo. A continuación, el receptor comprueba si es necesario comenzar una nueva página. En una posible implementación, las páginas son páginas de 1 Mbyte, pero, como alternativa, pueden ser de cualquier tamaño o formato adecuado. Cada archivo puede consistir en una o más páginas. Se fija una bandera de inicio de flujo para el primer paquete en el primer bloque de la primera página y la bandera de finalización de flujo se fija para el último paquete en el último bloque de la última página.

Como parte de la etapa 710, se crea un mapa para hacer el seguimiento de cada página del archivo y que hace un seguimiento de qué paquetes se han recibido. Este seguimiento puede hacerse a través de un mapa de datos de página, que combina entradas consecutivas, de tal manera que haya una entrada de mapa para cada 'hueco' en el mapa. En un sistema de usuario solicitante, el receptor emite NACK en la etapa 712 cuando se detectan huecos. El receptor puede escanear periódicamente el un mapa y emitir NACK para todos los huecos en la página. El mapa puede usarse, además, para detectar cuándo una página está completa y lista para cargarse. Si falta el último paquete, un temporizador puede configurarse para emitir una NACK indicando que la bandera de finalización de flujo no se recibió. Dado que el mapa contiene esencialmente una lista de huecos, la página está completa cuando se ha visto el final de la página, pero no hay ninguna entrada de hueco de mapa. Si se necesita enviar una NACK, puede añadirse un encabezamiento con los datos de paquete para identificar el hueco y, a continuación, la NACK se enviará a través de la conexión ITP de sesión. El sistema de servidor responde a las NACK en la etapa 714, hasta que la descarga de archivo para el sistema de usuario solicitante se completa en la etapa 716. Al mismo tiempo, los sistemas de usuario que no solicitaron los paquetes de objetos y componentes han recibido los paquetes sin emitir NACK. Estos sistemas pueden contener paquetes y el mapa de datos de página durante un breve período para capturar y transmitir en multidifusión de nuevo los paquetes que se envían en respuesta de otras NACK de sistemas y el preposicionamiento especulativo de los paquetes se completa a continuación para estos sistemas en la etapa 718.

Si todavía faltan paquetes para un archivo preposicionado de manera especulativa, las localizaciones de los datos que faltan pueden leerse a partir del mapa de datos de página en un bloque de deltadifusión. Los bloques de deltadifusión pueden incluir no solo los datos e identificadores de bloques, sino también una lista de cualquier paquete que falte. Las entradas de índice de diccionario normalmente tienen un tamaño fijo, pero la cantidad de datos necesarios para describir las localizaciones que faltan puede ser diferente para cada bloque. Esto puede requerir la creación de un nuevo bloque de almacenamiento para almacenar datos de huecos. Las entradas de índice de diccionario fijas pueden especificar el inicio de estos datos en un almacenamiento temporal circular o NULO si no faltan paquetes. A continuación, una cadena de mensajes puede describir los huecos de una página que tiene paquetes que faltan. El tamaño de un almacenamiento temporal circular debe ser lo suficientemente grande como para incluir todos los datos que falten de todos los bloques de un cliente con un enlace deficiente, ya que el tamaño de tal almacenamiento temporal todavía será pequeño en comparación con los bloques de datos y un bloque de deltadifusión es inútil sin la información de huecos.

En algún punto, un sistema con un bloque preposicionado de manera especulativa con huecos iniciará una solicitud de un objeto asociado. Un sistema 220 de servidor recibe tal solicitud del objeto en la etapa 720. Esta realización habilita que el sistema compruebe en un servidor si hay cambios en el objeto, dado que este se preposicionó de manera especulativa. En realizaciones alternativas, el sistema simplemente puede enviar una solicitud de los huecos si, por ejemplo, no ha transcurrido un tiempo de permanencia.

En la realización de la Fig. 7, el sistema 220 de servidor responde a la solicitud en la etapa 720 recuperando el objeto en la etapa 722. Un codificador de deltadifusión 524 puede pasar, a continuación, bloques de objetos a un módulo en el que se calculan sumas de verificación como datos de coincidencia. Los datos de coincidencia se envían junto con un identificador de bloque en la etapa 726. Cuando el decodificador delta en el receptor desempaqueta el identificador de bloque en la etapa 726, comprueba su índice para ver si falta algún paquete en el bloque. Si es así, este envía un mensaje de control de ITP de vuelta al remitente solicitando la retransmisión de estos datos en la etapa 728. El remitente recibe este mensaje y crea paquetes de salida de ITP que incluyen los datos de huecos que faltan en la etapa 730. Estos datos deben enviarse sin pérdidas con el fin de habilitar el uso del objeto en respuesta a la solicitud del objeto. Los datos de huecos pueden transferirse usando un flujo secundario de ITP global especial usando redundancia u otros mecanismos de fiabilidad, y los datos de huecos se transmiten al sistema de usuario solicitante en la etapa 730. Después de la recepción de los datos de huecos por el receptor, se construyen los bloques completos y se completa la descarga de archivos.

En una realización ilustrativa alternativa, un primer usuario ve una película a través de un sitio web de vídeo a la carta popular iniciando sesión en el sitio web usando credenciales (p. ej., un nombre de usuario y contraseña) y visualizando la película a través de un reproductor incorporado rodeado de anuncios publicitarios. Basándose en una o más determinaciones descritas anteriormente, el contenido fijado para el sitio web puede transmitirse en multidifusión al primer usuario (solicitante) y a un segundo usuario (no solicitante) y puede almacenarse en el diccionario de cliente del segundo usuario sin comprobación de errores en el diccionario de cliente del segundo usuario. El diccionario de cliente del segundo usuario puede incluir ahora bloques de datos de una película que incluyan material protegido por derechos de autor, de una sesión web autenticada de acuerdo con las credenciales de otro usuario, de anuncios que pueden reciclarse y/o rastrearse, de objetos web que se designan en los metadatos como “ no almacenables en memoria caché” , etc. Como se ha descrito anteriormente, realizaciones del diccionario de cliente almacenan los bloques de datos de tal manera que puede resultar efectivamente imposible que el primer usuario acceda al contenido de película directamente desde el diccionario de cliente.

En cambio, si el segundo usuario solicita la película posteriormente, la experiencia del segundo usuario puede ser muy parecida a la del primer usuario (p. ej., y muy parecida a la que habría tenido si los datos no se hubieran almacenado en el diccionario de cliente). Por ejemplo, el segundo usuario puede seguir visitando el sitio web usando un navegador web y puede seguir iniciando sesión con credenciales. Si está autorizado, el segundo usuario puede seguir solicitando una copia autorizada con licencia del archivo de película desde el sitio web, que a continuación puede verse en el reproductor incorporado rodeado de anuncios publicitarios. Sin embargo, a medida que se reciben los datos en respuesta a la solicitud, se usan técnicas de deltadifusión para registrar las huellas digitales de los datos e identificar los datos ya almacenados en el diccionario de cliente del segundo usuario. Pueden identificarse los huecos usando los identificadores de bloques y la coincidencia de suma de verificación, con los datos de huecos enviados al segundo sistema de usuario para completar los datos solicitados por el segundo usuario. Los datos pueden comunicarse o presentarse a continuación al segundo usuario en consecuencia, por ejemplo, comprimiendo altamente los datos de acuerdo con un modelo del diccionario de cliente almacenado en el lado de servidor del sistema de comunicaciones (p. ej., un modelo de diccionario de cliente).

Como tal, el uso de técnicas de deltadifusión puede conservar las obligaciones legales y de otro tipo para las transacciones de contenido. En el ejemplo anterior, el segundo usuario es incapaz de acceder al material protegido por derechos de autor y/o no autorizado desde el diccionario de cliente. Además, el hecho de obligar al segundo usuario a acceder al contenido según lo previsto por el proveedor de contenido (p. ej., a través del sitio web del proveedor) puede permitir al proveedor de contenido conservar la publicidad, el alojamiento y/u otras relaciones. Por ejemplo, si el proveedor de contenido ofrece por casualidad un anuncio que ya está almacenado en el diccionario de cliente, el anuncio puede seguir solicitándose a través del enlace de red de contenido (p. ej., proporcionando de este modo cualquier seguimiento de anuncio asociado, ingresos, etc.), al tiempo que también se comprime altamente a través del enlace de comunicaciones cliente-servidor. Esto puede habilitarse adicionalmente mediante el uso de la fiabilidad retardada, de tal manera que un archivo que no se haya comprobado en busca de errores y cualquier error en el archivo antes de la solicitud del archivo pueda crear esencialmente un archivo no reproducible, conservando de este modo las obligaciones legales y de otro tipo para las transacciones de contenido.

Las Figs. 8 y 9 muestran realizaciones alternativas adicionales. En algunas circunstancias, un sistema puede aprovechar el uso fuera de horas punta u otros momentos cuando el sistema no opera a su capacidad total para preposicionar de manera especulativa los archivos que no han sido seleccionados por ningún usuario. En estas circunstancias, el canal inverso puede seguir siendo el factor limitador y grandes volúmenes de errores en los archivos preposicionados de manera especulativa pueden sobrecargar el canal inverso y degradar el rendimiento para otros usuarios. En estos casos, el sistema puede identificar a un usuario para emitir los mensajes de error, como en la Fig. 8. Este usuario identificado o “canario” puede seleccionarse de manera aleatoria o basándose en las características identificadas que habilitan que un usuario identificado represente la dinámica de error común del usuario en el sistema. Como alternativa, el sistema puede operar sin ninguna detección de errores inicial, como en la Fig. 9. En otras realizaciones alternativas adicionales, un sistema de multidifusión puede incluir determinados umbrales de decisión sobre cuándo transmitir en multidifusión los mensajes de reparación de objeto y cuándo utilizar la comprobación de errores retardada. Por ejemplo, el sistema puede transmitir en unidifusión los mensajes de reparación de objeto hasta que se observe una determinada cantidad de solicitudes de error de los usuarios solicitantes del mismo objeto o datos de bloque, tras lo que se pueden transmitir en multidifusión los mensajes de reparación. Como alternativa, el sistema puede identificar usuarios “canarios” después de recibirse un primer mensaje de fiabilidad. A continuación, el sistema puede solicitar la información de error de uno o más usuarios que hayan recibido los datos como una colocación especulativa o preposicionando de manera especulativa los datos a los usuarios canarios con una solicitud específica de mensajes de fiabilidad inmediata como una forma si identificar si un mensaje de fiabilidad inicial desde un usuario solicitante se debió a un error individual del sistema o a un error del sistema que afectaría a muchos sistemas. A continuación, puede realizarse una decisión de multidifusión basándose en los resultados de la transmisión al usuario canario.

En la Fig. 8, el sistema inicial realiza una etapa de identificar los objetos para el preposicionamiento especulativo en la etapa 802. Dado que el objeto no se identifica mediante una selección inicial de usuario, la identificación puede hacerse basándose en los datos de uso recopilados en un servidor intermediario, un servidor de contenido, un sistema de usuario o grupos grandes de cualquier combinación de sistemas. El objeto también puede seleccionarse basándose en una demanda prevista, tal como el lanzamiento de una nueva película para la que no existe un historial específico de datos de uso.

Después de seleccionarse un objeto y fijarse el sistema, el objeto se recibe y procesa para su multidifusión en la etapa 804. Al igual que con las etapas correspondientes en la Fig. 7, en las etapas 806, 808 y 810, el objeto se envía a los sistemas de usuario. En la etapa 812, el usuario identificado emite mensajes de error. En este punto, dado que los mensajes de error no son específicamente para crear un archivo para su uso inmediato por parte del usuario identificado, los mensajes de error se envían para habilitar la multidifusión de mensajes de error para todos los usuarios que reciben el objeto a medida que los paquetes de datos se retransmiten en la etapa 814. En 816 y 818, el archivo se completa en el usuario identificado y el preposicionamiento se termina en otros sistemas de usuario.

Después de completar el preposicionamiento especulativo, un usuario puede solicitar el objeto en la etapa 820. En las etapas 822-832, la comprobación de fiabilidad retardada se realiza como en la Fig. 7 y se completa el archivo con comprobación de errores para el usuario en el sistema de usuario solicitante.

De manera similar, en la Fig. 9, el sistema inicial realiza una etapa de identificar los objetos para su preposicionamiento especulativo en la etapa 902. De nuevo debido a que el objeto no se identifica mediante una selección inicial de usuario, la identificación puede hacerse basándose en los datos de uso o cualquier otra métrica beneficiosa identificada. Después de seleccionarse un objeto y fijarse el sistema, el objeto se recibe y procesa para su multidifusión en la etapa 904. Al igual que con las etapas correspondientes en la Fig. 7, en las etapas 906, 908 y 910, el objeto se envía a los sistemas de usuario. A diferencia de las realizaciones de la Fig. 7 y la Fig. 8, no se realiza ninguna comprobación inicial de errores y cada sistema de usuario se vincula a una fiabilidad retardada. En la etapa 918, el preposicionamiento especulativo se finaliza en todos los sistemas de usuario. Después de completar el preposicionamiento especulativo, un usuario puede solicitar el objeto en la etapa 920. En las etapas 922-932, la comprobación de fiabilidad retardada se realiza como en la Fig. 7 y se completa el archivo con comprobación de errores para el usuario en el sistema de usuario solicitante.

En realizaciones alternativas adicionales, los usuarios identificados pueden participar en la comprobación de errores retardada, funcionando como propietarios de confianza de una copia con comprobación de errores en lugar del servidor, cuando un usuario selecciona el objeto e inicia la fiabilidad retardada. Tales implementaciones han añadido complejidad, pero el beneficio de evitar el uso del canal inverso y el canal directo de alta latencia en algunos sistemas. Otras realizaciones pueden usar cualquier combinación de los métodos identificados anteriormente.

La descripción anterior pretende proporcionar diversas realizaciones de la invención, pero no representa una lista exhaustiva de todas las realizaciones. Por ejemplo, los expertos en la materia apreciarán que diversas modificaciones están disponibles dentro del alcance de la invención. Además, aunque la descripción incluye diversas secciones y títulos, las secciones y los títulos no pretenden limitar el alcance de cualquier realización de la invención. Más bien, la descripción presentada con un título puede comunicar la descripción presentada con un título diferente. Por ejemplo, las descripciones de las realizaciones de etapas del método para el tratamiento de solicitudes de contenido que se solapen pueden usarse para comunicar las realizaciones de métodos para el tratamiento de solicitudes anticipadas.

En la descripción se facilitan detalles específicos para proporcionar una comprensión profunda de las realizaciones. Sin embargo, las realizaciones pueden ponerse en práctica sin estos detalles específicos. Por ejemplo, se pueden mostrar procesos, algoritmos, estructuras y técnicas bien conocidos sin detalles innecesarios con el fin de evitar complicar las realizaciones. La implementación de las técnicas, los bloques, las etapas y los medios descritos anteriormente puede hacerse de diversas maneras. Por ejemplo, estas técnicas, bloques, etapas y medios pueden implementarse en soporte físico, soporte lógico o una combinación de los mismos. En una implementación de soporte físico, las unidades de procesamiento pueden implementarse dentro de uno o más Application Specific Integrated Circuits (circuitos integrados específicos de aplicación - ASIC), Digital Signal Processors (procesadores de señales digitales - DSP), Digital Signal Processing Devices (dispositivos de procesamiento de señales digitales - DSPD), Programmable Logic Devices (dispositivos lógicos programables -PLD), Field-Programmable Gate Arrays (matrices de puertas lógicas programables en campo - FPGA), procesadores de núcleo blando, procesadores de núcleo duro, controladores, microcontroladores, microprocesadores, otras unidades electrónicas diseñadas para realizar las funciones descritas anteriormente y/o una combinación de los mismos. Puede usarse soporte lógico en lugar de o además de soporte físico para realizar las técnicas, los bloques, las etapas y los medios.

Asimismo, se observa que las realizaciones pueden describirse como un proceso que se representa como un organigrama, un diagrama de flujo, un diagrama de flujo de datos, un diagrama de estructuras o un diagrama de bloques. Aunque un organigrama puede describir las operaciones como un proceso en secuencias, muchas de las operaciones pueden realizarse en paralelo o de manera simultánea. Además, el orden de las operaciones se puede reorganizar. Un proceso se termina cuando sus operaciones se han completado, pero podría tener etapas adicionales no incluidas en la figura. Un proceso puede corresponder a un método, una función, un procedimiento, una subrutina, un subprograma, etc. Cuando un proceso corresponde a una función, su terminación corresponde a un retorno de la función a la función de llamada o la función principal.

Además, las realizaciones pueden implementarse mediante soporte físico, soporte lógico, lenguajes de guiones, soporte físico modificado, soporte lógico personalizado, microcódigo, lenguajes de descripción de soporte físico y/o cualquier combinación de los mismos. Cuando se implementa en soporte lógico, soporte físico modificado, soporte lógico personalizado, lenguaje de guiones y/o microcódigo, el código de programa o los segmentos de código para realizar las tareas necesarias pueden almacenarse en un medio legible a máquina, tal como un medio de almacenamiento. Un segmento de código o una información ejecutable por máquina puede representar un procedimiento, una función, un subprograma, un programa, una rutina, una subrutina, un módulo, un paquete de soporte lógico, un guion, una clase o cualquier combinación de instrucciones, estructuras de datos y/o sentencias de programas. Un segmento de código puede estar acoplado a otro segmento de código o a un circuito de soporte físico pasando y/o recibiendo información, datos, argumentos, parámetros y/o contenido de memoria. La información, los argumentos, los parámetros, los datos, etc. pueden pasarse, enviarse o transmitirse a través de cualquier medio adecuado que incluya intercambio de memoria, paso de mensajes, paso de testigos, transmisión de red, etc.

En una implementación de soporte físico modificado y/o soporte lógico, las metodologías pueden implementarse con módulos (p. ej., procedimientos, funciones y así sucesivamente) que realicen las funciones descritas en la presente memoria. Cualquier medio legible a máquina que incorpore de manera tangible instrucciones puede usarse en la implementación de las metodologías descritas en la presente memoria. Por ejemplo, los códigos de soporte lógico pueden almacenarse en una memoria. La memoria puede implementarse dentro del procesador o externa al procesador. Como se usa en la presente memoria, el término “ memoria” se refiere a cualquier tipo de medio de almacenamiento a largo plazo, a corto plazo, volátil, no volátil o de otro tipo y no ha de limitarse a ningún tipo particular de memoria o número de memorias o tipo de medios en que se almacene la memoria.

Además, según se describe en la presente memoria, la expresión “ medio de almacenamiento” puede representar una o más memorias para el almacenamiento de datos, incluyendo memoria de sólo lectura (Read Only Memory -ROM), memoria de acceso aleatorio (Random Access Memory - RAM), RAM magnética, memoria de núcleo, medios de almacenamiento de disco magnético, medios de almacenamiento óptico, dispositivos de memoria flash y/u otros medios legibles por máquina para el almacenamiento de información. De manera similar, las expresiones como “ memoria caché” pretenden incluir ampliamente cualquier tipo de almacenamiento, incluyendo almacenamiento temporal o persistente, colas (p. ej., FIFO, LIFO, etc.), memorias intermedias (p. ej., circulares, etc.), etc. La expresión “ medio legible por máquina” incluye, pero sin limitación, dispositivos de almacenamiento fijos o portátiles, dispositivos de almacenamiento óptico, canales inalámbricos y/o diversos medios de almacenamiento diferentes con capacidad de almacenamiento que contengan o porten instrucción o instrucciones y/o datos.

Además, determinadas partes de las realizaciones (p. ej., las etapas del método) se describen como implementadas “en función de” otras partes de las realizaciones. Estas y otras fraseologías similares, como se usan en la presente memoria, pretenden incluir ampliamente cualquier técnica para determinar un elemento parcial o totalmente de acuerdo con otro elemento. Por ejemplo, un método puede incluir generar una huella digital a partir de una primera solicitud y generar una determinación “en función de” la huella digital. En diversas realizaciones, la determinación puede realizarse de cualquier manera, siempre y cuando el resultado de la etapa de generación de determinación dependa al menos parcialmente del resultado de la etapa de generación de huella digital.

Aunque los principios de la descripción se han descrito anteriormente en relación con aparatos y métodos específicos, se entenderá claramente que la presente descripción se realiza únicamente a modo de ejemplo y no como limitación del alcance de la descripción, definido por las reivindicaciones adjuntas.

Claims

REIVINDICACIONES

i. Un método para el funcionamiento en un sistema (100) de comunicaciones de multidifusión que tiene una trayectoria de comunicaciones entre un servidor (150) de contenido en un lado de servidor del sistema de comunicaciones y primer y segundo sistemas (110b,110m) de usuario en un lado de cliente del sistema de comunicaciones a través de un sistema (120) de servidor en el lado de servidor del sistema de comunicaciones, comprendiendo la trayectoria de comunicaciones un enlace directo compartido a través del que se comparten recursos de ancho de banda, comprendiendo el método:

recibir (180), en el segundo sistema de usuario, un objeto a partir de una multidifusión (162) desde el lado de servidor a través de la trayectoria de comunicaciones, habiendo sido solicitado (160) el objeto por el primer sistema de usuario;

almacenar (182), por el segundo sistema de usuario, el objeto recibido;

en respuesta a una solicitud del objeto en el segundo sistema de usuario, enviar (184), por el segundo sistema de usuario a través de la trayectoria de comunicaciones al lado de servidor, una solicitud del objeto;

recibir (186), en el segundo sistema de usuario a través de la trayectoria de comunicaciones desde el lado de servidor, datos de corrección de errores como parte de un segundo mensaje de reparación de objeto, comprendiendo el segundo mensaje de reparación de objeto y un primer mensaje de reparación de objeto cada uno individualmente información de reparación para un bloque de datos del objeto, habiéndose comunicado el primer mensaje de reparación de objeto previamente al primer sistema de usuario por el sistema de servidor después de la recepción en el sistema de servidor de un mensaje (170) de fiabilidad del primer sistema de usuario que identifica el bloque de datos del objeto en el que se ha identificado un error o una omisión; e

integrar, en el segundo sistema de usuario, los datos de corrección de errores con el objeto almacenado para crear un objeto completamente comprobado en cuanto a errores que puede ser usado por el segundo sistema de usuario.
2. El método de la reivindicación 1, en donde la solicitud del objeto en el segundo sistema de usuario es de un usuario del segundo sistema de usuario.
3. El método de cualquiera de las reivindicaciones anteriores, que comprende además, después del almacenamiento del objeto recibido, recibir la solicitud del objeto en el segundo sistema de usuario.
4. El método de cualquiera de las reivindicaciones anteriores, en donde faltan partes del objeto a partir de la multidifusión desde el lado de servidor a través de la trayectoria de comunicaciones al segundo sistema de usuario.
5. El método de cualquiera de las reivindicaciones anteriores, en donde la recepción del objeto a partir de la multidifusión desde el lado de servidor a través de la trayectoria de comunicaciones comprende recibir, en el segundo sistema de usuario, partes corruptas del objeto.
6. El método de cualquiera de las reivindicaciones anteriores, en donde el objeto es un objeto multimedia.
7. Un sistema para el funcionamiento en un sistema (100) de comunicaciones de multidifusión que tiene una trayectoria de comunicaciones entre un servidor (150) de contenido en un lado de servidor del sistema de comunicaciones y primer y segundo sistemas (110b, 110m) de usuario en un lado de cliente del sistema de comunicaciones a través de un sistema (120) de servidor en el lado de servidor del sistema de comunicaciones, comprendiendo la trayectoria de comunicaciones un enlace directo compartido a través del que se comparten recursos de ancho de banda, comprendiendo el sistema:

medios para recibir (180), en el segundo sistema de usuario, un objeto a partir de una multidifusión (162) desde el lado de servidor a través de la trayectoria de comunicaciones, habiendo sido solicitado (160) el objeto por el primer sistema de usuario;

medios para almacenar (182), por el segundo sistema de usuario, el objeto recibido; medios para, en respuesta a una solicitud del objeto en el segundo sistema de usuario, enviar (184), por el segundo sistema de usuario a través de la trayectoria de comunicaciones al lado de servidor, una solicitud del objeto;

medios para recibir (186), en el segundo sistema de usuario a través de la trayectoria de comunicaciones desde el lado de servidor, datos de corrección de errores como parte de un segundo mensaje de reparación de objeto, comprendiendo el segundo mensaje de reparación de objeto y un primer mensaje de reparación de objeto cada uno individualmente información de reparación para un bloque de datos del objeto, habiéndose comunicado el primer mensaje de reparación de objeto previamente al primer sistema de usuario por el sistema de servidor después de la recepción en el sistema de servidor de un mensaje (170) de fiabilidad del primer sistema de usuario que identifica el bloque de datos del objeto en el que se ha identificado un error o una omisión; y

medios para integrar, en el segundo sistema de usuario, los datos de corrección de errores con el objeto almacenado para crear un objeto completamente comprobado en cuanto a errores que puede usarse por el segundo sistema de usuario.
8. El sistema de la reivindicación 7, en donde la solicitud del objeto en el segundo sistema de usuario es una solicitud de un usuario del segundo sistema de usuario.
9. El sistema de cualquiera de las reivindicaciones 7-8, que comprende, después del almacenamiento del objeto recibido, recibir la solicitud del objeto en el segundo sistema de usuario.
10. El sistema de cualquiera de las reivindicaciones 7-9, en donde faltan partes del objeto a partir de la multidifusión desde el lado de servidor a través de la trayectoria de comunicaciones al segundo sistema de usuario.
11. El sistema de cualquiera de las reivindicaciones 7-10, en donde la recepción del objeto a partir de la multidifusión desde el lado de servidor a través de la trayectoria de comunicaciones comprende, recibir partes corruptas del objeto.
12. El sistema de cualquiera de las reivindicaciones 7-11, en donde el objeto es un objeto multimedia.