Cardinality of routers and realms

[David Chappelle]

In looking at the crossbar implementation a router can have multiple realms configured. Just curious what the rationale is behind this rather than only allowing a router to be associated to a single realm. In the bonefish implementation I opted to only allow a 1:1 relationship between routers and realms which made implementation much simpler. Pros/cons of both approaches? Should this be a part of the basic specification?

[Tobias Oberstein]

Hi Dave,

Am 10.09.2015 um 14:59 schrieb David Chappelle:
> In looking at the crossbar implementation a router can have multiple
> realms configured. Just curious what the rationale is behind this rather
> than only allowing a router to be associated to a single realm. In the

A router is a technical thing (a piece of code), wheras realms are
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 realms in
the same router process is something we've learned from our first WAMP
router implementation (which was closed source).

> bonefish implementation I opted to only allow a 1:1 relationship between
> routers and realms which made implementation much simpler. Pros/cons of
> both approaches? Should this be a part of the basic specification?

The WAMP spec deliberately does not restrict this. It's an
implementation detail of the router. In fact, the WAMP spec makes a
clear separation between things that must behave "identical" across
implementations, and stuff where implementations can differentiate.

But I agree in so far as the spec probably should discuss the options
for implementations: only 1 realm vs multiple realms to make this
freedom more explicit ..

Cheers,
/Tobias

>
> --
> 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
> <mailto:wampws+un...@googlegroups.com>.
> To post to this group, send email to wam...@googlegroups.com
> <mailto:wam...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/wampws.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/wampws/e48b9a67-ee3c-40aa-94d6-6f4cb08c4982%40googlegroups.com
> <https://groups.google.com/d/msgid/wampws/e48b9a67-ee3c-40aa-94d6-6f4cb08c4982%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[David Chappelle]

On Thursday, 10 September 2015 09:13:43 UTC-4, Tobias Oberstein wrote:

Hi Dave,

Am 10.09.2015 um 14:59 schrieb David Chappelle:
> In looking at the crossbar implementation a router can have multiple
> realms configured. Just curious what the rationale is behind this rather
> than only allowing a router to be associated to a single realm. In the

A router is a technical thing (a piece of code), wheras realms are
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 realms in
the same router process is something we've learned from our first WAMP
router implementation (which was closed source).

Can you share a specific use case or limitations?

 

> bonefish implementation I opted to only allow a 1:1 relationship between
> routers and realms which made implementation much simpler. Pros/cons of
> both approaches? Should this be a part of the basic specification?

The WAMP spec deliberately does not restrict this. It's an
implementation detail of the router. In fact, the WAMP spec makes a
clear separation between things that must behave "identical" across
implementations, and stuff where implementations can differentiate.

But I agree in so far as the spec probably should discuss the options
for implementations: only 1 realm vs multiple realms to make this
freedom more explicit ..

That would be great. Perhaps a pros/cons listing of both approaches as well.

[Tobias Oberstein]

> A router is a technical thing (a piece of code), wheras realms are
> 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 realms in
> the same router process is something we've learned from our first WAMP
> router implementation (which was closed source).
>
>
> Can you share a specific use case or limitations?

See above for us cases

User can use realms to map and isolate different applications,
> environments (test1/test2), tenants, ..

>

> > bonefish implementation I opted to only allow a 1:1 relationship
> between
> > routers and realms which made implementation much simpler.
> Pros/cons of
> > both approaches? Should this be a part of the basic specification?
>
> The WAMP spec deliberately does not restrict this. It's an
> implementation detail of the router. In fact, the WAMP spec makes a
> clear separation between things that must behave "identical" across
> implementations, and stuff where implementations can differentiate.
>
> But I agree in so far as the spec probably should discuss the options
> for implementations: only 1 realm vs multiple realms to make this
> 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
protocol spec_.

[Elvis Stansvik]

On Thursday, September 10, 2015 at 3:37:53 PM UTC+2, Tobias Oberstein wrote:

>     A router is a technical thing (a piece of code), wheras realms are
>     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 realms in
>     the same router process is something we've learned from our first WAMP
>     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 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.

Elvis

[David Chappelle]

One advantage that I can see to having multiple realms per router is if transports are configured on a router by router basis. So if you had 100 realms, you could easily deploy them all under a common transport or set of transports. Where in a 1:1 type of relationship you would need to configure 100 different routers/transports. The same would be true of application components and any other resources owned by a router. So from a resource and configuration standpoint this makes sense. If you desired a 1:1 type of relationship you can still have that as well.

[Tobias Oberstein]

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:
>
> > A router is a technical thing (a piece of code), wheras
> realms are
> > 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
> realms in
> > the same router process is something we've learned from our
> first WAMP
> > 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

Ah, ok.

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.

Cheers,
/Tobias

> --
> 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
> <mailto:wampws+un...@googlegroups.com>.
> To post to this group, send email to wam...@googlegroups.com
> <mailto:wam...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/wampws.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/wampws/48c54ba8-c535-40da-8de2-bfebc93dbccf%40googlegroups.com
> <https://groups.google.com/d/msgid/wampws/48c54ba8-c535-40da-8de2-bfebc93dbccf%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Tobias Oberstein]

Am 10.09.2015 um 17:46 schrieb David Chappelle:
> One advantage that I can see to having multiple realms per router is if
> transports are configured on a router by router basis. So if you had 100
> realms, you could easily deploy them all under a common transport or set

Exactly. And the overhead in CB of running another realm is minimal. You
can run 10s of thousands realms. Think: multi-tenancy. You can't
configure those realms using a static node config, but you will be able
to script/API control CB to fire up those realms. You will be able to
have a "meta App component", which fires up realms when tenants (of your
app) sign up. etc etc.

We already did the hard groundwork in CB .. the bits are there. Need to
connect the dots. But as these are all quite new and advanced concepts,
we (the CB community) need to make sure to gradually introduce those
things to let users grok those concepts.

E.g. the idea, that _CB_ itsef has a meta API (I am not talking about
WAMP meta API - which CB also has), which is also WAMP, and where CB
talks to uplink management CB - on another level - might come as a
surprise to some. It's like a "self hosting compiler" - or recursive
WAMP. CB has passed that stage early this year. It's just that we are
not yet talking much about it.

> of transports. Where in a 1:1 type of relationship you would need to
> configure 100 different routers/transports. The same would be true of
> application components and any other resources owned by a router. So
> from a resource and configuration standpoint this makes sense. If
> you desired a 1:1 type of relationship you can still have that as well.

Yep. And you can also mix that.

E.g. you could have a dedicated router process with only a single realm,
where you give that process appropriate RAM resources (cgroups) to
"guarantee" a certain QoS. And then you can have another router process
that runs 1000 "best-efforts" realms.

Cheers,
/Tobias

[Elvis Stansvik]

Thanks to both of you for elaborating. It makes a lot of sense.

When I first saw the approach taken by Dave with Bonefish, I kind of liked the simplicity of it. In a way, it felt "pure" that there was a 1:1 mapping between router processes and realms. And the programmer in me also saw that this probably simplified the implementation, like Dave mentioned.

Reading your words though Tobias, Crossbar's model makes perfect sense, in the context of its ambition of being "more than just a WAMP router" so to speak.

I'm sure you can build sophisticated multi-tenant solutions _around_ a 1:1 router. The approach taken by Crossbar is just different in that it's "batteries included".

Cheers,
Elvis

Cheers,
/Tobias

[Elvis Stansvik]

On Thursday, September 10, 2015 at 5:52:46 PM UTC+2, Tobias Oberstein wrote:

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:
>
>      >     A router is a technical thing (a piece of code), wheras
>     realms are
>      >     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
>     realms in
>      >     the same router process is something we've learned from our
>     first WAMP
>      >     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

Ah, ok.

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.

Right, this is a strong use case actually. Especially considering the firewall piercing power of port 443 you mention below.

Elvis
 

[Tobias Oberstein]

Also note: Crossbar decouples not only router processes from realms, but also from transports!

E.g. you can start multiple transports (eg websocket and rawsocket) that are serving clients in the same realm. Or multiple realms.

This is also quite important! Eg running websocket plus longpoll on 443, and rawsocket on a second port. Cb supports 18 different transport flavors! All of this allows to address a lot of scenarios. User choice.

Again, this architecture stems from the experience we gained with the previous 2 router implementions we wrote.

Sent from Mobile (Google Nexus 5)

You received this message because you are subscribed to the Google Groups "Crossbar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crossbario+...@googlegroups.com.
To post to this group, send email to cross...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/crossbario/974cf84f-bf3d-4767-b1f5-1d618733809a%40googlegroups.com.

[Ming Leung]

Can crossbar run websocket/long poll and raw socket on the same port (e.g. 443)? I thought i read previously the WAMP Advance Profile that it is designed for that purpose but can't verify anymore as this link is broken. And not sure crossbar implementation will support that.

../ming

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 https://groups.google.com/d/msgid/wampws/CABuE%2BY62otVumWp_OndHfArPOT4zsMcjwa0ngUJ9EF4PV_a0XQ%40mail.gmail.com.

[Alexander Gödde]

Hi Ming!

I fixed the link in question - see https://github.com/tavendo/WAMP/blob/master/spec/advanced/transports.md

AFAIK the only combination of transport protocols on a port which works is WebSocket and HTTP since WebSocket starts off as a HTTP request. You can combine WebSocket and various other services which use HTTP on a Web transport - see http://crossbar.io/docs/Web-Transports-and-Services/.

Otherwise it's one transport protocol per port.

Regards,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to crossbario+unsubscribe@googlegroups.com.

To post to this group, send email to cross...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/crossbario/974cf84f-bf3d-4767-b1f5-1d618733809a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe@googlegroups.com.

[Tobias Oberstein]

This very feature is the only omission to the full matrix of transport options.

RawSocket is specified already with this in mind, but it is not yet possible in CB. And I don't know of any router providing it. We will have it in CB.

You will be able to run WebSocket, Longpoll and RawSocket plus all the CB HTTP Web services over TLS all on port 443 using one server certificate.

This is in my view the most desirable configuration for running in production. No reverse proxying or anything in front. Unneeded. It is what we will run ourselfes most of the time.

It will have the broadest range possible rgd client support, feature set and security.

Sidenote on security: CB by default will accept exactly 4 ciphers for TLS. All provide PFS. All the old and insecure crap is deactivated.

Say sorry to IE on XP;) Though Chrome/Firefox works great even on XP.

Sent from Mobile (Google Nexus 5)

To view this discussion on the web visit https://groups.google.com/d/msgid/wampws/CAO7yyAWN-6Jn4448Eu_ZThy_LoVftjU2dK0Kxx9z9eDsWqLyDA%40mail.gmail.com.

[Tobias Oberstein]

Being pedantic here: Longpoll is a fully featured transport. And it runs from a Web service along with WebSocket today.

Whats not yet there is adding RawSocket into above mix on the same port. But as said, its easy shit, as we already did the hard work figururin out how to make that fly .. some impl. bits are missing.

Sent from Mobile (Google Nexus 5)

To unsubscribe from this group and stop receiving emails from it, send an email to crossbario+...@googlegroups.com.

To post to this group, send email to cross...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/crossbario/974cf84f-bf3d-4767-b1f5-1d618733809a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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 https://groups.google.com/d/msgid/wampws/CABuE%2BY62otVumWp_OndHfArPOT4zsMcjwa0ngUJ9EF4PV_a0XQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

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 https://groups.google.com/d/msgid/wampws/1d82ec1e-d18c-4d58-8024-ff248481389c%40googlegroups.com.

[Ming Leung]

Thanks for all those info.

Put all those 3 transport protocol (WS/LP/RawSock) into one port is important. In embedded MCU world, especially the small & low power one, those systems has very limit resource. So saving the code (and effort) to put a http client could mean a lot.

../ming

[Emile Cormier]

I imagine that having one router process managing multiple realms using a thread pool would have higher performance than having multiple processes each managing their own independent realm. The 1:1 approach would have multiple processes running identical code, with only the realm URI being different. I suspect the multi-realm/multithreaded approach would be more cache friendly than the multiprocess approach.

If the bottleneck is I/O, then perhaps there would be no performance difference one way or another.

One possible advantage of the 1:1 approach would be that public-facing routers/realms can be isolated so that they don't have access/permission to access critical resources of the system.