Cardinality of routers and realms

#1

     > 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

···

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:

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.

0 Likes

#2
 >     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

···

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:

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.

0 Likes

#3

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)

Am 10.09.2015 7:19 nachm. schrieb “Elvis Stansvik” elvs...@gmail.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

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

mailto:wampws...@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.

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.

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

0 Likes

#4

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

···

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

On Fri, Sep 11, 2015 at 8:30 AM Tobias Oberstein tobias.o...@gmail.com wrote:

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)

Am 10.09.2015 7:19 nachm. schrieb “Elvis Stansvik” elvs...@gmail.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

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

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

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

0 Likes