Команды для сервера

Точно не знаю, но посмотрите в сторону Qt. Там есть части для работы с сетью.

если хочешь по уму - надо не просто отправлять, но еще и подтверждение дожидаться.
можно извратиться и какойнить modbus/dibus наворотить.

Точно не знаю, но посмотрите в сторону Qt. Там есть части для работы с сетью.

Ога, там есть обёртки для сокетов, которые для полного счастья на систему сигналов-слотов завязаны (по-умолчанию).

Сериализовать и вперед. Может есть готовые решения грамотнее, элегантнее и т.д. ?

ZeroC Ice

ZeroC Ice

RPC какой-нибудь. Или простой для переваривания orb, типа уже посоветованного zeroc ice.

RPC какой-нибудь

плюсую

> Сериализовать и вперед.
Реймонд в бешенстве. Самый трушный вей это использовать текстовый формат (telnet, ftp).

Сериализовать и вперед.

Реймонд в бешенстве.

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

Самый трушный вей это использовать текстовый формат

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

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

PS. Можно воспользоваться ASN.1 для сериализации, описать там все команды красиво и элегантно

XML-RPC

>можно извратиться и какойнить modbus/dibus наворотить.

modbus будет жирновато для этого, ИМХО.

А вот это как, тем более asio юзаю, да и по простому надо:

http://dancinghacker.com/code/rpc/doxygen/index.html

??

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

А Рэймонда все таки рекомендую, он много внимания подобным вопросам посвятил.

Я Реймонда читал. Речь бы о том, трушный вей - подбирать/разрабатывать протокол исходя из задачи, и в ряде случаев, связанных с управлением оборудованием текстовые протоколы не подходят.

Лежит у меня сейчас на столе отличная книжка: Уильям Стивенс «UNIX: взаимодействие процессов». Советую почитать. Описаны всевозможные методы обмена сообщениями между двумя приложениями (сервер-клиент).

Во-первых у него описывается UNIX IPC: в первую очередь взаимодействие процессов на одной машине. Из описываемых им RPC (Sun RPC и Doors), в Linux поддерживается только Sun RPC. Также для ТС неактуально.

Кстати, где сейчас используется Sun RPC кроме как в NFS?

В самописных клиент-серверных структурах, как, например, у ТС.

В самописных клиент-серверных структурах, как, например, у ТС.

Обычный IPC (включая и сокеты) - слишком низкий уровень абстракции для большинства задач. Да и на кой чёрт заморачиваться с переизобретением велосипеда, когда существует море готовых инструментов? Сто раз упомянутый ZeroC Ice, наверное, лучшее или одно из лучших решений для C++, ибо API в нём простой, позволяет использовать свой мощный функционал постепенно с усложнением программы, имеет двойное лицензирование, ну и существует решение для embedded.

Лучшие собаководы, как говорится, рекомендуют.

HTTP?

SOAP тогда уж, чего мелочиться-то?

http://www.linux.org.ru/view-message.jsp?msgid=3628216#comment-3628835

Если есть желание, то можешь глянуть на: git://github.com/urezki/sftpd.git и посметреть как я это делал раньше.

bert-rpc

Либо простой текстовый протокол, либо RPC без наворотов (SunRPC вполне подойдет). Ice - это оверкилл.

ИМХО самый трушный путь - это структура типа:

uint32 frame_size;  //Размер пакета
uint32 frame_code; // код функции
[данные, специфичные для данного кода frame_code размером frame_size байт]

З.Ы. Не забудь про «пульс» через SO_KEEPALIVE, а ещё лучше через свою функцию на прикладном уровне протокола.

>Реймонд в бешенстве. Самый трушный вей это использовать текстовый формат (telnet, ftp).

Для справки, протокол FTP - редкостное ГОВНО !!!

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

Спасибо. Полезно оказалось :)