Infinitely faster than Protocol Buffers, Cap'n Proto 1.0 is finally released after ten years of open source

Cap'n Proto is an extremely fast data exchange format and capability-based RPC system, which was released as open source in April 2013. Today, Cap'n Proto 1.0 is finally released , which is a long-term support version.

The author of the Cap'n Proto project is Kenton Varda, the main developer of Protocol Buffers version 2. He said that Cap'n Proto is the result of years of developing Protobufs, listening to user feedback, and drawing on experience and reflection.

He has now left Google, so "Cap'n Proto is not affiliated with Google and has never been affiliated with Google." Benchmark results show that Cap'n Proto is infinitely faster than Protocol Buffers.

Some highlights of the new version since the previous version v0.10 include:

• A number of optimizations for Cap'n Proto RPC performance. These include reducing the amount of memory allocated by the RPC implementation and the KJ I/O framework, adding the ability to omit certain information from the RPC protocol to reduce traffic, and better buffering of small messages sent and received together to reduce system calls.
• Breaking change: Previously, servers could opt-in to cancel an RPC by calling context.allowCancellation() after the call completed. In version 1.0, opting in to cancel an RPC is done via a schema annotation (allowCancellation annotation defined in c++.capnp); schema-level annotations can be set for an entire file at once. Also, dynamic opt-in requires a lot of bookkeeping, which in practice can have a noticeable performance impact; using annotations instead improves performance. For users who have never used context.allowCancellation(), there is no need to change when upgrading to version 1.0; cancellation is still not allowed by default. (You will see a compile error if this is affected. If not, there is no need to worry).
• KJ now uses kqueue() to handle asynchronous I/O on systems that have it (MacOS and BSD derivatives). On Linux, KJ has always used epoll, but on other Unix-like platforms, KJ has always used the slower poll()-based method.
• KJ's HTTP client and server implementations now support the CONNECT method.
• A new class, capnp::RevocableServer, has been introduced to help export RPC wrappers around objects whose lifetime is not controlled by the wrapper.
• And some smaller bug fixes and improvements. See the PR history for details .

After the release of version 1.0, the work on version 2.0 was also put on the agenda. According to the plan, v2.0 aims to make some changes to Cap'n Proto's C++ API and its supporting KJ C++ toolkit library; as well as make some comprehensive backwards-compatible changes to fix some issues and improve the experience of developers in the team. Some current ideas include:

• A compiler supporting C++20 or even C++23 is required. Cap'n Proto 1.0 only requires C++14.
• A compiler that supports C++20 coroutines is required.
• Cap'n Proto's RPC API, KJ's HTTP API, and other APIs are likely to be modified to be more coroutine-friendly.
• kj::Maybe will become more ergonomic. It will no longer overload nullptr to represent the absence of a value, and kj::none will be introduced instead. KJ_IF_MAYBE will no longer generate a pointer, but a reference (a trick that uses C++17 features).
• Support for disabling compilation under exception conditions will be dropped.
• Support for no-RTTI mode and other special modes that would create a maintenance burden will be dropped.
• KJ's reference counting approach may be revised, as the current design has proven to be unintuitive for many users.
• A long-standing design flaw in kj::AsyncOutputStream will be fixed, currently EOF is signaled by destroying the stream. Instead, an explicit end() method that returns a Promise will be added. Destroying the stream without calling end() will incorrectly signal a disconnect. (A few other cosmetic improvements to the KJ stream API are also expected).
• Redesigned several core I/O APIs to better fit Linux's new io_uring event notification paradigm.
• RPC implementations may change to allow cancellation by default.

It is worth noting that there are currently no plans to make any backwards-incompatible changes to the serialization format or the RPC protocol. The changes in question only affect the C++ API. Applications written in other languages ​​are completely unaffected by all this.

The official 2.0 version will not be released in the short term, and it may take a few years.