RTI Data Distribution Service

RTI Data Distribution Service The Real-Time Publish-Subscribe Middleware Release Notes Version 4.4d

2009 Real-Time Innovations, Inc. All rights reserved. Printed in U.S.A. First printing. May 2009. Trademarks Real-Time Innovations and RTI are registered trademarks of Real-Time Innovations, Inc. All other trademarks used in this document are the property of their respective owners. Copy and Use Restrictions No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form (including electronic, mechanical, photocopy, and facsimile) without the prior written permission of Real-Time Innovations, Inc. The software described in this document is furnished under and subject to the RTI software license agreement. The software may be used or copied only under the terms of the license agreement. Technical Support Real-Time Innovations, Inc. 385 Moffett Park Drive Sunnyvale, CA 94089 Phone: (408) 990-7444 Email: support@rti.com Website: http://www.rti.com/support

Contents 1 System Requirements... 2 1.1 Supported Operating Systems... 2 1.2 Disk and Memory Usage... 4 1.3 Networking Support... 4 2 Compatibility... 12 2.1 Wire Protocol Compatibility... 12 2.2 API and Generated-Code Compatibility...14 2.3 Data-Format Compatibility and Extensibility... 17 2.4 ODBC Database Compatibility... 18 2.5 API Compatibility... 18 3 What s Fixed in 4.4d... 20 3.1 read/take_next_instance() May Return NO_DATA Error... 20 3.2 Samples May be Placed in Wrong Instance when Using Variable-Size Key... 20 3.3 Large Data Implementation was Not Compliant with RTPS 2.1 on the Wire... 20 3.4 Reliable Writers Incorrectly Resent Large Data Without Asynchronous Publishing Enabled... 21 3.5 Key Information Cannot be Included with DISPOSE Messages... 21 3.6 Inconsistent Policy Error when set_qos() Called for a Best-Effort Writer... 21 3.7 Failure when set_qos() Called on a Disabled Writer...21 3.8 get_qos() May Have Provided Incorrect UserDataQosPolicy for DataWriter and DataReader... 22 3.9 Error When Creating ContentFilteredTopic DataReaders with Disabled Subscriber and Using Debug Libraries... 22 3.10 Failure When Transport Property's message_size_max Set to 512 or Less... 22 3.11 Incorrect Values for DDS_LOCATOR_KIND Constants Used for Interpreting Builtin Topic Data... 22 3.12 Resources May Not be Released During Participant ID Reservation...23 3.13 Possible Resource Leak During Participant ID Reservation When Using Multiple Instances of Same Transport... 23 3.14 Property Sequence Set in Derived XML Failed to Overwrite Parent Sequence... 23 iii

3.15 topic_filter XML Attribute Mistakenly Allowed in Participant, Publisher, and Subscriber QoS...24 3.16 Error Caused By Using XML QoS Profile With Same Name as Its Library...25 3.17 XML QoS Schema File had Extra Fields for DataReaderResourceLimitsQosPolicy...25 3.18 XML QoS Schema File was Missing PropertyQosPolicy s propagate Field...25 3.19 Typedef of Typedef Conversion from IDL to XSD May Have Generated Invalid Code...25 3.20 Incorrect Mapping from IDL to XSD by rtiddsgen for Valuetype baseclass...26 3.21 Incorrect Mapping from IDL to XSD by rtiddsgen for #include Statements...27 3.22 Operators, &, <<, >>, ~, ^ Not Supported in const Expressions when Converting IDL to XSD wtih rtiddsgen...28 3.23 Failure when Using Strings Longer Than 254 Characters in QoS.NET APIs Only...28 3.24 namespace ignored by rtiddsgen C++/CLI API Only...29 3.25 Building Types in Different Dynamic Libraries on Windows...29 3.26 Compilation Warnings when IDL Generated Code with Value Types is Compiled on Windows...29 4 What s Fixed in 4.4c...30 4.1 Writer-side Filtering of Resent Data Sometimes Caused Segmentation Fault...30 4.2 Reliable Communication May Have Stalled When Writer-side Filtering Enabled...30 4.3 Writer-side Filtering Sent Filtered Samples on the Wire...30 4.4 Piggyback Heartbeats Not Disabled When heartbeats_per_max_samples Set to Zero...30 4.5 Problems with Asynchronous Flushing of Batched Samples...31 4.6 Problems with wait_for_acknowledgements() When Using Multi-channel DataWriters...31 4.7 Out-of-memory Errors After Creating/Enabling a DataWriter Crashes JVM...31 4.8 Hanging Problem when Deleting a DomainParticipant on a Windows Host...31 4.9 get_<entity>_qos_from_profile() Reported an Error if profile_name or library_name parameters Were NULL...32 4.10 XML Parser Failed To Report Error for Missing Partition Sequence Tag...32 4.11 Problems with QoS Profile Inheritance...32 4.12 Segmentation Fault when Using a Custom DTD with Subgroups of Children...33 4.13 C# Generated Type Names Inconsistent with C, C++ & Java Type Names...34 4.14 Generated C# Example Code Used Incorrect Logging Value...34 4.15 C++/CLI Code Generated for Value Types Does Not Compile...35 4.16 C++/CLI Code Generated with -use42ealignment Option Does Not Compile...35 4.17 NACK-only Feature Was Not Supported on Non-Floating-Point Platforms...35 4.18 Changes in Dynamic Data Java API...36 4.19 Improved Performance in Dynamic Data...36 iv

4.20 Serialization Error Messages When Using Builtin Types and Batching...36 5 What s Fixed in 4.4b... 37 5.1 Asymmetric Loss of Liveliness May Have Halted Discovery... 37 5.2 Failure When Allocating Memory Larger Than 2GB... 37 5.3 Endianness of Keys in Publication and Subscription Builtin Topic Data... 37 5.4 Resolved Cross-language Instance-Lookup Issue When Using Keyed Data Types with.net... 37 5.5 Problems with ContentFilteredTopics when Multiple DataWriters in Same DomainParticipant... 38 5.6 Problems with Writer-Side Content-Filtering on Serialized Data... 38 5.7 Best-Effort DataWriter Failed When Statistics Enabled... 38 5.8 Memory Leak When Destroying WaitSets and Exclusive Areas Windows Systems Only... 38 5.9 Exception Logged for Content Filtered Topic Compile Errors During Discovery Java API Only... 39 5.10 Problems Using Profiles with XML Tag <writer_qos>... 39 5.11 Problem with topic_filter Attribute in C++, Java and.net APIs... 39 5.12 QoS Profiles Not Loaded Automatically when Using NDDS_QOS_PROFILES... 39 5.13 No Error Reported if XML File Set if URL Group Could Not be Found...40 5.14 Error if Files in URL Groups Contained Same Profile... 40 5.15 Using Spaces in Selector for Unions... 40 5.16 Could Not Generate.NET Example Code for Types inside a Module...41 5.17 rtiddsping and rtiddsspy Rejected Domain IDs Over 100... 41 6 What s Fixed in 4.4a... 42 6.1 Slowdown When Sending Many Instances with Transient Local Durability and No Matching DataReaders... 42 6.2 Reliable Writer Failed to Send Data in Repair Messages in a Timely Manner... 42 6.3 Multiple Keyed Topics Caused Failure in rtiddsspy... 42 6.4 Resolved Cross-language Instance Lookup Issue When Using Keyed Data Types with Java... 42 6.5 Setting Default Profile on a Publisher Mistakenly Affected Default DataWriter QoS... 43 6.6 XML Parser Failed if User-specified DTD File Not Found... 43 6.7 No Message Logged if DDS_DomainParticipantFactory_get_qos_from_profile() Failed... 43 6.8 RTI Data Distribution Service Failure when Parsing XML Files with Errors... 43 6.9 Performance Degradation when Calling read/take with access_scope INSTANCE or ordered_access FALSE and Many Instances...44 v

6.10 Incorrect Evaluation of Nested Content Filter Expressions C/C++ APIs...44 6.11 Error Processing Empty Expressions in ContentFilteredTopics...44 6.12 Receipt of Batched Data Did Not Always Trigger on_data_available() for Keyed DataReaders with ContentFilteredTopics...44 7 Known Issues...45 7.1 Typedefs of Sequences Causes Compiler Errors...45 7.2 Estimate of Message Overhead For Large Data May Be Exceeded...45 7.3 Incomplete Builtin Topic Data Returned from get_matched_*_data(), get_discovered_participant_data()...45 7.4 UDPv6 Transport Requires Change to NDDS_DISCOVERY_PEERS...46 7.5 Behavior When Only localhost in Peer List and accept_unknown_peers is FALSE...46 7.6 Writer-side Filtering May Cause a Deadline to be Missed...46 7.7 Participant Listeners Should Not be Destroyed after Removal...47 7.8 Group Address Ignored for Multicast Receive on Loopback (Linux and LynxOS Systems Only)...47 7.9 Disabled Interfaces on Windows Systems...47 7.10 Problems Deleting DataWriters if Using Timestamp APIs and BY_SOURCE_TIMESTAMP Destination Order...47 7.11 Do Not Set push_on_write to False for Asynchronous DataWriters...48 7.12 Wrong Error Code After Timeout on write() from Asynchronous Publisher...48 7.13 Effect of Disabling DataWriter s Inline Keyhash on Some RTI Tools...48 7.14 Possible Error Determining Need for Fragmentation if Transports Configured Differently...48 7.15 NDDS.ConfigLogger.set_print_format() Incompatible with NDDS.ConfigLogger.set_log_delegate()...49 7.16 Incorrect Content Filtering for Valuetypes and Sparse Types...49 7.17 Microsoft does not include Debug Symbols in Visual Studio Redistributable Libraries...49 7.18 Issues with Dynamic Data Types...50 7.19 Issues with INTEGRITY Systems...52 vi

Release Notes This document includes the following sections: System Requirements (Section 1) Compatibility (Section 2) What s Fixed in 4.4d (Section 3) What s Fixed in 4.4c (Section 4) What s Fixed in 4.4b (Section 5) What s Fixed in 4.4a (Section 6) Known Issues (Section 7) For an overview of new features, please see the RTI Data Distribution Service What s New document (RTI_DDS_WhatsNew.pdf). For more information, visit the RTI Knowledge Base, accessible from http:// www.rti.com/support, to see sample code, general information on RTI Data Distribution Service, performance information, troubleshooting tips, and technical details. By its very nature, the knowledge base is continuously evolving and improving. We hope that you will find it helpful. If there are questions that you would like to see addressed or comments you would like to share, please send e-mail to support@rti.com. We can only guarantee a response to customers with a current maintenance contract or subscription. You can purchase a maintenance contract or subscription by contacting your local RTI representative (see http://www.rti.com/company/contact.html), sending an e-mail request to sales@rti.com, or calling +1 (408) 990-7400. 1

Release Notes 1 System Requirements 1.1 Supported Operating Systems RTI Data Distribution Service requires a multi-threaded operating system. This section describes the host and target systems supported by RTI Data Distribution Service. In this context, a host is the computer on which you will be developing a RTI Data Distribution Service application. A target is the computer on which the completed application will run. A host installation provides the code generation tool (rtiddsgen), examples and documentation, as well as the header files required to build an RTI Data Distribution Service application for any architecture. You will also need a target installation, which provides the libraries required to build an RTI Data Distribution Service application for that particular target architecture. Table 1.0 lists the platforms available with RTI Data Distribution Service 4.4d. Table 1.0 Platforms Available with Release 4.4d Platform Operating System Reference AIX AIX 5.3 Table 1.1 on page 5 Fedora Fedora 8 Table 1.3 on page 5 INTEGRITY INTEGRITY 5.0 Table 1.2 on page 5 Linux Red Hat Enterprise Linux 4.0, 5.0, 5.1 Red Hat Linux 8.0 and 9.0 Table 1.3 on page 5 LynxOS LynxOS 4.0, LynxOS 4.2, LynxOS 5.0, LynxOS-SE 3.0, Table 1.4 on page 7 QNX QNX Neutrino 6.3.0 Table 1.5 on page 7 Solaris Solaris 2.8, 2.9, and 2.10 Table 1.6 on page 8 VxWorks VxWorks 5.4.2, 5.5.1, 6.0-6.6 Table 1.7 on page 9 Windows Windows 2000 with service pack 2 or higher Windows 2003 and Windows 2003 x64 Edition Windows Vista Windows XP Professional and Windows XP Professional x64 Edition Table 1.8 on page 10 2

1 System Requirements Visual Studio 2005 Service Pack 1 Requirement You must have Visual Studio 2005 Service Pack 1 or the Microsoft Visual C++ 2005 SP1 Redistribution Package installed on the machine where you are running an application built with the following RTI architecture packages: x64win64vs2005 built with dynamic libraries i86win32vs2005 built with dynamic libraries i86win32jdk, x64win64jdk, and i86win32dotnet2.0 The Microsoft Visual C++ 2005 SP1 Redistribution Package can be downloaded from RTI s Self Service Portal 1, or obtained from the following Microsoft website: For x86 architectures: http://www.microsoft.com/downloads/details.aspx? familyid=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en For x64 architectures: http://www.microsoft.com/downloads/details.aspx? familyid=eb4ebe2d-33c0-4a47-9dd4-b9a6d7bd44da&displaylang=en Visual Studio 2008 - Service Pack 1 Requirement You must have Visual Studio 2008 Service Pack 1 or the Microsoft Visual C++ 2008 SP1 Redistribution Package installed on the machine where you are running an application built with the following RTI architecture packages: x64win64vs2008 built with dynamic libraries i86win32vs2008 built with dynamic libraries For x64 architectures: The Microsoft Visual C++ 2008 SP1 Redistribution Package can be downloaded from RTI's Self Service Portal 1, or obtained from the following Microsoft website: For x86 architectures: http://www.microsoft.com/downloads/details.aspx?familyid=a5c84275-3b97-4ab7-a40d-3802b2af5fc2&displaylang=en http://www.microsoft.com/downloads/details.aspx?familyid=ba9257ca-337f-4b40-8c14-157cfdffee4e&displaylang=en 1. On the portal, select the Downloads page. The Redistribution Package is in the section labeled, Windows Target Libraries for RTI Data Distribution Service. 3

Release Notes Note: Additional platforms not listed in this document may be supported through special development and maintenance agreements. Contact your RTI sales representative for details. The following tables provide additional details. See the RTI Data Distribution Service User s Manual and Platform Notes for more information on compilers and linkers. Table 1.1, AIX Platforms, on page 1-5 Table 1.2, INTEGRITY Platforms, on page 1-5 Table 1.3, Linux Platforms, on page 1-5 Table 1.4, LynxOS Platforms, on page 1-7 Table 1.5, QNX Neutrino Platforms, on page 1-7 Table 1.6, Solaris Platforms, on page 1-8 Table 1.7, VxWorks Platforms, on page 1-9 Table 1.8, Windows Platforms, on page 1-10 1.2 Disk and Memory Usage Disk usage for a typical host-only installation is approximately 250 MB. Each additional architecture (host or target) requires an additional 75 MB. We recommend that you have at least 256 MB RAM installed on your host development system. The target requirements are significantly smaller and they depend on the complexity of your application and hardware architecture. 1.3 Networking Support RTI Data Distribution Service includes full support for pluggable transports. RTI Data Distribution Service applications can run over various communication media, such as UDP/IP over Ethernet, and local inter-process shared memory provided the correct "transport plug-ins" for the media are installed. By default, RTI Data Distribution Service uses the UDP/IPv4 and shared-memory transport plug-ins. The shared memory transport is not supported for VxWorks 5.4 or 5.5. The shared memory transport is not supported for Windows CE. A built-in IPv6 transport is also available (disabled by default) for these platforms: Linux: all platforms except Red Hat Linux 8.0 and 9.0 Solaris: all platforms except Solaris 2.8 Windows: all platforms except Windows CE 4

1 System Requirements Table 1.1 AIX Platforms Operating System CPU Compiler RTI Architecture Abbreviation AIX 5.3 POWER5 (32-bit mode) POWER5 (64-bit mode) IBM XLC for AIX v9.0 IBM Java 1.6 IBM XLC for AIX v9.0 IBM Java 1.6 p5aix5.3xlc9.0 p5aix5.3xlc9.0jdk 64p5AIX5.3xlc9.0 64p5AIX5.3xlc9.0jdk Table 1.2 INTEGRITY Platforms Operating System CPU IP Stack 1 RTI Architecture Abbreviation INTEGRITY 5.0.7 PPC 74XX InterNiche (GHnet1) TCP/IP stack Interpeak TCP/IP stack with multicast ppc7400inty5.0.7.mvme5100-7400 2 ppc7400inty5.0.7.mvme5100-7400-ipk INTEGRITY 5.0.8 PPC 74XX InterNiche (GHnet1) TCP/IP stack ppc7400inty5.0.7.mvme5100-7400 2 INTEGRITY 5.0.9, 5.0.10 PPC 74XX GHnet2 TCP/IP stack ppc7400inty5.0.9.mvme5100-7400- ghnet2 1. For additional supported transports, see the online documentation or contact support@rti.com. 2. INTEGRITY 5.0.7 and 5.0.8 share the same architecture (ppc7400inty5.0.7.mvme5100-7400). Table 1.3 Linux Platforms RTI Architecture Operating System CPU Compiler Abbreviation gcc 4.1.2 ppc64linux2.6gcc4.1.2 Fedora 8 (2.6 kernel) ppc64 (Cell BE) IBM Java JDK 1.4.2 ppc64linux2.6gcc4.1.2jdk gcc 3.2 i86linux2.4gcc3.2 Red Hat Linux 8.0 Pentium class (2.4 kernel) Sun Java Platform Standard i86linux2.4gcc3.2jdk Edition JDK 1.4, 1.5 and 1.6 gcc 3.2.2 i86linux2.4gcc3.2.2 1 Red Hat Linux 9.0 Pentium class (2.4 kernel) Sun Java Platform Standard i86linux2.4gcc3.2.2jdk Edition JDK 1.4, 1.5 and 1.6 5

Release Notes Table 1.3 Linux Platforms Operating System CPU Compiler RTI Architecture Abbreviation gcc 3.2.2 i86linux2.4gcc3.2.2 1 Pentium class Sun Java Platform Standard Red Hat Enterprise Edition JDK 1.4, 1.5 and 1.6 i86linux2.4gcc3.2.2jdk Linux 3.0 (2.4 kernel) gcc 3.2.3 x64linux2.4gcc3.2.3 AMD64 Sun Java Platform Standard Edition JDK 1.5 and 1.6 x64linux2.4okgcc3.2.3jdk gcc 3.4.3 i86linux2.6gcc3.4.3 Pentium class Sun Java Platform Standard Red Hat Enterprise Edition JDK 1.4, 1.5 and 1.6 i86linux2.6gcc3.4.3jdk Linux 4.0 (2.6 kernel) gcc 3.4.5 x64linux2.6gcc3.4.5 x86_64 and AMD64 Sun Java Platform Standard x64linux2.6gcc3.4.5jdk Edition JDK 1.5 and 1.6 gcc 4.1.1 i86linux2.6gcc4.1.1 Pentium class Sun Java Platform Standard Red Hat Enterprise Edition JDK 1.4, 1.5, or 1.6 i86linux2.6gcc4.1.1jdk Linux 5.0 (2.6 kernel) gcc 4.1.1 x64linux2.6gcc4.1.1 x86_64 and AMD64 Sun Java Platform Standard x64linux2.6gcc4.1.1jdk Edition JDK 1.5 or 1.6 gcc 3.4.6 i86linux2.6gcc3.4.6 Red Hat Enterprise Pentium class Linux 5.1 (2.6 kernel) Sun Java Platform Standard i86linux2.6gcc3.4.6jdk Edition JDK 1.4, 1.5, or 1.6 gcc 4.1.2 i86linux2.6gcc4.1.2 Pentium class Sun Java Platform Standard Red Hat Enterprise Edition JDK 1.4, 1.5, or 1.6 i86linux2.6gcc4.1.2jdk Linux 5.1 (2.6 kernel) gcc 4.1.2 x64linux2.6gcc4.1.2 x86_64 and AMD64 Sun Java Platform Standard x64linux2.6gcc4.1.2jdk Edition JDK 1.5 or 1.6 gcc 4.1.0 i86suse10.1gcc4.1.0 Pentium class Sun Java Platform Standard SUSE Linux Enterprise Edition JDK 1.4, 1.5, or 1.6 i86suse10.1gcc4.1.0jdk Server 10.1 (2.6 kernel) gcc 4.1.0 x64suse10.1gcc4.1.0 AMD64 Sun Java Platform Standard Edition JDK 1.5 or 1.6 x64suse10.1gcc4.1.0jdk 1. Red Hat Linux 9.0 and Red Hat Enterprise Linux 3.0 share the same RTI architecture. 6

1 System Requirements Table 1.4 LynxOS Platforms Operating System LynxOS 4.0 LynxOS 4.2 LynxOS 5.0 CPU Compiler RTI Architecture Abbreviation gcc 2.95.3 i86lynx4.0.0gcc2.95.3 Pentium class Sun Java Platform Standard Edition JDK 1.4 i86lynx4.0.0gcc2.95.3jdk gcc 3.2.2 i86lynx4.0.0gcc3.2.2 Pentium class Sun Java Platform Standard Edition JDK 1.4 i86lynx4.0.0gcc3.2.2jdk gcc 3.2.2 ppc7400lynx4.0.0gcc3.2.2 PPC 74xx (such as 7410) Sun Java Platform Standard Edition ppc7400lynx4.0.0gcc3.2.2jdk JDK 1.4 PPC 604 gcc 3.2.2 ppc750lynx4.0.0gcc3.2.2 PPC 7XX (such Sun Java Platform Standard Edition as 750) JDK 1.4 ppc750lynx4.0.0gcc3.2.2jdk Pentium class gcc 3.2.2 i86lynx4.2.0gcc3.2.2 PPC 74xx (such as 7410) gcc 3.2.2 ppc7400lynx4.2.0gcc3.2.2 PPC 604 PPC 7xx (such gcc 3.2.2 ppc750lynx4.2.0gcc3.2.2 as 750) gcc 3.4.3 ppc7400lynx5.0.0gcc3.4.3 PPC 74xx (such as 7410) Sun Java Platform Standard Edition ppc7400lynx5.0.0gcc3.4.3jdk JDK 1.4 LynxOS-SE 3.0 Pentium class gcc 3.4.3 i86lynxos_se3.0.0gcc3.4.3 Table 1.5 QNX Neutrino Platforms Operating System CPU Compiler QNX Neutrino 6.3.0 Pentium class qcc 3.3.1 Dinkum C++ qcc 3.3.1 Abridged Dinkum C++ RTI Architecture Abbreviation i86qnx6.3.0qcc_cpp i86qnx6.3.0qcc_acpp 7

Release Notes Table 1.6 Solaris Platforms Operating System CPU Compiler RTI Architecture Abbreviation sparcsol2.8cc5.2 sparcsol2.8gcc3.2 CC 5.2 Solaris 2.8 UltraSPARC gcc 3.2 Sun Java Platform Standard Edition JDK 1.4, 1.5 and 1.6 sparcsol2.8jdk gcc 3.3.2 i86sol2.9gcc3.3.2 Pentium class Sun Java Platform Standard Edition JDK 1.4, 1.5 and 1.6 i86sol2.9jdk CC 5.3 (Forte 6 update 2) sparcsol2.9cc5.3 Solaris 2.9 CC 5.4 (Forte Dev 7, Sun One Studio 7) sparcsol2.9cc5.4 UltraSPARC gcc 3.2 sparcsol2.9gcc3.2 gcc 3.3 sparcsol2.9gcc3.3 Sun Java Platform Standard Edition JDK 1.4, 1.5 and 1.6 sparcsol2.9jdk AMD64 gcc 3.4.3 x64sol2.10gcc3.4.3 Solaris 10 Pentium class UltraSPARC UltraSPARC (with native 64- bit support) Sun Java Platform Standard Edition JDK 1.5 or 1.6 gcc 3.4.4 Sun Java Platform Standard Edition JDK 1.4, 1.5 or 1.6 gcc3.4.2 Sun Java Platform Standard Edition JDK 1.4, 1.5 or 1.6 cc 5.8 gcc3.4.2 Sun Java Platform Standard Edition JDK 1.5 or 1.6 x64sol2.10jdk i86sol2.10gcc3.4.4 i86sol2.10jdk sparcsol2.10gcc3.4.2 sparcsol2.10jdk sparc64sol2.10cc5.8 sparc64sol2.10gcc3.4.2 sparc64sol2.10jdk 8

1 System Requirements Table 1.7 VxWorks Platforms Operating System VxWorks 6.0, 6.1, 6.2 CPU Compiler gcc 3.3.2 RTI Architecture Abbreviation VxWorks 5.4.2 ppc604, ppc750, ppc7400 gcc 2.96 ppc604vx5.4gcc Pentium pentiumvx5.5gcc VxWorks 5.5.1 ppc405 ppc405vx5.5gcc gcc 2.96 ppc604, ppc750, ppc7400 ppc604vx5.5gcc ppc603 ppc603vx5.5gcc For kernel modules: Pentium pentiumvx6.0gcc3.3.2 For Real Time Processes: pentiumvx6.0gcc3.3.2_rtp VxWorks 6.3, 6.4 Any Wind River PPC32 CPU with floating point hardware Pentium Any Wind River PPC32 CPU with floating point hardware gcc 3.4.4 For kernel modules: ppc604vx6.0gcc3.3.2 For Real Time Processes: ppc604vx6.0gcc3.3.2_rtp For kernel modules: pentiumvx6.3gcc3.4.4 For Real Time Processes: pentiumvx6.3gcc3.4.4_rtp For kernel modules: ppc604vx6.3gcc3.4.4 For Real Time Processes: ppc604vx6.3gcc3.4.4_rtp 9

Release Notes Table 1.7 VxWorks Platforms Operating System VxWorks 6.5 VxWorks 6.6 Pentium CPU Any Wind River PPC32 CPU with floating point hardware gcc 3.4.4 Pentium gcc 4.1.2 Any Wind River PPC32 CPU with floating point hardware Compiler gcc 4.1.2 ppc405 gcc 4.1.2 RTI Architecture Abbreviation For kernel modules: pentiumvx6.5gcc3.4.4 For Real Time Processes: pentiumvx6.5gcc3.4.4_rtp For kernel modules: ppc604vx6.5gcc3.4.4 For Real Time Processes: ppc604vx6.5gcc3.4.4_rtp For Kernel Modules: pentiumvx6.6gcc4.1.2 For Real Time Processes: pentiumvx6.6gcc4.1.2_rtp For Kernel Modules: ppc604vx6.6gcc4.1.2 For Real Time Processes: ppc604vx6.6gcc4.1.2_rtp For Kernel Modules: ppc405vx6.6gcc4.1.2 For Real Time Processes: ppc405vx6.6gcc4.1.2_rtp Table 1.8 Windows Platforms Operating System CPU Compiler or Software Development Kit RTI Architecture Windows 2000, Windows 2003, Windows Vista Windows XP Professional 1 Pentium Class Visual C++ 6.0 (Service Pack 4 or greater) Visual C++ 7.0 Visual Studio 2003 (C++ 7.1) i86win32vc60 i86win32vc70 i86win32vs2003 10

1 System Requirements Table 1.8 Windows Platforms Operating System Windows 2000, Windows 2003, Windows Vista Windows XP Professional 1 Windows 2003 x64 Edition, Windows Vista x64 Edition Windows XP Professional x64 Edition Windows CE 6.0 (target only) 4 5 Pentium Class x64 CPU armv4 Pentium Class Compiler or Software Development Kit Visual Studio 2005 (C++ 8.0) (Service Pack 1) i86win32vs2005 Visual Studio 2008 (C++ 9.0) (Service Pack 1) (not supported on Windows 2000) i86win32vs2008 Sun Java Platform Standard Edition JDK 1.4, 1.5, or 1.6 2 i86win32jdk Visual Studio 2005 (C++, C# 8.0 or 9.0) (Service Pack 1) 3 Visual Studio 2005 (C++ 8.0) (Service Pack 1) Visual Studio 2008 (C++ 9.0) (Service Pack 1) i86win32dotnet2.0 x64win64vs2005 x64win64vs2008 Sun Java Platform Standard Edition JDK 1.5 or 1.6 2 x64win64jdk Visual Studio 2005 (C++ 8.0) (Service Pack 1) RTI Architecture armv4wince6.0vs2005 i86wince6.0vs2005 1. Windows XP does not support IP_TOS unless registry changes are made. See http://support.microsoft.com/kb/ 248611, http://www.microsoft.com/technet/technetmag/issues/2007/02/cableguy/default.aspx. 2. On Windows XP: If you are using JDK 5.0 and want to use Intel s HyperThreading technology, use JDK 5.0 Update 6 (build 1.5.0_06), which includes fixes to JNI and HyperThreading. (If you must use Update 5 (build 1.5.0_05), you should disable HyperThreading.) 3. The RTI.NET assemblies are supported for both the C++/CLI and C# languages. The type support code generated by rtiddsgen is in C++/CLI; compiling the generated type support code requires Microsoft Visual C++. Calling the assembly from C# requires Microsoft Visual C#. 4. The Windows CE network stack does not support the IP_TOS socket option. 5. The Windows CE device must be connected directly to the network, not through a Windows PC using Active- Sync. RTI Data Distribution Service does not support Windows CE when used with ActiveSync 11

Release Notes 2 Compatibility RTI strives to provide a seamless upgrade path when the product is updated. When upgrading to a new version of RTI Data Distribution Service, there are 4 components to consider: Wire Protocol Compatibility (Section 2.1) API and Generated-Code Compatibility (Section 2.2) Data-Format Compatibility and Extensibility (Section 2.3) ODBC Database Compatibility (Section 2.4) 2.1 Wire Protocol Compatibility 2.1.1 General Information on RTPS (All Releases) RTI Data Distribution Service communicates over the wire using a formal Real-time Publish-Subscribe (RTPS) protocol. RTPS has been developed from the ground up with performance, interoperability and extensibility in mind. The RTPS protocol is an international standard managed by the OMG. The RTPS protocol has built-in extensibility mechanisms that enable new revisions to introduce new message types, extend the existing messages, or extend the Quality of Service settings in the product without breaking interoperability. RTPS 1.0 was introduced in 2001. The current version is 2.1. RTI plans to maintain interoperability between middleware versions based on RTPS 2.x. 2.1.2 Release-Specific Information for RTI Data Distribution Service 4.4 RTI Data Distribution Service 4.4 is compatible with 4.2 and 4.3, except as noted below. 2.1.2.1 RTPS Versions RTI Data Distribution Service 4.4 (as well as 4.2e and 4.3) supports RTPS 2.1. Earlier releases (4.2c and lower) supported RTPS 1. Because the two RTPS versions are incompatible with each other, applications built with 4.2e and higher will not interoperate with applications built using 4.2c or lower. 12

2 Compatibility 2.1.2.2 double, long long, unsigned long long or long double Wire Compatibility If your RTI Data Distribution Service 4.4 or 4.3 application s data type uses a double, long long, unsigned long long, or long double, it will not interoperate with RTI Data Distribution Service applications built with version 4.2e or lower, unless you use the - use42ealignment flag when generating code with rtiddsgen. 2.1.2.3 Sending Large Data between 4.4d and Older Releases The large data format in RTI Data Distribution Service 4.2e, 4.3, 4.4b and 4.4c is not compliant with RTPS 2.1. Large data refers to data that cannot be sent as a single packet by the transport. This issue has been resolved in RTI Data Distribution Service 4.4d. As a result, by default, large data in RTI Data Distribution Service 4.4d is not compatible with previous versions. You can achieve backward compatibility by setting the following properties to "1". dds.data_writer.protocol.use_43_large_data_format dds.data_reader.protocol.use_43_large_data_format The properties can be set per DataWriter/DataReader or per DomainParticipant. For example: <participant_qos> <property> <value> <element> <name> dds.data_writer.protocol.use_43_large_data_format </name> <value>1</value> </element> <element> <name> dds.data_reader.protocol.use_43_large_data_format </name> <value>1</value> </element> </value> </participant_qos> [RTI Bug # 12870] 13

Release Notes 2.2 API and Generated-Code Compatibility 2.2.1 General Information (All Releases) RTI Data Distribution Service uses an API that is an extension of the OMG Data Distribution Service (DDS) standard API. RTI strives to maintain API compatibility between versions, but will conform to changes in the OMG DDS standard. RTI Data Distribution Service primarily consists of a library and a set of header files. In most cases, upgrading simply requires you to recompile your source using the new header files and link the new libraries. In some cases, minor modifications to your application code might be required; any such changes are noted in this document. RTI allows you to define the data types that will used to send and receive messages. To create code for a data type, RTI Data Distribution Service includes a tool called rtiddsgen. For input, rtiddsgen takes a data-type description (in IDL format); rtiddsgen generates header files (or a class in Java) that can be used to send and receive data of the defined type. It also generates code that takes care of low-level details such as transforming the data into a machine-independent representation suitable for communication. While this is not the common case, some upgrades require you to regenerate the code produced by rtiddsgen. The regeneration process is very simple; you only need to run the new version of rtiddsgen using the original input IDL file. This process will regenerate the header and source files, which can then be compiled along with the rest of your application. 2.2.2 Release-Specific Information for RTI Data Distribution Service 4.4 double, long long and unsigned long long Code Generation If your RTI Data Distribution Service 4.4 application s data type uses a double, long long, unsigned long long, or long double, it will not be backwards compatible with RTI Data Distribution Service applications built with version 4.2e or lower, unless you use the -use42ealignment flag when generating code with rtiddsgen. Changes in rtiddsgen Code Generation The rtiddsgen-generated type-support code changed in 4.3d to facilitate some new features. If you have code that was generated using rtiddsgen 4.2e or lower, you must regenerate that code using the version of rtiddsgen provided with this release. 14

2 Compatibility Cross-language Instance Lookup when Using Keyed Data Types In RTI Data Distribution Service 4.3, keys were serialized with the incorrect byte order when using the Java and.net API, resulting in incorrect behavior in the lookup_instance() and get_key() methods when using keyed data-types to communicate between applications in these languages and other programming languages. This issue was resolved in Java in version 4.3e.rev01 and in.net in 4.4b. As a result of this change, systems using keyed data that incorporate Java applications using both 4.3e and either 4.3e.rev01 or 4.4 could experience problems in the lookup_instance() and get_key() methods, as could systems incorporating.net applications in both 4.3e or 4.4a and 4.4b. If you are affected by this limitation, please contact RTI Support. This issue does not impact systems using 4.2 and earlier versions of RTI Data Distribution Service. Tolerance for Destination-ordering by Source-timestamp Starting with release 4.4b, by default, RTI Data Distribution Service is less restrictive (compared to older releases) on the writer side with regards to timestamps between consecutive samples: if the timestamp of the current sample is less than the timestamp of the previous sample by a small tolerance amount, write() will succeed. If you are upgrading from RTI Data Distribution Service 4.4a or lower, and the application you are upgrading relied on the middleware to reject timestamps that went backwards on the writer side (that is, when a sample s timestamp was earlier than the previous sample s), there are two ways to keep the previous, more restrictive behavior: If your DestinationOrderQosPolicy s kind is BY_SOURCE_TIMESTAMP: set the new field in the DestinationOrderQosPolicy, source_timestamp_tolerance, to 0. If your DestinationOrderQosPolicy's kind is BY_RECEPTION_TIMESTAMP on the writer side, consider changing it to BY_SOURCE_TIMESTAMP instead and setting source_timestamp_tolerance to 0. However, this may not be desirable if you had a particular reason for using BY_RECEPTION_TIMESTAMP (perhaps because you did not want to match readers with BY_SOURCE_TIMESTAMP). If you need to keep the BY_RECEPTION_TIMESTAMP setting, there is no QoS setting that will give you the exact same behavior on the writer side as the previous release. 15

Release Notes Starting with release 4.4b, by default, RTI Data Distribution Service is more restrictive (compared to older releases) on the reader side with regards to source and reception timestamps of a sample if DestinationOrderQosPolicy kind is set to BY_SOURCE_TIMESTAMP: if the reception timestamp of the sample is less than the source timestamp by more than the tolerance amount, the sample will be rejected. If you are upgrading from RTI Data Distribution Service 4.4a or lower, your reader is using BY_SOURCE_TIMESTAMP, and you need the previous less restrictive behavior, set source_timestamp_tolerance to infinite on the reader side. New Location and Name for Default XML QoS Profiles File (formerly NDDS_QOS_PROFILES.xml) The default XML QoS Profiles file has been renamed and is now installed in a new directory: Old location/name: $NDDSHOME/resource/xml/NDDS_QOS_PROFILES.xml New location/name: $NDDSHOME/resource/qos_profiles_4.4d/xml/ NDDS_QOS_PROFILES.example.xml If you want to use this QoS profile, you need to set up your NDDSHOME environment variable at run time, and rename the file NDDS_QOS_PROFILES.example.xml to NDDS_QOS_PROFILES.xml (i.e., by default, even if your NDDSHOME environment variable is set, this QoS profile is not used.) See Section 15.2 in the User s Manual for details. The default value for the max_objects_per_thread field in the SystemResourceLimitsQosPolicy has been changed from 512 to 1024. Data Type with Variable Size Keys If your data type contains more than one key field and at least one of the key fields except the last one is of variable size (for example, if you use a string followed by a long as the key): RTI Data Distribution Service 4.3e, 4.4b or 4.4c DataWriters may not be compatible with RTI Data Distribution Service 4.4d DataReaders. RTI Data Distribution Service 4.3e, 4.4b or 4.4c DataReaders may not be compatible with RTI Data Distribution Service 4.4d DataWriters. 16

2 Compatibility Specifically, all samples will be received in those cases, but you may experience the following problems: Samples with the same key may be identified as different instances. (For the case in which the DataWriter uses 4.4d, this can happen only if the DataWriter s disable_inline_keyhash field (in the DataWriterProtocolQosPolicy) is true (this is not the default case). Calling lookup_instance() on the DataReader may return HANDLE_NIL even if the instance exists. Please note that you probably would have had the same problem with this kind of data type already, even if both your DataWriter and DataReader were built with 4.3e, 4.4b or 4.4c. If you are using a C/C++ or Java IDL type that belongs to this data type category in your 4.3e, 4.4b or 4.4c application, you can resolve the backwards compatibility problem by regenerating the code with version of rtiddsgen distributed with RTI Data Distribution Service 4.4d. If you are using a C/C++ or java IDL type that belongs to this data type category in this release, you should still regenerate your code even if you plan to compile all your applications with 4.4d. Otherwise, you may see the same problem. 2.3 Data-Format Compatibility and Extensibility With RTI Data Distribution Service, you can define your own data types, which will be used to communicate between applications on a network. Developers sometimes extend or modify their data types. When new fields are added, it is a common requirement that applications that use the extended types must still communicate with applications using the old types. To accomplish this, RTI provides a dynamic data API, which allows applications to define data types at runtime without code generation. Specifically, this API supports the concept of a sparse type, one for which every data sample need not contain a value for every field defined in the type. By dynamically defining a type as sparse, an application can add new fields to it later without breaking existing components that may be unable to fill in those new fields. For customers that may want to handle extensibility in a more custom way, such as with XML payloads or custom serialization and deserialization, RTI provides built-in string and opaque data types. 17

Release Notes 2.4 ODBC Database Compatibility To use the Durable Writer History and Durable Reader State features, you must install a relational database, such as Oracle TimesTen or MySQL. In principle, you can use any database that provides an ODBC driver, since ODBC is a standard. However, not all ODBC databases support the same feature set. Therefore, there is no guarantee that the persistent durability features will work with an arbitrary ODBC driver. We have tested the following drivers: Oracle TimesTen 6.0.8 MySQL ODBC 5.0.45 Performance will be better with Oracle TimesTen, because it is an in-memory database. If you choose MySQL, you will also need the MySQL ODBC 3.51 driver and UnixODBC. The Durable Writer History and Durable Reader State features have been tested with the following architectures: AIX: p5aix5.3xlc9.0, 64p5AIX5.3xlc9.0 (AIX architectures only support Oracle TimesTen) Linux: i86linux2.6gcc3.4.3, x64linux2.6gcc3.4.5, i86linux2.6gcc4.1.1 and x64linux2.6gcc4.1.1 Solaris: sparcsol2.10gcc3.4.2 and sparc64sol2.10gcc3.4.2 Windows: i86win32vs2005 and i86win32vs2008 For more information on database setup, please see the Addendum for Database Setup (RTI_DDS_GettingStarted_DatabaseAddendum.pdf). 2.5 API Compatibility Two fields in DDS_RtpsReliableWriterProtocol_t have been renamed: Old name: disable_positive_acks_decrease_sample_keep_duration_scaler New name: disable_positive_acks_decrease_sample_keep_duration_factor Old name: disable_positive_acks_increase_sample_keep_duration_scaler New name: disable_positive_acks_increase_sample_keep_duration_factor In releases prior to 4.4c, the NACK-only feature was not supported on platforms without floating-point support. Older versions of RTI Data Distribution Service will not run on these platforms because floats and doubles are used in the implementation of the 18

2 Compatibility NACK-only feature. In releases 4.4c and above, the NACK-only feature has been reimplemented to use fixed-point arithmetic and the new DDS_Long "factor" fields noted above, which replace the DDS_Double "scaler" fields. 19

Release Notes 3 What s Fixed in 4.4d 3.1 read/take_next_instance() May Return NO_DATA Error If you called read/take_next_instance() with any sample/view/read state mask, or if filtering is turned on (for example, for time-based filtering or lifespan), the previous release of RTI Data Distribution Service may have returned a NO_DATA error code even though there was data. This problem has been resolved. [RTI Bug # 12935] 3.2 Samples May be Placed in Wrong Instance when Using Variable-Size Key If the data type contains variable-size keys, it was possible for two samples with the same key value to be associated with different instances on the writer side. All samples were still received by the reader in this case, but may have been identified as the wrong instance. This problem has been resolved. [RTI Bug # 12936] 3.3 Large Data Implementation was Not Compliant with RTPS 2.1 on the Wire Previous RTI Data Distribution Service releases implementation of the data_frag RTPS submessage on the wire was not compliant with the latest RTPS specification (version 2.1). Large data (i.e., data larger than the maximum message size of the transport) is sent on the wire with a data_frag submessage. Therefore, this issue affected all the large data types. In this release, the data_frag implementation is changed to match the RTPS specificiation. As a result, by default, large data in this release is not compatible with previous releases, but will be compatible with the RTPS specification. To achieve the previous behavior so that large data is backwards compatible with previous releases, set the "dds.data_writer.protocol.use_43_large_data_format" and "dds.data_reader.protocol.use_43_large_data_format" properties to 1 in either the DataReaderQos, DataWriterQos, or the ParticipantQos. See Sending Large Data between 4.4d and Older Releases (Section 2.1.2.3). [RTI Bug # 12870] 20

3 What s Fixed in 4.4d 3.4 Reliable Writers Incorrectly Resent Large Data Without Asynchronous Publishing Enabled In the previous release, if you tried to send fragmented large data with a reliable DataWriter that did not have asynchronous publishing enabled, the write correctly failed, because sending large data reliably requires asynchronous publishing. However, if a reliable DataReader requested historical samples, the DataWriter would incorrectly resend the large data. This problem has been resolved; DataWriters will no longer resend large data if asynchronous publishing is not enabled. [RTI Bug # 12779] 3.5 Key Information Cannot be Included with DISPOSE Messages According to RTPS 2.1, a DATA message can include the serialized key in the payload. The previous release could not attach key information to dispose notifications. This behavior is now configurable using a new QoS setting called serialize_key_with_dispose in the DataWriterProtocolQosPolicy. [RTI Bug # 11835] 3.6 Inconsistent Policy Error when set_qos() Called for a Best-Effort Writer In the previous release, if you called get_qos() on a best-effort DataWriter and then tried to call set_qos() on that same DataWriter with the QoS obtained from get_qos(), you may have seen an INCONSISTENT POLICY error. This happened because get_qos() only returned QoS policies values relevant to besteffort DataWriters, but set_qos() checked for consistency among all QoS policies, including policies that only apply to reliable writers. This problem has been resolved; set_qos() now only checks for consistency among QoS settings relevant to that best-effort DataWriter. [RTI Bug # 12623] 3.7 Failure when set_qos() Called on a Disabled Writer In the previous release, calling set_qos() on a disabled DataWriter would cause a crash. This problem has been resolved. [RTI Bug # 12787] 21

Release Notes 3.8 get_qos() May Have Provided Incorrect UserDataQosPolicy for DataWriter and DataReader In the previous release, the UserDataQosPolicy retrieved when calling either the DataWriter s or DataReader s get_qos() may have been incorrect. This happened if the current default DataWriter or DataReader QoS of the respective factory (Publisher or Subscriber) had a different UserDataQosPolicy than that of the DataWriter or DataReader. The result was that the retrieved UserDataQosPolicy incorrectly had the values of the default DataWriter or DataReader QoS. This problem has been resolved. [RTI Bug # 12875] 3.9 Error When Creating ContentFilteredTopic DataReaders with Disabled Subscriber and Using Debug Libraries When using the debug libraries in the previous release, creating a DataReader with a disabled Subscriber resulted in the precondition error: PRESParticipant_getContentFilterTypeName:!precondition PRESParticipant_associateReader:!copy sequence for content filtered property data DDS_Subscriber_create_datareader_disabledI:ERROR: Failed to associate reader and content filtered topic As a result, the filter was not registered with the DataReader. The DataReader still received data, but the data was not filtered. This problem has been resolved. [RTI Bug # 12887] 3.10 Failure When Transport Property's message_size_max Set to 512 or Less In the previous release, a DataWriter or DataReader may have crashed if the message_max_size property of an in-use transport was set to 512 or less. This problem has been resolved. [RTI Bug # 12778, 12780] 3.11 Incorrect Values for DDS_LOCATOR_KIND Constants Used for Interpreting Builtin Topic Data In previous releases, the values for the DDS_LOCATOR_KINDs were defined incorrectly. These values are used to interpret the locator kind in builtin topic data. As a result, you may have incorrectly interpreted the transport kind in the builtin topic data. This problem has been resolved. [RTI Bug # 12894] 22

3 What s Fixed in 4.4d 3.12 Resources May Not be Released During Participant ID Reservation When using auto-participant ID selection, you may have seen the following log message when creating or enabling a DomainParticipant: RTINetioReceiver_removeEntryport:!goto WR NetioReceiver_Entryport The message reported a benign issue. In this release, the message will no longer be reported. [RTI Bug # 12725] 3.13 Possible Resource Leak During Participant ID Reservation When Using Multiple Instances of Same Transport In the previous release, if you had multiple instances of the same transport plugin (note that this is not a common case) and receive resource-creation succeeded for one instance but not for another, that transport-specific receive resource (e.g., a socket bound to a port or a shared memory segment) may not have been freed even if it was unused, making the resource unavailable for other participants. The log message noted in Section 3.24 may have indicated the presence of this issue. This problem has been resolved and resources are no longer leaked. [RTI Bug # 12726] 3.14 Property Sequence Set in Derived XML Failed to Overwrite Parent Sequence If you set an Entity's QoS using XML profiles, and the base profile and derived profile both set the PropertyQosPolicy, the expected behavior is for the derived Property- QosPolicy to replace that of the base. However, in the previous release, the Entity's QoS used the PropertyQosPolicy of the base profile. This problem has been resolved; the Entity's PropertyQosPolicy will match that of the derived profile. For example, using the XML seen below, the derived property sequence (enclosed in value tag) did not overwrite the parent property sequence <qos_profile name="mybaseprofile"> <participant_qos> <property> <value> <element> <name>com.rti.myproperty</name> <value>value1</value> </element> 23

Release Notes <element> <name>com.rti.myproperty2</name> <value>value2</value> </element> </value> </property> </participant_qos> </qos_profile> <qos_profile name="myderivedprofile" base_name="mybaseprofile"> <participant_qos> <property> <value> <element> <name>com.rti.myproperty</name> <value>value2</value> </element> </value> </property> </participant_qos> </qos_profile> In addition, the following error was reported for each property value defined in the derived and base sequences: DDS_PropertyQosPolicyHelper_add_property:!property. This problem has been resolved. [RTI Bug # 12789] 3.15 topic_filter XML Attribute Mistakenly Allowed in Participant, Publisher, and Subscriber QoS In the previous release, the XML parser did not report an error if a topic_filter XML attribute appeared in a participant_qos, publisher_qos, or subscriber_qos tag. For example, the following should have caused an error but did not: <participant_qos topic_filter="a*">... </participant_qos> This problem has been resolved. [RTI Bug # 12864] 24

3 What s Fixed in 4.4d 3.16 Error Caused By Using XML QoS Profile With Same Name as Its Library In the previous release, XML QoS Profiles could not have the same name as the container library. For example: <qos_library name="libraryprofile"> <qos_profile name="libraryprofile"> </qos_profile> </qos_library> If you tried to use a profile-related operation such as create_participant_with_profile(), RTI Data Distribution Service reported an error that the profile could not be found. This problem has been resolved; it is now permissible to use the same name for the profile and its library. [RTI Bug # 12879] 3.17 XML QoS Schema File had Extra Fields for DataReaderResourceLimitsQosPolicy In the previous release, the XML QoS schema file (rti_dds_qos_profiles.xsd) contained fields that should not be in the file. Specifically, the XSD file mistakenly included these fields in the DataReaderResourceLimitsQosPolicy: max_samples, max_instances, max_samples_per_instance, initial_samples, and initial_instances. This problem has been resolved. [RTI Bug # 12804] 3.18 XML QoS Schema File was Missing PropertyQosPolicy s propagate Field In the previous release, the PropertyQosPolicy s propagate field was missing in the XML QoS schema file (rti_dds_qos_profiles.xsd). This problem has been resolved. [RTI Bug # 12809] 3.19 Typedef of Typedef Conversion from IDL to XSD May Have Generated Invalid Code In the previous release, if you ran rtiddsgen with the -converttoxsd option to convert from IDL to XSD and you had a typedef of typedefs, with each typedef inside a different module, the generated code was incorrect. Example IDL content: module MyModule { 25

Release Notes typedef short MyShort; }; typedef MyModule::MyShort MyShort_2; In the previous release, rtiddsgen generated the following incorrect code from the above IDL: <xsd:simpletype name="mymodule.myshort"> <xsd:restriction base="xsd:short"> </xsd:restriction> </xsd:simpletype> <!--NOT yet implemented--> This problem has been resolved. Now rtiddsgen will generate the correct code: <xsd:simpletype name="mymodule.myshort"> <xsd:restriction base="xsd:short"> </xsd:restriction> </xsd:simpletype> <xsd:simpletype name="myshort_2"> <xsd:restriction base="tns:mymodule.myshort"> </xsd:restriction> </xsd:simpletype> [RTI Bug # 12801] 3.20 Incorrect Mapping from IDL to XSD by rtiddsgen for Valuetype baseclass In the previous release, rtiddsgen did not map IDL to XSD correctly for the Valuetype baseclass. Example IDL content: valuetype VA { public long m1; }; valuetype VB : VA { public long m2; }; In the previous release, rtiddsgen generated the following code for the above IDL: <xsd:complextype name="va">... </xsd:complextype> <!-- @valuetype true --> <!-- @typemodifier none --> <xsd:complextype name="vb"> 26

3 What s Fixed in 4.4d <xsd:complexcontent> <xsd:extension base="va">... </xsd:extension> </xsd:complexcontent> </xsd:complextype> <!-- @valuetype true --> <!-- @typemodifier none --> This problem has been resolved. Now rtiddsgen will generate the correct XSD code: <xsd:complextype name="va">... </xsd:complextype> <!-- @valuetype true --> <!-- @typemodifier none --> <xsd:complextype name="vb"> <xsd:complexcontent> <xsd:extension base="tns:va">... </xsd:extension> </xsd:complexcontent> </xsd:complextype> <!-- @valuetype true --> <!-- @typemodifier none --> [RTI Bug # 12800] 3.21 Incorrect Mapping from IDL to XSD by rtiddsgen for #include Statements In the previous release, when mapping IDL to XSD, rtiddsgen did not guard against double inclusion of IDL files and rtiddsgen may have mistakenly generated duplicate type declarations. Example IDL Files: Primitive1.idl #ifndef Primitive1 #define Primitive1 typedef short MyShort; #endif Primitive2.idl #ifndef Primitive2 #define Primitive2 #include "Primitive1.idl" 27

Release Notes typedef MyShort MyShortArray[2]; #endif Struct.idl /* type MyShort is included twice */ #include "Primitive1.idl" #include "Primitive2.idl" struct MyStruct { MyShort m1; }; In the previous release, rtiddsgen generated the following incorrect XSD code for the above IDL: <xsd:complextype name="mystruct"> <xsd:sequence> <xsd:element name="m1" minoccurs="1" maxoccurs="1" type="tns:myshortmyshort"/> </xsd:sequence> </xsd:complextype> This problem has been resolved. Now rtiddsgen will generate the following correct XSD code: <xsd:complextype name="mystruct"> <xsd:sequence> <xsd:element name="m1" minoccurs="1" maxoccurs="1" type="tns:myshort"/> </xsd:sequence> </xsd:complextype> [RTI Bug # 12802] 3.22 Operators, &, <<, >>, ~, ^ Not Supported in const Expressions when Converting IDL to XSD wtih rtiddsgen The operators, &, <<, >>, ~, ^ were not supported in const expressions when converting from IDL to XSD using rtiddsgen. This caused rtiddsgen to throw a SyntaxException when these operators were used. This problem has been resolved. [RTI Bug # 12877] 3.23 Failure when Using Strings Longer Than 254 Characters in QoS.NET APIs Only In the previous release if using a.net API, your application may have crashed if you tried to use a string longer than 254 characters in a QoS policy. For example, if you set 28

3 What s Fixed in 4.4d the DomainParticipant's QoS with a string_profile sequence (in the ProfileQosPolicy) that contained a string longer than 254 characters, your application would have crashed. This problem has been resolved. [RTI Bug # 12793] 3.24 namespace ignored by rtiddsgen C++/CLI API Only rtiddsgen generates a <typename>_get_typecode() function if C++/CLI is specified as the target language. This function was declared as "extern "C" ", so the surrounding C++ namespaces are completely ignored by the linker. This resulted in linker errors if there were multiple data types with the same name in different namespaces. This problem has been resolved; the extern C declarations have been moved in the generated code, permitting the names to be used. [RTI Bug # 12852] 3.25 Building Types in Different Dynamic Libraries on Windows In the previous release, if you had two data types, one referenced by the other, the rtiddsgen code generator did not allow the two data types to be put in different dynamic libraries on Windows out of the box, because the generated plugin methods are not exported. In this release, rtiddsgen has added the USER_DLL_EXPORT defines in the generated plugin method to allow them to be correctly exported when building dynamic library on Windows. [RTI Bug # 12833] 3.26 Compilation Warnings when IDL Generated Code with Value Types is Compiled on Windows In the previous release, you may have seen the following warning when compiling rtiddsgen-generated code containing value types with Visual Studio 2005: warning C4099: 'MyValueType' : type name first seen using 'class' now seen using 'struct' This problem has been resolved [RTI Bug # 12876] 29

Release Notes 4 What s Fixed in 4.4c This release corrects the issues listed below. 4.1 Writer-side Filtering of Resent Data Sometimes Caused Segmentation Fault In the previous release, if a DataWriter was configured with (a) writer-side filtering enabled and (b) NACK response delays set to zero (min_nack_response_delay and max_nack_response_delay in DDS_RtpsReliableWriterProtocol_t), a segmentation fault may have occurred when the DataWriter resent data. This problem has been resolved. [RTI Bug # 12672] 4.2 Reliable Communication May Have Stalled When Writer-side Filtering Enabled When a reliable DataReader requested samples from a reliable DataWriter with writerside filtering enabled, the DataWriter may not have resent all the requested samples. Specifically, the DataWriter did not resend information on the last sample it wrote if that last sample was filtered. If this happened, further communication would be stalled until an unfiltered sample was written. This problem has been resolved. [RTI Bug # 12673] 4.3 Writer-side Filtering Sent Filtered Samples on the Wire In the previous release (beginning with RTI Data Distribution Service 4.2), samples filtered by a DataWriter were still sent on the wire. Although the DataReader discarded these samples without refiltering, the bandwidth was not optimally utilized. This problem has been resolved and samples filtered on the DataWriter side are not sent on the wire. [RTI Bug # 12658] 4.4 Piggyback Heartbeats Not Disabled When heartbeats_per_max_samples Set to Zero Setting rtps_reliable_writer.heartbeats_per_max_samples (in the DataWriterProtocol QosPolicy) to zero should turn off non-repair piggyback heartbeat messages. However in the previous release, when heartbeats_per_max_samples=0, every new sample caused a piggyback HB, thus generating extra reliability traffic. This problem has been resolved. 30

4 What s Fixed in 4.4c [RTI Bug # 12687] 4.5 Problems with Asynchronous Flushing of Batched Samples When batching was enabled for a DataWriter, asynchronous flushing did not work if the batch size was set using max_data_bytes or when automatic flushing occurred because a coherent set started or ended, or because the number of samples in the batch was equal to max_samples in the ResourceLimits QosPolicy for unkeyed topics or max_samples_per_instance in ResourceLimits QosPolicy for keyed topics. This problem has been resolved. [RTI Bug # 12659] 4.6 Problems with wait_for_acknowledgements() When Using Multi-channel DataWriters When calling wait_for_acknowledgements() with a multi-channel DataWriter, the call should only wait for ACKs from active channels. In the previous release, wait_for_acknowledgements() waited for ACKs from all channels (even those for which there were no matched DataReaders to send an ACK). The call always timed out if samples were not sent over each channel. [RTI Bug # 12632] 4.7 Out-of-memory Errors After Creating/Enabling a DataWriter Crashes JVM In previous releases, certain out-of-memory errors that occurred in the Java type-handling implementation during Publisher.create_datawriter() or DataWriter.enable() could result in a JVM crash. This problem has been resolved. [RTI Bug # 12661] 4.8 Hanging Problem when Deleting a DomainParticipant on a Windows Host In the previous release, if a network interface was disconnected or disabled while the application was running, the application would hang if a DomainParticipant was deleted. This problem has been resolved. [RTI Bug # 12696] 31

Release Notes 4.9 get_<entity>_qos_from_profile() Reported an Error if profile_name or library_name parameters Were NULL The get_<entity>_qos_from_profile() operations accept a profile_name and library_name as parameters. In the previous release, these operations considered NULL values for these parameters to be an error. This problem has been resolved. If you use NULL for the profile_name and/or library_name parameters, the default profile/library will be used. [RTI Bug # 12746] 4.10 XML Parser Failed To Report Error for Missing Partition Sequence Tag In the previous release, the XML parser failed to catch the error in the following configuration: <partition> <name> A </name> </partition> The correct XML configuration is: <partition> <name> <element> A </element> </name> </partition> This problem has been resolved. The parser now checks for the <element> tag. [RTI Bug # 12731] 4.11 Problems with QoS Profile Inheritance If there were QoS defined in a derived profile but not in the base profile, RTI Data Distribution Service reported the following error: DDS_XMLQos_getBaseQos:invalid base qos: topic filters do not match DDS_XMLQos_new:!init XML QoS object RTIXMLParser_onStartTag:Parse error at line xy: Error processing tag '<entity>_qos' 32

4 What s Fixed in 4.4c For example, the following QoS profile definition was not parsed correctly. <qos_profile name="baseprofile"> <datareader_qos>... </datareader_qos> </qos_profile> <qos_profile name="derivedprofile" base_name="baseprofile"> <participant_qos>... </participant_qos> </qos_profile> The workaround consisted of defining a dummy QoS in the base profile: <qos_profile name="baseprofile"> <participant/> <!-dummy participant QoS -> <datareader_qos>... </datareader_qos> </qos_profile> <qos_profile name="derivedprofile" base_name="baseprofile"> <participant_qos>... </participant_qos> </qos_profile> This problem has been resolved in this release and the definition of the dummy QoS is no longer required. [RTI Bug # 12743] 4.12 Segmentation Fault when Using a Custom DTD with Subgroups of Children RTI Data Distribution Service uses a Document Type Definition (DTD) file to validate input XML profiles. In the previous release, using a non-default DTD that contained subgroups of anonymous children would cause a segmentation fault. (The default DTD does not contain elements with subgroups of children.) For example, using a external DTD with the following would have caused a segmentation fault: <!ELEMENT element1 (element11, element12, (element13 element14)*)> 33

Release Notes This problem did not occur when using just one main group, such as this: <!ELEMENT element1 (element11 element12 element13 element14)*> This problem has been resolved. [RTI Bug # 12697] 4.13 C# Generated Type Names Inconsistent with C, C++ & Java Type Names The generated type name for C# was inconsistent with the generated type name for C, C++ or Java. For the following IDL code, the C# type name was "MyType" while the C/C++/Java type name was "MyNamespace::MyType". module MyNamespace { struct MyType { long mvalue; }; }; As a result, a C# DataWriter using a type registered with the generated type name would not match a C/C++/Java DataReader using the same type registered with the generated name. This problem has been resolved. [RTI Bug # 12711] 4.14 Generated C# Example Code Used Incorrect Logging Value If you used the previous version of rtiddsgen to generate C# example code, the generated code would not compile because it used an incorrect logging code. It used: NDDS.LogCategory.CONFIG_LOG_CATEGORY_API and NDDS.LogVerbosity.CONFIG_LOG_VERBOSITY_STATUS_ALL This problem has been resolved. The correct code uses: NDDS.LogCategory.NDDS_CONFIG_LOG_CATEGORY_API and NDDS.LogVerbosity.NDDS_CONFIG_LOG_VERBOSITY_STATUS_ALL [RTI Bug # 12684] 34

4 What s Fixed in 4.4c 4.15 C++/CLI Code Generated for Value Types Does Not Compile If you used the previous version of rtiddsgen to generate C++/CLI code for value types, the generated code would not compile. You would have seen undeclared identifier errors at compile time such as: error C2661: 'DDS::TypePlugin<T,K,P,E>::serialize_key' : no overloaded function takes 5 arguments This problem has been resolved. [RTI Bug # 12741] 4.16 C++/CLI Code Generated with -use42ealignment Option Does Not Compile If you used the previous version of rtiddsgen to generate C++/CLI code and you used the -use42ealignment option, the generated code would not compile. You would have seen undeclared identifier errors at compile time such as: error C2065: 'serialized_encapsulation' : undeclared identifier This problem has been resolved. [RTI Bug # 12740] 4.17 NACK-only Feature Was Not Supported on Non-Floating-Point Platforms In the previous release, the NACK-only feature was not supported on platforms without floating-point support. RTI Data Distribution Service 4.3e will not run on these platforms because floats and doubles are used in the implementation of the NACK-only feature. In this release, the NACK-only feature has been reimplemented to use fixed-point arithmetic and new DDS_Long "factor" fields in DDS_RtpsReliableWriterProtocol_t noted below, which replace the DDS_Double "scaler" fields. Old name: disable_positive_acks_decrease_sample_keep_duration_scaler New name: disable_positive_acks_decrease_sample_keep_duration_factor Old name: disable_positive_acks_increase_sample_keep_duration_scaler New name: disable_positive_acks_increase_sample_keep_duration_factor [RTI Bug # 12765] 35

Release Notes 4.18 Changes in Dynamic Data Java API The dynamic data Java API has been changed to make it consistent with other languages. 4.19 Improved Performance in Dynamic Data The dynamic data implementation has been improved to optimize performance. 4.20 Serialization Error Messages When Using Builtin Types and Batching In the previous release, if you used builtin types with batching and configured the batch size using max_data_bytes, you may have seen the following serialization error message: DDS_<Builtin Type>Plugin_serialize:serialization error: sample In spite of this error message, communication still occurred. This problem has been resolved and the error message will no longer be logged. [RTI Bug # 12775] 36

5 What s Fixed in 4.4b 5 What s Fixed in 4.4b The previous release, 4.4b, corrected the issues listed below. 5.1 Asymmetric Loss of Liveliness May Have Halted Discovery In the previous release, if two participants had discovered each other and then one participant asymmetrically lost liveliness (as specified by DiscoveryConfig QosPolicy's participant_liveliness_lease_duration), the participants may have failed to fully rediscover each other, in that not all endpoints may have been discovered. This would have resulted in broken user endpoint communication. With the introduction of nack_period in DDS_RtpsReliableReaderProtocol_t and new reliability logic, this problem has been resolved. [RTI Bug # 12017] 5.2 Failure When Allocating Memory Larger Than 2GB Previously, RTI Data Distribution Service failed when allocating heap memory larger than 2 GB, possibly resulting in a system crash. An example could be the pre-allocation of DataWriter and DataReader queues with very large initial sizes. This problem has been resolved. [RTI Bug # 12015] 5.3 Endianness of Keys in Publication and Subscription Builtin Topic Data Previously, the key and participant_key fields in either DDS_PublicationBuiltinTopicData or DDS_SubscriptionBuiltinTopicData (retrieved by the DataReader s get_matched_publication_data() and get_matched_subscription_data() operations) were processed in big-endian byte-order, and consequently were incorrectly interpreted by hosts with little-endian byte order. This problem has been resolved. [RTI Bug # 12625] 5.4 Resolved Cross-language Instance-Lookup Issue When Using Keyed Data Types with.net In RTI Data Distribution Service 4.3, keys were serialized with the incorrect byte order when using the.net APIs. This caused incorrect behavior in the lookup_instance() and get_key() methods when using keyed data-types to communicate between applications in.net and other programming languages. This issue is resolved in.net in 4.4b. 37

Release Notes As a result of this change, systems using keyed data that incorporate.net applications using both 4.3e or 4.4a and 4.4b could experience problems in the lookup_instance() and get_key() methods. If you are affected by this limitation, please contact RTI Support. This issue does not impact systems using 4.2 and earlier versions of RTI Data Distribution Service. [RTI Bug # 12491] 5.5 Problems with ContentFilteredTopics when Multiple DataWriters in Same DomainParticipant In the previous release, ContentFilteredTopics did not filter correctly if a DataReader subscribed to content published by two or more DataWriters, with different filtering configurations, in the same DomainParticipant. If some DataWriters were configured to perform filtering and some were not, the DataReader may have provided samples to the application that should have been filtered, and vice versa. This problem has been resolved. [RTI Bug # 12605] 5.6 Problems with Writer-Side Content-Filtering on Serialized Data When performing writer side filtering (with ContentFilteredTopic) on a serialized data stream (such as with CORBA-compatible C++,.NET, or DynamicData), all DataReaders except the first would fail the filter test and would not receive the samples. This problem has been resolved; all filters now properly evaluate the sample. [RTI Bug # 12624] 5.7 Best-Effort DataWriter Failed When Statistics Enabled Previously, a best-effort DataWriter with statistics enabled would crash when writing to eight or more DataReaders. This problem has been resolved. [RTI Bug # 12565] 5.8 Memory Leak When Destroying WaitSets and Exclusive Areas Windows Systems Only This release corrects a memory leak in the destruction of internal constructs associated with objects such as WaitSets, GuardConditions, DomainParticipants, the DomainParticipantFactory, and potentially Publishers and Subscribers if not using the shared EA QoS setting. This problem has been resolved. 38

5 What s Fixed in 4.4b [RTI Bug # 12604] 5.9 Exception Logged for Content Filtered Topic Compile Errors During Discovery Java API Only With a Java application, if a DataReader with a ContentFilteredTopic was discovered and the application has no declaration of that DataReader s type, the ContentFilteredTopic compilation would fail and log an exception. In this release, only a warning is logged, so that the application may suppress the logged warning while still allowing exception logging. [RTI Bug # 12614] 5.10 Problems Using Profiles with XML Tag <writer_qos> In the previous release, the Publisher s set_default_datawriter_qos_with_profile() operation had no effect if the XML profile used the <writer_qos> tag (instead of <qos_profile> or <datawriter_qos>). This problem has been resolved. [RTI Bug # 12547] 5.11 Problem with topic_filter Attribute in C++, Java and.net APIs The topic_filter attribute was broken in the C++, Java and.net APIs. RTI Data Distribution Service sometimes used the wrong QoS when these operations were called: DomainParticipant::create_topic_with_profile() Publisher::create_topic_with_profile() Subscriber::create_topic_with_profile() This problem has been resolved. [RTI Bug # 12627] 5.12 QoS Profiles Not Loaded Automatically when Using NDDS_QOS_PROFILES When using the environment variable NDDS_QOS_PROFILES, QoS Profiles were not loaded automatically. Profiles were only loaded when the DomainParticipantFactory s load_profiles() operation was called. This problem has been resolved. [RTI Bug # 12628] 39

Release Notes 5.13 No Error Reported if XML File Set if URL Group Could Not be Found To provide redundancy and fault tolerance, you can specify multiple locations for a single XML document via URL groups. The syntax of a URL group is: [URL1 URL2 URL2... URLn] For example: [file:///usr/local/default_dds.xml file:///usr/local/ alternative_default_dds.xml] In the previous release, no error was reported if all of the specified XML files in the URL group could not be found. This problem has been resolved. If all files within a URL group cannot be found, RTI Data Distribution Service will log an exception specifying which file(s) could not be loaded. In addition, the operation (set_qos, load_profiles,...) that triggered the parsing process will fail with DDS_RETCODE_ERROR. [RTI Bug # 12534] 5.14 Error if Files in URL Groups Contained Same Profile In the previous release, RTI Data Distribution Service reported duplicate object error messages if URL groups included files that had some profiles in common. For example: [/usr/main_location/profiles.xml /usr/secondary_location/profiles.xml] This problem has been resolved. Only one of the elements in the URL group will be loaded by RTI Data Distribution Service, starting from the left. Parsing of the URL group will stop when after the first file is parsed successfully. [RTI Bug # 12543] 5.15 Using Spaces in Selector for Unions In the previous release, using a space as a selector in a union caused a build error. For example, the following data type definition did not work: union MyUnion switch(char) { case 'a': long my_long; case 'b': octet my_octet; case ' ': short my_short; }; 40

5 What s Fixed in 4.4b This problem has been resolved. [RTI Bug # 12560] 5.16 Could Not Generate.NET Example Code for Types inside a Module In the previous release, rtiddsgen generated invalid.net example code if the IDL had types inside a module. The generated example code would not compile. This problem has been resolved. [RTI Bug # 12611] 5.17 rtiddsping and rtiddsspy Rejected Domain IDs Over 100 The rtiddsping and rtiddsspy utilities previously only accepted domain IDs up to 100. This restrictions has been removed. You can now use domain IDs higher than 100 (there is no upper limit). [RTI Bug # 12506] 41

Release Notes 6 What s Fixed in 4.4a Release 4.4a corrected the issues listed below. 6.1 Slowdown When Sending Many Instances with Transient Local Durability and No Matching DataReaders In the previous release, if the Durability QoS policy was set to TRANSIENT_LOCAL and many instances were being sent, but there were no matching DataReaders, your publishing application may have experienced a significant slowdown while sending samples. This problem has been resolved. [RTI Bug # 11766] 6.2 Reliable Writer Failed to Send Data in Repair Messages in a Timely Manner In the previous release, reliable writers may not have responded to NACKs as expediently as the configuration allowed. Thus, a reader may have had to wait for one more Heartbeat-NACK exchange than necessary before receiving repair data. This problem has been resolved. [RTI Bug # 12448] 6.3 Multiple Keyed Topics Caused Failure in rtiddsspy In the previous release, the rtiddsspy utility crashed if it discovered multiple keyed topics. This problem has been resolved. [RTI Bug # 12475] 6.4 Resolved Cross-language Instance Lookup Issue When Using Keyed Data Types with Java In RTI Data Distribution Service 4.3, keys were serialized with the incorrect byte-order when using the Java APIs. This caused incorrect behavior in the lookup_instance() and get_key() methods when using keyed data-types to communicate between applications in Java and other programming languages. This issue was resolved in Java in version 4.3e.rev01. As a result of this change, systems using keyed data that incorporate Java applications using both 4.3e and either 4.3e.rev01 or 4.4 could experience problems in the 42

6 What s Fixed in 4.4a lookup_instance() and get_key() methods. If you are affected by this limitation, please contact RTI Support. This issue does not impact systems using 4.2 and earlier versions of RTI Data Distribution Service. [RTI Bug # 12491] 6.5 Setting Default Profile on a Publisher Mistakenly Affected Default DataWriter QoS In the previous release, setting the default profile for a Publisher also mistakenly affected the default QoS for DataWriters created by that Publisher. This behavior has been corrected. Now when you call a Publisher s set_default_profile() operation, the changes only affect the Publisher, not DataWriters created from it. [RTI Bug # 12454] 6.6 XML Parser Failed if User-specified DTD File Not Found In the previous release, if your XML configuration file specified a non-existent DTD file with the <DOCTYPE> tag, and that DTD files is not the first file, then the XML parser would crash. This problem has been resolved. If the file is not found, an error will be reported. [RTI Bug # 12485] 6.7 No Message Logged if DDS_DomainParticipantFactory_get_qos_from_profile() Failed If DDS_DomainParticipantFactory_get_qos_from_profile() could not find a profile, it failed with DDS_RETCODE_ERROR, but it did not log a message. In this release, it will also log an error message. [RTI Bug # 12480] 6.8 RTI Data Distribution Service Failure when Parsing XML Files with Errors The previous release of RTI Data Distribution Service sometimes crashed while parsing an XML file with syntactic/semantic errors. This problem has been resolved. If an error is found in the XML file, an error message will be logged which includes the line number in the XML file where the error was found. [RTI Bug # 12508] 43

Release Notes 6.9 Performance Degradation when Calling read/take with access_scope INSTANCE or ordered_access FALSE and Many Instances With the previous release, there was a performance degradation in read/take calls if there were many instances in the reader queue and the Presentation QosPolicy s access_scope was set to DDS_INSTANCE_PRESENTATION_QOS or ordered_access was FALSE. This performance degradation is fixed in this release. [RTI Bug # 11271] 6.10 Incorrect Evaluation of Nested Content Filter Expressions C/C++ APIs In the previous release when using the C/C++ API, complex SQL expressions for ContentFilteredTopics may not have been properly evaluated. Parentheses were not given a higher precedence when followed by the AND operator, and the AND operator was not given a higher precedence than the OR operator. This problem has been resolved. [RTI Bug # 12468] 6.11 Error Processing Empty Expressions in ContentFilteredTopics In the previous release, if you created a ContentFilteredTopic with an empty filter expression (that is, a pointer to a string containing only a \0 ), you may have seen a deserialization error message. In this release, empty expressions are allowed when calling create_contentfiltered_topic_with_filter() with non-builtin filters, but not when calling create_contentfiltered_topic() (used for the builtin SQL filter) or create_contentfiltered_topic_with_filter() using the builtin SQL filter or MarketData- Filter. [RTI Bug # 12464] 6.12 Receipt of Batched Data Did Not Always Trigger on_data_available() for Keyed DataReaders with ContentFilteredTopics In keyed DataReaders with ContentFilteredTopics, the callback on_data_available() was not always triggered after receiving a batch from a DataWriter. Although the callback was not called, the data could still be retrieved using the read/take APIs. This problem has been resolved. [RTI Bug # 12527] 44

7 Known Issues 7 Known Issues 7.1 Typedefs of Sequences Causes Compiler Errors An IDL file with a structure, union or valuetype called MyType cannot contain a sequence declaration with the name MyTypeSeq. For example: struct MyStruct { long mymember; }; typedef sequence<mystruct> MyStructSeq; Using the above IDL statement, the name MyStructSeq will collide with the name of the sequence automatically generated by RTI Data Distribution Service. [RTI Bug # 11949] 7.2 Estimate of Message Overhead For Large Data May Be Exceeded RTI Data Distribution Service underestimates the message overhead of samples with large data payloads (on the order of 64 KB). If not properly compensated by the transport s message_size_max property, the send operation will fail. To work around this issue, message_size_max should be sized to account for this overhead. As a rule-of-thumb, 64 KB requires an additional 1024 bytes of overhead. [RTI Bug # 11995] 7.3 Incomplete Builtin Topic Data Returned from get_matched_*_data(), get_discovered_participant_data() The get_matched_publication_data() and get_matched_subscription_data() operations currently do not retrieve the following information in the builtin topic data structures: type_code property content_filter_property (for DDS_SubscriptionBuiltinTopicData only) Information is only available in the on_data_available() callback if a reader listener is installed on the BuiltinTopicDataDataReader. 45

Release Notes Similarly, get_discovered_participant_data() does not currently retrieve the property information. [RTI Bug # 11914] 7.4 UDPv6 Transport Requires Change to NDDS_DISCOVERY_PEERS When using the UDPv6 transport, please make sure to specify a peer list that does not contain any IPv4 multicast addresses that do not have "udpv4://" in front of them. This will prevent problems when starting more than one participant using UDPv6 on a host. The default peer list contains an un-augmented peer "239.255.0.1" address which will cause this problem; therefore when using UDPv6, you must explicitly set the peer list. For example: setenv NDDS_DISCOVERY_PEERS "udpv4://localhost,udpv4:// 239.255.0.1,shmem://" or to add IPv6 loopback and an IPv6 multicast address: setenv NDDS_DISCOVERY_PEERS "udpv4://localhost,udpv4:// 239.255.0.1,shmem: //,udpv6://::1,udpv6://ff05::239.255.0.1" [RTI Bug # 11343] 7.5 Behavior When Only localhost in Peer List and accept_unknown_peers is FALSE If the accept_unknown_peers field in the Discovery QosPolicy is set to FALSE and shared memory is disabled, applications on the same node cannot communicate if only localhost is specified in the peer list. If shared memory is not enabled or shmem:// is not specified in the peer list, and you want to communicate with other applications on the same node through the loopback interface, a workaround is to put the actual node addresses or hostname in the peers list (NDDS_DISCOVERY_PEERS). [RTI Bug # 11086] 7.6 Writer-side Filtering May Cause a Deadline to be Missed If you are using a ContentFilteredTopic, and you set the Deadline QosPolicy, the deadline may be missed due to filtering by a DataWriter. [RTI Bug # 10765] 46

7 Known Issues 7.7 Participant Listeners Should Not be Destroyed after Removal Due to a thread-safety issue, the destruction of a DomainParticipantListener from an enabled DomainParticipant should be avoided even if the DomainParticipantListener has been removed from the DomainParticipant. This limitation does not affect the Java API. [RTI Bug # 9048] 7.8 Group Address Ignored for Multicast Receive on Loopback (Linux and LynxOS Systems Only) On Linux and LynxOS architectures, the implementation of multicast loopback ignores the group address when receiving messages. This causes RTI Data Distribution Service to receive all outgoing multicast traffic originating from the host for that port. Thus, if you have two participants on the same host and in the same domain, both listening for discovery traffic over multicast, they will discover each other, regardless of the multicast address to which they are listening. The correct behavior would be to receive messages only for the addresses to which the current process (not the host) is subscribed. [RTI Bug # 10584] 7.9 Disabled Interfaces on Windows Systems The creation of a DomainParticipant will fail if no interface is enabled and the Discovery- QosPolicy.multicast_receive_addresses list (specified either programmatically, or through the NDDS_DISCOVERY_PEERS file or environment variable) contains a multicast address. However, if NDDS_DISCOVERY_PEERS only contains unicast addresses, the Domain- Participant will be successfully created even if all the interfaces are disabled. The creation of a DataReader will fail if its TransportMulticastQosPolicy contains a UDPv4 or UPDv6 multicast address. 7.10 Problems Deleting DataWriters if Using Timestamp APIs and BY_SOURCE_TIMESTAMP Destination Order The following only applies when the DataWriter s DestinationOrderQosPolicy s kind is BY_SOURCE_TIMESTAMP. Calls to delete_datawriter() may fail if your application has previously used the with timestamp APIs (write_w_timestamp(), register_instance_w_timestamp(), unregister_instance_w_timestamp(), or dispose_w_timestamp()) with a timestamp that is larger than the time at which delete_datawriter() is called. 47

Release Notes As a workaround, either: or change the WriterDataLifeCycle QoS Policy so that RTI Data Distribution Service will not autodispose unregistered instances: writer_qos.writer_data_lifecycle.autodispose_unregistered_instances = DDS_BOOLEAN_FALSE; explicitly call unregister_instance_w_timestamp() for all instances modified with the *_w_timestamp() APIs before calling delete_writer(). [RTI Bug # 10853] 7.11 Do Not Set push_on_write to False for Asynchronous DataWriters When using an asynchronous DataWriter, the DataWriterProtocol QoS Policy s push_on_write must be set to TRUE. Otherwise, samples will never be sent. [RTI Bug # 11330] 7.12 Wrong Error Code After Timeout on write() from Asynchronous Publisher When using an asynchronous publisher, if write() times out, it will mistakenly return DDS_RETCODE_ERROR instead of the correct code, DDS_RETCODE_TIMEOUT. [RTI Bug # 11362] 7.13 Effect of Disabling DataWriter s Inline Keyhash on Some RTI Tools If your application has a keyed data-type and you set the DataWriterProtocolQosPolicy s disable_inline_keyhash field to TRUE (not the default), instances may not be interpreted correctly by RTI Event Processing, RTI Real-Time Connect, and RTI Recorder. Samples will be received, but may be treated by these tools as the wrong instance. 7.14 Possible Error Determining Need for Fragmentation if Transports Configured Differently If two transports have different settings for message_size_max (in NDDS_Transport_Property_t), such that fragmentation is required for one and not the other, the need for fragmentation is not correctly applied. You may see the following message: MIGGenerator_addData:serialize buffer too small 48

7 Known Issues The affect is that samples may be lost. To avoid this issue, set message_size_max to the same value in each transport. [RTI Bug # 12422] 7.15 NDDS.ConfigLogger.set_print_format() Incompatible with NDDS.ConfigLogger.set_log_delegate() If you are using NDDS.ConfigLogger.set_log_delegate() to redirect RTI Data Distribution Service log output, you cannot also change the format of logged messages with NDDS.ConfigLogger.set_print_format(). You must use NDDS.LogPrintFormat.NDDS_CONFIG_LOG_PRINT_FORMAT_DEFAULT. [RTI Bug # 12232] 7.16 Incorrect Content Filtering for Valuetypes and Sparse Types Content filters may not filter correctly if (a) the type is a valuetype or sparse type using inheritance and (b) the filters refer to members of a derived class. This issue exists for Topics using DynamicData type support. It may also affect filtering of valuetypes using the.net or C APIs, or CORBA-compatible C++ type plugins. [RTI Bug # 12606] 7.17 Microsoft does not include Debug Symbols in Visual Studio Redistributable Libraries The RTI Data Distribution Service dynamic libraries for Java and.net rely on Microsoft Visual Studio 2005 Service Pack 1 run-time libraries. These libraries are available with Microsoft Visual Studio 2005 or as part of a redistributable package independent of Visual Studio. (The redistributable package is available for download from the RTI Customer Portal.) However, while Microsoft includes debug versions of these run-time libraries with Visual Studio, it only includes release versions in the redistributable package. This limitation means that if you do not have Visual Studio 2005 installed, you cannot use the RTI debug libraries; you must use the RTI release libraries. If you attempt to use the RTI debug libraries, and your system does not have debug versions of the Microsoft runtime libraries available, your application will fail to start up properly. If you start it from a command shell, you will see an error about a failure to load the dynamic libraries. Fortunately, you do not need to use the RTI debug libraries to debug your own code. If you experience library loading problems when your Java or.net application starts up in debug mode, modify your application project files to use the release versions of the 49

Release Notes RTI libraries. Alternatively, you can obtain a no-cost version of Visual Studio 2005 directly from Microsoft, which will contain the necessary debug libraries. [RTI Bug # 12944] 7.18 Issues with Dynamic Data Types The DynamicData operations clear_member() and clear_nonkey_members() are only supported for sparse data types. For non-sparse types, you must use clear_all_members() to remove members from a data structure. [RTI Bug # 12637] Data types containing bitfield members are not supported by DynamicData. [RTI Bug # 12638] The DynamicData print() operation may not display any data for members at the end of a data structure that have not been explicitly set before the data sample is serialized. This will not be a problem on a received data sample, which should always correctly display all members. [RTI Bug # 12641] The conversion of data by member access primitives (get_x() operations) is limited for the case of converting to types that are not supported on all platforms. This limitation applies when converting to 64-bit long long types (get_longlong() and get_ulonglong() operations) and 128-bit long double type (get_longdouble()). These methods will always work for data members that are actually of the correct type, but will only support conversion from values that are stored as smaller types on a subset of platforms. Conversion to 64-bit long longs from a 32-bit or smaller integer type is supported on all Windows, Solaris, and Linux architectures, and any additional 64-bit architectures. Conversion to 128- bit long doubles from a float or double is only supported on Solaris SPARC architectures. [RTI Bug # 12647] DynamicData cannot handle a union with a discriminator that is set to a value which is not defined in the type. [RTI Bug # 12855] 50

7 Known Issues DynamicData may have problems resizing variable-size members that are >= 64k in size. In this case, the method (set_x() or unbind_complex_member()) will fail with the error: "sparsely stored member exceeds 65535 bytes." Note that it is not possible for a member of a sparse type to be >= 64k. [RTI Bug # 12897] DynamicData_print() will fail if an enum member is found with an ordinal value that does not exist in the type definition. The failure is reported with this message: DDS_DynamicDataStream_print_primitive_member: typecode error 7 on member_name [RTI Bug # 12912] Dynamic data member info may return an element kind of TK_ALIAS get_member_info() and get_member_info_by_index() may return a data type element kind of TK_ALIAS if there is a typedef in the type. Specifically, this may be an issue if the type is an array, or sequence of a type that is defined as a typedef. In these cases, standard array/sequence access members will work but the element kind will have to be deduced directly from the type of the member. To workaround this problem, if TK_ALIAS is seen in the return member info, do the following: Call get_member_type() for the member ID and/or name requested. Call TypeCode_content_type() to get the contained element type. Get the TypeCode_kind of the content type. While this kind is TK_ALIAS: Get the TypeCode_content_type to resolve the alias. Check the kind again. [RTI Bug # 12913] Objects allocated via the DynamicDataTypeSupport::create_data() method will be created with a buffer exactly large enough to hold the largest possible object received on the wire. However, when constructing a data object member by member using set_x operations, it is possible to require a buffer larger than this size. To ensure that all use cases will be properly supported, allocate a Dynamic- Data object by itself with properties that allow for growth as needed (set buffer_max_size to a large value such as 0x40000000L). The method Dynamic- 51

Release Notes DataTypeSupport::get_data_type() can be used to retrieve the correct type. Or, if a set_x operation fails with DDS_RETCODE_OUT_OF_MEMORY, you can try to call the compact() operation on the dynamic data object. TypeCode Error Message when Using Unions with Default Discriminators When accessing data of types that contain union members with a default discriminator case defined, you may see the following error message: DDS_TypeCode_get_type_serialized_min_size:typecode error 7 on member_type This can occur when writing to a sample of this type (specifically, a member after the union), or when calling get_key_value() on the reader or writer. If no other errors are report after this and all operations return successfully, you can consider the message benign. [RTI Bug # 12929] Dynamic data may fail to properly access a sample with an array or sequence of strings if there is a string of maximum length. It will also fail to properly access any data members following the string array/seq. For example, consider this type: struct Foo { long x; string<10> arrstr[2]; long y; }; If either member of arrstr is set to a string of length 10 (e.g., "TestString"), then calling bind/get_complex_member() on arrstr may return an empty or truncated data structure. There may also be problems setting or getting the value of y. Note that printing the value of the sample with DynamicData::print() or serializing the value of the sample will work properly. [RTI Bug # 12940] 7.19 Issues with INTEGRITY Systems 7.19.1 Ungraceful Shutdown When Using C++ and Dynamic System Libraries on INTEGRITY 5.0.7 Systems Due to an issue with the INTEGRITY 5.0.7 tool chain, C++ applications that are linked against shared system libraries and include stdio.h may encounter an exception at shutdown. 52

7 Known Issues The suggested workaround from Green Hills is to link against the static versions of the system libraries. In the case of the rtiddsgen-generated INTEGRITY project files, you may do so by following these steps: 1. Add the following line to your top-level project file, <IDL filename>_default.gpj: -non_shared 2. Remove all the shared objects from the three.int files in your project (<IDL file name>_publisherdd.int, <IDLfilename>_subscriberdd.int, posix_shm_manager.int) by removing the following lines: Library libintegrity.so Library libc.so Library libscxx.so 3. Rebuild your top-level project, <IDL file name>_default.gpj. 7.19.2 Delay When Writing to Unreachable Peers On INTEGRITY systems, if a publishing application s initial peers list includes a nonexistent (or simply unreachable) host, calls to write() may block for approximately 1 second. This long block is caused by the stack trying to resolve the invalid/unreachable host. Most IP stacks do not block the sending thread because of this reason, and you may include invalid/unreachable hosts in your initial-peers list. If you find that your stack does block the sending thread, please consult your IP stack vendor on how to change its behavior. [RTI Bug # 10768] 7.19.3 Linking with libivfs.a without a File System If you link your application with "libivfs.a" and are using a system that does not have a file system, you may notice the application hang for 2 seconds at start-up. 7.19.4 Compiler Warnings Regarding Unrecognized #pragma Directives Building RTI Data Distribution Service projects for INTEGRITY causes the compiler to produce several warnings about #pragma directives not recognized in some RTI Data Distribution Service header files. For example: Building default.bld "C:/ndds/ndds.4.4x/include/ndds/dds_c/dds_c_infrastructure.h", line 926: 53

Release Notes warning: unrecognized #pragma #pragma warning(push) ^ "C:/ndds/ndds.4.4x/include/ndds/dds_c/dds_c_infrastructure.h", line 927: warning: unrecognized #pragma #pragma warning(disable:4190) ^ "C:/ndds/ndds.4.4x/include/ndds/dds_c/dds_c_infrastructure.h", line 945: warning: unrecognized #pragma #pragma warning(pop) ^ These warnings do not compromise the final application produced and can be safely ignored. 7.19.5 Warning when Loading RTI Data Distribution Service Applications on Integrity 5.0.x Systems When an RTI Data Distribution Service application compiled with the rtiddsgen-generated project files is loaded on an INTEGRITY 5.0.x target, the following warning appears: "Warning: Program is linked with libc.so POSIX signals and cancellation will not work." The RTI Data Distribution Service libraries do not use the additional features provided by the full POSIX implementation, therefore the warning can safely be ignored. This warning is due to the fact that the rtiddsgen-generated project files use the Single AddressSpace POSIX library by default, not the full POSIX implementation on INTEG- RITY (POSIX System). The RTI Data Distribution Service libraries only require Single AddressSpace POSIX to function correctly, but will still work if you are using the POSIX System. The warning message indicates that items such as inter-process signaling or processshared semaphores will not be available (more information can be found in the INTEG- RITY Libraries and Utilities User's Guide, chapter "Introduction to POSIX on INTEG- RITY"). 54