पता असाइनमेंट

खास जानकारी

परिचय:

इंटरफ़ेस के बीच कई तरह की इंटर-डिपेंडेंसी होती हैं. इसलिए, अलग-अलग डिवाइस कॉन्फ़िगरेशन के लिए अलग टीसीपी/आईपी पते और रूट असाइनमेंट की ज़रूरत हो सकती है. इसलिए, यह ज़रूरी था कि आईपी पते को कंट्रोल करने वाले लॉजिक और रूट असाइनमेंट को एक ही मॉड्यूल में रखा जाए. WARM, टीसीपी/आईपी पतों और Weave से जुड़े आईपी इंटरफ़ेस के रूट को ठीक से जोड़ने और हटाने के लिए काम करता है, क्योंकि ये इंटरफ़ेस सक्रिय<->बंद होते हैं.

WARM को, वॉर्मProjectConfig.h और WarmConfig.h के ज़रिए कंपाइलेशन के समय कॉन्फ़िगर किया जाना है. वॉर्मप्रोजेक्टConfig.h को डिवाइस के साथ काम करने वाली उन सुविधाओं की सटीक जानकारी दिखानी चाहिए जिन पर WARM काम करेगा.

डब्ल्यूआरएम एक पोर्टेबल मॉड्यूल है. यह टीसीपी/आईपी स्टैक और थ्रेड इंटरफ़ेस को कॉन्फ़िगर करने के तरीके पर अपनी डिपेंडेंसी को सीमित करता है. इस मकसद से, WARM, प्लैटफ़ॉर्म एपीआई के सेट पर निर्भर करता है, जिसे प्लैटफ़ॉर्म इंटिग्रेटर को लागू करना होगा. इसके अलावा, प्लैटफ़ॉर्म इंटिग्रेटर, प्लैटफ़ॉर्म कोड बेस में सही एक्ज़ीक्यूशन पॉइंट से कई nl::Warm API कॉल करने के लिए ज़िम्मेदार है.

ऑपरेशन का सिद्धांत:

प्लैटफ़ॉर्म कोड बेस, nl::Warm API' को कॉल करेगा. इससे, वाई-फ़ाई इंटरफ़ेस और Thread इंटरफ़ेस जैसी मिलती-जुलती सुविधाओं की स्थिति में बदलाव का एलान किया जाएगा. इनमें से किसी भी nl::Warm API का इस्तेमाल करने पर WARM से प्लैटफ़ॉर्म::RequestInvokeAction() पर कॉल किया जा सकता है. प्लैटफ़ॉर्म::RequestInvokeactions() को लागू करना ज़रूरी है, ताकि ऐसे काम किए जा सकें जिनसे Warm::InvokeActions() कॉल किए जा सकें. पहली नज़र में यह प्रोसेस सीधे तौर पर अनजान लग सकती है. WARM, InvokeAction को सीधे तौर पर कॉल क्यों नहीं करेगा? इस सवाल का जवाब यह है कि एक से ज़्यादा काम करने वाले सिस्टम में किसी भी टास्क को nl::Warm State Change API को कॉल करने की अनुमति दी जा सकती है और एक ऐसा तरीका दिया जा सकता है जिससे सिर्फ़ कोई खास काम प्लैटफ़ॉर्म:: API को कॉल करे. प्लैटफ़ॉर्म की ज़रूरी शर्तों को ध्यान में रखते हुए, प्लैटफ़ॉर्म इंटीग्रेटर प्लैटफ़ॉर्म::RequestInvokeActions() लागू करना चुन सकता है, ताकि वह सही टास्क के लिए कोई इवेंट पोस्ट करे. यह टास्क Warm::InvokeActions() कॉल करके प्रतिक्रिया देगा. अगर किसी प्लैटफ़ॉर्म के लिए यह तय होता है कि एक से ज़्यादा काम करने वाली ऐसी कोई समस्या मौजूद नहीं है, तो Platform::RequestInvokeAction() को सीधे ActionsInvoke(): कॉल करने के लिए लागू किया जा सकता है.

जब Warm::InvokeAction() को कॉल किया जाता है, तो WARM लॉजिक मौजूदा सिस्टम की स्थिति की जांच करेगा और कोई भी ज़रूरी प्लैटफ़ॉर्म:: एपीआई कॉल करेगा, ताकि पते और रूटिंग की स्थिति को सिस्टम और कॉन्फ़िगरेशन की स्थिति के मुताबिक बनाया जा सके. ये कॉल पहले से तय किए गए क्रम में किए जाते हैं. साथ ही, अगर इनमें से कोई भी एपीआई, kPlatformresultsInPro दावा करता है, तो क्रम वाली सूची का एक्ज़ीक्यूशन निलंबित हो जाएगा और वह बंद हो जाएगा. इसके अलावा, जब इनमें से कोई एपीआई, kPlatformresultsInPro दावा करता है, तो यह माना जाता है कि कार्रवाई एसिंक्रोनस तरीके से पूरी होगी. साथ ही, WARM लॉजिक को उस कार्रवाई के पूरा होने का इंतज़ार करना चाहिए. कार्रवाई पूरी हो जाने के बाद, प्लैटफ़ॉर्म कोड को Warm::ReportActionComplete() को कॉल करना चाहिए, जो kPlatformनतीजे या kPlatformresultsFailure के नतीजे में पास होता है. यह कॉल मिलने के बाद WARM लॉजिक, Platform::RequestInvokeActions() को फिर से कॉल करेगा, ताकि क्रम वाली कार्रवाई सूची को फिर से चलाया जा सके.

इस तरह, डब्ल्यूआरएम को अपने टास्क की ज़रूरत नहीं होती. इसके बजाय, वह वॉर्म को ज़रूरत के मुताबिक कॉल करने के लिए किसी दूसरे टास्क पर भरोसा कर सकता है. इसके अलावा, कोई भी टास्क एक या उससे ज़्यादा System State Change API को कॉल कर सकता है. इससे इंटिग्रेशन आसान हो जाता है.