{
    "history":
    {
      "description": "This QoS Policy controls the behavior of the system when the value of an instance changes one or more times before it can be successfully communicated to the existing DataReader entities. \n - kind: Controls if the service should deliver only the most recent values, all the intermediate values or do something in between. \n\t - KEEP_LAST: The service will only attempt to keep the most recent values of the instance and discard the older ones. \n\t - KEEP_ALL: The service will attempt to keep all the values of the instance until it can be delivered to all the existing Subscribers. \n - depth: Establishes the maximum number of samples that must be kept on the history. It only has effect if the kind is set to KEEP_LAST."
    },
    "reliability":
    {
      "description": "This QoS Policy indicates the level of reliability offered and requested by the service.\n - kind: Specifies the behavior of the service regarding delivery of the samples. \n\t - BEST_EFFORT: It indicates that it is acceptable not to retransmit the missing samples, so the messages are sent without waiting for an arrival confirmation. Presumably new values for the samples are generated often enough that it is not necessary to re-send any sample. However, the data samples sent by the same DataWriter will be stored in the DataReader history in the same order they occur. In other words, even if the DataReader misses some data samples, an older value will never overwrite a newer value. \n\t - RELIABLE: It indicates that the service will attempt to deliver all samples of the DataWriter’s history expecting an arrival confirmation from the DataReader. The data samples sent by the same DataWriter cannot be made available to the DataReader if there are previous samples that have not been received yet. The service will retransmit the lost data samples in order to reconstruct a correct snapshot of the DataWriter history before it is accessible by the DataReader."
    },
    "durability":
    {
      "description": "A DataWriter can send messages throughout a Topic even if there are no DataReaders on the network. Moreover, a DataReader that joins to the Topic after some data has been written could be interested in accessing that information. \n The DurabilityQoSPolicy defines how the system will behave regarding those samples that existed on the Topic before the DataReader joins. The behavior of the system depends on the value of the DurabilityQosPolicyKind. \n - VOLATILE: Past samples are ignored and a joining DataReader receives samples generated after the moment it matches. \n - TRANSIENT_LOCAL: When a new DataReader joins, its History is filled with past samples."
    },
    "deadline":
    {
      "description": "This QoS policy raises an alarm when the frequency of new samples falls below a certain threshold. It is useful for cases where data is expected to be updated periodically. \n On the publishing side, the deadline defines the maximum period in which the application is expected to supply a new sample. On the subscribing side, it defines the maximum period in which new samples should be received. \n For Topics with keys, this QoS is applied by key. Suppose that the positions of some vehicles have to be published periodically. In that case, it is possible to set the ID of the vehicle as the key of the data type and the deadline QoS to the desired publication period."
    },
    "lifespan":
    {
      "description": "Each data sample written by a DataWriter has an associated expiration time beyond which the data is removed from the DataWriter and DataReader history as well as from the transient and persistent information caches. \n By default, the duration is infinite, which means that there is not a maximum duration for the validity of the samples written by the DataWriter. \n The expiration time is computed by adding the duration to the source timestamp, which can be calculated automatically if write() member function is called or supplied by the application by means of write_w_timestamp() member function. The DataReader is allowed to use the reception timestamp instead of the source timestamp."
    },
    "liveliness":
    {
      "description": "This QoS Policy controls the mechanism used by the service to ensure that a particular entity on the network is still alive. There are different settings that allow distinguishing between applications where data is updated periodically and applications where data is changed sporadically. It also allows customizing the application regarding the kind of failures that should be detected by the liveliness mechanism. \n - kind: This data member establishes if the service needs to assert the liveliness automatically or if it needs to wait until the liveliness is asserted by the publishing side. \n\t - AUTOMATIC: The service takes the responsibility for renewing the leases at the required rates, as long as the local process where the participant is running and the link connecting it to remote participants exists, the entities within the remote participant will be considered alive. This kind is suitable for applications that only need to detect whether a remote application is still running. \n\t - MANUAL_BY_TOPIC: This mode requires requires that at least one instance within the DataWriter asserts the liveliness periodically before the lease_duration timer expires to consider that the DataWriter is alive. Publishing any new data value implicitly asserts the DataWriter’s liveliness, but it can be done explicitly by calling the assert_liveliness member function. \n - lease_duration: Amount of time to wait since the last time the DataWriter asserts its liveliness to consider that it is no longer alive."
    }
}