annotate src/capnproto-git-20161025/doc/index.md @ 169:223a55898ab9 tip default

Add null config files
author Chris Cannam <cannam@all-day-breakfast.com>
date Mon, 02 Mar 2020 14:03:47 +0000
parents 1ac99bfc383d
children
rev   line source
cannam@133 1 ---
cannam@133 2 layout: page
cannam@133 3 title: Introduction
cannam@133 4 ---
cannam@133 5
cannam@133 6 # Introduction
cannam@133 7
cannam@133 8 <img src='images/infinity-times-faster.png' style='width:334px; height:306px; float: right;'>
cannam@133 9
cannam@133 10 Cap'n Proto is an insanely fast data interchange format and capability-based RPC system. Think
cannam@133 11 JSON, except binary. Or think [Protocol Buffers](http://protobuf.googlecode.com), except faster.
cannam@133 12 In fact, in benchmarks, Cap'n Proto is INFINITY TIMES faster than Protocol Buffers.
cannam@133 13
cannam@133 14 This benchmark is, of course, unfair. It is only measuring the time to encode and decode a message
cannam@133 15 in memory. Cap'n Proto gets a perfect score because _there is no encoding/decoding step_. The Cap'n
cannam@133 16 Proto encoding is appropriate both as a data interchange format and an in-memory representation, so
cannam@133 17 once your structure is built, you can simply write the bytes straight out to disk!
cannam@133 18
cannam@133 19 **_But doesn't that mean the encoding is platform-specific?_**
cannam@133 20
cannam@133 21 NO! The encoding is defined byte-for-byte independent of any platform. However, it is designed to
cannam@133 22 be efficiently manipulated on common modern CPUs. Data is arranged like a compiler would arrange a
cannam@133 23 struct -- with fixed widths, fixed offsets, and proper alignment. Variable-sized elements are
cannam@133 24 embedded as pointers. Pointers are offset-based rather than absolute so that messages are
cannam@133 25 position-independent. Integers use little-endian byte order because most CPUs are little-endian,
cannam@133 26 and even big-endian CPUs usually have instructions for reading little-endian data.
cannam@133 27
cannam@133 28 **_Doesn't that make backwards-compatibility hard?_**
cannam@133 29
cannam@133 30 Not at all! New fields are always added to the end of a struct (or replace padding space), so
cannam@133 31 existing field positions are unchanged. The recipient simply needs to do a bounds check when
cannam@133 32 reading each field. Fields are numbered in the order in which they were added, so Cap'n Proto
cannam@133 33 always knows how to arrange them for backwards-compatibility.
cannam@133 34
cannam@133 35 **_Won't fixed-width integers, unset optional fields, and padding waste space on the wire?_**
cannam@133 36
cannam@133 37 Yes. However, since all these extra bytes are zeros, when bandwidth matters, we can apply an
cannam@133 38 extremely fast Cap'n-Proto-specific compression scheme to remove them. Cap'n Proto calls this
cannam@133 39 "packing" the message; it achieves similar (better, even) message sizes to protobuf encoding, and
cannam@133 40 it's still faster.
cannam@133 41
cannam@133 42 When bandwidth really matters, you should apply general-purpose compression, like
cannam@133 43 [zlib](http://www.zlib.net/) or [LZ4](https://github.com/Cyan4973/lz4), regardless of your
cannam@133 44 encoding format.
cannam@133 45
cannam@133 46 **_Isn't this all horribly insecure?_**
cannam@133 47
cannam@133 48 No no no! To be clear, we're NOT just casting a buffer pointer to a struct pointer and calling it a day.
cannam@133 49
cannam@133 50 Cap'n Proto generates classes with accessor methods that you use to traverse the message. These accessors validate pointers before following them. If a pointer is invalid (e.g. out-of-bounds), the library can throw an exception or simply replace the value with a default / empty object (your choice).
cannam@133 51
cannam@133 52 Thus, Cap'n Proto checks the structural integrity of the message just like any other serialization protocol would. And, just like any other protocol, it is up to the app to check the validity of the content.
cannam@133 53
cannam@133 54 Cap'n Proto was built to be used in [Sandstorm.io](https://sandstorm.io), where security is a major concern. As of this writing, Cap'n Proto has not undergone a security review, therefore we suggest caution when handling messages from untrusted sources. That said, our response to security issues was once described by security guru Ben Laurie as ["the most awesome response I've ever had."](https://twitter.com/BenLaurie/status/575079375307153409) (Please report all security issues to [security@sandstorm.io](mailto:security@sandstorm.io).)
cannam@133 55
cannam@133 56 **_Are there other advantages?_**
cannam@133 57
cannam@133 58 Glad you asked!
cannam@133 59
cannam@133 60 * **Incremental reads:** It is easy to start processing a Cap'n Proto message before you have
cannam@133 61 received all of it since outer objects appear entirely before inner objects (as opposed to most
cannam@133 62 encodings, where outer objects encompass inner objects).
cannam@133 63 * **Random access:** You can read just one field of a message without parsing the whole thing.
cannam@133 64 * **mmap:** Read a large Cap'n Proto file by memory-mapping it. The OS won't even read in the
cannam@133 65 parts that you don't access.
cannam@133 66 * **Inter-language communication:** Calling C++ code from, say, Java or Python tends to be painful
cannam@133 67 or slow. With Cap'n Proto, the two languages can easily operate on the same in-memory data
cannam@133 68 structure.
cannam@133 69 * **Inter-process communication:** Multiple processes running on the same machine can share a
cannam@133 70 Cap'n Proto message via shared memory. No need to pipe data through the kernel. Calling another
cannam@133 71 process can be just as fast and easy as calling another thread.
cannam@133 72 * **Arena allocation:** Manipulating Protobuf objects tends to be bogged down by memory
cannam@133 73 allocation, unless you are very careful about object reuse. Cap'n Proto objects are always
cannam@133 74 allocated in an "arena" or "region" style, which is faster and promotes cache locality.
cannam@133 75 * **Tiny generated code:** Protobuf generates dedicated parsing and serialization code for every
cannam@133 76 message type, and this code tends to be enormous. Cap'n Proto generated code is smaller by an
cannam@133 77 order of magnitude or more. In fact, usually it's no more than some inline accessor methods!
cannam@133 78 * **Tiny runtime library:** Due to the simplicity of the Cap'n Proto format, the runtime library
cannam@133 79 can be much smaller.
cannam@133 80 * **Time-traveling RPC:** Cap'n Proto features an RPC system that implements [time travel](rpc.html)
cannam@133 81 such that call results are returned to the client before the request even arrives at the server!
cannam@133 82
cannam@133 83 <a href="rpc.html"><img src='images/time-travel.png' style='max-width:639px'></a>
cannam@133 84
cannam@133 85
cannam@133 86 **_Why do you pick on Protocol Buffers so much?_**
cannam@133 87
cannam@133 88 Because it's easy to pick on myself. :) I, Kenton Varda, was the primary author of Protocol Buffers
cannam@133 89 version 2, which is the version that Google released open source. Cap'n Proto is the result of
cannam@133 90 years of experience working on Protobufs, listening to user feedback, and thinking about how
cannam@133 91 things could be done better.
cannam@133 92
cannam@133 93 Note that I no longer work for Google. Cap'n Proto is not, and never has been, affiliated with Google; in fact, it is a property of [Sandstorm.io](https://sandstorm.io), of which I am co-founder.
cannam@133 94
cannam@133 95 **_OK, how do I get started?_**
cannam@133 96
cannam@133 97 To install Cap'n Proto, head over to the [installation page](install.html). If you'd like to help
cannam@133 98 hack on Cap'n Proto, such as by writing bindings in other languages, let us know on the
cannam@133 99 [discussion group](https://groups.google.com/group/capnproto). If you'd like to receive e-mail
cannam@133 100 updates about future releases, add yourself to the
cannam@133 101 [announcement list](https://groups.google.com/group/capnproto-announce).
cannam@133 102
cannam@133 103 {% include buttons.html %}