= yaml = title: FAQ toc: true = yaml =
Anyone who's interested in learning what the system can do, or is excited about the prospect of being an early adopter or contributor of what we hope will become a comprehensive framework for building distributed applications and multi-device UIs.
Anyone who needs to build a production quality system or application over the next few months — although we believe our code is well tested, we expect to continue to make changes to the core APIs and services as we learn from our early adopters. Keeping up with such changes in a production environment is likely to be problematic. In addition, key features like distributed storage are not available yet.
We anticipated that we would be more productive using Go than one of the other systems programming languages available to us.
Vanadium is an ongoing project, with a clear and ambitious long-term goal of making it easier to build distributed multi-device apps and UIs. We‘ll use whatever technology helps us meet those goals and design new technology whenever we need to. We’ll use whatever open source projects makes sense for us to use, whether they originate from Google or anywhere else. We recognize that there is overlap with many existing projects, but there is no single project that meets our requirements or goals.
One of our design principles is to put security first and we wanted an RPC protocol that has symmetrical end-to-end authentication, encryption, and the ability to run through proxies without compromising that security. No existing protocol that we are aware of meets these requirements, so we designed one. As an example, our protocol allows a client and proxy to authenticate with each other and for the client to authenticate with the server directly and independently of the proxy. This allows an independent company to run a proxy service for paying clients and service providers without having to implement its own authentication scheme. All clients still authenticate directly with the services they interact with and do not have to rely on the proxy service for the validity of that authentication.
We wanted an encoding that can be used when the producer and consumer don‘t necessarily share a common code base or ‘stub library’. This loose coupling can be in terms of space (e.g. a client and server implemented by two different code bases and/or organizations) and time (e.g. a log file is written today, but read 10 years from now without access to the original code). This implies an encoding that is language independent and self-describing; given a log file written using our encoding, it should be possible to algorithmically construct the data types needed to read that log file by examining that log file alone. Naturally we’d like the encoding to be as efficient as possible, both in terms of space and computational cost. We are not aware of any modern encoding format that meets these requirements.
Benchmark details and code used to measure the performance of the Vanadium RPC stack are available on GitHub.
As of April 20, 2015, the numbers are dismally low. We expect to make significant improvements to them over the coming months.
| Benchmark | GCEn1-standard-4 | Raspberry Pi | Raspberry Pi 2 |
|---|---|---|---|
| RPC Connection | 33.48 ms/rpc | 1765.47 ms/rpc | 847.41 ms/rpc |
| RPC (echo 1KB) | 1.31 ms/rpc (763.05 qps) | 78.61 ms/rpc (12.72 qps) | 16.47 ms/rpc (60.71 qps) |
| RPC Streaming (echo 1KB) | 0.11 ms/rpc | 23.85 ms/rpc | 3.33 ms/rpc |
| RPC Streaming Throughput (echo 1MB) | 313.91 MB/s | 0.92 MB/s | 2.31 MB/s |
Note: Google Compute Engine n1-standard-4 has 15 GB of memory and 4 virtual CPUs, each implemented as a single hyperthread on a 2.3 GHz Intel Xeon E5 v3 (Haswell).
Yes, the Vanadium JS library is both callback and promise compatible. For simplicity, the tutorials use callbacks exclusively.
Any function that accepts a callback argument also returns a promise. Thus, to use promises, omit the cb argument. Accordingly, use Promise.resolve and Promise.reject to indicate the end of the function.