चीनी कैमकोर्डर और टीसीपी: बग या फीचर?

हमारे MKD के प्रबंधकीय घर की स्थिति के usurpation, और "कंघी" सार्वजनिक विकार की आवश्यकता के संबंध में, हम धीरे-धीरे एक वीडियो निगरानी प्रणाली का निर्माण कर रहे हैं।
बेशक, वित्तपोषण न्यूनतम है, योजनाएं भव्य हैं, इसलिए सब कुछ चारागाह से एकत्र किया जाता है।
विवरण थोड़ा बाद में, लेकिन यहाँ एक दिलचस्प बग है जिसने मुझे बहुत सी चीजों के माध्यम से जाना है।

तो, यह सब एक छोटे से शुरू हुआ - एक साधारण गुंबद वाला कैमरा, सबसे घटिया एक " केवल इस्तेमाल किए गए आईपी और गुंबद " के सिद्धांत पर लिया गया था। उसके बाद, सॉफ्टवेयर खोज प्रक्रिया शुरू हुई (एक अलग पोस्ट का विषय, फिर से, बाद में होगा) ... अंत में, यह एक चैनल में मैक्रोस्कोप पर तय किया गया था। यह कुछ महीने था, मैंने खाना या पीने के लिए नहीं पूछा, इससे नशेड़ी लोगों को गाड़ी चलाने में मदद मिली।

और अब सब कुछ काम करने लगता है, लेकिन किसी तरह यह समय-समय पर दुर्घटनाग्रस्त हो जाता है। सब कुछ के लिए पाप किया: प्रतिशत, नेटवर्क, सॉफ्टवेयर, मंगल पर मौसम ... लॉग द्वारा समर्थन कहते हैं कि कैमरा समय-समय पर बंद हो जाता है।

upd

हां, अधिक कैमरे खरीदे गए, बहुत अधिक गुणवत्ता और कीमत। अलग-अलग हफ्तों में तीन खूबसूरत दिनों में आलस्य पर काबू पाने के बाद, यह सब 1 मंजिल पर लगाया गया, एक कंप्यूटर में लाया गया, जुड़ा हुआ था। और सॉफ्टवेयर एन्यूमरेशन का दूसरा पुनरावृत्ति चला गया, ताकि कैमरे बड़े, अधिक मानवीय हों, इंटरफ़ेस अधिक सुविधाजनक हो ... एन्यूमरेशन के दूसरे दौर के बाद, जबकि AxxonNext खड़ा है। हां, केवल लैग एक नए स्तर पर पहुंच गए हैं: यदि आप टीसीपी सक्षम करते हैं तो कैमरे हर 5-10 मिनट में लगभग समान रूप से गिर जाते हैं; और यदि आप यूडीपी रखते हैं, तो कलाकृतियों पर चढ़ जाता है क्योंकि मुझे नहीं पता कि क्या है।

मैंने बाल्टी में इस विषय के बारे में शिकायत की, और मैक्सप्लाशिन ले और कहा कि यह चीनी कैमरों का एक स्थिर बग है, जहां फर्मवेयर अपने स्वयं के प्रयासों से बनाया गया था: यदि ग्राहक को रेक करने का समय नहीं है, तो कचरा धारा में मिल जाता है। चूंकि यह अलसी पर बेचा गया था, इसलिए समस्या को पूरी तरह से हल करने का प्रयास करने का निर्णय लिया गया। मैंने कई बार अलग-अलग शब्दों के साथ बग का वर्णन करने की कोशिश की, लेकिन मुझे एहसास हुआ कि अंग्रेजी हम दोनों वांछित होने के लिए बहुत कुछ छोड़ देती है, इसलिए आपको बस "शो कोड" की आवश्यकता है।

खुदाई का पहला चरण: कारण का पता लगाएं

तो, पहले हम tcpdump लेते हैं, और चट्टान की स्थिति की प्रतीक्षा करते हैं। थोड़े समय प्रतीक्षा करें, 5 मिनट में मैंने 3 टुकड़े के रूप में पकड़ा। कैसे समझें कि क्या हुआ? डेढ़ मिलियन पैकेट की एक धारा ... के साथ शुरू करने के लिए, हम फ़िल्टर करते हैं, केवल एक कैमरा छोड़कर। फिर Ctrl + F => tcp.flags.syn == 1 => हम पुन: कनेक्ट करने की शुरुआत पाते हैं, जहां से हम यह समझने के लिए स्क्रॉल करते हैं कि क्या हुआ ...



हम देखते हैं कि कनेक्शन कंप्यूटर के हिस्से पर बंद था ... यह केवल भ्रमित करता है कि इससे पहले, Win = 11460, Win = 10200, Win = 8940 - अर्थात, ऐसा लगता है कि क्लाइंट के पास वास्तव में समय नहीं है। स्टॉप स्टॉप स्टॉप। यह समय में कैसे नहीं है? एएमडी फेनोम II X6 1100T? नहीं, यह अजीब है। आईओ? इसलिए एक अलग डिस्क पर रिकॉर्डिंग, और शेल्फ के खिलाफ आराम नहीं किया। और फिर देखने पर निर्भरता होगी, उदाहरण के लिए - लेकिन यह मौजूद नहीं है ... सामान्य तौर पर, हम थोड़ा अधिक स्क्रॉल करते हैं:



तो सचमुच एक दूसरे से पहले, वे आम तौर पर ज़ीरोविंडो पर चले गए। संक्षेप में समय नहीं है। लेकिन एक चट्टान क्यों! नीचे स्क्रॉल करें, एक और चट्टान देखें ...



इसलिए, हम 2.5 सेकंड के लिए ZeroWindow का निरीक्षण करते हैं - यह बिल्कुल किसी भी द्वार पर नहीं चढ़ता है। नीचे स्क्रॉल करें और समझना शुरू करें:




हम देखते हैं - टीसीपी स्टैक ने बहुत खराब व्यवहार किया (कैमरे? शायद ...), जिसके बाद आरटीपी स्ट्रीम भटक गई - एक बिंदु पर, डायनेमिकआरटीपी-टाइप -96 के बजाय, आरटीएसपी कंटिन्यूएशन।

इसलिए, हम निष्कर्ष निकालते हैं: सिमुलेशन के लिए आवश्यक सभी एक आरटीपी स्ट्रीम का अनुरोध करना है, इसे थोड़ा बाहर खींचो, और फिर सो जाओ (), और देखें कि क्या धारा टूटती है।

फ्रेंकस्टीन के लिए पार्ट्स ढूँढना

जब आपको परीक्षण टुकड़ा जल्दी से फेंकने की आवश्यकता हो तो क्या करें? स्क्रिप्टिंग भाषा लें, तैयार पुस्तकालयों का एक सेट, इसे एक साथ ढालना, आनन्दित करना। हम गूगल में चढ़ते हैं। पायथन + ONVIF। सड़े। रूबी + ONVIF। ओह, माणिक-ऑनविफ़-क्लाइंट है । ठीक है, ले लो। स्ट्रीम URL पकड़ा गया। महान, लेकिन अगर आप ट्विस्ट करते हैं: प्रोटोकॉल? .. यूडीपी, एचटीटीपी, टीसीपी ... परिणाम एक है - ठीक है, मैंने सीखा कि कैसे ओवीएफ का उपयोग करके यूआरएल को पकड़ा जाए, अब मैं इसे विलय कर दूंगा।

कर्ल? चबाने वाला नहीं। ठीक है, रूबी + आरटीएसपी ... हुर्रे, एक लीबी है। उसे url, और bummer काटें। बेसिक के माध्यम से विशेष रूप से लॉग इन करने की कोशिश करता है। थोड़ा और गूगल। ओह। फिर एक विधि रहती है - एक फाइल। हम एक गर्म लोहे के साथ मिलाप करते हैं , जिस तरह से कटौती के जादू के संस्करणों पर कसम खाता है (जो मुझे बताएगा कि कैसे एक "ईमानदार" पुनरावृत्ति को सही ढंग से बनाने के लिए, ताकि वापसी और उपज सही ढंग से काम करे? आप फ़ंक्शन के विवरण से कैसे अनुमान लगा सकते हैं? यह आवश्यक हो सकता है? सही ढंग से ... यह छुटकारा पाना आसान है उसके - और एक क्लीनर कोड, और रेशमी बाल)।

और फिर से आनन्दित, rtsp_client काम करता है। दूसरी खिड़की में खुला tcpdump ... धिक्कार है! मैंने ONVIF में अनुरोध किया: प्रोटोकॉल => "टीसीपी"। क्या नरक, क्यों यूडीपी?

आपके हाथों में टांका लगाने वाला लोहा ... हा! यूडीपी को lib/rtsp/client.rb@request_transport पर nailed किया जाता है। तो, एक ही नाखून / टीसीपी के साथ वहां मिलाप करें। हम शुरू करते हैं - यह गिरता है। क्यों? कहाँ तक? हाँ, इसके लिए क्लाइंट_पोर्ट की आवश्यकता है ... टीसीपी है तो क्या क्लाइंट_पोर्ट? हार्डकोड rtp_port यदि यह 554 में नहीं है। तो, सर्वर के लिए आईपी आवश्यक है - हार्डकोड। ओपा, यह नहीं कह सकता है, 'बाइंड ()' के साथ यह 554 पोर्ट पर जाने के लिए रूट नहीं है। तार्किक है। तो, क्यों? खैर ... यह RTP :: रिसीवर में है ... हम init_socket को मोड में देखते हैं: TCP और आश्चर्य - उसे रिसीवर के लिए TCPServer की आवश्यकता क्यों है? कुछ ठीक नहीं है। जाहिर है, कोई भी स्पष्ट रूप से टीसीपी पर डिबगिंग नहीं कर रहा था।

तर्क को समझने की कोशिश करने के कुछ मिनटों के बाद, विजिलेंट आई ने महसूस किया कि कोई दीवार नहीं थी:

 परिवहन: आरटीपी / एवीपी / टीसीपी; यूनीकास्ट; गंतव्य = 172.28.1.199; स्रोत = 172.28.1.95; इंटरलेयर्ड = 0-1;

चलो ... क्या अंतर्द्वंद्व हुआ? Google: rtp interleaved => विकिपीडिया => पृष्ठ पर खोजें "interleaved" => हाँ! तो उसी संबंध में आरटीपी और आरटीएसपी की दीवार!

हम आरटीएसपी लिब को बाहर फेंक देते हैं, क्योंकि मेरे काम के लिए मैं वास्तव में संपादित करना या स्पष्ट रूप से नहीं करना चाहता हूं - यहां यह स्पष्ट रूप से एक अच्छे तरीके से वास्तुकला को फिर से करने के लिए आवश्यक है।

हम अमीबा उगाते हैं

तो, हम फिर से शून्य पर हैं: हमारे पास rsp है: // कैमरे का url, कनेक्शन के साथ नाली के दौरान इसे मर्ज करने और खेलने की आवश्यकता है ... बंद करो! सबसे पहले। Url है। एक कैमरा है। उस पर एक बग को पुन: पेश करने का कार्य है। मुझे ONVIF की आवश्यकता क्यों है? आरटीएसपी क्यों? आपको केवल अनुरोध करने और उत्तर डाउनलोड करने की आवश्यकता है।

जल्दी से नहीं कहा। वर्णन? और हमें इसकी आवश्यकता क्यों है ... हमें केवल पहले SETUP की आवश्यकता है, जहां सत्र प्राप्त करने के लिए: फिर उसके साथ खेलें।

पहले अनुभव से पता चला कि उन्हें यहां प्राधिकरण की भी आवश्यकता नहीं है।
बहुत बढ़िया! पहले पैनकेक ने तुरंत गोली मार दी: एक साधारण स्क्रिप्ट ने बग को पूरी तरह से पुन: पेश किया - नींद के बाद () और एक धमाके के साथ धारा टूट गई।

लेकिन TCP विंडो के साथ खेलने के लिए, आपको TCP_WINDOW_CLAMP सेट करने में सक्षम होना चाहिए। और इसके लिए आपको कनेक्ट करने के लिए setsockopt करना होगा लेकिन सॉकेट बनाने के बाद।
और इसे रूबल में कैसे करें? उम ... हम Google में देखते हैं ... यह खाली है। हम स्रोत में देखते हैं - init_inetsock_internal ... अंजीर! सबसे पहले, rsock_socket () बनाएँ, और फिर तुरंत rsock_connect ()। अरे।

ठीक है, मैं अभी भी कटिंग की तरह नहीं हूं। 2 मिनट में हम अजगर को फिर से लिखते हैं, सेटस्कॉक को जोड़ते हैं। RTP पैकेट नंबर का विश्लेषण जोड़ें।

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

मैं शांत हो गया होता, लेकिन मैक्सलाप्शिन ने पूछा कि क्या मैं किसी तरह इस बग के साथ रह सकता हूं। और इसके लिए अतिरिक्त खुदाई की आवश्यकता थी।

सिद्धांत रूप में, इसके साथ कैसे रहना है?

1) आप विफलता को ट्रैक कर सकते हैं और अपने आप को फिर से जोड़ सकते हैं
2) आप अपने स्वयं के अंतराल को ट्रैक कर सकते हैं (मैं नहीं जानता कि कैसे, लेकिन आप कर सकते हैं) और तुरंत शामिल हो जाएं, प्रवाह को तोड़ने के लिए इंतजार किए बिना।
3) आप स्ट्रीम के साथ सिंक्रनाइज़ेशन को पुनर्स्थापित करने का प्रयास कर सकते हैं।

तो, हम कॉल उठाने के बजाय चिपक जाते हैं - कॉल को फिर से कनेक्ट करें, और आरटीपी पैकेट की संख्या में अंतर से नुकसान का विश्लेषण करें। यदि हम बिंदु 1 पर कार्य करते हैं, तो नुकसान लगभग 1500-1800 आरटीपी पैकेट (लगभग 600 पैकेट प्रति सेकंड नींद) () है।

हम सोने के तुरंत बाद फिर से जुड़ जाते हैं ()। परिणाम ठीक वैसा ही है।

हम खोज विधि "$ \ x00" द्वारा पुन: सिंक्रनाइज़ेशन से चिपके रहते हैं - यह घृणित रूप से काम करता है। हम खोज विधि "$ \ x00 [LEN] {लेन बाइट्स} $ \ x00" का उपयोग करके पुनरुत्थान को छड़ी करते हैं - यह दृढ़ता से काम करता है, नुकसान फिर से जोड़ने के मुकाबले डेढ़ गुना कम है। लेकिन सबसे महत्वपूर्ण बात यह है कि टीसीपी कनेक्शन गिरता नहीं है, जिसका अर्थ है कि टीसीपी विंडो का अनुकूलन एल्गोरिथ्म और प्राप्त बफ़र्स काम करना जारी रखते हैं। परिणामस्वरूप, कनेक्शन की शुरुआत में 1-2 विफलताओं के बाद, धारा बस टूटना बंद कर देती है - नींद () नियमित रूप से ग्राहक को सुस्त करना जारी रखती है, और धारा नहीं गिरती है।

परिणामी परीक्षण स्क्रिप्ट कोड की गुणवत्ता के साथ चमकती नहीं है , लेकिन यह पूरी तरह से प्रूफ-ऑफ-कॉन्सेप्ट का कार्य करती है।

और अब, अंत में, हम शीर्षक में पूछे गए सवाल पर आए हैं।

यह एक बग, या एक विशेषता है?

कनेक्शन को पूरी तरह से तोड़ने से मेरी व्यक्तिगत राय वास्तव में बेहतर है: कनेक्शन में आरटीपी पैकेट के नंबर हैं, इसलिए आप बिना किसी समस्या के खोए हुए वॉल्यूम को माप सकते हैं।
यदि चैनल नेटवर्क बैंडविड्थ की तुलना में पतला है - तो घाटे में वृद्धि होगी, इस प्रकार, 5 सेकंड से अधिक के नुकसान का पता लगाते हुए - आप शांति से चैनल की मोटाई के बारे में शिकायत कर सकते हैं (कम गुणवत्ता के साथ फिर से कनेक्ट करें, केबल बदलने के लिए कहें, परमाणु ऊर्जा संयंत्र को उड़ा दें, या प्रतिक्रिया देने का कोई अन्य तरीका) यह समस्या); अगर समस्या यह है कि रिसीवर के पास किसी कारण से रेक-अप करने का समय नहीं है - रेसिंक व्यवहार = हमारी खुशी। हमें एक ही समय में यूडीपी और टीसीपी दृष्टिकोण के लाभों का एक संयोजन मिलता है: अगर कुछ पूरी तरह से खराब है, तो एक टुकड़ा खो जाता है; अन्य मामलों में, रिट्रांसमिशन स्वचालित हैं और समस्याएं पैदा नहीं करते हैं।

खैर, शुरुआत के लिए, चलो फ़र्मवेयर में किस प्रकार के बग के बारे में बात करते हैं ... लेकिन बग सरल है: (somedata, somelen) एक त्रुटि के मामले में <0, रिटर्न, बाइट्स की संख्या, अगर यह काम करता है। और सभी शुरुआती नेटवर्क डेवलपर्स की पसंदीदा गलती: भेजना (somedata, somelen) somelen की तुलना में कुछ कम वापस कर सकता है - यह बफर में फिट नहीं हुआ।

यदि इसे संसाधित नहीं किया जाता है, तो किसी दिन सोमाटा से पूंछ खो जाती है - इसे भेजा नहीं गया और फेंक दिया गया।

इसे कैसे ठीक करें?

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

मुझे आशा है कि निर्माताओं ने इस बग को ठीक किया है, और थोड़ी देर के बाद, चीनी कैमरों के लिए सभी चीनी फर्मवेयर एकल ब्रेक और टीएम के बिना सही काम के साथ कृपया करेंगे;

खुशी का स्रोत: LIVE555 जुरासिक

समर्थन मैक्रोस्कोप ने इस तथ्य पर मेरी मूर्खतापूर्ण असावधानी को आकर्षित किया कि 2011 में LIVE555 की घोषणा की गई थी ... इसलिए, बिनवॉक + डीडी + माउंट के माध्यम से, मैंने फर्मवेयर के हिम्मत में देखा। rtsp_streamer और सच्चाई, 2011 से।
मैंने live.2013.10.09.tar.gz और live.2014.02.19.19.tar_g2 के दो संस्करणों के बीच अंतर को देखा:

diff --git a/liveMedia/RTPInterface.cpp b/liveMedia/RTPInterface.cpp index d45e5a8..3d88d55 100644 --- a/liveMedia/RTPInterface.cpp +++ b/liveMedia/RTPInterface.cpp @@ -324,19 +325,23 @@ Boolean RTPInterface::sendRTPorRTCPPacketOverTCP(u_int8_t* packet, unsigned p } Boolean RTPInterface::sendDataOverTCP(int socketNum, u_int8_t const* data, unsigned dataSize, Bool - if (send(socketNum, (char const*)data, dataSize, 0/*flags*/) != (int)dataSize) { - // The TCP send() failed. - - if (forceSendToSucceed && envir().getErrno() == EAGAIN) { - // The OS's TCP send buffer has filled up (because the stream's bitrate has exceeded the cap + int sendResult = send(socketNum, (char const*)data, dataSize, 0/*flags*/); + if (sendResult < (int)dataSize) { + // The TCP send() failed - at least partially. + + unsigned numBytesSentSoFar = sendResult < 0 ? 0 : (unsigned)sendResult; + if (numBytesSentSoFar > 0 || (forceSendToSucceed && envir().getErrno() == EAGAIN)) { + // The OS's TCP send buffer has filled up (because the stream's bitrate has exceeded + // the capacity of the TCP connection!). // Force this data write to succeed, by blocking if necessary until it does: + unsigned numBytesRemainingToSend = dataSize - numBytesSentSoFar; #ifdef DEBUG_SEND - fprintf(stderr, "sendDataOverTCP: resending %d-byte send (blocking)\n", dataSize); fflush(st + fprintf(stderr, "sendDataOverTCP: resending %d-byte send (blocking)\n", numBytesRemainingToS #endif makeSocketBlocking(socketNum); - Boolean sendSuccess = send(socketNum, (char const*)data, dataSize, 0/*flags*/) == (int)dataS + sendResult = send(socketNum, (char const*)(&data[numBytesSentSoFar]), numBytesRemainingToSen makeSocketNonBlocking(socketNum); - return sendSuccess; + return sendResult == (int)numBytesRemainingToSend; } return False; } 

और यहाँ changelog.txt से एक क्लिपिंग है:
2013.12.04:
- Updated the "sendDataOverTCP()" function (in "RTPInterface.cpp") to allow for the possibility of
one of the "send()" calls partially succeeding - ie, writing some, but not all, of its data.
- Fixed a couple of minor bugs. (Thanks to "maksqwe1ukr.net".)

? . , LIVE555 .

, -- topsee; MontaVista. , .