Dynamic registration of endpoints/paths in a single crossbar.io router

[Scott Wittenburg]

Hi all,

   I hope I'm not going to mis-use terminology in a confusing way here, please let me know if I have done that.  What I want to achieve is to have a single crossbar.io router, and then have multiple application components register themselves with it, each using their own unique path.  So for example, I wanted to set up my "transports" like this:

         "transports": [

            {

               "type": "web",

               "endpoint": {

                  "type": "tcp",

                  "port": 8080

               },

               "paths": {

                  "/": {

                     "type": "static",

                     "directory": "/home/scott/Downloads/hpcmpPvTest/static"

                  },

                  "ws/*": {

                     "type": "websocket"

                  }

               }

            }

         ]

I know that "ws/*" is not going to work in the configuration as I have showed it here, because I tried it.  But perhaps there is a way to do something equivalent.  

Then I want two (or more) application components to register themselves to this router using different paths, like:

               "transport": {

                  "type": "websocket",

                  "endpoint": {

                     "type": "tcp",

                     "host": "127.0.0.1",

                     "port": 8080

                  },

                  "url": "ws://127.0.0.1:8080/ws/123"

               }

and

               "transport": {

                  "type": "websocket",

                  "endpoint": {

                     "type": "tcp",

                     "host": "127.0.0.1",

                     "port": 8080

                  },

                  "url": "ws://127.0.0.1:8080/ws/456"

               }

so that two different clients can connect using:

ws://localhost:8080/ws/123

and 

ws://localhost:8080/ws/456

Each client should be connected to the application component that matches the path they use in their connection url.

I tried this setup with just the normal transport configuration on the router, and everything worked ok until the second client tried to connect.  Then it was obvious that rpc calls from both clients were getting sent to the first application component.  

Is it clear what I am trying to achieve here?  Is it possible?

Cheers,

Scott

[Scott Wittenburg]

Hi All,

   As I re-read this post, I don't think I made it clear that the two ApplicationSessions are probably nearly identical in the rpc methods they publish, so that without registering under different paths, the router could probably not know which one to pick.

  Hope that helps clarify my question a bit more.

Thanks!

Scott

[Tobias Oberstein]

Am 11.09.2014 21:40, schrieb Scott Wittenburg:
> Hi All,
>
> As I re-read this post, I don't think I made it clear that the two
> ApplicationSessions are probably nearly identical in the rpc methods
> they publish, so that without registering under different paths, the
> router could probably not know which one to pick.

Hi Scott,

a router does not care about which transport a component connects. This
is by design: a router can run multiple transports, and the WAMP level
does not (and should not) know about the specifics of a certain
transport (like for WebSocket, the fully qualified URL the client was
connecting to).

What you can do is prefix the WAMP URIs being registered for procedures
by a component, and then instantiate the component multiple times:

Component instance 1 (for user 123):

com.myapp.user.123.proc1
com.myapp.user.123.proc2


Component instance 2 (for user 456):

com.myapp.user.456.proc1
com.myapp.user.456.proc2


What is missing is dynamically firing up a component when a user connects.

Who/what is (should be) triggering the firing up of a component?

The user frontend session?

Or should the backend component already run when the user connects? In
which case, what else is the trigger?

Cheers,
/Tobias

>
> Hope that helps clarify my question a bit more.
>
> Thanks!
> Scott
>
>
> On Tuesday, September 2, 2014 5:31:17 PM UTC-6, Scott Wittenburg wrote:
>
> Hi all,
>
> I hope I'm not going to mis-use terminology in a confusing way
> here, please let me know if I have done that. What I want to

> achieve is to have a single crossbar.io <http://crossbar.io> router,

> <http://127.0.0.1:8080/ws/123>"

> }
>
> and
>
> "transport": {
> "type": "websocket",
> "endpoint": {
> "type": "tcp",
> "host": "127.0.0.1",
> "port": 8080
> },
> "url": "ws://127.0.0.1:8080/ws/456

> <http://127.0.0.1:8080/ws/456>"

> }
>
> so that two different clients can connect using:
>
> ws://localhost:8080/ws/123
>
> and
>
> ws://localhost:8080/ws/456
>
> Each client should be connected to the application component that
> matches the path they use in their connection url.
>
> I tried this setup with just the normal transport configuration on
> the router, and everything worked ok until the second client tried
> to connect. Then it was obvious that rpc calls from both clients
> were getting sent to the first application component.
>
> Is it clear what I am trying to achieve here? Is it possible?
>
> Cheers,
> Scott
>

> --
> 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/c4b87131-b6a3-40cb-b496-91a6c1abcda2%40googlegroups.com
> <https://groups.google.com/d/msgid/autobahnws/c4b87131-b6a3-40cb-b496-91a6c1abcda2%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Scott Wittenburg]

Hi Tobias,

On Thursday, September 11, 2014 3:33:32 PM UTC-6, Tobias Oberstein wrote:

Am 11.09.2014 21:40, schrieb Scott Wittenburg:
> Hi All,
>
>     As I re-read this post, I don't think I made it clear that the two
> ApplicationSessions are probably nearly identical in the rpc methods
> they publish, so that without registering under different paths, the
> router could probably not know which one to pick.

Hi Scott,

a router does not care about which transport a component connects. This
is by design: a router can run multiple transports, and the WAMP level
does not (and should not) know about the specifics of a certain
transport (like for WebSocket, the fully qualified URL the client was
connecting to).

What you can do is prefix the WAMP URIs being registered for procedures
by a component, and then instantiate the component multiple times:

Component instance 1 (for user 123):

com.myapp.user.123.proc1
com.myapp.user.123.proc2


Component instance 2 (for user 456):

com.myapp.user.456.proc1
com.myapp.user.456.proc2

Hmmm, but as I was just reminded, those are static source code annotations.  Unless there is some we can dynamically update those uris when the app component starts up, then I guess this approach won't work, right?  Maybe that's what you're getting at below.

What is missing is dynamically firing up a component when a user connects.

Who/what is (should be) triggering the firing up of a component?

The user frontend session?

Or should the backend component already run when the user connects? In
which case, what else is the trigger?

We usually run a launcher process that accepts POST requests which take configuration info about the process to start up.  But one way or another, the client interaction with the frontend (in our case, usually Apache), triggers an app session to begin on the backend.  Then the frontend also does web socket tunneling for the clients so they can talk to their running session on the backend without interfering with each other.  We maintain a mapping so that our frontend knows how to map each clients requests to the proper backend process.

Thanks for your response, we'll give it some more thought and see if we can come up with some way around this issue.

Cheers,

Scott

 

> <mailto:autobahnws+unsub...@googlegroups.com>.

[Tobias Oberstein]

When using decorators, procedures are registered statically with respect to source code. However, when using register(), you are not limited in that way and can register (and unregister) completely dynamically ..

Sent from Mobile (Google Nexus 5)

To unsubscribe from this group and stop receiving emails from it, send an email to autobahnws+...@googlegroups.com.
To post to this group, send email to autob...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/autobahnws/1a8c5357-1294-48d6-abd5-a7e68127b90e%40googlegroups.com.