El día 1 de septiembre de 2008 14:06, Herr Groucho <[EMAIL PROTECTED]> escribió: > Correcto, da lo mismo que el retardo para tener el dato en el sistema > fluctue 5 o 10 min, en tanto la velocidad promedio de lectura sea > tanto o más alta que la velocidad de generación de los datos.
Suena a neurona. Puede que esté dando algunos palos de ciego... si es así, aplica tortura. Posiblemente puedes tener un template del dato (un poco como lo hace Message Passing Interface), y transmitir la menor cantidad de cosas por la red. De esa manera, reduces en mucho la cantidad de datos a transmitir (y que es en base el por qué no se recomienda XML como arquitectura para sistemas orientados a datos). > No entendés. Mientras me tomé media hora para traer 1 bloque de datos > de cada módulos, se generaron 30/5=6 bloques de datos nuevos en cada > módulo, que me va a llevar más de media hora leerlos y así cuesta > abajo. Suena a que debes transmitir valores específicos por la vía UDP con un UDP status de vuelta cada una cierta cantidad de datagramas, mencionando qué datagramas se pierden. Sí, programado eficientemente es menos lento que TCP. No trates de usar los netpipes porque éstos son TCP. > El problema típico es que se pierda enlace con algún módulo y cuando > vuelva a estar en línea haya que traer datos atrasados. Por eso el UDP de vuelta. Me suena a poner dos o más equipos procesando la cantidad de datos. Si pones unos tres equipos recibiendo datos, podrías generar una mayor tolerancia a fallos y compartirlos internamente a través de una red más grande (posiblemente un clúster en que se dividan las tareas de procesamiento; vuelvo a pensar en OpenMPI y OpenSSI, pero depende de tu servidor la estrategia a usar). Saludos, -- Rodrigo Fuentealba Concepción, Chile
