Autobahn|CPP WAMP Routers

[David Chappelle]

New to the whole concept of WAMP and very intrigued by the Autobahn project. I have the following questions:

1. Do I need a WAMP router or can I do direct communication between peers/nodes?

2. Is there a c++ WAMP router anyone would recommend?

3. Difficulty level of implementing a simple WAMP router?

[Tobias Oberstein]

Hi David,

thanks! and welcome;)

1. Yes. However, you can have all components and a router in a single process talking over a function-call based pseudo transport.
2. There is none to my knowledge.
3. A basic router for dev and demo purposes: medium. A production quality, secure and scalable one: non trivial.

Cheers,
/Tobias

Sent from Mobile (Google Nexus 5)

--
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/6c3d6b38-bdbb-41f6-b6da-8465b8c9c381%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Chappelle]

I am very curious about the option to have all components and a router talking over a function-call based psuedo transport. Currently I am working with RPC setup in a very similar fashion with all of it running in the same process however it is using tcp sockets currently. Can you explain more about what a function-call based pseudo transport would look like? Simple call + future paradigm?

[Tobias Oberstein]

Am 21.11.2014 20:43, schrieb David Chappelle:
> I am very curious about the option to have all components and a router
> talking over a function-call based psuedo transport. Currently I am
> working with RPC setup in a very similar fashion with all of it running
> in the same process however it is using tcp sockets currently. Can you
> explain more about what a function-call based pseudo transport would
> look like? Simple call + future paradigm?

Crossbar.io uses a function-based pseudo transport to run Python WAMP
components inside a router process (this is called side-by-side/embedded
mode).

For this, e.g. a component doing a publish() will have a code path
directly into the routing core - no WAMP serialization at all.

Obviously, this only works for same-language (Python) components.

Thruway (a PHP WAMP router) has similar facilities. Sony is doing
similar with Kadecot (Java) for structuring their app even internally
into components (see the links on the landing page http://wamp.ws/).

Crossbar.io also supports running WAMP over Unix domain sockets, and
this, when using RawSocket+MsgPack for framing/serialization is very
efficient and low-latency. It is also language agnostic.

All of above was intended and by design: the WAMP principles are simple
enough to be applied to a lot of implementation options.

>
> On Friday, 21 November 2014 14:20:49 UTC-5, Tobias Oberstein wrote:
>
> Hi David,
>
> thanks! and welcome;)
>
> 1. Yes. However, you can have all components and a router in a
> single process talking over a function-call based pseudo transport.
> 2. There is none to my knowledge.
> 3. A basic router for dev and demo purposes: medium. A production
> quality, secure and scalable one: non trivial.
>
> Cheers,
> /Tobias
>
> Sent from Mobile (Google Nexus 5)
>
> Am 21.11.2014 18:45 schrieb "David Chappelle" <chap...@gmail.com

> <javascript:>>:

>
> New to the whole concept of WAMP and very intrigued by the
> Autobahn project. I have the following questions:
>
> 1. Do I need a WAMP router or can I do direct communication
> between peers/nodes?
> 2. Is there a c++ WAMP router anyone would recommend?
> 3. Difficulty level of implementing a simple WAMP router?
>
> --
> 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 <javascript:>.

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

> <javascript:>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/autobahnws/6c3d6b38-bdbb-41f6-b6da-8465b8c9c381%40googlegroups.com

> <https://groups.google.com/d/msgid/autobahnws/6c3d6b38-bdbb-41f6-b6da-8465b8c9c381%40googlegroups.com?utm_medium=email&utm_source=footer>.

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

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

> <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/d8d679ab-cab1-46d1-b429-a95822b0155b%40googlegroups.com
> <https://groups.google.com/d/msgid/autobahnws/d8d679ab-cab1-46d1-b429-a95822b0155b%40googlegroups.com?utm_medium=email&utm_source=footer>.

[David Chappelle]

Unfortunately I cannot utilize python in my target environment so I cannot utilize crossbar.io.

Where would a good starting point be for implementing a c++ based WAMPv2 router?
I read through the online protocol specification locate here http://wamp.ws/spec/. I have also familiarized myself with the code for Autobahn|C++. One thing that isn't clear to me is how the router knows what type of serialization protocol is being used. For example:

template<typename IStream, typename OStream>

boost::future<uint64_t> session<IStream, OStream>::join(const std::string& realm)

{

      // [HELLO, Realm|uri, Details|dict]

      m_packer.pack_array(3);

      m_packer.pack(static_cast<int> (msg_code::HELLO));

      m_packer.pack(realm);

      m_packer.pack_map(1);

      m_packer.pack(std::string("roles"));

      m_packer.pack_map(4);

      m_packer.pack(std::string("caller"));

      m_packer.pack_map(0);

      m_packer.pack(std::string("callee"));

      m_packer.pack_map(0);

      m_packer.pack(std::string("publisher"));

      m_packer.pack_map(0);

      m_packer.pack(std::string("subscriber"));

      m_packer.pack_map(0);

      send();

      return m_session_join.get_future();

}

template<typename IStream, typename OStream>

void session<IStream, OStream>::send()

{

      if (!m_stopped) {

         if (m_debug) {

            std::cerr << "TX message (" << m_buffer.size() << " octets) ..." << std::endl;

         }

         std::size_t written = 0;

         // write message length prefix

         uint32_t len = htonl(m_buffer.size());

         written += boost::asio::write(m_out, boost::asio::buffer((char*) &len, sizeof(len)));

         // write actual serialized message

         written += boost::asio::write(m_out, boost::asio::buffer(m_buffer.data(), m_buffer.size()));

         if (m_debug) {

            std::cerr << "TX message sent (" << written << " / " << (sizeof(len) + m_buffer.size()) << " octets)" << std::endl;

         }

      } else {

         if (m_debug) {

            std::cerr << "TX message skipped since session stopped (" << m_buffer.size() << " octets)." << std::endl;

         }

      }

      // clear serialization buffer

      m_buffer.clear();

}

I don't see anything that is sent to the router that indicates that msgpack is being used as opposed to json. Or am I missing something fundamental about the message format?

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

[David Chappelle]

I guess for a straight up tcp connection there would be no sub-protocol negotiation like there would be for websockets. So for raw tcp connections the default serialization is msgpack?

[Tobias Oberstein]

Am 19.12.2014 16:59, schrieb David Chappelle:
> I guess for a straight up tcp connection there would be no sub-protocol
> negotiation like there would be for websockets. So for raw tcp
> connections the default serialization is msgpack?

AutobahnCpp currently implements the old revision of RawSocket - which
didn't had negotiation of serialization.

The new RawSocket revision (as well as WebSocket) does have
serialization negotiation: https://github.com/tavendo/AutobahnCpp/issues/15

>
> On Friday, 19 December 2014 10:06:09 UTC-5, David Chappelle wrote:
>
> Unfortunately I cannot utilize python in my target environment so I

> cannot utilize crossbar.io <http://crossbar.io>.

Curious: why can't you use Python?

Does a router need to run on the device at all?

>
> Where would a good starting point be for implementing a c++ based
> WAMPv2 router?

In short: don't;)

> <https://groups.google.com/d/msgid/autobahnws/6c3d6b38-bdbb-41f6-b6da-8465b8c9c381%40googlegroups.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/autobahnws/6c3d6b38-bdbb-41f6-b6da-8465b8c9c381%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> > For more options, visit
> https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>
> > <https://groups.google.com/d/optout
> <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

> > <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/d8d679ab-cab1-46d1-b429-a95822b0155b%40googlegroups.com
> <https://groups.google.com/d/msgid/autobahnws/d8d679ab-cab1-46d1-b429-a95822b0155b%40googlegroups.com>
>
> >

> <https://groups.google.com/d/msgid/autobahnws/d8d679ab-cab1-46d1-b429-a95822b0155b%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/autobahnws/d8d679ab-cab1-46d1-b429-a95822b0155b%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>

> > For more options, visit https://groups.google.com/d/optout
> <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

> <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/a0fcb01d-affa-41b5-a79a-51868772e1c3%40googlegroups.com
> <https://groups.google.com/d/msgid/autobahnws/a0fcb01d-affa-41b5-a79a-51868772e1c3%40googlegroups.com?utm_medium=email&utm_source=footer>.

[David Chappelle]

    I can't run python on the target system(s) because it isn't supported. Trust me if I could use crossbar.io I would. The architecture is service oriented with each service running as a component. The router needs to live alongside the components as the application is a single deployable entity.  Perhaps one day python will be supported and then I can just switch to crossbar.io.

    Seems that there are a number of router implementations for WAMPv1 in a number of different languages. Have these all been abandoned in favor of crossbar.io? It makes sense to just have 1 core implementation and python is in my opinion the best choice. However, I am not in a position to capitalize on it.

>          > <mailto:autobahnws+unsub...@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/d8d679ab-cab1-46d1-b429-a95822b0155b%40googlegroups.com
>         <https://groups.google.com/d/msgid/autobahnws/d8d679ab-cab1-46d1-b429-a95822b0155b%40googlegroups.com>
>
>          >
>         <https://groups.google.com/d/msgid/autobahnws/d8d679ab-cab1-46d1-b429-a95822b0155b%40googlegroups.com?utm_medium=email&utm_source=footer
>         <https://groups.google.com/d/msgid/autobahnws/d8d679ab-cab1-46d1-b429-a95822b0155b%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
>          > For more options, visit https://groups.google.com/d/optout
>         <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

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

[Alexander Gödde]

Hi David!

We're focusing our efforts on Crossbar.io - that's why we've removed the WAMP router functionality from Autobahn|Python. 

Other implementations are by third parties, and there are quite a few to choose from for WAMP v2 as well. 

Regards,

Alex

[Tobias Oberstein]

Am 19.12.2014 17:33, schrieb David Chappelle:
> I can't run python on the target system(s) because it isn't
> supported. Trust me if I could use crossbar.io I would. The architecture

CPython is not supported, but a modern C++11/Boost environment is?
That's at least unusual, but ok.

To the best of my knowledge, there is no C++ WAMP router .. neither
WAMP1 nor WAMP2.

FWIW, we have no plans of making AutobahnCpp into a router. It's a C++
WAMP client library.

Cheers,
/Tobias

[emile.co...@gmail.com]

On Friday, December 19, 2014 1:29:24 PM UTC-4, Tobias Oberstein wrote:

Am 19.12.2014 17:33, schrieb David Chappelle:
CPython is not supported, but a modern C++11/Boost environment is?
That's at least unusual, but ok.

If you cross-compile C++11/Boost, then the target environment can just be plain old POSIX. In fact, we're using an embedded platform that only has partial C++11 support in its GCC compiler, but it doesn't matter because I'm cross-compiling from a Linux platform that has a pretty modern GCC compiler. I deploy the C++ runtime libraries along with the executable.

This approach can make for compact firmware update images. You'd only need to ship a new executable and perhaps a few shared library files. Not relying on external software packages on the target environment can greatly simplify maintenance!