WCF TCP雙工綁定配置的發布/訂閱模式

Question

將WCF TCP綁定用於雙工回調作為發布/訂閱設計模式的一部分時，我遇到WCF配置難題。

要求客戶端使用單向回調從服務器接收通知。 何時接收到通知尚不清楚，因此目的是無限期地保持連接打開。 如果客戶端或服務器接收到異常，則將啟動清理過程以正確關閉，中止和清理CommunicationObject，然后發出新連接以繼續接收通知。

我具有顯式訪問權限，可以同時配置客戶端和服務器WCF端點。 我的困境是我是否應該：

A.保持sendTimeout和receiveTimeout配置屬性設置為infinite以保持連接盡可能長的打開，同時仍處理異常以重新打開連接。

要么

B.保持sendTimeout和receiveTimeout較低的時間范圍，例如1小時。 超時將由客戶端或服務器接收，清理，然后建立新的連接。

使用WCF而不是使用WCF是否對我的問題而言不是可行的解決方案？

我的目標是保持最高的可用性。

編輯：

我擔心超時的原因是服務器意外關閉或超時連接，而客戶端沒有通過Faulted和Closing事件接收到任何有關此操作的通知，但是我可以確認客戶端和服務器都是為sendTimeout和receiveTimeout使用無限超時。 這通常在24小時內發生。

研究WCF雙工模型的MSDN文檔時，我讀了以下語句：

雙工模型不會自動檢測服務或客戶端何時關閉其通道。 因此，如果客戶端意外終止，則默認情況下不會通知服務，或者如果客戶端意外終止，則不會通知服務。 客戶端和服務可以選擇使用自己的協議來相互通知。

這就帶我問一個問題，是否有人可以實現自己的協議以保持會話存活，因為這是我的問題？

我是否只需要有一個客戶端線程，該線程會在固定的時間間隔內將“心跳”發送到服務器？ 顯然，我不想通過心跳向網絡發送垃圾郵件，但同時盡可能使會話保持活動狀態。

我相信ReliableSession不會為這個問題帶來任何實際好處。

Answer 1

我認為您應該僅將receiveTimeout保持為infinite ，就是這樣。 每小時重新創建一個頻道沒有任何好處。

您不需要將sendTimeout設置為infinite因為這是一個超時，它定義了WCF基礎結構在無法發送消息的聲明之前要等待的時間。

PS在我們的應用程序中，我們使用類似的技術，並且通道保持打開狀態數周沒有任何問題。