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

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

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

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

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

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

आम डिस्कनेक्शन त्रुटियों में ये शामिल हैं:

	"errors": [{
		"title": "operational-disconnect",
		"disconnect_type": "UpstreamOperationalDisconnect",
		"detail": "This stream has been disconnected upstream for operational reasons.",
		"type": "https://api.x.com/2/problems/operational-disconnect"
	}]
}

{
	"title": "ConnectionException",
	"detail": "This stream is currently at the maximum allowed connection limit.",
	"connection_issue": "TooManyConnections",
	"type": "https://api.x.com/2/problems/streaming-connection"
}

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

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

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

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

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

खोया हुआ डेटा पुनर्प्राप्त करना

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

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

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

• x-rate-limit-limit उन अनुरोधों की आवंटित संख्या दर्शाता है, जिन्हें आपका क्लाइंट 15-मिनट की विंडो के दौरान कर सकता है।

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

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

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

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

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

Backoff रणनीतियों का परीक्षण करें

किसी backoff implementation का परीक्षण करने का एक अच्छा तरीका है अमान्य authorization credentials का उपयोग करना और reconnect के प्रयासों की जांच करना। एक अच्छी implementation में 429 response नहीं आने चाहिए।

एकाधिक पुनःकनेक्शन के लिए अलर्ट जारी करें

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

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

यह जांचें कि आपकी client process DNS Time To Live (TTL) का पालन करती है। कुछ stacks process चलने की पूरी अवधि के लिए resolved address को cache कर लेते हैं और निर्धारित TTL के भीतर DNS परिवर्तनों को नहीं अपनाते। ऐसी आक्रामक caching के कारण, जब X IP addresses के बीच load शिफ्ट करता है, तो आपके client में सेवा बाधित हो सकती है।

User Agent

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