Functionnal Issue - Network cut [Resolved]

5 posts / 0 new
Log in or register to post comments
Last post
Wed, 01/08/2014 - 06:46
#1
Rodolf
Offline
Last seen: 10 years 8 months ago
Joined: 08/28/2013
Posts: 66
Functionnal Issue - Network cut [Resolved]

Edit:
If someone could try the following scenario to see if the issue occurs also. 
The test concerns the recovery when the connection is cut (ethernet).

Test 1:

DDS entity local Pub enable: OK
DDS entity remote Sub enable: OK
DDS match between Sub and Pub: OK
Ethernet cable unplugged
Ethernet cable plugged
Match and exchanged data: OK

Test 2:

DDS entity local Pub enable: OK
Ethernet cable unplugged
DDS entity remote Sub enable: OK
Ethernet cable plugged
DDS match between Sub and Pub: KO

What should be done in order to recover from this non communication ?
Is there a QoS for this use case ?

Regards,

Rodolf

 

Top
Mon, 01/13/2014 - 01:17
Rodolf
Offline
Last seen: 10 years 8 months ago
Joined: 08/28/2013
Posts: 66

Some precision:

PUB on 192.168.1.10
SUB on 192.168.1.1

Top
Wed, 01/15/2014 - 11:33
sumeet_rti
Offline
Last seen: 6 years 5 months ago
Joined: 01/31/2011
Posts: 37

Hi Rodolf,

Which operating system are you running on?

In Test 1, the ethernet interface is UP when the DDS::DomainParticipants are enabled.  That is, when you enable a DDS::DomainParticipant, our libraries will retrieve all available UP network interfaces and use the information for discovery.  At a lower level, we'll do three things with the interface information:

  1. open a unicast socket for listening on each interface
  2. open a multicast socket for listening on each interface
  3. use the interface IP address to generate a list of "locators", addresses by which the DDS::DomainParticipant can be contacted

In Test 2, the ethernet interface is not UP when the DDS::DomainParticipant is enabled (note: this depends on the Operating System).  Consequently, the DDS::DomainParticipant does not have any knowledge of network interfaces, and therefore cannot listen for discovery announcements.

There is no QoS to support this use case.  Some operating systems do allow the interface to still be UP even though the interface is not RUNNING (aka, cable plugged in), and our libraries will take advantage of this configuration.  Otherwise, your only option is to not enable the DDS::DomainParticipant until the interface is UP.

-sumeet

Top
Thu, 01/16/2014 - 04:05
Rodolf
Offline
Last seen: 10 years 8 months ago
Joined: 08/28/2013
Posts: 66

Hi Sumeet,

Thanks for reply.
Im on vxWorks with rti me 2.2.3.

I will add a check at "enable" step.

For this OS, unplugged cable do not "down" the interface:
cpsw0   Link type:Ethernet  HWaddr 00:18:32:28:be:ad  Queue:none
        inet 192.168.1.10  mask 255.255.255.0  broadcast 192.168.1.255
        UP SIMPLEX BROADCAST MULTICAST

Regards,

Rodolf

Top
Thu, 01/16/2014 - 06:16
Rodolf
Offline
Last seen: 10 years 8 months ago
Joined: 08/28/2013
Posts: 66

I added a check in my windows DDS API and now Test is OK.
To be very precise, ethernet link shall be checked before DDS_DomainParticipantFactory_create_participant and not before DDS_Entity_enable despite of:

/** Set Qos Factory Participant */
DDS_DomainParticipantFactory_get_qos(factory, &dpf_qos);
dpf_qos.entity_factory.autoenable_created_entities = DDS_BOOLEAN_FALSE;
DDS_DomainParticipantFactory_set_qos(factory, &dpf_qos);

Regards,

Rodolf

Top