custom WAMP router/service for small hardware appliance

[da...@lorenso.com]

I've been spending time designing a web client that can interact with a small hardware appliance using WAMP protocol, but thus far, most of the work is simply design and not a lot of coding.  We are almost ready to move into coding phase, but I still have a few details that need work before I am entirely confident in the architecture.  First, I have a few questions about security, performance, and licensing maybe you can help me clear up.

For this project, all "clients" are just web browsers using Autobahn|JS to connect to a WAMP "router/service".  The "server" is an application running on the device hardware that must be lightweight, speak the WAMP protocol, and implement pub/sub and req/rep patterns for the purpose of working with Autobahn|JS and reducing the amount of client-side library development that must be done.  This project is mostly just client/server in the sense that:

 - client = Caller, Subscriber

 - server = Callee, Publisher

Because of this model, I don't think I really need the Dealer/Broker patterns but you may convince me otherwise.

The "server" component will need to use custom C/C++ libraries to execute functions specific to the hardware of the device, but need not necessarily route procedure calls between clients.  Since all procedures are to be executed on the server side only, the clients will not need to 'register' any procedures.  Clients will simply subscribe to topics and call procedures.  Meanwhile, the "server" component will be the only part that can publish events and will process and respond to procedures.

1) security:

I'd like to have an 'authenticate' method that is first called by the client application to initialize ACL permissions for the TCP/Websocket session.  That means taking a username/password and responding with success or failure.  This would be implemented with a simple call to something like:

  com.domain.auth.authenticate (string username, string password) --> [int result, string error_message]

My question is, can the WAMP router or internal client functions get access to the Session_ID for purpose of tracking session information associated with this connection?  In a web PHP/Apache model, after authenticating a user, we would normally set a $_SESSION['auth_id'] = 1234 value that can be accessed and referenced on subsequent page calls.  This $_SESSION data can be stored server-side in either files, mysql database, or memcached, etc.  Is there comparable session-level variable storage with WAMP routers?  

If the WAMP spec doesn't want to worry about storage of session data, that's fine with me, we can implement our own session storage using files, memcached, or mysql, etc but in order to tap into that storage data, we need at least access to a 'session id' value.  Again in the PHP web model, this is managed by setting an HTTP cookie to track the session id between page requests.

If the "server" component of my project is broken into 2 parts (a router and a backend client), then the simple diagram looks as follows:

  backend client(Cpp) <-----> WAMP router <---> front-end client/gui (Js)

But from that design, it looks like there will be a TCP connection from the WAMP router to the front-end client/gui where I would expect a "session id" to be bound ... and that would be a different TCP connection from the one between the WAMP router and the backend client.  So, if all my procedures are implemented by the backend client, how does the backend client track the session associated with the front-end client that is making the actual calls and how do I implement ACL security on my procedure calls?  I don't want to have to pass a token to every procedure call when the session tracking, ideally, would be transparent and embedded in the transport layer itself.

2) performance:

The hardware we are using is minimal low-power chips and ram.  We have a very basic and stripped down Linux running, but there is no apt or yum packaging.  I'd prefer to use as few packages as possible with the least amount of LOC possible in order to implement the server-side WAMP router/service.  I don't even think I should *have* to separate the WAMP router from the actual server-side procedure implementations (in other words, I don't really want to have to create a separate backend client and router process).  What I'm imagining would be all client procedures somehow built into the router itself and have the router's functionality crippled so that it no longer serves the full roles of broker or dealer.

Similarly, I'd like to have just 1 daemon process running on the hardware that listens on a port and executes all called procedures internally where the only daemon process can be as lightweight as possible and preferably written in C/C++.  I know Crossbar exists, and there is an Autobahn|Cpp client, but is there a skeleton C/C++ WAMP Router implementation that can be modded similar to the service I intend to create?  It doesn't seem like the WAMP API is terribly complex, so perhaps there is a project similar to Thruway/PHP but for C/C++?  I'd like to avoid having to add a new language dependency (like Python) and external libraries just for this project because device storage is already limited enough as it is and for the next reason, we want to limit our dependency on 3rd party libraries as much as reasonably possible.

3) licensing:

If we intend to sell the hardware appliance and license the software, the WAMP protocol, Autobahn|JS, and possibly WAMP router implementation are created and licensed with the purpose of allowing that?

-- Dante

[Tobias Oberstein]

Hi Dante,

Am 09.01.2015 um 02:05 schrieb da...@lorenso.com:
> I've been spending time designing a web client that can interact with a
> small hardware appliance using WAMP protocol, but thus far, most of the
> work is simply design and not a lot of coding. We are almost ready to
> move into coding phase, but I still have a few details that need work
> before I am entirely confident in the architecture. First, I have a few
> questions about security, performance, and licensing maybe you can help
> me clear up.

Sure, will try.

>
> For this project, all "clients" are just web browsers using Autobahn|JS
> to connect to a WAMP "router/service". The "server" is an application
> running on the device hardware that must be lightweight, speak the WAMP
> protocol, and implement pub/sub and req/rep patterns for the purpose of
> working with Autobahn|JS and reducing the amount of client-side library
> development that must be done. This project is mostly just

Ok.

> client/server in the sense that:
>
> - client = Caller, Subscriber
> - server = Callee, Publisher
>
> Because of this model, I don't think I really need the Dealer/Broker
> patterns but you may convince me otherwise.

If you need PubSub, then you need a broker.

It's a different questions where that brokers runs, and how it is
structured compared to your app code (subscriber).

A broker might be:

- a separate OS process external to your app code process (the subscriber)
- running inside the same OS process that runs your app code (the
subscriber code), but still logically separated from the app code

In both cases, you do have a broker.

>
> The "server" component will need to use custom C/C++ libraries to
> execute functions specific to the hardware of the device, but need not
> necessarily route procedure calls between clients. Since all procedures
> are to be executed on the server side only, the clients will not need to
> 'register' any procedures. Clients will simply subscribe to topics and
> call procedures. Meanwhile, the "server" component will be the only
> part that can publish events and will process and respond to procedures.

You seem to have a quite restricted set of functionality/requirements -
_today_. I am not sure it is wise to assume those will stay like this
forever, and then deliberately cripple the underlying foundation - for
what gain?

>
> 1) security:
>
> I'd like to have an 'authenticate' method that is first called by the
> client application to initialize ACL permissions for the TCP/Websocket
> session. That means taking a username/password and responding with
> success or failure. This would be implemented with a simple call to
> something like:
>
> com.domain.auth.authenticate (string username, string password) -->
> [int result, string error_message]

Implementing authentication at the RPC level is the wrong approach. WAMP
has authentication at the beginning of WAMP session built right into the
protocol.

https://github.com/tavendo/WAMP/blob/master/spec/advanced.md#wamp-challenge-response-authentication

This is supported by AutobahnJS and Crossbar.io for example.

>
> My question is, can the WAMP router or internal client functions get
> access to the Session_ID for purpose of tracking session information
> associated with this connection? In a web PHP/Apache model, after
> authenticating a user, we would normally set a $_SESSION['auth_id'] =
> 1234 value that can be accessed and referenced on subsequent page calls.
> This $_SESSION data can be stored server-side in either files, mysql
> database, or memcached, etc. Is there comparable session-level variable
> storage with WAMP routers?

This is an internal implementation detail within routers not exposed to
apps. But see above how to do authentication.

E.g. the way you do authentication using Crossbar.io with custom app
code is by "doing dynamic authentication":

http://crossbar.io/docs/WAMP-CRA-Authentication/

You write a regular WAMP component that will then authenticate _other_
components.

In the former, you can do anthing you like: authenticate against "Foobar
Auth DB" whatevr.

>
> If the WAMP spec doesn't want to worry about storage of session data,
> that's fine with me, we can implement our own session storage using
> files, memcached, or mysql, etc but in order to tap into that storage
> data, we need at least access to a 'session id' value. Again in the PHP
> web model, this is managed by setting an HTTP cookie to track the
> session id between page requests.

You can access session IDs in any WAMP exposed procedure or event
handler via the "details" (Caller Details, Publisher Details) if the
router and client libs used supports this feature from the WAMP Advanced
Profile, which is the case e.g. for AutobahnXXX and Crossbar.io.

>
> If the "server" component of my project is broken into 2 parts (a router
> and a backend client), then the simple diagram looks as follows:
>
> backend client(Cpp) <-----> WAMP router <---> front-end client/gui (Js)
>
> But from that design, it looks like there will be a TCP connection from
> the WAMP router to the front-end client/gui where I would expect a
> "session id" to be bound ... and that would be a different TCP
> connection from the one between the WAMP router and the backend client.

WAMP session IDs are not "bound" to a point-to-point WAMP transport like
TCP, but the WAMP session.

> So, if all my procedures are implemented by the backend client, how
> does the backend client track the session associated with the front-end
> client that is making the actual calls and how do I implement ACL
> security on my procedure calls? I don't want to have to pass a token to

See above. Then, authorization of WAMP procedure calls, publication,
subscription is there already.

E.g. Crossbar.io supports both "static authorization" and "dynamic
authorization". The former has fixed permissions configured via config,
the latter allows you to hook up custom authorization procedures into
Crossbar.io

http://crossbar.io/docs/Authorization/

> every procedure call when the session tracking, ideally, would be
> transparent and embedded in the transport layer itself.
>
> 2) performance:
>
> The hardware we are using is minimal low-power chips and ram. We have a

In general, for performance on small devices, here are benchmarks on the
RaspberryPi: http://tavendo.com/blog/post/autobahn-pi-benchmark/

> very basic and stripped down Linux running, but there is no apt or yum
> packaging. I'd prefer to use as few packages as possible with the least

What exactly is the device? Something like Intel Edison?

> amount of LOC possible in order to implement the server-side WAMP
> router/service. I don't even think I should *have* to separate the WAMP
> router from the actual server-side procedure implementations (in other
> words, I don't really want to have to create a separate backend client
> and router process). What I'm imagining would be all client procedures

Why?

> somehow built into the router itself and have the router's functionality
> crippled so that it no longer serves the full roles of broker or dealer.

No. I don't think "crippling" is the right approach.

>
> Similarly, I'd like to have just 1 daemon process running on the
> hardware that listens on a port and executes all called procedures
> internally where the only daemon process can be as lightweight as
> possible and preferably written in C/C++. I know Crossbar exists, and
> there is an Autobahn|Cpp client, but is there a skeleton C/C++ WAMP
> Router implementation that can be modded similar to the service I intend
> to create? It doesn't seem like the WAMP API is terribly complex, so

FWIW, WAMP is a protocol, not an API.

> perhaps there is a project similar to Thruway/PHP but for C/C++? I'd

There is no C++ router (currently). But I think Emile is working on one.

However: what you describe above ("crippled") is nothing we would
encourage. In fact, we wouldn't allow a "crippled router" to claim to be
a "WAMP router". This is to protect the integrity of the WAMP ecosystem.

> like to avoid having to add a new language dependency (like Python) and
> external libraries just for this project because device storage is
> already limited enough as it is and for the next reason, we want to
> limit our dependency on 3rd party libraries as much as reasonably possible.
>
> 3) licensing:
>
> If we intend to sell the hardware appliance and license the software,
> the WAMP protocol, Autobahn|JS, and possibly WAMP router implementation
> are created and licensed with the purpose of allowing that?

All our stuff is open-source, under Apache license (AutobahnXXX) and
AGPL (Crossbar.io) and Creative Commons (WAMP Spec).

Of course you can use this in a commercial, closed-source project. Since
app code is only "linked" with Apache licensed libs (AutobahnXXX), your
proprietory, closed code can stay like this (no "infection"). If you
modify Crossbar.io _itself_, then you will need to comply to the terms
set forth in AGPL.

The only thing we will not allow is to use the trademark "WAMP" for
stuff that actually isn't WAMP - because it's crippled. That would hurt
the ecosystem.

Note that we didn't had to enforce this up to now - in all (very few)
cases where people wanted to "cripple", a technical discussion in the
end was convincing enough. I really want to stress this: I want to
convince, not force.

However, that being said, if you don't like the core WAMP design, which
includes paradigms like "routers for decoupling" and "no app code in
routers", then WAMP probably isn't for you.

I usually go to any length of discussion convincing people WAMP is great
and the WAMP principles make sense - but I won't support crippling WAMP
just to win users.

Cheers,
/Tobias


>
> -- Dante
>
>
>
> --
> 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/d2dd1780-f153-4761-8bbd-9dedf6ecb648%40googlegroups.com
> <https://groups.google.com/d/msgid/wampws/d2dd1780-f153-4761-8bbd-9dedf6ecb648%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[da...@lorenso.com]

On Friday, January 9, 2015 at 10:43:53 AM UTC+4, Tobias Oberstein wrote:

> The "server" component will need to use custom C/C++ libraries to
> execute functions specific to the hardware of the device, but need not
> necessarily route procedure calls between clients.  Since all procedures
> are to be executed on the server side only, the clients will not need to
> 'register' any procedures.  Clients will simply subscribe to topics and
> call procedures.  Meanwhile, the "server" component will be the only
> part that can publish events and will process and respond to procedures.

You seem to have a quite restricted set of functionality/requirements -
_today_. I am not sure it is wise to assume those will stay like this
forever, and then deliberately cripple the underlying foundation - for
what gain?

I have been working on the design based on your feedback and I guess the word that should have used is 'disabling' features rather than crippling the foundation.  As I'm studying the Authentication and Authorization parts of Crossbar.io, it looks as if you already had this plan built in.  By setting a role for a connected client, we can turn off 'publish' and 'register' functionality from all front-end clients.  This toggling of functionality by role is the limitation of functionality that I appear to be seeking.

  

> 1) security:
>
> I'd like to have an 'authenticate' method that is first called by the
> client application to initialize ACL permissions for the TCP/Websocket
> session.  That means taking a username/password and responding with
> success or failure.  This would be implemented with a simple call to
> something like:
>
>    com.domain.auth.authenticate (string username, string password) -->
> [int result, string error_message]

Implementing authentication at the RPC level is the wrong approach. WAMP
has authentication at the beginning of WAMP session built right into the
protocol.
https://github.com/tavendo/WAMP/blob/master/spec/advanced.md#wamp-challenge-response-authentication
This is supported by AutobahnJS and Crossbar.io for example.

I'm leaning toward Crossbar as I dig into it further.  We are having a lot of trouble trying to compile python and all its dependencies just to get pip and use it to install crossbar.  If my guys can manage to get crossbar running on the hardware, I think we'll use it as-is out of the box with some configs to define dynamic authentication and dynamic authorization functions.

We want to concentrate development on the clients (front-end and back-end) and not the router, anyhow.  I'm also trying to sell the idea of using more distributed back-end clients with limited focus so we can have more modules with fewer functions each.

> 2) performance:
> The hardware we are using is minimal low-power chips and ram.  We have a

In general, for performance on small devices, here are benchmarks on the
RaspberryPi: http://tavendo.com/blog/post/autobahn-pi-benchmark/

> very basic and stripped down Linux running, but there is no apt or yum
> packaging.  I'd prefer to use as few packages as possible with the least

What exactly is the device? Something like Intel Edison?

We are trying to compile Python 2.7.9 for A20 Linux sunxi.  These are ARM processors, not the typical x86.  So, in the end, maybe the fact Crossbar is written in Python might be an advantage ... it might be more likely we can get Python running than we'd have been able to get a Crossbar/CPP build to cross-compile.  I don't know until we get something working, however.

 

> perhaps there is a project similar to Thruway/PHP but for C/C++?  I'd

There is no C++ router (currently). But I think Emile is working on one.

 

Emile!  Who are you and do you have anything to show yet?  It'd be great if there were a Crossbar that could be downloaded, untar-gzipped, ./configure, make, make install ...  I think if that existed, such a router would be installable as is memcache or beanstalk.  And in the end, it'd be great to be able to apt-get install crossbar to get it up and running on a new Ubuntu server.  We can dream ...

-- Dante

[Joshua Elliott]

Depending on your timeline, you may want to check out Turnpike. While not quite production-ready, our WAMPv2 implementation is nearly complete. It's implemented in Go, which is *very* easy to cross-compile for ARM. When we complete our WAMPv2 Basic milestone we should have pre-compiled binaries for ARM.

--
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.
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/5d094d26-76e3-4e76-9356-03ee0726c15f%40googlegroups.com.

[Paul Fryer]

I would also love to see a version of crossbar that can be downloaded and installed (especially on windows). At this point from what I can tell I have to build it from source and install it that way - so the bar is currently high. I look forward to a more streamlined installation process for the server / router side components. 

Paul

[Tobias Oberstein]

> I have been working on the design based on your feedback and I guess the
> word that should have used is 'disabling' features rather than crippling
> the foundation. As I'm studying the Authentication and Authorization
> parts of Crossbar.io, it looks as if you already had this plan built in.
> By setting a role for a connected client, we can turn off 'publish'
> and 'register' functionality from all front-end clients. This toggling

Yes. You can turn off an action (like register) altogether just by
appropriate permissions configuration for the role the client
authenticates under.

> of functionality by role is the limitation of functionality that I
> appear to be seeking.

Ah, ok. Well, that is definitely not crippling, but limiting
permissions, and this is of course a perfectly fine thing to do.

> I'm leaning toward Crossbar as I dig into it further. We are having a
> lot of trouble trying to compile python and all its dependencies just to
> get pip and use it to install crossbar. If my guys can manage to get

Cross-compiling Python for something "exotic" (OS-wise) might require
some fiddling, yes. But if the target is anything Posix like, it should
be too too hard. Of course, running on a Pi (Debian) is way easier. But
Python (and Crossbar.io) even runs on the Arduino Yun, a tiny
Mips/OpenWrt platform.

Getting a full Boost/Asio cross-compiled to exotic stuff can make life
hard too. Different from a hello.c for sure.

But I understand your situation.

> crossbar running on the hardware, I think we'll use it as-is out of the
> box with some configs to define dynamic authentication and dynamic
> authorization functions.

Personally, I think having the ability to plug custom/dynamic
authentication and authorization into Crossbar.io by just writing a
standard WAMP component in any language open up tremendous flexibility -
and without compromising the "routers must not contain app code" paradigm.

>
> We want to concentrate development on the clients (front-end and
> back-end) and not the router, anyhow. I'm also trying to sell the idea

This is a wise approach;) Let others do the hard work on routers.

> of using more distributed back-end clients with limited focus so we can
> have more modules with fewer functions each.

Absolutely! Think "microservices". Even if only on a device, that kind
of decoupling brings advantages. Not to speak of isolating wrt to
security and resource consumption.

> We are trying to compile Python 2.7.9 for A20 Linux sunxi. These are
> ARM processors, not the typical x86. So, in the end, maybe the fact

This hardware has a _lot_ more power than the RaspberryPi. Not to speak
of the Arduino Yun.

> Crossbar is written in Python might be an advantage ... it might be more
> likely we can get Python running than we'd have been able to get a
> Crossbar/CPP build to cross-compile. I don't know until we get
> something working, however.

From the hardware, there should be no problem at all. Since it's ARM,
you might even run PyPy.

There seems to be multiple OSs available (Linux derivates, Android, BSDs)

including Debian

https://wiki.debian.org/InstallingDebianOn/Allwinner

Did you try the latter?

>
> > perhaps there is a project similar to Thruway/PHP but for C/C++?
> I'd
>
> There is no C++ router (currently). But I think Emile is working on one.
>
> Emile! Who are you and do you have anything to show yet? It'd be great

https://github.com/ecorm

> if there were a Crossbar that could be downloaded, untar-gzipped,
> ./configure, make, make install ... I think if that existed, such a
> router would be installable as is memcache or beanstalk. And in the
> end, it'd be great to be able to apt-get install crossbar to get it up
> and running on a new Ubuntu server. We can dream ...

rpm/deb Crossbar.io packages are upcoming.

I already go it packaged (rpm, fully self-contained, PyPy!). Just needs
a little more love before releasing and automation.

/Tobias

>
> -- Dante
>
> --
> 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/5d094d26-76e3-4e76-9356-03ee0726c15f%40googlegroups.com
> <https://groups.google.com/d/msgid/wampws/5d094d26-76e3-4e76-9356-03ee0726c15f%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Tobias Oberstein]

Hi Paul,

Am 12.01.2015 um 21:41 schrieb Paul Fryer:
> I would also love to see a version of crossbar that can be downloaded
> and installed (especially on windows). At this point from what I can

Windows? Easy: we've recently simplified installation:
http://crossbar.io/docs/Installation-on-Windows/

> tell I have to build it from source and install it that way - so the bar
> is currently high. I look forward to a more streamlined installation
> process for the server / router side components.

You mean, how to deploy WAMP app components into an already installed,
possibly running Crossbar.io node?

/Tobias

> --
> 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/ca11d73f-8d3f-43e1-8d1b-5647cc8a29c4%40googlegroups.com
> <https://groups.google.com/d/msgid/wampws/ca11d73f-8d3f-43e1-8d1b-5647cc8a29c4%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Emile Cormier]

On Monday, January 12, 2015 at 3:57:46 PM UTC-4, da...@lorenso.com wrote:

Emile!  Who are you and do you have anything to show yet?  It'd be great if there were a Crossbar that could be downloaded, untar-gzipped, ./configure, make, make install ...  I think if that existed, such a router would be installable as is memcache or beanstalk.  And in the end, it'd be great to be able to apt-get install crossbar to get it up and running on a new Ubuntu server.  We can dream ...

-- Dante

Dante, I stumbled upon this thread while searching for something else and saw my name. I've just released the first version of CppWamp at  https://github.com/ecorm/cppwamp. It is client-only, and currently only supports the basic WAMP profile (in addition to raw socket transports, which are part of the advanced profile). I'm current making breaking changes to the API, so be prepared to update your code if you intend to try my library (or wait a little while until I release v0.2.0).

At work, we'll be using the Crossbar.io router in the foreseeable future, so there are no plans to release a C++-based router anytime soon. I might implement a C++-based router in my spare time, but I have no idea how long it would take me. We'd love to have a natively compiled router that doesn't depend on an interpreter or some other kind of runtime, because it would greatly simplify firmware updates.

The CppWAMP library was designed to be usable in implementing a router. One would have to write a RouterSession class that derives from internal::Session and implement the dealer/broker functionality. The RouterSession instances would have to share information with a common Router object. I really haven't put that much thought yet on the router architecture, but hopefully a lot of the stuff from internal::Session can be used as-is.

Cheers,

Emile Cormier

[Elvis Stansvik]

On Tuesday, April 7, 2015 at 6:17:41 AM UTC+2, Emile Cormier wrote:

On Monday, January 12, 2015 at 3:57:46 PM UTC-4, da...@lorenso.com wrote:

Emile!  Who are you and do you have anything to show yet?  It'd be great if there were a Crossbar that could be downloaded, untar-gzipped, ./configure, make, make install ...  I think if that existed, such a router would be installable as is memcache or beanstalk.  And in the end, it'd be great to be able to apt-get install crossbar to get it up and running on a new Ubuntu server.  We can dream ...

-- Dante

Dante, I stumbled upon this thread while searching for something else and saw my name. I've just released the first version of CppWamp at  https://github.com/ecorm/cppwamp. It is client-only, and currently only supports the basic WAMP profile (in addition to raw socket transports, which are part of the advanced profile). I'm current making breaking changes to the API, so be prepared to update your code if you intend to try my library (or wait a little while until I release v0.2.0).

At work, we'll be using the Crossbar.io router in the foreseeable future, so there are no plans to release a C++-based router anytime soon. I might implement a C++-based router in my spare time, but I have no idea how long it would take me. We'd love to have a natively compiled router that doesn't depend on an interpreter or some other kind of runtime, because it would greatly simplify firmware updates.

I also know there's a guy Dave working on a C++ router, but he hasn't published anything yet. See the thread starting here: http://wamp.ws/implementations/#comment-1782395989

Elvis

[Emile Cormier]

On Wednesday, April 15, 2015 at 5:35:51 AM UTC-3, Elvis Stansvik wrote:

I also know there's a guy Dave working on a C++ router, but he hasn't published anything yet. See the thread starting here: http://wamp.ws/implementations/#comment-1782395989

Yes, I've been in touch with him. I'm eager to see what he's come up with.

[Elvis Stansvik]

Me too :) 

[David Chappelle]

Just making a final decision on a license. Expect a release early next week.

[Kevin Endrijaitis]

Tobias,

I am working on a home project and I want my yun to host crossbar.io.  I'm having trouble with the generic Linux installation instructions.  Could you possibly provide instructions for yun?

TIA,

Kevin

[Alexander Gödde]

Hi Kevin!

First of all sorry for the late reply. 

While we did get Crossbar to run on the Yun a while back, we're not really using the Yun except for as a WAMP client. Were specifically do things start to go wrong for you during the install?

Regards,

Alex

[David Chappelle]

If you are unable to get crossbario working, another option is to use bonefish which is the c++ based wamp router available here:

    https://github.com/tplgy/bonefish 

Regards,

Dave

--
You received this message because you are subscribed to a topic in the Google Groups "WAMP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wampws/CB6DSOL2oZk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wampws+un...@googlegroups.com.

To post to this group, send email to wam...@googlegroups.com.

Visit this group at https://groups.google.com/group/wampws.

To view this discussion on the web visit https://groups.google.com/d/msgid/wampws/c03e1d09-e091-468a-82bd-9567daf7e1b3%40googlegroups.com.