[Haskell-cafe] ANN: HaskellTorrent v0.1.1

Hello Cafe, I am pleased to announce yet another release of the HaskellTorrent project. In this release, focus has been on improving upon the work laid in v0.0. Highlights include: * Certain data structures have changed from Data.List to Data.IntSet, yielding much improved performance. * Addition of a GetOpt option parser. * Use of test-framework to run unit-tests. * Assertion optimization, cutting down CPU usage by quite a margin. * Change SHA1 checksumming to use Peter Simons hopenssl package. This plugged some serious memory leaks. * Support for listen() on port 1579 so incoming connections get handled correctly. * Support for more graceful stopping. The supervisor tree is now terminated in the opposite order of creation. * When closing down, tell the tracker we are stopping. * Add KeepAlive messages on idle socket connections. * Improve the console interface a bit so it is quasi-usable. * Change the logging framework from my own to hslogger by John Goerzen. It is better than my attempts and it shaves 150 lines of code from the project not having to maintain a logging framework. This also makes the client BEP003 compliant, so we can now claim to be a full BitTorrent client. Looking forward, I'd like to get less CPU usage, and support for more BitTorrent extensions. -- There are still bugs in the code, so watch out for spinning processes. Also, performance is still far from optimal. From a profiler run, we get the following: total time = 64.26 secs (3213 ticks @ 20 ms) total alloc = 6,712,153,496 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc MAIN MAIN 58.0 3.7 assertPieceDB Process.PieceMgr 13.4 29.6 logP Process 3.7 6.0 syncP Process 2.8 12.1 download Main 2.1 0.0 updateBS Digest 2.1 0.0 recvP Process 2.0 4.3 chooseP Process 1.9 7.0 receiverP Process.Peer 1.8 1.5 peerP Process.Peer 1.2 0.6 grabBlocks' Process.PieceMgr 1.0 3.1 senderP Process.Peer 1.0 1.4 sendP Process 0.9 3.1 checkPiece FS 0.7 6.1 msgPeer Process.ChokeMgr 0.6 2.4 registerL Process.Timer 0.2 1.9 getByteString Data.Serialize.Get 0.2 1.0 newBuffer Data.Serialize.Builder 0.0 10.1 which tells us we are still allocating far too much memory. I wonder what the 58.0% on MAIN means (this is with -prof -auto-all -caf-all). The code is heavily concurrent, using the cml package. My guess is that we have somewhere between 500 and 1000 threads when running. I ponder if that has something to do with it. The price of assertPieceDB can easily be removed by running the assertions at a rarer pace. -- J.