प्रॉक्सी किए गए WebSocket के पुनः कनेक्ट होने के बाद सत्र भी बहाल करें

पुनः कनेक्ट कॉलबैक चलता है और नया सॉकेट खुलता है। यह ट्रांसपोर्ट रिकवरी है। इसका अर्थ यह नहीं है कि आपकी सदस्यताएँ, संदेश पावतियाँ या एप्लिकेशन सत्र वहीं से जारी रहे जहाँ पिछला कनेक्शन रुका था।

यहाँ तक कि वही प्रॉक्सी एंडपॉइंट भी नया आउटगोइंग कनेक्शन बना सकता है। बदला हुआ एग्ज़िट IP गंतव्य की अपनी सत्र नीति भी सक्रिय कर सकता है। नए सॉकेट को नया कनेक्शन मानें और एप्लिकेशन के प्रलेखित रिकवरी विनिमय का पालन करें। तय करें कि पुनः कनेक्ट करते समय वर्कफ़्लो को अपना प्रॉक्सी मार्ग रखना चाहिए या नहीं।

अंतिम URL से थोड़ा अधिक रखें

उपयोगी रिकवरी स्थिति में अधिकृत सत्र पहचान, वांछित सदस्यताएँ, अंतिम पुष्ट घटना पहचानकर्ता और अभी पावती की प्रतीक्षा कर रहे ऑपरेशन शामिल हो सकते हैं। ये फ़ील्ड एप्लिकेशन प्रोटोकॉल के हैं; WebSocket कोई सार्वभौमिक रिज़्यूम टोकन परिभाषित नहीं करता।

तय करें कि कर्सर से फिर शुरू करना है, नया स्नैपशॉट लेना है, या अंतराल स्वीकार करना है। यदि कोई घटना स्रोत रीप्ले इंटरफ़ेस नहीं देता, तो तेज़ी से पुनः कनेक्ट करना यह सिद्ध नहीं कर सकता कि कोई संदेश छूटा नहीं।

दो बार भेजना दो बार करना हो सकता है

डिस्कनेक्ट से पहले स्थानीय रूप से कतार में रखा संदेश शायद क्लाइंट से कभी नहीं निकला। दूसरा शायद सर्वर तक पहुँच गया जबकि उसकी पावती खो गई। हर अपुष्ट कमांड को आँख मूँदकर दोबारा भेजना इन दोनों स्थितियों को एक जैसा मानता है।

जहाँ उपलब्ध हों वहाँ सेवा के अनुरोध पहचानकर्ता, इडेम्पोटेंसी समर्थन या सुलह तंत्र का उपयोग करें। ट्रांसपोर्ट का पुनः कनेक्शन किसी एप्लिकेशन क्रिया को उलटने योग्य नहीं बना सकता और न ही उसे स्वतः डुप्लिकेट-मुक्त कर सकता है।

पुनः कनेक्ट के प्रयास सीमित रखें और गति एप्लिकेशन की नीति के अनुसार रखें। RFC 6455 असामान्य बंद होने के बाद पीछे हटने की सलाह देता है; तुरंत फिर प्रयास करने वाले क्लाइंट का समूह रुकावट का भार बढ़ा सकता है।

दर्ज करें कि हर प्रयास ने कौन-सा प्रॉक्सी मार्ग चुना, पर मार्ग रिकवरी को एप्लिकेशन रिकवरी से अलग रखें। “फिर से जुड़ गए” उपयोगी साक्ष्य है। “बराबर आ गए और और काम जमा करने को तैयार” के लिए वह अतिरिक्त एप्लिकेशन विनिमय चाहिए जो इसे स्थापित करता है।