A Sikorsky Innovations Company

Hello-

As we gradually add new types to our system we are starting to reach the limits of available memory.  We have one or two types that are particularly large.

Suppose we have a single type that contains an array of data totalling 100MB in size.  Assume we want strict reliability and have no need at present to queue up multiple reads.  Consider it an error if we cannot process the current read before the next write is posted to our endpoint.  Assume this is not a keyed topic and there is 1 remote writer.

Hello-

We have a scenario where we autogen the same set of IDL files for Java, C++, and C#.  This IDL contains an enumeration type with IDs in one file and a struct type in another file with a single member of this enumerated ID type.  I don't believe the file seperation is actually contributing to the problem but I haven't determined this conclusively yet.

Rtiddgen properly creates the Java & C++ code fine, but when we autogen to C# the resulting cpp code is attempting to reference a ::copy_from() method that does not exist in the associated header file.

Hello-

Without AppCreator, we are only able to define QoS to share across distributed applications.  We’d prefer to have a single definition of all the types, topics, and QoS.  Furthermore, we’d like to have data readers/writers for those topics defined since QoS applies there too.  This helps to avoid problems of mismatched QoS for a topic.  This makes use of AppCreator attractive.

I saw a question in the General Questions forum related to default values of QoS parameters.  The answer pointed the user to the API reference guide.  However, that is still a very point-and-click (and time) intensive method to get the desired information for more than a few settings.  Does there exist a single document or web page which gives a comprehensive list of all settings and their related XML translation?  The "rti_dds_profiles.xsd" file does seem to contain much of this data but not in an easily read format...

We have a system consisting of a C based RTI DDS program running as a VxWorks 6.7 DKM which subscribes to and receives up to 2MB data packets and, in turn, generates approximately 34KB of data and publishes it back to the original data source.  For our current testing, the original data source comes from a Windows RTI DDS application (Java based running in Eclipse) while the target system is running on a Power PC target board.  They are connected via a 10/100 switch.