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

#include <restinio/all.hpp> int main() { restinio::run( restinio::on_this_thread() .port(8080) .address("localhost") .request_handler([](auto req) { return req->create_response().set_body("Hello, World!").done(); })); return 0; }

यह वास्तव में एक C ++ एप्लिकेशन के अंदर HTTP सर्वर को चलाने के लिए आवश्यक है।

और यद्यपि हम हमेशा यह कहने की कोशिश करते हैं कि मुख्य विशेषता जिसके लिए हमने आमतौर पर रैस्टिनियो को लिया था वह आने वाले अनुरोधों की अतुल्यकालिक प्रसंस्करण थी, हम अभी भी कभी-कभी सवालों का सामना करते हैं कि क्या करना है अगर request_handler के अंदर आपको लंबा ऑपरेशन करना है।

और चूंकि ऐसा प्रश्न प्रासंगिक है, तो आप इसके बारे में फिर से बात कर सकते हैं और कुछ छोटे उदाहरण दे सकते हैं।

उत्पत्ति का थोड़ा संदर्भ

हमने कई बार समान कार्यो का सामना करने के बाद भी कई बार एक ही तरह के कार्यों का सामना करने के बाद अपना एम्बेड करने योग्य HTTP सर्वर बनाने का फैसला किया: एक मौजूदा C ++ एप्लिकेशन के लिए HTTP इनपुट को व्यवस्थित करना आवश्यक था या एक microservice लिखना आवश्यक था जिसमें पहले से मौजूद "भारी" C ++ का पुन: उपयोग करना आवश्यक था ny कोड। इन कार्यों की एक सामान्य विशेषता यह थी कि अनुरोध का अनुप्रयोग प्रसंस्करण दसियों सेकंड तक फैल सकता था।

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

यह बहुत अधिक सुविधाजनक है जब HTTP सर्वर केवल एक काम करने वाले धागे पर काम कर सकता है, जिस पर I / O का प्रदर्शन किया जाता है और हैंडलर को अनुरोध किया जाता है। अनुरोध हैंडलर बस कुछ अन्य कार्यशील थ्रेड के वास्तविक प्रसंस्करण को दर्शाता है और HTTP सर्वर पर नियंत्रण लौटाता है। जब बहुत बाद में, कहीं और काम करने वाली थ्रेड जानकारी अनुरोध पर प्रतिक्रिया देने के लिए तैयार होती है, तो एक HTTP प्रतिक्रिया बस उत्पन्न होती है जो स्वचालित रूप से HTTP सर्वर को चुनती है और उचित ग्राहक को यह प्रतिक्रिया भेजती है।

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

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

इसलिए, एक आवक अनुरोध है जिसे बहुत प्रसंस्करण समय की आवश्यकता है। क्या करें?

वर्क थ्रेड Restinio / Asio

कभी-कभी Restinio उपयोगकर्ता इस बारे में नहीं सोचते हैं कि कौन से कार्य थ्रेड का उपयोग करते हैं और वास्तव में RESTinio का उपयोग कैसे करते हैं। उदाहरण के लिए, कोई यह विचार कर सकता है कि जब Restinio को एक कार्यशील थ्रेड ( run(on_this_thread(...)) , जैसा कि ऊपर दिए गए उदाहरण में है), तब इस कार्य थ्रेड पर RESTinio केवल अनुरोध हैंडलर कहता है। जबकि I / O RESTinio हुड के नीचे एक अलग धागा बनाता है। और यह अलग थ्रेड नए कनेक्शन की सेवा जारी रखता है, जब मुख्य कार्य धागा request_handler के कब्जे में है।

वास्तव में, उपयोगकर्ता द्वारा RESTINIO को आवंटित किए जाने वाले सभी थ्रेड्स का उपयोग I / O संचालन करने और अनुरोध करने वाले हैंडलर के लिए दोनों के लिए किया जाता है। इसलिए, यदि आपने run(on_this_thread(...)) माध्यम से RESTINIO सर्वर शुरू किया है, तो चालू थ्रेड पर run() I / O) और अनुरोध हैंडलर दोनों के अंदर run() होंगे।

मोटे तौर पर, Restinio एक Asio इवेंट-लूप लॉन्च करता है, जिसके अंदर यह नए कनेक्शन को प्रोसेस करता है, मौजूदा कनेक्शन से डेटा पढ़ता है और पार्स करता है, भेजने के लिए डेटा तैयार करता है, कनेक्शन बंद करना संभालता है, आदि। अन्य बातों के अलावा, आने वाले अनुरोध को पढ़ने और अगले कनेक्शन से पूरी तरह से पार्स करने के बाद, उपयोगकर्ता द्वारा निर्दिष्ट request_handler को इस अनुरोध को संसाधित करने के लिए कहा जाता है।

तदनुसार, यदि request_handler वर्तमान थ्रेड के संचालन को अवरुद्ध करता है, तो उसी थ्रेड पर काम कर रहे Asio-action ईवेंट-लूप को भी अवरुद्ध कर दिया जाता है। सब कुछ सरल है।

यदि Restinio को वर्किंग थ्रेड्स के पूल पर (अर्थात run(on_thread_pool(...)) ऑफ़ run(on_thread_pool(...)) , जैसा कि इस उदाहरण में दिया गया है ) पर लॉन्च किया जाता है, तो लगभग एक ही बात होती है: पूल से प्रत्येक थ्रेड के लिए एक Asio- ईवेंट इवेंट लूप लॉन्च किया गया है। इसलिए, यदि कुछ request_handler बड़े मैट्रिसेस को गुणा करना शुरू कर देता है, तो यह पूल में काम करने वाले धागे को अवरुद्ध कर देगा और I / O संचालन को अब इस थ्रेड पर नहीं परोसा जाएगा।

इसलिए, Restinio का उपयोग करते समय, डेवलपर का कार्य एक उचित और लंबे समय तक नहीं, अपने request_handlers को पूरा करना है।

क्या आपको Restinio / Asio के लिए वर्कफ़्लो पूल की आवश्यकता है?

इसलिए, जब उपयोगकर्ता द्वारा निर्दिष्ट request_handler काम करने वाले धागे को अवरुद्ध करता है, जिस पर इसे लंबे समय तक कहा जाता है, यह धागा I / O संचालन को संसाधित करने की क्षमता खो देता है। लेकिन क्या होगा अगर request_handler को प्रतिक्रिया बनाने के लिए बहुत समय चाहिए? मान लीजिए कि वह किसी तरह का भारी कंप्यूटिंग ऑपरेशन करता है, जिसके समय, सिद्धांत रूप में, कुछ मिलीसेकंड को छोटा नहीं किया जा सकता है?

उपयोगकर्ताओं में से एक सोच सकता है कि चूंकि रेस्टिनियो काम करने वाले थ्रेड्स के पूल पर काम कर सकता है, इसलिए केवल बड़े पूल के आकार को निर्दिष्ट करें और यह है।

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

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

हमने इस योजना के एक उदाहरण पर विस्तार से देखा, जब हमने इस लेख में अपनी चिंराट डेमो परियोजना के बारे में बात की थी: " चिंराट: स्केल और शेयर HTTP इमेजेज इन मॉडर्न C ++, ImageMagic ++, SObjectizer, और Restinio का उपयोग करना ।"

अलग-अलग काम के धागे के लिए अनुरोध प्रसंस्करण प्रतिनिधि के उदाहरण

ऊपर, मैंने यह समझाने की कोशिश की कि request_handler के अंदर लम्बी प्रोसेसिंग करने की आवश्यकता क्यों नहीं है। स्पष्ट परिणाम कहां से आता है: लम्बी अनुरोध प्रसंस्करण को किसी अन्य कार्य थ्रेड में निर्दिष्ट किया जाना चाहिए। आइए देखें कि यह कैसे दिख सकता है।

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

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

सेविंग अनुरोध_हैंडल ऑब्जेक्ट

बुनियादी तकनीक जिस पर अनुरोध प्रसंस्करण का प्रतिनिधिमंडल बनाया गया है, वह कहीं न कहीं request_handle_t ऑब्जेक्ट का स्थानांतरण है।

जब RESTINIO उपयोगकर्ता द्वारा निर्दिष्ट आवक अनुरोध को संसाधित करने के लिए request_handler को कॉल करता है, तो इस request_handler को एक प्रकार की request_handle_t वस्तु दी जाती है। यह प्रकार प्राप्त अनुरोध के मापदंडों के लिए एक स्मार्ट पॉइंटर से अधिक कुछ नहीं है। इसलिए यदि किसी के लिए यह सोचना सुविधाजनक है कि request_handle_t है, तो आप सुरक्षित रूप से ऐसा सोच सकते हैं। यह shared_ptr है।

और चूँकि request_handle_t shared_ptr , इसलिए हम सुरक्षित रूप से इस स्मार्ट पॉइंटर को पास कर सकते हैं। हम नीचे दिए गए उदाहरणों में क्या करेंगे।

इसलिए, इसके साथ संवाद करने के लिए हमें एक अलग कार्य सूत्र और चैनल की आवश्यकता है। चलो यह सब बनाएँ:

 int main() { //  SObjectizer. so_5::wrapped_env_t sobj; //  std::thread    . std::thread processing_thread; //    main      join. //    RAII. auto processing_thread_joiner = so_5::auto_join(processing_thread); //      . auto req_ch = so_5::create_mchain(sobj); //       main. //    RAII. auto ch_closer = so_5::auto_close_drop_content(req_ch); //     . //      main()  - , //     ,      join(). processing_thread = std::thread{ processing_thread_func, req_ch };

वर्किंग थ्रेड का शरीर स्वयं processing_thread_func() फ़ंक्शन के अंदर स्थित है, जिसे हम थोड़ी देर बाद चर्चा करेंगे।

अब हमारे पास पहले से ही एक अलग काम करने वाला धागा और इसके साथ संचार के लिए एक चैनल है। आप RESTINIO सर्वर शुरू कर सकते हैं:

  // ,     . struct traits_t : public restinio::default_traits_t { using logger_t = restinio::shared_ostream_logger_t; }; restinio::run( restinio::on_this_thread<traits_t>() .port(8080) .address("localhost") .request_handler([req_ch](auto req) { //   GET-   . if(restinio::http_method_t::http_get == req->header().method() && "/" == req->header().path()) { //    . so_5::send<handle_request>(req_ch, req); return restinio::request_accepted(); } else return restinio::request_rejected(); }) .cleanup_func([&] { //      . //    , ..  req_ch //          //     . so_5::close_drop_content(req_ch); }));

इस सर्वर के लिए तर्क बहुत सरल है। यदि '/' के लिए एक GET अनुरोध आया है, तो हम एक एकल थ्रेड के अनुरोध को संसाधित करते हैं। ऐसा करने के लिए, हम दो महत्वपूर्ण कार्य करते हैं:

CSP चैनल को request_handle_t ऑब्जेक्ट भेजें। जबकि यह ऑब्जेक्ट CSP चैनल के अंदर या कहीं और संग्रहीत है, Restinio जानता है कि अनुरोध अभी भी जीवित है;
हम अनुरोध हैंडलर से मूल्य restinio::request_accepted() । यह Restinio को समझता है कि प्रसंस्करण के लिए अनुरोध स्वीकार कर लिया गया है और क्लाइंट के साथ कनेक्शन बंद नहीं किया जा सकता है।

यह तथ्य कि request_handler ने तुरंत Restinio प्रतिक्रिया उत्पन्न नहीं की है, परेशान नहीं करता है। एक बार restinio::request_accepted() वापस कर दिया गया, तो उपयोगकर्ता ने अनुरोध को संसाधित करने की जिम्मेदारी ली और किसी दिन अनुरोध का जवाब तैयार किया जाएगा।

यदि अनुरोध हैंडलर ने restinio::request_rejected() वापस कर restinio::request_rejected() , तो Restinio समझता है कि अनुरोध संसाधित नहीं होगा और क्लाइंट को 501 त्रुटि लौटाएगा।

इसलिए, हम प्रारंभिक परिणाम को ठीक करते हैं: request_handle_t उदाहरण को कहीं से भी पारित किया जा सकता है, क्योंकि यह वास्तव में, std::shared_ptr । जब यह उदाहरण जीवित है, Restinio मानता है कि अनुरोध संसाधित किया जा रहा है। यदि अनुरोध हैंडलर ने restinio::request_accepted() लौटाया restinio::request_accepted() , तो Restinio चिंता नहीं करेगा कि अनुरोध की प्रतिक्रिया अभी उत्पन्न नहीं हुई है।

अब हम इस अलग थ्रेड के कार्यान्वयन को देख सकते हैं:

 void processing_thread_func(so_5::mchain_t req_ch) { //       //    . std::random_device rd; std::mt19937 generator{rd()}; std::uniform_int_distribution<> pause_generator{350, 3500}; //      timeout_elapsed. auto delayed_ch = so_5::create_mchain(req_ch->environment()); //     -  . bool stop = false; select( so_5::from_all() //      . .on_close([&stop](const auto &) { stop = true; }) //     select(). //  select()     . .stop_on([&stop]{ return stop; }), //   handle_request     RESTinio. case_(req_ch, [&](handle_request cmd) { //     . const std::chrono::milliseconds pause{pause_generator(generator)}; //     . so_5::send_delayed<timeout_elapsed>(delayed_ch, //    timeout_elapsed. pause, //      timeout_elapsed. cmd.m_req, pause); }), //   timeout_elapsed. case_(delayed_ch, [](timeout_elapsed cmd) { //     . cmd.m_req->create_response() .set_body("Hello, World! (pause:" + std::to_string(cmd.m_pause.count()) + "ms)") .done(); }) ); }

यहाँ तर्क बहुत सरल है: हम एक प्रारंभिक_ संदेश के रूप में प्रारंभिक अनुरोध प्राप्त करते हैं और इसे कुछ यादृच्छिक समय के लिए विलंबित timeout_elapsed संदेश के रूप में स्वयं को अग्रेषित करते हैं। हम केवल timeout_elapsed प्राप्त होने पर अनुरोध का वास्तविक प्रसंस्करण करते हैं।

Upd। जब काम done() विधि को एक अलग कार्य सूत्र पर बुलाया जाता है, तो Restinio को सूचित किया जाता है कि एक तैयार प्रतिक्रिया प्रकट हुई है जिसे टीसीपी कनेक्शन के लिए लिखा जाना चाहिए। Restinio लिखने का कार्य आरंभ करता है, लेकिन I / O ऑपरेशन स्वयं निष्पादित नहीं किया जाएगा जहाँ done() कहा जाता है, लेकिन जहाँ RESTinio I / O करता है और request_handlers को कॉल करता है। यानी इस उदाहरण में, done() एक अलग कार्य थ्रेड पर कहा जाता है, और लेखन ऑपरेशन मुख्य थ्रेड पर किया जाएगा, जहां restinio::run() काम करता है।

संदेश स्वयं इस प्रकार हैं:

 struct handle_request { restinio::request_handle_t m_req; }; struct timeout_elapsed { restinio::request_handle_t m_req; std::chrono::milliseconds m_pause; };

यानी एक अलग काम करने वाला धागा request_handle_t लेता है और इसे तब तक बचाता है जब तक कि अवसर पूर्ण प्रतिक्रिया के लिए नहीं उठता। और जब यह अवसर पैदा होता है, तो create_response() को सहेजे गए अनुरोध ऑब्जेक्ट पर कॉल किया जाता है और प्रतिक्रिया Restinio पर वापस आ जाती है। तब Restinio पहले से ही अपने काम के संदर्भ में संबंधित ग्राहक के संबंध में प्रतिक्रिया लिखता है।

यहाँ, request_handle_t उदाहरण timeout_elapsed विलंबित संदेश में संग्रहीत है, क्योंकि इस आदिम उदाहरण में कोई वास्तविक प्रसंस्करण नहीं है। एक वास्तविक आवेदन में, request_handle_t को अनुरोध को संसाधित करने के लिए किसी प्रकार की कतार में या किसी वस्तु के अंदर संग्रहीत किया जा सकता है।

इस उदाहरण के लिए पूर्ण कोड नियमित Restinio उदाहरणों के बीच पाया जा सकता है।

कुछ छोटे कोड नोट

यह निर्माण RESTinio गुण सेट करता है जो RESTinio सर्वर में होना चाहिए:

  // ,     . struct traits_t : public restinio::default_traits_t { using logger_t = restinio::shared_ostream_logger_t; }; restinio::run( restinio::on_this_thread<traits_t>()

इस उदाहरण के लिए, मुझे Restinio को अपने अनुरोध प्रसंस्करण कार्यों को लॉग इन करने की आवश्यकता है। इसलिए, मैं डिफ़ॉल्ट null_logger_t से अलग होने के logger_t सेट logger_t null_logger_t । लेकिन कब से Restinio काम करेगा, वास्तव में, कई थ्रेड्स पर (RESTinio आने वाले अनुरोधों को मुख्य थ्रेड पर संसाधित करता है, लेकिन प्रतिक्रियाएँ एक अलग कार्य थ्रेड से आती हैं), फिर आपको थ्रेड-सुरक्षित लकड़हारा चाहिए, जो shared_ostream_logger_t ।

अंदर processing_thread_func() thread_func processing_thread_func() , SObjectizer फ़ंक्शन select() , जो कुछ हद तक गो सेलेक्ट कंस्ट्रक्शन के समान है: आप एक साथ कई चैनलों के संदेशों को पढ़ और प्रोसेस कर सकते हैं। select() फ़ंक्शन तब तक काम करता है जब तक कि सभी चैनल इसे बंद नहीं कर देते। या जब तक कि उसे जबरन यह न बताया जाए कि यह खत्म होने का समय है।

उसी समय, यदि रेस्टिनियो सर्वर के साथ संचार के लिए चैनल बंद है, तो काम जारी रखने का कोई मतलब नहीं है। इसलिए, select() , किसी भी चैनल को बंद करने की प्रतिक्रिया निर्धारित की जाती है: जैसे ही एक चैनल बंद होता है, स्टॉप फ्लैग को उठाया जाता है। और यह select() पूरा होने की ओर ले जाएगा select() और processing_thread_func() से बाहर निकलें_ processing_thread_func() ।

Response_builder ऑब्जेक्ट को सेव करना

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

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

इसके अलावा, यह हमारे लिए वांछनीय हो सकता है कि इन सभी भागों के चले जाने के रूप में हम उन्हें बनाते हैं। यानी पहले, उत्तर का पहला भाग ताकि ग्राहक इसे घटा सके, फिर दूसरा, फिर तीसरा, आदि।

Restinio आपको विभिन्न प्रकार के responce_builders के कारण ऐसा करने की अनुमति देता है। विशेष रूप से, user_controlled_output और chunked_output जैसे प्रकार।

इस मामले में, request_handle_t को बचाने के लिए पर्याप्त नहीं है, क्योंकि request_handle_t केवल उपयोगी होने तक ही पहली कॉल create_reponse() । आगे हमें response_builder के साथ काम करने की आवश्यकता है। खैर ...

ठीक है, यह ठीक है। रिस्पांस_बिल्डर एक जंगम प्रकार है, जो कुछ हद तक यूनिक_प्रटर के समान है। इसलिए हम भी इसे तब तक रख सकते हैं जब तक हमें इसकी आवश्यकता है। और यह दिखाने के लिए कि यह कैसा दिखता है, हम उपरोक्त उदाहरण को थोड़ा फिर से करते हैं। processing_thread_func() फ़ंक्शन को भागों में प्रतिक्रिया बनाते हैं।

यह बिल्कुल मुश्किल नहीं है।

पहले हमें उन प्रकारों पर निर्णय लेने की आवश्यकता है जो नए processing_thread_func() की आवश्यकता होगी:

 struct handle_request { restinio::request_handle_t m_req; }; //     . using output_t = restinio::chunked_output_t; //   reponse_builder-   . using response_t = restinio::response_builder_t<output_t>; //     . struct timeout_elapsed { response_t m_resp; int m_counter; };

handle_request संदेश अपरिवर्तित रहता है। लेकिन timeout_elapsed संदेश में timeout_elapsed अब हम request_handle_t संग्रहीत नहीं करते हैं, लेकिन हमें जिस प्रकार की आवश्यकता होती है, उसके response_builder। साथ ही शेष भागों का एक काउंटर। जैसे ही यह काउंटर रीसेट होता है, अनुरोध सेवा समाप्त हो जाती है।

अब हम processing_thread_func() फ़ंक्शन के नए संस्करण को देख सकते हैं:

 void processing_thread_func(so_5::mchain_t req_ch) { std::random_device rd; std::mt19937 generator{rd()}; std::uniform_int_distribution<> pause_generator{350, 3500}; auto delayed_ch = so_5::create_mchain(req_ch->environment()); bool stop = false; select( so_5::from_all() .on_close([&stop](const auto &) { stop = true; }) .stop_on([&stop]{ return stop; }), case_(req_ch, [&](handle_request cmd) { //    ,    . auto resp = cmd.m_req->create_response<output_t>(); resp.append_header( restinio::http_field::server, "RESTinio" ) .append_header_date_field() .append_header( restinio::http_field::content_type, "text/plain; charset=utf-8" ); //    ,  RESTinio //   . resp.flush(); //       . so_5::send_delayed<so_5::mutable_msg<timeout_elapsed>>(delayed_ch, //     . std::chrono::milliseconds{pause_generator(generator)}, //    timeout_elapsed. //     response_builder-  . std::move(resp), 3); }), case_(delayed_ch, [&](so_5::mutable_mhood_t<timeout_elapsed> cmd) { //      . cmd->m_resp.append_chunk( "this is the next part of the response\n" ); //  RESTinio   . cmd->m_resp.flush(); cmd->m_counter -= 1; if( 0 != cmd->m_counter ) { //        . so_5::send_delayed( delayed_ch, std::chrono::milliseconds{pause_generator(generator)}, std::move(cmd)); } else // ,   . cmd->m_resp.done(); }) ); }

यानी , . . .

Upd. flush() , done() : RESTinio , I/O- , flush() , , RESTinio - request_handler-. यानी flush() , , , restinio::run() .

, RESTinio :

 [2019-05-13 15:02:35.106] TRACE: starting server on 127.0.0.1:8080 [2019-05-13 15:02:35.106] INFO: init accept #0 [2019-05-13 15:02:35.106] INFO: server started on 127.0.0.1:8080 [2019-05-13 15:02:39.050] TRACE: accept connection from 127.0.0.1:49280 on socket #0 [2019-05-13 15:02:39.050] TRACE: [connection:1] start connection with 127.0.0.1:49280 [2019-05-13 15:02:39.050] TRACE: [connection:1] start waiting for request [2019-05-13 15:02:39.050] TRACE: [connection:1] continue reading request [2019-05-13 15:02:39.050] TRACE: [connection:1] received 78 bytes [2019-05-13 15:02:39.050] TRACE: [connection:1] request received (#0): GET / [2019-05-13 15:02:39.050] TRACE: [connection:1] append response (#0), flags: { not_final_parts, connection_keepalive }, write group size: 1 [2019-05-13 15:02:39.050] TRACE: [connection:1] start next write group for response (#0), size: 1 [2019-05-13 15:02:39.050] TRACE: [connection:1] start response (#0): HTTP/1.1 200 OK [2019-05-13 15:02:39.050] TRACE: [connection:1] sending resp data, buf count: 1, total size: 167 [2019-05-13 15:02:39.050] TRACE: [connection:1] outgoing data was sent: 167 bytes [2019-05-13 15:02:39.050] TRACE: [connection:1] finishing current write group [2019-05-13 15:02:39.050] TRACE: [connection:1] should keep alive [2019-05-13 15:02:40.190] TRACE: [connection:1] append response (#0), flags: { not_final_parts, connection_keepalive }, write group size: 3 [2019-05-13 15:02:40.190] TRACE: [connection:1] start next write group for response (#0), size: 3 [2019-05-13 15:02:40.190] TRACE: [connection:1] sending resp data, buf count: 3, total size: 42 [2019-05-13 15:02:40.190] TRACE: [connection:1] outgoing data was sent: 42 bytes [2019-05-13 15:02:40.190] TRACE: [connection:1] finishing current write group [2019-05-13 15:02:40.190] TRACE: [connection:1] should keep alive [2019-05-13 15:02:43.542] TRACE: [connection:1] append response (#0), flags: { not_final_parts, connection_keepalive }, write group size: 3 [2019-05-13 15:02:43.542] TRACE: [connection:1] start next write group for response (#0), size: 3 [2019-05-13 15:02:43.542] TRACE: [connection:1] sending resp data, buf count: 3, total size: 42 [2019-05-13 15:02:43.542] TRACE: [connection:1] outgoing data was sent: 42 bytes [2019-05-13 15:02:43.542] TRACE: [connection:1] finishing current write group [2019-05-13 15:02:43.542] TRACE: [connection:1] should keep alive [2019-05-13 15:02:46.297] TRACE: [connection:1] append response (#0), flags: { not_final_parts, connection_keepalive }, write group size: 3 [2019-05-13 15:02:46.297] TRACE: [connection:1] start next write group for response (#0), size: 3 [2019-05-13 15:02:46.297] TRACE: [connection:1] sending resp data, buf count: 3, total size: 42 [2019-05-13 15:02:46.297] TRACE: [connection:1] append response (#0), flags: { final_parts, connection_keepalive }, write group size: 1 [2019-05-13 15:02:46.297] TRACE: [connection:1] outgoing data was sent: 42 bytes [2019-05-13 15:02:46.298] TRACE: [connection:1] finishing current write group [2019-05-13 15:02:46.298] TRACE: [connection:1] should keep alive [2019-05-13 15:02:46.298] TRACE: [connection:1] start next write group for response (#0), size: 1 [2019-05-13 15:02:46.298] TRACE: [connection:1] sending resp data, buf count: 1, total size: 5 [2019-05-13 15:02:46.298] TRACE: [connection:1] outgoing data was sent: 5 bytes [2019-05-13 15:02:46.298] TRACE: [connection:1] finishing current write group [2019-05-13 15:02:46.298] TRACE: [connection:1] should keep alive [2019-05-13 15:02:46.298] TRACE: [connection:1] start waiting for request [2019-05-13 15:02:46.298] TRACE: [connection:1] continue reading request [2019-05-13 15:02:46.298] TRACE: [connection:1] EOF and no request, close connection [2019-05-13 15:02:46.298] TRACE: [connection:1] close [2019-05-13 15:02:46.298] TRACE: [connection:1] close: close socket [2019-05-13 15:02:46.298] TRACE: [connection:1] close: timer canceled [2019-05-13 15:02:46.298] TRACE: [connection:1] close: reset responses data [2019-05-13 15:02:46.298] TRACE: [connection:1] destructor called

, RESTinio 167 . , , RESTinio .

, RESTinio - response_builder , .

. , , . response_builder . , responce_builder , ..

, ?

, request_handler- - . , , ?

RESTinio , - request_handler-. - , , RESTinio . , . , :

 [2019-05-13 15:32:23.618] TRACE: starting server on 127.0.0.1:8080 [2019-05-13 15:32:23.618] INFO: init accept #0 [2019-05-13 15:32:23.618] INFO: server started on 127.0.0.1:8080 [2019-05-13 15:32:26.768] TRACE: accept connection from 127.0.0.1:49502 on socket #0 [2019-05-13 15:32:26.768] TRACE: [connection:1] start connection with 127.0.0.1:49502 [2019-05-13 15:32:26.768] TRACE: [connection:1] start waiting for request [2019-05-13 15:32:26.768] TRACE: [connection:1] continue reading request [2019-05-13 15:32:26.768] TRACE: [connection:1] received 78 bytes [2019-05-13 15:32:26.768] TRACE: [connection:1] request received (#0): GET / [2019-05-13 15:32:30.768] TRACE: [connection:1] handle request timed out [2019-05-13 15:32:30.768] TRACE: [connection:1] close [2019-05-13 15:32:30.768] TRACE: [connection:1] close: close socket [2019-05-13 15:32:30.768] TRACE: [connection:1] close: timer canceled [2019-05-13 15:32:30.768] TRACE: [connection:1] close: reset responses data [2019-05-13 15:32:31.768] WARN: [connection:1] try to write response, while socket is closed [2019-05-13 15:32:31.768] TRACE: [connection:1] destructor called

- . , , RESTinio , .. .

- handle_request_timeout , RESTinio- ( ).

निष्कर्ष

, , RESTinio — , . , RESTinio, , RESTinio, .

RESTinio , , , : ? - ? - ? - - ?

पुनश्च। RESTinio , SObjectizer, . , - RESTinio , : " C++ HTTP- ", " HTTP- C++: RESTinio, libcurl. 1 ", " Shrimp: HTTP C++ ImageMagic++, SObjectizer RESTinio "

Restinio एक एसिंक्रोनस HTTP सर्वर है। अतुल्यकालिक