एसएमपीपी प्रोटोकॉल मुद्दे

दुनिया में कुछ भी सही मिलना मुश्किल है। एसएमपीपी प्रोटोकॉल भी कुछ खामियों के बिना नहीं है। मैं इस प्रोटोकॉल के साथ अपनी समस्याओं का वर्णन करूंगा। मुझे उम्मीद है कि इससे किसी को सही निर्णय लेने में मदद मिलेगी।

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

एसएमपीपी का यह दोष शायद एकमात्र अयोग्य प्रोटोकॉल उपकरण है जिसे मैं याद कर सकता हूं। समस्या, निश्चित रूप से, गैर-मानकीकृत विधियों द्वारा हल की गई है।

शेष नुकसान कार्यान्वयन की समस्याओं से संबंधित हैं। उनका समाधान, एक नियम के रूप में, एसएमएससी और एसएमपीपी ग्राहक के बीच एक समझौते पर पहुंचना है और विनिर्देश से परे नहीं जाना है।

दूसरी खामी, जो मुझे बहुत परेशान करती है, डिलीवरी रिपोर्ट से संबंधित है। प्रोटोकॉल संस्करण 3.4 कड़ाई से परिभाषित नहीं करता है कि स्थिति की जानकारी कैसे प्रसारित की जानी चाहिए। एक ओर, एक वैकल्पिक टीएलवी संरचना है जिसमें मैसेज_स्टेट और संबंधित मापदंडों को दृढ़ता से टाइप किए गए रूप में पास किया जाता है। यह विकल्प अच्छा है, सिवाय इसके कि एसएमएससी इस संरचना में कोई लंबी टिप्पणी नहीं भेज सकेगा। लेकिन, फिर से, कहीं भी इस पद्धति को अनिवार्य (MUST) के रूप में इंगित किया गया है। लेकिन प्रोटोकॉल के परिशिष्ट में एक उदाहरण दिया गया है। मैं जोर देता हूं: उदाहरण। सिफारिश भी नहीं। SMSC कैसे (ओह माय गॉड, जिसने इसका आविष्कार किया है !!!) short_message फ़ील्ड के माध्यम से स्टेटस की जानकारी दर्ज कर सकता है। यानी पाठ के रूप में, अजीब संक्षिप्तीकरण, जंगली प्रारूप, आदि।
सामान्य तौर पर, यह संभावित विकल्पों (एमवाय) में से एक को चुनने की स्थिति है। प्रोटोकॉल के कार्यान्वयन के बारे में मेरी राय में, प्रोटोकॉल द्वारा अनुमत विकल्पों में से एक का विकल्प पैकेट बनाने वाली पार्टी का विशेषाधिकार है। इस मामले में, रिपोर्ट पैकेज एसएमएससी है। और प्राप्त करने वाला पक्ष प्रोटोकॉल से मेल खाने वाले किसी भी पैकेट को सही ढंग से संसाधित करने के लिए बाध्य है। लेकिन कठोर वास्तविकता कहती है कि जो भुगतान करता है वह सही है। SMPP क्लाइंट का अधिकांश हिस्सा केवल short_message फ़ील्ड को समझता है।
भगवान का शुक्र है कि इस विनिर्देशन को प्रोटोकॉल (एप्लिकेशन) के पांचवें संस्करण के विनिर्देश से हटा दिया गया था, लेकिन पांचवें संस्करण के एसएमपीपी ग्राहक खोजें।

तीसरा दोष है लंबे संदेशों का प्रसारण। विनिर्देशन विनीत रूप से मानक [GSM 03.40] लघु ​​संदेश सेवा प्वाइंट टू प्वाइंट के तकनीकी बोध को संदर्भित करता है। " इतना विनीत कि आप लिंक को तभी नोटिस करते हैं जब आप विशेष रूप से देख रहे हों। इस मानक का एक संदर्भ संस्करण 3.4 के विनिर्देश के खंड 1.4 संदर्भ में दिया गया है।
प्रश्न: क्या short_message फ़ील्ड का उपयोग प्रोटोकॉल द्वारा केवल GSM 03.40 के अनुसार किया जाना चाहिए? GSM 03.40 UDH हेडर से लैस कॉन्टेक्टेड एसएमएस की एक श्रृंखला में विभाजित एक लंबा संदेश पाठ प्रदान करता है। एसएमपीपी विनिर्देश स्पष्ट रूप से नि: शुल्क उपयोग को प्रोत्साहित करता है - 254 ऑक्टेट का एक क्षेत्र लंबाई। ये लैटिन में दो sms हैं या सिरिलिक में लगभग चार sms हैं।
हम SMPP विनिर्देशन को ध्यान से पढ़ते हैं:

4.4.1 "SUBMIT_SM" सिंटैक्स
"लघु संदेश उपयोगकर्ता डेटा के 254 ओकटेट्स तक। "शॉर्ट_मेज़ साइज़ के लिए सटीक शारीरिक सीमा अंतर्निहित नेटवर्क के अनुसार भिन्न हो सकती है ..."

यानी प्रतिबंध अंतर्निहित नेटवर्क द्वारा लगाए जाते हैं। हमारे मामले में, अंतर्निहित नेटवर्क जीएसएम 03.40 द्वारा वर्णित है। इसलिए 140 बाइट्स डेटा। इतना लंबा मैदान क्यों? तथ्य यह है कि 7-बिट एन्कोडिंग का उपयोग किया जा सकता है, फिर वर्ण पहले से ही 160 हैं। शॉर्ट_मेज़ ऑक्टेट्स में मापा गया एक टेक्स्ट फ़ील्ड है, और बाइट्स में बाइनरी नहीं है। शायद रचनाकारों ने अन्य, अधिक परिष्कृत विकल्पों पर ध्यान दिया।
स्पष्ट कारणों के लिए, SMPP क्लाइंट का डेवलपर अपने कार्य को सरल बनाना चाहता है। और इसके पक्ष में संक्षिप्त एसएमएस के साथ संवाद करने की तलाश नहीं है। SMSC प्रोटोकॉल के अनुसार, MAY मैसेज_पेयूट फील्ड के माध्यम से ऐसी सर्विस प्रदान करता है (स्वतंत्र रूप से मैसेज को एसएमएस में विभाजित करें, हेडर प्रदान करें) अपनी पसंद (मानकीकृत नहीं) के रूप में। लेकिन प्रोटोकॉल की आवश्यकता नहीं है। हां, और आप इसे बिना किसी डर के केवल साधारण पाठ संदेशों पर लागू कर सकते हैं। व्यापारिक दृष्टिकोण से, यह सवाल भी फिसलन भरा है - ऐसे संदेशों को कैसे रेट किया जाए? लेकिन क्या होगा अगर सभी संदेश भागों ने स्थिति नहीं दी है?

चौथा दोष संबंधित समय प्रारूप से संबंधित है। निर्दिष्ट समय को मापने के लिए क्या? जब क्लाइंट या SMSC पर कोई देरी नहीं होती है और उनके बीच अच्छा संवाद होता है, तो आमतौर पर सवाल नहीं उठते हैं। लेकिन अगर किसी जगह पर देरी हो रही है, तो क्लाइंट और एसएमएससी के संदर्भ बिंदुओं में काफी गिरावट आती है।
शेड्यूल_डेलीवरी_टाइम के लिए, खंड 5.2.15 निर्दिष्ट करता है:

".. वर्तमान SMSC से संबंधित समय जिस पर इस संदेश का वितरण SMSC द्वारा किया जाएगा .."

लेकिन यह संदर्भ के विभिन्न बिंदुओं की समस्या को हल नहीं करता है।

साहित्य

• लघु संदेश सहकर्मी से सहकर्मी प्रोटोकॉल विशिष्टता v3.4
• [जीएसएम ०३.४०] शॉर्ट मैसेज सर्विस पॉइंट टू प्वाइंट »के तकनीकी अहसास