[uriy 4]

Ищу реализацию протокол GRPC для ESP32. Нужно подключаться к чужому серверу. Вот тут https://github.com/grpc/grpc есть реализация на C++, но она тянет за собой массу системных файлов от целевой операционной системы.

У меня пока нет никакого желания разбираться с этим громадным вариантом и впихивать это в ESP32. Нужно бы что-то попроще. 

[mantech 34]

1 час назад, uriy сказал:

У меня пока нет никакого желания разбираться с этим громадным вариантом и впихивать это в ESP32. Нужно бы что-то попроще. 

А ничего, что он почти весь зоопарк стеков сетевых и встроенных в ОС использует? Вы хотите исходник на пару сотен строк?))))))))

[uriy 4]

Ну на пару тысяч было бы вполне приемлемо.

mantech, у вас есть опыт его использования в embedded?

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

Как бы не так, чтобы передать 6 байт полезной информации добавляется еще 200-300 байт http2 заголовков.

У меня волосы дыбом от того сколько мусора накидывают и как это продвигают в массы.

Серверную часть ребята писали на Kotlin и они считают что это крутой протокол. При этом они абсолютно ничего не знают о том как он работает и что передает - работает и ладно.

Потом мы удивляемся что программы весят гигабайты и все тормозит.

Не могу даже найти описание полей этого grpc.

У меня есть дампы рабочих запросов, сделанных из-под винды. Это два разных запроса, у одного есть заголовок PRI * HTTP/2.0 у другого нет.

Но на оба запроса сервер корректно отвечает. 

 

[HardEgor 66]

18 минут назад, uriy сказал:

Не могу даже найти описание полей этого grpc.

https://ru.wikipedia.org/wiki/GRPC

[uriy 4]

13 minutes ago, HardEgor said:

https://ru.wikipedia.org/wiki/GRPC

И где там описано что за данные передаются в этом запросе?

00000000  00 00 34 01 04 00 00 00  09 86 04 aa 61 05 5d 1d   ..4..... ....a.].
00000010  7b af 5d 87 49 d7 21 e9  a4 f5 21 74 1a 6a 91 7c   {.].I.!. ..!t.j.|
00000020  69 1a f7 8f 52 6c 3d 1a  ec 3c d6 0e 96 37 24 76   i...Rl=. .<...7$v
00000030  27 58 cd 61 aa 9b 83 c3  c2 c1 c0 bf be 00 00 0d   'X.a.... ........
00000040  00 00 00 00 00 09 00 00  00 00 08 0a 06 31 31 32   ........ .....112
00000050  32 33 35 00 00 00 00 01  00 00 00 09               235..... ....

и в ответе

    00000011  00 00 04 01 04 00 00 00  09 88 c4 c3 c2            ........ .....
    0000001E  00 00 10 00 00 00 00 00  09 00 00 00 00 0b 0a 09   ........ ........
    0000002E  53 54 41 54 55 53 5f 4f  4b 00 00 01 01 05 00 00   STATUS_O K.......
    0000003E  00 09 c1                                           ...

 

[HardEgor 66]

10 минут назад, uriy сказал:

И где там описано что за данные передаются в этом запросе?

там ссылка есть https://ru.wikipedia.org/wiki/Protocol_Buffers

А вот что за классы передаются это вы должны знать.

Цитата

По замыслу разработчиков, сначала должна быть описана структура данных, которая затем компилируется в классы. Вместе с классами идёт код их сериализации в компактном формате представления.

 

[uriy 4]

Я вас наверно удивлю. protobuf добавляет всего лишь два байта к полезным данным и да он хорошо описан. Затем protobuf запихивают в grpc и затем grpc запихивают в HTTP2.

[mantech 34]

1 час назад, uriy сказал:

mantech, у вас есть опыт его использования в embedded?

К сожалению нет... А может к счастью)))

1 час назад, uriy сказал:

У меня волосы дыбом от того сколько мусора накидывают и как это продвигают в массы.

Этот процесс начался еще с того, когда придумали HTTP, потом вещества у кодеров стали забористее)))

1 час назад, uriy сказал:

Потом мы удивляемся что программы весят гигабайты и все тормозит.

Уже давно не удивляемся...

Если не секрет, для чего такая задача понадобилась - управлять RPC с мелкой железки?

Изменено 27 июня, 2023 пользователем mantech

[uriy 4]

Изначальное серверное и клиентское приложение было сделано под писюки, там все работает. Видно те разработчики где-то услышали о модном grpc и пошло поехало. Клиентская часть по большому счету всего-лишь шлет логи на сервер. Потом клиентскую часть решили перенести на девайсы попроще, тогда стали думать об одноплатниках с линуксом. А потом решили что клиентская часть должна стоить не больше 5 баксов. И тут появился я и смог предложить только ESP32. 

[mantech 34]

2 часа назад, uriy сказал:

тогда стали думать об одноплатниках с линуксом.

Вот на этом и надо было остановиться, ИМХО

[AlexG 1]

Для protobuf есть легковесная реализация - nanopb

[uriy 4]

13 hours ago, AlexG said:

Для protobuf есть легковесная реализация - nanopb

Да я ее использую. В самом начале я думал что protobuf и grpc это одно и то же, сделал на ней. Не получил ответ от сервера. Стал сравнивать дампы в сети мои и от готовых программ и ужаснулся сколько там еще мусора поверх protobuf.

Нашел еще вот такое https://github.com/aergoio/aergo-iot-microcontrollers

Там в функции send_grpc_request используется path что туда пихать в нашем случае не понятно. И почему для http2 заголовок в текстовом формате не понимаю.

  sprintf(path, "/types.AergoRPCService/%s", service);
  sprintf(len, "%d", size);

  const nghttp2_nv nva[] = {
    SH2LIB_MAKE_NV(":method", "POST"),
    SH2LIB_MAKE_NV(":scheme", "https"),
    SH2LIB_MAKE_NV(":authority", hd->hostname),
    SH2LIB_MAKE_NV(":path", path),
    //SH2LIB_MAKE_NV("te", "trailers"),
    SH2LIB_MAKE_NV("Content-Type", "application/grpc"),
    //SH2LIB_MAKE_NV("grpc-encoding", "identity")
    SH2LIB_MAKE_NV("content-length", len)
  };

Вот тут в описании http2 в репозитории grpc https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md также есть эти текстовые поля.