RTI Data Distribution Service

Transcription

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

2 2009 Real-Time Innovations, Inc. All rights reserved. Printed in U.S.A. First printing. May 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 Phone: (408) support@rti.com Website:

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

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

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

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

7 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 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 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 sending an request to sales@rti.com, or calling +1 (408)

8 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 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, 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

9 1 System Requirements Visual Studio 2005 Service Pack 1 Requirement You must have Visual Studio 2005 Service Pack 1 or the Microsoft Visual C 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 SP1 Redistribution Package can be downloaded from RTI s Self Service Portal 1, or obtained from the following Microsoft website: For x86 architectures: familyid=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en For x64 architectures: familyid=eb4ebe2d-33c0-4a47-9dd4-b9a6d7bd44da&displaylang=en Visual Studio Service Pack 1 Requirement You must have Visual Studio 2008 Service Pack 1 or the Microsoft Visual C 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 SP1 Redistribution Package can be downloaded from RTI's Self Service Portal 1, or obtained from the following Microsoft website: For x86 architectures: On the portal, select the Downloads page. The Redistribution Package is in the section labeled, Windows Target Libraries for RTI Data Distribution Service. 3

10 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 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

11 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 PPC 74XX InterNiche (GHnet1) TCP/IP stack Interpeak TCP/IP stack with multicast ppc7400inty5.0.7.mvme ppc7400inty5.0.7.mvme ipk INTEGRITY PPC 74XX InterNiche (GHnet1) TCP/IP stack ppc7400inty5.0.7.mvme INTEGRITY 5.0.9, PPC 74XX GHnet2 TCP/IP stack ppc7400inty5.0.9.mvme ghnet2 1. For additional supported transports, see the online documentation or contact support@rti.com. 2. INTEGRITY and share the same architecture (ppc7400inty5.0.7.mvme ). Table 1.3 Linux Platforms RTI Architecture Operating System CPU Compiler Abbreviation gcc ppc64linux2.6gcc4.1.2 Fedora 8 (2.6 kernel) ppc64 (Cell BE) IBM Java JDK 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 i86linux2.4gcc 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

12 Release Notes Table 1.3 Linux Platforms Operating System CPU Compiler RTI Architecture Abbreviation gcc i86linux2.4gcc 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 x64linux2.4gcc3.2.3 AMD64 Sun Java Platform Standard Edition JDK 1.5 and 1.6 x64linux2.4okgcc3.2.3jdk gcc 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 x64linux2.6gcc3.4.5 x86_64 and AMD64 Sun Java Platform Standard x64linux2.6gcc3.4.5jdk Edition JDK 1.5 and 1.6 gcc 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 x64linux2.6gcc4.1.1 x86_64 and AMD64 Sun Java Platform Standard x64linux2.6gcc4.1.1jdk Edition JDK 1.5 or 1.6 gcc 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 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 x64linux2.6gcc4.1.2 x86_64 and AMD64 Sun Java Platform Standard x64linux2.6gcc4.1.2jdk Edition JDK 1.5 or 1.6 gcc 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 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

13 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 i86lynx4.0.0gcc Pentium class Sun Java Platform Standard Edition JDK 1.4 i86lynx4.0.0gcc2.95.3jdk gcc i86lynx4.0.0gcc3.2.2 Pentium class Sun Java Platform Standard Edition JDK 1.4 i86lynx4.0.0gcc3.2.2jdk gcc 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 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 i86lynx4.2.0gcc3.2.2 PPC 74xx (such as 7410) gcc ppc7400lynx4.2.0gcc3.2.2 PPC 604 PPC 7xx (such gcc ppc750lynx4.2.0gcc3.2.2 as 750) gcc 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 i86lynxos_se3.0.0gcc3.4.3 Table 1.5 QNX Neutrino Platforms Operating System CPU Compiler QNX Neutrino Pentium class qcc Dinkum C++ qcc Abridged Dinkum C++ RTI Architecture Abbreviation i86qnx6.3.0qcc_cpp i86qnx6.3.0qcc_acpp 7

14 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 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 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 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

15 1 System Requirements Table 1.7 VxWorks Platforms Operating System VxWorks 6.0, 6.1, 6.2 CPU Compiler gcc RTI Architecture Abbreviation VxWorks ppc604, ppc750, ppc7400 gcc 2.96 ppc604vx5.4gcc Pentium pentiumvx5.5gcc VxWorks 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 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

16 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 Pentium gcc Any Wind River PPC32 CPU with floating point hardware Compiler gcc ppc405 gcc 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 (Service Pack 4 or greater) Visual C Visual Studio 2003 (C++ 7.1) i86win32vc60 i86win32vc70 i86win32vs

17 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 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 x64win64jdk Visual Studio 2005 (C++ 8.0) (Service Pack 1) RTI Architecture armv4wince6.0vs2005 i86wince6.0vs Windows XP does not support IP_TOS unless registry changes are made. See , 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

18 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 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 The current version is 2.1. RTI plans to maintain interoperability between middleware versions based on RTPS 2.x 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 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

19 2 Compatibility 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 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

20 Release Notes 2.2 API and Generated-Code Compatibility 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 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

21 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

22 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 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

23 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

24 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 MySQL ODBC 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

25 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

26 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 ). [RTI Bug # 12870] 20

27 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

28 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

29 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

30 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

31 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

32 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> true --> none --> <xsd:complextype name="vb"> 26