LINUX.ORG.RU

UDP multicast

 , ,


0

2

Осваиваю MulticastSocket

Не могу понять, как выбрать multicast ip (ip class d) для минисервера, если клиенты располагаются в различных подсетях, хотя сервер пингуют все (подразумевается работа через интернет).

То есть я пытаюсь подобрать инструмент для решения задачи «подписки» и «отписки» на широковещательную рассылку udp пакетов. Как выбрать ip адрес для сервера в приложении (как я понял, он не соответствует ip адресу интерфейса подключения)?

Например я сейчас тестирую в локалке. Компьютер А - сервер, имеет ip 192.168.0.2, компьютер B - клиент, имеет ip адрес 192.168.1.2, оба подключены к одному маршрутизатору (подсети разные). Как компьютеру B слушать компьютер A? Ведь мы указывает multicast ip, как в данном случае выполняется поиск маршрута?

Deleted

Последнее исправление: merhalak (всего исправлений: 3)

Судя по всему, это всё же для локальной сети решение.

Deleted
()

Адрес мультикаст-группы и архитектура сети, вообще говоря, вещи несвязанные, если только речь не идет о интранете (в этом случае следует использовать https://en.wikipedia.org/wiki/Multicast_address#Local_subnetwork). Работает multicast подобно broadcast'у, с той разницей, что, если сетевое оборудование поддерживает multicast, то пакеты отправляются только на те порты, на которых есть члены мультикаст-группы. Если оборудование (коммутатор) про мультикаст не в курсе, то оно обычно поступает с мультикаст-пакетами так же, как и с broadcast-пакетами. Мультикаст-группы создаются и управляются по протоколу IGMP (https://en.wikipedia.org/wiki/Internet_Group_Management_Protocol). Именно его должно поддерживать сетевое оборудование, чтобы всё работало правильно.

asaw ★★★★★
()
Ответ на: комментарий от asaw

Я вот это всё творю с одной лишь целью: пилим небольшую игрушку (сервак хотят закинуть на Azure), есть ли смысл мучаться с UDP, если у нас просто нужна рассылка общего состояния всем клиентам (как бы вариант либо всё каждый раз через UDP, либо только diff по TCP)?

Или для игрушки UDP Multicast не нужен?

Deleted
()
Последнее исправление: merhalak (всего исправлений: 1)
Ответ на: комментарий от Deleted

С UDP (или лучше - с SCTP), наверное, есть смысл помучаться. А вот с Multicast - не думаю. Именно по причине отсутствия гарантий поддержки этого дела сетевым оборудованием. Multicast обычно используют провайдеры для IPTV, и в их случае это оправдано, т.к. экономия ресурсов налицо, а оборудование к контролируют они. В остальных случаях, как показывает практика, лучше с этим не связываться.

asaw ★★★★★
()
Ответ на: комментарий от Deleted

Ты собрался UDP мультикаст через интернет делать??? Это ничего не даст, ИМХО

а гемора прибавится, выше всё верно пишут

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

Сейчас пилю связку на JavaRMI + UDP. В JavaRMI получаю getClientHost и кидаюсь в него udp какашками. Правда как это будет работать в случае с серыми IP, я не представляю. Надо как то пробивать NAT.

Deleted
()
Ответ на: комментарий от Deleted

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

I-Love-Microsoft ★★★★★
()

multicast будет работать только в твоей локальной сети, или в сети, где все коммутаторы под твоим контролем. Через интернет, а темболее NAT - это работать не будет.

joy4eg ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.