यूयूकेपी: Difference between revisions
No edit summary |
No edit summary |
||
| Line 98: | Line 98: | ||
जी-प्रोटोकॉल एंडपॉइंट्स के बीच संभावित लंबी लेटेंसी से निपटने के लिए एक सरल [[ स्लाइडिंग खिड़की | स्लाइडिंग विंडो]] प्रणाली का उपयोग करता है। प्रोटोकॉल पैकेट को 64 से 4096 8-बिट बाइट्स और विंडो जिसमें 1 से 7 पैकेट सम्मिलित हैं, के आकार की अनुमति देता है। सिद्धांत रूप में, 4k पैकेट और 7 पैकेट विंडो (4096x7) का उपयोग करने वाली प्रणाली [[ZMODEM|ज़ेडमोडेम]] जैसे सर्वश्रेष्ठ फ़ाइल-ट्रांसफर प्रोटोकॉल से मेल खाने या बेहतर प्रदर्शन की पेशकश करेगी। व्यवहार में, कई कार्यान्वयन केवल 64x3 की एक सेटिंग का समर्थन करते हैं। नतीजतन, जी-प्रोटोकॉल की खराब प्रदर्शन के लिए एक अवांछनीय प्रतिष्ठा है। पैकेट और विंडो के आकार पर भ्रम की स्थिति जी-प्रोटोकॉल के कारण हुई, केवल इसमें अंतर था कि यह हमेशा 4096x3. टेलर यूयूसीपी ने जी का समर्थन नहीं किया, किन्तु किसी भी वैध अनुरोधित विंडो या पैकेट आकार का समर्थन किया, इसलिए जी प्रारंभ करने वाले रिमोट प्रणाली टेलर के जी के साथ ठीक काम करेंगे, जबकि दो टेलर प्रणाली तेजी से कनेक्शन पर बातचीत कर सकते थे।<ref name="faq" /> | जी-प्रोटोकॉल एंडपॉइंट्स के बीच संभावित लंबी लेटेंसी से निपटने के लिए एक सरल [[ स्लाइडिंग खिड़की | स्लाइडिंग विंडो]] प्रणाली का उपयोग करता है। प्रोटोकॉल पैकेट को 64 से 4096 8-बिट बाइट्स और विंडो जिसमें 1 से 7 पैकेट सम्मिलित हैं, के आकार की अनुमति देता है। सिद्धांत रूप में, 4k पैकेट और 7 पैकेट विंडो (4096x7) का उपयोग करने वाली प्रणाली [[ZMODEM|ज़ेडमोडेम]] जैसे सर्वश्रेष्ठ फ़ाइल-ट्रांसफर प्रोटोकॉल से मेल खाने या बेहतर प्रदर्शन की पेशकश करेगी। व्यवहार में, कई कार्यान्वयन केवल 64x3 की एक सेटिंग का समर्थन करते हैं। नतीजतन, जी-प्रोटोकॉल की खराब प्रदर्शन के लिए एक अवांछनीय प्रतिष्ठा है। पैकेट और विंडो के आकार पर भ्रम की स्थिति जी-प्रोटोकॉल के कारण हुई, केवल इसमें अंतर था कि यह हमेशा 4096x3. टेलर यूयूसीपी ने जी का समर्थन नहीं किया, किन्तु किसी भी वैध अनुरोधित विंडो या पैकेट आकार का समर्थन किया, इसलिए जी प्रारंभ करने वाले रिमोट प्रणाली टेलर के जी के साथ ठीक काम करेंगे, जबकि दो टेलर प्रणाली तेजी से कनेक्शन पर बातचीत कर सकते थे।<ref name="faq" /> | ||
[[ टेलीविजन | टेलीविजन]] मोडेम ने [[प्रोटोकॉल स्पूफिंग]] का इस्तेमाल रिमोट प्रणाली को भेजे जाने वाले एंड-ऑफ-पैकेट मार्करों को नोटिस करके और तुरंत एक संदेश भेजकर जी-प्रोटोकॉल ट्रांसफर के प्रदर्शन को बेहतर बनाने के लिए किया। {{code|ACK}} स्थानीय होस्ट पर वापस, यह दिखाते हुए कि रिमोट प्रणाली ने पहले ही पैकेट प्राप्त कर लिया है और इसे सही विधि से डिकोड कर दिया है। इसने सॉफ्टवेयर स्टैक को अगला पैकेट भेजने के लिए ट्रिगर किया, इतनी तेजी से कि स्थानांतरण लगभग निरंतर हो गया। [[माइक्रोकॉम नेटवर्किंग प्रोटोकॉल]] पर आधारित एक मालिकाना प्रोटोकॉल का उपयोग करके दो मोडेम के बीच डेटा त्रुटि-सुधार किया गया था, जो सामान्य रूप से जी-प्रोटोकॉल की तुलना में टेलीबिट के आधे-द्वैध कनेक्शनों पर चलता था।<ref name="faq" /> क्योंकि आम 64x3 स्थितियों में रिमोट प्रणाली एक निरंतर स्ट्रीम भेज रहा होगा {{code|ACK}}s जो लो-स्पीड रिटर्न चैनल को ओवरफ्लो कर देगा। मॉडेम की स्वाभाविक रूप से उच्च डेटा दरों के साथ संयुक्त, उन्होंने समग्र थ्रूपुट में काफी सुधार किया और सामान्यतः 2400 बिट/एस मॉडेम की गति के बारे में सात गुना प्रदर्शन किया।<ref>{{cite web |url=http://www.umich.edu/~archive/mac/misc/documentation/telecomminfo.txt |title=मोडेम के बारे में आपको क्या जानना चाहिए|first=Kenneth |last=Kirksey |date=25 December 1991 |quote=The actual throughput is around 14400 bps. |access-date=29 August 2020 |archive-date=24 October 2020 |archive-url=https://web.archive.org/web/20201024183419/http://www.umich.edu/~archive/mac/misc/documentation/telecomminfo.txt |url-status=live }}</ref> यूयूसीपी मेजबानों पर उनका व्यापक रूप से उपयोग किया गया क्योंकि वे कम लंबी दूरी के शुल्कों में | [[ टेलीविजन | टेलीविजन]] मोडेम ने [[प्रोटोकॉल स्पूफिंग]] का इस्तेमाल रिमोट प्रणाली को भेजे जाने वाले एंड-ऑफ-पैकेट मार्करों को नोटिस करके और तुरंत एक संदेश भेजकर जी-प्रोटोकॉल ट्रांसफर के प्रदर्शन को बेहतर बनाने के लिए किया। {{code|ACK}} स्थानीय होस्ट पर वापस, यह दिखाते हुए कि रिमोट प्रणाली ने पहले ही पैकेट प्राप्त कर लिया है और इसे सही विधि से डिकोड कर दिया है। इसने सॉफ्टवेयर स्टैक को अगला पैकेट भेजने के लिए ट्रिगर किया, इतनी तेजी से कि स्थानांतरण लगभग निरंतर हो गया। [[माइक्रोकॉम नेटवर्किंग प्रोटोकॉल]] पर आधारित एक मालिकाना प्रोटोकॉल का उपयोग करके दो मोडेम के बीच डेटा त्रुटि-सुधार किया गया था, जो सामान्य रूप से जी-प्रोटोकॉल की तुलना में टेलीबिट के आधे-द्वैध कनेक्शनों पर चलता था।<ref name="faq" /> क्योंकि आम 64x3 स्थितियों में रिमोट प्रणाली एक निरंतर स्ट्रीम भेज रहा होगा {{code|ACK}}s जो लो-स्पीड रिटर्न चैनल को ओवरफ्लो कर देगा। मॉडेम की स्वाभाविक रूप से उच्च डेटा दरों के साथ संयुक्त, उन्होंने समग्र थ्रूपुट में काफी सुधार किया और सामान्यतः 2400 बिट/एस मॉडेम की गति के बारे में सात गुना प्रदर्शन किया।<ref>{{cite web |url=http://www.umich.edu/~archive/mac/misc/documentation/telecomminfo.txt |title=मोडेम के बारे में आपको क्या जानना चाहिए|first=Kenneth |last=Kirksey |date=25 December 1991 |quote=The actual throughput is around 14400 bps. |access-date=29 August 2020 |archive-date=24 October 2020 |archive-url=https://web.archive.org/web/20201024183419/http://www.umich.edu/~archive/mac/misc/documentation/telecomminfo.txt |url-status=live }}</ref> यूयूसीपी मेजबानों पर उनका व्यापक रूप से उपयोग किया गया क्योंकि वे कम लंबी दूरी के शुल्कों में स्वयं के लिए जल्दी से भुगतान कर सकते थे। | ||
=== अन्य प्रोटोकॉल === | === अन्य प्रोटोकॉल === | ||
| Line 105: | Line 105: | ||
f-प्रोटोकॉल को 7-बिट त्रुटि-सुधारित लिंक चलाने के लिए डिज़ाइन किया गया है। यह मूल रूप से X.25 लिंक पर उपयोग के लिए अभिप्रेत था, जो 1980 के दशक में एक समय के लिए लोकप्रिय थे। यह डेटा को पैकेट नहीं करता है, इसके अतिरिक्त, पूरी फ़ाइल को एक लंबी स्ट्रिंग के रूप में भेजा जाता है, जिसके बाद एक संपूर्ण फ़ाइल चेकसम होता है। ऐसा प्रतीत होता है कि समान एक्स-प्रोटोकॉल का बहुत कम या कोई उपयोग नहीं हुआ है। डी-प्रोटोकॉल एक्स के समान था, किन्तु डेटाकिट नेटवर्क पर उपयोग के लिए अभिप्रेत था जो [[बेल लैब्स]] के कई कार्यालयों से जुड़ा था।<ref name=faq/> | f-प्रोटोकॉल को 7-बिट त्रुटि-सुधारित लिंक चलाने के लिए डिज़ाइन किया गया है। यह मूल रूप से X.25 लिंक पर उपयोग के लिए अभिप्रेत था, जो 1980 के दशक में एक समय के लिए लोकप्रिय थे। यह डेटा को पैकेट नहीं करता है, इसके अतिरिक्त, पूरी फ़ाइल को एक लंबी स्ट्रिंग के रूप में भेजा जाता है, जिसके बाद एक संपूर्ण फ़ाइल चेकसम होता है। ऐसा प्रतीत होता है कि समान एक्स-प्रोटोकॉल का बहुत कम या कोई उपयोग नहीं हुआ है। डी-प्रोटोकॉल एक्स के समान था, किन्तु डेटाकिट नेटवर्क पर उपयोग के लिए अभिप्रेत था जो [[बेल लैब्स]] के कई कार्यालयों से जुड़ा था।<ref name=faq/> | ||
टी-प्रोटोकॉल यूयूसीपी के बीएसडी संस्करणों में उत्पन्न हुआ है और इसे 8-बिट त्रुटि-मुक्त टीसीपी/आईपी लिंक चलाने के लिए डिज़ाइन किया गया है। इसमें कोई त्रुटि सुधार नहीं है, और प्रोटोकॉल में सामान्य टीसीपी फ्रेम के अन्दर आसानी से फिट होने के लिए 512 या 1024-बाइट पैकेट में कमांड और फाइल डेटा को तोड़ना सम्मिलित है। कम उपयोग किया जाने वाला ई-प्रोटोकॉल, जो बीएसडी से टी के विरोध में हनीडैनबेर संस्करणों को उत्पन्न करता है, केवल उस कमांड में भिन्न होता है जिसे पैकेट नहीं किया जाता है और इसके अतिरिक्त सामान्य स्ट्रिंग्स के रूप में भेजा जाता है, जबकि फाइलें निकटतम 20 बाइट्स तक | टी-प्रोटोकॉल यूयूसीपी के बीएसडी संस्करणों में उत्पन्न हुआ है और इसे 8-बिट त्रुटि-मुक्त टीसीपी/आईपी लिंक चलाने के लिए डिज़ाइन किया गया है। इसमें कोई त्रुटि सुधार नहीं है, और प्रोटोकॉल में सामान्य टीसीपी फ्रेम के अन्दर आसानी से फिट होने के लिए 512 या 1024-बाइट पैकेट में कमांड और फाइल डेटा को तोड़ना सम्मिलित है। कम उपयोग किया जाने वाला ई-प्रोटोकॉल, जो बीएसडी से टी के विरोध में हनीडैनबेर संस्करणों को उत्पन्न करता है, केवल उस कमांड में भिन्न होता है जिसे पैकेट नहीं किया जाता है और इसके अतिरिक्त सामान्य स्ट्रिंग्स के रूप में भेजा जाता है, जबकि फाइलें निकटतम 20 बाइट्स तक पैडेड होती हैं।<ref name=faq/> | ||
== मेल रूटिंग == | == मेल रूटिंग == | ||
[[File:UUCP Email Address .jpg|thumb | | [[File:UUCP Email Address .jpg|thumb | यूयूसीपी ईमेल पते वाला व्यवसाय कार्ड]] | ||
{{code|uucp | {{code|uucp}} और {{code|uuxqt}} क्षमताओं का उपयोग उपयुक्त मेल यूजर इंटरफेस और डिलीवरी एजेंट प्रोग्राम वाली मशीनों के बीच ईमेल भेजने के लिए किया जा सकता है। एक साधारण यूयूसीपी मेल पता आसन्न मशीन के नाम से एक [[विस्मयादिबोधक चिह्न]] (अधिकांश उच्चारित बैंग कहा जाता है) से बनाया गया था, जिसके बाद आसन्न मशीन पर उपयोगकर्ता का नाम होता था। उदाहरण के लिए, पता ''barbox!user'' आसन्न मशीन बारबॉक्स पर उपयोगकर्ता उपयोगकर्ता को संदर्भित करेगा। | ||
मेल को अपने गंतव्य पर पहुंचने से पहले किसी भी संख्या में मध्यवर्ती नोड्स को पार करते हुए, नेटवर्क के माध्यम से रूट किया जा सकता है। प्रारंभ में, यह पूर्ण पथ निर्दिष्ट करके किया जाना था, मध्यवर्ती मेजबान नामों की एक सूची के साथ बैंग्स द्वारा अलग किया गया। उदाहरण के लिए, यदि मशीन बारबॉक्स स्थानीय मशीन से जुड़ा नहीं है, किन्तु यह ज्ञात है कि बारबॉक्स मशीन फूवैक्स से जुड़ा है जो स्थानीय मशीन के साथ संचार करता है, तो मेल भेजने के लिए उपयुक्त पता | मेल को अपने गंतव्य पर पहुंचने से पहले किसी भी संख्या में मध्यवर्ती नोड्स को पार करते हुए, नेटवर्क के माध्यम से रूट किया जा सकता है। प्रारंभ में, यह पूर्ण पथ निर्दिष्ट करके किया जाना था, मध्यवर्ती मेजबान नामों की एक सूची के साथ बैंग्स द्वारा अलग किया गया। उदाहरण के लिए, यदि मशीन बारबॉक्स स्थानीय मशीन से जुड़ा नहीं है, किन्तु यह ज्ञात है कि बारबॉक्स मशीन फूवैक्स से जुड़ा है जो स्थानीय मशीन के साथ संचार करता है, तो मेल भेजने के लिए उपयुक्त पता ''foovax!barbox!user'' होगा। | ||
उपयोगकर्ता barbox!user सामान्यतः अपने | उपयोगकर्ता ''barbox!user'' सामान्यतः अपने यूयूसीपी ईमेल पते को ''…!bigsite!foovax!barbox!user'' जैसे रूप में प्रकाशित करेगा। यह लोगों को अपने मेल को मशीन बिगसाइट (संभवतः एक प्रसिद्ध और अच्छी तरह से जुड़ी हुई मशीन जो हर किसी के लिए सुलभ है) और वहां से मशीन फूवैक्स के माध्यम से बारबॉक्स पर उपयोगकर्ता उपयोगकर्ता के खाते में भेजने के लिए निर्देशित करता है। एक पूर्ण पथ प्रकाशित करना व्यर्थ होगा, क्योंकि प्रेषक कहां था, इस पर निर्भर करते हुए यह अलग होगा। (उदाहरण के लिए एक साइट पर ऐन को पाथ ''gway!tcol!canty!uoh!bigsite!foovax!barbox!user'' के माध्यम से भेजना पड़ सकता है, जबकि कहीं और से बिल को पथ ''pdp10!router22!bigsite!foovax!barbox!user के माध्यम से भेजना होगा'')। कई उपयोगकर्ता विभिन्न बड़ी प्रसिद्ध साइटों से कई मार्गों का सुझाव देंगे, जो मेल प्रेषक से बेहतर और संभवतः तेज़ कनेक्शन सेवा प्रदान करते हैं। | ||
=== बंग पथ === | === बंग पथ === | ||
इस प्रपत्र के एक ईमेल पते को बैंग पाथ के रूप में जाना जाता था। | इस प्रपत्र के एक ईमेल पते को बैंग पाथ के रूप में जाना जाता था। | ||
1981 में आठ से दस मशीनों (या ''हॉप्स'') के धमाके असामान्य नहीं थे, और देर रात डायल-अप यूयूसीपी लिंक सप्ताह भर के प्रसारण समय का कारण बन सकते थे। प्रसारण समय और विश्वसनीयता दोनों द्वारा बैंग पथों का चयन अधिकांश किया जाता था, क्योंकि संदेश अधिकांश खो जाते थे। कुछ मेजबान इतनी दूर चले गए कि पथ को फिर से लिखने, तेज मार्गों के माध्यम से मेल भेजने की कोशिश करने लगे- इस प्रथा पर ध्यान नहीं दिया गया। | |||
सूडो-डोमेन एंडिंग .uucp को कभी-कभी यूयूसीपी नेटवर्किंग द्वारा पहुंच योग्य होने के रूप में एक होस्टनाम को निर्दिष्ट करने के लिए उपयोग किया जाता था, चूंकि यह [[डोमेन की नामांकन प्रणाली]] (डीएनएस) में एक [[शीर्ष-स्तरीय डोमेन]] के रूप में औपचारिक रूप से पंजीकृत नहीं था। यूयूसीपी समुदाय ने स्वयं को प्रशासित किया और डीएनएस को नियंत्रित करने वाले प्रशासन के विधियों और विनियमों के साथ अच्छी तरह से मेल नहीं खाता था; .uucp वहां काम करता है जहां इसकी आवश्यकता होती है{{where|date=January 2017}}; यदि आने वाले SMTP कनेक्शन पर .uucp पता पहचाना जाता है, तो कुछ होस्ट{{which|date=January 2017}} मेल को एसएमटीपी कतार से गेटवे मशीनों पर यूयूसीपी कतारों में भेज देते हैं।{{citation needed|date=January 2017}} | |||
सामान्य तौर पर, अन्य गैर-इंटरनेट ईमेल पते|पुराने ई-मेल पता प्रारूपों की तरह, बैंग पथों को अब ईमेल पते#अवलोकन|@ नोटेशन द्वारा अधिक्रमित कर दिया गया है, यहां तक कि उन साइटों द्वारा भी जो अभी भी | यूज़नेट ट्रैफ़िक मूल रूप से बैंग पाथ का उपयोग करके यूयूसीपी प्रोटोकॉल पर प्रसारित किया गया था। ये अभी भी यूज़नेट संदेश प्रारूप पथ हेडर लाइनों के अन्दर उपयोग में हैं। उनके पास अब केवल एक सूचनात्मक उद्देश्य है, और रूटिंग के लिए उपयोग नहीं किया जाता है, चूंकि उनका उपयोग यह सुनिश्चित करने के लिए किया जा सकता है कि लूप नहीं होते हैं। | ||
सामान्य तौर पर, अन्य गैर-इंटरनेट ईमेल पते|पुराने ई-मेल पता प्रारूपों की तरह, बैंग पथों को अब ईमेल पते#अवलोकन|@ नोटेशन द्वारा अधिक्रमित कर दिया गया है, यहां तक कि उन साइटों द्वारा भी जो अभी भी यूयूसीपी का उपयोग कर रहे हैं। एक यूयूसीपी-ओनली साइट एक डीएनएस डोमेन नाम पंजीकृत कर सकती है, और उस डोमेन को संभालने वाला डीएनएस सर्वर [[एमएक्स रिकॉर्ड]] प्रदान करता है जो उस साइट पर इंटरनेट मेल को इंटरनेट पर यूयूसीपी होस्ट को वितरित करने का कारण बनता है जो यूयूसीपी साइट को मेल वितरित कर सकता है। | |||
== यूयूसीपीएनईटी और मैपिंग<!--'UUCPNET' redirects here-->== | == यूयूसीपीएनईटी और मैपिंग<!--'UUCPNET' redirects here-->== | ||
| Line 144: | Line 145: | ||
यूयूसीपी प्रोटोकॉल को अब ज्यादातर इंटरनेट टीसीपी/आईपी आधारित प्रोटोकॉल मेल के लिए [[ सरल डाक स्थानांतरण प्रोटोकॉल ]] और यूज़नेट न्यूज के लिए [[नेटवर्क न्यूज ट्रांसफर प्रोटोकॉल]] द्वारा बदल दिया गया है। | यूयूसीपी प्रोटोकॉल को अब ज्यादातर इंटरनेट टीसीपी/आईपी आधारित प्रोटोकॉल मेल के लिए [[ सरल डाक स्थानांतरण प्रोटोकॉल ]] और यूज़नेट न्यूज के लिए [[नेटवर्क न्यूज ट्रांसफर प्रोटोकॉल]] द्वारा बदल दिया गया है। | ||
जुलाई 2012 में, डच इंटरनेट प्रदाता [[XS4ALL]] ने अपनी UUCP सेवा को बंद कर दिया, यह दावा करते हुए कि यह शायद दुनिया के अंतिम प्रदाताओं में से एक था जिसने अभी भी इसकी पेशकश की थी; उस समय इसके केवल 13 उपयोगकर्ता थे ( | जुलाई 2012 में, डच इंटरनेट प्रदाता [[XS4ALL]] ने अपनी UUCP सेवा को बंद कर दिया, यह दावा करते हुए कि यह शायद दुनिया के अंतिम प्रदाताओं में से एक था जिसने अभी भी इसकी पेशकश की थी; उस समय इसके केवल 13 उपयोगकर्ता थे (चूंकि इसके बंद होने से पहले इसने कई वर्षों तक नए उपयोगकर्ताओं के अनुरोधों को अस्वीकार कर दिया था)।<ref>{{cite web |first=Niels |last=Huijbregts |date=30 July 2012 |url=https://blog.xs4all.nl/2012/07/30/afscheid-van-uucp |title=XS4ALL Weblog: Afscheid van UUCP (Goodbye to UUCP) |publisher=[[XS4ALL]] |language=nl |archive-url=https://web.archive.org/web/20130731202722/https://blog.xs4all.nl/2012/07/30/afscheid-van-uucp/ |archive-date=31 July 2013|url-status=live}}</ref> | ||
| Line 176: | Line 177: | ||
2000 के दशक के मध्य में, टीसीपी/आईपी पर यूयूसीपी (अधिकांश सुरक्षित शेल प्रोटोकॉल का उपयोग करके एन्क्रिप्ट किया गया)<ref name=UUCPssh/> प्रस्तावित किया गया था{{whom|date=December 2015}} उपयोग के लिए जब कंप्यूटर के पास कोई निश्चित IP पता नहीं है किन्तु फिर भी वह [[Sendmail]] या Postfix (सॉफ्टवेयर) जैसे मानक [[मेल ट्रांसफर एजेंट]] (MTA) को चलाने के लिए तैयार है। | 2000 के दशक के मध्य में, टीसीपी/आईपी पर यूयूसीपी (अधिकांश सुरक्षित शेल प्रोटोकॉल का उपयोग करके एन्क्रिप्ट किया गया)<ref name=UUCPssh/> प्रस्तावित किया गया था{{whom|date=December 2015}} उपयोग के लिए जब कंप्यूटर के पास कोई निश्चित IP पता नहीं है किन्तु फिर भी वह [[Sendmail]] या Postfix (सॉफ्टवेयर) जैसे मानक [[मेल ट्रांसफर एजेंट]] (MTA) को चलाने के लिए तैयार है। | ||
यूज़नेट नेटवर्क के अन्दर बैंग जैसे पथ अभी भी उपयोग में हैं, | यूज़नेट नेटवर्क के अन्दर बैंग जैसे पथ अभी भी उपयोग में हैं, चूंकि रूटिंग के लिए नहीं; उनका उपयोग किसी संदेश के शीर्षलेख में उन नोड्स को रिकॉर्ड करने के लिए किया जाता है जिनके माध्यम से वह संदेश पारित किया गया है, यह निर्देशित करने के अतिरिक्त कि वह आगे कहां जाएगा।<ref>{{cite IETF|title=Netnews लेख प्रारूप|rfc=5536|sectionname=Path|section=3.1.5|page=14-16|author1=K. Murchison|author2=C. Lindsey|author3=D. Kohn|date=November 2009|publisher=[[Internet Engineering Task Force|IETF]]}}</ref> बैंग पथ का उपयोग नेटवर्क होस्ट के बीच स्पष्ट रूप से निर्दिष्ट [[मार्ग]] पथ के लिए अभिव्यक्ति के रूप में भी किया जाता है। यह उपयोग आवश्यक रूप से UUCP, IP रूटिंग, ईमेल मैसेजिंग या यूज़नेट तक सीमित नहीं है। | ||
2000 के दशक की शुरुआत में [[विलंब-सहिष्णु नेटवर्किंग]] प्रोटोकॉल की अवधारणा पर दोबारा गौर किया गया। UUCP द्वारा उपयोग की जाने वाली समान तकनीकें अन्य नेटवर्क पर लागू हो सकती हैं जो देरी या महत्वपूर्ण व्यवधान का अनुभव करती हैं।<ref>{{Cite conference |chapter= A Delay-Tolerant Network Architecture for Challenged Internets |pages= 27–34 |author= Kevin Fall |title= Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications - SIGCOMM '03 |publisher= ACM [[SIGCOMM]] |date= August 2003 |conference= 2003 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications |doi= 10.1145/863955.863960 |isbn= 978-1-58113-735-4 |doi-access= free }}</ref> | 2000 के दशक की शुरुआत में [[विलंब-सहिष्णु नेटवर्किंग]] प्रोटोकॉल की अवधारणा पर दोबारा गौर किया गया। UUCP द्वारा उपयोग की जाने वाली समान तकनीकें अन्य नेटवर्क पर लागू हो सकती हैं जो देरी या महत्वपूर्ण व्यवधान का अनुभव करती हैं।<ref>{{Cite conference |chapter= A Delay-Tolerant Network Architecture for Challenged Internets |pages= 27–34 |author= Kevin Fall |title= Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications - SIGCOMM '03 |publisher= ACM [[SIGCOMM]] |date= August 2003 |conference= 2003 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications |doi= 10.1145/863955.863960 |isbn= 978-1-58113-735-4 |doi-access= free }}</ref> | ||
Revision as of 12:53, 5 July 2023
| Original author(s) | Mike Lesk |
|---|---|
| Developer(s) | AT&T Bell Laboratories |
| Initial release | 1979 |
| Operating system | Unix and Unix-like, DOS, OS/2, OpenVMS, AmigaOS, classic Mac OS, CP/M |
| Type | Command |
यूयूसीपी यूनिक्स-टू-यूनिक्स कॉपी का संक्षिप्त रूप है।[1] यह शब्द सामान्यतः कंप्यूटर प्रोग्राम और संचार प्रोटोकॉल के एक सूट को संदर्भित करता है जो कमांड के दूरस्थ निष्पादन और कंप्यूटर के बीच कम्प्यूटर फाइलों , ईमेल और नेटन्यूज के हस्तांतरण की अनुमति देता है।
uucp नाम का एक कमांड सुइट के प्रोग्रामों में से एक है; यह फ़ाइल प्रतिलिपि संचालन का अनुरोध करने के लिए एक उपयोगकर्ता इंटरफ़ेस प्रदान करता है। यूयूसीपी सुइट में uux (रिमोट कमांड निष्पादन के लिए उपयोगकर्ता इंटरफ़ेस), uucico (संचार प्रोग्राम जो फ़ाइल स्थानांतरण करता है), uustat (नवीनतम गतिविधि पर आंकड़े रिपोर्ट करता है), uuxqt (दूरस्थ मशीनों से भेजे गए कमांड निष्पादित करें), और uuname (रिपोर्ट) भी सम्मिलित है स्थानीय प्रणाली का यूयूसीपी नाम)। सुइट के कुछ संस्करणों में uuencode/uudecode (8-बिट बाइनरी फ़ाइलों को 7-बिट टेक्स्ट प्रारूप में परिवर्तित करना और इसके विपरीत) सम्मिलित है।
यद्यपि यूयूसीपी मूल रूप से 1970 और 1980 के दशक में यूनिक्स पर विकसित किया गया था, और यूनिक्स जैसी प्रणालियों के साथ सबसे निकट से जुड़ा हुआ है, यूयूसीपी कार्यान्वयन कई गैर-यूनिक्स-जैसे ऑपरेटिंग प्रणालीों के लिए उपस्थित है, जिसमें डॉस, ओएस/2, ओपन वीएमएस (केवल वैक्स हार्डवेयर के लिए), अमिगाओएस ,[2] क्लासिक मैक ओएस, और यहां तक कि सीपी/एम भी सम्मिलित हैं।
इतिहास
यूयूसीपी मूल रूप से माइक लेस्क द्वारा एटी एंड टी बेल लेबोरेटरीज में लिखा गया था।[3] 1978 तक यह मुख्य रूप से सॉफ्टवेयर वितरण के लिए बेल प्रणाली के अंदर 82 यूनिक्स मशीनों पर उपयोग में था। इसे 1979 में संस्करण 7 यूनिक्स के भाग के रूप में जारी किया गया था।[4]
अमेरिका से पहला यूयूसीपी ईमेल 1979 में यूनाइटेड किंगडम में आया और यूके, नीदरलैंड और डेनमार्क के बीच ईमेल 1980 में प्रारंभ हुआ, जो 1982 में ईयूनेट के माध्यम से एक नियमित सेवा बन गया।[5][6]
मूल यूयूसीपी को 1983 के आसपास एटी एंड टी शोधकर्ताओं पीटर हनीमैन, डेविड ए. नोविट्ज़ और ब्रायन ई. रेडमैन द्वारा पुनर्लेखन (प्रोग्रामिंग) था। पुनर्लेखन को एचडीबी या हनीडैनबर यूयूसीपी के रूप में जाना जाता है, जिसे बाद में उन्नत बग फिक्स किया गया और बीएनयू यूयूसीपी ("बेसिक नेटवर्क यूटिलिटीज") के रूप में दोबारा पैक किया गया।।[7]
इनमें से प्रत्येक संस्करण को मालिकाना सॉफ्टवेयर के रूप में वितरित किया गया था, जिसने इयान लांस टेलर को 1991 में स्क्रैच से एक नया मुफ्त सॉफ्टवेयर संस्करण लिखने के लिए प्रेरित किया।[8]
टेलर यूयूसीपी जीएनयू जनरल पब्लिक लाइसेंस के अनुसार जारी किया गया था। टेलर यूयूसीपी ने सुरक्षा छेदों को संबोधित किया जिसने कुछ मूल कंप्यूटर कीड़ा को अनपेक्षित शेल कमांड को दूरस्थ रूप से निष्पादित करने की अनुमति दी। टेलर यूयूसीपी ने यूयूसीपी के सभी पिछले संस्करणों की विशेषताओं को भी सम्मिलित किया, जिससे यह किसी भी अन्य संस्करण के साथ संचार कर सके और यहां तक कि अन्य संस्करणों से समान कॉन्फ़िगरेशन फ़ाइल स्वरूपों का उपयोग कर सके।
यूयूसीपी को गैर-यूनिक्स ऑपरेटिंग प्रणाली, विशेष रूप से डॉस प्रणाली, के लिए भी लागू किया गया था। यूस्लेव/जीएनयूयूसीपी (जॉन गिलमोर (कार्यकर्ता), गैरी पैक्सिनो, टिम पॉज़र), यूयूसीपी/विस्तारित (केन्द्र इलेक्ट्रॉनिक वंडरवर्क्स के ड्रू डर्बीशायर) और एफएसयूयूसीपी (आईओडिज़ाइन के क्रिस्टोफर एंबलर) जैसे पैकेजों ने इंटरकनेक्टेड यूनिवर्सिटी प्रणाली से परे नेटवर्क का विस्तार करते हुए व्यक्तिगत कंप्यूटरों के लिए प्रारंभिक इंटरनेट कनेक्टिविटी लाई। एफएसयूयूसीपी ने कई बुलेटिन बोर्ड प्रणाली (बीबीएस) पैकेजों का आधार बनाया, जैसे कि गैलेक्टिकॉम के मेजर बीबीएस और मस्टैंग सॉफ्टवेयर के वाइल्डकैट! यूयूसीपी नेटवर्क से जुड़ने और ईमेल और यूज़नेट ट्रैफ़िक का आदान-प्रदान करने के लिए बीबीएस। एक उदाहरण के रूप में, यूएफगेट (जॉन गैल्विन, गैरी पैक्सिनो, टिम पॉज़र) एक पैकेज था जो फिडोनेट और यूयूसीपी प्रोटोकॉल चलाने वाले नेटवर्क के बीच एक प्रवेश द्वार प्रदान करता था।
एफएसयूयूसीपी टेलर के संवर्धित 'i' प्रोटोकॉल का एकमात्र अन्य कार्यान्वयन था, जो अधिकांश यूयूसीपी कार्यान्वयनों द्वारा उपयोग किए जाने वाले मानक 'g' प्रोटोकॉल पर एक महत्वपूर्ण सुधार था।[citation needed]
प्रौद्योगिकी
इंटरनेट एक्सेस की व्यापक उपलब्धता से पहले, कंप्यूटर केवल किसी कंपनी या संगठन के अन्दर छोटे स्थानीय क्षेत्र नेटवर्क से जुड़े होते थे। वे अधिकांश मोडेम से भी लैस होते थे जिससे उन्हें डायल-अप टेलीफोन लाइनों के माध्यम से कैरेक्टर-मोड टर्मिनलों से दूर से उपयोग किया जा सके। यूयूसीपी ने अन्य कंप्यूटरों से डायल आउट करने, उनके बीच अस्थायी, पॉइंट-टू-पॉइंट लिंक स्थापित करने के लिए कंप्यूटर के मॉडेम का उपयोग किया था। यूयूसीपी नेटवर्क में प्रत्येक प्रणाली में फोन नंबर, लॉगिन नाम और पासवर्ड इत्यादि के साथ पड़ोसी प्रणाली की एक सूची होती है। uucico प्रोग्राम सामान्यतः उस प्रणाली को काम को प्रोसेस करने के लिए कहता है। वह uucico कार्यक्रम समय-समय पर अपने पड़ोसियों को उनकी तरफ कतारबद्ध काम की जांच करने के लिए भी मतदान कर सकता है; यह बिना डायल-आउट क्षमता वाले पड़ोसियों को भाग लेने की अनुमति देता है।
समय के साथ, डायल-अप लिंक को इंटरनेट कनेक्शन द्वारा प्रतिस्थापित कर दिया गया, और यूयूसीपी ने कई नए लिंक परत प्रोटोकॉल जोड़े। इन नए कनेक्शनों ने यूयूसीपी की आवश्यकता को बिल्कुल भी कम कर दिया, क्योंकि नए नेटवर्क का लाभ उठाने के लिए नए एप्लिकेशन प्रोटोकॉल विकसित किए गये हैं। आज, यूयूसीपी का उपयोग संभवतः ही कभी डायल-अप लिंक पर किया जाता है किन्तु कभी-कभी टीसीपी/आईपी पर इसका उपयोग किया जाता है।[9][10] 2006 के प्रारंभ में सम्मिलित प्रणालियों की संख्या 60 उद्यमों में 1500 और 2000 साइटों के बीच चल रही थी। यूयूसीपी के दीर्घजीवी होने का श्रेय इसकी कम लागत, व्यापक लॉगिंग, डायलअप में नेटिव फ़ेलओवर , और निरंतर कतार प्रबंधन को दिया जा सकता है।
सत्र
यूयूसीपी सामान्य रूप से लक्ष्य प्रणाली में एक उपयोगकर्ता लॉग इन करके और फिर यूयूसीपी प्रोग्राम चलाकर प्रारंभ किया जाता है। अधिकांश स्थितियों में, यह स्थानान्तरण के लिए उपयोग किए जाने वाले ज्ञात उपयोगकर्ता खाते में प्रवेश करके स्वचालित होता है, जिसका खाता शेल uucico पर सेट किया गया है। इस प्रकार, स्वचालित स्थानान्तरण के लिए, किसी अन्य मशीन को बस कॉल की गई मशीन से एक मॉडेम कनेक्शन खोलना होगा और ज्ञात खाते में लॉग इन करना होगा।
जब uucico चलता है, यह कॉल करने वाले की मशीन पर दूसरे यूयूसीपी प्रोग्राम से कमांड प्राप्त करने और एक सत्र प्रारंभ करने की अपेक्षा करेगा। सत्र के तीन अलग-अलग चरण हैं:
- प्रारंभिक हैंडशेक
- फ़ाइल अनुरोध
- फाइनल हैंडशेक
प्रारंभिक हैंडशेक
प्रारंभ करने पर, uucico एक पहचान स्ट्रिंग \20Shere=hostname\0 भेजकर प्रतिक्रिया देगा, जहां \20 नियंत्रण-पी वर्ण है, और \0 अनुगामी शून्य है। कॉल करने वाले का यूयूसीपी \20Scallername options\0 के साथ प्रतिक्रिया करता है, जहां विकल्प एक स्ट्रिंग है जिसमें शून्य या अधिक यूनिक्स-जैसे विकल्प स्विच होते हैं। इनमें पैकेट और विंडो आकार, अधिकतम समर्थित फ़ाइल आकार, डिबगिंग विकल्प और अन्य सम्मिलित हो सकते हैं।
दो प्रणाली के सेटअप के आधार पर, कॉल यहाँ समाप्त हो सकती है। उदाहरण के लिए, जब कॉल करने वाला अपने प्रणाली नाम के साथ प्रतिक्रिया करता है, तो कॉल किया गया प्रणाली वैकल्पिक रूप से हैंग हो सकता है यदि वह RYou are unknown to me\0 प्रतिक्रिया स्ट्रिंग भेजने वाले कॉलर को नहीं पहचानता है और फिर डिस्कनेक्ट हो जाता है।
फ़ाइल अनुरोध
यदि दो प्रणालियाँ सफलतापूर्वक हाथ मिलाती हैं, तो कॉलर अब फ़ाइल अनुरोधों की एक श्रृंखला भेजना प्रारंभ कर देगा। चार प्रकार हैं:
- S कॉल करने वाले से फाइल को प्रणाली (अपलोड) में भेजने का कारण बनता है। से और नाम प्रदान किए जाते हैं, जिससे फ़ाइल नाम को रिसीवर पर बदला जा सकता है। जब कॉल किए गए प्रणाली पर एस कमांड प्राप्त होता है, तो यह सफल होने पर एसवाई के साथ प्रतिक्रिया करता है और यह फाइल को स्वीकार करने के लिए तैयार है, या एसएनएक्स विफल होने पर, जहां एक्स विफलता का कारण है। यदि कॉल करने वाले को SY प्राप्त होता है, तो वह आरंभिक हैंडशेक (नीचे देखें) के समय चुने गए प्रोटोकॉल का उपयोग करके फ़ाइल अपलोड करना प्रारंभ कर देता है। जब स्थानांतरण पूरा हो जाता है, तो कॉल किया गया प्रणाली CY के साथ प्रतिक्रिया करता है यदि उसे फ़ाइल सफलतापूर्वक प्राप्त हो गई है, या CN5 यदि विफल हो गई है।
- R कॉल करने वाले (डाउनलोड) को फ़ाइल भेजने के लिए कॉल किए गए प्रणाली के लिए एक अनुरोध है। यह अन्यथा एस के समान है, आदेश को स्वीकार करने के लिए आरवाई और आरएन का उपयोग करना और यह डेटा भेजना प्रारंभ कर देगा या इसमें कोई समस्या होगी, और स्थानांतरण के अंत में कॉलर से सीवाई और सीएन 5 की अपेक्षा है।
- X कमांड को कॉल किए गए प्रणाली पर निष्पादित करने के लिए अपलोड करता है। इसका उपयोग उस प्रणाली को दूसरे को कॉल करने और उसमें फाइल वितरित करने के लिए किया जा सकता है। कॉल किया गया प्रणाली XY के साथ प्रतिक्रिया करता है यदि यह सफल हुआ या XN यदि यह असफल हुआ।
- H, हैंगअप के लिए, निरुपित करता है कि कॉलर हो गया है। कॉल किया गया प्रणाली HY के साथ प्रतिक्रिया करता है यदि यह सफल हुआ या HN यदि यह विफल रहा।
अंतिम हैंडशेक
H कमांड भेजने के बाद, कॉलिंग प्रणाली एक अंतिम पैकेट \20OOOOOO\0 (कंट्रोल-पी, सिक्स ओह्स, नल-टर्मिनेटर) भेजता है और कॉल किया गया प्रणाली \20OOOOOO\0 (कंट्रोल-पी, सात ओह, नल-टर्मिनेटर) के साथ प्रतिक्रिया करता है। कुछ प्रणालियाँ एच कमांड के सफल स्वागत पर ही रुक जाएंगी और अंतिम हैंडशेक से परेशान नहीं होंगी।
जी-प्रोटोकॉल
यूयूसीपी में प्रोटोकॉल के सूट के अन्दर, अंतर्निहित जी-प्रोटोकॉल सूचना को त्रुटि मुक्त रूप में स्थानांतरित करने के लिए जिम्मेदार है। प्रोटोकॉल पैकेट वितरण के लिए एक सामान्य-उद्देश्य प्रणाली के रूप में उत्पन्न हुआ, और इस प्रकार कई सुविधाएँ प्रदान करता है जो कि यूयूसीपी पैकेज द्वारा समग्र रूप से उपयोग नहीं की जाती हैं। इनमें एक द्वितीयक चैनल शामिल है जो फ़ाइल स्थानांतरण के साथ-साथ कमांड डेटा भेज सकता है, और ट्रांसमिशन के दौरान पैकेट और विंडो आकार पर फिर से बातचीत करने की क्षमता शामिल है। ये अतिरिक्त सुविधाएँ यूयूसीपी स्टैक के कुछ कार्यान्वयनों में उपलब्ध नहीं हो सकती हैं।[11]
पैकेट प्रारूप में 6-बाइट हेडर और फिर पेलोड में शून्य और 4096 बाइट्स के बीच होता है। पैकेट एक \020 (नियंत्रण-पी) से प्रारंभ होता है। इसके बाद एक एकल बाइट आती है, जिसे K के रूप में जाना जाता है, जिसमें 1 से 8 का मान होता है, जो 32 से 4096 बाइट्स के पैकेट आकार को दर्शाता है, या 9 एक नियंत्रण पैकेट को दर्शाता है। कई प्रणालियाँ केवल K = 2 का समर्थन करती हैं, जिसका अर्थ है 64 बाइट्स। अगले दो बाइट पेलोड के 16-बिट चेकसम थे, जिसमें हेडर सम्मिलित नहीं था। अगला बाइट डेटा प्रकार है और अंत में, अंतिम बाइट हेडर का एक्सओआर है, जिससे इसे पेलोड से अलग से चेक किया जा सकता है।[11]
नियंत्रण बाइट में TTXXXYYY प्रारूप में तीन बिट-फ़ील्ड होते हैं। टीटी पैकेट प्रकार है, नियंत्रण पैकेट के लिए 0 (जिसके लिए वैध होने के लिए के = 9 की भी आवश्यकता होती है), 1 वैकल्पिक डेटा के लिए (यूयूसीपी में उपयोग नहीं किया गया), 2 डेटा के लिए, और 3 एक छोटे पैकेट को निरुपित करता है जो अर्थ को फिर से परिभाषित करता है K. एक डेटा पैकेट में, XXX इस पैकेट के लिए 0 से 7 तक पैकेट संख्या है, और YYY अंतिम है जो सही ढंग से प्राप्त हुआ था। यह एक विंडो में 8 पैकेट तक प्रदान करता है। एक नियंत्रण पैकेट में, XXX कमांड को निरुपित करता है और YYY का उपयोग विभिन्न मापदंडों के लिए किया जाता है। उदाहरण के लिए, टीटी = 0 (नियंत्रण), XXX = 7 और YYY के साथ एक विंडो में पैकेट की संख्या के साथ एक छोटा नियंत्रण पैकेट भेजकर स्थानांतरण प्रारंभ किया जाता है, फिर XXX = 6 और YYY के साथ पैकेट लंबाई के रूप में एक और पैकेट भेजा जाता है (के रूप में एन्कोड किया गया) यह K में होगा) और फिर एक तीसरा पैकेट जो पहले के समान है किन्तु XXX = 5 है।[11]
जी-प्रोटोकॉल एंडपॉइंट्स के बीच संभावित लंबी लेटेंसी से निपटने के लिए एक सरल स्लाइडिंग विंडो प्रणाली का उपयोग करता है। प्रोटोकॉल पैकेट को 64 से 4096 8-बिट बाइट्स और विंडो जिसमें 1 से 7 पैकेट सम्मिलित हैं, के आकार की अनुमति देता है। सिद्धांत रूप में, 4k पैकेट और 7 पैकेट विंडो (4096x7) का उपयोग करने वाली प्रणाली ज़ेडमोडेम जैसे सर्वश्रेष्ठ फ़ाइल-ट्रांसफर प्रोटोकॉल से मेल खाने या बेहतर प्रदर्शन की पेशकश करेगी। व्यवहार में, कई कार्यान्वयन केवल 64x3 की एक सेटिंग का समर्थन करते हैं। नतीजतन, जी-प्रोटोकॉल की खराब प्रदर्शन के लिए एक अवांछनीय प्रतिष्ठा है। पैकेट और विंडो के आकार पर भ्रम की स्थिति जी-प्रोटोकॉल के कारण हुई, केवल इसमें अंतर था कि यह हमेशा 4096x3. टेलर यूयूसीपी ने जी का समर्थन नहीं किया, किन्तु किसी भी वैध अनुरोधित विंडो या पैकेट आकार का समर्थन किया, इसलिए जी प्रारंभ करने वाले रिमोट प्रणाली टेलर के जी के साथ ठीक काम करेंगे, जबकि दो टेलर प्रणाली तेजी से कनेक्शन पर बातचीत कर सकते थे।[11]
टेलीविजन मोडेम ने प्रोटोकॉल स्पूफिंग का इस्तेमाल रिमोट प्रणाली को भेजे जाने वाले एंड-ऑफ-पैकेट मार्करों को नोटिस करके और तुरंत एक संदेश भेजकर जी-प्रोटोकॉल ट्रांसफर के प्रदर्शन को बेहतर बनाने के लिए किया। ACK स्थानीय होस्ट पर वापस, यह दिखाते हुए कि रिमोट प्रणाली ने पहले ही पैकेट प्राप्त कर लिया है और इसे सही विधि से डिकोड कर दिया है। इसने सॉफ्टवेयर स्टैक को अगला पैकेट भेजने के लिए ट्रिगर किया, इतनी तेजी से कि स्थानांतरण लगभग निरंतर हो गया। माइक्रोकॉम नेटवर्किंग प्रोटोकॉल पर आधारित एक मालिकाना प्रोटोकॉल का उपयोग करके दो मोडेम के बीच डेटा त्रुटि-सुधार किया गया था, जो सामान्य रूप से जी-प्रोटोकॉल की तुलना में टेलीबिट के आधे-द्वैध कनेक्शनों पर चलता था।[11] क्योंकि आम 64x3 स्थितियों में रिमोट प्रणाली एक निरंतर स्ट्रीम भेज रहा होगा ACKs जो लो-स्पीड रिटर्न चैनल को ओवरफ्लो कर देगा। मॉडेम की स्वाभाविक रूप से उच्च डेटा दरों के साथ संयुक्त, उन्होंने समग्र थ्रूपुट में काफी सुधार किया और सामान्यतः 2400 बिट/एस मॉडेम की गति के बारे में सात गुना प्रदर्शन किया।[12] यूयूसीपी मेजबानों पर उनका व्यापक रूप से उपयोग किया गया क्योंकि वे कम लंबी दूरी के शुल्कों में स्वयं के लिए जल्दी से भुगतान कर सकते थे।
अन्य प्रोटोकॉल
यूयूसीपी कार्यान्वयन में कुछ लिंक्स पर उपयोग के लिए अन्य ट्रांसफर प्रोटोकॉल भी सम्मिलित हैं।
f-प्रोटोकॉल को 7-बिट त्रुटि-सुधारित लिंक चलाने के लिए डिज़ाइन किया गया है। यह मूल रूप से X.25 लिंक पर उपयोग के लिए अभिप्रेत था, जो 1980 के दशक में एक समय के लिए लोकप्रिय थे। यह डेटा को पैकेट नहीं करता है, इसके अतिरिक्त, पूरी फ़ाइल को एक लंबी स्ट्रिंग के रूप में भेजा जाता है, जिसके बाद एक संपूर्ण फ़ाइल चेकसम होता है। ऐसा प्रतीत होता है कि समान एक्स-प्रोटोकॉल का बहुत कम या कोई उपयोग नहीं हुआ है। डी-प्रोटोकॉल एक्स के समान था, किन्तु डेटाकिट नेटवर्क पर उपयोग के लिए अभिप्रेत था जो बेल लैब्स के कई कार्यालयों से जुड़ा था।[11]
टी-प्रोटोकॉल यूयूसीपी के बीएसडी संस्करणों में उत्पन्न हुआ है और इसे 8-बिट त्रुटि-मुक्त टीसीपी/आईपी लिंक चलाने के लिए डिज़ाइन किया गया है। इसमें कोई त्रुटि सुधार नहीं है, और प्रोटोकॉल में सामान्य टीसीपी फ्रेम के अन्दर आसानी से फिट होने के लिए 512 या 1024-बाइट पैकेट में कमांड और फाइल डेटा को तोड़ना सम्मिलित है। कम उपयोग किया जाने वाला ई-प्रोटोकॉल, जो बीएसडी से टी के विरोध में हनीडैनबेर संस्करणों को उत्पन्न करता है, केवल उस कमांड में भिन्न होता है जिसे पैकेट नहीं किया जाता है और इसके अतिरिक्त सामान्य स्ट्रिंग्स के रूप में भेजा जाता है, जबकि फाइलें निकटतम 20 बाइट्स तक पैडेड होती हैं।[11]
मेल रूटिंग
uucpऔरuuxqtक्षमताओं का उपयोग उपयुक्त मेल यूजर इंटरफेस और डिलीवरी एजेंट प्रोग्राम वाली मशीनों के बीच ईमेल भेजने के लिए किया जा सकता है। एक साधारण यूयूसीपी मेल पता आसन्न मशीन के नाम से एक विस्मयादिबोधक चिह्न (अधिकांश उच्चारित बैंग कहा जाता है) से बनाया गया था, जिसके बाद आसन्न मशीन पर उपयोगकर्ता का नाम होता था। उदाहरण के लिए, पता barbox!user आसन्न मशीन बारबॉक्स पर उपयोगकर्ता उपयोगकर्ता को संदर्भित करेगा।
मेल को अपने गंतव्य पर पहुंचने से पहले किसी भी संख्या में मध्यवर्ती नोड्स को पार करते हुए, नेटवर्क के माध्यम से रूट किया जा सकता है। प्रारंभ में, यह पूर्ण पथ निर्दिष्ट करके किया जाना था, मध्यवर्ती मेजबान नामों की एक सूची के साथ बैंग्स द्वारा अलग किया गया। उदाहरण के लिए, यदि मशीन बारबॉक्स स्थानीय मशीन से जुड़ा नहीं है, किन्तु यह ज्ञात है कि बारबॉक्स मशीन फूवैक्स से जुड़ा है जो स्थानीय मशीन के साथ संचार करता है, तो मेल भेजने के लिए उपयुक्त पता foovax!barbox!user होगा।
उपयोगकर्ता barbox!user सामान्यतः अपने यूयूसीपी ईमेल पते को …!bigsite!foovax!barbox!user जैसे रूप में प्रकाशित करेगा। यह लोगों को अपने मेल को मशीन बिगसाइट (संभवतः एक प्रसिद्ध और अच्छी तरह से जुड़ी हुई मशीन जो हर किसी के लिए सुलभ है) और वहां से मशीन फूवैक्स के माध्यम से बारबॉक्स पर उपयोगकर्ता उपयोगकर्ता के खाते में भेजने के लिए निर्देशित करता है। एक पूर्ण पथ प्रकाशित करना व्यर्थ होगा, क्योंकि प्रेषक कहां था, इस पर निर्भर करते हुए यह अलग होगा। (उदाहरण के लिए एक साइट पर ऐन को पाथ gway!tcol!canty!uoh!bigsite!foovax!barbox!user के माध्यम से भेजना पड़ सकता है, जबकि कहीं और से बिल को पथ pdp10!router22!bigsite!foovax!barbox!user के माध्यम से भेजना होगा)। कई उपयोगकर्ता विभिन्न बड़ी प्रसिद्ध साइटों से कई मार्गों का सुझाव देंगे, जो मेल प्रेषक से बेहतर और संभवतः तेज़ कनेक्शन सेवा प्रदान करते हैं।
बंग पथ
इस प्रपत्र के एक ईमेल पते को बैंग पाथ के रूप में जाना जाता था।
1981 में आठ से दस मशीनों (या हॉप्स) के धमाके असामान्य नहीं थे, और देर रात डायल-अप यूयूसीपी लिंक सप्ताह भर के प्रसारण समय का कारण बन सकते थे। प्रसारण समय और विश्वसनीयता दोनों द्वारा बैंग पथों का चयन अधिकांश किया जाता था, क्योंकि संदेश अधिकांश खो जाते थे। कुछ मेजबान इतनी दूर चले गए कि पथ को फिर से लिखने, तेज मार्गों के माध्यम से मेल भेजने की कोशिश करने लगे- इस प्रथा पर ध्यान नहीं दिया गया।
सूडो-डोमेन एंडिंग .uucp को कभी-कभी यूयूसीपी नेटवर्किंग द्वारा पहुंच योग्य होने के रूप में एक होस्टनाम को निर्दिष्ट करने के लिए उपयोग किया जाता था, चूंकि यह डोमेन की नामांकन प्रणाली (डीएनएस) में एक शीर्ष-स्तरीय डोमेन के रूप में औपचारिक रूप से पंजीकृत नहीं था। यूयूसीपी समुदाय ने स्वयं को प्रशासित किया और डीएनएस को नियंत्रित करने वाले प्रशासन के विधियों और विनियमों के साथ अच्छी तरह से मेल नहीं खाता था; .uucp वहां काम करता है जहां इसकी आवश्यकता होती है[where?]; यदि आने वाले SMTP कनेक्शन पर .uucp पता पहचाना जाता है, तो कुछ होस्ट[which?] मेल को एसएमटीपी कतार से गेटवे मशीनों पर यूयूसीपी कतारों में भेज देते हैं।[citation needed]
यूज़नेट ट्रैफ़िक मूल रूप से बैंग पाथ का उपयोग करके यूयूसीपी प्रोटोकॉल पर प्रसारित किया गया था। ये अभी भी यूज़नेट संदेश प्रारूप पथ हेडर लाइनों के अन्दर उपयोग में हैं। उनके पास अब केवल एक सूचनात्मक उद्देश्य है, और रूटिंग के लिए उपयोग नहीं किया जाता है, चूंकि उनका उपयोग यह सुनिश्चित करने के लिए किया जा सकता है कि लूप नहीं होते हैं।
सामान्य तौर पर, अन्य गैर-इंटरनेट ईमेल पते|पुराने ई-मेल पता प्रारूपों की तरह, बैंग पथों को अब ईमेल पते#अवलोकन|@ नोटेशन द्वारा अधिक्रमित कर दिया गया है, यहां तक कि उन साइटों द्वारा भी जो अभी भी यूयूसीपी का उपयोग कर रहे हैं। एक यूयूसीपी-ओनली साइट एक डीएनएस डोमेन नाम पंजीकृत कर सकती है, और उस डोमेन को संभालने वाला डीएनएस सर्वर एमएक्स रिकॉर्ड प्रदान करता है जो उस साइट पर इंटरनेट मेल को इंटरनेट पर यूयूसीपी होस्ट को वितरित करने का कारण बनता है जो यूयूसीपी साइट को मेल वितरित कर सकता है।
यूयूसीपीएनईटी और मैपिंग
UUCP नेट UUCP के माध्यम से जुड़े कंप्यूटरों के नेटवर्क की समग्रता का नाम था। यह नेटवर्क बहुत ही अनौपचारिक था, जिसे हजारों निजी कंपनियों, विश्वविद्यालयों आदि के स्वामित्व वाली प्रणालियों के बीच आपसी सहयोग की भावना से बनाए रखा गया था। अधिकांश, विशेष रूप से निजी क्षेत्र में, कंपनियों के ऊपरी प्रबंधन से आधिकारिक अनुमोदन के बिना यूयूसीपी लिंक स्थापित किए गए थे। UUCP नेटवर्क लगातार बदल रहा था क्योंकि नए प्रणाली और डायल-अप लिंक जोड़े गए थे, अन्य को हटा दिया गया था, आदि।
यूयूसीपी मैपिंग प्रोजेक्ट एक स्वयंसेवक था, जो खुले मेल रिले वाली मशीनों के बीच कनेक्शन का नक्शा बनाने और एक प्रबंधित नामस्थान स्थापित करने का काफी हद तक सफल प्रयास था। प्रत्येक प्रणाली एडमिनिस्ट्रेटर ई-मेल द्वारा उन प्रणाली की एक सूची प्रस्तुत करेगा जिससे उनका कनेक्ट होगा, ऐसे प्रत्येक कनेक्शन के लिए एक रैंकिंग के साथ। इन सबमिट की गई मानचित्र प्रविष्टियों को एक स्वचालित प्रोग्राम द्वारा संसाधित किया गया था जो उन्हें नेटवर्क में सभी कनेक्शनों का वर्णन करने वाली फाइलों के एक सेट में जोड़ती थी। इन फ़ाइलों को तब इस उद्देश्य के लिए समर्पित समाचार समूह में मासिक रूप से प्रकाशित किया गया था। UUCP मानचित्र फ़ाइलों का उपयोग सॉफ्टवेयर द्वारा किया जा सकता है जैसे कि मेल के लिए एक मशीन से दूसरी मशीन तक सर्वोत्तम मार्ग पथ की गणना करने के लिए, और इस मार्ग को स्वचालित रूप से आपूर्ति करने के लिए। UUCP मानचित्रों ने साइटों के लिए संपर्क जानकारी भी सूचीबद्ध की, और इसलिए संभावित पड़ोसियों को खोजने के लिए UUCPNET में सम्मिलित होने की मांग करने वाली साइटों को एक आसान तरीका दिया।
इंटरनेट के साथ कनेक्शन
कई UUCP होस्ट, विशेष रूप से विश्वविद्यालयों में, अपने शुरुआती वर्षों में इंटरनेट से जुड़े हुए थे, और इंटरनेट SMTP- आधारित मेल और UUCP मेल के बीच ई-मेल गेटवे विकसित किए गए थे। UUCP कनेक्शन वाले प्रणाली पर एक उपयोगकर्ता इंटरनेट उपयोगकर्ताओं के साथ मेल का आदान-प्रदान कर सकता है, और इंटरनेट लिंक का उपयोग धीमे UUCP नेटवर्क के बड़े हिस्से को बायपास करने के लिए किया जा सकता है। इन इंटरफेस की सुविधा के लिए एक यूयूसीपी क्षेत्र को इंटरनेट डोमेन नेमस्पेस के अन्दर परिभाषित किया गया था।
इस बुनियादी ढांचे के साथ, UUCP की ताकत यह थी कि इसने एक साइट को इंटरनेट ई-मेल और यूज़नेट कनेक्टिविटी प्राप्त करने की अनुमति दी, जिसमें केवल एक डायल-अप मॉडेम लिंक दूसरे सहयोगी कंप्यूटर से था। यह एक ऐसा समय था जब सच्चे इंटरनेट एक्सेस के लिए एक इंटरनेट पॉइंट ऑफ़ प्रेजेंस के लिए एक कनेक्शन प्रदान करने वाली एक किरका का रेखा की आवश्यकता थी, जो दोनों महंगे थे और व्यवस्था करना मुश्किल था। इसके विपरीत, UUCP नेटवर्क के लिए एक लिंक सामान्यतः संभावित पड़ोसी प्रणाली के प्रशासकों को कुछ फोन कॉल के साथ स्थापित किया जा सकता है। टेलीफोन कॉल के लिए सबसे बुनियादी शुल्क को छोड़कर सभी से बचने के लिए पड़ोसी प्रणाली अधिकांश काफी करीब थे।
रिमोट कमांड
यूयूएक्स यूयूसीपी पर रिमोट कमांड निष्पादन है। यूक्स कमांड का उपयोग रिमोट प्रणाली पर कमांड (कंप्यूटिंग) निष्पादित करने के लिए किया जाता है, या रिमोट प्रणाली से फाइलों का उपयोग करके स्थानीय प्रणाली पर कमांड निष्पादित करने के लिए किया जाता है। कमांड द्वारा चलाया जाता है uucico डेमन, जो दूरस्थ निष्पादन अनुरोधों को केवल एक अन्य प्रकार की फ़ाइल के रूप में संभालता है, जब भी कोई अगला-हॉप नोड उपलब्ध होता है, तो रिमोट प्रणाली को बैच-भेजता है। रिमोट प्रणाली तब अनुरोधित कमांड को निष्पादित करेगा और परिणाम लौटाएगा, जब मूल प्रणाली उपलब्ध होगा। उपलब्धता की मनमानी खिड़कियों के साथ, ये दोनों स्थानान्तरण अप्रत्यक्ष हो सकते हैं, मल्टी-हॉप पथ के माध्यम से। हमेशा उपलब्ध पड़ोसी पर कमांड निष्पादित करते समय भी, यूक्स तत्काल नहीं होता है।
अस्वीकार
सस्ती सीरियल लाइन आईपी और पॉइंट-टू-पॉइंट प्रोटोकॉल सेवाओं की पेशकश करने वाले इंटरनेट सेवा प्रदाताओं के उदय के साथ यूयूसीपी का उपयोग समाप्त होना प्रारंभ हो गया। UUCP मानचित्रण परियोजना को औपचारिक रूप से 2000 के अंत में बंद कर दिया गया था।
यूयूसीपी प्रोटोकॉल को अब ज्यादातर इंटरनेट टीसीपी/आईपी आधारित प्रोटोकॉल मेल के लिए सरल डाक स्थानांतरण प्रोटोकॉल और यूज़नेट न्यूज के लिए नेटवर्क न्यूज ट्रांसफर प्रोटोकॉल द्वारा बदल दिया गया है।
जुलाई 2012 में, डच इंटरनेट प्रदाता XS4ALL ने अपनी UUCP सेवा को बंद कर दिया, यह दावा करते हुए कि यह शायद दुनिया के अंतिम प्रदाताओं में से एक था जिसने अभी भी इसकी पेशकश की थी; उस समय इसके केवल 13 उपयोगकर्ता थे (चूंकि इसके बंद होने से पहले इसने कई वर्षों तक नए उपयोगकर्ताओं के अनुरोधों को अस्वीकार कर दिया था)।[13]
वर्तमान उपयोग और विरासत
UUCP की एक जीवित विशेषता चैट फ़ाइल प्रारूप है, जो मोटे तौर पर अपेक्षा करना सॉफ़्टवेयर पैकेज द्वारा विरासत में मिली है।
यूयूसीपी विशेष प्रयोजन के उच्च लागत वाले लिंक (जैसे समुद्री उपग्रह लिंक) पर इसके गायब होने के लंबे समय बाद तक उपयोग में था,[14] और अभी भी लेगेसी उपयोग में है[citation needed]. विरासत के उपयोग के अलावा, 2021 में नए और अभिनव यूयूसीपी उपयोग बढ़ रहे हैं, विशेष रूप से उच्च आवृत्ति बैंड में दूरसंचार के लिए, उदाहरण के लिए, ईमेल एक्सचेंज और अन्य उपयोगों के लिए अमेज़ॅन वर्षावन में समुदायों के लिए। इयान के यूयूसीपी के एक पैच को यूयूसीपी डेबियन लिनक्स पैकेज में योगदान दिया गया था[15] HERMES (हाई-फ़्रीक्वेंसी इमरजेंसी एंड रूरल मल्टीमीडिया एक्सचेंज प्रणाली) प्रोजेक्ट के अनुकूल होने के लिए, जो UUCP HF कनेक्टिविटी प्रदान करता है।[16] 2000 के दशक के मध्य में, टीसीपी/आईपी पर यूयूसीपी (अधिकांश सुरक्षित शेल प्रोटोकॉल का उपयोग करके एन्क्रिप्ट किया गया)[10] प्रस्तावित किया गया था[according to whom?] उपयोग के लिए जब कंप्यूटर के पास कोई निश्चित IP पता नहीं है किन्तु फिर भी वह Sendmail या Postfix (सॉफ्टवेयर) जैसे मानक मेल ट्रांसफर एजेंट (MTA) को चलाने के लिए तैयार है।
यूज़नेट नेटवर्क के अन्दर बैंग जैसे पथ अभी भी उपयोग में हैं, चूंकि रूटिंग के लिए नहीं; उनका उपयोग किसी संदेश के शीर्षलेख में उन नोड्स को रिकॉर्ड करने के लिए किया जाता है जिनके माध्यम से वह संदेश पारित किया गया है, यह निर्देशित करने के अतिरिक्त कि वह आगे कहां जाएगा।[17] बैंग पथ का उपयोग नेटवर्क होस्ट के बीच स्पष्ट रूप से निर्दिष्ट मार्ग पथ के लिए अभिव्यक्ति के रूप में भी किया जाता है। यह उपयोग आवश्यक रूप से UUCP, IP रूटिंग, ईमेल मैसेजिंग या यूज़नेट तक सीमित नहीं है।
2000 के दशक की शुरुआत में विलंब-सहिष्णु नेटवर्किंग प्रोटोकॉल की अवधारणा पर दोबारा गौर किया गया। UUCP द्वारा उपयोग की जाने वाली समान तकनीकें अन्य नेटवर्क पर लागू हो सकती हैं जो देरी या महत्वपूर्ण व्यवधान का अनुभव करती हैं।[18]
यह भी देखें
संदर्भ
- ↑ UNIX(TM) TIME-SHARING SYSTEM: UNIX PROGRAMMER'S MANUAL, Seventh Edition, Volume 1 (PDF). Murray Hill, New Jersey: Bell Telephone Laboratories, Incorporated. January 1979. Archived (PDF) from the original on 2016-04-29. Retrieved 2018-02-20.
- ↑ "Aminet - Search".
- ↑ McIlroy, M. D. (1987). A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986 (PDF) (Technical report). CSTR. Bell Labs. 139. Archived (PDF) from the original on 2017-11-11. Retrieved 2015-02-01.
- ↑ "Version 7 Unix manual: "UUCP Implementation Description" by D. A. Nowitz, and "A Dial-Up Network of UNIX Systems" by D. A. Nowitz and M. E. Lesk" (PDF). Archived (PDF) from the original on 2018-02-21. Retrieved 2018-02-21.
- ↑ Houlder, Peter (19 January 2007). "यूके में वाणिज्यिक इंटरनेट शुरू करना" (PDF). 6th UK Network Operators' Forum. Retrieved 2020-02-12.
- ↑ Reid, Jim (3 April 2007). "Networking in UK Academia ~25 Years Ago" (PDF). 7th UK Network Operators' Forum. Retrieved 2020-02-12.
- ↑ Gary J. Murakami (September 24, 1988). "The History of ihnp4 and The Growth of the Email Network". Archived from the original on September 11, 2013. Retrieved June 7, 2013.
- ↑ Ian Lance Taylor (September 1991). "Beta release of new UUCP package available". Retrieved 2009-01-19.
- ↑ Ian Lance Taylor (June 2003). "UUCP 'f' Protocol". Archived from the original on 2008-07-18. Retrieved 2008-08-04.
- ↑ 10.0 10.1 Fabien Penso. "UUCPssh". Archived from the original on 2009-09-30. Retrieved 2009-08-09.
- ↑ 11.0 11.1 11.2 11.3 11.4 11.5 11.6 Taylor, Ian Lance (8 March 1996). "UUCP आंतरिक अक्सर पूछे जाने वाले प्रश्न". Archived from the original on 6 November 2019. Retrieved 29 August 2020.
- ↑ Kirksey, Kenneth (25 December 1991). "मोडेम के बारे में आपको क्या जानना चाहिए". Archived from the original on 24 October 2020. Retrieved 29 August 2020.
The actual throughput is around 14400 bps.
- ↑ Huijbregts, Niels (30 July 2012). "XS4ALL Weblog: Afscheid van UUCP (Goodbye to UUCP)" (in Nederlands). XS4ALL. Archived from the original on 31 July 2013.
- ↑ Randolph Bentson (August 1995). "Linux Goes To Sea". Archived from the original on 2008-02-26. Retrieved 2009-02-21.
- ↑ Rafael Diniz (January 2021). "UUCP 1.07.27-changelog". Archived from the original on 2020-08-12. Retrieved 2021-01-10.
- ↑ Rafael Diniz (January 2021). "High-frequency Emergency and Rural Multimedia Exchange System". Retrieved 2021-01-10.
- ↑ K. Murchison; C. Lindsey; D. Kohn (November 2009). "Path". Netnews लेख प्रारूप. IETF. p. 14-16. sec. 3.1.5. doi:10.17487/RFC5536. RFC 5536.
- ↑ Kevin Fall (August 2003). "A Delay-Tolerant Network Architecture for Challenged Internets". Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications - SIGCOMM '03. 2003 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications. ACM SIGCOMM. pp. 27–34. doi:10.1145/863955.863960. ISBN 978-1-58113-735-4.
बाहरी संबंध
- Using & Managing UUCP. Ed Ravin, Tim O'Reilly, Dale Doughtery, and Grace Todino. 1996, O'Reilly & Associates, Inc. ISBN 1-56592-153-4
- Mark Horton (1986). RFC 976: UUCP Mail Interchange Format Standard. Internet Engineering Task Force Requests for Comment.
- Taylor UUCP Documentation – useful information about UUCP in general and various uucp protocols.
- The UUCP Project: History at the Wayback Machine (archived January 6, 2014)
