प्रस्तावना

हमारी छोटी टीम C ++ डेवलपर्स के लिए दो OpenSource उपकरण विकसित कर रही है - SObjectizer अभिनेता फ्रेमवर्क और Restinio एम्बेडेड HTTP सर्वर। हालाँकि, हम नियमित रूप से गैर-तुच्छ सवालों के एक जोड़े में आते हैं:

• पुस्तकालय में जोड़ने के लिए कौन सी सुविधाएँ, और "ओवरबोर्ड" छोड़ने के लिए?
• पुस्तकालय का उपयोग करने के लिए "वैचारिक रूप से सही" तरीके को स्पष्ट रूप से कैसे प्रदर्शित करें?

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

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

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

आज हम ऐसे ही एक "छोटे" कार्य के बारे में बताना चाहते हैं, जिसमें SObjectizer और Restinio स्वाभाविक रूप से एक साथ आए थे।

चित्रों का स्केलिंग और वितरण। आखिर ऐसा क्यों?

अपने लिए एक छोटे से डेमो कार्य के रूप में, हमने एक HTTP सर्वर चुना जो अनुरोध पर स्केल की गई छवियों को वितरित करता है। आप छवियों को कुछ निर्देशिका में रखते हैं, HTTP सर्वर शुरू करते हैं, फॉर्म के लिए एक अनुरोध करते हैं:

curl "http://localhost:8080/my_picture.jpg?op=resize&max=1920" 

और बदले में आपको एक तस्वीर मिलती है जो लंबी तरफ 1920 पिक्सल के आकार की है।

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

यह वही होता है जब छवियों को स्केल करने के लिए प्रसंस्करण अनुरोध होता है। एक HTTP सर्वर एक मिलीसेकंड के एक अंश में अपना सीधा काम करने में सक्षम है (यानी डेटा पढ़ना, एक HTTP अनुरोध पार्स करना)। लेकिन एक तस्वीर को स्केल करना दसियों, सैकड़ों, या हजारों मिलीसेकंड भी ले सकता है।

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

यह पता चला है कि HTTP के माध्यम से स्केलेबल छवियों को वितरित करने के लिए, हमें लंबे समय से लिखित, काम कर रहे C / C ++ कोड (इस मामले में ImageMagic ++) का पुन: उपयोग करने की आवश्यकता है, और HTTP अनुरोधों को अतुल्यकालिक रूप से परोसें, और कई सूचनाओं में अनुरोधों का अनुप्रयोग प्रसंस्करण करें। Restinio और SObjectizer के लिए एक उत्कृष्ट कार्य, जैसा कि यह हमें लग रहा था।

और हमने अपने डेमो प्रोजेक्ट झींगा का नाम तय किया।

झींगा जैसा भी है

झींगा क्या करता है?

चिंराट एक सांत्वना अनुप्रयोग के रूप में चलता है, निर्दिष्ट पोर्ट पर खुलता है और सुनता है, फॉर्म के HTTP GET अनुरोध प्राप्त करता है और संसाधित करता है:

 /<image>.<ext> /<image>.<ext>?op=resize&<side>=<value> 

जहां:

• छवि छवि फ़ाइल पैमाने पर करने का नाम है। उदाहरण के लिए, my_picture या DSCF0069;
• ext झींगा (jpg, jpeg, png या gif) द्वारा समर्थित एक्सटेंशन में से एक है;
• साइड उस तरफ का संकेत है जिसके लिए आकार निर्धारित किया गया है। इसमें या तो चौड़ाई का मान हो सकता है, इस मामले में तस्वीर को बढ़ाया जाता है ताकि परिणामस्वरूप चौड़ाई निर्दिष्ट मूल्य के बराबर हो, पहलू अनुपात बनाए रखते हुए तस्वीर की ऊंचाई स्वचालित रूप से चुनी जाती है। या ऊंचाई का मूल्य, इस मामले में, ऊंचाई में स्केलिंग होती है। या तो अधिकतम, इस मामले में लंबा पक्ष सीमित है, और झींगा खुद निर्धारित करता है कि लंबी तरफ ऊंचाई या चौड़ाई है;
• मान वह आकार है जिस पर स्केलिंग होती है।

यदि केवल फ़ाइल का नाम URL में निर्दिष्ट है, बिना आकार के ऑपरेशन के, तो झींगा बस प्रतिक्रिया में मूल छवि देता है। यदि आकार बदलने का ऑपरेशन निर्दिष्ट है, तो झींगा अनुरोधित छवि के आकार को बदल देता है और स्केल किया गया संस्करण देता है।

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

कैश समय-समय पर साफ किया जाता है। चित्र जो कैश में एक घंटे से अधिक समय तक रहे हैं, क्योंकि अंतिम एक्सेस उन्हें इससे बाहर धकेल दिया गया है। इसके अलावा, अगर कैशे अपने अधिकतम आकार से अधिक हो जाता है (एक डेमो प्रोजेक्ट में यह 100Mb है) तो सबसे पुरानी तस्वीरें कैश से बाहर फेंक दी जाती हैं।

हमने एक पृष्ठ तैयार किया है जिस पर जाकर कोई भी झींगा के साथ प्रयोग कर सकता है:



इस पृष्ठ पर आप छवि का आकार निर्धारित कर सकते हैं और "आकार बदलें" पर क्लिक कर सकते हैं। एक ही मापदंडों के साथ झींगा सर्वर के लिए दो अनुरोध किए जाएंगे। सबसे अधिक संभावना है, पहला अनुरोध अद्वितीय होगा (यानी अभी तक कैश में ऐसे आकार के मापदंडों के साथ कैश नहीं होगा), इसलिए पहला अनुरोध वास्तव में छवि को स्केल करने में कुछ समय लगेगा। और दूसरा अनुरोध, सबसे अधिक संभावना है, कैश में पहले से ही स्केल की गई तस्वीर ढूंढ लेगा और इसे तुरंत दे देगा।

यह निर्धारित करना संभव है कि क्या चित्र कैश से दिया गया है या क्या यह वास्तव में चित्र के तहत पाठ द्वारा बढ़ाया गया था। उदाहरण के लिए, पाठ "ट्रांसफ़ॉर्म्ड (114.0ms)" इंगित करता है कि चित्र को छोटा किया गया था और ज़ूम ऑपरेशन में 114 मिलीसेकंड लगे।

झींगा कैसे करता है?

झींगा एक बहु-थ्रेडेड एप्लिकेशन है जो वर्क थ्रेड्स के तीन समूह चलाता है:

1. HTTP सर्वर पर काम करने वाले थ्रेड्स का पूल। इस पूल में, नए कनेक्शन दिए जाते हैं, आने वाले अनुरोध प्राप्त होते हैं और पार्स किए जाते हैं, प्रतिक्रियाएं उत्पन्न होती हैं और भेजी जाती हैं। HTTP सर्वर RESTINIO लाइब्रेरी के माध्यम से कार्यान्वित किया जाता है।
2. एक अलग कार्य सूत्र, जिस पर transform_manager SObjectizer एजेंट चलता है। यह एजेंट HTTP सर्वर से प्राप्त अनुरोधों को संसाधित करता है और स्केल की गई छवियों का कैश रखता है।
3. थ्रेड पूल जिस पर SObjectizer एजेंट काम कर रहे हैं ट्रांसफार्मर। वे ImageMagic ++ का उपयोग करके चित्रों की वास्तविक स्केलिंग करते हैं।

यह निम्नलिखित कार्य योजना को दर्शाता है:



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

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

ट्रांसफॉर्मर एजेंट से ट्रांसफॉर्म_मनगर के अनुरोध प्राप्त होते हैं, उन्हें संसाधित करता है, और ट्रांसफ़ॉर्म का परिणाम वापस ट्रांसफॉर्म_मनगर एजेंट को देता है।

झींगा के पास क्या है?

इस आलेख में वर्णित झींगा के सबसे न्यूनतम संस्करण के लिए स्रोत कोड इस भंडार में पाया जा सकता है: बिटबकेट पर या गीथहब पर झींगा-डेमो ।

कोड का एक बहुत है, हालांकि, अधिकांश भाग के लिए, चिंराट के इस संस्करण में, कोड काफी तुच्छ है। हालांकि, यह कार्यान्वयन के कुछ पहलुओं पर ध्यान केंद्रित करने के लिए समझ में आता है।

C ++ 17 और सबसे हाल के संकलक संस्करणों का उपयोग करना

झींगा के कार्यान्वयन में, हमने सी ++ 17 और संकलक के नवीनतम संस्करणों का उपयोग करने का निर्णय लिया, विशेष रूप से जीसीसी 7.3 और 8.1। परियोजना भारी शोध है। इसलिए, ऐसी परियोजना के ढांचे में C ++ 17 का व्यावहारिक परिचित स्वाभाविक और स्वीकार्य है। जबकि अधिक सांसारिक विकास यहां और अब व्यावहारिक औद्योगिक अनुप्रयोगों पर केंद्रित हैं, हम पुराने संकलक पर वापस देखने के लिए मजबूर हैं और शायद C ++ 14 का उपयोग करते हैं, या यहां तक ​​कि C ++ 11 का सबसेट भी।

मुझे कहना होगा कि C ++ 17 एक अच्छा प्रभाव डालता है। ऐसा लगता है कि हमने झींगा कोड में सत्रहवें मानक से इतने सारे नवाचारों का उपयोग नहीं किया है, लेकिन उनका सकारात्मक प्रभाव पड़ा है: विशेषता [[nodiscard]], std :: वैकल्पिक / std :: variant / std "फाइल सिस्टम" बॉक्स से बाहर ", और बाहरी निर्भरता से नहीं, संरचित बाइंडिंग, अगर कॉन्स्टैक्स, एसटीडी के लिए लंबोदर के लिए आगंतुक को इकट्ठा करने की क्षमता :: यात्रा ... व्यक्तिगत रूप से, ये सभी त्रिभुज हैं, लेकिन एक साथ वे एक शक्तिशाली संचयी प्रभाव पैदा करते हैं।

तो झींगा विकसित करते समय हमें जो पहला उपयोगी परिणाम मिला: सी ++ 17 यह इसके लिए स्विच करने के लिए लायक है।

Restinio टूल का उपयोग कर HTTP सर्वर

शायद चिंराट का सबसे आसान हिस्सा HTTP सर्वर और HTTP GET अनुरोध हैंडलर ( http_server.hpp और http_server.cpp ) है।

आने वाले अनुरोधों को प्राप्त करें और भेजें

मूल रूप से, चिंराट HTTP सर्वर के सभी बुनियादी तर्क इस फ़ंक्शन में केंद्रित हैं:

 void add_transform_op_handler( const app_params_t & app_params, http_req_router_t & router, so_5::mbox_t req_handler_mbox ) { router.http_get( R"(/:path(.*)\.:ext(.{3,4}))", restinio::path2regex::options_t{}.strict( true ), [req_handler_mbox, &app_params]( auto req, auto params ) { if( has_illegal_path_components( req->header().path() ) ) { return do_400_response( std::move( req ) ); } const auto opt_image_format = image_format_from_extension( params[ "ext" ] ); if( !opt_image_format ) { return do_400_response( std::move( req ) ); } if( req->header().query().empty() ) { return serve_as_regular_file( app_params.m_storage.m_root_dir, std::move( req ), *opt_image_format ); } const auto qp = restinio::parse_query( req->header().query() ); if( "resize" != restinio::value_or( qp, "op"sv, ""sv ) ) { return do_400_response( std::move( req ) ); } handle_resize_op_request( req_handler_mbox, *opt_image_format, qp, std::move( req ) ); return restinio::request_accepted(); } ); } 

यह फ़ंक्शन Restinio ExpressJS राउटर का उपयोग करके HTTP GET अनुरोध हैंडलर तैयार करता है। जब HTTP सर्वर को GET रिक्वेस्ट मिलती है, जिसमें से URL दिए गए रेगुलर एक्सप्रेशन के अंतर्गत आता है, तो निर्दिष्ट लैम्बडा फंक्शन कहा जाता है।

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

 void handle_resize_op_request( const so_5::mbox_t & req_handler_mbox, image_format_t image_format, const restinio::query_string_params_t & qp, restinio::request_handle_t req ) { try_to_handle_request( [&]{ auto op_params = transform::resize_params_t::make( restinio::opt_value< std::uint32_t >( qp, "width" ), restinio::opt_value< std::uint32_t >( qp, "height" ), restinio::opt_value< std::uint32_t >( qp, "max" ) ); transform::resize_params_constraints_t{}.check( op_params ); std::string image_path{ req->header().path() }; so_5::send< so_5::mutable_msg<a_transform_manager_t::resize_request_t>>( req_handler_mbox, std::move(req), std::move(image_path), image_format, op_params ); }, req ); } 

यह पता चलता है कि HTTP सर्वर, रिसाइज़-रिक्वेस्ट स्वीकार करने के बाद, उसे एसिंक्रोनस संदेश के माध्यम से transform_manager एजेंट को देता है, और अन्य अनुरोधों को पूरा करना जारी रखता है।

Sendfile के साथ फ़ाइल साझा करना

यदि HTTP सर्वर मूल चित्र के लिए एक अनुरोध का पता लगाता है, तो आकार परिवर्तन के बिना, सर्वर तुरंत Sendfile ऑपरेशन के माध्यम से इस चित्र को भेजता है। इससे जुड़ा मुख्य कोड इस प्रकार है (इस फ़ंक्शन का पूर्ण कोड रिपॉजिटरी में पाया जा सकता है ):

 [[nodiscard]] restinio::request_handling_status_t serve_as_regular_file( const std::string & root_dir, restinio::request_handle_t req, image_format_t image_format ) { const auto full_path = make_full_path( root_dir, req->header().path() ); try { auto sf = restinio::sendfile( full_path ); ... return set_common_header_fields_for_image_resp( file_stat.st_mtim.tv_sec, resp ) .append_header( restinio::http_field::content_type, image_content_type_from_img_format( image_format ) ) .append_header( http_header::shrimp_image_src, image_src_to_str( http_header::image_src_t::sendfile ) ) .set_body( std::move( sf ) ) .done(); } catch(...) {} return do_404_response( std::move( req ) ); } 

यहाँ मुख्य बिंदु restinio :: sendfile () कह रहा है, और फिर इस फ़ंक्शन द्वारा दिए गए मान को set_body () में पास कर रहा है।

Restinio :: sendfile () फ़ंक्शन सिस्टम API का उपयोग करके एक फ़ाइल अपलोड ऑपरेशन बनाता है। जब यह ऑपरेशन set_body () में पास हो जाता है, तो Restinio समझता है कि restinio :: sendfile () में निर्दिष्ट फ़ाइल की सामग्री का उपयोग HTTP प्रतिक्रिया के मुख्य भाग के लिए किया जाएगा। तब यह सिस्टम एपीआई का उपयोग इस फ़ाइल की सामग्री को टीसीपी सॉकेट में लिखने के लिए करता है।

छवि कैश को लागू करना

ट्रांसफॉर्म_मनगर एजेंट परिवर्तित छवियों के कैश को संग्रहीत करता है, जहां छवियों को स्केलिंग के बाद रखा जाता है। यह कैश एक साधारण स्व-निर्मित कंटेनर है जो दो तरह से इसकी सामग्री तक पहुँच प्रदान करता है:

1. कुंजी द्वारा एक तत्व की खोज करके (मानक कंटेनरों में ऐसा कैसे होता है std :: map और std :: unordered_map)।
2. सबसे पुराना कैश आइटम एक्सेस करके।

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

हमने इंटरनेट पर इन उद्देश्यों के लिए तैयार कुछ खोजना शुरू नहीं किया। शायद Boost.MultiIndex यहाँ काफी उपयुक्त होगा। लेकिन मैं सिर्फ मल्टीआंडेक्स के लिए बूस्ट को खींचना नहीं चाहता था, इसलिए हमने अपने तुच्छ कार्यान्वयन को सचमुच अपने घुटनों पर किया। यह काम करने लगता है;)

ट्रांसफॉर्म_मनगर में लंबित अनुरोधों की कतार

हमारे विचार के अनुसार, सरलतम कार्यान्वयन में झींगा के बारे में सभ्य आकार, (लगभग 250 लाइनों की एक hpp फ़ाइल और लगभग 270 रेखाओं की एक cpp फ़ाइल ) के बावजूद, हमारी राय में मामूली रूप से बदल गया।

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

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

झींगा में, हम प्रतीक्षा अनुरोधों की एक कतार का उपयोग करते हैं, जिसे निम्नानुसार परिभाषित किया गया है:

 struct pending_request_t { transform::resize_request_key_t m_key; sobj_shptr_t<resize_request_t> m_cmd; std::chrono::steady_clock::time_point m_stored_at; pending_request_t( transform::resize_request_key_t key, sobj_shptr_t<resize_request_t> cmd, std::chrono::steady_clock::time_point stored_at ) : m_key{ std::move(key) } , m_cmd{ std::move(cmd) } , m_stored_at{ stored_at } {} }; using pending_request_queue_t = std::queue<pending_request_t>; pending_request_queue_t m_pending_requests; static constexpr std::size_t max_pending_requests{ 64u }; 

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

लंबित अनुरोधों की कतार के लिए एक आकार सीमा भी है। यदि कतार पहले से ही अपने अधिकतम आकार तक पहुंच गई है, तो हम तुरंत अनुरोध को संसाधित करने से इनकार करते हैं और ग्राहक को बताते हैं कि हम अतिभारित हैं।

लंबित अनुरोधों की कतार से संबंधित एक महत्वपूर्ण बिंदु है, जिसे हम लेख के निष्कर्ष पर केंद्रित करेंगे।

टाइप करें sobj_shptr_t और पुन: उपयोग संदेश उदाहरण

प्रतीक्षा अनुरोधों की कतार, साथ ही ट्रांसफॉर्म_मनगर के कुछ तरीकों के हस्ताक्षर निर्धारित करने में, आप sobj_shptr_t प्रकार का उपयोग देख सकते हैं। यह किस प्रकार का है और इसका उपयोग क्यों किया जाता है, इस पर अधिक विस्तार से ध्यान देना चाहिए।

लब्बोलुआब यह है कि transform_manager को resize_request_t संदेश के रूप में HTTP सर्वर से एक अनुरोध प्राप्त होता है:

 struct resize_request_t final : public so_5::message_t { restinio::request_handle_t m_http_req; std::string m_image; image_format_t m_image_format; transform::resize_params_t m_params; resize_request_t( restinio::request_handle_t http_req, std::string image, image_format_t image_format, transform::resize_params_t params ) : m_http_req{ std::move(http_req) } , m_image{ std::move(image) } , m_image_format{ image_format } , m_params{ params } {} }; 

और हमें इस जानकारी को प्रतीक्षा अनुरोधों की कतार में संग्रहीत करने के लिए कुछ करना होगा। उदाहरण के लिए, आप resize_request_t का एक नया उदाहरण बना सकते हैं और इसमें प्राप्त संदेश से मानों को स्थानांतरित कर सकते हैं।

और आप याद कर सकते हैं कि SObjectizer में संदेश स्वयं एक गतिशील रूप से बनाई गई वस्तु है। और एक साधारण वस्तु नहीं है, लेकिन अंदर एक लिंक काउंटर के साथ। और यह कि SObjectizer में ऐसी वस्तुओं के लिए एक विशेष प्रकार का स्मार्ट पॉइंटर है - intrusive_ptr_t।

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

 template<typename T> using sobj_shptr_t = so_5::intrusive_ptr_t<T>; 

ग्राहकों के लिए अतुल्यकालिक प्रतिक्रियाएं

हमने कहा कि HTTP अनुरोधों को एसिंक्रोनस रूप से संसाधित किया जाता है। और हमने ऊपर दिखाया कि कैसे HTTP सर्वर एक एसिंक्रोनस संदेश के साथ transform_manager एजेंट को एक जांच भेजता है। लेकिन HTTP अनुरोधों की प्रतिक्रियाओं का क्या होता है?

प्रतिक्रियाओं को भी अतुल्यकालिक रूप से परोसा जाता है। उदाहरण के लिए, transform_manager कोड में आप निम्नलिखित देख सकते हैं:

 void a_transform_manager_t::on_failed_resize( failed_resize_t & /*result*/, sobj_shptr_t<resize_request_t> cmd ) { do_404_response( std::move(cmd->m_http_req) ); } 

यह कोड उस मामले में HTTP अनुरोध के लिए एक नकारात्मक प्रतिक्रिया उत्पन्न करता है जब छवि को किसी कारण से स्केल नहीं किया जा सकता था। प्रतिक्रिया do_404_response सहायक फ़ंक्शन में उत्पन्न होती है, जिसका कोड निम्नानुसार दर्शाया जा सकता है:

 auto do_404_response( restinio::request_handle_t req ) { auto resp = req->create_response( 404, "Not Found" ); resp.append_header( restinio::http_field_t::server, "Shrimp draft server" ); resp.append_header_date_field(); if( req->header().should_keep_alive() ) resp.connection_keep_alive(); else resp.connection_close(); return resp.done(); } 

Do_404_response () के साथ पहला मुख्य बिंदु यह है कि यह फ़ंक्शन ट्रांसफॉर्म_मनगर एजेंट के कार्य प्रसंग पर कहा जाता है, न कि HTTP सर्वर के कार्य प्रसंग पर।

दूसरा मुख्य बिंदु पूरी तरह से बनाई गई सम्मान वस्तु पर की गई () विधि के लिए कॉल है। एक HTTP प्रतिक्रिया के साथ सभी अतुल्यकालिक जादू यहां होता है। किए गए () विधि के संबंध में तैयार की गई सभी जानकारी को लेता है और एसिंक्रोनस रूप से इसे HTTP सर्वर पर भेजता है। यानी do_404_response () से वापसी तब होगी जब संबंधित वस्तु की सामग्री HTTP सर्वर द्वारा पंक्तिबद्ध हो जाएगी।

HTTP सर्वर अपने काम के संदर्भ में एक नई HTTP प्रतिक्रिया की उपस्थिति का पता लगाएगा और उचित ग्राहक को प्रतिक्रिया भेजने के लिए आवश्यक कार्रवाई करना शुरू कर देगा।

टाइप करें dataizable_blob_t

एक और छोटा बिंदु जो स्पष्ट करने के लिए समझ में आता है, क्योंकि यह शायद Restinio की पेचीदगियों को समझने के बिना समझ से बाहर है। हम पहली नज़र में, एक अजीब प्रकार के datasizeable_blob_t की उपस्थिति के बारे में बात कर रहे हैं:

 struct datasizable_blob_t : public std::enable_shared_from_this< datasizable_blob_t > { const void * data() const noexcept { return m_blob.data(); } std::size_t size() const noexcept { return m_blob.length(); } Magick::Blob m_blob; //! Value for `Last-Modified` http header field. const std::time_t m_last_modified_at{ std::time( nullptr ) }; }; 

यह बताने के लिए कि इस प्रकार की आवश्यकता क्यों है, आपको यह दिखाने की आवश्यकता है कि कैसे एक बदली हुई तस्वीर के साथ HTTP प्रतिक्रिया बनती है

 void serve_transformed_image( restinio::request_handle_t req, datasizable_blob_shared_ptr_t blob, image_format_t img_format, http_header::image_src_t image_src, header_fields_list_t header_fields ) { auto resp = req->create_response(); set_common_header_fields_for_image_resp( blob->m_last_modified_at, resp ) .append_header( restinio::http_field::content_type, image_content_type_from_img_format( img_format ) ) .append_header( http_header::shrimp_image_src, image_src_to_str( image_src ) ) .set_body( std::move( blob ) ); for( auto & hf : header_fields ) { resp.append_header( std::move( hf.m_name ), std::move( hf.m_value ) ); } resp.done(); } 

हम set_body () पर कॉल पर ध्यान देते हैं: डेटा भेजने योग्य_blob_t उदाहरण के लिए एक स्मार्ट पॉइंटर सीधे वहां भेजा जाता है। क्यों?

तथ्य यह है कि Restinio एक HTTP प्रतिसाद का मुख्य भाग बनाने के लिए कई विकल्पों का समर्थन करता है । सबसे सरल प्रकार का एक उदाहरण है std :: string to set_body () और RESTinio इस स्ट्रिंग का मान संबंधित ऑब्जेक्ट के अंदर सहेजेगा।

लेकिन ऐसे समय होते हैं जब set_body () के लिए मान का एक साथ कई उत्तरों में पुन: उपयोग किया जाना चाहिए। उदाहरण के लिए, झींगा में ऐसा तब होता है जब झींगा को एक ही छवि के परिवर्तन के लिए कई समान अनुरोध प्राप्त होते हैं। . RESTinio set_body() :

 template<typename T> auto set_body(std::shared_ptr<T> body); 

T : data() size(), , RESTinio .

shrimp- Magick::Blob. Magic::Blob data, size(), length(). - datasizable_blob_t, RESTinio Magick::Blob.

transform_manager

transform_manager :

• , ;
• transformer-.

transform_manager . .

, :

 struct clear_cache_t final : public so_5::signal_t {}; struct check_pending_requests_t final : public so_5::signal_t {}; 

, :

 void a_transform_manager_t::so_define_agent() { so_subscribe_self() .event( &a_transform_manager_t::on_resize_request ) .event( &a_transform_manager_t::on_resize_result ) .event( &a_transform_manager_t::on_clear_cache ) .event( &a_transform_manager_t::on_check_pending_requests ); } void a_transform_manager_t::on_clear_cache( mhood_t<clear_cache_t> ) {...} void a_transform_manager_t::on_check_pending_requests( mhood_t<check_pending_requests_t> ) {...} 

SObjectizer .

:

 void a_transform_manager_t::so_evt_start() { m_clear_cache_timer = so_5::send_periodic<clear_cache_t>( *this, clear_cache_period, clear_cache_period ); m_check_pending_timer = so_5::send_periodic<check_pending_requests_t>( *this, check_pending_period, check_pending_period ); } 

— timer_id, send_periodic(). , timer_id. , send_periodic() , . a_transform_manager_t :

 so_5::timer_id_t m_clear_cache_timer; so_5::timer_id_t m_check_pending_timer; 

shrimp-. , , RESTinio SObjectizer - - , HelloWorld. .

, transform_manager . , . , . . , , .

transform_manager. , — .

shrimp- « », . , . , , shrimp .

shrimp- . stay tuned.

- shrimp-, RESTinio SObjectizer-, . , shrimp — , - shrimp- - , resize, , .

जारी रखने के लिए ...