Some DHT code is already there by klaar, so we are already partway to the goal.

Most of the things at the "top" of the supervisor tree can probably be structured better than it currently is.

Rather than send Pids around like we do now, we ought to use a registry of process IDs via gproc instead.

How would you feel if your bittorrent client could IM you whenever a
torrent completed? How would you feel if your client could be directed by IM's?

Add IM support to etorrent.

Idea from Joe Armstrong.

Right now, every piece message will induce a message-traverse through the whole system. That means messaging for each 16KB we get in. I'd rather want to gather up PIECE messages if they can be seen as a bundle.

A bundle is a set of successive chunks. They are easy to detect. Several advantages are possible with this optimization: There is less work to do and when there is work to do we can scatter-gather process it in one fell swoop.

bg.gif 404s, which should be fixed.

This extension is a preliminary for many other extensions. So getting it right is fairly important.

There seems to be a problem with incoming connections. Investigate this problem and fix it.

Reported by Dale Harvey:

parsers is undefined
[Break on this error](function%28$%29{$.extend%28{tablesorter:new...g Zebra widget",time%29;}}});})(jQuery);

Requesting more peers is currently not done at all. We only get new peers
when someone chooses to connect and when we periodically contact the tracker.

There might be better strategies.

Some trackers support UDP requests. This is a fairly isolated piece of code
if anyone wants to hack it up. Many of the enormous trackers would be
grateful for us having this support. Furthermore, protocol handling is
erlang at its best!

Some of the oldest code I wrote in the project. It looks like crap. Fix.

We are currently not sending completed messages to the tracker, which is utterly wrong. We should fix this ASAP.

Add UPnP support to the client.

Or in general: Add UDP/TCP hole punching. Other clients support this
and it shouldn't be hard to add. Seems there are no BEP for it yet though :/

To support both BEP 12 and BEP 15 at the same time, some code is needed which does this correctly. Currently, we have a BEP ready which describes the interplay.

We are currently continuing much above the limit of 8. This ought to be fixed.

Support global bandwidth limitation.

This is done by a basic Weighted Fair Queue algorithm. Easy as hell to pull
off.

ince this is erlang it is easy to provide other storage engines than the
default. Some ideas are:

• Distributed storage: Rather than store data locally, allow the system to
  connect to another server that has the disk on it. Easily implementable and
  rather smart. You can probably even build it with staging so a nodeup on
  the storage server automagically copies torrents to it. Etc.
• mmap'ed storage: Write a C-node that is blindingly fast and provides
  storage in mmap'ed form. Would be good for smaller systems with little RAM.
  Combined with distributed storage because a Storage API is needed first.

There is a number of changes which must be done:

1. Globalize Piece Cache
2. Suggest pieces from globalized cache.

This is probably due to a calculation bug and should be fixed.

• I think the problem has to do with endgame.
• Make a logger which logs the presentation layer code errors so we can see what is going wrong. Inside the inets webserver, things are just silent when they fail.

The peer slot releases should be running on monitors rather than on the current setup where a peer cleans up after itself. It is a safer model.

One of the problems is that you may run out of space. By periodically
checking free space on the disk and the amount of data left to download one
can estimate if we have enough space.

This allows for early warning to log-places, eg syslog and friends. And it
allows for closing torrents when we are close to exhausting the space.

The problem is quite isolated and rather easy to implement.

This is definitely a candidate for v1.1, down the road.

The BEP does not seem too hard to implement really.

Transmission clients reporting versions TR1930 and TR2040 does not play too well with etorrent. Investigate why these clients provoke supervisor restarts.

Check out some of the work astro has made. Perhaps he has one :)

It would be really nice to have this as a DHT if needed.

This is a pure fun bragging project. Make etorrent hot-code upgrade itself
by having it download its hot upgrade and then deploy it on itself. Would
be fun to have for pure show-off.

We sorely need a full logging framework for etorrent. Investigate the possibilities.

This is a fairly important BEP, as I would like IPv6 support to be there quickly.

Step 1.

Move the pick_chunks code from chunk_mgr into the individual torrent processes. Only commit on the choice in the mgr. This evades a copy of a large gb_set.

Step 2.

Keep track of the pieces we have chunked currently. This number is small, so search with these as the iterator rather than the full piece set a peer has.

Step 3.

Implement the histogram. Two ETS tables: {{Torrent, PieceNo}, CountSeen} and {{Torrent, CountSeen}, [PieceNo]}. The latter is an ordered_set. Store the least CountSeen we know is there by an ExplicitMin functor on the structure. Search is by ets:next on {Torrent, CountSeen} until the torrent Id changes. If a piece has a count greater than THRESHOLD, it is abundant and can just be picked outside the histogram.

A simple etop call shows that the clear CPU-hugger is the etorrent_chunk_mgr. Use eprof on this process and figure out where it spends its time. This will probably lead to effective optimization oppurtunities.

We lack one.

There is some research you need to do w.r.t piece-size etc, but most of the
basic code for doing this should be here.

The currently weakest part of etorrent is the FS subsystem tied to
torrents. It sometimes takes some dives and crashes because of some race
conditions between processes in it. It can be fixed easily, but it will
take some time to do.

The change is not planned right now but rather for some later time.

In particular, it can run out of file descriptors, due to the way the system is created. We should definitely add some way of maintaining a LRU-list or something such.

And think about how to fix it permanently :)

Due to some code restructuring for rebar, the etorrent module is now renamed to be the etorrent_app module. But the console commands should still be called etorrent:Command(Arg, ...). To do this, move the relevant commands back to a etorrent module, which you have to add.

If a torrent is duplicate or tries to access a file another torrent has,
things go completely awry. Must be remedied by looking at what files are
there in the system and handling it gracefully.

I forgot this totally.

When we are stopping a torrent, we should clean up the torrent
from the mnesia tables. This is currently not done properly.

A thing to think about is who should do the cleanup: It would
be best if it is the process itself I think.

Here is the error from the shell:

12> etorrent:l().
Id: total left uploaded downloaded I C Comp.
** exception error: bad argument in an arithmetic expression
in function etorrent_rate:eta/2
in call from etorrent:'-list/0-fun-0-'/2
in call from lists:foreach/2

in call from etorrent:list/0

Currently, the rate management code returns the wrong data since the same rate is pushed twice into it. This should be fixed, but while one is there, it could be beneficial to document the process and to make sure there are no other bugs hiding along.

Rather, we should use monitors to track that the peer is dead in the processes and then remove the state. It has better code locality, and it is the right way to do things(TM).

I thought I got this done, but it seems I did not, unfortunately. When we go from a leecher to a seeder mode, the old rate sparkline entries should be invalidated so we begin freshly again. We are now reporting leeching values in the seeding values, and this is wrong.

This issue have two main tasks. One is to support the partial downloading of files inside a torrent. The other is to support the extension so you can tell other clients and the tracker you don't intend to download all files.

Add RSS Feed support to etorrent.

Here is the line I use to grep for the remaining modules:

 jlouis@illithid:~/Projects/etorrent/src$ grep -c -- '-spec' *.erl | sort -t: -k2,2 -nr

The storage subsystem is currently a bit naive. It can be optimized easily by changing to writev and readv calls rather than the current construction.

For some reason, this module hid under the radar when we spec'ed modules. Fix it by writing specs for it.

Implement scraping for trackers. We are going to use it later on, I am
sure. Also, research where it needs to be used, because I have not done so yet.

Currently, when we go from a leeching to a seeding state, we just keep the sparklines there. We ought to clean out the sparkline as well so we can get the right values from the beginning. Right now you have to wait 25 minutes for the sparklines content to disappear.

The install steps dont mention that you require rebar to be installed, it isnt a big deal but probably worth documenting or just packaging rebar

Basically, we want to take an educated guess based on the current rate with some minimum possible. The change should be fairly simple and fairly small.