Wykrywanie serwerów UDP - czy klienci powinni wysyłać pakiety multiemisji, aby znaleźć serwer, czy serwer powinien wysyłać regularne sygnały nawigacyjne?

Question

Mam klientów, którzy muszą połączyć się z procesem na pojedynczym serwerze. Używam wykrywania UDP dla klientów, aby znaleźć serwer. Mam klienta i serwer wymieniają adres IP i numer portu, aby połączenie TCP/IP mogło zostać ustanowione po zakończeniu wykrywania. W ten sposób rozmiar pakietu jest mały. Widzę, że można to zrobić na jeden z dwóch sposobów: UDP:

1. Każdy klient wysyła własną wiadomość multiemisji w poszukiwaniu serwera, na który następnie odpowiada serwer. Klient może powtarzać wysyłanie tej wiadomości multiemisji w regularnych odstępach czasu (w przypadku, gdy serwer jest wyłączony), dopóki serwer nie odpowie.
2. Serwer wysyła wielokierunkowy sygnał ostrzegawczy w regularnych odstępach czasu. Klienci subskrybują grupę multiemisji iw ten sposób odbierają komunikat multiemisji serwera i uzupełniają wykrywanie.

W 1. Jeśli jest wielu klientów, wówczas początkowo byłoby wiele wiadomości multiemisji wysyłanych (po jednym z każdego klienta). Tylko serwer będzie subskrybować i odbierać wiadomości multiemisji od klientów. Gdy serwer odpowie na klienta, klient przestaje wysyłać wiadomość multiemisji. Po zakończeniu wykrywania serwera przez wszystkich klientów nie są przesyłane żadne dalsze wiadomości multiemisji w sieci. Jeśli jednak serwer jest wyłączony, wówczas każdy klient będzie wysyłać sygnał nawigacyjny multiemisji w odstępach czasu, dopóki serwer nie zostanie utworzony i może odpowiedzieć.

W 2. tylko serwer wysyłałby wielokierunkowy sygnał ostrzegawczy w regularnych odstępach czasu. Ta wiadomość zostanie ostatecznie przekierowana do wszystkich klientów, którzy zasubskrybowali grupę multiemisji. Gdy klienci otrzymają pakiet, gniazdo nasłuchiwania UDP klienta zostanie zamknięte i nie będą już subskrybować grupy multiemisji. Jednak serwer musi nadal wysyłać sygnał multicast, aby nowi klienci mogli go wykryć. Nadal będzie wysyłał sygnał nawigacyjny w regularnych odstępach czasu, niezależnie od tego, czy jakikolwiek klient jest zmuszony do jego odkrycia, czy nie.

Widzę więc zalety i wady w obie strony. Wydaje mi się, że # 1 spowodowałoby początkowo większe obciążenie, ale obciążenie to ostatecznie spadnie do zera. W punkcie 2 serwer będzie wysyłał na zawsze sygnał nawigacyjny.

UDP i multicast to dla mnie całkiem nowy temat, dlatego jestem zainteresowany ustaleniem, które z nich byłoby preferowanym podejściem, a które spowodowałoby mniejsze obciążenie sieci.

Answer 1

Polecam metodę # 2, ponieważ jest prawdopodobne (w zależności od aplikacji), że będziesz miał znacznie więcej klientów niż serwery. Jeśli serwer wysyła sygnał nawigacyjny, wysyła się tylko jeden pakiet co jakiś czas, a nie jeden pakiet dla każdego klienta.

Inną zaletą tej metody jest to, że ułatwia ona klientom określenie, kiedy nowy serwer staje się dostępny, lub gdy istniejący serwer opuszcza sieć, ponieważ nie muszą oni utrzymywać połączenia z każdym z nich. serwer lub utrzymywać odpytanie każdego serwera, aby się dowiedzieć.

Answer 2

Obie metody są równie opłacalne.

Argumentem dla metody nr 1 jest normalne, że klienci inicjują żądania, a serwery nasłuchują i odpowiadają na nie.

Argumentem dla metody nr 2 byłoby to, że punktem rozsyłania grupowego jest to, że jeden host może wysłać pakiet i może zostać odebrany przez wielu klientów (jeden-do-wielu), więc ma być odwrotnością # 1.

OK, ponieważ myślę o tym, że jestem w rzeczywistości przyciągnięty do # 2, inicjowanego przez serwer sygnału nawigacyjnego. Problem z numerem 1 polega na tym, że np. Klienci emitują sygnały nawigacyjne i łączą się z serwerem, ale serwer przechodzi w tryb offline lub zmienia adres IP.

Po utworzeniu kopii zapasowej serwera i wysłaniu pierwszego sygnału nawigacyjnego wszyscy klienci zostaną powiadomieni w tym samym czasie, aby nawiązać połączenie ponownie, a cały system zostanie natychmiast utworzony. Z numerem 1 wszyscy klienci musieliby osobiście zdać sobie sprawę, że serwer zniknął, i wszyscy uruchomiliby multiemisję w tym samym czasie, aż do połączenia z serwerem. Gdybyś miał 1000 klientów i 1 serwer, obciążenie sieci byłoby dosłownie 1000 razy większe niż w przypadku metody # 2.

Wiem, że te wiadomości są najprawdopodobniej małe, a 1000 pakietów na raz jest niczym w sieci UDP, ale tylko z punktu widzenia projektu # 2 czuje się lepiej.

Edit: czuję jakbym rozwój zaburzenia osobowości split-tu, ale po prostu myślał o silnym punktem dlaczego nr 1 będzie dodatkowym atutem ... Jeśli kiedykolwiek chciał wdrożyć jakiś naturalny Równoważenie obciążenia lub skalowanie z wieloma serwerami sprawia, że ​​projekt nr 1 działa dobrze. W ten sposób pierwszy "dostępny" serwer może odpowiedzieć na sygnał nawigacyjny klienta i połączyć się z nim, w przeciwieństwie do # 2, gdzie wszyscy klienci przeskakują do serwera sygnalizującego.

Answer 3

Twoja opcja nr 2 ma duże ograniczenie polegające na tym, że serwer może komunikować się mniej więcej bezpośrednio z każdym możliwym klientem. W zależności od dokładnej architektury sieciowej systemu operacyjnego może to nie być prawdą. Na przykład możesz polegać na tym, że wszystkie routery i oprogramowanie VPN oraz WAN i NAT oraz inne rzeczy, z którymi ludzie łączą sieci, mogą obsłużyć pakiety sygnału nawigacyjnego multicast.

Z # 1, zakładasz, że klienci mogą wysyłać pakiet UDP do serwera. Jest to całkowicie uzasadnione oczekiwanie, zwłaszcza biorąc pod uwagę, że następną rzeczą, którą klient zrobi, będzie połączenie TCP z tym samym serwerem.

Jeśli serwer idzie w dół, a klient chce się dowiedzieć, kiedy to z powrotem w górę, być pewien używać exponential backoff inaczej weźmiesz sieci w dół z burzą pakietów pewnego dnia!

Answer 4

Użyłem opcji nr 2 w przeszłości kilka razy. Działa dobrze dla prostych topologii sieci. Widzieliśmy pewne problemy z przepustowością, gdy datagramy UDP przekroczyły MTU sieci Ethernet, powodując dużą fragmentację. Największym problemem, jaki zauważyliśmy, jest to, że wykrywanie multiemisji rozkłada się w większych topologiach, ponieważ wiele routerów jest skonfigurowanych do blokowania ruchu multiemisji.

Podczas projektowania pakietu protokołów należy raczej wziąć pod uwagę issue that Greg alluded to. Gdy tylko przejdziesz poza proste topologie sieci, będziesz musiał znaleźć rozwiązania dla address translation, IP spoofing i całego szeregu innych problemów związanych z przekazaniem od twojej warstwy wykrywania do warstwy komunikacyjnej. Większość z nich musi w szczególności dotyczyć sposobu, w jaki serwer identyfikuje się i zapewnienia, że ​​identyfikacja jest czymś, z czego klient może skorzystać.

Gdybym mógł zrobić to od nowa (ile razy wypowiadaliśmy to zdanie), szukałbym mechanizmów wykrywania opartych na standardach, które pasują do rachunku i zaczynają rozwiązywać inne problemy z pakietem protokołów. Ostatnią rzeczą, którą naprawdę chcesz zrobić, jest stworzenie naprawdę dobrego schematu wykrywania, który łamie tydzień po wdrożeniu z powodu nieprzewidzianej topologii sieci. Google service discovery dla listy startowej. Osobiście zmierzam w stronę DNS-SD, ale dostępnych jest wiele innych opcji.