Update of Datawriter and Datareader

9 posts / 0 new
Last post
Offline
Last seen: 9 years 11 months ago
Joined: 08/28/2013
Posts: 66
Update of Datawriter and Datareader

Hi,

I would like to know, from RTI point of view, which method is the best in case, for example, of a datawriter becoming a datareader.
I have a generic product and so in one case I can have a datawriter of topic toto and in one other case it could be a datareader of topic toto.

1/ Should i delete all entities and reconstruct everything

2/ Should i keep my participant and delete all its contained entities (subscriber, publisher, topic, datareader,....)

I ask that because with vxWorks there is an issue with participant ID so may be i should keep my participant and its participant ID.

Regards,

Rodolf 

rose's picture
Offline
Last seen: 2 years 8 months ago
Joined: 08/22/2011
Posts: 148

Hello Rodolf, 

The best mechanism would be to keep the DomainParticipant instead of creating a new one, because:

  1. You get no advantages in this case by creating a new DomainParticipant.  If you needed different settings for discovery or participant resource limits, it might make sense, but in this case I don't see a good reason to create a new one. 
  2. Creating a new DomainParticipant allocates resources and opens ports, which may be slow in comparison to the response time you want your application to display.
  3. A new DomainParticipant has to rediscover all of the remote DomainParticipants and their DataWriters/DataReaders.  
  4. On VxWorks you have to configure a new participant ID.  (Note that this is only one reason out of many, though.)

Thank you!

Rose

Offline
Last seen: 9 years 11 months ago
Joined: 08/28/2013
Posts: 66

Thanks for reply Rose.

I have done this modification but i have a problem when discovery is dpse.

In fact, when calling DPSE_RemoteParticipant_assert(), the previous record still exists but can not be updated.

It goes in NDDS_DomainParticipant_assert_remote_participant() but there, I have record != NULL and dbrc == DB_RETCODE_NOT_EXISTS after call to DB_Table_select_match.

This leads to DDSC_Log_assert_rem_participant_unknown(OSAPI_LOGKIND_ERROR,dbrc);

So i understand that my previous assert remote  participant is still in memory for my participant.
I tried to use NDDS_DomainParticipant_reset_remote_participant without success. I do not know the field DDS_BuiltinTopicKey_t that it is waiting for.

Regards,

Rodolf



Note that no problem when i was completely destroying participant + recreating it after.

 



Regards,

Rodolf

rose's picture
Offline
Last seen: 2 years 8 months ago
Joined: 08/22/2011
Posts: 148

Hello Rodolf, 

That is a good point; I was not thinking about the DPSE use case.  For the DPSE use case, the discovery time is much shorter, so that is not as big a concern.  

I do not know the details of NDDS_DomainParticipant_reset_remote_participant() – I'll see if I can find somebody to help answer that.

Thank you!

Rose

Offline
Last seen: 9 years 11 months ago
Joined: 08/28/2013
Posts: 66

Hi Rose,

I found my DDS_BuiltinTopicKey_t for the reset/remove call but it ends always with RETCODE_KO.

What should be called (RTI DDS function) to clean the following entities:

DPSE_RemoteParticipant_assert(participant,partnerName);
DPSE_RemotePublication_assert(participant,partnerName,&rem_publication_data,NDDS_TYPEPLUGIN_USER_KEY);

I tried :

NDDS_DomainParticipant_reset_remote_participant
(participant,&rem_publication_data.key);
NDDS_DomainParticipant_remove_remote_publication(participant,&rem_publication_data.key);

I changed the order of call (remove_publication before remove_participant), but these two calls ends in error.
I tried also to call these before cleaning QoS, but always KO.

Regards,

Rodolf

Regards,

Rodolf

 



Offline
Last seen: 9 years 11 months ago
Joined: 08/28/2013
Posts: 66

Hi,

I had to change some code that was based on helloworld_dpse.

1/ Call to DPSE_RemoteParticipant_assert shall be replaced by NDDS_DomainParticipant_assert_remote_participant + NDDS_DomainParticipant_enable_remote_participant_name

In fact, DPSE_RemoteParticipant_assert is creating a builtintopic for Participant with available IDs. These IDs is not known from me, so NDDS_DomainParticipant_reset_remote_participant failed.
Now i have made my DDS_ParticipantBuiltinTopicData and i imagine it is the same as pub or sub, i have to set the rtps_object_id of the participant and its host_app (etc) in the participant QoS.

But what is strange right now, is that my datawriter found a matching Partner (callback on_publication_matched) despite it is alone.

I have a participant "A" with a datawriter object id =2 looking for a datareader object id= 1 included in partipant "B" declared with guid=2.3.4.x (x seems to be always 1C1).
I declare remote subscription with these values.
But i go these logs as soon as i enable remote participant (which is not connected yet):

DDS Remote Participant is enable: OK
[0.483333315] TID[2169650816]UDP: Started thread on port: 7414
[0.516666646] TID[2152568516]RTPS bind: fwd: src: 0/2000000.3000000.4000000.7020000 ==> dst 0/0.4444444.deadc0de.2 060000
[0.533333313] TID[2152568516]UDP: bind_external: 7415/7f000001.0.0.0 ==> dst 0/0.4444444.deadc0de.0
[0.549999979] TID[2152568516]UDP: bind_external succeeded: 7415/7f000001.0.0.0 ==> dst 0/0.4444444.deadc0de.0 (cou nt = 1)
[0.549999979] TID[2152568516]UDP: bind_external: 7415/c0a801b7.0.0.0 ==> dst 0/0.4444444.deadc0de.0
[0.566666644] TID[2169652584]UDP: Started thread on port: 7415
[0.566666644] TID[2152568516]UDP: bind_external succeeded: 7415/c0a801b7.0.0.0 ==> dst 0/0.4444444.deadc0de.0 (cou nt = 2)

 

 DDS DataWriter of Topic xxxx has currently 0001 DataReader Matching with Qos

DDS DataWriter assert DataReader with ID 2 result is OK
DDS Participant is enable: 1

After a while, lost of liveliness appears and if i launch my participant B, communication is OK.

So why is Participant A finding someone to talk too ?

Regards,

Rodolf

Offline
Last seen: 9 years 11 months ago
Joined: 08/28/2013
Posts: 66

Hi,

I got also another issue with dpse.
If i keep my participant and recreate a datawriter for which datareader is still alive, it takes between 3 seconds and 45 seconds for my datareader to receive data.
Last message of it concerns sample with not alive instance, and then after this "random" delay, it receives data without warning or rediscover log (based on callbacks).

The Datawriter can assert liveliness. Can the datareader also send messages to tell it is alive and ready ?
Which parameter shall i see for this delay ?

My datawriter asserts every second for a lease of 5 seconds.

Thanks for help.

Rodolf 

 

[EDIT]

Im trying to find remote participant built in key when using DPSE_RemoteParticipant_assert.
I found DDS_DomainParticipant_get_discovered_participants which gives a list of handles.Then i convert handle to GUID.

I have one participant found (OK), but its value is 0 for each octet (KO) so NDDS_DomainParticipant_remove_remote_publication fails.

Any help is appreciated.

[EDIT BIS]

I found that for RTI ME 2.2.3, some code is commented and especially for what i am trying to do.

In file DomainParticipant.c line 2903

dbrc = DB_Cursor_get_next(cursor, (DB_Record_T*)&rem_participant);
#if 0
TODO: Fix this when remote discovery has been implemented
DDS_InstanceHandle_from_rtps(DDS_InstanceHandleSeq_get_reference(participant_handles, count),(conststruct MIGRtpsGuid *)&rem_participant->data.key);
++count;
#endif

So what should i do ?
Decomment and rebuild the library ?
Or wait for new version of RTI ME ?

#endif

Offline
Last seen: 5 years 11 months ago
Joined: 01/17/2013
Posts: 22

Hi Rodolf,

First, DDS_DomainParticipant_get_discovered_participants() is not currently a supported public API.  As you've seen, its implementation is mostly there but is untested.  Thus, though you can uncomment and recompile its existing implementation, its functionality is not officially supported for this release.  To make sure I understand your use-case, can you explain why you are finding a remote participant's builtin-key when asserting it?

Second, please clarify and help me understand what you mean by "If i keep my participant and recreate a datawriter for which datareader is still alive, it takes between 3 seconds and 45 seconds for my datareader to receive data."  Do you mean you have more than 1 participant?  Where 1 participant has its datareaders deleted and recreated as datawriters, writing to datareaders still alive on another participant?  If that's all correct, are you asserting remote publication and remote subscription upon creating the datareaders and datawriters?  Finally, what is your datareader's liveliness lease_duration?

Regards,

Edward

 

Offline
Last seen: 9 years 11 months ago
Joined: 08/28/2013
Posts: 66

Hi Edward,

1/ I have a participant containing a datawriter and a datareader on a machine IP 192.168.1.10
He is alone in a DDS World. I made the code like the one in helloworld_dpse. It is the same, except that DW and DR are within the same participant.
I made all check for dpse (assert remote participant with its name, remote datareader and remote datawriter with their specific object_ids.

I can understand that the DW finds the DR on the same host (as dpse is a "static" configuration, it should have been filtered out by object_id, but lets admit), but i don t understand why the DR is finding a ghost DW.
Here are the logs:

Register DPSE is OK

[0.83333330] TID[2152594796][UDP] bind port: 1/7410/7f000001
[0.333333321] TID[2152594796][UDP] set socket buffer size: 1/7410/7f000001 = 8192 bytes
[0.349999987] TID[2152594796]UDP: created port entry: 1/7410/7f000001
[0.349999987] TID[2152594796]UDP: created port thread: 1/7410/7f000001
[0.366666653] TID[2152594796][UDP] bind port: 1/7410/c0a801b7
[0.366666653] TID[2152594796]UDP: port exists: 1/7410/c0a801b7
[0.366666653] TID[2152594796][UDP] bind port: 1/7411/7f000001
[0.383333319] TID[2152594796][UDP] set socket buffer size: 1/7411/7f000001 = 8192 bytes
[0.383333319] TID[2152594796]UDP: created port entry: 1/7411/7f000001
[0.383333319] TID[2152594796]UDP: created port thread: 1/7411/7f000001
[0.399999985] TID[2152594796][UDP] bind port: 1/7411/c0a801b7
[0.399999985] TID[2152594796]UDP: port exists: 1/7411/c0a801b7
[0.466666649] TID[2152594796]RTPS bind: fwd: src: 0/0.0.0.c2000100 ==> dst 0/0.8888885.deadc0de.c7000100
[0.466666649] TID[2152594796]UDP: bind_external: 7410/7f000001.0.0.0 ==> dst 0/0.8888885.deadc0de.0
[0.466666649] TID[2152594796]UDP: bind_external succeeded: 7410/7f000001.0.0.0 ==> dst 0/0.8888885.deadc0de.0 (count = 1)
[0.466666649] TID[2152594796]RTPS bind: fwd: src: 0/0.0.0.c2000100 ==> dst 0/0.8888885.deadc0de.c7000100
[0.466666649] TID[2152594796]UDP: bind_external: 7410/c0a801b7.0.0.0 ==> dst 0/0.8888885.deadc0de.0
[0.466666649] TID[2152594796]UDP: bind_external succeeded: 7410/c0a801b7.0.0.0 ==> dst 0/0.8888885.deadc0de.0 (count = 2)

DDS Datawriter - create for type toto
DDS Datareader - create for type toto

DDS Participant assert Remote Participant . Result: OK
DDS DataWriter assert DataReader with ID 2 result is OK
DDS DataReader assert DataWriter with ID 11 result is OK

DDS DataReader of Topic toto failed to receive liveliness in time. (Nb of Miss: 1)

[0.499999981] TID[2169695688]UDP: Started thread on port: 7410
[0.566666644] TID[2152594796]RTPS bind: fwd: src: 0/0.8888885.deadc0de.2010000 ==> dst 0/0.8888885.deadc0de.7140000
[0.583333310] TID[2152594796]UDP: bind_external: 7411/7f000001.0.0.0 ==> dst 0/0.8888885.deadc0de.0
[0.583333310] TID[2152594796]UDP: bind_external succeeded: 7411/7f000001.0.0.0 ==> dst 0/0.8888885.deadc0de.0 (count = 1)
[0.599999977] TID[2152594796]UDP: bind_external: 7411/c0a801b7.0.0.0 ==> dst 0/0.8888885.deadc0de.0
[0.616666643] TID[2169697288]UDP: Started thread on port: 7411
[0.616666643] TID[2152594796]UDP: bind_external succeeded: 7411/c0a801b7.0.0.0 ==> dst 0/0.8888885.deadc0de.0 (count = 2)

DDS DataReader of Topic toto has currently 0001 Datawriter Matching with Qos
DDS DataWriter of Topic toto has currently 0001 DataReader Matching with Qos
DDS DataReader of Topic toto has currently 0002 Datawriter Matching with Qos   (<---log in reader_listener.on_subscription_matched with status->current_count)

DDS Participant is enable: 1

I can activate more logs if you need.

 2/ Concerning this use case, it is not more up to date as the participant is destroyed in dpse with its DW and DR when the configuration change.
This was a result of discussion http://community.rti.com/forum-topic/dpse-static-discovery-rti-me-223.

 

The only "problem" is this ghost partner and the use case of http://community.rti.com/forum-topic/dpse-static-discovery-rti-me-223.
It is the same use case as this one excepts that the GUID is more specific than just the object_id (host_id,instance_id,app_id are specified).

I had also this issue http://community.rti.com/forum-topic/dpse-static-discovery-rti-me-223 but it is related to participant_ID on vxworks.

Thanks for Help anyway.

Rodolf