بعد إعادة اتصال WebSocket عبر وسيط، استعد الجلسة أيضاً

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

حتى نقطة النهاية نفسها عبر الوسيط قد تُنتج اتصالاً خارجياً جديداً. وتغيّر عنوان IP الخارج قد يُطلق سياسة الجلسة الخاصة بالوجهة. تعامل مع المقبس الجديد كاتصال جديد واتبع تبادل التعافي الموثّق في التطبيق. قرّر ما إذا كان سير العمل ينبغي أن يحتفظ بمساره عبر الوسيط عند إعادة الاتصال.

احتفظ بأكثر قليلاً من عنوان URL الأخير

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

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

الإرسال مرتين قد يعني التنفيذ مرتين

رسالة وُضعت في الطابور محلياً قبل انقطاع قد لا تكون غادرت العميل قط. وأخرى ربما وصلت إلى الخادم بينما ضاع إقرارها. وإعادة إرسال كل أمر غير مؤكَّد بشكل أعمى تعامل هاتين الحالتين كأنهما متماثلتان.

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

أبقِ محاولات إعادة الاتصال محدودة وموزّعة الإيقاع وفق سياسة التطبيق. وتوصي RFC 6455 بالتراجع التدريجي بعد الإغلاق غير الطبيعي؛ فحشد من العملاء يعيد المحاولة فوراً قد يزيد الحمل أثناء الانقطاع.

سجّل المسار الذي اختاره كل محاولة عبر الوسيط، لكن أبقِ تعافي المسار منفصلاً عن تعافي التطبيق. «اتصلنا من جديد» دليل مفيد. أما «لحقنا بالركب ونحن جاهزون لإرسال المزيد من العمل» فيحتاج إلى التبادل التطبيقي الإضافي الذي يثبته.