2017-10-11 64 views
0

我正在尝试在现有项目中使用Cap'n Proto,该项目由通过UDS进行通信的客户端和服务器组成。我没有资源(我怀疑它会被接受)重做所有客户端 - 服务器RPC,但我想从Cap'n Proto序列化机制中受益。不幸的是,在我看来,这是不可能的。部分阅读/撰写Cap'n Proto邮件

最大的问题是服务器端,这是单线程(如果没有任何严重的多线程参数,它将保持这种状态),并使用它自己的基于轮询的循环。所有事件都被部分读取,服务器不能阻止等待任何事件被完全读取 - 而这正是我卡住的地方。我们有我们自己的协议和类,它们包装消息,当事件被完全读取时,它可以消耗来自文件描述符的字节并进行通知,以便服务器可以处理它。我想我已经分析了Cap'n Proto接口的大部分(序列化,异步序列化),看起来,它没有任何修改就不能以相同的方式使用。

我真的很希望我错过了一些东西。我有吗?

回答

1

有两种方法可以解决这个问题:

  • 硬的方式:你可以尝试与KJ集成异步I/O架构(由头儿原使用)。 KJ事件循环实际上可以与其他事件循环集成并在其上运行 - 但这很棘手。例如,node-capnp包含用于将KJ事件循环与libuv集成的代码,如this source file的第一部分所示。一旦你有必要的胶水,你可以编写使用capnp/serialize-async.h中的接口的KJ风格的异步代码。
  • 简单的方法:与其试图整合KJ,您可以使用事件基础设施,直接从文件描述符读取数据,写一些简单的代码,然后使用capnp::expectedSizeInWordsFromPrefix()(从capnp/serialize.h)弄清楚它是否已收到信息的全部内容然而。如果该函数返回的数字大于您已有的数字,那么您没有完整的消息并且必须等待。一旦你有完整的信息,你可以使用capnp::FlatArrayMessageReader解析它。
+0

谢谢。我真的很感谢代码作者,他在堆栈溢出中处于活动状态:) – zoska

+0

expectedSizeInWordsFromPrefix是否也适用于打包消息?我总是得到巨大的数字... – hunyadym

+0

@hunyadym不,它不适用于打包的消息。实现这样的封装消息实际上会相当困难。明确地写一个长度前缀可能会更好。 :/我已经为此提出了一个问题:https://github.com/capnproto/capnproto/issues/590 –