I am evaluating microDDS and am looking for a description of some of the micro DDS unique API's used in some of the examples provided with micro DDS. These APIs are not described in the "RTI Connext Micro API and QoS Guide". Specifically, in the HelloWorld_dpde example:
1. Configuration of the registry via RT_Registry_register() for strings "wh", "rh", "_udp" and "dpde" strings. What is the purpose of this function call and what is the signficance of the strings?
2. DPDE_DiscoveryPluginProperty(), RHSM_HistoryFactory_get_interface(), UDP_InterfaceFactory_get_interface() not documented.
3. How is the UDP_InterfaceFactoryProperty and associated functions used to enable the udp interface?
4. The above referenced spec does not document all supported QoS policies. For example, the HelloWorld_dpde example sets a number of resource limits (i.e. dp_qos.resource_limits.max_destination_ports) not covered in the spec. Do we need to assume that all fields defined in the QoS structs in the micro DDS header files are used?
5. Is the schema for QoS XML file the same for standard connext DDS and micro DDS? If not, is there a schema for micro DDS QoS. I am aware that the micro DDS API does not support profiles, but would still like to use XML file to document QoS for micro DDS.
Thanks.
Mark.
Hi Mark,
Connext Micro has been designed with a "component" interface for enabling architectural flexibility. Each component provides unique and necessary functionality (e.g. DDS queues, transports, DDS discovery).
1. A Micro application usually begins with registering and configuring components (with RT_Registry_register) necessary for the application. These include a writer history (wh) queue, a reader history (rh) queue, a UDP transport (_udp), and a dynamic-participant dynamic-endpoint (dpde) discovery component. The strings are names assigned to the registered components. They can be arbitrarily chosen for registration (with the current limitation that wh, rh, and _udp must be the names used for their respective components). Unregistration of components, which is necessary upon application shutdown, must use the registered names. _udp is the specific name of the built-in UDP transport, and that in the HelloWorld example is first unregistered before configuring the allow_interface property, and then re-registered.
2. These and other Micro-specific, non-DDS-standard APIs are being documented for a future release of Micro. The *Factory_get_interface() functions each get a component factory that will be used to create a component instance when necessary (e.g. DDS_Publisher_create_datawriter() will need an instance of a writer history queue, thus creating a "wh" instance).
3. The property sets the UDP-related configuration for DDS Entities that will be communicating over the UDP transport. For example, each DataWriter subsequently created by DDS_Publisher_create_datawriter() will be configured to use the UDP transport, sending its data on the interfaces in the allow_interface sequence, restricting its payloads to be no more than max_message_size, and configuring its socket send buffers to be max_send_buffer_size.
4. Like the undocumented APIs of 2, these QoS and properties are being documented for a future release. For now, do assume all fields are used.
5. No schema is available for Micro QoS.
Regards,
Edward