Publishers never forget subscribers in Network Mode

[genevanmeter]

Problem Description

When configured with communication_mode: "network" publishers never forgets remote subscribers after they close. If there is an active local subscription and a remote host that had previously subscribed to a topic it will also get the data even if the remote isn't actively subscribed to the data. The can cause unintended excess network bandwidth.

How to reproduce

Configure two machines for "network" mode

HOST-A
Terminal 1

ecal_sample_performance_snd

Terminal 2

ecal_sample_performance_rec

Leave them running.

---

HOST-B

ecal_sample_performance_rec

Observe the network utilization via System Monitor or wireshark on HOST-B. Should be some significant amount based on network.

Now stop ecal_sample_performance_rec

Observe the network utilization via System Monitor or wireshark on HOST-B. Should be minimal

Now start any ecal application that does NOT actively subscribe to Performance topic ie

ecal_sample_person_send

Observe the network utilization via System Monitor or wireshark on HOST-B. It will show significant traffic again even though the Performance topic wasn't subscribed to.

How did you get eCAL?

Custom Build / Built from source

Environment

eCAL 6.1.1 and master
Ubuntu 24.04

eCAL System Information

[eCAL][Config] Yaml configuration loaded from "/opt/dawg/etc/ecal/ecal.yaml".
------------------------- SYSTEM ---------------------------------
Version                  : v6.1.1-dirty (31.03.2026)
Platform                 : linux

------------------------- CONFIGURATION --------------------------
Default INI              : /opt/dawg/etc/ecal/ecal.yaml

------------------------- NETWORK --------------------------------
Host name                : glaptop
SHM transport domain     : glaptop
Network mode             : cloud
Network ttl              : 10
Network sndbuf           : 5 MByte
Network rcvbuf           : 5 MByte
Multicast cfg version    : v2
Multicast group          : 239.0.0.1
Multicast mask           : 255.255.255.240
Multicast ports          : 14002 - 14012
Multicast join all IFs   : off

------------------------- TIME -----------------------------------
Synchronization realtime : ecaltime-localtime
Synchronization replay   :
State                    :  synchronized
Master / Slave           :  Master
Status (Code)            : "everything is fine." (0)

------------------------- SUBSCRIPTION LAYER DEFAULTS ------------
Layer Mode UDP MC        : on
Drop out-of-order msgs   : on

[KerstinKeller]

Hi @genevanmeter,
thanks for reporting. The data handling layer inside a publisher is not particularly cleanly implemented. However, that data is being sent when there is no active subscription does sound at least like unintentional behavior, or even a bug.
We will take a look at the effort needed to fix this. Depending on the required effort the solution might be released as a patch release for eCAL 6.1 / 6.0, or if significant refactoring is required, it might need to become part of the eCAL 6.2 release for which we don't yet have a release date.

[KerstinKeller]

@genevanmeter would you mind testing the following branch and giving some feedback hotfix/dont-transmit-data-without-subscriber

[genevanmeter]

@KerstinKeller

It does appear to work. In my live environment where multiple hosts have multiple ecal nodes, after unsubscribing I am seeing the network data drop off after the registration_timeout (default: 10000) has elapsed which I would say is expected behavior.

[KerstinKeller]

If you shut down your tasks gracefully, the expected behavior would be that the network traffic stops more or less immediately, as all entities publish their unregistration before shutdown.
If the tasks are killed, you would see the traffic stop after the registration timeout, as you are observing.

[genevanmeter]

Network traffic will stop immediately if and only if there are no other eCAL processes running on the remote host. With the hotfix/dont-transmit-data-without-subscriber branch I observed if HOST-B had ecal_mon_gui running, but not subscribed to anything, once ecal_sample_performance_rec is stopped (HOST-B) the traffic will continue until the registration_timeout has elapsed.

Here is another example where ecal_sample_performance_rec is stopped, traffic drops, and a publisher ecal_sample_person_send is started within the registration_timeout and the network traffic jumps back up and then stops after the registration_timeout has elapsed since the last time the subscription was dropped. Hopefully the picture helps show this: