> A router is a technical thing (a piece of code), wheras
> logical, WAMP level entities.
> User can use realms to map and isolate different applications,
> environments (test1/test2), tenants, ..
> There are various use cases. Having the ability for multiple
> the same router process is something we've learned from our
> router implementation (which was closed source).
> Can you share a specific use case or limitations?
See above for us cases
I think Dave meant use cases for having multiple realms per router
process. Multiple realms could still be managed using a
Well, doing multiple realms with 1 realm per process means: you _have_ to use _different_ listening ports for different realms. With CB you can still choose to do that, or you can run on 1 port. User choice.
one-realm-per-process router simply by starting multiple processes, no?
I'm also a bit interested in why Crossbar is multiple-realms-per-process.
Let's say you have multiple independent apps or multiple tenants (eg customers).
You want make sure, that the apps/tenants are fully isolated. The apps/tenants should not interfere with each other. Each app/tenant is running code (app components) developed independently. This is a logical / security thing.
But you want to run everything on port 443 as secure WebSocket using a single server certificate. This is a technical/admin thing.
Crossbar.io will allow you to do that. Using the upcoming CB DevOps center (which is built on the already existing management API inside CB), you can _dynamically_ start and stop realms without even stopping a router worker. And if you need more performance, you will be able to dynamically start new router workers (with no change in realms).
Realms and router workers are orthogonal things. The former is a WAMP logical thing, whereas the latter is about technical/admin/performance. It's again the underlying philosophy of WAMP: separation of concerns.
App functionality should not be mixed with routing functionality.
Realms should not be mixed with technical artifacts like "workers".
App components should not care / know under which hosting run-time they run (guest worker, container, router side-by-side), over what transport they talk (WS, RawSocket, Pipes, Unix domain, ..) nor which serialization they use (JSON, MsgPack, ..).
In a way, Crossbar.io takes the core WAMP philosphy to extreme.
For me, this is just the "right way". I've written the 3rd router implementation now .. and I avoided a couple of restrictions this time. Getting this all work together was tricky .. took me around 6 weeks around last christmas (I hacked the core of CB at that time - from scratch). Dumped older implementations completely.
The whole internal architecture of CB works very well now.
But again: this is all implementation specific. It is not something we should put into the WAMP protocol spec.
It's perfectly fine to have a router implementation which has a realm-process 1:1 relation. It's 100% WAMP conformant. It may or may not be a restriction - all depends on the concrete use case.
With CB, we have a larger vision. We have only started;) Can't disclose much, but - after we are through with the current cleanup/stabilization phase - you are gonna fasten your seat belts as we take it to the next level. On different frontlines.
Am 10.09.2015 um 17:24 schrieb Elvis Stansvik:
On Thursday, September 10, 2015 at 3:37:53 PM UTC+2, Tobias Oberstein wrote:
User can use realms to map and isolate different applications,
> environments (test1/test2), tenants, ..
> > bonefish implementation I opted to only allow a 1:1
> > routers and realms which made implementation much simpler.
> Pros/cons of
> > both approaches? Should this be a part of the basic
> The WAMP spec deliberately does not restrict this. It's an
> implementation detail of the router. In fact, the WAMP spec
> clear separation between things that must behave "identical"
> implementations, and stuff where implementations can
> But I agree in so far as the spec probably should discuss the
> for implementations: only 1 realm vs multiple realms to make
> freedom more explicit ..
> That would be great. Perhaps a pros/cons listing of both
approaches as well.
A protocol spec shouldn't discuss implementation tradeoffs.
E.g. we use Python as an implementation language. There is no point in
discussion the pros/cons of using that in writing a router _in the
You received this message because you are subscribed to the Google
Groups "WAMP" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to wampws+un...@googlegroups.com
To post to this group, send email to wam...@googlegroups.com
Visit this group at http://groups.google.com/group/wampws.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.