Что почитать про создание протоколов обмена данными?

С++ + Бюст

Алёна CPP?

Ответы типа: -Возьмите JSon -там и так все есть не подходят.

Возьмите 0MQ и Protobuf.

Некоторые советы есть в книге Реймонда «Искусство программирования для UNIX»

А разве такие книги есть? Думаю, тут можно посмотреть на то, как сделано у «других». Вспоминаются сразу веб-сервисы (SOAP). Наверное, там есть какие-нибудь объяснительные статьи по протоколу.

такие книги есть! Навскидку назову «Design And Validation Of Computer Protocols»

но часто можно обойтись json, google protocol buffers, apache thrift и т.д.

Намного проще всего при таком раскладе Google Protobuf. Сам использовал, очень доволен.

Любопытно. Открытые и доступные в интернете главы выглядят интересно, даже матанно.

Ну тогда и ASN.1 до кучи

http://spinroot.com/spin/whatispin.html там есть интересные референсы. Но все это явно из пушки по воробьям в данном случае.

Для этого в приличных местах используют «шины» - системы обмена сообщениями, типа IBM Websphere, SonicMQ из проприетарщины или RabbitMQ и т.п.

>Возьмите 0MQ и Protobuf.
Я так понимаю это еще один протокол общего назначения. Меня больше интересует как правильно укладывать данные в эти протоколы - общие типы данных, общие команды и т.п.

Сейчас мы используем конструкции типа ключ:значение -
name:слон method:дернуть option:хвост number:10
:)

А вот если надо передать массив, то получаются уродцы вроде:
value1:10,value2.....valueN.

>Некоторые советы есть в книге Реймонда «Искусство программирования для UNIX» Спасибо, поищу.

>«Design And Validation Of Computer Protocols»
Спасибо посмотрю.

но часто можно обойтись json, google protocol buffers, apache thrift и т.д.

Меня интересует более высокий уровень. Как правильно структурировать данные и укладывать в эти протоколы.

>местах используют «шины»
расшифруй

>Сейчас мы используем конструкции типа ключ:значение -

name:слон method:дернуть option:хвост number:10

Может быть тупо RPC надо? Например, ZeroC Ice

> name:слон method:дернуть option:хвост number:10

Поздравляю с изобретением xml-rpc!

Свои 5 копеек (я не спеcИалист;-)))).

Для таких задач я тупо взял модуль pickle для Python (превращает в строку произвольную структуру и может раскрутить ея обратно). ИМНО первый шаг - перейти на что то высокоуровневое, позволяющее передавать структурированные данные, потому как 90% ошибок связаны именно с парсингом. Pickle вроде и под C++ реализован (было что то в boost), но в вместо него можно взять тот же xml или любую другую фигню.

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

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

Даже изложил свой скромный опыт в статье для студентов

http://a-iv.ru/pyart/mysocket-I.pdf

Вторую часть никак не допишу, но может и первая будет полезна в смысле идей;-)))

Спасибо :) Вот потому и спрашиваю, что как-то наизобретались уже. Но вопрос был не в том.

http://a-iv.ru/pyart/mysocket-I.pdf

Спасибо, почитаю. Так-то например JSON идеально подходит - есть миллион реализаций для 100500 языков. По сути создавай объект - который сериализатор сделает строкой, десериализатор превратит снова в объект.

Вот вопрос весь в том, как правильно создавать эти объекты,
чтобы всем было удобно, чтобы передавались нужные данные, чтобы в сериализованном виде было читабельно.

В смысле как правильно создавать эти объекты??? Сериализацией занимается протокол, пользователь сует в него структурированные данные и структурированные данные же получает. Что б протокол поддерживал все, что в него суют - отдельная задача...

Читабельность в сериализованном виде ИМНО нафик ненужна, нужно просто вести логи, куда сливать в текстовом виде что суешь и что получаешь.

Ну а дальше, опять таки, от задачи все очень сильно зависит... МНе удалось сваять штуку, которая обеспечивает удаленный доступ к классу, используем, очень удобно, ИМНО это чем простой удаленный вызов функций, и если говорить про абстрактную библиотеку для всего - то ничего более высокоуровневого абстрактного создать наверное не удасться, дальше неизбежно полезет специфика задачи.

Те, которые настоящие программисты, обзывают это то ли COM-ом то ли RPC - не знаю, я не программист;-)

Точнее сериализацией занимается библиотека поддерживающая протокол ес-но, ну и приходиться допиливать какие то вещи напильником что бы она понимала все, что в нее засовывают;-)

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

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

Вот думал, может есть какой труд, по устройству высокоуровневых протоколов общения между приложениями.

Почитал пока Реймонда. Он похоже советует делать более разговорчивые системы, где клиент и сервер обмениваются несколькими сообщениями, чтобы передать некое «сообщение» вроде того что я приводил. А мы все пытаемся впихать в одну строку - идентификацию, метод и данные к ним.

Собственно у Реймонда отвечено на вопрос в Сабже:) Он приводит ссылки на статьи, гд рассматриваются вопросы создания протоколов обмена данным. Попытаюсь их найти.

Если тебе нужен «высокий уровень», то тебе не протоколы обмена данными нужны, а проектирование самих структур данных.

Очень может быть! Спасибо. Пожалуй именно проектирование структур данных для передачи их через сеть. Посоветуете что-нибудь?

> Пожалуй именно проектирование структур данных для передачи их через сеть.

Честно говоря, я не улавливаю, что такого специфичного в «для передачи по сети». Ну, указателей нет. Вроде всё на этом?

Посоветуете что-нибудь?

Так сразу даже не знаю... боюсь, нужное знание рассеяно по учебника по OO[AD] и проектированию БД.

Но, подозреваю, что должно хватить здравого смысла, бумаги, ручки и минимальной дозу UML/OMT/чтотамеще. Главное, не бросаться реализовывать, пока не разрисуешь структуры данных для _всех_ приложений, и не изобретать своего велосипеда для транспортного уровня - взять Protobuf, Thrift, да хоть SunRPC.

Ну ладно. Бум рисовать.

Меня больше интересует как правильно укладывать данные в эти протоколы - общие типы данных, общие команды

Есть много похожих реализаций для решения ваших проблем - xml, xmlrpc, soap и т.п. Можно на примере этих технологий посмотреть способы упаковки разнородных данных.

Есть какие-нибудь особо хорошие примеры или ищем в гуггле все подряд? :)

Если по уму то надо asn.1, но это не так просто. Если вышепомянутй xml и К' то там обычно тупой gzip потока или сообщения, или сильно реже binary xml. В принципе json/xml + gzip (при необходимости) должны справиться.