Strangely such connections are not entirely uncommon. Added a hand shake
time out of 60 seconds to resolve this.
Added a peer_on_tick function which is used to monitor peers for different
timeouts. Timestamps are compared against the reborn btpd_seconds.
The issue has been reported by Ludvig Omholt and Arnaud Bergeron.
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.
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.
* Use the new net_bufs where it makes sense.
* Take advantage of the reference count on net_bufs and only allocate
the (un)choke and (un)interest messages once.
information on what data they hold, making it unnecessary to have
other lists tracking that information. Also they now have a reference
count, making it possible to use the same buffer on many peers.
This is only a start though. I've just done enough for btpd to work,
I haven't taken advantage of the reference count yet.
Let the default be 8 hz for now.
Removed a try at time correction. I don't really think it'll matter and
there was a potential bug if the clock went backwards.
Removed net_by_second. Let the peer bandwidth calculation be handled in
cm_by_second.
The net code now calls the peer code when it has read a full message.
This has mostly involved moving code from net.c to peer.c.
* Added torrent_piece_size helper function.
save uncomplete messages. I had forgotten about the four bytes of
message length preceding the message. A buffer overflow could occur
because of this. Ouch!