ما هو SMPP؟ بروتوكول جلسات الرسائل القصيرة SMS
شرح SMPP دون مصطلحات معقدة: عمليات الربط (bind) والنوافذ ووحدات PDU ومسار إيصالات التسليم، ولماذا يهم شكل الجلسة عند الأحجام الكبيرة.
بروتوكول SMPP هو البروتوكول الذي تستخدمه المنصة لتبادل الرسائل القصيرة مع مركز الرسائل عبر جلسة مستمرة. ويحدد الربط (bind) الاتجاه، وتحمل الجلسة نافذة لمعدل النقل، وتعود إيصالات التسليم في صورة وحدات PDU. وهو ليس واجهة API تعمل بنمط الطلب والاستجابة.
حقائق أساسية
- بروتوكول SMPP جلسة مستمرة باتجاه ربط معلَن.
- يحمل الربط تخصيصاً لمعدل النقل ونافذة للطلبات المعلّقة.
- لوحدة PDU ترويسة بطول 16 بايت ومتن خاص بالأمر.
- تصل إيصالات التسليم بشكل غير متزامن عبر الجلسة؛ وتُطابَق بمعرّف الرسالة.
في هذه الصفحة
جلسة، لا مكالمة
يُبقي SMPP اتصالاً مفتوحاً بين منصتكم ومركز الرسائل. إذ تتحقق المنصة من هويتها مرة واحدة، وتعلن ما تريد فعله، ثم ترسل الرسائل وتتلقى الأحداث عبر الجلسة نفسها. ولا ينتظر مركز الرسائل طلباً جديداً كي يرسل إيصالاً أو رسالة واردة؛ بل يدفع وحدة PDU متى كان لديه ما يبلّغ عنه.
يناسب هذا الشكل التدفق المنتظم. فالعبء لكل رسالة صغير لأن حالة الجلسة قائمة مسبقاً، وقناة الإيصالات مفتوحة مسبقاً. ويعني ذلك أيضاً أن عميلكم يتولى حالة لا يتولاها عميل HTTP: حالة الربط، ونافذة الطلبات الجارية، وتوقيت رسائل الإبقاء على الاتصال (keep-alive)، وسلوك إعادة الاتصال.
الربط يحدد الاتجاه
الربط (bind) هو الجلسة الموثَّقة مضافاً إليها اتجاه. فربط المرسِل (transmitter) يرسل الرسائل. وربط المستقبِل (receiver) يتلقى الرسائل الصادرة من الأجهزة المحمولة والإيصالات. وربط المرسِل والمستقبِل (transceiver) يجمع الأمرين في جلسة واحدة. ويُصدر المزوّد بيانات اعتماد لكل ربط، وقد يحدّ من عدد عمليات الربط التي يمكنكم فتحها.
وسّعوا السعة بإضافة عمليات ربط، لا بدفع ربط واحد إلى ما يتجاوز تخصيصه. فالربط الواحد يحمل تخصيصاً واحداً لمعدل النقل ونافذة واحدة للطلبات المعلّقة. وإذا احتاجت ذروتكم إلى أكثر من ذلك، فاطلبوا ربطاً إضافياً ووزّعوا الحركة. أما الربط الواحد الذي يُدفع إلى ما يتجاوز نافذته فينتج عنه تقييد للمعدل ومهلات منتهية وإعادة محاولات تبدو كأنها عطل في الشبكة، لكنها تبدأ في العميل.
الربط، ثم الإرسال، ثم الإيصال
- التطبيق (ESME)
- bind_transceiver فتح الجلسة
- SMSC
- submit_sm_resp مقبولة للتسليم
- إيصال التسليم
وصف نصي
يفتح التطبيق ربطاً فيجيب مركز الرسائل. ويرسل التطبيق رسالة قصيرة بالأمر submit_sm ويتلقى submit_sm_resp مع معرّف الرسالة. وفي وقت لاحق، يرسل مركز الرسائل وحدة deliver_sm PDU تحمل إيصال التسليم. ويقرّ التطبيق باستلامها بالأمر deliver_sm_resp. ويغلق الأمر unbind الجلسة عند انتهاء العمل.
النافذة هي العقد
النافذة هي عدد الطلبات التي يجوز لعميلكم أن يتركها معلّقة قبل أن ينتظر الاستجابات. وهي ليست اقتراحاً. فإذا أرسلتم أكثر مما تسمح به النافذة، قيّد مركز الرسائل معدلكم؛ وإذا واصلتم إعادة المحاولة بالمعدل نفسه، كبرت قائمة الانتظار. اقرؤوا رمز الاستجابة لكل إرسال، وأبطئوا عند تقييد المعدل، ودعوا النافذة تفرغ قبل الدفعة التالية.
تُبقي حركة الإبقاء على الاتصال الجلسة مفتوحة. فالعميل الذي لا يرسل enquire_link أبداً قد يبقى على اتصال ميت حتى يفشل أول إرسال. والعميل الذي يعيد الاتصال فوراً بعد كل انقطاع قد يُثقل على المزوّد. استخدموا التراجع التدريجي (backoff)، وحدّوا معدل إعادة الاتصال، وأطلقوا تنبيهاً عندما يظل الربط متوقفاً مدة أطول مما تحتمله حركتكم.
وحدة PDU واحدة، حقلاً حقلاً
- command_length
- 53
- command_id
- 0x00000004
- command_status
- 0x00000000
- sequence_number
- 1
- service_type
- source_addr_ton
- 1
- source_addr_npi
- 1
- source_addr
- 12345
- dest_addr_ton
- 1
- dest_addr_npi
- 1
- destination_addr
- 15551234567
- esm_class
- 0x00
- protocol_id
- 0x00
- priority_flag
- 0
- schedule_delivery_time
- validity_period
- registered_delivery
- 0x01
- replace_if_present_flag
- 0x00
- data_coding
- 0x00
- sm_default_msg_id
- 0x00
- sm_length
- 4
- short_message
- 54657374
- النص
- Test
وصف نصي
تبدأ كل وحدة PDU بطول أمر من أربعة بايتات، ومعرّف أمر من أربعة بايتات، وحالة أمر من أربعة بايتات، ورقم تسلسلي من أربعة بايتات. ثم يلي ذلك المتن. وفي submit_sm يحمل المتن عنواني المصدر والوجهة، والرسالة القصيرة، وترميز البيانات، وعلامة التسليم المسجَّل (registered-delivery). وتنتقل المعاملات الاختيارية في صورة حقول وسم-طول-قيمة (TLV).
يوم في حياة رسالة
يفتح العميل ربط transceiver ويقرأ استجابة الربط. ثم يرسل رسالة ويخزّن معرّف الرسالة من الاستجابة. ويوجّه مركز الرسائل الرسالة إلى شبكة الوجهة. وبعد دقائق، تصل وحدة deliver_sm PDU تحمل الإيصال: معرّف الرسالة الأصلي، وحالة، وغالباً رمز شبكة. ويقرّ العميل باستلام الإيصال ويطابق الحالة مع سجله الخاص.
لكل خطوة نمط إخفاق. فقد يُرفض الربط بسبب بيانات اعتماد خاطئة أو إصدار واجهة غير صحيح. وقد يُقيَّد الإرسال أو يُرفض، أو يُقبل ثم يفشل في الإيصال. وقد يصل الإيصال بعد انتهاء صلاحية الرمز. صمّموا العميل بحيث يخزّن معرّف الرسالة، ويقبل الإيصال المتأخر، ويُبقي حالة التطبيق نفسه المرجع المعتمد لما فعله المستخدم.
فكّوا ترميز الإيصال قبل تشخيص المسار
الصقوا إيصال تسليم في أداة فك ترميز SMPP وDLR واقرؤوا الحقول. تحقّقوا من معرّف الرسالة والحالة وتاريخ الإنجاز ورمز الخطأ. وإذا لم تكن الحالة DELIVRD، فإن رمز الخطأ، عند قراءته مقابل جدول رموز المزوّد، قد يشير إلى ما إذا كان الرقم أو الجهاز أو الشبكة هو الذي رفض الرسالة. افعلوا ذلك قبل أن تطلبوا من المزوّد تغيير المسار.
الإيصالات وتشخيص الأعطال
الإيصال غير متزامن. فهو يصل عبر الجلسة في صورة وحدة deliver_sm PDU، ويعتمد شكله على مركز الرسائل. وتحمل الأنظمة الأحدث الحالة في حقل message_state بصيغة وسم-طول-قيمة (TLV). أما الأقدم فتضع إيصالاً نصياً في حقل الرسالة القصيرة، مع أزواج مفتاح-قيمة مثل id وstat وerr. حلّلوا الشكلين معاً بدلاً من افتراض أحدهما.
طابقوا بمعرّف الرسالة، لا بترتيب الوصول. فرسالتان أُرسلتا بفارق ثانية قد تعودان بالترتيب المعاكس، وقد تُنتج إعادة المحاولة إيصالاً مكرراً. خزّنوا المعرّف عند الإرسال، وحدّثوا السجل عند وصول الإيصال، وتجاهلوا الإيصال الثاني للمعرّف نفسه ما لم تكن حالته أحدث. ويحوّل دليل الاتصال ذلك إلى تسلسل تشغيلي.
تحقق مما تعلمته
-
لماذا يفيد ربط ثانٍ أكثر من رفع معدل إعادة المحاولة؟
يحمل الربط نافذة واحدة. فإضافة ربط تضيف سعة؛ أما إعادة المحاولة أمام نافذة ممتلئة فتضيف إلى قائمة الانتظار والتأخير.
-
من أين يأتي معرّف الرسالة؟
يعيده مركز الرسائل في submit_sm_resp. خزّنوه وطابقوا به الإيصال اللاحق.
-
ما الذي يثبته إيصال يفيد بأن الرسالة سُلِّمت؟
أن الشبكة قبلت الرسالة وسلّمتها إلى مسار الجهاز. ولا يثبت أن شخصاً قرأها.
تظهر الإجابات عند الطلب. لا يتم تقييم أي شيء أو تخزينه أو إرساله.
الأسئلة الشائعة
هل نحتاج إلى SMPP للبدء؟
ما هو الربط (bind)؟
ما هي وحدة PDU؟
هل يمكننا استخدام SMPP عبر الإنترنت العام؟
كيف تُعالَج الرسائل الطويلة؟
ذات صلة
- الاتصال عبر SMPP وHTTP
انقل مسار الاختبار إلى الإنتاج دون كسر الربط أو النوافذ أو الإيصالات: الربط، ومعدل النقل، والإبقاء على الاتصال حيا، والترميز، واستدعاءات الرد، ومعالجة الأعطال.
- حزمة قوالب RFQ وRFP
قوائم الحقول لطلبات SMS بالجملة وeSIM والبيانات وIoT والاتصال بالصين، إضافة إلى قائمة التحقق عبر الإنترنت التي ترسل كطلب RFQ.
- تقرير نموذجي لاختبار المسار
نموذج ثابت مجهل البيانات لتقرير اختبار المسار: ما يتحقق منه الاختبار، وكيف تقرأ حالات الإخفاق، وما الذي يستدعي مراجعة المسار.
منتجات ذات صلة
ضع هذا موضع التطبيق
أخبرنا بحركة المرور والوجهة والقياس الذي تحتاجه؛ وسنرد بالخطوة التالية.