CMU440-P1:Distributed Bitcoin Miner(分布式比特币挖矿机)

本项目是卡耐基梅隆大学的课程分布式系统(CMU440)课程项目。
课程主页：http://www.cs.cmu.edu/~dga/15-440/S14/syllabus.html
程序代码：https://github.com/ZhouJiahui/CMU440/tree/master/P1-Distributed_Bitcoin_Miner


partA的任务是实现lsp协议。它提供了一些位于tcp和udp之间的特性，但也有一些它们没有的特性：
1，不像udp或者tcp，它支持客户端服务端通信模型。
2，服务器维护一些客户端，这些客户端使用一个数字id标识。
3，服务端和客户端之间的通信由每个方向的一连串具体的消息组成。
4，消息大小不超过单个udp包（1000比特左右）。
5，消息发送是可靠的。一个消息发送到网络上以后只会被收到一次而且多个消息必须的接收顺序必须和发送顺序一致。
6，服务端和客户端会监控他们的连接状态，并且会探测对方的连接是否断开。
partB的任务是使用lsp协议实现一个简单的分布式系统。
你的分布式系统包括下面三部分：
客户端：一个lsp客户端包括发送特定的用户请求给服务器、接收和打印结果，并退出。
挖矿机：它是一个用来用来持续接收来自服务端的lsp客户端，它会全力计算特定范围内的nonce，然后向服务器发送最终的结果。
服务端：一个lsp服务器会管理整个bitcoin流程。在任何时刻，服务器都能够接收来自任意客户端的任意请求。对于每个客户端请求，它会将请求拆分为多个更小的工作任务并将它们分发给可用的挖矿机。服务器会等待挖矿机返回结果再生成并发送最终的结果给客户端。


一些值得注意的地方：
partA
1，如果上层不调用Read怎么办？
一种容易想到的实现Read的方法是将每次滑动窗口收到的数据发到一个channel中，Read从这个channel中读取。这种方法有个问题是如果上层一直不调用Read（也许很少见），那么数据不断增加，channel早晚会阻塞，整个网络库就会崩溃。正确的做法是通过一个变长的数据结构如list来存储待Read的数据，channel只做数据传输，不做存储。
2，如何实现超时重传。
3，如何实现滑动窗口。
4，如何在关闭时保证对应的goroutine和连接关闭，同时该连接上的数据要保证被发送出去和确认？
partB
1，如果没有miner加入的时候，server能够暂存这些请求直到有miner加入。
2，如何拆分请求变为多个更小的job。
3，如何做负载均衡，避免每个请求总是打到同一个miner上。


测试结果：
我的代码可以在不同机器上稳定通过所有test case，且无竞态。