- John Gunderman documented a queue interface and helped me with haddock.
- The code doing SHA1 Digests have been abstracted into its own module.
- We now handle interest as intended in the bittorrent protocol. We update interest based on what peers tells us they have available.
- We now pick pieces in Random order rather than linearly.
- We correctly inform peers when we have retrieved a full message by sending them HAVE messages.
- We can now track how many bytes are left on a torrent. This is needed for the tracker.
- We have some preliminary rate calculation code, based on a 20 second window and running averages. It ensures a somewhat fair treatment of the rates of different peers.
- The Choke Manager now uses the rate calculation code to choke peers based on their current speed.
- The Readme file has been updated with what extensions and protocol-parts we support.
The current goal:
We currently aim for two things: BEP-003 support and a preview release (version 0.1). The BEP-003 is the support for the basic bittorrent protocol with no extensions at all present. This is the bare minimum needed to be able to call ourselves a bittorrent client. The list of missing items for BEP-003 is as follows:
- When the torrent file is initializing it needs to calculate how many bytes there are left to download before completion. This number is reported to the tracker.
- We need to make sure that the tracker is informed of Torrent completion in the right way.
- The client will have to handle multi-file torrents. That is, torrents where there are more than one file. We can punt this to after the preview release if needed, because it is not that important for a preview of the client.
- We must correctly change to a seeder mode when the torrent file in question completes. This is currently not happening.
- We use a Pure Haskell SHA1 checksum code. Rather than doing this, we should outsource our digest calculation to OpenSSL through the hsopenssl package. The abstraction should make this easier. This is not strictly needed for BEP-003, but it is nice to have.
The client will currently not handle the endgame in any special way. This means that a torrent will take considerably more time to complete. On one hand this would be nice to have before the preview release. On the other hand, I think it is better to bump it.
On the Preview:
The preview is not a working client. The purpose is to get the client tested in different environments by different people so we can find some bugs and get them sacked. I would like to have a client which has shown itself able to download files in non-lab environments, but perhaps with many bugs still left. This is also to get a test of the release engineering involved in the process. The release will also mark a milestone in the development: we can use it as a stepping stone and a breathing space while we decide what to work on next.
The plan is to use hackage for the release. I am using the Haskell Platform here - but that means GHC6.10.4. We could use a couple of compilation tests on what will become the next Haskell Platform. I am afraid we use some stuff which changed. A quick heads up would be nice.
Also, before the release, I would like some janitorial code work done. I have not enabled -Wall while developing, but around now might be the time that someone enables it and begins cleaning up dead code, limit module exports and similar janitor-work.
Watch this blog. The moment the client has downloaded its first non-lab torrent will be worthy of an announce. I can't predict the future, but my gut feeling says it is going to be soon.
(Note: The layout of this post is miserable. This is what you get in return for using blogspots built-in editor :)
