COMMENDFacade_canSampleBeSent:NOT SUPPORTED | Fragment data not supported by this writer Primary tabs

Hi, 

Based on the line 

PRESPsWriter_writeCommend:!anonw->write

it looks like it may be the builtin participant data writer that is failing to write because the Data(p) messages used for participant discovery are too big (this is a detail that you don't really need to know, but the 'anon' in that message stands for anonymous. We say that the participant writer and reader use an anonymous channel because it is not really best effort or reliable communiaction, just broadcasting messages to anyone in it's peer list. In case you see 'anon' in any messages again, that can help).

We do not support fragmentation of the participant channel, but one thing that usually helps is to make the participant messages smaller by removing a set of properties that we propogate by default and they can add a lot to the size of the data(p) messages. You can remove them like this by setting the 'propagate' tag to false: 

<participant_qos>
  <property>
    <value>
      <element>
          <name>dds.sys_info.hostname</name>
          <value>"hostname will not be propagate"</value>
          <propagate>false</propagate>
      </element>
      <element>
          <name>dds.sys_info.process_id</name>
          <value>1234</value>
          <propagate>false</propagate>
      </element>   
      </value>
  </property>
</participant_qos>

 The full list to disable is:

• dds.sys_info.creation_timestamp
• dds.sys_info.executable_filepath
• dds.sys_info.execution_timestamp
• dds.sys_info.hostname
• dds.sys_info.target
• dds.sys_info.process_id
• dds.sys_info.username

It doesn't matter what the 'value' tag is set to. These properties are just used for debugging and informational purposes. 

Hi Soumya,

It seems that you should be a supported customer of ours.

Could you contact me at zklim@rti.com so that I can see how to help you further with this?

Thank you!

Regards,

Zhi Kai

Hi, 

Are you able to get a wireshark capture? If so, as a test, can you increase the message_size_max to a larger value (or not set it to anything so it takes the default), capture the rtps traffic, and see what the size of the Data(p) messages are in the capture? You can filter to see only Data(p) messages with this filter:

rtps.sm.wrEntityId == 0x000100c2 

It would be helpful to see the length of those packets and then expand the frame to look at the serialized data so we can see what is making them so large (I'm assuming either a lot of properties are being propagated or there are a lot of interfaces being announced). Specifially, I'm interested in expanding "Real-Time Publish Subscribe Wire Protocol" > "submessageId: Data (0x15)" > serializedData > serializedData. For example:

Hi, 

That's great that there's been some progress. The new error message looks to me like there may be another participant that is not setting the message_size_max to 1400. There should be other log messages warning you about that error. You can try 2 things: 

- Try and find the participant that is not using that setting and set the message_size_max to 1400. 

- Set the DomainParticipantQoS.receiver_pool.buffer_size to 65507. From the documentation of that QoS: 

You may want the value to be greater than the default if you try to limit the largest data packet that can be sent through the transport(s) in one application, but you still want to receive data from other applications that have not made the same change.

For example, to avoid IP fragmentation, you may want to set NDDS_Transport_Property_t::message_size_max for IP-based transports to a small value, such as 1400 bytes. However, you may not be able to apply this change to all the applications at the same time. To receive data from these other applications the buffer_size should be equal to the original NDDS_Transport_Property_t::message_size_max.