हमारा सुझाव है कि 27 मार्च, 2025 से AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.
होस्ट कंट्रोलर का आर्किटेक्चर
संग्रह की मदद से व्यवस्थित रहें
अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
VTS टेस्ट फ़्रेमवर्क का आर्किटेक्चर, क्लाउड-आधारित टेस्ट सेव करने वाली सेवा के साथ इंटिग्रेट होता है. VTS होस्ट कंट्रोलर, होस्ट मशीन पर चलता है और यहां दिखाए गए तरीके से, जांच के लिए इस्तेमाल होने वाले टूल (उदाहरण के लिए, Tradefed) के इंस्टेंस को कंट्रोल करता है:
पहली इमेज. VTS होस्ट कंट्रोलर का आर्किटेक्चर.
कंट्रोलर, Google App
Engine (GAE) इंस्टेंस के तौर पर चल रहे क्लस्टर कमांडर से निर्देश लेता है. इसके बाद, अपने क्लस्टर कमांडर और टेस्ट हार्नेस इंस्टेंस के बीच निर्देश और जवाबों को रिले करता है.
इस आर्किटेक्चर के ये फ़ायदे हैं:
- यह किसी भी टेस्ट हार्नेस इंस्टेंस से अलग है. इसलिए, यह अलग-अलग तरह के टेस्ट हार्नेस को कंट्रोल कर सकता है और ज़्यादा बेहतर है. वैकल्पिक डिज़ाइन (टेस्ट हार्नेस में होस्ट कंट्रोल लॉजिक को एम्बेड करना), गड़बड़ियों को फैलने से नहीं रोकता.
- यह पुल-आधारित कमांड-एंड-कंट्रोल (C&C)
मॉडल का इस्तेमाल करता है. इसलिए, यह अलग-अलग तरह के क्लाउड-साइड क्लस्टर कमांडर के साथ-साथ, फ़ायरवॉल के पीछे मौजूद होस्ट (इनग्रेस कनेक्शन के लिए) के साथ काम कर सकता है. हो सकता है कि किसी अन्य डिज़ाइन (पुश-आधारित सी&सी मॉडल) की वजह से, क्लाउड कमांडर को निजी नेटवर्क में होस्ट कंप्यूटर पर मौजूद होस्ट कंट्रोलर इंस्टेंस को ऐक्सेस करने की अनुमति न मिले.
इस पेज पर मौजूद कॉन्टेंट और कोड सैंपल कॉन्टेंट के लाइसेंस में बताए गए लाइसेंस के हिसाब से हैं. Java और OpenJDK, Oracle और/या इससे जुड़ी हुई कंपनियों के ट्रेडमार्क या रजिस्टर किए हुए ट्रेडमार्क हैं.
आखिरी बार 2025-07-27 (UTC) को अपडेट किया गया.
[[["समझने में आसान है","easyToUnderstand","thumb-up"],["मेरी समस्या हल हो गई","solvedMyProblem","thumb-up"],["अन्य","otherUp","thumb-up"]],[["वह जानकारी मौजूद नहीं है जो मुझे चाहिए","missingTheInformationINeed","thumb-down"],["बहुत मुश्किल है / बहुत सारे चरण हैं","tooComplicatedTooManySteps","thumb-down"],["पुराना","outOfDate","thumb-down"],["अनुवाद से जुड़ी समस्या","translationIssue","thumb-down"],["सैंपल / कोड से जुड़ी समस्या","samplesCodeIssue","thumb-down"],["अन्य","otherDown","thumb-down"]],["आखिरी बार 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."]]
