开发者

SunRPC enable one way messaging (streaming / batching?)

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 th开发者_Python百科is.

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


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) {
    ...
}


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.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜