ES2399491T3 - Transferencia de datos masiva - Google Patents

Abstract

Un sistema (200) de transferencia de datos para proporcionar la transferencia de datos a través de una red (224)entre un emisor (201) y un receptor (226), que comprende: un emisor configurado para transferir los datos a una velocidad de inyección especificada como se determinamediante una entrada de velocidad de inyección y para dividir los datos en bloques, teniendo cada bloque unnúmero de identificación ordenado secuencialmente; un receptor configurado para recibir los bloques de datos transmitidos por el emisor y para detectar los bloquesque se han perdido en la transmisión; en el que el receptor está configurado para enviar solicitudes de retransmisión al emisor cuando se detectanbloques perdidos; en el que el receptor está configurado para planificar la transmisión de las solicitudes de retransmisión quecorresponden a los bloques perdidos al emisor tras el vencimiento de un tiempo de espera de retransmisión,RTO, en el que el RTO se obtiene de un tiempo de ida y vuelta de la ruta prevista; en el que el emisor está configurado para almacenar las retransmisiones pendientes en respuesta a lassolicitudes de retransmisión recibidas desde el receptor; en el que el emisor está configurado para transmitir los bloques perdidos en respuesta a las solicitudes deretransmisión antes de transmitir nuevos bloques; en el que el receptor está configurado para cancelar las solicitudes de las retransmisiones planificadas tras larecepción de los bloques perdidos correspondientes; y, en el que el receptor está configurado para enviar las solicitudes de retransmisión a una velocidadproporcionada con la velocidad de inyección para, de este modo, limitar el número de retransmisionespendientes almacenadas en el emisor.

Description

Transferencia de datos masiva

Solicitudes relacionadas

Campo

La materia objeto de la presente invención se refiere a la comunicación de datos de red, y más especialmente a un protocolo de transferencia de datos masiva.

Antecedentes

Con los recientes aumentos en el ancho de banda de red, la interconexión ubicua de los usuarios a través de la Internet global, y el creciente volumen de datos digitales procesados por los usuarios de negocios y consumidores, las demandas de transferencias, basadas en red, de datos masivas (archivos y directorios) están en constante crecimiento. En particular, los usuarios desean transferir archivos más grandes, sobre redes de anchos de banda cada vez mayores, y en distancias cada vez más largas.

Tales rutas de transferencia de datos no sólo experimentan altos anchos de banda de cuello de botella y retardos de ida y vuelta debidos a la distancia geográfica, sino que también experimentan períodos de pérdidas de paquetes y retardos variables debidos a los propios medios de comunicación (por ejemplo, la conexión inalámbrica), y a la congestión de tráfico variable y a veces excesiva.

Los protocolos de transferencia de datos masiva convencionales en base al protocolo de control de transmisión (TCP) sufren limitaciones de rendimiento severas a través de las típicas rutas de la Internet global, debido al mal rendimiento del TCP a través de las redes con altos productos de retardo por ancho de banda. Se ha focalizado mucha atención en las implementaciones y protocolos de transporte alternativos para mejorar el rendimiento (velocidad de transferencia y utilización del ancho de banda) para la transferencia de datos masiva en redes de alto ancho de banda, alto retardo. Sin embargo, los enfoques actuales ofrecen rendimientos mejorados y la utilización del ancho de banda principalmente en los enlaces del núcleo de Internet, que tienen velocidades (BER) de error de bits relativamente bajas y tienen una gran cantidad de ancho de banda, evitando el tráfico de congestión. Sin embargo, la mayoría de las transferencias de datos de usuario abarcan la red de borde a borde, y no sólo experimentan altos retardos de ida y vuelta debido a la distancia geográfica, sino que también experimentan periodos de pérdidas de paquetes y características de retardo variable de la típica red de "borde". En las redes de borde típicas, los enfoques actuales no logran alcanzar la utilización del ancho de banda completa, sufren de rendimientos variables a medida que aumenta la congestión, y no pueden proporcionar las suficientes garantías en los tiempos de transferencia requeridos por los procedimientos de negocio críticos en tiempo y los usuarios consumidores más exigentes. Adicionalmente, en los casos limitados en los que los enfoques actuales hacen mejorar el rendimiento, lo hacen a expensas de la distribución equitativa del ancho de banda con otras aplicaciones de red y de no proporcionar al usuario final el control sobre el ancho de banda compartido. El usuario final se ve obligado a elegir entre un bajo rendimiento, pero una implementación de TCP convencional "equitativa", o un nuevo protocolo alternativo que proporcione un rendimiento mejorado en casos limitados, pero a expensas de la equidad del ancho de banda. Aunque esto puede ser aceptable en el núcleo de Internet, no es aceptable en las redes de borde a menudo sobre suscritas en las que las transferencias de datos se admiten para las redes con el ancho de banda disponible limitado. Un protocolo UDP NACK existente es "UDT", la segunda generación de SABUL. (Yunhong Gu, Robert L. Grossman, "UDT: A Transport Protocol for Data Intensive Applications", draft-gg-udt-01.txt, Agosto de 2004). UDT añade un algoritmo de control de flujo que utiliza un tamaño de ventana dinámico para controlar la velocidad de envío y para limitar el máximo número de acuses de recibo negativos pendientes. Aunque esta técnica coloca un límite severo en el número de retransmisiones que pueden acumularse y a su vez protege contra el colapso de congestión, se crea un cuello de botella del protocolo artificial debido a la baja eficiencia del mecanismo de retransmisión de UDT, e impone, arbitrariamente, a este transporte UDP capaz de altas velocidades de transmisión, una restricción de velocidad de envío efectiva similar a TCP. Hay una necesidad en la técnica de un sistema para la transferencia de datos que aborde las preocupaciones anteriores y proporcione un rendimiento mejorado, velocidades de transferencia predecibles independientes de la distancia de red o de la congestión (y los retardos asociados y las pérdidas de paquetes), utilización completamente automática del ancho de banda y la capacidad de compartir el ancho de banda proporcionalmente con el otro tráfico cuando no se usa ningún ancho de banda, teniendo en cuenta tanto las implementaciones actuales y futuras del protocolo TCP.

Sumario

Los problemas anteriormente mencionados y otros no expresamente descritos en el presente documento se abordan mediante la materia objeto presente y se comprenderán leyendo y estudiando esta memoria descriptiva.

La materia objeto presente proporciona un sistema de transferencia de datos de red fiable tal como se define en la reivindicación independiente 1. El sistema es útil para transferir datos a través de las redes y proporciona mejoras en las velocidades de transferencia de datos a través de las redes que usan aplicaciones de transferencia de datos de soporte lógico.

Estos elementos, y otros, del sistema están incorporados en una interfaz de gestión de programación para aplicaciones, que proporciona un control exhaustivo y monitorización de las transferencias del sistema. Otras realizaciones incluyen aplicaciones independientes, programas adicionales del sistema operativo, aplicaciones de utilidades, componentes de soporte físico, y prácticamente cualquier otro tipo de dispositivo de soporte lógico o de soporte físico capaz de proporcionar los servicios de los sistemas descritos en el presente documento.

Este sumario es una visión de conjunto de algunas de las enseñanzas de la presente solicitud y no pretende ser un tratamiento exclusivo o exhaustivo de la materia objeto presente. Se pueden encontrar más detalles sobre la materia objeto presente en la descripción detallada y las reivindicaciones adjuntas. Otros aspectos serán evidentes para los expertos en la materia tras leer y comprender la siguiente descripción detallada y la visualización de los dibujos que forman una parte de la misma, cada uno de los cuales no ha de tomarse en un sentido limitativo. El alcance de la presente invención se define mediante las reivindicaciones adjuntas y sus equivalentes legales.

Breve descripción de los dibujos

Las figuras adjuntas se proporcionan para demostrar algunos aspectos y ejemplos relacionados con el presente sistema, pero no están destinadas a ser representaciones exclusivas o exhaustivas de la materia objeto presente.

La figura 1 es un diagrama de bloques esquemático de un sistema de acuerdo con una realización de ejemplo.

La figura 2 es un diagrama de bloques de un sistema emisor/receptor de acuerdo con una realización de ejemplo.

La figura 3 es un diagrama de bloques de un procedimiento de envío de datos de acuerdo con una realización de ejemplo.

La figura 4 es un diagrama de bloques de un procedimiento de recepción de datos de acuerdo con una realización de ejemplo.

La figura 5 es un diagrama de flujo de datos de un sistema de acuerdo con una realización de ejemplo.

La figura 6 es un diagrama de flujo de datos de un sistema de acuerdo con una realización de ejemplo.

La figura 7 es un diagrama de flujo de datos de un sistema 700 de acuerdo con una realización de ejemplo.

Descripción detallada

En la siguiente descripción detallada, se hace referencia a los dibujos adjuntos que forman parte de la misma, y en los que se muestran a modo de ilustración realizaciones específicas en las que pueden practicarse la materia objeto de la invención. Estas realizaciones se describen con suficiente detalle para permitir a los expertos en la materia practicarlas, y se ha de entender que pueden utilizarse otras realizaciones y que los cambios estructurales, lógicos y eléctricos pueden hacerse sin apartarse del alcance de la materia objeto de la invención. Por lo tanto, la siguiente descripción no ha de tomarse en un sentido limitado, y el alcance de la materia objeto de la invención se define mediante las reivindicaciones adjuntas y sus equivalentes legales.

Se entiende que el sistema proporcionado en el presente documento puede realizarse usando un soporte físico, un soporte lógico, un programa fijo de máquina y combinaciones de soporte físico y/o soporte lógico y/o un programa fijo de máquina en diferentes realizaciones. Se entiende que, en diversas realizaciones, las funciones del sistema pueden corresponder a módulos, que se implementan en un soporte lógico, un soporte físico, un programa fijo de máquina, o cualquier combinación de los mismos. Los ejemplos proporcionados en el presente documento pueden combinar una o más funciones por módulo, sin embargo, se contempla que pueden realizarse otras combinaciones de funciones sin apartarse del alcance de la materia objeto presente.

En diversas realizaciones, las porciones de soporte lógico pueden ejecutarse usando los dispositivos, que incluyen, pero no se limitan a, un procesador de señal digital, ASIC, un microprocesador, un microcontrolador, u otro tipo de procesador. Los entornos en los que la materia objeto presente puede ponerse en práctica incluyen, pero no se limitan a, los entornos informáticos con dispositivos de red, tales como ordenadores, servidores, enrutadores, pasarelas, redes LAN, redes WAN, rutas de intranet y/o Internet u otros dispositivos de interconexión de red.

Algunas realizaciones implementan las funciones en dos o más módulos o dispositivos de soporte físico específicos interconectados con las señales de control y de datos correspondientes comunicados entre y a través de los módulos, o como partes de un circuito integrado de aplicación específica. Por lo tanto, el flujo del procedimiento ejemplar se puede aplicar a implementaciones de soportes lógicos, programas fijos de máquina y soportes físicos.

Se proporcionan diversas realizaciones de la materia objeto presente en el presente documento. La figura 1 es un diagrama de bloques esquemático de un sistema 100 de acuerdo con una realización ejemplar de la materia objeto presente. El sistema 100 incluye un primer nodo 102 y un segundo nodo 132 conectados por una red 122.

El primer nodo 102 incluye un procesador 104, una memoria 106 y una interfaz 112 de red acoplada al bus 114. El primer nodo 102 puede incluir, opcionalmente, un dispositivo de almacenamiento, tal como un disco 110, un dispositivo 116 de salida y un dispositivo 118 de entrada. El segundo nodo 132 incluye un procesador 134, una memoria 136, y una interfaz 142 de red acoplada al bus 144. El segundo nodo 132 puede incluir, opcionalmente, un dispositivo de almacenamiento, tal como un disco 140, un dispositivo 146 de salida y un dispositivo 148 de entrada. En distintos ejemplos, las memorias 106, 136 de tanto el primer nodo 102 y el segundo nodo 132 se ilustran como que incluyen un soporte lógico 108, 138. Tal soporte lógico incluye funcionalidades para al menos la comunicación de datos a la interfaz de red. En distintas realizaciones y aplicaciones, tal soporte lógico puede cargarse en las memorias 108, 138 desde una o más fuentes, incluyendo, pero no limitado al almacenamiento 110, 140.

La red 122, en diversas realizaciones, incluye una o más de entre Internet, una red de área local ("LAN"), una intranet, una red de área extensa ("WAN") u otro tipo de red.

El soporte lógico 108, 138 puede funcionar en el procesador 104, 134 de su nodo respectivo 102, 132 para permitir a los nodos 102, 132 intercambiar datos a través de la red 122. El soporte lógico 108, 138 hace que los nodos 102, 132 realicen diversas acciones asociadas con el intercambio de datos. Estas acciones incluyen el intercambio de datos de acuerdo con los diversos procedimientos de acuses de recibo temporizados como se demuestra a continuación.

Hay referencias a la transferencia de datos en esta discusión en términos de una "ruta de transferencia" extremo a extremo. La ruta de transferencia se extiende desde el ordenador de origen, tal como el primer nodo 102, a un ordenador de destino, tal como el segundo nodo 132, a través de una red IP, tal como la red 122. La ruta de transferencia tiene una característica de "ancho de banda del cuello de botella", un "tiempo de ida y vuelta de red" y un "tiempo de ida y vuelta de la ruta".

El ancho de banda del cuello de botella de la ruta es la capacidad de transmisión de datos mínima (unidades de datos por unidad de tiempo) a lo largo de la longitud total de la ruta de transferencia. Esto incluye la capacidad del cuello de botella de los ordenadores de envío y recepción, tal como el primer nodo 102 y el segundo nodo 132, y la capacidad del cuello de botella de la red 122, que incluye uno o más saltos de red. La capacidad del cuello de botella de los nodos 102, 132 es el rendimiento de datos mínimo (datos por unidad de tiempo) de los recursos utilizados en una transferencia de datos, que incluyen el almacenamiento 110, 140 o la velocidad de lectura/escritura de la memoria106, 136, la velocidad del bus 114, 144 del ordenador, el procesador 104, la velocidad 134, y la velocidad del interfaz 112, 142 de red. La capacidad del cuello de botella de la red 122 es el ancho de banda mínimo de los enlaces de red individuales que comprenden la ruta de red.

El tiempo de ida y vuelta de la ruta ("RTT de la ruta") es el tiempo requerido para que una unidad de datos viaje desde el receptor de datos a la fuente y vuelva. Por ejemplo, el RTT de la ruta incluye el tiempo para leer la unidad de datos desde el segundo almacenamiento 140 del nodo 132 o de la memoria 136, transmitir de vuelta la unidad de datos a través de la red 122 al primer nodo 102, y leer la unidad de datos en memoria 106, y transmitir la unidad de datos de vuelta por la red 122 al segundo nodo 132 y leer la unidad de datos en el interior de la memoria 136. En un ejemplo, el tiempo se mide usando "marcadores" de tiempo en el paquete que indican el inicio de la transmisión y, en última instancia, el momento de la recepción.

El tiempo de ida y vuelta de red ("RTT de red ") es el tiempo requerido para que una unidad de datos viaje a través de la red 122 comenzando desde el momento en que se envía a través de la red mediante el ordenador receptor, al momento en que la unidad de datos llega al ordenador emisor y, a continuación, vuelve al ordenador receptor, algunas veces referido como "latencia de red".

En diversas realizaciones, el RTT de red incluye el tiempo de la solicitud para viajar "hacia abajo de la pila de comunicación" en el ordenador de destino (la capa del protocolo de red para la pila de red en el sistema operativo de la interfaz física), el tiempo para que la solicitud viaje a través de la red hacia el ordenador emisor, el tiempo para que el ordenador emisor reciba la solicitud de retransmisión y envíe la siguiente unidad de datos programada (incluye un pase "hacia arriba de la pila" para recibir la solicitud de retransmisión entrante (la interfaz física para la pila de red en el sistema operativo de la capa del protocolo del sistema) y un pase "hacia abajo de la pila" para enviar la siguiente unidad de datos programada (la capa del protocolo del sistema a la pila de red en el sistema operativo de la interfaz física), más el tiempo de viaje a través de la red al ordenador de destino.

El producto ancho de banda por retardo ("BDP") de una ruta de transferencia dada es una expresión de la capacidad de los datos total de la ruta y es igual a los tiempos del ancho de banda del cuello de botella por el tiempo de ida y vuelta. Para los fines de esta divulgación, al BDP se le referencia en términos de tiempo de ida y vuelta de la red, pero obsérvese que para redes de ancho de banda muy alto el ancho de banda del cuello de botella y el BDP pueden, en realidad, determinarse por el ancho de banda del ordenador.

La transferencia de datos se define en términos de "velocidad de inyección de datos", "velocidad de recepción" y "velocidad de recepción útil", que determina la "eficiencia". La velocidad de inyección de datos ("Ri (t)") es la velocidad a la que un emisor inyecta datos en la red en nombre de una aplicación de envío (por ejemplo, medido en bits o en bytes por segundo). La velocidad de recepción de datos ("Rr (t)") es la velocidad a la que un receptor lee datos desde la red 122 en nombre de la aplicación de recepción. La velocidad de recepción útil ("Ru (t)") es la velocidad a la que el receptor recibe datos "útiles", que incluye datos que no se ha recibido previamente (por ejemplo, datos duplicados).

También se usan a lo largo de esta descripción los términos "velocidad de recepción duplicada" y "eficiencia de la transferencia". La velocidad de recepción duplicada ("Rd (t)") es la velocidad a la que el receptor recibe los datos ya recibidos.

La eficiencia de la transferencia es la relación entre la velocidad de recepción útil y la velocidad de recepción total (Ru/Rr). La eficiencia (100%) de transferencia máxima se logra cuando Ru se aproxima a Rr y no se reciben datos duplicados (lo que quiere decir que la cabecera de datos redundantes del protocolo es insignificante): Ru/Rr ~ 1 y Rd ~ 0

Un protocolo "perfectamente eficiente" transfiere todos los datos necesarios, que puedan requerir retransmisión de los datos perdidos debido a las pérdidas de paquetes en la ruta de transferencia, con transmisiones no redundantes. Obsérvese que la eficiencia no es el mismo que la utilización del ancho de banda.

Un sistema 100 estable, de acuerdo con diversas realizaciones, converge a un rendimiento de estado estacionario que no oscila en el uso del ancho de banda en el caso de pérdida de paquetes, el retardo de red y la variación de la pérdida de paquetes y el retardo de red. Esto permite que la aplicación 108 en el sistema 102 elija una velocidad Ri de inyección de datos arbitraria sin alterar la estabilidad del sistema 100. Si el sistema 100 usa una velocidad objetivo fija, los datos se inyectan de manera constante en la red 122 y no se crean "ráfagas". En algunas realizaciones, en las que el sistema 100 usa una velocidad de adaptación dinámica, la velocidad se desarrolla a una velocidad de equilibrio en proporción a la distancia desde el equilibrio, no a la velocidad de transferencia actual, para la estabilidad a altas velocidades. También, un protocolo estable que usa una velocidad de adaptación dinámica no llena en exceso las memorias intermedias de los enrutadores intervinientes en la ruta de transferencia y deteriora el pequeño tráfico de "ratones".

Algunas realizaciones incluyen parámetros que se usan para medir el rendimiento del sistema 100, incluyen "previsibilidad", "equidad de ancho de banda" y "control de velocidad independiente". La velocidad (Ru) de recepción de datos útiles es "previsible" si el rendimiento de la transferencia y el tiempo es determinista a través de las condiciones de la ruta variable e impredecible, tal como la latencia de ida y vuelta variable y la pérdida de paquetes.

Un protocolo se considera con "un ancho de banda equitativo" para la norma TCP ("compatible TCP") si un único flujo que compite con TCP es igualmente agresivo y comparte el ancho de banda BW del cuello de botella en la misma proporción, de manera que la velocidad de cada flujo es BW/N para los N flujos que compiten. Para un alto rendimiento y equidad en las redes básicas, un protocolo de transferencia confiable comparte ambas, equitativamente, con TCP y tiene una equidad "máxima-mínima": Cuando un flujo TCP no usa su cuota proporcional completa del ancho de banda, el sistema 100, en algunas realizaciones, consume el ancho de banda restante.

El sistema 100 ofrece "control de velocidad independiente" para una aplicación si la velocidad de inyección de datos no está acoplada al mecanismo de fiabilidad, y el sistema 100 expone una interfaz a la aplicación a usar en la manipulación del control de la velocidad. Algunos parámetros de diversas realizaciones que pueden manipularse incluyen ajustes de la velocidad discretos tales como una velocidad objetivo o velocidades máxima-mínima, agresividad relativa y políticas de priorización. El sistema 100, en algunas realizaciones, también proporciona retroalimentación inteligente a la aplicación, tales como estadísticas de rendimiento, tales como velocidad efectiva, bytes contiguos transferidos y el impacto en la red medido en la forma de tiempo de ida y vuelta, de paquetes perdidos en la ruta de transferencia y sobrecarga del protocolo.

Para lograr las propiedades del sistema 100 anteriormente descritas (estabilidad y previsibilidad en el caso de pérdida de paquetes, el retardo de red y la variación de la pérdida de paquetes y el retardo de red, la eficiencia Ru/Rr~1 y el control de velocidad independiente), las realizaciones propuestas para un sistema de transporte de datos masivo fiable proporciona los procedimientos siguientes:

a.

Las solicitudes de retransmisión se almacenan en el receptor cuando los bloques se pierden

b.

El almacenamiento de la solicitud de retransmisión tiene las propiedades de estructura de datos siguientes

i. el tiempo de inserción en el almacenamiento debe ser en un tiempo constante O (1)

ii. para solicitarse la recuperación o la retransmisión debe ser en un tiempo constante O (1)

iii. encontrar y cancelar la(s) solicitud(es) pendiente(s) de retransmisión cuando el bloque retransmitido que se reciba debe ser en un tiempo constante O (1)

c.

Las solicitudes de retransmisión recibidas por el emisor se almacenan en el almacenamiento del emisor. El almacenamiento del emisor no debe crecer cuando crezca la pérdida de paquetes.

i. el receptor sólo envía solicitudes de retransmisión a la velocidad que el emisor pueda enviar los bloques retransmitidos

ii. el almacenamiento del emisor de solicitudes de retransmisión debe tener en cuenta el tiempo de inserción constante (la realización propuesta proporciona un tiempo O (log (n) de inserción logarítmica), pero como el tamaño del almacenamiento del emisor no crece con el aumento de la pérdida de paquetes, el tiempo de inserción es prácticamente constante)

iii. el emisor debe enviar bloques retransmitidos en orden (el más pequeño el primer índice) para optimizar el rendimiento de la lectura del disco, por lo que encontrar el índice de retransmisión mínimo en el almacenamiento debe ser en un tiempo constante O (1).

d.

Las solicitudes de retransmisión deben alcanzar al emisor sin retardo. El receptor envía las solicitudes de retransmisión en paquetes de tamaño lo más pequeños posible dada la cantidad de solicitudes de retransmisión que necesitan enviarse y la velocidad a la que tienen que enviarse.

e.

El sistema receptor debe procesar los datos de entrada a la velocidad a la que se reciben. Si los datos deben escribirse en el disco del sistema receptor, tiene que hacerse de una manera óptima.

f.

Si el sistema receptor no puede procesar los datos de entrada a la velocidad a la que se han recibido, debido a limitaciones del sistema, los datos de entrada se descartan y los bloques descartados se consideran perdidos para el fin del mecanismo de retransmisión.

La figura 2 es un diagrama de bloques de un sistema 200 de acuerdo con una realización de ejemplo. El sistema 200 incluye un sistema 201 emisor y un sistema 226 receptor. El sistema 201 emisor y el sistema 226 receptor están conectados entre sí a través de una red 224.

El sistema 201 emisor de la realización del sistema 200 incluye un conjunto de módulos. Estos módulos incluyen un módulo 222 de iniciación de transferencia, un módulo 218 fuente del sistema de archivos de datos, un módulo 203 fuente de la aplicación de datos, un módulo 206 manejador de bloque y un módulo 208 criptográfico opcional. El sistema 201 emisor incluye además un módulo 210 de egestión de bloque, un módulo 216 lector de retroalimentación, un módulo 214 de control de la velocidad, un módulo 212 de retransmisión, un módulo 204 de interfaz de gestión, y un módulo 222 de iniciación de transferencia.

El módulo 222 de iniciación de transferencia maneja el establecimiento de un canal de control con el sistema 226 receptor. El canal de control puede usar un transporte base confiable o no confiable (por ejemplo, TCP o UDP). El canal de control puede asegurarse también usando un procedimiento de clave pública-privada, tal como la capa de conexión segura ("SSL") o el intérprete de órdenes seguro ("SSH"). Usando el canal de control, el módulo 222 de iniciación de transferencia maneja la autenticación en nombre de la aplicación 202 del emisor enviando las credenciales al sistema 226 receptor, y puede intercambiar, opcionalmente, una clave de cifrado simétrica por sesión para su uso en el cifrado de los datos. El módulo 222 de iniciación de transferencia maneja también la negociación de los parámetros de transmisión, tales como el tamaño de bloque, la velocidad objetivo, etc., e intercambia los metadatos de archivos o directorios para construir el archivo de destino y reanudar las transferencias parciales. Los metadatos incluyen atributos tales como el nombre de archivo, el tamaño, los parámetros de control de acceso y la suma de verificación.

El módulo 218 fuente del sistema de archivos de datos proporciona una secuencia de datos a transferir desde un disco 220 o memoria accesibles para el sistema 201 emisor a través del sistema 218 de archivo del sistema 201 del emisor. La secuencia puede ser un archivo, un directorio, una secuencia de bytes sin procesar o prácticamente cualquier otro tipo o forma de datos.

El módulo 203 fuente de aplicación de datos proporciona una secuencia de datos transmitidos en el espacio de memoria de la aplicación 202 del emisor.

El módulo 206 manejador de bloque ingiere datos leyendo bloques de datos del sistema de archivos o desde el espacio 203 de memoria de la aplicación 202 del usuario cuando se necesite para la transmisión o la retransmisión.

El módulo 208 criptográfico es un módulo opcional dentro del sistema 201 emisor. El módulo 208 criptográfico opcional encripta bloques de datos y añade la autenticación asimilada para la verificación de la integridad.

El módulo 210 de egestión de bloque escribe bloques de datos a la red 224.

El módulo 216 lector de retroalimentación lee la información de retroalimentación de control desde el sistema 226 receptor, que incluye las solicitudes de retransmisión de bloques perdidos, estadísticas de transferencia y la velocidad objetivo dinámica. El módulo 216 lector de retroalimentación analiza el tipo de mensaje y pasa la carga útil al módulo apropiado para su procesamiento, tales como el módulo 212 de retransmisión, el módulo 214 de control de la velocidad, o la interfaz 204 de gestión.

El módulo 214 de control de la velocidad programa los bloques para la transmisión con respecto a la velocidad objetivo (por ejemplo, bits por segundo).

El módulo 212 de retransmisión almacena las solicitudes de retransmisión de entrada en una estructura de datos que permite la ordenación mediante un número de secuencia. Además, el módulo 212 de retransmisión emite los números de bloque a retransmitir.

El módulo 204 de interfaz de gestión proporciona una interfaz de monitorización y control desde la que se emite las órdenes de control y se leen las estadísticas de transferencia.

El sistema 226 receptor de la realización del sistema 200 incluye un conjunto de módulos. Estos módulos incluyen un módulo 225 de iniciación de transferencia, un módulo 250 de destino del sistema de archivos de datos, un módulo 227 de destino de la aplicación de datos, un módulo 230 manejador de bloque, y un módulo 232 criptográfico opcional. El sistema 200 receptor incluye además un módulo 236 de ingestión de bloque, un módulo 248 escritor de retroalimentación, un módulo 242 de control de la velocidad, un módulo 246 de retransmisión, un módulo 228 de interfaz de gestión y un módulo 225 de iniciación de transferencia.

El módulo 225 de iniciación de transferencia maneja el establecimiento de un canal de control con el sistema 201 emisor. El canal de control puede usar un transporte base confiable o no confiable (por ejemplo, TCP o UDP). El canal de control puede asegurarse también usando un procedimiento de clave pública-privada, tal como la capa de conexión segura ("SSL") o el intérprete de órdenes seguro ("SSH"). Usando el canal de control, el módulo 225 de iniciación de transferencia maneja la autenticación en nombre de la aplicación 227 del receptor enviando las credenciales al sistema 201 emisor, y puede intercambiar, opcionalmente, una clave de cifrado simétrica por sesión para su uso en el cifrado de los datos. El módulo 225 de iniciación de transferencia maneja también la negociación de los parámetros de transmisión, tales como el tamaño de bloque, la velocidad objetivo, etc., e intercambia los metadatos de archivos o directorios para construir el archivo de destino y reanudar las transferencias parciales. Los metadatos incluyen atributos tales como el nombre de archivo, el tamaño, los parámetros de control de acceso y la suma de verificación.

El módulo 236 de ingestión de bloque lee los bloques de datos de la red 224.

El módulo 232 criptográfico es opcional. Las realizaciones que incluyen el módulo 232 criptográfico descifran bloques de datos cifrados y verifican la autenticación asimilada de la integridad.

El módulo 230 manejador de bloque procesa los bloques de datos de entrada. Este procesamiento incluye la extracción de un sello de tiempo de ida y vuelta de red y pasarlo al módulo de cálculo de la velocidad y la extracción de un sello de tiempo de ida y vuelta de ruta y pasarlo al módulo de predicción del tiempo de espera. Además, el procesamiento incluye la copia de la carga útil dentro del módulo 234 escritor de disco para la egestión.

El módulo 234 escritor de disco implementa la lógica para maximizar el receptor de la velocidad de entrada/salida ("I/O"), minimizando el inter-bloqueo entre las operaciones de lectura de red y la escritura de disco. El módulo 234 escritor de disco usa un número de memorias intermedias y asigna en cualquier momento una memoria intermedia para la lectura de la red 224 y una para la escritura del disco 252. Una vez que la memoria intermedia se llena mediante el lector de red, se pasa al módulo 234 escritor de disco y se asigna una nueva memoria intermedia al lector de red.

El módulo 238 de memoria caché de archivos implementa la lógica para maximizar la velocidad a la que los bloques se escriben en el disco 252 o en la memoria del sistema, minimizando la escritura fuera de secuencia y escribiendo los bloques de tamaño óptimo del sistema de archivos específico.

El módulo 250 de destino del sistema de archivo de datos es un archivo o directorio en un disco 252 o en la memoria del sistema accesible al ordenador local a través de un sistema de archivos en el que se escriben los datos recibidos.

El módulo 229 de destino de la aplicación de datos es una secuencia de memoria en el receptor 226 de la aplicación 227 del espacio 229 de memoria en el que se escriben los datos recibidos.

El módulo 246 de retransmisión almacena la información de los bloques de datos perdidos para su recuperación mediante el índice. La información almacenada incluye el número de secuencia y el sello de tiempo de cuando se envió originalmente el bloque de datos perdido.

El módulo 248 escritor de retroalimentación envía información de retroalimentación al sistema 201 emisor. La información de retroalimentación puede incluir solicitudes de retransmisión, estadísticas, la velocidad de destino calculada y cualquier otra información relacionada con el intercambio de datos entre un sistema 201 emisor y un sistema 226 receptor.

El módulo 240 de predicción del tiempo de espera calcula el tiempo que debe transcurrir hasta la retransmisión de la solicitud de los bloques perdidos (RTO), usando un algoritmo de estimación recursivo que predice el tiempo de ida y vuelta de la ruta en base a las mediciones de ida y vuelta.

El módulo 242 de control de la velocidad calcula la velocidad de transmisión objetivo de acuerdo con un mecanismo de control de velocidad configurado que especifica una velocidad fija o una velocidad adaptativa dinámicamente como una función del tiempo de ida y vuelta de red medido.

El módulo temporizador 244 almacena los números de secuencia de los bloques para la retransmisión de acuerdo con el tiempo absoluto en el que se vence la solicitud de retransmisión. El tiempo absoluto se da mediante el RTO calculado por el módulo de predicción del tiempo de espera. El módulo temporizador envía una lista de los números de secuencia de bloques debidos a la retransmisión en el momento actual al módulo de retransmisión.

El módulo 228 de interfaz de gestión proporciona una interfaz de monitorización y control desde la que se emite las órdenes de control y se leen las estadísticas de transferencia.

El módulo 254 de diferenciación de archivo evalúa los datos ya presentes en el sistema 226 receptor y los compara con los datos del sistema 201 emisor para determinar si algunos datos idénticos están ya presentes y no se requiere la transmisión. En una realización, se hace una comparación entre un archivo del receptor que tiene un nombre idéntico al archivo del emisor en base a los atributos tales como el tamaño, el tiempo modificado y una suma de verificación de contenido. Si los archivos son idénticos no se transfieren datos. Si el archivo se transfiere parcialmente, el módulo de diferenciación del archivo determina el desfase en el que la transferencia debería comenzar o reanudarse.

Se entiende que las funciones exactas, cómo se agrupan e interconectan y los procedimientos ejecutados por cada uno pueden variar sin apartarse del alcance de la materia objeto presente.

La figura 3 es un diagrama de bloques de un procedimiento 300 de acuerdo con una realización de ejemplo. El procedimiento 300 es un procedimiento ejecutable en un ordenador para enviar un archivo, u otra estructura de datos, desde un sistema fuente a un sistema de destino. El procedimiento 300 incluye la recepción de una orden para transmitir un archivo o la otra estructura 302 de datos a un sistema de destino, el establecimiento de una conexión y el intercambio de los datos de control con el sistema 304 de destino, y la división del archivo, o de la otra estructura de datos, en bloques 306 numerados. Además, el procedimiento 300 incluye la determinación de, si se ha recibido una solicitud de retransmisión y está pendiente 308, se retransmite cualquiera de los bloques 310 solicitados antes de transmitir los bloques adicionales. El procedimiento 300 incluye también la determinación de, si hay bloques restantes para transmitir 312, se transmite el siguiente bloque en la secuencia 314 numerada. Si no hay bloques restantes para transmitir, el procedimiento 300 determina si ha habido una indicación recibida desde el sistema de destino de que se ha recibido el último bloque 316. Si esa indicación se ha recibido, el procedimiento 320 termina, de lo contrario el procedimiento 318 retransmite el último bloque.

La figura 4 es un diagrama de bloques de un procedimiento 400 para recibir un archivo, u otra estructura de datos, en un sistema de destino desde un sistema de origen de acuerdo con una realización de ejemplo. El procedimiento 400 incluye la recepción de una orden para recibir un archivo, u otra estructura 402 de datos, el establecimiento de una conexión y el intercambio de datos de control con el sistema 404 de origen, y la asignación de espacio de almacenamiento y la división del espacio de almacenamiento en bloques de acuerdo con un número de bloques 406 que se recibirán. Además, el procedimiento 400 incluye la recepción de un bloque 408 numerado, la determinación de si el bloque 410 se ha recibido previamente, el descarte 412 del bloque si se ha recibido previamente, o la escritura del bloque en su respectivo bloque de almacenamiento que corresponde al número del bloque 414 recibido. El procedimiento 400 determina, a continuación, si existe un hueco en los bloques 422 recibidos. Si existe un hueco, el procedimiento 416 programa la retransmisión del(os) bloque(s) perdido(s), determina si los bloques perdidos ya deberían haberse recibido 418, y solicita la retransmisión 420 del(os) bloque(s) perdido(s). A continuación, el procedimiento 400 determina si el bloque 424 recibido se solicitó para su retransmisión. Si el bloque se retransmitió, el bloque se elimina de la planificación de retransmisión. Seguidamente, el procedimiento 400 determina si el bloque 428 fue el último bloque. Si fue el último bloque, el procedimiento 400 termina 430. De lo contrario, el procedimiento 400 se repite hasta que se han recibido todos los bloques.

Se entiende que las variaciones en el flujo del procedimiento y el rendimiento de los procedimientos individuales pueden variar sin apartarse del alcance de la materia objeto presente.

Algunas realizaciones de los procedimientos 300 y 400, ilustradas en la figura 3 y la figura 4 respectivamente, proporcionan a las aplicaciones de ordenador la capacidad de transportar de manera fiable secuencias de bloques de datos entre sí. En algunas realizaciones, el procedimiento 300 y el procedimiento 400 se incluyen en una única aplicación de ordenador para proporcionar a un sistema la capacidad de ser un emisor y un receptor.

En funcionamiento, un sistema emisor funciona de acuerdo con el procedimiento 300 de la figura 3 para transferir una estructura de datos en una secuencia desde una fuente a un sistema receptor de destino a una velocidad objetivo solicitada o en el ancho de banda del cuello de botella de la ruta, el que sea el menor. El sistema receptor funciona de acuerdo con el procedimiento 400 ilustrado en la figura 4. La transferencia se realiza con una alta eficiencia, sin reparar en el tiempo de ida y vuelta de la ruta antes de la transmisión o en la variación en la latencia de ida y vuelta y la pérdida de paquetes durante la transmisión.

Cuando se solicita un velocidad objetivo constante, la velocidad de transferencia se mantiene constante, menos la velocidad de pérdida de paquetes, incluso con congestión. Cuando se utiliza un modo de ancho de banda equitativo, la velocidad de transferencia debería adaptarse de manera automática para utilizar el ancho de banda disponible cuando la red está ligeramente cargada, pero se adapta a una proporción configurada por el usuario de una velocidad equitativa TCP cuando la red está congestionada (no hay ancho de banda disponible).

La figura 5, la figura 6 y la figura 7 muestran diversos aspectos incluidos en una variedad de realizaciones de la materia objeto presente. Estas figuras proporcionan, entre otras cosas, detalles sobre la medición del tiempo de ida y vuelta, retransmisión de datos, y cálculo y actualización de las velocidades de inyección de datos de acuerdo con algunos ejemplos, y no se pretende que sean una demostración exhaustiva o exclusiva.

La figura 5 es un diagrama de flujo de datos de un sistema 500 de acuerdo con una realización de ejemplo. El sistema 500 incluye un emisor que tiene una fuente 502 de datos original, una red 504 y un receptor que tiene un destino 506 de datos final. Las solicitudes de transmisión se envían mediante el receptor que lleva un sello de tiempo que se usa para calcular el tiempo de ida y vuelta instantáneo para los procedimientos de fiabilidad (es decir, el RTT de la ruta) y la medición de la congestión (es decir, el RTT de red). Cada sello de tiempo se acompaña mediante una bandera para cada tipo (n = RTT de red, p = RTT de la ruta). "n" solicitudes (Trex) de retransmisión se envían en un intervalo de tiempo regular desde el receptor al emisor. Si no hay retransmisiones cuando se espera una medición "n", se envía una solicitud de retransmisión vacía.

La figura 5 incluye las siguientes señales de referencia "T" que tienen los siguientes significados:

T1: el tiempo en el que una solicitud de retransmisión se envía por el receptor T2: el tiempo en el que la solicitud de retransmisión llega al emisor T3 (p): el tiempo en el que el bloque que satisface la solicitud de retransmisión se envía por el emisor T3 (n): el tiempo en el que el primer bloque se envía, después de que se reciba la recepción de la solicitud de

retransmisión marcada con "RTT de red" T4: el tiempo en el que este bloque llega al receptor

Los siguientes cálculos son útiles en diversas realizaciones y pueden realizarse usando los tiempos medidos T1, T2, T3 (p), T3 (n) y T4:

Treverse_network = T2 - T1 Trex_sendqueue = T3 (p) - T2 Tforward_network = T4 - T3 (n o p) RTT path USADO PARA LA PLANIFICACIÓN DE LA SOLICITUD DE RETRANSMISIÓN (ALGORITMO

FIABILIDAD): RTT_path = Treverse_network + Trex_sendqueue + Tforward_network = T2 - T1 + T3 (p) - T2 + T4 - T3 (p)

= T4 - T1 RTT network USADO PARA LA CONGESTIÓN DE RED (ALGORITMO DE CONTROL DE LA VELOCIDAD

ADAPTATIVA): RTT_network = Treverse_network + Tforward_network = T2 - T1 + T4 - T3 (n) = T4 - T1 + (T2 - T3 (n))

La figura 6 es un diagrama de flujo de datos de un sistema 500 de acuerdo con una realización de ejemplo. La ilustración de la figura 6 proporciona mayor detalle de la generación y el procesamiento de la solicitud de retransmisión y la medición del tiempo de acuerdo con algunas realizaciones.

En el tiempo T1, el receptor añade los bloques perdidos que han llegado debido a una PDU de solicitud de retransmisión. En algunas realizaciones, las retransmisiones se "esperan" cuando un tiempo igual al RTT estimado actual, el "RTO", ha transcurrido. El tiempo actual se registra en un marcador (TK) de sello de tiempo en la cabecera de la PDU de solicitud de retransmisión y se establece la bandera tipo del marcador ("P" de la ruta o "N" de red). Los marcadores "N" de red se envían en un intervalo periódico. Si no es el momento de enviar un marcador "N", el marcador por defecto es "P".

En el tiempo T2 la solicitud de retransmisión llega al emisor. El emisor inserta la solicitud en una cola ordenada de manera secuencial por el número de bloque. Cada bloque se almacena con su marcador TK de sello de tiempo.

Cuando se recibe una solicitud de retransmisión contiene un marcador tipo "N", la PDU de datos siguientes enviada (de retransmisión u original) incluye el marcador TK ajustado mediante el tiempo de procesamiento del emisor para medir únicamente el tiempo de red: TK = TK + (T3 (p) - T2).

El emisor envía continuamente bloques a la velocidad Ri de inyección. Todas las retransmisiones encoladas se envían antes de que se envíen los datos nuevos. Si hay retransmisiones encoladas, el emisor elige el número de bloque más pequeño y relee ese bloque desde el disco. El bloque de datos retransmitido, su sello TK de tiempo y el tipo (P/N) se encapsulan en la PDU.

Cuando se recibe un bloque de datos por el receptor en el instante T4, si el bloque contiene un marcador, el receptor actualiza la estimación predictiva de la red o el tiempo (RTO) de ida y vuelta de la ruta. El receptor calcula el tiempo (RTT_i) de ida y vuelta de muestra desde el marcador incrustado, e introduce el tiempo de ida y vuelta de muestra en una función estimadora predictiva para calcular el RTO de la ruta o la red.

La figura 7 es un diagrama de flujo de datos de un sistema 500 de acuerdo con una realización de ejemplo. Esta ilustración muestra tanto el cálculo de la nueva velocidad de inyección de nuevo mediante el receptor 506 como una función de los parámetros de entrada tales como la velocidad máxima/mínima, la política de compartición del ancho de banda, tales como la velocidad constante o la velocidad automáticamente adaptada, y la agresividad relativa para TCP, todos los cuales pueden proporcionarse en tiempo real a través de una interfaz de gestión, y la propagación de la nueva velocidad para el emisor.

La secuencia de datos que va a transmitirse se divide en bloques de igual tamaño. El tamaño de los bloques de datos se calcula de manera que la unidad de datos de protocolo (PDU) que lleva los datos (carga útil + cabecera de la aplicación + cabeceras de paquetes encapsulados) no superará la unidad de transmisión máxima (MTU) para las redes que esta PDU es probable que pueda atravesar.

El sistema garantiza la transmisión de todos los bloques y la reconstrucción del archivo de origen en el destino. Los bloques se numeran en secuencia. El receptor del sistema anota los bloques perdidos y pide al emisor del sistema que retransmita los bloques perdidos hasta que todos los bloques se reciben y se escriben en el archivo de destino. Los bloques recibidos se escriben en el disco o en la memoria tal como se reciben, creando un archivo disperso que se llena gradualmente hasta que se complete.

El emisor del sistema empieza enviando los bloques en orden, a la velocidad objetivo especificada por el usuario (bien como un valor absoluto o como un porcentaje de la capacidad de ancho de banda descubierta automáticamente) o calculada por el mecanismo de velocidad adaptativa. En el modo de velocidad adaptativa, el emisor puede, opcionalmente, usar un mecanismo de inicio lento en el que la velocidad de envío inicial es una fracción de la velocidad de envío y el algoritmo de la velocidad adaptativa automáticamente incrementa la velocidad objetivo a lo largo de unos pocos segundos. Cada bloque incluye un número de bloque, usado para reconstruir el archivo en el receptor. El emisor puede recibir solicitudes de retransmisiones de bloques desde el receptor. En ese caso, el emisor almacena las solicitudes de retransmisiones y reenvía los bloques solicitados a la velocidad especificada por el usuario o calculada por el mecanismo de velocidad adaptativa. El servidor envía todos los bloques debidos a la retransmisión antes de enviar cualquier nuevo bloque. Cuando no hay más bloques para retransmitirse o nuevos bloques para transmitir, el servidor entra en un estado de terminación en el que envía el último bloque del archivo repetidamente hasta que el receptor indica la recepción del archivo completo, o envía más solicitudes de retransmisión.

El sistema receptor espera la recepción de los bloques de datos. Tras la recepción de un bloque, si el bloque no se ha recibido previamente, el receptor pasa el bloque a una memoria, tal como a un subsistema de disco o a la memoria del sistema. Si el número de secuencia de bloque indica un hueco en la recepción de bloques, el receptor planifica la retransmisión de todos los bloques perdidos que tienen el número de secuencia entre el último bloque recibido previamente y este bloque.

El planificador de retransmisión funciona para solicitar la retransmisión de los bloques perdidos como una función de un temporizador que determina cuándo enviar las solicitudes de retransmisión. El temporizador de retransmisión de la planificación se basa en una medición predictiva del tiempo de ida y vuelta de la ruta. Cuando se vence un lote de retransmisiones, el receptor envía las solicitudes de retransmisión de estos bloques al emisor. Cuando se reciben los bloques retransmitidos, sus entradas se eliminan del planificador de retransmisión pendiente. Los bloques se pasan a la memoria, al disco, o a otra localización con la posición de desfase de archivo apropiada, y se escriben en el archivo. Cuando se ha recibido el último bloque de datos, cualquiera de las retransmisiones restantes se solicita de acuerdo con un algoritmo de terminación rápida. Cuando se han recibido todos los bloques, el receptor envía un mensaje de terminación al emisor.

Diversas otras realizaciones proporcionan procedimientos para lograr una alta eficiencia de transferencia de datos y velocidades de transferencia predecibles independientes de la latencia de ida y vuelta y las pérdidas de paquetes para altas velocidades de inyección fijadas arbitrariamente.

Algunas de tales realizaciones proporcionan un transporte en base al bloque que proporciona un acceso a datos no secuencial de la aplicación de transferencia de datos y proporcionan velocidades de inyección de alta precisión que se desacoplan de la recepción fiable de datos.

Las realizaciones que proporcionan un acceso a datos no secuencial de la aplicación de transferencia de datos incluyen un transporte en base al bloque que solicita la fuente de datos, tal como un sistema de disco, memoria, o una aplicación, para proporcionar datos en bloques discretos, y no, necesariamente, en orden secuencial.

Estas realizaciones definen el tamaño de un "bloque" de datos y solicitan a la aplicación que proporcione los bloques, individualmente o como un intervalo. Por ejemplo, en el caso de una transferencia de archivos regular, tales realizaciones definen un bloque como un número de bytes. (El tamaño puede configurarse mediante la aplicación, un valor fijo precodificado en la implementación o descubierto a través de un sondeo del tamaño de la MTU de la ruta de transferencia. Para la eficiencia del rendimiento máximo, el tamaño de bloque debería ser tan grande como sea posible sin exceder la MTU de la ruta y haciendo fragmentación de paquetes, con el fin de evitar cualquier sobrecarga innecesaria en el reensamblaje de los paquetes fragmentados en la capa IP más baja). El archivo se divide en bloques, con el primer bloque siendo el bloque número 1. No hay garantía del orden y del número de veces que se solicitará un bloque determinado. En cualquier momento dado, la aplicación se provee con el número de bloque más pequeño que se solicitará. En base a esta información, la aplicación puede descartar bloques anteriores, evitando la sobrecarga de almacenar grandes memorias intermedias de datos en la memoria y, funcionando en potencia, sobre datos secuenciales en paralelo.

Algunas realizaciones incluyen una velocidad de inyección de datos independiente de su mecanismo de fiabilidad. En tales realizaciones, la velocidad de inyección no depende de si los datos se recibieron correctamente y el algoritmo de control de la velocidad está bajo el control explícito, independiente de la aplicación. Esto proporciona la capacidad para lograr el retardo de red y el rendimiento de la transferencia independiente de la pérdida del paquete, más un control de la velocidad de transferencia independiente dado para la aplicación.

Las aplicaciones que funcionan de acuerdo con estas realizaciones usan una velocidad de inyección objetivo, o configurada por la aplicación (por ejemplo, como un valor absoluto o como un porcentaje de una capacidad del ancho de banda configurada o descubierta automáticamente) o calculada usando un algoritmo basado en una ecuación, y controlan la velocidad de inyección usando sincronización en lugar de acuses de recibo. Este control de la velocidad mantiene la velocidad objetivo con una precisión relativa, independiente de la carga del sistema, y es compatible con la CPU para otras aplicaciones. Debido a que estas realizaciones no requieren acuses de recibo secuenciales de los datos transmitidos para fichar a los nuevos datos en la red, los datos pueden resolicitarse desde la aplicación en cualquier orden, eliminando la necesidad de mantener un almacenamiento redundante de los bloques transmitidos hasta que se reciba el acuse de recibo.

En el modo de "velocidad fija", las aplicaciones de acuerdo con estas realizaciones mantienen una velocidad de inyección constante, o cuando usando un algoritmo de control de "velocidad adaptativa", ajustan la velocidad objetivo de acuerdo a la medición en curso del ancho de banda de red disponible y una relativa agresividad configurable con respecto a TCP que puede exponerse explícitamente a la aplicación. La aplicación puede establecer sobre la marcha el modo de control de la velocidad (por ejemplo, fijo o adaptativo), y los parámetros de contorno incluyendo la velocidad objetivo, las velocidades de transferencia máxima y mínima y los factores de escala para la equidad del ancho de banda. (Mientras que las implementaciones actuales pueden encontrar más útil expresar el factor de escala para la velocidad objetivo calculada en relación al TCP convencional (Reno), la escala puede ser relativa a cualquier implementación compatible TCP que tenga un rendimiento de estado estacionario como una función de parámetros de red de extremo a extremo que se pueden medir, tales como el tiempo de ida y vuelta y la pérdida de paquetes).

En algunas realizaciones que maximizan la utilización de la red es importante, precisamente, que el sistema emisor envíe los datos a la velocidad de inyección requerida (calculada o predeterminada). Los problemas que necesitan resolverse para lograr esto se relacionan primero a los mecanismos de sincronización que proporcionan los sistemas operativos, y segundo a la carga del sistema.

En primer lugar, en los sistemas operativos multi-procedimiento, la granularidad de la conmutación de procedimientos es mucho mayor que el “tiempo entre paquetes" requerido por las transmisiones de red de alta velocidad. Típicamente, la granularidad es del orden de 10 a 20 milisegundos, lo que significa que una vez que un procedimiento abandona la CPU, no se ejecutará de nuevo durante al menos 10-20 milisegundos. Enviando un paquete de datos de 1500 bytes cada 10 milisegundos se produce sólo una velocidad de transferencia de 1,2 Mbps. El giro (como oposición al abandono de la CPU) proporciona sincronización de alta precisión pero no es práctico, a menos que la máquina pueda dedicarse a transmisor de red. Algunas realizaciones de la materia objeto presente proporcionan la transferencia de datos en los sistemas básicos, multitarea y no tienen el lujo de monopolizar la CPU.

En segundo lugar, el aumento de carga del sistema, en términos de CPU y de utilización de disco, puede afectar negativamente a la precisión de la velocidad de inyección, haciendo que se queda atrás.

El procedimiento utilizado por algunas realizaciones de la materia objeto presente proporcionan velocidades de inyección de alta precisión. Estas velocidades de inyección son compatibles con la CPU y no se ven afectadas por las variaciones en la carga del sistema, siempre y cuando, haya suficiente potencia de procesamiento disponible.

Las velocidades de inyección son compatibles con la CPU porque los paquetes se agrupan en lotes. El tamaño del lote se calcula de tal manera que el retardo ("IPD") entre paquetes es suficientemente grande para permitir que el emisor abandone la CPU y se recupere del retardo de conmutación del procedimiento resultante sin comprometer la velocidad de inyección.

Las velocidades de inyección no se ven afectadas por variaciones en la carga del sistema porque tales realizaciones miden el tiempo para procesar la transmisión de un paquete, o un lote, y compensar el retraso causado por este tiempo de procesamiento de más y el tiempo gastado en abandonar la conmutación del procedimiento de la CPU. El retardo entre paquetes de retardo presentes se compensa mediante el retraso medido, manteniendo así constante la velocidad de inyección en presencia de una carga del sistema variable.

El siguiente pseudo código es un ejemplo del algoritmo usado para inyectar paquetes en una red para lograr velocidades de transmisión de red de alta precisión. La restricción del retardo ("IPD") entre paquetes mínima de 5000 microsegundos (5 milisegundos) en el cálculo del tamaño del lote y la IPD se elige de manera que puede recuperarse un retardo causado por el cambio del procedimiento (10-20 milisegundos) a partir de los próximos 3 a 4 lotes.

El cálculo del retardo (IPD) entre paquetes y el tamaño del lote para una velocidad (Ri) de inyección dada:

IPD = block_size * 8 / rate [microseconds]

if IPD < 5000 microseconds

batch_size = 5000 / IPD

IPD = block_size * 8 * batch_size / rate

[microseconds]

else

batch_size = 1

El bucle de emisor:

lagbehind = 0

sleeptime = 0

Repeat until transfer finishes

/* Sleep routine */

sleep_spin = sleep_time % 1000 microseconds

sleep_yield = sleep_time - sleep_spin

sleep (sleep_yield microseconds)

/* This may take longer */

if time left

spin remainder of time /*Small, for

precision*/

/* Actual network transmission */

send batch of batch_size blocks

delay = current time in microseconds

last_sent

last_sent = current time in microseconds

/* Calculate sleep time and lag behind */

if IPD > delay

sleeptime = IPD - delay

if lagbehind > sleeptime

lagbehind = lagbehind

sleeptime

sleeptime = 0

else sleeptime = sleeptime lagbehind lagbehind = 0

else

sleeptime = 0

lagbehind = lagbehind + (delay - IPD)

if lagbehind > 100*IPD

lagbehind = 100*IPD

Algunas realizaciones también proporcionan procedimientos para mantener una alta eficiencia de transmisión de datos independiente del retardo de la ruta y de la pérdida de paquetes para altas velocidades de inyección.

Para evitar el cuello de botella de la velocidad de transmisión de un algoritmo de fiabilidad de acuse de recibo positivo, algunos procedimientos de acuerdo con la materia objeto presente utilizan un canal de transmisión no fiable, tal como el protocolo de datagramas de usuario ("UDP"), que no proporciona ninguna regulación de la velocidad de inyección o de la recuperación de los datos perdidos. Estos procedimientos consiguen fiabilidad implementando su propio algoritmo para la retransmisión de datos perdidos. El algoritmo de retransmisión determina con precisión cuándo un bloque de datos está realmente "perdido", entre una fuente original y un destino final, en oposición al retardado o reordenado, y de ese modo logra la estabilidad, una alta eficiencia independiente de la latencia de la ruta de extremo a extremo y la pérdida de paquetes, para altas velocidades de inyección. El algoritmo de retransmisión permite una combinación de alta velocidad de inyección y del rendimiento útil, invariante con un alto tiempo de ida y vuelta, tal como las redes intercontinentales de larga distancia, la pérdida de paquetes de alta aleatoriedad, tal como en algunos medios inalámbricos, y la latencia variable y las velocidades de pérdida de paquetes, tales como enlaces de Internet públicos congestionados con una carga pesada.

Algunas realizaciones usan como algoritmo de retransmisión los "acuses de recibo negativos". Los acuses de recibo negativos son cuando el receptor notifica al emisor sólo los bloques perdidos y el emisor retransmite en consecuencia.

Algunas realizaciones de la materia objeto presente muestrean continuamente el tiempo de ida y vuelta de la ruta y usan una función estimadora predictiva para predecir de manera precisa el tiempo de ida y vuelta y determinan cuando un bloque perdido se ha perdido verdaderamente y debe ser retransmitido. La solicitud de retransmisión no puede ser ni demasiado pronto, para mantener la estabilidad, ni demasiado tarde, lo que reduce la eficiencia. La velocidad de datos recibidos útil es constante e igual a la velocidad de inyección menos la velocidad de pérdida de paquetes de la ruta, para altas velocidades de inyección. Por lo tanto, la alta eficiencia de transmisión y la alta utilización de ancho de banda se realizan incluso a altas velocidades a través de enlaces que tienen pérdida alta y latencia variable.

El problema de un algoritmo de solicitud de retransmisión óptimo puede modelarse. Por ejemplo, dada una velocidad Ri (t) de inyección de ruta, para una transmisión eficiente cercana al 100%, la velocidad Ru (t) de datos útiles debería ser igual a Ri (t) menos la velocidad P (t) de pérdida del paquete por Ri (t):

Para una utilización cercana al 100% de una red rápida arbitraria, esta debe mantenerse para Ri que van desde unos pocos kilobits por segundo a una velocidad alta arbitrariamente (+ 1 gigabit por segundo).

Para lograr este modelo sustancialmente óptimo, la solicitud de retransmisión de un bloque perdido debería esperar sólo el tiempo suficiente para recibirse un bloque sobre la marcha, potencialmente retardado o reordenado, y no más tiempo que el tiempo necesario para enviar una solicitud de retransmisión al emisor y recibir una respuesta dada de la velocidad Ri de inyección objetivo del emisor.

Mientras que el tiempo exacto a esperar no puede determinarse a priori, puede estimarse a un alto grado de precisión midiendo continuamente el tiempo de ida y vuelta de la ruta y usando una clase de ecuaciones de estimación de predicción conocidas como error de predicción recursivo o funciones de gradiente estocásticas para predecir el futuro tiempo de ida y vuelta de la ruta. Algunas realizaciones de la materia objeto presente incluyen la aplicación de este sistema de transmisión de datos basado en bloques para estimar con precisión el tiempo de ida y vuelta de la ruta y para calcular el tiempo de espera para solicitar una retransmisión. Estas realizaciones logran a su vez una alta eficiencia de transmisión.

En algunas realizaciones, la planificación de la retransmisión incluye una predicción precisa del tiempo de ida y vuelta de la ruta, un muestreo exacto del tiempo de ida y vuelta actual y un planificador de retransmisión de rendimiento alto en base al tiempo de ida y vuelta de la ruta previsto.

Para un tiempo (RTO) de retransmisión preciso, es esencial predecir con precisión la evolución del tiempo de ida y vuelta de la ruta a través de la escala de tiempo usada para el envío de las solicitudes de retransmisión y la recepción de los bloques de datos retransmitidos. Diversas realizaciones de la materia objeto de la invención presente calculan la predicción RTT muestreando el tiempo de ida y vuelta para la ruta de transferencia total, que incluye el tiempo de procesamiento del emisor, por ejemplo, el tiempo para buscar la estructura de los datos de retransmisión y releer un bloque desde el disco, además del tiempo para que un bloque de datos viaje en la red. En tales realizaciones, el algoritmo de procesamiento del lado del emisor es constante con el número de solicitudes de retransmisión, y por lo tanto puede factorizarse de forma segura en la predicción del tiempo de ida y vuelta.

Además, algunas de estas realizaciones calculan una estimación de la media del tiempo de ida y vuelta de la ruta media ("RTT uniforme" o "SRTT") desde el tiempo de ida y vuelta de muestreo y obtienen una variación del retardo ("variación de RTT") de la diferencia entre la muestra del RTT y el RTT uniforme. A continuación, el retardo de red predicho se calcula en base a la RTT uniforme y la variación de RTT.

Tras la recepción y el cálculo de una nueva muestra de RTT (RTTi), el valor del RTT uniforme ("SRTT") se calcula como:

y es un factor de ganancia que determina cuánto pesa la muestra de RTT actual en la nueva estimación del RTT uniforme. La diferencia entre el RTTI y el SRTTi representa el error en la predicción previa, que consiste en un error aleatorio en la medición y un error debido a una mala estimación anterior. Con el tiempo los componentes de error aleatorios se cancelan y el error debido a las malas predicciones empuja la estimación al promedio "real". Un factor de ganancia pequeño asegura así que una SRTT específica no se ve afectada demasiado por el error aleatorio. Una realización usa un factor de ganancia, y, de 1/8.

Para tener en cuenta la oscilación de la estimación del SRTT alrededor de la media verdadera, la varianza del RTT (VRTT) se calcula como:

En la que 7 es el factor de atenuación. Una realización usa un factor de atenuación, 7, de 1/4.

El RTT predicho (= RTO) se calcula como:

El valor del RTO también está limitado al intervalo de los límites de ida y vuelta prácticos de las redes típicas en una implementación.

5 Otro factor en la predicción del retardo de red es la frecuencia de muestreo del RTT. Para el intervalo de la velocidad de transferencia usada por algunas realizaciones (20 Kbps - 1 Gbps), el período de muestreo es de 10 milisegundos.

La precisión del RTT predicho (=RTO) depende de la exactitud de la RTT muestreada. Un receptor genera un "ciclo de reloj" preciso, usando el mejor mecanismo de reloj ofrecido por el sistema operativo. El marcador se genera inmediatamente antes de enviar una solicitud de retransmisión y está incrustado en la PDU de la solicitud de retransmisión. La solicitud viaja a través de la red al emisor. Cuando el emisor está listo para retransmitir el bloque correspondiente, se incrusta el ciclo de reloj en la PDU de datos, y lo envía al receptor. Tras la recepción de una PDU de datos que contiene un ciclo de reloj, el receptor determina el RTT de la ruta restando el ciclo de reloj recibido desde el reloj actual. Este procedimiento es exacto porque usa los mecanismos de reloj de la más alta precisión disponibles desde el sistema operativo, e incluye el tiempo de procesamiento en el emisor.

15 El receptor de unas solicitudes de retransmisión de acuse de recibo ("NACK") negativo debe manejar las solicitudes de retransmisión de bloque. A continuación se describe una realización que maneja las solicitudes de retransmisión de bloques, la detección de los bloques perdidos, la retransmisión de la solicitud de los bloques perdidos y la cancelación de las solicitudes de retransmisión pendientes cuando se reciben los bloques solicitados.

Algunas realizaciones de acuerdo con la materia objeto presente numeran cada bloque en la fuente de datos de forma secuencial desde 1 a N, donde N = tamaño de archivo/tamaño de bloque [+ 1 si el tamaño del archivo de tamaño de bloque de módulo > 0]. Otras realizaciones usan diversos medios para identificar los bloques individuales de una manera secuencial.

Un emisor añadirá el número de secuencia de bloque a la carga útil en cada unidad de datos de protocolo ("PDU"). El receptor detecta un bloque perdido cuando se recibe un bloque con un número de secuencia mayor que el

25 siguiente número de secuencia esperado. Debido a que el bloque puede recibirse fuera de orden, el receptor no solicita inmediatamente una retransmisión del bloque perdido, pero planifica la primera solicitud de retransmisión después de una RTO. Esto permite al bloque reordenado sobre la marcha que pueda recibirse sin crear transmisiones duplicadas solicitando prematuramente una retransmisión.

El receptor almacena todas las solicitudes pendientes de retransmisión, junto con el tiempo absoluto preciso de cuando se vencen. El tiempo se calcula redondeando el valor del tiempo de vencimiento mediante las mediciones de RTT de precisión, para garantizar que el tiempo de vencimiento calculado no es menor que el valor teóricamente correcto debido al error de medición.

Una vez que se envía una solicitud de retransmisión del receptor al emisor, la solicitud posterior de retransmisión se

35 planifica en el tiempo de vencimiento calculado con el mismo procedimiento. Por consiguiente, una vez que se detecta un bloque perdido, hay siempre una solicitud pendiente para su retransmisión hasta que el bloque se reciba y se cancele la retransmisión pendiente actualmente.

Una ruta precisa que redondea la predicción del tiempo requiere que la sobrecarga en el envío y el procesamiento de las solicitudes de retransmisión sea constante con el número de retransmisiones, y no agrave la pérdida de datos. Para transferencias de alta velocidad a través de condiciones de red difíciles, el número de retransmisiones puede ser muy grande. Diversas realizaciones incluyen un número de elementos que aseguran un tiempo de procesamiento casi constante en el emisor y en el receptor y que maximizan la probabilidad de entrega correcta de las solicitudes de retransmisión, incluso para un gran número de retransmisiones.

En tales realizaciones, cuando se recibe un bloque retransmitido, la solicitud pendiente para su retransmisión se

45 recupera del planificador y se cancela. Cuando la pérdida es alta (el número de retransmisiones es grande), esto puede ser una operación costosa si el procedimiento de recuperación es proporcional al número de retransmisiones. El procedimiento de recuperación usado por estas realizaciones garantiza un tiempo de acceso constante cercano al rendimiento útil óptimo en el caso de pérdida alta. En el receptor, cuando un bloque se detecta primero como perdido, la solicitud de su retransmisión se almacena en una matriz lineal. El índice en el que se almacena se envía en la solicitud de la retransmisión. En el lado del emisor, este índice se almacena junto con las solicitudes de las retransmisiones. Cuando el emisor retransmite un bloque, el índice se añade a la carga del bloque, permitiendo que el receptor busque la retransmisión pendiente en un tiempo constante, independiente del número total de bloques.

Para evitar la acumulación de retransmisiones pendientes, el emisor de la presente realización siempre retransmite cualquier bloque perdido antes de enviar nuevos bloques. De otra manera el receptor acumularía más pérdidas y planificaría más solicitudes de retransmisiones, de este modo él mismo se conduciría al colapso de congestión y degradaría el rendimiento de la transferencia de archivos. Para retransmitir los bloques, el emisor debe releer los

5 datos de bloque del archivo de origen. Esta operación de búsqueda vuelta y lectura puede ser costosa para las transferencias de alta velocidad y agotadora cuando la pérdida de paquetes es alta y los tamaños de los archivos son grandes. El receptor regula las solicitudes de retransmisiones para que coincida la velocidad a la que el emisor puede reenviar los bloques perdidos de manera que el almacenamiento de las retransmisiones pendientes en el lado del emisor es casi constante en tamaño (no crece con la pérdida de red).

10 A través de los medios semidúplex, así como a través de dispositivos de red que inducen a un comportamiento semidúplex debido a los recursos de encolamiento demasiado pequeños, los grandes paquetes IP en la ruta de retorno, del receptor al emisor, pueden no ser capaces de llegar al emisor. Esto hace que el emisor continúe enviando nuevos bloques, lo que acelera la velocidad a la que la pérdida se acumula en el receptor e inmediatamente se degrada el rendimiento de la transferencia de archivos.

15 El receptor de la presente realización toma las siguientes contramedidas:

(a) Dado el número de solicitudes de retransmisiones que el receptor tiene que enviar por unidad de tiempo, y que el emisor no puede retransmitir más rápido que la velocidad de envío, el receptor envía el menor número de bloques para retransmitirse en una PDU de solicitud de retransmisión, como se determina mediante la velocidad objetivo del emisor y la velocidad de solicitud de retransmisión.

El intervalo de la solicitud es una constante igual a la resolución del temporizador de retransmisión (10 ms en la implementación actual), EXCEPTO en el caso especial siguiente:

Si la velocidad objetivo del emisor es pequeña de manera que la velocidad de solicitud mínima produciría menos de 1 rex por solicitud, el intervalo se alarga al intervalo mínimo requerido para 1 rex por solicitud.

(b) El tamaño máximo de una solicitud de retransmisión se puede configurar mediante la aplicación y por defecto se ajusta para que sea menor que el mínimo MTU típico de red (1492 bytes).

En realizaciones con velocidades de transferencia de archivos cercanas al rendimiento de lectura/escritura del disco,

30 el rendimiento I/O de disco puede llegar a ser el cuello de botella. El emisor en tales realizaciones alivia la búsqueda en disco mediante el reenvío siempre de los bloques más cercanos del principio del primer archivo. Esto permite que el emisor lea secuencialmente los bloques a retransmitir, y que el receptor escriba los bloques recibidos secuencialmente. En el lado del emisor, las retransmisiones vencidas se almacenan en una estructura de datos ordenados: un árbol negro rojo modificado para almacenar los números de secuencia de las retransmisiones

35 vencidas ordenadas por número. El árbol negro rojo es una clásica estructura de datos de árbol binario, bien descrita en la literatura informática, y no se describirá en el presente documento. Los números de secuencia de bloque son las claves de nodo en el árbol.

En base al hecho de que sólo el número de bloque más pequeño (el mínimo) necesita recuperarse, el árbol negro rojo se ha modificado para proporcionar una recuperación casi constante de tiempo. El tiempo de inserción es el de

40 un árbol negro rojo normal.

El árbol negro rojo modificado ofrece las primitivas siguientes:

insert_block (block_seq_number)

retrieve_minimum_block ()

El árbol negro rojo mantiene un seguimiento del nodo que tiene el número de secuencia mínima, denominado nodo

45 mínimo actual. Tras la inserción, es trivial mantener un seguimiento del nodo mínimo: conocer el mínimo actual, si el bloque a insertar tiene un número de secuencia más bajo que el del nodo mínimo actual, se convierte en el mínimo. Si no, el nodo mínimo actual se queda inalterado.

Tras la recuperación, el nodo mínimo se elimina del árbol y se devuelve a la aplicación, y se encuentra y se almacena un nuevo mínimo. En apoyo del algoritmo usado para encontrar el nuevo nodo mínimo, las siguientes afirmaciones son verdaderas:

el nodo mínimo actual no tiene descendiente izquierdo (o el descendiente izquierdo tendrá una clave menor que la del nodo mínimo) el nodo mínimo actual es el descendiente izquierdo de su padre (o su padre tendrá una clave menor que la del nodo mínimo) el subárbol enraizado en el descendiente derecho del nodo mínimo actual tiene todas las claves menores que las claves del padre del nodo mínimo actual, y el resto de las claves del árbol.

Para encontrar el "siguiente" nodo mínimo, antes de que el nodo mínimo actual se elimine del árbol, el árbol negro rojo modificado usa el siguiente algoritmo:

If the current minimum node has no right descendent, the next minimum node is its parent.

Else, the next minimum node belongs to the subtree rooted at the current minimum node’s right descendent.

The next minimum node is retrieved by inorder traversal of the mentioned subtree.

Se describe a continuación la modificación al algoritmo del árbol negro rojo ordinario usada en las diversas realizaciones.

minimum_seq_number = -1;

insert_block (block_seq_number) regular RBT insert block_seq_number if minimum_seq_number == -1

minimum_seq_number = block_seq_number else if block_seq_number < minimum_seq_number minimum_seq_number = block_seq_number retrieve_minimum_block () store minimum node to be returned to caller

application /* Find new minimum node */ if current minimum has no right descendent

new minimum = current minimum node’s parent else find the new minimum by inorder traversal of the subtree starting at the current minimum node’s right remove minimum node from tree

Algunas realizaciones de la materia objeto presente requieren acceso de disco aleatorio y volver a buscar frecuentemente y avanzar en un archivo si hay retransmisiones requeridas. Mientras que algunos sistemas operativos ofrecen un acceso aleatorio del sistema de archivos de alto rendimiento, otros sistemas operativos no manejan bien el acceso aleatorio y reducen la velocidad de lectura/escritura del disco mediante un factor sustancial. El lado del receptor en las presentes realizaciones es el más afectado porque las operaciones de escritura en disco son más costosas.

En algunas realizaciones, el receptor implementa un mecanismo de memoria caché de escritura de disco para minimizar el acceso aleatorio al disco. El tamaño de la memoria caché es proporcional a la velocidad de destino de transferencia del archivo, usando el siguiente cálculo:

file_cache_size = ( (Transfer_rate [bps] / 1800 * block_size) / write_size) * write_size

El tamaño de la memoria caché del archivo es proporcional a la memoria intermedia del tamaño de escritura del disco, "write_size". La memoria intermedia del tamaño de escritura del disco es un múltiplo del tamaño de un grupo de discos, el cual, dependiendo del sistema de archivos, puede ser de 512 bytes, 1024 bytes, 4096 bytes, 8192 bytes, o incluso superior. Algunas realizaciones usan un tamaño de escritura de disco de 64 Kbyte.

La memoria caché de archivo recibe bloques de datos del receptor, memoriza los bloques, y decide cuándo y qué datos escribir en el disco. Al final de la transferencia de archivos, la memoria caché descarga su contenido en el disco. La memoria caché de archivos resuelve el siguiente problema: Cuando la pérdida de datos es alta, la memoria caché debería retrasar la escritura en disco actual tanto como sea posible para proporcionar al receptor la máxima

5 oportunidad de recibir los bloques retransmitidos y completar los huecos en la memoria caché creados por la pérdida de los paquetes. Idealmente, la escritura de disco se produce cuando se han recibido todos los bloques constituyentes en la memoria intermedia de escritura. Cuando la pérdida de datos es baja, la memoria caché de archivos escribe en el disco tan pronto como es posible, sin almacenar en la memoria caché una gran cantidad de datos, para mejorar el tiempo de descarga al final de la transferencia de archivos.

Algunas realizaciones del procedimiento para lograr un alto rendimiento de almacenamiento en la memoria caché del disco incluyen el uso de un indicador de marca de agua superior en la escritura en disco. Cuando los datos escritos en la memoria caché exceden la marca de agua superior, la memoria caché escribe en el disco desde el principio de la memoria caché. Las políticas de almacenamiento en memoria caché de alta pérdida frente a bajas pérdidas descritas anteriormente se consiguen calculando un promedio de funcionamiento del tamaño de la tabla de

15 retransmisión del receptor.

La media de funcionamiento se calcula de tal manera que su valor controla el número de retransmisiones en la tabla del receptor cuando aumentan y se ajusta lentamente cuando decrecen. De esta manera, el receptor sigue estrechamente las tendencias alcistas y se queda atrás con las tendencias bajistas. Tendencia alcista:

Tendencia bajista:

Cuando deltai +1 = retransmission_samplei +1 - retransmission_avgi

La marca de agua superior se calcula como una función de la etapa logarítmica de la media de funcionamiento de la retransmisión. high_ watermark =

25 cache_size * 0,1, if retransmission_avg in [0, 100) cache_size * 0,2, if retransmission_avg in [100, 200) cache_size * 0,3, if retransmission_avg in [200, 400) cache_size * 0,4, if retransmission_avg in [400, 900) cache_size * 0,5, if retransmission_avg in [900, 1800) cache_size * 0,6, if retransmission_avg in [1800, 4000) cache_size * 0,7, if retransmission_avg in [4000, 8000) cache_size * 0,8, if retransmission_avg in [8000, 18000) cache_size * 0,9, if retransmission_avg in [18000, infinity)

La marca de agua superior se reajusta después de cada escritura en disco.

35 Definiciones. En cualquier punto en el tiempo una ruta de red puede tener "ancho de banda disponible" o "ancho de banda no disponible". Una ruta tiene ancho de banda disponible cuando la suma de la anchura de banda usada por todos los flujos que atraviesan actualmente la ruta es menor que el ancho de banda de cuello de botella de la ruta, y algunos anchos de banda no usados. Por el contrario, una ruta no tiene ancho de banda disponible cuando la suma del ancho de banda de la red demandado por todos los flujos es mayor que el ancho de banda del cuello de botella de la ruta. En este caso, la demanda de ancho de banda excede la oferta y el ancho de banda debe compartirse entre los diversos flujos en el enlace. El "ancho de banda de equidad" se refiere al ancho de banda relativo consumido por los flujos individuales.

Diversas realizaciones de la materia objeto presente, proporcionan un rendimiento de datos estable, eficiente, y ancho de banda no usado utilizado totalmente en los enlaces compartidos en la presencia de otros flujos de datos IP

45 cuando hay ancho de banda disponible. En las redes que no tienen ancho de banda disponible, estas realizaciones adaptan automáticamente su velocidad de transmisión para compartir el ancho de banda equitativo con TCP.

Estas realizaciones incluyen un modo de control de velocidad adaptativo que usa el retardo de encolamiento de red como una señal de congestión de red (o por el contrario, el ancho de banda disponible). En las redes con ancho de banda disponible, como se ha señalado mediante el retardo de encolamiento bajo, estas realizaciones determinan la velocidad de inyección de datos como una función del retardo de encolamiento medido. La técnica anterior ha mostrado que el retardo de encolamiento proporciona una señal de congestión precisa para adaptar el rendimiento de transferencia de TCP al ancho de banda disponible que varía dinámicamente, y han aplicado el control de velocidad en base a una ecuación como una función de retardo de encolamiento para mantener el alto rendimiento de TCP estable a la capacidad del ancho de banda en determinadas redes de alta velocidad. El alto rendimiento

55 estable de la técnica anterior sólo se aplica cuando hay una pérdida de paquetes insignificante (aun reduciendo el

rendimiento en eventos de pérdida de paquetes), y sólo en las redes con ancho de banda alto (no utilizan el ancho de banda en redes de velocidad baja), y a expensas de la equidad del ancho de banda para otros flujos TCP. En las redes con ancho de banda disponible, las realizaciones propuestas no reducen el rendimiento en los eventos de pérdida aleatorios (solicitando la adaptación en base al retardo a un transporte UDP fiable, tolerante a la de pérdida 5 de paquetes), y por lo tanto mantener un alto rendimiento incluso en medios con altas velocidades de pérdida de paquetes, tal como una red inalámbrica. También, las realizaciones propuestas usan parámetros de escala modificados para hacer que los sistemas se acerquen a la utilización total del ancho de banda en todas las redes prácticas (de unos pocos kilobits por segundo a gigabits por segundo), no sólo las redes de alta velocidad y la pérdida de paquetes despreciable). Además, las realizaciones propuestas usan, automáticamente, una velocidad de

10 TCP compatible en redes con ancho de banda no disponible.

En las redes con ancho de banda no disponible actualmente, las realizaciones propuestas son capaces de proporcionar un rendimiento de ancho de banda equitativo en relación a otros flujos TCP coincidiendo la velocidad de inyección calculada para un número proporcional de flujos TCP que funcionan bajo las mismas condiciones de red. La técnica anterior ha mostrado que el control de la velocidad en base a una ecuación puede usarse para que

15 coincida una velocidad de inyección del transporte UDP con una velocidad equivalente TCP bajo condiciones de funcionamiento similares y lograr la equidad del ancho de banda TCP, pero a expensas de la estabilidad, el rendimiento y la utilización del ancho de banda. El sistema propuesto determina con precisión cuando no hay ancho de banda disponible y logra la equidad TCP, manteniendo al mismo tiempo el rendimiento estable, el rendimiento alto y la total utilización del ancho de banda cuando hay ancho de banda disponible.

20 Se ha mostrado en la técnica anterior que la velocidad x (t) ventana/envío de congestión de todas las implementaciones TCP se desarrolla de acuerdo con la ecuación:

25 Ki (xi, Ti) es una función de ganancia, que determina las propiedades dinámicas tales como la estabilidad y capacidad de respuesta de la velocidad, pero no afecta a las propiedades de equilibrio.

ui (xi, Ti) es una función de utilidad marginal que establece las propiedades de equilibrio como la asignación de la velocidad de equilibrio y la equidad.

pi (t) es la medida de la congestión, o bien la probabilidad de pérdida o el retardo de encolamiento.

30 Ti (t) es el tiempo de ida y vuelta.

Para adaptar la velocidad de envío de las redes que tienen ancho de banda disponible, algunas realizaciones aplican un enfoque en base a un retardo para TCP como se muestra en la técnica anterior para un transporte UDP fiable. Este enfoque en base a un retardo tiene una función de utilidad marginal:

35 en la que ai (t) es un parámetro de protocolo y xi (t) es la velocidad actual y una función de ganancia sugerida de:

ki = y * ai (t) y una medida de la congestión, pi, la diferencia entre el tiempo brtti base de ida y vuelta y el tiempo srtti actual de ida y vuelta.

En algunas realizaciones, brtti es el tiempo más pequeño de ida y vuelta medido durante un transferencia. Para srtti,

40 estas realizaciones miden el retardo de red de ida y vuelta, no el retardo de la ruta de ida y vuelta, como se explica a continuación, y calculan un tiempo de ida y vuelta uniforme usando la misma función estimadora predictiva recursiva usada para calcular el RTO de las retransmisiones.

Para lograr una velocidad de equilibrio estable para un transporte UDP fiable, como se muestra en la técnica anterior para TCP, este enfoque se esfuerza para converger el cambio en la velocidad de envío a lo largo del tiempo (0).

45 Esto se logra ajustando el tamaño de la velocidad y la dirección de manera que la relación de la medida de la congestión y la función de utilidad (pi/ui) converge a 1, haciendo que x (t+1) - x (t) en la ecuación 1 converja a 0.

Expresando la ecuación 1 en términos de ui y ki y con u con y = ½ y simplificando términos, la ecuación general de actualización de la velocidad es:

En la que:

a = 2 * 10-5 * TargetRate * block_size [bits]

BaseAvgi+1 = 1, si brtti +1 < 5 AND srtti+1 <

20 = brtt i+1 / srtti 1, de otra manera

BaseAvg se fuerza a 1 cuando brtt y srtt son pequeñas, para manejar los casos en los que brtt es tan pequeño que es del mismo orden con la precisión de la medición del RTT.

En algunas realizaciones, a es el factor de adaptación de una función lineal de la velocidad objetivo para la convergencia a través de un amplio intervalo de anchos de banda que pueden sintonizarse con agresividad. Como se muestra en la técnica anterior, el factor a es una expresión del número de paquetes que deben memorizarse en las colas de la ruta de transferencia para el envío fuente a una velocidad xi para alcanzar el equilibrio, y representa la "agresividad" del algoritmo de control de la velocidad. Los flujos con el mismo valor de a compartirán el ancho de banda equitativamente, mientras que los flujos con un valor más alto de a tomarán más ancho de banda de manera proporcional.

En estas realizaciones, a diferencia de la técnica anterior, a se ajusta como una función lineal de la velocidad objetivo para permitir la convergencia a una velocidad objetivo estable para todos los anchos de banda de red prácticos (que van desde los 100 Kbps a 1 Gbps).

Justo cuando la estimación precisa del tiempo de ida y vuelta de la ruta es útil para determinar un tiempo de espera de retransmisión eficiente (RTO), la medición precisa del tiempo de ida y vuelta es útil para calcular con precisión el retardo de encolamiento. El retardo de encolamiento se aplica sólo a la parte de red de la ruta de transferencia, por lo que diversas realizaciones miden un segundo valor del tiempo de ida y vuelta, el RTT de red, que no incluye el tiempo de procesamiento en los ordenadores finales. Usando la misma función estimadora recursiva que se usa para calcular el RTO para la retransmisión, estas realizaciones calculan una media ponderada uniforme del RTT de red y usan este valor para calcular una proporción del RTT de red actual para el RTT base usado en la función de actualización de la velocidad (ecuación 2).

Para medir el retardo de red algunas realizaciones utilizan un procedimiento similar que el de la medición del tiempo de la ruta de ida y vuelta de la ruta de la RTO. En estas realizaciones, el receptor genera un "ciclo de reloj" preciso, usando el mejor mecanismo de reloj ofrecido por cada sistema operativo. El receptor genera este marcador inmediatamente antes de enviar una solicitud de retransmisión y se incrusta en la solicitud de retransmisión. Si no hay solicitudes de retransmisión que necesiten enviarse (por ejemplo, cuando no hay pérdida en el canal de ida), el receptor genera una retransmisión "vacía" que se envía con una frecuencia mínima, tal como, una vez por cada 10 ms. El ciclo de reloj se incrusta en la PDU de la solicitud de retransmisión y viaja a través de la red desde el receptor al emisor. El emisor hace un cálculo de tiempo preciso del tiempo usado para procesar la solicitud de retransmisión y añade este tiempo al ciclo de reloj recibido en la PDU de la solicitud de retransmisión, restando de manera eficaz el tiempo de procesamiento. A continuación, incrusta el ciclo de reloj en una PDU de datos y los envía al receptor. Tras la recepción de una PDU de datos que contiene un ciclo de reloj, el receptor determina el retardo de red restando el ciclo de reloj recibido desde el reloj actual. Este procedimiento es exacto porque utiliza los más altos mecanismos de precisión de reloj disponibles en el sistema operativo, y representa el tiempo en que el emisor procesa la solicitud.

Algunas realizaciones incluyen también la capacidad de compartir el ancho de banda equitativamente, o en una agresividad proporcional, con cualquier implementación de TCP en presencia de congestión de red, en redes con ancho de banda no disponible. Estas realizaciones comparten el ancho de banda igualmente o en una proporción configurable con cualquier implementación compatible TCP (es decir, cualquier protocolo que se desarrolle de acuerdo con la ecuación 1 previamente introducida) calculando la velocidad de estado estacionario de un flujo TCP bajo las condiciones de red medidas (por ejemplo, como una función del retardo de red y o la pérdida de paquetes). Estas realizaciones usan el retardo de encolamiento como una señal de que el ancho de banda no está disponible y no sacrifican la utilización del ancho de banda total en los enlaces que tienen ancho de banda disponible, al tiempo que garantizan la equidad configurable en los enlaces que actualmente no tienen ancho de banda disponible.

Como se muestra en la técnica anterior, que usa el hecho de que la velocidad de envío de todas las implementaciones TCP se desarrollan de acuerdo con la ecuación (1) (como se describió anteriormente):

Puede encontrarse una expresión de la velocidad de equilibrio para cualquier pérdida o retardo en base a la implementación de TCP estableciendo pi (t)/ui (t) = 1.

La realización propuesta usa un algoritmo de congestión en base al retardo, como se muestra en la ecuación 3.

Como se muestra en la técnica anterior, la velocidad de equilibrio para la implementación TCP más comúnmente desplegada (Reno TCP) se expresa en la ecuación 4:

Donde a ri es un parámetro del protocolo Reno TCP que depende de una constante y del tamaño de la MTU.

En algunas de las realizaciones propuestas las dos velocidades de equilibrio se igualan para obtener el parámetro de adaptación a en términos de retardo de encolamiento y la función de velocidad de equilibrio para el TCP específico en la ecuación 5.

La a obtenida se usa a continuación para calcular una velocidad de ancho de banda equitativo (usando la ecuación 3), lo que quiere decir igual a la velocidad de TCP para los parámetros de red medidos actualmente (por ejemplo, el tiempo de ida y vuelta y/o la pérdida de paquetes). Ya se ha descrito un procedimiento para medir con precisión el tiempo de ida y vuelta. La velocidad de pérdida de paquetes puede medirse de numerosas maneras, tales como

15 usando un promedio móvil ponderado estimado.

Obsérvese que el mismo procedimiento puede aplicarse para que coincida la velocidad de equilibrio de TCP con las funciones de respuesta diferentes tales como estos TCP se despliegan, por ejemplo, el TCP de alta velocidad o el TCP escalable:

TCP de alta velocidad: Xi = a hi / Ti * pi^0,84 20 TCP escalable: Xi = a si / Ti * pi

La funcionalidad de control de la velocidad de acuerdo con algunas realizaciones de la materia objeto presente incluye dos grandes componentes. Encontrar el factor a para producir una velocidad igual a la velocidad de TCP en términos de retardo de encolamiento, pérdida de paquetes y tiempo de ida y vuelta para la equidad del ancho de banda cuando hay "congestión" (ancho de banda no disponible); y determinar con precisión cuando hay congestión,

25 usando el retardo de encolamiento, para señalar la entrada en el estado compatible TCP. Estas realizaciones determinan las condiciones de congestión bajo las que usar una velocidad compatible TCP usando una máquina de dos estados que funciona en un "modo-x" adaptativo de acuerdo con la materia objeto (para la utilización del ancho de banda no usado cuando el ancho de banda está disponible) y un modo TCP (para la equidad cuando no hay ancho de banda disponible).

30 Estas realizaciones entran en el modo compatible TCP sólo cuando hay congestión, y no dejan el modo compatible TCP hasta que se conoce que la congestión ha terminado. Estas realizaciones usan un modelo de histéresis para determinar cuando cambian los modos. Si el tiempo de ida y vuelta se incrementa y el retardo de encolamiento es suficientemente mayor que la rtt base para que sea significativo, se introduce el modo TCP. Una vez en el modo TCP, tal sistema permanece en modo de TCP hasta que el RTT decrece y el retardo de encolamiento está

35 suficientemente cerca de la base rtt para indicar que el encolamiento ha bajado realmente.

Los parámetros específicos usados en algunas realizaciones fueron determinados experimentalmente:

Sea drtt = srtt - brtt - 10.

El estado inicial es el modo-x En modo-x: Si srtt aumentó desde la última muestra y drtt > 0,2 * brtt, cambia al modo TCP, si no

40 permanece en el modo-x En el modo TCP: Si srtt disminuyó desde la última muestra y drtt < 0,5 * brtt, cambia al modo-x, si no permanece en el modo TCP

Este procedimiento proporciona muy buenos resultados para escenarios de flujo concurrente en diferentes condiciones de red.

45 Los parámetros del modelo de control de la velocidad proporcionan "mandos de control" sintonizables a las solicitudes. Exponer a como un parámetro configurable permite el cambio de la velocidad objetivo o la agresividad, mientras que una transferencia está en funcionamiento.

La aplicación puede establecer su agresividad relativa a un número (y tipo) de flujos TCP, tal como una velocidad equivalente a un flujo TCP, u otros dos flujos TCP convencionales. También, la solicitud puede seleccionar un modo específico, tal como un modo de "goteo", en el que el flujo se retira por completo a un umbral mínimo que comparte con TCP pero se reforzará hasta tomar la totalidad del ancho de banda cuando se ejecuta solo.

Algunas realizaciones introducen una transferencia de goteo de alta eficiencia, permitiendo que una transferencia de datos use la totalidad del ancho de banda, siempre y cuando no haya otra actividad de red, y vuelve de nuevo a una velocidad muy baja cuando se detecta actividad de red. Ejecutando una transferencia en el modo de velocidad adaptativa y estableciendo el factor de agresividad muy bajo, el flujo usará la totalidad del ancho de banda disponible cuando se ejecute en el modo de no congestión y se volverá atrás por completo cuando se entre en el modo de congestión. En conjunto, la solicitud de transferencia puede establecer un umbral de velocidad mínimo para esta transferencia, para garantizar un tiempo de entrega. Un usuario de la solicitud de goteo puede cambiar el umbral mínimo sobre la marcha, negociando el ancho de banda de red para el momento de transferir.

Algunas realizaciones incluyen elementos de criptografía opcionales para cifrar y descifrar los bloques de datos sobre la marcha.

En el comienzo de una transferencia, un canal de TCP seguro se configura con el extremo remoto, usando un procedimiento establecido, tal como SSH o SSL/TLS. Un receptor en tal realización genera una clave de cifrado simétrico aleatoria dando un mensaje cifrado configurable por el usuario (algoritmo de cifrado) y lo intercambia con el emisor usando el canal seguro. En algunas realizaciones, los extremos, pueden decidir cambiar la clave de cifrado periódicamente e intercambiar nuevas claves a través del canal seguro. El emisor encripta cada bloque de datos para garantizar la confidencialidad de los datos y añade un código de autenticación de mensaje para garantizar la autenticidad de los datos. Este procedimiento se proporciona como una opción en diversas realizaciones, tal como una aplicación de transferencia de datos a nivel de aplicación. Este procedimiento proporciona a las aplicaciones un medio para transferir datos de forma segura a través de redes públicas, sin garantía, tales como Internet.

Algunas realizaciones también proporcionan la capacidad de controlar y monitorizar la transferencia de archivos. Estas realizaciones ofrecen una interfaz conector de TCP para la gestión, de tal manera que la aplicación de gestión puede ejecutarse en el mismo o en un ordenador diferente que el del extremo de la transferencia administrada. Esta interfaz permite que las operaciones de control y monitorización tales como la capacidad para iniciar y detener una transferencia, modificar la velocidad de transmisión sobre la marcha, pausar y reanudar la transmisión, y cambiar los parámetros de transmisión sobre la marcha, tales como activar o desactivar el modo de velocidad adaptativa, cambiar la agresividad. Las operaciones de control y monitorización también incluyen operaciones tales como la capacidad de leer estadísticas básicas de transferencia, leer estadísticas de transferencia necesarias para la descarga progresiva y leer estadísticas específicas FASP, tales como los parámetros de estructura de datos de retransmisión, las estadísticas de escritura en disco y los parámetros de la velocidad adaptativa. Esta interfaz es un mecanismo para integrar diferentes elementos de la realización del transporte en las aplicaciones. La interfaz también permite que las aplicaciones implementen políticas de transferencia tales como la priorización y la gestión de la utilización del ancho de banda.

Algunas realizaciones proporcionan un protocolo UDP fiable a nivel de aplicación para permitir que las aplicaciones cambien la velocidad de transferencia de una transferencia en curso. El gestor de transferencia, usando la interfaz de gestión, controla uno de los dos extremos implicados en una transferencia de datos. Tanto el emisor y el receptor, cuando se controlan por el mismo gestor de transferencia, tienen un subproceso de procesamiento dedicado que permite el intercambio de mensajes de monitorización y control con el gestor de transferencia independiente del subproceso(s) de procesamiento de datos. Cuando recibe órdenes de control, tales como cambios de velocidad sobre la marcha, el subproceso de procesamiento dedicado del emisor y del receptor almacena los nuevos valores y el subproceso de procesamiento de datos principal consulta y recoge periódicamente los nuevos valores.

Si el gestor controla el receptor, el gestor le pasa el umbral de velocidad mínima o máxima deseada. El receptor usa los nuevos valores en calcular la velocidad objetivo requerida para el modo de velocidad adaptativa, o para establecer la velocidad objetivo al umbral máximo si se ejecuta en modo de velocidad fija. El receptor envía la velocidad objetivo, calculada o establecida, al emisor en los mensajes de estadísticas periódicas y el emisor le obedece.

Si el gestor controla el emisor, el gestor le pasa el umbral de velocidad mínima o máxima deseada. Si se ejecuta en el modo de velocidad fija, el emisor usará la nueva velocidad como su velocidad objetivo fija, ignorando la velocidad objetivo solicitada por el receptor en los mensajes de estadísticas. Si se ejecuta en el modo de velocidad adaptativa, el emisor almacena las velocidades mínima y máxima establecidas por el gestor, y las compara con la velocidad objetivo solicitada por el receptor. Si la velocidad objetivo solicitada por el receptor es mayor que el umbral de velocidad máxima, el emisor establece su velocidad objetivo al umbral de la velocidad máxima. Si la velocidad objetivo solicitada por el receptor es menor que el umbral de la velocidad mínima, el emisor establece su velocidad objetivo al umbral mínimo. Si no, el emisor establece su velocidad objetivo a la velocidad objetivo solicitada por el receptor.

Dada la naturaleza predecible de las transferencias de datos de acuerdo con las diversas realizaciones de la materia objeto presente, el usuario puede elegir por establecer el tiempo de transferencia, en lugar de la velocidad de transferencia. Una realización de la aplicación puede permitir al usuario establecer la hora de transferencia o la hora estimada de llegada y calcular la velocidad objetivo necesaria para satisfacerla. El gestor de transferencia puede entonces establecer la velocidad objetivo sobre la marcha, como se describió anteriormente.

Pausar una transferencia en curso es un caso particular del establecimiento de la velocidad objetivo de destino sobre la marcha (estableciendo la velocidad a 0), pero requiere que tanto el emisor y el receptor detengan completamente el envío o el intento de recibir datos. Esta función es útil para la priorización del ancho de banda no planeado. Para hacer una pausa, el gestor de transferencia establece la velocidad objetivo, o el umbral de velocidad máxima, en el modo de velocidad adaptativa, a 0. El emisor aprende acerca del nuevo valor de la velocidad desde el gestor de transferencia o desde el receptor a través de los mensajes de estadísticas. Una vez que el emisor detecta este caso especial, el emisor deja de enviar datos y espera a que el gestor de transferencia establezca la velocidad objetivo a un valor mayor que 0. Si el receptor está controlado por el gestor de transferencia, el receptor aprende acerca del nuevo establecimiento a 0 de la velocidad directamente. Si el emisor está controlado por el gestor de transferencia, se envía un mensaje de control al receptor para informarle acerca de la entrada de un estado "pausado". En algunas realizaciones, es importante que el receptor sea consciente del estado "pausado" para evitar el desencadenamiento de un tiempo de espera de recepción de datos.

El gestor de transferencia, a través de la interfaz de gestión, pasa el establecimiento del modo de control de la velocidad (velocidad fija, velocidad adaptativa y agresividad de ancho de banda) al emisor o al receptor. Si el receptor está controlado por el gestor de transferencia, el receptor almacena e implementa el nuevo modo de control de velocidad. El receptor envía la velocidad objetivo fija o calculada al emisor a través de los mensajes de estadísticas o de control. Si el emisor está controlado por el gestor de transferencia, el emisor almacena el nuevo establecimiento y lo envía al receptor a través de un mensaje de control. En una realización, la agresividad del ancho de banda puede expresarse en términos de un múltiplo de la agresividad TCP convencional. Algunas realizaciones incluyen la capacidad de soportar una escala proporcional continua de la agresividad relativa al TCP convencional y otros TCP. Esto puede exponerse a los usuarios finales a través de la interfaz de gestión como un tipo de flujo de compatibilidad con un índice continuo para "marcar" el valor de la agresividad en relación con ese tipo de flujo.

En términos de la pila de protocolos OSI, algunas realizaciones de la materia objeto presente proporcionan una capa de transporte de datos integrada, una capa de sesión y un protocolo de la capa de servicio.

Diversas realizaciones incluyen la integración dentro de un marco de transferencia de archivos del sistema operativo, tal como SSH y SCP. SSH proporciona una autenticación de usuario y un marco de intercambio de claves. Algunas realizaciones usan este marco para establecer claves de cifrado, si se ejecuta en un modo seguro opcional. SCP proporciona una interfaz de usuario de hecho para la copia del archivo remoto. Algunas realizaciones incluyen la integración con SCP como una alternativa, ruta de datos de alto rendimiento para TCP.

Algunas realizaciones almacenan metadatos que permiten la reanudación de una transferencia de archivos sin o con mínimos residuos de datos que ya se han transferido. La transferencia puede reanudarse desde cualquier emisor que almacene el mismo archivo, no necesariamente desde el mismo emisor. Esto permite el despliegue de sistemas redundantes, en los que las aplicaciones pueden reanudarse después de un fallo del sistema emisor, o una conexión a la misma, cuando un emisor de copia de seguridad, o una ruta de conexión, está disponible. Este servicio de reanudación ofrece varios niveles de comprobación de la integridad, garantía de integridad de balanceo y tiempo de verificación (el tiempo de verificación cuenta de nuevo la velocidad de transferencia de extremo a extremo total).

La velocidad objetivo en base a la naturaleza de los bloques en base a los sistemas de transferencia, procedimientos y soportes lógicos descritos en el presente documento, junto con la ecuación en base al control de la velocidad, se mantiene en las realizaciones que incluyen políticas de transferencia. Algunas políticas de transferencias se refieren a la asignación del ancho de banda, la priorización y el control manual de las transferencias de archivos.

a) La política de asignación de ancho de banda dada una organización con múltiples localizaciones y la capacidad de los enlaces de red entre estas localizaciones, un gestor o una aplicación de gestión del ancho de banda puede determinar la asignación de la capacidad de red entre las diferentes aplicaciones de transferencia de archivos. Las velocidades de transferencia máximas para cada flujo pueden pasarse a las aplicaciones de transferencia de archivos y ejecutarse. Los límites de la velocidad de transferencia pueden pasarse antes de que la transferencia del archivo se inicie, o mientras está en progreso. Para la asignación del ancho de banda impulsado por tiempo, cuando las transferencias de archivos tienen que cumplir con un tiempo de transferencia determinado, una realización permite el establecimiento de una velocidad de transferencia mínima. El flujo se comportará equitativamente en presencia de congestión, pero no se enlentecerá más allá de la velocidad de transferencia mínima. Esto garantiza un tiempo de entrega mínimo, a costa de forzar injustamente a todo el otro tráfico a competir por el ancho de banda restante. b) La política de priorización de algunas realizaciones puede asociar un nivel de prioridad a los factores de agresividad del control de velocidad. Por lo tanto, el tráfico de prioridad alta se asignará dinámicamente más ancho de banda. En un caso extremo de priorización, el tráfico de prioridad baja puede configurarse para detenerse completamente cuando compita con el tráfico de prioridad alta. Esto también permite transferencias de goteo que no tienen impacto en el otro tráfico, estableciendo la prioridad del tráfico de goteo al nivel más bajo, haciendo que se detenga en presencia de cualquier otro tráfico. c) La política de control manual de las transferencias de archivos del interfaz de gestión proporcionado con algunas realizaciones permite a los usuarios o los gestores cambiar los parámetros de transferencia sobre la marcha. Esto incluye pausar las transferencias para permitir a otras transferencias ejecutarse más rápido, así como enlentecer o acelerar las transferencias en curso.

Algunas realizaciones exponen los parámetros siguientes a la aplicación: velocidad objetivo (o la velocidad máxima para el control de la velocidad adaptativa), velocidad mínima (para el control de la velocidad adaptativa) y el factor de adaptación. Estos parámetros pueden establecerse antes de que la transferencia se inicie o se modifique mientras que la transferencia está en progreso. En base a estos parámetros, las aplicaciones pueden controlar inteligentemente las transferencias de archivos para lograr:

•

Transferencia de archivos a una velocidad fija especificando un control de velocidad fijo y suministrando una velocidad objetivo.

•

Transferencia de archivos a la capacidad del enlace, pero adaptándose equitativamente en presencia de tráfico competitivo especificando el control de la velocidad adaptativa y suministrando una velocidad máxima mayor o igual que la capacidad del enlace.

•

Transferencia de archivos a una velocidad dada, pero adaptándose a una velocidad mínima en presencia de congestión especificando la velocidad de control adaptativa y suministrando una velocidad mínima. El flujo se adaptará para compartir el enlace con el tráfico de competencia, pero su velocidad no será menor que la mínima especificada, garantizando de este modo el tiempo de entrega.

•

Transferencia de archivos a la capacidad del enlace, pero no causando ningún impacto en el tráfico de competencia especificando un control de velocidad adaptativa y suministrando el valor mínimo para el factor de adaptación. El flujo se ejecutará a la capacidad del enlace pero se detendrá en presencia de tráfico de competencia, por tanto, no causando en absoluto impacto en la actividad normal de la red. Esto puede usarse para transferencias de goteo eficientes.

Permitiendo a las aplicaciones cambiar la velocidad de transferencia mientras que una transferencia está en curso, las aplicaciones pueden pausar y reanudar las transferencias estableciendo la velocidad objetivo a cero, y a continuación de nuevo a un valor distinto de cero.

Algunas realizaciones también proporcionan un servicio de almacenamiento en la memoria caché inteligente, en base al bloque. Esto permite que estas realizaciones determinen si los segmentos de un archivo se han transmitido ya al sistema receptor y reusar los datos almacenados en la memoria caché en lugar de transferirlos a través de la red. Este servicio de almacenamiento en la memoria caché ofrece varias capas de comprobación de la integridad. El tipo de comprobación de la integridad puede especificarse mediante la aplicación o se determina automáticamente usando FASP, una función de optimización. La función de optimización considera el tiempo de verificación de la integridad de la memoria caché respecto a la capacidad de la red y la cola de transferencia. Si la transferencia es más rápida que la verificación de la integridad local, el servicio de almacenamiento en la memoria caché elige transferir los datos de nuevo. De lo contrario, se vuelven a usar los datos que están en la memoria caché local.

Algunas realizaciones adicionales proporcionan todos los servicios de monitorización y control necesarios para permitir que las aplicaciones implementen la transferencia de datos canalizados de doble cara, también denominada como una descarga progresiva. Una transferencia de datos de doble cara incluye un extremo de transferencia que recibe datos y al mismo tiempo envía los mismos datos a un tercer extremo de transferencia o al consumo de los datos. Ejemplos de una transferencia de datos canalizados de doble cara incluyen una aplicación que descarga un archivo de medios y en el mismo tiempo alimenta a un reproductor de medios, o a una aplicación de almacenamiento en memoria caché que descarga un archivo en nombre de un usuario y que almacena el archivo en la memoria caché mientras que lo entrega al usuario en el mismo tiempo.

Una realización de este tipo incluye un procedimiento para lograr que la transferencia de datos canalizados iniciando la transferencia de datos desde A a B a la velocidad deseada y exponiendo, en B, la velocidad de recepción efectiva, la velocidad de pérdida, y la cantidad de datos contiguos recibidos, iniciándose en el principio del archivo. El procedimiento incluye además la determinación de un tiempo para iniciar una transferencia desde B a C en base a los datos expuestos en B y en la velocidad de transferencia deseada de B a C. El procedimiento también incluye exponer en B, la velocidad efectiva de la transferencia desde B a C y la cantidad de datos enviados. En base a esta información, el procedimiento puede decidir si las canalizaciones funcionan adecuadamente. En el caso de que la transferencia desde B a C vaya por delante de la transferencia desde A a B, el procedimiento puede ralentizarse o incluso detener la transferencia desde B a C. Además, el procedimiento incluye la exposición del menor número de bloques que se le permite solicitar a la transferencia de B a C. Esto permite que el procedimiento en B descarte los datos hasta el momento, lo que es útil cuando el almacenamiento es limitado.

Algunas realizaciones incluyen identificación y transferencia de archivos usando referencias. Un extremo de transmisión puede descargar o cargar archivos o directorios en base a referencias específicas. Las referencias, en diversas realizaciones, incluyen una identificación del archivo o directorio remoto, los parámetros de transporte tales como la velocidad de transferencia, el control de la velocidad adaptativa y el cifrado.

Un ejemplo de un formato de referencia es:

fasp://<severname>/<

path>[?<option>&<option>...]

<server-name> is the remote machine’s name

(FQDN) or IP address.

<path> can point to a directory or a file.

Una o más de las siguientes opciones están disponibles para las referencias en diversas realizaciones:

xfer = up|down Up representa una carga, en cuyo caso la ruta representa un directorio de destino auth = yes|no Si se establece en yes, la transferencia requiere autenticación de usuario enc = yes|no|any Si se establece en yes, se fuerza a que se cifre la descarga, y si se establece en no, se fuerza

a que no se cifre. Si se establece en any o esta opción no está presente, el usuario puede

elegir entre cifrar o no. maxrate=<val> Establece la velocidad permitida máxima a <val> Kbps. El usuario puede elegir una velocidad

de transferencia hasta este valor. defrate=<val> Establece la velocidad de transferencia por defecto a <val> Kbps. El usuario puede elegir otra

velocidad hasta la máxima permitida. adapt=yes|no Si es yes, usa el control de velocidad adaptativa port = <val>. Establece un puerto UDP a

<val>. sign=<val> Firma de la cadena de referencia, como medida de seguridad para asegurar la integridad.

Al proporcionar la transferencia mediante el servicio de referencia, FASP puede integrarse fácilmente en aplicaciones tales como descarga o carga de web, reemplazo del adjunto de correo electrónico con referencias para la descarga FASP, registro de entrada y salida del sistema de gestión de activos. Algunas realizaciones de ejemplo de la materia objeto utilizan UDP para transportar la carga útil de los datos del bloque. Sin embargo, pueden lograrse los mismos objetivos utilizando prácticamente cualquier mecanismo de la capa de transporte o de red. Por ejemplo, las capas de transportes y de redes alternativas pueden incluir un protocolo de transporte definido por el usuario a través de IP o una pila TCP modificada en los extremos. Las pilas TCP en los extremos pueden modificarse para actuar como UDP, por ejemplo, sin control de flujo o retransmisión. Los bloques pueden enviarse como paquetes TCP a través de la red que puede ofrecer la capacidad de establecer ajustes de cortafuegos, evitando así un cortafuego específico y los ajustes de detección de intrusos para UDP. Otros transportes alternativos incluyen redes no IP, ofreciendo servicios similares a IP: enrutamiento sin conexión del "mejor esfuerzo" y entrega de paquetes entre dos o más extremos involucrados en una operación de transferencia de datos. Tales redes incluyen redes por satélite, de radio por paquetes, punto a punto o inalámbricas de difusión y ATM.

La arquitectura de algunas realizaciones es de dos niveles. El primer nivel en tales realizaciones proporciona un protocolo, ofreciendo a las aplicaciones un servicio de transporte de archivos en base al bloque. El segundo nivel es una aplicación de transferencia de archivos mínima hecha en la parte superior del protocolo.

Sin embargo, las variaciones de esta arquitectura pueden incluir la implementación de los sistemas y procedimientos como parte de un sistema operativo, como un módulo del núcleo, o, simplemente, como parte de un sistema operativo monolítico. Otras variaciones incluyen la implementación de la materia objeto en una aplicación de transferencia de datos monolítica (es decir, un enfoque nivelado único).

Otras realizaciones incluyen el uso de un intermediario de interceptación, transparente o no, para interceptar el tráfico TCP existente y transportarlo a través de la red de acuerdo con los diversos elementos descritos en el presente documento para un intermediario en el extremo remoto, que pasa los datos al extremo remoto de la aplicación TCP usando TCP. Este intermediario de interceptación puede ser una pieza de soporte lógico que puede funcionar en las máquinas del extremo, una pieza de soporte lógico funcionando en los archivos o en las máquinas de servidor de aplicaciones o un dispositivo de soporte físico conectado a la red. Aún, realizaciones adiciones incluyen la materia objeto dentro de un sistema de archivos de red. Otra realización incluye una pasarela de aplicación especializada para redes inalámbricas o por satélite para el transporte masivo eficiente.

Algunas realizaciones incluyen procedimientos y algoritmos para lograr la fiabilidad, el rendimiento, la seguridad y la capacidad de administración sintonizando determinados parámetros de protocolo. Los valores de estos parámetros se establecen de acuerdo con la red y el entorno del sistema operativo. La fiabilidad, el rendimiento, la seguridad y la capacidad de administración se llevan a cabo manipulando estos parámetros o la forma en que se calculan. Estos parámetros incluyen:

•

El tamaño de bloque

•

Los parámetros y y 7 del tiempo de espera de retransmisión

•

El tamaño de la memoria caché

•

La marca de agua inferior y superior de la memoria caché de archivo

•

El promedio de retransmisión de la memoria caché de archivo

•

FASP de velocidad de control y parámetro a del modo de compatibilidad TCP

•

El promedio base del control de la velocidad de los parámetros de la función de paso

•

El parámetro C del control de la velocidad

•

Los factores de los parámetros de control de la velocidad para el cambio de estado entre el modo FASP y TCP.

Claims (10)

1. REIVINDICACIONES

   1.

   Un sistema (200) de transferencia de datos para proporcionar la transferencia de datos a través de una red (224) entre un emisor (201) y un receptor (226), que comprende:

   un emisor configurado para transferir los datos a una velocidad de inyección especificada como se determina mediante una entrada de velocidad de inyección y para dividir los datos en bloques, teniendo cada bloque un número de identificación ordenado secuencialmente; un receptor configurado para recibir los bloques de datos transmitidos por el emisor y para detectar los bloques que se han perdido en la transmisión; en el que el receptor está configurado para enviar solicitudes de retransmisión al emisor cuando se detectan bloques perdidos; en el que el receptor está configurado para planificar la transmisión de las solicitudes de retransmisión que corresponden a los bloques perdidos al emisor tras el vencimiento de un tiempo de espera de retransmisión, RTO, en el que el RTO se obtiene de un tiempo de ida y vuelta de la ruta prevista; en el que el emisor está configurado para almacenar las retransmisiones pendientes en respuesta a las solicitudes de retransmisión recibidas desde el receptor; en el que el emisor está configurado para transmitir los bloques perdidos en respuesta a las solicitudes de retransmisión antes de transmitir nuevos bloques; en el que el receptor está configurado para cancelar las solicitudes de las retransmisiones planificadas tras la recepción de los bloques perdidos correspondientes; y, en el que el receptor está configurado para enviar las solicitudes de retransmisión a una velocidad proporcionada con la velocidad de inyección para, de este modo, limitar el número de retransmisiones pendientes almacenadas en el emisor.

2. 2.

   El sistema de transferencia de datos de la reivindicación 1, en el que la entrada de velocidad de inyección recibe una velocidad de inyección fija.

3. 3.

   El sistema de transferencia de datos de la reivindicación 1, en el que la entrada de velocidad de inyección recibe una velocidad de inyección variable.

4. 4.

   El sistema de transferencia de datos de la reivindicación 1, en el que la entrada de velocidad de inyección recibe una velocidad de inyección determinada por un procedimiento de control de velocidad en base a la medición de la congestión de la red entre el emisor y el receptor.

5. 5.

   El sistema de transferencia de datos de la reivindicación 4, en el que el procedimiento de control de la velocidad incluye los medios de medición del retardo de encolamiento que determinan los tiempos de ida y vuelta de la red para determinar la agresividad del procedimiento de control de la velocidad.

6. 6.

   El sistema de transferencia de datos de la reivindicación 5, en el que el procedimiento de control de la velocidad se estabiliza a una velocidad substancialmente equivalente a un flujo compatible TCP cuando el retardo de encolamiento indica congestión de red.

7. 7.

   El sistema de transferencia de datos de la reivindicación 1, que incluye un elemento de predicción del tiempo de ida y vuelta de la ruta para predecir con exactitud los tiempos de ida y vuelta de la ruta para identificar los bloques perdidos, en el que tiempo de ida y vuelta de la ruta predicho incluye el tiempo para que una solicitud de retransmisión viaje desde el receptor al emisor, el tiempo para que el emisor procese la solicitud de retransmisión y la prepare para la transmisión que incluye el tiempo para que el emisor relea el bloque de datos de la fuente, y el tiempo para que el bloque retransmitido correspondiente viaje desde el emisor al receptor, y en el que el tiempo de ida y vuelta predicho se hace lo suficientemente largo para evitar transmisiones duplicadas.

8. 8.

   El sistema de transferencia de datos de la reivindicación 7, en el que el elemento de predicción del tiempo de ida y vuelta de la ruta realiza una predicción Van Jacobson del tiempo de ida y vuelta predicho.

9. 9.

   El sistema de transferencia de datos de la reivindicación 1, en el que un árbol rojo negro, con la recuperación sustancial de la constante de tiempo, se usa por los medios de retransmisión para almacenar números de secuencia para las retransmisiones ordenadas por número.

10. 10.

    El sistema de transferencia de datos de la reivindicación 1, que comprende además un mecanismo de memoria caché de escritura de disco para minimizar el acceso aleatorio a un disco, usando el mecanismo una marca de agua superior calculada como un promedio de funcionamiento del tamaño de una tabla de retransmisión.