Cap'n Proto VS rpclib

- may massively reduce the latency involved.

Those sharing Cap'n Proto-encoded data may have particular interest. Cap'n Proto (https://capnproto.org) is fantastic at its core task - in-place serialization with zero-copy - and we wanted to make the IPC (inter-process communication) involving capnp-serialized messages be zero-copy, end-to-end.

That said, we paid equal attention to other varieties of payload; it's not limited to capnp-encoded messages. For example there is painless (<-- I hope!) zero-copy transmission of arbitrary combinations of STL-compliant native C++ data structures.

To help determine whether Flow-IPC is relevant to you we wrote an intro blog post. It works through an example, summarizes the available features, and has some performance results. https://www.linode.com/blog/open-source/flow-ipc-introductio...

Of course there's nothing wrong with going straight to the GitHub link and getting into the README and docs.

Currently Flow-IPC is for Linux. (macOS/ARM64 and Windows support could follow soon, depending on demand/contributions.)

The second one is to encode data in such a way that you can read it and operate on it directly from the buffer. You write data in a layout that is the same, or easily transformed as types in memory. To do that you usually need to encode with a known schema, only Sized types to efficiently compute fields locations as offsets in the buffer, and you usually represent pointers as offset into the encode. You can look at capnproto protocol for instance https://capnproto.org/

Worked well for Cap'n Proto (the cerealization protocol)! https://capnproto.org/

With all due respect, you read completely wrong.

* The very first use case for which Cap'n Proto was designed was to be the protocol that Sandstorm.io used to talk between sandbox and supervisor -- an explicitly adversarial security scenario.

* The documentation explicitly calls out how implementations should manage resource exhaustion problems like deep recursion depth (stack overflow risk).

* The implementation has been fuzz-tested multiple ways, including as part of Google's oss-fuzz.

* When there are security bugs, I issue advisories like this:

https://github.com/capnproto/capnproto/tree/v2/security-advi...

* The primary aim of the entire project is to be a Capability-Based Security RPC protocol.

I like how they use capability-based security [0] and use Cap'n Proto protocol. This is another technology that is slow to get broad adoption, but has many things going for when compared to e.g. Protocol Buffers (Cap'n Proto is created by the primary author of Protobuf v2, Kenton Varda).

[0] https://sandstorm.io/how-it-works#capabilities

[1] https://capnproto.org

Related but not Rust-specific: FlatBuffers, Cap'n Proto.

Cap'n proto would be ideal for this. It can read out the data from a const byte array (using include_bytes! macro) directly without a separate deserialise step. protobuf and bincode would require deserialising the data into a heap allocated structure on startup or first use. Because your binary will be memory-mapped by the OS, the data can also be lazily paged in as it is read, requiring less I/O if you don't read the whole file.

This is only possible when you don't need serialization, though. However, just last week I started looking into Cap'n Proto to solve this issue. It's a serialization format that's designed for shared memory and so provides data types that can be used directly with no conversion. There's a full Rust implementation for it.

Google thinks gRPC is fast enough for there use case. What do you consider high-performance? Plain UDP with custom TCP-like stack? https://capnproto.org/?

Is Cap'n'Proto [0] as awesome as it sounds? Anyone have any first-hand experience and can speak on it?

Thanks!

[0]: https://capnproto.org/

Some years ago I created rpclib which, at the time, gained some traction. However, a planned hiatus turned into an indefinite one due to real-life obligations. I'm still getting new issues and PRs filed and I'd really hate to just archive the project without giving this a shot. I still think that RPC without code generation is a useful niche to fill.

Thanks for all your hard work in the past years. I'm not able to take over as a maintainer, but you mentioned CI rot and I can take thorough look at that! I opened a small PR refactoring the AppVeyor configuration.

The code is reasonably well covered with unit tests, although there are many things I would do differently if I were to start today (and indeed, this project itself was a huge learning opportunity for me). The cmake build is a mess and likely requires rewriting at this point, and the CI is likely a victim of code rot. Github: https://github.com/rpclib/rpclib