Комментарии 30
Но если сеть индустриальная, то часто DHCP сервер не используется
но ! если сеть одновременно "индустриальная" и "энтерпрайзная", то DHCP сервер опять используется.
Удобно использовать SSDP/UPnP протокол для обнаружения устройств в сети, практически в каждом своем проекте IoT его применяю. Были проблемы с поиском адекватного сканера под Android, но в итоге бросил и написал свое приложение.
Все хорошо пока разрешены в сети мультикасты. А так приходится надеятся на старый добрый dhcp и хардварную кнопку сброса до заводских настроек.
За труд спасибо, было полезно.
Как будто DHCP предсказуемее (если конечно доступно управление DHCP сервером): все адреса хранятся в одном месте, там же лежит сопоставление хост/адрес, устройства перезапрашивают аренду, подтверждая свою живость, для конфигурации не требуется абсолютно никаких действий с устройством, можно легко переезжать в другую подсеть, если вдруг надо — никаких "перенастрой 100 устройств", есть достаточная гарантия того, что одинаковых адресов в сети не будет (сервер ошибается сиииильно реже, чем человек, настраивая руками) и так далее. Хочется не трогать DHCP сервер? mDNS.
Потом железка с DHCP дохнет и всё встаёт колом.
И ещё DHCP сам по себе работает только для клиентов. А многие девайсы по своей сути - серверы.
mDNS решает часть проблем, но поддерживается мягко скажем не везде (привет Microsoft)
И ещё DHCP сам по себе работает только для клиентов. А многие девайсы по своей сути - серверы.
Это как?
Ну те же сетевые принтеры - это по своей сути серверы. Они могут получать адреса по dhcp, но в настройках драйвера принтера на каждом компе надо прописывать айпишник
...или имя хоста и тогда плевать какой там IPшник выдал DHCP этому принтеру.
А вообще ваша первоначальная фраза прозвучала так как будто серверная, в которой сервера получают адреса от DHCP, как бы и не серверная, а... клиентская (извините).
...или имя хоста и тогда плевать какой там IPшник выдал DHCP
Расскажите, как это сделать в windows 7
серверная, в которой сервера получают адреса от DHCP, как бы и не серверная, а... клиентская
Какая серверная? Речь про условный small office на три компа, сетевое мфу, вумную лампочку и вайфай для телефонов. DHCP там раздаёт какой-то роутер, он же и насом подрабатывает. И вот если у роутера нет в настройках чего-то типа MAC pinning, то хьюстон у нас проблемы.
У меня асусовский роутер умеет ресолвить хосты типа my-printer.local в правильный IP.
в windows и linux вполне работает LLMNR, это как mdns, только не как в bonjour/apple :] Впрочем, умеют ли это нынешние мыльницы, мне неведомо.
Реализаций mDNS для Windows больше одной для каждого языка программирования. И работает хоть по IPv4, хоть по IPv6, плюс service discavery. У mDNS главный недостаток -- UDP multicast может не всюду "добивать". И в таком случае, наверное нет альтернативы как-то сделанному динамическому DNS для всей сети.
Потом железка с DHCP дохнет и всё встаёт колом.
адреса выдаются на 3 года.
настройки DHCP можно поднять из бэкапа и развернуть новый сервер за 1 день. если торопиться - за 1 час.
mDNS идет лесом.
Если в протоколах RS-232, RS-485, USB пакет данных всегда будет доставлен, то в Ethernet доставка пакетов негарантированная.
Ээээммм. Ну, во-первых, RS-232 и RS-485 это не протоколы, это физуровень. Протокол выше может как гарантировать доставку, так и нет. Сама последовательная передача ничего не гарантирует, даже то, что эту передачу вообще кто-нибудь услышит и примет, это просто ногодрыг.
В USB — для изохронного канала доставка не гарантируется, для поточного гарантируется, зависит от того, что вы хотите делать, файл передавать на флешку или с микрофона писать звук.
Согласен. Термин "протокол" для RS-232 и RS-485 я выбрал неверный, поправлю.
Вообще о гарантии передачи сообщения можно говорить только, когда ответная сторона подтвердила доставку либо не сообщила вовремя о замеченной потере. Для пакетной передачи такая гарантия влечёт за собой неконтролируемую задержку доставки. Я же имел в виду, что для физического уровня соединения точка-точка потеря сообщения это нештатная ситуация уровня разрыва провода. Обычно можно расслабиться и считать "ногодрыг" на передающей стороне всегда успешным. Для сетевого соединения в топологии звезда потеря сообщений это штатная ситуация. И для управления в реальном времени приходится переходить на другие топологии, такие как, например, кольцо в EtherCAT.
Подход авто обнаружения устройств на самом деле очень удобен, в особенности, если идет речь о домашнем применении. Проблема ИТ индустрии заключается в том, что у нас до сих пор нет стандарта, который описывал бы обнаружение устройства с предоставлением информации о состоянии и функциональности. Например, подключаете к сети сетевую кофеварку. А вам винда такая, в сети обнаружена новая кофеварка с кофе зернами, она умеет варить кофе, хотите закапучиниться?
У нас с AutoIP на Windows началось забавное после обновления корпоративной ОС с 10 версии на 11. Windows 11 выбирает случайный интерфейс, если в системе есть несколько интерфейсов с автоназначенным адресом и указанный адрес хоста ещё ни разу не был достигнут. После первого успешного обращения к хосту "правильный" интерфейс кешируется и используется в дальнейшем. Подсеть у интерфейсов одна и маршруты добавляются одинаковые, но на 10 винде первый пакет похоже засылался на все интерфейсы. А на 11ой пока n пингов до первого успешного не отправишь хост недоступен, т.к. пакеты улетают не в тот интерфейс.
Что называется "вовремя". Я тут недавно делал POC SSDP обнаружения устройства на основе gssdp библиотеки и долго долго искал информацию на очень простой вопрос (но так и не нашел): А должен ли device-UUID сохраняться между перезапусками устройства?
Замечу, что для поиска устройств есть еще Web Service Discovery. Он вполне используется в стандарте ONVIF (IP-видеонаблюдение, если грубо). Он он очень многословен и требует нормального парсера XML - там все прелести в виде схем, namespace-ов и т.д.
Ага, и по моему опыту в Windows ответы WS-Discovery на сокет переставали приходить через пару минут после первого запуска. Как это отключить -- не знаю, хотя работающие программы от производителей камеры были и в Wireshark пакеты с ответами для них были.
А так -- только через dasHost, он как-то получает всю информацию.
Минусы у Ethernet тоже есть.
Самый главный минус, особенно для МК, в том, что надо тянуть большой и толстый TCP/IP стек. И иметь ответ на вопрос: "А когда будет IPv6?"
Вещь в некоторых случаях нужная. Спасибо.
Но есть неоднозначтность. Прога собрана под Windows, в сети принтер HP с параметрами:
Скрытый текст
После нажатия "Search" - в окне пусто. Firewall остановлен. Есть мысли куда копать? Или это другое?
Обнаружение устройств через UPnP / SSDP