לאחר חיבור מחדש של WebSocket דרך פרוקסי, שחזרו גם את ההפעלה

קריאת החיבור מחדש רצה והשקע החדש נפתח. זהו שחזור של שכבת התעבורה. זה לא בהכרח אומר שהמינויים שלכם, אישורי ההודעות או הפעלת היישום המשיכו מהמקום שבו החיבור הקודם עצר.

אפילו אותה נקודת קצה של פרוקסי יכולה ליצור חיבור יוצא חדש. כתובת IP יוצאת שהשתנתה יכולה גם להפעיל את מדיניות ההפעלה של היעד עצמו. התייחסו לשקע החדש כאל חיבור חדש ופעלו לפי חילופי השחזור המתועדים של היישום. החליטו אם תזרים העבודה צריך לשמור על נתיב הפרוקסי שלו בעת חיבור מחדש.

שמרו מעט יותר מאשר ה־URL האחרון

מצב שחזור שימושי יכול לכלול זהות הפעלה מורשית, מינויים רצויים, המזהה של האירוע האחרון שאושר ופעולות שעדיין ממתינות לאישור. השדות האלה שייכים לפרוטוקול היישום; WebSocket אינו מגדיר אסימון המשך אוניברסלי.

החליטו אם להמשיך מסמן, להשיג תמונת מצב חדשה או לקבל פער. אם מקור אירועים אינו מציע ממשק להשמחה חוזרת, חיבור מחדש מהיר יותר אינו יכול להוכיח שלא הוחמצו הודעות.

שליחה כפולה יכולה להיות ביצוע כפול

הודעה שהונחה בתור מקומית לפני ניתוק אולי מעולם לא עזבה את הלקוח. אחרת אולי הגיעה לשרת בזמן שהאישור שלה אבד. שליחה חוזרת עיוורת של כל פקודה לא מאושרת מתייחסת לשני המקרים האלה כאל זהים.

השתמשו במזהי הבקשה של השירות, בתמיכה באידמפוטנטיות או במנגנון התאמה היכן שהם זמינים. חיבור מחדש של שכבת התעבורה אינו יכול להפוך פעולה של היישום להפיכה או להסיר כפילויות שלה אוטומטית.

שמרו על ניסיונות חיבור מחדש מוגבלים ובקצב המתאים למדיניות היישום. RFC 6455 ממליץ על נסיגה לאחור לאחר סגירה לא תקינה; צי לקוחות שמנסים שוב מיד עלול להגדיל את העומס בזמן התקלה.

תעדו איזה נתיב פרוקסי בחר כל ניסיון, אך הפרידו בין שחזור הנתיב לבין שחזור היישום. "התחברנו מחדש" הוא ראיה שימושית. "הדבקנו את הפער ומוכנים לשלוח עוד עבודה" דורש את חילופי היישום הנוספים שמבססים זאת.