À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Architecture du contrôleur hôte
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
L'architecture du framework de test VTS s'intègre à son service de diffusion de tests cloud. Un contrôleur hôte VTS s'exécute sur une machine hôte et contrôle une instance de banc d'essai (par exemple, Tradefed), comme illustré ci-dessous:
Figure 1 : Architecture du contrôleur hôte VTS.
Le contrôleur extrait les commandes d'un contrôleur de cluster exécuté en tant qu'instance Google App Engine (GAE), puis transmet les commandes et les réponses entre son contrôleur de cluster et l'instance de banc d'essai.
Cette architecture présente les avantages suivants:
- Étant donné qu'il est découplé de toute instance de banc d'essais, il peut contrôler différents types de bancs d'essais et est plus robuste. La conception alternative (intégration de la logique de contrôle de l'hôte dans un banc d'essais) n'empêche pas la propagation des erreurs.
- Étant donné qu'il utilise un modèle de commande et de contrôle (C&C) basé sur le pull, il peut fonctionner avec différents types de commandes de cluster côté cloud, ainsi qu'avec des hôtes situés derrière un pare-feu (pour les connexions entrantes). La conception alternative (modèle de contrôle et de commande basé sur le push) peut ne pas permettre à un cloud commander d'accéder aux instances de contrôleur hôte qui existent sur les ordinateurs hôtes d'un réseau privé.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Host controller architecture\n\nThe architecture of VTS test framework integrates with its cloud-based test\nserving service. A VTS host controller runs on a host machine and controls a\ntest harness (for example, Tradefed) instance as shown below:\n\n\n**Figure 1.** VTS host controller architecture.\n\n\nThe controller pulls commands from a cluster commander running as a Google App\nEngine (GAE) instance, then relays commands and responses between its cluster\ncommander and the test harness instance.\n\nThis architecture includes the following advantages:\n\n- Because it's **decoupled from any test harness instance**, it can control different types of test harnesses and is more robust. The alternative design (embedding the host control logic in a test harness) does not block errors from propagating.\n- Because it uses a **pull-based command-and-control (C\\&C)\n model**, it can work with different types of cloud-side cluster commanders as well as hosts that exist behind a firewall (for ingress connections). The alternative design (push-based C\\&C model) might not allow a cloud commander to access host controller instances that exist on host computers in a private network."]]
