Re: [opendds-main] Problem with QoS Policies

[Alex D. <ale...@gm...>]

Regarding my previous question,

I used the next rtps.ini file :

[common]
DCPSDefaultDiscovery=DEFAULT_RTPS
DCPSGlobalTransportConfig=my_config

[config/my_config]
transports=tcp_transport,rtps_transport

[transport/tcp_transport]
transport_type=tcp

[transport/rtps_transport]
transport_type=rtps_udp

According to developers guide (page 100) , all participating processes
use this configuration file, the application attempts to use tcp to
initiate communication between data writers and readers. If the
initial tcp communication fails for any reason (e.g. application from
different DDS vendor) rtps_udp is used to initiate the connection.

My data writer and reader use the above configuration, discover one
another, but the reader does not receive samples from the writer
(firewall is disabled as well).
If I change 'transports=tcp_transport,rtps_transport' to
transports=rtps_transport,tcp_transport everything works fine.
If I change 'transports=tcp_transport,rtps_transport' to
transports=tcp_transport everything works fine too.

So do you have any idea why with tcp first and rtps_udp as second
choice I cannot receive any samples ?

Kind Regards,
Alex

On Wed, Dec 3, 2014 at 10:15 AM, Alex Douckas <ale...@gm...> wrote:
> Hello,
>
> First of all thank you for your help. It finally worked after changing
> to TCP transport. I was using RTPS UDP in my rtps.ini file as below :
>
> [common]
> DCPSGlobalTransportConfig=my_config
> DCPSDefaultDiscovery=DEFAULT_RTPS
>
> [config/my_config]
> transports=rtps_transport
>
> [transport/rtps_transport]
> transport_type=rtps_udp
> use_multicast=0
>
> and the only change I did in my rtps.ini was the transport type from
> "rtps_udp" to "tcp"
>
> A question that rose after this change :
> Isn't this configuration now preventing the application for being
> interoperable with other DDS implementations ? I am asking because in
> the OpenDDS Developers Guide states "The rtps_udp transport is one of
> the pluggable transports available to a developer and is necessary for
> interoperable communication between implementations." Is there any way
> to keep interoperability and use TCP transport as well ?
>
> Regards,
> Alex
>
> On Mon, Dec 1, 2014 at 6:18 PM, Jeff Schmitz <sch...@oc...> wrote:
>> Hi Alex,
>>
>> A few points
>>
>> 1. In the subscriber, it is not enough to check the status of take_next
>> sample().  You should also check info.valid_data
>>
>> 2. In the publisher, if you want it to behave reliably, change the history
>> kind to KEEP_ALL_HISTORY_QOS, and use resource limits to control the number
>> of samples in history.  Then check for a timeout status from the write()
>> call.  See the Reliability example.
>>
>> 3. Use TCP transport, if you are not.  It is the most trusted transport of
>> OpenDDS
>>
>> If this does not fix your problem, I'd suggest starting with the reliability
>> example, and working your way back to your example to see the difference.
>>
>> jeff
>>
>> On Thu, Nov 27, 2014 at 3:02 AM, Alex Douckas <ale...@gm...> wrote:
>>>
>>> Hello,
>>>
>>> I have created a publisher application and a subscriber one ( both in
>>> C++ ) with the following QoS policies on both Topic and DataWriter (
>>> and DataReader respectively ) :
>>>
>>> DDS::TopicQos default_topic_qos;
>>> participant->get_default_topic_qos(default_topic_qos);
>>> default_topic_qos.history.kind = DDS::KEEP_LAST_HISTORY_QOS;
>>> default_topic_qos.history.depth = 140000;
>>> default_topic_qos.reliability.kind = DDS::RELIABLE_RELIABILITY_QOS;
>>>
>>> DDS::DataWriterQos dw_default_qos;
>>> pub->get_default_datawriter_qos (dw_default_qos);
>>> dw_default_qos.history.kind = DDS::KEEP_LAST_HISTORY_QOS;
>>> dw_default_qos.history.depth = 140000;
>>> dw_default_qos.reliability.kind = DDS::RELIABLE_RELIABILITY_QOS;
>>>
>>> Now, the publisher is sending about 3000 data samples, each one every
>>> 100 miliseconds. So to test the history and reliability policies, I
>>> set a delay on the subscriber ( with usleep) of 500 miliseconds on the
>>> "on_data_available" class like this :
>>>
>>>       DDS::SampleInfo si ;
>>>       DDS::ReturnCode_t status = measurement_dr->take_next_sample(data,
>>> si) ;
>>>
>>>       if (status == DDS::RETCODE_OK) {
>>>          //omitted Code that manipulates the data sample
>>>
>>>              usleep (500000);
>>>
>>>        } else if (status == DDS::RETCODE_NO_DATA) {
>>>         cerr << "INFO: reading complete after " << count << " samples." <<
>>> endl;
>>>         break;
>>>       }
>>>
>>> The problem is that after about 1000 received samples, the subscriber
>>> somehow stops receiving the rest samples. Since the depth of History
>>> is bigger than the samples, the subscriber should receive everything.
>>> The same thing happens even if I use KEEP_ALL_HISTORY instead of
>>> KEEP_LAST. Do you have any idea about this issue ?  Am I using the
>>> policies wrong ?
>>>
>>> Thanks,
>>> Alex
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> opendds-main mailing list
>>> ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/opendds-main
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> opendds-main mailing list
>> ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opendds-main
>>