fk0легенда (18.09.2020 21:49, просмотров: 536) ответил lloyd на Обычно никогда не заморачивался с веб-нотификациями, поэтому даже
не изучал этот вопрос. Только знакомым рекламу через них
рассылаемую приходилось удалять из настроек браузера.Но в том, то и идея, что не обязательно свой. А если речь о работе в ЛВС, то там браузер может обратиться непосредственно на веб-сервер самой лампочки (и, кстати, откуда загрузить ту статическую страничку). Другой вопрос, как его обнаружить. Я бы скорей ориентировался на какой-либо способ сканирования портов: локальный DNS редко у кого есть и ещё реже туда будут прописывать каждую лампочку. Через вебсокеты, например.
Идея в том, чтоб сервер был однотипный для разнообразных IoT приложений. Не сервер фирмы имени такой-то для приборов таких-то. А просто некий абстрактный IoT-сервер. Как существует, например, DNS-сервер и он работает с любыми возможными приложениями. Сервер по сути решает только две задачи:
1) имеет известный белый IP-адрес к которому могут обратиться и мобильный телефон и умная лампочка;
2) поддерживает не отнимающее ресурсы UDP "соединение" (и пробивает NAT-ы по всей цепочке) с умной лампочкой и способен принятые по HTTPS данные быстро передать нужной лампочке (данные передаются, подразумеваем, не часто).
Последнее чрезвычайно важно. Допустим в квартире 10 лампочек, в доме 100 квартир, в городе 10000 домов в городе: 10 млн. умных устройств! Какие ресурсы может выделить общегородской сервер, спрашивается, на одну лампочку? Несколько сотен байт от силы. Про отдельное TCP-соединение с каждым можно даже не заикаться (там сотни кБайт). По сути сервер про лампочку должен знать её IP-адрес, порт и некий временный идентификатор. Ещё байт на состояние FSM и пару на таймер. Как-то так... В два десятка байт можно уместиться. На клиентский HTTP больше потратится (там нужны лимиты для айпишников и какой-то механизм валидации и блокировки повторяющихся сообщений -- https явно оверкилл).
Легковесный сервер смогут поддерживать разные организации и предоставлять возможность его использования сторонними клиентами (как сейчас это работает с NTP, например), если это не будет отнимать существенных ресурсов. Единый протокол (трансляции HTTP-->UDP) позволит пользоваться сервером разными несовместимыми приборами (понятно, что на уровне самих данных там может быть что угодно).
Такой сервер ничего не хранит, только транслирует. И только в одну сторону (http-->udp). Принял POST-запрос, и далее или откинул, или переслал. И всё. Коммуникация со стороны UDP же заключается в приёме запроса на "регистрацию", выдаче идентификационного кода, периодическом "пинге" от клиента (чтоб NAT не протух и идентификационный код тоже) и переправке сообщения клиенту (можно получение подтверждения о доставке от клиента выдать в ответе, в HTTP). Задача сервера в режиме реального времени принять сообщение по HTTP и доставить по UDP. И только.
В обратную сторону могут быть браузерные нотификации, какие-то другие сервера (где объём данных большой). Потому, что даже на уровне нотификаций -- их уже хранить нужно где-то. И траффик может быть значительный. Но нотификации могут проходит в очень мягком реальном времени. А управление -- должно быть моментальное или никакого. Ну да, через UDP обратно могут идти, опять же в реальном времени, в ответ на управляющее воздействие, какие-то моменальные короткие ответы. Но управляющий канал -- это очень короткие и не частые сообщения (нажатия кнопок на пульте). Он не для телеметрии и т.п.
Неужели я что-то новое изобрёл?