2012-02-29 50 views
3

我一直在研究是否使用WCF來處理我們將要開發的新項目。傳統的TCP IP服務器和WCF應用程序之間的通信

基本上,阻止我們使用它的唯一原因是新項目必須能夠與通過.Net的TcpClient類與二進制消息進行對話的傳統服務器進行通信。

我想知道如果我可以寫一個自定義綁定也許發送和接收來自服務器的消息。我設法發現我可以編寫自定義綁定和編碼。但我不確定是否可以將消息讀取爲字節而不是肥皂消息。

我想到的一種可能的解決方案是編寫一個自定義編碼,將字節轉換爲肥皂消息,反之亦然。但我沒有檢查過,也沒有多想。

+0

是您的客戶端已經寫好,你需要某種兼容的服務器或約束僅僅是客戶端被限制的TcpClient類(順便說一句,WCF不限制於SOAP)? – 2012-03-05 13:33:41

+0

@SimonMourier客戶端僅限於TcpClient類,服務器僅限於WCF – Jason 2012-03-06 23:10:01

+0

,但客戶端和服務器之間的協議/接口已存在,或者您正在創建它? – 2012-03-07 10:17:35

回答

2

傑森,
我建議(不知道這是否是一個答案,但我不能發表評論,對不起),
你願意與任何一個完整的插座或一個完整的解決方案WCF走(意思是兩個客戶端和服務器)。
鑑於你有一個傳統的服務器與通過套接字 - 這是更容易做一個套接字客戶端與你有一些自定義協議,解析,基本的錯誤處理等
......你會讓它更快(不知道應用的目的,應用的性質以及與服務器之間的通信是什麼,還是您需要其他WCF功能等)。 看到這個線程這或多或少是你的情況...
WCF TCP client with Java Socket server on custom XML messages

...基本上,你需要寫一個傳輸通道 - 這將再次幾乎要支持你所需要的一切它可以用於'套接字'客戶端+額外的工作和圖層。
通常情況下,只有當你想要
時纔有意義a)重複使用它以便以後進行開發,例如,您可以將該解決方案插入不同的服務器,或者如果您有許多開發人員和大型代碼庫等(如果您不這樣做,則使套接字解決方案成爲單獨的庫並重新使用仍然更容易)或者b)或者您需要一些不容易重現的特定功能,「手工和套接字」 - 仍然支持任何你必須包裝它非常徹底,或...
c)一些第三方庫 - - 我「M不知道對於這樣的情況(通常這屬於一個「過自定義的工作),
希望這有助於一些

+0

這是必須的,我不能使用原始套接字,是的,它將被用作插件(更多的框架)在其他服務器中。所以看來我需要編寫一個自定義傳輸。感謝您更多關注 – Jason 2012-03-03 19:30:05

+0

並非每個套接字通信都可以(很容易)進行WCF編輯,這取決於服務器協議模型。 你也可以考慮寫一個'代理'(即代理對話服務器,將WCF暴露給其他人) - 即使它聽起來像'更多'(可能會),它可能會變成更乾淨的解決方案。 – NSGaga 2012-03-05 16:32:11

0

不知道如果你看過卡洛斯·費圭的系列文章對WCF可擴展性,但他們如果你想了解什麼是可能的以及如何去做,那麼值得一讀。

http://blogs.msdn.com/b/carlosfigueira/archive/2011/03/14/wcf-extensibility.aspx

沒有爲JSON-RPC,你可能能夠使用一個基礎,一個新的傳輸你的情況有約束力基於自定義TCP的例子。

http://blogs.msdn.com/b/carlosfigueira/archive/2011/12/08/wcf-extensibility-transport-channels-request-channels-part-1.aspx

+0

謝謝,好的文章 – Jason 2012-03-06 17:16:47

相關問題