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

#1

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

0 Likes

#2

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

···

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

0 Likes

#3

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

···

Am 11.09.2014 21:40, schrieb Scott Wittenburg:

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

0 Likes

#4

Hi Tobias,

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

···

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

Am 11.09.2014 21:40, schrieb Scott Wittenburg:

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) <[http://crossbar.io](http://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](http://127.0.0.1:8080/ws/123)
<[http://127.0.0.1:8080/ws/123](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)
<[http://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+unsub...@googlegroups.com.

To post to this group, send email to auto...@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.

0 Likes

#5

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)

Am 11.09.2014 23:28 schrieb “Scott Wittenburg” scott.wi...@kitware.com:

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

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) <[http://crossbar.io](http://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](http://127.0.0.1:8080/ws/123)
<[http://127.0.0.1:8080/ws/123](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)
<[http://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+unsub...@googlegroups.com.

To post to this group, send email to auto...@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.

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.

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.

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

0 Likes