LINUX.ORG.RU

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


0

1

Привет.

Есть набор самописаных софтин, для которых надо организовать некий протокол общения унифицированный. Программы соотвественно написаны на С, С+ГТК, С++, С++ + Бюст, С++ + QT, Java. Все под линукс. Написаны разными людьми в разное время. Программы общаются через сеть. Каждый писатель создал себе удобный протокол, для доступа к своему творению. Практически все протоколы текстовые.

Программы обмениваются данными в интах, тексте и даблах, как единичными значениями и командами так и массивами по несколько тысяч чисел.

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

Собственно вопрос - чего бы почитать про грамотное устроение протоколов обмена данными. Ответы типа: -Возьмите JSon -там и так все есть не подходят. JSON подходит для всего, но нам нужно причесать его или еще что-то аналогичное под себя.

P.s. Все это надо для автоматизации одного неадронного и небольшого коллайдера.

P.p.s. Вариант - заставить всех делать одним образом - не подходит. Наука работает за интерес.

Извините. за много буков.

★★★★★

С++ + Бюст

Алёна CPP?

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

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

mv ★★★★★
()

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

urxvt ★★★★★
()

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

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

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

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

ott ★★★★★
()

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

vertexua ★★★★★
()

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

anonymous
()
Ответ на: комментарий от mv

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

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

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

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

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

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

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


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

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

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

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

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

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

arhibot
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

petrosha ★★★★★
() автор топика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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