Как реализовать multicast в интернете?

Question

[Виталий Пухов]

Я прекрасно понимаю что ответ будет - никак. Я имел в виду как реализовать подобное. Суть в следующем, есть сервер на белом IP и клиенты за NAT, IP сервера неизвестен, нужен способ без выделенного конкретного сервера с конкретным IP донести до клиентов какой IP у сервера. В локалке это легко реализовал через мультикаст, хочется расширить функционал до Всея интернета. Думал насчет реализации через DHT, но там все равно нужно знать хотябы 1 узел из сети.

Comments

[hobbyte]

Просто утонить: сервер вам подвластен, использовать DNS нет возможности?

[hobbyte]

*уточнить

[Виталий Пухов]

hobbyte: я себе это вижу примерно так, программа open source и любой может ее скачать и запустить, и тем самым станет сервером, я не могу знать заранее кто это будет. DNS в такой ситуации не поможет.

Answer 1

[Алексей]

Клиенты за NAT. Они же сидят за каким-то сервером, который смотрит в интернет?

В интернете никто ваши мультикасты транслировать не будет. Представьте что будет с каналами если такое позволить реализовывать?

Думается что вы проблему пытаетесь решить не с той стороны...
Опишите подробнее.

Comments

[Виталий Пухов]

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

[Алексей Черемисин]

Виталий Пухов: Сделайте пул координаторов, сервер, при включении регистрируется на одном из координаторов, координаторы обмениваются адресами серверов. Все координаторы имеют одно DNS имя. Сам сервер DNS будет клиентам раздавать адреса координаторов по round-robin - https://ru.wikipedia.org/wiki/Round_robin_DNS

[Алексей Черемисин]

RR - стандартный механизм любого DNS-сервера.

[Алексей]

Виталий Пухов: ждут клиенты как? Висят слушатели на каком-то порту или что? Все равно нужен один сервер, у которого всегда один и тот же IP или имя доменное, а уж он дальше будет распределять кто куда.

[Виталий Пухов]

Алексей Черемисин: Алексей: Про RR и пул координаторов это понятно, но суть в том что заранее не должно быть известно IP сервера, и хотелось исключить какие либо посредники, судя по всему не получится

[Виталий Пухов]

Алексей Черемисин: не уточнил, про RR исключаю пока потому как невозможно быстро и без заморочек зарегистрирова DNS для нового сервера, не говоря уже о том, что обновление DNS займет кучу времени

[Алексей Черемисин]

Виталий Пухов: Увы, IP-протокол, который маршрутизируется в глобальной сети, устроен так, что нужна точка входа или несколько точек.
Все P2P сети устроены аналогично. Есть изначальный пул точек входа, с которых мы получаем "последние зерегистрированные IP-адреса", далее проходим по ним и подключаемся к живому серверу.
Технически, клиенты в P2P являются и серверами, тогда можно у любого клиента спросить список других клиентов.
Но при запуске всё равно нужно знать хоть пару-тройку живых серверов.

Answer 2

[Валентин]

Легко) Мультикаст также может маршрутизироваться, просто нужно поставить TTL больше 1.

Почему никак:

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

Думал насчет реализации через DHT, но там все равно нужно знать хотябы 1 узел из сети.

В любом случае нужно знать хоть один адрес с чего начать. Это может быть адрес группы мультикаста, сервера. Не может быть только в пределах одного LAN, но это решается на уровне Ethernet (ARP) через broadcast-адресацию. Возможно вам нужно посмотреть в сторону broadcast ip-адресов.

Comments

[Виталий Пухов]

Насколько я понял адрес группы мультикаста для глобальной сети работать не будет (как раз первый случай) (или будет, но только если все на белых адресах), про broadcast ip-адресов не совсем понятно, по идее это как раз тот же самый мультикаст только пара байт другая в конце и они провайдеру тем более не дались и их точно так же будут резать, или я что то не правильно понимаю?

[Валентин]

Виталий Пухов: вы спросили "как реализовать мультикаст в интернете", я ответил и объяснил почему. Что именно вам непонятно?

Про "белые" адреса я ничего не писал, с позиции интернета мультикаст-группы - "серые" адреса. Про broadcast вам нужно немного почитать теорию IP-маршрутизации.

[Валентин]

Виталий Пухов: если ответ помог, не забудьте пометить как решение

[Виталий Пухов]

Валентин: к сожалению TTL ничем не помог, вероятно режется провайдером

[Виталий Пухов]

Валентин: про broadcast тоже не все ясно, "вроде как рабочий" пример с MSDN в моем окружении работает только в 1 направлении, в обратном по какой то причине пакеты не ходят

Answer 3

[Алексей Черемисин]

Ответ - никак, правильный. Если мы про мультикаст. Ну а если про интернет, то есть такая весчь как DNS, почему ей не воспользоваться?

Comments

[Виталий Пухов]

ок, а если серверов будет 2 или 155? клиенты должны узнать о существовании каждого из них, тут нужен механизм координации друг с другом наподобии DHT, чего не хотелось бы

[Алексей Черемисин]

А обязательно знать каждого? может быть достаточно знать 3-10 рабочих? Да сам механизм достаточно простой, координации никакой не нужно, просто рассылаем рандомно 5-6 серверам свой весь свой список. Через некоторое время все сервера будут знать всех.

[Алексей Черемисин]

И да, ну нет, нету в глобальном интернете мультикаста! Что-то нам обещает переход на IPv6 с его anycast, но мне кажется, то провайдеры будут его закрывать... (очень кажется)

[Виталий Пухов]

Алексей Черемисин: Видимо придется так и сделать, тут проблема как раз в "через некоторое время". С мультикастом задержки отсутствуют, кроме сетевых на передачу. А тут нужно еще эту информацию колбасить между серверами.

[Алексей Черемисин]

Мультикаст = локалка. По другому никак! С другой стороны, если у клиента уже есть старый кеш серверов, то он достаточно быстро будет старотовать. фактически так делает битторрент, и не только...