أداة تطوير مجانية · بروتوكول
محاكي جلسات SMPP.
استعرض محادثة SMPP 3.4 حقيقية - حيث يتم تبادل PDU بين ESME و SMSC بايتًا بايتًا. حدد أي PDU لعرض حقولها مُرتبطة بالوحدات الثمانية على الشبكة.
هذا لا يرسل رسالة أبداً
كل ما في هذه الصفحة يُعالج في متصفحك. لا يوجد اتصال مباشر، ولا طلبات إلى BroadNet أو أي جهة أخرى، ولا تُرسل أي رسالة من أي نوع إلى أي شبكة. تُستمد معرّفات الرسائل والطوابع الزمنية من مدخلاتك، لذا فإن نفس المدخلات تُنتج دائمًا نفس المخرجات - إنها مجرد أمثلة توضيحية وليست حقيقية.
غير مربوط
على الشبكة — ESME ⇄ SMSC0 PDU
ESMESMSC
لم يتم رصد أي بيانات حتى الآن. شغّل الجلسة لمراقبة PDU الخاصة بتبادل ESME وتبادل SMSC، ثم اختر أيًا منهما لعرض بياناته.
كيف تعمل جلسة SMPP فعلياً
- 1 · ربط. يفتح تطبيقك اتصال TCP مع SMSC ويرسل أمر bind_transceiver مع معرف النظام وكلمة المرور. ولن يتم قبول أي شيء آخر حتى يرد SMSC برسالة command_status 0.
- 2 · إرسال. كل رسالة هي PDU submit_sm. الرد يعطيك معرف الرسالة - وهذا قبول، وليس تسليمًا.
- 3 · إيصال. إذا طلبت واحدة، يقوم مركز خدمة SMSC لاحقًا بإرسال deliver_sm تحمل esm_class 0x04 ونص إيصال يشير إلى message_id.
- 4 · إبقاء الاتصال حيًّا (keepalive). يُثبت enquire_link كل 30-60 ثانية أن الاتصال لا يزال قابلاً للاستخدام. في حال عدم إرسالها، يقوم SMSC بقطع الاتصال.
- 5 · فك الربط. أنهِ الجلسة بشكل سليم حتى لا يعتبرها المشغّل انقطاعًا غير طبيعي.
الأسئلة التي يطرحها المهندسون
- هل يقوم هذا المحاكي بإرسال SMS حقيقية؟
- لا. لا يوجد في الصفحة ما يفتح اتصالاً أو يرسل رسالة إلى أي مكان. يتم حساب كل وحدة بيانات بروتوكول (PDU) وكل رد من SMSC في متصفحك بناءً على القيم التي تُدخلها، لذا فإن نفس المدخلات تُنتج دائمًا نفس النص. إنها أداة تعليمية للبروتوكول، وليست أداة إرسال.
- ما هو الربط في SMPP؟
- الربط هو الجلسة المصادَق عليها بين تطبيقك (ESME) ومركز خدمة الرسائل القصيرة (SMSC) التابع للمشغّل. يقتصر دور bind_transmitter على الإرسال فقط، وbind_receiver على الاستقبال فقط، بينما يقوم bind_transceiver بالأمرين معًا عبر اتصال واحد - وهو ما تستخدمه معظم عمليات التكامل. لا يتم قبول أي بيانات أخرى في الجلسة حتى يكتمل الربط بنجاح.
- ما وظيفة خدمة التوصيل المسجل؟
- يؤدي تعيين قيمة registered_delivery إلى 1 إلى طلب تأكيد من SMSC للنتيجة النهائية. يصل هذا التأكيد لاحقًا كوحدة بيانات بروتوكول (PDU) منفصلة باسم deliver_sm تحمل رمز esm_class 0x04 - وهو إيصال التسليم - والذي يشير إلى معرف الرسالة (message_id) الذي تم تزويدك به في submit_sm_resp. بدون هذا المعرف، لن تعلم سوى أن SMSC قد قبل الرسالة، وليس أن الهاتف قد استلمها.
- لماذا تنقسم رسالتي إلى عدة أجزاء؟
- تحتوي وحدة بيانات بروتوكول الرسائل القصيرة (SMS PDU) على 160 حرفًا في أبجدية GSM-7 أو 70 حرفًا في UCS-2. يتم دمج النصوص الأطول: حيث يُخصص كل جزء 6 بايتات لرأس بيانات المستخدم ليتمكن الهاتف من إعادة تجميعها، مما ينتج عنه 153 أو 67 حرفًا لكل مقطع. يؤدي إدخال حرف عربي واحد أو رمز تعبيري واحد إلى تحويل الرسالة بأكملها إلى UCS-2، ولهذا السبب تتطلب رسالة عربية مكونة من 100 حرف مقطعين.
- ما الفرق بين submit_sm_resp وإيصال التسليم؟
- تُعدّ submit_sm_resp متزامنة، وتعني فقط أن SMSC قد قبل PDU وخصص لها معرّف رسالة (message_id). يصل إيصال التسليم بشكل غير متزامن، غالبًا بعد ثوانٍ أو دقائق، ويُبلغ عن النتيجة الفعلية: تم التسليم، لم يتم التسليم، انتهت صلاحيتها، مرفوضة. يُعدّ اعتبار submit_sm_resp دليلاً على التسليم الخطأ الأكثر شيوعًا عند دمج بروتوكول SMPP لأول مرة.
- ما هي نافذة SMPP ولماذا تحد من معدل نقل الرسائل الخاص بي؟
- تُحدد نافذة البيانات عدد PDU التي قد تكون أرسلتها ولم تتلقَّ ردًا عليها في عملية ربط واحدة في أي لحظة. ولأن SMPP غير متزامن، فأنت لا تنتظر كل submit_sm_resp قبل إرسال الاستجابة التالية، ولكن نافذة البيانات تحدد مدى تقدمك في العملية. إذا تركتها على القيمة الافتراضية 1، فإن عملية الربط تتحول إلى طلب/استجابة، وينخفض معدل نقل الرسائل إلى رسالة واحدة لكل دورة ذهاب وإياب، بغض النظر عن المعدل الذي وافق عليه المشغّل.