ES2376893T3 - Control de flujo de TFTP por un servidor - Google Patents

Control de flujo de TFTP por un servidor Download PDF

Info

Publication number
ES2376893T3
ES2376893T3 ES05714794T ES05714794T ES2376893T3 ES 2376893 T3 ES2376893 T3 ES 2376893T3 ES 05714794 T ES05714794 T ES 05714794T ES 05714794 T ES05714794 T ES 05714794T ES 2376893 T3 ES2376893 T3 ES 2376893T3
Authority
ES
Spain
Prior art keywords
server
request
flow control
control techniques
tftp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES05714794T
Other languages
English (en)
Inventor
Zhi Wang
Rui Jian
Ying'an Deng
Yuanhao Sun
Caidong Song
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Application granted granted Critical
Publication of ES2376893T3 publication Critical patent/ES2376893T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/15—Flow control; Congestion control in relation to multipoint traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/25—Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un procedimiento que comprende: recibir una petición de un primer dispositivo cliente (140, 150, 160) para realizar la difusión múltiple de un archivo como una pluralidad de paquetes de datos desde un dispositivo servidor (100) a múltiples dispositivos cliente (140, 150, 160); transmitir la pluralidad de paquetes de datos desde un servidor (100) a los múltiples dispositivos clientes (140, 150, 160) utilizando un Protocolo Trivial de Transferencia de Archivos con difusión múltiple (TFTP), y que se caracteriza por aplicar, por el servidor (100), una o más técnicas de control de flujo que comprenden al menos determinar si el dispositivo servidor (100) tiene recursos suficientes para satisfacer la petición sobre la base del tamaño de bloque co10 rrespondiente a la petición y el ancho de banda disponible, y enviar un paquete de error al primer dispositivo cliente (140, 150, 160) si el servidor (100) no tiene recursos suficientes para satisfacer la petición.

Description

Control de flujo de TFTP por un servidor
Campo técnico
Las realizaciones de la invención se refieren a la transferencia de archivos. Más en particular, las realizaciones de la invención se refieren al control de flujo por un servidor para el Protocolo Trivial de Transferencia de Archivos (TFTP).
Antecedentes
El Protocolo Trivial de Transferencia de Archivos (TFTP) es un protocolo de transferencia de archivos simple que opera en una forma de paso bloqueado. Esto es, cada paquete es reconocido por un cliente receptor y el servidor no transmite el paquete siguiente hasta que se recibe el acuse de recibo del paquete anterior. Una realización del TFTP se describe formalmente en la Petición de Comentarios (RFC) 1350, Rev. 2, publicada en julio de 1992. Como consecuencia de su simplicidad, el TFTP es utilizado en entornos de pre -arranque y / o sistemas integrados. El uso típico puede incluir la descarga de un cargador del sistema operativo o la mejora de una imagen del sistema o del BIOS.
Sin embargo, cuando aumentan los tamaños de los archivos y / o los paquetes se pierden durante la transmisión, el rendimiento ofrecido por el TFTP puede ser inaceptable debido a que los grandes tamaños de archivo y la transmisión de paquetes repetida pueden sobrecargar los componentes de la infraestructura de red. Por lo tanto, el TFTP puede ser insuficiente para las condiciones de descarga de archivos más complejos.
Las difusiones dirigidas en subredes son desveladas en la Patente norteamericana número 6185623, debido a la carga del programa inicial de estaciones de red que no están punteadas por los clientes en una subred más lenta y a los cambios en la dirección IP de la fuente para acomodar múltiples IOP y el equilibrado de cargas, se permiten. Un servidor de difusión en subred transfiere un datagrama que incluye el programa de carga junto con un identificador de difusión en subred y un identificador de puerto de origen a las estaciones de la red cliente en una base de subred. Los enrutadores en las subredes que no coinciden con el identificador de difusión en subred realizan la difusión única del datagrama a la siguiente pasarela; y los enrutadores en el identificador de difusión que coincide con la capa de enlace de datos de subredes realizan la difusión única de los datagramas desde las subredes intervinientes a todas las vecinas en la subred coincidente al mismo tiempo que desatienden enviar esta difusión de capa de enlace de datos a cualesquiera subredes vecinas.
Desvelado en el documento de Patente norteamericana 6151696 hay un procedimiento de transmisión de datos que transfiere rápida y fiablemente (por ejemplo, un archivo de ordenador) desde una fuente a receptores. Mientras los marcos están siendo transmitidos, los acuses de recibo negativos de los receptores son recibidos por la fuente. Estos acuses de recibo indican que los marcos requieren retransmisión. Después de que todos los marcos hayan sido transmitidos, una retransmisión es realizada por la fuente solamente de aquellos marcos para los que los acuses de recibo indican que requieren retransmisión. Se pueden producir retransmisiones adicionales. Esta técnica de transferencia de datos de pasos múltiples solamente requiere que los acuses de recibo negativos sean enviados por los receptores. Las características incluyen la capacidad de fijar la tasa de transmisión y definir los grupos con difusión múltiple. Además, es posible determinar la capacidad de los enlaces de capacidad desconocida utilizando una característica de " sonda de red con difusión múltiple", y determinar las tasas de errores de marco de los enlaces de capacidad conocida utilizando la misma característica. Una característica de "ping con difusión múltiple" se puede utilizar para determinar la conectividad entre una fuente y los miembros de un grupo con difusión múltiple. Los "grupos de velocidad" se pueden configurar después de determinar las capacidades de los enlaces, o si ya son conocidos, los receptores conectados a la fuente por los enlaces más rápidos reciben todos los datos mientras que los receptores con enlaces más lentos reciben sólo una porción de los datos, en el primer paso. El número de receptores que pueden recibir los datos desde la fuente puede ser incrementado en gran medida mediante el uso de un esquema de "colección de acuses de recibo negativos" por el cual "los puntos de réplica" (preferiblemente enrutadores) recogen acuses de recibo negativos individuales y los mandan como una unidad al siguiente nivel.
Desvelado en la Solicitud de Patente norteamericana 2004/0267960 hay un procedimiento para aumentar el rendimiento de una red con difusión múltiple en la que un servidor realiza la difusión múltiple de los paquetes a un cliente maestro y al menos a un cliente pasivo. Los aspectos incluyen determinar por los clientes durante la transferencia con difusión múltiple, cual es el cliente más lento en base a cual cliente deja caer un mayor número de paquetes, y hacer que el cliente más lento sea el cliente maestro, determinando por lo tanto de manera adaptativa cual cliente se convierte en el cliente maestro para reducir al mínimo el tráfico de la red.
La Solicitud de Patente europea 1134950 desvela una red de transferencia de datos que comprende un servidor TFTP conectado para transferir datos a una serie de aparatos clientes conectados a la red. Cuando los datos deben ser transmitidos, uno de los clientes es designado como cliente maestro y la velocidad de las peticiones de datos del cliente maestro determina la tasa de transferencia de datos a todos los clientes. La tasa de transferencia de datos a cada cliente, cuando es seleccionado como cliente maestro, es monitorizada y comparada con las tasas de transferencia predeterminadas. Si se identifica por medio de la comparación que la tasa de transferencia es superior a la que se requiere, el servidor TFTP selecciona otro cliente que está disponible como cliente maestro. En el caso de que uno de los clientes esté deshabilitado y no pueda actuar como cliente maestro para recibir los datos, esto es identificado por el servidor TFTP monitorizando los mensajes de gestión de la red que identifican la deshabilitación o falta de disponibilidad del cliente. Si un cliente es identificado como que está indisponible o que deshabilitado, el servidor TFTP no intenta elegir al cliente como cliente maestro.
El TFTP con difusión múltiple no define las técnicas para el control de flujo por un servidor. El estándar de TFTP está basado en un modelo de transferencia de paso bloqueado en el que el dispositivo cliente acusa recibo de cada paquete antes de que el servidor transmita un paquete posterior. Esto no permite que la tasa de transferencia sea controlada por el dispositivo servidor.
Un objeto de la presente invención es proporcionar el control de flujo por un servidor de un TFTP y / o una sesión con difusión múltiple TFTP.
Breve descripción de los dibujos
Las realizaciones de la invención se ilustran, a título de ejemplo y no a título de limitación, en las figuras de los dibujos que se acompañan, en los que los mismos números de referencia se refieren a elementos similares.
La figura 1 es un diagrama de bloques de una red que puede conectar un servidor a múltiples clientes.
La figura 2 es un diagrama de flujo de una realización de un flujo principal de la operación de un dispositivo servidor que puede proporcionar el control de flujo de un servidor de un TFTP y / o de una sesión con difusión múltiple TFTP.
La figura 3 es un diagrama de flujo de la operación de una realización de un manejador de peticiones de carga ejecutadas por un dispositivo servidor que puede proporcionar el control de flujo de un servidor de un TFTP y / o de una sesión con difusión múltiple TFTP.
La figura 4 es un diagrama de flujo de la operación de una realización de un manejador de peticiones de descarga con difusión única ejecutadas por un dispositivo servidor que puede proporcionar el control de flujo de un servidor de un TFTP y / o de una sesión con difusión múltiple TFTP.
La figura 5 es un diagrama de flujo de la operación de una realización de un manejador de peticiones de descargas con difusión múltiple ejecutadas por un dispositivo servidor que puede proporcionar el control de flujo de un servidor de un TFTP y / o de una sesión con difusión múltiple TFTP.
La figura 6 es un diagrama de bloques de una realización de un sistema electrónico
Descripción detallada
En la descripción que sigue, se establecen numerosos detalles específicos. Sin embargo, las realizaciones de la invención pueden ser practicadas sin estos detalles específicos. En otros casos, circuitos, estructuras y técnicas bien conocidas no se han mostrado en detalle con el fin de no oscurecer la comprensión de esta descripción.
La figura 1 es un diagrama de bloques de una red que puede conectar un servidor a múltiples clientes. El servidor 100 se puede acoplar con cualquier número de clientes (por ejemplo, 140, 150, 160) por medio de la red 120, que opera de acuerdo con cualquier protocolo de comunicación de red conocido en la técnica.
Actualmente, el Protocolo Trivial de Transferencia de Archivos (TFTP) se puede utilizar para transferir archivos entre dispositivos. En general, el TFTP es un protocolo de transferencia que es más fácil de usar que el Protocolo de Transferencia de Archivos (FTP), pero ofrece menos funcionalidades. Por ejemplo, el TFTP no soporta la autenticación de usuario o la visibilidad de directorios. El TFTP utiliza el Protocolo de Datagrama de Usuario (UDP) en lugar del Protocolo de Control de Transmisión (TCP). Una realización del TFTP se describe formalmente en la Petición de Comentarios (RFC) 1350, Rev. 2, publicado en julio de 1992.
El TFTP ha sido expandido para incluir una opción con difusión múltiple tal como se describe en el RFC 2090, publicado en febrero de 1997. El TFTP con difusión múltiple clasifica los dispositivos cliente como clientes activos o clientes pasivos. Sólo hay un cliente activo en un momento dado. El cliente activo se comunica con un servidor para descargar los datos utilizando un flujo de ARQ de parada y espera y la técnica de control de errores a una dirección de grupo negociado. Los clientes pasivos buscan en la descarga al cliente activo y capturan datos destinados a la dirección de grupo. Cuando el cliente activo termina la descarga de los datos, un cliente pasivo es seleccionado como nuevo cliente activo.
En una realización, un cliente, por ejemplo, el cliente 160, puede operar como un cliente activo tal como es definido por el TFTP con difusión múltiple para solicitar la descarga de un archivo desde el servidor 100. Cualquier número de clientes adicionales, por ejemplo, los clientes 140 y 150, pueden operar como clientes pasivos tal como es definido por el TFTP con difusión múltiple para recibir los paquetes correspondientes al archivo pedido por el cliente activo. Una vez completada la descarga por el cliente activo, uno de los clientes pasivos puede llegar a ser un nuevo cliente activo para descargar los paquetes que faltan.
En la descripción de la presente memoria descriptiva, el término "paquete" se refiere a cualquier bloque de datos, que puede ser, por ejemplo, de una, longitud fija predefinida o de una longitud variable. En una realización, un paquete es definido por la definición de TFTP con difusión múltiple. En realizaciones alternativas, otros tamaños de paquetes pueden ser utilizados.
El TFTP con difusión múltiple no define las técnicas para el control de flujo por un servidor. En una realización, una sesión de TFTP con difusión múltiple puede ser gestionada por el servidor 100 usando una o más técnicas de control de flujo que se describen en la presente memoria descriptiva. El estándar de TFTP se basa en un modelo de transferencia de paso bloqueado en el que se realiza el acuse de recibo de cada paquete por el dispositivo cliente antes de que el servidor envíe un paquete posterior. Esto no permite que la tasa de transferencia sea controlada por el dispositivo servidor.
En una realización, un cliente pasivo se puede unir al grupo con difusión múltiple durante la descarga de archivos. Para estos clientes pasivos, los paquetes transmitidos antes de unirse al grupo con difusión múltiple pueden ser recibidos cuando los paquetes perdidos se retransmiten a un nuevo cliente activo.
La figura 2 es un diagrama de flujo de una realización de un flujo principal de la operación de un dispositivo servidor que puede proporcionar el control de flujo por un servidor de un TFTP y / o de una sesión de TFTP de difusión múltiple. El servidor puede monitorizar un puerto designado para detectar los paquetes que pueden llevar peticiones de descarga de un archivo 200. En una realización, el dispositivo servidor puede ejecutar una aplicación de hilos múltiples que incluye un hilo que monitoriza el puerto designado. El puerto designado puede ser, por ejemplo, el puerto UDP 69 tal como se define en el estándar TFTP; sin embargo, también se pueden utilizar otros puertos.
Cuando un paquete es recibido a través del puerto designado, la aplicación puede analizar el paquete para determinar si el paquete incluye una petición de un dispositivo cliente 210. En respuesta a una petición de un dispositivo cliente, la aplicación puede llamar al manejador de peticiones correspondiente, 220. Después de llamar al manejador de peticiones, la aplicación puede volver a monitorizar el puerto designado. En una realización, por lo menos los siguientes tres manejadores de peticiones son implementados por la aplicación y / o por otra aplicación ejecutada por el dispositivo servidor: un manejador de peticiones de carga (figura 3), un manejador de peticiones de descarga con difusión única (figura 4), y un manejador de peticiones de descarga con difusión múltiple (figura 5). En realizaciones alternativas, manejadores de peticiones adicionales y / o diferentes pueden ser soportados.
La figura 3 es un diagrama de flujo de la operación de una realización de un manejador de peticiones de carga ejecutada por un dispositivo servidor que puede proporcionar el control de flujo de un servidor de un TFTP y / o de una sesión de TFTP con difusión múltiple. Como respuesta a ser invocado, el manejador de carga puede determinar si la petición correspondiente es una petición duplicada, 300. Si la petición es una petición duplicada, el manejador de carga puede retornar debido a que la carga solicitada ha sido procesada.
Si la petición no es una duplicada, 300, el manejador de peticiones de carga puede determinar si el servidor principal tiene recursos satisfactorios para procesar la petición, 310. Si el servidor no tiene recursos satisfactorios disponibles, el manejador de carga puede hacer que un paquete de error sea enviado al dispositivo cliente solicitante, 330. Si el servidor tiene recursos satisfactorios disponibles, el manejador de carga puede guardar la información de sesión que puede ser utilizada, por ejemplo, por otros manejadores de peticiones, y el manejador de peticiones de carga puede crear un hilo para servir la petición, 320. Las técnicas de control de flujo de un servidor que pueden ser utilizadas en el servicio de la petición de carga se describen con más detalle a continuación.
La figura 4 es un diagrama del flujo de operación de una realización de un manejador de peticiones de descarga en difusión múltiple ejecutada por un dispositivo servidor que puede proporcionar control de flujo por un servidor de un TFTP y / o de una sesión con difusión múltiple de TFTP. Como respuesta a ser invocado, el manejador de descarga con difusión única puede determinar si la petición correspondiente es una petición duplicada, 400. Si la petición es una petición duplicada, el manejador de descarga con difusión única puede volver debido a que la descarga solicitada ya ha sido procesada.
Si la petición no es una duplicada, 400, el manejador de peticiones de descarga con difusión única puede determinar si el servidor principal tiene recursos satisfactorios disponibles para procesar la petición, 410. Si el servidor no tiene los recursos satisfactorios disponibles, el manejador de peticiones con difusión única puede hacer que un paquete de error sea enviado al dispositivo cliente solicitante, 430. Si el servidor tiene recursos satisfactorios disponibles, el manejador de peticiones con difusión única puede guardar la información de sesión que puede ser utilizada, por ejemplo, por otros manejadores de peticiones, y el manejador de peticiones de descarga con difusión única puede crear un hilo para servir la petición, 420. Técnicas de control de flujo de un servidor que pueden ser utilizadas para servir la petición de descarga con difusión única se describen con más detalle a continuación.
La figura 5 es un diagrama de flujo de la operación de una realización de un manejador de peticiones de descarga con difusión múltiple ejecutada por un dispositivo servidor que puede proporcionar el control de flujo de un servidor de un TFTP y / o de una sesión con difusión múltiple de TFTP. Como respuesta a ser invocado, el manejador de descarga con difusión múltiple puede determinar si la petición correspondiente es una petición duplicada, 500. Si la petición es una petición duplicada, el manejador de descarga con difusión múltiple puede devolver un mensaje de acuse de recibo enviado anteriormente al dispositivo cliente solicitante, 505. El mensaje de acuse de recibo puede hacer que el cliente solicitante opere como un cliente pasivo en la sesión de descarga con difusión múltiple.
Si la petición no es un duplicado, 500, el manejador de peticiones de descarga con difusión múltiple puede determinar si otro grupo con difusión múltiple está descargando el archivo solicitado, 510. Si el archivo solicitado está siendo 5 descargado, el manejador de descarga con difusión múltiple hace que el cliente solicitante se convierta en un cliente pasivo en el grupo de descarga con difusión múltiple existente, 515.
Si el archivo solicitado no está siendo descargado por otro grupo con difusión múltiple, 510, el manejador de peticiones de descargas con difusión múltiple puede determinar si el servidor principal tiene recursos satisfactorios disponibles para procesar la petición, 520. Si el servidor no tiene los recursos satisfactorios disponibles, el manejador de 10 descargas con difusión múltiple puede hacer que un paquete de error sea enviado al dispositivo cliente solicitante,
530. Si el servidor cuenta con los recursos satisfactorios disponibles, el manejador de descargas con difusión múltiple puede guardar la información de sesión que puede ser utilizada, por ejemplo, por otros manejadores de peticiones, y el manejador de peticiones de descargas con difusión múltiple puede crear un hilo para atender la petición,
540. Las técnicas de control de flujo de un servidor que pueden ser utilizadas en el servicio de la petición de descar15 ga con difusión única se describen con más detalle a continuación.
En una realización, para guardar la información de sesión, una aplicación que se ejecuta en el servidor puede mantener tres listas enlazadas (u otras estructuras de datos adecuadas) para guardar la información relativa a sesiones de subida, sesiones de descarga con difusión única y sesiones de descarga con difusión múltiple. Un manejador de peticiones puede atravesar una o más las listas enlazadas para determinar si la petición actual es una petición dupli
20 cada y / o si el archivo está siendo descargado. Esto puede permitir que el servidor combine sesiones de descarga cuando sea apropiado.
En una realización, uno o más controladores de peticiones monitorizan los recursos del sistema principal para determinar si hay suficientes recursos disponibles para procesar una petición. Los recursos pueden incluir, por ejemplo, el ancho de banda, capacidad de cálculo del ordenador principal, uso de memoria, el número de hilos activos, etc. El
25 criterio de los recursos puede ser diferente para los diferentes controladores de peticiones. Por ejemplo, si el tamaño de bloque de una petición es L y el ancho de banda de la conexión con el servidor es B, entonces se puede requerir que una nueva petición satisfaga
lo cual permitiría a cada sesión activa enviar al menos un paquete cada medio segundo. Otros criterios también se 30 pueden utilizar.
En una realización, el servidor puede monitorizar la tasa de pérdida de paquetes y ajustar la tasa de transmisión de paquetes en base, al menos en parte, a la tasa de pérdida de paquetes. Por ejemplo, un retardo en la transmisión puede ser calculado de acuerdo con:
Si(paquete se pierde){ 35 si (retardo de envío es cero) { Establecer retardo envío en 1 } en otro caso si (retardo envío > tiempo límite /4) { Establecer retardo envío en tiempo límite/ 4 } 40 Retardo envío doble } en otro caso{ Disminuir retardo envío en 1 cada 10 paquetes recibidos correctamentehasta 0 }
45 También se pueden utilizar otros cálculos de retardo.
En una realización, las técnicas de las figuras 2 -5 pueden ser implementadas como instrucciones ejecutadas por un sistema electrónico. Las instrucciones pueden ser almacenadas por el dispositivo electrónico o las instrucciones pueden ser recibidas por el dispositivo electrónico (por ejemplo, por medio de una conexión de red). La figura 6 es un diagrama de bloques de una realización de un sistema electrónico. El sistema electrónico ilustrado en la figura 6 está destinado a representar una amplia gama de sistemas electrónicos, por ejemplo, sistemas informáticos, dispositivos de acceso a la red, etc. Sistemas alternativos, ya sean electrónicos o no electrónicos, puede incluir más, menos y / o diferentes componentes. El sistema electrónico de la figura 6 puede representar un dispositivo servidor, así como uno o más dispositivos clientes.
El sistema electrónico 600 incluye un bus 605 u otro dispositivo de comunicación para comunicar información, y un procesador 610 acoplado al bus 605 para procesar la información. Aunque el sistema electrónico 600 está ilustrado con un único procesador, el sistema electrónico 600 puede incluir múltiples procesadores y / o coprocesadores. El sistema electrónico 600 incluye, además, una memoria de acceso aleatorio (RAM) u otro dispositivo de almacenamiento dinámico 620 (referido como memoria) acoplado al bus 605 para almacenar información e instrucciones para ser ejecutadas por el procesador 610. La memoria 620 también puede ser usada para almacenar variables temporales u otra información intermedia durante la ejecución de las instrucciones por el procesador 610.
El sistema electrónico 600 también incluye memoria de sólo lectura (ROM) y / o otros dispositivos de almacenamiento estático 630 acoplados al bus 605 para almacenar información estática y las instrucciones para el procesador 610. En una realización, el dispositivo de almacenamiento estático 630 puede incluir un agente de firmware integral que puede tener una interfaz que cumple con la Interfaz de Firmware Extensible (EFI) como se define en las Especificaciones de EFI, versión 1.10, publicada el 26 de noviembre 2003, disponible en Intel Corporation de Santa Clara, California. En realizaciones alternativas, otros componentes de firmware también pueden ser utilizados.
El dispositivo de almacenamiento de datos 640 está acoplado al bus 605 para almacenar información e instrucciones. El dispositivo de almacenamiento de datos 640, tal como un disco magnético o disco óptico y el controlador correspondiente se pueden acoplar al sistema electrónico 600.
El sistema electrónico 600 también se puede acoplar por medio del bus 605 al dispositivo de pantalla 650, tal como un tubo de rayos catódicos (CRT) o pantalla de cristal líquido (LCD) para mostrar información al usuario. El dispositivo de entrada alfanumérica 660, incluyendo teclas alfanuméricas y otras, típicamente está acoplado al bus 605 para comunicar la información y la selección de comandos al procesador 610. Otro tipo de dispositivo de entrada de usuario es el control de cursor 670, tal como un ratón, dispositivo de puntero o teclas de dirección del cursor para comunicar información de dirección y selección de comandos al procesador 610 y para controlar el movimiento del cursor en la pantalla 650. El sistema electrónico 600 incluye, además, la interfaz de red 680 para proporcionar acceso a una red, tal como una red de área local. La interfaz de red 680 puede incluir, además, una o más antenas 685 para proporcionar una interfaz de red inalámbrica de acuerdo con cualquier protocolo conocido en la técnica.
Las instrucciones se encuentran provistas en la memoria de un dispositivo de almacenamiento, tal como un disco magnético, un circuito integrado de memoria de sólo lectura (ROM), CD-ROM, DVD, por medio de una conexión remota (por ejemplo, en una red por medio de una interfaz de red 680) que proporciona acceso, ya sea por cable o inalámbrico, a uno o más medios accesibles electrónicamente, etc. En realizaciones alternativas, se pueden utilizar circuitos cableados en lugar de o en combinación con las instrucciones de software. Por lo tanto, la ejecución de las secuencias de instrucciones no se limita a ninguna combinación específica de los circuitos de hardware e instrucciones de software.
Un medio accesible electrónicamente incluye cualquier mecanismo que proporcione (es decir, almacene y / o transmita) el contenido (por ejemplo, instrucciones informáticas ejecutables) en una forma legible por un dispositivo electrónico (por ejemplo, un ordenador, un asistente personal digital, un teléfono celular). Por ejemplo, un medio accesible por máquina incluye memoria de sólo lectura (ROM); memoria de acceso aleatorio (RAM); medios magnéticos de almacenamiento en disco; medios ópticos de almacenamiento; dispositivos de memoria flash; señales propagadas de forma eléctrica, óptica, acústica o de otra forma señales propagadas (por ejemplo, ondas portadoras, señales de infrarrojos, señales digitales), etc.
La referencia en la memoria descriptiva a "una realización" significa que una característica o estructura particular descritas en relación con la realización está incluido en al menos una realización de la invención. Las apariciones de la frase "en una realización" en varios lugares en la memoria descriptiva, no se refieren todas necesariamente a la misma realización.

Claims (13)

  1. REIVINDICACIONES
    1. Un procedimiento que comprende:
    recibir una petición de un primer dispositivo cliente (140, 150, 160) para realizar la difusión múltiple de un archivo como una pluralidad de paquetes de datos desde un dispositivo servidor (100) a múltiples dispositivos cliente (140, 150, 160);
    transmitir la pluralidad de paquetes de datos desde un servidor (100) a los múltiples dispositivos clientes (140, 150, 160) utilizando un Protocolo Trivial de Transferencia de Archivos con difusión múltiple (TFTP), y
    que se caracteriza por
    aplicar, por el servidor (100), una o más técnicas de control de flujo que comprenden al menos determinar si el dispositivo servidor (100) tiene recursos suficientes para satisfacer la petición sobre la base del tamaño de bloque correspondiente a la petición y el ancho de banda disponible, y enviar un paquete de error al primer dispositivo cliente (140, 150, 160) si el servidor (100) no tiene recursos suficientes para satisfacer la petición.
  2. 2. El procedimiento de la reivindicación 1, en el que aplicar por el servidor (100) una o más técnicas de control de flujo comprende, además:
    monitorizar una tasa de pérdida de paquetes, y
    retardar el comienzo de la transmisión de la pluralidad de paquetes en base a la tasa de pérdida de paquetes.
  3. 3. El procedimiento de la reivindicación 1, en el que aplicar por el servidor (100), una o más técnicas de control de flujo comprende, además:
    determinar si una petición para descargar el archivo es el objeto de una sesión de descarga con difusión múltiple existente y
    hacer que los dispositivos cliente múltiples (140, 150, 160) se unan a un grupo con difusión múltiple existente correspondientes a la sesión de descarga con difusión múltiple existente.
  4. 4.
    El procedimiento de la reivindicación 1, en el que aplicar por el servidor (100), una o más técnicas de control de flujo comprende, además, modificar la calidad de servicio sobre la base, al menos en parte, de las condiciones de recursos.
  5. 5.
    El procedimiento de la reivindicación 4, en el que modificar la calidad del servicio comprende uno o más de:
    modificar el tamaño de bloque y modificar la duración del tiempo límite.
  6. 6.
    El procedimiento de la reivindicación 1, en el que aplicar por el servidor (100), una o más técnicas de control de flujo comprende, además, reducir la tasa de transmisión de paquetes.
  7. 7.
    El procedimiento de la reivindicación 1, en el que aplicar por el servidor (100) una o más técnicas de control de flujo comprende, además, retransmitir el paquete transmitido más recientemente como respuesta a la recepción de un paquete no esperado.
  8. 8.
    Un dispositivo servidor (100) que comprende:
    una interfaz de red (680) para recibir mensajes de uno o más dispositivos cliente (140, 150, 160), incluyendo peticiones para descargar un archivo almacenado por el dispositivo servidor (100);
    una memoria (620, 630, 640) acoplada a la interfaz de red (680) para almacenar el archivo, y
    que se caracteriza por
    un procesador (610) acoplado a la memoria (620, 630, 640) y a la interfaz de red (680) para recibir una petición de un primer dispositivo cliente (140, 150, 160) del uno o más dispositivos cliente (140, 150 , 160) para realizar la difusión múltiple del archivo como una pluralidad de paquetes de datos desde el dispositivo servidor (100) a uno o más dispositivos cliente (140, 150, 160), transmitir la pluralidad de paquetes de datos desde un servidor (100) a uno o más dispositivos cliente (140, 150, 160) con un Protocolo Trivial de Transferencia de Archivos (TFTP) con difusión múltiple, y aplicar una o más técnicas de control de flujo que comprende, al menos, determinar si el dispositivo servidor (100) cuenta con recursos suficientes para satisfacer la petición sobre la base del tamaño de bloque correspondiente a la petición y el ancho de banda disponible, y enviar un paquete de error al primer dispositivo cliente (140, 150, 160) si el servidor (100) no tiene recursos suficientes para satisfacer la petición.
  9. 9. El servidor (100) de la reivindicación 8, en el que la una o más técnicas de control de flujo comprenden, además:
    monitorizar una tasa de pérdida de paquetes, y
    retardar el comienzo de la transmisión de la pluralidad de paquetes sobre la base de la tasa de pérdida de paquetes.
    5 10. El servidor (100) de la reivindicación 8, en el que la una o más técnicas de control de flujo comprenden, además, determinar si una petición para descargar el archivo es un objeto de una sesión de descarga con difusión múltiple existente, y hacer que los dispositivos cliente múltiples (140, 150, 160) se unan a un grupo con difusión múltiple existente correspondiente a la sesión de descarga con difusión múltiple existente.
  10. 11. El servidor (100) de la reivindicación 8, en el que la una o más técnicas de control de flujo comprende, 10 además, modificar la calidad de servicio sobre la base de, al menos en parte, las condiciones de los recursos.
  11. 12. El servidor (100) de la reivindicación 11, en el que modificar la calidad del servicio comprende uno o más de:
    modificar el tamaño de bloque y modificar la duración de tiempo límite.
  12. 13. El servidor (100) de la reivindicación 8, en el que la una o más técnicas de control de flujo comprenden, 15 además, reducir la tasa de transmisión de paquetes.
  13. 14. Un medio de almacenamiento que almacena instrucciones de programa para programar un aparato de procesamiento programable que tiene uno o más procesadores, de manera que sean operativos para realizar un procedimiento tal como se establece en cualquiera de las reivindicaciones 1 a 7.
ES05714794T 2005-03-05 2005-03-05 Control de flujo de TFTP por un servidor Expired - Lifetime ES2376893T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2005/000263 WO2006094426A1 (en) 2005-03-05 2005-03-05 Server side tftp flow control

Publications (1)

Publication Number Publication Date
ES2376893T3 true ES2376893T3 (es) 2012-03-20

Family

ID=36952929

Family Applications (1)

Application Number Title Priority Date Filing Date
ES05714794T Expired - Lifetime ES2376893T3 (es) 2005-03-05 2005-03-05 Control de flujo de TFTP por un servidor

Country Status (8)

Country Link
US (1) US7934007B2 (es)
EP (1) EP1859594B1 (es)
KR (1) KR100953004B1 (es)
CN (1) CN101138216B (es)
AT (1) ATE541392T1 (es)
ES (1) ES2376893T3 (es)
GB (1) GB2439010B (es)
WO (1) WO2006094426A1 (es)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101088070B (zh) 2004-12-31 2011-07-27 英特尔公司 远程记录机制的方法与系统
CN100578484C (zh) * 2005-03-07 2010-01-06 英特尔公司 用于自适应组播文件传输的方法和装置
EP2058970A1 (en) * 2007-11-06 2009-05-13 Thomson Licensing Method, apparatus and system for multicast data rate adaptation
US20100296403A1 (en) * 2009-04-06 2010-11-25 Lili Qiu Predictable Performance Optimization of Wireless Networks
US7984166B2 (en) * 2009-09-02 2011-07-19 Honeywell International Inc. Trivial file transfer protocol (TFTP) file segment and file address options
US8521902B2 (en) 2010-12-02 2013-08-27 Microsoft Corporation Shared buffer for connectionless transfer protocols
US9049175B2 (en) 2010-12-02 2015-06-02 Microsoft Technology Licensing, Llc Client-adjustable window size for connectionless transfer protocols
US20140047124A1 (en) * 2012-08-10 2014-02-13 Honeywell International Inc. Trivial file transfer protocol (tftp) data transferring prior to file transfer completion
US9143553B2 (en) 2013-02-26 2015-09-22 Honeywell International Inc. Trivial file transfer protocol (TFTP) accelerated file retry option
US9912454B2 (en) * 2015-02-16 2018-03-06 Dell Products L.P. Systems and methods for efficient file transfer in a boot mode of a basic input/output system
US9986010B2 (en) * 2015-09-29 2018-05-29 Sensormatic Electronics, LLC System and method for controlling video and/or audio streams in a web browser
US10574706B2 (en) * 2016-05-29 2020-02-25 Flash Networks, Ltd Method and system for upload optimization
US11510220B2 (en) * 2017-11-24 2022-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Location aware scheduling
CN111078414B (zh) * 2019-12-17 2024-03-01 北京思维造物信息科技股份有限公司 请求响应方法、装置、设备和存储介质
US11381634B1 (en) 2021-08-03 2022-07-05 International Business Machines Corporation TFTP (trivial file transfer protocol) broadcast controller

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN86107645A (zh) * 1986-11-11 1988-05-25 美国电话电报公司 计算机网络中传送资源信息的方法
US5920701A (en) * 1995-01-19 1999-07-06 Starburst Communications Corporation Scheduling data transmission
US5553083B1 (en) 1995-01-19 2000-05-16 Starburst Comm Corp Method for quickly and reliably transmitting frames of data over communications links
US7301944B1 (en) * 1997-10-24 2007-11-27 Tranz-Send Broadcasting Network, Inc. Media file distribution with adaptive transmission protocols
US6185623B1 (en) * 1997-11-07 2001-02-06 International Business Machines Corporation Method and system for trivial file transfer protocol (TFTP) subnet broadcast
IL123819A (en) * 1998-03-24 2001-09-13 Geo Interactive Media Group Lt Network media streaming
GB0006096D0 (en) 2000-03-15 2000-05-03 Pace Micro Tech Plc Improvements to control system for network servers
US7051337B2 (en) * 2000-04-08 2006-05-23 Sun Microsystems, Inc. Method and apparatus for polling multiple sockets with a single thread and handling events received at the sockets with a pool of threads
US7065586B2 (en) * 2000-12-22 2006-06-20 Radiance Technologies, Inc. System and method for scheduling and executing data transfers over a network
US7069334B2 (en) 2000-12-27 2006-06-27 Intel Corporation Image restoration and reconfiguration support for crashed devices
GB0108791D0 (en) * 2001-04-07 2001-05-30 Pace Micro Tech Plc Improvements to control systems for network servers
US7088678B1 (en) * 2001-08-27 2006-08-08 3Com Corporation System and method for traffic shaping based on generalized congestion and flow control
US7051112B2 (en) * 2001-10-02 2006-05-23 Tropic Networks Inc. System and method for distribution of software
US6983334B2 (en) * 2001-11-07 2006-01-03 International Business Machines Corporation Method and system of tracking missing packets in a multicast TFTP environment
US7305585B2 (en) * 2002-05-23 2007-12-04 Exludus Technologies Inc. Asynchronous and autonomous data replication
US20040236829A1 (en) * 2003-05-13 2004-11-25 Yikang Xu Reliable delivery of multi-cast conferencing data
US20040267960A1 (en) 2003-06-25 2004-12-30 International Business Machines Corporation Force master capability during multicast transfers
KR100542368B1 (ko) * 2004-02-10 2006-01-10 삼성전자주식회사 브로드캐스팅 기능이 구비된 간단한 파일전송시스템 및 그방법

Also Published As

Publication number Publication date
GB2439010B (en) 2009-10-07
CN101138216B (zh) 2013-01-02
EP1859594A4 (en) 2009-04-22
EP1859594A1 (en) 2007-11-28
US20080250155A1 (en) 2008-10-09
ATE541392T1 (de) 2012-01-15
GB2439010A (en) 2007-12-12
CN101138216A (zh) 2008-03-05
WO2006094426A1 (en) 2006-09-14
GB0718495D0 (en) 2007-10-31
US7934007B2 (en) 2011-04-26
KR20070120118A (ko) 2007-12-21
EP1859594B1 (en) 2012-01-11
KR100953004B1 (ko) 2010-04-14

Similar Documents

Publication Publication Date Title
US8259628B2 (en) Method and system for handling connection setup in a network
US7532577B2 (en) Managing transmission control protocol (TCP) connections
US20100180037A1 (en) Method and apparatus for optimizing and prioritizing the creation of a large number of VPN tunnels
BRPI9908426B1 (pt) processo e sistema para reduzir o tempo excedente em comunicação de mensagens
ES2955714T3 (es) Método de envío de paquetes de datos y dispositivo relacionado
US10750499B2 (en) Method, device and system for controlling air interface resource
EP1859594B1 (en) Server side tftp flow control
CN106453356A (zh) 无线网络双边加速传输方法和系统
CN101686144A (zh) 一种处理数据的方法、系统和节点设备
US9749825B2 (en) Connection-oriented messaging and signaling in mobile heath networks
US9628366B2 (en) Methods, systems, and computer readable media for sustaining active control over concurrent session connections
CN110381007B (zh) Tcp加速方法及装置
CN108124504A (zh) Tfo传输方法、代理服务器和系统
CN112866133B (zh) 用于获取共用最大分段大小mss的方法及装置
KR100953005B1 (ko) 자체-적응형 멀티캐스트 파일 전송 프로토콜
JP2017034562A (ja) 通信装置および再接続方法
US20250175399A1 (en) Synchronized wireless network slicing
US11652780B2 (en) Address resolution protocol (ARP) for multi-homed devices
CN112584548A (zh) 一种隧道复用方法和核心网设备
CN118945215A (zh) 连接迁移的探测方法、装置、电子设备及存储介质
BRPI0315910B1 (pt) A method of establishing and automatically restoring a data connection on a wireless data network and mobile device to establish and maintain the same data connection