Re: RPC protocols and the path forward.

Apologies, my email setup is a bit messed up at the moment.  
 I'll have to attempt inline-answer in HTML format and hope it 
 isn't too messed up:
 
 

 
On 9/20/20 7:39 PM, Magnus Feuer wrote:
 
 
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).
 
 

[GA] I checked for you.  JSON and MsgPack are both described in the WAMP protocol specification and the initial WebSocket handshake must specify which subprotocol is being used.  So if anything *beyond* those two choices would be create (like applying protobuf to WAMP) then that would be a non-official extension to WAMP, but MsgPack seems fully supported out of the box.
 

 
 

 
 
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.
 
 
 
 

[GA] To my understanding, VSC would in effect be our interface description language so the lack of one in WAMP might not be a bad thing.  We might in some sense fill a gap then, if we were to make a binding from VSC to WAMP.
 

 
 

 
 
Dependencies are cmake, boost-asio, boost-future, WebSocket++, and msgpack-c (not JSON!).
 
 
 

[GA] As you mentioned there are many implementations so their dependencies may differ.
 

 
 

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

[GA] Crossbar (https://crossbar.io) is the full-featured and as close as I can see "de-facto" reference implementation, but I suppose Autobahn is the name of the protocol libraries utilized by Crossbar.  Crossbar is written in Python.  As you noted, the closest thing to a reference in C++ world would likely be Autobahn-CPP.  
 
 We might extend this analysis by clarifying if we are interested in how easy it is to handle the reference implementation, or the C++/optimized production case (if those are different), or both?
 

 
 
---
 

 
 
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.
 
 

[GA] Yes, WAMP appears to describe two (JSON and MsgPack variant) WebSocket subprotocols.
 

 
 
---
 

 
 
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.
 
 
 

[GA] Agreed, both support more than enough.
 
 

 

[GA] * 5.  Feature comparison?
 
 I don't know if it is desired but "Routed RPC" seems to be a feature relatively
 unique to WAMP.  (In this case I might be unaware of features in other ecosystems
 however).  WAMP is of course also a data-distribution alternative, within the 
 same spec.
 

 

Best Regards,
 - Gunnar

 


 

 
 

 
 
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.