सभी को नमस्ते, इस सप्ताह विलंबित स्टेटस नोट्स

  • Index
  1. नेट स्थिति 2) Router विकास स्थिति 3) Syndie का औचित्य जारी 4) Syndie विकास स्थिति 5) वितरित संस्करण नियंत्रण 6) ???
    1. Net status

पिछले एक-दो हफ्तों में irc और अन्य सेवाएँ काफ़ी स्थिर रही हैं, हालांकि dev.i2p/squid.i2p/www.i2p/cvs.i2p में कुछ उतार-चढ़ाव रहे (अस्थायी OS-संबंधित समस्याओं के कारण)। इस समय चीज़ें एक स्थिर अवस्था में लग रही हैं।

    1. Router dev status

Syndie चर्चा का दूसरा पहलू यह है: “तो, इसका router के लिए क्या अर्थ है?”, और इसका उत्तर देने के लिए, मुझे संक्षेप में बताने दें कि वर्तमान में router के विकास की स्थिति क्या है।

कुल मिलाकर, मेरे विचार में router को 1.0 तक पहुँचने से रोकने वाली चीज़ उसका प्रदर्शन है, न कि उसकी गुमनामी संबंधी विशेषताएँ। निस्संदेह, गुमनामी से जुड़ी कुछ बातें सुधारनी हैं, पर एक गुमनाम नेटवर्क के लिए हमें भले ही काफ़ी अच्छा प्रदर्शन मिलता हो, व्यापक उपयोग के लिए हमारा प्रदर्शन पर्याप्त नहीं है। इसके अतिरिक्त, नेटवर्क की गुमनामी में सुधार करने से उसके प्रदर्शन में सुधार नहीं होगा (अधिकांश मामलों में, जिनके बारे में मैं सोच सकता हूँ, गुमनामी में सुधार थ्रूपुट कम करता है और विलंबता बढ़ाता है)। हमें पहले प्रदर्शन संबंधी समस्याएँ सुलझानी होंगी, क्योंकि यदि प्रदर्शन अपर्याप्त है, तो पूरा सिस्टम ही अपर्याप्त है, चाहे उसकी गुमनामी तकनीकें कितनी ही मजबूत क्यों न हों।

तो, हमारा प्रदर्शन पीछे क्यों रह रहा है? हैरानी की बात है कि इसका कारण हमारा CPU उपयोग प्रतीत होता है। ठीक-ठीक क्यों ऐसा है, इस पर आने से पहले, पहले थोड़ी और पृष्ठभूमि।

  • to prevent partitioning attacks, we all need to plausibly build our tunnels from the same pool of routers.
  • to allow the tunnels to be of manageable length (and source routed), the routers in that pool must be directly reachable by anyone.
  • the bandwidth costs of receiving and rejecting tunnel join requests exceeds the capacity of dialup users on burst.

इसलिए, हमें routers के कई स्तर चाहिए - कुछ वैश्विक रूप से पहुँच योग्य हों और उच्च बैंडविड्थ सीमाएँ रखें (tier A), और कुछ न हों (tier B)। यह व्यवहार में पहले से ही netDb में क्षमता संबंधी जानकारी के माध्यम से लागू किया जा चुका है, और एक-दो दिन पहले तक, tier B से tier A का अनुपात लगभग 3 से 1 रहा है (cap L, M, N, या O के 93 routers, और cap K के 278)।

अब, tier A में प्रबंधन के लिए मूलतः दो दुर्लभ संसाधन हैं - बैंडविड्थ और CPU। बैंडविड्थ को सामान्य तरीकों से प्रबंधित किया जा सकता है (विस्तृत पूल में लोड को विभाजित करना, कुछ peers को अत्यधिक मात्रा संभालने देना [उदा. T3s पर वाले], और व्यक्तिगत tunnels तथा connections को अस्वीकार करना या उनकी गति सीमित करना)।

CPU उपयोग को प्रबंधित करना अधिक कठिन है। tier A routers पर देखी जाने वाली मुख्य CPU बाधा tunnel build अनुरोधों का डिक्रिप्शन है। बड़े routers इस गतिविधि से (और होते भी हैं) पूरी तरह खप सकते हैं—उदाहरण के लिए, मेरे एक router पर tunnel डिक्रिप्ट करने का समूचे जीवनकाल का औसत समय 225ms है, और tunnel अनुरोध डिक्रिप्शन की समूचे जीवनकाल की औसत आवृत्ति 60 सेकंड में 254 घटनाएँ, या प्रति सेकंड 4.2 है। इन दोनों को बस गुणा करने से यह दिखता है कि केवल tunnel अनुरोध डिक्रिप्शन ही CPU का 95% खपा देता है (और यह घटनाओं की संख्या में आने वाले उछालों को ध्यान में भी नहीं रखता)। वह router फिर भी किसी तरह एक समय में 4-6000 tunnels में भाग लेने में सफल रहता है, और डिक्रिप्ट किए गए अनुरोधों में से लगभग 80% स्वीकार करता है।

दुर्भाग्य से, क्योंकि उस router पर CPU अत्यधिक लोड में है, उसे tunnel build अनुरोधों की काफी संख्या को उन्हें डिक्रिप्ट किए जाने से पहले ही ड्रॉप करना पड़ता है (वरना अनुरोध क्यू में इतने देर तक पड़े रहते कि भले ही उन्हें स्वीकार कर लिया जाता, मूल अनुरोधकर्ता उन्हें खोया हुआ या इतना लोडेड मान लेता कि उनके साथ कुछ किया ही न जा सके)।

इस परिप्रेक्ष्य में, router की 80% स्वीकृति दर काफी अधिक खराब दिखती है - अपने जीवनकाल में उसने लगभग 250k अनुरोध डिक्रिप्ट किए (अर्थात लगभग 200k स्वीकार किए गए), लेकिन CPU ओवरलोड के कारण उसे डिक्रिप्ट क्यू में लगभग 430k अनुरोध ड्रॉप करने पड़े (जिससे वह 80% स्वीकृति दर 30% में बदल गई)।

समाधान संभवतः tunnel अनुरोधों के डिक्रिप्शन के लिए संबंधित CPU लागत को कम करने के इर्द-गिर्द हैं। यदि हम CPU समय को दस गुना घटा दें, तो इससे tier A router की क्षमता में काफी वृद्धि होगी, जिससे अस्वीकृतियाँ (स्पष्ट और निहित, ड्रॉप किए गए अनुरोधों के कारण) कम होंगी। इससे आगे चलकर tunnel निर्माण की सफलता दर बढ़ेगी, जिसके परिणामस्वरूप lease के समाप्त होने की आवृत्ति कम होगी, और इस तरह tunnel के पुनर्निर्माण के कारण नेटवर्क पर बैंडविड्थ का भार घटेगा।

इसे करने का एक तरीका यह होगा कि tunnel build अनुरोधों में 2048bit Elgamal का उपयोग बदलकर, मान लीजिए, 1024bit या 768bit कर दिया जाए। लेकिन यहाँ समस्या यह है कि यदि आप किसी tunnel build अनुरोध संदेश का एन्क्रिप्शन तोड़ देते हैं, तो आपको tunnel का पूरा मार्ग पता चल जाता है। भले ही हम यह रास्ता अपनाएँ, इससे हमें कितना लाभ होगा? डिक्रिप्शन समय में एक क्रम का सुधार, स्तर B से स्तर A के अनुपात में एक क्रम की वृद्धि (जिसे फ्रीराइडर्स समस्या कहा जाता है) से मिट सकता है, और तब हम फँस जाएँगे, क्योंकि हमारे लिए 512 या 256bit Elgamal पर जाना संभव नहीं होगा (और फिर आईने में खुद को देख भी सकें ;)

एक वैकल्पिक तरीका यह होगा कि हम कमज़ोर क्रिप्टोग्राफी का उपयोग करें, लेकिन नई tunnel निर्माण प्रक्रिया के साथ जो हमने पैकेट-गणना हमलों से बचाव जोड़ा था, उसे हटा दें। इससे हमें Tor-जैसे टेलिस्कोपिक tunnel में पूरी तरह अस्थायी रूप से सहमति से तय की गई कुंजियों का उपयोग करने की अनुमति मिल जाएगी (हालाँकि, फिर से, इससे tunnel निर्माता सेवा की पहचान करने वाले तुच्छ, निष्क्रिय पैकेट-गणना हमलों के लिए उजागर हो जाएगा)।

एक और विचार यह है कि netDb में लोड जानकारी को और भी अधिक स्पष्ट रूप से प्रकाशित किया जाए और उसका उपयोग किया जाए, ताकि क्लाइंट उपरोक्त जैसी स्थितियों का अधिक सटीकता से पता लगा सकें, जहाँ एक उच्च बैंडविड्थ router अपने tunnel अनुरोध संदेशों में से 60% को उन्हें देखे बिना ही ड्रॉप कर देता है। इस दिशा में कुछ प्रयोग करने योग्य हैं, और इन्हें पूर्ण पिछली संगतता (backwards compatibility) के साथ किया जा सकता है, इसलिए हमें ये जल्द ही दिखाई देने चाहिए।

तो, मेरी दृष्टि में आज router/नेटवर्क में यही बॉटलनेक है। हम इससे कैसे निपट सकते हैं, इस बारे में हर प्रकार के सुझावों का हार्दिक स्वागत है।

    1. Syndie rationale continued

फोरम पर Syndie के बारे में और व्यापक व्यवस्था में उसकी जगह क्या है, इस पर एक विस्तृत पोस्ट उपलब्ध है - इसे यहाँ देखें http://forum.i2p.net/viewtopic.php?t=1910

साथ ही, मैं बस उन Syndie दस्तावेज़ों से दो अंशों पर प्रकाश डालना चाहता हूँ जिन पर काम चल रहा है। पहला, irc से (और वह FAQ (अक्सर पूछे जाने वाले प्रश्न) जो अभी तक प्रकाशित नहीं हुई है):

मैं जिस सवाल पर सोच रहा हूँ, वह है: आगे चलकर syndie प्रोडक्शन सर्वर/आर्काइव होस्ट करने की इतनी हिम्मत किसमें होगी? क्या उन्हें आज के eepsites(I2P Sites) की तरह उतनी ही आसानी से ढूंढ निकालना नहीं होगा? पब्लिक syndie आर्काइव्स में फोरम पर पोस्ट की गई सामग्री को read करने की क्षमता नहीं होती, जब तक कि फोरम इस काम के लिए कुंजियाँ प्रकाशित न करें और usecases.html के दूसरे अनुच्छेद को भी देखो बेशक, जिन आर्काइव होस्ट करने वालों को किसी फोरम को हटाने के लिए कानूनी आदेश मिलेंगे, वे शायद ऐसा करेंगे (लेकिन तब लोग किसी दूसरे आर्काइव पर जा सकते हैं, बिना फोरम के संचालन में खलल डाले) हाँ, यह ज़रूर बताना चाहिए कि किसी अलग माध्यम पर माइग्रेशन निर्बाध होगा अगर मेरा आर्काइव बंद हो जाए, तो मैं अपना पूरा फोरम किसी नए आर्काइव पर अपलोड कर सकता हूँ, सही? ‘बिलकुल bar वे माइग्रेट करते समय एक ही समय में दो तरीकों का उपयोग कर सकते हैं और कोई भी उन माध्यमों को समकालिक कर सकता है सही कहा void

(जो अभी तक प्रकाशित नहीं हुआ है) Syndie usecases.html का संबंधित अनुभाग है:

जहाँ कई अलग-अलग समूह अक्सर चर्चाओं को एक ऑनलाइन फ़ोरम में व्यवस्थित करना चाहते हैं, पारंपरिक फ़ोरमों की केंद्रीकृत प्रकृति (वेबसाइटें, BBSes (बुलेटिन बोर्ड सिस्टम्स), आदि) एक समस्या हो सकती है। उदाहरण के लिए, वह साइट जो फ़ोरम की मेजबानी करती है, उसे Denial of Service attacks (सेवा-निषेध हमले) या प्रशासनिक कार्रवाई के माध्यम से ऑफ़लाइन किया जा सकता है। इसके अलावा, एकल होस्ट समूह की गतिविधि की निगरानी के लिए एक सरल बिंदु प्रदान करता है, ताकि भले ही कोई फ़ोरम छद्मनामिक हो, वे छद्मनाम उस IP से जोड़े जा सकते हैं जिसने व्यक्तिगत संदेश पोस्ट किए या पढ़े।

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

    1. Syndie dev status

हाल ही में Syndie पर काफ़ी प्रगति हुई है, और IRC चैनल पर लोगों को 7 अल्फ़ा रिलीज़ वितरित की गई हैं। स्क्रिप्टेबल इंटरफ़ेस के अधिकांश बड़े मुद्दों का समाधान कर दिया गया है, और मुझे उम्मीद है कि हम इस महीने के अंत तक Syndie 1.0 रिलीज़ जारी कर पाएंगे।

क्या मैंने अभी “1.0” कहा? हाँ, बिल्कुल! हालाँकि Syndie 1.0 एक टेक्स्ट-आधारित अनुप्रयोग होगा और अन्य समान टेक्स्ट-आधारित ऐप्स (जैसे mutt या tin) की उपयोग-सुविधा की बराबरी भी नहीं करेगा, फिर भी यह कार्यक्षमताओं की पूरी शृंखला प्रदान करेगा, HTTP और फ़ाइल-आधारित सिंडिकेशन रणनीतियों का समर्थन करेगा, और उम्मीद है कि संभावित डेवलपर्स को Syndie की क्षमताएँ प्रदर्शित करेगा।

इस समय, मैं Syndie 1.1 रिलीज़ को अस्थायी रूप से निर्धारित कर रहा हूँ (जिससे लोग अपने आर्काइव और पढ़ने की आदतों को बेहतर ढंग से व्यवस्थित कर सकेंगे) और शायद 1.2 रिलीज़ जिसमें कुछ खोज संबंधी फ़ंक्शनैलिटी एकीकृत की जाए (साधारण खोजें और शायद Lucene की फुलटेक्स्ट खोजें)। Syndie 2.0 संभवतः पहली GUI (ग्राफिकल यूज़र इंटरफ़ेस) रिलीज़ होगी, और ब्राउज़र प्लगइन 3.0 के साथ आएगा। अतिरिक्त आर्काइव और संदेश वितरण नेटवर्क के लिए समर्थन, लागू होने पर, निश्चित रूप से जोड़ा जाएगा (freenet, mixminion/mixmaster/smtp, opendht, gnutella, आदि)।

हालांकि मुझे एहसास है कि Syndie 1.0 उतना क्रांतिकारी नहीं होगा जितना कुछ लोग चाहते हैं, क्योंकि टेक्स्ट-आधारित ऐप्स वास्तव में तकनीकी शौकीनों के लिए ही होते हैं, लेकिन मैं यह कोशिश करना चाहता हूँ कि हम “1.0” को अंतिम रिलीज़ मानने की अपनी आदत छुड़ाएँ और उसकी बजाय उसे एक शुरुआत मानें।

    1. Distributed version control

अब तक, मैं Syndie के लिए vcs (संस्करण नियंत्रण प्रणाली) के तौर पर subversion के साथ थोड़ा-बहुत प्रयोग करता रहा हूँ, जबकि वास्तव में मैं केवल CVS और clearcase में ही पारंगत हूँ। इसका कारण यह है कि मैं अधिकांश समय ऑफ़लाइन रहता हूँ, और जब ऑनलाइन भी होता हूँ, तो डायल-अप धीमा होता है, इसलिए subversion का local diff/revert/etc काफ़ी काम का रहा है। हालांकि, कल void ने सुझाव दिया कि हम इसकी बजाय वितरित प्रणालियों में से किसी एक पर नज़र डालें।

कुछ साल पहले मैंने I2P के लिए एक VCS (वर्ज़न कंट्रोल सिस्टम) का मूल्यांकन करते समय उन्हें देखा था, लेकिन मैंने उन्हें इसीलिए खारिज कर दिया क्योंकि मुझे उनकी ऑफलाइन कार्यक्षमता की ज़रूरत नहीं थी (तब मेरे पास अच्छी नेटवर्क पहुँच थी), इसलिए उन्हें सीखना सार्थक नहीं लगा। अब स्थिति वैसी नहीं है, इसलिए मैं अब उन्हें थोड़ा और ध्यान से देख रहा हूँ।

  • From what I can see, darcs, monotone, and codeville are the top

विकल्पों में darcs का patch-आधारित vcs (संस्करण नियंत्रण प्रणाली) विशेष रूप से आकर्षक लगता है। उदाहरण के लिए, मैं अपना सारा काम लोकली कर सकता हूँ और बस scp के जरिए gzip’ed और gpg’ed diffs (अंतर फाइलें) को dev.i2p.net पर किसी Apache डायरेक्टरी में अपलोड कर सकता हूँ, और लोग अपनी पसंद की लोकेशनों पर अपनी gzip’ed और gpg’ed diffs पोस्ट करके अपने बदलाव योगदान कर सकते हैं। जब किसी रिलीज़ को टैग करने का समय आता है, तो मैं एक darcs diff बनाऊँगा जो रिलीज़ में शामिल पैचों के सेट को निर्दिष्ट करता है और बाकियों की तरह उसी .gz’ed/.gpg’ed diff को ऊपर पुश कर दूँगा (साथ ही, निश्चित रूप से असल tar.bz2, .exe, और .zip फाइलें भी पुश करूँगा ;)

और, एक विशेष रूप से रोचक बात यह है कि ये gzip’ed/gpg’ed diffs (अंतर फ़ाइलें) Syndie संदेशों में संलग्नकों के रूप में पोस्ट किए जा सकते हैं, जिससे Syndie स्व-होस्टेड हो सके।

वैसे, क्या किसी के पास इन चीज़ों के साथ कोई अनुभव है? कोई सलाह?

    1. ???

इस बार केवल 24 स्क्रीन-भर टेक्स्ट (फ़ोरम पोस्ट सहित) ;) दुर्भाग्य से मैं बैठक में शामिल नहीं हो सका, लेकिन हमेशा की तरह, यदि आपके पास कोई विचार या सुझाव हों, तो उन्हें सुनकर मुझे खुशी होगी - बस मेलिंग लिस्ट या फ़ोरम पर पोस्ट कर दें, या IRC पर आ जाएँ.

=jr