Autobahn|CPP WAMP Routers

#1

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?

0 Likes

#2

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:

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?
  1. Is there a c++ WAMP router anyone would recommend?
  1. 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.

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.

0 Likes

#3

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?

···

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” cha...@gmail.com:

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?
  1. Is there a c++ WAMP router anyone would recommend?
  1. 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.

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

0 Likes

#4

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.

···

Am 21.11.2014 20:43, schrieb David Chappelle:

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" <cha...@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 autobah...@googlegroups.com <javascript:>.
        To post to this group, send email to auto...@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>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#5

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?

···

On Friday, 21 November 2014 15:46:11 UTC-5, Tobias Oberstein wrote:

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" <cha...@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 auto...@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)
    <[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+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/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>.

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

0 Likes

#6

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?

···

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.

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?

On Friday, 21 November 2014 15:46:11 UTC-5, Tobias Oberstein wrote:

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" <cha...@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 auto...@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)
    <[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+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/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>.

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

0 Likes

#7

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

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

···

Am 19.12.2014 16:59, schrieb David Chappelle:

On Friday, 19 December 2014 10:06:09 UTC-5, David Chappelle wrote:

    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?

    On Friday, 21 November 2014 15:46:11 UTC-5, Tobias Oberstein wrote:

        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" > <cha...@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 autobah...@googlegroups.com
        <javascript:>.
         > To post to this group, send email to
        auto...@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>

         >
        <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 autobah...@googlegroups.com
         > <mailto:autobahnws+...@googlegroups.com>.
         > To post to this group, send email to auto...@googlegroups.com
         > <mailto:auto...@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>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#8

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.

···

On Friday, 19 December 2014 11:06:10 UTC-5, Tobias Oberstein wrote:

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) <[http://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;)

I read through the online protocol specification locate here
[http://wamp.ws/spec/](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?
On Friday, 21 November 2014 15:46:11 UTC-5, Tobias Oberstein wrote:
    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/](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" >  > >         <cha...@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
    auto...@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)
    <[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)>
     >
    <[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)
    <[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)>
     >         <[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+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/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](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)
    <[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)
    <[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.

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

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

0 Likes

#9

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

0 Likes

#10

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

···

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

0 Likes

#11

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!

···

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.

0 Likes