c# sequence length problems

2 posts / 0 new
Last post
Last seen: 10 years 9 months ago
Joined: 07/06/2013
Posts: 1
c# sequence length problems


I've not been using this long but I'm struggling to get varying sequence lengths to make it from the publisher to the subscriber.  ie, an anbounded sequence defaults to 100, fine, but if I use 'ensure_length' to set the max to (say) 20 and fill in 20 items, then the subscriber still gets a length of 100.  The 20 length isn't making it accross.

Even with the HelloIDL c# sample, if I try and reset the length, the full bounded (in this case) size still is reported as the sequence length at the subscriber.

Is it something to do with the C# interop with the c++ IDL/rttigen generated dll used?  I know I have to use 'copy_to' to get items into the published type samples.

Any advise, gratefully received


Last seen: 10 years 6 months ago
Joined: 06/24/2013
Posts: 8


I hope you mean that the subscriber gets a MAXIMUM length of 100. When I recreated your scenario I observed that the ACTUAL length is being properly reported at the subscriber, and only the MAXIMUM length remains unaffected.

If that is the case, then what you are seeing is normal behavior.

The maximum length of sequences contained within a data type is set by the IDL, and when empty samples are created by the reader all the contained elements (sequences, etc.) will be set to their maximum sizes. This is done to avoid any need for memory allocation during the reception of samples, which occurs on the critical path. During reception the reader will copy into the empty sample only the sequence members actually used (as determined by the sequence length), but because it can't know the actual length until reception, it needs to have room for the maximum possible of members.

When you call ensure_length on the writer to set the maximum to 20, it won't actually decrease the maximum length. If you look at the C# documentation for ensure_length you will notice that it says that if the current maximum is greater than the desired length, no resizing will occur. It's actually not a good idea to resize publication sequences, because if the publisher were to send more sequence members than the subscriber has space for, either a serialization or deserialization error will result. The serialization error will occur if the writer attempts to send more sequence members than the type allows for, and a deserialization error will occur if the reader receives more members than the type allows for.

The good news is that Connext only sends data for the actual sequence members in use (as determined by the sequence length). So even though there may be more room allocated at both the publisher and the subscriber, it won't affect performance or result in unneeded data sent on the wire.

I hope this explains the issue.