"Boost.Asio C ++ नेटवर्क प्रोग्रामिंग।" अध्याय 7: Boost.Asio - अतिरिक्त विषय

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

सामग्री:

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

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

• यदि डिबगिंग विफल हो जाती है, तो आप देखेंगे कि Boost.Asio इसमें आपकी सहायता करेगा।
• यदि आपको एसएसएल के साथ काम करना है, तो देखें कि Boost.Asio आपको क्या पेशकश कर सकता है
• यदि आप एक विशिष्ट OC के लिए एक आवेदन लिख रहे हैं, तो देखें कि Boost.Asio में आपके लिए क्या अतिरिक्त सुविधाएँ हैं

Asio बनाम Boost.Asio

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

• Asio को asio:: के नाम स्थान में परिभाषित किया गया है asio:: , जबकि Boost.Asio को परिभाषित किया गया है boost::asio::
• asio.hpp में हेडर फ़ाइल asio.hpp और boost/asio.hpp में boost/asio.hpp है
• आसियो के पास सूत्र शुरू करने के लिए अपनी कक्षा है ( boost::thread )
• Asio त्रुटि कोड के लिए अपनी कक्षाएं प्रदान करता है ( asio::error_code boost::system::error_cod बजाय boost::system::error_cod और asio::system_error boost::system::system_error बजाय boost::system::system_error )

आप यहाँ आसियो के बारे में अधिक जानकारी प्राप्त कर सकते हैं ।
आपको खुद तय करना चाहिए कि आपको कौन सा विकल्प पसंद है; मैं व्यक्तिगत रूप से Boost.Asio को पसंद करता हूं। अपनी पसंद बनाते समय कुछ बातों पर ध्यान दें:

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

आप एक आवेदन में Asio और Boost.Asio का उपयोग कर सकते हैं, हालांकि, मैं आपको ऐसा करने के लिए अनुशंसा नहीं करता हूं। यह उद्देश्य पर काम नहीं कर सकता है, इस मामले में सब कुछ ठीक होगा, उदाहरण के लिए, यदि आप आसियो का उपयोग करते हैं, और कुछ तीसरे पक्ष के पुस्तकालय बूस्ट.एसियो और इसके विपरीत का उपयोग करते हैं।

डिबगिंग

एक सिंक्रोनस एप्लिकेशन को डीबग करना एक एसिंक्रोनस एप्लिकेशन को डीबग करने की तुलना में आमतौर पर आसान होता है। एक सिंक्रोनस एप्लिकेशन के लिए, यदि यह ब्लॉक हो जाता है, तो आप बस डिबगिंग में जाते हैं और जहां यह हुआ है उसकी एक तस्वीर प्राप्त करें (सिंक्रोनस का मतलब अनुक्रमिक)। हालाँकि, जब आप अतुल्यकालिक रूप से प्रोग्राम करते हैं, तो ईवेंट्स क्रमिक रूप से घटित नहीं होते हैं, इसलिए यदि कोई त्रुटि होती है, तो इसे पकड़ना वास्तव में मुश्किल होगा।
इससे बचने के लिए, सबसे पहले, आपको कोरटाइन में बहुत अच्छा होना चाहिए। यदि कार्यक्रम सही ढंग से लागू किया गया है, तो आपको व्यावहारिक रूप से कोई समस्या नहीं होगी।
जब यह अतुल्यकालिक प्रोग्रामिंग की बात आती है, तो Boost.Asio आपको मदद के लिए उधार देगा; Boost.Asio आपको हैंडलर ट्रैक करने की अनुमति देता है यदि BOOST_ASIO_ENABLE_HANDLER_TRACKING मैक्रो को BOOST_ASIO_ENABLE_HANDLER_TRACKING । यदि ऐसा है, तो Boost.Asio रिकॉर्डिंग समय, एक अतुल्यकालिक ऑपरेशन और इससे संबंधित समाप्ति हैंडलर द्वारा मानक त्रुटि आउटपुट स्ट्रीम को सूचना के उत्पादन की सुविधा प्रदान करता है।

हैंडलर ट्रैकिंग जानकारी

जानकारी को समझना आसान नहीं है, लेकिन फिर भी बहुत उपयोगी है। Boost.Asio का आउटपुट निम्न देता है:

 @asio|<timestamp>|<action>|<description>. 

पहला टैग हमेशा @asio , आप इसे Boost.Asio से आने वाले संदेशों को आसानी से फ़िल्टर करने के लिए उपयोग कर सकते हैं यदि अन्य स्रोत मानक त्रुटि स्ट्रीम ( std::cerr बराबर) को लिखते हैं। timestamp उदाहरण 1 जनवरी, 1970 यूटीसी से शुरू होने वाले सेकंड और माइक्रोसेकंड में गिना जाता है। एक action उदाहरण निम्नलिखित में से एक हो सकता है:

• >n : उपयोग किया जाता है जब हम हैंडलर को नंबर n के साथ दर्ज करते हैं। description उदाहरण में हैंडलर को दी गई दलीलें हैं।
• <n : हैंडलर नंबर n बंद होने पर उपयोग किया जाता है।
• !n उपयोग तब किया जाता है जब हम अपवाद के कारण हैंडलर n से बाहर निकलते हैं।
• ~n : उपयोग किया जाता है जब नंबर n के साथ हैंडलर बिना कॉल के नष्ट हो जाता है; शायद इसलिए कि io_service इंस्टेंस बहुत जल्दी नष्ट हो जाता है (n को कॉल करने का मौका मिलने से पहले)।
• n*m : का उपयोग तब किया जाता है जब n हैंडलर अंतिम हैंडलर संख्या m के साथ एक नया एसिंक्रोनस ऑपरेशन बनाता है। प्रारंभ के बाद, शुरू किया गया अतुल्यकालिक ऑपरेशन description उदाहरण में प्रदर्शित किया जाएगा। अंतिम हैंडलर तब कहा जाता है जब आप >m(start) और <m(end) ।
• n : उपयोग किया जाता है जब संख्या n के साथ एक हैंडलर एक ऑपरेशन करता है जो description में प्रदर्शित होता है (जो close या cancel ऑपरेशन हो सकता है)। आमतौर पर, आप उन्हें सुरक्षित रूप से अनदेखा कर सकते हैं।

जब भी n = 0, तब सभी हैंडलर को बाहर (असिंक्रोनस रूप से) निष्पादित किया जाता है, आमतौर पर, आप देखते हैं कि पहला ऑपरेशन (ऑपरेशन) कब किया जाता है या यदि आप सिग्नल के साथ काम कर रहे हैं और सिग्नल ट्रिगर हो गया है।
आपको संदेशों की तरह ध्यान देना चाहिए !n और ~n , जो तब होते हैं जब कोड में त्रुटियां होती हैं। पहले मामले में, अतुल्यकालिक फ़ंक्शन ने एक अपवाद नहीं फेंका, इसलिए अपवाद को आपके द्वारा फेंक दिया जाना चाहिए, आपको अपने अंतिम हैंडलर से बाहर निकलते समय अपवादों की अनुमति नहीं देनी चाहिए। बाद के मामले में, आपने शायद io_service उदाहरण को बहुत जल्द नष्ट कर दिया, इससे पहले कि सभी हैंडलर को पूरा किया गया था।

उदाहरण

आपको सहायक जानकारी का एक उदाहरण दिखाने के लिए, मैं अध्याय 6 से उदाहरण को संशोधित करता हूं। boost/asio.hpp चालू करने से पहले आपको केवल एक अतिरिक्त #define जोड़ना boost/asio.hpp :

 #define BOOST_ASIO_ENABLE_HANDLER_TRACKING #include <boost/asio.hpp> ... 

जब उपयोगकर्ता लॉग इन करता है और ग्राहकों की पहली सूची प्राप्त करता है तो हम कंसोल को डंप भी करेंगे। निष्कर्ष इस प्रकार होगा:

 @asio|1355603116.602867|0*1|socket@008D4EF8.async_connect @asio|1355603116.604867|>1|ec=system:0 @asio|1355603116.604867|1*2|socket@008D4EF8.async_send @asio|1355603116.604867|<1| @asio|1355603116.604867|>2|ec=system:0,bytes_transferred=11 @asio|1355603116.604867|2*3|socket@008D4EF8.async_receive @asio|1355603116.604867|<2| @asio|1355603116.605867|>3|ec=system:0,bytes_transferred=9 @asio|1355603116.605867|3*4|io_service@008D4BC8.post @asio|1355603116.605867|<3| @asio|1355603116.605867|>4| John logged in @asio|1355603116.606867|4*5|io_service@008D4BC8.post @asio|1355603116.606867|<4| @asio|1355603116.606867|>5| @asio|1355603116.606867|5*6|socket@008D4EF8.async_send @asio|1355603116.606867|<5| @asio|1355603116.606867|>6|ec=system:0,bytes_transferred=12 @asio|1355603116.606867|6*7|socket@008D4EF8.async_receive @asio|1355603116.606867|<6| @asio|1355603116.606867|>7|ec=system:0,bytes_transferred=14 @asio|1355603116.606867|7*8|io_service@008D4BC8.post @asio|1355603116.607867|<7| @asio|1355603116.607867|>8| John, new client list: John 

मुझे प्रत्येक पंक्ति का विश्लेषण करने दें:

• हम async_connect परिचय async_connect , जो हैंडलर 1 बनाता है (हमारे मामले में, हर कोई talk_to_svr::step प्रक्रिया talk_to_svr::step )
• हैंडलर 1 को कहा जाता है (सर्वर के सफल कनेक्शन के बाद)
• हैंडलर 1 को async_send कहते हैं, जो हैंडलर 2 बनाता है (यहां हम सर्वर पर लॉगिन के साथ संदेश भेजते हैं)
• हैंडलर 1 बंद
• हैंडलर 2 को कहा जाता है और 11 बाइट्स भेजता है ( login John )
• हैंडलर 2 को async_receive कहता है, जो हैंडलर 3 बनाता है (हम अपने लॉगिन संदेश का जवाब देने के लिए सर्वर की प्रतीक्षा करते हैं)
• हैंडलर 2 बंद
• हैंडलर 3 कहा जाता है और 9 बाइट्स प्राप्त करता है ( login ok )
• हैंडलर 3 on_answer_from_server (जहां हैंडलर 4 बनाया गया है) पर रीडायरेक्ट करता है
• हैंडलर 3 बंद
• हैंडलर 4 कहा जाता है, जो तब John logged in डंप John logged in को लिखता John logged in
• हैंडलर 4 एक और step (हैंडलर 5) शुरू करता है, जो ask_clients
• हैंडलर 4 बंद
• हैंडलर 5 खुलता है
• हैंडलर 5, async_send ask_clients , हैंडलर 6 बनाता है
• हैंडलर 5 बंद
• हैंडलर 6 पेश किया गया है (हमने सफलतापूर्वक सर्वर ask_clients भेजा है)
• हैंडलर 6 को async_receive कहता है, जो हैंडलर 7 बनाता है (हम मौजूदा क्लाइंट की सूची भेजने के लिए सर्वर की प्रतीक्षा करते हैं)
• हैंडलर 6 बंद
• हैंडलर 7 कहा जाता है और हम ग्राहकों की सूची को स्वीकार करते हैं
• हैंडलर 7 on_answer_from_serve (जहां हैंडलर 8 बनाया गया है) शुरू होता है
• हैंडलर 7 बंद
• हैंडलर 8 खुलता है, और डंप करने के लिए क्लाइंट ( on_clients ) की एक सूची लिखी जाती है

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

फ़ाइल पर हैंडलर ट्रैकिंग जानकारी लिखना

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

 some_application 2>err.txt 

यदि आप बहुत आलसी नहीं हैं, तो आप इसे प्रोग्रामेटिक रूप से कर सकते हैं, जैसा कि निम्नलिखित कोड टुकड़ा में दिखाया गया है:

 // for Windows HANDLE h = CreateFile("err.txt", GENERIC_WRITE, 0, 0, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL , 0); SetStdHandle(STD_ERROR_HANDLE, h); // for Unix int err_file = open("err.txt", O_WRONLY); dup2(err_file, STDERR_FILENO); 

एसएसएल

Boost.Asio कुछ बुनियादी एसएसएल सुविधाओं का समर्थन करने के लिए कक्षाएं प्रदान करता है। अंदर, वह OpenSSL का उपयोग करती है। इसलिए यदि आप एसएसएल का उपयोग करना चाहते हैं, तो पहले ओपनएसएसएल डाउनलोड और निर्माण करें। यह ध्यान दिया जाना चाहिए कि, एक नियम के रूप में, OpenSSL का निर्माण एक आसान काम नहीं है, खासकर यदि आपके पास विज़ुअल स्टूडियो जैसे लोकप्रिय संकलक नहीं हैं।
यदि आपने सफलतापूर्वक OpenSSL संकलित किया है, तो Boost.Asio के पास इसके लिए कुछ ऐड-ऑन कक्षाएं हैं:

• ssl::stream : ip::::socket बजाय इस्तेमाल किया जाता है ip::::socket क्लास
  ssl::context : यह सत्र शुरू करने का संदर्भ है
  ssl::rfc2818_verification : यह वर्ग एक आसान तरीका है, जो कि सर्टिफिकेट को होस्टनाम द्वारा सत्यापित किया जाता है, जैसे कि ssl::rfc2818_verification अनुसार
  
  
  अगले कुछ लेखों में मैं कई पुस्तकों के पहले अध्यायों (तीन, शायद 4) का अनुवाद प्रस्तुत करना चाहता हूं, जो आपको अधिक प्रसन्न करेगा, और मैं पहले अनुवाद करना जारी रखूंगा।
  
  आप सभी को धन्यवाद, जल्द ही मिलते हैं!