有一個c＃項目，它承載了幾個wcf服務，包括basichttpbinding和nettcpbinding。 和一個silverlight項目，消耗服務。對於nettcpbinding部分，它建立與服務器的連接。當服務器在別處獲取新數據時，它會通過回調通道將數據發送到連接的客戶端。將Silverlight項目重寫爲javascript，涉及wcf
關於silverlight，我什麼都不知道，但它運行在客戶端。我認爲這是很重要的事情：因爲sliverlight運行在客戶端並且用c＃編寫，所以很容易使用wcf服務，包括雙工服務。
我的任務是重寫silverlight項目，主要是使用javascript。 對於非雙工部分，我寫了幾個ashx處理程序，並用ajax調用它。 （是嗎？）
但對於雙面打印部分，閱讀了一些帖子後，我發現投票似乎是唯一的方法。當服務器接收到新數據時，它將其存儲在某處，並且客戶端每隔幾秒鐘調用一次處理程序，然後處理程序返回新數據。所以服務器不能主動發送數據給客戶端。 我是否正確地做，或者其他方式？
Web sockets是支持從服務器推送到客戶端的新的HTML5標準。 （實際上，網絡套接字可能優於Silverlight雙工類，它們並不使用真正的推送，而是使用來自客戶端的定期「保持活躍」信號的老式長輪詢。）
我會建議看看SignalR，它是一個包裝了網絡套接字功能的ASP.Net組件，並且「可以回退到其他兼容舊版瀏覽器的技術」。
幾年前，我曾處於類似的位置：我有一個Silverlight客戶端與我需要移植到JavaScript/HTML5的雙工WCF服務器通信。問題是，「我們對後端做了什麼？」我的解決方案與@McGarnagle描述的完全相同，即在後端切換到SignalR，並使用SignalR JavaScript客戶端與後端進行通信。我本來可以花大量時間重新構建WCF後端與SignalR共享邏輯，但由於我們實際上放棄了我們的Silverlight客戶端，因此只需將支持WCF服務的代碼剪切並粘貼到新的SignalR中心。
關於我不喜歡SignalR（當時）的唯一的事情是它只使用動態對象與客戶端進行通信。我更喜歡（並且繼續喜歡）靜態編譯時檢查。我認爲現在有辦法用SignalR和TypeScript來做到這一點，但最近我還沒有對它們進行調查。
順便說一下，我調查的主要選擇是使用JavaScript與相同的WCF服務進行通信。雖然有人認爲有一些方法可以使其發揮作用，但似乎並不像他們非常成熟，並且不可能在未來得到很好的支持。如果您嘗試在後端使用C＃和客戶端上的JavaScript並需要雙向通信，則SignalR絕對是您想要使用的方法：在該場景中避開WCF。