在消息队列上使用管道进行基于消息的通信

Posted 2023-02-16

【中文标题】在消息队列上使用管道进行基于消息的通信

【英文标题】：Using pipes over message queues for message-based communication

【发布时间】：2021-12-28 12:40:17

【问题描述】：

有一个进程间通信用例，即两个相关进程需要相互通信请求/响应（固定结构消息），不需要对请求进行优先级排序。 据我了解，由于这是基于消息的通信，因此使用消息队列更方便。但是我遇到了一些使用管道的实现（它们构造消息头以便能够通过字节流打包/解包消息）。

所以我的问题是，在这个用例中（或者在一般的基于消息的通信中）使用管道而不是消息队列有什么好处，这只是一个糟糕的设计，还是有一些好处可以克服添加代码的成本通过字节流打包/解包消息？

【问题讨论】：

over message queues“消息队列”在你的文中是一个抽象的术语，还是你具体指的是关于POSIX的mq_open()接口？您可以通过管道实现“消息队列”（例如 MQTT）。

我指的是 POSIX（或 System V）消息队列

【参考方案1】：

让我们试着做一个简短的表格。

pipe()	POSIX mq_*
less resources, simple	more complicated
always available just everywhere	needs CONFIG_POSIX_MQUEUE Linux Kernel option
easy to use, known and used everywhere	almost forgotten nowadays and specific use cases
messages less than PIPE_BUF (4096 on linux, at least 512) are guaranteed be written/read in one go	builtin messages boundaries
just a fifo	builtin priorities of messages, the most important get's delivered first
you can use poll/select	You can't use poll/select. (Except you can on Linux, not portable).
auto-cleanup	auto-cleanup after unlink() / needs synchronization of processes to do proper cleanup
standard way of sharing a channel between forks / is local to the process	can communicate between unrelated processes / the name is global, unix permissions access appplies
ulimit -n (/etc/security/limits.conf) limit open file descriptors	NAME_MAX limits the name (and mqd_t is also file descriptor on linux)
	need to link with rt when compiling
can be connected to standard streams	requires special mq_* interface
uses read/write syscalls	uses special mq_* syscall (on Linux)