Replies: 1 comment 2 replies
-
|
I understood that your network contains many hosts and you need network communication within eCAL, however physically dividing your network into smaller sub-networks is not a feasible option. This is indeed a tricky use case and you already brought up the idea to configure multiple domains using different multicast addresses. Even though I totally agree that this feels like a workaround, I cannot think of any better solution. The advantage of this approach is, that not only the eCAL nodes will seize to discover nodes from a different multicast address, but you will actually help the OS and routers to better direct the multicast traffic to only relevant hosts and thus reduce network load and CPU usage. |
Beta Was this translation helpful? Give feedback.
-
|
OK thanks @FlorianReimold. I will give it a go and report what I find. I assume I can assign multicast addresses sequentially as 239.0.0.1, 239.0.0.2 and so on, or is there some internal implementation detail that prohibits me from doing so? |
Beta Was this translation helpful? Give feedback.
-
|
You will get better results by changing more than just the last section of the ip address. Ecal has a topic name to multicast mapping that you can control from the configuration file. By default, ecal will use the ip range from 239.0.0.1 to 239.0.0.15. The reason is to not overload hosts with too much traffic that they are not interested in. I would recommend trying 239.0.1.1, 239.0.2.1 and so on. Make sure to set your multicast routes accordingly. |
Beta Was this translation helpful? Give feedback.
-
Problem:
What are my options?
The obvious solution that comes to mind is to configure each 'system' to its own unique multicast network address. Is that the preferred approach?
Beta Was this translation helpful? Give feedback.
All reactions