Cap'n Proto is an extremely fast data interchange format and capability-based RPC system, released as open source in April 2013. Today, Cap'n Proto 1.0 is finally released , a long-term support release.
The author of the Cap'n Proto project is Kenton Varda, the lead developer of Protocol Buffers version 2. He said that Cap'n Proto is the culmination of years of developing Protobufs, listening to user feedback, and learning from 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 series of optimizations for Cap'n Proto RPC performance. These include reducing the amount of memory allocated for the RPC implementation and the KJ I/O framework, adding the ability to omit certain messages from the RPC protocol to reduce traffic, and better buffering of small messages sent and received together to reduce system calls.
- Breaking change: Previously, the server could optionally allow RPC cancellation by calling context.allowCancellation() after the call had completed. In version 1.0, opting out of canceling RPCs is possible through schema annotations (the allowCancellation annotation defined in c++.capnp); schema-level annotations can be set for the entire file at once. Also, dynamic opt-in requires a lot of bookkeeping and has a noticeable performance impact in practice; using annotations instead improves performance. For those who have never used context.allowCancellation(), no changes are required when upgrading to version 1.0, cancellation is still not allowed by default. (If it is affected, you will see compile errors. If there are no compile errors, nothing to worry about).
- KJ now uses kqueue() on systems that have it (MacOS and BSD derivatives) to handle asynchronous I/O. On Linux, KJ has been using epoll, but on other Unix-like platforms, KJ has been using 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 also began to be 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; and to make some comprehensive backward compatibility changes to fix some problems and improve the development of developers in the team. experience. Some current ideas include:
-
A compiler that supports C++20 or even C++23 is required. Cap'n Proto 1.0 only requires C++14.
-
Requires a compiler that supports C++20 coroutines.
-
Cap'n Proto's RPC API, KJ's HTTP API, and others will likely be modified to be more coroutine-friendly.
-
kj::Maybe will become more ergonomic. It will no longer overload nullptr to indicate the absence of a value, and kj::none will be introduced instead. KJ_IF_MAYBE will no longer generate a pointer, but a reference (this is a trick implemented using a C++17 feature).
-
Support for disabling compilation with exceptions will be dropped.
-
Support for no-RTTI mode and other special modes that create a maintenance burden will be dropped.
-
KJ's approach to reference counting may be revised, as the current design has proven unintuitive to many users.
-
A long-standing design flaw in kj::AsyncOutputStream will be fixed where EOF is currently signaled by destroying the stream. Instead, an explicit end() method that returns a Promise will be added. Destroying a data stream without calling end() will signal a false disconnect. (Want to make some other aesthetic improvements to the KJ Streams API as well).
-
Several core I/O APIs were redesigned to better fit Linux's new io_uring event notification paradigm.
-
RPC implementations may change to allow cancellation by default.
It's 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 a short time, and may have to wait a few years.
More details can be found in the official announcement .