ES2352558T3

ES2352558T3 - Servidor, procedimiento y sistema para almacenar en memoria cache flujos de datos.

Info

Publication number: ES2352558T3
Application number: ES05709141T
Authority: ES
Inventors: Shaul Hayim
Original assignee: Divinetworks Ltd
Current assignee: Divinetworks Ltd
Priority date: 2004-03-02
Filing date: 2005-03-02
Publication date: 2011-02-21
Anticipated expiration: 2025-03-02
Also published as: WO2005086415A3; EP1721438B1; DE602005023416D1; CN103067353A; US20070198523A1; US8549177B2; CN1969525A; CN1969525B; US20130346565A1; ATE480940T1; WO2005086415A2; EP1721438A2; CN103067353B; PT1721438E

Abstract

Servidor de comunicación para distribuir un flujo de datos a un destino remoto en una red de comunicación, comprendiendo el servidor de comunicación: una unidad de sustitución para sustituir elementos de datos procedentes de un flujo de datos entrantes dados a recibir de un remitente remoto por elementos de datos idénticas recuperables a partir de un almacenamiento de datos accesible para el mismo, según referencias suministradas por el remitente remoto; una unidad de identificación para identificar los elementos de datos a sustituir según una firma digital que es una función de datos contenidos en dichos elementos; y una unidad de determinación de anclas para determinar localizaciones en el flujo de datos donde grupos predefinidos de caracteres procedentes del flujo de datos cumplen un criterio predeterminado, siendo las localizaciones de tales grupos puntos de referencia asociados a firmas digitales asociadas a los elementos de datos en cada grupo

Description

CAMPO DE LA INVENCIÓN

La invención se refiere al campo del transporte de datos por redes de comunicaciones, y más específicamente al campo 5 de reducción del volumen de tal transporte de datos.

ANTECEDENTES DE LA INVENCIÓN

El capítulo de Antecedentes de la Solicitud provisional de patente de los Estados Unidos nº 60/548855 se incorpora a la presente memoria por referencia.

La reducción del ancho de banda es un deseo importante de ISP-s (proveedores de servicio de Internet), usuarios 10 domésticos, proveedores de contenido y casi toda organización propietaria de una red. El ancho de banda significa coste, ya que las líneas de comunicación se contratan según la cantidad de datos que transfieren. Para un arrendador menos ancho de banda consumido significa menos dinero gastado en el alquiler de una línea de comunicación. Para un proveedor de ancho de banda menos volumen de datos transmitidos sobre una línea por un número dado de clientes significa clientes adicionales que se pueden abonar sin reducir la calidad de servicio. 15

La publicación de los Estados Unidos nº 2002/0184333 (en lo sucesivo D1) apunta a mejorar las prestaciones de las redes de comunicaciones. El problema que se ha de resolver por D1 es el de los casos en los que una pluralidad de solicitantes pueden enviar peticiones para el mismo fichero, en el cual cada solicitante se dirige a un proveedor diferente que cita una URL diferente o incluso diferentes nombres de fichero. En una copia en memoria caché convencional, tal pluralidad de peticiones se relacionan como peticiones para diferentes ficheros, dando como resultado la respectiva 20 pluralidad de entregas de ficheros.

Según la invención D1, después de recibir un fichero completo de cada una de la pluralidad de fuentes, se asignará una firma digital, que a su vez será reconocida como idéntica a la firma digital del mismo fichero recibido procedente de cualquiera de las otras fuentes. En consecuencia, otras peticiones para el fichero de cualquiera de la pluralidad de proveedores se satisfarán recuperando el fichero de una simple copia almacenada localmente en el servidor caché. La 25 mejora se realiza copiando en memoria caché frecuentemente ficheros solicitados para devolver tales ficheros a un solicitante en respuesta a una solicitud del solicitante, en la que los ficheros se indexan según una firma digital asignada a cada fichero, evitando de este modo múltiples copias en memoria caché y múltiples entregas de proveedor-servidor del mismo fichero en casos en los cuales se puede recuperar un fichero de una pluralidad de fuentes.

Como se puede apreciar, con el fin de poder realizar asociaciones entre diferentes formas de peticiones y un fichero 30 solicitado, D1 solicita que se reconozca dos veces un fichero memorizado en caché: en primer lugar según su firma digital, y en segundo lugar según todas las URL o nombres de fichero conocidos como asociados a ese fichero. En el caso en que se recibe una petición para el mismo fichero y no es familiar para el sistema, se puede satisfacer solamente recuperando el fichero de la localización indicada por la solicitud, y solamente después de recuperar y reconocer el fichero como una copia de un fichero almacenado localmente, el nombre de fichero o URL indicado por la petición se 35 puede asociar al fichero local para un futuro uso (es decir, para futuras peticiones similares). Otro inconveniente de D1 es que los ficheros almacenados en algunos ordenadores de proveedor pueden cambiar, mientras el nodo intermedio sigue proporcionando a los solicitantes una versión antigua de un fichero almacenado localmente sin ser consciente del cambio.

La publicación WO 95/19003 (en lo sucesivo D2) se refiere a casos en los que un ordenador receptor tiene un fichero 40 antiguo, un ordenador transmisor tiene un nuevo fichero, en el cual parte de ambos ficheros puede ser idéntica. Con el fin de permitir que el ordenador receptor actualice en fichero antiguo para que sea idéntico al nuevo fichero, se requiere que al menos las partes del nuevo fichero que no son idénticas a ninguna parte del fichero antiguo se transmitan al ordenador receptor. Con el fin de permitir tanto que el ordenador receptor como el ordenador transmisor comparen qué partes del fichero necesitan ser transmitidas (acelerando de este modo el proceso de transmisión), el ordenador 45 receptor necesita como etapa preliminar dividir el fichero no antiguo en segmentos, para calcular un número hash en cada segmento y enviar los números hash al ordenador transmisor. El ordenador transmisor tiene que calcular a continuación los números hash “para cada posible segmento en el nuevo archivo” (página 7 líneas 23-24), a continuación comparar los números hash con los números hash recibidos del ordenador receptor.

Como se puede apreciar, D2 se destina a reconstruir un fichero en un ordenador receptor, de segmentos de un nuevo 50 fichero recibido de un remitente y de segmentos existentes de un fichero antiguo predesignado existente en el ordenador receptor, de manera que el resultado será una copia del nuevo fichero en el ordenador receptor. La patente de los Estados Unidos nº 5.721.907 tiene el mismo objetivo a D2, D1 a D3, todas relacionadas con un ordenador receptor que espera que se obtenga un fichero (o parte de fichero) solicitado predeterminado de otro ordenador y que se almacene en el ordenador receptor. Cuando se conoce un fichero, también tiene un punto de partida y un punto de 55 finalización conocidos, que se pueden usar como localizaciones de referencia para calcular una firma digital en un intervalo conocido de datos.

A diferencia de la técnica conocida, la presente invención se destina a iniciar la reducción de transporte en flujos de datos en tiempo real, es decir, reducir el volumen de flujos de datos, cuyo contenido es anónimo y no se puede reconocer como fichero o parte de un fichero por el ordenador que inicia la reducción. En referencia, por ejemplo a la difusión de vídeo en directo, en la cual una pluralidad de ordenadores receptores reciben el mismo contenido en tiempo real, el sistema y el procedimiento divulgado en D1 son incapaces de reducir el volumen de transporte en la red ya que 5 el nodo intermedio no tiene que recuperar ningún fichero en su memoria caché ya que no hay ningún “fichero” efectivo en ningún lugar en el caso en el cual los datos se crean en tiempo real.

Las invenciones de D2 y D3 son también irrelevantes para tal caso ya que no hay “fichero antiguo” en los ordenadores receptores cuyas partes pueden ser idénticas a los datos esperados.

En el contexto de la presente invención, la localización de las anclas en un flujo de datos determinado según su 10 contenido cumple criterios predeterminados. Se establecen los criterios de manera que se dirige una probabilidad satisfactoria para la presencia de un ancla en una cantidad predeterminada de datos.

Los valores de registro de anclajes devueltos por una función predeterminada (en lo sucesivo denominado también “función de anclaje”) operada para examinar intervalos predeterminados de contenidos cuya localización está en correlación con las anclas. La función y los intervalos de datos se seleccionan de manera que los valores devueltos se 15 puedan usar como firmas que identifican el contenido con una probabilidad satisfactoria.

SUMARIO DE LA INVENCIÓN

La presente invención se refiere a un procedimiento y sistemas para la sincronización de contenidos anónimos de flujos de datos que pasan actualmente por el servidor de comunicación y contenidos similares que ya han pasado por dichos servidores y se encuentran almacenados localmente, de manera que se pueda eliminar el transporte de ciertas 20 cantidades de dicho flujo de datos.

Según algunas realizaciones, la sincronización es también entre diversas copias de contenidos de datos similares que pasan simultáneamente por el servidor. Un sistema de la presente invención comprende, al menos, un servidor capaz de reducir volúmenes de transporte de red en línea como resultado de procedimientos autoiniciados que no requieren información relativa a la fuente de los datos, su tipo, su nombre o cualquier otro de sus detalles de identificación, con el 25 fin de conseguir una reducción de volumen. Esto difiere de los procedimientos según los cuales la reducción de volumen esperada depende de los nombres o rutas de fichero con el fin de permitir la sincronización entre un fichero solicitado y un fichero localmente almacenado. Además, cuando se conoce un fichero a transferir, también tiene un punto de partida y un punto de finalización conocidos, que se pueden usar como localizaciones de referencia para una firma digital a calcular en un intervalo predeterminado de datos. En el caso de flujos de datos anónimos cuyo contenido no tiene 30 puntos de partida y de finalización convenidos con todos (como es el caso según la presente invención) no hay puntos de referencia convenidos que permiten calcular una firma digital repetible. Si una firma digital no se puede repetir, no se puede usar para identificar el contenido. Como se explicará más adelante el servidor según la presente invención comprende una unidad de determinación de anclas que soluciona este problema.

Par otro uso de algunas partes de los flujos de datos que pasan por el mismo, el servidor según la presente invención 35 (en lo sucesivo denominado también “servidor caché de datos anónimos” o “servidor ADC”) almacena tales partes de los datos sin ser consciente de los nombres de fichero, integridad de los datos, URL, tipos de fichero, y origen o destino de datos. Según la presente invención, solamente se almacenan por el servidor los datos puros, sin etiquetas de identificación recibidas de los solicitantes de ficheros externos o proveedores de ficheros.

Un sistema según la presente invención comprende un servidor de comunicación que tiene un circuito de comunicación 40 para recibir y distribuir flujos de datos y al menos un soporte de memoria accesible para los mismos.

Se proporciona una unidad de determinación de anclas en el servidor capaz de determinar localizaciones en los flujos de datos donde grupos predefinidos de caracteres del flujo cumplen criterios predeterminados, las localizaciones de tales grupos se determinan como anclas (también denominadas “puntos de referencia”)

El servidor comprende, además, 45

una unidad de función de anclaje para devolver valores (en lo sucesivo se denominarán también como firmas digitales) como una función del contenido de intervalos de datos en el flujo, en el cual los intervalos están en una correlación conocida respecto de las anclas (dichos valores pueden servir de ayuda cuando se busca el contenido);

una unidad de partición de datos para dividir el flujo de datos en bloques de datos;

una unidad de registro para almacenar listas de valores devueltos por la unidad de unción de anclaje, en la cual cada 50 valor está asociado por una referencia apropiada con un bloque de datos específico que contiene el intervalo de datos a partir del cual dicho valor es devuelto por la función de anclaje (cada uno de los valores asociados a un bloque se denominará en el contexto de la presente invención como “Id de boque”, y en algunos caso particulares como “clave hash”).

Según varias realizaciones de la presente invención una pluralidad de identificadores de bloque se asocian a cada bloque de datos en circunstancias normales.

Según una realización de la presente invención, la unidad de partición de bloques divide los datos en bloques de una dimensión predeterminada. Por ejemplo, se puede elegir que la dimensión predeterminada sea de 64 k de datos.

Según otra realización y con el fin de aumentar la compatibilidad entre bloques que contienen datos similares en 5 diferentes servidores y evitar una partición diferente de los datos a cada transmisión de los mismos, la unidad de partición determina la localización de inicio de bloques como una función de datos contenido en el flujo de datos. Según esta variación, la unidad de partición de bloques activa en los flujos de datos una función para determinar anclas en la cual la función está destinada a una probabilidad de devolver un ancla por intervalo de datos de una dimensión satisfactoria, por ejemplo una función según la cual se puede esperar un ancla una vez cada 50K de datos 10 aproximadamente.

Los bloques de datos se pueden guardar en una memoria caché para una posterior recuperación según los identificadores de bloques que están asociadas a tales bloques por referencias apropiadas.

Como se ha mencionado anteriormente, un ancla es una localización en un flujo de datos determinada según el contenido de la misma que cumple criterios predeterminados. Los criterios se establecen de tal manera que se dirige 15 una probabilidad satisfactoria para la presencia de un ancla sobre una cantidad predeterminada de datos.

Por ejemplo, según una realización de la invención, un conjunto de anclas asociadas a un bloque de datos puede ser un conjunto de localizaciones donde aparece una cadena corta en el bloque, por ejemplo, cada lugar donde aparece “aaa” en el bloque. Según otra realización el conjunto de anclas puede ser el conjunto de localizaciones de n-tuplos donde una función hash sobre este n-tuplo devuelve un valor predefinido, por ejemplo cada localización de un triplete de bytes 20 en el bloque, cuyo valor hash devuelto es 123.

Algunos ejemplos de una función hash que se pueden usar para encontrar un ancla son LFSR (aka CRC), DES, MD5, etc.

Según una realización preferida, la función de anclaje se concibe de manera que la probabilidad para encontrar un ancla es de media cada 500 bytes. En consecuencia, se esperan que tres anclas sean encontradas en cada paquete de 25 datos. En el caso de que los datos se dividan en bloques de datos de 64K cada uno, se esperan 128 anclas por cada bloque. En el caso en que se usan bloques de aproximadamente 50K, el número esperado de anclas se reduce respectivamente y de este modo se esperan aproximadamente 100 anclas por cada bloque.

Como se ha mencionado anteriormente, anclar es registrar valores devueltos por una función predeterminada (“función anclaje”) utilizada para examinar intervalos predeterminados de contenido cuya localización está en correlación con 30 anclas. La función y los intervalos de datos se seleccionan de manera que los valores devueltos se pueden usar como firmas que identifican el contenido en una probabilidad satisfactoria. Según una realización preferida de la presente invención, se elige que la función de anclaje sea una función hash tomada en 100 bytes consecutivos empezando en un ancla y devolviendo un valor hash de 96 bits en forma de firma digital.

Según una realización preferida de la presente invención, la unidad de registro (o el servidor mediante cualquier otra 35 unidad apropiada) está diseñada, además, a registrar las anclas en correlación con el registro de los identificadores de bloque. Por ejemplo después de la partición de un bloque de datos dado a partir del flujo de datos por la unidad de partición de datos, la localización de las anclas se registra, por ejemplo como referencias de compensación a medir desde el punto de partida del bloque. Mediante tal registro, cuando se da un valor de firma digital, se puede buscar un valor idéntico en la lista de identificadores de bloques, y si se localiza, el bloque al cual está asociado se puede 40 recuperar o acceder al mismo. El intervalo de datos a partir del cual se ha devuelto el valor de firma digital se puede de este modo localizar fácilmente según la localización del ancla asociada a este valor, medida a partir del punto de partida del bloque.

Según otra realización, las localizaciones de anclas en el bloque no se registran. Según esta realización, cuando se da un valor de firma digital, se puede buscar un valor idéntico en una lista de identificadores de bloques, y si se localiza, el 45 bloque al cual está asociado se puede recuperar o se puede acceder al mismo. Puesto que las localizaciones de ancla no se registran según esta realización particular, la localización del intervalo de datos en el bloque a partir del cual el valor de firma digital se ha devuelto es todavía desconocido. De este modo, según esta realización se ha de usar un diccionario, como se explicará en el capítulo de la descripción detallada. Con este fin, el servidor ADC puede comprender, además, una unidad generadora de diccionarios. 50

Bien mediante dicha realización de registro de anclas o bien mediante una realización generadora de diccionarios, un paquete de datos actualmente recibido a partir del cual se ha devuelto una firma digital por la unidad de función de anclaje se puede sincronizar con un paquete de datos similar contenido en un bloque de datos ya almacenado en la memoria, de manera que se pueden comparar fácilmente con el fin de verificar si son idénticos. En caso de que sean idénticos, el paquete actualmente recibido se puede sustituir por una referencia a su localización en el bloque, 55 reduciendo de este modo el volumen de datos enviados al extremo de recepción. Si no son idénticos el volumen de

datos a enviar se puede todavía reducir sustituyendo las subcadenas idénticas (si existen) con referencias a sus localizaciones de partida y de finalización en el bloque.

El servidor de la presente invención se puede usar en una o dos opciones básicas, o combinaciones de las mismas, con el fin de reducir los volúmenes de transporte en redes de comunicación:

: (i) en combinación con al menos un servidor correspondiente de un tipo similar, estando ambos servidores 5 localizados en extremos remotos de una línea virtual de comunicación (en el contexto de la presente invención, el término línea de comunicación incluye una conexión inalámbrica, como una de las posibles opciones) conectados entre sí; y

: (ii) en combinación con al menos un ordenador proveedor de datos (en lo sucesivo “proveedor de datos”) que comprende una unidad de redirección; 10

Con el fin de facilitar la descripción, se entiende que dos servidores caché de datos anónimos según la presente invención están conectados en dos extremos remotos de una línea de comunicación, y ambos están funcionando también en combinación con proveedores de datos conectados a cada uno por redes y enrutadores respectivos.

Como punto de partida, pongamos por caso que los dos servidores ADC, tienen memorias caché que están vacías. Los flujos de datos se dirigen a través de los servidores ADC. Cada servidor ADC procesa los datos que pasan por él para 15 determinar anclas, calcular firmas digitales, dividir los datos en bloques, y crear identificadores de bloques. En circunstancias normales, los bloques se almacenan en las memorias caché que de este modo empiezan a llenarse con bloques de datos puros que no contienen información de identificación. Los identificadores de bloques de cada bloque se almacenan también, de manera que la dirección de cada bloque almacenado en la memoria caché se acorta con una lista respectiva de identificadores de bloques. En paralelo a la construcción de la memoria caché en cada servidor ADC, 20 los bloques se envían paquete por paquete a la dirección destinada, es decir, según las circunstancias bien al servidor ADC correspondiente en el extremo opuesto de la línea de comunicación, o a destinatarios convencionales a los cuales se encaminan los datos. Cuando se devuelve un valor de firma digital a partir de un flujo de datos recibidos, se buscan las listas almacenadas de identificadores de bloques en el servidor ADC para un valor idéntico. Al reconocer un identificador de bloque que tiene tal valor idéntico, se puede acceder al bloque asociado a esta Id de bloque. El servidor 25 localiza ahora el punto específico en este bloque a partir del cual el identificador de bloque se ha devuelto por la función de anclaje, y sincroniza la localización del paquete de datos actualmente recibidos y la localización en el bloque del paquete de datos originalmente recibidos, por ejemplo usando la compensación conocida del ancla del punto de partida del bloque (según la realización en la cual las anclas se guardan con los identificadores de bloque), o por ejemplo, mediante el uso de un diccionario (según otra realización). 30

El paquete actualmente recibido y el original, se pueden comparar ahora para verificar si son idénticos, o determinar qué partes de los mismos (o que subcadenas de los mismos) son idénticas.

En el caso de que sean idénticos, (y según varias otras realizaciones en el caso de que algunas partes de los mismos sean idénticas), el servidor ADC inicia un proceso para reducir el volumen del flujo de datos que se espera ahora que contenga datos que ya están almacenados localmente. 35

Si la fuente de los datos es un proveedor de datos, el servidor ADC iniciador envía un mensaje al proveedor de datos para activar la función de anclaje y enviar solamente referencias a localizaciones de anclas en el bloque, en lugar de enviar los propios datos. Mientras que las referencias recibidas permiten que el servidor recupere todos los paquetes del bloque almacenado localmente, el proveedor de datos sigue enviando referencias en lugar de datos completos. Si en cualquier punto dado, el servidor reconoce una falta de coincidencia entre las firmas de los datos recibidos y las de los 40 almacenados localmente, envía un mensaje al proveedor para que vuelva a la transmisión convencional.

En caso de que los flujos de datos recibidos se hayan de enviar a un servidor ADC correspondiente, el servidor iniciador envía un mensaje al servidor correspondiente para que recupere de su memoria caché un bloque según una firma actualmente reconocida. Se envían entonces uno o más paquetes actualmente recibidos al servidor correspondiente en modo de transmisión convencional, hasta que el servidor correspondiente confirme que el bloque deseado ha sido 45 reconocido y cargado.

En el servidor iniciador, partes de los paquetes actualmente recibidos que son idénticos a los almacenados localmente, se sustituyen entonces por referencias al bloque, permitiendo que el servidor correspondiente los reconstruya a partir del bloque. Puesto que las referencias son más cortas que los datos que sustituyen, la dimensión del paquete se puede reducir con seguridad. Los paquetes de dimensión reducida se envían entonces al servidor correspondiente mientras 50 que los datos idénticos a los datos actualmente recibido se pueden recuperar localmente.

Según una realización preferida, el servidor ADC se usa, además, para eliminar volumen de transporte innecesario en los casos donde información idéntica fluye simultáneamente hacia diferentes destinos por el servidor. Según esta realización, el servidor iniciador busca anclas en paquetes recibidos actualmente y a veces puede reconocer que los paquetes localmente almacenados devuelven firmas idénticas. Este puede ser el caso, por ejemplo cuando se difunde 55 un vídeo en directo a una pluralidad de destinatarios. En tal caso, el servidor iniciador puede enviar al servidor

correspondiente un mensaje para que use un único paquete enviado, y lo distribuya a todos los destinatarios que están esperando paquetes idénticos en el servidor iniciador. El volumen de transporte en tal caso se puede reducir considerablemente, y el tiempo de descarga de grandes cantidades de datos se puede acortar considerablemente.

Algunas realizaciones básicas de la invención se describirán ahora de manera resumida:

La presente invención se refiere aun servidor de comunicación para distribuir flujos de datos a un destino remoto en una 5 red de comunicación, comprendiendo el servidor una unidad de sustitución para sustituir elementos de datos procedentes de flujos de datos entrantes dados a recibir a partir de un remitente remoto por elementos de datos idénticos recuperables a partir de un almacenamiento de datos accesible para el mismo, según referencias suministradas por el remitente remoto; caracterizado por una unidad de identificación para identificar los elementos de datos a sustituir según una firma digital que es una función de datos contenidos en dichos elementos, y por una unidad 10 de determinación de anclas para determinar localizaciones en los flujos de datos donde grupos predefinidos de caracteres procedentes del flujo cumplen un criterio predeterminado, siendo las localizaciones de tales grupos puntos de referencia asociados a firmas digitales.

Según varias realizaciones preferidas, el servidor de comunicación que comprende, además, una unidad de mensajería para notificar a un remitente remoto que deje de intentar enviar elementos de datos entrantes que se pueden recuperar 15 a partir de un almacenamiento de datos0 accesible para él.

El remite remoto puede ser un PC que distribuye datos (o ficheros que el servidor de la invención denomina datos simples).

Según varias realizaciones preferidas, las unidades de servidor están diseñadas para a procesar elementos de datos que son paquetes de protocolo de transmisión TCP/IP. 20

Según varias realizaciones preferidas, el servidor comprende, además, un almacenamiento de datos accesible para el mismo, en el cual los paquetes se almacenan en el almacenamiento de datos en bloques de dimensión variable que se determina según la localización de ancla en el flujo de datos original.

Según varias realizaciones, la firma digital devuelta por la unidad de función de anclaje se basa en cualquier valor calculado CRC, SHA1 o DES de un número predeterminado de bytes de un elemento de datos seleccionado. 25

Según algunas realizaciones preferidas, la firma digital se calcula a partir de un número predeterminado de bytes de datos, la localización de dichos bytes en el flujo de datos está en correlación con al menos un ancla y el ancla es un apuntador a una localización en el flujo de datos que tiene una compatibilidad con criterios predeterminados.

Según varias realizaciones preferidas, dichos criterios son una función de datos contenidos en dichos elementos de datos y son independientes de un título, dirección o información de encaminamiento de dichos datos. 30

La función es receptiva a una combinación de caracteres predeterminada de manera que se asigne un ancla durante el reconocimiento de dicha combinación de caracteres.

Según varias realizaciones, la combinación de caracteres es una cadena corta de caracteres predefinidos.

Según varias realizaciones, se asigna un conjunto de anclas a un elemento de datos, cada ancla del conjunto está en correlación con una localización de n-tuplo en dicho elemento de datos, en el cual la función es una función hash, que 35 da un valor predefinido en el n-tuplo.

Según varias realizaciones preferidas, la función hash se selecciona entre el grupo que contiene LFSR, CRC SHA1, DES y MD5.

El servidor y los sistemas que lo contienen pueden tratar ficheros proporcionados a través de comunicación P2P sin tener en cuenta su dimensión ni si están divididos y descargados de una pluralidad de proveedores, ya que la presente 40 invención se refiere a cualquier tipo de ficheros como flujos de datos anónimos sin formato.

La presente invención se refiere también a un procedimiento para proporcionar flujos de datos en redes de comunicación, comprendiendo el procedimiento determinar puntos de referencia en un flujo de datos que son localizaciones en el flujo donde un número predefinido de caracteres satisfacen un criterio predeterminado; registrar firmas digitales que son valores devueltos de una función predeterminada tomada en intervalos predefinidos de 45 contenido, los intervalos están en correlación con los puntos de referencia; usar las firmas digitales para localizar contenido almacenado localmente, y usar los puntos de referencia o crear un diccionario y usarlo para sincronizar elementos de datos actualmente recibidos y contenido coincidente almacenado localmente.

La presente invención se refiere, además, a un soporte legible por ordenador que contiene instrucciones para controlar un sistema informático para ejecutar el procedimiento. 50

Un sistema para reducir volúmenes de transporte sobre redes de comunicación, que comprende al menos un servidor de comunicación tal como se define en la descripción anterior y en lo sucesivo se encuentra también dentro del alcance de la presente invención

BREVE DESCRIPCIÓN DE LOS DIBUJOS

Con el fin de comprender la invención y ver el modo de llevarla a la práctica, se describirá ahora una realización 5 preferida, solamente a título de ejemplo no limitativo, con referencia a los dibujos anexos, en los cuales:

La figura 1 ilustra la relación entre flujo de datos, paquetes contenidos en el flujo de datos, bloques de datos divididos del flujo de datos, y anclas generadas según la presente invención con el fin de permitir una correlación efectiva entre casos repetidos de flujos de datos anónimos similares.

La figura 2 ilustra la relación entre bloques de datos, entre una red de identificadores de bloques que permite localizar 10 bloques almacenados localmente, y entre un diccionario que según algunas realizaciones permite localizar paquetes en un bloque.

La figura 3 ilustra una primera parte de un diagrama de flujo que demuestra un procedimiento para reducir el volumen de transporte sobre una línea de red según una realización preferida de la presente invención.

La figura 4 ilustra una segunda parte del diagrama de flujo de la figura 3. 15

La figura 5 ilustra un ejemplo de la configuración del sistema según la presente invención.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN

La invención se refiere a un procedimiento para reducir ancho de banda copiando datos en memoria caché, y un sistema para reducir ancho de banda copiando datos en memoria caché. El núcleo de la invención es el almacenamiento de paquetes y su recuperación rápidamente de una manera eficiente. Se describirá ahora la manera en 20 que se almacenan los paquetes para luego recuperarlos eficientemente.

A lo largo de toda la siguiente descripción, un fichero que está siendo transferido se le denominará flujo de datos. Esto es una consideración razonable ya que los dispositivos que tratan con flujos en tiempo real en la red no conocen por adelantado el fichero que se está transfiriendo y descubren el fichero a medida que pasa por ellos, justo como un flujo.

Un servidor de comunicación según la presente invención conoce los datos cuando lee el paquete que pertenece al flujo 25 procedente de la línea de comunicación. El flujo que se está conociendo se ha de dividir en bloques de datos. La dimensión de un bloque es independiente de la dimensión del paquete. En lo sucesivo se hará referencia a modo de ejemplo a una dimensión de bloque de 64K (aunque puede ser de cualquier dimensión aceptable), según una realización. Un bloque también necesita no empezar al principio de un paquete. Al leer paquete de flujo procedente de la red, sus datos se copian en un bloque de datos. Cuando un bloque está lleno, y contiene 64K de datos, se guarda en el 30 disco local después de realizar algún preprocesamiento que se mencionará más adelante. Según otra realización, la posición de finalización de un bloque y de inicio del siguiente bloque en un flujo se determina mediante anclas (de una manera que se explicará más adelante). Mediante el uso de anclas (en contradicción con el uso de bloques de dimensión fija según otra realización), la partición de bloques se hace dependiente de su contenido (puesto que el ancla se determina como una función de los datos contenidos) y de este modo los bloques que contienen datos idénticos se 35 encontrarán más probablemente en la red como siendo divididos de manera idéntica, mientras que la partición de bloques de dimensión fija puede ocasionalmente cambiar puesto que ninguna regla inherente determina su partición.

Según varias realizaciones, se usarán funciones hash para facilitar la localización de datos requeridos durante los procesos tomados según la presente invención. Se define una clave hash para que sea un número de n bits que depende del valor de un intervalo de datos cuya dimensión es m bytes, donde la probabilidad de tener dos claves hash 40 idénticas para dos valores diferentes de m bytes es muy baja. Las claves hash se puede crear calculando el valor CRC de m bytes, o calculando su valor SHA1, el valor DES o cualquier otra función conocida para satisfacer la condición anterior. La decisión acerca de los valores específicos de n y m puede ser tomada por el experto en la técnica dependiendo de la red y del tipo de paquete sobre el que se aplica el procedimiento. Las claves hash se pueden usar para localizar un bloque solicitado sobre el disco. Las claves hash se pueden usar también para localizar un paquete 45 específico solicitado en el bloque.

Según una realización preferida de la presente invención se usa una clave hash de 64 bits tomada sobre 100 bytes para permitir la localización de un bloque en el disco.

Según otra realización preferida de la presente invención se usa una clave hash de 96 bits tomada sobre 100 bytes para permitir localizar un bloque en el disco. 50

Según algunas realizaciones se usa una clave hash de 16 bits tomada sobre 5 bytes para crear un diccionario que permitirá encontrar un paquete solicitado en un bloque.

Según varias realizaciones de la presente invención se seleccionan preferiblemente anclas que dependen de solamente pequeñas cantidades de datos (por ejemplo, unos pocos bytes) y que son independientes de la posición de partida del bloque que contiene las anclas o de la posición de partida del paquete que las contiene. Un ejemplo para definir anclas en un flujo, es la elección de un ancla en cada posición del flujo donde aparece la cadena “abc”. Otro ejemplo para definir anclas es la elección de anclas en cada posición del flujo donde un hash de 9 bits de 5 bytes consecutivos es 5 cero. Se eligió un CRC de 9 bits porque cuando se da un CRC de una cadena de cinco bits, es fácil eliminar la contribución del primer byte en la cadena y añadir un nuevo byte al final de la cadena. De este modo el CRC se puede “almacenar” eficientemente en la memoria intermedia.

En cada lugar donde se encuentra un ancla, se calcula una clave hash de 96 bits en los siguientes 100 bytes consecutivos. El valor de la clave hash devuelta se denomina “identificadores de bloque”. Evidentemente, según el 10 procedimiento descrito un bloque tendrá una pluralidad de identificadores. Con el fin de evitar demasiados identificadores de bloque, es posible saltar una cierta cantidad de datos después de encontrar el ancla, por ejemplo, se pueden saltar 400 ó 500 bytes lejos del ancla anterior considerada, antes de encontrar la siguiente ancla. En consecuencia, se aprecia que un paquete tendrá no más de tres Id de bloque, y que un bloque de 64K no tendrá más de 128 identificadores. 15

Todas las Id de bloque se guardan entonces en una matriz en el disco. Esta matriz se denominará también “matriz hash”. Cada identificador de bloque se asocia a una entrada de la matriz hash, aunque muchos identificadores se han de cartografiar en la misma entrada, ya que se refieren todos a un bloque específico. En cada entrada se mantiene de este modo una lista de identificadores de bloque con la localización de su bloque asociado.

Según algunas realizaciones, las claves hash se calculan para cada bloque, cada m bytes consecutivos del bloque, y 20 cada clave hash se almacena en una matriz junto con la posición donde se generó. Esta matriz se denominará también “diccionario” del bloque, y se usarán según estas realizaciones para localizar paquetes solicitados en el bloque. Según una realización, y como se ha mencionado anteriormente, la clave hash se elige para tener una longitud de 16 bits, y se calcula en 5 bytes consecutivos. Los valores de las claves hash devueltas del cálculo se almacenan en una matriz, sin embargo, según otras variaciones de realización se pueden almacenar en una lista, un árbol o cualquier estructura que 25 permita una búsqueda eficiente. El diccionario se establece de este modo para ser una matriz de 65536 entradas (en la cual cada entrada corresponde a una posible combinación diferente de la clave de 16 bits). En el caso de que se calcule una clave hash H en la posición p, la hésima entrada de la matriz se establecerá para contener el número p. En consecuencia, con el fin de encontrar la posición en un paquete donde se calculó una clave hash h, se debería leer el valor almacenado en la hesima entrada en la matriz. 30

La dimensión de diccionario se puede reducir calculando una clave hash solamente para cada m bytes consecutivos cuya posición de partida en el interior del paquete se puede dividir por x, donde x es un parámetro que se puede elegir por el desarrollador. Un mayor valor de x dará como resultado una menor dimensión de diccionario. Por ejemplo se puede elegir que x sea 16.

Se hace ahora referencia a la figura 1, que ilustra la relación entre el flujo de datos representado por el marco 1. Los 35 puntos en el interior del marco representan el contenido de datos. Los paquetes están contenidos en el flujo de datos, como se representa mediante el marco 2, que es idéntico al marco 1, con la diferencia de que el marco 2 ilustra los puntos de partida y de finalización de los paquetes por líneas verticales 4.- Los bloques de datos a dividir procedentes del flujo de datos se representan por líneas verticales dobles 5, y se ilustran también las anclas 6, 7 y 8 generadas según la presente invención con el fin de permitir una correlación efectiva entre casos repetidos de flujos de datos 40 anónimos similares, En el ejemplo ilustrado, las anclas se definen como localización donde se encuentra la combinación de caracteres “a,b,c” en el flujo de datos. En consecuencia, se ponen de relieve los casos de tales combinaciones en el flujo escribiendo explícitamente dicha combinación de caracteres. Las líneas verticales de puntos 9, 10 y 11, pasan por el flujo, los paquetes y las representaciones de bloques con el fin de resaltar que las anclas proporcionan puntos de referencia inherentes a las localizaciones en el flujo de datos, de manera que no importe cómo se va a dividir este flujo, 45 los puntos de referencia siempre se pueden reconocer activando una función que devuelve un ancla en cuanto se detecta la combinación de caracteres predefinida.

En referencia a la figura 2, se representan tres bloques almacenados en la memoria caché por tres marcos respectivos etiquetados A, B y C. El primer bloque A, contiene la cadena “abcdeafchijk”. El diccionario del primer bloque se representa mediante un marcho etiquetado D. El diccionario D indica las localizaciones en el bloque A donde aparecen 50 tripletes de caracteres. La figura 2 ilustra también una matriz de Id de bloques (etiquetada E), en la cual en el ejemplo ilustrado se asocian dos de los identificadores con, y que se dirigen de este modo al primer bloque A, como se representa mediante las flechas respectivas 31 y 32. Durante la recepción de un paquete, se busca un ancla, y cuando se encuentra, se calcula una firma digital mediante una función hash que devuelve un valor hash a partir de los 100 bytes que siguen al ancla. El valor de firma digital se busca entonces en una matriz que almacena identificadores de 55 bloques. Esta matriz también almacena la localización en la memoria caché en la cual se almacena el bloque. En caso de que se de una coincidencia entre el valor de firma digital y un valor de cualquiera de los identificadores de bloque, el bloque asociado con el identificador de bloque coincidente se carga a partir de la memoria caché. Después de cargar el bloque en la memoria, se puede usar el diccionario para encontrar grandes subcadenas del paquete en el bloque que

son idénticas a las subcadenas correspondientes en el paquete recibido actualmente. Tales subcadenas se pueden borrar del paquete y sustituir por referencias al bloque.

Un servidor ADC que recibe tal paquete procesado puede recuperar dichas partes borradas del paquete desde su memoria caché local, y de este modo el volumen de datos transmitidos se reduce según el volumen de las subcadenas borradas. 5

El proceso ejecutado según varias realizaciones de la presente invención se explicará más adelante asumiendo una configuración en la cual se conectan respectivamente dos servidores ADC en extremos opuestos de una línea de comunicación, y asumiendo (por motivos de simplicidad explicativa) que todos la comunicación se transmite desde el mismo extremo de la línea (en el contexto de la presente invención “extremo iniciador”) y se recibe en el otro extremo (en el contexto de la presente invención “extremo receptor”), y que los servidores en ambos extremos de la línea han 10 estado en funcionamiento durante una cantidad suficiente de tiempo y han estudiado la información transmitida por la línea, y han construido las estructuras de datos explicadas anteriormente.

A modo de resumen, la misma configuración se refiere según la presente invención a un sistema que comprende dos servidores ADC, uno en un extremo opuesto de una línea de comunicación. La comunicación transmitida por la línea pasa a través de ambos servidores. Los dos servidores estudian los ficheros y flujos que se transmiten en la línea. Los 15 dividen en bloques y almacenan los bloques en su disco local junto con un diccionario (según una variación) o con referencias de ancla (según otra variación). Igualmente actualizan su fichero hash que contiene las Id de bloque según los bloques recientemente almacenados. Cuando un paquete de un flujo se transfiere, los dos ordenadores buscan sus discos, usando su fichero hash, y cargan un bloque que se almacenó previamente. Este bloque es usado por el ordenador de transmisión para sustituir datos en el paquete con referencia a datos en el interior del bloque, y por el 20 ordenador receptor para reconstruir el paquete según las referencias. Dicho proceso se describirá más en detalle.

Una lectura de paquete desde la red en el extremo iniciador es una parte de un flujo de comunicación. Este flujo de comunicación se distingue de otras comunicaciones por sus identificadores de comunicación, que es el 4-tuplo: dirección IP fuente, dirección IP destino, puerto fuente y puerto destino. Durante la lectura del paquete y antes de su transmisión al extremo receptor, el servidor iniciador revisa el paquete para encontrar anclas en este paquete. 25

El número esperado de anclas en un paquete es tres (suponiendo que se está usando la realización anteriormente mencionada dirigida para tal número de anclas). Esto significa que hay una cierta probabilidad de que se encuentre alguna ancla. Obsérvese que la posición del ancla en el flujo es una función del contenido de paquete en lugar de su posición en el paquete. Esto garantiza que el ancla que se encuentra en un paquete actualmente recibido corresponde a un ancla que se encontró previamente cuando se conoció el flujo, si es que los dos paquetes contienen partes idénticas 30 de información.

Después de encontrar tal ancla, se calcula el valor de firma digital definido en esta ancla. Se usa la matriz hash para buscar un identificador de bloque que coincida con la firma digital devuelta a partir de dicho cálculo. En el caso de que se encuentre una coincidencia, el boque asociado al identificador de bloque coincidente se carga a partir de la memoria caché. Mientras tanto el paquete se transmite por la línea al extremo receptor, seguido de un mensaje diciéndole que 35 cargue el mismo bloque de su disco. Puesto que dicho bloque ya ha pasado anteriormente por el extremo iniciador (bien al o del extremo receptor), se espera que en condiciones normales se tenga que encontrar también en el extremo receptor. Toma el disco del extremo receptor durante unos pocos milisegundos para cargar el bloque. Durante este tiempo, más paquetes del mismo flujo se pueden transmitir sin cambios (es decir, por modo convencional de transmisión) por la línea. No se espera que el número de estos paquetes sea superior a una docena. 40

Después de cargar el bloque desde el disco del extremo receptor, y cuando un paquete llega desde el mismo flujo, se puede determinar la posición del paquete en el interior del flujo usando el diccionario. Con este fin, se calcula una clave hash en cinco bytes en el interior del paquete y se devuelve el valor h. La hèsima entrada del diccionario, que ocupa la posición donde una cadena que ha generado el mismo hash ha aparecido en el bloque, se lee a continuación, y los datos en esta localización en el paquete anteriormente almacenado se comparan con los datos en el paquete 45 actualmente recibido para ver si coinciden. En caso afirmativo, los datos en el paquete se sustituyen por una indicación de que los datos aparecen en el bloque, junto con su posición en el bloque y su longitud. Dicho procedimiento se repite tantas veces como sean necesarias hasta revisar todo el paquete. El servidor en el extremo receptor de la línea reconstruye el paquete copiando los datos indicados desde el bloque en el paquete.

Con el fin de mejorar el tiempo de carga de bloques desde la memoria caché, se pueden aplicar técnica de precarga. 50 Por ejemplo, un bloque (que más tarde se puede reconocer como uno solicitado) se puede precargar antes de ser de hecho necesario comprobando que el flujo alcanza el extremo del bloque actual, y precargando a continuación un conjunto de bloques de los que se ha predicho que uno de ellos será necesario más tarde. Con este fin, se puede estudiar una lista de bloques que puede ser necesaria después de usar un bloque específico para cada bloque, por ejemplo mediante técnicas de autoaprendizaje. 55

La figura 3 ilustra una primera parte de un diagrama de flujo que demuestra un proceso para reducir el volumen de transporte sobre una línea de red según una realización preferida de la presente invención. La primera parte del

diagrama de flujo ilustra, de manera general, el modo en que un primer servidor de comunicación ADC1 se prepara para trabajar junto con un segundo servidor de comunicación similar ADC2. ADC1 lee en primer lugar un paquete como el ilustrado por la etapa 41, encuentra anclas in el paquete, calcula la firma digital en intervalos de datos predeterminados cuya localización está en correlación con las anclas, y busca una lista de Id de bloque que intentan localizar firmas anteriormente almacenadas que son idénticas a los actualmente almacenados, como se representa mediante las etapas 5 42 y 43 del procedimiento. En el caso de que se encuentre una coincidencia, el procedimiento procede a la etapa 44, cargando un bloque a partir de una memoria caché según la localización del bloque que se asocia al identificador de bloque que ha sido encontrado ser coincidente con una firma del paquete actualmente recibido. Los datos del paquete actualmente recibidos se comparan a continuación con los datos en el bloque (después de sincronizar los paquetes respectivos, por ejemplo según las anclas con las cuales se asocia el ancla). En el caso de que la etapa 45 se lleve a 10 cabo de manera positiva, y que se encuentren datos idénticos, el primer servidor envía un mensaje (como se representa mediante la etapa 46) al segundo servidor ADC2, para cargar un bloque a partir de memoria caché local según la firma coincidente ahora conocida. El primer servidor espera una confirmación del segundo servidor, y permanece en un modo non-sincronizado de operación en cuanto no se devuelve una confirmación de carga del bloque apropiado del segundo servidor, como se representa mediante las etapas 47, 48 y 50, en el cual un modo no sincronizado significa que los 15 paquetes se siguen enviando al segundo servidor de manera convencional (es decir, en su forma original) como se representa mediante la etapa 54. El procedimiento se repite de este modo hasta la recepción de una confirmación del segundo servidor y los dos servidores empiezan a funcionar en modo sincronizado como se representa mediante la etapa 49 y se detalla, además, en la figura 5, o hasta que se encuentre que los paquetes comparados no son idénticos de manera que el proceso sigue desde la etapa 45 a la 53 y el paquete actual que es todavía desconocido para el 20 primer servidor se mantiene en una memoria intermedia como se representa mediante la etapa 53, y que se envía, además de manera convencional al segundo servidor como se representa por la etapa 54, mientras a continuación el proceso se repite leyendo otro paquete hasta que la memoria intermedia se llena mediante un bloque entero de datos no familiares, que a continuación se almacenan localmente como se representa mediante la etapa 51, junto con sus identificadores de bloque y las localizaciones de anclas asociadas, lo cual permite una futura recuperación del bloque 25 durante el reconocimiento de la firma coincidente en algún flujo de datos a recibir en el futuro.

La figura 4 ilustra una segunda parte del diagrama de flujo de la figura 3 que es el modo sincronizado en el cual los dos servidores operan con datos familiares (es decir, que ya están localmente almacenados en las memorias caché de ambos). En el modo sincronizado, el primer servidor lee un paquete actualmente recibido como se representa mediante la etapa 55, lo compara con los datos del paquete correspondiente en el bloque que se cargó en la etapa 44 (de la figura 30 3), y en caso de que los datos en los dos bloques sean idénticos, el servidor envía entones instrucciones al segundo servidor para reconstruir los datos a partir del bloque que se cargó por el segundo servidor como respuesta al mensaje que se envió al mismo en la etapa 46 (de la figura 3), y para enviar el paquete reconstruido a su destino. En el caso de que la comparación realizada en la etapa 56 sea negativa, el primer servidor envía un mensaje al segundo servidor de que el modo sincronizado ha de cesar como se representa mediante la etapa 59, y luego envía los paquetes 35 actualmente recibidos al segundo servidor en su forma original. El servidor cambia entonces su modo de funcionamiento a no sincronizado como se representa mediante la etapa 61, y el proceso empieza de nuevo, como se representa mediante la etapa 40 de la figura 3.

La figura 5 ilustra un ejemplo de configuración de sistema según la presente invención, que comprende dos servidores ADC 61 y 62 conectados en dos extremos de una línea virtual de comunicación 64 y que comunica, además, a través de 40 las líneas de red 64 y 65, respectivamente, con redes de comunicación convencionales representadas por los enrutadores 67 y 65 y por los proveedores de datos 69 y 68 y los receptores de datos 73 y 72.

Mediante tal configuración de red y estableciendo la comunicación entre los dos servidores ADC en la línea virtual, se pueden redirigir flujos de datos de manera que se garantiza que los flujos de datos en cuestión psarán seguramente por ambos servidores. 45

Claims

REIVINDICACIONES

1.-Servidor de comunicación para distribuir un flujo de datos a un destino remoto en una red de comunicación, comprendiendo el servidor de comunicación:

una unidad de sustitución para sustituir elementos de datos procedentes de un flujo de datos entrantes dados a recibir 5 de un remitente remoto por elementos de datos idénticas recuperables a partir de un almacenamiento de datos accesible para el mismo, según referencias suministradas por el remitente remoto;

una unidad de identificación para identificar los elementos de datos a sustituir según una firma digital que es una función de datos contenidos en dichos elementos; y

una unidad de determinación de anclas para determinar localizaciones en el flujo de datos donde grupos predefinidos de 10 caracteres procedentes del flujo de datos cumplen un criterio predeterminado, siendo las localizaciones de tales grupos puntos de referencia asociados a firmas digitales asociadas a los elementos de datos en cada grupo
2.-Servidor de comunicación según la reivindicación 1, que comprende, además, una unidad de mensajería para notificar a un remitente remoto que deje de distribuir elementos de datos entrantes previstos que se pueden recuperar a partir de un almacenamiento de datos accesible para él. 15
3.-Servidor de comunicación según la reivindicación 2, en el cual el remitente remoto puede es un PC que suministra los datos.
4.-Servidor de comunicación según una cualquiera de las reivindicaciones 1 a 3, en el cual los elementos de datos son paquetes de protocolo de transmisión TCP/IP.
5.-Servidor de comunicación según una cualquiera de las reivindicaciones 1 a 4, que comprende, además, un 20 almacenamiento de datos accesible para el mismo, en el cual los paquetes se almacenan en el almacenamiento de datos en bloques de dimensión variable que se determina según la localización de ancla en el flujo de datos original.
6.-Servidor de comunicación según una cualquiera de las reivindicaciones 1 a 5, en el cual a firma digital se basa en cualquier valor calculado CRC, SHA1 o DES de un número predeterminado de bytes de un elemento de datos seleccionado. 25
7.-Servidor de comunicación según una cualquiera de las reivindicaciones 1 a 6, en el cual la firma digital se calcula a partir de un número predeterminado de bytes de datos, la localización de dichos bytes en el flujo de datos está en correlación con al menos un ancla, y el al menos un ancla es un apuntador a una localización en el flujo de datos que tiene una compatibilidad con el criterio predeterminado.
8.-Servidor de comunicación según la reivindicación 7, en el cual, el criterio predeterminado es una función de datos 30 contenidos en dichos elementos de datos y es independiente de un título, una dirección o una información de encaminamiento de dichos datos.
9.-Servidor de comunicación según la reivindicación 8, en el cual la función es sensible a una combinación de caracteres predeterminada, de manera que se asigna un ancla durante el reconocimiento de dicha combinación de caracteres predeterminada. 35
10.-Servidor de comunicación según la reivindicación 9, en el cual la combinación de caracteres es una cadena corta de caracteres predefinidos.
11.-Servidor de comunicación según la reivindicación 9, en el cual se asigna un conjunto de anclas a un elemento respectivo de datos, cada ancla del conjunto está en correlación con una localización de n-tuplo en dicho elemento respectivo de datos, en el cual la función es una función hash, que da un valor predefinido en el n-tuplo. 40
12.-Servidor de comunicación según la reivindicación 11, en el cual la función hash está seleccionada entre un grupo que contiene LFSR, CRC SHA1, DES y MD5.
13.-Servidor de comunicación según una cualquiera de las reivindicaciones 1 a 12, en el cual los ficheros son suministrados a través de comunicación P2P.
14.-Procedimiento para proporcionar un flujo de datos en una red de comunicación, comprendiendo el procedimiento: 45

determinar puntos de referencia en el flujo de datos que son localizaciones en el flujo de datos donde un número predefinido de caracteres satisfacen un criterio predeterminado;

registrar una firma digital que es un valor devuelto de una función predeterminada tomada en un intervalo predefinido de contenido, el intervalo predefinido de contenido está en correlación con los puntos de referencia;

usar la firma digital para localizar contenido almacenado localmente, y usar los puntos de referencia o crear un diccionario y usarlo para sincronizar elementos de datos actualmente recibidos y contenido coincidente almacenado localmente.
15.-Soporte legible por ordenador que contiene instrucciones para controlar un sistema informático para ejecutar el procedimiento de la reivindicación 14. 5
16.-Sistema para reducir volúmenes de transporte por una red de comunicación, que comprende al menos un servidor de comunicación tal como se define en una cualquiera de las reivindicaciones 1 a 13.