Qu'est-ce que DDS ?

DDS (Data Distribution Service) est un standard OMG (Object Management Group) pour un middleware publish-subscribe centre sur les données. Il fournit un cadre pour l'échange de données en temps réel, scalable et fiable entre applications distribuees.

Le patron Publish-Subscribe

Contrairement aux architectures traditionnelles requête-réponse (comme HTTP ou gRPC), DDS utilise un patron publish-subscribe ou :

• Les Publishers envoient des données sans savoir qui les reçoit
• Les Subscribers reçoivent des données sans savoir qui les envoie
• Un Topic connecte publishers et subscribers ayant des interets communs

Concepts fondamentaux

Domain

Un Domain est un espace de communication isole identifié par un ID numérique (0-232). Les Participants dans le même Domain peuvent se découvrir et communiquer entre eux.

use hdds::{Participant, TransportMode};

// Two participants on the same domain can communicate
let participant1 = Participant::builder("app1")
    .domain_id(0)
    .with_transport(TransportMode::UdpMulticast)
    .build()?;

let participant2 = Participant::builder("app2")
    .domain_id(0)
    .with_transport(TransportMode::UdpMulticast)
    .build()?;

// This participant is isolated from the others (différent domain)
let isolated = Participant::builder("isolated")
    .domain_id(42)
    .with_transport(TransportMode::UdpMulticast)
    .build()?;

Participant (DomainParticipant)

Le Participant est votre point d'entrée vers DDS. Il :

• Rejoint un Domain
• Gère la découverte (discovery)
• Crée des Publishers, Subscribers et Topics

Topic

Un Topic est un canal nommé pour un type de données spécifique. Les Topics ont :

• Nom : Un identifiant chaîne (ex. sensor/temperature)
• Type : La structure de données publiée
• QoS : Les politiques de qualité de service

#[derive(Topic, Serialize, Deserialize)]
struct Temperature {
    #[key]
    sensor_id: String,
    value: f32,
    timestamp: u64,
}

let topic = participant.create_topic::<Temperature>("sensor/temperature")?;

Publisher / DataWriter

Un Publisher regroupe des DataWriters avec des QoS communes. Un DataWriter écrit des échantillons de données sur un Topic.

let publisher = participant.create_publisher()?;
let writer = publisher.create_writer(&topic)?;

writer.write(&Temperature {
    sensor_id: "room1".into(),
    value: 23.5,
    timestamp: now(),
})?;

Subscriber / DataReader

Un Subscriber regroupe des DataReaders avec des QoS communes. Un DataReader lit des échantillons de données depuis un Topic.

let subscriber = participant.create_subscriber()?;
let reader = subscriber.create_reader(&topic)?;

// Wait for data
while let Some(sample) = reader.take()? {
    println!("Received: {} = {}C", sample.sensor_id, sample.value);
}

Quality of Service (QoS)

DDS offre un contrôle fin sur la distribution des données via les politiques QoS :

Politique	Description
Reliability	BEST_EFFORT (rapide) vs RELIABLE (livraison garantie)
Durability	Ce qui arrive aux données avant que les Subscribers ne se connectent
History	Combien d'échantillons conserver
Deadline	Temps maximum entre les mises à jour
Liveliness	Comment détecter les Participants défaillants
Ownership	Qui possède une instance quand plusieurs Writers existent

astuce

Commencez avec les valeurs par défaut ! DDS à des paramètres par défaut raisonnables. Ne changez les QoS que lorsque vous avez un besoin spécifique.

Architecture centree sur les données

DDS est centre sur les données (data-centric), ce qui signifie :

1. Les données sont l'interface - Vous definissez à quoi ressemblent les données, pas comment les obtenir
2. Découverte automatique - Pas besoin de configurer des adresses IP ou des ports
3. Systèmes découplées - Publishers et Subscribers ne se connaissent pas
4. Transparence de localisation - Les données circulent indépendamment de l'emplacement des applications

Exemple : Réseau de capteurs

DDS vs autres technologies

Caractéristique	DDS	MQTT	Kafka	gRPC
Patron	Pub/Sub	Pub/Sub	Pub/Sub	Requête/Réponse
Broker	Aucun (P2P)	Requis	Requis	Aucun
Latence	Sub-us	~1ms	~10ms	~100us
QoS	22 politiques	3 niveaux	At-least-once	Aucun
Discovery	Automatique	Via broker	Via broker	Manuel
Temps réel	Oui	Non	Non	Non
Standard	OMG	OASIS	Confluent	Google

Quand utiliser DDS

Utilisez DDS quand vous avez besoin de :

• Distribution de données temps réel, basse latence
• Multicast fiable vers de nombreux Subscribers
• Découverte automatique sans infrastructure
• Contrôle QoS fin
• Interopérabilité entre vendeurs

Envisagez des alternatives quand :

• Vous avez besoin de files de messages cloud-native (utilisez Kafka)
• Vous avez des appareils IoT contraints en batterie (utilisez MQTT)
• Vous avez besoin de simple requête/réponse (utilisez gRPC)

Prochaines étapes

Maintenant que vous comprenez les concepts DDS, découvrez le protocole filaire :

• Qu'est-ce que RTPS ? - Le protocole qui fait fonctionner DDS