| 模式 | 架構 | 優點 | 缺點 |
|---|---|---|---|
| 固定狀態服務器 | 混合 P2P:廣播走 Mesh,狀態集中於已知 Web/WCF 服務 | 實作簡單、狀態單一權威 | 需部署/維護中心伺服器、單點故障 |
| 動態選舉服務器 | Mesh 節點演算法選出一節點為狀態服務器 (如最舊/最新節點) | 無固定基建 | 選舉演算法複雜、服務器離線/黑洞需容錯、實作難度高 |
| 數據廣播 | 新節點加入或明確請求時,全節點廣播完整狀態副本 | 無中心、無選舉邏輯 | 頻寬浪費隨節點數指數增長、同步瓶頸、需去重機制 |
| 鄰居同步 | 新節點單跳請求鄰居 ID 清單 → 比對 → 單跳請求缺失明細 → 自動傳播 | 無中心、自動容錯 (WCF 路由自動繞過故障節點)、頻寬效率高 | 需處理重入與並發同步 |
NetPeerTcpBinding:P2P 通訊綁定。[PeerHopCount] 訊息屬性:限制訊息跳數 (TTL),實現單跳。[MessageContract]
public class TransactionIdRequest
{
[MessageBodyMember] public string Requester;
[PeerHopCount] public int Hops = 1; // 單跳
}
TransactionIdRequest (Hops=1) → 單跳範圍內節點收到。CallbackChannel.TransactionIdsReply(...) 回覆本地所有交易 ID 列表。RequestTransactionDetails(missingIds) (單跳)。TransactionDetailsAck(transactions) 回傳完整明細。

使用 Semaphore 確保同一時間僅一個同步操作執行,避免重入亂序。
WCF P2P 配合 PeerHopCount 與雙向回調,讓無中心、自動容錯、高效率的鄰居同步成為現實。WeSpend 原始碼可下載體驗:雙機修改 app.config 模擬不同用戶,觀察交易自動同步傳播。