OpenDDS FAQ

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

A:

The odds of getting questions answered, bugs fixed, etc., goes up significantly when you report problems using the PRF because it insures that developers and support personnel get the most commonly required information right away. Failure to use the PRF means that those folks have to spend valuable time (yours and theirs) having a conversation to get that information just to start debugging. Unless you've got a paid support contract, there's even a chance that nobody will answer!

So, always use the PRF!

Q:

A:

Q:

A:

Q:

A:

Q:

A:

Q:

A:

1. The participant contacts the InfoRepo over IIOP (CORBA). The endpoint used for this connection can be supplied as:

      -DCPSInfoRepo corbaloc:iiop:HOST:PORT/DCPSInfoRepo

   (or a similar setting in the .ini file)
   The HOST is obviously the host where the InfoRepo is running. The PORT for the InfoRepo can be controlled by passing an argument to the InfoRepo process:

      -ORBListenEndpoints iiop://:PORT

   Another option that's useful for port-forwarding solutions such as NAT traversal and SSH tunneling is hostname_in_ior. This gets appended to the endpoint like so

      -ORBListenEndpoints iiop://:PORT/hostname_in_ior=HOST_ALIAS

   Where HOST_ALIAS is a hostname (or dotted-decimal IP) that can be used by the client to contact the server. In the NAT traversal example, the HOST_ALIAS would be the external side of the NAT and the PORT would be the port that's forwarded to the host running the server.
   You can also specify more than one endpoint (just repeating the -ORBListenEndpoints will work) so you can provide endpoints that will work for both "inside" and "outside" clients.

2. The InfoRepo will make an IIOP connection *back* to the participant. This is just the inverse of connection #1, but there is no equivalent to the -DCPSInfoRepo corbaloc:... option. It's not necessary because the InfoRepo knows how to find the participant already (from data transmitted over connection #1). To control the endpoint here, use the same -ORBListenEndpoints ... option but this time with the participant and not the InfoRepo.

3. Once the publishing participant and the subscribing participant have been associated, they connect directly using the SimpleTCP transport instance in each one. Here the endpoint is determined by the subscriber's transport config (the "local_address" value). Unfortunately there is no equivalent to the hostname_in_ior for DDS transports.

Q:

A:

Q:

A:

  e.g. $(ACE_ROOT)\bin\tao_idl -Gdcps -I$(DDS_ROOT) Messenger.idl

Q:

A:

We have seen gcc 4.0.x-series compiler users to hit this problem more often. The visibility feature in this compiler still seems to be in a state of flux. We therefore recommend turning it off by adding "no_hidden_visibility=1" to your platform_macros.GNU file.

Q:

A:

On a related note the DCPSInfoRepo uses the SimpleTcp transport solely to transmit BIT (Built In Topics) information. If your application isn't subscribing to BITS, then the InfoRepo doesn't need the transport library. Just start up the InfoRepo with the -NOBITS option and you will be OK.

Q:

A:

Q:

A:

    ::DDS::InstanceHandleSeq handles;
    while (1)
    {
      writer_->get_matched_subscriptions(handles);
      if (handles.length() > 0)
        break;
      else
        ACE_OS::sleep(ACE_Time_Value(0,200000));
    }

Q:

A:

Q:

A:

BIT associates are created via TCP and therefore require support of the SimpleTcp transport library. When using BITs make sure the SimpleTcp transport has been properly configured in both the InfoRepo as well as the participants.

Q:

A:

     mwc.pl -type <yourtype> -features built_in_topics=0 DDS.mwc

Q:

A:

The DCPSInfoRepo option -NOBITS disables BIT support for the InfoRepo.

The option '-DCPSBit 0' will disable BIT support for all participants in the process.