how to aovid the sender does not send messages for a long time, the link becomes invalid。

[BoxCharon]

When ecal is used to implement inter-process communication, during the sender does not send a message for a long time, and then the receiver cannot receive the message after this time which is sent by the sender.

[rex-schilasky]

Can you please provide a few more details. What kind of transport layer is used here, SHM, UDP or TCP? What exactly means 'long time'?

[BoxCharon]

I use tcp for data transfer in different process,'long time' means publisher didn't call it function in about five or six minutes to create message,then call function to send the data but the receiver can't receive the data.

The details about ecal.ini

[network]
network_enabled                    = false
multicast_config_version           = v1
multicast_group                    = 239.0.0.1
multicast_mask                     = 0.0.0.15
multicast_port                     = 14000
multicast_ttl                      = 2
multicast_sndbuf                   = 5242880
multicast_rcvbuf                   = 5242880

multicast_join_all_if              = false

bandwidth_max_udp                  = -1

inproc_rec_enabled                 = true
shm_rec_enabled                    = true
tcp_rec_enabled                    = true
udp_mc_rec_enabled                 = true

npcap_enabled                      = false

tcp_pubsub_num_executor_reader     = 4
tcp_pubsub_num_executor_writer     = 4
tcp_pubsub_max_reconnections       = 5

host_group_name           =

[common]
registration_timeout               = 60000
registration_refresh               = 1000

[process]
terminal_emulator                  = 

[publisher]
use_inproc                         = 2
use_shm                            = 2
use_tcp                            = 2
use_udp_mc                         = 0

memfile_minsize                    = 4096
memfile_reserve                    = 50
memfile_ack_timeout                = 0
memfile_buffer_count               = 1
memfile_zero_copy                  = 0

share_ttype                        = 1
share_tdesc                        = 1

[service]
protocol_v0                        = 1
protocol_v1                        = 1


[monitoring]
timeout                            = 5000
filter_excl                        = __.*
filter_incl                        =
filter_log_con                     = info, warning, error, fatal
filter_log_file                    =
filter_log_udp                     = info, warning, error, fatal

detail about how to transport data

eCAL::protobuf::CPublisher<test::can_bridge::test1>              test1_pub("test1");
test1.Send(test1);

eCAL::protobuf::CSubscriber<test::can_bridge::test1>            sub_test1("test1");
sub_test1.AddReceiveCallback(std::bind(on_receive_test1_data, std::placeholders::_1, std::placeholders::_2, std::placeholders::_3, std::placeholders::_4));

[rex-schilasky]

Hi @BoxCharon, thank you for providing more details. You mentioned you use tcp. How did you configure this? In your ecal.ini configuration you just set use_tcp to auto mode (2) and use_udp as well, this should lead to an error message like this

eCAL config error: to set [publisher/use_tcp] and [publisher/use_udp_mc] both on auto mode (2) is not allowed

and stop execution.

Besides this. In the current eCAL releases you can configure / force the usage of a specific transport layer using the CPublisher C++ API, like this:

 // force tcp send mode
 pub.SetLayerMode(eCAL::TLayer::tlayer_all, eCAL::TLayer::smode_off);
 pub.SetLayerMode(eCAL::TLayer::tlayer_tcp, eCAL::TLayer::smode_on);

I modified the existing eCAL minimal send sample to send over tcp messages every 5 minutes:

int main(int argc, char** argv)
{
 std::cout << "-------------------------------" << std::endl;
 std::cout << " HELLO WORLD SENDER" << std::endl;
 std::cout << "-------------------------------" << std::endl;

 // initialize eCAL API
 eCAL::Initialize(argc, argv, "minimal_snd");

 // publisher for topic "Hello"
 eCAL::string::CPublisher<std::string> pub("Hello");

 // force tcp send mode
 pub.SetLayerMode(eCAL::TLayer::tlayer_all, eCAL::TLayer::smode_off);
 pub.SetLayerMode(eCAL::TLayer::tlayer_tcp, eCAL::TLayer::smode_on);

 // send updates
 int cnt = 0;
 while (eCAL::Ok())
 {
   // build string
   std::stringstream snd_content;
   snd_content << "Hello World" << " (" << ++cnt << ")";

   // send content
   pub.Send(snd_content.str(), cnt);

   std::cout << "Sent \"" << snd_content.str() << "\"" << std::endl;

   // sleep 5 minutes
   std::this_thread::sleep_for(std::chrono::minutes(5));
 }

 // finalize eCAL API
 eCAL::Finalize();

 return(0);
}

It worked well on my machine with no message drops. So if you say during the sender does not send a message for a long time are you sending in a very low frequency like shown in the sample above or do you interrupt the sending node by pausing or debugging it?

Important to understand is, that eCAL is exchanging registration information in the background with an 1 Hz frequency. This registration thread should not be interrupted.

[BoxCharon]

Hi @rex-schilasky ,thanks for your help.
In my understand,in ecal.ini set use_tcp = 2 and use_udp_mc = 0 means use tcp to communication,or it have any other config to set transport layer? i will try to force the usage of a specific transport layer.The actual situation more like sending node by pausing or debugging,it not to slow down frequency.

[FlorianReimold]

@rex-schilasky: I think you missread the ecal.ini. BoxCharon posted the following configuration:

[publisher]
use_inproc                         = 2
use_shm                            = 2
use_tcp                            = 2
use_udp_mc                         = 0

That configuration should to my knowledge be absolutely valid, we even advertise that configuration in the documentation for use-cases where you don't want UDP data transport.

However, TCP will not be used, as they also set network_enabled = false. As the auto-setting is only used for network mode, but it is turned off, the default shared memory layer is used.

@BoxCharon: You understood that correctly. I am pretty sure, your issue is the following:

The actual situation more like sending node by pausing or debugging

I guess by pausing you also mean pausing the entire process with a debugger etc. If you do that, you will not only halt your own code, but you also stall the ecal-internal registration thread. That thread periodically sends out registration packages to make its topics visible to other nodes. By pausing that thread, other nodes will assume that your process has been terminated and therefore unsubscribe from the data after a certain timeout. You can configure the timeout in the ecal.ini and set it to a very large value:

[common]
registration_timeout               = 60000

This is the default value (6000ms = 6s) (60000ms = 60s). If you increase that number, external nodes will wait longer before dropping that connection due to the timeout. Please try increasing the timeout, but be aware that e.g. the eCAL Monitor will also be rather unresponsive and wait for the entire timeout before removing terminated nodes.

[rex-schilasky]

@FlorianReimold, fully correct. I thought tcp and udp were set to auto. One minor correction. The registration_timeout default is 60000ms = 60s.

[FlorianReimold]

Please create a new discussion instead of hijacking somebody else's.