2009-07-30 51 views
8

我有客戶需要全部連接到單個服務器進程。我正在使用UDP發現爲客戶端查找服務器。我有客戶端和服務器交換IP地址和端口號,以便完成發現後可以建立TCP/IP連接。這樣數據包大小保持很小。我看,這可能在使用UDP兩種方式之一進行:UDP服務器發現 - 客戶端應該發送多播發現服務器還是應該服務器發送常規信標?

  1. 每個客戶端在搜索服務器,然後服務器響應的發出自己的多播消息。客戶端可以定期重複發送此多播消息(在服務器關閉的情況下),直到服務器響應。
  2. 服務器定期發送一個多播消息信標。客戶端訂閱多播組並以這種方式接收服務器的多播消息並完成發現。

1.如果有很多客戶端,那麼最初會有很多多播消息(每個客戶端發送一個)。只有服務器將訂閱並接收來自客戶端的多播消息。一旦服務器響應客戶端,客戶端就停止發送多播消息。一旦所有客戶端都完成對服務器的發現,則不會在網絡上傳輸其他多播消息。但是,如果服務器關閉,則每個客戶端會間隔發送多播消息信標,直到服務器備份並可以響應。

2.只有服務器定期提交多播消息信標。這條消息最終會被路由到所有訂閱了多播組的客戶端。一旦客戶端收到數據包,客戶端的UDP監聽套接字就會關閉,並且不再訂閱多播組。但是,服務器必須繼續發送多播信標,以便新客戶端可以發現它。無論客戶是否需要發現,它都會定期繼續發送信標。

所以,我看到優點和缺點。在我看來#1最初會導致更重的負載,但是這個負載最終減少到零。在#2服務器將繼續發送一個燈塔永遠。

UDP和多播對我來說是一個相當新的話題,所以我有興趣找出哪些是首選方法,哪些會導致較少的網絡負載。

+1

您是否明確決定不使用標準服務發現機制? – Duck 2009-07-30 05:05:43

+3

當你說標準的服務發現機制時,你能否澄清一下你認爲的是什麼。我正在「發現」我的選擇以及採取的最佳方法。 – Elan 2009-07-31 06:12:04

回答

2

我會推薦方法#2,因爲它很可能(取決於應用程序)您將擁有比您將服務器更多的客戶端。通過讓服務器發送信標,您每隔一段時間只發送一個數據包,而不是爲每個客戶端發送一個數據包。

此方法的另一個好處是,它使客戶端更容易確定新服務器何時變爲可用,或者當現有服務器離開網絡時,因爲它們不必與每個服務器保持連接服務器,或保持輪詢每個服務器,找出。

1

兩者都是同樣可行的方法。

方法#1的參數是在正常的原則下,客戶端發起請求,服務器監聽並響應它們。

方法#2的參數是多點傳送的意義在於,一個主機可以發送一個數據包,它可以被許多客戶端(一對多)接收,所以它的意思是#1。

好的,正如我想到的那樣,我實際上被抽象爲#2,服務器啓動的信標。 #1的問題是讓我們說客戶端廣播信標,並且他們與服務器連接,但是服務器要麼脫機,要麼改變它的IP地址。

當服務器備份併發送其第一個信標時,將同時通知所有客戶端重新連接,並且您的整個系統立即備份。通過#1,所有的客戶端將不得不單獨認識到服務器已經消失,並且他們都將同時開始組播,直到與服務器連接爲止。如果你有1000個客戶端和1個服務器,你的網絡負載就會比方法#2大1000倍。

我知道這些消息很可能很小,每次1000個數據包對於UDP網絡來說沒有任何意義,但從設計的角度來看,#2感覺更好。

編輯︰我覺得我在這裏發展分裂人格障礙,但只是想到了爲什麼#1會是一個優勢的強大點......如果你想實施某種自然負載平衡或使用多臺服務器進行擴展,設計#1適用於此。這樣,第一個「可用」服務器可以響應客戶端的信標並連接到它,而#2則是所有客戶端都跳轉到信標服務器的。

1

您的選項#2有一個很大的限制,因爲它假設服務器可以或多或少地直接與每個可能的客戶端進行通信。根據運營系統的確切網絡架構,情況可能並非如此。例如,您可能會認爲所有路由器和VPN軟件以及WAN和NAT以及人們將網絡連接在一起的任何其他事物都可以實際處理多播信標數據包。

#1,你假設客戶端可以發送一個UDP數據包到服務器。這是一個完全合理的期望,特別是考慮到客戶端接下來要做的事情就是建立到同一臺服務器的TCP連接。

如果服務器出現故障,而且客戶希望找出時,它的備份,是一定使用exponential backoff否則你將採取網絡打倒一個數據包風暴一天!

+1

選項#1也基於發送一個多播數據包,它只是在相反的方向 - 所以類似的警告適用。 – caf 2009-07-30 04:53:04

4

我在過去幾次使用過選項#2。它適用於簡單的網絡拓撲。當UDP數據報超過以太網MTU導致大量碎片時,我們看到一些吞吐量問題。我們看到的最大的問題是多點發現在較大的拓撲中發生故障,因爲許多路由器被配置爲阻止多點傳送流量。

當你設計你的協議套件時,issue that Greg alluded to是非常重要的。只要您超越簡單的網絡拓撲,就必須找到address translation,IP spoofing的解決方案,以及與從發現層到通信層的越區切換有關的其他一系列問題。他們中的大多數都必須專門針對您的服務器如何識別自己,並確保識別是客戶可以使用的。如果我可以再做一次(我們說過多少次),我會尋找基於標準的發現機制,以適應賬單並開始解決其他協議套件問題。你真正想要做的最後一件事是提出一個非常好的發現方案,由於一些不可預見的網絡拓撲結構,在部署完成後的一週內就會打破。 Google service discovery作爲首發名單。我個人傾向於DNS-SD,但有很多其他選項可用。