I have seen your post on Raspberry Pi http://community.rti.com/content/forum-topic/howto-run-rti-connext-dds-raspberry-pi
and I was wondering if it is possible to run RTI Routing Service on the Pi?
I would like to build a small sensor network running on Raspberry Pi's(local subnet), and have these communicating with other subnets(containing linux server) over the internet - a system of systems running RTI DDS. And from what I have read so far, this requires RTI Routing Service.
Would this be possible? I am new to RTI, DDS and Raspberry Pi's, so excuse me if this is a silly question.
Hi,
When you say "communicate with other subnets over the internet" do you mean that you will have Firewalls and NATs between the two subnets so that regular UDP traffic directed to the the LAN IP addresses and ports will not be routed over the "internet"?
If the answer to the above is yes, then you will indeed need RoutingService to go through the Firewall and NAT. It is not strictly required but it does make your life a lot easier. That said you only need one routing service on each of the LANs so if you have other computers other than the Raspberry Pi's you could run Routing Service on those.
To answer your original question, there is nothing that would prevent building for the Raspberry Pi. It a pretty standard Linux architecture so it shouldn't be difficult. But it is not something we currenly have... But of course it could be built based on having a commercial opportunity for it.
Gerardo
Hi Gerado
Tried to illustrate the setup below:
|local subnet with Rapsberry Pi with DDS with local IP(192.168.x.xxx)|<----->NAT/Firewall/Router<----->WWW<------>Router/Firewall/NAT<------->|Local subnet with Linux machine with DDS with local IP(192.168.x.xxx)|
I would like to have a R-Pi which is fitted in London to communicate with a Linux machine in Paris via WWW
"It is not strictly required but it does make your life a lot easier." is there an alternative to routing services so that a raspberry pi, which is behind a firewall and NAT, can communicate over WWW? or would I need a standard linux machine in the local subnet as a kind of gateway to the WWW?
Thanks in advance
Hello,
Thank you for the description. Do you plan to have a single Raspberry Pi in London? Or do you expect to evolve that into having a network of those? This will impact the ease of configuration and therefore the motivation for the use of one or two routing services.
Also when you say "communicate over WWW" do you mean you must use HTTP or a specific port number? Or do you mean you must go over the public internet using TCP/IP or UDP/IP but you have no constraints on the higher level protocol (i.e. you do not need to tunnel inside HTTP)? My answer assumes that you can use any protocol or TCP, not just HTTP.
I wil try to describe here the different configuration options and point to where you can find more information. The description is a bit long... In fact I was in in the process of writing a HOWTO in this very subject. Unfortunately the HOWTO will take a bit longer because I wanted to include some example configuration files and code. In the meantime I will include the descriptive part here. Hopefully this information will be enough to get you started.
Additional Resources: In addition to the information provided here there is more information on how to configure the RTI Routing Service for WAN in Chapter 7 (Traversing Wide Area Networks) of the RTI Routing Service User's Manual. The use and configuration of the TCP_WAN tarnsports and the related TCP_TLS transport is documented in Chapter 36 (Configuring the RTI TCP Transport) of the RTI Connext DDS User's Manual.
Basically there are three options:
The difference as the name indicates is the number of routing services and their configuration and that of remaining DDS applications. The figures below illustrate the 3 configurations.
The Dual Routing Service deployment is probably the simplest to configure and manage. All the end-user DDS applications remain the same with the regular transport configuration. Only the Routing Services are configured to be aware of the WAN/NATs.
The Single Routing Service makes the DDS applications on one side be aware of the WAN/NAT. This makes it a little harder to manage but it can be a reasonable alternative if deploying the second routing service causes a problem as it would be if the client Raspberry Pi's in London were dispersed on different IP addresses and not connected to the same LAN.
A Zero Routing Service deployment is also possible but it is only practical if you have a single (or very few) well known applications in one side (e.g. the Paris side). Because of the inflexibility and complexity in the configuration I would not recommend it.
Taking into consideration that you want to run things on the Raspberry Pi and given that currently we do not support the TCP_WAN transport on the Raspberry Pi (or the Routing Service) then the only solution you can use without having us build new libraries are the ones under "Dual Routing Service deployment". Specifically I would recommend the ASYMMETRIC TCP configuration because it is simpler to do and maintain and keeps the "service" side independent from the "client" side so that new clients can be added later.
Note that in the descriptions here I will be using the tcpv4_wan transport for communication over the WAN. It is also possible to use the tlsv4_wan transport which is also a TCP transport that also uses Transport Level Security (TLS) for authentication, access control, integrity, and secure communications. See Section 7.1.4 (Secure Communication) of the the RTI Routing Service User's Manual.
1. Dual Routing Service deployment
This deployment places one Routing Service on each LAN. The Routing Services are configured using the RTI TCP WAN transport to be able to communicate through the Firewall/NAT. In addition the Firewalls and NATs are configured to let the Routing Service traffic go though.
There are two ways to configure it:
-Dual Routing Service deployment with Symmetric TCP Transport
-Dual Routing Service deployment with Asymmetric TCP Transport (this is what I would recommend)
1.1 Dual Routing Service deployment with Symmetric TCP Transport
This deployment configures the Routing Service with a TCP WAN transport to communicate with the other Routing Service. Both Firewalls are configured to forward TCP traffic to a specific port on the Routing Service located behind the NAT. This is illustrated in the figure below. More details on this configuration can be found on Section 7.1.2 (Symmetric Communication Across NATs) of the the RTI Routing Service User's Manual.
The orange dots in the figure illustrate the DDS DomainParticipants. As we can see the Routing Services have 2 DDS Domain Participants. There are 3 DDS Domains. One used by all the user applications in the London LAN, another for all the user applications in the Paris LAN and a third (DomainId = 1) used for the 2 routing services to communicate with each other.
In this figure we make assumptions about IP addresses for networks and hosts. This is only for clarity. There is no restriction on the IP addresses on these LANs/hosts/Firewalls/NATs. The two LANs can even be the using the same network address (e.g. 192.168.1.xx) because they are isolated from each other.
In the figure we see we are assuming the following IP addresses:
The end-user DDS applications running on either LAN domain (id 0) are configured with the standard Transports (UDP, Shared Memory) and standard Peer Hosts (Multicast).
The RTI Routing Services are configured to forward all traffic between the two domains (0 and 1). This means each Routing Service will have 2 DDS DomainParticipants one in DDS domain 1 (WAN side) and the other in DDS domain 0 (LAN side).
The
public_addressneeds to be configured to be the public IP address of its Firewall/NAT (the one visible from the WAN) and the port number that is being forwarded by that Firewall to the RoutingService. So the London Routing Service uses 173.194.34.100:8500 and the Paris Routing Service uses 74.125.200.230:8600.The
server_bind_portcould be any available port. I have used 8000 for the London Routing Service and 8001 for the Paris Routing Service.The
initial_peersmust be set to the Public IP address of the Firewall in the other side and the port that is being forwarded by that Firewall to the RoutingService. These addresses must have the prefix "tcpv4_wan://" indicating they are for the TCP WAN transport. Therefore the London Routing Servicetcpv4_wan://74.125.200.230:8600and the Paris Routing Service usestcpv4_wan://173.194.34.100:8500.The Firewalls/NATs are configured to open a port (8500 on the London FW and 8600 on the Paris FW) and forward it to
server_bind_portat the IP address of Routing Service in their respective LANs that is:- The London NAT forwards port 8500 to the IP address of the London Routing Service (192.168.2.20) and port 8000.
- The Paris NAT forwards port 8600 to the IP address of the Paris Routing Service (192.168.1.10) and port 8001.
Note that the port opened by the firewall must match the one used in the
server_bind_portof the RoutingService protected by that firewall (inside the NAT) and the "initial_peers" of the other RoutingService outside the NAT.Once all this is setup things will work as follows.
initial_peersthat have been configured for the TCP_WAN transport. This is a public IP address/port on the Firewall/NAT which is forwarded to an IP address/port in the Routing Service WAN participant. This way the WAN Participants in the Routing Services discover each other and communicate.1.2 Dual Routing Service deployment with Asymmetric TCP Transport
This deployment configures the two Routing Services to use the TCP WAN transport to communicate with the other Routing Service. However the TCP transports are configured on the Asymmetric manner. With this configuration only one Routing Service needs to know about the remote WAN and only the corresponding Firewall needs to open and forward a port. More details on this configuration can be found on Section 7.1.3 (Asymmetric Communication Across NATs) of the the RTI Routing Service User's Manual.
This configuration is simplest when one side represents well know "services" and the other represents clients with can appear at previously unknown location.
For this example we assume the Paris Side is configured as the "service" side an the London as the "client" side. Consequently only the Paris Firewall is configured to forward TCP traffic to a specific port to the DDS discovery port in the Routing Service located behind the NAT. This is illustrated in the figure below.
The end-user DDS applications running on either LAN domain (id 0) are configured with the standard Transports (UDP, Shared Memory) and standard Peer Hosts (Multicast)
The RTI Routing Services are configured to forward all traffic between the two domains (0 and 1). This means each Routing Service will have 2 DDS DomainParticipants one in DDS domain 1 (WAN side) and the other in DDS domain 0 (LAN side).
The configuration of the TCP WAN transport on the two routing services is different.
On the Paris side:
server_bind_portcould be any available port. I have used 8001.public_addressneeds to be configured to be the public IP address of the Paris Firewall/NAT (the one visible from the WAN) and the port number that is being forwarded by that Firewall to the RoutingService. So it is set to 74.125.200.230:8600initial_peersis set to the empty list. The Paris Routing Service does not need to know where the "clients" will appear.On the London side:
server_bind_portmust be configured to 0. This will tell the TCP_WAN transport that is operating in asymmetric mode and should operate as a client meaning it will not listen for incoming connections.public_addressneeds to be configured to an invalid address (e.g. 0.0.0.0). It will not be used.initial_peersmust be set to the Public IP address of the Paris Firewall and the port that is being forwarded by the Paris Routing Service. These address must have the prefix "tcpv4_wan://" indicating it is for the TCP WAN transport. So in this case it is set to tcpv4_wan://74.125.200.230:8600The configuration of the two Firewalls/NATs is also different.
On the Paris side:
server_bind_portat the IP address of Routing Service in the Paris LANs that is: forward port 8600 to 192.168.1.10:8001On the London side:
Once all this is setup things will work as follows.
The WAN participant on the London RTI Routing Service announces to the
initial_peersthat have been configured for the TCP_WAN transport. This is a public IP address/port on the Paris Firewall/NAT which is forwarded to an IP address/port in the Paris Routing Service WAN participant. Once the TCP connection is established it is used as a bi-directional connection so the Paris Routing Service communicates with the London Routing Service back over that same TCP connection.Data is automatically routed by the DDS Routing Services. This is the same as with the Symmetric deployment.
2 Single Routing Service deployment with Asymmetric TCP Transport
This deployment places a single Routing Service in one of the LANs. In this example we will place it in the Paris LAN. The Routing Service is configured using the RTI TCP WAN transport to be able to communicate through the Firewall/NAT. The corresponding Paris Firewall/NATs is configured to let the traffic destined to the Routing Service traffic go though. In addition all user DomainParticipants on the London side are configured to use the TCP_WAN transport (note that we currently do not have support for it on the Raspberry Pi). This is illustrated in the figure below.
On the Paris side:
public_address,server_bind_portand theinitial_peers:server_bind_portcould be any available port. I have used 8001.public_addressneeds to be configured to be the public IP address of the Paris Firewall/NAT (the one visible from the WAN) and the port that is being forwarded from the Firewall to the RoutingService. So it is set to 74.125.200.230:8600initial_peersis set to the empty list. The Paris Routing Service does not need to know where the "clients" will appear.server_bind_portat the IP address of Routing Service in the Paris LANs that is: forward port 8600 to IP 192.168.1.10:8001On the London side:
server_bind_port= 0 . Indicates it operates in client mode. It will not accept connections.public_address= 0.0.0.0 this is unused.initial_peersmust be set to the Public IP address of the Paris Firewall and the port that is being forwarded by the Paris RoutingService. This address must have the prefix "tcpv4_wan://" indicating it is for the TCP WAN transport. So in this case it is set totcpv4_wan://74.125.200.230:8600The effective NDDS_DISCOVERY_PEERS will be udpv4://239.255.0.1:7400;tcpv4_wan://74.125.200.230:8600
Once all this is setup things will work as follows.
initial_peersthat have been configured. This resolves to the local LAN multicast as well as the public IP address/port on the Paris Firewall/NAT which the Firewall forwards to the an IP address/port in the Paris RoutingService WAN participant. This causes the London applications to communicate directly with each other on the LAN and also connect to the Routing Service on the Paris LAN. Once the TCP connection to the Paris RoutingService is established it will be used as a bi-directional connection so the Paris RoutingService communicates with the London DDS applications over that same TCP connection.The disadvantage of the Single Routing Service deployment is that it is more complex to configure all the London applications with the TCP_WAN transport and the correct parameters. Moreover there will be many TCP connections that the Paris RoutingService will have to keep open.
3 Zero Routing Service deployment
This deployment configures applications to talk directly to each other over the WAN using the (UDP) WAN transport. This approach requires the depolyment of a STUN server on a public address reachable from both LANs. The STUN server is used to automatically determnine the public NAT addresses. Furthermore and uses "UDP hole punching" to automatically open forwarding paths in the NATs so that the packets can flow between participants located in the LAN accross the NAT. This technique does not work for all NATs. It only works for so called CONE (or Assymetric NATs).
Note that the (UDP) WAN transport is currently not included in the Raspberry Pi build.
Further details on how to configure and use the (UDP) WAN transport can be found in Part 5 (RTI Secure WAN Transport) of the RTI Connext DDS User's Guide.
Wow! empressive answer - just what I looking for, Thanks!
After reading your reply a second time and more carefully I must admit I still have a few questions - or issues in need of clarification
You wrote:
"Taking into consideration that you want to run things on the Raspberry Pi and given that currently we do not support the TCP_WAN transport on the Raspberry Pi (or the Routing Service) then the only solution you can use without having us build new libraries are the ones under "Dual Routing Service deployment". "
But I read it as if TCP_WAN and RTI Routing Service is not supported on the Raspberry Pi, and then you suggest that I use "Dual Routing Service Deployment" which from my understanding and the diagram does use the Routing Service - which is not supported on the R-Pi, and thereby is actually not possible.
Currently my understanding is that the Dual Routing Service is not possible in my desired scenario(due to lack of the necessary ARM libraries for the R-Pi) where I wish to connect a R-Pi directly to a Router/NAT and then access another machine over the internet using TCP/UDP - correct?
My understanding is that it is not possible unless I add a standard linux or windows machine to my local subnet of R-Pi's, and have this machine (x86 architecture) act as a gateway for my R-Pi's. Where the Routing on the x86 machine acts as a gateway - correct?
A few more questions about DDS and Routing Service - nothing related to the R-Pi scenario:
What if I have multiple subnets worldwide - like london, paris, madrid, and berlin - am I then able to configure the network to be a "mesh" - f.x. in Paris I configure each the public addresses of the all other networks(London, Madrid, and berlin) into the routing service, and the same in all other "remote locations" - London has the public IP address of Paris, Madrid and Berlin?
Or is it possible to "daisy-chain" subnets? If London is connected on to Madrid and Madrid is connected to London and Paris and etc... see diagram.
Is it possible for London to publish topic T and then have Madrid and Paris subscribe to topic T, and Paris receives it through Madrid?
Let me know if I have to clarify my questions :o)
Thank you in advance - your help is greatly appriciated!
Hello,
Yes. Given our current lack of support for the routing service and the TCP_WAN on the R-pi, the "Dual Routing Service Deployment" would require you to run the routing service in a separate (non R-Pi) computer on each of your subnets. Would that be that a problem for you?
Regarding your other questions:
Yes, exactly, in this situation you have to use the "Dual routing service symmetric TCP" approach and each RoutingService would be configures in its
initial_peersthe list of public addresses of all the other RoutingServices.You asked:
Yes, this is possible but it requires the intermediate locations (Madrid, Paris) to configure the RoutingServices with additional participants and routes so that the daisy-chain works. To make the picture easier I will illustrate what I mean using 2 RoutingService in Madrid (M1 and M2) and 2 also in Paris (P1 and P2). But you do not need two separate RoutingServices in each location ( Madrid or Paris). A single RoutingService in a location (e.g. Madrid) can have multiple routes and each route can use separate DomainParticipants, so you can run the two Madrid routes in a single RoutingService and the same applies to the Paris routes.
With this setup the Firwalls in Madrid and Paris would need to forward two ports. Each port goes to one of the two "external" participants. For example the Firewall in Madrid would have to forward port 8600 to the port for the "external" M1 partcipant and port 8650 to the "external" M2 participant. Similarly the Firewall Paris would forward forward port 8700 to the port for the "external" P1 partcipant and port 8750 to the "external" P2 participant.
Of course in this scenario the traffic from London to Berlin is relayed by 4 additional routes versus the first approach you suggested.
London-Madrid-WAN -> Madrid-LAN,
Madrid-LAN -> Madrid-Paris WAN
Madrid-Paris WAN -> Paris-LAN
Paris-LAN -> Paris-Berlin-WAN
Hi Gerado
We would have liked to able to connect a R-Pi directly to a Router/WAN and have it communicate with other R-Pi's over WAN in remote locations. But currently we are only doing research / prototyping with your product and evaluating it in relation to our requirements. We will continue our work with a ordinary computer.
Section 5.2 of Routing_Service_Manual.pdf describes "Remote Commands" - Could this functionality be used for dynamically adding remote subnets in WAN setup. For example would I be able to remotely add another subnet, lets call it Rio, to a set of exsisting subnet,London, Paris,Marid and Berlin, by using these remote commands to configure the routing.
Basically how easy is it to add/remove these subnets dynamically in WAN setup?
I assume that a big problem will be to open the correct ports at each subnet location as the participants of the WAN subnet changes?
Hi Gerardo,
I'm new with RTI Connext and reading Routing Service Manual and your clear explaination.
So What i would like to know if in the scenario in while Pub and Sub trasmitting data accross a wan if it is possible achieve that scenario with rti connex android library.
I have implement a Java Subscriver on Android Mobile smartphone in lan1 and i would like receive data sent from an Publisher from other lan2 where in the middle there are a wan. It is possible using Routing Service on Android Mobile?? How i can do it?
thanx in advance,
Manuel
Hi. I have created a thread asking about an issue with the deployment of a configuration having single routing service asymmetric TCP, as explained in your reply here.
However, I was not able yet to get to a solution to the issue I am facing.
In my application, I need to establish communication between a group of Raspberry Pis, each on a different network, on one side, and a DDS application on a LAN on the other side.
The link to that thread is the following:
https://community.rti.com/forum-topic/single-routing-service-asymmetric-tcp
Any advice regarding that is appreciated. Thanks!