# ما هو SMPP؟ بروتوكول جلسات الرسائل القصيرة SMS

بروتوكول SMPP هو البروتوكول الذي تستخدمه المنصة لتبادل الرسائل القصيرة مع مركز الرسائل عبر جلسة مستمرة. ويحدد الربط (bind) الاتجاه، وتحمل الجلسة نافذة لمعدل النقل، وتعود إيصالات التسليم في صورة وحدات PDU. وهو ليس واجهة API تعمل بنمط الطلب والاستجابة.

- بروتوكول SMPP جلسة مستمرة باتجاه ربط معلَن.

- يحمل الربط تخصيصاً لمعدل النقل ونافذة للطلبات المعلّقة.

- لوحدة PDU ترويسة بطول 16 بايت ومتن خاص بالأمر.

- تصل إيصالات التسليم بشكل غير متزامن عبر الجلسة؛ وتُطابَق بمعرّف الرسالة.

## جلسة، لا مكالمة

يُبقي SMPP اتصالاً مفتوحاً بين منصتكم ومركز الرسائل. إذ تتحقق المنصة من هويتها مرة واحدة، وتعلن ما تريد فعله، ثم ترسل الرسائل وتتلقى الأحداث عبر الجلسة نفسها. ولا ينتظر مركز الرسائل طلباً جديداً كي يرسل إيصالاً أو رسالة واردة؛ بل يدفع وحدة PDU متى كان لديه ما يبلّغ عنه.
يناسب هذا الشكل التدفق المنتظم. فالعبء لكل رسالة صغير لأن حالة الجلسة قائمة مسبقاً، وقناة الإيصالات مفتوحة مسبقاً. ويعني ذلك أيضاً أن عميلكم يتولى حالة لا يتولاها عميل HTTP: حالة الربط، ونافذة الطلبات الجارية، وتوقيت رسائل الإبقاء على الاتصال (keep-alive)، وسلوك إعادة الاتصال.

## الربط يحدد الاتجاه

الربط (bind) هو الجلسة الموثَّقة مضافاً إليها اتجاه. فربط المرسِل (transmitter) يرسل الرسائل. وربط المستقبِل (receiver) يتلقى الرسائل الصادرة من الأجهزة المحمولة والإيصالات. وربط المرسِل والمستقبِل (transceiver) يجمع الأمرين في جلسة واحدة. ويُصدر المزوّد بيانات اعتماد لكل ربط، وقد يحدّ من عدد عمليات الربط التي يمكنكم فتحها.
وسّعوا السعة بإضافة عمليات ربط، لا بدفع ربط واحد إلى ما يتجاوز تخصيصه. فالربط الواحد يحمل تخصيصاً واحداً لمعدل النقل ونافذة واحدة للطلبات المعلّقة. وإذا احتاجت ذروتكم إلى أكثر من ذلك، فاطلبوا ربطاً إضافياً ووزّعوا الحركة. أما الربط الواحد الذي يُدفع إلى ما يتجاوز نافذته فينتج عنه تقييد للمعدل ومهلات منتهية وإعادة محاولات تبدو كأنها عطل في الشبكة، لكنها تبدأ في العميل.

### الربط، ثم الإرسال، ثم الإيصال

تُفتح الجلسة مرة واحدة؛ ويتلقى كل إرسال استجابة تحمل معرّف الرسالة؛ ويصل الإيصال لاحقاً عبر الجلسة نفسها.

Alt: تسلسل من التطبيق إلى طلب الربط، ثم مركز الرسائل، ثم استجابة الإرسال، ثم إيصال التسليم.

يفتح التطبيق ربطاً فيجيب مركز الرسائل. ويرسل التطبيق رسالة قصيرة بالأمر submit_sm ويتلقى submit_sm_resp مع معرّف الرسالة. وفي وقت لاحق، يرسل مركز الرسائل وحدة deliver_sm PDU تحمل إيصال التسليم. ويقرّ التطبيق باستلامها بالأمر deliver_sm_resp. ويغلق الأمر unbind الجلسة عند انتهاء العمل.

| Item | Value | Note |
| --- | --- | --- |
| الحالة الأولى · 1 | التطبيق (ESME) |  |
| الحالة الأولى · 2 | bind_transceiver | فتح الجلسة |
| الحالة الأولى · 3 | SMSC |  |
| الحالة الأولى · 4 | submit_sm_resp | مقبولة للتسليم |
| الحالة الأولى · 5 | إيصال التسليم |  |

Source: smpp.org: جلسات SMPP وعمليات وحدات PDU (https://smpp.org/)

## النافذة هي العقد

النافذة هي عدد الطلبات التي يجوز لعميلكم أن يتركها معلّقة قبل أن ينتظر الاستجابات. وهي ليست اقتراحاً. فإذا أرسلتم أكثر مما تسمح به النافذة، قيّد مركز الرسائل معدلكم؛ وإذا واصلتم إعادة المحاولة بالمعدل نفسه، كبرت قائمة الانتظار. اقرؤوا رمز الاستجابة لكل إرسال، وأبطئوا عند تقييد المعدل، ودعوا النافذة تفرغ قبل الدفعة التالية.
تُبقي حركة الإبقاء على الاتصال الجلسة مفتوحة. فالعميل الذي لا يرسل enquire_link أبداً قد يبقى على اتصال ميت حتى يفشل أول إرسال. والعميل الذي يعيد الاتصال فوراً بعد كل انقطاع قد يُثقل على المزوّد. استخدموا التراجع التدريجي (backoff)، وحدّوا معدل إعادة الاتصال، وأطلقوا تنبيهاً عندما يظل الربط متوقفاً مدة أطول مما تحتمله حركتكم.

### وحدة PDU واحدة، حقلاً حقلاً

الترويسة ثابتة؛ والمتن يعتمد على الأمر. وتحمل submit_sm العناوين والترميز وعلامة طلب الإيصال.

Alt: وحدة submit_sm PDU مفكوكة الترميز مع طول الأمر ومعرّف الأمر والحالة والرقم التسلسلي وحقول المتن.

تبدأ كل وحدة PDU بطول أمر من أربعة بايتات، ومعرّف أمر من أربعة بايتات، وحالة أمر من أربعة بايتات، ورقم تسلسلي من أربعة بايتات. ثم يلي ذلك المتن. وفي submit_sm يحمل المتن عنواني المصدر والوجهة، والرسالة القصيرة، وترميز البيانات، وعلامة التسليم المسجَّل (registered-delivery). وتنتقل المعاملات الاختيارية في صورة حقول وسم-طول-قيمة (TLV).

| Item | Value | Note |
| --- | --- | --- |
| 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 |  |

Source: مواصفة SMPP v3.4، ترويسة PDU والأمر submit_sm (https://smpp.org/SMPP_v3_4_Issue1_2.pdf)

## يوم في حياة رسالة

يفتح العميل ربط transceiver ويقرأ استجابة الربط. ثم يرسل رسالة ويخزّن معرّف الرسالة من الاستجابة. ويوجّه مركز الرسائل الرسالة إلى شبكة الوجهة. وبعد دقائق، تصل وحدة deliver_sm PDU تحمل الإيصال: معرّف الرسالة الأصلي، وحالة، وغالباً رمز شبكة. ويقرّ العميل باستلام الإيصال ويطابق الحالة مع سجله الخاص.
لكل خطوة نمط إخفاق. فقد يُرفض الربط بسبب بيانات اعتماد خاطئة أو إصدار واجهة غير صحيح. وقد يُقيَّد الإرسال أو يُرفض، أو يُقبل ثم يفشل في الإيصال. وقد يصل الإيصال بعد انتهاء صلاحية الرمز. صمّموا العميل بحيث يخزّن معرّف الرسالة، ويقبل الإيصال المتأخر، ويُبقي حالة التطبيق نفسه المرجع المعتمد لما فعله المستخدم.

تعمل أداة فك الترميز في المتصفح؛ ويبقى الإيصال الملصق هناك.

[Open the tool](/ar/tools/smpp-decoder/?src=learn-what-is-smpp&scenario=dlr-example&sample=id%3A0123456789+sub%3A001+dlvrd%3A001+submit+date%3A2610181200+done+date%3A2610181201+stat%3ADELIVRD+err%3A000+text%3AYour+code+is+123456)

### فكّوا ترميز الإيصال قبل تشخيص المسار

الصقوا إيصال تسليم في [أداة فك ترميز SMPP وDLR](/ar/tools/smpp-decoder/) واقرؤوا الحقول. تحقّقوا من معرّف الرسالة والحالة وتاريخ الإنجاز ورمز الخطأ. وإذا لم تكن الحالة DELIVRD، فإن رمز الخطأ، عند قراءته مقابل جدول رموز المزوّد، قد يشير إلى ما إذا كان الرقم أو الجهاز أو الشبكة هو الذي رفض الرسالة. افعلوا ذلك قبل أن تطلبوا من المزوّد تغيير المسار.

## الإيصالات وتشخيص الأعطال

الإيصال غير متزامن. فهو يصل عبر الجلسة في صورة وحدة deliver_sm PDU، ويعتمد شكله على مركز الرسائل. وتحمل الأنظمة الأحدث الحالة في حقل message_state بصيغة وسم-طول-قيمة (TLV). أما الأقدم فتضع إيصالاً نصياً في حقل الرسالة القصيرة، مع أزواج مفتاح-قيمة مثل id وstat وerr. حلّلوا الشكلين معاً بدلاً من افتراض أحدهما.
طابقوا بمعرّف الرسالة، لا بترتيب الوصول. فرسالتان أُرسلتا بفارق ثانية قد تعودان بالترتيب المعاكس، وقد تُنتج إعادة المحاولة إيصالاً مكرراً. خزّنوا المعرّف عند الإرسال، وحدّثوا السجل عند وصول الإيصال، وتجاهلوا الإيصال الثاني للمعرّف نفسه ما لم تكن حالته أحدث. ويحوّل [دليل الاتصال](/ar/resources/guides/smpp-http-connection/) ذلك إلى تسلسل تشغيلي.

### Check what you learned

**لماذا يفيد ربط ثانٍ أكثر من رفع معدل إعادة المحاولة؟**

يحمل الربط نافذة واحدة. فإضافة ربط تضيف سعة؛ أما إعادة المحاولة أمام نافذة ممتلئة فتضيف إلى قائمة الانتظار والتأخير.

**من أين يأتي معرّف الرسالة؟**

يعيده مركز الرسائل في submit_sm_resp. خزّنوه وطابقوا به الإيصال اللاحق.

**ما الذي يثبته إيصال يفيد بأن الرسالة سُلِّمت؟**

أن الشبكة قبلت الرسالة وسلّمتها إلى مسار الجهاز. ولا يثبت أن شخصاً قرأها.

## FAQ

**هل نحتاج إلى SMPP للبدء؟**

لا. يمكن إنجاز التكامل عبر HTTP في غضون بضع ساعات؛ ويصبح SMPP مجدياً عندما يبرّر الحجم المنتظم إنشاء جلسة.

**ما هو الربط (bind)؟**

جلسة مستمرة باتجاه معلَن: transmitter أو receiver أو transceiver. وهي تحمل تخصيصاً لمعدل النقل وتبقى مفتوحة بفضل رسائل الإبقاء على الاتصال.

**ما هي وحدة PDU؟**

وحدة بيانات البروتوكول (Protocol Data Unit): الرسالة الثنائية التي يتبادلها SMPP. ولكل وحدة PDU ترويسة بطول 16 بايت ومتن خاص بالأمر.

**هل يمكننا استخدام SMPP عبر الإنترنت العام؟**

غالباً نعم، مع TLS وقائمة سماح لعناوين IP، لكن اسألوا المزوّد. وتستخدم بعض عمليات النشر اتصالاً خاصاً بدلاً من ذلك.

**كيف تُعالَج الرسائل الطويلة؟**

في صورة مقاطع متسلسلة مع ترويسة بيانات المستخدم، أو في صورة حقل TLV لحمولة الرسالة تتولى الشبكة تقسيمه. اختبروا النتيجة على الجهاز.

## Sources

- [smpp.org: جلسات SMPP وعمليات الربط وإيصالات التسليم](https://smpp.org/) — Accessed: 2026-10-19
- [مواصفة SMPP v3.4، الإصدار 1.2](https://smpp.org/SMPP_v3_4_Issue1_2.pdf) — Accessed: 2026-10-19
- [3GPP TS 23.040: التنفيذ التقني لخدمة الرسائل القصيرة (SMS)](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19

Updated: 2026-10-19