2017-10-11 98 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 –