پس از اتصال مجدد WebSocket از طریق پروکسی، نشست را هم بازیابی کنید

تابع بازگشت اتصال مجدد اجرا می‌شود و سوکت جدید باز می‌شود. این بازیابی انتقال است. لزوماً به این معنا نیست که اشتراک‌ها، تأییدهای پیام یا نشست برنامهٔ شما از جایی که اتصال پیشین متوقف شد ادامه یافته است.

حتی همان نقطهٔ پایانی پروکسی می‌تواند اتصال خروجی تازه‌ای ایجاد کند. تغییر IP خروجی می‌تواند سیاست نشست خود مقصد را نیز فعال کند. سوکت جدید را اتصالی تازه بدانید و تبادل بازیابی مستندشدهٔ برنامه را دنبال کنید. تصمیم بگیرید که آیا گردش‌کار باید مسیر پروکسی خود را در هنگام اتصال مجدد حفظ کند.

کمی بیشتر از آخرین URL نگه دارید

وضعیت بازیابی سودمند می‌تواند شامل هویت مجاز نشست، اشتراک‌های مطلوب، شناسهٔ آخرین رویداد تأییدشده و عملیاتی باشد که هنوز در انتظار تأییدند. این فیلدها متعلق به پروتکل برنامه‌اند؛ WebSocket هیچ توکن ادامهٔ جهانی تعریف نمی‌کند.

تصمیم بگیرید که از یک نشانگر ادامه دهید، تصویر لحظه‌ای تازه بگیرید یا شکاف را بپذیرید. اگر منبع رویداد رابط پخش مجدد ارائه نکند، اتصال مجدد سریع‌تر نمی‌تواند ثابت کند هیچ پیامی از دست نرفته است.

دو بار فرستادن می‌تواند دو بار انجام دادن باشد

پیامی که پیش از قطع اتصال به‌صورت محلی در صف قرار گرفته ممکن است هرگز از کلاینت خارج نشده باشد. دیگری ممکن است به سرور رسیده باشد در حالی که تأیید آن گم شده است. فرستادن کورکورانهٔ دوبارهٔ هر فرمان تأییدنشده این دو حالت را یکسان می‌گیرد.

در صورت وجود، از شناسه‌های درخواست سرویس، پشتیبانی idempotency یا سازوکار تطبیق استفاده کنید. اتصال مجدد انتقال نمی‌تواند یک کنش برنامه را برگشت‌پذیر کند یا به‌طور خودکار آن را تکراری‌زدایی کند.

تلاش‌های اتصال مجدد را محدود و آهنگ آن را مطابق سیاست برنامه نگه دارید. RFC 6455 پس از بسته‌شدن غیرعادی عقب‌نشینی را توصیه می‌کند؛ انبوهی از کلاینت‌ها که فوراً دوباره تلاش می‌کنند می‌تواند بار قطعی را بیشتر کند.

ثبت کنید هر تلاش کدام مسیر پروکسی را انتخاب کرد، اما بازیابی مسیر را از بازیابی برنامه جدا نگه دارید. «دوباره متصل شدیم» شاهد سودمندی است. «جبران کردیم و آمادهٔ ارسال کار بیشتریم» به تبادل افزودهٔ برنامه نیاز دارد که آن را اثبات کند.