以下內容摘自《ActionScript大型網頁游戲開發》
—————————————————————————————————————————————————————————
P2P架構
P2P架構是兩個或多個客戶端不經過服務器而直接通信的架構。可能首先會使用服務器以讓客戶端間能查找到對方，但在此之后就不再需要服務器了。具體也分兩種不同的形式：一種是完整連接拓撲架構，指的是每個客戶端與其他客戶端之間都必須有連接，信息可以直接在用戶間交換；另一種是環狀拓撲架構，指的是信息只有流經一個或多個客戶端后才能傳遞過來的架構。本文當談到P2P架構時，指的是完整連接拓撲架構。
一般來說，P2P架構在游戲方面用的不多。很多情況下游戲似乎是在使用P2P架構，但實際上其中的一個玩家已被設定為主機來充當服務器的角色。然而，P2P架構非常適用於搭建文件共享網絡。通過它，網絡游戲經常能夠高效地為玩家們發放游戲補丁（比如《魔獸世界》），這不僅減輕了Web服務器的負擔，而且也加速了玩家下載補丁的速度。
與C/S架構相比，P2P架構技術有幾個明顯的優勢，當然也存在幾個缺點。先講講它的優點。
P2P架構的優點
延時較小。延時就是指信息在從發出到接收這個過程中所用的傳輸時間。在C/S模式中，信息是先從一個客戶端傳到服務器端，而后再從服務器端傳到另一個客戶端。但P2P架構則是讓信息直接在兩個客戶端間傳遞，這樣就比C/S模式減少了一半的傳遞時間。
不需要服務器端。既然P2P架構全是由客戶端建成的，因此也就沒必要使用服務器端。這對於無論是游戲開發者還是發布者來說都是一件好事，因為他們不用再為維持運行游戲中央服務器而支付主機托管和管理費了。
P2P架構的缺點
游戲的可擴展性差。當游戲的客戶端相當少的時候，那就用P2P吧，因為它產生的延時很小且不需要使用服務器端。但是當游戲有很多客戶端時，比如說成百或上千個客戶端，那么P2P架構就不適用了。因為它需要每個客戶端都和其他客戶端保持一個獨立的連接。那么如果有1000個客戶端的話，完整拓撲架構就要求每一個客戶端都要建立並維持1000個開放的連接，其中每一個客戶端都要接受來自其他客戶端發出的所有信息。而在C/S架構中，一個客戶端只從服務器端接受經其職能篩選和歸集后的信息。
另外，還要考慮一下此種網絡的應用環境。假設你有1000個客戶端，但是它們全都在學校的子網絡中，1000個用戶彼此相連導致產生了1000000個連接，這將會使網絡因不堪重負而癱瘓。但是如果同樣數目的連接放到全球互聯網上，則根本不會出任何問題。
爭議解決機制不健全。加入有個雙人P2P游戲，每一方都能操縱鼠標去吃奶酪。玩家A接近第一塊奶酪，然后確定離它足夠近時就可以吃了它，於是玩家A因為吃了奶酪而獲得了一定的積分，然后他傳遞信息給玩家B，告訴B：這塊奶酪已經被我吃了。玩家B接收並處理了這條信息后從自己的屏幕上刪除了那塊奶酪，並且更新了玩家A的得分。誰都沒有異議，兩個客戶端對當前游戲的狀態達成了一致。
但比如說現在玩家A和玩家B都在對下一塊奶酪躍躍欲試。不巧的是這一次他們相互之間邏輯決策的時間就差了幾毫秒，雙方都各自認定是自己吃了這塊奶酪，然后都給自己加上了分，然后互發信息給對方證明是自己把奶酪吃了。結果兩個玩家就會互不相讓。
所以，P2P架構的一個缺點就是：沒有中心邏輯決策者。還有一些范例更能說明問題。
ü 兩個戰斗到最后的玩家間互發了一個必殺技，誰先倒下？
ü 在賽車游戲中，誰第一個沖過終點？
ü 玩家爭着搶地上的鑰匙，哪一位先搶到呢？
處理此類問題最好的方法就是采用C/S架構，讓服務器來維護游戲運行中的狀態，充當邏輯決策爭議的邏輯決策者。
P2P架構可通過選派一個客戶端充當主機（但其本身還是P2P架構中的一個客戶端）來解決邏輯爭端，而這樣做會帶來下面兩個新麻煩。
（1）如果所有重要的邏輯沖突都要通過充當主機的客戶端來解決的話，那就喪失了對等網絡架構的延時較低這個優點，因為信息要從客戶端傳到主機由其處理完后再傳回客戶端。
（2）P2P架構游戲本身存在安全隱患，因為所有的重要邏輯行為都運行在客戶端而沒有在一個中央結點得到驗證。那么如果你把所有重要的邏輯決策權都交給主機的話，無疑會使這個特殊的客戶端在理論上具有了某種控制能力上的優勢（作弊的機會大大增加）。