Usando ZeroMQ junto con Boost:: ASIO

Al final me di cuenta de que hay dos soluciones posibles:

• Sam Miller donde usamos el bucle de eventos de ASIO
• El bucle de eventos de ZeroMQ obteniendo los descriptores de archivo ASIO a través de los métodos .native() de acceptor y socket e insertándolos en el array de zmq_pollitem_t

He aceptado la respuesta de Sam Miller ya que para mí es la mejor solución en el caso SCGI donde constantemente se crean y terminan nuevas conexiones. Manejando así cada cambio zmq_pollitem_t array es una gran molestia que se puede evitar mediante el uso del bucle de eventos ASIO.

Obtener el socket a ZeroMQ es la parte más pequeña de la batalla. ZeroMQ se basa en un protocolo que está en capas sobre TCP, por lo que tendrá que reimplementar ZeroMQ dentro de un Boost personalizado.Asio io_service si vas por esta ruta. Me encontré con el mismo problema al crear un servicio asíncrono ENet usando Boost.Asio primero simplemente tratando de capturar el tráfico de un cliente ENet usando un Boost.Asio UDP service. ENet es un TCP como protocolo capas sobre UDP, por lo que todo lo que he logrado en ese punto era la captura de paquetes en un estado prácticamente inútil.

Aumentar.Asio está basado en plantillas, y el io_service integrado usa plantillas para básicamente envolver la biblioteca de sockets del sistema para crear el servicio TCP y UDP. Mi solución final fue crear un io_service personalizado que envolviera la biblioteca Enet en lugar de la biblioteca de sockets de sistemas, lo que le permitía usar las funciones de transporte de ENet en lugar de tener que volver a implementarlas utilizando el transporte UDP incorporado.

Lo mismo se puede hacer para ZeroMQ, pero ZeroMQ ya es una biblioteca de red de muy alto rendimiento por derecho propio que ya proporciona E/S async.Creo que puede crear una solución viable recibiendo mensajes utilizando la API existente de ZeroMQ y pasando los mensajes a un grupo de subprocesos io_service. De esta manera, los mensajes/tareas seguirán siendo manejados asincrónicamente usando Boost.El patrón del reactor de Asio sin tener que reescribir nada. ZeroMQ proporcionará la E/S asincrónica, Boost.Asio proporcionará la tarea async manipuladores / trabajadores.

El io_service existente también se puede acoplar a un socket TCP existente, lo que permite al threadpool manejar tanto TCP (HTTP en su caso) como ZeroMQ. Es totalmente posible en esta configuración que los controladores de tareas de ZeroMQ accedan a los objetos de sesión de servicios TCP, lo que le permite enviar los resultados del mensaje/tarea de ZeroMQ a un cliente TCP.

Lo siguiente es solo para ilustrar el concepto.

// Create a pool of threads to run all of the io_services.
std::vector<boost::shared_ptr<boost::thread> > threads;
for(std::size_t i = 0; i < thread_pool_size_; ++i) {
    boost::shared_ptr<boost::thread> thread(new boost::thread(boost::bind(&boost::asio::io_service::run, &io_service_)));
    threads.push_back(thread);
}

while (1) {
    char buffer [10];
    zmq_recv (responder_, buffer, 10, 0);
    io_service_.post(boost::bind(&server::handle_zeromq_message, buffer, this));
}

La solución es sondear tu io_service también en lugar de run().

Echa un vistazo a esta soluciónpara obtener información de poll().

Usar sondeo en lugar de ejecutar le permitirá sondear las conexiones de zmq sin ningún problema de bloqueo.