RPC protocols and the path forward.

All,

I had a chat with Steven Martin at JLR about the next steps in the RPC
standardization process.

We agreed that Steven will focus on the service catalog format, tooling,
and catalog (three related but separate efforts), while I will work on the
protocol spec itself.

Please note that Steven, and I feel for him, has taken over a few of my
responsibilities at JLR and will have limited bandwidth during the next
month or so. The same bandwidth limitations and duration goes for me as my
Toyota ramp-up continues.

I did have time to start digging into gRPC and WAMP. Below is a cursory
summary. On Monday we can talk about what further research we need to do,
and I'll expand the report.

The protocol primary use will be OTA communication between vehicle and
backend servers and, optionally, between vehicle and other (mobile) devices.

The proposed basic requirements on the protocol are:

*1. Efficient encoding*
"Every byte counts" (as was mentioned last week) over an expensive mobile
data link.

*gRPC* - Uses protobuf (v3) as a codec, which is binary encoded on an
atomic scalar element level. [1]

*WAMP* - Uses JSON with base64-encoded binary data [1], with optional gzip
compression on an HTTP level [2]. It seems like some implementations offers
MsgPack (similar to protobuf as an alternative to JSON, but this is not an
official standard (afaik).

*Winner: *gRPC
---

*2. Lightweight*
Low barrier of entry from a tooling and complexity point of view. Few
dependencies on underlying libraries, which should be well-known and
accepted.

*gRPC* - Uses protobuf, cmake, standard Linux build tools [4]. The dev
cycle is straight-forward with a single command to generate stub code.
libgrpc-dev and libgrpc-dev++ are available in the ubuntu repos, and are
dependent on libc-ares2.

*WAMP - *There are many implementations of WAMP [5]. Looking at the
autobahn cpp implementation (one of several languages supported by
autobahn) [5], building and running code seems fairly straight forward.
Please note the lack of an interface definition language, everything is
wired into the code, which may or may not have consequences for W3C
automotive usage.
Dependencies are cmake, boost-asio, boost-future, WebSocket++, and
msgpack-c (not JSON!).

*Winner:* gRPC due better packaging, less dependencies, and easily
available reference implementation.
---

*3. Web native*
No tunneling, special firewall setup, or other transport shenanigans needed
to communicate between vehicle and server.

*gRPC- *Uses HTTP/2, which seems well-supported if not well-used.
*WAMP *- Uses websockets.
*Winner:* WAMP. Websockets are widely available and accepted, unlike HTTP/2.
---

*4. Polyglot*
Code generators for C/C++, Python, and, preferably other languages.

*gRPC -* 13 languages [6]
*WAMP *- 15 languages [7]
*Winner: *WAMP, although both support more than enough languages.

References:
[1] https://developers.google.com/protocol-buffers/docs/encoding
[2]
https://stackoverflow.com/questions/21746184/enable-gzip-module-on-wampserver
[3] https://wamp-proto.org/spec.html
[4] https://grpc.io/docs/languages/cpp/quickstart/
[5] https://github.com/crossbario/autobahn-cpp/
[6] https://grpc.io/docs/languages/
[7] https://crossbar.io/about/Supported-Languages/

Regards,

/Magnus F.