TODO

   1 %%% Local Variables:
   2 %%% mode: todoo
   3 %%% End:
   4 ----------------------------------------------------------------------
   5 -- This is a list of what To Do before a release is ready to be made.
   6 --   Keep the style please. Can be read with emacs org-mode
   7 ----------------------------------------------------------------------
   8
   9 * Who clean up what? [Milestone: 1.0]
  10    Go through each table and decide who "owns" the right to clean it
  11    up. It should definitely be checked.
  12
  13 * etorrent_t_sup: Just start everything right away? [Milestone: 1.1]
  14    Rather than having the code start things one at a time from the
  15    Control, it is much more robust just to have etorrent_t_sup start
  16    everything right away.
  17
  18    Think about restarts!
  19
  20 * It takes too much space to use #chunk_data [Milestone: 1.1]
  21    To fix this we can move store_chunk down and make it into an FS
  22    operation. That way we should be able to do it much much simpler
  23    than now. We also get rid of the store_piece call in
  24    etorrent_piece. All in all, the code will be much much simpler that
  25    way and will not have to keep that much data in memory.
  26
  27 * Profile and minimize the critical path [Milestone: 1.1]
  28    It looks like the critical path takes a wee bit too many clock
  29    cycles. It might be possible to cut it down considerably by
  30    profiling and optimizing that path.
  31
  32    I want to do something about it, but not right now. Hence in
  33    Milestone 1.1.
  34
  35 * Use passive sockets [Milestone: 1.1]
  36    We need to use passive sockets at some point. The reason is that
  37    active sockets have no flow control, and the granularity of whole
  38    packets are bad from a choke/unchoke perspective. The code that
  39    needs change is rather contained, luckily, and can be placed in
  40    peer_communication.
  41
  42    An even more sinister idea: change to active sockets when the rate
  43    of the peer exceeds a certain set amount to cut down the amount of
  44    processing needed. We *do* have some flow control as a peer will
  45    only send things we requested, so a peer can't overflow us by more
  46    than that anyway.
  47
  48 * DOCUMENTATION!
  49 - Pick functions at random, and document what they are doing.
  50   It is /especially/ important to document library calls and
  51    non-standard internal functions in OTP modules.
  52
  53 * TorrentPeerMaster [Milestone: not decided]
  54 - Figure out a better choking/unchoking algorithm.
  55   The current algorithm is the original one. We should look for a
  56    better algorithm and implement that. Suggestions for digging:
  57      ** Azureus
  58      ** Mainline
  59      ** Bittornado
  60      ** rtorrent
  61
  62 * Cleanups
  63 - Decide what to do if we connect multiply to the same IP
  64
  65 * Temporary IP-ban on errors [Milestone: 1.1]
  66   If we find an error on a given peer, ban him temporarily for some
  67    time.
  68
  69 * ROBUSTNESS [Milestone: 1.2]
  70 - In general, robustness is not really taken care of. We ought to make
  71   the system more robust by not relying so much on Pids etc.
  72 - What happens if process X dies
  73   Go through all processes, and think about what happens if it
  74    dies. Ensure that the system is robust.
  75 - List of processes to check for it:
  76    etorrent_acceptor.erl            etorrent_sup.erl
  77    etorrent_acceptor_sup.erl        etorrent_t_control.erl
  78    etorrent_bcoding.erl             etorrent_t_manager.erl
  79    etorrent_chunk.erl               etorrent_torrent.erl
  80    etorrent_dirwatcher.erl          etorrent_t_peer_group.erl
  81    etorrent_dirwatcher_sup.erl      etorrent_t_peer_pool_sup.erl
  82    etorrent.erl
  83    etorrent_event.erl               etorrent_t_peer_send.erl
  84    etorrent_fs_checker.erl          etorrent_t_pool_sup.erl
  85    etorrent_fs.erl                  etorrent_tracker_communication.erl
  86    etorrent_fs_pool_sup.erl         etorrent_tracking_map.erl
  87    etorrent_t_sup.erl
  88    etorrent_listener.erl            etorrent_utils.erl
  89    etorrent_metainfo.erl            etorrent_version.hrl
  90    etorrent_mnesia_init.erl         http_gzip.erl
  91    etorrent_mnesia_table.hrl
  92    etorrent_peer_communication.erl
  93    etorrent_peer.erl                tr.erl
  94    etorrent_piece.erl
  95
  96 * Add another state for #piece records [Milestone: 1.2]
  97    The state 'chunked_no_left' should indicate that the piece has been
  98    chunked, but there are no chunks left to pick from it. The state is
  99    introduced when we empty the #chunk record with not_fetched for the
 100    #piece and it is reintroduced in putback_chunks so we may again
 101    pick from it. Also, in the endgame, we should pick off from this
 102    state.
 103
 104    It turns out to be an optimization, so put it into 1.2 for now. It
 105    is not obvious that it will give anything.
 106
 107