A .torrent file and a चुंबक link are two ways of giving a BitTorrent client the same thing: the identity of a torrent.
- एक .torrent फ़ाइल एक “मेटाइन्फो” फ़ाइल होती है। इसके सूचना शब्दकोश में टुकड़े की लंबाई, फ़ाइल का नाम और लंबाई (या फ़ाइलों की सूची) होती है, और v1 में प्रत्येक टुकड़े के लिए एक 20-बाइट SHA-1 हैश की एक संयुक्त सूची होती है। सूचना-हैश, एन्कोडेड सूचना मान का 20-बाइट SHA-1 होता है, जिसकी गणना .torrent फ़ाइल में दिखाई देने वाले एन्कोडेड रूप पर ठीक उसी तरह की जाती है। ट्रैकर URL उस शब्दकोश से बाहर होते हैं, इसलिए उन्हें टॉरेंट की पहचान बदले बिना बदला जा सकता है। BitTorrent v2 (BEP 52) हैशिंग को बदलता है: यह प्रति-फ़ाइल मर्कल ट्री और एक पदानुक्रमित फ़ाइल ट्री के साथ SHA-256 का उपयोग करता है। प्रति-फ़ाइल "टुकड़ा परतें" सूचना शब्दकोश से बाहर होती हैं, और कार्यान्वयन करना ही होगा उनकी तुलना इसके भीतर मौजूद मूल क्षेत्रों से करें। bep 0003 +2
- मैग्नेट लिंक में कोई मेटाडेटा नहीं होता, केवल उसकी पहचान होती है। इसका प्रारूप v1 के लिए magnet:?xt=urn:btih: या v2 के लिए xt=urn:btmh: है, जिसमें वैकल्पिक डिस्प्ले नाम (dn), ट्रैकर (tr) और पीयर-एड्रेस (x.pe) पैरामीटर शामिल हैं। एक हाइब्रिड टोरेंट एक ही लिंक में btih और btmh दोनों टॉपिक ले जा सकता है। शुरुआत में, क्लाइंट BEP 9 एक्सटेंशन का उपयोग करके अन्य पीयर्स से मेटाडेटा प्राप्त करता है। यह एक्सटेंशन .torrent फ़ाइल के केवल info-dictionary भाग को 16 KiB ब्लॉक में स्थानांतरित करता है। फिर क्लाइंट लिंक में मौजूद हैश के साथ इसकी जाँच करता है। यदि लिंक में कोई ट्रैकर नहीं है, तो क्लाइंट को पीयर्स को खोजने के लिए DHT का उपयोग करना चाहिए। bep 0009 +2
तो दोनों प्रारूप एक ही समूह की ओर इशारा करते हैं और डाउनलोड शुरू होने पर समान डाउनलोड परिणाम देते हैं। उनमें अंतर केवल मेटाडेटा के स्रोत में है:
एक .torrent फ़ाइल एक स्थिर कलाकृति है: फ़ाइल सूची तुरंत ज्ञात होती है, मेटाडेटा एक मृत स्वार्म से भी बचा रहता है, और फ़ाइल को कहीं न कहीं होस्ट किया जाना चाहिए।
मैग्नेट लिंक एक छोटी स्ट्रिंग होती है जिसे कहीं भी पेस्ट किया जा सकता है, लेकिन यह तभी काम करता है जब कम से कम एक पहुंच योग्य पीयर के पास मेटाडेटा मौजूद हो। दोनों में से कोई भी प्रारूप प्रकाशक की प्रामाणिकता की पुष्टि नहीं करता है और न ही यह साबित करता है कि सामग्री उसके लेबल से मेल खाती है। हैश केवल यह साबित करता है कि डेटा हैश से मेल खाता है।
बख्शीश: लोकप्रिय मांग पर, यह पोस्ट इंजीनियरिंग से संबंधित हमारी सभी टोरेंट और पी2पी पोस्टों के लिए एक सहायक के रूप में कार्य करती है।
इतिहास एवं पृष्ठभूमि
.torrent फॉर्मेट मूल BitTorrent डिज़ाइन से आया है। ब्रैम कोहेन ने अप्रैल 2001 में प्रोटोकॉल डिज़ाइन किया और 2 जुलाई 2001 को पहला संस्करण जारी किया। उन्होंने और अश्विन नवीन ने 2004 में BitTorrent, Inc. (बाद में Rainberry, Inc.) की स्थापना की। कोहेन को BEP 3 के लेखक के रूप में भी सूचीबद्ध किया गया है, जो मेटाइन्फो फ़ाइल और इन्फ़ो-हैश को परिभाषित करने वाला मुख्य विनिर्देश है। आगे का विकास BitTorrent Enhancement Proposal प्रक्रिया के माध्यम से समन्वित किया जाता है, जिसे Python के PEPs के मॉडल पर बनाया गया था, और कोहेन चाहते थे कि मुख्य क्लाइंट ओपन सोर्स रहे।
बीईपी 3 विनिर्देश औपचारिक प्राधिकरण के सबसे निकट है। फ़ाइल फ़ारमैटv2 प्रारूप बहुत बाद में आया: BitTorrent, Inc. ने 15 मई 2017 को v2 विनिर्देश जारी किया। मैग्नेट लिंक का इतिहास अलग है। magnet: योजना BitTorrent के लिए नहीं बनाई गई थी। इसे कई P2P नेटवर्कों में सामग्री हैश द्वारा फ़ाइलों की पहचान करने के लिए एक प्रोजेक्ट-तटस्थ तरीके के रूप में डिज़ाइन किया गया था। IANA इसे केवल एक अस्थायी योजना के रूप में सूचीबद्ध करता है, जिसे 2012 में Magnet-URI प्रोजेक्ट के निर्माता के रूप में पंजीकृत किया गया था। द्वितीयक स्रोत इसकी शुरुआत 2002 में बताते हैं, लेकिन मुझे उस तिथि का कोई प्राथमिक स्रोत नहीं मिला। BitTorrent द्वारा मैग्नेट लिंक का उपयोग BEP 9 पर आधारित है, जिसे ग्रेग हेज़ल और आर्विड नॉरबर्ग ने लिखा था (नॉरबर्ग libtorrent के मूल लेखक भी हैं)। बीईपी 9 अभी भी केवल "स्वीकृत" है, अंतिम नहीं, और इसमें 2016 में x.pe पीयर-एड्रेस पैरामीटर जोड़ा गया था। यह बीईपी मेटाडेटा-एक्सचेंज प्रोटोकॉल और बिटटोरेंट मैग्नेट प्रारूप दोनों को परिभाषित करता है, लेकिन एक कार्यान्वयनकर्ता के नोट्स में मैग्नेट यूआरआई को एक वास्तविक परंपरा के रूप में वर्णित किया गया है, न कि एक क्रमांकित बीईपी के रूप में।
व्यवहार में, दोनों प्रारूप बीईपी प्रक्रिया और प्रमुख ग्राहकों द्वारा लागू की गई प्रक्रियाओं पर आधारित हैं, न कि किसी औपचारिक पद्धति पर। मानकों शरीर।
1. बुनियादी बातें
| पहलू | ।धार फ़ाइल | चुंबक लिंक |
|---|---|---|
| यह क्या है | एक छोटी बाइनरी फ़ाइल (बी-कोडेड डिक्शनरी) | एक टेक्स्ट यूआरआई (magnet:?xt=urn:btih:…) |
| क्या इसमें सामग्री शामिल है? | नहीं, केवल मेटाडेटा | नहीं, केवल एक पहचानकर्ता |
| मुख्य विषय-सूची | ट्रैकर यूआरएल, फ़ाइल नाम और आकार, टुकड़े की लंबाई, प्रत्येक टुकड़े का हैश, वैकल्पिक टिप्पणी, निर्माता और तिथि | सूचना-हैश (xt), वैकल्पिक प्रदर्शन नाम (dn), ट्रैकर्स (tr), पीयर पते (x.pe); वेब सीड्स (ws) केवल क्लाइंट-निर्भर एक्सटेंशन के रूप में, BEP 9 में परिभाषित नहीं हैं। |
| सामान्य आकार | कुछ केबी से लेकर कई एमबी तक (सामग्री के आकार के साथ बढ़ता है) | लगभग 100-500 बाइट्स |
| प्रयुक्त पहचानकर्ता | SHA-1 सूचना-हैश (v1), SHA-256 (v2), या दोनों (हाइब्रिड) | वही सूचना-हैश: कलश:btih (v1) या urn:btmh (v2) |
| विनिर्देश | बीईपी 3 (v1), बीईपी 52 (v2) | बीईपी 9 (मेटाडेटा एक्सचेंज और मैग्नेट यूआरआई प्रारूप) |
| प्रोटोकॉल हैंडलर | फाइल एसोसिएशन (.torrent) द्वारा खोला गया | ऑपरेटिंग सिस्टम या ब्राउज़र मैग्नेट द्वारा खोला गया: यूआरआई हैंडलर |
2. मेटाडेटा और फ़ाइल जानकारी
| पहलू | ।धार फ़ाइल | चुंबक लिंक |
|---|---|---|
| डाउनलोड शुरू होने से पहले फ़ाइल सूची दिखाई देगी | जी हाँ, तुरंत | नहीं, केवल साथियों से मेटाडेटा प्राप्त होने के बाद ही। |
| मेटाडेटा स्रोत | फ़ाइल में एम्बेडेड | ut_metadata के माध्यम से पीयर्स (DHT, PEX, ट्रैकर्स) से डाउनलोड किया गया |
| मेटाडेटा अखंडता | हैशिंग द्वारा सत्यापित | लिंक में मौजूद इन्फो-हैश के आधार पर सत्यापन किया गया है, इसलिए छेड़छाड़ किए गए मेटाडेटा को अस्वीकार कर दिया गया है। |
| प्रारंभ विलंब | कोई नहीं | कुछ सेकंड से लेकर कुछ मिनट तक (या कभी नहीं, यदि किसी भी साथी के पास मेटाडेटा नहीं है) |
| प्रदर्शित होने वाला नाम | फ़ाइल (नाम) में संग्रहीत | dn वैकल्पिक और अपुष्ट है; यह केवल एक लेबल है। |
| टुकड़ा हैश | शामिल | मेटाडेटा के साथ बाद में प्राप्त किया गया |
| संपादन योग्य | ट्रैकर को हैश बदले बिना संपादित किया जा सकता है। इन्फो डिक्शनरी को संपादित करने से इन्फो-हैश बदल जाता है, जिससे एक अलग टॉरेंट बनता है। | टेक्स्ट के रूप में संपादित करना आसान है (ट्रैकर्स जोड़ना या हटाना)। अलग सामग्री को इंगित किए बिना सूचना-हैश को बदला नहीं जा सकता। |
3. लेखक, उत्पत्ति और प्रामाणिकता
| पहलू | ।धार फ़ाइल | चुंबक लिंक |
|---|---|---|
| लेखक की जानकारी | वैकल्पिक फ़ील्ड: निर्माता (क्लाइंट और संस्करण), निर्माण तिथि, टिप्पणी | कोई नहीं; कोई मानक लेखक फ़ील्ड नहीं है |
| निर्माता के बारे में मेटाडेटा का रिसाव | संभावित (क्लाइंट संस्करण, टाइमस्टैम्प, कभी-कभी टिप्पणियाँ या यूआरएल) | संक्षिप्त; लिंक में केवल वही जानकारी है जो साझाकर्ता ने शामिल की है। |
| अंगुली का हस्ताक्षर | हस्ताक्षर विस्तार (बीईपी 35) मौजूद है, लेकिन इसका उपयोग शायद ही कभी किया जाता है। | कोई नहीं |
| इस बात का प्रमाण कि सामग्री वही है जो लेबल पर लिखी है। | कोई नहीं, और नाम फर्जी हो सकता है | कोई नहीं, और डीएनए को नकली बनाया जा सकता है। |
| सामग्री के हैश से मेल खाने का प्रमाण दें | हां, प्रत्येक वस्तु की हैश सत्यापन की जाती है। | हां, मेटाडेटा के बाद प्रत्येक भाग का हैश सत्यापन किया जाता है। सत्यापन |
| विश्वास मॉडल | आप फाइल उपलब्ध कराने वाले पर भरोसा करते हैं, फिर हैश के आधार पर डेटा को सत्यापित करते हैं। | जिसने भी लिंक दिया है, उस पर आपको भरोसा है, तो उसी तरह से इसकी पुष्टि करें। |
| स्पूफिंग का जोखिम | एक ही शीर्षक वाले नकली टोरेंट आम हैं। | वही बात है, और लिंक में तो संदर्भ भी बहुत कम है (पहले जांच करने के लिए कोई फ़ाइल सूची नहीं है)। |
4. होस्टिंग, वितरण और उपलब्धता
| पहलू | ।धार फ़ाइल | चुंबक लिंक |
|---|---|---|
| होस्टिंग की आवश्यकता है | हां, एक वेब सर्वर, इंडेक्स साइट या फ़ाइल शेयर। | नहीं; यह केवल टेक्स्ट है और इसे कहीं भी पेस्ट किया जा सकता है। |
| साझा करने के तरीके | डाउनलोड, ईमेल अटैचमेंट, फ़ाइल ट्रांसफर (कभी-कभी अटैचमेंट ब्लॉक हो जाते हैं) | चैट, ईमेल बॉडी, क्यूआर कोड, फोरम पोस्ट, नोट्स ऐप |
| टेकडाउन एक्सपोजर | होस्ट की गई फ़ाइलों को हटाया या ब्लॉक किया जा सकता है। | इन्हें हटाना कठिन है (शुद्ध पाठ), लेकिन इन्हें प्रकाशित करने वाली साइटों को अभी भी अवरुद्ध किया जा सकता है। |
| लिंक रोट | यह फ़ाइल तब तक बनी रहती है जब तक होस्ट मौजूद रहता है। | पाठ तो सुरक्षित रहता है, लेकिन अगर किसी भी समकक्ष के पास मेटाडेटा न हो तो वह बेकार है। |
| संग्रहण मूल्य | उच्च: यह झुंड के मृत हो जाने पर भी संपूर्ण मेटाडेटा को संरक्षित रखता है। | कम: यह मेटाडेटा प्राप्त करने के लिए एक लाइव स्वार्म पर निर्भर करता है |
| अनुक्रमणिका और खोज साइटें | प्रत्येक टोरेंट के लिए एक फाइल स्टोर करना आवश्यक है (अधिक स्टोरेज की आवश्यकता होगी) | केवल एक छोटी सी डोरी ही रखें (यह सस्ती होती है और इसकी नकल करना आसान होता है)। |
| विभिन्न उपकरणों के साथ उपयोग में आसानी | फ़ाइल स्थानांतरण की आवश्यकता है | आसान तरीका: कॉपी और पेस्ट करें, या क्यूआर कोड स्कैन करें। |
| ब्राउज़र व्यवहार | एक फ़ाइल डाउनलोड करता है, फिर उसे क्लाइंट में खोलता है | प्रोटोकॉल हैंडलर प्रॉम्प्ट को ट्रिगर करता है (पंजीकृत क्लाइंट की आवश्यकता होती है) |
5. नेटवर्क व्यवहार और प्रदर्शन
| पहलू | ।धार फ़ाइल | चुंबक लिंक |
|---|---|---|
| सहकर्मी खोज | फाइल में सूचीबद्ध ट्रैकर्स, साथ ही डीएचटी, पीईएक्स और एलएसडी (जब तक कि वे निजी न हों) | लिंक में मौजूद DHT, PEX और LSD, साथ ही कोई भी tr ट्रैकर शामिल हैं। |
| यह बिना किसी ट्रैकर के काम करता है | केवल तभी जब डीएचटी की अनुमति हो। | हां, डीएचटी के साथ (यह इसका सामान्य रूप है) |
| डीएचटी पर निर्भरता | वैकल्पिक | मेटाडेटा और साथियों के लिए अक्सर आवश्यक होता है |
| वेब सीड्स (HTTP स्रोत) | यूआरएल-सूची / httpseeds फ़ील्ड (बीईपी 19) | ws= पैरामीटर, एक क्लाइंट-निर्भर एक्सटेंशन जो BEP 9 में परिभाषित नहीं है |
| एक बार चलने पर डाउनलोड गति | समान | |
| मृत या दुर्लभ टोरेंट के साथ व्यवहार | शुरू होता है और साथियों का इंतजार करता है | मेटाडेटा पुनर्प्राप्त करने में रुकावट आ सकती है |
| निजी ट्रैकर्स | पूरी तरह से समर्थित (घोषणा यूआरएल में निजी ध्वज, पासकी) | आम तौर पर अनुपयोगी। निजी टोरेंट DHT/PEX को निष्क्रिय कर देते हैं, और ट्रैकर पासकी साझा करने योग्य लिंक में उजागर नहीं होती है। |
6. सुरक्षा
| पहलू | ।धार फ़ाइल | चुंबक लिंक |
|---|---|---|
| मैलवेयर जोखिम का स्रोत | डाउनलोड की गई सामग्री, प्रारूप नहीं। | डाउनलोड की गई सामग्री, प्रारूप नहीं। |
| पार्सर या हैंडलर जोखिम | गलत तरीके से लिखा गया बेनकोड खराब तरीके से लिखे गए क्लाइंट में बग उत्पन्न कर सकता है (दुर्लभ)। | दुर्भावनापूर्ण डीएनएम या यूआरआई पैरामीटर खराब तरीके से लिखे गए क्लाइंट या हैंडलर में इंजेक्शन या डिस्प्ले बग का कारण बन सकते हैं (दुर्लभ)। |
| डाउनलोड करने से पहले जांच करने की क्षमता | उच्च स्तर: आप सबसे पहले फ़ाइल सूची, एक्सटेंशन और आकार देख सकते हैं। | मेटाडेटा आने तक लागत कम रहती है; अधिकांश क्लाइंट डाउनलोड करने से पहले आपको फ़ाइल सूची की समीक्षा करने देते हैं। |
| प्रच्छन्न निष्पादन योग्य | फ़ाइल सूची (.exe, .scr, .lnk इत्यादि) में इसका पता लगाया जा सकता है। | वही, लेकिन मेटाडेटा प्राप्त होने के बाद ही। |
| फ़िशिंग और विज्ञापन जोखिम | टोरेंट साइटें अक्सर विज्ञापनों से भरी होती हैं। | वही समस्या, साथ ही मिलते-जुलते मैग्नेट बटनों पर गलती से क्लिक हो जाना। |
| हैश शक्ति | v1 के लिए SHA-1 (सैद्धांतिक रूप से टकराव-कमजोर, टोरेंट के लिए शोषण करना मुश्किल); v2 के लिए SHA-256 | जिस टोरेंट की ओर यह इंगित करता है, उसका हैश भी समान है। |
| परिवहन के दौरान छेड़छाड़ | पीस हैश के माध्यम से पता लगाया गया | सूचना-हैश के माध्यम से इसका पता लगाया गया, हालांकि बदले हुए लिंक से पूरी तरह से अलग सामग्री प्राप्त होती है। |
7. निजता और गुमनामी
| पहलू | ।धार फ़ाइल | चुंबक लिंक |
|---|---|---|
| आपका आईपी अन्य लोगों को दिखाई देगा | हाँ | |
| आपका आईपी ट्रैकर्स को दिखाई दे रहा है | हां (एम्बेडेड ट्रैकर्स) | हां, अगर टीआर ट्रैकर्स शामिल हैं |
| डीएचटी एक्सपोजर | संभव | लगभग निश्चित; आपकी खोज सार्वजनिक डीएचटी में जाती है। |
| अनामता का अंतर | कोई अर्थहीन | |
| साझाकर्ता का खुलासा करने वाला मेटाडेटा | निर्माता, टिप्पणी और निर्माण तिथि से विवरण प्रकट हो सकते हैं। | लिंक टेक्स्ट में मौजूद जानकारी के अलावा और कुछ नहीं। |
| शमन | वीपीएन या प्रॉक्सी, क्लाइंट-साइड एन्क्रिप्शननिजी ट्रैकर्स | |
8. जोखिम और सीमाएँ
| जोखिम | ।धार फ़ाइल | चुंबक लिंक |
|---|---|---|
| अद्वितीय स्टॉल | साथियों का इंतजार करता है | मेटाडेटा कभी प्राप्त न हो सके |
| नकली या गलत लेबल वाली सामग्री | संभव | |
| कानूनी जोखिम | यह विषयवस्तु और अधिकार क्षेत्र पर निर्भर करता है। फ़ाइल को होस्ट करने से साइट संचालकों के लिए जोखिम बढ़ सकता है। | यह विषयवस्तु और अधिकार क्षेत्र पर निर्भर करता है। लिंक साझा करना कभी-कभी फ़ाइलों को होस्ट करने से अलग माना जाता है, लेकिन यह भिन्न-भिन्न होता है और सुरक्षित आश्रय स्थल नहीं है। |
| निजता का उल्लंघन | ट्रैकर और सहकर्मी दृश्यता | डीएचटी और सहकर्मी दृश्यता |
| ट्रैकर की मौत | इससे खोज की संभावना कम हो जाती है, लेकिन डीएचटी फिर भी काम कर सकता है। | अगर लिंक डीएचटी पर निर्भर करता है तो कोई समस्या नहीं है। |
| दीर्घकालिक स्थायित्व | बेहतर | ज़्यादा बुरा |
| टाइपो और संक्षिप्तीकरण | एक दूषित फ़ाइल का पता चला है | हैश में टाइपिंग की गलती किसी काम की नहीं होती, और अधूरा लिंक चुपचाप टूट जाता है। |
9. अनुकूलता और उपयोगिता
| पहलू | ।धार फ़ाइल | चुंबक लिंक |
|---|---|---|
| ग्राहक सहायता | सार्वभौमिक | आधुनिक ग्राहकों के लिए सार्वभौमिक (बीईपी 9 आवश्यक है) |
| सीडबॉक्स और वेब सेवाएं | सार्वभौमिक रूप से समर्थित | अधिकतर सेवाएं समर्थित हैं, हालांकि कुछ पुरानी सेवाएं केवल फ़ाइलें ही स्वीकार करती हैं। |
| मोबाइल अनुकूलता | मध्यम (डाउनलोड की गई फ़ाइलों को संभालना थोड़ा मुश्किल है) | उच्च |
| स्वचालन (आरएसएसस्क्रिप्ट, एपीआई) | सीधा | साथ ही, यह सरल है और इसे स्टोर करना भी आसान है। |
| मानव पठनीयता | बिना किसी उपकरण के इसे पढ़ा नहीं जा सकता | हैश अपारदर्शी है, लेकिन संरचना पठनीय है। |
10. .टोरेंट फ़ाइलें और मैग्नेट लिंक कैसे बनाएं
जिन वस्तुओं पर खंजर का निशान लगा है, वे मेरी अपनी तर्कशक्ति या सामान्य ज्ञान पर आधारित हैं, किसी स्रोत से पुष्टि नहीं की गई हैं।
| पहलू | ।धार फ़ाइल | चुंबक लिंक |
|---|---|---|
| प्रारंभिक इनपुट | आपकी वास्तविक फाइलें या फ़ोल्डर, साथ ही एक क्रिएटर टूल (उदाहरण के लिए mktorrent, या किसी क्लाइंट का "क्रिएट टोरेंट" फ़ंक्शन) | एक मौजूदा इन्फो-हैश। संस्करण 1 में यह bencoded इन्फो डिक्शनरी का SHA-1 है, इसलिए .torrent मेटाडेटा के अस्तित्व में आने से पहले मैग्नेट लिंक मौजूद नहीं हो सकता। |
| चरणों का क्रम | 1) टुकड़ों की लंबाई चुनें। 2) प्रत्येक टुकड़े को हैश करें। 3) सूचना शब्दकोश बनाएं। 4) ट्रैकर्स जैसे बाहरी फ़ील्ड जोड़ें। 5) बेनकोड करें और सहेजें। | 1) टॉरेंट फ़ाइल प्राप्त करें। 2) उसका इन्फ़ो-हैश लें। 3) xt कमांड का उपयोग करके URI लिखें। 4) चाहें तो dn, tr और x.pe जोड़ सकते हैं। |
| टुकड़े की लंबाई | आप इसे चुनते हैं। यह लगभग हमेशा दो की घात होती है, आमतौर पर 256 KiB। mktorrent डिफ़ॉल्ट रूप से 2^18 बाइट्स का उपयोग करता है और इसे -l कमांड से सेट किया जा सकता है। | कुछ नहीं; यह टोरेंट से विरासत में मिला है |
| हैशिंग कार्य | प्रत्येक बाइट को हैश किया जाता है: v1 के लिए SHA-1 टुकड़े, v2 के लिए SHA-256 प्रति-फ़ाइल मर्कल ट्री। डेटा के आकार के साथ समय बढ़ता है (डैगर), और mktorrent कई थ्रेड्स का उपयोग कर सकता है। | नगण्य: मौजूदा हैश से परे कुछ भी नहीं |
| ट्रैकर्स | घोषणा, या घोषणा-सूची। यह सूची सूचना अनुभाग के बाहर स्थित होती है; यदि मौजूद हो, तो संगत क्लाइंट घोषणा को अनदेखा कर देते हैं, और स्तरों को क्रम से आजमाया जाता है, जिसमें एक स्तर के भीतर URL को फेरबदल किया जाता है। | tr= URI में पैरामीटर। यदि कोई पैरामीटर नहीं दिया गया है, तो क्लाइंट को DHT का उपयोग करना चाहिए। |
| निजी ध्वज | इसे इंफो डिक्शनरी में private=1 डालकर सेट किया जाता है। अनुपालन करने वाले क्लाइंट केवल प्राइवेट ट्रैकर को ही सूचना देते हैं और केवल उन्हीं पीयर्स से कनेक्ट होते हैं जिन्हें यह लौटाता है। चूंकि यह इंफो के अंदर होता है, इसलिए यह इंफो-हैश (डैगर) को प्रभावित करता है। | लिंक में इसके लिए कोई फ़ील्ड नहीं है। यह फ़्लैग मेटाडेटा में मौजूद है, जिसे क्लाइंट इसे फ़ेच करने के बाद ही देख पाता है (डैगर)। |
| वेब सीड्स | BEP 19 के अनुसार, url-list को mktorrent -w के रूप में प्रदर्शित करता है। HTTP/FTP सर्वर एक स्थायी रूप से अनचोक्ड सीड के रूप में कार्य करता है। | ws= BEP 9 की पैरामीटर सूची का हिस्सा नहीं है। इसे क्लाइंट-निर्भर एक्सटेंशन के रूप में मानें। |
| वैकल्पिक वर्णनात्मक फ़ील्ड | टिप्पणी और निर्माण तिथि वैकल्पिक हैं। mktorrent टिप्पणी के लिए -c और तिथि को छोड़ने के लिए -d विकल्प प्रदान करता है। | केवल dn (प्रदर्शन नाम)। यह एक लेबल है और इसकी पुष्टि नहीं हुई है। |
| स्रोत टैग | mktorrent का -s कमांड info-hash में एक सोर्स स्ट्रिंग एम्बेड करता है, इसलिए अलग-अलग टैग वाली समान फ़ाइलों को अलग-अलग हैश और अलग स्वार्म मिलते हैं। | लागू नहीं |
| पहचान में क्या बदलाव आता है? | कोई भी आंतरिक जानकारी: नाम, टुकड़े की लंबाई, निजी ध्वज, स्रोत टैग, फ़ाइल सूची (डैगर) | xt बदलने से एक अलग टोरेंट का पता चलता है। dn, tr या x.pe बदलने से ऐसा नहीं होता। |
| हैश संस्करण चयन | निर्माण के समय v1 (SHA-1), v2 (SHA-256) या हाइब्रिड का चयन किया जाता है। | हाइब्रिड के लिए लिंक में btih, btmh, या दोनों होने चाहिए (BEP 9 एक ही मैग्नेट में दोनों विषयों की अनुमति देता है यदि वे एक ही हाइब्रिड टोरेंट का वर्णन करते हैं)। |
| हस्ताक्षर | BEP 35 फाइल में एम्बेडेड RSA हस्ताक्षरों की अनुमति देता है, वैकल्पिक रूप से X.509 प्रमाणपत्र के साथ, और प्रति टोरेंट कई हस्ताक्षरों की अनुमति देता है। इसका उपयोग शायद ही कभी किया जाता है (डैगर)। | BEP 9 में हस्ताक्षर फ़ील्ड परिभाषित नहीं है, इसलिए हस्ताक्षर करने के लिए कुछ भी नहीं है। |
| उत्पादन | एक बाइनरी फ़ाइल जिसका आकार KB से MB में होता है, जिसे आपको होस्ट करना होगा या भेजना होगा। | कुछ सौ बाइट्स की एक टेक्स्ट लाइन |
| इसे उपयोगी बनाना | फ़ाइल अपलोड करें और मूल डेटा के साथ क्लाइंट चलाएं ताकि आप सीडिंग कर सकें। | लाइन प्रकाशित करें और सीडिंग जारी रखें। यदि किसी पीयर के पास डेटा और मेटाडेटा नहीं है तो लिंक से कोई फायदा नहीं होगा। |
| सामान्य गलतियाँ | सामग्री के आकार के लिए गलत टुकड़ा आकार (डैगर); प्रकाशन से पहले निजी फ़्लैग को भूल जाना, क्योंकि इसे बाद में बदलने का मतलब एक नया हैश होगा (डैगर); गलत ट्रैकर जोड़ना | हैश में टाइपो या ट्रंकेशन, जिसके कारण लिंक चुपचाप कहीं भी इंगित नहीं करता (डैगर); गलत उपसर्ग (btih बनाम btmh); dn में अनएस्केप्ड विशेष वर्ण (डैगर) |
11. प्रत्येक का उपयोग करना
जिन वस्तुओं पर खंजर का निशान लगा है, वे मेरी अपनी तर्कशक्ति या सामान्य ज्ञान पर आधारित हैं, किसी स्रोत से पुष्टि नहीं की गई हैं।
| पहलू | ।धार फ़ाइल | चुंबक लिंक |
|---|---|---|
| आप इसे कैसे खोलते हैं | फ़ाइल एसोसिएशन के माध्यम से डबल-क्लिक करें, इसे क्लाइंट में ड्रैग करें, या "टोरेंट फ़ाइल जोड़ें" का उपयोग करें। | किसी मैग्नेट पर क्लिक करें: लिंक (इसके लिए एक पंजीकृत हैंडलर की आवश्यकता होती है), इसे किसी क्लाइंट में पेस्ट करें, या क्यूआर कोड स्कैन करें (डैगर) |
| ग्राहक सबसे पहले क्या करता है | यह बी-कोडेड मेटाजानकारी को पार्स करता है। | यह URI को पार्स करता है और इन्फो-हैश निकालता है। |
| मेटाडेटा कहाँ से आता है | पहले से ही फ़ाइल में मौजूद है | पीयर्स इन्फो डिक्शनरी (केवल .टोरेंट का वह भाग) को 16 KiB के ब्लॉक में BEP 9 एक्सटेंशन के माध्यम से भेजते हैं, और क्लाइंट इसे हैश के साथ जांचता है। |
| साथियों को खोजना | फ़ाइल से ट्रैकर्स, साथ ही DHT/PEX/LSD फ़ाइलें, यदि टोरेंट निजी न हो तो। निजी टोरेंट के लिए, DHT और PEX का उपयोग नहीं किया जाना चाहिए। | लिंक में ट्रैकर्स; यदि कोई नहीं है, तो डीएचटी |
| प्रारंभ विलंब | कोई नहीं | यह मेटाडेटा वाले किसी साथी के जवाब आने तक प्रतीक्षा करता है, इसलिए यह अनिश्चित काल तक रुका रह सकता है। |
| डाउनलोड करने से पहले फ़ाइलें चुनना | तुरंत | मेटाडेटा प्राप्त होने के बाद। कुछ क्लाइंट डाउनलोड करने से पहले फ़ाइल सूची का पूर्वावलोकन करने के लिए केवल मेटाडेटा ही प्राप्त कर सकते हैं। |
| प्रतिबद्धता जताने से पहले निरीक्षण करना | किसी भी पार्सर टूल के साथ ऑफ़लाइन पूर्ण निरीक्षण | मेटाडेटा प्राप्त होने तक यह संभव नहीं है |
| उनके बीच रूपांतरण | इन्फो-हैश की गणना करें और एक मैग्नेट लिंक (डैगर) लिखें। | प्राप्त मेटाडेटा को टॉरेंट के रूप में निर्यात और कैश किया जा सकता है, इसलिए उसी मैग्नेट को दोबारा मेटाडेटा डाउनलोड करने की आवश्यकता नहीं होती है। |
| निजी-ट्रैकर का उपयोग | यह काम करता है, क्योंकि फ़ाइल में ट्रैकर यूआरएल होता है, और क्लाइंट को खुद को उसी तक सीमित रखना होगा (बीईपी 27) | संभवतः अव्यावहारिक: लिंक में कोई सुरक्षा चिह्न नहीं है, और एक ट्रैकर यूआरएल में व्यक्तिगत जानकारी (खतरा) हो सकती है। बीईपी 27 में चुंबकों पर चर्चा नहीं की गई है। |
| संपादन | हैश को बदले बिना ट्रैकर्स जोड़ें या हटाएं, क्योंकि वे जानकारी अनुभाग से बाहर हैं। जानकारी संपादित करने से एक नया टोरेंट बनता है। | टेक्स्ट को स्वतंत्र रूप से संपादित करें; टेक्स्ट में बदलाव करने से टॉरेंट का प्रकार बदल जाता है। |
| प्रामाणिकता की जाँच करना | किसी विश्वसनीय प्रमाणपत्र के विरुद्ध BEP 35 हस्ताक्षर की पुष्टि करें। एक लाइब्रेरी का कहना है कि उसकी जाँच प्रमाणपत्र को स्वयं मान्य नहीं करती है। अन्यथा, फ़ाइल सूची की जाँच करें। | इस सूचना-हैश की तुलना किसी विश्वसनीय स्रोत से प्राप्त सूचना-हैश से करें; इसके अलावा कोई अन्य जानकारी उपलब्ध नहीं है। |
| स्वचालित अपडेट | BEP 39 क्रिएटर को इन्फो डिक्ट में अपडेट-यूआरएल डालने की अनुमति देता है, और क्लाइंट केवल तभी नए टॉरेंट को स्वचालित रूप से डाउनलोड करते हैं जब वे मूल निर्माता द्वारा हस्ताक्षरित हों। | कोई नहीं |
| आगे साझा करना | फ़ाइल भेजें या होस्ट करें | इस पंक्ति को कॉपी और पेस्ट करें |
| जब यह विफल हो जाता है | ट्रैकर निष्क्रिय है या कोई पीयर नहीं है: क्लाइंट प्रतीक्षा करता है। दूषित फ़ाइल अस्वीकार कर दी जाती है। | हैश में टाइपो या कोई पहुंच योग्य पीयर नहीं: मेटाडेटा पुनर्प्राप्त करने में अटक गया |
| वेब-सीड बचाव | वेब सीड वाली .torrent फ़ाइल बिना पीयर के भी काम करती है। मैग्नेट लिंक का कोई विकल्प नहीं है, क्योंकि न तो BEP 9 और न ही HTTP-सीडिंग BEP HTTP सीड से मेटाडेटा प्राप्त करने का कोई तरीका प्रदान करते हैं। | |
| डाउनलोड करने के बाद | उन्हीं फाइलों से सीडिंग जारी रखें | |
सारांश
टोरेंट फाइलें (.torrent) संग्रह करने, निजी ट्रैकर्स, पहले फ़ाइल सूची की समीक्षा करने और ऑफ़लाइन मेटाडेटा के लिए सबसे अच्छी होती हैं, जबकि मैग्नेट फाइलें त्वरित साझाकरण, क्यूआर कोड, ट्रैकर-स्वतंत्र वितरण और न्यूनतम होस्टिंग में उत्कृष्ट होती हैं।
दोनों में से कोई भी प्रारूप अपने आप में अधिक सुरक्षित नहीं है। दोनों ही क्रिप्टोग्राफिक रूप से डेटा की अखंडता की पुष्टि करते हैं, और न ही यह प्रमाणित करते हैं कि सामग्री किसने प्रकाशित की है या वह वास्तव में क्या है। वास्तविक सुरक्षा और कानूनी जोखिम सामग्री और उसके स्रोत से आता है, इसलिए संदिग्ध एक्सटेंशन के लिए फ़ाइल सूची की जाँच करें और लिंक कहाँ से प्राप्त हुआ है, इस बारे में सावधान रहें।
अक्सर पूछे जाने वाले प्रश्न
क्या बिटटोरेंट एक आईईटीएफ या आईएसओ मानक है, और .टोरेंट फाइलों और मैग्नेट लिंक की औपचारिक स्थिति क्या है?
नहीं। प्रोटोकॉल को बिटटोरेंट एन्हांसमेंट प्रपोज़ल्स (बीईपी) के माध्यम से निर्दिष्ट किया जाता है, जो पायथन के पीईपी पर आधारित एक प्रक्रिया है। बीईपी 3 मेटाइन्फो फॉर्मेट को परिभाषित करता है और बीईपी 52 v2 को परिभाषित करता है। बीईपी 9, जो मेटाडेटा एक्सचेंज और बिटटोरेंट मैग्नेट फॉर्मेट को कवर करता है, की स्थिति 'स्वीकृत' है, 'अंतिम' नहीं। मैग्नेट: स्कीम स्वयं केवल एक अस्थायी आईएएनए पंजीकरण है, जिसके निर्माता मैग्नेट-यूआरआई प्रोजेक्ट हैं। व्यवहार में, अंतरसंचालनीयता प्रमुख क्लाइंट लाइब्रेरी द्वारा परिभाषित की जाती है, इसलिए कई कार्यान्वयनों के साथ परीक्षण करें।
क्या इन्फो-हैश क्रिप्टोग्राफिक रूप से किसी टोरेंट को उसकी सामग्री से जोड़ता है?
हाँ, प्रत्यक्ष रूप से। v1 इन्फो-हैश, बी-एनकोडेड इन्फो डिक्शनरी का SHA-1 है, और उस डिक्शनरी में हर भाग का SHA-1 हैश होता है, इसलिए हैश डेटा को प्रमाणित करता है। लेकिन इसमें एक कमी यह है कि SHA-1 में टकराव प्रतिरोध क्षमता कम है: व्यावहारिक टकराव हो सकते हैं, इसलिए एक प्रकाशक जो टोरेंट के दोनों संस्करण बनाता है, वह एक ही हैश से दो पेलोड तैयार कर सकता है। मौजूदा टोरेंट पर सेकंड-प्रीइमेज हमले अभी भी संभव नहीं हैं। v2, SHA-256 का उपयोग करता है और इस समस्या को दूर करता है।
कौन से संपादन टोरेंट की पहचान बदलते हैं और कौन से नहीं?
इंफो डिक्शनरी के अंदर कुछ भी बदलने से इंफो-हैश बदल जाता है: नाम, फ़ाइल सूची, पीस की लंबाई, प्राइवेट फ़्लैग और सोर्स टैग, जैसे कि mktorrent का -s विकल्प। इसके बाहर के फ़ील्ड, जैसे कि announce और announce-list (BEP 12), को नया टॉरेंट बनाए बिना स्वतंत्र रूप से संपादित किया जा सकता है। मैग्नेट लिंक में, dn, tr और x.pe कभी भी पहचान को प्रभावित नहीं करते; केवल xt ही करता है। इंफो डिक्शनरी को बदलने से स्वार्म चुपचाप फोर्क हो जाता है, इसलिए इसे एक नया टॉरेंट प्रकाशित करने के रूप में मानें।
कोई क्लाइंट मैग्नेट लिंक के माध्यम से प्राप्त मेटाडेटा को कैसे प्रमाणित करता है?
पीयर BEP 9 ut_metadata एक्सटेंशन के माध्यम से 16 KiB ब्लॉक में सूचना शब्दकोश भेजते हैं, और क्लाइंट एकत्रित परिणाम को हैश करता है और लिंक से प्राप्त सूचना-हैश से उसकी तुलना करता है। जाली मेटाडेटा को अस्वीकार कर दिया जाता है जब तक कि हमलावर हैश को तोड़ न सके। यह लिंक के संबंध में अखंडता को सिद्ध करता है, सत्यता को नहीं। dn मान एक अपुष्ट लेबल है, और हैश से यह पता नहीं चलता कि सामग्री किसने प्रकाशित की या उसमें वास्तव में क्या है।
v1, v2 और हाइब्रिड टोरेंट के बीच व्यावहारिक अंतर क्या हैं?
v1 सूचना शब्दकोश में SHA-1 पीस हैश की एक सपाट सूची का उपयोग करता है। v2 (BEP 52) प्रति-फ़ाइल मर्कल ट्री और एक पदानुक्रमित फ़ाइल ट्री के साथ SHA-256 का उपयोग करता है। पीस लेयर सूचना शब्दकोश के बाहर स्थित होती हैं, और कार्यान्वयनकर्ताओं को इसकी जांच इसके भीतर मौजूद पीस रूट फ़ील्ड के साथ करनी चाहिए। एक हाइब्रिड टोरेंट दोनों संरचनाओं को वहन करता है और इसलिए इसमें दो सूचना-हैश होते हैं, और एक मैग्नेट लिंक btih और btmh दोनों विषयों को वहन कर सकता है। केवल v2 वाले टोरेंट प्रकाशित करने से पहले सुनिश्चित करें कि आपका क्लाइंट और टूलिंग v2 का समर्थन करते हैं।
क्या मैग्नेट लिंक तब डाउनलोड प्रक्रिया को शुरू कर सकता है जब कोई पीयर मौजूद न हो लेकिन एक HTTP वेब सीड मौजूद हो?
नहीं। बीईपी 9 केवल पीयर्स से मेटाडेटा प्राप्त करता है, और न तो बीईपी 9 और न ही HTTP-सीडिंग बीईपी (17, 19) HTTP सीड से मेटाडेटा प्राप्त करने का कोई तरीका परिभाषित करते हैं। वेब सीड वाली .टोरेंट फ़ाइल बिना किसी पीयर के भी काम करती है, क्योंकि मेटाडेटा पहले से ही फ़ाइल में मौजूद होता है। यदि आप उपलब्धता के लिए वेब सीड पर निर्भर हैं, तो केवल मैग्नेट लिंक के बजाय .टोरेंट फ़ाइल वितरित करें।
प्रत्येक प्रारूप मेरी गोपनीयता और नेटवर्क पहचान के बारे में क्या जानकारी उजागर करता है?
दोनों ही आपके आईपी पते को अन्य साथियों और आपके द्वारा घोषित किए गए किसी भी ट्रैकर के सामने उजागर करते हैं। मैग्नेट लिंक आमतौर पर सार्वजनिक डीएचटी पर निर्भर करते हैं, जो एक और लुकअप पथ जोड़ता है जहां आपका आईपी और सूचना-हैश दिखाई देते हैं। प्रोटोकॉल एन्क्रिप्शन ट्रैफ़िक को अस्पष्ट करता है लेकिन आपको गुमनाम नहीं बनाता। निजी टोरेंट (बीईपी 27) के लिए क्लाइंट को केवल निजी ट्रैकर का उपयोग करना आवश्यक है, इसलिए डीएचटी और पीईएक्स का उपयोग नहीं किया जाता है। गुमनामी की आवश्यकताओं के लिए, उचित नेटवर्क-स्तरीय निवारण के साथ एक खतरे के मॉडल का उपयोग करें, न कि प्रारूप विकल्प का।
टोरेंट के माध्यम से प्राप्त डेटा की अखंडता ही नहीं, बल्कि उसकी प्रामाणिकता को मैं कैसे सत्यापित करूँ?
डेटा सत्यापन केवल यह साबित करता है कि डेटा टोरेंट से मेल खाता है। प्रामाणिकता के लिए, एक स्वतंत्र विश्वसनीय चैनल के माध्यम से चेकसम या हस्ताक्षर (उदाहरण के लिए हस्ताक्षरित SHA-256 मैनिफेस्ट) प्राप्त करें और तैयार फ़ाइलों को इसके विरुद्ध सत्यापित करें। BEP 35 .torrent फ़ाइलों में एम्बेडेड RSA हस्ताक्षरों को परिभाषित करता है, जिसमें वैकल्पिक X.509 प्रमाणपत्र और कई हस्ताक्षरकर्ता शामिल हैं, लेकिन इसका उपयोग बहुत कम होता है, और इसे लागू करने वाली एक लाइब्रेरी बताती है कि इसका सत्यापन स्वयं प्रमाणपत्र को मान्य नहीं करता है। मैग्नेट लिंक में हस्ताक्षर करने की कोई व्यवस्था नहीं होती है।
टोरेंट बनाते समय मुझे फ़ाइल की लंबाई कैसे चुननी चाहिए?
यह मेटाडेटा के आकार और स्थानांतरण की सटीकता के बीच एक संतुलन है। BEP 3 के अनुसार, टुकड़ों की लंबाई लगभग हमेशा दो की घात होती है, आमतौर पर 256 KiB, जो mktorrent का डिफ़ॉल्ट भी है। v1 में, 256 KiB पर 100 GiB पेलोड में 409,600 टुकड़े होते हैं, इसलिए केवल टुकड़ों की स्ट्रिंग ही लगभग 8 MB की होती है। मैग्नेट क्लाइंट को शुरू होने से पहले लगभग 500 ब्लॉक में उस पूरे शब्दकोश को खींचना पड़ता है, इसलिए बड़े आकार का मेटाडेटा मैग्नेट की शुरुआत को धीमा कर देता है। बड़े टुकड़े मेटाडेटा को छोटा कर देते हैं, लेकिन विफल टुकड़े के बाद मरम्मत को जटिल बना देते हैं।
एक ही प्रकार के डेटा की दो धाराएँ अलग-अलग समूहों में क्यों पहुँच जाती हैं, और मैं इससे कैसे बच सकता हूँ?
क्योंकि इन्फो-हैश संपूर्ण इन्फो डिक्शनरी को कवर करता है। अलग-अलग नाम, फ़ाइल क्रम, टुकड़ों की लंबाई, निजी फ़्लैग या स्रोत टैग, बाइट-समान पेलोड के लिए भी अलग-अलग हैश उत्पन्न करते हैं। एक ही स्वार्म को बनाए रखने के लिए, अपनी रिलीज़ प्रक्रिया में टुकड़ों की लंबाई, नाम, फ़ाइल क्रम और फ़्लैग को मानकीकृत करें, और आर्टिफैक्ट के साथ इन्फो-हैश प्रकाशित करें। स्रोत टैग स्वार्म को अलग करने का एक जानबूझकर किया गया तरीका है, और mktorrent का -s विकल्प जानबूझकर हैश को बदलता है।
इन फॉर्मेट के लिए क्लाइंट या पार्सर लिखते समय मुख्य सुरक्षा संबंधी चिंताएं क्या हैं?
सभी इनपुट को अविश्वसनीय मानें। bencode को सख्ती से सत्यापित करें, मेटाडेटा का आकार सीमित करें (एक ओपन-सोर्स क्लाइंट 32 MB की सीमा लागू करता है), और डायरेक्टरी ट्रैवर्सल को रोकने के लिए मेटाडेटा से फ़ाइल पथों को सैनिटाइज़ करें। SSRF-शैली के दुरुपयोग को सीमित करने के लिए ट्रैकर्स और DHT द्वारा लौटाए गए निजी और लूपबैक पतों को फ़िल्टर करें, और कनेक्ट करने से पहले जांच लें कि ट्रैकर URL स्वीकार्य हैं या नहीं। dn को अविश्वसनीय टेक्स्ट के रूप में मानें, और अंतिम स्टोरेज में लिखने से पहले प्रत्येक हैश को सत्यापित करें।
मैं .torrent फ़ाइल से सही तरीके से इन्फो-हैश की गणना कैसे करूँ?
फ़ाइल में मौजूद जानकारी मान के सटीक बाइट स्पैन का पता लगाएं और उन बाइट्स को हैश करें: v1 के लिए SHA-1 या v2 के लिए SHA-256। BEP 3 इस बात पर ज़ोर देता है कि हैश फ़ाइल में मौजूद एन्कोडिंग पर आधारित होना चाहिए। डिक्शनरी को डिकोड और री-एन्कोड करना तभी सुरक्षित है जब डिकोडर ने इनपुट को पूरी तरह से मान्य किया हो, और एक उदार डिकोडर चुपचाप डेटा को सामान्य कर सकता है और एक अलग हैश उत्पन्न कर सकता है। हाइब्रिड टॉरेंट्स के लिए, दोनों हैश एक ही स्पैन से गणना करें।
क्या मैं प्राइवेट ट्रैकर टॉरेंट के लिए मैग्नेट लिंक का उपयोग कर सकता हूँ?
अक्सर व्यवहारिक रूप से नहीं। BEP 27 के अनुसार, क्लाइंट को केवल निजी ट्रैकर को ही घोषणा करनी होती है और केवल उन्हीं पीयर्स से कनेक्ट करना होता है जिन्हें यह ट्रैकर लौटाता है। एक साधारण मैग्नेट लिंक में कोई निजी फ़्लैग नहीं होता, क्योंकि वह मेटाडेटा में होता है, और इसमें उपयोगी ट्रैकर URL शामिल नहीं हो सकता है। यदि क्रेडेंशियल्स के साथ कोई ट्रैकर URL एम्बेडेड है, तो लिंक को गुप्त मानें। यह मेरा अनुमान विनिर्देश से है, क्योंकि BEP 27 सीधे मैग्नेट लिंक को संबोधित नहीं करता है, इसलिए इसे अपने ट्रैकर के नियमों के साथ जांच लें।
किसी पाइपलाइन में सॉफ्टवेयर, डेटासेट या आर्काइव वितरित करने के लिए, क्या मुझे .torrent फ़ाइल प्रकाशित करनी चाहिए या मैग्नेट लिंक?
दोनों फ़ाइलों को प्रकाशित करें, जिसमें .torrent फ़ाइल को मुख्य फ़ाइल के रूप में रखें। इससे संपूर्ण मेटाडेटा सुरक्षित रहता है, उपयोगकर्ता ऑफ़लाइन फ़ाइल सूची देख सकते हैं, और उपलब्धता के लिए वेब सीडिंग (BEP 19) का समर्थन मिलता है। सुविधा के लिए, मैग्नेट लिंक को उसी इन्फ़ो-हैश से प्राप्त करें, और इन्फ़ो-हैश के साथ एक हस्ताक्षरित चेकसम को एक विश्वसनीय चैनल पर प्रकाशित करें। इससे संग्रहणीय स्थायित्व और आसान साझाकरण सुनिश्चित होता है, और मेटाडेटा पुनर्प्राप्ति साथियों पर निर्भर नहीं करती।
किसी टोरेंट के कितने समय तक उपलब्ध रहने का निर्धारण किस आधार पर होता है, और मैं इसे कैसे बेहतर बना सकता हूँ?
डेटा को पुनः प्राप्त करने के लिए कम से कम एक पहुंच योग्य पीयर का होना आवश्यक है जिसमें डेटा मौजूद हो, और मैग्नेट लिंक के मामले में मेटाडेटा रखने वाला एक पीयर भी होना चाहिए। इसे बेहतर बनाने के लिए सीडर्स को चालू रखें, बैकअप के रूप में कई ट्रैकर्स को अलग-अलग स्तरों (BEP 12) में जोड़ें, HTTP वेब सीड्स जोड़ें, और .torrent फ़ाइल को आर्काइव करके रखें या उन क्लाइंट्स से निर्यात करने योग्य बनाएं जो फ़ेच किए गए मेटाडेटा को कैश करते हैं। केवल मैग्नेट लिंक से कुछ भी सुरक्षित नहीं रहता, इसलिए निष्क्रिय स्वार्म इसे बेकार कर देता है।
संबंधित पठन सामग्री और विषयों की विस्तृत सूची
- बेनकोडिंग: .torrent फ़ाइलों द्वारा उपयोग किया जाने वाला सीरियलाइज़ेशन प्रारूप, क्रमबद्ध शब्दकोश कुंजियों के साथ
- घपले की जानकारी: बीएनकोडेड सूचना शब्दकोश का SHA-1 (v1) या SHA-256 (v2) डाइजेस्ट, टोरेंट की पहचान
- सामग्री-संबोधित संग्रहण: डेटा को उसके स्थान के बजाय उसके हैश द्वारा पहचानना
- मर्कल वृक्ष: बिटटोरेंट v2 (BEP 52) में प्रति-फ़ाइल हैश ट्री का उपयोग करके खंड-स्तरीय सत्यापन किया जाता है।
- हाइब्रिड टोरेंट: एकल टोरेंट जिसमें v1 और v2 संरचनाएं और दो सूचना-हैश दोनों शामिल हैं
- टुकड़े की लंबाई और टुकड़ों की परतें: मेटाडेटा के आकार और सत्यापन की सटीकता के बीच संतुलन
- SHA-1 टकराव प्रतिरोध: v1 हैशिंग सैद्धांतिक रूप से कमजोर क्यों है और v2 SHA-256 की ओर क्यों बढ़ता है?
- एक्सटेंशन प्रोटोकॉल (बीईपी 10): वह हैंडशेक तंत्र जो ut_metadata, PEX और अन्य एक्सटेंशन को सक्षम बनाता है
- मेटाडेटा विनिमय (बीईपी 9, यूटी_मेटाडेटा): पीयर्स से इन्फो डिक्शनरी को 16 किबी ब्लॉक में फ़ेच करना
- मैग्नेट यूआरआई योजना: एक परियोजना-तटस्थ, हैश-आधारित पहचानकर्ता योजना, जिसका IANA में अस्थायी पंजीकरण है।
- मैग्मा (चुंबक का प्रकटीकरण): चुंबक योजना की बहु-नेटवर्क उत्पत्ति से प्रकट-विषय अवधारणा
- मैग्नेट फाइल चयन (बीईपी 53): लिंक से ही टोरेंट के अंदर विशिष्ट फ़ाइलों का चयन करना
- मल्टीट्रैकर मेटाडेटा (बीईपी 12): घोषणा सूची स्तरों में फेरबदल और फ़ेलओवर की सुविधा
- UDP ट्रैकर प्रोटोकॉल (बीईपी 15): यूडीपी पर लाइटवेट ट्रैकर की घोषणा
- कॉम्पैक्ट पीयर लिस्ट (बीईपी 23): ट्रैकर प्रतिक्रियाओं में साथियों का कॉम्पैक्ट बाइनरी एन्कोडिंग
- आईपीवी6 ट्रैकर एक्सटेंशन (बीईपी 7): IPv6 के लिए peers6 समर्थन की घोषणा की गई
- ट्रैकर बाह्य आईपी रिपोर्टिंग (बीईपी 24): ट्रैकर ग्राहकों को उनके देखे गए पते की जानकारी देते हैं।
- मेनलाइन डीएचटी (बीईपी 5): ट्रैकर रहित पीयर डिस्कवरी के लिए कैडेमलिया-आधारित वितरित हैश टेबल
- डीएचटी सुरक्षा विस्तार (बीईपी 42): सिबिल और राउटिंग टेबल हमलों से बचाव के लिए नोड आईडी को प्रतिबंधित करना
- डीएचटी पुट/गेट और इन्फोहैश इंडेक्सिंग (बीईपी 44, बीईपी 51): डीएचटी में डेटा और सैंपलिंग इन्फो-हैश को स्टोर करना
- पीयर एक्सचेंज, पीईएक्स (बीईपी 11): स्वार्म सदस्य सीधे पीयर सूचियों को साझा करते हैं
- स्थानीय सेवा खोज (बीईपी 14): एक ही नेटवर्क सेगमेंट पर साथियों को ढूंढना
- तीव्र विस्तार (बीईपी 6): प्रोटोकॉल शॉर्टकट जैसे कि have-all, have-none और reject
- यूटीपी (बीईपी 29): विलंब-आधारित भीड़ नियंत्रण के साथ यूडीपी-आधारित परिवहन
- होलपंच एक्सटेंशन (बीईपी 55): रिलेइंग पीयर्स के माध्यम से समन्वित एनएटी ट्रैवर्सल
- संदेश स्ट्रीम एन्क्रिप्शन (एमएसई/पीई): प्रोटोकॉल को अस्पष्ट करना, गुमनामी नहीं।
- निजी टोरेंट (बीईपी 27): ट्रैकर तक पीयर डिस्कवरी को प्रतिबंधित करने वाला निजी फ़्लैग
- वेब सीडिंग (बीईपी 17, बीईपी 19): HTTP या FTP सर्वर स्थायी सीड के रूप में कार्य करते हैं
- पैडिंग फाइलें (बीईपी 47): डुप्लिकेशन हटाने और हाइब्रिड समर्थन के लिए फ़ाइलों को टुकड़ों की सीमाओं के साथ संरेखित करना
- स्थानीय डेटा संकेत (बीईपी 38): पुनः डाउनलोड से बचने के लिए संबंधित टोरेंट से डेटा का पुन: उपयोग करना
- टोरेंट साइनिंग (बीईपी 35): वैकल्पिक X.509 प्रमाणपत्रों के साथ एम्बेडेड RSA हस्ताक्षर
- टोरेंट अपडेट फ़ीड (बीईपी 39): हस्ताक्षरित, स्वचालित उत्तराधिकारी टोरेंट के लिए अपडेट-यूआरएल
- भाग सत्यापन पाइपलाइन: कमिट करने से पहले हैश चेक और विफल हुए हिस्सों से रिकवरी
- पार्सर और क्लाइंट सुरक्षा में सुधार: सख्त बेन्कोड सत्यापनसाइज कैप, पाथ सैनिटाइजेशन, एसएसआरएफ फ़िल्टरिंग
- वेबटोरेंट और वेबआरटीसी: ब्राउज़र-आधारित पीयर्स जो ws/wss ट्रैकर्स और ICE या TURN का उपयोग करते हैं
- बीज बोने के डिब्बे और दीर्घकालिक बीज बोना: उपलब्धता और अभिलेखीय स्थायित्व के लिए अवसंरचना
- बीईपी प्रक्रिया और शासन: विनिर्देशों को कैसे प्रस्तावित किया जाता है, अनुक्रमित किया जाता है और स्वीकृत से अंतिम रूप में पदोन्नत किया जाता है।
- वैकल्पिक विषयवस्तु-आधारित प्रणालियाँ: IPFS-शैली के सामग्री पहचानकर्ताओं को एक तुलनीय मॉडल के रूप में उपयोग करना।
- उत्पत्ति बनाम अखंडता: हैश डेटा को सत्यापित क्यों करते हैं लेकिन प्रकाशक को कभी प्रमाणित क्यों नहीं करते?
टोरेंट पर बाहरी लिंक
(सामग्री का हमारा विवरण देखने के लिए लिंक पर होवर करें)
