Обнаружение сервера UDP - Должны ли клиенты отправлять многоадресные рассылки для поиска сервера или сервер должен отправлять обычный маяковый сигнал? - PullRequest
9 голосов
/ 30 июля 2009

У меня есть клиенты, которым нужно подключиться к одному серверу. Я использую обнаружение UDP для клиентов, чтобы найти сервер. У меня есть клиент и сервер, обменивающийся IP-адресом и номером порта, так что соединение TCP / IP может быть установлено после завершения обнаружения. Таким образом, размер пакета остается небольшим. Я вижу, что это можно сделать одним из двух способов, используя UDP:

  1. Каждый клиент отправляет свое собственное многоадресное сообщение в поисках сервера, на который сервер затем отвечает. Клиент может повторять отправку этого многоадресного сообщения через регулярные промежутки времени (в случае, если сервер не работает), пока сервер не ответит.
  2. Сервер отправляет многоадресный маяковый сигнал с регулярными интервалами. Клиенты подписываются на многоадресную группу и таким образом получают многоадресное сообщение сервера и завершают обнаружение.

В 1. если имеется много клиентов, то первоначально будет передаваться много многоадресных сообщений (по одному от каждого клиента). Только сервер будет подписываться и получать многоадресные сообщения от клиентов. Как только сервер ответил клиенту, клиент перестает отправлять многоадресное сообщение. Как только все клиенты завершили обнаружение сервера, в сети не передаются дальнейшие многоадресные сообщения. Однако, если сервер не работает, то каждый клиент будет отправлять маяк многоадресного сообщения с интервалами, пока сервер не вернется и не сможет ответить.

В 2. только сервер будет отправлять маяк многоадресного сообщения через равные промежутки времени. Это сообщение будет в конечном итоге направлено всем клиентам, которые подписаны на многоадресную группу. Как только клиенты получают пакет, прослушивающий сокет UDP клиента закрывается, и они больше не подписываются на группу многоадресной рассылки. Однако сервер должен продолжать отправлять многоадресный маяк, чтобы новые клиенты могли его обнаружить. Он будет продолжать отправлять маяк через равные промежутки времени независимо от того, находятся ли какие-либо клиенты на обнаружении или нет.

Итак, я вижу плюсы и минусы в любом случае. Мне кажется, что сначала # 1 приведет к более тяжелой нагрузке, но эта нагрузка в конечном итоге уменьшается до нуля. В # 2 сервер продолжит посылать маяк навсегда.

UDP и многоадресная рассылка являются для меня довольно новой темой, поэтому мне интересно узнать, какой из них является предпочтительным, а какой приведет к меньшей загрузке сети.

Ответы [ 4 ]

4 голосов
/ 30 июля 2009

Я использовал вариант № 2 в прошлом несколько раз. Это хорошо работает для простых сетевых топологий. Мы видели некоторые проблемы с пропускной способностью, когда датаграммы UDP превышали MTU Ethernet, что приводило к большой фрагментации. Самая большая проблема, которую мы видели, заключается в том, что обнаружение многоадресной рассылки не работает в больших топологиях, поскольку многие маршрутизаторы настроены на блокировку многоадресного трафика.

Проблема , которую Грег намекал на , весьма важна для рассмотрения при разработке набора протоколов. Как только вы выйдете за рамки простых сетевых топологий, вам нужно будет найти решения для трансляции адресов , IP-спуфинга и целого ряда других проблем, связанных с передачей обслуживания из уровня обнаружения на ваш уровень связи. Большинство из них связаны именно с тем, как ваш сервер идентифицирует себя и гарантирует, что идентификация - это то, что клиент может использовать.

Если бы я мог сделать это снова (сколько раз мы произносили эту фразу), я бы искал основанные на стандартах механизмы обнаружения, которые отвечают всем требованиям, и начал бы решать другие проблемы набора протоколов. Последнее, что вы действительно хотите сделать, - это придумать действительно хорошую схему обнаружения, которая ломается через неделю после ее развертывания из-за непредвиденной топологии сети. Google service discovery для стартового списка. Я лично склоняюсь к DNS-SD , но есть много других доступных вариантов.

2 голосов
/ 30 июля 2009

Я бы порекомендовал метод # 2, так как вполне вероятно (в зависимости от приложения), что у вас будет гораздо больше клиентов, чем серверов. Имея сервер отправляет маяк, вы отправляете только один пакет, а не один пакет для каждого клиента.

Другое преимущество этого метода заключается в том, что клиентам легче определять, когда новый сервер становится доступным или когда существующий сервер покидает сеть, поскольку им не нужно поддерживать соединение с каждым сервером. или продолжайте опрашивать каждый сервер, чтобы узнать.

1 голос
/ 30 июля 2009

Ваш вариант № 2 имеет большое ограничение в том смысле, что он предполагает, что сервер может более или менее напрямую взаимодействовать со всеми возможными клиентами. В зависимости от конкретной сетевой архитектуры вашей операционной системы, это может быть не так. Например, вы можете полагать, что все маршрутизаторы и программное обеспечение VPN, а также WAN и NAT и любые другие объекты, с которыми люди соединяют сети, могут обрабатывать пакеты многоадресного маякового сигнала.

С # 1 вы предполагаете, что клиенты могут отправлять UDP-пакет на сервер. Это вполне разумное ожидание, особенно с учетом того, что следующее, что сделает клиент, - это установление TCP-соединения с тем же сервером.

Если сервер выходит из строя и клиент хочет выяснить, когда он вернулся, будьте уверены , чтобы использовать экспоненциальный откат в противном случае вы однажды отключите сеть из-за шторма пакетов !

1 голос
/ 30 июля 2009

Оба метода одинаково жизнеспособны.

Аргументом для метода # 1 будет то, что в обычном принципе клиенты инициируют запросы, а серверы прослушивают и отвечают на них.

Аргументом для метода # 2 будет то, что точка многоадресной рассылки такова, что один хост может отправлять пакет, и он может быть получен многими клиентами (один-ко-многим), так что это должно быть противоположностью 1.

Хорошо, когда я думаю об этом, я на самом деле тянусь к # 2, инициированному сервером маяку. Проблема с # 1 состоит в том, что, скажем, клиенты транслируют маяки, и они подключаются к серверу, но сервер либо отключается, либо меняет свой IP-адрес.

Когда сервер выполняет резервное копирование и отправляет свой первый маяк, все клиенты будут уведомлены одновременно о повторном подключении, и вся ваша система будет немедленно восстановлена. При использовании # 1 все клиенты должны будут по отдельности понять, что сервер пропал, и все они начнут многоадресную рассылку одновременно, пока не подключатся обратно к серверу. Если бы у вас было 1000 клиентов и 1 сервер, нагрузка на вашу сеть в буквальном смысле была бы в 1000 раз больше, чем при методе № 2.

Я знаю, что эти сообщения, скорее всего, маленькие, и 1000 пакетов за раз ничего не значат для сети UDP, но только с точки зрения дизайна # 2 чувствует себя лучше.

Редактировать: Я чувствую, что у меня здесь развивается расстройство раздвоения личности, но я просто подумал о важном аргументе, почему # 1 будет преимуществом ... Если вы когда-нибудь хотели реализовать некоторые При естественной балансировке нагрузки или масштабировании с несколькими серверами, дизайн № 1 хорошо подходит для этого. Таким образом, первый «доступный» сервер может ответить на маяковый сигнал клиента и подключиться к нему, в отличие от # 2, где все клиенты переходят на маяковый сервер.

...