zerodds-durability-service

Services — Durability. Standalone Durability-Service for topics with TRANSIENT or PERSISTENT durability; the retention contract comes from DURABILITY_SERVICE (OMG DDS 1.4 §2.2.3.5), the architecture follows ADR 0009.

zerodds-durability-service is the library behind the durability daemon. Towards RTPS the service is an ordinary participant. For each served topic it

  1. ingests samples through a RELIABLE / TRANSIENT_LOCAL / KEEP_ALL reader, which also receives the history of a writer that was already running;
  2. stores each sample in a DurabilityStore from zerodds-durability-store;
  3. delivers the stored history to late-joining readers through a TRANSIENT_LOCAL writer, also after the process of the original writer has ended;
  4. fills that writer from the store when it starts serving a topic, so the history of a PERSISTENT topic is available after a restart of the service without any application writer.

The service uses two participants per domain, one for ingest and one for replay. They ignore each other before any endpoint exists, so the ingest reader never matches the replay writer. Samples are deduplicated on the GUID and sequence number of the source writer, so a writer's history received together with its live stream, or received again after a restart of the service, is stored once.

  • Retention contract. Contract::from_qos derives it from the DurabilityServiceQosPolicy a discovered writer announces (PID_DURABILITY_SERVICE). If the announced policy equals the DDS default (KEEP_LAST(1), all limits unlimited), which on the wire cannot be told apart from an unset policy, the default configured for the daemon applies. A per-topic contract in the daemon configuration takes precedence. Order: configuration, discovered QoS, daemon default.
  • Two writers with different policies. The contract of the first discovered writer stays in force for the topic. A different announcement from a later writer is not applied; it is reported as ServiceEvent::ConflictingDurabilityService.
  • Keyed topics. Keyedness is read from the RTPS entityKind octet of the writer. Keyed topics are stored and replayed per instance; KEEP_LAST applies per instance key, dispose/unregister and max_instances follow the contract. A replayed sample with a known source carries PID_ORIGINAL_WRITER_INFO with the GUID and sequence number of the original writer.
  • Restart. serve and serve_typed persist type name, keyedness and contract as TopicMeta in the store. serve_if_stored serves a topic from this metadata immediately, without waiting for a writer or reader to be discovered.
  • Reader without writer. A discovered reader alone does not start serving a topic, because DURABILITY_SERVICE is a Topic/DataWriter policy only. Serving requires stored TopicMeta or a discovered writer.
  • Cleanup. A background thread calls DurabilityStore::cleanup every 30 seconds, so an unregistered instance is purged once its service_cleanup_delay has elapsed.
  • Events. DurabilityService::events returns the most recent events (at most 256): AutoServeFailed, ConflictingDurabilityService, ReplayWriteFailed, ServedFromStoredMeta, TopicMetaMismatch. Each event is also written to stderr as one line.

Entry points: DurabilityService::start, start_with_config, serve, serve_typed, serve_if_stored, serve_discovered, enable_auto_discovery, contract_of, served_topics, events, shutdown.

Spec anchors

  • OMG DDS 1.4 §2.2.3.5 (DURABILITY_SERVICE: retention contract, service_cleanup_delay), §2.2.2.5.1.13 (dispose/unregister, forwarded to the replay writer).
  • DDSI-RTPS 2.5 §9.3.1.2 (entityKind and keyedness), §8.7.9 (sending stored data on behalf of the original writer), §9.6.3.9 (PID_STATUS_INFO bits of forwarded lifecycle markers).

Consumers

  • zerodds-durability-service-bin, which builds the daemon zerodds-durability-svc (man page).

Features

  • rt (off by default): enables zerodds-dcps/rt, i.e. real-time scheduling and CPU affinity for threads.* settings via zerodds-rt-linux. Without it the daemon refuses such a setting with "feature missing".

Status

  • std, #![forbid(unsafe_code)]. Safety classification in the crate docs: STANDARD.
  • Library only, no binary.
  • Test functions in the source: 8 in src/lib.rs, 9 in tests/ (one per file). tests/external_cyclone.rs is marked #[ignore] and needs an external CycloneDDS writer from tests/cyclone-harness/.

zerodds-durability-service

Dienste — Durability. Eigenständiger Durability-Service für Topics mit Durability TRANSIENT oder PERSISTENT; der Aufbewahrungsvertrag kommt aus DURABILITY_SERVICE (OMG DDS 1.4 §2.2.3.5), die Architektur folgt ADR 0009.

zerodds-durability-service ist die Bibliothek hinter dem Daemon des Durability-Service. Gegenüber RTPS ist der Dienst ein gewöhnlicher Participant. Für jedes bediente Topic

  1. nimmt er Samples über einen Reader mit RELIABLE / TRANSIENT_LOCAL / KEEP_ALL auf; dieser erhält auch die Historie eines Writers, der schon vorher lief;
  2. legt er jedes Sample in einem DurabilityStore aus zerodds-durability-store ab;
  3. liefert er die gespeicherte Historie über einen Writer mit TRANSIENT_LOCAL an spät hinzukommende Reader aus, auch nachdem der Prozess des ursprünglichen Writers beendet ist;
  4. füllt er diesen Writer beim Start der Bedienung eines Topics aus dem Speicher, sodass die Historie eines Topics mit PERSISTENT nach einem Neustart des Dienstes ohne jeden Writer der Anwendung verfügbar ist.

Der Dienst verwendet zwei Participants pro Domain, einen für die Aufnahme und einen für die Wiedergabe. Beide ignorieren sich gegenseitig, bevor ein Endpoint existiert; der Reader der Aufnahme passt daher nie zum Writer der Wiedergabe. Samples werden über GUID und Sequenznummer des Quell-Writers dedupliziert: Die Historie eines Writers, die zusammen mit seinem laufenden Datenstrom oder nach einem Neustart des Dienstes erneut eintrifft, wird einmal gespeichert.

  • Aufbewahrungsvertrag. Contract::from_qos leitet ihn aus der DurabilityServiceQosPolicy ab, die ein entdeckter Writer ankündigt (PID_DURABILITY_SERVICE). Entspricht die angekündigte Policy dem DDS-Standardwert (KEEP_LAST(1), alle Grenzen unbegrenzt), der auf der Leitung nicht von einer nicht gesetzten Policy zu unterscheiden ist, gilt der für den Daemon konfigurierte Standardwert. Ein contract pro Topic in der Konfiguration des Daemons hat Vorrang. Reihenfolge: Konfiguration, entdeckte QoS, Standardwert des Daemons.
  • Zwei Writer mit unterschiedlichen Policies. Für das Topic bleibt der Vertrag des zuerst entdeckten Writers in Kraft. Eine abweichende Ankündigung eines späteren Writers wird nicht übernommen, sondern als ServiceEvent::ConflictingDurabilityService gemeldet.
  • Topics mit Key. Ob ein Topic einen Key hat, wird aus dem RTPS-Oktett entityKind des Writers gelesen. Topics mit Key werden pro Instanz gespeichert und wiedergegeben; KEEP_LAST gilt pro Instanzschlüssel, Dispose/Unregister und max_instances folgen dem Vertrag. Ein wiedergegebenes Sample mit bekannter Quelle trägt PID_ORIGINAL_WRITER_INFO mit GUID und Sequenznummer des ursprünglichen Writers.
  • Neustart. serve und serve_typed legen Typname, Key-Eigenschaft und Vertrag als TopicMeta im Speicher ab. serve_if_stored bedient ein Topic sofort aus diesen Metadaten, ohne auf die Entdeckung eines Writers oder Readers zu warten.
  • Reader ohne Writer. Ein entdeckter Reader allein startet die Bedienung eines Topics nicht, weil DURABILITY_SERVICE nur eine Policy von Topic und DataWriter ist. Die Bedienung setzt gespeicherte TopicMeta oder einen entdeckten Writer voraus.
  • Bereinigung. Ein Hintergrund-Thread ruft alle 30 Sekunden DurabilityStore::cleanup auf; eine abgemeldete Instanz wird entfernt, sobald ihr service_cleanup_delay abgelaufen ist.
  • Ereignisse. DurabilityService::events liefert die jüngsten Ereignisse (höchstens 256): AutoServeFailed, ConflictingDurabilityService, ReplayWriteFailed, ServedFromStoredMeta, TopicMetaMismatch. Jedes Ereignis wird zusätzlich als eine Zeile auf stderr ausgegeben.

Einstiegspunkte: DurabilityService::start, start_with_config, serve, serve_typed, serve_if_stored, serve_discovered, enable_auto_discovery, contract_of, served_topics, events, shutdown.

Spec-Anker

  • OMG DDS 1.4 §2.2.3.5 (DURABILITY_SERVICE: Aufbewahrungsvertrag, service_cleanup_delay), §2.2.2.5.1.13 (Dispose/Unregister, an den Writer der Wiedergabe weitergereicht).
  • DDSI-RTPS 2.5 §9.3.1.2 (entityKind und Key-Eigenschaft), §8.7.9 (Senden gespeicherter Daten im Namen des ursprünglichen Writers), §9.6.3.9 (Bits von PID_STATUS_INFO für weitergereichte Lebenszyklus-Markierungen).

Konsumenten

  • zerodds-durability-service-bin, das den Daemon zerodds-durability-svc baut (Man-Page).

Features

  • rt (standardmäßig aus): schaltet zerodds-dcps/rt ein, also Echtzeit-Scheduling und CPU-Affinität für Einstellungen unter threads.* über zerodds-rt-linux. Ohne das Feature lehnt der Daemon eine solche Einstellung mit "feature missing" ab.

Status

  • std, #![forbid(unsafe_code)]. Einstufung in der Crate-Dokumentation (safety classification): STANDARD.
  • Nur Bibliothek, kein Binary.
  • Testfunktionen im Quelltext: 8 in src/lib.rs, 9 in tests/ (eine pro Datei). tests/external_cyclone.rs ist mit #[ignore] markiert und braucht einen externen CycloneDDS-Writer aus tests/cyclone-harness/.