uMCPIno: Arduino के लिए गारंटीकृत वितरण के साथ एक सरल प्रोटोकॉल लिखना

प्रणाम, प्रिय!

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



मैं उन सभी से पूछता हूं जो बोर्ड में रुचि रखते हैं, हम टोपियां बंद करते हैं, किंगस्टोन खोलते हैं, गिट्टी टैंक भरते हैं। हमारे पास अतीत, गंतव्य: वर्ष 1974 में एक भ्रमण है!


अच्छी पुरानी परंपरा के अनुसार, इस क्षेत्र में कम से कम दो मान्यता प्राप्त विशेषज्ञ क्रिप्टोग्राफिक एल्गोरिदम और प्रोटोकॉल का वर्णन करने में शामिल हैं, अगर कोई और उन्हें नहीं जानता है, तो परिचित हो जाएं:

और

पहले हम एक सरल कार्य का वर्णन करते हैं

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

कैसे और क्यों एक कनेक्शन स्थापित करने के लिए?

हम इस तरह की निराशाजनक स्थिति में विश्वसनीय डेटा ट्रांसफर की व्यवस्था कैसे कर सकते हैं, जब ऐसा लगेगा कि सब कुछ असफलता के लिए है?

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

ठीक है, चलो कहते हैं कि अगर ऐलिस संदेश भेजना चाहता है, तो उसे "शुरुआती संचरण!" चिल्लाने की ज़रूरत है और बॉब "आरंभ रिसेप्शन!" तक प्रतीक्षा करें।
यदि ऐलिस बॉब की प्रतिक्रिया की प्रतीक्षा नहीं करता है, तो वह केवल स्थानांतरण शुरू करने के लिए अपने अनुरोध को दोहराता है। स्वाभाविक रूप से, आपको ऐसा अक्सर नहीं करना चाहिए, अन्यथा, जैसा कि हम जानते हैं, आप बॉब का जवाब नहीं सुन रहे हैं।

ठीक। लेकिन अगर प्रतिक्रिया में ऐलिस अगली खाई से सुनता है तो क्या होता है, "शुरुआती ट्रांसमिशन!"।
यह पता चला है कि बॉब ने भी कुछ महत्वपूर्ण जानकारी अभी स्थानांतरित करने का फैसला किया है। ऐलिस का एक हल्का चरित्र है, और उसने सोचा हो सकता है: "ठीक है, मैं इंतजार करूंगा, मेरा संदेश सिद्धांत रूप में है, तत्काल नहीं, बॉब को पहले इसे पारित करने दें।" यह सोचकर, वह जवाब देती है, "रिसेप्शन शुरू करो!"।

चूंकि युद्धकाल में साइन का मूल्य चार तक पहुंच सकता है, ध्वनि की गति परिमित होती है, और एलिस और बॉब ने जो कुछ सुना है उसे समझने में कुछ समय लगता है, और यहां तक ​​कि बॉब, एक सज्जन के रूप में, महिला को देने का फैसला कर सकते हैं, वह सिकुड़ती है और चिल्लाती है "मैं प्राप्त करना शुरू कर रहा हूं!" ...

नाराजगी को स्पष्ट करने के लिए, हम समय चार्ट का उपयोग करेंगे। समय उनके नीचे चला जाता है।

मामला जब ऐलिस और बॉब समय पर सहमत नहीं हुए:


संदेश खो जाने पर मामला:


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

अब एलिस और बॉब दोनों एक स्वागत की उम्मीद कर रहे हैं। यह महसूस करना तर्कसंगत होगा कि एक संघर्ष हुआ है, और किसी को ट्रांसमिशन फिर से शुरू करने की आवश्यकता है। लेकिन क्या होगा अगर सब कुछ फिर से एक नए तरीके से होता है? और यहां हम फिर से वहीं हैं जहां हमने शुरुआत की थी।

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

इस बीच, खाइयों में, स्थिति गर्म हो रही है, कमांडर रिपोर्टों के प्रसारण की मांग करते हैं।
प्राथमिक स्रोतों की ओर मुड़ने का समय है: मार्क्स का अध्ययन करने के लिए, एंगेल्स 40 साल से अधिक समय पहले लौट आएंगे और देखेंगे कि कैसे DDCMP प्रोटोकॉल को डिज़ाइन करते समय DEC इंजीनियरों द्वारा ऐसी समस्याओं को हल किया गया था।

डीडीसीएमपी के डेवलपर्स के अनुसार, ऐलिस और बॉब को भावनाओं को अस्वीकार करने और परिमित राज्य मशीनों की तरह बनने की आवश्यकता है।
इसका मतलब यह है कि अब से, हमारे ऐलिस और बॉब के पास कुछ ही निश्चित राज्य होंगे, इन राज्यों के बीच संक्रमण कुछ नियमों के अनुसार कड़ाई से हो सकता है जब कुछ घटनाएं घटती हैं।

सबसे पहले, हम बस राज्यों को सूचीबद्ध करते हैं:

• रुका
• विशिष्ट हुक
• ACKNOWLEDGED START
• चल रहा है

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

आइए राज्यों पर अलग से, विस्तार से विचार करें

HALTED सबसे सरल अवस्था है, कोई भी कहीं भी नहीं जाता है, हर कोई अपने स्थानों पर रहता है, कुछ भी प्रेषित नहीं होता है और प्राप्त नहीं होता है, किसी भी बाहरी उत्तेजना को नजरअंदाज नहीं किया जाता है। सभी लेकिन एक - उच्च अधिकारियों की इच्छा। मूल DDCMP प्रोटोकॉल में, HALTED राज्य से संक्रमण केवल उपयोगकर्ता के अनुरोध पर INITIAL START स्थिति में हो सकता है - ऐलिस या बॉब को कनेक्शन स्थापित करने का आदेश प्राप्त होता है।

जब एलिस या बॉब को ऐसा आदेश मिलता है तो क्या होता है?
वे तुरंत खुद को नोट करते हैं कि राज्य HALTED से INITIAL START में बदल गया है, इस संक्रमण में, किसी भी अन्य की तरह, कड़ाई से परिभाषित अनुक्रम कार्रवाई शामिल है। इस स्थिति में, आपको "DO IT!" चिल्लाने की आवश्यकता है और घड़ी पर घड़ी सेट करें। वह सब है।

इसलिए, ऐलिस चिल्लाया कि उसकी क्या आवश्यकता थी, और स्टॉपवॉच पर एक बटन दबाया। अब, बॉब से क्या उम्मीद की जाए, यह समझने के लिए, हम यह जानेंगे कि जब वह INITIAL START में है तो वह ऐलिस के साथ क्या हो सकता है।

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

- यदि ऐलिस सुना है कि बॉब एक ​​ही बात चिल्लाया - "एक ही समय!", तो ऐलिस गैर-चुनिंदा ACKNOWLEDGED स्टार्ट स्थिति में चला जाता है, जिसके बारे में उसे तुरंत "DO TWO!" चिल्लाना चाहिए और घड़ी को फिर से।

- फिर से, अगर ऐलिस ने बॉब "डीओ टू!" से सुना, तो वह तुरंत रनिंग स्थिति (!) में जाती है, चिल्लाती है "नूवल!" यदि उसकी स्टॉपवॉच शुरू की गई है, तो वह सावधानी से सबसे आगे निकल जाती है।

यह बहुत महत्वपूर्ण है कि किसी भी तरह की अनावश्यक हरकत न की जाए जो वर्तमान स्थिति के लिए प्रदान नहीं की जाती है। जो भी बॉब रोता है, चाहे वह कितना भी कोसता या भीख मांगता हो, ऐलिस सहमत होते ही प्रतिक्रिया देता है।

ऐसी चीजें आसानी से एक तालिका में प्रस्तुत की जाती हैं। तो, चलिए पहले से वर्णित HALTED और INITIAL START राज्यों के साथ शुरू करते हैं, और फिर हम तालिका को फिर से भर देंगे।



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

लेकिन राज्यों और संक्रमण के विवरण पर वापस। अगला राज्य ACKNOWLEDGED START है ।
इस अवस्था में होने के कारण, ऐलिस या बॉब को चिंता हो सकती है:

- पहले की तरह, प्रतीक्षा समय की समाप्ति, इस मामले में आपको उसी स्थिति में रहने की आवश्यकता है, "डू टू डू!" चिल्लाएं और टाइमर को फिर से शुरू करें।

- सुना "डू डू!" चिल्लाते हुए राज्य में अनुवाद करता है, "चिल्लाओ रूओओल!" चिल्लाते हुए और टाइमर बंद करो;

- सुना है "यह करो!" उसी स्थिति में छोड़ देता है, आपको "डू डू!" चिल्लाने और टाइमर शुरू करने की आवश्यकता है।

- सुना "पागल स्वीकार!" - रनिंग राज्य के लिए संक्रमण, टाइमर बंद करो।

हमने उपरोक्त सभी को एक तालिका में रखा।


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

हैंडशेक प्रक्रिया के दृष्टिकोण से (हम अभी तक डेटा ट्रांसफर के लिए सौदा नहीं करते हैं, जिसके लिए सब कुछ शुरू किया गया था - यह एक अलग कहानी है) रनिंग राज्य में हम दो घटनाओं में रुचि रखते हैं:

- अगर वे हमारे लिए चिल्लाते हैं, "यह मत करो!" - सब कुछ बहुत बुरा है, यह एक पूर्ण वांछनीय है, सब कुछ नए सिरे से शुरू किया जाना चाहिए। मूल प्रोटोकॉल आपको केवल HALTED स्थिति दर्ज करने का निर्देश देता है । लेकिन यह हमें किसी भी तरह से मदद नहीं करेगा - अगर किसी कारण से यह एक स्वायत्त Arduino पर हुआ, जो कुछ सेंसर से कुछ डेटा प्रसारित करता है, तो हमारे लिए यह पूरी तरह से विफलता है। जैसा कि हम जानते हैं, HALTED से आप केवल अधिकारियों के आदेश से INITIAL START पर जा सकते हैं।
इसलिए, हम यहां प्रोटोकॉल को संशोधित कर रहे हैं: "DO ONCE!" कमांड के HALTED राज्य में रिसेप्शन, अधिकारियों से एक आदेश की तरह काम करना चाहिए - अर्थात INITIAL START स्थिति पर जाएं, "DO IT ONCE!" चिल्लाएं, टाइमर शुरू करें। इसके अलावा, कुछ मामलों में खुद को बिजली की आपूर्ति करने के तुरंत बाद संचार स्थापित करने का आदेश देना सुविधाजनक है।
इस प्रकार, अब, सबसे असुविधाजनक मामले में, हमारे पास बस कनेक्शन रीसेट होगा।

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



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

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

अब डेटा ट्रांसफर कैसे करें?

ठीक है, यह एक अच्छी कसरत थी। दो नेटवर्क नोड्स के संबंध में कैंडी-गुलदस्ता अवधि। याद रखें कि हमने एक व्यवसाय शुरू किया है: हमें गारंटीकृत वितरण और प्राथमिकता के साथ डेटा स्थानांतरित करने की आवश्यकता है! आपदा वसूली के साथ। इस हद तक कि हार्डवेयर संसाधन इसकी अनुमति देते हैं (आखिरकार, ऐलिस और बॉब दोनों ही 2 किलोबाइट रैम के साथ 8-बिट कंट्रोलर के रूप में कमजोर साबित हो सकते हैं!)।

डीईसी इंजीनियर हमें सिखाते हैं कि हमें जिन संदेशों को नंबर देना है, हमें यह गिनने की जरूरत है कि हमने कितना भेजा, हमें कितने मिले और कितने संदेश भेजे जो हम पते पर पहुंचे।

लेकिन वापस हमारी खाइयों में

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

हमारे ऐलिस और बॉब के भौतिक मापदंडों ने हमें अलग-अलग स्थितियों को निर्देशित किया। 8-बिट Arduino में, डेटा की यह मात्रा बस स्टोर करने के लिए कहीं नहीं है और हमें समझौता करना होगा। और मैं इस तथ्य के बारे में बात नहीं कर रहा हूं कि मानक में बाइट्स में पैकेट (संदेश) की लंबाई 16-बिट संख्या तक सीमित है, अर्थात। 64 किलोबाइट्स एक दुर्गम लक्जरी है!

तो, कनेक्शन स्थापित किया गया है। आगे क्या है?

जिस क्षण ऐलिस या बॉब रनिंग अवस्था में प्रवेश करते हैं , काउंटर रीसेट हो जाते हैं।
जैसा कि मैंने पहले ही उल्लेख किया है, मूल प्रोटोकॉल में नंबरिंग संदेश modulo 256 शामिल हैं, लेकिन हमें Arduino जैसी चीजों में स्मृति की छोटी मात्रा के अनुरूप इस संख्या को कम करना होगा।
काउंटरों की सभी वेतन वृद्धि को तुरंत सीमित करने में सक्षम होने के लिए, हम एक निश्चित निरंतर UMCP_PACKETS_NUMBER पेश करेंगे, और अब इस मॉड्यूल में सभी वेतन वृद्धि होगी।

यदि आप UMCP_PACKETS_NUMBER = 8 लेते हैं, और अधिकतम पैकेट का आकार UMCP_PACKET_DATA_SIZE है - एक समय में प्रेषित डेटा के अंश 64 बाइट्स तक सीमित हैं, तो सब कुछ Arduino UNO में फिट हो जाएगा और उपयोगकर्ता की आवश्यकताओं के लिए थोड़ा सा रहेगा।
यह याद रखना महत्वपूर्ण है कि इन दोनों मापदंडों को दोनों पक्षों के लिए समान होना चाहिए।

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

देखें कि तथाकथित आयोजन करना अब कितना आसान है पाइपलाइन करना और त्रुटि स्थितियों को संभालना कितना आसान है!

यदि कनेक्शन स्थापित होने के ठीक बाद ऐलिस एक पंक्ति में 3 पैकेट भेजता है, तो उन सभी में काउंटर आर सेट 0 होगा (उसे अभी तक कोई पैकेट नहीं मिला है), और काउंटर एन प्रत्येक नए पैकेट के साथ एक से बढ़ेगा।

यदि बॉब सफलतापूर्वक उन सभी को स्वीकार करता है, तो सभी तीन पैकेटों की प्राप्ति की पुष्टि करने के लिए, यह उसके लिए केवल अंतिम एक के लिए एक पुष्टि भेजने के लिए पर्याप्त होगा, वास्तव में, यदि वह बस अपने काउंटरों आर = 3 और एन = 0 की स्थिति को वापस भेजता है, तो ऐलिस तुरंत समझ जाएगा कि सभी को भेजा उसके संदेश पतेदार तक पहुँच गए।

यह एक आदर्श मामला था जब कोई जोर-जबरदस्ती नहीं हुई। आइए अब देखें कि क्या गलत हो सकता है और इससे कैसे निपटना है।

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

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

, A R , «» .

, , ().
RNA SACK SPEP. , (Send ACKnowledgement), — (Send REPly to a message).

, DDCMP — SNAK (Send Negative AcKnowledgement). - . , , , — .
, .

- . - . और यह सच है। .
.

, — , . , , L, (, — R).


, . , .
DDCMP, , SELECT — ( ) «» .
, , .
: SELECT. : , , — .

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

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

अब हमारे पास कनेक्शन स्थापित करने और उस पर डेटा प्रसारित करने के लिए नियमों का एक पूरा सेट है।

हमने नियमों के इस सेट के ठोस कार्यान्वयन पर केवल स्पर्श नहीं किया।
खैर, इसे ठीक करें!

पैकेज निर्माण और प्रारूप

Message Framing — .
, .

1. , R N . Arduino 8 . , , 4-.

:

 = (RL & 0x0F) | (NL << 4); 

और हम इस तरह से काउंटरों की स्थिति पढ़ेंगे:

 NR = (c >> 4) & 0x0F; RR = c & 0x0F; 

सी - संदेश से संबंधित बाइट

2. हमें यह भी याद है कि प्रत्येक संदेश में SELECT ध्वज की स्थिति होनी चाहिए। और विभिन्न प्रकार के संदेश स्वयं होंगे:


यानी सिर्फ 6 अलग-अलग तरह के मैसेज। डीटीए को छोड़कर सभी संदेश "सिलेक्ट फ्लैग" को जारी करते हैं - उन्हें रिमोट सब्सक्राइबर से तत्काल प्रतिक्रिया की आवश्यकता होती है, और ध्वज के बिना वह इसे प्रसारित करने में सक्षम नहीं होगा। पाइप लाइनिंग को संभव बनाने के लिए DTA संदेश ध्वज नहीं लौटाता है।

सामान्य तौर पर, हमारे पास संदेश के प्रकार के लिए पर्याप्त 3 बिट्स हैं, लेकिन बिट्स के साथ गड़बड़ न करने के लिए, हम टाइप करने के लिए एक पूरी बाइट असाइन करते हैं - संशोधन के मामले में, हमारे पास कार्रवाई की कुछ स्वतंत्रता होगी।

यदि संदेश में डेटा है, तो हमें उनकी मात्रा और चेकसम को स्थानांतरित करने की आवश्यकता है। चूंकि अधिकतम पैकेट का आकार 64 बाइट्स है, इसलिए हम चेकसम और लंबाई के लिए एक बाइट भी लेंगे - अचानक आपको पैकेट का आकार बढ़ाना होगा।

3. हमें संदेश की शुरुआत के कुछ हस्ताक्षर और हेडर के लिए एक अलग चेकसम की भी आवश्यकता है।

यह सब ध्यान में रखते हुए, शीर्ष लेख (उर्फ नियंत्रण संदेश) इस तरह दिखता है:


और डेटा ब्लॉक इस तरह है:


बस इतना ही। यह उस प्रोटोकॉल का पूरा विवरण है जो हमें DDCMP से मिला है।
अब आप कार्यान्वयन के माध्यम से जा सकते हैं।

इसे कैसे व्यवस्थित किया जाता है और इसका उपयोग कैसे किया जाता है?

सबसे पहले, रिपॉजिटरी की संरचना के बारे में थोड़ा।
जैसा कि मैंने शुरुआत में उल्लेख किया था, प्रोजेक्ट कोड github पर है: uMCPIno

यह देखने के लिए कि सब कुछ कैसे काम करता है, आप एक पीसी पर एक परीक्षण एप्लिकेशन चला सकते हैं।

संग्रह में, uMCPIno_Test.exe चलाएं, वांछित COM पोर्ट चुनें और कोशिश करें कि यह कैसे काम करता है।
आप वर्चुअल COM पोर्ट की एक जोड़ी पर जांच कर सकते हैं (मैं आमतौर पर ऐसा करता हूं)।
आप आवेदन की दो प्रतियां क्यों चला सकते हैं। बस एक कॉपी में "डिलेक्टेड बाय डिफॉल्ट" को ऑन करना न भूलें - यह मास्टर होगा, और दूसरे में - इसे बंद कर दें। वैसे, यदि आप रुचि रखते हैं, तो आप देख सकते हैं कि क्या होता है यदि आप इस नियम का पालन नहीं करते हैं =)

EXTRAS विकल्प आपको प्रोटोकॉल के मस्तिष्क के अंदर विचारों के सभी आंदोलनों को देखने की अनुमति देता है। चयनित झंडे की स्थिति में सभी परिवर्तन, टाइमर से घटनाओं, नोड की स्थिति में परिवर्तन, साथ ही संचरित और प्राप्त संदेशों में चर आर और एन के मूल्यों को प्रदर्शित किया जाएगा।

मैं अपने Arduino UNO को UART <-> USB कनवर्टर के माध्यम से अपने लैपटॉप से ​​जोड़ता हूं। पिन कनेक्टर आपको किसी भी समय एक लाइन ब्रेक अनुकरण करने की अनुमति देते हैं:


यदि आप अब लैपटॉप पर एप्लिकेशन चलाते हैं, तो "कनेक्ट" बटन दबाने के बाद, arduina एक कनेक्शन स्थापित करेगा:


और यह इस तरह है कि सिस्टम "फटे" लाइन के माध्यम से भेजने के प्रयास पर प्रतिक्रिया करता है:


PC के लिए अपने आवेदन में uMCPIno एम्बेड करने के लिए:

1. रिपॉजिटरी में एक uMCPIno लाइब्रेरी है। इसे अपने प्रोजेक्ट के संदर्भों से कनेक्ट करें
2. इसमें uMCPInoPort वर्ग शामिल है। हम इसका उदाहरण घोषित करते हैं:
   

    uMCPInoPort port; port = new uMCPInoPort("COM1", UCNLDrivers.BaudRate.baudRate9600, true, 8100, 2000, 64, 8); 

   
   क्रम में पैरामीटर: पोर्ट नाम, फिर पोर्ट स्पीड, डिफॉल्ट सेलेक्ट स्टेट, सेलेक्ट के लिए इंटरवल, टाइमआउट इंटरवल, पैकेट साइज, और अनजाने मैसेज की अधिकतम संख्या।
   
3. घटनाओं की सदस्यता लें:
   जब चयन - port.elect ध्वज परिवर्तन:
   

    OnSelectChangedEventHandler 

   
   जब राज्य बदलता है - port.State:
   

    OnStateChangedEventHandler 

   
   दूरस्थ होस्ट कोड की प्राप्ति की पुष्टि करता है:
   

    OnDataBlockAcknowledgedEventHandler 

   
   डेटा पैकेट कब आता है:
   

    OnDataBlockReceivedEventHandler 

   
   
4. काम करने से पहले, पोर्ट खोलें
   

    port.Open(); 

   
   
5. डेटा भेजने के लिए, हम विधि कहते हैं:

    port.Send(byte[] data); 

   
   
6. पूरा होने पर, पोर्ट को बंद करें:

    port.Close(); 

   
   

बस दो बाइट भेजो!

अब चलो Arduino के कार्यान्वयन के लिए आगे बढ़ते हैं। दो उदाहरण github.com/AlekUnderwater/uMCPIno/tree/master/Anuu फ़ोल्डर में हैं

पहले से और uMCP से सिर्फ एक कनवर्टर है। पहला सीरियल होस्ट के साथ संवाद करने के लिए कार्य करता है, और सीरियल 2 (यदि यह आपके बोर्ड पर है) या पिन 2 और 3 पर SoftwareSerial - एक और uMCPIno नोड के साथ संवाद करने के लिए। आप यहां ब्लूटूथ या एक रेडियो मॉड्यूल कनेक्ट कर सकते हैं।

दूसरा uMCPIno प्रोटोकॉल के समर्थन के साथ एक प्रोजेक्ट टेम्पलेट है

दोनों प्रोजेक्ट में सेटिंग्स हैं जहां आप चढ़ सकते हैं और चढ़ना चाहिए। यहाँ वे हैं:

डिफ़ॉल्ट ध्वज की डिफ़ॉल्ट स्थिति। यदि (सत्य) पर सेट किया जाता है, तो भले ही दूरस्थ नोड ध्वज को वापस नहीं करता है, यह टाइमर द्वारा सही पर सेट किया जाएगा।

 #define CFG_SELECT_DEFAULT_STATE (false) 

इस टाइमर की अवधि निर्धारित करने के लिए, निम्नलिखित सेटिंग है: मिलीसेकंड में SELECT फ्लैग को वापस करने के लिए अंतराल

 #define CFG_SELECT_DEFAULT_INTERVAL_MS (4000) 

मिलीसेकंड में प्रतिक्रिया की प्रतीक्षा करने के लिए अंतराल, सेलेक्ट फ्लैग को वापस करने के लिए अंतराल से थोड़ा कम छोड़ना बेहतर है।

 #define CFG_TIMEOUT_INTERVAL_MS (3000) 

लाइन की वास्तविक बॉड दर। स्थानांतरण कब समाप्त होगा यह निर्धारित करने के लिए इस पैरामीटर की आवश्यकता है।

 #define CFG_LINE_BAUDRATE_BPS (9600) 

नागल एल्गोरिथ्म के लिए डेटा संचय अंतराल। Insolently इसे 100 मिलीसेकंड के बराबर लें। इस समय के दौरान, हम पैकेज के एक सेट की प्रतीक्षा कर रहे हैं, यदि यह टाइप नहीं किया गया है, तो हम इसे उसी रूप में भेजते हैं। नागल एल्गोरिदम का कार्य आकार में एक से कई बाइट्स तक छोटे पैकेट के ढेर के नेटवर्क से छुटकारा पाना है।

 #define CFG_NAGLE_DELAY_MS (100) 

ये सेटिंग्स कंट्रोल सिस्टम (होस्ट) और लाइन के साथ संचार के लिए पोर्ट स्पीड सेट करती हैं। एक भौतिक हस्तांतरण दर के साथ एक लाइन के साथ पोर्ट गति को भ्रमित न करें।

 #define CFG_HOST_CONNECTION_BAUDRATE_BPS (9600) // Host connection port speed #define CFG_LINE_CONNECTION_BAUDRATE_BPS (9600) // Line connection port speed 

यदि यह सेटिंग सक्षम है, तो जब नियंत्रक को बिजली की आपूर्ति की जाती है, तो प्रोटोकॉल खुद ही एक कनेक्शन स्थापित करने के लिए शुरू करेगा।

 #define CFG_IS_AUTOSTART_ON_POWERON (true) 

यह आने वाले डेटा पैकेट के लिए बफर के बाइट्स में आकार है।

 #define CFG_IL_RING_SIZE (255) 

अगला, आइए देखें कि मुख्य स्केच लूप कैसा दिखता है:

 void loop() { uMCP_ITimers_Process(); DC_Input_Process(); DC_Output_Process(); //  ip_ready  ,      if (ip_ready) { uMCP_OnIncomingPacket(); } //        ,     -  if ((state == uMCP_STATE_HALTED) && ((ih_Cnt > 0) || (isStartup && CFG_IS_AUTOSTART_ON_POWERON))) { if (isStartup) { isStartup = false; } uMCP_STATE_Set(uMCP_STATE_ISTART); uMCP_CtrlSend(uMCP_PTYPE_STR, 0, 0, true); } else if (state == uMCP_STATE_RUNNING) { uMCP_Protocol_Perform(); //      -   if (il_ready) { il_ready = false; USER_uMCPIno_DataPacketReceived(); } } } 

अब देखते हैं कि प्रोटोकॉल कैसे काम करता है। मुख्य तर्क uMCP_Protocol_Perform () फ़ंक्शन में निहित है; यहाँ उसका कोड है:

 void uMCP_Protocol_Perform() { if (state == uMCP_STATE_RUNNING) { //              SELECT  if ((!iTimer_State[uMCP_Timer_TX]) && (!iTimer_State[uMCP_Timer_TMO]) && (select)) { //     if (ih_Cnt == 0) { //    REP -  if (srep) { uMCP_CtrlSend(uMCP_PTYPE_REP, N, R, true); srep = false; } //     -   else if (sentBlocksCnt > 0) { uMCP_DataBlockResend((A + 1) % UMCP_PACKETS_NUMBER, true, true); } //    SACK  -        //  -       ACK else if ((!selectDefaultState) || (sack)) { uMCP_CtrlSend(uMCP_PTYPE_ACK, N, R, false); sack = false; } } //     -  else if (ih_Cnt > 0) { //              -  if ((ih_Cnt >= UMCP_PACKET_DATA_SIZE) || (millis() >= ih_TS + CFG_NAGLE_DELAY_MS)) { //   N N = (N + 1) % UMCP_PACKETS_NUMBER; uMCP_NextDataBlockSend(); } } } } } 

एक पैकेट पार्सर जो एक फ़ंक्शन में रहता है

 On_NewByte_From_Line 

एक परिमित राज्य मशीन के सिद्धांत द्वारा भी व्यवस्थित और "बाइट-बाय-बाइट" काम करता है। ऐसा मेमोरी को बचाने के लिए किया जाता है।

बाकी कार्यान्वयन विशेष रुचि का नहीं है। हम बेहतर विश्लेषण करेंगे कि उपयोगकर्ता प्रोटोकॉल के साथ कैसे संपर्क करता है। इस उदाहरण में, "संपर्क के चार बिंदु" हैं।

पहला uMCPIno लाइन पर डेटा भेजने का कार्य है:

 bool uMCPIno_SendData(byte* dataToSend, byte dataSize); 

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

 bool uMCP_IsCanSend(byte dataSize); 

आने वाले डेटा पैकेट का विश्लेषण करने के लिए, आपको फ़ंक्शन कोड में अपना कोड जोड़ना होगा

 void USER_uMCPIno_DataPacketReceived(); 

इनकमिंग डेटा il_ring रिंग बफर को लिखा जाता है। इसे पढ़ने से इस तरह बाइट का आयोजन किया जा सकता है:

 while (il_Cnt > 0) { c = il_ring[il_rPos]; il_rPos = (il_rPos + 1) % CFG_IL_RING_SIZE; il_Cnt--; //   "c" -      } 

परिष्कृत सुख के लिए एक कार्य है

  void USER_uMCP_OnTxBufferEmptry(); 

जिसे सभी डेटा सफलतापूर्वक भेजे जाने पर कहा जाता है। इसमें किसी प्रकार का कोड डालना भी संभव और आवश्यक है।

यह सब क्यों और कहाँ है?

मैं मुख्य रूप से सिर्फ मनोरंजन के लिए निपटाता हूं। इसके अलावा, मुझे हमारे uWAVE सोनार मोडेम के माध्यम से डेटा भेजने के लिए कुछ सरल और सबसे महत्वपूर्ण, "हल्के" प्रोटोकॉल की आवश्यकता थी। चूंकि वे केवल 80 बीपीएस की गति से पानी के माध्यम से डेटा संचारित करते हैं, और उनकी अधिकतम संचार सीमा 1000 मीटर और लगभग 1500 मीटर / घंटा पानी में ध्वनि की गति के साथ, संचरण ध्यान देने योग्य देरी के साथ जुड़ा हुआ है, और केवल एक सोनार चैनल है (यदि सबसे अधिक नहीं है !) नीरव, सबसे धीमा और सबसे अस्थिर।
इसके कारण, मुझे नकारात्मक स्वीकार्यता (एनएके) के तंत्र को छोड़ना पड़ा - अगर यह संभव नहीं है - पानी में नहीं तो बेहतर है कि 100% संचारित न हो।
वास्तविकता में, प्रोटोकॉल तब काम में आया जब DORJI मॉड्यूल और NS-012 का उपयोग करके एक रेडियो चैनल पर डेटा ट्रांसमिट किया गया, जिसे Arduinoes के लिए जाना जाता है।

आगे क्या है?

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

पुनश्च

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

पी पी एस

मेरी अशिक्षा पर शर्म करने के लिए बहुत-बहुत धन्यवाद, त्रुटियों को इंगित करना (व्याकरणिक और तार्किक):

• Berez
• edo1h

परियोजना मूल रूप से खुला स्रोत थी, लेकिन अब लेख भी खुला स्रोत है।