- expiration wasn't handled correctly
- objects with no child stems never expired. While this is better for
anonymity, it can cause objects getting stuck
- upon expiration the nodes weren't marked as not having the object, causing it
to not be advertised
- I haven't tested it but at least I don't think can make things worse
- instead of being processed in the ReceiveQueue thread, uploads are now done
in a dedicated thread. Only the parsing is done in ReceiveQueue thread.
- the UploadThread is modelled based on the DownloadThred, but simpler.
- it checks for intersection attack, eliminates duplicates and restricts the
write buffer size to 2MB (may still grow slightly higher if too many big
objects are requested, but the absolute limit appears to be about 4.5MB in the
worst case scenario).
- the restriction of the write buffer may cause some upload throttling (to
about 2MB per second per connection), but can be optimised later
- fixes#1414
- in corner cases, download request could have contained an incorrect
request length. I haven't actually checked if this can be triggered
though
- wait for downloading until anti intersection delay expires. Doesn't
necessarily mean that it will always avoid peer's anti intersection
delay, but it's close enough
- tracks last time an object was received. If it was too long time ago,
reset the download request queue. This avoid situations like when a
request gets ignored during the anti intersection delay, but it will
keep thinking there are still pending requests as long as not all
missing objects have been requested. This caused staggered download
(request 1000 items, wait 1 minute, request 1000 more, wait another
minute, ...)
- with these fixes, you should end up downloading as fast as your
network and CPU allow
- best tested with trustedpeer
