Допустим, у вас есть 2 сервера по 8 ядер ЦП каждый.
Каждый сервер запускает 8 сетевых сервисов, на каждой из которых размещается произвольное количество долгоживущих клиентских соединений TCP / IP.
Клиенты отправляют сообщения сервисам.
Услуги сделай что-нибудь на основе сообщений и потенциально уведомить N> 1 клиентов об изменениях состояния.
Конечно, это похоже на ботнет, но это не так. Рассмотрим, как IRC работает с соединениями c2s и s2s и ретрансляцией сообщений s2s.
Как бы вы координировали, какие службы на каком хосте должны получать и ретранслировать сообщения подключенным клиентам для сообщений об изменении состояния?
Есть бесконечное количество способов эффективно решить эту проблему.
Я ищу решение, которое:
Какой у вас опыт?
Что вы порекомендуете?
Спасибо!
Если:
Тогда многоадресная рассылка IPv4 будет работать прямо из коробки именно для того, что вы пытаетесь сделать. Получатели подписываются на канал (группа многоадресной рассылки), отправители отправляют дейтаграмму UDP на адрес многоадресной рассылки, коммутатор определяет, кто что получает. Это заставляет ваше сетевое оборудование разумно обрабатывать маршрутизацию сообщений.
Если ваш переключатель не поддерживает отслеживание IGMP, тогда он будет рассматривать многоадресные кадры (Ethernet) как широковещательные и отправлять их на все хосты в VLAN, независимо от того, запрашивал ли их хост или нет. Таким образом, вы забьете трубку между коммутатором и хостами, даже если ОС хоста просто отбрасывает пакеты, прежде чем они попадут в какое-либо приложение.
Вы по-прежнему можете использовать многоадресную рассылку IPv4, если все они не находятся в одной VLAN, но вам нужно больше настроить свое оборудование, чтобы оно работало, но оно все равно будет работать нормально.