मुझे यूडीपी पर यथासंभव तेज़ और वास्तविक समय के रूप में वीडियो फ्रेम का अनुक्रम भेजना है और जब मुझे मूल बातें मिल रही हैं, तो मैं सभी प्रकार की कठिनाइयों में भाग रहा हूं। अपने लक्ष्यों में से कुछ:मैं यूडीपी पर रीयल-टाइम डेटा कैसे भेजूं?
डाटा सामान्य रूप से डायल अप (इसलिए टीसीपी के बजाय यूडीपी) पर भेज दिया जाएगा, लेकिन यह भी तेजी से ईथरनेट का समर्थन की जरूरत है।
कभी-कभी फ्रेम को छोड़ना ठीक है (इसलिए टीसीपी के बजाय यूडीपी)।
कम विलंबता की आवश्यकता है। दूरस्थ रिमोट फ्रेम वह होना चाहिए जिसे हाल ही में भेजा गया था (बफर में प्रतीक्षा करने वाले कुछ फ्रेम से अधिक नहीं)।
मुझे प्रभावी बैंडविड्थ का पता लगाने में सक्षम होना चाहिए ताकि मैं फ्रेम दर को बनाए रखने के लिए फ्रेम को कम या कम कर सकूं।
मैं टुकड़े के सबसे को लागू करने में कामयाब रहे:
मैं के बारे में 500 बाइट्स की एक या अधिक डाटाग्राम में फ्रेम डेटा को विभाजित करें और प्रत्येक एक क्रम संख्या और अन्य जानकारी है। रिसीवर पूरे फ्रेम को फिर से इकट्ठा करता है और पता लगाता है कि क्या कोई डेटाग्राम गायब है।
यदि रिसीवर गिराए गए फ्रेम के एक निश्चित प्रतिशत से अधिक का पता लगाता है (उदाहरण के लिए पिछले 10 फ्रेमों में 50%), तो मैं प्रेषक को 50% तक धीमा करने के लिए एक टीसीपी संदेश भेजता हूं। प्रत्येक बाद के फ्रेम में 5% की गति धीरे-धीरे बढ़ जाती है।
डेटा भेजने और प्राप्त करने के लिए System.Net.Sockets.UdpClient का उपयोग करना।
मेरे पास एक अलग टीसीपी चैनल है जो प्रेषक को वापस नियंत्रण संदेशों के लिए उपयोग किया जाता है।
मेरा मुख्य कठिनाई अभी प्रभावी बैंडविड्थ पता लगा रहा है और विलंबता के साथ काम कर, विशेष रूप से अधिक डायल अप (अधिकतम ~ 4000 बाइट्स/सेकंड)। उदाहरण के लिए, यदि मैं TcpClient.Send() का उपयोग करके 100,000 बाइट्स/सेकेंड भेजने की कोशिश करता हूं, तो वे सभी पहुंचने लगते हैं (कोई गिरावट डेटाग्राम नहीं) लेकिन आखिरी डेटाग्राम आने तक बड़ी विलंबता के साथ। मुझे लगता है कि TcpClient.Send() फ़ंक्शन तब तक अवरुद्ध हो रहा है जब तक बफर भेजने में सक्षम न हो जो मेरे वर्तमान एल्गोरिदम को गड़बड़ कर देता है।
UDP पर वास्तविक बैंडविड्थ का पता लगाने:
किसी को भी कैसे करने के लिए जानकारी के किसी भी सूत्रों के मुझे बात कर सकते हैं।
उपलब्ध पाइप के अनुरूप गतिशील रूप से समायोजित बैंडविड्थ के लिए एक बेहतर एल्गोरिदम।
वांछित बैंडविड्थ पर आसानी से डेटा भेजें।
विलंबता को कम से कम नीचे रखने और रखने का एक तरीका।
मैं पिछले सप्ताह में अपने पहियों को कताई कर रहा हूं और हर बार जब मैं एक समस्या हल करता हूं तो ऐसा लगता है कि एक और पीछे की ओर सिर है।
मुझे यकीन है कि विलंबता का पता लगाने के लिए किसी प्रकार का डेटाग्राम समय की आवश्यकता होगी। उदाहरण के लिए, मुझे शायद टाइमस्टैम्प संलग्न करने की आवश्यकता है, रिसीवर को भेजें, रिसीवर फिर इसे वापस भेजता है (शायद टीसीपी नियंत्रण चैनल का उपयोग कर)। किसी भी तरह की इतिहास कतार में मूल प्रेषण समय पाएं और अंतर/2 aprox है। विलंबता। ऐसा करने के लिए मुझे प्रकाशित एल्गोरिदम नहीं मिल रहे हैं इसलिए मैं कुशलता से कार्यान्वित कर सकता हूं। –
आपको पूर्ण विलंबता जानने की भी आवश्यकता नहीं है। चूंकि यह बैंडविड्थ है जिसके लिए आप हल करने की कोशिश कर रहे हैं, आप केवल इंटर-फ्रेम समय देख सकते हैं - अगर फ्रेम 40ms अलग भेजे गए थे, लेकिन आप उन्हें 90ms अलग में देख रहे हैं, तो प्रेषक को धीमा करने की आवश्यकता है। – caf
इसके साथ समस्या यह है कि, समय के साथ, जब फ्रेम भेजा जाता है तो छोटी देरी एक बड़ी अंतराल में जोड़ सकती है। मैं प्राप्त प्रत्येक पूर्ण फ्रेम के लिए एक एसीके भेजना समाप्त हो गया। प्रेषक पर मैं भेजा गया अंतिम 10 फ्रेम, जब उन्हें भेजा गया था, और जब उन्हें स्वीकार किया गया था, का ट्रैक रखें। यदि औसत समय बहुत अच्छा है, तो मुझे धीमा करना पता है। –