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
Hello Rodolf,
The best mechanism would be to keep the DomainParticipant instead of creating a new one, because:
Thank you!
Rose
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
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
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
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
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
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
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