毕业设计——BitTorrent客户端（一）
从苏州回来以后还是一直在写自己的毕业设计。题目是我自己选的，做一个BitTorrent客户端，并且在这个基本的客户端上加入我自己设想的独特功能，使这个客户端更加强大。从研究的角度讲，我认为这个题目还是比较合适的，对我个人来说，实现BitTorrent客户端绝对是一个合适的挑战；对计算机领域来说，如果我设想的独特功能被证明是有意义的，那也是有价值的。
当然，要实现“独特功能”，首先得把那个基本的、能够和现有别的客户端通讯的底层做出来，而这个才是难点所在。想一想，虽然一篇BitTorrent协议不算长（和IA-32、FAT这些比的话），但需要实现的东西还是挺多的：
按照协议的顺序，首先要实现bendcoding的解析器，这个在解析torrent文件和解析tracker服务器响应时都会用到。除了解析，还要提供接口，让外部访问者能获得结构化了的数据。
其次，要能和tracker服务器通讯。要充分考虑到tracker可能发生的各种情况，如连接失败，需要重定向，返回无效数据，返回错误，以及返回理想信息等。做到后面还要考虑多线程向多个tracker服务器发送请求，维持请求间隔时间，使用代理服务器访问等等。
再次，要能和各个peer通讯，传输数据。这部分其实就是在博弈，在你我都不知道对方规则的情况下各自制定一套规则，规则本身是由协议里面定义的消息元素来构造的，但是具体细节完全是由你我自己控制的。然后大家在一个对等的平台上，通过规则进行通讯，双方的目的都是在不违反对方规则的同时使自己获得最大的收益。比如，我可以一次向某个peer发送很多请求，但如果这个peer很忙，他就有可能choke我，一个可能更好的策略是，分散请求面，首先请求最稀少的数据块。自己获得最大利益并不意味着要损害对方，最好的结局是双赢，所有人都最终得到完整的数据。当然除了博弈这个算法的问题外，还有很多基础的网络问题要解决。
最后，还要把各个模块整合起来。比如在向tracker服务器发送请求时就要提供当前任务已经下载和上传了多少数据量。而这个数据量显然是要在和peer通讯时统计得到的。类与类之间肯定需要一个中间层来联系。像这种耦合在程序里实在不少，因此架构设计也是需要非常谨慎的。
原本打算还要把图形界面加上，做成一个完整的可发布软件，现在看起来一是时间不够，我实在是找不到能在短时间内实现像uTorrent那样界面的GUI解决方案，二是觉得作为毕业设计，界面确实不是最重要的，不能喧宾夺主嘛。所以界面的事可能得先缓一缓了。
下一篇里我会介绍一些我客户端的框架和一些实现细节，也算是为论文先打个草稿啦。
