"Boost.Asio C ++ नेटवर्क प्रोग्रामिंग।" अध्याय 2: Boost.Asio की मूल बातें भाग २

सभी को नमस्कार!
मैं जॉन टोरजो की पुस्तक Boost.Asio C ++ नेटवर्क प्रोग्रामिंग का अनुवाद करना जारी रखता हूं। दूसरे अध्याय के इस भाग में हम अतुल्यकालिक प्रोग्रामिंग के बारे में बात करेंगे।

सामग्री:

• अध्याय 1: Boost.Asio के साथ शुरुआत करना
• अध्याय 2: बूस्ट.आसियो मूल बातें
  
  • भाग 1: Boost.Asio की मूल बातें
  • भाग 2: अतुल्यकालिक प्रोग्रामिंग
• अध्याय 3: इको सर्वर / क्लाइंट
• अध्याय 4: क्लाइंट और सर्वर
• अध्याय 5: सिंक्रोनस बनाम एसिंक्रोनस
• अध्याय 6: Boost.Asio - अन्य विशेषताएं
• अध्याय 7: Boost.Asio - अतिरिक्त विषय

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

अतुल्यकालिक रूप से काम करने की आवश्यकता

जैसा कि मैंने कहा, एक नियम के रूप में, तुल्यकालिक प्रोग्रामिंग एसिंक्रोनस की तुलना में बहुत सरल है। क्योंकि रैखिक रूप से सोचना बहुत आसान है (हम फ़ंक्शन ए कहते हैं, इसके अंत के बाद हम इसके हैंडलर कहते हैं, हम फ़ंक्शन बी कहते हैं, इसके अंत के बाद हम इसके हैंडलर कहते हैं, और इसी तरह, ताकि हम घटना-हैंडलर तरीके से सोच सकें)। उत्तरार्द्ध मामले में, आप कह सकते हैं, पांच घटनाएं और आप कभी भी उस क्रम का पता नहीं लगा पाएंगे जिसमें वे प्रदर्शन कर रहे हैं, और आपको पता भी नहीं चलेगा कि क्या वे सभी पूरे होंगे!
लेकिन भले ही अतुल्यकालिक प्रोग्रामिंग अधिक जटिल है, आप शायद इसे लिखना पसंद करेंगे, सर्वर लिखने में, जो एक ही समय में बड़ी संख्या में ग्राहकों से निपटने की आवश्यकता है। आपके पास जितने अधिक ग्राहक हैं, अतुल्यकालिक प्रोग्रामिंग की तुलना सिंक्रोनस से की जाती है।
मान लीजिए कि आपके पास एक ऐसा एप्लिकेशन है जो एक साथ 1000 क्लाइंट्स के साथ काम करता है, क्लाइंट से सर्वर तक और सर्वर से क्लाइंट तक प्रत्येक संदेश कैरेक्टर 'n' के साथ समाप्त होता है।
तुल्यकालिक कोड, 1 धागा:

using namespace boost::asio; struct client { ip::tcp::socket sock; char buff[1024]; // each msg is at maximum this size int already_read; // how much have we already read? }; std::vector<client> clients; void handle_clients() { while ( true) for ( int i = 0; i < clients.size(); ++i) if ( clients[i].sock.available() ) on_read(clients[i]); } void on_read(client & c) { int to_read = std::min( 1024 - c.already_read, c.sock. available()); c.sock.read_some( buffer(c.buff + c.already_read, to_read)); c.already_read += to_read; if ( std::find(c.buff, c.buff + c.already_read, '\n') < c.buff + c.already_read) { int pos = std::find(c.buff, c.buff + c.already_read, '\n') - c.buff; std::string msg(c.buff, c.buff + pos); std::copy(c.buff + pos, c.buff + 1024, c.buff); c.already_read -= pos; on_read_msg(c, msg); } } void on_read_msg(client & c, const std::string & msg) { // analyze message, and write back if ( msg == "request_login") c.sock.write( "request_ok\n"); else if ... } 

सर्वर को लिखने से बचना चाहते हैं (और मूल रूप से कोई भी नेटवर्क एप्लिकेशन) कोड को रोकने के लिए है। हमारे मामले में, हम चाहते हैं कि handle_clients() फ़ंक्शन यथासंभव कम अवरुद्ध हो। यदि फ़ंक्शन किसी भी बिंदु पर अवरुद्ध है, तो क्लाइंट से आने वाले सभी संदेश फ़ंक्शन के अनलॉक होने तक इंतजार करेंगे और उन्हें संसाधित करना शुरू करेंगे।
प्रतिक्रियाशील बने रहने के लिए, हम केवल एक सॉकेट से पढ़ेंगे जब उसमें डेटा होगा, वह है, if ( clients[i].sock.available() ) on_read(clients[i]) । On_read में, हम केवल उतना ही पढ़ेंगे जितना उपलब्ध है; read_until(c.sock, buffer(...),'\n') को कॉल करना एक अच्छा विचार नहीं होगा, क्योंकि यह तब तक ब्लॉक होता है जब तक हम किसी विशिष्ट क्लाइंट से संदेश को अंत तक नहीं पढ़ते हैं (हम कभी नहीं जान पाएंगे कि यह कब होगा) ।
यहां अड़चन on_read_msg() फ़ंक्शन है; इस फ़ंक्शन को निष्पादित किए जाने तक सभी आने वाले संदेशों को रोक दिया जाएगा। अच्छी तरह से लिखा फ़ंक्शन on_read_msg() यह सुनिश्चित करेगा कि ऐसा नहीं होता है, लेकिन ऐसा हो सकता है (कभी-कभी सॉकेट पर लिखना अवरुद्ध हो सकता है, उदाहरण के लिए, यदि इसका बफर भरा हुआ है)।
तुल्यकालिक कोड, 10 धागे:

 using namespace boost::asio; struct client { // ... same as before bool set_reading() { boost::mutex::scoped_lock lk(cs_); if ( is_reading_) return false; // already reading else { is_reading_ = true; return true; } } void unset_reading() { boost::mutex::scoped_lock lk(cs_); is_reading_ = false; } private: boost::mutex cs_; bool is_reading_; }; std::vector<client> clients; void handle_clients() { for ( int i = 0; i < 10; ++i) boost::thread( handle_clients_thread); } void handle_clients_thread() { while ( true) for ( int i = 0; i < clients.size(); ++i) if ( clients[i].sock.available() ) if ( clients[i].set_reading()) { on_read(clients[i]); clients[i].unset_reading(); } } void on_read(client & c) { // same as before } void on_read_msg(client & c, const std::string & msg) { // same as before } 

कई थ्रेड्स का उपयोग करने के लिए, हमें उन्हें सिंक्रनाइज़ करने की आवश्यकता है, जो कि set_reading () और set_unreading() फ़ंक्शन करते हैं। set_reading() फ़ंक्शन बहुत महत्वपूर्ण है। आप "जांचना चाहते हैं कि क्या आप पढ़ सकते हैं और पढ़ना शुरू कर सकते हैं" एक चरण में किया गया था। यदि आपने इसे दो चरणों में किया है ("जाँचें कि क्या पढ़ना संभव है" और "पढ़ना शुरू करें"), तो आप दो सूत्र शुरू कर सकते हैं: एक ग्राहक के लिए on_read की on_read लिए, दूसरा उसी ग्राहक के लिए on_read फ़ंक्शन को कॉल करने के लिए। लंबे समय में, इससे डेटा भ्रष्टाचार हो सकता है और संभवतः सिस्टम क्रैश भी हो सकता है।
आप देखेंगे कि कोड अधिक जटिल होता जा रहा है।
एक तीसरा विकल्प तुल्यकालिक कोड के लिए भी संभव है, अर्थात् प्रति ग्राहक एक धागा। लेकिन जैसे-जैसे साथ-साथ ग्राहकों की संख्या बढ़ती है, यह काफी हद तक एक अपर्याप्त ऑपरेशन बन जाता है।
अब अतुल्यकालिक विकल्पों पर विचार करें। हमने लगातार एक एसिंक्रोनस रीड ऑपरेशन किया। जब ग्राहक एक अनुरोध करता है, तो on_read ऑपरेशन on_read , हम जवाब देते हैं, और फिर अगले अनुरोध के आने का इंतजार करते हैं (हम एक और अतुल्यकालिक रीड ऑपरेशन शुरू करते हैं)।
अतुल्यकालिक कोड, 10 धागे:

 using namespace boost::asio; io_service service; struct client { ip::tcp::socket sock; streambuf buff; // reads the answer from the client } std::vector<client> clients; void handle_clients() { for ( int i = 0; i < clients.size(); ++i) async_read_until(clients[i].sock, clients[i].buff, '\n', boost::bind(on_read, clients[i], _1, _2)); for ( int i = 0; i < 10; ++i) boost::thread(handle_clients_thread); } void handle_clients_thread() { service.run(); } void on_read(client & c, const error_code & err, size_t read_bytes) { std::istream in(&c.buff); std::string msg; std::getline(in, msg); if ( msg == "request_login") c.sock.async_write( "request_ok\n", on_write); else if ... ... // now, wait for the next read from the same client async_read_until(c.sock, c.buff, '\n', boost::bind(on_read, c, _1, _2)); } 

ध्यान दें कि कोड कितना आसान हो गया है। client संरचना में केवल दो सदस्य हैं, handle_clients() सिर्फ handle_clients() कॉल करता है, और फिर दस थ्रेड बनाता है, जिनमें से प्रत्येक कॉल service.run() । ये धागे क्लाइंट के लिए सभी अतुल्यकालिक पढ़ने या लिखने के संचालन को संभालेंगे। ध्यान देने वाली एक और बात यह है कि on_read() फ़ंक्शन लगातार अगले एसिंक्रोनस रीड ऑपरेशन के लिए तैयार करेगा (अंतिम पंक्ति देखें)।

अतुल्यकालिक कार्य चलते हैं (), run_one (), poll (), poll_one ()

एक सुनने वाले लूप को लागू करने के लिए, io_service वर्ग चार फ़ंक्शन प्रदान करता है, जैसे run(), run_one(), poll() , और poll_one() । यद्यपि अधिकांश समय आप service.run() साथ काम कर रहे होंगे। यहां आप सीखेंगे कि आप अन्य कार्यों की मदद से क्या हासिल कर सकते हैं।

लगातार काम कर रहे हैं

एक बार फिर, run() लंबित कार्यों के पूरा होने तक या जब तक आप स्वयं io_service::stop() कॉल नहीं करेंगे तब तक काम करेंगे। एक io_service उदाहरण को काम पर रखने के लिए, आप आमतौर पर एक या अधिक अतुल्यकालिक ऑपरेशन जोड़ते हैं, और जब वे समाप्त होते हैं, तो आप जोड़ना जारी रखते हैं, जैसा कि निम्नलिखित कोड में दिखाया गया है:

 using namespace boost::asio; io_service service; ip::tcp::socket sock(service); char buff_read[1024], buff_write[1024] = "ok"; void on_read(const boost::system::error_code &err, std::size_t bytes) ; void on_write(const boost::system::error_code &err, std::size_t bytes) { sock.async_read_some(buffer(buff_read), on_read); } void on_read(const boost::system::error_code &err, std::size_t bytes) { // ... process the read ... sock.async_write_some(buffer(buff_write,3), on_write); } void on_connect(const boost::system::error_code &err) { sock.async_read_some(buffer(buff_read), on_read); } int main(int argc, char* argv[]) { ip::tcp::endpoint ep( ip::address::from_string("127.0.0.1"), 2001); sock.async_connect(ep, on_connect); service.run(); } 

जब service.run() कहा जाता है, तो कम से कम एक अतुल्यकालिक ऑपरेशन इंतजार कर रहा है। जब सॉकेट सर्वर से on_connect है, तो on_connect , जो एक अन्य एसिंक्रोनस ऑपरेशन जोड़ता है। on_connect के अंत के बाद, हमारे पास अभी भी एक अनुसूचित ऑपरेशन ( read ) है। जब on_read ऑपरेशन on_read , तो हम प्रतिक्रिया लिखते हैं, एक और अनुसूचित ऑपरेशन ( write ) जोड़ा जाता है। जब on_write फ़ंक्शन को on_write , तो हम सर्वर से निम्न संदेश पढ़ते हैं, जो एक अन्य अनुसूचित ऑपरेशन को जोड़ देगा। जब on_write फ़ंक्शन on_write , तो हमारे पास एक अनुसूचित ऑपरेशन ( read ) होता है। और इसलिए चक्र तब तक जारी रहता है जब तक हम एप्लिकेशन को बंद करने का निर्णय नहीं लेते।

कार्य run_one (), जनमत (), poll_one ()

यह पहले उल्लेख किया गया था कि एसिंक्रोनस फ़ंक्शन हैंडलर को उसी थ्रेड में कहा जाता है जिसमें io_service::run कहा जाता था। यह सरलता के लिए नोट किया गया है, क्योंकि कम से कम 90 से 95 प्रतिशत समय केवल एक ही कार्य है जिसका आप उपयोग करेंगे। run_one(), poll() , या poll_one() कॉल के लिए भी run_one(), poll() सच है।
run_one() फ़ंक्शन निष्पादित करेगा और एक से अधिक अतुल्यकालिक ऑपरेशन भेजेगा:

• यदि कोई निर्धारित संचालन नहीं हैं, तो फ़ंक्शन तुरंत समाप्त होता है और 0 देता है
• यदि लंबित संचालन हैं, तो पहले ऑपरेशन के कार्यात्मक ब्लॉकों को निष्पादित किया जाता है और 1 वापस किया जाता है

आप निम्नलिखित समकक्ष कोड पर विचार कर सकते हैं:

 io_service service; service.run(); // OR while ( !service.stopped()) service.run_once(); 

आप एसिंक्रोनस ऑपरेशन शुरू करने के लिए run_once() का उपयोग कर सकते हैं, और फिर इसके पूरा होने तक प्रतीक्षा कर सकते हैं:

 io_service service; bool write_complete = false; void on_write(const boost::system::error_code & err, size_t bytes) { write_complete = true; } ... std::string data = "login ok"; write_complete = false; async_write(sock, buffer(data), on_write); do service.run_once() while (!write_complete); 

ऐसे कुछ उदाहरण भी हैं जो run_one() साथ बंडल किए गए run_one() उपयोग करते हैं, उदाहरण के लिए block_tcp_client.cpp और block_udp_client.cpp। poll_one फ़ंक्शन लॉन्च किए गए एक से अधिक लंबित ऑपरेशन को अवरुद्ध किए बिना चलाने के लिए तैयार है:

• यदि कम से कम एक लंबित ऑपरेशन, बिना अवरोध के शुरू करने के लिए तैयार है, तो run_one() इसे शुरू करेगा और 1 वापस करेगा
• अन्यथा, फ़ंक्शन तुरंत बाहर निकलता है और 0 देता है।

एक लंबित ऑपरेशन, जो बिना किसी अवरोध के शुरू होने के लिए तैयार है, आमतौर पर निम्नलिखित में से एक है:

• एक टाइमर जो समाप्त हो गया है और इसके async_wait हैंडलर द्वारा बुलाया जाना चाहिए
• एक I / O ऑपरेशन जो पूरा हो गया है (उदाहरण के लिए, async_read ) और उसके हैंडलर को बुलाया जाना चाहिए
• एक कस्टम हैंडलर जो पहले io_services उदाहरण io_services जोड़ा गया था (इसे अगले भाग में विस्तार से बताया गया है)

आप यह सत्यापित करने के लिए कि मैं / ओ संचालन के लिए सभी हैंडलर चल रहे हैं और निम्नलिखित कार्यों के लिए आगे बढ़ने के लिए poll_one का उपयोग कर सकते हैं:

 io_service service; while ( true) { // run all handlers of completed IO operations while ( service.poll_one()) ; // ... do other work here ... } 

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

 io_service service; service.poll(); // OR while ( service.poll_one()) ; 

पिछले सभी कार्य boost::system::system_error विफलता के मामले में boost::system::system_error । लेकिन ऐसा कभी नहीं होना चाहिए; यहां फेंकी गई त्रुटि आमतौर पर दुर्घटना की ओर ले जाती है, हो सकता है कि यह एक संसाधन त्रुटि हो या आपके किसी हैंडलर ने अपवाद छोड़ दिया हो। किसी भी स्थिति में, प्रत्येक फ़ंक्शन में एक अधिभार होता है जो अपवादों को नहीं फेंकता है, लेकिन boost::system::error_code एक तर्क के रूप में और रिटर्न मान के रूप में सेट करता है।

 io_service service; boost::system::error_code err = 0; service.run(err); if ( err) std::cout << "Error " << err << std::endl; 

अतुल्यकालिक ऑपरेशन

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

 #include <boost/thread.hpp> #include <boost/bind.hpp> #include <boost/asio.hpp> #include <iostream> using namespace boost::asio; io_service service; void func(int i) { std::cout << "func called, i= " << i << std::endl; } void worker_thread() { service.run(); } int main(int argc, char* argv[]) { for ( int i = 0; i < 10; ++i) service.post(boost::bind(func, i)); boost::thread_group threads; for ( int i = 0; i < 3; ++i) threads.create_thread(worker_thread); // wait for all threads to be created boost::this_thread::sleep( boost::posix_time::millisec(500)); threads.join_all(); } 

पिछले उदाहरण में, service.post(some_function) एक एसिंक्रोनस फ़ंक्शन कॉल जोड़ता है। यह फ़ंक्शन तुरंत एक io_service आवृत्ति का अनुरोध करने के बाद बाहर निकलता है, जो इस थ्रेड में से किसी एक में कॉल करने के लिए service.run() कहता है। हमारे मामले में, हमने अग्रिम में तीन थ्रेड्स में से एक बनाया। आप सुनिश्चित नहीं हो सकते हैं कि किस क्रम में एसिंक्रोनस फ़ंक्शंस को बुलाया जाएगा। आपको उनसे यह उम्मीद नहीं करनी चाहिए कि उन्हें उस क्रम में बुलाया जाएगा जिसे उन्होंने ( post() ) जोड़ा था। पिछले उदाहरण का एक संभावित परिणाम निम्नानुसार है:

 func called, i= 0 func called, i= 2 func called, i= 1 func called, i= 4 func called, i= 3 func called, i= 6 func called, i= 7 func called, i= 8 func called, i= 5 func called, i= 9 

एक समय हो सकता है जब आप किसी असिंक्रोनस फ़ंक्शन के लिए हैंडलर असाइन करना चाहते हैं। मान लीजिए कि आपको एक रेस्तरां में जाना है ( go_to_restaurant ), एक order और खाएं ( eat )। आप पहले रेस्तरां में आना चाहते हैं, एक ऑर्डर करते हैं और उसके बाद ही खाना खाते हैं। ऐसा करने के लिए, आप io_service::strand उपयोग करेंगे, जो कॉल करने के लिए अतुल्यकालिक हैंडलर को असाइन करेगा। निम्नलिखित उदाहरण पर विचार करें:

 using namespace boost::asio; io_service service; void func(int i) { std::cout << "func called, i= " << i << "/" << boost::this_thread::get_id() << std::endl; } void worker_thread() { service.run(); } int main(int argc, char* argv[]) { io_service::strand strand_one(service), strand_two(service); for ( int i = 0; i < 5; ++i) service.post( strand_one.wrap( boost::bind(func, i))); for ( int i = 5; i < 10; ++i) service.post( strand_two.wrap( boost::bind(func, i))); boost::thread_group threads; for ( int i = 0; i < 3; ++i) threads.create_thread(worker_thread); // wait for all threads to be created boost::this_thread::sleep( boost::posix_time::millisec(500)); threads.join_all(); } 

उपरोक्त कोड में, हम देखते हैं कि पहली पाँच और अंतिम पाँच स्ट्रीम आईडी क्रमिक रूप से प्रदर्शित की जाती हैं, अर्थात्, func called, i = 0 को func called, i = 1 से पहले प्रदर्शित किया जाएगा, जिसे func called, i = 2 और इससे पहले प्रदर्शित किया जाएगा । वही func called, i = 5 लिए चला जाता है func called, i = 5 जो कि func called, i = 6 आउटपुट के लिए होगा func called, i = 6 और func called, i = 6 को func called, i = 7 और इसी तरह से आउटपुट होगा। यह ध्यान दिया जाना चाहिए कि भले ही कार्यों को क्रमिक रूप से कहा जाता है, इसका मतलब यह नहीं है कि वे सभी एक ही धागे में बुलाए जाएंगे। इस कार्यक्रम का एक संभावित कार्यान्वयन इस प्रकार हो सकता है:

 func called, i= 0/002A60C8 func called, i= 5/002A6138 func called, i= 6/002A6530 func called, i= 1/002A6138 func called, i= 7/002A6530 func called, i= 2/002A6138 func called, i= 8/002A6530 func called, i= 3/002A6138 func called, i= 9/002A6530 func called, i= 4/002A6138 

अतुल्यकालिक पोस्ट () बनाम प्रेषण () बनाम रैप ()

Boost.Asio एक अतुल्यकालिक कॉल के लिए एक फ़ंक्शन हैंडलर जोड़ने के लिए तीन तरीके प्रदान करता है:

• service.post(handler) : यह फ़ंक्शन सुनिश्चित करता है कि यह निर्दिष्ट हैंडलर को कॉल करने के लिए io_service उदाहरण के लिए अनुरोध करने के तुरंत बाद io_service । हैंडलर को बाद में थ्रेड्स में से एक में बुलाया जाएगा जिसे service.run() कहा जाता है।
• service.dispatch(handler) : यह निर्दिष्ट हैंडलर को कॉल करने के लिए io_service उदाहरण के लिए एक अनुरोध है, लेकिन, इसके अलावा, यह फ़ंक्शन के अंदर हैंडलर को कॉल कर सकता है यदि वर्तमान थ्रेड को service.run() कहा जाता है।
• service.wrap(handler) : यह फंक्शन एक रैपर फंक्शन बनाता है, जो service.dispatch(handler) । यह थोड़ा भ्रमित करने वाला है, मैं जल्द ही इसका मतलब बताऊंगा।

आपने पिछले अनुभाग में service.post() का उपयोग करने का एक उदाहरण, साथ ही कार्यक्रम के निष्पादन का एक संभावित परिणाम देखा। इसे बदलें और देखें कि service.dispatch परिणाम को कैसे प्रभावित करता है:

 using namespace boost::asio; io_service service; void func(int i) { std::cout << "func called, i= " << i << std::endl; } void run_dispatch_and_post() { for ( int i = 0; i < 10; i += 2) { service.dispatch(boost::bind(func, i)); service.post(boost::bind(func, i + 1)); } } int main(int argc, char* argv[]) { service.post(run_dispatch_and_post); service.run(); } 

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

 func called, i= 0 func called, i= 2 func called, i= 4 func called, i= 6 func called, i= 8 func called, i= 1 func called, i= 3 func called, i= 5 func called, i= 7 func called, i= 9 

पहले, यहां तक ​​कि संख्याएं भी लिखी जाती हैं, और फिर विषम। इसका कारण यह है कि हम संख्याओं और post() को लिखने के लिए dispatch() का उपयोग करते हैं dispatch() विषम संख्याएँ लिखने के लिए। dispatch() हैंडलर को बाहर निकलने से पहले कॉल करेगा क्योंकि वर्तमान थ्रेड ने service.run() कहा है, जबकि पोस्ट () अभी बाहर निकलता है।
अब बात करते हैं service.wrap(handler) । रैप () एक फ़नकार देता है जिसे दूसरे फ़ंक्शन के तर्क के रूप में उपयोग किया जा सकता है:

 using namespace boost::asio; io_service service; void dispatched_func_1() { std::cout << "dispatched 1" << std::endl; } void dispatched_func_2() { std::cout << "dispatched 2" << std::endl; } void test(boost::function<void()> func) { std::cout << "test" << std::endl; service.dispatch(dispatched_func_1); func(); } void service_run() { service.run(); } int main(int argc, char* argv[]) { test( service.wrap(dispatched_func_2)); boost::thread th(service_run); boost::this_thread::sleep( boost::posix_time::millisec(500)); th.join(); } 

स्ट्रिंग test(service.wrap(dispatched_func_2)); डिस्पैच_फंचc_2 को लपेटेंगे और एक फ़नकार बनायेंगे जिसे एक तर्क के रूप में test करने के लिए पास किया जाएगा। जब test() कहा जाता है, तो यह कॉल को func() और कॉल func() पुनर्निर्देशित करता है। इस बिंदु पर, आप देखेंगे कि कॉलिंग func() service.dispatch(dispatched_func_2) बराबर है, क्योंकि उन्हें क्रमिक रूप से कहा जाता है। कार्यक्रम आउटपुट इसकी पुष्टि करता है:

 test dispatched 1 dispatched 2 

io_service::strand क्लास (अतुल्यकालिक कार्यों को क्रमबद्ध करने के लिए उपयोग किया जाता है) में फंक्शन poll(), dispatch() और wrap() । उनका अर्थ poll(), dispatch() और wrap() io_service । हालाँकि, अधिकांश समय आप केवल io_service::strand::wrap() फ़ंक्शन का उपयोग io_service::poll() या io_service::dispatch() तर्क के रूप में करेंगे।

जिंदा रहने के लिए

आप निम्नलिखित ऑपरेशन करके कहेंगे:

 io_service service; ip::tcp::socket sock(service); char buff[512]; ... read(sock, buffer(buff)); 

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

 io_service service; ip::tcp::socket sock(service); char buff[512]; void on_read(const boost::system::error_code &, size_t) {} ... async_read(sock, buffer(buff), on_read); 

इस मामले में, sock और buff को स्वयं read ऑपरेशन से बचना चाहिए, लेकिन हम नहीं जानते कि यह कब होगा, क्योंकि यह अतुल्यकालिक है।
सॉकेट बफ़र्स का उपयोग करते समय, आपके पास buffer का एक उदाहरण हो सकता है जो एक एसिंक्रोनस कॉल से बच गया था ( boost::shared_array<> का उपयोग करके boost::shared_array<> यहां हम एक ही सिद्धांत का उपयोग करके एक वर्ग बना सकते हैं जिसमें आंतरिक रूप से सॉकेट होता है और बफ़र्स को पढ़ा / लिखा जाता है। फिर सभी अतुल्यकालिक कॉल के लिए, हम boost::bind देते हैं boost::bind एक साझा पॉइंटर के साथ फन्डर को boost::bind :

 using namespace boost::asio; io_service service; struct connection : boost::enable_shared_from_this<connection> { typedef boost::system::error_code error_code; typedef boost::shared_ptr<connection> ptr; connection() : sock_(service), started_(true) {} void start(ip::tcp::endpoint ep) { sock_.async_connect(ep, boost::bind(&connection::on_connect, shared_from_this(), _1)); } void stop() { if ( !started_) return; started_ = false; sock_.close(); } bool started() { return started_; } private: void on_connect(const error_code & err) { // here you decide what to do with the connection: read or write if ( !err) do_read(); else stop(); } void on_read(const error_code & err, size_t bytes) { if ( !started() ) return; std::string msg(read_buffer_, bytes); if ( msg == "can_login") do_write("access_data"); else if ( msg.find("data ") == 0) process_data(msg); else if ( msg == "login_fail") stop(); } void on_write(const error_code & err, size_t bytes) { do_read(); } void do_read() { sock_.async_read_some(buffer(read_buffer_), boost::bind(&connection::on_read, shared_from_this(), _1, _2)); } void do_write(const std::string & msg) { if ( !started() ) return; // note: in case you want to send several messages before // doing another async_read, you'll need several write buffers! std::copy(msg.begin(), msg.end(), write_buffer_); sock_.async_write_some(buffer(write_buffer_, msg.size()), boost::bind(&connection::on_write, shared_from_this(), _1, _2)); } void process_data(const std::string & msg) { // process what comes from server, and then perform another write } private: ip::tcp::socket sock_; enum { max_msg = 1024 }; char read_buffer_[max_msg]; char write_buffer_[max_msg]; bool started_; }; int main(int argc, char* argv[]) { ip::tcp::endpoint ep( ip::address::from_string("127.0.0.1"), 8001); connection::ptr(new connection)->start(ep); } 

सभी अतुल्यकालिक कॉल में, boost::bind फ़न्क्टर को एक तर्क के रूप में भेजा जाता है। यह फ़नकार आंतरिक रूप से connection उदाहरण के लिए एक साझा पॉइंटर संग्रहीत करता है। जबकि एसिंक्रोनस ऑपरेशन लंबित है, Boost.Asio boost::bind की एक प्रति संग्रहीत करेगा boost::bind फ़नकार, जो बदले में connection लिए एक साझा सूचक को संग्रहीत करता है। समस्या हल हो गई!
बेशक, connection वर्ग सिर्फ skeleton वर्ग है; आपको इसे अपनी आवश्यकताओं के अनुकूल बनाना होगा (सर्वर के मामले में, यह पूरी तरह से अलग दिखेगा)। ध्यान दें कि आप कितनी आसानी से एक नया कनेक्शन connection::ptr(new connection)->start(ep) बनाते हैं connection::ptr(new connection)->start(ep) । यह सर्वर के लिए एक (एसिंक्रोनस) कनेक्शन शुरू करता है। यदि आप कनेक्शन बंद करना चाहते हैं, तो आप stop() ।
एक बार उदाहरण शुरू हो गया है ( start() ), यह कनेक्शन के लिए इंतजार करेगा। जब कोई कनेक्शन होता है, तो on_connect() कहा जाता है। यदि कोई त्रुटि नहीं है, तो रीड ऑपरेशन ( do_read() ) कहा जाता है। एक बार रीड ऑपरेशन पूरा हो जाने के बाद, आप संदेश की व्याख्या कर सकते हैं; आपके आवेदन में सबसे अधिक संभावना on_read() अलग on_read() । जब आप एक संदेश भेजते हैं, तो आपको इसे बफर में कॉपी करना होगा, और फिर इसे भेजना होगा, जैसा कि do_write() में किया गया है, क्योंकि, फिर से, बफर को एसिंक्रोनस राइट ऑपरेशन से बचना चाहिए। और आखिरी नोट - जब रिकॉर्डिंग करते हैं, तो याद रखें कि आपको यह निर्दिष्ट करना होगा कि कितना लिखना है, अन्यथा पूरे बफर को भेजा जाएगा।

सारांश

नेटवर्क एपीआई बहुत व्यापक है। इस अध्याय को एक लिंक के रूप में लागू किया गया था, जिस पर आपको उस समय वापस लौटना चाहिए जब आप अपने स्वयं के नेटवर्क एप्लिकेशन को लागू करेंगे।
Boost.Asio एंडपॉइंट की अवधारणा को लागू करता है, जिसे आप आईपी पते और पोर्ट के रूप में सोच सकते हैं। यदि आपको सटीक आईपी पता नहीं है, तो आप एक या अधिक आईपी पते के बजाय www.yahoo.com जैसे होस्ट नाम को शामिल करने के लिए resolver ऑब्जेक्ट का उपयोग कर सकते हैं।
हमने सॉकेट क्लासेस को भी देखा जो कोर एपीआई में हैं। Boost.Asio टीसीपी, यूडीपी और आईसीएमपी के लिए कार्यान्वयन प्रदान करता है, लेकिन आप इसे अपने स्वयं के प्रोटोकॉल के लिए बढ़ा सकते हैं, हालांकि यह दिल के बेहोश होने के लिए नहीं है।
अतुल्यकालिक प्रोग्रामिंग एक आवश्यक बुराई है। आपने देखा कि कभी-कभी यह आवश्यक क्यों होता है, विशेष रूप से सर्वर लिखते समय। आम तौर पर, कॉल करने के लिए run_one(), poll() आपके लिए एक अतुल्यकालिक लूप बनाने के लिए पर्याप्त होगा, लेकिन कभी-कभी आपको आगे जाने की आवश्यकता होती है और फिर आप run_one(), poll() , या poll_one() उपयोग कर सकते हैं।
अतुल्यकालिक दृष्टिकोण का उपयोग करते समय, आपके पास अपने स्वयं के अतुल्यकालिक कार्य हो सकते हैं, बस उपयोग service.post()या service.dispatch()।
अंत में, एसिंक्रोनस ऑपरेशन की पूरी अवधि के दौरान वैध रहने के लिए सॉकेट और बफर (पढ़ने या लिखने के लिए) दोनों के लिए, हमें विशेष सावधानी बरतनी चाहिए। आपकी कक्षा connectionसे व्युत्पन्न होना चाहिए enabled_shared_from_this, सभी आवश्यक बफ़र्स को अपने भीतर समाहित करें और हर असिंक्रोनस कॉल के साथ इस ऑपरेशन में एक साझा पॉइंटर पास करें।
अगला अध्याय बहुत व्यावहारिक कार्य होगा; क्लाइंट / सर्वर गूंज जैसे अनुप्रयोगों को लागू करते समय बहुत सारे अनुप्रयोग कोडिंग।

आप सभी को धन्यवाद, जल्द ही मिलते हैं!