डिस्कनेक्शन को संभालना

​

डिस्कनेक्शन क्या है?

स्ट्रीमिंग APIs से कनेक्शन स्थापित करने का मतलब है बहुत लंबे समय तक चलने वाला HTTPS अनुरोध करना और रिस्पॉन्स को क्रमिक रूप से पार्स करना। powerstream endpoint से कनेक्ट करते समय, आपको एक HTTPS अनुरोध बनाना चाहिए और जहाँ तक व्यावहारिक हो, उससे प्राप्त स्ट्रीम का उपभोग करते रहना चाहिए। सर्वर-साइड त्रुटि, अत्यधिक क्लाइंट-साइड विलंब, नेटवर्क समस्याएँ, नियमित सर्वर रखरखाव, या डुप्लिकेट लॉगिन जैसी स्थितियों को छोड़कर, हमारे सर्वर कनेक्शन को अनिश्चित काल तक खुला रखेंगे। स्ट्रीमिंग endpoints के साथ काम करते समय, डिस्कनेक्शन होना संभावित है—और इसकी अपेक्षा भी की जानी चाहिए—इसलिए पुनःकनेक्शन लॉजिक पहले से बनाया होना चाहिए।

​

स्ट्रीमिंग कनेक्शन डिस्कनेक्ट क्यों हो सकता है

आपकी स्ट्रीम कई कारणों से डिस्कनेक्ट हो सकती है। विफलता का कारण समझने के लिए स्ट्रीम द्वारा लौटाए गए त्रुटि संदेश की जाँच करें। डिस्कनेक्शन के संभावित कारण इस प्रकार हैं:

• प्रमाणीकरण से जुड़ी त्रुटि (जैसे गलत टोकन या गलत प्रमाणीकरण विधि का उपयोग)।
• X की ओर किसी स्ट्रीमिंग सर्वर का रीस्टार्ट होना। यह आमतौर पर कोड डिप्लॉयमेंट से संबंधित होता है, इसलिए इसकी संभावना सामान्य मानी जानी चाहिए और सिस्टम को उसी के अनुसार डिज़ाइन किया जाना चाहिए।
• आपका क्लाइंट स्ट्रीम द्वारा भेजे जा रहे पोस्ट्स की मात्रा के साथ तालमेल नहीं बैठा पा रहा है या डेटा बहुत धीमी गति से पढ़ रहा है। हर स्ट्रीमिंग कनेक्शन के साथ क्लाइंट को भेजे जाने वाले संदेशों की एक कतार होती है। अगर समय के साथ यह कतार बहुत बड़ी हो जाती है, तो कनेक्शन बंद कर दिया जाएगा।
• आपके खाते ने पोस्ट्स का अपना दैनिक/मासिक कोटा पार कर लिया है।
• आपके पास बहुत अधिक सक्रिय अतिरिक्त कनेक्शन हैं।
• कोई क्लाइंट अचानक डेटा पढ़ना बंद कर देता है। अगर स्ट्रीम से पढ़े जा रहे पोस्ट्स की दर अचानक गिर जाती है, तो कनेक्शन बंद कर दिया जाएगा।
• सर्वर और क्लाइंट के बीच संभावित नेटवर्क संबंधी समस्याएँ
• सर्वर पक्ष की कोई अस्थायी समस्या, निर्धारित रखरखाव या अपडेट। (status page देखें)

​

डिस्कनेक्शन का अनुमान लगाना और फिर से कनेक्ट करना

जब पोस्ट्स को स्ट्रीम किया जा रहा हो, तो लक्ष्य यथासंभव लंबे समय तक कनेक्टेड रहना है, यह मानते हुए कि डिस्कनेक्शन हो सकते हैं। endpoint 20-सेकंड का keep alive heartbeat देता है (यह नई पंक्ति के कैरेक्टर जैसा दिखाई देगा)। यह पता लगाने के लिए इस सिग्नल का उपयोग करें कि आपका कनेक्शन टूट रहा है या नहीं।

1. आपके कोड को यह पता लगाना चाहिए कि नया कंटेंट और heartbeat आना कब बंद हो जाता है।
2. यदि ऐसा होता है, तो आपके कोड को पुनःकनेक्शन logic ट्रिगर करनी चाहिए। कुछ clients और languages आपको read timeout निर्दिष्ट करने की अनुमति देते हैं, जिसे आप 20 सेकंड पर सेट कर सकते हैं।
3. आपकी सेवा को इन डिस्कनेक्शनों का पता लगाना चाहिए और यथाशीघ्र फिर से कनेक्ट करना चाहिए।

एक बार स्थापित कनेक्शन टूट जाए, तो तुरंत फिर से कनेक्ट करने का प्रयास करें। यदि फिर से कनेक्ट करना विफल हो जाए, तो हुई त्रुटि के प्रकार के अनुसार अपने reconnect प्रयासों की गति कम करें:

• TCP/IP स्तर की network errors के लिए रैखिक रूप से back off करें। ये समस्याएँ आम तौर पर अस्थायी होती हैं और जल्दी ठीक हो जाती हैं। हर प्रयास के साथ reconnect के बीच विलंब 250ms बढ़ाएँ, अधिकतम 16 सेकंड तक।
• उन HTTP errors के लिए, जिनमें फिर से कनेक्ट करना उपयुक्त हो, घातीय रूप से back off करें। 5 सेकंड की प्रतीक्षा से शुरू करें, हर प्रयास के साथ इसे दोगुना करें, अधिकतम 320 सेकंड तक।
• HTTP 429 errors Rate limit exceeded के लिए घातीय रूप से back off करें। 1 मिनट की प्रतीक्षा से शुरू करें और हर प्रयास के साथ इसे दोगुना करें। ध्यान दें कि हर HTTP 429 मिलने पर वह समय बढ़ जाता है, जितना आपको तब तक प्रतीक्षा करनी होगी जब तक आपके खाते पर rate limiting लागू रहना बंद नहीं हो जाता।  

​

खोए हुए डेटा की पुनर्प्राप्ति

यदि आपका कनेक्शन टूट जाता है, तो कुछ अलग-अलग रणनीतियाँ हैं जिनका उपयोग करके आप यह सुनिश्चित कर सकते हैं कि आपसे छूटा हुआ सारा डेटा आपको मिल जाए। छूटा हुआ डेटा पुनर्प्राप्त करने के लिए उठाए जाने वाले कुछ मुख्य चरणों को हमने अपनी इंटीग्रेशन गाइड डेटा पुनर्प्राप्ति में प्रलेखित किया है।   

​

रेट लिमिट्स और उपयोग

कनेक्शन लिमिट्स की जांच करने के लिए रिस्पॉन्स में तीन हेडर लौटाए जाते हैं। इससे यह समझने में मदद मिलती है कि आप rule endpoint का कितनी बार उपयोग कर सकते हैं, और streaming endpoint के लिए कितने पुनःकनेक्शन attempts की अनुमति है।

• x-rate-limit-limit उन आवंटित requests की संख्या बताता है, जिन्हें आपका client 15 मिनट की विंडो के दौरान कर सकता है।

• x-rate-limit-remaining 15 मिनट की विंडो में अब तक किए गए requests की संख्या बताता है।

• x-rate-limit-reset एक UNIX timestamp है, जो यह बताता है कि 15 मिनट की विंडो कब फिर से शुरू होगी, और x-rate-limit-remaining को 0 पर reset कर देगी।

filter stream endpoint फ़िलहाल usage data रिपोर्ट नहीं करता। कितने पोस्ट्स डिलीवर हुए हैं, यह जांचने के लिए आपका code metering logic लागू कर सकता है, ताकि consumption को मापा जा सके और ज़रूरत पड़ने पर रोका जा सके। 

आपका code, जो stream के client side को host करता है, आने वाले पोस्ट्स को बस एक first in, first out (FIFO) queue या इसी तरह की memory structure में डालता है; content को parse करके storage के लिए तैयार करने हेतु एक अलग process/thread को उस queue से पोस्ट्स consume करने चाहिए। इस design के साथ, अगर आने वाले पोस्ट्स की मात्रा में बड़ा बदलाव हो, तो आप ऐसी service लागू कर सकते हैं जो कुशलता से scale कर सके। वैचारिक रूप से, आप इसे HTTP पर एक अनंत लंबी file डाउनलोड करने जैसा समझ सकते हैं।

​

पुनःकनेक्शन के सर्वोत्तम तरीके

​

बैकऑफ़ रणनीतियों का परीक्षण करें

बैकऑफ़ कार्यान्वयन का परीक्षण करने का एक अच्छा तरीका अमान्य ऑथराइज़ेशन क्रेडेंशियल्स का उपयोग करना और फिर से कनेक्ट करने के प्रयासों की जांच करना है। एक अच्छे कार्यान्वयन में 429 रिस्पॉन्स नहीं मिलने चाहिए।

​

कई बार फिर से कनेक्ट होने पर अलर्ट जारी करें

यदि कोई client फिर से कनेक्ट होने के बीच के समय की अपनी अधिकतम सीमा तक पहुँच जाता है, तो उसे आपको सूचनाएँ भेजनी चाहिए, ताकि आप अपने कनेक्शन को प्रभावित करने वाली समस्याओं की जाँच कर सकें।

​

DNS परिवर्तनों को संभालें

जाँचें कि आपकी क्लाइंट प्रक्रिया DNS Time To Live (TTL) का पालन करती है। कुछ स्टैक प्रक्रिया के पूरे समय तक रिज़ॉल्व किए गए पते को कैश में रखते हैं और निर्धारित TTL के भीतर होने वाले DNS परिवर्तनों को नहीं अपनाते। इस तरह की अत्यधिक आक्रामक कैशिंग से आपकी क्लाइंट सेवा में व्यवधान आ सकता है, क्योंकि X IP पतों के बीच लोड शिफ्ट करता है।

​

यूज़र एजेंट

सुनिश्चित करें कि आपके user-agent HTTP header में client का version शामिल हो। X की ओर की समस्याओं का निदान करने में यह बेहद महत्वपूर्ण होगा। अगर आपका environment user-agent फ़ील्ड सेट करने की अनुमति नहीं देता, तो x-user-agent header सेट करें।