Autobahn WAMP Architecture

[David Chappelle]

    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.

[Tobias Oberstein]

Am 22.11.2014 18:18, schrieb David Chappelle:
> 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

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