ट्रांस्ड लाइब्रेरी 4: आर्किटेक्चर को कैसे व्यवस्थित किया जाता है

शुभ दोपहर, आज मैं अपने पुस्तकालय के बारे में बात करना जारी रखना चाहता हूं, विचार के समर्थकों को खोजने की उम्मीद है।
यह पोस्ट ट्रांसेंड लाइब्रेरी 4 की एक निरंतरता है : परिचय , टिप्पणियों में चर्चा का तार्किक विकास।

मैं कोड तोड़ने के बजाय एक नया पोस्ट क्यों लिख रहा हूं

- एक साधारण कारण है। का कारण बनता है।

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

त्याग

मैं महत्वाकांक्षी, युवा, बेवकूफ और आत्मविश्वासी हूं। मैक्सिमिज़्म अभी तक मर नहीं गया है और कई बार पैदा होता है। लेकिन फिर भी, अधिक या कम समझदार तर्क के बाद, कोड खोलना और ओपन सोर्स पर जाना मुझे लगता है कि साथी डेवलपर्स को पहली बिक्री और किराया कर्मचारियों से पैसा कमाने की तुलना में अधिक सरल और अधिक यथार्थवादी तरीका लगता है।

पैटर्न

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

TL4

asynchrony

नेटवर्क प्रकृति

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

भीड़ से निवेदन करें

नेटवर्क का उपयोग करने के लिए एक और लागत है - प्रत्येक कॉल समय के लायक है। बहुत अच्छा समय रहा। यह एक संसाधन को मुक्त करने, एक ऑपरेटिंग सिस्टम को कतारबद्ध करने और इस तरह से खर्च किया जाता है। उदाहरण के लिए, हम 1000 डीएनएस अनुरोध करना चाहते हैं। प्रत्येक कॉल की लागत 1ms (पर्याप्त समय, कभी-कभी अधिक) दें, इसका मतलब है कि हम कॉल पर केवल एक सेकंड खो देंगे। इस समय, एक ही थ्रेड में चल रहा हमारा एप्लिकेशन FPS के माध्यम से "सिंक" करेगा, और उपयोगकर्ता फ्रीज को नीले रंग से बाहर देखेगा।
इसके अलावा, वास्तव में, ड्राइवर सिस्टम में सभी अनुप्रयोगों के लिए 50 (छत से संख्या) अनुरोध करता है।
मैं समझता हूं कि कहीं न कहीं ऐसा करना न्यायसंगत हो सकता है (और ऐसा होने के लिए एक सेटिंग है), लेकिन सिस्टम को रियलटाइम अनुप्रयोगों के लिए विकसित किया गया था, और यह उनमें अस्वीकार्य है।

कार्य निष्पादन आदेश

आपके OpenConnection अनुरोध पर, लाइब्रेरी स्मृति को आवंटित करने और बदले में नौकरी निर्धारित करने के अलावा कुछ नहीं करती है। सभी ऑपरेशन स्थानीय पता स्थान और स्थानीय स्ट्रीम में होते हैं, इस वजह से वे तेज़ होते हैं।
वास्तविक प्रतिनिधिमंडल तब होता है जब रिस्पॉन्स कहा जाता है, जो कार्यों को स्कैन करता है और टाइमआउट से पहले एक के बाद एक प्रदर्शन करता है।
हमारे उदाहरण में, यह पहले 50 अनुरोधों के बाद, एक कनेक्शन स्थापित करने के लिए शुरू करने की अनुमति देता है, और यह संभव है (यदि यह सफल होता है) सभी 1000 पतों को प्राप्त करने से पहले सूचना का आदान-प्रदान शुरू करना (या पूरा करना)।
आंतरिक डिवाइस की तुलना घटना-संचालित वास्तुकला से की जा सकती है, सिवाय इसके कि घटनाओं की अधिसूचना पर्यवेक्षक पैटर्न के अनुसार नहीं होती है।

प्राथमिकता कार्य

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

संबंधित कार्य

फ़ीचर रिलीज़ में या आर्किटेक्चर में प्रदान नहीं किया गया है, लेकिन वहाँ सामंजस्यपूर्ण रूप से फिट बैठता है।
एक दूसरे के बिना तलवार, बनावट, मॉडल और आइकन की विशेषताएं बहुत मायने नहीं रखती हैं। लेकिन एक ही समय में, विशेषताओं और आइकन को बताना तर्कसंगत होगा, जिससे मॉडल को लोड करने के लिए इंतजार किए बिना हथियारों का उपयोग करना संभव होगा।
बनावट और मॉडल संचरण के दौरान माता-पिता की प्राथमिकता को विरासत में लेंगे, और उनकी प्राथमिकता रिश्तेदार ऑफसेट द्वारा दी जाएगी। यह गुणांक का चयन करने के लिए रहता है ताकि स्थानांतरण समय पर हो सके।

गतिशील प्राथमिकता

हमारे बहु-गीगाबाइट यात्रा को समाप्त होने दें, और सिस्टम में कम प्राथमिकता है। और इसी क्षण ( 99.9% ) तत्काल डेटा के कई मेगाबाइट को स्थानांतरित करने की आवश्यकता थी। इस तथ्य के बावजूद कि काल्पनिक टमटम एक दर्जन किलोबाइट में बदल गया।
यहां डेटा की शेष और बफर राशि के आधार पर कार्य की प्राथमिकता को बदलना बेहद उचित होगा।
मैं पुस्तकालय में अपने वर्तमान समाधान की तरह नहीं हूं, मुझे इसके बारे में सोचने की जरूरत है और अगर मैं इसे सुधार सकता हूं।

मेमोरी डिवाइस

डेटा भंडारण मॉडल

एक जटिल प्रणाली में, आपको विभिन्न स्थानों से एक संसाधन तक पहुंचने की आवश्यकता हो सकती है। उदाहरण के लिए, chat_listener और attack_listener एक संदेश भेजना चाहते हैं। इसके अलावा, उनमें से प्रत्येक का कनेक्शन का अपना सेट है।
डेटा के दोहराव और वंशानुक्रम से बचने के लिए, उपयोगकर्ता को दी गई वस्तुओं में डेटाबेस के लिए कुंजी का भंडारण उपयोग किया जाता है ( निकटतम यहां ब्रिज है , केवल संग्रहीत डेटा के लिए )।
डेटाबेस प्रति वर्चुअल नेटवर्क में से एक है (यही कारण है कि उसी नेटवर्क के भीतर डेटा ऑपरेशन स्ट्रीम के लिए सुरक्षित नहीं हैं), और इसमें संग्रहीत सभी डेटा की तरह, इसे साझा किया गया है स्वयं के माध्यम से प्रबंधित_ स्वयं_ नियंत्रित ।

स्मृति के लिए जिम्मेदारी

कार्य की प्रकृति के कारण, उपयोगकर्ता आवंटित मेमोरी पर पूर्ण नियंत्रण नहीं रख सकता है।
पुस्तकालय का विचार - "शिपमेंट पर रखने के लिए और सुनिश्चित करें कि यह पहुंच जाएगा" कुछ हद तक जहर है, अगर आपको भी पालन करना है और जब यह आता है और हटा दें।
अजीब तरह से पर्याप्त है, सामान्य मामले में पुस्तकालय भी नहीं जानता है कि वास्तव में ऑब्जेक्ट को कब हटाया जाना चाहिए। वह जानती है कि इसे स्थानांतरित किया जाना चाहिए, वह जानती है कि यह हस्तांतरण कब पूरा होगा, लेकिन क्या इसके बाद इसे हटा दिया जाना चाहिए? केवल वस्तु ही यह जानती है। ( हे भगवान वह इसे हटाने का उपयोग करता है )

कचरा इकट्ठा करने वाला

बड़े शब्द जो पूरी तरह से उस तत्व को प्रतिबिंबित नहीं करते हैं जो हो रहा है। लेकिन यह दूर से ऐसा है - जैसे ही किसी को ऑब्जेक्ट की आवश्यकता नहीं होती है, इसे हटा दिया जाता है। आप इसे share_ptr से बचा सकते हैं, सिवाय इसके कि वस्तु स्वयं एक कंटेनर और एक वस्तु दोनों है।
share_self_conrolled का शाब्दिक अर्थ है निम्नलिखित। किसी वस्तु को साझा किया जा सकता है (जैसा कि एक साधारण self_controlled का विरोध किया जाता है), और जब उसे आत्म-विनाश की आवश्यकता होती है, तो उसे ट्रैक रखना चाहिए (जैसा कि साझा के विपरीत)।
जैसे ही ऑब्जेक्ट को स्थानांतरित किया गया, पुस्तकालय को इसकी आवश्यकता नहीं है, यह उपयोगकर्ताओं की सूची से खुद को मारता है। यदि वे शून्य हो जाते हैं - कोई अन्य वस्तु से संपर्क नहीं कर सकता है, तो इसकी आवश्यकता नहीं है।

डाटा प्रोसेसिंग

पढना स्थगित कर दिया

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

धागा तनाव

यदि हम मशीन को रस्सी (इस तरह के खिलौने) से खींचना चाहते हैं, तो यह केवल तभी जाएगा जब पूरा धागा खींच लिया जाएगा। बल एक परत से दूसरी परत में समान रूप से प्रेषित होगा। अगर किसी जगह पर कठोरता दूसरों की तुलना में कम है - तो यह खिंचाव होगा, सारा बोझ खुद पर ले लेगा।
जब डेटा हैंडलर लाइन अप करते हैं, तो हमें इस बात में कोई दिलचस्पी नहीं है कि बीच में क्या होता है। केवल सिरों पर यातायात।
हमारे पास एक डीकंप्रेस हैंडलर है जो कंप्रेस्ड डेटा को डिकम्प्रेस करता है और क्लाइंट को 30 बाइट्स की जरूरत होती है। जब विघटित होता है, तो इस वॉल्यूम को प्राप्त करने के लिए केवल 5 बाइट्स ऑफ सोर्स डेटा का उपयोग किया गया था। नैतिक यह है कि प्रत्येक लिंक जानता है कि अगले से कितना आवश्यक है, और अधिक कुछ नहीं। यह पुस्तकालय में परिलक्षित होता है - सभी गणना अनुरोध पर की जाती हैं।

कैशिंग

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

निष्कर्ष

मुझे आशा है कि इस पोस्ट के साथ मैं उन विचारों को प्रकट करने में सक्षम था जो लाइब्रेरी बनाने के कारण के रूप में कार्य करते थे, और यह मेरे लिए प्रतिस्पर्धी क्यों लगता है। मेरा यह भी मानना ​​है कि कई डेयरडेविल्स इतने अद्भुत (आईएमएचओ) के निर्माण में भाग लेना चाहेंगे, जैसा कि यहां प्रस्तावित वास्तुकला है।
यह निश्चित रूप से परियोजना में छिपे हुए सभी विचारों के लिए नहीं है, उनमें से कुछ अवचेतन में चले गए हैं और अस्थि मज्जा में छिपे हुए हैं, स्पष्ट प्रतीत होते हैं। ये केवल सबसे महत्वपूर्ण हैं, और दिमाग में आते हैं।
"हमें सिखाया जाता है कि एक आदमी की परियोजना को याद न रखें, लेकिन एक विचार, क्योंकि एक आदमी कमजोर है, और उसे पकड़ा जा सकता है, उसे मारा जा सकता है और भुला दिया जा सकता है। लेकिन एक विचार और 400 साल बाद दुनिया बदल सकती है। ” “ V का अर्थ है वेंडेट्टा ”
अच्छा सप्ताहांत है।