SunRPC 启用单向消息传递(流/批处理?)

发布于 2024-09-17 01:05:49 字数 396 浏览 10 评论 0原文

我们有一些在 Linux (RHEL 4/5) 上使用 SunRPC 的服务,我们希望加快速度。

我们的 RPC 调用不需要返回值,但由于 RPC 的本质,无论如何总是会发送 ack。这引入了最近成为一个问题的延迟 - 当在可靠传输 (TCP) 上运行时,我们希望避免 RPC 回复引入的延迟。

文档此处表示 Solaris 有“oneway”关键字就可以实现这一点,尽管 Linux/glibc 似乎不支持这一点。

有没有一种方法可以在 Linux 上使用 SunRPC 启用“流式”或单向消息传递?

We have some services utilizing SunRPC on Linux (RHEL 4/5) that we'd like to speed up.

Our RPC call require no return value, though by the nature of RPC, an ack is always sent anyway. This introduces latency that's recently become a problem - when run over a reliable transport (TCP), we'd hope to avoid the latency introduced by the RPC reply.

Docs here indicates Solaris has the "oneway" keyword enabling just that, though Linux/glibc does not seem to support this.

Is there any way we can enable "streaming" or one-way messaging with SunRPC on Linux ?

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

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

发布评论

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

评论(2

甜点 2024-09-24 01:05:49

为了获得异步(或“批量”)RPC 调用,必须对标准 clnt_call() 调用进行两项更改:参数是指向回复数据的 XDR 函数的指针-结构必须为NULL并且超时参数必须为零,即

static struct timeval ZERO_TIMEOUT = { 0, 0 };
static char clnt_res;
memset((char*)&clnt_res, 0, sizeof(clnt_res);
if (clnt_call(clnt, messageType, (xdrproc_t)xdr_messageType_t, (caddr_t)argp,
            (xdrproc_t)NULL, (caddr_t)&clnt_res, ZERO_TIMEOUT) != RPC_SUCCESS) {
    ...
}

There are two changes that must be made to the standard clnt_call() invocation in order to obtain an asynchronous (or "batched") RPC call: the argument that's the pointer to the XDR function for the reply data-structure must be NULL and the timeout argument must be zero, i.e.,

static struct timeval ZERO_TIMEOUT = { 0, 0 };
static char clnt_res;
memset((char*)&clnt_res, 0, sizeof(clnt_res);
if (clnt_call(clnt, messageType, (xdrproc_t)xdr_messageType_t, (caddr_t)argp,
            (xdrproc_t)NULL, (caddr_t)&clnt_res, ZERO_TIMEOUT) != RPC_SUCCESS) {
    ...
}
公布 2024-09-24 01:05:49

如果您的 RPC 库不支持“单向”通信,那么您始终可以使用线程池模式 在程序中模拟“即发即忘”类型的调用。您不是直接发送远程调用(从而阻塞直到收到答案),而是将 命令 排入队列它在不同的线程中进行远程调用,并允许主程序继续执行。

If your RPC library does not support the "oneway" communication, then you can always use the Thread Pool Pattern to emulate the "fire and forget" kind of invocation in your program. Instead of sending the remote call directly (and thus blocking until you receive an answer) you enqueue a command that does the remote call in a different thread and allows you main program to continue with it's execution.

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