It's not quite how I want it yet, but it's getting there.

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.

be shared by several peers. At least in end game.
* Link blocks with the peers we are loading them from and vice versa.
* Limit the number of requests / peer in end game too.
* Improve end game by using some sort of round robin for block requests.

to build with glibc.

writing to a peer. If more requests arrive they will be ignored.
When all pieces have been sent to the peer, in order for it not to
wait on the ignored requests, its state will be reset by a choke
followed by an unchoke message. 

Without this limit there was no bound on how much memory btpd would
consume to satisfy a greedy peer.

* 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.

being sent too early it could now be sent too late.

Change version to 0.5 and document the bug fix.

be extracted from the buffer data instead. Created functions to do
that.

gotten new request if the piece was fully downloaded and found
to be bad.

Each piece must have at least one byte for their block bit array,
  or they will collide causing great confusion in btpd. The calculation
  was done wrong so this could happen for small torrents (blocks / piece < 8).

policy_subr.c:
  * Add test for correctness.
  * Add missing call to cm_on_piece_full in cm_new_piece.

* Add function net_unsend to safely remove network buffers from a peer's
  outq. Use it where needed in peer.c.

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.

This fixes a bug where  peer could miss pieces btpd got while the
peer was in handshake.

Also, btpd now sends multiple have messages instead of a bitfield
when it's better to do so.

Since the set hz is (almost) never achieved the denominator is now based
on the average hz the last 5 seconds.

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.

be killed.

* Don't decrease busy count on a piece when a block arrives in end game.
  The busy count should always be zero at that stage.

Add test for program correctness.

Added test for program correctness.

totally correct. Since there's a possibility that we've assigned
requests to peer and then decreased the wanted level, we could've
missed peers with requests but a wanted level of zero.

Now we check if the peer has any requests instead.

added to the torrent list. This bug crept in because this file was
based on an earlier version of policy.c.