Implement Recovery

[Dannyps]

Depends on #31

[Dannyps]

This sucks. We can't make the thread that sends the initial GETCHUNK messages wait for CHUNKs that may never come. Thus, we will not. There will probably be a support structure taking note of the start time of a GETCHUNK request. If after some time we don't have all the chunks, we can merely say that not all necessary peers are up in order to restore the file. Besides, the specification does not say anything about retrying.

[fabiodrg]

Although we don't like the approach used for PUTCHUNK messages, maybe we can take a similar approach here.

[Dannyps]

The only reason we had to retry was the fact that the receiving socket (on the requester peer, aka the initiator peer) could become easily overwhelmed with data. This happens due to the fact that it sends all GETCHUNK messages without waiting for the replies to the first ones. We could make it wait (and thus preventing full queues and thus, dropped packets), or we could make it wait a random interval between each GETCHUNK message. These are the alternatives I can see that wouldn't make this process much harder than it already is.

[Dannyps]

e3178d0 closed part of this issue. However, the structure used to detect that other peers have sent chunks must be purged after some time. A comment with a TODO has been added on ad067f8.