संरचनात्मक इकाइयों में एक सतत डेटा स्ट्रीम को विभाजित करना

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

इस तरह के कार्य उत्पन्न होते हैं, उदाहरण के लिए, टेलीमेट्री ट्रांसमिशन में और रिमोट उपकरण को नियंत्रित करने के लिए। एक तरफ, आमतौर पर एक साधारण माइक्रोकंट्रोलर होता है, दूसरी तरफ एक कंप्यूटर होता है। उनके बीच अच्छे पुराने RS232 पर संचार किया जा सकता है। यद्यपि यह अधिक कठिन हो सकता है, उदाहरण के लिए, UART माइक्रोकंट्रोलर का आउटपुट 802.11b में परिवर्तित हो जाता है, फिर रेडियो सिग्नल रेडियो मास्ट में प्रसारित होता है और ईथरनेट सर्वर पर आता है।

अगर मेरी बाइक इस विषय पर दिलचस्प है, तो बिल्ली का स्वागत करें।

सबसे पहले, हम आवश्यकताओं का निर्धारण करेंगे:

1. एक चैनल किसी भी समय बनाया जा सकता है।
2. कंट्रोलर और कंप्यूटर दोनों को किसी भी समय चैनल से जोड़ा जा सकता है, जिसमें डेटा ट्रांसफर भी शामिल है।
3. यदि चैनल विकृत है, तो संबंधित डेटा ब्लॉक को छोड़ दिया जाना चाहिए।
4. एक चैनल में कई उपकरण हो सकते हैं।
5. डेटा ब्लॉक में बाइट्स का कोई भी क्रम हो सकता है और मनमानी लंबाई हो सकती है।
6. प्रोटोकॉल का समर्थन करने के लिए आवंटित संसाधन गंभीर रूप से सीमित हैं।

यह यूडीपी से मिलता-जुलता एक कार्यान्वयन है।

"तनाव" की तीन संख्याओं के हस्तांतरण के उदाहरण के लिए कई सामान्य तरीकों पर विचार करें एक ब्लॉक के रूप में और दो अन्य संख्या "तापमान" के रूप में।

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

यह इस तरह लग सकता है:

वी 1231, 2400, -231
वी 1333, 2100, -232
टी 36, -40
स्प्रिंटफ का उपयोग किया जाता है (buf, "V% d,% d", ...)।

ट्रांसमिशन मुद्दा: स्प्रिंटफ एक महत्वपूर्ण मात्रा में स्टैक का उपयोग करता है, काफी लंबे समय से।

रिसेप्शन की समस्या: नियंत्रक पर, "-232" वर्ण को इंट में परिवर्तित करने के लिए अतिरिक्त संसाधनों की आवश्यकता होती है। कोई प्रकार का नियंत्रण, 100,500 त्रुटि जाँच स्थितियाँ।

प्लसस के रूप में - एक व्यक्ति नग्न आंखों के साथ संचरित मापदंडों को देख सकता है।

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

दशमलव अंकों को प्रेषित करके समस्या को आंशिक रूप से हल करना संभव है, लेकिन हेक्साडेसिमल अंक - यह प्रसंस्करण को सरल करेगा, लेकिन अन्य समस्याओं को नहीं बचाएगा।

नियंत्रण में सुधार के लिए, आप XML में प्रेषित डेटा को लपेट सकते हैं:

<?xml version="1.0" encoding="UTF-8"?> <voltages> <voltage num=”1”>1231</voltage> <voltage num=”1”> 2400</voltage> <voltage num=”1”> -231</voltage> </voltages> 

या आप इसे JSON में लपेट सकते हैं:

 { “Voltages”: [1231, 2400, -231] } 

प्रोटोकॉल डॉक्यूमेंटेड हो जाएगा। लेकिन एक ही समय में, संकलन चरण पर अभी भी कोई प्रकार का नियंत्रण नहीं है। और अतिरिक्त रूप से प्रसारित डेटा की मात्रा अत्यधिक बड़ी हो जाती है। इसी समय, सीमित संसाधनों पर संख्या और पाठ को पार्स करने की समस्या बनी हुई है।

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

$ GNVLT, 1231,2400, -231 * 71

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

बाइनरी डेटा ट्रांसफर पर विचार करें। बाइट सेट प्रेषित किया जाएगा, इसलिए, संरचनाओं को निर्धारित करना आवश्यक है:

 typedef struct { int16_t supplyIn; int16_t supplyOut; int16_t groundPotential; }PackVoltages; typedef struct { int8_t internal; int8_t outside; }PackTemperature; 

हमारे पास वोल्टेज के लिए 6 बाइट्स और तापमान के लिए 2 बाइट्स हैं।

आप इन संरचनाओं को एक में जोड़ सकते हैं, आगे प्रोटोकॉल विस्तार के लिए एक और 5 बाइट्स जोड़ सकते हैं, संरचना में संचरित डेटा का प्रकार दर्ज करें:

 typedef struct{ char type; union { PackVoltages voltages; PackTemperature temperatures; }Data; char rezerv[5]; }FullPack; 

हमें 16 बाइट्स (स्पष्ट संरेखण के कारण) का एक पैकेट मिलता है, और 12 नहीं जैसा कि लग सकता है (हमारे उदाहरण में, यह कोई समस्या नहीं है, लेकिन संरेखित करते समय आपको सावधान रहने की आवश्यकता है)। आप तंग बाइट पैकिंग के लिए संकलक विकल्प सक्षम कर सकते हैं, लेकिन एक और समस्या उत्पन्न हो सकती है - कुछ प्रोसेसर (एआरएम कोर पर) बिना डेटा दिए नहीं पढ़ सकते हैं और शुरुआत करने वाले जेडी के लिए यह त्रुटि ढूंढना इतना आसान नहीं है।

इसके अलावा 16 बाइट्स हमेशा चैनल में स्थानांतरित किए जाते हैं। प्राप्त पक्ष अगले 16 बाइट्स की प्रतीक्षा करता है और अगले पैकेट को संसाधित करता है। यह देखना आसान है कि कोई सीआरसी नहीं है। CRC जोड़ें:

 typedef struct{ char type; union { PackVoltages voltages; PackTemperature temperatures; }Data; char rezerv[5]; char CRC; }FullPack; 

पैकेट का आकार 16 बाइट्स रहता है। डेटा भेजते समय, हमें पैकेज का प्रकार नीचे रखना होगा, गणना करना होगा और सीआरसी पैकेज में डालना होगा, फिर हम प्राप्त पैकेज भेजते हैं।

इस दृष्टिकोण के फायदे यह है कि जब प्रसंस्करण पैकेज होते हैं, तो संकलन नियंत्रण संकलन समय पर दिखाई देता है। संख्या - पाठ और इसके विपरीत के बीच कोई अनावश्यक रूपांतरण नहीं हैं। डेटा का प्राप्त भाग हमेशा एक ही आकार का होता है - यह अग्रिम में मेमोरी आवंटित करने के लिए सुविधाजनक है।
कई कमियां हैं: प्रेषित डेटा की काफी अलग-अलग लंबाई के साथ छोटे मूल्यों से दसियों बार डेटा ट्रांसमिशन के लिए अनावश्यक ओवरहेड लागत हैं। टीसीपी चैनल पर क्लाइंट-सर्वर इंटरैक्शन के लिए यह सिंक्रनाइज़ेशन विधि अच्छी तरह से अनुकूल है - रास्ते में कुछ भी खो नहीं जाएगा, पैकेट की शुरुआत हमेशा ज्ञात होती है। प्रारंभिक कनेक्शन की तुलना में बाद में चैनल के संबंध में एक स्थिति संभव है, जब पहले कुछ बाइट्स नहीं पहुंचे हैं। फिर सभी प्राप्त पैकेटों को इस संख्या के बाइट्स द्वारा स्थानांतरित किया जाएगा और उनमें डेटा स्वाभाविक रूप से गलत होगा। खैर, अगर सीआरसी उन्हें छोड़ देता है, तो नोड के साथ कोई संबंध नहीं होगा। और 1/256 की संभावना के साथ, "टूटे हुए" पैकेट छूट गए। आप पैकेट के "शुरुआत" के एक हस्ताक्षर बाइट को प्रेषित करके इस समस्या को हल करने का प्रयास कर सकते हैं, लेकिन यह देखते हुए कि हम द्विआधारी डेटा प्रसारित करते हैं, वही बाइट डेटा में भी हो सकता है। इसलिए, पैकेट की शुरुआत को मज़बूती से निर्धारित करना हमेशा संभव नहीं होता है। एक अन्य मुद्दा चर संरेखण है। प्रति पैकेट हेडर के लिए एक बाइट की आवश्यकता होती है, 32-बिट संख्याएं अक्सर डेटा में ही मिल सकती हैं, जिससे समय-समय पर 0-2 बाइट्स के डेटा शिफ्ट हो जाएंगे। कष्टप्रद झुंझलाहट यह है कि विभिन्न प्रकार के पैकेट भेजते समय सीआरसी को "मैन्युअल रूप से" गणना की जानी चाहिए।

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

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

काम करने के लिए विभिन्न रूपांतरणों के लिए, तीन बाइट्स आरक्षित होने चाहिए। उन्हें चुनना सबसे अच्छा है ताकि वे कम सामान्य हों। बाइट प्रतिस्थापन नियम:
<शेयरिंग> = <शेयरिंग> <शेयरिंग>
<फाइनल> = <शेयरिंग> <वैकल्पिक>
<वैकल्पिक> = <वैकल्पिक>

इससे पता चलता है कि डेटा स्ट्रीम में <फाइनल> किसी भी तरह से घोषित नहीं किया जा सकता है।
पैकेज इस तरह से बनाया जा सकता है:
<साझाकरण> प्रोटोकॉल_ डेटा <अंतिम>
यदि आप बढ़ी हुई विश्वसनीयता चाहते हैं, तो आप इस तरह से पैकेज बना सकते हैं:
<अंतिम> <विभाजक> प्रोटोकॉल_ डेटा <विभाजक> <अंतिम>

दूसरे रूप में क्षतिग्रस्त छोटे पैकेटों की अस्वीकृति का प्रतिशत लगभग 15% बढ़ जाता है, जबकि एक ही 10-15% द्वारा ओवरहेड जोड़ते हैं, इसलिए इसे आगे नहीं माना जाएगा।

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

अब आप देख सकते हैं कि "प्रोटोकॉल_डेटा" में क्या शामिल हैं:

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

हमारे मामले के लिए, यह डेटा संरचनाओं की परिभाषा की तरह दिखेगा:

 typedef struct { int16_t supplyIn; int16_t supplyOut; int16_t groundPotential; }PackVoltages; typedef struct { int8_t internal; int8_t outside; }PackTemperature; 

और ज्ञान कि पहली संरचना को प्रतीक 'V' द्वारा निरूपित किया जाएगा, और दूसरा 'T'। इन मापदंडों के हस्तांतरण को 3 मापदंडों के साथ एक फ़ंक्शन के माध्यम से किया जाएगा - यह पैकेट का प्रकार है, प्रेषित डेटा की शुरुआत का पता और प्रेषित डेटा की लंबाई।
BP_SendMyPack ('T', और packTENS, sizeof (पैकटेन्स));

और प्रसारण चैनल में, ऐसा क्रम होगा:



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

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

नुकसान: पैकेट का प्रकार और पैकेट का पता विशेष वर्ण के बराबर नहीं हो सकता है और 1 से 254 तक मान ले सकता है। सीआरसी बाइट केवल एक है और, परिणामस्वरूप, टूटे हुए पैकेट के गुम होने की 1/256 संभावना है।

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

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

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

बाइनरी प्रोटोकॉल के साथ काम करने के लिए स्पष्टीकरण।
मेनविंडो वर्ग में, सभी प्रोटोकॉल और टीसीपी कनेक्शन इंटरैक्शन एकत्र किए जाते हैं (टीसीपी के बजाय, आप कुछ और उपयोग कर सकते हैं)।

निर्माता मेनविंडो :: मेनविंडो निजी फ़ंक्शन initBinProtocol () कहता है; जो प्रोटोकॉल को इनिशियलाइज़ करता है। एक ही स्थान पर, "जारी बाइट्स" GlobalSendCharToExternal () के लिए फ़ंक्शन का पता प्रोटोकॉल को दिया गया है। फिर, TCP सॉकेट में वर्णों के सिग्नल आगमन का एक हैंडलर ReadFromParent () पर स्थापित होता है, जो अंततः वर्ण द्वारा वर्ण प्रोटोकॉल हैंडलर को सभी प्राप्त बाइट्स को स्थानांतरित करता है।

TCP कनेक्ट करने के बाद, एक और ReadFromChild () हैंडलर जुड़े सत्र पर लटका दिया जाता है, जो इसी तरह सभी प्राप्त बाइट्स को प्रोटोकॉल हैंडलर में स्थानांतरित करता है।

PackTypes.h फ़ाइल में सभी प्रकार के संचरित पैकेट हैं। यह वास्तव में एक प्रोटोकॉल विवरण है। कंप्यूटर पर प्रसंस्करण में आसानी के लिए टाइप TPackAllTypes पेश किया गया था; इस प्रकार का उपयोग माइक्रोकंट्रोलर पर करना आवश्यक नहीं है।

पेंटबॉक्स वर्ग में ही प्रोटोकॉल होता है। कार्यक्रम के अन्य उदाहरणों के पैकेज टाइमर द्वारा हर 50ms की जाँच की जाती है। यदि वांछित है, तो आप पूरे पैकेट के अंतिम बाइट को प्राप्त करने के लिए प्रसंस्करण कर सकते हैं।

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

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

Types.h फ़ाइल में विभिन्न प्लेटफार्मों के लिए अलग-अलग संकलक द्वारा क्रॉस-संकलन के लिए समान बुनियादी प्रकार की परिभाषाएं शामिल हैं, आपके मामले में इसे संपादित करना आवश्यक हो सकता है।

सामान्य तौर पर, कोड को प्रलेखित किया जाता है, इसलिए यह पता लगाना मुश्किल नहीं है।

पुस्तकालय के साथ जीथूब के लिंक:

• git: git@github.com: Elvish / microkern.git
• http: https://github.com/Elvish/microkern

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

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

लेखक से: मेरी राय में, समय का विभाजन हलकी भरी हुई लाइनों पर या बहुत सटीक घंटों में संभव है। ऐसी स्थिति में जहां भौतिक डेटा स्थानांतरण की निगरानी करना मुश्किल है (उदाहरण के लिए, वाईफाई के माध्यम से रिले)। संकुल को एक दूसरे के साथ जोड़ा जा सकता है या मनमाने ढंग से विभाजित किया जा सकता है। यहां तक ​​कि कुछ USB-RS232 एडेप्टर यह पाप करते हैं - वे 8-बाइट पैकेट को मिलाते हैं और परिणामस्वरूप, सभी हार्डवेयर एडेप्टर के माध्यम से काम नहीं करते हैं।

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