14
¿Cuál es la diferencia entre colas de mensajes y un conducto en Linux?Pipe vs msg queue
A
Respuesta
18
De la parte superior de mi cabeza y suponiendo que habla de colas de mensajes POSIX (no los SysV):
- tuberías no están limitados en tamaño, colas de mensajes son.
- Las tuberías se pueden integrar en sistemas que utilizan descriptores de archivos, las colas de mensajes tienen su propio conjunto de funciones, aunque Linux admite
select(),poll(),epoll()y amigos enmqd_t. - Las tuberías, una vez cerradas, requieren cierta cooperación por ambas partes para restablecerlas, las colas de mensajes se pueden cerrar y volver a abrir en cualquier lado sin la coorporación del otro lado.
- Las tuberías son planas, muy parecidas a un flujo, para imponer una estructura de mensaje. Debería implementar un protocolo en ambos lados, las colas de mensajes ya están orientadas a mensajes, no se debe tener cuidado para obtener, por ejemplo, el quinto mensaje la cola.
9
Son cosas muy diferentes, de verdad.
La mayor diferencia práctica es que una tubería no tiene la noción de "mensajes", es solo una tubería para write() bytes y read() bytes. El receptor debe tener una forma de saber qué parte de los datos constituye un "mensaje" en su programa, y debe implementarlo usted mismo. Además, se define el orden de los bytes: los bytes aparecerán en el orden en que los colocaste. Y, en términos generales, tiene una entrada y una salida.
Una cola de mensajes se utiliza para transferir "mensajes", que tienen un tipo y tamaño. Entonces el receptor puede esperar un "mensaje" con un cierto tipo, y no tiene que preocuparse si esto está completo o no. Varios procesos pueden enviar y recibir desde la misma cola.
ver man mq_overview y/o man svipc para obtener más información.
+1
incluso en la cola puede enviar cualquier estructura como mensaje, así que en este caso también el receptor debe saber "qué parte de los datos constituyen un mensaje en su programa. –
Cuestiones relacionadas
- 1. Multiproceso de Python - Pipe vs Queue
- 2. Pipe vs. archivo temporal
- 3. Message Queue vs Task Queue difference
- 4. Java NIO Pipe vs BlockingQueue
- 5. C++ deque vs queue vs stack
- 6. Message Queue vs. Web Services?
- 7. ¿Cuándo debería usar make_heap vs. Priority Queue?
- 8. Github: Fork Queue vs Pull Request
- 9. La diferencia entre Handler.dispatchMessage (msg) y Handler.sendMessage (msg)
- 10. Repository Commit Msg Etiquette
- 11. Lectura de archivos .msg
- 12. Delphi y MSG archivo
- 13. Queue <T> vs List <T>
- 14. Queue ordinario frente a SEDA Queue
- 15. Bash Pipe Handling
- 16. System.IO.Exception: Pipe está roto
- 17. SSL Broken Pipe
- 18. Pipe sed to diff
- 19. Archivo Parse .msg con C#
- 20. guardar System.Net.mail.MailMessage como archivo .msg
- 21. .msg file gives download error
- 22. ¿Qué significa msg en Mirth?
- 23. Pipe sign in Código PHP
- 24. Hibernate, C3P0, Mysql - Broken Pipe
- 25. git stderr output no pipe
- 26. Escribir a fifo (named pipe)
- 27. .Net SMTP Queue
- 28. MassTransit Queue Maintenance
- 29. WSMQ Queue Limit
- 30. Administración de TPL Queue
bien, muchas gracias ... Pero tengo una pequeña duda de que "las tuberías una vez cerradas requieren algún tipo de soporte en ambos lados", quiere resaltar el hecho de que las tuberías no son kernel persistentes y los mensajes quese .. ¿Y exactamente qué tipo de soporte se requiere para volver a conectar la tubería una vez cerrada? – mint9
@ mint9: bueno, en términos generales, debe capturar el SIGPIPE, manejarlo con elegancia y luego "volver a abrir" la tubería. Imagino que podría bifurcar() su proceso (en ambos lados), duplicar su stdin/stdout, mantener a los padres en ejecución (actúan como guardias), luego cuando está cerrado deja que sus hijos mueran (en ambos lados) y vuelva a hacer el tenedor/procedimiento dup/pipe. – hroptatyr
okie, lo tengo. Gracias – mint9