Re: Cardinality of routers and realms
93 views
Skip to first unread message
Tobias Oberstein
Sep 10, 2015, 11:52:46 AM9/10/15
to wam...@googlegroups.com, cross...@googlegroups.com
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
>
> Elvis
>
>
> 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_.
>
>
>
> --
> 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>.
> For more options, visit https://groups.google.com/d/optout.
> 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
>
> Elvis
>
>
> 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_.
>
>
>
> --
> 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>.
> For more options, visit https://groups.google.com/d/optout.
Tobias Oberstein
Sep 10, 2015, 12:56:05 PM9/10/15
to wam...@googlegroups.com, cross...@googlegroups.com
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
> 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
Sep 10, 2015, 1:14:25 PM9/10/15
to WAMP, cross...@googlegroups.com
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
Sep 10, 2015, 1:19:12 PM9/10/15
to WAMP, cross...@googlegroups.com
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
Sep 11, 2015, 8:30:07 AM9/11/15
to cross...@googlegroups.com, WAMP
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.
Alexander Gödde
Sep 11, 2015, 9:54:33 AM9/11/15
to WAMP, cross...@googlegroups.com
Hi Ming!
Am Freitag, 11. September 2015 15:43:20 UTC+2 schrieb Ming Leung:
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
Am Freitag, 11. September 2015 15:43:20 UTC+2 schrieb 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 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.
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.
Reply all
Reply to author
Forward
0 new messages