2015-09-10 12 views
13

पिछले कुछ दिनों में मैंने d00m से नेटवर्क त्रुटि डीबग करने का प्रयास किया है। मैं विचारों/लीडों से बाहर निकलना शुरू कर रहा हूं और मेरी आशा यह है कि अन्य SO उपयोगकर्ताओं के पास मूल्यवान अनुभव है जो उपयोगी हो सकता है। मैं सभी प्रासंगिक जानकारी प्रदान करने में सक्षम होने की उम्मीद करता हूं, लेकिन मैं व्यक्तिगत रूप से सर्वर वातावरण के नियंत्रण में नहीं हूं।यादृच्छिक और सामयिक नेटवर्क त्रुटि (NSURLErrorDomain कोड = -1001 और NSURLErrorDomain कोड = -1005)

उपयोगकर्ताओं द्वारा शुरू की गई पूरी चीज हमारे ऐप में कुछ "नेटवर्क त्रुटियों" को देखते हुए शुरू हुई। इंटरनेट कनेक्टिविटी, आईओएस संस्करण या बैकएंड अपडेट से संबंधित किसी भी ध्यान देने योग्य पैटर्न के बिना त्रुटि यादृच्छिक रूप से होती है। दो त्रुटियों कि पर्दे के पीछे होता है इस प्रकार हैं:

Error Domain=NSURLErrorDomain Code=-1001 "The request timed out."

और अधिक बार:

Error Domain=kCFErrorDomainCFNetwork Code=-1005 "The network connection was lost.

कुछ दिनों के लिए यह डिबगिंग के बाद, मैं (इन त्रुटियों को पुन: पेश करने प्रबंधित किया है यादृच्छिक रूप से हो रहा है) लगभग फायरिंग द्वारा। प्रत्येक अनुरोध के बीच एक यादृच्छिक नींद टाइमर के साथ हमारे बैकएंड की ओर 10 यादृच्छिक (जीईटी और पोस्ट) अनुरोध (1-20 सेकेंड पर सेट)। हालांकि, यह केवल अवधि में होता है। पिछले कुछ दिनों में मैंने जो अनुभव किया है वह यह है कि जब "त्रुटि की अवधि" शुरू होती है, तो मुझे दो बार त्रुटियों में से एक मिलता है, प्रत्येक बार या दो बार मैं कोड चलाता हूं (जिसका अर्थ है 1/10 या 1/20 अनुरोधों की त्रुटि दर)। यह त्रुटि दर कुछ घंटों तक जारी है और फिर त्रुटि कुछ घंटों तक गायब हो जाती है और फिर यह सब खत्म हो जाती है।

स्थापना के बारे में कुछ त्वरित तथ्य:

  • डिवाइस और सिम्युलेटर
  • आईओएस 8.4 पर होता है और iOS 7.1 पर होता है - हालांकि वी 8.4 मुख्य एक मैं परीक्षण के लिए उपयोग है।।
  • हम अपने नेटवर्क अनुरोधों के लिए NSURLSession का उपयोग करते हैं। हमारे पास AFNetworking भी शामिल है (नवीनतम संस्करण में अपडेट किया गया है), लेकिन हम केवल एसएसएल पिनिंग के लिए सुरक्षा भाग का उपयोग करते हैं। एसएसएल पिनिंग पूरी तरह से बंद होने के साथ भी, त्रुटि अभी भी होती है।

कुछ निष्कर्ष मैं पिछले कुछ दिनों के दौरान नीचे लिखा है:

  • यह केवल हमारे उत्पादन वातावरण जो हमारे निर्धारण वातावरण के रूप में कुछ अलग विन्यास है पर हो रहा है। इससे मुझे लगता है कि यह keep-alive बग से संबंधित हो सकता है जैसा कि here और here पर चर्चा की गई है। हालांकि, हमारे ओप विभाग ने उत्पादन वातावरण के रूप में एक ही keep-alive शीर्षलेख भेजकर एक नया स्टेजिंग वातावरण स्थापित किया है, लेकिन इससे स्टेजिंग वातावरण पर त्रुटि उत्पन्न नहीं हुई है।
  • ऐप का हमारा एंड्रॉइड संस्करण अनुरोधों के एक ही सेटअप का उपयोग कर त्रुटि को पुन: उत्पन्न करने में असमर्थ था। इसके अलावा, हमें एंड्रॉइड ऐप में "नेटवर्क त्रुटियों" पर कोई ग्राहक समस्या नहीं मिली है।

मेरा आंत महसूस कहता है कि यह सर्वर पर्यावरण और आईओएस में HTTP कार्यान्वयन से संबंधित है। हालांकि मैं एक ठोस पैटर्न को ट्रैक करने में असमर्थ हूं जो कुछ भी साबित करता है। मैंने एक साधारण रेल स्क्रिप्ट का उपयोग करके एक ही सेटअप किया है, और जब अगली "त्रुटि अवधि" होती है, तो मैं आईओएस भूमि के बाहर इसे पुन: पेश करने और पुन: पेश करने के लिए तैयार रहूंगा। जब ऐसा होता है तो मैं प्रश्न अपडेट कर दूंगा।

मैं वाईफाई सेटिंग्स को रीसेट करने, सिम्युलेटर को बंद करने या इसी तरह के समाधान के समाधान के लिए समाधान की तलाश नहीं कर रहा हूं क्योंकि मुझे इसे उत्पादन वातावरण में व्यवहार्य समाधान के रूप में नहीं देखा जाता है।मैंने गिटहब मुद्दे में उल्लिखित रीट्री-लूप-फ़िक्स बनाने पर भी विचार किया है, लेकिन मैं इसे अंतिम उपाय के रूप में देखता हूं।

अगर आपको और जानकारी चाहिए तो कृपया मुझे बताएं।

+0

क्या आप वेबसॉकेट का उपयोग कर रहे हैं? – Ducky

+0

'NSURLSessionDataTask' –

+0

हाय स्टीफन के साथ कोई मूल' NSURLSession' नहीं, क्या आप इस समस्या को हल करते हैं? –

उत्तर

2

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

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

किसी भी तरह से, यह सुनिश्चित करने का एकमात्र तरीका यह है कि एक पैकेट ट्रेस लेने के लिए क्या हो रहा है। ऐसा करने के लिए, वायर्ड कनेक्शन के माध्यम से मैक को इंटरनेट से कनेक्ट करें, वाई-फाई पर नेटवर्क साझाकरण सक्षम करें, और आईओएस डिवाइस को उस वाई-फाई नेटवर्क से कनेक्ट करें। फिर वायरशर्क चलाएं और पुल इंटरफेस की निगरानी के लिए इसे बताएं। यहाँ निर्देश:

http://www.howtogeek.com/104278/how-to-use-wireshark-to-capture-filter-and-inspect-packets/

वहाँ से, आप वास्तव में देखने के लिए सक्षम होना चाहिए क्या भेजा जा रहा है और जब। यह शायद यह समझने की दिशा में एक लंबा रास्ता तय करेगा कि यह क्यों विफल रहा है।

+0

सलाह के लिए धन्यवाद - मैं निश्चित रूप से इस पर ध्यान रखूंगा और अगर यह रहस्य को सुलझाने में समाप्त होता है तो मैं आपको वापस ले जाऊंगा। –

संबंधित मुद्दे