[Introductions]
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:
https://wamp-proto.org/routing.html
https://crossbario.com/blog/Free-Your-Code-Backends-in-the-Browser/
https://crossbario.com/static/presentations/seamless-connectivity/index.html
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:
https://crossbario.com/docs/crossbarfx/benchmarks.html
https://crossbario.com/docs/benchmarks/serialization/index.html
https://crossbario.com/docs/benchmarks/serialization/vmprof_pypy_msgpack_normal_small.html
[informal and unminuted discussion on ports and cell carriers, etc]