gpt4 book ai didi

ipc - 有没有像 DBus 那样具有信号功能的 RPC 框架?

转载 作者:行者123 更新时间:2023-12-02 00:25:12 26 4
gpt4 key购买 nike

我们目前正在寻找RPC框架,但遗憾的是无法找到任何具有信号功能的框架,但我们需要它。我们研究了 gRPCApache ThriftCap-n-Proto,发现它们都没有像 DBus 那样提供开箱即用的功能做。值得一提的是,我们需要它作为IPC。另外,我们还需要监视 1 个以上的套接字,因此一个用于 RPC 服务器,另一个用于另一台服务器。在 DBus 中,我们可以将其添加到 glib 的主循环中。我们的目标 RPC 必须允许这样做。

附注DBus 并不是我们真正需要的,因为我们只需要客户端-服务器架构,而不是客户端-总线-守护进程。

P.P.S。关于离题 - 我认为这个问题没有什么需要固执己见的答案。答案应该包含事实,但不包含观点。

最佳答案

信号可以通过几种不同的方式在 Cap'n Proto 之上实现。

对象链

Cap'n Proto RPC 调用需要很长时间才能完成是没有问题的。同一连接上的其他调用可以正常继续,并且您一次可以有多个未完成的调用。因此,接收信号的一种策略是让调用在返回之前等待信号。

许多 RPC 系统支持挂起调用,但还有一个额外的挑战:如果您有信号流,并且客户端观察流中的每个信号非常重要,那么如果有新信号,事情就会变得复杂信号的生成速度比客户端调用 RPC 读取信号的速度要快。您需要为每个客户端保留一个缓冲区。但是如果客户端死亡并停止发出请求怎么办?现在您需要某种超时,然后清除它。

与大多数其他 RPC 系统不同,Cap'n Proto 支持动态生成新对象。因此,您可以将信号流表示为对象链。例如:

struct MyPayload { ... }

interface MyInterface {
subscribe @0 () -> (firstSignal :Signal(MyPayload));
# Subscribe to signals from this interface.
}

interface Signal(Type) {
# One signal in a stream of signals. Has a payload, and lets you
# wait for the next signal.

get @0 () -> (value :Type);
# Gets the payload value of this signal. (Returns immediately.)

waitForNext @1 () -> (nextSignal :Signal(Type));
# Waits for the next signal in the sequence, returning a new
# `Signal` object representing it.
}

这极大地简化了服务器端的状态管理,因为一旦所有客户端都表明它们已完成使用,Cap'n Proto 就会自动调用每个对象的析构函数(通过销毁客户端引用,也称为“删除”它) )。如果客户端断开连接,则其所有引用都会隐式删除。

回调

由于 Cap'n Proto 允许双向 RPC 调用(客户端 -> 服务器和服务器 -> 客户端),因此您可以使用回调实现“信号”或发布/订阅机制:

struct MyPayload { ... }

interface MyInterface {
subscribe @0 (cb :Callback(MyPayload)) -> (handle :Handle);
}

interface Callback(Type) {
call @0 (value :Type);
}

interface Handle {}

客户端调用subscribe()并传递回调对象cb。然后,只要有信号,服务器就可以回调客户端。

请注意,subscribe() 返回一个Handle,它是一个没有方法的对象。这样做的目的是检测客户端何时取消订阅。如果客户端删除handle,服务器将收到通知(服务器端对象的析构函数将运行),然后服务器可以取消注册回调。这也可以处理客户端断开连接的情况——所有对象引用都会在断开连接时隐式删除​​。

乍一看,由于其简单性,该解决方案可能看起来比对象链解决方案好得多。但是,它存在一个问题,即您现在有指向两个方向的对象引用,这可能会导致循环。在客户端代码中,您必须小心确保回调实现不会“拥有”保持其注册的句柄,否则它将永远不会被清理(除非连接关闭)。您还必须确保在删除句柄后的短时间内仍可以调用回调,同时等待服务器取消注册回调。这些问题在对象链解决方案中不存在,这可能会使该解决方案的实现更加清晰。

其他 RPC 系统

我在上面讨论了 Cap'n Proto,因为我是作者,而且它提供了比大多数 RPC 系统更多的选项。

如果你使用gRPC,你可以使用它的“流”功能来支持信号之类的东西。流式 RPC 可以随着时间的推移返回多个响应。

我不确定 Thrift 的情况。上次我尝试时,请求必须是 FIFO,这意味着长时间运行的 RPC 是禁忌。然而,那是很久以前的事了,也许从那时起它已经改变了。

关于ipc - 有没有像 DBus 那样具有信号功能的 RPC 框架?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41677473/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com