я ничем не могу вам помочь, если вы отказываетесь понимать

a: mDNS
b: NetBIOS
c: Captive DNS

Вариант C поломает работу DNS всех устройств в сети поэтому его следует использовать только при соединении точка-точка.
Вариант B - Win only, да и Netbios может быть отключен/заблокирован.

Сообщение отредактировал sharikov - Aug 20 2017, 07:46

Большое спасибо! Похоже - это именно то, что нужно.
Как я понимаю:
1. Устройство вносит 01:00:5E:00:00:FB в MAC-фильтр мультикастных адресов.
2. Ждёт по этому MAC UDP-пакеты для IP=224.0.0.251 порт 5353.
3. Сравнивает имена из этих пакетов со своим именем в формате: имя_устройства-серийный_номер.local (а можно даже несколько имён - одно с серийником, а одно - одинаковое для всех устройств - имя_устройства.local).
4. Обнаружив такой пакет (запрос) отвечает на него со своим IP.

Остаются только вопросы:
1. Насколько mDNS общепринят и распространён? Т.е. - можно-ли ожидать, что на некоей системе пользователя, после того как пользователь ввёл имя_устройства в адресной строке браузера, браузер обратился за разрешением этого имени к классическому DNS (если он есть в системе), классический DNS ответил "не знаю такого имени", то запрос разрешения этого имени будет перенаправлен далее в mDNS? (если классического unicast-DNS в системе нет, то запрос сразу должен быть отправлен в mDNS).
2. Нужны-ли специальные настройки роутера, чтобы мультикастные кадры на 01:00:5E:00:00:FB ретранслировались через шлюз в другие подсети или роутеры это делают по дефолту? Хотя это не очень важный вопрос - не будут уходить кадры в другую подсеть - ну и ладно.

Вобщем mDNS - это примерно то, что я и хотел. Самый главный вопрос - это п.1.


Да, на прошлой работе в аналогичной задаче именно так и делали (через WINS). Но там были немного другие требования.
Вот тут пока неясный для меня момент:
В записях DHCP-сервера (внутри своего роутера) я вижу, что для каждого выданного им в аренду IP-адреса, он знает некое "host name". Это "host name" есть и для компа с виндой (для него оно совпадает с NetBIOS-именем компа) и для планшета и телефона с Андроид. И на своём устройстве я могу сообщить это имя DHCP-серверу.
Вот если-б веб-браузеры в этой сети, не получив разрешение имени от DNS, разрешали это имя через эти записи DHCP - это было бы тоже решением вопроса. Но похоже браузеры не используют эту инфу из DHCP.
Хотя в этом случае всё равно останется открытым вопрос для статического IP в системах без DHCP, но это уже не так критично.


Посмотрю его позже.


Не только Win, но то, что с большой вероятностью может быть выключен - это так.

основной вектор уже прозвучал.
Но я бы обратил бы Ваше внимание на уже сложившиеся традиции на этот счёт у всевозможных поставщиков IP камер и иже. И именно на такие действия надрочены лохи от продажи и простые обыватели.
И вот тут наверное надо определится кто покупатель, кто ЦА. Если профи - ему нужна только стабильность, возможность и простота действа. Чем проще(не путать с самоавтоматикой) и эффективней - тем лучше.

Ну и как альтернативу = если девайс достаточно большой, стационар... То я обычно использую ещё один канал = WiFi.
1) альтернатива повышает живучесть
2) можно с любого переносного планшета-смартфона настроить (для инициализации самое то сапорту)
3) стоимость 3 бакса
4) при поддержки дефолтного сервера - логинится сразу при включении вайфай и запуске броузера.

удачи вам
(круглый)

Покупатели будут разные.
Я почитал внимательнее про mDNS и пр. Всё это - части одного множества называемого "Zeroconf": https://ru.wikipedia.org/wiki/Zeroconf
Т.е. - это целый набор методов. Что-то из них работает под виндами (разными версиями), что-то - под линухом и т.п. Т.е. - чтобы более-менее обеспечить попадание в цель, нужно реализовывать всю их совокупность (или значительную часть). Так что пока отложил это на будущее - может реализую потом.
Пока пойду первым путём (из первого поста). Назначу второй фиксированный IP из области Link-local (169.254.1.0 ... 169.254.254.255). Вроде всё должно работать в любом случае.


Это конечно хорошо, но этот вопрос несколько из иной оперы.