* Added a thread and api for http requests. The thread uses the curl multi
interface and will be used by the tracker code. The tracker code currently
use forked processes to do its bidding.
o Unhook cli_if.c from build temporarily. It needs to be fixed.
o Torrent meta data is now kept in subdirectories to $BTPD_HOME/library.
o Added some very incomplete life cycle logic for torrents.
pieces we and blocks we have, it'll do the writing and reading from disk
and test pieces against their hashes.
This is only a dummy implementation of the api. I'll flesh it out in
subsequent commits.
and net_del_torrent does the opposite (surprise!).
* Some code shuffle has been done to separate net_ and dl_ from torrent_
but there's still much to be done.
* Removed a couple of dead vars from struct torrent.
* Renamed the policy* files to upload* and download*.
* The upload (un)choker is now global instead of per torrent. The algorithm
is not yet implemented however.
To be continued...
* The peer rates are now only updated when data transfer is enabled
in the corresponding direction. They are also computed differently
from before. The rates are computed in the bw callback once a second.
This facilitates later improvements in the choke algorithm.
message when we no longer have any pending requests. This fixes a bug
where two uniterest messages were sent to a peer that was no longer
wanted in endgame.
rid of the global btpd struct. Some fields in the struct got a corresponding
global variable whereas some was made static and moved to a module.
The bandwidht algorithm also got tweaked. It now tries to fire the event
at specific times. This was to make the code simpler. It'll probably have
to be tweaked again :P
First step to make btpd run from a directory where it'll keep the log,
socket, configuration, data on the known torrents, etc. Btpd now uses
flock on the pidfile instead of connecting to the socket in order to
be reasonably sure that no other btpd runs in the same directory.
message followed by an interest message. Optimize this but not sending
those messages in that case. This is better becasue we don't risk to
trigger a choke from the receiving peer.