Qu'est-ce que DDS ?

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

Le patron Publish-Subscribe

Contrairement aux architectures traditionnelles requete-reponse (comme HTTP ou gRPC), DDS utilise un patron publish-subscribe ou :

• Les Publishers envoient des donnees sans savoir qui les recoit
• Les Subscribers recoivent des donnees 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 identifie par un ID numerique (0-232). Les Participants dans le meme Domain peuvent se decouvrir 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 (different domain)
let isolated = Participant::builder("isolated")
    .domain_id(42)
    .with_transport(TransportMode::UdpMulticast)
    .build()?;

Participant (DomainParticipant)

Le Participant est votre point d'entree vers DDS. Il :

• Rejoint un Domain
• Gere la decouverte (discovery)
• Cree des Publishers, Subscribers et Topics

Topic

Un Topic est un canal nomme pour un type de donnees specifique. Les Topics ont :

• Nom : Un identifiant chaine (ex. sensor/temperature)
• Type : La structure de donnees publiee
• QoS : Les politiques de qualite 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 ecrit des echantillons de donnees 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 echantillons de donnees 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 controle fin sur la distribution des donnees via les politiques QoS :

Politique	Description
Reliability	BEST_EFFORT (rapide) vs RELIABLE (livraison garantie)
Durability	Ce qui arrive aux donnees avant que les Subscribers ne se connectent
History	Combien d'echantillons conserver
Deadline	Temps maximum entre les mises a jour
Liveliness	Comment detecter les Participants defaillants
Ownership	Qui possede une instance quand plusieurs Writers existent

astuce

Commencez avec les valeurs par defaut ! DDS a des parametres par defaut raisonnables. Ne changez les QoS que lorsque vous avez un besoin specifique.

Architecture centree sur les donnees

DDS est centre sur les donnees (data-centric), ce qui signifie :

1. Les donnees sont l'interface - Vous definissez a quoi ressemblent les donnees, pas comment les obtenir
2. Decouverte automatique - Pas besoin de configurer des adresses IP ou des ports
3. Systemes decouplees - Publishers et Subscribers ne se connaissent pas
4. Transparence de localisation - Les donnees circulent independamment de l'emplacement des applications

Exemple : Reseau de capteurs

DDS vs autres technologies

Caracteristique	DDS	MQTT	Kafka	gRPC
Patron	Pub/Sub	Pub/Sub	Pub/Sub	Requete/Reponse
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 reel	Oui	Non	Non	Non
Standard	OMG	OASIS	Confluent	Google

Quand utiliser DDS

Utilisez DDS quand vous avez besoin de :

• Distribution de donnees temps reel, basse latence
• Multicast fiable vers de nombreux Subscribers
• Decouverte automatique sans infrastructure
• Controle QoS fin
• Interoperabilite 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 requete/reponse (utilisez gRPC)

Prochaines etapes

Maintenant que vous comprenez les concepts DDS, decouvrez le protocole filaire :

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