- Gnutella अब लगभग भुला दिया गया फ़ाइल-शेयरिंग प्रोटोकॉल है, लेकिन यह एक वास्तविक उदाहरण था जिसमें विकेंद्रीकृत तकनीक को समझे बिना लाखों उपयोगकर्ताओं ने MP3 डाउनलोड की समस्या हल की
- 2000–2001 के दौरान अमेरिका में इंटरनेट प्रसार 50% तक पहुँचा, सस्ते MP3 players, स्ट्रीमिंग की सीमाएँ, और फ़ाइलों को सीधे संभालने की संस्कृति ने इसके अपनाने को बढ़ावा दिया
- सर्वर-रहित संरचना और single point of failure की अनुपस्थिति के कारण AOL द्वारा रद्द किए जाने के बाद भी इसे वापस लेना कठिन था, और वर्षों तक इसे बंद करने की कोशिशों के बावजूद यह चलता रहा
- इसकी बुनियादी संरचना HTTP फ़ाइल ट्रांसफ़र और TCP gossip protocol के संयोजन पर आधारित है, जहाँ PING/PONG, QUERY/QUERYHIT, और PUSH खोज, प्रतिक्रिया और फ़ायरवॉल बायपास का काम संभालते हैं
- यह मुख्यधारा से इसलिए गायब नहीं हुआ कि तकनीक तुरंत विफल हो गई, बल्कि इसलिए कि उस समय का user environment ही खत्म हो गया; नेटवर्क आज भी छोटे पैमाने पर जीवित है
Gnutella के लंबे समय तक जीवित रहने की वजह
- Gnutella एक ऐसा फ़ाइल-शेयरिंग प्रोटोकॉल है जिसे बहुत लोग भूल चुके हैं, लेकिन यह उस स्थिति का उदाहरण है जहाँ विकेंद्रीकृत तकनीक को समझने की कोशिश भी न करने वाले आम उपयोगकर्ताओं के लाखों समूह ने वास्तविक समस्या हल करने के लिए इसका उपयोग किया
- उपयोगकर्ता token value बढ़ने जैसी प्रेरणा से नहीं, बल्कि MP3 download के लिए Gnutella नेटवर्क में शामिल हुए; नेटवर्क तेज़ी से बढ़ा, लगभग 10 साल तक स्थिर दौर में रहा, और बाद में कम उपयोग के साथ लंबे tail के रूप में बना रहा
- Gnutella, LimeWire जैसे अधिक दिखने वाले प्रोजेक्ट्स के नीचे छिपी आधारभूत तकनीक थी, और आधुनिक प्लेटफ़ॉर्म के walled garden मॉडल के कारण आज ऐसे इंटरनेट उपयोगकर्ता भी बहुत हैं जिन्हें फ़ाइलसिस्टम की याद तक नहीं है
- Gnutella प्रोजेक्ट की शुरुआत AOL द्वारा रद्द किए गए एक internal demo के सार्वजनिक रूप से लीक हो जाने से हुई, और इसकी serverless decentralized design के कारण एक बार सार्वजनिक होने के बाद इसे वापस लेना मुश्किल था
- बंद करने की कोशिशों के बावजूद Gnutella वर्षों तक चलता रहा, और मूल
Gnutella.exe की कॉपी archive.org पर अब भी मिल सकती है
- इसे विफल प्रोटोकॉल मानना मुश्किल है, इसके स्पष्ट कारण हैं
- यह लाखों concurrent active users तक scale हुआ और लगभग 10 साल तक mainstream use case के रूप में फलता-फूलता रहा
- यह मुख्यधारा से इसलिए गायब नहीं हुआ कि प्रोटोकॉल खुद तुरंत विफल हो गया, बल्कि इसलिए कि Gnutella जिस user environment में पैदा हुआ था, वह ही खत्म हो गया
- आज भी यह छोटे पैमाने पर चलता है
अपनाने को संभव बनाने वाली ऐतिहासिक परिस्थितियाँ
- 2000–2001 के आसपास अमेरिकी उपभोक्ताओं में इंटरनेट प्रसार 50% तक पहुँच गया था, और इंटरनेट एक niche tool से रोज़मर्रा के बुनियादी माध्यम में बदल रहा था
- म्यूज़िक फ़ाइल शेयरिंग आम होने के पीछे कई स्थितियाँ एक साथ काम कर रही थीं
- संगीत उद्योग बदलती उपभोक्ता पसंद के हिसाब से खुद को ढाल नहीं पाया
- MP3 players और solid-state storage सस्ते और व्यापक हो रहे थे
- धीमे dial-up इंटरनेट पर म्यूज़िक स्ट्रीमिंग व्यावहारिक नहीं थी
- disk space, directories, backup, और डाउनलोड की गई फ़ाइलों को सीधे manage करना उस समय आम कंप्यूटर उपयोगकर्ताओं के लिए भी स्वीकार्य था
- इन परिस्थितियों ने 2010s की शुरुआत तक जारी रहने वाले फ़ाइल-शेयरिंग के golden age को जन्म दिया, और LimeWire उस दौर के अनुभव का प्रतिनिधि नाम बन गया
- Gnutella में single point of failure नहीं था, इसलिए इसे खत्म करना मुश्किल था, और इसका base protocol सरल था, लेकिन spec में शामिल optional extensions की वजह से इसे आसानी से बढ़ाया जा सकता था
प्रोटोकॉल का बुनियादी स्वभाव
- ज़्यादातर उपयोगकर्ताओं के लिए Gnutella एक फ़ाइल ट्रांसफ़र टूल था, लेकिन मूल रूप से यह blob ढूँढने वाला P2P search engine ज़्यादा था
- सिद्धांत रूप से इसे एक simple DNS, global key/value metadata lookup table, या Unreal Tournament league matching service जैसी चीज़ों के लिए भी इस्तेमाल किया जा सकता था, लेकिन वास्तविक इतिहास में इसे search term से मेल खाने वाली फ़ाइलें, खासकर MP3, डाउनलोड करने के लिए ही याद किया जाता है
- Gnutella 0.6 draft spec कहती है कि share किए जाने वाले resources कुछ भी हो सकते हैं: दूसरे resources का mapping, encryption keys, किसी भी format की files, या key-addressable resources का metadata
- सामान्य उपयोग प्रवाह कुछ ऐसा था
- LimeWire, BearShare, GTK-Gnutella जैसे Gnutella clients चलाए जाते थे
- client इंटरनेट पर कहीं मौजूद कुछ peers से connect करता था
- उपयोगकर्ता
LinkinPark.mp3.exe जैसे search terms दर्ज करता था
- query peer से peer की ओर नेटवर्क के बाहरी हिस्सों तक फैलती थी
- दुनिया भर के random computers से results धीरे-धीरे वापस आते थे
- उपयोगकर्ता फ़ाइलनाम देखकर नकली होने का अंदाज़ा लगाता, connection speed की तुलना करता, और उम्मीद करता कि वायरस न हो
- फ़ाइल चुनने पर client उपयोगकर्ता के कंप्यूटर पर HTTP के जरिए सीधे उसके टुकड़े डाउनलोड करता
- गलत फ़ाइल मिलते-मिलते कभी नया content संयोग से मिल जाता था या malware भी आ सकता था, और इस तरह का exploratory foraging behavior recommendation engines के आने के साथ गायब हो गया
- client आम तौर पर चार मुख्य functions देता था
- query manager: हज़ारों peers में धीरे-धीरे फैलने वाली search को संभालता था
- file manager: share करने वाली directories या paths, और downloaded files को कहाँ save करना है, यह तय करता था
- transfer manager: दो-तरफ़ा फ़ाइल ट्रांसफ़र का resume, splitting, और management संभालता था
- additional features: IRC chat, bulletin boards, search query monitoring, और specific host browsing जैसी सुविधाएँ, लेकिन इनमें से कई प्रोटोकॉल का हिस्सा नहीं थीं
- Gnutella ecosystem में LimeWire जैसा market leader था, लेकिन कई clients साथ मौजूद थे, और independent developers चाहें तो शुरू से अपना client लिख सकते थे
- Gnutella Bun Client को implement करते समय यह सामने आया कि spec में न लिखी गई बातें, undocumented features, और अलग-अलग अतिरिक्त specs में बिखरी सुविधाएँ बहुत थीं; प्रोटोकॉल organic तरीके से evolve हुआ
HTTP और gossip protocol का संयोजन
- अगर किसी personal computer पर HTTP server चलाकर उसका IP address बता दिया जाए, तो फ़ाइल शेयरिंग संभव लगती है, लेकिन आज NAT, firewall, और home ISP policies के कारण inbound TCP ports सार्वजनिक करना कठिन है
- 20 साल पहले local machine पर छोटा HTTP server चलाकर उसे public IP पर expose करना आज की तुलना में कहीं अधिक सामान्य और संभव था
- Gnutella ने इसी माहौल का उपयोग किया, ताकि gossip करने वाले peers के mesh के भीतर हर participant फ़ाइल host कर सके
- LimeWire से फ़ाइल डाउनलोड करने का transfer चरण
curl या wget से फ़ाइल लेने जैसा था
- लेकिन केवल HTTP server होने से P2P file-sharing network नहीं बनता
- उस समय भी ISP अक्सर stable static IP नहीं देते थे
- आज share किया गया IP address कल बदल सकता था
http://74.6.231.21:4000 जैसी random URL शायद किसी search engine में indexed नहीं होती, और laptop बंद होते ही offline हो जाती
- Gnutella client HTTP server के साथ TCP-based gossip protocol भी चलाता था
- वह दूसरे Gnutella participants को, shared directory को HTTP पर serve करने वाले peers के mesh के भीतर, अपने अस्तित्व की सूचना देता था
- peer address, bandwidth, latency, और search queries जैसी जानकारी mesh के भीतर संदेशों के रूप में चलती थी
- firewall से निपटने के कुछ tools थे, लेकिन modern NAT समस्याओं के लिए बाद में extensions की ज़रूरत पड़ी
- Gnutella node की तीन बुनियादी भूमिकाएँ थीं
- local HTTP server से चाहने वालों को फ़ाइल देना
- gossip messages के जरिए उपलब्ध फ़ाइलों की खोज और घोषणा करना
- ज़रूरत पड़ने पर firewall bypass techniques का उपयोग करना
- Gnutella में कोई central entry point या user registry नहीं थी, इसलिए mesh के भीतर आने के बाद नए peers, inbound search queries, और बाकी network traffic दिखने लगते थे
Bootstrapping
- bootstrapping वह प्रक्रिया है जिसमें बिना निमंत्रण और बिना मुख्य द्वार वाले P2P mesh में पहली बार प्रवेश करने के लिए शुरुआती peers ढूँढे जाते हैं
- Gnutella का global network participant IP addresses का एक मिश्रण है, और main network से जुड़े किसी एक विश्वसनीय peer से connect करते ही बड़े user set का network traffic दिखने लगता है
- समय के साथ PONG messages के जरिए और peers मिलते जाते हैं, और peer list दोबारा connect होने के लिए disk पर save की जाती है
- IP address बदलने या offline हो जाने के कारण saved peer list समय के साथ आंशिक रूप से विफल हो जाती है, इसलिए client valid peer मिलने तक सूची के पते आज़माता रहता है
- पहली बार network में शामिल होने पर, या लंबे समय बाद वापस आने पर, केवल saved list काफ़ी नहीं हो सकती, इसलिए bootstrapping की ज़रूरत पड़ती है
- इसका सबसे आम तरीका Gnutella Web Cache (GWebCache) है
- यह volunteers द्वारा चलाए जाने वाले स्वतंत्र web servers का federation है, आमतौर पर CGI या PHP scripts के रूप में छोटे web applications
- यह स्वेच्छा से जानकारी देने वाले Gnutella participants के IP addresses रिकॉर्ड करता है
- मौजूदा server बंद हो जाए तो काम आएँ, इसके लिए दूसरे GWebCache servers के IP या domains भी रिकॉर्ड करता है
- यह alternative GWebCache servers की सूची देता है
- यह वर्तमान में ज्ञात Gnutella network participants के IP addresses की सूची देता है
- कुछ Gnutella clients cache servers तक अपने आप पहुँचते थे, और कुछ में IP को config file या settings menu में manually डालना पड़ता था
- शुरुआती peers से connect होने के बाद network messages के भीतर से और peers अप्रत्यक्ष रूप से मिलने लगते थे, इसलिए cache पर निर्भरता कम हो जाती थी
- GWebCache कोई central bottleneck नहीं था
- कई एक-दूसरे से असंबंधित GWebCache servers मौजूद थे
- GWebCache के बिना भी client को bootstrap करने के कई तरीके थे
- GWebCache न हो तब भी Gnutella कम सुविधाजनक रूप में जीवित रह सकता था
- bootstrap list request का उदाहरण इस प्रकार है
- URL के अंत में
?get=1&client=TEST&version=1 जोड़ने पर सूची मिल सकती है, लेकिन बहुत ज़्यादा requests करने पर जल्दी rate limit लग जाती है
http://cache.jayl.de/g2/gwc.php
http://gweb.4octets.co.uk/skulls.php
http://midian.jayl.de/g2/bazooka.php
http://p2p.findclan.net/skulls.php
http://skulls.gwc.dyslexicfish.net/skulls.php
- output का उदाहरण इस प्रकार है
H|106.107.193.27:23459|88579
H|182.233.59.26:23464|88581
U|http://bj.ddns.net/skulls/skulls.php|208999
U|http://scissors.gwc.dyslexicfish.net:3709/|341201
H से शुरू होने वाली entries peers हैं, और U से शुरू होने वाली entries duplicate cache servers हैं जिन्हें बाद में इस्तेमाल किया जा सकता है
मुख्य message types
- Gnutella एक TCP-based protocol है, और inbound connections लेने वाले peer से connect करने पर पहले handshake होता है
- client
GNUTELLA CONNECT/0.4 या GNUTELLA CONNECT/0.6 भेजता है, और सामने वाला positive response भेज दे तो connection स्थापित हो जाता है और binary Gnutella messages बहने लगते हैं
- हर binary message 23-byte header से शुरू होता है
- header में message ID, payload type, TTL, hop count, और payload length शामिल होती है
- TTL message का बचा हुआ जीवन है, और hop count वह दूरी है जो यह तय कर चुका है
TTL + Hops बताता है कि message की मूल intended reach क्या थी
- असल में पाँच message types सबसे महत्वपूर्ण हैं
- PING: जीवित peers को खोजता है, payload type
0x00
- PONG: PING का जवाब, जिसमें IP address, port, और sharing stats होते हैं, payload type
0x01
- QUERY: user द्वारा शुरू की गई या आसपास के peer से आई search request, payload type
0x80
- QUERYHIT: QUERY का positive response, जिसमें file result records और download connection info होती है, payload type
0x81
- PUSH: firewall के पीछे मौजूद uploader के लिए workaround, जो file holder से downloader की तरफ़ वापस connect करने को कहता है, payload type
0x40
BYE message भी है, लेकिन यह सख़्ती से आवश्यक नहीं है- protocol messages extension data fields को support करते हैं, ताकि clients पूरे network को तोड़े बिना नई features जोड़ सकें
- GTK-Gnutella छोटे core protocol में मूल रूप से न होने वाले TLS, IPv6, और UDP जैसी सुविधाओं को support करता है
प्रोटोकॉल विस्तार
- संभव है कि केवल पाँच message types implement करके काम करने वाला Gnutella client बनाया जा सके, लेकिन spec लगभग 30 साल पुरानी है और ecosystem रुका नहीं है
- Gnutella ने पुराने packets के भीतर नए ideas जोड़ने की जगह छोड़ी थी
- GGEP (Gnutella Generic Extension Protocol) सामान्य messages के भीतर extension data रखने की एक generic space देता है
- HUGE (Hash/URN Gnutella Extensions) clients को केवल filename से खोजने के बजाय SHA hash के आधार पर files की पहचान करने देता है
- XML extension payload support का ज़िक्र मिलता है, लेकिन spec इसे भूतकाल की चीज़ की तरह लेती है और आधुनिक network traffic में यह दिखाई नहीं देता
- मूल design छोटी थी, लेकिन उसमें लगातार बढ़ते रहने की पर्याप्त flexibility थी
खोज और ट्रांसफ़र कैसे काम करते थे
- PING/PONG messages nodes के बीच heartbeat की तरह काम करते थे
- PING में सामान्य 23-byte header के अलावा कोई mandatory payload नहीं होती, लेकिन optional GGEP extension data हो सकती है
- PONG में जवाब देने वाले servent का port, IPv4 address, shared files की संख्या, और shared kilobytes की संख्या होती है
- nodes PONG से मिले IP/port को इकट्ठा करके mesh के भीतर बेहतर connected members बनते हैं, और बाद के sessions के लिए इसे save कर लेते हैं
- QUERY/QUERYHIT PING/PONG की तरह काम करते हैं, लेकिन peer advertisement के बजाय search traffic ले जाते हैं
- QUERY में minimum speed यानी transfer bandwidth field होती है, और उसके बाद NUL-terminated search string आती है
- उदाहरण:
beethoven.mp3
- QUERY messages sender से बाहर की ओर flood की तरह फैलते हैं, और QUERYHIT messages result होने पर वापस sender की ओर लौटते हैं
- QUERYHIT में responder का IP address, port, speed, और result set होता है
- हर result में file index, file size, filename, और optional metadata या extensions शामिल होते हैं
- file index का उपयोग बाद में HTTP पर file request करते समय होता है
- Gnutella की flood routing प्रकृति के कारण results धीरे-धीरे आते थे, और पूरा होने में कई मिनट लग सकते थे
- LimeWire engineers ने इसे ज़्यादा scalable बनाने के लिए dynamic query routing तैयार किया
- इसमें Bloom filters और smart network topology का उपयोग हुआ
- इस उन्नत व्यवस्था की वजह से flood routing की समस्या के बिना इसे लाखों users तक scale किया जा सका
- आज भी ज़्यादातर mainstream clients इसी system को implement करते हैं
PUSH और firewall
- PUSH messages कुछ HTTP servers को firewall के पार निकलने में मदद देने वाला workaround हैं, लेकिन ये हर स्थिति हल नहीं करते
- सामान्य HTTP की तरह client के server से connect करने के बजाय, यह server से client की ओर connect करने का अनुरोध करने जैसा है
- PUSH message में uploader को downloader तक पहुँचने के लिए ज़रूरी servent identifier और अन्य identifiers होते हैं
- चूँकि client सीधे connect नहीं कर सकता, इसलिए यह सामने वाले से वापस connect होकर file भेजने का अनुरोध करता है
- अधिक विवरण Gnutella spec में देखे जा सकते हैं
- आधुनिक clients इन समस्याओं को अधिक सहज ढंग से संभालने के लिए अतिरिक्त techniques और UDP extensions का उपयोग करते हैं
बचा हुआ महत्व और संदर्भ सामग्री
- Gnutella ने अच्छी शुरुआती design की बदौलत लाखों concurrent users तक scale किया, blocking से बचा, और बाहरी मदद के बिना दशकों तक online बना रहा
- यह ऐसा network नहीं था जो असली traffic आते ही ढह गया; बल्कि यह तथ्य कि Y2K संस्कृति का हिस्सा रहा यह network अब भी गायब नहीं हुआ, इसकी design की मज़बूती दिखाता है
- निष्कर्ष लगभग यही है कि Gnutella के धुंधला पड़ने की असली वजह यह है कि वह उसे बनाने वाली दुनिया से अधिक समय तक जीवित रहा
- network खुद उन websites से भी अधिक समय तक जीवित रहा जो कभी प्रोटोकॉल से जुड़ी सामग्री host करती थीं
-
संदर्भ लिंक
1 टिप्पणियां
Lobste.rs की राय
Gnutella के बारे में मुझे याद है कि यह सर्च टर्म से मेल खाने वाली फ़ाइलें, आम तौर पर MP3, आसानी से बड़ी संख्या में डाउनलोड करने देता था, लेकिन वह “दूसरी चीज़” भी थी
पुरानी यादें ताज़ा हो गईं, अच्छा लगा, लेकिन अफ़सोस है कि आज का वेब एक राक्षस बन गया है
2000 के दशक के मध्य में यूनिवर्सिटी के डॉर्म flat network थे, और iTunes बहुत लोकप्रिय था, जो नेटवर्क पर किसी के साथ भी संगीत शेयर कर देता था
Circuit City से खरीदे नए 64-bit HP laptop को मैंने एक हफ़्ते के भीतर Evanescence और Green Day से भर दिया था, और लगा कि Columbia House CD Club की अब कोई ज़रूरत नहीं रही
ग्रेजुएशन के कुछ साल बाद किसी ने ग़लत व्यक्ति के सामने इसकी बात छेड़ दी, जिससे IT को आधिकारिक तौर पर पता चल गया, और आखिरकार उसे बंद करना पड़ा
बाद में समझ आया कि यूनिवर्सिटी नेटवर्क के ऊपर बनाए गए फ़ाइल-शेयरिंग नोड्स का “flat network” नहीं, बल्कि नेटवर्क ख़ुद flat था
फिर भी, कॉलेज का समय ऐसी चीज़ें करने के लिए मज़ेदार होता था
Soulseek अभी भी काफ़ी हद तक ज़िंदा है और ठीक से चल रहा है
Gnutella की सबसे मज़ेदार बात यह है कि इसका GNU project से कोई संबंध नहीं था, बस GNU अच्छा लगा इसलिए नाम में डाल दिया गया
मैं अक्सर सोचता हूँ कि Gnutella की मुख्य तकनीक को नए small-web या Gemini जैसे content discovery में कितना दोबारा इस्तेमाल किया जा सकता है
“फेल हो गया” कहना अधूरा है। आम तौर पर चीज़ें बस सफल या असफल नहीं होतीं, वे केवल किसी लक्ष्य के संदर्भ में सफल या असफल हो सकती हैं
Gnutella के यूज़र अब लगभग न होने के दो बड़े कारण हैं, और दोनों को विफलता माना जा सकता है
पहला, Gnutella और उससे जुड़े कई सॉफ़्टवेयर यूज़रों की privacy protection पर्याप्त रूप से नहीं कर पाए, जिससे वे वास्तविक और महसूस किए गए दोनों तरह के ख़तरों के सामने आ गए
दूसरा, मीडिया फ़ाइल डिस्ट्रीब्यूशन सिस्टम के रूप में यह बहुत अच्छा था, लेकिन यह ज़्यादातर यूज़रों को संतुष्ट करने वाला quality-price balance नहीं दे सका। इसने यूज़रों को वह असीमित access दिया जो वे चाहते थे, लेकिन असली content की गारंटी नहीं दे सका, जबकि Spotify ने दोनों दिए
इस अर्थ में Gnutella के यूज़र अब भी मौजूद हैं, बस वे अब कुछ और इस्तेमाल कर रहे हैं
*.gmiफ़ाइल आर्काइव बनाना, उसे Gnutella एक्सटेंशन के ज़रिए searchable करना, और लोगों के लिए gemtext दस्तावेज़ों पर साइन करके उन्हें पोस्ट करने वाला एक pointer system सोचा थायह ख़ुद में नई आइडिया नहीं है, लेकिन Gemtext + Gnutella distribution का संयोजन नया लगता है: https://github.com/RickCarlino/gnutella-bun-client/…
यह लेख GPT-5.4 के साथ बातचीत करते हुए brainstorm करने का नतीजा है, इसलिए इसे बाद के लिए दबाकर रखा था और अभी साझा करने का इरादा नहीं था, तो सावधानी से देखें
Gemini + Gnutella स्पेस के बारे में आपके विचार सुनना चाहूँगा, और मुझे Linkedin, Reddit, Fediverse आदि पर आसानी से ढूँढा जा सकता है, ब्लॉग पर भी संपर्क विवरण है
OnionShare भी काफ़ी दिलचस्प है: https://onionshare.org/
यह DaRkWeB का एक हिस्सा हो सकता है
दस्तावेज़ देखकर यह direct-connect फ़ाइल ट्रांसफ़र टूल के ज़्यादा क़रीब लगता है
लगता है कि उस समय की परिस्थितियों में Gnutella के लंबे समय तक टिके रहने का एक कारण यह भी था कि P2P search spam करने की कोई ख़ास व्यावहारिक प्रेरणा नहीं थी
बाद में P2P search spam वास्तव में उभर आया
आजकल IRC में भी spam लगभग नहीं के बराबर है, शायद इसी तरह के कारणों से
यह दिलचस्प है कि प्रोटोकॉल का बड़ा हिस्सा client पर भरोसा करता है
GUID को random होना चाहिए, लेकिन वह यूज़र के नियंत्रण में है, इसलिए सब लोग GUID को
0000भी सेट कर सकते हैं। अगर आज के हिसाब से Gnutella को फिर बनाया जाए, तो शायद उसमें कोई जटिल key-exchange system और ED25519 key-आधारित identity डाली जातीadvertised फ़ाइलों की संख्या, bandwidth वगैरह भी मूलतः इस भरोसे पर टिकी है कि यूज़र सच बोल रहा है। अगर प्रोटोकॉल ज़्यादा जटिल होता, तो शायद वह ऐसे दावों को वास्तव में verify करने की कोशिश करता
अगर इसमें बहुत सारे key signatures या reputation management डाल दिए जाते, तो implementation बहुत जटिल हो सकता था, और संभव है कि इसकी सादगी ही इसकी सफलता का कारण रही हो। Gnutella client वास्तव में बनाया जा सकता है
मुझे लगता है कि कई आधुनिक P2P प्रोजेक्ट इस बात को चूक जाते हैं। मेरा पसंदीदा प्रोजेक्ट Secure Scuttlebutt भी, तरह-तरह की विफलताओं और दुरुपयोग के मामलों को ध्यान में रखकर लगभग परफेक्ट चीज़ बनाने की कोशिश में, अंततः ऐसे ecosystem में बदल गया जहाँ काम करने वाला client लगभग सिर्फ़ spec लिखने वालों का बना हुआ एक ही है
यही उदाहरण
gemini://पर भी लागू होता है। यह P2P नहीं बल्कि एक federated protocol है, लेकिन spec में समस्याएँ और loopholes होने के बावजूद लोगों ने वास्तव में clients बनाए, और उन समस्याओं के बावजूद ecosystem में काफ़ी विविध implementations मौजूद हैंGnutella के उस समय उभरने में Berkeley XCF के सदस्य Gene Kan और Spencer Kimball की बड़ी भूमिका थी
Spencer ने बाद में Google में बहुत बेहतरीन engineering work किया, और अब वह डेटाबेस कंपनी Cockroach Labs के CEO हैं
Gene ने अपनी search company को Sun को बेचकर जल्दी सफलता हासिल कर ली थी, लेकिन दुखद रूप से 2002 में बहुत कम उम्र में उनका त्रासद निधन हो गया