Обзор
Это предложение касается отправки нескольких Data Garlic Cloves внутри конечного Garlic Message, вместо одного.
Мотивация
Не ясно.
Необходимые изменения
Изменения будут внесены в OCMOSJ и связанные вспомогательные классы, а также в ClientMessagePool. Так как очереди сейчас нет, потребуется новая очередь и некоторая задержка. Любая пакетная обработка должна учитывать максимальный размер garlic, чтобы минимизировать потери. Возможно, 3KB? Для начала нужно инструментировать вещи, чтобы измерить, как часто это будет использоваться.
Мысли
Неясно, будет ли это иметь какое-либо полезное воздействие, поскольку потоковая передача уже выполняет пакетную обработку и выбирает оптимальное MTU. Пакетная обработка увеличила бы размер сообщения и вероятность его выпадения по экспоненте.
Исключением является несжатый контент, сжатый на уровне I2CP. Но HTTP-трафик уже сжат на более высоком уровне, а данные Bittorrent обычно несжимаемы. Что это оставляет? I2pd в настоящее время не выполняет сжатие x-i2p-gzip, поэтому это может помочь гораздо больше. Но заявленная цель избежать нехватки тегов лучше решается с помощью правильной реализации управления окнами в его потоковой библиотеке.
Совместимость
Это совместимо с предыдущими версиями, так как получатель garlic уже обрабатывает все поступающие гвоздики.