Tuesday, July 20, 2010

Requestin' Blocks in Bittorrent (Part II)

I've worked on a XPCOM component to figure out what block (piece subsection) to request next. The component is probably complete, it's passed parsing and there are no exceptions on calling methods. I've got an idea for a set of tests, so perhaps I'll write that before releasing the code.

I expected to just write code to identify the next block to request, however it kept growing as the decision became influenced by more variables. In the end, the decision of what block to request came as a result of (i) what had already been downloaded, (ii) rarity/what has already been requested, and (iii) what messages have been sent/received from the peer. The third item grew the component so that it now functions by responding to peer messages. The table below summarizes how the component has been written to respond to incoming messages.

General behavior of bittorrent perhaps?
Received MessageResponse Message
BitfieldInterested (if peer has pieces we don't)
HaveInterested (if peer has pieces we don't & we haven't sent Interested)
UnchokeRequest (if they still have pieces we don't) else Not Interested
Not InterestedChoke
PieceRequest (if they still have pieces we don't) else Not Interested

What isn't covered here, though I think is probably appropriate, is a timeout associated with each peer that will either send Have messages of completed pieces since last timeout, or a keepalive. I haven't written the timeout, but provided it existed and worked in such a manner, there doesn't really need to be any more intelligence in the program, with the exception of handling bandwidth.

No comments:

Post a Comment