2009-09-14 44 views
2

我在運行同步顯示例程的局域網上有一系列系統。例如,想一下合唱線。他們運行的程序是固定的。我有每個「客戶端」下載整個例程,然後在例程中的固定點聯繫中央「服務器」進行同步。例程本身可能有20個可能的指令。在多個系統上運行圖形顯示,保持同步

每個客戶端運行相同的例程,但他們可以在任何時候完全不同的事情。合唱隊的一部分可以踢左,另一部分踢得恰到好處,但時間緊迫。客戶可以隨時加入和退出,但他們都被分配了一部分。如果沒有人來運行該部件,它就不會運行。

這全部用C#.Net編碼。

客戶端顯示器是Windows窗體應用程序。服務器接受TCP連接,然後以循環方式爲它們提供服務,從而保持正在進行的主時鐘。客戶端發送一個信號,說明「我已經達到同步點32」(或19或5,或其他),並等待服務器確認,然後繼續前進。或者服務器可以說「不,你需要從同步點15開始」。

這一切都很好。在第一個客戶端和最後一個客戶端之間有一個小的點延遲點擊一個同步點,但它幾乎不明顯。跑了幾個月。

然後規範改變了。

現在客戶需要響應來自服務器的近實時指令 - 它不再是預先設定的舞蹈程序。服務器將發送指令,舞蹈程序即時編寫。我很樂意重新設計協議,服務循環和編程指令。

我的工具包包含標準.Net 3.5工具箱中的任何東西。安裝新軟件是一件痛苦的事情,因爲可能涉及很多系統(客戶端)。

我正在尋找有關保持客戶端同步的建議(某種鎖存系統?UDP?廣播?),「舞蹈程序」的分發,任何可能比傳統的客戶端/服務器TCP協議。

請記住,還存在時間/速度限制。我可以將舞蹈程序放入網絡數據庫中,但我不得不相當迅速地提出指示,並且會有很多讀者使用較厚的協議(DBI,SqlClient等)來獲取一點點的文字。這似乎過於複雜。而我仍然需要的東西,讓他們都顯示在同步。

對此提出建議?意見?野驢投機?代碼示例?

PS:答案可能不會被標記爲「正確」(因爲這不是一個「正確的」答案),但肯定會得到+1票。

回答

1

我做了類似的事情(一段時間後),同步一組4臺顯示器,每臺顯示器由一個系統運行,接收來自中央服務器的消息。

經過相當數量的測試後,我們終於確定了架構,其中包含一臺「主」機器。在你的情況下,這將會讓你的20個客戶端中的一個充當主服務器,並通過TCP連接到服務器。

然後,服務器將把系列的整個系列命令發送到那臺機器。

然後,該機器使用UDP向其他機器(LAN上的19個其他機器)廣播實時指令,以保持顯示器的最新狀態。我們在這裏使用UDP有幾個原因 - 涉及的開銷較低,這有助於保持資源使用總量下降。此外,由於您正在實時更新,如果一個或兩個「幀」不同步,它永遠不會顯示出來,至少對於我們的目的而言不夠明顯(有人坐着和與系統交互)。

然而,這種工作的關鍵點是在主服務器和「主」機器之間有一個智能的通信手段 - 您希望保持儘可能低的帶寬。在像你這樣的情況下,我可能會想出一個單一的二進制blob,其最小的形式具有20臺機器的當前指令集。 (也許像20字節,或者如果你需要40字節等等)。 「主」機器然後會擔心將其轉換到其他19臺機器和它自己。

有一些很好的事情 - 服務器有更容易的時間傳輸到集羣中的一臺機器,而不是集羣中的每臺機器。例如,這讓我們有一個單一的集中式服務器可以有效地「驅動」多個集羣,而不會在任何地方出現荒謬的硬件要求。它也使客戶端代碼非常簡單。它只需要監聽一個UDP數據報並執行它所說的任何事情 - 在你的情況下,它聽起來像有20個命令之一,所以客戶端變得非常非常簡單。

「主」服務器是最棘手的。在我們的實現中,我們實際上與其他19個客戶端代碼(作爲單獨的進程)以及一個採用blob的「翻譯」進程相同,將其分解爲20個塊並傳輸它們。寫起來相當簡單,而且工作得很好。

相關問題