إعادة اتصال WebSocket: تصميم جلسة تستعيد حالتها دون رسائل مكررة

اتصال WebSocket قد ينقطع عند تبديل الشبكة أو نوم الجهاز أو إعادة تشغيل الخادم. إعادة فتح المقبس لا تعني أن التطبيق استعاد الحالة؛ فقد تكون رسائل ضاعت أثناء الانقطاع أو تكررت بعد العودة. يحتاج التصميم إلى بروتوكول استئناف واضح يحدد ما يمكن ضمانه.

افصل الاتصال عن حالة الجلسة

احتفظ بمعرف جلسة منطقي منفصل عن اتصال TCP الحالي، وحدد كيف يتحقق الخادم من هوية المستخدم عند العودة. لا تفترض أن اتصالًا جديدًا يملك الاشتراكات القديمة تلقائيًا. بعد المصادقة، أعد تسجيل القنوات المطلوبة واستعلم عن آخر حالة معروفة إذا كان ذلك ضروريًا.

استخدم مؤشرات تسلسل عند الحاجة

إذا كانت الرسائل تمثل أحداثًا لا يجوز تفويتها، امنحها معرفات أو أرقام تسلسل واحتفظ بها مدة مناسبة على الخادم. يرسل العميل آخر رقم استلمه، فيعيد الخادم ما يمكن استعادته. لا تعد بضمان التسليم إذا كان الخادم لا يحتفظ بسجل كافٍ أو انتهت فترة الاحتفاظ.

عالج التكرار قبل تحديث الواجهة

قد يستقبل العميل حدثًا سبق تطبيقه بعد إعادة الاتصال. اجعل معالجة الأحداث قابلة للتكرار الآمن عبر معرف حدث ثابت أو مقارنة رقم الإصدار. في محادثة مثلًا، لا تُضف الرسالة نفسها مرتين لمجرد أن الشبكة أعادت إرسالها؛ لكن لا تحذف رسائل متشابهة النص باعتبارها مكررة.

اضبط إعادة المحاولة والمهلات

استخدم تأخيرًا متزايدًا مع عشوائية لتجنب إعادة اتصال آلاف العملاء في اللحظة نفسها بعد عودة الخدمة. فرّق بين انقطاع عابر ورفض مصادقة يحتاج تدخل المستخدم. ضع حدودًا لعدد محاولات الاتصال المتزامنة، ووضح في الواجهة أن البيانات قد تكون مؤقتًا غير محدثة.

اختبر الاستئناف لا مجرد الاتصال

جرّب تبديل Wi-Fi إلى بيانات الهاتف، وإغلاق الجهاز ثم فتحه، وإعادة تشغيل الخادم، وتأخر وصول الرسائل. تحقق من عدد الرسائل النهائية وترتيبها حيث يكون الترتيب مطلوبًا، ومن أن الاشتراكات القديمة لا تتسرب بين الحسابات. معيار النجاح هو استعادة الحالة الصحيحة لا ظهور أيقونة «متصل» فقط.