Bittorrent Client: Part III
So our project is "done".
But we're pretty far from functional.
Functionality we have: our client successfully parses torrent files, talks to trackers and gets the peer list, and initiates connections with peers, sending the "handshake" bytes. Beyond this, we don't do much communication with the peer.
We have code to perform this communication, and weird bugs to track down. The code is in place to send request messages for blocks, download and verify them, and write them to files without consuming massive amounts of memory, but we need to debug all of this code, and to do that we need to communicate with peers.
This summer we'll continue working on this project. We'll start with a restructure. Peer I/O is spread through several methods and it all needs to be done in the same place.
We don't yet have peer seeding algorithms in place, or a way to differentiate and prefer faster peers over slower ones. This is next to do on the list. Using the subversion Eclipse plugin we used, I put together some data about the project.
| entire project: | 1831 lines of code |
| decoding torrent files: | 228 lines |
| communication with tracker: (reading peer lists, etc) | 144 lines |
| communication with peer: (initial handshake, sending/receiving messages) | 931+ lines |
| 5-26 | 4 hours | 5 revisions |
| 5-27 | 3 hours | 8 revisions |
| 5-28 | 2 hours | 4 revisions |
| 5-29 | 4 hours | 3 revisions |
| 6-01 | 48 hours | 86 revisions |
| 6-02 | 31 hours | 84 revisions |
| 6-03 | 53 hours | 78 revisions |


1 Comments:
I sure hope those hour totals are cumulative.
Post a Comment
Links to this post:
Create a Link
<< Home