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.
If more than 1 simultaneous downloads are going on, use more compact
format in readout. Currently, at most 5 download stats are displayed.
util::abbrevSize() is rewritten to support "Gi" unit and provides more
compact abbreviation.
If we receive small data (e.g., 1 or 2 bytes), cache entry becomes a
headache. To mitigate this problem, we allocate cache buffer at least
4KiB and append the data to the contagious cache data.
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.
If true is given, which is default, save the uploaded torrent or
metalink metadata in the directory specified by --dir option. The
filename consists of SHA1-hash hex string of metadata plus
extension. For torrent, the extension is '.torrent'. For metalink, it
is '.meta4'. If false is given to this option, the downloads added by
aria2.addTorrent or aria2.addMetalink will not be saved by
--save-session option.
In this change, we defined HTTP header fields we are interested in.
We only store those headers in HttpHeader object. Accessing HTTP
headers in HttpHeader object is now done through enum values.
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.
Using off_t, at least, in DiskAdaptor layer is problematic because
torrent can contain under 2GiB files but total sum of those files may
exceed 2GiB limit, which makes off_t overflow in 32 bit system without
large file support. So we use int64_t in API. We'll check the file
length before download so that it does not exceed max off_t.
We only percent-decode filename* value in Content-Disposition because
the encoding is fully specified. But since filename value is not, so
we just accept it as is.
The old implementation calls at least 2 read(2) (4bytes length and
payload) to receive the message. This change will read as many bytes
as possible in one read(2) call. BtPieceMessage::data_ is now just a
const pointer to the internal buffer of PeerConnection.
The previous implementation mistakenly sees '/abspath?uri=http://foo'
as an absolute URI because it contains '://', but actually it is not.
This change checks scheme part is constructed in the allowed character
set described in RFC 3986 Section 3.1.
If the number of pieces gets bigger, the length of Bitfield message
payload exceeds the initial buffer capacity of PeerConnection, which
is MAX_PAYLOAD_LEN. We expand buffer as necessary so that
PeerConnection can receive the Bitfield message.
In aria2, one piece is downloaded from several peers, so when hash
check failed for that piece, it cannot determine which peer(s) sent
bad data. So, we ignore peer who sent last block of data in random
minutes. We use randomized timeout because all peers get waken up at
the almost same time.