प्रॉक्सीमधून WebSocket Ping विरुद्ध TCP Keepalive
अॅप्लिकेशन मार्ग प्रतिसाद देत आहे याचा पुरावा म्हणून जिवंत TCP सॉकेट समजण्याऐवजी WebSocket सहभागीसाठी जिवंतपणा तपासणी निवडा.
जिवंत TCP सॉकेट, प्रतिसाद देणारा WebSocket सहभागी आणि उपयुक्त अॅप्लिकेशन प्रगती या वेगवेगळ्या निरीक्षणे आहेत:
| पुरावा | ते काय स्थापित करते |
|---|---|
| TCP स्तरावरील जिवंतपणा | तपासलेला वाहतूक मार्ग त्या स्तरावर प्रतिसाद देतो |
| जुळणारा WebSocket Pong | सहभागीने त्या नियंत्रण फ्रेमला उत्तर दिले |
| अॅप्लिकेशन पुष्टी | अॅप्लिकेशनने स्वतःच्या प्रोटोकॉलनुसार ऑपरेशनची पुष्टी केली |
फॉरवर्ड प्रॉक्सी सामान्यतः क्लायंट आणि गंतव्य यांच्यासाठी वेगळे कनेक्शन ठेवतो. क्लायंटचा TCP सहभागी प्रॉक्सी असतो, तर स्थापित टनेलमधील Ping WebSocket टोकापर्यंत जातो.
जुळणारा Pong
प्रोटोकॉलनुसार प्रतिसाद देणाऱ्या Pong मध्ये Ping चा अॅप्लिकेशन डेटा असणे आवश्यक आहे. प्रलंबित तपासणी ओळखण्यासाठी ती जुळणी वापरा. न मागितलेला Pong परवानगीयोग्य आहे पण पुष्टी मागत नाही; प्रत्येक डेटा संदेशानंतर तो पाठवणे वेगळा पुरावा देतो.
लायब्ररीने समर्थित हार्टबीट यंत्रणेला प्राधान्य द्या. ब्राउझर JavaScript ला त्याऐवजीअॅप्लिकेशन हार्टबीट करारआवश्यक असतो. कामाचा भार आणि नेटवर्क धोरण यानुसार अंतराल आणि अयशस्वी मर्यादा निवडा. शेड्युलिंग थांबे किंवा ओव्हरलोडेड इव्हेंट लूप आक्रमक मर्यादा चुकवू शकतात, नेटवर्क अयशस्वी झाल्याचे सिद्ध न करता.
प्राप्तकर्ता चालू ठेवा
नियंत्रण फ्रेम्स मिळवण्यासाठी आणि प्रक्रिया करण्यासाठी क्लायंटला सतत I/O आवश्यक आहे. ती यंत्रणा अडवल्यास स्थानिक संसाधन-उपासमार बिघाडासारखी दिसू शकते.
Ping टनेल रहदारी निर्माण करतो, पण आपल्या निष्क्रिय धोरणाचे समाधान काय करते हे प्रत्येक मध्यस्थ ठरवतो. कोणताही हार्टबीट कनेक्शनच्या निरपेक्ष आयुष्यमर्यादेपासून संरक्षणाची हमी देत नाही.
सहभागीचे अॅप्लिकेशन अद्यतने तयार करणे थांबवत असतानाही तो Ping ला उत्तर देऊ शकतो, आणि शांत सदस्यता निरोगी असू शकते. दोन्ही महत्त्वाचे असताना शेवटचा वैध Pong आणि अर्थपूर्ण अॅप्लिकेशन इव्हेंट वेगळे ठेवा. अपयशी झाल्यास मार्ग, गेलेला वेळ आणि प्रलंबित तपासणी जतन करा, नंतर समर्थित जीवनचक्रातून बंद करा किंवा पुनर्प्राप्त करा.