кто сталкивался, подскажите как правильно реализовать такой функционал (не могу понять что-то). Имеем веб-сервер и удаленный терминал на основе Ардуино Мега 2560 + шилд с SIM800C. Удаленный терминал постоянно опрашивает веб-сервер по API для получения некоторых данных.
Чтобы было актуально планирую опрашивать каждые 5 минут (этого по идее достаточно), но есть загвоздка что на сервере могут появится данные которые нужно передать сразу в удаленный терминал. В таком случае 5 минут ОЧЕНЬ много, но опрашивать каждые 5 секунд мне кажется не рационально, да и может потеряться связь, в таком случае это вообще увеличит время получения данных терминалом неизвестно насколько.
Вопрос: как правильно реализовать чтобы когда вебсерверу нужно передать данные в удаленный терминал, он это делал почти моментально ? И эти данные уже должны храниться в терминале потом, чтобы если связь прервалась их можно было бы использовать ?
Я вижу только очень частый опрос веб-сервера, тк удаленный терминал имеет динамический ip и городить систему с DDNS для того чтобы к нему был доступ думаю не реально. Но такой функционал существует, но как он сделан - не пойму (знаю только что есть на STM32 и есть и на Ардуино).
Буду очень признателен за наводки в области решения данной проблемы. Может железяки не подходят поменять нужно ?
Если одна сторона желает уведомить другую немедленно, то между ними либо должна уже существовать сессия, либо она должна быть организована заинтересованной стороной.
Я использую TinyGSM - чтобы не париться с АТ командами, и соединяюсь с АПИ по http (а тут только клиент может начать соединение). Может есть ссылка на какую нибудь библиотеку где пример с tcp есть ?
вот и вопрос как организовать сессию со стороны сервера до терминала ? Насколько я понял ардуино как клиент работает с TinyGSM, хотя можно и сервером его сделать, но это тоже для меня не вариант. А сделать его клиент-сервером не получится (или я плохо искал)
Очевидно, что нужна достижимость ардуины с сервера. Т.к. “удаленный терминал имеет динамический ip и городить систему с DDNS для того чтобы к нему был доступ думаю не реально”, то решения нет.
не имеет значения как вы соединяетесь. В вашем случае смена http на tcp ничего принципиального не изменит.
Чтобы клиент был достижим оперативно - вы либо держите сессию открытой постоянно, либо запрашиваете данные с сервера каждые N секунд (5 или 30 - это уже зависит от того, насколько “оперативной” должна быть реакция клиента).
При отсуствии коннекта от сервера к клиенту (а это ваш вариант) - ДРУГИХ ВАРИАНТОВ НЕТ.
Опрашивайте с установленным интервалом 5,10,30 мин.
А если серверу нужна железка моментом на связи - то делаем с сервера голосовой звонок, посыл СМС - и железка приняв вызов моментом конектится к серверу т получает то что ей надо.
Ну тот факт, что с пользовательской стороны TCP нет никаких пакетов, - какая это проблема, разумеется. (там есть свой механизм поддержания сессии, без всякого вот этого рукожопства)
Читал тему. Перечитывал. Много думал. Утром встал вопрос, не то, про что вы подумали - а зачем вы websocket заново изобретаете?
Без сарказма если, то это и есть надстройка на tcp, удобная в описанном контексте.
То есть или мы переспрашиваем о наличии новой информации каждую секунду, условно. Или пользуемся сессиями tcp. Во втором случае вебсокет очевидное решение.
Третий вариант возможен только в алкогольных фантазиях про “гипертекстовый, векторный фидонет”.
