- 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
- objectsKnownToThem is supposed to track if it's necessary to send inv
commands to a peer
- it is supposed to enter garbage collection after 1 hour
(ObjectTracker.trackingExpires)
- due to peer not announcing all objects, or announcing them before we
announce, this contains excessive number of entries after connection
is fully established.
- profiling revealed that this creates unnecessary memory to be kept
allocated
- this patch will prevent tracking of entries sent during bigInv,
reducing the memory "leak"
- it is possible, in theory, that this does have some negative effect,
like increased bandwidth or neglecting to announce some invs. It
probably doesn't though as my review of objectsKnownToThem occurrences
didn't reveal any such case, and since the dict didn't track fully
accurately anyway (so it would have already been broken if it was a
problem), I consider it an acceptable risk at the moment. If it indeed
causes problems, they can be solved separately
- I tested this on one of the bootstrap servers with little memory, and
it increased the number of connections than can be handled by a factor
of about 3.5
- new options in network section: onionsocksproxytype,
onionsockshostname and onionsocksport. These allow to separate
connectivity types for onion and non-onion addresses, e.g. connect to
clear nodes over clearnet and onions over tor
- also remove some obsolete imports
- dandelion fixes
- try to wait as long as possible before expiration if there are no
outbound connections
- expire in invThread rather than singleCleaner thread
- deduplication of code in inv and dinv command methods
- turn on by default, seems to work correctly now
- turn off dandelion if outbound connections are disabled
- start tracking downloads earlier, and faster download loop
- remove some obsolete lines
- minor PEP8 updates
- will try to report "Server full" over protocol for 10 extra
connections over limit, instead of simply dropping them
- if connected to the same host inbound and outbound, handle as server
full (prevents duplicate connections)
