एक ऐप्लिकेशन प्राप्तकर्ता का फ़ोन उपलब्ध होने से पहले ही टेक्स्ट सबमिट कर सकता है। एक SMPP कनेक्शन उस सबमिशन और बाद के ऑपरेशन को ले जाता है जो बताते हैं कि क्या हुआ।
कनेक्शन क्या ले जाता है?
SMPP कनेक्टेड सिस्टम के बीच मैसेज सबमिशन, इनकमिंग मैसेज और डिलीवरी रिपोर्ट ले जाता है।
आपका ऐप्लिकेशन एक गेटवे से कनेक्ट हो सकता है जो ट्रैफ़िक को आगे रूट करता है। यह सीधे मैसेज सेंटर से भी कनेक्ट हो सकता है जहाँ प्रदाता उस व्यवस्था का समर्थन करता है।
SMPP संदर्भ उन भूमिकाओं और ऑपरेशन का वर्णन करता है। एक मैसेज सेंटर टेक्स्ट स्टोर करता है और उन्हें प्राप्तकर्ताओं की ओर फ़ॉरवर्ड करता है।
आपके ऐप्लिकेशन और सेंटर के बीच एक गेटवे एक अतिरिक्त रूटिंग चरण जोड़ता है। प्रोटोकॉल का नाम अकेले यह नहीं बताता कि कितने सिस्टम मैसेज को संभालते हैं।
SMPP सेशन कैसे काम करता है?
आपका क्लाइंट एक कनेक्शन खोलता है। यह सेशन को ऑथेंटिकेट करता है और इसे मैसेज ऑपरेशन के लिए उपलब्ध रखता है।
ऑथेंटिकेशन चरण को bind कहा जाता है। एक ट्रांसमीटर सेशन मैसेज भेजता है। एक रिसीवर सेशन उन्हें प्राप्त करता है। एक ट्रांसीवर सेशन दोनों दिशाओं का समर्थन करता है।
आपके वर्कफ़्लो के अनुसार आवश्यक सेशन प्रकार का उपयोग करें। जब आपको इनकमिंग ऑपरेशन चाहिए तो सेंड-ओनली कनेक्शन रिसीविंग सेशन की जगह नहीं ले सकता।
आपके क्लाइंट को कनेक्शन टूटने से रिकवर करना होगा। इसे प्राप्त होने वाले ऑपरेशन को acknowledge भी करना होगा। रिस्पॉन्स की प्रतीक्षा कर रहे रिक्वेस्ट को ट्रैक करें ताकि देरी से आया रिस्पॉन्स सही रिक्वेस्ट से मैच हो।
क्या सबमिशन रिस्पॉन्स डिलीवरी साबित करता है?
सबमिशन रिस्पॉन्स बताता है कि कनेक्टेड सर्विस ने सबमिशन स्वीकार किया या नहीं, यह नहीं कि फ़ोन ने टेक्स्ट प्राप्त किया या नहीं।
submit_sm ऑपरेशन एक मैसेज सबमिट करता है। इसका संबंधित submit_sm_resp उस रिक्वेस्ट का परिणाम रिपोर्ट करता है।
इनकमिंग मैसेज और डिलीवरी रिसीट्स deliver_sm के ज़रिए आ सकती हैं। डिलीवरी-रिसीट संदर्भ रिसीट ऑपरेशन और उनकी सामग्री समझाता है।
अपने ऐप्लिकेशन में सबमिशन परिणाम को डिलीवरी परिणाम से अलग रखें। एक मैसेज स्वीकार हो सकता है और बाद में विफल हो सकता है क्योंकि प्राप्तकर्ता अनुपलब्ध रहता है।
जब मैं इसके बजाय HTTP API का उपयोग करूँ तो क्या बदलता है?
HTTP रिक्वेस्ट और रिस्पॉन्स ऑपरेशन उपलब्ध कराता है, बिना आपके ऐप्लिकेशन को SMPP bind प्रबंधित करने की आवश्यकता के।
आपके ऐप्लिकेशन को अभी भी फिर से प्रयास करना संभालना होगा। इसे बाद के डिलीवरी परिणामों को भी प्रोसेस करना होगा। HTTP कैरियर की एसिंक्रोनस डिलीवरी को सिंक्रोनस गारंटी में नहीं बदलता।
Bird के साथ, आप POST /v1/sms/messages के ज़रिए सबमिट करते हैं और लौटाए गए मैसेज आइडेंटिफ़ायर को ट्रैक करते हैं। भेजने की गाइड 202 स्वीकृति रिस्पॉन्स समझाती है। SMS इवेंट्स बाद की डिलीवरी रिपोर्ट प्रदान करता है।
वे API जिम्मेदारियाँ किसी प्रदाता से SMPP कनेक्शन प्रबंधित करने से अलग हैं। API और गेटवे परतों को समझाता है।
क्या SMPP का उपयोग प्रदाताओं को विनिमेय बनाता है?
प्रदाता सिर्फ़ इसलिए विनिमेय नहीं हैं क्योंकि वे एक ही प्रोटोकॉल साझा करते हैं। वे अलग-अलग ऑपरेशन, एन्कोडिंग और सीमाओं का समर्थन कर सकते हैं।
ट्रैफ़िक स्थानांतरित करने से पहले आपका ऐप्लिकेशन जिन क्षमताओं का उपयोग करता है उनका परीक्षण करें। एक सफल bind यह साबित नहीं करता कि हर आवश्यक ऑपरेशन उस प्रदाता पर काम करता है।
गेटवे संदर्भ इम्प्लीमेंटेशन सपोर्ट और प्रदर्शन के परीक्षण की सिफ़ारिश करता है। कनेक्शन बदलते समय अपनी डिलीवरी जाँच बनाए रखें, न कि नए एंडपॉइंट को पूर्ण माइग्रेशन मानें।
मुझे SMPP कब चुनना चाहिए?
SMPP तब चुनें जब किसी मौजूदा सिस्टम को persistent bind या SMPP-विशिष्ट इनकमिंग ऑपरेशन की आवश्यकता हो।
- बिना किसी विशिष्ट SMPP आवश्यकता वाले नए ऐप्लिकेशन के लिए HTTP का उपयोग करें।
- SMPP का उपयोग करें जब किसी मौजूदा सिस्टम को persistent bind या SMPP-विशिष्ट इनकमिंग ऑपरेशन की आवश्यकता हो।
- प्रोडक्शन ट्रैफ़िक स्थानांतरित करने से पहले प्रदाता सपोर्ट और डिलीवरी परिणामों का परीक्षण करें।
संक्षेप में
आपका क्लाइंट एक सेशन प्रबंधित करता है।
यह कनेक्शन को ऑथेंटिकेट करता है और कनेक्शन विफल होने पर रिकवरी संभालता है।
सबमिशन और डिलीवरी अलग-अलग ऑपरेशन हैं।
एक सफल सबमिशन रिस्पॉन्स यह साबित नहीं करता कि हैंडसेट ने मैसेज प्राप्त किया।
सपोर्ट प्रदाताओं के बीच भिन्न होता है।
यह मानने के बजाय कि प्रोटोकॉल प्रदाताओं को विनिमेय बनाता है, ऑपरेशन, एन्कोडिंग और क्षमता का परीक्षण करें।
HTTP SMPP सेशन प्रबंधन से बचा सकता है।
HTTP SMPP bind प्रबंधित करने से बचाता है, जबकि आपका ऐप्लिकेशन अभी भी डिलीवरी इवेंट्स संभालता है।