The information that is kept in the ‘Global Data Space’ can be divided into application-data (the samples of topics that are published/subscribed by applications) and meta-data (the standardized so-called ‘built-in topics‘ that describe which DDS-entities are active in the system i.e. the set of active participants, publishers, subscribers, readers and writers).

Where information gets stored depends on several factors, such as the ‘durability‘ of the data i.e. whether data is volatile or not. Volatile data is delivered from writers to readers and is kept in a dataReader’s history until its taken out explicitly or cleaned-up by the middleware if so configured. Non-volatile data can be transient-local (in which case its kept in the writer’s history to be available for late-joiners in the system), transient (in which case its maintained by one or more ‘durability services’ memory that decouple its lifecycle from the publishing application’s lifecycle) or persistent (in which case a durability-service will actually persist the data on non-volatile memory such as a disk so that this persistent-data outlives the system-downtime).

So the logical Global Data Space (GDS) is physically implemented in a distributed way that prevents the need for centralized components/brokers