LINUX.ORG.RU

как спроектировать такое приложение?

 , ,


0

1

В браузере должно отображаться состояние прибора постоянно- желательно как можно ближе к RT с поправкой на сеть разумеется. К прибору подключаться по TCP сокетам.

Сейчас сделано так

Web browser <----AJAX-----> Apache+PHP <---TCP sockets------> Прибор

Браузер говорит что ему надо данных, php получает от браузера запрос, и открывает соединение с прибором полуает данные и отправляет в браузер. PHP не принципиально.

Вопрос: как такое лучше сделать чтобы каждый раз не отправлять запрос из браузера, но при этом получать данные с устройства постоянно? Web sockets?

★★★★★

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

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

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

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

deep-purple ★★★★★ ()

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

crutch_master ★★★★★ ()
Ответ на: комментарий от crutch_master

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

anonymous ()

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

snizovtsev ★★★★ ()
Ответ на: комментарий от Harald

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

snizovtsev ★★★★ ()

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

То я бы делал не так. Ну, если мне действительно были бы нужны данные практически в 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. Прочёл комменты. Взоржал аки конь стоялый... Кто все эти люди и что они здесь делают? =)))

Moisha_Liberman ()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)

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

KillTheCat ★★★★★ ()
Ответ на: комментарий от sniper21

Да незачто!

Только, чтобы проще курилось, ставите вот эту вот штуку (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. Учитывая то, что я всем этим уже давно с ног до головы обмазался, задавайте вопросы. Помогу чем смогу.

Moisha_Liberman ()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)