DDSIRTP21 — The specification does not state how to generate unique GUIDs

In RTPS each entity has a so-called GUID_t. It consists of a 12 Byte GuidPrefix_and a 4-Byte EntityId_t and must be globally unique. In heterogeneous systems (with multiple RTPS implementations), the specification provides no mechanism or guidance to ensure global uniqueness.

A solution would be to make the vendorId part of the GuidPrefix_t.

Resolution:
The first two bytes of the GUID_t prefix should be the vendor id.

The first two bytes of the GUID_t prefix should be the vendor id, the rest can be
chosen by the vendors as they see fit, as long as they ensure uniqueness.
This approach avoids collisions between vendors, but has the drawback that it limits
the range of available GUID prefixes for each vendor. But as we can see below, this
limitation should not cause a problem as the remaining 10 Bytes are sufficient to
generate unique GUIDs even in very large DDS domains.
The GUID_t prefix is 12 bytes, after 2 are used for the vendor there remain only 10
bytes that can be used to generate unique DDS Entity GUIDs, this means there can
be S = 2^80 different GUID prefixes.
GUID prefixes are assigned in one-to-one correspondence with DDS
DomainParticipants as all the DDS Entities within a participant share the same GUID
Prefix.
Assume that a particular DDS domain has ‘n’ DDS participants, if a good algorithm is
used to generate GUID prefixes, the probability of a collision P (i.e. two or more
entities having the same GUID) can be approximated as: P ~ 1 – exp(-(n^2)/(2*S))
In a very large system with 1 Million DDS Participants the probability of a collision
would be extremely small: 4e-13
In a system with 1 Billion (10^9) DDS Participants the probability of a collision would
be 4e-7 also very small.
Therefore the solution requiring the first 2 bytes of the GUID_t Prefix to match the
vendorId will not prevent the generation of unique GUID prefixes.