[core] new-pub-sub-matching

[rex-schilasky]

Description

• layer states (enabling) exchanged between pub/sub
• layer activation based on layer priority lists for local and remote connections

[KerstinKeller]

😨 Tests should be reproducible!
if you are generating numbers for a tests, you should do so with a seed, so they are always generating the same.
And in this case, combinations would maked more sense instead of just random numbers.

[KerstinKeller]

Just a remark: I think we really need to discuss about starting layers even though no subscribers are there. What is the current behavior? If noone is subscribed, nothing happens.
If someone is subscribed on udp, is the publisher also always sending on shm, even though noone is listening on SHM?

What are the latencies, when a Publisher is present, a subscriber wants to subscriber, until the subscriber receives the first message, assuming e.g. the publisher sends at 10 Hz frequency. How is it in eCAL5?

[KerstinKeller]

Can you explain the logic again?

[rex-schilasky]

enabled == enabled by the (user) publisher/subscriber logic
confirmed == data were successful send over the layer finally (used by the monitoring mainly)

[rex-schilasky]

Just a remark: I think we really need to discuss about starting layers even though no subscribers are there. What is the current behavior? If noone is subscribed, nothing happens. If someone is subscribed on udp, is the publisher also always sending on shm, even though noone is listening on SHM?

What are the latencies, when a Publisher is present, a subscriber wants to subscriber, until the subscriber receives the first message, assuming e.g. the publisher sends at 10 Hz frequency. How is it in eCAL5?

The old behavior is that write layers are enabled (instantiated) at the construction phase of the CDataWriter if their mode is configured as off or auto. This leads to the fact that a memory file is created, a socket is opened .. even there is no local/external subscription.

The new behavior is to not instantiate any of theses layers if their is no matching subscription for this kind of transport. The connection timing is still insides 2 registration loops as guaranteed in eCAL5.

[KerstinKeller]

I was thinking about it more. What do you think about the following logic:

The publisher provides which layers it supports. In the config this may be activated.
The subscriber provides a list of priorities, on which layer it would prefer to receive data.
eg [shm, udp, tcp] or [tcp, udp]. The first entry has highest priority.

The publisher will then send on the "first" layer which is activated, which the subscriber wants.

With this combination (and the knowledge, if a layer is supported for the combi / location of publisher & subscriber), for both publisher and subscriber, it's clear on which layer the data will flow.

e.g.

Publisher 1: 
Host: host1
shm: true
udp: true
tcp: true

Subscriber 1:
Host: host1
layers: [shm, udp, tcp]

Publisher 1 and subscriber 1 will communicate on SHM

Subscriber 2:
Host: host1
layers: [tcp, udp]

Publisher 1 and subscriber 1 will communicate on TCP

Subscriber 3:
Host: host2
layers: [shm, udp, tcp]

Publisher 1 and subscriber 3 will communicate on UDP, because they are on different hosts but shm does not support inter_host communication

Publisher 2: 
Host: host1
shm: false
udp: true
tcp: true

Publisher 2 and Subscriber 1 will communicate on udp
Publisher 2 and Subscriber 2 will communicate on tcp
Publisher 2 and Subscriber 3 will communicate on udp

I think it's pretty straighforward, and there is not forward - backward communication necessary.

[github-actions]

clang-tidy made some suggestions

[github-actions]

warning: variable 'layer_priority_vector' of type 'Publisher::Configuration::LayerPriorityVector &' (aka 'vectorTLayer::eTransportLayer &') can be declared 'const' [misc-const-correctness]

Suggested change

	Publisher::Configuration::LayerPriorityVector& layer_priority_vector = same_host_ ? m_config.layer_priority_local : m_config.layer_priority_remote;
	Publisher::Configuration::LayerPriorityVector const& layer_priority_vector = same_host_ ? m_config.layer_priority_local : m_config.layer_priority_remote;

[rex-schilasky]

replaced by new PR new-pub-sub-matching-2