AutobahnJS using raw TCP transport

#1

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

0 Likes

#2

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! :slight_smile:

···

On Friday, October 3, 2014 5:31:46 PM UTC-3, emile...@gmail.com wrote:

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

0 Likes

#3

I might have ruled out Autobahn too quickly… :slight_smile: 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. :slight_smile:

Cheers,

Emile

···

On Friday, October 3, 2014 7:51:20 PM UTC-3, emile...@gmail.com wrote:

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! :slight_smile:

0 Likes

#4

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

···

Am Samstag, 4. Oktober 2014 01:55:36 UTC+2 schrieb emile...@gmail.com:

I might have ruled out Autobahn too quickly… :slight_smile: 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. :slight_smile:

Cheers,

Emile

On Friday, October 3, 2014 7:51:20 PM UTC-3, emile...@gmail.com wrote:

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! :slight_smile:

0 Likes

#5

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.

···

On Thursday, October 9, 2014 9:05:02 AM UTC-3, Alexander Gödde wrote:

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

0 Likes

#6

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

···

Sent from Mobile (Google Nexus 5)

Am 04.10.2014 00:51 schrieb 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! :slight_smile:

On Friday, October 3, 2014 5:31:46 PM UTC-3, emile...@gmail.com wrote:

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

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.

0 Likes

#7

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)

Am 10.10.2014 20:21 schrieb 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.

On Thursday, October 9, 2014 9:05:02 AM UTC-3, Alexander Gödde wrote:

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

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.

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

0 Likes

#8

Hi!

Thanks - that’s two good suggestions right there!

Regards,

Alex

Von:
autob...@googlegroups.com [mailto:autob...@googlegroups.com] Im Auftrag
von
emile.co...@gmail.com

···

Gesendet: Freitag, 10. Oktober 2014 20:21
An: autob...@googlegroups.com
Betreff: Re: AutobahnJS using raw TCP transport

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.

On Thursday, October 9, 2014 9:05:02 AM UTC-3, Alexander Gödde wrote:

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

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.

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

0 Likes

#9

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.

···

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)

0 Likes

#10

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?

···

Am 13.10.2014 23:00, schrieb emile.co...@gmail.com:

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

0 Likes

#11

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.

···

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?

0 Likes

#12

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

···

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:

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

0 Likes

#13

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.

···

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.

0 Likes

#14

    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.

···

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:

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

0 Likes