今天用酷狗搜索音乐，突然顿悟
原来酷狗使用了原始的P2P思想，把每个人的音乐共享出来，这样大家就可以互相搜索了，而且也可以随便下载，本身并不用花费很大的代价，这个思想太有才了
1、每个人安装客户端，
客户端与服务器通信方式：
1、客户端不是时时刻刻跟服务器相连，每次连接后保持连接一定的时间，也可能是马上断开（如果考虑到服务器负载的话）
2、一些必要的东西是从服务器获取的，歌曲排行等等
3、客户端每次跟服务器连接的时候，除了获取自己想要获取的信息外，可能还接受一些服务器指派的任务，比如搜索之类的
搜索部分：
1、客户端搜索本地硬盘上的音乐，根据既定的规则读取音乐信息，比如歌手，歌名形成列表
3、将列表作为该客户端可以共享给别人的音乐列表
4、当一个客户端发送搜索请求的时候，服务器可能进行几种处理：

• 第一种，服务器将搜索请求发送给所有当前跟服务器有联系的客户端，每个客户端搜索自己的共享音乐列表，然后将结果直接发送给发出搜索请求的客户端（或者通过服务器转发给那个客户端。这种方式不可取，服务器负载太高，一个是要求有所有客户端时刻跟服务器连接，在一个搜索结果可能把那个客户端给淹死
• 第二种，客户端将搜索请求直接发送给服务器，服务器将该请求发送给当前跟服务器有通信的客户端，收到搜索任务的客户端搜索本地的音乐列表，如果搜索到了就将相关的信息发送给服务器，或者直接发送给那个搜索的客户端，收到搜索任务的客户端会判断一下，比如搜索任务超时之类的或者跟目标客户端通信的速度太低，或者不可连接什么的，这种方式也不太可行，服务器的负载还是太高，而且貌似客户端的负载也太高
• 第三种，客户端有一个最近联系的其他客户端连接信息列表，跟其他客户端的任何通信都会更新这个列表，当客户端有搜索请求的时候会同时发送给服务器和列表中的所有客户端，服务器会根据发出请求客户端的特点（网通还是电信、IP地址段等等）将该请求发送给相关的客户端（可能在所有符合条件的客户端中挑几个），收到请求的客户端搜索本地的音乐列表，如果有结果就将结果发送给最初发送查询请求的那个客户端，这些客户端还可能将搜索请求发送给自己的最近联系客户端列表中的客户端，并通过在查询请求上增加一个转发次数计数，如果这个计数大于多少就不再转发，受到搜索请求的客户端同样处理。在传播的过程中有可能因为搜索转发次数太多而终止传播，也可能根据请求发送的时间来决定是否继续转发，或者是否处理，这种可能性很大哦，hoho，反正如果我设计这种方案最终肯定会被采用，因为服务器的负载最小

音乐下载部分：
1、音乐下载部分没什么好说的，一般的P2P下载处理，服务器或者客户端发送给该客户端搜索结果的时候就说明可以从哪里下载，直接连接过去就可以了，这部分没什么悬念

总之来说，目前这种P2P的思想真的很强大，这一切都开始于BT，至少我知道的是这样啊，说错了你就赶快告诉我，呵呵，开始的BT只是用来下载，可是现在可以用来听音乐和看视频，似乎无所不在，P2P的好处就是，不需要有一个很强大的服务器，每个人在获取的同时也在贡献，嗯，很有前途，也许目前的云彩也是基于这个原理，或者云彩可以向P2P多靠近一些哦，hoho
上面的分析纯属一些愚见，偶尔想到的，也许大家早就明白了，算是与君共勉吧，已经明白的多多指教，还没明白的，咱们一起探讨