今天用酷狗搜索音樂，突然頓悟
原來酷狗使用了原始的P2P思想，把每個人的音樂共享出來，這樣大家就可以互相搜索了，而且也可以隨便下載，本身并不用花費很大的代價，這個思想太有才了
1、每個人安裝客戶端，
客戶端與服務器通信方式：
1、客戶端不是時時刻刻跟服務器相連，每次連接后保持連接一定的時間，也可能是馬上斷開（如果考慮到服務器負載的話）
2、一些必要的東西是從服務器獲取的，歌曲排行等等
3、客戶端每次跟服務器連接的時候，除了獲取自己想要獲取的信息外，可能還接受一些服務器指派的任務，比如搜索之類的
搜索部分：
1、客戶端搜索本地硬盤上的音樂，根據既定的規則讀取音樂信息，比如歌手，歌名形成列表
3、將列表作為該客戶端可以共享給別人的音樂列表
4、當一個客戶端發送搜索請求的時候，服務器可能進行幾種處理：

• 第一種，服務器將搜索請求發送給所有當前跟服務器有聯系的客戶端，每個客戶端搜索自己的共享音樂列表，然后將結果直接發送給發出搜索請求的客戶端（或者通過服務器轉發給那個客戶端。這種方式不可取，服務器負載太高，一個是要求有所有客戶端時刻跟服務器連接，在一個搜索結果可能把那個客戶端給淹死
• 第二種，客戶端將搜索請求直接發送給服務器，服務器將該請求發送給當前跟服務器有通信的客戶端，收到搜索任務的客戶端搜索本地的音樂列表，如果搜索到了就將相關的信息發送給服務器，或者直接發送給那個搜索的客戶端，收到搜索任務的客戶端會判斷一下，比如搜索任務超時之類的或者跟目標客戶端通信的速度太低，或者不可連接什么的，這種方式也不太可行，服務器的負載還是太高，而且貌似客戶端的負載也太高
• 第三種，客戶端有一個最近聯系的其他客戶端連接信息列表，跟其他客戶端的任何通信都會更新這個列表，當客戶端有搜索請求的時候會同時發送給服務器和列表中的所有客戶端，服務器會根據發出請求客戶端的特點（網通還是電信、IP地址段等等）將該請求發送給相關的客戶端（可能在所有符合條件的客戶端中挑幾個），收到請求的客戶端搜索本地的音樂列表，如果有結果就將結果發送給最初發送查詢請求的那個客戶端，這些客戶端還可能將搜索請求發送給自己的最近聯系客戶端列表中的客戶端，并通過在查詢請求上增加一個轉發次數計數，如果這個計數大于多少就不再轉發，受到搜索請求的客戶端同樣處理。在傳播的過程中有可能因為搜索轉發次數太多而終止傳播，也可能根據請求發送的時間來決定是否繼續轉發，或者是否處理，這種可能性很大哦，hoho，反正如果我設計這種方案最終肯定會被采用，因為服務器的負載最小

音樂下載部分：
1、音樂下載部分沒什么好說的，一般的P2P下載處理，服務器或者客戶端發送給該客戶端搜索結果的時候就說明可以從哪里下載，直接連接過去就可以了，這部分沒什么懸念

總之來說，目前這種P2P的思想真的很強大，這一切都開始于BT，至少我知道的是這樣啊，說錯了你就趕快告訴我，呵呵，開始的BT只是用來下載，可是現在可以用來聽音樂和看視頻，似乎無所不在，P2P的好處就是，不需要有一個很強大的服務器，每個人在獲取的同時也在貢獻，嗯，很有前途，也許目前的云彩也是基于這個原理，或者云彩可以向P2P多靠近一些哦，hoho
上面的分析純屬一些愚見，偶爾想到的，也許大家早就明白了，算是與君共勉吧，已經明白的多多指教，還沒明白的，咱們一起探討