हाल ही में, मैं एक ऐसे एप्लिकेशन पर काम करने के लिए हुआ था जो इसके आउटगोइंग कनेक्शन की गति को नियंत्रित करने वाला था। उदाहरण के लिए, एक URL से कनेक्ट होने पर, एप्लिकेशन को स्वयं को 200KiB / सेकंड तक सीमित करना चाहिए। और दूसरे URL से कनेक्ट हो रहा है - केवल 30KiB / sec।

यहाँ सबसे दिलचस्प बिंदु इन्हीं सीमाओं का परीक्षण कर रहा था। मुझे एक HTTP सर्वर की आवश्यकता थी जो कुछ दिए गए गति से ट्रैफ़िक दे, उदाहरण के लिए, 512KiB / sec। तब मैं देख सकता था कि क्या एप्लिकेशन वास्तव में 200KiB / सेकंड की गति को रोक देता है या यदि यह उच्च गति तक टूट जाता है।

लेकिन ऐसा HTTP सर्वर कहां से मिलेगा?

चूँकि मुझे C ++ एप्लिकेशन में एम्बेडेड Restinio HTTP सर्वर के साथ कुछ करना है, इसलिए मैं अपने घुटने पर एक साधारण HTTP टेस्ट सर्वर को फेंकने से बेहतर कुछ भी नहीं कर सकता हूं जो क्लाइंट को आउटगोइंग डेटा की एक लंबी स्ट्रीम भेज सकता है।

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

सामान्य विचार

ऊपर उल्लिखित परीक्षण सर्वर का सामान्य विचार बहुत ही सरल है: जब कोई क्लाइंट सर्वर से जुड़ता है और HTTP GET अनुरोध करता है, तो एक टाइमर सक्रिय होता है जो एक सेकंड में एक बार चलता है। जब टाइमर को ट्रिगर किया जाता है, तो किसी दिए गए आकार का अगला डेटा ब्लॉक क्लाइंट को भेजा जाता है।

लेकिन सब कुछ थोड़ा और जटिल है

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

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

यह उचित लगता है, लेकिन I / O संचालन RESTinio की बाइबिल में छिपे हुए हैं ... मैं कैसे पता लगा सकता हूं कि डेटा का अगला टुकड़ा लिखा जा सकता है या नहीं?

आप इस स्थिति से बाहर निकल सकते हैं यदि आप आफ्टर-राइट नोटिफ़ायर का उपयोग करते हैं, जो कि रेस्टिनियो में हैं। उदाहरण के लिए, हम इसे लिख सकते हैं:

void request_handler(restinio::request_handle_t req) { req->create_response() //   . ... //   . .done([](const auto & ec) { ... //         . }); } 

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

आफ्टर-राइट नोटिफ़ायर के उपयोग के कारण, परीक्षण सर्वर का तर्क निम्नानुसार होगा:

• डेटा के अगले बैच को भेजें, उस समय की गणना करें जब हमें घटनाओं के सामान्य पाठ्यक्रम में अगले बैच को भेजने की आवश्यकता होगी;
• हम डेटा के अगले हिस्से पर नोटिफ़ायर लिखने के बाद हैंग करते हैं;
• जब लिखने के बाद अधिसूचना को बुलाया जाता है, तो हम यह देखने के लिए जांच करते हैं कि क्या अगला बैच आ गया है। यदि ऐसा होता है, तो तुरंत अगले भाग को भेजने की पहल करें। यदि ऐसा नहीं होता है, तो टाइमर को कॉक करें।

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

और थोड़ा और अधिक जटिल: chunked_output

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

इसलिए, वर्णित परीक्षण सर्वर तथाकथित का उपयोग करता है chunked_output । यानी उत्तर बनाते समय, मैं Restinio को इंगित करता हूं कि उत्तर भागों में बनेगा। तब मैं बस समय-समय पर append_chunk तरीकों को कॉल करता append_chunk ताकि अगले भाग को उत्तर में जोड़ा जा सके और संचित भागों को सॉकेट में लिखने के लिए flush किया जा सके।

और कोड में देखते हैं!

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

अनुरोध_प्रोसेसर फ़ंक्शन और उसके सहायक

HTTP GET अनुरोधों को संसाधित करने के लिए request_processor फ़ंक्शन को कहा जाता है। इसे तर्कों के रूप में पारित किया जाता है:

• Asio-shny io_context जिस पर सभी कार्य किए जाते हैं (यह आवश्यक होगा, उदाहरण के लिए, मुर्गा लगाने के लिए);
• प्रतिक्रिया के एक हिस्से का आकार। यानी यदि मुझे 512KiB / सेकंड की दर से एक आउटगोइंग स्ट्रीम देने की आवश्यकता है, तो 512KiB मान को इस पैरामीटर के रूप में पारित किया जाएगा;
• प्रतिक्रिया में भागों की संख्या। मामले में धारा कुछ सीमित होनी चाहिए। उदाहरण के लिए, यदि आप 5 मिनट के लिए 512KiB / सेकंड की दर से एक स्ट्रीम देना चाहते हैं, तो मान 300 इस पैरामीटर के रूप में पारित किया जाएगा (5 मिनट के लिए प्रति मिनट 60 ब्लॉक);
• खैर, आने वाले अनुरोध खुद प्रसंस्करण के लिए।

request_processor अंदर, अनुरोध और उसके प्रसंस्करण मापदंडों के बारे में जानकारी के साथ एक ऑब्जेक्ट बनाया जाता है, जिसके बाद यह बहुत प्रसंस्करण शुरू होता है:

 void request_processor( asio_ns::io_context & ctx, std::size_t chunk_size, std::size_t count, restinio::request_handle_t req) { auto data = std::make_shared<response_data>( ctx, chunk_size, req->create_response<output_t>(), count); data->response_ .append_header(restinio::http_field::server, "RESTinio") .append_header_date_field() .append_header( restinio::http_field::content_type, "text/plain; charset=utf-8") .flush(); send_next_portion(data); } 

response_data प्रकार, जिसमें अनुरोध से संबंधित सभी पैरामीटर हैं, इस तरह दिखता है:

 struct response_data { asio_ns::io_context & io_ctx_; std::size_t chunk_size_; response_t response_; std::size_t counter_; response_data( asio_ns::io_context & io_ctx, std::size_t chunk_size, response_t response, std::size_t counter) : io_ctx_{io_ctx} , chunk_size_{chunk_size} , response_{std::move(response)} , counter_{counter} {} }; 

यहां यह ध्यान दिया जाना चाहिए कि response_data संरचना की उपस्थिति के कारणों में से एक यह है कि प्रकार restinio::response_builder_t<restinio::chunked_output_t> की एक वस्तु restinio::response_builder_t<restinio::chunked_output_t> (अर्थात, यह प्रकार संक्षिप्त रूप से अन्य नाम के पीछे छिपा हुआ है response_t ) एक चल प्रकार है, लेकिन एक प्रतिलिपि प्रकार नहीं है (द्वारा) std::unique_ptr साथ सादृश्य std::unique_ptr )। इसलिए, यह ऑब्जेक्ट सिर्फ एक लंबो फ़ंक्शन में कैप्चर नहीं किया जा सकता है, जो तब std::function में खुद को लपेटता है। लेकिन यदि आप प्रतिक्रिया ऑब्जेक्ट को प्रतिक्रियाशील_डेटा के गतिशील रूप से बनाए गए उदाहरण में रखते response_data , तो reponse_data उदाहरण के लिए स्मार्ट पॉइंटर को पहले से ही समस्याओं के बिना लैम्ब्डा फ़ंक्शन में कैप्चर किया जा सकता है, और फिर इस लैम्ब्डा को std::function सेव करें।

Send_next_portion फ़ंक्शन

send_next_portion फ़ंक्शन send_next_portion हर बार कॉल किया जाता है, जब क्लाइंट की प्रतिक्रिया के अगले भाग को भेजना आवश्यक होता है। इसमें कुछ भी जटिल नहीं है, इसलिए यह काफी सरल और संक्षिप्त लगता है:

 void send_next_portion(response_data_shptr data) { data->response_.append_chunk(make_buffer(data->chunk_size_)); if(1u == data->counter_) { data->response_.flush(); data->response_.done(); } else { data->counter_ -= 1u; data->response_.flush(make_done_handler(data)); } } 

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

फंक्शन मेक_डोन_हैंडलर

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

सामान्य तौर पर, सरल क्रियाएं, लेकिन कोड में आपको लैम्ब्डा के अंदर लैम्बडा मिलता है, जो उन लोगों को भ्रमित कर सकता है जो "आधुनिक" सी ++ के लिए उपयोग नहीं किए जाते हैं। जिसे आधुनिक कहलाने के लिए इतने साल नहीं हैं;)

 auto make_done_handler(response_data_shptr data) { const auto next_timepoint = steady_clock::now() + 1s; return [=](const auto & ec) { if(!ec) { const auto now = steady_clock::now(); if(now < next_timepoint) { auto timer = std::make_shared<asio_ns::steady_timer>(data->io_ctx_); timer->expires_after(next_timepoint - now); timer->async_wait([timer, data](const auto & ec) { if(!ec) send_next_portion(data); }); } else data->io_ctx_.post([data] { send_next_portion(data); }); } }; } 

मेरी राय में, इस कोड में मुख्य कठिनाई असियो में टाइमर और निर्माण की ख़ासियत से उपजी है। मेरी राय में, यह किसी भी तरह निकलता है। लेकिन वास्तव में है, वह है। लेकिन आपको किसी भी अतिरिक्त पुस्तकालयों को आकर्षित करने की आवश्यकता नहीं है।

एक एक्सप्रेस-राउटर से कनेक्ट करना

ऊपर दिखाया गया request_processor , send_next_portion और make_done_handler send_next_portion में मेरे परीक्षण सर्वर का पहला संस्करण बना है, जिसका शाब्दिक अर्थ 15 या 20 मिनट में लिखा गया है।

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

फिर यह विचार सामने आया: क्या होगा यदि रिटर्न की गति सीधे यूआरएल में मांगी जाए? उदाहरण के लिए, उन्होंने localhost:8080/ लिए एक अनुरोध किया और एक पूर्व निर्धारित गति पर प्रतिक्रिया प्राप्त की। और अगर आपने localhost:8080/128K लिए अनुरोध किया, तो उन्हें 128KiB / सेकंड की गति से प्रतिक्रिया मिलनी शुरू हो गई।

फिर विचार और भी आगे बढ़ गया: URL में आप प्रतिक्रिया में व्यक्तिगत भागों की संख्या भी निर्दिष्ट कर सकते हैं। यानी localhost:8080/128K/3000 अनुरोध localhost:8080/128K/3000 128KiB / सेकंड की गति से 3000 भागों की एक धारा का उत्पादन करेगा।

कोई बात नहीं। Restinio में ExpressJS के प्रभाव में बने क्वेरी राउटर का उपयोग करने की क्षमता है। नतीजतन, आने वाले HTTP अनुरोधों के लिए हैंडलर का वर्णन करने के लिए ऐसा एक समारोह था:

 auto make_router(asio_ns::io_context & ctx) { auto router = std::make_unique<router_t>(); router->http_get("/", [&ctx](auto req, auto) { request_processor(ctx, 100u*1024u, 10000u, std::move(req)); return restinio::request_accepted(); }); router->http_get( R"(/:value(\d+):multiplier([MmKkBb]?))", [&ctx](auto req, auto params) { const auto chunk_size = extract_chunk_size(params); if(0u != chunk_size) { request_processor(ctx, chunk_size, 10000u, std::move(req)); return restinio::request_accepted(); } else return restinio::request_rejected(); }); router->http_get( R"(/:value(\d+):multiplier([MmKkBb]?)/:count(\d+))", [&ctx](auto req, auto params) { const auto chunk_size = extract_chunk_size(params); const auto count = restinio::cast_to<std::size_t>(params["count"]); if(0u != chunk_size && 0u != count) { request_processor(ctx, chunk_size, count, std::move(req)); return restinio::request_accepted(); } else return restinio::request_rejected(); }); return router; } 

यहां HTTP GET अनुरोध हैंडलर तीन प्रकार के URL के लिए बनाए गए हैं:

• फॉर्म http://localhost/ ;
• http://localhost/<speed>[<U>]/ ;
• फार्म का http://localhost/<speed>[<U>]/<count>/

जहां speed एक संख्या है जो गति को परिभाषित करती है, और U एक वैकल्पिक गुणक है जो इंगित करता है कि किस इकाई में गति निर्धारित है। तो 128 या 128 128b अर्थ है प्रति सेकंड 128 बाइट्स की गति। और 128k प्रति किलोग्राम 128 किलोबाइट है।

प्रत्येक URL का अपना स्वयं का लंबर फ़ंक्शन होता है, जो प्राप्त मापदंडों को समझता है, यदि सबकुछ ठीक है, तो यह ऊपर दिए गए request_processor फ़ंक्शन को कॉल करता है।

सहायक समारोह extract_chunk_size निम्नानुसार है:

 std::size_t extract_chunk_size(const restinio::router::route_params_t & params) { const auto multiplier = [](const auto sv) noexcept -> std::size_t { if(sv.empty() || "B" == sv || "b" == sv) return 1u; else if("K" == sv || "k" == sv) return 1024u; else return 1024u*1024u; }; return restinio::cast_to<std::size_t>(params["value"]) * multiplier(params["multiplier"]); } 

यहां, C ++ लंबोदर का उपयोग अन्य प्रोग्रामिंग भाषाओं से स्थानीय कार्यों का अनुकरण करने के लिए किया जाता है।

मुख्य समारोह

यह देखना बाकी है कि मुख्य समारोह में यह सब कैसे चलता है:

 using router_t = restinio::router::express_router_t<>; ... int main() { struct traits_t : public restinio::default_single_thread_traits_t { using logger_t = restinio::single_threaded_ostream_logger_t; using request_handler_t = router_t; }; asio_ns::io_context io_ctx; restinio::run( io_ctx, restinio::on_this_thread<traits_t>() .port(8080) .address("localhost") .write_http_response_timelimit(60s) .request_handler(make_router(io_ctx))); return 0; } 

यहाँ क्या हो रहा है:

1. चूंकि मुझे अनुरोधों के एक सामान्य नियमित राउटर की आवश्यकता नहीं है (जो कि कुछ भी नहीं कर सकता है और प्रोग्रामर के कंधों पर सारा काम डालता है), मैं अपने HTTP सर्वर के लिए नए गुणों को परिभाषित करता हूं। ऐसा करने के लिए, मैं एकल-थ्रेडेड HTTP सर्वर के मानक गुण (प्रकार restinio::default_single_thread_traits_t ) restinio::default_single_thread_traits_t और इंगित करता restinio::default_single_thread_traits_t कि एक्सप्रेस-जैसे राउटर का एक उदाहरण अनुरोध हैंडलर के रूप में उपयोग किया जाएगा। उसी समय, अंदर क्या हो रहा है, इसे नियंत्रित करने के लिए, मैं इंगित करता हूं कि HTTP सर्वर एक वास्तविक लकड़हारा (डिफ़ॉल्ट रूप से, null_logger_t उपयोग किया जाता है जो कुछ भी लॉग नहीं करता null_logger_t उपयोग करता है।
2. चूँकि मुझे लिखने के बाद के नोटिफ़ायर के अंदर टाइमर को लगाने की ज़रूरत है, मुझे एक io_context उदाहरण की आवश्यकता है जिसके साथ मैं काम कर सकता था। इसलिए, मैं इसे स्वयं बनाता हूं। यह मुझे make_router फ़ंक्शन में मेरे io_context के लिंक को पास करने का अवसर देता है।
3. यह केवल केवल पहले बनाए गए io_context पर एक-थ्रेडेड संस्करण में HTTP सर्वर को शुरू करने के लिए बना हुआ है। restinio::run फ़ंक्शन तभी नियंत्रण वापस करेगा जब एचटीटीपी सर्वर अपना काम पूरा कर लेगा।

निष्कर्ष

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

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

सामान्य तौर पर, यदि किसी और ने Restinio की कोशिश नहीं की है, तो मैं आपको कोशिश करने के लिए आमंत्रित करता हूं। प्रोजेक्ट खुद GitHub पर रहता है । आप एक प्रश्न पूछ सकते हैं या अपने सुझाव Google समूह में या यहीं टिप्पणियों में व्यक्त कर सकते हैं।