Uso de colas de mensajes POSIX en lugar de sockets TCP: ¿cómo establecer & # 8220; connection & # 8221 ;?

Question

Tengo programas de cliente y servidor que ahora se comunican a través de TCP. Estoy probando con las colas de mensajes POSIX en su lugar (en los casos en que el cliente y el servidor están en la misma máquina, por supuesto). Mi esperanza es que mejorará el rendimiento (específicamente a través de una latencia reducida).

He resuelto la mayor parte del proceso, pero no estoy seguro de una cosa: cómo establecer la conexión " " El servidor acepta conexiones de varios clientes al mismo tiempo, por lo que estoy tentado de emular el proceso de establecimiento de la conexión TCP de este modo:

1. El servidor abre una cola con un nombre conocido y lo lee continuamente (puede usar select (2) como con TCP).
2. El cliente abre tres colas: dos con nombres arbitrarios (incluidas algunas características únicas, como PID para evitar colisiones), y una con el nombre conocido que usa el servidor.
3. El cliente publica un " conectar " mensaje a la cola del servidor, incluidos los nombres de la cola del cliente (uno está designado para el tráfico de cliente a servidor y el otro para el contrario).
4. El servidor abre las colas nombradas en el mensaje de conexión del cliente y comienza a leer (seleccionar) del cliente al servidor.
5. El cliente cierra la cola del servidor con el nombre conocido. La comunicación bidireccional se realiza utilizando las dos colas nombradas por el cliente (una para cada dirección).

Probablemente pueda ver cómo este esquema es similar al método TCP común, y eso no es accidental. Sin embargo, me gustaría saber:

1. ¿Puedes pensar en una mejor manera de hacerlo?
2. ¿Ves algún problema potencial con mi método?
3. ¿Tiene alguna otra idea, incluida la posibilidad de que el uso de colas de mensajes en lugar de TCP en la misma máquina realmente mejore el rendimiento (latencia)?

Tenga en cuenta que no he usado las colas de mensajes POSIX antes (usé IBM WebSphere MQ hace un tiempo, pero eso es bastante diferente). La plataforma es Linux.

Answer 1

Terminé implementándolo básicamente como lo describí, con algunas mejoras:

• En el paso 2, usé GUID para los nombres de cola en lugar de incorporar el PID del cliente.
• En el paso 4, agregué el envío de un " aceptar " mensaje del servidor al cliente.
• Cuando cualquiera de las partes desea finalizar la comunicación, envía un " desconectar " mensaje.

El protocolo de enlace es más simple que TCP, pero parece suficiente.

En cuanto a la latencia: es mucho mejor. Aproximadamente un 75% menos de latencia mediante las colas de mensajes POSIX en lugar de TCP en la misma máquina. Mis mensajes son del orden de 100 bytes cada uno.

Answer 2

1.   

   ¿Puedes pensar en una mejor manera de hacerlo?

   Quizás eche un vistazo a fifos (también conocido como pipe). Son como sockets de red pero para la máquina local. Son unidireccionales, por lo que es posible que necesite crear dos, uno para cada dirección. Su pregunta no tiene ninguna razón de por qué está haciendo este cambio específicamente. No hay nada de malo en usar sockets para procesar el proceso de comunicación. Son bidireccionales, eficientes, cuentan con un amplio respaldo y le brindan la libertad de separar los procesos entre las máquinas más adelante.

2.   

   ¿Ves algún problema potencial con mi método?

   Las colas de mensajes de System V y las canalizaciones con quince nombres están absolutamente bien. Las canalizaciones de Fifo son como las tuberías normales, por lo que puede leer () y escribir () con cambios mínimos de código. Las colas de mensajes de System V requieren colocar los datos en una estructura e invocar a msgsnd (). Sin embargo, cualquier enfoque estaría bien.

3.   

   ¿Tiene alguna otra idea, incluida la posibilidad de que el uso de colas de mensajes en lugar de TCP en la misma máquina realmente mejore el rendimiento (latencia)?

   Mis otros pensamientos son que, como dijiste, necesitas desarrollar una técnica para que cada cliente tenga un identificador único. Un enfoque sería agregar el pid a la estructura por la que pasa o negociar una identificación única con el padre / maestro al principio. La otra cosa a tener en cuenta es que la ventaja de las colas de mensajes del Sistema V es que escucha " selectivo " mensajes, por lo que idealmente podría usar una cola del servidor para todos los clientes, con cada cliente esperando un mensaje diferente.

   No tengo idea de qué técnica le brinda el rendimiento más óptimo en su software. Es posible que no valga la pena utilizar las colas de mensajes del Sistema V, pero solo usted puede tomar esa decisión.

Philluminati

Answer 3

Comparé el rendimiento de posix MQ y un par de sockets TCP / IP.

El programa de demostración tiene dos hilos, uno para escribir y el otro para leer.

El resultado es que posix MQ es más rápido,

• MQ 460000 tps
• socketpair 400000 tps

Answer 4

He encontrado un problema similar, desarrollo aplicaciones en tiempo real y necesito una técnica IPC con una funcionalidad similar a la de sockets y una latencia mínima.

¿Ha comparado su solución basada en POSIX-MQ con sockets locales UNIX o sockets TCP?

Gracias

Answer 5

¿Cómo hizo esto cuando select () no funciona en las colas de mensajes? ¿Qué es Sys V o POSIX? ¿Por qué hacer un esfuerzo adicional para crear una tabla de búsqueda de GUID a PID cuando se garantiza que PID es único y es un almacenamiento más pequeño (entero)?

/ blee /

Answer 6

También puede usar Message Queue para IPC en programas que residen en diferentes máquinas, en tales casos puede usar ZeroMQ ( http: //www.zeromq.org ) u otras API de cola de mensajes, también le sugiero que las considere y las pruebe también.