将 ZeroMQ 与 Boost::ASIO 一起使用
我有一个使用 ZeroMQ 进行消息传递的 C++ 应用程序.但它还必须为基于 AJAX/Comet 的 Web 服务提供 SGCI 连接.
I've got a C++ application that is using ZeroMQ for some messaging. But it also has to provide a SGCI connection for an AJAX / Comet based web service.
为此，我需要一个普通的 TCP 套接字.我可以通过普通的 Posix 套接字做到这一点，但为了保持跨平台的便携性并使我的生活更轻松(我希望......)我正在考虑使用 Boost::ASIO.
For this I need a normal TCP socket. I could do that by normal Posix sockets, but to stay cross platform portable and make my life easier (I hope...) I was thinking of using Boost::ASIO.
但现在我有 ZMQ 的冲突，想要使用它自己的 zmq_poll() 和 ASIO 它是 io_service.run()...
But now I have the clash of ZMQ wanting to use it's own zmq_poll() and ASIO it's io_service.run()...
有没有办法让 ASIO 与 0MQ zmq_poll() 一起工作?
Is there a way to get ASIO to work together with the 0MQ zmq_poll()?
或者是否有其他推荐的方法来实现这样的设置?
Or is there an other recommended way to achieve such a setup?
注意:我可以通过使用多线程来解决这个问题――但它只是一个小小的单核/CPU 盒子，它可以以非常低的 SCGI 流量运行该程序，所以多线程会浪费资源......
Note: I could solve that by using multiple threads - but it's only a little single core / CPU box that'll run that program with a very low amount of SCGI traffic, so multithreading would be a waste of resources...
推荐答案
阅读文档后 这里和这里，特别是这一段
After reading the documentation here and here, specifically this paragraph
ZMQ_FD:检索与套接字关联的文件描述符 ZMQ_FD选项应检索与关联的文件描述符指定的套接字.返回的文件描述符可用于将套接字集成到现有的事件循环中；?MQ 库应以边缘触发的方式向套接字上的任何未决事件发出信号通过使文件描述符准备好读取来实现时尚.
ZMQ_FD: Retrieve file descriptor associated with the socket The ZMQ_FD option shall retrieve the file descriptor associated with the specified socket. The returned file descriptor can be used to integrate the socket into an existing event loop; the ?MQ library shall signal any pending events on the socket in an edge-triggered fashion by making the file descriptor become ready for reading.
我认为您可以为每个 zmq_pollitem_t 使用 null_buffers并将事件循环推迟到 io_service，完全绕过 zmq_poll().然而，上述文档中似乎有一些警告，特别是
I think you can use null_buffers for every zmq_pollitem_t and defer the event loop to an io_service, completely bypassing zmq_poll() altogether. There appear to be some caveats in the aforementioned documentation however, notably
从返回的文件描述符中读取的能力不必然表明消息可供读取，或可以写入，底层套接字；应用程序必须检索实际事件状态，随后检索 ZMQ_EVENTS选项.
The ability to read from the returned file descriptor does not necessarily indicate that messages are available to be read from, or can be written to, the underlying socket; applications must retrieve the actual event state with a subsequent retrieval of the ZMQ_EVENTS option.
因此，当您的一个 zmq 套接字的处理程序被触发时，您必须在处理我认为的事件之前做更多的工作.未编译的伪代码如下
So when the handler for one of your zmq sockets is fired, you'll have to do a little more work before handling the event I think. Uncompiled pseudo-code is below
const int fd = getZmqDescriptorSomehow();
boost::asio::posix::stream_descriptor socket( _io_service, fd );
socket->async_read_some(
boost::asio::null_buffers(),
[=](const boost::system::error_code& error)
{
if (!error) {
// handle data ready to be read
}
}
);
注意你不必在这里使用 lambda，boost::bind 到成员函数就足够了.
note you don't have to use a lambda here, boost::bind to a member function would be sufficient.
相关文章