مطٌ نراه باستمرار: شركةٌ ما تُسجّل طلبًا لـ 100 رسالة SMS في الثانية، وتُوجّه تطبيقها إلى نقطة الربط، ثم تقيس 12 رسالة. عرض النطاق الترددي جيد. بيانات SMSC جيدة. لم يتم تقييد أي شيء. حركة البيانات بطيئةٌ للغاية، والدافع الأول دائمًا هو إلقاء اللوم على المسار. لكن نادرًا ما يكون المسار هو السبب، بل النافذة.
بروتوكول SMPP هو بروتوكول غير متزامن، لكن معظم عمليات التكامل تُشغّله بشكل متزامن عن طريق الخطأ. فهم السبب هو الفرق بين دفع ثمن الإنتاجية والحصول عليها.
ما هي النافذة في الواقع
النافذة هي عدد وحدات بيانات البروتوكول (PDUs) التي ربما تكون قد أرسلتها ولم تتلقَّ ردًا عليها بعد، في عملية ربط واحدة، في أي لحظة. أرسل submit_sm وسيرد عليك SMSC بـ submit_sm_resp، لكن SMPP لا يتطلب منك أبدًا انتظار هذا الرد قبل إرسال الرسالة التالية. النافذة هي مدى تقدمك المسموح به.
مع نافذة زمنية قدرها 1، تُرسل، تنتظر، تستقبل، ثم تُرسل مرة أخرى. يصبح معدل نقل الرسائل لديك محدودًا بزمن الاستجابة ذهابًا وإيابًا، وليس بأي شيء اتفقت عليه تجاريًا. عند زمن استجابة 40 مللي ثانية، يُصبح لديك 25 رسالة في الثانية - بغض النظر عما ينص عليه عقدك. مع نافذة زمنية قدرها 10، يكون لديك عشر رسائل قيد الإرسال في وقت واحد، وينقل نفس الرابط ما يقارب عشرة أضعاف حجم البيانات عبر نفس الاتصال.
حجم النافذة هو العامل المحدد الأكبر للإنتاجية التي تحصل عليها من الربط، وهو الإعداد الذي غالبًا ما يُترك على الوضع الافتراضي للمكتبة والذي يحد من التكامل بشكل صامت إلى ما هو أقل بكثير من معدله المتفق عليه.
لماذا تستخدم العديد من المكتبات هذا الخيار افتراضيًا؟
نافذة بحجم 1 هي القيمة الافتراضية الآمنة لمطوري المكتبات. فهي لا تتطلب أي حالة ارتباط، ولا إدارة مهلة زمنية، ولا إعادة ترتيب: لكل طلب استجابة واحدة معلقة فقط، لذا يمكن لعميل بسيط التعامل مع SMPP كطلب/استجابة دون أن يلاحظ الفرق. إنها تعمل، ويسهل فهمها، ولكنها بطيئة. العديد من مكتبات عملاء SMPP تُشحن بهذه الطريقة، ولا تتم إعادة النظر في القيمة أبدًا لأنه لا يبدو أن هناك أي خلل - تصل الرسائل، ولكن ليس بسرعة.
أرقام التسلسل هي ما يجعل النافذة ممكنة
تحتوي كل وحدة بيانات بروتوكول SMPP على رقم sequence_number في رأسها المكون من 16 بايت. عند إرسال عدة طلبات في وقت واحد، يكون هذا الرقم هو الرابط الوحيد بين كل طلب submit_sm_resp وطلب submit_sm الذي تسبب فيه. لا يُضمن وصول الاستجابات بنفس ترتيب إرسال الطلبات، لذا يجب على العميل الذي يستخدم نافذة أكبر من 1 الاحتفاظ بخريطة لأرقام التسلسل المعلقة ومطابقتها عند الوصول.
هناك قاعدتان أساسيتان. أولاً، لا تعيد استخدام رقم تسلسلي أثناء تنفيذه، لأن أي تأخير في الاستجابة لرقم مُعاد استخدامه سيُعزى إلى رسالة خاطئة. ثانياً، احرص دائماً على تحديد مهلة زمنية للإدخالات: إذا لم تصل أي استجابة، يجب تحرير الخانة، وإلا ستتقلص نافذة الانتظار الفعالة إلى الصفر خلال مدة الجلسة، مما يُسبب مشكلة مزعجة تتمثل في تعطل النظام الذي يبدأ بسرعة ويتدهور تدريجياً على مدار ساعات.
يمكنك مشاهدة هذا يحدث حقلًا تلو الآخر في محاكي جلسة SMPP الخاص بنا - فهو يعرض sequence_number في رأس كل PDU، وأي استجابة تجيب على أي طلب.
حجم النافذة ومعدل المعاملات في الثانية (TPS) حدود مختلفة
تتداخل هذه المصطلحات باستمرار. يمثل TPS حدًا أقصى لمعدل الإرسال يفرضه المشغّل: عدد عمليات الإرسال في الثانية، مُقاسًا خلال فترة زمنية محددة. أما نافذة SMPP فهي حد للتزامن يمكنك ضبطه: عدد وحدات بيانات البروتوكول (PDUs) المعلقة في لحظة معينة. تتفاعل هذه المصطلحات، لكن عددها ليس متطابقًا.
العلاقة التقريبية هي: معدل المعاملات في الثانية (TPS) المُمكن تحقيقه ≈ حجم النافذة ÷ زمن الاستجابة. نافذة بحجم 10 مع زمن استجابة 50 مللي ثانية تُعطي حوالي 200 معاملة في الثانية. إذا حدد المشغّل الحد الأقصى لمعاملاتك بـ 100 معاملة، فستصل إلى هذا الحد وستتلقى رمز ESME_RTHROTTLED على المعاملات الزائدة. أما إذا سمح المشغّل بـ 500 معاملة وكانت نافذتك بحجم 10، فلن تصل إلى 500 معاملة مهما كان حجم البيانات التي تُقدمها - فأنت مُقيد بالتزامن، وليس بالمعدل.
| نافذة | رحلة ذهاب وعودة | سقف | الأعراض |
|---|---|---|---|
| 1 | 40 مللي ثانية | حوالي 25 رسالة في الثانية | لم يتم الوصول إلى السعر المتفق عليه مطلقًا؛ يبدو الرابط غير نشط |
| 10 | 40 مللي ثانية | حوالي 250 رسالة في الثانية | مفيد لمعظم مرسلي الشركات |
| 50 | 40 مللي ثانية | حوالي 1250 معاملة في الثانية | فقط في حال موافقة المشغّل؛ وإلا سيتم تقييد سرعة الإنترنت. |
| 10 | 250 مللي ثانية | حوالي 40 عملية في الثانية | مرتبط بالتأخير - ارفع النافذة أو اقترب |
قراءة ESME_RTHROTTLED بشكل صحيح
يشير الرمز ESME_RTHROTTLED (0x00000058) إلى تجاوزك معدل الإرسال المتفق عليه. هذا لا يعني رفض الرسالة ولا فشل التوجيه. الحل الصحيح هو التراجع وإعادة محاولة إرسال الرسالة، لأن التعامل معها كرسالة نهائية سيؤدي إلى إسقاط حركة رسائل كان المشغّل سيقبلها بعد لحظات.
كما أنها إشارة إلى أن حجم نافذة الاتصال لديك أصبح الآن أكبر من المعدل الذي تحدده. إذا أدى توسيع نافذة الاتصال إلى تقييد معدل نقل الرسائل بدلاً من زيادته، فإن القيد قد تحول من التزامن إلى العقد، وبالتالي يصبح النقاش التالي تجارياً بدلاً من تقني.
enquire_link: السبب الآخر الذي يربط الموت
يبدو الربط الذي لا يرسل أي بيانات مطابقًا تمامًا للربط الذي انقطع اتصال TCP الخاص به بصمت - إذ تقوم مهلة NAT وجدران الحماية ذات الحالة بفصل الجلسات الخاملة دون إبلاغ أي من الطرفين. يُثبت إرسال enquire_link كل 30 إلى 60 ثانية أن المقبس لا يزال قابلاً للاستخدام في كلا الاتجاهين. إذا لم يتم الإرسال خلال الفترة الزمنية التي يتوقعها المشغّل، فسيؤدي إرسال SMSC إلى قطع الاتصال، وعادةً ما يكون ذلك في أسوأ وقت ممكن.
أرسل enquire_link على نفس نقطة الربط التي أرسلت عليها، واستجب فورًا لرسالة enquire_link الخاصة بـ SMSC، واعتبر أي رد فائت بمثابة جلسة منتهية: أرسل unbind، ثم أعد الاتصال، واستأنف. العميل الذي يستمر في الإرسال إلى منفذ نصف مفتوح يُنتج الحالة الكلاسيكية حيث يبدو كل شيء سليمًا ولكن لا يتم تسليم أي شيء.
كيفية تحديد حجم النافذة عملياً
- قم بقياس زمن الاستجابة ذهابًا وإيابًا على الجهاز الذي تستخدمه فعليًا، وليس من جهاز الكمبيوتر المحمول. أرسل رسالة واحدة بنافذة زمنية قدرها 1، ووقتها من submit_sm إلى submit_sm_resp.
- قسّم معدل المعاملات المتعاقد عليه في الثانية على عدد الرسائل التي تسمح بها رحلة ذهاب وإياب واحدة في الثانية. هذا الناتج هو الحد الأدنى للوقت المتاح.
- أضف هامشًا - قم بالتقريب لأعلى، ثم أضف حوالي 50٪ - لأن وقت الرحلة ذهابًا وإيابًا ليس ثابتًا، والنافذة التي تم تحديد حجمها بدقة وفقًا للمتوسط ستؤدي أداءً أقل من المتوسط عند الوسيط.
- ارفعها تدريجيًا، وليس دفعة واحدة، وانتبه لرمز ESME_RTHROTTLED. أول تسارع مستمر يُخبرك أين تكمن حدود المشغّل الحقيقية.
- تأكد من القيمة باستخدام المعامل. بعض رموز SMSC تفرض حدًا أقصى للنافذة لكل عملية ربط، وستقوم بتخزين البيانات في قائمة الانتظار أو إسقاطها تلقائيًا إذا تجاوزت هذا الحد.
- بعد ذلك، وفقط بعد ذلك، فكّر في ربط ثانٍ. يؤدي الربط المتعدد إلى زيادة التزامن، ولكنه يزيد أيضًا من احتمالات فشل الجلسة.
عندما يتفوّق عدد أكبر من عمليات الربط (bind) على نافذة أكبر
هناك حد أقصى لما يمكن أن تحمله وصلة TCP واحدة. فبعد تجاوز بضع مئات من وحدات بيانات البروتوكول (PDUs) المعلقة، تصبح حالات الفشل مزعجة: إذ يؤدي عطل في منفذ واحد إلى فقدان كل تلك البيانات، ويصبح حجب رأس الطابور واضحًا، ويتطلب التعافي بعد انقطاع الاتصال إعادة تشغيل مجموعة كبيرة من البيانات قيد الإرسال. يفضل معظم المشغّلين وجود عدة حالات ربط متوسطة بدلاً من حالة ربط واحدة ضخمة، وسيخبرك معظمهم بالشكل الذي يفضلونه إذا سُئلوا.
يُفضّل تقسيم البيانات حسب فئة حركة الرسائل بدلاً من تقسيمها بشكل عشوائي. إنّ فصل رموز المرور لمرة واحدة ذات الأهمية الزمنية عن التسويق الجماعي يعني أن حملة التسويق المكثفة لا يمكنها تأخير رمز تسجيل الدخول، وهو قرار يتعلق بالإنتاجية، ولكنه في الواقع قرار متعلق بالمنتج.
قائمة مراجعة قبل إلقاء اللوم على الطريق
- ما هي النافذة المُهيأة، وهل قام أحد بضبطها عمداً؟
- هل يتم تحرير أرقام التسلسل المعلقة بعد انتهاء صلاحيتها؟
- هل يعمل برنامج enquire_link بالفترة الزمنية التي يتوقعها المشغّل؟
- هل تتم إعادة محاولة الاستجابات ESME_RTHROTTLED مع التراجع، أم يتم احتسابها كفشل؟
- هل وقت الرحلة ذهابًا وإيابًا المقاس هو ما افترضته عند تحديد حجم النافذة؟
- هل يتم تأكيد استلام الإيصالات (deliver_sm) على الفور؟ - يمكن أن يؤدي عدم تأكيد استلام الإيصالات إلى توقف الجلسة أيضًا.
الأسئلة الشائعة
ما هو حجم نافذة SMPP المناسب؟
لا يوجد رقم موحد، لأن القيمة المثلى تعتمد على زمن الاستجابة ذهابًا وإيابًا ومعدل المعاملات المتفق عليه. نقطة بداية عملية لحركة بيانات المؤسسات هي 10، ثم زيادتها تدريجيًا حتى تصل إلى معدل المعاملات المتفق عليه أو تبدأ برؤية ESME_RTHROTTLED. تحديد الحجم بضرب معدل المعاملات المتفق عليه في زمن الاستجابة ذهابًا وإيابًا، مع إضافة هامش أمان بنسبة 50% تقريبًا، يضمن نجاح معظم عمليات التكامل من المحاولة الأولى.
هل يؤدي تكبير حجم النافذة إلى زيادة معدل نقل الرسائل بلا حدود؟
لا. بمجرد أن تصبح نافذة البيانات كبيرة بما يكفي للوصول إلى الحد الأقصى لمعدل نقل الرسائل لدى المشغّل، فإن أي زيادة إضافية ستؤدي إلى ظهور رمز ESME_RTHROTTLED بدلاً من المزيد من الرسائل. تعمل نافذة البيانات على إزالة عنق الزجاجة في التزامن، ولا يمكنها رفع الحد الأقصى التجاري.
لماذا يتراجع معدل نقل الرسائل لدي على مدى ساعات بدلاً من أن يتراجع فوراً؟
هذه هي الأعراض الكلاسيكية لأرقام التسلسل المعلقة التي لا تنتهي مهلتها. كل استجابة مفقودة تستهلك خانة نافذة بشكل دائم، لذا تتقلص النافذة الفعلية بمرور الوقت حتى يصبح الربط كما لو كانت النافذة تساوي 1. تحرير الخانات عند انتهاء المهلة يحل المشكلة.
هل ESME_RTHROTTLED فشل دائم؟
لا، والتعامل مع الأمر على أنه فقدان للبيانات يعني أنك تجاوزت المعدل المتفق عليه في تلك اللحظة. خفّض السرعة، وأعد إرسال الرسالة نفسها، وإذا استمر التقييد، قلّل حجم النافذة أو أعد التفاوض على المعدل.
كم مرة يجب أن أرسل enquire_link؟
يتراوح معدل الإرسال عادةً بين 30 و60 ثانية، ويجب أن يتطابق الرقم الدقيق مع ما يتوقعه المشغّل. والهدف من ذلك هو التأكد من أن جلسة TCP، التي قد تكون خاملة، لا تزال نشطة في كلا الاتجاهين قبل أن يقوم جدار الحماية أو نظام ترجمة عناوين الشبكة (NAT) بحذفها تلقائيًا.
هل أستخدم ربطة كبيرة واحدة أم عدة ربطات أصغر؟
تُعدّ عدة عمليات ربط متوسطة الحجم أفضل عمومًا من عملية ربط واحدة كبيرة جدًا، لأنّ تعطل المنفذ في هذه الحالة يُكلّفك جزءًا صغيرًا من سعتك بدلًا من كاملها. قسّم البيانات حسب فئة حركة الرسائل - رموز المرور الحساسة للوقت بشكل منفصل عن البيانات العامة - حتى لا يؤدي تدفق التسويق المفاجئ إلى تأخير رمز تسجيل الدخول.
هل يؤثر وقت التسليم أيضاً على إيصالات التسليم؟
نعم، في الاتجاه المعاكس. يقوم SMSC بإرسال إيصالات deliver_sm إليك، وإذا كان تطبيقك بطيئًا في إرجاع deliver_sm_resp، فسيتراكم تدفق الإيصالات. عند ربط جهاز الإرسال والاستقبال، يمكن أن يؤثر هذا الازدحام على الجلسة بأكملها، لذا تأكد من تأكيد الإيصالات فورًا حتى لو كنت تعالجها بشكل غير متزامن.
أين يمكنني رؤية هذا السلوك دون الاتصال بخادم SMSC حقيقي؟
يقوم برنامجنا محاكي جلسة SMPP بتتبع جلسة SMPP 3.4 كاملة في المتصفح - الربط، الإرسال، إيصال التسليم غير المتزامن، enquire_link وunbind - ويعرض حقول كل وحدة بيانات بروتوكول (PDU) مُرتبطة بالبايتات الفعلية على السلك. لا يتم الاتصال ولا يتم إرسال أي بيانات.
النسخة المختصرة
إذا كان أداء عملية الربط ضعيفًا، فتحقق من نافذة الاتصال قبل التحقق من الشبكة. إن تسلسل SMPP غير متزامن بطبيعته، ومعظم عمليات التكامل تُشغّله بشكل متزامن عن طريق الخطأ. حدد حجم نافذة الاتصال بناءً على زمن الاستجابة ذهابًا وإيابًا ومعدل النقل المتعاقد عليه، وحدد مهلة زمنية لأرقام التسلسل، وحافظ على دقة تسلسل enquire_link، وأعد محاولة تسلسل ESME_RTHROTTLED مع مراعاة فترة التراجع. يحل هذا التسلسل غالبية شكاوى انخفاض الإنتاجية دون الحاجة إلى تعديل أي مسار.