p2p的概念大家都不陌生，也就是所謂的「點對點傳輸」，即不直接通過伺服器，在兩台或多台客戶端之間傳輸資料，實現資訊交流和資源共享。p2p技術已經發展了很多年了，雖然理論上已經發展了很多的模型，但在實際的網路環境中（尤其是鎮里這種環境），究竟怎樣的網路結構才具有較好的穩定性和較高的傳輸效能，還是有很大的爭議，每家做p2p的網路公司都會有不同的見解。當前，p2p技術應用的主要目的還是減輕伺服器工作壓力，本人不才，之前曾在國內某網路軟體公司裡擔任p2p相關的流**專案開發，對於p2p技術所創造的能力和帶來的價值深有體會，也曾被它的複雜性所折磨的痛苦不已，不過，這也是我所珍惜的一筆寶貴的知識財富。
似乎扯遠了。。。趕緊回來，前段時間做了乙個c#實現p2p檔案傳輸系統的專案。以前都是用c/c++，這還是第一次用c#來做這種專案，由於用c++比用c#要早的多，所以寫c#程式不免會帶些c++的習慣，不過不影響程式整體。第一步：設計。對於「檔案分享和傳輸」這種典型的p2p應用，可以使用成熟的模型和框架：
這個模型基本涵蓋了p2p網路架構的主要幾個部分，在具體實施的時候會根據不同的資源型別有不同的變化，通常會更加的複雜，當然，也有可能更簡單。比如，dht(distributed hash table) 網路，這種網路，以不需要伺服器的參與來完成p2p的查詢與傳輸為主要特點，例如大家常用的emule中的kad網路，就是一種dht網路。但其實，dht中，是peer節點，負責了tracker server和source server的工作。也就是peer變得比較複雜，如果把它拆開來看，也基本就是這個模型。peer的複雜化，可以降低伺服器執行壓力，但就犧牲了實時性，對於實時性和準確性要求高的應用，例如流**，不太適合dht，當然，這並不妨礙dht作為輔助手段來探知更多的資源節點。
我要做的這個「easyp2p」檔案分享與傳輸系統，目前暫時不需要source server，由peer負責source server的功能，也就是資源的發布；tracker server負責節點和資源的查詢；nat server依然負責打洞。於是，變化成如下結構：
這就是easyp2p系統的模型，接下來，將根據這個模型，來具體設計整個網路的架構和執行流程。
libjingle 部分 P2P傳輸
1，libjing 基本結構。mediachannel 相關功能的抽象，接收capture network的資料，處理後傳送給其他模組。實際的處理工作需要有繼承類呼叫其他模組實現。transprotchannel 提供抽象的p2p傳輸功能。實現ice協議，ice協商後，會選擇最好的方法傳送。對外只暴...
P2P原理的解釋與實現
關於採用udp協議進行打洞以進行p2p會話的原理,我本來想寫一篇文章作說明,但是現在已經有一篇文章把原理性的東西解釋清楚了,我在這裡不再作這部分的重複,可以參見這裡 p2p 之 udp穿透nat的原理與實現 附源 下面解釋一下上面的文章中沒有提及或者說我覺得比較欠缺的地方.如果明白了上面的東西,下面...
P2P共享協議最少傳輸次數
from 現有一完全的 p2p共享協議，每次兩個節點通訊後都能獲取對方已經獲取的全部資訊，現在使得系統中每個節點都知道所有節點的檔案資訊，共 17個節點，假設只能通過多次兩個對等節點之間通訊的方式，則最少需要 c 次通訊 a 32 b 31 c 30 d 29 解法由 龍人920提供 分析 如上圖 ...