À propos des paramètres de qualité de service
Aperçu
ROS 2 offre une grande variété de politiques de qualité de service (QoS) qui vous permettent d’ajuster la communication entre les nœuds. Avec le bon ensemble de politiques de qualité de service, ROS 2 peut être aussi fiable que TCP ou aussi efficace qu’UDP, avec de très nombreux états possibles entre les deux. Contrairement à ROS 1, qui ne prenait principalement en charge que TCP, ROS 2 bénéficie de la flexibilité du transport DDS sous-jacent dans des environnements avec des réseaux sans fil avec perte où une politique de « meilleur effort » serait plus appropriée, ou dans des systèmes informatiques en temps réel où la bonne qualité du profil de service est nécessaire pour respecter les délais.
Un ensemble de « politiques » QoS se combinent pour former un « profil » QoS. Compte tenu de la complexité du choix des politiques QoS correctes pour un scénario donné, ROS 2 fournit un ensemble de profils QoS prédéfinis pour les cas d’utilisation courants (par exemple, les données de capteur). Dans le même temps, les développeurs ont la possibilité de contrôler des politiques spécifiques des profils QoS.
Des profils QoS peuvent être spécifiés pour les éditeurs, les abonnements, les serveurs de service et les clients. Un profil QoS peut être appliqué indépendamment à chaque instance des entités susmentionnées, mais si différents profils sont utilisés, il est possible qu’ils soient incompatibles, empêchant la livraison des messages.
Politiques de qualité de service
Le profil QoS de base inclut actuellement des paramètres pour les stratégies suivantes :
Histoire
Keep last : ne stocke que jusqu’à N échantillons, configurable via l’option de profondeur de file d’attente.
Tout conserver : stocke tous les échantillons, sous réserve des limites de ressources configurées du middleware sous-jacent.
Profondeur
Taille de la file d’attente : honoré uniquement si la politique « historique » a été définie sur « conserver en dernier ».
Fiabilité
Meilleur effort : tentative de livraison d’échantillons, mais risque de les perdre si le réseau n’est pas robuste.
Fiable : garantit que les échantillons sont livrés, peut réessayer plusieurs fois.
Durabilité
Transient local : l’éditeur devient responsable de la persistance des échantillons pour les abonnements « tardifs ».
Volatile : aucune tentative n’est effectuée pour conserver les échantillons.
Date limite
Durée : la durée maximale prévue entre les messages suivants publiés sur un sujet
Durée de vie
Durée : la durée maximale entre la publication et la réception d’un message sans que le message soit considéré comme obsolète ou expiré (les messages expirés sont supprimés silencieusement et ne sont effectivement jamais reçus).
Vivacité
Automatique : le système considérera que tous les éditeurs du nœud sont actifs pour une autre « durée de bail » lorsque l’un de ses éditeurs a publié un message.
Manuel par sujet : le système considérera que l’éditeur est en vie pour une autre « durée de bail » s’il affirme manuellement qu’il est toujours en vie (via un appel à l’API de l’éditeur).
Durée du bail
Durée : la période maximale pendant laquelle un éditeur doit indiquer qu’il est actif avant que le système ne considère qu’il a perdu de l’activité (la perte de l’activité peut être le signe d’un échec).
Pour chacune des politiques qui n’est pas une durée, il y a aussi l’option « système par défaut », qui utilise la valeur par défaut du middleware sous-jacent. Pour chacune des politiques qui est une durée, il existe également une option « par défaut » qui signifie que la durée n’est pas spécifiée, ce que le middleware sous-jacent interprétera généralement comme une durée infiniment longue.
Comparaison avec ROS 1
Les politiques « historique » et « profondeur » dans ROS 2 se combinent pour fournir des fonctionnalités similaires à la taille de la file d’attente dans ROS 1.
La politique de « fiabilité » dans ROS 2 s’apparente à l’utilisation soit de UDPROS (uniquement dans roscpp) pour « meilleur effort », soit de TCPROS (par défaut ROS 1) pour « fiable ». Notez cependant que même la politique fiable dans ROS 2 est implémentée à l’aide d’UDP, ce qui permet la multidiffusion si nécessaire.
La politique de « durabilité » « transitoire locale », combinée à toute profondeur, offre une fonctionnalité similaire à celle des éditeurs « à verrouillage ». Les politiques restantes dans ROS 2 ne s’apparentent à rien de ce qui est disponible dans ROS 1, ce qui signifie que ROS 2 est plus complet que ROS 1 à cet égard. Il est possible qu’à l’avenir, encore plus de politiques QoS soient disponibles dans ROS 2.
Profils de qualité de service
Les profils permettent aux développeurs de se concentrer sur leurs applications sans se soucier de tous les paramètres QoS possibles. Un profil QoS définit un ensemble de politiques censées aller bien ensemble pour un cas d’utilisation particulier.
Les profils QoS actuellement définis sont :
Paramètres QoS par défaut pour les éditeurs et les abonnements
Afin de faciliter la transition de ROS 1 à ROS 2, il est souhaitable d’exercer un comportement de réseau similaire. Par défaut, les éditeurs et les abonnements dans ROS 2 ont « conserver en dernier » pour l’historique avec une taille de file d’attente de 10, « fiable » pour la fiabilité, « volatile » pour la durabilité et « système par défaut » pour la vivacité. La date limite, la durée de vie et la durée des baux sont également définies sur « par défaut ».
Prestations de service
Dans la même veine que les éditeurs et les abonnements, les services sont fiables. Il est particulièrement important que les services utilisent une durabilité volatile, sinon les serveurs de service qui redémarrent peuvent recevoir des demandes obsolètes. Alors que le client est protégé contre la réception de plusieurs réponses, le serveur n’est pas protégé contre les effets secondaires de la réception des demandes obsolètes.
Données du capteur
Pour les données des capteurs, dans la plupart des cas, il est plus important de recevoir les lectures en temps opportun, plutôt que de s’assurer qu’elles arrivent toutes. Autrement dit, les développeurs veulent les derniers échantillons dès qu’ils sont capturés, au risque d’en perdre peut-être certains. Pour cette raison, le profil de données du capteur utilise la fiabilité du meilleur effort et une taille de file d’attente plus petite.
Paramètres
Les paramètres dans ROS 2 sont basés sur les services et, en tant que tels, ont un profil similaire. La différence est que les paramètres utilisent une profondeur de file d’attente beaucoup plus grande afin que les demandes ne soient pas perdues lorsque, par exemple, le client de paramètres est incapable d’atteindre le serveur de service de paramètres.
Défaut du système
Cela utilise les valeurs par défaut de l’implémentation RMW pour toutes les stratégies. Différentes implémentations RMW peuvent avoir des valeurs par défaut différentes.
Cliquez ici pour les politiques spécifiques utilisées pour les profils ci-dessus. Les paramètres de ces profils sont sujets à d’autres ajustements, en fonction des commentaires de la communauté.
Compatibilités QoS
Remarque : Cette section fait référence aux éditeurs et aux abonnements, mais le contenu s’applique aux serveurs de service et aux clients de la même manière.
Les profils QoS peuvent être configurés indépendamment pour les éditeurs et les abonnements. Une connexion entre un éditeur et un abonnement n’est établie que si la paire a des profils QoS compatibles.
La compatibilité du profil QoS est déterminée sur la base d’un modèle « Demande vs Offert ». Les abonnements demandent un profil QoS qui est la « qualité minimale » qu’ils sont prêts à accepter, et les éditeurs offrent un profil QoS qui est la « qualité maximale » qu’ils sont capables de fournir. Les connexions ne sont établies que si chaque politique du profil QoS demandé n’est pas plus stricte que celle du profil QoS proposé. Plusieurs abonnements peuvent être connectés simultanément à un seul éditeur même si leurs profils QoS demandés sont différents. La compatibilité entre un éditeur et un abonnement n’est pas affectée par la présence d’autres éditeurs et abonnements.
Les tableaux suivants montrent la compatibilité des différents paramètres de stratégie et le résultat :
Compatibilité des politiques de QoS de fiabilité :
Éditeur |
Abonnement |
Compatibles |
|---|---|---|
Meilleur effort |
Meilleur effort |
Oui |
Meilleur effort |
Fiable |
Non |
Fiable |
Meilleur effort |
Oui |
Fiable |
Fiable |
Oui |
Compatibilité des politiques QoS de durabilité :
Éditeur |
Abonnement |
Compatibles |
|---|---|---|
Volatil |
Volatil |
Oui |
Volatil |
Transitoire locale |
Non |
Transitoire locale |
Volatil |
Oui |
Transitoire locale |
Transitoire locale |
Oui |
Compatibilité des politiques de qualité de service des délais :
Supposons que x et y sont des valeurs de durée valides arbitraires.
Éditeur |
Abonnement |
Compatibles |
|---|---|---|
Défaut |
Défaut |
Oui |
Défaut |
X |
Non |
X |
Défaut |
Oui |
X |
X |
Oui |
X |
y (où y > x) |
Oui |
X |
y (où y < x) |
Non |
Compatibilité des politiques QoS de vivacité :
Éditeur |
Abonnement |
Compatibles |
|---|---|---|
Automatique |
Automatique |
Oui |
Automatique |
Manuel par sujet |
Non |
Manuel par sujet |
Automatique |
Oui |
Manuel par sujet |
Manuel par sujet |
Oui |
Compatibilité des politiques QoS de durée de location :
Supposons que x et y sont des valeurs de durée valides arbitraires.
Éditeur |
Abonnement |
Compatibles |
|---|---|---|
Défaut |
Défaut |
Oui |
Défaut |
X |
Non |
X |
Défaut |
Oui |
X |
X |
Oui |
X |
y (où y > x) |
Oui |
X |
y (où y < x) |
Non |
Pour qu’une connexion soit établie, toutes les stratégies qui affectent la compatibilité doivent être compatibles. Par exemple, même si une paire de profils QoS demandée et offerte a des politiques QoS de fiabilité compatibles, mais qu’elles ont des politiques QoS de durabilité incompatibles, une connexion ne sera toujours pas établie.
Lorsque les connexions ne sont pas établies, aucun message ne sera transmis entre l’éditeur et l’abonnement. Il existe des mécanismes pour détecter cette situation, qui seront couverts dans une section ultérieure.
Comparaison avec ROS 1
Historiquement, dans ROS 1, tout éditeur et abonné avec le même type de message sur le même sujet serait connecté. La possibilité de profils QoS demandés et proposés incompatibles est quelque chose de nouveau à prendre en compte lors de l’utilisation de ROS 2.
Événements de qualité de service
Certaines stratégies de QoS ont des événements possibles qui leur sont associés. Les développeurs peuvent fournir à chaque éditeur et abonnement des fonctions de rappel déclenchées par ces événements QoS et les gérer comme ils l’entendent, de la même manière que les messages reçus sur un sujet sont traités.
Les développeurs peuvent s’abonner aux événements QoS suivants associés à un éditeur :
Délai proposé manqué
L’éditeur n’a pas publié de message dans le délai prévu défini par la politique de qualité de service des délais.
La vivacité a perdu
L’éditeur a omis d’indiquer sa vivacité dans la durée du bail.
Qualité de service incompatible offerte
L’éditeur a rencontré un abonnement sur le même sujet qui demande un profil QoS que le profil QoS proposé ne peut pas satisfaire, ce qui entraîne l’absence de connexion entre l’éditeur et cet abonnement.
Les développeurs peuvent s’abonner aux événements QoS suivants associés à un abonnement :
Délai demandé dépassé
L’abonnement n’a pas reçu de message dans le délai prévu défini par la politique QoS d’échéance.
La vivacité a changé
L’abonnement a remarqué qu’un ou plusieurs éditeurs sur le sujet abonné n’ont pas indiqué leur activité pendant la durée du bail.
QoS incompatible demandée
L’abonnement a rencontré un éditeur sur le même sujet qui propose un profil QoS qui ne satisfait pas le profil QoS demandé, ce qui entraîne l’absence de connexion entre l’abonnement et cet éditeur.