We eliminated 1 second delay between completion of name resolution for
tracker request and time when it is actually issued. We also elimited
1 second delay after last torrent download exists and it is told to
DHTInteractionCommand.
Previously, with --bt-detach-seed-only, when user issued pause and
unpause command to seeding torrent, and it was started again, and it
immediately got seeding status, but aria2 did not start new download
waiting in the queue. This commit fixes this bug.
See GH-490
This option excludes seed only downloads when counting concurrent
active downloads (-j option). This means that if -j3 is given and
this option is turned on and 3 downloads are active and one of those
enters seed mode, then it is excluded from active download count (thus
it becomes 2), and the next download waiting in queue gets started.
But be aware that seeding item is still recognized as active download
in RPC method.
DefaultPieceStorage may be referenced by one of DHT task (e.g.,
DHTPeerLookupTask), after RequestGroup was deleted, and even after
RequestGroupMan was deleted. DefaultPieceStorage has a reference to
MultiDiskAdaptor which calls RequestGroupMan object on destruction.
So when DHT task is destroyed, DefaultPieceStorage is destroyed, which
in turn destroys MultiDiskAdaptor. DHT task is destroyed after
RequestGroupMan was destroyed, MultiDiskAdaptor will use now freed
RequestGroupMan object, this is use-after-free.
This change changes the behavior of --bt-max-open-files. Previously,
it specifies the maximum number of opened files for each multi-file
download. Since it is more useful to limit the number globally, the
option now specifies the global limit. This change suggests that
aria2.changeOption() method now ignores --bt-max-open-files and
aria2.changeGlobalOption now reads it and dynamically change the
limit.
With -c option, aria2 can continue download after the existing file
position. If it is not completed, then after completion aria2 runs
checksum checking if available. But if existing file has already been
completed, then CreateRequestCommand exits without issuing checksum
checking. And aria2 treats it download error because it needs checksum
verification but it has not been done. This change fixes this by
properly checking download state and issue checksum checking before
CreateRequestCommand.
This change replaces the current 64 bit sequential GID with 64 bits
random bytes GID in an attempt to support persistent GID. Internally,
the GID is stored as uint64_t. For human representation and RPC
interface, GID is represented as 16 bytes hex string. For console
readout, 16 bytes are too long, so it is abbreviated to first 6 bytes.
When querying GID in RPC calls, user can speicfy the prefix of GID as
long as the prefix is shared by more than 1 GID entries.
This option enables disk cache. If SIZE is 0, the disk cache is
disabled. This feature caches the downloaded data in memory, which
grows to at most SIZE bytes. The cache storage is created for aria2
instance and shared by all downloads. The one advantage of the disk
cache is reduce the disk seek time because the data is written in
larger unit and it is reordered by the offset of the file. If the
underlying file is heavily fragmented it is not the case.
The old implementation calculates download/upload statistics for a
RequestGroup by summing up all PeerStat objects. For global
statistics, those are summed together. This clearly incurs runtime
penalty and we introduced some kind of caching which updates
statistics every 250ms but it did not work right.
This change removes all these aggregation code, and instead makes
RequestGroup and RequestGroupMan objects hold NetStat object and
download/upload bytes are directly calculated by thier own NetStat.
This is far more simplar than the old way and less runtime penalty and
brings more accuracy.
DownloadHandlerConstants was simplified. MIME type handling in Accept
header was also reworked. DownloadContext's metalinkServerContacted_
is replaced with acceptMetalink_ and its boolean value is reverted.
RequestGroup and HttpRequest now do not hold vector of accepting
types. HttpRequest has the flag acceptMetalink_ which will be set by
the same value of DownloadContext::accpetMetalink_ and if it is true,
Metalink MIME types are added to Accept header field.
Tatsuhiro Tsujikawa