概述
该提案涉及在端到端大蒜消息中发送多个数据大蒜瓣，而不仅仅是一个。
动机
不明确。
所需更改
更改将涉及OCMOSJ和相关的辅助类，以及ClientMessagePool。由于现在没有队列，新的队列和一些延迟将是必要的。任何批处理都必须遵循最大大蒜大小以最小化丢弃。也许是3KB？希望首先对事物进行检测，以测量其使用频率。
想法
尚不清楚这是否会产生任何有用的效果，因为流已经在进行批处理并选择了最佳MTU。批处理会增加消息大小和指数级的丢失概率。
例外是未压缩内容，在I2CP层进行了gzip压缩。但HTTP流量已经在更高层进行了压缩，Bittorrent数据通常不可压缩。那么剩下什么呢？I2pd目前未执行x-i2p-gzip压缩，因此在那里可能会有更多的帮助。但声明的避免耗尽标签的目标更好地通过他的流媒体库中的正确窗口实现来解决。
兼容性
这是向后兼容的，因为大蒜接收方已经会处理所有接收到的瓣。