Architecture de HDDS

HDDS suit une architecture en couches concue pour la performance, la modularite et la conformite aux standards.

Vue d'ensemble des couches

+---------------------------------------------------------+
|                   Couche Application                     |
|          (Votre application Rust/C/C++/Python)          |
+---------------------------------------------------------+
|                     Couche DCPS                          |
|  DomainParticipant | Publisher | Subscriber | Topic | QoS|
+---------------------------------------------------------+
|                     Couche RTPS                          |
|   Discovery (SPDP/SEDP) | Writers | Readers | History   |
+---------------------------------------------------------+
|                   Couche Transport                       |
|         UDP Multicast | UDP Unicast | Shared Memory      |
+---------------------------------------------------------+

Couche DCPS (Data-Centric Publish-Subscribe)

La couche DCPS fournit l'API DDS avec laquelle les applications interagissent :

Entite	Role
DomainParticipant	Point d'entree, possede toutes les autres entites
Publisher	Regroupe les DataWriters, applique des QoS communes
Subscriber	Regroupe les DataReaders, applique des QoS communes
Topic	Canal de donnees nomme avec un type
DataWriter	Ecrit des echantillons sur un Topic
DataReader	Lit des echantillons depuis un Topic

Hierarchie des entites

DomainParticipant
+-- Publisher
|   +-- DataWriter<SensorData>
|   +-- DataWriter<Command>
+-- Subscriber
|   +-- DataReader<SensorData>
|   +-- DataReader<Status>
+-- Topic
    +-- "SensorTopic"
    +-- "CommandTopic"

Couche RTPS (Real-Time Publish-Subscribe)

La couche RTPS implemente le protocole filaire pour l'interoperabilite :

RTPS Writers et Readers

+------------------+     Protocole RTPS      +------------------+
|   RTPS Writer    | ----------------------> |   RTPS Reader    |
|                  |                         |                  |
|  +------------+  |     DATA, HEARTBEAT     |  +------------+  |
|  |  History   |  | ---------------------> |  |  History   |  |
|  |   Cache    |  |                         |  |   Cache    |  |
|  +------------+  |     ACKNACK, GAP        |  +------------+  |
|                  | <--------------------- |                  |
+------------------+                         +------------------+

History Cache

Chaque Writer et Reader maintient un History Cache :

• Writer History : Stocke les echantillons jusqu'a l'acquittement
• Reader History : Stocke les echantillons recus jusqu'a leur consommation

use hdds::QoS;

// History depth controlled by QoS
let qos = QoS::reliable().keep_last(100);

Architecture de la decouverte

La decouverte utilise deux protocoles s'executant sur des endpoints integres :

+---------------------------------------------------------+
|                  DomainParticipant                       |
+----------------------------+----------------------------+
|   SPDP (Participants)      |   SEDP (Endpoints)         |
|                            |                            |
|  BuiltinParticipant        |  BuiltinPublications       |
|    Writer/Reader           |    Writer/Reader            |
|                            |                            |
|  Multicast: 239.255.x.x   |  BuiltinSubscriptions      |
|  Port: 7400 + offset       |    Writer/Reader            |
+----------------------------+----------------------------+

Flux de decouverte

1. Annonce SPDP (multicast)
   Participant A --> 239.255.0.1:7400 --> Participant B

2. Echange SEDP (unicast)
   A.Publications ------> B (infos endpoints)
   A <------ B.Publications (infos endpoints)

3. Appariement
   A.Writer apparie avec B.Reader (QoS compatibles)

4. Flux de donnees utilisateur
   A.Writer --> DATA --> B.Reader

Couche Transport

HDDS supporte plusieurs transports :

Transport	Cas d'usage	Latence
UDP Multicast	Discovery, multi-Subscriber	Moyenne
UDP Unicast	Point a point, WAN	Moyenne
Shared Memory	Meme hote, haute performance	Faible (~1 us)

Selection du transport

let config = ParticipantConfig::default()
    .transport(Transport::UdpMulticast)   // Default
    .transport(Transport::SharedMemory);   // Add SHM

Modele de threading

HDDS utilise un runtime async avec des threads dedies :

+---------------------------------------------------------+
|                    Threads utilisateur                    |
|    (write(), take(), create_reader(), etc.)             |
+---------------------------------------------------------+
|                     Runtime HDDS                         |
|  +-------------+  +-------------+  +------------------+ |
|  |  Discovery  |  |   Pool I/O  |  |  Timer/Scheduler | |
|  |   Thread    |  |  (tokio)    |  |                  | |
|  +-------------+  +-------------+  +------------------+ |
+---------------------------------------------------------+

• Threads utilisateur : Les appels applicatifs sont non-bloquants autant que possible
• Thread Discovery : Gere le protocole SPDP/SEDP
• Pool I/O : Operations reseau async (basees sur tokio)
• Thread Timer : Heartbeats, deadlines, liveliness

Architecture memoire

Chemin zero-copy

Pour les scenarios haute performance, HDDS supporte le zero-copy :

// Standard path (copy)
writer.write(&sample)?;

// Zero-copy path (loan buffer)
let mut loan = writer.loan_sample()?;
*loan = sample;
loan.write()?;  // No copy to internal buffer

Gestion des buffers

+-----------------+    +-----------------+    +-----------------+
|  Buffer utilisa-|    |  History Cache  |    | Buffer reseau   |
|  teur           | -> |  (par Writer)   | -> | (par envoi)     |
+-----------------+    +-----------------+    +-----------------+

Les limites de ressources empechent une croissance memoire non bornee :

use hdds::QoS;

let qos = QoS::reliable()
    .max_samples(10000)
    .max_instances(100)
    .max_samples_per_instance(100);

Flux de donnees

Chemin d'ecriture

1. L'application appelle writer.write(&sample)
2. L'echantillon est serialise (CDR2/XCDR2)
3. Ajoute au History Cache du Writer
4. Encapsule dans un sous-message RTPS DATA
5. Envoye via le transport (UDP/SHM)
6. Acquitte (si reliable)
7. Retire de l'historique (si acquitte)

Chemin de lecture

1. Le reseau recoit un paquet RTPS
2. Analyse des sous-messages (DATA, HEARTBEAT, etc.)
3. Deserialisation de l'echantillon
4. Ajout au History Cache du Reader
5. Envoi d'ACKNACK (si reliable)
6. L'application appelle reader.take()
7. L'echantillon est retire de l'historique

Structure des modules

hdds/
+-- dcps/           # API DDS (Participant, Publisher, etc.)
+-- rtps/           # Implementation du protocole RTPS
|   +-- writer.rs   # Machine a etats RTPS Writer
|   +-- reader.rs   # Machine a etats RTPS Reader
|   +-- discovery/  # SPDP et SEDP
|   +-- messages/   # Types de messages RTPS
+-- transport/      # Transports reseau
|   +-- udp.rs
|   +-- shm.rs
+-- serialization/  # Codecs CDR/XCDR2
+-- qos/            # Implementations des politiques QoS

Caracteristiques de performance

Operation	Latence typique
write() vers le reseau	5-50 us
Reseau vers take()	10-100 us
Aller-retour Shared Memory	1-5 us
Discovery (demarrage a froid)	100-500 ms

Prochaines etapes

• DomainParticipant - Details du point d'entree
• Topics - Canaux de donnees
• Discovery - Comment les endpoints se trouvent