RPC protocols and the path forward.

Hi,

just wanted to chime into a recent discussion here about "RPC" and WAMP. 
I'm original author of WAMP, and have also participated in WebSocket 
specification (in the IETF Hybi WG in 2012 ff).

(note: since I only now subscribed, I have to reply "manually" to the 
post that I missed and wanted to comment on)

https://lists.w3.org/Archives/Public/public-automotive/2020Sep/0024.html

 > From: Magnus Feuer <magnus@feuerworks.com>
 > Date: Sun, 20 Sep 2020 10:39:21 -0700
 > Message-ID: 
<CAFpX5iFH71PLZrKhTMw3bUvRHw6RXQTsC9Tn1LYHOA2a1e-nuA@mail.gmail.com>
 > To: public-automotive@w3.org

So here are my comments.

1) serialization

 > *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).

The serializer used in WAMP is negotiated and orthogonal to the rest of 
the protocol ("pluggable")

https://wamp-proto.org/_static/gen/wamp_latest.html#building-blocks

The basic profile (BP) of WAMP only specifies 1 mandatory serializer: JSON

The advanced profile (AP) of WAMP specifies more serializers:

* MessagePack
* CBOR
* UBJSON

as well as a statically typed application payload serializer:

* FlatBuffers

Different WAMP implementations have different levels of support for 
those, and the characteristics of the serializers is different.

For Crossbar.io (and AutobahnPython) eg you can find extensive size and 
performance data here

https://crossbario.com/docs/benchmarks/serialization/index.html

You can drill down using the links in that page to the detail results 
(incl. payload definition), eg

https://crossbario.com/docs/benchmarks/serialization/vmprof_pypy_msgpack_normal_medium.html

Sidenote Flatbuffers, just super quickly: this is also the basis for 
statically typed WAMP interfaces, eg

https://github.com/crossbario/xbr-app/blob/4afd0f6039c75619f27db1b054796a0190bf6398/schema/climate.fbs#L70


2) lightweight

This seems to look at implementation weight rather than protocol weight, 
but it does not specify the protocol implementations being compared.

It also does not define "implementation weight", but seems to assume 
"number of dependencies" (which obviously would only be one of multiple 
aspects).

FWIW, also in WAMP, it does not make much sense to talk about 
implementation weight without specifying the level of WAMP support: 
basic profile only or advanced profile options, and if so, which. etc

Background: WAMP was designed with builtin pluggability and extensibility


3) Web native

Yes, WAMP was designed to be Web native, originally for WebSocket.

Nowerdays, WAMP also runs over RawSocket (over TLS/TCP): simpler/faster 
than WebSocket, can be used in cluster interconnects or for cloud 
backends. We also use that to talk WAMP over plain serial connections 
(in embedded).

In general, we've be super happy with WebSocket, we won't add HTTP/2 as 
a transport, but we might add QUIC

https://github.com/wamp-proto/wamp-proto/issues/363

Having a UDP based transport for WAMP would also provide the basis for 
native WAMP on 6LoWPAN networks and LTE-M.

---

Should you have more questions about WAMP, lemme know:) this seems an 
interesting ..

Cheers,
/Tobias


-- 

Tobias Oberstein - phone +49 176 2375 2055 - tobias.oberstein@crossbario.com
Crossbar.io GmbH - Waldstrasse 18 - 91054 Erlangen
HRB 15870 - Amtsgericht Fuerth - Geschäftsfuehrer/CEO - Tobias Oberstein

https://crossbar.io
https://crossbario.com

Received on Tuesday, 22 September 2020 17:05:09 UTC