Autobahn WAMP Architecture

#1

I come from a systems programming background with experience in using RPC. However, RPC in the traditional sense has always lacked things like subscriptions/callbacks to support more advanced interactions. Instead we have had to result to comet/long-poll and other such tactics which have many shortcomings. The other problem is that each RPC service listens on a socket for incoming connections. So when you have dozens of services this can quickly become tricky to deal with especially when you start looking at authentication. And finally, the unidirectional relationship imposed by the classic client/server model doesn’t really allow for bi-directional communication.

I am working on a project that consists of a dozen or so RPC services built upon msgpack-rpc. The services themselves run in a single process for ease of deployment. Some of these services talk to one another via the corresponding RPC clients which forms a hierarchy of sorts. The services learn about one another via a registry service. On startup, each of these services registers themselves with the registry. They then have the option to block and wait for other services to come online. This provides a means to synchronize services on startup. There is also a front-end that runs as a separate process space. Currently the front-end utilizes a few of the RPC clients to interact with the back-end services.

What I am looking at now is providing some kind of authentication mechanism between front-end and back-end to prevent unprivileged use of the services. In addition to this, I also want to be able to expose the API provided to the front end to third-party users. Perhaps even restrict capabilities/roles based on the level of authentication. This is proving to be a daunting task given that msgpack-rpc does not provide any sort of authentication mechanism and over and above that, any means to mediate based on roles/capabilities.

One approach I was looking at was to simply hide all of the RPC backend services behind a websocket API. Then the front-end can authenticate over a websocket, negotiate capabiltiies/role, etc. However, in order to do this I need to now introduce another service to mediate between the websocket to the front end and the RPC services on the backend. Plus, I also then need somehow secure each of the individual RPC services.

Note that I do not have any notion of a web front-end at this point in time and likely won’t. So I don’t need to “serve” anything to a web browser. However, it is a possibility that this could materialize in the future so it would be nice to keep that door open. I am now trying to decide if my architecture would be much simpler and more extendible if I went with Autobahn|Cpp and a WAMP Router. This would mean that I would have a single point of authentication since the only thing “listening for” and “accepting” connections would be the WAMP Router. Plus, the ability to now expose and manage an API to a third-party would be much simpler. It almost feels like a natural progression. Furthermore, the ability for full-duplex communication over the WAMP protocol greatly simplifies the notification/callback semantics. Currently this is unpleasant with msgpack-rpc.

  1. Can you see anything here that raises a red flag where you would say, “don’t move to Autobahn|Cpp + WAMP Router”?

  2. Does this seem like a logical architectural move even though I am not technically doing anything “web” based?

  3. What kind of performance can I expect? Does the routing add significant overhead?

  4. If I am working in a closed system (i.e. WAMP Router accepting only local connections), can I get away with writing a scaled down implementation of a WAMP Router natively in C++ using simple authentication.

  5. Is it a common use case to have the WAMP Peers and WAMP Router all live together on one machine? same process space?

I appreciate any insights that the group can can offer.

0 Likes

#2

     I come from a systems programming background with experience in
using RPC. However, RPC in the traditional sense has always lacked
things like subscriptions/callbacks to support more advanced
interactions. Instead we have had to result to comet/long-poll and other
such tactics which have many shortcomings. The other problem is that
each RPC service listens on a socket for incoming connections. So when

Yes, exactly. With "classic" RPC, the caller and callee are tigthly coupled, since the caller needs to know the location and how to reach the callee.

If you haven't done yet, I'd highly recommend at least skimming over http://wamp.ws/why/, which explains this in detail. I call this "routable RPC".

you have dozens of services this can quickly become tricky to deal with
especially when you start looking at authentication. And finally, the
unidirectional relationship imposed by the classic client/server model
doesn't really allow for bi-directional communication.

Yep. Very limiting.

     I am working on a project that consists of a dozen or so RPC
services built upon msgpack-rpc. The services themselves run in a single
process for ease of deployment. Some of these services talk to one
another via the corresponding RPC clients which forms a hierarchy of
sorts. The services learn about one another via a registry service. On
startup, each of these services registers themselves with the registry.
They then have the option to block and wait for other services to come
online. This provides a means to synchronize services on startup. There
is also a front-end that runs as a separate process space. Currently the
front-end utilizes a few of the RPC clients to interact with the
back-end services.

     What I am looking at now is providing some kind of authentication
mechanism between front-end and back-end to prevent unprivileged use of
the services. In addition to this, I also want to be able to expose the
API provided to the front end to third-party users. Perhaps even
restrict capabilities/roles based on the level of authentication. This
is proving to be a daunting task given that msgpack-rpc does not provide
any sort of authentication mechanism and over and above that, any means
to mediate based on roles/capabilities.

Crossbar.io has clearly separated mechnisms for authentication and authorization. And the latter is fully role based. So you can have frontends authenticate via mechanism A, getting role "frontend", and backends authenticate via mechnism B and getting role "backend", and assign different sets of permissions to those roles.

     One approach I was looking at was to simply hide all of the RPC
backend services behind a websocket API. Then the front-end can
authenticate over a websocket, negotiate capabiltiies/role, etc.
However, in order to do this I need to now introduce another service to
mediate between the websocket to the front end and the RPC services on
the backend. Plus, I also then need somehow secure each of the

With WAMP, the router fills this mediating role.

individual RPC services.

    Note that I do not have any notion of a web front-end at this point
in time and likely won't. So I don't need to "serve" anything to a web
browser. However, it is a possibility that this could materialize in the

That's fine. Browsers are just one run-time for executing JavaScript based WAMP components. E.g. http://tavendo.com/blog/post/free-your-code-backends-in-the-browser/

future so it would be nice to keep that door open. I am now trying to
decide if my architecture would be much simpler and more extendible if I
went with Autobahn|Cpp and a WAMP Router. This would mean that I would
have a single point of authentication since the only thing "listening
for" and "accepting" connections would be the WAMP Router. Plus, the
ability to now expose and manage an API to a third-party would be much
simpler. It almost feels like a natural progression. Furthermore, the
ability for full-duplex communication over the WAMP protocol greatly
simplifies the notification/callback semantics. Currently this is
unpleasant with msgpack-rpc.

     1. Can you see anything here that raises a red flag where you would
say, "don't move to Autobahn|Cpp + WAMP Router"?

From what you describe above (obviously I don't know all your requirements / sideconditions) I don't see any showstoppers.

     2. Does this seem like a logical architectural move even though I
am not technically doing anything "web" based?

Sure. Actually, the most interest in WAMP/Crossbar.io seems to come from embedded / IoT developers, not classical Web (or even mobile).

     3. What kind of performance can I expect? Does the routing add
significant overhead?

The routing of a call from component A via a locally running router to component B and back (that is 3 processes, e.g. wired via Unix domain sockets, speaking WAMP-RawSocket-MsgPack) does involve a couple of context switches. On a tuned system, this will be in the range of 10-100us. There will be some jitter depending on router load also. If you need a system that can do calls between components in say 100ns +/- 10ns jitter, then WAMP probably isn't for you.

     4. If I am working in a closed system (i.e. WAMP Router accepting
only local connections), can I get away with writing a scaled down
implementation of a WAMP Router natively in C++ using simple authentication.

You can of course implement a router in C++. The question I'd raise is why? Performance wise, beating PyPy on this task won't be easy even in C++.

My personal bet would be: if you want to beat PyPy on actual network WAMP routing by any significant performance margin, you will need to take radical approaches, like kernel-bypass networking. This isn't for the faint hearted;) I was contemplating about this. I'd either use C++ or Rust. But that's a whole different story.

     5. Is it a common use case to have the WAMP Peers and WAMP Router
all live together on one machine? same process space?

Yes. We are structuring our apps like this. Backends live on the same host. When the latter are Python, we sometimes move them to run inside Crossbar.io. This is just a config change. Fully transparent code wise.

I appreciate any insights that the group can can offer.

Hope above helps!

Thanks for all your interest (and patience with bleeding edge stuff;). Keep asking more if you have more questions ..

Cheers,
/Tobias

···

Am 22.11.2014 18:18, schrieb David Chappelle:

--
You received this message because you are subscribed to the Google
Groups "Autobahn" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to autobahnws+...@googlegroups.com
<mailto:autobahnws+...@googlegroups.com>.
To post to this group, send email to autob...@googlegroups.com
<mailto:autob...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/autobahnws/3bbefbc6-f37f-493e-8a5c-6daa306ac446%40googlegroups.com
<https://groups.google.com/d/msgid/autobahnws/3bbefbc6-f37f-493e-8a5c-6daa306ac446%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

0 Likes