как можно ближе к RT

Сидеть рядом с прибором.

У прибора своя частота обновления данных есть? А если таковой нет и отдача данных происходит исключительно по запросу извне, то частоту обновления данных устанавливает тот, кто за ними обращается, но не чаще, чем время за которое прибор может успеть подготовить и отдать данные (плюс немного на бездействие).

Так тебе с какого боку? Что за прибор?

У прибора своя частота обновления данных есть?

Похоже нет.

Что за прибор?

Цифровой мультиметр.

По-царски, конечно. Везде вебсокет и си вместо пхп.
Я бы сделал сервак на яве/питоне/ноде, опрашивал бы прибор раз в n сек и отдавал бы через ajax/ws/как надо.

опрос прибора реализовать в виде отдельного демона, данный пихать например в kafka, в таком случае кол-во потребителей данных может быть любым.

websockets. Если нет цели контролировать или перекодировать данные внутри сокета к девайсу на сервере, то после установки соединения можно просто заюзать exec(socat) для дальнейшего проксирования.

а отдельное нативное приложение уже не модно для такого?

Молодежь уже не та, да и менеджеры смузи за нативное приложение не нальют. У меня даже в коллективе плюсовиков многие не понимали разницы между приложениями telegram (qt) и slack (electron), и удивлялись, что второе я предпочитаю использовать в браузере.

FlashSSE ещё можно рассмотреть, он проще чем WS.

Я бы сделал сервак на яве/питоне/ноде

Нода, если вебморда. и красивости в react (vue)

Если по хорошему...

То я бы делал не так. Ну, если мне действительно были бы нужны данные практически в RT или близко к тому.

1 Данные с прибор, снимаемые раз в N секунд, я бы публиковал в MQTT брокер. Этот протокол для таких вещей и делался. Брокер, если что, поднимается на той же Raspberry Pi 2 или Orange Pi Zero W на счёт «раз». Mosquitto MQTT это «всеми любимый» голый С. Этот протокол для таких задач и создавался. В принципе, можно прикрутить тут кафку или ещё что... Но зачем?

2 Из брокера MQTT я бы читал приложением-подписчиком данные сразу, как только они были бы опубликованы в соответствующем канале. Дальше приложение-подписчик уже просто либо хранит их, либо визуализирует... Что угодно. Приблуда, кстати, может быть хоть на РС, хоть на ведроид (paho mqtt тот же). Это уже не важно.

Т.е., картинка упрощается:

MQTT-subscriber <--- MQTT-broker <--- MQTT-publisher <--- Датчик

Как-то вот так. Как в IoT принято. Более-менее.

Причины. Нехер пытаться спать на потолке. Законодательно не запрещено, но вот одеяло так и норовит упасть. Можно и не выспаться.

Во-первых, http никогда не разрабатывался для real-time или даже для его подобия. Во-вторых, php + apache это вообще-то даже близко не real-time, это два монстра. Здесь они типа из пушки по воробьям палить, неизвестно сколько воробьёв убьёшь, но посудную лавку разнесёшь в хлам, это точно (я это гарантирую). В третьих, запросы к устройству тут должны исходить не от браузера, а от опрашивающего устройства приложения (в нашем случае MQTT-publisher). Запросили, получили, опубликовали в брокер. Сабскрайбер получил практически сразу и вывел, например, на экран.

UPD. Прочёл комменты. Взоржал аки конь стоялый... Кто все эти люди и что они здесь делают? =)))

Взоржал аки конь стоялый... Кто все эти люди и что они здесь делают? =)))

Мы - прикладники. Нам похрен.

Делаешь демона, который собирает инфу с прибора с определенным интервалом и отдает по ws. Ну и html можно им отдавать. Все элементарно делается на go.

Спасибо, премного благодарен. Пошел курить все это.

Да незачто!

Только, чтобы проще курилось, ставите вот эту вот штуку (http://mosquitto.org/ или, оно же, https://github.com/eclipse/mosquitto) как положено в Вашем дистрибутиве. Оно есть вплоть до openwrt/lede.

В составе пакета есть или, точнее, должны быть две утилитины. mosquitto_pub и mosquitto_sub. Первая это паблишер, вторая это сабскрайбер. Т.е., в принципе, Вы можете затестить работу прямо с места. Не написав ни строчки кода.

Чтобы посмотреть как оно работает, используйте существующий тестовый брокер — https://test.mosquitto.org/ Он доступен и практически постоянно он-лайн. Понятно, что задержки будут, понятно что эмулируем сеть, но посмотреть как оно вообще и в принципе работает, если никогда раньше не сталкивался, вполне возможно и без траха с подъёмом своего MQTT-брокера, с самоподписанными сертификатами или с сертификатами от eff... Короче, просто поставить и посмотреть.

Ну и да. На сайте там не зря написано:

Please don't publish anything sensitive, anybody could be listening.

Да, всё так. Несмотря на то, что есть SSL/TLS, несмотря на то, что канал, который Вы создаёте, может быть припароленным, т.е., и паблишер и сабскрайбер входят по логину/паролю на канал, это публичный сервер и не стоит там размещать какую-либо чувствительную к разглашению информацию.

Так же обратил внимание что там заявлена поддержка websockets, заявлена она давно, как работает, без понятия.

Ну и в принципе, с libmosquitto на той же сишечке код пишется довольно легко и приятно. Сама по себе эта либа куда только не портирована (работал с нею даже на устройствах под openwrt/lede). Всё работает без вопросов.

UPD. Учитывая то, что я всем этим уже давно с ног до головы обмазался, задавайте вопросы. Помогу чем смогу.

Да ладно... =)))

Я же просто шучу. Не со зла же! =)

конечно MQTT и москит, это просто безальтернативно.

только веб-девы наверное будут против - это слишком просто и нет длинного веб-стека

Да.

Наверное. =)

ух. будем посмтреть...

Если надумаете применять MQTT, то почитайте про такую штуку, как MQTT over WebSockets.

Через MQTT можно реализовать, я сам по этому тутору https://nerdytechy.com/installing-mqtt-broker-on-raspberry-pi/ основы изучил, жаль на инглише