eCAL to work with multiple NIC on same host?

[chengguizi]

Hi eCAL team,

I recently find out that it is not trivial to setup a machine that has two NIC, say eth0 and eth1 and configure to cloud mode and receive data from both interfaces.

The reason being that, the standard instruction of setting 239.0.0.0/24 route will make the routing table only route to 1 NIC. There seems no good way in linux to make a route to send multicast to multiple NIC at the same multicast address.

For now, a workaround we found is that, to start ecal node on host using 239.0.0.0 cloud mode. Then modify the ecal.ini, change the route to 239.0.1.0. Then start the second ecal node.

On the other ends of the NICs, the ecal nodes are configured with 239.0.0.0 and 239.0.1.0 respectively.

Is there a better way to do this?

It would be great if eCAL ini can configure multicast address per NIC. So to receive from either NIC.

[chengguizi]

A related question. Is it possible to let ecal node to use a custom eacl.ini, instead of the system path one?

[FlorianReimold]

eCAL is socket-based, not NIC-based

eCAL is socket-based, i.e. it uses the socket API provided by the operating system. eCAL has no idea about what the operating system does with the data after it was passed to the socket. So you will have to achieve your goal by means of the operating system.

different ecal.ini files

Yes, you can use individual ecal.ini files for individual applications by putting them in separate directories and starting your eCAL applications with differen $ECAL_DATA variables. You can read more about that in the documentation:
https://eclipse-ecal.github.io/ecal/configuration/options.html

But to summarize it: eCAL will load the $ECAL_DATA/ecal.ini file, if the $ECAL_DATA variable ist set.

Using a network bridge

To me it sounds like you actually want to have a proper network with a central switch.

• If you can incorporate a physical switch in your network, this should be easy. You can then set your multicast route to only one NIC and let the switch relay the data to all connected machines.
• If you cannot connect everything to a physical switch, Linux has utilities to create a virtual switch (-> a network bridge). With this technique you can create a new virtual adapter (often named br0) and set the multicast route to that bridge. You can then assign the bridge to bridge between eth0 and eth1. With this technique, both of your connected devices can also see each other and communicate via eCAL, as the br0 bridges between both physical NICs. If that is not desired, you can apply package filters and e.g. drop all traffic that would be routed from eth0->eth1 and eth1->eth0.
  If this is your desired strategy, you should check out the brctl manpage: https://linux.die.net/man/8/brctl

[chengguizi]

Very insightful. Yes, the two way comm is broken on a simple ip route append attempt. We will try to solve it better next time, probably using bridge is the easiest and cleanest. Thanks!

[Tarisper]

Hello. I'm just starting to get acquainted with ecal, so there are questions from a beginner.
As far as I understand, one instance of an application using ecal can accept only one cal.ini configuration file. That is, calling the ecal::Initialize function will change the configuration of all publishers and subscribers inside one application, although I need one publisher to send data to the first network interface and the other to the second. Thus, using multiple configs is not suitable for me. Is that so, or am I wrong? It's just that using a network bridge seems to me a less suitable solution for my task (I need to physically divide traffic between two network interfaces so that they do not affect each other, without giving delays and without reducing the final speed).

[KerstinKeller]

Hi @Tarisper, no what you're trying to achieve is currently not possible, unfortunately.
Basically, when communicating over UDP, we're just opening sockets and sending multicast traffic.
Maybe, it can be achieved with our tpc_pubsub library, but even there I am not sure if you can chose network interfaces. With that library you can do pubsub based on hostname / ip adresses and fixed ports, and eCAL uses it for its TCP mode.

However, maybe @FlorianReimold can also comment here.

[FlorianReimold]

When using UDP multicast traffic (which is what eCAL does), sending different payloads to different network interfaces is not possible. The Operating system is responsible for choosing the network interface for transferring the data and it does that based on a route. You can only have 1 active route at a time, so either you can make the OS use that one route to send the data to one interface, or you can make it duplicate the traffic via a bridge.

As Kerstin wrote, UDP multicast is not the proper way of transferring data, if you want to address individual machines and apps, so you may want to take a look at TCP. eCAL offers a TCP option for payloads, but the registration traffic will still have to be multiplexed via a bridge, as that remains on UDP Mulitcast.

[Tarisper]

@KerstinKeller @FlorianReimold Thanks for the reply. Unfortunately, the bridge option is not suitable due to the unwillingness to spam the interface with messages that are not suitable for it, and tcp is simply not suitable due to the implementation features. So you will have to look for a workaround or another solution. Perhaps one of the options would be to transfer work with different interfaces to different services.