This list constitutes work which have to be done. We are trying
to list the level of -Ofun! a given task will have. There is a
strong correlation between the -Ofun! level and how much risk
a risk analysis would tie to a given part of the project. This is
totally coincidential ;). The fun parts are those we do not know
how to solve yet in detail.
If you want to add something to the list, do so. If you want to work
on something on the list, coordinate via conjure@lists.urchin.earth.li.
Grep for FIXME/TODO in the code.
================================
Faster sha1 hash check.
=======================
We should save our piecemap (with an option for ignoring it) and only
recheck downloaded pieces.
Optimize HTTP library.
======================
The tracker in bittorrent communicates by HTTP. Thus, we need a fast
HTTP library to be able to fetch files from the tracker. Fix this by
using FPS in HTTP.hs. -Ofun! level is low.
[Is this really important? We don't need to contact the tracker all
*that* often, do we? --SamB]
[No, but it's an easy task that'll make Conjure use fewer resources.
--Lemmih]
Construct an implementation of khashmir
=======================================
khashmir is a distributed hash table (DHT). We need an implementation of this
to support trackerless torrents.
Build the Option Parser
=======================
[Contact: Jesper Louis Andersen <jlouis@mongers.org>]
STATUS: I was bored and built a preliminary option parser.
The config file parser stuff still needs doing. Any volunteers?
Are you new to Haskell? Want a simple task? Begin building the Option
parser for Conjure. You'll learn a bit about module structure and how
the getOpt framework in Haskell works. This is simple, but I'll
gladly volunteer to help you out if/when you get stuck.
If you want really bloody hands, you can begin building a simple
configuration file parser. The path you take is up to you: You can
rely upon the MissingH package and use its config parser. If you want
a bit more fun, you can define your own little config language and
Parsec away on it.
You can also take a look into Reader monads for the configuration
environment.
Research into effective storage management
==========================================
[Workers: Jesper Louis Andersen <jlouis@mongers.org>]
I have a hunch: The original bittorrent client is ineffective when it
comes to the FileSystem. I think it is wasting a lot of processing
power moving stuff around and that there are evil evil race condition
and atomicity problems in it as well.
Currently I am researching how to do this more effectively. Sending
files on FreeBSD with high speed is easy: We use sendfile(2) and then
we can forget entirely and completely about the file until it
completes. We have to compute the transfer rate though for the choker
can work its magic, but I think it is possible.
However, Linux doesn't have sendfile(2), so we need to use its corking
features. If somebody is able to provide me with information about
this, I would be grateful.
(As a side note: It is sendfile(2) that makes things like kernelbased
HTTPd servers irrelavant. It is extremely fast and uses zero-copy).
We also need to see if using stuff like kqueue() can benefit the
client. Of course we will need to play along with the FFI, but for
speed, nothing can beat it.
I propose we go for a simpler thing in the beginning, but we need to
design the code such that we can utilize sendfile() later on.
The simpler designs are to prefill the data on the disk with NULLs
before getting the file. It has the advantage of ensuring we can get
the whole file too and ensures we do not have to move around files
later.
We can also opt for sparse files. MLdonkey does this. Problem is that
the kernels are normally not optimized for manipulating them.
We can even simpler just let lseek(2) do its stuff on 0-byte sized
files. This is what the original bittorrent client seems to
do. Anyway, there is more to do in this world.
Proper (un)choke algorithm
==========================
Paper by INRIA
(http://hal.inria.fr/docs/00/05/86/99/PDF/bt_experiments_techRepINRIA-00001111_VERSION1_13FEBRUARY2006.pdf)
contains a very detailed descriptions of what we ought to have
Decode client name from peer ids
================================
http://wiki.theory.org/BitTorrentSpecification#peer_id