Y gracias por echar un vistazo a la pregunta.

El fondo
Tengo varias máquinas que generan continuamente scripts de consola de PHP múltiples (hasta 300) en un período de tiempo muy corto. Estos scripts se ejecutan rápidamente (menos de un segundo) y luego salen. Todos estos scripts necesitan acceso de solo lectura a una grantrie estructura que sería muy costosa de cargar en la memoria cada vez que se ejecuta cada uno de los scripts. El servidor ejecuta Linux.

Mi solución
Cree un demonio C que mantenga la estructura de trie en la memoria y reciba solicitudes de los clientes PHP. Recibirá una solicitud de cada uno de los clientes de PHP, realizará la búsqueda en la estructura de la memoria y responderá con la respuesta, evitando que los scripts de PHP hagan ese trabajo. Tanto las solicitudes como las respuestas son cadenas cortas (no más de 20 caracteres)

Mi problema
Soy muy nuevo en C daemons y la comunicación entre procesos. Después de mucha investigación, he reducido las opciones a Message Queues y sockets de dominio Unix. Las colas de mensajes parecen adecuadas porque creo (puedo estar equivocado) que ponen en cola todas las solicitudes para que el daemon las responda en serie. Sin embargo, los sockets de dominio Unix parecen ser más fáciles de usar. Sin embargo, tengo varias preguntas que no he podido encontrar respuestas a:

¿Cómo puede un script PHP enviar y recibir mensajes o usar un socket UNIX para comunicarse con el daemon? A la inversa, ¿cómo realiza el daemon C un seguimiento de a qué proceso PHP debe enviar una respuesta?La mayoría de los ejemplos de demonios que he visto utilizan un bucle infinito mientras que tiene una condición de sueño en su interior. Mi daemon necesita atender muchas conexiones que pueden llegar en cualquier momento, y la latencia de respuesta es crítica. ¿Cómo reaccionaría el demonio si el script PHP envía una solicitud mientras está durmiendo? He leído sobre encuestas y comentarios, ¿sería esta la manera correcta de esperar un mensaje recibido?Cada proceso de PHP siempre enviará una solicitud y luego esperará para recibir una respuesta. Necesito asegurarme de que si el daemon está inactivo / no disponible, el proceso PHP esperará una respuesta por un tiempo máximo establecido, y si no se recibe una respuesta, continuará independientemente en lugar de colgarse. Se puede hacer esto?

La búsqueda real de la estructura de datos es muy rápida, no necesito ningún subproceso múltiple complejo o solución similar, ya que creo que con el manejo de las solicitudes de manera FIFO será suficiente. También necesito mantenerlo simple y estúpido, ya que este es un servicio de misión crítica y soy bastante nuevo en este tipo de programa. (Lo sé, pero realmente no tengo forma de evitar esto, y la experiencia de aprendizaje será excelente)

Realmente agradecería fragmentos de código que iluminen un poco las preguntas específicas que tengo. Los enlaces a guías e indicadores que me ayudarán a comprender mejor este mundo turbio de IPC de bajo nivel también son bienvenidos.

¡Gracias por tu ayuda!

Actualizar

Sabiendo mucho más ahora que yo al momento de hacer esta pregunta, solo quería señalar a cualquier persona interesada que tantoAhorro marco yZeroMQ haga un trabajo fantástico de abstraer la programación difícil, a nivel de socket. ¡Thrift incluso te da los andamios para el servidor de forma gratuita!

De hecho, en lugar de continuar con el arduo trabajo de construir un servidor de red, considere simplemente escribir su código de servidor de aplicaciones usando un buen servidor asíncrono que ya haya resuelto el problema por usted. Por supuesto, los servidores que utilizan E / S asíncronas son excelentes para las aplicaciones de red que no requieren un procesamiento intensivo de la CPU (o los bloques de bucle de eventos).

Ejemplos para python:Retorcido, gevent. Prefiero gevent, y no incluyo tornado porque está enfocado en el lado del servidor HTTP.

Ejemplos para Ruby:Máquina de eventos

Por supuesto,Node.js es básicamente la opción predeterminada para un servidor asíncrono hoy en día.

Si quieres profundizar, lee elProblema C10kyProgramación de red Unix.