LINUX.ORG.RU
Форум — Development  

Простой data/messaging протокол


0

1

Есть своя программа (=есть её исходники) для обнаружения и трекинга объектов на видео. Пока всё один большой комбайн, хочу прикрутить к ней возможность цепляться по tcp/ip клиентом для разных шалостей - например, запросить позицию определённого объекта или отправить команду остановить слежение за определённым объектом. Пока что пихаю всё struct с __attribute__((packed)) и пересылаю её. Но пока команд немного, и данных вроде как тоже - позиция, таймстемп, ещё пара служебных целочисленных значений.

Руки уже зачесались пересылать также и разные другие данные, картинку объекта, например. Другими словами, пересылать бинарные данные неизвестного размера. Думаю добавить поле datasize и data и пересылать блоб. А как грамотные программисты такое реализуют? С json-ами связываться не хочется, хочется KISS.



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

struct с __attribute__((packed)) самый KISS. Я делал на protobuf'е как-то RPC - получилось очень компактно и просто. Что-то вроде: 

Picture::Ptr Client::getPicture(int w, int h, other ....) const {
   return rpc::call("server", "getPicture", rpc::pack(w, h, other ...));
}

NegatiV ★
()

Самое KISSное: код команды (тип передаваемого пакета), опционально длина команды, собственно данные. Структура команды известна исходя из ее кода. Если внутри команды передаются какие-то данные переменной длины, каждые такие данные предваряешь их длиной.

Можно сделать чуть сложнее, но гибче: каждое поле команды предварять кодом типа этого поля, в зависимости от типа далее может идти само значение или еще какие-то вспомогательные префиксы вроде длины.

А вообще существует куча сериализаторов, можно взять готовое и выбрать простое.

staseg ★★★★★
()

RPC мне тоже вспомнилось, но это опять вникать надо и переделывать...

код команды (тип передаваемого пакета), опционально длина команды, собственно данные. Структура команды известна исходя из ее кода.

да, сейчас так и делаю. Сделал 

enum class Command : int16_t {...}

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

каждое поле команды предварять кодом типа этого поля, в зависимости от типа далее может идти само значение или еще какие-то вспомогательные префиксы вроде длины

это мне нравится, это наверное пригодится.

float
() автор топика
Ответ на: комментарий от float

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

man (U)LEB128.

NegatiV ★
()

По моему - лучше не изобретать свой собстенный сериализатор, а взять готовый - тотже protobuf или msgpack. А то и реализовать простой www-интерфейс (хотя бы cgi (fastcgi)).

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

взять готовый - тотже protobuf или msgpack

о, спасибо, я что-то подобное и искал. Protobuf уже в первом ответе упоминался, но я не понял, что это оно.

float
() автор топика
Ответ на: комментарий от NegatiV

Интересная штука, но для меня немного мудрено. Придумал посылать int в качестве битмаски для команд и всякой мелочи.

float
() автор топика
Ответ на: комментарий от joy4eg

xml

noooo! not this shit again.

xmpp уже всем хватило, чтобы понять что к чему.

anonymous
()

KISS не KISS но в лоб пихать структуры в сеть нельзя. Код будет непортабельным. Нужно обязательно писать код сериализации/десериализации. Или возьми что-то типа protobuf

vasily_pupkin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development