मैं समझता हूं कि एक धारा बाइट्स के अनुक्रम का एक प्रतिनिधित्व है। प्रत्येक स्ट्रीम अपने दिए गए बैकिंग स्टोर को बाइट्स पढ़ने और लिखने के लिए साधन प्रदान करती है। लेकिन धारा की बात क्या है? बैकिंग स्टोर अपने आप से क्यों नहीं हमारे साथ बातचीत करता है?
जो भी कारण इस अवधारणा के लिए सिर्फ मेरे लिए क्लिक नहीं कर रहा है। मैंने लेखों का एक समूह पढ़ा है, लेकिन मुझे लगता है कि मुझे एक सादृश्य या कुछ और चाहिए।
जवाबों:
"स्ट्रीम" शब्द इसलिए चुना गया है क्योंकि यह (वास्तविक जीवन में) एक बहुत ही समान अर्थ है जो हम इसका उपयोग करते समय व्यक्त करना चाहते हैं।
चलो थोड़ी देर के लिए बैकिंग स्टोर के बारे में भूल जाते हैं, और एक जलधारा के लिए सादृश्य के बारे में सोचना शुरू करते हैं। आपको डेटा का एक सतत प्रवाह प्राप्त होता है, जैसे नदी में लगातार पानी बहता रहता है। आप जरूरी नहीं जानते कि डेटा कहां से आ रहा है, और सबसे अधिक बार आपको इसकी आवश्यकता नहीं है; यह एक फ़ाइल, एक सॉकेट, या किसी अन्य स्रोत से हो, यह वास्तव में मायने नहीं रखता (नहीं) होना चाहिए। यह पानी की एक धारा प्राप्त करने के समान है, जिससे आपको यह जानने की आवश्यकता नहीं है कि यह कहाँ से आ रहा है; यह एक झील, एक फव्वारा, या किसी अन्य स्रोत से हो, यह वास्तव में मायने नहीं रखता (नहीं) होना चाहिए।
उस ने कहा, एक बार जब आप यह सोचना शुरू कर देते हैं कि आप केवल उस डेटा को प्राप्त करने के बारे में परवाह करते हैं जिसकी आपको आवश्यकता है, भले ही वह कहां से आता है, तो अन्य लोगों ने जो सार की बात की है वह स्पष्ट हो जाती है। आप सोचने लगते हैं कि आप धाराएँ लपेट सकते हैं, और आपके तरीके अभी भी पूरी तरह से काम करेंगे। उदाहरण के लिए, आप ऐसा कर सकते हैं:
int ReadInt(StreamReader reader) { return Int32.Parse(reader.ReadLine()); }
// in another method:
Stream fileStream = new FileStream("My Data.dat");
Stream zipStream = new ZipDecompressorStream(fileStream);
Stream decryptedStream = new DecryptionStream(zipStream);
StreamReader reader = new StreamReader(decryptedStream);
int x = ReadInt(reader);जैसा कि आप देखते हैं, अपने प्रसंस्करण तर्क को बदलने के बिना अपने इनपुट स्रोत को बदलना बहुत आसान हो जाता है। उदाहरण के लिए, फ़ाइल के बजाय नेटवर्क सॉकेट से अपना डेटा पढ़ने के लिए:
Stream stream = new NetworkStream(mySocket);
StreamReader reader = new StreamReader(stream);
int x = ReadInt(reader);यह जितना आसान हो सकता है। और सौंदर्य जारी है, जब तक आप किसी भी तरह के इनपुट स्रोत का उपयोग कर सकते हैं, जब तक आप इसके लिए एक स्ट्रीम "रैपर" बना सकते हैं। आप भी ऐसा कर सकते हैं:
public class RandomNumbersStreamReader : StreamReader {
private Random random = new Random();
public String ReadLine() { return random.Next().ToString(); }
}
// and to call it:
int x = ReadInt(new RandomNumbersStreamReader());देख? जब तक आपकी विधि यह ध्यान नहीं रखती कि इनपुट स्रोत क्या है, आप अपने स्रोत को विभिन्न तरीकों से अनुकूलित कर सकते हैं। अमूर्तता आपको प्रसंस्करण तर्क से इनपुट को बहुत ही सुरुचिपूर्ण तरीके से समझने की अनुमति देती है।
ध्यान दें कि हमने जो स्ट्रीम खुद बनाई है, उसमें बैकिंग स्टोर नहीं है, लेकिन यह अभी भी हमारे उद्देश्यों को पूरी तरह से पूरा करता है।
इसलिए, संक्षेप में, एक धारा केवल इनपुट का एक स्रोत है, दूसरे स्रोत को दूर (सार) छिपा रही है। जब तक आप अमूर्तता को नहीं तोड़ते, आपका कोड बहुत लचीला हो जाएगा।
ReadIntका उपयोग करते हुए बहुत ऊपर परिभाषित किया गया है int.Parse, जो स्ट्रिंग से reader.ReadLine()लौटाता है और इसे प्राप्त करता है। बेशक आप एक समान ReadStringविधि बना सकते हैं । क्या यह पर्याप्त है?
Stream.Copyबहुत सारे एप्लिकेशन में जीवन इतना आसान हो जाता है।
मुद्दा यह है कि आपको यह जानना नहीं चाहिए कि बैकिंग स्टोर क्या है - यह इस पर एक अमूर्त है। वास्तव में, वहाँ भी नहीं हो सकता है एक समर्थन दुकान - यदि आप किसी नेटवर्क से पढ़ने जा सकता है, और डेटा कभी नहीं सब पर "संग्रहीत" है।
यदि आप वह कोड लिख सकते हैं जो काम करता है चाहे आप किसी फ़ाइल सिस्टम, मेमोरी, नेटवर्क या किसी अन्य चीज़ से बात कर रहे हों जो स्ट्रीम आइडिया का समर्थन करता है, तो आपका कोड बहुत अधिक लचीला है।
इसके अलावा, धाराओं को अक्सर एक साथ जंजीर किया जाता है - आपके पास एक धारा हो सकती है जो कि जो कुछ भी डाला जाता है उसे संपीड़ित करता है, संकुचित रूप को दूसरी धारा पर लिखता है, या जो डेटा को एन्क्रिप्ट करता है, आदि। दूसरे छोर पर रिवर्स होगा। चेन, डिक्रिप्टिंग, डिकम्प्रेसिंग या जो भी हो।
StreamReader- या बेहतर लेते हैं , TextReaderतो आपका कोड नहीं जानता है कि किस प्रकार की धारा डेटा प्रवाह को कम करती है। या इसके बजाय, यह BaseStreamसंपत्ति का उपयोग प्रकार का पता लगाने के लिए कर सकता है - लेकिन यह एक प्रकार हो सकता है जिसे आपके कोड ने पहले कभी नहीं देखा है। मुद्दा यह है कि आपको परवाह नहीं करनी चाहिए। और हां, आप लेखन कोड को पूरी तरह से समाप्त कर सकते हैं जो कभी-कभी नेटवर्क स्ट्रीम के लिए उपयोग किया जाएगा और कभी-कभी फ़ाइल स्ट्रीम के लिए उपयोग किया जा सकता है। एक प्रक्रिया के माध्यम से पाइपिंग डेटा धाराओं के लिए - अच्छी तरह से प्रक्रिया के अंदर ऐसा नहीं किया जाएगा ... यह स्ट्रीम प्रदाता होगा।
धारा का बिंदु आपके और बैकिंग स्टोर के बीच अमूर्तता की एक परत प्रदान करना है। इस प्रकार कोड का एक दिया हुआ ब्लॉक, जो एक स्ट्रीम का उपयोग करता है, को ध्यान रखने की आवश्यकता नहीं है यदि बैकिंग स्टोर एक डिस्क फ़ाइल, मेमोरी आदि है ...
इको चैम्बर में जोड़ने के लिए, धारा एक अमूर्त है ताकि आप अंतर्निहित स्टोर के बारे में परवाह न करें। यह सबसे अधिक समझ में आता है जब आप धाराओं के साथ और बिना परिदृश्य पर विचार करते हैं।
फाइलें अधिकांश भाग के लिए निर्बाध हैं क्योंकि धाराएं उन गैर-स्ट्रीम-आधारित विधियों से अधिक नहीं हैं जिनसे मैं परिचित हूं। चलो इंटरनेट फ़ाइलों के साथ शुरू करते हैं।
अगर मैं इंटरनेट से कोई फ़ाइल डाउनलोड करना चाहता हूं, तो मुझे एक टीसीपी सॉकेट खोलना होगा, एक कनेक्शन बनाना होगा, और बाइट्स प्राप्त करना होगा जब तक कि अधिक बाइट्स न हों। मुझे एक बफर का प्रबंधन करना है, अपेक्षित फ़ाइल का आकार पता है, और कनेक्शन को गिराए जाने का पता लगाने के लिए कोड लिखें और इसे उचित रूप से संभालें।
मान लीजिए कि मेरे पास TcpDataStream ऑब्जेक्ट के कुछ प्रकार हैं। मैं इसे उचित कनेक्शन जानकारी के साथ बनाता हूं, फिर स्ट्रीम से बाइट्स पढ़ता हूं जब तक यह नहीं कहता कि कोई और बाइट्स नहीं हैं। स्ट्रीम बफ़र प्रबंधन, एंड-ऑफ़-डेटा स्थितियों और कनेक्शन प्रबंधन को संभालती है।
इस तरह, धाराएँ I / O को आसान बनाती हैं। आप निश्चित रूप से एक TcpFileDownloader वर्ग लिख सकते हैं जो स्ट्रीम करता है, लेकिन फिर आपके पास एक ऐसा वर्ग है जो टीसीपी के लिए विशिष्ट है। अधिकांश स्ट्रीम इंटरफेस बस एक रीड () और राइट () विधि प्रदान करते हैं, और किसी भी अधिक जटिल अवधारणाओं को आंतरिक कार्यान्वयन द्वारा नियंत्रित किया जाता है। इस वजह से, आप मेमोरी, डिस्क फ़ाइलों, सॉकेट्स और कई अन्य डेटा स्टोरों को पढ़ने या लिखने के लिए एक ही मूल कोड का उपयोग कर सकते हैं।
मैं जिस विज़ुअलाइज़ेशन का उपयोग करता हूं वह कन्वेयर बेल्ट है, वास्तविक कारखानों में नहीं क्योंकि मुझे इसके बारे में कुछ भी पता नहीं है, लेकिन कार्टून कारखानों में जहां आइटम लाइनों के साथ चलते हैं और मुहर लगी और बॉक्सिंग और गिने जाते हैं और गूंगा उपकरणों के अनुक्रम द्वारा जांच की जाती है।
आपके पास सरल घटक हैं जो एक काम करते हैं, उदाहरण के लिए एक केक पर चेरी लगाने के लिए एक उपकरण। इस उपकरण में चेरी रहित केक का एक इनपुट स्ट्रीम और चेरी के साथ केक का आउटपुट स्ट्रीम है। इस तरह से आपके प्रसंस्करण को संरचित करने के लायक तीन फायदे हैं।
सबसे पहले यह स्वयं घटकों को सरल करता है: यदि आप एक केक पर चॉकलेट आइसिंग डालना चाहते हैं, तो आपको एक जटिल उपकरण की आवश्यकता नहीं है जो केक के बारे में सब कुछ जानता है, आप एक डंब डिवाइस बना सकते हैं जो उस में खिलाया गया चॉकलेट चॉकलेट पर चिपक जाता है (में) कार्टून, यह जहाँ तक पता नहीं है कि अगले आइटम केक में नहीं है, यह विले ई। कोयोट है)।
दूसरे आप डिवाइसेस को अलग-अलग क्रम में लगाकर अलग-अलग उत्पाद बना सकते हैं: हो सकता है कि आप चाहते हैं कि आपके केक चेरी के बजाय चेरी के शीर्ष पर आइसिंग करें, और आप बस लाइन पर उपकरणों को स्वैप करके ऐसा कर सकते हैं। ।
तीसरा, उपकरणों को इन्वेंट्री, बॉक्सिंग, या अनबॉक्सिंग को प्रबंधित करने की आवश्यकता नहीं है। चीजों को एकत्र करने और पैकेजिंग करने का सबसे कुशल तरीका परिवर्तनशील है: हो सकता है कि आज आप अपने केक को 48 के बक्से में डाल रहे हों और उन्हें ट्रक द्वारा बाहर भेज रहे हों, लेकिन कल आप कस्टम ऑर्डर के जवाब में छह के बॉक्स बाहर भेजना चाहते हैं। उत्पादन लाइन के प्रारंभ और अंत में मशीनों को बदलने या पुन: संयोजन करके इस तरह के परिवर्तन को समायोजित किया जा सकता है; लाइन के बीच में चेरी मशीन को एक बार में विभिन्न मदों को संसाधित करने के लिए बदलना नहीं पड़ता है, यह हमेशा एक समय में एक आइटम के साथ काम करता है और यह जानने की जरूरत नहीं है कि इसका इनपुट या आउटपुट कैसा है समूहबद्ध किया जा रहा है।
जब मैंने पहली बार स्ट्रीमिंग के बारे में सुना, तो यह वेबकैम के साथ लाइव स्ट्रीमिंग के संदर्भ में था । तो, एक होस्ट वीडियो सामग्री प्रसारित कर रहा है, और दूसरा होस्ट वीडियो सामग्री प्राप्त कर रहा है। तो क्या यह स्ट्रीमिंग है? खैर ... हाँ ... लेकिन एक लाइव स्ट्रीम एक ठोस अवधारणा है, और मुझे लगता है कि यह प्रश्न स्ट्रीमिंग की अमूर्त अवधारणा को संदर्भित करता है। Https://en.wikipedia.org/wiki/Live_streaming देखें
तो चलिए आगे बढ़ते हैं।
वीडियो एकमात्र संसाधन नहीं है जिसे स्ट्रीम किया जा सकता है। ऑडियो भी स्ट्रीम किया जा सकता है। इसलिए हम अब स्ट्रीमिंग मीडिया के बारे में बात कर रहे हैं। Https://en.wikipedia.org/wiki/Streaming_media देखें । ऑडियो को कई तरीकों से लक्ष्य से स्रोत तक पहुंचाया जा सकता है। तो चलिए कुछ डेटा डिलीवरी के तरीकों की एक दूसरे से तुलना करते हैं।
क्लासिक फ़ाइल डाउनलोड करने वाली क्लासिक फ़ाइल वास्तविक समय में नहीं होती है। फ़ाइल का उपयोग करने से पहले, आपको डाउनलोड पूरा होने तक इंतजार करना होगा।
प्रोग्रेसिव डाउनलोड प्रोग्रेसिव डाउनलोड चंक्स स्ट्रीम किए गए मीडिया फ़ाइल से अस्थायी बफर में डेटा डाउनलोड करते हैं। उस बफ़र में डेटा काम करने योग्य है: बफ़र में ऑडियो-वीडियो डेटा खेलने योग्य है। इसके कारण उपयोगकर्ता डाउनलोड करते समय स्ट्रीम की गई मीडिया फ़ाइल को देख / सुन सकते हैं। फास्ट-फ़ॉरवर्डिंग और रिवाइंडिंग संभव है, बफर के साथ संभोग। वैसे भी, प्रगतिशील डाउनलोड लाइव स्ट्रीमिंग नहीं है।
स्ट्रीमिंग वास्तविक समय, और विखंडू डेटा होता है। लाइव प्रसारण में स्ट्रीमिंग को लागू किया जाता है। प्रसारण सुनने वाले ग्राहक तेजी से अग्रेषण या रिवाइंड नहीं कर सकते। वीडियो स्ट्रीम में, प्लेबैक के बाद डेटा को छोड़ दिया जाता है।
एक स्ट्रीमिंग सर्वर अपने क्लाइंट के साथ 2-तरह का कनेक्शन रखता है, जबकि एक वेब सर्वर सर्वर प्रतिक्रिया के बाद कनेक्शन बंद कर देता है।
ऑडियो और वीडियो केवल एक चीज नहीं है जिसे स्ट्रीम किया जा सकता है। आइए PHP मैनुअल में धाराओं की अवधारणा पर एक नज़र डालें।
एक स्ट्रीम एक संसाधन ऑब्जेक्ट है जो स्ट्रीम करने योग्य व्यवहार प्रदर्शित करता है। यही है, इसे रैखिक शैली में पढ़ा या लिखा जा सकता है, और धारा के भीतर एक मनमाने स्थान पर fseek () करने में सक्षम हो सकता है। लिंक: https://www.php.net/manual/en/intro.stream.php
PHP में, एक संसाधन एक बाहरी स्रोत जैसे फ़ाइल, डेटाबेस कनेक्शन का एक संदर्भ है। तो दूसरे शब्दों में, एक धारा एक स्रोत है जिसे पढ़ा या लिखा जा सकता है। इसलिए, यदि आपने साथ काम किया है fopen(), तो आप पहले ही धाराओं के साथ काम कर चुके हैं।
पाठ-फ़ाइल का एक उदाहरण जो स्ट्रीमिंग के अधीन है:
// Let's say that cheese.txt is a file that contains this content:
// I like cheese, a lot! My favorite cheese brand is Leerdammer.
$fp = fopen('cheese.txt', 'r');
$str8 = fread($fp, 8); // read first 8 characters from stream.
fseek($fp, 21); // set position indicator from stream at the 21th position (0 = first position)
$str30 = fread($fp, 30); // read 30 characters from stream
echo $str8; // Output: I like c
echo $str30; // Output: My favorite cheese brand is Lजिप फाइलों को भी स्ट्रीम किया जा सकता है। उसके शीर्ष पर, स्ट्रीमिंग फ़ाइलों तक सीमित नहीं है। HTTP, FTP, SSH कनेक्शन और इनपुट / आउटपुट को भी स्ट्रीम किया जा सकता है।
स्ट्रीमिंग की अवधारणा के बारे में विकिपीडिया क्या कहता है?
कंप्यूटर विज्ञान में, एक धारा डेटा तत्वों का एक क्रम है जो समय के साथ उपलब्ध कराया जाता है। एक धारा को एक कन्वेयर बेल्ट पर आइटम के रूप में सोचा जा सकता है जिसे बड़े बैचों के बजाय एक बार में संसाधित किया जा सकता है।
देखें: https://en.wikipedia.org/wiki/Stream_%28computing%29 ।
इसके लिए विकिपीडिया लिंक: https://srfi.schemers.org/srfi-41/srfi-41.html और लेखकों को धाराओं के बारे में कहना है:
धाराएँ, जिन्हें कभी-कभी आलसी सूची भी कहा जाता है, एक अनुक्रमिक डेटा संरचना होती है जिसमें केवल मांग पर गणना की गई तत्व होते हैं। एक धारा या तो अशक्त है या उसके cdr में एक धारा के साथ एक जोड़ी है। चूंकि स्ट्रीम के तत्वों की गणना केवल तब की जाती है जब एक्सेस किया जाता है, धाराएं अनंत हो सकती हैं।
तो एक स्ट्रीम वास्तव में एक डेटा संरचना है।
मेरा निष्कर्ष: एक धारा एक स्रोत है जिसमें डेटा हो सकता है जिसे अनुक्रमिक तरीके से पढ़ा या लिखा जा सकता है। एक धारा वह सब कुछ नहीं पढ़ती है जो स्रोत में एक बार होता है, यह क्रमिक रूप से पढ़ता / लिखता है।
उपयोगी लिंक:
यह सिर्फ एक अवधारणा है, अमूर्तता का एक और स्तर जो आपके जीवन को आसान बनाता है। और उन सभी में सामान्य इंटरफ़ेस है जिसका अर्थ है कि आप उन्हें पाइप में तरीके से जोड़ सकते हैं। उदाहरण के लिए, बेस 64 पर एनकोड करें, फिर ज़िप करें और फिर डिस्क और सभी को एक लाइन में लिखें!
मैंने देखी गई धाराओं का सबसे अच्छा विवरण SICP का अध्याय 3 है । (इसका अर्थ निकालने के लिए आपको पहले 2 अध्यायों को पढ़ने की आवश्यकता हो सकती है, लेकिन फिर भी आपको करना चाहिए। :-)
वे बाइट्स के लिए स्टेरम्स का उपयोग बिल्कुल नहीं करते हैं, बल्कि पूर्णांक बनाते हैं। मुझे इससे जो बड़े बिंदु मिले, वे थे:
धाराओं को डेटा के एक सार स्रोत (बाइट्स, वर्ण, आदि) के रूप में सोचें। वे ठोस डेटा स्रोत से पढ़ने और लिखने के वास्तविक यांत्रिकी को अमूर्त करते हैं, यह एक नेटवर्क सॉकेट है, डिस्क पर फ़ाइल या वेब सर्वर से प्रतिक्रिया।
मुझे लगता है कि आपको यह विचार करने की आवश्यकता है कि बैकिंग स्टोर अक्सर केवल एक और अमूर्त है। एक मेमोरी स्ट्रीम समझना बहुत आसान है, लेकिन एक फ़ाइल मौलिक रूप से भिन्न होती है, जिसके आधार पर आप जिस फ़ाइल सिस्टम का उपयोग कर रहे हैं, उस पर कभी ध्यान न दें कि आप किस हार्ड ड्राइव का उपयोग कर रहे हैं। सभी स्ट्रीम वास्तव में एक बैकिंग स्टोर के शीर्ष पर नहीं बैठती हैं: नेटवर्क स्ट्रीम बहुत अधिक बस स्ट्रीम हैं।
एक धारा की बात यह है कि हम अपना ध्यान उस बात तक सीमित रखते हैं जो महत्वपूर्ण है। एक मानक अमूर्तता होने से, हम सामान्य ऑपरेशन कर सकते हैं। उदाहरण के लिए, यदि आप आज भी URL के लिए फ़ाइल या HTTP प्रतिक्रिया नहीं खोजते हैं, तो इसका मतलब यह नहीं है कि आप कल की इच्छा नहीं रखेंगे।
जब मेमोरी स्टोरेज की तुलना में छोटी थी तब स्ट्रीम की कल्पना की गई थी। बस एक सी फाइल पढ़ना एक महत्वपूर्ण भार हो सकता है। मेमोरी फुटप्रिंट को कम करना बेहद जरूरी था। इसलिए, एक अमूर्त जिसमें बहुत कम लोड किए जाने की आवश्यकता होती है, बहुत उपयोगी था। आज, नेटवर्क संचार करते समय यह समान रूप से उपयोगी है और, यह पता चला है, जब हम फाइलों से निपटते हैं तो शायद ही कभी यह प्रतिबंधक होता है। सामान्य फैशन में बफरिंग जैसी चीजों को पारदर्शी रूप से जोड़ने की क्षमता इसे और भी उपयोगी बनाती है।
एक धारा बाइट्स के अनुक्रम का एक सार है। विचार यह है कि आपको यह जानने की जरूरत नहीं है कि बाइट्स कहां से आते हैं, बस आप उन्हें मानकीकृत तरीके से पढ़ सकते हैं।
उदाहरण के लिए, यदि आप किसी स्ट्रीम के माध्यम से डेटा प्रोसेस करते हैं तो यह आपके कोड के लिए मायने नहीं रखता है यदि डेटा किसी फाइल, नेटवर्क कनेक्शन, स्ट्रिंग, डेटाबेस में ब्लॉब आदि आदि से आता है।
इस तथ्य के अलावा कि यह आपको बैकिंग स्टोर के कार्यान्वयन से संबंधित है, के अलावा कुछ भी गलत नहीं है।
एक धारा एक अमूर्तता है जो डेटा के साथ बातचीत के लिए तरीकों और गुणों का एक मानक सेट प्रदान करती है। वास्तविक भंडारण माध्यम से दूर होने से, आपका कोड बिना किसी निर्भरता के उस माध्यम पर या उस माध्यम के क्रियान्वयन पर भी निर्भर हो सकता है।
एक अच्छा सादृश्य एक बैग पर विचार करने के लिए हो सकता है। आपको इस बात से कोई फ़र्क नहीं पड़ता कि एक बैग किस चीज से बना है या क्या करता है जब आप अपना सामान उसमें डालते हैं, जब तक बैग बैग होने का काम करता है और आप अपना सामान वापस ले सकते हैं। स्टोरेज मीडिया के लिए एक धारा परिभाषित करता है कि बैग की विभिन्न स्थितियों के लिए बैग की अवधारणा क्या परिभाषित करती है (जैसे कचरा बैग, हैंडबैग, रूकसाक, आदि) - बातचीत के नियम।