[erlang-questions] [ANNOUNCE] etorrent v0.9
Jesper Louis Andersen
jesper.louis.andersen@REDACTED
Wed Jul 16 18:07:25 CEST 2008
Hi!
I am happy to announce etorrent v0.9, another beta-release of a
bittorrent client for Erlang. Many improvements have happened in the
source code and the new version works better than the old one. While
we have added functionality, the number of code lines is pretty stable
because many things could be shaved away. ohloh.net reports some 3400
lines of code in this release, not counting comments.
You will find that this release acts much better than v0.8. We begun
attacking the parts of the bittorrent protocol that are not specified,
but absolutely necessary if one wants adequate performance from the
client.
The ETA for v1.0 is currently unknown. It will take more time than the
transition v0.8 --> v0.9 though.
And finally the shameless plug: I need a half-time job around the
Copenhagen area in Denmark. And of course, an Erlang (or another
functional programming) job would be preferred. Mail me, and we might
be able to cook something up.
Main web page: http://code.google.com/p/etorrent/
Git repository: http://repo.or.cz/w/etorrent.git
NEWS:
Version 0.9:
This is yet another Tech. Preview release. The torrent client works
to the point where it can be used to download things, but it have
not seen much testing yet and there are numerous places it can be
improved still. Yet, there are so many changes, that it warrants a
new release.
The current regressions revolve around a high CPU usage at times. We
expect to tackle this problem next with some profiling. We also
expect to tackle fast resume support as the main "new thing". And
some 10 things in the issue tracker and the TODO lists for the
next release. I don't expect it to follow as fast as this one.
One development methodology change worth mentioning: the git
repository now uses several branches laid out as described in
doc/git.txt. Tracking the 'master' branch ought to provide you with
a system that is stable at all times, while tracking the 'next'
branch gives you the 'cooking pot' of new things that ought to be
tested. We'll try to keep 'next' stable, though it may have problems
at times.
Changes:
- There is a set of new commands for viewing what is currently
cooking in the torrent client. etorrent:l/0, etorrent:s/1,
etorrent:h/0. Implemented with help from Tuncer Ayaz.
- Changed build infrastructure. No more autoconf. It simplifies the
build structure considerably. Introduce the use of EMakefile for
building the erlang parts of the system. Reinstate all make targets
and add a 'tags' target for building a TAGS file.
- etorrent now correctly handles the 'min_interval' tracker response
parameter. It is not strictly part of the spec, but everybody uses
it.
- Add support for installing etorrent. A shell-script, etorrentctl,
is provided to control the etorrent daemon. The installer, while
overly simple, has not seen much testing as of yet and may not
work. It will be tested before v1.0.
- etorrent no longer pre-fills files it want to download with
junk. It uses the semantics of fseek() to make a file of the right
size initially.
- several ETS restructurings has brought the memory use
down. Before, etorrent would take some 660 megabytes of memory
running 20 torrents. Now it is more like 50-80 megabytes for 20
torrents. More can be shaved but this is a good start. Also, memory
usage still occasionally spikes because we are doing nothing in certain
situations to limit it.
- New choking/unchoking algorithm, based on a combination of
BitTornado/BitTorrent/Transmission. This is not the smartest one can
do, but it follows the spec more or less precisely.
- Event Publisher. A gen_event OTP behaviour one can subscribe to and
get information about the system. A logfile subscriber is there by
default.
- Rate calculation optimizations. etorrent now uses a running
average over a period of up to 20 seconds to measure the rate of a
peer. This yields a more fair measurement of individual peers so we
claim the best peers. While here, change the sockets to be passive
for now. It bumps the CPU-usage, but makes the rate calculation more
precise. There are several optimizations possible revolving around
passive/active sockets.
- Robustize the supervisor tree. etorrent is now less likely to die
due to a crash somewhere in the tree. It is not entirely safe yet,
but it will be during the next releases.
More information about the erlang-questions
mailing list