Un programa escrito en C+ que gestione sesiones Udp y las conecte con una interface Tap

Requerimientos del Proyecto:
Lenguaje de Programación:
El proyecto debe ser desarrollado en C++ y debe ejecutarse en Linux.

Uso de Hilos:
La aplicación debe aprovechar el uso de multihilos en todas las áreas donde sea necesario para garantizar un rendimiento óptimo, especialmente en la gestión de sesiones y el procesamiento de datos en tiempo real.

Comandos y Funcionalidad:
La aplicación debe ser capaz de recibir comandos internos (aún por definir) que desencadenen funciones específicas. Estos comandos deben ser definidos en un archivo de configuración y procesados por la aplicación al inicio.
Se debe proveer una interfaz de terminal de usuario que funcione a través de un Unix socket. Además, se debe crear una terminal cliente que se conecte a dicho Unix socket para enviar comandos y recibir respuestas.

Archivo de Configuración:
Al iniciar, la aplicación debe leer un archivo de configuración. Este archivo debe contener los comandos que la aplicación ejecutará al inicio, simulando el comportamiento de una terminal escribiendo comandos.

Comandos Base en la Configuración:
id {IPv4}: Asigna un identificador único para la aplicación (almacenado en un registro de 32 bits).
Tap {interface_name}: Crea una interfaz TAP para enviar y recibir datos utilizando multihilos.
Key {encryption_key}: Establece la clave de encriptación utilizada en las sesiones UDP.
Listen {listen_ip} {start_port} {end_port} {num_sessions}: Establece un rango de puertos para escuchar peticiones de datos. Además, se define el número de sesiones a generar para cada llamada connect.
Connect {destination_ip} {start_port} {end_port} {always}: Define un rango de puertos en el destino. Por cada puerto de listen, se establece una conexión. La ip de origen y el puerto de origen son seleccionados aleatoriamente dentro de los rangos definidos por listen, y la ip de destino y el puerto de destino son seleccionados aleatoriamente dentro del rango definido en connect. Si always es 1, la conexión intentará reconectar automáticamente si se pierde; si es 0, intentará reconectar solo durante 30 segundos.

Protocolos y Compresión:
Las sesiones udp deben usar un algoritmo de compresión lzo de nivel 9, aplicable solo al payload.
El encabezado de los paquetes UDP debe reservar bits para el control de sesión.
La clave de encriptación proporcionada debe ser procesada mediante sha-256, luego se aplica el algoritmo xor para encriptar los datos.
Si los datos superan el tamaño del paquete soportado ( previamente negociado en el inicio de sesión ), se deben dividir (split) en fragmentos utilizando los bits de control, el tamaño máximo es de un MTU 9000.

Sesiones UDP:
Se medirá la latencia de la sesión udp utilizando el tiempo de ida y vuelta de los paquetes (rtt).
El último valor de latencia se almacenará en un registro para su posterior análisis y uso en el algoritmo de balanceo de tráfico.
Se realizará un seguimiento de los últimos 100 paquetes enviados y recibidos por la sesión.
Si se detecta una pérdida de paquetes, se calculará el porcentaje de pérdida basándose en el número de paquetes perdidos en los últimos 100 paquetes.
El costo de la sesión se calculará utilizando la fórmula:
costo = latencia (ms) * (1 - porcentaje de pérdida de paquetes)
Si el parámetro always es 1, la conexión intentará reconectar automáticamente si se pierde, utilizando un puerto aleatorio tanto para el origen como para el destino dentro de los rangos definidos.
Si el parámetro always es 0, la reconexión solo se intentará durante 30 segundos, y si no se puede establecer la conexión dentro de ese tiempo, se abandona el intento.

Balanceo de Paquetes:
El algoritmo de balanceo de paquetes priorizará las sesiones con la menor latencia, siempre y cuando la pérdida de paquetes no sea superior a un umbral aceptable.
Si el porcentaje de pérdida de paquetes es alto en una sesión, esta será descartada o utilizada con un mayor costo en el balanceo de carga.

Manejo de Tráfico a través de TAP:
El tráfico recibido en la interfaz TAP debe ser procesado de la siguiente manera:
Tráfico Broadcast y Multicast:
Si la MAC de destino es de tipo broadcast o multicast, el tráfico se enviará a todos los destinos correspondientes.
Se enviará solo por una sesión de esa ID, manteniendo el balanceo.
Tráfico Unicast (mac registrada en la tabla arp):
si la mac de destino está registrada en la tabla arp y asociada a un id, se seleccionará la sesión correspondiente.
La selección de la sesión se realizará utilizando el criterio de menor latencia, siempre y cuando el porcentaje de pérdida de paquetes no sea excesivo (según lo determinado por el algoritmo de balanceo de carga).
En caso de que haya varias sesiones con una latencia similar, se priorizará aquella con el menor porcentaje de pérdida de paquetes.

Balanceo de Paquetes:
El algoritmo de balanceo de paquetes priorizará las sesiones con la menor latencia, siempre y cuando la pérdida de paquetes no sea superior a un umbral aceptable.
Si el porcentaje de pérdida de paquetes es alto en una sesión, esta será descartada o utilizada con un mayor costo en el balanceo de carga.
El costo de la sesión será calculado previamente utilizando la fórmula:
costo = latencia (ms) * (1 - porcentaje de pérdida de paquetes)
Las sesiones con menor costo (calculado a partir de la latencia y el porcentaje de pérdida de paquetes) serán priorizadas en el balanceo de tráfico.
En caso de que varias sesiones tengan una latencia similar, el costo basado en el porcentaje de pérdida de paquetes se utilizará para determinar cuál debe ser priorizada, favoreciendo aquella con menor costo.

Manejo de Conexiones y Multi-Hilo:
Tanto las conexiones de listen como las de connect pueden ser múltiples. Cada uno debe ejecutarse en hilos independientes para gestionar el transmit (tx) y receive (rx) de manera concurrente y eficiente.