अवलोकन
यह प्रस्ताव एक सिरे से दूसरे सिरे तक गार्लिक संदेश में कई डेटा गार्लिक क्लोव्स भेजने के बारे में है, सिर्फ एक के बजाय।
प्रेरणा
स्पष्ट नहीं।
आवश्यक परिवर्तन
परिवर्तन OCMOSJ और संबंधित हेल्पर क्लासेस में, और ClientMessagePool में होंगे। चूंकि अब कोई कतार नहीं है, एक नई कतार और कुछ देरी आवश्यक होगी। किसी भी बैचिंग को एक अधिकतम गार्लिक साइज का सम्मान करना होगा ताकि इसे न्यूनतम किया जा सके। शायद 3KB? पहले चीजों को इंस्ट्रूमेंट करना चाहेंगे ताकि यह मापा जा सके कि यह कितनी बार उपयोग में आता है।
विचार
यह स्पष्ट नहीं है कि इसका कोई उपयोगी प्रभाव होगा या नहीं, क्योंकि स्ट्रीमिंग पहले से ही बैचिंग करती है और इष्टतम MTU का चयन करती है। बैचिंग से संदेश का आकार बढ़ेगा और ड्रॉप की संभावना बढ़ेगी।
अपवाद है असंपीड़ित सामग्री, जो I2CP लेयर पर gzip की गई है। लेकिन HTTP ट्रैफिक पहले से ही उच्च लेयर पर संपीड़ित है, और बिटटोरेंट डेटा आमतौर पर असंपीड़ित होता है। इसके बाद क्या बचता है? I2pd वर्तमान में x-i2p-gzip संपीड़न नहीं करता है इसलिए यह वहां काफी मदद कर सकता है। लेकिन टैग समाप्त न होने का दिया गया लक्ष्य उनके स्ट्रीमिंग लाइब्रेरी में सही विंडोइंग कार्यान्वयन के साथ बेहतर तरीके से हल किया जा सकता है।
संगतता
यह पिछली संगतता को बनाए रखता है, क्योंकि गार्लिक रिसीवर पहले से ही उसे प्राप्त सभी क्लोव्स को प्रोसेस कर देगा।