Протокол для простого девайса

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

сервер ему к примеру «STATE» а тот в ответ показания/состояния. и с миганиями также.

Я понимаю, как на сервере входящие запросы обрабатывать — написал простой обработчик и готово.
Я понимаю, как на девайсе исходящие запросы делать: подключился к сети, получил IP, сделал DNS-запрос по хостнейму сервера, отправил самобытный HTTP POST или GET.
А вот как наоборот — этого я не понимаю.

веб сокеты, ну или лонг пулинг если вс не умеет.

ИМХО, делать новый коннект на каждую команду - не правильно. Лучше держать непрерывный коннект с сервером с периодическими Keep Alive-пакетами (по GSM соединения рвуться, если долго ничего не передавать).

Пиши на вебсокетах. Удобно и отлично.

На тебе для затравки.

А вот как наоборот — этого я не понимаю.

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

Зачем там вообще HTTP?

лонг пулинг

long pooling? long pulling?

TCP есть? Зачем все остальное? TCP, построчное общение, запрос-ответ.

Как это разумнее всего сделать?

Я не понимаю, тебе протокол какой-то нужен стандартный поверх TCP? Modbus — стандартный промышленный протокол как раз для таких целей: получить значения датчиков, чем-нибудь мигнуть. Тебе нужен Modbus TCP/IP (Modbus TCP)

Lonk pollink, guv.

Если девайс достаточно производительный (раз может быть http клиентом) - то лично я бы делал наоборот - WWW сервер опрашивает девайс (по необходимости) через cgi запросы, девайс отвечает и выполняет. Можно использовать fastcgi например (почитай http://habrahabr.ru/post/154187/ ). Или вообще реализовать на борту полноценный www-сервер используя libmicrohttpd или mongoose (civetweb)

Веб сокеты — это интересно. Я потому и спрашиваю.

Да Modbus TCP был изначальным вариантом, но потом я решил использовать nginx, так как ничего городить не нужно.

Для modbus тоже есть всякое готовое. Вот, например, библиотеки в Debian. Да и для микроконтроллеров уже есть готовые библиотеки.

$ aptitude search ~dmodbus
collectd-core             statistics collection and monitoring daemon (core system)
libmodbus-dev             development files for the Modbus protocol library
libmodbus5                library for the Modbus protocol
node-crc                  module for calculating Cyclic Redundancy Check (CRC)
python-pymodbus           full Modbus protocol implementation

потом я решил использовать nginx, так как ничего городить не нужно.

Веб сокеты — это интересно

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

но потом я решил использовать nginx, так как ничего городить не нужно.

Насколько я понимаю, решение ты уже выбрал. То есть вопрос твой уже ориентирован на предопределенное решение, а ты хочешь, чтобы мы тут подбодрили чуть-чуть. Ведь что еще можно посоветовать тебе? :) Твое решение имеет смысл только тогда, когда ты делаешь сугубо для себя. Но если ты повышаешь свой уровень до специалиста, то уже не годится - надо думать об интеграции, надежности, стандартизации. Придешь ты со своим девайсом с датчиком куда-нибудь на производство, а там тебе: «И куда нам это втыкать?».

А по-моему, ты хочешь получить удовольствие от разработки своего велосипеда.

Ну, я только ради этого всё и затеял.

Насколько я понимаю, решение ты уже выбрал.

Да.

То есть вопрос твой уже ориентирован на предопределенное решение, а ты хочешь, чтобы мы тут подбодрили чуть-чуть.

Нет. Я хочу, чтобы тут сказали, что моё решение говно и посоветовали, как это сделать правильно.

Нет. Я хочу, чтобы тут сказали, что моё решение говно

Я понял. Нет, ну твое решение имеет право на жизнь. Все зависит от того, где, кем и как будет использоваться устройство.

и посоветовали, как это сделать правильно.

Альтернативы: MQTT или даже XMPP. В модном ныне напрвлении IoT (Internet of Things) эти протоколы вполне себе рассматриваются.

Девайс как раз вполне классифицируется как IoT. Но я думал, вебсокеты в IoT популярнее, чем XMPP.

А вообще, Modbus TCP — это промышленный стандарт, это надёжнее всего должно быть.

выше тебе намекнули про modbus. Наиболее правильный вариант.

Если так уж хочется http, то девайс ходит на сервер, который через websocket или long polling скармливает ему команды или получает состояние датчиков.

Почему именно так: у тебя железяка, в общем случае, будет за NAT опсоса и ходить на неё напрямую у тебя не получится. Но при этом можно забыть про автономность девайса, от батарейки жить долго не будет.

Бред какой то.

К девайсу можно подключиться по TCP и видеть там события и слать команды и получать результаты? Нужно сделать веб морду к этому «TCP»?

Это две сотни строк довольно простого кода на каком-нибудь node.js. Любому студенту будет интересно такое закодить.

Изначально я и хотел сделать Modbus и до сих пор от этой идеи до конца не отказался.
Открыть на сервере порт 502 — ничего сложного. Проблема в том, что на этот порт вешать.
Посоветуй примеры сервера и клиента что ли.

Но я думал, вебсокеты в IoT популярнее, чем XMPP.

ИМХО, о популярности IoT говорить рано. Каждый использует то, что ему нравится. Все, что мы используем в интернете, может быть использовано и тут: и WebSockets, и REST. Пока не попадешь в ситуацию, когда нужна интеграция, какие-то стандартные решения (именно это я имею в виду по «когда, где и кем»).

Я брал libmodbus и пилил на сишечке две небольших софтины, одна выступает как slave, другая как master. Дальше обычный опрос мастером slave. Но есть момент, что modbus не позволяет slave говорить без обращения от master, прерывания не сделать.

Но есть момент, что modbus не позволяет slave говорить без обращения от master, прерывания не сделать.

А и не нужно. В варианте, который я описал та же фигня.

Я брал libmodbus и пилил на сишечке две небольших софтины, одна выступает как slave, другая как master.

Можно код?

Уточнение - можно воспользоваться нормальными корпоративными тарифами для телематики. Там рваться ничего не должно.

Партия^W IETF уже подумал за нас: https://tools.ietf.org/html/rfc7252

В исходниках libmodbus есть каталог tests - там примеры нескольких клиентов и серверов. Вот простейший сервер:

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <errno.h>

#include <modbus.h>

int main(void)
{
    int socket;
    modbus_t *ctx;
    modbus_mapping_t *mb_mapping;

    ctx = modbus_new_tcp("127.0.0.1", 1502);
    /* modbus_set_debug(ctx, TRUE); */

    mb_mapping = modbus_mapping_new(500, 500, 500, 500);
    if (mb_mapping == NULL) {
        fprintf(stderr, "Failed to allocate the mapping: %s\n", modbus_strerror(errno));
        modbus_free(ctx);
        return -1;
    }

    socket = modbus_tcp_listen(ctx, 1);
    modbus_tcp_accept(ctx, &socket);

    for (;;) {
        uint8_t query[MODBUS_TCP_MAX_ADU_LENGTH];
        int rc;

        rc = modbus_receive(ctx, query);
        if (rc != -1) {
            /* rc is the query size */
            modbus_reply(ctx, query, rc, mb_mapping);
        } else {
            /* Connection closed by the client or error */
            break;
        }
    }

    printf("Quit the loop: %s\n", modbus_strerror(errno));

    modbus_mapping_free(mb_mapping);
    modbus_close(ctx);
    modbus_free(ctx);

    return 0;
}

Можно код?

смотри в examples к libmodbus. Свой я успешно прое-л

я думал, вебсокеты в IoT популярнее, чем XMPP.

Первое, с чем ассоциируются IoT сегодня — это MQTT. Второе — обычные HTTP-запросы. Про XMPP в IoT ни разу не слышал :)

веб сокеты

девайс умеет только TCP

Шикарный совет! Да, использовать сокеты поверх http поверх сокетов — это просто генитально.