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 ] 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 ] 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