¿Cuál es mejor para IPC local, colas de mensajes POSIX (mqueues) o sockets de dominio Unix (locales)?

Question

¿Es mejor utilizar colas de mensajes POSIX o sockets de dominio Unix para la comunicación IPC local?

He trabajado con zócalos Unix entre máquinas (no dominio) y recuerdo que hacer y romper la conexión provocaría que los zócalos se demoraran un poco antes de que finalmente desaparecieran. Además, si quería un intercambio "confiable", tenía que usar TCP o diseñar la aplicación para devolver un ACK. No estoy seguro de si esto también se aplica a los sockets de dominio de Unix.

En mi proyecto actual, necesitamos IPC local. Mi primera reacción fue usar POSIX MQueues, ya que los he usado antes para la mensajería local. Sin embargo, un compañero de trabajo está sugiriendo enchufes de dominio Unix en su lugar.

¿Es uno mejor que el otro, o es una cuestión de familiaridad con la programación? ¿O tal vez depende de la aplicación que se está creando?

En general, la aplicación en la que estamos trabajando sigue un modelo cliente/servidor. Los clientes envían mensajes al servidor para "hacer algo". Sin embargo, el cliente no espera una respuesta de "finalización", aunque sí quiere saber si su solicitud se ha recibido o no.

La lógica básica para el lado del emisor es:

connect to server 
send request 
note if the send worked or not 
disconnect from server 

No puede haber cientos de clientes a un servidor.

Estamos ejecutando un sistema SMP (4-8 núcleos) que ejecuta el sistema operativo Linux.

Gracias de antemano.

Answer 1

Los sockets de dominio UNIX no tienen que "quedarse" en un estado similar a TIME_WAIT, ya que ese tiempo de espera se usa en caso de que haya paquetes perdidos de la conexión que deambulan por Internet. La preocupación no se aplica localmente.

Los sockets de dominio UNIX pueden ser SOCK_STREAM (como TCP) o SOCK_DGRAM (como UDP), con la garantía adicional de que los sockets de datagramas de dominio UNIX son confiables y no reordenan datagramas.

Todavía necesitará algún tipo de ACK (incluso con TCP) si quiere ser cierto que su otra aplicación haya leído el mensaje que envió; después de todo, incluso si el send() tuvo éxito, puede haberse bloqueado antes de que tuviera la oportunidad de procesar el mensaje. (Esto también se aplica a las colas de mensajes: para estar totalmente seguro de que un mensaje no se perderá, la aplicación de recepción debe escribir la solicitud en un diario, enjuagarlo en el disco y luego devolver un acuse de recibo).

Estoy de acuerdo en que la elección es esencialmente una cuestión de familiaridad con la programación.

Answer 2

¿Es uno mejor que el otro, o se trata de una cuestión de familiaridad con la programación? ¿O tal vez depende de la aplicación que se está creando?

colas de mensajes SysV en comparación con UNIX sockets de datagramas de dominio tienen las mayores diferencias yo sepa:

• Puede poll() zócalo, pero no se puede cola de mensajes.

• La cola de mensajes es global y podría (y normalmente lo hace) requerir cierta participación administrativa: la limpieza de recursos colgados SysV es una de las muchas rutinas diarias de sysadmin. Si bien la semántica del dominio UNIX es mucho más simple y las aplicaciones generalmente pueden mantenerlo completamente internamente sin la participación de administrador de sistemas.

• (?) La cola de mensajes es persistente, puede retener los mensajes de las sesiones anteriores. (No puedo recordar ese bit con precisión, pero el IIRC me estaba sucediendo más de una vez).

• En cuanto a man msgrcv No veo análogo de socket MSG_PEEK. Rara vez es necesario, pero a veces resulta bastante útil.

• La mayoría de las veces, los usuarios prefieren usar en la configuración los nombres simbólicos, no la identificación numérica de la clave. La falta de claves simbólicas IMO es una supervisión bastante grave de parte de los diseñadores de la interfaz SysV.

Al igual que con todos los recursos SysV, su gestión es la principal PITA. Si permite que el sistema decida la identificación de la cola de mensajes, entonces debe asegurarse de compartirla adecuadamente con otras aplicaciones. (Y también tiene que decirle a los administradores de alguna manera que la ID tiene que ser eliminada eventualmente). Si permite configurar la clave para la cola de mensajes, es posible que se encuentre con problemas triviales de que el ID ya está siendo utilizado por alguna aplicación o es un remanente de la ejecución anterior. (Ver que los servidores se reinician solo porque se quedan sin recursos SysV es bastante común.)

En general, evito los recursos de SysV cuando sea posible: la falta de compatibilidad con poll() en las circunstancias más comunes es un factor decisivo.

Sin embargo, el cliente no espera una respuesta "finalizada", aunque sí desea saber si su solicitud se ha recibido o no.

Ese es un dilema común del procesamiento transaccional. La respuesta general es (como en RDBMS) no se puede y después de la interrupción de la comunicación (bloqueo o lo que sea) la aplicación tiene que verificar si la solicitud ya fue procesada o no.

De eso puedo decir que probablemente TCP sería una mejor opción. El cliente envía la solicitud y la declara finalizada solo cuando obtiene una respuesta positiva del servidor. Servidor a menos que sea capaz de enviar la respuesta al cliente, tiene que deshacer la transacción.

Answer 3

Sugiero buscar en DBus para una aplicación de este tipo, aunque solo sea para la clasificación de datos y la interfaz similar a RPC (tanto síncrona como asíncrona). Utiliza conectores de dominio de forma nativa y funciona realmente bien después de una curva de aprendizaje inicial.