Accepte des connexions et permet le transfert et la réception de flux de données binaires pour des ports modélisés.
Contexte
La classe ara::rds::RawDataStreamServer représente, dans l'AUTOSAR Adaptive Platform (module rds), le pendant côté serveur pour les transferts de données orientés flux SWS RawDataStream p. 1. Sa tâche principale consiste à accepter les connexions client entrantes sur un port de communication modélisé et à gérer l'échange bidirectionnel ultérieur de données brutes non structurées via des flux de données binaires.
Les partenaires d'interaction clés comprennent :
- l'application serveur de niveau supérieur, qui crée l'instance, attend les connexions et initie le transfert de données,
- le système d'exécution AUTOSAR, auquel le serveur est lié via un
ara::core::InstanceSpecifier pour un port modélisé [SWS_RDS_11312],
- le client externe, qui établit une connexion vers le serveur [SWS_RDS_11318] et échange des données utiles [SWS_RDS_11322], [SWS_RDS_11324].
Cycle de vie
L'instanciation d'un RawDataStreamServer ne s'effectue pas via des constructeurs ordinaires, mais exclusivement via la méthode fabrique statique Create [SWS_RDS_11312]. Celle-ci lie le serveur au port spécifié par ara::core::InstanceSpecifier.
Concernant les relations de propriété, la classe impose une sémantique stricte exclusivement déplaçable (move-only). Le constructeur de copie [SWS_RDS_11316] et l'opérateur d'assignation par copie [SWS_RDS_11317] sont explicitement supprimés (delete). La transmission de ressources à d'autres portées n'est donc possible que via le constructeur de déplacement [SWS_RDS_11314] ou l'opérateur d'assignation par déplacement [SWS_RDS_11315].
Interprétation : après une création réussie, l'instance du serveur se trouve dans un état initial de disponibilité dans lequel aucune connexion active n'existe encore. Question Q-5d536f7c10a62342 (ouverte) Via WaitForConnection [SWS_RDS_11318] ou la variante temporisée WaitForConnection(timeout) [SWS_RDS_11319], le serveur attend un client et passe, en cas de succès, à l'état d'une connexion active. La connexion peut être fermée de manière ciblée à l'exécution par l'appel de Shutdown [SWS_RDS_11320].
Lors de la destruction de l'instance du serveur, le destructeur ~RawDataStreamServer garantit qu'une connexion encore ouverte est automatiquement arrêtée et fermée en bonne et due forme [SWS_RDS_11313].
En matière de concurrence, la méthode de création Create est spécifiée comme thread-safe [SWS_RDS_11312]. Les opérations de déplacement [SWS_RDS_11314], [SWS_RDS_11315] ainsi que le destructeur [SWS_RDS_11313] sont en revanche explicitement désignés comme non thread-safe (not thread-safe) et requièrent une protection par synchronisation externe lors d'accès simultanés depuis plusieurs threads.
Diagramme d'états : phases d'une instance serveur, de la création à la fermeture de la connexion en passant par l'acceptation de la connexion. Sources : [SWS_RDS_11312], [SWS_RDS_11318], [SWS_RDS_11320], [SWS_RDS_11313]
Parcours d'utilisation
Le chemin d'utilisation typique d'une application serveur comprend les étapes d'initialisation, d'attente de connexions, de transfert bidirectionnel de données et de libération de la connexion :
- Créer le serveur : l'application instancie le serveur via
ara::rds::RawDataStreamServer::Create(instance) pour le port configuré [SWS_RDS_11312].
- Attendre une connexion : l'application bloque au moyen de
WaitForConnection() [SWS_RDS_11318] ou avec une durée maximale configurée via WaitForConnection(timeout) [SWS_RDS_11319], jusqu'à ce qu'un client ait établi la connexion.
- Recevoir et envoyer des données : après une connexion réussie, l'application lit des données binaires au moyen de
ReadData(maxLength) [SWS_RDS_11322] ou de manière temporisée via ReadData(maxLength, timeout) [SWS_RDS_11323]. Pour envoyer des données binaires, WriteData est appelé, au choix sans limitation de temps d'attente [SWS_RDS_11324] ou avec surveillance temporelle [SWS_RDS_11325]. L'envoi via WriteData transfère vraisemblablement la propriété du tampon d'octets fourni (std::unique_ptr<ara::core::Byte[]>) au serveur. Question Q-eec0fea4a5ffaf40 (ouverte)
- Fermer la connexion : lorsque le transfert de données est terminé, l'application met fin explicitement à la session via
Shutdown() [SWS_RDS_11320].
Diagramme de séquence : déroulement de la création, de l'acceptation de connexion, de l'échange de données et de la fermeture de la connexion. Sources : [SWS_RDS_11312], [SWS_RDS_11318], [SWS_RDS_11322], [SWS_RDS_11324], [SWS_RDS_11320]
Scénarios d'erreur
Le traitement des erreurs de RawDataStreamServer suit les principes de l'AUTOSAR Adaptive Platform relatifs aux interfaces à sûreté de fonctionnement (fail-safe) :
Aucune des méthodes ne lève d'exceptions C++ ; toutes les fonctions sont déclarées comme noexcept SWS RawDataStream p. 1. Les cas d'erreur sont communiqués à l'appelant via le type de retour ara::core::Result.
Les scénarios d'erreur typiques comprennent :
- Dépassements de délai : pour les méthodes
WaitForConnection [SWS_RDS_11319], ReadData [SWS_RDS_11323] et WriteData [SWS_RDS_11325] avec délai d'attente (timeout), l'écoulement de la durée indiquée entraîne un état d'erreur dans le ara::core::Result renvoyé.
- Erreurs de connexion et états non valides : les méthodes
ReadData, WriteData et WaitForConnection devraient, en cas d'erreur (par exemple lors d'une connexion prématurément coupée ou d'erreurs de communication internes), renvoyer des codes d'erreur correspondants dans le ara::core::Result. Question Q-0c6815ddde412d81 (ouverte)
- Préconditions et postconditions : les appelants doivent toujours vérifier la validité du
ara::core::Result renvoyé avant d'accéder aux valeurs de données, afin de s'assurer de l'état sans erreur de l'opération.
Ce guide est basé sur la spécification AUTOSAR Adaptive R25-11 et a été généré automatiquement.
gemini-3.8-flash-low· 2026-10-13 · Original allemand