服務器和客戶端的WinForms

Question

之間的通信我有我希望能夠得到一個狀態更新，從一臺計算機，按需而不是一個區間50+亭風格的電腦。這些計算機在請求狀態的計算機上位於LAN上。

我研究過WCF，但它看起來像我需要IIS安裝，我寧願不在50 + Windows XP盒子上安裝IIS - 所以我認爲這消除了使用Web服務，除非它可能有一個WinForm主機Web服務？

我使用的System.Net.Sockets還研究了，甚至得到了一個勉強功能樣機去，但是我覺得我沒有足夠的技術，使其成爲堅實可靠的系統。鑑於這個道路，我需要更多地瞭解套接字編程和線程。

這些框運行.NET 3.5 SP1，所以我在.NET版本的靈活性但是我想堅持到C＃。

實現此目的的最佳方法是什麼？我應該只是咬緊牙關，多學習套接字，還是.NET有更好的方式來處理這個問題？

編輯： 我是去了雙向通信，直到我意識到我需要的是一個雙向溝通。

編輯2： 我避開了傳統的服務器/客戶端，因爲我想避免消耗太多帶寬，並且不確定我在討論什麼樣的開銷。我也希望能夠更好地控制個人信息亭。看了它之後，我想我仍然可以通過WCF和IP連接（我不知道我可以通過IP連接，我想我將不得不添加50個Web服務或其他東西）。

Answer 1

除非您有計劃將此擴展到數千個客戶端，否則我認爲WCF性能甚至不會是一個附帶問題。您可以輕鬆地從Windows服務或Winforms應用程序託管WCF服務，並且一旦獲得關鍵概念，您就會發現讓WCF與WCF一起工作將會非常簡單。

我已經部署了一些與100-150個客戶類似的東西，取得了巨大的成功。

有豐富的資源了在網絡上，讓你開始 - 這裏是一個讓你去到：

http://msdn.microsoft.com/en-us/library/aa480190.aspx

Answer 2

WCF不都必須在IIS託管，它可以在你的WinForm的內舉辦，作爲控制檯應用程序或Windows服務。 您可以讓每臺計算機在winform中託管它的服務，並在自己的計算機上編寫程序調用每臺計算機的服務以獲取狀態信息。

這樣做的另一種方法是在您自己的計算機中託管一項服務，並使50+臺計算機在狀態更新後調用服務，您可以使用數據庫服務來保存每個服務的狀態數據網絡內的節點。此選項更易於維護和擴展。

P.S. WCF旨在取代.net遠程處理，替代方案可以是net.tcp綁定或net.pipe

Answer 3

我建議使用.NET Remoting。這很容易實現，不需要其他任何東西。

Answer 4

對我來說，它是更好地學習網絡..或套接字通信的手工方式.. Web服務是糊狀慢，因爲它包含元數據..

您的客戶端和服務器可以轉化爲多線程應用程序。只是模仿請求和響應架構。這是很容易實現這樣的..

Answer 5

網絡應用程序。如果你只需要一個狀態更新，你可以使用更簡單的解決方案，如簡單的TCP服務器/客戶端郵件或類似orrsella說，遠程處理。 WCF在這裏有點矯枉過正。

但有一點需要注意的是，如果所有50+的自助服務終端都通過互聯網連接，那麼您可能需要使用VPN或每個自助服務終端都有開放端口（這是一種安全風險），以便您的服務器可以從每個亭。

我們有一個類似的情況，但狀態定期發送到我們的服務器，所以我們只有1個端口來保護/安全。更新的頻率可以配置爲容納較慢的客戶端。

Answer 6

無論您是使用中央服務器上的Web服務或WCF中，你只需要在服務器上安裝和配置IIS（而不是在50多個客戶端上）。

你想要做的是對問題有點不清楚，但是如果客戶端需要調用服務器（例如獲取服務器狀態），那麼他們只需調用Web服務上運行的方法服務器。

如果您需要讓服務器隨時調用客戶端，則每次客戶端啓動時都需要讓每個客戶端在服務器webservice上調用登錄方法。登錄方法將採用客戶端的委託方法作爲參數。服務器會在需要來自客戶端的信息時調用該委託。

使用自己的Web服務設置每個客戶端將代表傳統（一個服務器，多個客戶端）客戶端/服務器架構的反轉，並且您已經注意到這是不切實際的。

Answer 7

請勿使用遠程處理。

如果你想要健壯性和可擴展性，你最終會排除一切，但實質上是無狀態的遠程過程調用。由於這正是Web服務的功能，並且Web服務更簡單且更容易構建，因此遠程處理本質上是毫無意義的技術。

與遠程代表的回調是關於性能/可靠性禁止列表的，所以如果您想爲遠程代理使用遠程處理，請再考慮一下。

使用Web服務。

我知道你不想投票，但我不認爲你需要。既然你說你所有的單位都在一個網段上，那麼我建議UDP用於廣播改變通知，本質上是設置一個髒標誌，並允許應用程序按需重新獲取。它仍然不可靠，但它很容易，速度很快，因爲它是廣播。

正如其他人所說，你不需要IIS，你可以自我託管。有關如何執行此操作的詳細信息，請參閱ServiceHost class。

Answer 8

正如有人誰實現這樣的事情有超過500多個客戶和成長：

消息Queing是要走的路。

我們已經從一個內部開發的TCP服務器和客戶端轉向WCF輪詢，並以消息隊列結束。這是通過互聯網從客戶端和服務器獲取數據的唯一保證方式。作爲獎勵，許多這些解決方案都有一個廣泛的框架，使得實現發佈 - 訂閱，發送 - 單向，點對點發送，請求 - 回覆變得微不足道。其中一些可能與WCF一起使用，但它會涉及到哭泣，吶喊，嗚咽和漫長的夜晚，更不用說加侖的咖啡。

一對夫婦的重要講話：

讓一個過程調查的客戶，而不是周圍的其他方法=壞主意。它是不可擴展的一切，你很快就會在出事時正在運行的進程需要太長的時間才能完成......更不用說必須處理所有的IP地址了（你是否可以訪問所需端口上的所有客戶端？當IP變化時會發生什麼等等。）

我們做了什麼：客戶端會定期向中央消息隊列發送狀態更新（您可以輕鬆地在UI中實現實時更新），它還會在自己的隊列上偵聽GetStatusRequest消息。如果它收到了，它會回答（有一個超時）。這樣，我們可以隨時查看所有客戶端的總體狀態，並在需要時獲得特定客戶端的特定狀態。

關於帶寬：kiosk通常顯示圖像/視頻等。1Kb或更少的狀態消息不會是大的開銷。

我不能強調你目前的設計會有一個非常密集的開發週期，並且不會擴展或延伸（相信我，我們已經學到了這一課）。除此之外，爲這種類型的東西建立一個良好的客戶端/服務器協議是一項艱鉅的工作，如果發生設計錯誤（遷移協議並不容易），這將是完全沒有用的。

我們已經在top ActiveMQ（使用NMS庫C＃），目前正在爲我們的內部工作擴展簡單服務總線。

我們只使用WCF我們的WinForms應用程序和集中服務（S）