AutobahnJS using raw TCP transport

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

We are considering using Autobahn/WAMP for our IoT-related commercial project. Our embedded device will be running a Node.js server which communicates with C++ control software (running in a separate process) using RPC.

I'd like to know if it's possible for AutobahnJS to use a raw TCP connection, instead of a websocket connection? It would be even better if AutobahnJS can use unix domain sockets. If either is possible, could someone provide a short snippet that shows how to establish the connection?

Cheers,

Emile

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

Upon further reading, I now understand that the Autobahn libraries do not support direct peer-to-peer RPC, but rather RPC must be done through a WAMP router. I'm looking for direct IPC between our Node.js backend and our C++ control software. I'm also looking to use the same IPC technology for communications between C++ processes. I don't like the prospect of having to go through a "middleman" for every single RPC call.

Autobahn/WAMP seems very promising, but it looks like it won't be a good fit for our product. Nonetheless, if I end up rolling my own JSON-based RPC, I'll definitely consider using the WAMP protocol as my message format! :-)

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

I might have ruled out Autobahn too quickly... :-) Upon even *more* reading (based on your SO answer here, and the Crossbar.io Scenarios page), it seems that Crossbar.io could help me eliminate the Node.js server entirely!

See, I first thought it was supposed work like this:

Frontend (Javascript) --> Node.js --> AutobahnJs --> AutobahnC++ --> C++ Backend

but a WAMP router would allow me to do this:

Frontend (Javascript) --> Crossbar.io --> C++ Backend

Which suits us just fine, because our Web UI developer doesn't need to know anything about C++, and the back-end developer (myself) doesn't need to know anything about Javascript!

Please let me know if I am mistaken in my current understanding of how this all works.

I'll try to read more documentation before asking any more silly questions. :-)

Cheers,

Emile

[Alexander Gödde]

Hi!

First of all - thanks for sticking in there an continuing with your exploration of WAMP/Autobahn!

In principle, the second connection pattern you give,

Frontend (Javascript) --> Crossbar.io --> C++ Backend

is how things are supposed to work.

I know the documentation needs improvement to make things clearer.

Any suggestions from your side, especially regarding things that initially led you astray, or changes that would communicate basic principles better?

Regards

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

I'm not sure I can give good suggestions on improving the documentation. I'm under a little pressure to get things started, and there are quite a few RPC technologies out there competing for my attention, so I end up skimming the docs when evaluating a candidate RPC technology.

Perhaps you could show, on your main page, some of the diagrams from the Crossbar.io scenarios page? It's the polyglot nature of Autobahn that was attractive to me. You could also make it more apparent that Crossbar.io is already a functioning http server.

Hope this helps.

[Tobias Oberstein]

Did you look at zero mq already? Another one: Cap'n'Proto.

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/b9b76685-1636-4127-9140-9c98a65a6cf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tobias Oberstein]

Thanks for the feedback! We'll try to improve on these! Crossbar.io indeed comes with a couple of services integrated. WAMP routing is just a core service. WAMP is also not only RPC, but also PubSub. Which can come in handy if you need a dual nature protocol that also works over the Web natively.

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/ebdbdf59-f34f-4e82-b525-f1e98605854e%40googlegroups.com.

[Alexander Gödde]

Hi!

 

Thanks  - that’s two good suggestions right there!

 

Regards,

 

Alex

--

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

I had evaluated Cap'n Proto quite thoroughly, but had to abandon it because it was crashing GDB (even the latest Github version of GDB). Cap'n Proto uses advanced C+11 features rather extensively, so it's a bit too "bleeding edge" for GDB's symbol parser right now. Also, Cap'n Proto doesn't treat pub/sub as a first class citizen; you basically have to implement your own GoF Observer pattern on top of capabilities.

I've looked at ZeroMQ, but it seems like you need to implement serialization and RPC on top of it yourself.

Most of the RPC "payloads" in our project will be ultimately consumed by a web browser, so I like the fact that WAMP supports both JSON and WebSockets.

[Tobias Oberstein]

Am 13.10.2014 23:00, schrieb emile.co...@gmail.com:
> I had evaluated Cap'n Proto quite thoroughly, but had to abandon it
> because it was crashing GDB (even the latest Github version of GDB).
> Cap'n Proto uses advanced C+11 features rather extensively, so it's a
> bit too "bleeding edge" for GDB's symbol parser right now. Also, Cap'n
> Proto doesn't treat pub/sub as a first class citizen; you basically have
> to implement your own GoF Observer pattern on top of capabilities.

Yes, probably ..

>
> I've looked at ZeroMQ, but it seems like you need to implement
> serialization and RPC on top of it yourself.

Yes.

>
> Most of the RPC "payloads" in our project will be ultimately consumed by
> a web browser, so I like the fact that WAMP supports both JSON and
> WebSockets.

Great! If I remember correctly, you don't like the fact that WAMP not
only routes PubSub events (via a broker), but also routes RPCs (via a
dealer). However, the latter is a core and innovative aspect of WAMP
that brings a lot of flexibility. So let me ask (probably again): what
problem do you see/expect with RPC routing?

>
>
> On Friday, October 10, 2014 5:54:39 PM UTC-3, Tobias Oberstein wrote:
>
> Did you look at zero mq already? Another one: Cap'n'Proto.
>
> 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

> <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/c4cc91d0-a615-4eb2-88e7-72b419bb16fe%40googlegroups.com
> <https://groups.google.com/d/msgid/autobahnws/c4cc91d0-a615-4eb2-88e7-72b419bb16fe%40googlegroups.com?utm_medium=email&utm_source=footer>.

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

On Tuesday, October 14, 2014 5:53:09 PM UTC-3, Tobias Oberstein wrote:

Great! If I remember correctly, you don't like the fact that WAMP not
only routes PubSub events (via a broker), but also routes RPCs (via a
dealer). However, the latter is a core and innovative aspect of WAMP
that brings a lot of flexibility. So let me ask (probably again): what
problem do you see/expect with RPC routing?

I was mistaken in thinking the RPC dealer would be a problem. Let me explain... Before I had even considered Autobahn/WAMP, I was going to use an architecture like this:

Web frontend ->  socket.io -> Node.js -> Protobuf+Asio -> C++ Backend

Then I discovered Autobahn/WAMP, and naively thought I had to use this architecture:

Web frontend -> Autobahn|JS -> Node.js -> Autobahn|JS -> Crossbar.io -> Autobahn|Cpp -> C++ Backend

That long chain above explains why I didn't like the idea of Crossbar.io being the "middleman" between Node.js and C++.

But it turns out I can just do this:

Web frontend -> Autobahn|JS -> Crossbar.io -> Autobahn|Cpp -> C++ Backend

In my original architecture using Node.js and Protobuf+Asio, the Node.js server would have ended up performing a "dealer" role very similar to Crossbar.io, except the dealing would have been more hard-coded and aware of the application details.

In the original architecture, a change in the C++ backend API would likely require changes to the Node.js code. But the dealer role of Crossbar.io eliminates the need to maintain the backend API in two different languages (C++ and Node.js)! I've therefore warmed up to this RPC dealer concept. 

[Tobias Oberstein]

Am 15.10.2014 00:42, schrieb emile.co...@gmail.com:
>
>
> On Tuesday, October 14, 2014 5:53:09 PM UTC-3, Tobias Oberstein wrote:
>
> Great! If I remember correctly, you don't like the fact that WAMP not
> only routes PubSub events (via a broker), but also routes RPCs (via a
> dealer). However, the latter is a core and innovative aspect of WAMP
> that brings a lot of flexibility. So let me ask (probably again): what
> problem do you see/expect with RPC routing?
>
>
> I was mistaken in thinking the RPC dealer would be a problem. Let me
> explain... Before I had even considered Autobahn/WAMP, I was going to
> use an architecture like this:
>

> Web frontend -> socket.io <http://socket.io/> -> Node.js ->

> Protobuf+Asio -> C++ Backend
>
> Then I discovered Autobahn/WAMP, and naively thought I had to use this
> architecture:
>
> Web frontend -> Autobahn|JS -> Node.js -> Autobahn|JS -> Crossbar.io ->
> Autobahn|Cpp -> C++ Backend
>
> That long chain above explains why I didn't like the idea of Crossbar.io
> being the "middleman" between Node.js and C++.

Ah, I see. No, that would indeed be a "problem" ..

>
> But it turns out I can just do this:
>
> Web frontend -> Autobahn|JS -> Crossbar.io -> Autobahn|Cpp -> C++ Backend

Yes, exactly.

>
> In my original architecture using Node.js and Protobuf+Asio, the Node.js
> server would have ended up performing a "dealer" role very similar to
> Crossbar.io, except the dealing would have been more hard-coded and
> aware of the application details.

In fact the strict separation of concerns - routers only do routing, and
no app stuff - is an important paradigm in WAMP (v2). This brings a lot
of advantages: developers can choose/switch their fav. router with no
app code changes (= no lock in), fleixble app deployment with no app
code change, and router federation (multi-hop routing) in the future.

>
> In the original architecture, a change in the C++ backend API would
> likely require changes to the Node.js code. But the dealer role of
> Crossbar.io eliminates the need to maintain the backend API in two
> different languages (C++ and Node.js)! I've therefore warmed up to this
> RPC dealer concept.

I'm happy you see the light;)

>
> --
> 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/1be942d8-6ed2-4a21-8fb2-89beb315c17a%40googlegroups.com
> <https://groups.google.com/d/msgid/autobahnws/1be942d8-6ed2-4a21-8fb2-89beb315c17a%40googlegroups.com?utm_medium=email&utm_source=footer>.

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

On Wednesday, October 15, 2014 3:42:01 AM UTC-3, Tobias Oberstein wrote:

In fact the strict separation of concerns - routers only do routing, and
no app stuff - is an important paradigm in WAMP (v2). This brings a lot
of advantages: developers can choose/switch their fav. router with no
app code changes (= no lock in), fleixble app deployment with no app
code change, and router federation (multi-hop routing) in the future.

I'm eager to see the multi-hop routing feature, as it would be quite useful in IoT applications for bypassing firewalls on residential LAN routers:

Web frontend <--> Crossbar.io "gateway" WAMP router <--> Residential LAN firewall <--> Crossbar.io residential WAMP router <--> C++ IoT backend <-- Sensors

With the above architecture, and because WAMP supports Websockets (in addition to the recent HTTP long polling support), the end-user should be able to access their sensor network from anywhere on the Internet without having to poke holes through their residential LAN router.

Please keep the above scenario in mind as you finalize the WAMP v2 specification. I think it may be a major "selling point" for Autobahn/WAMP in the IoT industry.

[Tobias Oberstein]

Am 15.10.2014 17:29, schrieb emile.co...@gmail.com:
> On Wednesday, October 15, 2014 3:42:01 AM UTC-3, Tobias Oberstein wrote:
>
> In fact the strict separation of concerns - routers only do routing,
> and
> no app stuff - is an important paradigm in WAMP (v2). This brings a lot
> of advantages: developers can choose/switch their fav. router with no
> app code changes (= no lock in), fleixble app deployment with no app
> code change, and router federation (multi-hop routing) in the future.
>
>
> I'm eager to see the multi-hop routing feature, as it would be quite
> useful in IoT applications for bypassing firewalls on residential LAN
> routers:

FWIW, multi-hop is not needed to make above work:

Browser using AutobahnJS ---> FW >-- WAMP --> Crossbar.io
IoT Device using AutobahnCpp ---> FW >-- WAMP --> Crossbar.io

Both browsers and device actively connect to Crossbar.io (an outbound
TCP connection crossing any resdential router / DSL / FW device .. since
it is outbound).

Browsers and devices can talk _symmetrically_ with each other.

On the WAMP level, it does not matter that both browsers and devices
connect to Crossbar.io as TCP clients.

>
> Web frontend <--> Crossbar.io "gateway" WAMP router <--> Residential LAN
> firewall <--> Crossbar.io residential WAMP router <--> C++ IoT backend
> <-- Sensors
>
> With the above architecture, and because WAMP supports Websockets (in
> addition to the recent HTTP long polling support), the end-user should
> be able to access their sensor network from anywhere on the Internet
> without having to poke holes through their residential LAN router.

This already works today: see above.

>
> Please keep the above scenario in mind as you finalize the WAMP v2
> specification. I think it may be a major "selling point" for
> Autobahn/WAMP in the IoT industry.
>

> --
> 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/60e3a7e1-0ad5-4236-9fcf-665c25730ee8%40googlegroups.com
> <https://groups.google.com/d/msgid/autobahnws/60e3a7e1-0ad5-4236-9fcf-665c25730ee8%40googlegroups.com?utm_medium=email&utm_source=footer>.