SMPP: الدليل الكامل للبروتوكول.

ما هو SMPP وأين يندرج

تتضمن جلسة SMPP دائمًا دورين. ESME (كيان المراسلة القصيرة الخارجي) هو تطبيقك — منصة SMS جماعية، أو خدمة OTP، أو نظام تنبيهات. أما SMSC (مركز خدمة الرسائل القصيرة)، ويُسمّى MC (مركز خدمة الرسائل) في الإصدار 5.0، هو عقدة المشغّل أو المجمِّع التي تخزّن الرسائل وتمرّرها من الهواتف وإليها عبر شبكة الهاتف المحمول. يتصل ESME بـ SMSC، ويتصل SMSC بشبكة SS7 / النواة الأوسع للشبكة المحمولة.

SMPP هو العمود الفقري لمراسلة A2P (من التطبيقات إلى الأشخاص) — رموز التحقق لمرة واحدة، والإيصالات، والتنبيهات، والتسويق — بخلاف رسائل P2P (من شخص إلى شخص) المتبادلة بين هاتفين. وتتميز حركة A2P بحجمها الكبير، وتوليدها الآلي، واعتمادها على إيصالات التسليم، وهذا تحديدًا ما صُمم بروتوكول SMPP لنقله.

لماذا بروتوكول TCP ثنائي بدلاً من HTTP؟ ربط (bind) SMPP الواحد هو مقبس (socket) طويل الأمد. بمجرد فتحه تتجنب مصافحة TCP وTLS لكل رسالة، ويمكن أن تكون رسائل عديدة قيد الإرسال في آن واحد (النوافذ غير المتزامنة – asynchronous windowing)، ويقوم مركز خدمة الرسائل القصيرة (SMSC) بإرسال إيصالات التسليم والرسائل الواردة مباشرةً عبر نفس الاتصال. عند معدل نقل بيانات عالٍ ومستدام، يكون هذا أكثر كفاءة بشكل ملحوظ من واجهة برمجة تطبيقات HTTP التي تعتمد على طلب/استجابة - ولهذا السبب يعتمده المشغّلون وكبار المرسلين معيارًا.

سجل الإصدارات

• SMPP الإصدار 3.3 — أول إصدار واسع الانتشار؛ قدّم المجموعة الأساسية من وحدات PDU، لكنه سبق ظهور معاملات TLV (المعاملات الاختيارية) وربط الإرسال والاستقبال (transceiver).
• SMPP الإصدار 3.4 — الإصدار السائد في الإنتاج اليوم. أضاف ربط الإرسال والاستقبال (transceiver)، ومعاملات TLV الاختيارية، وmessage_payload، وdata_sm. وتكاد كل عملية تكامل حقيقية ستبنيها تعتمد الإصدار 3.4.
• SMPP الإصدار 5.0 — أحدث إصدار. يُعيد تسمية SMSC إلى MC (مركز خدمة الرسائل)، ويضيف وحدات PDU للبث (broadcast_sm)، وإشارات حالة الازدحام، ومعاملات TLV أكثر توحيدًا. انتشاره محدود؛ ادعم الإصدار 3.4 أولًا، واعتبر الإصدار 5.0 اختياريًا.

البنية وأنواع الربط (bind)

البنية بسيطة: يفتح ESME اتصال TCP مع SMSC/MC، ثم يُجري عملية المصادقة باستخدام system_id و password. ويُحدَّد الاتجاه الذي يُسمح للجلسة بنقل الحركة فيه لحظة الربط باختيار أحد ثلاثة أوضاع ربط، ولكل وضع وحدة PDU ربط مختلفة.

والطرف الرابع هو التوجيه: يُحدد SMSC، لكل رسالة على حدة، مسار المشغّل أو وصلة الربط البيني التي تسلكها الرسالة المُرسلة نحو الهاتف المستهدف، وأيّ ESME مربوط تعود إليه الرسالة الواردة (المُرسلة من الهاتف المحمول، MO).

على الشبكة، يعمل بروتوكول SMPP عبر بروتوكول TCP. المنفذ الافتراضي المسجل لدى IANA هو 2775 للوصلات العادية. SMPPS — بروتوكول SMPP المُغلّف ببروتوكول TLS — ليس له منفذ قياسي واحد؛ يُتيحه مُزوّدو الخدمة على منفذ من اختيارهم (3550 و8775 و2776 شائعة الاستخدام). استخدم دائمًا المنفذ المُشفّر الذي يُخصّصه مُزوّد الخدمة للإنتاج.

دورة حياة الجلسة

تتبع كل جلسة SMPP نفس المسار: فتح TCP، والربط، والبقاء نشطة، وتبادل الرسائل والإيصالات، ثم فك الربط والإغلاق. يوضح الرسم أدناه جلسة transceiver كاملة — كل صف يمثل وحدة PDU واحدة؛ الأزرق يتدفق من ESME إلى SMSC، والأخضر يتدفق عائدًا.

تفصيلان مهمان. أولاً، submit_sm_resp يعود فورًا ولا يعني سوى "قُبلت للتسليم" — أما النتيجة الحقيقية فتصل لاحقًا في إيصال deliver_sm. ثانيًا، لكل طلب PDU استجابة _resp مطابقة تُعيد قيمة sequence_number نفسها، وبها تُربط الاستجابات غير المتزامنة بطلباتها.

تشريح وحدة PDU

كل شيء على اتصال SMPP هو وحدة بيانات البروتوكول (PDU). تبدأ كل وحدة PDU بـترويسة ثابتة من 16 بايت تتألف من أربعة أعداد صحيحة، كل منها 4 بايت (32 بت، بنظام Big-Endian)، متبوعة بجسم خاص بالأمر. اقرأ الترويسة أولاً، وستعرف بالضبط كيف تقرأ الباقي.

ينتهي الجسم بأي عدد من معاملات TLV — معلمات اختيارية مُشفّرة كـ Tag (بايتان)، وLength (بايتان)، وValue (عدد بايتات الطول). تُعدّ TLVs الطريقة التي وسّع بها الإصدار 3.4 البروتوكول دون كسر التوافق مع الأنظمة القديمة: message_payload، وreceipted_message_id، وحقول تجميع المقاطع sar_*، وغيرها الكثير جميعها تُرسل كـ TLVs.

يُعدّ sequence_number مفتاح آلية النوافذ (windowing). ولأن بروتوكول SMPP غير متزامن، يمكن لـ ESME إرسال العديد من وحدات بيانات البروتوكول submit_sm - كل منها برقم تسلسلي متزايد - قبل وصول أي ردود. وعندما تعود وحدات بيانات البروتوكول submit_sm_resp، يُخبرك رقمها التسلسلي بأي عملية إرسال يُجيب عنها كل منها. ويُعرف عدد وحدات بيانات البروتوكول غير المُؤكدة المسموح بها أثناء النقل بـ حجم النافذة.

مرجع وحدات PDU الأساسية

هذه هي العمليات التي ستستخدمها فعليًا. لكل طلب وحدة PDU استجابة تكون قيمة command_id فيها هي معرّف الطلب مع ضبط البت الأعلى (0x80000000)، لذا فإن submit_sm 0x00000004 يُقابل submit_sm_resp 0x80000004.

حقول submit_sm حقلًا حقلًا

submit_sm هي وحدة PDU التي سترسلها في أغلب الأحيان. يتكون جسمها من سلسلة من المعلمات الإلزامية، تليها قيم TLV اختيارية. هذه هي الحقول المهمة عمليًا.

ترميز البيانات (data_coding) وتجميع المقاطع

الحقل data_coding (مخطط ترميز البيانات، DCS) يُخبر الهاتف بكيفية تفسير البايتات، ويحدد عدد الأحرف التي تتسع لها رسالة SMS واحدة.

يتم تقسيم الرسالة التي يزيد طولها عن مقطع واحد وإعادة تجميعها على الهاتف باستخدام UDH (رأس بيانات المستخدم) تُضاف في بداية كل مقطع. يستخدم عنصر التجميع IEI 0x00 (مرجع 8 بت) — ترويسة من 6 أوكتيتات تحمل رقمًا مرجعيًا، والعدد الإجمالي للأجزاء، وترتيب هذا الجزء. هذه الأوكتيتات الستة هي سبب انخفاض حد كل جزء إلى 153 (GSM 7-bit) و67 (UCS-2). وعند إرسال UDH داخل short_message، يجب أيضًا ضبط البت UDHI (0x40) في esm_class.

هناك طريقتان لإرسال محتوى طويل: إما إنشاء أجزاء مجزأة باستخدام UDH بنفسك (كل جزء عبارة عن submit_sm مع مجموعة UDHI)، أو إرسال النص الكامل إلى مركز خدمة الرسائل القصيرة (SMSC) في message_payload ودَعه يتولى التجزئة. وبدلًا من ذلك، تقبل بعض مراكز SMSC معاملات TLV التالية: sar_msg_ref_num / sar_total_segments / sar_segment_seqnum لوصف التجميع دون UDH.

إيصالات التسليم (DLR)

عند ضبط registered_delivery = 1، يُبلغك SMSC لاحقًا بمصير الرسالة بإرسال deliver_sm مع ضبط بت إيصال التسليم في esm_class (0x04). ويُخزَّن نص الإيصال في حقل short_message كسلسلة كلمات مفتاحية معروفة:

id:1a2b3c4d5e sub:001 dlvrd:001 submit date:2607251432 done date:2607251432 stat:DELIVRD err:000 text:Your code is 8

يطابق الحقل id قيمة message_id التي تلقيتها في submit_sm_resp (كما يظهر أيضًا في receipted_message_id TLV 0x001E). ويحمل الحقل stat الحالة النهائية:

أجب دائمًا على رسالة deliver_sm بـ deliver_sm_resp؛ وإلا فسيعيد SMSC إرسال الإيصال، وقد يخنق الربط أو يقطعه. يُرجى ملاحظة أن تنسيق الإيصال ليس موحدًا تمامًا إذ يختلف مقدمو الخدمات اختلافًا طفيفًا في ترتيب الحقول وخريطة رموز الخطأ.

رموز الخطأ / command_status

تحمل كل وحدة PDU استجابة command_status في ترويستها — وهو رمز من نوع ESME_R*. القيمة صفر تعني النجاح؛ وأي قيمة أخرى تصف سبب رفض الطلب. وهذه هي الرموز التي ستصادفها أكثر من غيرها.

يمكن البحث في السجل الكامل — بما في ذلك النطاقات الخاصة بكل مزوّد — في مرجع رموز أخطاء بروتوكول SMPP.

معدل نقل الرسائل (TPS) والنوافذ (windowing) والخنق (throttling)

يُقاس معدل نقل الرسائل في SMPP بوحدة TPS — عدد المعاملات (submit_sm) في الثانية — ويخضع ذلك لأمرين: المعدل الذي يسمح به مركز خدمة الرسائل القصيرة (SMSC)، وعدد الرسائل التي تُبقيها قيد الإرسال. ولأن بروتوكول SMPP غير متزامن، فلا داعي لانتظار كل submit_sm_resp قبل إرسال وحدة بيانات البروتوكول (PDU) التالية. عدد عمليات الإرسال غير المُؤكدة التي تسمح بها في وقت واحد هوحجم النافذة (عادةً من 10 إلى 100). النافذة الأكبر تُخفي زمن الذهاب والإياب وترفع معدل TPS الفعلي — حتى الحد الأقصى لدى SMSC.

• احترم الخنق (throttle). عندما يُعيد SMSC الرمز ESME_RTHROTTLED (0x58)، أبطئ — توقف مؤقتًا ثم أعد المحاولة بتأخير أسّي (exponential backoff) بدلًا من إغراق الربط بالطلبات، وهو ما قد يؤدي إلى قطع اتصالك.
• أرسل keepalive بإيقاع منتظم. أرسل enquire_link كل 30 ثانية تقريبًا أثناء الخمول؛ وإذا بقيت عدة طلبات بلا رد، فاعتبر الاتصال منقطعًا.
• أعد الاتصال عمداً. عند انقطاع الاتصال، أعد الاتصال وأعد الربط بتأخير متزايد (backoff) مع تفاوت عشوائي (jitter)؛ وتجنّب الحلقات المتلاحقة. تتبّع قيم sequence_number المعلّقة لتتمكن من مطابقة الإيصالات بعد إعادة الاتصال.
• توسّع بعدة عمليات ربط، بحرص. عادةً ما يأتي ارتفاع إجمالي TPS من عدة عمليات ربط (binds)، ولكن فقط في حدود ما يسمح به مزوّدك لكل حساب.

نموذج التعليمات البرمجية

رسم توضيحي لعملية الاتصال ← الربط ← الإرسال باستخدام شيفرة زائفة على نمط Node.js. تتولى مكتبات SMPP الحقيقية (مثل node-smpp، وjSMPP للغة Java، وpython-smpplib) ترميز وحدات بيانات البروتوكول (PDU) نيابةً عنك؛ يوضح هذا الرسم بنية الجلسة وليس واجهة برمجة تطبيقات مكتبة محددة.

import smpp from "smpp";

// 1. Open a TCP (or TLS) session to the SMSC.
const session = smpp.connect({
  // Host, port and bind credentials come with your test access.
  // Plain SMPP conventionally uses 2775; the TLS port is provided with your account.
  url: process.env.SMPP_URL!,             // e.g. smpp://<host>:2775 (plain) or smpps://<host>:<tls-port>
  auto_enquire_link_period: 30000,        // keepalive every 30s
});

// 2. Bind as a transceiver.
session.bind_transceiver(
  {
    system_id: "YOUR_SYSTEM_ID",
    password:  "YOUR_PASSWORD",
    system_type: "",
  },
  (pdu) => {
    if (pdu.command_status !== 0) {
      throw new Error("bind failed: 0x" + pdu.command_status.toString(16));
    }

    // 3. Submit a Unicode message, asking for a delivery receipt.
    session.submit_sm(
      {
        source_addr_ton: 5,                // alphanumeric Sender ID
        source_addr:      "BroadNet",
        dest_addr_ton:    1,               // international E.164
        destination_addr: "447700900123",
        registered_delivery: 1,            // request a DLR
        data_coding: 8,                    // UCS-2 (Unicode)
        short_message: "Your code is 8123",
      },
      (submitResp) => {
        // submit_sm_resp returns the SMSC message_id.
        console.log("accepted, message_id =", submitResp.message_id);
      }
    );
  }
);

// 4. Receive delivery receipts on the same session.
session.on("deliver_sm", (pdu) => {
  if ((pdu.esm_class & 0x04) === 0x04) {   // delivery-receipt bit
    console.log("DLR:", pdu.short_message.message);
  }
  session.send(pdu.response());            // ALWAYS deliver_sm_resp
});

BroadNet SMPP

تُشغّل BroadNet بوابة SMSC بمستوى المشغّلين تقبل عمليات ربط SMPP v3.4 عبر TLS. ستحصل على ربط transceiver، ومعدل TPS مرتفع مع نوافذ غير متزامنة، وإيصالات تسليم كاملة، ودعم Unicode وتجميع المقاطع، واتصال موثّق بقائمة عناوين IP مسموح بها للوصول إلى المشغّلين حول العالم. إنه البروتوكول نفسه الذي تشرحه هذه الصفحة — موجَّهًا إلى مسارات حقيقية.

الأسئلة الشائعة

الأدوات والوثائق ذات الصلة