前段時間和朋友一起做了乙個類似於電驢、迅雷 + msn工具的毛坯模型，基本上所有功能都是從socket通訊級別向上實現。
整體架構為c/s架構，使用mfc實現。技術上都是很老的東西，此文主要介紹類似於 電驢 的這樣乙個軟體的設計思路和部分**框架。
我們實現的**不是很優化，僅為設計思路的佐證。
我最初做這個小軟體的想法是，方便乙個小型網路中大家的資源共享和交流。
每個人都能共享出自己的一部分檔案，當然這個可以通過windows的共享資料夾或者linux的samba實現，不過假如在我並不知道共享源的情況下，就很難獲得資源了。有人說，直接在windows的網路上的芳鄰裡可以看到區域網上大家共享的資源，但是我發現可能由於各種網路設定的關係，在網路上的芳鄰裡我經常看不到其他人共享的資源。
於是當時我用windows的幾個api，（忘了具體是什麼了，可以探測和遍歷他人共享目錄），寫出來效果也很不好，第一很慢，第二還是收不全，第三不可控，其封裝度太高，隱藏n多技術細節。
於是後來我想，還是基於socket，從底層做起。
在不知道源的情況下，我們如何探測、收集到各個源的共享資源呢？—— 答案很快浮出水面，弄一台伺服器，大家都連線伺服器，告訴它自己這兒的資源情況，然後大家統一從伺服器查詢網路上的共享資源，然後建立客戶端的點對點連線傳輸檔案。
1. 內部協議
我們的客戶端需要與伺服器端「交流」，就得有一套系統內部能被互相識別的語言，這樣一套協議完全可以咱們自己設計。
我在實現中採用的udp通訊，每個udp包 頭乙個位元組為 指令位元組，其後按照每個指令的格式跟接引數。例如我的「內部協議」部分**：
如果直接在網路上傳送明文，則很容易被別人使用抓包工具抓取，稍加分析則可理解其中的內容，然後別人可以模擬寫客戶端或者程式來非法訪問、攻擊你的伺服器端和別的客戶端。所以這裡應該要使用加密演算法，在網路上傳輸加密資料。在我的「毛坯」程式中沒有實現這一點，不過，這在網際網路上發布的任何一款商用通訊程式都是必須的。
2. tcp檔案傳輸及傳輸群管理。
那麼我們總結核心思想就是，不管客戶端還是伺服器端，都應該有乙個tcp listener，不斷的監聽網路上到來的tcp請求，每當過來乙個請求時，與其建立連線，並且單獨增開乙個執行緒與其通訊進行檔案傳輸——我把這個機制叫做tcp檔案傳輸群管理。
傳輸群管理應該包括以下幾點
1. 偵聽請求，建立連線；
2. 為連線增開執行緒；
3. 控制傳輸服務；
4. 結束傳輸，關閉執行緒。
下面給出我們傳輸群管理的核心部分**：
大致說明一下，tcpservermanager為傳輸群管理，每次有連線單獨啟動乙個tcptaskmanager作為tcp傳輸的容器類，負責管理乙個tcp傳輸任務。
未完待續。。。。
乙個基於socket的資源共享平台的實現（三）
需要共享資源，則需要探測本地資源分布情況。此處我們用的演算法比較2 不過還是說說吧。下面使用mfc的cfilefind實現乙個本地檔案遞迴收集器，以jason格式儲存檔案路徑和檔案大小 然後定期收集，對收集結果md5，若發生變化，則上傳伺服器。伺服器端使用乙個資料結構維護所有資源站資源，對於使用者的...
乙個基於socket的資源共享平台的實現（二）
我們用乙個ns download pool類來封裝對其的管理。接下來我們針對資源傳送過程中限速進行分析和實現。如果需要將傳送速度限制在乙個值，我們可以這麼理解，單位時間內最多允許傳送資料為n，若超過之，就需要降低速度，若不足，則需要提高速度。如何控制速度？這裡我們採用最樸素的方法，sleep，只要將...
乙個基於socket的資源共享平台的實現（四）
現在我們的整個系統基本可用了，還缺少什麼？客戶端自動公升級。所以我們應該要開發乙個loader，客戶端能夠自動檢測更新 公升級，並可以在伺服器端打包公升級流及公升級流資訊下發。在此系統中，我直接是伺服器下發一條公升級資訊 帶版本號 然後與客戶端當前版本號進行配對，若高於客戶端，則開始客戶端更新公升級...