WCF雙工客戶端的最佳做法

Question

我不能否認雙工異步調用的性能優勢，但有些事情讓我感到很謹慎。

我擔心的是，給定一個客戶端對象實例化後，WCF能夠告訴哪個特定的客戶端服務實例將接收回調參數？

誰能告訴我，這是個好主意嗎？如果不是爲什麼不呢？

new DuplexChannelFactory<IServerWithCallback>(
    new ClientService(), 
    new NetTcpBinding(), 
    new EndpointAddress("net.tcp://localhost:1234/"+Guid.NewGuid())) 

1. 如果上述虛擬路徑被保留它是如何可以被丟棄。我希望客戶服務的生命週期相當短。 IE發出請求並收到響應，完成接收後，將其殺死。在縮短客戶服務使用壽命的過程中，性能會受到多大的影響，而不是將其彙集並保持更長的運行時間。

   這個想法是爲了避免超時問題。完成接收，發送，處置儘快。按照慣例 - 不能通過客戶端服務。如果你需要的信息，創建一個新的，簡單 - 就像EF/L2S等

2. 從WCF服務本身，如何殺死與客戶端的會話。即。我不希望客戶端會話結束 - 我知道我可以相應地修飾我的操作，但我希望服務在滿足特定條件時以程序化方式自行終止。

3. 我可以固定端口並據此轉發以解決任何防火牆問題，但我擔心的是客戶端是否坐在負載均衡器後面。服務如何知道要調用哪個特定的服務器？

Answer 1

我認爲最終雙面打印服務只是另一個來自Microsoft的失敗體系結構。這是紙上看起來非常不錯的東西之一，但經過仔細檢查後纔會分崩離析。

有太多的弱點：

1）會議依賴服務器建立客戶端偵聽器。這是會話信息存儲在內存中。因此服務器本身不能進行負載平衡。或者如果負載均衡，則需要關閉ip affinity，但現在如果其中一臺服務器遭到轟炸，則不能簡單地添加另一臺服務器，並希望所有這些會話都自動遷移到新服務器。

2）對於每個坐在路由器/防火牆/負載均衡器後面的客戶端，都需要創建一個具有特定端口的新端點。否則，路由器將無法將回調消息正確路由到適當的客戶端。另一種方法是使用允許自定義編程將特定路徑重定向到特定服務器的路由器。再次是一個高的命令。或者另一種方式是客戶端通過回調託管自己的數據庫並通過數據庫共享數據。< - 在許可費用不成問題的情況下可能會工作......但它引入了很多複雜性和繁瑣客戶端加上它將應用程序和服務層混合在一起（這在某些特殊情況下可能是可以接受的，但不是在巨大的安裝成本之上）

3）所有這些基本上都說雙工幾乎沒用。如果你需要回撥，那麼你將在客戶端建立一個wcf主機。它會更簡單，更具可擴展性。另外，客戶端和服務器之間的耦合度更低。

可伸縮體系結構的最佳雙工解決方案最終不會使用它。

Answer 2

1. 這將取決於你需要多短的客戶new'd起來，他們將持續多長時間。如果您每次都特別需要一個新客戶端，那麼並不是一個選項，但是如果客戶端繼續做同樣的事情，爲什麼沒有一個等待使用它們的池，如果他們錯誤地再次重新創建同一個客戶端。

2. 實際上，在回調場景中，如果服務正在回調給客戶端（真正調用客戶端的功能）來傳遞信息，則服務現在是客戶端，反之亦然。您可以讓服務進行回調.Close（）連接，但它會一直開放，直到GC可以處理它爲止，這從我的經驗來看可能需要比預期更長的時間。因此，簡而言之，客戶端應該負責（客戶端是調用某個東西的客戶端）來關閉自己或斷開連接，服務應該只回答客戶端的答案或從客戶端獲取數據。

3. 在雙工回調中，現在回撥給客戶端的服務將獲得在duplexchannelfactory後面抽象的客戶端地址。如果服務不能回撥給客戶端，我認爲沒有太多可以完成的工作，您必須確保您的客戶端調用服務的端口可以接收回撥，我猜測。