mirror of
https://github.com/rkd77/elinks.git
synced 2024-12-04 14:46:47 -05:00
The not so short BitTorrent TODO list
This commit is contained in:
parent
9bd00e0ad8
commit
f9c8838465
@ -1,14 +1,69 @@
|
||||
A short TODO list for the BT implementation:
|
||||
The ELinks BitTorrent Client
|
||||
============================
|
||||
|
||||
Torrents should be added to the global history.
|
||||
The BitTorrent client is fully usable and has been tested on multiple sites, it
|
||||
does however still lack certain core functionally and is therefore marked
|
||||
experimental. Below, various known problems and limitations are listed:
|
||||
|
||||
Peer IDs should be restorable from ~/.elinks/downloadhist.
|
||||
- Torrents should be added to the global history.
|
||||
|
||||
It needs to give up on unreachable peers.
|
||||
- Peer IDs should be restorable from ~/.elinks/downloadhist.
|
||||
|
||||
It should be possible to specify the download location.
|
||||
- It needs to give up on unreachable peers.
|
||||
|
||||
When the file is removed from under it (in the shell), either give
|
||||
a warning and stop downloading, or start over.
|
||||
- It should be possible to specify the download location.
|
||||
|
||||
Addition of a blacklist, either temporary (session) or persistant.
|
||||
- When the file is removed from under it (in the shell), either give a warning
|
||||
and stop downloading, or start over.
|
||||
|
||||
- Addition of a blacklist, either temporary (session) or persistant.
|
||||
|
||||
- Unsupported Tracker Protocol Error: When connecting to some trackers we get
|
||||
a returned failure reason reading:
|
||||
|
||||
unsupported tracker protocol, please upgrade your client
|
||||
|
||||
often this is due to the compact peer format is not enabled. We should maybe
|
||||
try to reconnect when this occurs.
|
||||
|
||||
- Multiple Trackers: The metainfo file can contain a list of tracker URIs so
|
||||
that the client can handle tracker request errors more gracefully by
|
||||
attempting to connect to a new tracker. Although this functionality should
|
||||
be simple to add to the client we have chosen not to implement this.
|
||||
|
||||
- Access to Disk: Currently, the are a couple of assertions in respect to disk
|
||||
access. Once pieces are completed they can never become incomplete again if
|
||||
something was to remove them from under the client. This is a valid
|
||||
assertion for most systems and usage. Furthermore, when writing and reading
|
||||
pieces, it is asserted that pieces are transferred correctly so that a read
|
||||
following a write will return the valid piece.
|
||||
|
||||
- All access to disk uses blocking I/O. With the many consecutive reads and
|
||||
write the client uses, this can potential become a problem that can end up
|
||||
stalling all execution if the piece length is very big. For this reason, the
|
||||
ideas outlined in regard to a more fine grained solution using
|
||||
block-oriented disk access is even more relevant.
|
||||
|
||||
- No download or upload rate limiting: All transferring happens
|
||||
unconditionally; in other words there are no means to limit the rate data is
|
||||
transferred. This can potential deny other services from running.
|
||||
|
||||
- Badly configured web servers: We have experienced that many web servers
|
||||
providing metainfo files are badly configured in that they do not correctly
|
||||
set the content type. We have therefore found it necessary to also allow
|
||||
application/x-torrent in addition to application/x-bittorrent. However, some
|
||||
servers set the content type to text/plain which, due to the way ELinks
|
||||
prioritises content types provided in the protocol header sent by the
|
||||
server, means that loading many metainfo files will not cause the BitTorrent
|
||||
download to be queried. As a workaround, the internal BitTorrent URI scheme
|
||||
can be used. This, however, will not open the download dialog, but keep the
|
||||
download progress entirely in the status bar of the browser.
|
||||
|
||||
- IPv6: Although certain informal extensions to the BitTorrent protocol, such
|
||||
as the compact peer information format returned by the tracker, are
|
||||
optimised for IPv4, the protocol works for IPv6. We have only tested the
|
||||
client under IPv4.
|
||||
|
||||
- Multiple Resumes: By default ELinks does three connection attempts. This
|
||||
can cause the resuming to happen multiple times if the initial tracker
|
||||
connection causes the main BitTorrent connection to timeout.
|
||||
|
Loading…
Reference in New Issue
Block a user