Cap"n Proto 是一種速度極快的數據交換格式和 capability-based RPC 系統，于 2013 年 4 月開源發(fā)布。時至今日，Cap"n Proto 1.0 終于發(fā)布，這是一個長期支持版本。

【資料圖】

Cap"n Proto 項目作者是Kenton Varda —— Protocol Buffers version 2 的主要開發(fā)者。他表示，Cap"n Proto 是其多年來開發(fā) Protobufs、聽取用戶反饋并汲取經驗思考反思后的成果結晶。

目前他已離開谷歌，因此“Cap"n Proto 不隸屬于谷歌，也從未隸屬于谷歌”?；鶞蕼y試結果表明，Cap"n Proto 比 Protocol Buffers 快無限倍。

自上一個版本 v0.10 以來，新版本的一些亮點內容包括：

針對 Cap"n Proto RPC 性能的一系列優(yōu)化。其中包括減少 RPC 實現和 KJ I/O 框架的內存分配量，增加從 RPC 協議中省略某些信息以減少流量的功能，以及更好地緩沖一起發(fā)送和接收的小信息以減少系統調用。 Breaking change：在此之前，服務器可在調用完成后調用 context.allowCancellation()，選擇允許取消 RPC。在 1.0 版中，選擇取消 RPC 可通過模式注解（c++.capnp 中定義的 allowCancellation 注解）來實現；模式級注解可以一次對整個文件進行設置。此外，動態(tài)選擇加入需要大量的簿記工作，在實際使用中會對性能產生明顯影響；而改用注釋則能提高性能。對于從未使用 context.allowCancellation() 的用戶來說，升級到 1.0 版時無需做任何更改，默認情況下仍不允許取消。(如果受到影響，你將看到編譯錯誤。如果沒有編譯錯誤，則無需擔心）。 KJ 現在在有 kqueue() 的系統（MacOS 和 BSD 衍生版本）上使用它來處理異步 I/O。在 Linux 上，KJ 一直使用 epoll，但在其他類 Unix 平臺上，KJ 一直使用較慢的 poll()-based 方法。 KJ 的 HTTP 客戶端和服務器實現現在支持 CONNECT 方法。 引入了一個新類 capnp::RevocableServer，以幫助在生命周期不受包裝器控制的對象周圍導出 RPC 包裝器。 以及一些更小的 bug 修復和改進。詳情可參閱 PR 歷史記錄。

在 1.0 版本發(fā)布后，2.0 版本的工作也開始提上日程。根據規(guī)劃，v2.0 旨在對 Cap"n Proto 的 C++ API 及其配套的 KJ C++ 工具包庫做出一些改變；以及做一些全面的向后兼容改動以修復一些問題，并改善團隊中開發(fā)人員的體驗。目前的一些想法包括：

需要一個支持 C++20 甚至 C++23 的編譯器。Cap"n Proto 1.0 僅需要 C++14。

需要一個支持 C++20 協程的編譯器。

Cap"n Proto 的 RPC 應用程序接口、KJ 的 HTTP 應用程序接口和其他程序接口很可能會進行修改，使其更加的coroutine-friendly。

kj::Maybe 將變得更符合人體工學。它將不再重載 nullptr 來表示值的缺失，將引入 kj::none 來代替。KJ_IF_MAYBE 將不再生成指針，而是一個引用（這是利用 C++17 特性實現的一種技巧）。

將放棄對禁用異常情況下的編譯的支持。

將放棄對no-RTTI 模式和其他會造成維護負擔的特殊模式的支持。

可能會修改 KJ 的引用計數方法，因為目前的設計已被證明對許多用戶來說并不直觀。

將修復 kj::AsyncOutputStream 中一個長期存在的設計缺陷，目前 EOF 信號是通過銷毀流來發(fā)出的。取而代之的是將添加一個返回 Promise 的顯式 end() 方法。在不調用 end() 的情況下銷毀數據流將發(fā)出錯誤的斷開信號。(還想對 KJ 流 API 進行其他一些美觀改進）。

重新設計幾個核心 I/O API，以便更好地適應 Linux 新的 io_uring 事件通知范式。

RPC 實現可能會改為默認允許取消。

值得注意的是，目前還沒有計劃對序列化格式或 RPC 協議進行任何向后不兼容的更改。所討論的更改僅影響 C++ API。用其他語言編寫的應用程序完全不受這一切的影響。

正式的 2.0 版本短時間內不會推出發(fā)布，或許也要等上幾年。

更多詳情可查看官方公告。

關鍵詞：