Automotive Working Group Teleconference

29 Sep 2020



Peter, Tobias, Glenn, Ted, Adnan, Ulf, Gunnar, MagnusF, Steven, Daniel


WAMP evaluation


Tobias Oberstein, Crossbar.io WAMP author

[Ted summarizes RPC call yesterday, Magnus Feuer's evaluation of WAMP, Gunnar's earlier encouragements to consider it, how some of the capabilities may address some of our outstanding concerns for Gen2 or a Gen3]

https://gist.github.com/oberstet/efaba6eaaf4170b39550b25d6a28a5cd Tobias' WAMP/Gen2 mapping

Tobias: I had a quick read through of the specs and came up with a couple options on how it could work

Tobias: I should first recap quick history of WAMP and the challenges it sought to handle
... even if you don't consider adopting WAMP there are aspects that might be worth learning from

[Tobias shares screen]

Tobias: in 2012 I had a company before Crossbar and had need to have realtime capable user interface for a cloud application that runs in the browser
... that was a different world wrought with flash and various broken workarounds on limitations of browser
... goal was to run in browser, realtime and bidirectional
... we jumped into the WebSocket standards work
... contributed test suite, over 800 tests, here is a sample implementation report against it
... we had quite a bit of interactions over WebSocket, created implementations including first Android one
... after WS was widely spread in different browsers we were able to work on our initial interests but unfortunately found it insufficient by itself
... peers can send messages but that's it. we wanted a higher level of abstraction. if the cloud piece updates a piece, eg product price change, and that event would be subscribed to in user interface (browser) to receive immediately the price update
... no need to refresh to make another HTTP request
... if I am not refreshing regularly will miss it. other client might by permitted to update price and in that case the backend after verification can update db and start a new event to alert the other clients
... https://wamp-proto.org is community website for WAMP
... we wanted early adopters, have it neutral so didn't put it on our website
... the loose coupling, pubsub and RPC were part of version1
... we combined both patterns in one protocol, MQTT does pubsub but not available in browser
... a challenge in any design, having RPC in browser without decoupling caller and callee you run into problems
... client might be behind NAT or firewall and not reachable
... cell carriers all have NAT and won't allow connections to phone, there is no way to get a port forwarded like you can manually on a home router
... the is also the security consideration as you are opening an attack surface
... somewhere there needs to be something listening
... what we did to get around this problem was look at pubsub with a third rule, a broker that decouples the publishing and subscribing sides
... we used that pattern to transfer to RPC world, calling dealer in the middle
... WAMP router is broker and dealer combined
... callee opens a WebSocket connection outbound (no need for a port) back to the dealer at router
... once WAMP session is established, dealer can send calls down to callee
... at network level it is from the client end point to listening point in the cloud, traversing NATs and firewalls
... established WAMP session enables caller/callee communication through the dealer
... dealer can route calls, not merely RPC
... you can move callee somewhere else and caller doesn't care
... I'm usually developing the callee side user browser IDE (JS) and can also run in cloud with NodeJS

Routed RPC links:




MagnusF: is it possible to load balance with multiple callers/callees?

Tobias: yes, we have in Crossbar implementation, part of the registration process and governed by policy
... you can start multiple instances, order them based on availability in ranked order
... easy to scale
... first version of WAMP had RPC but not routed, version 2 solved that problem
... there won't be a version 3. we wanted to get the first version out quickly to get feedback and experience and revise
... that worked well
... version 1 had 10 implementations and lost track at number for version 2

[reviews list of implementations aware of]

Tobias: I would claim our implementation of routing is the most advanced

Gunnar: we looked over this a bit before, there was a comparison of languages
... maybe we should get into questions and answers
... one of the concerns we have had. if you are assuming a client/server role the router seems like something extra
... is it possible to stay client/server or do you simply consider server+router as one entity?

Tobias: you can write a WAMP component and run it out of process as a container worker or run in the same process of routing code

(in Crossbar at least)

Tobias: I don't want to care about that implementation detail, why should I care?

Gunnar: when you don't have NAT and firewall would client/server be more straightforward?

Tobias: why would you care? it is possible to run all three (client, router, server) on same host
... you can use UNIX domain sockets, doing away with TCP
... you can have a microcontroller talking WAMP over a serial connection even

Gunnar: I like the list of features as something we can grow into even if we don't need it now
... some might prefer simpler

Tobias: regarding transport, we do not have any coupling
... for example the whole WAMP spec only care about these four (message based, reliable, ordered, full-duplex)
... all the features of the advanced profile are announced by the router during WAMP handshake
... client announces as well
... basic profile is mandatory, the advanced is selective for different implementations
... an advanced profile capability you might be interested in for RPC is progressive results

MagnusF: can the recipient indicate when it is ready for next set of data?

Tobias: as I mentioned having a shared registration of callees we realized you can overload the group
... we wanted to be able to specify the maximum number of callees, putting additional in queue until queue is full

MagnusF: more on buffering data, indicating ready for next set of data

Tobias: this concurrency works across calls. producing side is in control of how fast it produces
... once there are progressive call arguments there is duplex communication

MagnusF: message queue provides consistent storage

Tobias: it is a complex matter. you need to worry about backscatter at transportation layer
... only one who can take pressure away is the producer
... non-trivial and don't claim we have solved everything
... we intend to support QUIC, we find it highly interesting as it is UDP based and solves a number of remaining issues including talking to microcontrollers that are incapable of TCP

MagnusF: using QUIC right now, but looks like we are running out of time

Tobias: we didn't have time to go into the mapping I sent

Adnan: how do you compare to rsockets done by Netflix? they address some of the same problems

Tobias: not familiar with it...

Adnan: they opened it about four years ago
... as Gunnar mentioned, if we don't have specific problems such as NAT then can you control that part and open port?

Tobias: you don't want to because you are combining a network artifact, the URL

Adnan: you don't have to bind to hostname or IP

Tobias: people created a whole industry around the misuse of TCP, proxy sidecars... etc
... people are doing RPC of MQTT

Adnan: how could we use WAMP in automotive is what I am trying to understand, your goals might have been different
... we have different limitations and wonder if it makes sense to use it 1:1 or combine with something else?

Tobias: I do not expect OEM to be able to convince carriers to open ports

Adnan: just read up on some of the hacking stories

Ted: eg the Jeep one (in addition to usb firmware recall they had carrier block port)

Tobias: there's your attack surface, it is crazy to have that on the device
... it is harder to control all the devices than secure the server
... do you want to have things end up in browser?

Adnan: depends on what kind of overhead do you want on the communication

Tobias: most efficient way in with JSON compression, it uses quite a bit of CPU load though
... you can do compressed flat buffers to reduce CPU

Adnan: you can't compress headers

rgd wire efficiency (of websocket)

Tobias: only one header for WebSocket
... WebSocket has payload compression, HTTP header compression
... HTTP3 will have best of both but you just have the first HTTP request for establishing WebSocket
... once that is done you can keep it open for hours without headers
... depends on payload of course
... flat buffers as serializer/payload format may make more sense for cars

[conversation will continue during TPAC on serialization & compression at least]

Additional reading:




[informal and unminuted discussion on ports and cell carriers, etc]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/09/30 19:15:24 $