पुन्हा कनेक्ट होणारा कॉलबॅक चालतो आणि नवीन सॉकेट उघडते. ते वाहतूक पुनर्प्राप्ती आहे. याचा अर्थ असा नाही की तुमची सदस्यता, संदेश पोचपावत्या किंवा अनुप्रयोग सत्र मागील कनेक्शन जिथे थांबले तिथूनच पुढे चालू राहिले.

तीच प्रॉक्सी अंतबिंदू देखील नवीन बाहेर जाणारे कनेक्शन निर्माण करू शकते. बदललेला एक्झिट IP गंतव्यस्थानाचे स्वतःचे सत्र धोरण सक्रिय करू शकतो. नवीन सॉकेटला नवीन कनेक्शन माना आणि अनुप्रयोगाच्या दस्तऐवजीकृत पुनर्प्राप्ती देवाणघेवाणीचे पालन करा. पुन्हा कनेक्ट करताना वर्कफ्लोने त्याचा प्रॉक्सी मार्ग राखावा का ते ठरवा.

शेवटच्या URL पेक्षा थोडे अधिक ठेवा

उपयुक्त पुनर्प्राप्ती स्थितीत अधिकृत सत्र ओळख, इच्छित सदस्यता, शेवटच्या पुष्टी झालेल्या घटनेचा ओळखकर्ता आणि अजून पोचेच्या प्रतीक्षेत असलेल्या क्रिया असू शकतात. ती क्षेत्रे अनुप्रयोग प्रोटोकॉलची आहेत; WebSocket सार्वत्रिक पुन्हा सुरू करण्याचे टोकन परिभाषित करत नाही.

कर्सरपासून पुढे जायचे, नवीन स्नॅपशॉट घ्यायचा की अंतर स्वीकारायचे ते ठरवा. घटना स्रोत पुन्हा प्ले इंटरफेस देत नसेल, तर वेगाने पुन्हा कनेक्ट केल्याने कोणतेही संदेश गमावले नाहीत हे सिद्ध होऊ शकत नाही.

दोनदा पाठवणे म्हणजे दोनदा करणे असू शकते

डिस्कनेक्टपूर्वी स्थानिकपणे रांगेत ठेवलेला संदेश कदाचित क्लायंटमधून कधीच गेला नसेल. दुसरा कदाचित सर्व्हरपर्यंत पोहोचला असेल आणि त्याची पोच हरवली असेल. प्रत्येक अपुष्ट आदेश आंधळेपणाने पुन्हा पाठवणे या दोन्ही प्रकरणांना एकसारखे मानते.

उपलब्ध असेल तिथे सेवेचे विनंती ओळखकर्ते, आयडेम्पोटेन्सी समर्थन किंवा सलोखा यंत्रणा वापरा. वाहतुकीचे पुन्हा कनेक्शन अनुप्रयोगाची क्रिया उलटण्यायोग्य करू शकत नाही किंवा तिची प्रत आपोआप काढू शकत नाही.

पुन्हा कनेक्ट होण्याचे प्रयत्न मर्यादित ठेवा आणि गती अनुप्रयोगाच्या धोरणानुसार ठेवा. RFC 6455 असामान्य बंदानंतर मागे हटण्याची शिफारस करते; तात्काळ पुन्हा प्रयत्न करणाऱ्या क्लायंटचा समूह बिघाडाचा भार वाढवू शकतो.

प्रत्येक प्रयत्नाने कोणता प्रॉक्सी मार्ग निवडला ते नोंदवा, पण मार्ग पुनर्प्राप्ती अनुप्रयोग पुनर्प्राप्तीपासून वेगळी ठेवा. “पुन्हा जोडले गेले” हा उपयुक्त पुरावा आहे. “आधी पकडले आणि अधिक काम सादर करण्यास तयार” यासाठी ते सिद्ध करणारी अतिरिक्त अनुप्रयोग देवाणघेवाण आवश्यक आहे.

संबंधित लेख