यह लेख एक महीने पहले प्रकाशित एक प्रतिबिंब लेख की एक निरंतरता है, " क्या पुराने ढांचे में नई सुविधाओं को जोड़ना आसान है? सोबिजाइज़र के विकास के उदाहरण के आधार पर पसंद की पीड़ा "। उस लेख में उस कार्य का वर्णन किया गया था जिसे हम SObjectizer के अगले संस्करण में हल करना चाहते थे, इसके समाधान के लिए दो दृष्टिकोणों की जांच की और प्रत्येक दृष्टिकोण के फायदे और नुकसान को सूचीबद्ध किया।

जैसे-जैसे समय बीतता गया, दृष्टिकोणों में से एक को लागू किया गया और SObjectizer के नए संस्करणों, साथ ही साथ परियोजना so_5_extra , पहले से ही " गहरी साँस लेने " कहा जाता है। आप सचमुच ले सकते हैं और कोशिश कर सकते हैं।

आज हम बात करेंगे कि क्या किया गया, क्यों किया गया, इसके कारण क्या हुआ। यदि कोई यह जानने में रुचि रखता है कि C ++ के लिए कुछ लाइव, क्रॉस-प्लेटफॉर्म और ओपन एक्टर फ्रेमवर्क में से एक कैसे विकसित हो रहा है, तो आपको बिल्ली के लिए स्वागत है।

यह सब कैसे शुरू हुआ?

यह सभी टाइमर की गारंटी रद्द करने की समस्या को हल करने के प्रयास के साथ शुरू हुआ। समस्या का सार यह है कि जब देरी या आवधिक संदेश भेजा जाता है, तो प्रोग्रामर संदेश की डिलीवरी को रद्द कर सकता है। उदाहरण के लिए:

auto timer_id = so_5::send_periodic<my_message>(my_agent, 10s, 10s, ...); ... // - . // ,    my_message    . timer_id.release(); //      my_message.

टाइमर_आईडी.release () कॉल करने के बाद , टाइमर अब my_message संदेश के नए इंस्टेंस नहीं भेजेगा। लेकिन जो प्रतियाँ पहले ही भेजी जा चुकी हैं और प्राप्तकर्ताओं की कतार में हैं वे कहीं नहीं जाएँगी। समय के साथ, उन्हें इन समान कतारों से निकाला जाएगा और प्रसंस्करण के लिए प्राप्तकर्ता एजेंटों को स्थानांतरित किया जाएगा।

यह समस्या SObjectizer-5 के संचालन के मूल सिद्धांतों का एक परिणाम है और इस तथ्य के कारण एक सरल समाधान नहीं है कि SObjectizer संदेशों को कतारों से नहीं निकाल सकता है। यह इसलिए नहीं हो सकता क्योंकि SObjectizer में कतार डिस्पैचर से संबंधित हैं, डिस्पैचर अलग-अलग हैं, उनकी कतारें भी अलग-अलग आयोजित की जाती हैं। इसमें डिस्पैचर भी शामिल हैं जो एसओबीजेनाइजर का हिस्सा नहीं हैं, और एसओबीजेनाइजर, सिद्धांत रूप में, यह नहीं जान सकते कि ये डिस्पैचर कैसे काम करते हैं।

सामान्य तौर पर, मूल SObjectizer टाइमर में ऐसी सुविधा होती है। ऐसा नहीं है कि यह डेवलपर्स को बहुत खराब करता है। लेकिन कुछ अतिरिक्त देखभाल की जानी चाहिए। विशेष रूप से शुरुआती लोगों के लिए जो सिर्फ रूपरेखा से परिचित हो रहे हैं।

और फिर, आखिरकार, इस समस्या के समाधान की पेशकश करने के लिए हाथ चले गए।

कौन सा समाधान पथ चुना गया था?

पिछले लेख में , दो संभावित विकल्पों पर विचार किया गया था। पहले विकल्प को SObjectizer में संदेश वितरण तंत्र में संशोधन की आवश्यकता नहीं थी, लेकिन प्रोग्रामर को भेजे गए / प्राप्त संदेश के प्रकार को स्पष्ट रूप से बदलने की आवश्यकता थी।

दूसरा विकल्प SObjectizer संदेश वितरण तंत्र के संशोधन की आवश्यकता है। यह इस मार्ग को चुना गया था, क्योंकि इसने संदेश के प्राप्तकर्ता से इस तथ्य को छिपाने की अनुमति दी थी कि संदेश कुछ विशिष्ट तरीके से भेजा गया था।

SObjectizer में क्या बदलाव आया है?

नई अवधारणा: अंदर संदेश के साथ लिफाफा

कार्यान्वित समाधान का पहला घटक एसबिजाइज़र के लिफाफे के रूप में इस तरह की अवधारणा के अतिरिक्त है। एक लिफाफा एक विशेष संदेश है, जिसके अंदर वर्तमान संदेश (पेलोड) निहित है। SObjectizer लगभग सामान्य तरीके से प्राप्तकर्ता को संदेश के साथ लिफाफा वितरित करता है। लिफाफा प्रसंस्करण में मूलभूत अंतर केवल डिलीवरी के अंतिम चरण में पाया जाता है:

एक नियमित संदेश के वितरण पर, प्राप्तकर्ता एजेंट बस इस प्रकार के संदेश के लिए एक हैंडलर की तलाश करता है और, यदि ऐसा हैंडलर पाया जाता है, तो पाया गया हैंडलर कहा जाता है और डिलीवर किए गए संदेश को एक पैरामीटर के रूप में लौटाया जाता है;
और हैंडलर मिलने के बाद संदेश के साथ लिफाफे का वितरण, पहले संदेश को लिफाफे से बाहर निकालने का प्रयास किया जाता है। और केवल अगर लिफाफे ने इसमें संग्रहीत संदेश दिया, तभी हैंडलर कहा जाता है।

यहां दो प्रमुख बिंदु हैं जो एक प्रमुख प्रभाव है कि क्यों और कैसे संदेश लिफाफे का उपयोग किया जा सकता है।

पहला मुख्य बिंदु यह है कि एक संदेश लिफाफे से केवल तभी अनुरोध किया जाता है जब एक संदेश हैंडलर प्राप्तकर्ता पर पाया जाता है। यानी केवल तभी जब संदेश वास्तव में प्राप्तकर्ता को दिया गया हो और प्राप्तकर्ता यहीं होगा और अब इस संदेश को संसाधित करेगा।

यहाँ दूसरा मुख्य बिंदु यह है कि लिफाफा इसमें संदेश नहीं दे सकता है। अर्थात्, उदाहरण के लिए, एक लिफाफा वर्तमान समय की जांच कर सकता है और यह तय कर सकता है कि सभी वितरण तिथियां छूट गई हैं और इसलिए, संदेश प्रासंगिक होना बंद हो गया है और संसाधित नहीं किया जा सकता है। इसलिए, लिफाफा संदेश को बाहर नहीं देगा। तदनुसार, SObjectizer केवल इस लिफाफे की उपेक्षा करेगा और कोई अतिरिक्त कार्रवाई नहीं करेगा।

लिफाफा कैसा होता है?

एक लिफाफा लिफाफे_टी इंटरफ़ेस का कार्यान्वयन है, जिसे निम्नानुसार परिभाषित किया गया है:

 class SO_5_TYPE envelope_t : public message_t { public: ... // -. //   ,       //    . virtual void handler_found_hook( handler_invoker_t & invoker ) noexcept = 0; //   ,      //     . virtual void transformation_hook( handler_invoker_t & invoker ) noexcept = 0; private : kind_t so5_message_kind() const noexcept override { return kind_t::enveloped_msg; } };

यानी एक लिफाफा अनिवार्य रूप से सभी के समान संदेश है। लेकिन एक विशेष विशेषता के साथ, जिसे so5_message_kind () विधि द्वारा लौटाया जाता है।

प्रोग्रामर लिफ़ाफ़े_ t (या, और अधिक आसानी से, so_5 :: extra :: लिफाफा_msg :: just_envelope_t ) से विरासत में मिले अपने लिफाफे विकसित कर सकता है और हुक विधियों हैंडलर_फाउंड_बूक () और परिवर्तन_हूक () से आगे निकल सकता है।

हुक विधियों के अंदर, लिफाफा डेवलपर यह तय करता है कि वह लिफाफे के अंदर प्रसंस्करण / परिवर्तन के लिए संदेश देना चाहता है या नहीं। यदि वह चाहता है, तो डेवलपर को इनवोक () विधि और इनवोकर ऑब्जेक्ट को कॉल करना होगा। यदि वह नहीं चाहता है, तो वह कॉल नहीं करता है, इस मामले में लिफाफा और उसकी सामग्री को नजरअंदाज कर दिया जाएगा।

लिफाफे कैसे रद्द करने की समस्या को हल करते हैं?

समाधान, जिसे अब so_5_extra में so_5 :: extra :: revocable_timer नाम स्थान के रूप में लागू किया जाता है, बहुत सरल है: एक लंबित या आवधिक संदेश का विशेष भेज एक विशेष लिफाफा बनाता है, जिसके अंदर न केवल संदेश स्थित है, बल्कि परमाणु ध्वज भी निरस्त है। यदि यह ध्वज साफ़ हो जाता है, तो संदेश प्रासंगिक माना जाता है। यदि सेट किया जाता है, तो संदेश वापस ले लिया जाता है।

जब हुक विधि को लिफाफे पर बुलाया जाता है, तो लिफाफा निरस्त ध्वज के मूल्य की जांच करता है। यदि ध्वज सेट है, तो लिफाफा एक संदेश नहीं देता है। इस प्रकार, संदेश को संसाधित नहीं किया जाता है भले ही टाइमर पहले से ही रिसीवर की कतार में संदेश डालने में कामयाब हो।

इंटरफ़ेस एक्सटेंशन abstract_message_box_t

लिफाफे_टी इंटरफ़ेस को जोड़ना SObjectizer में लिफाफे के कार्यान्वयन का सिर्फ एक हिस्सा है। दूसरा हिस्सा सोबजेनाइज़र के अंदर संदेश वितरण तंत्र में लिफाफों के अस्तित्व के तथ्य को ध्यान में रख रहा है।

यहां, दुर्भाग्य से, उपयोगकर्ता के लिए दृश्यमान बदलाव किए बिना नहीं कर सका। विशेष रूप से, क्लास एब्स्ट्रैक्ट_मेसेज_बॉक्स_टी में, जो सोबिजाइज़र के सभी मेलबॉक्सेस के इंटरफ़ेस को परिभाषित करता है, एक और वर्चुअल विधि जोड़ना आवश्यक था:

 virtual void do_deliver_enveloped_msg( const std::type_index & msg_type, const message_ref_t & message, unsigned int overlimit_reaction_deep );

यह विधि एक संदेश लिफाफे को संदेश के साथ संदेश भेजने के लिए ज़िम्मेदार है, जो कि रिसीवर को msg_type का संदेश देता है। इस तरह की डिलीवरी कार्यान्वयन के विवरण में भिन्न हो सकती है जो इस बात पर निर्भर करता है कि यह किस प्रकार का है।

Do_deliver_enveloped_msg () को abstract_message_box_t में जोड़ने पर, हमारे पास एक विकल्प था: इसे एक शुद्ध आभासी विधि बनाने या कुछ डिफ़ॉल्ट कार्यान्वयन की पेशकश करने के लिए।

यदि हमने do_deliver_enveloped_msg () एक शुद्ध आभासी विधि बनाई है, तो हम शाखा 5.5 में SObjectizer के संस्करणों के बीच संगतता को तोड़ देंगे। आखिरकार, फिर उन उपयोगकर्ताओं को जिन्होंने अपने स्वयं के एमबॉक्स कार्यान्वयन को लिखा था, उन्हें अपने स्वयं के बॉक्स को संशोधित करना होगा, जब वे एसओबीजेनाइज़र-5.5.23 पर स्विच करेंगे, अन्यथा वे एसओबीजेनाइज़र के नए संस्करण के साथ संकलन नहीं कर पाएंगे।

हम यह नहीं चाहते थे, इसलिए हमने v.5.5.23 में do_deliver_enveloped_msg () को शुद्ध आभासी विधि नहीं बनाया। इसका एक डिफ़ॉल्ट कार्यान्वयन है जो केवल एक अपवाद को फेंकता है। इस प्रकार, कस्टम उपयोगकर्ता एमबॉक्स-एस नियमित संदेशों के साथ सामान्य रूप से काम करना जारी रखने में सक्षम होगा, लेकिन स्वचालित रूप से लिफाफे स्वीकार करने से इनकार कर देगा। हमें यह व्यवहार अधिक स्वीकार्य लगा। इसके अलावा, प्रारंभिक चरण में, संदेशों वाले लिफाफे का व्यापक रूप से उपयोग किए जाने की संभावना नहीं है, और यह संभावना नहीं है कि SObjectizer बॉक्स के "जंगली" कस्टम कार्यान्वयन अक्सर पाए जाते हैं;)

इसके अलावा, एक शून्य अवसर से बहुत दूर है कि SObjectizer के बाद के प्रमुख संस्करणों में, जहां हम शाखा 5.5 के साथ संगतता को नहीं देखेंगे, abstract_message_box_t इंटरफ़ेस प्रमुख परिवर्तनों से गुजरना होगा। लेकिन हम पहले से ही खुद से आगे निकल रहे हैं ...

संदेशों के साथ लिफाफे कैसे भेजें

SObjectizer-5.5.23 ही लिफाफे भेजने का एक सरल साधन प्रदान नहीं करता है। यह माना जाता है कि एक विशिष्ट प्रकार के लिफाफे और उपयुक्त उपकरण एक विशिष्ट प्रकार के लिफाफे को आसानी से भेजने के लिए एक विशिष्ट कार्य के लिए विकसित किए जा रहे हैं। इसका एक उदाहरण so_5 :: extra :: revocable_timer में देखा जा सकता है, जहाँ आपको न केवल लिफाफा भेजना होगा, बल्कि उपयोगकर्ता को एक विशेष टाइमर_ड भी देना होगा।

सरल स्थितियों के लिए, आप so_5 :: अतिरिक्त :: covered_msg से टूल का उपयोग कर सकते हैं। उदाहरण के लिए, यह संदेश दिया जाता है कि उसके वितरण समय पर एक निर्दिष्ट सीमा के साथ संदेश कैसे भेजा जाता है:

 // make     . so_5::extra::enveloped_msg::make<my_message>(... /*    */) // envelope         . //  5s        . .envelope<so_5::extra::enveloped_msg::time_limited_delivery_t>(5s) //        . .send_to(destination);

यह सब मजेदार बनाने के लिए: लिफाफे में लिफाफे

लिफाफे कुछ संदेशों को अपने अंदर ले जाने के लिए डिज़ाइन किए गए हैं। लेकिन कौन से?

किसी भी।

और यह हमें एक दिलचस्प सवाल पर लाता है: क्या एक लिफाफे को दूसरे लिफाफे के अंदर रखना संभव है?

हाँ आप कर सकते हैं। जितना आपको पसंद है। घोंसले की गहराई केवल डेवलपर के सामान्य ज्ञान और पुनरावर्ती कॉल हैंडलर_फाउंड_हूक / परिवर्तन_हूक के लिए स्टैक की गहराई तक सीमित है।

उसी समय, SObjectizer अपने स्वयं के लिफाफे के डेवलपर्स की ओर जाता है: लिफाफे को यह नहीं सोचना चाहिए कि इसके अंदर क्या है - एक विशिष्ट संदेश या दूसरा लिफाफा। जब लिफाफे पर हुक विधि को बुलाया जाता है और लिफाफा यह तय करता है कि वह अपनी सामग्री दे सकता है, तो लिफाफा केवल हैंडलर_invoker_t पर इनवोक () कॉल करता है और इनवोक में अपनी सामग्री के लिए एक लिंक पारित करता है ()। और पहले से ही आह्वान () अंदर यह पता लगाएगा कि यह क्या व्यवहार कर रहा है। और अगर यह एक और लिफाफा है, तो आह्वान () खुद इस लिफाफे पर आवश्यक हुक विधि को बुलाएगा।

ऊपर दिखाए गए टूलकिट का उपयोग करके so_5 :: अतिरिक्त :: लिफाफा_msg उपयोगकर्ता इस तरह कई नेस्टेड लिफाफे बना सकता है:

 so_5::extra::enveloped_msg::make<my_message>(...) // ,        my_message. .envelope<inner_envelope_type>(...) // ,      inner_envelope_type. .envelope<outer_envelope_type>(...) .send_to(destination);

लिफाफे के उपयोग के कुछ उदाहरण

अब, जब हम SObjectizer-5.5.23 के इंटर्न के माध्यम से चले हैं, तो यह उपयोगकर्ताओं के लिए अधिक उपयोगी एप्लिकेशन पार्ट पर आगे बढ़ने का समय है। नीचे कुछ उदाहरण दिए गए हैं जो या तो पहले से ही so_5_extra में लागू किए गए हैं, या so_5_extra से टूल का उपयोग करते हैं।

निरर्थक समय

चूंकि लिफाफे के साथ इस पूरे रसोईघर की कल्पना टाइमर संदेशों की गारंटी की समस्या को हल करने के लिए की गई थी, आइए देखें कि अंत में क्या हुआ। हम so_5_extra-1.2.0 से उदाहरण का उपयोग करेंगे, जो नए so_5 :: अतिरिक्त :: revocable_timer नाम स्थान से उपकरण का उपयोग करता है:

रिवोकेबल टाइमर के साथ उदाहरण कोड

 #include <so_5_extra/revocable_timer/pub.hpp> #include <so_5/all.hpp> namespace timer_ns = so_5::extra::revocable_timer; class example_t final : public so_5::agent_t { //  ,       //    . struct first_delayed final : public so_5::signal_t {}; struct second_delayed final : public so_5::signal_t {}; struct last_delayed final : public so_5::signal_t {}; struct periodic final : public so_5::signal_t {}; //    . timer_ns::timer_id_t m_first; timer_ns::timer_id_t m_second; timer_ns::timer_id_t m_last; timer_ns::timer_id_t m_periodic; public : example_t( context_t ctx ) : so_5::agent_t{ std::move(ctx) } { so_subscribe_self() .event( &example_t::on_first_delayed ) .event( &example_t::on_second_delayed ) .event( &example_t::on_last_delayed ) .event( &example_t::on_periodic ); } void so_evt_start() override { using namespace std::chrono_literals; //      ... m_first = timer_ns::send_delayed< first_delayed >( *this, 100ms ); m_second = timer_ns::send_delayed< second_delayed >( *this, 200ms ); m_last = timer_ns::send_delayed< last_delayed >( *this, 300ms ); // ...    . m_periodic = timer_ns::send_periodic< periodic >( *this, 75ms, 75ms ); //    220ms.       //    first_delaye, second_delayed  //    periodic. std::cout << "hang the agent..." << std::flush; std::this_thread::sleep_for( 220ms ); std::cout << "done" << std::endl; } private : void on_first_delayed( mhood_t<first_delayed> ) { std::cout << "first_delayed received" << std::endl; //   second_delayed  periodic. //          ,  //       . m_second.revoke(); m_periodic.revoke(); } void on_second_delayed( mhood_t<second_delayed> ) { std::cout << "second_delayed received" << std::endl; } void on_last_delayed( mhood_t<last_delayed> ) { std::cout << "last_delayed received" << std::endl; so_deregister_agent_coop_normally(); } void on_periodic( mhood_t<periodic> ) { std::cout << "periodic received" << std::endl; } }; int main() { so_5::launch( [](so_5::environment_t & env) { env.register_agent_as_coop( "example", env.make_agent<example_t>() ); } ); return 0; }

हमारे यहाँ क्या है?

हमारे पास एक एजेंट है जो पहले कई टाइमर संदेशों को शुरू करता है, और फिर थोड़ी देर के लिए अपने काम के धागे को अवरुद्ध करता है। इस समय के दौरान, टाइमर ट्रिगर किए गए टाइमर के परिणामस्वरूप एजेंट को कई अनुरोधों को पंक्तिबद्ध करने का प्रबंधन करता है: कई आवधिक उदाहरण, एक first_delayed और दूसरा_delayed प्रत्येक।

तदनुसार, जब कोई एजेंट अपना धागा अनलॉक करता है, तो उसे पहले आवधिक और first_delayed प्राप्त करना चाहिए। First_delayed को संसाधित करते समय, एजेंट आवधिक और second_delayed के वितरण को रद्द कर देता है। इसलिए, ये संकेत एजेंट तक नहीं पहुंचने चाहिए, चाहे वे पहले से ही एजेंट की कतार में हों या नहीं (और वे हैं)।

हम उदाहरण के परिणाम को देखते हैं:

 hang the agent...done periodic received first_delayed received last_delayed received

हाँ, यह है। पहला आवधिक और First_delayed मिला। फिर न तो आवधिक है और न ही दूसरा_दिलयेद।

लेकिन यदि उदाहरण में हम so_5 से "टाइमर" की जगह लेते हैं :: अतिरिक्त :: Revocable_timer SObjectizer से मानक टाइमर के साथ, तो परिणाम अलग-अलग होगा: पहले से ही एजेंट की कतार में प्रवेश करने वाले आवधिक और second_deleded संकेतों के सभी उदाहरण एजेंट तक पहुंच जाएंगे।

डिलीवरी का समय प्रतिबंधित संदेश

एक और उपयोगी, कई बार, वह चीज जो so_5_extra-1.2.0 में उपलब्ध हो जाएगी, वह समय सीमा के साथ संदेश वितरण है। उदाहरण के लिए, request_handler एजेंट crypto_master एजेंट को एक Ver_signature संदेश भेजता है। उसी समय, request_handler 5 सेकंड के भीतर verify_signature पर पहुंचना चाहता है। यदि ऐसा नहीं होता है, तो verity_signature प्रसंस्करण में कोई मतलब नहीं होगा, request_handler एजेंट अपना काम पहले ही रोक देगा।

और क्रिप्टो_मास्टर एजेंट एक ऐसा कॉमरेड है जो एक "अड़चन" होना पसंद करता है: कई बार वह धीमा होना शुरू कर देता है। ऐसे क्षण में, कतार में संदेश जमा हो जाते हैं, जैसे कि ऊपर Ver_signature, जो तब तक प्रतीक्षा कर सकता है जब तक कि crypto_master को राहत नहीं मिल जाती।

मान लीजिए कि request_handler ने crypto_master एजेंट को एक Ver_signature संदेश भेजा है, लेकिन फिर crypto_master बहुत चकरा गया और यह 10 सेकंड के लिए अटक गया। अनुरोध_हैंडलर एजेंट पहले से ही "गिर गया" है, अर्थात्। पहले ही सभी को सेवा से वंचित कर दिया और अपना काम पूरा कर लिया। लेकिन Ver_signature संदेश crypto_master कतार में बना हुआ है! इसलिए, जब क्रिप्टो_मास्टर "अनस्टिक्स", यह संदेश ले जाएगा और इस संदेश को संसाधित करेगा। हालांकि यह अब जरूरी नहीं है।

नए लिफाफे का उपयोग करना so_5 :: अतिरिक्त :: लिफाफा_msg :: time_limited_delivery_t, हम इस समस्या को हल कर सकते हैं: request_handler एजेंट सत्यापन_ भेज देगा time_limited_delivery_t एक डिलीवरी समय सीमा के साथ लिफाफे में संलग्न:

 so_5::extra::enveloped_msg::make<verify_signature>(...) .envelope<so_5::extra::enveloped_msg::time_limited_delivery_t>(5s) .send_to(crypto_master_mbox);

अब अगर crypto_master "चिपक जाता है" और 5 सेकंड में Ver_signature पर पहुंचने का प्रबंधन नहीं करता है, तो लिफाफा बस इस संदेश को प्रसंस्करण के लिए नहीं भेजेगा। और crypto_master वह काम नहीं करेगा जिसकी किसी और को जरूरत नहीं है।

प्राप्तकर्ता वितरण रिपोर्ट

और अंत में, एक जिज्ञासु चीज का एक उदाहरण जो नियमित रूप से या तो SObjectizer में लागू नहीं होता है या so_5_extra, लेकिन जो स्वतंत्र रूप से किया जा सकता है।

कभी-कभी आप प्राप्तकर्ता को "डिलीवरी रिपोर्ट" संदेश की तरह कुछ विशेषण से प्राप्त करना चाहते हैं। आखिरकार, यह एक बात है जब संदेश प्राप्तकर्ता तक पहुंच गया, लेकिन किसी कारण से प्राप्तकर्ता ने इसका जवाब नहीं दिया। एक और बात यह है कि संदेश प्राप्तकर्ता तक बिल्कुल नहीं पहुंचा। उदाहरण के लिए, यह एक एजेंट अधिभार संरक्षण तंत्र द्वारा अवरुद्ध किया गया था। पहले मामले में, एक संदेश जिसके लिए हमने उत्तर की प्रतीक्षा नहीं की थी, छोड़ा जा सकता है। लेकिन दूसरे मामले में, कुछ समय के बाद संदेश को फिर से भेजने का कोई मतलब हो सकता है।

अब हम विचार करेंगे कि लिफाफे का उपयोग करके "वितरण रिपोर्ट" का सबसे सरल तंत्र कैसे लागू किया जा सकता है।

इसलिए, पहले हम आवश्यक प्रारंभिक कदम उठाते हैं:

 #include <so_5_extra/enveloped_msg/just_envelope.hpp> #include <so_5_extra/enveloped_msg/send_functions.hpp> #include <so_5/all.hpp> using namespace std::chrono_literals; namespace envelope_ns = so_5::extra::enveloped_msg; using request_id_t = int;

अब हम उन संदेशों को परिभाषित कर सकते हैं जिनका उपयोग उदाहरण में किया जाएगा। पहला संदेश कुछ कार्यों को करने का अनुरोध है, जिनकी हमें आवश्यकता है। और दूसरा संदेश एक पुष्टि है कि पहला संदेश प्राप्तकर्ता तक पहुंच गया है:

 struct request_t final { request_id_t m_id; std::string m_data; }; struct delivery_receipt_t final { //   request_t::m_id   request_t. request_id_t m_id; };

अगला, हम एक एजेंट processor_t को परिभाषित कर सकते हैं जो टाइप request_t के संदेशों को संसाधित करेगा। लेकिन प्रसंस्करण "चिपके हुए" की नकल के साथ होगा। यानी यह request_t को संसाधित करता है, जिसके बाद यह अपने राज्य को st_normal से st_busy में बदल देता है। St_busy अवस्था में, यह कुछ भी नहीं करता है और इसके लिए आने वाले सभी संदेशों को अनदेखा करता है।

इसका मतलब है कि यदि प्रोसेसर_t एजेंट लगातार तीन अनुरोध_ संदेश भेजता है, तो यह पहले एक को संसाधित करेगा और अन्य दो को छोड़ दिया जाएगा, क्योंकि पहले संदेश को संसाधित करते समय, एजेंट st_busy पर जाएगा और नजरअंदाज कर देगा कि st_busy में होने पर उसे क्या करना होगा।

St_busy में, agent processor_t 2 सेकंड खर्च करेगा, जिसके बाद यह फिर से st_normal पर वापस आ जाएगा और नए संदेशों को संसाधित करने के लिए तैयार होगा।

यहां ऐसा क्या है जैसे कि processor_t एजेंट दिखता है:

 class processor_t final : public so_5::agent_t { //   .     //   . state_t st_normal{this, "normal"}; //  " ".   . state_t st_busy{this, "busy"}; public: processor_t(context_t ctx) : so_5::agent_t{std::move(ctx)} { this >>= st_normal; st_normal.event(&processor_t::on_request); //     ,    . //  2   ,    st_normal. st_busy.time_limit(2s, st_normal); } private: void on_request(mhood_t<request_t> cmd) { std::cout << "processor: on_request(" << cmd->m_id << ", " << cmd->m_data << ")" << std::endl; this >>= st_busy; } };

अब हम एजेंट request_generator_t को परिभाषित कर सकते हैं, जिसमें उन अनुरोधों का एक समूह है, जिन्हें प्रोसेसर_ टी तक पहुंचाने की आवश्यकता है। Request_generator_t एजेंट पूरे 3 सेकंड में पूरे पैकेट को भेजता है, और फिर delivery_receipt_t के रूप में वितरण की पुष्टि का इंतजार करता है।

जब delivery_recept_t आता है, तो request_generator_t एजेंट वितरित अनुरोध को बंडल से बाहर फेंक देता है। यदि पैक पूरी तरह से खाली है, तो उदाहरण पूरा हो गया है। यदि कुछ और शेष रहता है, तो शेष पैकेट अगली बार फिर से भेजा जाएगा।

तो यहाँ request_generator_t एजेंट कोड है। यह काफी स्वैच्छिक है, लेकिन आदिम है। आप केवल send_requests () विधि के आंतरिक पर ध्यान दे सकते हैं, जिसमें request_t संदेश भेजे जाते हैं, जो एक विशेष लिफाफे में संलग्न हैं।

Request_generator_t एजेंट कोड

 class requests_generator_t final : public so_5::agent_t { //    . const so_5::mbox_t m_processor; //  ,       . std::map<request_id_t, std::string> m_requests; struct resend_requests final : public so_5::signal_t {}; public: requests_generator_t(context_t ctx, so_5::mbox_t processor) : so_5::agent_t{std::move(ctx)} , m_processor{std::move(processor)} { so_subscribe_self() .event(&requests_generator_t::on_delivery_receipt) .event(&requests_generator_t::on_resend); } void so_evt_start() override { //    . m_requests.emplace(0, "First"); m_requests.emplace(1, "Second"); m_requests.emplace(2, "Third"); m_requests.emplace(3, "Four"); //  . send_requests(); } private: void on_delivery_receipt(mhood_t<delivery_receipt_t> cmd) { std::cout << "request delivered: " << cmd->m_id << std::endl; m_requests.erase(cmd->m_id); if(m_requests.empty()) //    .  . so_deregister_agent_coop_normally(); } void on_resend(mhood_t<resend_requests>) { std::cout << "time to resend requests, pending requests: " << m_requests.size() << std::endl; send_requests(); } void send_requests() { for(const auto & item : m_requests) { std::cout << "sending request: (" << item.first << ", " << item.second << ")" << std::endl; envelope_ns::make<request_t>(item.first, item.second) .envelope<custom_envelope_t>(so_direct_mbox(), item.first) .send_to(m_processor); } //       3 . so_5::send_delayed<resend_requests>(*this, 3s); } };

अब हमारे पास संदेश और एजेंट हैं जिन्हें संचार करने के लिए इन संदेशों का उपयोग करना चाहिए। केवल एक छोटी सी चीज बची थी - किसी भी तरह से delivery_receipt_t संदेश बनाते समय प्रोसेसर_t को request_t भेजते समय।

यह इस लिफाफे का उपयोग करके किया गया है:

 class custom_envelope_t final : public envelope_ns::just_envelope_t { //     . const so_5::mbox_t m_to; // ID  . const request_id_t m_id; public: custom_envelope_t(so_5::message_ref_t payload, so_5::mbox_t to, request_id_t id) : envelope_ns::just_envelope_t{std::move(payload)} , m_to{std::move(to)} , m_id{id} {} void handler_found_hook(handler_invoker_t & invoker) noexcept override { //    ,     . //     . so_5::send<delivery_receipt_t>(m_to, m_id); //      . envelope_ns::just_envelope_t::handler_found_hook(invoker); } };

सामान्य तौर पर, कुछ भी जटिल नहीं है। हम so_5 से विरासत में लेते हैं :: अतिरिक्त :: लिफाफा_msg :: just_envelope_t। यह एक सहायक प्रकार का लिफाफा है जो इसमें संलग्न संदेश को संग्रहीत करता है और हुक
हैंडलर_फाउंड_हूक () और परिवर्तन_हूक () का मूल कार्यान्वयन प्रदान करता है । इसलिए, हम केवल उन विशेषताओं को सहेज सकते हैं जो हमें custom_envelope_t के अंदर चाहिए और hand_found_hook () हुक के अंदर delivery_receipt_t भेजें।

वह, वास्तव में, सब है। यदि हम इस उदाहरण को चलाते हैं, तो हमें निम्नलिखित मिलते हैं:

 sending request: (0, First) sending request: (1, Second) sending request: (2, Third) sending request: (3, Four) processor: on_request(0, First) request delivered: 0 time to resend requests, pending requests: 3 sending request: (1, Second) sending request: (2, Third) sending request: (3, Four) processor: on_request(1, Second) request delivered: 1 time to resend requests, pending requests: 2 sending request: (2, Third) sending request: (3, Four) processor: on_request(2, Third) request delivered: 2 time to resend requests, pending requests: 1 sending request: (3, Four) processor: on_request(3, Four) request delivered: 3

इसके अलावा, मुझे कहना होगा कि व्यवहार में, वितरण रिपोर्ट बनाने के लिए इस तरह के एक सरल custom_envelope_t शायद ही उपयुक्त है। लेकिन अगर किसी को इस विषय में दिलचस्पी है, तो यह टिप्पणियों में चर्चा की जा सकती है, और लेख की मात्रा में वृद्धि नहीं कर सकता है।

लिफाफे के साथ और क्या किया जा सकता है?

बड़ा अच्छा सवाल!जिसका हमारे पास कोई व्यापक जवाब नहीं है। शायद, संभावनाएं केवल उपयोगकर्ताओं की कल्पना से सीमित हैं। ठीक है, अगर SObjectizer में कल्पनाओं की प्राप्ति के लिए कुछ याद आ रहा है, तो यह हमें बताया जा सकता है। हम हमेशा सुनते हैं। और, महत्वपूर्ण बात, कई बार हम ऐसा भी करते हैं :)

माचिन के साथ एजेंटों का एकीकरण

थोड़ी अधिक गंभीरता से बोलते हुए, यह एक और विशेषता है जिसे मैं समय-समय पर लेना चाहता हूं और जिसे so_5_extra-1.2.0 के लिए भी योजना बनाई गई थी। लेकिन जो सबसे अधिक संभावना है, 1.2.0 रिलीज में नहीं आएगा।

यह mchains और एजेंटों के एकीकरण को सरल बनाने के बारे में है ।

तथ्य यह है कि शुरू में mchains SObjectizer में जोड़े गए थे ताकि एजेंटों के संचार को सरल बनाया जा सके, जो कि बिना एजेंटों के लिखे गए हैं। उदाहरण के लिए, एप्लिकेशन का मुख्य धागा है, जिस पर उपयोगकर्ता GUI का उपयोग करके इंटरैक्ट करता है। और कई एजेंट-श्रमिक हैं जो पृष्ठभूमि "कठिन" काम करते हैं। मुख्य थ्रेड से एजेंट को संदेश भेजना कोई समस्या नहीं है: बस नियमित रूप से कॉल करें। लेकिन जानकारी को वापस कैसे स्थानांतरित करें?

इसके लिए माचिन-एस को जोड़ा गया।

लेकिन समय के साथ, यह पता चला कि माचिन बहुत बड़ी भूमिका निभा सकता है। यह संभव है, सिद्धांत रूप में, केवल किसी भी एजेंट के बिना SObjectizer पर मल्टीथ्रेडेड एप्लिकेशन बनाने के लिए, केवल माचिन-आह पर ( यहां अधिक विवरण )। और आप एजेंटों पर लोड को संतुलित करने के साधन के रूप में माचिन-एस का उपयोग कर सकते हैं। निर्माता-उपभोक्ता समस्याओं को हल करने के लिए एक तंत्र के रूप में।

निर्माता-उपभोक्ता के साथ समस्या यह है कि यदि निर्माता तेजी से संदेश उत्पन्न करता है तो उपभोक्ता उन्हें संभाल सकता है, तो हम परेशानी में हैं। संदेश की कतारें बढ़ेंगी, प्रदर्शन समय के साथ कम हो सकता है, या एप्लिकेशन मेमोरी थकावट के कारण पूरी तरह से दुर्घटनाग्रस्त हो जाएगा।

सामान्य समाधान जो हमने इस मामले में उपयोग करने का प्रस्ताव दिया था, वह है उपयोग करने के लिएकलेक्टर-प्रदर्शन करने वाले एजेंटों की एक जोड़ी । आप संदेश सीमा (या तो मुख्य सुरक्षा तंत्र के रूप में, या कलेक्टर-कलाकार के अतिरिक्त के रूप में) का उपयोग कर सकते हैं। लेकिन कलेक्टर-कलाकार को लिखने के लिए प्रोग्रामर से अतिरिक्त काम की आवश्यकता होती है।

लेकिन डेवलपर से न्यूनतम प्रयास के साथ इन उद्देश्यों के लिए mchains का उपयोग किया जा सकता है। इसलिए, निर्माता अगला संदेश मचिन में डाल देगा, और उपभोक्ता इस मचिन से संदेश ले जाएगा।

लेकिन समस्या यह है कि जब उपभोक्ता एक एजेंट होता है, तो एजेंट के लिए उपलब्ध प्राप्त () और चयन () कार्यों के माध्यम से माचिन के साथ काम करना बहुत सुविधाजनक नहीं होता है। और एजेंटों और मचिन-एस को एकीकृत करने के लिए कुछ उपकरण की मदद से इस असुविधा को समाप्त करने की कोशिश की जा सकती है।

इस तरह के उपकरण को विकसित करते समय, कई समस्याओं को हल करना आवश्यक होगा। उदाहरण के लिए, जब एक संदेश माचिन में आता है, तो उसे किस बिंदु पर माचिन से निकाला जाना चाहिए? यदि उपभोक्ता स्वतंत्र है और कुछ भी संसाधित नहीं करता है, तो आप मैचिन से संदेश को तुरंत उठा सकते हैं और इसे उपभोक्ता एजेंट को दे सकते हैं। यदि उपभोक्ता को मेचिन से एक संदेश पहले ही भेजा जा चुका है, तो वह अभी तक इस संदेश को संसाधित करने में कामयाब नहीं हुआ है, लेकिन एक नया संदेश पहले ही माचिन में आ चुका है ... इस मामले में क्या किया जाना चाहिए?

ऐसी अटकलें हैं कि लिफाफे इस मामले में मदद कर सकते हैं। इसलिए, जब हम माचिन से पहला संदेश लेते हैं और इसे उपभोक्ता को भेजते हैं, तो हम इस संदेश को एक विशेष लिफाफे में लपेटते हैं। जब लिफाफा देखता है कि संदेश वितरित और संसाधित किया गया है, तो यह माचिन से अगला संदेश अनुरोध करता है (यदि कोई है)।

बेशक, यहां सब कुछ इतना सरल नहीं है। लेकिन अभी तक यह काफी सॉल्व लग रहा है। और, मुझे आशा है, एक समान तंत्र so_5_extra के अगले संस्करणों में से एक में दिखाई देगा।

क्या हम भानुमती का पिटारा खोलने जा रहे हैं?

यह ध्यान दिया जाना चाहिए कि हमारे साथ जोड़ा क्षमताओं खुद दोहरी भावनाओं का कारण बनती हैं।

एक तरफ, लिफाफे पहले से ही उन चीजों को करने की अनुमति देते हैं / अनुमति देते हैं जो पहले उल्लेख किए गए थे (लेकिन बस कुछ के बारे में सपना देखा)। उदाहरण के लिए, यह टाइमर की गारंटी रद्द करने और डिलीवरी के समय, वितरण रिपोर्ट, पहले भेजे गए संदेश को वापस बुलाने की क्षमता पर प्रतिबंध है।

दूसरी ओर, यह स्पष्ट नहीं है कि इससे आगे क्या होगा। आखिरकार, आप किसी भी अवसर से एक समस्या बना सकते हैं यदि आप इस अवसर का उपयोग करना शुरू करते हैं जहां आपको ज़रूरत है और जहां आप नहीं करते हैं। तो हो सकता है कि हम पेंडोरा का डिब्बा खोल दें और हम अभी भी कल्पना न करें कि हमें क्या इंतजार है?

यह केवल धैर्य रखने और यह देखने के लिए रहता है कि यह सब हमें कहां ले जाएगा।

समापन के बजाय SObjectizer की तत्काल विकास योजनाओं के बारे में

एक निष्कर्ष के बजाय, मैं इस बारे में बात करना चाहता हूं कि हम सोबिजाइज़र के भविष्य के निकट (और न केवल) कैसे देखते हैं। यदि कोई हमारी योजनाओं में किसी चीज से खुश नहीं है, तो आप बाहर बात कर सकते हैं और प्रभावित कर सकते हैं कि एसओबीजेनाइजर -5 कैसे विकसित होगा।

SObjectizer-5.5.23 और so_5_extra-1.2.0 के पहले बीटा संस्करण पहले से तय हैं और डाउनलोड और प्रयोगों के लिए उपलब्ध हैं। प्रलेखन और उपयोग मामलों के क्षेत्र में अभी भी बहुत काम किया जाना है। इसलिए, आधिकारिक रिलीज की योजना नवंबर के पहले दशक में बनाई गई है। यदि यह पहले काम करता है, तो हम इसे पहले करेंगे।

SObjectizer-5.5.23 की रिहाई का मतलब है कि शाखा 5.5 का विकास इसके अंत में आ रहा है। यह है इस शाखा की पहली रिलीज चार साल पहले आयोजित किया गया था, अक्टूबर 2014 में। तब से, SObjectizer-5 संस्करणों के बीच किसी भी बड़े ब्रेकिंग परिवर्तन के बिना 5.5 शाखा के भीतर विकसित हुआ है। यह आसान नहीं था। विशेष रूप से इस तथ्य पर विचार करते हुए कि इस बार हमें उन कंपाइलरों को देखना पड़ा जो C ++ 11 के लिए आदर्श समर्थन से दूर थे।

अब हम 5.5 शाखा के भीतर और विशेष रूप से पुराने C ++ कंपाइलर पर संगतता देखने का कोई कारण नहीं देखते हैं। 2014 में क्या उचित हो सकता है, जब C ++ 14 सिर्फ आधिकारिक तौर पर अपनाने के लिए तैयार हो रहा था, और C ++ 17 अभी तक क्षितिज पर नहीं था, अब यह पूरी तरह से अलग दिखता है।

इसके अलावा, SObjectizer-5.5 में ही पहले से ही उचित मात्रा में रेक और बैकअप जमा हो गए हैं, जो इसी संगतता के कारण दिखाई दिए और जो SObjectizer के आगे के विकास को जटिल बनाते हैं।

इसलिए, आने वाले महीनों में हम निम्नलिखित परिदृश्य के अनुसार कार्य करने जा रहे हैं:

1. so_5_extra के अगले संस्करण का विकास, जिसमें मैं एजेंटों के लिए परीक्षणों के लेखन को सरल बनाने के लिए उपकरण जोड़ना चाहता हूं। क्या यह so_5_extra-1.3.0 होगा (यानी 1.2.0 के सापेक्ष परिवर्तन तोड़ने के साथ) या क्या यह so_5_extra-1.2.1 होगा (यानी बिना परिवर्तन तोड़े) अभी तक स्पष्ट नहीं है। आइए देखें कि यह कैसे होता है। यह केवल स्पष्ट है कि so_5_extra का अगला संस्करण SObjectizer-5.5 पर आधारित होगा।

1 क। यदि so_5_extra के अगले संस्करण के लिए आपको SObjectizer-5.5 में कुछ अतिरिक्त करने की आवश्यकता है, तो अगला संस्करण 5.5.24 जारी किया जाएगा। यदि so_5_extra के लिए यह SObjectizer के मूल में सुधार करने के लिए आवश्यक नहीं होगा, तो संस्करण 5.5.23 शाखा 5.5 के ढांचे में अंतिम महत्वपूर्ण संस्करण बन जाएगा। मामूली बग-फिक्स रिलीज सामने आएंगी। लेकिन शाखा 5.5 का विकास संस्करण 5.5.23 या 5.5.24 पर ही रुक जाता है।

2. फिर SObjectizer-5.6.0 का एक संस्करण जारी किया जाएगा, जो एक नई शाखा खोलेगा। शाखा 5.6 में हम सभी संचित बैसाखियों और बैकअपों के साथ-साथ पुराने कूड़ेदानों से SObjectizer कोड को साफ करेंगे, जिन्हें लंबे समय से पदावनत के रूप में चिह्नित किया गया है। यह संभावना है कि कुछ चीजें रिफैक्टिंग से गुजरेंगी (उदाहरण के लिए, abstract_message_box_t बदला जा सकता है), लेकिन शायद ही कार्डिनल। काम के मूल सिद्धांत और SObjectizer-5.6 में SObjectizer-5.5 की विशिष्ट विशेषताएं समान रूप में रहेंगी।

SObjectizer-5.6 को पहले से ही C ++ 14 (कम से कम GCC-5.5 स्तर पर) की आवश्यकता होगी। VC ++ 15 (जो Visual Studio 2017 से है) के नीचे विजुअल C ++ कंपाइलर समर्थित नहीं होंगे।

हम शाखा 5.6 को SObjectizer की एक स्थिर शाखा के रूप में मानते हैं, जो SObjectizer-5.7 के पहले संस्करण के प्रकट होने तक प्रासंगिक होगी।

मैं फरवरी में अस्थायी रूप से 2019 की शुरुआत में संस्करण 5.6.0 जारी करना चाहता हूं।

3. शाखा 5.6 को स्थिर करने के बाद, हम शाखा 5.7 पर काम करना शुरू करना चाहते हैं, जिसमें हम SObjectizer के काम के कुछ बुनियादी सिद्धांतों को संशोधित कर सकते हैं। उदाहरण के लिए, केवल निजी लोगों को छोड़कर, सार्वजनिक डिस्पैचरों को पूरी तरह से छोड़ दें। सहकारी समितियों के तंत्र और उनके अभिभावक-बच्चे के रिश्तों को फिर से बनाएं, जिससे सहकारी समितियों के पंजीकरण / डेरेगेटिंग के दौरान अड़चन से छुटकारा मिल सके। संदेश / संकेत द्वारा विभाजन निकालें। केवल संदेश भेजने के लिए / send_delayed / send_periodic को भेजने की अनुमति दें, और "हुड के तहत" पहुंच और शेड्यूल_टाइमर विधियों को छुपायें। संदेश भेजने के लिए तंत्र को संशोधित करें ताकि या तो पूरी तरह से इस प्रक्रिया से डायनेमिक_कास्ट हटा दें, या उन्हें बहुत कम कर दें।

सामान्य तौर पर, जहां घूमना होता है। इसी समय, SObjectizer-5.7 को C ++ 14 की परवाह किए बिना पहले से ही C ++ 17 की आवश्यकता होगी।

यदि आप गुलाबी चश्मे के बिना चीजों को देखते हैं, तो यह अच्छा है अगर रिलीज 5.7.0 देर से शरद ऋतु 2019 में होती है। यह क्या है 2019 के लिए SObjectizer का मुख्य कार्य संस्करण शाखा 5.6 होगा।

4. इस सबके समानांतर, इसलिए_5_ कस्टम्रा विकसित होगा। संभवतः, so_5_extra-2 संस्करण SObjectizer-5.6 के साथ जारी किया जाएगा, जो 2019 के पाठ्यक्रम पर नई कार्यक्षमता को शामिल करेगा, लेकिन SObjectizer-5.6 पर आधारित होगा।

इस प्रकार, हम खुद SObjectizer-5 के कुछ मूल सिद्धांतों के क्रमिक संशोधन के साथ SObjectizer-5 के लिए प्रगतिशील विकास को देखते हैं। उसी समय, हम इसे यथासंभव सुचारू रूप से करने की कोशिश करेंगे ताकि न्यूनतम दर्द के साथ एक संस्करण से दूसरे में स्विच करना संभव हो।

हालाँकि, अगर कोई SObjectizer से अधिक नाटकीय और महत्वपूर्ण बदलाव चाहता है, तो हमारे पास इस पर कुछ विचार हैं । संक्षेप में: आप अपनी पसंद के अनुसार SObjectizer का रीमेक कर सकते हैं, एक अन्य प्रोग्रामिंग भाषा के लिए SObjectizer-6 को कार्यान्वित करने का अधिकार। लेकिन हम इसे पूरी तरह से अपने खर्च पर नहीं करेंगे, क्योंकि यह SObjectizer -5 के विकास के साथ होता है।

शायद यही सब है।पिछले लेख की टिप्पणियाँ एक अच्छी और रचनात्मक चर्चा निकलीं। अगर इस बार भी इसी तरह की चर्चा हुई तो यह हमारे लिए उपयोगी होगा। हमेशा की तरह, हम किसी भी सवाल का जवाब देने के लिए तैयार हैं, लेकिन समझदार लोगों के लिए, और खुशी के साथ।

और सबसे अधिक रोगी पाठकों के लिए जो इन पंक्तियों तक पहुंच गए हैं, लेख पढ़ने में बिताए गए समय के लिए बहुत धन्यवाद।

SObjectizer-5.5.23 में नया: इच्छा पूर्ति या पेंडोरा बॉक्स?