¿Hay un & # 8220; agradable & # 8221; ¿Cómo lidiar con el reensamblado de multidifusiones de múltiples fuentes?

Question

Actualmente estoy reelaborando nuestro código de envoltura de socket patentado existente para usar boost asio para que pueda hacer algo de trabajo pesado por nosotros. Quizás el área más compleja de nuestro código existente es el código de manejo de multidifusión. El código permite que nuestros servidores de nivel medio (de los cuales puedo tener muchos en un sistema) envíen multidifusiones a buzones de clientes, que los utilizan para presentar actualizaciones a los usuarios del sistema.

La razón por la cual el código es complejo y propenso a errores es que utiliza una serie de memorias intermedias sin procesar para volver a ensamblar las secuencias de multidifusión de acuerdo con su origen. Parece que incluso con Boost.Asio voy a tener que lidiar con este mismo problema, así que antes de quedar atrapado pensé que valdría la pena preguntar cómo otras personas han lidiado con esta situación.

Parece un caso de uso muy común. ¿Hay algo por ahí que pueda ayudarme a hacer este trabajo sin el tipo de código que tengo ahora? ¿O hay una plantilla C ++ establecida (Boost o de otro tipo) que puede hacer este tipo de trabajo?

Obviamente, podría facilitarme las cosas y usar contenedores STL para almacenar en búfer los paquetes en lugar de las matrices en bruto, pero este código debe tener un rendimiento realmente alto. En instalaciones grandes, hay una gran cantidad de paquetes volando y necesita responder lo más cerca posible en tiempo real.

Gracias de antemano por cualquier comentario sobre este asunto.

Jamie

Answer 1

No parece que hayas proporcionado suficiente información para respuestas detalladas, pero hay algunos consejos generales a tener en cuenta para el manejo en tiempo real de datos de multidifusión.

• Si está utilizando multidifusión UDP sin procesar, probablemente esté haciendo algún tipo de secuencia de protocolo en el espacio de usuario para tratar con paquetes perdidos o duplicados. Independientemente de las optimizaciones que desee hacer, resista la tentación de romper las capas entre su aplicación y su capa de protocolo.
• std :: vector , para la mayoría de los propósitos, es idéntico a un búfer de caracteres asignados dinámicamente sin procesar. No evite usarlo solo porque es una capa de abstracción. Sin embargo, hay dos casos en los que debe evitarlo:
  • Si puede salirse con buffers asignados estáticamente
  • Si necesita transferir la propiedad del búfer en sentido descendente (aunque si diseña con cuidado, swap () puede ser suficiente)
• La preasignación es tu amiga. Si puede tener un conjunto de buffers disponibles para su uso cuando ingresan los datos, puede eliminar la mayoría de la asignación dinámica de la ruta rápida de ejecución.
• Minimice las copias de memoria. Si puede procesar datos en una sola pila de llamadas, tiene la posibilidad de evitar copias. Si tiene que pasar datos a un hilo diferente, puede verse obligado a copiar datos.
• Si su aplicación puede manejar búferes fragmentados (en lugar de agregar todos los datos en un solo búfer), busque writev y readv .

No creo que ninguna solución enlatada resuelva sus problemas. Boost ASIO, libevent , etc. manejarán todas las abstracciones de socket por usted, pero lo que haga con sus datos sigue siendo su responsabilidad, una vez que se hayan entregado.