topología de red sugerida para esta aplicación de transmisión de datos/comando más bien pequeña?

Question

Estamos armando un sistema que lee ~ 32 señales de voltaje a través de una tarjeta convertidora de analógico a digital, hace un procesamiento preliminar en ellas, y pasa los resultados (aún separados en 32 canales) a la red como paquetes UDP, donde son recogidos por otra computadora y diversamente (a) se muestran, (b) se procesan más, (c) buscan criterios para cambiar el estado del sistema de adquisición, o (d) alguna combinación de AC. Simultáneamente, se está ejecutando un proceso GUI en la computadora que realiza estos últimos procesos (la computadora vis), que cambia el estado tanto en la computadora generadora de datos como en los procesos múltiples de la computadora vis, a través de mensajes de comando empaquetados por UDP.

Soy nuevo en la programación de redes y estoy luchando para elegir una topología de red. ¿Hay alguna heurística (o capítulos de libros, documentos) sobre la topología de red para aplicaciones relativamente pequeñas que la necesidad de pasar datos, comandos y acuses de recibo de forma flexible?

detalles del sistema:

• adquisición de datos sin procesar que ocurre en una sola máquina Linux. Simplemente procesar los datos, guardarlos en el disco y enviarlos a la red utiliza aproximadamente el 25% de la capacidad de la CPU y una pequeña cantidad de memoria. Menos de 0.5 Mb/seg de datos van a la red. Todo el código para la generación de datos está en C++.

• Otra máquina Linux ejecuta varios procesos de visualización/procesamiento/GUI. La GUI controla tanto la máquina de adquisición como los procesos en la computadora vis/processing/GUI misma. Este código se encuentra principalmente en C++, con un par de pequeñas utilidades en Python.

• Vamos a escribir otras aplicaciones que deseen escuchar los datos sin procesar, los datos procesados ​​y todos los comandos que se pasan; esas aplicaciones también querrán emitir comandos; no podemos anticipar cuántos de esos módulos queremos escribir, pero esperamos 3 o 4 procesos de datos pesados ​​que transformen los 32 flujos de entrada en una sola salida; así como 3 o 4 pequeñas aplicaciones únicas como un "registrador de comandos". El requisito de modularidad significa que queremos que los viejos generadores de datos y emisores de comandos sean agnósticos sobre cuántos oyentes hay por ahí. También queremos que los comandos sean reconocidos por sus destinatarios.

• Las dos máquinas están conectadas por un interruptor, y los paquetes (datos y comandos, y confirmaciones) se envían en UDP.

Los cinco posibilidades que estamos pensando:

1. flujos de datos, comandos y reconocimientos son el blanco de número de puerto. El generador de datos envía flujos de datos independientes como paquetes UDP a diferentes números de puerto vinculados por procesos de visualización independientes en la computadora de visualización. Cada proceso también vincula un puerto de escucha para los comandos entrantes, y otro puerto para los acuses de recibo entrantes a los comandos salientes. Esta opción parece buena porque el kernel hace el trabajo de traficar/filtrar los paquetes; pero malo porque es difícil ver cómo los procesos se dirigen entre sí frente a los módulos agregados imprevistos; también parece conducir a una explosión de puertos encuadernados.

2. Las secuencias de datos se dirigen a sus respectivos visualizadores por número de puerto, y cada proceso enlaza un puerto para escuchar los comandos. Pero todos los emisores de comandos envían sus comandos a un proceso de reenvío de paquetes que conoce los puertos de entrada de todos los procesos y reenvía cada comando a todos ellos. Los reconocimientos también se envían a este puerto universal de comando y se envían a todos los procesos.Embalamos información sobre el objetivo previsto de cada comando y cada confirmación en los paquetes de comando/ack, por lo que los procesos mismos tienen que examinar todos los comandos/acks para encontrar los que pertenecen a ellos.

3. El proceso de envío de paquetes también es el objetivo de todos los paquetes de datos. Todos los paquetes de datos y todos los paquetes de comandos se envían a quizás 40 procesos diferentes. Obviamente, esto genera mucho más tráfico en la subred; también limpia la explosión de puertos encuadernados.

4. Dos paquetes-distribuidores podrían funcionar en la computadora de vis - uno difunde comandos/ack a todos los puertos. El otro difunde datos solo a los puertos que posiblemente deseen datos.

5. Nuestros 32 procesos de visualización se pueden agrupar en 1 proceso que extrae datos para las 32 señales, lo que reduce en gran medida el tráfico adicional que causa la opción 3.

Si usted ha experimentado con los datos que pasan alrededor de entre múltiples procesos en un pequeño número de máquinas, y tienen algo de sabiduría o reglas generales sobre qué estrategias son robustos, lo agradecería enormemente el consejo! (las solicitudes de aclaración en las fotos son bienvenidas)

Answer 1

No tengo suficientes representantes para mover esta pregunta a programmers.stackexhange.com, así que la responderé aquí.

Primero le arrojaré algunas tecnologías, cada una de las cuales debe consultar.

• Hadoop A map-reduce framework. La capacidad de tomar una gran cantidad de datos y procesarlos a través de nodos distribuidos.

• Kafka Un sistema de mensajería de alto rendimiento. Sugeriría ver esto como su bus de mensajes.

• ZooKeeper Un sistema distribuido que le permite "descubrir" todos los diferentes aspectos de su sistema distribuido. Es un sistema de coordinación que se distribuye

• Pub/Sub Messaging

• ∅mq Otra biblioteca socket que permite pub/mensajería sub y otras disposiciones de paso de mensajes N-a-N.

Ahora que le he lanzado algunas tecnologías, le explicaré lo que haría.

Cree un sistema que le permita crear N conectores. Estos conectores pueden manejar Datos/Comando N en su diagrama, donde N es una señal específica. Es decir, si tenía 32 señales, puede configurar su sistema con 32 conectores para "conectar". Estos conectores pueden manejar comunicaciones bidireccionales. De ahí su problema de recibir/comando. Un solo conector publicará sus datos en algo como Kafka sobre un tema específico de esa señal.

Utilice un sistema de publicación/suscripción. Esencialmente, lo que sucede es que los conectores publican sus resultados a un tema específico. Este tema es algo que eliges. Luego los procesadores, ya sea UI, lógica de negocios, etc. escuchan un tema específico. Estos son todos arbitrarios y puede configurarlos como desee.

============   =============  =====  ============  ============= 
= Signal 1= < --- > = Connector = < -- = K = --> = "signal 1" ---> = Processor = 
============   =============  = a =  ============  ============= 
             = f = 
============   =============  = k =  ============  ============= 
= Signal 2= < --- > = Connector = < -- = a = --> = "signal 2" ---> = Processor = 
============   =============  = =  ============ | ============= 
             = =     | 
============   =============  = =  ============ | 
= Signal 3= < --- > = Connector = < -- = = --> = "signal 3" --- 
============   =============  =====  ============  

En este ejemplo, el primer conector "publica" Es resultados al tema "señal 1" en el que el primer procesador está escuchando en ese tema. Cualquier información enviada a ese tema se envía al primer procesador. El segundo procesador está escuchando los datos de "señal 2" y "señal 3". Esto representa algo así como una interfaz de usuario que recupera diferentes señales al mismo tiempo.

Una cosa a tener en cuenta es que esto puede suceder en cualquier tema que elija. Un "procesador" puede escuchar todos los temas si lo considera importante.