Dynamic ports and service binding in multiservice desktop app + some viability concerns.

#1

Dear Colleagues,

We develop desktop application, containing some separate services. Since we code primarily in Python, we are considering using Crossbar as a router for inter process communication messaging and also as a process manager. Base on the documentation and examples it matches our requirements quite well, but there are some issues I cannot find solution for, so I would like to ask the community for advice.

Since we develop desktop application, we cannot be sure that some specific ports are available on the client’s PC, so we cannot hardcode port numbers to the Crossbar configuration file. Typically, the solution is to make the service to bind to any available port (usually coded as port 0) and to report it to the process manager the port number it is bound to. We usually implement such reporting through named pipe which id is given to the service as a command line parameter or as value of environment variable. So I am looking for the ideas how to implement such behavior with Crossbar.

Another concern I have, is that WAMP protocol itself and all accompanying Autobahn projects are not very popular these days by some reason. For example, in spite of there are many libraries implementing WAMP, according to GitHub statistics only few of them are really actively maintained. The company Tavendo behind Autobahn and Crossbar seems to be dead, at least the copyright on tavendo.com is “Copyright © 2011-2014”. I do not see any significant activity on StackOverflow by relevant tags, strictly speaking there are some flow of questions, but most of them have no any responses. There are some dead links in the Crossbar documentation, for instance the link “Manhole” on this page. Please understand me correctly it is not critique, I am just afraid of picking dying technology for the new product. Dear colleagues, please correct me if I am wrong, I would be happy to see the elephant in the room I am missing,

Best regards,
Alexander.

0 Likes

#2

Hi Alexander

With regards to the dynamic port thing I don’t really have any ideas, although I guess you could fork Crossbar and implement changes for dynamic port binding? I imagine it wouldn’t be too much of an effort to do. You could even make said changes in a way that is compatible for the project at large and submit a PR back to the main project for inclusion. Being able to specify the port as 0 and allow it to bind dynamically could work. However, the big question is: If your router is bound to a dynamic port then how do client applications running outside the router know which port to connect to? You will need some method of advertising which port the router is running on. Advertising this port is a whole other task in itself…

With regards to the status of WAMP and Tavendo, I know they’re fairly quiet but as I understand it this is because they’re hard at work on their Crossbar+ solution which will include router clustering for high availability. WAMP itself is actually on pretty solid ground. Keep in mind that WAMP is built on WebSockets, which are in a fairly healthy place right now. Keep in mind, however, the WS is still a relatively young technology that was only standardized in 2011. For comparison, work on ES6 happened over many years since ES5.1 was released and it was only standardised in 2015. As such, you shouldn’t worry too much about the state of WAMP and WS because they’re still rather young technologies with plenty of room for growth.

The documentation is still a little out of date but was actually improved a great deal recently. Nevertheless, it’s still worth checking the Example code in GitHub to ensure you’re not reading old documentation.

0 Likes

#3

Hi Adam, thank you for the reply.

I think I could try to implement the feature to somehow bind port automatically, it also will give me a chance to better understand an architecture and a quality of this piece of software. Is there a document describing how to start developing Crossbar? I mean some configuration management guide: how to build, run tests and so on. There is a DEVELOPERS.md in the root of repository, but it is significantly outdated as far as I see. At least it contains roadmap up to version 14 while there is 16 already here. Actually, I think the Makefile is a way to start with, and I will definetely use virtualenv, but it would be nice to have some guide just to be sure I am the right way.

Another question concerns the overall architecture. Is there a design-document that I can dive into in order to catch the the hi-level architecture of Crossbar router?

···

воскресенье, 15 января 2017 г., 10:00:14 UTC+3 пользователь Adam Jorgensen написал:

Hi Alexander

With regards to the dynamic port thing I don’t really have any ideas, although I guess you could fork Crossbar and implement changes for dynamic port binding? I imagine it wouldn’t be too much of an effort to do. You could even make said changes in a way that is compatible for the project at large and submit a PR back to the main project for inclusion. Being able to specify the port as 0 and allow it to bind dynamically could work. However, the big question is: If your router is bound to a dynamic port then how do client applications running outside the router know which port to connect to? You will need some method of advertising which port the router is running on. Advertising this port is a whole other task in itself…

With regards to the status of WAMP and Tavendo, I know they’re fairly quiet but as I understand it this is because they’re hard at work on their Crossbar+ solution which will include router clustering for high availability. WAMP itself is actually on pretty solid ground. Keep in mind that WAMP is built on WebSockets, which are in a fairly healthy place right now. Keep in mind, however, the WS is still a relatively young technology that was only standardized in 2011. For comparison, work on ES6 happened over many years since ES5.1 was released and it was only standardised in 2015. As such, you shouldn’t worry too much about the state of WAMP and WS because they’re still rather young technologies with plenty of room for growth.

The documentation is still a little out of date but was actually improved a great deal recently. Nevertheless, it’s still worth checking the Example code in GitHub to ensure you’re not reading old documentation.

0 Likes

#4

Since we develop desktop application, we cannot be sure that some specific
ports are available on the client's PC, so we cannot hardcode port numbers
to the Crossbar configuration file. Typically, the solution is to make the
service to bind to any available port (usually coded as port 0) and to
report it to the process manager the port number it is bound to. We usually
implement such reporting through named pipe which id is given to the
service as a command line parameter or as value of environment variable. So
I am looking for the ideas how to implement such behavior with Crossbar.

If you only need host local communication, why not use Unix domain sockets? Faster, more secure, less hassle.

If you can't use that, but must use loopback TCP, it would be trivial to allow configuration of TCP port with value 0 and let the OS choose a port.

I just quickly checked that: http://picpaste.com/Bildschirmfoto_vom_2017-01-15_17-37-16.png

The real question is: _where_ do you need to know the actually selected port?

Another concern I have, is that WAMP protocol itself and all accompanying
Autobahn projects are not very popular these days by some reason. For
example, in spite of there are many libraries implementing WAMP, according
to GitHub statistics only few of them are really actively maintained. The
company Tavendo behind Autobahn and Crossbar seems to be dead, at least the

I can assure you, we are not dead;)

To the contrary: we have founded a new company "Crossbar.io GmbH" exclusively dedicated to Crossbar.io (and hence, Tavendo is being dissolved, and we are moving stuff.)

copyright on tavendo.com is "Copyright © 2011-2014". I do not see any
significant activity on StackOverflow by relevant tags, strictly speaking
there are some flow of questions, but most of them have no any responses.
There are some dead links in the Crossbar documentation, for instance the
link "Manhole" on this page

Really? That should be removed. Manhold is strictly a feature for Crossbar.io developers (working on Crossbar.io itself), not users.

<http://crossbar.io/docs/Controller-Configuration/>. Please understand me
correctly it is not critique, I am just afraid of picking dying technology
for the new product. Dear colleagues, please correct me if I am wrong, I
would be happy to see the elephant in the room I am missing,

There are some huge companies already using Crossbar.io (I mean, S&P500 size) or are doing PoCs - I can't talk about these at this point.

We (as a company) have been a little bit less responsive / visible lately, since we have so much stuff to do / getting our act together.

Cheers,
/Tobias

···

Best regards,
Alexander.

0 Likes

#5

Hi Adam,

Hi Alexander

With regards to the dynamic port thing I don't really have any ideas,
although I guess you could fork Crossbar and implement changes for dynamic

Why fork and not contribute?

Anyway: sure one can fork and modify the hack out of it. Just keep in mind that Crossbar.io is licensed under the AGPL 3.0 - you have to comply to the license ..

port binding? I imagine it wouldn't be too much of an effort to do. You
could even make said changes in a way that is compatible for the project at
large and submit a PR back to the main project for inclusion. Being able to
specify the port as 0 and allow it to bind dynamically could work. However,
the big question is: If your router is bound to a dynamic port then how do
client applications running outside the router know which port to connect
to? You will need some method of advertising which port the router is
running on. Advertising this port is a whole other task in itself...

With regards to the status of WAMP and Tavendo, I know they're fairly quiet
but as I understand it this is because they're hard at work on their
Crossbar+ solution which will include router clustering for high

Yep, true.

availability. WAMP itself is actually on pretty solid ground. Keep in mind
that WAMP is built on WebSockets, which are in a fairly healthy place right
now. Keep in mind, however, the WS is still a relatively young technology
that was only standardized in 2011. For comparison, work on ES6 happened
over many years since ES5.1 was released and it was only standardised in
2015. As such, you shouldn't worry too much about the state of WAMP and WS
because they're still rather young technologies with plenty of room for
growth.

Agreed. There are plenty of reasons for WebSocket, and if you go WebSocket, then (in my view) it is likely that you will reinvent something similar to WAMP sooner or later - as WebSocket is awesome, but low-level ...

The documentation is still a little out of date but was actually improved a
great deal recently. Nevertheless, it's still worth checking the Example
code in GitHub to ensure you're not reading old documentation.

Yeah, absolutely. We have _tons_ of examples.

Cheers,
/Tobias

···

Am 15.01.2017 um 08:00 schrieb Adam Jorgensen:

0 Likes

#6

Dear Tobias,

it is nice to hear that the company behind Crossbar is alive and performing well. I think it is too early to discuss contributing, at first I need to see the code and find out if I can implement the features I need. But, of course I will share my work if I get something working.

It is good you mentioned licensing, I think it could be an issue. Actually, I (and the company I work for) completely agree to share the modifications of Crossbar code we could make if there are ones. But do we legally allowed to redistribute Crossover as a part of our closed-source proprietary commercial desktop application? Is this allowed by AGPL 3.0 license?

···

воскресенье, 15 января 2017 г., 19:52:26 UTC+3 пользователь Tobias Oberstein написал:

Hi Adam,

Am 15.01.2017 um 08:00 schrieb Adam Jorgensen:

Hi Alexander

With regards to the dynamic port thing I don’t really have any ideas,

although I guess you could fork Crossbar and implement changes for dynamic

Why fork and not contribute?

Anyway: sure one can fork and modify the hack out of it. Just keep in
mind that Crossbar.io is licensed under the AGPL 3.0 - you have to
comply to the license …

port binding? I imagine it wouldn’t be too much of an effort to do. You

could even make said changes in a way that is compatible for the project at

large and submit a PR back to the main project for inclusion. Being able to

specify the port as 0 and allow it to bind dynamically could work. However,

the big question is: If your router is bound to a dynamic port then how do

client applications running outside the router know which port to connect

to? You will need some method of advertising which port the router is

running on. Advertising this port is a whole other task in itself…

With regards to the status of WAMP and Tavendo, I know they’re fairly quiet

but as I understand it this is because they’re hard at work on their

Crossbar+ solution which will include router clustering for high

Yep, true.

availability. WAMP itself is actually on pretty solid ground. Keep in mind

that WAMP is built on WebSockets, which are in a fairly healthy place right

now. Keep in mind, however, the WS is still a relatively young technology

that was only standardized in 2011. For comparison, work on ES6 happened

over many years since ES5.1 was released and it was only standardised in

  1. As such, you shouldn’t worry too much about the state of WAMP and WS

because they’re still rather young technologies with plenty of room for

growth.

Agreed. There are plenty of reasons for WebSocket, and if you go
WebSocket, then (in my view) it is likely that you will reinvent
something similar to WAMP sooner or later - as WebSocket is awesome, but
low-level …

The documentation is still a little out of date but was actually improved a

great deal recently. Nevertheless, it’s still worth checking the Example

code in GitHub to ensure you’re not reading old documentation.

Yeah, absolutely. We have tons of examples.

Cheers,

/Tobias

0 Likes

#7

If you only need host local communication, why not use Unix domain
sockets? Faster, more secure, less hassle.

The reason is simple. There is a web-based version of the application I am taking about. So I would like to use the same technology in both deployment variants.

If you can’t use that, but must use loopback TCP, it would be trivial to
allow configuration of TCP port with value 0 and let the OS choose a port.

I just quickly checked that:
http://picpaste.com/Bildschirmfoto_vom_2017-01-15_17-37-16.png

I already did the same :slight_smile: Trivial extending the range of allowed port numbers in checkconfig.py:681 did the trick.

The real question is: where do you need to know the actually selected
port?

Indeed, this is the question. My application contains of several processes. There are some domain-specific workers, web browser (custom chromium-based application) and web server. What I need is to somehow bind these workers to the web server and let browser know the port webserver is bound on. I know several ways to implement this manually in Python and we have working prototype. Now I am trying to understand which part of this bootstrapping can be more-or-less easily implemented with Crossbar.

0 Likes

#8

This sounds like chicken/egg .. a URL (including host/port) is supposed to be "well-known".

Honestly, I don't see much value in going down this road in your scenario (or I don't understand it fully):

simply allow the user to specify the port to use at installation time and generate appropriate node configuration ..

···

Am 15.01.2017 um 20:22 schrieb Alexander Prokhorov:

let browser know the port webserver is bound on

--

That being said, I think the feature you might want to have is

https://en.wikipedia.org/wiki/Zero-configuration_networking#DNS-SD_with_multicast
https://github.com/crossbario/crossbar/issues/240

If we had DNS-SD in Crossbar.io, the router (transport) could be discovered automatically by WAMP clients on the local network.

Then again I don't know about non-Safari browser support

Quickly googling turns up

https://developer.chrome.com/apps/mdns

But hey:

https://www.w3.org/TR/discovery-api/

--

A first step would be to research above a little deeper .. in essence, it's about service discovery on local networks where the service is a Crossbar.io WAMP routing listening transport.

Cheers,
/Tobias

0 Likes

#9

It is good you mentioned licensing, I think it could be an issue. Actually,
I (and the company I work for) completely agree to share the modifications
of Crossbar code we could make if there are ones. But do we legally allowed
to redistribute Crossover as a part of our closed-source proprietary
commercial desktop application? Is this allowed by AGPL 3.0 license?

This is not a legal advice (pls ask a lawyer;), but here is our informal view:

1)
WAMP components that talk to Crossbar.io via WAMP transport are NOT affected by the AGPL: http://crossbar.io/docs/Crossbar-License/#wamp-clients-as-separate-works

2)
if you touch the code of Crossbar.io _itself_, you have to publish the source code for your modified version of Crossbar.io (but not your app) and make it available - and this holds true regardless whether you redistribute your modified Crossbar.io version or not (for example, if you "only" run it in the cloud)

3)
you cannot use the name "Crossbar.io" without our prior written permission, because we hold up the trademark (otherwise people would get confused about the "real" Crossbar.io)

4)
you cannot use the management API and it's components which is embedded inside Crossbar.io, because we have a copyright on the _API_

https://github.com/crossbario/crossbar/blob/master/LICENSE-FOR-API

The management API of Crossbar.io is used internally including for the node configuration. We have a version of Crossbar.io upcoming that allows dynamic and remote reconfiguration of Crossbar.io via that management API.

As long as you follow above, "you are good"!

Cheers,
/Tobias

···

воскресенье, 15 января 2017 г., 19:52:26 UTC+3 пользователь Tobias > Oberstein написал:

Hi Adam,

Am 15.01.2017 um 08:00 schrieb Adam Jorgensen:

Hi Alexander

With regards to the dynamic port thing I don't really have any ideas,
although I guess you could fork Crossbar and implement changes for

dynamic

Why fork and not contribute?

Anyway: sure one can fork and modify the hack out of it. Just keep in
mind that Crossbar.io is licensed under the AGPL 3.0 - you have to
comply to the license ..

port binding? I imagine it wouldn't be too much of an effort to do. You
could even make said changes in a way that is compatible for the project

at

large and submit a PR back to the main project for inclusion. Being able

to

specify the port as 0 and allow it to bind dynamically could work.

However,

the big question is: If your router is bound to a dynamic port then how

do

client applications running outside the router know which port to

connect

to? You will need some method of advertising which port the router is
running on. Advertising this port is a whole other task in itself...

With regards to the status of WAMP and Tavendo, I know they're fairly

quiet

but as I understand it this is because they're hard at work on their
Crossbar+ solution which will include router clustering for high

Yep, true.

availability. WAMP itself is actually on pretty solid ground. Keep in

mind

that WAMP is built on WebSockets, which are in a fairly healthy place

right

now. Keep in mind, however, the WS is still a relatively young

technology

that was only standardized in 2011. For comparison, work on ES6 happened
over many years since ES5.1 was released and it was only standardised in
2015. As such, you shouldn't worry too much about the state of WAMP and

WS

because they're still rather young technologies with plenty of room for
growth.

Agreed. There are plenty of reasons for WebSocket, and if you go
WebSocket, then (in my view) it is likely that you will reinvent
something similar to WAMP sooner or later - as WebSocket is awesome, but
low-level ...

The documentation is still a little out of date but was actually

improved a

great deal recently. Nevertheless, it's still worth checking the Example
code in GitHub to ensure you're not reading old documentation.

Yeah, absolutely. We have _tons_ of examples.

Cheers,
/Tobias

0 Likes

#10

Hi Tobias

···

On Sunday, 15 January 2017 18:52:26 UTC+2, Tobias Oberstein wrote:

Hi Adam,

Am 15.01.2017 um 08:00 schrieb Adam Jorgensen:

Hi Alexander

With regards to the dynamic port thing I don’t really have any ideas,

although I guess you could fork Crossbar and implement changes for dynamic

Why fork and not contribute?

Anyway: sure one can fork and modify the hack out of it. Just keep in
mind that Crossbar.io is licensed under the AGPL 3.0 - you have to
comply to the license …

This is actually what I had in mind. When I said fork what I was talking about was the GitHub process of forking, working and then submitting a PR back to the original project. My bad, I realise this was a poor use of the word fork.

0 Likes

#11

This is not a legal advice (pls ask a lawyer;), but here is our informal

view:

if you touch the code of Crossbar.io itself, you have to publish the
source code for your modified version of Crossbar.io (but not your app)
and make it available - and this holds true regardless whether you
redistribute your modified Crossbar.io version or not (for example, if
you “only” run it in the cloud)

I understood that if we modify the code then we need to share that changes, that is perfectly fine with us. Consider we do not modify any code, can we redistribute Crossbar.io within package of our commercial software? For example, we cannot do this with libraries licensed under GPL, but we can for LGPL, What about AGPL? I could not find clear answer for that yet…

you cannot use the management API and it’s components which is embedded
inside Crossbar.io, because we have a copyright on the API

https://github.com/crossbario/crossbar/blob/master/LICENSE-FOR-API

The management API of Crossbar.io is used internally including for the
node configuration. We have a version of Crossbar.io upcoming that
allows dynamic and remote reconfiguration of Crossbar.io via that
management API.

I didn’t even know there is such API :slight_smile:

Actually, there is another question, can I instantiate and somehow manage Crossbar instance from my Python code? For instance I have a Python launcher script where I want to setup setting from Crossbar and then run it. In other words, is there ability to use Crossbar as a Python package?

0 Likes

#12

I understood that if we modify the code then we need to share that changes,
that is perfectly fine with us. Consider we do not modify any code, can we
redistribute Crossbar.io within package of our commercial software? For
example, we cannot do this with libraries licensed under GPL, but we can
for LGPL, What about AGPL? I could not find clear answer for that yet...

If you _link_ a AGPL _library_ from your code, you are creating a "derived work", and hence the GPL applies to your code.

If you talk to a AGPL _application_ over a _network connection_, you are not creating a derived work, and hence the GPL does not apply to your code.

Crossbar.io is a _application_ in above sense, and when you talk to it via a WAMP transport (a network connection, including loopback TCP or Unix domain socket) from your app, your app isn't affected by the AGPL, and hence you can redistribute the whole thing (including Crossbar.io).

This is what we explicitly state here:

http://crossbar.io/docs/Crossbar-License/#wamp-clients-as-separate-works

If you directly import a Crossbar.io Python class or function from your Python code, you are creating a derived work, and the AGPL applies to your code.

Independent of above, if you want to use the name "Crossbar.io", then this is about our trademark, and unless you are using it under the doctrine of "fair use", you should contact us first.

4)
you cannot use the management API and it's components which is embedded
inside Crossbar.io, because we have a copyright on the _API_

https://github.com/crossbario/crossbar/blob/master/LICENSE-FOR-API

The management API of Crossbar.io is used internally including for the
node configuration. We have a version of Crossbar.io upcoming that
allows dynamic and remote reconfiguration of Crossbar.io via that
management API.

I didn't even know there is such API :slight_smile:

Yeah, it isn't something we talk about now a lot, because this is still "upcoming":wink:

It is a very powerful feature, in particular, because that meta management API will be exposed to users via WAMP itself. Stay tuned ..

Actually, there is another question, can I instantiate and somehow manage
Crossbar instance from my Python code? For instance I have a Python
launcher script where I want to setup setting from Crossbar and then run
it. In other words, is there ability to use Crossbar as a Python package?

If you start Crossbar.io from your Python code like this:

os.system('crossbar start')

that is perfectly fine. You can generate a Crossbar.io config.json in your app, and then _fork_ it like above. The critical point is: you must use the "crossbar" executable to start it.

If you do

from crossbar... import xxx

you are creating a derived work, and the AGPL applies to your code.

_Technically_, you can do this (as long as you honor the AGPL which appies to your code too in this case) - we cannot stop you;) This is open-source.

But we strongly discourage that. It is unsupported. Don't do it. Crossbar.io should be considered a "black box server" (like Nginx), and everything within Crossbar.io can change at any time. There is no Python API to Crossbar.io itself.

You should treat Crossbar.io like a black box, and the fact that it is implemented in Python is a detail. Which can change in the future.

If you have further questions, please don't hesitate.

Cheers,
/Tobias

@Alex: we should add these Q and explanations to our FAQ (maybe a section for "product embedding" or such).

0 Likes

#13

Dear Tobias,

thank you for detailed reply. The reason I am asking is because I did such research recently in order to understand if we are allowed to redistribute MongoDB as a part of our commercial desktop application, and we found the following statement here:

  • There are no restrictions if you are using the mongodb.org drivers, not making any modifications to the core server code, and not redistributing/embedding the MongoDB server.
  • If
    you are redistributing the core server package, deploying MongoDB Enterprise server, or embedding the MongoDB server in an OEM or installable commercial solution you will probably need commercial licenses and should Contact MongoDB for follow-up.

Since both Crossbar.io and MongoDB are licensed under GNU AGPL v3, I am a little bit scared.

···

четверг, 19 января 2017 г., 0:55:55 UTC+3 пользователь Tobias Oberstein написал:

I understood that if we modify the code then we need to share that changes,

that is perfectly fine with us. Consider we do not modify any code, can we

redistribute Crossbar.io within package of our commercial software? For

example, we cannot do this with libraries licensed under GPL, but we can

for LGPL, What about AGPL? I could not find clear answer for that yet…

If you link a AGPL library from your code, you are creating a
“derived work”, and hence the GPL applies to your code.

If you talk to a AGPL application over a network connection, you are
not creating a derived work, and hence the GPL does not apply to your code.

Crossbar.io is a application in above sense, and when you talk to it
via a WAMP transport (a network connection, including loopback TCP or
Unix domain socket) from your app, your app isn’t affected by the AGPL,
and hence you can redistribute the whole thing (including Crossbar.io).

This is what we explicitly state here:

http://crossbar.io/docs/Crossbar-License/#wamp-clients-as-separate-works

If you directly import a Crossbar.io Python class or function from your
Python code, you are creating a derived work, and the AGPL applies to
your code.

Independent of above, if you want to use the name “Crossbar.io”, then
this is about our trademark, and unless you are using it under the
doctrine of “fair use”, you should contact us first.

you cannot use the management API and it’s components which is embedded

inside Crossbar.io, because we have a copyright on the API

https://github.com/crossbario/crossbar/blob/master/LICENSE-FOR-API

The management API of Crossbar.io is used internally including for the

node configuration. We have a version of Crossbar.io upcoming that

allows dynamic and remote reconfiguration of Crossbar.io via that

management API.

I didn’t even know there is such API :slight_smile:

Yeah, it isn’t something we talk about now a lot, because this is still
“upcoming”:wink:

It is a very powerful feature, in particular, because that meta
management API will be exposed to users via WAMP itself. Stay tuned …

Actually, there is another question, can I instantiate and somehow manage

Crossbar instance from my Python code? For instance I have a Python

launcher script where I want to setup setting from Crossbar and then run

it. In other words, is there ability to use Crossbar as a Python package?

If you start Crossbar.io from your Python code like this:

os.system(‘crossbar start’)

that is perfectly fine. You can generate a Crossbar.io config.json in
your app, and then fork it like above. The critical point is: you must
use the “crossbar” executable to start it.

If you do

from crossbar… import xxx

you are creating a derived work, and the AGPL applies to your code.

Technically, you can do this (as long as you honor the AGPL which
appies to your code too in this case) - we cannot stop you;) This is
open-source.

But we strongly discourage that. It is unsupported. Don’t do it.
Crossbar.io should be considered a “black box server” (like Nginx), and
everything within Crossbar.io can change at any time. There is no Python
API to Crossbar.io itself.

You should treat Crossbar.io like a black box, and the fact that it is
implemented in Python is a detail. Which can change in the future.

If you have further questions, please don’t hesitate.

Cheers,

/Tobias

@Alex: we should add these Q and explanations to our FAQ (maybe a
section for “product embedding” or such).

0 Likes

#14

Dear Tobias, thank for pointing out on service discovery solutions. I did read a little about them. After reading docs and playing with Crossbar.io I’ve cane to the following understanding. I would like to provide "port": 0 to the router itself and then make components (speaking in Crossbar terms), to somehow connect to it without declaring explicit port numbers. So I think config could be like the following:

"workers": [{
        "type": "router",
...
        "transports": [{
...
            "endpoint": {
                "type": "tcp",
                "port": 0
                "id": 42   <--- here is the kluge
            },
...
        "components": [{
            "type": "class",
            "classname": "...",
            "transport": {
                ...
                "endpoint": {
                    "type": "tcp",
                    "id": 42,  <--- here is the kluge
                },

In such a case I could use Crossbar.io as both router and process manager. I think I could try to implement the thing like this if you think it is feasible. That is why I am asking for advice. Is that possible at all? I mean, there could be underlying difficulties. For example, as far as I see, all the workers start in parallel, but in such case components need to wait at least until router gets the port number, which is (I suppose) rather hard to overcome. What do you think?

Alternative solution I have is to use circus (since it has Python API and I can customize the bootstrap process) and start Crossbar controller on manually generated configuration files: start Crossbar router, wait until it gets ports, get the notification about this (I already implemented this in my local Crossbar fork); once I have a port number - generate configurations for other workers, run controllers for each worker separately. This could probably work, but complicates the whole setup.

···

воскресенье, 15 января 2017 г., 22:46:36 UTC+3 пользователь Tobias Oberstein написал:

Am 15.01.2017 um 20:22 schrieb Alexander Prokhorov:

let browser know the port webserver is bound on

This sounds like chicken/egg … a URL (including host/port) is supposed
to be “well-known”.

Honestly, I don’t see much value in going down this road in your
scenario (or I don’t understand it fully):

simply allow the user to specify the port to use at installation time
and generate appropriate node configuration …

That being said, I think the feature you might want to have is

https://en.wikipedia.org/wiki/Zero-configuration_networking#DNS-SD_with_multicast

https://github.com/crossbario/crossbar/issues/240

If we had DNS-SD in Crossbar.io, the router (transport) could be
discovered automatically by WAMP clients on the local network.

Then again I don’t know about non-Safari browser support

Quickly googling turns up

https://developer.chrome.com/apps/mdns

But hey:

https://www.w3.org/TR/discovery-api/

A first step would be to research above a little deeper … in essence,
it’s about service discovery on local networks where the service is a
Crossbar.io WAMP routing listening transport.

Cheers,

/Tobias

0 Likes

#15

Just remark, I am speaking of course about components running in a native container, not in the system process of the router.

···

четверг, 19 января 2017 г., 18:09:19 UTC+3 пользователь Alexander Prokhorov написал:

Dear Tobias, thank for pointing out on service discovery solutions. I did read a little about them. After reading docs and playing with Crossbar.io I’ve cane to the following understanding. I would like to provide "port": 0 to the router itself and then make components (speaking in Crossbar terms), to somehow connect to it without declaring explicit port numbers. So I think config could be like the following:

"workers": [{
        "type": "router",
...
        "transports": [{
...
            "endpoint": {
                "type": "tcp",
                "port": 0
                "id": 42   <--- here is the kluge
            },
...
        "components": [{
            "type": "class",
            "classname": "...",
            "transport": {
                ...
                "endpoint": {
                    "type": "tcp",
                    "id": 42,  <--- here is the kluge
                },

In such a case I could use Crossbar.io as both router and process manager. I think I could try to implement the thing like this if you think it is feasible. That is why I am asking for advice. Is that possible at all? I mean, there could be underlying difficulties. For example, as far as I see, all the workers start in parallel, but in such case components need to wait at least until router gets the port number, which is (I suppose) rather hard to overcome. What do you think?

Alternative solution I have is to use circus (since it has Python API and I can customize the bootstrap process) and start Crossbar controller on manually generated configuration files: start Crossbar router, wait until it gets ports, get the notification about this (I already implemented this in my local Crossbar fork); once I have a port number - generate configurations for other workers, run controllers for each worker separately. This could probably work, but complicates the whole setup.

воскресенье, 15 января 2017 г., 22:46:36 UTC+3 пользователь Tobias Oberstein написал:

Am 15.01.2017 um 20:22 schrieb Alexander Prokhorov:

let browser know the port webserver is bound on

This sounds like chicken/egg … a URL (including host/port) is supposed
to be “well-known”.

Honestly, I don’t see much value in going down this road in your
scenario (or I don’t understand it fully):

simply allow the user to specify the port to use at installation time
and generate appropriate node configuration …

That being said, I think the feature you might want to have is

https://en.wikipedia.org/wiki/Zero-configuration_networking#DNS-SD_with_multicast

https://github.com/crossbario/crossbar/issues/240

If we had DNS-SD in Crossbar.io, the router (transport) could be
discovered automatically by WAMP clients on the local network.

Then again I don’t know about non-Safari browser support

Quickly googling turns up

https://developer.chrome.com/apps/mdns

But hey:

https://www.w3.org/TR/discovery-api/

A first step would be to research above a little deeper … in essence,
it’s about service discovery on local networks where the service is a
Crossbar.io WAMP routing listening transport.

Cheers,

/Tobias

0 Likes