Всем доброго времени суток. Есть небольшой устройство, работающее удаленно, устройство проводит определенный вид работ по расписанию, оснащено GPRS модем производства ОВЕН (ПМ01). Необходимо мониторить в реальном времени текущее состояние установки, а так необходима возможность запуска/остановки работы оборудования. Первый раз столкнулся с подобной задачей и пока слабо представляю реализацию протокола обмена данными между ними. Пока что был написан небольшой модуль на стороне сервера, который мониторит обращения методом GET и складывает данные с полей в файл. Так же со стороны модема была написана утилита, формирующая данный запрос на сервер. Потестировав данный способ, пришел к выводу, что он не совсем подходит для моих целей. Есть ли готовые велосипеды/варианты решения данной проблемы, по возможности поделитесь ссылками на статьи.

А разработчик (овен) что не предоставляет ПО к своим устройствам?

В идеале можно поднять на устройстве веб сервер и принимать запросы от клиентов на включение/выключение. Однако это решение требует приличных ресурсов на контроллере и реальный IP для каждого устройства.
Ваш вариант (с http клиентом на устройстве, насколько я понял) можно доработать под использование веб сокетов. Тогда можно реализовать риал тайм мониторинг и всё такое.
Самый простой для реализации вариант - TCP сервер с самопальным протоколом. На устройстве соответственно TCP клиент.

А еще проще самопальный UDP-сервер в дипетчерской и UDP-клиент на устройстве, периодически (обычно раз в минуту достаточно - чуть чаще, чем разрушение ассоциации портов NAT сотового провайдера, если последний выдает серый IP) отправляющий пакет с телеметрическими данными. В случае необходимости удаленного управления со стороны сервера отсылается управляющий пакет на IP:порт, с которого было получено последнее сообщение.
Пишется все на уровне сокетов, размер кода и ресурсоемкость ничтожны. Причем в крайнем случае даже не обязательно наличие встроенного тсп-стека на клиенте: задача на столько проста, что ее можно даже реализовать вручную, отработав lcp, pap и ipcp фазы ррр и затем формируя ppp-ip-udp побайтно вручную (на любителя, конечно, не тем не менее).
В любом случае, если прикрутили HTTP-GET, то чистый UDP реально на много проще.

Свой промежуточный сервер лишит необходимости в IP и NAT. Посмотрите в сторону протоколов MQTT, RabbitMQ - достаточно лёгкие для микроконтроллеров, публичных серверов в интернете хватает.

Предоставляет но только для своих ПЛК.



Работаем в данный момент именно в этом направлении. Поднимаем HTTP сервер со статическим IP адресом и пробуем отрабатывать запрос-ответы между устройством (клиент) и сервером. Пробовали работать с сервером, на котором хостится сайт, но сервер настроен так, что после каждого ответа сервера соединение рвется (Connection: close) Возможно будет написан самопальный протокол поверх http.





В чем преимущество использования UDP в данном случае?

Преимущество UDP всегда - в простоте реализации.



Это сильно: имея http поверх tcp поверх ip, писать поверх еще свою надстройку, чтобы получить собственно исходный функционал ip(udp) А использовать "голый" udp на уровне сокетов религия не позволяет? На самом деле это реально проще любых верхних протоколов и реализуется намного легче - буквально в несколько строчек кода С, без никакого геморроя. И если ваш программист крутит носом и говорит, что так нельзя, то он просто этого не умеет, не имеет желания учиться и, главное, обучен решать только формализованные задачи стандартными методами, освоенными в вузе, без тени креатива. То же касается рассуждений об "гарантийности" доставки tcp без понимания интимных механизмов ее реализации на уровне сокета.

MQTT, RabbitMQ - это тоже достойный вариант, но реализация чуть посложнее. Опять же, если необходим внешний сервер, то написать и разместить на самом дешевом VDS под линукс свой легковесный демон с единственным udp-сокетом для пересылки UDP между клиентом и сервером - дело на полчаса.

Это штатное поведение для http сервера. Чтобы этого избежать, можно использовать keep-alive запросы. Или ознакомиться с принципами работы веб сокетов (нужна поддержка на хостинге, если ваш сервер сидит на стороне).

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