वीडियो प्लेयर में पीयर-टू-पीयर नेटवर्क

कुछ उपयोगकर्ता पहले से ही पीयर-टू-पीयर नेटवर्क के उपयोग की अनुमति देने के लिए हमारे वीडियो प्लेयर की पेशकश में एक खिड़की देख सकते हैं। सहकर्मी से सहकर्मी तकनीक का उपयोग करने वाले वीडियो देखना अंतिम परीक्षण चरण के माध्यम से जाता है। एक नियम के रूप में साइट पर अपलोड किए गए सभी वीडियो में से, एक नियम के रूप में, 10-15% से अधिक नहीं देखा जाता है। इन वीडियो का एक और 15-20% लोकप्रिय माना जा सकता है। पी 2 पी पर स्विच करने से सर्वर पर लोड काफी कम हो जाता है, उपयोगकर्ताओं को पड़ोसी ग्राहकों से भी वीडियो स्ट्रीम प्राप्त करने का अवसर प्रदान करता है (निश्चित रूप से, उन्होंने पीयर-टू-पीयर नेटवर्क में अपनी भागीदारी की पुष्टि की है)।




विकास फ्लैश प्लेयर 10.1 द्वारा क्लाइंट साइड पर लागू किए गए आरटीएमएमएफ प्रोटोकॉल और सर्वर साइड पर एडोब सिरस का उपयोग करता है।

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

वीडियो प्लेयर केवल उस वीडियो को वितरित कर सकता है जिसे एक समय या किसी अन्य पर देखा जा रहा है - और केवल उसका वह भाग जो डाउनलोड किया गया है और अभी भी मेमोरी में है। उसी समय, बफर का आकार 64 एमबी से अधिक नहीं हो सकता है, इसलिए बहुत अधिक रैम न खाएं। सैद्धांतिक रूप से, पी 2 पी मोड को सक्षम करने के लिए, एक साथ वीडियो देखने वाले दो उपयोगकर्ता पर्याप्त हैं। हालाँकि, यह केवल उन वीडियो के लिए सलाह दी जाती है जो दर्जनों उपयोगकर्ताओं द्वारा एक साथ देखे जाते हैं (जैसा कि ऊपर उल्लेख किया गया है, VKontakte के लिए ऐसे वीडियो सक्रिय रूप से देखे गए लगभग 15 से 20% तक होते हैं)। वीडियो खेलने के मामले में जिसके लिए पी 2 पी का उपयोग दृश्यमान परिणाम नहीं लाएगा, खिलाड़ी मानक डाउनलोड पर स्विच करता है।

क्लाइंट पहचान के लिए, केवल Adobe Cirrus सर्वर द्वारा जारी की गई कुंजी का उपयोग किया जाता है, न तो आईपी पते और न ही उपयोगकर्ता यूआईडी को इसके साथ बहाल किया जा सकता है)।

तकनीकी विवरण

जैसा कि पहले ही ऊपर उल्लेख किया गया है, एक ही वीडियो (एक ही रिज़ॉल्यूशन में) देखने वाले उपयोगकर्ताओं के एक अलग समूह में एकजुट होने के लिए, वर्तमान में एडोब की सिरस सेवा का उपयोग किया जा रहा है, जिसे RTMFP प्रोटोकॉल का उपयोग करके इंटरैक्ट किया गया है। संबंधित नेटग्रुप वर्ग के लिए समर्थन केवल फ़्लैश प्लेयर संस्करण 10.1 में दिखाई दिया - इसलिए, दसवें संस्करण के खिलाड़ी वाले उपयोगकर्ताओं को पी 2 पी का उपयोग करने की पेशकश नहीं दिखाई देगी।

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

लोड किए गए विखंडू को आउटपुट करने के लिए, नेटस्ट्रीम क्लास के तथाकथित "डेटा जेनरेशन मोड" का उपयोग किया जाता है। दुर्भाग्य से, यह MP4 प्रारूप का समर्थन नहीं करता है, जो अब Vkontakte वीडियो को संग्रहीत करने के लिए उपयोग किया जाता है, इसलिए MP4 से FLV तक का कंटेनर अब चंक्स से एकत्रित वीडियो फ़ाइलों से मक्खी पर बदल जाता है।

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

उप-योगों

वर्तमान चरण में मुख्य परिणाम देरी में ध्यान देने योग्य कमी हैं:

1. जब बड़ी संख्या में उपयोगकर्ताओं द्वारा एक साथ डाउनलोड किए गए लोकप्रिय वीडियो चला रहे हों।
2. किसी भी वीडियो को मनमाने स्थान से चलाते समय।

इस स्तर पर व्यापक निष्कर्ष निकालना जल्दबाजी होगी। वर्तमान में एकत्र किए गए आंकड़े बताते हैं कि लगभग 7 से 10% डेटा सभी साथियों से डाउनलोड किया जाता है। प्रतिशत लगातार बढ़ रहा है।