46 lines
1.3 KiB
ReStructuredText
46 lines
1.3 KiB
ReStructuredText
|
====================================
|
||
|
|
Batch Multiple Data Cloves in Garlic
|
||
|
|
====================================
|
||
|
|
.. meta::
|
||
|
|
:author: orignal
|
||
|
|
:created: 2015-01-22
|
||
|
|
:thread: http://zzz.i2p/topics/1797
|
||
|
|
:lastupdated: 2015-01-22
|
||
|
|
:status: Draft
|
||
|
|
|
||
|
|
.. contents::
|
||
|
|
|
||
|
|
|
||
|
|
Introduction
|
||
|
|
============
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
Required Changes
|
||
|
|
================
|
||
|
|
|
||
|
|
The changes would be in OCMOSJ and related helper classes, and in
|
||
|
|
ClientMessagePool. As there is no queue now, a new queue and some delay would be
|
||
|
|
necessary. Any batching would have to honor a max garlic size to minimize
|
||
|
|
dropping. Perhaps 3KB? Would want to instrument things first to measure how
|
||
|
|
often this would get used.
|
||
|
|
|
||
|
|
This is backward-compatible, as the garlic receiver will already process all
|
||
|
|
cloves it receives.
|
||
|
|
|
||
|
|
|
||
|
|
Thoughts
|
||
|
|
========
|
||
|
|
|
||
|
|
It is unclear whether this will have any useful effect, as streaming already
|
||
|
|
does batching and selects optimum MTU. Batching would increase message size and
|
||
|
|
exponential drop probability.
|
||
|
|
|
||
|
|
The exception is uncompressed content, gzipped at the I2CP layer. But HTTP
|
||
|
|
traffic is already compressed at higher layer, and Bittorrent data is usually
|
||
|
|
uncompressible. What does this leave? I2pd doesn't currently do the x-i2p-gzip
|
||
|
|
compression so it may help there a lot more. But stated goal of not running out
|
||
|
|
of tags is better fixed with proper windowing implementation in his streaming
|
||
|
|
library.
|