XMLRPCPP 异步处理多个调用?

发布于 2024-09-10 16:21:44 字数 530 浏览 6 评论 0 原文

我有一个远程服务器,它处理各种不同的命令,其中之一是事件获取方法。

如果队列中列出了 1 个或多个事件可供处理,则事件获取会立即返回。如果事件队列为空,则此方法直到几秒超时后才会返回。这样我就不会遇到任何 HTTP/套接字超时。当事件可用时,该方法立即返回。这样,客户端仅与服务器建立连接,而服务器不必与客户端建立任何连接。 这个事件机制运作良好。我正在使用 boost 库来处理队列、事件通知等。

这就是问题所在。虽然服务器阻止从事件获取方法返回,但在此期间,我无法发出任何其他命令。 在源代码 XmlRpcDispatch.cpp 中,我在“work”方法中看到一个简单的循环,它使用对“select”的阻塞调用。 似乎当一个方法的处理很忙时,没有处理其他请求。

问题:我没有看到什么吗?XmlRpcpp (xmlrpc++) 可以异步处理多个请求吗?有谁知道更好的 C++ xmlrpc 库?我不认为 Boost 库有一个组件可以让我发出远程命令? 实际上我并不关心 XML 或 over-HTTP 功能。我只需要通过 TCP 以任何形状或形式发出(异步)命令? 我期待任何人提供的任何意见。

I have a remote server which handles various different commands, one of which is an event fetching method.

The event fetch returns right away if there is 1 or more events listed in the queue ready for processing. If the event queue is empty, this method does not return until a timeout of a few seconds. This way I don't run into any HTTP/socket timeouts. The moment an event becomes available, the method returns right away. This way the client only ever makes connections to the server, and the server does not have to make any connections to the client.
This event mechanism works nicely. I'm using the boost library to handle queues, event notifications, etc.

Here's the problem. While the server is holding back on returning from the event fetch method, during that time, I can't issue any other commands.
In the source code, XmlRpcDispatch.cpp, I'm seeing in the "work" method, a simple loop that uses a blocking call to "select".
Seems like while the handling of a method is busy, no other requests are processed.

Question: am I not seeing something and can XmlRpcpp (xmlrpc++) handle multiple requests asynchronously? Does anyone know of a better xmlrpc library for C++? I don't suppose the Boost library has a component that lets me issue remote commands?
I actually don't care about the XML or over-HTTP feature. I simply need to issue (asynchronous) commands over TCP in any shape or form?
I look forward to any input anyone might offer.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

久隐师 2024-09-17 16:21:44

我在 XMLRPC 方面也遇到了一些问题,并研究了许多解决方案,例如 GSoap 和 XMLRPC++,但最终我放弃并使用 Boost.ASIOTinyXML++(后来我将 TinyXML 替换为 expat)。这实际上并没有那么多工作;我自己花了大约一周的时间完成了这个工作,从头开始,最终完全实现了许多 RPC 调用。

Boost.ASIO 取得了很好的效果。正如其名称所示,它是完全异步的,并且具有出色的性能和很少的开销,这对我来说非常重要,因为它运行在嵌入式环境 (MIPS) 中。

后来,这可能是您的情况,我将 XML 更改为 Google 的 Protocol-buffers,并且更开心了。它的 API 以及它的消息容器都是类型安全的(即,您发送一个 int 和一个 float,它永远不会转换为字符串并返回,就像 XML 的情况一样),一旦您掌握了它的窍门,这并不需要很长时间,它是非常富有成效的解决方案。

我的建议:如果你可以放弃 XML,请使用 Boost.ASIO + Protobuf
如果您需要 XML:Boost.ASIO + Expat

从头开始​​做这些事情真的值得。

I had some problems with XMLRPC also, and investigated many solutions like GSoap and XMLRPC++, but in the end I gave up and wrote the whole HTTP+XMLRPC from scratch using Boost.ASIO and TinyXML++ (later I swaped TinyXML to expat). It wasn't really that much work; I did it myself in about a week, starting from scratch and ending up with many RPC calls fully implemented.

Boost.ASIO gave great results. It is, as its name says, totally async, and with excellent performance with little overhead, which to me was very important because it was running in an embedded environment (MIPS).

Later, and this might be your case, I changed XML to Google's Protocol-buffers, and was even happier. Its API, as well as its message containers, are all type safe (i.e. you send an int and a float, and it never gets converted to string and back, as is the case with XML), and once you get the hang of it, which doesn't take very long, its very productive solution.

My recomendation: if you can ditch XML, go with Boost.ASIO + Protobuf
If you need XML: Boost.ASIO + Expat

Doing this stuff from scratch is really worth it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文