Expected behavior when where are only localhost subscribers

[chengguizi]

Hi,

I am pretty much excited about the upcoming 5.12 release regarding the amazing zero-copy implementation among other efficiency / low-latency improvemtn things.

In the similar vein, we have a use case that some heavy data (e.g. raw images) are being passed on a local host, and only processed data (detections, trajectories) are to be transmitted over UDP to another host (through eCAL network mode)

However I have a question. What is the current behaviour of eCAL when there is local subscribers but no cross-host subscribers? Would eCAL still send / spam the router over multicast?

The expected behaviour would be that if there is no subscriber over the network, UDP and TCP are not being sent, only memfile / inproc memories are being used. This is to save the precious bandwidth in wireless comms.

Currently the logic i can see is here

ecal/ecal/core/src/pubsub/ecal_publisher.cpp

Line 342 in fcf750b

if (!IsSubscribed())

. It seems to be a simple global switch.

[chengguizi]

I do come accross the m_ext_subscribed variable, perhaps that already giving the expected behavior -> no network subscriber, no mc_udp

[rex-schilasky]

Hi @chengguizi,
thank you for asking. So there is a simple logic for using the eCAL transport layers. In the global eCAL configuration file ecal.ini there is a publisher settings section like this

; --------------------------------------------------
; PUBLISHER SETTINGS
; --------------------------------------------------
; use_inproc              = 0, 1, 2                 Use inner process transport layer (0 = off, 1 = on, 2 = auto, default = 0)
; use_shm                 = 0, 1, 2                 Use shared memory transport layer (0 = off, 1 = on, 2 = auto, default = 2)
; use_tcp                 = 0, 1, 2                 Use tcp transport layer           (0 = off, 1 = on, 2 = auto, default = 0)
; use_udp_mc              = 0, 1, 2                 Use udp multicast transport layer (0 = off, 1 = on, 2 = auto, default = 2)
;
; memfile_minsize         = x * 4096 kB             Default memory file size for new publisher
;
; memfile_reserve         = 50 .. x %               Dynamic file size reserve before recreating memory file if topic size changes
;
; memfile_ack_timeout     = 0 .. x ms               Publisher timeout for ack event from subscriber that memory file content is processed
;
; memfile_buffer_count    = 1 .. x                  Number of parallel used memory file buffers for 1:n publish/subscribe ipc connections (default = 1)
; memfile_zero_copy       = 0, 1                    Allow matching subscriber to access memory file without copying its content in advance (blocking mode)
;
; share_ttype             = 0, 1                    Share topic type via registration layer
; share_tdesc             = 0, 1                    Share topic description via registration layer (switch off to disable reflection)
; --------------------------------------------------
[publisher]
use_inproc                = 0
use_shm                   = 2
use_tcp                   = 0
use_udp_mc                = 2

Here you can configure the publication behavior. There are 3 modes off [0] , on [1], auto [2], described here. Setting a layer off [0] is easy to understand - no more communication over that layer. Setting a layer on [1] means always publish data using this layer no matter if there is a subscription detected using this transport mechanism or not, i.e. a local subscriber for the shared memory layer or an external subscriber for the udp or tcp one.

Setting a layer to auto [2] is realizing exactly the behavior you expect, it means using shm only if there is a local subscription, using tcp or udp only if there is an external subscription. This is the default setting for the shm and udp transport layer.

You can configure this behavior as described globally for a complete host, using the ecal.ini configuration file or you can configure this publisher-wise using the CPublisher C++ API function SetLayerMode.

[chengguizi]

A quick question. By opening an ecal monitor on anther host, viewing the statistics on the topics being published. Would it trigger the udp publishing?

[rex-schilasky]

A quick question. By opening an ecal monitor on anther host, viewing the statistics on the topics being published. Would it trigger the udp publishing?

No, this is just monitoring the registration/discovery layer. This registration layer is using udp by default but not transferring a large amount of data.

In eCAL 5.11.4 there is a new feature called shm monitoring that can be activated in the global configuration. Then eCAL is using shm for registration/discovery too and so finally the whole ipc middleware is running without any socket communication. For sure this is working on a single host only.

But last but not least if you open a monitor topic view (by double clicking on a publisher for example) you force the monitor to subscribe on that topic and eCAL will transmit the payload using udp.

[edwardstevenw]

Hi the eCAL config I have is already set to 2 for shm, and udp. So I expected when running a publisher on a host with no external subscriber and view the network bandwidth using iftop, there will be not much data transmitted. However I see that the bandwidth used is quite big for something I believe to be registration layer (as seen on the first picture).

Then I tried to run a subscriber in a different host to compare the amount of bandwidth.

It seems to have the same amount of bandwidth used when there is subscriber and when there is not subscriber.

[FlorianReimold]

You should open a new question and not ask your questions as a comment to somebody else's question. But shortly speaking: Yes, eCAL Nodes will send out registration data, even when no subscriber is connected, because that ensures that a subscriber is able to connect at all. You can set your eCAL to local mode, so the traffic will stay on localhost. But it is still UDP traffic.