First we need to distinguish between the (Apache license 2 based) open-source Community Edition (CE) and the commercially supported version of Vortex OpenSplice; The  Community-edition only includes our DDSI implementation (implementing the OMG-DDSI rev2.2 specification)  i.e. that assures interoperability with other DDS-vendors based on the standardized OMG-DDSI (also called ‘RTPS’) protocol.   The DDSI protocol is based on dynamic discovery of DDS entities (participants a and reader/writer endpoints) in your system.

Our commercially-supported Vortex OpenSplice edition also has that same DDSI service but alternatively also supports what we call our ‘native’ RTNetworking service where ‘native‘ implies that its not an open-standard but it has some properties that especially in large-scale systems can be important.  The main difference is that  in DDSI there’s explicit discovery of endpoints (which generate discovery-traffic), in RTNetworking,  the communication is more ‘push’ oriented where we push published information over preconfigured so-called ‘networkPartitions‘ (an association between a logical DDS topic/partition expression and a physical multicast-group) and where we also perform time-triggered transfers (driven by the DDS latency-budget QoS)  over multiple ‘priority-lanes‘ (selected by the DDS transport-priority QoS).

So our RTNetworking doesn’t incur the discovery-overhead (so scales better in use-cases where you have thousands of participants on the network), whereas DDSI is an interoperable protocol where based on discovered ‘endpoints’ we can dynamically switch between using unicast or multicast (both also ‘reliable’ of course when required).

Our commercial offering also includes a ‘Enhanced’ DDSI service, called DDSI2E where the concepts of ‘networking-partitions’ and ‘priority-lanes‘ have been incorporated in the DDSI-protocol (without loosing interoperability), which makes the decisive factor between DDSI/RTNetworking the interoperability with other Vendors (in which case you need one of our DDSI services) and/or the tolerance for the discovery-traffic overhead (if too many endpoints in the system, you might consider using RTNetworking instead)

Finally, both DDSI and RTNetworking services also allow to configure endpoints statically and for our DDSI services, we also support TCP (with optional TLS-based encryption) in addition to UDP multicast and/or unicast)