On Saturday 16 October 2010 22:04:47 Matthew Toseland wrote: ... > > For this to achieve its promise and improve efficiency (as well as enabling > transport plugins with relatively small packets and enabling support for low > MTUs), we need a new padding rule. Either: > a) We always send the largest possible packet. This will maximise bandwidth > efficiency and probably minimise traffic analysis, at the cost of some > latency, OR > b) If there is high priority stuff (or urgent stuff??) to send, aggregate it, > get the packet size, then (assuming it is not full), get the packet size, pad > it, and then fill in the padding as much as possible with lower priority > stuff. > This should be configurable. Although I do wonder if the first strategy is > better for most purposes... The current code more or less implements the > first strategy, and because we can send big messages along with everything > else, it should be more efficient than the old FNP, even though we have an > extra few bytes per message...
This still needs to happen. It can happen post-merge however. And please don't feel under any obligation - if I need to do the last tweaks that's fine. If you have any input on the above that'd be great though. There's a related bug: https://bugs.freenetproject.org/view.php?id=4352 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101109/177728db/attachment.pgp>
