प्रोटोकॉल के बारे में एक शब्द कहें ... या चलो एक केतली को एक साथ डिज़ाइन करें!

वास्तव में, न केवल प्रोटोकॉल के बारे में, बल्कि जटिल प्रणालियों की बातचीत के तर्क के बारे में भी। यह बिगडेटा नहीं है, लेकिन फिर भी उसके सिर और भाले को तोड़ना कुछ है।



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

चलो चलते हैं!

आप केतली बनाते हैं। हालांकि यह हमारे प्रोटोटाइप की तरह फोन से सीधे नियंत्रित होता है, सब कुछ सरल और तार्किक है:

एक स्थानीय नेटवर्क है, ग्राहक हैं, एक उपकरण है। कोई सर्वर नहीं है, कोई खाता नहीं है, कोई प्राधिकरण नहीं है। सौंदर्य। हम केतली खरीदते हैं, इसे घर लाते हैं, और इसे नेटवर्क से जोड़ते हैं। हम कैसे जुड़ेंगे?

पहले उपयोग

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

लेकिन अभी के लिए, मैं वाईफाई प्राधिकरण विकल्प से आगे बढ़ूंगा।

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

सब कुछ सरल और स्पष्ट है। किसी एप्लिकेशन से डिवाइस पर कमांड का ट्रांसमिशन भी काफी सरल लगता है:

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

हम कार्य को जटिल करते हैं। अब हमारे पास रिमोट प्रबंधन के लिए एक सर्वर भी है।

लेकिन इतना सरल नहीं है। हम रिमोट कंट्रोल चाहते हैं, है ना? ऐसा करने के लिए, हमें एक और तत्व - सर्वर को पेश करना होगा। योजना निम्नलिखित रूप लेती है:

यह बहुत मुश्किल नहीं है। लेकिन जब आप सर्वर को परिमाण का क्रम जोड़ते हैं तो तर्क की जटिलता बढ़ जाती है।

यहाँ, उदाहरण के लिए, आवेदन के पक्ष से पहला समावेश कैसे दिखाई देने लगा:

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

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

अनोखे कमरों के बारे में

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

इसके अलावा, आपको अभी भी एक और फोटो अपलोड करते समय लॉक प्रदान करने की आवश्यकता है - कोई फर्क नहीं पड़ता कि आप सूचना को कितनी जल्दी अपडेट नहीं करते हैं, एक स्थिति अभी भी संभव है जहां दो उपयोगकर्ता वास्तव में एक ही समय में एक फोटो अपलोड करेंगे। संक्षेप में, ऐसा करने के लिए, आप आरोही क्रम में फ़ाइलों का नाम नहीं दे सकते।
उदाहरण के लिए, आप एक यादृच्छिक संख्या को पर्याप्त रूप से उत्पन्न कर सकते हैं ताकि यह निकट भविष्य में मेल न खाए। यह डेटा को सक्रिय रूप से बदलने के लिए भी अच्छा है, इसे वर्तमान समय के आधार पर उत्पन्न करें - फिर दो फ़ाइलों के संभावित संयोग के लिए, न केवल दो यादृच्छिक संख्याओं का संयोग होना चाहिए, उन्हें एक ही सेकंड में भी मेल खाना चाहिए! लेकिन इस संयोजन की संभावना बहुत कम है, शायद इसलिए कि बिल्ली के बच्चे अन्य लड़कियों की तस्वीरों में नहीं बदलते :(
संक्षेप में, "सब कुछ पहले से ही हमारे लिए मानकीकृत है!" इस मामले के लिए एक तैयार मानक है, जिसे RFC 4122 में वर्णित किया गया है - यूनिवर्सली यूनिक आइडेंटिफ़ायर, लेकिन सिर्फ़ एक UUID है , यह इस तरह दिखता है: 65C4B640-3452-11E3-AA6E-080020040000A66, और सभी में 34000000000000000000000000000000000 टुकड़े हो सकते हैं, या बस 3.4 Godecillion हो सकते हैं। ।

लेकिन कुछ मैं डोडेकिल स्तन से विचलित हो गया। यहां बताया गया है कि चायदानी के लिए पहला समावेश कैसा दिखता है:

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

सुरक्षा

हम एक दिलचस्प निर्णय पर आए, विरोधाभास के बारे में सोच "डिवाइस जितना संभव हो उतना सरल होना चाहिए - डिवाइस को संरक्षित किया जाना चाहिए।" अधिक सटीक रूप से - खातों का उपयोग करके सुरक्षा प्रणाली को लागू करना अधिक सुविधाजनक है, लेकिन मैं सबसे पहले किसी के सामने थूक दूंगा जो कहेगा कि केतली का उपयोग करने के लिए आपको एक खाता बनाने की आवश्यकता है। नतीजतन, एक खाता बनाया जाता है, लेकिन उपयोगकर्ता इसमें शामिल नहीं है - आप इसे ऊपर की तस्वीरों में देख सकते हैं। आरंभीकरण के दौरान, हम एक यादृच्छिक नाम और पासवर्ड के साथ एक खाता बनाते हैं, और इसे उस एप्लिकेशन में सहेजते हैं जिसे हम प्राधिकरण के लिए एक कुंजी के रूप में उपयोग करते हैं। उपयोगकर्ता को इसके बारे में पता नहीं हो सकता है, इसलिए खाता बनाने की समस्या हल हो गई है।
हां, मैं पहले से ही दर्शकों की आपत्तियां सुनता हूं - उन लोगों के बारे में क्या जो खाते से सहज हैं? एक व्यक्ति के खाते में कई डिवाइस हो सकते हैं, कई फोन, या वह अक्सर अपडेट किया जाता है, जिसके बाद एप्लिकेशन को फिर से इंस्टॉल करना पड़ता है। डी वास्तविक खाते हैं, लेकिन उनका उपयोग करना मुश्किल है - यह याद रखने की कोशिश करें कि आपके पास A811BF51-98B8-4604-9A8C-D72D8E40D846 उपयोगकर्ता नाम और 798E625-912D-4625-BC9E-08E9B3047219 का पासवर्ड है।
बेशक, हम उपयोगकर्ताओं को उस तरह से पीड़ा नहीं देंगे, इसलिए हमें उन्हें खाते का नाम बदलने का अवसर देने की आवश्यकता है। चूंकि उपयोगकर्ता को यह नहीं पता है कि उसका खाता पहले ही बन चुका है, इसलिए उसकी सादगी के भ्रम को नष्ट करने की आवश्यकता नहीं है, और आप आइटम को "खाता बनाएँ" कह सकते हैं। लेकिन इसके तहत छिपाना बिल्कुल नामकरण होगा:

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

टीमों के साथ काम

और अब हम सबसे दिलचस्प हिस्सा शुरू कर रहे हैं - डिवाइस को कमांड भेज रहे हैं। आवेदन इसे इस तरह करता है:

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

तो, एप्लिकेशन सर्वर को एक कमांड भेजता है, और सर्वर ... यहां सर्वर है:

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

और चायदानी, शाश्वत कार्यकर्ता, सर्वर से एक कमांड प्राप्त कर रहा है, लेकिन इसे निष्पादित करने के अलावा कोई विकल्प नहीं है:

बेशक, छोटे बॉक्स "कमांड एक्ज़ेक्यूशन" के तहत ब्लॉक आरेख कोई कम (या इससे भी अधिक) नहीं है, लेकिन यह पूरी तरह से अलग कहानी है ...

हमेशा की तरह:
1) निजी में व्याकरण और विराम चिह्नों की रिपोर्ट करें
2) तर्क, वाक्य, विचारों में त्रुटियों के बारे में - एक टिप्पणी में।
3) व्यवस्था की व्यवस्था - अनुमति दी।
4) उन दोस्तों की सदस्यता लें, जो केतली बनाते हैं कंपनी पेज (सदस्यता बटन) पर
5) आप चित्र को पूर्ण आकार में यहाँ देख सकते हैं ।
6) और आप यहां मैक के लिए ओमनीग्रैफ कार्यक्रम के प्रारूप में इसके स्रोत को उठा सकते हैं । मुझे नहीं पता कि क्यों, लेकिन अचानक कोई इसे एक आधार के रूप में ले जाएगा, मुझे खुशी होगी।