UDP communication doesn't work in different network

[harlenli2022]

Dear eCAL Team,

I’m trying to use eCAL framework in my test validation, the system deployment is test server (in c/c++) running in Host A and test client (in python) running in Host B.

Following the network configuration guide, I had added route 239.0.0.0 already in both Host in same network (IP like 192.168.1.xx), after then the communication between these two Host is working fine. But when one Host change to different network (IP like 192.168.2.xx), then the server/client (same to pub and sub) can't identify each other.

Could you kindly support to confirm if special configuration needed for sub-network case?

Thanks in advance.

Best Regards,
Harlen

[FlorianReimold]

Hi Harlen,

There are 2 different communication protocols used with eCAL:

1. Normal data transfer:

   • UDP Multicast
   • For this you need the 239.0.0.0 route on all machines
   • The documentation page on how to configure this is here: https://continental.github.io/ecal/getting_started/cloud.html

2. Services:

   • TCP Unicast
   • For this your OS must be able to do HOSTNAME -> IPv4 resolution
   • You can check if you can ping all of your machines
     • HOSTNAME.local -> IPv4 is something else and is not sufficient! So when pinging check if your OS maybe added the .local TLD. If it does, eCAL will probably not work!
   • In pure-Windows networks this works out of the box, but for anything else you may have to edit hosts files
   • The documentation page on how to configure this is here: https://continental.github.io/ecal/getting_started/services.html

If you change the static IPv4 addresses, you will most likely also have to change your routes and hosts entries. On linux the multicast route is per-adapter (and not per-IP), so it will continue to function, but on Windows it won't.

[harlenli2022]

Hi Florian,

Thank you for feedback.

For UDP multicast, if two host in different network (one is 192.168.1.xx, the other one is 192.168.2.xx), shall we still set route 239.0.0.0 in both machines? I tried this before, the registration of publisher (or subscriber) can't be applied to subscriber (or publisher) running in other machine.

For TCP unicast, I also add hostname and IP resolution in /etc/hosts, and hostname can ping successfully between machines.
But the sample minimal_server_c and minimal_client_c still can't communicate each other.
Btw, from the snd_sample.cpp， seems server registration was done by UDP msg (CUDPSender), does it mean UDP network is necessary for TCP unicast case?

Do I need additional configuration in ecal.ini? I see there are configurations related to udp and tcp like below items:
[network]
multicast_group = 239.0.0.1
multicast_mask = 0.0.0.15
tcp_rec_enabled = true
[publisher]
use_tcp = 0
use_udp_mc = 2

[harlenli2022]

Network configuration in Host A:


Host A ping Host B's hostname:

Network configuration in Host B:


Host B ping Host A's hostname:

Run sample using UDP multicast, registration can't be received each other:
person_snd in Host A: in reggate ApplySample, only bct_reg_process and bct_reg_publisher received.
person_rec in Host B: in reggate ApplySample, only bct_reg_process and bct_reg_subscriber received.

Run sample using TCP unicast, registration can't be received each other:
minimal_server_c in Host A: in reggate ApplySample, only bct_reg_process and bct_reg_service received.
minimal_client_c in Host B: in reggate ApplySample, only bct_reg_process and bct_reg_client received.

[FlorianReimold]

You shouldn't have to change anything in the ecal.ini, if you are using our default configuration. That your UDP communication is working proves that it is configured properly. Just in case, here is how to configure eCAL in cloud mode.

I guess your issue is that your machines are in different subnets. I am surprised that they can ping each other at all.

• Host A (nvidia) is in Network 172.26.41.* (Because your subnet mask is 255.255.255.0 forming a subnet from the first 24bit / 3 "blocks")
• Host B (harleni-space) is in Network 172.26.42.* (Your subnet mask is 255.255.255.0 as well)

Not sure if that configuration is intended, because you wrote about 192.168.1.xx, and 192.168.2.xx (but both subnets don't appear in your screenshots). Either way, the nature of IPv4 says that you have configured 2 separate subnets that are not meant to exchange data.

What you can do is:

• Move one of the machines to the others subnet (e.g. 172.26.41.24 and 172.26.41.41)

  or

• Shrink your subnet mask to increase the size of your subnet, so both machines are in the same subnet. You can e.g. use 255.255.0.0, which will make both machines share the subnet 172.26.*.*

[harlenli2022]

Hi Florian,

The IP address of 192.168.1.xx, and 192.168.2.xx are just example to describe my use case.
The actual environment is like the screenshot (172.26.41.* and 172.26.42.*), these host are under same switch but different subnets, so they can ping each other.
I understand your suggestion #1 to switch to same subnet which is works fine for communication.
Regarding suggestion #2, do you mean change route's netmask to 255.255.0.0? or change the network adapter's netmask?

[FlorianReimold]

The route is a pure UDP Multicast route and has nothing to do with your Unicast TCP Connections. You have to modify the network-adapter's netmask.