Why doesn't my RTI Connext application communicate with an RTI Connext application installed as a Windows Service?

Note: Applies to RTI Connext 4.x and above.

An RTI Connext application installed as a Windows Service application (formerly known as an NT service) will not communicate over shared memory with a DDS application that is not installed as a Windows Service.

This is due to the namespace used to create the shared memory segments. On Windows 2003, Windows Vista, Windows 2008 Server, and Windows 7 systems, the shared-memory objects that are created need to be in the global namespace since the Windows Service application and the regular (non-Windows Service) application run under different logins.

If you need to run in this configuration, as a workaround we recommend disabling shared memory in both applications (the regular application and the Windows Service application). To do so, make the following changes in both the publishing and subscribing applications: 

   1. Get the default DomainParticipant QoS.

   2. Modify the QoS so that only UDPv4 is used (remove shared memory).

   3. Used the modified QoS to create the DomainParticipant.

The modified code will look similar to the following C++ code snippet:

DDS_DomainParticipantQos participant_qos;

factory->get_default_participant_qos(participant_qos);

//Only enable UDPV4 transport
participant_qos.transport_builtin.mask = DDS_TRANSPORTBUILTIN_UDPv4; 

//Remove Shared Memory from default peers.
participant_qos.discovery.initial_peers.length(2);
participant_qos.discovery.initial_peers[0] =
	DDS_String_dup("builtin.udpv4://127.0.0.1");
participant_qos.discovery.initial_peers[1] =
	DDS_String_dup("builtin.udpv4://239.225.0.1");

participant = DDSTheParticipantFactory->create_participant(
	domainId, participant_qos, 
	NULL /* listener */, 
	DDS_STATUS_MASK_NONE);

Alternatively, using XML QoS:

<participant_qos>
  <transport_builtin>
    <mask>UDPv4</mask>
  </transport_builtin>
  <discovery>
    <initial_peers>
      <element>builtin.udpv4:/127.0.0.1</element>
      <element>builtin.udpv4:/239.225.0.1</element>
    </initial_peers>
  </discovery>
</participant_qos> 

Attached Examples

Two examples are attached to this solution: HelloServiceSubCpp.zip and HelloServicePubDotNet.zip. These examples were built using Visual Studio 10 Professional and tested on Windows 2008 Server and Windows 7.

• HelloServiceSubCpp.zip—This example is written in C++ and implements a Subscriber in a Windows Service. This example includes a Publisher for testing purposes.
• HelloServicePubDotNet.zip—This example is written in .Net/C# and implements a Publisher in a Windows Service. This example includes a Subscriber for testing purposes.

For both examples, extract the zip file and open the solution file in Visual Studio 10 to build. For more information on creating and installing a Windows Service Application, please reference the following Microsoft webpage: http://msdn.microsoft.com/en-us/library/d56de412(v=VS.100).aspx

How to Verify that Your Windows Service Application is Running

One way to verify that your Windows Service application is running is by using the rtiddsspy tool that is provided with RTI Connext. For rtiddsspy to discover your entity, you need to use the -transport option as follows:

rtiddsspy -domainId 0 -transport 1

Set the domainId to match the domain that your Windows Service application is using. Using '1' for the transport option disables shared memory and enables the built-in UDPv4 transport. 

When rtiddsspy discovers your DataReader or DataWriter, you will see output similar to the following, which indicates that a new DataReader "R" has been discovered:

source_timestamp  Info Src HostId  topic              type 
----------------- ---- ----------- ------------------ ------------------ 
1306253926.786989 R +N 0A0A4628    Example HelloWorld HelloWorld