> With the new packet format, the obvious strategy to maximise the payload > percentage is to send as big a packet as possible within the MTU. If there > is plenty of data queued we will always be able to reach it exactly, so > won't need padding (unless we decide to set a lower limit and randomise > above it). This also minimises any possible exposure to traffic analysis. > The catch is big packets are more likely to be dropped and tend to have > higher latency. > > The other option is if there are high priority messages in the queue, we > should pack them into a packet, then pad it, then fill the padding with > data from lower priority messages. This was more or less what was > originally envisaged when we started with the new packet format. We should > probably make this configurable.
I vote for being able to configure this. I want my node to have high throughput, I do not depend on latency. Therefore, high packet size is nice for me. High payload size is also nice, I do not provide a seed-node anymore because the payload output was too low and my inserts were suffering from that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101221/9ed3bbb7/attachment.pgp>
